SevenX Ventures: 모듈화된 스마트 계약 계좌 구조와 도전 과제

원문 제목：《모듈형 스마트 계약 계좌 아키텍처와 도전 과제》
원문 저자：Rui, SevenX Ventures 투자자
원문 편집：Luccy, Joyce, BlockBeats

편집자 주：

스마트 계약 계좌(SCA)의 발전세가 강력하며, Vitalik을 포함한 많은 핵심 창업자들의 지지를 받고 있습니다. 그러나 SCA의 채택은 여전히 많은 도전에 직면해 있습니다. 계좌 추상화(AA)의 장점은 코드를 사용하여 기능을 사용자 정의할 수 있다는 점이지만, 그 비호환성은 통합 및 공급업체 잠금 문제를 초래합니다. 모듈형 계좌 추상화는 다양한 기능을 갖춘 안전하고 원활하게 통합된 지갑을 개발하기 위해 모듈형 구조를 만드는 것을 목표로 합니다.

SevenX Ventures 투자자 Rui는 SCA 채택이 직면한 다섯 가지 도전 과제를 지적했습니다. 즉, 약세장 영향, 이전의 어려움, 서명 문제, 높은 가스 비용 및 엔지니어링 문제이며, 엔지니어링 문제에 대해 더 깊이 논의했습니다. 또한 모듈형 스마트 계약 계좌의 아키텍처를 분석한 후, 모듈형 SCA는 채택 문제의 일부분에 불과하다고 지적했습니다.

SCA의 잠재력을 충분히 발휘하기 위해서는 Layer 2 솔루션이 추가적인 프로토콜 레이어 지원, 강력한 번들러 인프라 및 P2P 메모리 풀, 더 비용 효율적이고 실행 가능한 SCA 서명 메커니즘, 크로스 체인 SCA 동기화 및 관리 메커니즘, 사용자 친화적인 인터페이스 개발 등을 제공해야 합니다.

미래에는 현재의 도전 과제가 점차 해결되어 더 많은 사람들이 SCA를 채택하게 될 것입니다. 그렇다면 다음에는 어떤 일이 일어날까요? Rui는 이에 대해 몇 가지 흥미로운 질문을 제기했습니다. BlockBeats는 원문을 다음과 같이 편집했습니다:

외부 소유 계좌(EOA)에서 스마트 계약 계좌(SCA)로의 전환이 강력하게 진행되고 있으며, Vitalik을 포함한 많은 핵심 창업자들의 지지를 받고 있습니다. 그럼에도 불구하고 SCA의 채택은 EOA만큼 광범위하지 않습니다. 이 주요 문제에는 약세장이 미치는 영향, EOA에서 SCA로의 이전 어려움, 서명 문제, 높은 가스 비용 및 가장 중요한 개발 문제 등이 포함됩니다.

계좌 추상화(AA)의 가장 두드러진 장점은 코드를 사용하여 기능을 사용자 정의할 수 있다는 점입니다. 그러나 AA 기능의 비호환성은 주요 도전 과제를 초래하며, 이러한 분산성은 AA 통합을 방해하고 공급업체 잠금을 강화합니다. 또한, 안전성을 보장하면서 업그레이드 가능성과 조합 가능성을 유지하는 것도 중요한 도전 과제입니다.

모듈형 계좌 추상화의 출현은 AA 발전 추세의 세분화된 분야로, 이러한 혁신적인 접근 방식은 스마트 계좌와 그 사용자 정의 기능을 분리할 수 있습니다. 목표는 다양한 기능을 갖춘 안전하고 원활하게 통합된 지갑을 개발하기 위한 모듈형 구조를 만드는 것입니다. 미래에는 모듈형 계좌 추상화가 자유로운 스마트 계약 계좌 "앱 스토어"를 실현하여 지갑과 dApp이 사용자 경험 개선에 집중할 수 있도록 하여 기능 구축에 너무 많은 에너지를 소모하지 않도록 할 수 있습니다.

계좌 추상화(AA) 개요

