Commit-Boost의 병렬 경매

avatar
Ethereum Research
08-22
이 기사는 기계로 번역되었습니다
원문 표시

이 글은 Radius 의 연구원인 Chanyang Ju( 우주 )가 작성했습니다. PoC에 기여해 주신 Hugo 와 이 글을 검토해 주신 AJ 에게 감사드립니다.

1. 초록

이 글에서는 제안자-빌더 분리(PBS)를 위한 새로운 블록스페이스 커밋 메커니즘인 상태 잠금 커밋(State Lock Commitment )을 소개합니다. 현재의 포함 기반 커밋은 실행 일관성을 보장하지 못하여 검색자가 시장 효율성을 저하시키는 위험 회피 전략을 채택하게 합니다. 본 논문에서는 단순한 포함 약속을 넘어서는 이중 구성 요소 접근 방식을 제안합니다. 먼저, 제외 커밋(Exclusion Commitment)이 발행됩니다. 이는 빌더에 독립적인 사전 예약으로, 충돌하는 거래로 인해 특정 상태가 변경되지 않음을 보장합니다. 그 다음에는 후속 경매에서 이긴 번들에 대한 표준 포함 커밋 (사전 확인)이 이루어집니다. 이러한 커밋은 함께 실행 커밋 과 동등한 강력한 보장을 제공하여 검색자가 더욱 확신을 가지고 입찰할 수 있도록 합니다. 아키텍처에는 제안자용 게이트웨이 (Gateway)와 빌더용 잠금 엔진(LockEngine )이 포함되어 있어 제안자가 독점적인 상태 권한을 경매하고, 충돌을 방지하고, 수익을 늘리고, 더욱 강력하고 효율적인 MEV 시장을 조성할 수 있습니다.

1.1 배경

제안자-구축자 분리(PBS)는 블록 공간을 거래 가능한 자산으로 취급하여 제안자가 블록을 구축할 권리를 경매에 부칠 수 있도록 합니다. 이를 통해 빌더 및 검색자와 같은 외부 참여자에게 판매된 약정을 통해 블록 구축의 일부를 위임할 수 있습니다. 현재 이러한 약정은 대부분 포함 기반(포함 목록 및 사전 확인 등)이지만, 시장은 계속해서 발전하고 있습니다.

그러나 기술적, 경제적 한계로 인해 번들이 의도한 대로 실행될 것을 보장하는 널리 채택된 시스템은 없습니다. 결과적으로:

  • 미리 확인된 묶음이 블록에 포함되어 있더라도 의도된 실행이 변경될 수 있으며, 상태가 사전에 변경된 경우 거래가 실패할 수 있습니다.
  • 포함 보장만으로는 일관된 실행에 충분하지 않으므로 검색자는 위험을 분산하고 공격적인 입찰을 억제해야 합니다.
  • 자주 포함되었으나 실패한 실행은 약속에 대한 신뢰를 훼손하고 시장 효율성을 떨어뜨려 결국 제안자 수익이 감소합니다.

발전하려면 블록 공간 약속이 단순한 포함 약속을 넘어 상태 일관성을 보장하는 실행 수준의 보장으로 전환되어야 합니다.

1.2 솔루션: 상태 잠금 커밋

이러한 한계를 해결하기 위해, 제안자가 번들이 접근하는 상태에 대한 배타적인 실행 권한을 명시적으로 약속하는 메커니즘인 상태 잠금 약속(State Lock Commitment)을 도입합니다. 이 약속은 블록 내 정의된 상태 범위가 변경되지 않도록 보장하여 안정적인 번들 실행을 가능하게 함으로써 단순한 포함을 넘어섭니다.

글로벌 상태 잠금을 적용하는 대신, 본 접근 방식은 번들별로 로컬 상태 잠금을 적용합니다. 이를 통해 글로벌 동기화나 메모리풀 전체 제어를 피하고, 잠재적으로 충돌할 수 있는 상태 범위만 제한합니다. 아키텍처의 중요한 측면은 제안자가 특정 EVM 상태에 대한 배타적 실행 권한을 모든 빌더에게 일관되게 전달해야 한다는 것입니다. 즉, 서로 다른 빌더가 서로 다른 후보 블록을 구성하더라도, 이 제약 조건은 고려 중인 모든 옵션에 걸쳐 공통된 접근 제한 규칙으로 작용해야 합니다.

State Lock Commitment는 두 단계로 운영되며 빌더에 대한 부분적 제약으로 작용합니다.

  1. 제외 약속: 제안자는 특정 stateScope 잠금 후보로 선언하고 이를 모든 빌더에 브로드캐스트하여 충돌하는 트랜잭션을 포함하지 않도록 지시합니다.
  2. 포함 약속: stateScope 에 대한 경매가 끝나면 최종 블록에 포함될 번들을 미리 확인합니다.

