Deze tekst is een vervolg op een serie artikelen waarin ik de structuur van het (vermoedelijk) komende Telegram Open Network (TON) bespreek. Ik heb het over het meest basale niveau - de manier waarop knooppunten met elkaar interageren.
Voor de duidelijkheid, ik heb niets met de ontwikkeling van dit netwerk te maken en al het materiaal is afkomstig uit een openbare (alhoewel onbevestigde) bron - (er is ook een bijbehorende , die in het kort de belangrijkste punten samenvat), verschenen aan het einde van afgelopen jaar. De hoeveelheid informatie in dit document duidt, naar mijn mening, op de authenticiteit ervan, hoewel er geen officiële bevestigingen voor zijn.
Vandaag kijken we naar de belangrijkste component van TON - de blockchain.
Basisconcepten
Account (account). Een set gegevens, geïdentificeerd door een 256-bits nummer account_id (meestal is dit de openbare sleutel van de account eigenaar). In het basis geval (zie hieronder nul blockchain), verwijzen deze gegevens naar het saldo van de gebruiker. Iedereen kan een specifiek account_id leningen
Slim contract (smart-contract). In wezen is dit een speciale variant van een account, aangevuld met de code van het smart contract en het opslagmedium voor zijn variabelen. Terwijl er in het geval van een 'portemonnee' relatief eenvoudige en vooraf gedefinieerde regels zijn voor het bijschrijven en afschrijven van geld, zijn die regels in het geval van een smart contract vastgelegd in de vorm van zijn code (in een bepaalde Turing-complete programmeertaal).
De staat van de blockchain (state of blockchain). De verzameling van de staten van alle accounts/smart contracts (in abstracte zin - een hash-tabel, waarbij de identificatoren van de accounts de sleutels zijn en de opgeslagen gegevens in de accounts de waarden).
Bericht (bericht). Boven heb ik de uitdrukking 'geld bijschrijven en afschrijven' gebruikt - dit is een specifiek voorbeeld van een bericht ('over te dragen N gram van account account_1 naar account account_2'). Het lijkt evident dat alleen een knooppunt dat de privésleutel van het account bezit, zo'n bericht kan verzenden account_1 en dit kan bevestigen met een handtekening. Het resultaat van het afleveren van dergelijke berichten aan een reguliere account is een toename van het saldo, en voor het smart contract is het de uitvoering van zijn code (die de ontvangst van het bericht verwerkt). Uiteraard zijn er ook andere berichten mogelijk (die niet geldbedragen, maar willekeurige gegevens tussen smart contracts overdragen).
De transactie (transactie). De feitelijke levering van het bericht wordt een transactie genoemd. Transacties veranderen de staat van de blockchain. Blokken in de blockchain bestaan uit transacties (leveringsrecords van berichten). In dit opzicht kan de staat van de blockchain worden gezien als een incrementele database — alle blokken zijn 'diffs' die achtereenvolgens moeten worden toegepast om de huidige staat van de database te verkrijgen. De specificiteit van het verpakken van deze 'diffs' (en het herstellen van de volledige staat daarop) wordt in het volgende artikel besproken.
Blockchain in TON: wat is het en waarvoor dient het?
Zoals vermeld in het vorige artikel, is blockchain een datastructuur waarvan de elementen (blokken) in een 'keten' zijn geordend, en elk volgend blok in de keten bevat de hash van het vorige. In de opmerkingen werd de vraag gesteld: waarom hebben we eigenlijk zo'n datastructuur nodig, als we al een DHT hebben — een gedistribueerde hash-tabel? Het is duidelijk dat sommige gegevens ook in DHT kunnen worden opgeslagen, maar dit is alleen geschikt voor niet al te 'gevoelige' informatie. Balansen van cryptocurrency kunnen niet in DHT worden opgeslagen — voornamelijk vanwege het ontbreken van controles op integriteit. De complexiteit van de blockchain-structuur komt in feite voort uit het voorkomen van inmenging in de daarin opgeslagen gegevens.
Echter, de blockchain in TON lijkt nog ingewikkelder dan in de meeste andere gedistribueerde systemen — en daarvoor zijn er twee redenen. De eerste is de wens om de behoefte aan forks. In traditionele cryptocurrency zijn alle parameters in het begin vastgesteld en elke poging om deze te wijzigen leidt feitelijk tot de creatie van een 'alternatieve cryptocurrency-universum'. De tweede reden is de ondersteuning van sharding (sharding, ) van de blockchain. Blockchain is een structuur die niet kleiner kan worden in de loop van de tijd; en meestal is elke node die verantwoordelijk is voor de werking van het netwerk verplicht om deze volledig op te slaan. In traditionele (gecentraliseerde) systemen wordt sharding toegepast om dergelijke problemen op te lossen: een deel van de records in de database bevindt zich op de ene server, een deel op een andere, enzovoort. In het geval van cryptocurrencies is deze functionaliteit tot nu toe vrij zeldzaam — met name omdat het moeilijk is om sharding toe te voegen aan een systeem waar het aanvankelijk niet voor was gepland.Hoe van plan is TON beide bovengenoemde problemen op te lossen?
Hoe is TON van plan beide hierboven beschreven problemen op te lossen?
Inhoud van de blockchain. Workchains.
Laten we eerst bespreken wat er in de blockchain zal worden opgeslagen. Daar zullen de staten van accounts (ook wel 'wallets' in de basisversie genoemd) en smart contracts worden bewaard (ter vereenvoudiging beschouwen we dit als hetzelfde als accounts). In wezen zal dit een gewone hash-tabel zijn — de sleutelwaarden zullen de identificatoren zijn account_id, en de waarden zullen datastructuren zijn die zaken bevatten zoals:
- saldo;
- code van het smart contract (alleen voor smart contracts);
- gegevensopslag van het smart contract (alleen voor smart contracts);
- statistieken;
- (optioneel) openbare sleutel voor overboekingen vanaf het account, standaard is account_id;
- wachtrij van uitgaande berichten (hier worden ze toegevoegd voor verzending naar de ontvanger);
- lijst van de laatst afgeleverde berichten aan dit account.
Zoals hierboven vermeld, bestaan de blokken uit transacties — berichten die geleverd zijn aan verschillende accounts account_id. Maar behalve account_id bevatten de berichten ook een 32-bits veld workchain_id — de identificator van de zogenaamde workchain (workchain, werkende blockchain). Dit maakt het mogelijk om verschillende onafhankelijke blockchains te hebben met verschillende configuraties. Hierbij wordt workchain_id = 0 beschouwd als een bijzondere casus, nul workchain — de saldi die daarin zijn, zullen overeenkomen met de cryptocurrency TON (Grams). Waarschijnlijk zullen in het begin er helemaal geen andere workchains bestaan.
Shardchains. Infinite Sharding Paradigm.
Maar de groei van het aantal blockchains stopt hier niet. Laten we het over sharding hebben. Stel je voor dat aan elk account (account_id) zijn eigen blockchain is toegewezen — daarin liggen alle binnenkomende berichten — en de staten van al deze blockchains worden op aparte knooppunten opgeslagen.
Natuurlijk is dit behoorlijk verspilling: hoogstwaarschijnlijk zullen transacties in elk van deze shardchains (shardchain, shard blockchain) zeer zelden binnenkomen, en er zijn veel krachtige knooppunten nodig (enkele details vooruitlopend, het gaat niet alleen om klanten op mobiele telefoons — maar om serieuze servers).
Daarom groeperen shardchains accounts op basis van de binaire prefixen van hun identificatoren: als een shardchain de prefix 0110 heeft, dan komen transacties van alle account_id's die met deze cijfers beginnen daarin terecht. Deze shard_prefix kan een lengte hebben van 0 tot 60 bits — en het belangrijkste is dat hij dynamisch kan veranderen.
Zodra er een overmatig aantal transacties binnenkomt op een van de shardchains, splitsen de werkende knooppunten het volgens vooraf bepaalde regels in twee dochtershardchains - hun prefixen zullen één bit langer zijn (waarvan voor de een dit bit 0 is en voor de ander 1). Bijvoorbeeld, shard_prefix = 0110b splitst in 01100b en 01101b. Als twee 'buren' shardchains zich een tijdje genoeg bevrijd voelen, zullen ze weer samensmelten.
Op deze manier wordt sharding 'van onderaf' gedaan - we nemen aan dat elk account zijn eigen shard heeft, maar deze zijn tijdelijk 'gelijmd' op basis van prefixen. Dit houdt in Infinite Sharding Paradigm (de paradigma van oneindige sharding).
Daarnaast wil ik benadrukken dat workchains alleen virtueel bestaan - in werkelijkheid, workchain_id maakt het deel uit van de identificator van een specifieke shardchain. Formeel gesproken, elke shardchain wordt gedefinieerd door een paar getallen (workchain_id, shard_prefix).
Foutcorrectie. Verticale blockchain.
Er wordt traditioneel aangenomen dat elke transactie in een blockchain 'in steen gebeiteld' is. Echter, bij TON is er een mogelijkheid om 'de geschiedenis te herschrijven' - als iemand (de zogenaamde vangknoop) kan aantonen dat een van de blokken onjuist is ondertekend. In dat geval wordt er een speciale correctieblock aan de betreffende shardchain toegevoegd, die de hash van het te corrigeren blok bevat (en niet van het laatste blok in de shardchain). Als we de shardchain beschouwen als een horizontaal gelegde keten van blokken, kan worden gezegd dat de correctieblock niet rechtsonder, maar erboven aan het foutieve blok wordt gekoppeld - daarom wordt aangenomen dat dit een deel wordt van een kleine 'verticale blockchain'. Op deze manier kan worden gezegd dat shardchains tweidimensionale blockchains zijn.
Als na een foutieve blok op de aangebrachte wijzigingen verwijzingen waren naar volgende blokken (d.w.z. als er nieuwe transacties werden uitgevoerd op basis van ongeldig), worden ook daarbovenop correcties toegevoegd. Als de blokken de "aangetaste" informatie niet betroffen, zijn deze "correctiegolven" niet van toepassing op hen. Bijvoorbeeld, in de bovenstaande illustratie werd de transactie van de eerste blok als ongeldig beschouwd, wat het saldo van account C verhoogde – daarom moet de transactie die dit saldo in de derde blok verlaagt, ook worden geannuleerd, en moet er bovenop deze blok een corrigerend blok worden gecommit.
Het is belangrijk op te merken dat, hoewel correctieblokken worden weergegeven als 'boven' de originele, ze in werkelijkheid aan het einde van de overeenkomstige blockchain worden toegevoegd (waar ze chronologisch horen te staan). De tweedimensionale opstelling laat alleen zien aan welk punt in de blockchain ze zullen worden "aangekoppeld" (via de hash van het originele blok die daarin zit).
Men kan zich afzonderlijk afvragen hoe goed het idee is om "het verleden te veranderen". Het lijkt erop dat, als we de mogelijkheid van een ongeldig blok in de shardchain toestaan, we ook de mogelijkheid van een foutief correctieblok moeten toestaan. Hier is, voor zover ik kan oordelen, het verschil het aantal knooppunten dat consensus moet bereiken over de nieuwe blokken – op elke shardchain zal een relatief kleine "werkgroep" knooppunten werkzaam zijn (waarvan de samenstelling vrij vaak verandert), en het inbrengen van correctieblokken vereist de goedkeuring van alle validator knooppunten. Meer over validators, werkgroepen en andere rollen van knooppunten zal ik in het volgende artikel vertellen.
Één blockchain om ze allemaal te beheersen
Er is veel informatie opgesomd over verschillende soorten blockchains, die ook ergens opgeslagen moet worden. In het bijzonder betreft het de volgende gegevens:
- over het aantal en de configuraties van werkchains;
- over het aantal shardchains en hun prefixen;
- over welke knooppunten momenteel verantwoordelijk zijn voor welke shardchains;
- de hashes van de recent toegevoegde blokken in alle shardchains.
Zoals je wellicht al hebt geraden, worden al deze dingen opgenomen in nog een opslag-blockchain – masterchain (masterchain, master blockchain). Dankzij de aanwezigheid van hashes in zijn blokken van alle shardchains, maakt het systeem sterk verbonden. Dit betekent onder andere dat het genereren van een nieuw blok in de masterchain direct zal plaatsvinden na het genereren van blokken in de shardchains — het wordt verwacht dat blokken in de shardchains bijna gelijktijdig zullen verschijnen, om de 5 seconden, en het volgende blok in de masterchain zal een seconde later volgen.
Maar wie is er verantwoordelijk voor de uitvoering van al dit titaneske werk — het verzenden van berichten, het uitvoeren van slimme contracten, het vormgeven van blokken in shardchains en de masterchain, en ook het controleren van blokken op fouten? Zullen dit echt in stilte de telefoons van miljoenen gebruikers zijn met de Telegram-client erop geïnstalleerd? Of misschien zal het team van Durov de ideeën van decentralisatie laten vallen en zullen hun servers het ouderwets doen?
In werkelijkheid is geen van beide antwoorden correct. Maar de ruimte van dit artikel raakt snel op, dus de discussie over de verschillende rollen van knooppunten (je hebt misschien al enkele vermeldingen daarvan opgemerkt), evenals de mechanica van hun werking, zal in het volgende deel plaatsvinden.
Bron: habr.com
