공격과 실패 모드에 대한 컨센서스 보호(Consensus Protections Against Attacks and Failure Modes)

XRP Ledger 컨센서스 프로토콜은 비잔틴 장애에 내구성이 있는 컨센서스 메커니즘으로, 모든 종류의 문제가 발생할 수 있는 상황에서 작동하도록 설계되었습니다. 참여자들은 신뢰할 수 없는 개방 네트워크를 통해 통신하며, 악의적인 행위자들은 언제든지 시스템을 제어하거나 중단하려고 시도할 수 있습니다. 게다가, XRP Ledger 컨센서스 프로토콜의 참여자 집합은 미리 알려져 있지 않으며 시간이 지남에 따라 변경될 수 있습니다.

네트워크의 원하는 속성을 유지하면서 트랜잭션을 빠르게 확인하는 것은 복잡한 과제이며, 완벽한 시스템을 구축하는 것은 불가능합니다. XRP Ledger 컨센서스 프로토콜은 대부분의 상황에서 최대한 잘 작동하도록 설계되었으며, 작동하지 못하는 상황에서는 가능한 우아하게 실패합니다.

이 문서는 XRP Ledger 컨센서스 프로토콜이 직면하는 일부 유형의 도전과 그 처리 방법에 대해 설명합니다.

개별 유효성 검증인의 부적절한 행동(Individual Validators Misbehaving)

유효성 검증인은 각 새로운 ledger 버전을 결정하는 과정에 적극적으로 기여하는 서버입니다. 유효성 검증인은 구성된 서버들에게 (간접적으로 포함되어) 신뢰를 받으며 영향을 미칠 수 있습니다. 어떤 유효성 검증인이 부적절한 행동을 한다고 해도 컨센서스는 지속될 수 있으며, 다양한 실패 사례를 포함하여 다음과 같습니다:

  • 이용 불가능하거나 과부하 상태인 경우.

  • 네트워크에서 부분적으로 연결이 끊긴 경우, 그들의 메시지가 일부 참가자에게만 지연 없이 도달하는 경우.

  • 다른 사람을 속이거나 네트워크를 중단하기 위해 의도적으로 행동하는 경우.

  • 억압적인 정부로부터의 위협과 같은 외부 요인으로 인해 악의적으로 행동하는 경우.

  • 버그나 오래된 소프트웨어로 인해 혼란스러운 또는 잘못된 메시지를 우연히 전송하는 경우.

일반적으로 컨센서스는 신뢰하는 유효성 검증인의 약 20% 미만이 잘못된 행동을 하는 경우에도 문제 없이 계속될 수 있습니다. (구체적인 비율 및 관련 수학적인 내용은 최신 컨센서스 연구 문서를 참조하십시오.)

만약 유효성 검증인의 약 20% 이상이 도달할 수 없거나 적절하게 행동하지 않는 경우, 네트워크는 컨센서스에 도달하지 못하게 됩니다. 이러한 상황에서는 새로운 거래가 일시적으로 처리될 수 있지만, 새로운 ledger 버전은 검증되지 않으므로 해당 거래의 최종 결과는 확실하지 않습니다. 이러한 경우 XRP Ledger가 정상적으로 작동하지 않음이 명백해지며, 인간 참가자들은 기다릴지 아니면 신뢰하는 유효성 검증인의 구성을 다시 설정할지를 결정하는 개입을 할 수 있습니다.

잘못된 거래를 확인하기 위해서는 신뢰하는 유효성 검증인의 최소 80%가 해당 거래를 승인하고 정확한 결과에 동의해야 합니다. (잘못된 거래에는 이미 사용된 자금을 소비하는 거래 또는 네트워크의 규칙을 위반하는 거래가 포함됩니다.) 즉, 신뢰하는 유효성 검증인의 대다수가 의도적으로 협력해야만 잘못된 거래를 확인할 수 있습니다. 전 세계의 다양한 사람들과 기업들이 운영하는 수십 개의 신뢰할 수 있는 유효성 검증인이 있기 때문에 이는 의도적으로 달성하기 매우 어려울 것입니다.

소프트웨어 취약점(Software Vulnerabilities)

XRP Ledger 컨센서스 프로토콜의 구현, 일반적으로 배포되는 소프트웨어 패키지 또는 해당 의존성에 대한 버그(또는 악성 코드)는 심각한 문제입니다. 조심해야 할 사항입니다. 신중히 테스트하고 검토하는 절차를 거치고, 안전한 소프트웨어 패키지를 제공하기 위해 Ripple은 다음과 같은 조치를 취하고 있습니다:

  • 공개 소스 코드 기반: 이를 통해 일반 대중이 관련 소프트웨어를 검토, 컴파일 및 독립적으로 테스트할 수 있습니다.

  • 공식 XRP Ledger 저장소에 대한 변경 사항에 대한 철저하고 견고한 코드 검토 프로세스.

  • 모든 릴리스 및 공식 소프트웨어 패키지에 대한 Ripple 직원의 디지털 서명.

  • 보안 취약점 및 불안정성에 대한 정기적인 전문적인 검토.

  • 보안 연구자들이 책임을 지고 취약점을 공개할 경우 보상하는 버그 바운티 프로그램.

