Le sidechain federate sono l'implementazione originale della sidechain aggiornabile di Bitcoin

Questo è un editoriale di opinione di Shinobi, un educatore autodidatta nello spazio Bitcoin e host di podcast Bitcoin orientato alla tecnologia.

Sidechain federate sono attualmente l'unico tipo distribuito di sidechain Bitcoin (il documento più recente qui). L'idea di utilizzare un sistema federato di peg e consenso era in realtà un'appendice del whitepaper originale sulle sidechain. Non esisteva un progetto concreto per qualsiasi tipo di peg bidirezionale che coinvolgesse i minatori, quindi un peg federato è stato descritto come un modo per implementare subito una sidechain e passare a un peg verificato a due vie utilizzando prove SPV (semplici verifiche di pagamento) simili a Che cosa softchains fare, quando è stato concretamente progettato qualcosa che fosse sicuro e dispiegabile. È stato anche sottolineato che in termini di incentivi, per sistemi molto piccoli potrebbe essere pericoloso utilizzare un ancoraggio basato sui minatori poiché potrebbero rubare a un gruppo molto piccolo di persone senza molto consenso sul fare qualcosa al riguardo dal più ampio sistema Bitcoin. . Le federazioni potrebbero essere utili per i sistemi più piccoli in cui il gruppo di utenti non è abbastanza grande da disincentivare i minatori a rubare monete.

L'idea generale è quella di avere effettivamente una blockchain in cui un gruppo selezionato di parti fidate custodisce bitcoin ancorati al sistema utilizzando multisig e produce i blocchi sulla sidechain, firmandoli con chiavi crittografiche invece di utilizzare prove di lavoro. L’intero modello di sicurezza si basa sulla presenza di un insieme abbastanza ampio di partecipanti distinti nel gruppo, o federazione, distribuiti geograficamente e conosciuti pubblicamente.

Le federazioni utilizzano una soglia di membri sia per la custodia dei bitcoin sulla catena principale che per il blocksigning, ovvero un multisig 5 su 7. Questo viene fatto invece di richiedere la firma a tutti e sette i membri per bilanciare i due principali rischi di un tale sistema: furto contro perdita. La federazione insieme può rubare tutti i fondi bloccati in una sidechain federata se scelgono di cooperare insieme per farlo; questo è il motivo per cui l’intero modello di sicurezza si basa su molti attori diversi in molte giurisdizioni legali diverse. Vuoi che sia estremamente difficile e improbabile che molti governi diversi collaborino per costringere una federazione a fare qualcosa di dannoso, quindi vuoi che sia necessario un gran numero di persone per firmare le cose. D'altra parte, se richiedi a tutti e sette i membri di firmare tutto, allora basta che un singolo membro perda l'accesso alle proprie chiavi con conseguente perdita permanente di tutti i fondi nella sidechain. Quindi è necessario che firmi la maggioranza dei membri, ma non tutti. Ciò lascia un certo margine di errore per la perdita delle chiavi, pur richiedendo comunque che un numero elevato di membri venga costretto o cospiri per provocare un furto di fondi.

Ciò rende il modello di sicurezza del sistema bidirezionale in termini di soglie di sicurezza. Come affermato in precedenza, affinché i fondi vengano attivamente rubati, cinque dei sette partecipanti in questa ipotetica situazione devono colludere o essere costretti a colludere per rubare i fondi della sidechain. Tuttavia, solo tre dei sette partecipanti devono perdere, distruggere o essere costretti a disabilitare le proprie chiavi per lasciare i fondi della sidechain congelati e impossibilitati a essere spostati, possibilmente in modo permanente. Le soglie rappresentano un atto di bilanciamento tra questi due rischi.

Entrambi devono essere sufficientemente elevati contemporaneamente per rendere improbabile il verificarsi di entrambi i casi peggiori.

A parte queste proprietà fondamentali, esiste un ampio grado di libertà nel modo in cui è possibile implementare una sidechain federata, sia in termini di come progettare la sidechain stessa sia di come gestire la gestione delle chiavi per la firma dei blocchi e le chiavi di custodia dei peg.

Liquido

Liquid è stata la prima sidechain federata implementata su Bitcoin, progettata per transazioni private tra scambi per il trading e l'emissione di altri asset come stablecoin o equity token. La sua base di codice è costruita quasi interamente su quella dello stesso Bitcoin. Una delle caratteristiche principali della rete Liquid è stata l'implementazione di Transazioni riservate, una funzionalità che utilizza prove di intervallo crittografiche per nascondere gli importi inviati nelle transazioni ma fornire comunque una garanzia, sotto determinati presupposti, che non venga speso denaro che non esiste. Implementato anche il liquido Attività riservate, un'estensione alle transazioni riservate. Risorse riservate nasconde quale token viene speso oltre all'importo.

