이 기사에서는 MEV가 이더리움에 가져오는 중앙 집중화 문제를 살펴봅니다. 개선하는 방법?
저자: 사이먼 브라운
원본 편집: 0x11, ForesightNews
MEV는 어떻게 PoS Ethereum의 중앙집중력이 되었습니까? 이 문서는 이 문제에 대한 탐구의 두 번째 부분입니다. 첫 번째 부분은 MEV의 영향으로 인해 이더리움이 어떻게 더 중앙 집중화될 수 있는지 추측하기 위해 합병 전에 작성되었습니다. 합병 후 작성된 두 번째 보고서는 합병 후 몇 달 동안 실제로 일어난 일, 오늘날 생태계의 상태, 그리고 미래에 어디로 갈 것인지를 살펴봅니다.
유효성 검사기의 중앙 집중화
유효성 검사기의 중앙 집중화
MEV-Boost의 원래 근거는 MEV 인출에 대한 대규모 스테이킹 풀의 규모 효과를 완화하려는 시도였으며, 이는 불가피하게 중앙 집중화로 이어질 수 있음을 상기하십시오. MEV-Boost는 모든 검증인이 제안한 블록에서 가능한 한 많은 MEV를 얻을 수 있도록 설계되었습니다. 즉, 독립적인 스테이커가 대규모 스테이킹 풀과 동일한 MEV를 얻을 수 있는 기회를 가지므로 공정한 경쟁의 장을 유지할 수 있습니다.
이미지 설명
비콘 체인 입금 내역, 출처: Etherscan
리도가 지분의 29.8%를 차지하고 있어 컨센서스 문턱에 근접해 우려를 낳고 있다.
그러나 Lido 자체가 DAO이기 때문에 오해가 있습니다. 즉, 정의에 따라 분산되어 있음을 의미합니다. Lido는 노드 운영자의 배포에 대한 투명한 정책을 가지고 있으며, 분산화에 대한 게시물에서 자세한 내용을 읽을 수 있습니다.
이미지 설명
엔터티별 예금자(Lido 분할 노드 포함), 출처: Etherscan
특히 Coinbase와 Kraken(미국에 등록된 두 회사)이 공동으로 21% 이상의 스테이킹을 소유하고 있다는 점을 고려하면 상황은 암울합니다. 또한 Danny Ryan은 유동성 스테이킹 파생 계약에는 위험이 있다고 생각합니다. 계약 자체가 분산된 경우에도 합의 임계값을 초과하는 유효성 검사기 지분을 얻을 위험이 있습니다. 그의 기사에서 찾을 수 있습니다.The Risks of LSD — HackMD에서 자세한 내용을 읽어보십시오.
이 중앙 집중화의 어느 정도가 MEV에 의해 주도됩니까? MEV-Boost가 모든 검증자에게 모든 MEV에 대한 공정한 액세스를 제공한다는 점을 감안할 때 이러한 중앙 집중화는 다른 요인으로 인한 것임에 틀림없습니다. 유효성 검사기가 많을수록 유효성 검사기를 제안자로 선택하는 빈도가 높아집니다. 현재 적어도 일주일에 한 번 제안자로 선출될 확률은 10%입니다.
slots_per_week = seconds_per_week / seconds_per_slot = ( 60* 60* 24* 7) / 12
( 1 / number_validators) * slots_per_week = ( 1 / 479652) * 50400 = 0.1
여기여기이 현상에 대한 Flashbots의 분석을 확인하십시오.
이미지 설명
비콘 체인 예금에 대한 변경 사항
이것은 MEV-Boost가 작동하고 앙상블의 모든 유효성 검사기에 MEV를 균등하게 분배하고 있음을 보여줍니다. 물론 합병 이후 검증자 점유율에 변화가 없는 것은 MEV-Boost의 채택률이 낮거나 검증자에게 지급되는 MEV의 양이 매우 적기 때문일 수 있습니다. 이 두 가지 지표를 자세히 살펴보면 이것이 이유가 아님을 알 수 있습니다.
이미지 설명
MEV-Boost 채택 변경, 출처: https://dune.com/queries/1279670/2192739
이미지 설명
검증자에게 지급되는 보상, 출처: https://dune.com/queries/1279670/2192739
물론 실행 계층 보상에는 블록의 모든 거래에 대한 선호 수수료와 그 위에 캡처된 모든 MEV가 포함됩니다. 합병 후 검증인 집중도 변화가 없는 것이 MEV 수가 적어서인지 판단하기 위해서는 MEV를 우선 수수료와 별도로 살펴봐야 합니다. 다행스럽게도 Flashbots의 좋은 친구들은이미 마쳤어. 그들의 데이터 분석에 따르면 MEV는 유효성 검사기에 대한 모든 지불 보상의 73%를 차지합니다.
이러한 모든 메트릭을 종합하면 MEV가 유효성 검사기 세트 전체에 상당히 균등하게 분산되어 중앙화를 완화하는 그림이 그려집니다.
인출은 지분 분배에 어떤 영향을 미칩니까?
이것은 흥미로운 질문입니다. 스테이커가 한 스테이킹 공급자에서 다른 공급자로 이동하는 것을 볼 수 있습니까? 현재 모든 스테이커가 잠겨 있습니다. 인출이 활성화되면 스테이킹 풀 간의 경쟁이 심화됩니다. 이 시점에서 스테이킹된 주식의 자발적인 재분배를 볼 수 있습니다.
이것이 일어날지 여부와 그 방법은 단지 추측일 뿐이지만 많은 사람들이 APR만을 기반으로 자금을 이동하거나 유동성 담보 파생 상품 계약에 의해 더 많은 시장 점유율이 끌어당기는 것을 보게 될 것입니다. Ethereum에서 인출이 활성화되면 분산 유효성 검사기 기술이 실행되고 실행되는 것을 볼 수 있습니다.Obol또는SSV회로망.
리피터 집중화
이미지 설명
릴레이어가 처리하는 블록 분배, 출처: https://www.mevboost.org
이것은 Ethereum 인프라의 매우 중요한 구성 요소가 집중되어 있음을 분명히 보여줍니다. 그것은 이상적이지 않으며 미 재무부(특히 OFAC)가 Tornado Cash에 제재를 가한 8월에 이러한 수준의 중앙 집중화에 대한 잠재적인 문제가 집중되었습니다. 그들은 SDN 목록에 다수의 Tornado Cash 관련 스마트 계약 주소를 추가했습니다. 이로 인해 오싹한 효과가 있었고 많은 조직이 dapp UI, GitHub 리포지토리 및 물론 RPC 엔드포인트 공급자를 제거하여 Tornado Cash로 전송된 모든 트랜잭션을 검열했습니다.
OFAC가 실제로 Tornado Cash에 대한 액세스를 실제로 차단할 수 없다는 사실을 알고 있었는지 여부는 불분명하지만(스포일러 경고: 여전히 적극적으로 사용되고 있음) 이러한 계약 주소를 SDN 목록에 추가하면 냉각 효과가 예상됩니다. 많은 MEV-Boost 릴레이어가 Tornado 거래를 심사하기 시작했습니다(감옥에 갈 위험을 감수하거나 막대한 벌금을 지불하는 대신). 그 중 하나는 Flashbots 릴레이였습니다. 즉, 이 글을 쓰는 시점에 이더리움의 모든 블록 중 75%가 검토되고 있습니다.
이 검열은 Tornado Cash(또는 검열되는 다른 계약)에 대한 액세스를 막는 것이 아니라 Tornado Cash로의 라우팅을 몇 블록 지연시킬 뿐이라는 점에 유의하는 것이 중요합니다. 저스틴 드레이크는 이것을 "약한 검열접근을 전면 차단하는 '강력한 검열'에 반대한다. 그러나 현재 Tornado Cash를 사용하는 것은 실제로 문제가 되지 않으며, 문제는 Ethereum이 권위주의 정부의 법령을 시행할 경우 신뢰할 수 있는 중립 플랫폼이라고 주장할 수 없다는 것입니다. 이로 인해 MEV-Boost 릴레이의 중앙 집중화가 문제가 됩니다.
MEV-Boost 릴레이를 중앙 집중화하게 된 계기는 무엇입니까?
파트 1에서 mev-hiding 현상과 이것이 어떻게 스테이킹 풀과 릴레이어 간의 신뢰 관계로 이어질 수 있는지 설명했던 것을 기억하십니까? 스테이킹 풀은 일반적으로 노드 운영자가 특정 릴레이에 연결하는 것을 선호하므로 검증자에게 지급되는 MEV의 양을 추적할 수 있습니다. 이는 검증자에게 전달되지 않은 노드 운영자에 대한 잠재적 지불을 식별하기 위한 것입니다. 이것은 물론 중계 중앙화에 기여하는 요인입니다. 즉, 빌더가 가치 있는 블록을 생성하면 확립되고 신뢰할 수 있는 중계를 사용하기가 더 쉬워집니다.
블록 빌더의 중앙 집중화
놀랍게도 제3자 블록 빌더가 네트워크에 제안한 블록의 분포는 실제로 상당히 균등합니다. 나는 네트워크 효과가 소수의 주요 블록 빌더의 출현만을 견인할 것이라고 예측했으며, 사실 단일 블록 빌더의 출현을 완전히 배제하지도 않았습니다.
이미지 설명
11월 21일부터 28일까지 블록 빌더 배포. 출처: https://www.relayscan.io/
이것은 여전히 개선될 수 있지만 대부분의 블록을 생산하는 두 개의 주요 풀 운영자가 있는 PoW의 중앙 집중화보다 훨씬 나쁘지 않습니다.
이미지 설명
네트워크에 제안된 블록 공유 분배, 출처: https://dune.com/queries/1306635/2237247
보시다시피 한때 Flashbot은 MEV-Boost 블록의 60% 이상을 구축했습니다. 이 수치를 유효성 검사기의 총 MEV-Boost 채택과 결합하면 어느 시점에서 Flashbots가 이더리움 블록의 약 30%를 생성했음을 알 수 있습니다. 어느 정도 예상은 했지만 당시에는 이러한 추세가 계속될 것으로 보였기 때문에 걱정스럽기도 했습니다.
이미지 설명
이미지 설명
출처: https://dune.com/queries/1306635/2237247
이미지 설명
블록 빌더 수의 변화, 출처: mevboost.org
이더리움의 미래는?
MEV-Boost는 단순한 소프트웨어가 아니라 Ethereum 인프라의 중요한 부분임이 분명합니다. Flashbot이 만든 것은 웹 디자인 방식을 근본적으로 바꿔 놓았습니다. 앞으로 Flashbots는 MEV-Boost의 관리 및 거버넌스가 커뮤니티의 책임이 되기를 원합니다.
10월 초, Flashbots더 많은 지역 사회 참여를 요청하십시오, 그리고 긍정적인 반응을 받았습니다. 많은 조직이 MEV-Boost의 지속적인 관리 및 개발에 기여하기 위해 나섰습니다.
부분 블록 경매, 트랜잭션 포함 목록, 새로운 트랜잭션 유형 등을 구현하는 방법에 대한 향후 결정이 내려질 것입니다. 더 많은 사람들이 프로세스에 참여하고 기여하는 것을 볼 수 있기를 바랍니다.
이미지 설명
이더리움 로드맵, 출처: https://twitter.com/vitalikbuterin/status/1588669782471368704
프로토콜 내 PBS(제안자-빌더 분리)
PBS는 디자인 철학이며, PBS를 구현하는 방법에는 여러 가지가 있으며, 이를 연구할 이유도 많습니다.
PBS는 원래 MEV의 중앙 집중화 효과를 완화하는 방법으로 제안되었습니다. 경험이 풍부한 전문가에게 MEV 추출을 아웃소싱하고 모든 검증자에게 아웃소싱 서비스에 대한 동등한 액세스 권한을 부여하면 스테이킹 풀이 규모의 경제에서 이익을 얻어 점점 더 큰 검증자가 세트를 공유하는 것을 방지할 수 있습니다.
PBS는 또한 확장성(예: 단크샤딩)에 영향을 미칩니다. 대규모 댄샤딩 블록을 만드는 것은 모든 검증자가 할 수 있는 일이 아닙니다. PBS가 없으면 네트워크의 유효성 검사기 수가 크게 줄어들 수 있으므로 PBS는 다크샤딩을 활성화하는 핵심으로 간주됩니다.
MEV-Boost는 "proto-PBS" 또는 프로토콜 외부에 존재하는 PBS로 생각할 수 있습니다. 어떻게 보면 아이디어에 대한 좋은 테스트라고 볼 수 있습니다. 그러나 이 접근 방식의 문제점은 MEV-Boost 릴레이어를 블록 빌더와 제안자가 신뢰하는 신뢰할 수 있는 위치에 두는 것입니다. 일종의 보호된 PBS가 없으면 제안자가 빌더의 블록이 해제되고 지불을 받을 것임을 확신할 수 있는 신뢰할 수 없는 방법이 없으며 빌더가 자신이 블록을 차단하는지 확인할 수 있는 신뢰할 수 없는 방법이 없습니다. 도난당하지 않았습니다.
그래서 어떤 식으로든 PBS가 협정에 포함될 가능성이 있어 보이지만 그렇게 하겠다는 제안이 많기 때문에 현재로서는 어떻게 될지 불분명합니다.
프로토콜에서 PBS를 구현하는 방법에 대한 현재 아이디어에 대한 자세한 내용은 다음 스레드에 설명된 아이디어를 참조하십시오.
기타 방향: 부분 블록 경매
우리가 본 바와 같이 블록의 전체 콘텐츠 구성을 제3자 블록 빌더에게 아웃소싱하면 블록 콘텐츠에 대한 일관되지 않은 선호도가 발생할 수 있습니다.
솔루션은 종종 부분 블록 경매라고 하는 아이디어인 블록 콘텐츠의 일부만 구성을 아웃소싱하는 것으로 보입니다.
이 문제를 해결하는 방법에는 여러 가지가 있지만 모두 아이디어를 중심으로 돌아가는 것 같습니다. 제안자는 트랜잭션을 포함하는 블록 접두사 또는 접미사를 만들고 블록의 나머지 트랜잭션은 블록 빌더에서 가져옵니다. 현재 우리는 여러 블록 빌더가 단일 블록에 트랜잭션을 기여하도록 허용하는 제안을 보지 못했습니다.
Eigenlayer는 인기를 얻고 있는 것으로 보이는 접근 방식을 제안하며 재지정 메커니즘을 사용합니다.
재저당에 의한 부분 블록 경매
remortgaging의 아이디어는 매우 간단합니다. 검증인이 프로토콜에 등록하면 예금 계약에 32 ETH를 입금하고 출금 자격 증명을 제공하여 검증인이 스테이킹 해제를 원하는 경우 출금 주소를 지정합니다.
Rehypothecation은 스마트 계약 주소를 출금 주소로 제공한다는 아이디어를 기반으로 합니다. 검증인이 스테이킹을 해제하면 이 재스테이킹 스마트 계약으로 잔액을 인출한 다음 지분과 검증인 보상을 받기 위해 종료해야 합니다.
이를 통해 스마트 계약은 유효성 검사자에게 추가 페널티를 부과할 수 있으므로 유효성 검사자의 지분과 전체 보상을 받으려면 유효성 검사자로서 한 약속을 이행해야 합니다. 실제로 Eigenlayer는 "미들웨어"라고 부르는 다양한 재지정 계약의 공식화를 허용합니다. 이런 식으로 Eigenlayer는 "프로그래밍 가능한 클리핑 프로토콜"로 생각할 수 있습니다.
검증자가 서명할 수 있는 약속의 예는 검증자가 블록 자체의 일부를 생성하고 블록 빌더가 다른 부분을 생성하도록 허용할 수 있는 부분 블록 경매입니다. 유효성 검사기는 블록 빌더가 블록의 임의 크기 부분을 생성하고 나머지는 스스로 제안하도록 허용할 수 있습니다.
이 설정에서 MEV-Boost 릴레이는 트랜잭션의 빌더 부분을 저장하고 트랜잭션의 Merkle 루트를 검증자에게 전달합니다. 설명된 설정은 여전히 중앙의 신뢰할 수 있는 릴레이에 의존하지만 유효성 검사기는 문제가 발생할 경우 제안할 수 있는 백업 블록을 유지 관리합니다. 또한 Eigenlayer는 데이터 가용성 계층으로 설계된 다른 미들웨어를 사용하여 신뢰할 수 있는 릴레이어를 완전히 제거할 수 있습니다.
빌더는 이 데이터 가용성 미들웨어를 사용하여 블록 부분을 "데이터 가용성 중재자"에게 보냅니다. 단일 노드가 블록에 대한 정보에 액세스할 수 없도록 DA 쿼럼의 노드에 블록을 비밀리에 공유하여 이를 수행합니다. 쿼럼 노드는 받은 비밀 블록에 서명하고 빌더에게 반환합니다. 그런 다음 빌더는 집계된 서명의 형태로 "인증서"를 생성하고 제안자에 대한 입찰에 포함합니다. 제안자는 유효한 인증서가 있는 모든 입찰 중에서 가장 높은 입찰가를 선택하고 해당 입찰에 포함된 블록 헤더에 서명합니다. 그런 다음 제안자는 이 서명된 블록 헤더를 DA 중재자에게 보냅니다. 중재자는 각각의 비밀 블록을 제안자에게 게시하고 이제 블록의 빌더 부분을 재조립할 수 있습니다.
이 접근 방식은 두 가지 이유로 흥미롭습니다. 즉, 제안자가 자체적으로 일부 블록을 구성할 수 있으며, 이는 현재 이더리움에 영향을 미치는 검열 문제를 완화하는 데 도움이 되며 MEV-Boost 인프라를 분산시켜 중앙 집중식 중계자에 대한 의존성을 제거하는 데도 도움이 됩니다.
PEPC를 통한 부분 블록 경매
Barnabé Monnot도 수행했습니다.탐사, 프로토콜 수준에서 다시 스테이킹하는 형태를 구현합니다. 이를 통해 검증인은 제3자와 모든 유형의 일반적인 약속을 할 수 있으며 Eigenlayers가 계약/미들웨어를 다시 스테이킹할 필요 없이 증명 위원회가 프로토콜 수준에서 이 약속을 시행할 수 있습니다. 이 아이디어는 Protocol Enforced Proposer Commitment 또는 "PEPC"로 알려져 있습니다. Barnabé가 말했듯이 이 접근 방식의 주요 근거는 프로토콜이 얼마나 많은 유효성 검사기가 실제로 위험에 처해 있는지 더 이상 알지 못할 때 합의를 불안정하게 만들 수 있다는 것입니다(Eigenlayer가 프로그래밍 방식으로 유효성 검사기 종료를 트리거하는 것을 포함하여 이 시나리오에 대한 또 다른 완화 조치가 있다고 생각하지만) .
PEPC는 스테이킹과 거의 같은 방식으로 부분 블록 경매를 용이하게 합니다. 단, 프로토콜이 어떤 검증인이 삭감되고 있는지, 어느 정도까지 삭감되는지 추적할 수 있다는 점이 다릅니다. 물론 이것은 프로토콜을 적용한 제안자 약속이 스마트 계약을 재지정하는 것보다 유효성 검사자와 제3자에게 더 매력적이라고 가정합니다.
프로토콜 수준 부분 블록 경매
이 형식의 분수 블록 경매는 PBS의 crLists(검열 저항 목록)에 대한 대안으로 제안되며, 이에 대해서는 나중에 자세히 살펴보겠습니다. 이 계획에서 부분 블록 경매는 프로토콜 자체에 의해 촉진됩니다. 이 아이디어로 제안자는 접두사 또는 접미사를 제공할 수 있습니다. 기본적으로 빌더가 블록의 일부를 제공하고 제안자가 나머지를 제공한다는 의미입니다. 비탈릭에 대해 이야기예를 들어, 이는 제안자에게 추가 부담을 부과하여 궁극적인 무국적자로의 진행을 방해할 수 있습니다.
트랜잭션 포함 목록/crLists/하이브리드 PBS
거래 포함 목록인 crLists는 제안자가 실제로 블록 자체의 일부를 제공할 필요 없이 블록 빌더의 거래 검열을 용이하게 하는 방법입니다.
높은 수준에서 아이디어는 제안자가 유효한 거래 목록(즉, 유효한 논스, 서명, 잔액, maxFeePerGas 등) 블록을 생성할 수 있도록 하는 것입니다.
이것은 보이는 것처럼 간단하지 않으며 이 방법에는 다양한 변형이 있습니다. crLists 접근 방식의 모든 변형은 프로토콜이 빌더가 전체 블록 또는 목록을 포함하는 제안자를 수락하는 블록을 생성하도록 강제한다는 중심 원칙에 수렴하는 것 같습니다.
이에 대한 이론적 근거는 빌더가 사용 가능한 모든 블록 공간을 사용하지 않는 블록을 생성하는 경우 mempool에 이를 포함할 수 있는 트랜잭션이 있음에도 불구하고 합리적인 빌더가 어떤 이유로 트랜잭션을 검열하고 있다고 가정할 수 있다는 것입니다. , 사용 가능한 모든 거래를 제외하면 테이블에 돈이 남을 뿐이므로 이는 비합리적입니다. 블록 빌더가 생성한 블록이 사용 가능한 공간을 모두 사용하지 않는 경우 생성한 블록이 crList에 트랜잭션을 포함하지 않을 이유가 없습니다.
이 체계에서 crList의 트랜잭션을 포함하는 트랜잭션의 검열을 피하기 위해 빌더는 블록을 제안자와 네트워크에서 승인할 수 있도록 가스 한도까지 블록을 채워야 합니다. 이를 위해서는 블록 자체를 임의 트랜잭션으로 채워야 합니다. 이것은 한두 블록에 대해 경제적으로 실행 가능할 수 있지만 EIP-1559에 따라 블록 한도에 도달하면 기본 요금이 증가하므로 빌더가 거래에 대해 지불해야 함을 의미합니다. crLists를 포함하지 않으려면 더 많은 가스를 지불해야 합니다. 시간이 지남에 따라 기본 요금이 증가하면 대부분의 일반 거래가 블록에 포함되지 않으며, 따라서 빌더는 더 많은 공간을 "채워야" 합니다.
더 가능성 있는 시나리오는 블록 빌더가 crLists에 승인된 트랜잭션이 포함되지 않을 때까지 블록 생성을 포기하는 것입니다. 이는 비검열 빌더를 위해 블록 빌더 환경을 재조정해야 합니다.
이 접근 방식은 모두 이타주의에 의존하는 것 같습니다. crLists의 다양한 설계는 제안자가 crLists를 생성하는 데 비용이 많이 들지 않도록 하므로 이론적으로는 비용이 들지 않지만 crLists를 생성할 명확한 인센티브도 없습니다.
현재 슬롯의 제안자가 해당 슬롯에 대한 crList를 만드는 책임이 있는 경우 빈 목록을 만들 인센티브가 있습니다. 이렇게 하면 블록 빌더가 계속해서 가장 수익성 있는 블록을 만들 수 있기 때문입니다. 이는 주요 블록 빌더(일반적으로 가장 높은 가치의 블록을 빌드하는 사람)가 모두 검열될 때 특히 그렇습니다.
따라서 향후 슬롯을 위해 crList를 생성한다고 상상해 보십시오. 예를 들어, 현재 슬롯 2n의 제안자는 2n + 2에 대한 crList를 생성합니다. 이를 "정방향 포함 목록"이라고 합니다. 이렇게 하면 현재 슬롯의 제안자는 crList를 생성하여 금전적 불이익을 당하지 않습니다. 이것은 또한 제안자가 자신의 위치보다 먼저 crList를 게시하여 자신을 속이지 않기 때문에 단일 비밀 리더 선거 또는 SSLE와 호환되는 좋은 속성을 가지고 있습니다.
문서문서crLists 체계 설계를 요약한 변형의 전체 목록이 아닙니다.
열린 질문
위에 나열된 모든 아이디어는 활발히 논의 중이며 그 중 일부는 매우 유망한 것으로 나타났습니다. 그러나 몇 가지 질문이 있습니다. 검증자가 블록의 100%를 빌더에게 아웃소싱하지 않는 이유는 무엇입니까? 우리는 이타주의에만 의존하고 있습니까? 제안자가 부분 블록을 기여하기 위해 어떤 작업을 하도록 하는 인센티브는 무엇입니까? 유효성 검사기가 crList를 만드는 데 어려움을 겪는 이유는 무엇입니까? 이더리움 클라이언트가 기본적으로 이 작업을 수행하기 때문이라면 유효성 검사기가 이를 비활성화할 수 있는 옵션이 있습니까? 일부 스테이킹 풀의 노드 운영자가 승인된 트랜잭션을 포함하는 crList 또는 블록 접두사/접미사를 게시하는 것을 꺼릴 것이라고 상상할 수 있습니다.
잘못 정렬된 인센티브는 어떻습니까? 제안자가 블록의 일부를 제공하는 경우 빌더가 MEV를 포크하는 데 사용할 수 있는 귀중한 블록 공간을 빼앗아 갑니까? 블록을 채울 트랜잭션이 충분하지 않더라도 제안자는 빌더의 번들과 충돌하지 않는 트랜잭션을 선택하도록 주의해야 합니다.
crList에 관한 한 제안자가 P2P 네트워크에 crList를 게시하지 않으면 어떻게 됩니까? 이것이 합의에 의해 시행될 수 있습니까? 여기에는 내가 링크한 일부 원본 자료에서 이미 언급한 복잡성을 추가하는 강력한 동기화 가정이 있습니다.
결론적으로
결론적으로
이것들은 이 글을 쓰는 동안 떠오른 몇 가지 질문일 뿐이며, 나보다 똑똑한 사람들의 더 어려운 질문이 있습니다. 따라서 보시다시피 특정 방향이나 접근 방식을 설정하기 전에 해결해야 할 열린 질문과 잠재적인 문제가 여전히 많이 있습니다. 이와 관련하여 효과적인 솔루션이 등장하기까지 몇 년이 걸릴 수 있으며 그때까지 전체 MEV 환경이 매우 다르게 보일 수 있습니다.
원본 링크