사이빌 공격(Sybil Attacks)

사이빌 공격은 가짜 신분을 가진 많은 수의 신분을 사용하여 네트워크를 제어하려는 시도입니다. XRP Ledger에서 사이빌 공격은 많은 수의 유효성 검증인을 실행한 다음, 다른 참가자들을 설득하여 해당 유효성 검증인을 신뢰하도록 만드는 형태로 이루어질 수 있습니다. 이러한 유형의 공격은 이론적으로 가능하지만, 유효성 검증인이 신뢰받기 위해서는 인간의 개입이 필요하기 때문에 실현하기는 매우 어려울 것입니다.

어떤 유효성 검사 서버를 실행하더라도, 해당 서버는 기존 참가자들이 검증된 것으로 여기는 내용에 어떠한 의견도 제시할 수 없습니다. 다른 서버들은 유효성 검증인 목록이나 명시적인 구성을 통해 신뢰하는 유효성 검증인들만을 수신합니다. (기본 유효성 검증인 목록이 작동 방식에 대한 요약은 아래 "유효성 검증인 중복 요구 사항"을 참조하십시오.)

이러한 신뢰는 자동으로 이루어지지 않으며, 성공적인 사이빌 공격을 수행하려면 대상 인간 및 기업을 설득하여 XRP Ledger 서버를 재구성하여 공격자의 유효성 검증인을 신뢰하도록 만드는 어려운 작업이 필요합니다. 실제로 하나의 개별 개체가 속았다고 하더라도, 이는 구성을 변경하지 않는 다른 참가자들에게는 최소한의 영향을 미칠 것입니다.

51% 공격(51% Attack)

"51% 공격"은 한 당사자가 모든 마이닝 또는 투표 권한의 50% 이상을 통제하는 블록체인 시스템에 대한 공격입니다. (엄밀히 말하면, 50% 이상의 어떤 양도 충분합니다.) XRP Ledger는 컨센서스 메커니즘에서 마이닝을 사용하지 않기 때문에 51% 공격에 취약하지 않습니다. XRP Ledger의 다음으로 가까운 유사한 공격 형태는 사이빌 공격이며, 이 역시 어려울 것입니다.

유효성 검증인 중복 요구 사항(Validator Overlap Requirements)

XRP Ledger의 모든 참여자들이 인증된 거래에 대해 컨센서스를 이루려면, 그들은 우선 대부분의 다른 이들이 선택한 신뢰할 수 있는 검증인들의 집합을 선택해야 합니다. 최악의 경우, 약 90% 미만의 중복이 있을 경우 일부 참가자들이 서로 이겨나갈 수 있습니다. 이러한 이유로 Ripple은 회사, 산업 및 커뮤니티에서 운영하는 신뢰할 수 있고 잘 유지되는 서버를 포함한 추천 검증인 목록을 서명하여 게시합니다.

기본적으로 XRP Ledger 서버는 Ripple이 운영하는 검증인 목록 사이트를 사용하도록 설정되어 있습니다. 해당 사이트는 Ripple이 주기적으로 업데이트하는 추천 검증인 목록(또는 추천 Unique Node List, UNL)을 제공합니다. 이런 방식으로 설정된 서버들은 최신 버전의 목록에 있는 모든 검증인들을 신뢰하게 되며, 이는 동일한 목록을 사용하는 다른 서버들과 100% 중복을 보장합니다. 기본 설정에는 사이트의 내용의 진위를 검증하는 공개 키가 포함되어 있습니다. 사이트가 다운되는 경우, XRP Ledger의 P2P 네트워크에 있는 서버들이 서로 사이에서 서명된 목록 업데이트를 직접 중계할 수 있습니다.

기술적으로, 서버를 운영한다면, 개인적으로 신뢰하는 검증인를 개별적으로 선택하거나 자신만의 목록 사이트를 설정할 수 있지만, Ripple은 이렇게 하는 것을 권장하지 않습니다. 만약 선택한 검증인 집합이 다른 검증인 집합과 충분한 중복이 없다면, 서버는 네트워크의 나머지 부분과 이격할 수 있고, 서버의 이격된 상태에 따른 조치를 취함으로써 돈을 잃을 수 있습니다.

보다 이질적인 검증인 목록을 허용하는 향상된 컨센서스 프로토콜 설계에 대한 연구가 진행 중입니다. 자세한 정보는 컨센서스 연구 페이지를 참조하십시오.

Last updated