Intent 101 (상)

Published in

Decipher Media ｜디사이퍼 미디어

41 min readJan 8, 2024

Disclaimer: 본 글은 서울대학교 블록체인 학회 디사이퍼(Decipher)의 Weekly Session에서 Intent를 주제로 발표한 내용을 기반으로 작성되었습니다. 해당 글은 인텐트의 등장배경과 전반적인 내용을 바탕으로 작성자의 주관적인 의견을 포함하여 작성하였으며, 본 글에 포함된 어떠한 내용도 투자 조언이 아님을 명시합니다. 이에 따라 본 글의 어떠한 내용도 투자 조언으로 해석되어서도 안 됩니다.

시리즈

Intent 101 (상)
Intent 101 (하)

Author

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

1. 서론

본 글은 인텐트의 등장배경과 인텐트에 대한 전반적인 내용 — 개념, 로직 구조, 종류 등 — 을 다루고 있습니다. 특히 일반적인 트랜잭션과 인텐트의 차이점을 기준으로 비교분석을 진행했으며 5가지 분석 지점을 바탕으로 인텐트 프로젝트에 대한 개괄적인 분석을 포함해 인텐트의 효용과 위험성에 대해서도 다루고 있는 글입니다. 본 글에서는 리서치를 통해 파악한 객관적인 통계와 사실을 기반으로 필자의 주관적인 의견을 개진하고 있음을 서론에서 밝힙니다.

인텐트에 대한 논의가 꾸준히 이뤄져 온 가운데 여러 의문점이 생겨 해당 주제에 대한 리서치를 시작하게 되었습니다. 리서치를 통해 본 아티클을 발간하는 과정에서 다음과 같은 여섯 가지 의문점을 해소하고자 했습니다.

도대체 인텐트란 무엇인가
인텐트는 어떤 로직으로 작동하는가
인텐트는 트랜잭션과 어떻게 다른가
인텐트의 현재 주소는 어떻게 되는가
Why intent?
Side Effect of Intent

위 여섯 가지 의문점을 바탕으로 본 글을 전개해나갈 것을 언급하며 본론을 시작하겠습니다.

2. 인텐트 등장 배경

인텐트가 무엇인지 파악하기 전에 등장 배경을 이해할 필요가 있습니다. 필자는 인텐트가 등장하게 된 배경을 기존 시스템의 문제점에서 찾았습니다. 제시하고자 하는 문제점은 크게 2가지입니다.

문제 지점 1) 경로에 의존적인 트랜잭션 결과

글 작성일 기준(2023.12.29) 현재 블록체인에 존재하는 서비스의 종류만 36가지이며 탈중앙화거래소(DEX)만 세어보더라도 1,112개의 프로토콜(혹은 프로젝트)가 존재합니다. 그 중 이더리움 위의 DEX만 총 124개로 하나의 체인 위에도 상당히 많은 프로젝트가 존재함을 파악할 수 있습니다. 이는 곧 동일한 행위를 여러 경로를 통해 성취할 수 있음을 의미합니다. 예를 들어, 이더리움에서 1 ETH를 USDC로 스왑하고자하는 상황을 가정해보겠습니다. 첫 번째로 스왑할 수 있는 DEX는 앞서 언급한 것처럼 128개가 존재하기 때문에 이 중 하나의 프로토콜을 결정해야 합니다. 두 번째로 하나의 프로토콜을 결정했다고 하더라도 한 프로토콜 안에서 한 페어(현재 예시로 ETH-USDC 가정)에 대해 여러 풀이 존재하고 해당 풀마다 apr과 같은 인센티브 요소가 다르기 때문에 어떤 풀에서 스왑할 것인지도 결정해야 합니다. 이처럼 하나의 행위를 하려고 하더라도 굉장히 많은 경로가 있음을 알 수 있습니다.

경로가 많은 점이 이용자에게 어떤 불편함을 초래하는 지 알아보겠습니다. 먼저, 이용자는 첫 번째 결정을 함에 있어 본인의 지식에 비례하는 만큼의 선택지를 가지고 선택할 수 있습니다. 알고 있는 DEX가 한 곳 뿐이라면 어쩔 수 없이 해당 DEX를 선택하게 되고, 아는 곳이 더 많다면 그만큼 많은 선택지를 가지게 됩니다. 이 부분은 두 번째 결정에서도 마찬가지로 작용합니다. 이때, 이러한 일련의 결정에 따라 동일한 행위에 대한 결과가 달라질 수 있습니다. 위에서 들었던 예시를 이어서 설명해보자면 A라는 DEX의 A’ pool과 B라는 DEX의 B’ pool있다고 가정해봅시다. A’ pool에서의 ETH-USDC 페어의 경우, 2,000 USDC/ETH의 교환비를 가지고 있으며 B’ pool은 2,100 USDC/ETH의 교환비를 가지고 있습니다. 이때, 이용자는 당연히 B에서 스왑하는 것이 훨씬 이득을 가져가지만 B’ pool을 모른다면 어쩔 수 없이 A’ pool에서 교환하게 될 것이며 이는 곧 100 USDC의 손실로 이어지게 됩니다. 즉, 아는 만큼 결과에 대해 예상할 수 있으며 이에 따른 손해도 상이하게 됩니다.

여기서 제기하고자 하는 첫 번째 문제점은 기존의 트랜잭션 결과가 경로 의존적이라는 점입니다. 급변하는 블록체인 생태계에서 모든 프로젝트와 모든 경우의 수를 매번 파악하기란 매우 어려운 문제입니다. 이러한 문제점이 있지만 여전히 어떠한 경로를 선택했느냐에 따라 같은 의도를 갖는 트랜잭션조차 결과가 달라진다는 점에서 문제 지점이라고 생각했습니다. 실제로 이와 같은 문제점으로 인해 1inch와 같이 유저를 대신해서 최적의 경로를 추천해 주는 서비스인 Aggregator가 등장하기 시작했습니다. Aggregator의 등장으로 유저는 프로토콜에 대한 많은 정보를 가지고 있지 않아도 비교적 수월하게 손해를 최소화하여 스왑할 수 있게 되었습니다. 이런 형태로 미뤄보았을 때, 아직 언급하진 않았지만 인텐트와 매우 비슷한 목적이라고 보여집니다. 어쩌면 이 또한 인텐트라고 명명되지 않았을 뿐 인텐트의 한 가지 형태로 보여지기도 합니다.

문제 지점 2) 기존 트랜잭션의 불편한 요소

다음으로 문제삼은 지점은 트랜잭션 자체에 내재되어 있는 불편 요소들입니다. 크게 4가지 불편한 점을 꼽을 수 있습니다.

첫 번째, 일반적인 트랜잭션은 이용자가 원하는 결과를 보장하지 못한다는 점

트랜잭션은 이용자가 원하는 행위를 하기 위한 의도를 가지고 특정 경로를 실행하는 것으로, 경로를 실행하기 때문에 실행 결과에 대한 예측은 가능할 수 있지만 확신은 불가능합니다. 이는 트랜잭션은 네트워크 내에서 독립적으로 실행될 수 없고 여러 요소에 종속적이기 때문입니다.

