6월 5일 Paradigm의 연구 책임자인 Dan Robinson과 연구 파트너인 Dave White는 광부 추출 가능 가치(MEV) 세금을 제안하는 연구 기사를 발표했습니다. 이 세금을 통해 모든 애플리케이션은 구성성을 유지하면서 MEV를 캡처할 수 있습니다. 이 메커니즘은 이제 OP Mainnet, Base, Blast는 물론 기타 OP Stack L2 플랫폼에서도 사용할 수 있습니다. 기사에서는 스마트 계약이 거래의 우선순위 수수료를 기준으로 일정 비율의 수수료를 부과함으로써 거래에서 MEV를 포착할 수 있다고 제안합니다.
이 기사는 또한 경쟁 순서 규칙을 엄격하게 준수하기 위해 블록 제안자에 의존하고 이더 L1에서 효과적으로 운영할 수 없는 가능성을 포함하여 MEV 세금의 한계를 지적합니다. 또한 이 기사에서는 인센티브 비호환성, 전체 블록 문제, 트랜잭션 복원, 사용자 의도 유출 등과 같은 MEV 세금의 일부 단점을 설계를 통해 완화하는 방법에 대해서도 논의합니다. BlockBeats는 다음과 같이 기사를 편집합니다.
소개하다
이 기사에서는 모든 애플리케이션이 자체 MEV를 캡처하는 데 사용할 수 있는 메커니즘인 MEV 세금을 소개합니다. 이 메커니즘은 이제 OP Mainnet, Base 및 Blast와 같은 OP Stack L2에서 사용할 수 있습니다. 온체인 블록 제안자는 우리가 경쟁 순서 라고 부르는 일련의 규칙을 따르기 때문입니다.
체인 중 하나에 MEV 세금을 부과하기 위해 스마트 계약은 거래 우선 수수료에 따라 수수료를 부과합니다. 애플리케이션이 검색자 우선 수수료 1달러당 99달러의 MEV 세금을 부과하는 경우 해당 거래에 대한 경쟁력 있는 MEV의 99%를 포착합니다.
MEV 과세는 광대한 설계 공간을 열어주는 간단한 기술입니다. 블록 제안자가 운영하는 단일 공유 경매에 연결하기만 하면 온체인 모든 애플리케이션이 자체 오프체인 인프라 없이 자체 맞춤형 MEV 경매를 실행할 수 있도록 허용하는 것으로 생각할 수 있습니다.
우리는 MEV 세금을 사용하여 MEV 연구의 세 가지 주요 질문을 해결하는 방법을 설명합니다.
탈중앙화 거래소(DEX) 라우터는 거래소가 받는 가격을 최적화합니다.
유동성 공급자가 경험하는 손실 및 재조정(LVR)을 최소화하는 자동 마켓메이커(AMM) (AMM)
사용자가 거래로 생성된 "백엔드 실행" MEV를 캡처할 수 있게 해주는 지갑
하지만 문제가 있습니다. MEV 세금은 블록 제안자가 거래를 검열, 스누핑 또는 지연시키지 않고 우선 순위 수수료로 거래를 순서 포함하는 경쟁 순서 규칙을 엄격하게 준수하는 경우에만 효과적입니다. 블록 제안자가 이러한 규칙을 벗어나면 MEV 세금을 회피하고 스스로 가치를 얻을 수 있습니다. 따라서 오늘날 MEV 세금은 신뢰할 수 있는 L2 순서 에 의존하며 블록 건설이 제안자의 소득을 극대화하는 경쟁 빌더 경매에 의해 지배 이더 이더 L1에서는 전혀 작동하지 않을 수 있습니다.
그럼에도 불구하고 MEV 과세의 강력함과 유연성은 현재 이 서비스를 제공할 수 있는 플랫폼에 순서 하는 것이 올바른 선택일 수 있음을 시사합니다. 경쟁적 순서 의 상대적 단순성은 단일 순서 신뢰하지 않고도 분산된 방식으로 이를 시행할 수 있는 실행 가능한 방법이 있을 수 있음을 시사합니다. 이 기사가 이 문제에 대한 추가 연구를 자극할 수 있기를 바랍니다.
순서
누군가 이더 L1 또는 L2에서 트랜잭션을 보낼 때 우선 순위 수수료를 할당하고 이를 블록 제안자에게 지불합니다. 이것이 ETH의 총 지불액인 builderPriorityFee를 얻기 위해 거래에 사용된 가스에 숫자를 곱한 PriorityFeePerGas(순서 수수료)로 지정된다고 상상할 수 있습니다.
이더 프로토콜에는 블록의 거래가 우선순위FeePerGas의 내림차순으로 순서 되어야 한다는 조항이 없습니다. 그러나 이는 블록을 구성하는 인기 있는 방법입니다. 예를 들어 OP 스택 체인의 순서 이자 geth 및 reth에서 사용하는 기본 알고리즘입니다. 순서 거래자 거래의 긴급성을 효과적으로 표현할 수 있을 뿐만 아니라 특정 유형의 MEV를 블록 제안자에게 자연스럽게 전달할 수 있습니다.
이는 순서 MEV 경쟁을 우선순위 가스 경매로 바꾸기 때문에 발생합니다. AMM을 통한 중앙화 거래소 와의 차익 거래와 같이 체인과의 상호 작용을 통해 이익을 얻을 수 있는 기회가 있을 때 검색자는 가장 먼저 그렇게 하기 위해 경쟁할 것입니다. 체인이 거래 포함 및 순서 결정하기 위해 순서 사용하는 경우 검색자는 거래에 대해 높은 우선순위 수수료를 설정하여 경쟁합니다.
제로 리스크 수익 경쟁이 있는 경쟁 시나리오에서 승리한 검색자는 궁극적으로 MEV 우선 수수료 전액을 지불해야 합니다. 따라서 계약과의 상호 작용을 통해 100 ETH의 이익이 가능하다면 해당 이익을 주장하는 첫 번째 거래에는 100 ETH의 우선 수수료가 설정됩니다. (제한 사항 섹션에서 몇 가지 주의 사항을 논의합니다.)
MEV 세금
스마트 계약이 상호 작용하는 모든 트랜잭션에서 MEV를 캡처하려고 한다고 가정해 보겠습니다. 스마트 계약이 자체 MEV를 포착하려고 시도할 수 있는 다양한 애플리케이션별 방법에 대한 대량 연구가 있습니다.
그러나 실제로 우리는 애플리케이션에 대해 반드시 알 필요는 없습니다. 블록이 경쟁적 순서 를 통해 구축되었다는 것을 알면 거래의 MEV 양, 즉 우선순위 수수료에 대한 보편적인 신호를 갖게 됩니다.
우리는 스마트 계약이 거래의 우선 수수료를 살펴보고 그에 대한 증분 기능으로 자체 수수료를 부과할 수 있다고 제안합니다. 예를 들어, 컨트랙트는 호출자가 ETH의 applicationPriorityFee = 99 * ProposerPriorityFee를 컨트랙트로 전송하도록 요구할 수 있습니다.
이 새로운 수수료는 거래를 보낸 검색자가 지불하므로 해당 검색자의 행동에 영향을 미칩니다. 기회에 100 MEV가 있는 경우 승리한 거래는 이제 1 ETH의 우선 순위 수수료만 설정합니다. 이로 인해 총 지불금은 100 ETH(블록 제안자에게 1 ETH, 스마트 계약에 99 ETH)가 됩니다. 우선 순위가 높은 수수료는 거래의 수익성을 떨어뜨립니다. 우선 순위가 낮은 수수료는 더 높은 수수료를 설정한 경쟁업체에게 기회를 잃게 됩니다. 이는 스마트 계약이 거래에서 MEV의 99%를 포착했음을 의미합니다.

