작성자: Peter Pan, Particle Network의 공동 창립자이자 CTO, Geek Web3의 Faust

계정추상화는 2022년부터 폭넓게 논의된 주제로, EIP-4337을 핵심으로 하는 계정추상 분야의 프레임워크는 업계 전반의 공감대가 된 것으로 보입니다. 의도 개념의 인기로 인해 사람들은 임계값이 낮은 사용자 상호 작용 구성 요소에 더 많은 관심을 기울이게 되었습니다.

그러나 EIP-4337에는 여전히 단편화된 스마트 계정 계정과 크로스체인 계정 추상화의 고도로 단편화된 사용자 경험이라는 문제점이 있습니다. 이 기사에서는 Biconomy, Safe Core 및 Particle Network와 같은 프로젝트를 예로 들어 EIP-4337 프레임워크에서 계정 추상화 필드의 개발을 더욱 촉진하는 방법을 논의합니다.

거래 프로세스 추상화의 관점에서 "계정 추상화"의 개념을 이해합니다.

계정 추상화와 관련하여 Vitalik은 이더리움의 사용자 임계값을 낮추고 대량 채택을 달성하기 위한 필수 조건이라고 여러 번 지적했습니다. 핵심 비전은 사용자가 서명 확인 방법을 사용자 정의하고 가스 지불을 즐길 수 있도록 하는 것입니다. 자산 없이 체인 거래를 시작합니다(일반적으로 가스 없는 거래라고 함). 이러한 전제조건을 실현해야만 Web3 애플리케이션의 신규 사용자 전환율을 향상시킬 수 있습니다.

이전의 비계정 추상 제안이나 스마트 계약 지갑은 유사한 경험을 달성할 수 있지만 충분히 유연하고 효율적이지는 않습니다.예를 들어 Gnosis Safe는 여전히 거래를 시작하기 위해 EOA 주소가 필요하며 가스 비용이 매우 높습니다.

계정 추상화는 스마트 계약 계정 구조의 최하위 계층에서 최적화되어 차세대 지능형 계정 시스템을 위한 길을 열어주기 위한 것입니다.

그러나 실제 계정 추상화 제안을 살펴보면 그들의 초점이 계정 모델 자체에 있지 않다는 것을 알 수 있습니다. 예를 들어 EIP-86, EIP-4337, EIP-6900 등 계정 추상화 관련 제안은 거래 개시부터 노드 수신, 서명 검증, 가스 지불 등 전체 처리 과정을 추상화/모듈화하는 데 중점을 두고 있다. 그러나 실제로 계정 구조의 추상화에 집중하지 마십시오. 따라서 현재의 다양한 제안을 "트랜잭션 추상화"라고 부르는 것이 더 적절해 보입니다.

이러한 잘 알려진 계정 추상화 제안을 "트랜잭션 처리 프로세스의 추상화" 관점에서 이해하면 요점을 더 쉽게 이해할 수 있습니다. 이러한 트랜잭션 추상화는 실제로 Web2 수준의 사용자가 제품에 진입하고 사용할 수 있도록 하기 위한 것입니다. 블랙리스트/화이트리스트 등 이더리움 시스템으로 도입, 일정 기간 내 거래 시작 시 신원 확인 불필요, 가스 거래 불가, 법정화폐 결제 수수료 등

(이미지 출처: 젠고)

하지만 어떤 사람들은 이렇게 질문할 수도 있습니다. 과거에는 스마트 계약 지갑에서 이런 것들이 구현될 수 없었나요? EIP-4337 이러한 유형의 계정 추상화 솔루션의 가치는 무엇입니까?

EIP-4337의 본질: 이더리움 생태계의 계정 추상화를 위한 로컬 최적 솔루션

위 질문에서 언급했듯이 과거의 스마트 지갑은 위에서 언급한 기능을 달성할 수 있었지만 구현 방법은 일반적으로 거칠고 고도로 중앙 집중화된 제3자 시설에 의존하는 경우가 많습니다. 예를 들어, 과거 가스 결제 솔루션에는 타사 Relayer 노드(EIP-2771) 도입이 필요했습니다. 더욱이, 다양한 스마트 지갑 간에 통일된 표준이 부족하여 지원 구성 요소의 개발 및 레이아웃에 도움이 되지 않습니다.

