Conor McMenamin 과 Lin Oshitani 가 공동 집필했으며, 둘 다 Nethermind Research의 구성원입니다 .

요약

우리는 사전 확인의 적시-공정한 교환을 시행하려는 프로토콜을 분석하기 위한 프레임워크를 개략적으로 설명합니다. 이 프레임워크 내에서 우리는 명확하게 지배적인 적시-공정한 교환 프로토콜 설계를 개략적으로 설명합니다. 우리는 기존 L1 및 L2 설계와 관련하여 이러한 최적 프로토콜의 실행 가능성을 논의하고, 우리의 프레임워크를 기존 사전 확인 프로토콜에 적용합니다.

감사의 말 및 면책 조항

이 기사는 PBS Foundation 에서 자금을 지원받았습니다. 도움이 되는 리뷰를 해주신 Davide Rezzoli , Ellie Davidson , Christian Matt 에게 감사드립니다. 표현된 모든 견해는 저자의 견해이며 반드시 Nethermind, PBSF 또는 리뷰어를 대표하는 것은 아닙니다.

소개

사전 확인(preconf)은 사용자에게 더 빠른 확인 시간을 제공하는 경로로서 이더리움 생태계 내에서 관심 주제로 떠올랐으며, 이는 Web2의 거의 즉각적인 사용자 경험과 유사합니다. 사전 확인이 자리 잡으려면 블록 제안자가 제안 슬롯에서 더 일찍 상태를 확인하는 기회 비용을 지불하고 사전 확인자가 되도록 하는 인센티브가 필요합니다. 이는 제안 슬롯이 끝날 때 블록을 적시에 구축하는 현상 유지와 대조적입니다. 이 인센티브는 수수료 형태로 제공되며, 사용자는 사전 확인이 제공될 시간 선호도를 지정하고 사전 확인자는 사용자의 시간 및 실행 선호도를 충족하는 대가로 수수료를 수락할지 여부를 선택합니다.

이 문서는 사용자 선호도에 따라 사전 구성을 적시에 제공할 수 있는 설계 공간을 이해하는 데 중점을 두고 있습니다. 사전 구성을 다음과 같이 정의합니다.

정의 1: 사전 확인

거래 사전 확인은 거래가 L1 제안자가 서명한 L1 블록에 포함되기 전에 거래를 포함하거나 실행하겠다는 약속입니다.

L1에 제출할 기회가 있어야 합니다. L1 사전 협의의 경우, 이는 다음을 통해 사전 확인되는 것을 의미할 수 있습니다.

• L1 제안자,
• L1 제안자를 대신하여 사전 확인을 위임받은 사람
• L1 제안자가 제안하는 블록을 건설할 권리에 대한 경매에서 이길 가능성이 있는 건설자(예: mev-commit) .

L2 사전 구성 설계는 위에 나열된 것 중 하나, 특히 기반 롤업 과 기반 사전 구성 의 경우에 주어질 수 있습니다. 그러나 L2 사전 구성은 일반적으로 L1에서 L2 블록을 제안할 독점적 권한을 가진 L2 거버넌스에 의해 지정된 중앙 집중식 시퀀서에 의해 주어집니다.

사전 컨펌을 제공할 수 있는 사람과 관계없이 사용자는 거래를 의미 있게 사전 확인할 수 있는 엔터티가 사전 컨펌을 제공할 것이라는 보장이 필요합니다. 특정 사전 컨펌/사전 컨펌 프로토콜은 지정된 제안자에게 단순히 거래를 확인하는 것보다 수익이 적기 때문에 사용자는 제안자에게 거래를 사전 확인하도록 인센티브를 제공해야 할 가능성이 높습니다. 이는 제안자에게 사전 컨펌을 제공할 의무가 없고 허가가 없는 프로토콜에서 특히 그렇습니다. 제안자에게 거래를 사전 확인하도록 인센티브를 제공하기 위해 고려 중인 솔루션은 사전 컨펌의 적시 공정한 교환 에 달려 있습니다. 이 문서의 나머지 부분은 적시 공정한 교환의 속성에 초점을 맞춥니다. 즉, 그것이 무엇이고, 어떻게 시행되고, 언제 유지되고, 언제 유지되지 않는지입니다.

독립적인 관심사로서, 신뢰할 수 있는 제3자가 없는 반복 게임 설정에서 공정한 거래 교환이 어떻게 이루어질 수 있는지 보여드립니다. 이는 일회성 게임에서는 알려진 불가능성입니다. 프레임워크 내에서 제공되는 공정한 교환 보장은 인센티브에 기반하지만, 이러한 인센티브는 공정한 교환을 위반하는 거래를 확인하는 엔터티의 비용에 직접 비례합니다. 이러한 비용은 임의로 높을 수 있습니다. 이는 사전 구성을 제공하는 엔터티가 공정한 교환을 제공하는 데 대한 일관된 긍정적인 보상과/또는 이탈하는 데 대한 부정적인 "종말의 날" 보상이 있는 반복 게임을 할 때 분명해집니다. 이러한 인센티브는 공정한 교환을 제공하는 데 대한 수수료를 수집하고 각각 기반 블록체인에 대한 신뢰에 가치가 연결된 대규모 토큰 보유를 갖는 것과 일치합니다. 이러한 비용에 의해 제한된 일회성 이탈 인센티브는 비합리적이 됩니다. 이는Folk's Theorem 과 같은 게임 이론적 결과와 일치합니다.

