미래 지향적 사전 확인

Ethereum Research

06-16

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

원문 표시

예정된 EIP가 사전 확인에 미치는 영향

작성자 : Aikaterini-Panagiota Stouka 및 Conor McMenamin , 둘 다 Nethermind.

이 글은 PBS 재단의 지원으로 완성되었습니다. Lin Oshitani 와 Davide Rezzoli 의 유익한 리뷰와 의견에 감사드립니다. 본 글의 내용은 저자의 견해입니다.

소개

사전 확인은 블록 제안자와 빌더가 완성된 블록을 최종 확정하기 전에 사용자에게 거래 포함/실행에 대한 확신을 제공하는 특정 유형의 약속입니다. 그러나 대부분의 사전 확인 프로토콜은 이더리움의 현재 설계를 염두에 두고 설계 및 분석되었습니다. 이더리움 개선 제안(EIP*) 덕분에 이더리움은 끊임없이 변화하고 업그레이드되고 있습니다. 이러한 EIP 중 일부는 설계상 또는 부수적으로 사전 확인 프로토콜의 호환성에 직접적인 영향을 미칩니다.

이 글에서는 사전 확인 관점에서 가장 큰 영향력을 가진 EIP들을 살펴보고, 이러한 EIP들이 사전 확인에 어떤 영향을 미칠지, 그리고 이러한 EIP들이 이더리움에 포함될 경우 호환성을 유지하기 위해 사전 확인 프로토콜에서 어떤 수정안을 채택할 수 있는지 살펴봅니다. 이러한 EIP들은 L1 블록 제안자 선정 방식을 수정하고, 제안자 예측 기능을 숨기고, 블록 제안 책임을 여러 주체에 분산하고, 블록 콘텐츠 및 검열 저항에 기여하는 새로운 주체를 도입하는 것을 목표로 합니다. 이 보고서는 작성 시점을 기준으로 가장 타당한 EIP 설계를 기반으로 이러한 EIP들이 사전 확인에 어떤 영향을 미칠 가능성이 있는지 분석합니다.

분석 요약

이미지 753×629 110KB

이미지 775×853 164KB

기사 개요

예비 섹션에서는 다음을 소개합니다.

사전 확인 유형은 다음을 기준으로 분류됩니다.
1. 거래가 어느 계층에 해당하는가(L1 또는 L2)
2. 사전 확인이 제공하는 보장의 특성(포함 또는 실행)
현재 설계의 주요 사전 확인 프로토콜 기능:
1. 사전 협의가 어긋날 경우 처벌.
2. 사전 협의에 대한 보상/팁입니다.

각 EIP 분석을 위한 프레임워크 섹션 에서는 기존 사전 확인 설계가 제안 및 EIP에 의해 영향을 받는지 여부와 그 영향을 받는 방식을 평가하는 데 사용되는 프레임워크를 소개합니다.

이후 각 섹션에서는 특정 EIP를 살펴봅니다. 분석 대상 EIP는 다음과 같습니다.

포함 목록. 구체적으로는 다음과 같습니다.
1. 포크 선택 강제 포함 목록 (FOCIL)
2. 이더리움(Ethereum)의 검열 저항성을 강화하기 위한 경매 기반 포함 목록 설계 (AUCIL)
다중 동시 제안자 (MCP)
단일 비밀 리더 선거 (SSLE),
APS( 증명자 제안자 분리 )
제정된 제안자-건설자 분리 (ePBS).

예비 사항

사전 확인 유형

거래가 발생하는 블록체인 계층과 사전 확인이 제공하는 보장의 특성에 따라 여러 유형의 사전 확인이 가능합니다.

블록체인 계층을 기반으로 한 사전 확인 유형은 다음과 같습니다.

L1 거래에 대한 사전 확인. 이를 L1 사전 확인 이라고 표기하겠습니다.
기반 L2에서 L2 거래에 대한 사전 확인. L2 거래 순서가 L1에 의해 결정되는 L2 블록체인 프로토콜. 이러한 분류에는 두 가지 중요한 차이점이 있습니다.
1. 모든 L1 제안자는 L2 제안자입니다. 본 논문에서 수행하는 분석에서는 이러한 사전 확인이 L1 사전 확인과 구별되지 않습니다. 이러한 이유와 표기의 용이성을 위해, 모든 L1 제안자가 L2 제안자인 L2 기반 사전 확인 분석을 L1 사전 확인 분석에 포함했습니다.
2. L1 제안자의 일부는 L2 제안자입니다. 이 설정에서 L2 제안자는 두 개 이상의 L1 슬롯에 대해 L2 블록을 제안할 독점적인 권한을 가질 수 있습니다. 이러한 사전 확인을 L2 기반 사전 확인 이라고 합니다. 이전 항목 2.a에서 언급했듯이, 모든 L1 제안자가 L2 제안자인 한 가지 예외는 제외되며, 이 글에서는 이러한 경우를 L1 사전 확인으로 분류합니다.
비기반 L2(예: Arbitrum , OP, Polygon 레이어 2 블록체인 프로토콜, 트랜잭션 순서가 롤업 제어 시퀀서 세트에 의해 처리되는 프로토콜)에서 L2 트랜잭션에 대한 사전 확인. 이러한 유형의 사전 확인에서는 트랜잭션 순서가 L1 제안자에 의존하지 않으므로, 여기서 논의하는 EIP가 이러한 유형의 사전 확인에 유의미한 영향을 미칠 것으로 예상하지 않습니다.

실행 보장의 성격에 따른 유형은 다음과 같습니다.

포함 사전 확인 : 이는 거래가 향후 블록에 포함될 것임을 보장합니다.
실행 사전 확인 : 이는 거래가 특정 슬롯의 특정 주문에 포함될 것을 보장합니다.

참고: 지정된 제안자(해당하는 경우 포함 목록 제안자/생성자 포함) 또는 독점적인 제안 권한을 위임받은 단체가 제공한 사전 확인만 분석합니다. 제안 권한을 통제하지 않는 단체의 사전 확인 분석은 생략합니다. 이는 L1 및 L2에서 제공될 것으로 예상되는 주요 사전 확인 유형에 대한 집중적인 분석을 보장하기 위한 것입니다. 준수해야 하는 차단/포함 목록을 제안하지 않는다는 보장이 없는 단체의 비제안자 사전 확인 및 확률적 사전 확인도 가능하지만, 이는 본 문서의 범위를 벗어납니다.

