원저자:Albert He, BlockPI Cheif Scientist

원본 편집: MarsBit, MK

원저자:

원본 편집: MarsBit, MK

상승장이든 하락장이든 이더리움 생태계는 지속적으로 구축되고 자체 최적화되어 왔습니다. 그 중 계정 추상화(AA)는 최근 몇 년간 매우 중요한 발전이 되었으며, 애플리케이션, 인프라, 사용자, 개발자 등 이더리움 생태계의 다양한 구성 요소에 침투했습니다.

우리는 AA의 광범위한 채택이 블록체인 사용 사례에 대한 진입 장벽을 낮춰 웹2 사용자 경험을 웹3 산업에 가져올 수 있다고 예측할 수 있습니다.

수십억 규모의 AA 시장 형성 가능성을 수용하기 위해 BlockPI는 AA를 인프라 서비스에 통합하는 데 자원을 투입할 계획입니다. AA 통합을 구축함으로써 우리는 AA 사용자가 블록체인에서 계약 지갑 계정과 상호 작용할 수 있는 보다 편리하고 효율적인 방법을 제공하는 동시에 BlockPI를 업계 리더로 자리매김하는 것을 목표로 합니다.

이번 포스팅에서는 AA에 대한 이해를 알아보고, 인프라 서비스 제공자 입장에서 생각을 공유해보겠습니다.

EOA 및 스마트 계약 지갑

AA의 개념은 EOA 계정의 한계에서 비롯됩니다. EOA 계정(외부 소유 계정)은 공개 키(블록체인 주소)로 표시되고 개인 키를 통해 접근할 수 있는 이더리움의 일반적인 사용자 계정입니다. 이는 이더리움 생태계의 주요 구성 요소로, 사용자가 스마트 계약과 상호 작용하고 네트워크에서 거래를 실행할 수 있도록 해줍니다. 그러나 EOA를 사용하는 것은 사람들에게 어려울 수 있으며 일부 불편은 사용자 경험에 영향을 미칠 수 있습니다.

EOA의 첫 번째 불편함은 가스 사용과 관련이 있습니다. 각 거래는 사용자에게 가스 수수료로 많은 양의 ETH를 부과합니다(가스 가격의 경우 25 Gwei의 단순 ETH 전송 수수료는 0.5 USD이고 계약 상호 작용 또는 더 높은 가스 가격의 경우 더 많은 비용이 듭니다). 이는 특히 네트워크 정체가 가장 심한 기간 동안 소규모 거래의 경우 거래 수수료를 매우 비싸게 만듭니다. 또한, 가스 비용을 지불하는 데는 ETH만 사용할 수 있습니다. 즉, 사용자는 지갑에 ETH를 가지고 있어야 하며, 이는 많은 사용자에게 상당한 진입 장벽이 됩니다.

EOA의 두 번째 불편함은 다른 스마트 계약을 사용하여 일부 로직을 구현하지 않으면 조건부 거래가 이루어질 수 없다는 것입니다. 예를 들어, 사용자가 정기 이체를 설정하려는 경우 이 기능을 달성하려면 이 기능을 사용하여 ETH를 제3자 스마트 계약으로 이체해야 합니다.

EOA의 세 번째 불편한 점은 서명 암호화 알고리즘이다. Ethereum 네트워크는 secp 256 k 1이라는 특정 디지털 서명 알고리즘을 사용하여 거래의 신뢰성과 보안을 보장합니다. 이는 시스템에 하드코딩되어 있으며 사용자는 다른 알고리즘을 사용하도록 선택할 수 없습니다.

따라서 사람들은 이러한 문제로부터 시작하여 해결책을 찾으려고 노력하기 시작했습니다. MetaMask 및 Argent와 같은 스마트 계약 지갑은 이러한 노력의 결과로 Ethereum 스마트 계약을 사용하여 사용자 계정 기능을 향상함으로써 EOA의 많은 한계를 해결합니다. 그러나 이러한 솔루션에는 주로 사용자가 거래에 대한 가스 수수료를 지불해야 한다는 점과 스마트 계약 지갑의 인기 등 몇 가지 단점이 있습니다.

