Gov2: La prossima generazione di governance decentralizzata di Polkadot

Gov2: La prossima generazione di governance decentralizzata di Polkadot

July 20, 2022 inPolkadot,Governance by Gavin Wood

Il primo sistema di governance decentralizzato di Polkadot era molto interessante all’epoca: una struttura tricamerale (a tre camere) con un comitato tecnocratico che gestiva le tempistiche di aggiornamento, un “governo” eletto per gestire parametri, amministrazione e proposte di spesa, nonché un sistema di voto generale per premiare gli stake-holder a lungo termine incrementando la loro influenza. Era vagamente basato sulla democrazia parlamentare e ha funzionato ragionevolmente bene nei primi 2–3 anni di attività, contribuendo a garantire un buon uso dei fondi del tesoro, mantenendo un ritmo rapido con l’implementazione degli aggiornamenti e gestendo la correzioni più critiche e distribuendo soluzioni in modo tempestivo . Tuttavia, ha i suoi svantaggi.

L’esecutivo eletto (noto come Consiglio) è centralizzato e generalmente non anonimo. Ciò mette sia il protocollo in un certo grado di rischio, sia i singoli consiglieri che potrebbero trovarsi sotto pressione per agire in un modo o nell’altro. Il Comitato Tecnico, pur esercitando un potere sostanzialmente inferiore, ha un’esposizione simile e una maggiore centralizzazione. In un mondo in cui le autorità in tutte le società (sia benigne che maligne), il decentramento è sempre più necessario sia per la sicurezza che per la protezione di tutti i partecipanti.

Inoltre, esiste un solo modello di referendum “tutto o niente”: tutti i referendum portano la massima quantità di potere. In parte a causa di ciò, può essere votato un solo referendum alla volta e questi voti durano più settimane per impostazione predefinita. Questo, e il potere limitato del Consiglio, significa che nel complesso il sistema favorisce un’approfondita considerazione di pochissime proposte piuttosto che un’ampia considerazione di moltissime. Piuttosto che sfruttare il potere della folla, inavvertitamente la limita nei suoi sforzi per gestire il volume del potenziale flusso decisionale.

La natura della delega a grana grossa significa che il sistema ha un grado di esclusività integrato in se stesso. Le barriere all’ingresso nel quadro politico decisionale sono elevate, riducendo l’inclusività e la diversità, danneggiando l’affluenza alle urne e la legittimità.

E’ sempre stato chiaro che la prima versione della governance di Polkadot era proprio questo: qualcosa su cui lavorare nel tempo. Ora, sono felice di poter descrivere in dettaglio la nostra proposta per la prossima generazione di governance all’interno dell’ecosistema Polkadot

Introduzione Gov2

Il sistema di governance di nuova generazione di Polkadot, noto durante lo sviluppo come Gov2, mira a risolvere i problemi del sistema attuale. Primo, cosa non cambia: non infrange il principio di governance originale di Polkadot, che sostiene che il 50% dello staking totale nel sistema dovrebbe, se secondo loro le decisioni e opinioni hanno sufficiente forza , essere in grado alla fine di comandare il futuro del sistema. Allo stesso modo, non si stacca dal Conviction Voting introdotto per la prima volta in Polkadot, dando maggiore peso a coloro che sono disposti a mettere in staking i propri token nel sistema più a lungo. Inoltre, c’è ancora bisogno di un collettivo tecnocratico, anche se è leggermente diverso per importanza, dimensioni, composizione e meccanismi di appartenenza rispetto all’attuale Comitato Tecnico.

Ciò che differisce maggiormente è il modo in cui gestisce i mezzi pratici del processo decisionale quotidiano, rendendo le ripercussioni dei referendum più mirate e agili al fine di aumentare drasticamente il numero di decisioni collettive che il sistema è in grado di prendere. Diamo un’occhiata un po’ più a fondo a come funziona.

Abbassare le barriere