이 두 가지 커밋을 함께 사용하면 일관된 번들 실행 및 충돌 회피 가능성이 크게 높아집니다. 특정 조건에서는 강력한 수준의 실행 보장(실행 커밋)을 제공할 수 있습니다. 제외 커밋이 모든 빌더에 전파되고 일관되게 적용되면, 검색자는 "내 번들이 블록의 최상위에 있을 것"이라는 포함 보장이 없더라도 "아무도 내 지정된 상태에 영향을 미치지 않을 것"이라는 가정 하에 경쟁 우위를 확보합니다.

따라서 주 단위의 제약(제외)에 기반한 포괄 약속은 일련의 실행 공약의 연속적인 스펙트럼의 일부로 볼 수 있습니다. 건설업체에 독립적인 제약으로서, 이 메커니즘은 블록 건설 역학과 향후 MEV 시장의 인센티브 및 경쟁을 모두 재편할 수 있습니다.

1.2.1 개요

구성 요소 및 책임

요소 책임
제안자 블록을 제안하고, 상태 잠금을 선언하고, 커밋 생성을 요청합니다.
게이트웨이 번들 경매를 조정하고, 약정 요청을 관리합니다.
빌더 블록을 구성합니다.
검색자 묶음을 구성하고 경매에 참여합니다.

절차적 흐름

  1. 제출 및 경매: 검색자는 게이트웨이에 번들을 제출합니다.
  2. 조정 및 경매 시작: 게이트웨이는 번들을 시뮬레이션하여 자동으로 stateScope (예: 액세스 목록)를 추출하고 이 특정 stateScope 에 대한 경매를 시작합니다.
  3. 제외: 경매가 진행되는 동안 제안자는 (게이트웨이를 통해) stateScope 잠금 후보로 발표합니다. 이는 초기 제외 약속의 역할을 하며 참여하는 모든 빌더에게 브로드캐스트됩니다.
  4. 입찰 및 사전 확인: 건설업체는 이러한 제약 조건을 인지하고 거래 충돌을 방지하기 위해 임시 블록을 시공합니다. 경매가 종료되면 낙찰된 번들에 대한 사전 확인 요청이 건설업체에 전송됩니다.
  5. 시행 및 구축: 빌더는 서명된 커밋을 검증하고, 사전 확인된 번들을 포함하여 최종 블록이 stateScope 제약 조건을 준수하는지 확인합니다. 이후, 빌더는 제외를 해제하고 블록 구축을 진행할 수 있습니다.

1.2.2 건축학적 중요성

이 아키텍처는 포함 목록(예: EIP-7547)과 같은 기존 모델에 비해 뚜렷한 이점을 제공하며, 더욱 세분화되고 유연한 블록 공간 시장을 구축할 수 있도록 합니다. 특히, 제외 약정은 검색자에게 번들의 실행 가능성을 사전에 보장하고, 빌더에게 충돌 방지를 위한 명확한 기준을 제공하여 사실상 실행 수준 약정으로 기능할 수 있도록 합니다.

이 모델에서 제안자는 충돌하지 않는 여러 개의 제외 커밋을 병렬로 선언하고 각 stateScope 에 고유한 LockId 할당할 수 있습니다. 각 잠금은 별도의 번들과 연결되며, 동일하거나 겹치는 상태 범위에 대해 하나의 승자만 선택되고 단일 사전 확인이 발행됩니다.

이 구조는 다음과 같은 이점을 제공합니다.

  • 트랜잭션 중심이 아닌 상태 중심: 제안자는 전체 트랜잭션 목록이 아닌 상태 범위에 집중함으로써 빌더에게 더 많은 유연성을 제공합니다. 빌더는 더 작고 명확하게 정의된 상태 영역만 피하면 되므로 나머지 블록을 최적화할 수 있습니다.
  • 병렬적이고 충돌 없는 경매: 제안자는 겹치지 않는 상태 범위에 대해 여러 경매를 동시에 진행할 수 있습니다. 이를 통해 단일 블록 내에 여러 개의 독립적인 MEV 전략을 포함하여 가치를 극대화할 수 있습니다.
  • 모든 참가자를 위한 향상된 인센티브:
    • 검색자: 블록 시간보다 빠르게 실행 확실성을 확보하여 자본 집약적 전략을 보다 공격적으로 입찰하고 자신 있게 구축할 수 있습니다.
    • 제안자: 독점적인 국가 접근 권한을 경매에 붙여 새로운 수익원을 창출하고, 여러 개의 고부가가치 번들을 안전하게 포함하여 블록 보상을 극대화합니다.
    • 건설업체: 명확한 제약 조건을 조기에 확보하여 전체 거래 목록을 기다리지 않고도 블록 시공을 최적화할 수 있습니다. 이를 통해 글로벌 제약 조건이 있는 시나리오에 비해 전략적 유연성과 효율성이 향상됩니다.

