오늘날 운영되는 분산형 합의 네트워크에 대한 중대한 위협은 다음 블록의 콘텐츠를 선택할 수 있는 능력에서 이익을 추출하는 복잡한 기술인 채굴자 추출 가능한 가치의 경제학과 관련이 있습니다. 간단한 MEV 예는 이전 블록의 가격 움직임을 기반으로 하는 모든 온체인 분산형 거래소 간의 차익 거래입니다. 일반적으로 PoS 보상은 합리적이고 균등하지만, 즉 단일 유효성 검사기의 수익률은 강력한 스테이킹 풀과 동일하지만 복잡한 MEV 추출 기회를 찾는 것은 상당한 규모의 경제를 가져왔습니다. 10배 더 큰 풀은 MEV를 추출할 기회가 10배이지만 풀은 또한 기회당 더 많은 가치를 추출하기 위해 독점 최적화에 더 많이 투자할 수 있어야 합니다.

이 문제 외에도 MEV는 탈중앙화 스테이킹 풀을 복잡하게 만듭니다. 왜냐하면 탈중앙화 스테이킹 풀에서는 트랜잭션 패키징과 블록 제안이 여전히 엔터티에 의해 수행되어야 하고 MEV를 비밀리에 쉽게 인출할 수 있기 때문입니다.이러한 수익을 풀에 분배하는 대신.

가장 잘 알려진 솔루션은 제안자/블록 빌더 분리입니다. 블록 제안자 스스로 수익 극대화 블록을 생성하는 대신 완전한 블록 콘텐츠와 블록 제안자에 대한 수수료를 포함하는 트랜잭션 번들을 생성하는 외부 블록 빌더로 구성된 시장에 의존합니다. 그런 다음 제안자는 가장 높은 수수료가 포함된 트랜잭션 번들을 선택합니다. 이러한 방식으로 블록 제안자의 선택은 수수료가 가장 높은 트랜잭션 번들을 선택하는 것으로 축소되며 간단한 알고리즘으로 구현할 수 있습니다. 부정 행위를 방지합니다.

이 문서에서는 이를 달성하는 방법에 대한 몇 가지 디자인을 제안합니다.

첫 번째 레벨 제목

Optimised proposal commitment scheme 20

제안자/빌더 분할 블록 제안 디자인의 원하는 속성

우리가 집중할 상위 5가지 기능:

• 제안자의 친근함을 신뢰할 필요가 없습니다. 제안자가 블록 빌더를 괴롭힐 위험은 사실상 제로이므로 블록 빌더는 서약 풀이 있는 오프체인 제안자를 선호할 인센티브가 없습니다.
  

• 빌더 친근함을 신뢰할 필요 없음: 빌더가 제안자를 괴롭힐 위험은 거의 제로이므로 제안자는 명성이 있는 오프체인 빌더 또는 빌더와의 개인적 관계를 선호할 인센티브가 없습니다(이로 인해 새로운 빌더가 시장에 진입할 수 있으므로 선택되지 않음) ).
  

• 약한 제안자 친화성: 이 메커니즘은 제안자에게 (i) 높은 대역폭 또는 기타 컴퓨팅 리소스 또는 (ii) 높은 기술을 요구하지 않아야 합니다.
  

• 훔칠 수 없는 트랜잭션 번들: 제안자는 블록 빌더가 제안한 트랜잭션 번들을 수락하고 트랜잭션을 추출하여 자신의 트랜잭션 번들을 형성할 수 없어 블록 제안자가 이익을 얻는 것을 방지할 수 있습니다.
  

• 첫 번째 레벨 제목

아이디어 1

• 블록 빌더는 트랜잭션 번들을 빌드하고 이러한 트랜잭션 번들에 대한 번들 헤더를 게시합니다. 번들 헤더에는 번들 본문(예상되는 블록 콘텐츠)에 대한 약속, 제안자에 대한 지불 정보 및 빌더의 서명이 포함됩니다.
  

• 제안자는 가장 높은 수수료를 제공하는 번들 헤드를 선택합니다(번들 제작자가 실제로 지불할 충분한 잔액이 있는지 여부만 고려하면 됨). 거래 헤더에 서명하고 거래 헤더가 포함된 제안서를 발행합니다.
  

• 서명된 제안서를 보면 패키지 트랜잭션 번들 헤더를 제공한 블록 빌더가 전체 트랜잭션 번들을 게시합니다.

이때 포크 선택 규칙은 다음 세 가지 판단 중 하나를 내릴 수 있습니다(일반적인 두 가지 대신 블록 있음 vs. 없음).

• 차단 제안이 없습니다.