참고: 포함 사전 확인의 경우, 사전 협의자 역할을 하는 여러 지정 제안자가 동일한 거래에 대해 사전 확인을 제공할 수 있습니다. 팁의 호환성과 효과는 경쟁하는 포함 사전 확인이 어떻게 처리되는지에 따라 달라집니다. 일반적으로 포함 사전 협의자는 사전 확인을 제공할 때 이러한 위험을 감수해야 합니다. 동일한 슬롯에 대해 여러 사전 협의자가 있는 경우(포함 목록 및 여러 동시 제안자 EIP 등) 이러한 위험은 더욱 커집니다. 이러한 위험은 모든 사전 확인 요청 및 응답을 기록하는 중개자 또는 팁 지급을 위한 전용 사전 확인 플랫폼을 통해 완화할 수 있습니다.

이 기사의 나머지 부분에서는 사전 확인을 제공하는 기관을 사전 협의 기관이라고 칭하겠습니다.

현재 이더리움 디자인의 사전 확인의 특징

다양한 EIP가 사전 확인 설계에 어떤 영향을 미칠 수 있는지 살펴보기 위해, 본 분석에서는 두 가지 중요한 사전 확인 프로토콜 메커니즘이 각 EIP에 의해 어떻게 영향을 받을 가능성이 있는지 살펴봅니다. 바로 처벌 메커니즘과 보상 메커니즘입니다. 이전 PBSF 연구비 논문에서 강조했듯이 , 사전 확인은 제안자가 사전 확인을 제공하고 최종적으로 확인하도록 하는 인센티브에 크게 의존합니다. 각 EIP가 기존 사전 확인 처벌 및 보상 메커니즘에 미치는 영향을 보여줌으로써, 사전 확인의 비호환성, 또는 대부분의 경우 처벌 및 보상 메커니즘을 제대로 활성화하는 데 필요한 사전 확인 프로토콜 및/또는 기반 블록체인 기능의 변경 사항을 파악할 수 있습니다.

처벌

모든 사전 확인 설계는 사전 협의 참여자들이 사전 확인 발급을 거부하거나 지연하는 것을 방지하기 위해 어떤 형태의 처벌 및/또는 강제 메커니즘에 의존합니다. 본 분석에서는 여기에 소개된 프레임워크 를 바탕으로 처벌을 집행하는 주체를 기준으로 이러한 처벌을 분류합니다.

스마트 계약: 모든 사전 확인 설계에서 스마트 계약은 객관적인 오동작을 포함하는 조건을 시행하는 데 사용될 수 있습니다. 몇 가지 예로는 사전 확인된 거래 순서를 방해하는 안전 위반과 사전 확인된 거래를 제외하는 활성 위반(liveness violation)이 있습니다( 사전 확인 레지스트리 의 슬래싱 조건 참조).
감독자( 여기서 제안됨 ): 사전 협의 대상자에게 특정 행동이나 처벌을 강제할 수 있는 특별한 권한을 가진 기관. 감독자는 원래 사전 확인 요청과 응답의 공정한 교환 을 위해 도입되었지만, 더 일반적으로는 객관적 및 주관적 사전 확인 요건을 모두 강제하는 데 사용될 수 있습니다. 감독자가 내리는 처벌에는 다음이 포함될 수 있습니다.
1. 슬래싱. 감독자는 사전 담보에 대해 임의로 슬래싱 조건을 부과할 수 있습니다.
2. 블랙리스트. 감독관은 모든 비정상 사전 협의자 목록을 관리하고 특정 기간 동안 사전 협의자로서의 활동을 금지할 수 있습니다.
3. 주문 흐름 손실. 감독자는 다음 방법 중 하나를 통해 비정상적인 사전 협의에 대한 주문 흐름(사전 확인 요청)을 줄이거나 중단할 수 있습니다.
  1. 사전 확인서는 사전 협의자와 감독자 모두가 서명해야 하며, 이를 통해 감독자는 예외적인 사전 협의자에 대한 사전 확인서 서명을 중단할 수 있습니다.
  2. 신호. 감독자는 사전 협의가 비정상적임을 알리는 신호를 보내 사용자에게 해당 사전 협의에 대한 사전 확인 요청 전송을 중단하도록 할 수 있습니다.
사용자: 사용자는 현재 슬롯 또는 향후 슬롯에 대해 비정상적인 사전 협의 요청 전송을 중단할 수 있습니다. 이는 주문 흐름 손실이라고 하며, 단기적 또는 장기적 손실이 발생할 수 있습니다.

보상/팁

사전 컨퍼런스 참여자는 사전 확인 후 보상을 받을 것으로 예상됩니다. 팁은 일반 거래 수수료를 통해 사전 컨퍼런스 참여자에게 지급되거나, 감독자 또는 전용 스마트 계약을 통해 관리 및 분배될 수 있습니다. 본 분석은 각 EIP에 따라 팁 지급 방식 및/또는 총 팁 금액이 어떻게 변경될 것으로 예상되는지에 중점을 두고 있습니다.

각 EIP 분석을 위한 프레임워크

서론에서 논의된 각 EIP를 다음 프레임워크를 사용하여 살펴보겠습니다.

우리는 사전 확인과 가장 관련성이 높은 측면에 초점을 맞춰 EIP에 대한 개요를 제공합니다.
각 사전 확인 유형 또는 유형 그룹(하위 섹션당 그룹 하나)에 대해 다음 사항을 논의합니다.
1. 호환성: 호환성 문제가 발생하면 일치성을 보장하기 위해 잠재적인 수정 사항을 모색합니다.
2. EIP로 인해 처벌과 팁의 효과가 변화합니다.

APS의 경우, 여러 후보 설계가 존재하고 각 설계가 서로 다른 사전 확인 유형의 호환성에 각기 다른 방식으로 영향을 미치기 때문에 다른 프레임워크를 채택합니다. 이에 대해서는 APS를 다루는 섹션 4에서 더 자세히 설명합니다.

섹션 1. 포함 목록

우리가 살펴보는 첫 번째 EIP는 여러 제안자 유사 개체가 포함 목록을 생성하여 블록 생성에 입력을 제공할 수 있도록 하는 프로토콜입니다. 이때 지정된 제안자 중 한 명이 거래 순서를 결정합니다. 이러한 프로토콜은 이더리움의 검열 저항성을 강화하는 것을 목표로 합니다. 대표적인 예로는 포크 선택 강제 포함 목록 (FOCIL)(EIP 관련 내용은 여기 참조)과 이더리움 검열 저항성 강화를 위한 경매 기반 포함 목록 설계 (AUCIL)(사전 인쇄본 관련 내용은 여기 참조)가 있습니다.

1.1. FOCIL 및 AUCIL 개요

