Până acum, mitul bunăstării în industria cercului valutar/blockchain continuă, iar următoarea zonă importantă de „creare a bogăției” se concentrează pe „pista de joc”. Proiectul XAI organizează un eveniment Odyssey. Dacă sunteți interesat, vă rugăm să participați la acest articol de-al meu de pe piață: Ghid pentru începători cu cost zero al evenimentului Odyssey din lanțul public al jocului XAI

În acest articol, vă voi aduce o explicație detaliată a nodului Sentry al lanțului public de jocuri XAI! Acest articol este relativ tehnic, așa că dacă ești interesat să faci bani, trebuie să îl citești cu atenție. Pentru că numai dacă înțelegi singur „logica” și îți îmbunătățești cunoașterea, poți avea ocazia să faci bani!

Dacă doriți să vedeți direct despre nodul Sentry, citiți direct prima parte fără a citi mai târziu dacă doriți o buclă închisă logică, atunci trebuie să citiți partea a doua, a treia și a patra!

Ceea ce vreau să subliniez este că Xai primește asistență tehnică directă de la Offchain Labs. Acest tip de suport este de neimaginat pentru alte lanțuri Orbit! și este o componentă cheie a planului strategic de joc al lui Xai în cadrul ecosistemului Arbitrum.

Partea 1: Explicația nodului Sentry

Nodul Sentry este un nod de observație care monitorizează protocolul de rulare Xai și dacă se propune un bloc defect, va emite o alertă (prin orice mijloc alege operatorul său) pentru ca alții să poată interveni. Scopul nodului santinelă este de a rezolva dilema verificatorului (a se vedea Partea IV pentru detalii despre dilema verificatorului).

Click aici pentru a vizualiza videoclipul promotional:

Promovare video Sentinel Node

Rulați noduri Xai și obțineți jetoane Xai cu un singur clic!

Nodurile Sentinel pot rula pe laptopurile, desktopurile sau chiar pe instanțele cloud ale membrilor comunității. Atâta timp cât nodul rulează, există un algoritm probabilistic care determină dacă operatorul nodului va fi recompensat cu jetoane esXai din rețea. Prin miza pe Xai, creșteți probabilitatea algoritmului. Dacă nu știți despre esXai, vă rugăm să participați la articolul meu despre pătrat: Interpretarea „Token Economy” a proiectului XAI

1. Principiul de funcționare al ganglionului santinelă

Protocolul Attention Challenge v2 implică mai mulți participanți, inclusiv lanțul Xai, un lanț părinte (Arbitrum One), un challenger de încredere, sentinelele Xai și cheile de licență ale acestora și un contract de arbitru (arbitru). Challengerul creează o pereche de chei BLS, înregistrează cheia publică în contractul de arbitru și semnează revendicările făcute de validator în protocolul de acumulare Xai pe Arbitrum One. Aceste semnături sunt verificate prin contractul de arbitru și înregistrate ca provocări asociate cererii.

Xai Sentinels se poate înregistra cu contractul de arbitru cumpărând o cheie de licență Sentinel pentru a fi eligibil să publice declarații despre revendicări. Ei obțin rădăcina de stat a declarației corecte care va fi succesorul declarației emitente. Dacă o anumită condiție este îndeplinită, ei emit o declarație despre declarație prin invocarea contractului de arbitru. Dacă o declarație ulterioară este creată și confirmată, iar Sentinel emite declarația corectă, Sentinel va contacta contractul de arbitru pentru a emite o tranzacție de răscumpărare. Arbitrul va verifica mai multe condiții înainte de a plăti recompensa Santinelei.

Acest protocol asigură că fiecare revendicare trebuie să consume pe deplin mesajele primite care existau când a fost creată revendicarea predecesorului său. Aceasta înseamnă că odată ce o revendicare este creată, rădăcinile de stat ale revendicărilor sale ulterioare corecte sunt pe deplin determinate și pot fi calculate de orice nod. Acest lucru încurajează fiecare santinelă să determine rădăcina corectă a stării următoare. Recompensa sentinelei este determinată de ID-ul permisiunii de stat al santinelei, de rădăcina de stat ulterioară și de o valoare de provocare care nu devine cunoscută până când rădăcina de stat ulterioară este pe deplin determinată.

2. Cine poate rula nodul?

Oricine poate opera Sentinel descărcând software-ul, instalându-l și rulându-l. Cu toate acestea, pentru a primi recompense cu simboluri, trebuie achiziționată cel puțin o cheie de licență Sentinel.

Cumpărătorii trebuie să treacă cu succes o verificare KYC pentru a se asigura că:

• nu in Statele Unite

• Nu face obiectul niciunei sancțiuni OFAC din SUA (OFAC este reflectată într-o listă de sancțiuni din SUA)

Acele noduri Sentinel care nu funcționează sau nu au fondurile adecvate pentru a plăti taxele de gaz (GAS) nu vor acumula recompense, chiar și cu o cheie de licență. Prin urmare, operatorii vor dori să se asigure că nodurile lor sunt finanțate, online și rulează.

3.Contract de arbitru (arbitru).

