bafyreih4z2neienowhth7izyb6n473h47ejo4vuahjxlo4dun2bz4uhbg4

ROUNDUP 2021

**Ultime notizie sulla ricerca: il caso delle aste a candela**

15 luglio 2021 July 15, 2021 in [Research](https://polkadot.network/tag/research/),[Polkadot](https://polkadot.network/tag/polkadot/),[Kusama](https://polkadot.network/tag/kusama/) by Polkadot

Di Samuel Häfner, ricercatore della Web3 foundation

Le aste Parachain sono una caratteristica centrale sia di Kusama che di Polkadot. Il loro risultato determina chi ottiene gli slot parachain e la quantità di token bloccati. Per la salute dell'ecosistema, è importante che i pochi slot siano assegnati a quei progetti che possono farne il massimo uso. È risaputo che le aste in generale sono un ottimo mezzo per raggiungere questo obiettivo, perché ad esempio, le negoziazioni bilaterali, costringono i team a essere in anticipo sulla loro valutazione per lo slot dell’ asta.[1]

Sia Kusama che Polkadot utilizzano un formato di asta a candela per allocare gli slot parachain. Ci sono molte buone risorse che spiegano come funziona in pratica questo meccanismo.[2] Tuttavia, il formato della candela è un modo piuttosto insolito per eseguire un'asta. Inoltre, le aste delle dimensioni e di questa portata non si verificano sulla blockchain tutti i giorni. Questo post esplorerà le seguenti domande fondamentali:

1. Perché le aste si svolgono meglio on-chain che off-chain?
2. Qual è il motivo particolare per utilizzare un'asta a candela?

Per rispondere a queste domande, ci addentreremo innanzitutto nella tragica vicenda di Gian Vincenzo Pinelli (1535 - 1601), studioso padovano, appassionato collezionista e mentore di Galileo Galilei. La vendita della sua eredità è stata effettuata in un'asta a candela, che si è conclusa in un disastro. In secondo luogo, sosteniamo che le ragioni di questo fallimento siano esattamente le ragioni per cui eseguire le aste sulla blockchain in generale è una buona idea. Terzo, passiamo alla domanda sul perché un'asta a candela sia la forma più adatta per le aste blockchain. Qui, esaminiamo brevemente le recenti ricerche condotte presso la Web3 Foundation.

**L'eredità di Pinelli**

Pinelli, che era di nobile discendenza napoletana, collezionava praticamente tutto di interesse accademico, dai fossili alle monete, dai minerali ai ritratti storici, dagli strumenti astronomici alle mappe.[3] La parte più famosa della sua eredità, però, era la sua immensa biblioteca. Oltre a numerosi libri, era costituito da oltre 700 manoscritti, tra cui molte rarità, come frammenti illustrati di Omero del IV secolo e un Dante con miniature del 1355.

Dopo la sua morte, la biblioteca di Pinelli fu imballata e spedita al suo erede a Napoli. La biblioteca era composta da circa 130 scatole e richiedeva tre navi per il trasporto. Una delle navi andò perduta per colpa dei pirati e poco dopo che le parti rimanenti della biblioteca giunsero a destinazione, l'erede di Pinelli morì. Dopo anni di avanti e indietro, durante i quali gran parte dei libri andarono perduti per negligenza, la biblioteca fu venduta all'asta per conto della vedova dell'erede di Pinelli nel 1608.

Come era consuetudine all'epoca, il formato dell'asta era quello di un'asta a candela: il banditore accendeva una candela in vista degli offerenti interessati, che poi chiamavano le loro offerte fino allo spegnimento della candela. Il miglior offerente nel momento in cui la candela si spegneva aveva vinto l'oggetto e pagava la sua offerta. L'asta per gli oggetti di Pinelli è stata una delle prime aste a candela su cui esiste un resoconto storico dettagliato. Le aste a candela furono utilizzate già nella Francia medievale (i documenti risalgono almeno al 1368), principalmente per risolvere le controversie sull'eredità. Altri record includono aste di navi e pellicce in Inghilterra.

Le aste a candela sono state utilizzate regolarmente solo per un periodo di tempo relativamente breve. (Alla fine sono stati sostituiti da aste la cui fine è stata annunciata dal banditore con tre colpi di bastone, proprio come le conosciamo oggi.) Il motivo della loro scomparsa era che erano piuttosto problematiche da gestire. In particolare, la maggior parte delle aste a candela all'epoca hanno dovuto affrontare i tre seguenti problemi.

In primo luogo, le persone iniziarono presto a impegnarsi in ciò che oggi è noto come cecchinaggio; cioè essi:

"maliziosamente [tirano] fuori l'offerta fino a quando la candela [non è] molto bruciata, con il risultato che le eredità [vennero] raramente vendute al loro valore reale."[4]

In secondo luogo, ci sono stati ripetuti tentativi di manipolare il tempo finale, principalmente tossendo così forte che la candela si spegneva.

E terzo, era spesso molto difficile determinare con precisione il vincitore una volta spenta la candela, il che poteva portare ad accese controversie. Ad esempio, Samuel Pepys scrisse, nei suoi famosi diari, osservando un'asta a candela in Inghilterra rimase sconvolto nel vedere:

"quando la candela si spegne, come gridano e poi contestano chi ha offerto di più per primo."[5]

La vendita della biblioteca di Pinelli non è andata come previsto per un ulteriore, quarto motivo: poiché la vedova non era soddisfatta del prezzo raggiunto dall'asta, si è rifiutata di consegnare alcuni dei libri dopo l'asta. L'acquirente, un avvocato per conto del cardinale Federico Borromeo, fondatore della famosa Biblioteca Ambrosiana a Milano, da anni era alla ricerca della biblioteca Pinelli. Per paura di ulteriori ritardi a causa di una lunga battaglia legale, accettò un nuovo accordo meno favorevole e alla fine spedì i libri a Milano.

**I vantaggi della tecnologia blockchain**

Quindi, le prime aste a candela in generale e la vendita della biblioteca di Pinelli, in particolare, furono un disastro. In che senso la tecnologia blockchain poteva aiutare?

In primo luogo, il comportamento della vedova dopo la vendita punta a un grosso problema di qualsiasi asta che si tiene off-chain: la mancanza di potere di impegno da parte del banditore. Anche con il miglior sistema legale in atto, il venditore può almeno ritardare la transazione della merce in vendita quando ha un improvviso cambio di idea dopo l'asta. Naturalmente, se gli offerenti nell'asta anticipano tale comportamento, non faranno offerte così seriamente come farebbero altrimenti, il che a sua volta produce ricavi ancora più bassi. Al contrario, se sia l'asta che l'oggetto in vendita sono sulla blockchain, uno smart contract può risolvere facilmente questo problema, innescando il trasferimento sia dell'offerta che dell'oggetto una volta determinato l'offerente vincente.

Quindi, passa all'asta a candela in modo più specifico e considera il problema del cecchinaggio. Il motivo per utilizzare una candela è rendere stocastico (casuale) l'ora di fine dell'asta: nessuno dovrebbe essere in grado di dire quando l'asta è finita, il che a sua volta dovrebbe incoraggiare l'offerta anticipata. Sembra una buona idea, ma la distribuzione di probabilità fornita dalla candela aveva la massa maggiore nel periodo in cui la candela era quasi bruciata. In altre parole, la probabilità che l'asta finisse anticipatamente era praticamente nulla. Non c'è da stupirsi, quindi, che tutti abbiano aspettato che la candela fosse quasi spenta (cosa che si poteva dire quando la fiamma ha iniziato a tremolare).

Al contrario, i computer moderni consentono distribuzioni temporali di fine (possibili tempi di fine) che sono più distribuite, aumentando la probabilità che un'asta termini in anticipo. Il potenziale per tempi di conclusione anticipati implica che lo sniping non sia più un problema, poiché gli offerenti sono sotto pressione per fare offerte seriamente fin dall'inizio.

Tuttavia, i computer moderni da soli non possono risolvere il secondo problema dell'asta a candela: la manipolabilità del tempo finale. In particolare, il banditore che agisce per conto del venditore deve ancora convincere gli offerenti che il finale annunciato è effettivamente quello scelto dal generatore di numeri casuali. Dopotutto, poiché le offerte aumentano nel tempo, il venditore preferisce sempre un termine successivo piuttosto che anticipato. Fortunatamente, i recenti progressi della crittografia consentono una casualità che è immutabile e che può essere verificata da tutti nella rete.[6] Quindi in un'asta a candela nella blockchain, gli offerenti non possono semplicemente tossire sulla candela né il banditore può mentire sull'ora di fine.

Il terzo problema con le aste a candela era che la loro esecuzione era spesso piuttosto frenetica, portando a litigi su chi offriva quando e quale importo. Nelle aste moderne (sia online che offline) viene registrato l'ordine esatto delle offerte, il che dovrebbe ridurre questo tipo di controversie. Tuttavia, c'è ancora un problema con la manipolazione segreta di tali record. Soprattutto nelle aste online complesse, le accuse di frode sono frequenti.[7] Quindi, la partecipazione a tali aste è sempre basata su una buona dose di fiducia nel banditore. Ovviamente, questo contrasta con le aste blockchain: se le offerte sono registrate on-chain, allora tutti possono verificare l'importo e la tempistica di tutte le offerte e non è richiesta alcuna fiducia.

**Il caso dell'asta a candela**

Ora che abbiamo un'idea di come le implementazioni blockchain delle aste a candela siano un miglioramento rispetto alle implementazioni precedenti, la domanda rimane: perché usare un'asta a candela in primo luogo?

Recenti ricerche presso la Web3 Foundation [cfr. Häfner e Stewart, 2021] suggeriscono che l'asta a candela aiuta con due problemi principali tipicamente affrontati dalle aste basate su blockchain: il front-running e la presenza di contratti intelligenti tra gli offerenti.

Opportunità di primo piano (agire prima di altri sulla base di informazioni privilegiate o conoscenze privilegiate) emergono naturalmente sulle blockchain perché le transazioni imminenti diventano note tra i partecipanti alla rete prima che siano incluse in nuovi blocchi.[8] Per le implementazioni blockchain delle aste, ciò significa che alcuni offerenti possono vedere e reagire alle offerte di altri offerenti prima che entrino in vigore; cioè prima che siano registrati sulla chain e siano quindi presi in considerazione dal meccanismo dell'asta.

Ad esempio, nelle aste al primo prezzo (aste in cui l'offerente vincente paga l'offerta più alta) ciò offre agli offerenti esperti di tecnologia la possibilità di superare gli altri offerenti a loro piacimento. Ma poi, la preoccupazione è che la presenza del front-running renda la partecipazione molto poco attraente per alcuni offerenti, deprima le offerte complessive e quindi riduca le entrate nelle aste. Inoltre, l'efficienza potrebbe essere negativamente influenzata dal fatto che il bene in vendita va all'offerente tecnicamente più avanzato piuttosto che all'offerente con la valutazione più alta.

Come discusso nella ricerca della Web3 Foundation di Jeff Burdges e Luca de Feo, esistono soluzioni crittografiche al problema di primo piano. Tuttavia, sono molto impegnativi in ​​termini di calcolo o richiedono più azioni da parte degli offerenti. Ancora più importante, tuttavia, le soluzioni crittografiche non funzionano se l'offerta stessa viene eseguita da smart contract. Il motivo è che gli smart contract corrispondono a codice visibile pubblicamente. Quindi, la loro valutazione per il bene in vendita e la loro strategia sono pubblicamente noti prima dell'asta. Dato il loro uso diffuso, la presenza di smart contract tra i potenziali offerenti è molto probabile in qualsiasi asta implementata su una blockchain.

Gli smart-contract offerenti affrontano più in generale un problema di trasparenza. Se la valutazione di uno smart contract è nota in anticipo, il banditore ha un incentivo a registrare il proprio offerente (pseudonimo) e a fare le cosiddette offerte shill (cioè offerte che hanno lo scopo di aumentare il prezzo pagato dal vincitore). Ciò è particolarmente problematico nelle aste al secondo prezzo (vale a dire, le aste in cui l'offerente vincente paga la seconda offerta più alta). In tali aste, è ottimale che tutti facciano un'offerta veritiera e, quindi, il banditore può arrivare al punto di defraudare sostanzialmente lo smart contract di qualsiasi utilità positiva dall'asta (presentando un'offerta appena al di sotto della valutazione dello smart contract) . Ma è probabile che gli Smart contract che anticipano un tale comportamento siano riluttanti a partecipare in primo luogo. Questo porta ancora una volta a problemi di efficienza, perché gli smart contract che hanno deciso di non partecipare potrebbero benissimo essere quelli con la valutazione più alta.

In conclusione, il front-running preclude essenzialmente le aste statiche in cui gli offerenti presentano contemporaneamente una sola offerta) e la trasparenza degli smart contract preclude le aste con una regola di pagamento del secondo prezzo (che sia statico o dinamico, ovvero con più round di offerta) .

