부정 UNL
Last updated
Last updated
(에 의해 추가되었습니다.)
Negative UNL은 XRP Ledger 의 기능으로서, 네트워크가 일부 다운된 상태에서도 전진할 수 있는 능력인 활성성(liveness)을 향상시킵니다. Negative UNL을 사용하여 서버는 현재 온라인 및 동작 중인 검증인에 따라 유효한 이 선언될 수 있도록 유효한 UNL(effective UNL)을 조정합니다. 따라서 신뢰할 수 있는 검증인 중 일부가 오프라인 상태인 경우에도 새로운 ledger 버전이 유효하다고 선언될 수 있습니다.
Negative UNL은 네트워크가 트랜잭션을 처리하는 방식이나 트랜잭션 결과에는 영향을 주지 않습니다. 다만 일부 유형의 일시적인 다운 상태에서 트랜잭션의 최종 결과를 선언하는 네트워크의 능력을 향상시킵니다.
XRP Ledger 프로토콜의 각 서버는 동조하지 않을 것으로 신뢰하는 검증인의 목록인 고유한 노드 목록(Unique Node List, UNL)을 갖습니다. 각 서버는 신뢰하는 검증인들이 새로운 ledger 버전에 대해 컨센서스를 이룰 때 충분한 수의 검증인이 동의할 때 ledger 버전이 유효하게 선언되도록 독립적으로 결정합니다. (기본 구성은 Ripple이 서명한 권장 UNL로, Ripple이 충분히 고유하고 신뢰할 수 있으며 독립적인 검증인으로 간주하는 검증인들의 목록을 사용합니다.) 표준 컨센서스 요구사항은 신뢰하는 검증인 중 최소 80%가 동의해야 합니다.
만약 신뢰하는 검증인 중 20% 이상이 오프라인이 되거나 네트워크와 통신할 수 없는 상태가 되면, 네트워크는 쿼럼을 충족할 수 없으므로 새로운 ledger를 유효화하지 않습니다. 이는 트랜잭션의 최종 결과가 선언된 후에는 트랜잭션의 결과가 변경될 수 없도록 보장하기 위한 설계 선택입니다. 이러한 상황에서 남아 있는 서버들은 여전히 온라인 상태이며 과거 및 임시적인 트랜잭션 데이터를 제공할 수 있지만, 새로운 트랜잭션의 최종 및 변경할 수 없는 결과를 확인할 수는 없습니다.
그러나 이는 일부 신뢰할 수 있는 검증인이 오프라인 상태가 될 경우 네트워크가 전진하는 것을 막을 수도 있습니다. 2020년 10월 6일 기준으로 Ripple의 권장 UNL에는 34개의 검증인이 있으므로, 7개 이상의 검증인이 오프라인 상태가 되면 네트워크는 전진할 수 없게 됩니다. 또한, 하나 또는 두 개의 검증인이 장기간 오프라인 상태인 경우, 남아 있는 검증인 간의 의견 차이가 더 작아져 컨센서스에 도달하는 데 더 많은 시간이 소요될 수 있습니다.
다양한 유효성 검증인들이 항상 100% 가동 상태를 유지하는 것은 합리적으로 기대하기 어렵습니다. 하드웨어 유지보수, 소프트웨어 업그레이드, 인터넷 연결 문제, 표적 공격, 인적 실수, 하드웨어 고장 및 자연재해와 같은 외부 요인으로 인해 유효성 검증인은 일시적으로 사용할 수 없게 될 수 있습니다.
"Negative UNL"은 남은 유효성 검증인들의 컨센서스에 따라 오프라인 상태나 동작 오류가 발생하는 신뢰할 수 있는 유효성 검증인의 목록입니다. Negative UNL에 포함된 유효성 검증인은 새로운 ledger 버전의 컨센서스 도달 여부를 결정하는 데 사용되지 않습니다.
Negative UNL에 있는 유효성 검증인이 온라인으로 돌아오고 일관된 유효성 검증 투표를 보내면, 남은 유효성 검증인들은 일정 시간이 지난 후에 Negative UNL에서 해당 검증인을 제거합니다.
유효성 검증인들이 하나 또는 둘씩 오프라인 상태가 되는 경우, 남은 유효성 검증인들은 Negative UNL을 사용하여 점진적으로 유효 UNL을 조정할 수 있습니다. 이렇게 함으로써 네트워크는 항상 온라인 유효성 검증인의 80%만 있으면 컨센서스 도달을 위한 쿼럼을 충족할 수 있습니다. 네트워크가 분할되는 것을 방지하기 위해 쿼럼은 최소 60%의 총 유효성 검증인을 가져야 합니다.
만약 20% 이상의 유효성 검증인이 동시에 갑자기 오프라인 상태가 된다면, 남은 서버들은 새로운 ledger를 검증할 수 있는 필요한 쿼럼을 충족할 수 없게 됩니다. 그러나 이러한 서버들은 계속해서 연속적인 컨센서스 라운드를 통해 예비적인 전진을 할 수 있습니다. 시간이 지나면서 남은 유효성 검증인들은 예비 ledger 및 조정된 Negative UNL에서 변경사항을 계속 적용하고 유효 UNL을 조정할 것입니다. 상황이 계속되면 네트워크는 예비 ledger 버전의 조정된 Negative UNL을 사용하여 완전히 ledger를 검증할 수 있게 됩니다.
Negative UNL은 stand-alone 모드에는 영향을 주지 않습니다. 에서 서버는 컨센서스를 사용하지 않기 때문입니다.
Negative UNL은 컨센서스 프로세스와 밀접하게 관련되어 있으며, 악재에 대한 네트워크의 연속성과 신뢰성을 유지하기 위해 안전장치가 구축되어 있습니다. 모든 신뢰할 수 있는 유효성 검증인들이 정상적으로 작동하는 경우에는 Negative UNL은 사용되지 않으며 영향을 미치지 않습니다. 일부 유효성 검증인들이 오프라인 상태이거나 동기화되지 않은 것처럼 보일 때에만 Negative UNL 규칙이 적용됩니다.
Negative UNL은 주어진 ledger 버전의 컨센서스 프로세스에 어떤 Negative UNL이 적용되어야 하는지에 대한 시간 기반적인 논쟁을 피하기 위해 느리게 변경될 수 있도록 고안되었습니다.
네트워크의 각 서버는 신뢰할 수 있는 유효성 검증인 목록인 UNL을 가지고 있습니다. (기본적으로 서버의 정확한 UNL은 Ripple이 발행하는 권장 유효성 검증인 목록에 따라 암묵적으로 구성됩니다.) 각 서버는 자체적으로 신뢰하는 유효성 검증인들의 신뢰성을 추적하기 위해 단일 지표인 "신뢰성"을 사용합니다. 이 신뢰성 지표는 서버의 자체적인 컨센서스 뷰와 일치하는 마지막 256개의 ledger에서 해당 유효성 검증인의 유효성 투표가 서버의 뷰와 일치한 횟수의 백분율입니다. 즉:
Va는 한 유효성 검증인으로부터 받은 지난 256개의 ledger에서 서버의 뷰와 일치한 유효성 투표의 총 수입니다.
이 신뢰성 지표는 유효성 검증인의 가용성과 동작을 측정합니다. 유효성 검증인은 네트워크의 나머지 부분과 동기화되어 있으며 서버의 프로토콜 규칙을 따르는 경우에 신뢰성 점수가 높아야 합니다. 유효성 검증인의 신뢰성 점수는 다음과 같은 이유로 인해 감소할 수 있습니다.
서버와의 네트워크 연결 문제로 인해 유효성 검증인의 유효성 투표가 서버에 도달하지 않는 경우.
유효성 검증인이 작동을 중지하거나 과부하가 걸리는 경우.
유효성 검증인의 신뢰성이 50% 미만인 경우, 해당 유효성 검증인은 Negative UNL에 추가될 수 있는 후보입니다. Negative UNL에서 제거되려면 유효성 검증인의 신뢰성이 80% 이상이어야 합니다.
각 서버, 유효성 검증인을 포함하여 신뢰할 수 있는 유효성 검증인들에 대한 신뢰성 점수를 독립적으로 계산합니다. 서로 다른 서버들은 유효성 검증인의 신뢰성에 대해 다른 결론에 도달할 수 있으며, 이는 해당 유효성 검증인의 투표가 한 서버에 도달하지 않았거나 서로 다른 ledger에서 특정 ledger에 대해 동의나 비동의하는 횟수가 다른 경우일 수 있습니다. Negative UNL에서 유효성 검증인을 추가하거나 제거하기 위해서는 신뢰할 수 있는 유효성 검증인의 컨센서스가 특정 유효성 검증인이 신뢰성 기준에 부합하는지 여부에 대해 컨센서스해야 합니다.
Ledger 버전의 ledger 인덱스가 256으로 나누어 떨어지면 해당 ledger 버전은 플래그 ledger로 간주됩니다. Negative UNL은 오직 플래그 ledger에서만 수정할 수 있습니다. (플래그 ledger는 XRP Ledger Mainnet에서 약 15분마다 발생합니다. 거래량이 적은 테스트 네트워크에서는 더 긴 간격으로 발생할 수 있습니다.)
각 플래그 ledger마다 다음과 같은 변경 사항이 적용됩니다:
이전 플래그 ledger에서 예약된 Negative UNL 변경 사항이 다음 ledger 버전에 적용됩니다. 플래그 ledger 자체의 컨센서스 프로세스에서는 예약된 변경 사항을 사용하지 않습니다.
만약 Negative UNL이 가득 차 있지 않다면, 각 서버는 신뢰도가 50% 미만인 신뢰할 수 있는 유효성 검증인 중에서 최대 1명을 Negative UNL에 추가하기 위해 제안합니다.
만약 Negative UNL이 비어 있지 않다면, 각 서버는 Negative UNL에서 최대 1명의 유효성 검증인을 제거하기 위해 제안할 수 있습니다. 서버는 다음과 같은 이유로 Negative UNL에서 유효성 검증인을 제거할 수 있습니다:
해당 유효성 검증인의 신뢰도가 80% 이상인 경우.
해당 유효성 검증인이 자신의 UNL에 포함되어 있지 않은 경우. (유효성 검증인이 영구적으로 다운되면 이 규칙에 따라 UNL에서 제거될 수 있도록 보장됩니다.)
Negative UNL에 대한 제안 변경 사항이 컨센서스를 달성하면 해당 변경 사항은 다음 플래그 ledger에 적용될 수 있도록 예약됩니다. 한 번에 최대 1명의 추가와 1명의 제거가 이와 같은 방식으로 예약될 수 있습니다.
Negative UNL에 대한 예약된 및 실제 변경 사항은 ledger의 상태 데이터에 있는 NegativeUNL 객체에서 추적됩니다.
네트워크가 두 개 이상의 하위 네트워크로 분리되는 것을 방지하기 위해 Negative UNL은 전체 UNL 항목 수의 60%보다 적은 쿼럼 요구사항을 줄일 수 없습니다. 이를 보장하기 위해 서버는 Negative UNL에 있는 유효성 검증인 수가 서버의 구성된 UNL에 있는 유효성 검증인 수의 25% (내림하여 반올림)인 경우 Negative UNL을 "가득 찬" 것으로 간주합니다. (25%는 75%가 남은 상태에서 80% 컨센서스가 원래 수의 60%와 동일하도록 25%의 유효성 검증인이 제거된 경우를 기반으로 계산됩니다.) 서버가 Negative UNL이 가득 찬 것으로 간주되면 새로운 추가 제안은 하지 않지만, 최종 결과는 신뢰할 수 있는 유효성 검증인의 컨센서스에 따라 달라집니다.
신뢰성 임계값에 따라 여러 개의 유효성 검증인이 Negative UNL에 추가될 수 있는 경우가 있습니다. 하나의 유효성 검증인만 한 번에 Negative UNL에 추가될 수 있으므로, 서버는 어떤 유효성 검증인을 추가 제안할지 선택해야 합니다. 여러 후보가 있는 경우, 서버는 다음 메커니즘을 사용하여 어떤 유효성 검증인을 제안할지 선택합니다:
부모 ledger 버전의 ledger 해시로 시작합니다.
각 후보 유효성 검증인의 공개 키를 사용합니다.
후보 유효성 검증인과 부모 ledger의 해시의 XOR(exclusive-or) 값을 계산합니다.
XOR 연산의 결과값이 숫자적으로 가장 작은 유효성 검증인을 제안합니다.
주어진 플래그 ledger에서 Negative UNL에서 제거해야 할 다중 후보가 있는 경우, 서버는 동일한 메커니즘을 사용하여 후보 중 하나를 선택합니다.
이 메커니즘은 다음과 같은 유용한 특성을 가지고 있습니다:
모든 서버가 사용할 수 있는 정보로 빠르게 계산할 수 있습니다. 대부분의 서버는 신뢰할 수 있는 유효성 검증인에 대해 약간 다른 점수를 계산하더라도 동일한 후보를 선택합니다. 이는 어떤 서버에서 유효성 검증인이 가장 신뢰성이 낮거나 높은지에 대해 다른 의견이 있더라도 유효성 검증인을 선택하는 데에 큰 영향을 주지 않습니다. 이는 서버들이 어떤 유효성 검증인을 추가하거나 제거할지에 대한 컨센서스를 달성할 가능성이 높다는 것을 의미합니다.
이 방법은 항상 동일한 결과를 제공하지는 않습니다. Negative UNL에 대한 하나의 제안 변경이 컨센서스를 달성하지 못하는 경우, 네트워크는 계속해서 동일한 유효성 검증인을 추가하거나 제거하려는 일부 서버들로 인해 매번 문제가 발생하지 않습니다. 네트워크는 나중에 다른 후보 유효성 검증인을 Negative UNL에 추가하거나 제거하기 위해 노력할 수 있습니다.
Negative UNL은 다른 컨센서스 과정, 예를 들어 제안된 트랜잭션 세트에 포함할 트랜잭션을 선택하는 과정에는 영향을 미치지 않습니다. 이 단계들은 항상 구성된 UNL을 기반으로 하며, 임계값은 신뢰할 수 있는 유효성 검증인이 현재 컨센서스 라운드에 활동적으로 참여하는 수에 따라 결정됩니다. Negative UNL에 있는 유효성 검증인도 컨센서스 과정에 참여할 수 있습니다.
다음 예제는 Negative UNL이 컨센서스 과정에 어떻게 영향을 미치는지를 보여줍니다:
서버의 UNL에는 38개의 신뢰할 수 있는 유효성 검증인이 포함되어 있으므로 80%의 쿼럼은 38개 중 최소 31개의 신뢰할 수 있는 유효성 검증인입니다.
MissingA와 UnsteadyB라는 2개의 유효성 검증인이 오프라인으로 보입니다. (두 유효성 검증인 모두 신뢰성 점수 < 50%입니다.) ledger N의 컨센서스 과정에서 나머지 유효성 검증인들 중 많은 수가 UnsteadyB를 Negative UNL에 추가하기 위해 제안합니다. 최소 31개의 남은 유효성 검증인의 컨센서스를 통과하여 ledger N은 UnsteadyB가 비활성화될 예정인 상태로 유효성을 검증합니다.
N+1부터 N+256까지의 ledger에서 컨센서스 과정은 변경 없이 계속됩니다.
다음 플래그 ledger인 N+256에서 UnsteadyB는 자동으로 ledger의 "비활성화" 목록으로 이동합니다. 또한 MissingA는 여전히 오프라인이므로 유효성 검증인들의 컨센서스에 따라 다음 플래그 ledger에서 MissingA가 비활성화될 예정입니다.
N+257부터 N+512까지의 ledger에서 쿼럼은 이제 37개의 유효성 검증인 중 30개입니다.
UnsteadyB는 N+270의 ledger에서 다시 온라인으로 돌아옵니다. UnsteadyB는 N+270부터 N+511까지의 유효성 검증 투표를 네트워크와 일치시켜 신뢰성 점수가 80% 이상으로 계산됩니다.
다음 플래그 ledger인 N+256에서 MissingA는 예정된 대로 비활성화 목록으로 자동으로 이동합니다. 한편, 유효성 검증인들의 컨센서스에 따라 향상된 신뢰성 점수 때문에 UnsteadyB가 Negative UNL에서 제거되도록 예정됩니다.
N+513부터 N+768까지의 ledger에서 쿼럼은 이제 36개의 유효성 검증인 중 29개입니다. UnsteadyB는 계속해서 안정적으로 유효성 검증을 보내는 동안 MissingA는 여전히 오프라인입니다.
N+768의 플래그 ledger에서 예정된 대로 UnsteadyB가 자동으로 비활성화 목록에서 제거됩니다.
결국, MissingA가 아마도 돌아오지 않을 것이라고 판단하여 MissingA를 서버의 구성된 UNL에서 제거합니다. 이후로 서버는 매 플래그 ledger마다 MissingA를 Negative UNL에서 제거하도록 제안합니다.
유효성 검증인 운영자들이 구성된 UNL에서 MissingA를 제거함에 따라 그들의 유효성 검증인들은 MissingA를 Negative UNL에서 제거하기 위해 투표합니다. 충분한 유효성 검증인들이 이를 수행하면 MissingA를 제거하기 위한 제안이 컨센서스에 도달하고, MissingA는 예정된 후에 Negative UNL에서 최종적으로 제거됩니다.
유효성 검증인이 서버와 같은 프로토콜 규칙을 따르지 않는 경우. (설정 오류, 소프트웨어 버그, 를 의도적으로 따르거나 악의적인 동작 등 여러 가지 가능성이 있음)
Note: 이는 이나 유사한 없이도 ledger의 상태 데이터가 수정되는 몇 가지 경우 중 하나입니다.
Negative UNL에 유효성 검증인을 추가하거나 제거하기 위한 제안은 형태로 이루어집니다. 컨센서스 프로세스는 각 이 컨센서스를 달성하거나 폐기되는지를 결정합니다. 즉, 특정 유효성 검증인을 Negative UNL에서 추가하거나 제거하기 위해서는 신뢰할 수 있는 서버들의 컨센서스가 동일한 변경 사항을 제안해야 합니다.
에서는 부모 ledger의 Negative UNL에 있는 유효성 검증인이 비활성화됩니다. 각 서버는 비활성화된 유효성 검증인을 제거하여 구성된 UNL로 구성된 "유효 UNL"을 계산하고 쿼럼을 다시 계산합니다. (쿼럼은 항상 유효 UNL의 최소 80% 및 구성된 UNL의 최소 60%입니다.) 비활성화된 유효성 검증인이 유효성 검증 투표를 보내면, 서버는 해당 투표를 비활성화된 유효성 검증인의 신뢰도 측정을 계산하기 위한 용도로 추적하지만, 해당 투표를 컨센서스에 도달하는 데 사용하지 않습니다.
