Autor: @Web3Mario

Introducere: Odată cu lansarea Notcoin, cel mai mare joc din ecosistemul TON, pe Binance și efectul uriaș de bogăție cauzat de modelul economic cu jetoane cu circulație completă, TON a câștigat o mare atenție într-o perioadă scurtă de timp. După ce am discutat cu un prieten, am aflat că pragul tehnic al TON este relativ ridicat, iar paradigma de dezvoltare DApp este foarte diferită de protocoalele de lanț public mainstream, așa că am petrecut ceva timp făcând cercetări aprofundate pe subiecte conexe și v-am împărtășit câteva perspective. Pe scurt, conceptul de bază al TON este de a reconstrui protocolul blockchain tradițional într-o manieră „de jos în sus” și de a obține o concurență ridicată și o scalabilitate ridicată în detrimentul interoperabilității.

Ideea de bază a designului TON - concurență ridicată și scalabilitate ridicată

Se poate spune că scopul tuturor selecțiilor tehnologice complexe din TON provine din urmărirea concurenței ridicate și a unei scalabilitati ridicate. Desigur, nu este dificil pentru noi să înțelegem acest lucru din contextul nașterii sale. TON, sau The Open Network, este o rețea de calcul descentralizată care conține un blockchain L1 și mai multe componente. TON a fost dezvoltat inițial de fondatorul Telegram, Nikolai Durov și echipa sa, iar acum este susținut și întreținut de o comunitate globală de colaboratori independenți. Nașterea sa datează din 2017, când echipa Telegram a început să exploreze singure soluții blockchain. Întrucât niciun blockchain L1 existent la acea vreme nu putea susține baza de utilizatori din nouă cifre a Telegram, ei au decis să-și creeze propriul blockchain, numit atunci Telegram Open Network. A venit vremea în 2018. Pentru a obține resursele necesare implementării TON, Telegram a lansat vânzarea de jetoane Gram (redenumite ulterior Toncoin) în primul trimestru al anului 2018. În 2020, echipa Telegram s-a retras din proiectul TON din cauza unor probleme de reglementare. Ulterior, un mic grup de dezvoltatori open source și câștigători ai competiției Telegram au preluat baza de coduri a TON, au redenumit proiectul în The Open Network și continuă să dezvolte în mod activ blockchain-ul până în prezent, aderând la principiile prezentate în cartea albă TON originală.

Deci, deoarece este proiectat ca mediu de execuție descentralizat al Telegram, trebuie să se confrunte în mod natural cu două probleme, solicitări concomitente ridicate și date masive. Știm că, odată cu dezvoltarea tehnologiei până în prezent, Solana, care este cunoscut ca cel mai înalt TPS cel mai mare TPS măsurat de doar 65.000, ceea ce, evident, nu este suficient pentru a susține ecosistemul Telegram care necesită milioane de TPS. În același timp, cu aplicația pe scară largă a Telegramului, cantitatea de date pe care o generează a depășit deja cerul Ca sistem distribuit extrem de redundant, blockchain necesită ca fiecare nod din rețea să salveze o copie completă a datelor de asemenea, nerealist.

Prin urmare, pentru a rezolva cele două probleme de mai sus, TON a făcut două optimizări la protocoalele blockchain mainstream:

  • Folosind „Infinite Sharding Paradigm” pentru a proiecta sistemul, rezolvăm problema redundanței datelor, astfel încât să poată transporta date mari și să atenueze problema blocajului de performanță;

  • Prin introducerea unui mediu de execuție complet paralel bazat pe modelul Actor, TPS-ul de rețea este mult îmbunătățit;

Faceți un lanț blockchain - prin capabilități nelimitate de sharding, fiecare cont are un lanț de conturi exclusiv

Știm acum că sharding-ul a devenit soluția principală pentru majoritatea protocoalelor blockchain pentru a îmbunătăți performanța și a reduce costurile, iar TON a dus acest lucru la extrem și a propus paradigma infinite sharding, așa-numita paradigmă infinite sharding crește sau reduce în mod dinamic numărul de fragmente în funcție de încărcarea rețelei. Această paradigmă permite TON să gestioneze tranzacțiile la scară largă și operațiunile de contracte inteligente, menținând în același timp o performanță ridicată. În teorie, TON poate stabili un lanț de conturi exclusiv pentru fiecare cont și poate asigura interoperabilitatea între aceste lanțuri prin anumite reguli.

