모듈식 스마트 계약 계정 설계에 대한 심층 토론: 구현 시 기술적 문제 해결

원래 제목:Modular Smart Contract Account Architecture and Challenges

원저자: Rui S, SevenX Ventures

원본 편집: Deep Chao TechFlow

소개하다

외부 소유 계정(EOA)에서 스마트 계약 계정(SCA)으로의 전환이 급속도로 진행되고 있으며 Vitalik 자신을 포함한 많은 매니아들의 지지를 받고 있습니다. 많은 기대에도 불구하고 SCA 채택은 EOA만큼 널리 확산되지 않았습니다. 주요 문제에는 약세장 문제, 마이그레이션 문제, 서명 문제, 가스 오버헤드 및 가장 중요한 엔지니어링 문제가 포함됩니다.

AA(계정 추상화)의 가장 중요한 장점 중 하나는 코드를 사용하여 기능을 사용자 정의할 수 있다는 것입니다. 그러나 주요 엔지니어링 과제는 AA 기능의 비상호운용성이며, 이러한 단편화는 통합을 방해하고 공급업체 종속의 문을 열어줍니다. 또한 기능을 동시에 업그레이드하고 결합할 때 보안을 보장하는 것은 복잡할 수 있습니다.

모듈식 계정 추상화는 스마트 계정을 사용자 정의 기능에서 분리하는 혁신적인 접근 방식인 광범위한 AA 운동의 하위 집합으로 나타났습니다. 목표는 다양한 기능을 갖춘 안전하고 완벽하게 통합된 지갑을 개발하기 위한 모듈식 구조를 만드는 것입니다. 앞으로는 지갑과 dApp이 더 이상 기능 구축에 집중하지 않고 사용자 경험에 집중할 수 있도록 무료 스마트 계약 계정 앱 스토어를 구현할 수 있습니다.

AA 간략한 설명

전통적인 EOA에는 시드 문구, 가스, 크로스체인 및 다중 거래와 같은 많은 문제가 발생합니다. 우리는 결코 복잡성을 도입할 의도가 없었지만 현실은 블록체인이 대중에게 쉬운 게임이 아니라는 것입니다.

계정 추상화는 스마트 계약 계정을 활용하여 프로그래밍 가능한 검증 및 실행을 허용하고 사용자가 각 거래에 서명하고 브로드캐스트할 필요 없이 일련의 거래를 한 번에 승인할 수 있도록 하며 더 많은 기능을 활성화합니다. 이는 사용자 경험(예: 가스 추상화 및 세션 키), 비용(예: 일괄 트랜잭션) 및 보안(예: 소셜 복구, 다중 서명)에 이점을 제공합니다. 현재 계정 추상화를 구현하는 방법에는 두 가지가 있습니다.

• 프로토콜 계층: 일부 프로토콜 자체는 로컬 계정 추상화 지원을 제공합니다. EOA이든 SCA이든 ZKsync 트랜잭션은 동일한 프로세스를 따르며 단일 메모리 풀과 트랜잭션 프로세스를 사용하여 AA를 지원하는 반면 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에 비해 훨씬 적습니다.

이 딜레마에 대해 더 자세히 살펴보겠습니다.

• 약세장의 영향:

AA는 원활한 로그인, 가스 추상화 등의 이점을 도입했지만 현재 약세장을 경험하고 있는 사람들은 주로 신규 사용자보다는 교육받은 EOA 사용자들로 구성되어 있어 dApp 및 지갑에 대한 인센티브가 없습니다. 그럼에도 불구하고 일부 주요 애플리케이션에서는 AA 시스템과 가스 프리 솔루션을 도입하여 단 한 달 만에 약 360,000개의 UserOps(AA 트랜잭션)를 유도한 Cyberconnect와 같은 AA를 점차적으로 채택하고 있습니다.

• 마이그레이션 장벽:

사용자와 자산이 축적된 지갑과 애플리케이션의 경우 안전하고 편리하게 자산을 이전하는 것은 여전히 ​​어려운 과제로 남아 있습니다. 그러나 EIP-7377과 같은 이니셔티브를 통해 EOA는 일회성 마이그레이션 트랜잭션을 시작할 수 있습니다.

• 서명 문제:

스마트 계약 자체에는 EOA와 같은 개인 키가 없기 때문에 자연스럽게 메시지에 서명할 수 없습니다. ERC 1271과 같은 노력으로 이러한 서명이 가능해졌지만 메시지 서명은 첫 번째 트랜잭션까지 작동하지 않으므로 반사실 배포를 사용하는 지갑에 문제가 됩니다. Ambire가 제안한 ERC-6492는 ERC-1271의 이전 버전과 호환되는 후속 버전이며 이전 문제를 해결할 수 있습니다.

