요약
신뢰할 수 있는 사전 협의 프로토콜은 제안자가 블록에 서명하기 전에 자신의 약속이 이행되었는지 검증하도록 요구합니다. 전체 블록 본문을 검사하는 단순한 접근 방식은 빌더의 블록을 노출시키므로 문제가 됩니다. 릴레이가 이러한 문제를 해결할 수 있지만, ePBS 이후에는 필수 사항이 아닙니다. 신뢰할 수 없는 해결책은 빌더가 입찰과 함께 제약 조건 충족 증명을 제출하는 것입니다. 하지만 이 방식의 단점은 증명 생성 과정에서 특히 제약 조건이 단순한 트랜잭션 포함을 넘어 복잡해질 경우 중요한 경로에 지연 시간이 추가된다는 것입니다.
EIP-7928 BAL은 구조화된 대안을 제공합니다. BAL은 실행의 부산물로 생성되어 블록 헤더에 기록되는 블록 내 모든 상태 기록의 완전한 레코드입니다. 모든 BAL 항목은 동일한 구조를 가지므로, 모든 사전 구성 유형은 동일한 객체에 대한 참/거짓 질의로 축소될 수 있습니다. 단일 검증 언어로 모든 사전 구성 유형(포함, 실행, 순서, 제외 등)을 처리할 수 있으며, 단일 검증 함수로 재배포 없이 모든 유형을 처리할 수 있습니다. 새로운 사전 구성 유형은 동일한 인프라로 검증 가능한 새로운 공식이 됩니다. 이는 머클 증명을 통해 가능한 보장 수준을 엄격하게 향상시키면서 지연 시간과 복잡성을 줄입니다.
배경
사전 확정(Preconf)은 제안자가 블록이 생성되기 전에 특정 속성이 다음 블록에서 유지될 것이라고 확정하는 기능입니다. 사용자는 자신의 거래가 블록에 포함될 것이라는 보장, 특정 값이 특정 저장 슬롯에 기록될 것이라는 보장, 또는 특정 임계값 이상의 결제가 블록에 포함될 것이라는 보장을 담은 사전 확정을 받을 수 있습니다.
제안자가 제시하는 약정은 블록이 어떻게 생성되어야 하는지에 대한 제약을 갖습니다. 현재와 같이 제약 조건이 없는 경우, 블록 생성자는 제안자에게 어떤 블록이든 자유롭게 제시할 수 있습니다. 하지만 포함 사전 약정(inclusion preconfs)과 같은 제약 조건이 있다면, 블록 생성자는 지정된 트랜잭션을 포함하는 블록만을 제시해야 합니다.
블록을 생성하기 전에 제안자는 해당 블록이 모든 제약 조건을 충족하는지 확인할 수 있는 방법이 필요합니다. 그래야만 제안자가 약속한 내용이 제대로 이행될 수 있습니다. 여기서 중요한 차이점은 약속은 사용자에게 공개되는 반면, 제약 조건은 블록 생성자에게 공개된다는 점입니다.
검증 문제
가장 확실한 방법은 제안자가 블록 전체를 직접 검사하는 것입니다. 블록이 조건을 충족하면 제안자가 서명하는 것이죠. 하지만 이 방법은 제안자가 건설업자에게 비용을 지불하지 않고 블록을 가로챌 수 있게 되므로 현실적으로 불가능합니다.
릴레이는 이미 오늘날 이러한 공정한 교환 문제를 해결하고 있습니다. 비관적 릴레이 방식에서는 릴레이가 블록을 완전히 실행한 후 헤더를 제안자에게 전달하여 서명을 받으며, 이를 확장하여 신뢰 서비스로서 사전 구성 제약 조건을 검증할 수도 있습니다. 또 다른 대안은 낙관적 릴레이 방식인데, 이 방식에서는 릴레이가 블록을 완전히 실행하지 않고 헤더만 전달하며, 대신 사후 오류 귀속에 의존합니다. 빌더의 블록이 나중에 유효하지 않거나 제약 조건을 위반하는 것으로 판명되면 해당 빌더에게 불이익이 주어집니다. 두 방식 모두 현재 실제 운영 환경에서 사용되고 있습니다. 하지만 릴레이를 핵심 경로에서 완전히 제거하는 ePBS(electronic Public Statement Signing) 방식에서는 두 방식 모두 더 이상 유효하지 않습니다.
신뢰할 수 없는 대안은 블록 생성자가 입찰과 함께 제약 조건 만족 증명을 생성하는 것입니다. 가장 간단한 형태는 블록 헤더에 커밋된 트라이 루트에 대한 머클 포함 증명입니다. 블록 생성자는 전체 블록 본문을 공개하지 않고도 특정 트랜잭션이 포함되었거나 특정 저장 슬롯이 블록 끝에서 특정 값으로 설정되었음을 증명할 수 있습니다.
한 가지 문제는 지연 시간입니다. 증명 생성은 블록 생성이 완료된 후에 이루어집니다. 사전 구성 제약 조건의 수가 증가함에 따라 증명 생성은 블록 생성과 입찰 제출 사이의 핵심 경로에서 중요한 단계가 됩니다. 매 밀리초마다 귀중한 생성 시간이 낭비되어 제안자의 수익에 악영향을 미칩니다.
또 다른 문제는 표현력입니다. 머클 증명은 블록 수준입니다. 즉, 트랜잭션이 포함되었는지 또는 상태 슬롯에 특정 값이 저장되었는지 증명할 수는 있지만, 트랜잭션 수준의 상태 차이를 증명할 수는 없습니다. 특정 트랜잭션이 특정 상태 변화를 일으켰다는 머클 증명은 존재하지 않습니다. 상태 저장 사전 구성을 검증하려면 전체 재실행이나 영지식 증명이 필요한데, 이는 개인정보 보호나 지연 시간 문제 때문에 현실적으로 불가능합니다.
차단 액세스 목록이 제공하는 기능
EIP-7928은 블록 수준 접근 목록(BAL)을 블록 실행 중에 접근한 모든 계정 및 저장 위치에 대한 완전한 기록으로 정의합니다. 각 BAL은 block_access_list_hash 를 통해 특정 입찰/블록에 연결되며, BAL을 재생하면 실제 트랜잭션을 실행하지 않고도 누구나 블록의 최종 상태를 다시 계산할 수 있습니다.
사전 회의 맥락에서 이는 두 가지 주요 이유 때문에 유용합니다.
1. BAL(블록 접근 인덱스)은 블록 실행의 직접적인 부산물입니다. 별도의 증명 생성 단계는 없습니다. 블록 생성자는 블록이 생성될 때 이미 BAL을 가지고 있습니다. BAL에는 블록 생성 중에 발생한 모든 상태 기록(저장 슬롯 값, 잔액 변동, 논스 증가, 코드 업데이트)이 기록되며, 각 기록에는 전역 쓰기 순서를 나타내는 block_access_index 태그로 지정됩니다. 따라서 제안자는 상태 결과에 대한 모든 속성을 직접 검증할 수 있습니다. 예를 들어 슬롯에 어떤 값이 기록되었는지, 계정 잔액이 임계값을 초과했는지, 논스가 증가했는지, 두 쓰기 작업이 특정 순서로 발생했는지, 또는 계약이 변경되었는지 등을 확인할 수 있습니다. 이러한 모든 검증에는 트랜잭션 검사가 필요하지 않습니다.
2. BAL은 블록 내용을 유출하지 않고도 검증할 수 있습니다. 블록을 재구성하려면 실제 서명된 거래와 그 입력값이 필요한데, BAL에는 이러한 정보가 누락되어 있습니다. BAL만 검사하는 제안자는 블록 생성자에게 비용을 지불하지 않고는 블록을 재구성하여 다시 제출할 수 있는 정보를 얻을 수 없습니다. 그러나 모든 거래가 공개 멤풀에서 발생한 경우, 의도적인 제안자는 원칙적으로 공개 정보만으로 블록을 재구성할 수 있습니다(하지만 이 경우 제안자는 생성자의 BAL 없이도 동일한 블록을 직접 생성할 수 있습니다). 비공개 주문 흐름을 가진 블록은 재구성할 수 없습니다.
거래 약정에서 결과 사전 합의까지
현재의 사전 구성 접근 방식은 특정 서명된 트랜잭션에 대한 약속을 합니다. 결과 기반 사전 구성은 트랜잭션에서 벗어나 상태에 대한 약속에만 초점을 맞춥니다.
오늘날의 인텐트 방식에서는 " X 최소 Y 로 교환"과 같은 특정 결과를 지정하면, 솔버들이 맞춤형 솔루션을 찾기 위해 경쟁하고, 최종적으로 스마트 계약이 인텐트가 충족되었는지 검증합니다. 결과 사전 구성 방식도 제안자 계층에서 동일한 모델을 적용합니다. 제안자가 "슬롯 S 에 대한 첫 번째 쓰기는 값 V 될 것이다"라고 커밋할 때, 이는 실행 경로가 아닌 상태 결과를 커밋하는 것입니다. 빌더는 어떤 트랜잭션이 쓰기를 발생시키는지, 누가 보냈는지, 어떤 가스를 소비했는지 등에 대한 제약 조건이 없으므로, 유효한 트랜잭션 시퀀스를 통해 이 제약 조건을 충족할 수 있습니다.
간단히 말해, 제안자는 블록의 원하는 결과를 표현하고, 빌더들은 그 결과를 달성할 수 있는 유효한 실행 경로를 찾기 위해 경쟁하며, 제안자는 블록에 커밋하기 전에 (블록 내용을 유출하지 않고) (BAL을 통해) 결과가 달성되었는지 검증합니다.
통일된 제약 조건 언어
BAL은 모든 결과 사전 구성 유형을 검증할 수 있는 단일 구조입니다. 이는 각 유형이 고유한 설계 문제를 안고 있는 현재의 사전 구성 방식과는 크게 다른 점입니다. 포함 사전 구성에는 하나의 증명 형식이 필요하고, 순서 제약 조건에는 또 다른 형식이 필요하며, 실행 사전 구성에는 또 다른 형식이 필요합니다. 새로운 유형이 추가될 때마다 제안자를 위한 새로운 검증 로직과 새로운 온체인 슬래싱 인프라가 요구됩니다. 새로운 사전 구성 유형을 추가한다는 것은 스택의 모든 계층에 걸쳐 조정된 업그레이드가 필요하다는 것을 의미합니다.
모든 BAL 항목은 동일한 네 가지 필드(주소, 필드 유형, 기록된 값, 순서 인덱스)를 공유하므로 사전 구성 결과 검증은 다음과 같은 참/거짓 질문으로 귀결됩니다. 이러한 속성을 가진 쓰기 작업이 존재하는가? 이 주소가 없는가? 쓰기 A 쓰기 B 보다 먼저 발생했는가?
1차 논리(FOL)는 고정된 객체 집합에 대해 참/거짓 명제를 정확하게 표현하기 위한 형식 언어입니다. FOL은 잘 알려져 있으며 유한 구조에 대해 완전성을 갖습니다. 즉, 고정된 스키마를 가진 논리 배열(BAL)에 대해 일반 영어로 표현할 수 있는 모든 부울 속성은 FOL 공식으로 표현할 수 있습니다.
실질적으로 필요한 검증자는 단 하나뿐입니다. 이 검증자는 1차 논리(FOL) 공식과 잔액 목록(BAL)을 입력으로 받아 참 또는 거짓을 반환합니다. 검증자 함수는 한 번만 구축되며(일반 입찰 흐름의 경우 제안자 측 사이드카에, 분쟁 해결을 위한 슬래싱 계약에) 이후에는 변경할 필요가 없습니다. 새로운 사전 구성 유형이 추가되면 새로운 인프라를 구축하는 것이 아니라 새로운 FOL 공식을 작성하기만 하면 됩니다.
이 언어는 두 가지 범주의 기본 요소를 가지고 있습니다. 비교 연산은 가장 기본적인 요소로, 일치하는 항목의 값에 적용되는 필드 같음, 다름, 순서 검사( == , >= , < 등)를 포함합니다. 논리 연결자는 "…을 만족하는 항목이 존재한다", "두 조건 모두 충족된다", "이 조건은 충족되지 않는다"와 같은 구조를 나타냅니다. 이는 단 하나의 게이트 유형으로 논리 회로를 구성하는 것과 같은 원리로, 최소한의 기본 요소만으로 무한한 표현력을 얻을 수 있습니다.
탈중앙화 애플리케이션(DApp)은 사용자를 대신하여 공식을 계산해야 합니다. 여기에는 사용자의 거래에 영향을 받는 저장 위치와 잔액 관리 목록(BAL)에서 확인해야 할 관련 위치를 파악하는 작업이 포함됩니다. 산술적 제약 조건("잔액이 Y 만큼 증가", "가격이 5% 이내", "nonce 증가")의 경우, DApp은 이러한 힌트를 공식에 직접 제공하므로 언어 자체에서 산술 연산을 지원할 필요가 없습니다. 구체적으로, 앨리스의 nonce가 5 이고 USDC 잔액이 500 이며, 그녀가 최소 2000 USDC를 받으려는 경우, DApp은 사전 상태를 읽고 6 과 2500 계산한 다음, nonce == 6 이고 balance >= 2500 인지 확인하는 간단한 공식을 구성합니다.
결과 사전 구성 패턴 및 L1 UX
다음 각 패턴은 BAL에 대한 수식입니다. 동일한 검증자가 모든 패턴을 처리합니다. 이러한 패턴은 예시를 위한 것이며 완전하지 않을 수 있습니다. 아래 수식에서 (A, Nonce) 와 (A, Balance) 는 계정 A 의 nonce 및 ETH 잔액 필드를 나타내고, (C, S) 는 계약 C 의 스토리지 슬롯 S 를 나타내며, V 예상되는 값입니다. 이러한 값들은 BAL 항목의 필드 유형에 직접적으로 대응합니다.
블록 포함 보장. 앨리스는 밥에게 보낸 이더리움(ETH) 이체가 다음 블록에 포함되기를 원합니다. 앨리스의 논스(nonce) 증가는 거래가 실행되었음을 확인시켜주고, 밥의 잔액 증가는 결제가 완료되었음을 확인시켜줍니다. 두 기록은 동일한 거래에서 발생했음을 확인하기 위해 동일한 block_access_index 공유해야 합니다. 탈중앙화 애플리케이션(dApp)은 공식을 구성하기 전에 상위 상태 루트에서 절대적인 사후 상태 값을 계산합니다.
there exists a write to ( Alice, Nonce ) with value == n+ 1 [call this e1] AND there exists a write to ( Bob, Balance ) with value > = bob_pre_balance + amount AND index == e1.index 블록 최상단. 사용자의 트랜잭션은 블록에서 첫 번째 사용자 트랜잭션이어야 합니다. block_access_index 트랜잭션별로 할당되며, 인덱스 0 실행 전 시스템 계약 쓰기(예: EIP-4788 비콘 루트 업데이트)를 위해 예약되어 있고, 사용자 트랜잭션에는 1 부터 시작하는 인덱스가 할당됩니다. 이는 가장 강력한 순서 보장 방식이며, 그에 상응하는 가격이 책정되어야 합니다.
there exists a write to (Alice, Nonce) with value == n+ 1 AND index == 1 AND there exists a write to (C, S) with value == V AND index == 1 최초 계약 접근 권한. 사용자는 특정 계약과 가장 먼저 상호 작용하고 싶지만, 블록 최상단에 대한 비용을 지불하고 싶지는 않습니다. 대표적인 예는 NFT 발행입니다. 다른 모든 작업과는 상관없이, 발행 함수를 가장 먼저 호출하는 것이 목표입니다. 이 검사는 전적으로 계약 C 의 항목에만 적용되므로, 빌더는 나머지 모든 작업 순서를 자유롭게 정할 수 있습니다.
there exists a write to (C, S) with value == VAND its index is less than or equal to every other write to C 동일 슬롯 의도 정산. 사용자가 "내 X ETH를 최소 Y USDC로 교환"이라는 의도를 서명하지만, 어떻게 처리될지는 지정하지 않습니다. 빌더는 사용자의 의도 거래와 솔버의 이행 거래를 모두 포함합니다. 공식의 순서 제약 조건은 솔버가 지급하기 전에 의도가 실행되도록 보장합니다. 중요한 것은, 건전한 빌더 경쟁이 사용자의 결과를 개선하는 데 중요하다는 점입니다.
there exists a write to ( A, Nonce ) with value == n+ 1 [call this e1] AND there exists a write to ( A, ETH_Balance ) with value < = eth_pre_balance - X AND index == e1. indexAND there exists a write to ( A, USDC_Balance ) with value > = Y [call this e2]AND e1.index < e2.index실행 결과는 사전 협의를 통해 확인됩니다. 과거에는 특정 사후 상태를 보장하기 위해 EVM 실행에 대한 영지식 증명이 필요했습니다. BAL(Balanced Logging)을 사용하면 논스(nonce) 증가를 통해 사용자 트랜잭션이 실행되었음을 확인할 수 있으며, 스토리지 슬롯 검사를 통해 예상되는 상태 변화를 확인할 수 있습니다. 두 쓰기 작업이 동일한 트랜잭션에서 발생했음을 확인하기 위해 동일한 인덱스를 공유해야 합니다. 재실행은 필요하지 않습니다.
there exists a write to ( A, Nonce ) with value == n+ 1 [call this e1] AND there exists a write to ( C, S ) with value == V AND index == e1.index 위의 패턴들은 자유롭게 조합될 수 있습니다. 블록 최상단 보장은 nonce 검사에 index == 1 추가함으로써 동일 슬롯 의도 합의에 적용될 수 있습니다. 실행 결과는 순서 제약 조건과 결합될 수 있습니다. 위의 모든 조합은 유효한 공식이며 동일한 검증 함수를 사용하여 검증됩니다.
ePBS를 활용한 결과 사전 회의
결과 사전 조건은 특정 거래가 아닌 결과에 초점을 맞추기 때문에, 이를 충족하는 것은 시장 경쟁이 됩니다. 여러 검색자가 독립적으로 경쟁하여 주어진 사전 조건을 충족할 수 있으며, 빌더는 최적의 번들을 선택합니다. 어느 한쪽 당사자가 다른 쪽 당사자의 실행 전략을 볼 필요는 없습니다. 아래 순서는 이러한 방식이 ePBS 이후 입찰 흐름에 어떻게 적용되는지를 보여줍니다.
참고로, 빌더가 서명한 제약 조건 약정은 온체인 흐름에 영향을 미치지 않습니다. 그 목적은 프로토콜 외부에 있으며, 빌더가 제약 조건에 서명한 후 이를 위반하는 BAL을 제출하면 자신의 잘못에 대한 암호화 증거를 생성하게 되고, 외부 슬래싱 또는 평판 시스템이 이를 기반으로 조치를 취할 수 있습니다.
제약 조건 검증 단계는 제안자의 사이드카에서 실행됩니다. 사이드카는 슬래싱 계약에 배포된 것과 동일한 검증 로직의 오프체인 구현체입니다. 두 단계는 구조적으로 동일하므로, 제안자는 분쟁 발생 시 슬래싱 계약이 나중에 수행할 것과 동일한 검사를 확인합니다.
또한 ePBS 사양에서 빌더의 입찰에는 헤더 자체가 아닌 block_hash 커밋먼트가 포함되어 있다는 점에 유의하십시오. 따라서 제안자는 BAL → block_access_list_hash → 헤더 → block_hash → 입찰로 이어지는 신뢰 체인을 구축해야 합니다.
제한 사항
BAL은 기본 거래에 유효한 서명이 있음을 증명하지 않습니다. 빌더는 모든 결과 사전 구성 검사를 만족하지만 유효하지 않거나 위조된 거래에 해당하는 BAL을 구성할 수 있습니다. 페이로드가 공개되면 유효성 검사에 실패하고 제안자는 슬롯을 놓치게 됩니다. 다행히 제안자는 ePBS 이후에도 입찰 금액을 무조건적으로 지급받습니다.
이러한 건설자 행동을 억제할 수 있는 프로토콜 외적인 제재 메커니즘이 없다면, 사전 협의된 약속을 어기는 행위가 금전적 이득으로 이어질 경우 건설자가 자유 선택권을 행사하도록 더욱 부추길 수 있습니다. 건설자 또는 여러 당사자가 제약 조건에 동의하도록 하는 것이 이러한 메커니즘을 향한 한 걸음입니다.
BAL을 분쟁 증거로 활용
사전 협의 결과에 대한 분쟁이 온체인 판정 단계에 도달하면, 각 제약 조건은 독립적으로 이의를 제기할 수 있습니다. 이의를 제기하는 당사자는 위반된 제약 조건, 제안자의 서명, 빌더의 서명된 커밋먼트, BAL(블록 접근 목록) 및 블록 헤더를 제공합니다. 슬래싱 계약은 block_access_list_hash 사용하여 BAL을 인증하고, 제안자의 사이드카가 일반 검증 과정에서 실행했던 것과 동일한 검증기를 실행합니다. 검증기가 false를 반환하면 위반이 입증된 것으로 간주합니다.
1차 논리(FOL) 공식 구조는 지키 증명(ZK 증명)에 매우 적합합니다. 고정 스키마 BAL에 대한 질의는 임의의 EVM 실행보다 증명 비용이 훨씬 저렴하므로, 확정된 BAL 루트에 대한 지키 증명은 향후 최적화 방안으로 유력합니다.
신성함을 향한 길
본 논문에 설명된 설계는 프로토콜을 완전히 벗어난 방식입니다. 제안자와 건설자의 약속은 경제적 인센티브와 프로토콜을 벗어난 슬래싱을 통해 강제됩니다. 결과 사전 합의를 위반하는 블록이라도 네트워크 관점에서는 여전히 유효한 블록으로 간주됩니다.
이를 프로토콜 내에 구현할 수 있는 타당한 방안이 있습니다. PEPC는 프로토콜에 의해 강제되는 제안자 커밋먼트의 필요성을 인식했지만, 커밋먼트 표현 방식에 대해서는 EVM 실행, SNARK 또는 다른 구조를 사용할지 여부를 결정하지 못했고, 데이터 가용성 문제도 지적했습니다. 즉, 제3자가 검증자가 확인할 수 있는 방식으로 커밋먼트 증명을 어떻게 제공해야 할까요? BAL은 블록 헤더에 이미 커밋된 일급 객체이므로 별도의 증명 전달 메커니즘이 필요하지 않아 이 두 가지 문제를 모두 해결할 수 있습니다. 1차 논리 제약 조건 언어는 간결하고 명확하게 정의되어 있으며, 검증자는 합의 계층에 배포 가능한 단일 함수입니다. 검증자가 커밋먼트 코드를 다시 실행하는 대신, 프로토콜은 인증된 BAL을 사용하여 1차 논리 공식을 직접 검증할 수 있습니다.
이것이 프로토콜에 따라 작동하려면 몇 가지 추가 요소가 충족되어야 합니다.
구속력 있는 약정 방송. 제안자의 제약 조건은 입찰 과정 전에 변경 불가능하고 출처를 명확히 알 수 있는 방식으로 공개되어야 합니다. PTC와 유사하지만 제약 조건에 관한 것입니다.
입찰서와 함께 BAL 및 헤더가 제출됩니다. 제안자가 서명 전에 제약 조건을 확인할 수 있도록, 시공사는 입찰서와 함께 BAL 및 헤더를 제출해야 합니다. 현재 이는 ePBS 사양에 포함되어 있지 않습니다.
유효하지 않은 BAL에 대한 건설업체의 벌칙. 입찰서와 함께 제출된 BAL이 최종적으로 공개된 블록과 일치하지 않거나, 공개된 블록이 유효성을 검증하지 못하는 경우, 건설업체는 벌칙을 받아야 합니다. ePBS 도입 이후, 건설업체는 이미 담보를 제공해야 하므로 상당한 준비는 이미 완료된 상태입니다.
요약
ePBS에서는 릴레이가 필수적이지 않으므로 이를 신뢰할 수 있는 사전 구성 검증자로 다시 도입하는 것은 이상적이지 않습니다. 머클 증명은 신뢰할 수 없는 대안을 제공하지만 중요 경로에 지연 시간을 추가하고 상태 저장 또는 제외 제약 조건을 표현할 수 없습니다. BAL은 이 두 가지 문제를 모두 해결합니다. BAL은 블록 실행의 부산물로 생성되어 추가 지연 시간이 없으며, 트랜잭션 수준에서 의도 수준으로 커밋을 전환함으로써 모든 사전 구성 유형을 동일한 BAL 구조에 대한 공식으로 축소할 수 있습니다. 이러한 표현 가능성은 중요 경로에 ZK 증명을 요구하지 않으며, 새로운 사전 구성 유형을 추가하더라도 검증자 또는 슬래싱 인프라를 변경할 필요가 없습니다.
