2023 계정 추상화 톺아보기 2편

1. ERC-4337은 End Solution이 아니다

1.1. 현재 ERC-4337의 문제점

ERC-4337은 프로토콜 변화 없이 계정 추상화를 구현하자는 초기의 목적을 달성하는 데에는 성공하였습니다. 그러나 앞선 2023 계정 추상화 톺아보기 1편에서 이야기했듯이, 아직까지 계정 추상화 및 ERC-4337의 도입은 미진한 수준입니다. 그 이유 중 하나는 ERC-4337이 아직까지 완벽한 솔루션이 아니라는 것에 있습니다. 현재 ERC-4337은 다음과 같은 세 가지의 단점이 존재합니다.

1.1.1. User Operation의 높은 비용

ERC-4337에서 트랜잭션 대신 사용되는 UserOp의 비용은 일반 트랜잭션보다 2~3배 이상 비쌉니다. 이는 원래 프로토콜 단에서 수행되었던 서명, 논스 등의 검증을 별도의 멤풀에서 수행하기 위한 비용이 추가되기 때문입니다. 실제로 User Operation의 처리는 다음과 같이 매우 복잡한 검증 과정을 요구합니다.

따라서 이더리움 내에서는 상기한 비용 문제로 인해 ERC-4337이 거의 사용되지 않고 있으며, ERC-4337이 나온 이후로 이더리움 네트워크 내에서 발생한 총 UserOp은 약 2만 개 수준에 머무르고 있습니다.

한편, 이더리움을 Layer 1으로 설정한 옵티미스틱 롤업들에서도 트랜잭션 비용 구조로 인한 문제가 두드러지고 있습니다. 일반적으로 옵티미스틱 롤업의 트랜잭션 비용은 다음과 같이 두 부분으로 구성됩니다.

• L2 실행 비용: 트랜잭션을 L2에서 실행하고, 상태 변화를 기록하는 데에 청구되는 비용입니다. ZK 롤업의 경우 ZK 증명을 생성하는 비용도 포함됩니다.
• L1 보안 비용: 트랜잭션을 calldata의 형태로 L1(이더리움)에 제출하는 비용입니다. 이때 해당 비용은 calldata의 길이에 비례합니다.

ERC-4337의 UserOp은 2번의 비용에서 큰 비용을 소모하게 됩니다. UserOp의 calldata는 다음과 같이 일반 트랜잭션에 비해 매우 길이가 길기 때문입니다.

기존 트랜잭션이 [사용자 → 컨트랙트 A]라는 호출 경로를 가지고 있었다고 한다면, ERC-4337에서는 [Bundler → EntryPoint 컨트랙트 → 사용자의 컨트랙트 계정 → 컨트랙트 A]의 형태로 복잡한 호출 경로를 가지고 있습니다. 또한 Paymaster를 사용하려는 경우 이에 대한 정보도 트랜잭션 내에 담아주어야 합니다. 즉, 이러한 추가 정보들을 표현하기 위해 트랜잭션의 길이가 길어질 수밖에 없는 것입니다. Arbitrum에서 UserOp의 평균 가스비를 확인해 보면 이에 따른 비용이 생각보다 크다는 것을 알 수 있습니다.

Biconomy에서 배포한 컨트랙트 계정의 경우, ETH를 전송하는 아주 단순한 액션임에도 불구하고 Arbitrum에서 User Operation 비용이 최대 1달러 이상 드는 시기도 존재하였습니다. 또한 UserOp이 ERC20 등 외부 컨트랙트와 상호작용하는 경우, 다음과 같이 비용은 더욱 비싸집니다.

위 ERC20 토큰 전송의 경우, 작년 12월을 기준으로 Biconomy와 ZeroDev의 계정 모두 한 User Operation 당 평균 1달러가 넘는 비용을 요구하였습니다. 물론 만약 Dencun 업데이트로 EIP-4844가 적용된다면 절대적인 가스비 자체는 감소하겠지만, UserOp은 여전히 일반 트랜잭션의 평균 가스비의 2~3배에 해당하는 비용을 소모합니다.

UserOp의 비용이 비싸다면, 컨트랙트 계정의 사용자도 부담이 될 뿐만 아니라, paymaster를 통한 가스비 대납을 제공하는 애플리케이션들도 부담이 될 수밖에 없습니다. 즉, L1이든 L2든 UserOp의 비용을 줄일 수 있는 대안이 필요합니다.

1.1.2. MEV 중앙화와 검열

이더리움의 밸리데이터들은 블록 내 트랜잭션 순서를 조정할 권한을 가지고 있기 때문에, 이를 이용한 차익거래, 프론트러닝, 샌드위치 공격 등으로 MEV(Maximal Extractable Value)라고 불리는 수익을 얻을 수 있습니다. 만약 거래 순서를 조정할 수 있는 권한이 특정 밸리데이터들에게만 돌아간다면, 해당 밸리데이터가 MEV 시장을 독점할 뿐만 아니라 트랜잭션 검열과 같은 문제가 발생할 수 있습니다.

따라서 이더리움은 PBS(Proposer-Builder Separation)와 crList(censorship resistance lists)라는 솔루션을 통해 MEV 시장 내 탈중앙화와 검열 저항성을 갖추려고 하고 있습니다. 그런데 ERC-4337에서 사용되는 멤풀은 오프체인에 존재하며 별도의 검증을 거치기 때문에, 프로토콜 내 PBS와 crList가 구현되어도 그 효과를 보지 못하게 됩니다. 이에 따라 Bundler가 MEV 수익을 독점하거나, 사용자의 User Operation이 검열될 가능성이 존재합니다. 물론 해당 멤풀에서도 ERC-4337 용으로 별도의 PBS와 crList를 구현할 수도 있겠지만, 이는 추가적인 복잡성을 낳기 때문에 바람직하지 않습니다.

또한 현재 Bundler들이 permissionless한 구조를 택하고 있지 않기 때문에, 현재 이 문제는 더욱 바람직하지 못한 상황에 있습니다. 현재까지 Bundler 제공자들 중 퍼블릭 멤풀을 통해 누구나 번들링 작업에 참여할 수 있도록 구현해 둔 곳은 존재하지 않습니다. 즉, 현재 ERC-4337 생태계는 중앙화된 Bundler에 의존하고 있고, 사용자들의 User Operation은 단일 번들러가 악의적으로 MEV를 추출하거나 검열하지 않는다는 신뢰 가정 하에서 제출되고 있습니다.

1.1.3. 컨트랙트 계정으로의 낮은 Migration Rate