이러한 과제를 바탕으로 이더리움은 계정 추상화라는 새로운 개념을 도입하기 시작했습니다. 계정 추상화의 목표는 스마트 계약이나 기타 미들웨어에 의존하기보다는 프로토콜 수준에서 이러한 문제를 해결하는 것입니다. 이것이 바로 우리가 계정 추상화(AA)라고 부르는 것입니다.

이 게시물의 나머지 부분에서는 계정 추상화의 개념과 이를 사용하여 BlockPI의 인프라를 최적화하는 방법을 자세히 살펴보겠습니다.

위에서 언급한 EOA의 세 가지 불편함 외에도 공개키와 개인키의 바인딩 관계도 문제입니다. 개인 키는 EOA에 접근할 수 있는 유일한 방법이며, 분실한 경우 개인 키를 복구할 수 있는 방법이 없습니다. 이는 개인 키가 분실되면 이와 관련된 모든 자산을 복구할 수 없음을 의미합니다.

또한 EOA는 단일 트랜잭션에서 선형 작업을 수행할 때 제약 사항에 직면합니다. 예를 들어, 사용자가 한 번의 작업으로 토큰을 승인, 교환 및 승인 취소하려는 경우 세 가지 별도의 트랜잭션을 수행해야 하므로 비효율적이고 시간이 많이 걸립니다.

좋은 소식은 위의 모든 문제가 스마트 계약 지갑으로 해결될 수 있다는 것입니다. 스마트 계약 지갑은 AA를 구현하는 특별한 유형의 스마트 계약입니다. 이는 이더리움 네트워크에서 사용자의 지갑 역할을 하며 자금을 관리하는 보다 적응적이고 개인화된 방법을 제공하도록 설계되었습니다. 이더리움 스마트 계약의 논리가 실현될 수 있는 한 스마트 계약 지갑은 필요한 기능을 제공할 수 있습니다.

EIP-86 

구체적으로, 스마트 계약 지갑의 거래는 온체인 거래로 패키징되어 가스 비용을 공유할 수 있으며, 제3자가 기꺼이 지불할 의사가 있는 경우 가스 비용이 없을 수도 있습니다. 작업은 스마트 계약 지갑 내에서 순차적 작업 실행을 용이하게 할 수 있습니다. 스마트 계약 지갑은 모든 서명 암호화 알고리즘을 지원하고 복구 코드 등을 설정할 수 있습니다.

EIP-2938 

스마트 계약 지갑의 이점에 대한 모든 이야기와 함께 Ethereum 커뮤니티는 실제로 처음부터 계약 지갑에 대해 작업해 왔습니다. 계정 추상화를 탐구하기 위해 많은 EIP가 제안되었지만 2021년까지 통일된 표준이 확립되지 않았습니다. 다음은 가장 대표적인 제안 중 일부입니다.

EIP-3074 

Vitalik Buterin이 2017년에 처음 만들었습니다. 추상적 서명 확인 및 nonce 확인 서비스에 대한 일련의 변경 사항을 구현하여 사용자가 원하는 서명/nonce 확인을 수행하는 계정 계약을 생성할 수 있도록 했습니다.

2020년에 생성되었습니다. 본 EIP의 제목은 Account Abstraction입니다. 이 EIP는 AA의 개념을 자세히 설명합니다. AA 트랜잭션이라는 새로운 유형의 트랜잭션이 도입되었습니다. 이 거래는 EntryPoint 주소로 초기화되며 AA 지갑 계약을 호출합니다. 이를 통해 통일된 사양을 제공하고 이더리움 합의에 AA를 도입합니다. 보다 구체적으로 말하면 이더리움 합의에 두 개의 새로운 opcode, 세 개의 전역 변수 및 다른 페이로드 구조를 추가합니다.

ERC — 4337 