두 프로토콜 모두 포함자라고 불리는 무작위로 선택된 개체로 구성된 위원회를 활용하여 거래의 포함 목록을 만듭니다.

포실

블록 제안자는 블록을 생성하고, 공간이 있으면 포함 목록에 있는 모든 유효한 거래를 포함해야 합니다. 그렇지 않으면 증명자가 블록을 거부할 수 있습니다. 현재 설계 에서는 사용자가 포함자에게 수수료를 지불하지 않습니다. 이 핵심 설계를 포함자 수수료가 없는 조건부 포함 목록 이라고 합니다. 이 핵심 프로토콜의 주요 변형은 다음과 같습니다.

무조건 포함 목록 : 블록 제안자는 혼잡(즉, 메모리 풀에 모든 트랜잭션을 수용할 공간이 부족함)이 발생하더라도 모든 포함자의 포함 목록에 있는 모든 유효 트랜잭션을 포함해야 합니다. 트랜잭션 순서는 블록 제안자가 결정합니다.
포함 수수료 : 사용자는 자신의 거래가 블록과 포함 목록에 모두 포함되는 경우 위원회에 추가 수수료를 지불합니다( 여기 참조).

오실

AUCIL은 무조건 포함 목록을 통해 이더리움의 검열 저항성을 강화하는 것을 목표로 하는 또 다른 프로토콜입니다( 여기 3, 15페이지 참조). AUCIL의 주요 추가 사항은 (i) 포함자가 특정 방식으로 IL을 생성하도록 하는 인센티브를 제공하는 상관 평형 접근 방식, (ii) 경매 기반 IL 집계 방식입니다. 집계자는 IL을 집계하고 입찰을 제출하며 블록 제안자는 가장 큰 집계 목록을 선택합니다. 블록 제안자가 집계 목록에 포함된 포함 목록의 수에 대한 특정 요구 사항( 여기에 자세히 설명됨 )을 충족하지 못하면 제안자의 블록은 증명자에 의해 거부됩니다. 이러한 추가 사항은 (i) 순서와 제안자가 자신의 거래를 추가할 수 있는지 여부와 무관하며, (ii) 모든 IL이 하나의 집계자에게 제공되어야 한다는 보장이 필요하지 않으므로 더 많은 IL을 허용할 수 있습니다. 이 글의 목적상, 우리는 블록 제안자가 주문을 수행하고 블록 제안자가 더 많은 거래를 추가할 수 있다고 생각합니다(이는 무조건 FOCIL과 동일함).

1.2. 사전 확인 분석

다음 분석을 기존 사전 확인 설계와의 호환성 측면에서 유사한 특성을 공유하고, 관련 처벌 및 팁의 효과성 측면에서도 유사한 사전 확인 유형 그룹으로 구성했습니다. 그룹화는 다음과 같습니다.

포함 사전 확인.
L1 실행 사전 확인.
L2 실행 사전 확인 기반.

1.2.a. 포함 사전 확인

포함 목록에는 사전 확인을 제공할 수 있는 두 가지 행위자가 있습니다. 블록 제안자와 포함자입니다. 따라서 각 행위자의 호환성에 대해서는 별도로 논의하겠습니다.

호환성: 블록 제안자 사전 확인

FOCIL의 조건부 포함 목록:

블록 제안자는 여전히 모든 사전 확인을 블록에 포함할 수 있습니다(공간이 있을 때만 포함 목록을 준수해야 하기 때문).
블록 제안자 선출 절차는 변경되지 않습니다. 따라서 기존 사전 확인 설계와의 호환성 문제는 발생하지 않을 것으로 예상됩니다.

FOCIL 및 AUCIL과 같은 무조건 포함 목록의 경우, 결합된 포함 목록이 전체 블록 공간보다 적은 공간을 차지하는 것으로 알려진 경우, 호환성 문제는 발생하지 않을 것으로 예상됩니다. 이 경우에도 블록 제안자는 나머지 블록 공간에 대한 사전 확인을 발행할 수 있습니다.

제안자는 자신의 블록의 사용 가능한 공간을 초과하는 사전 확인을 발행할 수 있으며, 이는 이전 L1 제안자가 사전 협의자를 대신하여 사용 가능한 블록 공간을 활용하여 이러한 사전 확인을 포함할 것이라는 예상에 따른 것입니다. 포함 목록은 검열 저항성을 강화할 것으로 예상되므로, 사전 협의자 블록의 공간을 초과하는 사전 확인을 제공하는 것이 더 실행 가능하고 위험성이 줄어듭니다.

호환성: 포함자 사전 확인

FOCIL의 무조건 포함 목록을 사용하면 포함자는 포함 사전 확인을 발행할 수도 있습니다. FOCIL이 의도한 대로 작동한다고 가정할 때(예: 증명자의 2/3 또는 2/3 가 정직하고 블록 제안자가 유효한 블록을 생성하려고 하는 경우), 포함자의 사전 확인은 블록 제안자의 사전 확인과 동일한 이점을 갖습니다.

AUCIL을 사용하면 포함자가 발행하는 사전 확인이 더 위험합니다. 앞서 언급했듯이 AUCIL은 모든 애그리게이터가 포함 목록을 사용할 수 없는 경우를 고려하기 때문입니다. FOCIL과 동일한 사전 확인 보장을 제공하려면 AUCIL 설계에서 블록 제안자가 IL을 하나도 누락하더라도 페널티를 받도록 해야 합니다.

무조건 포함 목록 포함자가 사전 확인을 제공할 수 있는 이러한 기능에는 주목할 만한 단점이 있습니다. 사전 확인은 검열에 취약한 거래를 위해 주로 사용되는 포함 목록의 공간을 차지합니다. 이러한 단점은 "크라우딩(crowding)"이라고 불리며, 여기 와 여기 에서 논의되었습니다.

조건부 FOCIL의 경우, 블록 제안자가 블록이 가득 찼을 때 IL을 생략하더라도 증명자가 해당 블록을 거부하지 않으므로, 포함자가 사전 확인을 발행할 것으로 예상하지 않습니다. 또한, 다음 슬롯에서는 새로운 포함자가 선출되며, 다음 슬롯의 블록 제안자는 이전 블록에 대해 발행된 IL의 트랜잭션을 포함할 의무가 없습니다. ( 슬롯 N+1에서 준수해야 하는 유일한 IL은 슬롯 N의 두 번째 0과 9 사이에 전파된 IL입니다 .)

처벌과 팁의 효과

조건부 포함 목록은 처벌 메커니즘의 효과성에 영향을 미쳐서는 안 됩니다. 사전 협의체는 동일한 주체로 유지되고 동일한 방식과 빈도로 선출되기 때문입니다.