• 가스 오버헤드:

SCA 배포, 시뮬레이션 및 실행에는 표준 EOA보다 비용이 더 많이 듭니다. 이는 채택에 장애가 됩니다. 그러나 이러한 비용을 줄이기 위해 계정 생성을 사용자 작업과 분리하고 계정 솔트 및 존재 확인을 제거하는 것을 고려하는 등 몇 가지 테스트가 있었습니다.

• 엔지니어링 어려움:

ERC-4337 팀은 개발자에게 기본 구현을 제공하기 위해 eth-infinitiism 저장소를 구축했습니다. 그러나 다양한 사용 사례에서 더욱 세분화되거나 구체적인 기능으로 확장됨에 따라 통합 및 디코딩이 어려워집니다.

이 기사에서는 다섯 번째 문제인 엔지니어링 과제에 대해 더 자세히 살펴보겠습니다.

엔지니어링 문제를 해결하기 위한 모듈형 스마트 계약 계정

엔지니어링 과제에 대한 추가 설명은 다음과 같습니다.

• 단편화: 이제 특정 SCA를 통해서든 독립 플러그인 시스템을 통해서든 다양한 기능이 다양한 방식으로 활성화됩니다. 각각은 자체 표준을 따르므로 개발자는 지원할 플랫폼을 결정해야 합니다. 이로 인해 플랫폼이 잠기거나 노력이 중복될 수 있습니다.

• 보안: 계정과 기능 간의 유연성은 이점을 제공하지만 보안 문제를 악화시킬 수도 있습니다. 기능은 집합적으로 감사될 수 있지만 독립적인 평가가 부족하면 계정 위반 위험이 높아질 수 있습니다.

• 업그레이드 가능성: 기능이 발전함에 따라 기능을 추가, 교체 또는 제거할 수 있는 능력을 유지하는 것이 중요합니다. 업데이트할 때마다 기존 기능을 재배포하면 복잡성이 발생합니다.

이러한 문제를 해결하려면 안전하고 효율적인 업그레이드를 보장하기 위한 업그레이드 가능한 계약, 전반적인 개발 효율성을 향상시키기 위한 재사용 가능한 코어, 계약 계정이 서로 다른 프런트 엔드 간에 원활하게 전환될 수 있도록 보장하는 표준화된 인터페이스가 필요합니다.

이러한 용어는 모듈식 계정 추상화 아키텍처(모듈식 AA) 구축이라는 공통 개념으로 수렴됩니다.

모듈식 AA는 사용자에게 서비스를 맞춤화하고 개발자가 최소한의 제한으로 기능을 원활하게 향상시킬 수 있도록 스마트 계정을 모듈화하는 것을 구상하는 광범위한 AA 운동의 틈새 시장입니다.

그러나 새로운 표준을 수립하고 홍보하는 것은 모든 산업 분야에서 큰 과제입니다. 모든 사람이 주요 솔루션을 받아들이기 전의 초기 단계에서는 다양한 솔루션이 나타날 수 있습니다. 그러나 4337 SDK, 지갑 개발자, 인프라 팀 및 프로토콜 디자이너가 모두 협력하여 이 프로세스의 속도를 높이는 것은 고무적입니다.

모듈형 구조: 마스터 계정 및 모듈

통화 및 대리 계약 위임

외부 통화 및 대리인 통화:

Delegatecall은 호출과 유사하지만 자체 컨텍스트에서 대상 계약을 실행하는 대신 호출 계약의 현재 상태에서 대상 계약을 실행합니다. 이는 대상 계약에 의한 모든 상태 변경이 호출 계약의 저장소에 적용된다는 것을 의미합니다.

구성 가능하고 업그레이드 가능한 구조를 구현하려면 에이전시 계약이라는 기본 지식이 필요합니다.

• 프록시 계약: 일반 계약은 논리와 상태를 저장하며 배포 후에는 업데이트할 수 없습니다. 프록시 계약은 대리인을 사용하여 다른 계약을 호출합니다. 에이전트 계약의 현재 상태에서 실행되는 함수를 참조로 구현합니다.

• 사용 사례: 프록시 계약은 동일하게 유지되지만 프록시 뒤에 새로운 구현을 배포할 수 있습니다. 프록시 계약은 업그레이드를 위해 사용되며 퍼블릭 블록체인에 배포하고 유지하는 것이 더 저렴합니다.