위 질문에서 언급했듯이 과거의 스마트 지갑은 위에서 언급한 기능을 달성할 수 있었지만 구현 방법은 일반적으로 거칠고 고도로 중앙 집중화된 제3자 시설에 의존하는 경우가 많습니다. 예를 들어, 과거 가스 결제 솔루션에는 타사 Relayer 노드(EIP-2771) 도입이 필요했습니다. 더욱이, 다양한 스마트 지갑 간에 통일된 표준이 부족하여 지원 구성 요소의 개발 및 레이아웃에 도움이 되지 않습니다.

다양한 계정 추상화와 관련된 EIP의 핵심 매력은 스마트 계약 지갑을 위해 설계된 표준화된 프레임워크를 통해 다양한 지갑 프로젝트의 이러한 단점을 해결하고, 기본 기능 구조에서 이더리움 생태계의 계정 구조를 촉진하는 것입니다. 더 높은 천장.

(이미지 출처: Springer Link)

이는 ERC-20 또는 ERC-721이 출현하기 전에는 많은 토큰의 구현 방법, 기능 및 외부에서 제공되는 기능/인터페이스가 일관성이 없었고 "불일치"가 제3자 지원 개발에 도움이 되지 않았던 것과 같습니다. 시설, 그리고 제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. 서로 다른 체인 간의 계정 추상화 생태계는 고도로 단편화되어 있어 최종 사용자와 개발자에게 더 나은 UX를 달성하기 위한 통합된 고품질 경험을 제공하기가 어렵습니다.

아래에서는 이러한 문제에 대한 해결책을 살펴보겠습니다.

최적화 방향 1: 계정 추상화 기능 플러그인이 기본 구성이 됩니다.

계정 추상화와 관련된 핵심 논의 포인트 중 하나는 계정 추상화 지갑의 모듈화를 어떻게 더 잘 구현하고 각 모듈의 세분화를 더 미세한 부분으로 자르는가 하는 것입니다.

예를 들어, Biconomy는 계정 추상화 생태계의 모듈식 개발을 더욱 촉진하기 위해 EIP-4337(향후 세분화된 EIP-6900이 도입될 예정)을 기반으로 계정 추상화 기능을 위한 플러그인 내러티브를 제안했습니다.

예를 들어, Biconomy는 계정 추상화 생태계의 모듈식 개발을 더욱 촉진하기 위해 EIP-4337(향후 세분화된 EIP-6900이 도입될 예정)을 기반으로 계정 추상화 기능을 위한 플러그인 내러티브를 제안했습니다.

(이미지 출처: 바이코노미)

소위 계정 추상화 기능의 플러그인은 실제로 스마트 계약 지갑에 어떤 핵심 모듈이 포함되어 있는지, 이러한 모듈이 구현해야 하는 인터페이스/기능은 무엇인지, 이름은 무엇인지 외부 세계에 명확히 하기 위해 일련의 프로토콜을 사용하는 것입니다. 그리고 이러한 인터페이스의 호출 메소드. 그런 다음 제3자 개발자는 자신의 아이디어에 따라 다양한 세부 사항을 갖춘 구성 요소를 개발하지만 이러한 구성 요소는 모두 계약에 명시된 요구 사항을 준수합니다.

Biconomy의 V2 버전은 EIP-4337을 프로토콜 뼈대로 사용하고 보다 상세한 표준을 공식화하며 4337에서 언급되지 않은 여러 인터페이스를 추가합니다. Bundler, Smart Contract Wallet 및 Paymaster와 같은 모듈이 어떤 기능을 가져야 하는지 선언하는 동안 Biconomy는 타사 개발자가 Biconomy의 사전 선언을 따르는 한 동일한 기능 및 다른 버전의 모듈을 구현하기 위해 다른 코드 세부 정보를 사용할 수 있도록 허용합니다. 계약 세부정보(EIP-4337과 호환 가능)

(Biconomy가 제안한 인터페이스 표준은 타사 모듈 개발자가 외부 호출을 위해 모듈 내에서 구현해야 하는 기능을 지정합니다.)

동시에 Biconomy는 "Module Store"라는 슬로건도 제안했으며, 계정 추상화 모듈 SDK를 적극적으로 출시하는 동시에 개발자가 자신이 설계한 계정 추상화 모듈을 제출하고 "Module as a service"를 출시하여 이를 준수하는 모든 개발자가 참여할 수 있도록 독려합니다. EIP-4337 프로토콜을 사용하면 모든 지갑 프로젝트에서 외부인이 작성한 이러한 계정 추상화 모듈을 직접 사용할 수 있습니다. 사용자가 프런트엔드 페이지를 통해 스마트 계정을 만들면 사용할 모듈에 대한 선택도 더욱 다양해집니다.

