Intent 101 (하)

Published in

Decipher Media ｜디사이퍼 미디어

28 min readJan 8, 2024

Disclaimer: 서울대학교 블록체인 학회 디사이퍼(Decipher)에서 Intent를 주제로 Weekly Session에서 발표한 내용을 바탕으로 합니다. 본 아티클은 인텐트의 구현 방식, Solver의 현주소 및 한계 등에 대한 내용을 다루고 있습니다. 이 보고서에 포함된 어떠한 내용도 투자 조언이 아니며, 투자 조언으로 해석되어서도 안 됩니다.

시리즈

Intent 101 (상)
Intent 101 (하)

Author

박찬우, 박보현 of Decipher Seoul Nat’l Univ. Blockchain Academy Decipher(@decipher-media) Reviewed By 김동혁, 박순종, 신성헌

1. 서론

Intent 101 (상) 에서는 인텐트의 개념과 인텐트를 어플리케이션 레벨에서 사용할 수 있도록 만들어진 프로토콜들을 통해 인텐트 구현에 필요한 구성요소들을 살펴봤습니다. 2부에서는 어플리케이션 레벨에서 인텐트를 사용하도록 구현된 것 외에 지갑 레벨에서의 인텐트와 인텐트 자체가 아키텍처에 내장되어 있는 프로젝트를 살펴보며, 특징과 한계점을 살펴보겠습니다. 또한, 인텐트 구현에 공통적으로 나타나는 Solver 집단에 대해서도 살펴보겠습니다. 솔버(Solver)는 필수적인 요소이며, 인텐트 생태계의 퀄리티를 결정한다고 볼 수도 있기 때문에, Solver의 현주소 및 한계를 살펴보며 인텐트에 대한 글을 마무리하도록 하겠습니다. (Solver는 인텐트를 구현한 집단에 따라서 다르게 Filler, Resolver 등으로 다르게 부르기도 하지만, 해당 글에서는 “솔버”라고 통칭하여 부르겠습니다.)

2. 인텐트의 구현

앞선 글에서도 설명했듯이 인텐트는 멀리 있지 않습니다. 이미 어플리케이션 레벨에서는 인텐트를 사용할 수 있도록 구현해둔 서비스가 많이 존재합니다. 대표적으로 UniswapX, 1inch Fusion, CoWSwap 등이 있습니다. 하지만, 이러한 어플리케이션 레벨의 인텐트는 그 자체로 한계가 존재합니다. 한계에 대해선 뒤에서 자세하게 설명하도록 하겠습니다.

2.1. 구현 방식에 따른 분류

인텐트의 구현 방식은 크게 세 가지로 분류할 수 있습니다.

어플리케이션 레벨에서의 구현(App-specific Intent)
지갑 레벨에서의 구현(Wallet-level Intent)
인텐트가 내장된 아키텍처(General purpose Intent)

어플리케이션 레벨에서의 구현은 호환성과 범용성 측면에서 한계를 지닙니다. 서로 다른 어플리케이션을 통해 제출한 유저의 인텐트는 같은 솔루션 내에 포함될 수 없으며, 또한 현재 인텐트를 구현한 어플리케이션은 토큰 지정가 스왑 어플리케이션에 불과합니다. 이러한 한계를 해결하기 위해 ERC-7521 표준과 같은 지갑 레벨에서의 구현이 등장했으며, 이더리움에 종속되지 않고 다른 체인에서도 인텐트를 사용할 수 있도록 인텐트가 내장된 새로운 아키텍처가 제안됐습니다.

해당 글에서는 지갑 레벨에서의 구현과 인텐트 내장 아키텍처를 위주로 설명하도록 하겠습니다.

2.2. 프로젝트 소개: Essential

Essential은 23년 5월부터 시작된 프로젝트로, 비교적 최근에 시작했습니다. 또한, 23년 9월 $5.15M 을 펀드레이징 했습니다. 해당 프로젝트의 비전은 “From Value Extraction to Intent Satisfaction” 으로, 직역하자면 “가치 추출에서 인텐트 충족을 향해” 란 의미입니다. 해당 의미에 대해서 추가 설명을 해보자면, 유저의 인텐트와 솔버의 가치 추출 인센티브를 하나로 얼라인(align) 하겠단 의미입니다. 즉, 솔버의 이익을 위해서 하는 행동이 유저의 인텐트를 충족시켜주는 행동으로 이어지는 생태계란 의미입니다.