보안 아키텍처

Safe는 입증된 보안과 유연성을 제공하여 개발자가 다양한 애플리케이션과 지갑을 만들 수 있도록 설계된 선도적인 모듈형 스마트 계정 인프라입니다. 많은 팀이 Safe를 기반으로 구축하거나 Safe에서 영감을 받아 구축하고 있다는 점은 주목할 가치가 있습니다. Biconomy는 Safe에서 기본 4337 및 1/1 다중 서명을 확장하여 계정을 시작합니다. 164,000개 이상의 계약이 배포되고 307억 달러 이상의 가치가 고정되어 있는 Safe는 의심할 여지 없이 이 분야에서 최고의 선택입니다.

안전한 구조

• 안전계좌 계약 : 주체계약(Stateful)

Safe 계정은 싱글톤 계약을 위임 호출하므로 프록시 계약입니다. Safe 계정에는 에이전트의 변수로 설정되는 소유자, 임계값 및 구현 주소가 포함되어 에이전트의 상태를 정의합니다.

• 싱글톤 계약: 통합 센터(상태 비저장)

싱글톤은 Safe 계정을 제공하고 플러그인, 후크, 함수 핸들러 및 서명 유효성 검사기를 포함한 다양한 통합을 통합하고 정의합니다.

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

모듈은 매우 강력합니다. 모듈형 플러그인은 결제 흐름, 복구 메커니즘, 세션 키 등 다양한 기능을 정의할 수 있으며, 오프체인 데이터를 획득하여 Web2와 Web3 간의 크로스체인 브리지 역할을 할 수 있습니다. Hooks와 같은 다른 모듈은 안전 가드 역할을 하며 함수 핸들러는 모든 명령에 응답합니다.

Safe를 채택하면 어떻게 되나요?

• 업그레이드 가능한 계약:

새로운 플러그인이 도입될 때마다 새로운 싱글톤을 배포해야 합니다. 사용자는 선호도와 요구 사항에 맞게 Safe를 원하는 싱글톤 버전으로 업그레이드할 수 있는 자율성을 유지합니다.

• 구성 가능하고 재사용 가능한 모듈:

플러그인의 모듈식 특성으로 인해 개발자는 독립적으로 기능을 구축할 수 있습니다. 그런 다음 자신의 사용 사례에 따라 이러한 플러그인을 자유롭게 선택하고 결합할 수 있으므로 고도로 사용자 정의 가능한 접근 방식이 가능해집니다.

ERC-2535 다이아몬드 에이전트

ERC 2535 및 다이아몬드 에이전트 소개

ERC 2535는 배포 후 업그레이드/확장할 수 있고 크기 제한이 거의 없는 모듈형 스마트 계약 시스템인 Diamond Agent를 표준화합니다. 지금까지 Zerodev의 Kernel과 Soul Wallet의 실험 등 많은 팀이 이에 영감을 받았습니다.

다이아몬드의 구조는 무엇입니까?

• 다이아몬드 계약: 마스터 프록시 계약(상태 저장) 다이아몬드는 위임자 호출을 통해 구현에서 기능을 호출하는 프록시 계약입니다.

• 모듈/플러그인/패싯 계약: 사용자 정의 논리 및 기능(상태 비저장) 모듈 또는 소위 패싯은 해당 기능을 하나 이상의 다이아몬드에 배포할 수 있는 상태 비저장 계약입니다. 내부 함수, 라이브러리, 상태 변수를 공유할 수 있는 독립적인 계약입니다.

다이아몬드를 사용하면 어떻게 되나요?

• 업그레이드 가능한 계약: Diamond는 다양한 플러그인을 분리하여 함께 연결하고, DiamondCut 기능을 통해 플러그인을 직접 추가/교체/제거하는 체계적인 방법을 제공합니다. 시간이 지남에 따라 Diamond에 추가할 수 있는 플러그인 수에는 제한이 없습니다.

• 모듈식 및 재사용 가능한 플러그인: 배포된 플러그인은 원하는 수의 다이아몬드에서 사용할 수 있으므로 배포 비용이 크게 절감됩니다.

안전한 스마트 계정과 다이아몬드 방식의 차이점

Safe와 Diamond 아키텍처에는 프록시 계약을 핵심으로 사용하고 업그레이드 가능성과 모듈성을 위한 논리 계약을 참조한다는 점에서 많은 유사점이 있습니다.

그러나 주요 차이점은 논리적 계약 처리에 있습니다. 자세한 지침은 다음과 같습니다.

