{"id":34631,"date":"2019-10-31T21:59:31","date_gmt":"2019-10-31T18:59:31","guid":{"rendered":"https:\/\/prohoster.info\/blog\/ton-telegram-open-network-chast-2-blokchejny-shardirovanie\/"},"modified":"2019-10-31T21:59:31","modified_gmt":"2019-10-31T18:59:31","slug":"ton-telegram-open-network-chast-2-blokchejny-shardirovanie","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/ton-telegram-open-network-chast-2-blokchejny-shardirovanie","title":{"rendered":"TON: Telegram Open Network. Deel 2: Blockchains, sharding","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"TON: Telegram Open Network. Deel 2: Blockchains, sharding\" src=\"\/wp-content\/uploads\/2019\/05\/e2a24aa1dda6a435e60da257af662853.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>Deze tekst is een vervolg op een serie artikelen waarin ik de structuur van het (vermoedelijk) komende Telegram Open Network (TON) bespreek. <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/post\/354366\/\">vorig deel<\/a><\/noindex> Ik heb het over het meest basale niveau - de manier waarop knooppunten met elkaar interageren.<\/p>\n<p><\/p>\n<p>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 - <noindex><a rel=\"nofollow\" href=\"https:\/\/denull.ru\/telegram\/ton-tech.pdf\">Inkomstenstructuur van een PhD-student en Post-Doc aan de EPFL<\/a><\/noindex> (er is ook een bijbehorende <noindex><a rel=\"nofollow\" href=\"https:\/\/denull.ru\/telegram\/ton.pdf\">brochure<\/a><\/noindex>, 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\u00eble bevestigingen voor zijn.<\/p>\n<p><\/p>\n<p>Vandaag kijken we naar de belangrijkste component van TON - de blockchain.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3 id=\"bazovye-ponyatiya\">Basisconcepten<\/h3>\n<p><\/p>\n<p><strong>Account<\/strong> (<em>account<\/em>). Een set gegevens, ge\u00efdentificeerd door een 256-bits nummer <em>account_id<\/em> (meestal is dit de openbare sleutel van de account eigenaar). In het basis geval (zie hieronder <em>nul blockchain<\/em>), verwijzen deze gegevens naar het saldo van de gebruiker. Iedereen kan een specifiek <em>account_id<\/em> leningen<\/p>\n<p><\/p>\n<p><strong>Slim contract<\/strong> (<em>smart-contract<\/em>). 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).<\/p>\n<p><\/p>\n<p><strong>De staat van de blockchain<\/strong> (<em>state of blockchain<\/em>). 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).<\/p>\n<p><\/p>\n<p><strong>Bericht<\/strong> (<em>bericht<\/em>). Boven heb ik de uitdrukking 'geld bijschrijven en afschrijven' gebruikt - dit is een specifiek voorbeeld van een bericht ('over te dragen <em>N gram<\/em> van account <em>account_1<\/em> naar account <em>account_2<\/em>'). Het lijkt evident dat alleen een knooppunt dat de priv\u00e9sleutel van het account bezit, zo'n bericht kan verzenden <em>account_1<\/em> 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).<\/p>\n<p><\/p>\n<p><strong>De transactie<\/strong> (<em>transactie<\/em>). 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 \u2014 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.<\/p>\n<p><\/p>\n<h3 id=\"blokcheyn-v-ton-chto-eto-i-zachem\">Blockchain in TON: wat is het en waarvoor dient het?<\/h3>\n<p><\/p>\n<p>Zoals vermeld in het vorige artikel, <em>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<\/em>. In de opmerkingen werd de vraag gesteld: waarom hebben we eigenlijk zo'n datastructuur nodig, als we al een DHT hebben \u2014 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 \u2014 voornamelijk vanwege het ontbreken van controles op <em>integriteit<\/em>. De complexiteit van de blockchain-structuur komt in feite voort uit het voorkomen van inmenging in de daarin opgeslagen gegevens.<\/p>\n<p><\/p>\n<p>Echter, de blockchain in TON lijkt nog ingewikkelder dan in de meeste andere gedistribueerde systemen \u2014 en daarvoor zijn er twee redenen. De eerste is de wens om de behoefte aan <em>forks<\/em>. 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 (<em>sharding<\/em>, <em>) 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 \u2014 met name omdat het moeilijk is om sharding toe te voegen aan een systeem waar het aanvankelijk niet voor was gepland.<\/em>Hoe van plan is TON beide bovengenoemde problemen op te lossen?<\/p>\n<p><\/p>\n<p>Hoe is TON van plan beide hierboven beschreven problemen op te lossen?<\/p>\n<p><\/p>\n<h3 id=\"soderzhimoe-blokcheyna-vorkcheyny\">Inhoud van de blockchain. Workchains.<\/h3>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"TON: Telegram Open Network. Deel 2: Blockchains, sharding\" src=\"\/wp-content\/uploads\/2019\/05\/c4f0f6e6702322ad4312cb262b3a0fab.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>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 \u2014 de sleutelwaarden zullen de identificatoren zijn <strong>account_id<\/strong>, en de waarden zullen datastructuren zijn die zaken bevatten zoals:<\/p>\n<p><\/p>\n<ul>\n<li>saldo;<\/li>\n<li>code van het smart contract (alleen voor smart contracts);<\/li>\n<li>gegevensopslag van het smart contract (alleen voor smart contracts);<\/li>\n<li>statistieken;<\/li>\n<li>(<em>optioneel<\/em>) openbare sleutel voor overboekingen vanaf het account, standaard is account_id;<\/li>\n<li>wachtrij van uitgaande berichten (hier worden ze toegevoegd voor verzending naar de ontvanger);<\/li>\n<li>lijst van de laatst afgeleverde berichten aan dit account.<\/li>\n<\/ul>\n<p><\/p>\n<p>Zoals hierboven vermeld, bestaan de blokken uit transacties \u2014 berichten die geleverd zijn aan verschillende accounts account_id. Maar behalve account_id bevatten de berichten ook een 32-bits veld <em>workchain_id<\/em> \u2014 de identificator van de zogenaamde <strong>workchain<\/strong> (<em>workchain<\/em>, <em>werkende blockchain<\/em>). Dit maakt het mogelijk om verschillende onafhankelijke blockchains te hebben met verschillende configuraties. Hierbij wordt workchain_id = 0 beschouwd als een bijzondere casus, <strong>nul workchain<\/strong> \u2014 de saldi die daarin zijn, zullen overeenkomen met de cryptocurrency TON (Grams). Waarschijnlijk zullen in het begin er helemaal geen andere workchains bestaan.<\/p>\n<p><\/p>\n<h3 id=\"shardcheyny-infinite-sharding-paradigm\">Shardchains. Infinite Sharding Paradigm.<\/h3>\n<p><\/p>\n<p>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 \u2014 daarin liggen alle binnenkomende berichten \u2014 en de staten van al deze blockchains worden op aparte knooppunten opgeslagen.<\/p>\n<p><\/p>\n<p>Natuurlijk is dit behoorlijk verspilling: hoogstwaarschijnlijk zullen transacties in elk van deze <strong>shardchains<\/strong> (<em>shardchain<\/em>, <em>shard blockchain<\/em>) zeer zelden binnenkomen, en er zijn veel krachtige knooppunten nodig (enkele details vooruitlopend, het gaat niet alleen om klanten op mobiele telefoons \u2014 maar om serieuze servers).<\/p>\n<p><\/p>\n<p>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 <em>shard_prefix<\/em> kan een lengte hebben van 0 tot 60 bits \u2014 en het belangrijkste is dat hij dynamisch kan veranderen.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"TON: Telegram Open Network. Deel 2: Blockchains, sharding\" src=\"\/wp-content\/uploads\/2019\/05\/568aec7ad3d8cc3e268f0e60d453b502.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>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 \u00e9\u00e9n bit langer zijn (waarvan voor de een dit bit 0 is en voor de ander 1). Bijvoorbeeld, <em>shard_prefix<\/em> = <u>0110<\/u>b splitst in <u>0110<\/u>0b en <u>0110<\/u>1b. Als twee 'buren' shardchains zich een tijdje genoeg bevrijd voelen, zullen ze weer samensmelten.<\/p>\n<p><\/p>\n<p>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 <strong>Infinite Sharding Paradigm<\/strong> (<em>de paradigma van oneindige sharding<\/em>).<\/p>\n<p><\/p>\n<p>Daarnaast wil ik benadrukken dat workchains alleen virtueel bestaan - in werkelijkheid, <em>workchain_id<\/em> maakt het deel uit van de identificator van een specifieke shardchain. Formeel gesproken, elke shardchain wordt gedefinieerd door een paar getallen (<em>workchain_id<\/em>, <em>shard_prefix<\/em>).<\/p>\n<p><\/p>\n<h3 id=\"ispravlenie-oshibok-vertikalnye-blokcheyny\">Foutcorrectie. Verticale blockchain.<\/h3>\n<p><\/p>\n<p>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 <em>vangknoop<\/em>) 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 <em>tweidimensionale blockchains zijn<\/em>.<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"TON: Telegram Open Network. Deel 2: Blockchains, sharding\" src=\"\/wp-content\/uploads\/2019\/05\/eda526705f5febd37995901b5542264c.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p>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 \u2013 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.<\/p>\n<p><\/p>\n<p>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).<\/p>\n<p><\/p>\n<p>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 \u2013 op elke shardchain zal een relatief kleine \"<em>werkgroep<\/em>\" knooppunten werkzaam zijn (waarvan de samenstelling vrij vaak verandert), en het inbrengen van correctieblokken vereist de goedkeuring van alle <em>validator knooppunten<\/em>. Meer over validators, werkgroepen en andere rollen van knooppunten zal ik in het volgende artikel vertellen.<\/p>\n<p><\/p>\n<h3 id=\"odin-blokcheyn-chtob-pravit-vsemi\">\u00c9\u00e9n blockchain om ze allemaal te beheersen<\/h3>\n<p><\/p>\n<p>Er is veel informatie opgesomd over verschillende soorten blockchains, die ook ergens opgeslagen moet worden. In het bijzonder betreft het de volgende gegevens:<\/p>\n<p><\/p>\n<ul>\n<li>over het aantal en de configuraties van werkchains;<\/li>\n<li>over het aantal shardchains en hun prefixen;<\/li>\n<li>over welke knooppunten momenteel verantwoordelijk zijn voor welke shardchains;<\/li>\n<li>de hashes van de recent toegevoegde blokken in alle shardchains.<\/li>\n<\/ul>\n<p><\/p>\n<p>Zoals je wellicht al hebt geraden, worden al deze dingen opgenomen in nog een opslag-blockchain \u2013 <strong>masterchain<\/strong> (<em>masterchain<\/em>, <em>master blockchain<\/em>). 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 \u2014 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.<\/p>\n<p><\/p>\n<p>Maar wie is er verantwoordelijk voor de uitvoering van al dit titaneske werk \u2014 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\u00efnstalleerd? Of misschien zal het team van Durov de idee\u00ebn van decentralisatie laten vallen en zullen hun servers het ouderwets doen?<\/p>\n<p><\/p>\n<p>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.<\/p>\n<p>Bron: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/354568\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0414\u0430\u043d\u043d\u044b\u0439 \u0442\u0435\u043a\u0441\u0442 \u2014 \u043f\u0440\u043e\u0434\u043e\u043b\u0436\u0435\u043d\u0438\u0435 \u0441\u0435\u0440\u0438\u0438 \u0441\u0442\u0430\u0442\u0435\u0439, \u0432 \u043a\u043e\u0442\u043e\u0440\u044b\u0445 \u044f \u0440\u0430\u0441\u0441\u043c\u0430\u0442\u0440\u0438\u0432\u0430\u044e \u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0443 (\u043f\u0440\u0435\u0434\u043f\u043e\u043b\u043e\u0436\u0438\u0442\u0435\u043b\u044c\u043d\u043e) \u0433\u043e\u0442\u043e\u0432\u044f\u0449\u0435\u0439\u0441\u044f \u043a \u0432\u044b\u0445\u043e\u0434\u0443 \u0432 \u044d\u0442\u043e\u043c \u0433\u043e\u0434\u0443 \u0440\u0430\u0441\u043f\u0440\u0435\u0434\u0435\u043b\u0435\u043d\u043d\u043e\u0439 \u0441\u0435\u0442\u0438 Telegram Open Network (TON). \u0412 \u043f\u0440\u0435\u0434\u044b\u0434\u0443\u0449\u0435\u0439 \u0447\u0430\u0441\u0442\u0438 \u044f \u043e\u043f\u0438\u0441\u0430\u043b \u0435\u0451 \u0441\u0430\u043c\u044b\u0439 \u0431\u0430\u0437\u043e\u0432\u044b\u0439 \u0443\u0440\u043e\u0432\u0435\u043d\u044c \u2014 \u0441\u043f\u043e\u0441\u043e\u0431 \u0432\u0437\u0430\u0438\u043c\u043e\u0434\u0435\u0439\u0441\u0442\u0432\u0438\u044f \u0443\u0437\u043b\u043e\u0432 \u043c\u0435\u0436\u0434\u0443 \u0441\u043e\u0431\u043e\u0439. \u041d\u0430 \u0432\u0441\u044f\u043a\u0438\u0439 \u0441\u043b\u0443\u0447\u0430\u0439 \u043d\u0430\u043f\u043e\u043c\u043d\u044e, \u0447\u0442\u043e \u043a \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0435 \u044d\u0442\u043e\u0439 \u0441\u0435\u0442\u0438 \u044f \u043e\u0442\u043d\u043e\u0448\u0435\u043d\u0438\u044f \u043d\u0435 \u0438\u043c\u0435\u044e \u0438 \u0432\u0435\u0441\u044c \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":26098,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-34631","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.3 - aioseo.com -->\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/ton-telegram-open-network-chast-2-blokchejny-shardirovanie\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"nl_NL\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47TON: Telegram Open Network. \u0427\u0430\u0441\u0442\u044c 2: \u0411\u043b\u043e\u043a\u0447\u0435\u0439\u043d\u044b, \u0448\u0430\u0440\u0434\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 | ProHoster\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/ton-telegram-open-network-chast-2-blokchejny-shardirovanie\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T18:59:31+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T18:59:31+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47TON: Telegram Open Network. Deel 2: Blockchains, Sharding | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/ton-telegram-open-network-chast-2-blokchejny-shardirovanie","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nl_NL","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47TON: Telegram Open Network. \u0427\u0430\u0441\u0442\u044c 2: \u0411\u043b\u043e\u043a\u0447\u0435\u0439\u043d\u044b, \u0448\u0430\u0440\u0434\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 | ProHoster","og:url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/ton-telegram-open-network-chast-2-blokchejny-shardirovanie","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:59:31+00:00","article:modified_time":"2019-10-31T18:59:31+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"34631","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-21 20:00:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:17:24","updated":"2026-01-21 20:00:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/34631","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/comments?post=34631"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/34631\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media\/26098"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media?parent=34631"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/categories?post=34631"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/tags?post=34631"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}