LUCID: 분산 페이로드 전파 기능을 갖춘 암호화된 멤풀

이 기사는 기계로 번역되었습니다

원문 표시

Julian Ma , Benedikt Wagner , Justin Florentine 님께서 피드백과 검토를 해주셔서 감사합니다. 또한 1월 초 베를린에서 디자인의 특정 측면에 대해 논의했던 세션에 참여해주신 Julian , Thomas , Justin , Vitalik , Caspar , Marios , Ansgar , Francesco 님께도 감사드립니다.

1. 개요

이 글에서는 포함자와 제안자 간의 간극을 메우면서 ePBS , BAL , 감사 가능한 빌더 입찰( ABB )과 같은 기존 이더리움 메커니즘을 준수하는 암호화된 멤풀 설계인 LUCID를 소개합니다. 이 설계는 범용적이며, 예를 들어 발신자에 의한 신뢰할 수 없는 자체 복호화, 신뢰할 수 있는 당사자에 의한 복호화 또는 임계값 설계에 사용할 수 있습니다. LUCID는 주요 특징을 나타내는 약어입니다.

IL – 이 설계는 FOCIL처럼 포크 선택에 의해 강제되는 포함 목록(IL)에 기반하지만, 포함자에게 보다 공평한 포함 권한과 MEV 보호를 위한 암호화 기능을 부여하도록 잠정적으로 수정되었습니다. 따라서 포함자는 제안자와 유사한 역할을 수행합니다. IL은 검열 저항성을 향상시키고, 분산형 포함 사전 확인을 용이하게 하며, 네트워크 비효율성을 유발하지 않고 포함자에게 보상을 제공하기 위해 단계적으로 적용될 수 있습니다.
U – 두 가지 IL 설계 옵션이 고려됩니다. 하나는 발신자가 포함을 위해 제시하는 수수료를 기준으로 거래 순위를 매기는 균일 가격 경매( UPIL )이고, 다른 하나는 포함자가 자신의 목록에 대한 우선순위를 결정하는 무조건적 IL(UIL)입니다.
C – IL은 암호화된 멤풀에서 전파되고 묶일 수 있는 봉인된 트랜잭션(ST)에 C 암호문을 포함할 수 있습니다. ST는 ABB에 커밋됩니다.
D – 페이로드는 분산 방식으로 전파되며 네트워크 표현 에는 IL 트랜잭션에 대한 참조만 포함됩니다. 합의 표현은 자체적으로 완전한 실행 페이로드로 유지되며, ST 발신자에게서 금액을 차감하는 데 사용되는 ST 티켓과 복호화된 ST를 포함합니다.

이 글에서 설명하는 여러 구성 요소는 개별적으로 또는 함께 사용할 수 있습니다. 예를 들어, 분산 페이로드 전파(DPP) 없이 암호화 방식만 실행할 수도 있습니다. 다만, 이 경우 브로드캐스트 효율성이 떨어질 수 있습니다. LUCID의 개발 일정은 아래와 같습니다.

제2절에서는 해결하고자 하는 문제를 소개하고, 제3절에서는 암호화 설계에 대해 자세히 살펴봅니다. 제4절에서는 DPP(Decryption Protocol)를 제시하고, 제5절에서는 설계에서 공개 선택권을 어떻게 처리하는지 논의합니다. 마지막으로 제6절에서는 간략한 설명을 제공하며, 제6.1절에서는 최소 실행 가능 EIP(Electronic Interpreter Protocol)의 구조에 대해 자세히 설명합니다. 부록 A에서는 포함자가 슬롯 동안 페이로드를 점진적으로 구축하는 단계적 포함 목록(SIL)을 제안하여 DPP에 대한 비전을 완성합니다. 부록 B에서는 복호화할 ST(Structured Time)를 ABB(Analytic Hierarchy Block)가 아닌 페이로드에 명시하는 보다 효율적인 설계를 제시합니다. 마지막으로 부록 C에서는 복호화자가 사용할 수 있는 하나의 복호화 방식을 보여줍니다.

타임라인

그림 1은 LUCID 메커니즘에 대한 개요를 제공합니다.

그림 1 1920×1391 167KB

그림 1. LUCID 타임라인. 빌더는 봉인된 트랜잭션에 대한 약정을 포함하는 ABB를 생성합니다. 이러한 ABB는 복호화기가 다음 슬롯이 시작되기 전에 적시에 키를 해제할 수 있도록 비콘 블록에 포함됩니다. IL에 나열된 트랜잭션은 참조를 통해 페이로드에 포함될 수 있습니다.

T_1 이전 단계 에서는 인클루더가 평문 트랜잭션(PT) 외에도 암호화 트랜잭션(ST)을 포함할 수 있는 IL을 전파합니다. ST는 개별적으로 또는 번들(진한 파란색 배경)로 포함되며, 공개 암호화 메모리 풀에서 가져올 수 있습니다. 각 ST는 발신자에게 요금을 부과하고 복호화기에 연결하는 데 사용되는 서명된 ST 티켓과 ST에 포함된 암호문 encrypted_tx 로 구성됩니다. encrypted_tx 는 ST와 다른 from 필드를 가질 수 있는 서명된 PT와 복호화 후 PT를 블록 상단(ToB)에 정렬하는 데 사용될 ToB_fee_per_gas 로 복호화됩니다. 발신자는 복호화기의 오프 프로토콜 지침(해당되는 경우 공개 키 사용)에 따라 개방형 설계에서 복호화기로 트랜잭션을 암호화하거나, 신뢰할 수 없는 방식으로 자체 복호화할 수 있습니다. 부록 A에서는 더 나은 적용 범위를 달성하기 위해 IL을 분산하는 방법을 설명하고, 부록 C에서는 복호화기가 배포할 수 있는 암호화 설계 예시를 제공합니다.
T_1 T 1 – 슬롯 n n 의 증명자(보라색)는 전파된 IL에 대한 보기와 이전 블록의 복호화 키를 고정합니다.
T_1 이후 – 빌더는 모든 관련 IL과 키(대부분의 검증자가 고정된 보기에서 확인한 것들)를 확인했다고 확신하면 블록을 생성할 권한에 대한 ABB (확장된 ExecutionPayloadBid )를 생성합니다(파란색 사각형). 이 ABB에는 IL에 있는 ST와 ST 번들의 해시에 대한 "ST 커밋먼트"가 포함됩니다. 또한 ABB는 이전 슬롯에서 확인된 복호화 키를 표시합니다.
T_2 T 2 – 슬롯 n n 의 시작 부분에서 제안자는 필요한 IL 및 키에 대한 자체적인 관점만큼 포괄적인 최적의 ABB를 선택합니다. 그리고 그 ABB를 비콘 블록에 포함시킵니다.
T_2 T 2 이후 – ABB를 관찰한 후, 노드들은 누락된 IL뿐만 아니라 ABB의 ST 커밋먼트에서 참조되는 ST 바이트를 요청하기 시작합니다. 송신자와 복호화자는 이제 이러한 바이트를 독립적으로 전파할 수 있습니다.
T_3 T 3 – 슬롯 n 의 증명자들은 현재 체인의 헤드에 투표합니다. 비콘 블록이 없거나 포함된 ABB가 고정된 보기에서 누락된 IL 또는 키로 인해 감사를 통과하지 못하면, 해당 보기에서 체인의 헤드인 이전 블록을 표시합니다. ABB가 감사를 통과하면, 해당 블록을 낙관적으로 증명합니다.
T_3 T 3 (페이로드 릴리스) 이후 – 빌더는 ST 티켓을 포함하는 페이로드를 릴리스합니다. 첫 번째 트랜잭션(흰색 사각형)은 이전에 블록 n-1 n − 1 에 커밋된 복호화된 ST이며, 가스당 복호화된 ToB 수수료 순으로 정렬됩니다. 현재 슬롯의 일반 PT가 뒤따르며(검은색 사각형), 빌더가 자유롭게 순서를 정합니다. 빌더는 IL 트랜잭션을 새로 전파하는 대신(네트워크 표현에서 별도의 목록 사용) 인덱스를 통해 IL을 참조합니다.
T_3 T 3 (페이로드 재구성) 이후 – 각 클라이언트는 로컬 캐시에 저장된 IL 트랜잭션 참조와 ST 커밋을 대조하여 전체 페이로드를 구성합니다. 페이로드 루트를 계산하고 검증한 후 페이로드를 실행합니다. 포함된 ABB에서 다음 슬롯 복호화를 위해 선택된 ST는 실행 페이로드에 ST 티켓 목록으로 표시되며, 각 티켓은 지정된 전체 gas_limit 에 따라 요금이 부과됩니다.
T_3 (키 릴리스 ) 이후 – 각 복호화기는 비콘 블록에 포함된 ABB의 ST 커밋먼트를 관찰합니다. 복호화기는 ABB가 자체 ST 커밋먼트에 대한 올바른 데이터(예: 가스 소비량을 지정하는 gas_obligation )를 가지고 있는지, 모든 gas_obligation 항목의 합계가 다음 페이로드에 할당된 몫( ToB_gas_limit ) 내에 있는지, 그리고 비콘 블록이 검증되었는지 확인합니다. 그런 다음 다음 블록에 맞는 ST를 공개하는 서명된 키를 전파합니다. 이 키는 P2P 방식으로 전송되어 T_5 마감 시한 전에 다음 블록의 검증자에 의해 확인됩니다. 이후 복호화된 ST를 ToB 순으로 정렬하여 페이로드 n+ 1 의 ToB 를 구성할 수 있습니다.
T_4 T 4 – 페이로드 적시성 위원회(PTC)는 페이로드의 적시성에 대해 투표합니다. 분산 설계 특성상, 페이로드에 참조된 트랜잭션을 포함하는 IL 또는 커밋된 전체 ST/ST 번들도 이 시점까지 PTC 위원에게 도달해야 투표에서 페이로드가 적시 처리되었다고 판단할 수 있습니다.
T_4 T 4 또는 T_5 T 5 – 공개된 키의 마감일은 PTC 비트필드 투표를 통해 적시성을 확인하거나, 슬롯 n+1 n + 1 의 증명자가 공개된 키에 대한 뷰를 고정하고 뷰 병합을 사용하여 강제할 수 있습니다. 증명자는 PTC 비트필드 투표 또는 고정된 키 뷰 준수 여부에 따라 다음 ABB에 투표합니다.
T_5 이후 - 프로세스는 이전 슬롯 인 T_1 이후와 동일한 경로를 따릅니다. 슬롯 n 에서 복호화된 ST는 ToB에 추가되고 ToB 수수료 순으로 정렬되어 해당 수수료가 부과됩니다. ST가 블록 n 이 생성되기 전에 복호화 되므로 이 설계는 BAL과 완벽하게 호환됩니다. 블록 n+ 1 빌더 는 평소와 같이 BAL을 실행하고 준비합니다.