사람들이 블록체인에 접촉하는 과정에서 전통적인 EOA는 많은 도전 과제를 가져왔습니다. 예를 들어, 니모닉, 가스 비용, 크로스 체인 작업 및 다중 거래 등이 있습니다.

계좌 추상화는 스마트 계약 계좌를 활용하여 프로그래밍 가능한 검증(validation) 및 실행(execution)을 허용합니다. 이는 사용자가 일련의 거래를 한 번에 승인할 수 있게 하여 각 거래에 대해 서명하고 방송할 필요가 없음을 의미합니다. 계좌 추상화는 또한 사용자 경험 개선(예: 가스 추상화 및 세션 키), 비용 절감(예: 배치 거래) 및 보안 강화(예: 소셜 복구, 다중 서명)와 같은 더 많은 기능을 실현할 수 있습니다. 현재 계좌 추상화를 구현하는 두 가지 방법이 있습니다.

· 프로토콜 레이어: 일부 프로토콜 자체에서 로컬 계좌 추상화 지원을 제공합니다. ZKSync 거래는 단일 메모리 풀 및 거래 프로세스를 사용하여 AA를 지원합니다. EOA에서 SCA까지 동일한 프로세스를 따르며, Starknet는 EOA를 제거하고 모든 계좌를 SCA로 만들었으며, Argent와 같은 로컬 스마트 계약 지갑을 보유하고 있습니다.

· 계약 레이어: 이더리움 및 유사한 L2의 경우, ERC4337은 합의 레이어를 변경하지 않고 AA를 지원하기 위해 별도의 메모리 풀을 도입했습니다. Stackup, Alchemy, Etherspot, Biconomy, Candide 및 Plimico와 같은 팀이 번들러 인프라를 구축하고 있으며, Safe, Zerodev, Etherspot 및 Biconomy는 번들러 및 SDK를 구축하고 있습니다.

SCA 채택이 직면한 어려움

2015년 이후, 계좌 추상화(AA) 주제가 논의되어 왔으며, 올해 ERC 4337에 의해 더욱 주목받게 되었습니다. 그러나 배포된 스마트 계약 계좌의 수는 여전히 EOA에 비해 현저히 적습니다.

이 어려움을 깊이 연구해 보겠습니다:

1. 약세장의 영향

AA는 원활한 로그인 및 가스 추상화와 같은 장점을 가지고 있지만, 현재의 약세장에서 모든 사용자는 교육받은 EOA 사용자이며, 새로운 사용자는 많지 않기 때문에 dApp과 지갑은 SCA를 채택할 동기가 없습니다. 그럼에도 불구하고 일부 선도적인 dApp은 AA를 점진적으로 채택하고 있습니다. 예를 들어, Cyberconnect는 그들의 AA 시스템과 무가스 솔루션을 도입하여 단 한 달 만에 약 36만 건의 UserOps(AA 거래)를 촉진했습니다.

2. 이전 장애물

이미 사용자와 자산을 축적한 지갑과 애플리케이션의 경우, 자산을 안전하고 편리하게 이전하는 것은 여전히 도전 과제입니다. 그러나 EIP-7377과 같은 솔루션은 EOA가 일회성 이전 거래를 시작할 수 있도록 허용합니다.

3. 서명 문제

스마트 계약 자체는 EOA와 같은 개인 키가 없기 때문에 메시지를 서명할 수 없습니다. ERC1271과 같은 시도가 이를 가능하게 했지만, 메시지 서명은 첫 번째 거래 이전에는 작동하지 않으며, 이는 반사실적 배포를 사용하는 지갑에 도전 과제를 제기합니다. Ambire에서 제안한 ERC-6492는 ERC-1271과의 하위 호환성을 갖춘 후계자로, 이전 문제를 해결할 수 있을 것입니다.

4. 가스 비용

표준 EOA와 비교할 때, SCA의 배포, 시뮬레이션 및 실행은 더 높은 비용을 발생시키며, 이는 채택의 장애물 중 하나가 되었습니다. 그러나 현재 계좌 생성과 사용자 작업을 분리하고 특정 계좌와 관련된 "salt"를 제거하는 등의 테스트가 진행되고 있습니다.