기사의 구성

우리는 적시 공정한 교환의 개념을 소개하는 것으로 시작하고, 이어서 적시 공정한 교환 솔루션을 고려하고 비교할 수 있는 프레임워크를 소개합니다. 이 프레임워크는 모든 적시 공정한 교환 프로토콜에 필요한 구성 요소와 그러한 프로토콜의 주요 속성 및 요구 사항을 설명합니다. 이 프레임워크를 사용하여 기본 블록체인의 설계 제약 조건에 따라 적시 공정한 교환 프로토콜에 대한 최적의 솔루션을 식별합니다. 그런 다음 기존 및 미래 사전 구성 프로토콜에 프레임워크를 적용하고 게이트웨이가 L1 사전 구성 솔루션으로 적합한지에 대한 논의를 포함합니다.

시기적절한 공정한 교환

전통 문헌 에서 공정한 교환 속성은 다음과 같이 정의됩니다.

정의 2: 공정한 교환

두 당사자가 디지털 항목(예: 전자 계약, 지불 또는 서명)을 교환할 때, 두 당사자 모두 예상한 항목을 받거나 아무도 받지 못합니다.

그러나 서론에서 보았듯이, 사전 회의의 경우 교환의 시기적절함이 핵심입니다. 이 직관을 포착하기 위해 적시 공정 교환 또는 줄여서 TFE라는 속성을 도입합니다.

정의 3: 적시 공정 교환(TFE)

두 행위자가 디지털 항목(예: 전자 계약, 지불 또는 서명)을 교환할 때, 두 당사자 모두 예상 항목을 받거나 아무도 받지 못합니다. 더욱이, 교환에 대한 알림은 당사자 중 한 명이 지정한 일부 목표 시간 범위, target 내에서 이루어져야 합니다 .

TFE에서 교환되는 항목은 사용자 가 제공하는 preconf 팁과 preconfirmer가 제공하는 preconf 자체입니다. 또한, 대상 시간은 사용자가 preconf 요청에서 지정합니다.

TFE 배우

모든 TFE 사전 협의 프로토콜에는 고려해야 할 세 가지 행위자가 있습니다.

• 사용자 : 적시에 사전 구성을 요청하는 엔티티입니다.

• 사전 확인자 : 사전 확인을 제공하는 엔터티. 이 글에서 우리는 사전 확인자가 합리적이며, 특정 시간 범위 내에서 예상 유용성을 극대화하는 행동을 선택한다고 가정합니다. 특정 처벌의 효과는 사전 확인자가 다음에 해당하는지에 따라 달라집니다.

  • 원샷 사전 확인 : 익명화, 허가 불필요 및/또는 소수의 고정된 사전 설정 슬롯에 대해서만 사전 설정.
  • 반복 게임 사전 확인자: 잘 알려져 있고, 허가를 받았으며, 많은 수의 사전 확인 슬롯/무기한 동안 프로토콜에 참여할 것으로 예상됨.

  이것들은 다차원적 분류이기는 하지만, 단지 광범위한 목적을 위해서만 의도된 것입니다. 이러한 분류 내에서, 이더리움 검증자 세트는 일반적으로 원샷으로 설명되는데, 검증자는 현재 140일마다 1블록을 제안하도록 선출되고 검증자 세트에 가입하거나 탈퇴하기 위한 현재 대기 시간은 1일 미만이기 때문입니다. 반복 게임 사전 확인자의 템플릿은 L2의 중앙 집중식 시퀀서이고, L1의 위임된 게이트웨이는 반복 게임일 가능성이 높지만, 게이트웨이 설계에 대한 세부 사항은 아직 나오고 있습니다.

• 감독자 : 사전 확인자가 TFE를 제공하도록 강제하거나 인센티브를 제공할 수 있는 일련의 조치를 통해 TFE를 모니터링하는 엔터티(또는 엔터티들). "감독자" 분류 내에서는 많은 감독자 설계가 가능합니다. 감독자는 단일 엔터티이든 그룹이든 두 가지 방법으로 구현할 수 있습니다. 프로토콜에 명시적으로 지정하여 공식적으로 구현하거나, 아래에 설명된 대로 명시적으로 지정하지 않고 비공식적으로 구현할 수 있습니다.

  • 공식적인 :
    • 롤업 제네시스에서 결정되었습니다.
    • 통치에 의해 선출됨.
    • 지분 증명과 같은 토큰 보유 요구 사항을 통해 선출되며 다음 중 하나 또는 둘 다와 일치합니다.
      • 사전 설정 프로토콜.
      • 기본 합의 프로토콜.
    • 기본 합의 프로토콜의 검증자가 악의적인 사전 확인자를 슬래싱하기 위해 협력할 수 있는 일종의 주관적 슬래싱을 통한 암묵적 감독자. 주관적 슬래싱에 대한 자세한 내용은 여기 , 여기 , 여기를 참조하세요. 이러한 유형의 솔루션은 감독자 기반 L1 사전 컨펌 TFE에만 실제로 필요합니다. 슬래싱을 위해 L1 검증자를 협력하는 것이 적절한지는 기술적 논쟁이라기보다는 철학적 논쟁에 가깝기 때문에 이 기사에서는 이 기술에 대한 추가 논의를 생략합니다.
  • 비공식 : 프로토콜 내에서 명시적으로 지정되지 않은 감독자. 예를 들어, 다음과 같습니다.
    • 사용자, 즉 사용자를 대신하여 행동하는 지갑이나 L2 전체 노드는 사전 확인을 추적하고 TFE가 의심되는 경우 다른 사용자에게 메시지를 전파합니다( 사용자 모니터링 ) .

