토론 과 피드백을 해주신 토니 와 라디슬라우스 에게 감사드립니다 .
이더리움 개선 제안(EIP)-7928은 L1에서의 병렬 실행을 개선하기 위해 블록 수준 액세스 목록(BAL)을 도입합니다. 확장성 외에도 BAL은 제안자 커밋 프로토콜, 특히 실행 사전 설정(preconf) 을 위한 더욱 간소화된 기반을 제공합니다. 여러 머클 패트리샤 트라이에 걸친 단편화된 증명에 의존하는 대신, BAL은 커밋이 연결될 수 있는 모든 트랜잭션 이후 값에 대한 표준 레코드를 제공합니다.
하지만 현재 이더리움 개선 제안(EIP)-7928 사양은 효율적인 EVM 수준의 증명에 직접적으로 적합하지 않습니다. 이 글은 사전 설정(preconf)에 BAL을 사용하도록 유도하고, 증명 친화적으로 만들기 위해 제안된 사양 변경 사항을 강조하며, Discord에서 논의 중인 복잡성 상충 관계를 간략하게 설명합니다.
동기 부여
실행 사전 설정(Execution Preconf)을 통해 제안자(또는 위임자)는 거래 결과가 체인에 적용되기 전에 사용자에게 거래 결과에 대한 사전 약속을 제공할 수 있습니다. 이를 통해 사전 확인 시간이 사전 설정자에서 사용자에게 전송되는 단 한 번의 "핑"으로 단축되어, 합의 프로토콜보다 빠른 사용자 경험을 제공합니다. 블록 확인을 기다리는 대신, 사용자는 신뢰할 수 있는 실행 사전 설정을 수신하는 순간 안심하고 행동할 수 있습니다.
오늘날 신뢰할 수 있는 약속은 온체인 슬래싱 조건을 본딩된 사전 협의(예: URC )에 적용하기 위해 약속 위반 시 신뢰할 수 있는 방식으로 증명할 수 있어야 합니다. 이러한 증명은 여러 트라이에 분산되어 있습니다. 포함/순서를 위한 거래 트라이, 실행 성공을 위한 영수증 트라이, 논스 또는 잔액 변경을 위한 계좌 트라이, 그리고 저장을 위한 상태 트라이가 그것입니다. 이 방식은 효과적이지만, 단편화 문제가 발생하고, 맞춤형 증명 논리가 필요하며, 세분성이 제한적입니다.
단편화 : 완전한 적용을 위해서는 수정된 상태의 각 부분에 대해 여러 번의 시도를 통해 값을 적용해야 합니다.
논리: 각 커밋은 서로 다른 약속을 하고 서로 다른 상태에 영향을 미치므로 사용자 정의 논리가 필요합니다.
세분성: 시도는 모든 거래를 적용한 후의 상태만 기록하므로 중간 상태 업데이트(예: 네 번째 거래 후의 앨리스의 잔액)는 직접적으로 증명할 수 없습니다.
일부 제안된 설계는 1)과 3) 사후 상태가 사용자가 예상한 것과 다를 경우(예: "1,000 USDC를 최소 0.98 이더리움(ETH) 에 매도") 거래를 되돌리는 방식을 사용합니다. 이는 실용적이지만, 계약 개발자에게 부담을 전가하여 이러한 조건을 수동으로 인코딩해야 합니다. 실제로는 모든 동작에 맞춤형 유효성 조건이 적용되는 인텐트 스타일 프로그래밍과 유사합니다.
BAL은 트랜잭션 수준 상태 차이에 대한 표준 레코드를 제공함으로써 제안자 커밋 프로토콜을 구축하는 더 간단한 기본 방식을 제공합니다. 실행 사전 설정(preconf)은 밸런서(BAL) 의 하위 집합에 대한 커밋으로 표현될 수 있으며, 깨진 커밋은 표준 밸런서(BAL) 에 대해 증명될 수 있습니다. 이를 통해 커밋에 대한 추론, 시행 및 표준화가 간소화되어 프로토콜 설계자와 사용자 모두의 마찰을 줄일 수 있습니다. 결과적으로 BAL을 효과적으로 활용하는 단일 일반 제안자 커밋 프로토콜은 오늘날의 모든 사전 설정 사용 사례를 포괄할 수 있습니다.
오늘날의 BALs
밸런서(BAL) 은 RLP로 인코딩된 List[AccountChanges] 이며, AccountChanges 객체는 주소의 논스, 잔액, 저장소 및/또는 코드에 대한 트랜잭션별 상태 변경 사항을 기록합니다. 모든 AccountChanges 반복적으로 적용함으로써 클라이언트는 영향을 받는 모든 계정이 블록 전체에서 어떻게 변화했는지 결정론적으로, 그리고 병렬로 재구성할 수 있습니다.
이는 실행 사전 설정과 관련된 과제를 해결하는 데 충분합니다.
단편화: 여러 번 시도하는 대신 밸런서(BAL) 만 약속을 해야 함논리: 단일 일반 프로토콜은 의도 스타일 프로그래밍 없이도 오늘날의 모든 사전 구성 사용 사례를 포착하기에 충분합니다.세분성:AccountChanges객체를 사용하면 트랜잭션별 상태 차이에 대한 커밋이 가능합니다.
전류 제한
BAL은 사전 설정 프로토콜을 개선할 가능성이 분명합니다. 하지만 문제는 BAL의 인코딩 방식에 있습니다. 현재 이더리움 개선 제안(EIP)-7928 사양에서는 BAL이 RLP 인코딩되며 블록 헤더에 밸런서(BAL) 해시 포함됩니다.
이로 인해 이더리움 가상 머신(EVM) 에 커밋 위반을 증명하는 것이 번거로워집니다. 사용자는 전체 밸런서(BAL) calldata로 전달하고, 해당 해시 부모 블록 해시 와 비교한 후, 충돌하는 값을 찾기 위해 수동으로 RLP 디코딩해야 합니다. 현재 압축되지 않은 밸런서(BAL) 약 100KB 정도이며, 이는 calldata 제한 내에 있습니다. 커밋 위반은 드물게 발생 하므로 이는 무리한 요구가 아닙니다.
제안된 이더리움 개선 제안(EIP) 변경(더 어려움)
블록과 BAL이 커짐에 따라 밸런서(BAL) 호출 데이터로 전달하는 데 드는 비용은 더욱 커집니다. 제안된 변경 사항은 이더리움 가상 머신(EVM) 에서 밸런서(BAL) 멤버십을 더 쉽게 증명할 수 있도록 합니다.
실행 클라이언트가 SSZ를 사용하여 밸런서(BAL) 인코딩할 가능성이 낮으므로, Toni가 제안한 것처럼 밸런서(BAL) 별도의 MPT로 인코딩하는 것이 대안적인 접근 방식입니다. 블록 헤더에는 해시 대신 밸런서(BAL) 루트가 포함되므로 이더리움 개선 제안(EIP)-2935 부모 해시 대한 효율적인 MPT 증명이 가능합니다.
사전 설정(preconf)에 대한 이상적인 인코딩은 두 단계의 트라이(trie)를 갖는 것입니다. 바깥쪽 트라이는 bal_index (거래 인덱스) 키를 subTrieRoot 값에 매핑하며, 각 bal_index 고유한 거래 인덱스를 나타냅니다. 안쪽 subTrie 다양한 계좌 변경 사항을 모두 포괄하는 고유 키를 포함합니다.
RLP(["balance_change", address])RLP(["storage_change", address, slot])RLP(["nonce_change", address])RLP([“code_change”, address])
RLP로 인코딩된 거래 후 데이터(즉, RLP([uint256]) )를 포함하는 값이 있습니다.
이를 통해 사전 협의자는 거래 후 상태 차이에 대한 간결한 커밋, 즉 주어진 bal_index 에 대한 subTrieRoot 에 대한 서명을 할 수 있습니다. 커밋이 위반되었음을 증명하는 것은 해당 bal_index 의 실제 subTrieRoot 서명된 것과 다르다는 것을 보여주는 것으로 축소됩니다. subTrie 의 개별 계정 변경 사항은 커밋 프로토콜에서 추상화됩니다.
이는 오늘날의 상황보다 훨씬 간단합니다. 현재 사전 협의(preconfer)는 트랜잭션이 접촉하는 모든 위치에 대해 여러 번의 시도를 통해 사후 상태 차이(post-state diff)를 계산해야 합니다. 이제 각 트랜잭션은 깔끔하게 패키징된 단일 subTrieRoot 로 축소됩니다.
그러나 이러한 접근 방식은 EIP의 복잡성을 증가시키는 또 다른 시도를 도입해야 합니다.
제안된 이더리움 개선 제안(EIP) 변경(더 쉬움)
블록 헤더가 여전히 RLP 인코딩된 밸런서(BAL) 해시 에 커밋된다고 가정할 때, 밸런서(BAL) 레이아웃을 약간만 재구성하면 커밋을 크게 단순화할 수 있습니다. 이 제안은 밸런서(BAL) accounts가 아닌 bal_index 로 인덱싱하여 밸런서(BAL) 인코딩된 List[TransactionDiff] 로 인코딩하는 것입니다.
TransactionDiff 에는 해당 트랜잭션의 모든 논스, balance, storage 및 코드 변경 사항이 포함됩니다. 이렇게 하면 여러 AccountChanges 값의 커밋이 하나의 TransactionDiff 로 축소되며, 이는 이전 제안의 subTrieRoot 와 동일한 기능을 합니다.
TransactionDiff 를 간결하게 적용하면 지갑과 PBS 파이프라인의 나머지 부분이 실행 사전 설정을 적용한 후 최신 상태로 업데이트될 수 있으므로 지속적인 블록 구축이 더욱 현실적으로 이루어질 것입니다.
BAL의 다른 이점
주요 롤업은 이미 슈레드(Shred) , 플래시블록(Flashblock) , 프래그 (Frag)와 같은 커밋 방식을 통해 UX 개선을 위한 더 빠른 확인 방식을 실험하고 있습니다. 현재 이러한 방식은 타사 구현에 의존하며, 커밋을 위해서는 시퀀서를 완전히 신뢰해야 합니다.
BAL은 이러한 패턴을 표준화합니다. BAL을 사용하는 롤업은 더 이상 자체적인 커밋 체계를 유지할 필요가 없으며, 사용자는 신뢰할 수 있는 커밋을 통해 더 쉽게 혜택을 누릴 수 있습니다. 사실상 BAL은 이미 실무에서 일어나고 있는 일들을 담고 있습니다.
Vitalik은 MPT 접근 방식으로 밸런서(BAL) 사용하면 부분적 무상태 노드가 관심 있는 BAL 부분에 대한 증명만 검증할 수 있다고 지적했습니다. 즉, 블록 과정에서 내 잔액이 어떻게 변했는지 확인할 수 있습니다.
실행 사전 설정은 페이로드 청킹 과 같은 아이디어에 대한 프로토콜 외부의 전구체입니다.
