모듈화된 스마트 계약 계좌 설계: 실용 기술 문제 해결

원문 제목：모듈형 스마트 계약 계좌 아키텍처와 도전 과제

원문 저자：Rui S, SevenX Ventures

편집：심조 TechFlow

소개

외부 소유 계좌(EOA)에서 스마트 계약 계좌(SCA)로의 전환이 활발히 진행되고 있으며, Vitalik 본인을 포함한 많은 애호가들의 지지를 받고 있습니다. 사람들을 흥분시키고 있지만, SCA의 채택은 EOA만큼 보편적이지 않습니다. 여기서 핵심 문제는 불황이 가져온 도전, 이전에 대한 우려, 서명 문제, 가스 비용, 그리고 가장 중요한 엔지니어링 난제입니다.

계좌 추상화(AA)의 가장 중요한 장점 중 하나는 코드를 사용하여 기능을 맞춤화할 수 있는 능력입니다. 그러나 주요 엔지니어링 도전 과제는 AA 기능의 비호환성으로, 이러한 단편화는 통합을 방해하고 공급업체 잠금을 열어줍니다. 또한 동시에 기능을 업그레이드하고 조합할 때 보안을 보장하는 것이 복잡할 수 있습니다.

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

AA 개요

전통적인 EOA는 시드 문구, 가스, 크로스 체인 및 여러 거래와 같은 많은 도전을 도입했습니다. 우리는 복잡성을 도입할 의도가 없었지만, 사실 블록체인은 대중에게 간단한 게임이 아닙니다.

계좌 추상화는 스마트 계약 계좌를 활용하여 프로그래머블 검증 및 실행을 허용하며, 사용자가 각 거래마다 서명하고 방송하는 대신 일괄적으로 거래를 승인할 수 있도록 합니다. 이는 사용자 경험(예: 가스 추상화 및 세션 키), 비용(예: 배치 거래) 및 보안(예: 소셜 복구, 다중 서명)에 이점을 제공합니다. 현재 계좌 추상화를 구현하는 두 가지 방법이 있습니다:

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

• 계약 레이어: 이더리움 및 그 동등한 L2에 대해 ERC4337은 합의 레이어를 변경하지 않고 AA를 지원하기 위해 별도의 트랜잭션 진입점을 도입했습니다. Stackup, Alchemy, Etherspot, Biconomy, Candide 및 Plimico와 같은 프로젝트는 번들러 인프라를 구축하고 있으며, Safe, Zerodev, Etherspot 및 Biconomy와 같은 프로젝트는 스택 및 SDK를 구축하고 있습니다.

SCA 채택의 딜레마

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

이 딜레마를 깊이 탐구해 봅시다:

1. 불황의 영향:

AA가 원활한 로그인 및 가스 추상화와 같은 이점을 도입했음에도 불구하고, 현재 불황을 겪고 있는 사람들은 주로 교육받은 EOA 사용자로 구성되어 있으며, 새로운 사용자들은 아닙니다. 따라서 dApp 및 지갑에 대한 유인이 없습니다. 그럼에도 불구하고 Cyberconnect와 같은 일부 선도적인 애플리케이션은 AA 시스템과 무가스 솔루션을 도입하여 한 달 만에 약 360,000회의 UserOps(AA 거래)를 촉진하고 있습니다.

2. 이전 장벽:

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

3. 서명 문제:

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

4. 가스 비용:

SCA를 배포, 시뮬레이션 및 실행하는 것은 표준 EOA에 비해 더 높은 비용을 발생시킵니다. 이는 채택의 장애물이 되었습니다. 그러나 계좌 생성과 사용자 작업을 분리하고 계좌 소금 및 존재성 검사를 제거하는 것을 고려하는 등의 테스트가 진행되었습니다.

5. 엔지니어링 난제:

ERC-4337 팀은 개발자에게 기본 구현을 제공하는 eth-infinitism 저장소를 구축했습니다. 그러나 다양한 사용 사례에서 더 세분화되거나 특정 기능으로 분기할수록 통합 및 디코딩이 도전 과제가 됩니다.