Gov2 è in realtà molto più semplice in molti modi rispetto all’attuale governance. Non ci sono ulteriori organi che agiscano da “cittadini di prim’ordine” nella governance come il Consiglio e il Comitato Tecnico. Non è previsto un calendario alternato delle proposte. Non è presente alcuna coda di proposte pubbliche. Abbiamo invece un solo meccanismo decisionale di prim’ordine: il referendum. La differenza principale in Gov2 è che possono esserci molti referendum, forse anche migliaia, che accadono tutti contemporaneamente.

In Gov2, chiunque può avviare un referendum in qualsiasi momento e può farlo tutte le volte che lo desidera. Chiunque può votare anche su questi referendum. Non ci sono limiti espliciti al numero di referendum su cui è possibile votare in qualsiasi momento.

Ma questo potrebbe portare a più cose su cui votare che una persona normale con un ragionevole lasso di tempo potrebbe valutare. Ciò potrebbe ridurre sia l’inclusività che la sicurezza. Quindi, per rendere questa potenziale pletora di cose su cui votare gestibile per semplici umani, introduciamo alcune interessanti novità nel processo referendario.

Origini e tracce

Tutti i referendum si basano su una proposta, che in realtà è solo un altro modo per dire “un’operazione” in Polkadot. Questo è lo stesso tipo di cosa che viene descritta ed eseguita quando si effettua una transazione e viene inclusa in un blocco. Ci sono tutti i tipi di operazioni che Polkadot può fare, ma un paio con cui probabilmente hai già familiarità sono il trasferimento che può spostare gli asset tra gli account e lostaking che consente di avere un conto. Ce ne sono molti altri. La cosa che rende speciale questa funzionalità di governance non sono solo queste proposte/operazioni, ma piuttosto l’Origine con cui vengono eseguite.

Puoi pensare a un’Origine come a una sorta di ricco descrittore (classificare e identificare) per livelli di privilegio. La quale viene passata quando viene eseguita un’operazione e la logica dell’operazione di solito controlla che sia come dovrebbe essere. Quando viene eseguita una transazione regolare, il parametro Origine viene impostato su una variante nota come Signed. Ciò implica che un account specifico nel sistema abbia autorizzato (generalmente attraverso la firma della transazione) l’esecuzione dell’operazione e funziona con questo privilegio, il che implica ulteriormente ad esempio che i fondi controllati da questo conto e solo da questo conto possono essere spesi.

Le cose a livello di governance funzionano per consentire l’esecuzione delle operazioni con altre Origini più privilegiate. Il più privilegiato di tutti è l’Origine Root, che è onnipotente. Questa è l’Origine da cui sono state inviate le proposte di tutti i referendum approvati nel vecchio sistema di governance. In Gov2, abbiamo molte origini diverse, tutte che godono di alcuni privilegi diversi, ma molte sono significativamente meno potenti e più di nicchia dell’ Origine Root.

In Gov2, consentiamo a chi propone di specificare con quale origine vorrebbe che la sua proposta fosse eseguita. Ogni Origine supportata è associata a una singola classe referendaria (cioè un tipo di referendum) e la maggior parte di queste classi corrisponderà esattamente a un’origine, ma potrebbero essercene alcune che comprendono più Origini. Ogni classe ha la sua Traccia, che è fondamentalmente una pipeline (canale) in cui la proposta vive e procede, ed è completamente indipendente dalle tracce delle altre classi.

Avere tracce indipendenti ci consente di adattare le dinamiche dei referendum in base al loro livello di privilegio implicito. I referendum che eseguiranno le loro proposte da origini più potenti (leggi: pericolose!) avranno tutele più rigorose, soglie più elevate e periodi di considerazione più lunghi. The Root Origine ha le soglie e le protezioni più alte. Quelle Origini che trasmettono relativamente poco potere (ad esempio il Tip Origin, in grado di spendere al massimo 10 DOT dal tesoro), hanno di conseguenza periodi di considerazione più brevi e soglie più basse per l’approvazione.

Kicking off (Inizio)