5. 엔지니어링 문제

ERC-4337 팀은 개발자에게 기본 구현을 제공하기 위해 eth-infinitism repo를 구축했습니다. 그러나 개발자가 다양한 사용 사례에 맞춰 더 세부적이고 구체적인 기능으로 확장함에 따라 통합 및 디코딩은 더 많은 도전에 직면하게 됩니다. 본문에서는 엔지니어링 문제를 깊이 탐구할 것입니다.

모듈형 스마트 계약 계좌를 통한 엔지니어링 문제 해결

엔지니어링 문제는 분산화, 보안성 및 업그레이드 가능성의 세 가지 측면으로 더 구체화될 수 있습니다.

· 분산화: 현재 기능을 활성화하는 방법은 특정 SCA를 통해서든 독립적인 플러그인 시스템을 통해서든 여러 가지가 있습니다. 각 플랫폼과 서비스 제공자는 자신의 표준을 따르며, 개발자는 어떤 플랫폼과 서비스 제공자를 지원할지 결정해야 합니다. 이는 잠재적인 플랫폼(공급업체) 잠금 또는 중복 작업을 초래할 수 있습니다.

· 보안성: 계좌와 기능의 분리는 유연성의 장점을 가져오지만 보안 문제를 더욱 심각하게 만들 수 있습니다. 모든 기능이 함께 감사될 수 있기 때문에 독립적인 평가가 부족하면 계좌의 취약점 위험이 증가할 수 있습니다.

· 업그레이드 가능성: 계좌가 발전함에 따라 기능을 추가, 교체 또는 삭제할 수 있는 능력을 유지하는 것이 매우 중요합니다. 기존 기능의 각 업데이트를 재배포하는 것은 복잡성을 초래합니다.

이러한 문제를 해결하기 위해서는 안전하고 효율적인 업그레이드를 보장하는 업그레이드 가능한 계약, 전체 개발 효율성을 높이는 재사용 가능한 핵심, 다양한 프론트엔드 간의 원활한 전환을 보장하는 표준화된 인터페이스가 필요합니다.

이러한 용어는 모듈형 계좌 추상화 아키텍처(모듈형 AA)를 구축하는 공통 개념으로 집결됩니다.

모듈형 계좌 추상화는 광범위한 AA 발전의 세분화된 분야로, 스마트 계좌를 모듈화하여 사용자에게 맞춤형 서비스를 제공하고 개발자가 최소한의 제약으로 원활하게 기능을 강화할 수 있도록 하는 것을 구상합니다.

그러나 어떤 산업에서든 새로운 표준을 구축하고 홍보하는 것은 큰 도전입니다. 모두가 동일한 표준을 수용하기 전에는 초기 단계에서 많은 다양한 솔루션이 나타날 수 있습니다. 계좌 추상화를 개선하고 홍보하기 위해 헌신하는 사람들을 보는 것은 고무적입니다. 4337 SDK, 지갑, 인프라 팀 또는 프로토콜 레이어 설계자 등 그들은 모두 이 과정을 가속화하기 위해 함께 노력하고 있습니다.

모듈형 구조: 주 계좌와 모듈

계좌가 모듈을 호출하여 기능을 구현하는 방법

위임 호출(Delegate call) 및 프록시 계약(proxy contract)

외부 호출 및 위임 호출:

위임 호출에 대하여

"위임 호출"은 "호출"과 유사하지만, 목표 계약의 컨텍스트에서 실행되지 않고 호출 계약의 현재 상태의 컨텍스트에서 실행됩니다. 이는 목표 계약에서 이루어진 모든 상태 변경이 호출 계약의 저장소를 변경함을 의미합니다.

프록시 계약과 위임 호출

조합 가능하고 업그레이드 가능한 구조를 구현하기 위해서는 기본 개념인 "프록시 계약"을 도입해야 합니다.