Essential은 1)DSL for Intent Expression, 2)Intent-centric AA standard, 3)Modular Intent Layer 순으로 로드맵을 가지고 있으며, 현재는 2)Intent-centric AA standard 단계에 있습니다. 1)DSL for Intent Expression 에 대한 스펙은 자세하게 나온 것이 없으며, 현재 빌딩 중이라고만 나와 있습니다. DSL은 추후에 Anoma에 대한 소개를 할 때에도 나오겠지만, 먼저 간략하게 설명하자면 Domain Specific Language로, 인텐트 표현을 위한 새로운 프로그래밍 언어입니다.

먼저, 최근 Essential에서 활발하게 빌딩 중인 ERC-7521에 대해 살펴보도록 하겠습니다.

Intent-centric AA Standard: ERC-7521

(출처 : “Introducing ERC-7521: Generalized Intents for Smart Contract Wallets” | Essential Blog)

해당 표준은 인텐트를 사용할 수 있는 Smart Contract Wallet의 아키텍처에 대한 표준입니다. 기본적으로 ERC-4337 과 유사한 아키텍처를 가지고 있으며, 약간의 차이점이 존재합니다.

우선, 인텐트를 위한 표준답게 ERC-7521은 트랜잭션이 아닌 Intent Standard에 의해 정의된 인텐트를 인텐트 전용 멤풀에 제출합니다. 다음으로, 인텐트 멤풀에서 솔루션(유저의 인텐트가 해결된 상태)을 발견한 솔버는 이를 블록 빌더에게 바로 제출합니다.

해당 표준에서 제안하고 있는 필수적인 구성요소의 함수 인터페이스는 다음과 같습니다.

EntryPoint의 경우엔 ERC-4337과 유사하게 유저의 인텐트 서명을 검증하는 역할을 수행하며, 여기서 기존 ERC-4337에는 존재하지 않던, 새롭게 제안된 Intent Standard가 나타납니다. Intent Standard에는 각 인텐트의 실행 및 실행에 필요한 세부 사항을 명시해 둡니다. 마지막으로 Abstract Account는 인텐트 서명 검증 및 인텐트 실행 과정에서 delegate call을 호출하는 역할을 합니다.

솔버가 솔루션을 EntryPoint에 제출하면 인텐트 서명 검증 및 개별 인텐트 실행 과정이 시작됩니다. 이때, 실행 과정에서 Intent Standard는 인텐트 실행에 필요한 추가적인 데이터를 제공합니다. Intent Standard는 일종의 커뮤니티 플러그인이기 때문에 여러 개 존재할 수 있으며, 현재는 Essential 팀에서 만든 Asset Based Intent Standard 만 존재하는 상황입니다.

(출처 : “Asset Based Intent Standard: An Intent Standard for the World of Digital Assets” | Essential Blog)

해당 Intent Standard는 Asset required / Operation / Asset to release 으로 구성되며, 위 자료구조는 유저 인텐트의 예시입니다. ETH만으로 살 수 있는 NFT를 DAI로 사고 싶은 경우에 유저는 위와 같은 인텐트를 만들고, 인텐트 멤풀로 전달합니다. 그렇게 전달한 인텐트는 솔버가 솔루션을 아래와 같이 만들어서 완전한 트랜잭션을 만들고, 최종적으로 블록 빌더에게 전달합니다.

2.3. 프로젝트 소개: Anoma

다음으로 소개할 Anoma는 비교적 예전인 2021년부터 시작된 프로젝트입니다. 21년 4월부터 3차례 펀드 레이징을 했으며, 같은 투자사로부터 꾸준히 후속투자를 받아오고 있습니다. 세 명의 코파운더 중 한 명인 Adrian Brink는 Anoma를 “디지털 자산 거래를 위한 조정 시스템” 이라고 정의하는데, 이는 Counterparty Discovery를 통해 화폐에 대한 의미 자체를 재정의한 새로운 플랫폼이라는 의미입니다. Anoma의 Counterparty Discovery에 대한 과정은 뒤에서 더 자세히 살펴보도록 하겠습니다.

사실 이미 어플리케이션 레벨에서 인텐트를 사용할 수 있으므로 블록체인의 다양한 디앱을 사용하는 유저 입장에선 왜, 굳이, 또, 다른 네트워크인 Anoma를 사용해야 하는지에 대한 의문이 들 수 있습니다. 따라서 먼저 Intent-centric Architecture가 왜 필요한지 알아보도록 하겠습니다.

