MEV의 향후 5년: MEV 분야의 최신 동향 이해

Foresight News
本文约4868字,阅读全文需要约19分钟
MEV는 도둑질도 아니고 패배해야 할 적이 아닙니다. 그것은 우리 관행의 필수적인 부분입니다.

편집 원본: aididiaojp.eth, Foresight News

편집 원본: aididiaojp.eth, Foresight News

최근에 "라는 글을 썼습니다.Penumbra일괄 경매 및 임계값 암호화 거래로 인해 SBP 시장 구조가 형성되지 않습니다. 또한 Osmosis 팀은 MEV 대책 메커니즘에 대해 많은 연구 시간을 보냈지만 적어도 일시적으로 성숙한 MEV 공급망을 형성할 수 없는 이러한 체인에서 MEV 시장 구조가 어떤 모습일지 명확하지 않습니다.

소스 링크

소스 링크

논란 재조명

우리는 MEV가 도덕적으로 또는 법적으로 절도인지에 대해 훌륭한 논쟁을 벌였습니다. 강세장에서는 다들 MEV 매수에 여념이 없었고, 많은 것들이 시장의 열기에 가려졌습니다. 현재 온체인 금융 활동은 완화되었으며 MEV 인수에 대한 "도덕적 보상"을 기대합니다. 또한 Twitter에서 일부 오래된 에피소드를 재방송하고 누가 MEV를 받을 자격이 있는지에 대한 팬들 사이의 열띤 토론이 있을 것입니다. 그러나 검색자는 신경쓰지 않을 것이며 MEV 획득은 계속될 것입니다.

MEV 인식 하드포크

MEV 수수료 시장은 일차 가격 경매로 이동합니다. 핵심 개발자는 프로토콜 설계 측면에서 MEV를 고려했습니다. 여러 생태계와의 상호 작용에서 핵심 개발자는 두 진영에 기대는 경향이 있습니다.

핵심 개발자의 첫 번째 진영은 MEV 획득 비용을 증가시키는 메커니즘을 설계했습니다. 일괄 경매, 임계값 암호화, 사전 합의 등으로 보입니다. 그들은 이러한 메커니즘이 MEV 추출 비용을 더 비싸게 만들기를 희망합니다. 추출이 잠재적인 처벌에 직면하여 유효성 검사기와 공모가 필요한 경우 전혀 불가능할 수 있습니다. 그러나 이러한 메커니즘은 사용자 상호 작용 및 프로토콜 인센티브의 비용과 복잡성을 증가시킵니다. 현재 특정 메커니즘 설계는 아직 광범위한 합의에 도달하지 못했습니다.

또 다른 프로토콜 개발자 그룹은 가치 회피를 최소화하고 MEV가 프로토콜 자체에 미치는 영향을 완화하며 참가자의 공정한 분배를 보장하는 데 중점을 두고 우아한 메커니즘을 공식화하고 보다 문명화된 블록체인을 구축하는 접근 방식을 취했습니다. 즉, 다음 세 가지 질문입니다. 첫째, MEV가 프로토콜 사용자에게 미치는 영향을 최소화하는 방법은 무엇입니까? 둘째, MEV가 프로토콜 자체에 미치는 영향을 완화하는 방법은 무엇입니까? 셋째, 프로토콜이 MEV를 공정하게 분배하도록 어떻게 보장합니까?

소스 링크

소스 링크

EIP-1559와 같은 복잡한 메커니즘은 널리 사용하기 어렵고 실제로 적합한 솔루션이 아닙니다. 나는 개발자들이 제안자 수수료를 줄이는 것을 목표로 EIP-1559의 발자취를 따를 것이라고 생각합니다. MEV에 대한 그림자 수수료 시장은 제안자와 MEV 빌더에게 이익을 주지만 다른 모든 사용자에게는 해를 끼칩니다. EIP-1559 이전의 수수료와 마찬가지로 MEV 블록 생산 및 포함 역학은 근본적으로 불공평한 시장을 만듭니다. 이를 위해 건축자와 제안자 간의 관계 개선을 특별히 목표로 하는 1559와 같은 메커니즘을 보기를 바랍니다.