본질적으로, 상태 잠금 커미트먼트는 블록스페이스 시장을 단순한 포함 보장에서 이더리움 상태의 정교한 선물 시장으로 전환할 수 있습니다. 이는 더욱 안정적이고 효율적이며 수익성 있는 MEV 생태계에 필요한 보장을 제공합니다.

1.3 인프라 구성 요소: Gateway 및 LockEngine

PBS 인프라 내에서 이러한 상태 제약 기반 커밋 구조를 구현하기 위해 기존 Commit-Boost 기능의 확장을 제안합니다. 구체적으로, 제안자(proposer)의 커밋 생성을 담당하는 Signer 와 번들 조정을 중재하는 Gateway 의 역할을 확장하여 상태 수준 커밋을 처리합니다. 이에 따라 빌더 측에 새로운 보조 모듈인 LockEngine이 도입됩니다. 이 설계를 통해 기존 PBS/MEV-Boost 인프라를 크게 수정하지 않고도 상태 제약 기반 사전 확인을 일관되게 처리할 수 있습니다.

1.3.1 게이트웨이

  • 역할: 제안자의 약속 요청을 전달하고, 번들 간 경쟁을 조정하고, 서명자와 통합하여 서명 수집 및 전달을 처리하는 오프체인 릴레이 인프라입니다.
  • 기능:
    • stateScope 에 따라 번들을 수신하고 관리합니다.
    • 동일한 stateScope 놓고 경쟁하는 번들 간의 충돌을 관리합니다.
    • 경매에 참여하는 검색자로부터 묶음과 입찰을 수신하고 조정합니다.
    • 제안자의 약속 요청과 서명 요청을 서명자에게 전달합니다.
    • 빌더와 검색자에게 약속 결과를 전달합니다.
  • 형질:
    • 핵심 PBS 프로토콜 외부에서 운영되고 검증자와 직접 상호 작용하지 않는 오프체인 중개자입니다.
    • 다양한 전략을 지원하기 위한 중립적 릴레이 인프라로 구성될 수 있습니다.

1.3.2 서명자

  • 역할: 제안자의 제외/포함 약속에 대한 서명 기반 약속을 생성하는 프로토콜입니다. 제안자로부터 위임된 서명 권한을 프록시 키를 통해 부여받아 서명 생성을 처리합니다. 이 프로토콜의 목적은 제안자와 개발자 간의 신뢰할 수 있는 협업을 가능하게 하고 MEV 거래의 안전성과 효율성을 향상시키는 것입니다.
  • 기능:
    • stateScope 기준으로 약속을 처리합니다.
    • BLS 서명을 조정합니다(커밋 → 공개 → 집계 절차).
    • 동일한 슬롯에 대해 중복된 커밋/공개 작업을 방지하는 기능을 제공합니다.
    • 동일한 LockId 에 대해 중복된 커밋/공개 작업을 방지합니다.
  • 형질:
    • 게이트웨이에서 전달된 요청에 대한 서명을 처리합니다(제안자 서명 위임 모델).
    • 여러 게이트웨이가 동일한 Signer 인스턴스를 공유할 수 있습니다(중립성).
    • 제안자 노드 옆에 사이드카로 설치되며, MEV-Boost와 병렬로 실행하거나 통합할 수 있습니다.

1.3.3 LockEngine(빌더 사이드카)

  • 역할: 블록 구성 중에 제안자가 설정한 stateScope 제약 조건을 준수하도록 빌더를 지원하는 사이드카 모듈입니다.
  • 기능:
    • 서명자가 발급한 약정 서명을 확인합니다.
    • 각 stateScope 에 대한 충돌을 감지하고 이에 따라 트랜잭션을 필터링합니다.
    • 빌더의 메모리 풀에서 충돌하는 거래를 사전에 제거합니다.
    • 거래 재정렬 및 번들 재조합을 지원합니다.
  • 형질:
    • 빌더의 핵심 로직을 수정하지 않고도 사이드카로 작동할 수 있습니다.
    • 제안자 또는 게이트웨이로부터 커밋 및 stateScope 정보를 수신합니다.
    • 실행 전 단계에서 stateScope 충돌 방지를 보장합니다.

