Finora, il mito del welfare nel circolo valutario/industria della blockchain continua, e il prossimo importante ambito della “creazione di ricchezza” si concentra sul “percorso di gioco”. Il progetto XAI sta organizzando un evento Odyssey. Se sei interessato, partecipa a questo mio articolo sulla piazza: XAI Game Public Chain Odyssey Event Zero-Cost Beginner's Guide

In questo articolo ti fornirò una spiegazione dettagliata del nodo Sentry della catena pubblica del gioco XAI! Questo articolo è relativamente tecnico, quindi se sei interessato a guadagnare soldi, devi leggerlo attentamente. Perché solo se capisci tu stesso la "logica" e migliori le tue capacità cognitive, puoi avere l'opportunità di fare soldi!

Se vuoi vedere direttamente il nodo Sentinella, leggi direttamente la prima parte senza leggere dopo; se vuoi un ciclo logico chiuso, allora devi leggere la seconda, la terza e la quarta parte!

Quello che voglio sottolineare è che Xai riceve supporto tecnico diretto da Offchain Labs. Questo tipo di supporto è inimmaginabile per altre catene Orbit! ed è una componente chiave del piano strategico di Xai all’interno dell’ecosistema Arbitrum.

Parte 1: Spiegazione del nodo sentinella

Il nodo Sentry è un nodo di osservazione che monitora il protocollo di rollup Xai e se viene proposto un blocco errato, emetterà un avviso (con qualsiasi mezzo scelto dall'operatore) in modo che altri possano intervenire. Lo scopo del nodo sentinella è risolvere il dilemma del verificatore (vedi Parte IV per i dettagli sul dilemma del verificatore).

Clicca qui per vedere il video promozionale:

Promozione video del nodo Sentinel

Esegui i nodi Xai e ottieni token Xai con un clic!

I nodi Sentinel possono essere eseguiti sui laptop, sui desktop o anche sulle istanze cloud dei membri della comunità. Finché il nodo è in esecuzione, esiste un algoritmo probabilistico che determina se l'operatore del nodo verrà ricompensato con token esXai dalla rete. Puntando Xai, aumenti la probabilità dell'algoritmo. Se non conosci esXai, partecipa al mio articolo sulla piazza: Interpretazione della “Token Economy” del progetto XAI

1. Principio di funzionamento del nodo sentinella

Il protocollo Attention Challenge v2 coinvolge più partecipanti, tra cui la catena Xai, una catena madre (Arbitrum One), uno sfidante fidato, le sentinelle Xai e le loro chiavi di licenza e un contratto Referee (arbitro). Lo sfidante crea una coppia di chiavi BLS, registra la chiave pubblica nel contratto dell'arbitro e firma le affermazioni fatte dal validatore nel protocollo rollup Xai su Arbitrum One. Queste firme vengono verificate dal contratto dell'arbitro e registrate come contestazioni associate al reclamo.

Xai Sentinels può registrarsi con il contratto di arbitro acquistando una chiave di licenza Sentinel per avere diritto a pubblicare dichiarazioni sui reclami. Ottengono la radice dello stato dell'affermazione corretta che sarà il successore dell'affermazione emittente. Se una determinata condizione è soddisfatta, rilasciano una dichiarazione sulla dichiarazione invocando il contratto arbitrale. Se viene creata e confermata una dichiarazione di follow-up e Sentinel emette la dichiarazione corretta, Sentinel contatterà il contratto di riferimento per emettere una transazione di riscatto. L'arbitro verificherà diverse condizioni prima di pagare la ricompensa alla Sentinella.

Questo protocollo garantisce che ogni attestazione utilizzi completamente i messaggi di posta in arrivo esistenti al momento della creazione dell'attestazione precedente. Ciò significa che una volta creata un'affermazione, le radici dello stato delle sue successive affermazioni corrette sono completamente determinate e possono essere calcolate da qualsiasi nodo. Ciò incoraggia ciascuna sentinella a determinare la radice dello stato successivo corretta. La ricompensa della sentinella è determinata dall'ID di autorizzazione dello stato della sentinella, dalla radice dello stato successivo e da un valore di sfida che non diventa noto finché la radice dello stato successivo non viene completamente determinata.

2. Chi può gestire il nodo?

Chiunque può utilizzare Sentinel scaricando il software, installandolo ed eseguendolo. Tuttavia, per ricevere i premi in token, è necessario acquistare almeno una chiave di licenza Sentinel.

Gli acquirenti devono superare con successo un controllo KYC per garantire che:

  • non negli Stati Uniti

  • Non soggetto ad alcuna sanzione dell'OFAC statunitense (l'OFAC è riportato in un elenco di sanzioni statunitensi)

I nodi Sentinel che non sono in funzione o che non dispongono dei fondi adeguati per pagare le tariffe del gas (GAS) non accumuleranno premi, anche con una chiave di licenza. Pertanto, gli operatori vorranno garantire che i loro nodi siano finanziati, online e funzionanti.

3.Contratto arbitrale (arbitro).

