Denna text är en fortsättning på en serie artiklar där jag undersöker strukturen för det (förmodligen) distribuerade nätverket Telegram Open Network (TON), som förbereds för release i år. I Jag beskrev dess mest grundläggande nivå - hur noder interagerar med varandra.
För säkerhets skull, låt mig påminna dig om att jag inte har något att göra med utvecklingen av detta nätverk och allt material hämtades från en öppen (om än overifierad) källa - (det finns också en medföljande , som kort beskriver huvudpunkterna), som publicerades i slutet av förra året. Mängden information i detta dokument, enligt min mening, indikerar dess äkthet, även om det inte finns någon officiell bekräftelse på detta.
Idag kommer vi att titta på huvudkomponenten i TON - blockkedjan.
Grundläggande begrepp
Account (konto). En uppsättning data som identifieras av ett 256-bitars nummer konto-id (oftast är detta kontoägarens publika nyckel). I basfallet (se nedan noll arbetskedja), hänvisar dessa data till användarens saldo. "Occupy" specifikt konto-id vem som helst kan, men dess värde kan bara ändras enligt vissa regler.
Smart kontrakt (smart kontrakt). I huvudsak är det ett specialfall av ett konto, kompletterat med smart kontraktskod och lagring av dess variabler. Om du i fallet med en "plånbok" kan sätta in och ta ut pengar från den enligt relativt enkla och förutbestämda regler, då i fallet med ett smart kontrakt skrivs dessa regler i form av dess kod (i en viss Turing-komplett programmeringsspråk).
Blockchain State (blockkedjans tillstånd). Uppsättningen av tillstånd för alla konton/smarta kontrakt (i abstrakt bemärkelse, en hashtabell, där nycklarna är kontoidentifierare och värdena är data som lagras i kontona).
meddelande (meddelande). Ovan använde jag uttrycket "kreditera och debitera pengar" - det här är ett speciellt exempel på ett meddelande ("överföring N gram från konto konto_1 till konto konto_2"). Uppenbarligen kan bara den nod som äger kontots privata nyckel skicka ett sådant meddelande konto_1 - och kunna bekräfta detta med en signatur. Resultatet av att leverera sådana meddelanden till ett vanligt konto är en ökning av dess saldo, och resultatet av det smarta kontraktet är exekveringen av dess kod (som kommer att behandla mottagandet av meddelandet). Naturligtvis är andra meddelanden också möjliga (överföring av inte monetära belopp, utan godtyckliga data mellan smarta kontrakt).
Transaktion (transaktion). Det faktum att ett meddelande levereras kallas en transaktion. Transaktioner förändrar blockkedjans tillstånd. Det är transaktioner (poster för meddelandeleverans) som utgör blocken i blockkedjan. I detta avseende kan du tänka på blockkedjans tillstånd som en inkrementell databas - alla block är "diffar" som måste appliceras sekventiellt för att få databasens nuvarande tillstånd. Detaljerna för att förpacka dessa "diffar" (och återställa det fullständiga tillståndet från dem) kommer att diskuteras i nästa artikel.
Blockchain i TON: vad är det och varför?
Som nämndes i föregående artikel, blockchain är en datastruktur, vars element (block) är ordnade i en "kedja", och varje efterföljande block i kedjan innehåller en hash av det föregående. Kommentarerna ställde frågan: varför behöver vi en sådan datastruktur överhuvudtaget när vi redan har en DHT - en distribuerad hashtabell? Uppenbarligen kan vissa data lagras i DHT, men detta är endast lämpligt för inte alltför "känslig" information. Saldon i kryptovaluta kan inte lagras i DHT – främst på grund av bristen på kontroller på integritet. Egentligen växer hela komplexiteten i blockkedjestrukturen för att förhindra störningar av data som lagras i den.
Blockkedjan i TON ser dock ännu mer komplex ut än i de flesta andra distribuerade system – och av två anledningar. Den första är önskan att minimera behovet av gafflar. I traditionella kryptovalutor ställs alla parametrar in i det inledande skedet och varje försök att ändra dem leder faktiskt till uppkomsten av ett "alternativt kryptovalutauniversum." Det andra skälet är stöd för krossning (skärning, skärning) blockchain. Blockchain är en struktur som inte kan bli mindre med tiden; och vanligtvis tvingas varje nod som ansvarar för driften av nätverket att lagra den helt. I traditionella (centraliserade) system används sharding för att lösa sådana problem: några av posterna i databasen finns på en server, några på en annan, etc. När det gäller kryptovalutor är sådan funktionalitet fortfarande ganska sällsynt – i synnerhet på grund av att det är svårt att lägga till sharding i ett system där det inte var planerat från början.
Hur planerar TON att lösa båda ovanstående problem?
Blockchain-innehåll. Arbetskedjor.
Först och främst, låt oss prata om vad som är planerat att lagras i blockkedjan. Kontotillståndet (”plånböcker” i basfallet) och smarta kontrakt kommer att lagras där (för enkelhetens skull kommer vi att anta att detta är detsamma som konton). I huvudsak kommer detta att vara en vanlig hashtabell - nycklarna i den kommer att vara identifierare konto-id, och värden är datastrukturer som innehåller sådant som:
- balans;
- smart kontraktskod (endast för smarta kontrakt);
- smart kontraktsdatalagring (endast för smarta kontrakt);
- statistik;
- (valfritt) offentlig nyckel för överföringar från kontot, som standard account_id;
- kö av utgående meddelanden (här läggs de in för vidarebefordran till mottagaren);
- en lista över de senaste meddelandena som levererats till det här kontot.
Som nämnts ovan består själva blocken av transaktioner - meddelanden som levereras till olika account_id-konton. Men förutom account_id innehåller meddelanden även ett 32-bitarsfält workchain_id — så kallad identifierare arbetskedja (arbetskedja, fungerande blockchain). Detta gör att du kan ha flera blockkedjor oberoende av varandra med olika konfigurationer. I det här fallet anses workchain_id = 0 som ett specialfall, noll arbetskedja — det är saldot i den som kommer att motsvara TON (Grams) kryptovaluta. Troligtvis kommer andra arbetskedjor till en början inte att existera alls.
Shardchains. Infinite Sharding Paradigm.
Men ökningen av antalet blockkedjor stannar inte där. Låt oss ta itu med skärning. Låt oss föreställa oss att varje konto (account_id) tilldelas sin egen blockchain - den innehåller alla meddelanden som kommer till den - och tillstånden för alla sådana blockchains lagras på separata noder.
Naturligtvis är detta väldigt slösaktigt: troligen i var och en av dessa skärvkedjor (skärvkedja, skärva blockchain) transaktioner kommer mycket sällan fram, och det kommer att behövas många kraftfulla noder (när man ser framåt noterar jag att vi inte bara pratar om klienter på mobiltelefoner – utan om seriösa servrar).
Därför kombinerar shardchains konton med de binära prefixen för deras identifierare: om en shardchain har prefixet 0110, kommer den att inkludera transaktioner för alla account_id som börjar med dessa siffror. Detta shard_prefix kan ha en längd från 0 till 60 bitar - och huvudsaken är att den kan ändras dynamiskt.
Så snart en av skärvkedjorna börjar ta emot för många transaktioner "delar" noderna som arbetar på den, enligt förutbestämda regler, den i två barn - deras prefix kommer att vara en bit längre (och för en av dem kommer denna bit att vara lika med 0, och för den andra - 1). Till exempel, shard_prefix = 0110b kommer att delas upp i 01100b och 0110Ib. I sin tur, om två "intilliggande" skärvkedjor börjar känna sig tillräckligt bekväma (under en tid), kommer de att smälta samman igen.
Sålunda sker skärning "nedifrån och upp" - vi antar att varje konto har sin egen skärva, men för tillfället är de "limmade ihop" av prefix. Detta är vad det betyder Infinite Sharding Paradigm (oändligt skärningsparadigm).
Separat vill jag betona att arbetskedjor endast existerar praktiskt taget - faktiskt, workchain_id det är en del av identifieraren för en specifik skärvkedja. I formella termer definieras varje shardchain av ett par siffror (workchain_id, shard_prefix).
Felkorrigering. Vertikala blockkedjor.
Traditionellt anses alla transaktioner på en blockchain vara "huggna i sten". Men i fallet med TON är det möjligt att "skriva om historien" - om någon (den så kallade. fiskare knut) kommer att bevisa att ett av blocken signerades felaktigt. I det här fallet läggs ett speciellt korrigeringsblock till motsvarande shardchain, som innehåller hashen för själva blocket som korrigeras (och inte det sista blocket i shardchain). Om vi tänker på skärvkedjan som en kedja av block som är utlagd horisontellt kan vi säga att det korrigerande blocket är fäst vid det felaktiga blocket inte till höger utan ovanifrån - så det anses att det blir en del av en liten "vertikal blockchain" . Således kan vi säga att shardchains är tvådimensionella blockkedjor.
Om, efter ett felaktigt block, de ändringar som gjorts av den refererades till av efterföljande block (dvs nya transaktioner gjordes baserat på ogiltiga), läggs även korrigerande till dessa block "överst". Om blocken inte påverkade den "berörda" informationen, gäller inte dessa "korrigerande vågor" för dem. Till exempel, i illustrationen ovan, erkändes transaktionen för det första blocket, som ökar saldot på konto C, som felaktig - därför bör transaktionen som minskar saldot på detta konto i det tredje blocket också annulleras, och ett korrigerande block bör begås ovanpå själva blocket.
Det bör noteras att även om de korrigerande blocken är avbildade som placerade "ovanför" de ursprungliga, kommer de faktiskt att läggas till i slutet av motsvarande blockkedja (där de borde vara kronologiskt). Den tvådimensionella platsen visar bara till vilken punkt i blockkedjan de kommer att "länkas" (via hashen för det ursprungliga blocket som finns i dem).
Du kan separat filosofera över hur bra beslutet att "förändra det förflutna" är. Det verkar som om vi erkänner möjligheten att ett felaktigt block dyker upp i shardchain, så kan vi inte undvika möjligheten att ett felaktigt korrigerande block dyker upp. Här, så vitt jag kan säga, är skillnaden i antalet noder som måste nå konsensus om nya block - det kommer att finnas ett relativt litet antal personer som arbetar på varje shardchain."arbetsgrupp» noder (som ändrar sin sammansättning ganska ofta) och införandet av korrigerande block kräver samtycke från alla validatornoder. Jag kommer att prata mer om validerare, arbetsgrupper och andra nodroller i nästa artikel.
En blockchain för att styra dem alla
Det finns mycket information listad ovan om de olika typerna av blockkedjor, som i sig också bör lagras någonstans. I synnerhet talar vi om följande information:
- om antalet och konfigurationerna av arbetskedjor;
- om antalet skärvkedjor och deras prefix;
- om vilka noder som för närvarande är ansvariga för vilka shardchains;
- hash för de sista blocken som lagts till i alla skärvkedjor.
Som du kanske har gissat är alla dessa saker inspelade i en annan blockchain-lagring - mästerkedja (mästerkedja, mästare blockchain). På grund av närvaron av hash från blocken av alla shardchains i dess block, gör det systemet mycket uppkopplat. Detta innebär bland annat att genereringen av ett nytt block i masterkedjan kommer att ske omedelbart efter genereringen av block i shardchains - det förväntas att block i shardchains kommer att dyka upp nästan samtidigt ungefär var 5:e sekund, och nästa block i shardchains. masterchain - en sekund efter det.
Men vem kommer att ansvara för implementeringen av allt detta enorma arbete - för att skicka meddelanden, utföra smarta kontrakt, bilda block i shardchains och masterchain, och till och med kontrollera block för fel? Kommer allt detta att göras i hemlighet av miljontals användares telefoner med Telegram-klienten installerad på dem? Eller kanske Durov-teamet kommer att överge idéerna om decentralisering och deras servrar kommer att göra det på gammaldags sätt?
Faktum är att varken det ena eller det andra svaret är korrekt. Men marginalerna för den här artikeln håller snabbt på att ta slut, så vi kommer att prata om nodernas olika roller (du kanske redan har märkt omnämnanden av några av dem), såväl som mekaniken i deras arbete, i nästa del.
Källa: will.com