EIP-4337의 마지막 퍼즐 조각: 전체 체인 계정 추상화

저자: Peter Pan, Particle Network의 공동 창립자 및 CTO \& Faust, 극한의 Web3

2022년부터 현재까지, 계정 추상화는 널리 논의되고 있는 주제이며, EIP-4337을 중심으로 한 계정 추상화 분야의 프레임워크는 업계의 일반적인 합의가 된 것 같습니다. 의도 개념의 열기는 사람들이 이러한 낮은 진입 장벽의 사용자 상호작용 구성 요소에 대한 중요성을 강화하도록 촉구했습니다. 그러나 EIP-4337은 여전히 스마트 계정의 계정 단편화와 크로스 체인 간의 계정 추상화 사용자 경험의 심각한 단절이라는 문제를 안고 있습니다. 이 글에서는 Biconomy, Safe Core, Particle Network 등의 프로젝트를 예로 들어 EIP-4337 프레임워크 하에서 계정 추상화 분야의 발전을 어떻게 촉진할 수 있는지 논의합니다.

거래 프로세스 추상화 관점에서 "계정 추상화" 개념 이해하기

계정 추상화에 관해 Vitalik은 여러 차례 언급했듯이, 이는 이더리움 사용자 진입 장벽을 낮추고 대중적 채택을 실현하기 위한 필수 조건이며, 그 핵심 비전은 사용자가 사용자 정의 서명 방법을 설정하고 가스 비용을 대납받으며 자산 없이도 체인에서 거래를 시작할 수 있도록 하는 것입니다(소위 무가스 거래). 이러한 전제가 충족되어야만 Web3 애플리케이션의 신규 사용자 전환율을 높일 수 있습니다. 이전의 비계정 추상화 제안이나 스마트 계약 지갑은 유사한 경험을 제공할 수 있지만, 여전히 유연성과 효율성이 부족합니다. 예를 들어 Gnosis Safe는 여전히 EOA 주소를 통해 거래를 촉발해야 하며, 가스 비용이 매우 높습니다. 계정 추상화는 스마트 계약 계정의 구조적 기반에서 최적화를 시도하여 차세대 스마트 계정 시스템을 위한 길을 열고자 합니다. 그러나 실제 계정 추상화 제안을 살펴보면, 그들의 관심사는 계정 모델 자체에 있지 않다는 것을 알 수 있습니다. 예를 들어 EIP-86, EIP-4337 및 EIP-6900과 같은 계정 추상화 관련 제안은 거래가 시작되어 노드에 의해 수신되고, 서명되고, 가스가 지불되는 전체 처리 프로세스의 추상화/모듈화에 초점을 맞추고 있으며, 실제로 계정 구조의 추상화에 진정으로 관심을 두고 있지 않습니다. 따라서 현재의 다양한 제안을 "거래 추상화"라고 부르는 것이 더 적절할 것 같습니다. "거래 처리 프로세스의 추상화" 관점에서 잘 알려진 계정 추상화 제안을 이해하면 그 요점을 더 쉽게 이해할 수 있습니다: 이러한 거래 추상화는 실제로 Web2 수준의 사용자가 제품에 접근하고 사용하는 경험을 이더리움 시스템 내로 가져오고자 하는 것입니다. 예를 들어 블랙리스트/화이트리스트, 일정 기간 내 거래 시 신원 확인 불필요, 무가스 거래, 법정 화폐 수수료 지불 등이 있습니다. （이미지 출처: Zengo） 그러나 누군가는 질문할 것입니다: 이러한 것들이 과거의 스마트 계약 지갑에서 구현되지 않았나요? EIP-4337과 같은 계정 추상화 솔루션의 가치는 어디에 있나요?

EIP-4337의 본질: 이더리움 생태계에서 계정 추상화의 국소 최적 해법