Pentru a înțelege în mod abstract, există patru straturi de structură în lanț în TON:

  • Lanț de conturi: Acest lanț de straturi reprezintă un lanț compus dintr-o serie de tranzacții legate de un cont. Motivul pentru care tranzacțiile pot forma o structură în lanț este că pentru o mașină de stat, atâta timp cât regulile de execuție sunt consecvente, mașina de stat va. rezultatele obținute după primirea instrucțiunilor în aceeași secvență sunt consistente. Prin urmare, ordonarea în lanț a tranzacțiilor este necesară în toate sistemele distribuite blockchain, iar TON nu face excepție. Lanțul de conturi este cea mai de bază componentă a rețelei TON. De obicei, lanțul de conturi este un concept virtual și este puțin probabil ca un lanț de conturi independent să existe.

  • Lanțul de fragmente: în majoritatea contextelor, lanțul de fragmente este unitatea componentă reală în TON. Așa-numitul lanț de fragmente este o colecție de lanțuri de conturi.

  • WorkChain: poate fi numit și un set de lanțuri sharding cu reguli personalizate, cum ar fi crearea unui lanț de lucru bazat pe EVM și rularea de contracte inteligente Solidity pe acesta. În teorie, toată lumea din comunitate își poate crea propriul lanț de muncă. De fapt, construirea acestuia este o sarcină destul de complexă, precedată de plata taxei (costisitoare) pentru a-l crea și de obținerea a 2/3 din voturi de la validatori pentru a aproba crearea lanțului tău de lucru.

  • Lanț principal (MasterChain): În cele din urmă, există un lanț special în TON numit lanț principal, care este responsabil pentru aducerea finalității tuturor lanțurilor shard. Odată ce hash-ul unui bloc al lanțului de cioburi este îmbinat în blocul lanțului principal, acel bloc de lanț shard și toate blocurile sale părinte sunt considerate definitive, ceea ce înseamnă că pot fi considerate fixe și de nedespărțit lanţuri.

Prin adoptarea unei astfel de paradigme, rețeaua TON are următoarele trei caracteristici:

  • Fragmentare dinamică: TON poate diviza și îmbina automat lanțurile de fragmente pentru a se adapta la schimbările de încărcare. Aceasta înseamnă că noile blocuri sunt întotdeauna generate rapid și tranzacțiile nu implică timpi lungi de așteptare.

  • Foarte scalabil: prin paradigma de fragmentare infinită, TON poate suporta un număr aproape nelimitat de fragmente și, teoretic, poate ajunge la 2 până la a 60-a putere a lanțurilor de lucru.

  • Adaptabilitate: Când sarcina crește pe o parte a rețelei, acea parte poate fi subdivizată în mai multe fragmente pentru a gestiona volumul crescut de tranzacții. În schimb, atunci când sarcina scade, cioburi pot fi îmbinate pentru a crește eficiența.

Apoi, primul lucru cu care trebuie să se confrunte un astfel de sistem cu mai multe lanțuri este problema comunicării încrucișate, în special datorită capacității de fragmentare nelimitată atunci când numărul de fragmente din rețea atinge un anumit nivel, rutarea informațiilor între lanțuri va deveni un lucru dificil de făcut. Imaginați-vă că există 4 noduri în rețea. Fiecare nod este responsabil pentru menținerea unui lanț de lucru independent. modificări în lanțul țintă, implementate în TON în mod specific prin monitorizarea mesajelor din coada de ieșire,

Să presupunem că contul A din lanțul de lucru 1 dorește să trimită un mesaj către contul C din lanțul de lucru 3. Trebuie să proiectați problema de rutare a mesajelor În acest exemplu, există două căi de rutare, lanțul de lucru 1 -> lanțul de lucru 2 -> lanțul de lucru 3 și lanțul de lucru 1 -> lanțul de lucru 4 -> lanțul de lucru 3.

Când se confruntă cu situații mai complexe, este necesar un algoritm de rutare eficient și cu costuri reduse pentru a finaliza rapid comunicarea mesajelor TON a ales așa-numitul „algoritm de rutare hipercub” pentru a realiza descoperirea rutei de comunicare a mesajelor încrucișate. Așa-numita structură de hipercub se referă la o topologie de rețea specială. Un hipercub n-dimensional este compus din 2^n vârfuri, iar fiecare vârf poate fi identificat în mod unic printr-un număr binar de n biți. În această structură, oricare două vârfuri sunt adiacente dacă diferă doar cu un bit în reprezentarea binară. De exemplu, într-un hipercub 3D, vârful 000 și vârful 001 sunt adiacente, deoarece diferă doar în ultimul bit. Exemplul de mai sus este un hipercub bidimensional.