감독자가 필요한 이유는 신뢰할 수 없는 사전 확인자와 사용자 간의 TFE는 분쟁을 중재하기 위한 감독자가 도입되지 않으면 보장될 수 없다는 레거시 불가능성 결과에서 비롯됩니다 . 이러한 불가능성을 염두에 두고 이 문서에 도입된 모든 TFE 솔루션은 다음 중 하나를 활용합니다.

1. 신뢰받는 감독자. 우리는 이러한 솔루션을 신뢰할 수 있는 TFE를 만족시키는 것으로 부릅니다.
2. 신뢰할 수 없지만 경제적으로 합리적인 감독자. 우리는 이러한 솔루션을 경제적 TFE를 만족시키는 것으로 부릅니다.

신뢰할 수 있거나 경제적인 TFE의 이러한 속성은 감독자가 기본 합의 프로토콜의 검열과 활성에 영향을 미칠 수 있는 정도나 합리적인 사전 확인자가 정직하게 행동할 정확한 인센티브에 대해서는 아무 말도 하지 않습니다. 이러한 속성의 정확한 분류는 프로토콜별로 설명되며 진행 섹션에 요약되어 있습니다.

합리적인 사전 확인자가 경제적인 TFE 프로토콜에서 TFE와 다른 이유는 무엇일까요?

사전 확인자가 TFE에서 벗어나는 인센티브는 시간에 따라 사전 설정된 기본 거래 또는 상태 액세스의 가치 변화에서 비롯됩니다. 즉, CEX-DEX 중재 와 같은 특정 유형의 MEV는 시간에 따라 기대치가 증가하는 것으로 입증되었습니다. 이보다 더 중요한 것은 mempool의 크기가 커짐에 따라 거래 주문의 조합도 커지는데, 이는 마지막 순간까지 거래 확인을 지연할 수 있는 능력을 가진 제안자와 사전 확인자에게도 가치의 원천입니다.

TFE 솔루션의 특성

TFE 솔루션의 효율성을 결정하는 두 가지 주요 속성은 다음과 같습니다.

• 처벌 : 어떤 신뢰 가정이나 경제적 메커니즘이 TFE가 사용자에게 예상대로 유지되도록 보장합니까?
• 감독자에 대한 활성성 의존성 : 감독자에 의해 검열 및 활성성과 관련된 추가적인 신뢰 가정 또는 위험이 도입됩니까?

처벌

모든 TFE 처벌은 TFE 위반에 의해 유발되며, 위반은 사전 확인자가 사전 협의 요청의 대상 시간 범위를 위반하는 것과 일치합니다. TFE 보장의 가능한 강도는 처벌의 강도와 거의 직접적으로 대응하며, 아래에서 강도의 대략적 순서(가장 강한 것에서 가장 약한 것)로 설명합니다.

1. 실시간 처벌 허가된 감독자는 모든 사전 구성 요청을 처리하고 각 요청에 해당하는 사전 구성이 TFE를 충족하도록 강제합니다. 이는 다음에 따라 수행할 수 있습니다.
   1. 사전 협의는 감독자가 사전 협의에 서명한 경우에만 유효합니다.
   2. 요청은 감독자를 통해 사전 확인자에게 전달되어야 합니다.
   3. 사전 협의 팁은 감독자가 사전 협의에 서명한 경우에만 유효합니다.
2. 사후 처벌:
   1. 슬래싱: 사전 확인자는 사전 컨프 프로토콜에 의해 설정된 일부 미리 정해진 금액을 잃습니다. 위반은 하나 이상의 요청이 TFE되지 않음을 의미하지만, 합리적인 사전 확인자는 TFE를 위반하여 지분 담보를 위험에 빠뜨리는 것을 피하기 때문에 사용자는 간접적으로 TFE를 보호받습니다. TFE 위반을 중재하기 위해 허가된 감독자가 필요합니다.
   2. 블랙리스트: 사전 확인자는 지정된 기간 동안 사전 협의에서 블랙리스트에 등록됩니다. 블랙리스트를 업데이트하려면 권한이 있는 감독자가 필요합니다.
   3. 단기 주문 흐름 손실: 사전 확인자가 TFE를 위반하면 사전 확인자는 현재 사전 확인 슬롯(여러 Ethereum 합의 슬롯에 걸쳐 있을 수 있음)의 나머지 기간 동안 사용자로부터 사전 확인 주문 흐름을 잃습니다. 이 주문 흐름 손실은 사용자 모니터링 또는 일부 허가된 감독자에 의해 트리거될 수 있습니다.
   4. 장기 주문 흐름 손실: 사전 확인자가 TFE를 위반하면 사전 확인자는 모든 미래 사전 설정 슬롯에 대한 사전 설정 주문 흐름을 잃습니다. 다시 말하지만, 이 주문 흐름 손실은 사용자 모니터링이나 허가된 감독자에 의해 트리거될 수 있습니다.