ERC-4337이 호환되는 지갑도 점점 많이 출시되고 있고, dApp 생태계에서도 ERC-4337을 통한 다양한 시도가 이루어지고 있습니다. 그러나 이를 쓰는 사용자의 리텐션은 그리 좋지 못한 상황입니다.

위 자료에서 모든 경우 지갑을 만든 지 한 달(4주)이 넘어가면, 해당 지갑을 다시 사용하는 비율이 1%를 넘지 않는다는 것을 확인할 수 있습니다.

이 문제는 크게 두 가지 부분에서 기인한다고 볼 수 있습니다.

1) 킬러 앱의 부재
위 결과의 원인을 애플리케이션에서 찾는다면 다음과 같은 이유들이 있을 수 있습니다.

• 계정 추상화를 사용하는 앱이 사용자에게 큰 매력을 끌지 못했습니다.
• 애플리케이션이 계정 추상화를 이벤트용으로 단기간에만 사용하였습니다.

실제로 ZTX와 같은 앱들은 ERC-4337 지갑을 이벤트용으로만 사용하여, 지갑 당 평균 UserOp 수가 거의 1에 근접한 것을 확인할 수 있습니다.

2) 앱 안에 갇혀버린 컨트랙트 계정
위에서 보았던 계정 추상화를 사용하는 앱들의 공통점은, 단 한 가지 지갑 제공자만 지원한다는 점입니다. 이로 인해, 사용자들은 컨트랙트 지갑을 여러 앱에서 사용하는 것이 아니라 각 앱마다 서로 다른 컨트랙트 지갑을 생성해서 사용하게 됩니다. 이에 따라, 사용자들은 한 앱에서 생성된 지갑을 지속적으로 사용하기 어려운 환경에 놓이게 됩니다.

이러한 문제점의 원인으로 꼽을 수 있는 것은 컨트랙트 지갑 표준의 부재입니다. 만약 Biconomy와 ZeroDev의 계정이 서로 호환된다면, 애플리케이션 입장에서 두 지갑 SDK 모두를 통합하기 매우 쉬울 것입니다. 그러나 안타깝게도 현재의 지갑 제공자들은 서로 호환되지 않습니다. 이에 따라 컨트랙트 지갑의 표준이 필요한 상황입니다.

2. ERC-4337 내에서의 개선

이러한 문제들을 ERC-4337 내에서 해결하고자 하는 움직임들이 존재합니다. 크게 아래와 같이 세 가지로 나눌 수 있습니다.

2.1. Bundler 표준과 퍼블릭 멤풀

현재 Pimlico, Biconomy, Alchemy 등 프로덕션 레벨에 있는 Bundler들은 모두 각각의 UserOp 멤풀을 사용하고 있습니다. 즉, 현재 모든 UserOp들은 중앙화된 단일 Bundler에 의해 처리되고 있고, 컨트랙트 계정을 가진 모든 사용자는 Bundler가 악의적인 행동을 하지 않을 것을 믿으면서 트랜잭션 요청을 보내야 합니다.

이로 인한 문제를 개선하기 위해, ERC-4337의 저자들로 구성된 eth-infinitism 팀은 Bundler 표준을 제시하고 퍼블릭 멤풀의 구성을 장려하고 있습니다. Bundler 표준이 필요한 이유는, Bundler 간 사양이 다르다면 같은 멤풀을 공유할 수 없기 때문입니다. 이를 위한 표준은 ERC-4337의 저자로 구성된 eth-infinitism의 GitHub에서 찾아보실 수 있습니다.

UserOp 퍼블릭 멤풀을 위해 여러 Bundler 제공자들도 협력하고 있습니다. 현재 Candide가 만든 Voltaire, Etherspot이 만든 Skandha, 그리고 Vid Kersid이 만든 Silius까지 세 종류의 Bundler가 Sepolia 테스트넷에서 퍼블릭 멤풀을 형성하여 퍼블릭 멤풀을 테스트해보고 있습니다.

뿐만 아니라 현재 메인넷에서 Bundler를 운영하고 있는 Alchemy와 Stackup 역시 P2P 인터페이스를 구현할 예정입니다. P2P 인터페이스가 구현되면 Bundler 간 통신이 가능해지고, 동일한 퍼블릭 멤풀을 공유할 수 있게 되어 탈중앙화된 형태로 UserOp Bundling을 수행할 수 있게 됩니다. 테스트넷에서의 실험을 거쳐 안정성과 효율이 확인된다면, 조만간 이더리움뿐만 아니라 폴리곤, 아비트럼 등 메인넷에 Bundler 퍼블릭 멤풀이 만들어질 것입니다. 이를 통해, Bundler의 중앙화를 막고 ERC-4337 아키텍처 내 검열 저항성을 높일 수 있습니다.

2.2. BLS 지갑을 통한 비용 감소

서로 다른 객체들의 서명을 집계하여 한 개의 서명으로 만들 수 있는 BLS 지갑을 사용한다면, UserOp의 비용을 크게 줄일 수 있을 것입니다. 그러나 현재 프로덕션 레벨에 존재하는 지갑들 중 BLS 서명 메커니즘을 사용하는 지갑은 없습니다. Ethereum Foundation의 PSE(Privacy & Scaling Exploration)에서 만든 팀인 WAX가 아래와 같이 BLS 지갑 데모를 만들어 실험해 본 것이 전부입니다.

BLS 서명 집계는 사용자가 내는 가스비를 감소시켜 줄 수 있다는 점에서 매우 유의미한 솔루션입니다. 그러나, 현실적으로 이 기술의 도입이 쉽지 않은 이유는 BLS 서명 자체의 특성에 있습니다. 기존의 ECDSA 서명과 비교했을 때, BLS는 검증에 드는 리소스가 다소 큰 편이라고 할 수 있습니다. 그럼에도 BLS가 효율적일 수 있는 이유는, 여러 개의 서명을 한 번에 검증할 수 있기 때문입니다. 다시 말하면 여러 개의 서명이 있지 않은 이상 BLS는 기존 서명 체계보다 더 많은 비용을 요구합니다.

ERC-4337에서 BLS가 효율성을 달성하기 위해선, 한 Bundle에 약 10개 이상의 UserOp이 있어야 합니다. 그러나 계정 추상화의 도입이 초기이기 때문에, Bundler 입장에서 한 Bundle에 10개 이상의 UserOp을 모으기 쉽지 않고. BLS의 도입 역시 어려운 상황입니다. 하지만 향후 UserOp의 개수가 많아짐에 따라 BLS 지갑이 상용화될 여지가 증가할 것이라고 생각할 수 있습니다.

2.3. 롤업에서의 비용 감소: Calldata Compression