Referee è un contratto intelligente progettato per garantire il rispetto di regole predefinite, verificare l'origine delle iscrizioni e distribuire premi ai vincitori all'interno del sistema. Il contratto intelligente di arbitro è un componente chiave nell'ecosistema Xai, responsabile della gestione e della convalida delle richieste avanzate dai nodi sentinella nella rete. Il contratto ha diverse funzioni fondamentali:

3.1 Presentazione della dichiarazione

Il contratto arbitrale consente ai nodi sentinella di presentare reclami alle sfide. Questa funzione può essere richiamata solo dal proprietario della chiave di licenza Sentinel o dal suo indirizzo approvato su questo contratto. Questa funzione controlla se la sfida è ancora aperta per l'invio e se è già stata inviata una NodeLicense per questa sfida.

3.2 Ricevi ricompense

Il contratto contiene una funzionalità che consente agli utenti di richiedere premi per richieste di successo. Questa funzione controlla se la sfida è stata chiusa per l'invio e controlla se il proprietario della chiave del nodo ha completato il KYC. Se queste condizioni sono soddisfatte e la richiesta è idonea al pagamento, il premio verrà inviato all'utente.

3.3 Creare hash di richiesta e controllare il pagamento.

Il contratto ha una funzione che crea un hash dell'ID di autorizzazione sentinella, dell'ID di sfida, di challengerSignedHash nella sfida e della successiva radice dello stato. Quindi controlla se l'hash è inferiore a una determinata soglia, calcolata in base al numero totale di licenze Sentinel coniate. Se l'hash è inferiore alla soglia, la richiesta è idonea al pagamento.

Il contratto di arbitro garantisce l'integrità della rete Xai convalidando le richieste e premiando quelle di successo, incentivando così i nodi sentinella a monitorare la rete in modo accurato e diligente.

4. Componente sfidante

Lo sfidante è un’entità fidata nell’ecosistema Xai. Crea una coppia di chiavi BLS e registra la chiave pubblica nel contratto di arbitro. Quando un validatore presenta una richiesta nel protocollo Xai rollup, lo sfidante firma la richiesta utilizzando la propria chiave privata e invia la firma al referee. L'arbitro verifica la firma e la registra come contestazione associata alla dichiarazione. Questo processo garantisce l'integrità delle affermazioni effettuate nel protocollo di rollup Xai.

5. Chiave (autorizzazione chiave del nodo Sentinel, basata su NFT)

La chiave di licenza Sentinel è un token univoco e non fungibile (NFT) necessario per far funzionare un nodo Sentinel nella rete Xai. Le licenze Sentinel servono come prova di idoneità per i nodi a inviare richieste e ricevere premi. Viene coniato inviando la quantità corretta di ETH e il prezzo del conio è determinato da un sistema di soglie crescenti.

La licenza del nodo gioca un ruolo chiave nel contratto arbitrale. Quando un nodo desidera inviare una richiesta a una sfida, deve fornire il proprio ID di autorizzazione Sentinel. Il contratto di arbitro verifica se la licenza Sentinel è valida e se il nodo è il proprietario della licenza Sentinel o un operatore approvato (sezione KYC sopra). Se queste condizioni sono soddisfatte, la rivendicazione del nodo viene sottoposta alla sfida.

Le autorizzazioni Sentinel entrano in gioco anche quando si richiedono ricompense per richieste riuscite. Il contratto di arbitro verifica se il titolare della licenza Sentinel ha completato il KYC e se la dichiarazione è idonea al pagamento. Se queste condizioni vengono soddisfatte, la ricompensa viene inviata al proprietario della licenza Sentinel.

In sintesi, il permesso Sentinel è un componente chiave della rete Xai, che regola il funzionamento dei nodi Sentinel, la presentazione dei reclami e la distribuzione dei premi.

6. Scaricare ed eseguire il nodo

Per eseguire un nodo sentinella, gli utenti devono solo scaricare un pacchetto software specifico. Questo pacchetto può essere utilizzato in un'applicazione desktop o come strumento da riga di comando sul tuo computer. In poche parole, queste app sono strumenti che rendono il software Sentinel più facile da usare. Lo scopo di questo pacchetto è automatizzare tutte le operazioni necessarie per eseguire Sentinel, rendendone molto semplice la configurazione e l'utilizzo, anche per chi non è un tecnico.

Questo pacchetto aiuta gli utenti con attività quali configurazione, gestione e interazione con altre parti e dispone di un'interfaccia facile da usare che consente agli utenti di visualizzare e regolare facilmente le impostazioni. Utilizzando questo pacchetto, gli utenti possono concentrarsi maggiormente su come correre meglio e ottenere più premi in gettoni. Gli utenti possono scegliere di eseguire questo pacchetto utilizzando un'applicazione desktop o uno strumento da riga di comando, entrambi molto facili da usare e che rendono il processo operativo molto fluido.

7. Funzione portafoglio Sentinel

