스테이트 락 경매: 협력적 블록 구축을 향해

Ethereum Research

02-04

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

원문 표시

스테이트 락 경매: 협업 블록 구축을 향하여

이 게시물에 영감을 준 토론과 의견을 보내주신 Quintus, Louis, Shea에게 감사드립니다.

BJ506v_E2.jpg1024×1024266 KB

개요

공개 최초가 경매의 공개 부스트 경매 특성으로 인해, 검색자는 '보다 전략적으로' 입찰하기 위해 '검색자 구축자'가 되어 수직적 통합에 대한 인센티브를 얻게 되었습니다. MEV 부스트 경매에서 우위를 점하기 위한 이러한 수직화는 통계적 차익 거래의 진입 장벽을 상당히 높이는 불행한 결과를 가져왔으며, 그 결과 새로운 "검색자-빌더"가 다른 빌더로부터 주문 흐름을 대량으로 구매하고 기존 블록 빌더와 주문 흐름 동등성을 달성하기 위해 효과적인 "광고 지출"로 블록에 보조금을 지급하는 불리한 시장 구조를 만들어냈습니다. "전략적 입찰"에서 이러한 우위를 제거하려는 시도는 주로 경매를 밀봉 입찰 형식으로 수정하는 데 집중되어 왔으며, 이러한 시도는 MPC, FHE, TEE와 같은 신뢰할 수 있는 프라이빗 커미트먼트 기술이 없는 상황에서 새로운 담합 벡터를 도입하는 것이어서 모두 실패했습니다.

분산 시스템 문헌에서 많은 부분을 차용한 이 글에서는 메브 부스트 경매에서 '잠금 상태'를 활성화하고, 이 '잠금 상태'에 대한 가시성을 제공하는 후속 기능을 구현하는 제안을 스케치합니다. 이러한 접근 방식의 궁극적인 결과는 블록 빌더가 나머지 블록을 구성할 때 불확실성으로 인해 더 이상 효과적으로 "파이프라인이 멈추지 않도록" 하는 것이며, 이는 "협력적 블록 구축"을 위한 문을 여는 것입니다. 분산 시스템 측면에서 볼 때, 저희는 가시성을 활용하여 이더리움 분산 상태 머신을 위한 "부트 레그" 분산형 다중 버전 동시성 제어 시스템을 만들고 있습니다.

이 접근 방식의 주요 장점은 이러한 고속 차익거래에서 경쟁하는 검색자의 기본적인 프라이버시와 입찰가 업데이트 기능을 유지하고, 이전의 "랜딩" 접근 방식에 비해 더 일반적인 차익거래를 지원하며, 현재 시장에 쉽게 배포할 수 있다는 점입니다. 주요 단점은 블록 상단에 단일 거래 차익거래의 '의사 안치'를 생성하고 새로운 검열과 괴롭힘 벡터를 제공한다는 점입니다. 이 제안은 단지 스케치일 뿐이므로, 상태 잠금에 드는 비용을 효과적으로 책정하는 방법, 검색자의 입찰 전략에 미치는 영향, 단일 상태 집합을 잠그는 기능을 넘어 경매를 일반화하는 방법 등 아직 알려지지 않은 부분이 많이 있습니다.

상태 잠금 경매에 바람직한 속성

전부는 아니지만, 즉시 눈에 띄는 몇 가지 유리한 속성을 소개합니다:

락커 안전성 - 블록이 확정되기 전에 상태를 잠근 사람의 주소가 공개되면 표적화된 DoS 벡터가 생성됩니다.
입찰 업데이트 기능 - 상태 잠금을 커밋한 검색자는 상태 액세스 목록을 수정하지 않는 한 트랜잭션의 매개변수를 업데이트할 수 있어야 합니다.
잠금 상태 가시성 - 잠금 상태의 스토리지 슬롯은 블록 빌더가 공개적으로 볼 수 있어야 합니다.
잠금 상태결제 보장 - 검색자가 입찰가를 업데이트하든 그렇지 않든, 잠금 상태의 블록에 결제 트랜잭션이 포함되어야 합니다.
스쿼팅 저항 - 그리핑을 방지하기 위해 광범위한 양의 상태를 잠그는 데 드는 비용을 엄청나게 높게 책정해야 합니다.
경합인식 - 부족한 상태의 가격은 해당 상태에 대한 관심의 양을 반영해야 합니다.

