SSP kontra Squads V4: dwa projekty multisigu na Solanie
Portfel multisig to portfel, który wymaga więcej niż jednej akceptacji, zanim środki będą mogły zostać przeniesione. Na Solanie kilka zespołów zbudowało systemy multisig i nie wszystkie działają pod maską tak samo. Ten artykuł porównuje dwa z nich — Squads V4 oraz własny program multisig SSP — nie po to, by koronować zwycięzcę, lecz by pokazać dwie uczciwe, dobrze przemyślane filozofie projektowe i to, komu każda z nich służy.
Jeśli to twój pierwszy przystanek w tej serii, towarzyszący artykuł o samoinicjującym się multisigu na Solanie w całości wyjaśnia, jak działa projekt SSP. Tutaj zestawiamy go z najbardziej ugruntowaną opcją w sieci.
Najpierw uznanie dla Squads V4
Squads V4 to dominujący multisig na Solanie. Jest dojrzały, zabezpiecza miliardy dolarów wartości i został zbadany przez niezwykle długą listę firm zajmujących się bezpieczeństwem — OtterSec, Neodyme, Trail of Bits oraz Certora, przy czym ta ostatnia zastosowała również weryfikację formalną (matematyczny dowód, że kod zachowuje się zgodnie ze specyfikacją). Portfele takie jak Fuse są na nim zbudowane. Każde uczciwe porównanie musi zaczynać się stamtąd: Squads to poważna, sprawdzona w boju platforma, a nic z poniższego nie jest jej krytyką.
Program multisig SSP dla Solany przybiera inną formę, ponieważ został zbudowany w innym celu. Te dwa nie konkurują o to samo zadanie, a reszta tego artykułu dotyczy tego, co się różni i dlaczego.
Zastrzeżenie dotyczące dojrzałości, powiedziane wprost
Jedna różnica waży więcej niż jakikolwiek wybór projektowy, więc idzie pierwsza. Squads V4 działa na sieci głównej (mainnet) Solany — na żywej sieci, gdzie poruszają się prawdziwe środki — i przeszedł audyty wymienione powyżej. Program multisig SSP dla Solany jest, w chwili pisania tego tekstu, dostępny tylko na devnecie (sieci testowej Solany, gdzie tokeny nie mają wartości pieniężnej) i oczekuje na zewnętrzny audyt bezpieczeństwa. To jeszcze nie jest coś, czemu powinieneś powierzyć środki z mainnetu. Poniższe porównanie dotyczy kompromisów projektowych; nie jest rekomendacją używania niezaudytowanego oprogramowania na mainnecie.
Jak powstaje portfel
Najwyraźniejsza różnica leży w tym, jak multisig zaczyna istnieć.
Squads V4 tworzy multisig za pomocą instrukcji on-chain o nazwie multisig_create_v2. Ta instrukcja potrzebuje dwóch rzeczy: osoby tworzącej portfel (twórcy) oraz świeżego, losowego, jednorazowego klucza zwanego create_key. Adres on-chain portfela jest wyprowadzany z tego losowego create_key — więc adres po prostu nie istnieje i nie może być znany ani zasilony, dopóki nie wykona się transakcja tworzenia. W tym momencie obecny jest również twórca: pojedyncza strona, która konfiguruje portfel.
Program SSP nie ma kroku tworzenia w tym sensie. Jego adres multisigu jest wyprowadzany bezpośrednio z samego zbioru członków — konkretnie z odcisku posortowanej listy członków wraz z progiem akceptacji. Ponieważ danymi wejściowymi są tylko „kim są członkowie" i „ilu musi zaakceptować", każdy, kto zna te fakty, może obliczyć adres offline, zanim cokolwiek wydarzy się on-chain. Rejestracja portfela jest bez pozwolenia: program po prostu sprawdza, że członkowie, których przedstawiasz, rzeczywiście odpowiadają deklarowanemu adresowi, tak że adres kanoniczny może przechowywać tylko kanoniczny zbiór członków. Nie ma twórcy ani losowego klucza.
Czy możesz go zasilić, zanim zaistnieje?
To wynika bezpośrednio z poprzedniego punktu.
W przypadku Squads V4 adres zależy od losowego klucza wybranego podczas tworzenia, więc nie możesz go zasilić z wyprzedzeniem — najpierw tworzysz portfel, potem wysyłasz środki. W projekcie SSP, ponieważ adres jest czystą funkcją członków i progu, możesz obliczyć adres depozytowy i wysłać na niego pieniądze zanim portfel zostanie kiedykolwiek zarejestrowany on-chain. Odzwierciedla to działanie Bitcoina: bitcoinowy adres P2WSH jest haszem reguł wydawania, a każdy może go zasilić offline bez żadnej transakcji „tworzenia". W odróżnieniu od dominujących multisigów Solany, takich jak Squads, program SSP wnosi tę właściwość „adres to reguły" na Solanę.
Uprzywilejowane role i uprawnienia administratora
Squads V4 jest platformą zarządzania i oferuje odpowiadające temu funkcje zarządzania. Każdemu członkowi można przypisać maskę bitową uprawnień — kombinację trzech praw: Inicjuj (zaproponuj transakcję), Głosuj (zaakceptuj ją) oraz Wykonaj (przeprowadź już zaakceptowaną). Ponadto multisig Squads może opcjonalnie mieć config_authority: klucz, który może samodzielnie zmienić listę członków lub próg. Multisig „kontrolowany" zachowuje tę władzę; „autonomiczny" ustawia ją na pustą wartość, tak by każda zmiana konfiguracji musiała zamiast tego przejść przez głosowanie członków. To prawdziwe, użyteczne funkcje dla organizacji, które chcą wyznaczonego administratora.
Program SSP celowo nie ma niczego z tego. Wszyscy członkowie są równi — nie ma poziomów uprawnień na członka. Nie ma klucza administratora ani config_authority. Zbiór członków i próg są ustalane przy rejestracji i są potem niezmienne; „rotacja klucza" oznacza przeniesienie środków do nowego multisigu z nowym zbiorem członków. Próg jest sprawdzany tylko wtedy, gdy środki są wydawane, nigdy przy rejestracji. Kompromis jest jasny: Squads daje ci elastyczność administracyjną; SSP daje ci mniejszą powierzchnię, ponieważ uprzywilejowana rola, która nie istnieje, nie może paść ofiarą phishingu, zostać skradziona ani nadużyta.
Ile kosztuje utworzenie
Utworzenie multisigu Squads V4 wiąże się z udokumentowaną opłatą protokolarną wynoszącą około 0,1 SOL, płaconą do skarbca Squads, oprócz niewielkiego czynszu Solany (zwrotnego depozytu, który każde konto musi utrzymywać, by pozostać aktywne). Program SSP nie pobiera żadnej opłaty protokolarnej: rejestracja multisigu kosztuje tylko podstawowy czynsz Solany. To nie jest osąd wartościujący: opłata protokolarna finansuje bieżący rozwój dużej platformy. To po prostu kolejna oś, wzdłuż której oba projekty się różnią.
Dwie filozofie, dwie grupy odbiorców
Cofnij się o krok, a wzorzec staje się jasny. Squads V4 to bogata w funkcje platforma zarządzania: role na członka, opcjonalni administratorzy, dojrzała, zaudytowana baza kodu oraz narzędzia, których organizacja potrzebuje do zarządzania skarbcem z wieloma interesariuszami. Program SSP to minimalny deterministyczny prymityw: adres jest zbiorem członków, rejestracja jest bez pozwolenia, nie ma uprzywilejowanych ról, a między tobą a twoimi środkami jest jak najmniej mechanizmów.
Każdy pasuje do innej potrzeby. DAO lub firma, która chce wyznaczonych administratorów, szczegółowych uprawnień i sprawdzonej historii na mainnecie, jest dobrze obsłużona przez Squads. Projekt SSP celuje w inny model — konsumencki portfel 2-z-2 oraz konfigurację M-z-N dla przedsiębiorstw — gdzie priorytetem jest, by adres portfela był przewidywalny, możliwy do zasilenia z wyprzedzeniem i wolny od jakiejkolwiek roli, która mogłaby stać się pojedynczym punktem awarii. SSP celowo pomija funkcje zarządzania Squads: dla zastosowania SSP jest po prostu mniej do skompromitowania.
Aby zobaczyć, jak wybory SSP sprawdzają się wobec rzeczywistych scenariuszy atakującego, artykuł akademii o trybach awarii multisigu i tym, jak SSP je łagodzi przechodzi przez modele zagrożeń bezpośrednio. A jeśli chcesz technicznych szczegółów wyprowadzenia w SSP, artykuł o samoinicjującym się multisigu na Solanie jest kanonicznym odniesieniem. Co do drugiej strony, kod źródłowy i dokumentacja Squads V4 są otwarcie dostępne.
Uczciwe podsumowanie
Nie ma tu „lepszego" multisigu, są tylko lepsze dopasowania. Squads V4 to dojrzały, intensywnie zaudytowany, bogaty w funkcje wybór dla organizacji, które chcą wbudowanego zarządzania. Program SSP to mniejszy, zorientowany na adres projekt — obecnie dostępny tylko na devnecie i czekający na swój audyt — zbudowany tak, by portfel multisig był równie przewidywalny jak adres Bitcoina. Dwie uczciwe filozofie, każda rozwiązuje problem, który jej twórcy postanowili rozwiązać.