무조건적인 FOCIL과 AUCIL의 경우, 블록 제안자의 관점에서 볼 때, 우리는 미래의 사전 확인 팁과 관련된 처벌 메커니즘, 즉 블랙리스트와 주문 흐름 손실의 처벌만이 이루어질 것으로 예상합니다.

무조건 포함 목록은 블록 공간의 일부를 차지해야 하므로, 블록 제안자는 사전 확인을 위한 여유 공간이 줄어듭니다. 이는 사전 확인 팁에 영향을 미치고, 나아가 블랙리스트 및 장기적인 주문 흐름 페널티의 효과에도 영향을 미칩니다. 현재로서는 무조건 포함 목록이 팁에 미치는 정확한 영향을 예측하기는 어렵지만, 적어도 두 가지 주요 반작용 요인이 존재합니다.

무조건적인 포함 목록은 사전 확인 용량을 줄이고, 따라서 팁을 수집할 수 있는 사전 확인의 수도 줄어듭니다.
블록 공간의 공급이 감소하고, 이로 인해 사용 가능한 공간에 대한 수요가 증가함에 따라 사전 확인당 평균 팁은 증가할 것입니다.

포함자가 사전 협의자 역할을 하는 경우, 블랙리스트의 효과와 주문 흐름 손실은 포함 목록 사전 확인 시장의 가치와 직접적인 관련이 있습니다. 제안자 사전 확인과 마찬가지로, 선정 빈도, 포함 목록의 규모, 그리고 슬롯 사전 확인 제공 가능 시점은 모두 포함자의 사전 확인 수익에 영향을 미칩니다. 그러나 이러한 가치의 주요 동인은 사용자 수요에서 비롯됩니다. 고부가가치 사전 확인 시장이 부재한 상황에서, 슬래싱은 여전히 실행 가능한 처벌 메커니즘으로 남을 것입니다.

사전 확인 유형 섹션에서 언급했듯이, 동일한 슬롯에 대한 포함 사전 협의자로 활동하는 여러 포함자가 있으면 포함 사전 확인 충돌 위험이 높아지며, 이는 사전 협의자에게 결제 및 팁 위험을 초래할 수 있습니다.

1.2.b. L1 실행 사전 확인

호환성

이 경우, 사전 확인은 슬롯 N N 동안 슬롯 N N 의 제안자에 의해서만 발행될 수 있습니다.또한, 조건부 및 무조건부 포함 목록에서 블록 제안자는 블록의 순서에 대한 제어권을 유지합니다.이를 통해 슬롯 N-1 N − 1 에 대한 블록이 게시되면 슬롯 N N 의 블록 제안자는 실행 사전 확인을 발행할 때 준수해야 하는 관련 L1 또는 L2 상태를 완전히 인식하게 됩니다.따라서 무조건부 포함 목록에서 블록 제안자는 포함 목록에 대해 차지되지 않은 블록 공간에 대해서만 사전 확인을 발행해야 한다는 사실을 제외하고는 이러한 유형의 사전 확인과 관련하여 호환성 문제가 없을 것으로 예상합니다.

실행 사전 확인의 경우, 포함자는 L1 또는 L2 블록의 거래 순서를 제어하지 않으므로 사전 협의자 역할을 할 수 없습니다.

처벌과 팁의 효과

블록 제안자의 관점에서 볼 때, 이러한 사전 확인에 대한 처벌과 팁의 효과는 포함 사전 확인의 효과와 비슷합니다.

포함자는 실행 사전 설정을 제공할 수 없으므로 해당 분석은 이 섹션과 관련이 없습니다.

1.2.c. 기반 L2 실행 사전 확인

호환성

호환성 문제는 없습니다. 기반 L2 실행 사전 협의자는 사전 확인 슬롯이 시작되는 즉시 사전 확인을 제공할 수 있습니다. 무조건적이든 조건적이든, 포함자는 포함자라는 이유만으로 기반 L2 실행 사전 확인을 제공할 수 없습니다. 포함자가 L2 제안자로 등록된 경우, 포함자는 활성 실행 사전 협의자이기도 한 경우, 즉 해당 포함자의 사전 확인 슬롯인 경우에만 기반 L2 실행 사전 확인을 제공할 수 있습니다. 그렇지 않고 다른 사람의 사전 확인 슬롯인 경우, 해당 포함자는 L2 블록을 제안할 독점적인 권한을 가지므로 포함자가 제안한 모든 L2 블록은 무효화됩니다.

처벌과 팁의 효과

무조건 포함 목록에서는 사전 협의자가 사용 가능한 블록 공간이 줄어듭니다. 이러한 감소가 슬롯당 사전 확인으로 인한 예상 보상에 영향을 미치면, 1.2.a절에서 설명한 바와 같이 블랙리스트 및 장기 주문 흐름에도 영향을 미칩니다.

이 외에는 사전 협의자는 포함 목록이 있든 없든 동일한 방식과 빈도로 선출되므로 처벌과 팁의 효과에 큰 변화가 없을 것으로 예상합니다.

섹션 2. 다중 동시 제안자(MCP)

2.1. MCP 개요

MCP 에서는 두 개 이상의 엔티티가 현재 슬롯에 대한 부분 블록 페이로드를 제안합니다(이 부분 페이로드를 하위 블록이라고 합니다). 최종 블록의 페이로드는 이러한 모든 하위 블록의 트랜잭션을 합집합으로 구성되며, 결정론적 순서 규칙에 따라 정렬됩니다. 이 규칙은 논란의 여지가 있지만, 우선 수수료 순서는 고려되어 왔습니다 . BRAID 는 MCP 프로토콜의 한 예입니다.

2.2. 사전 확인 분석

이 섹션의 사전 확인 분석을 다음과 같이 구분했습니다.

포함 사전 확인.
실행 사전 확인.

2.2.a. 포함 사전 확인

호환성

하위 블록의 합집합이 최종 블록보다 크지 않다고 가정하면, 제안자는 모든 하위 블록의 모든 거래를 최종 블록에 포함하므로 포함 사전 협의자 역할을 할 수 있습니다( 여기 , 여기 , 여기 에서도 논의).

처벌과 팁의 효과

1절에서 언급했듯이, 블랙리스트 및 장기적인 오더플로우 손실의 효과는 에포크당 사전 확인에서 예상되는 팁 수에 따라 달라집니다. 팁 수가 많을수록 이러한 페널티의 효과가 커집니다. MCP에서는 단일 제안자 프로토콜보다 제안자가 더 자주 선출되어야 하지만, 네트워크 대역폭 사용량을 유지하기 위해 하위 블록의 크기는 제안자 수의 반비례해야 합니다. 즉, 사전 확인을 위한 총 가용 공간은 MCP와 단일 제안자 설정에서 동일하게 유지되어야 합니다. 이 경우, MCP에서 포함 사전 설정 팁의 변화는 없을 것으로 예상됩니다.