우리는 모든 프로토콜이 페널티 2.x 2.x 를 구현하면 최소한의 추가 프로토콜 변경으로 2.(x+1) 2. ( x + 1 ) 도 구현할 수 있도록 이러한 사후 TFE 페널티를 명령했습니다. 즉, 사전 확인자를 블랙리스트 에 추가할 수 있는 권한이 있는 엔터티가 있는 모든 프로토콜은 해당 권한이 있는 엔터티를 사용하여 사용자와 지갑에 단기 c c ., 장기 d d . 주문 흐름 을 위반 하는 사전 확인자 에게 보내는 것을 중단 하라고 신호를 보낼 수 있습니다 .

감독자에 대한 라이브니스 의존성

TFE의 이 속성은 사전 컨펌 프로토콜과 기본 블록체인 프로토콜이 Overseer에 미치는 노출을 식별하는 것을 목표로 합니다. 활성도에 영향을 미치는 위협은 사전 컨펌자의 잘못된 행동을 억제하는 데 사용될 수 있지만, 사전 컨펌이 제공되는 체인의 검열 및 활성도 속성을 변경할 수도 있습니다.

활성 상태를 위한 중요 종속성 경로에 Overseer를 배치하는 TFE는 엄격한 활성 상태 요구 사항이 있는 프로토콜에 TFE 프로토콜을 배포하는 데 적합하지 않다고 간주합니다.

이미지 1171×361 82KB

단순화를 위해 이 문서에서는 "활성 종속성" 또는 "활성 종속성 없음"을 넘어서는 향후 활성 종속성 한정을 피합니다.

TFE 솔루션 비교를 위한 프레임워크

이전 섹션의 속성과 분류를 손에 쥐고, 이제 처벌의 강도와 사전 확인자 범주에 따라 사전 협의 프로토콜을 비교할 준비가 되었습니다. 이미 설명한 구성 요소를 요약하면, TFE 솔루션은 다음 구성 요소를 정의해야 합니다. 굵은 글씨 로 강조 표시된 부분은 해당 구성 요소의 이상적인 구현을 나타내며, 다른 모든 것은 동일합니다.

1. 감독자 정의 :
   1. 감독관은 공식적인가요?
      • 아니요: 감독자를 통치하거나 보조금을 지급할 필요가 없습니다.
      • 예: 감독자를 선정하고 감독하기 위해서는 거버넌스 및/또는 보조금 지원이 필요합니다.
   2. (특정 구현의 경우) 감독자는 TFE 실패를 어떻게 식별하고 보고할 수 있습니까?
2. 집행 및 처벌 : TFE 위반자에게는 어떤 처벌이 부과됩니까? 우리는 이러한 처벌을 다음과 같이 분류했습니다.
   1. 실시간 시행
   2. 날카로운
   3. 블랙리스트
   4. 단기 주문 흐름 손실
   5. 장기 주문 흐름 손실

각 TFE 솔루션에 대해 우리는 주로 두 가지 속성에 관심이 있습니다. 굵은 글씨 로 강조 표시된 부분은 해당 속성의 이상적인 만족도를 나타내며, 다른 모든 것은 동일합니다.

1. 처벌의 효과성: 처벌이 TFE를 보장하는 데 효과적일 것으로 기대되는가? 우리는 이 속성의 만족을 3차 변수로 유지하려고 노력한다.
   1. 높음: 처벌이 매우 효과적입니다.
   2. 중간: 처벌은 높음 또는 낮음의 효과를 갖도록 매개변수화될 수 있으며, 정확한 구현 세부 사항이 중요합니다.
   3. 낮음: 처벌이 효과적이지 않습니다.
2. 감독자에 대한 활성성 종속성: 감독자가 기반 블록체인의 검열 저항성과 활성성에 영향을 미칠 수 있는가?
   • 아니요: 이상적으로는 감독자에 대한 생존 의존성이 없어야 합니다.
   • 예: 종속성이 존재하므로 바람직하지 않습니다.

구체적인 프로토콜을 정의하기 전에, 이제 우리는 각 TFE 시행 메커니즘이 One-Shot 및 Repeated-Game Preconfirmer가 있는 상황에서 어떻게 수행되는지에 대한 높은 수준의 이해를 제공합니다. 이를 위해 우리는 제안자 유형과 시행 메커니즘의 각 조합에 대해 다음을 설명하는 트리플을 지정합니다.

( 1. 감독자에 대한 생명력 의존성,
2. 정식 감독자의 필요성
3. 처벌의 효과 t )

표 1: 제안자 유형과 집행 메커니즘의 조합 분석. 굵은 글씨로 표시된 항목은 해당 속성의 광범위한 선호 만족도를 나타냅니다. 즉, 다음과 같습니다.
1. 감독자에 대한 생존 의존성이 없습니다.
2. 공식적인 감독자가 필요하지 않습니다.
3. 집행 및 처벌의 높은 효과성

* 사전 설정 슬롯에서 남은 주문 흐름의 예상 값에 따라 달라집니다.
** 슬래시 금액에 따라 달라집니다.

프레임워크 내 최적의 TFE 솔루션

만약 우리가 굵은 글씨로 표시된 튜플 항목에만 집중한다면, 오늘날 모든 속성을 최적으로 충족하는 하나의 일반적인 TFE 솔루션 클래스가 배포 가능합니다. 이는 표 1의 " 단기 및 장기 주문 흐름 손실이 있는 반복 게임 사전 확인자 "입니다.

L2의 경우, L2 거버넌스에서 선출된 중앙집중식 시퀀서는 이에 대한 이상적인 후보입니다. L1에서 제안자 역할을 하는 분산형 검증자 세트가 있는 상황에서 반복 게임 사전 확인기를 도입하는 것은 그렇게 명확하지 않습니다. L1에서 반복 게임 사전 확인기의 잠재적 구현인 게이트웨이에 대한 논의는 논의 섹션으로 미룹니다.