제안자든 쓸모없는 투기꾼이든 소득이 억제되어야 하는 미래에 대한 나의 예측은 매우 간단합니다. 향후 5년 안에 우리는 서로 다른 생태계에서 여러 하드 포크를 보게 될 것입니다. 이 하드 포크는 분명히 특정 체인에 대한 MEV 시장을 목표로 합니다. 그들은 MEV에 대한 비용 또는 MEV 이익의 몫을 추출할 수 있습니다. 이상적으로는 MEV 공급망과 L1의 긴밀한 통합을 보게 될 것입니다.

수직 통합

제안자, 구축자, 검색자 간의 수직적 통합에 대해 시장에서 많은 논쟁이 있었습니다. 기본 아이디어는 제안자가 빌더 수익을 위해 내부 빌더를 유지하거나 빌더가 특정 검색자를 우선시할 수 있다는 것입니다. 수직 통합은 소규모 기업을 압박하고 소수의 주요 건설업체가 지배하는 시장으로 이어질 수 있습니다.

두려움이 좀 지나친 것 같아요. 프로토콜은 제안자를 무작위로 선택하며 검색 및 구축 시장은 경쟁이 치열합니다. (시장의 모든 힘을 가진) 제안자 간의 수평적 협력이 더 걱정스러워 보인다. 제안자 간의 가격 고정 합의는 스테이커 활성화 소프트 포크를 통해 시행될 수 있습니다. 프로토콜은 유해한 PBS 시장이 사용자 경험에 영향을 미치지 않도록 방지하기 위해 제안자 신뢰 차단자가 되어야 할 수 있습니다. 더 나쁜 것은 공모 제안자가 인접한 슬롯을 가지고 있는 한 MEV의 여러 블록이 철회될 수 있다는 사실입니다. 이는 블록체인 최종화에 불안정한 영향을 미칠 수 있습니다.

수직계열화는 분명 특수한 경우에 일어날 것이다. 번들 간의 상호 작용에 의해 일정량의 MEV가 생성됩니다. 빌더는 이 교차 번들 MEV에 액세스할 수 있으며 내부 전용 검색기를 통합할 수 있습니다. 검색자, 건축자 및 제안자 사이에 경제적으로 실행 가능한 보다 긴밀하고 신뢰할 수 있는 관계를 만드는 다른 특별한 상황이 있을 수 있습니다.

MEV 인식 애플리케이션 설계

이미 일어나고 있기 때문에 부정 행위와 같습니다. 예를 들어CowSwap팀은 이미 MEV 인식 애플리케이션을 출시하고 있습니다. 절충이 필요하므로 MEV 최소화는 한동안 논의의 중심이 될 것입니다. 여기서 연구는 하나의 핵심 질문에 의해 추진됩니다. MEV를 제거하기 위해 무엇을 포기해야 합니까?

합의의 디자인 공간은 매우 제한적이지만 실제로는 합의 합의에 도달하기 어렵습니다. 그러나 애플리케이션에는 MEV 최소화를 달성하기 위한 많은 옵션이 있습니다. 작동하는 것은 애플리케이션에 따라 다르며 대출 프로토콜에는 작동하지 않는 DEX 최소화 메커니즘(예: 일괄 처리)이 표시됩니다. 새로운 연구는 각 dApp 분야에서 약간의 변화를 가져올 것입니다. 그러나 새로운 MEV 최소화 모델은 기존 애플리케이션의 모멘텀과 싸워야 합니다. 어떤 dApp이 MEV 저항 디자인의 사용자 채택을 광범위하게 보게 될지, 어떤 dApp이 현재 수준의 MEV 세대를 수용할지는 불확실합니다.

그러나 우리는 MEV를 최소화하기 위한 프로토콜 설계에 그치지 않을 것입니다. 대신 MEV는 애플리케이션 설계의 도구가 될 것이며 애플리케이션 설계자는 MEV를 생성하는 시기와 방법을 선택할 것입니다. 우리는 MEV가 허용되는 시기를 결정하기 위한 고유한 프레임워크와 시스템에서 생성되는 MEV의 양을 조정하기 위한 일련의 표준 기술을 제안할 것입니다.

