저자: 0xNatalie
이더리움 블록 생성 및 검증 과정에서 빌더는 거래 풀에서 거래를 선택 및 정렬하고 경매 메커니즘을 통해 제안자에게 블록을 제출할 책임이 있습니다. 제안자는 제출된 블록 중 하나를 선택해 블록체인에 서명하고 제안합니다. 제안자가 단일 주체로서 최종 선택권을 가지므로, 제안자와 빌더가 거래를 검열하기 위해 공모할 수 있는 위험이 있습니다.
블록체인의 핵심 가치 중 하나는 검열 저항성이라는 점으로, 이는 중앙 기관의 간섭 없이 누구나 거래를 할 수 있다는 것을 의미합니다. 이 기능은 제안자가 블록에 포함될 트랜잭션을 통제할 수 있게 되면 위협을 받게 됩니다. 공정성과 투명성이 훼손됩니다. 또한 이러한 권한은 추가적인 금전적 이득을 위해 블록 내 거래 순서를 조작하는 데 사용될 수 있으며, 이는 MEV 문제를 야기합니다.
기존 검열 방지 솔루션
이 문제를 해결하기 위해 커뮤니티에서는 필수 포함 목록(FOCIL)과 같은 다양한 검열 방지 솔루션을 고안해냈습니다. FOCIL 메커니즘에서는 각 슬롯에서 무작위로 검증자 그룹을 선정하여 포함 목록 위원회를 구성합니다. 이 위원회는 트랜잭션 풀(멤풀)에 대한 각자의 주관적인 견해를 바탕으로 로컬 포함 목록을 생성하고 이를 브로드캐스트합니다. 그런 다음 제안자는 이러한 로컬 목록을 수집하고 집계하여 집계된 목록을 만들어 블록에 포함시킬 책임이 있습니다. 이 메커니즘은 검증자가 이전에 브로드캐스트된 로컬 목록을 기반으로 집계된 목록의 정확성을 검증하고 합의 규칙을 준수하는 블록만 승인되어 블록체인에 추가되기 때문에 블록의 공정성을 보장합니다.
커뮤니티에서는 FOCIL 외에도 다중 동시 제안자(MCP) 옵션에 대해서도 논의했습니다. 이 개념은 다중성 메커니즘에서 맥스 레스닉(Max Resnick)이 처음 제안한 것으로, 다수의 병렬 블록 제안자를 도입하여 권한을 분산함으로써 단일 노드가 거래를 면밀히 조사할 수 있는 능력을 줄이기 위해 고안되었습니다. 다중성 메커니즘에서 각 검증자는 자체 트랜잭션 풀에서 트랜잭션의 일부를 선택해 '특별한 트랜잭션 패키지'를 구성합니다. 이러한 검증자는 자신이 선택한 패키지에 서명하고 현재 라운드의 제안자에게 보냅니다. 이를 받은 제안자는 자신이 제안한 블록에 이 패킷의 2/3 이상을 포함시켜야 합니다. 그래야만 블록이 유효한 것으로 간주됩니다. 이 메커니즘은 제안자가 블록의 내용을 단독으로 결정할 수 없도록 하여 검열의 가능성을 줄여줍니다. 제안자가 거래를 공정하게 포함하도록 장려하기 위해 이 메커니즘은 '조건부 팁' 규칙을 구현하여 거래를 포함하는 제안자만 거래의 팁을 분배받도록 합니다. 거래를 처음 포함한 제안자에게 자동으로 거래 전체가 팁으로 지급되는 대신, 특정 조건에 따라 실제로 거래를 포함한 모든 제안자에게 거래 팁이 분배됩니다. 이렇게 하면 심사 비용이 증가하므로 거래를 심사하려면 거래를 포함한 모든 제안자에게 뇌물을 주어야 합니다.
BRAID: 개선된 MCP 구현
멀티플리시티를 기반으로 Max Resnick은 훨씬 더 복잡하고 MCP의 구현입니다. 패러다임의 "MEV 시대의 탈중앙 금융" 세미나에서 Max는 여러 제안자가 서로 다른 병렬 체인에서 블록을 제안할 수 있고 동기 합의를 사용해 체인 간 일관성을 유지하며, 각 체인마다 자체 제안자가 있고 모두 같은 슬롯에 블록을 동시에 게시하는 방식으로 MCP를 구현하는 BRAID를 소개했습니다. 각 체인에는 자체 제안자가 있으며, 모든 제안자는 동일한 슬롯 내에서 동시에 블록을 공개합니다. 이더리움 실행 레이어는 해당 슬롯 내의 모든 서브체인에서 생성된 블록 트랜잭션을 실행 블록으로 집계하고, 미리 정의된 규칙에 따라 가중치를 제거하고 정렬하여 실행하므로 단일 주체가 트랜잭션 기록을 조작할 수 있는 능력을 감소시킵니다.
BRAID의 설계는 추가 역할을 도입하지 않으므로 인센티브/불인센티브 메커니즘의 복잡성을 피하지만, 구현이 상대적으로 복잡하여 여러 하위 체인에서 동기화 및 데이터 처리의 조정을 필요로 합니다.
<그림>
BRAID 메커니즘의 문제점
블록체인 캐피탈 팀(Jonahb)은 '조건부 팁' 모델에 사용자 경험에 영향을 미치는 유동성 요건이 있다는 점을 지적하며 BRAID 메커니즘의 문제점을 지적했습니다. 요구 사항이 있어 사용자 경험에 영향을 미칩니다. 이 모델은 동적 가격 책정 전략으로, 거래가 검열에 저항할 수 있도록 사용자가 일정량의 유동성을 보유하도록 요구합니다. 사용자는 트랜잭션을 제출할 때 두 가지 팁 값(T와 t)을 설정해야 합니다. 실제 지급되는 팁은 트랜잭션에 포함된 제안자 수에 따라 달라집니다.
높은 팁 T: 사용자가 거래가 검열되지 않도록 하기 위해 지불할 의사가 있는 가장 높은 수수료를 나타냅니다. 다른 제안자가 거래를 포함시키지 않으려는 경우 제안자가 거래를 포함하도록 장려하는 것이 목적입니다. 궁극적으로 한 명의 제안자만 트랜잭션을 포함할 의향이 있다면 그는 T를 받게 됩니다.
하한 팁 T: 사용자가 설정한 낮은 금액으로, 두 명 이상의 제안자가 동시에 거래를 포함할 경우 사용자는 T만 지불합니다. 를 여러 제안자에게 나눠서 지불합니다. 사용자가 검열에 신경 쓰지 않는다면 T=t로 설정하고 한 명의 제안자에게만 트랜잭션을 보낼 수 있습니다.
그러나 이러한 추가 유동성 요구 사항은 블록체인 거래 참여의 복잡성과 비용을 증가시키며, 사용자는 검열에 저항하기 위해 거래 시점에 추가 금액을 따로 준비해야 합니다. 이렇게 준비된 자금은 실제로 사용될 때까지 동결됩니다.
이에 대해 Jonahb는 두 가지 해결책을 제안했습니다.
포스트 스테이트 유동성 증명. 증명): 사용자가 트랜잭션을 제출할 때 트랜잭션이 실행된 후 T에 지불할 수 있는 충분한 유동성이 있다는 증명을 제공합니다(예: 사용자가 트랜잭션 후 100만 달러의 유동성을 보유할 것). 이렇게 하면 트랜잭션 전에 T를 지불할 자금이 충분하지 않더라도 사용자가 트랜잭션 후에 지불할 수 있다는 것을 증명하면 트랜잭션이 실행된 후에 지불할 수 있습니다. 이 접근 방식의 문제점은 제안자가 거래가 실행되기 전에 거래의 최종 상태를 알아야 하지만 대부분의 금융 거래에는 공유 상태(예: 동일한 계좌 잔액을 공유하는 여러 거래)가 포함되므로 제안자는 거래 순서가 결정될 때까지 거래 후 상태를 정확하게 파악할 수 없다는 것입니다. 이는 각 거래 유형에 대한 맞춤형 증명이 필요하며 실용성이 떨어집니다.
검열 보험: 제3자 검열 보험 공급자(CI 공급자)를 도입하여 사용자의 T를 보장하고, 사용자는 이에 대한 프리미엄 rT를 지불합니다. 사용자는 rT의 프리미엄을 지불하며, 여기서 r은 거래가 검토될 가능성에 따라 계산됩니다. 이 솔루션은 사용자가 즉시 많은 양의 유동성을 보유할 필요성을 줄여줄 뿐만 아니라 CI를 통해 T가 너무 낮아 검토될 위험이 높다는 것을 사용자에게 알려줍니다. 그러나 사용자와 CI 제공자 사이에 마켓플레이스를 구축하는 데는 시간이 걸립니다.
FOCIL과 BRAID에 대한 커뮤니티의 생각
이더리움 클라이언트 Prysm 개발자 테렌스는 BRAID의 중요한 장점 중 하나가 추가 참여자가 필요하지 않다는 점이라고 생각합니다. FOCIL을 포함한 대부분의 포함 목록(IL) 설계에서는 추가 참가자가 필요하며, 이로 인해 IL 제출 시간, 입찰 업데이트 시간, 검증자가 IL을 확인하는 시간 등 이더넷 시간 슬롯에 시간 제약이 추가됩니다. 그러나 FOCIL 방식은 BRAID보다 구현하기가 더 간단하고 유연합니다.
패러다임 연구원 댄 로빈슨은 트랜잭션의 우선순위를 리더(단일 제안자)의 재량에 맡기지 않고, 거래의 우선순위를 정하는 BRAID의 설계가 MEV를 효과적으로 완화한다고 평가합니다. 또한, BRAID의 조건부 의 조건부 팁 메커니즘은 검열되지 않은 행동에 인센티브를 제공하며, 이는 FOCIL에 반영되지 않습니다.
개발자 '개발자'는 MCP보다 FOCIL을 선호하며 FOCIL이 강력한 저항을 제공하고 구현을 간소화하는 이점이 있다고 생각합니다. 그는 FOCIL을 더 쉽게 구현할 수 있도록 몇 가지 개선 사항을 제공합니다.
이더 펠로우(barnabe.eth)는 FOCIL이 상당히 다재다능하고 확장 가능한 메커니즘이라고 믿으며, BRAID가 어떤 면에서 FOCIL이 제공하는 보증을 개선할 가능성이 있다고 인정하지만 리더 기반 모델을 완전히 포기하는 것은 경계하고 있습니다. 리더 기반 모델은 현재 합의된 모델이 아니며 실행 가능성을 입증하기 위해 더 많은 작업이 필요하다고 주장하며 신중한 입장을 취하고 있습니다.