첫 번째 요소로 실행 순서를 꼽을 수 있습니다. 트랜잭션이 어떤 순서로 실행되었는지는 결과에 영향을 미치기 때문입니다. 트랜잭션의 실행 순서에 대한 설명을 발전시켜 보면 MEV attack 또한 생각해볼 수 있습니다. 특정 트랜잭션에 대해 프론트러닝(Front running)이나 샌드위치 공격(Sandwich attack)을 통해 실행 순서의 변동이 일어나는 경우, 이용자가 예상한 결과의 오차 범위에서 꽤 벗어나는 결과를 초래할 수 있습니다.

두 번째 요소로 네트워크의 혼잡도를 들 수 있습니다. 네트워크의 상황에 따라 가스비나 트랜잭션의 처리 속도가 상이해지고 이러한 부분은 이용자가 예상하지 못한 부분으로 트랜잭션의 결과에 영향을 미치게 됩니다. 특정 시간에 트랜잭션이 많이 발생하여 트랜잭션이 지연되는 경우 혹은 PGA(Priority Gas Auction) 발생에 따라 가스비가 증폭하는 경우를 예시로 들 수 있습니다.

두 번째, 이용자가 직접 데이터를 지정해 트랜잭션 명령을 내려야 한다는 점

즉, 이용자가 블록체인과 직접적으로 소통해야 합니다. 이용자가 1 WETH를 2,100 USDC로 스왑하고자 하는 경우를 예시로 들어보겠습니다. 이때 이용자가 스스로 결정을 해야 하는 부분은 아래와 같습니다.

스왑할 체인 선택 : 이더리움
체인 위의 DEX 및 pool 선택 : Uniswap — ETH/USDC pool
스왑할 토큰에 대한 권한 허용 : Approve 해야함.
스왑할 토큰과 정확한 수량을 명시 : “1만큼의 WETH를 1.2만큼의 ETH로 바꾸고, 1.2 ETH를 2,100 USDC로 바꿔달라” → 총 2번의 트랜잭션을 각각 생성해야 함.
이 외의 옵션 선택 : (서비스 및 지갑에서 제공해준다면) 슬리피지, 가스비 등의 한도 설정
해당 거래에 대한 트랜잭션 생성 (사인)

이용자는 위의 과정을 거치며 블록체인과 직접 소통해야 하며, 위의 예시에서 최소 3번 이상의 트랜잭션이 발생합니다. 먼저 3번 과정에서 토큰 권한을 허용하기 위한 트랜잭션이 한 번 필요하며, 4번 과정에서 원하는 결과가 한 번에 도출되지 않으므로 총 2번의 트랜잭션을 통해서 원하는 결과를 도출해야 합니다. 또한 트랜잭션을 전송하는 데 있어 필요한 데이터들을 직접 지정해서 같이 전송해줘야 합니다. 위의 예시에서 들어준 세부사항 — 이더리움, Uniswap 등 — 은 모두 유저가 지정해야 할 데이터라고 할 수 있습니다.

정리하자면, 이용자는 직접 트랜잭션을 블록체인에 전송해야 하며, 필요한 데이터를 같이 명시해야만 합니다. 이는 사용자 경험이 굉장히 낮아지는 원인 중 하나이며 블록체인에서의 금융 거래를 시작하기 어렵게 하는 요소이기도 합니다. 이러한 부분이 문제점으로 대두되면서 계정추상화가 주목을 받기 시작했습니다. 실제로 계정추상화를 통해 UserOps라고 불리는 여러 행위를 묶어서 한 번에 처리할 수 있게 하는 것이 가능해졌습니다. 계정추상화는 인텐트와 다르게 여전히 데이터를 명시해야 하는 부분은 있지만 사용자 경험에 긍정적이라는 점과 여러 operation을 한 트랜잭션으로 묶는다는 점에 있어서 해결하려는 문제의 맥락은 비슷해보입니다. 이는 또 다른 형태의 인텐트라고 생각이 됩니다.

세 번째, 이용자가 트랜잭션을 통해 원하는 행위를 실행하기 위해서 스스로 모든 경로를 지정해야 한다는 점

앞서 언급했듯이 트랜잭션은 결과가 아닌 경로를 지정해서 실행 권한을 부여하는 행위이기 때문에 이용자가 여러 경로를 통해 원하는 결과를 성취해야 한다면, 직접 모든 경로를 지정해야만 합니다. 예시를 통해 설명을 덧붙이자면, ‘A의 A’ 풀에서 스왑 후 B의 B’ 풀에서 스왑’이 필요한 경우, 총 2번의 경로를 지정할 필요가 있는데 이는 이용자가 모두 각각 지정해줘야 합니다. 이러한 구조는 사용자 경험성을 매우 저하시키며, 특정 결과를 얻기 위해 소요되는 시간도 증가하게 됨으로써 첫 번째 제시한 문제점인 결과의 변동성이 증가한다는 점으로 이어집니다.

네 번째, 트랜잭션을 실행하기 위해 가스비를 native token으로 지불해야 한다는 점

트랜잭션은 가스비를 지불함으로써 실행이 됩니다. 이는 곧 가스비를 지불하지 않으면 실행할 수 없다는 것을 의미하는데, 가스비를 지불하는 수단에 있어 모든 토큰이 수용되는 것이 아닌 native token만을 사용한다는 점이 현재 트랜잭션의 큰 문제점 중 하나라고 생각합니다. 이 지점이 문제점이라고 생각되는 근거는 사용자 경험적인 측면에 있어 불편한 점을 야기하게 되기 때문입니다. 가령 사용자가 이더리움에서 트랜잭션을 제출하려고 할 때, 트랜잭션에 이더(ETH)가 필요하지 않아도 무조건적으로 이더리움의 native token인 이더(ETH)를 트랜잭션을 제출하는 지갑에 소유하고 있어야 트랜잭션을 제출 가능하게 된다는 점을 불편한 점의 예시로 들 수 있습니다.

위에 제기된 문제점들을 정리해보면 다음과 같습니다.

원하는 행위를 하기 위한 최적의 방법을 알기 위해서는 그에 상응하는 지식을 가지고 있어야 하며 이는 곧 트랜잭션의 경로가 사용자의 지식에 의존하는 것을 의미합니다. 또한, 앞서 언급했던 기존 트랜잭션의 문제점과 다수의 블록체인 서비스에서 제공하는 불편한 유저 인터페이스는 곧 부정적 사용자 경험으로 이어집니다.

따라서 현재와 같이 블록체인 시스템 자체에 중점을 맞춘 blockchain-centric한 구조에서 이와 같은 문제점이 발생함에 따라 사용자 친화적이지 않고, 이용자가 복잡한 행위를 수행하는 데에 있어 한계점이 존재하게 됩니다.