이 문서에서는 다섯 번째 문제인 엔지니어링 난제를 깊이 탐구할 것입니다.

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

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

• 단편화: 현재 다양한 기능이 특정 SCA 또는 독립적인 플러그인 시스템을 통해 다양한 방식으로 활성화되고 있습니다. 각각은 자체 표준을 따르며, 개발자가 어떤 플랫폼을 지원할지를 결정하도록 강요합니다. 이는 플랫폼 잠금 또는 중복 노력을 초래할 수 있습니다.

• 보안성: 계좌와 기능 간의 유연성은 장점을 가져오지만, 보안 문제를 악화시킬 수 있습니다. 기능은 집단 감사될 수 있지만, 독립적인 평가의 부족은 계좌 취약점의 위험을 증가시킬 수 있습니다.

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

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

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

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

그러나 어떤 산업에서든 새로운 표준을 구축하고 홍보하는 것은 큰 도전입니다. 모두가 주요 솔루션을 수용하기 전에는 초기 단계에서 여러 가지 다른 솔루션이 나타날 수 있습니다. 그러나 고무적인 것은 4337 SDK, 지갑 개발자, 인프라 팀 또는 프로토콜 설계자 모두가 이 과정을 가속화하기 위해 공동으로 노력하고 있다는 점입니다.

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

위임 호출 및 프록시 계약

외부 호출 및 위임 호출:

delegatecall은 call과 유사하지만, 자신의 컨텍스트에서 목표 계약을 실행하는 것이 아니라 호출 계약의 현재 상태에서 목표 계약을 실행합니다. 이는 목표 계약에서 수행된 모든 상태 변경이 호출 계약의 저장소에 적용됨을 의미합니다.

조합 가능하고 업그레이드 가능한 구조를 실현하기 위해서는 "프록시 계약"이라고 하는 기본 지식이 필요합니다.

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

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

보안 아키텍처

Safe는 실전에서 검증된 보안성과 유연성을 제공하여 개발자가 다양한 애플리케이션과 지갑을 만들 수 있도록 하는 선도적인 모듈형 스마트 계좌 인프라입니다. 주목할 점은 많은 팀이 Safe 위에 구축하거나 그로부터 영감을 받고 있다는 것입니다. Biconomy는 Safe에서 네이티브 4337 및 1/1 다중 서명을 확장하여 계좌를 출시했습니다. Safe는 164,000개 이상의 계약을 배포했으며, 307억 이상의 가치를 잠금 상태로 유지하고 있어, 의심할 여지 없이 Safe는 이 분야의 선호 대상입니다.

Safe의 구조

1. Safe 계좌 계약: 주 프록시 계약(상태 있음)

Safe 계좌는 단일 계약을 위임 호출(delegatecall)하여 호출하는 프록시 계약입니다. Safe 계좌는 소유자, 임계값 및 구현 주소를 포함하며, 이들은 모두 프록시의 변수로 설정되어 상태를 정의합니다.

2. 단일 계약: 통합 센터(상태 없음)

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

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

모듈은 매우 강력합니다. 모듈형 유형으로서 플러그인은 지불 흐름, 복구 메커니즘 및 세션 키와 같은 다양한 기능을 정의할 수 있으며, Web2와 Web3 간의 크로스 체인 브리지로서 체인 외 데이터를 가져올 수 있습니다. 후크와 같은 다른 모듈은 보안 보호 역할을 하며, 함수 처리기는 모든 지시를 응답합니다.

Safe를 채택할 때 발생하는 일

1. 업그레이드 가능한 계약:

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

2. 조합 가능하고 재사용 가능한 모듈:

플러그인의 모듈화 특성은 개발자가 기능을 독립적으로 구축할 수 있게 해줍니다. 그런 다음 그들은 자신의 사용 사례에 따라 이러한 플러그인을 자유롭게 선택하고 조합하여 높은 수준의 맞춤형 접근 방식을 촉진할 수 있습니다.