우리는 스마트 계약에 의해 부과되는 이 추가 수수료를 MEV 세금이라고 부릅니다. MEV 세금을 사용하면 애플리케이션이 자체 이익을 위해 순서 탈취하여 MEV를 블록 제안자에게 유출하는 대신 사용자를 위해 다시 확보할 수 있습니다.
PriorityFeePerGas의 함수로 수수료가 충분히 빠르게 증가하는 경우 제안자는 무시할 수 있는 MEV만 얻게 됩니다. PriorityFeePerGas의 가격은 wei(1ETH의 10억분의 1)로 책정되므로 매우 정밀하게 처리해야 합니다. 예를 들어, MEV 세금이 50,000의 PriorityFeePerGas가 과도한 세금을 초래할 정도로 민감하다면 제안자에게 지불되는 총 금액은 $0.01 미만이 됩니다. (5)
그러나 중요한 경고가 있습니다. "제한 사항" 섹션에서 설명한 것처럼 MEV 세금은 블록 제안자가 특정 규칙("경쟁적 우선 순위"라고 함)을 따르고 자신의 수익을 극대화하기 위해 이러한 규칙을 벗어나지 않는 경우에만 적용됩니다. 신뢰할 수 없는 방식으로 이러한 규칙을 시행하는 것은 공개적인 질문입니다.
단일 애플리케이션 MEV 캡처
여기에서는 MEV 세금을 사용하여 경쟁 우선 순위를 사용하여 블록 구성을 보장하는 온체인 MEV에서 세 가지 중요한 문제를 완화할 수 있는 방법을 간략하게 설명합니다. DEX 인터페이스를 통해 교환기의 거래 실행을 개선하고 AMM이 LP에 대한 차익 거래 손실을 줄일 수 있도록 허용하며 사용자의 역주행권을 판매하여 사용자의 MEV 유출을 줄이기 위한 지갑입니다.
탈중앙화 거래소 라우터
UniswapX 및 1inch Fusion과 같은 의도 기반 DEX 라우팅 프로토콜에서 사용자(Alice)는 교환 의도에 서명하고 검색자는 최상의 가격으로 Alice를 위해 해당 의도를 라우팅하거나 채우기 위해 경쟁합니다.
UniswapX의 현재 버전은 두 가지 경쟁 메커니즘을 사용합니다. 하나는 검색자가 가격을 채울 때까지 Alice의 제한 가격이 변경되는 네덜란드 경매와 네덜란드 경매를 설정하는 초기 오프체인 견적 요청(RFQ) 경매입니다. 경매 시작 가격입니다.
경쟁적 순서 보장하는 플랫폼에서 UniswapX는 이러한 메커니즘을 MEV 세금이라는 단일 메커니즘으로 대체할 수 있습니다. 이는 누구나 즉시 체결할 수 있는 주문에 사용자가 서명할 수 있도록 함으로써 이루어지지만 체결 가격은 거래 우선순위에 따라 설정됩니다.
예를 들어, Alice가 1 ETH를 판매하기 위한 UniswapX 주문을 가지고 있는 경우 주문 실행 가격을 최소 가격 + ($0.01 * PriorityFeePerGas)로 정의할 수 있습니다. 최소 가격은 현재 가격보다 훨씬 낮을 것으로 예상되는 고정 값일 수 있습니다.
검색자는 거래를 제출하여 Alice의 주문을 채우기 위해 경쟁합니다. 주문은 어떤 거래가 가장 높은 우선 순위 수수료를 가지고 있는지에 관계없이 이행되며 복원되지 않습니다. 이는 교환자가 검색자가 찾을 수 있는 최상의 가격을 얻을 수 있도록 보장해야 합니다. (일부 예외 사항은 제한 사항 섹션에서 설명합니다.)
Alice의 최소 가격이 $3,000이고 ETH의 현재 가격이 $3,500인 경우 승리한 거래의 우선순위FeePerGas는 약 50,000입니다. (200,000 Gas 비용이 드는 거래에서 블록 제안자에게만 약 100억 Wei(약 $0.000035)가 지불된다는 점에 유의하세요.)
이는 UniswapX에서 사용되는 기존 메커니즘에 비해 몇 가지 잠재적인 이점이 있습니다.
MEV 세금을 사용하는 주문은 네덜란드 경매를 사용하는 주문보다 더 빠르고 더 나은 가격으로 체결될 수 있습니다. 이 기사에서 설명한 것처럼 온체인 더치 경매는 블록 간 가격 변동으로 인해 MEV에 일부 가치가 유출되며 완료하는 데 많은 블록이 필요할 수 있습니다. 대조적으로, MEV 세금을 사용하는 주문은 대부분의 MEV를 포착하면서 다음 블록에서 채워질 수 있습니다.
오프체인 RFQ와 달리 MEV 세금을 사용하는 주문에 대한 경매는 온체인 거래가 실행될 때 자동으로 발생합니다. 이는 낙찰자가 온체인 거래가 성공한 경우에만 주문을 이행할 것을 보장한다는 것을 의미합니다. 이를 통해 AMM과 같은 온체인 유동성이 오프체인 유동성과 더 쉽게 경쟁할 수 있습니다. 이는 UniswapX가 Uniswap v4와 같은 다중 풀 시스템을 위한 보다 효율적인 라우터 역할을 할 수 있음을 의미합니다.
AMM
일반적으로 AMM은 손실 및 재조정 문서에서 설명한 대로 블록 상단의 오래된 가격을 기반으로 거래하는 차익거래자에게 가치를 유출합니다. MEV 세금을 사용하여 AMM이 MEV를 포착하도록 할 수 있습니다. 단순화를 위해 중앙화된 유동성 없이 AMM에서 작동하는 방법을 논의하겠습니다. (유동성을 풀링하여 이러한 문제를 해결하는 방법에 관심이 있으시면 Sorella가 곧 솔루션을 출시할 것입니다.)
AMM은 거래 우선 수수료에 따라 추가 수수료를 부과함으로써 MEV를 포착할 수 있으며, 이를 통해 블록 내 거래에서 첫 번째 권리를 경매할 수 있습니다. 이 수수료를 계산하고 평가하는 방법에는 여러 가지가 있습니다. 우리는 풀 유동성 단위인 sqrt(xy)로 중립적인 것에 대해 논의할 것입니다. 승리하는 거래는 풀의 유동성을 가장 많이 증가시키는 거래가 될 것입니다.
블록의 풀에서 첫 번째 트랜잭션을 실행할 때 풀은 x_end * y_end > x_start * y_start 조건을 적용하는 대신 조건(일부 상수로)을 적용할 수 있습니다.
x_end * y_end > (sqrt(x_start * y_start) + a*priorityFeePerGas)^2
이 공식은 차익 거래자 실제 가격으로 거래하도록 장려하며, 해당 거래 후에는 풀의 중간 가격이 실제 가격이 되어야 합니다.
첫 번째 거래 이후에는 Uniswap v2와 마찬가지로 고정된 스왑 수수료로 거래를 진행할 수 있습니다. 추가 MEV 세금을 납부하지 않고 풀에서 거래하기를 원하는 정보가 없는 거래자에게는 더 낮은 우선순위 수수료가 설정됩니다.
AMM에 MEV 세금을 부과하는 방법에는 여러 가지가 있으며, 이는 다양한 영향을 미칠 수 있습니다. 예를 들어, MEV 세금은 스왑의 입력 또는 출력 토큰으로 표시될 수 있고, 풀에서 적용되는 스왑 수수료 비율에 영향을 미치거나, 사용자 거래에 대한 최소 가격을 결정할 수 있습니다. 우리는 이것이 탐구할 가치가 있는 흥미로운 디자인 공간이라고 생각합니다.
역행 경매
위 설명은 MEV 누출을 방지하기 위해 특정 애플리케이션을 설계하는 방법을 보여줍니다. 그러나 지갑이 MEV 세금이 포함되지 않은 거래라도 애플리케이션과 상호 작용하는 모든 거래에서 사용자가 생성한 MEV를 캡처하도록 돕고 싶다면 어떻게 해야 할까요?
예를 들어, Alice는 AMM에서 대규모 거래를 할 때 때때로 "백러너"가 가격을 인하할 수 있는 차익 거래 기회를 만듭니다. 이는 일반적으로 Alice가 아닌 MEV로 유출됩니다.
MEV-Share와 MEVBlocker는 사용자가 거래에서 MEV를 캡처할 수 있게 해주는 두 가지 프로토콜이지만 복잡한 오프체인 경매 시스템에 의존합니다. 주문 흐름 경매 디자인 공간에서는 몇 가지 다른 솔루션을 설명합니다.
의도 기반 스마트 계약 지갑과 결합된 MEV 세금을 통해 우리는 Alice를 위해 백그라운드에서 실행되는 MEV를 캡처하는 대체 시스템을 구축할 수 있습니다. Alice가 AMM에서 거래하기 위한 트랜잭션을 생성하지 않고 대신 누구든지 Alice의 스마트 계약 지갑에 제출하여 해당 작업을 수행하도록 할 수 있다는 의도에 서명한다고 가정합니다. Alice의 스마트 계약 지갑은 거래를 제출하는 모든 사람에게 MEV 세금을 부과하고, 세금은 Alice에게 지급됩니다.
Alice의 의도를 제출한 검색자는 동일한 거래 내에서 자동으로 그렇게 할 수 있으므로 그녀를 반대할 수 있는 독점적인 권리를 갖게 됩니다. 따라서 검색이 경쟁적이라면 Alice의 모든 이익은 MEV 세금을 통해 Alice에게 발생해야 합니다.
이 시스템은 선행 사용자의 거래와 관련된 공격으로부터 사용자를 반드시 보호하지는 않습니다. 선행 사용자의 거래로 인해 해당 사용자에게 MEV 세금을 지불하는 것을 피할 수 있기 때문입니다. 이 문제(및 일부 가능한 완화 방법)는 아래 제한 사항 섹션에서 자세히 설명합니다. 그럼에도 불구하고 이는 최소한 완화 없이 공통 메모리 풀을 사용하는 시스템에 비해 개선될 수 있습니다.
기타 사용 사례
이러한 예 외에도 MEV 세금의 다른 잠재적인 용도에는 현재 오프체인 또는 네덜란드 경매를 사용하는 거의 모든 것이 포함될 수 있습니다.
Oval과 같이 오라클 오라클 할 수 있는 가치를 클레임 프로토콜;
Blend와 같은 NFT 모기지 프로토콜에 대한 융자 경매;
대출 계약 청산의 누수 가치는 네덜란드 경매보다 낮습니다.
애플리케이션 간 MEV 캡처
위 솔루션은 단일 애플리케이션과 MEV 상호 작용을 캡처하도록 설계되었습니다. 그러나 때로는 검색자가 동일한 거래에서 여러 애플리케이션과 상호 작용하여 더 많은 가치를 얻을 수도 있습니다.
이러한 애플리케이션 중 하나만 MEV 세금이 있는 경우 거래의 모든 MEV는 MEV 세금이 얼마나 높거나 낮은지에 관계없이 MEV 세금이 있는 애플리케이션으로 이동해야 합니다.
하지만 검색자의 거래가 MEV 세금을 사용하는 두 개의 애플리케이션과 상호 작용하는 경우 어떻게 될까요? 예를 들어, MEV 과세 AMM에 대해 위의 MEV 과세 UniswapX 주문 중 하나를 작성해야만 캡처할 수 있는 일부 MEV가 있다면 어떻게 될까요?
이 경우 각 애플리케이션에서 포착한 초과 MEV의 상대적 금액은 해당 애플리케이션이 MEV 세금을 설정하는 방식에 따라 달라집니다. MEV 세금으로 징수된 app_i 값이 Tax_i(우선순위) 함수에 의해 제공되면 다음 우선순위 방정식을 풀어 승리한 거래의 우선순위를 결정할 수 있습니다.
세금_1(priorityPerGas) + 세금_2(priorityPerGas) = 총 MEV
(기술적으로, 블록 제안자에게 지불되는 우선권 수수료를 설명하기 위해 PriorityPerGas * gasUsed에 세 번째 항을 추가할 수 있지만 이를 무시하겠습니다. 일반적인 상황에서는 무시할 수 있습니다.)
MEV 세금이 PriorityPerGas와 선형적으로 관련되어 있는 간단한 경우(그래서 Tax_1(priorityPerGas) = a_1 * PriorityPerGas), 각 애플리케이션에서 받은 MEV 점유율 풀 수 있습니다.
a_1 *priorityPerGas + a_2 *priorityPerGas = MEV
우선순위PerGas = MEV/(a_1 + a_2)
Tax_1(priorityPerGas) = (a_1/(a_1+a_2))*MEV
Tax_2(priorityPerGas) = (a_2/(a_1+a_2))*MEV
애플리케이션은 자체 MEV 세금을 설정할 때 절충점에 직면합니다. 세금이 높을수록 애플리케이션 간 MEV 발생 시 더 큰 점유율 제공하지만, 클레임 할 수 있는 경쟁 방법이 있는 경우 일부 애플리케이션 간 MEV를 놓칠 수 있음을 의미합니다. 앱메브. 예를 들어, 모든 거래에 대해 MEV 세금을 부과하는 AMM이 하나 있다면 MEV 세금 UniswapX 주문은 다른 AMM 또는 오프체인 필러에 의해 채워질 가능성이 더 높을 수 있습니다.
대부분의 경우 두 애플리케이션이 각각의 이익을 최대화하는 방식으로 MEV를 공유하도록 MEV 세금을 설계하는 균형이 존재할 수 있습니다. 예를 들어, MEV 세금 AMM은 블록 상단 근처에 있는 단일 거래자 로부터 가치를 확보하고 싶지만 다른 거래자 및 애플리케이션(MEV 세금을 사용하는 애플리케이션 포함)에 더 낮은 고정 금리로 유동성을 제공하려고 할 수 있습니다. 비용. 이 경우 AMM은 상대적으로 낮은 MEV 세금(예: $0.00001 * PriorityFeePerGas)을 설정하여 차익 거래(있는 경우)가 블록 초기에 발생하고 블록의 후속 거래에 MEV 세금을 부과하지 않을 수 있습니다. AMM과 상호 작용하려는 UniswapX와 같은 애플리케이션은 더 높은 MEV 세금(예: $0.01 * PriorityFeePerGas)을 설정하여 풀이 이미 중재된 후에 거래가 포함되도록 할 수 있습니다. 이러한 상대적 세금을 감안할 때 UniswapX 주문에 $1 MEV와 $50,000 MEV만 있어도 AMM이 먼저 중재를 받게 됩니다.
우리는 이것이 미래 연구에 가치가 있는 광범위한 디자인 공간이라고 믿습니다.
한정
MEV 세금에는 몇 가지 복잡성과 단점이 있는데, 이는 향후 연구의 흥미로운 영역이라고 생각합니다.
인센티브 비호환성
MEV 세금은 독점 블록 제안자에게 인센티브와 호환되지 않습니다. 이는 거래 포함을 위한 공평한 경쟁의 순서 있는 경우에만 작동하며, 이는 블록 제안자가 자신의 수익을 극대화하는 대신 "경쟁적 우선순위" 규칙을 따르는 경우에만 해당됩니다. 제안된 규칙의 비공식 목록에는 다음이 포함되지만 이에 국한되지는 않습니다.
순서. 블록 내의 거래는 PriorityFeePerGas의 내림차순으로 정렬되어야 합니다.
검열에 저항하세요. 블록 제안자가 블록 중에 트랜잭션 t1을 수신하고 블록이 가득 차지 않았거나 t2.priorityFeePerGas < t1.priorityFeePerGas와 같은 일부 트랜잭션 t2를 포함하는 경우 블록에는 트랜잭션 t1이 포함되어야 합니다.
거래 전 개인 정보 보호. 블록 제안자는 프라이빗 엔드포인트를 통해 트랜잭션을 수락해야 하며 해당 트랜잭션을 블록에 제출하기 전에 다른 사람과 공유하거나 이러한 트랜잭션의 내용을 자신의 트랜잭션 구축을 위한 입력으로 사용할 수 없습니다.
최종 리뷰가 없습니다. 블록 제안자는 이 시간 이전에 명확한 블록 시간을 설정해야 하며, 이 시간 이후에는 누구의 거래 요청도 수락하지 않습니다.
이러한 속성 중 하나 이상을 위반하면 MEV 세금의 효율성이 저하될 수 있습니다. 검열을 위반하는 블록 제안자는 경쟁 거래를 제외하고 자신을 이용하는 우선순위가 없는 거래를 제출함으로써 대부분의 MEV 세금을 피할 수 있습니다. 거래 전 개인 정보 보호를 위반하는 블록 제안자는 다른 거래에서 MEV를 훔치거나 우선 순위 수수료를 확인하여 수수료를 얼마나 높게 설정해야 하는지 정확히 알 수 있으며, 다른 사람보다 늦게 거래를 제출할 수 있는 블록 제안자는 "마지막으로 Free"를 얻게 됩니다. 기회를 얻기 위해 다른 사람보다 더 높은 가격을 지불하려는지 여부는 둘 다 궁극적으로 경쟁을 방해하는 역선택 문제를 일으킬 수 있습니다.
불행하게도 첫 번째 속성은 프로토콜 계층에서 쉽게 적용되지만 다른 속성을 무신뢰 방식으로 적용하는 것은 공개된 문제입니다.
프로토콜 계층에서 적용되지 않는 경우 이러한 규칙을 준수하는 단일 시퀀서는 이러한 규칙에서 벗어나지 않도록 신뢰해야 하며, 제안자가 블록 구성을 경쟁력 있는 수익 극대화 경매(예: 이더 L1의 MEV-Boost)에 아웃소싱하는 경우 블록은 그들을 따르지 마십시오.
이러한 문제는 블록 구축을 위해 경쟁력 있는 우선 순서 사용하겠다고 약속 순서 신뢰할 수 있는 단일 순서 에 의해 "해결"될 수 있습니다. 또한 Sorella의 Angstrom, Flashbots의 SUAVE, 리더 없는 경매 또는 다중성과 같은 합의, 암호화 및/또는 신뢰할 수 있는 실행 환경의 조합을 사용하는 탈중앙화 메커니즘을 통해 문제를 해결할 수도 있습니다.
완전한 블록
블록이 완전히 가득 차면 MEV 세금의 정상적인 운영에 대한 예외가 발생합니다. 이 경우, 블록 제안자는 우선순위가 낮은 거래를 단순히 블록에 포함시키는 대신 포기해야 할 수도 있습니다. MEV 세금 애플리케이션과 상호작용하는 거래는 우선순위 수수료가 매우 낮을 수 있으므로 이러한 애플리케이션은 MEV 세금을 사용하지 않거나 MEV 세금이 매우 낮은 애플리케이션에 의해 밀려날 수 있습니다. 그러나 별도의 기본 수수료를 설정하기 위해 EIP-1559와 같은 메커니즘을 사용하는 체인에서는 블록이 완전히 채워지는 경우가 비교적 드뭅니다. 또한 블록이 가득 찼을 때 특정 거래를 지연해야 하는 경우 MEV 세금을 더 높게 설정하여 긴급성이 낮은 거래를 지연하는 것이 합리적인 결과일 수 있습니다.
복원된 거래
MEV 세금은 실제로 각 "입찰"이 거래인 단일 블록 경매에 의존합니다. 이러한 경매의 한 가지 단점은 실패한 입찰로 인해 복원된 거래가 온체인 에 포함되어 일부 기본 수수료를 지불하고 체인 정체를 초래하는 경우가 많다는 것입니다.
순서 실패한 트랜잭션을 완전히 제외할 수 있다면 이 문제를 완화할 수 있지만, 이는 중앙 집중식 순서 사용해도 달성하기 어려울 수 있습니다. (또한 위에서 언급한 검열 저항 속성을 엄격히 준수하지는 않지만 해당 정의는 조정될 수 있습니다.) 보다 정교한 시퀀서는 트랜잭션이 참여하고 있는 경쟁 경매를 지정하여 시퀀서가 충분한 정보를 얻을 수 있도록 함으로써 이 프로세스를 최적화할 수 있습니다. 실패할 것으로 알고 있는 후속 트랜잭션을 건너뛰는 것입니다.
사용자 의도 공개
MEV 세금은 검색자 간에 경쟁이 있는 경우에만 적용됩니다. 즉, 기회를 어느 정도 알아야 함을 의미합니다. 온체인 에서 기회를 볼 수 있는 AMM과 같은 애플리케이션의 경우 이는 자연스럽게 발생해야 합니다. 그러나 의도 기반 라우팅 또는 백그라운드 경매와 같은 애플리케이션의 경우 이는 애플리케이션이 사용자의 의도를 검색자와 공유해야 할 수도 있음을 의미합니다.
어떤 경우에는 사용자 의도가 실현되기 전에 전파되어 발생하는 일시적인 개인 정보 보호 손실로 인해 MEV 세금이 회복될 수 없는 방식으로 가치가 유출될 수 있습니다.
예를 들어, Alice가 위에서 설명한 백엔드 경매 프로토콜을 사용하여 유동성이 낮은 토큰을 구매하려고 한다고 가정해 보겠습니다. 그녀는 AMM에서 토큰을 구매하고 특정 미끄러짐 허용치를 설정하기 위해 스마트 계약 지갑의 서명된 의도를 게시했습니다. 검색자는 사용자의 주문을 이행하지 않고도 해당 토큰의 가격을 미끄러짐 허용 범위까지 끌어올리기 위해 우선순위가 높은 거래에서 경쟁할 수 있습니다. 그러면 승자 Bob은 우선순위가 낮은 거래에 이를 포함시키고 이를 역으로 실행함으로써 비경쟁적인 방식으로 Alice의 의도를 충족시킬 수 있습니다. 이로써 Alice의 거래를 샌드위치에 끼우고 MEV 세금을 피하는 동시에 앨리스에게 더 나쁜 가격을 제공할 수 있습니다. NFT를 구매할 때 비슷한 문제가 발생할 수 있습니다.
Bob은 토큰 구매와 Alice에게 판매 사이의 원자성을 보장할 수 없기 때문에 그러한 공격은 Bob에게 리스크 점에 유의해야 합니다. 순진한 Bob은 "클램핑 및 찢기" 함정에 빠질 수 있습니다. Alice는 먼저 자신에게서 가치 없는 토큰을 구매하겠다는 의도를 발표하고 Bob은 거래 측면을 공격하기 위해 토큰을 구매하지만 Bob이 측면 공격을 완료하기 전에 Alice는 자신의 의도를 철회합니다. .
또한 애플리케이션은 기존의 많은 주문 흐름 경매와 마찬가지로 의도를 공유하는 검색자 집합을 제한하고 그들의 행동을 모니터링하여 이를 완화할 수 있습니다.
MEV 세금을 SUAVE 디자인을 위해 Flashbots가 구상한 것과 같은 개인 정보 보호 빌더 기능과 결합하는 것도 가능합니다.
마지막으로, Alice가 의도를 공유하는 데 드는 비용이 경쟁 검색의 이점보다 크다고 판단하면 자신이 트랜잭션을 직접 구성하여 블록에 직접 제출할 수 있습니다. 위에서 언급한 바와 같이, 경쟁적 순서 의 이상적인 구현은 블록 제안자에게 거래 전 개인정보 보호를 제공하는 것입니다.
관련 토론
가스 우선 경매. "채굴자 클레임 가치"라는 용어를 만든 Flash Boys 2.0 논문은 탈중앙화 블록체인에서 우선 순서 의 역학 중 일부를 조사합니다. 논문에서는 이더 채굴자(네트워크가 작업 증명을 사용했을 때)가 이미 순서 우선순위를 정했으며 차익거래자는 첫 번째 구역에 포함될 권리를 입찰하는 "우선 가스 경매"에 참여하기 위해 이 행동에 의존했다고 명시합니다. 이로 인해 MEV의 대부분은 채굴자가 소유하는 탈중앙화 거래소 에 의해 차익화됩니다.
선착순입니다. Themis 또는 Arbitrum One의 현재 순서 (7)와 같은 트랜잭션 순서 규칙을 통해 MEV를 완화하려는 일부 시도는 다른 순서 규칙, 선착순(때때로 "공정한 순서"이라고도 함)을 시행하는 데 중점을 두고 있으며, 여기서 블록 제안자는 트랜잭션을 순서 해야 합니다. 보는 순서.
순서 다른 접근 방식을 취합니다. 지정된 시간 내에 도착하는 트랜잭션은 동일하게 처리되며 선언된 우선순위에 따라 순서.
여러 검증자가 있는 실제 네트워크 환경에서는 선착순을 적용하거나 정의하기가 어렵습니다. 신뢰할 수 있는 단일 순서 사용하더라도 낭비적인 대기 시간 경합 및 스팸이 발생할 수 있습니다. 마지막으로, MEV 세금은 자산 가격의 불연속적인 "점프"로 인한 차익 거래와 같이 순서 할 수 없는 특정 유형의 MEV를 제거할 수 있습니다. 선착순 주문에 비해 우선 순서 순서 의 잠재적 이점은 Budish, Cramton 및 Shim(2015)에서 논의된 연속 시간 교환에 비해 이산 시간의 이점과 부분적으로 관련되어 있습니다.
동시에 순서 기본적으로 MEV에 가치를 유출하는 것처럼 보이지만 이 게시물에서는 이를 다시 얻기 위해 애플리케이션을 설계하는 방법을 보여줍니다.
비용 공유. Blast는 이더 L2이며 거래에서 액세스되는 스마트 계약과 우선 순위 및 기본 수수료의 일부를 공유합니다.
MEV 세금은 유사한 것을 허용하지만(적어도 우선 순위가 지정된 수수료에 대해서는) 수수료 공유에 대한 특별한 지원 없이 경쟁 순서 사용하여 온체인 애플리케이션 계층에서 구현할 수 있습니다. 또한 애플리케이션이 우선 수수료의 맞춤형 기능으로 자체 세금을 정의할 수 있도록 하여 더 큰 유연성을 제공하고 잠재적으로 MEV 인식 애플리케이션의 구성성을 향상시킵니다.
무신뢰 솔루션. 이 기사에서는 무신뢰 방식으로 플랫폼을 시행하는 방법보다는 플랫폼이 경쟁 우선순위를 사용하는 순서 와 플랫폼을 활용하는 방법에 중점을 둡니다.
경쟁 순서 에 필요한 다른 각 속성은 이전에 중요하게 논의되었습니다. 예를 들어, Fox, Pai, Resnick(2023)에서 저자는 검열 저항이 없는 온체인 경매의 취약성을 논의하고 여러 동시 제안자를 사용하여 검열 저항 경매의 설계를 설명합니다. 그러나 구체적인 거래 순서를 제시하지는 않았습니다.
Flashbots의 SUAVE, Sorella의 Angstrom, Leaderless Auctions, Espresso 및 Offchain Labs의 탈중앙화 Timeboost, Péter Szilági의 강제 공개 거래 포함 등 신뢰가 최소화된 블록 구축 메커니즘 구축에 대한 다른 연구가 있습니다.
이 기사가 L2가 순서(OP 스택에서 기본적으로 지원) 사용을 고려하도록 장려하고 애플리케이션이 지원되는 경우 MEV 과세를 시도하도록 권장하기를 바랍니다. 또한 L1 및 L2에서 신뢰를 최소화하는 경쟁 순서 프로토콜에 대한 추가 연구에 영감을 주기를 바랍니다.