Nell'ecosistema Xai, il portafoglio Sentinel gioca un ruolo chiave nell'interazione tra i nodi Sentinel e gli smart contract arbitrali. Sentinel Wallet funge da agente intermediario ed è responsabile dell'invio di dichiarazioni all'arbitro per conto delle Sentinelle interessate. Ciò si ottiene attraverso funzioni specifiche nel contratto di riferimento che possono essere richiamate solo dal proprietario della chiave di licenza Sentinel o dal suo indirizzo approvato su questo contratto.

Il portafoglio Sentinel può inviare una dichiarazione alla sfida chiamando la funzione sendAssertionToChallenge nel contratto di riferimento. Questa funzione controlla se la sfida è ancora aperta per l'invio e se la chiave del nodo è già stata inviata per questa sfida.

Il Portafoglio Sentry può anche richiedere premi per richieste di successo richiamando la funzioneclaimReward nel contratto di arbitro. Questa funzionalità controlla se la sfida è stata chiusa per l'invio e controlla se il proprietario della licenza Sentinel ha completato un controllo "KYC". Se queste condizioni sono soddisfatte e la richiesta è idonea al pagamento, la ricompensa verrà inviata al proprietario del Sentinel.

In sintesi, il Sentinel Wallet funge da messaggero, facilitando l’interazione tra nodi e arbitri, garantendo così il buon funzionamento della rete Xai.

8. Licenza

Il rapporto tra il numero di licenze e la capacità di invio del nodo è fondamentale. Sebbene sia possibile che a un nodo siano associate più licenze, è importante comprendere che il numero di licenze influisce direttamente sulla capacità del nodo di impegnarsi. In sostanza, per garantire quote di commit eque, il rapporto tra licenze e istanze del nodo viene mantenuto su 1:1. Seguendo i principi di cui sopra, il sistema stabilisce un approccio strutturato alla concessione di licenze, alla presentazione dei diritti e al funzionamento complessivo dei nodi all’interno dell’ecosistema.

9.Requisiti software e hardware del nodo Sentinella

Il software del nodo Sentinel supporta desktop Windows, Mac e Linux (richiede 64 bit). Di seguito sono riportate le risorse attuali necessarie per eseguire il software del nodo Sentinel per un massimo di 100 chiavi di licenza:

  • 4 GB di RAM

  • 2 core della CPU

  • 60 GB di spazio su disco

  • Processore x86/X64 (supporta il processore ARM, come il chip Apple M1/M2)

  • Connessione Internet stabile

Quando si aggiungono chiavi aggiuntive a un nodo, idealmente le capacità hardware dovrebbero aumentare di conseguenza. Tuttavia non è obbligatorio assegnare a ciascuna chiave una macchina separata. Si prevede che il sistema sarà scalabile per ospitare dozzine di chiavi su una singola macchina, e forse di più.

Nota: questi requisiti hardware sono soggetti a modifiche.

10. Ricompense stimate della rete del nodo Sentry

Modello economico dei token XAI, fare riferimento a: Interpretazione della "Token Economy" del progetto XAI

Ecco tre scenari per stimare le ricompense Xai che potresti guadagnare eseguendo un nodo Sentry. Questi tre scenari si basano sui seguenti presupposti:

  • La somma di XAI ed esXAI non supererà mai 2.500.000.000. Dato che l'ecosistema Xai è dinamico, è impossibile prevedere con precisione i premi mensili in token per ciascuna chiave Sentry.

  • Il 100% del GAS viene bruciato, quindi non vi è alcuna garanzia che la fornitura sarà sempre inflazionistica, potrebbe essere deflazionistica.

  • La Fondazione Xai non venderà più di 50.000 chiavi Sentry (un nodo può caricare più chiavi). Si prevede che ciò richiederà 2-3 anni. Le chiavi della sentinella diventano più costose nel tempo.

  • L'importo mensile esXAI per chiave Sentry può anche variare in base al numero di partecipanti allo staking nell'ecosistema.

Il significato delle tre tabelle seguenti è che, in base alla diversa circolazione dei token XAI ed esXAI, il numero di chiavi di nodo attivate nella rete e i corrispondenti premi mensili previsti in token per chiave:

Scenario A stimato: se sono in circolazione un totale di 750.000 token XAI ed esXAI, ciascuna chiave Sentry riceverà premi esXAI in base alla seguente tabella:

Stima dello scenario B: se sono in circolazione un totale di 1.250.000.000 di token XAI ed esXAI, ciascuna chiave Sentry riceverà premi esXAI in base alla seguente tabella:

Stima dello scenario C: se sono in circolazione un totale di 2.187.500.000 token XAI ed esXAI, ciascuna chiave Sentry riceverà premi esXAI in base alla seguente tabella:

Parte 2: XAI è sviluppato e gestito da Arbitrum (ARB), quindi dobbiamo far luce sull'architettura di Arbitrum:

1. Decisione Nitro

Tutte le catene Arbitrum sono costruite su Arbitrum Nitro, che è la tecnologia alla base di tutte le catene dell'ecosistema. Nitro esegue una versione biforcuta di Geth e utilizza WebAssembly come macchina virtuale sottostante a prova di frode.

