이 기사는 SevenX 연구팀이 작성한 원본이며 커뮤니케이션 및 학습 목적으로만 작성되었으며 투자 참고 자료가 아닙니다. 인용이 필요하신 경우 출처를 표기해주세요.
원본 영문 보고서는 2023년 9월 SevenX의 Mirror 플랫폼에 게재되었습니다.더 많은 중국 투자 리서치 콘텐츠를 보시려면 공개 계정 [SevenXVentures]를 팔로우해주세요.
Safe의 공동 창립자인 Lukas, Alchemy의 엔지니어링 책임자인 Noam, rhinestone의 공동 창립자인 Kurt 및 Konrad, 그리고 HashKey Capital의 투자자 Arnav에게 감사드립니다.
편집자 주: SCA(스마트 계약 계정)는 강력하게 발전하고 있으며 Vitalik을 비롯한 많은 핵심 기업가의 지원을 받고 있지만 SCA 채택은 여전히 많은 어려움에 직면해 있습니다. AA(계정 추상화)는 코드를 사용하여 기능을 사용자 정의할 수 있다는 장점이 있지만 상호 운용성이 없기 때문에 통합 및 공급업체 잠금 문제가 발생합니다. 모듈식 계정 추상화는 다양한 기능, 보안 및 원활한 통합을 갖춘 지갑 개발을 위한 모듈식 구조를 만드는 것을 목표로 합니다.
SevenX Ventures 투자자인 Rui는 SCA 채택에 직면한 5가지 주요 과제, 즉 약세 시장 영향, 마이그레이션 어려움, 서명 문제, 높은 가스 비용 및 엔지니어링 어려움을 지적하고 엔지니어링 문제에 대해 추가로 논의했습니다. 또한, 모듈식 스마트 계약 계정의 아키텍처 분석은 모듈식 SCA가 채택 퍼즐의 작은 조각일 뿐이라는 점을 지적합니다.
SCA의 잠재력을 완전히 실현하려면 추가 프로토콜 계층 지원, 강력한 번들러 인프라 및 P2P 메모리 풀, 보다 비용 효율적이고 실현 가능한 SCA 서명 메커니즘, 크로스체인 SCA 동기화 및 기능을 제공하는 레이어 2 솔루션이 필요합니다. 관리 메커니즘 및 개발 사용자 친화적인 인터페이스 등.
앞으로는 현재의 과제가 점차 해결되고 더 많은 사람들이 SCA를 채택하게 된다면 그 다음에는 어떤 일이 일어날까요? Rui는 이에 대해 몇 가지 흥미로운 질문도 제기했습니다. BlockBeats는 다음과 같이 원본 텍스트를 컴파일합니다.
외부 소유 계정(EOA)에서 스마트 계약 계정(SCA)으로의 전환이 추진력을 얻고 있으며 Vitalik을 포함한 많은 핵심 기업가로부터 지원을 받았습니다. 그럼에도 불구하고 SCA 채택은 EOA만큼 널리 보급되지 않았습니다. 주요 문제로는 하락장 영향, eoa에서 sca로 마이그레이션의 어려움, 서명 문제, 높은 가스 비용, 가장 중요한 개발 문제 등이 있습니다.
AA(계정 추상화)의 가장 중요한 장점은 코드를 사용하여 기능을 사용자 정의할 수 있다는 것입니다. 그러나 AA 기능의 비상호운용성은 큰 문제를 야기하며, 이러한 단편화는 AA 통합을 방해하고 공급업체 종속을 강화할 수 있습니다. 또한 업그레이드 및 구성이 가능하면서도 보안을 보장하는 것도 중요한 과제입니다.
AA 개발 추세 중 하나의 틈새 영역은 스마트 계정을 사용자 정의 기능과 분리하는 혁신적인 접근 방식인 모듈식 계정 추상화의 출현입니다. 목표는 다양한 기능, 보안 및 원활한 통합을 갖춘 지갑을 개발하기 위한 모듈식 구조를 만드는 것입니다. 미래에는 모듈식 계정 추상화를 통해 무료 스마트 계약 계정 앱 스토어를 구현할 수 있어 지갑과 dApp이 기능 구축에 너무 많은 에너지를 소비하지 않고도 사용자 경험을 개선하는 데 집중할 수 있습니다.
계정 추상화(AA)에 대한 간략한 소개
사람들이 블록체인을 접하는 과정에서 전통적인 EOA는 니모닉 단어, 가스 요금, 크로스체인 운영 및 다중 거래와 같은 많은 문제를 가져왔습니다.
계정 추상화는 스마트 계약 계정을 활용하여 프로그래밍 가능한 검증 및 실행을 허용합니다. 이는 사용자가 각 거래에 서명하고 브로드캐스트할 필요 없이 일련의 거래를 한 번에 승인할 수 있음을 의미합니다. 계정 추상화는 사용자 경험 개선(가스 추상화 및 세션 키 등), 비용 절감(일괄 거래 등), 보안 강화(사회 복구, 다중 서명 등)와 같은 더 많은 기능을 달성할 수도 있습니다. 현재 계정 추상화를 구현하는 방법에는 두 가지가 있습니다.
프로토콜 계층: 일부 프로토콜 자체는 기본 계정 추상화 지원을 제공합니다. ZKSync 트랜잭션은 단일 메모리 풀과 트랜잭션 프로세스를 사용하여 AA를 지원합니다. EOA이든 SCA이든 동일한 프로세스를 따르며 Starknet은 EOA를 제거했으며 모든 계정은 SCA입니다. , Argent와 같은 기본 스마트 계약 지갑이 있습니다.
계약 계층: Ethereum 및 유사한 L2의 경우 ERC 4337은 합의 계층을 변경하지 않고 AA를 지원하기 위해 별도의 멤풀을 도입합니다. Stackup, Alchemy, Etherspot, Biconomy, Candide 및 Plimico와 같은 회사는 번들러 인프라를 구축하고 있으며 Safe, Zerodev, Etherspot 및 Biconomy와 같은 회사는 번들러 및 SDK를 구축하고 있습니다.
SCA 도입 시 딜레마
AA(Account Abstraction) 주제는 2015년부터 논의되어 왔으며 올해 ERC 4337에 의해 더욱 주목을 받았습니다. 그러나 배포된 스마트 계약 계정 수는 여전히 EOA에 비해 훨씬 적습니다.
이 딜레마에 대해 더 자세히 살펴보겠습니다.
1. 약세장의 영향
AA는 원활한 로그인 및 가스 추상화 등의 장점을 가지고 있지만 현재 약세장에서는 모든 사용자가 교육받은 EOA 사용자이고 신규 사용자가 많지 않기 때문에 dApp과 지갑은 SCA를 채택할 인센티브가 없습니다. 그럼에도 불구하고 일부 주요 dApp은 AA 시스템과 가스 프리 솔루션을 도입하여 단 한 달 만에 약 360,000개의 UserOps(AA 트랜잭션)를 유도한 Cyberconnect와 같은 AA를 점차적으로 채택하고 있습니다.
2. 이주 장벽
사용자와 자산이 축적된 지갑과 애플리케이션의 경우 안전하고 편리하게 자산을 이전하는 것은 여전히 어려운 과제로 남아 있습니다. 그러나 EIP-7377과 같은 체계를 사용하면 EOA가 일회성 마이그레이션 트랜잭션을 시작할 수 있습니다.
3. 서명 문제
스마트 계약 자체에는 EOA와 같은 개인 키가 없기 때문에 메시지에 서명할 수 없습니다. ERC 1271과 같은 시도가 이를 가능하게 하지만 첫 번째 트랜잭션 전에는 메시지 서명이 작동하지 않으므로 반사실 배포를 사용하는 지갑에 다시 문제가 발생합니다. Ambire가 제안한 ERC-6492는 ERC-1271의 이전 버전과 호환되는 후속 버전이며 이전 문제를 해결할 수 있습니다.
4. 가스비
채택 장벽 중 하나는 표준 EOA에 비해 SCA를 배포, 시뮬레이션 및 실행하는 데 드는 비용이 더 높다는 것입니다. 그러나 계정 생성과 사용자 작업을 분리하고"salt"기다리다.
5. 엔지니어링 문제
ERC-4337 팀은 개발자에게 기본 구현을 제공하기 위해 eth-infinitism 저장소를 구축했습니다. 그러나 개발자가 다양한 사용 사례에 대해 더욱 미묘하고 구체적인 기능을 확장함에 따라 통합 및 디코딩은 더 많은 과제에 직면하게 됩니다. 이 글에서는 엔지니어링 과제에 대해 자세히 살펴보겠습니다.
모듈식 스마트 계약 계정으로 엔지니어링 문제 해결
엔지니어링 과제는 조각화, 보안 및 확장성의 세 가지 측면으로 더 자세히 설명할 수 있습니다.
분열
이제 특정 SCA를 통해서든 독립형 플러그인 시스템을 통해서든 다양한 방법으로 기능을 활성화할 수 있습니다. 각 플랫폼과 서비스 제공업체는 자체 표준을 따르므로 개발자는 지원할 플랫폼과 서비스 제공업체를 결정해야 합니다. 이는 잠재적인 플랫폼(공급업체) 잠금 또는 중복 작업으로 이어질 수 있습니다.
안전
계정과 기능을 분리하면 유연성이 향상되지만 보안 문제가 더욱 악화될 수도 있습니다. 모든 기능을 함께 검토할 수 있으므로 독립적인 평가가 없으면 계정 취약점의 위험이 높아질 수 있습니다.
업그레이드 가능성
계정이 성장함에 따라 기능을 추가, 교체 또는 제거하는 능력을 유지하는 것이 중요하며, 기존 기능을 재배포하는 각 업데이트는 복잡성을 야기합니다.
이러한 문제를 해결하려면 안전하고 효율적인 업그레이드를 보장하기 위한 업그레이드 가능한 계약, 전반적인 개발 효율성을 향상시키기 위한 재사용 가능한 코어, 계약 계정이 서로 다른 프런트 엔드 간에 원활하게 전환될 수 있도록 보장하는 표준화된 인터페이스가 필요합니다.
이러한 용어는 모듈식 계정 추상화 아키텍처(모듈식 AA) 구축이라는 공통 개념으로 수렴됩니다.
모듈식 계정 추상화는 스마트 계정을 모듈화하여 사용자에게 서비스를 맞춤화하고 개발자가 최소한의 제한으로 기능을 원활하게 향상시킬 수 있도록 하는 광범위한 AA 개발의 세분입니다.
그러나 어떤 산업에서든 새로운 표준을 확립하고 홍보하는 것은 큰 도전입니다. 모두가 동일한 표준을 받아들일 때까지 초기 단계에서는 다양한 솔루션이 등장할 가능성이 높습니다. 4337 SDK, 지갑, 인프라 팀, 프로토콜 계층 설계자 등 계정 추상화를 개선하고 홍보하는 사람들이 이 프로세스 속도를 높이기 위해 협력하는 모습은 고무적입니다.
모듈형 구조: 마스터 계정 및 모듈
계정이 기능을 구현하기 위해 모듈을 호출하는 방법
통화 및 대리 계약 위임
외부 통화 및 대리인 통화:
대리인 통화 정보
위임 호출은 호출과 유사하지만 대상 계약의 컨텍스트에서 실행되지 않고 호출 계약의 현재 상태의 컨텍스트에서 실행됩니다. 이는 대상 계약에 의해 발생한 모든 상태 변경으로 인해 호출 계약의 저장 공간이 변경된다는 의미입니다.
대리 계약 및 대리인 호출
구성 가능하고 업그레이드 가능한 구조를 달성하려면 에이전시 계약이라는 기본 개념을 도입해야 합니다.
에이전트 계약: 일반 계약은 논리와 상태를 저장하며 배포 후에는 업데이트할 수 없습니다. 프록시 계약은 대리인 호출을 사용하여 다른 계약에 배포합니다. 참조로 함수를 구현하고 에이전트 계약의 현재 상태에서 실행합니다.
사용 사례: 프록시 계약은 동일하게 유지되지만 프록시 뒤에 새로운 구현을 배포할 수 있습니다. 프록시 계약은 업그레이드를 가능하게 하며 퍼블릭 블록체인에 배포하고 유지하는 비용이 더 저렴합니다.
안전한 아키텍처
안전한 아키텍처
안전이란 무엇입니까?
Safe는 검증된 보안과 유연성을 제공하도록 설계된 선도적인 모듈형 스마트 계정 인프라로, 개발자가 다양한 애플리케이션과 지갑을 만들 수 있도록 지원합니다. 많은 팀이 Safe를 기반으로(또는 영감을 받아) 애플리케이션을 구축하고 있습니다. 예를 들어 Biconomy는 스마트 계약 계정을 출시했을 때 기본 4337 및 1/1 다중 서명을 사용하여 Safe를 확장했습니다. 164,000개 이상의 계약이 배포되고 307억 달러 이상의 가치가 고정되어 있는 Safe는 의심할 여지 없이 해당 분야의 선두주자입니다.
Safe의 구조에는 보안 계정 계약, 싱글톤 계약, 모듈 계약이 포함됩니다.
보안계좌계약(프록시계약) : 주체계약(Stateful)
위임 호출은 싱글톤 계약이므로 보안 계정은 프록시 계약입니다. 보안 계정에는 에이전트에 모두 설정된 소유자, 임계값, 구현 주소에 대한 변수가 포함되어 있으며 이를 기반으로 상태가 정의됩니다.
싱글톤 계약: 통합 허브(상태 비저장)
싱글톤 계약은 Safe 계정을 제공하고 플러그인, 후크, 함수 핸들러 및 서명 유효성 검사기를 포함한 다양한 모듈 계약 통합을 정의합니다.
모듈 계약(모듈): 사용자 정의 논리 및 기능
모듈 계약은 강력합니다. 모듈형 플러그인은 결제 흐름, 복구 메커니즘, 세션 키 등 다양한 기능을 정의할 수 있으며, 오프체인 데이터를 획득하여 Web2와 Web3 사이의 브리지 역할을 할 수 있습니다. 보안 가드 역할을 하는 Hook 및 Function Handler와 같은 다른 모듈은 모든 명령에 응답할 수 있습니다.
Safe 도입으로 인한 변화:
업그레이드 가능한 계약: 새로운 플러그인이 도입될 때마다 새로운 싱글톤을 배포해야 합니다. 사용자는 Safe를 원하는 싱글톤 버전으로 업그레이드할 수 있는 자율성을 유지합니다.
구성 가능하고 재사용 가능한 모듈: 플러그인의 모듈식 특성을 통해 개발자는 독립적으로 기능을 개발할 수 있습니다. 사용 사례에 따라 이러한 플러그인을 자유롭게 선택하고 결합할 수 있으므로 고도로 사용자 정의 가능한 접근 방식이 가능합니다.
ERC-2535 다이아몬드 에이전트
ERC 2535, 다이아몬드 에이전트 정보:
ERC 2535 표준화된 다이아몬드 모델은 크기 제한이 거의 없이 배포 후 업그레이드/확장할 수 있는 모듈형 스마트 계약 시스템입니다. 현재 Zerodev의 Kernel, Soul Wallet 등 많은 팀의 실험은 Diamond 구조에서 영감을 받았습니다.
다이아몬드 구조는 무엇입니까:
다이아몬드 계약: 기본 프록시 계약(상태 저장) 다이아몬드는 위임 호출 방법을 사용하여 구현에서 함수를 호출하는 프록시 계약입니다.
모듈/플러그인/Facet 계약: 사용자 정의 논리 및 기능(상태 비저장) 모듈 또는 소위 Facet은 해당 기능을 하나 이상의 다이아몬드에 배포할 수 있는 상태 비저장 계약입니다. 이는 내부 기능, 라이브러리 및 상태 변수를 공유할 수 있는 별도의 독립적인 계약입니다.
Diamond 도입으로 인한 변화:
업그레이드 가능한 계약: Diamond는 서로 다른 플러그인을 분리하여 함께 연결하고, 플러그인 간에 데이터를 공유하고, DiamondCut 기능을 사용하여 플러그인을 직접 추가/교체/제거할 수 있는 체계적인 방법을 제공합니다. 시간이 지남에 따라 Diamond에 추가할 수 있는 플러그인 수에는 제한이 없습니다.
모듈식 및 재사용 가능한 플러그인: 배포된 플러그인은 원하는 수의 다이아몬드에서 사용할 수 있으므로 배포 비용이 크게 절감됩니다.
안전한 스마트 계정과 다이아몬드 방식의 차이점:
Safe와 Diamond 아키텍처 사이에는 많은 유사점이 있습니다. 둘 다 핵심에서 프록시 계약에 의존하고 업그레이드 가능성과 모듈성을 위해 논리 계약을 참조합니다.
둘 사이의 주요 차이점은 논리적 계약을 처리하는 것입니다. 구체적으로:
유연성: 새로운 플러그인이 활성화되면 Safe는 프록시에 변경 사항을 구현하기 위해 싱글톤 계약을 재배포해야 합니다. 대조적으로, Diamond는 프록시 계약의 DiamondCut 기능을 통해 이를 직접 수행합니다. 이러한 접근 방식의 차이는 Safe가 더 높은 수준의 제어를 유지하는 반면 Diamond는 향상된 유연성과 모듈성을 도입한다는 것을 의미합니다.
보안: 현재 외부 코드가 주 계약의 저장소를 조작할 수 있도록 허용하는 두 가지 구조에서 사용됩니다. Safe 아키텍처에서 위임 호출은 단일 논리적 계약을 가리키는 반면 Diamond는 여러 모듈 계약 플러그인에서 위임 호출을 사용합니다. 따라서 악성 플러그인이 다른 플러그인을 덮어쓰게 되면 저장소 충돌 위험이 발생하고 에이전트 무결성이 손상될 수 있습니다.
비용: 다이아몬드 접근 방식을 사용하면 유연성에는 안전 문제가 수반됩니다. 이로 인해 비용이 추가되고 새 플러그인이 추가될 때마다 전체 검토가 필요합니다. 핵심은 이러한 플러그인이 서로의 기능을 방해하지 않도록 하는 것입니다. 이는 특히 높은 보안 표준을 유지하려고 노력하는 중소기업의 경우 어려운 작업입니다.
세이프 스마트 어카운트 방식과 다이아몬드 방식은 에이전트와 모듈이 관련된 다양한 구조의 예입니다. 유연성과 보안의 균형을 맞추는 방법은 매우 중요하며, 이 두 가지 접근 방식은 앞으로도 지속적으로 발전하고 서로를 보완할 것입니다.
모듈 순서: 유효성 검사기, 실행기 및 후크
Alchemy 팀이 제안하고 Diamond에서 영감을 얻어 ERC-4337에 맞게 특별히 맞춤화된 표준인 ERC-6900을 소개하면서 논의를 더 진행해 보겠습니다. 공통 인터페이스를 제공하고 플러그인과 지갑 개발자 간의 작업을 조정하여 스마트 계정 모듈화 문제를 해결합니다.
AA의 거래 프로세스는 크게 검증, 실행, 후킹 3가지 프로세스로 구성됩니다. 앞서 논의한 것처럼 이러한 단계는 모두 프록시 계정을 사용하여 모듈을 호출하여 관리할 수 있습니다. 프로젝트마다 다른 이름을 사용할 수 있지만 유사한 기본 논리를 파악하는 것이 중요합니다.
다양한 디자인의 기능 이름
검증인: 계정 호출자의 신뢰성과 권한을 확인합니다.
실행자: 계정에서 허용하는 모든 사용자 지정 논리를 실행합니다.
Hook: 다른 기능 전후에 실행되는 모듈 역할을 합니다. 상태를 수정하거나 전체 호출을 취소할 수 있습니다.
ERC 6900
서로 다른 로직을 기반으로 모듈을 분리하는 것이 중요합니다. 표준화된 접근 방식은 스마트 계약 계정에 대한 검증, 실행 및 후킹 기능을 작성하는 방법을 규정해야 합니다. 안전하든 ERC-6900이든 표준화는 특정 구현이나 생태계와 관련된 고유한 개발 노력의 필요성을 줄이고 공급업체 종속을 방지하는 데 도움이 됩니다.
모듈 검색 및 보안
공개 방식으로 모듈을 찾고 검증하는 방법: 발전 중인 솔루션 중 하나는 사용자가 검증 가능한 모듈을 발견할 수 있는 영역을 생성하는 것입니다. 이를 레지스트리라고 합니다. 레지스트리는 앱 스토어와 같은 기능을 하며 단순하지만 번창하는 모듈식 시장을 육성하도록 설계되었습니다.
안전한{핵심} 프로토콜
Safe{Core} 프로토콜은 명확하게 정의된 표준 및 규칙을 통해 강력한 보안을 유지하면서 다양한 공급업체 및 개발자의 접근성을 향상시키도록 설계된 스마트 계약 계정을 위한 오픈 소스 상호 운용 가능한 프로토콜입니다.
계정: Safe{Core} 프로토콜에서 계정 개념은 유연하며 특정 구현에 얽매이지 않습니다. 이를 통해 다양한 계정 서비스 제공업체가 참여할 수 있습니다.
관리자: 관리자는 계정, 레지스트리 및 모듈 간의 조정자 역할을 합니다. 또한 보안을 담당하는 권한 계층 역할도 합니다.
등록 센터: 등록 센터는 보안 속성을 정의하고 ERC 6900과 같은 모듈 표준을 구현하여 검색 가능성과 보안을 달성하기 위한 개방형 애플리케이션 스토어 환경을 만드는 것을 목표로 합니다.
모듈: 모듈은 기능을 처리하며 플러그인, 후크, 서명 유효성 검사기 및 함수 핸들러를 포함한 다양한 초기 유형을 갖습니다. 개발자는 확립된 표준을 충족하는 한 참여할 수 있습니다.
라인스톤 디자인
프로세스는 다음과 같이 전개됩니다.
스키마 정의(스키마) 만들기: 스키마는 미리 정의된 데이터 구조를 제공합니다. 사람들은 특정 사용 사례에 맞게 이를 사용자 정의할 수 있습니다.
아키텍처를 기반으로 모듈 생성: 모듈로 등록된 스마트 계약은 바이트코드를 가져오고 아키텍처 ID를 선택하며 데이터는 레지스트리에 저장됩니다.
모듈 증명 획득: 인증자/감사자는 아키텍처를 기반으로 모듈에 대한 증명을 제공할 수 있습니다. 이러한 인증서에는 고유 식별자(UID)와 연결에 사용되는 다른 인증서에 대한 참조가 포함될 수 있습니다. 이는 체인 전체에 전파되어 대상 체인이 특정 임계값을 충족하는지 확인할 수 있습니다.
리졸버를 사용하여 복잡한 로직 구현: 리졸버(선택적 설정)가 작동합니다. 모듈 생성, 증명 설정 및 해체 중에 호출할 수 있습니다. 이러한 파서를 통해 개발자는 증명 구조를 유지하면서 복잡하고 다양한 논리를 통합할 수 있습니다.
사용자 친화적인 쿼리 액세스(query): 쿼리는 사용자에게 프런트 엔드에서 보안 정보에 액세스할 수 있는 방법을 제공합니다.
이 모델은 아직 초기 단계에 있지만 분산되고 협력적인 방식으로 표준을 확립할 수 있는 잠재력을 가지고 있습니다. 레지스트리를 통해 개발자는 모듈을 등록하고 감사자는 보안을 확인하고 지갑은 통합할 수 있으며 사용자는 쉽게 모듈을 찾고 증명 정보를 확인할 수 있습니다. 향후 몇 가지 용도는 다음과 같습니다.
입증인: Safe와 같은 신뢰할 수 있는 실체는 라인스톤과 협력하여 내부 모듈에 대한 입증인 역할을 할 수 있습니다. 동시에 독립 인증자도 참여할 수 있습니다.
모듈 개발자: 공개 시장이 형성되면서 모듈 개발자는 레지스트리를 통해 자신의 작업으로 수익을 창출할 수 있습니다.
사용자: 사용자가 모듈 정보를 검사하고 다른 증명자에게 신뢰를 위임할 수 있는 지갑이나 dApp과 같은 사용자 친화적인 인터페이스를 통해 참여합니다.
모듈 레지스트리 개념은 플러그인 및 모듈 개발자에게 수익성 있는 길을 열어줍니다. 이는 모듈 시장을 위한 길을 더욱 열어줄 수 있습니다. 일부 측면은 Safe 팀에 의해 감독될 수 있지만 다른 측면은 분산된 시장으로 나타나 모든 사람이 기여하도록 초대하고 투명한 감사 추적을 제공할 수 있습니다. 이를 통합하면 벤더 종속을 방지하고 더 많은 청중에게 어필할 수 있는 향상된 사용자 경험을 추가하여 EVM 확장을 지원합니다.
이러한 방법은 개별 모듈을 보호하지만, 스마트 계약 계정은 더 넓은 보안 측면에서 완벽하지는 않습니다. 규정 준수 모듈과 통합하고 스토리지 충돌이 없음을 증명하는 것은 어려울 수 있으며, 이는 이러한 문제를 해결하는 데 지갑이나 AA 인프라의 중요성을 강조합니다.
요약하다
모듈식 스마트 계약 계정 스택을 활용함으로써 지갑 제공업체와 dApp은 기술 유지 관리의 복잡성에서 벗어날 수 있습니다. 동시에 외부 모듈 개발자는 개인화된 전문 서비스를 제공할 수 있는 기회를 갖습니다. 그러나 해결해야 할 과제에는 유연성과 보안 간의 균형 유지, 모듈식 표준 추진, 사용자가 스마트 계정을 쉽게 업그레이드하고 수정할 수 있도록 하는 표준화된 인터페이스 구현 등이 포함됩니다.
게다가 모듈식 스마트 계약 계정(SCA)은 채택 퍼즐의 작은 부분일 뿐입니다. SCA의 잠재력을 완전히 실현하려면 강력한 번들러 인프라 및 P2P 메모리 풀, 보다 비용 효율적이고 실행 가능한 SCA 서명 메커니즘, 크로스체인 SCA와 같은 추가 프로토콜 계층 지원을 제공하는 레이어 2 솔루션이 필요합니다. 동기화 및 관리 메커니즘, 사용자 친화적인 인터페이스 개발.
앞으로는 SCA 채택이 더 많아지겠지만 몇 가지 흥미로운 질문도 제기됩니다. SCA 주문 흐름이 충분히 수익성이 있게 되면 기존 MEV(채굴자 추출 가능 가치) 메커니즘이 번들러를 구축하기 위해 어떻게 공간에 들어가 가치를 얻을 수 있을까요? 인프라가 성숙되면 AA(계정 추상화)가 어떻게 의도 기반 트랜잭션의 기본 계층 역할을 할 수 있습니까? 기다려 보자.
