Największym ryzykiem bezpieczeństwa w każdym systemie płatności kryptowalutowych jest ujawnienie klucza prywatnego. Jeśli serwer monitorujący przychodzące płatności może również wydawać te środki, to jedno naruszenie oznacza całkowitą stratę. Architektura non-custodial całkowicie eliminuje to ryzyko — a mechanizm, który za tym stoi, czyli pochodzenie kluczy portfela HD, jest na tyle elegancki, że warto go zrozumieć.
Problem z gorącymi portfelami na serwerach
"Gorący portfel" to portfel, którego klucz prywatny znajduje się na maszynie podłączonej do internetu. Większość naiwna implementacja płatności kryptowalutowych działa w ten sposób: generuje portfel, umieszcza klucz prywatny w pliku konfiguracyjnym lub bazie danych i używa go do tworzenia adresów depozytowych oraz podpisywania transakcji wypłat.
Problem jest oczywisty w retrospektywie: każdy atakujący, który skompromituje serwer — poprzez niezałatane luki, atak łańcucha dostaw, wyciek danych uwierzytelniających lub źle skonfigurowany zaporę — zdobywa klucz prywatny i może opróżnić każdy portfel z nim powiązany. Historia włamań do giełd kryptowalutowych to w dużej mierze historia kompromitacji gorących portfeli.
Rozwiązaniem jest oddzielenie możliwości obserwacji płatności od możliwości wydawania środków.
Portfele HD i Rozszerzony Klucz Publiczny
BIP-32 (Hierarchiczne Portfele Deterministyczne) definiuje sposób pochodzenia nieskończonego drzewa par kluczy z jednego głównego ziarna. Kluczową cechą jest pochodzenie klucza publicznego: mając rozszerzony klucz publiczny (xPub) węzła rodzica, możesz wyprowadzić wszystkie klucze publiczne dzieci — a tym samym wszystkie adresy Bitcoin dzieci — nie widząc nigdy klucza prywatnego.
Jest to matematycznie możliwe dzięki arytmetyce krzywych eliptycznych: klucze publiczne są punktami na krzywej, a możesz dodać deterministyczny modyfikator, aby wyprowadzić klucze publiczne dzieci tylko z klucza publicznego rodzica.
W praktyce oznacza to:
- Generujesz główne ziarno offline — na komputerze odizolowanym od sieci, portfelu sprzętowym lub urządzeniu do podpisywania.
- Eksportujesz xPub (tylko klucz publiczny, bez materiału prywatnego) i przekazujesz go swojemu serwerowi płatności.
- Serwer wyprowadza adres #1 dla faktury #1, adres #2 dla faktury #2 i tak dalej — wszystkie unikalne, wszystkie twoje — nie znając nigdy klucza prywatnego.
Jak działa pochodzenie adresów w praktyce
Dla BIP-32 xPub na ścieżce pochodzenia m/44'/0'/0' (standardowy Bitcoin BIP-44), serwer wyprowadza adresy na m/44'/0'/0'/0/N, gdzie N to indeks faktury. Każde N produkuje unikalny adres. Adresy są deterministyczne — ten sam xPub + to samo N zawsze produkuje ten sam adres — więc możesz ponownie wyprowadzić dowolny adres w celu weryfikacji.
Dla łańcuchów UTXO (Bitcoin, Litecoin, Dogecoin, Bitcoin Cash) jest to standardowe podejście. Inne łańcuchy używają różnych, ale równoważnych mechanizmów:
- TON i Tron: każda faktura otrzymuje świeżo wygenerowaną parę kluczy; tylko klucz publiczny (a tym samym adres) jest przechowywany na serwerze. Klucz prywatny jest albo odrzucany (do użytku tylko do obserwacji), albo przechowywany w offline'owej puli.
- Solana: offline'owa pula wcześniej wygenerowanych kluczy publicznych (pochodzących z offline'owego ziarna) jest zużywana po jednym na fakturę.
- Łańcuchy EVM (ETH, BSC, Polygon itd.): pochodzenie xPub za pomocą BIP-44, tak jak w Bitcoinie.
- XRP i XLM: model wspólnego adresu z unikalnymi tagami docelowymi lub notatkami dla każdej faktury.
Pełny proces płatności non-custodial
- Faktura utworzona: twoja strona wywołuje API bramki. Bramki wyprowadza świeży adres depozytowy (lub przypisuje unikalny tag) używając tylko materiału publicznego.
- Klient płaci: środki są wysyłane na ten adres. Bramki wykrywa transakcję za pomocą API eksploratora blockchain.
- Potwierdzenie: po wymaganej liczbie potwierdzeń, bramka aktualizuje status faktury i wysyła podpisany webhook do twojego serwera.
- Środki przychodzą: do twoich własnych portfeli. Bramki nigdy ich nie przechowywały, nie mogą ich przenieść i nie mają klucza prywatnego, aby to zrobić.
- Wypłata: gdy chcesz przelać środki lub przetworzyć wypłatę, podpisujesz transakcję offline — na maszynie odizolowanej od sieci, portfelu sprzętowym lub dowolnym urządzeniu do podpisywania — i transmitujesz podpisaną transakcję. Serwer rejestruje hash transakcji, ale nie może zainicjować wydania.
Co to oznacza dla bezpieczeństwa
Całkowita kompromitacja serwera płatności w tym modelu jest, w najgorszym przypadku, naruszeniem danych — atakujący może zobaczyć historię zamówień i faktury w toku, ale nie może przenieść ani jednego satoshi. Środki znajdują się w portfelach kontrolowanych przez klucze, które nigdy nie dotknęły serwera.
Dlatego bramki non-custodial wymagają, abyś wyeksportował xPub (lub użył narzędzia do generowania kluczy offline) przed przetwarzaniem płatności. Nieco wyższy koszt konfiguracji zapewnia ci fundamentalnie inny profil ryzyka: kompromitacja serwera ≠ utrata środków.
Dla każdego operatora obsługującego znaczną ilość, ta architektura nie jest opcjonalna — to minimalna możliwa postawa bezpieczeństwa. Dowiedz się więcej o tym, jak Payora to wdraża w ponad 20 wspieranych sieciach.
Comments