• 유연성: 새로운 플러그인이 활성화되면 Safe는 에이전트의 변경 사항을 구현하기 위해 싱글톤 계약을 재배포해야 합니다. 대조적으로, Diamond는 대리자의 DiamondCut 함수를 통해 이를 직접 수행합니다. 이러한 접근 방식의 차이는 Safe가 더 높은 수준의 제어를 유지하는 반면 Diamond는 더 높은 유연성과 모듈성을 도입한다는 것을 의미합니다.

• 보안: 현재 외부 코드가 기본 계약의 저장소를 조작할 수 있도록 허용하는 두 구조 모두에서 위임 호출이 사용됩니다. Safe 아키텍처에서 Delegatecall은 단일 논리적 계약을 가리키는 반면 Diamond는 여러 모듈 계약(플러그인) 간의 Delegatecall을 사용합니다. 따라서 악성 플러그인이 다른 플러그인을 덮어쓰게 되면 에이전트의 무결성을 손상시킬 수 있는 저장소 충돌 위험이 발생할 수 있습니다.

• 비용: 다이아몬드 접근 방식에 내재된 유연성으로 인해 보안 문제가 증가합니다. 이로 인해 비용 요소가 추가되고 새 플러그인이 추가될 때마다 전체 감사가 필요합니다. 핵심은 이러한 플러그인이 서로의 기능을 방해하지 않도록 하는 것입니다. 이는 강력한 보안 표준을 유지하려는 중소기업에게 어려운 일이 될 수 있습니다.

세이프 스마트 어카운트 방식과 다이아몬드 방식은 에이전트와 모듈이 관련된 다양한 구조의 예입니다. 유연성과 보안의 균형을 맞추는 방법이 중요하며 두 접근 방식은 향후 서로를 보완할 가능성이 높습니다.

모듈 순서: 유효성 검사기, 실행기 및 후크

다이아몬드에서 영감을 받아 ERC-4337에 맞게 특별히 조정된 Alchemy 팀이 제안한 표준인 ERC 6900을 소개하여 논의를 확장해 보겠습니다. 공통 인터페이스를 제공하고 플러그인과 지갑 개발자 간의 작업을 조정하여 스마트 계정의 모듈성 문제를 해결합니다.

AA의 거래 프로세스는 크게 검증(Verification), 실행(Execution), 후크(Hook) 3가지 프로세스로 구성됩니다. 앞서 논의한 것처럼 이러한 단계는 프록시 계정을 사용하여 모듈을 호출하여 관리할 수 있습니다. 프로젝트마다 서로 다른 이름을 사용할 수 있지만 유사한 기본 논리를 캡처하는 것이 중요합니다.

• 확인: 발신자 계정의 신뢰성과 권한을 확인합니다.

• 실행: 계정에서 허용하는 모든 사용자 지정 논리를 실행합니다.

• Hook: 다른 기능 전후에 실행되는 모듈입니다. 상태를 수정하거나 전체 호출이 취소될 수 있습니다.

서로 다른 로직을 기반으로 모듈을 분리하는 것이 중요합니다. 표준화된 접근 방식은 스마트 계약 계정 확인, 실행 및 Hook 기능을 작성하는 방법을 지정해야 합니다. 안전하든 ERC 6900이든 표준화는 특정 구현이나 생태계에 대한 고유한 개발 노력의 필요성을 줄이고 공급업체 종속을 방지하는 데 도움이 됩니다.

모듈 검색 및 보안

호황을 누리고 있는 한 가지 솔루션은 사용자가 검증 가능한 모듈, 즉 레지스트리를 검색할 수 있는 장소를 만드는 것입니다. 이 레지스트리는 단순하지만 번창하는 모듈식 시장을 촉진하도록 설계된 앱 스토어와 유사합니다.

안전한{핵심} 프로토콜

Safe{Core} 프로토콜은 강력한 보안을 유지하면서 명확하게 정의된 표준과 규칙을 통해 다양한 공급업체와 개발자의 접근성을 높이도록 설계된 오픈 소스, 상호 운용 가능한 스마트 계약 계정 프로토콜입니다.

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

• 관리자: 관리자는 계정, 레지스트리 및 모듈 간의 조정자 역할을 합니다. 또한 권한 계층 역할을 하여 보안을 담당합니다.

• 레지스트리: 레지스트리는 보안 속성을 정의하고 ERC 6900과 같은 모듈 표준을 시행하여 검색 및 보안을 위한 개방형 앱 스토어 환경을 만드는 것을 목표로 합니다.