문제점 1번에서 언급했듯이, 옵티미스틱 롤업에서는 트랜잭션의 calldata를 L1에 올리는 비용으로 인해 UserOp의 가스비가 많이 소모된다는 문제가 있었습니다. 이를 해결하기 위한 방법 중 하나로, 현재 UserOp의 calldata를 압축하는 방법에 대한 연구가 활발히 이루어지고 있습니다. 최근 Pimlico와 Daimo가 협력하여 이에 대한 솔루션을 출시하였습니다.

Bundler는 사용자의 UserOp을 받아서 엔트리포인트 컨트랙트를 통해 이를 트랜잭션으로 만듭니다. 이 호출에 많은 데이터가 필요하기 때문에 UserOp 트랜잭션의 calldata가 길어지고, 비용이 많이 들게 되는 것입니다. 그러나 만약 엔트리포인트로의 호출 앞단에서 압축된 calldata를 받아 이를 올바른 calldata 형태로 만들고 엔트리포인트로 호출을 보내주는 일종의 Inflator 컨트랙트가 있다면 어떨까요?

위와 같은 구조로 UserOp을 보내면, 압축된 형태의 calldata로 가스비를 이전보다 훨씬 저렴하게 만들 수 있습니다. 물론 압축을 푸는 과정에서 조금의 가스비가 추가되긴 하겠지만, calldata 압축으로 줄어드는 가스비가 훨씬 크기 때문에 전체 가스비는 대폭 감소하게 됩니다.

위 자료는 PSE 팀에서 수행한 연구 결과의 일부로, BLS 서명 집계와 calldata 압축을 통해 얼마만큼의 가스비를 아낄 수 있는지 나타낸 표입니다. 연구 결과에 따르면 UserOp의 가스비는 약 82%에서 최대 90%가량 감소하고, 이는 EOA에서 발생하는 가스비보다도 대략 2배 이상 작은 수준입니다.

앞으로 지갑 제공자들이 이러한 calldata 압축 및 BLS 서명 집계를 지원한다면, Arbitrum 혹은 Optimism과 같은 옵티미스틱 롤업에서 ERC-4337을 매우 저렴하게 사용할 수 있을 것입니다.

다만 위 사진에서 볼 수 있듯이, UserOp에 대한 calldata 압축은 Layer 1에서는 오히려 비용이 증가하는 결과를 낳습니다. Layer 1에서의 비용 감소를 위해서는 아래에서 소개할 Native Account Abstraction과 같은 솔루션을 도입해야 합니다.

3. 롤업에 구현하는 Native Account Abstraction: RIP-7560

3.1. Why Native Account Abstraction?

ERC-4337의 비용, 복잡성, 그리고 계정 리텐션 문제를 해결하는 방법 중 하나는 "Native account abstraction"을 도입하는 것입니다. 이는 EIP-2938, EIP-3074와 같이 프로토콜 내에서 계정 추상화를 지원하는 방식을 의미합니다. 계정 추상화를 프로토콜 내로 들여온다면 다음과 같은 이점을 얻을 수 있습니다.

• 가스비 절감
  • 사용자는 트랜잭션 대신 UserOp을 보내고, 이를 Bundler가 검증하여 트랜잭션을 대신 전송
  • 그 대가로 Bundler는 사용자에게 수수료를 받으며, 이 과정에서 Bundler에게 수수료를 보내거나, nonce를 수정하는 프로세스 하나하나가 가스를 크게 소모
  • 현재 ERC-4337에서 UserOp을 보내는 과정은 위 그림 및 설명과 같이 복잡하며, 이를 프로토콜에 내장한다면 UserOp 전송으로 인해 발생하는 가스비 절감이 가능
• 개발 리소스 절약 및 프로토콜 안정성 개선
  • PBS, crList 등 프로토콜에 새로 적용될 솔루션들을 UserOp에 적용 가능
  • 이는 ERC-4337에 적용될 솔루션에 대한 리서치 및 개발 리소스를 줄이고, 프로토콜의 안정성 개선에 기여

이전에는 EIP-3074와 같은 제안들이 복잡한 프로토콜 변화를 필요로 한다는 이유로 거절되었다면, 이제는 이러한 논의가 보다 가시적으로 진행되고 있습니다. 그렇다면 왜 애초부터 계정 추상화를 프로토콜 내에 구현하지 않고, ERC-4337과 같은 오프체인 메커니즘을 사용하였을까요?

2022년도부터 이더리움의 로드맵에는 ‘Native Account Abstraction 구현’이 존재하였습니다. 그러나 이 과정은 매우 복잡하고 높은 엔지니어링 리소스가 드는 작업입니다. 당시 이더리움은 proto-danksharding부터 PBS, Verkle trie 등 상대적으로 더 중요하게 여겨지는 기능들을 먼저 구현해야 하는 상황이었기에, Native Account Abstraction은 상대적으로 후순위에 있었고, 이는 현재도 그렇습니다.

이에 대한 중간 단계 솔루션으로 ERC-4337이 등장한 것입니다. 현재 ERC-4337이 발표되고 약 1년 동안 이 시스템의 안정성이 어느 정도 검증된 상태에서, 프로토콜 내 네이티브한 계정 추상화로의 논의가 일어나고 있습니다. 그중 가장 대표적인 움직임으로는 "RIP-7560"이 있습니다.

3.2. RIP란 무엇인가

RIP-7560을 알아보기 전에 먼저 RIP가 무엇인지부터 알아보겠습니다. RIP는 Rollup Improvement Proposal로, 이더리움을 L1으로 두는 롤업 간의 호환성이나 협력을 논의하기 위한 제안을 의미합니다. 이는 이더리움 재단에서 작년 10월부터 진행한 RollCall에서 논의되기 시작했습니다.

롤업들은 각자만의 방식으로 이더리움의 보안을 끌어오려고 노력하고, 그 과정에서 제공하는 도구 및 기능들이 상이한 경우가 많습니다. 대표적으로 Starknet과 zkSync는 네이티브한 계정 추상화를 지원하지만, 타 롤업들은 그렇지 않은 것이 그 특징입니다.

이에 따라 dApp 개발자들이 체인에 따라 다른 구현을 해야 한다는 문제가 발생합니다. 예를 들어 L1-L2 브릿지를 통합하고 싶은 dApp이 있다고 했을 때, 해당 dApp은 각 롤업마다 다른 코드를 바탕으로 해야 합니다. 롤업마다 서로 다른 브릿지 인터페이스를 가지고 있기 때문입니다.