이미 이를 해결하고자 다양한 개선 방향이 제시되었으며 그 일환으로 1inch와 같은 Dex Aggregator와 ERC-4337의 구현체인 Account Abstraction을 확인할 수 있었습니다. 실제로 이처럼 인텐트와 비슷한 개념은 그 필요성이 대두되어 왔으며 이미 다른 형태로 해결하려는 움직임이 있었지만 또 다른 개선 방향으로 “인텐트”라는 단어를 사용하며 본격적인 내러티브가 시작된 것으로 보입니다.

3. 인텐트란?

2.1. 인텐트 정의

인텐트의 등장 배경을 바탕으로 첫 번째 의문인 “(1) 인텐트란 무엇인지”, 그 정의에 대해 짚고 넘어가겠습니다.

인텐트는 완전한 트랜잭션이 아닌 부분적인 트랜잭션(partial transaction)으로 정확히는 “사용자가 원하는 미래 상태에 대해 사인한 메시지”입니다. 사용자가 원하는 특정한 미래 상태에 대해서만 허락의 의미로 사인한 메시지로, 인텐트 여러 개가 모여 하나의 트랜잭션을 이루게 됩니다.

인텐트라는 단어 자체가 “내가 하려는 의도, 원하는 것”을 의미함에 따라 다양한 상황적 예시를 통해 인텐트를 이해할 수 있습니다. 위의 그림에서 {State 0}은 인텐트를 실현하기 전의 초기 상태를 의미하며, {State 1}은 인텐트를 실현한 후의 상태를 의미합니다.

먼저 첫 번째 예시에서는 {0 fish, 1 chicken (0 마리의 생선, 1 마리의 닭)}을 소유한 S0 상태에서 “닭 한 마리를 물고기 한 마리로 교환”하고자 하는 인텐트가 “언어(Language)”라는 수단을 통해 실현되어 {1 fish, 0 chicken (1 마리의 생선, 0 마리의 닭)}이라는 S1 상태가 도출되었습니다.

또 다른 예시를 한 가지만 더 들어보자면, 마지막 네 번째 예시에서 초기 상태 S0는 {0 Pudgy Penguin, 1 ETH (0 개의 퍼지펭귄 NFT, 1 이더)}를 소유한 상태입니다. 이 때 “1 ETH를 1개의 퍼지 펭귄 NFT로 교환”하려는 인텐트가 “이더리움 상의 Wyvern 프로토콜(Wyvern on Ethereum)”이라는 수단을 통해 실현되어 {1 Pudgy Penguin, 0 ETH (1 개의 퍼지펭귄 NFT, 0 이더)}라는 최종 상태 S1으로 변환되었습니다.

즉, 사용자는 인텐트로 인해 원하는 “미래 상태(결과)”만 사인해서 메시지로 제시하게 됩니다. 이는 다르게 표현하면 사용자가 “특정 상태”에 대해서 승인한 것으로 볼 수 있으며 앞서 언급한 글을 통해 예상했다시피 인텐트는 “무엇”에 집중할 뿐 “어떻게”라는 과정에는 신경쓰지 않습니다. “어떻게”에 해당되는 트랜잭션의 생성과정을 제 3자에게 아웃소싱하게 되며 이에 따라 제 3자에게 트랜잭션에 대한 권한을 일부 허용해야 합니다. 이때 제 3자는 보통 솔버(Solver)라고 통칭하나 프로토콜마다 “리졸버(Resolver)” 혹은 “필러(Filler)”와 같은 상이한 명칭을 사용하기도 합니다. 본 글에서는 제 3자를 모두 “솔버(Solver)”라고 통일하겠습니다.

2.2. 인텐트 구조

인텐트가 네트워크에서 어떤 부분으로 어떻게 작동하게 되는지 그 구조를 알아봄으로써 두 번째 의문인 “(2) 인텐트는 어떤 로직으로 작동하는가”에 대해서 알아보겠습니다.

먼저 예시를 통해 구조를 이해해 보겠습니다. 위 그림의 로직을 정리하면 아래와 같습니다.

#1 유저가 사인된 인텐트 제출

먼저 유저가 본인이 원하는 결과에 대한 인텐트를 솔버 네트워크(혹은 인텐트 네트워크)에 제출합니다. 여기서 유저가 제출한 인텐트는 [ 1.5 이더와 2,500 다이 스왑(swap) ]이 됩니다.

#2 솔버가 해당 intent를 보고 최적의 경로 탐색

솔버가 해당 인텐트를 발견을 하고 함께 트랜잭션으로 묶을 수 있는 상대 인텐트(counterparty intent)를 찾아 최적의 경로를 탐색하게 됩니다. 위 그림에서 솔버는 [ 1.5 이더 ↔ 2,600 다이 스왑 ]이라는 1.5 이더와 2,600 다이를 스왑할 수 있는 경로를 찾게 되었고, 이에 따라 2,500 다이를 유저의 인텐트를 해결하는 데 사용하면 남은 100 다이는 본인이 가질 수 있게 됩니다.

#3 솔버가 서명된 인텐트가 포함된 트랜잭션을 이더리움 네트워크에 제출

해당 경로를 찾게 되면 트랜잭션을 기존 레이어 네트워크(위의 예시에서는 이더리움)에 제출하게 됩니다. 솔버가 찾은 경로가 1.5 이더를 2,600 다이로 스왑하는 것이었기에 트랜잭션에서 유저에게 2,500 다이를 주고 남은 100 다이는 인센티브로 본인 지갑으로 입금합니다.

조금 더 일반적인 구조를 살펴보겠습니다. 기존 트랜잭션은 제출 후 다른 경로없이 바로 결과(Outcome)가 도출되는 구조인 반면 인텐트는 그러지 않음을 확인할 수 있습니다.

인텐트의 워크플로우(WorkFlow)를 보면 다음과 같습니다.

#1 인텐트에 사용자가 서명을 하고 인텐트 풀에 제출

사용자가 각 프로토콜이 제시하는 인텐트 형태로 인텐트를 작성 후 서명을 해서 인텐트 풀에 제출합니다. 여기서 인텐트 풀이란 인텐트 네트워크라고 봐도 무방합니다.

인텐트 풀에 대해 조금 더 자세히 설명하자면, 프로토콜에 따라 그 형태와 명칭이 다르며 풀 내에서 인텐트는 Gossip 방법으로 전파되는 것이 일반적입니다. 인텐트 풀의 예시로 “Intent 101 (하)”에서 자세하게 설명할 Anoma의 Gossip layer가 있으며 인텐트 네트워크 혹은 인텐트 풀이라고 일컫습니다.

또한 인텐트 풀의 또 다른 특징은 Visibility 및 Access 설정이 가능하다는 점입니다. Public하게 운영할지, Private하게 운영할지를 설정할 수 있고 이와 더불어 권한이 있는 자만 접근 가능하게 할지(Permissioned), 권한을 설정하지 않고 모두 자유롭게 접근 가능하게 할지(Permissionless)에 대한 권한 설정도 할 수 있습니다. 이는 곧 인텐트 풀을 EOF(External Order Flow)처럼 운영할 수 있다는 점을 시사합니다.

