리플 CTODDavid Schwartz는 최근 몇 달 동안 운영되어 온 XRP Ledger 허브에 대한 업데이트를 공유했습니다.
hisXRP Ledgerhub에 대한 Ripple의 CTO 업데이트는 XRP Ledgerhub의 안정성을 칭찬하는 동시에 리플 업그레이드 및 XRP Ledger 수정 프로세스와 관련된 중요한 질문을 제기하면서 암호화폐 커뮤니티로부터 반응을 이끌어 냈습니다.
XRP Ledger는 합의 프로세스를 활용하여 거래 처리에 영향을 미치는 모든 변경 사항을 승인하고 검증인이 이에 투표하는 수정 시스템을 사용합니다. 수정안이 2주 동안 80% 이상의 지지를 받으면 수정안이 통과되고 변경 사항은 모든 후속 원장 버전에 영구적으로 적용됩니다.
X 사용자는 dUNL 서버에서 여러 버전의 리플이 발생한 사례를 언급하면서 리플 업그레이드를 활성화하는 경우 수정 프로세스를 적용할 수 있는지 문의했습니다.
나는 이것이 검증자의 힘에 대한 본질적인 제한을 약화시킬 것이라고 생각합니다. 이러한 변경을 통해 검증자는 의식적으로 수락하기로 선택하지 않은 규칙 변경 사항을 노드가 수락하도록 할 수 있습니다. 나는 수정 과정을 단순한 조정 메커니즘으로 유지하는 것을 강력히 선호하며…
11월에는 v2. 6. 새로운 디렉터리 제한 수정 사항과 중요한 버그 수정 사항이 추가된 2 릴리스가 출시되었습니다. 12월 18일 "디렉터리 제한 수정" 수정안이 활성화되면서 업그레이드되지 않은 많은 노드가 "수정안 차단" 상태가 되었습니다.
Rippled v2가 출시된 지 3주도 채 되지 않았습니다. 6. 2, 리플X는 rippled v. 3. 0. 0의 또 다른 새 버전을 사용할 수 있으며 새로운 수정 사항과 버그 수정이 추가되었음을 알렸습니다. 버전 v3. 0. 0은 또한 활성화되지 않았지만 거의 코드가 완성된 대출 프로토콜과 같은 수정안을 추가했습니다.
이를 고려하여 X 사용자는 RippleCTO에게 투표 가능 수정 사항으로 "update rippled"를 추가할 수 있는지 물었습니다. 검증인의 80%가 업그레이드에 투표하면 서버는 사용자 개입 없이 단계적 업그레이드를 수행한다고 X 사용자는 덧붙였습니다.
리플 CTO는 이것이 검증자의 권한에 대한 본질적인 제한을 약화시킬 수 있다고 말했습니다. 이것이 완료되면 검증자는 의식적으로 수락하기로 선택하지 않은 규칙 변경 사항을 노드가 수락하도록 할 수 있습니다.
Schwartz는 이 아이디어가 그에게 그다지 적합하지 않은 이유에 대해 더 자세히 설명하면서 수정 과정을 기본 거버넌스 메커니즘이 아닌 단순한 조정 메커니즘으로 유지하는 것을 강력히 선호한다고 말했습니다.
X 사용자는 XRP Ledger의 빠른 혁신 속도로 인해 업데이트 동기화, 테스트 및 변화의 바람에 귀를 기울이는 것이 많은 작업이 될 수 있다고 언급했습니다. 리플 CTO는 "노드 운영자에게 경고하는 일종의 우선순위 방법이 좋을 것"이라고 강조했습니다.
원문 제목: Ripple CTO Reacts to Speculation Around XRP Ledger Upgrade Ahead of 2026
Ripple CTODavid Schwartzrecently shared an update about his XRP Ledger hub, which has been operational for months now.
The Ripple's CTO updates about hisXRP Ledgerhub drew responses from the crypto community, with an X user praising its stability while bringing up an important question pertaining to rippled upgrades and the XRP Ledger amendment process.
XRP Ledger uses an amendment system that utilizes the consensus process to approve any changes that affect transaction processing, with validators voting on them.
If an amendment receives more than 80% support for two weeks, the amendment passes and the change applies permanently to all subsequent ledger versions.
The X user had asked if the amendment process could be applied in the case of enabling rippled upgrades, citing the case of many versions of rippled on the dUNL servers.
I think this would weaken an essential limitation on the power of validators.
With that change, validators could get nodes to accept rule changes that they didn't consciously choose to accept.
I strongly prefer keeping the amendment process as a mere coordination mechanism and….
In November, the rippled v2.
6.
2 release was made available, which adds a new fixDirectoryLimit amendment and a critical bug fix.
The activation of the "fixDirectoryLimit" amendment on Dec.
18 saw many nodes that did not upgrade to be "amendment blocked.
".
Less than three weeks after the release of rippled v2.
6.
2, Ripplex made it known that another new version of rippled v.
3.
0.
0 was available, which added new amendments as well as bug fixes.
Version v3.
0.
0 also added amendments, such as the lending protocol, which have not been enabled but are nearly code complete.
Given this, the X user asked theRippleCTO if it would be possible to add "update rippled" as a vote-enabled amendment.
If 80% of validators vote to upgrade, the servers perform a staged upgrade without user intervention, the X user added.
TheRipple CTOresponded, saying this might weaken an essential limitation on the power of validators.
If this is done, validators could get nodes to accept rule changes that they did not consciously choose to accept.
Shedding further light on why the idea does not sit too well with him, Schwartz said he strongly prefers keeping the amendment process as a mere coordination mechanism and not as a primary governance mechanism.
The X user mentioned that with the fast pace of innovation on the XRP Ledger, synchronizing updates, testing and keeping an ear to the winds of change might be a lot of work.
The Ripple CTO highlighted that "some kind of priority way to alert the node operator would be good.
".
