Deze tekst is een voortzetting van een reeks artikelen waarin ik de structuur onderzoek van het (vermoedelijk) gedistribueerde netwerk Telegram Open Network (TON), dat wordt voorbereid voor release dit jaar. IN Ik heb het meest basale niveau beschreven: de manier waarop knooppunten met elkaar omgaan.
Voor het geval dat, laat me je eraan herinneren dat ik niets te maken heb met de ontwikkeling van dit netwerk en dat al het materiaal afkomstig is van een open (zij het niet-geverifieerde) bron - (Er is ook een begeleidende versie , waarin de hoofdpunten kort worden uiteengezet), dat eind vorig jaar verscheen. De hoeveelheid informatie in dit document geeft naar mijn mening de authenticiteit ervan aan, hoewel hiervan geen officiële bevestiging bestaat.
Vandaag zullen we kijken naar het hoofdbestanddeel van TON: de blockchain.
Basisconcepten
Rekening (account). Een set gegevens die wordt geïdentificeerd door een getal van 256 bits Account ID (meestal is dit de publieke sleutel van de accounteigenaar). In het basisscenario (zie hieronder nul werkketen), hebben deze gegevens betrekking op het saldo van de gebruiker. Specifiek voor ‘bezetten’ Account ID iedereen kan dat, maar de waarde ervan kan alleen volgens bepaalde regels worden gewijzigd.
Slim contract (slim contract). In wezen is het een speciaal geval van een account, aangevuld met slimme contractcode en opslag van de variabelen ervan. Als je in het geval van een ‘portemonnee’ er geld uit kunt storten en opnemen volgens relatief eenvoudige en vooraf bepaalde regels, dan zijn deze regels in het geval van een slim contract geschreven in de vorm van de code ervan (in een bepaalde Turing-complete versie). programmeertaal).
Blockchain-staat (staat van blockchain). De reeks statussen van alle accounts/slimme contracten (in abstracte zin een hashtabel, waarbij de sleutels account-ID's zijn en de waarden de gegevens zijn die in de accounts zijn opgeslagen).
bericht (Bericht). Hierboven gebruikte ik de uitdrukking “credit- en debitgeld” - dit is een specifiek voorbeeld van een bericht (“overboeking N gram van account rekening_1 per rekening rekening_2"). Het is duidelijk dat alleen het knooppunt dat eigenaar is van de privésleutel van het account een dergelijk bericht kan verzenden rekening_1 - en dit kunnen bevestigen met een handtekening. Het resultaat van het bezorgen van dergelijke berichten op een gewoon account is een verhoging van het saldo, en het resultaat van het slimme contract is de uitvoering van de code (die de ontvangst van het bericht verwerkt). Uiteraard zijn ook andere berichten mogelijk (geen geldbedragen overdragen, maar willekeurige gegevens tussen slimme contracten).
Transactie (transactie). Het feit dat een bericht wordt afgeleverd, wordt een transactie genoemd. Transacties veranderen de toestand van de blockchain. Het zijn transacties (berichtenbezorgingsrecords) die de blokken in de blockchain vormen. In dit opzicht kun je de status van de blockchain zien als een incrementele database; alle blokken zijn ‘diffs’ die opeenvolgend moeten worden toegepast om de huidige status van de database te verkrijgen. De details van het verpakken van deze “diffs” (en het herstellen van de volledige staat ervan) zullen in het volgende artikel worden besproken.
Blockchain in TON: wat is het en waarom?
Zoals vermeld in het vorige artikel, blockchain is een datastructuur waarvan de elementen (blokken) in een ‘keten’ zijn geordend, en elk volgend blok van de keten bevat een hash van het vorige. In de commentaren werd de vraag gesteld: waarom hebben we überhaupt zo'n datastructuur nodig als we al een DHT hebben - een gedistribueerde hashtabel? Uiteraard kunnen sommige gegevens in DHT worden opgeslagen, maar dit is alleen geschikt voor niet al te “gevoelige” informatie. Cryptocurrency-saldi kunnen niet worden opgeslagen in DHT, voornamelijk vanwege het gebrek aan controles integriteit. Eigenlijk groeit de hele complexiteit van de blockchain-structuur om interferentie met de daarin opgeslagen gegevens te voorkomen.
De blockchain in TON ziet er echter nog complexer uit dan in de meeste andere gedistribueerde systemen – en wel om twee redenen. De eerste is de wens om de noodzaak ervan te minimaliseren vorken. In traditionele cryptocurrencies worden alle parameters in de beginfase vastgelegd en elke poging om deze te veranderen leidt feitelijk tot de opkomst van een ‘alternatief cryptocurrency-universum’. De tweede reden is ondersteuning voor verplettering (scherven, scherven) blockchain. Blockchain is een structuur die in de loop van de tijd niet kleiner kan worden; en meestal wordt elk knooppunt dat verantwoordelijk is voor de werking van het netwerk gedwongen dit volledig op te slaan. In traditionele (gecentraliseerde) systemen wordt sharding gebruikt om dergelijke problemen op te lossen: sommige records in de database bevinden zich op de ene server, andere op een andere, enz. In het geval van cryptocurrencies is dergelijke functionaliteit nog steeds vrij zeldzaam - vooral vanwege het feit dat het moeilijk is om sharding toe te voegen aan een systeem waar dit oorspronkelijk niet was gepland.
Hoe is TON van plan beide bovenstaande problemen op te lossen?
Blockchain-inhoud. Werkketens.
Laten we eerst eens kijken naar wat er in de blockchain zal worden opgeslagen. De statussen van accounts (“wallets” in het basisscenario) en slimme contracten zullen daar worden opgeslagen (voor de eenvoud gaan we ervan uit dat dit hetzelfde is als accounts). In wezen zal dit een gewone hashtabel zijn - de sleutels daarin zullen identificatiegegevens zijn Account ID, en waarden zijn datastructuren die zaken bevatten als:
- balans;
- slimme contractcode (alleen voor slimme contracten);
- opslag van slimme contractgegevens (alleen voor slimme contracten);
- statistieken;
- (facultatief) publieke sleutel voor overboekingen vanaf de rekening, standaard account_id;
- wachtrij met uitgaande berichten (hier worden ze ingevoerd om door te sturen naar de ontvanger);
- een lijst met de laatste berichten die op dit account zijn afgeleverd.
Zoals hierboven vermeld, bestaan de blokken zelf uit transacties: berichten die worden afgeleverd bij verschillende account_id-accounts. Naast account_id bevatten berichten echter ook een 32-bits veld werkketen_id — zogenaamde identificatie werkketen (werkketen, werkende blockchain). Hierdoor kun je meerdere blockchains onafhankelijk van elkaar hebben met verschillende configuraties. In dit geval wordt workchain_id = 0 als een speciaal geval beschouwd, nul werkketen – het zijn de saldi daarin die overeenkomen met de cryptocurrency TON (Grams). Hoogstwaarschijnlijk zullen andere werkketens in eerste instantie helemaal niet bestaan.
Shardchains. Oneindige Sharding-paradigma.
Maar daar houdt de groei van het aantal blockchains niet op. Laten we het over sharding hebben. Laten we ons voorstellen dat aan elk account (account_id) een eigen blockchain wordt toegewezen – deze bevat alle berichten die ernaartoe komen – en dat de statussen van al dergelijke blockchains op afzonderlijke knooppunten worden opgeslagen.
Dit is natuurlijk erg verspillend: hoogstwaarschijnlijk in elk van deze schervenketens (scherfketen, Shard-blockchain) transacties zullen zeer zelden aankomen, en er zullen veel krachtige knooppunten nodig zijn (vooruitkijkend merk ik op dat we het niet alleen hebben over clients op mobiele telefoons, maar over serieuze servers).
Daarom combineren shardchains accounts op basis van de binaire voorvoegsels van hun ID's: als een shardchain het voorvoegsel 0110 heeft, omvat deze transacties van alle account_ids die met deze nummers beginnen. Dit scherf_voorvoegsel kan een lengte hebben van 0 tot 60 bits - en het belangrijkste is dat het dynamisch kan veranderen.
Zodra een van de shardchains te veel transacties begint te ontvangen, 'splitsen' de knooppunten die eraan werken, volgens vooraf bepaalde regels, deze in twee kinderen - hun voorvoegsels zullen een beetje langer zijn (en voor een van hen zal dit bit zijn gelijk aan 0, en voor de andere - 1). Bijvoorbeeld, scherf_voorvoegsel = 0110b zal splitsen in 01100b en 01101b. Als twee ‘naburige’ shardchains zich op hun beurt (een tijdje) op hun gemak gaan voelen, zullen ze weer samensmelten.
Het sharden gebeurt dus “van onderaf” - we gaan ervan uit dat elk account zijn eigen shard heeft, maar voorlopig zijn ze door voorvoegsels “aan elkaar gelijmd”. Dit is wat het betekent Oneindige Sharding-paradigma (oneindig sharding-paradigma).
Los daarvan zou ik willen benadrukken dat werkketens alleen virtueel bestaan – sterker nog: werkketen_id het maakt deel uit van de identificatie van een specifieke shardchain. In formele termen wordt elke shardchain gedefinieerd door een paar cijfers (werkketen_id, scherf_voorvoegsel).
Foutcorrectie. Verticale blockchains.
Traditioneel wordt elke transactie op een blockchain beschouwd als ‘in steen gebeiteld’. In het geval van TON is het echter mogelijk om “de geschiedenis te herschrijven” - voor het geval iemand (de zogenaamde. vissers knoop) zal bewijzen dat een van de blokken verkeerd is ondertekend. In dit geval wordt een speciaal correctieblok toegevoegd aan de overeenkomstige shardchain, met daarin de hash van het blok zelf dat wordt gecorrigeerd (en niet het laatste blok in de shardchain). Als we de shardchain beschouwen als een ketting van horizontaal opgestelde blokken, kunnen we zeggen dat het corrigerende blok niet aan de rechterkant, maar van bovenaf aan het foutieve blok is bevestigd. Er wordt dus aangenomen dat het onderdeel wordt van een kleine “verticale blockchain”. . We kunnen dus zeggen dat shardchains dat wel zijn tweedimensionale blockchains.
Als na een foutief blok naar de door het blok aangebrachte wijzigingen wordt verwezen door volgende blokken (d.w.z. er zijn nieuwe transacties gemaakt op basis van ongeldige transacties), worden er ook corrigerende transacties “bovenaan” aan deze blokken toegevoegd. Als de blokken geen invloed hadden op de “getroffen” informatie, zijn deze “correctiegolven” niet op hen van toepassing. In de bovenstaande illustratie werd bijvoorbeeld de transactie van het eerste blok, waarbij het saldo van rekening C werd verhoogd, als onjuist herkend. Daarom moet de transactie die het saldo van deze rekening in het derde blok verlaagt, ook worden geannuleerd, en een correctieblok moet bovenop het blok zelf worden vastgelegd.
Opgemerkt moet worden dat, hoewel de corrigerende blokken worden weergegeven als “boven” de originele blokken, ze in feite zullen worden toegevoegd aan het einde van de overeenkomstige blockchain (waar ze chronologisch zouden moeten zijn). De tweedimensionale locatie laat alleen zien aan welk punt in de blockchain ze zullen worden “gekoppeld” (via de hash van het originele blok dat zich daarin bevindt).
Je kunt afzonderlijk filosoferen over hoe goed de beslissing is om ‘het verleden te veranderen’. Het lijkt erop dat als we de mogelijkheid erkennen dat er een onjuist blok in de shardchain verschijnt, we de mogelijkheid dat er een foutief correctieblok verschijnt, niet kunnen vermijden. Hier, voor zover ik weet, zit het verschil in het aantal knooppunten dat consensus moet bereiken over nieuwe blokken – er zal een relatief klein aantal mensen aan elke shardchain werken.”werkgroep» knooppunten (waarvan de samenstelling vrij vaak verandert), en de introductie van corrigerende blokken vereist de toestemming van iedereen validator knooppunten. In het volgende artikel zal ik meer vertellen over validators, werkgroepen en andere knooppuntrollen.
Eén blockchain om ze allemaal te regeren
Er staat hierboven veel informatie over de verschillende soorten blockchains, die zelf ook ergens opgeslagen moeten worden. We hebben het in het bijzonder over de volgende informatie:
- over het aantal en de configuraties van werkketens;
- over het aantal shardchains en hun voorvoegsels;
- over welke knooppunten momenteel verantwoordelijk zijn voor welke shardchains;
- hashes van de laatste blokken die aan alle shardchains zijn toegevoegd.
Zoals je misschien al geraden had, worden al deze dingen vastgelegd in een andere blockchain-opslag - hoofdketen (hoofdketen, meester blockchain). Door de aanwezigheid van hashes uit de blokken van alle shardchains in de blokken, wordt het systeem sterk verbonden. Dit betekent onder andere dat het genereren van een nieuw blok in de masterchain onmiddellijk zal plaatsvinden na het genereren van blokken in shardchains - de verwachting is dat blokken in shardchains ongeveer elke 5 seconden vrijwel gelijktijdig zullen verschijnen, en het volgende blok in de masterchain - een seconde daarna.
Maar wie zal verantwoordelijk zijn voor de implementatie van al dit gigantische werk – voor het verzenden van berichten, het uitvoeren van slimme contracten, het vormen van blokken in shardchains en de masterchain, en zelfs het controleren van blokken op fouten? Zal dit allemaal in het geheim worden gedaan door de telefoons van miljoenen gebruikers waarop de Telegram-client is geïnstalleerd? Of misschien zal het Durov-team de ideeën van decentralisatie laten varen en zullen hun servers het op de ouderwetse manier doen?
In feite is noch het ene noch het andere antwoord juist. Maar de marges van dit artikel raken snel op, dus we zullen het in het volgende deel hebben over de verschillende rollen van knooppunten (je hebt misschien al enkele vermeldingen opgemerkt), evenals de werking van hun werk.
Bron: www.habr.com