• 모듈: 모듈은 기능을 처리하며 플러그인, 후크, 서명 유효성 검사기 및 함수 핸들러를 포함한 다양한 초기 유형으로 제공됩니다. 개발자는 확립된 표준을 충족하는 한 이에 기여할 수 있습니다.

Rhinestone Design

프로세스는 다음과 같이 전개됩니다.

• 스키마 정의 생성: 스키마는 증명에 사용할 사전 정의된 데이터 구조 역할을 합니다. 기업은 특정 사용 사례에 따라 패턴을 사용자 정의할 수 있습니다.

• 패턴을 기반으로 모듈 생성: 스마트 계약이 모듈로 등록되고 바이트코드를 가져오고 패턴 ID를 선택합니다. 이 데이터는 레지스트리에 저장됩니다.

• 모듈에 대한 증명 얻기: 증명자/감사자는 스키마를 기반으로 모듈에 대한 증명을 제공할 수 있습니다. 이러한 인증서에는 고유 식별자(UID)와 연결을 위한 다른 인증서에 대한 참조가 포함될 수 있습니다. 이는 온체인으로 전파될 수 있으며 대상 체인에서 특정 임계값이 충족되는지 확인할 수 있습니다.

• 파서를 사용하여 복잡한 논리 구현: 파서는 선택적으로 스키마에 설정됩니다. 모듈 생성, 증명 설정 및 해체 중에 호출할 수 있습니다. 이러한 파서를 통해 개발자는 증명 구조를 유지하면서 복잡하고 다양한 논리를 통합할 수 있습니다.

• 사용자 친화적인 쿼리 액세스: 쿼리는 사용자가 프런트 엔드에서 보안 정보에 액세스할 수 있는 방법을 제공합니다. EIP는 여기에서 확인할 수 있습니다.

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

• 인증자: Safe와 같은 신뢰할 수 있는 실체는 내부 모듈의 인증자로서 라인스톤과 협력할 수 있습니다. 동시에 독립적인 증명자도 참여할 수 있습니다.

• 모듈 개발자: 공개 시장이 형성되면서 모듈 개발자는 레지스트리를 통해 자신의 작업을 상용화하는 것이 가능합니다.

• 사용자: 지갑이나 dApp과 같은 사용자 친화적인 인터페이스를 통해 사용자는 모듈 정보를 보고 다른 증명자에게 신뢰를 위임할 수 있습니다.

모듈 레지스트리 개념은 플러그인 및 모듈 개발자에게 수익성 있는 기회를 제공합니다. 이는 또한 모듈 시장을 위한 길을 열 수도 있습니다. 이러한 측면 중 일부는 Safe 팀에 의해 감독될 수 있지만 다른 측면은 모든 사람이 기여하고 투명한 감사 추적을 제공하도록 초대하는 분산형 시장으로 나타날 수 있습니다. 이러한 접근 방식을 취함으로써 우리는 벤더 종속을 피하고 더 많은 청중에게 어필할 수 있는 더 나은 사용자 경험을 제공함으로써 EVM의 확장을 지원할 수 있습니다.

이러한 방법은 개별 모듈의 보안을 보장하지만 스마트 계약 계정의 전반적인 보안은 절대적으로 신뢰할 수 없습니다. 합법적인 모듈을 결합하고 스토리지 충돌이 없음을 증명하는 것은 어려울 수 있으며, 이러한 문제를 해결하는 데 있어 지갑이나 AA 인프라의 중요성을 강조합니다.

요약하다

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

그러나 모듈식 스마트 계약 계정(SCA)은 채택 퍼즐의 한 부분일 뿐입니다. SCA의 잠재력을 완전히 실현하려면 강력한 번들러 인프라 및 P2P 메모리 풀, 보다 비용 효율적이고 실행 가능한 SCA 서명 메커니즘, 크로스체인 SCA 동기화뿐만 아니라 두 번째 계층 솔루션의 프로토콜 계층 지원도 필요합니다. 및 관리는 물론 사용자 친화적인 인터페이스를 개발합니다.

우리는 광범위한 참여가 가능한 미래를 상상하며 몇 가지 흥미로운 질문을 제기합니다. SCA 주문 프로세스가 충분히 수익성이 있게 되면 기존 MEV(채굴 추출 가능 가치) 메커니즘이 어떻게 공간에 진입하고 번들러를 구축하고 가치를 포착할 것인가? 인프라가 성숙되면 AA(계정 추상화)가 어떻게 의도 기반 트랜잭션의 기본 계층이 될 수 있습니까? 이 영역은 지속적으로 발전하고 있으므로 계속 지켜봐 주시기 바랍니다.