< Wróć do aktualności

Ekspansja EVM: Polygon, BSC i Avalanche dołączają do SSP — odrębny adres na sieć, z założenia

·5 min czytania·Autor: SSP Editorial Team
Plakietka RELEASE z ikonami ułożonych cylindrów (baza danych), błyskawicy, tarczy z fajką i piętrzonych monet nad nagłówkiem „Ekspansja EVM: Polygon, BSC i Avalanche".

W ciągu dziewięciu dni SSP Wallet przeszedł z obsługi jednej sieci EVM do czterech. v1.18.0 dodał Polygon 25-03-2025; v1.19.0 dołączył 01-04-2025 z Binance Smart Chain i Avalanche C-Chain. Liczba sieci to haczyk, ale prawdziwa historia jest pod spodem: SSP daje każdej sieci EVM odrębny adres, idąc za BIP49 ze ścisłą derywacją SLIP44. To świadoma decyzja zorientowana na bezpieczeństwo — i dlatego nagłówek brzmi nie „trzy nowe sieci", lecz „trzy nowe sieci, trzy nowe przestrzenie adresowe".

Polygon przybywa (v1.18.0, 25 marca)

v1.18.0 wprowadził Polygon do SSP — mainnet plus testnet Amoy. POL jest obsługiwany natywnie, podobnie predefiniowane tokeny oraz dowolny niestandardowy ERC-20, który użytkownik chce zaimportować. Polygon zachowuje się teraz tak jak Ethereum od startu ERC-4337: ten sam przepływ multisig 2-z-2, ta sama choreografia SSP Wallet/SSP Key, ten sam inteligentny portfel z abstrakcją konta, tylko na szybszej i tańszej L2.

Nowością nie jest to, że Polygon jest w SSP — lecz to, że twój adres Polygon w SSP nie jest twoim adresem Ethereum w SSP. Ta sama seed, ten sam multisig. Inny coin type SLIP44, inna ścieżka derywacji, inny adres. Wrócimy do tego, dlaczego.

Potem BSC i Avalanche (v1.19.0, 1 kwietnia)

Tydzień później v1.19.0 dodał Binance Smart Chain i Avalanche C-Chain. Obie przybyły w tej samej formie co Polygon: natywna moneta (BNB na BSC, AVAX na Avalanche), standardowa lista predefiniowanych tokenów SSP oraz import niestandardowych tokenów dla wszystkiego innego na tych sieciach.

Po dwóch wydaniach SSP obsługuje Ethereum, Polygon, BSC i Avalanche — cztery sieci EVM, cztery odrębne adresy. Twój adres BNB to nie twój adres AVAX; twój AVAX to nie twój ETH; żaden nie koliduje. To nie przypadek — to cel.

Dlaczego ścisły SLIP44 ma znaczenie

Większość portfeli EVM robi jedno: wybierają jedną ścieżkę derywacji pod coin type SLIP44 60 (Ethereum) i ponownie używają uzyskanego adresu na każdej sieci kompatybilnej z EVM. Wysyłasz ETH na Ethereum i BNB na BSC pod „ten sam adres" — bo na poziomie sieci adres rzeczywiście jest bajt-identyczny. Wygodne. To także milcząca decyzja kompromisowa.

BIP44 zdefiniował hierarchiczną strukturę: m/purpose'/coin_type'/account'/change/index. SLIP44 zdefiniował rejestr coin types: Bitcoin to 0, Ethereum to 60, Polygon to 966, BSC to 9006, Avalanche to 9000. Różne coin types dają różne ścieżki derywacji, które dają różne klucze, które dają różne adresy — chociaż krzywa, podpis i bajtowy format adresu są identyczne.

SSP idzie za BIP49 ze ścisłym SLIP44. Portfel respektuje coin type każdej wspieranej sieci. Polygon wyprowadza pod 966. BSC pod 9006. Avalanche pod 9000. Efekt: każda sieć dostaje własny materiał klucza, własny adres, własną historię na sieć.

Po co się męczyć, skoro ponowne użycie jednego adresu byłoby łatwiejsze?

  • Pomyłki między sieciami kosztują pieniądze. Jeśli twój „adres EVM" jest taki sam na każdej sieci, bardzo łatwo wysłać niewłaściwy aktyw do niewłaściwego środowiska — USDC.e na Polygon do odbiorcy oczekującego Ethereum, „przemostuję to później" które się sypie. Odrębne adresy włączają sieć do modelu mentalnego użytkownika, zamiast ukrywać ją jako pułapkę.
  • Prywatność i księgowość on-chain. Jeden wspólny adres oznacza, że publiczny obserwator może skorelować twoje zachowanie na każdej sieci EVM, której dotykasz. Odrębne adresy na sieć zapobiegają temu, by przypadkowa powiązywalność cross-chain była ustawieniem domyślnym.
  • Promień rażenia przy wycieku klucza. SSP to multisig, więc kompromitacja pojedynczego klucza nie opróżnia środków. Ale zasada obowiązuje: portfel, który mapuje jeden klucz na jedną sieć, ogranicza powierzchnię, w której bierze udział każda derywacja — ten sam argument higieniczny, który BIP44 zrobił dla Bitcoina w 2014.
  • Kompatybilność z tym, jak inne portfele indeksują historię. Narzędzia respektujące SLIP44 szukają twojej historii Polygon, BSC, AVAX w odpowiednim miejscu. Te, które tego nie robią, dalej traktują wszystko jak „coin type 60" i po cichu tracą dane.

Kosztem produktu jest dodatkowy krok w modelu użytkownika: „twój adres Polygon to nie twój adres Ethereum". Korzyścią jest portfel, który nie recyklinguje po cichu jednej tożsamości w stylu ETH na każdej nowej sieci, którą przyjmuje.

Import niestandardowych tokenów

Wszystkie trzy sieci akceptują ten sam przepływ importu niestandardowych tokenów wprowadzony dla tokenów Ethereum wcześniej w osi czasu. Jeśli sieć wspiera ERC-20 (lub odpowiednik BEP-20), a ty masz adres kontraktu, możesz dodać go na tej konkretnej sieci. Listy predefiniowane pokrywają oczywiste aktywa — wersje wrapped, stablecoiny, flagowe tokeny DeFi — a importy niestandardowe pokrywają resztę.

Tokeny są na sieć. Kontrakt USDC na Ethereum i kontrakt USDC na Polygon to odrębne artefakty on-chain pod odrębnymi adresami. SSP traktuje je tak, każda sieć pokazuje swoją własną listę tokenów pod swoim adresem wyprowadzonym przez SLIP44.

Wymagana wersja SSP Key

Notka operacyjna z wydania v1.18.0: Polygon (a przy okazji sieci dodane w v1.19.0) wymaga SSP Key w wersji v1.11.0 lub nowszej. Mobilny podpisujący musi rozumieć nowe coin types SLIP44, aby wyprowadzić właściwe klucze w momencie podpisywania. Jeśli jesteś na starszym SSP Key, zaktualizuj go zanim dodasz konta Polygon, BSC lub Avalanche w SSP Wallet — w przeciwnym razie portfel nie będzie miał kontrpartnera do uzupełnienia podpisu 2-z-2.

Po v1.18.0 i v1.19.0 SSP to już nie „rodzina Bitcoin plus Ethereum". To portfel multi-sieciowy EVM, z trzema nowymi sieciami dodanymi w mniej niż dziesięć dni — i polityką derywacji, która sprawia, że każda nowa sieć przychodzi z własnym adresem, celowo.

Udostępnij ten artykuł

Powiązane artykuły