1.4 주요 구성 요소의 정의

  • 제안자
    • 비콘 체인에 블록을 제안합니다.
    • 프록시 키를 통해 서명자에게 서명 권한을 위임합니다.
    • 게이트웨이에서 수신한 검색자 번들과 해당 액세스 목록( stateScope )을 기반으로 비경쟁 상태 범위에 대한 잠금을 선언합니다(예: 제외 + 포함 커밋 요청).
    • 서명자에게 낙찰 결과에 서명해 달라고 요청합니다.
  • 게이트웨이
    • 검색자로부터 번들을 수신하고 EVM 시뮬레이션을 통해 액세스 목록( stateScope )을 추출합니다.
    • 동일한 상태 범위에 접근하는 번들 간의 충돌을 확인합니다.
    • 모든 번들과 관련 메타데이터를 Relay에 전달합니다.
    • 당첨된 상품을 제안자에게 전달합니다.
    • 제안자의 약정서명 요청을 서명자에게 전달합니다.
    • 모든 커밋 요청과 처리 결과를 기록하고 전파합니다.
  • 계전기
    • 게이트웨이에서 모든 번들과 입찰 정보를 수신합니다.
    • 선택된 번들에 대한 정보를 Gateway와 Proposer에 전파합니다.
    • 블록 제출 후 빌더가 실제로 제안자 약속을 이행했는지 확인합니다(예: 포함, 상태 충돌 회피, 지정된 높이 내 포함).
    • 규정을 준수하지 않을 경우, 슬래싱 증거를 수집하여 AVS 또는 모니터링 네트워크로 전달할 수 있습니다.
  • 서명자
    • 제안자의 요청에 따라, 건설업체가 검증 가능한 방식으로 제외/포함 약정에 서명합니다.
    • 제안자의 위임된 권한에 따라 서명을 처리합니다(예: BLS 사용).
  • 빌더
    • LockEngine을 통해 수신된 stateScope 기반 제약 조건을 준수하여 블록을 구성합니다.
    • 사전 확인에 지정된 번들을 포함해야 하며 stateScope 와 충돌하는 트랜잭션을 포함해서는 안 됩니다(또는 재정렬해야 함).
    • 이러한 조건을 위반하면 삭제 또는 차단 거부와 같은 처벌을 받습니다.
  • 잠금 엔진
    • 빌더 노드와 함께 실행되는 사이드카 모듈입니다.
    • 게이트웨이에서 사전 확인 및 상태 제약 정보( stateScope , LockId 등)를 수신합니다.
    • stateScope 와 충돌하는 트랜잭션을 필터링하거나 재정렬하기 위해 빌더의 mempool을 모니터링합니다.
    • 사전 확인된 번들이 블록에 포함되도록 지원합니다.
    • 빌더가 핵심 논리를 수정하지 않고도 제안자의 제약 조건을 준수할 수 있도록 합니다.
  • 검색자
    • 오프체인 MEV 기회를 파악하고 번들을 구성하여 게이트웨이에 제출합니다.
    • 번들에 대한 stateScope 명시적으로 지정할 필요가 없습니다. Gateway가 자동으로 추출합니다.
    • 동일한 주 범위에 대해 다른 검색자와 경쟁하며, 승리한 묶음은 최종 사전 확인을 받습니다.
    • 실행 실패 위험이 낮아지기 때문에 커밋된 번들에 대해 더욱 공격적인 입찰 전략을 채택할 수 있습니다.

2. 주요 특징

2.1 지역 상태 잠금(제외 약속)

사전 확인을 실행하기 전에 제안자는 특정 번들이 접근하는 상태 범위( stateScope )에 대한 배타적 접근 제약 조건을 선언하여 실행을 보장합니다. 이 선언은 배제 약속(Exclusion Commitment) 의 역할을 합니다. 제안자가 빌더에게 지정된 상태가 접근 금지 상태임을 일방적으로 통지함으로써 충돌을 방지하는 선제적 메커니즘으로 작동합니다.

이 모델에서는 빌더와의 사전 협상 없이 상태 잠금이 설정되며 다음 흐름에 따라 적용됩니다.

  1. 제외 약정 에는 다음 필드가 포함됩니다.
    • LockId
    • stateScope // 액세스 목록을 기반으로 한 계정 세트
    • inclusionHeight // 검색자의 관점에서 상태를 정의합니다.
    • signature
  2. 제안자는 주어진 번들의 상태 범위를 분석한 후 해당 범위에 대한 배타적 접근 제약 조건을 선언합니다. stateScope 는 번들 내 트랜잭션이 접근하는 상태의 주소 목록입니다.
  3. 이 선언은 Gateway를 통해 모든 건설업체에 방송됩니다.
  4. LockEngine (빌더 측)은 이 메시지를 수신하여 로컬 상태 액세스 제한으로 적용합니다.
  5. LockId 활성화되어 있는 동안 빌더는 블록에 충돌하는 거래를 포함해서는 안 됩니다.