Why Intent-centric Architecture?

기존에 존재하는 블록체인 네트워크를 Blockchain-centric Architecture라고 하겠습니다. 이러한 Blockchain-centric Architecture 가 디앱에게 제공하는 기능은 Programmable Settlement 하나밖에 없습니다. Programmable Settlement 란 스마트 컨트랙트의 로직에 따라 블록체인 네트워크의 상태를 변경시키는 것을 말합니다.

(출처 : “An Introduction to Intents and Intent-centric Architectures” | Anoma Blog)

Programmable Settlement를 통해서 ERC-20, ERC-721, AMM, etc 와 같은 상대적으로 간단한 형태의 어플리케이션은 온체인 위에 전부 구현할 수 있습니다. 그러나 Blur, Opensea와 같은 NFT marketplace, 인텐트를 이용한 DEX인 CoWSwap, 1inch Fusion, UniswapX, 그리고, Gitcoin과 같은 voting platform을 구현하기 위해선 중앙화된 서버 혹은 단일 주체에 의존해야 하며, 최종 Settlement만 블록체인에서 이뤄지는 방식입니다. 예를 들어, Opensea의 경우 Seaport contract를 이용하긴 하지만, 매수자와 매도자를 연결해주는 기능(Counterparty Discovery)은 중앙 서버를 이용하여 이뤄집니다. 또한, CoWSwap의 경우에도 유저의 주문을 체결시키기 위해서 솔버라는 단일 주체에 의존하게 됩니다.

이러한 Single Point of Failure를 완화하기 위해 대부분의 어플리케이션 혹은 프로토콜은 로드맵 상에 단일 주체를 분산화하겠다는 마일스톤을 추가해둡니다. 즉, 결국 Blockchain-to-decentralize-X 구조를 취하게 됩니다. 이러한 구조는 탈중앙화 측면에서 볼때 적절하지만, 상호운용성 측면에서는 적절하다고 볼 수 없습니다. 개별 어플리케이션들은 호환 불가능하며, 네트워크 효과를 누리기 힘들어집니다.

위와 같은 한계점 때문에 Intent-centric Architecture가 제안됩니다. Intent-centric Architecture가 디앱에게 제공하는 기능은 1)Generalized Intents, 2)Counterparty Discovery, 3)Solving, 4)Settlement 입니다.

Generalized Intents 특정 어플리케이션 혹은 특수한 상황의 인텐트로 제한되지 않고 임의의 인텐트 처리
Counterparty Discovery 개별 인텐트가 노드들에게 전파되고 솔버가 접근할 수 있는 탈중앙화 프로세스
Solving 인텐트를 결합해서 솔루션을 만들고, 해당 솔루션이 유효한지 계산해보는 탈중앙화 프로세스
Settlement 온체인 상에서 솔루션을 검증하고 확정하는 과정

해당 아키텍처 위에서 디앱은 비즈니스 로직에 따른 인텐트 생성과 솔버 선출 알고리즘만 고려하고, Counterparty Discovery를 위한 솔버 집단 자체에 대한 고려나 구현은 필요로 하지 않습니다. 또한, 유저들의 인텐트가 모두 같은 도메인 위에 존재하기 때문에 다양한 디앱을 통해 발생한 유저의 인텐트 간의 호환성이 높아집니다. 즉, CoW(Coincidence of Wants)의 확률이 Blockchain-centric Architecture의 인텐트 구현 디앱에 비해 상대적으로 높습니다.

위와 같은 이유로 Intent-centric Architecture가 등장했고, 이러한 Intent-centric Architecture는 모듈러하게 사용할 수도 있습니다.

Intent-centric Architecture 사용방안

크게 3가지 방식으로 Intent-centric Architecture를 사용할 수 있습니다.

레이어 1
레이어 1.5
레이어 2

우선, Intent-centric Architecture인 Anoma는 그 자체로 블록체인 레이어 1이며, 해당 블록체인에서 만들어진 트랜잭션을 통해 계정들의 상태를 업데이트 할 수 있습니다.

다음으로 레이어 1.5, 즉 DA layer로 활용할 수도 있습니다. Settlement를 기존에 존재하는 레이어 1 블록체인으로 설정하고, Settlement를 제외한 트랜잭션 검증 및 실행, Counterparty Discovery 등을 전부 Anoma 위에서 동작하도록 하는 것입니다.

