Autore: Zeke, YBB Capital Fonte: medium Traduzione: Shan Oba, Golden Finance

Prefazione

Nell’era delle blockchain modulari guidate da Ethereum, fornire servizi di sicurezza integrando un livello di disponibilità dei dati (DA) non è più un concetto nuovo. Attualmente, il concetto di sicurezza condivisa introdotto attraverso lo staking fornisce una nuova dimensione allo spazio modulare. Sfrutta il potenziale dell’”oro e argento digitale” per fornire sicurezza a numerosi protocolli blockchain e catene pubbliche, da Bitcoin o Ethereum. La storia è piuttosto ambiziosa, poiché non solo sblocca liquidità in asset per un valore di trilioni di dollari, ma è anche un elemento chiave nelle future soluzioni di scalabilità. Ad esempio, i recenti massicci raccolti di finanziamenti di 70 milioni di dollari per il protocollo di staking di Bitcoin Babylon e di 100 milioni di dollari per il protocollo di re-staking di Ethereum EigenLayer illustrano il forte sostegno per questo spazio da parte delle principali società di venture capital.

Tuttavia, questi sviluppi sollevano anche serie preoccupazioni. Se la modularità è la soluzione definitiva alla scalabilità e questi protocolli sono un componente chiave di tale soluzione, probabilmente avranno grandi quantità di BTC ed ETH bloccate. Ciò comporta problemi di sicurezza del protocollo stesso. I complessi strati formati da numerosi protocolli LSD (Liquid Stake Derivatives) e LRT (Layer 2 Rollup Tokens) diventeranno il più grande cigno nero del futuro della blockchain? La loro logica aziendale è valida? Poiché abbiamo già analizzato EigenLayer in un articolo precedente, la discussione seguente si concentrerà principalmente su Babylon per affrontare questi problemi.

Espandere il consenso sulla sicurezza

Bitcoin ed Ethereum sono senza dubbio le blockchain pubbliche di maggior valore oggi. La sicurezza, la decentralizzazione e il consenso sui valori che hanno accumulato nel corso degli anni sono le ragioni principali per cui sono sempre stati ai vertici del mondo blockchain. Si tratta di qualità rare e difficilmente replicabili con altre catene eterogenee. L’idea centrale della modularità è “affittare” queste qualità a chi ne ha bisogno. Nell'attuale approccio modulare, ci sono due fazioni principali:

La prima fazione utilizza uno strato 1 sufficientemente sicuro (di solito Ethereum) come gli ultimi tre strati o strati parzialmente funzionali dei Rollup. Questa soluzione ha la massima sicurezza e legalità e può assorbire le risorse dell’ecosistema della catena principale. Ma per rollup specifici (catene di applicazioni, catene a coda lunga, ecc.), potrebbe non essere particolarmente amichevole in termini di produttività e costi.

Il secondo gruppo mira a creare un’esistenza che sia vicina alla sicurezza di Bitcoin ed Ethereum ma con un migliore rapporto costi-prestazioni, come Celestia. Celestia raggiunge questo obiettivo utilizzando un'architettura funzionale DA pura, requisiti hardware minimi dei nodi e bassi costi del gas. Questo approccio semplificato mira a creare un livello DA che corrisponda alla sicurezza e alla decentralizzazione di Ethereum, offrendo allo stesso tempo prestazioni elevate nel più breve tempo possibile. Gli svantaggi di questo approccio sono che ci vorrà del tempo prima che la sua sicurezza e decentralizzazione siano pienamente realizzate, e manca di legittimità quando compete direttamente con Ethereum, portando al rifiuto da parte della comunità di Ethereum.

Il terzo tipo all'interno di questa fazione include gli strati Babilonese e Caratteristico. Sfruttano il concetto centrale di Proof of Stake (POS) per creare servizi di sicurezza condivisi sfruttando il valore patrimoniale di Bitcoin o Ethereum. Rispetto alle prime due, questa è un’esistenza più neutrale. Il suo vantaggio è che eredita legalità e sicurezza, fornendo allo stesso tempo più valore pratico agli asset della catena principale e fornendo maggiore flessibilità.

Le potenzialità dell'oro digitale