#2 솔버가 인텐트풀에서 해당 인텐트를 보고 최적의 경로를 탐색

이 과정이 위 그림에서 회색박스로 표현된 부분으로 위 그림에선 matchmaking을 예시로 들고 있습니다. 솔버가 인텐트를 해결하기 위해 최적의 경로를 탐색하고 인텐트를 해소할 수 있는 상대 인텐트(Counterparty intent)를 탐색하게 됩니다.

이러한 과정을 솔빙(Solving)이라고 부르며, 솔빙 과정은 보통 off-chain에서 이뤄집니다. 체인 밖에서 솔루션인 경로를 탐색하게 되며 여러 경로 중 최적의 경로가 최종 선택되게 됩니다. 이때 사용자는 허용한 미래 상태에 대한 실행 경로를 생성할 권한을 솔버에게 일부 넘겨줘야 합니다.

#3 인텐트를 묶어 트랜잭션 생성 후 Mempool에 제출

2번 과정에서 언급한 상대 인텐트를 찾아 최적의 경로가 선정되면 여러 인텐트를 묶어 트랜잭션을 생성하게 됩니다. 솔버는 사용자에게 받은 일부 권한을 이용해 트랜잭션을 생성하게 됩니다. 이후의 과정은 일반적인 트랜잭션 생성 과정과 동일합니다. 해당 트랜잭션은 mempool에 제출되게 됩니다.

#4 트랜잭션 실행 후 결과(Outcome) 도출

이후 트랜잭션이 블록에 포함되어 실행되게 되면 제출한 인텐트가 해소되고 상태변화와 함께 결과가 도출됩니다..

2.3. 일반 트랜잭션과 인텐트 비교

인텐트에 대한 정의와 구조를 파악한 것을 바탕으로 기존 트랜잭션과 어떤 차이점을 지니는지 비교해보고 세 번째 의문인 “(3) 인텐트는 트랜잭션과 어떻게 다른가”에 대해서 정리해보겠습니다.

출처: https://x.com/CannnGurel/status/1663292583550803969?s=20

트랜잭션과 인텐트의 차이를 극명하게 보여주는 좋은 예시를 통해 먼저 이해를 해보고자 합니다.

위의 예시에서 보듯이 인텐트는 “20 달러로 저녁 8시에 우리 집 문 앞으로 하와이안 피자를 가져다줘.”라고 이야기를 하는 것이라면, 트랜잭션은 “너 스쿠터 타고 코너에 있는 도미노 피자에 가서 4번 아이템을 주문한 다음에 가져다줘. 20달러를 줄 건데, 18달러는 피자 값이고, 2달러는 가스비야.”라고 명령하는 것이라고 볼 수 있습니다.

즉, 트랜잭션에서 사용자는 “무엇(What)”이 아닌 “어떻게(How)”를 지정했으며, “도미노 피자(Domino)”라는 특정 “장소(Venue)”를 지정했습니다. 또한 이미 “배달원”이라는 “거래 상대방(Counterparty)”을 알고 있었으며, “2 달러”라는 가스비를 미리 지불했습니다. 마지막으로 트랜잭션은 결과에 대해 확신할 수 없습니다. 예를 들어, 4번 피자를 사기 전에 품절이 되거나 가스비가 상승해 지정한 2 달러로 충당할 수 없는 경우 등으로 인해 거래가 실패할 수도 있습니다.

이에 반해 인텐트에서 사용자는 “어떻게(How)”가 아닌 “무엇(What)”를 지정했으며 거래 과정에 대한 그 어떤 정보 — 도미노 피자, 아이템 4번, 20달러를 피자 값과 가스비로 배분 등 — 도 제공하지 않았습니다. 또한 저녁 8시를 특정하거나 집 문 앞으로의 배달이라는 조건을 추가하는 등 조금 더 복잡한 형태의 제약을 걸 수 있습니다.

앞서 설명했던 트랜잭션과 인텐트의 차이를 표로 정리하면 다음과 같습니다. 본 표는 인텐트를 최대한 일반화하여 제시하였으며 인텐트를 구현하는 프로토콜마다 디테일한 부분에서 차이가 발생할 수 있습니다.

표를 바탕으로 비교 대상 별로 비교하면 아래와 같습니다.

실행 성격

트랜잭션의 경우, 실행됨에 있어 단계적으로 진행이 되며 명령적입니다. 앞의 Can Gurel의 예시를 보면 알 수 있듯이 모두 명령형으로 경로를 지정해 전달되며 순차적으로 실행됨을 파악할 수 있습니다.

인텐트의 경우, commitment-based로 실행됨에 있어 commit이 되는지 아닌지로 결정이 되며, 어떠한 경로도 지정하지 않고 서술적으로 표현이 됩니다.

승인 대상

트랜잭션의 경우, 서명을 통해 승인하는 것은 “실행 경로”입니다. 즉, 결과가 아닌 “해당 결과를 위한 경로”를 승인하기 때문에 승인한 경로가 아니면 같은 결과를 내는 경로이더라도 트랜잭션이 실행되지 않게 됩니다.

인텐트의 경우, 서명을 통해 승인하는 것은 “미래 상태”입니다. 즉, 인텐트는 특정 경로에 대해 승인하지 않았고 이는 다르게 해석하면 승인된 “미래 상태”를 도출하는 어떠한 경로도 승인한 것으로 해석할 수 있습니다.

실행 결과의 경로 의존도

트랜잭션의 경우, 승인 대상이 실행 경로이기 때문에 실행 결과가 경로에 의존하게 됩니다. 즉, 결과가 아닌 해당 결과를 위한 경로를 승인하기 때문에 승인한 경로가 아니면 같은 결과를 내더라도 트랜잭션이 실행되지 않게 됩니다.

인텐트의 경우, 이와 다르게 승인 대상이 미래 상태이기 때문에 실행 결과가 경로에 의존하지 않습니다. 그 어떤 경로가 되더라도 무조건 승인한 미래 상태가 실행 결과로 도출되기 때문입니다.

실행 및 검증 범위

트랜잭션의 경우, 트랜잭션 자체의 실행과 검증이 모두 체인 위에서 진행이 됩니다.

인텐트의 경우, 실행은 체인 밖에서 진행이 됩니다. 이는 앞서 언급했던 솔빙 과정이 오프 체인에서 진행된 것을 생각하면 쉽게 이해할 수 있습니다. 이후, 인텐트에 대한 검증은 트랜잭션과 마찬가지로 체인 위에서 진행됩니다.

거래 상대방

트랜잭션의 경우, 거래 상대방을 알고 있습니다. 트랜잭션을 생성할 때 어떤 디앱 혹은 어떤 블록체인이 본인의 트랜잭션을 수행하게 되는 지 알고 있고 이들이 곧 거래 상대방이 됩니다.