위의 질문에서 언급했듯이, 과거의 스마트 지갑은 위에서 언급한 기능을 구현할 수 있었지만, 구현 방식이 일반적으로 거칠고 종종 고도로 중앙집중화된 제3자 시설에 의존했습니다. 예를 들어 과거의 가스 대납 솔루션은 제3자의 릴레이어 노드를 도입해야 했습니다(EIP-2771). 또한, 서로 다른 스마트 지갑 간에 통일된 표준이 부족하여 부가적인 구성 요소 개발 및 배치에 불리합니다. 다양한 계정 추상화 관련 EIP의 핵심 요구는 스마트 계약 지갑을 위해 특별히 설계된 표준화된 프레임워크를 통해 서로 다른 지갑 프로젝트에서 존재하는 결함을 해결하고, 이더리움 생태계 내의 계정 구조를 기본 기능 구조에서 더 높은 한계를 가진 스마트 구조로 전환하는 것입니다. （이미지 출처: Springer Link） 이는 ERC-20 또는 ERC-721이 등장하기 전, 많은 토큰의 구현 방식, 기능, 외부에 제공하는 함수/인터페이스가 일관되지 않았던 것과 같습니다. "일관되지 않음"은 제3자 시설 개발에 불리하며, 코드 감사에도 불리합니다(ERC-20 프로토콜이 없다면 DeFi 애플리케이션이 현재의 번영 수준에 어떻게 발전할 수 있었을지 상상하기 어렵습니다). 표준화된 프로토콜/기능 구현 표준은 모듈화 서사의 전제 조건이며, 모듈화 개발 방식은 거의 모든 분야에서 번영을 원할 때의 전제 조건입니다 (분업은 효율성을 높이는 첫 번째 원칙입니다). 결국 EIP-4337이 두각을 나타냈습니다.

EIP-4337은 국소 최적 해법이지만, 그 프레임워크 내에는 여러 최적화가 시급합니다

EIP-4337은 전체 인터페이스 표준을 정의하고, 4337 프로토콜을 준수하는 스마트 지갑이 최소한 어떤 모듈을 가져야 하는지, 각 모듈이 어떤 함수/인터페이스를 구현해야 하는지를 명확히 했습니다. 예를 들어 Bundler, EntryPoint, Paymaster와 같은 구성 요소는 외부에 어떤 호출 가능한 함수를 제공해야 하는지에 대한 것입니다. 이러한 규칙을 명확히 한 후, 다양한 구성 요소 간의 상호작용 관계가 더 명확해져 모듈화 설계 사고를 계정 추상화 및 스마트 지갑 설계에 도입하기 용이해졌습니다. 지갑 모듈 개발자들도 크게 혜택을 받았습니다. 물론, 사용자 관점에서 보면 모듈화된 스마트 지갑 개발 패러다임이 가져오는 가치는 아직 명확하지 않습니다. 왜냐하면 단기적으로 사람들은 계정 추상화 지갑 자체의 변화가 얼마나 큰지 느끼지 못할 것이기 때문입니다. 하지만 중장기적으로 보면 EIP-4337과 같은 프로토콜의 가치는 ERC-20 및 ERC-721과 유사합니다. 이는 계정 추상화 지갑의 장기 발전을 위한 기초를 마련하며, 시대를 초월한 이정표입니다. 하지만 EIP-4337은 여전히 해결되지 않은 많은 문제를 안고 있습니다: 예를 들어: 1. 계정 추상화 기능이 충분히 플러그인화되지 않아, 다양한 개발자들이 쉽게 중복된 작업을 하게 됩니다; 2. 계정 모듈의 호환성이 떨어져 전체 계정 시스템이 생태계에서 단편화되는 경향이 있습니다; 3. 서로 다른 체인 간의 계정 추상화 생태계가 심각하게 단절되어 최종 사용자와 개발자에게 통일되고 고품질의 경험을 제공하기 어렵습니다. 아래에서는 이러한 문제의 해결책을 논의할 것입니다.

최적화 방향 1: 계정 추상화의 기능 플러그인화가 기본 구성으로 자리잡을 것입니다