2.Qualsiasi decisione fiduciaria

Anytrust è un protocollo Arbitrum che gestisce la disponibilità dei dati attraverso un insieme di concessori di licenza chiamato Data Availability Committee (DAC). Questo protocollo riduce le commissioni di transazione introducendo un ulteriore presupposto di fiducia relativo alla disponibilità dei dati, anziché utilizzare il meccanismo di disponibilità dei dati senza fiducia di Ethereum.

3. Introduzione ai livelli Arbitrum 2 che potresti conoscere

Arbitrum Nova è un esempio di catena AnyTrust; Arbitrum One è un'altra catena alternativa che implementa il protocollo Arbitrum Rollup puramente trustless (e più intensivo di gas L1). Entrambe le catene sono costruite su Nitro.

4. Catena orbitale

Arbitrum Orbit consente a terze parti di creare le proprie catene Arbitrum Rollup e AnyTrust autogestite. Arbitrum offre le tecnologie Rollup e AnyTrust per la massima flessibilità durante la creazione di catene Orbit. Come tutte le catene dell'ecosistema Arbitrum, sia Arbitrum Rollups che la catena Arbitrum Anytrust Orbit sono costruite utilizzando Nitro come tecnologia di base.

5. Comprendere la situazione di base di Xai

Comprendiamo Xai nel contesto di cui sopra. Xai opera come catena Arbitrum Orbit, sfruttando la tecnologia Anytrust per la massima velocità e il minimo costo. A differenza della maggior parte delle catene Orbit “autogovernate”, Xai beneficia del supporto tecnico diretto di Offchain Labs. Questo tipo di supporto è inimmaginabile per altre catene Orbit! ed è una componente chiave del piano strategico di Xai all’interno dell’ecosistema Arbitrum.

Parte 3: Dopo aver appreso i concetti di cui sopra, comprendiamo ulteriormente l'architettura:

1.AnyTrust: infrastruttura blockchain rivoluzionaria

All'interno del framework AnyTrust e come variante all'avanguardia della tecnologia Arbitrum Nitro, Offchain Labs sfrutta l'innovazione per risolvere alcune delle sfide più urgenti nello spazio blockchain. AnyTrust ci offre una nuova prospettiva incorporando presupposti di light trust, riducendo significativamente i costi e garantendo allo stesso tempo una forte disponibilità e sicurezza dei dati.

2. Ridurre i costi attraverso presupposti di fiducia

Al centro del protocollo Arbitrum, tutti i nodi Arbitrum (compresi i validatori che verificano la correttezza della catena e mettono in stake i risultati accurati) devono accedere ai dati di ogni transazione di livello due (L2) nella casella di posta della catena Arbitrum. Tradizionalmente, il rollup Arbitrum garantisce l’accesso ai dati pubblicando i dati come calldata sul livello uno (L1) Ethereum, un processo che genera commissioni significative sul gas Ethereum, che è una delle principali componenti di costo in Arbitrum.

3. Flessibilità dei set

I ketset svolgono un ruolo chiave nell'architettura di AnyTrust. Specificano le chiavi pubbliche dei membri del comitato e il numero di firme necessarie per verificare il certificato di disponibilità dei dati (DACert). I ketset offrono flessibilità per cambiare i membri del comitato e consentono ai membri del comitato di aggiornare le proprie chiavi secondo necessità.

4. Certificati di disponibilità dei dati (DACert)

In AnyTrust, un concetto base è il certificato di disponibilità dei dati (DACert). Un DACert è costituito dall'hash del blocco dati, da una data di scadenza e dalla prova che i membri del comitato N-1 hanno firmato la coppia (hash, data di scadenza). Questa prova include un hash del set di chiavi utilizzato per la firma, una bitmap che indica quali membri del comitato hanno firmato e una firma aggregata BLS sulla curva BLS12-381, a dimostrazione del firmatario.

A causa del presupposto di fiducia 2 su N, DACert funge da prova che i dati di un blocco saranno disponibili per almeno un membro onesto del comitato fino a una data di scadenza specificata. Questo presupposto di fiducia è la base per l'affidabilità e la sicurezza della disponibilità dei dati all'interno del framework AnyTrust.

5.Doppio meccanismo di rilascio dei dati

AnyTrust introduce un doppio metodo per pubblicare blocchi di dati su L1. Oltre al metodo tradizionale di pubblicazione di blocchi di dati completi, consente anche l'emissione di DACert, ovvero certificati che dimostrano la disponibilità dei dati. Il contratto di posta in arrivo L1 verifica la validità dei DACert, incluso il riferimento ai Keset validi specificati nel DACert.

Il codice L2 responsabile della lettura dei dati dalla posta in arrivo è progettato per gestire entrambi i formati di dati senza problemi. Quando viene rilevato un DACert, esegue controlli di validità, inclusa la garanzia che il numero di firmatari soddisfi i requisiti di Ketsets, la convalida delle firme aggregate e la conferma della scadenza oltre il timestamp L2 corrente. I DACert validi garantiscono che il blocco dati sia accessibile e possa essere sfruttato dal codice L2.