프록시 계약: 일반 계약은 그 논리와 상태를 저장하며, 배포 후에는 업데이트할 수 없습니다. 반면 프록시 계약은 위임 호출(delegate call)을 사용하여 다른 계약에 배포됩니다. 참조를 통해 함수를 구현하고, 프록시 계약의 현재 상태에서 이를 실행합니다.

사용 사례: 프록시 계약은 변하지 않지만, 그 뒤에 새로운 구현을 배포할 수 있습니다. 프록시 계약은 업그레이드 가능성을 구현하며, 공공 블록체인에서의 배포 및 유지 관리 비용이 더 낮습니다.

Safe 아키텍처

Safe 아키텍처

Safe란 무엇인가: Safe는 검증된 보안성과 유연성을 제공하기 위해 설계된 선도적인 모듈형 스마트 계좌 인프라로, 개발자가 다양한 애플리케이션과 지갑을 생성할 수 있도록 합니다. 많은 팀이 Safe를 기반으로(또는 Safe에서 영감을 받아) 애플리케이션을 구축하고 있습니다. 예를 들어, Biconomy는 스마트 계약 계좌를 출시할 때 네이티브 4337 및 1/1 다중 서명을 사용하여 Safe를 확장했습니다. Safe는 164,000개 이상의 계약 배포를 목격했으며, 307억 달러 이상의 가치를 잠금 해제했습니다. 이는 의심할 여지 없이 이 분야의 선두주자입니다.

Safe의 구조는 안전 계좌 계약, 단일 계약, 모듈 계약을 포함합니다.

안전 계좌 계약(프록시 계약): 주 프록시 계약(상태 유지)

안전 계좌는 프록시 계약입니다. 이는 위임 호출이 단일 계약이기 때문입니다. 안전 계좌는 소유자, 임계값 및 구현 주소가 프록시로 설정된 변수를 포함하며, 이를 기반으로 상태를 정의합니다.

단일 계약(싱글턴 계약): 통합 허브(무상태)

단일 계약은 Safe 계좌에 서비스를 제공하며, 플러그인, 훅, 함수 핸들러 및 서명 검증기를 포함한 다양한 모듈 계약 통합을 정의합니다.

모듈 계약(모듈): 사용자 정의 논리 및 기능

모듈 계약은 강력한 기능을 가지고 있습니다. 플러그인은 모듈형 유형으로 다양한 기능을 정의할 수 있으며, 예를 들어 지불 흐름, 복구 메커니즘 및 세션 키를 정의할 수 있으며, Web2와 Web3 간의 다리 역할을 하여 체인 외 데이터를 가져올 수 있습니다. 다른 모듈은 보안 방어 역할을 하는 훅 및 함수 핸들러로, 모든 지시를 응답할 수 있습니다.

Safe 채택 후의 변화:

업그레이드 가능한 계약: 새로운 플러그인을 도입할 때마다 새로운 단일 계약을 배포해야 합니다. 사용자는 Safe를 원하는 단일 계약 버전으로 업그레이드할 권한을 유지합니다.

조합 가능하고 재사용 가능한 모듈: 플러그인의 모듈형 특성은 개발자가 기능을 독립적으로 개발할 수 있게 합니다. 그들은 자신의 사용 사례에 따라 이러한 플러그인을 자유롭게 선택하고 조합하여 매우 맞춤화된 접근 방식을 형성할 수 있습니다.

ERC-2535 다이아몬드 프록시

ERC2535, 다이아몬드 프록시에 대하여:

ERC2535는 다이아몬드 모델을 표준화한 것으로, 이는 배포 후 업그레이드/확장할 수 있는 모듈형 스마트 계약 시스템이며, 크기 제한이 거의 없습니다. 현재 많은 팀이 Zerodev의 Kernel, Soul Wallet의 실험 등 다이아몬드 구조에서 영감을 받고 있습니다.

다이아몬드 구조란 무엇인가:

다이아몬드 계약: 주요 프록시 계약(상태 유지) 다이아몬드는 프록시 계약으로, 위임 호출 방법을 사용하여 그 구현에서 함수를 호출합니다.