사전 확인 유형 섹션에서 언급했듯이, 동일한 슬롯에 대해 여러 MCP 제안자가 포함 사전 협의자로 활동할 경우, 포함 사전 확인이 충돌할 위험이 높아지고, 이는 사전 협의자에게 팁(tip) 위험을 초래할 수 있습니다. 이는 다음 사항에 따라 달라집니다.

특정 MCP 구현이 중복 거래를 처리하는 방법.
동일한 거래에 대해 두 명 이상의 사전 협의자가 사전 확인을 제공하는 경우 사전 협의자에게 팁이 지급되는 방식:
- 예를 들어 거래의 최종 사본이 포함된 블록을 만든 제안자에게 팁을 한 번만 지급합니다.
- 사전 컨퍼런스에 참석한 모든 사람은 사전 컨퍼런스에 대한 팁을 받습니다.

2.2.b. 실행 사전 확인

호환성

이는 순서 규칙에 따라 다르지만, 일반적으로 병합된 블록의 최종 순서를 모르는 MCP 제안자는 L1 실행 사전 확인을 제공할 수 없습니다. 하위 블록에 미리 순서 우선순위가 부여되는 MCP 구현에서는 첫 번째 하위 블록의 제안자가 실행 사전 확인을 제공할 수 있습니다. 하지만 이러한 MCP 구현은 블록 제안자가 블록의 최상위 블록을 생성하고 정렬하는 우선순위를 갖는 무조건적 FOCIL과 매우 유사하지만, 현재로서는 제대로 고려되지 않았습니다.

L2 실행 사전 설정의 경우, 단일 MCP 제안자가 L2 블록을 제안할 독점적인 권한을 가지고 있는 경우 L2 실행 사전 확인이 가능합니다. 반대로, 두 명 이상의 MCP 제안자가 L2 블록을 제안할 수 있는 경우, 실행 사전 확인은 호환되지 않습니다.

섹션 3. 단일 비밀 지도자 선거

3.1. SSLE 개요

기존 단일 비밀 리더 선출 (Single Secret Leader Election, SSLE) 구조에서 공통적인 점은 다음 에포크의 검증자 일정이 숨겨져 있다는 것입니다. 선출된 검증자만이 리더(=제안자)로 지정된 특정 슬롯을 알고 있으며, 슬롯당 하나의 리더만 존재합니다. 이는 서비스 거부(DoS) 방어를 강화하기 위해 설계되었습니다. SSLE 프로토콜에 대한 구체적인 설명은 아래에 제시된 Whisk 에서 확인할 수 있습니다.

여기서 소개된 프로토콜의 수정된 버전인 Whisk 는 다음과 같이 작동합니다. 처음에는 부트스트래핑 기간 동안 각 검증자가 장기 무작위 비밀을 커밋합니다. 그런 다음, RANDAO를 통해 선정된 검증자 중 무작위로 선택된 하위 집합이 새로운 무작위성을 사용하여 장기 비밀을 커밋합니다. 이러한 커밋은 이후 현재 기간의 리더에 의해 섞이고 다시 무작위화됩니다. 섞인 검증자 풀에서 RANDAO를 통해 슬롯당 하나씩 무작위로 선택된 하위 집합이 다음 기간의 슬롯 리더 역할을 합니다. 할당 방식은 슬롯에 할당된 검증자(슬롯에 해당하는 비밀을 알고 있는 검증자)만 슬롯 할당을 알도록 하는 것입니다. 특정 슬롯에 대한 리더십을 증명하려면 검증자는 (장기 비밀을 공개하지 않고) 해당 커밋의 소유권을 입증해야 합니다. 검증자는 영지식 증명을 사용하여 커밋에 포함된 비밀을 알고 있으며, 이 비밀이 자신의 신원과 암호적으로 연결된 장기 비밀과 일치함을 증명합니다.

3.2. 사전 확인 분석

우리는 섹션 3의 분석을 다음과 같이 나누었습니다.

포함 및 L1 실행 사전 확인.
L2 실행 사전 확인 기반.

3.2.a. 포함 및 L1 실행 사전 확인

호환성

SSLE 설계에서 사전 협의자가 사전에 신원을 공개할 의향이 있다면, 기존 사전 확인 설계와의 호환성 문제는 발생하지 않을 것으로 예상됩니다. 물론, 이는 선거의 비밀 유지를 침해하는 요소입니다.

반면, 사전 협의자가 블록 제안 전에 익명성을 유지하기를 원한다면, 사전 확인 메커니즘의 구성은 신중하게 조정되어야 합니다. 아래에서 호환 가능한 수정된 사전 확인 프로토콜에 대한 간략한 개요를 제공합니다.

검증자가 익명을 유지하면서 슬롯 N N 에 대한 적격 사전 협의자임을 증명하려면 검증자는 다음 두 가지 진술이 사실임을 증명해야 합니다.

검증자는 슬롯 N N 의 리더입니다.
이 명제를 증명하기 위해 영지식 증명을 사용하는 것에 대해서는 여기 와 여기 에서도 논의되었습니다. Whisk 의 경우, 검증자는 슬롯 N N 과 관련된 커밋에 숨겨진 장기 비밀을 알고 있음을 증명해야 합니다.
처벌에 슬래싱이 포함되는 경우 검증자는 현재 슬래싱에 대해 등록되어 있음을 증명해야 합니다(예: 등록 계약) .
이를 달성하는 한 가지 방법은 레지스트리 스마트 계약이 모든 등록된 검증자의 공개 키를 포함하는 추가 전용 머클 트리를 유지하는 것입니다. 이는 현재 범용 레지스트리 계약 에 존재하는 것과 같습니다. 그러면 사전 협의자는 이 머클 트리에 포함된 공개 키에 해당하는 개인 키를 소유하고 있음을 증명할 수 있습니다( Zcash 에서 사용되는 기술과 유사).
처벌에 블랙리스트에 포함되는 경우 검증자는 자신이 블랙리스트에 있는 집합에 속하지 않는다는 것을 증명해야 합니다.
이를 구현하는 한 가지 방법은 감독자(또는 스마트 계약)가 블랙리스트에 있는 사전 협의자와 블랙리스트에 없는 사전 협의자 집합을 유지 관리하고, 사전 협의자가 블랙리스트에 없는 집합의 구성원임을 증명하는 것입니다. 예를 들어, 희소 머클 트리 포함 증명을 사용합니다.