• 블록 제안이 있지만 트랜잭션 번들 본문이 없습니다.

• 블록 제안과 트랜잭션 번들 본문이 모두 존재합니다.

분석하다

분석하다

5개 속성 중 3개는 표현하기가 매우 쉽습니다.

• 블록 제안자는 약속된 지불을 무조건 수락하므로 트랜잭션 번들이 제안자를 괴롭힐 수 없습니다.

• 세 단계 모두 매우 자동화되고 대역폭이 낮기 때문에 약한 제안자 친화성을 충족합니다.

• 제안자는 서명하려는 번들에 대한 정보를 볼 수 없으므로 번들 비도용성을 충족합니다.

합의 계층 속성과 무신뢰 제안자 친화성은 더 까다롭습니다. 이 설계는 실제로 포크 선택 메커니즘을 두 가지 옵션에서 세 가지로 변경합니다. 이는 제안자가 더 이상 이 메커니즘의 마지막 행위자가 아님을 의미합니다. 이론적으로 포크 선택이 의사 결정이라면 괜찮을 것이라고 추론할 수 있지만 이것은 여전히 ​​잠재적인 알려지지 않은 중요한 변화입니다.

블록 제안자는 트랜잭션 번들의 내용을 볼 수 없으며 트랜잭션 번들을 훔쳐 블록 빌더를 괴롭힐 수는 없지만 블록 빌더에 대해 보다 교묘한 공격을 실행할 수 있습니다. 그들은 슬롯의 끝에 제안을 게시하여 증명자가 (아마도) 제 시간에 제안을 볼 수 있도록 할 수 있지만 블록 빌더는 트랜잭션 번들 본문을 게시할 시간이 충분하지 않으므로 증명자가 제 시간에 거래 번들 본문을 볼 수 없습니다. 이는 블록 빌더에게 위험을 초래하고 신뢰할 수 있는 제안자를 선호하도록 권장합니다. 또한 악의적인 행위자가 마음에 들지 않는 블록 빌더에게 막대한 불이익을 줄 수 있는 대부분의 기회를 제공합니다.

이 문제를 완화할 수 있는 두 가지 방법이 있다고 생각합니다.

• 증명자는 제안을 수락하는 최대 시간과 트랜잭션 번들의 본문을 수락하는 최대 시간 사이에 2초의 지연이 있습니다. 증명자를 신뢰하면 블록 빌더가 자금을 잃을 위험이 여전히 존재하지만 기본적으로 문제가 해결됩니다. 또한, 증명자가 이런 방식으로 투표할 인센티브가 있는지는 불분명합니다(2초 연기 가능한 검증 기능에 대한 제안을 증명하도록 요청함으로써 증명자를 기다리게 할 수는 있지만).
  

• 트랜잭션 번들의 본문이 포함되지 않은 경우 제안자는 지불금의 절반만 받습니다(블록 빌더는 절반만 지불). 이로 인해 제안자의 사보타주 비용이 많이 들지만 블록 빌더의 사보타주도 비용이 많이 듭니다(두 경우 모두 비용이 충분히 높으면 일반적으로 익명의 행위자도 기물 파손 행위를 원하지 않을 것이라고 신뢰할 수 있습니다). 예를 들어 트랜잭션 번들에 대한 제안자 수수료가 1인 경우 블록 빌더는 1.05를 얻습니다.
  
  ○ 정직한 행동에 대한 건축업자와 제안자의 보수는 각각 0.05와 1입니다.
  
  첫 번째 레벨 제목

아이디어 2

• 블록 빌더는 트랜잭션 번들을 빌드하고 게시합니다. 트랜잭션 헤더에는 콘텐츠에 대한 약정, 제안자에 대한 지불 및 빌더의 서명이 포함됩니다.
  

• 제안자는 자신이 본 트랜잭션 번들을 선택하고 목록을 구성한 다음 목록을 구성하는 진술에 서명합니다.
  

• 이 진술을 보고 선출된 블록 빌더는 해당 거래 번들 본문을 게시합니다.
  

• 제안자는 이전에 커밋한 트랜잭션 헤더 목록 중 하나를 선택하고 이를 사용하여 제안을 발행합니다.

커밋 목록에 없는 트랜잭션 번들을 제안하는 동일한 슬롯의 모든 제안자는 퇴거되고 불이익을 받는 새로운 삭감 조건도 필요합니다.

분석하다

분석하다

마찬가지로, 5개 속성의 삼항식은 매우 쉽게 표시할 수 있습니다.

• 제안자는 제한된 기존 트랜잭션 번들 헤더 세트로 자신을 제한했을 때만 트랜잭션 번들의 본문을 볼 수 있기 때문에 트랜잭션 번들을 훔칠 수 없습니다.
  

