거래 = 수행 방법을 지정합니다. 의도 = 원하는 것을 지정하지만 달성 방법은 신경 쓰지 않습니다.
원제: " 계정 추상화 및 SUAVE: 의도 중심 이더리움에서 우리는 얼마나 멀리 떨어져 있습니까? "
작성자: StanleyH, MetaWebVentures 연구원
편집자: Yvonne
"의도"는 최근 이더리움 매니아들 사이에서 핵심 논의 주제가 되었으며, 계정 추상화, SUAVE, 주문 흐름 경매 등과 같은 관련 콘텐츠도 시리즈로 연결되었습니다. 이번 글에서는 "트랜잭션 기반 스왑"에서 "인텐트 기반 스왑"으로의 전환을 어떻게 완료하는지, 그리고 그 과정에서 어떤 예상치 못한 결과가 발생하여 MEV의 형태를 완전히 바꿀 수 있는지에 대해 설명합니다.
의지
Anoma를 언급하지 않고 "의도"에 대해 이야기하는 것은 불가능합니다. 그들은 처음부터 의도 중심의 블록체인 아키텍처를 구축하기 시작했습니다. 그렇다면 의도란 무엇입니까? 고맙게도 이 기사는 Paradigm을 기반으로 하므로 Paradigm의 정의를 빌릴 수 있습니다.
"인텐트는 사용자가 거래 상대방에 대한 모든 통제권을 포기하면서 거래 생성을 제3자에게 아웃소싱할 수 있도록 하는 서명된 선언적 제약 조건의 집합입니다."
실제 사례를 살펴보겠습니다. Alice는 Ethereum에 10,000 USDT를 보유하고 있으며 이 돈을 사용하여 Arbitrum에서 최대한 많은 GLP를 얻기를 원합니다. 오늘날 Alice는 먼저 자신의 자금을 Ethereum에서 Arbitrum으로 연결해야 하며, 이를 위해서는 최적의 크로스 체인 브리지를 선택해야 합니다. 다행히도 Bungee와 같은 브리징 수집기를 통해 이 작업을 수행할 수 있습니다. USDT를 Arbitrum에 연결한 후 Alice는 이제 GLP를 구매하는 데 사용할 자산을 결정해야 합니다. GMX는 GLP를 구매할 때 풀의 균형을 맞추기 위해 다양한 자산에 동적 수수료를 부과하므로 USDT에 대한 수수료가 너무 높으면 Alice는 다음을 수행할 수 있습니다. USDT를 다른 자산(예: ETH)으로 교환하고 ETH를 사용하여 GLP를 구매하세요. 결정을 내리기 위해 Alice는 GMX의 수수료 차이와 여러 자산 간의 거래 슬리피지를 비교해야 합니다. 작업량이 많고 거래에 서명할 때쯤에는 계산을 사용할 수 없을 수도 있습니다. 요율, 가격, 슬리피지는 항상 변하기 때문입니다.
인텐트를 사용하면 프로세스가 완전히 다르게 보입니다. Alice는 "가능한 한 많은 GLP, 최소 100,000을 얻고 싶습니다. Ethereum에는 10,000 USDT가 있습니다."라는 의도만 표현하면 Intent 솔버는 그녀를 위해 모든 계산과 트랜잭션을 완료하고 최종 결과만 제공합니다. 대상: Arbitrum의 GLP.
즉, 트랜잭션 = 수행 방법을 지정하고, 의도 = 원하는 것을 명확히 하지만 달성 방법은 신경 쓰지 않습니다.
사실, 우리는 이미 이더리움에 대한 의도를 표현했습니다. 1inch와 같은 DEX 수집기를 사용하는 모든 스왑은 인텐트입니다. 입력 볼륨과 슬리피지를 지정하기만 하면 라우팅 계약이 가장 적합한 경로를 찾도록 할 수 있습니다. 우리는 이를 "단순 의도"라고 부릅니다. Flashbots 경매에서 거래 순서에 대한 검색자의 선호와 같이 제가 "검색자 의도"라고 부르는 것도 있습니다. 이는 나중에 Intent 구현을 살펴볼 때 중요합니다. 그런 다음 "임의의 의도"가 있습니다. 즉, 사용자가 모든 의도를 표현하고 의도를 완료할 수 있습니다.
사용자 경험의 혁명
블록체인의 열악한 사용자 경험은 오랫동안 대중으로부터 비판을 받아 왔으며 많은 사람들은 사용자 경험이 Web3의 대규모 채택을 방해하는 장애물 중 하나라고 믿고 있습니다. 이제 우리는 블록체인 사용자 경험을 Web2와 비교할 수 있을 뿐만 아니라 실제로 Web2보다 더 좋게 만들 수 있는 상호 작용 패러다임인 Intents를 보유하게 되었습니다. 현재 Web2 설정에서 최종 목표를 가진 사용자는 여전히 경로를 알아야 합니다. 즉, 주식/아이템/음식을 구매하려면 어떤 애플리케이션을 사용해야 하는지 알아야 합니다... 그러나 Intent는 알지 못한 채 사용될 수 있습니다. 길, 궁극적인 목표를 달성하세요. 블록체인 dapp의 기본 구성 가능성은 격리된 Web2 애플리케이션에 비해 모델의 확장성을 더욱 높여줍니다.
의도 레이어
이 비전은 훌륭해 보이지만 먼저 사용자가 자신의 인텐트를 표현할 수 있고 해결자가 이러한 인텐트를 해결하기 위해 경쟁할 수 있는 인텐트 레이어가 필요합니다. Anoma와 SUAVE는 Flashbots의 궁극적인 의도이며, 둘 다 완전히 다른 접근 방식을 사용하면서 블록체인의 의도 계층이 되려고 시도합니다. 그것들을 비교하기에는 너무 이르지만(인텐트 레이어가 어떤 모습이어야 하는지 아무도 모릅니다) 한 가지 확실한 것은 인텐트 레이어를 구축하는 것이 어렵다는 것입니다. SUAVE의 설계 원칙 중 상당수는 실제로 모순적이며 이는 SUAVE의 청사진에 반영되어 있습니다.
1. 신뢰할 수 있는 헌신과 분권화
인텐트의 단순한 p2p 네트워크(예: "인텐트 메모리 풀")는 인텐트에 대한 사용자와 확인자의 약속을 보장하지 않기 때문에 작동할 가능성이 없습니다. 예를 들어 사용자가 약속한 금액을 지불하도록 보장해야 합니다. , 그녀의 의도가 해결되면 솔버는 사용자가 설정한 제약 조건을 준수해야 합니다. 중앙 집중식 솔루션이 작동할 수 있지만 물론 우리는 블록체인이라는 한 가지 옵션만 남기는 분산형 솔루션을 원합니다. 예, 이것이 바로 SUAVE가 그 자체로 블록체인인 이유입니다.
2. 개인정보 보호
우리는 솔버가 가능한 한 많은 정보가 필요한 사용자 인텐트에 대해 최적의 실행을 제공하기를 원하지만 동시에 적어도 일부 인텐트 정보를 숨겨야 하는 악의적인 행위자가 이를 악용하는 것을 원하지 않습니다. 현재 두 가지 문제가 있습니다. 첫째, 블록체인의 계산 가능한 정보를 비공개로 유지하는 것이 기술적으로 어렵습니다. 제한된 선택: TEE, ZKP, MPC. 완벽한 것은 없으며 Flashbots는 보안(및 암호화 솔루션에 비해 우아함) 측면에서 이미 일부 비판을 받고 있는 Intel의 TEE(Trusted Execution Environment) 사용을 제안합니다. . 둘째, 프라이버시의 "적절한 균형"이 이루어질지 여부가 불분명합니다. Flashbots의 최신 제품인 MEV-Share 또는 "proto-SUAVE"는 사용자의 거래 데이터 중 일부를 검색자에게 공개합니다. 이것이 실제로 사용자와 검색자 모두에게 이익이 될지는 아직 알 수 없습니다. 백런은 검색자가 스왑의 크기와 미끄러짐을 정확히 아는 경우에만 최적화되며, 정보 누출이 0이면 어떤 가치도 추출할 수 없습니다. 그 사이의 모든 것은 가능한 최대 잉여를 감소시킬 것입니다.
3. 의도 언어/프로토콜
사용자는 의도를 표현하기 위한 언어도 필요합니다. 우리는 이 언어가 임의의 인텐트를 표현할 수 있기를 원하며, 이것이 SUAVE가 EVM/Solidity를 사용하는 이유입니다. 이는 Turing Complete입니다. 그러나 인텐트를 표준화하고 언어를 제한하는 프로토콜도 필요합니다. 그 이유는 두 가지 이유 때문입니다. 첫째, 무한히 표현 가능한 인텐트는 체인 상에서 확인되거나 확인되지 않을 수 있습니다. 둘째, 표현력은 더 많은 MEV를 생성하는 모호한 인텐트를 가능하게 하며 이를 최소화하고자 합니다. 이것은 또 다른 어려운 균형입니다.
4. 크로스체인 결제 및 오라클 머신
SUAVE는 독립적인 블록체인이므로 외부 도메인(예: 이더리움)의 인텐트를 처리하기 위해 크로스체인 결제가 필요합니다. 이더리움 사용자는 SUAVE에 자금을 입금하고 의도가 해결되면 해당 자금을 잠금 해제하기로 약속해야 합니다. SUAVE의 스마트 계약의 경우 이를 확인하기 위해 오라클이 필요합니다. 따라서 SUAVE는 보안, 속도, 사용자 경험, 신뢰 가정 등 오늘날 크로스체인 브리지에서 직면하는 모든 문제에 직면하게 될 것입니다.
요약하자면, 우리는 블록체인을 사용하여 인텐트 레이어를 분산시켜 크로스체인 결제 문제를 일으키고자 하며, 사용자에게 더 많은 가치 수익을 제공하고 이로 인해 더 많은 페널티가 발생할 수 있기를 바랍니다. 우리는 사용자가 자신의 규칙을 따르기를 바랍니다. 희망사항을 표현하는 것뿐만 아니라 표현한 내용이 해결 가능하도록 보장해야 합니다.
인텐트 레이어에는 계정 추상화가 필요합니다.
계정 추상화(AA)는 종종 "가스 없는 거래", "키 없는 복구" 및 "이자율 제한"으로 단순화됩니다. 예, 이것들은 멋지지만 충분히 멋지지는 않습니다. AA의 가장 멋진 점은 지갑을 인텐트의 입구로 만드는 아키텍처입니다.
AA에 대한 간략한 검토:
이더리움에는 스마트 계약과 외부 계정(EOA)이라는 두 가지 유형의 주소가 있습니다. EOA는 거래를 시작할 수 있지만 스마트 계약은 그렇지 않습니다. 따라서 오늘날 우리가 사용하는 대부분의 이더리움 지갑은 EOA입니다. Gnosis Safe와 같은 스마트 계약 지갑(SCW)이 있지만 스마트 계약은 거래를 시작할 수 없으므로 SCW를 실행하려면 EOA가 필요합니다. SCW의 장점: 스마트 계약으로서 지갑은 임의의 논리를 실행하여 지갑을 위한 수많은 새로운 애플리케이션을 열 수 있는 반면, EOA는 거래에 서명만 할 수 있습니다.
사용자가 별도의 EOA 없이 SCW를 사용할 수 있도록 EIP-4337에서는 User Operation이라는 새로운 트랜잭션 유형과 Bundlers라는 새로운 역할을 도입합니다. EIP-4337을 통과한 후 SCW의 사용자 흐름은 다음과 같습니다.
사용자는 UserOps(지갑이 수행하려는 작업 지시)를 UserOp 메모리 풀로 보냅니다. → 번들러는 UserOps를 확인 및 "번들링"하고 이를 실행(서명, 가스 지불)하고 트랜잭션을 EntryPoint 계약으로 보냅니다. → EntryPoint 계약 바인딩 SCW에 전달된 트랜잭션은 SCW에 사용자가 요청한 작업을 수행하도록 요청합니다. → 번들러는 EntryPoint 계약에서 가스 환불을 받습니다(단순화를 위해 PayMaster를 건너뜁니다).
그렇다면 Intent 레이어에 AA가 필요한 이유는 무엇일까요? SUAVE를 예로 들어 보겠습니다. 두 가지 상황이 있습니다.
1. SUAVE는 사용자 Intent를 직접 처리합니다.
이 경우 앞서 언급한 것처럼 사용자는 SUAVE에 자금을 입금하고 스마트 계약을 확인하고 작성해야 합니다. 이는 사용자 경험을 크게 감소시킵니다. 이것은 매우 반직관적입니다 - 왜 이더리움에서 무언가를 하기 위해 다른 체인으로 자금을 이동하고 다른 체인과 상호 작용해야 합니까?여기서 AA와 SCW가 작동합니다: SUAVE 가능 모든 상호 작용 논리는 이더리움 지갑에 패키지되어 있습니다. 자금이 입금되고 확인이 수행되며 모든 것이 정상입니다. 이는 SUAVE가 직면한 근본적인 문제를 해결하지 못합니다. 여전히 무신뢰 브리지, 인텐트 프로토콜 등이 필요합니다. 그러나 적어도 SCW를 사용하면 사용자 경험 자체는 상당 부분 절약할 수 있습니다. EOA는 이것을 할 수 없습니다.
2. SUAVE는 검색자의 Intent만 처리합니다.
Flashbots가 기존 제품, 즉 MEV-Boost 및 MEV-Share 위에 SUAVE를 반복적으로 구축할 것이라는 점은 분명합니다. 임의의 인텐트에 대해 실행 가능한 프로토콜을 구축하는 것이 어렵다는 점을 고려하면 SUAVE는 오랫동안 사용자 인텐트를 건드리지 않을 가능성이 높습니다. 대신에 주로 거래 주문 기본 설정, 즉 "검색자 의도"를 처리하는 현재의 Flashbot과 더 비슷해 보일 것입니다. 이 경우 누군가는 먼저 사용자의 인텐트를 트랜잭션으로 변환한 다음 해당 트랜잭션을 SUAVE에 제출해야 합니다. 이는 SUAVE보다 먼저 인텐트 해결이 발생함을 의미합니다.
그렇다면 이 경우 인텐트 레이어는 누구입니까?현재는 간단한 인텐트를 해결하는 DEX 수집기와 같은 dapp입니다. AA가 성숙해짐에 따라 SCW는 사실상 인텐트 계층이 되어 dapp 및 SUAVE로부터 점심을 빼앗을 수 있습니다. 이유는 다음과 같습니다.
현재 MEV는 기존 거래를 재정렬하는 것입니다. 그러나 인텐트를 사용하면 대부분의 값은 트랜잭션이 생성되기 전에 추출되며 MEV(아직도 그렇게 부르는 경우)는 인텐트에서 트랜잭션을 생성하는 것과 관련이 있습니다. 솔버는 인텐트를 수신한 후 원하는 대로(제약 조건이 충족되는 한) 실행을 조정하고 인텐트에 의해 생성된 트랜잭션에 자체 트랜잭션을 삽입하여 하나의 원자 트랜잭션으로 묶을 수 있습니다.
가장 직접적인 예는 샌드위치 공격입니다. 이제 샌드위치 공격자는 사용자 거래에 따라 가격을 조정하기 위해 인벤토리가 필요하며 릴레이어, 빌더 및 제안자가 샌드위치를 풀지 않도록 신뢰해야 합니다(그렇지 않으면 완전히 파괴됩니다). 그러나 의도 해결자는 사용자 의도를 위험과 자본 없이 사이에 둘 수 있습니다. 그는 플래시 대출을 수락하고, 사용자 교환 전에 가격을 변경하고, 사용자 교환 후 교환하고, 플래시 대출을 상환하고 수익을 창출하기만 하면 됩니다. 관련된 모든 단계가 기술적으로 HIS이므로 거래가 완료됩니다.
잠깐, 이 말이 낯설지 않나요? 이 멋진 그림을 다시 한 번 살펴보겠습니다.
실제로 번들러는 인텐트 솔버와 매우 유사합니다. 이들은 UserOps를 수신하고, 이를 트랜잭션으로 변환하고, 트랜잭션이 기술적으로 자신에게 속하기 때문에 원하는 대로 이를 활용합니다.
따라서 Bundlers가 다음 검색자가 될 것입니다. 이것이 지갑과 어떤 관련이 있나요? 요점은 UserOps가 Intent가 아니라는 것입니다. UserOps는 nonce 및 서명 필드의 사용이 프로토콜이 아니라 각 계정 구현에 의해 정의되는 의사 이더리움 트랜잭션입니다. 따라서 "Intent to User Operation"까지의 과정이 있어야 합니다. 이것이 바로 Intent 레이어가 수행하는 작업입니다.
SCW가 지배할 것이라고 믿는다면 논리적인 결과는 단 하나뿐입니다. 지갑이 인텐트 레이어가 되는 것입니다. 이전에 dapp에 입력된 의도와 주문 흐름은 지갑 프런트엔드에 의해 차단됩니다. 사용자 흐름은 다음과 같습니다.
SCW 프런트엔드의 인텐트 확인자는 번들러 역할도 할 가능성이 높으며 번들러는 블록 빌더일 수도 있습니다. 이러한 수직적 통합은 MEV 커뮤니티에서 널리 논의되는 EOF(Exclusive Order Flow)와 마찬가지로 "EIF(Exclusive Intent Flow)"라고 불리는 결과를 낳습니다. 지난 게시물에서 나는 사용자가 혼잡함을 발견하면 쉽게 액추에이터를 전환할 수 있기 때문에 EOF는 문제가 되지 않는다고 주장했습니다. 그러나 이번에는 의도가 달라집니다. 사용자는 더 이상 거래를 소유하지 않습니다. 물론 인텐트 레이어를 전환할 수도 있지만 지금 RPC를 전환하는 것보다 비용이 훨씬 더 높습니다.
따라서 (놀랍지도 않게) 인텐트는 MEV를 더욱 중앙 집중화합니다. 좋은 소식은 Flashbot과 모든 지갑에서 완전한 기능을 갖춘 인텐트 레이어를 구축하는 것이 어렵기 때문에 오랫동안 전체 EIF를 볼 수 없다는 것입니다. 나쁜 소식은 지갑도 반복할 수 있다는 것입니다. 오늘날의 dapp은 인텐트 솔버이며, SCW는 지갑 내에 플러그인 또는 dapp을 포함할 수 있다는 점을 기억하세요. 지갑에 지갑 플러그인을 설치하는 것은 Android 휴대폰에 Google Play에서 앱을 설치하는 것과 마찬가지로 일상적인 작업입니다. 이러한 지갑 플러그인은 최초의 인텐트 리졸버 역할을 하며, 이 플러그인이 끌어들이는 모든 인텐트는 먼저 지갑에 집계됩니다. 아래에서 위로 구축된 인텐트 레이어.
이제 우리는 이 스레드의 질문에 답할 수 있습니다. 우리는 여전히 인텐트 중심의 이더리움과는 거리가 멀지만 인텐트는 사용자 트래픽에서 더 큰 역할을 하기 시작할 것이며 이는 필연적으로 MEV 환경을 영구적으로 변화시킬 것입니다. 스마트 계약 지갑은 강력한 가치 추출기. 사용자는 더 나은 사용자 경험을 위해 트랜잭션 소유권을 희생하며, 교묘하게 설계된 인텐트 레이어가 인텐트에서 생성된 가치에 대해 공정하게 보상할 것이라고 기대합니다.