접근 목록

이 글의 대부분에서 잠글 상태를 "액세스 목록"이라고 합니다. EIP-2930의 맥락에서 상태 액세스 목록AA는 튜플의 시퀀스로 정의됩니다:

A = [ ( \text{주소}, [ \text{storageKey}_1, \text{storageKey}_2, \ldots ] ), \ldots ]입니다.

A=[(주소,[storageKey1,storageKey2,...]),...]

Where:

\텍스트{주소}주소는 트랜잭션이 상호작용하는 컨트랙트 또는 외부 소유 계정(EOA)의 이더리움 주소입니다.
[텍스트{스토리지키}_1, \텍스트{스토리지키}_2, \점][스토리지키1,스토리지키2,...] 는 트랜잭션이 접근할 지정된 컨트랙트의 스토리지 내 스토리지 키 목록을 나타냅니다.

스왑에 대한 액세스 목록 예시는 부록 A에 나와 있습니다.

제안: 릴레이 실행 단일 잠금 경매

검색자를SS, 릴레이를 RR, 부분 블록 빌더를 PBPB로 표현하면 경매 프로세스는 다음과 같이 진행됩니다:

경매를 시작합니다:

슬롯의 컷오프 시간 T_{cutoff}T컷오프 초 전에, 검색자는 두 개의 트랜잭션으로 상태 잠금 커미트먼트를 RR에 제출합니다:
\text{SubmitStateCommitment}(n, A, tx_{state}, tx_{payment}, b)
SubmitStateCommitment(n,A,tx_{상태},tx_{지불},b)
여기서
- nn: 슬롯 번호.
- AA: 액세스 목록.
- TX_{STATE}TXSTATE: 상태 액세스 트랜잭션.
- TX_{PAYMENT}TXPAYMENT: 잠금 비용을 지불하는 결제 트랜잭션입니다.
- bb: 입찰값,
그리고 제출 시 RR 값입니다:
- bb는AA를 기준으로 잠금 준비금 비용을 충족하거나 초과해야 합니다.
  - 잠금 준비금은 다음에 의해 결정됩니다:
\text{LockCost}(A) = C \times |A|
LockCost(A)=C×|A|
여기서:
- CC는 스토리지 슬롯당 고정 비용을 나타내고, |A||A|는 tx_{state}txstate에 대한 액세스 목록AA에 있는 스토리지 슬롯의 개수입니다. 이 접근 방식은 순진하게도 대량의 상태를 잠그는 데 더 많은 비용이 들지만 이상적인 가격 책정 규칙과는 거리가 멀다.
- - tx_{state}txstate는 액세스 목록이AA와 같은 트랜잭션이어야 합니다.
- - tx_{payment}txpayment는 콜 데이터가 없는 EOA에서 검증자에게 지불하는 트랜잭션이어야 합니다.
- - 블록 상단에서 함께 시뮬레이션된(tx_{state}txstate, tx_{payment}txpayment) 트랜잭션은 bb가 약속한 금액을 지불합니다.

승자 선택:

T_{cutoff}Tcutoff에서RR은 가장 높은 입찰가를 선택합니다:
b_{max} = \max(\{b_i | b_i \geq \text{LockCost}(A_i), \forall i \in S\})
bmax=max({bi|bi≥LockCost(Ai),∀i∈S})
- 그런 다음 RR은 호출하는 모든 사람에게 b_{max}bmax와 연관된 당첨된 액세스 목록 A_{max}Amax를 공개합니다:

\text{GetLockedState}(n)

GetLockedState(n)

입찰 업데이트 및 부분 블록 제출:
낙찰자 선정 후 두 가지 주요 활동이 발생할 수 있습니다:

