본문으로 이동
Financial Context Wiki

약한 주관성: 신뢰 체크포인트와 안전한 PoS 동기화

약한 주관성은 증명 지분 노드가 충분히 최근의 신뢰할 수 있는 체크포인트를 얻은 후에 앞으로의 상태를 객관적으로 검증할 수 있도록 합니다. 오래된 서명이 장기 이력을 어떻게 지원할 수 있는지, 체크포인트의 최신성과 소스 독립성이 어떻게 검증되는지, 그리고 체크포인트 동기화가 무엇을 증명하지 않는지 알아보세요.

업데이트

교육 목적으로만 사용됩니다; 투자 조언이 아닙니다. 투자는 손실을 초래할 수 있습니다.

직접적인 답변

약한 주관성은 노드가 신뢰할 수 있거나 사회적으로 검증된 채널을 통해 얻은 충분히 최근의 체크포인트에서 시작한 후 프로토콜 규칙에 따라 블록, 상태 전환, 투표 및 포크 선택을 검증할 수 있는 지분 증명 보안 모델입니다. ‘약한’ 주관적 입력은 시작점입니다. 이는 임의의 이후 블록을 선택할 수 있는 허가는 아닙니다. 일단 고정되면 노드는 체크포인트를 포함하지 않는 기록을 거부하고 정상적으로 앞으로 검증해야 합니다.

문제는 역사적 모호성입니다. 이미 퇴출되어 더 이상 경제적으로 처벌받을 수 없는 검증자로부터 키를 얻은 적대자는 유효해 보이는 서명으로 긴 대체 역사를 구성할 수 있습니다. 검증자가 처벌 가능한 동안 정통 체인을 관찰한 노드는 유용한 기억을 유지합니다. 완전히 새로운 노드, 데이터베이스가 삭제된 노드, 또는 프로토콜의 안전한 최신성 창을 넘어 오프라인 상태였던 노드는 제네시스 데이터와 피어 메시지만으로 사회적으로 정통인 역사를 식별하지 못할 수 있습니다.

Ethereum에서 약한 주관성 체크포인트는 클라이언트가 절대적인 기준으로 취급하는 epoch 및 block_root입니다. 성공적인 동기화는 표준 경로가 해당 시대(epoch)에 그 루트를 포함하고 있음을 증명해야 합니다. 불일치는 포크 선택 투표가 아니라 치명적인 실패입니다. 약한 주관성 체크포인트는 일반적인 최종화된 체크포인트와도 다릅니다. 노드가 이전 기억 없이 두 개의 상충되는 최종화된 기록을 처음 접할 경우, 최종성 규칙만으로는 어느 사회적 기록이 표준인지 식별할 수 없습니다.

Ethereum의 메커니즘을 일반화하지 마십시오. CometBFT 라이트 클라이언트는 구성된 trusting_period 내의 신뢰할 수 있는 헤더에서 시작하여 검증자 세트의 겹침, 서명, 시간 제한, 증인을 사용하여 신뢰를 이전합니다. 대신 Ouroboros Genesis 연구는 명시된 보안 모델 하에서 신뢰할 수 있는 제네시스 블록에서 부트스트랩하도록 설계된 체인 선택 규칙을 정의합니다. 따라서 “지분 증명”은 하나의 체크포인트 형식, 하나의 기간 공식, 하나의 부트스트랩 절차를 의미하지 않습니다.

약한 주관성도 동기화 단축키와 분리하십시오. 체크포인트 동기화는 시작 시간과 역사적 상태 처리를 줄일 수 있지만, 속도가 보안 정의는 아닙니다. 신뢰할 수 있는 루트는 이를 제공한 웹사이트를 인증하거나, 클라이언트가 명시한 가정 외부에서 실행 페이로드를 검증하거나, 가지치기된 히스토리를 복원하거나, 데이터 가용성을 증명하거나, 가려진 피어 집합을 정직하게 만들지 않습니다.

약한 주관성 부트스트랩을 검증하는 방법

1. 정확한 프로토콜과 보안 모델을 식별하세요

network, chain ID, 제네시스 루트 또는 해시, 활성 포크 또는 런타임, 클라이언트 버전, 체크포인트 유형, 합의 사양을 기록하십시오. 프로토콜이 최근 소셜 체크포인트, 신뢰할 수 있는 헤더와 검증자 세트, 최종성 증명 체인, 아니면 다른 모델에서의 제네시스만 요구하는지 확인하십시오. Ethereum의 compute_weak_subjectivity_period나 CometBFT의 trusting_period를 규칙 없이 다른 체인에 이식하지 마십시오.