이를 해결하기 위해선 롤업 간 협업이 필요합니다. RIP는 이를 위한 일종의 중립적인 토론의 장이 되는 것을 목표로 합니다. 롤업 간 차이는 어쩔 수 없지만, 호환되지 않는 부분을 최소화하는 방향으로 나아가자는 의미라고 볼 수 있습니다. 또한 RIP는 의무적인 프로세스가 아닙니다. 즉, RIP에 올라온 주제라고 해서 꼭 각 롤업에서 구현을 해야 한다는 의미는 아닙니다.

3.3. RIP-7560: Native Account Abstraction for L2s

RIP-7560은 롤업에서 Native Account Abstraction을 구현하고자 새로운 트랜잭션 타입을 제시하는 RIP입니다. 현재 zkSync와 Starknet에서 네이티브한 방식의 계정 추상화가 구현되어 있긴 하지만, 이는 ERC-4337과 호환되지 않는다는 문제점이 존재합니다. 이에 따라 RIP-7560은 ERC-4337와의 호환성을 지키면서 프로토콜 내에 Account Abstraction을 구현하고자 하고, 이를 통해 ERC-4337을 기반으로 하는 지갑 제공자들이 원활하게 통합될 수 있는 환경을 조성하고자 합니다.

RIP-7560은 계정 추상화의 트랜잭션 형태로 새로운 트랜잭션 타입인 "AA_TX_TYPE"을 제시합니다. 이에 따라 바뀌는 점은 다음과 같습니다.

1) 별도의 nonce 관리
기존 컨트랙트에서 nonce는 오직 CREATE opcode가 쓰일 때, 즉 해당 컨트랙트에서 다른 컨트랙트를 배포할 때만 증가하였습니다. 그러나 RIP-7560이 적용되어 컨트랙트 계정에서 AA_TX_TYPE 트랜잭션을 보낼 수 있게 된다면, 해당 트랜잭션이 발생할 때마다 nonce를 증가시켜 주어야 합니다. 그렇게 하지 않는다면 AA_TX_TYPE 트랜잭션에 대한 서명 재생(signature replay) 공격 등이 발생할 수 있게 되고, 계정의 자금이 탈취되는 상황이 발생할 수 있게 됩니다.

컨트랙트 계정에서도 nonce를 겹치지 않고 유지하는 방법 중 하나는 EOA의 nonce를 컨트랙트 계정에서도 사용하는 것입니다. 모든 EOA는 매 트랜잭션마다 1씩 증가하는 nonce를 가지고 있기 때문에, 이를 동일하게 컨트랙트 계정에 적용한다면 각 트랜잭션마다 서명을 구분할 수 있고, 서명이 재사용되었는지 여부를 확인할 수 있습니다. 이를 통해 서명 재생 공격과 같은 취약점을 방지할 수 있게 됩니다.

그러나, 이 솔루션에는 여러 엣지 케이스들이 있습니다. 만약 한 계정이 여러 사용자에 의해 운영될 경우, nonce가 겹쳐 혼란스러운 상황이 발생할 수 있습니다. 이에 따라 RIP-7560에서는 NonceManager 컨트랙트를 통해 컨트랙트 계정에서 오는 트랜잭션에 대해서 별도의 nonce를 취급하게 됩니다. 즉, 일반 EOA의 nonce와 컨트랙트 계정의 nonce가 순서대로 이어지지 않습니다.

2) 새로운 수수료 체계
기존 트랜잭션은 21,000 가스를 소모하도록 설정되어 있습니다. 그러나 AA_TX_TYPE이 도입되면 검증 메커니즘을 애플리케이션이 원하는 방식으로 설계할 수 있는 데다가, paymaster와의 상호작용 역시 고려해야 합니다. 이에 따라 RIP-7560에는 새로운 수수료(paymasterGasLimit 등)가 도입되어, 트랜잭션 수수료가 아래와 같은 로직으로 계산됩니다.

또한 eth_sendTransaction과 같은 RPC 메서드들이 AA_TX_TYPE을 받도록 수정됩니다.

3) 별도의 멤풀
AA_TX_TYPE 트랜잭션은 기존 트랜잭션과 다른 검증 및 실행 로직을 가지고 있기 때문에, 별도의 멤풀에서 처리됩니다. 그러나, 프로토콜 단의 블록 빌더가 이를 일괄 처리하기 때문에 블록에는 일반 트랜잭션들과 같이 들어가게 됩니다.

4) 검증과 실행의 분리
기존 ERC-4337에서 Bundler의 역할은 블록 빌더가 수행합니다. 블록 빌더는 아래와 같이 한 트랜잭션에서 AA_TX_TYPE 트랜잭션 배치의 검증과 실행을 나누어 블록에 포함합니다. 이는 기존 ERC-4337에서 한 트랜잭션 내에 여러 개의 UserOperation이 들어갔던 것과 유사합니다.

5) 빌더 수수료
이러한 과정에서 블록 빌더는 기존 트랜잭션을 처리하는 것보다 더 큰 컴퓨팅 리소스를 소모해야 합니다. 만약 블록 빌더가 이를 이유로 AA_TX_TYPE 트랜잭션들을 처리해주지 않으면 어떡할까요?

이러한 상황을 방지하기 위해, AA_TX_TYPE을 보내는 sender들은 트랜잭션에 builder fee를 붙여 이를 보상하는 동시에 자신의 트랜잭션이 블록에 먼저 포함되게끔 할 수 있습니다. 이는 마치 EIP-1559의 priorityFee와 유사한 개념입니다.

아직 RIP-7560은 정식 RIP로 등록되기 전 피드백을 받는 단계에 있습니다. 또한 멤풀에서 AA_TX_TYPE의 트랜잭션들이 어떻게 검증될지, ERC-4337에서 지원하던 서명 집계는 어떻게 구현될지와 관련된 후속 RIP가 두 개 정도 더 나와야 하는 상황입니다.

아직 롤업에서의 Native Account Abstraction 논의는 매우 초기 단계라고 볼 수 있지만, 적용되었을 때 사용자에게 줄 수 있는 가치가 크기 때문에 관심을 많이 받고 있습니다. 특히 Coinbase 측에서 빌딩 중인 Base 체인에서는 2024년 로드맵 중 하나로 컨트랙트 지갑 지원을 제시한 바 있습니다.

3.4. ERC-4337만이 해답은 아니다: EIP-3074

ERC-4337의 단점들이 드러나고, 계정 추상화를 프로토콜 내부로 들여오자는 논의가 점점 구체화됨에 따라 이전에 제안되었던 프로토콜 단의 계정 추상화 방식들이 재조명받고 있습니다. 특히 최근 EIP-3074를 여러 체인 내로 들여오자는 논의들이 진행되고 있습니다.