2.2 사전 확인(포함 약속)

사전 확인은 제안자가 특정 번들을 지정된 블록에 포함하겠다는 암호화된 약속입니다. 이는 블록스페이스 경매 결과를 확정하는 포함 약속(Inclusion Commitment) 의 역할을 합니다. 이 약속은 배제 약속(Exclusion Commitment)을 기반으로 이루어지며, 이는 실행 가능성이 사전에 확보되었음을 의미합니다.

2.2.1 사전 확인 생성 프로세스

  1. 제안자는 낙찰된 패키지에 대한 사전 확인을 발행하고, 이는 서명자를 통해 서명되어 건설업체에 전달됩니다.
  2. 포용 약속 에는 다음 필드가 포함됩니다.
    • LockId // 제외 커밋의 LockId와 일치합니다.
    • bundleTxs
    • inclusionHeight
    • signature

2.2.2 역할 및 효과

  • 제안자: 포함 약정에 명시된 inclusionHeight 에 번들을 포함할 책임이 있습니다.
  • 빌더: 제외 및 포함 약정의 제약 조건을 기반으로 블록을 구성합니다.
  • LockEngine: 제외 커밋에 따라 상태 범위에 대한 액세스 제어를 시행합니다.

배제 약속(국가 갈등 방지)과 포함 약속(블록 포함 약속)은 별개의 구성 요소이지만, 함께 작동하면 다음과 같은 효과를 제공합니다.

  • 검색자의 경우: 제출한 번들이 특정 상태에서 실행되고 상태 충돌로 인해 실패하지 않음을 보장합니다.
  • 제안자를 위해: 충돌하지 않는 번들을 병렬로 결합하기 위한 프레임워크를 제공합니다.
  • 빌더를 위해: 전체 번들 세트를 기다리지 않고도 미리 블록을 조립할 수 있는 유연성을 제공합니다.

2.3 빌더 제약 조건 처리

빌더는 제안자로부터 두 가지 유형의 제약 조건을 받습니다. 하나는 stateScope 에 대한 상태 접근 제한(제외 약속)이고, 다른 하나는 특정 번들에 대한 포함 약속(포함 약속, 즉 사전 확인)입니다. 이러한 제약 조건은 제안자가 블록을 유효한 후보로 간주하기 위해 반드시 준수해야 하는 구조적 제약 조건입니다. 이는 단순한 권장 사항이 아니라 필수 조건입니다. 이러한 약속은 다음 경로를 통해 전달됩니다.

제안자 → 게이트웨이 → 릴레이 → 빌더(LockEngine 사이드카를 통해)

릴레이는 제안자 약속이 네트워크 전반의 모든 빌더에게 일관되게 전파되도록 보장하여, 어떤 빌더도 일방적으로 제약 조건을 무시하거나 우회하는 것을 방지합니다.

2.3.1 제안자 약속 제약 조건

빌더는 다음 두 가지 제약 조건에 따라 블록을 구성해야 합니다.

  1. StateScope 제외 제약 조건
    • 제안자는 특정 stateScope 에 대한 상태 충돌을 허용하지 않는 잠금(커밋)을 생성합니다.
    • 게이트웨이는 이 잠금 선언을 수신하여 릴레이를 통해 빌더 네트워크로 전파합니다. 각 잠금은 고유한 LockId 로 식별됩니다.
    • 빌더는 다음 방법 중 하나로 이 범위에 액세스하는 모든 트랜잭션을 처리해야 합니다.
      • 포함하지 마세요(엄격한 제외).
      • 상태 충돌이 발생하지 않도록 확인된 번들을 주문한 후 주문하세요.
  2. 사전 확인 포함 제약 조건
    • 제안자는 특정 번들이 지정된 블록 높이( inclusionHeight )에 포함될 것이라고 암호화된 방식으로 약속(사전 확인)합니다.
    • 빌더는 이 번들을 지정된 위치에 포함해야 합니다. 그렇지 않으면 제안자 관점에서 해당 블록이 무효화됩니다.

이 두 조건은 서로 밀접하게 연관되어 있습니다. 둘 중 하나라도 위반될 경우, 제안자는 블록 수용을 거부하거나 시공자에게 벌금을 부과할 수 있습니다.

2.3.2 제약 조건 적용 및 검증

