Fonte originale: account Web3 Mario X
Autore: @Web3 Mario
Introduzione: Con il lancio di Notcoin, il gioco più grande dell'ecosistema TON, su Binance e l'enorme effetto ricchezza causato dal modello economico dei token a piena circolazione, TON ha attirato grande attenzione in un breve periodo di tempo. Dopo aver chiacchierato con un amico, ho appreso che la soglia tecnica di TON è relativamente alta e che il paradigma di sviluppo DApp è molto diverso dai protocolli tradizionali della catena pubblica, quindi ho trascorso un po' di tempo facendo ricerche approfondite su argomenti correlati e ho condiviso alcune intuizioni con voi. In breve, il concetto centrale di progettazione di TON è ricostruire il tradizionale protocollo blockchain in modo "dal basso verso l'alto" e ottenere un'elevata concorrenza e un'elevata scalabilità a scapito dell'interoperabilità.
L'idea progettuale principale di TON: elevata concorrenza ed elevata scalabilità
Si può dire che lo scopo di tutte le complesse selezioni tecnologiche in TON deriva dal perseguimento di un'elevata concorrenza e di un'elevata scalabilità. Naturalmente, non è difficile per noi capirlo dal contesto della sua nascita. TON, o The Open Network, è una rete informatica decentralizzata che include una blockchain L1 e più componenti. TON è stato originariamente sviluppato dal fondatore di Telegram Nikolai Durov e dal suo team, ed è ora supportato e gestito da una comunità globale di contributori indipendenti. La sua nascita risale al 2017, quando il team di Telegram iniziò ad esplorare in proprio le soluzioni blockchain. Poiché all’epoca nessuna blockchain L1 esistente poteva supportare la base di utenti a nove cifre di Telegram, decisero di progettare la propria blockchain, allora chiamata Telegram Open Network. Il momento è arrivato nel 2018. Per ottenere le risorse necessarie per implementare TON, Telegram ha lanciato una vendita di token Gram (poi ribattezzati Toncoin) nel primo trimestre del 2018. Nel 2020, il team di Telegram si è ritirato dal progetto TON a causa di problemi normativi. Successivamente, un piccolo gruppo di sviluppatori open source e vincitori del concorso Telegram hanno rilevato il codice base di TON, ribattezzato il progetto The Open Network e continuano a sviluppare attivamente la blockchain fino ad oggi, aderendo ai principi delineati nel white paper originale di TON.
Quindi, poiché è progettato come ambiente di esecuzione decentralizzato per Telegram, deve naturalmente affrontare due problemi, elevate richieste simultanee e enormi quantità di dati. Sappiamo che con lo sviluppo della tecnologia fino ad oggi, Solana, che è noto come il TPS più alto,. ha il TPS più alto misurato, 65.000, il che ovviamente non è sufficiente per supportare l'ecosistema Telegram che richiede milioni di TPS. Allo stesso tempo, con l'applicazione su larga scala di Telegram, la quantità di dati che genera ha già superato il cielo. Essendo un sistema distribuito estremamente ridondante, la blockchain richiede che ogni nodo della rete salvi una copia completa dei dati anche irrealistico.
Pertanto, per risolvere i due problemi di cui sopra, TON ha apportato due ottimizzazioni ai protocolli blockchain tradizionali:
Utilizzando il "paradigma dello sharding infinito" per progettare il sistema, risolviamo il problema della ridondanza dei dati in modo che possa trasportare grandi dati e alleviare il problema del collo di bottiglia delle prestazioni;
Introducendo un ambiente di esecuzione completamente parallelo basato sul modello Actor, il TPS di rete risulta notevolmente migliorato;
Crea una catena blockchain: attraverso capacità di sharding illimitate, ogni account ha una catena di conti esclusiva
Ora sappiamo che lo sharding è diventato la soluzione principale per la maggior parte dei protocolli blockchain per migliorare le prestazioni e ridurre i costi, e TON ha portato questo concetto all'estremo e ha proposto il paradigma dello sharding infinito, il cosiddetto paradigma dello sharding infinito. Si riferisce al consentire alla blockchain di farlo aumentare o diminuire dinamicamente il numero di shard in base al carico di rete. Questo paradigma consente a TON di gestire transazioni su larga scala e operazioni di contratto intelligente mantenendo prestazioni elevate. In teoria, TON può stabilire una catena di conti esclusiva per ciascun conto e garantire l'interoperabilità tra queste catene attraverso determinate regole.
Per capirlo in astratto, ci sono quattro livelli di struttura della catena in TON:
Catena di conti: questa catena di livelli rappresenta una catena composta da una serie di transazioni relative a un conto. Il motivo per cui le transazioni possono formare una struttura a catena è perché per una macchina a stati, purché le regole di esecuzione siano coerenti, la macchina a stati lo farà. i risultati ottenuti dopo aver ricevuto istruzioni nella stessa sequenza sono coerenti, quindi l'ordinamento a catena delle transazioni è richiesto in tutti i sistemi distribuiti blockchain e TON non fa eccezione. La catena di conti è l'unità componente più elementare della rete TON. Di solito la catena di conti è un concetto virtuale ed è improbabile che esista effettivamente una catena di conti indipendente.
Catena di shard: nella maggior parte dei contesti, la catena di shard è l'effettiva unità componente in TON. La cosiddetta catena di shard è una raccolta di catene di account.
WorkChain: può anche essere definito un insieme di catene di sharding con regole personalizzate, come la creazione di una catena di lavoro basata su EVM e l'esecuzione di contratti intelligenti Solidity su di essa. In teoria, ognuno nella comunità può creare la propria catena di lavoro. Costruirla infatti è un compito piuttosto complesso, preceduto dal pagamento della (costosa) quota per crearla e dall’ottenere 2/3 dei voti dei validatori per approvare la creazione della vostra catena di lavoro.
MasterChain: Infine, esiste una catena speciale in TON chiamata catena master, che è responsabile di dare finalità a tutte le catene di shard. Una volta che l'hash del blocco di una catena di shard viene unito al blocco della catena principale, quel blocco della catena di shard e tutti i suoi blocchi principali sono considerati definitivi, il che significa che possono essere considerati fissi e indistruttibili. I blocchi successivi di tutto lo shard fanno riferimento al contenuto modificato Catene.
Adottando tale paradigma, la rete TON presenta le seguenti tre caratteristiche:
Sharding dinamico: TON può dividere e unire automaticamente catene di shard per adattarsi ai cambiamenti di carico. Ciò significa che i nuovi blocchi vengono sempre generati rapidamente e le transazioni non comportano lunghi tempi di attesa.
Altamente scalabile: attraverso il paradigma dello sharding infinito, TON può supportare un numero quasi illimitato di shard e può teoricamente raggiungere da 2 alla 60a potenza delle catene di lavoro.
Adattabilità: quando il carico aumenta su una parte della rete, quella parte può essere suddivisa in più frammenti per gestire l'aumento del volume delle transazioni. Al contrario, quando il carico diminuisce, gli shard possono essere uniti per aumentare l’efficienza.
Quindi la prima cosa che un tale sistema multicatena deve affrontare è il problema della comunicazione cross-chain, soprattutto a causa della capacità di sharding illimitato. Quando il numero di frammenti nella rete raggiunge un certo livello, le informazioni vengono instradate tra le catene diventerà una cosa difficile da fare. Immagina che ci siano 4 nodi nella rete. Ciascun nodo è responsabile del mantenimento di una catena di lavoro indipendente. La relazione di collegamento indica che oltre ad essere responsabile dello smistamento delle transazioni nella propria catena di lavoro, il nodo deve anche monitorare ed elaborare lo stato. cambiamenti nella catena di destinazione, che è specificamente implementata in TON monitorando i messaggi nella coda di output.
Supponiamo che l'account A nella catena di lavoro 1 desideri inviare un messaggio all'account C nella catena di lavoro 3. Quindi è necessario progettare il problema dell'instradamento dei messaggi. In questo esempio sono presenti due percorsi di instradamento, catena di lavoro 1 -> catena di lavoro 2-> catena di lavoro 3 e catena di lavoro 1 -> catena di lavoro 4 -> catena di lavoro 3.
Quando si affrontano situazioni più complesse, è necessario un algoritmo di routing efficiente e a basso costo per completare rapidamente la comunicazione dei messaggi. TON ha scelto il cosiddetto "algoritmo di routing dell'ipercubo" per realizzare il rilevamento del percorso di comunicazione dei messaggi a catena incrociata. La cosiddetta struttura dell'ipercubo si riferisce a una speciale topologia di rete. Un ipercubo n-dimensionale è composto da 2^n vertici e ciascun vertice può essere identificato in modo univoco da un numero binario di n bit. In questa struttura, due vertici qualsiasi sono adiacenti se differiscono di un solo bit nella rappresentazione binaria. Ad esempio, in un ipercubo tridimensionale, il vertice 000 e il vertice 001 sono adiacenti perché differiscono solo nell'ultimo bit. L'esempio sopra è un ipercubo bidimensionale.
Nel protocollo di instradamento dell'ipercubo, il processo di instradamento di un messaggio da una catena di lavoro di origine a una catena di lavoro di destinazione viene eseguito confrontando le rappresentazioni binarie della catena di lavoro di origine e degli indirizzi della catena di lavoro di destinazione. L'algoritmo di instradamento trova la distanza minima (ovvero il numero di bit diversi nella rappresentazione binaria) tra questi due indirizzi e inoltra progressivamente le informazioni attraverso catene di lavoro adiacenti fino a raggiungere la catena di lavoro target. Questo metodo garantisce che i pacchetti di dati vengano trasmessi lungo il percorso più breve, migliorando così l'efficienza di comunicazione della rete.
Naturalmente, per semplificare questo processo, TON ha anche proposto una soluzione tecnica ottimistica. Quando un utente può fornire una prova valida di un certo percorso di instradamento, che di solito è una radice merkle trie, il nodo può riconoscere direttamente la credibilità del percorso. messaggio inviato dalle proprietà dell'utente, noto anche come routing dell'ipercubo istantaneo.
Pertanto, possiamo vedere che ci sono evidenti differenze tra gli indirizzi in TON e altri protocolli blockchain. La maggior parte degli altri protocolli blockchain tradizionali utilizzano come indirizzo l'hash corrispondente alla chiave pubblica nelle chiavi pubblica e privata generata dall'algoritmo di crittografia ellittica. l'indirizzo viene utilizzato solo come indirizzo univoco. Non è necessario che esegua la funzione di indirizzamento del routing e l'indirizzo in TON è composto da due parti (workchain_id, account_id), dove workchain_id è codificato in base all'indirizzo dell'algoritmo di routing dell'ipercubo, che non verrà qui approfondito.
C'è un altro punto su cui è facile sollevare dubbi. Potresti aver notato che la catena principale ha una relazione di collegamento con ciascuna catena operativa, quindi non sarebbe sufficiente che tutte le informazioni incrociate fossero trasmesse attraverso la catena principale, semplicemente come Cosmo. Nel concetto di progettazione di TON, la catena principale viene utilizzata solo per gestire le attività più critiche, ovvero per mantenere la finalità di molte catene di lavoro. Non è impossibile instradare i messaggi attraverso la catena principale, ma i costi di gestione risultanti saranno molto costosi .
Infine, menzioniamo brevemente il suo algoritmo di consenso. TON adotta il metodo BFT+PoS, ovvero qualsiasi staker ha l'opportunità di partecipare al contratto di governance elettorale di TON selezionerà casualmente un verificatore di packaging da tutti gli Staker a intervalli regolari cluster, i nodi selezionati come validatori impacchetteranno e produrranno blocchi attraverso l'algoritmo BFT. Se impacchettano informazioni errate o fanno del male, i loro gettoni di puntata verranno persi e altrimenti riceveranno ricompense di blocco. Questa è fondamentalmente una scelta comune, quindi non la introdurrò qui.
Contratti intelligenti e ambiente di esecuzione completamente parallelo basato sul modello Actor
Un’altra differenza tra TON e i protocolli blockchain tradizionali è il suo ambiente di esecuzione del contratto intelligente. Per superare i limiti del TPS dei protocolli blockchain tradizionali, TON adotta un'idea di progettazione dal basso verso l'alto e utilizza il modello Actor per ricostruire i contratti intelligenti e i loro metodi di esecuzione, in modo che abbiano la capacità di essere completamente parallelizzati.
Sappiamo che la maggior parte dei protocolli blockchain tradizionali utilizzano un ambiente di esecuzione seriale a thread singolo. Prendendo come esempio Ethereum, il suo ambiente di esecuzione EVM è una macchina a stati con transazioni come input quando il nodo che produce il blocco completa la transazione impacchettando il blocco dopo l'ordinamento , le transazioni verranno eseguite tramite l'EVM in questo ordine. L'intero processo è completamente seriale e a thread singolo, ovvero è possibile eseguire solo una transazione alla volta confermato, il risultato dell'esecuzione sarà C'è coerenza in un'ampia gamma di cluster distribuiti. Allo stesso tempo, poiché viene eseguita solo una transazione in serie allo stesso tempo, ciò significa che durante il processo di esecuzione è impossibile per altre transazioni. modificare determinati dati statali a cui accedere, in modo da ottenere l'interoperabilità tra contratti intelligenti. Ad esempio, utilizziamo USDT per acquistare ETH tramite Uniswap. Quando la transazione viene eseguita, la distribuzione di LP nella coppia di scambio è un determinato valore. In questo modo, il risultato corrispondente può essere ottenuto attraverso determinati modelli matematici, ma supponendo che lo sia non è questo il caso, quando si esegue il calcolo di una determinata curva obbligazionaria, se altri LP aggiungono nuova liquidità, il risultato del calcolo sarà un risultato obsoleto, il che è ovviamente inaccettabile.
Ma questa architettura ha anche evidenti limitazioni, che rappresentano il collo di bottiglia del TPS, e questo collo di bottiglia appare molto vecchio con gli attuali processori multi-core Proprio come se si utilizzasse l'ultimo PC per giocare ad alcuni vecchi giochi per computer, come Red Alert, When the numero di unità combattenti raggiunge un certo livello, scoprirai che è comunque bloccato. Si tratta di un problema con l'architettura del software.
Potresti sentire che alcuni protocolli stanno già prestando attenzione a questo problema e hanno proposto le proprie soluzioni parallele Prendendo Solana, che attualmente afferma di avere il TPS più alto, ad esempio, ha anche la capacità di eseguire in parallelo. Tuttavia, la sua idea progettuale è diversa da TON, la sua idea principale è dividere tutte le transazioni in più gruppi in base alle dipendenze di esecuzione e nessun dato sullo stato viene condiviso tra i diversi gruppi. Cioè, non esistono dipendenze identiche, quindi le transazioni in gruppi diversi possono essere eseguite in parallelo senza preoccuparsi dei conflitti, mentre le transazioni all'interno dello stesso gruppo vengono ancora eseguite nella tradizionale modalità seriale.
In TON abbandona completamente l'architettura di esecuzione seriale e adotta invece un paradigma di sviluppo appositamente progettato per il parallelismo, il modello Actor, per ricostruire l'ambiente di esecuzione. Il cosiddetto modello dell'attore fu proposto per la prima volta da Carl Hewitt nel 1973 per risolvere la complessità dello stato condiviso nei tradizionali programmi concorrenti attraverso lo scambio di messaggi. Ogni attore ha il proprio stato e comportamento privati e nessuna informazione sullo stato viene condivisa con altri attori. Il modello Actor è un modello di calcolo simultaneo che implementa il calcolo parallelo attraverso lo scambio di messaggi. In questo modello, un "Attore" è l'unità di lavoro di base, in grado di elaborare i messaggi ricevuti, creare nuovi attori, inviare più messaggi e decidere come rispondere ai messaggi successivi. Il modello dell'attore deve avere le seguenti caratteristiche:
Incapsulamento e indipendenza: ogni attore è completamente indipendente durante l'elaborazione dei messaggi e può elaborarli in parallelo senza interferire tra loro.
Scambio di messaggi: gli attori interagiscono tra loro solo inviando e ricevendo messaggi e lo scambio di messaggi è asincrono.
Struttura dinamica: gli attori possono creare più attori in fase di esecuzione. Questa natura dinamica consente al modello di attore di ridimensionare il sistema in base alle esigenze.
TON adotta questa architettura per progettare modelli di contratto intelligente, il che significa che in TON ogni contratto intelligente è un modello di attore con spazio di archiviazione completamente indipendente. Perché non si basa su dati esterni. Inoltre, le chiamate allo stesso contratto intelligente vengono comunque eseguite in base all'ordine dei messaggi nella coda di ricezione, quindi le transazioni in TON possono essere eseguite in modo efficiente in parallelo senza preoccuparsi dei conflitti.
Tuttavia, un tale schema di progettazione porta anche alcuni nuovi impatti Per gli sviluppatori DApp, il loro paradigma di sviluppo abituale verrà rotto, come segue:
1. Chiamate asincrone tra contratti intelligenti: non è possibile chiamare atomicamente contratti esterni o accedere ai dati dei contratti esterni all'interno dei contratti intelligenti di TON. Sappiamo che in Solidity, la funzione 1 del contratto A chiama la funzione 2 del contratto B. Oppure accedere a determinati dati di stato attraverso la funzione di sola lettura n3 del contratto C. L'intero processo è atomico ed eseguito in una transazione Questa è una cosa molto semplice, tuttavia, in TON, ciò non sarà possibile. Tutte le interazioni con contratti intelligenti esterni verranno eseguite in modo asincrono impacchettando nuove transazioni. Tali transazioni avviate da contratti intelligenti sono anche chiamate messaggi interni. E non può essere bloccato durante l'esecuzione per ottenere risultati di esecuzione.
Ad esempio, se sviluppiamo un DEX, se adottiamo il paradigma comune in EVM, di solito ci sarà un contratto router unificato utilizzato per gestire l'instradamento delle transazioni e ciascun Pool gestisce in modo indipendente i dati LP relativi a una determinata coppia di trading attualmente ci sono due Pool USDT-DAI e DAI-ETH. Quando un utente desidera acquistare ETH direttamente tramite USDT, può richiedere in sequenza questi due pool in un'unica transazione tramite il contratto del router per completare una transazione atomica. Tuttavia, non è così facile da implementare in TON. È necessario pensare a un nuovo paradigma di sviluppo Se questo paradigma viene ancora riutilizzato, il flusso di informazioni potrebbe essere così. Questa richiesta sarà accompagnata da un messaggio esterno avviato da utente e tre messaggi interni sono completati (notare che questo viene utilizzato per illustrare la differenza. Nello sviluppo reale, anche il paradigma di ERC 20 dovrà essere riprogettato).
2. È necessario considerare attentamente il processo di elaborazione degli errori di esecuzione quando si chiamano tra contratti e progettare funzioni di rimbalzo corrispondenti per ciascuna chiamata intercontratto. Sappiamo che nell'EVM tradizionale, quando si verifica un problema durante l'esecuzione della transazione, l'intera transazione verrà ripristinata, ovvero ripristinata allo stato di esecuzione iniziale. Questo è facile da capire nel modello seriale a thread singolo. Tuttavia, in TON, poiché le chiamate tra contratti vengono eseguite in modo asincrono, anche se si verifica un errore in un collegamento successivo, poiché la transazione precedentemente eseguita con successo è già stata eseguita e confermata, ciò potrebbe causare problemi. Pertanto, in TON viene impostato un tipo di messaggio speciale, chiamato messaggio di rimbalzo, ovvero quando si verifica un errore nel successivo processo di esecuzione attivato da un messaggio interno, il contratto attivato può attivare un determinato evento nel contratto attivando il rimbalzo. funzione riservata dal contratto. Alcuni stati vengono ripristinati.
3. In alcune situazioni complesse, la transazione ricevuta per prima potrebbe non essere eseguita per prima, quindi questa relazione temporale non può essere preimpostata. In un tale sistema di chiamate di contratti intelligenti asincrone e parallele, definire l’ordine in cui le operazioni vengono elaborate può essere difficile. Questo è il motivo per cui ogni messaggio in TON ha il suo tempo logico Lamport time (di seguito denominato lt). Viene utilizzato per capire quale evento ne ha attivato un altro e cosa deve prima gestire il validatore. Per un modello semplice, la transazione ricevuta per prima deve essere eseguita per prima.
In questo modello, A e B rappresentano rispettivamente due contratti intelligenti e esiste una relazione temporale di if msg 1 _lt < msg 2 _lt, quindi tx 1 _lt < tx 2 _lt.
Tuttavia, in situazioni più complesse, questa regola viene infranta. Ce n'è un esempio nella documentazione ufficiale, supponendo di avere tre contratti A, B e C. In una transazione, A invia due messaggi interni msg 1 e msg 2: uno a B e l'altro a C. Sebbene vengano creati nell'ordine esatto (prima msg 1 , poi msg 2 ), non possiamo essere sicuri che msg 1 venga elaborato prima di msg 2 . Questo perché i percorsi da A a B e da A a C possono differire per lunghezza e set di validatori. Se questi contratti si trovano su catene di shard diverse, uno dei messaggi potrebbe richiedere diversi blocchi per raggiungere il contratto di destinazione. Cioè, abbiamo due possibili percorsi commerciali, come mostrato nella figura.
4. In TON, l'archiviazione persistente dei suoi contratti intelligenti utilizza un grafico aciclico diretto con Cell come unità come struttura dei dati. I dati verranno compressi in modo compatto in una Cell secondo le regole di codifica e allo stesso tempo secondo grafico aciclico diretto. Il percorso si estende verso il basso, il che è diverso dall'organizzazione strutturale dei dati di stato basata su hashmap in EVM. A causa dei diversi algoritmi di richiesta dati, TON imposta prezzi del gas diversi per diverse profondità di elaborazione dei dati , più Gas richiede, più alto, quindi esiste un paradigma di attacco DOS in TON, ovvero alcuni utenti malintenzionati occupano tutte le celle superficiali in un determinato contratto intelligente inviando un gran numero di messaggi di spam, il che significa che il il costo di archiviazione degli utenti onesti diventerà sempre più elevato. In EVM, poiché la complessità della query di hashmap è o(1), ha lo stesso Gas e non ci saranno problemi simili. Pertanto, gli sviluppatori TON Dapp dovrebbero cercare di evitare tipi di dati illimitati nei contratti intelligenti. Quando vengono visualizzati tipi di dati illimitati, è necessario suddividerli tramite lo sharding.
5. Ci sono anche alcune funzionalità meno speciali, come i contratti intelligenti che devono pagare l'affitto per l'archiviazione, i contratti intelligenti in TON sono naturalmente aggiornabili e le funzioni di account astratte native, ovvero tutti gli indirizzi del portafoglio in TON sono contratti intelligenti, semplicemente non inizializzato, ecc. Questi richiedono agli sviluppatori di prestare molta attenzione.
Quanto sopra sono alcune delle mie esperienze nell'apprendimento delle tecnologie relative a TON durante questo periodo. Vorrei condividerle con te. Spero che tu possa correggermi se commetto errori. Allo stesso tempo, penso che con le enormi risorse di traffico di Telegram , l'ecosistema TON fungerà sicuramente da piattaforma per Web3 portando alcune nuove applicazioni, anche gli amici interessati allo sviluppo di TON DApp possono contattarmi e discutere con noi.