2020년에 생성되었습니다. 이 EIP에는 AUTH 및 AUTHCALL이라는 두 가지 EVM 명령어가 도입되었습니다. AUTH는 ECDSA 서명을 기반으로 Authorized라는 컨텍스트 변수를 설정합니다. AUTHCALL은 승인된 계정을 대신하여 호출을 보냅니다. 이를 통해 스마트 계약이 EOA를 대신하여 트랜잭션을 보낼 수 있습니다. 그러나 이는 AA에 대한 완벽한 솔루션은 아닙니다. EIP-3074는 후원 거래 중 기본 가치 이전에 특정 제한을 둡니다. EOA에 접근할 수 없게 되면 자산을 복구할 수 없으며, 도난당한 경우 모든 자산을 새 계정으로 이전해야 합니다.

위의 아이디어 중 어느 것도 합의 계층에서 변경이 필요하거나 포괄적이지 않은 등의 주요 이유로 이더리움 프로토콜에 공식적으로 채택되지 않았습니다. 따라서 이더리움 커뮤니티는 합의를 변경하지 않고 이더리움 프로토콜에 AA를 도입하는 방법을 계속해서 모색했으며 마침내 EIP 4337을 만들었습니다.

EIP-4337은 원래 2021년 9월에 제안되었으며 2023년 3월에 ERC-4337로 승인되었습니다. 저자로는 Vitalik Buterin, Yoav Weiss, Kristof Gazso, Namra Patel, Dror Tirosh, Shahaf Nacson 및 Tjaden Hess가 있습니다.

EIP-4337은 핵심 Ethereum 프로토콜을 변경하지 않고 AA를 도입하는 판도를 바꾸는 제안입니다. EIP-4337은 빌더가 자체 스마트 계약 지갑을 구현하는 데 사용할 수 있는 ERC-4337 표준을 안내하며 번들러 및 UserOperation 메모리 풀을 포함한 몇 가지 추가 인프라를 포함합니다. 이를 통해 본질적으로 고급 시스템에서 트랜잭션 멤풀의 기능을 복제합니다. 트랜잭션을 보내는 대신 사용자는 UserOperation 개체를 제출합니다. 그러면 이 개체가 단일 트랜잭션으로 패키징되어 이더리움 체인에 포함될 수 있습니다.

다음은 공식 문서에 있는 ERC-4337에 대한 좀 더 구체적인 기술적 설명과 이해를 돕기 위한 몇 가지 설명입니다.

ERC-4337의 정의 및 주요 역할

UserOperation — 사용자를 대신하여 전송된 트랜잭션을 설명하는 구조입니다. 혼동을 피하기 위해 트랜잭션이라는 이름을 지정하지 않았습니다. 이는 다른 UserOperation과 함께 패키징되도록 Bundler로 전송됩니다. 그런 다음 패키지는 단일 트랜잭션으로 블록 생성자에게 전송됩니다.

보낸 사람 — 새 UserOperation을 보내는 계약 계정입니다. 스마트 계약 지갑은 ERC-4337의 IAccount 인터페이스를 구현해야 합니다.

EntryPoint — UserOperations 패키지를 구현하는 싱글톤 계약입니다. 번들러/클라이언트 화이트리스트는 EntryPoint를 지원합니다. 이 계약은 Infinitism 팀에 의해 승인 및 검토되었으며 모든 UserOperations를 처리하고 Wallet Factory, Aggregator, Paymaster를 포함한 다른 계약을 연결하는 일을 담당합니다. 대부분의 EVM 호환 체인에서는 동일한 주소를 갖습니다.

Bundler — mempool에서 여러 UserOperations를 번들로 묶고 EntryPoint.handleOps() 트랜잭션을 생성하는 노드(블록 빌더)입니다. 프로토콜 계층의 모든 유효성 검사기는 번들러일 필요는 없습니다. Bundler 서비스는 블록 빌더와 독립적으로 실행될 수 있으며 RPC를 사용하여 번들된 UserOperations를 보냅니다.

Aggregator — 집계된 서명을 확인하기 위해 계정에서 신뢰하는 도우미 계약입니다. 번들러/클라이언트는 지원되는 수집기를 허용 목록에 추가합니다. 집계자는 ERC-4337 IAggregator 인터페이스를 구현해야 합니다.