2. 기존 신뢰가 여전히 유효한지 결정하세요

노드가 마지막으로 로컬에서 검증한 최종화 체크포인트, 해당 에포크 또는 높이와 시각, 현재 시간 소스, 데이터베이스 복원 여부를 기록하십시오. 기억에 의존한 달력 추정이 아니라 프로토콜의 현재 규칙과 상태로 경과 시간을 계산하십시오. Ethereum의 경우 Phase 0 가이드는 current_epoch <= ws_state_epoch + ws_period을 검사하며, Electra는 전체 활성 잔액과 잔액 churn에 따라 기간 계산을 변경합니다. 신뢰가 만료됐다면 신뢰할 수 없는 피어에 더 의존하지 말고 대역 외에서 새 앵커를 확보하십시오.

3. 체크포인트를 획득하고 확인하십시오

독립적으로 운용되고 독립적으로 제공되는 채널에서 동일한 체크포인트를 확보하십시오. 예를 들어, 직접 운영하는 노드, 다른 운영자, 여러 클라이언트 팀, 그리고 별도의 인프라를 가진 탐색자 등이 있습니다. 각 소스, 획득 시간, 네트워크, epoch, 전체 루트를 기록하십시오. 하나의 업스트림을 복제한 다섯 개의 URL은 하나의 장애 도메인입니다. 단순한 응답 다수 결정은 소스 독립성, 인증된 전송, 또는 사회적 사고 검토를 대체할 수 없습니다.

4. 모든 체크포인트 필드를 바인딩하십시오

체크포인트 값 이전에 네트워크와 제네시스 아이덴티티를 확인하십시오. 전체 루트를 잘라내지 않고 보존하며, 필요한 경우 정확한 에포크 또는 높이, 상태, 포크 버전 및 획득 시간을 함께 기록하십시오. Ethereum의 가이드는 block_root:epoch_number를 사용하며; CometBFT 초기화는 신뢰할 수 있는 헤더와 검증자 세트 및 신뢰 매개변수도 바인딩합니다. 잘못된 체인이나 높이에 첨부된 올바른 루트는 유효한 앵커가 아닙니다.

5. 실패 시 폐쇄 동기화 경로를 적용

클라이언트의 문서화된 인터페이스를 통해 체크포인트를 구성하고 시작 로그를 보관하십시오. 동기화 중에는 체크포인트 에포크에서 정규 경로가 제공된 block_root와 같아야 합니다. Ethereum 가이드는 어설션 실패 시 설명적인 치명적 오류와 프로세스 종료를 요구합니다. 체크포인트를 조용히 폐기하거나, 피어 과반수로 되돌리거나, 최신 피어 응답으로 덮어쓰거나, 합의 뷰가 불확실한 상태에서 검증자 서명을 유지하지 마십시오.

6. 검증된 레이어와 검증되지 않은 레이어를 분리하세요

합의 체크포인트 신뢰, 비콘 또는 합의 블록 검증, 실행 페이로드 상태, 실행 상태 동기화, 과거 데이터 채우기, 애플리케이션 증명을 별도로 추적합니다. Ethereum 낙관적 동기화는 체크포인트 앵커의 ExecutionPayload을 실행 엔진에 먼저 전달하지 않고 VALID으로 간주할 수 있지만, 낙관적 노드는 검증자 역할을 수행해서는 안 됩니다. Lighthouse 체크포인트 채우기는 과거 해시 체인 무결성과 제안자 서명을 확인하지만 기본적으로 모든 과거 상태를 재구성하지는 않습니다.

7. 복구를 새로 고치고, 모니터링하며, 연습하세요

적용 기간 안쪽에 충분한 여유를 두고 알림과 갱신 일정을 설정하십시오. 최종화, 시계 상태, 클라이언트 불일치, execution_optimistic 상태, 피어 다양성, 체크포인트 경과 시간과 백필 공백을 모니터링하십시오. 데이터베이스 삭제, 체크포인트 만료, 출처 충돌, 제공자 장애에서 복구하는 절차를 연습하십시오. 앵커와 결정의 서명 기록은 보관하되, 오래된 체크포인트를 영구적으로 최신 신뢰점처럼 취급하지 마십시오.

실제 예제

남은 여유 공간이 있는 Ethereum 체크포인트

적용 가능한 엘렉트라 참조 계산이 ws_period = 3,532 epochs를 주는 설명적인 상태를 사용하십시오. current_epoch = 420,000와 독립적으로 확인된 체크포인트가 checkpoint_epoch = 418,200라고 가정합니다:

