프리즘의 안전 헤드에 대한 빠른 확인 규칙(1부)
이 문서는 Prysm에서 빠른 확인 알고리즘을 구현한 과정을 광범위한 탐구의 1부로 집중 조명합니다. 1부라고 부르는 이유는 아직 초기 단계이기 때문입니다. 백서 와 안전 증명이 있지만, 둘 다 완전히 검증되지 않았고, 저희가 아는 한 다른 클라이언트도 아직 이를 구현하지 않았습니다. 모든 구현과 마찬가지로 버그와 오류가 존재합니다. 이 게시물에서는 Prysm에서의 구현 과정을 살펴보고 메인넷에서 실행하면서 관찰한 몇 가지 흥미로운 점을 공유합니다.
참고문헌:
- Aditya Asgaonkar가 작성한 Ethereum PoS 확인 규칙 (Francesco D'Amato, Roberto Saltini, Luca Zanolini, Chenyi Zhang의 기여 포함)
- Aditya Asgaonkar, Francesco D'Amato, Roberto Saltini, Luca Zanolini, Chenyi Zhang의 Ethereum 합의 프로토콜에 대한 빠른 확인 규칙
- Aditya Asgaonkar와 Terence가 작성한 Prysm 빠른 확인 구현 코드
- Terence의 Prysm Forkchoice 구현 설명
배경
세이프 헤드란?
이더리움에서 안전 블록(safe head)은 단기적인 재편(reorg)으로부터 안전하다고 간주되는 가장 최근 블록 의미하며, 포크(Fork) 로 인해 다른 블록 으로 대체될 가능성이 낮음을 의미합니다. 블록 정당화된 체크포인트에 뿌리를 두고 충분한 검증자 증명을 받으면 결국 안전 블록이 됩니다. 전통적으로 클라이언트는 가장 최근에 정당화된 체크포인트(LMD GHOST 포크(Fork) 선택 알고리즘의 시작점이기도 함)를 안전 블록( safe block)이라고 부르거나, 실현되지 않은 가장 최근에 정당화된 체크포인트(온체인 실현 여부와 관계없이)를 안전 블록(safe block)이라고 부릅니다. 안전 블록 체인 사용자가 완결성 )을 기다리는 데 시간이 오래 걸립니다.
안전한 머리를 얻는 방법은?
실행 계층 클라이언트(예: Geth, Nethermind 이더리움 클래식(ETC))는 head , safe head 및 finalized 실행 블록을 쿼리하기 위한 전용 RPC 엔드포인트를 제공합니다. 블록체인 라이브 데이터 사용자는 이 정보를 기반으로 어떤 작업을 수행할지 결정할 수 있습니다.
- 완성된 헤드 :
eth_getBlockByHash("finalized", ...) - 안전한 헤드 :
eth_getBlockByHash("safe", ...) - 헤드 :
eth_getBlockByHash("latest", ...)
안전한 머리가 EL에게 어떻게 전달되나요?
안전한 헤드는 엔진 API를 통해 합의 계층에서 실행 계층으로 전달되며, 특히 헤드 업데이트 시 engine_forkchoiceUpdated 메서드를 통해 전달됩니다. CL 클라이언트마다 안전한 블록의 정의에 대한 해석이 다를 수 있습니다. 1) 최신 정당화된 체크포인트를 사용하는 클라이언트가 있고, 2) 최신 미실현 정당화된 체크포인트를 사용하는 클라이언트(기본적으로 Prysm 등)도 있습니다. 이 글에서는 3) 빠른 확인 블록 안전한 블록 으로 사용하는 대안을 살펴보겠습니다.
{ "jsonrpc" : "2.0" , "method" : "engine_forkchoiceUpdatedV2" , "params" : [ { "headBlockHash" : "0x..." , "safeBlockHash" : "0x..." , ← this is the safe head "finalizedBlockHash" : "0x..." } , { "timestamp" : "0x..." , "random" : "0x..." , "suggestedFeeRecipient" : "0x..." } ] , "id" : 1 }빠른 확인 블록 무엇입니까?
빠른 확인 블록 동기식 네트워크(증명 도착까지 8초 미만 소요)와 제한된 적대적 힘을 가정할 때, 최종 확정되기 전에도 정식 체인에 남아 있을 가능성이 매우 높은 블록입니다. 빠른 확인 규칙은 사용자와 애플리케이션이 제안 후 몇 초에서 1분 이내에 블록 확인된 것으로 처리할 수 있는 휴리스틱을 제공합니다. 이는 블록 이 충분한 관측 가능한 검증자 투표를 받았는지, 특정 안전 임계값을 충족하는지 확인함으로써 이루어집니다. 슬래싱 싱 조건을 통해 비가역성을 보장하는 완결성 과 달리, 빠른 확인은 네트워크 조건과 검증자 행동에 따라 더 빠르지만 보장성이 약합니다.
Prysm 구현
이 섹션에서는 실험용 PR 에서 Prysm의 안전 헤드 구현을 간략하게 설명합니다. 아직 개발 중이며 변경될 수 있으므로 테스트 관찰 섹션으로 바로 이동하셔도 됩니다. 안전 블록 으로 빠른 확인을 활성화하려면 두 가지 플래그를 설정해야 합니다.
- 안전 블록 모드를 선택하려면:
-safe-block=fast-confirmation(기본값:unrealized-justified) - 비잔틴 스레스홀드(Threshold) 지정하려면:
-fast-confirmation-byzantine-threshold=33(기본값:33)- 여기서 비잔틴은 증명을 보류하거나 충돌하는 서브트리에 투표하는 이더리움 클래식(ETC) 의 악의적인 행위를 말합니다.
빠른 확인 타임라인
슬롯 n 의 0초에, 운이 좋은 경우, Prysm 비콘 노드는 정기적인 간격으로 UpdateHead Upd a t e H e a d 를 호출 합니다. n-1 의 4초부터 적시에 블록 슬롯 n-1 에 대한 증명을 수집, 검증 및 계산하기 시작합니다. 모든 것이 예상대로 진행된다면, n-1 의 블록 8초 이내에 빠르게 확인될 수 있습니다(비잔틴 스레스홀드(Threshold) 이 30% 미만이라고 가정할 때, 이 계산의 이유는 나중에 설명하겠습니다).
수정된 forkchoice 및 node 객체
Forkchoice F o r k choice 객체 는 이제 새로운 필드 인 safe head root를 캐시합니다.
노드 노드 는 시작 슬롯 에서 현재 슬롯까지 받을 수 있는 최대 지지를 계산하는 새로운 방법을 추가합니다. 이는 위원회 가중치와 슬롯/에포크 구조를 기반으로 합니다.
- 범위 가 단일 에포크 내에 있는 경우 총 지원 은 다음 과 같이 반환 됩니다 . CommitteeWeight × SlotCount 위원회 가중치 × 슬롯 개수 .
- 범위가 전체 에포크에 걸쳐 있는 경우 1 에포크 의 가중치 가 반환 됩니다 . CommitteeWeight * 32 Commit Weight ∗ 32 .
- 완전히 넘지 않고 새로운 시대로 넘어가는 경우, 각 시대 세그먼트의 슬롯 수에 따라 비례적으로 지원을 계산합니다.
최상의 자손을 업데이트할 때 함수는 현재 슬롯의 초 수와 현재 체인의 위원회 가중치를 모두 받습니다.
- 이전 슬롯 의 최상의 자식 이 빠르게 확인 되면 BestConfirmedDescendant Best Confirmed Descendant 를 가장 깊은 확인 자식 으로 재귀 적 으로 설정 합니다 .
- 확인 되지 않으면 최상의 자식 을 직접 할당 하거나 BestConfirmedDescendant Best Confirmed Descendant 를 nilnil 로 설정 합니다 .
이를 통해 체인을 통해 확인 상태가 빠르게 역방향으로 전달됩니다.
마지막으로, 노드가 확인되었는지 확인하기 위해 제안자 부스트가 적용되지 않은 노드의 가중치를 안전 스레스홀드(Threshold) 과 비교합니다. 로직은 다음을 확인합니다.
- 노드의 슬롯은 현재 슬롯보다 이전이어야 합니다.
- 가능한 최대 지원 및 제안자 부스트 가중치를 계산합니다.
- 확인 조건은 다음과 같습니다.
voteOnlyWeight > ( maxPossibleSupport + proposalrBoostWeight ) / 2 + maxPossibleSupport / 3 투표 전용 가중치 > ( 최대 가능 지원 + 제안자 부스트 가중치 ) / 2 + 최대 가능 지원 / 3
어디:
제안자 부스트 가중치 = ( 위원회 가중치 * 제안자 점수 부스트 ) / 100 제안자 부스트 가중치 = ( 위원회 가중치 * 제안자 점수 부스트 ) / 100
관찰 #1
(아래 모든 데이터는 2025년 4월 13일 ~ 2025년 4월 14일 사이에 수집되었습니다.)
바람직한 경우: 슬롯 n 에서 제시간에 제안된 유효한 블록 의 경우, 슬롯 n+1 시작될 때까지 해당 블록 일반적으로 집계된 증명 서브넷을 구독하는 것만으로 검증자 지원의 약 97%를 받습니다.
이 차트에서 슬롯 n 의 시작을 가정하면, node0 슬롯 n-1 에서 블록 되고, node1 슬롯 n-2: 에서 블록 됩니다.
늦은 블록 경우: 슬롯 n 의 블록 늦게 릴리스되면 n+1 의 시작 시점까지 충분한 지지를 얻지 못합니다. 이 경우, 후속 블록 늦은 블록 재구성한다고 가정할 때 빠른 확인에는 일반적으로 3개 이상의 슬롯이 필요합니다.
관찰 #2
예상대로 비콘 슬롯 재구성은 안전 블록 재구성보다 더 자주 발생하며, 지난 12시간 동안 비콘 재구성은 8건, 안전 블록 재구성은 0건이 관찰되었습니다.
관찰 #3
예상대로, 빠르게 확인된 (안전한) 블록은 실현되지 않은 정당화된 (안전한) 블록보다 더 자주 발생하며, 이는 결국 확정된 블록보다 더 자주 발생합니다. 이는 확인 속도와 안전성 보장의 강도 간의 상충 관계를 반영합니다. 빠른 확인은 더 빠른 보장을 제공하는 반면, 보장 강도는 약하고, 완결성 가장 강력한 보장을 제공하지만 지연 시간이 더 깁니다.
이는 시간별 보기로, 녹색은 정당화된 에포크, 노란색은 실현되지 않은 정당화된 에포크, 파란색은 빠르게 확인된 에포크, 주황색은 최신 에포크를 나타냅니다. 표시된 바와 같이, 빠르게 확인된 에포크는 최신 에포크를 밀접하게 추적하는 반면, 정당화된 에포크와 실현되지 않은 정당화된 에포크는 뒤처지는 경향이 있습니다.
30분짜리 영상입니다.
관찰 #4
최신 헤드 슬롯과 안전 슬롯의 차이는 일반적으로 시간당 보기에서 평균 2개 슬롯이고 5분 창에 걸쳐 2~4개 슬롯입니다.
관찰 #5
33%의 비잔틴 스레스홀드(Threshold) 사용하면 단일 슬롯 내에서 블록 확인하는 것이 불가능 해집니다. 이는 더 엄격한 확인 조건 때문입니다.
vote > (max_support + pb_score) / 2 + max_support * 0.33직관적으로 이는 블록 다음이 필요하다는 것을 의미합니다.
- 50% (LMD GHOST 스레스홀드(Threshold))
- 20% (제안자 부스트의 절반)
- 33% (비잔틴 스레스홀드(Threshold))
총 103% 로, 투표 가중치의 최대치인 100%를 초과합니다.
여러 슬롯에 걸쳐 스레스홀드(Threshold) 일반화하려면 다음과 같이 모델링합니다.
threshold = ((n * 0.5 ) + 0.2 + (n * 0.33 )) / n 여기서 n 블록 제안된 이후 슬롯의 개수입니다. 이 공식은 다음을 나타냅니다.
-
n * 0.5: LMD 투표 요구 사항 -
n * 0.33: 비잔틴 동작을 위한 안전 버퍼 -
0.2: 제안자 부스트 기여도 고정
n 증가함에 따라 제안자 부스트의 영향력은 감소하고 스레스홀드(Threshold) 0.83 으로 수렴합니다. 이는 두 슬롯 내에서 블록 빠르게 확인하려면 전체 위원회 가중치의 최소 93%를 받아야 함을 의미합니다.
| 제안 이후 슬롯(n) | LMD 투표(n * 0.5) | 제안자 증가 (/2) | 비잔틴 스레스홀드(Threshold) (n * 0.33) | 총 | 정규화된 스레스홀드(Threshold) (전체/n) |
|---|---|---|---|---|---|
| 1 | 0.50 | 0.20 | 0.33 | 1.03 | 1.03 |
| 2 | 1.00 | 0.20 | 0.66 | 1.86 | 0.93 |
| 3 | 1.50 | 0.20 | 0.99 | 2.69 | 0.89 |
| 4 | 2.00 | 0.20 | 1.32 | 3.52 | 0.88 |
| 5 | 2.50 | 0.20 | 1.65 | 4.35 | 0.87 |
이 그래프에서 예상대로 상단 그래프는 n-1 블록 보여줍니다. 노란색은 빠른 확인 스레스홀드(Threshold) 이며, 녹색은 제안자 부스트가 적용되지 않은 노드의 가중치입니다. 해당 블록은 스레스홀드(Threshold) 아래에 있으며 항상 2~4% 숏 확인될 수 없습니다. 하단 그래프에서는 블록 이 n-2 에 속하며 가중치가 스레스홀드(Threshold) 보다 1~2% 높아 확인될 수 있습니다.
관찰 #6
비잔틴 스레스홀드(Threshold) 이 25%이면 한 슬롯도 안 되는 시간, 즉 약 8초 안에 블록 확인할 수 있습니다. 헤드 슬롯에서 안전 슬롯을 뺀 차트와 노드 가중치 0과 안전 스레스홀드(Threshold) 을 비교한 차트를 다시 살펴보겠습니다.
후속 항목
안전 블록에 대한 재구성은 절대 용납될 수 없습니다. 예를 들어, 거래소가 출금 처리를 위해 안전 블록에 의존하는 경우, 재구성은 이중 지불을 초래할 수 있습니다. 저희 실험에서 안전 블록 의 재구성은 체인 헤드와의 초기 동기화 중에만 관찰되었습니다. 이는 구현상의 문제인 것으로 보입니다. 한 가지 가능한 해결책은 블록 현재 슬롯 타임스탬프(h/t potuz)가 있는 경우에만 빠른 확인 알고리즘을 적용하는 것입니다. 그렇지 않은 경우, 안전을 위해 실현되지 않은 정당화 알고리즘을 사용하는 것으로 대체하는 것입니다.
- 이는 오늘 Prysm의 PR에서 이미 진행 중입니다.
논문에 설명된 빠른 확인 안전 증명은 더 많은 검토를 통해 개선될 것입니다. 증명에 대한 검증 및 검토가 많을수록 더 좋습니다(1번 항목 참조). 안전 블록의 재구성은 실제 사용 방식에 따라 위험할 수 있습니다.
질문이나 의견이 있으시면 언제든지 문의해 주세요. 저희는 이 구현을 프로덕션 환경에 바로 적용하고, 장기 테스트 모드로 실행하며, 업데이트된 결과를 담은 2부 보고서를 발표하기 위해 계속 노력할 것입니다.