6. Server di disponibilità dei dati (DAS)

I membri del comitato gestiscono il Data Availability Server (DAS), che fornisce due API chiave:

(1) API sorter: progettata per l'utilizzo da parte del sorter della catena Arbitrum, questa interfaccia JSON-RPC consente al sorter di inviare blocchi di dati a DAS per l'archiviazione.

(2) API REST: progettato per una più ampia accessibilità, il protocollo basato su HTTP(S) RESTful consente il recupero di blocchi di dati tramite hash. È completamente memorizzabile nella cache e può essere distribuito insieme a proxy di memorizzazione nella cache o CDN per migliorare la scalabilità e proteggere da potenziali attacchi DoS.

7. Interazione tra comitato selezionatore

Quando il sorter Arbitrum intende pubblicare un lotto di dati attraverso il comitato, invia i dati e un tempo di scadenza a tutti i membri del comitato in parallelo tramite RPC. Ogni membro del comitato memorizza i dati, firma la coppia (hash, data di scadenza) utilizzando la propria chiave BLS e restituisce la firma e l'indicatore di successo al sequenziatore. Una volta raccolte firme sufficienti, il sequenziatore le aggrega per creare un DACert valido per le coppie (hash, data di scadenza). Questo DACert viene quindi pubblicato nel contratto di posta in arrivo L1, rendendolo accessibile al software della catena AnyTrust di L2. Nel caso in cui il sequenziatore non riesca a raccogliere firme sufficienti entro l'intervallo di tempo specificato, adotta una strategia di "fallback to rollup" e pubblica i dati completi direttamente sulla catena L1. Il software L2 eccelle nel comprendere entrambi i formati di pubblicazione dei dati (tramite DACert o dati completi) e nel gestire ciascun formato in modo appropriato. In sintesi, AnyTrust, in quanto innovazione rivoluzionaria all'interno dell'ecosistema Offchain Labs, rappresenta un progresso fondamentale nell'affrontare la disponibilità dei dati, la sicurezza e l'efficienza in termini di costi dell'infrastruttura blockchain. Attraverso un presupposto di fiducia ragionevole e un nuovo approccio alla pubblicazione dei dati, AnyTrust apre la strada a soluzioni blockchain più scalabili, accessibili e sicure.

Parte 4: Tenendo a mente i concetti di cui sopra, spieghiamo ora perché i nodi sentinella sono importanti: il problema del controllo degli imbroglioni, perché il dilemma del validatore è più difficile di quanto pensi e la soluzione!

L'autore è Ed Felten, capo scienziato dell'Arbitrum

Nei sistemi blockchain, un modello di progettazione comune prevede che una parte svolga un certo lavoro e versi un deposito per un comportamento corretto, quindi inviti altri a verificare il lavoro e togliere questo deposito se scoprono che il lavoratore imbroglia. Potresti chiamarlo il modello di progettazione "asserzione-sfida". Lo facciamo in Arbitrum e di recente abbiamo visto proposte come Optimistic Rollup nelle notizie.

Questi sistemi possono essere influenzati dal dilemma del validatore, che è fondamentalmente l'osservazione che non ha senso controllare il lavoro di qualcuno se sai che non imbroglia, ma se non controlli, hanno un incentivo a imbrogliare; Se sei un designer, vuoi dimostrare che il tuo sistema è compatibile con gli incentivi, il che significa che se tutti si comportano in modo coerente con i propri incentivi, non si verificheranno imbrogli. Questa è un'area in cui l'intuizione può portarti in errore. Questo problema è molto più difficile di quanto sembri, come vedremo quando analizzeremo gli incentivi dei partiti più avanti.

Un modello semplicissimo

Iniziamo costruendo il modello più semplice possibile. Supponiamo che ci siano due giocatori. L'assertore fa un'affermazione, che può essere vera o falsa. Il controllore può verificare l'asserzione dell'assertore, oppure può scegliere di non fare nulla, presumibilmente partendo dal presupposto che l'assertore probabilmente sta dicendo la verità. Assumiamo che il costo del controllo sostenuto dalla pedina sia C. Se la pedina controlla e scopre che l'assertore ha imbrogliato, riceverà una ricompensa di R. (R include tutti i benefici maturati dalla pedina come risultato della scoperta di un imbroglio. Ciò include i benefici realizzati “al di fuori del sistema” così come eventuali benefici ottenuti grazie ad una maggiore fiducia nel sistema.) Se l’assertore non viene scoperto, Sotto imbroglio , la pedina perde L, ad esempio perché l'assertore imbroglione può sottrarre in modo fraudolento oggetti di valore alla pedina.

