🇮🇹 Mi sono piaciuti molto Itn e Cardano, ma potrebbe non piacermi mainet a causa di a0!

:it: Mi sono piaciuti molto Itn e Cardano, ma potrebbe non piacermi mainet a causa di a0!

Ho adorato il Testnet Incentivato. E’ stato fantastico perché chiunque poteva gestire una pool e convalidare alcuni blocchi, con possibilità proporzionali alle loro puntate, anche con pochi 100kAda si otteneva un blocco al mese. Ho gestito una pool e mi è piaciuto molto, onestamente non mi ha portato molti guadagni, ma ero molto contento dell’idea di partecipare direttamente alla sicurezza della rete. Non vedevo l’ora di avere Mainet e una criptovaluta PoS che controlliamo veramente.

Ma tutto questo potrebbe essere giunto alla fine perché ho appena scoperto che nel mainet le grandi pool, a quanto pare, verranno artificialmente avvantaggiate rispetto alle piccole dando loro un RoS più alto e la capacità di convalidare i blocchi. (Si noti che lo erano già perché una grande pool aveva più ricompense per i costi operativi simili, ma in questo caso sto parlando di qualcos’altro). Questo significa che daremo artificialmente più (potere e denaro) a chi ha già molto, e meno a chi ha già poco. Questo può solo portare alla centralizzazione nel lungo termine. La decentralizzazione non riguarda solo il numero di pool, ma anche dal fatto che chiunque dovrebbe avere le potenzialità per partecipare direttamente alla rete in proporzione ai propri mezzi, né più, né meno.

(Per consultare un post più tecnico su questo argomento: Understanding shelley reward formula (and k, a0 parameters))

Ma perché cambiare il modo in cui funzionava, quando si passava a mainet? Perché era suscettibile agli attacchi Sybill. Perché se le persone delegano a caso le loro partecipazioni alle pool, allora qualcuno potrebbe creare molte pool diverse e fingere di essere persone diverse. E poi o sperare che le persone deleghino a caso alle loro pool per conto loro (solo perché ce ne sono tante), o fare un po’ di pubblicità per attirare le persone verso le loro pool. Se chi sta attaccando potesse quindi controllare a basso costo il 51% delle stakes, controllerebbe l’intera rete.

Ci sono 2 possibili strategie per evitare tali attacchi sybill (entrambe possono essere applicate contemporaneamente):

1- Incentivare le persone a non delegare a caso:

a-Fare in modo che deleghino a una pool gestita direttamente da loro stessi
b-Farli delegare a una pool gestita da un amico o da qualcuno che conoscono direttamente
c-Farli partecipare a una pool di qualcuno che conoscono indirettamente ma che sia difficile da falsificare: youtuber, università, associazione, fornitore di servizi ben affermato, membro noto della comunità, ecc…

Naturalmente, perché questa prima strategia funzioni, bisogna permettere alle piccole pool di essere competitive almeno quanto quelle grandi, in modo che molte persone gestiscano piccole pool per conto proprio, e successivamente molte persone abbiano amici che lo fanno. Ma si vuole anche avere un RoS prevedibile che sia più o meno lo stesso per ogni pool gestita correttamente, in modo che l’unico criterio per un utente per scegliere una pool è quale sia la pool di cui si fida di più. Se si introduce un RoS variabile, allora si spinge la gente a delegare a caso a quella con il RoS più alto anche se non ha idea di chi la gestisca. Quindi nel complesso la formula scelta peggiora le cose da quel punto di vista.

**2- Limitare la capacità di un partecipante di creare molte pool che possono potenzialmente diventare grandi, limitando la quantità di stake delegati che si possono ottenere in proporzione al pledge/stake che si possiedono direttamente.

Sarebbe molto facile far rispettare che per ogni ADA che impegno direttamente nella mia pool, posso avere al massimo 2,4,5, 10 o 20 ADA delegati. (Non avvantaggerebbe le pool grandi rispetto a quelle piccole).

Ciò che è stato scelto invece può sembrare simile ma non lo è: l’ammontare del pledge influenzerebbe il RoS della stakepool, per dare e incentivare ad avere un pledge abbastanza grande, ma senza imporre nulla. Questo implica conseguenze abbastanza complesse e imprevedibili, non si conosce molto bene l’impatto di a0 e k, e bisogna provare a stimare tutto ciò con modelli complicati. La formula scelta ha anche il brutto effetto collaterale di avvantaggiare le pool grandi rispetto a quelle piccole, come ho detto prima.

Inoltre se trovate problematico far rispettare una limitazione, notate che k sta già facendo rispettare la puntata massima nello stesso identico modo.

**Potrei sbagliarmi o mancare in qualcosa, se è così per favore correggetemi. Se è veramente indispensabile che le grandi pool siano avvantaggiate rispetto a quelle piccole per prevenire gli attacchi sybill, dovremmo perlomeno avere delle prove valide e pubbliche. Per favore, dimostratemi che limitare semplicemente la capacità di ricevere ADA delegati in modo proporzionale agli ADA impegnati non è una buona idea.

Se ho ragione, spero che la formula di reward venga cambiata, per il meglio.

Traduzione di I loved Itn and Cardano, but I may not love mainet because of a0!