Paymaster — EntryPoint 계약에 충분한 ETH가 예치된 경우 보낸 사람에게 UserOperation의 가스 요금을 지불할 수 있는 계약입니다. Paymaster는 효율적인 가스 추상화를 구현합니다. Paymaster는 ERC-4337의 Paymaster 인터페이스를 구현해야 합니다. Paymaster는 Sender와 거래를 하기 위한 자체 논리를 가질 수 있습니다. 예를 들어, 송금인은 USDC를 Paymaster에 지불하고 Paymaster는 ETH로 UserOperations를 후원합니다. 실제로 Paymaster가 동의하고 기술적으로 실현 가능한 한 모든 ERC 20 토큰 또는 다른 체인의 토큰도 지원할 수 있습니다.

Wallet Factory — ERC-4337 사용자를 위한 스마트 계약 지갑을 생성하기 위해 호출할 수 있는 계약입니다. 지갑 팩토리 배포는 허가가 없습니다. 온체인 구성요소로서 공개 감사 및 투명한 조사가 가능합니다. 널리 사용되는 Wallet Factory는 전문가의 철저한 감사를 받아야 합니다.

아래 다이어그램은 EntryPoint 계약이 다른 행위자와 상호 작용하는 방식을 설명합니다.

번들러는 UserOperation을 입력으로 사용하는 EntryPoint 계약의 handlerOps 함수를 호출합니다.

handlerOps는 체인의 UserOperation을 확인하고, 지정된 스마트 계약 지갑 주소로 서명되었는지, 지갑에 Bundler를 보상할 만큼 충분한 가스가 있는지 확인합니다.

검증이 성공하면, handlerOps는 UserOperation의 호출 데이터에 정의된 함수 서명 및 입력 매개변수에 따라 스마트 계약 지갑 기능을 실행합니다.

반면, Bundler가 EOA를 사용하여 handlerOps 기능을 실행하는 경우 가스 요금이 발생합니다. 스마트 계약 지갑은 자체 계정 잔액에서 번들러에게 가스 요금을 지불하거나 Paymaster 계약에 대신 지불하도록 요청할 수 있습니다. Gas가 충분하지 않은 UserOperations는 대상 스마트 계약 지갑의 검증 프로세스를 통과할 수 없으므로 실행 전에 실패합니다. 가스가 충분하더라도 런타임 오류 등으로 인해 실행 중에 UserOperations가 실패할 수 있습니다. 실행 성공 여부에 관계없이 EntryPoint 계약은 HandleOps 기능을 트리거하는 번들러에 가스 요금을 지불합니다.