Ora abbiamo due minacce di cui preoccuparci: la corruzione e la pigrizia. La corruzione è la possibilità che l'assertore possa corrompere la pedina affinché non controlli, permettendo così all'assertore di imbrogliare senza essere scoperto. Possiamo evitare che ciò accada assicurandoci che l'assertore depositi in garanzia un deposito molto grande che è maggiore del valore totale nel sistema e paga la pedina quando viene rilevato un imbroglio, in modo che l'assertore non sia disposto a pagare più della ricompensa della pedina R's tangente. Ciò eviterà la corruzione, ma richiede che il sistema sia completamente collateralizzato, il che può essere molto costoso.

Un'altra minaccia è la pigrizia, il rischio che il controllore decida di non controllare il lavoro dell'assertore. (Ricordate, le pedine possono dire che stanno controllando ma in realtà non lo stanno facendo.) Diamo un'occhiata agli incentivi per le pedine per vedere se questa è una strategia ragionevole.

Supponiamo che l'assertore imbrogli con probabilità X. Ora, l'utilità dell'ispettore è la seguente:

  • Se il revisore seleziona: RX-C

  • Se la pedina non controlla: -XL

Controllare è utile solo se l'utilità del controllo è maggiore dell'utilità di non controllare, cioè se X > C/(R+L). Ecco la brutta notizia: l'assertore può imbrogliare in modo casuale, con probabilità inferiore a C/(R+L), un controllore razionale non controllerà mai, quindi l'assertore non verrà mai sorpreso a imbrogliare.

Inseriamo alcuni numeri. Se il costo del controllo di ogni transazione è di $ 0,10, e il controllore riceve una taglia di $ 75 se rileva un imbroglio, ma perde $ 25 se non riesce a rilevare un imbroglio, allora l'assertore può imbrogliare impunemente mille volte. Se vogliamo che questo sistema esegua migliaia di transazioni, allora abbiamo un grosso problema. Ovviamente non c’è nulla che possiamo fare in questo modello per ridurre a zero la probabilità di imbrogliare. Possiamo solo sperare in un sistema sovracollateralizzato in modo che il denominatore di C/(R+L) diventi più grande.

Questo è un risultato sorprendentemente solido, nel senso negativo. Non dipende affatto dagli incentivi dell'assertore. Finché l'assertore ottiene un vantaggio diverso da zero da un imbroglio riuscito, può farlo con una certa probabilità, sapendo che non vale la pena fare check da parte della pedina. Inoltre, questo risultato non dipende da quanto tempo concediamo all'ispettore per completare il lavoro o dal fatto che paghiamo il (presunto) ispettore. Forse adesso stai pensando che il problema è che c'è un solo ispettore. Aggiungere più pedine ridurrebbe la probabilità di imbrogliare? Sorprendentemente, non è così.

L'aggiunta di censure non aiuta a prevenire gli imbrogli

Ancora una volta, formuliamo un modello più semplice. Ora ci sono due ispettori che agiscono in modo indipendente. Ciascuna pedina paga C se fa check, e se qualcuno checka e sorprende l'assertore a imbrogliare, una ricompensa di R viene pagata alla pedina che ha successo, o se entrambi hanno checkato, la ricompensa è divisa equamente tra i due. (Se vuoi, puoi dare a uno di loro una ricompensa casuale completa di R nel caso in cui tutti checkino. Ciò non influenza la strategia o i risultati di nessuno.) Come prima, ogni pedina perderà L se l'assertore Bara senza ottenere preso.

Resta il fatto che se l'assertore imbroglia meno di C/(R+L) del tempo, allora non vale la pena per chi controlla controllare, poiché l'utilità di controllare è inferiore all'utilità di non controllare. In effetti, il problema dell'incentivo è peggiore di prima, perché il costo del check per pedina è ancora C, ma la ricompensa attesa per una pedina che riesce a catturare una pedina è inferiore a R, perché la ricompensa a volte deve essere divisa: la ricompensa attesa sarà essere in R/2 e R. Se la ricompensa attesa è bR, dove b è compreso tra 0,5 e 1, allora l'assertore può imbrogliare fino a C/(bR+L) tempo - questo è un numero maggiore di imbrogli non rilevati che se ci fosse una sola pedina! (I calcoli diventano un po' complicati perché il valore di b dipende dalla strategia della pedina, e la sua strategia dipende da b, ma dovrebbe essere chiaro che a volte sarà necessario dividere la ricompensa. Inoltre, anche il valore effettivo di L è ridotto , dal momento che non lo si fa, le pedine non possono perdere la loro L se fanno check da parte di altre pedine).

Un ambito in cui l’aggiunta di censori aiuterebbe davvero è la prevenzione della corruzione. Con due pedine, l'assertore deve pagare una tangente superiore a R a ciascun assertore, rendendo la tangente due volte più costosa, consentendo una puntata del 50% invece della puntata completa. Ma il compromesso è che la quantità di imbrogli aumenta.

Non entrerò nei dettagli qui, ma in base a presupposti ragionevoli, passare da una a due pedine potrebbe comportare un aumento del 50% degli imbrogli non rilevati.

L'aggiunta di censori peggiora le cose!

