18 lipca 2024 r. SSP Wallet v1.6.0 dodał Ethereum — a SSP stał się pierwszym portfelem, który wdrożył prawdziwe konta Schnorr-multisig na Ethereum z użyciem Account Abstraction ERC-4337. Inne portfele nazywają się "Ethereum multisig", umieszczając pojedyncze konto zewnętrznie posiadane za interfejsem. SSP wybrał trudniejszą drogę, aby ten sam model 2-z-2, który chroni Bitcoina wewnątrz SSP, teraz chronił także ETH.
TL;DR
- Ethereum (ETH) dołącza do SSP jako łańcuch pierwszej klasy.
- Konta to inteligentne kontrakty zgodne z ERC-4337, a nie EOA — więc egzekwowanie 2-z-2 żyje on-chain.
- Dwa podpisy Schnorra agregują się w jeden, zanim trafią na Ethereum, utrzymując gaz przewidywalnym.
- Biblioteka podpisywania jest open source na npm:
@runonflux/aa-schnorr-multisig-sdk. - Obsługa tokenów ERC-20 to następny krok; ta wersja dostarcza ETH same w sobie plus fundamenty AA pod spodem.
Co wylądowało: wsparcie dla Ethereum, na trudniejszy sposób
Większość portfeli "obsługuje Ethereum" generując konto zewnętrznie posiadane (EOA) — pojedynczy klucz prywatny, pojedynczy podpis, pojedynczy punkt awarii. Dołożenie multisig na górze zwykle oznacza politykę programową po stronie portfela, a nie regułę egzekwowaną na łańcuchu. Łańcuch nadal widzi jeden klucz, a ktokolwiek go posiada, może sam ruszyć środki.
SSP odmówił tego skrótu. Cały sens modelu 2-z-2 SSP polega na tym, że ani SSP Wallet na desktopie, ani SSP Key na telefonie nie mogą same ruszyć środków — współpodpisywanie to właściwość konta, a nie konwencja interfejsu. Aby zachować to na Ethereum, EOA nigdy nie wystarczyłoby. Konto Ethereum musiało być inteligentnym kontraktem, który z założenia wymaga dwóch podpisów. To dokładnie zostało dostarczone w v1.6.0.
Co tu znaczy Schnorr multisig
Skrypty UTXO Bitcoina potrafią wyrazić 2-z-2 natywnie — w ten sposób istniejące łańcuchy SSP egzekwują współpodpisywanie. Model kont Ethereum nie potrafi tego bez pomocy. SSP wypełnia tę lukę podpisami Schnorra.
Schnorr to schemat podpisu z jedną właściwością, która tu się liczy: dwóch sygnatariuszy może wyprodukować po podpisie częściowym, a te częściowe można połączyć w pojedynczy, prawidłowy podpis, który weryfikuje się względem pojedynczego zagregowanego klucza publicznego. Dla każdego czytającego łańcuch wygląda to tak, jakby jeden sygnatariusz podpisał raz. Dla SSP musiały zgodzić się dwa urządzenia. Głębia kryptograficzna — agregacja kluczy, koordynacja nonców, rundy w stylu MuSig2 — jest opisana w naszym artykule akademickim o podpisach Schnorra i agregacji multisig, jeśli jej chcesz. Podsumowanie dla użytkownika jest krótkie: ten sam uścisk dłoni SSP Wallet + SSP Key, którego już używasz, wyrażony teraz jako jeden zagregowany podpis Schnorra na Ethereum.
Account Abstraction ERC-4337
Account Abstraction (AA) to termin parasolowy dla pozwolenia kontom Ethereum zachowywać się jak programowalne portfele zamiast nagich par kluczy. W standardowym modelu Ethereum istnieją dwa typy kont: EOA, kontrolowane jednym kluczem prywatnym, i kontrakty, które same nie mogą zainicjować transakcji. AA znosi to rozróżnienie na warstwie aplikacyjnej.
ERC-4337 to standard Ethereum, który dostarcza AA bez zmiany samego Ethereum. Zamiast hard forka definiuje obiekt transakcyjny wyższego poziomu nazywany UserOperation, bundler, który zamienia je w normalne transakcje Ethereum, oraz kontrakt EntryPoint, który je waliduje. Twoje "konto" to inteligentny kontrakt, który decyduje, jak chce uwierzytelniać wydatki — dla SSP ta reguła uwierzytelniania brzmi: zagregowany podpis Schnorra z SSP Wallet i SSP Key, albo nic. Bez hard forka L1, bez specjalnych operatorów węzłów, bez założeń zaufania poza tym, co już jest wdrożone na mainnecie.
Biblioteka open source
Warstwa podpisywania Schnorr-multisig nie jest zakopana w aplikacji SSP. Wyodrębniliśmy ją jako bibliotekę wielokrotnego użytku i wypuściliśmy pod tą samą postawą open source co reszta SSP. SDK w TypeScripcie żyje na npm jako @runonflux/aa-schnorr-multisig-sdk; kontrakty Account Abstraction w Solidity, z którymi się sprzęga, żyją w repozytorium @runonflux/account-abstraction na GitHubie.
Jeśli budujesz portfel, prowadzisz badania bezpieczeństwa lub po prostu jesteś ciekaw, jak Schnorr-multisig AA naprawdę składa się na Ethereum, oba projekty są tam, by je czytać, forkować i wnosić wkład. Pull requesty i issues są mile widziane — wolimy utwardzać jedną wspólną bibliotekę z większą liczbą oczu, niż pozwalać, by każdy portfel chcący tego prymitywu wymyślał go od nowa.
Co to odblokowuje
Konkretnie dla v1.6.0 oferowanym łańcuchem jest samo Ethereum — salda ETH, transfery ETH, ten sam przełącznik panelu Chains, którego używasz do każdej innej monety, teraz z kontem AA za sobą. Hydraulika kładziona przez tę wersję jest trudniejszą częścią. Gdy konta Schnorr AA 2-z-2 istnieją i działają, każde saldo o kształcie Ethereum staje się osiągalne.
Obsługa tokenów ERC-20 to naturalny następny krok i już jest na mapie drogowej — pokryjemy ją własnym wpisem newsroom, gdy się ukaże. Na dziś nagłówkiem jest to, że Ethereum jest w SSP, jest w SSP w odpowiedni sposób, a leżące pod nim fundamenty kryptograficzne i smart-kontraktowe są open source na npm i GitHubie, by każdy mógł je sprawdzić.
Źródło: notatki wydania SSP Wallet v1.6.0.