Paradigm의 새 기사: MEV 과세 및 우선순위-웹3.0-php.cn

저자: Dan Robinson,Dave White

편집자: Joyce, BlockBeats

소개

이 기사에서는 MEV 세금을 소개합니다. 모든 애플리케이션이 자체 MEV를 캡처하는 데 사용할 수 있는 메커니즘입니다. 이 메커니즘은 이제 OP Mainnet, Base 및 Blast와 같은 OP Stack L2에서 사용할 수 있습니다. 이러한 체인의 블록 제안자는 우리가 경쟁 우선 순위라고 부르는 일련의 규칙을 따르기 때문입니다.

체인 중 하나에 MEV 세금을 부과하기 위해 스마트 계약은 거래 우선 수수료의 함수인 수수료를 부과합니다. 애플리케이션이 검색자 우선 수수료 1달러당 99달러의 MEV 세금을 부과하는 경우 해당 거래에 대한 경쟁력 있는 MEV의 99%를 포착합니다.

MEV 세금은 광대한 디자인 공간을 열어주는 간단한 기술입니다. 블록 제안자가 운영하는 단일 공유 경매에 연결하기만 하면 체인의 모든 애플리케이션이 자체 오프체인 인프라 없이 자체 맞춤형 MEV 경매를 실행할 수 있도록 허용하는 것으로 생각할 수 있습니다.

MEV 세금을 사용하여 MEV 연구의 세 가지 주요 문제를 해결하는 방법을 설명합니다.

가격 교환기 수신을 최적화하는 분산형 교환기(DEX) 라우터

Market Maker(AMM)에서 자동으로 수행합니다. , 유동성 공급자가 경험하는 손실 및 재조정(LVR)을 최소화합니다.

사용자가 거래로 인해 생성된 "백그라운드 실행" MEV를 캡처할 수 있는 지갑

하지만 한 가지 질문이 있습니다. MEV 세금은 블록 제안자가 거래를 검열, 스누핑 또는 지연하지 않고 우선 순위 수수료로 거래를 주문하는 것을 포함하는 경쟁 우선 순위 규칙을 엄격하게 준수하는 경우에만 적용됩니다. 블록 제안자가 이러한 규칙을 벗어나면 MEV 세금을 회피하고 스스로 가치를 얻을 수 있습니다. 따라서 오늘날 MEV 세금은 신뢰할 수 있는 L2 주문자에 의존하며 블록 건설이 제안자의 소득을 극대화하는 경쟁 빌더 경매에 의해 지배되는 Ethereum 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%를 포착했음을 의미합니다.

Paradigm 新文：MEV 税与优先排序

우리는 스마트 계약에 의해 부과되는 이 추가 수수료를 MEV 세금이라고 부릅니다. MEV 세금을 사용하면 애플리케이션이 자체 이익을 위해 우선순위를 탈취하여 MEV를 블록 제안자에게 유출하는 대신 사용자를 위해 다시 확보할 수 있습니다.

priorityFeePerGas의 기능으로 수수료가 충분히 빠르게 증가하면 제안자는 무시할 수 있는 MEV만 받게 됩니다. PriorityFeePerGas의 가격은 wei(10억분의 1 ETH) 단위로 책정되므로 매우 정밀하게 처리해야 합니다. 예를 들어, 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인 경우 승리한 거래의 PriorityFeePerGas는 약 50,000입니다. (200,000 Gas 비용이 드는 거래에서 블록 제안자에게 지급되는 금액은 최대 100억 wei(~$0.000035)에 불과합니다.)

UniswapX에서 사용되는 기존 메커니즘과 비교할 때 이는 몇 가지 잠재적인 이점이 있습니다.

MEV 세금을 사용한 주문은 Dutch Auction을 사용한 주문보다 더 빠르고 더 나은 가격에 체결될 수 있습니다. 이 기사에서 논의된 것처럼 온체인 더치 경매는 블록 간 가격 변동으로 인해 MEV에 일부 가치가 유출되며 완료하는 데 많은 블록이 필요할 수 있습니다. 대조적으로, MEV 세금을 사용하는 주문은 대부분의 MEV를 포착하면서 다음 블록에서 채워질 수 있습니다.

