Recentemente, Babylon ha lanciato un evento di staking di Bitcoin su Testnet-4, innescando discussioni nella comunità sullo staking di Bitcoin. Oggi, il team di Chakra Research ti guiderà attraverso le ultime opzioni di staking di Bitcoin.

Nel recente Testnet-4 di Babylon, il processo di staking è diviso in tre tipi di transazioni: Staking Tx, Unbonding Tx e Slashing Tx. Queste transazioni generano tre tipi di output Bitcoin: output di staking, output di unbonding e output di taglio. Il processo di conversione è mostrato nella figura seguente.

Transazione di pegno

Le transazioni di puntata devono includere due uscite speciali. Uno è l'output di Taproot che contiene gli asset impegnati, che deve contenere lo script di staking di BTC definito da Babylon. L'altro è un output di importo zero che contiene informazioni identificabili sul pegno babilonese tramite OP_RETURN.

L'immagine seguente mostra un esempio di transazione di picchettamento, in cui il primo output è l'output di picchettamento, il secondo è l'output OP_RETURN e il terzo è l'output di resto.

Uscita del pegno

L'output di picchettamento è un output Taproot, come menzionato nel precedente articolo di Chakra:

Esistono due metodi di pagamento per l'output Taproot, vale a dire il percorso di pagamento chiave e il percorso di pagamento dello script. Babylon ha disabilitato il percorso di pagamento chiave impostando la chiave interna sul punto "Nothing Up My Sleeve" (NUMS), rendendo gli output di staking pagabili solo attraverso il percorso di pagamento programmato.

L'output di picchettamento può essere speso tramite tre percorsi di script, corrispondenti al diagramma di processo:

1. Percorso della serratura temporale

Il percorso timelock implementa la funzione di staking e funge anche da garanzia di attività.

<Staker_PK> OP_CHECKSIGVERIFY <Timelock_Blocks> OP_CHECKSEQUENCEVERIFY

Lo script time lock blocca i BTC dello staker per un certo numero di blocchi. I percorsi Timelock non richiedono altre entità, fornendo così garanzie di attività agli staker. Anche se il fornitore delle finalità e il comitato contrattuale diventano inattivi, gli staker possono comunque ritirare i propri asset BTC dopo il periodo di lock-up.

2. Percorso non impegnativo

Se BTC è bloccato da un blocco temporale, come possono gli utenti interrompere anticipatamente lo staking? Babylon ha risolto questo problema introducendo il percorso non vincolante.

<StakerPk> OP_CHECKSIGVERIFY <CovenantPk1> OP_CHECKSIG <CovenantPk1> OP_CHECKSIGADD ... <CovenantPkN> OP_CHECKSIGAD <CovenantThreshold> OP_GREATERTHANOREQUAL

Questo percorso richiede non solo la firma dello staker, ma anche quella del Deeds Committee

Soglia del Patto

Numero di firme dei membri. La ragione principale per l’introduzione del comitato contrattuale è quella di creare artificialmente un periodo di disaggregazione per evitare che gli stakeholder eludano la punizione attraverso il percorso di disaggregazione.

3. Percorso della punizione

Per garantire la sicurezza dei PoS sono necessarie sanzioni. Se il fornitore finale agisce in malafede, potrebbe essere necessario confiscare i fondi propri e affidati per fornire sicurezza finanziaria. Babylon fornisce la funzione di punizione introducendo il percorso di punizione.

<StakerPk > OP_CHECKSIGVERIFY <FinalityProviderPk > OP_CHECKSIGVERIFY <CovenantPk1 > OP_CHECKSIG <CovenantPk1 > OP_CHECKSIGADD ... <CovenantPkN > OP_CHECKSIGADD <CovenantThreshold > OP_GREATERTHANOREQUAL