명시적 MEV

MEV 인식 응용 프로그램 설계의 결과는 MEV를 선택하고 도구로 사용하는 것입니다. 놀랍게도 MEV 공급망은 정상적인 거래에 접근할 수 없고 MEV 거래가 절대 복원되지 않으며 빌더가 수익성 없는 체인에서 블록 공간을 낭비하지 않는다는 보장을 제공합니다. MEV 트랜잭션이 더 빨리 확인되고 Seeker는 해당 MEV를 섀도우 수수료로 변환하여 트랜잭션에 더 높은 우선 순위를 부여합니다. 응용 프로그램은 의도적으로 MEV를 사용하여 "명시적 MEV"라고 부르는 이러한 기능에 액세스하기 시작합니다.

명시적 MEV는 애플리케이션에 특정 초능력을 부여할 수 있습니다. 이를 통해 사용자는 EIP-1559 팁을 거부하고 거래를 신속하게 확인할 수 있습니다. 응용 프로그램은 의도적으로 MEV 기회를 잠금 해제하고 중요한 시스템 작업에 연결할 수 있습니다. 예를 들어 오라클 업데이트에 0.1 ETH MEV를 추가할 수 있습니다. 이 MEV 기회는 찾는 사람들 사이에 경쟁을 일으키고 거래를 확인하는 첫 번째 찾는 사람이 해당 MEV를 얻습니다. PBS MEV 이전에는 우선 가스 경매가 발생하여 Seeker에 참여하는 데 비용이 많이 들 수 있습니다. 그러나 최신 MEV 공급망은 이 경주에서 패배하는 비용을 없애고 검색자는 트랜잭션 복원이 빌더에 의해 삭제된다는 것을 알고 있습니다.

MEV 인식 설계의 논리적 결론은 MEV 포함 설계입니다. 애플리케이션은 명시적으로 MEV를 생성하고, MEV를 설계에 통합하고, 이를 사용하여 블록스페이스 시장에서 특권 위치를 구매합니다. 명시적 MEV 트랜잭션은 가치가 높은 사용 사례에 대한 표준 트랜잭션을 효과적으로 대체합니다.

MevWeth

명시적 MEV에는 두 가지가 필요합니다.

첫째, 표준을 만들어야 합니다. 값비싼 가스를 피하기 위해 모든 명시적 MEV는 이를 생성한 계약에 관계없이 동일한 온체인 상태를 사용해야 합니다. 이를 통해 MEV는 복잡성을 크게 증가시키지 않고 많은 트랜잭션에서 연결을 설정할 수 있습니다. 찾는 사람은 애플리케이션이 명시적 MEV를 생성하는지 쉽게 알 수 있는 방법이 필요합니다. 찾는 사람은 구체적이고 예측 가능한 상태 변화를 찾을 수 있어야 합니다. 명시적 MEV를 감지하기 위해 많은 계약을 스캔할 필요가 없습니다. 각 계약이 자체 명시적 MEV를 관리하는 경우 검색자는 상태 조회 및 변경을 많이 수행하지 않고는 이를 얻을 수 없습니다. 단일 특정 계약은 명시적 MEV를 관리할 수 있어야 합니다.

둘째, 별도의 회계 시스템, 명시적으로 MEV는 ETH로 표시되어야 합니다. Seeker는 가스 가격 위험을 감수하기 때문에 지불은 가스 자산에 있어야 하며 모든 것을 엄청나게 단순화합니다. 그러나 이는 명시적 MEV를 생성하는 계약에 새로운 요구 사항을 부여합니다. 계약은 MEV에 얼마나 많은 ETH를 사용할 수 있는지 추적해야 합니다. DEX가 실수로 사용자 ETH를 명시적 MEV에 사용하는 것은 재앙이 될 것입니다. 따라서 명시적인 MEV 및 ETH를 사용하는 계약은 MEV 가능 ETH와 MEV 불가능 ETH의 균형을 유지해야 합니다.