마지막으로 이더리움 레이어 2로도 활용할 수 있습니다. 계정들의 상태를 전부 Anoma 위에서 업데이트하고, 해당 상태에 대한 영지식 증명과 해시값을 이더리움으로 전송하는 방식으로 기존 롤업과 유사하게 사용할 수 있습니다. 즉, 일종의 Intent-centric Rollup이 되는 것입니다.

다음으로, Anoma의 아키텍처에 대해 조금 더 자세하게 살펴보겠습니다.

Architecture of Anoma

(출처 : “Intent-centric architectures for fully decentralized dApps” | Adrian Brink)

Anoma의 아키텍처는 기능에 따라서 다음과 같이 1)Counterparty Discovery, 2)Consensus, 3)Execution & Verification 세 가지 부분으로 분류할 수 있습니다. 먼저, 1)Counterparty Discovery 부분에서는 유저가 클라이언트를 통해 자신의 인텐트를 제출합니다. 이렇게 제출한 인텐트는 Intent Gossip Network에 올라가게 되고, 솔버는 해당 네트워크에 존재하는 유저의 인텐트에 대한 솔루션을 찾습니다.

(출처 : Breaking Down Taiga | Anoma Forum)

이때, 유저가 최초로 제출한 인텐트는 일종의 부분(혹은 미완성) 트랜잭션(partial transaction)이라고 볼 수 있습니다. 인텐트 자체로는 계정의 상태를 변경시킬 수 있는 완전한 트랜잭션이 아니므로, 이러한 부분 트랜잭션을 조합해서 온전한 트랜잭션으로 만드는 과정을 솔빙(Solving)이라고 하며, 솔버가 이러한 역할을 수행합니다.

솔버는 솔루션을 찾은 후에 이를 트랜잭션 멤풀로 제출합니다. 이때 2)Consensus 과정이 시작되며, 일반적인 블록체인 레이어 1과 유사하게 동작합니다. 노드 간의 합의 과정을 거쳐 블록을 확정짓습니다. 이때, Anoma에서는 트랜잭션 멤풀에 대한 MEV를 막기 위해 트랜잭션을 전부 암호화시켜 두고, 블록이 확정되고 나서야 해당 트랜잭션 내용을 공개합니다.

마지막으로 확정된 블록 내의 트랜잭션들에 대해 3)Execution & Verification 과정이 진행됩니다. 먼저 트랜잭션 실행에 따른 상태 전환을 한 후에, 해당 상태 전환이 유효한지 검증을 합니다. 유효하다면, 상태 트리 루트를 업데이트하고 다음 블록에 포함시켜둠으로써 최종적으로 Settlement를 통해 유저의 상태를 반영합니다.

Dapps on Intent-centric Architecture

다음으로 Blockchain-centric Architecture와 Intent-centric Architecture의 디앱에 대해서 살펴보겠습니다.

블록체인 네트워크에 존재하는 리소스(스마트 컨트랙트, 계정상태)는 누구나 확인하고 사용할 수 있으며(스마트 컨트랙트의 특정 주체만 실행할 수 있는 조건을 제외하면), 기존에 존재하던 리소스를 활용해 새로운 어플리케이션을 만들어낼 수 있습니다. 가장 쉽게 와닿는 예시로는 특정 블록체인 게임에서 사용하던 게임 아이템을 다른 게임에서도 활용할 수 있다는 것입니다. 따라서 필자는 웹3 어플리케이션의 가치는 상호운용성과 무허가성에서 기인한다고 생각합니다. 이러한 특성을 잘 살린 웹3 어플리케이션으로는 Defi(Uniswap, Aave, GMX), Collectables(Blur, Opensea, Magic Eden), Storage(IPFS, Filecoin, Arweave), Games(Dark Forest, Axie Infinity), Social(Lens, Friend.tech) 등의 카테고리가 있습니다. 그러나 Blockchain-centric Architecture 위의 웹3 어플리케이션에는 한계가 존재합니다. 바로 1)Liquidity Composability(유동성 호환성), 2)Best UX requires trust(최고의 사용자 경험을 위해선 신뢰 필요), 3)High onboarding cost(높은 온보딩 비용) 입니다. 블록체인 네트워크와 개별 디앱과 같은 도메인마다 유동성이 파편화되어 있고, 좋은 사용자 경험을 제공하기 위해선 여전히 중앙 서버 혹은 단일 주체와 같은 신뢰를 필요로 합니다. 마지막으로 가파른 러닝커브를 가지고 있기 때문에 신규 유저의 유입이 어렵습니다.