In Häfner e Stewart (2021), mostriamo che il formato dell'asta a candela è una buona alternativa. Per chiarire il nostro punto, analizziamo un'asta stilizzata di candele tra due offerenti. In ogni round, i due offerenti si muovono in sequenza in un ordine fisso. Cioè, un offerente (pensalo come il meno esperto di tecnologia o l'offerente di smart contract) è sistematicamente in testa all'altro offerente. Le offerte devono aumentare nel tempo. L'offerente con l'offerta più alta nel round decisivo vince e paga la sua offerta.

Si scopre che con una distribuzione del tempo di fine opportunamente scelta è ottimale che il primo offerente faccia offerte crescenti nel tempo e che il secondo offerente corrisponda a queste offerte ogni volta che la sua valutazione per il bene in vendita è maggiore. Quindi, il formato dell'asta a candela fornisce una certa sicurezza contro gli attacchi con shill-bidding: per aumentare il prezzo al di sopra del prezzo di equilibrio, un banditore con shill-bidding dovrebbe presentare un'offerta vincente più alta in un round precedente. Ma questo avviene al costo di rinunciare a un pagamento da parte di uno degli offerenti nel caso in cui l'asta si concluda in quel periodo esatto.

Inoltre, un orario di fine casuale rende la partecipazione dell'offerente in prima fila più attraente rispetto a un orario di fine fisso. In un tempo di fine fisso è ottimale per entrambi gli offerenti attendere con l'offerta fino all'ultimo periodo. Il tempo di fine casuale, d'altra parte, mette sotto pressione gli offerenti a fare offerte prima. In particolare, poiché è ottimale che l'offerente di punta corrisponda all'attuale offerta più alta ogni volta che la sua valutazione è maggiore, l'offerente in prima posizione può esplorare la valutazione dell'offerente di punta presentando offerte crescenti nel tempo. Ciò gli consente di ottimizzare le sue offerte in base alle sue nuove informazioni e ottenere così un'utilità attesa maggiore.

Inoltre, mostriamo che un'ora di fine casuale porta a offerte vincenti più elevate rispetto a un'ora di fine fissa e quindi maggiori entrate. Questa non è affatto una conclusione scontata. Poiché gli offerenti presentano offerte crescenti nel tempo, avere una regola di chiusura casuale significa che a volte il banditore deve anche accettare offerte inferiori dai round precedenti. Tuttavia, la magia del tempo di fine casuale funziona per fare in modo che gli offerenti abbiano un'offerta complessivamente più alta, in modo che l'offerta vincente sia in media più alta.

Infine, mostriamo che con una distribuzione del tempo di fine uniforme e un numero elevato di round, il risultato si avvicina a quello di un'asta al secondo prezzo. Ciò significa che il pagamento previsto degli offerenti e, quindi, il reddito atteso del banditore sono pari a quelli dell'asta di secondo prezzo. Questo è un risultato importante, perché l'asta del secondo prezzo è tra le aste più ottimali, cioè tra quelle che producono le entrate più elevate. Significa anche - e questa è probabilmente la conseguenza più importante per Polkadot - che l'offerente con la valutazione più alta ottiene il bene. In altre parole, il risultato è efficiente.

Per riassumere, il formato dell'asta a candela è in grado di mitigare tutti e tre i problemi causati dal front-running: (1) bassa utilità per l'offerente svantaggiato; (2) basso reddito; (3) bassa efficienza. Inoltre, fintanto che il numero di round è finito, c'è un costo per lo shill bidding (perché, come detto sopra, il banditore corre il rischio di presentare lui stesso un'offerta vincente, nel qual caso il suo ricavo sarebbe zero). Date queste proprietà, dovremmo aspettarci che l'asta delle candele diventi un meccanismo standard per qualsiasi asta eseguita sulla blockchain.

**Post scriptum**

In un ultimo, ultimo tragico colpo di scena della svendita del libro Pinelli, il trasporto dei libri a Milano si rivelò più oneroso del previsto e, di conseguenza, gran parte dei libri fu smaltita via via. Infine, solo 35 scatole (sulle 130 iniziali) arrivarono alla Biblioteca Ambrosiana di Milano, dove si trovano ancora oggi.

**Per saperne di più**

Scopri di più su come funzionano le aste a candela di Polkadot su Polkadot Wiki e visita il portale di ricerca della Fondazione Web3 per le ultime pubblicazioni dei ricercatori della Fondazione Web3.

**Riferimenti**

Bulow, Jeremy, and Paul Klemperer. 1996\. “Auctions Versus Negotiations.” *The American Economic Review*, 86(1), 180-194.

Burdges, Jeffrey, and Luca De Feo. 2020\. “Delay Encryption.” *Working Paper*.