현재 계정 추상화와 관련된 핵심 논의 중 하나는 계정 추상화 지갑의 모듈화를 더 잘 구현하는 방법, 즉 각 모듈의 구분을 더 세분화하는 것입니다. 예를 들어 Biconomy는 EIP-4337을 기반으로(미래에는 더 세분화된 EIP-6900을 도입할 예정) 계정 추상화 기능 플러그인화의 서사를 제안하여 계정 추상화 생태계의 모듈화 발전을 촉진하고자 합니다. （이미지 출처: Biconomy） 계정 추상화 기능 플러그인화란, 특정 프로토콜을 통해 스마트 계약 지갑과 관련된 핵심 모듈이 무엇인지, 이러한 모듈이 어떤 인터페이스/함수를 구현해야 하는지를 외부에 명확히 하는 것입니다. 그런 다음, 제3자 개발자는 자신의 아이디어에 따라 세부 사항이 다양한 구성 요소를 개발할 수 있지만, 이러한 구성 요소는 모두 프로토콜에서 제시한 요구 사항을 충족해야 합니다. Biconomy의 V2 버전은 EIP-4337을 프로토콜 뼈대로 삼아 더 자세한 표준을 설정하고, 4337에서 언급되지 않은 여러 인터페이스를 추가했습니다. Bundler, 스마트 계약 지갑, Paymaster와 같은 모듈이 어떤 기능을 갖추어야 하는지를 명시하면서, Biconomy는 제3자 개발자가 서로 다른 코드 세부 사항으로 동일한 특성을 가진, 버전이 다른 모듈을 구현할 수 있도록 허용합니다. 단지 Biconomy가 사전에 선언한 프로토콜 세부 사항을 준수하기만 하면 됩니다(호환성 EIP-4337). （Biconomy가 제안한 인터페이스 표준으로, 제3자 모듈 개발자가 모듈 내에서 외부 호출을 위해 구현해야 하는 함수들을 명시합니다） 동시에, Biconomy는 "모듈 상점"이라는 슬로건을 제안하여, 계정 추상화 모듈 SDK를 출시하는 동시에, 많은 개발자들이 자신이 설계한 계정 추상화 모듈을 제출하도록 장려하고, "모듈 서비스"를 전개합니다. 이를 통해 EIP-4337 프로토콜을 준수하는 모든 지갑 프로젝트가 외부에서 작성된 이러한 계정 추상화 모듈을 직접 사용할 수 있게 됩니다. 사용자는 프론트엔드 페이지를 통해 스마트 계정을 생성할 때 어떤 모듈을 사용할지에 대한 더 다양한 선택을 할 수 있습니다. 모듈화는 분업을 용이하게 할 뿐만 아니라, 사용자가 스마트 지갑 내에서 특정 기능을 빠르게 전환하거나 추가, 삭제할 수 있도록 합니다(즉, 구분을 더 세분화하는 것입니다). Biconomy는 스마트 계약 지갑의 모듈화 정도가 높을수록 업데이트나 업그레이드 시 필요한 변경 사항이 적어진다고 지적합니다. (기존의 스마트 계약 지갑 계약을 업데이트할 필요가 없거나 DelegateCall을 사용할 필요가 없으며, 특정 외부 모듈만 업데이트하면 됩니다.) Biconomy의 향후 새로운 계정 추상화 솔루션에서는 EIP-4337보다 모듈화에 더 유리한 EIP-6900 제안을 참고할 예정입니다.

최적화 방향 2: 더 세분화된 모듈 구분으로 계정 단편화 문제 해결하기

