OKX Ventures: 계정 추상화 트랙의 과거, 현재 및 미래에 대한 시스템적 분석
저자: OKX Ventures 연구원 Kiwi
본문은 어떠한 투자 조언도 구성하지 않습니다.
2021년 9월 비탈릭 부테린이 EIP-4337을 제안한 이래 계정 추상화(Account Abstraction, AA) 개념이 점차 주류 Web3 지갑에 도입되고 있으며, OKX Ventures는 이 개념의 기원을 출발점으로 삼아 계정 추상화의 과거, 현재 및 미래 기회를 체계적으로 정리하였습니다.
주요 요약
기초 정보:
-
계정 추상화(AA)는 세션 키(session key)를 지원하여 거래 원천과 서명을 분리할 수 있으며, 사용자가 개인 키 백업, 가스비 등 복잡한 작업을 피할 수 있도록 도와줍니다. 이로써 사용자의 Web3 참여 장벽을 낮출 수 있습니다.
-
계정 유형을 단순화하고 체인 상 행동에 더 큰 자유도를 제공하며 계정을 더 높은 보안 수준에 두기 위해 계정 추상화가 필요합니다.
-
EIP-86, EIP-1014, EIP-2938, EIP-3074을 거쳐온 후, EIP-4337은 합의층 변경 없이 구현 가능하여 기본적으로 이더리움 AA의 최종 방안으로 간주됩니다.
다중체인 계정 추상화의 두 가지 경로: 4337 호환 방식(4337 compatible method), 네이티브 계정 추상화 방식(native account abstraction).
-
4337 호환 방식: 현재 Arbitrum, Polygon, Optimism 및 BNB는 네이티브로 계정 추상화를 통합하지 않았습니다. 다만 Biconomy, Stackup 등의 4337 관련 제품을 통해 지원하고 있으며, 인프라 구축은 여전히 개념 단계에 머물러 있습니다.
-
네이티브 계정 추상화 방식: Starknet과 zkSync는 4337 방식과 달리 네이티브 계정 추상화를 지원합니다. 차이점은 Starknet이 번들러(Bundler)와 페이마스터(Paymaster) 없이 시퀀서(Sequencer)가 거래 순서 결정, 가스 지불 및 실행을 담당하는 반면, zkSync는 오퍼레이터(Operator)가 거래 순서 결정 및 가스 지불 후 부트로더(bootloader)를 호출해 함께 작동한다는 점입니다.
성장 데이터: 이더리움, Arbitrum, Optimism 및 Polygon에는 이미 52만 개 이상의 AA 계정이 배포되었으며, 이 중 80% 이상이 7~8월에 새로 생성되었습니다. 대부분의 성장은 Polygon과 Optimism에서 AA 제품 출시로 인한 것입니다. 번들러 및 페이마스터 프로토콜은 아직 소수만 운영 중이며, 각 체인에서는 Pimlico, StackUp 등의 프로젝트가 독점적인 위치를 차지하고 있습니다.
AA가 가져오는 기회:
-
페이마스터는 dApp이 배포하는 스마트 계약으로, 번들러를 통해 특정 UserOperation의 가스를 대신 지불하도록 트리거될 수 있습니다. 페이마스터는 표준화된 서비스로서 독립적인 프로젝트로 존재하기 어렵고, 웹2 트래픽 사업자는 이를 기능으로 통합하여 웹3 비즈니스를 지원할 수 있습니다. 대납 서비스의 상업적 기회: 대납 트래픽 입구, 자동 환전, DeFi 게임 프로젝트와의 통합 유입 등이 있으며, 거시적으로는 결제 업계의 혁신 사례와 유사합니다. 페이마스터의 혁신 방향은 다소 단조롭지만 가치 포착이 가장 안정적인 영역이며, 웹2 사용자가 웹3 진입 장벽을 낮추므로 많은 웹2 기관들이 페이마스터 서비스를 배포할 가능성이 있습니다.
-
번들러는 기회가 가장 많은 구성 요소 중 하나로, 본질적으로 리레이어(relayer)와 유사하며 수익 모델은 주로 거래 패킹과 관련된 일련의 기회(예: 가스 스프레드 수익, MEV, B2B 수요 중심의 프라이버시 풀 등)에 집중됩니다. 그러나 거래 패킹 실패 시 번들러가 손실을 입기 때문에 거래 선택이 어려운 문제입니다.
-
노드 및 리레이어 서비스를 자체 보유한 프로토콜은 번들러 네트워크 구축이 용이하며, RPC는 분산형 인프라로서 번들러의 탈중앙화를 지원할 수 있습니다.
-
번들러는 서치어(searcher), 시퀀서(sequencer)와 협력하는 것이 더 나은 선택이며, 향후 MEV share 형태로 다양한 채널을 통해 수익을 사용자에게 환원하여 점점 더 공정해질 가능성이 있습니다.
-
현재 번들러는 모두 프라이빗 풀이며 공용 풀은 존재하지 않으며, 현재 Stackup만이 잘 운영되어 수익을 내고 있고, Biconomy는 평균 수준입니다.
-
번들러는 수익 창출이 어렵지만 생태계에 매우 필요한 공공재이지만, 시장에는 성숙한 공공재 운영 방안이 없으며, 현재 대부분의 프로젝트팀은 수익 고려로 인해 이를 사유화하려는 경향이 있습니다.
-
번들러가 직면한 기술적 개선 방향은 nonce 충돌 회피, p2p 네트워크를 통해 마킹 및 삭제로 이러한 문제를 최적화하는 방법이 있으며, 계약 storage 수정으로 인해 번들러가 충분한 보상을 받지 못하는 부분은 향후 제안을 통해 최적화가 필요합니다.
-
-
AA와 MEV의 융합: AA, 시퀀서 및 인텐트(intent)는 본질적으로 체인 상 작업 체인을 연장시키며, MEV는 더 긴 체인을 매수해야 하므로 AA의 번들러와 인텐트 솔버(solve)는 MEV 체인 내 서치어(searcher) 등의 역할과 협력하여 MEV share 형태를 형성할 수 있습니다. AA는 번들러와 엔트리포인트(entrypoint) 계약을 제공하므로 이론적으로 PEV(Prover Extractable Value) 수익을 공유할 수도 있습니다.
-
NFT: 사용자 경험 향상은 더 많은 신규 사용자를 끌어들일 수 있으며, 시장 모니터링과 거래 자동화도 가능하게 합니다. ERC6551과 4337은 사용자 인식 측면에서 모두 계정 기능을 갖추고 있으며, 전체 체인 게임, DID 및 미들웨어와 통합 가능합니다. 향후 전체 체인 게임은 ERC-6551의 조합성을 필요로 하며, 다중 체인 + 거래 가능한 장비 계정 등을 완성한 게임 경험을 제공할 수 있습니다.
-
소셜 및 게임: 신원 인프라의 최적화는 제품의 사용 편의성을 크게 향상시키며, 전체 체인 게임 조작 장벽 감소 + 계정 모델 최적화 + 다중 체인 계정 시스템이 다중 체인 게임 세계관을 가져올 것입니다.
AA와 인텐트(intent):
-
본질적으로 인텐트와 AA는 필연적인 관계가 없습니다. 인텐트는 본질적으로 사용자 경험 층의 혁신으로, 사용자 요구를 더 잘 이해하고 분해하여 하나 또는 여러 개의 UserOperation으로 변환하는 것을 의미합니다. AA는 백엔드 최적화로서 사용자 명령을 더 잘 실행하는 것입니다. 텔레그램 봇(telegram bot)은 전형적인 인텐트 혁신 사례이지만 백엔드는 여전히 EOA 지갑을 사용하며 사용자 경험에는 영향을 미치지 않습니다.
-
인텐트는 특정 목표를 위한 최적의 op 경로를 찾는 과정입니다. 과거의 인텐트는 단순한 요구에 치중했지만 향후에는 다중 조건, 다중 단계, 다중 실행 환경의 복잡한 문제, 심지어 AI 에이전트까지 도입될 가능성이 있습니다.
-
인텐트 기회: 운영 측면에서 서명 횟수를 줄여 사용자 경험을 향상시킬 수 있습니다. 애플리케이션 측면에서는 의도 내러티브를 바탕으로 새로운 인프라, 언어 및 해결 방식을 형성할 수 있으며, 이는 향후 가장 잠재력 있는 사례 중 하나입니다.
-
중개상 인텐트 풀 또는 인텐트 공용 체인: 인텐트 기반 애플리케이션은 스마트 계약과의 상호작용을 위한 새로운 메시지 형식뿐만 아니라 대체 메모리풀 형태의 전파 및 거래 상대방 발견 메커니즘을 포함합니다. 인센티브를 포함하면서도 탈중앙화된 인텐트 발견 및 매칭 메커니즘을 설계하는 것은 어렵습니다.
-
솔버(Solver)의 다양화된 실현 경로: 단기적으로 이미 성숙한 다양한 슈퍼 스마트 계약이 우선 통합될 것이며, 장기적으로는 자유도가 더 높은 AI가 가장 이상적인 형태이지만 실현 난이도가 매우 큽니다. 솔버는 체인 외 사전 처리 후 체인 상 처리라는 새로운 패러다임을 가져오며, 일부 자동화 프로토콜(Uniswap X 등)에 유리합니다. 현재 ZK 코프로세서 Axiom은 프라이버시 솔빙의 일종의 데모로 볼 수 있습니다.
-
의도를 표현하기 위한 새로운 언어: 현재 Juvix 및 Essential이 존재하며, 이러한 프로젝트는 선점이 중요하며 사용자의 신뢰를 미리 구축해야 합니다.
-
-
지갑 및 입구 기회: 지갑은 완전히 인텐트 층 구성단으로 작용할 수 있으며, 전략적 지위가 크게 증가하여 각 프로토콜의 유입 인프라 및 입구가 될 수 있습니다. 인텐트 백엔드는 기존의 EOA, MPC 및 스마트 계약 지갑을 통합할 수 있으며, 거래 및 크로스체인 애플리케이션은 입구 단의 다양화로 인해 경험을 개선(자동화, 다중 방안 등)할 수 있습니다.
-
ZK 애플리케이션 기회: 사용자의 인텐트는 많은 암호화 요구가 있으며, 4337 자체 메커니즘은 이미 프라이버시 결제를 충족시킬 수 있으나, 더 깊은 통합은 zkProof 시장에서 발전할 것입니다.
-
위험과 장벽: 인텐트는 강력한 신뢰 기대를 필요로 하며, 이는 높은 진입 장벽을 초래하여 지나치게 중앙화되고 혁신이 부족한 결과를 낳을 수 있습니다.
주요 프로젝트:
-
계정 추상화 시장에는 두 가지 종류의 참여자가 있습니다. 하나는 소셜 로그인 및 복구, 가스 추상화, 거래 일괄 처리, 제3자 서비스(법정화폐 입출금 및 DeFi 프로토콜 등) 통합 및 집계 기능을 갖춘 스마트 계약 지갑으로, 이 분야의 초기 스타트업 프로젝트가 많고 방안이 초보적입니다. 다른 하나는 번들러 및 페이마스터의 모듈화 제공업체, Biconomy 및 Stackup 외 대부분 초기 단계에 있습니다.
-
주요 프로젝트: Biconomy, Stackup 및 Pimlico은 현재 시장에서 비교적 성숙한 4337 방안이며, SDK 및 모듈화 방안을 계속 완성하면 선도 시장을 선점하고 기술 방안의 높은 시장 점유율을 달성할 수 있습니다. 현재 Stackup은 두 가지 유형의 페이마스터 및 번들러 모드를 이미 구현했으며, 향후 전과정 솔루션 + 다양한 컴포넌트 라이브러리는 이러한 선두 프로젝트가 우위를 확대하는 방식이 될 것입니다.
-
Pimlico의 번들러 시장 점유율(전체 체인 번들의 userop 비중52%) 및 수익(Polygon에서 수익 1위, 7월 637 MATIC, Optimism에서도 흑자) 모두 선두입니다.
-
Stackup은 각 체인에 번들러 사업을 운영하고 있으며, Arbitrum(8월 5 ETH) 및 이더리움(7월 0.4 ETH)에서 수익이 선도적입니다. 번들러는 실패 건수는 많지만 수익도 많은 상태입니다.
-
-
혁신 프로젝트: 프라이버시는 필수 요구사항으로, ZK 코프로세서 Axiom은 프라이버시 솔빙의 일종의 데모로 볼 수 있습니다. Nocturne는 조합 가능한 프라이버시 AA 레이어로, 사용자가 EOA 또는 계약에서 자금을 예치한 후 계약과 상호작용하여 zkp를 이용해 프라이버시 보호를 실현합니다. AI는 시장의 핫 아이템으로, Echooo Wallet은 MPC 및 AI 기술을 결합하여 다중 서명 및 AI 위험 모니터링을 달성했습니다. 동시에 기존 프로젝트의 혁신도 눈에 띕니다. 예를 들어 Uniswap 팀의 Universal Paymaster는 지갑 사용자와 페이마스터 운영자 양측의 유동성 시장을 연결합니다.
기타 EIP 및 기회:
-
4337과 관련된 EIP는 공식적으로 4337 방향을 제시하였으므로 현재 대부분의 제안은 AA 배포 최적화 방향을 중심으로 하고 있습니다. 예를 들어 ERC 6551은 4337 파생 제품의 보조 방안이며, EIP 6662, ERC 6900, ERC 1271, ERC 6492, EIP 7204 및 EIP 7197은 모두 AA 최적화 방향이며, ERC 7377은 향후 계정 이전에 도움을 줍니다.
-
기타 수상 프로젝트: 이더리움은 23년 1~2분기에 계정 추상화 관련 프로젝트 4개를 후원하였으며, 이 중 2개는 4337 공식 팀 작품(공식 AA 팀 및 그들이 개발한 4337 브라우저 지갑 trampoline)이고, 나머지 2개는 4337과 기존 프로토콜/기술의 조합성에서 발생한 혁신 프로젝트(zkShield는 ZKP와 계정 추상화를 사용하여 계정 소유자의 프라이빗 멀티시그를 숨기는 방안, Uniswap 팀이 출시한 Universal Paymaster는 ERC-20 가스 지불을 위한 단일 유동성 매칭 시장)입니다.
향후 발전: 단기적으로는 시장을 확장하고 Layer2와 공동 촉진 모드를 형성하는 것이 주요 목표입니다. 중기적으로는 모듈화된 번들러 및 페이마스터의 실현과 SDK 배포에 주력하며, 사용자 경험을 세부적으로 최적화(예: 가스 비용 감소, 선택적 EOA-to-ERC-4337 변환 추가 등)합니다. 장기적으로는 EOA 지갑을 강제 전환하는 것을 고려합니다.
1. 계정 추상화 소개
정의 및 개요:
-
계정 추상화의 본질은: 거래 원천과 서명의 분리입니다.
-
왜 계정 추상화가 필요한가:
1) 계정 유형 단순화;
2) 계정과 서명을 분리하여 체인 상 행동에 더 많은 자유도를 부여하며, 계정을 더 높은 보안 수준에 둡니다.
-
계정 추상화의 발전: 직접 구분은 공학량과 복잡도가 크며, EIP 2938 및 EIP 3074은 합의층 변경이 필요하므로 결국底层 변경이 불필요한 EIP 4337 방안을 선택했습니다.
ERC 4337의 원리:
-
역할: EIP 4337은 스마트 계약 지갑 및 관련 인프라를 다섯 가지 계약 인터페이스로 표준화합니다: 번들러(Bundler), 엔트리포인트 계약(Entry Point Contract), 대납 계약(Paymaster), 스마트 계약 지갑 팩토리(Wallet Factory), 서명 집계기(Signature Aggregator). 그리고 새로운 거래 유형인(UserOperation)을 추가합니다.
-
거래 단계: 4337은 이더리움 합의층을 수정하지 않고 새 작업 논리인 useroperation을 도입하고 번들러를 배치하여 userop를 패키징합니다. 기존 프로세스 후 엔트리포인트와 지갑 계약을 추가하여 검증 및 실행 프로세스를 분리하여 사용자 정의 작업 실행을 완료한 후, 페이마스터를 통해 가스비 지불 논리를 추출합니다. 사용자가 userop를 시작 → userop가 "사용자 userop 메모리풀"에 전송 → 번들러가 선택된 UserOps를 묶어 한 건의 거래로 엔트리포인트에 제출 → 엔트리포인트가 사용자 작업을 검증하고 스마트 계약 지갑이 사용자 작업을 실행하여 블록에 포함합니다.
4337과 기타 방안 비교:
-
EIP-3074의 AA 방안: EOA 계정이 계약을 사용하기 위해 두 개의 새로운 op code를 도입해야 하며, 이는 합의층 변경을 수반하므로 포기되었습니다.
1.1 정의 및 방안 개요
계정 추상화란 무엇인가:
-
이더리움에는 두 가지 유형의 계정이 있습니다: 외부 계정(EOA) 및 계약 계정(CA). EOA는 기존 방안으로 개인 키 관리 및 ECDSA 서명에 너무 의존하며, 작업 논리가 경직되어 서명권과 계정을 엄격히 묶는 메커니즘이 신규 사용자의 진입 및 후속 발전에 영향을 미칩니다.
-
임의의 검증 논리를 포함하는 스마트 계약 지갑을 사용하여 이러한 문제를 해결할 수 있는 방안이 필요하며, 이를 계정 추상화(Account Abstract, AA)라고 하며, 원리는 거래 원천과 서명을 분리하는 것입니다.
왜 계정 추상화가 필요한가:
1) 계정 유형 단순화;
2) 계정과 서명을 분리하여 체인 상 행동에 더 많은 자유도를 부여하며, 계정을 더 높은 보안 수준에 둡니다.
계정 추상화의 발전: 직접 구분은 공학량과 복잡도가 크며, EIP 2938 및 EIP 3074은 합의층 변경이 필요하므로 결국底层 변경이 불필요한 EIP 4337 방안을 선택했습니다.
-
직접 구분: EIP 86, EIP 101, EIP 859 등을 통해 새로운 거래 유형을 추가하여 구분합니다.
-
특정 유형 계정의 지위 향상:
-
EIP 2938: 계약 계정이 수수료를 지불하고 트랜잭션을 수행할 수 있는 "최상위" 계정이 되도록 합니다.
-
EIP 3074: 두 개의 새로운 op code를 도입하여 EOA 계정이 계약을 사용하도록 합니다.
-
EIP 4337: 새 작업 논리 - 사용자 작업 풀 도입.
1.2 ERC 4337 기초 원리
-
소개: 2021년 9월, 비탈릭 부테린과 OpenGSN 및 Nethermind의 이더리움 연구원들은 EIP-4337을 제안했습니다. EIP-4337은 기존 거래 메모리풀을 완전히 대체할 수 있는 새로운 UserOperation 메모리풀을 추가하여 계정 추상화를 실현하고자 합니다.
역할
-
UserOperation: 사용자가 시작해야 하는 거래로, 번들러에 전송되어 다른 UserOperations과 함께 번들로 묶입니다.
-
Bundler: 거래 풀에서 거래를 선택하여 여러 UserOperations을 패키징하고 EntryPoint.handleOps() 거래를 생성하는 노드입니다.
-
EntryPoint: 번들된 UserOperations의 검증 및 실행을 처리하는 스마트 계약으로, 번들러와 스마트 계약 지갑 사이의 중개자 역할을 합니다.
-
Wallet contract: 4337 사용자를 위한 계약 지갑을 생성하는 스마트 계약.
-
Aggregator: 집계 서명 검증용.
-
Paymaster: 사용자의 가스비를 대신 지불할 수 있는 스마트 계약.
거래 단계
-
거래 서명: 사용자가 지갑 사용자 작업을 시작하고 임의 형태의 개인 키로 사용자 작업에 서명(명령은 동일하지만 내용 필드는 변경 가능, 비 ECDSA 서명 사용 가능)하여 서명된 사용자 작업(UserOperations)을 생성하고, 이 UserOp는 처리를 위해 대기 중인 사용자 작업 메모리풀에 전송됩니다.
-
거래 전송: 번들러가 사용자 작업 메모리풀의 사용자 작업을 패키징한 후 별도로 서명하여 사용자의 명령을 래핑하고 여러 UserOp를 하나의 거래로 처리하여 엔트리포인트 계약에 제출합니다. 여러 UserOperations을 함께 패키징한 후 번들러는 먼저 거래를 시뮬레이션하여 계약 실행 실패 여부를 확인하고 가스비가 충분한지 계산합니다. 시뮬레이션이 통과되면 이 UserOperations들을 하나의 거래로 제출하여 블록 생성 노드에 제출합니다.
-
사용자 작업 처리: 엔트리포인트 계약이 지갑 존재 여부를 검증 → 지갑에 사용자 작업 검증 요청 → 사용자 작업을 스마트 계약 지갑으로 보내 실행하며, 번들러와 스마트 계약 지갑 사이의 중개자 역할을 합니다.
-
블록체인 등록: 스마트 계약 지갑이 사용자 작업을 실행하여 블록에 포함합니다.
1.3 기존 지갑 및 MPC 지갑과 비교
1.4 EIP-3074의 AA 방안
-
EIP-3074: 두 개의 새로운 op code를 도입하여 EOA 계정이 계약을 사용하도록 하며, 합의층 변경을 수반하므로 포기되었습니다.
-
EIP-4337이 CA 계정 지갑이 EOA처럼 사용할 수 있게 한다면, EIP-3074은 EOA 외부 지갑이 스마트 계약 계정의 프로그래밍 가능 기능을 가질 수 있게 합니다. 핵심은 서명을 통해 타인이 내 계정으로 명령을 발행할 수 있도록 허가하는 것입니다.
-
EIP-3074은 두 개의 새로운 OpCodes, AUTH 및 AUTHCALL을 추가했습니다. 이 방안은 User(EOA)가 계약(Invoker Contract, Invoker는 업그레이드 불가)을 통해 자신을 대신하여 다양한 동작을 수행할 수 있도록 하며, 개발자가 더 탄력적인 프레임워크를 통해 거래 객체 및 검증 메커니즘(서명 알고리즘)을 설계할 수 있도록 합니다. 이를 통해 어떤 EOA도 계약 계정처럼 작동할 수 있으며, 계약을 배포하지 않아도 됩니다.
-
장점: 1) 자유도가 높아 일괄 거래, 래핑 거래, 수수료 납부, 다중 서명 등을 실현할 수 있습니다; 2) 다양한 수수료 지불이 가능하여 외부 계정도 좋아하는 토큰으로 Invoker 수수료를 지불할 수 있습니다.
-
단점: 1) EIP-3074은 광범위한 합의층 변경을 수반하며 문제가 발생하면 하드포크(hard fork)를 통해 해결해야 합니다; 2) EIP-3074은 EOA 외부 계정이 스마트 계약 계정의 특성을 가지도록 하지만 서명 메커니즘은 여전히 고정된 ECDSA 서명을 사용하므로 EIP-4337처럼 임의의 서명 방식을 사용할 수 없습니다.
-
EIP-5003: EIP-3074(AUTH 및 AUTHCALL)의 확장 제안으로 새로운 AUTHUSURP 오퍼코드를 도입합니다. EIP-3074 메커니즘을 사용하면 EOA 주소 A가 다른 주소 B에게 대신 행동할 권한을 부여한 경우, AUTHUSURP는 B가 A의 코드를 설정할 수 있도록 허용합니다. 즉 기존 EOA를 계약으로 업그레이드하고 ECDSA에서 더 효율적이거나 양자 저항성이 있는 서명 방식으로 마이그레이션할 수 있도록 합니다.
2. 다중체인 계정 추상화 방안
요약
-
두 가지 경로: 4337 호환 방식(4337 compatible method), 네이티브 계정 추상화 방식(native account abstraction).
-
4337 호환 방식:
-
현재 Arbitrum, Polygon, Optimism 및 BNB는 네이티브로 계정 추상화를 통합하지 않았습니다. 다만 Biconomy, Stackup 등의 4337 관련 제품을 통해 지원하고 있으며, 인프라 구축은 여전히 개념 단계에 머물러 있습니다.
-
Arbitrum은 올해 7월 계정 추상화 엔드포인트 지원 제안을 통과시켰습니다.
-
Polygon zkEVM은 공식 문서에서 향후 다중 토큰 가스 지불을 지원하겠다고 밝혔습니다.
-
네이티브 계정 추상화 방안: Starknet 및 zkSync는 4337 방안과 달리 네이티브 계정 추상화를 지원합니다.
4337 호환 방안
Arbitrum:
-
Arbitrum은 23년 7월 17일 계정 추상화 엔드포인트 지원과 관련된 AIP-2 제안을 통과시켰으며, 현재 Offchain Labs는 Arbitrum One 및 Arbitrum Nova에서 계정 추상화 엔드포인트 지원을 공식 활성화했습니다.
-
이 제안은 이더리움 연구원들이 L2 정렬기가 ERC-4337 번들러(bundlers)의 특정 요구에 적응할 수 있도록 새로운 RPC 엔드포인트 eth_sendRawTransactionConditional을 제안했다고 밝혔습니다.
Polygon:
-
Polygon은 4337과 호환되며 메타 거래 관련 솔루션을 발표했습니다. 예를 들어 Biconomy(다중 체인 릴레이 프로토콜), Gas Station Network (GSN)(탈중앙화 공공재 프로토콜, 사용자가 가스를 지불하는 과정을 추상화하는 데 도움), Infura(노드 제공업체) 및 Gelato(릴레이어 SDK, 다중 토큰 결제 가능)
-
Polygon은 공식 문서에서 Polygon zkEVM이 ERC 4337을 통해 계정 추상화를 지원하며 사용자가 어떤 토큰으로든 수수료를 지불할 수 있다고 밝혔으며, 추가 세부 정보는 추후 발표될 예정입니다.
Optimism: 현재 OP 메인넷은 Alchemy, Biconomy, CyberConnect, Pimlico 및 Stackup 등의 일부 계정 추상화 인프라를 제공하고 있으며, 아키텍처 세부 정보는 아직 공개되지 않았습니다.
BNB: BNB 체인의 2023년 기술 로드맵에서 공식적으로 계정 추상화 인프라를 구축할 것이라고 밝혔으며, 현재 4377이 BNB에서 호환되지만 추가 세부 정보는 추후 공개될 예정입니다.
네이티브 계정 추상화 방안
Starknet은 계정 추상화를 네이티브로 지원하며, 모든 계정이 스마트 계정입니다.
- 방안목표: 서명 추상화(다양한 계정 계약이 서로 다른 서명 검증 방안 사용) 및 지불 추상화(다양한 거래 지불 모드 및 토큰 형태)
- 프로세스: 거래는 풀에 들어가기 전에 nouce를 검증한 후 계정 스마트 계약 주소로 전송되어 검증을 거친 후 블록에 추가됩니다. 이 두 단계는 계정 계약 내의 두 개의 별도 함수 validate 및 execute로 코딩됩니다.
-
시퀀서(Sequencer)는 먼저 계정 계약에 거래 검증을 요청합니다. DoS 공격을 방지하기 위해 거래를 수락하는 시퀀서는 거래를 메모리풀에 추가하고 다른 시퀀서에 브로드캐스트하기 전에 알려진 상태를 기반으로 로컬 시뮬레이션을 수행해야 합니다.
-
시뮬레이션 성공 후 거래가 실행되어 풀에 들어가 네트워크에서 전파됩니다.
-
Starknet 및 이더리움 방안의 차이점:
-
Starknet 네이티브 계정 추상화에서 모든 계정은 스마트 계정이며 validate 및 execution 함수를 반드시 포함해야 하며, 사용자는 이 두 함수에서 임의의 논리를 구현하여 계정 기능을 확장할 수 있습니다.
-
StarkNet은 다양한 타원 곡선을 지원하며 서명 검증이 고도로 프로그래밍 가능합니다. validate는 서명 검증을 통해 계정 소유자만이 거래를 시작할 수 있음을 보장하고 거래 실행자가 충분한 가스비를 확보할 수 있도록 하며, 사용자는 validate 함수에서 다양한 서명 검증 알고리즘을 구현할 수 있습니다.
-
번들러(Bundler)로 인한 추가 복잡성 제거: Starknet은 번들러의 역할을 수행하는 지정된 시퀀서(Sequencer)를 통해 프로세스를 단순화합니다.
-
Starknet은 유사한 페이마스터(Paymaster)의 거래 수수료 추상화 프로토콜이 없습니다.
-
Starknet은 일반 거래와 UserOperations를 구분하지 않습니다. 왜냐하면 Starknet의 모든 거래는 계약 계정에 의해 트리거되기 때문입니다. 이더리움에서는 번들러가 UserOperation 거래를 실행하지만, Starknet에서는 시퀀서(Sequencer)가 모든 거래를 실행합니다.
-
계약 계정 배포 방식의 차이:
-
Starknet은 먼저 계약 계정을 배포한 후 호출할 수 있으며, Starknet은 토큰 잔액이 있는 계정이 전용 deploy_account 함수를 호출하여 새로운 계약 계정을 생성하도록 요구하며, 이 배포된 계정 계약은 가스를 지불할 수 있습니다.
-
EIP 4337은 사전 배포가 필요하지 않으며, 번들러는 initCode 매개변수가 비어 있지 않은 UserOperation 거래를 실행하여 계약 계정을 배포합니다. 배포 과정에서 반드시 토큰 잔액이 있는 계정일 필요는 없으며, 가스비는 페이마스터가 대신 지불할 수 있습니다.
-
zkSync: zkSync Era는 native account abstraction 방안이지만 동시에 EVM-Compatible입니다.
-
방안 목표: 서명 추상화(다양한 계정 계약이 서로 다른 서명 검증 방안 사용) 및 지불 추상화(다양한 거래 지불 모드 및 토큰 형태)
-
프로세스: 사용자가 로컬에서 서명된 트랜잭션을 오퍼레이터(Operator)에게 전송하면, 오퍼레이터는 트랜잭션을 부트로더(bootloader)로 보내 검증을 수행한 후 수수료를 확보하고, 부트로더는 Account Contract의 executeTransaction을 호출하여 거래를 실행합니다.
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
즐겨찾기 추가소셜 미디어 공유
OKX Ventures
