작성: Rui S( SevenX Ventures)

번역: TechFlow

소개

외부 소유 계정(EOA)에서 스마트 계약 계정(SCA)으로의 전환은 비탈릭을 포함한 많은 지지자들의 지지를 받으며 활발히 진행되고 있다. 그러나 기대감에도 불구하고 SCA의 채택은 EOA만큼 보편적이지 않다. 주요 문제는 약세장이 초래하는 어려움, 마이그레이션 우려, 서명 문제, 가스 비용 및 가장 중요한 엔지니어링 난제들이다.

계정 추상화(AA)의 가장 중요한 이점 중 하나는 코드를 통해 기능을 맞춤화할 수 있다는 점이다. 그러나 주요 엔지니어링 과제는 AA 기능 간의 상호 운용성 부족이며, 이러한 단편화는 통합을 방해하고 공급업체 잠금 현상을 유도한다. 또한 기능을 동시에 업그레이드하고 조합할 때 보안을 유지하는 것은 복잡할 수 있다.

모듈형 계정 추상화의 등장은 더 광범위한 AA 운동의 하위 분야로서, 스마트 계정과 그 사용자 정의 기능을 분리하는 혁신적인 접근법이다. 다양한 기능을 안전하게 통합하고 원활하게 작동하는 지갑을 개발하기 위한 모듈형 구조를 만들고자 한다. 미래에는 자유로운 스마트 계약 계정 ‘앱 스토어’를 실현하여 지갑과 dApp이 기능 구축보다 사용자 경험에 집중할 수 있게 될 것이다.

AA 개요

기존의 EOA는 시드 문구, 가스, 크로스체인, 다수의 트랜잭션 등 많은 도전 과제를 제시한다. 우리는 복잡성을 의도적으로 도입한 적 없지만, 블록체인은 대중에게 결코 쉬운 게임이 아니었다.

계정 추상화는 스마트 계약 계정을 활용하여 프로그래밍 가능한 검증과 실행을 가능하게 하며, 사용자는 각 트랜잭션마다 서명하고 브로드캐스트하는 것이 아니라 일련의 트랜잭션을 한 번에 승인할 수 있다. 이는 사용자 경험(예: 가스 추상화, 세션 키), 비용(예: 배치 처리), 보안(예: 소셜 리커버리, 멀티서명) 측면에서 이점을 제공한다. 현재 계정 추상화를 구현하는 두 가지 방법이 있다:

• 프로토콜 계층: 일부 프로토콜은 자체적으로 네이티브 AA 지원을 제공한다. ZKsync는 EOA나 SCA에서 오는 트랜잭션 모두 동일한 프로세스를 따르며, 단일 메모리풀과 트랜잭션 흐름을 통해 AA를 지원한다. Starknet은 아예 EOA를 제거하고 모든 계정을 SCA로 만들었으며 Argent와 같은 네이티브 스마트 계약 지갑을 갖추고 있다.

• 계약 계층: 이더리움 및 이에 상응하는 L2의 경우, ERC4337은 합의 계층을 변경하지 않고도 별도의 트랜잭션 진입점을 도입하여 AA를 지원한다. Stackup, Alchemy, Etherspot, Biconomy, Candide, Pimlico 등의 프로젝트는 번들러 인프라를 구축 중이며, Safe, Zerodev, Etherspot, Biconomy 등의 프로젝트는 스택과 SDK를 개발하고 있다.

SCA 채택의 딜레마

2015년 이후로 계정 추상화(AA)는 논의되어 왔으며 올해 ERC4337에 의해 중심 무대에 등장했다. 그러나 배포된 스마트 계약 계정 수는 여전히 EOA에 크게 못 미친다.

이 딜레마를 깊이 살펴보자:

1. 약세장의 영향:

AA는 원활한 로그인, 가스 추상화 등의 이점을 제공하지만, 현재 약세장을 겪는 사용자들은 대부분 교육받은 EOA 사용자들이며 신규 사용자가 아니다. 따라서 dApp과 지갑 입장에서는 유인이 없다. 그럼에도 불구하고 일부 선도적 애플리케이션은 점진적으로 AA를 채택하고 있는데, 예를 들어 Cyberconnect는 자체 AA 시스템과 가스 프리 솔루션을 도입한 후 한 달 만에 약 36만 건의 UserOps(AA 트랜잭션)를 유도했다.

2. 마이그레이션 장벽:

이미 사용자와 자산을 축적한 지갑과 애플리케이션 입장에서는 자산을 안전하고 편리하게 마이그레이션하는 것이 여전히 도전이다. 그러나 EIP-7377과 같은 제안은 EOA가 일회성 마이그레이션 트랜잭션을 시작할 수 있도록 한다.