Referee este un contract inteligent conceput pentru a impune respectarea regulilor predefinite, pentru a verifica originea trimiterilor și pentru a distribui recompense câștigătorilor în cadrul sistemului. Contractul inteligent de arbitru este o componentă cheie a ecosistemului Xai, responsabilă de gestionarea și validarea revendicărilor făcute de nodurile sentinelă din rețea. Contractul are mai multe funcții cheie:

3.1 Depunerea declarației

Contractul de arbitru permite ganglionilor santinelă să depună cereri la provocări. Această funcție poate fi apelată numai de proprietarul cheii de licență Sentinel sau de adresa aprobată a acestuia în acest contract. Această funcție verifică dacă provocarea este încă deschisă pentru depunere și dacă a fost deja trimisă o NodeLicense pentru această provocare.

3.2 Primiți recompense

Contractul conține o funcție care permite utilizatorilor să revendice recompense pentru revendicările reușite. Această funcție verifică dacă provocarea a fost închisă pentru trimitere și verifică dacă proprietarul cheii nodului a finalizat KYC. Dacă aceste condiții sunt îndeplinite și cererea este eligibilă pentru plată, recompensa va fi trimisă utilizatorului.

3.3 Creați hash de revendicare și plată cu cec.

Contractul are o funcție care creează un hash al ID-ului permisiunii sentinelă, ID-ului provocării, challengerSignedHash în provocare și rădăcină de stat ulterioară. Apoi verifică dacă hash-ul este sub un anumit prag, care este calculat pe baza numărului total de licențe Sentinel care au fost bătute. Dacă hash-ul este sub prag, revendicarea este eligibilă pentru plată.

Contractul de arbitru asigură integritatea rețelei Xai prin validarea revendicărilor și recompensând pe cele de succes, stimulând astfel nodulii santinelă să monitorizeze rețeaua cu acuratețe și sârguință.

4. Componenta Challenger

Challenger-ul este o entitate de încredere în ecosistemul Xai. Acesta creează o pereche de chei BLS și înregistrează cheia publică în contractul de arbitru. Când un validator face o revendicare în protocolul de acumulare Xai, contestatorul semnează revendicarea folosind cheia sa privată și trimite semnătura arbitrului. Arbitrul verifică semnătura și o înregistrează ca o provocare asociată declarației. Acest proces asigură integritatea revendicărilor făcute în protocolul de acumulare Xai.

5. Cheie (permisiunea cheii nodului Sentinel, bazată pe NFT)

Cheia de licență Sentinel este un token unic, nefungibil (NFT) care este necesar pentru a opera un nod Sentinel în rețeaua Xai. Licențele Sentinel servesc drept dovadă a eligibilității nodurilor pentru a trimite revendicări și a primi recompense. Se bate prin trimiterea cantității corecte de ETH, iar prețul bateriei este determinat de un sistem de prag crescător.

Licențiarea nodului joacă un rol cheie în contractul de arbitru. Când un nod dorește să trimită o revendicare la o provocare, trebuie să furnizeze ID-ul său de permisiune Sentinel. Contractul de arbitru verifică dacă licența Sentinel este valabilă și dacă nodul este proprietarul licenței Sentinel sau un operator aprobat (secțiunea KYC de mai sus). Dacă aceste condiții sunt îndeplinite, cererea nodului este supusă contestației.

Permisiunile Sentinel intră, de asemenea, în joc atunci când revendicați recompense pentru revendicările reușite. Contractul de arbitru verifică dacă proprietarul licenței Sentinel a finalizat KYC și dacă declarația este eligibilă pentru plată. Dacă aceste condiții sunt îndeplinite, recompensa este trimisă proprietarului licenței Sentinel.

În rezumat, permisiunea Sentinel este o componentă cheie în rețeaua Xai, care reglementează funcționarea nodurilor Sentinel, depunerea cererilor și distribuirea recompenselor.

6. Descărcați și rulați nodul

Pentru a rula un nod santinelă, utilizatorii trebuie doar să descarce un pachet software specific. Acest pachet poate fi folosit într-o aplicație desktop sau ca instrument de linie de comandă pe computer. Mai simplu spus, aceste aplicații sunt instrumente care fac software-ul Sentinel mai ușor de utilizat. Scopul acestui pachet este de a automatiza toate operațiunile necesare rulării Sentinel, făcându-l foarte simplu de configurat și utilizat, chiar dacă nu sunteți tehnic.

Acest pachet ajută utilizatorii cu sarcini precum configurarea, gestionarea și interacțiunea cu alte părți și are o interfață ușor de utilizat care permite utilizatorilor să vizualizeze și să ajusteze cu ușurință setările. Folosind acest pachet, utilizatorii se pot concentra mai mult pe cum să ruleze mai bine și să obțină mai multe recompense simbol. Utilizatorii pot alege să ruleze acest pachet folosind o aplicație desktop sau un instrument de linie de comandă, ambele fiind foarte ușor de utilizat și fac procesul de operare foarte ușor.

7. Funcția portofel Sentinel