모듈/플러그인/Facet 계약: 사용자 정의 논리 및 기능(무상태) 모듈 또는 소위 Facet는 무상태 계약으로, 그 기능을 하나 이상의 다이아몬드에 배포할 수 있습니다. 이들은 개별적이고 독립적인 계약으로, 내부 함수, 라이브러리 및 상태 변수를 공유할 수 있습니다.

다이아몬드 채택 후의 변화:

업그레이드 가능한 계약: 다이아몬드는 서로 다른 플러그인을 격리하고 연결하여 데이터를 공유하는 시스템적 방법을 제공합니다. diamondCut 기능을 사용하여 직접적으로 플러그인을 추가/교체/삭제할 수 있습니다. 시간이 지남에 따라 다이아몬드에 추가할 수 있는 플러그인의 수는 제한이 없습니다.

모듈화되고 재사용 가능한 플러그인: 배포된 플러그인은 임의의 수의 다이아몬드에서 사용할 수 있어 배포 비용을 크게 줄일 수 있습니다.

Safe 스마트 계좌와 다이아몬드 방식의 차이점:

Safe와 다이아몬드 아키텍처 간에는 많은 유사점이 있으며, 두 구조 모두 핵심 프록시 계약에 의존하고 논리 계약을 참조하여 업그레이드 가능성과 모듈화를 구현합니다.

두 구조의 주요 차이점은 논리 계약의 처리 방식입니다. 구체적으로:

· 유연성: 새로운 플러그인을 활성화할 경우, Safe는 프록시 내의 변경을 구현하기 위해 단일 계약(싱글턴)을 재배포해야 합니다. 반면 다이아몬드는 프록시 계약 내의 diamondCut 함수를 통해 이를 직접 구현합니다. 이러한 접근 방식의 차이는 Safe가 더 높은 수준의 제어를 유지하는 반면, 다이아몬드는 향상된 유연성과 모듈화를 도입한다는 것을 의미합니다.

· 보안: 현재 두 구조에서 사용되는 것은 외부 코드가 주요 계약의 저장소를 조작할 수 있도록 허용합니다. Safe 아키텍처에서는 위임 호출이 단일 논리 계약을 가리키는 반면, 다이아몬드는 여러 모듈 계약-플러그인에서 위임 호출을 사용합니다. 따라서 악의적인 플러그인이 다른 플러그인을 덮어쓰는 경우가 발생할 수 있어 저장소 충돌의 위험이 있으며, 프록시의 무결성을 손상시킬 수 있습니다.

· 비용: 다이아몬드 방식에서는 유연성과 보안 위험이 동시에 존재합니다. 이는 비용을 증가시키며, 새로운 플러그인을 추가할 때마다 포괄적인 감사를 요구합니다. 이러한 플러그인이 서로의 기능에 간섭하지 않도록 보장하는 것이 중요하며, 이는 높은 보안 기준을 유지하려는 중소기업에게 특히 도전적입니다.

"Safe 스마트 계좌 방식"과 "다이아몬드 방식"은 프록시 및 모듈과 관련된 다양한 구조의 예입니다. 유연성과 보안 간의 균형을 맞추는 것이 중요하며, 이 두 가지 방법은 미래에도 계속 진화하고 서로 보완할 것입니다.

모듈 순서: 검증자(Validator), 실행자(Executor) 및 훅(Hook)

ERC6900을 소개하여 논의를 이어가겠습니다. 이는 Alchemy 팀이 제안한 것으로, 다이아몬드에서 영감을 받아 ERC-4337에 맞춰 설계된 표준입니다. 이는 일반 인터페이스를 제공하여 스마트 계좌 모듈화의 도전 과제를 해결하고 플러그인 및 지갑 개발자 간의 작업을 조정합니다.

AA의 거래 프로세스에는 주로 세 가지 프로세스가 있습니다: 검증, 실행, 훅. 앞서 논의한 바와 같이, 이러한 단계는 프록시 계좌를 사용하여 모듈을 호출함으로써 관리할 수 있습니다. 서로 다른 프로젝트가 서로 다른 이름을 사용할 수 있지만, 유사한 기본 논리를 이해하는 것이 중요합니다.