Gli staker devono prefirmare le transazioni del percorso di penalità prima che lo stato dello staking cambi in Attivo, impedendo loro di trattenere le firme per evitare la perdita di BTC se il fornitore di finalità agisce in modo dannoso. Dopo aver ricevuto la firma dello staker, il comitato di atto verifica innanzitutto la firma e, una volta confermata la sua validità, rilascerà la propria firma.

Un comportamento punibile nello staking di BTC è che un fornitore di finalità firmi due blocchi in conflitto alla stessa altezza, a quel punto qualsiasi utente può ottenere la chiave privata del fornitore di finalità dannoso tramite EOTS. Poiché lo staker e il contratto hanno pre-firmato la transazione della penalità, un utente che ottiene la chiave privata del fornitore di finalità dannose può firmare la transazione, inviando una parte dei fondi impegnati all'indirizzo burn come penalità attraverso il percorso della penalità.

Uscita OP_RETURN

Sebbene l'output di Taproot esprima condizioni di utilizzo complesse in ScriptPubKeys più piccoli, ciò rende anche difficile distinguere le transazioni di staking da altre transazioni nella rete Bitcoin. Pertanto, è necessario divulgare le informazioni relative allo staking attraverso altri mezzi in modo che gli utenti possano identificare le transazioni di penalità sulla base di queste informazioni.

Babylon serializza le informazioni che devono essere divulgate, incorporandole nello script OP_RETURN e accodandole a un altro output della transazione di picchettamento. Il formato è come mostrato di seguito e i dati devono corrispondere ai dati nello script Taproot.

type V0OpReturnData struct { MagicBytes []byte Version byte StakerPublicKey []byte FinalityProviderPublicKey []byte StakingTime []byte }

Secondo lo snapshot della transazione precedente, i dati validi trasportati dall'output OP_RETURN sono infatti 4+1+32+32+2=71 byte in totale. Nella figura, la FinalityProviderPublicKey della transazione di pegno è f4940b238dcd00535fde9730345bab6ff4ea6d413cc3602c4033c10f251c7e81, che appartiene a Chakra.

MagicBytes viene utilizzato per individuare rapidamente le transazioni di staking, mentre Version è un campo riservato per futuri aggiornamenti per una facile differenziazione.

Secondo le istantanee delle transazioni precedenti, il totale dei dati validi trasportati dall'output OP_RETURN è effettivamente pari a

4+1+32+32+2=71 byte

byte. Nella figura, la FinalityProviderPublicKey della transazione di pegno è f4940b238dcd00535fde9730345bab6ff4ea6d413cc3602c4033c10f251c7e81, che appartiene a Chakra.

MagicBytes

Viene utilizzato per individuare rapidamente le transazioni di pegno, mentre Versione è un campo riservato a futuri aggiornamenti per una facile differenziazione.

Separare la transazione

Quando gli staker desiderano sbloccare anticipatamente i BTC in staking, possono inviare una transazione di disaggregazione spendendo il percorso di disaggregazione nell'output dello staking. La transazione di svincolo richiede che accetti solo una singola transazione di pegno come input e restituisca un singolo impegno all'output taproot dello script di svincolo.

Di seguito è riportato uno screenshot della transazione di unbundling, corrispondente all'output di staking precedente.

Tra questi, il penultimo campo che inizia con '20' è il tapscript del percorso non vincolante, e il campo che inizia con 'c1' è la prova Merkle della chiave interna Taproot e il punto NUMS non vincolante può essere chiaramente osservato

0x50929b74c1a04954b78b4b6035e97a5e078a5a0f28ec96d547bfee9ace803ac0

. Nel campo Testimone dell'operazione di unbundling possiamo osservare la firma dello staker e la firma del comitato contrattuale.

Gli output non vincolati possono essere spesi in due condizioni: il percorso timelock e il percorso penalità, che sono entrambi gli stessi percorsi nell'output di picchettamento. Ad un livello elevato, l’output di svincolo è uno stato intermedio progettato per impedire agli staker di ritirare immediatamente le proprie puntate e sfuggire alla punizione, portando infine a uno stato stabile di transazioni di prelievo.