În ecosistemul Xai, portofelul Sentinel joacă un rol cheie în interacțiunea dintre nodurile Sentinel și contractele inteligente de arbitri. Sentinel Wallet acționează ca agent intermediar și este responsabil pentru transmiterea declarațiilor către arbitru în numele Sentinelilor relevante. Acest lucru se realizează prin funcții specifice din contractul de arbitru care pot fi apelate doar de proprietarul cheii de licență Sentinel sau adresa aprobată a acestora în acest contract.

Portofelul Sentinel poate trimite o declarație la contestație apelând funcția submitAssertionToChallenge din contractul de arbitru. Această funcție verifică dacă provocarea este încă deschisă pentru depunere și dacă cheia de nod a fost deja trimisă pentru această provocare.

Sentry Wallet poate, de asemenea, revendica recompense pentru revendicări reușite, apelând funcția claimReward din contractul de arbitru. Această funcție verifică dacă provocarea a fost închisă pentru depunere și verifică dacă proprietarul licenței Sentinel a efectuat o verificare „KYC”. Dacă aceste condiții sunt îndeplinite și cererea este eligibilă pentru plată, recompensa va fi trimisă proprietarului Sentinel-ului.

Pe scurt, Sentinel Wallet acționează ca un mesager, facilitând interacțiunea dintre noduri și arbitri, asigurând astfel funcționarea armonioasă a rețelei Xai.

8. Licență

Relația dintre numărul de licențe și capacitățile de trimitere ale nodului este fundamentală. Deși este posibil ca un nod să aibă mai multe licențe asociate cu acesta, este important să ne dăm seama că numărul de licențe afectează direct capacitatea nodului de a se angaja. În esență, pentru a asigura cote echitabile de comitere, raportul dintre licențe și instanțe de nod este menținut la 1:1. Urmând principiile de mai sus, sistemul stabilește o abordare structurată pentru acordarea de licențe, transmiterea drepturilor și funcționarea generală a nodurilor din ecosistem.

9.Sentry nod software și cerințe hardware

Software-ul Sentinel Node acceptă desktop Windows, Mac și Linux (necesită 64 de biți). Următoarele sunt resursele actuale necesare pentru a rula software-ul nodului Sentinel pentru până la 100 de chei de licență:

• 4 GB de RAM

• 2 nuclee CPU

• 60 GB spațiu pe disc

• procesor x86/X64 (suporta procesor ARM, cum ar fi chipul Apple M1/M2)

• Conexiune la internet stabilă

Când adăugați chei suplimentare la un nod, în mod ideal, capabilitățile hardware ar trebui să crească în consecință. Cu toate acestea, nu este obligatoriu să atribuiți o mașină separată fiecărei taste. Se așteaptă ca sistemul să fie scalabil pentru a găzdui zeci de chei pe o singură mașină și, posibil, mai multe.

Notă: Aceste cerințe hardware pot fi modificate.

10. Recompense estimate ale rețelei nodului Sentry

Model economic XAI token, vă rugăm să consultați: Interpretarea „Token Economy” a proiectului XAI

Iată trei scenarii pentru estimarea recompenselor Xai pe care le-ați putea câștiga din rularea unui nod Sentry. Aceste trei scenarii se bazează pe următoarele ipoteze:

• Suma XAI și esXAI nu va depăși niciodată 2.500.000.000. Având în vedere că ecosistemul Xai este dinamic, este imposibil să preziceți cu exactitate recompensele lunare pentru fiecare cheie Sentry.

• 100% din GAZ este arse, deci nu există nicio garanție că oferta va fi întotdeauna inflaționistă, poate fi deflaționistă.

• Fundația Xai nu va vinde mai mult de 50.000 de chei Sentry (un nod poate încărca mai multe chei). Este de așteptat să dureze 2-3 ani. Cheile de santinelă devin mai scumpe în timp.

• Suma lunară esXAI per cheie Sentry poate varia, de asemenea, în funcție de numărul de participanți la miză în ecosistem.

Semnificația următoarelor trei tabele este că, sub circulația diferită a jetoanelor XAI și esXAI, numărul de chei de nod activate în rețea și recompensele lunare corespunzătoare așteptate de token pe cheie:

Estimarea scenariului A: dacă există un total de 750.000 de jetoane XAI și esXAI în circulație, atunci fiecare cheie Sentry va primi recompense esXAI conform următorului tabel:

Estimarea scenariului B: Dacă există un total de 1.250.000.000 de jetoane XAI și esXAI în circulație, atunci fiecare cheie Sentry va primi recompense esXAI conform următorului tabel:

Estimarea scenariului C: Dacă există un total de 2.187.500.000 de jetoane XAI și esXAI în circulație, atunci fiecare cheie Sentry va primi recompense esXAI conform următorului tabel:

Partea 2: XAI este dezvoltat și întreținut de Arbitrum (ARB), așa că trebuie să aruncăm puțină lumină asupra arhitecturii Arbitrum:

1.Nitro decizie

Toate lanțurile Arbitrum sunt construite pe Arbitrum Nitro, care este tehnologia de bază pentru toate lanțurile din ecosistem. Nitro rulează o versiune forked de Geth și folosește WebAssembly ca mașină virtuală subiacentă, rezistentă la fraudă.

