Storia della rete Lightning di Aaron Van Wirdum : dal brainstorming alla beta  racconta l'interessante storia della rete Lightning prima del 2018.

Satoshi Nakamoto ha avuto l'idea di un canale di pagamento quando ha creato BTC nel 2009 e l'implementazione del codice iniziale del canale di pagamento è stata inclusa in Bitcoin 1.0 e l'idea di un canale di pagamento e persino di Lightning Network è stata discussa dalla comunità di BTC per molti anni.

Bitcoinmagazine, che Vitalik ha fondato nei suoi primi anni, includeva molti articoli importanti da Lightning Network e, alla fine del 2013, Vitalik ha proposto un approccio più generale al team di Mastercoin quando ha considerato come espandere ulteriormente le funzionalità di Bitcoin e Mastercoin. Questa soluzione consente di sostituire il linguaggio contrattuale professionale di Mastercoin con contratti flessibili e programmabili (ma non Turing-completi). Sebbene il team di Mastercoin sia rimasto colpito, l'offerta era troppo radicale per adattarsi alla loro tabella di marcia e la proposta è stata respinta.

Di conseguenza, il rifiutato Vitalik ha iniziato a redigere un white paper di Ethereum per implementare le sue idee sugli smart contract on-chain e gli sviluppatori di BTC hanno gradualmente formato un consenso, abbandonando il percorso di implementazione di smart contract e ridimensionamento a un livello, fissando le funzioni di uno strato sulla sicurezza e sulle funzioni di base e mettendo varie estensioni fuori dall'implementazione della chain, due chain pubbliche dietro le due chain pubbliche.

molding

Febbraio 2015 è stato un momento importante in cui Thaddeus Dryja e Joseph Poon hanno scritto un documento intitolato "The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments" con Joseph Poon dopo molte discussioni tra i programmatori Il white paper è stato pubblicato per la prima volta nel febbraio 2015 e ha presentato la loro visione per la prima volta al Bitcoin Devs Seminar di San Francisco.

Nei mesi successivi, per tutta la primavera e l'estate del 2015, i problemi di ridimensionamento di Bitcoin e i limiti di dimensione dei blocchi si sono trasformati in controversie pubbliche. In questo clima di crisi, alla fine del 2015 si sono tenute due conferenze consecutive: Scaling Bitcoin Montreal a settembre e Scaling Bitcoin Hong Kong a ottobre. A Montreal, Poon e Dryja sono saliti di nuovo sul palco, ed entrambi hanno tenuto una seconda presentazione più approfondita a Hong Kong.

Subito dopo la conferenza di Hong Kong, Gregory Maxwell ha presentato una tabella di marcia per l'espansione nel gruppo di mailing degli sviluppatori Bitcoin. Questa tabella di marcia include in primo piano la rete Lightning. Ha ottenuto il supporto di gran parte della comunità tecnica di Bitcoin ed è diventata di fatto la roadmap per il progetto Bitcoin Core.

Il white paper di Lightning Network contiene molti concetti altamente tecnici che non sono facili da leggere.

Il componente base di Lightning Network è il canale di pagamento.

Come viene implementato il canale di pagamento? Questo contiene una serie di mezzi tecnici crittografici e ingegnosità basati sulla logica delle transazioni BTC, in breve, con il presupposto che la sicurezza dei fondi è garantita dall'affidabilità, due utenti contemporaneamente si "ricaricano" a un indirizzo multi-firma 2 su 2 e quindi, scambiando le informazioni sulla transazione della firma per ottenere ogni aggiornamento del saldo/pagamento completo, entro il limite del saldo, tale pagamento non deve necessariamente essere on chain, entrambe le parti della transazione fanno affidamento sulle informazioni corrette della transazione della firma per garantire la propria interessi, quando necessario, il regolamento on-chain può essere effettuato trasmettendo le ultime informazioni sulle transazioni alla chain e chiudendo il canale di pagamento.

