어멘드먼트 프로세스 자세히 살펴보기

XRP 레저의 프로토콜 규칙이 어떻게 변경될 수 있는지, 그리고 그 과정에 내장된 안전장치를 자세히 살펴봅니다.

본 위키의 기술 섹션 전반에서 설명한 모든 네이티브 기능 — AMM, NFT, 에스크로 등 — 은 동일한 공식 메커니즘인 어멘드먼트 프로세스를 통해 XRP 레저에 도입되었습니다. 이 페이지는 What Is the XRP Ledger?에서의 간략한 언급보다 더 깊이 들어갑니다.

어멘드먼트란 무엇인가

어멘드먼트는 XRP 레저의 프로토콜 규칙에 대한 제안된, 개별적인 변경입니다 — (AMM이나 NFT 같은) 완전히 새로운 거래 유형 추가부터 기존 동작의 예외 케이스 수정까지 무엇이든 될 수 있습니다. 어멘드먼트는 이름과 고유한 해시로 식별되며, rippled 코드베이스에 미리 구현되어 소프트웨어 릴리스로 배포되지만, 네트워크 자체가 투표로 승인할 때까지는 활성화되지 않습니다.

왜 활성화가 코드 배포와 분리되어 있는가

이는 의도적인 안전 설계입니다. 소프트웨어 개발자는 새로운 어멘드먼트를 위한 코드를 충분히 미리 작성하고 배포하여 노드와 검증자 운영자들에게 소프트웨어를 업데이트할 시간을 줄 수 있지만, 검증자들이 명시적으로 지지를 표명할 때까지 새로운 규칙은 실제 네트워크에서 발효되지 않습니다. 이는 "코드가 존재하고 이용 가능하다"는 것과 "네트워크가 이를 사용하기로 합의했다"는 것을 분리하여, 단일 소프트웨어 릴리스가 은밀하게 컨센서스 규칙을 바꾸는 것을 방지합니다.

투표 메커니즘

어멘드먼트를 지원하는 코드가 배포되면, 검증자들은 자신이 생성에 참여하는 레저에 해당 어멘드먼트에 대한 "찬성" 투표를 포함시킬 수 있습니다. 어멘드먼트는 다음 조건이 충족될 때만 활성화됩니다.

최소 **신뢰받는 검증자의 80%**가 이에 찬성 투표하고 있으며, 그리고
그 80% 이상의 지지 수준이 2주 동안 지속적으로 유지되어야 합니다.

2주가 지나기 전 어느 시점에서든 지지가 임계값 아래로 떨어지면 카운트다운이 재설정됩니다. 이는 이 프로세스가 짧고 일시적인 지지 급등에 의도적으로 저항력을 갖도록 하며, 진정하고 지속적인 컨센서스를 요구합니다.

이것이 방지하는 것

일방적인 변경 불가. 검증자를 운영하고 널리 사용되는 기본 UNL을 발행하는 Ripple조차도(자세한 내용은 Unique Node List and Validators 참고) 단독으로 어멘드먼트를 활성화할 수 없습니다 — 신뢰받는 검증자 집합 전반에 걸친 폭넓은 합의가 필요합니다.
은밀한 강제 업그레이드 불가. 제안된 변경에 동의하지 않는 노드 운영자는 단순히 이를 지원하는 소프트웨어로 업그레이드하지 않으면 되며, 네트워크의 충분한 부분이 그들에게 동의하는 한 그 변경은 활성화되지 않습니다.
경고 없는 우발적인 영구적 실수 방지. 2주간의 지속적인 압도적 다수 요건은 거래소, 지갑 제공업체, 애플리케이션 개발자를 포함한 생태계에 변경이 즉시 전환되는 대신 실질적인 사전 통지를 제공합니다.

네트워크가 합의하지 못하면 어떻게 되는가

원칙적으로, 다수가 원하는 어멘드먼트를 의미 있는 소수의 검증자가 지지하기를 거부하고 그 불일치가 해소될 수 없다면, 네트워크는 두 개의 호환되지 않는 체인으로 분열될 수 있습니다("하드포크"). 하지만 실제로는 XRPL의 어멘드먼트 역사에서 이런 종류의 논쟁적인 분열은 발생하지 않았으며, 제안된 어멘드먼트는 일반적으로 폭넓은 수용으로 수렴하거나 커뮤니티 논의 후 보류되는 쪽으로 귀결되어 왔습니다(어떤 기능이 검증자 투표에 도달하기 훨씬 전에 이루어지는 논의 단계는 XLS: How New Features Get Proposed 참고).

오래된 어멘드먼트 폐기

어멘드먼트는 기능이 완전히 대체된 후 "폐기됨"으로 표시될 수도 있어, 실제 운영 중인 네트워크에서 이미 활성화된 동작을 방해하지 않으면서 시간이 지남에 따라 코드베이스를 정리할 수 있습니다.