https://iohk.io/en/blog/posts/2024/05/08/ouroboros-genesis-design-update/
Ouroboros Genesis는 네트워크 노드가 새로 생성되거나 부재 후 돌아올 때 네트워크 노드를 보호하기 위한 대책을 포함하여 이미 강력한 Ouroboros 프로토콜을 개선한 일련의 기능입니다.
Ouroboros는 Cardano 블록체인의 핵심인 합의 프로토콜입니다. Cardano의 지속적인 개발과 활용 증가를 고려하여 Ouroboros는 계획된 업그레이드 경로를 따라 진행되었습니다. Ouroboros Classic은 최초로 입증된 안전한 지분 증명 프로토콜이었습니다. Ouroboros BFT는 Byron 업데이트를 가능하게 하는 임시 솔루션이었습니다. Ouroboros Praos는 Ouroboros Classic의 개발을 계속했습니다. 우로보로스의 진화는 현재 2024년 3분기에 출시될 예정인 우로보로스 제네시스(Ouroboros Genesis)를 통해 한 단계 더 나아갈 것입니다.
이 문서에서는 Ouroboros Genesis 프로토콜의 개발 및 구현에 대한 최근 업데이트를 설명합니다.
지금까지의 우로보로스 이야기
블록체인은 노드라고 불리는 기계 전체에 복제된 분산 원장입니다. 단일 중앙 권한이 없기 때문에 모든 원장 사본의 일관성과 불변성을 보장하는 메커니즘이 존재해야 합니다. 그 메커니즘이 합의 프로토콜입니다. 또한 프로토콜은 노드가 새 블록을 검증하고 체인에 추가하도록 인센티브를 설정합니다.
Ouroboros는 Cardano의 시간을 여러 시대로 나누고, 각 시대를 슬롯으로 세분화합니다. 슬롯은 블록이 생성될 수 있는 짧은 기간을 나타냅니다.
Ouroboros Classic은 대부분의 노드가 온라인 상태이고 일관된 원장 사본을 보유하고 있을 때 안전한 것으로 입증되었습니다. 공격자는 어느 노드가 다음 슬롯 리더(체인에 블록을 추가하는 노드)가 될지 예측할 수 없으므로 공격 비용이 매우 높습니다.
우로보로스 프라오스는 다음 슬롯 리더 선택의 무작위성을 높이고 다른 가능한 공격에 대한 대응책을 추가했습니다.
Ouroboros Genesis는 노드가 처음으로 네트워크에 합류하거나(제네시스 블록에서 시작) 장기간 부재 후 다시 합류하는 상황을 해결합니다. 이러한 노드는 따라잡을 때까지 취약한 상황에 처해 있습니다. 예를 들어, 장거리 공격은 공격자가 체인의 기록을 다시 쓰려고 시도할 때 발생합니다. 적들은 메인 체인보다 더 빠르게 블록을 비밀리에 생성할 수 있도록 큰 지분을 축적합니다. 그런 다음 대체 역사적 체인이 준비되면 공격자는 메인 체인을 상대의 체인으로 전환하려고 시도합니다. Genesis 구현은 동기화 노드가 가려지지 않는 한 장거리 공격을 완화합니다. Eclipse 공격은 공격자가 피해자 노드를 악의적인 피어로 둘러싸서 실제 네트워크를 모호하게 하려고 시도할 때 발생합니다.
최신 개발
Genesis는 다음과 같은 새로운 개념을 도입합니다.
- 원장 동료
- 경량 체크포인트(임시 대체/재정의)
- 열정의 한계(LoE)
- 제네시스 밀도 단절(GDD)
- 인내심의 한계(LoP)
- 창세기 상태 머신
원장 동료
Genesis 문서에서 가장 크게 벗어난 점은 롤백에 대한 Praos 노드의 제한을 보존하려는 초기 아키텍처 결정이었습니다. Praos에서는 Cardano 노드가 수동 개입 없이 2,160블록 이상 롤백되지 않습니다. Genesis 논문에 설명된 바와 같이, Eclipse 공격을 받는 노드는 수년 동안만 적대적인 체인의 확장만 선택할 수 있으며, 마침내 정직한 체인을 제공하는 노드에 연결되면 갑자기 원하는 수의 블록을 롤백할 수 있습니다.
실제로 노드가 무제한 롤백 기능을 가질 필요는 없기 때문에 설계자는 대신 리소스 사용량에 대한 많은 범위의 핵심인 롤백 제한에 우선순위를 두었습니다. Genesis에 이를 삭제하면 이전 엔지니어링 작업의 상당 부분에서 호출된 주요 불변성이 제거됩니다. 게다가 동기화 중인 Cardano Genesis 노드가 건전하고 정직한 피어에 액세스할 수 있는 한 Praos 노드처럼 2,160개 이상의 블록을 롤백할 필요가 없습니다.
일식은 잠재적으로 이 문서에 표현된 것보다 Genesis 노드에 더 심각한 위협이 될 수 있지만 직접적으로 해결하지는 않습니다. 이러한 공격은 제네시스 안전 속성을 위협합니다. 왜냐하면 몇 초 이상 지속되는 일식은 제네시스 밀도 비교를 충실하게 구현했음에도 불구하고 동기화 제네시스 노드가 잠재적으로 적대 체인에서 2,161개의 블록을 선택하기에 충분하기 때문입니다. 정직한 체인에 대한 지식이 없으면 Genesis 규칙은 현재 접근 가능한 가장 밀도가 높은 체인을 선택합니다. 일식 상황에서는 반드시 정직한 체인이 아닐 수도 있습니다. 이는 eclipse 노드와 해당 사용자가 단지 지연, 혼란, 잘못된 정보를 받는 등의 내용을 담고 있는 Genesis 논문과 대조됩니다. 이는 관련 위험을 수반하지만 노드가 결국 정직한 동료와 노드를 연결할 수 있기 때문에 안전성이나 활성 속성을 손상시키지 않습니다. 그러므로 회복하십시오.
이론적으로 노드가 절대 뒤쳐지지 않는 Praos 네트워크만 고려하면 일식은 여전히 해로울 수 있습니다. Genesis와의 주요 차이점은 Praos 노드(본질적으로 따라잡음)가 적대적 체인에 커밋될 가능성이 커지기 전에 훨씬 더 긴 일식을 견딜 수 있다는 것입니다. 그러나 동기화 중 추가 취약성을 고려하지 않더라도 Praos 노드에는 일식에 대한 방어가 필요합니다.
한 가지 방어 방법은 일식의 확률과 기간을 충분히 제한하기 위해 피어 선택 논리 내에 원장 피어 개념을 도입하는 것입니다. 동기화하는 동안 Genesis 노드는 원장 피어 구성을 조정하여 일식 가능성을 대폭 줄입니다. 그리고 일식이 없으면 Genesis 노드는 적대적 체인에서 2,161개의 블록을 선택하지 않습니다.
변경된 피어 선택은 다음과 같이 작동합니다. Genesis 노드는 최근 지분 분포를 조사하여 네트워크 유지에 참여한 샘플 피어를 선택하므로 악의적인 노드가 선택될 확률이 크게 줄어듭니다.
대안: 경량 체크포인트
Genesis 논문에서는 건강한 Praos 네트워크 내 최고의 체인이 두 체인이 교차한 직후 고정된 슬롯 창에서 다른 체인보다 더 많은 블록을 갖게 될 것임을 입증했습니다. 유일한 예외는 Praos 네트워크가 건강하지 않은 경우입니다.
심각한 네트워크 중단은 정직한 체인을 복구하기 위해 중단 기간 내에 체인을 다시 작성하기 위해 이해관계자 간의 오프체인 협력이 필요한 재해 복구 계획 실행을 정당화합니다. 그런 일이 발생한 후에는 창세기 규칙이 다시 정직한 체인을 선호하게 됩니다.
그러나 재해 복구 계획은 본질적으로 실행하기 어렵고 비용이 많이 듭니다. 적어도 그 동안에는 간단한 체크포인트 메커니즘을 통해 충분히 큰 협력 하위 집합인 스테이크 풀 운영자가 블록 생산 중단 중 또는 직후에 빠르고 쉽게 네트워크 제어를 유지할 수 있습니다.
논리는 간단하고 프로토콜의 나머지 부분과 일치합니다. 즉, 블록 번호 및 해시 쌍 목록을 지정하는 구성 파일로, 각각 동일한 블록 번호를 가진 다른 블록이 유효하지 않은 것으로 처리됩니다. 해당 체크포인트의 구성 데이터는 주의해서 사용해야 하며 신뢰할 수 있는 소스에서만 획득해야 합니다. 이상적으로는 복구 계획의 최종 실행에서 검사점 목록에 대한 사후 대응 추가가 일시적인 것을 허용하고 요구할 수도 있습니다. 유일한 영구 체크포인트는 Byron 시대의 제네시스 키가 더 이상 Cardano 체인과 관련되지 않도록 보장하는 세트가 될 것입니다.
열의의 한계
원장 피어는 일식을 효과적으로 방지하므로 동기화 노드는 모든 정직한 체인을 서비스하는 건강한 피어가 하나 이상 있다고 가정할 수 있습니다. 따라서 동기화 Genesis 노드가 원장 피어 체인의 교차점을 지나 체인의 2,160개 이상의 블록을 선택하는 것을 단순히 금지함으로써 안전 속성이 직접적으로 보장됩니다. 모든 원장 피어가 동의하는 블록만 선택하며, 여기에는 거의 확실히 정직한 피어가 포함됩니다. 동기화 노드는 지금까지 본 최고의 블록에 적극적으로 커밋해서는 안 되기 때문에 이 제약 조건을 LoE(열심도 제한)라고 합니다. 적대적인 피어는 정직한 피어가 과거 블록을 제공할 수 있는 것보다 훨씬 빠르게 대체 블록을 제공할 수 있습니다.
제네시스 밀도 단절
공격자가 LoE를 남용하여 피해자가 블록 동기화를 중단하도록 하고 동기화 노드의 활성 속성을 위반하는 것은 사소한 일입니다. 그렇게 하는 방법에는 세 가지가 있습니다.
• 공격하는 피어는 더 이상 블록이 없다고 주장합니다.
• 공격하는 피어는 대체 체인을 제공합니다.
• 공격하는 피어는 대체 블록이 있다고 주장하지만 이를 제공하지 않습니다.
창세기 논문의 기본 규칙은 처음 두 가지를 직접적으로 완화합니다. 두 피어가 서로 다른 체인을 서비스하고 체인 중 하나 이상이 교차 후 2,161개 이상의 블록을 갖고 있는 경우 Genesis는 두 체인 교차 후 고정된 슬롯 창에 더 많은 블록이 있는 체인을 선호합니다. (정직한 체인은 항상 비교에서 승리합니다. 체인 중 하나가 단순히 다른 체인의 확장인 경우에도 공유 접두사는 체인 교차를 반영한다는 점을 기억하십시오.) Genesis 노드는 다른 피어와의 연결을 끊음으로써 정직한 체인을 선호합니다. 이 동작을 GDD(Genesis Density Disconnection)라고 합니다. 충분한 GDD 후에 나머지 피어 교차점은 역사적 정직 체인을 따라 더 멀리 떨어져 있을 것입니다.
인내심의 한계
세 번째 공격 벡터는 분석하기 가장 어렵습니다. 피어가 더 많은 블록을 가지고 있다고 주장하므로 GDD가 비활성화됩니다. 즉, 더 많은 블록을 서비스하는 데 더 많은 시간이 허용되면 고정 창의 블록 수가 증가할 것이라고 주장합니다. 정직한 피어는 동기화 노드가 실제로 모든 정직한 블록을 가질 때까지 항상 진심으로 그러한 주장을 합니다. 그러나 공격하는 동료는 악의적인 주장을 할 수도 있습니다. LoP(인내 제한)는 더 많은 블록을 가지고 있다고 주장하는 피어가 실제로 블록을 보내야 하며 즉시 보내도록 보장합니다. 중요한 문제는 정직한 피어라도 몇 시간 동안 완벽한 응답성을 유지할 수 없고 때때로 대기 시간이 급증하는 등의 현상이 발생한다는 것입니다. 이러한 이유로 LoP는 각 피어에 대해 누출 버킷으로 구현되며, 여기서 누출은 처리 속도입니다. 피어가 블록을 요청하고 넉넉한 최소 속도보다 느리게 서비스하는 동안 블록을 처리하지만 각 정직한 피어의 버킷 용량은 일반적으로 건강한 원장 피어에서 예상되는 폭발적인 대기 시간을 흡수할 만큼 충분히 높습니다.
창세기 상태 머신
Genesis 노드는 두 가지 중요한 이유로 따라잡았다고 판단되면 LoE, GDD 및 LoP를 비활성화합니다. 첫째, Praos 네트워크의 따라잡힌 노드는 기본적으로 자신이 선택한 슬롯에서 가능한 최고의 블록을 발행해야 합니다. 예를 들어, 그러한 노드가 여전히 Genesis 규칙을 사용하고 있는 경우 강력한 공격자는 LoE를 남용하여 피해자가 방금 생성한 블록을 선택하는 것을 일시적으로 금지하여 해당 블록이 네트워크에 전파되는 것을 방지할 수 있습니다. 이러한 벡터의 시스템 전체 결과를 제한하는 것은 어렵기 때문에 Genesis 노드는 동기화되지 않을 때마다 Praos 노드처럼 정확하게 작동해야 합니다.
둘째, 잡힌 노드는 Eclipse에 취약하지 않기 때문에 동기화 노드만큼 많은 피어가 필요하지 않습니다. 따라서 부풀려진 원장 피어 수를 유지하는 모든 노드로 인해 네트워크에 상당한 추가 로드가 발생하는 것은 불필요하고 바람직하지 않습니다. Genesis 상태 머신은 자신을 따라잡았는지 여부를 고려하는 노드의 전환을 관리합니다.
• 따라잡으면 노드는 LoE, GDD 및 LoP를 비활성화합니다. • 노드는 다음 조건이 충족되면 따라잡았다고 결론을 내립니다.
- 원장 피어가 충분합니다.
- 모든 피어는 추가 블록이 없다고 주장합니다(잘 조정된 LoP는 곧 발생해야 함).
- 노드는 이미 피어 체인 중 가장 좋은 것을 선택했습니다.
- 이는 공격하는 피어가 이러한 임계값을 트리거하여 피해자가 방어를 조기에 낮추게 만들 수 있으므로 로컬 선택의 나이 등을 신뢰하는 것보다 더 강력합니다.
체인 끝이 너무 오래된 경우(예: 20분 정도) 노드는 동기화로 대체됩니다. 특히, 이는 머신이 충분히 오랫동안 절전 모드인 경우(예: 사용자가 노트북 덮개를 잠시 닫은 경우) 노드 운영 체제 프로세스의 수명 동안 발생합니다.
다음 단계
위의 디자인은 지난 1년 정도에 걸쳐 안정화되었습니다. 아직은 조금씩 발전하고 있지만 큰 변화는 없습니다. IOG는 이를 구현하고 테스트하기 위해 지난 몇 달 동안 Tweag와 협력해 왔습니다.
첫 번째 Genesis 지원 구현은 2024년 3분기에 출시될 예정입니다. 이 단계에서 가장 알려지지 않은 것은 일식을 방지하는 데 필요한 피어 수 증가를 보상하는 데 필요한 최적화 수준입니다.
그때까지는 임박한 부트스트랩 피어 디자인이 Genesis를 향한 증분 역할을 합니다. 부트스트랩 상태 머신은 Genesis 상태 머신의 간단한 변형입니다. 동기화하는 동안 노드는 모든 단일 피어를 신뢰할 수 있는 부트스트랩 피어하고만 통신하므로 LoE, GDD 및 LoP는 필요하지 않습니다. 대조적으로, Genesis는 일식화되지 않는 한(즉, 한 피어가 정직한 한) 동기화 노드가 신뢰할 수 없는 피어를 안전하게 포함할 수 있도록 허용하여 부트스트랩 피어를 폐기할 수 있게 함으로써 노드 동기화 및 이행을 위한 인프라를 분산화합니다. 우로보로스 제네시스의 약속.
Neil Burgess가 이 작품에 기여했습니다.