인텐트의 경우, 거래 상대방을 알 수가 없습니다. 사용자가 제출하는 것은 원하는 미래 상태를 승인한 인텐트 메세지이며 따라서 어떠한 디앱 또는 어떠한 체인을 통해 수행이 되는 지 그 거래 상대방은 알 수가 없습니다.

상태 변화

트랜잭션의 경우, 트랜잭션이 실행된 후의 상태 변화에 있어 특정 범위가 정해져 있지않습니다. 다시 말하면, 트랜잭션의 결과가 지정된 형태가 아닌 임의적으로 도출된다는 것을 의미합니다. 실행 결과가 될 수 있는 값의 범위가 비교적 넓으며 트랜잭션의 종류에 따라 그 결과의 범위 또한 상이합니다. 이에 상태 변화가 임의적이라고 할 수 있습니다.

인텐트의 경우, 인텐트가 실행된 후의 상태 변화는 이분법적입니다. 즉, 인텐트는 어떠한 인텐트든 종류에 관계없이 모두 “성공” 혹은 “실패”라는 두 가지 상태만을 도출하며 이에 따라 상태 변화가 이분법적이라고 할 수 있습니다.

Settlement

트랜잭션의 경우, Settlement가 보장됩니다. Settlement란, 트랜잭션이 체인 위의 블록에 추가되어 finalize되는 것을 의미합니다. 트랜잭션이 생성되어 제출되었다는 것은 일단 해당 경로가 유효한 경로이며 이를 네트워크 위에 올리는 것이 성공했다는 것을 의미합니다. 즉, 트랜잭션의 실행이 늦춰질 수는 있어도 결국 Settle이 된다고 생각하는 것이 일반적입니다.

인텐트의 경우, 부분적인 트랜잭션으로 완성되지 못한 트랜잭션입니다. 즉, 트랜잭션이 아니며 인텐트가 제출되어도 상대 인텐트를 찾지 못하거나 체인 상에서 실행될 수 있는 최적의 실행 경로를 찾지 못하면 인텐트는 트랜잭션으로 만들어지지 못하고 이는 곧 Settle되지 못함을 의미합니다. 따라서 인텐트는 트랜잭션과 다르게 Settlement를 보장할 수 없습니다.

Settle 주체

트랜잭션의 경우, 유저가 트랜잭션을 직접 생성하여 서명을 하게 되므로 Settle 주체를 유저라고 볼 수 있습니다.

인텐트의 경우, 앞서 언급했던 것처럼 솔버(Solver)라고 불리는 제 3자에게 실행 권한을 넘겨주기 때문에 솔버가 인텐트를 트랜잭션에 포함시키게 되고 곧 Settle 주체가 됩니다.

독립성

트랜잭션의 경우, 다른 트랜잭션의 존재 여부에 상관없이 독립적으로 생성될 수 있습니다.

인텐트의 경우, 특정 인텐트가 Settle되어야만 또 다른 특정 인텐트도 Settle될 수 있다는 점에서 서로 종속적입니다. 상대 인텐트가 Settle되어야만 본 인텐트도 Settle될 수 있다는 점을 생각하면 이해하기 쉬울 거 같습니다.

참고

비교하는 부분의 내용을 이해함에 있어 참고하면 도움이 될 내용을 트랜잭션과 인텐트로 나뉘어 각각 적어두었습니다.

2.4. 인텐트 종류

인텐트에 대한 개괄적인 개념을 바탕으로 그 종류를 조금 더 자세하게 분류할 수 있습니다. 인텐트를 나누는 기준은 여러 가지가 될 수 있지만 본 글에서는 크게 2가지 기준 — (1) 조건의 복잡도 및 지속성과 (2) 범용성 — 에 따라 분류를 진행했습니다.

(1) 조건 복잡도 및 지속성에 따른 분류

먼저 조건의 복잡도 및 지속성에 따른 분류입니다. 조건의 복잡도와 지속성에 따라 3가지 — Simple Intent, Conditional Intent, Continuous Intent — 로 분류했습니다.

Simple Intent

Simple Intent란 어떠한 조건도 명시하지 않은 형태의 인텐트를 의미합니다. 조건없이 원하는 요구사항만 명시되어 있는 게 일반적이며, 예로 지갑에서 다른 지갑으로 암호화폐 전송이나 일반적인 암호화폐 구매가 있습니다.

Conditional Intent

Conditional Intent는 특정 조건을 명시하여 해당 조건을 충족해야지만 실행되는 인텐트를 의미합니다. 이 경우는 조건이 단발적이며 지속되지 않습니다. 따라서 조건이 지속적이지 않고 한 번만 충족하면 되며, 조건이 충족되었을 시 인텐트의 실현이 완료됩니다.

Continuous Intent

Continuous Intent는 이름에서 유추할 수 있다시피 지속적인 작업을 실행하기 위한 인텐트로 조건이 지속적으로 충족되어야 하며 이로 인해 인텐트가 지속적으로 유지되게 됩니다. 예시로 정기 결제를 들 수 있습니다. A라는 사람이 매월 15일마다 월급을 받고 월급날마다 1 이더(ETH)씩 구매를 하는 경우, A는 다음과 같은 인텐트를 제시할 수 있습니다.

“매달 월급날마다 들어오는 월급으로 1 이더로 구매(혹은 스왑)해줘“

이 경우 인텐트는 A가 더이상 원하지 않거나, 조건을 충족되지 못하게 될 때까지 지속성을 가지고 매달 실행되게 됩니다. 인텐트에 있어서 매달 확인하는 조건은 크게 2가지가 됩니다.

(1) 오늘이 15일인가

(2) 1 이더를 구매(혹은 스왑)할 만큼의 충분한 재산을 지갑에 소유하고 있는가

위 두 가지 조건을 매달 확인하게 되고 조건이 충족했을 시 A가 의도한 인텐트는 매달 실행되게 됩니다. 이러한 형태의 인텐트를 Continuous Intent의 예시라고 할 수 있습니다.

(2) 범용성에 따른 분류

다음은 구현된 인텐트 구조의 범용성에 따른 분류입니다. 범용성에 따라 3가지 — App-specific Intent, Wallet-level Intent, General purpose Intent — 로 분류했습니다.

App-specific intent

App-specific intent의 경우, 특정 어플리케이션에서만 사용할 수 있도록 커스터마이즈되어 구현된 인텐트를 의미합니다. 즉, 범용성이 제일 적은 혹은 거의 없다고 볼 수 있는 형태의 인텐트입니다. 보통 이러한 형태의 인텐트는 어플리케이션 단위로 예시를 들 수 있으며 현재 가장 사용이 많이 되고 있는 예시로 CoW Swap이나 1inch Fusion을 들 수 있습니다. 해당 프로토콜은 자체적으로 인텐트 아키텍처를 구현하여 서비스를 제공하는 데 있어서 필요한 로직이 작동할 수 있도록 합니다. 대게 어플리케이션 이용자는 원하는 금융 거래를 인텐트의 형태로 제시할 수 있으며 이에 대한 요구를 Solving하는 과정(즉, Match Making 과정)에서 솔버(Solver)를 이용하게 되며 프로토콜마다 상이하게 구현합니다.