Indipendentemente dalla logica alla base di qualsiasi meccanismo di consenso, la sicurezza di una blockchain dipende in gran parte dalle risorse che la supportano. Le catene PoW richiedono molto hardware ed elettricità, mentre le PoS si basano sul valore delle risorse impegnate. Lo stesso Bitcoin è supportato da una rete PoW estremamente ampia, che lo rende l’esistenza più sicura nell’intero spazio blockchain. Tuttavia, essendo una catena pubblica con un valore di mercato circolante di 1,39 trilioni di dollari e che rappresenta la metà del mercato blockchain, la sua utilità patrimoniale è principalmente limitata ai trasferimenti e ai pagamenti del gas.

Per l'altra metà del mondo blockchain, soprattutto dopo che Ethereum è passato al PoS dopo l'aggiornamento di Shanghai, si può dire che la maggior parte delle catene pubbliche utilizza per impostazione predefinita diverse architetture PoS per raggiungere il consenso. Tuttavia, le nuove catene eterogenee spesso non riescono ad attrarre grandi impegni di capitale, sollevando dubbi sulla loro sicurezza. Nell’attuale era della modularità, le zone Cosmos e varie soluzioni Layer 2 possono utilizzare vari livelli DA per compensare, ma ciò spesso va a scapito dell’autonomia. Anche l’utilizzo di Ethereum o Celestia come livello DA è generalmente poco pratico per la maggior parte dei meccanismi PoS o delle catene di consorzi più vecchi. Il valore di Babylon sta nel colmare questa lacuna fornendo protezione alla catena PoS utilizzando lo staking di BTC. Proprio come gli esseri umani usano l’oro per sostenere il valore della carta moneta, Bitcoin è perfettamente adatto a svolgere questo ruolo nel mondo blockchain.

da 0 a 1

Sbloccare l’“oro digitale” è sempre stato l’obiettivo più ambizioso ma più sfuggente nel campo della blockchain. Dalle prime sidechain, Lightning Network e token bridge fino alle Rune e al BTC Layer 2 di oggi, ogni soluzione ha i suoi difetti intrinseci. Se Babylon mira a sfruttare la sicurezza di Bitcoin, bisogna innanzitutto escludere soluzioni centralizzate che introducono un presupposto di fiducia da parte di terzi. Tra le restanti opzioni, Rune e Lightning Network (limitate da un avanzamento dello sviluppo estremamente lento) attualmente hanno solo la possibilità di emettere risorse. Ciò significa che Babylon deve progettare la propria “soluzione di scalabilità” per abilitare lo staking nativo di Bitcoin da 0 a 1.

Analizzando gli elementi base attualmente disponibili in Bitcoin, sono essenzialmente i seguenti: 1. Modello UTXO, 2. Timestamp, 3. Vari metodi di firma, 4. Codici operativi di base. Data la limitata programmabilità e capacità di trasporto dati di Bitcoin, la soluzione di Babylon si basa su principi minimalisti. Su Bitcoin, è necessario completare solo le funzioni di base del contratto di staking, il che significa che lo staking, il taglio, i premi e il recupero di BTC sono tutti gestiti sulla catena principale. Una volta raggiunto questo rapporto 0 a 1, la zona Cosmos può gestire requisiti più complessi. Tuttavia, rimane ancora una domanda chiave: come registrare i dati della catena PoS sulla catena principale?

Staking remoto

UTXO (Unspent Transaction Outputs) è un modello di transazione progettato da Satoshi Nakamoto per Bitcoin. L’idea di base è molto semplice: le transazioni sono solo l’entrata e l’uscita di fondi, quindi l’intero sistema commerciale può essere rappresentato in termini di input e output. Gli UTXO rappresentano la parte di fondi entrati ma non completamente spesi, e quindi rimangono come output di transazioni non spesi (cioè Bitcoin non pagati). L'intero registro Bitcoin è essenzialmente una raccolta di UTXO, che registra lo stato di ciascun UTXO per gestire la proprietà e la circolazione dei Bitcoin. Ogni transazione spende un vecchio UTXO e genera un nuovo UTXO. Grazie al loro potenziale di scalabilità intrinseco, UTXO è un punto di partenza naturale per molte soluzioni di scalabilità nativa. Per esempio,

Babylon deve anche utilizzare UTXO per implementare il contratto Stake (Babylon si chiama remote Stake, che trasmette in remoto la sicurezza di Bitcoin alla catena PoS attraverso lo strato intermedio). L’implementazione del contratto può essere suddivisa in quattro fasi, combinando abilmente i codici operativi esistenti:

Blocca i fondi

Gli utenti inviano fondi a indirizzi controllati da firme multiple. Attraverso OP_CTV (OP_CHECKTEMPLATEVERIFY, che consente la creazione di modelli di transazione predefiniti, garantendo che le transazioni possano essere eseguite solo secondo strutture e condizioni specifiche), il contratto può specificare che questi fondi possono essere utilizzati solo a determinate condizioni. Una volta bloccati i fondi, viene generato un nuovo UTXO che indica che i fondi sono stati picchettati.

Verifica condizionale

I blocchi temporali possono essere implementati chiamando OP_CSV (OP_CHECKSEQUENCEVERIFY, che consente di impostare un blocco temporale relativo in base al numero di sequenza della transazione, indicando che UTXO può essere speso solo dopo un certo tempo relativo o numero di blocchi). In combinazione con OP_CTV, è possibile ottenere staking, unstaking (consentendo allo staker di spendere l'UTXO bloccato dopo che è stato raggiunto il periodo di impegno) e slashing (forzando l'UTXO a essere speso all'indirizzo bloccato, rendendolo non spendibile se lo staker si comporta in modo dannoso). , simile all'indirizzo di un buco nero).

aggiornamento dello stato

Ogni volta che un utente punta o ritira i fondi puntati, viene creato e speso un UTXO. I nuovi output delle transazioni generano nuovi UTXO e i vecchi UTXO vengono contrassegnati come spesi. In questo modo ogni transazione e movimento finanziario viene accuratamente registrato sulla blockchain, garantendo trasparenza e sicurezza.

Distribuzione della ricompensa

Il contratto calcola i premi in base all'importo puntato e al periodo di puntata e li distribuisce generando nuovi UTXO. Questi premi possono essere sbloccati e spesi tramite condizioni predefinite una volta soddisfatte determinate condizioni.

Timestamp

Stabilito il contratto di Palo originario, è naturale porsi il problema della registrazione degli eventi storici della filiera esterna. Nel white paper di Satoshi Nakamoto, la blockchain di Bitcoin ha introdotto il concetto di timestamp supportato da PoW, fornendo un ordine cronologico irreversibile degli eventi. Nel caso d'uso nativo di Bitcoin, questi eventi si riferiscono a varie transazioni eseguite sul registro. Oggi, per migliorare la sicurezza di altre catene PoS, Bitcoin può essere utilizzato anche per timestamp di eventi su blockchain esterne. Ogni volta che si verifica un evento del genere, viene attivata una transazione che viene inviata al miner, che poi la inserisce nel registro Bitcoin, aggiungendo così un timestamp all'evento. Questi timestamp possono risolvere vari problemi di sicurezza della blockchain. Il concetto generale di timestamp degli eventi in una catena figlia su una catena genitore è chiamato "checkpoint" e le transazioni utilizzate per timestamp sono chiamate transazioni checkpoint. Nello specifico, i timestamp nella blockchain di Bitcoin hanno le seguenti importanti caratteristiche:

  • Formato ora: un timestamp registra il numero di secondi dal 1 gennaio 1970 alle 00:00:00 UTC. Questo formato è chiamato ora Unix o ora POSIX.

  • Scopo: lo scopo principale del timestamp è contrassegnare il tempo di generazione dei blocchi, aiutare i nodi a determinare l'ordine dei blocchi e assistere il meccanismo di regolazione della difficoltà della rete.

  • Timestamp e aggiustamenti della difficoltà: la rete Bitcoin aggiusta la difficoltà di mining circa ogni due settimane o ogni blocco del 2016. I timestamp svolgono un ruolo cruciale in questo processo, poiché la rete regola la difficoltà in base al tempo di generazione totale degli ultimi blocchi del 2016 per garantire che nuovi blocchi vengano generati circa ogni 10 minuti.

  • Controllo di validità: quando un nodo riceve un nuovo blocco, verifica il timestamp. Il timestamp del nuovo blocco deve essere maggiore del tempo mediano dei blocchi precedenti e non deve superare il tempo di rete di oltre 120 minuti (2 ore in futuro).

Il server timestamp è una nuova primitiva definita da Babylon, che può distribuire i timestamp Bitcoin attraverso i checkpoint Babylon nei blocchi PoS, garantendo l'accuratezza e la non manomissione delle serie temporali. Essendo lo strato superiore dell'intera architettura di Babylon, questo server è la principale fonte di fiducia.