모듈화는 작업 분업을 용이하게 할 뿐만 아니라 사용자가 스마트 지갑의 특정 기능을 빠르게 전환하거나 추가 또는 삭제할 수 있도록 돕습니다(직설적으로 말하면 입도를 더 미세한 부분으로 나누는 것을 의미합니다).

Biconomy는 스마트 계약 지갑의 모듈성이 높을수록 업데이트 또는 업그레이드 시 필요한 변경 사항이 줄어든다고 지적했습니다(사용자의 기존 스마트 계약 지갑 계약을 업데이트하거나 DelegateCall을 사용할 필요가 없으며 특정 외부 모듈만 업데이트하면 됨). .다른 사용자나 개발자가 특정 구성 요소를 교체하는 것이 편리합니다.

Biconomy의 향후 새로운 버전의 계정 추상화 체계에서는 EIP-4337보다 모듈화된 EIP-6900 제안도 참조될 것입니다.

최적화 방향 2: 계정 단편화 문제를 해결하기 위한 보다 세분화된 모듈 분할

EIP-6900 제안과 관련해 세이프(구 노시스 세이프)는 실제로 올해 8월 관련 세이프 코어 프로토콜 백서를 출시했는데, 가장 많이 참고된 것이 EIP-6900이다.

(EIP-6900 회로도)

EIP-6900은 모듈식 계정 추상화의 현재 문제 중 하나가 계정의 "조각화" 또는 섬 문제라고 지적했습니다. 예를 들어, 서로 다른 계정 추상화 모듈 공급자 또는 서로 다른 DAPP 애플리케이션이 EIP-4337과 호환되지만 EIP-4337은 서로 다른 모듈을 충분히 높게 추상화하지 않으며 분할 세분성이 상대적으로 거칠기 때문에 스마트 계정 모듈 개발자는 " " 과도한' 자유도(스마트 계정은 사용자 정보 저장, 맞춤형 거래 검증 기록, 가스 지불 로직의 핵심 부분입니다).

결과적으로 다양한 지갑 프로젝트는 고유한 속성을 가진 스마트 계정 모듈을 설계하는 경향이 있습니다. 이런 일이 진행되면 다른 계정 추상화 모듈 공급업체는 다른 사람이 제공하는 스마트 계정 모듈과의 호환성을 우선시해야 하며 점차 고정된 업스트림 및 다운스트림 공급망이 형성될 것이며 이는 필연적으로 단편화 및 분리로 이어질 것입니다. 계정 추상화 모듈 생태. (이것은 컴퓨터 산업 초기에 운영 체제 개발자가 먼저 어떤 컴퓨터 하드웨어 제조업체가 호환 장비를 제공했는지 고려해야 했던 것과 같습니다.)

생태적 단편화 문제를 해결하고 다양한 공급업체가 개발한 계정 추상화 모듈의 호환성을 향상시키기 위한 가장 좋은 방법은 스마트 계약 지갑 계정을 더욱 추상화하고 모듈 분할 세분성을 더욱 세밀하게 만드는 것입니다.

Safe Core 프로토콜 백서는 EIP-6900의 아이디어를 바탕으로 Smart Account(사용자의 스마트 지갑 계정)에 대한 보다 세부적인 최적화를 수행합니다. Safe Core 프로토콜은 각 스마트 지갑 계정에서 호출할 수 있는 모듈을 플러그인, 후크, 서명 검증기, 기능 프로세서 등 다양한 범주로 나눕니다.

스마트 계정 모듈은 최대한 가볍습니다. 계정 계약은 가장 기본적인 데이터와 기능만 저장합니다. 외부로 이동할 수 있는 모든 기능은 "기능 프로세서" 또는 "플러그인"과 같은 세분화된 모듈로 구현됩니다. 이는 소위 Occam의 면도날 원칙인 "필요하지 않은 경우 엔터티를 추가하지 마십시오"와 일치합니다.

스마트 계정 자체가 충분히 가볍고 너무 복잡한 세부 사항을 포함하지 않는다면, 서로 다른 제조업체에서 개발한 스마트 계정은 내부 구조가 더 가깝고 호환성이 더 높습니다.

Safe Core 프로토콜에는 승인되고 사용 가능한 모든 모듈이 포함된 iPhone App Store와 유사한 레지스트리도 도입되었습니다. 사용자는 활성화할 모듈을 선택할 수 있으며, 새 모듈이 활성화될 때마다 Manger 계약을 통해 처리되어야 합니다.