낙찰된 검색자 addr_{max}addrmax는 촉진된 상태 접근 트랜잭션을 업데이트할 수 있습니다:
\text{UpdateStateCommitment}(n, addr_{최대}, A_{최대}, tx_{상태\_새}, b_{새})
업데이트 상태 커미트먼트(n,addrmax,Amax,txstate_new,bnew)
여기서
- nn은 addr_{max}addrmax에서 낙찰된 입찰과 관련된 가장 최근 슬롯과 같아야 합니다.
- RR은 업데이트된 상태 액세스 트랜잭션 tx_{state\_new}txstate_new의 액세스 목록이 A_{max}Amax와 동일한지 확인해야 합니다.
- 그리고 결제 트랜잭션 tx_{payment}txpayment는 암시적으로 변경되지 않은 상태로 유지됩니다.
부분 블록 빌더는 A_{max}Amax에 대해GetLockedState(n )를 쿼리하고, 이 정보를 기반으로 부분 블록을 빌드한 다음, 다음을 사용하여 제출합니다:
\text{SubmitPartialPayload}(TX_{list}, b_{PB})
SubmitPartialPayload(TXlist,bPB)
여기서
- TX_{list}TXlist에는 트랜잭션 목록이 포함됩니다.
- b_{PB}bPB는 부분 블록에 대한 입찰을 나타냅니다.
부분 페이로드 제출을 받으면 릴레이(RR)는 다음 단계를 수행합니다:
- 1. 트랜잭션 조합: RR은 다음을 생성합니다.
\tx_{상태}, tx_{지불},TX_{목록}을 생성합니다.
콜라보블록 = (tx_{상태},tx_{결제},TX_{리스트})
- 2. 블록 검증: RR은 CollabBlock을 시뮬레이션하여 일반적인 블록 검증을 수행하고 결합된 블록 입찰 값이 b_{max} +b_{PB}bmax+bPB.
- 3. 결제 처리: RR은 결제 트랜잭션을 생성, 서명, 삽입하여 결제 검증자와 부분 블록 빌더에 전달합니다.
- 4. 상태 루트 계산: 검증에 성공하면 RR은 블록의 상태 루트 및 관련 필드를 계산하여 최신 EL 및 CL 사양과의 호환성을 보장하고, 최신 페이로드 속성을 가진 비콘 블록에 삽입하며, 검증자의 getHeader 호출에 사용할 수 있도록 합니다.

아래는 위의 경매 과정을 아티스트가 렌더링한 것입니다.

스크린샷 2024-02-03 at 3.58.51 PM1850×1312253 KB

릴레이 사양 변경에 대한 대략적인 스케치는 부록 B에서 확인할 수 있습니다.

분석

이 접근 방식은 락커 안전성, 입찰 업데이트 기능, 락 상태 가시성, 락 결제 보장 등 상태 잠금 시스템의 핵심 목표를 대부분 충족하고, 스쿼팅 저항을 해결하며, 컨텐트 인식을 시도하지 않습니다. 또한, 잠금 상태 가시성은 빌더가 블록 상단 차익거래에 부분 블록을 더 자신 있게 추가할 수 있도록 함으로써 협력적 블록 구축의 기반을 마련합니다. 이 설계는 분쟁이 있는 잠금 상태를 건드리려는 다른 트랜잭션이 차단되지 않도록 의도적으로 SubmitPartialPayloadSubmitPartialPayload 중에 충돌하는 트랜잭션이 있는지 확인하지 않도록 합니다. 블록 빌더는 충돌이 있는 블록을 자유롭게 전송할 수 있지만, 이제 충돌을 미리 인지할 수 있으므로 현재 시장보다 개선되어 참여 인센티브가 생깁니다. 검색자 역시 스탯 아브에 참여하기가 더 쉬워지고 블록이 포함될 가능성이 높아지기 때문에 참여에 대한 인센티브를 받게 됩니다. 릴레이는 추가 작업을 수행하므로 추가 비용이 발생하지만, 이 접근 방식은 로터리 인센티브에서 릴레이 간의 두 번째 가격 경매를 통해 이익을 취할 수 있는 능력을 정상화합니다.