L’architettura a tre livelli di Babilonia

Come mostrato nella figura, l'architettura complessiva di Babylon può essere divisa in tre strati: Bitcoin (come server di timestamp), Babylon (come Cosmos Zone come strato intermedio) e la catena PoS come strato di domanda. Babylon si riferisce a questi ultimi due come al piano di controllo (Babilonia stessa) e al piano dati (varie catene di consumo PoS).

Ora che abbiamo compreso l'implementazione trustless di base del protocollo, analizziamo il modo in cui Babylon stessa utilizza le zone Cosmos per connettere le due estremità. Secondo una spiegazione dettagliata del Tse Lab dell'Università di Stanford su Babylon, Babylon può ricevere flussi di checkpoint da più catene PoS e unire questi checkpoint per la pubblicazione su Bitcoin. La dimensione del checkpoint può essere ridotta al minimo utilizzando firme aggregate dai validatori Babylon e la frequenza di questi checkpoint può essere controllata consentendo ai validatori Babylon di cambiare solo una volta per epoca.

I validatori di varie catene PoS scaricano i blocchi Babylon per verificare se i loro checkpoint PoS sono inclusi nei blocchi Babylon controllati da Bitcoin. Ciò consente alla catena PoS di rilevare discrepanze, ad esempio se un validatore Babylon creasse un blocco non disponibile convalidato da Bitcoin e mentisse sui checkpoint PoS contenuti al suo interno. Gli elementi principali dell’accordo sono i seguenti:

· Checkpoint: Bitcoin verifica solo l'ultimo blocco dell'era babilonese. Un checkpoint è costituito dall’hash di un blocco e da una singola firma BLS aggregata, corrispondente alle firme della maggioranza dei due terzi dei validatori che firmano la definitività sul blocco. Babylon Checkpoint include anche Anno. Ai blocchi PoS possono essere assegnati timestamp Bitcoin tramite i checkpoint Babylon. Ad esempio, i primi due blocchi PoS vengono checkpointati dal blocco Babylon e poi dal blocco Bitcoin con timestamp t_3. Pertanto, a questi blocchi PoS viene assegnato il timestamp Bitcoin t_3.

· Catena PoS canonica: quando una catena PoS si biforca, la catena con un timestamp precedente è considerata la catena PoS canonica. Se due fork hanno lo stesso timestamp, il pareggio verrà risolto a favore del blocco PoS dal checkpoint precedente su Babylon.

· Regole di prelievo: per prelevare denaro, il verificatore invia una richiesta di prelievo alla catena PoS. Il blocco PoS contenente la richiesta di prelievo verrà poi checkpoint da Babylon e successivamente da Bitcoin, che gli assegnerà un timestamp t_1. I prelievi vengono approvati sulla catena PoS una volta che il blocco Bitcoin con timestamp t_1 raggiunge la profondità k. Se un validatore in ritirata tenta un attacco remoto, ai blocchi sulla catena attaccante possono essere assegnati solo timestamp successivi a t_1. Questo perché una volta che il blocco Bitcoin con timestamp t_1 raggiunge la profondità k, non può essere ripristinato. Osservando l'ordine di questi checkpoint su Bitcoin, i clienti PoS possono distinguere tra catene canoniche e di attacco e ignorare queste ultime.

· Regole di riduzione: se i validatori non ritirano la loro puntata dopo che viene rilevato un attacco, potrebbero essere ridotti per aver firmato doppiamente blocchi PoS in conflitto. I validatori PoS dannosi sanno che se aspettano che una richiesta di prelievo venga approvata prima di lanciare un attacco remoto, non saranno in grado di ingannare i clienti che possono fare riferimento a Bitcoin per identificare la catena canonica. Pertanto, potrebbero biforcare la catena PoS assegnando al contempo i timestamp Bitcoin ai blocchi sulla catena PoS canonica. Questi validatori PoS hanno collaborato con validatori Babylon dannosi e minatori Bitcoin per creare un fork di Babylon e Bitcoin, sostituendo il blocco Bitcoin con timestamp t_2 con un altro blocco con timestamp t_3. Agli occhi dei successivi clienti PoS, questo cambierà la catena PoS canonica dalla catena superiore alla catena inferiore. Anche se questo è stato un attacco alla sicurezza riuscito.