오프체인 RFQ와 달리 MEV 세금을 사용한 주문에 대한 경매는 온체인 거래가 실행될 때 자동으로 진행됩니다. 즉, 낙찰자는 온체인 거래가 성공한 경우에만 주문을 이행할 것을 약속합니다. 이를 통해 AMM과 같은 온체인 유동성이 오프체인 유동성과 더 쉽게 경쟁할 수 있습니다. 즉, UniswapX는 Uniswap v4와 같은 다중 풀 시스템을 위한 보다 효율적인 라우터 역할을 할 수 있습니다.

AMM

일반적으로 AMM은 손실 및 재조정 백서에서 설명한 대로 블록 상단의 오래된 가격을 기반으로 거래하는 차익거래자에게 가치를 유출합니다. MEV 세금을 사용하여 AMM이 MEV를 포착하도록 할 수 있습니다. 단순화를 위해 중앙화된 유동성 없이 AMM에서 작동하는 방법을 논의하겠습니다. (유동성을 풀링하여 이러한 문제를 해결하는 방법에 관심이 있으시면 Sorella가 곧 솔루션을 출시할 예정입니다.)

AMM은 거래 우선 순위 수수료에 따라 추가 수수료를 부과하여 MEV를 캡처할 수 있으며, 이를 통해 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 세금은 스왑의 입력 또는 출력 토큰으로 표시될 수 있고, 풀에서 적용되는 스왑 수수료 비율에 영향을 미치거나, 사용자 거래에 대한 최소 가격을 결정할 수 있습니다. 우리는 이것이 탐구할 가치가 있는 흥미로운 디자인 공간이라고 생각합니다.

Retrograde Auction

위의 설명은 MEV 누출을 방지하기 위해 특정 애플리케이션을 설계할 수 있는 방법을 보여줍니다. 그러나 지갑이 MEV 세금이 포함되지 않은 거래라도 애플리케이션과 상호 작용하는 모든 거래에서 사용자가 생성한 MEV를 캡처하도록 돕고 싶다면 어떻게 해야 할까요?

예를 들어, Alice는 AMM에서 대규모 거래를 할 때 때때로 "백러너"가 가격을 인출할 수 있는 차익 거래 기회를 만듭니다. 이는 일반적으로 Alice가 아닌 MEV로 유출됩니다.

MEV-Share와 MEVBlocker는 사용자가 거래에서 MEV를 캡처할 수 있게 해주는 두 가지 프로토콜이지만 복잡한 오프체인 경매 시스템에 의존합니다. 주문 흐름 경매 디자인 공간에서는 몇 가지 다른 솔루션을 설명합니다.

MEV 세금을 의도 기반 스마트 계약 지갑과 결합하면 Alice를 위해 백그라운드에서 실행되는 MEV를 캡처하는 대체 시스템을 구축할 수 있습니다. Alice가 AMM에서 거래하기 위한 트랜잭션을 생성하지 않고 대신 누구든지 Alice의 스마트 계약 지갑에 제출하여 해당 작업을 수행하도록 할 수 있다는 의도에 서명한다고 가정합니다. Alice의 스마트 계약 지갑은 거래를 제출하는 모든 사람에게 MEV 세금을 부과하고 해당 세금은 Alice에게 지급됩니다.

Alice의 의도를 제출한 검색자는 동일한 거래 내에서 자동으로 Alice의 실행을 취소할 수 있는 독점 권한을 갖습니다. 따라서 검색이 경쟁적이라면 Alice의 모든 이익은 MEV 세금을 통해 Alice에게 발생해야 합니다.

선행 사용자의 거래로 인해 해당 사용자에게 MEV 세금을 지불하는 것을 피할 수 있으므로 이 시스템이 반드시 선행 사용자의 거래와 관련된 공격으로부터 사용자를 보호하는 것은 아닙니다. 이 문제(및 일부 가능한 완화 방법)는 아래 제한 사항 섹션에서 자세히 설명합니다. 그럼에도 불구하고 이는 최소한 완화 없이 공통 메모리 풀을 사용하는 시스템에 비해 개선될 수 있습니다.

기타 사용 사례

이러한 예 외에도 MEV 세금의 다른 잠재적인 사용에는 현재 오프체인 또는 네덜란드 경매를 사용하는 거의 모든 것이 포함될 수 있습니다.

Blend와 같은 NFT 모기지 프로토콜에 대한 재융자 경매