Quando un referendum viene inizialmente creato, è immediatamente votabile da chiunque nella comunità. Tuttavia, non è in uno stato in cui può terminare, o anche far contare, approvare e sommare i suoi voti. Invece, i referendum devono soddisfare una serie di criteri prima di essere spostati in uno stato noto come Deciding ( Decisione). Finché non sono in questo stato, rimangono Undecided ( Indecisi).

I criteri che devono essere soddisfatti sono tre: in primo luogo, tutti i referendum hanno un periodo di introduzione. Questo è un intervallo di tempo che deve essere trascorso dopo la proposta prima di decidere che può iniziare. Ciò prevede un periodo di preavviso iniziale in cui possono essere presentati voti per mitigare la possibilità di “sniping decisionale” in cui un aggressore che controlla una quantità sostanziale di potere di voto potrebbe cercare di far approvare una proposta subito dopo averla proposta, non consentendo alla popolazione di avere il tempo giusto complessivo per considerare e votare.

In secondo luogo, ci deve essere spazio per la decisione. Tutte le tracce proposte hanno un proprio limite al numero di referendum che possono essere decisi contemporaneamente. Più potenti sono le Origini consentite nella traccia , più basso è questo limite. Il livello Root Origin ha un limite di uno, il che implica che solo una singola proposta über-dangerous può essere decisa alla volta. Al contrario, la traccia Tipping piuttosto sottodimensionata ha limiti molto meno severi poiché qualsiasi danno causato dalla sovrappopolazione è minimo ed è molto più utile avere molti suggerimenti decisi contemporaneamente su molte chiamate a livello di root. Quando c’è spazio disponibile, allora è il referendum (altrimenti ammissibile) della classe che ha il maggior numero di voti a favore dell’approvazione che viene elevato allo stato Deciding state (deliberante).

Infine, deve essere versato un Deposito Decisionale. Creare un referendum è economico, con il deposito che deve essere pagato relativo solo allo storage on-chain necessario per rintracciarlo. Tuttavia, la decisione di un referendum comporta rischi maggiori e occupa uno spazio limitato poiché limitiamo il numero di referendum che possono essere decisi contemporaneamente su ciascuna traccia. Pertanto, è necessario versare un deposito più grande (sebbene rimborsabile) per mitigare lo spamming o il rigonfiamento del sistema.

Decisione e Conferma della Proposal

Una volta che un referendum entra nello stato di decisione, può essere approvato. Questa idoneità dura solo un tempo limitato (28 giorni su Polkadot), a quel punto se non viene approvato, viene rifiutato per impostazione predefinita. Per essere approvato, deve soddisfare due criteri (se nel caso diciamo che sta superando) e deve continuare a soddisfare questi criteri per un minimo del Periodo di Conferma. Tracce diverse hanno diverse durate del periodo di conferma, mentre quelle più potenti richiedono più tempo per la conferma. Questa è un’ulteriore difesa contro un elettore balena che tenta di fare il “cecchino” da referendum piazzando un voto sufficientemente ampio da colpire inaspettatamente i criteri di approvazione.

I due criteri di passaggio riguardano l’approvazione e il supporto. È finito il pregiudizio adattivo del quorum dei referendum passati. Ora abbiamo un sistema più flessibile in cui questi requisiti possono essere personalizzati a un livello molto più fine. L’approvazione è definita come la quota del peso del voto di approvazione (cioè dopo l’adeguamento per la condanna) rispetto al numero totale di peso del voto (sia per l’approvazione che per il rifiuto). Il supporto è il numero totale di voti in approvazione (ovvero ignorando qualsiasi adeguamento per convinzione) rispetto al totale possibile di voti che potrebbero essere effettuati nel sistema.

Ogni classe di referendum ha requisiti diversi per questi valori. Tuttavia, la cosa più interessante è che questi requisiti sono in grado di ridursi nel tempo secondo una pianificazione ben definita. Ciò significa che man mano che la votazione procede nei 28 giorni, possiamo configurare le cose in modo che sia necessaria una quantità sempre più bassa di sostegno e un’approvazione generale per la proposta per il suo passaggio. In generale, inizieranno e finiranno sempre più o meno allo stesso modo, partendo dalle soglie più alte e finendo con le più basse che sono comunque in linea con i principi generali: almeno il 50% di gradimento.

