Praktyka
Produkty on-chain, które przeżywają własny redesign
Publiczny łańcuch obiecuje, że reguły nie zmieniają się nikomu za plecami. Produkt obiecuje, że zostanie poprawiony po starcie. Da się dotrzymać obu, ale tylko wtedy, gdy granica aktualizacji jest narysowana świadomie, przed startem, a nie w trakcie incydentu.

Jak na to patrzymy
Większość takich projektów przegrywa na jednym z dwóch symetrycznych błędów. Albo kontrakt jest niezmienny i ekonomia zostaje zamrożona na tym, w co zespół wierzył w dniu startu, albo logika siedzi na serwerze, a łańcuch trzyma obrazek i pokwitowanie, czyli część on-chain jest dekoracją. Żaden z tych błędów nie jest problemem technologicznym, oba są jednym pytaniem bez odpowiedzi: co w tym produkcie nigdy nie powinno wymagać zmiany. Drugie pytanie należy do tego, kto ma to faktycznie kupić. W kanale masowym portfel nie może być warunkiem transakcji, bo architektura żądająca od kupującego nowej kompetencji przed sprzedażą nie sprzedaje już produktu, tylko tę kompetencję. A w organizacji regulowanej łańcuch jest tanią częścią problemu. Drogą częścią jest uzgodnienie, czym jest produkt w kategoriach, których ta organizacja już używa, bo dopiero wtedy da się go sprzedawać, obsługiwać i obronić na audycie.
Co zbudowaliśmy
Prowadziliśmy Polski Krypto-Znaczek dla narodowego operatora pocztowego, organizacji ponad 80 000 osób, od koncepcji po wprowadzenie na rynek, odpowiadając za stronę handlową, techniczną i prawną oraz za partnerów zewnętrznych. Rzecz fizyczna pozostaje pełnoprawnym znaczkiem pocztowym, a token jest jej odpowiednikiem, nie zamiennikiem; dyscyplina nakładu i numeracji jest egzekwowana w kontrakcie; zakup idzie kanałem, którego klient już używał, i formą płatności, której już używał, bez portfela przy okienku. We własnym protokole kolekcje stoją na EIP-2535: jedno proxy kierujące wywołania po selektorze funkcji do 21 faset nad wspólnym układem pamięci, więc poprawka mechaniki gry wychodzi jako podmiana fasety, a nie migracja proszą 2 300 posiadaczy o przejście na nowy adres. Komponowalność wzięliśmy ze standardów ERC-6220, ERC-7401 i ERC-5773, zamiast ją wymyślać, i to dzięki temu marketplace, z którym nigdy nie rozmawialiśmy, poprawnie renderuje złożony token. Ekonomia jest rozdzielona na elastyczny token użytkowy i token zarządczy o stałej podaży, ze stakingiem i tokenem-pokwitowaniem pozycji, który pozwala wyjść z płynności bez odstakowania. Poza łańcuchem podział trzymamy uczciwie: indekser słucha zdarzeń i wypełnia model odczytowy w PostgreSQL, aplikacje rozmawiają z API, nigdy z węzłem, i nie ma tam niczego, co rozstrzyga wynik, więc gdy API zniknie, stan wciąż jest w łańcuchu i wciąż daje się zweryfikować. Mechanika marketplace'u działa na Seaporcie dla ERC-721 i ERC-1155, zamiast być pisana od nowa. Po stronie tożsamości własne SPI Keycloak weryfikuje podpisy EIP-191 z jednorazowym nonce o ograniczonym czasie życia, więc portfel jest jedną z metod uwierzytelniania w tym samym realmie co OTP mailowy i passkeys, z portfelem wbudowanym dla tych, którzy przychodzą bez własnego, i obsługą kont ERC-4337; połowa kliencka jest opublikowana na licencji MIT jako konektor wagmi.
Co z tego wynika
Zostaje produkt, który ktoś inny może zintegrować bez pytania: opublikowane adresy kontraktów, inwentarz faset i model tokenów, oraz ścieżka aktualizacji przećwiczona, a nie założona. Dwa koszty są powiedziane, a nie ukryte: aktualizowalność oznacza, że posiadacze ufają kluczowi administracyjnemu, a pamięć współdzielona między fasetami karze nieostrożną zmianę struktury we wszystkich fasetach naraz. Kupujemy za to prawo do poprawienia projektu po starcie bez proszenia kogokolwiek o migrację.