팁의 호환성과 관련하여, 팁이 사전 협의자에게 즉시 제공될 경우, 사전 협의자는 자신의 슬롯 전에 주소를 공개해야 하며, 이로 인해 신원이 노출될 가능성이 있습니다. 대신, 팁은 스마트 컨트랙트에 지불되고 슬롯 N N 이후에 사전 협의자에게 지급될 수 있으며, 슬래싱 조건이 충족되지 않는 한 그렇게 될 수 있습니다. 슬롯 N N 이 지나면 검증자의 신원이 공개됩니다. 따라서 그 시점부터 팁과 처벌이 적용될 수 있습니다.

사용자가 부과하는 평판 관련 처벌은 사전 회의 참여자의 신원을 익명으로 유지하면서도 쉽게 적용할 수 없습니다. 익명 평판 도구를 사용하여 사전 회의 참여자가 사용자에게 평판을 전달할 수 있도록 하는 방안이 있을 수 있습니다. 그러나 평판은 블랙리스트 및 기타 감독 관련 프로토콜을 대체하기 위한 것이므로, 각 사전 회의 참여자의 평판을 사용자별로 관리해야 하며, 이는 매우 복잡하고 목적에 부합하지 않을 가능성이 높습니다.

처벌과 팁의 효과

이전 섹션에서 언급했듯이, 사전 협의된 신원 공개 없이 SSLE를 적용하면 평판 기반 처벌이 매우 복잡해지고 효과적이지 않을 가능성이 높습니다. 다른 처벌 메커니즘은 여전히 효과적이어야 하지만, 이전 섹션에서 논의된 구현 방식에 따라 신중하게 구현해야 합니다.

SSLE 사전 확인 절차에 따른 사전 확인 요구는 이론적으로는 크게 변동이 없을 것입니다. 그러나 SSLE 사전 확인 절차가 초래하는 추가적인 복잡성을 고려할 때, 제안자들은 사전 확인자가 되기 위해 더 높은 사전 확인 팁을 요구할 것으로 예상됩니다.

마지막으로, 선거 빈도가 변경되어 에포크당 사전 확인에서 예상되는 보상이 달라지면 이전 섹션에서 설명한 대로 블랙리스트나 주문 흐름 손실의 효과도 영향을 받습니다.

3.2.b. 기반 L2 실행 사전 확인

호환성

이러한 유형의 사전 확인은 사전 협의자가 사전 확인 슬롯이 시작될 때 발행할 수 있으며, 이 슬롯은 하나 이상의 L1 슬롯을 포함할 수 있습니다. 제안 슬롯보다 일찍 실행 사전 확인을 제공하려면 사전 협의자가 사전 협의 룩어헤드(또는 신원이 없는 사전 협의 일정)를 알아야 합니다. 사전 협의 룩어헤드 공개를 가능하게 하려면 모든 사전 협의자가 자신의 슬롯을 공개하도록 강제/인센티브를 제공하는 메커니즘이 필요합니다. 이는 3.2.a절에서 설명한 방식(신원을 공개하거나 영지식 증명을 사용하여 특정 슬롯에 참여할 자격이 있는 사전 협의자임을 증명하는 방식)과 유사합니다.

가능한 해결책 - 감독자 활용: L2 시스템에서 감독자는 사전 협의 공개에 대한 마감일을 설정할 수 있습니다. 이를 통해 모든 사전 협의자는 정해진 마감일, 예를 들어 SSLE 프로토콜에 의해 검증자 일정이 결정된 후 몇 초 후에 자신의 역할을 공개해야 합니다. 마감일 이후에는 사전 협의자가 있는 슬롯이 고정되어 결정론적인 사전 협의 일정을 가능하게 합니다. 그러나 이 방식은 감독자가 정해진 시간 내에 역할을 공개하는 사전 협의자를 거부할 수 있는 잠재적인 활성도 문제를 야기합니다.

이를 완화하고 감독자에 대한 활성도 종속성을 제거하기 위해, 감독자는 슬래싱만 수행하도록 제한하여 특정 마감일까지 역할을 공개하지 않은 사전 협의자를 모두 슬래싱할 수 있습니다. 이 대안은 자체적인 단점을 가지고 있습니다. 바로 룩어헤드가 더 이상 결정적이지 않다는 것입니다. 룩어헤드가 결정적이지 않으면, 두 개 이상의 슬롯으로 구성된 사전 확인 윈도우에 대한 실행 사전 확인이, 사전 확인 윈도우의 더 이른 슬롯에서 유효한 사전 협의자로서 역할을 공개하는 제안자에 의해 무효화될 위험이 있습니다. 따라서, 감독자 기반 룩어헤드 솔루션이 L2 기반 실행 사전 확인에 더 적합한 솔루션이라고 생각합니다.

처벌과 팁의 효과

팁과 처벌의 효과는 논의된 것과 동일할 것으로 예상됩니다. 이전 하위 섹션에서 SSLE에 대해 설명했습니다.

섹션 4. 증명자 제안자 분리(APS)

4.1. APS 개요

APS 에서 실행 제안자의 역할은 증명과 같은 다른 검증자의 업무와 분리됩니다. 이러한 분리를 통해 더욱 정교한 실행 제안자가 이더리움에 참여할 수 있게 되면서, 제안자에서 증명자로 의 인센티브 유출을 완화할 수 있습니다. 증명자는 고도로 탈중앙화된 검증자 집합의 일부로 유지되어야 합니다. 주요 APS 설계 중 두 가지는 실행 경매 (EA)와 실행 티켓 (ET)입니다.

두 설계 모두 실행 제안자(execution proposal)의 역할은 정교한 경쟁 주체에게 할당됩니다. EA에서는 제안자가 경매를 통해 결정론적으로 선정되는 반면, ET에서는 이전에 티켓을 구매한 추첨을 통해 무작위로 선정됩니다( 여기, 여기 , 여기 , 여기 참조).

4.2. 사전 확인 분석

우리는 위에서 설명한 APS의 두 가지 주요 설계 측면을 중심으로 다음 분석을 구성했습니다.