따라서 MEV 생성을 위한 기준과 MEV에 대한 회계 시스템이 필요합니다. 매우 명확하고 명백하며 직관적인 솔루션은 이러한 요구 사항을 결합하고 MEV 가능 ETH에 대한 사용자 잔액을 추적하는 시스템을 쉽게 구축할 수 있습니다. 우리는 ETH를 수락하고 사용자를 위해 보유하는 계약을 구축하는 방법을 정확히 알고 있으며 명시적인 MEV 기능을 추적하고 관리하는 것은 매우 쉽습니다.

"MEV Wrapped ETH" 또는 MevWeth라고 부를 수 있습니다.

코드는 명시적인 MEV 관리 인터페이스가 있는 WETH 10의 확장처럼 보일 수 있습니다.github에, 그리고 아마도이미 메인넷에 배포우수한.

MevWeth는 다음에 대한 표준을 제공하는 ERC 20입니다.

  • addMev() 함수 시리즈를 통해 MEV 생성

  • getMev() 계열을 통해 MEV 검색

  • Mevitize.sol 기본 계약을 통해 명시적 MEV 생성을 계약에 추가

음의 MEV

명시적 MEV는 이를 생성한 트랜잭션에서 분리할 수 없습니다. 명시적 MEV는 트랜잭션에 암시적 MEV를 추가합니다. 그들은 함께 더 빠른 확인(및 최신 MEV 공급망의 다른 모든 이점)에 보조금을 지급하는 데 사용됩니다. 그러나 특정 거래 범주에는 이미 많은 MEV가 있습니다. 청산, DEX 거래 등은 명시적인 가치 생성 없이 우선 확인을 받기에 충분한 MEV를 이미 생성합니다. 인구에 명시적인 MEV를 추가하면 MEV 공급망에 대한 액세스 비용이 초과됩니다.

어쨌든 이러한 거래 비용은 엄청나게 높습니다. Uniswap 사용자는 앉아서 거래에 대한 MEV 생성 범위를 계산하지 않으며 "수수료 우선 시장 청산 MEV" 개념과 비교하지 않습니다. 아무도 아직 MEV를 우선 수수료로 취급하지 않으며, 설령 그렇게 하더라도 그 가치를 회복할 효율적인 방법이 없습니다. 마이너스 MEV는 모든 것을 바꿀 수 있습니다.

음수 MEV는 0 미만의 명시적 MEV입니다. MEV가 음수인 온체인 작업은 MevWeth를 통해 MEV를 지불해야 합니다. 사전 결제 없이 작업을 완료할 수 없습니다. MEV 공급망의 기존 권력 관계를 이해하는 것이 중요합니다. 사용자와 애플리케이션은 추출된 가치를 생성하지만 아직 추출 공급망에 참여하지는 않습니다. 제안자는 다른 공급망 참여자에게 임대료를 청구합니다. 마이너스 MEV는 제안자가 궁극적으로 이 프로세스를 제어할 수 없으며 제안자는 사용자 및 애플리케이션이 생성한 가치에 의존한다는 점을 인정합니다.

음의 MEV를 지정하면 사용자 또는 프로토콜이 중요한 작업으로 생성된 MEV를 다시 캡처할 수 있습니다. 제안자로부터 MEV를 가져와 해당 가치를 만든 사람에게 돌려줄 수 있습니다. 네거티브 MEV는 MEV 공급망에서 작동하는 간단하고 직접적인 방법을 제공합니다. 음수 MEV를 사용하면 사용자는 대상이 아닌 가치 추출 프로세스의 참여자가 됩니다.

예를 들어 Uniswap 사용자는 거래에서 슬리피지 마진을 줄임으로써 MEV로부터 보호할 수 있습니다. 그러나 이것은 종종 거래를 악화시키거나 성사 가능성을 낮춥니다. 네거티브 MEV는 트랜잭션 자체를 변경하지 않고 트랜잭션 결과를 개선할 수 있는 대역 외 방법을 제공합니다. 슬리피지 범위를 좁히는 대신 사용자는 거래에 소량의 마이너스 MEV를 첨부할 수 있습니다. 이는 검색자와의 상호 작용을 통해 수수료 리베이트를 효과적으로 제공합니다. 사용자는 더 나은 결과를 얻습니다. 트랜잭션 자체는 영향을 받지 않습니다. 사용자에 대한 트랜잭션 및 지불의 원자적 결합을 통해 사용자는 궁극적으로 사용자가 생성한 가치를 명시적으로 공유할 수 있습니다.