이미지 692×399 56.1KB

L2에 초점을 맞추면, L2 거버넌스에 의해 선출된 중앙집중식 시퀀서는 우리가 거버넌스 선출 감독자가 될 것이라고 생각하는 것과 같은 방식으로 "최대로 정렬"됩니다. 사용자 모니터링이 있는 경우 중앙집중식 시퀀서가 TFE를 위반하지 않을 것이라고 확신할 수 있습니다. 그렇게 하면 사용자의 이탈과 시퀀서/거버넌스 토큰 보유의 평가 절하가 발생할 위험이 있기 때문입니다. 프레임워크에서 장기 주문 흐름 손실이 최대가 됩니다.

그러나 중앙집중식 시퀀서는 단기 검열 및 활성을 위해 중요 경로를 따라 단일 장애 지점을 생성합니다. 이 장애 모드는 TFE 프레임워크 내에서 허용되지만, 중앙집중식 시퀀서 L2 사용자는 시퀀싱을 위해 지연된 받은 편지함에 의존해야 하며, 롤업의 지연된 받은 편지함 설계 에 따라 24시간 이상의 지연이 발생할 가능성이 있습니다.

그렇다면 중앙 집중식 시퀀서가 없는 환경에서 최적의 솔루션은 무엇일까요?

중앙 시퀀서 없이 사전 확인을 위한 최적의 TFE 솔루션

이제 중앙 집중식 시퀀서 설정 외부에서 preconf를 사용하는 주요 환경과 각 환경에 가장 적합하고 효과적인 TFE 솔루션을 간략하게 설명하겠습니다.

분산형 L2 제안자 세트를 사용한 L2 사전 확인

이 설정에는 Taiko , Surge 등의 L2 기반 프로토콜이 포함됩니다.

권장 사항: 슬래싱 기능이 있는 정식 감독자. 이는 표 1의 " 슬래싱 기능이 있는 원샷 사전 확인자 " 사례에 해당합니다.

이유: 시행 메커니즘의 효율성이 높고, 감독자에 대한 활성 의존성이 없으며, 롤업 거버넌스에서 감독자를 선택하여 L2의 장기적 성공에 최대한 부합할 수 있습니다.

이미지 692×527 73.4KB

구성 요소를 살펴보겠습니다.

• 감독:
  • 누구: 감독자는 단일 TTP, 여러 TTP, 사전 동의 사전 확인자, 독립 AVS 또는 사전 동의 검증자가 될 수 있습니다. 감독자는 롤업 거버넌스에 의해 관리되는 것이 좋습니다. 롤업은 단기 수익 손실에 대한 대가로 좋은 UX를 제공하도록 인센티브를 제공받기 때문입니다.
  • 장애 감지 메커니즘: 감독자는 사전 협의를 적시에 완료하기 위한 합의를 형성합니다.
• 집행 및 처벌 :
  • 적시에 릴리스가 이루어지지 않으면 위원회의 합의는 경고 신호로 지갑으로 전송되거나 다음 중 하나에 L1에 게시될 수 있습니다.
    • 사전 확인자를 블랙리스트에 추가합니다.
    • 사전 확인자를 삭제하세요.

속성:

• 보증의 강도
  • 사용자로서, 귀하가 보내는 모든 사전 협의 요청은 TFE의 사전 협의에 대한 경제적 보장만 있습니다. 그러나 감독 위원회가 정직한 한, 사전 확인자는 삭감을 피하기 위해 TFE를 지지하도록 인센티브를 받아야 합니다.
• 감독자에 대한 라이브니스 의존성
  • 없음. 슬래싱은 소급적으로만 적용되기 때문입니다.

L1 사전 확인

L2 사전 구성의 경우와 달리 L1 사전 구성에 대한 명확한 권장 프로토콜은 없습니다. 각각 다른 상충 관계를 가져오기 때문입니다. 따라서 다음 요구 사항에 따라 두 가지 권장 사항을 제시합니다.

1. "패스트트랙" 권장 사항 : 기본 프로토콜에서 선출되지 않은 공식 감독자를 도입하더라도 L1 사전 협의를 즉시 활성화하고 인센티브를 제공하고자 합니다.
2. "느리지만 꾸준한" 권장 사항 : L1 블록 구축 파이프라인에 공식적인 감독자를 도입하는 대신 게이트웨이 위임 및/또는 증명자-제안자 분리에 대한 연구가 성숙될 때까지 기다립니다. 그 시점에서 독점을 방지하기 위해 "가드레일"(부록에서 논의)을 구현할 수 있으며, 사용자 모니터링과 사전 확인자 평판의 조합이 TFE 솔루션으로 사용될 수 있습니다.

"패스트트랙" 권장 사항: TFE 위반에 대한 슬래싱을 시행하기 위해 하나 이상의 외부 감독자 프로토콜을 활용합니다. 이 프로토콜에 대한 설명은 이전 섹션 인 분산형 L2 제안자 세트를 사용한 L2 사전 확인 에서 설명한 프로토콜과 동일하지만, 공식 감독자에 대한 덜 명확한 설계가 있습니다.

이유: 집행 메커니즘의 효율성이 높고, 감독자에 대한 의존성이 없습니다.

왜 안 되나?: L1의 공식 감독자 구현에 대한 개방형 질문.