Safe Core 프로토콜에는 승인되고 사용 가능한 모든 모듈이 포함된 iPhone App Store와 유사한 레지스트리도 도입되었습니다. 사용자는 활성화할 모듈을 선택할 수 있으며, 새 모듈이 활성화될 때마다 Manger 계약을 통해 처리되어야 합니다.

정상적인 상황에서 UserOperation은 먼저 플러그인을 트리거한 후 Manger 계약이 플러그인 상태가 정상인지(레지스트리에 기록이 있는지) 확인합니다. 정상이면 플러그인의 요청 출시 예정. 필요한 경우 플러그인 플러그인은 Hook에서 제공하는 일부 기능을 호출하거나 호출하지 않습니다. 나중에 UserOperation과 관련된 스마트 계정의 상태가 변경됩니다.

위에서 언급한 세분화된 모듈 분할 방법 및 예약 프로세스를 통해 Safe Core Protocol은 오픈 소스 계정 추상화 모듈 상호 운용성 프로토콜 세트를 구현하려고 시도합니다. 핵심 아이디어는 스마트 계정을 EOA 계정만큼 가볍고 간단하게 만들어 개선 다양한 제조업체의 스마트 어카운트 모듈 호환성이 향상되었습니다.

최적화 방향 3: 다양한 체인에서 통합 계정을 달성하기 위한 전체 체인 계정 추상화

그러나 앞서 언급한 솔루션에도 불구하고 여전히 해결되지 않은 큰 문제가 있습니다. 서로 다른 체인과 서로 다른 Layer2가 서로 다른 세부 사항을 가진 계정 추상화 구현 솔루션을 홍보하고 있으며 이들 중 다수는 zkSync와 같은 EIP-4337과 충돌하는 형식을 채택하고 있습니다. 에라(Era), 스타크넷(Starknet), 플로우(Flow) 등 이로 인해 사용자를 위한 지갑 UX에 파편화가 발생했는데, 예를 들어 스타크넷의 사용자 스마트 지갑 주소와 Arbitrum의 스마트 지갑 주소가 전혀 통합될 수 없습니다.

또한 다중 체인 환경에서 사용자는 서로 다른 체인에 스마트 계정을 독립적으로 배포했으며 해당 사용자 데이터는 종종 이러한 계약에 분산되어 저장됩니다. 키와 같은 사용자 데이터를 업데이트해야 하는 경우 여러 체인에서 트랜잭션을 반복적으로 시작해야 하므로 스마트 어카운트의 일관성을 보장하기 어렵습니다.

Vitalik 자신은 이전에 전체 체인에 대해 통합되고 관리하기 쉬운 스마트 계정 솔루션을 제안한 적이 있습니다. 이 솔루션은 Ethereum 또는 매우 안전한 ZKRolllup을 소스 체인으로 사용하고 Keystore 계약을 배포하고 사용자의 글로벌 키를 저장한 다음 사용자가 L2의 모든 스마트 계약 계정은 키 저장소 계약에 저장된 글로벌 키를 공유합니다.