· La regola di sospensione del checkpoint PoS non è disponibile: i validatori PoS devono mettere in pausa la catena PoS quando osservano un checkpoint PoS non disponibile su Babylon. Un checkpoint PoS non disponibile è definito come un hash firmato da due terzi dei validatori PoS che presumibilmente corrisponde a un blocco PoS non osservabile. Se il validatore PoS non mette in pausa la catena PoS quando osserva un checkpoint non disponibile, un utente malintenzionato può rivelare una catena di attacco precedentemente non disponibile, modificando così la catena canonica nelle future visualizzazioni del client. Questo perché il punto di controllo della Catena dell'Ombra, successivamente rivelato essere avvenuto in precedenza a Babilonia. Le regole di pausa di cui sopra spiegano perché richiediamo che gli hash dei blocchi PoS inviati come checkpoint siano firmati dal set di validatori PoS. Se questi checkpoint non sono firmati, qualsiasi utente malintenzionato può inviare un hash arbitrario sostenendo che si tratta dell'hash di un checkpoint del blocco PoS che non è disponibile su Babylon. Il validatore PoS deve quindi fermarsi al checkpoint. Tieni presente che la creazione di una catena PoS inutilizzabile è impegnativa: richiede il compromesso di almeno due terzi dei validatori PoS per accedere ai blocchi PoS senza fornire dati a validatori onesti. Tuttavia, nell’ipotetico attacco di cui sopra, un avversario malintenzionato ha bloccato la catena PoS senza compromettere un singolo validatore. Per prevenire tali attacchi, richiediamo che i checkpoint PoS siano firmati da due terzi dei validatori PoS. Pertanto, non ci saranno checkpoint PoS non disponibili su Babylon a meno che due terzi dei validatori PoS non siano compromessi, il che è estremamente improbabile a causa del costo della compromissione dei validatori PoS, e non influenzerà altre catene PoS o Babylon stessa. È necessario che almeno due terzi dei validatori PoS firmino un blocco PoS senza fornire dati a validatori onesti. Tuttavia, nell’ipotetico attacco di cui sopra, un avversario malintenzionato ha bloccato la catena PoS senza compromettere un singolo validatore. Per prevenire tali attacchi, richiediamo che i checkpoint PoS siano firmati da due terzi dei validatori PoS. Pertanto, non ci saranno checkpoint PoS non disponibili su Babylon a meno che due terzi dei validatori PoS non siano compromessi, il che è estremamente improbabile a causa del costo della compromissione dei validatori PoS, e non influenzerà altre catene PoS o Babylon stessa.È necessario che almeno due terzi dei validatori PoS firmino un blocco PoS senza fornire dati a validatori onesti. Tuttavia, nell’ipotetico attacco di cui sopra, un avversario malintenzionato ha bloccato la catena PoS senza compromettere un singolo validatore. Per prevenire tali attacchi, richiediamo che i checkpoint PoS siano firmati da due terzi dei validatori PoS.

· La regola di pausa del checkpoint Babylon non è disponibile: sia i validatori PoS che quelli Babylon devono mettere in pausa la blockchain quando osservano un checkpoint Babylon che non è disponibile su Bitcoin. Un checkpoint Babylon non disponibile è definito come un hash delle firme BLS aggregate di due terzi dei validatori Babylon che presumibilmente corrisponde a un blocco Babylon non osservabile. Se i validatori Babylon non sospendono la blockchain Babylon, un utente malintenzionato potrebbe far trapelare una catena Babylon precedentemente non disponibile, modificando così la catena canonica Babylon nelle future visualizzazioni dei client. Allo stesso modo, se il validatore PoS non mette in pausa la catena PoS, un utente malintenzionato può rivelare una catena di attacco PoS precedentemente non disponibile e una catena Babylon precedentemente non disponibile, modificando così la catena PoS canonica nelle visualizzazioni future dei client. Questo perché la catena profonda Babylon rivelata successivamente aveva un timestamp precedente su Bitcoin e conteneva checkpoint della catena di attacco PoS rivelata successivamente. Similmente alle regole per la pausa sui checkpoint PoS non disponibili, questa regola spiega perché richiediamo che gli hash di blocco Babylon inviati come checkpoint abbiano firme BLS aggregate, dimostrando le firme di due terzi dei validatori Babylon. Se il checkpoint Babylon non è firmato, qualsiasi avversario può inviare un hash arbitrario sostenendo che si tratta dell'hash del checkpoint del blocco Babylon che non è disponibile su Bitcoin. I validatori PoS e i validatori Babylon devono quindi attendere un checkpoint senza una catena Babylon o PoS non disponibile nella loro preimmagine. Per creare una catena Babylon non disponibile è necessario compromettere almeno due terzi dei validatori Babylon. Tuttavia, nell’ipotetico attacco di cui sopra, l’avversario ferma tutte le catene del sistema senza influenzare un singolo validatore Babylon o PoS. Per prevenire tali attacchi, richiediamo che i checkpoint Babylon siano attestati da firme aggregate; pertanto, non ci saranno checkpoint Babylon inutilizzabili a meno che due terzi dei validatori non siano compromessi, il che, a causa del costo della compromissione dei validatori Babylon, questa possibilità è estremamente ridotta. Ma in casi estremi, colpisce tutte le catene PoS costringendole a fermarsi.

