Titolo originale: "Tecnologia Bitlayer Core: DLC e sue considerazioni sull'ottimizzazione"
Scritto da: lynndell & mutourend, Bitlayer Research Group
1. Introduzione
Discreet Log Contract (DLC) è un insieme di soluzioni di esecuzione dei contratti basate su oracoli proposte da Tadge Dryja del MIT nel 2018. Il DLC consente a due parti di effettuare pagamenti condizionati in base a condizioni predefinite. Ciascuna parte determina e prefirma i possibili risultati e utilizza queste prefirme per eseguire il pagamento quando un oracolo firma i risultati. Pertanto, DLC consente nuove applicazioni finanziarie decentralizzate garantendo al tempo stesso la sicurezza dei depositi Bitcoin.
Rispetto a Lightning Network, il DLC presenta i seguenti vantaggi significativi:
Privacy: il DLC è superiore a Lightning Network in termini di protezione della privacy. I dettagli del contratto sono condivisi solo tra i partecipanti e non verranno archiviati sulla blockchain. Al contrario, le transazioni di Lightning Network vengono instradate attraverso canali e nodi pubblici e le loro informazioni sono pubbliche e trasparenti;
Complessità e flessibilità dei contratti finanziari: il DLC può creare ed eseguire contratti finanziari complessi direttamente sulla rete Bitcoin, come derivati, assicurazioni e contratti di gioco d'azzardo, mentre Lightning Network viene utilizzato principalmente per piccoli pagamenti veloci e non può supportare applicazioni complesse;
Rischio di controparte ridotto: i fondi DLC sono bloccati in contratti multi-firma e verranno rilasciati solo quando si verificano i risultati di eventi predefiniti, riducendo il rischio che entrambe le parti non rispettino il contratto. Sebbene il Lightning Network riduca il bisogno di fiducia, esiste ancora un certo rischio di controparte in termini di gestione del canale e fornitura di liquidità;
Non è necessario gestire i canali di pagamento: le operazioni DLC non richiedono la creazione o il mantenimento di canali di pagamento, che è una componente fondamentale di Lightning Network. La gestione dei canali è complessa e dispendiosa in termini di risorse;
Scalabilità per casi d'uso specifici: Lightning Network migliora in una certa misura il volume delle transazioni di Bitcoin, mentre il DLC fornisce una migliore scalabilità in termini di contratti complessi su Bitcoin.
Sebbene il DLC presenti grandi vantaggi nelle applicazioni ecologiche di Bitcoin, ci sono ancora alcuni rischi e problemi, come:
Rischio chiave: la chiave privata della macchina Oracle e il numero casuale promesso rischiano di essere divulgati o persi, con conseguente perdita delle risorse dell'utente;
Rischio di fiducia centralizzata: i problemi di centralizzazione di Oracle possono facilmente portare ad attacchi di negazione del servizio;
La decentralizzazione impedisce la derivazione della chiave: se l'oracolo è decentralizzato, il nodo oracolo possiede solo il frammento della chiave privata. Tuttavia, i nodi Oracle decentralizzati non possono utilizzare direttamente BIP32 per la derivazione della chiave basata sullo sharding della chiave privata;
Rischio di collusione: se i nodi Oracle colludono tra loro o colludono con le parti partecipanti, la questione della fiducia della macchina Oracle non è ancora risolta. È necessario un meccanismo di supervisione affidabile per ridurre al minimo la fiducia negli oracoli;
Problema di modifica della denominazione fissa: le firme condizionali richiedono un insieme deterministico di eventi enumerabili prima di creare un contratto per costruire una transazione. Pertanto, ci sarà un limite minimo di importo per i DLC da utilizzare per la ridistribuzione delle risorse, con conseguente problema di modifica della denominazione fissa.
A tal fine, questo articolo propone alcune soluzioni e idee di ottimizzazione per risolvere i rischi e i problemi dei DLC e migliorare la sicurezza dell’ecosistema Bitcoin.
Principio 2.DLC
Alice e Bob firmano un accordo di scommessa: scommettono che il valore hash del blocco n+k è un numero pari o dispari. Se è un numero dispari, Alice vince la partita e può ritirare le risorse entro t tempo; se è un numero pari, Bob vince la partita e può ritirare le risorse entro t tempo; Utilizzando il DLC, le informazioni sul blocco n+k vengono passate attraverso l'oracolo per costruire una firma condizionale in modo che il vincitore corretto vinca tutte le risorse.
Inizializzazione: il generatore di curve ellittiche è G e l'ordine è q.
Generazione delle chiavi: l'oracolo, Alice e Bob generano in modo indipendente le proprie chiavi private e pubbliche.
La chiave privata della macchina Oracle è z e la chiave pubblica è Z, soddisfacendo la relazione Z=z⋅G;
La chiave privata di Alice è x e la sua chiave pubblica è X, soddisfacendo la relazione X=x⋅G;
La chiave privata di Bob è y e la sua chiave pubblica è Y, soddisfacendo la relazione Y=y⋅G.
Transazione di iniezione di capitale: Alice e Bob creano insieme una transazione di iniezione di capitale, ciascuno bloccando 1 BTC in un output multi-firma 2 su 2 (una chiave pubblica X appartiene ad Alice e una chiave pubblica Y appartiene a Bob).
Transazione di esecuzione del contratto: Alice e Bob creano due transazioni di esecuzione del contratto (CET) per le transazioni di iniezione di capitale di spesa.
Oracle calcola gli impegni
$R:=k ⋅ SOL$
Quindi, calcola S e S'
$S:=R-hash(NumeroDispari,R) ⋅ Z,$
$S':=R-hash(NumeroPari,R) ⋅ Z$
trasmissione(R,S,S').
Alice e Bob calcolano ciascuno la nuova chiave pubblica corrispondente
$PK^{Alice}:=X+ S,$
$PK^{Bob}:=Y+ S'.$
Liquidazione: quando appare il n+kesimo blocco, la macchina oracle genera i corrispondenti s o s' in base al valore hash del blocco.
Se il valore hash del blocco n+k è dispari, l'oracolo calcola e trasmette s
$s:=k-hash(NumeroDispari,R) ⋅ z$
Se il valore hash del blocco n+k è pari, l'oracolo calcola e trasmette s'
$s':=k-hash(NumeroPari,R) ⋅ z$
Prelevare monete: uno dei partecipanti, Alice o Bob, può prelevare beni in base alle "s" trasmesse dall'oracolo.
Se l'oracolo trasmette s, Alice può calcolare la nuova chiave privata sk^{Alice} e ritirare i 2 BTC bloccati
$sk^{Alice}:= x + s.$
Se l'oracolo trasmette s', Bob può calcolare la nuova chiave privata sk^{Bob} e ritirare i 2 BTC bloccati
$sk^{Bob}:= y + s'.$
Analisi: La nuova chiave privata sk^{Alice} calcolata da Alice e la nuova chiave pubblica PK^{Alice} soddisfano la relazione logaritmica discreta
$sk^{Alice} ⋅ Sol= (x+s) ⋅ Sol=X+S=PK^{Alice}$
In questo caso, il ritiro della valuta di Alice avrà successo.
Allo stesso modo, la nuova chiave privata sk^{Bob} calcolata da Bob e la nuova chiave pubblica PK^{Bob} soddisfano la relazione logaritmica discreta.
$sk^{Bob} ⋅ G= (y+s') ⋅ G=Y+S'=PK^{Bob}$
In questo caso, il ritiro di Bob avrà successo.
Inoltre, se l'oracolo trasmette s, è utile ad Alice ma non a Bob. Perché Bob non può essere utilizzato per calcolare la nuova chiave privata corrispondente sk^{Bob}. Allo stesso modo, se l'oracolo trasmette s', è utile a Bob, ma non ad Alice. Perché Alice non può essere utilizzata per calcolare la nuova chiave privata corrispondente sk^{Alice}.
Infine, la descrizione precedente omette i blocchi temporali. È necessario aggiungere un blocco temporale in modo che una parte possa calcolare la nuova chiave privata e ritirare la valuta entro t tempo. Altrimenti, se il tempo t viene superato, l'altra parte può ritirare i beni utilizzando la chiave privata originale.
ottimizzazione 3.DLC
3.1 Gestione delle chiavi
Nel protocollo DLC sono fondamentali la chiave privata dell'oracolo e il numero casuale promesso. Se la chiave privata dell'oracolo e il numero casuale promesso vengono divulgati o persi, ciò porterà facilmente ai seguenti quattro problemi di sicurezza:
(1) La macchina Oracle perde la chiave privata z
Se l'oracolo perde la chiave privata, il DLC non potrà essere saldato, con conseguente necessità di stipulare il contratto di rimborso del DLC. Pertanto, nel protocollo DLC viene impostata una transazione di rimborso per impedire all'oracolo di perdere la propria chiave privata.
(2) La macchina Oracle perde la chiave privata z
Se la chiave privata dell'oracolo viene divulgata, tutti i DLC basati su quella chiave privata sono a rischio di transazione fraudolenta. Un utente malintenzionato che ruba la chiave privata può firmare qualsiasi messaggio desideri, ottenendo il controllo completo sull'esito di tutti i contratti futuri. Inoltre, l'aggressore non si limita a pubblicare un unico messaggio firmato, ma può anche pubblicare messaggi contrastanti, ad esempio firmando l'n+kesimo blocco con hash pari e dispari contemporaneamente.
(3) La macchina oracolare perde o riutilizza il numero casuale k
Se l'oracolo divulga il numero casuale k, durante la fase di regolamento, indipendentemente dal fatto che l'oracolo trasmetta s o s', l'aggressore può calcolare la chiave privata z dell'oracolo come segue
$z:=(k-s)/hash(Numerodispari, R)$
$z:=(k-s')/hash(NumeroPari, R)$
Se la macchina Oracle riutilizza il numero casuale k, dopo due soluzioni, l'attaccante può risolvere il sistema di equazioni in base alla firma trasmessa dalla macchina Oracle e in una delle seguenti quattro situazioni per ottenere la chiave privata z della macchina Oracle,
Caso 1:
$s_1=k-hash(Numerodispari_1, R) ⋅ z$
$s_2=k-hash(NumeroDispari_2, R) ⋅ z$
Caso 2:
$s_1'=k-hash(NumeroPari_1, R) ⋅ z$
$s_2'=k-hash(NumeroPari_2, R) ⋅ z$
Caso 3:
$s_1=k-hash(Numerodispari_1, R) ⋅ z$
$s_2'=k-hash(NumeroPari_2, R) ⋅ z$
Caso 4:
$s_1'=k-hash(NumeroPari_1, R) ⋅ z$
$s_2=k-hash(NumeroDispari_2, R) ⋅ z$
(4) La macchina oracolare perde il numero casuale k
Se l'oracolo perde il numero casuale k, il DLC corrispondente non potrà essere risolto e sarà necessario stipulare il contratto di rimborso del DLC.
Pertanto, al fine di migliorare la sicurezza della chiave privata Oracle, è necessario utilizzare BIP32 per derivare la chiave figlio o la chiave nipote per la firma. Inoltre, per migliorare la sicurezza del numero casuale, il valore hash k:=hash(z, contatore) della chiave privata e del contatore dovrebbe essere utilizzato come numero casuale k per evitare che il numero casuale venga ripetuto o perso.
3.2 Oracolo decentralizzato
Nel DLC, il ruolo dell'oracolo è cruciale, poiché fornisce dati esterni chiave che determinano l'esito del contratto. Per migliorare la sicurezza di questi contratti sono necessari oracoli decentralizzati. A differenza degli oracoli centralizzati, gli oracoli decentralizzati distribuiscono la responsabilità di fornire dati accurati e a prova di manomissione su più nodi indipendenti, il che può ridurre il rischio di fare affidamento su un singolo punto di errore e ridurre la possibilità di manipolazione o attacchi mirati. Attraverso oracoli decentralizzati, DLC può raggiungere un grado più elevato di trustless e affidabilità, garantendo che l’esecuzione del contratto dipenda interamente dall’obiettività di condizioni predeterminate.
Le firme delle soglie Schnorr possono implementare oracoli decentralizzati. Le firme delle soglie Schnorr presentano i seguenti vantaggi:
Maggiore sicurezza: le firme delle soglie riducono il rischio di singoli punti di errore attraverso la gestione decentralizzata delle chiavi. Anche se le chiavi di alcuni partecipanti vengono rubate o attaccate, l'intero sistema è comunque sicuro finché non viene superata la soglia impostata.
Controllo distribuito: la firma della soglia realizza il controllo distribuito della gestione delle chiavi Nessuna singola entità ha tutto il potere di firma, riducendo così il rischio causato da un'eccessiva concentrazione di potere.
Disponibilità migliorata: solo un certo numero di nodi Oracle deve accettare di completare la firma, il che migliora la flessibilità e la disponibilità del sistema. Anche se alcuni nodi non sono disponibili, ciò non influirà sul funzionamento affidabile dell'intero sistema.
Flessibilità e scalabilità: il protocollo di firma della soglia può impostare soglie diverse in base alle necessità per adattarsi a vari requisiti e scenari di sicurezza. Inoltre è adatto anche per reti su larga scala e ha una buona scalabilità.
Responsabilità: ciascun nodo Oracle genera frammenti di firma per i messaggi basati su frammenti di chiave privata e gli altri partecipanti possono utilizzare i frammenti di chiave pubblica corrispondenti per verificare la correttezza dei frammenti di firma per ottenere la responsabilità. Se corretti, i frammenti della firma vengono accumulati per generare una firma completa.
Pertanto, il protocollo di firma della soglia Schnorr presenta vantaggi significativi negli oracoli decentralizzati che migliorano la sicurezza, l'affidabilità, la flessibilità, la scalabilità e la responsabilità.
3.3 Accoppiare decentramento e gestione delle chiavi
Nella tecnologia di gestione delle chiavi, l'oracolo ha una chiave completa z. Basandosi sulla chiave completa z e sull'incremento ω, utilizzando BIP32, può emettere un gran numero di sottochiavi z+{ω }^{(1)} e grandi chiavi. z+ω ^{(1)}+ω ^{(2)}. Per eventi diversi, l'oracolo può utilizzare diverse chiavi private principali z+ω ^{(1)}+ω ^{(2)} per generare la firma σ corrispondente per il messaggio di evento corrispondente.
Nello scenario dell'applicazione Oracle decentralizzata, ci sono n partecipanti e t+1 partecipanti devono eseguire le firme delle soglie. Tra questi, t. Ciascuno degli n nodi Oracle ha un frammento di chiave privata z_i, i=1,...,n. Questi n frammenti di chiave privata z_i corrispondono a una chiave privata completa z, ma la chiave privata completa z non appare dall'inizio alla fine. Partendo dalla premessa che la chiave privata completa z non viene visualizzata, i nodi Oracle t+1 utilizzano i frammenti di chiave privata z_i, i=1,...,t+1 per generare frammenti di firma σ_i' per il messaggio msg' e i frammenti di firma σ_i' viene fuso nella firma completa σ '. Il verificatore può verificare la correttezza della coppia di firme del messaggio (msg',σ ') utilizzando la chiave pubblica completa Z. Poiché sono necessari t+1 nodi Oracle per generare congiuntamente una firma di soglia, la sicurezza è elevata.
Tuttavia, nello scenario dell'applicazione Oracle decentralizzata, la chiave privata completa z non viene visualizzata e BIP32 non può essere utilizzato direttamente per la derivazione della chiave. In altre parole, la tecnologia di decentralizzazione dell’oracolo e la tecnologia di gestione delle chiavi non possono essere direttamente accoppiate.
Il documento Distributed Key Derivation for Multi-Party Management of Blockchain Digital Assets propone un metodo di derivazione della chiave distribuita nello scenario della firma a soglia. L'idea centrale di questo articolo è che, secondo il polinomio di interpolazione lagrangiano, il frammento di chiave privata z_i e la chiave privata completa z soddisfano la seguente relazione di interpolazione
Aggiungendo l'incremento ω ad entrambi i lati dell'equazione precedente, otteniamo la seguente equazione
Questa equazione mostra che: il frammento di chiave privata z_i più l'incremento ω soddisfa ancora la relazione di interpolazione con la chiave privata completa z più l'incremento ω. In altre parole, il frammento di chiave sub-privata z_i+ω e la sottochiave z+ω soddisfano la relazione di interpolazione. Pertanto, ciascun partecipante può utilizzare il frammento di chiave privata z_i più l'incremento ω per derivare il frammento di chiave sub-privata z_i+ω, che viene utilizzato per generare frammenti di sottofirma, e può utilizzare la corrispondente chiave sub-pubblica Z+ω ⋅ G Verifica di validità.
Tuttavia, è necessario considerare il BIP32 potenziato rispetto a quello non potenziato. Il BIP32 avanzato prende la chiave privata, il codice della catena e il percorso come input, calcola SHA512 e restituisce l'incremento e il codice della sottocatena. Il BIP32 non avanzato prende la chiave pubblica, il codice della catena e il percorso come input, calcola SHA512 e restituisce l'incremento e il codice della sottocatena. Nel caso della firma a soglia, la chiave privata non esiste, quindi è possibile utilizzare solo BIP32 non avanzato. Oppure utilizza la funzione hash omomorfica, è disponibile BIP32 potenziato. Tuttavia, la funzione hash omomorfica è diversa da SHA512 ed è incompatibile con il BIP32 originale.
3.4 OP-DLC: ridurre al minimo Oracle Trust
Nel DLC, il contratto tra Alice e Bob viene eseguito in base al risultato della firma dell'oracolo, quindi è necessario fidarsi dell'oracolo in una certa misura. Pertanto, il corretto comportamento della Oracle Machine è un prerequisito importante per il funzionamento del DLC.
Per diffidare degli oracoli, ci sono stati studi sull'esecuzione di DLC basati sui risultati degli oracoli per ridurre la dipendenza da un singolo oracolo.
Il modello "n-of-n" significa utilizzare n oracoli per firmare un contratto ed eseguire il contratto in base ai risultati degli n oracoli. Questo modello non richiede oracoli per firmare tutti online. Se un oracolo va offline o presenta disaccordi sui risultati, ciò influenzerà l'esecuzione del contratto DLC. Il presupposto della fiducia è che tutti gli oracoli siano onesti.
Il modello "k-of-n" significa utilizzare n oracoli per firmare un contratto ed eseguire il contratto in base ai risultati di k oracoli. Se più di k oracoli colludono, ciò influenzerà la corretta esecuzione del contratto. Inoltre, quando si utilizza il modello "k-di-n", il numero di CET che devono essere preparati è C_n^k volte quello di un singolo oracolo o del modello "n-di-n". Il presupposto della fiducia è che almeno k oracoli tra n oracoli siano onesti.
L’aumento del numero di macchine Oracle non raggiunge la sfiducia nei confronti delle macchine Oracle. Perché quando l'oracolo fa qualcosa di male, la parte lesa nel contratto non ha alcun canale di ricorso sulla catena.
Pertanto, questa sezione propone OP-DLC, che introduce un meccanismo di sfida ottimistico nel DLC. Prima che i n oracoli partecipino alla creazione del DLC, devono impegnarsi in anticipo a costruire un gioco OP on-chain senza autorizzazione e promettere di non fare del male. Se un oracolo fa il male, Alice o Bob, o qualsiasi altro oracolo onesto o altro osservatore onesto di terze parti, può avviare una sfida. Se lo sfidante vince la partita, il malvagio oracolo verrà punito sulla catena e il suo deposito verrà incamerato. Inoltre, OP-DLC può essere firmato anche utilizzando il modello "k-of-n". Tra questi, il valore k può essere anche 1. Pertanto, il presupposto della fiducia si riduce al fatto che finché esiste un partecipante onesto nella rete, la sfida OP può essere lanciata per punire il malvagio nodo oracolo.
Quando si regola l'OP-DLC in base ai risultati del calcolo Layer2:
Se l'oracolo utilizza una firma del risultato errata, danneggiando gli interessi di Alice, Alice può utilizzare il livello 2 per calcolare correttamente il risultato e sfidare il gioco OP on-chain senza autorizzazione promesso in anticipo dall'oracolo. Alice vince la partita, punisce il malvagio oracolo e compensa la perdita;
Allo stesso modo, Bob, altri nodi oracoli onesti e osservatori onesti di terze parti possono tutti avviare sfide. Tuttavia, per prevenire sfide dannose, anche lo sfidante deve puntare.
Pertanto, OP-DLC consente ai nodi Oracle di supervisionarsi a vicenda, riducendo al minimo la fiducia degli Oracle. Questo meccanismo richiede un solo partecipante onesto e ha un tasso di tolleranza agli errori del 99%, che risolve meglio il rischio di collusione degli oracoli.
3.5 OP-DLC + BitVM doppio ponte
Quando il DLC viene utilizzato come ponte a catena incrociata, è richiesta l'allocazione dei fondi al momento della risoluzione del contratto DLC:
Deve essere preimpostato dal CET. Ciò significa che la granularità del regolamento dei fondi DLC è limitata, come la rete Bison con una granularità di 0,1 BTC. C’è un problema: l’interazione con le risorse degli utenti nel Layer 2 non dovrebbe essere limitata alla granularità dei fondi del DLC CET.
Quando Alice desidera liquidare le sue risorse di Livello 2, le risorse di Livello 2 dell'utente Bob saranno costrette a liquidarle sul Livello 1. C’è un problema: ogni utente del Livello 2 dovrebbe essere in grado di scegliere liberamente di depositare e prelevare fondi senza essere influenzato dai depositi e prelievi di altri utenti.
Alice e Bob negoziano il costo. C’è un problema: entrambe le parti devono essere disposte a collaborare.
Pertanto, per risolvere i problemi di cui sopra, questa sezione propone il dual bridge OP-DLC + BitVM. Questa soluzione consente agli utenti di depositare e prelevare denaro tramite il bridge senza autorizzazione di BitVM, nonché di depositare e prelevare denaro tramite il meccanismo OP-DLC, ottenendo modifiche a qualsiasi granularità e migliorando la liquidità del capitale.
In OP-DLC, l'oracolo è BitVM Alliance, Alice è un utente normale e Bob è BitVM Alliance. Quando si imposta OP-DLC, nel CET costruito, l'output dato all'utente Alice può essere speso immediatamente su Layer1 e nell'output dato a Bob, viene costruito un "gioco DLC a cui Alice può partecipare alla sfida" e un blocco temporale è impostato il periodo di blocco. Quando Alice vuole prelevare denaro:
Se BitVM Alliance agisce come un oracolo e firma correttamente, Alice può prelevare denaro su Layer1. Tuttavia, Bob può prelevare denaro sul Livello 1 dopo la scadenza del periodo di blocco.
Se l'Alleanza BitVM agisce come un oracolo e imbroglia, gli interessi di Alice verranno danneggiati. Tuttavia, Alice può sfidare l'UTXO di Bob. Se la sfida ha successo, l'importo di Bob può essere confiscato. Nota: anche uno degli altri membri dell'Alleanza BitVM può avviare una sfida, ma Alice è più motivata ad avviare una sfida perché i suoi interessi sono danneggiati.
Se l'Alleanza BitVM agisce come un oracolo e imbroglia, gli interessi di Bob verranno danneggiati. Tuttavia, un membro onesto dell'Alleanza BitVM può sfidare il "Gioco BitVM" e punire i nodi Oracle imbroglioni.
Inoltre, quando l'utente Alice desidera prelevare fondi dal Livello 2, ma il CET preimpostato nel contratto OP-DLC non corrisponde all'importo, Alice può scegliere i seguenti metodi:
Preleva denaro tramite BitVM e avanzalo sul Layer1 dall'operatore BitVM. Il bridge BitVM presuppone un partecipante onesto all'alleanza BitVM.
Preleva denaro attraverso un determinato CET in OP-DLC e il resto rimanente verrà anticipato dall'operatore BitVM nel Layer1. I prelievi OP-DLC chiuderanno il canale DLC, ma i fondi rimanenti nel canale DLC verranno trasferiti al pool di fondi BitVM Layer1 senza costringere altri utenti Layer2 a prelevare fondi. Il bridge trust OP-DLC presuppone la presenza di un partecipante onesto nel canale.
Alice e Bob negoziano il costo senza la partecipazione della macchina oracolare, richiedendo la collaborazione di Bob.
Pertanto, il dual bridge OP-DLC + BitVM presenta i seguenti vantaggi:
L'utilizzo di BitVM risolve il problema della modifica dei fondi del canale DLC, riduce il numero di impostazioni CET e non è influenzato dalla granularità dei fondi CET;
La combinazione del bridge OP-DLC e del bridge BitVM offre agli utenti più canali di prelievo e deposito e modifiche a qualsiasi granularità;
Imposta l'alleanza BitVM su Bob e l'oracolo e riduci al minimo la fiducia dell'oracolo attraverso il meccanismo OP;
Introdurre il saldo dei prelievi del canale DLC nel pool di capitali del bridge BitVM per migliorare l'utilizzo del capitale.
4. Conclusione
Il DLC è apparso prima dell'attivazione di Segwit v1 (Taproot), è stata implementata l'integrazione del canale DLC e di Lightning Network e il DLC è stato esteso per aggiornare ed eseguire contratti continui all'interno dello stesso canale DLC. Con l'aiuto di tecnologie come Taproot e BitVM, è possibile ottenere verifiche e regolamenti dei contratti off-chain più complessi all'interno del DLC, mentre combinato con il meccanismo di sfida OP, è possibile ottenere la minimizzazione della fiducia degli oracoli.
Riferimenti
Specifiche per contratti di registro discreti
Contratti di tronchi discreti
DLC in scalabilità Parte 1: contratti di registro discreti fuori catena
Ridimensionamento del DLC Parte 2: problema relativo all'opzione gratuita con il DLC
Ridimensionamento del DLC Parte 3: come evitare problemi relativi alle opzioni gratuite con il DLC
Rete fulminea
DLC su Fulmine
Gestione della chiave privata DLC Parte 1
Gestione delle chiavi private DLC Parte 2: Le chiavi private di Oracle
Gestione delle chiavi DLC Parte 3: Distribuzione della chiave pubblica Oracle
BitVM: calcola qualsiasi cosa su Bitcoin
BitVM 2: verifica senza autorizzazione su Bitcoin
Contratti Bitcoin fuori catena BitVM
BIP32 BIP44
Firma Schnorr
FROST: firme di soglia Schnorr flessibili e ottimizzate per il round
Un'indagine sulla firma della soglia ECDSA
Derivazione di chiavi distribuite per la gestione multipartitica delle risorse digitali Blockchain
Testimone segregato
Rollup ottimista
Fittone
