Przejdź do treści
ArchXS

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.

Produkty on-chain, które przeżywają własny redesign
Rys. 01To, co nigdy nie powinno wymagać zmiany, idzie na łańcuch i zostaje niezmienne, reszta siedzi za świadomie zaprojektowaną granicą aktualizacji, a kupujący nie musi mieć portfela, żeby kupić.

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ę.