2.Orice decizie de încredere

Anytrust este un protocol Arbitrum care gestionează disponibilitatea datelor printr-o colecție de licențiatori numită Data Availability Committee (DAC). Acest protocol reduce taxele de tranzacție prin introducerea unei ipoteze suplimentare de încredere în ceea ce privește disponibilitatea datelor, mai degrabă decât utilizarea mecanismului de disponibilitate a datelor fără încredere Ethereum.

3. Introducere în Arbitrum 2 straturi pe care poate le cunoașteți

Arbitrum Nova este un exemplu de lanț AnyTrust Arbitrum One este un alt lanț alternativ care implementează protocolul Arbitrum Rollup pur fără încredere (și mai intensiv în gaz L1). Ambele lanțuri sunt construite pe Nitro.

4.Lant orbital

Arbitrum Orbit permite terților să-și creeze propriile lanțuri Arbitrum Rollup și AnyTrust autogestionate. Arbitrum oferă tehnologii Rollup și AnyTrust pentru flexibilitate maximă la construirea lanțurilor Orbit. Ca toate lanțurile din ecosistemul Arbitrum, atât Arbitrum Rollups, cât și lanțul Arbitrum Anytrust Orbit sunt construite folosind Nitro ca tehnologie de bază.

5. Înțelegeți situația de bază a lui Xai

Să-l înțelegem pe Xai în contextul de mai sus. Xai funcționează ca un lanț Arbitrum Orbit, utilizând tehnologia Anytrust pentru viteză maximă și cost minim. Spre deosebire de majoritatea lanțurilor Orbit „autoguvernate”, Xai beneficiază de suport tehnic direct de la Offchain Labs. Acest tip de suport este de neimaginat pentru alte lanțuri Orbit! și este o componentă cheie a planului strategic de joc al lui Xai în cadrul ecosistemului Arbitrum.

Partea 3: După ce aveți conceptele de mai sus, să înțelegem mai bine arhitectura:

1.AnyTrust: infrastructură revoluționară Blockchain

În cadrul AnyTrust și ca variantă de ultimă oră a tehnologiei Arbitrum Nitro, Offchain Labs valorifică inovația pentru a rezolva unele dintre cele mai presante provocări din spațiul blockchain. AnyTrust ne aduce o nouă perspectivă prin încorporarea unor ipoteze ușoare de încredere, reducând semnificativ costurile, asigurând în același timp disponibilitatea și securitatea puternică a datelor.

2. Reduceți costurile prin ipoteze de încredere

La baza protocolului Arbitrum, toate nodurile Arbitrum (inclusiv validatorii care verifică corectitudinea lanțului și miză rezultatele exacte) trebuie să acceseze datele fiecărei tranzacții de nivel doi (L2) din căsuța de e-mail a lanțului Arbitrum. În mod tradițional, Arbitrum rollup asigură accesul la date prin publicarea datelor ca date de apel pe stratul unu (L1) Ethereum, un proces care generează taxe semnificative de gaz Ethereum, care este o componentă majoră a costurilor în Arbitrum.

3.Ketsets Flexibilitate

Ketsets joacă un rol cheie în arhitectura AnyTrust. Acestea specifică cheile publice ale membrilor comitetului și numărul de semnături necesare pentru verificarea Certificatului de Disponibilitate a Datelor (DACert). Ketsets oferă flexibilitate pentru schimbarea membrilor comitetului și le permit membrilor comitetului să își actualizeze cheile după cum este necesar.

4. Certificate de disponibilitate a datelor (DACerts)

În AnyTrust, un concept de bază este certificatul de disponibilitate a datelor (DACert). Un DACert constă din hash-ul blocului de date, un timp de expirare și dovada că membrii comitetului N-1 au semnat perechea (hash, expiration time). Această dovadă include un hash al setului de chei utilizat pentru semnătură, un bitmap care indică ce membri ai comitetului au semnat și o semnătură agregată BLS pe ​​curba BLS12-381, care demonstrează semnatarul.

Datorită ipotezei de încredere 2 din N, DACert servește drept dovadă că datele unui bloc vor fi disponibile pentru cel puțin un membru onest al comitetului până la o dată de expirare specificată. Această ipoteză de încredere este baza pentru fiabilitatea și securitatea disponibilității datelor în cadrul AnyTrust.

5. Mecanism dublu de eliberare a datelor

AnyTrust introduce o metodă duală de publicare a blocurilor de date pe L1. Pe lângă metoda tradițională de publicare a blocurilor complete de date, permite și emiterea de DACerts, care sunt certificate care dovedesc disponibilitatea datelor. Contractul de inbox L1 verifică valabilitatea DACert-urilor, inclusiv referința la Keset-uri valide specificate în DACert.

