Wróć do blogamarket-rules

Jak pisać weryfikowalne zasady rynku

Zamień niejednoznaczną prognozę w weryfikowalne zasady rynku, a następnie prześledź pierwotne dane rozstrzygnięcia Kuest, zewnętrzne metadane i historię zmian powiązaną z twórcą.

Lupa i mały zegar podkreślają precyzyjne zasady w dokumencie rynku.

„Czy temperatura osiągnie 30 stopni?” pozostawia miejsce na kilka różnych transakcji. Zaokrąglona prognoza w aplikacji pogodowej, temperatura zmierzona przez stację i oficjalny raport opublikowany później mogą się różnić. Rynek musi określić, które z nich decyduje o wypłacie, zanim ktokolwiek kupi YES lub NO.

Ten szósty artykuł serii Jak działają Polymarket i Kuest przekształca to pytanie w regułę, którą można przetestować, a potem śledzi jej dowody przez oddzielne warstwy systemu. Czytelna strona, utrwalone bajty rozstrzygnięcia i dostępny dokument metadanych dowodzą różnych rzeczy.

Przepisuj pytanie, aż dwaj czytelnicy uzyskają tę samą odpowiedź

Zachowajmy fikcyjne Obserwatorium A, Miasto B i Dzień C. „O 12:00” musi wskazywać czas obserwacji albo termin publikacji; to różne zdarzenia. Przepisz tytuł: „Czy obserwacja Obserwatorium A dla Miasta B o 12:00 UTC w Dniu C wyniesie co najmniej 30,0°C?” Następnie określ dowody:

Użyj oficjalnego pliku CSV dziennych obserwacji Obserwatorium A, stacja B-01, dla Dnia C. Odczytaj pole temperatury powietrza w stopniach Celsjusza dla rekordu ze znacznikiem 12:00:00 UTC. Użyj najnowszej oficjalnej rewizji dostępnej do 13:00:00 UTC w Dniu C, włącznie z rewizją opublikowaną dokładnie w tym terminie. Porównaj opublikowaną wartość liczbową bezpośrednio z 30,0; nie zaokrąglaj jej ponownie. Poprawna wartość 30,0 lub wyższa oznacza YES; poprawna niższa wartość oznacza NO. Pomiń prognozy, inne stacje i późniejsze rewizje. Jeśli w tym terminie rekord został wycofany, sprzeczne rekordy nie mają wiążącej kolejności rewizji lub brak poprawnego rekordu, użyj określonego wyniku dla niedostępnych danych.

W rzeczywistym rynku zastąp każdą fikcyjną nazwę i datę dokładnym adresem URL źródła, identyfikatorem stacji, datą kalendarzową i definicją pola. Samo „oficjalna strona” pozostawia czytelnikom wybór między stronami, kopiami i rewizjami. Źródło zapasowe również potrzebuje określonego pierwszeństwa; inaczej dodaje kolejny wybór po poznaniu wyniku.

Tutaj 29,96 oznacza NO, nawet jeśli aplikacja pokazuje 30,0. Korekta z 29,9 na 30,1 przed terminem oznacza YES; taka sama korekta później nie zmienia wybranej obserwacji. Równość jest wyraźnie YES, więc próg nie ma nierozstrzygniętego remisu.

Oficjalne źródło dostarcza obserwację w południe i termin rewizji 13:00 UTC, po których następują oznaczone gałęzie wypłaty YES, NO i niedostępnych danych.

Czas obserwacji wybiera rekord. Termin wybiera jego rewizję. Polityka wypłat obsługuje brak dowodów.

Wynik dla niedostępnych danych musi odpowiadać wybranej ścieżce kontraktu. W tym przykładzie dydaktycznym załóż standardowy adapter binarny obsługujący UNKNOWN: YES wypłaca jedną jednostkę zabezpieczenia, a NO zero przy wyniku YES, odwrotnie przy NO, a przy UNKNOWN każdy wypłaca połowę. To wyraźne założenie modelu, nie uniwersalna reguła anulowania ani polityka wypłat NegRisk.

Pół jednostki na token nie jest zwrotem ceny jego zakupu. Uczestnik, który zapłacił 0,80 za YES, otrzymuje 0,50 przy tym założonym wyniku. Mechanika podziału i wykupu określa wypłatę; zasady określają, który obsługiwany wynik należy zgłosić.

Termin źródła, zakończenie przyjmowania zleceń i czas rozstrzygnięcia służą różnym celom. Pierwszy wybiera dowody, drugi kontroluje przyjmowanie zleceń, trzeci zapisuje wynik. Na przykład zlecenia mogą przestać być przyjmowane o 11:55 UTC, podczas gdy dopuszczalne rewizje pozostają otwarte do 13:00; rozstrzygnięcie może nastąpić później. Operator musi skonfigurować handel osobno, a opóźniona transakcja nie przedłuża terminu dowodowego.