한 가지 관심 분야는 릴레이 중심의 블록 빌딩으로 전환하고 빌더 릴레이를 정상화하는 것입니다. 저의 편향되고 조심스러운 초기 반응은 어떤 블록이 건설되는지에 대한 의견이 분분하거나 한 당사자가 다른 당사자에 비해 불평등한 이점을 얻지 않는 한 이러한 추세는 괜찮을 것이라는 것입니다. 이러한 관점에서 볼 때, 릴레이는 구축자 네트워크 사이에서 신뢰할 수 있는 제3자로서 경매 관련 로직을 계속 추가할 것이며, 각 추가 로직은 이상적으로는 보다 협력적인 블록 구축을 촉진하는 데 도움이 될 것입니다.

이 접근 방식은 프로토콜을 변경할 필요가 없으며 현재의 메브 부스트 경매와 병행하여 실행할 수 있습니다. 또한, 단일 차익거래 유형으로 제한하지 않고 "랜딩" 접근 방식을 생성하지만, 블록 상단 차익거래를 단일 트랜잭션으로 제한하기 때문에 완전히 일반화되지는 않았습니다. 따라서 번들 지원을 탐색하는 것은 이상적인 미래 탐색이지만, 순진하게 수행하면 전체 블록을 제출하는 새로운 경로를 통해 추가적인 복잡성을 야기할 수 있습니다.

그러나 이 접근 방식을 실시간으로 적용하는 데에는 몇 가지 복잡한 문제가 있습니다. 그 중 하나는 콜드 스타트 문제입니다. 출시 시점에 단 한 명의 검색자만이 이 경매에서 경쟁할 수 있는 역량을 개발했다면, 잠금 예약 비용 가격에 따라 단기간 동안 매우 저렴하게 우위를 점할 가능성이 높습니다. 한 명의 검색자만 참여해도 나머지 검색자의 참여가 눈덩이처럼 불어날 수 있다는 이중적인 문제가 있습니다. 개선해야 할 또 다른 부분은 이 설계가 단일 릴레이의 경우에만 초점을 맞췄지만 실제로는 모두 독립적으로 작동하는 릴레이가 많다는 점입니다. 한 가지 생각은 입찰 취소가 보장되지 않는 유사한 교차 릴레이 문제이기 때문에 동기화가 중요하지 않을 수도 있다는 것입니다. 다중 릴레이 시나리오에서 가장 좋은 경우는 각 릴레이가 잠글 상태에 대해 합의하는 것입니다. 최악의 경우, 각각 다른 상태를 설정하고 모든 잠재적 경로에 대해 부분 블록 빌더를 구축합니다. 이렇게 하면 더 많은 작업이 필요하지만, 최소한 병렬 처리가 가능하고 현재 상태보다 크게 개선된 것입니다. 향후 연구해야 할 또 다른 영역은 이 접근 방식이 더 복잡한 검증 로직을 고려할 때 낙관적 릴레이에 어떻게 적용되는지입니다.

마지막으로, 가장 중요한 미지의 영역은 잠금 가격 책정 메커니즘과 국가 공약이 검색자 전략에 미치는 영향입니다. 잠금 가격 책정 메커니즘은 매우 정의되지 않았으며, 상황이 우스꽝스럽게 잘못될 가능성이 높으므로 후속 작업에서는 이를 분석적이고 적대적으로 추론해야 합니다. 과거 상태 액세스를 가격 책정 메커니즘에 통합하는 것도 어려운데, 이는 순진하게 수행하면 업데이트해야 할 벡터가 매우 크고 기본 수수료처럼 블록에 연결할 수 없기 때문입니다. 이 메커니즘을 파악하는 데 진전이 있으면 이 경매의 검열 벡터가 얼마나 큰지 평가하고 인센티브를 더 구체적으로 파악하는 데 도움이 될 것입니다. 통계적 차익거래를 수행하기 위해 새로운 선불 비용이 발생하는 효과도 고려해야 하지만, 최악의 경우 검색자는 다른 도메인의 신호에 따라 더 이상 매력적이지 않은 가격에 대량의 거래를 할 필요 없이 효과적으로 거래를 취소하고 수수료만 지불할 수 있습니다.