이미지 692×527 78.7KB

"느리지만 꾸준히" 권장: TFE에 대한 비공식적인 사용자 모니터링의 어떤 형태를 활용하여 TFE 위반 사항을 식별하고 광범위한 커뮤니티에 알립니다.

이유: 감독자에 대한 생존 의존성이 없고, 공식적인 감독자가 필요하지 않습니다.

그렇지 않은 이유: 반복적인 게임 사전 확인 없이 시행 메커니즘의 효과가 낮습니다.

이미지 692×399 56.1KB

구성 요소를 살펴보겠습니다.

• 감독:
  • 누구: preconf 프로토콜의 최종 사용자.
  • 실패 감지 메커니즘: 사전 구성의 적시 릴리스를 로컬에서 모니터링합니다. 실제로 모니터링은 지갑이나 연결된 전체 노드에서 수행됩니다.
• 집행 및 처벌 :
  • TFE 위반이 감지되면 사용자 주문 흐름을 사전 확인자에게 보내는 것을 중지합니다.
  • 사전 확인이 이루어지지 않은 주문 흐름으로 인해 사전 확인자의 평판이 손상되었습니다.

속성:

• 보증의 강도
  • 사용자로서, 귀하가 보내는 사전 구성 요청에는 TFE 보장이 없습니다. 그러나 위에서 언급한 처벌 메커니즘의 위협은 사전 확인자가 TFE를 지지한다는 경제적 보장을 제공합니다. 사전 확인자가 시행 메커니즘을 통해 잃는 주문 흐름의 가치가 클수록 TFE 보장이 더 강력해집니다. 사전 확인자에게 평판이 있고, 다시 선출될 가능성이 높으며, 요청이 슬롯에서 더 일찍 있을 때 사용자 모니터링을 통한 TFE 보장이 더 강력합니다. 이러한 모든 것이 TFE를 위반하는 데 대한 대안보다 더 높은 기회 비용을 수반하기 때문입니다. 평판이 없고, 다시 사전 확인을 위해 선출될 가능성이 낮으며, 사전 확인자 슬롯에 남아 있는 주문 흐름이 거의 없거나 전혀 없습니다.
• 감독자에 대한 라이브니스 의존성
  • 없음.

기존 프로토콜에 프레임워크 적용

오늘날 사용 중이거나 사용이 제안된 가장 잘 알려진 일부 사전 구성 프로토콜을 간략하게 설명하고 이러한 프로토콜이 TFE 프레임워크에 어떻게 들어맞는지 알아보겠습니다.

메브-커밋

Mev-commit은 다음과 같이 설명됩니다.

이미지 818×338 83.5KB

구성 요소를 살펴보겠습니다.

• 감독:
  • 누구: mev-commit에서 감독자는 사전 협의 요청의 만족에 대한 합의에 도달하는 책임이 있는 체인/위원회 입니다. 처음에 위원회 구성원은 권한 증명 합의를 실행하는 허용 목록에 있는 검증자이지만, 참여하기로 선택한 재투표 검증자를 포함할 계획입니다 .
  • 실패 감지 메커니즘: 위원회는 사전 협의가 제때에 공개되는지 여부에 대한 합의를 형성합니다.
• 처벌 :
  • 사전 설정 팁은 사전 설정 제공 시간에 따라 성능이 저하됩니다.
  • TFE가 위반되면(예: 사전 확인자가 사전 약속을 어기는 경우) 사전 확인자는 해고될 수 있습니다 .

속성:

• 보증의 강도
  • 현재 mev-commit에서 사전 설정 요청 조건을 위반하는 경우 슬래싱 금액은 낮으며, 대략 지불되는 팁과 같습니다. 저희 프레임워크 내에서 이 슬래싱 금액은 인센티브를 떨어뜨리는 슬래싱 금액(예: >1 ETH)보다 단기 주문 흐름 손실과 더 비슷합니다. 임의로 높은 슬래싱 금액을 구현하려는 계획이 있지만, 그러한 설계는 아직 구현되지 않았습니다.
• 감독자에 대한 라이브니스 의존성
  • 사전 컨프 라이브니스 종속성: 그렇습니다. 감독 위원회에 라이브니스 문제가 있거나 검열을 시작하면 사전 컨프가 해결될 수 없습니다.
  • 일반 거래 활성도 종속성: 아니요. 사전 확인자는 mev-commit을 활용할 의무가 없으며 mev-commit 외부에서 일반 거래를 소싱할 수 있습니다.

에스프레소 커피

Espresso는 반드시 TFE를 처리하도록 구성된 것은 아니지만 TFE를 활성화하도록 쉽게 조정할 수 있습니다. 이제 Espresso 아키텍처와 TFE를 처리하는 방법을 설명합니다.

이미지 818×338 83.5KB

에스프레소 구성 요소를 살펴보겠습니다.

• 감독:
  • 누구: 감독자는 재투표에 참여한 검증자들로 구성된 위원회입니다.
  • 실패 감지 메커니즘: 위원회는 합의를 형성하고, 합의는 사전 협의가 제때 발표되었는지 여부에 대해 동의하게 됩니다.
• 집행 및 처벌 :
  • TFE가 위반되면 L2 거래 자체는 L2 블록에 포함될 수 없습니다. 감독 위원회의 정족수 인증서는 L2 블록의 유효성에 필요한 요건이기 때문입니다.

속성:

• 보증의 강도
  • 위원회의 비잔틴 다수가 정직한 한, 사용자는 해당 사전 구성이 적시에 발표되지 않는 한 거래가 실행되지 않을 것이라고 보장받을 수 있습니다.
• 감독자에 대한 라이브니스 의존성
  • Preconf 활성 종속성: 예.
  • 일반 트랜잭션 활성성 종속성: Espresso는 Espresso 사전 구성을 선택하는 롤업에 대해 두 가지 가능한 디자인을 가지고 있습니다. 이는 활성성 실패(롤업 블록이 L1에 제출된 후 너무 많은 시간이 경과한 경우)의 경우 탈출 해치가 있거나 없는 것입니다.
    • 탈출구가 없으면 일반적인 거래는 감독 위원회에 따라 활발하게 진행됩니다.
    • 탈출 해치를 사용하면 거래의 최종 활성도가 유지됩니다. 그러나 단기 활성도(탈출 해치 시간 제한 전 활성도)와 검열 저항은 감독 위원회에 따라 달라집니다.

L1 게이트웨이 디자인

게이트웨이는 L1 제안자가 아웃소싱을 선택할 수 있는 정교하고 평판이 좋은 엔터티가 될 것으로 기대됩니다. 게이트웨이는 정교하고 기술적으로 진보적이며 평판이 좋은 엔터티가 되기 위해 필요한 투자로 인해 반복 게임 사전 확인자로 분류될 가능성이 거의 확실합니다. 이는 이론적으로 L2의 중앙 집중식 시퀀서와 유사해 보일 수 있지만, 게이트웨이가 잘못 작동하는 경우 강제 포함 메커니즘이 현재 없기 때문에 시행 메커니즘이 근본적으로 다릅니다. 이는 특히 TFE 시행과 해당 시행의 효과성과 관련하여 분명합니다.

게이트웨이에서 TFE를 감독하는 데 사용자 모니터링을 사용하는 경우, 사용자는 현재 게이트웨이가 잘못 작동하는 상황에서 L1에 거래를 제출할 수 있는 대체 메커니즘이 없습니다. 이 문제는 독점 게이트웨이가 있는 상황에서 심각해지며, 이는 역할의 중앙 집중화 특성(부록에 설명됨)을 감안할 때 분명히 발생할 가능성이 있습니다.

이를 염두에 두고 게이트웨이 TFE 또는 게이트웨이의 주관적 요구 사항을 시행하려면 공식적인 감독자가 필요한 것으로 보입니다. 적극적으로 검증된 서비스 (AVS)는 이러한 감독자를 구현하는 데 적합한 후보입니다. 그러나 L1 사전 확인자(제안자 포함)를 주관적으로 삭감할 수 있는 공식 감독자는 논란의 여지가 있는 설계 영역 입니다. 공식 감독자가 L1 사전 확인자를 주관적으로 삭감할 수 있는 범위는 불분명하며 이 작업의 범위를 벗어납니다. 나아가 L1에서 반복 게임 사전 확인자 보장을 달성하는 더 실행 가능한 경로는 또 다른 개방형 연구 영역인 Attestor-Proposer Separation 의 어떤 형태를 채택하는 것이라고 생각합니다.

결론

TFE 솔루션의 디자인 공간은 L1 및 L2 공간이 항상 발전하는 것과 거의 같은 방식으로 항상 발전하고 있습니다. 이 문서는 TFE 솔루션을 이해하고, 평가하고, 비교하기 위한 프레임워크를 수립합니다. 이 프레임워크의 핵심 요점 중 하나는 모든 TFE 솔루션이 감독자, 감독자가 TFE를 시행하는 방법, 감독자가 기본 블록체인에서 거래의 검열 및 활성에 영향을 미칠 수 있는 방법을 지정해야 한다는 필요성입니다.

롤업의 경우, 롤업의 성공(또는 롤업에서의 이탈)에 따라 얻거나 잃을 것이 많은 "게임 속의 스킨" 감독자를 사용하는 TFE 솔루션을 권장합니다. 이러한 감독자는 사전 협의의 적시적 공정한 교환의 주관적 특성을 처리할 완벽한 위치에 있습니다.

L1의 경우, 추천할 만한 명백히 우수한 TFE 솔루션은 없습니다. 허가 없는 검증자가 제안자를 겸하는 현재의 L1 디자인에서는 공식적인 모니터링이 필요할 가능성이 큽니다. 누가 신뢰할 수 있는 공식적인 감독자로 등장할 것인지, 그리고 그들의 처벌 역량이 얼마나 커야 할지는 불분명합니다. L1 사전 협의와 TFE에 대한 우리의 주요 권장 사항은 지배적인 제안자와 게이트웨이의 등장으로부터 L1의 검열과 활성 상태를 보호하는 데 필요한 보호 장치를 구현하는 것입니다.

충수

확장된 게이트웨이 토론

검증자 세트에서 의사 난수로 선출된 제안자의 현재 L1 디자인에서 이러한 제안자에 의한 게이트웨이 선택은 게이트웨이가 제안자에게 약속할 수 있는 예상 수익 금액을 놓고 경쟁하는 "게이트웨이 시장"과 거의 유사할 것입니다. 사실상 사전 경매입니다.