APS 경매가 언제 진행되는지 , 즉 슬롯 N N 에 대한 실행 제안자가 얼마나 미리 선출되는지에 대한 내용입니다. 제안 사항은 다음과 같습니다.
- 앞으로 많은 슬롯이 있습니다(예: 32개 슬롯).
- 슬롯 N-1 N − 1 에 대한 블록이 제안된 후 Dt D t 초가 경과한 시점( 여기에 제시된 제안; 이 제안은 무작위성을 가진 2슬롯 앞선 실행 티켓으로 표시됨). 이 설계에서 슬롯 N N 의 실행 제안자는 슬롯 N-1 N − 1 에 대한 블록이 제안된 후 Dt D t 초 후에 추출된 무작위성을 통해 결정됩니다.
- 슬롯 동안 JIT(Just-In-Time) 경매를 통해.
제안 권리의 의정서 내 재판매가 허용되는지 여부, 즉 선출된 제안자가 제안 권리를 재판매할 수 있는지 여부입니다 .

이 설계 측면의 각 APS 유형에 대해, 어떤 유형의 사전 확인이 호환되고 호환되지 않는지 간략하게 설명합니다. 마지막으로, 마지막 하위 섹션에서는 APS가 처벌과 팁의 효과에 미치는 예상 영향을 논의합니다.

4.2.a. 호환성: APS 경매가 실행될 때

호환성 측면에서 사전 협의자는 각 APS 경매 또는 복권의 당첨자가 됩니다. 이는 현재 이더리움 환경에서 검증자를 대신하여 사전 확인을 제공할 수 있는 중앙화된 게이트웨이가 이러한 중개자를 제거하고 스스로 제안자가 되어 비용을 최소화하고 수익을 극대화할 수 있는 길을 열어줍니다. 결과적으로, APS에서는 L1 실행 제안자와 사전 확인자가 더욱 정교해질 것으로 예상되며, 선택 빈도는 예치 지분과 분리될 것입니다.

여기에서 논의된 바와 같이, RANDAO가 무작위성의 유일한 원천인 APS 설계에서는 다중 슬롯 MEV 방지 라는 속성과 사전 확인과의 호환성 간에 상충 관계가 존재합니다. 다중 슬롯 MEV는 여러 연속 슬롯의 제안자가 되는 것이 각 슬롯에서 개별적으로 사용 가능한 MEV의 합보다 더 많은 MEV를 생성하는 현상을 나타냅니다( 여기 참조). 여기에서 제시된 구조는 특정 유형의 사전 확인을 계속 지원하면서 다중 슬롯 MEV를 방지함으로써 이러한 상충 관계를 해결합니다. 그러나 슬롯 N N 에 대한 실행 제안자는 이전 슬롯의 블록이 제안된 후 Dt Dt 초 후에 추출된 무작위성을 사용하여 선택된다고 가정합니다. 아래에서 이러한 생각을 자세히 설명합니다.

실행 제안자가 여러 슬롯에 걸쳐 미리 선택되는 설계에서는 모든 유형의 사전 확인이 발생할 것으로 예상됩니다. 이러한 설계의 단점은 다중 슬롯 MEV에 취약하다는 것입니다.
슬롯 N N 에 대한 실행 제안자가 슬롯 N-1 N − 1 에 대한 블록 제안 후 Dt D t 초 후에 선출되는 설계( 여기에 제시됨)는 다중 슬롯 MEV를 방지하고 슬롯 자체에서 발행되는 포함 및 실행 사전 확인만 지원합니다. Dt D t 가 작을수록 사전 확인에 더 많은 시간이 소요되고 더 가치 있는 사전 확인이 가능합니다. 이러한 설계의 단점은 슬롯 N N 에 대한 블록 제안 후 추출된 무작위성을 가정한다는 것입니다.
실행 제안자 선출이 슬롯 중에 이루어지는 설계(예: 적시 경매)는 슬롯 N N 의 실행 제안자가 슬롯 N+1 N + 1 의 실행 제안자를 알기 전에 페이로드를 제안하기 때문에 다중 슬롯 MEV를 방지합니다. 그러나 이러한 적시 선거 설계가 제안자 사전 확인을 지원할 것으로 기대하지는 않습니다.

4.2.b. 호환성: 제안 권한의 프로토콜 내 재판매

실행 제안자가 사전에 여러 슬롯을 선택했지만 프로토콜 내에서 권리를 재판매할 수 있는 디자인은 다음 중 하나가 충족되는 한 사전 확인을 계속 지원할 수 있습니다.

최초 실행 제안자가 제안권을 매수한 제안자에게 제공된 사전 확인을 강제할 수 있도록 하는 강제 메커니즘이 마련되어 있습니다. 정확한 강제 메커니즘은 다음과 같습니다.
- 특정 거래 목록의 L1 블록 상단 순서 강제 지정: 모든 유형의 사전 확인은 원래 제안자에 의해 제공되고 강제될 수 있습니다.
- L1 포함만 가능: 원래 제안자가 제안할 수 있습니다.
  - 포함 사전 확인.
  - 모든 L2 사전 확인 거래가 (1) 원래 제안자의 서명을 필요로 하고 (2) 단일 L1 거래에 포함될 수 있는 기반 L2 실행 사전 확인.
    그러나 원래 제안자가 순서를 강제할 수 없기 때문에 L1 실행 사전 확인은 지원되지 않습니다.
제안자는 제안할 권리를 보유하기로 약속합니다. 이는 최초 제안자일 수도 있고, 제안할 권리를 구매한 제안자일 수도 있습니다. 합리적인 제안자가 제안 권리를 재판매하는 대신 사전 확인 제안을 통해 수익을 극대화할 수 있다고 믿는 경우, 이는 발생합니다. 합리적인 제안자가 사전 확인 제안을 통해 수익을 극대화할 수 있다고 믿는지 여부와 그 시점에 대한 질문은 본 연구에서 다루어졌습니다.

특정 슬롯에 대해 제안할 권리가 있는 최종 제안자는 해당 슬롯에 대한 제안 시간보다 앞서 구매가 이루어지는 한, 즉 적시에 구매가 이루어지지 않는 한 해당 슬롯에 대한 사전 확인을 제안할 수 있습니다.

4.2.c. 처벌과 팁의 효과

슬래싱의 효과는 사전 협의 담보 요건에 따라 달라집니다. 이는 모든 사전 확인 프로토콜에 해당하지만, 아직 결정되지 않은 주요 APS 질문 중 하나는 실행 제안자(execution proposalr)의 담보 요건, 즉 사전 협의자(preconfirmer)에 대한 담보 요건입니다. 담보 요건이 APS를 통해 시행될 경우, 이 담보는 사전 확인을 포함한 제안자 약정에 사용될 가능성이 높습니다. 실행 제안자에 대한 담보 요건이 프로토콜 내에서 시행되는지 여부와 관계없이, 사전 협의 권리와 슬래싱을 관리하는 일종의 사전 협의 레지스트리 계약이 존재할 것입니다. 이는 블랙리스트 및 평판 기반 주문 흐름 제한 또한 가능함을 의미합니다.