Śledź dwa rodzaje dowodów

Rynek potrzebuje zarówno zdefiniowanego pytania rozstrzygnięcia, jak i czytelnych informacji pomocniczych. Ancillary data oznacza dodatkowe bajty pytania używane przez konkretną integrację wyroczni; metadane opisowe mogą też obejmować obrazy, etykiety i linki. Służą różnym celom i nie należy traktować ich jako zamiennych zobowiązań.

Publiczny adapter CTF Polymarket jest przykładem danych pytania zapisanych w określonym kodowaniu. Ponowne obliczenie zobowiązania kryptograficznego wymaga dokładnie tego kodowania, nie wizualnie podobnego akapitu. Sprawdź opublikowany interfejs wybranego wdrożenia zamiast uogólniać przykład na wszystkie rodziny adapterów.

Zobowiązanie do treści pytania i czytelny dokument zasad to różne dowody. Porównaj dokładnie zapisane pytanie z bieżącym dokumentem i jego odwołaniem.

Zobowiązanie do treści pytania i zewnętrzny dokument wspierają różne kontrole; samo odwołanie nie dowodzi integralności ani dostępności.

Publicznie zweryfikowany kontrakt Conditional Tokens Kuest zapisuje twórcę i odwołanie do zewnętrznych metadanych. Odwołanie lokalizuje informacje; samo nie dowodzi, że dokument jest dostępny, niezmienny lub identyczny z pierwotnym zobowiązaniem rozstrzygnięcia. Pobierz dokumenty i porównaj je z zapisanymi dowodami pytania.

Publiczna dokumentacja tworzenia rynków Kuest opisuje obsługiwany interfejs produktu. Przesłany dokument, przygotowany warunek i rynek dostępny do handlu to osobne obserwacje. Potwierdź właściwe rekordy zamiast wywodzić wszystkie trzy z jednego ekranu sukcesu.

Podobne identyfikatory mają różne zadania

Slug lokalizuje stronę. Identyfikator pytania identyfikuje pytanie według schematu adaptera. Identyfikator warunku łączy wyrocznię, identyfikator pytania i liczbę wyników w publicznej konstrukcji CTF. Dokładne dane wejściowe mają znaczenie; podobny tekst strony nie dowodzi identycznych warunków.

Identyfikator pozycji identyfikuje posiadane i handlowane aktywo. W CTF jego wyprowadzenie zależy też od zabezpieczenia i kolekcji reprezentującej zbiór wyników. Zgodne tytuły lub slugi nie dowodzą identycznych aktywów. Adres twórcy zapisuje autorstwo i określone uprawnienia; identyfikator zewnętrznych metadanych lokalizuje treść opisową. Żaden nie zastępuje identyfikatora warunku lub pozycji.

Nawet „identyfikator pytania” nie jest uniwersalnym kodowaniem. W konkretnym NegRiskIdLib Polymarket pytanie współdzieli pierwsze 31 bajtów identyfikatora swojego rynku i używa ostatniego bajtu jako indeksu pytania. Stosuj tę regułę tylko do tej rodziny adapterów, nie do każdego pytania wyroczni.

Pole metadata w podpisanym zleceniu giełdowym jest innym obiektem. Na przykład publiczna definicja CTF Exchange V2 zawiera bytes32 metadata na poziomie zlecenia. Jego obecność nie dowodzi, że podpis zobowiązuje do wyświetlanego dokumentu rynku.

Zmiana możliwa do prześledzenia nadal jest zmianą

Rozszerzenie Conditional Tokens Kuest zapisuje twórcę warunku i bieżące odwołanie do zewnętrznych metadanych. Twórca lub administrator CTF może je zastąpić. Każde udane wywołanie zwiększa licznik i emituje identyfikator warunku, stare odwołanie, nowe odwołanie oraz adres aktualizującego.

Przeanalizowana funkcja nie blokuje zmian przy rozstrzygnięciu i nie sprawdza, czy nowy ciąg wskazuje dostępną, niepustą treść. Niezmieniony identyfikator warunku nie oznacza więc, że jego bieżący wyświetlany opis nigdy się nie zmienił. Aktualizacja może też dodać odwołanie pomocnicze lub poprawić obraz; porównaj rzeczywiste dokumenty przed oceną, czy zmieniło się twierdzenie rynku.

Pierwotny dokument pytania pozostaje oddzielny od odwołań metadanych A i B, ze zmianą twórcy lub administratora, zdarzeniem starego i nowego odwołania oraz zwiększonym licznikiem.

