Denna text Ă€r en fortsĂ€ttning pĂ„ en serie artiklar dĂ€r jag undersöker strukturen av det förmodligen förestĂ„ende distribuerade nĂ€tverket Telegram Open Network (TON) som planeras att lanseras i Ă„r. Jag har beskrivit dess mest grundlĂ€ggande nivĂ„ â sĂ€ttet som noder interagerar sinsemellan.
Jag vill pĂ„minna om att jag inte har nĂ„got att göra med utvecklingen av detta nĂ€tverk och allt material Ă€r hĂ€mtat frĂ„n en öppen (Ă€ven om den Ă€r ogranskad) kĂ€lla â (till vilken det Ă€ven finns bifogad , som sammanfattar huvudpunkterna), som dök upp i slutet av förra Ă„ret. MĂ€ngden information i detta dokument tyder, enligt min Ă„sikt, pĂ„ dess Ă€kthet, Ă€ven om det inte finns nĂ„gra officiella bekrĂ€ftelser pĂ„ det.
Idag ska vi titta pĂ„ huvudkomponenten i TON â blockchain.
GrundlÀggande begrepp
Konto (konto). En uppsÀttning data som identifieras med ett 256-bitars nummer account_id (oftast Àr detta den offentliga nyckeln för kontoinnehavaren). I det grundlÀggande fallet (se nedan noll blockchain), innebÀr dessa data anvÀndarens saldo. "LÄna" ett specifikt account_id kan vem som helst, men att Àndra dess vÀrde kan endast göras enligt bestÀmda regler.
Smart kontrakt (smart-contract). I grunden Àr det ett specialfall av ett konto, kompletterat med smart kontraktskod och lagring av dess variabler. I fallet med "plÄnboken" kan pengar sÀttas in och dras ut enligt relativt enkla och förutbestÀmda regler, medan i fallet med ett smart kontrakt skrivs dessa regler ner i form av dess kod (pÄ nÄgot Turing-fullstÀndigt programmeringssprÄk).
Blockchain tillstĂ„nd (state of blockchain). En uppsĂ€ttning tillstĂ„nd för alla konton/smart kontrakt (i abstrakt mening â en hash-tabell dĂ€r nycklarna Ă€r kontoidentifierare och vĂ€rdena Ă€r de data som lagras i kontona).
Meddelandet (meddelande). Jag anvĂ€nde tidigare uttrycket "sĂ€tta in och dra ut pengar" â detta Ă€r ett specifikt exempel pĂ„ ett meddelande ("överföra N gram frĂ„n kontot account_1 till kontot account_2"). Det Ă€r uppenbart att ett sĂ„dant meddelande endast kan skickas av en nod som Ă€ger den privata nyckeln till kontot account_1 â och kan bekrĂ€fta detta med en signatur. Resultatet av att leverera sĂ„dana meddelanden till ett vanligt konto Ă€r en ökning av dess saldo, medan ett smart kontrakt fĂ„r sin kod att utföras (som behandlar mottagandet av meddelandet). Naturligtvis Ă€r andra meddelanden möjliga (som överför icke-monetĂ€ra belopp eller godtyckliga data mellan smarta kontrakt).
Transaktion (transaction). Faktumet av att ett meddelande levereras kallas transaktion. Transaktioner förĂ€ndrar blockchainens tillstĂ„nd. Det Ă€r just av transaktioner (leveransposter) som block i blockkedjan bestĂ„r. I detta avseende kan man förestĂ€lla sig blockchainens tillstĂ„nd som en inkrementell databas â alla block Ă€r «diffar» som mĂ„ste tillĂ€mpas sekventiellt för att fĂ„ den aktuella databasen. Om detaljeringen av hur dessa «diffar» paketeras (och hur man Ă„terstĂ€ller det fullstĂ€ndiga tillstĂ„ndet frĂ„n dem) kommer att behandlas i nĂ€sta artikel.
Blockchain i TON: vad Àr det och varför?
Som nĂ€mndes i den föregĂ„ende artikeln, blockchain Ă€r en datastruktur dĂ€r elementen (blocken) Ă€r ordnade i en «kedja» och varje efterföljande block i kedjan innehĂ„ller en hash av den föregĂ„ende. I kommentarerna stĂ€lldes frĂ„gan: varför behövs överhuvudtaget en sĂ„dan datastruktur nĂ€r vi redan har DHT â en distribuerad hash-tabell? Det Ă€r uppenbart att vissa uppgifter kan lagras i DHT, men det passar endast för information som inte Ă€r alltför «kĂ€nslig». Man kan inte lagra kryptovaluta saldon i DHT â framför allt pĂ„ grund av bristen pĂ„ kontroller för integritet. Egentligen vĂ€xer hela komplexiteten i blockchain-strukturen för att förhindra att obehöriga gör intrĂ„ng i de uppgifter som lagras dĂ€r.
Men blockchain i TON ser Ă€nnu mer komplicerat ut Ă€n i de flesta andra distribuerade system â och det finns tvĂ„ anledningar till det. Den första Ă€r strĂ€van att minimera behovet av forkar. I traditionella kryptovalutor Ă€r alla parametrar angivna frĂ„n början och varje försök att Ă€ndra dem leder faktiskt till en «alternativ kryptovalutauniversum». Den andra anledningen Ă€r stödet för partitionering (sharding, sharding) i blockchainen. Blockchain Ă€r en struktur som inte kan bli mindre med tiden; och normalt mĂ„ste varje nod som ansvarar för nĂ€tverkets funktionalitet lagra det helt. I traditionella (centraliserade) system anvĂ€nds sharding för att lösa sĂ„dana problem: en del av posterna i databasen finns pĂ„ en server, en del â pĂ„ en annan, och sĂ„ vidare. NĂ€r det gĂ€ller kryptovalutor Ă€r denna funktionalitet fortfarande ganska sĂ€llsynt â sĂ€rskilt eftersom det Ă€r svĂ„rt att lĂ€gga till sharding i ett system dĂ€r det inte ursprungligen planerades.
Hur planerar dÄ TON att lösa de bÄda ovan beskrivna problemen?
InnehÄllet i blockkedjan. Vorkchains.
Först och frĂ€mst, lĂ„t oss prata om vad som planeras att lagras i blockkedjan. Det som kommer att lagras Ă€r tillstĂ„nd av konton ("plĂ„nböcker" i grundlĂ€ggande fall) och smarta kontrakt (för enkelhetens skull kommer vi att betrakta dem som samma sak som konton). I grund och botten kommer det att vara en vanlig hash-tabell â identifierare kommer att vara nycklar. account_id, och vĂ€rdena kommer att vara datatyper som innehĂ„ller sĂ„dana saker som:
- saldo;
- kod för det smarta kontraktet (endast för smarta kontrakt);
- databas för det smarta kontraktet (endast för smarta kontrakt);
- statistik;
- (valfritt) offentlig nyckel för överföringar frÄn kontot, som standard account_id;
- kön av utgÄende meddelanden (hÀr lagras de för vidarebefordran till mottagaren);
- lista över de senaste meddelandena som levererats till detta konto.
Som nĂ€mnts ovan bestĂ„r blocken direkt av transaktioner â meddelanden som levererats till olika konton account_id. Men förutom account_id innehĂ„ller meddelandena ocksĂ„ ett 32-bitars fĂ€lt workchain_id â identifierare för sĂ„ kallade vorkchains (workchain, working blockchain). Detta gör det möjligt att ha flera oberoende blockkedjor med olika konfigurationer. HĂ€r betrakta workchain_id = 0 som ett speciellt fall, noll vorkchain â det Ă€r saldon i denna som kommer att motsvara kryptovalutan TON (Grams). Troligtvis kommer det inte att finnas nĂ„gra andra vorkchains i början.
Shardchains. Infinite Sharding Paradigm.
Men tillvĂ€xten av antalet blockkedjor stannar inte hĂ€r. LĂ„t oss utforska sharding. TĂ€nk dig att varje konto (account_id) fĂ„r sin egen blockkedja â alla inkommande meddelanden ligger i den â och tillstĂ„ndet för alla sĂ„dana blockkedjor lagras pĂ„ separata noder.
SjĂ€lvklart Ă€r detta ganska slösaktigt: troligtvis kommer transaktioner i var och en av dessa shardchains (shardchain, shard blockchain) att mottas mycket sĂ€llan, och mĂ„nga kraftfulla noder behövs (för att vara tydlig, handlar det inte bara om klienter pĂ„ mobiltelefoner â utan om mycket kraftfulla servrar).
DĂ€rför grupperar shardchains konton efter de binĂ€ra prefixen av deras identifierare: om en shardchain har prefixet 0110, kommer transaktioner för alla account_id som börjar med dessa siffror att landa dĂ€r. Detta shard_prefix kan ha en lĂ€ngd frĂ„n 0 till 60 bitar â och huvudsaken Ă€r att det kan Ă€ndras dynamiskt.
NÀr en av shardkedjorna börjar ta emot ett överdrivet antal transaktioner, "delar" noderna som arbetar med den den i förvÀg definierade reglerna i tvÄ underliggande kedjor - deras prefix kommer att vara en bit lÀngre (och för en av dem kommer denna bit att vara 0, medan för den andra kommer den att vara 1). Till exempel, shard_prefix = 0110b delas upp i 01100b och 01101b. à sin sida, om tvÄ "grann" shardkedjor börjar kÀnna sig tillrÀckligt bekvÀma (under en viss tid), sÄ slÄs de Äterigen samman.
DÀrför görs sharding "uppifrÄn och ner" - vi antar att varje konto har sin egen shard, men de Àr - för tillfÀllet - "klistrade" ihop efter prefix. Detta innebÀr Infinite Sharding Paradigm (paradigmen av oÀndlig sharding.).
Det Àr vÀrt att pÄpeka att arbetskedjor endast existerar virtuellt - i verkligheten, workchain_id Àr det en del av identifikatorn för den specifika shardkedjan. Formellt sett definieras varje shardkedja av ett par nummer (workchain_id, shard_prefix).
FelrÀttning. Vertikala blockkedjor.
Det anses traditionellt att varje transaktion i en blockkedja Àr "huggen i sten". Men i fallet med TON förutses möjligheten att "skiva om historien" - om nÄgon (sÄ kallad fisknod) kan bevisa att en av blocken signerades felaktigt. I sÄ fall lÀggs en sÀrskild korrigerande block till den motsvarande shardkedjan, innehÄllande hash av den block som korrigeras (och inte den senaste blocket i shardkedjan). NÀr vi betraktar shardkedjan som en kedja av block som ligger horisontellt, kan vi sÀga att det korrigerande blocket kopplas till det felaktiga blocket inte till höger, utan ovanifrÄn - dÀrför anses det bli en del av den lilla "vertikala blockkedjan". DÀrför kan man sÀga att shardkedjor Àr tvÄdimensionella blockkedjor..
Om efter ett felaktigt block de Ă€ndringar som gjorts refererades av efterföljande block (d.v.s. nya transaktioner gjordes baserat pĂ„ ogiltiga), lĂ€ggs korrigerande block ocksĂ„ "ovanpĂ„" dessa. Om blocken inte pĂ„verkade den "drabbade" informationen, sprider sig inte dessa "korrigerande vĂ„gor" till dem. Till exempel, i illustrationen ovan erkĂ€ndes transaktionen i första blocket som felaktig, vilket ökar saldot för konto C â dĂ€rför mĂ„ste transaktionen som minskar saldot för detta konto i det tredje blocket ocksĂ„ annulleras, och ett korrigerande block ska göras över blocket.
Det Ă€r vĂ€rt att notera â Ă€ven om korrigerande block visas som placerade "ovanför" originalen, kommer de faktiskt att skrivas in i slutet av den motsvarande blockchain (dit de hĂ€ndelsemĂ€ssigt ska befinna sig). Den tvĂ„dimensionella placeringen visar bara vilken punkt i blockkedjan de kommer att "kopplas" till (genom hashet frĂ„n det ursprungliga blocket).
Man kan sĂ€rskilt filosofera över hur bra det Ă€r att "Ă€ndra det förflutna". Det verkar som om vi accepterar möjligheten för ett felaktigt block i shardkedjan, sĂ„ kan vi inte undvika möjligheten för ett felaktigt korrigerande block. HĂ€r, sĂ„ lĂ„ngt jag kan döma, ligger skillnaden i antalet noder som mĂ„ste nĂ„ en överenskommelse angĂ„ende nya block â vid varje shardkedja kommer en relativt liten "arbetsgrupp" av noder (som ofta Ă€ndrar sin sammansĂ€ttning) arbeta, medan införandet av korrigerande block krĂ€ver samtycke frĂ„n alla valideringsnoder. Mer om validerare, arbetsgrupper och andra roller för noder kommer jag att berĂ€tta i nĂ€sta artikel.
En blockchain för att styra alla
Ovan beskrivs mycket information om olika typer av blockkedjor, som ocksÄ bör lagras nÄgonstans. SÀrskilt handlar det om följande uppgifter:
- om antal och konfigurationer av arbetskedjor;
- om antal shardkedjor och deras prefixer;
- om vilka noder som för nÀrvarande ansvarar för vilka shardkedjor;
- hashar av de senaste tillagda blocken i alla shardkedjor.
Som du redan har gissat, registreras alla dessa saker i en annan lagringsblockkedja â masterkedja (masterchain, master blockchain). Tack vare nĂ€rvaron av hash-blocken frĂ„n alla shard-blocken, gör det systemet starkt sammankopplat. Det innebĂ€r bland annat att genereringen av ett nytt block i master-chain kommer att ske direkt efter att blocken i shard-chains har genererats â det förvĂ€ntas att block i shard-chains kommer att dyka upp nĂ€stan samtidigt var femte sekund, och nĂ€sta block i master-chain en sekund efter det.
Men vem kommer att vara ansvarig för att genomföra hela detta titanska arbete â för att skicka meddelanden, utföra smarta kontrakt, skapa block i shard-chains och master-chain, och dessutom kontrollera block för fel? Kommer verkligen detta att ske i tysthet av telefonerna hos miljontals anvĂ€ndare med Telegram-klienten installerad pĂ„ sina enheter? Eller kanske Durovs team kommer att ge upp idĂ©erna om decentralisering och lĂ„ta sina servrar göra det som förr?
I sjÀlva verket Àr inget av svaren korrekta. Men utrymmet för denna artikel rinner snabbt ut, sÄ diskussionen om de olika rollerna för noder (du har kanske redan mÀrkts nÄgra av dem) och hur de fungerar kommer att fortsÀtta i nÀsta del.
KĂ€lla: habr.com
