빌더를 얼마나 제한할 수 있습니까?

https://ethresear.ch/t/how-much-can-we-constrain-builders-without-bringing-back-heavy-burdens-to-proposers/13808

제안자에게 무거운 부담을 지우지 않고 빌더를 얼마나 제한할 수 있습니까?

빌더 중앙 집중화(주로 검열이지만 다양한 형태의 경제적 착취)의 위험에 대한 자연스러운 반응 중 하나는 빌더가 가진 권한을 제한하는 것입니다. 건축업자가 전체 고삐를 건설하는 대신전체 블록이 경매에서 이기면 빌더는 더 제한된 권한을 갖게 됩니다. 이 힘은 여전히 캡처할 수 있는 거의 모든 MEV를 캡처하기에 충분해야 하며 이상적으로는 여전히 PBS의 다른 이점을 캡처하기에 충분해야 하지만 남용 기회를 제한하기 위해 약화되어야 합니다.

이 아이디어는 부분 블록 경매라고도 합니다. 블록의 모든 것을 결정할 권리를 경매하는 대신 결정권을 경매합니다.몇 가지 , 그 "일부 것"은 예보다 훨씬 더 미묘한 차이가 있을 수 있습니다. "빌더는 블록의 첫 번째 절반을 선택하고 두 번째는 선택하지 않습니다": 빌더에게 재정렬, 앞에 추가, 추가할 수 있는 권한을 부여할 수 있으며 제안자를 제한할 수도 있습니다. 이 게시물은 이 작업을 수행할 수 있는 몇 가지 가능한 방법과 그에 따른 장단점에 대해 설명합니다.

포함 목록

포함 목록 패러다임에서 제안자는포함 목록 , 빌더가 블록을 채울 수 있는 경우가 아니면 요구하는 트랜잭션 목록이 블록에 포함되어야 합니다.완전히 다른 거래와.

비정상적인 외부 인센티브의 영향을 받지 않는 이익 극대화 빌더의 경우 포함 목록은 전혀 제약이 없습니다. 블록 끝에 추가 트랜잭션을 추가하면 항상 해당 트랜잭션의 우선 수수료를 추가 이익으로 빌더에게 제공합니다.

블록이 전체 가스 한도(목표의 2배)까지 채워져 빌더가 해당 트랜잭션과 다른 트랜잭션 중에서 선택해야 하는 경우 제약 조건이 비활성화됩니다. 전체 블록 실행은 기본 수수료를 기하급수적으로(6 블록마다 ~2.02x) 상승시키기 때문에 잠시 동안만 유지될 수 있기 때문에 장기적으로 포함에는 영향을 미치지 않습니다.

그러나 빌더가 승인하지 않았거나 제외하도록 유인이 있는 특정 트랜잭션을 포함하는 것을 거부하려는 경우 해당 빌더는 경매에 참여하지 않을 수 있습니다.

이 디자인은 합리적으로 단순하지만 일부 약점을 설명하는 것이 중요합니다.

• 인센티브 호환성 문제 : 빌더는 미리 포함 목록을 확인하고 빌더는 빌드하고 싶지 않은 포함 목록이 포함된 블록 빌드를 거부할 수 있습니다. 이것은 빌더가 블록을 구축할 기회를 최대화하기 위해 제안자가 빈 포함 목록을 갖도록 즉각적인 인센티브를 생성합니다.
• 제안자에 대한 추가 부담 : 제안자는 수수료 지불 거래를 식별할 수 있어야 합니다. 이를 위해서는 (i) mempool에 대한 액세스 및 (ii) 수수료 지불 여부를 결정하기 위해 상태를 읽을 수 있는 기능 또는 거래에 첨부된 증인이 필요합니다. 검증자가 상태 비저장 클라이언트가 될 수 있다는 PBS 속성을 보존하므로 목격자가 선호됩니다.
• 빌더는 여전히 일부 남용에 관여할 수 있습니다. : 특히 샌드위치 공격. 그러나 mempool을 암호화하기 위해 고급 암호화를 사용하는 것과 같은 극단적인 접근 방식 없이 이 문제를 제거하는 것이 어떻게 가능한지 명확하지 않습니다.
• 계정 추상화가 작동하려면 부분적 보관이 필요합니다.: 보다계정 추상화로 가는 길 - HackMD

접미사 제안

다른 구성은 제안자가 블록에 대한 접미사를 만들 수 있도록 하는 것입니다. 빌더는 블록을 구축할 때 제안자의 의도에 대한 정보를 볼 수 없으며 제안자는 빌더가 놓친 트랜잭션을 끝에 추가할 수 있습니다.