3. 서명 문제:

스마트 계약 자체는 EOA처럼 개인키를 갖지 않기 때문에 메시지를 서명할 수 없다. ERC1271과 같은 노력은 이를 가능하게 하지만, 첫 번째 트랜잭션이 발생하기 전까지는 메시지 서명이 작동하지 않아 반사실적 배포(factored deployment) 지갑에 도전 과제를 제시한다. Ambire가 제안한 ERC-6492은 ERC-1271의 역방향 호환 후속 표준으로 이전 문제들을 해결할 수 있다.

4. 가스 비용:

표준 EOA에 비해 SCA의 배포, 시뮬레이션, 실행은 더 높은 비용을 초래한다. 이는 채택의 장벽이 된다. 그러나 계정 생성과 유저 오퍼레이션을 분리하거나 계정 소금값(salt)과 존재성 확인을 제거하는 등의 테스트를 통해 비용 절감을 모색하고 있다.

5. 엔지니어링 난제:

ERC-4337 팀은 개발자들에게 기본 구현을 제공하기 위해 eth-infinitism 저장소를 구축했다. 그러나 다양한 사용 사례에서 더욱 정교하거나 특정 기능으로 분기할 경우 통합과 디코딩이 어렵다.

본 문서에서는 다섯 번째 문제인 엔지니어링 난제에 대해 심층적으로 다룬다.

엔지니어링 난제 해결을 위한 모듈형 스마트 계약 계정

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

• 단편화: 현재 다양한 기능은 특정 SCA 또는 독립 플러그인 시스템을 통해 서로 다른 방식으로 활성화된다. 각각 고유한 표준을 따르기 때문에 개발자는 어느 플랫폼을 지원할지 결정해야 하며, 이는 플랫폼 잠금이나 중복 작업을 초래할 수 있다.

• 보안: 계정과 기능 간의 유연성은 장점이지만 보안 문제를 가중시킬 수 있다. 기능은 집단적으로 감사를 받을 수 있지만, 독립 평가 부재는 계정 취약성 위험을 증가시킨다.

• 업그레이드 가능성: 기능이 발전함에 따라 기능을 추가, 교체, 삭제할 수 있는 능력을 유지하는 것이 중요하다. 매번 업데이트 시 기존 기능을 재배포하면 복잡성이 증가한다.

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

이러한 용어들은 하나의 공통 개념에 수렴한다: 모듈형 계정 추상화 아키텍처(Modular AA) 구축이다.

모듈형 AA는 더 광범위한 AA 운동의 하위 분야로서, 스마트 계정을 모듈화하여 사용자에게 맞춤 서비스를 제공하고 개발자가 최소한의 제약 아래 기능을 원활히 강화할 수 있도록 한다.

그러나 어떤 산업이든 새로운 표준을 수립하고 확산시키는 것은 거대한 도전이다. 주요 해결책이 모두 받아들여지기 전까지 초기 단계에서는 다양한 솔루션이 등장할 수 있다. 하지만 고무적인 점은 4337 SDK, 지갑 개발자, 인프라 팀, 프로토콜 설계자들이 모두 함께 이 과정을 가속화하기 위해 노력하고 있다는 점이다.

모듈형 구조: 메인 계정과 모듈

위임 호출과 프록시 계약

외부 호출과 위임 호출:

delegatecall은 call과 유사하지만, 대상 계약을 자신의 컨텍스트에서 실행하는 것이 아니라 호출 계약의 현재 상태에서 실행한다. 즉, 대상 계약이 수행하는 모든 상태 변경은 호출 계약의 스토리지에 적용된다.

조합 가능하고 업그레이드 가능한 구조를 구현하려면 '프록시 계약(proxy contract)'이라는 기본 개념이 필요하다.

1. 프록시 계약: 일반 계약은 로직과 상태를 저장하며 배포 후에는 업데이트할 수 없다. 프록시 계약은 다른 계약을 delegatecall한다. 함수 구현을 참조하여 프록시 계약의 현재 상태에서 실행한다.

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

보안 아키텍처

Safe는 검증된 보안성과 유연성을 제공하는 선도적인 모듈형 스마트 계정 기반 구조로, 개발자가 다양한 애플리케이션과 지갑을 만들 수 있도록 한다. 주목할 점은 많은 팀들이 Safe 위에서 구축하거나 영향을 받고 있다는 것이다. Biconomy는 Safe 위에서 네이티브 4337과 1/1 멀티시그를 확장해 계정을 출시했다. Safe는 이미 164,000개 이상의 계약을 배포했으며 307억 달러 이상의 가치를 보유하고 있어, 이 분야의 명백한 선두주자임을 입증했다.

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이든 표준화는 특정 구현이나 생태계에 특화된 개발 작업을 줄이고 공급업체 잠금을 방지하는 데 도움이 된다.

