Kluczowa decyzja architektoniczna: sieć publiczna czy permissioned
Zanim wejdziesz w temat portfeli i kontraktów, określ, czy potrzebujesz sieci publicznej (permissionless), czy permissioned (z kontrolą uczestników). Ta decyzja wpływa na:
model zagrożeń (nieznani uczestnicy vs. znane podmioty),
governance (kto może pisać, kto utrzymuje infrastrukturę, jak podejmuje się decyzje),
to, co jest replikowane i gdzie,
oraz na trudność ułożenia ról i odpowiedzialności.
Wniosek decyzyjny:
Jeśli potrzebujesz interoperacyjności z ekosystemem (portfele, tokeny, integracje), najczęściej kończy się na sieci publicznej lub L2.
Jeśli priorytetem jest kontrola dostępu i uczestników, permissioned może pasować — ale nadal trzeba obronić sens DLT vs klasycznej bazy danych.
Co „nie jest aż tak trudne” (bo standardy i narzędzia są dojrzałe)
Standardowe interfejsy tokenów i przewidywalna integracja
Jeżeli przypadek użycia mieści się w standardowym zachowaniu tokena (np. typowe funkcje transfer/allowance), możesz oprzeć się o znane interfejsy. To ogranicza tarcia integracyjne z portfelami i toolingiem.
Kiedy przestaje być łatwo:
upgrade’y i kontrola administracyjna,
niestandardowe ograniczenia transferu, fee logic, listy blokad,
bridging i wielołańcuchowość,
logika dotykająca realnej wartości (zwykle rośnie powierzchnia audytu).
Wzorce bezpieczeństwa, które warto „pożyczyć” zamiast wymyślać
Dostępne są sprawdzone wzorce (np. bezpieczniejsze schematy wypłat, zabezpieczenia przed reentrancy, mechanizmy pauzy). To nie zastępuje kompetencji, ale znacząco redukuje liczbę własnych wynalazków, które później trudno zweryfikować.
Managed infrastruktura do dostępu do sieci
Na starcie wiele zespołów wybiera dostawców RPC zamiast samodzielnego hostowania węzłów. To przyspiesza dostarczenie produkcyjnej łączności, ale wnosi ryzyko zależności od dostawcy i kosztową wrażliwość (limity, throttling, retry storms, awarie regionów).
Wniosek decyzyjny:
MVP da się dostarczyć szybko.
Skala, niezawodność, weryfikacja bezpieczeństwa i compliance to obszary, które realnie „zjadają” harmonogram.
Co jest trudne: portfele, custody i zarządzanie kluczami
Wybór portfela to nie detal UX. To decyzja o tym, kto kontroluje aktywa i kto ponosi koszt błędów oraz incydentów.
Portfele custodial (ty lub dostawca trzymacie klucze)
Co rośnie w złożoności:
kontrola podpisu (approval flows, separacja ról, procedury awaryjne),
polityki hot vs cold, limity wypłat, automatyczne i ręczne kontrole,
logowanie i ślad audytowy z perspektywy operacji,
obsługa incydentów oraz oczekiwania użytkowników „żeby cofnąć transakcję” (zwykle niewykonalne on-chain).
Custody często podnosi też wagę wymagań regulacyjnych i audytowych, bo wchodzisz w obszar usług podobnych do finansowych.
Portfele non-custodial (klucze po stronie użytkownika)
Co jest trudne:
odzyskiwanie dostępu: w wielu modelach nie możesz pomóc, jeśli użytkownik straci seed/private key,
wsparcie i fraud handling: „pomyliłem adres”, phishing i błędy użytkowników stają się stałym kosztem operacyjnym,
projektowanie przepływów minimalizujących nieodwracalne pomyłki (symulacje transakcji, czytelne potwierdzenia, jasne ryzyka).
Hot vs cold – kompromis operacyjny
Bez wchodzenia w vendor-specific detale:
hot: szybkość i automatyzacja, ale większa ekspozycja na ataki online,
cold: mocniejsza izolacja, ale wolniejsze operacje i cięższe procedury.
Wniosek decyzyjny:
Jeśli oferujesz custody, budujesz funkcję bezpieczeństwa i operacji, nie tylko „feature”.
Jeśli idziesz w non-custodial, projektuj pod porażki: procesy wsparcia i bezpieczne UX to część definicji „done”.
Smart kontrakty: bezpieczeństwo to deliverable, nie „checkbox”
Ryzyko smart kontraktów wynika z połączenia:
wartości, która może zostać utracona,
powierzchni ataku rosnącej wraz z niestandardową logiką,
oraz realiów upgrade’ów, admin keys i działań awaryjnych.
Najtrudniejsze jest:
przetłumaczenie „bezpiecznie” na mierzalne wymagania i testy,
zbudowanie planu weryfikacji adekwatnego do ryzyka (nie tylko unit testy),
świadoma decyzja o (nie)upgrade’owalności i governance.
Wniosek decyzyjny:
Bezpieczeństwo powinno mieć kryteria akceptacji i zakres – inaczej audyt wyjdzie późno i wymusi przebudowę.
Koszty gas i wybór sieci: gdzie „tanie” robi się nieprzewidywalne
Gas to ograniczenie produktowe. Wpływa na onboarding, retencję i unit economics.
Realne konsekwencje:
Na L1 opłaty potrafią być zmienne wraz z popytem.
Na L2 koszt bywa niższy, ale nadal zależy od czynników L1 oraz obciążenia L2 (i od tego, jak zaprojektujesz transakcje).
Typowe taktyki projektowe:
batching/grupowanie operacji tam, gdzie to możliwe,
minimalizacja zapisów on-chain (tylko to, co musi być na łańcuchu),
UX, który nie zmusza użytkownika do drogich akcji w złym momencie,
strategia sieci dopasowana do tolerancji zmienności kosztów.
Wniosek decyzyjny:
Jeśli marża zależy od stabilnego kosztu na akcję użytkownika, musisz mieć plan na zmienność (architektura + UX), a nie założenie, że „L2 zawsze jest tanie”.
Najpierw prawo i compliance – dopiero potem implementacja
W praktyce system blockchain i dane osobowe/regulacje potrafią wejść ze sobą w konflikt, jeśli podejdziesz do tematu „najpierw zbudujmy, potem ułożymy”.
GDPR i dane osobowe on-chain
Jeżeli w systemie pojawiają się dane osobowe, musisz umieć obronić:
co trafia on-chain, a co zostaje off-chain,
kto jest administratorem i podmiotem przetwarzającym w danej architekturze,
jak realizujesz zasady minimalizacji i ograniczenia celu w środowisku replikacji danych.
Regulator: kiedy wchodzisz w obszar MiCA
Jeżeli emitujesz kryptoaktywa albo świadczysz usługi na kryptoaktywach, musisz sklasyfikować, co faktycznie robisz (np. custody, obrót, emisja) i jakie obowiązki mogą z tego wynikać. To wpływa na architekturę, governance i procesy operacyjne.
Wniosek decyzyjny:
Jeśli klasyfikacja prawna nie jest jasna, wstrzymaj decyzje architektoniczne do czasu, aż masz spójną mapę obowiązków.
Typowe koszty: użyteczny „kosztowy stos” zamiast jednej liczby
Zamiast zgadywać kwotę, która i tak zależy od ryzyk, lepiej rozbić koszty na elementy, które da się zweryfikować w discovery/PoC.
Koszty jednorazowe (build)
Architektura: publiczna vs permissioned, L1 vs L2, custody, strategia upgrade’ów.
Smart kontrakty: standardy przyspieszają, custom logic poszerza zakres.
Weryfikacja bezpieczeństwa: wymagania, testy, przygotowanie pod audyt.
Integracja portfeli: custodial (podpis i kontrola) vs non-custodial (UX i procesy wsparcia).
Compliance: mapowanie danych i ról (GDPR), analiza triggerów regulacyjnych (MiCA) i plan działań.
Koszty stałe (run)
Gas: koszt per akcja + bufor na zmienność.
Infrastruktura: koszty RPC rosną z ruchem, retry i odczytami.
Operacje kluczy (custody): koszty podpisów/operacji i cały „security overhead”.
Wsparcie i fraud: nieodwracalne błędy i przejęcia kont.
Jak to sensownie policzyć (nawet wcześnie):
Zdefiniuj 5–10 kluczowych akcji użytkownika (transfer, claim, mint, swap itp.).
Zmierz opłaty w docelowych sieciach dla tych akcji i oszacuj wahania.
Oszacuj wolumen zapytań do RPC (odczyty i zapisy) oraz obciążenie backendu.
Ustal minimalny zestaw bezpieczeństwa i compliance jako stały scope.
Wniosek decyzyjny:
Najdroższe „niespodzianki” to zwykle custody operations, przebudowy pod bezpieczeństwo oraz redesign pod compliance – nie samo kodowanie kontraktów.
Trade-offy, które mają znaczenie dla decydentów
Custodial vs non-custodial
Custodial: lepsza kontrola UX i odzyskiwania, ale większy ciężar operacyjny i compliance.
Non-custodial: mniejszy ciężar custody, ale większe ryzyko utraty kluczy i koszt wsparcia.
Build vs buy dla krytycznych komponentów
Kupowanie (RPC/elementy wallet stack): szybciej, ale zależność od dostawcy i wrażliwość kosztowa.
Budowanie: większa kontrola, ale wymaga dojrzałego security/ops.
„Wszystko on-chain” vs podejście hybrydowe
Więcej on-chain: prostsze założenia zaufania, ale większa ekspozycja kosztowa i ograniczenia niezmienności.
Hybryda: niższe opłaty i łatwiejsza praca z danymi, ale większa złożoność systemu i wymagania spójności.
Anti-patterny: typowe błędy i ich skutki
Start bez governance i odpowiedzialności
Skutek: brak jasnych odpowiedzi, kto zatwierdza upgrade’y, kto podpisuje transakcje, jak wygląda reakcja na incydent.Traktowanie gas jako detalu implementacyjnego
Skutek: unit economics rozjeżdża się przy obciążeniu, UX psuje się w najgorszym momencie.Custom token logic „bo możemy”
Skutek: większa powierzchnia ataku i większy zakres audytu.Myślenie „audyt to naprawi”
Skutek: przebudowy pod koniec projektu, gdy założenia nie przechodzą weryfikacji.Custody bez kontroli operacyjnej
Skutek: pierwszy incydent staje się krytyczny dla firmy – nie przez sam blockchain, tylko brak procesów.
Checklisty decyzyjne
Checklist dla dostawców (RPC / wallet / custody)
Jaka jest jednostka rozliczeń i co powoduje skok kosztów?
Jakie są limity i zachowanie przy throttlingu?
Jakie logi możesz eksportować pod audyt i na jakich zasadach?
Jak wygląda redundancja i failover (multi-region, multi-provider)?
Jakie są warunki wsparcia/SLA dla incydentów produkcyjnych?
Checklist dla zespołu (zanim „klepniesz” implementację)
Jaki jest model custody i kto ponosi ryzyko straty?
Jak wyglądają polityki hot/cold i approval flows (jeśli custodial)?
Jak definiujesz „done” dla bezpieczeństwa (zakres testów i weryfikacji)?
Co jest on-chain vs off-chain i czy potrafisz to uzasadnić (GDPR)?
Jakie są triggery regulacyjne dla Twojego modelu (MiCA)?
Jaki jest plan na zmienność opłat dla każdej kluczowej akcji użytkownika?
Kiedy system blockchain ma sens, a kiedy nie
Ma sens, gdy:
potrzebujesz wspólnego rozliczania między stronami bez jednego operatora,
interoperacyjność z ekosystemem jest wymogiem,
akceptujesz nieodwracalność i projektujesz pod nią procesy.
Często nie ma sensu, gdy:
priorytetem są odwracalne operacje, ścisła kontrola dostępu i przewidywalne koszty,
nie potrafisz jednoznacznie opisać odpowiedzialności prawnej i governance.
Końcowy wniosek:
System blockchain działa biznesowo wtedy, gdy custody, governance i compliance są częścią scope’u od pierwszego dnia, a footprint on-chain jest ograniczony do tego, co naprawdę musi być na łańcuchu.