Quindi, tramite HTLC, è possibile collegare un gran numero di reti di pagamento per formare una rete e i pagamenti possono raggiungere i destinatari che non hanno una connessione di canale diretta con il pagatore attraverso tale rete, una rete di pagamento offline che si basa sul BTC è chiamata Lightning Network.

Naturalmente, questa descrizione è eccessivamente semplificata, per i dettagli, si prega di leggere anche il white paper.

Costruzione

Dopo che l'obiettivo è stato fissato, i fan di BTC si sono lanciati con entusiasmo nella costruzione del Lightning Network.

Per creare e ottimizzare il Lightning Network, BTC ha subito diversi aggiornamenti di protocollo, il più grande dei quali è stato SegWit.

Ciò che ottiene Segregated Witness è separare la parte della firma dell'iniziatore in una transazione per un riferimento separato.

Ciò rende possibile che le sottotransazioni basate sulla transazione A possano già essere trasmesse quando la transazione A è firmata ma non è stata ancora trasmessa. Questo può essere utilizzato per creare transazioni di impegno pre-firmate per mitigare il rischio di controparte dopo aver iniettato fondi in un indirizzo MultiSig, una funzionalità necessaria per creare canali di pagamento.

Per la storia di SegWit, vedere "La lunga strada verso SegWit: come il più grande aggiornamento del protocollo di Bitcoin è diventato realtà".

Dopo una lunga lotta, il soft fork SegWit è stato finalmente attivato sulla blockchain di Bitcoin nell'estate del 2017, aprendo la strada al Lightning Network.

Francamente, la rete Lightning costruita dal basso verso l'alto dei canali di pagamento presenta molti problemi sin dall'inizio, tra cui il più influente sull'esperienza dell'utente dovrebbe essere il problema dell'economia della capacità del canale, inoltre ci sono problemi di ritardo di pagamento, problemi di gestione dello stato, Problemi HTLC e problemi di dipendenza da Tor, vedi "“Where the Lightning Network is Not Satisfactory“.di Shinobi.

Il ciclo di vita di un canale richiede l'apertura e la chiusura di due transazioni on-chain, ma il costo di queste due transazioni è sufficiente a costituire in molti casi una barriera all'ingresso e questo modello simile a una ricarica non è sicuramente efficiente in termini di l'efficienza nell'uso dei fondi.

Ad esempio, se Twitter vuole utilizzare Lightning Network per attivare la mancia per l'1% dei 300 milioni di utenti Twitter attivi, deve aprire canali di pagamento per ciascuno di questi 3 milioni di utenti, supponendo che ogni canale occupi 0,01 BTC, quindi tutti questi canali occuperanno 30.000 BTC.

Secondo le statistiche su 1ml.com, l'attuale rete Lightning (20 ottobre 2022) ha un totale di 82.623 canali di pagamento e fondi di canale di 5.001 BTC.

Bolt

“Il white paper di Lightning Network è un documento lungo e complesso che contiene molti concetti altamente tecnici; Nel 2015 poche persone hanno avuto il tempo e la capacità di leggere e comprendere questo documento. Ma dopo che lo sviluppatore di kernel Linux di lunga data Rusty Russell ha studiato questo white paper, la comprensione di base di tutti è migliorata molto. In un numero del blog della serie all'inizio del 2015 , Russell ha "tradotto" il white paper per un pubblico più ampio (ma comunque esigente).

Quindi, nel marzo 2015, Russell ha accettato un'offerta di Blockstream Engineering  Develop a C lightning network: c-lightning. Questo si è rivelato un passo cruciale verso la realizzazione. Un concetto che è stato proposto solo pochi mesi fa ora ha uno dei migliori ingegneri del mondo per realizzarlo. Successivamente, Christian Decker di Blockstream si è unito a Russell. Anche altri, tra cui Corné Plooy, hanno contribuito al progetto open source.