Wallet-level intent

조금 더 범용적으로 사용할 수 있는 인텐트의 형태로 Wallet-level intent가 있습니다. 해당 인텐트는 생태계에서 전반적으로 사용되는 특정 규격의 형태 또는 지갑의 형태로 구현되며 이의 예시로 ERC-4337과 그 구현체인 Account Abstraction을 들 수 있습니다. 또한 “인텐트 101 (하)”에서 상세하게 분석할 Essentials라는 프로토콜이 Wallet-level intent를 구현하고 있는 프로토콜로 ERC-7521을 제시했습니다.

General purpose intent

가장 범용성 있는 인텐트로 General purpose intent가 있습니다. 해당 인텐트의 경우, 여러 체인에 대한 상태를 기반으로 광범위하게 사용 가능하며 인텐트의 인프라, 즉, 전반적인 아키텍처 자체를 구현한 구현체라고 생각하면 됩니다. 대체로 자체 체인의 형태로 구현이 되며, 그 예시로는 Solution으로 Intent-Centric Architecture를 제공하는 SUAVE 혹은 “인텐트 101 (하)”에서 상세하게 분석할 Anoma라는 프로토콜을 들 수 있습니다.

2.5. 인텐트 분석 지점과 이에 기반한 프로젝트 비교 분석

지금까지 인텐트의 정의, 구조, 트랜잭션과의 차이점, 그리고 종류에 대해서 알아보았습니다. 앞서 언급했던 내용들을 기반으로 인텐트를 구현하고 있는 프로젝트를 바라볼 때 (1) 분석 지점을 어떻게 가져가야 하는 지 와 (2) 제시한 지점을 통해 프로젝트에서 실제로 어떻게 분석이 이루어지는 지에 대한 예시를 통해 네 번째 의문인 “(4) 인텐트의 현재 주소는 어떻게 되는가”에 대해서 확인해보고자 합니다.

(1) 인텐트를 바라보는 5가지 분석 지점

인텐트를 구현하고 있는 프로젝트를 바라볼 때 아래와 같은 다섯 가지 지점을 가장 중요한 분석 지점들로 꼽았습니다. 하위에 제시하고 있는 분석 지점들은 모두 서론에서 언급했던 의문점 2번에 대한 상세한 답변으로 이어질 수 있으며 파트 3에서 언급한 트랜잭션과 인텐트의 비교분석에서 비교대상에 대한 구체적인 내용을 제시합니다.

Intent Expression and Authorization

“인텐트의 표현 및 권한부여”를 분석함으로써 확인할 수 있는 부분은 다음과 같습니다.

(1) 이용자가 프로젝트 내에서 어떻게 인텐트를 표현하게 되는 지

(2) 이용자가 인텐트로 어느 수준까지 원하는 결과를 표현할 수 있는지와 인텐트의 종류

(3) 이용자가 어떤 권한을 제 3자에게 넘겨줄지

Solver Candidates

“솔버 선발 방법”을 분석함으로써 확인할 수 있는 부분은 다음과 같습니다.

(1) permissioned / permissionless 여부 : 즉, 솔버를 허가를 받아야할 수 있는 지, 허가 없이도 할 수 있는 지

(2) 솔버가 되기 위한 특정 조건이 있는 지

(3) 특정 분야에 집중하는 솔버와 이로 인한 다양한 유형의 솔버가 존재하는 지

Solving Process

“솔빙 과정”을 분석함으로써 확인할 수 있는 부분은 다음과 같습니다.

(1) 어떤 과정(path)으로 solving하는 지

(2) 인텐트를 충족한다는 것을 어떻게 결정하는 지

Solver Selection

“솔버 선발 과정”을 분석함으로써 확인할 수 있는 부분은 다음과 같습니다.

(1) 여러 솔버 중 Winner selection은 어떻게 할 건지

(2) 경쟁을 함에 있어 Winner-takes-all 방식인지

Validation and Settlement

“검증 및 Settlement 과정”을 분석함으로써 확인할 수 있는 부분은 다음과 같습니다.

(1) Solver의 임무 완수 확인 방법

(2) settlement 방법 : 이용자와 솔버 간 정산이 어떻게 이루어지는 가

(2) 프로젝트 분석 예시

위 (1)번에서 제시한 다섯 가지 분석 지점을 바탕으로 기존의 있는 인텐트 구현 서비스를 개괄적으로 분석해보고 실제로 어떻게 분석 지점을 통해 분석하게 되는 지 그 예시를 확인하고자 합니다. 비교 분석할 두 가지 프로토콜은 CoW Swap과 1inch Fusion으로 두 프로토콜 모두 동일한 서비스를 제공하고 있습니다.

각 분석 지점 별로 분석해보면 아래와 같습니다.

Intent Expression and Authorization

인텐트의 표현과 권한의 부여에 있어 두 서비스 모두 동일한 방식을 채택하고 있습니다. 모두 플랫폼의 인터페이스를 통해 사용자가 인텐트를 표현할 수 있게 하며, 표현할 수 있는 인텐트의 종류는 희망 거래 및 지정가 주문이 됩니다. 또한 권한 부여에 있어서도 동일한 방식을 취하고 있는데, 모두 오프 체인 메시지 혹은 트랜잭션에 서명을 함으로써 수행 권한을 제 3자에게 부여할 수 있도록 하였습니다.

마지막으로, 인텐트를 통해 표현할 수 있는 요소 중 하나인 가스비 대납에 대해 native token인 이더(ETH)가 아닌 거래 토큰으로 대체 가능합니다.

Solver Candidates

솔버 선발 방식에 있어 두 서비스는 상이한 방법을 가지게 됩니다. 먼저, CoW Swap의 경우, 화이트리스트를 통해서 선발하게 됩니다. 화이트리스트에 포함되기 위해서 카우 스왑의 솔버는 1백만 달러(USDC & COW)의 본딩 풀을 생성하거나, CoW DAO 본딩 풀 또는 Gnosis DAO 본딩 풀에 포함되고 CoW DAO의 기준을 충족해야 합니다.

반면 1inch Fusion의 경우, 허가된 방식으로 솔버 선발을 운영하고 있습니다. 즉, 솔버는 사전에 등록 해야하고, KYC 절차를 거쳐야 하며, 주문 수수료를 충당할 수 있는 충분한 잔액을 지갑에 유지해야 합니다.

Solving Process

솔빙 과정에 있어 두 서비스 모두 동일한 방식을 채택하고 있습니다. 솔버는 기존 배치를 평가하여 거래 또는 지정가 주문을 체결할 수 있는 최적의 가격을 제공할 수 있는 일치된 호가(CoW)를 식별합닌다. 이때, 유동성, 호가창 spread, 가격 슬리피지 등 다양한 요소를 고려하여 트레이더에게 최적의 체결을 보장하는 것이 솔버의 몫이며 솔버는 유니스왑과 같은 다른 AMM을 직접 탐색하거나 1inch와 같은 DEX 애그리게이터를 활용하여 가장 유리한 가격과 경로를 찾을 수도 있습니다.

