Internet computer wiki

Network Nervous System – NNS

Network Nervous System – NNS

L’NNS è l’organizzazione autonoma decentralizzata (DAO) che governa Internet Computer (IC).

È un sistema completamente on-chain e decentralizzato ed è, ad esempio, responsabile degli aggiornamenti a livello di protocollo per migliorare continuamente Internet Computer.
Questo avviene attraverso un’implementazione di “democrazia liquida” in cui gli holder di ICP neuron votano le proposte che modellano lo sviluppo di Internet Computer.

Una volta accettata tale proposta, viene eseguita autonomamente.

Mentre altre blockchain richiedono settimane o mesi per l’aggiornamento (a volte chiamate hard fork) e in genere necessitano un notevole lavoro manuale e coordinamento per farlo, IC si aggiorna su base settimanale (https://dashboard.internetcomputer.org/releases).
La sua capacità di aggiornare e iterare è comparativamente un “superpotere”.

NNS lavora in maniera da consentire agli utenti di mettere in stake i propri token di governance ICP per creare neurons di voto. Chiunque può creare un neuron, che uniti esercitano la volontà della comunità, mediata attraverso algoritmi. I neuron sono come account che devono dare un periodo di preavviso per effettuare prelievi, la durata del periodo di preavviso è una configurazione nota come “dissolve delay”. Il potere di voto dei neurons, e di conseguenza sulle ricompense di voto, è proporzionale alla quantità di ICP in stake, alla lunghezza del “dissolve
delay” configurato e alla loro “age”. I neurons possono votare manualmente, o automaticamente seguendo altri neurons in una forma di “liquid democracy”.

I detentori di neurons sono quindi incentivati a votare per approvare o rifiutare proposte, oppure a configurare i “neuron follows” che consentono di votare in maniera automatica scegliendo il neuron che con più probabilità porterebbe valore alla rete di Internet Computer nel lungo termine.
Questa è la prima volta nella storia in cui un’infrastruttura decentralizzata si auto-gestisce con lo scopo di competere contro infrastrutture proprietarie centralizzate e gestite da organizzazioni commerciali con a capo imprenditori e consigli di amministrazione.

Panoramica

Lo scopo del NNS è quello di consentire alla rete Internet Computer di essere governata in modo aperto, decentralizzato e sicuro. Ha il controllo completo su tutti gli aspetti della rete. Ad esempio, può aggiornare il protocollo e il software utilizzati dalle macchine/nodi che ospitano la rete; può creare nuove “subnet blockchains” per aumentare la capacità della rete; può dividere le subnet per bilanciare il carico; può configurare parametri economici che controllano quanto devono pagare gli utenti per la capacità di calcolo; e, in casi estremi, può congelare codice malevolo di canister smart contract al fine di proteggere la rete; e molto altro. NNS funziona accettando proposte, decidendo se approvare o rifiutarle in base all’attività di voto dei “neurons” che i partecipanti alla rete hanno creato.

I neurons sono anche utilizzati dai partecipanti per presentare nuove proposte. Dopo la presentazione, le proposte vengono approvate o respinte, il che può accadere quasi immediatamente o dopo un certo periodo, a seconda di come vota la totalità dei neurons. Ogni proposta è un’istanza di uno specifico “proposal type”, che determina quali informazioni contiene. Per ogni tipo di proposta NNS mantiene una funzione di sistema corrispondente che viene invocata ogni qualvolta sia adottata una proposta di quel tipo. Quando una proposta viene adottata dall’NNS, richiama la funzione di sistema corrispondente attingendo informazioni dal contenuto della proposta per riempire i parametri. Ogni tipo di proposta appartiene a uno specifico “proposal topic”, ad esempio “#NodeAdmin” o “#NetworkEconomics”, che determina i dettagli su come questa verrà elaborata. Per impedire agli utenti (neurons) di spammare l’NNS attraverso proposte, viene imposta una fee al neuron che ha presentato una proposta qualora questa venga respinta.

L’NNS decide se approvare o rifiutare le proposte osservando i voti dei neurons. Chiunque può creare un neuron bloccando i propri ICP sul registro (ledger) interno del NNS. Quando un utente crea un neuron, il quantitativo bloccato di ICP può essere sbloccato solo “dissolvendo” il neuron. Gli utenti sono incentivati a creare neurons perché guadagnano ricompense quando votano le proposte, queste ricompense vengono erogate tramite il minting di nuovi ICP da parte del NNS. La quantità di ricompense ICP distribuite a un neuron deriva da fattori come la dimensione del quantitativo bloccato, il periodo minimo di blocco rimanente (il “dissolve delay”), l’ “age” del neuron, la proporzione di possibili voti a cui ha partecipato e la somma dell’attività di voto tra tutti i neurons, poiché le ricompense totali complessive erogate sono limitate e devono essere divise tra i votanti.

Ogni neuron ha un “dissolve delay” impostato, questo determina quanto tempo impiegherà dissolversi se viene posto in “dissolve mode”. Una volta che un neuron è impostato in “dissolve mode”, il suo dissolve delay decade nel corso del tempo, un po’ come un timer, fino a raggiungere lo zero; dopo di che il suo proprietario può eseguire un’azione di unlock finale per sbloccare il quantitativo di ICP. 

Il dissolve delay crea un incentivo economico per i proprietari di neurons a votare al fine di massimizzare il valore futuro degli ICP bloccati.
ICP è un proxy per il successo della rete a lungo termine, senza volatilità a breve termine, questo crea un incentivo economico a votare nel migliore interesse della rete. 

I proprietari di neurons possono impostare liberamente dissolve delay più elevati, fino a un delay massimo di otto anni, ma non possono diminuire il dissolve delay se non con il naturale passare del tempo. L’NNS paga rewards di voto più alti tanto più è il tempo di dissolve delay impostato, incoraggiando gli utenti a entrare in un gioco in cui viene creato un incentivo economico per il voto eseguito secondo una visione a lungo termine.

I proprietari di neurons possono avere difficoltà a votare manualmente ogni proposta presentata al NNS. In primo luogo perché grandi volumi di proposte possono essere presentati al NNS, spesso in momenti scomodi, e i proprietari potrebbero non essere disponibili o non avere il tempo necessario per valutare ciascuna di esse.
In secondo luogo, i proprietari di neurons potrebbero non avere le competenze necessarie per valutare le proposte stesse. NNS utilizza una forma di democrazia liquida per affrontare queste sfide.

Per qualsiasi tipologia di proposta, un neuron può essere configurato per votare automaticamente seguendo i voti di un gruppo di neurons, votando per adottare proposte ogni volta che più della metà dei followees vota per adottare e votando per respingere ogni volta che almeno la metà dei followees vota per rifiutare. Inoltre può anche essere definita una regola per far votare automaticamente un neuron su proposte con argomenti per i quali non è stata definita alcuna regola di follow. 

Si presume che i proprietari di neurons gestiscono nel migliore interesse della rete il modo in cui seguire gli altri neurons,  oltre che nel loro interesse economico tenendo conto dei loro lock.

Si presume che gran parte dell’offerta complessiva di ICP sarà bloccata per guadagnare ricompense. Ciò protegge la governance della rete di Internet Computer, rendendo sia difficile che esorbitantemente costoso per un utente malintenzionato acquisire una quota sufficientemente grande per ottenere un’influenza significativa. 

Poiché i proprietari di neurons potrebbero voler massimizzare le loro ricompense votando su tutte le proposte, la maggior parte dei neurons sarà gestita attivamente o configurata per seguire altri neurons in modo che possano votare automaticamente. In pratica, una volta che i neurons fidati hanno votato le proposte, anche la maggioranza degli altri neurons voterà come risultato di relazioni a cascata. Ciò significa che l’NNS di solito può determinare rapidamente se la maggioranza del potere di voto complessivo, rappresentato da tutti i neurons, desidera approvare o rifiutare una proposta. 
Tuttavia, l’NNS non può dipendere dall’ottenimento di tale maggioranza poiché idealmente i proprietari di neurons potrebbero non definire le regole di follow-up, o potrebbero semplicemente scegliere di non votare.

Proposals

Format

Ogni proposta presentata al NNS ha i seguenti campi:
  • Summary: Testo che fornisce una breve descrizione della proposta, composta utilizzando un massimo di 280 bytes.
  • URL: l’indirizzo Web del contenuto aggiuntivo necessario per valutare la proposta, specificato tramite HTTPS. Ad esempio, l’indirizzo potrebbe descrivere il contenuto che supporta l’assegnazione di un DCID (data center ID) a un nuovo data center.
  • Proposer: l’ID del neuron che ha presentato la proposta. Quando viene presentata una proposta, una fee viene addebitata preventivamente, nel caso in cui questa venga respinta. Quindi il saldo deve essere sufficiente per pagare l’addebito. Inoltre è richiesto che un neuron abbia un dissolve delay ≥ 6 mesi per votare, questo vale anche per la presentazione di nuove proposte.
  • Proposal Type: il tipo di proposta. Questo indica a quale argomento appartiene la proposta (es. #NodeAdmin), la funzione di sistema che elaborerà la proposta nel caso in cui venga adottata e il tipo e la struttura dei parametri che verranno passati a quella funzione.
  • Parameters: i parametri che verranno passati alla funzione di sistema, verranno richiamati se la proposta sarà adottata, come determinato dal Proposl Type. Quando viene presentata una proposta, l’ NNS ne controlla i parametri ed assegna un’identità univoca.

Topics

Il topic di una proposta, dedotto dal suo tipo, determina come verrà elaborato. Ad esempio, l’NNS può richiedere alla community di aumentare il grado di accordo  o di cercare di elaborare le proposte più velocemente per alcuni topic.

I Topic iniziali includono:

 

  • #NeuronManagement: un topic speciale per mezzo del quale un neuron può essere gestito dai followees di questo topic (in questo caso, non esiste un fallback to default). I voti su questo topic non sono inclusi nella cronologia delle votazioni del neuron. Solo chi segue il neuron relativo al topic a cui si riferiscono le proposte sono autorizzati a votare. Poiché l’insieme dei votanti idonei delle proposte su questo topic è limitato, queste hanno un periodo di votazione più breve del normale.
  • ExchangeRate: Tutte le proposte forniscono informazioni in “tempo reale” sul valore di mercato di ICP, misurato da un Diritto Speciale di Prelievo (SDR – special drawing right) del Fondo Monetario Internazionale (IMF – international monetary found), che consente al NNS di convertire ICP in Cycles ad un tasso che costante. Poiché le proposte su questo topic sono molto frequenti, hanno un periodo di votazione più breve e i voti non sono inclusi nella cronologia delle votazioni del neuron.
  • #NetworkEconomics: proposte che amministrano l’economia della rete, ad esempio determinando quali ricompense dovrebbero essere pagate ai node operator.
  • #Governance: tutte le proposte che amministrano la governance, ad esempio i movimenti e la configurazione di determinati parametri.
  • #NodeAdmin: tutte le proposte che amministrano in qualche modo le node machines, incluso l’aggiornamento o la configurazione del sistema operativo, l’aggiornamento o la configurazione del framework della macchina virtuale e l’aggiornamento o la configurazione del software di replica del nodo.
  • #ParticipantManagement: tutte le proposte che amministrano i partecipanti alla rete, ad esempio la concessione e la revoca di DCID (Data center identities) o NPID (Node provider identities).
  • #SubnetManagement: tutte le proposte che amministrano le subnet di rete, ad esempio la creazione di nuove subnet, l’aggiunta e la rimozione di nodi e subnet, e la suddivisione delle subnet.
  • #NetworkCanisterManagement: installazione e aggiornamento dei “system” canisters che appartengono alla rete, ad esempio l’aggiornamento del NNS.
  • #KYC: proposte che aggiornano le informazioni KYC per scopi normativi, ad esempio durante la distribuzione iniziale di Genesis di ICP sotto forma di neuron.
  • #NodeProviderRewards: Topic di proposte per le ricompense dei node provider.

Types

I tipi di proposta iniziali includono:

  • ManageNeuron (#NeuronManagement, Voto limitato) Questo tipo di proposta chiama una funzione principale su uno specifico neuron target. Solo i followee del neuron target possono votare su queste proposte, il che fornisce effettivamente ai followee il controllo su quel neuron. Questo può essere una soluzione conveniente e altamente sicura per un team che deve gestire un neuron importante. Ad esempio, un neuron potrebbe avere un grande bilancio, o appartenere a un’organizzazione importante, ed essere pubblicizzato in modo che molti altri neurons possano seguire il suo voto. In entrambi i casi, la gestione sicura della chiave privata dell’entità potrebbe essere problematica. (O viene conservata una singola copia, soluzione molto insicura in quanto prevede che una singola parte abbia il controllo, oppure un gruppo di individui deve dividersi la responsabilità, ad esempio utilizzando la threshold criptography, che è complessa e richiede tempo). Per affrontare questo problema utilizzando questo tipo di proposta, il neuron può essere configurato per seguire i neurons controllati dai singoli membri di un team. In questo modo possono presentare proposte per far sì che il neuron esegua azioni, che vengono adottate se e solo se la maggioranza di loro vota per l’adozione. (L’invio di una proposta di questo tipo prevede una piccola commissione, per prevenire attacchi denial-of-service.) Quasi tutti i comandi sul neuron target possono essere eseguiti, compresi i comandi che cambiano le regole seguenti, permettendo ai membri del team di essere dinamici. Solo la fase finale di dissolving del neuron una volta che il suo dissolve delay raggiunge lo zero non può essere eseguita utilizzando questo tipo di proposta, poiché ciò consentirebbe di trasferire il controllo/proprietà dei bilanci bloccati. (L’unica eccezione a questa regola si applica alle organizzazioni senza scopo di lucro, che possono essere autorizzate a sciogliere i loro neurons senza utilizzare la chiave privata iniziale.) Per evitare che un neuron per sbaglio cada sotto il controllo maligno della chiave privata del principal, la chiave privata può essere distrutta in modo che il neuron possa essere controllato solo dai suoi seguaci, anche se ciò rende impossibile sbloccare successivamente il bilancio.

 

  • ManageNetworkEconomics (#NetworkEconomics) Questo è un singolo tipo di proposta che può aggiornare uno o più parametri economici:
    • Reject cost: verrà addebitato l’importo di ICP addebitato al proponente di una proposta respinta, per evitare lo spamming di proposte frivole.
    • Minimum Neuron Stake: imposta il numero minimo di ICP richiesto per la creazione di un neuron. Lo stesso limite deve essere rispettato anche quando si aumenta il dissolve delay o si modifica lo stato del neuron da dissolving a aging.
    • Neuron Management Fee: il costo in ICP per proposta di gestione dei neurons. Qui l’NNS sta lavorando per conto di un neuron specifico e verrà applicata una piccola fee per prevenire l’uso eccessivo di questa funzione (ad esempio, spam).
    • Minimum ICP/SDR rate: per evitare errori, esiste un limite inferiore per il tasso ICP/SDR, gestito da proposte economiche di rete.
    • Dissolve delay of spawned neurons: il dissolve delay di un neuron generato dalla maturity di un neuron esistente.
    • Maximum node provider rewards: le ricompense massime da distribuire ai provider di nodi in un singolo evento di distribuzione (proposta).
    • Transaction fee: la commissione di transazione che deve essere pagata per ogni transazione sulla chain.
    • Maximum number of proposals to keep per topic: il numero massimo di proposte da mantenere per argomento. Quando il numero totale di proposte per un determinato argomento è maggiore di questo numero, le proposte meno recenti che hanno raggiunto uno stato “finale” possono essere eliminate per risparmiare spazio.

 

  • Motion (#Governance) Una mozione è un testo che può essere adottato o respinto. Nessun codice viene eseguito quando viene adottata una mozione. Una mozione adottata dovrebbe guidare la strategia dell’ecosistema Internet Computer.
  • ApproveGenesisKYC (#KYC) Quando vengono creati nuovi neurons alla Genesi, hanno GenesisKYC=false. Questo limita le azioni che possono eseguire. In particolare, non possono generare nuovi neurons e, una volta che i loro dissolve delay sono pari a zero, non possono essere erogati e i loro saldi sbloccati su nuovi account. Questa proposta imposta GenesisKYC=true per gruppi di principals.
    (Nota: l’evento Genesis eroga tutti gli ICP sotto forma di neurons, i cui principals devono essere KYCed. Di conseguenza, tutti i neurons creati dopo Genesis hanno GenesisKYC=true impostato automaticamente poiché devono essere stati derivati da bilanci che sono già stati KYCed.)
  • AddOrRemoveNodeProvider (#Participant Management) Assegna (o revoca) un’identità a un provider di nodi, associando le informazioni chiave relative alla persona giuridica associata che dovrebbero fornire un modo per identificarla univocamente.
  • RewardNodeProvider (#NodeProviderRewards) Propone di premiare un provider di nodi Gen-1 con una quantità di ICP come compensazione per la fornitura di nodi Gen-1 all’IC.
  • SetDefaultFollowees (#Governance) Specifica l’elenco dei followee che un neuron appena creato dovrebbe avere.

Di seguito è riportato un elenco di tipi di proposte che chiamano altri canister NNS:

  • CreateSubnet (#SubnetManagement) Combina un set di nodi specificato, tipicamente tratti da data center e operatori in modo tale da garantirne l’indipendenza, in una nuova subnet decentralizzata. L’esecuzione di questo aggiornamento esterno avvia innanzitutto una nuova istanza del protocollo di generazione di chiavi distribuite. La trascrizione di tale protocollo viene scritta in un nuovo subnet record nel ledger, insieme alle informazioni di configurazione iniziali per la subnet, da cui i nodi che compongono la subnet la prelevano.
  • AddNodeToSubnet (#SubnetManagement) Aggiunge un nuovo nodo a una subnet. Il nodo non può essere attualmente assegnato a una subnet in quanto l’esecuzione di questa proposta modifica un subnet record esistente. Dal punto di vista del NNS, questo aggiornamento è un semplice aggiornamento del subnet record nel ledger.
  • InstallNetworkCanister (#NetworkCanisterManagement) Proposta per aggiungere un nuovo canister da installare ed eseguire nella subnet NNS. Il root canister, che controlla tutti i canister del NNS tranne se stesso, gestisce questo tipo di proposta. La chiamata prevede che il modulo Wasm sia installato.
  • UpgradeNetworkCanister (#NetworkCanisterManagement) Proposta di aggiornamento di un canister esistente nella subnet NNS. Questo tipo di proposta viene eseguito dal canister Root. Oltre ad aggiornare il modulo Wasm del canister di destinazione, la proposta può anche impostare le informazioni di autorizzazione e le allocazioni.
  • BlessReplicaVersion (#NodeAdmin) Una proposta per dichiarare una nuova versione da cui le repliche potranno essere aggiornate. La proposta registra una versione della replica (identificata dall’hash dell’immagine di installazione) nel ledger. Oltre a creare un record per tale versione, la proposta aggiunge tale versione all’elenco delle “blessed versions” che possono essere installate in una subnet . Di per sé, questa proposta non ha alcun effetto sull’aggiornamento. (In futuro, ci sarà solo una versione “blessed” del software di replica in qualsiasi momento).
  • RecoverSubnet (#SubnetManagement) Aggiorna il CUP di recupero di una subnet (usato per recuperare le subnets in stallo). I nodi che trovano un CUP di recupero per la loro subnet lo caricano dal ledger e riavviano la replica da quel CUP.
  • UpdateSubnetConfig (#SubnetManagement) Aggiorna la configurazione di una subnet. Questa proposta aggiorna il record della subnet nel ledger e le modifiche vengono recepite dai nodi della subnet quando fanno riferimento alla rispettiva versione del ledger. La configurazione della subnet comprende parametri di protocollo che devono essere coerenti in tutta la subnet (ad esempio, le dimensioni dei messaggi).
  • AssignNPID (#ParticipantManagement) Assegna un’identità ad un node operator associandovi informazioni chiave relative alla sua proprietà, alla giurisdizione in cui si trova e ad altre informazioni. Il node operator viene memorizzato come un record nel ledger.
    Contiene la quota di nodi rimanente per quel node operator, cioè il numero di nodi che l’operatore può ancora aggiungere all’ IC. Quando un nuovo nodo è aggiunto dal node operator, la quota rimanente diminuisce.
  • RootUpgrade (#NetworkCanisterManagement) Proposta di aggiornamento del root canister nella subnet NNS. La proposta viene elaborata dal Lifeline canister, che controlla il root canister. La proposta aggiorna il modulo Wasm e le impostazioni di autorizzazione.
  • SetICPSDR (#ExchangeRate) Istruisce l’NNS sul valore di mercato di 1 ICP misurato da un IMF SDR. Questa impostazione influisce sul prezzo dei cicli (poiché il valore dei cicli è costante rispetto ai IMF SDRs).
  • UpgradeSubnetToReplicaVersion (#SubnetManagement) Aggiorna la versione della replica in esecuzione su una determinata subnet . La proposta modifica la versione della replica utilizzata sulla subnet specificata. La versione deve essere contenuta nell’elenco delle versioni di replica “blessed”. L’aggiornamento viene eseguito quando la subnet crea il prossimo CUP regolare.
  • ClearProvisionalWhitelist (#NetworkEconomics) Cancella la whitelist provvisoria, che consente ai committenti elencati di creare canisters con cicli. Il meccanismo è necessario solo per il bootstrap e i test e deve essere disattivato successivamente.
  • RemoveNodeFromSubnet (#SubnetManagement) Rimuove un nodo da una subnet. Diventa quindi disponibile per la riassegnazione. L’esecuzione di questa proposta modifica un record di subnet esistente per rimuovere un nodo. Dal punto di vista dell’NNS, questo aggiornamento è un semplice aggiornamento del record di subnet nel ledger.
  • SetAuthorizedSubnetworks (#Governance) Informa il canister di minting dei cicli che un determinato principal è autorizzato a utilizzare determinate subnets (da un elenco). Può anche essere usato per impostare l’elenco “predefinito” di subnets che i principal senza autorizzazione speciale possono usare.
  • SetFirewallConfig (#SubnetManagement) Modifica la configurazione del firewall nel ledger (configura con quali nodi di confine comunicheranno le repliche della blockchain della subnet).
  • UpdateNodeOperatorConfig (#NodeAdmin) Modifica l’autorizzazione di un node operator nel ledger.
  • StopOrStartNNSCanister (#NetworkCanisterManagement) Arresta o avvia un canister NNS.

Token ICP

Gli ICP sono token nativi che svolgono tre ruoli chiave nella rete:

1. Facilitare la governance della rete: I token ICP possono essere bloccati per creare neurons che partecipano alla governance della rete attraverso il voto, grazie al quale possono guadagnare ricompense economiche.

2. Produzione di Cycles per la computazione: ICP fornisce una fonte di valore che può essere convertita in “cicli” che alimentano il calcolo, come il carburante che viene bruciato quando viene utilizzato. L’NNS converte gli ICP in cicli a un tasso variabile, scelto per garantire che gli utenti della rete possano sempre creare nuovi cicli a un costo approssimativamente costante in termini reali, in modo che il costo di acquisizione del carburante sia prevedibile.

3. Ricompensa dei partecipanti: La rete minta nuovi ICP per ricompensare e incentivare coloro che svolgono ruoli importanti che consentono alla rete di funzionare, tra cui:

  • l’erogazione di “ricompense di voto” a coloro che partecipano alla governance
  • l’erogazione di “ricompense per i node provider” a coloro che gestiscono le macchine nodo che ospitano il network.

Ledger

Il ledger è il registro dell’ICP, è ospitato all’interno del NNS e registra tutti i saldi di ICP come un foglio di calcolo. Ogni riga è chiamata “account”, con due campi (cioè due “colonne”):

  • Account identifier(bytes): Un valore univoco che deriva dall’identità del “principal” che “controlla” l’account. Attualmente, il proprietario deve essere: (i) in possesso di una coppia di chiavi pubbliche, oppure (ii) uno smart contract canister che fa parte dell’NNS. Gli identificatori degli account sono ottenuti mediante hashing della concatenazione di un separatore di dominio, del principal ID e del sub account (o di zeri se non viene indicato alcun sub account).
  • Balance (numero intero positivo, che rappresenta un centesimo di milionesimo di ICP) La quantità di ICP assegnata al proprietario dell’account.

Quando il principal è una chiave pubblica o un Canister, può applicare le seguenti operazioni su un account:

  • Send: Invia una parte del saldo ICP a un altro account. Se tutto l’ICP viene inviato a un altro account, l’account mittente cessa di esistere (cioè viene cancellato dal ledger).
  • Notify: Quando la destinazione dei fondi inviati è l’account di un canister NNS (ad esempio, un account del canister di governance), il mittente può chiedere al ledger di notificare al canister destinatario il trasferimento in arrivo. Il canister destinatario può quindi agire in base a questa notifica. Due esempi di utilizzo di questa capacità sono la creazione di un neuron e l’aggiornamento dello staking di un neuron. Queste operazioni sono descritte in dettaglio qui di seguito.

Operazioni che richiedono l’interazione tra il ledger e il sistema di governance (Neurons):

  • Create neuron: Quando il principal è un detentore di una chiave pubblica, può bloccare una parte del proprio saldo all’interno di un nuovo neuron. Tecnicamente, la creazione del neuron avviene in due fasi. Prima si trasferiscono gli ICP da bloccare su un account del canister di governance (che corrisponde a un nuovo neuron – i dettagli dell’associazione sono omessi in questa sede). Poi si comunica al canister di governance il trasferimento in arrivo, che aggiorna la contabilità interna del neuron. Se l’intero saldo è bloccato all’interno di un nuovo neuron, l’account cessa di esistere (cioè viene cancellato dal ledger). Per spostare questi ICP su un altro account, ad esempio sull’account originale, dove possono essere nuovamente controllati come un saldo normale, il neuron associato deve essere completamente dissolto ed erogato (distrutto). Il nuovo neuron creato è controllato dalla chiave privata del titolare che lo ha creato.
  • Refresh stake: Lo staking di un neuron può essere aumentato mediante un trasferimento al suo indirizzo/account nel ledger e notificando il trasferimento in arrivo al canister di governance.
    L’aggiornamento dello stake modificherà la maturity e l’age del neuron in modo proporzionale.
    Ad esempio, se lo stake è raddoppiato, la maturity e l’age saranno dimezzate, quindi la generazione produrrà lo stesso importo e l’age bonus sarà lo stesso di prima (in termini assoluti).

Neurons

Un neuron blocca un valore di ICP e consente al suo proprietario di partecipare alla governance della rete, attraverso la quale può guadagnare ricompense.

Attributi

I neurons hanno i seguenti attributi:

  • Identity (uint64): L’identità generale del neuron. Quando un neuron è configurato per seguire un altro neuron, questo è il valore utilizzato. Si tratta di un valore casuale a 64 bit selezionato alla creazione del neuron.
  • Account (bytes, privato): L’account del ledger in cui risiede il saldo ICP
  • Controller (principal ID, privato) Il principal che controlla effettivamente il neuron. Il principal deve identificare una coppia di chiavi pubbliche, che funge da “chiave principale”, in modo che la chiave segreta corrispondente sia custodita in estrema sicurezza. Il principal potrebbe controllare diversi neuron.
  • Hot Keys (elenco di ID principale, privato): Chiavi che possono essere utilizzate per eseguire azioni con privilegi limitati, come il voto, senza esporre la chiave segreta corrispondente al principal (ad esempio, potrebbe essere una chiave WebAuthn).
  • CreatedAt (timestamp): Quando il neuron è stato creato.
  • AgingSince (timestamp): Il timestamp corrispondente al momento in cui questo neuron ha iniziato a maturare. Si tratta del momento della creazione o dell’ultimo momento in cui il neuron ha smesso di dissolversi. Questo valore è privo di significato quando il neuron si sta dissolvendo, poiché un neuron che si dissolve ha sempre un age pari a zero.
  • DissolveState: In qualsiasi momento, è possibile specificare al massimo uno dei due valori WhenDissolved e WhenDissolved (timestamp)

Quando il timer di dissolvenza è in funzione, memorizza il timestamp in secondi dall’epoch Unix, momento in cui il neuron viene dissolto. In qualsiasi momento, mentre il neuron si sta dissolvendo, il proprietario di tale neuron può mettere in pausa la dissolvenza, in tal caso DissolveDelay verrà assegnato a: WhenDissolved meno il timestamp dell’azione.

 

  • DissolveDelay (durata): Quando il timer di dissolvenza viene fermato, memorizza il tempo con cui il timer di dissolvenza verrà avviato. Può essere al massimo di otto anni. In qualsiasi momento, mentre si trova in questo stato, il proprietario del neuron può (ri)iniziare a dissolvere, in tal caso WhenDissolved verrà assegnato al timestamp dell’azione più DissolveDelay.

 

  • Maturiry (numero positivo – percentuale): La maturity di un neuron, che determina la sua capacità di generare (spawn) un nuovo neuron e il corrispondente saldo bloccato di nuovi ICP emessi. Quando vengono creati nuovi neurons, la loro maturity è pari a zero. Quando i neurons votano, nel corso del tempo l’NNS aumenta la loro maturity per premiarli.
  • Follow Reletionships (mappatura da topic a list dei followees, privato): Un neuron può essere configurato per votare automaticamente seguendo altri neurons in base ad ogni topic. Per qualsiasi topic valido, è possibile specificare un elenco di followees e il neuron seguirà il voto della maggioranza dei followees in merito ad  una proposta appartenente a quel topic. Se viene specificato un argomento nullo, questo agisce come una sorta di “catch-all” che consente al neuron di seguire il voto dei followees quando non è stata specificata una regola.
  • Recent votes (pubblico): Viene mantenuto un record dei voti recenti. Questo può fornire una guida per coloro che desiderano valutare se seguire un neuron o come stanno votando i suoi followees.
  • NotForProfit (booleano) Se questo neuron è “non a scopo di lucro”, il che lo rende dissolvibile tramite votazione.

È possibile calcolare i seguenti attributi:

  • Age (secondi) (Calcolata da AgingSince e dall’ora corrente): Il periodo di tempo trascorso da quando il neuron è stato creato o ha smesso di dissolversi. Concettualmente, ogni volta che un neuron inizia a dissolversi, la sua age viene azzerata e rimane zero durante la  dissolvenza. Se un neuron in dissolvenza è disattivato, l’ora corrente diventa la data di creazione effettiva del neuron ai fini del calcolo dell’age.
  • State (LOCKED o DISSOLVING o DISSOLVED) (calcolato da DissolveState e dall’ora corrente)
    • LOCKED: in questo stato, il neuron è bloccato con uno specifico DissolveDelay. L’age matura con il passare del tempo e può votare se DissolveDelay è di almeno sei mesi. Il metodo start_dissolve può essere chiamato per trasferire il neuron allo stato DISSOLVE. Il metodo increase_dissolve_delay può essere usato per aumentare il ritardo di dissoluzione senza influenzare lo stato o l’age del neuron.
    • DISSOLVING: in questo stato, il dissolve delay effettivo del neuron diminuisce con il passare del tempo. Durante la dissoluzione, l’age del neuron è considerata pari a zero. Alla fine raggiungerà lo stato DISSOLVED. Il metodo stop_dissolve può essere richiamato per trasferire il neuron allo stato LOCKED e il neuron ricomincerà a invecchiare. Il metodo increase_dissolve_delay può essere usato per aumentare il dissolve delay, ma questo non fermerà il timer né influenzerà l’age del neuron.
    • DISSOLVED: Nello stato dissolved, la stake dei neuron può essere erogato con il metodo disburse. Non può votare perché il suo dissolve delay è considerato pari a zero. Se il metodo increase_dissolve_delay viene chiamato in questo stato, il neuron viene bloccato con il dissolve delay specificato e ricomincia a invecchiare. Gli holders dei neurons sono incentivati a non mantenerli a lungo in stato Dissolved: se vogliono rendere liquidi i loro token, eseguono il disburse della quota di staking, se vogliono ottenere ricompense di voto, aumentano il dissolve delay. Se questi incentivi si rivelano insufficienti, l’NNS può decidere di imporre ulteriori restrizioni ai neurons dissolti.
    • ControlByProposals (booleano) (true se il neuron ha un elenco non vuoto di followees sull’argomento #NeuronManagement): Se un neuron specifica dei followees sul topic ManageNeuron, può essere gestito da proposte di tipo ManageNeuron (#NeuronManagement), che possono essere votate solo dai followees del neuron stesso. Ciò fornisce una base per la gestione di neurons altamente sensibili dal punto di vista della sicurezza, in quanto consente di mantenerli senza hot keys o la secret key del principal, che può essere conservata in un cold storage o addirittura distrutta (a patto che il saldo di ICP associato non debba mai essere sbloccato). Ad esempio, la Fondazione DFINITY o l’Internet Computer Association potrebbero rendere pubblico l’indirizzo di speciali neurons che voteranno secondo i loro criteri, in modo che altri possano configurare i loro neurons per seguirli e sfruttare la loro esperienza in governance. Un problema di queste pratiche è che introducono il rischio che le chiavi segrete utilizzate nella gestione dei neurons pubblicizzati possano essere compromesse, consentendo agli hacker di prendere il controllo e “ingannare” un gran numero di neurons che li seguono affinché votino secondo i loro desideri. Se invece i neurons pubblicizzati hanno le proposte di amministrazione abilitate, possono essere amministrati dai neurons che seguono (i loro followees), che sono tipicamente controllati da un gran numero di membri del team che non possono essere estorti simultaneamente, senza alcun bisogno di usare chiavi segrete.

Comandi

Il principal che controlla un neuron può ordinargli di eseguire le seguenti azioni:

  • Start Dissolving: Il dissolve delay è come un timer da cucina che può essere girato solo in una parte. Può essere aumentato arbitrariamente, ma può essere ridotto solo attivando la modalità di dissoluzione che avvia il conto alla rovescia. Il neuron può essere avviare il “dissolving”. Quando il neuron si dissolve, il suo dissolve delay diminuisce con il passare del tempo, finché non si ferma o raggiunge lo zero. Un neuron non può votare (o guadagnare ricompense per il voto) quando il suo dissolve delay scende sotto i sei mesi. Una volta che il dissolve delay raggiunge lo zero, smette di diminuire e il principal che ha il controllo può ordinare al neuron di erogare.
  • Stop dissolving: Un neuron che si sta dissolvendo può essere fermato, e in tal caso il suo dissolve delay smette di diminuire con il tempo.
  • Disburse: Quando il dissolve delay del neuron è pari a 0, il suo principal può ordinargli di versare la quota del neuron. Il suo saldo ICP bloccato viene trasferito a un nuovo ledger account specificato e il neuron e il suo ledger account scompaiono.
  • Increase dissolve delay: Il dissolve delay di un neuron può essere aumentato fino a un massimo di otto anni.
  • Spawn: Quando la maturity di un neuron supera una certa soglia, è possibile ordinargli di generare un nuovo neuron. Questo crea un nuovo neuron che blocca un nuovo saldo di ICP sul ledger. Il nuovo neuron può rimanere controllato dallo stesso principal del suo genitore o essere assegnato a un nuovo principal. Quando un neuron genera un nuovo neuron, la sua maturity scende a zero.
  • Add Hot Key: Aggiunge una nuova hot key che può essere utilizzata per gestire il neuron. Si tratta di un’alternativa all’uso della cold key del principal per gestire il neuron, la cui sicurezza potrebbe essere onerosa e difficile da assicurare, soprattutto se viene usata regolarmente. Una hot key potrebbe essere una chiave WebAuthn mantenuta all’interno di un dispositivo dell’utente, come uno smartphone.
  • Remove Hot Key: Rimuove una hot key precedentemente assegnata al neuron.

Le seguenti azioni possono essere avviate utilizzando il principale o una hot key che è stata configurata:

  • Vote: Far votare il neuron per adottare o rifiutare una proposta con un ID specificato.
  • Follow: Aggiungere una regola che permette al neuron di votare automaticamente le proposte che appartengono a un argomento specifico, specificando un gruppo di neurons followee il cui voto di maggioranza viene seguito. La configurazione di tali regole di follow può essere utilizzata per:
    1. distribuire il controllo del potere di voto tra più entità
    2. far votare automaticamente un neuron quando il suo proprietario non ha il tempo di valutare le nuove proposte presentate
    3. far votare automaticamente un neuron quando il suo proprietario non ha le competenze necessarie per valutare le nuove proposte presentate
    4. per altri scopi. Una regola di follow specifica un insieme di followees. Una volta che la maggioranza dei followees vota per adottare o rifiutare una proposta appartenente al topic specificato, il neuron vota allo stesso modo. Se la maggioranza dei followees non è in grado di adottare (ad esempio, perché si dividono al 50% tra adottare e rifiutare), il neuron vota per rifiutare. Se viene specificata una regola in cui l’argomento della proposta è nullo, essa diventa una regola di follow catch-all, che verrà utilizzata per votare automaticamente le proposte appartenenti ad argomenti per i quali non è stata specificata una regola specifica. Se l’elenco dei followees è vuoto, si elimina di fatto una regola di follow.