Puoi aggiungere più pedine e le cose peggioreranno. Man mano che il numero di pedine aumenta, la pedina deve preoccuparsi maggiormente della suddivisione della ricompensa in più modi, quindi la ricompensa attesa per ogni pedina che ha successo diminuisce gradualmente, facendo aumentare gradualmente la probabilità dell'assertore di imbrogliare in modo sicuro. Da questo punto di vista, lo scenario peggiore è che chiunque nel mondo possa diventare un censore. Ciò non è infinitamente negativo, dal momento che le cose peggiorano man mano che vengono aggiunti ulteriori censori, ma certamente non aiuterà a prevenire gli imbrogli, anche se elimina effettivamente il rischio di corruzione.

Sei sicuro che il tuo sistema sia compatibile con gli incentivi?

Se disponi di un sistema che si adatta a questo tipo di modello e ritieni che sia compatibile con gli incentivi, devi riflettere attentamente sul perché. In particolare, è necessario spiegare perché il verificatore dovrebbe svolgere il lavoro di controllo, anche se ritiene improbabile che l'assertore imbrogli. Avere semplicemente una grossa penalità per imbrogliare non è sufficiente. Avere semplicemente una ricompensa per aver scoperto gli imbroglioni non è sufficiente. Avere semplicemente molte pedine non è sufficiente, anzi, può peggiorare le cose. Perché il tuo sistema è immune?

Questa sfida si applica a sistemi come Optimistic Rollup. Quando parliamo di Arbitrum vale anche per noi.

Tenendo conto di quanto sopra, i tradizionali metodi di controllo degli incentivi non raggiungono i risultati desiderati: esiste un tasso di imbroglio di base al di sotto del quale i controllori considereranno il controllo non utile. Insomma:

Ci sono due giocatori, un assertore, che fa un'affermazione se è vera o falsa, e un controllore, che può verificare l'affermazione ad un certo costo computazionale. Se la pedina fa check, la sua utilità è RX-C, se non checka, la sua utilità è -XL, dove R è la ricompensa per aver scoperto che barare, C è il costo del check e L è la perdita della pedina per non aver scoperto che bara. , X è la probabilità che l'assertore imbrogli (scelta dall'assertore). Un po' di algebra lo dimostra se

Per risolvere questo problema e creare una situazione in cui un revisore basato sugli incentivi controllerà sempre, dobbiamo modificare gli incentivi del revisore. Il problema di base è che nel modello originale gli incentivi positivi per i controllori sono tutti proporzionali Se vogliamo un incentivo al controllo che funzioni a prescindere, dobbiamo creare un incentivo al controllo o un disincentivo per non controllare che sia indipendente dalle azioni dell'assertore.

TrueBit tenta di farlo aggiungendo affermazioni intenzionalmente false all'insieme di asserzioni, sostituendo essenzialmente X con X più una costante. Ci sono alcuni problemi con questo approccio. (Il documento originale di Arbitrum contiene una sezione sui problemi di motivazione di TrueBit.)

Concentrarsi sulle sfide