Livello di funzionalità in BTC

Babylon è simile a Eigenlayer in termini di scopo, ma è ben lungi dall'essere un semplice "fork" di Eigenlayer. Dato che DA non può essere utilizzato in modo nativo sulla catena principale di BTC, l’esistenza di Babylon è piuttosto importante. Il protocollo non solo porta sicurezza alle catene PoS esterne, ma è anche fondamentale per rivitalizzare l’ecosistema BTC internamente.

caso d'uso

Babylon offre molti potenziali casi d’uso, alcuni dei quali sono già stati implementati o potrebbero avere l’opportunità di essere implementati in futuro:

  1. Riduci il periodo di staking e migliora la sicurezza: le catene PoS in genere richiedono il consenso sociale (accordo tra la comunità, gli operatori dei nodi e i validatori) per prevenire attacchi remoti. Questi attacchi comportano la riscrittura della storia della blockchain per manipolare i record delle transazioni o controllare la catena. Gli attacchi remoti sono particolarmente gravi nei sistemi PoS perché, a differenza del PoW, i sistemi PoS non richiedono che i validatori consumino grandi quantità di risorse di elaborazione. Un utente malintenzionato può riscrivere la storia controllando le chiavi dei primi staker. Per garantire la stabilità e la sicurezza del consenso della rete blockchain, generalmente è necessario un ciclo di impegno più lungo. Ad esempio, Cosmos richiede un periodo di svincolo di 21 giorni. Tuttavia, con Babylon, gli eventi storici della catena PoS possono essere incorporati nei server di timestamp BTC, utilizzando BTC come fonte di fiducia per sostituire il consenso sociale. Ciò può ridurre il tempo di svincolo a un giorno (equivalente a circa 100 blocchi BTC). Inoltre, la catena PoS può raggiungere una doppia sicurezza attraverso lo staking di token nativi e lo staking di BTC.

  • Interoperabilità incrociata: attraverso il protocollo IBC, Babylon può ricevere dati di checkpoint da più catene PoS, ottenendo così l'interoperabilità incrociata. Questa interoperabilità consente una comunicazione continua e la condivisione dei dati tra diverse blockchain, aumentando così l’efficienza e la funzionalità complessive dell’ecosistema blockchain.

  • Integrare l'ecosistema BTC: la maggior parte dei progetti nell'attuale ecosistema BTC, inclusi Layer 2, LRT e DeFi, mancano di sicurezza sufficiente e spesso si basano su presupposti di fiducia di terze parti. Questi protocolli memorizzano anche grandi quantità di BTC nei loro indirizzi. In futuro, Babylon potrebbe sviluppare alcune soluzioni altamente compatibili con questi progetti, creando vantaggi reciproci e eventualmente formando un forte ecosistema simile a Eigenlayer all’interno di Ethereum.

  • Gestione delle risorse a catena incrociata: il protocollo Babylon può essere utilizzato per la gestione sicura delle risorse a catena incrociata. Aggiungendo timestamp alle transazioni cross-chain, sono garantite la sicurezza e la trasparenza dei trasferimenti di asset tra diverse blockchain. Questo meccanismo aiuta a prevenire la doppia spesa e altri attacchi cross-chain.

Torre di Babele