릴레이 및 제3자 검증자(예: 게이트웨이, AVS)는 다음 기준에 따라 빌더 블록이 제안자 약속을 충실히 반영하는지 독립적으로 검증할 수 있습니다. 이 검증은 제외 및 포함 약속의 정보가 공개되어 있고 제안자의 암호화 서명이 첨부되어 있다고 가정합니다.

  • 제외 약정 확인

    • 약속 정보:
      • LockId
      • stateScope
      • inclusionHeight
      • 제안자 서명
    • 검증 절차:
      1. 릴레이는 제안자가 발행한 제외 약속을 수신하고 저장합니다.
      2. 빌더가 제출한 블록 후보를 시뮬레이션하거나 정적으로 분석하여 블록 내 거래에서 액세스하는 상태 집합을 추출합니다.
      3. 추출된 액세스 상태 세트가 커밋된 stateScope 와 교차하는지 확인합니다.
        • 교차로 발견 → 제외 위반.
        • 교차 없음 → 제외가 충족됨.
    • 위반 증거:
      • Relay는 위반 블록과 해당 제외 커밋을 함께 제시하여 슬래싱 증명을 생성할 수 있으며, "이 블록은 제안자가 명시적으로 잠근 stateScope 위반했다"는 것을 보여줄 수 있습니다.

  • 포용 약속 검증

    • 약속 정보:
      • LockId
      • bundleTxs
      • inclusionHeight
      • 제안자 서명
    • 검증 절차:
      1. Relay는 빌더가 제출한 블록의 높이를 inclusionHeight 와 비교합니다.
      2. 정확히 동일한 거래 묶음이 블록에 포함되어 있는지 확인합니다.
      3. 이는 포함 순서와 실행 위치가 커밋에 정의된 조건(예: 맨 위에 배치, 잠금 이후에 실행)을 충족하는지 확인합니다.
        • 포함되지 않았거나 잘못된 주문 → 포함 위반.
        • 올바르게 포함됨 → 포함이 충족됨.
    • 위반 증거:
      • 릴레이는 제출된 블록 헤더와 거래 목록을 "빌더가 지정된 블록 높이에 약속된 번들을 포함하지 못했다"는 증거로 제시하여 포함 위반 증명을 생성할 수 있습니다.

  • 책임 메커니즘

    이 검증 프로세스는 릴레이 수준에서 자동화될 수 있습니다. 위반 사항이 발생할 경우 다음과 같은 조치를 취할 수 있습니다.

    • 슬래싱(슬래싱 방지 제출을 통해):

      • 위반 증명(약속 + 위반 블록의 거래 세트)은 체인상 계약에 제출됩니다.
      • 해당 건설업자의 지분은 소각되거나 벌금이 부과됩니다.

    • 평판 기반 제외:

      • 릴레이/게이트웨이 네트워크는 위반한 빌더를 신뢰할 수 없는 빌더로 표시합니다.
      • 이후 제안자는 해당 건설업체에 대한 블록 수익 창출 기회를 거부합니다.

    • TEE 증명 및 ZK 증명 기반 검증과 같은 향후 확장 경로도 고려할 수 있습니다.

      검증 방법 설명
      TEE 기반 SGX와 같은 신뢰할 수 있는 실행 환경(TEE)에서 생성된 블록에 대해 원격 증명을 사용합니다.
      ZK 기반 Gateway/AVS에서 검증할 stateScope 내의 거래 순서와 실행 경로에 대한 제로 지식 증명을 생성합니다.

3. Commit-Boost의 병렬 경매

3.1 시퀀스 다이어그램

커밋 부스트에 대한 병렬 경매
커밋 부스트에 대한 병렬 경매 1920×2123 107KB