APS는 제안자 중앙화의 영향을 제어/격리하기 위한 것이므로, APS는 각 APS 경매에서 경쟁할 수 있는 소수의 제안자를 더 자주 선출하게 할 가능성이 높습니다. 제안자당 하나의 주소를 사용함으로써 주문 흐름과 블랙리스트에 대한 인센티브가 더욱 효과적으로 제공됩니다. 그러나 제안자는 악의적인 행위로 인한 평판 손실을 격리하기 위해 APS 선거에 참여하는 여러 주소를 생성할 수 있습니다. 이러한 전략이 악의적인 행위를 수행하는 제안자가 소유한 비악의적인 주소의 평판을 유지하는 데 효과적인지는 현재 명확하지 않습니다. 이는 평판 메커니즘의 시빌 저항성(sybil-resistance)에 대한 문제이며, 이에 대해서는 앞서 자세히 논의되었습니다.

이에 대한 몇 가지 완화책은 다음과 같습니다.

APS 제안자에게 사용자가 면밀히 검토하고 감사할 수 있는 신원 기반 공개 키를 유지하도록 요구합니다. 신원 기반 키는 전형적인 시빌 공격 방지 수단입니다.
APS 제안자가 여기 와 여기에서 논의된 바와 같이 신뢰 실행 환경(TEE) 내에서 블록 생성 코드를 실행할 수 있도록 허용합니다. 이를 통해 제안자가 악의적인 행위를 수행할 때 발생할 수 있는 공격 표면을 최소화하고, APS 제안자에게 최소한의 평판을 제공하는 데 활용할 수 있습니다.

섹션 5. 제안자-건설자 분리(ePBS)

5.1. ePBS 개요

PBS(Proposer-Builder Separation) 방식에서 Proposer는 실행 페이로드를 생성할 권한을 Builder 라는 정교한 엔티티에게 팁(tip)과 교환하여 경매합니다. 이 방식에서 비콘 Proposer와 Builder 간의 공정한 교환, 즉 Proposer가 Builder의 페이로드를 포함하는 경우에만 팁을 받도록 하는 것은 Relayer 라는 신뢰할 수 있는 제3자를 통해 중재됩니다.

ePBS (enshrined Proposer-Builder Separation) 에서는 경매가 프로토콜 내에서 진행되므로 공정한 교환을 보장하기 위해 프로토콜 외부 중계자가 필요하지 않습니다. 비콘 제안자는 빌더로부터 직접 입찰을 받고 최고 입찰자가 제출한 실행 페이로드의 해시값을 포함합니다. 이후 빌더는 전체 실행 페이로드를 공개합니다. 기존 이더리움 프로토콜과 달리, ePBS는 검증자 위원회가 빌더가 페이로드를 올바르게 공개했는지 확인하는 추가적인 검증 단계를 도입합니다.

5.2. 사전 확인 분석

우리는 모든 유형의 사전 확인을 종합적으로 검토합니다. 왜냐하면 각 사전 확인은 호환성 측면에서 유사한 특성을 보이고, 처벌과 팁의 효과도 다르기 때문입니다.

호환성

호환성에 영향을 미치는 주요 요소는 다음과 같습니다.

ePBS를 통해 제안 권리를 경매하는 것이 의무적인지 여부.
비콘 제안자가 지정할 수 있는 강제 블록 제약 조건이 존재하며, 이는 ePBS 경매에 참여하는 모든 빌더가 준수해야 합니다. 이러한 강제 메커니즘은 과거에도 암시된 바 있지만, 정확한 설계는 명시되지 않았습니다. 빌더가 제안자가 지정한 블록 제약 조건을 준수하도록 강제하는 한 가지 가능한 메커니즘은 빌더에게 스테이킹을 강제하는 것( ePBS EIP-7732에 제안된 바와 같이 )이며, 블록 제약 조건을 준수하지 않는 블록을 공개하는 빌더를 삭감하는 것입니다.

제안자 권한 경매가 의무적이고 집행 가능한 차단 제약 조건이 존재하는 경우, 비콘 제안자는 모든 유형의 사전 확인을 제공할 수 있습니다(모든 유형의 사전 확인을 가능하게 하는 집행 메커니즘 유형에 대한 구체적인 내용은 4.2.b절 참조). 1절에서 언급했듯이, ePBS 빌더 사전 확인은 빌더가 독점적인 제안 권한을 통제하지 않으므로 고려하지 않습니다.

제안자 권리 경매가 의무적이고 집행 가능한 블록 제약 조건이 존재하지 않는 경우, 사전 확인은 양립할 수 없습니다. 특히, 비콘 제안자는 최종적으로 경매에서 낙찰받는 건설사가 사전 확인을 준수할 의무가 없으므로 안전하게 사전 확인을 발행할 수 없습니다.

경매가 선택 사항인 경우, 비콘 제안자는 모든 유형의 사전 확인을 발행할 수 있습니다. 시행 가능한 블록 제약 조건이 있는 경우, 제안자는 자체 블록을 구축하거나 구축 권한을 경매할 수 있습니다. 시행 가능한 블록 제약 조건이 없는 경우, 제안자는 자체 블록을 구축해야 합니다.

처벌과 팁의 효과

경매가 선택 사항일 경우, 처벌과 팁은 이더리움 초기 설계의 사전 확인과 동일한 효과를 기대할 수 있습니다. 사전 확인 대상 선정 절차가 동일하며, 사전 확인 발행을 위한 공간도 동일하게 확보되기 때문입니다.

강제 블록 제약의 경우, 호환되는 사전 확인 설계는 기존 이더리움 설계의 사전 확인과 유사한 처벌 및 팁 효과를 가질 것으로 예상합니다. 주요 차이점은 사용 가능한 블록 공간의 양에 있습니다. 이전 섹션에서 논의했듯이, 감소된 블록 공간은 슬롯당 사전 확인에서 예상되는 보상에 영향을 미칠 수 있으며, 이는 다시 주문 흐름 손실이나 블랙리스트 등재와 같은 처벌 메커니즘의 효과에 영향을 미칠 수 있습니다. 예상 보상의 증가 또는 감소는 팁이 감소된 블록 공간을 상쇄할 만큼 충분히 증가하는지에 따라 달라집니다.

출처

면책조항: 상기 내용은 작자의 개인적인 의견입니다. 따라서 이는 Followin의 입장과 무관하며 Followin과 관련된 어떠한 투자 제안도 구성하지 않습니다.

라이크

즐겨찾기에 추가

코멘트