추가 기능

무작위 마감 시간은 막판 입찰을 막기 위해 사용할 수 있습니다. 그러나 다중 독립 릴레이의 경우 릴레이마다 다른 낙찰자를 만들어야 하는 비용이 발생합니다.
스테이트 락 경매는 두 번째 가격 규칙을 사용하여 지불을 결정함으로써 정직한 입찰을 장려할 수 있습니다. 이는 21,000 가스의 비용으로 차액에 대한 환불 트랜잭션을 블록에 삽입함으로써 달성할 수 있습니다.
EIP-2930 트랜잭션 유형은 상태 액세스 트랜잭션에 사용할 수 있지만, 액세스 목록에 없는 스토리지 슬롯에 대한 액세스를 지원하므로 블라인드 트러스트가 불가능합니다. 일반적으로 이 방향으로 나아가는 것이 향후 모든 협업 구축 노력을 간소화하는 데 도움이 될 것입니다.
릴레이의 블록 구성은 무조건 포함 목록을 연결하기에 이상적인 시기를 제공합니다.
입찰을 열어두면 원본과 동일한 상태에 닿는 한 상태 액세스 트랜잭션을 자신의 트랜잭션으로 대체할 수 있습니다. 이와 관련된 인센티브는 약간 불분명합니다.
겹치는 액세스 목록에 대한 경매를 병렬로 허용합니다.
- 여기서 한 가지 문제는 두 개의 풀을 차익거래하는 것을 나타내는 접근 목록을 두 개의 경매로 나누어 각 풀을 차익거래할 수 있으며, 각 풀을 개별적으로 잠그는 비용이 두 풀을 동시에 잠그는 비용보다 높지 않을 수 있다는 것입니다. 따라서 일반화하려면 다른 경매의 낙찰을 조건으로 입찰할 수 있는 일종의 조합형 경매가 필요합니다.
  - 타룬은 여기에서 지토 솔라나 MEV 경매가 비슷한 방식으로 작동하는 방식에 대해 설명했습니다.
- 또 다른 문제는 단일 경매의 경우 릴레이가 낙찰된 트랜잭션이 특정 액세스 목록을 생성하는지 확인할 수 있다는 것입니다. 이중 경매의 경우, 첫 번째 거래의 액세스 목록만으로는 두 번째 거래의 액세스 목록을 더 이상 확신할 수 없습니다. 이는 트랜잭션 1에서 수정된 잔액을 조건으로 하는 트랜잭션 2를 예로 들 수 있습니다. 이러한 읽기-쓰기 충돌의 가능성을 감지할 수 있어야 하지만, 이러한 경매를 지속적으로 쌓아 올릴 수 있을 만큼 안정적이지 않을 가능성이 높습니다. 릴레이는 첫 번째 경매의 낙찰자 위에 두 번째 거래를 시뮬레이션할 수 있지만, 블록에서 많은 경매를 실행하기에 충분한 시간을 제공하지 않습니다. 이 문제를 해결하려면 트랜잭션의 상태 쓰기 및 읽기 기능에 몇 가지 제약 조건을 적용해야 할 가능성이 높습니다.

ePBS의 실현 가능성

이 접근 방식을 향후 "ePBS"와 같은 것과 통합하는 데 따르는 어려움은 경매를 어테스터 계층으로 옮겨야 한다는 점이며, 이는 당연히 추가적인 동기화 기간을 필요로 합니다. 네트워크는 프로토콜 계층에서 인센티브를 제공하는 P2P 게임은 말할 것도 없고, 당첨된 액세스 목록이 '무엇'인지에 대한 합의에 도달해야 합니다.