Poco dopo che Russell ha iniziato a sviluppare c-lightning, Blocksteam non è stata l'unica azienda ad entrare nel Lightning Network. Nell'estate del 2015 ,  ACINQ, una piccola società di tecnologia bitcoin che inizialmente prevedeva di sviluppare portafogli hardware basati su smart card, ha deciso di provare anche questa promettente tecnologia. La startup con sede a Parigi ha successivamente annunciato che i suoi sviluppatori avevano sviluppato il proprio protocollo Lightning Network, chiamato Eclair, nel linguaggio di programmazione Scala.

Dopo qualche altro mese, la terza implementazione ha iniziato a decollare. Nel gennaio 2016, Poon e Dryja, autori del white paper Lightning Network, si sono uniti a Elizabeth Stark e Olaoluwa "Laolu" Osuntokun per formare una nuova società per lo sviluppo di Lightning Network  Lightning Labs. nel linguaggio di programmazione Go di Google (noto anche come "golang"), che avevano sviluppato prima della fondazione dell'azienda.

Circa un anno dopo aver fondato l'azienda, alla fine del 2016, Dryja ha lasciato Lightning Labs per unirsi  alla Digital Currency Initiative del MIT Media Lab, che impiega anche il principale sviluppatore di Bitcoin Core Wladimir van der Laan e diversi contributori di Bitcoin Core. Al MIT, Dryja ha continuato a sviluppare la sua implementazione del Lightning Network che ha avviato presso i Lightning Labs, ribattezzato lit. Ora sono disponibili sia lnd che lit. Ciò che distingue Lit da LND e altre implementazioni è che incapsula il portafoglio e i nodi in un unico insieme; Ora supporta anche l'uso simultaneo di più monete.

Inoltre, la società blockchain  Bitfury (nota per i suoi servizi di mining pool e hardware di mining) ha biforcato l'implementazione lnd e ne ha realizzato un'altra versione. La particolarità di questa versione è che fa sacrifici di progettazione che eliminano la necessità di correggere la malleabilità della rete Bitcoin – entreremo più in dettaglio in seguito. Bitfury ha anche contribuito al campo dell'instradamento delle transazioni, in particolare il protocollo "Flare" (tranne che ora lo sviluppo della versione Bitfury di lnd sembra essersi bloccato) (Nota del traduttore: l'esempio di "fusione" è che le transazioni sono essenzialmente la stessa firma può produrre hash (ID transazione) completamente diversi, rendendo le transazioni non rintracciabili; proprio come lo stesso pezzo di metallo può essere fuso in forme diverse).

Successivamente, nel 2016, il principale servizio di portafoglio Blockchain ha annunciato di aver  sviluppato una versione semplificata di Lightning Network, chiamata "thunder". Questa implementazione fa un grande sacrificio rispetto all'implementazione standard di Lightning Network, in particolare in quanto richiede di fidarsi della controparte nella rete. A causa di questo sacrificio, è stato in grado di lanciare una versione alfa nella primavera del 2016, molto prima rispetto agli altri team di sviluppo. (Sebbene Thunder possa anche essere compatibile con Lightning Network, lo sviluppo di questa implementazione sembra essersi bloccato.) ）