Codul L2 responsabil pentru citirea datelor din căsuța de e-mail este conceput pentru a gestiona perfect ambele formate de date. Când este întâlnit un DACert, acesta efectuează verificări de valabilitate, inclusiv asigurându-se că numărul de semnatari îndeplinește cerințele Ketsets, validând semnăturile agregate și confirmând expirarea dincolo de marcajul de timp L2 actual. DACert-urile valide asigură că blocul de date este accesibil și poate fi exploatat prin codul L2.

6. Server de disponibilitate a datelor (DAS)

Membrii comitetului operează Data Availability Server (DAS), care oferă două API-uri cheie:

(1) Sorter API: concepută pentru a fi utilizată de sortatorul lanțului Arbitrum, această interfață JSON-RPC permite sortatorului să trimită blocuri de date către DAS pentru stocare.

(2) API REST: Proiectat pentru o accesibilitate mai largă, protocolul bazat pe HTTP(S) RESTful permite preluarea fragmentelor de date prin hash. Este complet stocabil în cache și poate fi implementat împreună cu proxy-uri de cache sau CDN-uri pentru a îmbunătăți scalabilitatea și a proteja împotriva potențialelor atacuri DoS.

7. Interacțiunea Sorter-Comitet

Atunci când sortătorul Arbitrum intenționează să publice un lot de date prin intermediul comitetului, trimite datele și un timp de expirare tuturor membrilor comitetului în paralel prin RPC. Fiecare membru al comitetului stochează datele, semnează perechea (hash, timp de expirare) folosind cheia sa BLS și returnează semnătura și indicatorul de succes la secvențiator. Odată ce sunt colectate suficiente semnături, secvențiatorul le agregează pentru a crea un DACert valid pentru perechi (hash, timp de expirare). Acest DACert este apoi publicat în contractul de inbox L1, făcându-l accesibil pentru software-ul lanțului AnyTrust al L2. În cazul în care secvențiatorul nu poate colecta suficiente semnături în intervalul de timp specificat, adoptă o strategie de „reducere la acumulare” și publică datele complete direct în lanțul L1. Software-ul L2 excelează la înțelegerea atât a formatelor de publicare a datelor (prin DACert sau a datelor complete) cât și la manipularea fiecărui format în mod corespunzător. Pe scurt, AnyTrust, ca o inovație revoluționară în cadrul ecosistemului Offchain Labs, reprezintă un progres critic în abordarea disponibilității datelor, securității și eficienței costurilor infrastructurii blockchain. Printr-o ipoteză sensibilă a încrederii și o abordare nouă a publicării datelor, AnyTrust deschide calea pentru soluții blockchain mai scalabile, accesibile și mai sigure.

Partea 4: Ținând cont de conceptele de mai sus, să explicăm acum de ce sunt importanți ganglionii santinelă: problema de verificare a trișorului, de ce dilema validatorului este mai grea decât credeți și soluția!

Autorul este Ed Felten, om de știință șef la Arbitrum

În sistemele blockchain, un model obișnuit de proiectare este ca o parte să lucreze și să păstreze un depozit pentru un comportament corect, apoi să îi invite pe alții să verifice munca și să ia acest depozit dacă îl prind pe lucrător înșelând. L-ați putea numi modelul de design „afirmare-provocare”. Facem asta în Arbitrum și am văzut recent propuneri precum Optimistic Rollup în știri.

Aceste sisteme pot fi afectate de dilema validatorului, care este practic observația că nu are rost să verifici munca cuiva dacă știi că nu va trișa, dar dacă nu verifici, ei au un stimulent să trișeze; Dacă sunteți designer, doriți să dovediți că sistemul dvs. este compatibil cu stimulente, ceea ce înseamnă că, dacă toată lumea se comportă în mod consecvent cu stimulentele lor, nu va avea loc nicio înșelăciune. Acesta este un domeniu în care intuiția te poate duce greșit. Această problemă este mult mai grea decât pare, așa cum vom vedea când vom despacheta stimulentele părților de mai jos.

Un model super simplu

Începem prin a construi cel mai simplu model posibil. Să presupunem că sunt doi jucători. Afirmatorul face o afirmație, care poate fi adevărată sau falsă. Verificatorul poate verifica afirmația celui care afirmă sau poate alege să nu facă nimic, probabil din ipoteza că cel care afirmă probabil spune adevărul. Presupunem că costul verificării al verificatorului este C. Dacă verificatorul verifică și constată că persoana care afirmă a trișat, verificatorul va primi o recompensă de R. (R include toate beneficiile acumulate de verificator ca urmare a prinsului de trișare. Aceasta include beneficiile realizate „în afara sistemului”, precum și orice beneficii obținute datorită încrederii crescute în sistem.) Dacă cel care afirmă nu este prins, Sub trișare , verificatorul pierde L, de exemplu pentru că cel care afirmă înșelăciune poate lua în mod fraudulos obiecte valoroase de la verificator.

Acum avem două amenințări de care să ne îngrijorăm: mita și lenea. Mituirea este posibilitatea ca persoana care afirmă să-l mituiască pe verificator pentru a nu verifica, permițând astfel celui care afirmă să trișeze fără a fi detectat. Putem preveni acest lucru asigurându-ne că persoana care afirmă deține un depozit foarte mare care este mai mare decât valoarea totală din sistem și plătește verificatorul atunci când este detectată înșelăciune, astfel încât cel care afirmă nu este dispus să plătească mai mult decât recompensa verificatorului R. mită. Acest lucru va preveni mita, dar necesită ca sistemul să fie complet garantat, ceea ce poate fi foarte costisitor.