ERC-2535 다이아몬드 프록시

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

ERC2535는 배포 후 업그레이드/확장이 가능하고 거의 크기 제한이 없는 모듈형 스마트 계약 시스템인 다이아몬드 프록시를 표준화했습니다. 지금까지 많은 팀이 Zerodev의 Kernel 및 Soul Wallet의 실험과 같은 영감을 받았습니다.

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

1. 다이아몬드 계약: 주 프록시 계약(상태 있음) 다이아몬드는 프록시 계약으로, 위임 호출(delegatecall)을 통해 구현에서 함수를 호출합니다.

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

다이아몬드를 채택할 때 발생하는 일

1. 업그레이드 가능한 계약: 다이아몬드는 서로 다른 플러그인을 분리하고 연결하는 체계적인 방법을 제공하며, diamondCut 함수를 통해 직접 플러그인을 추가/교체/삭제할 수 있습니다. 시간이 지남에 따라 다이아몬드에 추가할 수 있는 플러그인의 수에는 제한이 없습니다.

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

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

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

그러나 주요 차이점은 논리 계약의 처리 방식에 있습니다. 다음은 더 자세한 설명입니다:

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

2. 보안성: 현재 두 가지 구조 모두 delegatecall을 사용하고 있으며, 이는 외부 코드가 주 계약의 저장소를 조작할 수 있도록 허용합니다. Safe 아키텍처에서는 delegatecall이 단일 논리 계약을 가리키지만, 다이아몬드는 여러 모듈 계약(플러그인) 간에 delegatecall을 사용합니다. 따라서 악의적인 플러그인이 다른 플러그인을 덮어쓸 수 있는 가능성이 있어 저장소 충돌의 위험을 초래하고, 프록시의 무결성을 손상시킬 수 있습니다.

3. 비용: 다이아몬드 방법에 내재된 유연성은 증가된 보안성 문제와 함께 발생합니다. 이는 비용 요소를 증가시키며, 새로운 플러그인을 추가할 때마다 철저한 감사를 수행해야 합니다. 중요한 것은 이러한 플러그인이 서로의 기능에 간섭하지 않도록 보장하는 것이며, 이는 강력한 보안 기준을 유지하려는 중소기업에게 도전 과제가 됩니다.

"Safe 스마트 계좌 방법"과 "다이아몬드 방법"은 프록시와 모듈을 포함하는 서로 다른 구조의 예입니다. 유연성과 보안성 간의 균형을 맞추는 것이 중요하며, 이 두 가지 방법은 미래에 서로 보완할 가능성이 있습니다.

모듈 순서: 검증기, 실행기 및 후크

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

AA의 거래 과정에는 세 가지 주요 과정이 있습니다: 검증, 실행 및 후크. 이전에 논의한 바와 같이, 위임 계좌를 사용하여 모듈을 호출함으로써 이러한 단계를 관리할 수 있습니다. 다양한 프로젝트가 다른 이름을 사용할 수 있지만, 유사한 기본 논리를 파악하는 것이 중요합니다.

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

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

• 후크: 다른 함수 이전 또는 이후에 실행되는 모듈로, 상태를 수정하거나 전체 호출을 철회할 수 있습니다.

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

모듈의 발견과 보안성

급성장하는 솔루션 중 하나는 사용자가 검증 가능한 모듈을 발견할 수 있는 장소를 만드는 것으로, 이를 "레지스트리"라고 부를 수 있습니다. 이 레지스트리는 "앱 스토어"와 유사하며, 간소화된 번영하는 모듈화 시장을 촉진하는 것을 목표로 합니다.

Safe{Core} 프로토콜

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

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

• 관리자: 관리자는 계좌, 레지스트리 및 모듈 간의 조정자로 작용합니다. 또한 보안을 담당하며 권한 계층으로 기능합니다.