• 완전한 트랜잭션 묶음이 패키징될 때까지 빌더가 제안자에게 비용을 지불하는 것은 불가능하므로 제안자는 경제적으로 빌더를 속일 수 없습니다.
  

• 시스템 설정이 여전히 메커니즘의 마지막 행위자로서 제안자이고 합의 규칙에 의해 결정된 내용이 변경되지 않았기 때문에 합의 기능은 변경되지 않습니다.

이 경우 두 가지 더 까다로운 속성은 약한 제안자 친화성과 신뢰할 수 없는 블록 빌더 친화성입니다. 이 계획에 대한 우려는 악의적인 블록 빌더가 높은 거래 수수료로 많은 제안을 하지만 이러한 거래 번들의 본문을 게시하지 않음으로써 제안자를 공격할 수 있다는 것입니다. 제안자가 허용되는 트랜잭션 번들의 수에 상한선이 있는 경우 이 공격은 모든 합법적인 트랜잭션 번들을 제외할 수 있으므로 제안자는 블록에 포함하도록 제안할 합법적인 트랜잭션 번들을 갖지 않습니다. 제안자가 수락할 수 있는 트랜잭션 번들의 수에 제한이 없는 경우 제안자에게 전송되는 전체 트랜잭션 번들 본문(각각 500kB)의 무한한 수가 있을 수 있으며, 이는 매우 많은 양의 대역폭을 필요로 합니다.

이 딜레마에 대한 한 가지 해결책은 엄격한 제한이 아닌 트랜잭션 헤더의 제출을 ​​어떻게든 속도 제한하는 것입니다.

• EIP-1559와 유사한 메커니즘(예: 슬롯당 8개의 트랜잭션 번들)을 통해 특정 요율로 조정된 트랜잭션 번들을 제출하는 데 수수료가 있습니다.
  

• 블록 제안자가 되려면 예치금(제안자가 지불을 보장하기 위해 필요함)과 포함되지 않은 트랜잭션 번들을 게시하지만 더 저렴한 번들을 포함하는 경우 다음 N에서 트랜잭션 번들을 제출할 수 없다는 규칙이 필요합니다. 슬롯.

이 경우에만 수수료가 공제됩니다. 트랜잭션 번들은 패키지되지 않지만 더 낮은 가격의 트랜잭션 번들은 패키지됩니다. 왜냐하면 이 특정한 경우에는 귀하가 악(또는 제안자가 악하거나 네트워크 상태가 좋지 않을 수 있기 때문)입니다. 좋은).

이것에 대한 선례가 있습니다; 이전 ENS 경매에는 낙찰되지 않을 것이 분명한 경우 누군가가 입찰을 하지 못하도록 0.5%의 낙찰자 수수료가 있었습니다.

그러나 이러한 기술은 제안자에 대한 신뢰 요구 사항을 도입할 수 있으므로 신중하게 처리해야 하며 트랜잭션 번들 패키징 실패에 대한 페널티가 너무 높지 않아야 합니다.

대안은 트랜잭션 번들 본문의 제한 없는 무료 게시를 허용하지만 본문이 네트워크 계층에서 브로드캐스트하도록 제한하는 것입니다. 간단한 알고리즘은 다음과 같습니다.

• 번들이 전파되기 위해 약간 지연된 최소 시간 제한을 추가합니다: 거래 가격이 가장 높은 번들은 0초, 두 번째로 높은 거래는 0.2초, 세 번째로 높은 거래는 0.38초, 일반적으로 k번째로 높은 거래 가격 거래 시간 2*[1−0.9^(k−1)]초입니다.
  

• 규칙 추가: 노드가 트랜잭션 수수료가 더 높은 트랜잭션 번들 바디를 이미 브로드캐스트한 경우 다시 브로드캐스트할 수 없습니다.

결론적으로

결론적으로

지금까지 위의 두 가지 방법으로만 이 문제를 해결할 수 있는지 여부는 알 수 없으며 다른 방법도 있을 수 있습니다. 두 가지 접근 방식 중 아이디어 (1)은 개념적으로 더 간단하지만 블록 빌더에게 위험을 초래하고 더 복잡한 포크 선택 규칙 요구 사항을 도입합니다. 아이디어 (2)는 포크 선택과 합의에서 더 간단하지만 악의적인 블록 빌더에 의한 DoS 공격에 대처하기 어렵고, 이 문제에 대한 어떤 해결책도 다른 문제에 저항하지만 최소화하는 방법을 생각할 수 있습니다. 지금까지는 어느 것이 더 나은지 아직 확실하지 않습니다.