이러한 기능을 프로토콜로 옮기는 것을 반대하는 이유 중 하나는 검증자의 관점에서 볼 때 네트워크의 리소스에 영향을 미치지 않기 때문이며, 잠금이 많거나 적다고 해서 검증자의 업무를 수행하는 데 필요한 리소스 요구 사항에 영향을 미치지 않기 때문입니다. 또한, 잠금 경매는 네트워크의 생존 위험을 나타내지 않습니다. 경매가 실패하면 현재 블록 생성 상태로 돌아가기 때문입니다. 경매를 프로토콜로 옮기는 것을 지지하는 논거는 경매가 프로토콜의 상태에서 수익을 창출한다는 것입니다.

결론

이 제안은 이더리움에서 블록 상단 상태 잠금을 경매하고 블록 생성자 시장에서 협업을 가능하게 하는 비교적 조잡한 메커니즘의 설계를 스케치한 것입니다. 최종적인 해결책은 아니지만, 이는 상태 잠금 실험을 위한 이상적인 인터페이스를 만들고 블록 생성 시장의 새로운 측면을 열어주며, 현재의 로컬 맥시멈에서 벗어나는 데 도움이 될 수 있습니다. 이상적인 락 가격 책정 메커니즘을 가정할 때, 이 접근 방식은 빠르게 야생에 적용되어 더 나은 빌더 시장 구조를 향해 한 걸음 더 나아갈 수 있습니다.

부록

A. 액세스 목록 예시

액세스 목록 예시

tx 해시 0x84ba67793c7aa0140ae9f7cbc58a7bec04099672d467dfe280ec5987b5f26b46 랩드 이더를 포크토시 나카모토로 스왑.

이 파이썬 스크립트를 통해 생성되었습니다.

[{"주소": "0xa65303cbe1186f58dda9cf96b29e1e89ae90b165","storageKeys": ["0x0000000000000000000000000000000000000000000000000000000000000008"]},{"address": "0xb39bc86ac75118011f646276fca48d56e54c4854","storageKeys": ["0x000000000000000000000000000000000000000000000000000000000000000d","0x7e3bb96fe9c3e8bf8baff39136a5e5778a1f21be90df3270983ce535ed884516","0x9db3014a7ecc5c8baca43505a03b4e7e24c2ec389a973d5605a299f04defc730"]},{"address": "0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2","storageKeys": ["0x377eec8667584e30e85471441b46e69393e5f35d2b63a0b4c26a5b1f6d059aa5"]}]

Here
- 0xC02aaA...3C756Cc2는 WETH 토큰 컨트랙트입니다.
- 0xb39BC8...e54C4854는 PORKTOSHI 토큰 컨트랙트입니다.
- 0xA65303...AE90B165는 PORKTOSHI/WETH Uni V2 풀입니다.
PORKTOSHI 컨트랙트의 저장 키를 기반으로 몇 가지 비표준 ERC20 동작이 있음을 알 수 있으며, 소스 코드에서 이를 확인할 수 있지만 중요한 것은 아닙니다.

B. 대략적인 릴레이 사양 변경

유효성 검사 규칙과 내부 로직은 이전 섹션에서 설명했습니다.

1. `릴레이_서브밋스테이트커미트먼트`

참가자가 특정 슬롯에 대한 상태 커밋을 제출할 수 있도록 허용합니다.

수락합니다:
- n (슬롯 번호): 슬롯 번호를 나타내는 정수입니다.
- A (액세스 목록): 트랜잭션이 상호작용하려는 상태 키(주소 및 스토리지 키)를 자세히 설명하는 객체 배열입니다.
- statetx (서명된 트랜잭션): 서명된 트랜잭션의 16진수 문자열입니다.
- paymenttx (서명된 트랜잭션): 서명된 트랜잭션의 16진수 문자열입니다.
- b (입찰값): 입찰값을 위 단위로 나타내는 정수입니다.
반환값: 제출 확인.