원문: "완우 연구소: 웹3의 차세대 10억 사용자 시장? 계정 추상화와 EIP4337 기술 및 응용 분야에 대한 포괄적 설명"
저자: Steve Wang , Institute of Everything의 연구원, Wharton 학생, 프런트엔드 및 계약 엔지니어
소개
이더 개선 제안 4337(EIP 4337)에 정의된 계정 추상화는 프로토콜 수준 인터페이스의 집합입니다. 다중 인증(MFA)과 같은 웹2 사용자와의 익숙한 상호작용을 통합할 뿐만 아니라, 가스비 없는 거래와 같은 웹3의 고유한 사용자 문제점도 해결합니다. 차세대 10억 명의 사용자를 위한 프로토콜 인터페이스로서, 사용자 경험은 계정 추상화에 있어 가장 중요한 고려 사항입니다.
기존 논문들은 계정 추상화에 대한 훌륭한 설명을 많이 제공하지만, 대부분은 일반적인 지식 위주이며, 일부는 기술적 세부 사항을 심도 있게 다루고 있습니다. 본 논문은 이러한 간극을 메우는 것을 목표로 합니다. 계정 추상화 개념에 대한 포괄적인 기술적 설명을 제공하는 동시에 기존 애플리케이션 및 인프라 사례를 분류하고 분석합니다. 따라서 본 논문은 세 부분으로 구성됩니다. 1부에서는 EIP 4337의 기원을 살펴보고 사용자 운영, 번들러, 진입점 계약, 페이마스터, 월렛 팩토리, 서명 집계기를 포함한 기술적 세부 사항을 심층적으로 다룹니다. 2부에서는 스마트 계약 지갑 및 서드파티 인프라 제공업체를 포함한 기존 시장 참여자들을 분석합니다. 3부에서는 계정 추상화의 미래 방향과 이 분야의 혁신에 대한 전망 및 예측을 논의합니다.
이 글은 꽤 깁니다. 첫 번째 부분에서는 주로 계정 추상화의 기술적 측면을 설명합니다. 계정 추상화의 적용 시나리오에만 관심이 있는 독자는 두 번째 부분으로 바로 넘어가실 수 있습니다.
1부: EIP 4337에 대한 포괄적인 기술 분석
먼저 기본 사항을 간략하게 살펴보겠습니다. 이더 외부 소유 계정(EOA)과 컨트랙트 계정, 두 가지 유형의 계정이 있습니다.
- EOA 는 사용자가 제어하는 계정으로, 거래를 전송할 수 있습니다. EOA는 개인 키를 통해 계정 소유권을 제어하고, 서명을 통해 거래를 실행하여 EOA의 내부 상태 또는 외부 계약 계정의 상태를 변경할 수 있습니다. 개인 키(또는 시드 문구)는 EOA 소유권을 나타내는 유일한 수단이므로, 소셜 로그인이나 다자 서명(멀티시그) 거래와 같은 복잡한 소유권 또는 거래 로직을 정의하는 데 적합하지 않습니다. EOA의 한계는 사용자 경험을 저하시킵니다. 개인 키 및 시드 문구 관리와 같은 복잡한 단계는 웹 2 사용자가 웹 3에 진입하는 것을 직접적으로 방해합니다. MetaMask와 같은 대부분의 인기 지갑은 EOA 계정 모델을 기반으로 합니다.
- 계약 계정은 임의의 Solidity 코드를 호스팅할 수 있으므로 EVM의 튜링 완전성을 완전히 활용할 수 있습니다. 하지만 계약 계정은 트랜잭션을 전송할 수 없으므로, 해당 기능은 EOA에 의해 트리거되어야 합니다. 스마트 계약 지갑은 사용자가 지갑 제공업체의 EOA 네트워크(릴레이어 또는 번들러)를 통해 간접적으로 트리거하는 계약 계정입니다.
그림: EOA 및 계약 계정(출처: Bitcoin Insider)
스마트 계약 지갑은 EIP 4337보다 훨씬 이전부터 존재했습니다. EIP 4337은 스마트 계약 지갑과 관련 인프라의 공통 기능을 표준화하기 위해 제안되었습니다. EIP 4337은 다음과 같은 설계 원칙을 따릅니다.
- 전반적으로 모든 기술 구현은 최상위 계층(스마트 계약 계층)에서 구현되므로 컨센서스 레이어 및 실행 계층과 같은 기본 인프라를 건드릴 필요가 없습니다. 이 계층에서 계정 모델과 같은 기본 설계를 수정하는 것은 이더 PoS 메인넷 병합과 마찬가지로 상당한 업그레이드가 될 것입니다. 개발자 리소스가 제한적이기 때문에 계약 계층에 구현되는 경량화된 접근 방식이 유일한 선택지입니다.
- 프로토콜 인터페이스의 디자인은 사용자가 거래 패키징(Bundler), 가스 지불(Paymaster), 서명 집계(Aggregator) 등의 옵션을 사용자 정의할 수 있도록 모듈식이어야 합니다 .
- 이상적으로는 이러한 각 서비스가 사용자가 가격과 평판을 기준으로 가장 좋은 서비스를 선택할 수 있는 경쟁적이고 개방적인 시장이 되어야 합니다 .
EIP 4337은 표준화된 스마트 계약 지갑을 위한 6가지 계약 인터페이스를 정의합니다.
첫째, 스마트 계약 지갑 자체는 패키저가 진입 계약을 트리거하여 간접적으로 트리거되고, 체인 외부에서 거래를 검증한 다음 온체인 실행합니다.
둘째, Bundler는 사용자 작업(EIP 4337에 정의된 스마트 계약 지갑의 거래 유형인 UserOperation)을 일괄적으로 검증하고 실행하는 데 사용됩니다.
셋째, 진입점 계약(Entry Point Contract) 은 이더 에서 단 한 번만 존재하는 글로벌 계약입니다. 이는 트랜잭션 실행을 표준화하고 악의적인 트랜잭션으로 인한 서비스 거부(DoS) 공격으로부터 패키저를 보호하는 데 사용됩니다.
넷째, Paymaster 계약은 지갑 사용자를 대신하여 가스 지불을 처리하는 데 사용됩니다.
다섯째, Wallet Factory는 지갑 생성에 필요한 매개변수와 프로세스를 표준화하는 데 사용됩니다.
여섯째, 서명 집계기는 여러 거래의 서명을 바이트로 집계하여 거래의 검증 및 실행을 가속화하는 데 사용됩니다.
아래에서는 UserOperation과 위에서 언급한 6가지 계약 인터페이스에 대해 자세히 설명하겠습니다. 이는 공식 EIP 4337 문서와 Alchemy의 David Philipson의 계정 추상화 시리즈를 해석한 것입니다.
1. 사용자 조작
UserOperation은 EIP 4337의 계약 인터페이스를 기반으로 추가 매개변수를 정의한다는 점을 제외하면 일반 트랜잭션과 본질적으로 동일합니다. 요약하자면, EOA에 의해 트리거되는 일반 이더 트랜잭션에는 트랜잭션 대상 주소, 전송된 이더 양, 가스 양, 가스 가격과 같은 매개변수가 포함됩니다.
또한 EIP 4337 계약 인터페이스의 모듈식 설계를 고려하여 UserOperation에는 인터페이스 트리거를 정의하기 위한 다음과 같은 주요 매개변수가 포함됩니다.
- Calldata: 스마트 계약 지갑에서 호출될 함수 시그니처와 입력 매개변수를 정의합니다. Calldata는 일반 트랜잭션에도 존재합니다.
- 서명: 거래가 실제로 스마트 계약 지갑 주소에서 이루어졌는지 확인합니다. 서명은 일반 거래에도 적용됩니다.
- Nonce: 재생 공격을 방지하고 일반 거래에도 사용됩니다.
- 발신자: UserOperation을 실행하는 스마트 계약 지갑 주소를 지정합니다.
- paymasterAndData: 지불 계약(Paymaster) 주소 및 가스 지불 매개변수를 포함하여 거래 수수료 추상화(가스 추상화)에 사용됩니다 .
- initCode: 지갑 생성에 사용되며 Wallet Factory 계약 주소와 스마트 계약 지갑을 생성하기 위한 매개변수(예: 지갑 계약 코드)를 포함합니다.
추가 매개변수가 필요하다는 점 외에는 UserOperations는 일반 트랜잭션과 유사하게 작동합니다. 즉, 모든 트랜잭션은 검증, 실행, 그리고 궁극적으로 블록 생성을 위해 메모리 풀로 브로드캐스트됩니다. UserOperations의 검증 및 실행은 번들러에 의해 트리거되는데 , 이에 대해서는 아래에서 설명하겠습니다.
그림: 공식 EIP 4337 문서의 UserOperation 매개변수 정의
2. 번들러
Bundler는 스마트 컨트랙트 지갑에서 사용자를 대신하여 UserOperation 트랜잭션을 검증하고 실행하는 외부 소유 계정(EOA)입니다. 이더 의 모든 트랜잭션은 EOA에 의해 트리거되어야 하므로, Bundler를 사용하면 사용자가 EOA의 개인 키를 생성하고 기억할 필요 없이 스마트 컨트랙트 지갑 트랜잭션을 트리거할 수 있습니다. 이는 스마트 컨트랙트 지갑의 원래 목적입니다.
Bundler는 강력한 공공재 속성을 가지고 있지만, 다음과 같은 이유로 경제적 이점도 있습니다 .
- Bundler는 UserOperation을 실행한 후 최대 우선권 수수료와 실제 가스 비용의 차액을 챙길 수 있습니다.
- 일반 거래의 릴레이어와 유사하게 Bundler는 번들 거래에서 UserOperation을 순서 하여 MEV를 얻을 수 있습니다.
사용자는 비용을 지불하지만, 번들러는 가스 비용 절감에 도움이 됩니다 . 각 트랜잭션은 21,000 가스의 고정 비용을 가지며, 번들 트랜잭션을 실행하면 이 고정 비용을 번들 트랜잭션의 여러 UserOperation에 분산하여 가스 비용을 절감할 수 있습니다. 또한, 동일한 트랜잭션에서 스토리지를 여러 번 수정하는 경우, 추가 작업당 가스 비용이 소폭 감소합니다.
이더 의 트랜잭션은 상태 충돌을 피하기 위해 선형적으로(병렬이 아닌) 실행되지만, 번들러가 동일한 스마트 계약 지갑 주소에 최대 하나의 UserOperation만 포함하도록 설정할 수 있으므로 여러 UserOperation을 단일 번들 트랜잭션에서 실행할 수 있다는 점에 유의하는 것이 중요합니다. 이렇게 하면 번들 트랜잭션이 상태를 수정할 때 서로 충돌하지 않습니다.
이러한 차이점 외에도, 번들러는 블록 빌더와 유사합니다. 둘 다 검증된 UserOperations를 공개 또는 비공개 메모리 풀로 브로드캐스트합니다. 다음으로, 번들러가 UserOperations를 실행하기 위해 상호 작용해야 하는 진입점 계약을 소개합니다.
3. 진입점 계약
진입점 계약은 모든 번들러가 UserOperation을 실행하기 위해 호출해야 하는 글로벌 싱글턴 계약입니다. 번들러와 스마트 계약 지갑 사이의 중개자 역할을 합니다.
- 한편 Bundlers는 UserOperation을 입력 매개변수로 수락하는 진입점 계약의 handleOp 함수를 호출합니다. handleOp는 UserOperation의 calldata를 기반으로 스마트 계약 지갑 함수를 검증하고 실행하는 역할을 합니다.
- handleOp는 먼저 지정된 스마트 계약 지갑 주소로 서명되었는지, 그리고 지갑에 Bundler를 보상할 만큼 충분한 가스가 있는지 확인하여 온체인 UserOperation을 검증합니다.
- 검증이 성공하면 handleOp는 UserOperation의 calldata에 정의된 함수 서명 및 입력 매개변수에 따라 스마트 계약 지갑 함수를 실행합니다.
- 반면, 스마트 컨트랙트 지갑은 Bundler에 가스비를 지불하기 위해 진입점 컨트랙트에 토큰을 예치해야 합니다. Bundler가 EOA를 사용하여 handleOp 함수를 트리거하면 가스비가 발생합니다.
- 또한, 스마트 컨트랙트 지갑은 자체 계좌 잔액 사용하여 Bundler에 가스비를 지불하거나, 결제 컨트랙트(Paymaster)에 대신 지불을 요청할 수 있습니다. 자세한 내용은 나중에 설명하겠습니다.
- 가스가 충분하지 않은 UserOperations는 대상 스마트 계약 지갑의 검증 단계를 통과할 수 없으므로 실행 전에 실패합니다.
- 가스가 충분하더라도 UserOperation은 실행 단계에서 런타임 오류와 같이 실패할 수 있습니다.
- 실행이 성공하든 실패하든 진입점 계약은 Bundler에 가스 수수료를 지불하여 handleOp 함수를 트리거합니다.
- 진입점 계약은 스마트 계약 지갑에서 토큰 담보를 추가하거나 클레임 기능을 제공합니다.
그림: 공식 EIP 4337 문서의 진입점 계약 워크플로
4. 스마트 컨트랙트 지갑 메인 컨트랙트
스마트 계약 지갑 메인 계약은 UserOperation의 검증 및 실행 단계를 분리합니다.
- 검증 단계는 validateOp 함수에 정의되어 있습니다. 이 함수는 두 번 호출됩니다. 첫 번째는 Bundler가 오프체인 검증을 시뮬레이션하고, UserOperation의 서명을 검증하고, 스마트 컨트랙트 지갑에 충분한 가스 잔액 있는지 확인할 때이고, 두 번째는 진입점 컨트랙트가 UserOperation을 실행하기 전에 온체인 검증을 수행할 때입니다.
- 실행 단계는 UserOperation의 calldata에 정의되어 있으며, 이는 스마트 계약 지갑 함수의 서명 및 입력 매개변수를 지정하는 데 사용됩니다.
Bundler는 UserOperation의 검증과 실행을 분리함으로써, UserOperation을 오프체인에서 검증하여 가스 비용 없이 악성 거래를 걸러낼 수 있습니다. 따라서 validateOp 함수는 오프체인 디버그 API 역할도 수행합니다.
5. 지불 계약(Paymaster)
Paymaster 계약은 스마트 계약 지갑 내 가스 추상화 로직을 정의합니다. 가스 추상화에는 ERC20 기반 토큰을 사용한 이더 이더 가스 지불과 가스가 필요 없는 거래가 포함되며, 두 가지 모두 Paymaster에서 구현할 수 있습니다. ERC-4337의 모듈형 설계 덕분에 UserOperation은 paymasterAndData 매개변수를 통해 임의의 Paymaster 주소와 입력 매개변수를 지정할 수 있습니다. Paymaster는 다음과 같은 기능과 요구 사항을 갖습니다.
- 기본적으로 Paymaster는 dApp에 의해 배포되는 스마트 컨트랙트입니다. Bundler를 통해 Paymaster의 validatePaymasterOp 함수를 트리거하여 임의의 로직을 통해 컨트랙트에 지정된 UserOperation에 대한 가스를 선택적으로 지불할 수 있습니다.
- Paymaster는 UserOperation 가스 비용을 지불하기 위해 진입점 계약에 이더 입금해야 합니다.
- Paymaster는 가스 예치 외에도 진입점 컨트랙트에 추가 이더 스테이킹 해야 합니다. 이 스테이킹 삭감되지 않지만, 로봇이 악의적으로 Paymaster를 대량으로 생성하는 것을 방지할 수 있습니다.
Paymaster(적어도 공식적인 비전에서는)는 경쟁적이고 개방적인 시장입니다. Paymaster를 위한 공식적인 온체인 평판 시스템은 없지만, 번들러는 Paymaster 서비스 품질을 오프체인에서 기록하고 품질이 낮은 Paymaster 사용을 중단할 수 있습니다. 이를 통해 Paymaster가 UserOperations에 안정적인 서비스를 제공하도록 유도할 수 있습니다.
Paymaster 인터페이스는 두 가지 기능을 정의합니다.
- validatePaymasterOp: 가스 추상화 로직을 정의합니다. 예를 들어, 스마트 컨트랙트 지갑이 ERC20 토큰으로 가스를 지불하는 경우, 이 함수는 지갑에 충분한 잔액 있는지 확인합니다. validatePaymasterOp는 UserOperation을 실행하기 전에 호출되며, 이는 검증 단계와 실행 단계를 분리하는 설계 로직에 부합합니다.
- postOp: 스마트 컨트랙트 지갑 함수 실행의 마지막 단계에서 호출됩니다. 지갑에 Paymaster에게 가스비를 지불할 ERC20 잔액 충분하지 않으면 postOp는 함수 실행을 취소합니다. 이 단계에서 런타임 오류로 인해 함수 실행이 실패하더라도 가스비는 차감됩니다.
그림: 공식 EIP 4337 문서의 Paymaster 워크플로
그림: 공식 EIP 4337 문서의 Paymaster 인터페이스
6. 월렛 팩토리
Wallet Factory는 스마트 컨트랙트 지갑을 생성하는 컨트랙트입니다. UserOperation에는 선택적인 initCode 필드가 있습니다. initCode가 비어 있으면 UserOperation은 스마트 컨트랙트 지갑의 기능을 트리거합니다. initCode에 Wallet Factory 주소와 새 스마트 컨트랙트 지갑의 매개변수가 입력되면 Bundler는 해당 Wallet Factory를 트리거하여 지정된 매개변수를 사용하여 스마트 컨트랙트를 생성합니다.
Wallet Factory는 다음과 같은 방법으로 계정 추상화를 용이하게 합니다.
- 사용자는 EOA가 없어도 initCode로 채워진 UserOperation을 제출하여 Bundler에 스마트 계약 지갑을 생성하도록 요청할 수 있습니다.
- 사용자는 특정 사용자 정의 옵션이 있는 Wallet Factory를 선택하고 자체 매개변수를 전달하여 스마트 계약 지갑을 사용자 정의할 수 있습니다. 또한, Wallet Factory 계약은 공개되어 있고 널리 사용되는 Wallet Factory는 포괄적인 코드 감사 거치기 때문에 사용자가 Wallet Factory를 사용하여 새 지갑을 생성하는 것이 더 안전합니다.
- 사용자는 이더 소유하지 않고도 Paymaster가 지갑 생성에 필요한 가스비를 지불하도록 하거나, ERC20 토큰을 사용하여 가스비를 지불하도록 선택할 수 있습니다. 또한, Paymaster는 신뢰할 수 있는 Wallet Factory에서 배포한 스마트 컨트랙트 지갑에 대해서만 가스비를 지불하도록 선택할 수 있습니다.
- 지갑을 생성하기 전에 사용자는 CREATE2 함수를 호출하여 스마트 계약 지갑 주소를 얻을 수 있습니다. 이 함수는 스마트 계약 지갑 생성을 트리거한 EOA 주소, 솔트, 그리고 initCode를 사용하여 스마트 계약 주소를 확정적으로 생성합니다. 사용자는 지갑 생성 시 가스를 지불할 필요가 없으며, 지갑에서 첫 번째 트랜잭션을 수행할 때 지갑 생성 비용과 트랜잭션 가스 비용만 지불하면 되므로 사용자 경험이 향상됩니다.
월렛 팩토리는 다른 책임도 있습니다. 페이마스터와 마찬가지로, 번들러에서 더 많은 트래픽을 확보하기 위해 진입점 컨트랙트에 ETH를 스테이킹하고 UserOperations에 지속적으로 좋은 서비스를 제공해야 합니다.
7. 서명 수집기
서로 다른 스마트 컨트랙트 지갑은 서로 다른 서명 알고리즘을 사용하기 때문에, 동일한 서명 알고리즘을 사용하는 UserOperations는 먼저 집계된 후 개별적으로 검증되어야 합니다. 또한, 온체인 암호화 계산에는 대량 의 가스가 소모되므로, 집계를 지원하는 서명 방식(예: BLS)은 온체인 검증 과정에서 가스를 절약할 수 있습니다 . 따라서 Signature Aggregator라는 EIP 4337 스마트 컨트랙트 인터페이스가 필요합니다. 이 인터페이스는 다음 두 가지 함수를 구현하여 특정 서명 알고리즘을 지원할 수 있습니다.
- aggregateSignatures: 입력 매개변수는 UserOperations 배열이며, 특정 서명 알고리즘을 사용하여 집계 서명을 출력합니다.
- validateSignatures: 입력 매개변수는 UserOperations 배열과 집계 서명입니다. 집계 서명은 배열에 있는 모든 UserOperations의 서명을 확인하는 데 사용됩니다.
Bundler는 UserOperations를 한 번에 하나씩 검증하는 대신, 먼저 여러 서명 집계자 계약(서명 알고리즘당 하나씩)을 사용하여 여러 개의 집계 서명(서명 알고리즘당 하나씩)을 생성합니다. 그런 다음 Bundler는 UserOperations 배열, 집계 서명, 그리고 집계자 주소를 진입점 계약에 전달합니다. 각 UserOperation 배열은 해당 서명 집계자의 validateSignature 함수를 호출합니다. 검증이 완료되면 Bundler는 스마트 계약 지갑에서 UserOperations 집합을 실행합니다.
Paymaster와 Wallet Factory와 마찬가지로, 애그리게이터 역시 진입점 계약에 이더 스테이킹 하고 UserOperations에 대한 양호한 서비스 제공 기록을 유지해야 합니다.
그림: 공식 EIP 4337 문서의 서명 집계기 인터페이스
8. 전체 워크플로우 요약
EIP 4337의 모듈형 설계는 스마트 계약 지갑의 계정 추상화 기능을 여러 인터페이스로 나눕니다. 이러한 인터페이스의 기능은 다음과 같은 워크플로우로 요약할 수 있습니다.
- 사용자는 Bundler에 UserOperation을 보냅니다.
- UserOperation이 initCode 매개변수를 채우면 Bundler는 Wallet Factory를 트리거하여 특정 주소로 새 지갑을 생성합니다.
- UserOperation에 paymasterAndData 매개변수가 입력되면 Bundler는 Paymaster가 진입점 컨트랙트에 스테이킹 이더 수집하여 가스비를 지불합니다. paymasterAndData가 입력되지 않으면 Bundler는 스마트 컨트랙트 지갑이 진입점 컨트랙트에 스테이킹 이더 수집하여 가스비를 지불합니다.
- Bundler는 선택적으로 서명 집계기를 사용할 수 있습니다.
- Bundler는 validateOp, validatePaymasterOp, validateSignatures 함수를 사용하여 UserOperation을 오프체인으로 시뮬레이션하고 검증하여 서명이 정확하고 UserOperation에 충분한 가스가 있는지 확인합니다.
- 오프체인 시뮬레이션 검증이 통과되면 Bundler는 위 함수를 사용하여 온체인 UserOperation을 검증합니다.
- 온체인 검증이 통과되면 Bundler는 온체인 에서 UserOperation을 실행합니다. 실행 성공 여부와 관계없이 가스가 차감됩니다.
그림: 서명 집계기가 없는 계정 추상화 워크플로(Alchemy 제공)
그림: 서명 집계기를 사용한 계정 추상화 워크플로(Alchemy 제공)
9. 기타 참고사항
UserOperation은 트랜잭션 검증을 위해 오프체인과 온체인 모두에서 validateOp와 같은 함수를 트리거합니다. 스마트 월렛 계약 외부의 상태 변경으로 인해 오프체인과 온체인 간의 검증 결과가 일치하지 않는 것을 방지하기 위해, EIP 4337은 검증 함수가 외부 저장소 또는 전역 상태(예: 타임스탬프)를 읽는 OpCode를 사용하는 것을 금지합니다. 이 금지 사항은 validateOp, validatePaymasterOp, validateSignatures와 같은 검증 함수에도 적용됩니다.
2부: 계정 추상화 시장 참여자
1. 스마트 컨트랙트 지갑 및 지원 SDK
스마트 컨트랙트 지갑은 계정 추상화 시장에서 가장 큰 비중을 차지하는 플랫폼입니다. EIP 4337과의 호환성을 확보하기 위해 일반적으로 자체 번들러, 페이마스터, 지갑 팩토리, 서명 애그리게이터를 구현합니다. 이러한 지갑에는 dApp 통합을 지원하는 SDK도 함께 제공됩니다. 스마트 컨트랙트 지갑 시장은 상당히 포화 상태이며, 다중 서명 지갑인 Gnosis Safe와 같은 기존 업체들은 기존 제품에 계정 추상화 기능을 구현하고 있는 반면, Candide와 같은 신규 업체들은 EIP 4337과 완벽하게 호환되는 스마트 컨트랙트 지갑 개발에 집중하고 있습니다. 이 섹션에서는 이러한 지갑의 공통적인 기능과 차이점을 설명합니다.
a. 소셜 로그인 및 소셜 복구
소셜 로그인은 기존 Google 계정을 사용하여 지갑을 생성하고 로그인하는 등 Web2 사용자에게 익숙한 상호작용 경험을 스마트 컨트랙트 지갑에 제공합니다. 이와 동일한 로직을 소셜 복구에도 확장하여 이메일 주소를 사용하여 스마트 컨트랙트 지갑의 비밀번호를 재설정할 수 있습니다. 소셜 로그인 및 복구 로직은 일반적으로 지갑의 메인 컨트랙트에 정의됩니다.
여기서는 가디언(Guardian)의 개념을 소개합니다. 가디언은 사용자에게 계정 접근 권한을 부여하거나 계정 복구를 지원하는 개체입니다. 가디언은 Web2 계정이나 이메일 주소일 수 있습니다. 이 개념은 Web2에서 널리 사용되어 왔으며, 이제 계정 추상화 개념을 통해 스마트 계약 지갑에 구현될 수 있습니다.
스마트 계약 지갑에는 여러 명의 가디언이 있을 수 있습니다. 사용자는 지갑 생성 중 또는 생성 후에 가디언을 설정하고, 특정 가디언 검증 기준(예: 3명 중 2명)을 충족해야 지갑에 로그인하거나 복원할 수 있습니다. 이 프로세스를 다중 요소 인증 이라고 합니다. 다음은 일반적인 스마트 계약 지갑 가디언 유형입니다.
- 지갑 사용자의 소셜 미디어 계정과 같은 웹2 서비스 제공자는 일반적으로 OAuth(Open Authorization) 표준을 구현하여 구현됩니다. 이 표준을 통해 지갑은 다른 웹2 애플리케이션에서 호스팅되는 사용자 계정 정보에 접근할 수 있는 사용자 권한을 얻을 수 있습니다.
- 사용자 장치: 브라우저 저장소 및 모바일 저장소 등
- 이메일: 예를 들어, 서명을 보내는 이메일의 링크를 클릭하는 경우
- 다중 서명: 사용자는 여러 개인 소유의 EOA 또는 스마트 계약 지갑을 보호자로 설정할 수 있습니다.
- MPC: 사용자는 개인 키를 여러 개의 점유율 로 분할할 수 있으며, 점유율 MPC 네트워크의 노드에서 제어되므로 전체 키가 공개되지 않습니다.
- SWIE(이더 으로 로그인)
일부 시장 참여자가 이 기능을 어떻게 구현했는지 살펴보겠습니다.
- Web3Auth는 Biconomy, Etherspot, 0xPass를 포함한 많은 트래픽이 많은 스마트 컨트랙트 지갑에서 사용되는 소셜 로그인 및 MPC 서비스입니다. Web3Auth는 사용자 키를 여러 개의 공유 키로 분할하여 소셜 로그인, 사용자 기기, MPC 노드 네트워크 등 다양한 가디언에게 분배합니다. 이 제품의 로직은 완전히 오프체인으로 구현되며, 단일 가디언이 전체 개인 키를 저장하지 않습니다. (아래 다이어그램 참조)
- BLS Wallet과 Argent는 사용자가 지정한 여러 EOA 주소를 통해 키를 복구하기 위해 다중 서명 기술(multisig)을 사용합니다.
- UniPass는 이메일을 통한 혁신적인 소셜 복구 방식을 구현합니다. 사용자는 온체인 보호자의 이메일 주소를 제출하고, 스마트 컨트랙트는 해당 이메일의 DKIM 서명을 온체인 검증합니다. DKIM(Domain Keys Identified Mail)은 디지털 서명을 생성하는 데 사용되는 이메일 인증 프로토콜입니다. 이메일 제공자는 이 디지털 서명을 사용하여 이메일 발신자의 신원을 확인할 수 있습니다. UniPass는 또한 영지식 증명을 사용하여 온체인 사용자 정보를 안전하게 보호합니다. UniPass는 이메일 외에도 다양한 소셜 복구 방식을 지원합니다.
- Soul Wallet은 소셜 복구를 위해 온체인 보호자의 이메일 주소를 검증합니다.
그림: Web3Auth 소셜 로그인 및 소셜 복구(이 경우 보호자 3명 포함)
b. 가스 추상화(가스는 거래 수수료)
가스 추상화에는 가스 비용 없이 거래하고 ERC20 토큰을 사용하여 가스 비용을 지불하는 것이 포함됩니다. 이 로직은 Paymaster 계약이나 릴레이어를 통해 구현될 수 있습니다.
많은 스마트 계약 지갑은 EIP 4337과 호환되는 자체 Paymaster 계약을 구현하고 사용자가 가스 비용을 지불할 수 있도록 진입점 계약에 토큰을 스테이킹.
릴레이어는 EIP 4337 이전에 존재했던 또 다른 가스 추상화 솔루션입니다. 릴레이어는 메타 트랜잭션이라는 특수한 유형의 가스리스 트랜잭션을 실행하는 신뢰할 수 있는 트랜잭션 포워더입니다. 메타 트랜잭션은 원래 트랜잭션에 다른 트랜잭션을 삽입하는 이더 트랜잭션입니다. 사용자는 개인 키로 메타 트랜잭션에 서명하고 릴레이어에게 전송합니다. 릴레이어는 이를 검증하고 블록체인에 제출한 후 가스 비용을 지불합니다. 릴레이어는 트랜잭션 자체를 변경하지 않고 트랜잭션을 실행합니다. 릴레이어는 트랜잭션을 실행하는 계약에 가스 수수료와 소액의 수익을 부과하기 때문에 재정적 이익을 얻습니다. 예를 들어, 릴레이어는 가스리스 트랜잭션을 지원하는 탈중앙화 애플리케이션(dApp)에 수수료를 부과할 수 있습니다. 릴레이어는 중앙화된 신뢰할 수 있는 제3자 또는 탈중앙화 네트워크일 수 있습니다. 릴레이어는 다음과 같은 점에서 페이마스터와 다릅니다.
- Relayer는 가스 비용을 지불하는 것 외에도 거래에 서명하는데, 이는 EIP 4337의 Bundler가 하는 일과 유사합니다.
- Relayer는 UserOperations 유형 트랜잭션만 처리하지 않습니다.
- 중계자는 진입점 계약에 가스를 스테이킹 하지 않습니다.
일부 시장 참여자가 이 기능을 어떻게 구현했는지 살펴보겠습니다.
- Biconomy는 EIP 4337과 호환되는 자체 Paymaster를 구현했을 뿐만 아니라, 가스 비용을 지불하기 위해 모든 ERC20 토큰을 지원하는 Relayer 네트워크도 갖추고 있습니다.
- Argent는 제3자 중계자를 사용하여 메타 거래 형태로 가스 비용을 지불합니다.
- 칸디드는 스스로 Paymaster를 구현했습니다.
- UniPass는 자체 Relayer 노드를 사용하여 가스 비용을 지불하고, 앞으로는 "광고 시청 시 가스 비용 없이 거래" 모드를 추가하고 크로스 체인 브리지를 사용하여 가스 비용을 지불할 수 있도록 지원할 계획입니다.
지금까지 대부분의 ERC20 가스 결제 솔루션(예: Candide 및 Soul Wallet)은 주로 스테이블코인인 매우 제한된 범위의 토큰 유형만 지원하지만, 앞으로는 이러한 상황이 바뀔 것으로 예상합니다.
그림: Biconomy는 Paymaster를 사용하여 가스가 필요 없는 거래를 지원합니다(EIP 4337 기반)
그림: Biconomy는 Relayer를 통해 가스 비용을 지불하기 위해 ERC20을 사용합니다(EIP 4337 기반 아님)
c. 법정 화폐 입출금 램프 및 교차 체인 브리지
MetaMask와 같은 많은 기존 지갑은 타사 공급업체와의 협력을 통해 법정화폐 입출금 램프와 크로스 체인 브리지를 지갑에 통합했습니다. 이러한 입출금 램프와 크로스 체인 브리지는 가스 추상화 내에서 Paymaster 계약과 추가로 통합될 수 있습니다.
일부 시장 참여자가 이 기능을 어떻게 구현했는지 살펴보겠습니다.
- Biconomy와 0xPass는 Transak과 파트너십을 맺고 법정화폐 온램프를 제공합니다. Biconomy는 또한 크로스체인 브릿지와 크로스체인 커뮤니케이션 서비스를 제공합니다.
- Argent Vault는 Moonpay, Transak, Wyre와 협력하여 법정 화폐 온램프를 제공하고 있으며 DeFi 프로토콜 애그리게이터를 내장하고 있습니다.
- Etherspot, UniPass, Braavos는 법정화폐 채널, 스왑, 크로스체인 브리지를 지원합니다.
d. 거래 배칭
트랜잭션 배칭은 스마트 컨트랙트 지갑의 고유한 기능으로, 지갑 사용자가 단일 온체인 트랜잭션 내에서 여러 트랜잭션을 실행할 수 있도록 합니다. 한 가지 구현 방식은 multiCall 함수를 호출하는 것입니다. 이 함수는 두 개의 매개변수를 받습니다. 하나는 calldata 배열(각 calldata는 함수 호출을 정의함)이고, 다른 하나는 contract 주소 배열(각 함수 호출의 contract 주소)입니다. multiCall 함수는 루프를 포함하고 있으며, 각 루프 내에서 하나의 함수 호출을 실행합니다. 트랜잭션 배칭을 사용하면 여러 트랜잭션이 단일 이더 트랜잭션의 고정 가스 수수료를 공유할 수 있어 비용을 절감할 수 있습니다.
트랜잭션 배칭은 서명 집계와는 다릅니다. 서명 집계는 UserOperation 배열을 입력으로 받고 집계된 서명 바이트를 출력하여 여러 서명 검증 속도를 높입니다. 이 배열의 각 UserOperation은 multiCall을 호출하여 트랜잭션 배칭을 수행할 수 있습니다.
EIP 4337에서 거래 배칭이 구현되는 방식은 다음과 같습니다. 진입점 계약은 handleOp 함수를 호출하고, 이 함수는 스마트 계약 지갑 메인 계약에 정의된 multiCall 함수를 호출합니다.
일부 시장 참여자가 이 기능을 어떻게 구현했는지 살펴보겠습니다.
- Biconomy는 스마트 계약 지갑에서 호출하여 일괄적으로 거래를 실행할 수 있는 MultiCall 계약을 설정합니다.
- Argent는 멀티콜과 사용자 세션 키를 지원하는 Transaction Manager라는 스마트 계약 모듈을 통해 일괄적으로 거래를 실행합니다.
- Etherspot, Candide, Openfort, 0xpass는 모두 트랜잭션 배칭을 지원합니다.
그림: MultiCall 계약 예시(Solidity by Example 제공)
e. 스마트 계약 지갑의 모듈식 디자인
스마트 계약 지갑이 EOA에 비해 갖는 주요 장점은 모듈식 설계입니다. 지갑 기능은 지갑 제공업체가 개발한 계약 모듈을 통해 확장할 수 있습니다. 이러한 모듈은 EIP 4337 인터페이스에 정의되지 않은 기능을 제공하며 사용자가 직접 설정할 수 있습니다. 이러한 모듈식 설계 덕분에 스마트 계약 지갑은 업그레이드가 가능합니다. 이러한 방식은 EIP 4337 출시 이전부터 Gnosis Safe와 같은 제품을 통해 업계 표준으로 자리 잡았습니다. Gnosis Safe는 주로 비즈니스 사용자를 대상으로 하는 다중 서명 지갑으로, EIP 4337에 정의되지 않은 다양한 기능을 제공합니다.
- 지출 한도: 서명 권한이 있는 계정이 지갑에서 클레임 할 수 있는 금액을 제한합니다.
- 정기 결제: 사용자 정의된 일정에 따라 자동으로 결제합니다.
- 역할 및 권한 부여: 다양한 지갑 거래 및 동작에 필요한 역할과 권한을 정의합니다.
- 조직 권한: 조직 내의 다양한 역할에 따라 권한을 설정합니다.
- 허용 목록과 차단 목록
동일한 모듈형 디자인은 Argent, Candide, Soul Wallet, zeroDev를 포함한 EIP 4337 호환 지갑에서도 계승되었습니다.
스마트 컨트랙트 지갑의 기능을 확장하는 또 다른 방법은 지갑 내에 탈중앙화 애플리케이션(dApp)을 기본적으로 통합하는 것입니다. 예를 들어, Gnosis Safe는 dApp용 SDK를 제공합니다. 이 SDK를 사용하면 dApp이 지갑 인터페이스 내에 직접 표시되어 사실상 내장 앱 스토어를 제공합니다. 다른 유사한 솔루션으로는 WalletConnect가 있습니다. 그러나 이러한 프런트엔드 솔루션은 프로토콜 수준에서 설계되지 않았으므로 본 문서의 범위를 벗어납니다.
그림: Candide 지갑의 모듈식 디자인은 Gnosis Safe의 모듈식 디자인과 유사합니다(Candide 지갑 웹사이트 제공)
2. 인프라 제공업체
다음 섹션에서는 번들러와 결제자를 위한 계정 추상화와 타사 인프라 공급자를 위한 다양한 레이어 2 지원에 대해 설명합니다.
a. 레이어 2의 계정 추상화
최근 L2의 폭발적인 성장세에 힘입어 많은 스마트 컨트랙트 지갑이 L2로 개발 방향을 전환했습니다. 많은 L2 지갑이 기본적으로 계정 추상화 계약(ACC) 표준을 지원하는데, 이는 EIP 4337과 매우 유사하며 이 섹션에서 자세히 살펴보겠습니다.
낙천주의
Optimism의 첫 번째 버전은 EVM에서 지원하지 않는 세 가지 OVM OpCode를 도입하여 계정 추상화를 구현했습니다. Optimism의 기술 구현에서는 스마트 컨트랙트가 유일한 계정 유형(EOA 없음)이므로 모든 사용자 지갑은 스마트 컨트랙트 지갑입니다. 스마트 컨트랙트 지갑은 업그레이드 함수를 호출하여 컨트랙트 코드를 업그레이드할 수도 있습니다.
안타깝게도 EVM과의 완벽한 일관성을 유지하고 보안상의 이유로 Optimism의 두 번째 버전에서는 이 세 가지 OVM Opcode와 계정 추상화 지원이 제거되었습니다.
현재 소수의 스마트 계약 지갑이 Optimism을 기반으로 구축되고 있지만, 계정 추상화 지원에 대한 공식 발표는 없습니다.
중재
현재 Arbitrum에서 소수의 스마트 계약 지갑이 구축되고 있지만, 계정 추상화 지원에 대한 공식 발표는 없습니다.
스타크넷
이더 달리 스타크넷은 EOA와 컨트랙트 계정을 구분하지 않습니다. 따라서 모든 스타크넷 계정은 스마트 컨트랙트 계정입니다. 스타크넷의 계정 모델은 EIP 4337의 영향을 크게 받으며, 특히 다음과 같은 측면에서 영향을 받습니다.
- 모든 Starknet 스마트 계약 계정에는 검증 및 실행 함수가 포함되어야 합니다. 검증 함수는 필수이며, 서명을 검증하여 계정 소유자만 거래를 시작할 수 있고 거래 실행자가 충분한 가스 수수료를 받을 수 있도록 보장합니다. 사용자는 검증 및 실행 함수에 임의의 로직을 구현하여 계정 기능을 유연하게 확장할 수 있습니다. 예를 들어, 사용자는 검증 함수에 다양한 서명 검증 알고리즘을 구현할 수 있습니다.
- 거래가 검증되었지만 실행되지 않는 것을 방지하기 위해 Starknet은 검증 함수가 외부 계약 상태를 호출하는 것을 금지합니다.
Starknet의 계정 추상화 구현은 여전히 이더 과 상당한 차이점이 있습니다.
- Starknet은 모든 트랜잭션이 컨트랙트 계정에 의해 트리거되므로 일반 트랜잭션과 UserOperations를 구분하지 않습니다. 이더 에서는 Bundler가 UserOperation 트랜잭션을 실행하는 반면, Starknet에서는 Sequencer가 모든 트랜잭션을 실행합니다.
- Starknet은 아직 Paymaster와 유사한 거래 수수료 추상화 프로토콜을 구현하지 않았습니다.
- Starknet은 전용 deploy_account 함수를 호출하여 새 계약 계정을 생성하려면 토큰 잔액 있는 계정이 필요합니다. 그러나 EIP 4337에서 Bundler는 비어 있지 않은 initCode 매개변수를 사용하여 UserOperation 트랜잭션을 실행하여 계약 계정을 배포합니다. 이 배포 프로세스에는 토큰 잔액 있는 계정이 필요하지 않습니다. 가스비는 Paymaster가 지불할 수 있기 때문입니다.
- 검증된 거래가 실행 단계에서 실패하면 Starknet의 시퀀서는 가스 수수료를 추출할 수 없지만 이더 이런 문제가 없습니다.
그림: Starknet에는 EOA 계정 유형이 없으며 계약 계정만 있습니다(사진 제공: Starknet 공식 웹사이트)
zkSync
zkSync는 EOA와 계약 계정을 구분하지 않으므로 기본적으로 계정 추상화를 지원합니다. zkSync의 계정 모델은 EIP 4337과 매우 유사하며, 특히 다음과 같은 측면에서 유사합니다.
- 계정(스마트 계약 지갑) 인터페이스는 validateTransaction과 executeTransaction 함수도 분리합니다.
- Paymaster 계약 인터페이스에는 validateAndPayForPaymasterTransaction 및 postOp 함수도 포함되어 있습니다. 전자는 Paymaster의 결제 거래 로직을 정의합니다. 후자는 거래 실행 후 Paymaster가 가스 수수료 보상을 받을 수 있도록 보장하지만, 아직 구현되지 않았습니다.
- 사용자는 EIP 4337의 UserOperation과 유사하게 거래에서 paymaster 주소와 paymasterInput 매개변수를 입력하여 Paymaster를 호출합니다.
하지만 zkSync가 구현한 계정 추상화도 이더 과 상당히 다릅니다.
- zkSync에서는 배포된 컨트랙트가 변경 불가능하기 때문에 validateTransaction 함수가 배포된 외부 컨트랙트를 호출할 수 있습니다. 이더 트랜잭션 검증은 통과하지만 트랜잭션 실행은 실패할 수 있는 상태 변화를 방지하기 위해 검증 함수가 외부 컨트랙트를 호출하는 것을 금지합니다.
- zkSync는 validateTransaction이 이 트랜잭션을 발행하는 계약 계정의 외부 저장소(예: 외부 계약의 계약 계정 토큰 잔액) 를 호출하도록 허용합니다. 이는 위와 같은 이유입니다.
- 거래 검증 중에 Paymaster는 위와 같은 이유로 외부 저장소에 접근할 수 있습니다.
b. 제3자 인프라 제공자(스마트 계약이 아닌 지갑)
위에서 언급했듯이, 계정 추상화 인프라에는 UserOperations, 번들러, 페이마스터, 서명 애그리게이터를 전송할 수 있는 클라이언트 SDK가 포함됩니다. 이 인프라는 종종 스마트 계약 지갑 자체에 의해 구현되어 상류 및 하류 산업과의 통합을 향상시킵니다. 그러나 대부분은 제3자 사용을 위해 설계되지 않았습니다. 따라서 모듈화되고 사용자 정의 가능한 번들러 및 페이마스터 서비스를 제공하는 제3자 인프라 제공업체가 필요합니다. Alchemy와 같은 유명 인프라 업체들이 이 시장에 진출했습니다. 이 섹션에서는 이러한 제3자 인프라 제공업체에 대해 자세히 살펴보겠습니다.
스택업
Stackup은 번들러이자 페이마스터 서비스 제공업체입니다. Stackup 번들러는 Go 언어로 구현되었으며, 모든 EIP 4377 테스트 스위트 요건을 충족하고, 완전 오픈 소스이며 무료로 사용할 수 있습니다. Stackup 번들러는 다양한 모드를 지원합니다.
- 비공개 모드: UserOperations는 비공개 메모리 풀에 진입하여 트랜잭션 실행 속도를 낮추는 대신 개인 정보 보호 기능을 강화합니다. UserOperations는 공개 메모리 풀에 표시되지 않으므로 MEV 공격을 방지할 수 있습니다.
- 검색 모드: 이더 생태계의 봇 운영자(DeFi 중재 봇과 같은 검색자라고도 함)가 사용하고 Flashbot과 같은 블록 빌더와 통합하여 MEV-Boost를 통해 UserOperations를 전송하여 검색자가 특정 거래 순서 에 입찰할 수 있도록 하여 블록 빌더가 가장 큰 MEV를 가진 거래 순서 선택하여 블록을 구축할 수 있도록 합니다.
Stackup은 또한 두 가지 유형의 Paymasters를 지원합니다.
- 검증 Paymaster: 오프체인 거래(예: 법정화폐 입출금)를 요구하는 거래에 대한 가스 추상화를 제공합니다. 예를 들어, 사용자는 Paymaster 서비스에 가입하여 신용카드로 가스비를 결제할 수 있습니다. 가스비 결제 로직을 사용자 지정할 수도 있습니다. Stackup은 "pay as you go" 모델을 통해 사용자에게 요금을 부과합니다.
- Deposit Paymaster: 사용자가 ERC20 토큰으로 가스 수수료를 지불할 수 있습니다.
그림: Stackup의 인프라 제품군
블록네이티브
Blocknative는 주로 멤풀 탐색기 및 시각화 도구 제공업체입니다. 멤풀에 대한 깊은 이해를 바탕으로 Blocknative는 다음과 같은 고유한 기능을 갖춘 번들러 서비스를 제공합니다.
- EIP 4337 UserOps Explorer를 사용하여 메모리 풀의 UserOperations 상태를 시각화하면 지갑과 dApp에서 실시간으로 거래 상태를 모니터링하기가 더 쉬워집니다.
- Blocknative의 핵심 제품인 mempool 탐색기는 진입점 계약에서 보류 중인 Bundler 거래와 확인된 Bundler 거래도 모니터링할 수 있습니다.
연금술
Alchemy는 현재 Bundler와 Paymaster 서비스를 개발 중이며, 잠재적 사용자는 대기자 명단에 참여할 수 있습니다.
그림: Alchemy의 EIP 4337 인프라 서비스는 아직 개발 중입니다.
eth-무한주의
eth-infinitism은 EIP 4337 표준에 정의된 Bundler와 Paymaster를 구현한 이더 재단 공식 팀입니다. 이 팀에 대한 문서는 거의 없지만, Stackup의 한 기사에 따르면 2023년 2월 기준으로 eth-infinitism은 공식 EIP 4337 테스트 스위트를 통과한 두 개의 번들러(다른 하나는 Stackup) 중 하나입니다.
제3부: 계정 추상화의 미래
1. 궁극적으로 계정 추상화 시장의 생존은 생태계가 EIP 4337을 채택하는 데 달려 있으며, 이 시장은 아직 초기 단계에 있습니다.
Web3Caff Research의 최근 보고서에 따르면, 모든 이더 거래에서 매개변수를 통해 중복 제거된 발신 주소의 총 수는 약 1억 5천만 개입니다. 그러나 사용자가 가장 많은 두 제품인 Gnosis Safe와 Argent 계정을 합친 기준으로 추정한 스마트 계약 지갑의 총 수는 15만 개에 불과합니다.
EOA 지갑과 스마트 컨트랙트 지갑의 수가 궁극적으로 동일하다고 가정하면, 스마트 컨트랙트 지갑 시장은 1,000배 성장할 잠재력을 가지고 있다고 예측할 수 있습니다. 그러나 스마트 컨트랙트 지갑의 생태계 도입은 순탄치 않을 것입니다. MetaMask와 같은 주요 EOA 지갑 회사들은 아직 EIP 4337 도입 계획을 발표하지 않았습니다. 그들의 의도는 알 수 없지만, 주요 EOA 지갑의 상당한 수익이 불완전한 인프라를 가진 새로운 표준을 도입하는 것을 정당화하지는 못한다는 것을 쉽게 유추할 수 있습니다. UserOperation은 아직 dApp에서 널리 사용되는 거래 유형이 아닙니다. 그럼에도 불구하고 저는 스마트 컨트랙트 지갑 시장에 대해 낙관적이며, 스마트 컨트랙트 지갑이 제공하는 사용자 경험의 상당한 개선이 계정 추상화 시장의 기하급수적 성장을 이끌 것으로 예상합니다. 하지만 이러한 폭발적인 성장은 아직 1~2년 더 걸릴 수 있습니다.
2. EIP 4337은 아직 완성되지 않았으며 동지들은 여전히 열심히 일해야 합니다.
EIP 4337은 번들러, 페이마스터, 서명 애그리게이터와 같은 인프라에 대한 계약 인터페이스를 정의하고 있지만, 이더 아직 여러 중요한 기술적 문제에 대한 공식적인 해결책을 제시하지 못했습니다. 이러한 문제들은 프로젝트 개발자들이 다음과 같은 다양한 기술적 구현을 반복적으로 시도해야 함을 의미합니다.
- 현재 Bundler는 주로 프라이빗 멤풀에서 트랜잭션을 브로드캐스트 하고, UserOperations는 지정된 블록 빌더에게 직접 전송됩니다. Bundler 네트워크에서 퍼블릭 멤풀을 사용할 수 있을까요?
- 번들러가 UserOperations를 순서 하여 MEV를 추출할 수 있나요? 블록 빌더가 번들을 순서 하여 MEV를 추출할 수 있나요? 번들러와 블록 빌더 간에 MEV가 어떻게 분배되나요? 번들러와 블록 빌더를 분리해야 하나요?
- Bundler가 오프체인 시뮬레이션과 온체인 검증을 대량 수행해야 한다는 점을 감안할 때, Bundler가 신뢰할 수 있는 블록 빌더 역할도 할 수 있을까요?
- 상태 충돌을 피하기 위해 UserOperation 메모리 풀과 일반 트랜잭션 메모리 풀을 어떻게 조정해야 합니까?
3. 다양한 속도에서 EIP 4337의 L2 채택
zkSync와 Starknet은 이미 계정 추상화를 기본적으로 지원하지만 , 아직 모든 EIP 4337 인터페이스를 구현하지 않았으며 기술 구현 방식도 이더 과 다릅니다. 많은 프로젝트팀이 Optimism과 Arbitrum을 위한 스마트 계약 지갑, 번들러, 페이마스터를 개발하고 있지만, 이러한 L2 프로젝트들은 EIP 4337 지원 계획을 공식적으로 발표하지 않았으며, 계정 추상화는 개발 우선순위가 아닙니다.
순전히 기술적인 관점에서 볼 때, L2 계정 추상화 인프라 구현은 L1보다 더 복잡합니다 . 예를 들어, 검증 단계에서 L2 스마트 계약 지갑은 L1 및 L2 가스 요금을 모두 추정하여 번들의 각 UserOperation에 할당해야 합니다.
4. 기술적 세부 사항은 제쳐두고, 좋은 스마트 계약 지갑은 어떤 기능을 갖춰야 할까요?
지갑 시장에는 가스 추상화, 소셜 복구, MPC 등 혁신적인 기능이 많이 있지만, 대부분의 스마트 계약 지갑은 이러한 기능의 기술적 구현이 어렵지 않기 때문에 위의 모든 기능을 지원합니다. 따라서 스마트 계약 지갑의 비즈니스 측면은 사용자 경험만큼 중요합니다. 중요한 비즈니스 요소는 다음과 같습니다.
- dApp과의 협업: 각 L1 또는 L2 체인의 트래픽 엔트리 레벨 dApp, 특히 인프라 dApp(예: 스테이블코인 또는 DeFi 프로토콜)과의 협업은 사용자를 유치하는 주요 방법입니다.
- 실용적인 기능: 지갑에 통합된 NFT 시장, 런치패드 또는 새로운 거래 쌍의 빠른 수집 등
- 외부 지원: VC 또는 이더 Foundation의 공식 지원과 같이 지갑이 첫 번째 사용자를 찾는 데 도움이 될 수 있습니다.
5. 좋은 번들러는 어떤 기능을 가져야 할까요?
허가가 필요 없고 모듈화된 Bundler 서비스는 공공재입니다. 대부분의 Bundler 서비스는 오픈 소스이기 때문에 배제성과 경합성이 없습니다. 모든 RPC 엔드포인트는 오픈 소스 코드를 포킹하여 Bundler를 실행할 수 있습니다. Bundler를 실행하는 RPC 엔드포인트가 API 키를 통해 서비스 사용료를 부과하더라도, Bundler 서비스는 Paymasters와 같은 다른 인프라보다 수익 창출이 어렵습니다. Paymasters는 제3자 입출금 제공업체 또는 DeFi 프로토콜 애그리게이터와의 파트너십을 통해 수수료 차액을 쉽게 얻을 수 있습니다. Bundler는 상용화하기는 어렵지만, UserOperations의 검증 및 실행에 가능한 탈중앙화 많은 Bundler의 참여가 필요하기 때문에 중요한 공공재입니다. Stackup과 eth-infinitism은 현재 이용 가능한 두 개의 유일한 제3자 Bundler 서비스 제공업체이므로, 의심할 여지 없이 더 많은 Bundler가 필요합니다.
번들러 서비스 제공자는 다음과 같은 많은 기술적 어려움을 극복해야 합니다.
- UserOperations가 성공적으로 실행될 수 있도록 여러 오프체인 및 온체인 검증 단계에 대한 심층 연구를 수행했습니다. 기술적 어려움으로는 여러 UserOperations 간에 발생할 수 있는 상태 충돌을 이해하는 것이 있습니다.
- 검증 기능을 통해 특정 OpCode를 비활성화하는 방법 이해:
- 변경 가능한 외부 상태를 읽으면 트랜잭션 검증은 성공하지만 실행은 실패할 수 있으므로 EIP 4337은 검증 기능이 외부 상태를 읽는 OpCode를 호출하는 것을 금지합니다.
- L2마다 외부 상태를 읽는 OpCode에 대한 비활성화 정책이 약간씩 다르기 때문에 멀티체인 개발에 어려움이 있을 수 있습니다.
- Bundler를 빌드하는 프로젝트는 traceCall 함수를 사용하여 각 함수 호출의 OpCode를 얻어야 합니다. 그러나 대부분의 타사 RPC 노드는 traceCall을 지원하지 않으므로 Bundler 프로젝트는 자체 노드를 실행해야 할 수 있으며, 이 또한 기술적 장벽이 됩니다.
- 현재, 대부분의 Bundler 프로젝트 개발자는 L2에 집중하고 있으며, L1과 L2에 대한 가스 요금을 별도로 계산해야 합니다.
- 프라이빗 및 퍼블릭 메모리 풀을 갖춘 P2P 네트워크를 구현합니다. 프라이빗 메모리 풀은 화이트리스트 작성과 같은 검색 엔진 및 dApp에 맞춤형 서비스를 제공해야 합니다. 퍼블릭 UserOperation 메모리 풀에 대한 업계 표준은 아직 완성되지 않았습니다.
번들러 서비스 제공자는 다음과 같은 측면에서 차별화됩니다.
- Bundler 서비스는 지갑에 맞게 특별히 구축된 것인가요, 아니면 제3자 인프라 공급업체가 구축한 것인가요?
- Bundler는 지갑 프로젝트에서 구축해야 하는 여러 요소 중 하나일 뿐이므로, 지갑에 기본적으로 사용할 수 있는 Bundler를 구축하는 데 집중할 가능성이 더 높습니다.
- 타사 인프라 제공자는 허가 없이 사용할 수 있는 모듈식 번들러를 구축하고 다양한 시나리오에 맞는 고품질 서비스를 제공해야 합니다.
- 이더 노드와 마찬가지로 번들러 서비스는 다양한 언어로 구현됩니다. 이러한 언어의 다양성은 단일 장애 지점을 방지하고 이더 생태계에 도움이 됩니다.
- 개인 및 공용 메모리 풀을 지원하고 개인 메모리 풀을 사용자 정의하는 옵션을 제공합니다.
- L1 및 다양한 L2 체인을 지원하며, 각각 인터페이스 구현이 약간씩 다릅니다.
6. 혁신에 대해 이야기해 보자
이 섹션에서는 스마트 계약 지갑과 계정 추상화 인프라에서 가장 필요한 혁신을 나열합니다.
허가 없이 모듈화된 EIP 4337 인프라
먼저 EIP 4337 인프라의 최종 단계를 상상해 보겠습니다.
- 많은 번들러, 페이마스터, 그리고 서명 수집업체들이 개방된 시장에서 경쟁하게 될 것입니다. 사용자는 최저 비용으로 고품질 서비스를 받을 수 있습니다.
- Bundler, Paymaster, Signature Aggregator에는 허가가 필요 없는 공개 엔드포인트가 있으며, 스마트 계약 지갑이나 dApp에 특별히 배포된 엔드포인트도 있습니다.
- 스마트 컨트랙트 지갑, dApp 및 개별 사용자는 앞서 언급한 인프라를 허가 없이, 모듈식으로, 사용자 친화적인 방식으로 배포할 수 있습니다. 즉, 타사 인프라 제공업체를 통해 모든 주소에서 Bundler, Paymaster, Signature Aggregator를 빠르고 사용자 정의 가능한 방식으로 배포할 수 있습니다.
현재 시장에서는 많은 스마트 컨트랙트 지갑이 자체 인프라를 구축했지만, 이러한 인프라는 다양한 서드파티 지갑 사용 사례에 적합하지 않습니다. Stackup과 같은 서드파티 인프라 제공업체는 모듈화된 번들러와 페이마스터를 개발하고 있지만, 배포 프로세스는 아직 허가형과는 거리가 멉니다. EIP 4337이 아직 완료되지 않았기 때문에 이 인프라의 모듈식 기능이 완전히 정의되지 않았습니다. 더욱이 UserOperation 거래량이 적기 때문에 서명 집계를 지원하는 지갑(예: BLS Wallet)은 아직 주류가 아닙니다.
EIP 4337 다운스트림 인프라
여기에는 EIP 4337에 정의되어 있지 않지만 이를 구현하는 데 필요한 다운스트림 인프라가 포함됩니다. 예를 들어, 법정화폐 입출금 애그리게이터와 Paymaster에 통합 가능한 DeFi 애그리게이터가 있습니다. 이러한 솔루션은 이미 존재하기 때문에 혁신은 기존 제공업체 내에서 발생할 가능성이 가장 높으며 , 기존 제공업체는 공용 인터페이스만 재구성하면 됩니다.
dApp SDK 및 스캐폴딩
기존 스마트 계약 지갑은 dApp 통합을 용이하게 하기 위해 자체 클라이언트 SDK를 구축했지만 시장에는 여전히 다음이 부족합니다.
- 다음 함수의 캡슐화와 같은 계정 추상화를 지원하는 ether.js와 유사한 dApp 개발 표준 라이브러리입니다.
- Web2 소셜 미디어 계정과 이메일을 사용하여 지갑 주소를 만들고 복구합니다.
- UserOperations 생성, 서명, 전송 및 이벤트 모니터링
- Paymaster 및 Signature Aggregator의 신속한 배포
- 모든 주요 스마트 계약 지갑을 위한 SDK 및 UI 도구 통합
- dApp 개발자가 제품의 업무 로직에 집중할 수 있도록 신속한 프런트엔드 배포를 위한 스캐폴딩 도구
- 가스 추상화를 지원하는 게임 등 계정 추상화를 기반으로 하는 새로운 유형의 dApp을 위한 템플릿
더욱 근본적인 접근 방식: 스마트 계약 지갑에서 계정 분리
EIP 4337의 스마트 컨트랙트 지갑 인터페이스는 단일 validateOp 함수만 필요로 하므로 사용자 등록, 권한 제어, 소셜 복구와 같은 모든 핵심 업무 로직을 지갑 개발자의 재량에 맡깁니다. 이는 유연성을 높여주지만, 서로 다른 스마트 컨트랙트 지갑은 한 지갑의 데이터를 다른 지갑으로 쉽게 전송할 수 없기 때문에 이더 생태계를 더욱 분열시킬 수 있습니다 . 또한 DApp은 특정 스마트 컨트랙트 지갑만 지원하고 다른 지갑은 지원하지 않음으로써 이러한 분열을 심화시킬 수 있습니다.
또한, 사용자는 Web2에서 이메일이나 기타 일반적인 프로세스를 통해 스마트 계약 지갑에 로그인할 수 있지만, Web2 사용자에게는 익숙하지 않은 "지갑 연결"과 같