2. 서론

이더리움과 같은 탈중앙화 블록체인의 문제점 중 하나는 단일 제안자가 각 블록에 포함될 트랜잭션에 대한 독점권을 갖는다는 점이며, 이는 검열과 사용자 복지 저하로 이어질 수 있습니다. 이러한 이유로 여러 동시 제안자(MCP)를 사용하는 설계 방식이 제안되었습니다( 1 , 2 , 3 , 4 ). 수년간의 병렬적인 포함 목록(IL) 연구(예: 1 , 2 )를 통해 포크 선택 강제 포함 목록( FOCIL ) 설계가 개발되었습니다. FOCIL은 EIP-7805를 통해 이더리움에서 검열 저항(CR)을 촉진하는 주요 옵션으로 자리 잡았으며, 여러 포함자가 다음 블록에 포함될 트랜잭션의 IL을 전파할 수 있도록 합니다. 그러나 블록이 가득 차면 제안자는 실제로 포함된 트랜잭션보다 더 많은 비용을 지불하더라도 여전히 트랜잭션을 검열할 권리를 갖습니다. 또한, 검열 대상 거래의 상당 부분은 MEV를 피하기 위해 비공개로 전파되어야 하므로 CR에 대해 FOCIL에 의존할 수 없습니다.

제안자가 블록 내용을 통제하는 데 있어 재량권을 줄이는 다양한 포함 목록(IL) 설계 방식이 제안되어 왔습니다. 무조건 포함 목록 (UIL)은 일반적인 포함 기준을 충족하는 모든 나열된 거래를 포함하도록 요구합니다. EIP-8046은 포함 목록에 대한 균일 가격 경매 (UPIL)를 도입하여 블록이 가득 찼을 때 제안자가 더 이상 포함 목록을 무시할 수 없도록 했습니다. 거래는 지불하려는 수수료에 따라 순위가 매겨지고, 가장 높은 수수료를 지불하려는 거래가 포함됩니다. 각 거래는 동일한 균일 블록 내 기본 수수료를 지불하며, 이 수수료는 소각됩니다. 이는 강력한 CR(크래프팅 규칙)을 제공하며 시간 제약이 있는 거래와 다차원적인 수수료 시장에 유리합니다. 그러나 UIL과 UPIL은 거래가 여전히 공개적으로 전파되어야 하므로 MEV(다중 효과)를 완전히 방지하지는 못합니다.

MEV(Mempool Encryption )를 방지하기 위해 거래는 확정될 때까지 숨겨져 있어야 합니다. 암호화된 멤풀에 대해서는 제안자 확정을 활용하는 임계값 암호화, Sealed 거래 에서처럼 확정-공개 방식, 또는 이 둘을 혼합한 방식 등 다양한 설계가 제안되었습니다. ePBS(electronic Protocol Security Board) 하에서 Sealed 거래는 ABB( Approved Budget Board)를 활용할 수 있습니다. Sealed 거래처럼 포크 선택 강제(fork-choice enforcement) 하에서 확정-공개 방식은 다양한 프로토콜 외 암호화 방식을 더욱 용이하게 할 수 있으며, 이는 일반화된 Sealed 거래 의 한 형태입니다. 이러한 방향으로 진행되지만 동일 슬롯 복호화를 사용하는 설계가 최근 연구 논문 및 EIP( Engineering Improvement Project)로 제안되기도 했습니다. 또 다른 전략으로는 스마트 계정 암호화 멤풀을 사용하는 방식이 있으며, 이 역시 EIP 로 제안되었습니다.

하이에크의 관점에서 분산형 블록 생성을 옹호하는 논거는 더 많은 참여자들이 좋은 블록을 만드는 데 필요한 지식을 공동으로 보유하게 된다는 것입니다. 개별 참여자의 블록 생성 기여도를 MEV(Method of Evaluation)로부터 보호하고 유효한 거래에 대한 블록 생성을 보장함으로써만 참여자들이 신뢰할 수 없는 방식으로 지식을 공유 할 수 있게 된다는 점에 주목해야 합니다.

일반적으로 포함 목록은 데이터 중복을 유발합니다. 트랜잭션은 멤풀에서 가십되고, IL을 통해 전달된 다음, 실행 페이로드 내부에서 다시 가십됩니다. 대신 포함 목록 가십을 "사전 채우기" 단계로 처리함으로써 페이로드를 슬롯 지속 시간 동안 효과적으로 분산시킬 수 있으며, 마지막에 버스트 방식으로 전파되지 않습니다. 따라서 단일 슬롯 윈도우 내에서 동일한 바이트가 두 번 전송되는 것(한 번은 IL 가십에서, 한 번은 페이로드 봉투에서)을 방지할 수 있습니다. ExecutionPayloadEnvelope 의 크기를 줄이면 전파 지연 시간이 최소화되어 슬롯 시간을 단축하거나, IL을 늘리거나, 블록 크기를 키울 수 있습니다. 이 설계는 페이로드 청킹( 1 , 2 )과 호환되며, DPP에서 이미 어느 정도 압축된 페이로드를 기반으로 작동합니다.