EIP-3074는 메타마스크와 같은 EOA에서 컨트랙트에게 계정 권한을 일부 ‘위임’할 수 있도록 하게 만들자는 제안입니다. 이를 위해 EIP-3074에서는 AUTH, AUTHCALL 두 가지 opcode의 도입을 제안합니다. 이것이 적용되었을 때 사용자의 호출 흐름은 다음과 같습니다.

우선 사용자는 본인의 지갑을 맡기고 싶은 컨트랙트를 포함한 메세지에 개인 키로 서명을 하여 릴레이어에게 보냅니다. 릴레이어는 이 서명을 Invoker라고 불리는 컨트랙트에 전달하고, 컨트랙트는 받은 서명을 AUTH opcode를 통해 검증합니다. 이러한 과정이 끝나면, Invoker 컨트랙트는 사용자 지갑에 대한 권한을 가지게 되고, 사용자 대신 트랜잭션을 보낼 수 있게 됩니다. 이때 Invoker 컨트랙트는 AUTHCALL opcode를 통해 트랜잭션을 보내는데, 이때 트랜잭션의 송신자(sender)는 권한을 빌려준 사용자의 지갑 주소로 설정되게 됩니다.

EIP-3074의 가장 큰 이점은, AUTHCALL을 포함한 트랜잭션이 전송될 때 사용자가 가스비를 낼 필요가 없다는 것입니다. AUTHCALL을 통해 실행되는 트랜잭션의 가스비는 릴레이어에 의해 지원되기 때문입니다. 즉, ERC-4337의 paymaster가 디폴트로 설정되어 있는 것입니다.

EIP-3074는 ERC-4337로 지원 가능한 대부분의 기능들을 포함할 수 있습니다. Invoker 컨트랙트가 어떻게 구성되어 있는지에 따라 트랜잭션 배칭, 세션 키, 소셜 리커버리 등 다양한 기능들이 구현될 수 있습니다. 나아가 EIP-3074는 기존 사용자들이 EOA에서 컨트랙트 계정으로 마이그레이션할 필요 없이 컨트랙트 계정이 제공할 수 있는 다양한 기능을 누릴 수 있다는 장점이 존재하고, 단순한 아키텍처로 가스비 역시 ERC-4337보다 적게 듭니다.

그러나 EIP-3074는 여러 가지 단점들이 존재합니다. 우선 이를 지원하기 위해선 프로토콜 변경(새로운 opcode 추가)이 필요하기 때문에, 멀티체인 지원을 위해선 여러 체인의 채택이 선행되어야 합니다. 또한, EOA에 의존하기 때문에 사용자가 개인 키 관리를 철저하게 해야 한다는 점은 변화가 없고, ECDSA 서명만 사용하여야 한다는 단점도 존재합니다. 물론 EIP-3074가 적용된 지갑을 컨트랙트 계정으로 마이그레이션할 수 있도록 하는 EIP-5003이 제안된 바 있지만, 마이그레이션 과정에서의 보안 문제에 대해 더욱 많은 논의들이 필요합니다.

그럼에도 EIP-3074는 EOA를 컨트랙트 지갑처럼 사용할 수 있게 만들어주는 강력한 기능을 제공합니다. 이에 따라, 최근 RIP-7560을 통해 계정 추상화를 프로토콜 내로 들여오자는 제안과 더불어 EIP-3074에 대한 많은 논의들이 이루어지고 있는 상황입니다. 이에 대한 내용은 후에 더 자세히 설명하도록 하겠습니다.

4. 계정 표준화: ERC-6900 & ERC-7579

위에서 이야기하였던 낮은 컨트랙트 계정 리텐션 문제를 해결하기 위해, 컨트랙트 계정 자체를 표준화하자는 논의도 많이 이루어지고 있습니다. 계정을 표준화한다면 사용자들은 앱 별로 동일한 지갑을 계속 사용할 수 있을 것입니다. 이를 위해 현재 두 개의 ERC가 제안되어 있습니다.

4.1. ERC-6900: Modular Smart Contract Account and Plugins

ERC-6900은 Alchemy에서 제안한 컨트랙트 계정의 표준입니다. 이 ERC의 특징은, 스마트폰처럼 계정에 앱들을 자유롭게 설치하고 제거할 수 있는 기능을 제공한다는 것입니다. ERC-6900에서는 계정에 설치되는 앱들을 Plugin이라고 부릅니다.

Plugin의 대표적인 예로는 다음과 같은 것들이 존재합니다. 만약 게임에서 사용되는 컨트랙트 계정일 경우, 계정의 권한을 일부 빌려주는 세션 키 기능이 필요한 상황이 있을 수 있습니다. 기존 컨트랙트 계정의 경우 이 기능을 배포 시부터 계정 컨트랙트 내에 포함시켰던 반면, ERC-6900의 경우 세션 키 기능을 수행하는 Plugin을 만들어 계정에 설치하는 방식을 택합니다.

이러한 방식을 통해 ERC-6900은 사용자가 자유롭게 계정에 기능 추가 및 제거를 할 수 있도록 하고, 계정의 재사용성을 높입니다. 이에 따라, 앱 입장에서도 더 쉽게 컨트랙트 계정을 통합할 수 있습니다.

예를 들어, 세션 키가 필요한 온체인 게임이 있다고 해 봅시다. 지금 상황에서 이 게임이 컨트랙트 지갑을 통합하려 한다고 했을 때, 게임은 컨트랙트 지갑을 하나만 선택해야 합니다. 지갑마다 세션 키의 구현 방식이 달라, 여러 종류의 지갑을 통합했을 때 일관성 있게 트랜잭션을 보낼 수 없게 되기 때문입니다. 물론 지갑 내 세션 키마다 알맞게 상호작용할 수 있는 로직을 짜도 괜찮겠지만, 이는 앱 내 복잡성을 가중시키기 때문에 바람직하지 않습니다.

ERC-6900과 같은 컨트랙트 지갑 및 모듈(플러그인)의 표준이 상용화된다면 이러한 문제를 해결할 수 있습니다. 위와 같은 상황에서 애플리케이션은 본인이 사용하고 싶은 세션 키 플러그인을 개발해서, 이를 사용자가 지갑에 설치할 수만 있게끔 하면 되기 때문입니다.

ERC-6900의 장점이자 단점은, 보안이 철저하다는 것입니다. ERC-6900의 참조 구현체를 보면, 보안을 위해 다양한 조치를 해 놓아서 악의적인 플러그인이 설치되는 상황에 어느 정도 대처가 가능하게 설계가 되었다는 것을 알 수 있습니다. 그러나 보안이 철저한 만큼 컨트랙트 내에서 확인해야 하는 것들이 많아지다 보니, 사용자가 기존 지갑들보다 더 많은 가스비를 부담해야 하고, 구조의 복잡성으로 인해 개발 난이도가 다소 높다는 단점이 존재합니다.