În protocolul de rutare hypercube, procesul de rutare a unui mesaj de la un lanț de lucru sursă la un lanț de lucru țintă este realizat prin compararea reprezentărilor binare ale lanțului de lucru sursă și adresele lanțului de lucru țintă. Algoritmul de rutare găsește distanța minimă (adică numărul de biți diferiți în reprezentarea binară) dintre aceste două adrese și transmite progresiv informațiile prin lanțurile de lucru adiacente până când lanțul de lucru țintă este atins. Această metodă asigură că pachetele de date sunt transmise pe calea cea mai scurtă, îmbunătățind astfel eficiența comunicării rețelei.

Desigur, pentru a simplifica acest proces, TON a propus și o soluție tehnică optimistă. Atunci când un utilizator poate furniza o dovadă validă a unei anumite căi de rutare, care este de obicei o rădăcină merkle trie, nodul poate recunoaște în mod direct credibilitatea. mesaj trimis de utilizator, acesta este cunoscut și sub numele de rutare instant hypercube.

Prin urmare, putem vedea că există diferențe evidente între adresele din TON și alte protocoale blockchain Majoritatea celorlalte protocoale blockchain mainstream folosesc hash-ul corespunzător cheii publice din cheile publice și private generate de algoritmul de criptare eliptică ca adresă. adresa este folosită doar ca o adresă unică. Nu este necesar să transporte funcția de direcționare de rutare, iar adresa din TON constă din două părți (workchain_id, account_id), unde workchain_id este codificat în funcție de adresa algoritmului de rutare hypercube. nu va fi elaborat aici.

Există un alt punct care este ușor de ridicat îndoieli. Poate că ați observat că lanțul principal are o relație de verigă cu fiecare lanț de lucru, așa că nu ar fi suficient ca toate informațiile încrucișate să fie transmise prin lanțul principal, doar. ca Cosmos. În conceptul de design al TON, lanțul principal este folosit doar pentru a gestiona cele mai critice sarcini, adică menținerea finalității multor lanțuri de lucru .

În cele din urmă, să menționăm pe scurt algoritmul său de consens TON adoptă metoda BFT+PoS, adică orice staker are posibilitatea de a participa la contractul de guvernare a alegerilor TON va selecta aleatoriu un verificator de ambalare din toți Stakers cluster, nodurile selectate ca validatori vor împacheta și vor produce blocuri prin algoritmul BFT Dacă împachetează informații incorecte sau fac rău, jetoanele lor mizate vor fi pierdute, iar în caz contrar vor primi recompense de bloc. Aceasta este practic o alegere comună, așa că nu o voi prezenta aici.

Contracte inteligente și mediu de execuție complet paralel bazat pe modelul Actor

Un alt punct din TON care este diferit de protocoalele blockchain mainstream este mediul său inteligent de execuție a contractelor. Pentru a depăși limitările protocolului blockchain TPS, TON a adoptat o idee de design de jos în sus și a folosit modelul Actor pentru a reconstrui contractele inteligente și metodele lor de execuție, oferindu-le posibilitatea de a fi paralelizate complet.

Știm că majoritatea protocoalelor de tip blockchain folosesc un mediu de execuție serial cu un singur thread, luând ca exemplu Ethereum, mediul său de execuție EVM este o mașină de stat cu tranzacții ca intrare când nodul care produce blocul finalizează tranzacția prin împachetarea blocului , tranzacțiile vor fi executate prin EVM în această ordine. Întregul proces este complet în serie și cu un singur thread, adică doar o singură tranzacție poate fi executată la un anumit moment confirmat, rezultatul execuției va fi. Există consecvență într-o gamă largă de clustere distribuite În același timp, deoarece o singură tranzacție este executată în serie în același timp, aceasta înseamnă că în timpul procesului de execuție, este imposibil ca alte tranzacții. modificați anumite date de stat pentru a fi accesate, astfel încât să se realizeze interoperabilitatea între contractele inteligente. De exemplu, folosim USDT pentru a cumpăra ETH prin Uniswap Când tranzacția este executată, distribuția LP în perechea de tranzacționare este o anumită valoare. În acest fel, rezultatul corespunzător poate fi obținut prin anumite modele matematice, dar presupunând că este nu este cazul, atunci când se efectuează calculul unei anumite curbe de legare, dacă alte LP-uri adaugă lichiditate nouă, rezultatul calculului va fi un rezultat învechit, ceea ce este evident inacceptabil.

Dar această arhitectură are, de asemenea, limitări evidente, care este blocajul TPS, iar acest blocaj pare foarte vechi sub procesoarele multi-core actuale numărul de unități de luptă ajunge la un anumit nivel, veți găsi în continuare că este blocat Aceasta este o problemă cu arhitectura software.