DPP는 네트워크 효율성을 향상시키지만, 여러 개의 포함 목록(IL)이 동일한 트랜잭션을 전파하는 비효율성을 해결하지는 못합니다. 이러한 중복을 줄이는 프로토콜 내 솔루션이 필요하며, 본 논문에서는 이를 위해 신뢰할 수 없는 사전 확인을 용이하게 하는 단계적 포함 목록(부록 A)을 제안합니다. 실행 전에 조정해야 하는 독립적인 복호화 키의 수를 제한하기 위해, 트랜잭션 트리(ST)는 커밋 전에 묶을 수 있습니다. 본 논문에서는 일반화된 봉인된 트랜잭션(참고문헌 1 , 2 의 확장)을 구현하는 LUCID를 제안합니다. LUCID는 포함자가 MEV로부터 트랜잭션을 보호하고 블록 공간에 대한 동등한 권한을 갖도록 업그레이드하여 포함자와 제안자 간의 격차를 해소합니다.

3. 암호화 설계

암호화 설계는 먼저 UPIL 메커니즘을 사용하여 설명하며, UIL 메커니즘에 필요한 변경 사항은 3.10절에 제시됩니다. 일반적인 설계에서는 바닐라 FOCIL(조건부 IL)도 사용할 수 있습니다. 3~4절에서 설명한 DPP, UPIL, 번들 등의 여러 기능은 기본 LUCID 암호화 멤풀에는 필수적이지 않으며, 이는 6.1절에서 자세히 논의됩니다.

3.1 봉인된 거래

봉인된 거래(ST)는 서명된 ST 티켓과 암호화된 거래 encrypted_tx 로 구성됩니다. ST는 다음과 같은 필드를 포함합니다.

ST 티켓에 서명하고 수수료를 지불하는 from ,
일반 필드 nonce , gas_limit , max_fee_per_gas , max_priority_fee_per_gas , max_ranking_fee_per_gas
복호화를 담당하는 주체의 decryptor_address ,
from 자금이 투입된 경우, 복호화된 평문 거래 실행 시 지불될 decryptor_fee 입니다.
reveal_commitment 는 reveal_commitment = hash_tree_root(RevealCommitmentPreimage(ticket.from, ticket.nonce, plaintext_tx, ToB_fee_per_gas)) 로 정의되며, 공개된 평문 페이로드를 특정 유료 티켓에 바인딩합니다.
ciphertext_hash 암호화된 텍스트 바이트를 바인딩하는 데 사용됩니다. 여기서 ciphertext_hash = keccak256(encrypted_tx) 입니다.
encrypted_tx 는 RevealedTransaction(plaintext_tx, ToB_fee_per_gas) 로 복호화됩니다.

일반적인 해결책을 제시한다는 취지에서, 기본 아이디어는 프로토콜이 클라이언트가 encrypted_tx 파싱하고 여는 방법만 명시하고, 복호화 도구가 어떤 키 에스크로/하이브리드 암호화 방식을 사용할지는 (프로토콜 외부에서) 정의하도록 하는 것입니다. 구체적으로, encrypted_tx 일종의 봉투입니다.


 encrypted_tx = header_len:u16 || header || ct_demct_dem = nonce || aead_ciphertext

header 프로토콜에 대해 불투명하며 DEM 키를 복구하는 데 필요한 복호화기별 메타데이터(예: 하이브리드 공개 키 암호화( HPKE )/KEM 캡슐화, 임계값 복호화기 키에 따른 임계값 암호문 등)를 포함할 수 있습니다. 복호화기는 발신자가 header 채우는 방법과 특정 티켓에 대한 DEM 키 k_dem 도출되는 방법을 설명하는 프로토콜 외부 지침을 게시합니다. 공개 시점에 복호화기는 티켓별 DEM 키 자료( k_dem )만 공개하여 누구나 ct_dem 복호화하고 reveal_commitment 에 대해 공개를 검증할 수 있도록 합니다.

복호화 도구는 공개된 k_dem 가 유료 티켓에 컨텍스트 바인딩되도록 해야 합니다(예: KDF 입력으로 (chain_id, ticket.from, ticket.nonce) 의 도메인 분리 인코딩(HPKE를 사용하는 경우 HPKE info ) 및/또는 AEAD 관련 데이터를 사용하여 키를 도출). 이렇게 하면 공개된 키가 티켓별로 고유해지므로, 한 티켓에 대한 복호화 자료를 공개하더라도 header 바이트가 티켓 간에 복사되더라도 다른 티켓에 첨부된 암호문을 복호화하는 데 도움이 되지 않습니다(헤더에서 복구된 장기 비밀 키는 절대 공개해서는 안 됩니다). 부록 C는 이러한 구성의 한 예를 제공합니다(Benedikt Wagner 제공). 신뢰할 수 없는 자체 복호화의 경우, 발신자는 간단하게 처리할 수 있습니다(예: header_len = 0 으로 설정하고 티켓별로 새로운 DEM 키를 직접 선택).


 class RevealedTransaction ( Container ):plaintext_tx: Transaction # Type 2 transaction ToB_fee_per_gas: uint64 class RevealCommitmentPreimage ( Container ):ticket_from: ExecutionAddressticket_nonce: uint64plaintext_tx: TransactionToB_fee_per_gas: uint64 class STTicket ( Container ): from : ExecutionAddressnonce: uint64gas_limit: uint64max_fee_per_gas: uint64max_priority_fee_per_gas: uint64max_ranking_fee_per_gas: uint64decryptor_address: ExecutionAddressdecryptor_fee: uint64reveal_commitment: Bytes32ciphertext_hash: Bytes32signature: Bytes65 # Signature by `from` over the ticket fields class SealedTransaction ( Container ):ticket: STTicketencrypted_tx: ByteList[MAX_ENCRYPTED_TX_BYTES]

gas_limit encrypted_tx 의 바이트 크기에 해당하는 calldata 비용을 충당할 수 있을 만큼 충분해야 하며, MAX_TRANSACTION_GAS_LIMIT 으로 제한되고, 실행 후 실제 가스 사용량을 확인하더라도 환불 없이 전액 청구됩니다. RevealedTransaction 내의 복호화된 plaintext_tx 는 max_priority_fee_per_gas = 0 , max_fee_per_gas = 0 (복호화된 트랜잭션은 이미 ST 티켓으로 선불되었으므로), gas_limit = ticket.gas_limit 인 EIP-1559(유형 2) 트랜잭션입니다.

ST 티켓의 논스는 이더리움의 일반 계정 논스를 재사용하며, ST는 실행 성공 여부와 관계없이 비용이 발생하므로 암호문이 나중에 공개되는지 여부와 관계없이 소모됩니다. ST 발신자는 ST 티켓에 서명합니다. 서명은 chain_id (및 포크/버전)와 티켓 필드( signature 제외)의 해시 트리 루트를 포함하는 도메인으로 구분된 다이제스트를 기반으로 계산됩니다.

encrypted_tx 내의 평문 페이로드는 plaintext_tx 의 일부로 평문 발신자에 의해 별도로 서명됩니다. 노드는 티켓 서명을 확인하고 ciphertext_hash encrypted_tx 의 해시와 일치하는지 확인하여 ST를 검증합니다.

3.2 봉인된 거래 묶음

봉인된 트랜잭션(Stealed Transaction, ST)은 ABB(Account-Based Board)에 커밋됩니다. 암호화된 멤풀이 널리 사용되면, 수많은 개별 커밋과 복호화 키로 인해 네트워크에 부담이 가중될 수 있으며, 특히 이더리움 네트워크가 확장될수록 더욱 심각해질 수 있습니다. 따라서 높은 처리량을 유지하면서도 ABB에 ST를 커밋하는 횟수를 제한해야 할 이유가 있습니다. 이러한 이유로 ST들을 묶어서 한꺼번에 커밋할 수 있습니다.