제안자 수익에 대한 경쟁은 게이트웨이 정교함(블록 구축 및 MEV 추출 기능, 위험 허용 범위, 연결성, 일반적인 인프라)과 사용자가 게이트웨이에 주문 흐름을 보내도록 보장하는 평판에 달려 있습니다. 선출되면 게이트웨이는 실행 사전 구성을 제공하기 위한 독점적 액세스 권한을 얻습니다. 이는 다음과 같은 자체 유지 플라이휠을 생성합니다.

평판 → 주문 흐름 → 블록 가치 → 수익성 → 선거 확률 → 평판…

이것은 중앙집중화된 시스템입니다.

1. 경매의 사전 특성은 게이트웨이가 장기적으로 제안자 수익을 놓고 경쟁 한다는 것을 의미합니다.
   a. 어떤 기간 동안 가장 높은 평균 제안자 수익을 가진 게이트웨이는 단 하나일 수 있습니다. 슬롯을 사전 확정하기 위해 가장 높은 예상 제안자 수익을 가진 게이트웨이는 결국 변경될 수 있지만, 경쟁자가 기술적 우위를 얻는 데 걸리는 시간 때문에 단기 및 중기 기간(몇 달에서 몇 년) 동안은 변경되지 않습니다. 이는 속도와 실행 품질이 게이트웨이 요구 사항과 직접 관련이 있지 않더라도 비슷한 현대의 고빈도 거래 시장( 여기 , 여기 , 여기 논의)에서 반복적으로 확인되었습니다.

   b. 더 작은 게이트웨이가 사용자를 설득하여 주문 흐름을 자신만을 위해 독점적으로 예약하도록 하지 않는 한(실행이 지연된다는 것을 의미하더라도) 또는 검증자가 더 낮은 수익을 제공하더라도 자신에게 위임하도록 설득하지 않는 한, 모든 게이트웨이 마켓플레이스는 궁극적으로 승자 독식 시장이 될 것입니다.

2. 신규 진입자는 지배적인 게이트웨이와 경쟁하기 위해 상당한 기술 투자를 해야 합니다. 이는 소수의 고자원 개인만이 할 수 있는 기술적 군비 경쟁을 만들어냅니다.

이 승자 독식 패러다임에서 L1 게이트웨이 솔루션은 중앙 집중식 시퀀서 L2 분류와 가장 유사합니다. 개별적으로 합리적인 L1 제안자는 가장 높은 수익을 내는 게이트웨이를 선택할 것입니다. 이렇게 되면 전체 L1을 시퀀싱하는 단일 엔터티가 남게 되어 명확한 검열 및 활성 종속성이 생성됩니다. 가장 수익성이 높은 게이트웨이는 임의로 개인을 검열하거나, 예를 들어 유지 관리 중에 블록 생성을 중단할 수도 있습니다. 지배적인 게이트웨이가 가장 가까운 경쟁자보다 수익성이 높은 한, 사용자는 게이트웨이로 거래를 보내거나 상당히 나쁜 조건(예: 게이트웨이에 옵트인하지 않은 다음 제안자를 기다림)으로 시퀀싱됩니다.

독점 게이트웨이 방어(게이트웨이가 채택된다고 가정)

게이트웨이의 승자독식 특성으로 인한 부정적 결과를 제한하기 위해 적용할 수 있는 보호 장치가 있습니다. 그 중 일부를 아래에 나열했습니다.

1. 포함 목록: 포함 목록은 지배적인 게이트웨이의 검열 및 라이브니스에 영향을 미치는 힘을 크게 제한합니다. 그래도 TFE는 게이트웨이를 명시적으로 처벌하는 방법(다음 항목 참조, 공식 감독자를 통해)이나 게이트웨이 주문 흐름을 줄이는 방법으로만 시행할 수 있습니다. 지배적인 게이트웨이가 주어지면 주문 흐름을 줄이는 것은 다른 블록체인 생태계로 마이그레이션하는 것을 의미합니다.
2. 공식 감독자: 지배적인 게이트웨이가 등장하면, 현재 L1에 거래를 제출할 수 있는 대체 방법이 부족하기 때문에 사용자 모니터링만으로는 TFE 위반을 강제하기에 충분하지 않을 가능성이 큽니다. 게이트웨이를 블랙리스트에 올리거나 슬래시할 수 있는 공식 감독자는 허용 가능한 보호가 될 수 있습니다. 그러나 이 기사의 앞부분에서 언급했듯이, L1 시퀀싱을 관리하는 메커니즘으로 공식 감독자를 선택하는 방법은 명확하지 않습니다. 각자 고유한 슬래싱 기능을 갖춘 L1 감독자/계층화된 L1 감독자의 다양성은 이와 관련하여 흥미로운 연구 분야가 될 수 있습니다.
3. 증명자-제안자 분리 가속화: 직접적인 가드레일은 아니지만 증명자-제안자 분리는 게이트웨이가 의존하는 프로토콜 외부 게이트웨이 위임의 프로토콜 내 구현입니다. 모든 프로토콜 내 솔루션은 분산된 증명자 집합을 제안의 이익 극대화 특성에서 분리합니다. 이 미래의 모든 제안자 선거 메커니즘은 지배적인 제안자가 출현하는 것을 처리하기 위해 프로토콜 내 가드레일이 있어야 합니다.

결론적으로, L1 게이트웨이 솔루션은 단기적으로는 수용 가능한 것처럼 보일 수 있습니다. 그러나 독점 게이트웨이 시퀀싱 L1에 대한 보호 장치가 명확하지 않은 경우, 게이트웨이 사전 구성 솔루션은 상당한 주의를 기울여 채택해야 합니다.