checkpoint_age = 420,000 - 418,200 = 1,800 epochs.

가이드의 최신성 테스트는 420,000 <= 418,200 + 3,532이므로 체크포인트는 기간 내에 있습니다. 32 slots * 12 seconds = 6.4 minutes per epoch에서 그 나이는 1,800 * 6.4 / 1,440 = 8 days입니다. 남은 여유는 3,532 - 1,800 = 1,732 epochs이거나 1,732 * 6.4 / 1,440 = 7.6978 days입니다. 이는 라이브 네트워크 약속이 아닌 참조 표 기간을 사용하며, 클라이언트는 실제 포크와 상태에서 계산해야 합니다.

만료된 체크포인트는 더 많은 피어에 의해 복구되지 않습니다

current_epoch = 500,000, checkpoint_epoch = 496,000 및 적용 가능한 ws_period = 3,532 epochs를 가정해 보십시오:

checkpoint_age = 500,000 - 496,000 = 4,000 epochs.

500,000 > 496,000 + 3,532 때문에 체크포인트가 4,000 - 3,532 = 468 epochs만큼 오래되었습니다. 에포크당 6.4분이라면, 이는 한계를 468 * 6.4 / 60 = 49.92 hours만큼 초과한 것입니다. 100 피어에서 동일한 만료된 루트를 다운로드한다고 해서 가정이 복원되지는 않습니다; 운영자는 신뢰할 수 있고 확인된 채널에서 충분히 최근의 체크포인트가 필요합니다.

출처 수 대 출처 독립성

운영자는 다섯 가지 응답을 받습니다. 그중 네 개는 epoch = 600,000를 보고하고, 동일한 전체 루트인 root_A를 표시하며, 하나는 다른 전체 루트 root_B를 보고합니다. 조사 결과, 일치하는 세 개의 웹사이트 모두 동일하게 호스팅된 노드를 프록시하고 있으며, 네 번째는 운영자 자신의 노드입니다. 겉으로 보이는 합의는 4 / 5 = 80%이지만, 이는 독립적인 계통이 두 개만 존재함을 나타냅니다. 운영 정책에서 세 개의 독립적인 관리 및 데이터 경로를 요구하기 때문에, 체크포인트는 아직 승인되지 않았습니다. 세 번째 독립 운영자가 root_A를 확인하고, 반대 의견이 있는 서비스는 격리되며, 출처 기록이 이 결정을 설명합니다.

CometBFT 스타일 신뢰 기간 예산

unbonding_period = 21 days로 구성된 체인과 운영자가 선택한 trusting_period = 14 days를 고려해 보십시오. 이는 신뢰 기간이 언바운딩 기간보다 짧아야 한다는 요구 사항과 일치합니다. 11 days로 설정된 신뢰된 헤더는 14 - 11 = 3 days의 여유 공간을 가지고 있습니다. 일일 새로 고침 목표는 운영 여유를 남깁니다. 클라이언트가 16 days 후에 돌아오면, 헤더는 신뢰 기간을 이틀 초과했으며 새로운 신뢰 초기화를 통해 교체해야 합니다. Ethereum 에포크 공식은 이 CometBFT 경우를 결정하지 않습니다.