4.2. ERC-7579: Minimal Modular Smart Accounts

ERC-7579 역시 컨트랙트 지갑의 표준을 정하기 위해 Rhinestone, ZeroDev, Biconomy, OKX의 협업을 통해 제안된 ERC로, 지갑에 모듈을 사용자가 원하는 대로 설치 및 제거하는 메커니즘을 사용합니다. 이러한 점에서 ERC-6900과 유사하다고 볼 수 있지만, 가장 큰 차이점은 보안과 비용입니다.

ERC-7579는 그 이름에서 알 수 있듯, 컨트랙트 계정에 있어 최소한의 표준을 갖추기 위한 제안입니다. 이에 따라 ERC-7579에서는 호환성과 상호 운용성에 집중해 각 지갑의 자율성을 해치지 않는 선의 스펙을 제시합니다. 따라서 ERC-7579는 최소한의 제한 사항만 지키면서 쉽게 개발할 수 있다는 장점이 있습니다. 이는 다양한 구현체가 나올 수 있다는 장점으로 이어지고, 실제로 아래와 같이 ERC-7579 구현체는 데모 단계임에도 불구하고 특히 ‘Native transfer’와 ‘ERC20 transfer’에서 최적화를 거친 프로덕션 레벨의 타 지갑들과 비교했을 때에도 몇천 수준의 가스비 차이밖에 존재하지 않았습니다.

그러나 ERC-7579는 ERC-6900과 비교했을 때 보안의 측면에서 위험할 수 있는 요소들도 허용하는 측면이 존재합니다. 모듈러한 아키텍처에서 가장 위험한 것은 계정에 설치되는 악의적인 모듈입니다. 이에 따라 ERC-6900에서는 설치되는 플러그인(모듈)이 접근할 수 있는 외부 컨트랙트를 제한할 수 있는 기능을 만들어두는 등, 계정의 보안을 보장하기 위한 다양한 방법들을 구현해두고 있습니다. 반면, ERC-7579에서는 이러한 사항을 체크하고 있지 않습니다. 물론 참조 구현체에서는 모듈 레지스트리를 두어 미리 설정된 개발자 및 감사자들이 해당 모듈이 악의적인지, 보안 허점은 없는지 확인하는 ERC-7484의 도입을 제안하고는 있으나, 이는 사전에 설정된 committee에 의존해야 한다는 점에서 궁극적인 해결책은 아닙니다.

결론적으로, ERC-6900과 ERC-7579는 모두 모듈러 컨트랙트 계정의 표준을 제안하고 있습니다. 개인적으로, 위 두 표준은 공존하게 될 것이라 생각합니다. DeFi나 페이먼트 등 보안이 중요한 영역에서는 ERC-6900 표준을 따르는 지갑이 더 적합할 수 있고, 게임이나 소셜 등 상호작용이 많이 필요한 영역에서는 ERC-7579 표준을 따르는 것이 적합할 수 있기 때문입니다.

이 표준들은 많은 개발과 피드백을 거쳤고, 이를 활용한 컨트랙트 계정들이 현재 출시를 앞두거나, 시장에 나와 있습니다. 최근 ZeroDev에서 ERC-7579와 호환되는 지갑 SDK를 공개했고, 사용자 및 애플리케이션 개발자들은 이 SDK를 기반으로 ERC-7579 표준에 맞는 모듈을 개발하거나 해당 지갑을 메인넷에서 사용해 볼 수 있습니다. 또한 ERC-6900은 커뮤니티의 피드백을 거치는 단계에 있고, 조만간 프로덕션 레벨에서 사용될 수 있게 감사를 거쳐 출시될 것으로 예상됩니다. 두 표준이 점점 상용화됨에 따라, 애플리케이션 별로 서로 다른 지갑을 사용하는 것이 아니라 한 컨트랙트 계정을 여러 앱에서 사용하게 될 수 있을 것이라고 예상할 수 있습니다.

5. Account Abstraction + Intent: ERC-7521

5.1. Intent의 정의와 문제점

현재 이더리움에서 트랜잭션을 보내려면, 어디로 트랜잭션을 보낼지, 얼마만큼의 ETH를 보낼지, 얼마만큼의 가스를 사용할지 등을 모두 정해주어야 합니다. 이는 매우 복잡한 작업이며, 특히 DEX에서 토큰을 스왑하려는 트랜잭션의 경우 MEV 등을 고려해 가스 및 스왑 양을 설정해야 합니다.

Intent는 이러한 복잡성을 제거하고 UX를 개선하고자 등장한 개념입니다. Web3에서 Intent가 적용된 앱들은 사용자가 트랜잭션을 어디로 보낼지, 얼마만큼의 토큰을 보낼지 정확히 특정하지 않아도 그 ‘의도’를 보고 트랜잭션을 대신 구성해 보내줍니다. 즉, Intent는 여기서 사용자가 해당 트랜잭션 실행에 거는 일종의 제한사항으로, 스왑의 결과로 최소한 얼마만큼의 토큰을 받을지와 같이 사용자가 기대하는 바를 표현합니다. 애플리케이션은 Intent를 받아 조건에 맞는 트랜잭션을 대신 구성해 주게 되는데, 이 일을 하는 주체를 Solver라고 합니다.

Intent는 작년부터 블록체인 생태계 내에서 주목받고 있는 개념 중 하나입니다. Intent를 사용하면, "내일까지 1 ETH를 USDC로 바꾸는데, 최소 2000 USDC 이상은 받게 해 줘"와 같이 지정가 주문 등 다양한 사용 사례들을 만들어 낼 수 있습니다. 현재 CoWSwap, UniswapX, Flashbot, Anoma 등에서 Intent를 활용한 프로토콜을 개발하고 있습니다.

하지만 여러 프로토콜이 각자만의 Intent 표준을 개발하고 있기 때문에, 서로 간 호환이 되지 않을 수 있고, 이 경우 Intent 서비스 간 사용자의 파편화가 발생할 수 있습니다. Intent를 사용하는 메커니즘에서 가장 중요한 것 중 하나는 Solver의 탈중앙화이기 때문에 위와 같은 상황은 문제를 발생시킬 수 있습니다. Solver는 사용자 대신 트랜잭션을 구성해 주는 강력한 주체로, 중앙화되었을 때 사용자에게 미치는 영향이 매우 큽니다. 다음과 같은 상황을 생각해 볼 수 있습니다.