네덜란드 경매보다 누출 가치가 낮은 대출 프로토콜 MEV 캡처;

위 솔루션은 단일 애플리케이션으로 MEV 상호 작용을 캡처하도록 설계되었습니다. 그러나 때로는 검색자가 동일한 거래에서 여러 애플리케이션과 상호 작용하여 더 많은 가치를 얻을 수도 있습니다.

이 애플리케이션 중 하나만 MEV 세금이 있는 경우 거래의 모든 MEV는 MEV 세금이 높거나 낮더라도 MEV 세금이 있는 애플리케이션으로 이동해야 합니다.

하지만 검색자의 거래가 MEV 세금을 사용하는 두 개의 애플리케이션과 상호 작용하면 어떻게 될까요? 예를 들어, MEV 세금 납부 AMM에 대해 위의 MEV 세금 납부 UniswapX 주문 중 하나를 작성해야만 캡처할 수 있는 일부 MEV가 있는 경우 어떻게 될까요?

이 경우 각 애플리케이션에서 포착한 초과 MEV의 상대적 금액은 해당 애플리케이션이 MEV 세금을 설정하는 방식에 따라 달라집니다. MEV 세금으로 징수된 app_i 값이 Tax_i(우선순위) 함수에 의해 제공되면 다음 방정식으로 우선순위를 풀어서 승리한 거래의 우선순위를 결정할 수 있습니다.

tax_1(priorityPerGas) + Tax_2(priorityPerGas) = 총 MEV

(기술적으로는 PriorityPerGas * gas에 세 번째 항목을 추가할 수 있습니다. 블록 제안자에게 지불되는 우선 순위 수수료를 설명하는 데 사용되지만 이를 무시합니다. 일반적인 상황에서는 아마도 작동할 것입니다. 무시됨)

In MEV 세금이 PriorityPerGas와 선형적으로 관련된 간단한 경우(그래서 Tax_1(priorityPerGas) = a_1 * PriorityPerGas), 각 애플리케이션에서 받은 MEV 공유에 대해 풀 수 있습니다:

a_1 * PriorityPerGas + a_2 * PriorityPerGas = MEV
PriorityPerGas = 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'Finally를 얻습니다. 다른 것보다 더 높은 가격으로 기회를 얻으려는 경우 둘 다 궁극적으로 경쟁을 방해하는 역선택 문제를 일으킬 수 있습니다.

안타깝게도 첫 번째 속성은 계약 레이어 적용에서 쉽게 사용할 수 있지만 다른 속성을 적용합니다. 무신뢰 방식은 공개 질문입니다

프로토콜 계층에서 적용되지 않는 경우 이러한 규칙을 준수하는 단일 시퀀서는 이러한 규칙에서 벗어나지 않도록 신뢰할 수 있어야 합니다. 그리고 제안자가 블록 구성을 경쟁 업체에 아웃소싱하는 경우. 수익을 극대화하는 경매(예: Ethereum 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를 구매할 때 비슷한 문제가 발생할 수 있습니다.

토큰 구매와 Alice에게 판매 사이의 원자성을 보장할 수 없기 때문에 Bob에게는 이러한 공격이 위험하다는 점에 유의해야 합니다. 순진한 Bob은 "클램핑 및 찢기" 함정에 빠질 수 있습니다. Alice는 먼저 자신에게서 가치 없는 토큰을 구매하겠다는 의도를 발표하고 Bob은 거래를 측면에서 공격하기 위해 토큰을 구매하지만 Bob이 측면 공격을 완료하기 전에 Alice는 자신의 의도를 철회합니다. .

앱은 기존의 많은 주문 흐름 경매와 마찬가지로 의도를 공유하는 검색자 집합을 제한하고 그들의 행동을 모니터링하여 이를 완화할 수도 있습니다.

플래시봇이 SUAVE 디자인을 위해 구상한 것과 같은 개인 정보 보호 빌더 기능과 MEV 세금을 결합하는 것도 가능합니다.

마지막으로 Alice가 의도를 공유하는 데 드는 비용이 경쟁 검색의 이점보다 크다고 결정하면 거래를 직접 구성하여 블록에 직접 제출할 수 있습니다. 위에서 언급한 바와 같이 경쟁적 우선순위 지정의 이상적인 구현은 블록 제안자에게 거래 전 개인정보 보호를 제공하는 것입니다.