S-ar putea să auzi că unele protocoale acordă deja atenție acestei probleme și și-au propus propriile soluții paralele Luând Solana, care în prezent susține că are cel mai mare TPS, ca exemplu, are și capacitatea de a se executa în paralel. Cu toate acestea, ideea sa de design este diferită de TON. În Solana, ideea sa de bază este de a împărți toate tranzacțiile în mai multe grupuri în funcție de dependențele de execuție și nu sunt partajate date de stat între diferite grupuri. Adică, nu există dependențe identice, astfel încât tranzacțiile în grupuri diferite pot fi executate în paralel fără a vă face griji cu privire la conflicte, în timp ce tranzacțiile din cadrul aceluiași grup sunt încă executate în mod tradițional în serie.

În TON, abandonează complet arhitectura de execuție în serie și adoptă în schimb o paradigmă de dezvoltare special concepută pentru paralelism, modelul Actor, pentru a reconstrui mediul de execuție. Așa-numitul model Actor a fost propus pentru prima dată de Carl Hewitt în 1973 pentru a rezolva complexitatea stării partajate în programele concurente tradiționale prin transmiterea mesajelor. Fiecare actor are propria stare și comportament privat și nu împărtășește nicio informație de stat cu alți actori. Modelul Actor este un model de calcul concurent care implementează calculul paralel prin transmiterea de mesaje. În acest model, un „Actor” este unitatea de bază de lucru, capabilă să proceseze mesajele primite, să creeze noi Actori, să trimită mai multe mesaje și să decidă cum să răspundă la mesajele ulterioare. Modelul de actor trebuie să aibă următoarele caracteristici:

  • Încapsulare și independență: Fiecare actor este complet independent atunci când procesează mesaje și poate procesa mesaje în paralel fără a interfera unul cu celălalt.

  • Transmiterea mesajelor: actorii interacționează între ei doar trimițând și primind mesaje, iar transmiterea mesajelor este asincronă.

  • Structura dinamică: Actorii pot crea mai mulți actori în timpul rulării. Această natură dinamică permite modelului Actor să extindă sistemul după cum este necesar.

 

TON adoptă această arhitectură pentru a proiecta modele de contracte inteligente, ceea ce înseamnă că în TON, fiecare contract inteligent este un model Actor cu spațiu de stocare complet independent. Pentru că nu se bazează pe date externe. În plus, apelurile către același contract inteligent sunt încă executate în funcție de ordinea mesajelor din coada de primire, astfel încât tranzacțiile în TON pot fi executate eficient în paralel, fără a vă face griji pentru conflicte.

Cu toate acestea, o astfel de schemă de proiectare aduce și unele impacturi noi Pentru dezvoltatorii DApp, paradigma lor obișnuită de dezvoltare va fi ruptă, după cum urmează:

1. Apeluri asincrone între contractele inteligente: Nu este posibil să apelați atomic contracte externe sau să accesați datele contractelor externe în cadrul contractelor inteligente ale TON. Știm că în Solidity, funcția1 a contractului A apelează funcția2 a contractului B sau prin funcția de doar citire 3 din contractul C accesează anumite date de stat. Întregul proces este atomic și executat într-o tranzacție. Acesta este un lucru foarte ușor. Cu toate acestea, în TON, acest lucru nu va fi posibil, iar orice interacțiune cu inteligența externă se va executa asincron. prin ambalarea unor noi tranzacții, astfel de tranzacții inițiate prin contracte inteligente se mai numesc și mesaje interne. Și nu poate fi blocat în timpul execuției pentru a obține rezultate ale execuției.

De exemplu, dacă dezvoltăm un DEX, dacă adoptăm paradigma comună în EVM, va exista de obicei un contract de router unificat utilizat pentru a gestiona rutarea tranzacțiilor și fiecare Pool gestionează în mod independent datele LP legate de o anumită pereche de tranzacționare În prezent există două grupuri sunt USDT-DAI și DAI-ETH. Când un utilizator dorește să achiziționeze ETH direct prin USDT, el sau ea poate solicita secvențial aceste două pool-uri într-o singură tranzacție prin contractul de router pentru a finaliza o tranzacție atomică. Cu toate acestea, nu este atât de ușor de implementat în TON. Trebuie să ne gândim la o nouă paradigmă de dezvoltare Dacă încă reutilizam această paradigmă, fluxul de informații poate fi însoțit de un mesaj extern și trei mesaje interne sunt completate (rețineți că acesta este folosit pentru a ilustra diferența. În dezvoltarea reală, chiar și paradigma ERC20 trebuie reproiectată).