Ciò che accade nel mezzo determina quanto sia facile ottenere un’approvazione prima della scadenza di 28 giorni. Con proposte che utilizzano origini meno privilegiate (es. la classe Tip, che è in grado di comandare solo un pagamento dal tesoro fino a 10 DOT) è molto più ragionevole ridurre l’affluenza alle urne richiesta a un importo più realistico prima di quelle che utilizzano classi altamente privilegiate come Root. Allo stesso modo, le classi che hanno un maggiore significato politico tenderanno ad accettare meno controversie (e quindi richiedono una maggiore approvazione) all’inizio.

Dopo l’ Approvazione

Le proposte che non vengono approvate dopo 28 giorni sono considerate rifiutate per impostazione predefinita. A questo punto, il Decision Deposit può essere rimborsato. Se, invece, la proposta riesce a diventare e a rimanere transitante per il Periodo di Conferma durante questi 28 giorni, allora si considera approvata e si prevede di dare esecuzione all’origine con cui è stata debitamente proposta, dopo un certo Periodo di Attuazione.

Il Periodo di attuazione è indicato anche al momento della proposta referendaria ma è subordinato ad un valore minimo dipendente dalla traccia. Alcune delle tracce più potenti impongono un periodo di attuazione più ampio per garantire che la rete abbia tempo sufficiente per prepararsi a eventuali modifiche che la proposta potrebbe apportare.

Interventi

A volte diventa evidente che una proposta già votata (e forse già approvata) contiene un problema ed è opportuno annullarla. Un esempio di ciò potrebbe essere un aggiornamento della chain che in seguito è stato scoperto contenere una sorta di problema. Anche se questo non è molto comune, non è nemmeno del tutto inaudito.

In Gov2 esiste un’operazione speciale per intervenire in questo modo nota come Cancelation (Cancellazione). Questa operazione respinge immediatamente un referendum in corso indipendentemente dal suo stato. In realtà si presenta in due forme, con una che esegue solo la nuda operazione e l’altra slasha anche chi ha fatto la proposta iniziale con il deposito o i depositi pagati per il referendum.

La Cancelation è di per sé un’operazione di governance che deve essere votata dalla rete per essere eseguita. Ciò pone un possibile problema di sequenza temporale e, per essere utile, l’approvazione di una proposta di annullamento deve generalmente essere molto più veloce di qualsiasi possibile proposta di destinazione approvata. In quanto tale, l’annullamento viene fornito con la propria origine e traccia, che ha tempi di consegna bassi e curve di approvazione/supporto con riduzioni leggermente più marcate delle soglie di superamento.

Delegazione agile

In un mondo perfetto, in cui tutti abbiamo tempo e virtuosismi illimitati, tutti avrebbero ricercato, discusso, considerato e votato attentamente ogni proposta. Tuttavia, in un mondo perfetto non viviamo. Non tutti hanno il tempo o la voglia di fare un voto ben studiato su ogni questione. Da questa presa di coscienza, il Consiglio è nato nella governance originale di Polkadot: un organo delegato dagli elettori per compensare il fatto che molti di loro non volevano prendere parte alla governance quotidiana. Tuttavia, con il Consiglio andato in Gov2, abbiamo bisogno di un mezzo alternativo per garantire che gli elettori "passivi" siano ascoltati.

Il sistema di governance originale aveva una funzione chiamata Delega di voto, che abbiamo mantenuto e migliorato in Gov2. Per chi non lo conoscesse, questo è simile alla premessa della democrazia liquida: puoi delegare il tuo potere di voto a un altro elettore nel sistema. Quando il tuo delegato vota, esercita non solo il proprio potere di voto, ma anche il tuo. Funziona con il voto di convinzione, consentendoti di bloccare i tuoi token per aumentare il livello di potere di voto che il tuo delegato esercita per tuo conto. Ovviamente i token in questione non lasciano mai il tuo controllo e sei libero di cambiare delegato o riprendere il controllo diretto ogni volta che lo desideri.