Usiamo un approccio diverso che chiamiamo focalizzazione sulla sfida. L'idea è che se l'assertore sta calcolando un valore f(x), prima emette x e una sfida crittografica. Per rispondere correttamente alla sfida, l'esaminatore deve conoscere f(x). Solo dopo che si è verificata la sfida, l'assertore pubblica f(x): a questo punto, il controllore ha già svolto il duro lavoro di calcolo di f(x), quindi non ha alcun incentivo a essere pigro. (Seguono ulteriori dettagli sull'accordo.)

Per ridurre il numero di transazioni on-chain che ciò richiede, organizzeremo le cose in modo che la risposta corretta a una sfida da parte di una pedina sia solitamente il silenzio. Ma in rari casi, il controllore deve pubblicare una transazione molto piccola sulla catena. Se la pedina dà la risposta sbagliata - silenzio quando dovrebbe essere rilasciato, o silenzio quando dovrebbe essere rilasciato - perderà un piccolo deposito.

Adattiamo il modello di incentivi originale per incorporare le sfide dell'attenzione. Abbiamo bisogno di due nuovi parametri (entrambi selezionabili): P, la percentuale di volte in cui viene pubblicata la risposta corretta della pedina, e A, la penalità se la pedina dà una risposta sbagliata. Ora, l'utilità dell'ispettore è:

Se selezionato: RX-C

In caso contrario verificare: -LX-PA

L’osservazione chiave è che finché PA > C, controllare è la strategia ottimale, indipendentemente da quanto sia X (la probabilità di imbrogliare).

Costo molto basso

Per valutare il costo, vediamo un esempio concreto. Supponiamo che venga effettuata un'asserzione ogni cinque minuti e che il costo della verifica sia pari a $ 0,001. Se impostiamo la probabilità P allo 0,3%, il controllore dovrà pagare un deposito di 3$. Ora, il costo per asserzione del controllore è di $ 0,0003 in commissioni per il gas (la commissione per il gas di $ 0,10 per aver pubblicato la sua risposta non silenziosa, moltiplicata per la probabilità dello 0,3% che deve pubblicare), più circa $ 0,0003 per bloccare la sua scommessa di $ 3 per cinque minuti. il costo degli interessi è di $ 0,0006 per asserzione.

Estensione per più ispettori

La sfida focalizzata si adatta bene a più esaminatori. Il protocollo lancia una sfida che influenza ciascuna pedina in modo diverso, costringendo ciascuna pedina a calcolare f(x) da sola. Ciascuna pedina subirà lo stesso costo (nel nostro caso, $ 0,0006 per asserzione).

In un sistema aperto, chiunque può controllare i calcoli e puoi consentire a chiunque di registrarsi come controllore e di effettuare il piccolo deposito richiesto. Ciò li renderà idonei a ricevere sfide di attenzione e potenzialmente a ricevere un compenso dagli sviluppatori di dapp. Chiunque può contestare le affermazioni errate di un assertore, ma solo i controllori registrati devono affrontare sfide di attenzione.

Dettagli tecnici dell'accordo

Ora che abbiamo capito cosa può fare per noi concentrarci sulle sfide, entriamo nei dettagli tecnici di come funzionano.

Ciascuna pedina ha una chiave privata k e una corrispondente chiave pubblica gᵏ, definite in un apposito gruppo. La chiave pubblica di ciascuna pedina è nota a tutti. Faremo affidamento anche su un'apposita funzione hash H.

Per lanciare una sfida al calcolo di f(x), dove la funzione f è nota in anticipo, l'assertore genera un valore casuale r e quindi emette (x, gʳ) come sfida.

Un controllore in possesso della chiave privata k dovrebbe rispondere alla sfida pubblicando una piccola transazione solo se H(gʳᵏ, f(x)) < T, dove T è una soglia opportunamente scelta. Si noti che solo l'assertore (che conosce r) e quel particolare controllore (che conosce la sua chiave privata k) possono calcolare l'hash, poiché sono gli unici che possono calcolare gʳᵏ. Si noti inoltre che il calcolo dell'hash richiede la conoscenza di f(x).

Dopo che le pedine hanno avuto un po' di tempo per postare le loro risposte alla sfida, l'assertore può postare la sua f(x) e se qualche pedina non è d'accordo, verrà contestata come al solito. A questo punto, l'assertore può accusare qualsiasi verificatore di risposte errate; l'assertore deve emettere r per comprovare la sua accusa. Il minatore o il contratto possono verificare se l'accusa è corretta e punire il trasgressore, ma se l'asserzione di f (x) da parte dell'assertore non viene infine accettata come corretta, l'accusa verrà ignorata. Se una pedina viene multata, l'assertore riceverà metà dei fondi confiscati e l'altra metà verrà distrutta.

Questo approccio dà all’esaminatore i giusti incentivi. Sapere come una pedina dovrebbe rispondere a una sfida richiede la conoscenza della chiave privata della pedina e di f(x), quindi ogni pedina vorrà calcolare f(x). A meno che il controllore non calcoli f(x) da solo, non può applicare in modo sicuro il protocollo. Le risposte di altri controllori non sono utili per determinare f(x) perché si basano sulle chiavi private di tali controllori. Se una pedina fa affidamento sul fatto che qualcun altro le dica f(x), non ha alcun modo di verificare il valore dichiarato (a parte il calcolo di f(x) stesso) e la pedina rischia di essere penalizzata se è sbagliata. C'è anche un incentivo per una delle parti a tentare di fuorviare il controllore riguardo f(x) - cioè l'assertore, che trae profitto dall'errore del controllore e può utilizzare questi profitti per corrompere gli "amici" del controllore affinché forniscano al controllore informazioni errate .

Ottimizzazione e conclusione

Esistono diversi trucchi per rendere questo protocollo più efficace. Ad esempio, potremmo raggruppare un'asserzione con la sfida successiva in una transazione on-chain in modo che la sfida non aumenti il ​​numero di transazioni. Se P è piccolo (ad esempio, 0,3% nel nostro esempio) e il numero di pedine non è molto grande, allora le pedine raramente avranno bisogno di scrivere transazioni sulla catena, quindi l'impatto complessivo del protocollo sul numero di transazioni sulla catena sarà essere il più piccolo.

Con un'implementazione intelligente, il costo di questo protocollo dovrebbe essere molto basso rispetto al costo iniziale dell'emissione di asserzioni sulla catena. Nel nostro caso, l’aggiunta di sfide di attenzione al protocollo di sfida di asserzione esistente aumenta il costo totale di meno dell’1%.

E i vantaggi sono sostanziali: otteniamo un protocollo di controllo compatibile con gli incentivi e immune al dilemma del validatore. Finché almeno un controllore è razionale, le affermazioni dell'assertore saranno sempre controllate.

Per altre informazioni sul progetto, fare riferimento a: Catena pubblica di giochi Xai: database Binance Square

#ARB #Layer3 #game #XAI #web3