• 레지스트리: 레지스트리는 보안 속성을 정의하고 ERC6900과 같은 모듈 표준을 시행하여 발견과 보안을 위한 개방된 "앱 스토어" 환경을 창출합니다.

• 모듈: 모듈은 기능을 처리하며 플러그인, 후크, 서명 검증기 및 함수 처리기와 같은 다양한 초기 유형을 제공합니다. 정해진 표준을 충족하는 한, 개발자는 이를 위해 기여할 수 있습니다.

Rhinestone 디자인

이 과정의 전개는 다음과 같습니다:

• 패턴 정의 생성: 패턴은 증명을 위한 미리 정의된 데이터 구조로 사용됩니다. 기업은 특정 사용 사례에 따라 패턴을 사용자 정의할 수 있습니다.

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

• 모듈의 증명 획득: 증명자/감사자는 패턴에 따라 모듈에 대한 증명을 제공할 수 있습니다. 이러한 증명에는 고유 식별자(UID) 및 링크를 위한 다른 증명의 참조가 포함될 수 있습니다. 이들은 체인에서 전파되고, 특정 임계값이 목표 체인에서 충족되는지를 검증할 수 있습니다.

• 해석기를 사용하여 복잡한 논리 구현: 해석기는 패턴 내에서 선택적 설정으로 존재할 수 있습니다. 이들은 모듈 생성, 증명 구축 및 철회 과정에서 호출될 수 있습니다. 이러한 해석기는 개발자가 증명 구조를 유지하면서 복잡하고 다양한 논리를 통합할 수 있게 해줍니다.

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

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

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

• 모듈 개발자: 개방된 시장이 형성됨에 따라 모듈 개발자는 레지스트리를 통해 그들의 작업을 상업화할 수 있는 가능성이 있습니다.

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

"모듈 레지스트리" 개념은 플러그인 및 모듈 개발자에게 수익 기회를 제공합니다. 또한 "모듈 시장"을 위한 길을 열 수 있습니다. 이들 중 일부는 Safe 팀이 감독할 수 있으며, 다른 부분은 탈중앙화된 시장으로 나타나 모든 사람이 기여하고 투명한 감사 기록을 제공하도록 초대할 수 있습니다. 이러한 방식을 채택함으로써 우리는 공급업체 잠금을 피하고 더 나은 사용자 경험을 제공하여 EVM의 확장을 지원하는 더 넓은 청중을 유치할 수 있습니다.

이러한 방법들은 개별 모듈의 보안을 보장하지만, 스마트 계약 계좌의 전체 보안성은 절대적으로 신뢰할 수 없습니다. 합법적인 모듈과 그것들이 저장소 충돌이 없음을 증명하는 것은 도전 과제가 될 수 있으며, 이는 지갑이나 AA 인프라가 이러한 문제를 해결하는 데 있어 중요한 역할을 강조합니다.

결론

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

그러나 모듈형 스마트 계약 계좌(SCA)는 채택의 퍼즐 조각 중 하나일 뿐입니다. SCA의 잠재력을 충분히 실현하기 위해서는 2층 솔루션의 프로토콜 레이어 지원, 강력한 번들러 인프라 및 피어 투 피어 메모리 풀, 더 비용 효율적이고 실행 가능한 SCA 서명 메커니즘, 크로스 체인 SCA 동기화 및 관리, 그리고 사용자 친화적인 인터페이스 개발이 필요합니다.

우리는 광범위한 참여가 이루어지는 미래를 상상하며, 몇 가지 흥미로운 질문을 제기합니다: SCA 주문 프로세스가 충분히 수익성이 높아지면, 전통적인 채굴자가 가치를 추출할 수 있는(MEV) 메커니즘은 어떻게 이 분야에 진입하여 가치를 포착할까요? 인프라가 성숙해질 때, 계좌 추상화(AA)는 "의도 기반" 거래의 기본 레이어가 되는 방법은 무엇일까요? 지속적으로 주목해 주세요, 이 분야는 끊임없이 발전하고 변화하고 있습니다.