Doposud pokračuje mýtus o blahobytu v měnovém kruhu/blockchainovém průmyslu a další důležitou oblastí „vytváření bohatství“ je zaměření na „herní dráhu“. Projekt XAI pořádá událost Odyssey Pokud máte zájem, zúčastněte se tohoto mého článku na náměstí: XAI Game Public Chain Odyssey Event Zero-Cost Beginner’s Guide.
V tomto článku vám přinesu podrobné vysvětlení Sentry uzlu herního veřejného řetězce XAI! Tento článek je poměrně technický, takže pokud máte zájem vydělávat peníze, musíte si jej pozorně přečíst. Protože pouze pokud sami pochopíte "logiku" a zlepšíte své poznávání, můžete mít příležitost vydělat peníze!
Pokud chcete vidět přímo o uzlu Sentry, přečtěte si první část přímo bez pozdějšího čtení, pokud chcete logickou uzavřenou smyčku, musíte si přečíst druhou, třetí a čtvrtou část!
Chci zdůraznit, že Xai dostává přímou technickou podporu od Offchain Labs. Tento druh podpory je u jiných řetězců Orbit nepředstavitelný! a je klíčovou součástí strategického herního plánu společnosti Xai v rámci ekosystému Arbitrum.
Část 1: Vysvětlení strážního uzlu
Sentry uzel je pozorovací uzel, který monitoruje protokol Xai rollup, a pokud je navržen špatný blok, spustí výstrahu (jakýmikoli prostředky, které si jeho operátor zvolí), aby ostatní mohli zasáhnout. Účelem sentinelového uzlu je vyřešit dilema ověřovatele (podrobnosti o dilematu ověřovatele viz část IV).
Kliknutím sem zobrazíte propagační video:
Spusťte uzly Xai a získejte tokeny Xai jedním kliknutím!
Sentinelové uzly mohou běžet na noteboocích, počítačích nebo dokonce cloudových instancích členů komunity. Dokud uzel běží, existuje pravděpodobnostní algoritmus, který určuje, zda bude operátor uzlu odměněn tokeny esXai ze sítě. Vysazením Xai zvýšíte pravděpodobnost algoritmu. Pokud o esXai nevíte, zapojte se prosím do mého článku na náměstí: Výklad „Token Economy“ projektu XAI
1. Princip činnosti sentinelové uzliny
Protokol Attention Challenge v2 zahrnuje více účastníků, včetně řetězce Xai, mateřského řetězce (Arbitrum One), důvěryhodného vyzyvatele, Xai sentinels a jejich licenčních klíčů a smlouvy s rozhodčím (rozhodčím). Vyzyvatel vytvoří pár klíčů BLS, zaregistruje veřejný klíč ke smlouvě s rozhodčím a podepíše nároky provedené validátorem v protokolu Xai rollup na Arbitrum One. Tyto podpisy jsou ověřeny rozhodčí smlouvou a zaznamenány jako výzvy spojené s reklamací.
Xai Sentinel se může zaregistrovat do smlouvy s rozhodčím zakoupením licenčního klíče Sentinel, aby byl způsobilý publikovat prohlášení o nárocích. Dostanou státní kořen správného výpisu, který bude následníkem vydávajícího výpisu. Pokud je splněna určitá podmínka, vydají prohlášení o prohlášení s odvoláním na rozhodčí smlouvu. Pokud je vytvořeno a potvrzeno následné prohlášení a Sentinel vydá správné prohlášení, Sentinel se obrátí na rozhodčího kontraktu, aby vydal transakci zpětného odkupu. Před vyplacením odměny Sentinelu rozhodčí ověří několik podmínek.
Tento protokol zajišťuje, že každý nárok musí plně spotřebovat zprávy doručené pošty, které existovaly, když byl vytvořen jeho předchůdce. To znamená, že jakmile je deklarace vytvořena, jsou plně určeny stavové kořeny jejích správných následných deklarací a mohou být spočítány jakýmkoliv uzlem. To povzbudí každého sentinela, aby určil správný kořen dalšího stavu. Odměna hlídače je určena ID státního oprávnění hlídače, následným kořenem stavu a hodnotou výzvy, která není známa, dokud není plně určen následující kořenový stav.
2. Kdo může provozovat uzel?
Sentinel může ovládat kdokoli stažením softwaru, jeho instalací a spuštěním. Chcete-li však získat tokenové odměny, musíte si zakoupit alespoň jeden licenční klíč Sentinel.
Kupující musí úspěšně projít kontrolou KYC, aby se ujistili, že:
ne ve Spojených státech
Nepodléhá žádným sankcím USA OFAC (OFAC je uveden v seznamu sankcí USA)
Ty Sentinel uzly, které neběží nebo nemají odpovídající finanční prostředky na placení poplatků za plyn (GAS), nebudou získávat odměny, a to ani s licenčním klíčem. Operátoři proto budou chtít zajistit, aby jejich uzly byly financovány, online a fungovaly.
3.Rozhodčí (rozhodčí) smlouva
Referee je chytrá smlouva navržená tak, aby vynucovala dodržování předem definovaných pravidel, ověřovala původ příspěvků a rozdělovala odměny vítězům v rámci systému. Inteligentní smlouva rozhodčího je klíčovou složkou v ekosystému Xai, která je zodpovědná za správu a ověřování nároků podaných sentinelovými uzly v síti. Smlouva má několik klíčových funkcí:
3.1 Předložení vyjádření
Smlouva rozhodčího umožňuje sentinelovým uzlům podávat nároky na výzvy. Tuto funkci může volat pouze vlastník licenčního klíče Sentinel nebo jeho schválená adresa na této smlouvě. Tato funkce kontroluje, zda je výzva stále otevřena k odeslání a zda již byla pro tuto výzvu odeslána licence NodeLicense.
3.2 Získejte odměny
Smlouva obsahuje funkci, která uživatelům umožňuje požadovat odměny za úspěšné reklamace. Tato funkce zkontroluje, zda byla výzva uzavřena pro odeslání, a zkontroluje, zda vlastník klíče uzlu dokončil KYC. Pokud jsou tyto podmínky splněny a reklamace je způsobilá k výplatě, odměna bude uživateli zaslána.
3.3 Vytvořte hash nároku a zkontrolujte platbu.
Smlouva má funkci, která vytváří hash ID oprávnění sentinelu, ID výzvy, challengerSignedHash ve výzvě a následný kořen stavu. Poté zkontroluje, zda je hash pod určitou hranicí, která se vypočítá na základě celkového počtu vyražených licencí Sentinel. Pokud je hash pod prahovou hodnotou, nárok je způsobilý k platbě.
Smlouva s rozhodčím zajišťuje integritu sítě Xai ověřováním nároků a odměňováním úspěšných, čímž motivuje sentinelové uzly k přesnému a pečlivému monitorování sítě.
4. Součást Challenger
Vyzyvatel je důvěryhodná entita v ekosystému Xai. Vytvoří pár klíčů BLS a zaregistruje veřejný klíč do smlouvy rozhodčího. Když validátor vznese nárok v protokolu Xai rollup, vyzyvatel podepíše nárok pomocí svého soukromého klíče a předá podpis rozhodčímu. Rozhodčí ověří podpis a zaznamená jej jako výzvu spojenou s prohlášením. Tento proces zajišťuje integritu nároků učiněných v protokolu Xai rollup.
5. Klíč (oprávnění klíče uzlu Sentinel, založené na NFT)
Licenční klíč Sentinel je jedinečný, nezaměnitelný token (NFT), který je nutný k provozu uzlu Sentinel v síti Xai. Licence Sentinel slouží jako důkaz způsobilosti pro uzly podávat nároky a přijímat odměny. Je ražen zasláním správného množství ETH a cena ražby je určena systémem zvyšujících se prahů.
Klíčovou roli ve smlouvě s rozhodčím hraje licencování uzlů. Když chce uzel odeslat nárok na výzvu, musí poskytnout své ID oprávnění Sentinel. Smlouva s rozhodčím kontroluje, zda je licence Sentinel platná a zda je uzel vlastníkem licence Sentinel nebo schváleným operátorem (část KYC výše). Pokud jsou tyto podmínky splněny, je nárok uzlu předložen k výzvě.
Oprávnění Sentinel vstupují do hry také při nárokování odměn za úspěšné nároky. Smlouva s rozhodčím kontroluje, zda vlastník licence Sentinel dokončil KYC a zda je výpis způsobilý k platbě. Při splnění těchto podmínek je odměna zaslána majiteli licence Sentinel.
Stručně řečeno, povolení Sentinel je klíčovou součástí sítě Xai, která reguluje provoz uzlů Sentinel, podávání nároků a rozdělování odměn.
6. Stažení a spuštění uzlu
Ke spuštění sentinelového uzlu si uživatelé potřebují stáhnout konkrétní softwarový balíček. Tento balíček lze použít v desktopové aplikaci nebo jako nástroj příkazového řádku na vašem počítači. Jednoduše řečeno, tyto aplikace jsou nástroje, které usnadňují používání softwaru Sentinel. Účelem tohoto balíčku je automatizovat všechny operace potřebné ke spuštění Sentinelu, takže je velmi jednoduché nastavit a používat, i když nejste technický.
Tento balíček pomáhá uživatelům s úkoly, jako je nastavení, správa a interakce s ostatními částmi, a má snadno použitelné rozhraní, které uživatelům umožňuje snadno prohlížet a upravovat nastavení. Pomocí tohoto balíčku se uživatelé mohou více soustředit na to, jak lépe běhat a získat více tokenových odměn. Uživatelé si mohou vybrat, zda budou tento balíček spouštět pomocí desktopové aplikace nebo nástroje příkazového řádku, přičemž obojí se velmi snadno používá a proces operace je velmi hladký.
7. Funkce peněženky Sentinel
V ekosystému Xai hraje peněženka Sentinel klíčovou roli v interakci mezi uzly Sentinel a rozhodovacími inteligentními smlouvami. Peněženka Sentinel funguje jako zprostředkovatel a je odpovědná za předkládání prohlášení rozhodčímu jménem příslušných Sentinelů. Toho je dosaženo prostřednictvím specifických funkcí v rozhodčí smlouvě, které může volat pouze vlastník licenčního klíče Sentinel nebo jeho schválená adresa na této smlouvě.
Peněženka Sentinel může odeslat prohlášení k výzvě voláním funkce submitAssertionToChallenge ve smlouvě rozhodčího. Tato funkce kontroluje, zda je výzva stále otevřena k odeslání a zda již byl pro tuto výzvu odeslán klíč uzlu.
Sentry Wallet může také požadovat odměny za úspěšné reklamace voláním funkce claimReward ve smlouvě s rozhodčím. Tato funkce zkontroluje, zda byla výzva uzavřena pro odeslání, a zkontroluje, zda vlastník licence Sentinel dokončil kontrolu „KYC“. Pokud jsou tyto podmínky splněny a reklamace je způsobilá k výplatě, bude odměna zaslána majiteli Sentinelu.
Stručně řečeno, peněženka Sentinel funguje jako messenger, který usnadňuje interakci mezi uzly a rozhodčími, čímž zajišťuje hladký provoz sítě Xai.
8. Licence
Zásadní je vztah mezi počtem licencí a možností odesílání uzlu. I když je možné, že k uzlu je přidruženo více licencí, je důležité si uvědomit, že počet licencí přímo ovlivňuje schopnost uzlu provést potvrzení. V zásadě, aby byly zajištěny spravedlivé kvóty potvrzení, je poměr licencí k instancím uzlů udržován na 1:1. Dodržováním výše uvedených principů systém zavádí strukturovaný přístup k licencování, předkládání práv a celkovému provozu uzlů v rámci ekosystému.
9.Požadavky na software a hardware vysílače
Software Sentinel node podporuje Windows desktop, Mac a Linux (vyžaduje 64bitový). Níže jsou uvedeny aktuální zdroje potřebné ke spuštění softwaru uzlu Sentinel pro až 100 licenčních klíčů:
4 GB RAM
2 jádra CPU
60 GB místa na disku
Procesor x86/X64 (podporuje procesor ARM, jako je čip Apple M1/M2)
Stabilní připojení k internetu
Při přidávání dalších klíčů do uzlu by se v ideálním případě měly odpovídajícím způsobem zvýšit možnosti hardwaru. Není však povinné přiřadit každému klíči samostatný stroj. Očekává se, že systém bude škálovatelný, aby pojal desítky klíčů na jednom počítači a možná i více.
Poznámka: Tyto hardwarové požadavky se mohou změnit.
10. Odhadované odměny sítě Sentry node
Ekonomický model tokenů XAI, viz: Výklad "Token Economy" projektu XAI
Zde jsou tři scénáře pro odhad odměn Xai, které můžete získat za provozování Sentry uzlu. Tyto tři scénáře jsou založeny na následujících předpokladech:
Součet XAI a esXAI nikdy nepřekročí 2 500 000 000. Vzhledem k tomu, že ekosystém Xai je dynamický, není možné přesně předpovědět měsíční odměny tokenů pro každý klíč Sentry.
100% PLYNU je spáleno, takže není zaručeno, že zásoba bude vždy inflační, může být deflační.
Xai Foundation neprodá více než 50 000 Sentry klíčů (uzel může načíst více klíčů). Očekává se, že to bude trvat 2–3 roky. Sentry klíče jsou časem dražší.
Měsíční částka esXAI na klíč Sentry může také kolísat v závislosti na počtu účastníků sázek v ekosystému.
Význam následujících tří tabulek je ten, že při různém oběhu tokenů XAI a esXAI je počet klíčů uzlů aktivovaných v síti a odpovídající očekávané měsíční odměny za tokeny na klíč:
Odhad scénáře A: Pokud je v oběhu celkem 750 000 tokenů XAI a esXAI, pak každý klíč Sentry obdrží odměny esXAI podle následující tabulky:
Scénář B Odhad: Pokud je v oběhu celkem 1 250 000 000 tokenů XAI a esXAI, pak každý klíč Sentry obdrží odměny esXAI podle následující tabulky:
Scénář C Odhad: Pokud je v oběhu celkem 2 187 500 000 tokenů XAI a esXAI, pak každý klíč Sentry obdrží odměny esXAI podle následující tabulky:
Část 2: XAI je vyvíjen a udržován společností Arbitrum (ARB), takže musíme trochu osvětlit architekturu Arbitrum:
1.Nitrorozhodnutí
Všechny řetězce Arbitrum jsou postaveny na Arbitrum Nitro, což je základní technologie pro všechny řetězce v ekosystému. Nitro provozuje rozvětvenou verzi Geth a používá WebAssembly jako svůj základní virtuální stroj odolný proti podvodům.
2. Rozhodnutí o jakékoli důvěře
Anytrust je protokol Arbitrum, který spravuje dostupnost dat prostřednictvím kolekce poskytovatelů licencí nazvané Výbor pro dostupnost dat (DAC – Data Availability Committee). Tento protokol snižuje transakční poplatky zavedením dalšího předpokladu důvěry ohledně dostupnosti dat namísto používání mechanismu dostupnosti důvěryhodných dat Ethereum.
3. Úvod do vrstev Arbitrum 2, které možná znáte
Arbitrum Nova je příkladem řetězce AnyTrust Arbitrum One je dalším alternativním řetězcem, který implementuje čistě důvěryhodný (a na plyn L1 náročný) protokol Arbitrum Rollup. Oba řetězy jsou postaveny na Nitro.
4.Oběžný řetěz
Arbitrum Orbit umožňuje třetím stranám vytvářet vlastní samoobslužné řetězce Arbitrum Rollup a AnyTrust. Arbitrum nabízí technologie Rollup a AnyTrust pro maximální flexibilitu při budování řetězců Orbit. Stejně jako všechny řetězce v ekosystému Arbitrum jsou jak Arbitrum Rollups, tak řetězec Arbitrum Anytrust Orbit postaveny pomocí Nitro jako základní technologie.
5. Pochopte základní situaci Xai
Pojďme pochopit Xai ve výše uvedeném kontextu. Xai funguje jako řetězec Arbitrum Orbit, který využívá technologii Anytrust pro maximální rychlost a minimální náklady. Na rozdíl od většiny „samosprávných“ řetězců Orbit využívá Xai přímou technickou podporu od Offchain Labs. Tento druh podpory je u jiných řetězců Orbit nepředstavitelný! a je klíčovou součástí strategického herního plánu společnosti Xai v rámci ekosystému Arbitrum.
Část 3: Poté, co budete mít výše uvedené koncepty, pojďme dále porozumět architektuře:
1. AnyTrust: Revoluční blockchainová infrastruktura
V rámci AnyTrust a jako špičková varianta technologie Arbitrum Nitro využívá Offchain Labs inovace k řešení některých z nejnaléhavějších výzev v oblasti blockchainu. AnyTrust nám přináší novou perspektivu začleněním lehkých předpokladů důvěry, což výrazně snižuje náklady a zároveň zajišťuje vysokou dostupnost a zabezpečení dat.
2. Snižte náklady pomocí předpokladů důvěry
Jádrem protokolu Arbitrum je, že všechny uzly Arbitrum (včetně validátorů, kteří ověřují správnost řetězce a sází přesné výsledky) potřebují přístup k datům každé transakce druhé vrstvy (L2) ve schránce řetězce Arbitrum. Arbitrum rollup tradičně zajišťuje přístup k datům publikováním dat jako calldata na vrstvě jedna (L1) Ethereum, což je proces, který generuje značné poplatky za plyn Ethereum, což je hlavní nákladová složka v Arbitrum.
3.Ketsets Flexibilita
Ketsety hrají klíčovou roli v architektuře AnyTrust. Uvádějí veřejné klíče členů komise a počet podpisů potřebných k ověření certifikátu dostupnosti dat (DACert). Ketsety poskytují flexibilitu pro změnu členů výboru a umožňují členům výboru aktualizovat své klíče podle potřeby.
4. Certifikáty dostupnosti dat (DACerts)
V AnyTrust je základním konceptem certifikát dostupnosti dat (DACert). DACert se skládá z hashe datového bloku, doby vypršení platnosti a důkazu, že členové výboru N-1 podepsali pár (hash, doba vypršení platnosti). Tento důkaz obsahuje hash sady klíčů použité pro podpis, bitmapu označující, kteří členové komise podepsali, a souhrnný podpis BLS na křivce BLS12-381, dokazující podepisujícího.
Vzhledem k předpokladu důvěry 2-of-N slouží DACert jako důkaz, že data bloku budou k dispozici alespoň jednomu čestnému členovi výboru až do stanovené doby platnosti. Tento předpoklad důvěry je základem spolehlivosti a bezpečnosti dostupnosti dat v rámci AnyTrust.
5. Duální mechanismus uvolňování dat
AnyTrust zavádí duální metodu publikování datových bloků na L1. Kromě tradičního způsobu publikování kompletních datových bloků umožňuje i vydávání DACerts, což jsou certifikáty prokazující dostupnost dat. Smlouva L1 inbox ověřuje platnost DACerts, včetně odkazu na platné Kesety specifikované v DACert.
Kód L2 zodpovědný za čtení dat z doručené pošty je navržen tak, aby bezproblémově zvládnul oba formáty dat. Když narazí na DACert, provede kontroly platnosti, včetně zajištění, že počet podepisujících odpovídá požadavkům Ketsets, ověří agregované podpisy a potvrdí, že datum vypršení platnosti přesahuje aktuální časové razítko L2. Platné DACerts zajišťují, že datový blok je přístupný a může být zneužit kódem L2.
6. Server dostupnosti dat (DAS)
Členové výboru provozují server DAS (Data Availability Server), který poskytuje dvě klíčová rozhraní API:
(1) Sorter API: Toto rozhraní JSON-RPC, navržené pro použití třídičem řetězce Arbitrum, umožňuje třídiči odesílat bloky dat do DAS k uložení.
(2) REST API: Protokol založený na RESTful HTTP(S), navržený pro širší dostupnost, umožňuje získávání datových bloků pomocí hash. Je plně cacheovatelný a lze jej nasadit ve spojení s mezipamětí proxy nebo CDN pro zvýšení škálovatelnosti a ochranu před potenciálními DoS útoky.
7. Interakce třídiče a výboru
Když třídič arbitra hodlá publikovat dávku dat prostřednictvím komise, zašle data a dobu expirace paralelně všem členům komise prostřednictvím RPC. Každý člen komise uloží data, podepíše pár (hash, doba expirace) pomocí svého klíče BLS a vrátí podpis a indikátor úspěchu do sekvenceru. Jakmile je shromážděno dostatečné množství podpisů, sekvencer je agreguje, aby vytvořil platný DACert pro páry (hash, doba expirace). Tento DACert je poté zveřejněn ve smlouvě s doručenou poštou L1, takže je přístupný pro řetězový software L2 AnyTrust. V případě, že sekvencer nemůže shromáždit dostatek podpisů ve stanoveném časovém rámci, přijme strategii „fallback to rollup“ a publikuje kompletní data přímo do L1 řetězce. Software L2 vyniká tím, že rozumí oběma formátům publikování dat (přes DACert nebo kompletní data) a vhodně zachází s každým formátem. Stručně řečeno, AnyTrust, jako přelomová inovace v rámci ekosystému Offchain Labs, představuje zásadní pokrok v řešení dostupnosti dat, bezpečnosti a nákladové efektivity blockchainové infrastruktury. Díky rozumnému předpokladu důvěry a novému přístupu k publikování dat dláždí AnyTrust cestu pro škálovatelnější, přístupnější a bezpečnější blockchainová řešení.
Část 4: S ohledem na výše uvedené pojmy si nyní vysvětlíme, proč jsou hlídací uzliny důležité: problém s kontrolou podvodníků, proč je dilema validátoru těžší, než si myslíte, a řešení!
Autorem je Ed Felten, hlavní vědec Arbitrum
V blockchainových systémech je běžným návrhovým vzorem to, že jedna strana udělá nějakou práci a uloží zálohu za správné chování a pak vyzvou ostatní, aby práci ověřili a odebrali si tuto zálohu, pokud přistihnou pracovníka při podvádění. Dalo by se to nazvat designovým vzorem „assert-challenge“. Děláme to v Arbitrum a nedávno jsme ve zprávách viděli návrhy jako Optimistic Rollup.
Tyto systémy mohou být ovlivněny dilematem validátoru, což je v podstatě pozorování, že nemá smysl kontrolovat něčí práci, pokud víte, že nepodvádí, ale pokud to nekontrolujete, má motivaci podvádět. Pokud jste designér, chcete dokázat, že váš systém je kompatibilní s pobídkami, což znamená, že pokud se každý bude chovat konzistentně se svými pobídkami, nedojde k žádnému podvádění. Toto je oblast, kde vás intuice může vést špatně. Tento problém je mnohem těžší, než se zdá, jak uvidíme, až rozbalíme pobídky stran níže.
Super jednoduchý model
Začneme tím, že postavíme nejjednodušší model, jaký umíme. Předpokládejme, že jsou dva hráči. Prohlašovatel učiní prohlášení, které může být pravdivé nebo nepravdivé. Kontrolor může prověřit tvrzení žadatele, nebo se může rozhodnout nedělat nic, pravděpodobně za předpokladu, že žadatel pravděpodobně mluví pravdu. Předpokládáme, že náklady kontrolora na kontrolu jsou C. Pokud kontrolor zkontroluje a zjistí, že subjekt podváděl, získá kontrolor odměnu R. (R zahrnuje všechny výhody nashromážděné zkoušejícím v důsledku přistižení podvádění. To zahrnuje výhody realizované „mimo systém“ a také jakékoli výhody získané díky zvýšené důvěře v systém.) Pokud se nedaří přistihnout, podvádění , dáma ztratí L, například proto, že podvádějící hráč může podvodně sebrat cenné předměty z pokladny.
Nyní se musíme obávat dvou hrozeb: úplatkářství a lenosti. Úplatek je možnost, že prosazovatel může podplatit kontrolora, aby nekontroloval, a tím mu umožnit podvádět, aniž by byl odhalen. Tomu můžeme zabránit tím, že zajistíme, aby si agresor uložil do úschovy velmi velký vklad, který je větší než celková hodnota v systému, a zaplatil checkerovi, když je odhaleno podvádění, takže ten, kdo prosazuje, není ochoten zaplatit vyšší, než je úplatek odměny R. . Tím se zabrání úplatkům, ale vyžaduje to, aby byl systém plně zajištěn, což může být velmi nákladné.
Další hrozbou je lenost, riziko, že se kontrolor rozhodne nekontrolovat práci asertera. (Pamatujte si, že dáma může říkat, že kontroluje, ale ve skutečnosti to nedělá.) Podívejme se na pobídky pro dámu, abychom zjistili, zda je to rozumná strategie.
Předpokládejme, že asertor podvádí s pravděpodobností X. Nyní je nástroj inspektora následující:
Pokud recenzent zkontroluje: RX-C
Pokud kontrola nekontroluje: -XL
Kontrola má smysl pouze tehdy, je-li užitečnost kontroly větší než užitečnost nekontrolování, tedy pokud X > C/(R+L). Zde je špatná zpráva: aserter může podvádět náhodně, s pravděpodobností menší než C/(R+L), racionální kontrolor to nikdy nezkontroluje, takže aserter nebude nikdy přistižen při podvádění.
Zapojme nějaká čísla. Pokud jsou náklady na kontrolu každé transakce 0,10 USD a kontrolor obdrží odměnu 75 USD, pokud zjistí podvádění, ale prohraje 25 USD, pokud podvod neodhalí, pak může prosazovatel beztrestně podvádět tisíckrát. Pokud chceme, aby tento systém prováděl tisíce transakcí, pak máme velký problém. V tomto modelu evidentně nemůžeme udělat nic, abychom snížili pravděpodobnost podvádění na nulu. Můžeme jen doufat v překolateralizovaný systém, aby se jmenovatel C/(R+L) zvětšil.
To je překvapivě robustní výsledek – špatným způsobem. Vůbec nezáleží na pobídkách prosazovatele. Dokud aserter získá nenulovou výhodu z úspěšného podvádění, může tak učinit s určitou pravděpodobností, s vědomím, že nestojí za námahu kontrolora kontrolovat. Tento výsledek také nezávisí na tom, kolik času dáme inspektorovi na dokončení práce, nebo zda za (údajného) inspektora platíme. Možná si teď říkáte, problém je v tom, že je jen jeden inspektor. Snížilo by přidání více kostek pravděpodobnost podvádění? Kupodivu ne.
Přidání cenzorů nepomůže zabránit podvádění
Opět zformulujme nejjednodušší model. Nyní působí dva inspektoři samostatně. Každá kontrola zaplatí C, pokud kontroluje, a pokud někdo zkontroluje a přistihne uživatele při podvádění, úspěšnému kontrolorovi je vyplacena odměna R, nebo pokud oba kontrolují, odměna se rozdělí rovným dílem mezi oba. (Pokud chcete, můžete jednomu z nich dát náhodnou plnou odměnu R v případě, že všichni kontrolují. To neovlivní nikoho strategii ani výsledky.) Stejně jako dříve, každý hráč ztratí L, pokud asertivní podvádění bez získání chycen.
Zůstává pravdou, že pokud aserter podvádí méně než C/(R+L) daného času, pak se nevyplatí pro kontrolu kontrolovat, protože užitečnost kontroly je menší než užitečnost nekontrolování. Ve skutečnosti je problém s pobídkou horší než dříve, protože náklady na kontrolu na jednoho checkera jsou stále C, ale očekávaná odměna za úspěšného checkera při podvádění je menší než R, protože odměnu je někdy potřeba rozdělit – očekávaná odměna bude být v R/2 a R. Pokud je očekávaná odměna bR, kde b je mezi 0,5 a 1, pak může aserter podvádět až C/(bR+L) daného času - to je více nezjištěné podvádění, než kdyby byl pouze jeden checker! (Matematika se trochu zkomplikuje, protože hodnota b závisí na strategii hráče a jejich strategie závisí na b, ale mělo by být jasné, že někdy budou muset odměnu rozdělit. Také se sníží efektivní hodnota L , protože jedna dáma nesmí ztratit své L pro kontrolu jinými dámami).
Jedním z míst, kde by přidání cenzorů skutečně pomohlo, je předcházení úplatkářství. Se dvěma dámami musí prosazovatel zaplatit úplatek vyšší než R každému prosazovateli, čímž je úplatek dvakrát dražší, což umožňuje 50% sázky místo plné sázky. Ale kompromisem je, že množství podvádění se zvyšuje.
Nebudu zde zabíhat do celé matematiky, ale za rozumných předpokladů by zvýšení z jedné kontroly na dvě mohlo vést k 50% nárůstu neodhaleného podvádění.
Přidáním cenzorů se věci zhorší!
Můžete přidat další dámu a věci se zhorší. Se zvyšujícím se počtem checkerů se checker musí více starat o to, aby odměna byla rozdělena více způsoby, takže očekávaná odměna za každou úspěšnou checker postupně klesá, což způsobuje postupné zvyšování pravděpodobnosti, že daný hráč bude bezpečně podvádět. Z tohoto pohledu je nejhorší scénář, že každý na světě by se mohl stát cenzorem. To není nekonečně špatné, protože věci se zhoršují, když přibývají další cenzorové, ale rozhodně to nepomůže zabránit podvádění, i když to účinně eliminuje riziko úplatků.
Jste si jisti, že váš systém je kompatibilní s motivací?
Pokud máte systém, který se hodí k tomuto typu modelu, a myslíte si, že je kompatibilní s motivací, musíte si dobře rozmyslet proč. Zejména musíte vysvětlit, proč by kontrolor vykonával práci kontroly, i když si myslí, že je nepravděpodobné, že by kontrolor podváděl. Jen mít velký trest za podvádění nestačí. Mít odměnu za dopadení podvodníků nestačí. Jednoduše mít hodně dáma nestačí – ve skutečnosti to může všechno zhoršit. Proč je váš systém imunní?
Tato výzva se týká systémů jako Optimistic Rollup. Když mluvíme o Arbitrum, týká se to i nás.
Na základě výše uvedeného tradiční metody kontroly pobídek nedosahují požadovaných výsledků – existuje základní míra podvádění, pod kterou budou kontroloři považovat kontrolu za nevyplácenou. Na závěr:
Jsou zde dva hráči, prohlašovatel, který tvrdí, zda je pravdivý nebo nepravdivý, a kontrolor, který může toto tvrzení zkontrolovat za určité výpočetní náklady. Pokud checker kontroluje, jeho užitek je RX-C, pokud nekontroluje, jeho užitek je -XL, kde R je odměna za chycení podvádění, C jsou náklady na kontrolu a L je ztráta kontrolora v důsledku neodhalení podvádění. , X je pravděpodobnost podvádění prosazovatele (zvolená prosazovatelem). Nějaká algebra ukazuje, že pokud
Abychom tento problém vyřešili a vytvořili situaci, kdy bude recenzent řízený pobídkami vždy kontrolovat, musíme pobídky recenzenta změnit. Základním problémem je, že v původním modelu jsou pozitivní pobídky pro dámu ke kontrole úměrné Pokud chceme kontrolní pobídku, která funguje bez ohledu na to, musíme vytvořit kontrolní pobídku nebo odrazující pobídku za nekontrolování, která je nezávislá na akcích prohlašovatele.
TrueBit se o to pokouší přidáním záměrně nepravdivých tvrzení do sady tvrzení, v podstatě nahrazením X X plus konstantou. Tento přístup má určité problémy. (Původní dokument Arbitrum obsahuje část o problémech motivace TrueBit.)
Zaměřte se na výzvy
Používáme jiný přístup, kterému říkáme zaměření na výzvu. Myšlenka je taková, že pokud aserter počítá hodnotu f(x), nejprve vydá x a kryptografickou výzvu. Aby zkoušející správně odpověděl na výzvu, potřebuje znát f(x). Teprve poté, co došlo k výzvě, aserter publikuje f(x) - v tomto okamžiku již kontrolor vykonal těžkou práci s výpočtem f(x), takže nemá motivaci lenošit. (Další podrobnosti o smlouvě následují.)
Abychom snížili počet transakcí v řetězci, které to vyžaduje, zařídíme věci tak, aby správnou odpovědí na výzvu kontrolora bylo obvykle ticho. Ale ve vzácných případech musí kontrolor zveřejnit velmi malou transakci v řetězci. Pokud kontrolor dá špatnou odpověď - ticho, kdy má být uvolněn, nebo ticho, kdy má být uvolněn - ztratí malý vklad.
Přizpůsobme původní motivační model tak, aby zahrnoval výzvy k pozornosti. Potřebujeme dva nové parametry (oba si můžeme vybrat): P, procento času, kdy byla odeslána správná odpověď kontrolora, a A, penalizace, pokud kontrolor odpoví špatně. Nyní je nástroj inspektora:
Pokud je zaškrtnuto: RX-C
Pokud ne, zkontrolujte: -LX-PA
Klíčovým postřehem je, že pokud PA > C, pak je kontrola optimální strategií, bez ohledu na to, jaká je X (pravděpodobnost podvádění).
Velmi nízké náklady
Pro zhodnocení nákladů se podívejme na konkrétní příklad. Předpokládejme, že existuje tvrzení každých pět minut a náklady na kontrolu jsou 0,001 $. Pokud nastavíme pravděpodobnost P na 0,3 %, bude muset dáma zaplatit zálohu 3 $. Nyní je cena kontrolora za tvrzení 0,0003 $ v poplatcích za plyn (poplatek za plyn 0,10 $ za zveřejnění své tiché odpovědi, vynásobený 0,3% pravděpodobností, kterou musí zveřejnit), plus asi 0,0003 $ na uzamčení své sázky 3 $ na pět minut Celková částka náklady na úrok jsou 0,0006 USD za tvrzení.
Rozšíření pro více inspektorů
Výzva zaměřená na zaměření se dobře škáluje s více zkoušejícími. Protokol vydává výzvu, která ovlivňuje každý kontrolor odlišně a nutí každého kontrolora počítat f(x) samostatně. Každá kontrola bude mít stejnou cenu (v našem případě 0,0006 $ za tvrzení).
V otevřeném systému je kdokoli oprávněn kontrolovat výpočty a komukoli můžete povolit, aby se zaregistroval jako kontrolor a vložil požadovaný malý vklad. Díky tomu budou způsobilí přijímat výzvy k pozornosti a případně získat kompenzaci od vývojářů dapp. Kdokoli může napadnout nesprávná tvrzení žadatele, ale pouze registrovaní zkoušející čelí problémům s pozorností.
Technické detaily smlouvy
Nyní, když chápeme, co pro nás může zaměření na výzvy udělat, pojďme se ponořit do technických podrobností, jak fungují.
Každá kontrola má soukromý klíč k a odpovídající veřejný klíč gᵏ, definované v příslušné skupině. Veřejný klíč každé kontroly je všem znám. Budeme se také spoléhat na vhodnou hašovací funkci H.
Pro zadání výzvy k výpočtu f(x), kde je funkce f předem známá, vygeneruje asertor náhodnou hodnotu r a poté vydá (x, gʳ) jako výzvu.
Kontrolor vlastnící soukromý klíč k by měl reagovat na výzvu zveřejněním malé transakce pouze v případě, že H(gʳᵏ, f(x)) < T, kde T je vhodně zvolená prahová hodnota. Všimněte si, že hash může vypočítat pouze aserter (který zná r) a konkrétní kontrolor (který zná jeho soukromý klíč k), protože jsou jediní, kdo může vypočítat gʳᵏ. Všimněte si také, že výpočet hashe vyžaduje znalost f(x).
Poté, co mají dáma nějaký čas na zveřejnění svých odpovědí na výzvu, může asertor zveřejnit své f(x) a pokud s tím kterýkoli hráč nesouhlasí, bude vyzván jako obvykle. V tomto bodě může prohlašovatel obvinit kteréhokoli kontrolora z nesprávných odpovědí, aby prokázal své obvinění. Těžař nebo kontraktor může zkontrolovat, zda je obvinění správné, a potrestat porušovatele, ale pokud tvrzení tvrzení o f(x) nebude nakonec přijato jako správné, bude obvinění ignorováno. Bude-li kterýkoli kontrolor pokutován, subjekt obdrží polovinu propadlých prostředků a druhá polovina bude zničena.
Tento přístup dává zkoušejícímu ty správné podněty. Vědět, jak by měl kontrolor reagovat na výzvu, vyžaduje znát soukromý klíč tohoto kontrolora a f(x), takže každý kontrolor bude chtít vypočítat f(x). Pokud kontrolor sám nevypočítá f(x), nemůže bezpečně vynutit protokol. Odpovědi ostatních kontrolorů nejsou užitečné při určování f(x), protože se spoléhají na soukromé klíče těchto kontrolorů. Pokud se kontrolor spoléhá na to, že mu někdo jiný řekne f(x), nemá žádný způsob, jak tuto nárokovanou hodnotu ověřit (kromě výpočtu f(x) samotného) a kontrolor riskuje, že bude penalizován, pokud se mýlí. Existuje dokonce pobídka pro jednu stranu, aby se pokusila uvést kontrolora v omyl ohledně f(x) – to je ten, kdo vydělává na chybách kontrolora a může tyto zisky použít k uplácení „přátel“ kontrolora, aby poskytli kontrolorovi nesprávné informace. informace.
Optimalizace a závěr
Existuje několik triků, jak tento protokol zefektivnit. Mohli bychom například spojit tvrzení s další výzvou do řetězové transakce, aby výzva nezvyšovala počet transakcí. Pokud je P malé (např. 0,3 % v našem příkladu) a počet kontrolorů není příliš velký, pak kontroloři zřídka potřebují zapsat transakce do řetězce, takže celkový dopad protokolu na počet transakcí v řetězci bude být nejmenší.
Díky chytré implementaci by náklady na tento protokol měly být velmi nízké ve srovnání s počátečními náklady na vydávání asercí v řetězci. V našem případě přidání výzev pozornosti ke stávajícímu protokolu asertion-chlenge zvyšuje celkové náklady o méně než 1 %.
A zisky jsou značné – získáváme kontrolní protokol kompatibilní s pobídkami, který je imunní vůči dilematu validátoru. Dokud je alespoň jeden kontrolor racionální, budou tvrzení tvrzení vždy kontrolována.
Další informace o projektu naleznete na: Herní veřejný řetězec Xai: databáze Binance Square
