Ethereum è Centralizzato? Infura, AWS e Node Provider

Con il Merge (passaggio da Proof Of Work a Proof Of Stake), Ethereum è stato criticato per una sua eventuale centralizzazione. Infura è un'infrastruttura utilizzata da molti service provider di Ethereum, tra cui il wallet Metamask, che permette di non avere un proprio full node (sostanzialmente è simile ad Amazon Web Service). Cioè se devi offrire un servizio e non hai risorse, puoi appoggiarti ad Infura. Infura è stato lanciato nel 2016. All'epoca, l'obiettivo alla base del lancio era ridurre l'attrito per gli sviluppatori Web3 rendendo più semplice l'accesso alle reti Ethereum e IPFS. L'API di Infura Ethereum ha supportato più di 430.000 sviluppatori che ora stanno costruendo prodotti che ruotano attorno a giochi blockchain, finanza decentralizzata (DeFi), organizzazioni autonome decentralizzate (DAO) e token non fungibili (NFT). Qual è il problema di tutto questo? Che ti appoggi ad un ente terzo e soprattutto ad un servizio centralizzato (per quanto riguarda l'infrastruttura). Infura, tra l'altro, è americano quindi soggetto ad imposizioni da parte del governo. Ad esempio lo scorso anno, Metamask appoggiandosi ad Infura aveva avuto problemi di censura in alcuni paesi quindi si era urlato allo scandalo in quanto Ethereum appoggiandosi a Metamask quindi ad Infura era stato etichettato centralizzato (Metamask di default utilizza l'end-point di Infura). Sostanzialmente è possibile accedere ad Ethereum collegandosi a qualsiasi full node in modo decentralizzato, tuttavia utilizzando Metamask che di default usa Infura, se quest'ultimo decide di blacklistare indirizzi IP a causa di decisioni dei governi, si attua una censura. In realtà in questi casi basta cambiare URL RPC su Metamask, proprio perchè la censura è infrastrutturale e non dipende dalla blockchain. In realtà va aggiunta una rete manuale (le informazioni da aggiungere sono sempre le classiche della mainnet di Ethereum ovvero Chain ID, Block Explorer e simbolo che trovate anche nello screen di sotto, unica cosa che va modificato è appunto l'URL RPC e volendo il nome della rete dove potete scrivere Ethereum RPC Privacy per distinguerla da quella di default di Infura). Qui trovi una lista di URL RPC: Chainlist

Infura in futuro proverà a diventare più decentralizzato utilizzando più nodi sparsi nel mondo. Questo fornitore di infrastrutture è appunto controllato da ConsenSys di Joseph Lubin che ha sviluppato anche il wallet Metamask. Oltre a supportare gli sviluppatori su Ethereum, Infura supporta anche altri prodotti web3 come Ethereum Name Service e reti di livello 2. Esso supporta anche un'ampia gamma di API blockchain per realizzare un network multi-chain. Il passaggio ad una maggiore decentralizzazione arriverà nel 2023.

Ad inizio 2021, quando si parlava ancora di Proof Of Work, più di 6000 (56%) di tutti i nodi Ethereum erano in esecuzione su hosting provider, in particolare 2.500 (36%) su Amazon Web Services (AWS). Il secondo classificato per il maggior numero di nodi Ethereum era residenziale, con un discreto 4.500 (o 38,91%). Il vantaggio di avere il proprio full node, oltre a favorire la decentralizzazione, risiede nel non preoccuparsi che ad esempio AWS possa non funzionare o che qualche altro provider di hosting venga utilizzato per una dapp influendo sulle prestazioni degli utenti. Si può citare Quicknode, Allnodes, Alchemy o lo stesso Infura, il fornitore numero 1 di node-as-a-service, che nel corso della sua storia ha avuto anche altre interruzioni. La maggior parte dei pool/nodi minerari (quando Ethereum veniva minato) sono collegati tra loro, quindi i blocchi continuerebbero a passare, anche se la rete subirebbe rallentamenti (ci sarebbero meno transazioni convalidate). Chi ha un proprio full node non vedrebbe alcuna differenza. In realtà hosting provider come Infura e AWS non hanno solo aspetti negativi ma sono fondamentali per il buon funzionamento della rete. Gestire oltre 800 GB di spazio di archiviazione solo per sincronizzare la chain e quindi aggiungere 1 GB ogni giorno non è pratico per la persona media. Inoltre, non c'è quasi nessun incentivo economico per gestire un nodo, sebbene progetti come vipnode stiano lavorando su questo problema.

Il Trilemma Dei Bridge: Asset Nativi, Liquidità Unificata e Finalizzazione Istantanea

Chi è nel mondo blockchain sa che il più noto trilemma riguarda: decentralizzazione, sicurezza, scalabilità. Decentralizzazione indica un network non centralizzato, con tanti nodi. Affinchè sia decentralizzato è necessario che l'hardware per validare transazioni sia alla portata di più persone possibili. Questo è anche connesso alla sicurezza: più un network è decentralizzato e migliore sarà la sua sicurezza. Infine la scalabilità indica la velocità di conferma delle transazioni e la loro economicità. Un network molto scalabile è economico e veloce e viceversa. Viene definito trilemma perchè al migliorare 1 o 2 di questi 3 parametri si peggiora l'altro o gli altri 2. In poche parole non esiste la blockchain perfetta, bisogna solo trovare il giusto compromesso. 

Per approfondire: Come Risolvere Il Trilemma: Scalabilità, Sicurezza, Decentralizzazione

Un altro noto trilemma in ambito blockchain è quello dei bridge che sono uno dei più grandi punti deboli del mondo blockchain perchè essendo multichain hanno tanti punti di attacco. Un bridge hackerato e derubato dei suoi asset nativi immessi come collaterale, porta al de-peg della versione bridgiata per mancanza di liquidità.

TRILEMMA DEI BRIDGE

Il trilemma dei bridge ha 3 parametri da considerare:

-Native Assets (cioè la necessità di trasportare asset nativi nella chain di destinazione)

-Unified Liquidity (unico pool di liquidità per tutte le chains quindi accesso condiviso)

-Instant Guaranteed Finality (appena la transazione è confermata, i fondi dovrebbero arrivare istantaneamente nella chain di destinazione)

Anche in questo caso, è possibile prediligere 1 o 2 di questi 3 parametri. Un asset sintetico finalizzato mediante meccanismo lock & mint e burn & redeem raggiunge l'Instant Guaranteed Finality poiché gli asset vengono coniati sulla catena di destinazione senza alcuna possibilità di reversione a causa della mancanza di liquidità. Tuttavia, gli utenti ricevono un asset sintetico e devono poi ri-scambiarlo con la risorsa di cui hanno effettivamente bisogno. Ad esempio deposito Bitcoin nativo, ottengo una versione sintetica che ne traccia il prezzo (wBTC). Ovviamente se il bridge viene hackerato con la perdita degli asset nativi ci sarebbero problemi di liquidità e perdita del peg.

Nei bridge tradizionali, viene usato qualcosa chiamato come liquidità frammentata in cui si hanno pool separati per i diversi token (ad esempio se devo trasferire USDT da Ethereum a Solana, devo avere 2 pool di USDT sulle due chains). In uno schema frammentato, ogni catena mantiene un pool di liquidità separato appunto, dove se uno dei due pool si esaurisce otterrei ritardi o il fallimento della transazione. Per risolvere questo problema, l'utilizzo della liquidità unificata consentirà a tutte le chains di depositare e prelevare da un unico pool di liquidità. Tutte le chains condividono un singolo pool: USDC pool servirà tutte le chains ad esempio.

La liquidità unificata presenta il problema che se più transazioni simultanee vengono ritirate dallo stesso pool di liquidità, è necessario fare attenzione che il pool non si esaurisca prima che tutte le transazioni possano essere completate. Il bridge ideale dovrebbe permettere di scambiare un token sulla chain di ETH con un altro token sulla chain di BNB (esempio), utilizzando asset nativi ed un unico pool di liquidità multi-chain. Il tutto con una sola transazione. 

Una volta risolto il trilemma, non abbiamo più bisogno del lock & mint di asset sintetici o di una liquidità frammentata. Invece, è possibile avere simultaneamente pool unificati di risorse native legate a tutte le catene, creando ordini di maggiore efficienza (senza che la transazione fallisca per mancanza di liquidità). I LP potranno partecipare a un pool di asset unilaterali senza impermanent loss e riscuotere commissioni da tutti i trasferimenti in entrata, indipendentemente dalla loro catena di origine e senza asset wrapped/sintentici. Stargate costruito su LayerZero pare abbia risolto questo problema tramite il wrapping di un algoritmo Delta (Δ) che avviene in una singola transazione dalla catena di origine per eseguire azioni come swap -> bridge -> swap.

Come Funziona Elrond (MultiversX): Scalabilità e Il Problema Centralizzazione

Pochi giorni fa, a causa di un bug di Egld su Maiar, qualcuno è riuscito a far scendere il prezzo di Egld da 75$ a circa 5$. Sono stati generati più di 1 milione e 600mila Egld, poi dumpati sul dex grazie ad uno smart contract. Il prezzo è dumpato del 92% in circa 40 minuti. Il guadagno è derivato da operazioni di arbitraggio. In seguito i dev hanno bloccato il dex, mettendolo offline.

Uno dei più grossi problemi di Egld infatti è la centralizzazione e questa l'abbiamo visto anche in passato sempre sul Maiar Exchange. Gran parte dell'infrastruttura è "interna" sia per quanto riguarda le dapps che per il wallet Maiar. Già al lancio di Maiar c'erano stati enormi interrogativi, principalmente a dicembre 2021. Dopo una manutenzione programmata, ci sono stati problemi tecnici che hanno costretto lo staff di sviluppatori a mettere offline la piattaforma (conseguenza di ciò? Prezzi in picchiata del token del dex e di Egld). Il CEO Beniamin Mincu a dicembre 2021 aveva rassicurato tutti sul disservizio, dicendo che i fondi erano al sicuro:

"Abbiamo solamente trovato un complicato bug nel sistema di calcolo delle ricompense per i pool di liquidità, che creava una discordanza tra la liquidità attuale depositata nei pool e quella calcolata dal sistema, di conseguenza si è anche verificata una discordanza anche dei rispettivi APR.

Il fatto più importante da sottolineare è che nel grande schema delle cose, l’unico modo per assicurarsi che siate sul pezzo, e possiate continuare a spingere per migliorare le cose, è porre la massima enfasi e rispetto per la sicurezza. In particolare questo è vero quando la complessità di un prodotto è fuori scala, come nel caso del dex di Maiar"

Egld, rebrandizzato con questo nome dopo il cambio di supply (in precedenza era conosciuto come Elrond), è una delle chains più scalabili grazie al suo Secure Proof Of Stake e allo sharding (frammentazione della chains in "shards" che velocizzano validazioni di blocchi e transazioni). 

Il Secure Proof Of Stake vede validatori random (in base al numero dei token in staking e al punteggio reputazionale che aumenta all'aumentare delle validazioni corrette nel tempo, senza comportamenti malevoli) validare i blocchi sullo shard dove si trovano. I validatori ogni 24 ore vengono mischiati sui vari shards mediante "shuffle", per motivi di sicurezza.

La chain utilizza l' "Adaptive State Sharding" con un numero variabile di shards (gli shards aumentano all'aumentare dell'utilizzo del network) e la metachain (chain centrale di coordinamento). Gli shards variabili ottimizzano il network, la transazione una volta validata sullo shard viene inviata sulla metachain. La latenza del protocollo di comunicazione tra gli shards è zero quindi gli smart contract sono istantanei. Gli smart contract sono Arwen VM (tanti linguaggi di programmazione) e possono diventare compatibili con Ethereum tramite qualche operazione. Il token Egld ha una supply iniziale di 20 milioni e può raggiungere l'hard cap massima di 31.5 milioni (in realtà il numero sarà minore perchè con l'utilizzo del network le fee di transazione vengono sottratte dall'emissione di supply e distribuite agli stakers).

Cosa Sono I Trilemma? CAP, PACELC e Zooko Theorem

Oggi parleremo del Trilemma: ovvero tre opzioni (o requisiti, se preferite) sfavorevoli di cui una deve essere per forza scelta (trovando magari un compromesso). Oppure le tre opzioni possono essere apparentemente favorevoli ma solo due di tre rispetteranno il dato criterio stabilito. Ad esempio la tecnologia RAID (tecnica di raggruppamento dei dischi rigidi del PC) può offrire due dei tre valori favorevoli voluti: economicità, velocità o affidabilità. Il RAID 0 è veloce ed economico, ma inaffidabile. Il RAID 6 è estremamente veloce ed affidabile ma costoso.


CAP THEOREM
Applicato per la prima volta nel 1998 e noto anche come Teorema di Brewer, afferma che è impossibile per un sistema informatico distribuito rispondere simultaneamente a tutte e tre le seguenti garanzie:

1) Consistency (tutti i nodi vedono transitare gli stessi dati nello stesso momento)
2) Availability (ogni richiesta deve ricevere una risposta su ciò che è riuscito o fallito)
3) Partition Tolerance (il sistema continua a funzionare nonostante perdite di informazione)

Secondo il teorema, un sistema distribuito è in grado di soddisfare al massimo due di queste garanzie allo stesso tempo, ma non tutte e tre insieme.


PACELC THEOREM
Si tratta di un'estensione del CAP Theorem. Nel caso di partizionamento di rete (P) in un sistema informatico distribuito, si deve scegliere tra la disponibilità (A) e consistenza (C) (secondo il teorema CAP), ma per il resto (E), anche quando il sistema è in esecuzione normalmente in assenza di partizioni, si deve scegliere tra latenza (L) e consistenza (C).

TEOREMA DEL TRIANGOLO DI ZOOKO
Questo teorema invece riguarda la denominazione dei partecipanti a protocolli di rete.
I criteri sono: Human-Meaningful (nome facile da ricordare), Secure (sicuro, cioè una sola entità al cui il nome si applica), Decentralized (decentralizzato). Sostanzialmente, come si sarà capito, un nome non può essere allo stesso tempo facile da ricordare, sicuro e decentralizzato (cioè quando non si ha bisogno di un ente centrale per la risoluzione del nome). Solo due di queste tre garanzie saranno rispettate.
Ad esempio i nomi di dominio sono facili da ricordare, globali ma assolutamente non sicuri.
Gli indirizzi .onion (del protocollo TOR) sono decentralizzati, mediamente sicuri ma non facili da ricordare. I DNSSEC sono facili da ricordare e sicuri ma non decentralizzati.


LA TEORIA DI STIELGEL
Stiegel sostenne che utilizzando il sistema "Petname", tramite concatenamento di diversi fattori, si potrebbe riuscire ad incarnare tutte e tre le garanzie volute dal teorema di Zooko.
I criteri leggermente modificati sono:

1) Memorable (cioè facile da ricordare, leggendolo su un'insegna o un bus)
2) Global (nome deve rimandare ad una singola entità, non deve essere quindi ambiguo)
3) Securely Unique (nome che non può essere contraffatto o imitato. Nel primo caso il nome viene replicato, nel secondo caso no ma è talmente simile all'originale che inganna l'essere umano: si veda il Phishing ad esempio e i tentativi di spacciarsi per siti internet o mail di date società cambiando un simbolo al link o all'indirizzo mail)

Il Petname è sicuro e facile da ricordare ma non globale. Un essere umano può utilizzare l'Alias (globale e facile da ricordare ma non sicuro) per recuperare la chiave (globale e sicura ma non facile da ricordare) e per selezionare un Petname. Facendo riferimento a quest'ultimo si avrà un collegamento privato e bidirezionale con la chiave, dato che quest'ultima sarà associata sempre ad un Petname (riservato per accrescerne la sicurezza). Per esempio l'Alias potrebbe essere il mio nome e cognome, la chiave il mio numero di cellulare ed infine il Petname il mio nomignolo.

Per quello sulle criptovalute: Come Risolvere Il Trilemma: Scalabilità, Sicurezza, Decentralizzazione