Dopo la conferenza Scaling Bitcoin Milano, a fine 2016 si è tenuta la terza conferenza che ha riunito la maggior parte  dei contributori di Lightning Network  (da cui il nome del primo Lightning Network Summit). Qui, discutono come rendere interoperabili tutte le diverse implementazioni, risultando in una specifica per il protocollo Lightning Network chiamata "BOLT" (BOLT è l'abbreviazione di "Basis of Lightning Technology"). "

                                                                  -["The History of Lightning Network: From Brainstorm to Beta **"](https://www.btcstudy.org/2020/09/03/history-lightning-brainstorm-beta/)

Il white paper di Lightning Network ha un progetto teorico e BOLT è lo stack di protocolli di Lightning Network. è il fondamento di ciò che conosciamo oggi, di fatto il Lightning Network.

Omnibolt

OmniBOLT, apparso il 1 agosto 2019, è una versione potenziata del protocollo BOLT, proposto dalla fondazione omni e, come suggerisce il nome, il più grande impulso per il lancio di questa versione potenziata del protocollo è consentire alla rete Lightning per aggiungere il supporto per le risorse omnilayer.

Le informazioni su github mostrano che OmniBOLT supporta anche le seguenti funzionalità, alcune delle quali sono ancora in fase di pianificazione:

OmniBOLT #05:  Atomic Swap Protocol among Channels

OmniBOLT #06:  Market Maker automatico, Liquidity Pool e DEX

OmniBOLT #07:  Hierarchical Deterministic (HD) wallet, Invoice Encoding

L'Atomic Swap qui menzionato viene effettuato tramite HTLC, come mostrato di seguito.

Va notato qui che nel terzo passaggio, quando Alice usa R per sbloccare Tx 2 per ottenere BTC, deve esporre R a Bob, che è la chiave per garantire l'atomicità dello scambio.

Ovviamente, le due parti dell'Atomic Swap non hanno bisogno di avere un canale di pagamento diretto, fintanto che c'è un percorso di canale che collega le due parti, ovviamente, se il percorso è lungo, ci saranno commissioni di instradamento e ritardi di transazione i problemi.

Quindi possono esserci scambi atomici a cross-chain ? Naturalmente, ma la premessa è che le due parti della transazione hanno due percorsi di canale di pagamento corrispondenti alle due chain e le strutture tecniche pertinenti di queste due chain sono coerenti, come BTC e LTC.

Infatti, nel novembre 2017, prima della comparsa di OmniBOLT, Ligntning Labs ha condotto un esperimento di Atomic Swap a cross-chain, che può essere trovato qui: https://blog.lightning.engineering/announcement/2017/11/16/ln-swap. html

L'emergere di un tale metodo di trading ha senso per gli utenti che detengono asset BTC o ominilayer e non vogliono fare trading al di fuori dei loro wallet.

Il modello di trading AMM di OmniBOLT è simile a uniswap v3.

Questo modello di transazione si basa sugli atomic swap descritti in precedenza, in cui non esiste un contratto intelligente on-chain o un pool di liquidità su un singolo indirizzo e tutti i nodi possono fornire liquidità con i propri fondi nel canale, che è suddiviso in "pagamento equilibrio” e “saldo di liquidità”. I nodi possono inviare messaggi al tracker per informarsi sulla liquidità fornita e sulla fascia di prezzo a cui sono disposti a partecipare al market making.

Tracker è un motore di corrispondenza delle transazioni che raccoglie costantemente informazioni sulla liquidità e informazioni sulle richieste di transazione e, quando può essere abbinato, aiuta i nodi ad abbinare e raggiungere le transazioni.

I nodi non devono fidarsi del tracker, i nodi possono verificare l'autenticità delle informazioni fornite dal tracker e soddisfare le proprie condizioni di transazione, quindi decidere se confermare la transazione.

C'è qualche perdita temporanea quando i nodi partecipano al market making qui? Come uniswap v3, c'è, ma gli LP possono controllare le perdite temporanee a un livello basso impostando una fascia di prezzo di mercato.

In breve, la logica di trading qui è equivalente a Uniswap v3 + order book, implementato solo su un pool di liquidità distribuito, basato sulla logica degli atomic swap.

Tutti i mezzi tecnici di cui sopra possono essere utilizzati anche per ottenere prestiti ipotecari, ma finora le informazioni su github mostrano che l'idea di OmniBOLT di prestiti ipotecari è ancora nella fase della discussione di fattibilità da parte della comunità e non è inclusa nella roadmap di sviluppo.

Taproot

A metà novembre 2021, BTC ha completato l'aggiornamento Taproot, che è probabilmente l'aggiornamento più importante di BTC dopo SegWit.

L'aggiornamento Taproot è una raccolta di tre BIP, Schnorr Signature (BIP 340), Taproot (BIP 341) e TapScript (BIP 342), noti collettivamente come BIP Taproot, che offre a Bitcoin un modo più efficiente, flessibile e privato per trasmettere, con firme Schnorr e Merkel Abstract Syntax Trees (MAST) al centro.

Il principio del Taproot, in parole povere, è definire un output e due percorsi di spesa. Come mostrato nell'immagine sopra, con la partecipazione di Alice e Bob, Taproot funziona come segue:

Aggrega le chiavi pubbliche di Alice e Bob in: C=P_A+P_B

Con MerkleRoot, la chiave pubblica viene aggregata come: P=C+H(C|| MerkleRoot) G, dove H(C|| MerkleRoot) rappresenta un hash C e MerkleRoot combinato

Lo script di blocco è compilato con la chiave pubblica aggregata P, nel formato come Segwit:[ver] [P]. ver rappresenta il numero di versione e ver=1 in Taproot.

Ci sono due percorsi di spesa, scegli uno dei due:

Modalità firma: Alice e Bob firmano tutti per generare una firma aggregata, che viene compilata nello script di controllo. Con la chiave pubblica aggregata P, la firma può essere spesa dopo che è stata verificata.

Modalità script: Alice e Bob, che si rifiutano di firmare, possono passare alla modalità script. A questo punto, se Alice vuole completare il costo, è necessario compilare lo script testimone: dati di esecuzione D, Script 1, C, Hash 2 secondo Script 1. Per verificare la firma, utilizzare prima Script 1, Hash2, calcola MerkleRoot, quindi verifica che P==C+H(C|| MerkleRoot)G sia vero e infine compila lo script completo D|| Script 1 ed eseguire lo script per verificare che il risultato sia vero. Una volta superata la verifica di cui sopra, il costo può essere completato.

Quando Taproot viene speso secondo il modello di firma, più parti e una singola parte sembrano tutte uguali sulla blockchain, quindi molte analisi blockchain non saranno disponibili, preservando la privacy per tutti gli utenti Taproot. Allo stesso tempo, il modello di spesa degli script di Taproot consente agli utenti di implementare condizioni di spesa complesse. Taproot può comprimere efficacemente il numero di byte degli script di transazione. Nella modalità firma, la dimensione dello script della transazione EDSA aumenta linearmente all'aumentare del numero di partecipanti, mentre la dimensione dello script della transazione Taproot rimane invariata. In modalità script, all'aumentare del numero di script, la dimensione dello script della transazione EDSA aumenta in modo lineare e la dimensione logaritmica dello script della transazione Taproot aumenta.

Taproot rende possibili gli smart contracts?

Taproot rende possibili transazioni basate su condizioni complesse e le firme Schnorr rendono fattibile la firma di massa, ma Taproot non migliora molto la programmabilità di BTC e le sue benedizioni "smart" per BTC sono ancora limitate.

Il figlio più brillante generato da Taproot è stato Taro di Lighting Labs.

Come Omnilayer e RGB, Taro emette risorse sulla catena BTC inserendo i metadati delle transazioni delle risorse nell'output UTXO, ma Taro utilizza il nuovo tipo di transazione Taproot per ottenere tutto ciò, quindi dovrebbe essere più efficiente e con una migliore privacy.

 

RGB

La ricerca e lo sviluppo nel campo dei protocolli off-chain di Bitcoin ha aperto una finestra per Bitcoin e gli sviluppatori stanno perseguendo molto di più che decentralizzare il trasferimento di valore. Hanno iniziato a cercare di andare oltre, ad esempio, implementando contratti intelligenti in un protocollo off-chain e RGB è leader in tali progetti.

RGB si basa sulla ricerca di Peter Todd sui sigilli una tantum e sulla verifica dei clienti ed è stato concepito da Giacomo Zucco e dalla comunità nel 2016 come un protocollo di emissione di risorse migliore su Bitcoin e Lightning Network. L'ulteriore sviluppo di queste idee ha portato Maxim Orlovsky a sviluppare RGB in un sistema di smart contract più completo, che guida dal 2019 con la partecipazione della comunità.

Secondo la descrizione ufficiale, RGB è definito come un insieme di protocolli open source che ci consentono di eseguire smart contracts complessi in modo scalabile e riservato. Non è una rete specifica (come Bitcoin o Lightning Network); Ogni smart contract è semplicemente un insieme di partecipanti al contratto che possono interagire utilizzando diversi canali di comunicazione (la rete Lightning per impostazione predefinita). RGB sfrutta la blockchain di Bitcoin come livello di impegno dello stato e mantiene il codice e i dati degli smart contract off chain  per la scalabilità. Utilizza le transazioni (e gli script) Bitcoin come sistema di controllo della proprietà per gli smart contracts ; Anche se l'evoluzione degli smart contract è definita da una soluzione off-chain. Infine, è importante notare che tutto è convalidato dal lato client.

In breve, RGB è un sistema che consente agli utenti di controllare, eseguire e verificare smart contracts in qualsiasi momento senza alcun sovraccarico aggiuntivo e non utilizza la blockchain in modo "tradizionale".

Ad alcuni fan RGB non piace Ethereum e la tabella seguente mostra questo atteggiamento.

Qui dobbiamo discutere brevemente della programmabilità di Bitcoin e confrontare gli smart contract di Bitcoin con Ethereum.

Bitcoin opera su due concetti di base: transazioni e UTXO. Quando una transazione crea un nuovo UTXO, si presenterà con una condizione di sblocco espressa dallo script di blocco, e quando la transazione successiva vuole addebitare questo UTXO, i dati corrispondenti devono essere forniti attraverso la procedura di verifica specificata dallo script di blocco, altrimenti non può essere speso. Per programmare Bitcoin, non devi fare altro che a livello di transazione o a livello di script.

La cassetta degli strumenti di programmazione di Bitcoin ha attualmente strumenti come firme, firme multiple, blocchi hash, blocchi temporali e controllo dei processi.

Confrontando Ethereum e Bitcoin, si può scoprire che la programmabilità di Bitcoin ha evidenti limitazioni nei seguenti aspetti:

1. Le procedure di verifica che consente non sono arbitrarie, ne esistono solo un numero limitato.
2. Non consente di memorizzare lo stato interno dei fondi negli script. Anche se prevede più percorsi di sblocco, non può limitare la quantità di fondi che possono essere utilizzati da ciascun percorso di sblocco, purché tu possa sbloccare fondi, puoi utilizzare tutti i fondi utilizzando un percorso qualsiasi. Si può anche dire che lo script non calcola.
3. Non consente di limitare il modo in cui vengono spesi i fondi. Dopo che un UTXO è stato sbloccato, puoi spenderlo come vuoi e lo script non ha modo di limitare il modo in cui vengono spesi i fondi.
4. Lo script di sblocco esprime una condizione di sblocco completa e indipendente che non ci consente di esprimere una dipendenza da un altro UTXO. Un UTXO non decide (e non può) decidere se può sbloccarlo in base all'esistenza di un altro UTXO, né (non può) decidere se può sbloccarlo in base alle condizioni di blocco di un altro UTXO. In una parola, quando si spende un UTXO, lo script di blocco dell'UTXO e lo script di sblocco fornito dallo scambio sono un universo indipendente, non disturbato da nulla di esterno.

Se chiediamo a un esperto tecnico che ama BTC, BTC supporta gli smart contracts? Molto probabilmente dirà che BTC ha supportato gli smart contract sin dall'inizio.

Non possiamo dire che abbia torto, perché si può anche dire che semplici script sono smart contracts, e si può dire che Lightning Network è un protocollo basato su contratto che gira sulla blockchain di BTC, e quando diamo un'occhiata più da vicino al Lightning Network, troveremo alcune funzionalità che potrebbero essere comuni agli smart contract nativi di BTC:

• È possibile utilizzare le transazioni per esprimere lo stato del contratto e la modifica delle transazioni indica una modifica dello stato del contratto.
• Se si entra in uno stato e si corre il rischio di perdere il controllo, è possibile vincolare la direzione dopo essere entrati in questo stato firmando in anticipo l'operazione di impegno, eliminando così il corrispondente rischio di controparte. Ad esempio, se l'immissione di un output multi-firma 2 su 2 può causare il blocco dei fondi, organizzare prima una transazione per spendere questo output.
• Oltre alla risoluzione del contratto, gli aggiornamenti di stato richiedono sempre che tutte le parti siano online.
• Le transazioni storiche che esprimono lo stato devono essere archiviate separatamente dalle parti (almeno per ora).
• La funzione principale dello script di blocco è quella di organizzare la priorità delle azioni dei partecipanti al contratto, piuttosto che produrre direttamente il risultato; In altre parole, la programmazione del protocollo basata su Bitcoin utilizza la scienza dei giochi.

La programmazione di Bitcoin pone requisiti più elevati sia agli sviluppatori di applicazioni che ai partecipanti alle applicazioni, e queste limitazioni rendono lo sviluppo delle applicazioni più non intuitivo e difficile da analizzare, per usare un'analogia inappropriata, un po' come un dojo in un guscio di vite o la scrittura di un sistema operativo in linguaggio assembly. Gli utenti, inoltre, non possono fare affidamento sulla blockchain per fornire loro una comodità sufficiente, ma devono assumersi maggiori responsabilità (ad esempio, nella rete Lightning, è necessario mantenere le transazioni dello stato storico e le protologie hash corrispondenti, o almeno qualcuno è responsabile per tenerli).

Non possiamo dire che BTC non abbia senso limitare così tanto la programmabilità, Bitcoin ha infatti perseguito un principio di "minimizzazione dell'uso delle risorse", rifiutando transazioni a basso costo per occupare spazio di blocco ed espandersi. Scendi la catena. Questo stato attuale è il risultato naturale del mantenimento dell'intenzione originaria.

Nel contesto di Ethereum, "smart contract" indica un programma per computer immutabile che viene eseguito in modo determinante in un ambiente di macchina virtuale, il contratto viene distribuito nell'account del contratto onchain e l'EVM viene eseguito come istanza locale su ciascun nodo Ethereum, ma poiché tutte le istanze dell'EVM vengono eseguite nello stesso stato iniziale e producono lo stesso stato finale, l'intero sistema si comporta come un unico computer mondiale completo di Turing.

L'atomicità delle transazioni è garantita dalle regole con cui viene eseguito l'EVM, indipendentemente da ciò che esegue il contratto quando viene chiamato. Eventuali cambiamenti nello stato globale (contratti, conti, ecc.) vengono registrati solo quando la transazione viene terminata con successo. Una conclusione riuscita significa che il programma viene eseguito senza errori e viene raggiunta la fine dell'esecuzione. Se una transazione non riesce a causa di un errore, tutti i suoi effetti (cambiamenti di stato) vengono "riportati indietro" come se la transazione non fosse mai stata eseguita. Le transazioni non riuscite vengono ancora archiviate nella blockchain e i costi del gas vengono detratti dall'account originale, ma non hanno altro impatto sul contratto o sullo stato dell'account.

Qui, gli smart contracts  sono on-chain, tutti gli stati sono on-chain e il risultato è una buona esperienza per sviluppatori e utenti e, naturalmente, il rigonfiamento della blockchain.

Non possiamo semplicemente giudicare quale sia la strada giusta o sbagliata, è una questione di scelta.

Naturalmente, il team RGB crede profondamente nel percorso di BTC e spiega la sua scelta in questo modo:

L'attuale industria blockchain sostiene l'archiviazione del codice e dei dati dello smart contract sulla blockchain e l'esecuzione da parte di tutti i nodi della rete, ignorando l'eccessiva crescita del volume della blockchain e l'abuso delle risorse informatiche. Lo schema proposto da RGB è più intelligente ed efficiente perché si allontana dal paradigma blockchain separando smart contract e dati dalla blockchain, evitando così la saturazione della rete che è comune su altre piattaforme e, a sua volta, non richiede tutti i nodi per eseguire ogni contratto, ma trasforma l'esecutore testamentario in una parte del contratto, il che porta una riservatezza senza precedenti.

Gli sviluppatori di smart contract su RGB definiscono uno schema per l'evoluzione dei contratti nel tempo. Questa soluzione è uno standard per la creazione di contratti intelligenti in RGB e gli emittenti devono prima verificare i contratti quando definiscono contratti emessi e portafogli o scambi quando devono affrontare contratti specifici. Solo quando la convalida è corretta ciascuna parte può accettare la richiesta ed elaborare il relativo asset.

Uno smart contract in RGB è un grafo aciclico diretto (DAG) costituito da cambiamenti di stato che è sempre noto solo in parte e il resto è inaccessibile. Lo schema RGB è un insieme fondamentale di regole che regolano l'evoluzione degli smart contract ed è il punto di partenza per tutti gli smart contract. Ciascun partecipante al contratto può integrare questo insieme di regole (come consentito dall'architettura) e il grafico risultante è costruito dall'applicazione iterativa di queste regole.

                                      - Francisco Calderon[《Una breve introduzione ai protocolli RGB》](https://bitcoinmagazine.com/guides/a-brief-introduction-to-rgb-protocols)

Sembra fantastico, ma poiché la blockchain di Bitcoin viene utilizzata come livello di impegno dello stato, è necessariamente soggetta alle limitazioni della programmabilità di BTC, che sono critiche in molti scenari.

Lo sviluppo di RGB è fondamentalmente solo nella fase di emissione di asset e l'implementazione di contratti intelligenti off-chain non sarà mai agevole e se esiste una reale opportunità di eguagliare o addirittura superare gli smart contract on-chain è un grande punto interrogativo .

primo piano

Negli ultimi mesi sono stati frequenti i grandi finanziamenti nel settore Lightning Network, in particolare i seguenti:

Il fornitore di app di pagamento Strike ha raccolto $ 80 milioni. ❕

Lightning Labs ha raccolto 70 milioni di dollari.

LightsPark ha ricevuto investimenti da A16Z e Paradigm, il cui importo non è stato divulgato.

La capacità del canale della rete Lightning è aumentata in modo significativo negli ultimi due anni:

La cosa principale dietro è la forza di queste istituzioni:

Nonostante stia crescendo rapidamente, la capacità complessiva del Lightning Network è ancora molto diversa dalle aspettative dei fan. Di seguito è riportato 1 ml di dati per il 20 ottobre.

Dopotutto, ci sono più di 170.000 BTC attraverso le catene verso ETH.

Kollider, una piattaforma di trading di derivati ​​basata su Lightning Network, ha scambiato circa 1,1 BTC il 22 ottobre.

Dopotutto, Lightning Network è più adatto per i micropagamenti e non così bene per le grandi transazioni.

Il Lightning Network ha un significato fondamentale per il percorso di espansione off-chain rappresentato da BTC, sebbene la strada sia difficile, ma grazie agli sforzi degli sviluppatori, ai grandi finanziamenti e all'entusiasmo della comunità, il Lightning Network dovrebbe essere in grado di innescare un'ondata di applicazioni boom.

Dopotutto, l'atmosfera è stata cotta qui.

Ma dati i suoi limiti, non dovrebbero esserci aspettative irrealistiche al riguardo.

Le informazioni riportate sono state estrapolate da diverse fonti e tradotte, tutte le informazioni fornite non sono correlate alle opinioni e alle posizioni di mindthechart e non costituiscono alcun investimento e consulenza finanziaria. Gli utenti sono tenuti a controllare attentamente per prevenire i rischi.