가령 어떤 DEX에 Intent 메커니즘이 적용되었는데, Solver가 단 한 명이라고 생각해 봅시다. 사용자는 여기에 스왑을 신청하면서 Intent에 "나는 1 ETH를 최소 2,300 USDC로 바꾸고 싶어"라고 적었습니다. Solver가 단 한 명이기에, 현재 ETH의 가격이 2,400 USDC이더라도 Solver는 사용자에게 2,300 USDC만 주고 $100의 차익을 챙길 수 있게 됩니다.

이러한 경우 때문에 Intent를 사용하는 애플리케이션에서는 항상 탈중앙화된 Solver들 간의 옥션 구조를 택하고 있습니다. Solver가 항상 사용자에게 최대한 유리한 트랜잭션을 구성해 주도록 유도하고, 중앙화된 Solver의 수익 독점을 막기 위함입니다.

여기서 각 프로토콜이 정의하는 Intent 표준 간의 호환성이 문제가 됩니다. 프로토콜 내 Solver들이 각각 별도의 Intent mempool을 두고 운영된다면, 이는 모두 합쳐 하나의 mempool에서 운영되는 것보다 중앙화될 수밖에 없기 때문입니다. 즉, Intent에 대한 표준이 필요한 상황입니다.

5.2. ERC-7521 & Essential

23년 5월 설립되어 Intent 인프라를 제공하려고 하는 Essential은 ERC-4337을 활용한 Intent 표준을 제시합니다. ERC-4337 및 계정 추상화는 Intent를 사용하는 메커니즘은 아니지만, Intent와 결합하기 좋은 조건을 가지고 있습니다.

Intent에서 사용되는 Solver와 ERC-4337의 Bundler는 매우 유사한 작업을 수행하는 주체입니다. 둘 다 오프체인에서 사용자의 서명이 포함된 데이터(Intent / UserOperation)를 트랜잭션 형태로 바꿔주기 때문입니다. 따라서 Solver도 현재 구축된 ERC-4337 인프라를 활용한다면, 큰 변화를 주지 않고도 현재 컨트랙트 계정에 Intent의 효과를 줄 수 있다는 장점이 존재하게 됩니다.

Intent 아키텍처에서 중요한 것은, 사용자가 Intent에 올바르게 서명했는지, 그리고 실행할 때 Intent의 조건이 올바르게 맞추어졌는지(검증)와 이를 어떻게 트랜잭션으로 구성하는지(실행)입니다. ERC-7521은 ERC-4337의 검증과 실행 프로세스에 영감을 받아, 엔트리포인트 컨트랙트에서 Intent의 처리도 가능하도록 만드는 것을 제안하였습니다. 자세한 메커니즘은 다음과 같습니다.

사용자가 UserIntent 멤풀에 Intent와 서명을 같이 보내면, Solver는 이를 보고 이에 대한 Solution(트랜잭션)을 구성하게 됩니다.

그런 다음 Solver는 엔트리포인트 컨트랙트 내 handleIntents 함수를 호출합니다. 그러면 해당 함수 내에선 Intent에 포함된 사용자의 서명을 검증하고, Solver가 구성한 Solution이 사용자가 제시한 Intent의 조건과 맞는지 확인합니다. 그런 다음, 해당 Solution을 실행하여 사용자가 요청한 액션을 수행하게 됩니다.

이때 중요한 부분은 각 Intent가 어떠한 형태를 띠고 있는지입니다. Intent는 어디에 쓰이냐에 따라 각각 다른 형태를 가질 수 있기 때문에, 이를 컨트랙트 상에서 고정시켜 버리면 자유도가 매우 줄어들게 되는 단점이 존재합니다. 이러한 문제에 대해 ERC-7521은 Intent 표준을 등록할 수 있게끔 하여 해결합니다.

이러한 방식을 통해 ERC-7521은 컨트랙트 계정에서 쉽게 Intent를 사용할 수 있도록 함과 동시에, Intent 처리의 표준을 만듦으로써 Solver 네트워크가 파편화되지 않도록 할 수 있습니다.

그러나 여기에도 몇 가지 단점이 존재합니다. 우선, ERC-7521은 ERC-4337 스펙의 변화를 요구합니다. Intent 검증 및 실행, Intent 표준 등록 등에 필요한 함수들을 엔트리포인트에 추가해야 하고, 이 과정에서 커뮤니티 및 개발자들이 이러한 업데이트에 동의해야 합니다. 또한, 이러한 Intent 표준을 지원하려면 현재 존재하는 ERC-4337 호환 지갑들이 업그레이드를 진행해야 합니다. 즉 이 표준이 실제로 적용되기까지는 여러 이해관계자들, 그리고 커뮤니티와의 논의가 필요하고, 이는 이더리움 커뮤니티의 특성상 꽤 오래 걸리는 작업이 될 가능성이 큽니다.

6. 결론 및 전망

지금까지 두 개의 계정 추상화 1편과 2편을 통해 지난해 계정 추상화 생태계가 어떻게 발전되어 왔고, 어떤 방향으로 나아가고 있는지에 대해 알아보았습니다. 이를 기반으로, 앞으로 계정 추상화 생태계는 어떻게 발전할지, 어떠한 기술적 진보와 허들이 있을지 예상해 보았습니다.

6.1. 계정 추상화를 활용하는 킬러 앱의 등장

계정 추상화나 ERC-4337이 기술적으로 발전하더라도, 결국 중요한 것은 애플리케이션이 이 기술을 얼마나 받아들일 수 있는지에 달려 있습니다. 현재까지 계정 추상화를 도입한 앱들은 앱 자체의 매력이 떨어지거나, 계정 추상화를 단순 이벤트용으로 사용하는 경우가 많았습니다. 그러나 앞으로는 Calldata 압축을 통한 비용 절감 등을 통해 ERC-4337 자체에서도 사용성을 크게 개선할 수 있고, 이를 적용한 애플리케이션이 더욱 많이 등장할 것이라 예상합니다.

개인적으로 ERC-4337 적용으로 가장 큰 시너지를 낼 수 있다고 생각되는 섹터는 게임입니다. 게임 내에서 트랜잭션 서명 창이 켜지는 등의 UX는 바람직하지 않고, 이는 세션 키 등 ERC-4337에서 지원되는 기능으로 해결할 수 있습니다. 그러나 아직까진 Web3 게임 섹터에서 계정 추상화를 사용해 UserOp을 많이 만든 애플리케이션은 없습니다. 최근 Arbitrum Orbit 기반의 게임 앱체인인 Xai가 많은 관심을 받고 있기는 하지만, 게임이 성공하여 지속적으로 트랜잭션을 발생시킬지는 조금 더 지켜봐야 하는 상황입니다.