Queste due caratteristiche combinate forniscono una soluzione efficace a uno dei maggiori difetti possibili con una sidechain federata: la censura. Una soglia di maggioranza (nella nostra ipotetica federazione 5 su 7 di cui sopra) potrebbe tutti concordare di censurare transazioni specifiche o UTXO se tutti ne avessero motivo, come attività illegali sospette o confermate. In tal caso avrebbero anche un incentivo razionale a farlo, per non dare ai governi un motivo per perseguire l’intero sistema. Le transazioni/risorse riservate possono fornire un livello di privacy sufficientemente elevato che, anche se una federazione avesse motivo di censurare determinati tipi di transazioni, avrebbe difficoltà a selezionarle per farlo.

Una transazione peg-in su Liquid è un processo relativamente semplice in due fasi. Un utente che desidera effettuare il peg-in prende l'indirizzo multisig della federazione e poi "modifica" ciascuna chiave pubblica coinvolta utilizzando pagamento a contratto con un indirizzo Liquid che controllano, per creare nuove chiavi pubbliche. I membri della federazione possono ricavare le chiavi private corrispondenti una volta appreso l'indirizzo Liquid utilizzato. Fino a quando tali informazioni non verranno rivelate nessuno, nemmeno la federazione, sa che una transazione a questo indirizzo modificato è un peg-in di Liquid. Quindi l'utente trasmette la transazione sulla catena principale e attende 100 conferme. Una volta accumulate le conferme, l'utente può inviare una transazione sulla rete Liquid per inviare a se stesso le proprie monete. Questa transazione utilizza un input speciale che contiene l'indirizzo Liquid con cui hanno modificato le chiavi della federazione, una firma che dimostra che la controllano e una prova Merkle che mostra che la transazione peg-in della mainchain ha almeno 100 conferme.

Il processo di peg-out è molto più semplice. Un utente costruisce una transazione che brucia bitcoin su Liquid utilizzando OP_RETURN, contiene un indirizzo a cui inviare sulla catena principale e una speciale prova a conoscenza zero da uno dei membri della federazione (quale è nascosto). Quando i membri della federazione vedranno tale transazione con una prova di membro valida, firmeranno un ritiro sulla catena principale. La prova è implementata per prevenire prelievi fraudolenti o non validi e consente a qualunque membro della federazione fornisca la prova di applicare la whitelist o le restrizioni sui peg-out. Chiunque può agganciare liberamente bitcoin alla rete Liquid, ma per agganciarlo è necessaria una relazione con un membro della federazione.

In termini di gestione delle chiavi e gestione della sicurezza, Blockstream ha sviluppato moduli di sicurezza hardware (HSM) per gestire le chiavi ed eseguire operazioni di firma. Questi dispositivi proteggono le chiavi utilizzate per la firma dei blocchi e i peg-in/out, proteggendole da manomissioni o estrazione delle chiavi. Al fine di fornire alcuni mezzi di ripristino nel caso in cui i dispositivi guasti perdano le chiavi, ma anche per proteggere dall'estrazione delle chiavi per scopi dannosi, i backup di ciascuna chiave membro vengono mantenuti crittografati in modo da richiedere sia a quel membro che a Blockstream di collaborare per decrittografare la chiave per caricarla in un nuovo HSM. Nessuna delle parti può decrittografare il backup da sola. Un'ultima linea di difesa contro la perdita delle chiavi sono le chiavi di prelievo di emergenza. Ogni indirizzo a cui la federazione invia le monete peg-in ha due percorsi di spesa: la soglia richiesta dalla federazione e, dopo circa un mese di blocco temporale (anche se il periodo di tempo potrebbe essere modificato) la soglia richiesta delle chiavi di emergenza. Si tratta di un secondo set di chiavi che può essere mantenuto dalla federazione, da un altro soggetto o da una combinazione di essi per garantire che le monete possano essere recuperate in caso di smarrimento di troppe chiavi della federazione. La federazione sposta regolarmente le monete sulla mainchain in sua custodia prima della scadenza del timelock, quindi finché la federazione non avrà fallito, questo percorso di emergenza non sarà mai spendibile. Attualmente Blockstream mantiene le chiavi di ripristino distribuite geograficamente.

Infine esiste una funzionalità chiamata “Federazioni dinamiche”. Ciò consente alla grande maggioranza della federazione di aggiornare i membri, aggiungendo o rimuovendo membri. Ciò avviene tramite un aggiornamento del software di firma dopo aver deciso quali nuovi membri aggiungere o quali esistenti rimuovere e quindi un periodo di segnalazione di un mese. Se, per un mese, quattro quinti dei blocchi segnalati per la federazione cambiano, la rete si “biforca” per riconoscere la nuova federazione come firmatari del blocco. La rete inizia quindi a utilizzare nuovi indirizzi di collegamento con la nuova federazione, ma riconosce comunque quelli vecchi per un ulteriore mese per garantire che nessun collegamento venga invalidato durante il cambio di federazione. Inoltre, non è consentito rimuovere così tanti membri della federazione che non ce ne siano abbastanza per firmare per i ritiri dai vecchi indirizzi. Tutti questi aspetti degli aggiornamenti della federazione fanno parte delle regole di consenso e vengono applicati/convalidati dagli HSM.

Portinnesto (RSK)