O altă amenințare este lenea, riscul ca verificatorul să decidă să nu verifice munca celui care afirmă. (Amintiți-vă, verificatorii pot spune că verifică, dar nu o fac de fapt.) Să ne uităm la stimulentele pentru dame pentru a vedea dacă aceasta este o strategie rezonabilă.

Să presupunem că afirmatorul trișează cu probabilitatea X. Acum, utilitatea inspectorului este următoarea:

• Dacă recenzentul verifică: RX-C

• Dacă verificatorul nu verifică: -XL

Verificarea merită numai dacă utilitatea verificării este mai mare decât utilitatea neverificarii, adică dacă X > C/(R+L). Iată vestea proastă: cel care afirmă poate înșela la întâmplare, cu probabilitate mai mică decât C/(R+L), un verificator rațional nu va verifica niciodată, astfel încât cel care afirmă nu va fi prins niciodată trișând.

Să introducem câteva numere. Dacă costul verificării fiecărei tranzacții este de 0,10 USD, iar verificatorul primește o recompensă de 75 USD dacă detectează înșelăciune, dar pierde 25 USD dacă nu reușește să detecteze înșelăciunea, atunci cel care afirmă poate înșela cu impunitate de o mie de ori. Dacă vrem ca acest sistem să ruleze mii de tranzacții, atunci avem o mare problemă. În mod evident, nu putem face nimic în acest model pentru a reduce probabilitatea de a înșela la zero. Nu putem decât să sperăm la un sistem supracolateralizat, astfel încât numitorul lui C/(R+L) să devină mai mare.

Acesta este un rezultat surprinzător de robust – într-un mod prost. Nu depinde deloc de stimulentele celui care afirmă. Atâta timp cât cel care afirmă obține un avantaj diferit de zero din trișarea reușită, poate face acest lucru cu o oarecare probabilitate, știind că nu merită efortul verificatorului de a verifica. De asemenea, acest rezultat nu depinde de cât timp îi acordăm inspectorului pentru a finaliza lucrarea sau dacă plătim pentru (pretins) inspector. Poate te gândești acum, problema este că există un singur inspector. Adăugarea mai multor dame ar reduce probabilitatea de a înșela? În mod surprinzător, nu.

Adăugarea de cenzori nu ajută la prevenirea înșelăciunii

Din nou, să formulăm un model cel mai simplu. Acum sunt doi inspectori care acționează independent. Fiecare checker plătește C dacă face check, iar dacă cineva verifică și îl prinde pe cel care afirmă trișează, o recompensă de R este plătită verificatorului de succes, sau dacă amândoi au bifat, recompensa este împărțită în mod egal între cele două. (Dacă doriți, puteți oferi unuia dintre ei o recompensă completă aleatorie de R în cazul în care toți verifică. Acest lucru nu afectează strategia sau rezultatele nimănui.) Ca și înainte, fiecare verificator va pierde L dacă asertorul Trișează fără să obțină prins.

Rămâne cazul că, dacă afirmatorul trișează mai puțin de C/(R+L) al timpului, atunci nu merită ca verificatorul să verifice, deoarece utilitatea verificării este mai mică decât utilitatea neverificarii. De fapt, problema stimulentelor este mai gravă decât înainte, deoarece costul verificării per piesă este încă C, dar recompensa așteptată pentru un verificator de succes care prind trișare este mai mică decât R, deoarece recompensa uneori trebuie să fie împărțită - recompensa așteptată va fie în R/2 și R. Dacă recompensa așteptată este bR, unde b este între 0,5 și 1, atunci cel care afirmă poate trișa până la C/(bR+L) timp - aceasta este mai multă înșelăciune nedetectată decât dacă ar fi fost un singur verificator! (Matematica se complică puțin, deoarece valoarea lui b depinde de strategia verificatorului, iar strategia lor depinde de b, dar ar trebui să fie clar că uneori vor trebui să împartă recompensa. De asemenea, valoarea efectivă a lui L este, de asemenea, redusă. , din moment ce nu o face, damele nu-și pot pierde L pentru verificarea de către alte dame).

Un loc în care adăugarea de cenzori ar ajuta cu adevărat este prevenirea mituirii. Cu două dame, cel care afirmă trebuie să plătească o mită mai mare de R fiecărui asertor, făcând mită de două ori mai scumpă, permițând miza de 50% în loc de miza totală. Dar compromisul este că cantitatea de înșelăciune crește.

Nu voi trece la matematică aici, dar în baza unor ipoteze rezonabile, creșterea de la o piesă la două ar putea duce la o creștere cu 50% a înșelăciunii nedetectate.

Adăugarea de cenzori agravează lucrurile!