번들 내의 모든 트랜잭션은 동일한 decryptor_address 가져야 하며, 번들은 decryptor_address 제어하는 주체에 의해 서명되어야 합니다. 번들에는 전체 ST를 포함하거나, 해시 값과 그 위에 서명된 해시 값만 포함할 수 있습니다. 이 경우, 포함자는 전체 ST 번들을 재구성해야 합니다. PTC 마감일까지 전체 ST 바이트를 사용할 수 있어야 한다는 점을 고려할 때, IL에 전체 ST 바이트를 포함하도록 요구하는 것이 합리적입니다. 비콘 블록에서 해당 번들을 참조하는 IL을 사용할 수 없는 경우, 전체 번들을 P2P 방식으로 전파해야 합니다.

번들링되지 않은 암호화된 멤풀 트랜잭션을 포함할 수 있는 기능은 다음과 같은 세 가지 이유에서 여전히 유익합니다.

IL에 포함된 모든 ST는 실행될 수 있으므로 공용 멤풀에 스팸 방지 기능을 제공합니다.
임계값 복호화와 같은 설계는 트랜잭션을 사전에 묶는 시퀀서 없이도 실행될 수 있습니다.
사용자는 신뢰할 수 없는 방식으로 복호화하려는 단일 ST에 대해 번들을 전파할 필요가 없습니다.

3.3 ST 약속

봉인된 트랜잭션은 ABB의 "ST 커밋먼트"에 개별적으로 또는 공개 암호화 멤풀에서 가져온 번들의 일부로 커밋됩니다(또는 프로토콜 외부에서 제공될 수도 있으며, 이 경우 MEV 부스트와 유사한 설계를 활용할 수 있습니다). 포함 목록은 ST 커밋먼트에 대한 중요한 포함 경로를 제공하며, 빌더는 자신이 제안한 커밋먼트를 준수해야 합니다. 각 ST 커밋먼트는 다음 네 가지 필드를 지정합니다.


 class STCommitment ( Container ):bundle: bool # False if ST, True if ST-bundle commitment_root: Bytes32 # ticket_root if ST, bundle_root if bundle decrypt: Bitfield # indices to release keys to decrypt the tx gas_obligation: uint64 # sum of gas_limit over entries with decrypt=1