Gov2, tuttavia, migliora questo aspetto con una funzionalità piuttosto speciale chiamata Multirole Delegation (Delega multiruolo). Ciò consente di specificare un delegato diverso per ogni classe di referendum nel sistema. Se non vuoi delegare per una particolare classe di referendum, puoi anche mantenere il controllo diretto per quella classe.

Ciò significa che puoi delegare a un individuo per eventuali referendum sulla distribuzione di piccoli suggerimenti dei contributori dell’ecosistema, un altro ente per referendum su spese di tesoreria più consistenti, un altro ente per aggiornamenti e parametrizzazioni di rete puramente tecniche e infine mantenere il controllo diretto per qualsiasi altra decisione!

The Fellowship “La Compagnia” e la Whitelist

Un’opinione “esperta” e ben informata gioca un ruolo importante in qualsiasi sistema di governance ben funzionante. Una tecnocrazia ha i suoi difetti pure piuttosto gravi e quindi non vorremmo che “esperti” fossero posti in una posizione di comando: introduce rischi di centralizzazione, autorità irresponsabili e getta le basi per quella che potrebbe diventare in definitiva una cabala di governo. È per questo motivo che il Comitato tecnico della governance originale di Polkadot non ha “potere decisionale” ma solo la capacità di ridurre il periodo di voto.

Detto questo, ora esprimere un’opinione ben informata e consentirle di aiutare a ottimizzare il processo decisionale, anche se non ha alcun effetto diretto sull’esito del verdetto decisionale, sembra un obiettivo ragionevole a cui tendere. Fondamentalmente, e per il bene di tutte le parti coinvolte, non deve essere possibile in alcun modo per l’organismo di esperti sovvertire la decisione complessiva delle parti interessate.

Le proposte Root-Origin sono del tipo necessario per aggiornamenti, correzioni e salvataggi, ma che hanno necessariamente il potere di rompere e corrompere arbitrariamente il sistema. In Gov2, poiché sono così pericolosi, pecchiamo dalla parte della sicurezza e abbiamo livelli estremamente alti di approvazione e supporto necessari per il passaggio anticipato e che si riducono solo lentamente ai livelli finali. Anche i periodi di introduzione e di attuazione sono ampi. In generale il processo è lento, e questo serve a dare a tutti a Polkadot la massima quantità di preavviso per garantire che le cattive proposte non vengano accettate.

Tuttavia, ci sono occasioni in cui è importante implementare una logica di correzione, aggiornamento o salvataggio in un periodo di tempo più breve. Potremmo essere in grado di presumere che ci sia un ampio consenso in questi tempi, ma le salvaguardie sul processo di voto che citiamo sopra potrebbero far si che che l’esecuzione di tale correzione può essere difficile o poco pratica a causa dei soli limiti di tempo. Oraclizzare l’idea che “gli esperti sono d’accordo: questo è sia sicuro che critico in termini di tempo” può essere uno strumento molto utile per formare un processo chiaro che è ben ponderato nel caso generale ma in grado di prendere decisioni in tempi stretti quando c’è buona ragione per credere che le circostanze lo richiedano.

Rimangono due grandi domande a cui rispondere qui: come potrebbe la chain a - un blob deterministico di logica senza alcuna capacità intrinseca di esprimere o osservare concetti come “sicuri” e “critici in termini di tempo”? E anche se potesse conoscere tali circostanze, come adattiamo la nostra logica senza compromettere la nostra trattabilità e semplicità complessive?

The Fellowship “La Compagnia”

La risposta alla prima domanda risiede in un nuovo organo di governo. Per chi ha familiarità con il vecchio sistema di governance, questo organismo può essere considerato il logico successore del Comitato Tecnico.