La storia della Torre di Babele ha origine da Genesi 11:1-9 nella Bibbia. È una storia classica di esseri umani che cercano di costruire la Torre di Babele ma vengono ostacolati da Dio. Questa storia simboleggia l’unità umana e lo scopo comune. Il protocollo Babylon mira a costruire una torre simile per varie catene PoS, unificandole sotto lo stesso tetto. In termini narrativi sembra essere bravo quanto Eigenlayer, il difensore di Ethereum. Ma come funziona in pratica?

Ad oggi, il testnet Babylon ha fornito sicurezza a 50 zone Cosmos attraverso il protocollo IBC. Oltre all'ecosistema Cosmos, Babylon integra anche diversi protocolli LSD (Liquid Collateralized Derivatives), protocolli di interoperabilità a catena intera e protocolli dell'ecosistema Bitcoin. Tuttavia, per quanto riguarda lo staking, Babylon è attualmente in ritardo rispetto a Eigenlayer, che può riutilizzare Stake e LSD all’interno dell’ecosistema Ethereum. Ma sul lungo termine, la grande quantità di Bitcoin dormiente nei portafogli e nei protocolli deve ancora essere completamente risvegliata, e questa è solo la punta dell’iceberg da 1,3 trilioni di dollari. Babylon deve formare una simbiosi benevola con l’intero ecosistema BTC.

L'unica soluzione al dilemma di Ponzi

Come accennato in precedenza, sia Eigenlayer che Babylon si stanno sviluppando rapidamente e le tendenze future indicano che bloccheranno un gran numero di asset blockchain fondamentali. Anche se i protocolli stessi sono sicuri, lo staking multilivello creerà una spirale mortale per l’ecosistema dello staking, portando a un collasso simile a un altro aumento dei tassi di interesse negli Stati Uniti? Dalla transizione di Ethereum al PoS e dall’emergere di Eigenlayer, l’attuale settore degli stake ha effettivamente sperimentato un’esuberanza irrazionale. I progetti spesso attirano utenti TVL elevati attraverso enormi aspettative di airdrop e rendimenti graduali. Un ETH può passare attraverso staking nativo, LSD e LRT, con un massimo di cinque o sei stack. Questo accumulo aumenta il rischio, poiché i problemi in qualsiasi protocollo possono avere un impatto diretto su tutti i protocolli coinvolti, specialmente quelli alla fine della catena di staking. Ecosistema Bitcoin,

Tuttavia, vale la pena notare che Eigenlayer e Babylon mirano fondamentalmente a indirizzare il volano dello staking verso una vera utilità, creando una domanda reale per compensare il rischio. Pertanto, sebbene questi protocolli di “sicurezza condivisa” possano indirettamente o direttamente esacerbare comportamenti scorretti, sono anche l’unico modo per evitare rendimenti derivanti da schemi Ponzi con staking a più livelli. La domanda più urgente ora è se la logica aziendale di un protocollo di “sicurezza condivisa” sia effettivamente fattibile.

I bisogni reali sono fondamentali

Nel Web3, che si tratti di una catena pubblica o di un protocollo, la logica sottostante spesso prevede l'abbinamento di acquirenti e venditori per esigenze specifiche. In questo modo, puoi “vincere il mondo” perché la tecnologia blockchain garantisce che il processo di abbinamento sia giusto, autentico e credibile. In teoria, i protocolli di sicurezza condivisi potrebbero integrare il fiorente ecosistema modulare e di staking. Tuttavia, l’offerta supererà di gran lunga la domanda? Dal lato dell’offerta, sono molti i progetti e le principali filiere in grado di fornire sicurezza modulare. Dal lato della domanda, le catene PoS consolidate potrebbero non aver bisogno o non essere disposte a noleggiare tali titoli per motivi di facciata, mentre le nuove catene PoS potrebbero avere difficoltà a pagare gli interessi generati da grandi quantità di BTC ed ETH. Lasciamo che Eigenlayer e Babylon formino un ciclo commerciale chiuso e che il reddito generato debba bilanciare gli interessi generati dai token promessi nel protocollo. Anche se questo equilibrio venisse raggiunto e le entrate superassero di gran lunga i pagamenti degli interessi, ciò potrebbe comunque causare l’esaurimento di queste nuove catene e protocolli PoS. Pertanto, sarà cruciale come bilanciare il modello economico, evitare bolle causate dalle aspettative di airdrop e guidare in modo sano domanda e offerta.

#Bitcoin #Ethereum