원저자: Yuxing, SevenX Ventures
이 기사는 학습 및 커뮤니케이션 목적으로만 작성되었으며 투자 참고 자료가 아닙니다.
이더리움 애플리케이션 시나리오의 지속적인 확장 및 확장으로 인해 기존 이더리움 지갑의 외부 소유 계정(EOA) 솔루션의 단점이 점차 드러나고 있으며 기능은 간단하고 성능은 평균이며 동시 트랜잭션을 지원하지 않으며 핵심이 있습니다. 관리 문제 문제. 스마트 컨트랙트 지갑은 CA(Contract Accounts)를 지갑 주소로 사용하며, EOA 지갑의 단점을 해결하고 더욱 강력한 기능을 제공할 수 있는 비교적 새로운 이더리움 지갑 솔루션입니다. 미래에는 개인 키를 조심스럽게 보호하지 않아도 거의 동일한 수준의 보안을 누릴 수 있으며, 분산형 거래소에서도 현재 중앙형 거래소의 편리함을 누릴 수 있지만 동시에 자금은 항상 자신의 손에 있으므로 거래소에서 뇌우가 발생할 가능성에 대해 걱정할 필요가 없습니다...
얼마 전 공개된 이더리움 로드맵의 새 버전에서는 계정 추상화 스마트 계약 사양 ERC-4337이 EOA 지갑을 스마트 계약 지갑으로 전환하기 위한 핵심 요소로 The Splurge에 기록되었습니다. 그렇다면 스마트 계약 지갑이란 정확히 무엇이며 계정 추상화와 스마트 계약 지갑의 관계는 무엇이며 어떻게 구현되며 향후 개발 형태는 무엇이며 기회와 과제는 무엇입니까?
이더리움 계정 유형
이더리움에는 외부 소유 계정(EOA)과 계약 계정(CA)이라는 두 가지 유형의 계정이 있습니다. 외부 계정은 사용자 잔액을 기록하는 이더리움의 기본 지갑 계정 주소입니다. 계약 계정은 원래 사용자 지갑 주소 잔액을 기록하도록 설계되지 않았습니다.
외부 계정
EOA는 이더리움 및 기타 EVM 호환 체인(또는 EVM 유사 체인) 고유의 개념으로, 엄밀히 말하면 BTC를 비롯한 주류 비 EVM 체인에는 이러한 설정이 없습니다. 메타마스크 지갑은 외부 계정을 사용하며 이러한 유형의 지갑은 EOA 지갑이라고도 하며 사용자의 개인 키에 의해 제어됩니다. 생성 규칙은 다음과 같습니다.
개인 키 → 공개 키 → Keccak 256 해시 → 마지막 20바이트 → 16진수 문자열(EOA 주소)
이 생성 규칙은 완전히 수학적 변환에서 파생되며 이 주소는 어떤 스마트 계약과도 일치하지 않습니다. 거래에 이러한 유형의 주소를 사용할 때 노드 확인 규칙은 다음과 같습니다.
트랜잭션 서명 → ec_recover → 공개 키 → (위 규칙을 사용하여 생성) 주소 → 조작할 주소 비교
검증이 통과되면 후속 프로세스를 계속 진행하세요. 그렇지 않으면 거래가 거부됩니다. 이더리움에서 EOA의 핵심 설정은 트랜잭션의 개시자 역할과 가스 지불, 즉 트랜잭션의 트리거 역할을 하는 것입니다. 트랜잭션 뒤에 아무리 많은 계약 호출이 있어도 처음에는 EOA에 의해 시작되어야 하며 충분한 가스를 지불해야 합니다. EOA 주소의 거래 과정은 아래 그림과 같습니다.
단순화된 EOA 거래 메커니즘 출처: Nethermind
외부 계정 문제
현재 EOA 계정은 사용자가 사용하는 절대적으로 주류 지갑 유형입니다. Ethereum 커뮤니티는 다음을 포함하여 EOA에 대해 여러 가지 우려를 표명했습니다.
• 키 관리: 자금을 얻을 수 있는 유일한 방법은 개인 키를 아는 것입니다.가장 큰 문제는 단일 실패 지점입니다.사용자에게 개인 키는 자산입니다. 사용자에게 개인 키가 분실되거나 도난당하면 이는 자산 손실을 의미합니다.
• ECDSA 서명에 대한 의존: 더욱 간단하고 양자에 강한 디지털 서명은 현재 ECDSA에 비해 확실히 개선되었습니다.
• 트랜잭션은 작업과 일대일로 진행됩니다. 여러 작업을 동시에 수행할 수 없으면 불필요한 비용이 발생하고 사용자 경험이 저하됩니다.
블록체인 적용 시나리오가 지속적으로 확장됨에 따라 사용자는 블록체인에서 자신의 온체인 자산뿐만 아니라 온체인 신원, 사회적 관계, 심지어 온체인 크레딧 등도 관리합니다. 현재 이러한 컨텐츠의 대부분은 단순히 지갑을 통해 유사 익명의 개인에게 매핑되어 있으며, 사용자들은 니모닉 기반의 EOA 지갑 개인키 관리 솔루션으로 인해 어려움을 겪고 있을 뿐만 아니라, EOA 지갑의 단순성으로 인해 많은 애플리케이션에 적용되고 있습니다. 장면이 제한되어 있습니다.
이러한 문제를 해결하기 위한 많은 지갑 솔루션이 있습니다:
• 단일 실패 지점 주변에서 MPC 지갑은 임계값 서명 체계(TSS)를 사용하여 더 나은 개인 키 관리 솔루션을 제공하는 반면, 스마트 계약 지갑은 소셜 복구, 다중 서명 및 기타 솔루션을 통해 이 문제를 해결할 수 있습니다.
• 더 나은 사용자 경험, 더 강력한 기능 및 확장성(예: 일괄 트랜잭션, 사용자 정의 검증 로직 등)은 주로 스마트 계약 지갑을 통해 제공됩니다.
MPC 지갑과 스마트 계약 지갑은 완전히 독립적인 솔루션이 아닙니다.스마트 계약 지갑은 MPC+TSS 기술을 사용하여 스마트 계약 지갑을 관리할 수도 있습니다.Unipass가 좋은 예입니다.
참고: MPC 지갑은 다자간 보안 컴퓨팅 기술을 사용하는 지갑을 말하며 자산 보관을 위해 M 명의 관리인을 고용하는 것과 같습니다. 각 관리인은 독립적으로 저장소를 열 수 없으며 TSS(Threshold Signature Scheme)를 사용하는 것은 자산 보관을 제공하는 것과 같습니다. 귀하의 금고는 N개의 키가 필요한 잠금 장치로 설정되어 있으며, MPC + TSS 지갑 솔루션은 다중 역할 금고 관리 솔루션을 제공하는 것과 같습니다.M명의 관리자 중 N명의 관리자가 동시에 관리하는 키를 제공해야 합니다. 시간 금고를 여는 능력.
계약계좌
CA는 비즈니스 로직(토큰 계약은 회계에 사용되고 서약 계약은 대출 및 청산에 사용됨) 또는 계정 로직(예: gnosis safe의 다중 서명 로직)일 수 있는 내부 로직을 갖춘 이더리움 계정입니다. 스마트 계약 지갑/계정(SCW)입니다. Argent 지갑은 사회 회복 모델을 개척한 스마트 계약 지갑을 사용하며 계약은 내부 논리 코드에 의해 제어되며 생성 규칙에는 CREATE 및 CREATE 2가 포함되어 있으므로 여기서는 논의하지 않습니다.
EOA와 달리 CA와 공개 키 간에는 필요한 대응 관계가 없습니다. 예를 들어, gnosis safe가 생성한 CA는 자신의 주소에 해당하는 자산을 잠금 해제하기 위해 공개 키를 원하는 만큼 설정할 수 있습니다. 물론 CA도 키를 설정할 수 없지만 잠금 해제 가능 여부는 다른 CA의 로직에 따라 결정됩니다. DeFi와 같은 대출 계약을 통해 돈을 상환하는 한 담보 자산을 돌려받을 수 있습니다.
ETH를 제외한 이더리움의 모든 자산은 CA에 의해 운반되며 DeFi와 같은 비즈니스 로직은 모두 CA에 의해 구현됩니다. 그러나 CA가 적극적으로 운영하고 가스비를 지불할 수 없다는 설정도 CA의 역량을 제한합니다.이르면 2016년부터제안CA가 가스 비용 자체를 지불할 수 있기를 바랍니다.
스마트 컨트랙트 지갑 거래 출처: Nethermind
거래는 EOA에서만 시작될 수 있으므로 사용자 경험을 개선하기 위해 스마트 계약 지갑은 일반적으로 사용자로부터 서명된 메시지를 받고 서비스 제공자로부터 EOA를 체인에 제출하는 중계 서비스를 제공합니다. 맞춤형 수수료 메커니즘은 ETH를 사용자에게 반환할 수 있습니다. EOA 지갑은 가스 수수료가 없습니다.
현재 스마트 계약 지갑에 대한 운영 표준(EIP-4337이 표준이 될 예정)이 없으므로 모든 프로젝트는 Ethereum Gas Station Network(GSN)과 같은 메타 거래 솔루션을 사용하거나 스마트 계약 지갑을 생성하고 관리하기 위해 노력해야 합니다. 자체 중계 서비스를 제공할 뿐만 아니라 수수료 메커니즘을 관리하고 복잡한 스마트 계약을 감사합니다.
스마트 계약 지갑
SCW(Smart Contract Wallet/Account)는 이름에서 알 수 있듯이 CA를 주소로 사용하는 지갑 솔루션으로 내부 로직이 특징이며 가스 결제, 일괄 트랜잭션 등 EOA가 달성할 수 없는 많은 기능을 스마트 계약 지갑에서 구현할 수 있습니다. , 다중 서명, 권한 관리, 오프라인 인증, 소셜 복구 등이 있습니다.
계약 계정은 서명자(승인자)와는 별개의 스마트 계약이며 자체 서명 및 복구 논리를 가질 수 있습니다. 즉, Signer에 액세스할 수 없다고 해서 반드시 계정에 액세스할 수 없다는 의미는 아닙니다. 여기서도 Account Abstraction이라는 이름이 유래되었습니다. 계정은 서명자로부터 추상화됩니다.
계정 추상화
현재 이더리움의 상태는 대다수의 사람들이 EOA 지갑을 사용하고 있다는 점입니다. 현재 이더리움의 모든 거래는 EOA로 시작해야 하고, EOA는 가스비를 지불하기 위해 일정량의 ETH를 보유해야 하기 때문에 신규 사용자가 빠르게 진입할 수 없기 때문입니다. 임의의 검증 로직이 포함된 스마트 계약 지갑을 사용자가 사용할 수 있도록 하는 솔루션이 필요하며, 이 솔루션을 Account Abstract(AA)라고 합니다.
간단히 말해서 계정 추상화의 결과는 다음과 같습니다.
과거에는 이더리움 EOA 지갑 주소에 돈을 보관했는데, 다양한 EOA 주소에 제한을 받으면서 개인키로 자산을 소유하는 간편함과 편리함도 누렸습니다.
이제 이더리움 스마트 계약 주소에 돈을 보관하므로 개인 키를 관리하지 않고도 지갑 자산을 제어할 수 있습니다. 서명자와 계정 자체를 분리하면 낮은 보안 수준에서 거래 작업을 수행할 수 있습니다. 계정 자체는 다음 위치에 배치됩니다. 더 높은 보안 수준.
계정 추상화의 목표는 계정 유형 수를 2개(EOA 및 계약)에서 1개(계약만)로 줄이고 서명 검증, 가스 지불, 재생 공격 보호 등의 기능을 핵심 프로토콜에서 EVM . EIP의 역사에서 볼 수 있듯이 계정 추상화를 구현하는 것은 항상 많은 이더리움 개발자들의 노력이었습니다.
EIP 연혁
계정 추상화 개념은 Vitalik이 2016년에 처음 제안했으며, 2017년에 첫 번째 제안을 시작했습니다. 수년에 걸쳐 계정 추상화와 관련된 많은 제안이 있었으며 그 중 가장 중요한 것은 EIP-3074 및 EIP-4337입니다. EIP-3074는 EIP-4337보다 1년 먼저 제안되었지만 EIP-4337은 새 버전의 이더리움 로드맵에 포함되었습니다. 주된 이유는 EIP-4337의 구현이 더 가볍고 수정이 필요하지 않기 때문입니다. 이더리움 프로토콜의 핵심이며 EIP-3074와 같은 보안 위험이 없습니다. EIP-4337의 사용자 마이그레이션 문제, 과도한 가스 문제 및 잠재적인 스마트 계약 보안 문제는 스마트 계약 지갑의 일반적인 문제입니다. Vitalik은 계정 추상화를 위한 가장 현실적인 방법은 단기적으로 ERC-4337을 적극적으로 지원하기 시작하는 것이라고 믿습니다. 그런 다음 약점을 보완하기 위해 Over time EIP가 추가되었습니다.
계정 요약 EIP 내역
EIP-86: 2017년 Vitalik은 전달 계약으로 간주할 수 있는 스마트 계약 지갑을 도입하려는 시도로 EIP-86을 제안했습니다. 이러한 전달 계약은 특정 형식을 따르는 한 누구나 거래를 보낼 수 있는 진입 지점 주소의 거래만 허용합니다.
EIP-1014: 이러한 전달 계약은 코드를 기반으로 특정 주소에 배포되며 나중에 CREATE 2 opcode를 제안하는 EIP-1014로 발전한 아이디어를 도입합니다. EIP-86은 프로토콜에 상당한 변경이 필요했기 때문에 결국 병합되지 않았지만 EIP-1014는 2018년에 병합되었습니다.
EIP-2938: 2020년 9월 Vitalik Buterin, Ansgar Dietrichs 및 Matt Garnett는 스마트 계약 지갑으로 식별된 특수 스마트 계약이 계정 추상 거래만 허용하도록 요구하는 EIP-2938을 제안했습니다. 이 새로운 유형의 거래는 EIP-에서 지원됩니다. 2718이 도입되었습니다. 그들은 프로그래밍 방식으로 거래에 대한 최대 가스를 설정하고 임의의 검증 방법을 구현합니다. EIP-2938 트랜잭션을 실행하려면 두 개의 새로운 opcode를 EVM에 추가해야 합니다. 이러한 opcode는 핵심 프로토콜을 크게 변경하며 이러한 변경 사항을 통합하는 프로세스는 시간이 오래 걸릴 수 있습니다.
EIP-3074: 2020년 10월 Ansgar Dietrichs, Matt Garnett 등은 AUTH 및 AUTHCALL이라는 두 가지 새로운 opcode를 도입한 EIP-3074를 제안했습니다. 함께 사용하면 스마트 계약을 통해 EOA를 대신하여 트랜잭션을 보낼 수 있으며, 예를 들어 다중 서명, 일괄 및 후원 트랜잭션, 키 복구, CeFi 거래소에서 더 쉽게 접근할 수 있는 예금 등이 가능해집니다. 그러나 이 EIP에는 보안상의 위험이 있었고 일부 비판도 있었습니다. 새로운 운영 코드는 핵심 프로토콜도 수정하게 되므로 연구원들은 더 나은 솔루션을 고민하기 시작했고 이는 결국 EIP-4337로 제안되었습니다.
EIP-3074 트랜잭션 프로세스 소스: Nethermind
레이어 2: 이후 L2에는 Ethereum L1의 기술적 부채가 없기 때문에 계정 추상화를 즉시 도입할 수 있습니다. Optimism과 Starknet 모두 자체 계정 추상화 구현을 가지고 있습니다. ArgentX는 영향을 받는 버전을 사용하는 Starknet의 Argent 지갑 버전입니다. EIP-4337 영감을 받은 맞춤형 계정 추상화 구현. 가장 최근의 예는 StarkNet의 Visa 암호화폐 자동 결제입니다. Visa의 이더리움 자동 결제 솔루션은 계정 추상화 개념을 활용하고 새로운 유형의 계정 계약(위임 계정)을 생성합니다. 주요 아이디어는 프로그래밍 가능한 거래 유효성 규칙을 사전 포함으로 확장하는 것입니다. -승인된 허용 목록. 간단히 말해서, 계정 추상화는 사용자 계정에 의해 시작된 자동 결제 작업을 사전 승인된 자동 결제 스마트 계약에 위임할 수 있습니다. StarkNet의 계정 모델은 Visa가 현재 계정 추상화라고 부르는 것입니다. 구현은 ERC-4337에서 영감을 얻었습니다. 추상 계정은 거래가 특정 주소에서 오는지 여부를 확인합니다.
Visa는 StarkNet에서 계정 추상화를 구현합니다.
EIP-4337: 2021년 9월 Vitalik Buterin과 OpenGSN 및 Nethermind의 Ethereum 연구원들은 이전 노력의 교훈을 배우고 EIP-4337을 제안했습니다. EIP-4337은 계정 추상화를 달성하기 위해 현재 트랜잭션 메모리 풀을 완전히 교체하기 위해 새로운 UserOperation 메모리 풀을 추가합니다. 사용자는 UserOperation 개체를 Ethereum 노드로 보내고, 트랜잭션 대신 이러한 개체 집합을 Ethereum 체인에 포함된 트랜잭션으로 패키징합니다. 이 패키지된 트랜잭션을 진입점 스마트 계약이라고 하며, UserOperation 개체를 처리하고 여기에 스마트 계약 지갑을 배포합니다.
ERC-4337 트랜잭션 프로세스 소스: Nethermind
EIP-5003: 2022년 3월 Dan Finlay, Sam Wilson은 외부 계정 대신 코드를 배포하여 ECDSA에서 마이그레이션할 수 있기를 희망하면서 EIP-5003을 제안했습니다. 이 EIP는 EIP-3074 인증 주소 AUTHUSURP에 코드를 배포하는 새로운 opcode를 도입합니다. EIP-3607과 함께 외부 소유 계정(EOA)의 경우 이는 원래 서명 키의 권한을 효과적으로 취소합니다. 이는 추가 참가자 권한만 부여할 수 있지만 취소할 수는 없는 EIP-3074에 추가됩니다.
EIP-5792: 2022년 10월, Moody Salem은 사용자 지갑에서 여러 함수 호출을 보내고 상태를 확인하기 위한 JSON-RPC 방법을 추가하는 EIP-5792를 제안했습니다. 새로운 접근 방식은 EIP-4337을 사용하는 스마트 계약 지갑 또는 EIP-3074를 통해 번들 거래를 지원하는 EOA 지갑과 같은 지갑 구현 간의 차이를 허용하기 위해 기존 거래 전송 API보다 기본 거래 측면에서 더 추상적입니다. Dapp은 이 보다 추상적인 인터페이스를 사용하여 추가 작업 없이 다양한 유형의 지갑을 지원하고 함수 호출 패키지(예: EIP-20 #approve 다음에 계약 호출)를 보내는 데 더 나은 사용자 경험을 제공할 수 있습니다.
EIP-4337 상세설명
EIP-4337에는 EntryPoint 계약, Paymaster 계약, UserOperation, Bundler, Sender 계약 및 Aggregator(Aggregator) 등 총 6개의 구성 요소가 있습니다.
EntryPoint: 진입점 계약은 전달된 트랜잭션 작업의 실행 및 확인을 처리합니다. 전역 진입점 계약은 다양한 번들러로부터 패키지된 트랜잭션을 수신하고 각 UserOperations를 통해 유효성 검사 및 실행 루프를 실행합니다.
Paymaster: 사용자를 대신하여 거래에 대한 가스를 지불할 수 있는 선택적 계약입니다. 사용자는 지갑에 의존하는 대신 창구 직원이 후원하는 거래 수수료를 받습니다.
UserOperations: 사용자를 대신하여 트랜잭션을 수행하기 위해 생성된 트랜잭션 개체입니다. 발신자 계약 확인 후 실행이 발생합니다. 이러한 작업은 Dapp에 의해 생성됩니다.
번들러: 번들러는 메모리 풀에서 UserOperations를 가져와 함께 패키징하여 실행을 위해 EntryPoint 계약으로 보냅니다.
발신자 계약: 스마트 계약 형태의 사용자 지갑 계정입니다.
집계자(Aggregator): 집계자는 지갑에서 신뢰하는 보조 계약이며 집계 서명을 확인하는 데 사용됩니다.
전체 ERC-4337 표준 운영 로직에는 확인 루프와 실행 루프라는 두 개의 루프가 포함되어 있으며 결합되어 계정 추상화 로직을 완성합니다.
검증 루프:진입점 계약은 각 UserOperation을 거치며 보낸 사람 계약의 확인 기능을 호출합니다. Sender Contract는 이 기능을 실행하여 UserOperation의 서명을 확인하고 이러한 거래를 패키징한 Bunder에게 보상합니다.
실행 루프:각 UserOperation의 호출 데이터를 발신자 계약으로 보냅니다. 지갑은 작업에 지정된 트랜잭션을 수행하기 위해 실행 작업을 실행합니다. 송신자 계약은 작업이 실행된 후 남은 가스를 반환합니다.
검증 루프 및 실행 루프 출처: EIP-4337
도입된 계산원 역할을 통해 애플리케이션 개발자는 사용자에게 수수료를 보조할 수 있습니다. paymaster가 0 주소와 같지 않으면 진입점은 다른 프로세스를 실행합니다.
텔러를 위한 검증 루프 및 실행 루프 소개 출처: EIP-4337
검증 루프에서 체크 기능을 호출하는 것 외에도 진입점 계약은 페이마스터가 스테이킹되어 있는지, 운영 수수료를 충당할 만큼 충분한 ETH가 진입점 계약에 예치되어 있는지 확인해야 합니다. 그런 다음 수표를 호출해야 합니다. 기능을 사용하여 해당 페이마스터가 지불할 의향이 있는지 확인하세요.
실행 루프에서 진입점 계약은 기본 실행 호출 후 paymaster에서 사후 작업을 호출해야 합니다. 내부 호출 환경에서 Main 수행을 하여 Post-op 수행을 보장해야 하며, 내부 호출 환경이 롤백되면 외부 호출 환경에서 다시 Post-op 호출을 시도한다. 사용자 작업 롤백 비용).
Vitalik은 ERC-4337이 순전히 자발적인 ERC로서 많은 일을 할 수 있다고 결론지었습니다. 그러나 일부 핵심 영역에서는 실제 프로토콜 내 솔루션보다 약합니다.
사용자 마이그레이션 문제, 기존 사용자는 모든 자산과 활동을 새 계정으로 이동하지 않고는 업그레이드할 수 없습니다.
추가 가스 오버헤드(기본 UserOperation 사용자 작업은 약 42k, 기본 트랜잭션은 약 21k)
트랜잭션을 대상으로 하고 사용자 작업을 무시하는 프로토콜 내 검열 저항 기술(예: crLists)의 이점이 적은 스마트 계약 보안 문제
최상의 결과를 얻는 현실적인 방법은 단기적으로 ERC-4337을 강력하게 지원하기 시작한 다음 시간이 지남에 따라 EIP를 추가하여 약점을 보완하는 것입니다. 이는 ERC-4337을 준수하기 위한 구체적인 약속을 반드시 요구하지는 않습니다. 대신, 프로토콜 내 지원은 보다 일반적이고 ERC-4337과 그 대안 및 개선 사항을 지원하도록 설계될 수 있습니다. 현재 ERC-4337 구현 솔루션에는 Biconomy, Soul Wallet 및 eth-infinitism이 포함되며 모두 자체 진입점 계약 구현 솔루션을 작성했으며 진입점 계약은 이 표준에 따른 스마트 계약 보안의 핵심입니다.
Vitalik은 계정 추상화 가능성을 제안했습니다.노선지도 。
단기
ERC-4337을 정식 생산에 투입합니다. 이상적으로는 롤업 친화성을 달성하기 위해 서명 집계 기능을 사용하여 확장할 수 있습니다.
ERC-4337과 인터페이스하는 사용하기 쉬운 브라우저 지갑이 있어야 합니다.
ERC-4337을 보다 L2 친화적으로 만들기 위해 서명 집계 및 압축 구현을 고려하십시오.
가스 비용 문제가 적은 L2 프로토콜에서 ERC-4337 생태계를 안내합니다.
중기
Verkle 트리를 구현하고 EIP를 추가하여 가스 비용을 절감합니다.
선택적 EOA-ERC-4337 변환을 추가합니다.
제안자/빌더 분리(PBS) 롤아웃 직후 또는 동시에 crList 논리를 추가합니다.
긴
캐스팅, 불규칙한 상태 전환 수행, EOA일 수 있는 모든 계정에 바이트코드 배포를 고려하세요. 하지만 이 접근 방식의 단점은 핵심 프로토콜을 수정해야 하고 채굴자/검증자에 대한 높은 비용이 든다는 것입니다.
프로젝트 스캔
SevenX Ventures는 시장에 있는 스마트 계약 지갑에 대한 간단한 스캔을 수행하고 시장에 있는 보다 주류인 스마트 계약 지갑 프로젝트 중 일부를 수집했습니다. 종합적인 상황은 다음과 같습니다.
구현사례
사례소개를 위해 2개의 프로젝트를 선정하고 각각의 기능과 그에 따른 구현원리를 분석하였다. 그 중 Unipass는 전통적인 스마트 컨트랙트 지갑의 대표적인 대표자이고, Candide Wallet은 ERC-4337 표준을 사용하는 지갑의 대표적인 대표자로, 제품 기능 구현을 자세히 설명하는 풍부한 공개 문서를 보유하고 있습니다.
Unipass
UniPass Wallet은 이메일 소셜 복구를 지원하는 스마트 계약 지갑 솔루션입니다. UniPass Wallet을 통해 개발자는 제품 내에서 개인 키가 없고 가스가 없는 원활한 사용자 경험을 제공할 수 있으며 이를 통해 많은 Web2 사용자를 빠르게 유치할 수 있습니다. 그 기능은 다음과 같습니다: 개인 키 없음, 검열 방지, 가스 없음, 이메일 복구, 개인 정보 보호, 다중 플랫폼 및 다중 체인 지원.
개인 키 없음, 검열 저항, 이메일 복구 및 개인 정보 보호 기능은 주로 Unipass의 키 관리 솔루션에서 가져옵니다. UniPass Wallet의 계약 계정은 사용자가 여러 유형의 키를 설정할 수 있도록 지원합니다. 이미 지원되는 키 유형은 다음과 같습니다.
우리가 자주 사용하는 외부 주소는 EIP-1271 프로토콜(계약의 표준 서명 확인 방법)을 지원하는 계약 계정입니다.
UniPass 사용자는 이메일 주소를 키로 사용할 수도 있습니다. 체인에 배포된 스마트 계약은 DKIM(도메인 이름 키 식별 메일)을 통해 인터넷 사서함에 대한 사용자의 소유권을 암호화 방식으로 확인할 수 있습니다.
확인 과정에서 UniPass는 영지식 증명 기술을 사용하여 사용자 이메일 정보의 개인정보 보호와 보안을 보장합니다.
앞으로 UniPass Wallet은 secp 256 k 1(예: Schnorr, BLS), 포스트퀀텀 보안 서명 알고리즘(예: Lamport, Winternitz)보다 더 효율적이고 간단한 서명 알고리즘 지원도 고려할 것입니다.
비밀 키에는 세 가지 주요 역할이 있습니다.
소유자는 계정의 소유자입니다. 소유자는 계정의 배포, 업그레이드, 파괴 및 기타 핵심 기능을 제어하며 계정의 최고 권한 컨트롤러입니다.
운영자는 계정 자산의 집행자입니다. 운영자는 계정의 자산 이전, 계약 호출, 승인 및 기타 기능을 담당하며 사용자가 매일 사용하는 키입니다.
Guardian은 계정의 보호자입니다. 계정의 키가 손상되거나 분실되어 사용자가 계정에 대한 통제권을 상실한 경우 보호자를 활용하여 계정을 복원할 수 있습니다. UniPass가 제공하는 주요 기능은 온체인 이메일 소셜 복구입니다.
UniPass Wallet의 스마트 계약에서 사용자는 역할 가중치가 있는 일련의 키를 통해 계정을 관리합니다. 보안 다자간 계산(MPC) 방식으로 구현된 마스터 키 외에도 사용자는 다양한 유형의 키를 설정할 수도 있습니다. 각 키에는 해당 역할과 가중치가 있습니다. 사용자는 전체 역할 가중치 임계값이 요구 사항을 초과하는 키를 수집한 후에만 이 역할에 대한 권한을 얻을 수 있습니다.
키에는 단일 또는 여러 역할이 할당될 수 있습니다. 키에 역할이 할당되면 해당 가중치도 동시에 설정됩니다. 사용자가 특정 ID와 관련된 작업 수행을 시작하려면 역할의 총 가중치가 100 이상에 도달하는 단일 또는 다중 키로 서명해야 합니다. 예를 들어, 처음 계정을 등록할 때 사용자는 보호자 설정을 건너뛸 수 있습니다. 관련 매개변수는 다음과 같이 설정할 수 있습니다.
가스 프리 기능은 제3자 중계기를 통해 구현되며, 사용자가 거래를 시작할 때 중계기는 사용자가 거래를 시작할 수 있도록 도와줍니다. 이 과정에서 Relayer는 사용자가 어떤 토큰을 사용하여 가스를 지불하도록 지원할 수 있으며 사용자가 가스를 대신 지불하도록 완전히 도와 가스 없는 경험을 달성할 수도 있습니다. Relayer는 오픈 소스 서버 프로그램으로 UniPass가 기본 Relayer를 실행하며, 파트너나 제3자도 Relayer를 실행할 수 있습니다.
Candide
CANDIDE는 단일 단체나 회사가 개발을 통제하지 않고 기여자 그룹에 의해 공동으로 공개적으로 구축된 공개 제품입니다. Candide Wallet Beta는 자체 호스팅 모바일 스마트 계약 지갑입니다. 현재 Goerli 테스트넷에 배포되어 있습니다. 이제 Android 테스트 및 IOS Testflight에서 사용할 수 있습니다.
Candide Beta의 기술적 기반은 Stackup 포크의 ERC-4337 구현과 Gnosis Safe의 오픈 소스 프레임워크이며, 무언어, 소셜 복구, 일괄 트랜잭션 및 가스 요금 없음이 특징입니다.
그 중 노노트 워드, 일괄 트랜잭션, 가스비 없음 등의 기능 구현 로직은 ERC-4337과 동일하며, eth-infinitism에서 개발한 진입점 컨트랙트를 사용해 완성된다. Candide는 자체 패키저를 실행하고 UserOperation을 자체 지갑용 서비스로 패키징합니다. 이 솔루션에서는 대부분의 보안이 지갑 자체의 구성보다는 진입점 계약에 있습니다.
또한 소셜 복구 기능은 Candide가 기본 지갑 계약에 Safe를 사용하는 데서 비롯됩니다. 이를 통해 Candide는 가장 신뢰할 수 있는 DAO 계약을 활용하여 디지털 토큰을 관리할 수 있습니다. Candide는 Gnosis Safe 모듈식 설계를 사용하여 사회적 회복을 포함한 핵심 기능은 물론 시간 잠금 및 출금 제한과 같은 미래 기능을 제공할 것입니다. 이 소셜 복구 모듈은 Unipass가 주로 이메일 복구를 위한 것이라는 점을 제외하면 Unipass와 동일한 논리를 가지고 있지만 Candide의 보호자는 가족 친구, 기관 및 하드웨어 지갑과 같이 공개 주소를 가진 모든 서명자가 될 수 있습니다.
계약 지갑에 대한 생각
초기 스마트 계약 지갑은 Gnosis Safe의 다중 서명 및 Argent의 소셜 복구 기능과 같은 매우 구체적인 문제를 기반으로 개발되었습니다. 이러한 초기 제품은 디자인이 복잡하고 개방적이지 않고 투명하지 않은 경우가 많았으며 통일된 표준을 형성하지 않아 다른 애플리케이션에 미들웨어로 삽입하기가 어려웠습니다. 이러한 유형의 제품에 대해서는 사용 시나리오와 그것이 사용자의 핵심 요구 사항을 포착하는지 여부에 따라 판단 기준이 더 높아져야 합니다.예를 들어 Safe의 다중 서명 기능은 사용자의 핵심 요구 사항 중 하나를 포착합니다.
ERC-4337의 탄생으로 단어도 없고, 일괄 트랜잭션도 없고, 가스비도 없는 지갑을 빠르게 구축하는 것이 매우 편리해졌습니다.통합 표준은 또한 이 표준을 기반으로 구축된 개발 키트를 컴포저블하게 만들어 중개자 역할을 할 수 있습니다. 소프트웨어는 다른 애플리케이션에 연결되며 상호 운용이 가능합니다.
따라서 초기 스마트 지갑 솔루션을 고려할 때 ERC-4337과 호환되는 것이 매우 중요합니다. ERC-4337 기반 솔루션의 경우 대부분의 기술이 오픈 소스이므로 다음 사항에 중점을 두고 고려하는 것이 좋습니다.
기술: 진입점 계약, 패커 및 수집기(있는 경우)를 구축하는 방법, 소셜 복구 기능과 같은 ERC-4337이 제공하는 것 이상의 기능을 구축하는 방법
운영: 커뮤니티 구축, 시장 진출, 사용자 확보 방법
경험: 부드러움, 안정성 등 지갑 사용에 대한 사용자 경험이 충분한지 여부
그리고 다른 C 제품의 주요 검사 로직
미래의 지갑 모델은 B2B2C 모델과 유사할 가능성이 높습니다. 지갑이 C-end 제품으로 존재하지만, 다른 애플리케이션이 인앱 지갑에 통합되어 C-end 사용자를 대상으로 할 수 있도록 성숙한 SDK 솔루션을 제공하는 것이 더 중요합니다. 그 중 패커(Packer)와 애그리게이터(Aggregator)는 초기에는 주로 중앙 집중식으로 구축되었으나 나중에는 모듈식 네트워크를 형성하는 것도 가능하지만 이 부분이 가치 포착의 핵심이기 때문에 타인이 구축한 패커 네트워크를 활용한 지갑은 갈 필요가 있다. 경제적 이익의 게임을 통해..