위험과 검토 실패

  • 잘못된 네트워크: 테스트넷, 포크, 복제 체인 또는 다른 제네시스의 유효한 루트가 잘못된 기록을 고정할 수 있습니다.
  • 오래된 체크포인트: 적용 기간을 벗어난 루트는 필요한 최신 검증자 집합 가정을 충족하지 못합니다.
  • 잘못된 기간 공식: 포크 업그레이드, 검증자 잔액, 교체 규칙, 언본딩 및 안전 매개변수에 따라 한계가 달라질 수 있습니다.
  • 출처 단일 장애점: 여러 엔드포인트가 같은 노드, 클라우드 계정, 데이터베이스, DNS 제공자 또는 운영자를 공유할 수 있습니다.
  • 배포 경로 침해: 악의적인 릴리스, 웹사이트, 패키지, DNS 응답 또는 지원 메시지가 체크포인트를 바꿀 수 있습니다.
  • 축약 비교: 접두사, 스크린샷 또는 형식화된 식별자만 비교하면 전체 루트의 차이가 가려질 수 있습니다.
  • 필드 불일치: 올바른 루트도 에포크, 높이, 상태, 포크 또는 체인이 다르면 같은 체크포인트가 아닙니다.
  • 피어 다수로 대체: 이클립스 공격을 받은 노드에는 많은 적대적 피어가 보일 수 있으며, 피어 수는 신뢰 앵커보다 우선하지 않습니다.
  • 조용한 대체: 클라이언트나 래퍼가 거부된 체크포인트를 무시하면 의도한 실패 폐쇄 제어가 무력화됩니다.
  • 상충하는 최종 기록: 새 노드는 두 브랜치가 모두 최종화됐다는 표시만으로 합의 실패를 해결할 수 없습니다.
  • 시계 오류: 부정확한 로컬 시간은 슬롯, 에포크, 경과 시간, 신뢰 기간 및 미래 헤더 검사를 망가뜨릴 수 있습니다.
  • 낙관 상태 혼동: 가져온 합의 블록에도 완전히 검증되지 않은 실행 페이로드가 있을 수 있습니다.
  • 조기 검증자 업무: 낙관 상태, 미동기화 상태 또는 불확실한 앵커에서 서명하면 잘못된 투표나 슬래싱이 발생할 수 있습니다.
  • 기록 완전성 혼동: 라이브 헤드가 유효해도 체크포인트 동기화와 백필에는 과거 상태가 빠질 수 있습니다.
  • 유효하지 않은 백필 서명: 해시로 연결된 과거 블록에도 프로토콜이 요구하는 제안자 서명 검사가 필요합니다.
  • 실행 또는 애플리케이션 증명 부족: 합의 앵커링은 임의의 RPC 값, 계약 주장 또는 오프체인 인덱스를 증명하지 않습니다.
  • 데이터 가용성 공백: 상태 루트를 안다고 모든 바디, Blob, 증인 또는 과거 기록에 접근할 수 있는 것은 아닙니다.
  • 만료된 복구 계획: 장애 중 만료를 발견하면 독립적인 체크포인트 출처를 구하지 못할 수 있습니다.
  • 사회적 조정 집중: 거버넌스, 클라이언트 팀, 익스플로러, 거래소 및 운영자가 이해관계나 의존성을 공유할 수 있습니다.
  • 잘못된 일반화: 다른 PoS 설계는 다른 가정, 증명 체인, 신뢰 기간 또는 제네시스 부트스트랩 보장을 사용할 수 있습니다.

일반적인 오해

약한 주관성이란 시작 후 프로토콜 규칙이 주관적임을 의미합니까?

아니요. 노드는 사회적 또는 신뢰할 수 있는 채널을 통해 특정 최근 앵커를 수락한 후, 결정론적 검증과 포크 선택 규칙을 앞으로 적용합니다. 앵커와 충돌하는 블록은 거부됩니다.

최종화된 체크포인트는 자동으로 안전한 부트스트랩 체크포인트인가요?

아니요. 그것은 의도된 네트워크와 정통 사회적 기록에 속해야 하며, 적용 가능한 규칙에 따라 충분히 최근이어야 하고, 필요한 필드를 포함해야 하며, 신뢰할 수 있는 증명된 경로를 통해 전달되어야 합니다. 공격자가 제공한 기록에서 처음으로 관찰된 최종성은 출처를 확립하지 않습니다.

제네시스에서 동기화를 하면 장거리 공격 문제를 제거할 수 있나요?

최근 약한 주체성 체크포인트를 요구하는 보안 모델을 가진 프로토콜에는 해당되지 않습니다. 제네시스에서 내부적으로 유효한 서명을 재생한다고 해서 새로운 노드가 두 개의 오래된 최종 확정된 기록 중 커뮤니티가 실제로 어느 것을 따랐는지 알 수 있는 것은 아닙니다. 다른 프로토콜은 다른 가정 하에서 다른 제네시스-부트스트랩 보장을 제공할 수 있습니다.

체크포인트 동기화가 모든 과거 실행과 상태를 검증합니까?

아니요. 클라이언트의 동작은 계층적이며 구현에 따라 다릅니다. 노드는 앵커를 신뢰하거나 낙관적으로 가져올 수 있으며, 현재 실행 상태를 별도로 동기화하고, 모든 과거 상태를 재구성하지 않고 블록 링크와 제안자 서명만 채워 넣을 수 있습니다.

하드코딩된 체크포인트를 영원히 신뢰할 수 있을까?

아니요. 체크포인트는 네트워크와 기간에 속합니다. 그것은 감사 기록이나 역사적 제약으로서 유용하게 남을 수 있지만, 최근 신뢰 가정이 만료된 노드는 적절히 최근의 앵커나 해당 프로토콜이 지정한 복구 과정을 필요로 합니다.

관련 주제

출처

탐색

위키 검색...