Solver Selection

솔버를 선정하는 과정에 있어 CoW Swap에서는 일괄 경매(Batch auction)을 통해 외부 솔버가 결정한 최적의 가격으로 거래가 체결되어 트레이더의 잉여를 극대화하는 방식을 채택하고 있습니다. 즉, 가장 최적의 솔루션을 제공하는 솔버가 선택되게 됩니다. 반면, 1inch Fusion의 솔버 경쟁은 더치 경매 방식을 이용하여 솔버를 선정하고 있으며 솔버가 스테이킹한 1인치 토큰이 중요한 요소가 되어 조금 더 제한적인 방식을 채택하고 있습니다.

Validation and Settlement

검증 및 정산 프로세스는 솔버가 거래 또는 지정가 주문을 실행한 후에 발생합니다. 두 서비스 모두 동일한 검증 및 정산 방식을 가지는데 일단 솔버는 settlement contract에 있는 ERC20 approval을 활용하여 사용자를 대신해 토큰을 이동할 수 있습니다. 솔버가 트랜잭션을 수행한 후, settlement contract은 사용자의 의도가 담긴 서명을 확인하고 체결이 지정된 지정가 및 수량과 일치하는지 확인함으로써 검증을 하게 됩니다. 이는 EIP-1271에 의해 활성화됩니다. 이 검증을 통해 의도한 거래 또는 지정가 주문이 성공적으로 완료되었음을 확인할 수 있으며 검증이 완료되면 settlement contract은 거래에 참여한 솔버와 사용자에게 적절한 자금을 배분함으로써 정산 과정을 마무리 짓습니다.

3. Why Intent & Risk of Intent

3.1. Why Intent

기존의 시스템에서 인텐트를 왜 사용하는 가를 생각해본다면 크게 3가지 이유를 들 수 있습니다.

먼저 첫째, 효율성 측면을 무시할 수 없다는 점입니다. 인텐트는 이용자의 요청에 대한 연산을 솔버 네트워크에 아웃소싱함으로써 연산 리소스를 줄일 수 있는데, 이는 이용자의 리소스 뿐만 아니라 디앱 자체의 연산 리소스를 줄일 수 있게 되고 이는 전체적인 시스템의 측면에서 효율성의 향상이라고 보입니다. 또한 이용자의 입장을 생각해보면, 인텐트를 이용함으로써 기존에는 불가능했던 복잡한 형태의 요청이 가능해집니다. 가령 조건부 거래를 하는 경우나 원하는 요소를 한 번에 요청하는 경우를 들 수 있습니다.

두 번째로, 사용자의 경험이 향상된다는 점입니다. 이용자는 블록체인과 직접 소통하지 않고도 원하는 행위를 수행할 수 있으며 이에 대해 일부 권한을 내어주지만 이는 본인 자산에 대한 커스터디 권한과는 관련이 없기 때문에 본인 자산에 대한 권한 또한 잃지 않습니다. 이러한 점은 현재 블록체인 서비스가 제공할 수 없는 부분이며 인텐트를 통해 일부 해결할 수 있는 부분이기도 합니다. 또한 이용자는 기존의 복잡한 과정 — 필요한 데이터를 직접 지정해주는 행위 등 — 없이 단지 원하는 상태를 명시함으로써 거래를 할 수 있습니다. 앞서 설명한 두 가지 경우 모두 사용자 경험을 향상시키는 요인이 되며 아직 비교적 사용자 경험이 부정적인 블록체인 서비스에 사용자 경험이 향상됨으로써 인텐트가 긍정적인 작용을 할 것으로 비춰집니다.

셋 번째로, 인텐트가 도입됨으로써 거래 형태 자체가 편리해집니다. 이 문장이 의미하는 바를 조금 더 구체적으로 풀어보면, 기존의 AA와 비슷한 환경을 제공하고 있다고 생각이 되지만 single domain에 대한 요청 처리만 가능했던 AA에 비해 인텐트는 multi domain에 대한 요청 처리 가능해집니다. 또한 애초에 AA와 인텐트는 그 목적성이 상이하기 때문에 현재 거래 형태를 편리하게 해주는 요소가 필요한 것으로 보입니다. 이 뿐만 아니라 인텐트는 크로스체인 거래도 편리하게 합니다. 크로스체인 거래가 필요한 거래 형태 자체도 트랜잭션을 생성함에 있어 솔버 네트워크에 아웃소싱되기 때문에 단지 인텐트 제출을 통해 크로스체인 거래가 가능해지게 됩니다.

3.2. Risk of Intent

모든 기술은 양날의 검이듯, 인텐트를 이용하는 이유와 상반되게 이용했을 시 발생할 수 있는 문제점을 생각해본다면 아래와 같이 3 가지 가능성을 들 수 있습니다.

우선, 솔빙 과정에서 신뢰성 이슈가 발생할 수 있다는 점입니다. 위 글에서 언급했다시피 솔버가 솔루션을 찾는 과정이 오프체인에서 발생한다는 점에 있어서 솔빙 과정을 믿는 것은 전적으로 이용자의 신뢰 문제로 이어집니다. 이에 따라 신뢰성 이슈가 발생할 수 밖에 없는 구조가 되게 됩니다. 물론 솔버가 악의를 가지더라도 이용자가 허락한 최종상태가 아니라면 승인되지 않는다는 안전 장치가 있지만 이 외에도 악용할 방법은 존재한다고 생각하기 때문에 첫 번째 위험성으로 솔빙 과정의 신뢰성 이슈를 제시했습니다.

다음으로, 솔버의 독점 가능성이 제기됩니다. 인텐트는 특정 태그(tag)가 부착되게 되며 솔버들이 솔버 네트워크에서 인텐트에 대한 태그를 바탕으로 해당 인텐트를 해결할지를 선택할 수 있습니다. 여기서 태그(tag)란, 인텐트의 종류에 대한 라벨링으로, 특정 어떠한 거래에 관련된 것인지 태그를 붙일 수 있게 됩니다. 이때, 솔버가 특정 태그에 대해서 독점하게 된다면 해당 태그와 관련된 솔루션은 전적으로 독점한 솔버에 의해 결정이 되게 되며 이는 탈중앙성과 거리가 멀어질 뿐더러 향후 해당 태그와 관련된 인텐트를 솔빙하는 과정에서 해당 솔버가 나쁜 의도를 표출하는 방향으로 이어질 수도 있습니다.

마지막으로, 인텐트의 실행 여부를 확정할 수 없다는 점에 있어 문제점을 제시합니다. 앞서 설명했던 인텐트의 구조를 다시 언급해 보면, 인텐트는 Counterparty discovery를 통해 트랜잭션이 되게 됩니다. 이러한 인텐트의 구조상, 인텐트는 실행 여부에 대해 확정 지을 수 없게 됩니다. 만약 솔버가 특정 인텐트에 대한 상대 인텐트 (Counterparty intent)를 찾지 못하고, 경로를 제시하지 못하면 해당 인텐트는 영원히 제출된 상태로 남으면 트랜잭션으로 묶이지 않습니다. 하지만 이 과정에 있어 이용자는 처음부터 이 부분에 대한 확정을 할 수가 없습니다.