3.2 프로세스

  1. 경매 시작
  • Gateway 특정 슬롯(예: slot N )에 대한 경매 시작을 선언합니다.
  • 모든 참여 검색자에게 StartAuction(slot N) 브로드캐스트합니다.
  1. 번들 제출 및 StateScope 정의
  • Searcher1 → Gateway : 다음을 포함하는 번들을 제출합니다.
    • txList1
    • bid1
    • inclusionHeight
  • Gateway :
    • 번들을 시뮬레이션하고 AccessList 추출합니다.
    • 해당 stateScope 파생합니다.
    • 번들에 대한 고유한 LockId 생성합니다.
  1. 제외 약정 요청 및 서명
  • Gateway → Signer : RequestSig(LockId, stateScope)
  • Signer :
    • ExclusionCommitment 에 서명합니다
    • ExclusionSig 반환합니다.
  • Gateway → LockEngine : ExclusionCommitment 전송합니다.
  • LockEngine :
    • 약속을 확인합니다
    • stateScope 기반 트랜잭션 필터링을 준비합니다.
  1. StateScope 브로드캐스트 및 필터링
  • Gateway :
    • 모든 검색자에게 stateScope 브로드캐스트합니다.
    • 중복 입찰을 방지하고 전략 차별화를 장려합니다.
  • LockEngine :
    • 잠긴 stateScope 와 충돌하는 mempool 트랜잭션을 필터링합니다.
    • 충돌하지 않는 거래의 필터링된 목록을 Builder에 전달합니다.
  • LockEngine → Builder : DeliverFilteredTxList
  • Builder : 필터링된 거래를 기반으로 블록 구성을 시작합니다.
  1. 추가 입찰 및 경매 완료
  • Searcher2 → Gateway : 다른 번들을 제출합니다.
    • 포함 사항:
      • txList2
      • bid2
      • inclusionHeight
  • Gateway
    • 입찰을 비교하고 우승 번들을 선택합니다(예: Searcher2 )
    • EndAuction 선언하고 결과를 전달합니다.
  1. 포용 약속 발행
  • Gateway → Signer : RequestSig(bundleHash, inclusionHeight)
  • Signer :
    • InclusionCommitment (사전 확인)에 서명합니다.
    • InclusionSig 반환합니다.
  • Gateway → LockEngine : 서명된 포함 커밋을 전송합니다.
  1. 최종 블록 건설
  • LockEngine :
    • InclusionSig 확인합니다.
  • LockEngine → Builder : Send(txList2)
  • Builder :
    • 주어진 거래 목록을 포함하는 블록을 구성합니다.
    • 지정된 inclusionHeight 에 번들이 포함되도록 합니다.
  1. 블록 제출 및 포함 증명
  • Builder → Proposer : 완성된 블록을 제출합니다.
  • Builder → Gateway : InclusionProof(bundle) 제출합니다.
  • Gateway → Relay : InclusionProof(bundle) 릴레이합니다.
  • Relay :
    • 약속 이행을 검증합니다.
    • 필요한 경우 AVS 또는 기타 모니터링 인프라에 증거를 전파합니다.

4. 경쟁 조건 및 충돌 처리

4.1 사전 확인 충돌 규칙

  • 동일한 stateScope 에 대해 유효한 사전 확인은 하나만 발행될 수 있습니다.
    • 하나의 LockId 단 하나의 우승 검색자에게만 할당됩니다.
    • 경매 시점에 Gateway는 상태 충돌이 있는지 확인하고 동일한 stateScope 에 대해 경쟁하는 번들에서 단 한 명의 승자만 선택합니다.
  • stateScope 가 서로 분리된 상태에 접근하는 경우, 사전 확인을 병렬로 실행할 수 있습니다.
    • Gateway는 여러 LockId 에 대한 경매를 병렬로 실행할 수 있습니다.
    • 빌더는 LockEngine을 통해 여러 LockId 를 병렬로 관리하여 번들을 간섭 없이 블록 내에서 공존하도록 조정합니다.

4.2 갈등 탐지 기준 및 위치

  • 갈등 기준:
    • 두 번들이 동일한 계약 주소나 슬롯 수준 항목을 포함하는 상태( stateScope )에 액세스하는 경우 충돌이 식별됩니다.
    • stateScope 계약 수준이나 슬롯 수준에서 정의할 수 있습니다. 구현 복잡성과 달성 가능한 병렬 처리 수준 사이에 균형이 필요합니다.
  • 갈등 감지 위치:
    • 게이트웨이: 검색자 번들을 시뮬레이션하고 액세스 목록을 추출합니다.
    • LockEngine: 빌더의 메모리 풀에 대한 실시간 필터링을 수행하여 충돌하는 트랜잭션을 사전에 제거하거나 재정렬합니다.

4.3 약속 불이행 및 페널티

건설업체는 다음 조건을 위반할 경우 삭감 또는 기타 처벌을 받을 수 있습니다.

  • 지정된 inclusionHeight 에 우승 번들을 포함시키지 못했습니다.
  • 사전 확인된 번들 보다 먼저 동일한 stateScope 에 액세스하는 다른 트랜잭션을 포함하여 번들이 실패하게 합니다.
  • 블록을 구성할 때 사전 확인에서 서명된 정보를 생략하거나 조작합니다.
  • 증명 제출 및 슬래싱:
    • 게이트웨이 또는 검색자는 관련 블록과 해당 커밋(제외/포함)을 AVS 또는 온체인 검증 모듈에 제출할 수 있습니다.
    • InclusionProof (예: Merkle 증명) 또는 전체 블록 데이터를 증거로 사용할 수 있습니다.
  • 예외 처리:
    • 제외 약정 후 포함 약정이 발행되지 않은 경우:
      • LockEngine(빌더)은 일정 기간 후에 자동으로 잠금을 해제할 수 있습니다.
      • 최대 잠금 기간을 설정해야 합니다(예: 8초 이내).
      • 건설사는 해당 거래를 제외하고 블록 건설을 진행할 수 있습니다.
    • 체인 재구성과 같은 이벤트로 인해 포함이 무효화되는 경우 제안자 오류와 빌더 오류를 구별할 필요가 있습니다.