Intent-centric Architecture에서는 인텐트 멤풀을 통한 유동성 파편화 문제 해결, Counterparty Discover & Solving 과정의 탈중앙화를 통한 Trustless best UX 제공, 인텐트 도입을 통한 유저 러닝커브 완화가 가능할 것입니다. Blockchain-centric Architecture에서의 디앱과 유사하게 Intent-centric Architecture에서의 디앱도 컨트랙트 배포를 통해 만들 수 있습니다. 아래 코드는 Anoma에서 자체적으로 제작 중인 언어인 Juvix를 사용해 간단한 은행의 로직 일부를 가져온 것입니다.

(출처 : https://github.com/anoma/juvix/blob/758d1cd949a98bec981fc6ffbfc42e991705fc26/examples/milestone/Bank/Bank.juvix#L4)

Dapps on Intent-centric Architecture: Public Signal

Intent-centric Architecture에서는 Counterparty Discovery 기능을 잘 활용하면 기존에 존재하지 않던 새로운 형태의 디앱이 나올 수 있다고 합니다. 이렇게만 말해선 어떤 형태의 디앱이 나올지 쉽게 상상이 되지 않기 때문에 Anoma에서는 그 예시로 Public Signal 이란 디앱을 제안합니다. 간단하게 말해서 사적재화 및 공적재화에 펀딩할 수 있는 어플리케이션 입니다.

기존 공공재 펀딩의 문제점은 크게 2가지가 있습니다.

Free-rider Problem: 내가 기여하지 않아도 타인이 기여할 것으로 예상해 액션을 취하지 않고 이득만 취하는 문제
Assurance Problem: 기여한 사람이 나밖에 없을때, 특정 임계값을 넘지 못해 자신의 기여가 무용지물이 될까 걱정하는 문제

해당 문제의 해결책으로는 “Dominant Assurance Contract” 가 있습니다. 이는 펀드가 성사되지 않았을 때, 이미 펀드에 참여한 투자자들에게 환불과 함께 환불 보너스(경제적 인센티브)를 제공함으로써 펀딩 요인을 높이는 우세 보증 계약입니다.

웹2에는 Kickstarter와 같은 어플리케이션이 이미 존재합니다. 그러나 Kickstarter는 펀딩 수요에 대한 집계가 불가능합니다. Intent-centric Architecture에서는 수요자들의 인텐트를 통해 수요자가 어떤 펀딩이 열리기를 원하고 기다리는지 확인할 수 있습니다. 또한, 특정 인물이 펀딩에 참여해야 본인이 해당 펀딩에 참여할 것이라는 “Conditional Commitment”도 가능하기 때문에 훨씬 더 나은 유저 경험을 제공할 수 있다고 생각합니다.

DSL(Domain Specific Language)

(출처 : “Juvix: Towards a Functional Programming Language for Decentralized Applications and Beyond” | ETH Prague)

Anoma에서는 Juvix라는 함수형 언어인 Domain Specific Language도 함께 만들고 있습니다. Anoma 뿐만 아니라 Essential 에서도 마찬가지로 DSL 만드는 것이 로드맵 상에 존재하지만, 현재 공개된 스펙은 없기에 Anoma의 Juvix에 대해서만 언급하겠습니다. Juvix는 유저 인텐트를 좀 더 잘 표현할 수 있는 언어에 대한 필요성과 보안적으로 객체지향언어인 Solidity보다 낫다고 판단해서 만들어지고 있는 새로운 언어입니다. Anoma 위에 컨트랙트를 배포할 때 사용되며, 확장성, 성능, 유지보수 측면에서 장점을 가지고 있습니다. 또한, 기존 low-level 언어와 유사하기 때문에 개발자 친화적이라는 특징을 지니고 있습니다. 하지만, 새로운 언어로 개발을 요구하는 것은 해당 생태계의 진입장벽으로 작용할 수 있습니다.

2.4. Essential vs. Anoma

앞서 살펴본 Essential과 Anoma 둘 다 인텐트를 범용적으로 사용할 수 있는 프로토콜을 만들고 있습니다. 그러나 두 프로젝트의 GTM(Go-to-Market) 전략에는 차이가 있습니다. 따라서 해당 파트에서는 어떤 차이점이 있는지 앞서 소개한 내용을 바탕으로 살펴보도록 하겠습니다.

먼저 Essential은 현재 ERC-7521을 메인으로 지갑 레벨의 인텐트 구현에 집중하고 있습니다. 그러나 Essential의 최종 목표가 ERC-7521을 구현하는 것은 아니며, 최종적으로 Modular intent layer를 구축하려고 합니다. 이들은 유저가 가장 많은 이더리움 생태계를 레버리지 하여 지갑 레벨에서 유저들이 인텐트를 손쉽게 사용할 수 있도록 해주려고 합니다. 이렇게 많은 유저가 지갑 레벨에서 인텐트를 사용하도록 구현한 명성을 레버리지 하여 유저를 확보하려는 전략으로 추측됩니다.

그에 반해 Anoma는 프라이버시를 원하는 유저들을 위해 프라이버시 보호에 특화된 레이어 1을 먼저 개발하고 런칭했습니다. 이렇듯 자체 개발한 블록체인을 통해 먼저 유저들을 모을 것으로 예상됩니다. 앞서도 설명했듯이 Anoma는 자체 Settlement도 가능한 레이어 1으로 사용될 수도 있지만, Settlement만을 다른 체인으로 지정해 레이어 1.5로 사용할 수도 있기 때문에 자체 체인을 통해 먼저 확보한 유저들을 바탕으로 Anoma 생태계를 확장해 나갈것으로 추측됩니다.

3. Solver의 현주소 및 한계

모든 인텐트의 구현에 공통적으로 Solver Network가 필요합니다. 솔버는 유저의 인텐트를 해결해주는 역할을 하고, 이 과정에서 다른 솔버들과 경쟁을 합니다. 이러한 경쟁 속에서 자신이 제공한 솔루션이 채택되기 위해선 다른 솔버보다 빠르게, 더 좋은 조건의 솔루션을 찾아야 합니다.

이렇듯 솔버의 퀄리티를 보장하기 위해선 바람직한 경쟁이 일어나는 환경을 구축하는 것이 중요하고, 솔버의 퀄리티가 결국 해당 인텐트 생태계의 퀄리티도 결정한다고 볼 수 있습니다. 솔버의 솔루션은 대부분 Auction을 통해 채택되는데, 현재는 Dutch Auction이나 Batch Auction 방식을 많이 사용하고 있습니다. Dutch Auction은 솔버에게 가장 불리한 조건에서 시간이 지남에 따라 점점 더 좋은 조건을 제공하는 식으로 진행되는 경매이며, 시간에 의존적인 경매 방식입니다. 다음으로 Batch Auction은 최적의 솔루션을 제공하는 솔버의 솔루션이 채택되는 방식입니다.

3.1. Solver Incentive

경매를 통해 채택된 솔버에게는 인센티브가 제공되며, 솔버는 해당 인센티브를 통해 솔루션을 찾아내는 과정에서 소모한 리소스에 대한 보상을 받습니다. 솔버의 인센티브는 Implicit Incentive & Explicit Incentive로 나뉘어 집니다. Implicit Incentive는 솔버가 제공한 솔루션과 유저의 인텐트 간에 차이로 인해 발생하는 솔버의 잉여 보상입니다. Implicit Incentive의 간단한 예시로는 유저가 1 ETH를 2,000DAI에 파는 인텐트를 제출한 경우, 솔버가 1 ETH를 2,100DAI에 파는 경로를 발견할 수 있습니다. 이 경우에 솔버는 100DAI의 Implicit Incentive를 얻을 수 있습니다. 아래 그래프는 유저가 1 ETH를 1,600USDC로 스왑하는 지정가 주문을 제출했을때의 Implicit Incentive 추세를 나타낸 것입니다.

(출처 : “Powerful Intents Part 2: Solver Incentives” | Anoma Forum)

Explicit Incentive는 솔버가 제출한 솔루션이 채택될 경우에 프로토콜 자체에서 솔버에게 추가적으로 지급하는 수수료 혹은 보상을 말합니다.

(출처 : @cowprotocol/Solver Info & @flashbots/UniswapX | Dune)

현재 솔버가 실제로 운영되고 있는 프로토콜은 어플리케이션 레벨에서 인텐트를 구현해 둔 CoWSwap, UniswapX, 1inch Fusion 등이 있습니다. 해당 생태계에 참여하는 솔버는 다양하며, 실제로 UniswapX 의 경우 솔버를 사용하지 않는 Uniswap 대비 UniswapX의 거래 비중이 점점 늘고 있습니다. 이는 인텐트가 이미 많이 사용되고 있으며 솔버도 잘 구축되어 있음을 알 수 있습니다.

3.2. 한계: Fill or Kill

그러나 이러한 Solver Network에 한계가 존재하는데 바로, 승자독식시장이란 것입니다. 승자독식시장에서 승자가 되지 못한 솔버들은 솔루션을 만들기 위해 지불하는 비용을 온전히 감당해야 합니다. 아래 그래프는 ${배치당 솔버 수수료 / 가스 수수료}$ 값을 하루 단위로 나타냅니다. 해당 지표가 1을 넘기지 못한다는 뜻은 가스 수수료, 즉 솔버가 지불하는 비용이 솔버의 수익인 배치 당 솔버 수수료보다 작다는 뜻입니다. 이러한 추세가 지속되면 솔버는 수익을 얻을 수 없으며, 소수의 승자 솔버들만이 남게 됩니다. 승자 솔버가 해당 시장을 독점하므로 자연스럽게 인텐트 솔빙의 퀄리티가 떨어지며, 해당 인텐트 생태계는 지속 불가능합니다.

이렇게 대부분의 솔버들은 배치 당 수수료만으로 가스 수수료를 충당하지 못하기 때문에 프로토콜 차원에서 추가적인 보상을 줍니다. CoWSwap의 경우엔 $COW 토큰 지급을 통해 솔버의 수익을 보장해주고 있습니다.

솔버를 운영하는 입장에서는 위의 Optimal Score 계산 및 그에 따른 인텐트 생태계 참여를 결정하게 됩니다. p 는 자신의 솔루션이 채택될 확률이고, successfulQuality는 자신의 솔루션이 채택되었을때 얻을 수 있는 보상이며, SC는 솔루션이 채택되었을때 발생하는 비용입니다. 마지막으로 C는 솔루션 채택과 무관하게 사용되는 비용이며 대부분 가스비 혹은 시뮬레이션 진행 시 소모되는 리소스입니다. 여기서 p는 솔버들과의 경쟁을 통해서 결정되는 확률로, 해당 확률은 솔버 간의 알고리즘 경쟁, 리소스 경쟁 등을 통해 결정됩니다.

4. 결론

해당 글에서는 Essential과 Anoma를 통해 Intent-centric Architecture가 제안된 배경과 구조를 살펴봤습니다. 기존 Blockchain-centric Architecture에서는 Programmable settlement를 이용해 비교적 간단한 로직의 디앱을 온체인 상에 구축할 수 있었지만, Counterparty discovery 같은 기능은 중앙 서버나 단일 주체를 통해 구현을 해야 했으므로 온체인 상에 구축하는 디앱의 한계가 존재합니다. 따라서 General intents, Counterparty discovery, Solving, Settlement와 같은 기능을 제공해주는 Intent-centric Architecture가 제안되었습니다.

필자는 Essential과 Anoma가 인텐트를 블록체인에 도입시키는 것이 향후 3년간 매우 큰 과제이며, 동시에 블록체인의 좀 더 많은 쓰임새를 고민할 수 있는 기회라고 생각합니다. 인텐트를 통해 소비자의 수요에 대한 예측 및 해당 수요를 바탕으로 펀딩을 진행하거나, 프로덕트를 만들어낼 수 있는 새로운 기회가 발생할 것입니다. 그러나, 인텐트를 왜 사용해야 하는지, 인텐트를 탈중앙화 금융에 사용하면 사실상 중앙화 금융과 같아지는 것이 아닌지, 인텐트가 단순히 하나의 내러티브가 아닌지와 같은 생각을 하는 많은 사람들을 설득시켜 나가는 매우 큰 과제가 남아있습니다. 아주 잘 만든 프로토콜이라도 유저가 없으면 무용지물이기 때문에, 적절한 GTM 전략을 통해 자연스럽게 유저들을 Intent-centric Architecture에 온보딩할 수 있도록 하는 것이 중요합니다. 해당 글에 나온 Essential과 Anoma 외에도 수많은 인텐트 생태계를 빌딩하고 있는 프로젝트들이 있습니다. 과연 Intent-centric Architecture 의 미래가 올지 지켜보는 재미가 있을것 같습니다.