다양한 설계에서의 함수 이름

검증(Validator): 계좌 호출자의 진위와 권한을 확인합니다.

실행(Executor): 계좌가 허용하는 모든 사용자 정의 논리를 실행합니다.

훅(Hook): 다른 함수 이전 또는 이후에 실행되는 모듈 역할을 합니다. 상태를 수정하거나 전체 호출을 철회할 수 있습니다.

다양한 논리에 따라 모듈을 분리하는 것이 중요합니다. 표준화된 방법은 스마트 계약 계좌의 검증, 실행 및 훅 함수를 작성하는 방법을 규정해야 합니다. Safe든 ERC6900이든, 표준화는 특정 구현이나 생태계에 특화된 독특한 개발 작업의 필요성을 줄이고 공급업체 잠금을 방지하는 데 도움이 됩니다.

모듈 발견 및 보안

모듈을 개방적으로 찾고 검증하는 방법: 진행 중인 솔루션은 사용자가 검증 가능한 모듈을 발견할 수 있는 영역을 생성하는 것을 포함합니다. 이를 "레지스트리"라고 부를 수 있습니다. 이 레지스트리는 "앱 스토어"와 유사한 기능을 하며, 간소화된 그러나 번창하는 모듈화 시장을 육성하는 것을 목표로 합니다.

Safe{Core} 프로토콜

Safe{Core} 프로토콜은 스마트 계약 계좌를 위한 오픈 소스, 상호 운용 가능한 프로토콜로, 다양한 공급업체와 개발자의 접근성을 향상시키는 동시에 명확하게 정의된 표준과 규칙을 통해 강력한 보안을 유지하는 것을 목표로 합니다.

· 계좌: Safe{Core} 프로토콜에서 계좌의 개념은 유연하며 특정 구현에 구속되지 않습니다. 이는 다양한 계좌 서비스 제공업체가 참여할 수 있도록 합니다.

· 관리자: 관리자는 계좌, 레지스트리 및 모듈 간의 조정자 역할을 합니다. 또한 보안을 책임지는 허가 계층으로 작용합니다.

· 등록 센터: 등록 센터는 보안 속성을 정의하고 ERC6900과 같은 모듈 표준을 실행하여 개방된 "앱 스토어" 환경을 생성하여 발견 가능성과 보안을 실현하는 것을 목표로 합니다.

· 모듈: 모듈은 기능을 처리하며 플러그인, 훅, 서명 검증기 및 함수 처리기를 포함한 다양한 초기 유형을 가집니다. 정해진 표준을 준수하는 한, 개발자는 참여할 수 있습니다.

Rhinestone 설계

이 과정은 다음과 같이 전개됩니다:

· 아키텍처 정의(schema) 생성: 아키텍처는 미리 정의된 데이터 구조를 제공합니다. 사람들은 이를 맞춤화하여 특정 사용 사례에 맞출 수 있습니다.

· 아키텍처 기반 모듈(modules) 생성: 모듈로 등록된 스마트 계약은 바이트코드를 가져오고 아키텍처 ID를 선택하며, 데이터는 레지스트리에 저장됩니다.

· 모듈의 증명(attestation) 획득: 증명자/감사자는 아키텍처를 기반으로 모듈에 대한 증명을 제공할 수 있습니다. 이러한 증명에는 고유 식별자(UID) 및 링크에 사용된 다른 증명에 대한 참조가 포함될 수 있습니다. 이들은 크로스 체인으로 전파되고 특정 임계값을 충족하는지 검증할 수 있습니다.

· 복잡한 논리를 구현하기 위해 해석기(resolver) 사용: 해석기(선택적 설정)는 작동하기 시작합니다. 이들은 모듈 생성, 증명 수립 및 철회 기간 동안 호출될 수 있습니다. 이러한 해석기는 개발자가 복잡하고 다양한 논리를 통합하면서 증명 구조를 유지할 수 있도록 합니다.

사용자 친화적인 쿼리 접근(query): 쿼리는 사용자가 프론트엔드에서 보안 정보를 접근할 수 있는 방법을 제공합니다.