accordo di penalità

La transazione di penalità prende come input una transazione di picchettamento o di svincolo, viene spesa attraverso il percorso di penalità nello script Taproot e produce due output. Un output invia BTC parzialmente picchettati a un indirizzo di masterizzazione, mentre l'altro restituisce i BTC rimanenti allo staker.

Più strettamente parlando, Babylon implementa la confisca parziale per cattiva condotta invece di bruciare tutti i BTC messi in staking dagli staker in una sola volta. Questo approccio fornisce una maggiore tolleranza agli errori e protegge gli interessi degli stakeholder.

Le transazioni di penalità possono avvenire solo sotto la firma congiunta dello staker, del comitato di azione e del fornitore di finalità. Pertanto, anche se un singolo partito viene compromesso, ciò non causerà il collasso dell’intero sistema di puntata. Le transazioni punitive fungono da deterrente, scoraggiando finanziariamente gli attori dal comportarsi in modo dannoso. Finché le sanzioni per comportamenti scorretti superano qualsiasi potenziale guadagno, è probabile che i partecipanti rispettino le regole.

analisi della sicurezza

Esistono due tipi di sicurezza associati a Babylon:

Il primo tipo di sicurezza riguarda lo staker, garantendo che finché lo staker e il suo fornitore di finalità delegato non intraprendono alcun comportamento dannoso, i suoi asset messi in staking non saranno mai puniti.

Il secondo tipo di sicurezza coinvolge il sistema PoS stesso, garantendo che se i partecipanti si comportano in modo dannoso, il protocollo deve essere in grado di identificarli e punirli.

La prospettiva del giurato

Per gli staker, una volta effettuato lo staking di BTC tramite la transazione di staking di Babylon, ci sono solo tre modi per trasferire fondi.

Il primo è un percorso di blocco temporizzato, che richiede solo la firma dell'utente per essere speso. Ciò garantisce che anche se FP e Babylon cessano le operazioni, gli staker possono comunque ritirare i loro BTC originali al termine del periodo di staking.

Il secondo è il percorso di separazione, che funge da stato intermedio, creando un output di separazione e consentendo un tempo di separazione più breve. Ciò fornisce agli staker la possibilità di ritirare anticipatamente i fondi promessi.

Il terzo è il percorso delle penalità, che è l’unico percorso che può ledere gli interessi dei promettenti. Se un outsider tentasse di attaccare il percorso di penalità, dovrebbe fornire contemporaneamente la firma dello staker, la firma del fornitore della finalità e la firma del comitato di azione sopra la soglia, il che è estremamente difficile. Anche se il comitato contrattuale è dannoso, finché il fornitore della finalità è onesto, il BTC dello staker è al sicuro.

La prospettiva del sistema PoS

Dal punto di vista di un sistema PoS, la sua sicurezza deriva dalla capacità di punire i fornitori di finalità quando si comportano in modo dannoso.

Babylon adotta il meccanismo EOTS Se il fornitore di finalità firma due volte un blocco, qualsiasi utente può estrarre la chiave privata del fornitore di finalità dalle due firme diverse. Ciò consente loro di firmare e inviare un'operazione di penalità con una parte della penalità corrispondente al BTC di tutti i diritti di voto detenuti dal fornitore di finalità.

Questa misura punitiva scoraggia comportamenti dannosi da parte dei fornitori di finalità, allineando così i loro incentivi con la fornitura di finalità ai servizi di consenso PoS connessi a Babylon, garantendo la sicurezza dei sistemi PoS con grandi quantità di TVL in staking.

In futuro, Chakra continuerà a collaborare con Babylon per lanciare una serie di eventi di staking per offrire agli utenti molteplici vantaggi risolvendo al contempo le sfide di liquidità e interoperabilità e sbloccando l’enorme valore di Bitcoin in tutti gli ecosistemi crittografici.