모듈 발견과 보안

활발히 발전하는 해결책 중 하나는 사용자가 검증 가능한 모듈을 발견할 수 있는 공간을 만드는 것으로, 이를 '레지스트리(registry)'라고 부를 수 있다. 이 레지스트리는 단순하면서도 번성하는 모듈 시장을 촉진하는 '앱 스토어'와 유사하다.

Safe{Core} 프로토콜

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

• 계정: Safe{Core} 프로토콜에서 계정 개념은 유연하며 특정 구현에 국한되지 않는다. 다양한 계정 서비스 제공자가 참여할 수 있다.

• 매니저: 매니저는 계정, 레지스트리, 모듈 사이에서 조정자 역할을 하며, 권한 계층으로서 보안도 책임진다.

• 레지스트리: 레지스트리는 보안 속성을 정의하고 ERC6900과 같은 모듈 표준을 시행하며, 발견과 보안을 위한 개방형 '앱 스토어' 환경을 조성한다.

• 모듈: 모듈은 기능을 처리하며 플러그인, 훅, 서명 검증기, 함수 처리기 등 다양한 초기 유형으로 제공된다. 설정된 표준을 충족하면 개발자가 기여할 수 있다.

Rhinestone Design

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

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

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

• 모듈 증명 획득: 증명자/감사원은 패턴에 따라 모듈에 증명을 제공할 수 있다. 증명은 고유 식별자(UID)와 링크를 위한 기타 증명 참조를 포함할 수 있다. 체인 상에서 전파되며 목표 체인에서 특정 임계값이 충족되었는지 검증할 수 있다.

• 해석기를 통한 복잡한 로직 구현: 해석기는 패턴 내에서 선택적으로 설정할 수 있다. 모듈 생성, 증명 설정, 취소 과정에서 호출될 수 있다. 개발자는 증명 구조를 유지하면서도 복잡하고 다양한 로직을 통합할 수 있다.

• 사용자 친화적 조회 접근: 조회는 사용자가 프론트엔드를 통해 보안 정보에 접근하는 방법을 제공한다. 여기에서 EIP을 찾을 수 있다.

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

• 증명자: Safe와 같은 신뢰할 수 있는 엔티티는 내부 모듈의 증명자로서 Rhinestone과 협력할 수 있다. 동시에 독립 증명자들도 참여할 수 있다.

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

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

"모듈 레지스트리" 개념은 플러그인 및 모듈 개발자에게 수익 창출 기회를 제공한다. 또한 "모듈 시장"의 길을 열 수도 있다. 일부 분야는 Safe 팀이 감독할 수 있고, 다른 분야는 모두가 기여하고 투명한 감사 기록을 제공하는 탈중앙화 시장 형태일 수 있다. 이런 방식을 채택함으로써 공급업체 잠금을 피하고 더 나은 사용자 경험을 제공함으로써 EVM 확장을 지지하는 더 넓은 청중을 유치할 수 있다.

이러한 방법들은 개별 모듈의 보안을 보장하지만, 스마트 계약 계정 전체의 보안은 절대적이지 않다. 합법적인 모듈을 결합하고 스토리지 충돌이 없는지 증명하는 것은 도전 과제일 수 있으며, 이는 그러한 문제를 해결하는 데 있어 지갑이나 AA 인프라의 중요성을 강조한다.

결론

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

그러나 모듈형 스마트 계약 계정(SCA)은 채택 퍼즐의 일부에 불과하다. SCA의 잠재력을 충분히 실현하려면 L2 솔루션의 프로토콜 계층 지원, 강력한 번들러 인프라 및 P2P 메모리풀, 더 비용 효율적이고 실현 가능한 SCA 서명 메커니즘, 크로스체인 SCA 동기화 및 관리, 사용자 친화적 인터페이스 개발 등이 필요하다.

우리는 광범위한 참여를 예상하며 몇 가지 흥미로운 질문을 제기한다: SCA 주문 프로세스가 충분히 수익성이 있게 되면 전통적인 마이너 추출 가치(MEV) 메커니즘은 어떻게 영역에 진입하여 번들러를 구축하고 가치를 포착할 것인가? 인프라가 성숙할 때 계정 추상화(AA)가 '의도 기반(intent-based)' 트랜잭션의 기반 계층이 되는 방법은 무엇인가? 계속 지켜보자. 이 분야는 끊임없이 진화하고 있다.