이 모델은 아직 초기 단계에 있지만, 분산되고 협력적인 방식으로 표준을 구축할 수 있는 잠재력을 가지고 있습니다. 레지스트리는 개발자가 자신의 모듈을 등록하고 감사자가 그 보안을 검증하며, 지갑이 통합하고 사용자가 모듈을 쉽게 찾고 그 증명 정보를 검증할 수 있도록 합니다. 미래의 몇 가지 용도는 다음과 같을 수 있습니다:

· 증명자(attestor): Safe와 같은 신뢰할 수 있는 엔티티는 Rhinestone과 협력하여 내부 모듈의 증명자로 활동할 수 있습니다. 동시에 독립적인 증명자도 참여할 수 있습니다.

· 모듈 개발자(module developer): 개방된 시장이 형성됨에 따라 모듈 개발자는 레지스트리를 통해 자신의 작업을 수익화할 가능성이 있습니다.

· 사용자: 사용자 친화적인 인터페이스(예: 지갑 또는 dApp)를 통해 참여하여, 사용자는 모듈 정보를 확인하고 다양한 증명자에게 신뢰를 위임할 수 있습니다.

"모듈 레지스트리" 개념은 플러그인 및 모듈 개발자에게 수익 경로를 열어줍니다. 이는 "모듈 시장"을 위한 길을 더욱 넓힐 수 있습니다. 특정 측면은 Safe 팀이 감독할 수 있으며, 다른 측면은 모든 사람이 기여하고 투명한 감사 기록을 제공하는 탈중앙화된 시장으로 나타날 수 있습니다. 이를 통합하면 공급업체 잠금을 피할 수 있으며, 더 넓은 청중을 끌어들일 수 있는 향상된 사용자 경험을 추가하여 EVM의 확장을 지원할 수 있습니다.

이러한 방법들은 개별 모듈의 보안을 보장할 수 있지만, 더 넓은 보안성 측면에서 스마트 계약 계좌는 완벽하지 않습니다. 모듈을 결합하고 저장소 충돌이 없음을 증명하는 것은 도전이 될 수 있으며, 이는 지갑이나 AA 인프라가 이러한 문제를 해결하는 데 있어 중요함을 강조합니다.

요약

모듈형 스마트 계약 계좌 스택을 활용함으로써, 지갑 제공자와 dApp은 기술 유지 관리의 복잡성에서 벗어날 수 있습니다. 동시에 외부 모듈 개발자는 개인화된 전문 서비스를 제공할 기회를 가집니다. 그러나 해결해야 할 도전 과제는 유연성과 보안 간의 균형을 맞추고, 모듈화 표준을 추진하며, 사용자들이 스마트 계좌를 쉽게 업그레이드하고 수정할 수 있도록 표준화된 인터페이스를 구현하는 것입니다.

또한, 모듈형 스마트 계약 계좌(SCA)는 채택 문제의 일부분에 불과합니다. SCA의 잠재력을 충분히 발휘하기 위해서는 Layer 2 솔루션이 추가적인 프로토콜 레이어 지원을 제공해야 합니다. 예를 들어, 강력한 번들러 인프라 및 P2P 메모리 풀, 더 비용 효율적이고 실행 가능한 SCA 서명 메커니즘, 크로스 체인 SCA 동기화 및 관리 메커니즘, 사용자 친화적인 인터페이스 개발 등이 필요합니다.

미래에는 더 많은 사람들이 SCA를 채택할 것이지만, 이는 몇 가지 흥미로운 질문을 불러일으킬 것입니다. SCA 주문 흐름이 충분한 이익을 창출하게 되면, 전통적인 채굴자가 가치 추출(MEV) 메커니즘을 통해 이 분야에 진입하여 번들러를 구축하고 가치를 얻는 방법은 무엇일까요? 인프라가 성숙해지면, 계좌 추상화(AA)는 "의도 기반" 거래의 기본 레이어로 어떻게 작용할까요? 지켜보도록 하겠습니다.