EIP-6900 제안에 관해, Safe(구 Gnosis Safe)는 올해 8월에 관련된 Safe Core Protocol 백서를 발표했으며, 그 중 가장 많이 참조된 것은 EIP-6900입니다. （EIP-6900 원리도） EIP-6900은 현재 모듈화된 계정 추상화의 한 가지 문제는 계정의 "단편화" 또는 고립 문제라고 지적합니다. 예를 들어 서로 다른 계정 추상화 모듈 공급자나 서로 다른 DAPP 애플리케이션은 EIP-4337을 호환할 수 있지만, EIP-4337은 서로 다른 모듈에 대한 추상화 정도가 충분히 높지 않으며, 구분이 거칠어 스마트 계정 모듈 개발자에게 "과도한" 자유도를 남깁니다(스마트 계정은 사용자 정보를 저장하고 사용자 정의 거래 검증 및 가스 지불 논리를 기록하는 가장 핵심적인 부분입니다). 이로 인해 서로 다른 지갑 프로젝트는 독특한 속성을 가진 스마트 계정 모듈을 설계하는 경향이 있습니다. 이런 식으로 시간이 지나면 다른 계정 추상화 모듈 공급자는 누구의 스마트 계정 모듈과 호환할지를 우선 고려해야 하며, 점차 고정된 상하 공급망이 형성될 것입니다. 이는 필연적으로 계정 추상화 모듈 생태계의 단편화와 서로의 단절을 초래할 것입니다. (이는 컴퓨터 산업 초기에서 운영 체제 개발자가 어떤 컴퓨터 하드웨어 제조업체의 장비와 호환될지를 먼저 고려해야 했던 것과 같습니다.) 생태계의 단편화 문제를 해결하고 서로 다른 공급자가 개발한 계정 추상화 모듈의 호환성을 높이는 최선의 방법은 스마트 계약 지갑 계정을 더욱 추상화하고 모듈 구분의 세분화를 이루는 것입니다. EIP-6900의 사고를 참고하여 Safe Core 프로토콜 백서는 스마트 계정(사용자의 스마트 지갑 계정)을 더 세밀하게 최적화했습니다. Safe Core 프로토콜은 각 스마트 지갑 계정에서 호출 가능한 모듈을 플러그인, 훅, 서명 검증기, 함수 처리기 등 여러 범주로 나누었습니다. 스마트 계정 모듈은 가능한 한 경량화되며, 계정 계약은 가장 기본적인 데이터와 함수만 저장하고, 외부로 이동할 수 있는 함수는 모두 "함수 처리기" 또는 "플러그인"과 같은 세분화된 모듈에 맡깁니다. 이는 소위 오컴의 면도날 원칙에 부합합니다—"필요 없다면 실체를 늘리지 말라." 만약 스마트 계정 자체가 충분히 경량화되어 복잡한 세부 사항을 포함하지 않는다면, 서로 다른 제조업체가 개발한 스마트 계정은 내부 구조에서 더 가까워지고 호환성도 높아질 것입니다. Safe Core 프로토콜은 또한 iPhone의 애플리케이션 스토어와 유사한 등록부를 도입하여, 모든 승인된 사용 가능한 모듈을 포함합니다. 사용자는 어떤 모듈을 활성화할지 선택할 수 있으며, 새로운 모듈을 활성화할 때마다 Manger 계약을 통해 처리해야 합니다. 일반적으로 UserOperation은 먼저 특정 플러그인 Plugin을 트리거하고, Manger 계약은 해당 플러그인의 상태가 정상인지(등록부에 기록이 있는지)를 확인합니다. 정상이라면 플러그인의 요청을 허용합니다. 필요할 경우 플러그인은 특정 훅이 제공하는 기능을 호출하거나 호출하지 않을 수 있습니다. 이후 UserOperation과 관련된 스마트 계정의 상태를 변경합니다. 위의 세분화된 모듈 구분 방식과 조정 프로세스를 통해 Safe Core Protocol은 오픈 소스 계정 추상화 모듈 상호 운용 프로토콜을 추진하려고 하며, 그 핵심 사고는 스마트 계정을 경량화하여 가능한 한 EOA 계정처럼 간단하게 만들어 서로 다른 제조업체가 개발한 스마트 계정 모듈의 호환성을 높이는 것입니다.

최적화 방향 3: 전 체인 계정 추상화, 서로 다른 체인에서 통일된 계정 구현하기