2. Este necesar să luați în considerare cu atenție procesul de gestionare a erorilor de execuție atunci când apelați peste contracte și să proiectați funcțiile de respingere corespunzătoare pentru fiecare apel inter-contract. Știm că în EVM mainstream, atunci când se întâlnește o problemă în timpul execuției tranzacției, întreaga tranzacție va fi anulată, adică va fi resetată la starea inițială de execuție. Acest lucru este ușor de înțeles în modelul serial cu un singur fir. Totuși, în TON, deoarece apelurile între contracte sunt executate asincron, chiar dacă apare o eroare într-o legătură ulterioară, deoarece tranzacția executată cu succes anterior a fost deja executată și confirmată, acest lucru poate cauza probleme. Prin urmare, în TON este configurat un tip de mesaj special, numit mesaj de respingere, adică atunci când apare o eroare în procesul de execuție ulterior declanșat de un mesaj intern, contractul declanșat poate declanșa un anumit mesaj în contract prin funcția de respingere. rezervate prin contractul de declanșare.

3. În unele situații complexe, tranzacția primită prima poate să nu fie executată prima, astfel încât această relație de timp nu poate fi prestabilită. Într-un astfel de sistem de apeluri smart contract asincrone și paralele, definirea ordinii în care sunt procesate operațiunile poate fi dificilă. Acesta este motivul pentru care fiecare mesaj în TON are timpul său logic, ora Lamport (denumit în continuare lt). Este folosit pentru a înțelege ce eveniment a declanșat altul și ce trebuie să se ocupe mai întâi validatorul. Pentru un model simplu, tranzacția primită trebuie mai întâi executată.

În acest model, A și B reprezintă, respectiv, două contracte inteligente și există o relație de timp astfel încât dacă msg1_lt < msg2_lt, atunci tx1_lt < tx2_lt.

Cu toate acestea, în situații mai complexe, această regulă este încălcată. Există un exemplu în documentația oficială. Să presupunem că avem trei contracte A, B și C. Într-o tranzacție, A trimite două mesaje interne msg1 și msg2: unul către B și celălalt către C. Deși sunt create în ordinea exactă (msg1 mai întâi, apoi msg2), nu putem fi siguri că msg1 va fi procesat înainte de msg2. Acest lucru se datorează faptului că rutele de la A la B și de la A la C pot diferi ca lungime și setul de validator. Dacă aceste contracte sunt pe diferite lanțuri shard, unul dintre mesaje poate dura mai multe blocuri pentru a ajunge la contractul țintă. Adică, avem două căi posibile de tranzacționare, așa cum se arată în figură.

4. În TON, stocarea persistentă a contractelor sale inteligente utilizează un grafic aciclic direcționat cu Cell ca unitate ca structură de date Graficul aciclic direcționat se extinde în jos, ceea ce este diferit de organizarea structurală bazată pe hashmap a datelor din EVM Datorită diferiților algoritmi de solicitare a datelor, TON stabilește prețuri diferite de procesare a datelor cu cât este mai profundă , cu cât necesită mai mult Gas, cu atât este mai mare, deci există o paradigmă de atac DOS în TON, adică unii utilizatori rău intenționați ocupă toate celulele superficiale dintr-un anumit contract inteligent prin trimiterea unui număr mare de mesaje spam, ceea ce înseamnă că costul de stocare al utilizatorilor cinstiți va deveni din ce în ce mai scump. În EVM, deoarece complexitatea interogării hashmap este o(1), are același gaz și nu vor exista probleme similare. Prin urmare, dezvoltatorii TON Dapp ar trebui să încerce să evite tipurile de date nelimitate în contractele inteligente. Când apar tipuri de date nelimitate, acestea ar trebui să fie împărțite prin sharding.

5. Există, de asemenea, unele caracteristici care sunt mai puțin speciale, cum ar fi contractele inteligente care trebuie să plătească chiria pentru stocare, contractele inteligente din TON pot fi actualizate în mod natural și funcțiile de cont abstracte native, adică toate adresele portofelului din TON sunt contracte inteligente , pur și simplu nu sunt inițializate etc. Acestea necesită ca dezvoltatorii să acorde o atenție deosebită.

Cele de mai sus sunt câteva dintre experiențele mele în ceea ce privește învățarea tehnologiilor legate de TON în această perioadă, aș dori să le împărtășesc cu voi resurse, ecosistemul TON va oferi cu siguranță o platformă pentru Web3 Aducând niște aplicații noi, prietenii care sunt interesați de dezvoltarea TON DApp mă pot contacta și discuta cu noi.

X Link-uri: https://x.com/web3_mario