ST 커밋먼트는 commitment_root 통해 식별되며, 이는 서명된 티켓의 SSZ 해시 트리 루트 ticket_root = hash_tree_root(STTicket) 이거나 서명된 번들의 SSZ 해시 트리 루트( bundle_root 입니다. 번들의 번들 루트는 번들 내의 모든 ticket_root 항목을 포함합니다. decrypt=1 인 ticket_root 항목에 대한 가능한 scheduled_root 6.3절에서 설명합니다. 암호화된 텍스트 바이트는 서명된 티켓에 포함된 ciphertext_hash = keccak256(encrypted_tx) 를 통해 티켓에 바인딩됩니다.

3.4 할당량 및 ToB 가스 제한

각 IL에는 ST 커밋 할당량이 있으며, 초기에는 상당히 낮게 설정할 수 있습니다. 예를 들어, 각 IL은 MAX_COMMITS_PER_IL = 4 ST 커밋을 할당받을 수 있습니다. 빌더가 자체적으로 커밋을 수행할 수 있도록 허용하는 것도 가능하며, 예를 들어 MAX_COMMITS_PER_IL ST 커밋을 할당할 수도 있습니다. 그러나 설계의 단순성을 위해 빌더에게 자체 IL을 부여하는 것이 가장 쉬울 수 있습니다. FOCIL과 마찬가지로 각 IL에는 max_bytes_per_inclusion_list 할당량이 있습니다. 이 값은 가스 제한에 따라 달라지므로 블록의 gas_limit 증가할 때 포함자가 제안자에 비해 불리하지 않도록 합니다. max_bytes_per_inclusion_list = gas_limit/(IL_COMMITTEE_SIZE * GAS_PER_AGG_IL_BYTES) 로 계산할 수 있습니다. FOCIL에서와 같이 IL_COMMITTEE_SIZE = 16 사용할 때, GAS_PER_AGG_IL_BYTES = 2**9 로 설정하면 가스 제한이 60M일 때 IL 바이트 크기는 7.15 KiB 가 됩니다. ST 커밋은 여전히 max_bytes_per_inclusion_list 에 포함됩니다.

각 블록에는 복호화된 트랜잭션에 대한 ToB_gas_limit 있으며, 이는 이전 블록의 전체 gas_limit 의 일부(예: 잠정적으로 1/4 * gas_limit 로 설정됩니다. 또한 ToB_marginal_ranking_fee_per_gas 가 있으며, 이는 현재 블록의 marginal_ranking_fee_per_gas (EIP-8046에 명시된 대로)와 다음 블록의 ToB_gas_limit 할당에서 제외되는 가장 높은 순위의 ST의 ranking_fee_per_gas 중 최댓값으로 계산됩니다.

3.5 감사 가능한 건설업체 입찰(ABB)

빌더는 페이로드를 빌드할 권리에 대한 감사 가능한 빌더 입찰(ABB)을 제출합니다. ABB는 ExecutionPayloadBid 확장하여 ToB_marginal_ranking_fee_per_gas , ST-commitments 및 이전 블록의 ST-commitments에 대한 키 준수 여부를 나타내는 비트필드를 포함합니다.


 class ILCommitments ( Container ):IL_root: Bytes32commits: List [STCommitment, MAX_COMMITS_PER_IL] class ILKeyAdherence ( Container ):key_adherence: List [Boolean, MAX_COMMITS_PER_IL] class ABB ( Container ):... # existing fields of the ExecutionPayloadBid ToB_marginal_ranking_fee_per_gas: uint64IL_data: List [ILCommitments, IL_COMMITTEE_SIZE]key_adherence: List [ILKeyAdherence, IL_COMMITTEE_SIZE] # one bitfield per previous IL in a list of bitfields

빌더는 (ticket.from, ticket.nonce) 사용하여 ST 커밋먼트의 ST를 중복 제거합니다. 중복 제거된 세트에는 (ticket.from, ticket.nonce) 가 동일한 ST가 하나만 존재해야 하며, 이 ST는 decrypt 비트가 1 로 설정됩니다. (ticket.from, ticket.nonce) 가 동일한 다른 모든 ST는 decrypt 비트가 0 으로 설정되어야 합니다. 또한, ticket.from 에 대해 유효하지 않은 티켓 nonce 시퀀스를 생성하거나 티켓 요금 부과 시작 시점에 요금이 부과되지 않는 ST(섹션 3.9)도 동일한 방식으로 제거됩니다. 중복 제거 중에 어떤 ST를 유지할지 결정하는 결정론적 규칙이 적용되며, 번들에서 가장 많은 ST를 포함하는 인스턴스를 선택하고, 동점일 경우 IL의 committee_index 기준으로 결정합니다.

특정 ST 번들에 대한 IL 커밋이 두 개 이상 있는 경우, 중복된 커밋은 공간 절약을 위해 decrypt 값을 표준 0 인코딩(단일 비트 0)으로 설정하고, committee_index 가장 높은 IL의 ST 번들만 남깁니다. 변조를 방지하기 위해 decrypt 값에 설정된 비트가 없는 경우, 번들 길이에 관계없이 정확히 0 (단일 비트 0)으로 인코딩되어야 하며 모든 비트가 0인 마스크로 해석되어야 합니다. 다른 모든 비트가 0인 인코딩은 유효하지 않습니다.

번들 내의 중복된 ST는 모두 동일한 decryptor_address 공유하므로 중복 제거는 복호화자의 책임 하에 이루어집니다. 또한 빌더는 decrypt 비트를 임의로 설정할 수 없습니다. 검증자, 빌더(및 슬롯 n+ 1 의 모든 노드)는 decrypt 비트가 결정론적 규칙(예: 중복 제거)을 준수하도록 엄격하게 설정되었는지, 그리고 IL에 의해 노출된 유효한 ST를 누락하지 않았는지 검토합니다. 페이로드가 검증을 통과하지 못하면 프로토콜은 4.5절에 설명된 대로 유효하지 않은 페이로드 복구 프로세스를 시작합니다.

중복 제거된 ST는 ranking_fee_per_gas 가 ToB_marginal_ranking_fee_per_gas 를 초과하는 경우 decrypt = 1 로 설정하여 최종적으로 포함됩니다. 이때 동점일 경우 ticket_root 기준으로 결정합니다. 포함할 ST를 결정한 후, 각 ST 커밋먼트에 대해 gas_obligation 은 해당 커밋먼트에서 decrypt = 1 로 설정된 모든 gas_limit 항목의 합으로 설정됩니다. ToB_marginal_ranking_fee_per_gas 는 decrypt 비트필드를 압축하여 충분한 ranking_fee_per_gas 가진 트랜잭션의 허용 범위만 포함하도록 하는 데에도 사용할 수 있습니다.

ABB의 commitment_root 사용하면 복호화 프로그램은 페이로드가 공개되기 전이라도 적시에 비콘 블록을 감지하면 이를 식별하고 복호화 키를 공개할 수 있습니다. 각 IL_root 는 ABB에 포함되어 모호성 문제를 해결하며, 이는 DPP를 다루는 4.3절에서 자세히 설명합니다.

건설업체가 각 입찰마다 전체 ABB를 전파해야 하는 번거로움을 피하기 위해 두 가지 방법을 사용할 수 있습니다. 첫째, 건설업체는 새로운 입찰마다 이전 입찰과의 차이(델타)를 지정하고 참조용 해시값을 포함할 수 있습니다. ST 약정은 입찰 마감일 훨씬 전에 확정되므로, 이후 입찰에서의 델타는 늦게 도착한 PT로 인한 입찰 값 및 페이로드 변경 사항만 반영하면 됩니다. 둘째, 풀 방식(pull-scheme)을 도입하여 건설업체의 입찰을 간소화하고, 제안자가 게시 전에 낙찰된 건설업체로부터 ABB를 가져오는 방식입니다.

3.6 증명

검증자는 ABB를 자신들이 관찰한 IL과 비교합니다. 그들은 다음 사항을 확인합니다.

모든 gas_obligation 항목의 합계가 ToB_gas_limit 내에 있습니다.
발표된 ToB_marginal_ranking_fee_per_gas 고려할 때, 모호함 없이 적시에 관찰된 모든 IL은 ABB에 정확하게 명시되어 있습니다.

검증자가 확인하지 않은 ABB의 포함 목록은 검토되지 않습니다. 노드는 ABB에서 해당 목록을 확인한 후 요청하며, PTC는 최종적으로 요청의 적시성에 대해 투표합니다.

3.7 주요 릴리스

복호화기는 비콘 블록 n n 과 함께 전파된 ABB에서 ToB_marginal_ranking_fee_per_gas 와 명시된 gas_obligation 관찰합니다. ToB_marginal_ranking_fee_per_gas 와 decrypt 비트필드가 자체 ST-commitment에 대해 지정된 gas_obligation 실제로 생성하는지, 그리고 모든 gas_obligation 항목의 합계가 ToB_gas_limit 내에 있는지 확인합니다. 이는 복호화 키를 해제하기 위한 필수 조건입니다. 특히, 페이로드가 유효하지 않거나 시기적절하지 않은 것으로 판명되더라도 복호화기의 ST-commitment는 항상 ToB_gas_limit 내에 포함됩니다. 즉, 다음 유효한 페이로드에 ToB를 포함할 수 있으며, 이는 4.5절에서 자세히 설명합니다.

ST(또는 번들) 목록을 제공하는 IL을 사용할 수 없는 경우, 복호화기는 이 시점에서(이전에 수행하지 않은 경우) ABB의 commitment_root ticket_root / bundle_root 일치하는 전체 ST 바이트(또는 번들 본문)를 브로드캐스트하여 노드가 PTC 마감일까지 릴리스된 키를 검증할 수 있도록 합니다. 복호화기(또는 다른 사용자)가 커밋된 ST에 대한 전체 SealedTransaction 바이트를 제공하면 노드는 hash_tree_root(st.ticket) == commitment_root 및 keccak256(st.encrypted_tx) == st.ticket.ciphertext_hash 확인합니다. 복호화기는 비콘 블록이 정규화될 것이라고 확신할 때(예: 해당 블록에 대한 증명을 확인한 후) 키를 릴리스합니다.

키 공개 시점에 복호화기는 3.1절에 설명된 대로 대칭 키 자료를 게시합니다. 키는 decryptor_address 주소로 서명된 메시지에 포함되어 공개되며, 이 메시지에는 committee_index 와 commit_index 통해 관련 ST 커밋이 식별되고, 슬롯 번호와 관련 ABB를 포함하는 비콘 블록의 beacon_block_root 가 추가로 포함됩니다. 키 묶음의 경우, 키는 1 로 설정된 decrypt 비트 수와 동일한 길이의 목록으로 묶이며, 커밋된 묶음과 동일한 순서로 정렬됩니다.

키 메시지는 P2P 방식으로 대량 전송됩니다. 노드는 (beacon_block_root, slot) 으로 식별되는 ABB에 존재하는 커밋먼트를 대상으로 하고 ST-커밋먼트에 지정된 decryptor_address 로 서명된 모든 형식이 올바른 키 메시지를 중계합니다. 키는 커밋된 암호문을 RevealedTransaction(plaintext_tx, ToB_fee_per_gas) 로 복호화할 때 hash_tree_root(RevealCommitmentPreimage(ticket.from, ticket.nonce, plaintext_tx, ToB_fee_per_gas)) == ticket.reveal_commitment 만족하고, 복호화된 plaintext_tx 필수 고정 필드( max_priority_fee_per_gas = 0 , max_fee_per_gas = 0 , gas_limit = ticket.gas_limit )를 만족하면 유효합니다. 복호화된 평문의 발신자와 논스는 ST 발신자의 from 및 nonce 와 일치할 필요가 없습니다.

동일한 beacon_block_root , committee_index 및 commit_index 대상으로 하지만 바이트 단위로 동일하지 않은 키는 모호한 것으로 간주됩니다. 모호한 키는 FOCIL의 IL 모호성과 유사하게 처리됩니다. 노드는 동일한 대상에 대해 관찰된 최초의 두 개의 서로 다른 서명된 키 메시지를 전파하여 모호성을 알리고, 빌더는 복호화기가 모호성을 보인 ST를 무시할 수 있습니다. 증명자는 증명 마감일까지 모호성 증거를 관찰한 경우 이러한 생략을 허용합니다.

3.8 PTC 투표

PTC는 페이로드 브로드캐스트 및 블롭 데이터와 관련된 DA에 대해 투표합니다. 페이로드의 분산 전파(섹션 4)를 준수하기 위해 PTC 투표는 커밋된 ExecutionPayload 재구성하는 데 필요한 모든 데이터, 즉 참조된 평문 트랜잭션 바이트( tx_reference ), 참조된 ST 커밋, 그리고 해당 커밋에서 참조되는 기본 ST/번들 바이트의 가용성에도 관련됩니다.

따라서 빌더는 PTC 투표 시점까지 ABB에 등록한 IL이 도착했는지 확인해야 할 책임이 있지만, IL을 사용할 수 없는 경우 복호화 도구는 해당 ST 바이트를 독립적으로 전파할 수도 있습니다. 이 주제에 대한 자세한 내용은 4.3절에서 다룹니다. 저장된 IL을 이용하여 페이로드를 재구성한 후, PTC 구성원은 페이로드의 루트가 올바른지 확인합니다. 또한, 페이로드에서 확인할 수 있듯이 ABB가 올바르게 지정되었는지 투표를 통해 확인합니다.

선택적으로, 각 PTC 멤버는 다음 슬롯 복호화를 위해 예약된 ST 커밋 중 키 마감 시간까지 유효한 키 메시지가 관찰된 커밋을 나타내는 서명된 비트필드를 브로드캐스트합니다. 이 비트필드는 0이 아닌 decrypt 마스크를 가진 예약 ABB의 ST 커밋에 대해 (committee_index, commit_index) 순서로 정규 인덱싱됩니다(즉, committee_index 증가하는 순서로 IL_data 스캔하고 commits[] 증가하는 순서로 commit_index 스캔). PTC 투표를 사용하는 이유는 6.3절에서 설명합니다.

빌더와 n+ 1 번째 슬롯 의 검증자는 PTC 투표 결과를 바탕으로 적시성에 대한 결정을 내립니다. 검증자는 의견을 병합하기 위해 n+ 1 번째 슬롯 시작 전에 PTC 투표에 대한 자신의 의견을 확정할 수 있습니다. 빌더는 키가 예를 들어 45~55%의 득표율을 얻었을 때 적시성에 대한 자신의 의견을 강제할 수 있습니다(45% 미만일 경우 검증자는 적시성이 아니라고 판단하고, 55% 이상일 경우 검증자는 투표 마감일까지 해당 키를 직접 확인했다는 조건 하에 적시성이 맞다고 판단합니다). 선택적으로 빌더는 의견 병합을 위해 자신이 확인한 투표 결과를 별도의 구조로 전파할 수 있습니다.

3.9 지불 및 포함

실행 페이로드의 합의 표현은 st_tickets 목록과 decrypted_transactions 목록(둘 다 4.2절에 설명됨)으로 확장됩니다. 이 목록들은 ST에 요금을 부과하는 데 사용됩니다.

ST 티켓 요금 부과

st_tickets 의 각 ST 티켓은 ticket.from ticket.from 에서 ticket.gas_limit * (base_fee_per_gas + ToB_marginal_ranking_fee_per_gas) + ticket.decryptor_fee 차감합니다. 여기서 ToB_marginal_ranking_fee_per_gas 해당 티켓의 ST 약정을 예약한 ABB(즉, 보류 세트를 정의하는 ABB)에서 가져옵니다. 실제 gas_used 기준으로 한 n+ 1 블록 에서는 환불이 없으며, ST가 복호화되지 않으면 decryptor_fee 만 환불됩니다. st_tickets 의 티켓 중 하나라도 완전히 충전되지 않으면 해당 블록은 무효입니다.

노드는 ToB_marginal_ranking_fee_per_gas (섹션 3.4 참조)가 ToB에서 제외된 유효하게 포함될 수 있는 ST 중 가장 높은 순위의 ST의 ranking_fee_per_gas 와 비교하여 올바르게 설정되었는지 확인합니다. ST는 실제 사용된 가스가 아닌 공개적으로 보이는 gas_limit 기준으로 요금이 부과되므로, 커밋 시점의 자금 조달 가능성 검사는 고정적이며 다른 트랜잭션의 실행에 의존하지 않습니다. 이는 UPIL의 순위 결정 메커니즘에서 보수적인 잔액 검사를 필요로 하는 순환 종속성 문제를 방지합니다.

암호 해제된 ST를 포함하고 요금을 부과합니다.

노드들은 키 공개를 관찰하고 ST 트랜잭션을 로컬에서 복호화합니다. 블록 n+ 1 의 생성자 는 찾을 수 있는 모든 키를 수집하고, 자신이 준수하는 유효한 키들을 담은 비트필드가 포함된 ABB를 생성합니다. 증명자들은 생성자가 모든 유효한 키를 적시에 준수하도록 요구하며, 적시성은 앞서 설명한 바와 같이 뷰 병합 또는 PTC 투표를 통해 결정됩니다. 공개된 키로 복호화할 수 없는 ST는 무시됩니다.

노드는 각 복호화된 ToB 트랜잭션을 해당 트랜잭션을 생성한 특정 ST 티켓(전체 ST 및 해당 키를 통해)과 비교하여 유효성을 검사합니다. 공개는 hash_tree_root(RevealCommitmentPreimage(ticket.from, ticket.nonce, plaintext_tx, ToB_fee_per_gas)) == ticket.reveal_commitment 이고 복호화된 plaintext_tx 필수 고정 필드( max_priority_fee_per_gas = 0 , max_fee_per_gas = 0 , gas_limit = ticket.gas_limit )를 만족하는 경우에만 유효합니다.

decrypted_transactions 처리하는 첫 번째 단계는 복호화되지 않은 모든 ST에 대해 ticket.decryptor_fee 를 환불하는 것입니다. 발신자는 ticket_index (섹션 4.2)에서 인덱스가 누락된 발신자로 식별됩니다. decrypted_transactions 의 decryptor_fee 해당 ticket.decryptor_address 로 입금됩니다. 마지막으로 프로토콜은 ticket.from 에서 ToB 수수료 ticket.gas_limit * ToB_fee_per_gas 차감하고 소각합니다. ticket.from 이 이 수수료를 충당할 수 없는 경우 해당 트랜잭션은 처리되지 않습니다.

복호화된 plaintext_tx 의 from 가 동일하고 순차적인 nonce를 갖는 여러 ST를 제출하는 사용자는 ToB_fee_per_gas 가 nonce와 호환되는지 확인해야 합니다. 복호화된 트랜잭션은 주로 ToB_fee_per_gas 에 따라 정렬되지만 실행 시에는 발신자별 nonce 순서가 유지되기 때문입니다.

3.10 무조건 IL 버전

무조건적 IL 버전의 경우 몇 가지 수정 사항이 있으며, 이에 대한 자세한 내용은 다음과 같습니다. 핵심 아이디어는 FOCIL의 설계 원칙을 대부분 유지하면서 각 포함자의 목록을 무조건적으로 허용하는 "무조건적 FOCIL"을 구현하는 것입니다. 이는 LUCID에서처럼 암호화된 멤풀을 구축하는 실행 가능한 방법일 뿐만 아니라, EIP-7999와 같은 다차원 수수료 시장에서도 유용할 수 있습니다. 무조건적 FOCIL에 대한 자세한 내용과 분석은 여기에 설명된 내용 외에 별도로 제공될 예정입니다.

오버플로우가 있는 UIL

ToB_marginal_ranking_fee_per_gas 는 ABB에서 제거되었습니다. 각 IL은 최소 ST_gas_min_per_IL 의 ToB 가스를 소비할 수 있으며, 이 값은 ST_gas_min_per_IL = ToB_gas_limit // IL_COMMITTEE_SIZE 로 계산됩니다. IL이 실제로 소비할 수 있는 ToB 가스량은 다른 IL의 소비량에 따라 달라집니다. max_bytes_per_inclusion_list 를 설정하여 IL이 ST_gas_min_per_IL 또는 그 이하까지 calldata를 채울 수 있도록 할 수 있습니다. ST 커밋의 순서와 번들 내 ST의 순서가 IL이 지정한 우선순위를 정의합니다. 빌더는 모든 gas_obligation 항목의 합계가 ToB_gas_limit 을 초과할 때까지 IL이 소비할 수 있는 최대 가스량을 증가시킨 다음, 마지막으로 추가된 트랜잭션을 제거하기 위해 최대값을 감소시킵니다. 따라서 이전과 마찬가지로 gas_obligation 항목의 (중복 제거되지 않은) 총합은 ToB_gas_limit 내에 있어야 합니다.

검증자는 모든 적시 ST 커밋에 대해 모든 gas_obligation 항목의 최댓값과 공개된 decrypt 비트를 고려하여 gas_obligation 올바르게 지정되었는지 확인합니다. 각 복호화자 또한 자신의 커밋에 대해 이를 검증합니다. 복호화자는 ST 가스 제한의 합계가 gas_obligation 과 같아지도록 decrypt = 1 인 트랜잭션에 대한 키를 공개합니다.

오버플로가 없는 UIL

오버플로가 없는 무조건적인 IL 버전에서는 각 IL의 가스 제한이 ST_gas_limit_per_IL = ToB_gas_limit // IL_COMMITTEE_SIZE 로 제한됩니다. 이 제한은 IL별로 고정되어 있으므로 ABB에서 gas_obligation 필드를 생략할 수 있습니다. 하지만 포함자가 여전히 모호한 표현을 사용할 수 있으므로 ABB에 commitment_root 필드를 유지하는 것이 타당해 보입니다.

UIL과 UPIL이 함께

또 다른 실행 가능한 설계는 IL에 ST_gas_limit_per_IL = ToB_gas_limit // IL_COMMITTEE_SIZE 무조건 포함시키고, 추가 트랜잭션은 UPIL에 따라 포함시키는 것입니다. 그러면 오버행은 max_bytes_per_inclusion_list 로 제한됩니다.

4. 분산 페이로드 전파

페이로드는 페이로드 브로드캐스트에서 트랜잭션 바이트를 중복하는 대신, 미리 전달된 트랜잭션 데이터와 이전 ST 커밋에 대한 참조를 활용합니다. 합의 표현은 st_tickets 및 decrypted_transactions (섹션 4.2)로 확장되지만, 일반 transactions 목록은 현재 실행 페이로드와 마찬가지로 전체 트랜잭션 바이트 목록으로 유지됩니다. P2P를 통해 전송되는 네트워크 표현은 다르며 일시적인 최적화로 사용됩니다.

4.1 네트워크 표현

경량 페이로드 브로드캐스트가 도입되었습니다. DistributedExecutionPayloadEnvelope 는 포함 목록에서 가져오지 않은 트랜잭션의 전체 트랜잭션 바이트를 전달하는 것 외에도 노드가 이미 가지고 있거나 정규 포함 목록에서 가져올 수 있을 것으로 예상되는 트랜잭션에 대한 포인터 목록을 포함합니다. 각 ILTransactionPointer 블록의 최종 transactions 목록(합의 표현)에서 해당 포함 목록 트랜잭션의 위치를 지정합니다.


 class ILTransactionPointer ( Container ):committee_index: uint8 # 0..IL_COMMITTEE_SIZE-1 tx_index: uint16 # index into the canonical IL body for this committee_index position: uint32 # index in the final full transactions list

페이로드의 네트워크 표현은 ST를 참조하지 않습니다. 빌더가 생성하는 ABB는 ST 티켓과 복호화된 ST를 결정론적으로 재구성하기에 충분합니다. 구체적으로, 스케줄링 ABB의 ST 커밋먼트는 빌더가 지정한 decrypt 비트를 통해 페이로드에 포함된 ST 티켓과 그 순서를 식별합니다. 마찬가지로, key_adherence 비트는 포함되어야 하는 복호화된 ST를 식별하며, 그 순서는 ToB 수수료에 따라 결정됩니다. 복구와 관련된 추가적인 세부 사항은 4.5절에서 설명합니다.

따라서 구체적으로 DistributedExecutionPayloadEnvelope 는 ExecutionPayload 헤더 필드( block_hash 다시 계산하는 데 필요한 모든 것)를 반영하지만 IL에서 가져온 트랜잭션의 경우 포인터( ILTransactionPointer )에 의존하고 ST 티켓 및 복호화된 ST를 재구성하는 데 ABB에 의존합니다.

4.2 합의 표현

실행 페이로드의 합의 표현은 st_tickets 및 decrypted_transactions 라는 두 개의 추가 목록으로 확장됩니다.

`st_tickets`

st_tickets 는 블록 처리 시작 시 청구되는 서명된 ST 티켓 목록이며, 보류 중인(즉, 아직 청구되지 않은) ST 커밋 집합에 해당합니다. 빌더는 decrypt=1 로 설정한 모든 ST 티켓을 ABB의 ST 커밋에 포함해야 합니다. 복구(섹션 4.5) 시, 빌더는 결정론적 필터링(중복 제거, 논스 실행 가능성, 청구 가능성) 후 남은, 관련 상위 ABB의 보류 중인 ST 커밋에 해당하는 decrypt = 1 1 ST 티켓만 포함해야 합니다.

st_tickets 목록은 정규 순서를 따릅니다. 이 목록은 스케줄링 ABB의 IL_data committee_index 으로 스캔한 다음 commit_index 순으로 commits[] 스캔하고 (번들의 경우) tx_index 순으로 entries를 스캔한 후 결정론적 필터링 후 남은 각 항목에 대해 ST 티켓을 포함하여 구성됩니다.

`decrypted_transactions`

decrypted_transactions 는 현재 블록에서 ToB 방식으로 실행된 복호화된 ToB 트랜잭션 목록입니다. 각 항목에는 (ticket_index, plaintext_tx, ToB_fee_per_gas) 가 포함되며, ticket_index 는 현재 복호화 중인 트랜잭션을 예약한 블록(일반적으로 이전 블록)의 st_tickets 에 대한 인덱스입니다. ticket_index 블록 처리 시 경량 포인터로 포함되며, decrypted_transactions 에 동일한 ticket_index 두 번 이상 나타나면 해당 블록은 유효하지 않습니다. 두 세트의 st_tickets (섹션 4.5)가 동일한 decrypted_transactions 목록을 가리키는 경우, 나중에 생성된 st_tickets 의 인덱스를 len(st_tickets) 부터 시작하여 ticket_index 에 번호를 매깁니다.

해당 항목은 hash_tree_root(RevealCommitmentPreimage(t.from, t.nonce, plaintext_tx, ToB_fee_per_gas)) == t.reveal_commitment ( t = st_tickets[ticket_index] 인 경우에만 유효합니다. ToB 정렬 순서는 ToB_fee_per_gas 감소하는 순서로 이루어져야 하며, 동점일 경우 ticket_index 기준으로 결정하고, nonce 순서 때문에 실행할 수 없는 항목은 건너뜁니다.

합의 표현의 속성

일반 transactions 목록은 현재 실행 페이로드 형식과 마찬가지로 전체 트랜잭션 바이트 목록으로 유지됩니다. 비콘 블록에는 전체 페이로드를 확정하는 SignedExecutionPayloadBid 가 포함되어 있으며, 특히 EIP-7732에서처럼 block_hash 통해 확정됩니다. 포인터 기반 페이로드 형식은 임시 네트워크 최적화 용도로만 사용됩니다. 노드는 전체 ExecutionPayload 로컬에서 재구성하고, 확정된 헤더와 비교하여 결과 block_hash 계산/검증한 다음, 실행 계층 클라이언트가 평소처럼 전체 트랜잭션 데이터를 실행하고 저장합니다. 동기화는 전체 블록을 대상으로 수행되며, 포인터는 합의 객체의 일부가 되지 않습니다.

4.3 ABB의 IL 기본 약정은 모호성을 방지하기 위한 것입니다.

포함자는 블록 생성 시점에 여러 개의 IL(Includer Interpreter)을 전파할 수 있습니다. 빌더는 페이로드를 커밋하기 전에 이러한 IL 중 하나만 관찰하고 해당 IL의 트랜잭션을 포함하기로 결정할 수 있습니다. 네트워크의 노드가 포함자가 전파한 IL과 다른 IL을 관찰하여 빌더가 어떤 IL을 참조했는지에 대한 모호성이 발생할 위험이 있습니다. 따라서 빌더는 ABB(Analytic Bia Block)에 각 포함자에 대한 32바이트 SSZ IL_root 포함시켜 각 포함자로부터 고유한 "표준" IL을 정의합니다. 특히, 분산 페이로드가 ILTransactionPointer(committee_index=i, ...) 통해 위원회 구성원 i 의 트랜잭션을 참조하는 경우, 비콘 블록에 포함된 ABB에는 i 에 대한 비어 있지 않은 IL_root 포함되어야 합니다.

빌더가 인클루더로부터 IL을 관찰하지 못한 경우, 해당 항목 전체를 비워둡니다. 빌더는 페이로드 내용을 공개하기 전에 난독화하기 위해 참조하지 않을 관찰된 IL의 루트를 블록에 포함할 수 있지만, 생략할 수도 있습니다.

노드는 모호한 경우에도 항상 정규 IL을 전달하도록 지시받습니다(모호함을 나타내는 추가 IL 하나와 함께). 노드가 동일한 포함자로부터 이미 두 개의 IL을 전달한 상태에서 세 번째 IL이 정규 IL임을 알게 되면, 해당 IL을 수신하는 즉시 세 번째 IL도 전달합니다. 빌더는 입찰 공고 후 모호한 상황을 발견하면 정규 IL을 다시 시드합니다. 포함자에게 모호한 상황에 대한 불이익을 주는 것은 여전히 가능하며, IL의 DA(데이터 액세스)의 중요성이 높아진 DPP(데이터 보호 정책) 하에서는 이러한 조치가 더욱 적절해 보입니다.

4.4 탑재체 재구성

복잡성은 CL 클라이언트 내부에 캡슐화되어 있습니다. 워크플로는 다음과 같습니다.

IL 수신: CL 클라이언트는 P2P를 통해 IL을 수신하고 IL_root 키로 사용하는 로컬 캐시에 저장합니다.
페이로드 수신: SignedDistributedExecutionPayloadEnvelope )를 수신하고, 빌더 서명을 검증하며, 해당 봉투의 (slot, beacon_block_root, builder_index, block_hash) 비콘 블록에 커밋된 서명된 실행 페이로드 입찰 SignedExecutionPayloadBid 과 일치하는지 확인합니다.
해상도 및 재구성:
- 클라이언트는 비콘 블록의 ABB에서 committee_index 에 대한 정규 IL_root 조회하고, 캐시에서 해당 IL을 가져오고(없으면 요청), tx_index 에서 전체 트랜잭션을 읽어 모든 ILTransactionPointer 항목을 해결합니다. 그런 다음 각 IL 트랜잭션을 최종 목록의 고유한 position 에 삽입하여 이러한 트랜잭션을 봉투의 전체 transactions 과 병합합니다.
- 클라이언트는 스케줄링 ABB(일반적으로 현재 슬롯의 ABB, 복구 시에는 요금이 부과되지 않은 상위 ABB)로부터 st_tickets 결정론적으로 구성합니다. 클라이언트는 IL_data → commits[] ->(bundle tx_index )를 정규 순서로 스캔하고, 결정론적 필터링 규칙(중복 제거, nonce 실행 가능성, 요금 부과 가능성)을 적용한 후, 해당 SealedTransaction 바이트를 가져오고, 나머지 각 항목에 대한 ST 티켓을 추출합니다.
- 클라이언트는 해당 블록에 대해 복호화가 필요한 ST 커밋으로부터 decrypted_transactions 을 결정론적으로 구성하고 정렬합니다. 정상 작동 시에는 상위 블록의 예정된 ST 커밋이 사용되며, 복구 시에는 가장 최근의 전체 상위 블록과 첫 번째 빈 블록의 커밋이 모두 포함될 수 있습니다(섹션 4.5). ABB가 준수하는 유효한 해제 키 메시지가 있는 각 커밋에 대해, 클라이언트는 복호화를 통해 RevealedTransaction(plaintext_tx, ToB_fee_per_gas) 얻고, 해당 청구 티켓 t 를 식별한 후 hash_tree_root(RevealCommitmentPreimage(t.from, t.nonce, plaintext_tx, ToB_fee_per_gas)) == t.reveal_commitment 검증합니다. 그런 다음 st_tickets 에 t 의 ticket_index 포함하는 decrypted_transactions ) 항목을 생성합니다. 마지막으로, ToB_fee_per_gas 감소하는 순서대로 정렬하고, 동점일 경우 ticket_index 기준으로 처리하며, 해당 순서대로 거래별 지불 가능성 검사를 적용합니다(검사에 실패한 항목은 제외).
검증: 클라이언트는 결과 block_hash 계산하고 비콘 블록의 SignedExecutionPayloadBid 와 비교하여 검증합니다.
실행: 클라이언트는 완전히 구성된 ExecutionPayload 엔진 API( engine_newPayload )에 전달합니다.
PTC 투표: 노드들은 누락된 IL/ST 바이트/키를 계속 가져와 새 데이터가 도착하면 재구성을 재시도합니다. PTC 구성원은 T_4 시점 에 페이 로드를 완전히 재구성하고 block_hash 검증한 경우에만 "적시" 투표를 하고, 그렇지 않으면 "적시하지 않음" 투표를 합니다.

4.5 거부된 페이로드에 대한 복구

송신자는 비콘 블록의 ABB(Analytic Hierarchy Block)에 ST 커밋먼트에 대한 올바른 gas_obligation 항목이 지정되어 있고, 모든 gas_obligation 항목의 합계가 ToB_gas_limit 내에 있으며, ST 커밋먼트와 복호화 키를 사용할 수 있는 경우, 복호화된 트랜잭션을 다음 블록에 포함할 권리가 있습니다. 그러나 복호화 키가 공개된 후 송신자나 복호화자의 잘못이 아닌 이유로 페이로드 n 이 거부될 수 있습니다. 이 경우 다음 페이로드에는 페이로드 n 에 대해 예약된 복호화된 ST와 슬롯 n + 1 에 대해 예약 되었지만 키가 공개된 ST가 모두 포함되어야 합니다.

구체적으로, 블록의 복호화된 ST는 다음과 같은 ST입니다.

ST 바이트와 키를 사용할 수 있습니다.
정확하게 지정된 ABB에 나열되었으며, 해당 ABB는
- 현재 슬롯의 ABB가 아닙니다.
- 아직 복호화된 ST 커밋이 온체인에 포함되지 않았습니다.

따라서 블록이 비어 있는 경우(페이로드가 없는 경우), 다음 페이로드에는 해당 빈 블록에 포함되었어야 할 복호화된 ST와 빈 블록이 ABB에서 커밋한 (이제 복호화된) ST가 모두 포함되어야 합니다. 복구 페이로드는 (Potuz가 제안한 것처럼 ) 새로운 ST를 커밋할 수 없으며, 대신 key_adherence 비트를 사용하여 빈 블록의 ST 커밋이 현재 사용 가능한지(바이트+키) 여부를 나타내야 합니다. 이 비트는 복구 시 복호화된 ST와 동일한 페이로드에 포함되어야 하는 ST 티켓에 대해서도 플래그를 지정합니다. 블록에 복호화된 ST가 포함되지 않아 체인이 복구되지 않으면 해당 블록은 빈 블록으로 간주되어 다음 페이로드가 다시 복구해야 합니다.

기본 사양에서 복호화된 ST는 가스 제한의 최대 1/4까지만 할당됩니다. 이는 페이로드 전송이 누락되더라도 다음 페이로드에는 복호화된 ST 세트를 두 개 포함할 수 있도록 하며, 이 경우 블록의 가스 제한의 최대 1/2만 소비하게 됩니다.

5. LUCID에서 선택 가능한 옵션을 확인하세요

봉인된 거래 확정-공개 방식에서 발생할 수 있는 문제점 중 하나는 공개 여부를 선택적으로 결정할 수 있다는 점입니다. 일부 봉인된 거래는 예를 들어 중앙거래소(CEX) 가격 변동을 역추적하는 데 사용될 수 있습니다.

섹터:

메타버스

스마트 컨트랙트

레이어 1

출처

면책조항: 상기 내용은 작자의 개인적인 의견입니다. 따라서 이는 Followin의 입장과 무관하며 Followin과 관련된 어떠한 투자 제안도 구성하지 않습니다.

라이크

즐겨찾기에 추가

코멘트