4. 결론

지금까지 인텐트에 대한 정의, 구조, 트랜잭션과의 차이점, 종류 그리고 분석 지점에 대해서 알아봤습니다. 알아본 내용을 바탕으로 인텐트의 사용 이유와 향후 제기될 수 있는 문제점을 알아보며 글의 본론을 마무리 지었습니다. 인텐트에 대한 리서치를 진행하고 다양한 분들과 논의를 하면서 인텐트에 대해 개인적으로 생각을 해보았던 부분들이 존재하고, 이러한 의견에 대해 제시하는 것으로 결론을 마무리 지으려고 합니다.

필자는 현재 인텐트의 꽤 많은 구현제가 존재한다고 생각합니다. 이에 따라 사람들은 이미 인텐트에 노출이 되어 있으나 자각하지 못하고 있습니다. 일례로 CoW Swap과 1inch와 같은 DEX Aggregator를 들 수 있는데 이 두 종류도 일종의 인텐트라고 생각이 되지만 인텐트라는 단어를 사용한 것이 최근이기에 인텐트라고 확실하게 말하지 못하는 부분이라고 생각됩니다. 이처럼 인텐트는 향후 블록체인 생태계에 알게 모르게 더 많이 스며들 것이라고 예상하지만, 이 부분에 있어 지금은 분명한 한계점이 존재한다고 생각합니다. 바로 현재까지의 구현물은 바로 Intent-specific한 어플리케이션이라는 점입니다. 즉, 앞서 제시했던 프로젝트들과 같은 현재까지의 구현물은 특정 기능만을 수행하는 인텐트를 기반으로 하는 어플리케이션입니다. Intent-specific한 어플리케이션이 한계점이라고 생각하는 이유는 바로 멀티 체인 환경에서 확장성(Scalabililty)가 없기 때문입니다. Intent-specific한 어플리케이션은 우선 Single-domain에 대한 인텐트 구현을 의미하는 것으로 특정 환경에 대한 인텐트만 구현한 것이 일반적입니다. 이는 곧 상위레벨에서 반복적인 문제점이 발생한다는 것을 의미합니다. 문장에 대한 설명을 덧붙이자면, Intent-specific한 어플리케이션으로 1inch(DEX Aggregator)를 들 수 있습니다. 1inch로 인해 최적의 Swap이 가능해졌지만, 시간이 지남에 따라 굉장히 많은 DEX Aggregator가 등장했고 이에 따라 사용자는 DEX Aggregator 중에서 또 제일 좋은 Aggregator를 찾게 되었으며 다양한 체인의 등장으로 체인 별로 또 확인이 필요합니다. 이는 곧 DEX Aggregator의 Aggregator 출현으로 이어지지만 이는 곧 또 똑같은 문제가 반복될 것임을 암시한다고 생각합니다. 따라서 이러한 문제점이 바탕이 되어 Anoma와 같은 General purpose를 가진 Intent architecture의 등장으로 이어진 것이라는 결론을 내렸습니다.

다만 여전히 General purpose Intent에서 언급했던 Intent-centric architecture가 등장한다고 하더라도 migration에 대한 이슈로 인해 가까운 시일이 아닌 “먼 미래”에 많이 사용될 것이라고 예상하고 있습니다. 이에 따라 먼 미래에는 블록체인에 대한 접근성도 좋아질 것이며 더 대중적인 dApp 나오지 않을까 기대해봅니다. 또한 인텐트 중심의 구조로 바뀌게 되면 다양한 변화가 초래될 것이라고 생각하는데, 그 중 하나가 롤업 생태계에 대한 변화입니다. 현재 논의가 되고 있는 롤업 생태계의 공유시퀀서의 역할이 매우 중요해질 것으로 예상됩니다. 공유시퀀서는 L2 미들웨어 블록체인으로 공유시퀀서 네트워크에 참여하는 모든 L2 트랜잭션을 공유해서 처리할 수 있다는 장점이 있습니다. 이에 대해서 크로스체인 거래가 필요한 경우 브릿지를 사용하지 않고 (두 체인이 모두 공유시퀀서 네트워크에 참여했다면) 한 번에 해결할 수 있고, 이 부분을 염두해두고 솔버의 솔빙 과정을 생각했을 때 인텐트의 솔루션이 공유시퀀서를 통해 해결될 수 있다고 생각합니다. 특히 공유시퀀서를 통한 트랜잭션 또한 인텐트의 조건과 비슷한 요소를 지니고 있어 그 결이 비슷해보입니다. 이에 따라 공유 시퀀서의 사용성 또한 증가할 것으로 예상하게 되었는데 해당 생각에 대한 근거는 앞서 제시했다시피 거래의 형태가 다변화될 수 있고 편리해짐에 따라 크로스체인 거래와 같은 부분이 활성화될 것이라고 생각했기 때문입니다.

이 외에 예상되는 또 다른 변화는 MEV 이슈입니다. 솔버는 리소스를 사용하여 솔루션을 도출하며 해당 업무에 대한 보상을 받기 위해서 솔버 인센티브가 본인이 사용한 비용보다 커야합니다. 하지만 솔루션에 대한 프론트러닝이 발생하게 되면 리소스에 대한 보상을 받을 수 없고 이는 솔버가 솔루션을 제출할 유인이 감소하는 원인이 됩니다. 솔버 생태계가 발전하지 않으면 인텐트 자체의 퀄리티도 보장할 수 없기 때문에 해당 문제에 MEV 이슈에 대한 관리가 필요해보이며 실제로 현재 논의가 되고 있습니다. 가령 Anoma에서는 인텐트를 암호화하는 방식을 제공하기도 합니다. 또한 솔버가 현재 블록 빌딩 환경의 Searcher(서처)와 역할이 비슷한 것으로 보아 서처의 역할도 같이 하게 될 수도 혹은 서처가 솔버의 역할을 대신 할 수도 있다고 생각됩니다.

인텐트가 단지 하나의 파도로 지나갈 것인지와 같은 Psyop 논란이 분분하지만 그럼에도 논의를 해보는 것은 충분히 의미가 있다고 생각합니다. 특히 인텐트는 해외에서는 꽤 예전부터 논의되어 왔던 주제이지만 한국에서는 아직 초기 단계라고 생각이 되어 본 글이 인텐트에 대한 논의에 조금의 기여를 할 수 있기를 바라는 마음으로 이 글을 마무리하고자 합니다.

두 번째 글인 “Intent 101 (하)”에서는 Essential과 Anoma를 통해 Intent-centric Architecture를 구현한 프로젝트에 대한 배경과 구조를 자세히 설명하고 있으니 이어지는 글도 많은 관심 부탁드립니다.