(이미지 출처 : https://vitalik.ca/general/2023/06/20/deeperdive.html)

그러나 이 솔루션은 비용이 매우 많이 듭니다. 즉, 소스 체인의 키 저장소 계약에 의해 기록된 글로벌 키가 변경될 때마다 L2/대상 체인의 각 계정은 크로스 체인 상호 작용을 통해 새 키를 동기화해야 합니다. 이더리움과 L2 간의 크로스체인 상호작용 비용은 너무 높으며 사용자는 이를 감당할 수 없습니다. 또한 스마트 컨트랙트 계정은 EOA 계정과 다르다는 점에 유의해야 합니다. 후자는 고유한 주소 생성 방식으로 인해 본질적으로 멀티체인 통합(EVM 체인 간 통합)이지만 스마트 컨트랙트 계정은 완전히 다르며 사용자가 어렵습니다. 다른 체인에서 동일한 주소를 가진 스마트 계약 계정을 얻습니다.

이와 관련하여 Particle Network는 자체적인 접근 방식을 제안했습니다. 일반적인 아이디어는 스마트 계정의 저장소와 코드를 분리하려는 Vitalik의 아이디어와 일치하지만 Particle Network는 제3자를 통해 독립적인 체인인 Particle Network Chain을 스마트 계정의 전체 체인 저장소 데이터베이스로 사용할 계획입니다. 크로스체인 메시징 솔루션(LayerZero, CCIP, Axelar, Connext 등) 계정 저장소에 대한 사용자의 변경 사항을 다른 체인의 로컬 계정과 동기화합니다.

(Particle Network의 멀티체인 계정 추상 구조)

특히, Particle Network의 전체 체인 계정 추상화 시스템을 통해 사용자는 다양한 EVM 체인에서 통합된 스마트 계약 계정 주소를 가질 수 있으며, 이를 위해서는 다양한 체인에 배포자 계약 세트를 배포해야 합니다.

사용자는 입자 네트워크 체인에서 새 계정 생성을 트리거해야 하며 입자 체인은 모든 체인에서 배포자 계약을 트리거하여 다른 체인의 사용자를 위해 생성된 스마트 계약 계정 주소가 통합되도록 하거나 사용자가 다음을 수행할 수 있도록 합니다. 다른 체인에서 새로운 계정 생성을 촉발합니다.인식의 경우 파티클 체인의 계약을 통해 다중 체인 상호 작용 프로세스가 완료되며 Unified Gas Token을 통합 수수료 지불 방법으로 사용할 수 있습니다.

풀체인 계정 추상화는 Cross-Chain의 사용자 작업도 가능하게 하며, 소스 체인의 사용자 작업과 해당 결제용 가스를 통해 대상 체인의 트랜잭션을 촉발할 수 있습니다.예를 들어 Polygon의 USDC를 사용하여 구매가 가능합니다. 베이스 기반 NFT.

그러나 Particle Network의 솔루션은 다중 체인 계정과 소스 체인 저장소의 동기화를 달성하기 위해 배포자 계약과 크로스 체인 메시징 구성 요소 간의 높은 수준의 협업이 필요합니다. 이로 인해 실제로 사용되는 오라클 또는 크로스 체인 메시지 브리지에 더 높은 요구 사항이 적용됩니다. (이 문제는 풀체인 상호운용성과 관련된 모든 솔루션에 존재하는 것으로 보입니다).

그러나 사용자의 크로스체인 계정 동기화는 특정 브리지에만 의존하는 대신 다양한 메시지 브리지 조합을 유연하게 구성할 수 있습니다. 예를 들어 LayerZero 중 두 개의 확인에 의존하는 2/3 전략으로 구성할 수 있습니다. , Axelar 및 Connext가 대상 체인에 있어야 합니다. Storage 변경을 확인하면 이 단일 지점 종속성 문제를 대략적으로 해결할 수 있습니다.

EVM과 비EVM 간의 원활한 전체 체인 상호 운용성은 이더리움 생태계 내에서 전체 체인 계정 추상화를 향한 추가 단계입니다.

EVM 체인 전체에 키 관리 및 통합 계정이 있지만 전체 체인 계정 추상화에는 여전히 최적화의 여지가 있습니다. Aptos, Solana, Sui 등과 같이 EVM과 호환되지 않는 체인은 다음을 보장할 수 없습니다. 사용자 생성 스마트 계약 계정 주소는 체인의 EVM 일관성과 일치하며, 동시에 비 EVM 체인이 동등한 솔루션으로 EIP-4337 프로토콜을 구현하지 않으면 완전한 개념을 따르기가 어려울 것입니다. - 이전 기사에서 Vitalik과 Particle Network가 제안한 체인 계정 추상화.

또한, EIP-4337 호환 지갑 프로젝트 자체에도 개선의 여지가 있습니다. 대부분의 스마트 지갑에서 사용하는 Bundler 노드는 공식적으로는 독립적으로 실행되며 서로 통신도 하지 않습니다. 실제로 많은 스마트 지갑 프로젝트가 자체 체인을 형성하므로 많은 위험(검열 저항, 가용성)이 발생합니다. 대부분의 체인에 걸쳐 통합된 단일 프런트 엔드 인터페이스를 구축하는 것은 매우 어렵습니다. 한 가지 해결책은 의도 중심 설계를 도입하고, 전체 체인 계정 추상화 위에 레이어를 추가하고, 이더리움의 EIP-4337 생태계 또는 다른 체인의 기본 계정 추상화 기능(예: zkSync)을 Reactor 유형의 솔버/특정 인스턴스로 처리하는 것입니다. , 적절한 솔버를 선택하는 방법은 더 높은 수준의 작업입니다.

Particle Network를 예로 들면 간결하고 추상적인 Intent-Centric 구현 솔루션 세트를 제안하며, 다양한 계정 추상화 프로젝트는 Intent 솔루션의 Solver 카테고리에 포함된 인스턴스 유형일 뿐입니다.

우선, 사용자 프런트 엔드는 자연어 요청 또는 임의의 사용자 상호 작용을 입력 제약 조건 및 출력 제약 조건(직접 말하면 사용자 요구 사항을 충족하는 입력 조건 및 출력 결과 범위)을 포함하는 특정 프로그래밍 방식 설명으로 변환하는 일을 담당합니다. ) 그러면 솔버 네트워크의 하나 또는 일부 솔버는 특정 입력 및 출력 제약 조건이 포함된 트랜잭션을 체인에 배포된 솔버 계약에 전달합니다(솔버에는 노드 기능뿐만 아니라 온체인 계약 부분도 있음). Solver 계약은 Intent 명령을 Reactor 계약(체인에서 사용자 계정을 관리함)으로 보내고 후자는 다른 모듈을 호출하여 최종 상호 작용을 완료합니다.