Rootstock è una sidechain federata con molte differenze di progettazione rispetto a Liquid. Innanzitutto, è essenzialmente un clone copia-incolla di Ethereum in termini di funzionalità. Supporta pienamente Solidity, il linguaggio di scripting utilizzato da Ethereum, in modo che qualsiasi contratto distribuito su Ethereum sia banalmente trasferibile su Rootstock. La logica alla base di ciò è ovviamente che Ethereum ha molta domanda e può fornire funzionalità di cui Bitcoin non è in grado. Ovviamente, ci sono molti aspetti negativi e rischi per l'architettura di Ethereum, ma non si può negare che ce ne sia richiesta.

Un'altra grande differenza in termini di architettura è ciò che fa la federazione: gestiscono collettivamente un multisig che custodisce i fondi sulla catena principale, ma in circostanze normali la federazione non partecipa ai blocchi di conio. Ciò viene fatto dai minatori di Bitcoin attraverso il mining combinato, consentendo loro di estrarre Bitcoin e Rootstock contemporaneamente. Sebbene ciò non fornisca alcuna differenza significativa in termini di sicurezza per Bitcoin ancorati alla catena Rootstock, ne fornisce alcune per altri asset emessi sulla sidechain. La federazione può sempre rubare i Bitcoin sulla catena principale in caso di collusione sufficiente, ma poiché i minatori effettivamente estraggono la catena laterale, possono continuare e consentire che le altre risorse continuino a essere oggetto di transazioni. Se questi altri asset avessero abbastanza valore, anche senza essere supportati da bitcoin reali, il token Rootstock BTC dovrebbe comunque avere una domanda di mercato sufficiente per pagare commissioni per utilizzare altri asset per incentivare i minatori a continuare il mining.

Tuttavia, il coinvolgimento dei minatori non è assoluto. Finché la maggioranza dei minatori Bitcoin estrae anche Rootstock, ha il controllo totale dell'organizzazione delle transazioni e dell'estrazione in blocchi, ma se quella percentuale di minatori scende nell'intervallo della metà (o leggermente inferiore), esistono regole di consenso che consentono la federazione firmerà dei checkpoint che impediscano le riorganizzazioni prima del checkpoint. Se l'hash rate scende in modo più drastico, sono persino in grado di assumere il ruolo di blocksigner, come i membri della federazione di Liquid. È un sistema molto dinamico che può funzionare sia senza miner che senza federazione per far avanzare la blockchain.

Il processo di peg-in è molto semplice: invia bitcoin all'indirizzo di peg-in RSK e poi attendi sufficienti conferme. Dopo che si sono accumulate sufficienti conferme, uno smart contract Solidity sulla sidechain riconoscerà la transazione e la accrediterà su un conto sulla sidechain controllato dalla stessa chiave a cui era bloccato l'UTXO a cui ti sei collegato. Il pegging-out è anche controllato da un contratto intelligente, che comunicherà con gli HSM della federazione, che firmeranno una transazione di ritiro dalla catena principale quando richiesto dal contratto.

Quando Roostock lanciò per la prima volta, tutto ciò che era necessario per stabilizzarsi era che la maggioranza degli HSM della federazione firmassero la transazione dopo essere stati informati dal contratto intelligente sulla sidechain. Nel 2020 hanno implementato un nuovo meccanismo di ancoraggio chiamato POWPeg. Questo aggiornamento ha consentito agli HSM di convalidare effettivamente le prove SPV dei minatori. Gli HSM ora si rifiutano di firmare transazioni di peg-out a meno che la maggioranza dell’attuale gruppo di minatori RSK non si basi sulla transazione dall’avvio del peg-out. Il modello di sicurezza in definitiva si riduce al fatto che gli HSM rimangono sicuri, ma a meno che la maggior parte di essi non venga manomessa e le chiavi estratte, non firmeranno senza una sufficiente prova di lavoro che attesti i peg-out.

Chiudi

Le persone lavorano alla progettazione di sidechain ormai da otto anni e mentre noi essere andato fino alle quattro diversi progetti (e ce ne sono alcuni altri là fuori: questi sono solo quelli che hanno ottenuto popolarità tra i Bitcoiner tecnici), non c'è nulla attualmente implementato tranne le catene federate. I sistemi federati potrebbero non essere la sidechain trustless che molte persone desiderano, ma sono comunque sistemi molto utili, specialmente in qualsiasi contesto in cui l’unico modo per soddisfare una domanda di mercato è fidarsi di un singolo custode per arbitrare qualcosa. Le federazioni diventano immediatamente un miglioramento predefinito distribuendo il rischio di controparte su più giocatori.

Bene, queste sono le sidechain federate in poche parole. L'ultimo pezzo in arrivo riguarda tutti gli aspetti negativi e negativi delle principali proposte attuali, almeno alcune riflessioni di alto livello su ciò che le persone vogliono veramente da una sidechain "perfetta" e su come potenzialmente ottenerlo.

Questo è un guest post di Shinobi. Le opinioni espresse sono interamente proprie e non riflettono necessariamente quelle di BTC Inc o Bitcoin Magazine.