Si chiama Polkadot Fellowship, e nel complesso è una struttura sufficientemente ricca e sofisticata da formare l’argomento di un intero altro articolo. Inizialmente verrà eseguito sulla rete Kusama, poiché Gov2 sarà distribuito lì per scopi di test dal vivo, tuttavia verrà migrato su Polkadot con la distribuzione finale di Gov2 e una volta lì servirà entrambe le reti tramite il ponte Polkadot/Kusama.

La Fellowship è un organismo di esperti per lo più autogestito con l’obiettivo principale di rappresentare gli esseri umani che incarnano e contengono la base di conoscenze tecniche della rete e del protocollo Polkadot. A differenza dell’attuale Technical Collective, è progettato per essere molto più ampio nell’adesione (cioè per lavorare bene anche con decine di migliaia di membri) e con barriere all’ingresso molto più basse (sia in termini di flusso del processo amministrativo che di aspettative di competenza). Diventare un membro candidato della Fellowship è facile come depositare un piccolo deposito.

Al fine di contribuire a garantire un’elevata qualità delle decisioni collettive alla luce di un’adesione così ampia, i membri sono associati a un rank per designare il grado in cui il sistema si aspetta che il loro parere sia ben informato, di una solida base tecnica e in linea con gli interessi di Polkadot. I membri della Fellowship possono votare su qualsiasi proposta di Fellowship e l’opinione complessiva dei membri (ponderata in base al loro grado) costituisce l’opinione ponderata della Fellowship.

Abbastanza meravigliosamente, il mezzo tecnico con cui la Fellowship vota è in realtà esattamente lo stesso codice (Substrate pallet) del mezzo con cui le parti interessate di Polkadot votano in un referendum e ha esattamente le stesse strutture (tracce multiple, delega agile, ecc.).

Gradi e insidie

L’introduzione del concetto di grado è irta di insidie. Tuttavia, ci vengono presentate relativamente poche opzioni se il decentramento, la responsabilità e la sicurezza per tutti i soggetti coinvolti sono i nostri requisiti. Riteniamo che sia ragionevole utilizzare l’apertura, la trasparenza e la resistenza alla corruzione che il consenso decentralizzato offre per garantire che eventuali “governanti” non siano essi stessi al di sopra delle “regole” e che il grado abbia aspettative, regole e responsabilità chiare. Gli aspetti negativi del grado non sono solo negativi per la rete ma, alla luce di alcune recenti posizioni politiche dei politici in materia di tecnologia decentralizzata, sono anche negativi per i partecipanti: se il grado consente a un piccolo gruppo di partecipanti di avere un controllo effettivo sulla rete, potrebbe essere considerato in controllo effettivo di esso e quindi responsabile di ciò che è accaduto su di esso.

Pertanto, aderiamo a tre principi: in primo luogo, la Fellowship non deve mai avere un potere forte sulla rete: non può modificare parametri, condurre salvataggi o spostare risorse. Per quanto riguarda la governance della rete, l’unica cosa in suo potere è ridurre la tempistica effettiva su cui si svolge un referendum.

In secondo luogo, il sistema di classificazione e i pesi devono essere progettati in modo tale da non aspettarci che piccoli gruppi di individui siano in grado di catturare e controllare la capacità decisionale complessiva. Mentre la Fellowship pondera maggiormente quelli con rango più alto nell’opinione aggregata, il peso non dovrebbe essere così alto da rendere insormontabile un piccolo numero di opinioni di membri più alti rispetto a un’opinione coerente proveniente da membri di rango inferiore.

In terzo luogo, la Fellowship dovrebbe essere progettata per far crescere e sviluppare i suoi membri e i loro livelli aggregati di esperienza e, così facendo, garantire che la sua capacità decisionale complessiva diventi più forte nel tempo. Per un successo a lungo termine, la Fellowship deve essere un’efficace meritocrazia in cui coloro che hanno impegno, talento e competenza salgono a livelli di influenza maggiori. Per raggiungere questo obiettivo, dobbiamo dare chiarezza e trasparenza al processo di ingresso e promozione attraverso i ranghi. Nella misura più alta possibile, l’identità di un individuo non dovrebbe essere presa in considerazione, ma solo la sua capacità.