Daian, Philip, Steven Goldfeder, Tyler Kell, Yunqi Li, Xueyuan Zhao, Iddo Bentov, Lorenz Breidenbach, and Ari Juels. 2019\. [Flash Boys 2.0: Frontrunning, Transaction Reordering, and Consensus Instability in Decentralized Exchanges](https://arxiv.org/abs/1904.05234).

Häfner, Samuel, and Alistair Stewart. 2021.[Blockchains, Front-Running, and Candle Auctions.” *Working Paper*](https://ssrn.com/abstract=3846363).

Hobson, Anthony. 1971\. “A Sale by Candle in 1608.” *The Library* 5 (3): 215-233.

Micali, Silvio, Michael Rabin, and Salil Vadhan. 1999\. “Verifiable Random Functions.” *40th annual symposium on foundations of computer science* (cat. No. 99CB37039), 120-130.

Pepys, Samuel. [The Diary of Samuel Pepys](https://www.pepysdiary.com/).

---

1. See the seminal work by Bulow and Klemperer (1996). [↩︎](https://polkadot.network/blog/research-update-the-case-for-candle-auctions/#fnref1)
2. For a general overview, cf. the [Polkadot wiki article](https://wiki.polkadot.network/docs/en/learn-auction). The [Polkadot decoded talk by Shawn Tabrizi](https://www.youtube.com/watch?v=sxju74QqYuA) is also very informative. [↩︎](https://polkadot.network/blog/research-update-the-case-for-candle-auctions/#fnref2)
3. The accounts given in this and the next section largely follow Hobson (1971). [↩︎](https://polkadot.network/blog/research-update-the-case-for-candle-auctions/#fnref3)
4. Hobson (1971, 223). [↩︎](https://polkadot.network/blog/research-update-the-case-for-candle-auctions/#fnref4)
5. Pepys (1662, Wed. 3 September). [↩︎](https://polkadot.network/blog/research-update-the-case-for-candle-auctions/#fnref5)
6. See, e.g., Micali, Rabin, and Vadhan (1999). [↩︎](https://polkadot.network/blog/research-update-the-case-for-candle-auctions/#fnref6)
7. For example, [see this story](https://www.marketwatch.com/story/daily-mail-publisher-accuses-google-of-manipulating-search-engine-results-and-rigging-online-ad-auctions-11619023812) on MarketWatch about the manipulation accusations of Daily Mail against Google [↩︎](https://polkadot.network/blog/research-update-the-case-for-candle-auctions/#fnref7)
8. See, e.g., Daian et al. (2019). [↩︎](https://polkadot.network/blog/research-update-the-case-for-candle-auctions/#fnref8)

bafyreiflcsedzsvc45jwkbf4zc7h2lc244aeqbgqzlyfzzkdz5hzefaoqe

Ultime notizie sulla ricerca: il caso delle aste a candela

*Nota: tutto quanto descritto qui è soggetto a modifiche prima del lancio iniziale della mainnet di Polkadot, previsto per la fine del 2019 a seconda degli audit di sicurezza e delle disposizioni di lancio al di fuori del nostro controllo. È anche molto probabile che una volta che Polkadot sarà attivo, la rete aggiornerà i meccanismi di governance qui descritti. Per rimanere aggiornato, segui* [*Polkadot su Twitter*](https://twitter.com/polkadotnetwork) *per futuri annunci o tieni d'occhio* [*Polkadot Wiki*](https://wiki.polkadot.network/)*, dove verranno aggiornati i dettagli dei meccanismi di governance*

Polkadot istituisce un modello di governance all'avanguardia progettato per ottenere una rete sana che si adatti alle esigenze dei suoi utenti. È progettato per consentire un coinvolgimento rapido e rappresentativo della comunità sfruttando la tecnologia blockchain per trasparenza e responsabilità. Il token DOT consente un coinvolgimento a basso attrito in Polkadot e fornisce un livello innovativo di sofisticatezza e partecipazione alla governance globale distribuita.

Effettuare aggiornamenti ai protocolli distribuiti è un'impresa che tradizionalmente richiede enormi sforzi di coordinamento, creando costi generali esosi per l'adozione di nuove funzionalità e rendendo difficile l'adozione delle modifiche, indipendentemente da quanto possa essere controversa una proposta.

L'evolversi è fondamentale per la fattibilità a lungo termine di qualsiasi prodotto utile e le blockchain non sono diverse. Essendo decentralizzate, non ci sono mezzi banali per determinare come il prodotto di rete dovrebbe evolversi nel tempo: la governance è fondamentale per garantire un'evoluzione ordinata e senza scismi. I sistemi criptoeconomici decentralizzati diventeranno i nuovi stati del mondo di Internet e la governance è fondamentale per garantire che le risorse di questi sistemi crypto economici funzionino nei loro interessi (e dei suoi stakeholder).

## Governo 101

Esistono molte definizioni di governance, soprattutto negli ultimi tempi nello spazio blockchain, quindi è importante concordare i principi fondamentali della governance. Wikipedia definisce la governance come "*il modo in cui regole, norme e azioni sono strutturate, sostenute, regolate e ritenute responsabili*". Le Nazioni Unite affermano: "*La governance è stata definita come le regole del sistema politico per risolvere i conflitti tra attori e adottare decisioni*". I fattori comuni si riducono alla governance:

* Un sistema di regole
* Prendere decisioni
* Con i partecipanti ritenuti responsabili

Questi fattori costituiscono le regole che governano un sistema, o le regole su un sistema, piuttosto che all'interno di un sistema. Ad esempio, le regole che definiscono una transazione valida in Polkadot non rientrano nella "governance", ma le regole che decidono come modificare le regole di un formato di transazione rientrano nella nozione di governance.

## Governance di Polkadot

Un sistema di governance chiaramente delineato consente ai partecipanti di comprendere chiaramente i metodi, i requisiti e le fasi per attuare un cambiamento. Un sistema formalizzato che è codificato sulla chain assicura che queste regole siano seguite e che gli attori siano responsabili. Poiché l'adozione di regole formalizzate per i sistemi informali in sito è ​​estremamente difficile, Polkadot lancerà un sofisticato insieme di regole formalizzate sulla genesi. Al centro della governance di Polkadot c'è la nozione di voto ponderato per la posta in gioco, in cui i detentori di DOT votano con la loro partecipazione ai referendum proposti dalla comunità. Tutte le modifiche a Polkadot richiedono che venga concordata una maggioranza ponderata per la posta. Ciò viene eseguito utilizzando meccanismi sofisticati, descritti in dettaglio più avanti in questo articolo, che si differenziano notevolmente da altri recenti meccanismi di voto a moneta che appaiono in questa fase iniziale delle blockchain di governance on-chain. Tieni presente, tuttavia, che le regole stabilite all'inizio di Polkadot possono cambiare in seguito per fornire una migliore rappresentazione e attuazione man mano che la comunità impara dalle esperienze nel governo di una grande rete.

## Partecipanti alla governance di Polkadot

Allora, chi sono i partecipanti alla governance di Polkadot?

### Holder DOT

Al centro della governance di Polkadot c'è il token DOT, che consente un'interazione diretta e a basso attrito con le proposte avanzate dalla comunità. Gli holder di DOT votano sulle proposte con i loro token e aumentano il peso del loro voto bloccandoli per lunghi periodi di tempo. Gli holder di DOT possono utilizzare i propri DOT nella governance Polkadot nei seguenti modi:

* Proporre un referendum pubblico
* Dare priorità ai referendum pubblici
* Votare tutti i referendum attivi
* Votare i membri del consiglio
* Diventare membro del consiglio

I DOT consentono inoltre ai partecipanti di mettere in stake i propri DOT per convalidare sulla rete o impegnarsi nella votazione per i validatori, chiamata "nomina". Maggiori dettagli sul sistema Nominated-Proof-of-Stake di Polkadot sono disponibili [qui](https://medium.com/web3foundation/how-nominated-proof-of-stake-will-work-in-polkadot-377d70c6bd43).

## Il Consiglio

Le reti pubbliche decentralizzate che hanno tentato di formalizzare metodi di voto specifici spesso incontrano il problema della bassa affluenza alle urne. Questo è anche un problema nei sistemi di governance tradizionali, dove, a meno che non vengano fornite al pubblico questioni altamente politicizzate, è molto [improbabile](https://link.springer.com/article/10.1007/s11127-009-9504-1) che i referendum pubblici ottengano un'affluenza considerevole.

Per rappresentare i token holder passivi che potrebbero non essere in grado di votare in tutti i referendum, Polkadot introduce il Consiglio, un corpo di 6-24 membri che otterranno diritti di voto prioritari rispetto alla rete Polkadot. Il consiglio sarà eletto con l'ambizione di proporre referendum sensati, poiché i membri del consiglio metteranno in gioco la loro esperienza ed esperienza nello sviluppo, mantenimento e utilizzo di reti decentralizzate. I membri del consiglio hanno la possibilità di porre il veto alle proposte in arrivo. Dopo un periodo di riflessione, tuttavia, queste proposte possono essere riproposte e il membro del consiglio che ha posto il veto non può porre nuovamente il veto su questa proposta.

### Elezione del Consiglio

I membri del consiglio sono eletti in elezioni consecutive, con un membro del consiglio candidato alle elezioni ogni due settimane da una lista di candidati che si autoproclamano. Il mandato di ciascun membro del consiglio è determinato dalle dimensioni del consiglio, che cambierà nel tempo a causa della natura adattiva della governance di Polkadot. Ciò significa che la durata del mandato di un membro del consiglio è pari a 2 settimane per il numero dei membri del consiglio. Ad esempio, se ci sono 6 membri del consiglio, il mandato di un membro del consiglio dura 12 settimane (6x2).

![](https://ipfs.subsocial.network/ipfs/QmSKMkiPu4FXM5qT8dpwZZaxeKWMWmo2e8rZ7M4HM4fhPU)**Gli holder di DOT** votano per i membri del consiglio che li rappresentino. Introduciamo una funzione ponderata per la perdita a beneficio dei secondi classificati in ogni elezione, in modo che i membri del consiglio con una lunga storia di candidature come candidati possano beneficiare del loro continuo sostegno da parte della comunità.

![](https://ipfs.subsocial.network/ipfs/QmR8uX7owHT6DDxQwj41Noep7BvgxNJCcrWPR95NDeit4b)![](https://ipfs.subsocial.network/ipfs/QmNb5bXZmWrkvrBwXChdaXuHhmDUqCCftauJzsP746iCby)I potenziali membri del consiglio si eleggono per far parte della lista dei candidati del consiglio. Ogni due settimane viene eletto il membro del consiglio con il maggior numero di DOT utilizzati per votarli. Nel round successivo, i candidati del consiglio mantengono i loro voti dal round precedente finché gli holder di DOT non cambiano la loro posizione. Inoltre, i DOT utilizzati per votare i membri del consiglio perdenti vengono in parte accumulati nel round successivo evitando di “sprecarne” il valore. Il grafico sopra mostra un esempio di elezione al primo turno e la tabella seguente mostra il peso per ogni potenziale membro del consiglio per le elezioni successive due settimane dopo.

![](https://ipfs.subsocial.network/ipfs/QmNtZwdck9HodwnNkQrtA6uXxxWemKzyQhXYLCz7v83XW1)Come puoi vedere, il candidato del consiglio C ha vinto nel round 1 ed è stato rimosso dall'elenco dei candidati. Nel round 2, gli holder di DOT che non hanno ottenuto il voto del loro candidato al consiglio ora portano alcuni dei loro pesi di voto al voto successivo. (Nella tabella portano tutti i loro pesi, ma a Polkadot al momento del lancio, probabilmente ne riporteranno solo una parte.) I DOT utilizzati per votare per i membri del consiglio non sono bloccati in alcun modo e possono essere revocati o modificati in qualsiasi momento durante l'elezione dagli holder di DOT. I voti che stanno portando di più dalle precedenti elezioni "perse", tuttavia, vengono ripristinati una volta che un elettore cambia posizione.

## Referendum in Polkadot Governance

### Referendum

Ogni modifica a Polkadot assume la forma di un referendum. Il referendum contiene una funzione cruciale nel codice da affiancare ad essa, `set_code`, che ha la capacità di modificare qualsiasi aspetto del sistema. La funzione `set_code` è la funzione più potente che si trova in Polkadot, poiché cambia qualsiasi caratteristica, incluso il sistema di governance stesso.

### Chi può proporre un referendum?

I referendum possono essere proposti in tre modi, ciascuno con percorsi di attuazione diversi:

* Consiglio unanime
* Consiglio di Maggioranza
* Referendum pubblici

Le proposte che non ottengono la maggioranza all'interno del consiglio non arrivano a un referendum pubblico. Nelle situazioni in cui il consiglio è d'accordo all'unanimità, le proposte beneficiano di una soglia inferiore alla maggioranza in un voto pubblico per l'approvazione, come descritto nella sezione seguente sulla "Biasing del quorum adattivo". Quando solo la maggioranza dei membri del consiglio vota aye (si) su una determinata proposta, il pubblico deve approvare la mozione a maggioranza semplice.

I referendum pubblici possono essere proposti da qualsiasi holder di DOT e distaccati dai titolari di DOT di supporto. Dato che ci aspettiamo molte proposte dal pubblico, mitighiamo il problema dello spam delle proposte dando la priorità alle proposte con il maggior peso di Dot in stake. Ciò garantisce che le proposte più desiderate vengano votate per prime.

## Meccanismi di voto

### Bias adattivo del quorum

Per mitigare la realtà in cui è molto probabile che l'affluenza alle urne non sia mai al 100%, Polkadot introduce il Biasing del quorum adattivo. Il quorum è stato tradizionalmente definito come un numero minimo di partecipanti presenti affinché un voto sia considerato valido, ma negli ultimi secoli sono sorti problemi. Il superamento del quorum è stato utilizzato dalle minoranze per ritardare o impedire che si verificasse un voto e alcuni personaggi storici sono arrivati al punto di "[evitare il voto](https://historynewsnetwork.org/article/136982)" per impedire il raggiungimento del quorum. Gli studi hanno anche [dimostrato](https://historynewsnetwork.org/article/136982) che quorum rigorosi [riducono la partecipazione degli elettori](https://www.uni-heidelberg.de/md/awi/professuren/fiwi/2015%5F6%5F2%5Flac%5Fpm%5Fcv.pdf). Un'altra questione è come determinare il numero minimo di voti necessari per il raggiungimento del quorum, una decisione stessa che può essere controversa e come raggiungere una decisione senza un quorum definito? I sistemi di voto senza quorum hanno esplorato modi per incentivare la partecipazione premiando gli elettori o, al contrario, punendo i cittadini che non votano. La ricerca ha dimostrato che tali meccanismi possono portare a un'affluenza alle urne molto più elevata, ma un [effetto sproporzionato sull'aumento della conoscenza degli elettori](https://www.dropbox.com/s/6wsy97glfdpz038/Shineman%5FBJPS%5FIfYouMobilizeThemTheyWillBecomeInformed.pdf?dl=0)

![](https://ipfs.subsocial.network/ipfs/QmS9UfWfmTqMem2oGDXFftqF8TxJ2g2otQoJ5dKC9Lo8PD) L'Adaptive Quorum Biasing di Polkadot cambia la super maggioranza richiesta per l'approvazione di un referendum in base alla percentuale di affluenza alle urne.

* Un bias di affluenza alle urne positivo richiede una massiccia super maggioranza di voti aye (si) da portare a bassa affluenza alle urne, ma quando l'affluenza aumenta verso il 100%, diventa una maggioranza semplice come sopra. Chiamiamo questo un bias di affluenza "positivo" perché il margine richiesto di sì aumenta all'aumentare dell'affluenza alle urne.
* Un pregiudizio di affluenza alle urne negativo richiede una forte super maggioranza di voti contrari da respingere a bassa affluenza alle urne, ma quando l'affluenza aumenta verso il 100%, diventa una semplice maggioranza come sopra. Chiamiamo questo un bias di affluenza "negativo" perché il margine richiesto di no aumenta all'aumentare dell'affluenza alle urne.

Quando una proposta viene votata all'unanimità a favore del consiglio, beneficia dell'utilizzo del pregiudizio negativo. Partiamo dal presupposto che se il consiglio propone un referendum, la bassa affluenza alle urne è meno problematica. I referendum pubblici, invece, devono essere concordati utilizzando la curva positiva. Questo viene fatto per mitigare gli attacchi di proposte dannose o mal concepite. 

## Emanazione in ritardo

Quando una proposta viene votata all'unanimità a favore del consiglio, beneficia dell'utilizzo del pregiudizio invertito. I referendum pubblici, invece, devono essere concordati utilizzando la curva standard. Questo viene fatto per mitigare gli attacchi di proposte dannose o mal concepite. 

Una caratteristica importante nella governance di Polkadot è l'emanazione ritardata. Ogni referendum approvato passa per un certo periodo di tempo prima di essere emanato on-chain. Ciò consente ai partecipanti che non sono d'accordo con qualsiasi referendum di lasciare la rete, mentre gli holder di DOT che hanno votato a sostegno di questo referendum hanno i loro DOT bloccati fino all'adozione dell'aggiornamento. 

Gli elettori dovrebbero scegliere con attenzione quali proposte votare e tenere a mente l'impatto che i referendum avranno sulla salute dell'intera rete Polkadot. 

## Moltiplicazione dei voti bloccati / Votazione bloccata nel tempo

Polkadot introduce l'aspetto del voto con blocco temporale, un nuovo approccio che consente agli holder di DOT di aumentare il peso del proprio voto su una particolare mozione. 

Tutti gli elettori sono ponderati in base a due criteri: 

* DOT: la quantità di token di proprietà dell'elettore;
* Tempo: la quantità di tempo in cui queste coin rimarranno bloccate dopo la fine del referendum. Sono consentiti cinque periodi: 4 settimane, 8 settimane, 16 settimane, 32 settimane e 64 settimane. Ogni raddoppio del periodo fa sì che l'elettore ottenga un "voto" aggiuntivo.

Per votare, un elettore deve bloccare i propri DOT per almeno 4 settimane, il periodo di ritardo dell'emanazione oltre la fine del referendum. Questo per garantire che sia necessario un minimo di partecipazione economica al risultato e per mitigare lo scambio di voti. 

Con questo meccanismo, un elettore con cinque token disposto a bloccarli solo per la durata minima consentita avrebbe lo stesso numero di voti di un elettore con un solo token felice di averlo bloccato per il periodo di tempo massimo. 

In aggiunta a quanto sopra, un elettore può scegliere di non bloccare affatto i token per un forte sconto (90%) sul proprio peso di voto. Nello stesso scenario di cui sopra, un terzo elettore dovrebbe possedere 50 token per avere lo stesso potere di voto se non volesse bloccarli affatto. ![](https://lh6.googleusercontent.com/VSYk3qK0CiJQ47E%5C_Xb1pO5KTyq8X1p2Bmveu4UDhwGqOgBXVkIE-rOSzU9u8mMljmt8Hq-7gEAmgM7QJD76DS5tBJDgAYmkywR9ord64D1aoewFJBussa6WS8mDl6IDoOqtOk0YAqLRARWsZ-uXuj7w) 

![](https://ipfs.subsocial.network/ipfs/QmR6h8oUPjxzdsRwMye9ZT7rf8MWXFHh5yc4arbDpaxCnW)

## E c'è dell'altro

Nei mesi successivi, sviluppatori e ricercatori metteranno a punto i dettagli di quanto descritto qui. Probabilmente verranno utilizzati intervalli di tempo diversi una volta lanciato Polkadot e forse i pesi del voto con blocco temporale verranno modificati una volta completate ulteriori ricerche e test. 

Una caratteristica in arrivo su cui si sta lavorando in questo momento è il voto delegato, noto anche come "*democrazia liquida*". Per i partecipanti che non desiderano partecipare a tutte le votazioni, ma conoscono un individuo o un gruppo di cui si fidano per allinearsi con le proprie convinzioni, potranno delegare i propri voti. 

## Vuoi partecipare?

Questo [walkthrough di Polkadot](https://wiki.polkadot.network/docs/build-smart-contracts) vi ha invogliato a partecipare? Sentiti libero di usare Alexander testnet, il testnet vivente di Polkadot, già nella sua quarta Proof-of-Concept, essendo stato aggiornato utilizzando alcuni dei meccanismi sopra descritti. Molte delle caratteristiche descritte finora, tra cui la differenziazione del quorum adattivo, i referendum pubblici, la democrazia e i moduli del consiglio sono attivi. 

Mentre continuiamo a lavorare sulle interfacce di governance per una versione futura, il modo più semplice per iniziare è andare su <https://poc-3.polkadot.io>, creare un account, ottenere alcuni DOT di testnet dal [faucet](https://wiki.polkadot.network/docs/learn-DOT?ref=polkadot-network#getting-tokens-on-the-westend-testnet) e iniziare a giocare con trasferimenti, staking, nomine e, se ti va, proporre nuovi referendum.

bafyreigtq7i7bxmb6cl5eybjwqaj2zqgz56qe2tiqby32hx6kyvg4sl2my

Una panoramica della governance di Polkadot

Un intenso periodo di attività su Kusama è riportato dall'annuncio delle prime aste parachain. I 5 progetti che hanno partecipato, gareggiato e vinto durante le aste sono stati inseriti nella rete. Da allora, ciascuno ha lavorato alle relative fasi di lancio, ha avuto luogo il [monitoraggio delle prestazioni](https://github.com/paritytech/parity-ethereum) della rete ed è già stato proposto il [secondo round delle aste](https://polkadot.network/kusama-parachain-auctions-second-batch/). Con la prossima ondata di aste parachain in fase di lancio, è giunto il momento per un aggiornamento sul primo gruppo di vincitori e su ciò che hanno realizzato da quando hanno vinto il loro slot.

Questo blog contiene informazioni fornite dai progetti [Karura](https://acala.notion.site/dcabf9ba7c6246c69b913d5972503227?v=4121894373fd43d98ffcac260803928d), [Moonriver](https://moonbeam.network/networks/moonriver/launch/), [Shiden](https://astarnetwork.notion.site/dc65264053e84b9d97967b0ca364f8dd), [Khala](https://github.com/orgs/Phala-Network/projects/11) e [Bifrost](https://medium.com/bifrost-finance/bifrost-parachain-mainnet-is-live-collator-has-been-upgraded-to-version-0-9-8-weekly-report-62-e5bdd27f51f1), nell’ ordine in cui hanno vinto il loro slot parachain \[\*\]. Scoprite cosa fa ogni rete, i risultati ottenuti finora e le fasi future sulle rispettive roadmap.

## Karura

Secondo la loro pagina web, [Karura](https://acala.network/karura) è l'hub **DeFi** all-in-one di Kusama. Fondata dalla **Acala Foundation**, Karura è una rete scalabile compatibile con **EVM** ottimizzata per la DeFi. La piattaforma offre una suite di applicazioni finanziarie tra cui derivati di staking trustless (KSM liquido), una stablecoin multi-collateralizzata supportata da asset cross-chain (kUSD) e un AMM DEX, il tutto con commissioni di micro gas che possono essere pagate in qualsiasi token.

### Quali aggiornamenti avete fatto finora su Kusama?

Noi (Karura) abbiamo completato i seguenti aggiornamenti:

* Karura Runtime Upgrade ha disabilitato la chiave Sudo (super utente) e abilitato i trasferimenti di token
* Listata la coppia KAR/KMS tramite bootstrap su Karura Swap
* Karura Runtime Upgrade ha abilitato KSM come pagamento delle commissioni, stablecoin e NFT
* Abilitato il mint di stablecoin kUSD con KSM come garanzia
* Listata la coppia KSM/kUSD su Karura Swap
* Attivato il programma di incentivi sulle pool ( KAR/KSM e KSM/kUSD)
* Abilitato kUSD (KSM come garanzia) e listato la coppia KSM/kUSD e attivato il programma di incentivi
* Un aggiornamento urgente del runtime ha corretto un bug della tariffa di stabilità

Gli eventi onchain sono disponibili [qui](https://karura.subscan.io/event?address=&module=parachainsystem&event=validationfunctionapplied) e tutte le proposte di governance di aggiornamento di Karura possono essere trovate sul [forum](https://acala.discourse.group/c/karura/15) di Acala e Karura.

### Quali aggiornamenti avete pianificato?

Per abilitare nuove funzionalità e aggiornare le versioni di **Substrate**.

### Quali aggiornamenti avete pianificato fino alla fine dell'anno?

I prossimi passi per Karura includono l'abilitazione di Liquid KSM (LKSM), l’ aggiunta di altre coppie su Karura Swap, il lancio dei nostri bridge BTC ed ETH e l'abilitazione di Acala EVM su Karura. La roadmap completa per il lancio può essere trovata [qui](https://aca.la/karura-roadmap).

### Avete effettuato trasferimenti cross-chain? Se sì, quanti finora e a quali chain?

I seguenti trasferimenti KSM sono stati completati:

* Kusama => Karura ([7.220](https://karura.subscan.io/event?address=&module=parachainsystem&event=downwardmessagesprocessed))
* Karura => Kusama ([2.049](https://karura.subscan.io/event?address=&module=xtokens&event=transferred))

Sebbene ci siano già migliaia di [trasferimenti incrociati tra Kusama e Karura](https://twitter.com/XiliangChen/status/1425766573806022661), questo è il primo messaggio generico inviato da Karura a Kusama. Ciò ha dimostrato con successo la fattibilità di un pool di staking decentralizzato tramite XCM.

* Totale transazioni: 116.858
* Conti totali di Karura: 59.689
* Volume di scambio decentralizzato in 7 giorni: $ 200 milioni

### Qualche altra collaborazione cross-chain che avete fatto o su cui state lavorando?

Stiamo lavorando con tutte le parachain live per supportare i trasferimenti di token tra di loro. [Questo team](https://github.com/AcalaNetwork/Acala/pull/1307) ha già un proof of concept (PoC) funzionante.

## Moonriver

Secondo il loro sito web, [**Moonriver**](https://moonbeam.network/networks/moonriver/) è la “Parachain sorella guidata dalla community su Kusama. Moonriver è una rete complementare a Moonbeam e fornisce una rete canary permanentemente incentivata. Il nuovo codice viene spedito prima a Moonriver, dove può essere testato e verificato in condizioni economiche reali. Una volta testato con successo, lo stesso codice viene implementato su Moonbeam su Polkadot”.

### Quali aggiornamenti avete fatto finora su Kusama?

Noi (Moonriver) abbiamo completato almeno sei aggiornamenti finora su Kusama e prevediamo di fare molto di più. Gli aggiornamenti includono l'espansione del set di collator attivi a 32, che stanno già producendo blocchi, l'abilitazione della funzione di governance e la rimozione di Sudo. Altre fasi del processo di lancio di Moonriver sono state completate, le quali hanno consentito ai possessori di token di iniziare a prendere il controllo della rete tramite la governance on-chian, e hanno anche abilitato i trasferimenti di saldo e l'EVM. Ciò significa che la rete è completamente avviata e operativa su Kusama.

### Quali aggiornamenti avete pianificato per la fine dell'anno?

Ci saranno più aggiornamenti quest'anno. Abbiamo in programma di sfruttare appieno la possibilità di aggiornamento di Moonriver, integrata e senza fork, fornita da Substrate. Alcuni degli aggiornamenti pianificati (senza un ordine particolare) includono:

* Miglioramenti multipli delle prestazioni
* Supporto per EIP1559
* Supporto per asset cross-chain per KSM
* Supporto per asset cross-chain per KAR, kUSD
* Supporto cross-chain per la funzionalità della Relay chain

### Qual è la vostra tabella di marcia per il prossimo futuro? Qual è il prossimo passo?

Avendo abilitato i trasferimenti di saldo e l'EVM, i progetti attualmente basati su Moonbase Alpha (il nostro TestNet) inizieranno a essere implementati su Moonriver e avranno accesso alla rete Kusama. Siamo entusiasti di vedere come si svilupperà l'ecosistema di integrazioni e comunità di Moonriver!

### Avete effettuato trasferimenti cross-chain? Se sì, quanti finora e a quali chain?

Gran parte degli aggiornamenti riguardanti il trasferimento cross-chain sono stati ritardati a causa degli importanti sviluppi subiti dal formato XCM. Tuttavia, ora che XCM si sta stabilizzando, questi sviluppi sono la nostra priorita'. I nostri primi obiettivi sono KSM e l'intergazione bidirezionale tra Karura e Moonriver per permettere il trasferimento di KAR e kUSD a Moonriver e MOVR a Karura. Tuttavia, ora che l'XCM si sta stabilizzando, i trasferimenti cross-chain sono per noi al primo posto. Quindi i primi obiettivi sono KSM e l'integrazione bidirezionale con Karura per KAR e kUSD per essere trasferiti a Moonriver e MOVR per essere trasferito a Karura.

### Qualche altra collaborazione cross-chain che avete fatto o su cui state lavorando?

Le integrazioni native rivolte a Kusama sonosoltanto un aspetto dell'esecuzione; abbiamo anche un gran numero di integrazioni rivolte verso l'esterno ad altre chain che non siano Kusama. Ci sono bridge ERC20 come Meter Passport, che ci collegano a Polygon, Ethereum e BSC. Le reti di integrazione con cui stiamo lavorando, come Axelar, forniranno connettività a Ethereum e Terra una volta lanciate. Esistono anche bridge specifici per casi d'uso, come myNFT, progettati specificamente per il trasferimento di risorse NFT da Ethereum a Moonriver, ecc.

## Shiden

Secondo il loro sito Web, [Shiden](https://shiden.astar.network/) è un layer decentralizzato di applicazioni multi-chain su Kusama Network. La Relay chain Kusama non supporta la funzionalità di smart contract in base alla sua progettazione: la rete Kusama necessita quindi di un layer di smart contract. È qui che entra in gioco Shiden Network. Shiden supporta le soluzioni Ethereum Virtual Machine, WebAssembly e Layer2 sin dal primo giorno. La piattaforma supporta varie applicazioni come DeFi, NFT e altro. Le seguenti informazioni sono corrette al 14 agosto 2021.

### Quali aggiornamenti avete fatto finora su Kusama?

Dopo essere diventati una parachain su Kusama, abbiamo apportato i seguenti aggiornamenti:

1. Aggiornata la versione runtime di Shiden: il runtime del collator è stato aggiornato per funzionare con l'ultima versione di Kusama
2. Abilitato il modulo di chiamata in batch: le tariffe di tx per i token di vesting sono state modificate e il modulo di utilità batch è stato abilitato
3. Le ricompense del crowdloan Kusama sono state distribuite tramite il pallet di vesting
4. PoS implementato

### Quali aggiornamenti avete pianificato per la fine dell'anno?

Shiden Network sarà completamente funzionante entro la fine di settembre. Supporteremo sia EVM che WASM, nonché lo staking di dApp e un bridge Ethereum. Entro la fine di quest'anno, termineremo alcuni casi d'uso XCMP e il nostro Astar Network Portal, il primo prodotto realizzato da Stake Technologies, sarà completamente pronto.

### Qual è la vostra tabella di marcia per il prossimo futuro? Qual è il prossimo passo?

Come passaggio successivo, Shiden diventerà una rete NPoS e supporterà EVM e il bridge Ethereum. A metà corsa, supporteremo WASM in modo che gli utenti possano utilizzare sia EVM che WASM senza problemi.

### Avete effettuato trasferimenti cross-chain? Se sì, quanti finora e a quali chain?

Non ancora, ma abbiamo effettuato i primi trasferimenti XCMP con Acala su Rococo.

## Khala

Secondo il loro sito web, [Khala](https://phala.network/en/khala) è la Canary Network di [Phala](https://phala.network/en/). Phala mira a diventare una parachain di Polkadot che consente agli sviluppatori di invocare e interagire con contratti riservati su altre parachain di Polkadot.

### Quali aggiornamenti avete fatto finora su Kusama?

Khala è andato live dopo aver vinto lo slot di un'asta su Kusama a metà luglio. C'è una descrizione dettagliata per l'[evoluzione del lancio della rete](https://github.com/orgs/Phala-Network/projects/11), suddivisa in 4 "era".

#### 01 - Era Triassica (Completata)

* Phala Network ha vinto lo slot di Khala con l’ asta pubblica, rivendicando il quarto slot parachain su Kusama.

#### 02 - Era giurassica (in corso)

Completato:

* Rilasciato il [wallet Phala](https://app.phala.network/) e distribuito 24.961.006 K-PHA ai contributori del crowdloan ed early miner.
* Lanciato il bridge unidirezionale da Ethereum a Khala per i PHA il 6 agosto: gli utenti possono trasferire ERC-20 PHA a K-PHA in modo decentralizzato con solo una commissione di transazione di Ethereum. È il primo bridge ufficiale parachain-Ethereum nell'ecosistema Substrate. Il bridge ha superato un audit da parte di [CertiK](https://www.certik.org/?ref=polkadot-network), la principale società di sicurezza blockchain al mondo.

In corso:

* Attualmente, abbiamo un test di Inner mining che è in corso in Para-1 testnet e sarà presto aperto al pubblico. Quindi nomineremo una comunità di guardiani e i membri del consiglio professionale su invito.

### Quali aggiornamenti avete pianificato per la fine dell'anno?

Phala prevede di completare tutte e quattro le fasi del lancio della sua rete prima della fine dell'anno, inclusa l'era del Cretaceo (fase 3) e l'era dell'olocene (fase 4):

#### 03 - Era Cretacica

* Un voto pubblico formale su una proposta per aggiungere TEE worker e lanciare la funzione di mining TEE su Khala Network.
* Avviare l'elezione dei membri del consiglio e la rimozione del Sudo, dando alla community l'autorità completa per gestire la community
* Abilitare la funzione di trasferimento, il che significa abilitare $PHA per il trasferimento nella rete Khala

#### 04 - Era dell'Olocene

* Avviare il bridge a due vie Ethereum-Khala per trasferimenti semplici di PHA: ERC-20 PHA e K-PHA
* Inviare una proposta per aggiungere e lanciare il wallet PhaSe per la protezione della privacy
* Aggiungere i token Acala, Plasm e Statemint nel portafoglio PhaSe
* Abilitare XCMP per il cross-chain nel wallet PhaSe

### Qual è la vostra tabella di marcia per il prossimo futuro? Qual è il prossimo passo?

Rilasceremo al pubblico il nostro test di mining TEE, quindi inizieremo a votare per il nuovo modello ecologico di Phala. Quando sarà approvato, intendiamo lanciare ufficialmente Khala Network con il mining di TEE.

Pertanto, prevediamo di completare quanto segue nel prossimo futuro (due mesi):

* Test di TEE (agosto)
* Lancio del mining di TEE su Khala (settembre)
* Rimozione del Sudo e abilitazione della funzione di trasferimento (settembre)

### Avete effettuato trasferimenti cross-chain? Se sì, quanti finora e a quali chain?

Sì, Phala ha lanciato il ponte unidirezionale tra Ethereum e Khala per PHA, il che significa che il cross-chain bridge di Phala entra in una nuova pietra miliare. Ora gli utenti possono trasferire ERC-20 PHA a K-PHA in modo decentralizzato nel primo bridge ufficiale parachain-Ethereum nell'ecosistema Substrate. E in futuro, Phala lancerà più chain, non solo limitate alla parachain nell'ecosistema Substrate, ma anche su una delle chain di punta nel settore delle criptovalute.

### Qualche altra collaborazione cross-chain che avete fatto o su cui state lavorando?

In effetti, stiamo pianificando di costruire ponti con la blockchain della famiglia BTC, Diem, BSC, Heco, Solana, ecc. Stiamo lavorando nell'ecosistema Substrate con chain come Acala, Plasm e Statemint. In futuro, lanceremo XCMP per la funzionalità cross-chain nel wallet PhaSe.

## Bifrost

Secondo la loro wiki, [Bifrost](https://bifrost.finance/) è un protocollo **DeFi** che si connette con Polkadot e diverse blockchain PoS per fornire derivati di staking tramite XCMP o smart contracts.

### Quali aggiornamenti avete fatto finora su Kusama?

Il 20 luglio 2021, Bifrost ha aggiornato i collators alla v0.9.8 e ha completato con successo l'onboarding della parachain. Dal momento che la tesoreria non è stata ancora aperta, abbiamo eseguito il primo aggiornamento di Kusama per rimuovere la funzione delle commissioni della parachain di Bifrost, consentendoci di inviare tutte le ricompense di crowdloan ai contributori. Verrà riaperto una volta abilitata la governance.

### Quali aggiornamenti avete pianificato per la fine dell'anno?

Rimozione sudo

### Qual è la vostra tabella di marcia per il prossimo futuro? Qual è il prossimo passo?

Noi (Bifrost) prevediamo i seguenti nove interventi per abilitare le funzioni di base su governance, SALP e il token nativo $BNC, durante il processo di aggiornamento:

**Mozione 1: Rimozione del Sudo**. Una volta rimossa la chiave Sudo, i seguenti aggiornamenti di runtime verranno implementati tramite la democrazia e il consiglio tramite proposte.

**Mozione 2: Abilitare il trasferimento vsKSM e vsBond**

**Mozione 3: Abilitare il modulo SALP**

**Mozione 4: Abilitare il mining vsKSM e vsBond**

**Mozione 5: Abilitare SALP** [**Bancor**](https://wiki.bifrost.finance/learn/vtoken/salp?#bancor-algorithm). Verranno distribuiti i 5.613.129 KSM riservati durante il crowdloan di Bifrost.

**Mozione 6: Abilitare il modulo di Swap**. Supportare lo swap di BNC, vsKSM, KSM e i fornitori di liquidità. Stablecoin e [vETH](https://wiki.bifrost.finance/publicity/eth2.0-deposit-history). In futuro verranno aggiunti altri asset eterogenei della blockchain.

**Mozione 7: Abilitare il vsBond Market.** Supportare i requisiti di trading degli ordini in sospeso di vsBond.

**Mozione 8: Abilitare il trasferimento di BNC e Treasury**. Il vesting di BNC inizia a sbloccarsi e le commissioni della parachain confluiscono nella Tesoreria.

**Mozione 9: Abilitare dello Swap Liquidity Mining**

### Avete effettuato trasferimenti cross-chain? Se sì, quanti finora e a quali chain?

Non ancora, ma faremo sicuramente il doppio trasferimento cross-chain con Bifrost, per ottenere il contributo decentralizzato SALP tramite XCM.

### Qualche altra collaborazione cross-chain che avete fatto o su cui state lavorando?

Sì, al momento siamo partner di Karura e intendiamo occuparci presto di prestiti derivati. Nel frattempo, realizzeremo anche un trasferimento cross-chain con Statemine, consentendo il mining di derivati con progetti che hanno emesso un token nativo su Statemine, come Zenlink.

## Un inizio positivo per la interoperabilità delle parachain

Gli aggiornamenti dei team dipingono un quadro incoraggiante. Ogni progetto si sta muovendo a un buon ritmo attraverso le relative fasi di lancio e diverse parachain hanno già raggiunto la comunicazione cross-chain. I traguardi raggiunti in poco tempo dalla conquista di uno slot aggiungono credibilità alle proiezioni future di ciascun team e servono come segnale incoraggiante per un più ampio lancio di parachain. 

L'utilità delle parachain come chain solitaria può essere notevole, ma per la maggior parte il loro vero valore può essere realizzato solo una volta che sarà disponibile una comunità di parachain interoperabili. A breve, quando il prossimo lotto di aste di parachain si sarà svolto, undici parachain si saranno collegate alla Kusama Relay Chain, segnando un nuovo capitolo per la rete e portandoci un passo avanti verso il futuro multi-chain: un Internet di blockchain interoperabili.

\[\*\] Le informazioni sono state richieste ai team dal 13 al 14 agosto 2021\. Alcune delle risposte dei team sono state modificate per brevità e chiarezza o per mantenere aggiornate le informazioni

bafyreicy45cssbsdchqxp65c3jpnasdg3nucbwf53uirhk5uvj4oicveuq

Il primo lotto di parachain su Kusama: un'intervista con i team 

Polkadot è una rete blockchain che si ridimensiona diffondendo le transazioni su più frammenti (shards) di blockchain parallele chiamate parachain. Le parachain sono frammenti specializzati di Polkadot che danno ai progetti e alle loro comunità la possibiltà di agire sui rispettivi obiettivi. Sette team hanno aggiunto una parachain sulla testnet Rococo dal suo lancio il mese scorso, con molti altri nell'ecosistema Polkadot che si stanno muovendo rapidamente verso lo stesso traguardo.

Gli slot Parachain sono limitati e verranno [venduti in aste](https://wiki.polkadot.network/docs/en/learn-auction) a candela aperte. Piuttosto che mettere all'asta molti slot di parachain insieme, è più probabile (anche se non ancora confermato) che verranno venduti uno per uno, in modo che ci sia una sola asta parachain in un dato momento.

## Parachain vincoli e costi

Poiché questo processo significa che il costo dell'affitto di uno slot parachain sarà puramente in funzione della domanda e dell'offerta di mercato, è difficile fornire una stima significativa su quale sarà il requisito del vincolo. Tuttavia, possiamo iniziare a ottenere un quadro con la seguente valutazione della disponibilità dei DOT.

Polkadot cerca di incoraggiare un [tasso ideale di staking](https://wiki.polkadot.network/docs/en/learn-staking#inflation) al 50% di tutti i DOT. Supponendo che siano disponibili 100 slot per parachain (probabilmente l'importo massimo a medio termine), ciò significa che solo l'altro 50% di DOT sarà disponibile per il parachain bonding. Ovviamente, questo presuppone che si realizzi il tasso ideale di staking, che le persone useranno solo DOT per staking o parachain bonding e che tutti gli slot parachain costeranno lo stesso.

È importante rendersi conto che il costo effettivo di uno slot parachain non è uguale alla dimensione del blocco di DOT per la parachain , poiché il vincolo dei DOT viene restituito alla fine del periodo di locazione. Il costo effettivo della parachain è caratterizzato più accuratamente come il costo opportunità derivante dal non mettere in stake quei DOT.

## Numero di slot per parachain disponibili

L'obiettivo attuale è che Polkadot supporti fino a 100 parachain. Il supporto per parachain verrà probabilmente aggiunto prima della fine dell'anno e già più di un team ha schierato la propria parachain sulla testnet Rococò. Tuttavia, ci vorrà del tempo prima che la Polkadot Relay Chain supporti completamente i 100 slot. È probabile che gli slot vengano aggiunti al sistema lentamente nei prossimi due anni fino al raggiungimento di questo target.

## Come posso raccogliere fondi da vincolare?

La maggior parte dei progetti che vogliono lanciare una parachain sono startup che potrebbero non essere in grado di permettersi il costo richiesto per un contratto di locazione parachain. Inoltre, molti possessori di DOT potrebbero volere opzioni di utilità diverse da quelle che lo staking può fornire. Pertanto, è naturale che gli holder di DOT vogliano prestare i propri DOT a progetti che richiedono un prestito in cambio di un credito.

Se un progetto decide che vorrebbe fare un'offerta per un imminente slot parachain ma ritiene di non avere il capitale necessario per questo, può creare un'**offerta di prestito parachain** utilizzando il modulo di [crowdfunding](https://substrate.dev/recipes/crowdfund.html) di Substrate per accettare prestiti DOT da qualsiasi holder di DOT. I fondi garantiti tramite questo modulo andrebbero in un conto sulla Polkadot relay chain. Se il progetto è in grado di garantire contributi sufficienti per vincere l'asta, i prestiti DOT verranno restituiti al contribuente alla fine del periodo di locazione della parachain. Se il progetto non è in grado di garantire contributi sufficienti e l'asta viene persa, i DOT verranno restituiti immediatamente ai contributori. I DOT in questo account possono essere utilizzati solo per il parachain bonding e i progetti non sono in grado di trasferire i DOT da questo account. Poiché questo modulo si trova sulla Polkadot Relay Chain, i contributori possono fidarsi che il loro contributo è sicuro e alla fine lo riceveranno indietro (alla conclusione del contratto di locazione o in caso di perdita dell'asta).

A causa delle caratteristiche descritte sopra, i contributori del crowdfunding stanno essenzialmente effettuando un investimento di debito garantito su una parachain. Si prevede che i progetti ricompenseranno in qualche modo i contributori qualora dovessero vincere lo slot parachain nell'asta, ad esempio premiandoli con token parachain nativi. Sebbene le disposizioni sui premi non siano applicate dal modulo di crowdfunding, è probabile che molti progetti vorranno indicare una logica trust (trasparente) on-chain su come verranno forniti questi premi.

Se consideriamo il rendimento dello staking (10-20%) come il tasso di rendimento privo di rischio di DOT, ciò consente ai progetti una linea di base per pensare a come premiare i contributori del crowdsales di DOT. La caratterizzazione per cui il rendimento dello staking è equivalente al tasso privo di rischio non è del tutto vero, poiché lo staking comporta un rischio di slashing anche se il protocollo garantisce un certo rendimento. Quando si considera il ritorno che si guadagnerebbe tramite un crowdsale, è vero il contrario. Sebbene il protocollo garantisca la restituzione del proprio principale, non garantisce che il progetto li ricompenserà con un ulteriore ritorno in aggiunta a quanto detto sopra.

Le parachain che scelgono di implementare un token nativo possono scegliere di premiare i contributori di crowdsale utilizzando il loro token nativo. In questo caso, i contributori del crowdsale si aspetteranno probabilmente un rendimento superiore al tasso di rendimento dello staking per compensare il (presunto) rischio di prezzo più elevato di un nuovo token nativo. I progetti non devono necessariamente premiare la partecipazione tramite un token nativo, ma hanno la libertà di selezionare il metodo più sensato per loro. Alcuni scenari alternativi:

* I premi potrebbero essere emessi in stablecoin. In questo caso è probabile che possa essere fornito un rendimento inferiore al tasso di rendimento di staking poiché c'è poco rischio di prezzo sul flusso di rendimento e il capitale è completamente sicuro e non soggetto a slashing.
* I premi possono essere emessi in DOT. In questo caso è probabile che possa essere fornito un rendimento inferiore al tasso di rendimento dello staking ma maggiore del rendimento in stablecoin, poiché esiste un rischio di prezzo sul flusso di rendimento ma il capitale è completamente sicuro e non soggetto a slashing.

In definitiva, diversi tipi di contributori avranno preferenze diverse e i progetti potrebbero anche prendere in considerazione la possibilità di scegliere tra diverse opzioni di restituzione.

## E se non vinco una futura asta parachain?

Gli slot Parachain possono essere acquisiti solo per un periodo limitato di due anni o meno. Al termine del contratto di locazione, lo slot tornerà all'asta. I progetti che non riescono a vincere questa successiva asta di slot parachain hanno quattro opzioni principali da considerare:

1. Convertire la loro chain basata su Substrate in una [parathread](https://polkadot.network/parathreads-parathreads-pay-as-you-go-parachains/). Anche se questo non darà loro le stesse garanzie di throughput di una parachain, possono comunque utilizzare la sicurezza condivisa e l'interoperabilità di Polkadot, ma in un modello pay-as-you-go.
2. Sviluppare la parachain su Kusama. Ciò richiederà una pianificazione poiché anche su Kusama dovrà essere disponibile uno slot per parachain.Tuttavia, è probabile che i requisiti per vincere uno slot parachain siano inferiori su Kusama rispetto a Polkadot.
3. Sviluppare la loro applicazione o servizio su una parachain esistente tramite smart contract in Solidity o Ink!. Ciò ha un costo di sviluppo più elevato, ma è un'opzione per i progetti che desiderano utilizzare le parachain che supportano questi metodi.
4. Eseguire la loro chain basata su Substrate come chain solista e connetterla a Polkadot tramite un bridge. Ciò richiede la raccolta di risorse di sicurezza come validatori sul bridge e sulla chain stessa.

Le prime due opzioni di cui sopra non richiederebbero modifiche significative a una chain basata su Substrate. Per (1), parathread e parachain utilizzano un'API identica, quindi non sarebbero necessarie modifiche. Per (2), poiché Kusama e Polkadot utilizzano basi di codice molto simili, sarebbero probabilmente necessarie solo modifiche minime (se presenti).

È importante notare che un titolare di parachain non perderà il proprio slot immediatamente a causa della perdita dell'asta per il medesimo slot. Ci sarà un periodo di tempo dopo la conclusione dell'asta e quando lo slot sarà trasferito al nuovo titolare che sarà probabilmente dell'ordine di mesi.

## Modelli di sostenibilità per la parachain

Per molti progetti, potrebbe essere indesiderabile dover tentare continuamente di garantire il crowdfunding per gli slot parachain. Teoricamente, la dimensione del titolo richiesto crescerà nel tempo a un tasso vicino alla percentuale di inflazione (cioè circa il 10% con i parametri attuali). Per garantire la sostenibilità, ha senso che la maggior parte dei progetti si concentri almeno in parte sullo sviluppo delle proprie riserve DOT in modo che possano permettersi almeno una parte dell'obbligazione richiesta.

Un metodo per farlo è attraverso l'idea di un Decentralizzato Sovereign Wealth Fund (dSWF). Promulgato per la prima volta da Acala, questo è un fondo on-chain che si concentrerebbe sull'acquisizione di un numero sufficiente di DOT per consentire alla fine al progetto di assicurarsi il proprio slot parachain senza ricorrere a un crowdfunding significativo che potrebbe rappresentare un grave rischio aziendale. Spiegato in dettaglio nel [post](https://medium.com/acalanetwork/building-a-decentralized-sovereign-wealth-fund-6a5a0ae995b1#:~:text=Consider%20Acala%20Network%20as%20its,a%20well%2Dmanaged%20dSWF%20could) sul blog di Acala, una parte delle commissioni di transazione di un progetto potrebbe essere assegnata a un dSWF, che inizialmente utilizzerà queste commissioni per acquisire DOT, metterle in stake tra le aste di slot parachain e rimuoverle quando è il momento per il progetto di fare offerte su un nuovo slot. Man mano che la base di utenti del progetto cresce, crescono anche le commissioni di transazione guadagnate dal dSWF, che consente loro di acquisire sempre più DOT, consentendo al progetto di finanziare una parte maggiore del proprio slot di parachain nel tempo.

I progetti che hanno il proprio token potrebbero volerlo inflazionare tramite lo [staking di pallet](https://crates.parity.io/pallet_staking/index.html) e aggiungere una parte di questa inflazione (probabilmente la stragrande maggioranza) al dSWF. Questi token possono quindi essere utilizzati dal dSWF per acquisire DOT tramite un DEX o un altro metodo.

## Incentivazione dei collator

I [collators](https://wiki.polkadot.network/docs/en/maintain-collator) mantengono le parachain raccogliendo transazioni e producendo prove di transizione dello stato per i validatori. È buona norma che le chain dispongano di più collator per garantire la disponibilità di blocchi e prove di transizione dello stato ai validatori. Tuttavia, i collator possono influenzare solo la disponibilità dei blocchi e non possono compromettere la sicurezza. Hai solo bisogno di un collator onesto per garantire la disponibilità. Ciò rende i loro ruoli molto meno importanti e sensibili rispetto ai ruoli dei validatori. Sebbene sia importante disporre di un set distribuito di collator, questo è molto meno importante che avere un set distribuito di validatori.

Molti progetti richiedono le migliori iniziative per incentivare i collators e di seguito presentiamo alcune opzioni:

* Incentivare i collator attraverso commissioni di transazione specifiche per la tua chain. Potreste voler fare un bootstrap riservando una porzione fissa del vostro token nativo o altri tipi di ricompense per un'incentivazione iniziale, in modo da incentivare e diventare un collator prima che la tua chain abbia un numero significativo di transazioni.
* Se applicabile, inflazionate il vostro token nativo tramite lo [staking di pallet](https://crates.parity.io/pallet_staking/index.html) e utilizzate le ricompense per incentivare i collator. Questo è probabilmente il modo più semplice per creare un insieme decentralizzato di collator. Tuttavia dato il loro ruolo, questa incentivazione è forse eccessiva. Se utilizzato, il livello inflazionistico del vostro token potrà quindi essere molto basso.

Molti progetti sceglieranno di gestire autonomamente una parte dei nodi collator. Il che rappresenta la procedura migliore per garantire la disponibilità.

## Implicazioni per i modelli di token

Le considerazioni citate sopra hanno le seguenti implicazioni per i modelli economici parachain che coinvolgono un token nativo:

* In genere non è necessario inflazionare in modo *significativo* il token nativo per fornire ricompense ai collator.
* I modelli di token dovrebbero avere un meccanismo che consenta ai progetti di aumentare il livello delle loro riserve DOT, in modo che si muovano verso la possibilità di finanziare in modo sostenibile il loro noleggio di slot parachain e ridurre il livello di finanziamento DOT esterno richiesto nel tempo. Un potenziale modo per ottenere ciò è utilizzare il modello dSWF descritto sopra, con o senza l'uso dell'inflazione per acquisire DOT aggiuntivi.

## Percorso di sviluppo delle parachain

Per costruire in modo più efficace su Polkadot, consigliamo ai progetti di seguire il seguente percorso di sviluppo:

* Sviluppo di parachain in [Rococo](https://polkadot.network/introducing-rococo-polkadots-parachain-testnet/), la rete testnet di Polkadot e Kusama. Ciò consentirà al progetto di verificare la solidità della propria tecnologia prima di implementarla su una piattaforma con reali conseguenze economiche.
* Dopo che la tecnologia è stata sufficientemente sviluppata, la parachain dovrebbe essere lanciata su [Kusama](https://kusama.network/). Kusama è progettato per l'innovazione frenetica e mette la tecnologia più recente di Parity Technologies e Web3 Foundation nelle mani degli sviluppatori, anche prima che queste funzionalità arrivino su Polkadot. Fondamentalmente, Kusama avrà barriere di ingresso inferiori per gli sviluppatori poiché è probabile che il requisito di parachain bonding sia inferiore rispetto a Polkadot. Ciò lo rende un ambiente ideale per i team per mettere a punto il proprio prodotto e modello di business in una comunità di utenti effettivi prima di considerare un'implementazione su Polkadot.
* Dopo la messa a punto su Kusama, i progetti che richiedono sicurezza e robustezza simili a quelle di una banca possono prendere in considerazione un'implementazione su Polkadot. In caso di sviluppo su Polkadot, molti team possono scegliere di mantenere lo sviluppo su Kusama per testare nuove funzionalità prima di implementarle sulla loro parachain di Polkadot.

Maggiori dettagli sulla relazione tra Kusama e Polkadot possono essere trovati in questo [articolo (EN)](https://medium.com/polkadot-network/kusama-polkadot-comparing-the-cousins-170e4fe6c280).

**Ulteriori risorse**

*[Preparazione alla tua prima asta parachain (LongHash) (EN)](https://medium.com/@longhashSG/preparing-for-your-first-parachain-auction-d965bfe2ac6e)
* [Slot Parachain di Polkadot (EN)](https://medium.com/polkadot-network/polkadot-parachain-slots-f3f051d41699)

bafyreieabh2stdfknt7b2ksbawlqd3huh6ovwdd5dcgftbf2p5mb6kz53e

Come ottenere uno slot Parachain su Polkadot

# **Lancio e governance di Kusama**

Kusama è la rete sperimentale (“canary") di Polkadot. Si tratta di una prima rete di prova di pre-produzione, non certificata e completamente sperimentale, progettata per aiutare a comprendere come le varie tecnologie all'avanguardia introdotte in aree tra cui governance, staking e sharding funzionano in condizioni economiche "reali". Per saperne di più su Kusama, visitare <https://kusama.network/>.

La mattina \[del 23 agosto 2019\], intorno alle 9:30 ora svizzera, abbiamo dato il via a una blockchain che sarebbe presto diventata "Kusama Chain Candidate 1" e, con essa, il primo dispiegamento ("in the wild") di un protocollo originariamente concepito tre anni fa e in fase di sviluppo attivo da quasi due anni. Combinando innovazioni all'avanguardia in termini di governance, consenso e scalabilità, state per avere un assaggio del mondo blockchain che verrà. In breve, Polkadot v0.5.0 è uscito e ora potete sincronizzarvi con la rete provvisoria di Kusama.

Per decollare con un lancio soft, Kusama è nata come rete PoA (proof-of-authority) con nodi validatori gestiti esclusivamente da Web3 Foundation (senza compenso, ovviamente!). Durante questo periodo, molte funzionalità della rete sono disabilitate. In particolare non sono possibili trasferimenti di saldo e la governance è limitata al modulo “Sudo” di cui la Fondazione Web3 detiene la chiave unica. La funzionalità abilitata è limitata all'utilizzo dei moduli di Staking, Sessions e Claims; in particolare, saranno supportati il bonding, la nomina e l'emissione dell'intenzione di diventare un validatore, l'impostazione delle proprie chiavi di sessione e la rivendicazione dei KSM. Questo periodo durerà sufficientemente a lungo per consentire il bonding e la preparazione di almeno 50 e in futuro 100 validatori ben supportati. Ci aspettiamo che sarà tra una a quattro settimane.

Durante questo periodo si verificheranno uno o più aggiornamenti di runtime aggiuntivi per unire ulteriori funzionalità alla chain. Ciò in parte per consentire un ulteriore test e sviluppo della logica e in parte per testare la stessa nell’ aggiornamento del runtime. Dopo questo periodo, Web3 Foundation rilascerà un aggiornamento centralizzato finale del runtime. Questo rimuoverà il modulo Sudo e con esso l'autorità della Web3 Foundation sulla chain. Introdurrà l'apparato di governance Genesis di Kusama e consentirà il sistema di staking NPoS, trasformando efficacemente Kusama da una rete PoA centralizzata a una rete PoS decentralizzata. A questo punto, la governance e i trasferimenti di bilancio diventeranno attivi e Kusama sarà funzionalmente attiva.

## Governance Genesi

Il sistema di governance iniziale di Kusama, noto come "Genesis Governance", è un modello tricamerale. La camera *referendaria* (che può essere approssimativamente considerata la camera "legislativa") ha la composizione più ampia di tutte e tre ed è di gran lunga la più potente. Tutta la legislazione (cioè le modifiche alla logica di Kusama) devono ottenere l'approvazione di questa camera, che avviene come un'assemblea di tutte le parti interessate (cioè i token holder di KSM) ponderata in base sia alla quantità di KSM detenuta sia per la quantità di tempo che gli holder sono disposti a holdare(detenere). Le altre due camere sono il *Consiglio*, o *Council*, (che ha alcune somiglianze con un organo esecutivo) e il *Comitato tecnico*, o *Technical Committee*. L'appartenenza al Consiglio è un voto di approvazione proporzionalmente rappresentativo degli holder, ponderato solo per il numero di token controllati. Inizierà con sette seggi, partendo dal presupposto che dovrebbero essere ampliati man mano che cresce l'interesse della comunità per la governance. Il Comitato Tecnico è composto in base a un unico voto per tutti i team che hanno implementato o formalmente specificato con successo e in modo indipendente una delle due metà del protocollo Polkadot/Kusama (ovvero Polkadot Runtime Environment o l'attuale Kusama Runtime). I team che implementano entrambe ottengono quindi due voti. I team possono essere aggiunti o rimossi a maggioranza semplice del Consiglio votante. La votazione delle proposte in camera del referendum dura 28 giorni e, se approvata, si attendono altri 30 giorni prima dell'entrata in vigore della modifica. Ciò consente a coloro che sono vincolati al sistema di consenso NPoS ("stakers") di uscire dalla rete nel caso in cui ritengano che la legislazione sia catastrofica.

Tutti i votanti sono tenuti a rimanere per il periodo di 30 giorni fino alla data di entrata in vigore nel caso in cui "vinca la loro parte" (in caso contrario sono altrimenti liberi di vendere e lasciare la rete). Coloro che sono disposti a resistere per il doppio del tempo ottengono un voto aggiuntivo. Questo è il caso per un massimo di cinque voti aggiuntivi (ovvero coloro che sono disposti a tenere per circa due anni e mezzo ottengono sei voti). Coloro che non sono disposti a tenere possono ancora votare ma con una riduzione del potere del 90% rispetto a coloro che detengono per il minimo di quattro settimane.

Al 100% di affluenza alle urne (cioè con tutti i token allegati a un voto, indipendentemente dal suo periodo di blocco), nessuna legislazione può essere approvata senza almeno il 50% dei voti totali della prima camera in approvazione. Man mano che l'affluenza diminuisce, i meccanismi per l'approvazione differiscono a seconda di come è stata avanzata la normativa. In generale, viene applicata una tecnica nota come [Positive Turnout Bias](https://medium.com/polkadot-network/a-walkthrough-of-polkadots-governance-486555a056e0) (o semplicemente porta a super-maggioranza), per cui all'aumentare del numero di elettori distinti, la quantità di maggioranza necessaria per approvare la legislazione si riduce dal 100% al 50%. In altre parole, a qualsiasi cosa meno di un'affluenza completa, è necessaria una super maggioranza per approvare. La dimensione della super maggioranza richiesta si riduce (e quindi aumenta la possibilità che il movimento passi) all'aumentare dell'affluenza alle urne. Esistono due casi speciali; uno in cui è necessaria la maggioranza semplice, indipendentemente dall'affluenza alle urne. Questo metodo di conteggio viene solitamente indicato come portatore di maggioranza. L'altro, il cui nome proprio è Negative Turnout Bias, ma che è spesso noto come semplicemente default-carries, dove è necessaria una super-maggioranza di dissidenti per impedire il successo della legislazione, anche se questo si riduce ancora una volta a una maggioranza semplice poiché l'affluenza alle urne aumenta al 100%.

### Proposta di legge su Kusama

L'agenda legislativa di Kusama è suddivisa in proposte mensili per la votazione della prima camera. Le proposte vengono avanzate dal Consiglio o dal pubblico (che viene inserito nella coda pubblica). Ogni mese viene portata in votazione una proposta proveniente da uno di loro, dando la priorità a quella che non ha avuto esito positivo l'istanza precedente. In sostanza, lo fanno a turno. È quindi prerogativa del Consiglio controllare il 50% dell'agenda legislativa e del pubblico il restante 50%.

La coda pubblica è il mezzo più ampio per consentire l'attuazione della legislazione. Qualsiasi utente di Kusama può inserire una proposta in questa coda depositando un importo minimo di KSM dietro di essa, o "staccando" una proposta esistente e aggiungendo a questo deposito. Quando è il turno di una nuova proposta da questa coda pubblica, viene votata la proposta con il maggior numero di token in stake dietro.

Come accennato, i meccanismi per lo spoglio dei voti in camera del Referendum sono generalmente portanti della supermaggioranza. C'è un'eccezione: quando più di tre quarti del Consiglio votano a favore di una proposta, il voto diventa una maggioranza semplice senza riferimento all'affluenza alle urne. Inoltre, se e solo se il consiglio è unanime nella sua approvazione, viene utilizzato il default carry come metodo di conteggio dei voti.

### Tracciamento rapido

Kusama include la logica per consentire al suo sistema di governance di gestire condizioni impreviste in cui è necessario apportare rapidamente modifiche legislative. Questo tipo di “cortocircuito” legislativo consente di portare una proposta al referendum immediatamente e parallelamente alle normali proposte mensili.

In caso di approvazione da parte di una super maggioranza (più di tre quarti) del Consiglio e di due terzi del Comitato Tecnico, allora un atto legislativo può essere accelerato. Qui, viene messo immediatamente in votazione nella camera del referendum, con un periodo di votazione molto più breve del normale (3 giorni) e un periodo di emanazione vicino allo zero. I meccanismi di approvazione in questo caso sono invariati rispetto a come sarebbero altrimenti (a maggioranza semplice o, in caso di consiglio unanime, quindi a default-carry). Questo meccanismo dovrebbe essere sufficiente per correzioni di bug e aggiornamenti tecnici non controversi, ma dato il requisito dell'approvazione del Comitato Tecnico, potrebbe non essere efficace in caso di emergenze che hanno una sfumatura di sensibilità politica o importanza strategica per loro.

### Tesoreria (Treasury)

Oltre alla legislazione, l'apparato di governo di Kusama include la tesoreria. La tesoreria è una pentola di KSM riempita attraverso commissioni di transazioni, tagli, inefficienze nel set di staking di Kusama (ovvero qualsiasi cosa rimasta dall'inflazione del 10% che non viene ricompensata) e depositi persi. Lo scopo di questi fondi, in generale, è a beneficio della rete Kusama.

Il modo preciso in cui dovrebbero essere implementati è una cosa che spetta alla comunità decidere e rendere note le proprie aspettative. Queste aspettative possono essere rafforzate attraverso la selezione dei membri del consiglio da parte degli holder di KSM. Suggerimenti di spesa possono essere presentati da chiunque, con un acconto del 5% a fondo perduto sull'importo da spendere. Questi sono poi approvati o respinti dal consiglio. Quelle che sono approvate si mettono in coda e ogni 24 giorni (periodo di bilancio), vengono consumate dalla coda tante proposte di spesa quante il tesoro può permettersi di finanziare. Se non ci sono proposte di spesa approvate sufficienti per spendere i fondi del tesoro, una piccola parte dei fondi del tesoro rimanenti viene bruciata, creando una leggera pressione deflazionistica.

Il tipo di cose che possiamo immaginare che coprano le proposte di spesa includono:

* dispiegamento dell'infrastruttura e funzionamento continuato;
* operazioni di sicurezza della rete (servizi di monitoraggio, auditing continuo, …);
* disposizioni sull'ecosistema (collaborazioni con chain amiche, …);
* attività di marketing (pubblicità, funzionalità a pagamento, collaborazioni);
* eventi della comunità e sensibilizzazione (meetup, pizza-party di Kusama, hack-space);
* sviluppo software (wallet e integrazione di wallets,client e aggiornamenti di client, …);

Tuttavia, questo è in definitiva controllato dalle parti interessate di Kusama e sarà quel gruppo, la loro immaginazione e giudizio collettivi che determineranno davvero il corso della tesoreria.

## Governance post-genesi

Due ulteriori meccanismi di governance dovrebbero essere aggiunti a Kusama dopo il lancio (e alla rete principale di Polkadot su Genesis, se le prove andranno bene). Uno è l'Oracle Committee, l'altro è Spontaneous Subject Committees.

### Comitato Oracle

Il Comitato Oracle è un gruppo, non molto diverso dal Comitato Tecnico, la cui composizione è controllata dai membri stessi secondo un insieme di regole del linguaggio naturale un po' come una costituzione. A differenza del Comitato Tecnico, ai membri del Comitato Oracle viene chiesto, e retribuito, di votare esplicitamente. Ci si aspetta che valutino affermazioni progettate per essere oggettivamente vere o false e forniscano una risposta adeguata. In linea di principio, non ci si aspetta mai che usino giudizi o opinioni di alcun tipo.

La loro appartenenza è dettata da criteri oggettivi ampiamente progettati per massimizzare le loro possibilità di votare onestamente e le identità rimangono segrete fino a quando le persone non lasciano il comitato.

### Comitati tematici spontanei

I comitati tematici spontanei sono progettati per essere un modo più agile di catturare il sentimento degli stakeholder che può essere utilizzato in tandem con la struttura tricamerale esistente al fine di ottimizzare il flusso legislativo. In sostanza, utilizza un campionamento casuale progressivamente crescente e statisticamente significativo della popolazione votante ponderata per peso dello stake al fine di determinare la possibilità di un rifiuto o di un'approvazione schiacciante del referendum. Gli elettori campionati casualmente vengono ricompensati per i loro voti e viene presa in considerazione l'affluenza alle urne. Se il rifiuto o l'approvazione sono determinati con sufficiente sicurezza, la proposta può essere abbandonata o accelerata, liberando la lista d’ attesa per altre leggi più controverse.

## Scopri di più

Per saperne di più su [Kusama](https://kusama.network/), per ulteriori informazioni e collegamenti visitate il sito Web della rete.

## Uniscitevi alla comunità di Kusama

[Kusama Email Newsletter](https://share.hsforms.com/7051618/a475e0b5-411d-4e2e-b0b8-5b28cc6affd6)

[Kusama Twitter](https://twitter.com/kusamanetwork)

[Kusama Telegram](https://t.me/kusamanetworkofficial)

[Kusama Riot Chat](https://riot.im/app/#/room/#kusamawatercooler:polkadot.builders)

[Join the Polkadot Ambassadors](https://polkadot.network/polkadot-ambassador-program/)

[Kusama & Polkadot Webinars](https://www.crowdcast.io/polkadot)

bafyreif55fxvlyllkksuolc3jbv52qirb3misdwj52o2wqdubrowdwyus4

Lancio e governance di Kusama

Substrate e il sistema FRAME definiscono per lo sviluppo in runtime un potente insieme di funzioni primitive per la costruzione di infrastrutture blockchain. Usati insieme, creano nuovi approcci ai problemi esistenti. Questo articolo esplorerà un'applicazione reale in cui le funzioni di Substrate vengono utilizzate per implementare un hot wallet multi-indirizzo.

Un hot wallet di solito significa che le chiavi di spesa (spending keys)sono conservate su un dispositivo online in modo che possa creare e trasmettere transazioni in modo comodo e veloce, ma in genere con un rischio maggiore. Questo articolo esplorerà alcuni account abstractions- account multi-signature, account proxy e account derivative di Substrate ​​- che ci consentono di costruire un hot wallet in grado di supportare milioni di indirizzi in sicurezza.

Questo wallet sarebbe utile se aveste bisogno di conservare token per diversi account, ma nel frattempo voleste anche dare a ciascun cliente il proprio indirizzo di deposito. La soluzione banale sarebbe quella di creare un nuovo indirizzo di deposito per ogni cliente generando una nuova coppia di chiavi. Ma gestire tutte quelle chiavi diventa rapidamente non facile. E se aveste decine o centinaia di migliaia di utenti? Utilizzando Substrate account abstractions, possiamo costruire una soluzione che sia allo stesso tempo più scalabile e più sicura.

## Origini e ID account

Prima di iniziare a costruire l'hot wallet, dobbiamo gettare le basi che utilizzerà. Quando un utente interagisce con una blockchain, sta chiamando una funzione; l'insieme di queste funzioni "inviabili" costituisce l'interfaccia della blockchain.

Poiché le funzioni “inviabili” vengono invocate dal mondo esterno, la prima cosa che potrebbe interessare alla blockchain è chi ha effettivamente chiamato la funzione. Come prima cosa, la funzione deve verificare se il chiamante ha l'autorità per eseguirla. In secondo luogo, la chain potrebbe aver bisogno di sapere esattamente chi ha chiamato la funzione per aggiornare alcune informazioni sul chiamante. Se il chiamante è un account, la chain potrebbe dover aggiornare il suo saldo, ad es. per detrarre una commissione.

Potreste pensare: "Cosa intendi se il chiamante è un account?" Le funzioni in Substrate non provengono da account di per sé, provengono dalle *origini*. Il sistema di governance di Polkadot, ad esempio, ha una suite di *origini* speciali con privilegi come l'allocazione di fondi del Tesoro o la cancellazione di slashes. Se progettate la vostra blockchain con Substrate, potete creare le vostre origini personalizzate. Ma la cosa da tenere a mente per questo articolo è che un account è semplicemente una variante dell'origine Substrate. Potete pensare a questo come Substrate che dice alla funzione inviabile: "L'origine di questa esecuzione è un account".

Ora che abbiamo fatto il primo passo, abbiamo bisogno di un modo per dire alla funzione a quale account si riferisce l'origine. Se avete utilizzato qualsiasi blockchain, potreste essere abituati a un ID account come chiave pubblica che corrisponde a una chiave privata. Va bene, funziona anche in Substrate. In questo senso, un account viene identificato dalla chiave pubblica e autorizzato dalla corrispondente chiave privata.

Tuttavia, Substrate supporta maggiore astrazione. Un ID account può essere qualsiasi numero di 32 byte.\[1\] Potrebbe essere la chiave pubblica che corrisponde a una chiave privata, ma non deve esserlo per forza. Ha solo bisogno di un metodo di autorizzazione. Come se dovesse esserci un modo univoco per generare questo numero di identificazione dell'account, in modo che Substrate possa completare la frase iniziata sopra: "L'origine di questa esecuzione è un account identificato da questo numero".\[2\]

## Funzioni hash

Le funzioni hash si verificano continuamente nella blockchain. I blocchi sono letteralmente collegati tra loro tramite i loro hash. Ma useremo le proprietà delle funzioni hash per altri due scopi: generare ID account e identificare le chiamate di funzione.

Una funzione hash prende un input di qualsiasi dimensione e lo mappa su un output di dimensioni fisse, diciamo 32 byte. Ma non si limita a mappare i dati su qualsiasi numero di 32 byte, ma dovrebbe mappare deterministicamente i dati univoci a un numero univoco. Si dà il caso che 32 byte possano catturare un numero astronomicamente elevato di elementi.\[3\]

Ad esempio, potremmo prendere alcune informazioni su una chain, come "polkadot-treasury", e trasformarle in un ID account (32 byte) utilizzando una funzione hash. Oppure, potremmo prendere le informazioni su alcune transazioni, ad es. "trasferisci 10 unità sull'account 123..." e confidare nel fatto che l'hash sia un'immagine unica di tali informazioni.

## Account Multisig

Detto questo, possiamo iniziare a costruire la prima parte del nostro hot wallet: un account multisig. Gli account Multisig potrebbero non sembrare parte di un hot wallet a causa della goffaggine generale, ma questo account fungerà da base sicura per il resto dei componenti e tale goffaggine non ostacolerà l'utilizzo quotidiano.

Alcune blockchain utilizzano il multisig crittografico, dove più detentori di chiavi firmano una singola transazione off-chain prima di inviare la transazione on-chain. Il sistema multisig fornito con il sistema FRAME di Substrate funziona in un altro modo: genera un ID account basato sui singoli account che compongono il multisig e genera la soglia richiesta necessaria per l’invio dall'account creato. Substrate aggiunge uno speciale prefisso multisig a tutte queste informazioni e ne esegue l'hashing per ottenere un singolo output di 32 byte che utilizzerà l’account multisig come ID. Si noti che a questo ID account non è associata una chiave privata.

Per autorizzare una transazione da quel nuovo ID account, i membri del multisig inviano ciascuno una transazione on-chain con la chiamata di funzione che vogliono far eseguire all’account multisig. Ma non è efficiente per tutti inviare la chiamata di funzione; potrebbe essere grande e lo spazio del blocco scarso (e quindi costoso). Le funzioni hash tornano utili: solo uno dei singoli account deve inviare la chiamata di funzione effettiva; gli altri inviano solo l'hash. Stanno dicendo "siamo d'accordo a chiamare la funzione con questo hash dall'account multisig" e non è necessario inviare nuovamente la funzione.

Questo multisig da solo è troppo goffo e macchinoso per essere utilizzato come hot wallet perché richiede che più titolari di chiavi inviino transazioni per farlo funzionare. Ma è altamente sicuro e fungerà da account di base che potremo trasformare in un hot wallet senza sacrificarne la sicurezza.

## Account proxy

Gli account proxy consentono all'indirizzo multisig di delegare l'autorità di spesa a un altro account, che fungerà da hot wallet pur mantenendo sicuro il multisig. Imposteremo un proxy di ritardo temporale per gestire la spesa e un altro (o più) proxy istantanei per gestire la sicurezza per questo account multisig.

Un account proxy concede alcuni privilegi da un account all'altro per effettuare chiamate di funzione per suo conto. Questi privilegi possono essere specifici, ad esempio, "solo transazioni relative allo staking", o ampi, ad esempio, "tutte le transazioni che non trasferiscono fondi", o anche privilegi completi, "qualsiasi transazione".

La creazione di un proxy richiede solo una transazione dall'account da cui è stato eseguito il proxy, indicando quale altro account sarà il suo proxied account e i suoi privilegi. Una volta che si è stabilita la relazione tra i proxy, l'account proxy potrà effettuare transazioni per l’altro account, dicendo essenzialmente alla chain: "Sono un proxy per questo account, ho questi privilegi e voglio inviare questa chiamata di funzione per conto dell’account proxied”. La logica della chain verificherà che il proxy abbia i privilegi corretti e invierà quella funzione con l'origine dell'account proxied.

L'aggiunta di un ritardo aggiunge un ulteriore livello di sicurezza. Immaginate un ritardo di 600 blocchi (un'ora su Polkadot). L'account proxy invierebbe comunque una transazione dicendo che si tratta di un proxy con alcuni privilegi, ma annuncerebbe solo l'hash della chiamata di funzione che desidera effettuare. Il proprietario dell'account proxied può richiedere la chiamata di funzione effettiva ed esaminarla. Se il proprietario non approva, può rifiutare la chiamata di funzione inviando un'altra transazione prima che scada il ritardo. Dopo il ritardo, il proxy può inviare la chiamata di funzione effettiva che corrisponde all'annuncio e Substrate la invierà.\[4\]

Per il nostro caso d'uso, i titolari di chiavi multisig effettueranno una transazione per impostare un altro account come proxy di ritardo con privilegi completi, ad esempio includendo i trasferimenti di saldo. Forse questo account proxy vivrà su un server online che effettua le transazioni in modo autonomo. Ogni volta che effettua una transazione, dovrà prima annunciare l'hash e quindi inviare la chiamata di funzione effettiva a qualche altro titolare dell’account (per semplicità consideriamo questo altro titolare un membro del multisig) che può verificare che la chiamata di funzione non sia dannosa. In tal caso, il multisig può effettuare una transazione in tempo per rifiutare la chiamata e, per cautela, decidere che l'account proxy è stato compromesso e rimuoverlo.

Questa configurazione funziona effettivamente, ma possiamo comunque renderla più comoda da usare. Utilizzando un solo proxy, potremmo richiedere un lungo ritardo perché coordinare un numero sufficiente di titolari di chiavi multisig per effettuare una transazione di rifiuto può essere difficile con poco preavviso. Ma un account può avere più account proxy con privilegi diversi. Per risolvere questo problema, impostare ogni titolare di chiavi multisig come un proxy con privilegi di non trasferimento, in particolare con il privilegio di rifiutare gli annunci dal proxy di ritardo.

Ricapitoliamo questa configurazione. Al centro, abbiamo un conto multisig. Questo account non ha una chiave privata, ma ha due modi per controllarla: utilizzando un account proxy ritardato o raccogliendo un numero sufficiente di firmatari degli account dei membri. Ogni membro del multisig ha anche la possibilità di rifiutare le transazioni dal proxy con privilegi completi, ma non può effettuare trasferimenti di saldo senza che altri membri si uniscano per effettuare una transazione multisig.

Di per sé, questo è un hot wallet completamente funzionale che può cambiare la hot key (l'account proxy con privilegi completi) senza cambiarne l'indirizzo (l'account multisig), semplicemente rimuovendo il proxy e impostandone uno nuovo. Ma la nostra dichiarazione del problema originale richiedeva indirizzi di deposito univoci per decine di migliaia di utenti e finora ne abbiamo solo uno.

## Account Derivative

Finora abbiamo utilizzato più metodi per accedere a un account multisig; ora useremo un account per accedere a tanti multisig.

Ogni account in Substrate ha un albero di account derivati ​​a cui può accedere. Per ricavare gli ID account, e questo non ci dovrebbe più sorprendere, Substrate utilizza un algoritmo hash. Mediante l'hashing dell'ID account del chiamante con l'indice desiderato e un prefisso derivato, Substrate crea un nuovo ID account. Ad esempio, il mittente fornisce una chiamata di funzione e un indice, dicendo: "Voglio inviare questa funzione dal mio account derivato con questo indice".

Probabilmente vedrete dove sta andando. Il proprietario del wallet può assegnare un indice a ciascuno dei suoi utenti e fornire l'ID account derivato come indirizzo di deposito per quell'utente. Per accedere ai fondi, l'indirizzo proxy emetterebbe una transazione per trasferire fondi dall'indirizzo derivato del multisig.

In pratica, l'indice è limitato a 16 bit, o 65.536 account derivati, ma funziona anche il nesting. Cioè, ogni account derivato può avere il proprio insieme di 65.536 conti derivati e così via. Il secondo livello di questo albero avrebbe oltre quattro miliardi di account.

## Il quadro completo

Usiamo finalmente questo. Immagina che l'utente con l'indice 11 vi paghi e voi abbiate un "account di risparmio" sul quale volete depositare i fondi. La transazione completa sarebbe del tipo: "Sono un proxy per l’account multisig e voglio trasferire fondi dall’account derivato ​​​​del multisig con indice 11 all’account di risparmio".

Supponendo che tutto appaia OK per i supervisori, il ritardo scadrebbe e il proxy può trasmettere l'intera transazione. Se i membri del multisig pensano che la hot key debba essere modificata, possono semplicemente generarne una nuova e rimuovere quella vecchia come proxy, senza influenzare il multisig o nessuno dei suoi indirizzi derivati.

![](https://lh4.googleusercontent.com/76twLpxXEhfgjEZsPI70uyI-zuvW_j62pL7wkCzF7ZoSXmNnCAmhC8NPgL1sR0Rrneg-1LJY12oIZ-hmTQLcbyNbG_k1vZREU0rkxlLCKLxE8UzSea52wAAAm3dIseqe2ZJXRpvCtUtVXKDpdZT3J2gdlO8UHv2H8fMv2qEk5B31aHVGtNzKfmnnxj-4gQ)

L'immagine sopra mostra un diagramma del wallet che abbiamo impostato: un multisig (MS) è controllato da un insieme di chiavi (indicate con k) e imposta un proxy di ritardo del tempo (H) come tasto di scelta rapida. Dal multisig può derivare indirizzi virtualmente illimitati (l'insieme di d).

Possiamo anche ottimizzare ulteriormente questo flusso di lavoro. Substrate fornisce anche una funzione per inviare una batch di chiamate di funzione. Se gli utenti depositano e prelevano regolarmente dai loro account derivati, potete inviarli tutti in un unica batch di trasferimenti.

Le Substrate abstractions account on-chain forniscono metodi potenti per gestire gli account. Riducendo il numero di chiavi effettive necessarie e accedendo agli account in base a regole formali anziché a chiavi private, è possibile gestire centinaia di migliaia di account senza dover affrontare i limiti della memorizzazione di un numero equivalente di chiavi di firma. Questo articolo si è concentrato solo su un esempio, la creazione di un hot wallet, ma tutte le astrazioni sono isolate e possono essere composte in applicazioni più avanzate.

\[1\] Non devono essere 32 byte. Potete creare il vostro runtime con quello che volete, ma non voglio che questo articolo divampi nello sviluppo del runtime più di quanto dovrebbe

\[2\] Una rapida interruzione sulla parola “unico”, che intendo in un senso più rigoroso rispetto alla definizione media del dizionario. Una funzione è unica non se esiste una sola rappresentazione di essa, ma piuttosto se tutte le rappresentazioni (o serie di rappresentazioni) sono dimostrabilmente equivalenti. Potrebbe esistere un numero infinito di metodi per generare un particolare numero(account), ma finché tutti questi metodi generano lo stesso account, allora quell'account può essere considerato unico. Continuare su questo percorso ci porterà al tipo di matematica che ci tiene svegli la notte, ma noi stiamo generando un ID account e lo passeremo tra le funzioni, e il punto chiave qui è che non importa quante funzioni uniamo insieme (mettiamo in serie) per raggiungere un ID account, esso si comporterà come lo stesso ID account nella sua capacità di inviare *origin*

\[3\] Se siete interessati, 32 byte possono contenere fino al numero 1,15x10^77\. La distanza dal bordo dell'universo osservabile è di 45,7 miliardi di anni luce, ovvero 4,32x10^23 chilometri, o 4,32x10^29 millimetri. Se consideriamo che un disco piatto, ha un'area di 5,87x10^59 millimetri quadrati. Siamo ancora fuori di un fattore 10^18, o un miliardo al quadrato. Quindi le possibilità che due diversi input hash abbiano lo stesso output è come se entrambi gli elementi atterrassero sullo stesso millimetro quadrato dell'universo osservabile, quindi lo scompongono in una griglia di 1 miliardo per 1 miliardo e di nuovo entrambi atterrano nello stesso quadrato. Quei quadrati sono larghi 1 picometro. Per riferimento, un atomo di elio ha un diametro di 62 picometri

\[4\] In realtà, qualsiasi account può inviare la chiamata, a condizione che il proxy abbia fatto l'annuncio, ma per motivi di pragmatismo, supponiamo che il nostro hot wallet utilizzi semplicemente lo stesso account per annunciare e inviare.

bafyreie4xniyxrrmsu4iyelxemu6wlo2j2wtvbcekh5fain5o53jvegfqq

Costruire un Hot Wallet con Substrate Primitives

bafybeibrnjh7fuxcfcman26m2mwsccaefpa3ltamwpxz2ub65skb2mkrgy

Yamne

bafyreievvbfatnkwlpr7cjzunptcguf4xr44sxk24h6qqj775r33y27ysy

Polkadot Arena

bafyreigmllcpx4m7o2tfnlmtq3tywyb2e64taq5bslu45gmzjigsip62tu

Markh884

Un intenso periodo di attività su Kusama è riportato dall'annuncio delle prime aste parachain. I 5 progetti che hanno partecipato, gareggiato e vinto durante le aste sono stati inseriti nella rete. Da allora, ciascuno ha lavorato alle relative fasi di lancio, ha avuto luogo il monitoraggio delle...

Substrate e il sistema FRAME definiscono per lo sviluppo in runtime un potente insieme di funzioni primitive per la costruzione di infrastrutture blockchain. Usati insieme, creano nuovi approcci ai problemi esistenti. Questo articolo esplorerà un'applicazione reale in cui le funzioni di Substrate...

Polkadot è una rete blockchain che si ridimensiona diffondendo le transazioni su più frammenti (shards) di blockchain parallele chiamate parachain. Le parachain sono frammenti specializzati di Polkadot che danno ai progetti e alle loro comunità la possibiltà di agire sui rispettivi obiettivi...

Polkadot Arena è un progetto in lingua italiana di divulgazione sull'ecosistema #Polkadot. Tutti i contenuti realizzati dai membri del collettivo.

Il progetto è stato lanciato da appassionati, ambassador, validator e collator di Polkadot e/o alcune parachain. Abbiamo pensato che unendo le forze...

Lancio e governance di Kusama

Kusama è la rete sperimentale (“canary") di Polkadot. Si tratta di una prima rete di prova di pre-produzione, non certificata e completamente sperimentale, progettata per aiutare a comprendere come le varie tecnologie all'avanguardia introdotte in aree tra cui...

Ultime notizie sulla ricerca: il caso delle aste a candela

15 luglio 2021 July 15, 2021 in Research,Polkadot,Kusama by Polkadot

Di Samuel Häfner, ricercatore della Web3 foundation

Le aste Parachain sono una caratteristica centrale sia di Kusama che di Polkadot. Il loro risultato determina chi...

Nota: tutto quanto descritto qui è soggetto a modifiche prima del lancio iniziale della mainnet di Polkadot, previsto per la fine del 2019 a seconda degli audit di sicurezza e delle disposizioni di lancio al di fuori del nostro controllo. È anche molto probabile che una volta che Polkadot sarà...

Polkadot 2021 Roundup

December 31, 2021 in Polkadot by Gavin Wood

Le festività natalizie stanno tornando di nuovo e con il nuovo anno, diamo una veloce retrospettiva su ciò che il progetto Polkadot ha concluso nel 2021.

Ormai è una tradizione iniziare il nuovo anno con uno sguardo all’...

The Mountains hold up the heavens

The desire of gold is not for gold. It is for the means of freedom!

Traveller, Passionate about software development, Polkadot enthusiast