(출처: 공식 문서: https://eips.ethereum.org/EIPS/eip-4337)

ERC-4337이 발효된 후, 사용자는 이제 블록체인 거래를 시작하는 두 가지 방법을 갖게 되었습니다. 하나는 EOA가 거래를 시작하는 원래 방식입니다. 다른 하나는 ERC-4337 표준을 사용하여 Bundler를 통해 UserOperation을 시작한 다음 Bundler가 이를 다른 UserOperations와 함께 패키징하고 체인에서 시작하는 것입니다. 다음 흐름도는 일반 EOA 전송 트랜잭션과 ERC-4337 계약 지갑 전송 UserOperation 간의 차이점을 보여줍니다.

도로는 포장되어 있지만 승객은 많지 않습니다.

ERC-4337은 사용자와 개발자가 Ethereum 플랫폼에서 AA를 사용하고 구축할 수 있는 강력한 프레임워크를 제공합니다. 이 프레임워크는 중요한 진전이지만 여전히 해결해야 할 몇 가지 과제와 불확실성이 있습니다.

AA의 채택은 아직 초기 단계입니다. Dune ERC-4337 분석 패널(@niftytable의 ERC-4337 계정 추상화)에 따르면 체인에서 65,000개 이상의 UserOperations만 실행되며 그 중 90%는 Polygon에서 발생합니다. 따라서 현재 수행되는 UserOperations의 수는 여전히 매우 적으며, 대부분은 개발자 테스트이고 작은 부분만이 사용자에게 귀속됩니다. AA를 통합한 제품은 아직 초기 단계입니다. 동시에 Bundler의 이익은 마이너스(MATIC 기준으로 -700)임을 알 수 있습니다. 이는 Polygon의 일부 번들러가 사전 검증 가스를 올바르게 계산하지 않기 때문입니다. 이 검증 알고리즘에는 여전히 최적화가 필요합니다.

그 외에도 해결해야 할 몇 가지 문제가 있습니다. 그러한 문제 중 하나는 번들러가 트랜잭션 실패를 처리하는 방법입니다. Bundler가 여러 UserOperations를 함께 묶은 후 Bundler는 먼저 트랜잭션을 시뮬레이션하여 롤백할지 여부를 확인한 다음 보낸 사람 또는 Paymaster가 반환한 가스 수수료가 트랜잭션에서 지불한 가스 수수료보다 큰지 여부를 계산합니다. 수익성이 있는 경우 Bundler는 이 UserOperations 배치를 트랜잭션으로 함께 블록 빌더에 제출합니다. 그러나 트랜잭션이 여전히 실패하여 번들러가 가스 요금을 지불하지만 EntryPoint에서 가스를 돌려받지 못하는 결과가 발생할 수 있습니다. 예를 들어 사용자는 다른 번들러에 작업을 보낼 수 있습니다. 번들러는 수익성이 있고 시뮬레이션이 성공적인 경우 온체인 작업을 기꺼이 제출합니다. 이는 UserOperation이 동시에 여러 번들러에 의해 제출되는 경우를 의미합니다. 단 하나의 거래만 성공하고, 단 하나의 번들러만 EntryPoint로부터 가스 수수료를 받게 되며, 다른 모든 번들러는 온체인 오류로 인해 가스를 잃게 됩니다. 사용자가 이렇게 해서는 안 된다고 주장할 수도 있지만, 그러한 행동은 악의적인 공격으로 간주되며 Bundler가 보낸 사람 주소를 금지하고 이 주소에서 향후 요청을 거부할 수 있다고 주장할 수 있지만, 이는 사용자가 이 작업을 수행할 수 있기 때문에 합리적인 접근 방식이 아닙니다. 실수로 제출되었습니다. 이러한 문제는 미완성 공용 멤풀 네트워크를 개발하여 코드에서 적절하게 해결해야 합니다. 또한 갑작스러운 가스 변동으로 인해 트랜잭션이 성공적으로 제출되고 수익성이 있는 것으로 시뮬레이션되었더라도 번들러는 손실을 입을 수 있습니다.

또 다른 것은 AA에서 추출할 수 있는 최대 추출 가능 값(MEV)입니다. 이더리움의 맥락에서 MEV는 일반적으로 채굴자나 기타 거래 처리자가 블록 내 거래 순서를 조작하거나 자신의 거래를 블록에 포함시켜 추출할 수 있는 가치를 의미합니다. Bundler는 UserOperations를 자유롭게 주문할 수 있으므로 MEV의 논리가 AA에도 적용될 수 있다는 것을 아는 사람이 있습니까? 그러나 이는 조건부이므로 번들러가 MEV를 추출하려면 충분한 UserOperations를 함께 번들링해야 합니다. 이제 전체 AA 시장은 아직 초기 단계이므로 Bundler MEV도 초기 단계로 간주될 수 있습니다. 일반적으로 AA 산업은 두 가지 방향으로 발전할 수 있습니다. 하나는 Flashbots, Ultra Sound 및 BloXroute와 같은 참가자가 참여하는 이더리움 메인넷과 유사하며, 다른 하나는 공정한 주문을 시행하기 위해 Bundler 합의를 형성하는 것입니다. 후자의 접근 방식은 AA에서 MEV의 가능성을 완전히 제거합니다.

미래의 발전

공개 메모리풀

AA 생태계는 이미 작동하고 있지만 아직 해야 할 개발 작업이 많이 남아 있습니다. 전체 AA 생태계를 살펴보면 현재 가장 큰 격차는 공개 멤풀입니다. Skandha Bundler 클라이언트 개발자인 Etherspot 팀은 현재 공개 멤풀을 갖춘 p2p 네트워크를 개발하고 있습니다. 공공멤풀의 P2P 네트워크는 올해 8월 출시될 예정이다.

패킹 알고리즘

그 과정에서 Ethereum Foundation은 헌신적이고 열심히 일하는 개발자로 구성된 여러 AA 개발 팀에 자금을 지원했습니다. 현재까지 여러 버전의 Bundler 클라이언트가 개발되어 현재 사용 가능합니다. 그 중 일부는 제품 성숙도 측면에서 고도로 발전되어 있습니다. Candide(Python으로 작성된 Voltaire Bundler), Pimlico(Typescript로 작성된 Alto Bundler), Etherspot(Typescript로 작성된 Skandha Bundler), Stackup(Go로 작성된 Stackup-Bundler) 등이 있습니다.

이제 패킹 알고리즘에 대해 더 자세히 살펴보겠습니다. 현재 UserOperations 수가 적기 때문에 번들러는 고정된 시간 간격이나 각 번들의 UserOperations 수와 같은 간단하고 간단한 패키징 로직을 사용할 수 있습니다. 그러나 UserOperations 수가 증가함에 따라, 특히 공용 mempool 도입 이후 UserOperations 선택 및 패키징 전략이 더욱 복잡해졌습니다. 그 이유는 간단합니다. 블록체인과 같은 합의 프로토콜이 없으면 번들러는 각자 자신의 이익에 따라 작업의 우선 순위를 정하고 서로 경쟁하는 어둠의 숲을 형성합니다. 공개 멤풀에 상응하는 비공개 멤풀이 먼저 나올 가능성이 더 높습니다. 공개 mempool에서 UserOperations를 패키징하는 것이 수익성이 없을 때 UserOperations를 비공개 mempool에 함께 패키징하는 것이 수익성이 있을 수 있기 때문입니다. 이러한 방식으로 Bundler는 패키징 측면에서 경쟁 우위를 확보합니다.

또한, 공개 멤풀이 점진적으로 수용됨에 따라 그 안의 UserOperations는 다양한 가스 이익 기대치 및 온체인 실행 복잡성과 같은 다양한 특성을 갖게 됩니다. 번들러는 오프체인 시뮬레이션을 수행하여 다양한 UserOperations 조합의 수익성을 평가하여 고유한 번들링 전략을 수립합니다. 더 많은 UserOperations를 패킹하면 더 많은 수익을 얻을 수 있지만 유효성 검사 실패의 위험도 높아집니다. 검증이 통과되더라도 체인에서의 실행 실패 위험은 여전히 ​​존재합니다. 덜 패키지된 UserOperations는 그 반대입니다. 번들러는 자체 트랜잭션 가스 매개변수를 설정해야 하며, 이는 트랜잭션을 실행하는 블록 빌더의 우선순위에 영향을 미칩니다. 다양한 시장 가스 가격과 가스 변동성 조건에서 번들러는 다양한 패키징 전략을 가질 수 있습니다. 동시에 이러한 검증 및 정책 계산은 로컬 하드웨어 컴퓨팅 리소스와 블록체인 노드 리소스를 소비해야 합니다. 또한 번들러는 사용자에게 좋은 경험을 제공하고 UserOperation을 제출한 후 사용자가 과도한 지연을 겪지 않도록 해야 합니다.

이러한 과제에 대한 해결책은 여전히 ​​불확실하지만, AA 산업의 발전과 개발자들의 결합된 노력이 결국 해결책을 찾을 것이라고 확신할 수 있습니다. 인프라 빌더로서 BlockPI는 개발자로서든 다른 개발자에게 친숙한 AA 인프라를 제공하든 AA 산업 발전의 문제를 해결하기를 희망합니다.

인프라는 적응해야 합니다

AA는 발신자, 번들러, 가스 납부자, 계약 지갑, 서명자를 포함하여 체인의 거래 행동에서 다양한 역할을 추상화하여 사용자가 블록체인을 사용할 때 더 높은 자유도를 가질 수 있도록 합니다. 또한 AA 내의 서비스는 별도로 배포될 수 있습니다.

AA의 대규모 채택에 적응하려면 인프라 제공업체는 먼저 Bundler 서비스와 Paymaster 서비스라는 두 가지 이상의 기본 서비스를 제공해야 합니다.

Bundler 서비스에서 인프라 제공자는 좋은 사용자 경험을 보장하기 위해 Bundler를 사용하여 개인 멤풀을 개발해야 할 수도 있습니다. 특히 인프라 제공업체는 Bundler 서비스의 견고성을 보장하기 위해 다양한 Bundler 클라이언트를 통합해야 합니다. 이러한 Bundler 클라이언트는 다양한 프로그래밍 언어로 개발되었지만 모두 ERC-4337 핵심 팀에서 지정한 표준 JSON RPC 방법 세트를 제공합니다. 현재는 사용할 수 있는 방법이 많지 않지만 앞으로 더 많은 방법이 추가될 예정입니다. 인프라 서비스 제공업체는 이러한 API에 대해 지속적이고 완전한 지원을 제공해야 합니다.

또한 인프라 제공업체는 고객에게 가스 없는 사용자 경험을 제공하고 다양한 서비스 옵션을 제공하기 위해 다양한 Paymaster 서비스를 통합해야 합니다. 이를 위해서는 제3자 Paymaster 서비스 제공업체와의 원활한 의사소통 및 통합이 필요하며, 동시에 시장 수요에 따라 기존 Paymaster 서비스를 기반으로 보다 편리한 통합 솔루션을 설계할 수도 있습니다. 통합 서명, 지갑 팩토리 등과 같은 기타 서비스도 향후 개발 및 통합을 위한 가능한 방향입니다.

요약하다

현재 BlockPI는 실제로 위의 모든 목표를 달성하려고 노력하고 있습니다. 뿐만 아니라 커뮤니티 내 거의 모든 Bundler 클라이언트 및 Paymaster 서비스 제공업체와 소통하고 있으며 AA 서비스를 BlockPI Network에 통합하는 것을 최우선 과제로 삼았습니다. 또한 사용자의 요구를 이해하기 위해 AA 지갑 개발자와 심도 있는 논의를 진행하고 있습니다. 따라서 우리는 앞으로 나아가는 동안 모든 번들러, 페이마스터, 지갑과의 협력과 교류를 진심으로 환영합니다. 우리의 전반적인 목표는 다른 사람들과 함께 AA 생태계를 구축하고 개발하여 최선을 다해 성장과 발전을 촉진하는 것입니다. 우리는 함께 협력함으로써 AA 산업 전체에 의미 있는 기여를 하고 지속적인 발전을 지원할 수 있기를 바랍니다. 왜냐하면 결국 우리의 궁극적인 임무는 업계의 선구자가 되어 웹2 사용자가 장벽 없이 블록체인 경험을 즐길 수 있도록 AA 생태계의 발전을 촉진하는 것이기 때문입니다.

요약하다

AA의 관점에서 볼 때, 우리는 새로운 역사적 순간에 있습니다. 대로변에 도로가 포장되어 있지만 아직 라이더가 많지 않습니다. 현재 AA 적용은 아직 초기 단계에 있으며, ERC-4337은 사용자와 개발자가 이더리움 플랫폼에서 AA를 사용하고 구축할 수 있는 강력한 프레임워크를 제공하지만 여전히 해결해야 할 과제와 불확실성이 많이 남아 있습니다.

AA의 인프라 제공자는 사용자에게 Bundler 서비스와 Paymaster 서비스를 제공해야 하며, 서비스의 견고성을 보장하기 위해 다양한 Bundler 클라이언트와 Paymaster 서비스 제공자를 통합해야 합니다. API와 노드 클라이언트 간의 응답성을 최적화하려면 단일 요청에 대한 하드웨어 소비를 줄이기 위해 AA 데이터를 인덱싱해야 할 수도 있습니다. 더 나은 사용자 경험을 제공하기 위해 인프라 제공업체는 사용자에게 더 많은 서비스 옵션을 제공해야 합니다.