사용자의 요청은 Solver 네트워크에 의해 먼저 알려지기 때문에 사용자는 기본 체인이나 다양한 계정 추상화 솔루션 구성에 대해 너무 많이 알 필요가 없으며 이 부분은 특정 솔루션을 구성하기 위해 Solver에 맡길 수 있습니다.

물론 이러한 아이디어는 현재 이론적 프레임워크일 뿐이며 후속 구현 세부 사항은 아직 Particle Network에서 공식적으로 제시되지 않았습니다.

현재 상대적으로 분명한 것은 미래에는 경쟁적인 해결자 시장이 확실히 등장할 것이며 사용자는 경매를 시작하고 여러 해결자가 서로 다른 솔루션을 제시하도록 할 수 있으며 로컬 시뮬레이션 거래를 통해 최상의 솔루션을 선택할 수 있다는 것입니다. 해당 해결사. 인센티브의 형태는 Solver 네트워크의 프로토콜 설계자의 고려 사항에 따라 다릅니다(Particle Network는 Solver 경매 시장의 인센티브 토큰으로 PNT 토큰을 사용할 계획입니다).

현재 인텐트는 본질적으로 하위 계층의 복잡한 세부 사항을 보호하고 상위 계층을 추상화합니다. TCP/IP 프로토콜의 특성을 지닌 이러한 계층 설계는 전체 체인에 걸친 원활한 상호 운용성 하에서 사용자 경험과 개발에 필수적입니다. 경험이 필요합니다. 상태.

계정 추상화의 대량 채택 준비

우리는 이더리움 생태계의 4337 프레임워크를 모든 각도에서 최적화한 후 전체 이더리움 및 비이더리움 생태계에 걸쳐 원활한 상호 운용성을 촉진했습니다. 계정 추상화의 대규모 채택을 지원하려면 여전히 제품이 필요하다고 생각합니다. 공급측면과 수요측면을 포괄하는 것입니다. 최종 사용자가 다양한 Web3 제품 및 서비스를 사용해야 하는 필요성을 줄이는 동시에 개발자 서비스에 집중하고 개발자의 문턱을 낮출 수도 있습니다.

이 역할을 수행할 수 있는 최고의 제품 중 하나는 Particle Network의 모듈식 계정 추상화 서비스형 지갑(Modular Smart Wallet-as-Service) 제품입니다.

(Particle Network의 서비스형 스마트 지갑 아키텍처)

위의 개발자 친화적인 기능 외에도 가장 중요한 기능은 서명 계산을 기반으로 개발자 중심의 계정 추상화 필드를 구축하는 Particle Network의 Modular Smart Wallet-as-as-Service 제품입니다. 자체 개발한 계정 추상화 제품 모듈은 다양한 유형의 계정 추상화 제품 및 서비스를 통합하여 전체 계정 추상화 분야에서 개발자의 제품 및 서비스 채택을 신속하게 촉진할 수 있습니다.

(Particle Network의 Smart Wallet-as-a-Service의 모듈형 설계)

기술이 필요를 충족시키도록 하세요. ERC-4337 프레임워크의 한계를 모든 각도에서 해결한 후, 개발자 경험의 향상은 뛰어난 사용자 경험을 갖춘 더 많은 제품의 생산을 촉진하고 Web3 산업을 사이퍼펑크 친화적인 금융 산업에서 변화를 가속화할 것입니다. 대중 친화적인 소비자급 산업을 지향합니다.