5. 개념 증명(PoC) 구현

이 프로토콜은 단순한 이론적 제안이 아닙니다. 저희는 로컬 상태 잠금 프로토콜 형태로 커밋-부스트 아키텍처를 확장하여 실질적인 개념 증명(PoC)을 수행했습니다. 이 설계는 새로운 기능을 추가하면서 기존 PBS 인프라와 커밋-부스트 설계를 최대한 재사용하는 데 중점을 두었습니다.

5.1 구현 범위

PoC는 다음 두 가지 핵심 커밋 프로세스를 코드로 구현했습니다.

  1. 배제 약속
    • 검색자가 제출한 번들에 대한 stateScope 정의했습니다.
    • 제안자는 이 stateScope 를 기반으로 "갈등 방지" 메시지를 생성하여 모든 빌더에게 전달했습니다.
    • 빌더의 LockEngine이 이를 수신하여 메모리 풀에서 충돌하는 트랜잭션을 필터링하고 로컬 상태를 업데이트했습니다.
  2. 포용성 약속
    • 제안자는 stateScope 경매를 통해 우승자를 결정했습니다.
    • 우승자(검색자)에게 LockId , bundleHash , inclusionHeight 등이 포함된 사전 확인이 발행되었습니다.
    • 이는 Signer 모듈을 통해 서명되어 빌더에게 전달되었습니다.

5.2 운영 흐름(PoC)

PoC에 구현된 엔드투엔드 실행 흐름은 다음과 같습니다.

  1. 검색기 → 게이트웨이: 번들을 제출하고 stateScope 사양을 제공합니다.
  2. 게이트웨이 → 제안자: 번들 집합을 수집하고 충돌을 파악합니다. 분리된 stateScope 에 대해서는 병렬 경매를 실행합니다.
  3. 제안자 → 빌더: 제외 약정을 브로드캐스트합니다. 낙찰된 번들에 대한 포함 약정을 발행합니다.
  4. Builder(LockEngine): 충돌하는 트랜잭션을 제외하여 제외 약정을 적용합니다. 지정된 슬롯에 번들을 포함하여 포함 약정을 적용합니다.

5.3 주요 실험 결과

  • 예측 가능한 실행 보장:
    • 잠금이 stateScope 수준에서 적용되었기 때문에 동일한 상태에 액세스하는 경쟁 번들로 인한 충돌 없이 검색자 번들이 실행되었습니다.
  • 병행 경매 타당성 확인:
    • stateScope 가 분리되어 있을 때 여러 번들이 동시에 사전 확인을 받을 수 있음을 확인했습니다.
  • Builder 통합의 용이성:
    • LockEngine을 사이드카로 구현함으로써 기존 빌더 로직을 크게 수정하지 않고도 커밋 제약 조건을 적용할 수 있음을 확인했습니다.

5.4 제한 사항 및 향후 작업

  • PoC는 슬롯 수준 잠금보다는 계약 수준 세분성에 중점을 두고 구현되었습니다.
  • 재구성 시나리오, 잠금 시간 초과 처리, 슬래싱 증명 제출과 같은 일부 예외 사례는 구현되지 않은 상태로 남아 있습니다.
  • 향후 작업에서는 TEE/ZK 기반 블록 검증을 통합하고 더욱 세부적인 stateScope 정의해야 합니다.

참고문헌

https://github.com/radiusxyz/parallel-auction-commit-boost
https://ethresear.ch/t/state-lock-auctions-towards-collaborative-block-building/18558
https://ethresear.ch/t/commit-boost-proposer-platform-to-safely-make-commitments/20107
https://eips.ethereum.org/EIPS/eip-2930
https://eips.ethereum.org/EIPS/eip-7547


출처
면책조항: 상기 내용은 작자의 개인적인 의견입니다. 따라서 이는 Followin의 입장과 무관하며 Followin과 관련된 어떠한 투자 제안도 구성하지 않습니다.
라이크
즐겨찾기에 추가
코멘트
관련 콘텐츠