Puteți adăuga mai multe dame și lucrurile se vor înrăutăți. Pe măsură ce numărul de dame crește, verificatorul trebuie să se preocupe mai mult de împărțirea recompensei în mai multe moduri, astfel încât recompensa așteptată pentru fiecare damă reușită scade treptat, determinând creșterea treptată a probabilității celui care afirmă să trișeze în siguranță. Din această perspectivă, cel mai rău caz este că toată lumea din lume ar putea deveni cenzor. Acest lucru nu este infinit de rău, deoarece lucrurile se înrăutățesc pe măsură ce se adaugă mai mulți cenzori, dar cu siguranță nu va ajuta la prevenirea înșelăciunii, chiar dacă elimină efectiv riscul de mită.

Sunteți sigur că sistemul dvs. este compatibil cu stimulente?

Dacă aveți un sistem care se potrivește acestui tip de model și credeți că este compatibil cu stimulente, trebuie să vă gândiți bine de ce. În special, trebuie să explicați de ce verificatorul ar face treaba de a verifica, chiar dacă ei cred că este puțin probabil ca cel care afirmă să trișeze. Nu este suficient să ai o penalizare mare pentru înșelăciune. Pur și simplu să ai o recompensă pentru că ai prins trișori nu este suficient. Pur și simplu să ai o mulțime de dame nu este suficient - de fapt, poate înrăutăți lucrurile. De ce este sistemul tău imunitar?

Această provocare se aplică sistemelor precum Optimistic Rollup. Când vorbim despre Arbitrum, se aplică și la noi.

Luând în considerare cele de mai sus, metodele tradiționale de verificare a stimulentelor nu obțin rezultatele dorite - există o rată de înșelăciune de bază sub care verificatorii vor considera că verificarea nu merită. În concluzie:

Există doi jucători, un afirmator, care face o afirmație dacă este adevărată sau falsă și un verificator, care poate verifica afirmația cu un anumit cost de calcul. Dacă verificatorul verifică, utilitatea lui este RX-C, dacă nu verifică, utilitatea sa este -XL, unde R este recompensa pentru că a prins trișare, C este costul verificării și L este pierderea verificatorului din faptul că nu a detectat trișarea. , X este probabilitatea ca asertorul să trișeze (aleasă de afirmator). Unele algebră arată că dacă

Pentru a rezolva această problemă și a crea o situație în care un evaluator bazat pe stimulente va verifica întotdeauna, trebuie să schimbăm stimulentele recenzentului. Problema de bază este că, în modelul inițial, stimulentele pozitive pentru dame de a verifica sunt toate proporționale cu Dacă dorim un stimulent de cec care funcționează indiferent, trebuie să creăm un stimulent de cec sau un stimulent pentru neverificare care este independent de acțiunile celui care afirmă.

TrueBit încearcă să facă acest lucru adăugând afirmații false în mod intenționat la setul de afirmații, în esență înlocuind X cu X plus o constantă. Există câteva probleme cu această abordare. (Lucrul original Arbitrum are o secțiune despre problemele de motivație ale TrueBit.)

Concentrați-vă pe provocări

Folosim o abordare diferită pe care o numim concentrarea asupra provocării. Ideea este că, dacă afirmatorul calculează o valoare f(x), mai întâi emite x și o provocare criptografică. Pentru a răspunde corect provocării, examinatorul trebuie să cunoască f(x). Numai după ce a apărut provocarea, cel care afirmă publică f(x) - în acest moment, verificatorul a făcut deja munca grea de a calcula f(x), așa că nu are niciun stimulent să fie leneș. (Urmează mai multe detalii despre acord.)

Pentru a reduce numărul de tranzacții în lanț care necesită acest lucru, vom aranja lucrurile astfel încât răspunsul corect la o provocare a unui verificator să fie de obicei tăcerea. Dar, în cazuri rare, verificatorul trebuie să publice o tranzacție foarte mică pe lanț. Dacă verificatorul dă răspunsul greșit - tăcere când ar trebui să fie eliberat sau tăcere când ar trebui să fie eliberat - va pierde un mic depozit.

Să adaptăm modelul original de stimulare pentru a încorpora provocările de atenție. Avem nevoie de doi parametri noi (amândoi îi putem alege): P, procentul de timp în care este postat răspunsul corect al verificatorului și A, penalizarea dacă verificatorul dă un răspuns greșit. Acum, utilitatea inspectorului este:

Dacă este bifat: RX-C

Dacă nu, verificați: -LX-PA

Observația cheie este că atâta timp cât PA > C, atunci verificarea este strategia optimă, indiferent de X (probabilitatea de a înșela).

Cost foarte mic

Pentru a evalua costul, să ne uităm la un exemplu concret. Să presupunem că există o afirmație la fiecare cinci minute și costul verificării este de 0,001 USD. Dacă setăm probabilitatea P la 0,3%, verificatorul va trebui să plătească un depozit de 3 USD. Acum, costul verificatorului pe afirmație este de 0,0003 USD în taxe de gaz (taxa de 0,10 USD pentru gazul pentru postarea răspunsului său non-silențios, înmulțit cu probabilitatea de 0,3% pe care trebuie să îl posteze), plus aproximativ 0,0003 USD pentru a-și bloca pariul de 3 USD timp de cinci minute Totalul costul dobânzii este de 0,0006 USD per afirmație.

