2024년 7월 18일, SSP Wallet v1.6.0이 Ethereum을 추가했고 — SSP는 ERC-4337 Account Abstraction을 사용해 Ethereum 위에 진정한 Schnorr-multisig 계정을 출시한 최초의 지갑이 되었습니다. 다른 지갑들은 단일 외부 소유 계정을 UI 뒤에 쌓아 놓고 스스로를 "Ethereum multisig"라고 부릅니다. SSP는 더 어려운 길을 선택했고, 그래서 SSP 안에서 Bitcoin을 지키는 같은 2-of-2 모델이 이제 ETH도 지킵니다.
TL;DR
- Ethereum(ETH)이 일급 체인으로 SSP에 합류합니다.
- 계정은 EOA가 아니라 ERC-4337을 따르는 스마트 컨트랙트입니다 — 그래서 2-of-2 강제가 체인 위에 살아 있습니다.
- 두 개의 Schnorr 서명이 Ethereum에 도달하기 전에 하나로 집계되어 가스 비용을 예측 가능하게 유지합니다.
- 서명 라이브러리는 npm에 오픈 소스로 공개되어 있습니다:
@runonflux/aa-schnorr-multisig-sdk. - ERC-20 토큰 지원이 다음 단계이며, 이번 릴리스는 ETH 자체와 그 아래의 AA 기반을 함께 제공합니다.
무엇이 도착했는가: Ethereum 지원, 어려운 방식으로
대부분의 지갑은 외부 소유 계정(EOA)을 생성하는 방식으로 "Ethereum을 지원"합니다 — 단일 개인키, 단일 서명, 단일 장애점. 그 위에 multisig를 얹는 것은 보통 지갑 측의 소프트웨어 정책일 뿐, 체인에서 강제되는 규칙이 아닙니다. 체인은 여전히 키 하나만 보고, 그 키를 가진 자는 혼자서 자금을 옮길 수 있습니다.
SSP는 그 지름길을 거부했습니다. SSP의 2-of-2 모델의 핵심은 데스크톱의 SSP Wallet도, 휴대폰의 SSP Key도 혼자서는 자금을 움직일 수 없다는 점입니다 — 공동 서명은 계정의 속성이지, UI 관례가 아닙니다. 이를 Ethereum 위에서 유지하려면, EOA는 결코 충분하지 않았습니다. Ethereum 계정은 구조적으로 두 개의 서명을 요구하는 스마트 컨트랙트여야 했습니다. v1.6.0에서 출시된 것이 바로 그것입니다.
여기서 Schnorr multisig가 의미하는 것
Bitcoin의 UTXO 스크립트는 2-of-2를 네이티브로 표현할 수 있습니다 — SSP의 기존 체인들이 공동 서명을 강제하는 방식이 그것입니다. Ethereum의 계정 모델은 그것을 할 수 없습니다 — 도움 없이는요. SSP는 Schnorr 서명으로 그 간극을 메웁니다.
Schnorr는 여기에서 중요한 한 가지 성질을 가진 서명 방식입니다: 두 서명자가 각각 부분 서명을 생성할 수 있고, 그 부분들을 단일의 유효한 서명으로 결합하여 하나의 집계된 공개키 아래 검증할 수 있습니다. 체인을 읽는 누구에게나 단일 서명자가 한 번 서명한 것처럼 보입니다. SSP에게는 두 기기가 동의해야 했습니다. 암호학적 깊이 — 키 집계, 논스 조정, MuSig2 스타일의 라운드 — 는 우리 아카데미 글 Schnorr 서명과 multisig 집계에서 다룹니다, 필요하다면요. 사용자 관점의 요약은 짧습니다: 이미 쓰고 있는 같은 SSP Wallet + SSP Key 핸드셰이크가, 이제 Ethereum 위에서 하나의 집계된 Schnorr 서명으로 표현된다는 것입니다.
ERC-4337 Account Abstraction
Account Abstraction(AA)은 Ethereum 계정이 단순한 키 쌍이 아니라 프로그래밍 가능한 지갑처럼 동작하도록 허용하는 우산 용어입니다. 표준 Ethereum 모델에는 두 가지 계정 유형이 있습니다: 단일 개인키로 통제되는 EOA, 그리고 스스로 트랜잭션을 시작할 수 없는 컨트랙트입니다. AA는 그 구분을 애플리케이션 계층에서 해소합니다.
ERC-4337은 Ethereum 자체를 바꾸지 않으면서 AA를 전달하는 Ethereum 표준입니다. 하드포크 대신 UserOperation이라는 상위 트랜잭션 객체, 그것을 일반 Ethereum 트랜잭션으로 변환하는 bundler, 그리고 그것을 검증하는 EntryPoint 컨트랙트를 정의합니다. 당신의 "계정"은 지출을 어떻게 인증할지 스스로 결정하는 스마트 컨트랙트입니다 — SSP에게 그 인증 규칙은: SSP Wallet과 SSP Key에서 온 집계된 Schnorr 서명, 그렇지 않으면 거부, 입니다. L1 하드포크 불필요, 특수 노드 운영자 불필요, 이미 메인넷에 배포된 것 외에는 어떤 신뢰 가정도 없음.
오픈 소스 라이브러리
Schnorr-multisig 서명 계층은 SSP 앱 내부에 묻혀 있지 않습니다. 우리는 그것을 재사용 가능한 라이브러리로 분리하여, SSP의 나머지와 같은 오픈 소스 자세로 공개했습니다. TypeScript SDK는 npm에 @runonflux/aa-schnorr-multisig-sdk로 살아 있고, 그와 짝을 이루는 Solidity Account Abstraction 컨트랙트들은 GitHub의 @runonflux/account-abstraction 저장소에 살아 있습니다.
당신이 지갑 개발자, 보안 연구자이거나, 혹은 단지 Schnorr-multisig AA가 Ethereum 위에서 실제로 어떻게 조립되는지가 궁금하다면, 두 프로젝트 모두 읽고, 포크하고, 다시 기여할 수 있도록 거기에 있습니다. Pull Request와 이슈 모두 환영합니다 — 이 프리미티브를 원하는 모든 지갑이 매번 바퀴를 재발명하게 두는 것보다, 더 많은 눈이 닿는 하나의 공유 라이브러리를 단단하게 다지는 편을 선호합니다.
이것이 열어주는 것
특별히 v1.6.0의 경우 제공되는 체인은 Ethereum 자체입니다 — ETH 잔액, ETH 전송, 다른 모든 코인에서 쓰는 같은 Chains 패널 토글, 이제 그 뒤에 AA 계정이 자리합니다. 이 릴리스가 깔아 놓은 배관이야말로 더 어려운 부분입니다. 일단 2-of-2 Schnorr AA 계정들이 존재하고 작동하면, Ethereum 모양의 어떤 잔액이든 도달 가능해집니다.
ERC-20 토큰 지원은 자연스러운 다음 단계이며 이미 로드맵에 있습니다 — 출시될 때 별도의 newsroom 글에서 다루겠습니다. 오늘의 헤드라인은: Ethereum이 SSP 안에 있고, 올바른 방식으로 SSP 안에 있으며, 그 아래의 암호학적·스마트 컨트랙트 기반은 npm과 GitHub에 오픈 소스로 공개되어 누구나 점검할 수 있다는 것입니다.