하지만 앞서 언급한 해결책이 있더라도, 현재 해결되지 않은 큰 문제가 있습니다: 서로 다른 체인과 서로 다른 Layer2가 세부 사항이 다른 계정 추상화 구현 솔루션을 추진하고 있으며, 많은 경우 EIP-4337과 충돌하는 형태를 채택하고 있습니다. 예를 들어 zkSync Era, Starknet, Flow 등이 있습니다. 이는 사용자에게 지갑 UX의 단절을 초래합니다. 예를 들어 사용자가 Starknet의 스마트 지갑 주소와 Arbitrum의 스마트 지갑 주소를 통합할 수 없습니다. 또한 다중 체인 환경에서 사용자는 서로 다른 체인에 독립적으로 배포된 스마트 계정을 가지고 있으며, 해당 사용자 데이터는 종종 이러한 계약에 분산 저장됩니다. 사용자의 데이터(예: 키 등)를 업데이트해야 할 경우, 여러 체인에서 거래를 반복적으로 발행해야 하며, 스마트 계정의 일관성을 보장하기 어렵습니다. Vitalik은 이전에 이더리움 또는 매우 안전한 ZKRollup을 소스 체인으로 하여, 사용자의 전역 키를 저장하는 Keystore 계약을 배포하는 전 체인 통일적이고 관리하기 쉬운 스마트 계정 솔루션을 제안했습니다. 이 솔루션은 소스 체인에서 Keystore 계약에 기록된 전역 키가 변경될 때마다 L2/목표 체인에 있는 각 계정이 새로운 키를 동기화하기 위해 크로스 체인 상호작용을 통해 진행해야 합니다. 이더리움과 L2 간의 크로스 체인 상호작용 비용이 너무 높아 사용자가 감당할 수 없습니다. 또한 스마트 계약 계정은 EOA 계정과 다르며, 후자는 고유한 주소 생성 방식 덕분에 본질적으로 다중 체인 통일성이 있습니다(EVM 체인 간 통일). 하지만 스마트 계약 계정은 완전히 다릅니다. 사용자가 서로 다른 체인에서 동일한 주소의 스마트 계약 계정을 갖는 것은 매우 어렵습니다. 이에 대해 Particle Network는 자신만의 방법을 제안했습니다. 기본적인 사고는 Vitalik의 아이디어와 유사하며, 스마트 계정의 저장소와 코드를 분리하는 것입니다. 하지만 Particle Network는 독립적인 체인인 Particle Network Chain을 스마트 계정의 전 체인 저장소 데이터베이스로 사용하고, 제3자의 크로스 체인 메시지 전송 솔루션(LayerZero, CCIP, Axelar, Connext 등)을 통해 특정 사용자의 계정 저장소 변경 사항을 다른 체인의 Account 로컬로 동기화할 계획입니다. (Particle Network의 다중 체인 계정 추상화 구조) 구체적으로, Particle Network의 전 체인 계정 추상화 시스템은 사용자가 서로 다른 EVM 체인에서 통일된 스마트 계약 계정 주소를 갖도록 하며, 이를 위해 서로 다른 체인에 Deployer Contract를 배포해야 합니다. 사용자는 Particle Network Chain에서 새 계정 생성을 트리거해야 하며, 이후 Particle Chain은 모든 체인에서 Deployer Contract를 트리거하여 서로 다른 체인에서 사용자를 위해 생성된 스마트 계약 계정 주소가 통일되도록 보장합니다. 또는 사용자는 다른 체인에 대한 인식 없이 Particle Chain의 계약을 통해 다중 체인 상호작용 프로세스를 완료할 수 있으며, 통일된 수수료 지불 방식으로 Unified Gas Token을 사용할 수 있습니다. 전 체인 계정 추상화는 또한 크로스 체인의 사용자 작업을 가능하게 하며, 소스 체인의 사용자 작업과 해당 가스를 지불하여 목표 체인의 거래를 트리거할 수 있습니다. 예를 들어 Polygon의 USDC를 사용하여 Base에서 NFT를 구매하는 것이 가능합니다. 그러나 Particle Network의 솔루션은 Deployer Contract와 크로스 체인 메시지 전송 구성 요소가 높은 협업을 요구하여 다중 체인 계정과 소스 체인 저장소의 동기화를 실현해야 하며, 이는 실제로 사용하는 오라클이나 크로스 체인 메시지 브리지에 높은 요구를 하게 됩니다(이 문제는 전 체인 상호 운용과 관련된 모든 솔루션에서 발생하는 것 같습니다). 그러나 사용자의 크로스 체인 계정 동기화는 서로 다른 메시지 브리지 조합을 유연하게 구성할 수 있으며, 단지 하나의 브리지에 의존하지 않고, 예를 들어 2/3 전략으로 구성하여 LayerZero, Axelar, Connext 중 두 개의 확인이 필요할 때만 목표 체인에서 저장소 변경을 확인할 수 있습니다. EVM과 비-EVM 간의 전 체인 원활한 상호 운용은 이더리움 생태계 내의 전 체인 계정 추상화의 한 단계 더 나아간 것입니다. EVM 체인 간의 키 관리와 통일된 계정이 있음에도 불구하고, 전 체인 계정 추상화는 여전히 최적화 공간이 있습니다: 비-EVM 체인(예: Aptos, Solana, Sui 등)에서는 사용자가 생성한 스마트 계약 계정 주소가 EVM 체인과 일치하지 않을 수 있습니다. 또한 비-EVM 체인이 EIP-4337 프로토콜을 구현하는 동등한 솔루션이 없다면, 앞서 Vitalik과 Particle Network이 제안한 전 체인 계정 추상화 구상을 따르기 어렵습니다. 게다가 EIP-4337을 호환하는 지갑 프로젝트 자체도 발전의 여지가 있습니다. 대부분의 스마트 지갑이 사용하는 Bundler 노드는 공식적으로 독립적으로 운영되며, 서로 통신하지 않으며, 많은 스마트 지갑 프로젝트는 실제로 독립적인 체인을 형성하고 있습니다. 이는 많은 위험(검열 저항성, 가용성)을 초래합니다. 대부분의 체인을 아우르는 단일 프론트엔드 인터페이스를 구축하는 것은 매우 어려울 것입니다. 한 가지 해결책은 의도를 중심으로 한 디자인을 도입하여 전 체인 계정 추상화 위에 한 층을 추가하는 것입니다. 이더리움의 EIP-4337 생태계나 다른 체인의 원주율 계정 추상화 시설(예: zkSync)을 모두 Solver/Reactor 유형의 구체적인 인스턴스로 간주하고, 적절한 Solver를 선택하는 것이 더 높은 수준의 작업입니다. 예를 들어 Particle Network는 간단한 추상화된 Intent-Centric 구현 솔루션을 제안하며, 서로 다른 계정 추상화 프로젝트는 Intent 솔루션 내에서 Solver 범주에 포함된 인스턴스 중 하나일 뿐입니다. 먼저 사용자의 프론트엔드는 자연어 요청이나 임의의 사용자 상호작용을 구체적인 프로그래밍 설명으로 변환하며, 여기에는 입력 제약과 출력 제약이 포함됩니다(즉, 사용자의 요구를 충족하는 입력 조건과 출력 결과 범위를 정의합니다). 이후 Solver 네트워크의 특정 Solver가 포함된 구체적인 입력 출력 제약을 가진 거래를 체인에 배포된 Solver 계약으로 전달합니다(솔버는 노드 시설뿐만 아니라 체인 상의 계약 부분도 포함됩니다). Solver 계약은 Intent 지시를 Reactor 계약(체인에서 사용자의 계정을 관리)으로 전달하여 후자가 다른 모듈을 호출하여 최종 상호작용을 완료하도록 합니다. 사용자의 요청은 처음에 Solver 네트워크에 의해 인식되며, 사용자는 기본 체인이나 서로 다른 계정 추상화 솔루션의 구조를 과도하게 인식할 필요가 없습니다. 이 부분은 Solver가 구체적인 해결책을 구성하도록 맡기면 됩니다. 물론 이러한 구상은 현재 이론적 프레임워크에 불과하며, 후속 구현 세부 사항은 Particle Network의 공식적인 발표를 기다려야 합니다. 현재 비교적 확실한 것은, 미래에는 경쟁이 치열한 Solver 시장이 반드시 생겨날 것이라는 점입니다. 사용자는 경매를 시작하여 여러 Solver가 서로 다른 해결책을 제시하도록 하고, 로컬 시뮬레이션 거래를 통해 최적의 해결책을 선정하고 해당 Solver에 보상을 제공할 수 있습니다. 보상의 형태는 Solver 네트워크의 프로토콜 설계자의 고려에 따라 달라질 것입니다(Particle Network는 PNT 토큰을 Solver 경매 시장의 보상 토큰으로 사용할 계획입니다). 현재의 Intent는 하위의 복잡한 세부 사항을 차단하고 더 높은 수준으로 추상화된 것입니다. 이러한 TCP/IP 프로토콜 성격의 계층적 설계는 전 체인 원활한 상호 운용 하에서 사용자 경험과 개발자 경험 모두에 필수적입니다. 계정 추상화의 대규모 채택을 맞이하기 위해 이더리움 생태계 내의 4337 프레임워크를 다양한 각도에서 최적화한 후, 이더리움과 비이더리움 생태계 간의 전 체인 원활한 상호 운용을 추진했습니다. 계정 추상화의 대규모 채택을 지원하기 위해, 우리는 여전히 공급 측과 수요 측을 아우르는 제품이 필요하다고 생각합니다. 최종 사용자가 다양한 Web3 제품 서비스를 사용하는 데 드는 비용을 낮추는 동시에, 서비스 개발자에게 집중하여 개발자 진입 장벽을 낮추는 것입니다. 이 역할을 수행하는 최상의 제품 중 하나는 Particle Network의 모듈화된 계정 추상화 지갑 서비스(Modular Smart Wallet-as-a-Service) 제품입니다: （Particle Network의 Smart Wallet-as-a-Service 아키텍처）