앞으로 2024년에는 계정 추상화를 적용한 게임 등 다양한 앱들이 등장해, 많은 사용자들에게 더욱 높은 수준의 UX를 제공할 수 있길 기대합니다.

6.2. 컨트랙트 계정 재사용

ERC-6900, ERC-7579로 대표되는 계정의 표준화가 이루어진다면, 앱 별로 다른 컨트랙트 계정을 사용하는 것이 아니라 하나의 컨트랙트 계정으로 여러 앱을 사용할 수 있는 환경이 조성될 것입니다.

최근 ZeroDev가 ERC-7579 계정을 기반으로 모듈러한 계정 아키텍처를 발표하였습니다. 이를 시작으로 앞으로의 계정들은 모듈러한 형태로 서로 호환성을 유지하며 재사용이 용이한 형태를 갖출 것이고, 이는 사용자들로 하여금 한 컨트랙트 계정을 계속 사용할 수 있게끔 만들어 줄 것입니다.

이를 가속화하기 위해선 여러 컨트랙트 계정을 쉽게 앱에 통합할 수 있는 SDK가 필요합니다. 기존 EOA 지갑들에 대해선 RainbowKit와 같은 툴들이 존재하여, dApp 개발자들이 메타마스크, 코인베이스 월렛 등 여러 지갑을 앱에 쉽게 통합할 수 있었습니다.

그러나 컨트랙트 계정에 대해서는 이러한 SDK가 거의 존재하지 않습니다. 현재 Pimlico에서 만든 permissionless.js가 거의 유일한데, 이는 컨트랙트 계정에 대해서도 RainbowKit와 같은 기능을 제공하고자 하는 SDK입니다.

현재 permissionless.js에는 ZeroDev, Safe, 그리고 ERC-4337 참조 구현체 내 SimpleAccount 계정을 지원하고 있어, 애플리케이션들이 해당 지갑들을 쉽게 통합할 수 있도록 하고 있습니다. 해당 SDK가 더욱 많은 지갑들을 통합하게 된다면, 애플리케이션도 컨트랙트 계정 도입이 더욱 쉬워질 것이라고 생각할 수 있습니다.

6.3. 프로토콜 내 Native Account Abstraction

Vitalik이 올해 초 발표한 이더리움 로드맵을 보면, 계정 추상화에 대한 이더리움 재단의 생각을 알 수 있습니다. 이는 로드맵 내 The Splurge 부분에서 잘 드러나 있습니다.

현재는 ERC-4337 Rollout(발표)까지 이루어진 상황이고, 사용자들이 컨트랙트 계정으로 사용 지갑을 이전하는 Voluntary EOA conversion이 진행된 후 Native Account Abstraction이 구현될 예정입니다.

이 로드맵을 고려했을 때, 최근 RIP-7560의 제안은 Voluntary EOA conversion의 의도가 있다고도 볼 수 있습니다. 굉장히 긴 기간의 논의를 거쳐 진행되는 이더리움 프로토콜 업데이트와 달리, 롤업의 업데이트는 보통 중앙화된 재단이 빠르게 진행하는 방식으로 이루어집니다. 이에 따라 EVM 호환성을 갖추고 있는 롤업들에서 먼저 빠르게 네이티브한 방식의 계정 추상화를 제공하고, 많은 사용자들을 컨트랙트 계정으로 마이그레이션 하도록 만드는 방식입니다.

RIP-7560을 통해 롤업에서 프로토콜 내로 계정 추상화를 들여오면, 가스비 절감 효과를 통해 저렴한 비용으로 다양한 기능을 누릴 수 있을 것입니다. 2024년에는 RIP-7560을 적용하고자 하는 네이티브한 방식의 계정 추상화를 제공하려는 롤업들이 늘어날 것으로 예상됩니다.

6.4. EIP-3074의 약진

EIP-3074는 EOA에 컨트랙트 계정의 기능들을 더해주는 강력한 EIP입니다. 사용자들을 EOA에 의존하게 만든다는 단점에도 불구하고, 최근 몇 달간 이와 관련된 여러 논의들이 진행되며 EIP-3074를 구현하자는 의견이 점점 커지고 있습니다. Polygon에서는 작년 9월 EIP-3074를 프로토콜 내로 들여오자는 PIP-22가 포럼에 제안된 바 있고, Dencun 이후로 예정된 이더리움의 Prague 업데이트에 들어갈 EIP를 논의하는 Ethereum Core Dev Meeting에서도 EIP-3074와 관련된 논의가 길게 이어진 바 있습니다.

아직까진 EIP-3074를 지원하는 체인이나 서비스 제공자들은 당연히 존재하지 않지만, 앞으로 이더리움 혹은 EVM 호환 체인에서 점점 EIP-3074를 지원하기 시작한다면 이를 기반으로 한 새로운 생태계가 형성될 것입니다.

또한 EIP-3074와 ERC-4337의 접근 방식이 서로 겹치기 않기 때문에, 둘 모두를 사용한 솔루션이 등장할 수도 있습니다. 가장 대표적인 예시는 EIP-3074의 Invoker를 ERC-4337 계정 역할을 하도록 만드는 것입니다. Invoker 컨트랙트를 기존 ERC-4337 계정처럼 만들어두고, 해당 Invoker 컨트랙트에 AUTH 서명을 보내놓는다면 매우 저렴한 비용으로 ERC-4337의 기능을 이용할 수 있습니다.

2024년에는 EIP-3074를 지원하는 체인이 여러 개 생기고, 위의 예시와 같이 EIP-3074를 활용한 재미있는 사용 사례 및 애플리케이션들이 생기길 바랍니다.

6.5. 아직 초기에 머무르고 있는 계정 추상화와 Intent의 결합

계정 추상화와 Intent 모두 블록체인의 불편한 UX를 개선하고자 제안된 기술들이고, 최근 제안된 ERC-7521을 통해 ERC-4337에서도 쉽게 Intent를 지원할 수 있는 표준이 생겼습니다. 두 기술의 결합을 통해, 매우 높은 수준의 UX를 제공하는 애플리케이션이 등장할 수 있을 것입니다.

그러나 아직 이와 관련된 논의는 매우 초기 수준에 머물러 있습니다. 우선 Intent 자체도 아직 그 사용 사례가 많지 않습니다. 현재 CowSwap, UniswapX 등 ‘스왑’에 대해서만 Intent가 적용되고 있습니다. 앞으로 Anoma, SUAVE 등 좀 더 일반적인 상황에서 Intent가 적용될 수 있는 환경이 선행되어야 할 것이고, ERC-7521를 현 ERC-4337 아키텍처에 어떻게 적용할지에 대한 논의도 더욱 많이 진행되어야 할 것입니다.