Artykuł pochodzi od Pavela Naydanova
Kompilacja | Odaily Planet Daily Golem (@web3_golem)
Nota redaktora: Polymarket zyskał więcej uwagi w tegorocznych wyborach w USA, nie tylko dlatego, że całkowity wolumen transakcji na przewidywanych tematach przekroczył 3,6 miliarda dolarów, ale również dlatego, że w porównaniu do sondaży i tradycyjnych mediów przewidział z wyprzedzeniem i skutecznie, że Trump wygra, co skłoniło ludzi do uświadomienia sobie, że Polymarket to nie tylko strona zakładów, ale stanie się bardziej wiarygodnym „serwisem informacyjnym” (polecamy przeczytać: (Nowy artykuł Vitalika: Od rynków przewidywań do finansów informacyjnych)). Polymarket może być najbardziej przyciągającą „atrakcją” w tej turze innowacji blockchain.
Jak Polymarket, mający znaczenie "rewolucji blockchain", został technicznie zrealizowany? Programista inteligentnych kontraktów Pavel Naydanov szczegółowo przedstawił technologie stosowane przez Polymarket, co może być inspirujące dla deweloperów (szczególnie dla nowicjuszy w budowaniu rynków przewidywania). Odaily Planet Daily skompilował część dotyczącą realizacji technologii w następujący sposób, a teraz zagłębimy się w szczegóły techniczne tego protokołu.
CTF: Tokenizacja wyników
Wszystkie wyniki zdarzeń na Polymarket są tokenizowane:
Takie tokeny mogą być nazywane tokenami Share;
Udziały są wykupywane za pomocą aktywów bazowych, więc są całkowicie zabezpieczone;
Udziały mogą być sprzedawane w zamian za aktywa bazowe.
Tokeny Share są realizowane w oparciu o warunkowy framework tokenów Gnosis (CTF), który udowodnił swoją skuteczność i przeszedł testy w różnych protokołach. CTF może obsługiwać maksymalnie 256 wyników dla każdego zdarzenia.
Każde przewidywanie jest identyfikowane w CTF, dlatego przypisywany jest im unikalny identyfikator warunkowy, składający się z hasza trzech parametrów:
Oracle: adres oracla, który określi wyniki zdarzenia, zapewnia, że tylko określony oracle może rozliczyć przewidywanie;
ID problemu: identyfikator przewidywania, ustalany przez twórcę pytania przewidywania. Może to być prosty licznik, który zwiększa się o jeden dla każdego nowego przewidywania, lub bardziej skomplikowany schemat wykorzystujący tekst i inne dane haszowe;
outcomeSlotCount: liczba możliwych wyników przewidywania.
Poniższy obrazek ilustruje, jak działa CTF (warunkowy framework tokenów):
Użytkownicy dostarczają aktywa bazowe do zakładów i otrzymują tokeny Share, nazywane warunkowymi tokenami w CTF. Po tym, jak oracle ustali przewidywanie, użytkownicy mogą odebrać nagrody na podstawie wyników przewidywań z CTF.
Gdy użytkownicy otrzymują warunkowe tokeny, są uważani za określających konkretną pozycję. W CTF pozycje reprezentują zestaw możliwych kombinacji wyników dla każdego przewidywania. CTF generuje te pozycje dla każdego przewidywania, a każda pozycja odpowiada jednej z możliwych kombinacji wyników, które użytkownik może wybrać.
Na przykład:
Jaki film w 2024 roku zarobi najwięcej?
Ekipa Umysłu 2
Deadpool 3
Joker 2
Gru, Dru i Minionki 4
Dune 2
Mad Max 4
Inne
Użytkownicy mogą głosować, że (Ekipa Umysłu 2) stanie się najbardziej dochodowym filmem, lub że (Dune 2) na pewno nie stanie się najbardziej dochodowym filmem w 2024 roku. Ta kombinacja przewidywań będzie traktowana jako ich pozycja.
CTF oferuje dwa interesujące mechanizmy zarządzania pozycjami: podział i łączenie. Mechanizm podziału pozwala podzielić jedną pozycję na wiele oddzielnych wyników, podczas gdy łączenie scala różne wyniki w jedną pozycję. Te mechanizmy umożliwiają użytkownikom elastyczne zarządzanie swoimi pozycjami.
CTF zapewnia Polymarketowi cztery ważne zalety:
Tokeny Share mogą być używane do potwierdzania głosów użytkowników na konkretne wyniki przewidywań;
Zrealizowano elastyczny system, który łączy głosy użytkowników w różne pozycje;
Na podstawie sygnałów oracla, odpowiedzialność za obliczanie wyników delegowana jest do CTF;
Nagrody obliczane są na podstawie liczby tokenów Share za zwycięski wynik.
Warto również zauważyć, że CTF umożliwia organizowanie powiązanych działań, w których pozycje użytkowników mogą być scalane. Jednak na Polymarkecie w tej chwili nie ma takich przykładów. Aby dowiedzieć się więcej o CTF, można zapoznać się z oficjalną dokumentacją.
Mechanizm zamówień
Aby dokonać zakupu, interfejs Polymarket oferuje trzy rodzaje zamówień:
Rynek - natychmiastowy zakup po bieżącej cenie rynkowej;
Limit - zlecenie opóźnione, które pozwala określić cenę zakupu po osiągnięciu danej ceny;
AMM - zakup po cenie automatycznie określonej w sposób podobny do zdecentralizowanej giełdy, na podstawie kwoty rezerw w puli.
Na chwilę obecną funkcja zamówień AMM wydaje się być nieaktywna, nie znaleziono przewidywań, które pozwalałyby na zakupy za pośrednictwem AMM. Komentarz jednego z użytkowników na Discordzie Polymarket w pewnym stopniu wyjaśnił tę sytuację.
AMM jest przestarzałe
Według dokumentacji Polymarket, AMM został opracowany jako część inteligentnego kontraktu w ramach warunkowego frameworku tokenów. Dlatego AMM jest używany do ustalania ceny zakupu Sharetoken. Ta podstawowa mechanika wymaga płynności, aby zapewnić stabilność cen i zredukować zmienność. Dostawcy płynności potrzebują ekonomicznych zachęt, aby uzyskać nagrody z każdego zakupu, aby utrzymać system w ruchu.
Początkowo Polymarket mógł być w pełni oparty na CTF, wykorzystując AMM do określenia ceny. Jednak z biegiem czasu protokół opracował hybrydowe rozwiązanie z książką zamówień, a inne dwa typy zamówień (limitowane i rynkowe) zaczęły działać na tym dostosowanym rozwiązaniu. Rozwiązanie to nazywa się CLOB (Centralny Limit Order Book) lub BLOB (Binarny Limit Order Book).
CLOB i BLOB
CLOB (Centralny Limit Order Book) lub BLOB (Binarny Limit Order Book) to system reprezentujący mieszany zdecentralizowany książkę zamówień. W tym systemie dedykowani operatorzy zajmują się dopasowywaniem zamówień i uruchamianiem wykonania inteligentnych kontraktów.
Nie trzeba zbyt wiele wyjaśniać, system wygląda jak na poniższym rysunku:
Użytkownicy tworzą zamówienia do wykonania, mogą to być zlecenia limitowane lub rynkowe; operator dopasowuje zamówienia użytkowników i uruchamia wykonanie na inteligentnym kontrakcie, tworzenie zamówień oznacza tworzenie struktury danych podpisanej za pomocą klucza prywatnego użytkownika według standardu EIP-712. Zlecenia są przechowywane poza łańcuchem przed wykonaniem, co pozwala na szybkie i darmowe dostosowanie warunków zamówienia, a nawet całkowite ich anulowanie.
Jednak wszystkie kwestie związane z książkami zamówień i dopasowywaniem zamówień można uzyskać tylko przez API, dla wygody Polymarket oferuje dwa klientów: jeden używający JavaScript, a drugi używający Pythona.
Jednak kontrakt inteligentny Exchange.sol jest publiczny i odpowiedzialny za tworzenie pozycji użytkowników w CTF. Umożliwia także zarządzanie pozycjami użytkowników i transfer aktywów między nimi, co zapewnia bezpieczeństwo i przejrzystość w ramach protokołu.
Ten inteligentny kontrakt przeszedł audyt, a raport z audytu jest dołączony do repozytorium.
Inteligentny kontrakt
Inteligentny kontrakt Exchange ma w rzeczywistości bardziej szczegółową nazwę, tzn. CTFExchange.sol. Nie jest zbyt duży, ma około 100 linii kodu, ale ma wiele zależności.
Większość z nich to małe inteligentne kontrakty o ograniczonej funkcjonalności:
BaseExchange.sol: Abstrakcyjny inteligentny kontrakt, który implementuje możliwość odbierania tokenów ERC-1155 oraz zapobiega atakom reentrancy;
Auth.sol: Menedżer ról, definiuje funkcje weryfikujące i modyfikatory do ustawiania ról, admin i operator z CTFExchange.sol;
Assets.sol: Definiuje dwa rodzaje aktywów, aktywa bazowe (zabezpieczenie) i adres CTF;
Fees.sol: Definiuje opłaty protokołu;
Pausable.sol: Definiuje możliwość zawieszenia operacji inteligentnego kontraktu, protokół zgadza się na przyjęcie centralizowanej formy w przypadkach nieprzewidzianych. Dotyczy tylko roli admina;
AssetOperation.sol: Definiuje operacje na aktywach bazowych i CTF. Obejmuje transfery pozycji, podział i łączenie;
Signature.sol: Definiuje kod używany do weryfikacji podpisów użytkowników przy składaniu zamówień;
Hashing.sol: Definiuje hasz wartości parametrów zamówienia, używany do weryfikacji podpisów;
Registry.sol: Definiuje proces rejestracji przewidywań w systemie i związane z nimi tokeny przewidywań.
Wszystko, co dotyczy rzeczywistego wykonywania zamówień, jest realizowane w inteligentnym kontrakcie Trading.sol. Przeglądanie kodu i badanie inteligentnych kontraktów jest również proste. Struktura definiuje punkty wejścia za pomocą funkcji:
fillOrder() - wykonuje zlecenie między użytkownikiem, który utworzył zamówienie, a zamówieniem wybranym przez użytkownika (innym zamówieniem);
fillOrders() - to samo co fillOrder(), ale dla listy zamówień;
matchOrders() - operator wybiera dwa różne zamówienia i je wykonuje.
Wszystkie powyższe funkcje mogą być wywoływane tylko przez operatora.
Bez względu na to, jak wywołanie wchodzi do inteligentnego kontraktu, rezultat zawsze jest taki sam: dwóch użytkowników wymienia tokeny na podstawie swoich zamówień.
Opłaty protokołu
Opłaty są pobierane na podstawie aktywów wyjściowych. W przypadku przewidywań binarnych opłaty są symetryczne, co oznacza: jeśli użytkownik sprzedaje tokeny za 0,99 USD, zapłaci taką samą opłatę, jak kupujący, który kupuje tokeny za 0,01 USD.
Formuła obliczeniowa jest prosta, pochodzi z dokumentacji oficjalnej:
Program nagród za płynność
Ogólnym celem programu jest zachęcenie do płynności rynkowej.
Aby giełda oparta na książce zamówień działała, ktoś musi stworzyć zlecenia limitowane, które zapewniają płynność umożliwiającą natychmiastowe wykonanie zleceń po cenie rynkowej. Użytkownicy, którzy tworzą zlecenia limitowane, nazywani są makerami rynku. Im większa „bliskość” zlecenia limitowanego do ceny rynkowej, tym szybciej realizowane są zlecenia rynkowe, a wolumen transakcji jest większy, co niewątpliwie jest korzystne dla użytkowników końcowych. Ponadto większa płynność utrudnia manipulację rynkiem.
Aby zapewnić wystarczającą płynność, Polymarket wprowadził specjalny program nagród, aby zachęcić użytkowników do składania zleceń limitowanych. Im bliżej średniej ceny rynkowej zlecenie limitowane, tym wyższa nagroda. Nagrody będą automatycznie wypłacane codziennie o północy (czasu UTC).
System wzoruje się na dYdX, aby dowiedzieć się więcej, można zapoznać się z oryginalnym programem nagród za płynność dYdX i szczegółową formułą obliczania nagród płynności w Polymarket.
Oracle
Oracle jest używany do dostarczania wyników przewidywań - niezależnie od tego, czy zdarzenie miało miejsce. Oracle jest jednym z najważniejszych komponentów protokołu, ale jest obsługiwany przez usługi zewnętrzne, a nie przez zespół Polymarket, ten oracle nazywa się UMA.
UMA to zdecentralizowany oracle, który został zaprojektowany do rejestrowania wszelkiego rodzaju danych w blockchainie, z wyjątkiem tych, które nie mogą być zweryfikowane. Ten oracle jest optymistyczny, chyba że wystąpi spór, w przeciwnym razie dane domyślnie uznawane są za poprawne. UMA ma własny system arbitrażu do rozwiązywania sporów, a arbitrzy to prawdziwi ludzie - uczestnicy ekosystemu UMA, w szczególności posiadacze tokenów UMA. Ten system nazywa się DVM (mechanizm weryfikacji danych).
Poniższy proces służy do określenia wyników przewidywań i rejestrowania ich na blockchainie:
Oświadczenie: Przewidywanie dodane do oracla wraz z nagrodą. Każdy, kto skutecznie zakwestionuje wynik przewidywania, może odebrać nagrodę;
Okres wyzwania: w tym okresie każdy może zakwestionować wyniki przewidywania. Jeśli nie wystąpią wyzwania, a czas upłynie, wyniki przewidywania uznaje się za gotowe do ostatecznego rozliczenia, co wskazuje na ich dokładność;
Spór: każdy uczestnik protokołu może kwestionować wyniki, niezależnie od tego, czy chodzi o uzyskanie nagrody, czy o sprawiedliwość. W rzeczywistości sytuacja ta rzadko się zdarza, ponieważ teoria gier wskazuje, że większość uczestników działa uczciwie.
Głosowanie: jeśli wystąpi spór, posiadacze tokenów UMA będą głosować w celu rozwiązania sporu. UMA jest protokołem tokenów używanych do głosowania, a uczestnicy uzyskują nagrody za udział w głosowaniu.
Rozliczenie: Ostateczny etap to proces rozliczenia, czyli faktyczne rejestrowanie danych na blockchainie. Po tym przewidywania mogą być uznawane za wiarygodne.
Cały protokół oparty jest na teorii gier, gdzie wszelkie złe działania uczestników są ekonomicznie niekorzystne.
Uczestnicy składający przewidywania dostarczają inteligentnemu kontraktowi zabezpieczenie. Jeśli ich wyniki zostaną zakwestionowane, stracą zabezpieczenie; w przeciwnym razie odzyskają zabezpieczenie i otrzymają nagrodę. Tworzy to silną motywację do składania jedynie dokładnych wyników.
Uczestnicy, którzy kwestionują wyniki przewidywania, również dostarczają zabezpieczenie. Jeśli mają rację, odzyskają zabezpieczenie i otrzymają nagrodę; w przeciwnym razie stracą zabezpieczenie. To motywuje uczestników do kwestionowania tylko tych wyników, co do których są pewni, że są błędne.
Uczestnicy rozwiązujący spory. Muszą stakować tokeny UMA i będą otrzymywać nagrody za rozwiązanie sporu. Jeśli zagłosują źle lub w ogóle nie zagłosują, stracą część swojego stakowanego salda; w przeciwnym razie otrzymają nagrodę. Nie ma możliwości leniuchowania.
Szczególnie warto zauważyć, że proces głosowania w sporze jest podzielony na dwa etapy za pomocą schematu commit/reveal:
Commit: Zgłoszenie, uczestnicy tajnie głosują, przesyłając hasz głosowania do inteligentnego kontraktu, co oznacza, że nikt nie może rozpoznać, jak uczestnicy głosowali, tylko na podstawie hasza.
Reveal: Ujawnić, po zakończeniu etapu głosowania, uczestnicy ujawniają swoje głosy, a inteligentny kontrakt weryfikuje, czy odpowiadają one wcześniej przesłanemu haszowi.
Ten dwuetapowy proces głosowania zapobiega zmowie wyborców w celu zdyskredytowania oracla lub zaatakowania usług, które polegają na wynikach przewidywań. Jednocześnie wyniki przewidywań mogą być wielokrotnie kwestionowane, a w takim przypadku UMA pozwala na wznowienie procesu decyzyjnego po zakończeniu wcześniejszego sporu.
Proces wszczynania sporów wygląda następująco:
Wnioski
Polymarket, na pozór prosty system zakładów i przewidywań, w rzeczywistości składa się z trzech głównych modułów, z których każdy został opracowany przez różne protokoły i zespoły:
CTF (warunkowy framework tokenów): zarządza kombinacjami, pozycjami i Share w przewidywaniach, ten elastyczny framework stworzony przez Gnosis jest idealny do rynków przewidywań.
CLOB (Centralny Limit Order Book): wewnętrzne rozwiązanie Polymarket do wdrażania książek zamówień i zleceń limitowanych. CLOB pozwala użytkownikom skutecznie uczestniczyć w ekosystemie i pomaga w agregacji płynności.
UMA: zdecentralizowany oracle z unikalnym systemem arbitrażu do rozwiązywania sporów. UMA jest rdzeniem systemu, przesyła wyniki przewidywań przez blockchain.
Mimo że Polymarket to system zakładów, technicznie rzecz biorąc, protokół skutecznie łączy technologie z różnych projektów, co czyni go szczególnie atrakcyjnym dla deweloperów.
Powiązane artykuły
Jak długo Polymarket i gorączka rynków przewidywań będą istnieć po wyborach prezydenckich w USA?
Jak Polymarket przewyższa tradycyjne sondaże wyborcze?