Alla luce di ciò, la Fellowship avrà uno statuto che descrive in termini specifici i requisiti e le aspettative degli individui per raggiungere e mantenere un determinato grado. I ranghi più alti sono in grado di votare e promuovere il potere di voto del rango inferiore in base a questa costituzione. La retrocessione avviene automaticamente dopo un periodo in cui un membro non è in grado di difendere la propria posizione nei confronti dei propri pari. La sospensione può avvenire solo tramite referendum generale (Polkadot), fornendo un mezzo per garantire che le controversie o l’impopolarità all’interno della Fellowship non comportino (necessariamente) l’espulsione. Inoltre, per evitare la possibilità che la Fellowship diventi una cabala, l’ingresso nei livelli più alti dei ranghi richiede anche un referendum completo (Polkadot) e non può essere conferito semplicemente dai colleghi della Fellowship.

The Whitelist

Sebbene la Fellowship possa essere in grado di rappresentare il corpo di esperti umani di Polkadot sulla chain e fornire un pezzo di logica pertinente da cui ricavare la loro opinione aggregata, potrebbe non essere chiaro come possiamo integrarlo nel sistema referendario generale. In effetti, ciò si ottiene utilizzando una combinazione di concetti che già conosciamo e una logica on-chain meravigliosamente semplice chiamata pallet Whitelist.

Il pallet Whitelist fa una cosa: consente a un’Origine di aumentare il livello di privilegio di un’altra Origine per una determinata operazione. In termini di Gov2, consente alla Fellowship di autorizzare una nuova Origine (che chiameremo Whitelisted-Root) da eseguire con privilegi a livello di root. Puoi pensarlo come una sorta di Unix sudo, tranne per il fatto che funziona solo con comandi specifici che la Fellowship ha pre-autorizzato. Ciò significa che possiamo avere una nuova traccia nella governance di Polkadot che riguarda le proposte che saranno state inserite nella whitelist dalla Fellowship. Se il referendum viene superato, verranno eseguiti all’interno del pallet Whitelist con questa origine Whitelist-Root. Il pallet Whitelist verifica due cose: che questa Origine sia davvero la Whitelisted-Root (ovvero che il referendum sia passato su questo binario) e che la proposta sia stata effettivamente inserita nella whitelist dalla Fellowship. In tal caso, va avanti ed esegue l’operazione con privilegi a livello di root.

Con questo non abbiamo bisogno di cambiare nulla su come funziona il sistema referendario (sì!). Ora abbiamo una nuova traccia (per l’Origine Whitelisted-Root) i cui parametri consentono un turnaround di votazione più breve, sicuri nella consapevolezza che attraverso un processo aperto e trasparente, un corpo di esperti globali sul protocollo Polkadot ha stabilito che questo è sia sicuro e anche urgente.

Cronologia e lavoro futuro

Gov2 verrà lanciato su Kusama a breve, dopo l’audit professionale finale del suo codice. Una volta testato su Kusama, verrà fatta una proposta per la rete Polkadot su cui votare.

Un aggiornamento a questo sistema di governance generale, nome in codice “Gov2.5”, è previsto per l’eventuale distribuzione alcuni mesi dopo. Porterà due caratteristiche chiave: in primo luogo una funzione “collect-call” per la delega del voto, che consente essenzialmente agli utenti (tramite i loro wallet) di offrire i propri fondi per la delega senza pagare alcuna commissione di transazione; invece il delegato sarebbe in grado di pagare facoltativamente le commissioni di transazione per ottenere i fondi delegati. In secondo luogo, verrà introdotta un’operazione di undelega gratuita, utilizzabile in misura limitata da tutti gli utenti deleganti. Insieme, queste funzionalità consentono ai wallet di offrire un’integrazione di governance altamente snella e a costo zero ai propri utenti, che speriamo attirerà un maggiore coinvolgimento degli utenti nel processo di governance generale.