Extensie pentru mai mulți inspectori

Provocarea de concentrare se scalează bine cu mai mulți examinatori. Protocolul emite o provocare care afectează fiecare verificator în mod diferit, forțând fiecare verificator să calculeze singur f(x). Fiecare verificator va experimenta același cost (în cazul nostru, 0,0006 USD per afirmație).

Într-un sistem deschis, oricine este eligibil să verifice calculele și puteți permite oricui să se înregistreze ca verificator și să plaseze mic depozit necesar. Acest lucru îi va face eligibili să primească provocări de atenție și, eventual, să primească compensații de la dezvoltatorii dapp. Oricine poate contesta afirmațiile incorecte ale unui afirmator, dar numai examinatorii înregistrați se confruntă cu provocări de atenție.

Detalii tehnice ale contractului

Acum că înțelegem ce poate face pentru noi concentrarea pe provocări, haideți să ne aprofundăm în detaliile tehnice ale modului în care funcționează.

Fiecare verificator are o cheie privată k și o cheie publică corespunzătoare gᵏ, definite într-un grup adecvat. Cheia publică a fiecărui verificator este cunoscută de toată lumea. De asemenea, ne vom baza pe o funcție hash adecvată H.

Pentru a lansa o provocare la calculul lui f(x), unde funcția f este cunoscută în avans, afirmatorul generează o valoare aleatorie r și apoi emite (x, gʳ) ca o provocare.

Un verificator care posedă cheia privată k ar trebui să răspundă provocării publicând o tranzacție mică numai dacă H(gʳᵏ, f(x)) < T, unde T este un prag ales corespunzător. Rețineți că numai assertorul (care știe r) și acel verificator particular (care își cunoaște cheia privată k) pot calcula hash-ul, deoarece ei sunt singurii care pot calcula gʳᵏ. De asemenea, rețineți că calcularea hashului necesită cunoașterea f(x).

După ce verificatorii au avut timp să-și posteze răspunsurile la provocare, cel care afirmă își poate posta f(x) și dacă vreun verificator nu este de acord cu acesta, acesta va fi contestat ca de obicei. În acest moment, afirmatorul poate acuza orice verificator de răspunsuri incorecte afirmătorul trebuie să emită r pentru a-și fundamenta acuzația. Minerul sau contractul poate verifica dacă acuzația este corectă și pedepsește contravenientul, dar dacă afirmația f(x) a afirmatorului nu este acceptată în cele din urmă ca fiind corectă, acuzația va fi ignorată. Dacă vreun verificator este amendat, cel care afirmă va primi jumătate din fondurile pierdute, iar cealaltă jumătate va fi distrusă.

Această abordare oferă examinatorului stimulentele potrivite. A ști cum ar trebui să răspundă un verificator la o provocare necesită cunoașterea cheii private a verificatorului și f(x), astfel încât fiecare verificator va dori să calculeze f(x). Cu excepția cazului în care verificatorul calculează f(x) în sine, nu poate aplica protocolul în siguranță. Răspunsurile altor verificatoare nu sunt utile în determinarea f(x) deoarece se bazează pe cheile private ale acelor verificatoare. Dacă un verificator se bazează pe faptul că altcineva îi spune f(x), nu are nicio modalitate de a verifica acea valoare revendicată (altul decât calculul f(x) în sine), iar verificatorul riscă să fie penalizat dacă este greșit. Există chiar și un stimulent pentru o parte să încerce să inducă în eroare verificatorul cu privire la f(x) - adică cel care afirmă, care profită din eroarea verificatorului și poate folosi aceste profituri pentru a mitui „prietenii” verificatorului pentru a oferi verificatorului informații greșite. .

Optimizare si concluzie

Există mai multe trucuri pentru a face acest protocol mai eficient. De exemplu, am putea grupa o afirmație cu următoarea provocare într-o tranzacție în lanț, astfel încât provocarea să nu mărească numărul de tranzacții. Dacă P este mic (de exemplu, 0,3% în exemplul nostru) și numărul de dame nu este foarte mare, atunci verificatorii rareori trebuie să scrie tranzacții pe lanț, astfel încât impactul general al protocolului asupra numărului de tranzacții în lanț va fii cel mai mic.

Cu o implementare inteligentă, costul acestui protocol ar trebui să fie foarte scăzut în comparație cu costul inițial al emiterii aserțiilor în lanț. În cazul nostru, adăugarea provocărilor de atenție la protocolul de afirmare-provocare existent crește costul total cu mai puțin de 1%.

Și câștigurile sunt substanțiale - obținem un protocol de verificare compatibil cu stimulente, care este imun la dilema validatorului. Atâta timp cât cel puțin un verificator este rațional, pretențiile celui care afirmă vor fi întotdeauna verificate.

Pentru alte informații despre proiect, vă rugăm să consultați: Lanțul public de jocuri Xai: baza de date Binance Square

#ARB #Layer3 #game #XAI #web3