• 이 서비스는 개발자가 자신의 애플리케이션에 모듈화된 계정 추상화 기능을 쉽게 통합할 수 있도록 하는 사용하기 쉬운 API 세트를 제공합니다;
• 개발자는 이 서비스를 사용하여 전 체인 계정을 생성하고 관리하며, 크로스 체인 상호작용을 수행하고 통일된 수수료 지불 방식을 사용할 수 있습니다;
• 이러한 서비스는 개발자에게 다중 체인 애플리케이션을 구축하는 더 유연하고 편리한 방법을 제공하고, 계정 추상화의 광범위한 채택을 촉진할 것입니다.

위의 개발자 친화적인 특성 외에도, 가장 중요한 특징은 Particle Network의 모듈화된 계정 추상화 지갑 서비스(Modular Smart Wallet-as-a-Service) 제품이 서명 계산을 기반으로 하여 개발자를 위한 계정 추상화 분야의 개방 생태계를 구축했다는 점입니다. 자사 개발의 계정 추상화 제품 모듈 외에도 다양한 계정 추상화 제품 및 서비스를 통합하여 전체 계정 추상화 분야의 다양한 개발자 제품 및 서비스의 채택도를 신속하게 추진할 수 있습니다. （Particle Network의 Smart Wallet-as-a-Service 모듈화 디자인） 기술이 수요에 봉사하도록 하여 ERC-4337 프레임워크의 다양한 각도의 제약을 해결한 후, 개발자 경험의 향상이 더 많은 우수한 사용자 경험을 가진 제품을 생성하도록 촉진하고, Web3 산업이 암호화 펑크 친화적인 금융 산업에서 대중 친화적인 소비자 산업으로 전환하는 속도를 가속화할 것입니다.