Aktualizacja odwołania może wzbogacić dokument lub zmienić jego opis. Zdarzenie ujawnia, kto zmienił wskaźnik; porównaj treść.

Zmiana wskaźnika nie przepisuje pierwotnych bajtów pytania i nie nadaje nowego prawa do zgłaszania wypłat. Funkcja zgłaszania CTF wyprowadza warunek, używając wywołującego jako wyroczni. Adapter i jego skonfigurowana ścieżka rozstrzygnięcia określają, jak wynik dociera do tej funkcji; prawo edycji metadanych jest osobnym uprawnieniem.

Załóżmy, że wersja A podaje 30,0°C, a wersja B 31,0°C. Zdarzenie historii uwidacznia podmianę; nie dowodzi, że 31,0 stało się prawomocnym progiem. Porównaj obie wersje z pierwotnymi bajtami ancillary data i odpowiednią polityką wyjaśnień przed interpretacją zmiany.

Wyjaśnienia potrzebują autora i polityki

Polymarket już ma zobowiązania do treści pytań on-chain. Wskazana wersja jego adaptera UMA CTF haszuje i przechowuje rozszerzone ancillary data, a tablica komunikatów zapisuje aktualizacje z przypisanym autorstwem. To konkretne mechanizmy adaptera CTF, nie twierdzenie o ABI każdej aktualnej ścieżki Polymarket.

Wyjaśnienie potrzebuje też identyfikowalnego autora i obowiązującej polityki. W publicznym przykładzie Polymarket wpis z przypisanym autorem nie przepisuje pierwotnych ancillary data. Nie traktuj dowolnego oświadczenia wspominającego pytanie jako oficjalnej zmiany.

Aktualna dokumentacja rozstrzygnięć Polymarket mówi, że kontekst wyjaśnień powinien zachować podstawową intencję. Wskazanie kolumny CSV o zmienionej nazwie może doprecyzować dowody; zastąpienie progu 30,0 progiem 31,0 zmienia twierdzenie. Znacznik czasu dowodzi, kiedy zapisano oświadczenie, nie tego, że ma ono prawomocną moc.

Sprawdź drogę od odwołania do ekranu

Praktyczny przegląd śledzi dowody po kolei:

  1. Zidentyfikuj wdrożenie. Zapisz sieć, adresy kontraktów, rodzinę adaptera i odniesienie do bloku. Uzyskaj potwierdzenie utworzenia, pierwotne bajty pytania, tożsamość wyroczni, twórcę i identyfikator warunku.
  2. Oblicz ponownie właściwe identyfikatory. Użyj kodowania tej implementacji, sposobu obsługi inicjalizacji i liczby wyników. Sprawdź identyfikatory pozycji względem rzeczywistego zabezpieczenia i mapowania wyników.
  3. Prześledź historię metadanych. Odczytaj odwołanie z przygotowania, bieżące odwołanie, licznik i logi aktualizacji. Pobierz pierwotne i zastępujące dokumenty, następnie porównaj zmiany i adresy aktualizujących.
  4. Sprawdź osobno integralność i dostępność. Zweryfikuj treść za pomocą rzeczywistego schematu transakcji lub zobowiązań systemu przechowywania. Zachowaj dokładne pobrane bajty i ich pochodzenie; zapisane odwołanie nie udostępni dokumentu, którego nikt nie potrafi pobrać.
  5. Porównaj to, co widzą uczestnicy. Zestaw wyświetlane źródło, daty, zasady i etykiety wyników z pierwotnymi danymi rozstrzygnięcia i autoryzowanym kontekstem. Czytelny interfejs nie jest niezależną kontrolą integralności.
Odwołanie kontraktu, pobrany dokument, historia aktualizacji i wyświetlane zasady są sprawdzane po kolei, z osobnymi kontrolami integralności, dostępności i autora.

Dostępny dokument, prawidłowe pochodzenie i zgodne wyświetlanie to oddzielne kontrole. Żadna sama nie dowodzi poprawnego rozstrzygnięcia.

Dla operatora pod własną marką konkretnym dodatkiem Kuest są odwołania do metadanych powiązane z twórcą i widoczna historia zmian obok pierwotnych danych rozstrzygnięcia. Wspiera to katalog możliwy do przeglądu i proces publikacji z przypisanym autorstwem. Nie umieszcza wszystkich informacji rynku on-chain, nie gwarantuje dostępności dokumentów ani nie rozstrzyga sporu o znaczenie.

Uruchom własny rynek predykcyjny z Kuest, przygotowując określonych odbiorców i jurysdykcje, dopracowaną kartę zasad, politykę źródeł i korekt, obsługiwaną ścieżkę rozstrzygnięcia oraz plan zachowania dostępnych dowodów. Przetestuj te dane na niejednoznacznych przykładach przed przyjęciem transakcji.