네거티브 MEV는 프로토콜이 청산과 같은 높은 MEV 프로세스에 대한 액세스를 제어하는 ​​방식을 변경하고 사용자가 DEX 거래와 같은 높은 MEV 작업을 수행하는 방식을 변경합니다.

MevWallet

MevWallet사용자가 거래에 명시적인 MEV를 첨부할 수 있는 스마트 계약 지갑입니다. 매우 표준적인 EIP-712 메타 거래 표준을 따르며 사용자가 팁을 줄 거래를 지정할 수 있습니다. 트랜잭션이 서명되면 누구나 브로드캐스트할 수 있습니다. MevWallet은 트랜잭션 세부 정보를 확인하고 트랜잭션을 실행하기 전에 몇 가지 기본 조건을 적용합니다. 모든 스마트 계약 지갑과 마찬가지로 트랜잭션은 EOA가 아닌 지갑에서 실행됩니다. msg.sender는 지갑이고 tx.origin은 검색자입니다.

트랜잭션이 실행된 후 MevWallet은 Gas 사용량을 계산하고 팁을 추가하며 결과가 긍정적이면 MevWeth에서 Seeker에게 보상합니다. 결과가 음수이면 MevWeth에서 저장된 일부 MEV를 검색합니다. 마이너스 거래 수수료를 지불할 수 있으며 거래가 실행을 완전히 상쇄하기에 충분한 MEV를 생성하는 경우 사용자는 지불을 받습니다. 자신이 생산한 MEV에 대한 보상을 요구함으로써 사용자는 MEV 공급망을 통해 블록 제안자에게 포기했을 가치를 되찾을 수 있습니다.

MevWallet 트랜잭션은 타임록 및 기한은 물론 논스 기반 중복 지불 보호를 지원합니다. 이 조합을 사용하면 시간에 따라 복잡한 요금 조정이 가능합니다. 예를 들어 트랜잭션은 확인될 때까지 시간이 지남에 따라 더 명시적인 MEV를 생성할 수 있습니다. 이렇게 하면 검색자 사이에 네덜란드 경매가 생성되어 거래가 시장에서 가장 낮은 가격으로 확인되도록 합니다. 다른 많은 흥미로운 수수료 에스컬레이터 모델을 온체인 오버헤드 없이 구현할 수 있습니다. 수수료 경매는 Seeker와 롤백 트랜잭션 확인 사이에서 발생하기 때문에 Gas Auction이 아무리 복잡하더라도 사용자나 Seeker 모두 추가 가스 비용을 발생시키지 않습니다.

그리고TypeScript그리고Rust에 코드베이스가 있습니다.최소 에이전트 공장새로운 MevWallet을 배포합니다. 이 코드는 라이선스가 부여되었으며 GitHub에서 사용할 수 있습니다. MevWallet이 지금 놓치고 있는 가장 중요한 것은 검색자가 트랜잭션을 볼 수 있는 방법입니다. 이 작업을 수행하는 가장 좋은 방법을 계속 찾고 있습니다. 간단한 CRUD API와 전용 메모리 풀을 고려했지만 장기적으로 실행 가능한 솔루션인지 확신할 수 없습니다.

MEV의 향후 5년

MEV의 다음 5년은 첫 해만큼 훌륭할 것이라고 기대하고 희망합니다. MEV 연구가 청소년기에서 시작되어 성숙기에 진입함에 따라 애플리케이션 설계에 이를 환영해야 합니다. 우리는 그것의 강점을 찾고 그것이 우리의 애플리케이션과 프로토콜에 기여하도록 해야 합니다. MEV는 도둑질도 아니고 패배해야 할 적이 아닙니다. 그것은 우리 관행의 필수적인 부분입니다.

원본 링크

원본 링크