• 인센티브 호환성 문제 감소 : 빌더는 빌더가 승인하지 않은 트랜잭션을 포함하는 제안자를 소급하여 처벌(예: 향후 빌드 거부)할 수 있으며 루트를 빌더에게 보냅니다. 이것은 피할 수 없지만 빌더가 실시간으로 블록 구성을 거부할 수 있는 것보다 훨씬 더 제안자 친화적입니다(특히 각 개별 제안자가 가끔 제안하기 때문에 오늘날 ~2개월에 한 번).
• 제안자에 대한 추가 부담 - 제안자는 이제 사후 상태 루트를 계산해야 합니다. 이는 제안자가 전체 상태를 보유해야 함을 의미합니다. 따라서 제안자가 이 작업을 아웃소싱하지 않는 한 무국적은 불가능합니다.분리된 중개인.
• 제안자는 일부 MEV 기회를 얻습니다. 빌더로부터 응답을 받는 것과 블록을 게시해야 하는 것 사이에 있습니다. 이것은 단지 0.5초의 가치일 가능성이 높지만 검증자가 사내에서 최적화할 수 있도록 지분 풀에 참여하는 인센티브가 여전히 약간 증가합니다.
• 빌더는 이전과 마찬가지로 여전히 일부 남용에 관여할 수 있습니다.
• 계정 추상화가 작동하려면 부분적 보관이 필요합니다. 이전과

제안자 접미사 수정: 사전 약속

제안자는 포함하려는 tx 세트의 머클 트리 또는 KZG 약속 또는 기타 누적기에 사전 커밋합니다. 빌더는 블록을 생성합니다. 그런 다음 제안자는 빌더가 아직 포함하지 않은 Merkle 트리의 하위 집합으로 정확히 구성되는 접미사를 추가해야 하며 가스 제한으로 인해 txhash 또는 다른 표준화된 순서로 정렬할 수 있습니다(다른 접미사, 슬래시).

슬래싱 적용에 대한 세부 사항은 다소 복잡합니다. 특히 제안자의 포함 트리를 명확하게 표시하지 않으려는 경우 더욱 그렇습니다. KZG 약속 및 특수 목적 ZK-SNARK를 사용하면 "약속 X로 집합에서 시작하고 Y에 있는 모든 것을 제거하면 나머지 집합은 Z라는 개념을 확인하기 위해 특수 다항식을 사용하여 합리적으로 쉽게 수행할 수 있습니다. ".

이렇게 하면 제안자의 MEV 기회가 제거됩니다. 빌더가 자신의 블록 콘텐츠로 회신하면 제안자는 게시할 블록에 대해 자유도가 0이지만 다른 문제는 해결되지 않은 상태로 남겨두기 때문입니다.

장기 최종 게임: 빌더를 어떻게 제한합니까?그리고 제안자의 책임을 최소화합니까?

제안자의 역할은 이상적으로 최소한으로 유지되어야 합니다. 포함될 가치가 있는 트랜잭션을 식별하기만 하면 됩니다. 제안자의 역할을 최소화하면 역할에 대한 접근성이 높게 유지됩니다. 빌더의 역할은 이상적으로 최소한으로 유지되어야 합니다. 빌더는 포함할 트랜잭션을 기반으로 블록을 구별할 수 없이 mempool에서 트랜잭션을 재정렬하고 MEV를 수집하기 위해 자신의 트랜잭션을 삽입할 수 있는 권한을 가져야 합니다.

그러나 이로 인해 다른 많은 중요한 작업, 특히 향후에 필요하게 될 작업이 할당되지 않은 상태로 남게 됩니다.

• 사후 상태 루트를 계산하는 작업
• 증인을 계산하고 게시하는 작업
• 블록의 정확성을 증명하는 ZK-SNARK를 만드는 작업

이러한 작업이 건축업자 또는 제안자에게 가지 않으면 일부제삼 배우. 이를 구현하는 몇 가지 가능한 방법이 있습니다.

• 우리는 제안자가 계약을 맺고 자신을 함수의 출력(ZK SNARK 생성, 상태 루트 계산 등)을 계산하는 일을 하는 전문 클라우드 컴퓨팅 공급자로 간주하는 별도의 빌더와 같은 중개자 클래스를 만듭니다. 블록 내용 선택에 관여하지 않음
• 우리는다음 블록은 이전 블록에 대한 이러한 값을 포함합니다. 이러한 값을 구성하고 필요한 경우 이를 확인하기 위해 중개자를 찾는 것은 다음 블록의 제안자에게 달려 있습니다.
• 우리는 별도의 중개자 클래스를 프로토콜에 안치하고 그들을 위한 프로토콜 내 인센티브를 추가합니다.
• 우리는 이러한 값을 게시하는 것을 네트워크의 이타적인 행위자에게 맡깁니다(따라서 값이 블록에 해시되지 않음). 증명자는 올바른 값이 제공된 경우에만 증명합니다.

어쨌든 빌더가 사용할 수 있는 권한과 정보를 동시에 최소화해야 할 필요성과 제안자에게 부과되는 부담은 블록 생산 파이프라인에서 일부 제3자의 필요성을 분명히 가리키는 것 같습니다. 빌더는 포함 목록을 볼 수 있는 권한이 있으므로 동일한 슬롯에 포함된 특정 트랜잭션을 차별합니다.) 우리는 이것이 정확히 어떻게 처리될 것인지에 대해 더 깊이 생각하기 시작해야 합니다.