Eftersom många av oss har lite mer tid på händerna, tänkte jag att det nu kan vara ett bra tillfälle att fortsätta med något kanske lite tråkigt och tråkigt, men ändå ganska grundläggande för den statslösa Ethereum-ansträngningen: att förstå den formella vittnesspecifikationen.

Liksom kaptenen för Battleship i StarCraft kommer vi att ta det långsamt. Vittnesspecifikationen är inte särskilt komplicerad koncept, men det är mycket djup. Det djupet är lite skrämmande, men är väl värt att utforska, eftersom det kommer att ge insikter som, kanske till din nördiga glädje, sträcker sig långt bortom blockchains världen, eller till och med programvara!

I slutet av denna primer bör du ha åtminstone minimalt livskraftigt förtroende för din förmåga att förstå vad den formella statslösa Ethereum Specifikation för vittnen handlar om. Jag försöker göra det lite mer roligtockså.

Sammanfattning: Vad du behöver veta om staten

Stateless Ethereum är naturligtvis lite felaktigt, eftersom staten verkligen är det som hela denna ansträngning handlar om. Specifikt att hitta ett sätt att göra en kopia av hela Ethereum-staten och valfri sak. Om du inte har följt den här serien kan det vara värt att titta på min tidigare primer om tillståndet till statslös Ethereum. Jag kommer dock att ge en kort TL; DR här. Känn dig fri att skumma om du känner att du redan har ett bra grepp om detta ämne.

Den fullständiga “staten” Ethereum beskriver den aktuella statusen för alla konton och saldon, liksom de kollektiva minnen från alla smarta kontrakt som distribueras och körs i EVM. Varje slutgiltigt block i kedjan har ett och endast ett tillstånd, vilket överenskommits av alla deltagare i nätverket. Det tillståndet ändras och uppdateras med varje nytt block som läggs till i kedjan.

Ethereum-staten är representerad in silico som en Merkle-Patricia Trie: en hashad datastruktur som organiserar varje enskild information (t.ex. en kontobalans) i en massiv ansluten enhet som kan verifieras för unikhet. Den kompletta tillståndstrisen är för massiv för att visualisera, men här är en “leksaksversion” som kommer att vara till hjälp när vi kommer till vittnen:

leksaksstatstjärna

Liksom magiska kryptografiska larver lever konton och kod för smarta kontrakt i trädets löv och grenar, vilket genom successiv hashning så småningom leder till en enda rot hash. Om du vill veta att två kopior av en statstrie är desamma kan du helt enkelt jämföra rot hasherna. Att upprätthålla relativt säkert och obestridligt samförstånd om ett “kanoniskt” tillstånd är kärnan i vad en blockchain är utformad för att göra.

För att skicka en transaktion som ska inkluderas i nästa block, eller för att bekräfta att en viss förändring överensstämmer med det sist inkluderade blocket, måste Ethereum-noder behålla en fullständig kopia av staten och beräkna om root-hash (över och om igen). Stateless Ethereum är en uppsättning förändringar som tar bort detta krav genom att lägga till det som kallas ett “vittne”.

Ett vittne skiss

Innan vi dyker in i vittnesspecifikationen hjälper det att ha en intuitiv känsla av vad ett vittne är. Återigen finns det en mer ingående förklaring i inlägget om Ethereum-staten som är länkad ovan.

Ett vittne är lite som ett fuskark för en glömsk (statslös) student (klient). Det är bara den minsta mängden information som krävs för att klara provet (skicka en giltig statusändring för att inkluderas i nästa block). Istället för att läsa hela läroboken (behålla en kopia av det aktuella tillståndet) ber den glömska studenten (statslös klient) en vän (fullständig nod) för en spjälsark för att lämna in sina svar.

I mycket abstrakta termer tillhandahåller ett vittne alla de nödvändiga hasherna i en statstrie, i kombination med viss “strukturell” information om var i trie dessa hascher hör hemma. Detta tillåter en “glömsk” nod att inkludera en ny transaktion i dess tillstånd och att beräkna en ny root-hash lokalt – utan att kräva att de laddar ner en hel kopia av state-trien.

Låt oss flytta från den tecknad filmiska idén och mot en mer konkret representation. Här är en “riktig” visualisering av ett vittne:

vittne-hex

Jag rekommenderar att du öppnar den här bilden i en ny flik så att du kan zooma in och verkligen uppskatta den. Detta vittne valdes eftersom det är relativt litet och enkelt att välja funktioner. Varje lilla kvadrat i den här bilden representerar en enda “nibble”, eller hälften av en byte, och du kan verifiera dig själv genom att räkna antalet rutor som du måste “passera”, börja vid roten och slutar på en Ether-balans (du bör räkna 64). Medan vi tittar på den här bilden, lägg märke till den enorma biten av koden inom en av transaktionerna som måste ingå för ett samtalssamtal – koden utgör en relativt stor del av vittnet och kan reduceras med kodmarkering (som vi Jag ska utforska en annan dag).

Vissa formaliteter

En av de grundläggande särdragen hos Ethereum som ett protokoll är dess oberoende från en viss implementering. Det är därför, snarare än bara en officiell klient som vi ser i Bitcoin har Ethereum flera helt olika versioner av klient. Dessa klienter, skrivna på olika programmeringsspråk, måste följa Ethereum Yellow Paper, vilket förklarar i mycket mer formella termer hur några klienten bör bete sig för att delta i Ethereum-protokollet. På så sätt behöver en utvecklare som skriver en klient för Ethereum inte hantera någon tvetydighet i systemet.

Vittnesspecifikationen har detta exakta mål: att tillhandahålla en entydig beskrivning av vad ett vittne är, vilket gör det enkelt att implementera det på alla språk för alla klienter. Om och när Stateless Ethereum blir “en sak”, kan vittnesspecifikationen infogas i gulboken som en bilaga.

När vi säger entydig i detta sammanhang betyder det något starkare än vad du kan betyda i vanligt tal. Det är inte så att den formella specifikationen bara är en riktigt, riktigt, verkligen detaljerad beskrivning av vad ett vittne är och hur det uppför sig. Det betyder att det idealiskt finns det bokstavligen ett och bara ett sätt beskriv ett vittne. Det vill säga, om du följer den formella specifikationen, skulle det vara det omöjlig för dig att skriva en implementering för Stateless Ethereum som genererar vittnen annorlunda än någon annan implementering som också följer reglerna. Detta är nyckeln, eftersom vittnet kommer (förhoppningsvis) att bli en ny hörnsten i Ethereum-protokollet; Det måste vara korrekt genom konstruktion.

A Matter of Semantics (and Syntax)

Även om “blockchain-utveckling” vanligtvis innebär något nytt och spännande, måste det sägas att mycket av det är baserat i mycket äldre och klokare traditioner av datorprogrammering, kryptografi och formell logik. Detta kommer verkligen ut i vittnesspecifikationen! För att förstå hur det fungerar, måste vi känna oss bekväma med några av de tekniska termerna, och för att göra det måste vi ta en liten omväg till lingvistik och formell språkteori.

Läs högt följande två meningar och var särskilt uppmärksam på din intonation och kadens:

  • rasande sömnidéer grön färglös
  • färglösa gröna idéer sover rasande

Jag slår vad om att den första meningen kom ut lite robot, med en plan betoning och paus efter varje ord. Däremot kändes troligen andra meningen naturligt, om det är lite dumt. Även om det inte riktigt gjorde det betyder vad som helst, andra meningen vettigt på ett sätt som den första inte gjorde. Detta är en liten intuktionspump för att uppmärksamma skillnaden mellan Syntax och Semantik. Om du är engelsktalande har du en förståelse för vad orden är representera (deras semantiska innehåll), men det var till stor del irrelevant här; vad du märkte var skillnaden mellan giltig och ogiltig grammatik (deras syntax).

Detta exempel är från ett papper från 1956 av en Noam Chomsky, som är ett namn du kanske känner igen. Även om han nu är känd som en inflytelserik politisk och social tänkare, var Chomskys första bidrag som akademiker inom området logik och lingvistik, och i denna artikel skapade han ett av de mest användbara klassificeringssystemen för formella språk.

Chomsky handlade om den matematiska beskrivningen av grammatik, hur man kan kategorisera språk baserat på deras grammatikregler och vilka egenskaper dessa kategorier har. En sådan egendom som är relevant för oss är syntaktisk tvetydighet.

Tvetydig buffel

Tänk på den grammatiskt korrekta meningen “Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo.”- detta är ett klassiskt exempel som illustrerar hur tvetydiga engelska syntaxregler kan vara. Om du förstår att beroende på sammanhanget kan ordet “buffel” användas som ett verb (för att skrämma), ett adjektiv (kommer från Buffalo, NY) eller ett substantiv (en bison), kan du analysera meningen på var varje ord hör hemma.

Vi kan också använda helt olika ord och flera meningar: “Du känner till NY-bisonen som andra NY-bison skrämmer? De skrämmer också. De skrämmer NY-bison, för att vara exakt. ”

Men vad händer om vi vill ta bort tvetydigheten, men ändå begränsa våra ord till att bara använda “buffel”, och behålla allt som en enda mening? Det är möjligt, men vi måste ändra reglerna på engelska lite. Vårt nya “språk” kommer att bli lite mer exakt. Ett sätt att göra det vore att markera varje ord för att ange dess tal, som så:

Buffalo{pn} buffalo{n} Buffalo{pn} buffalo{n} buffalo{v} buffalo{v} Buffalo{pn} buffalo{n}

Kanske är det fortfarande inte mycket tydligt för en läsare. För att göra det ännu mer exakt, låt oss försöka använda lite av utbyte för att hjälpa oss att flocka några av dessa “bufflar” i grupper. Varje bison från Buffalo, NY är egentligen bara en speciell version av vad vi skulle kalla en ”substantivfras”, eller . Vi kan ersätta in i meningen varje gång vi stöter på strängen Buffalo{pn} buffalo{n}. Eftersom vi blir lite mer formella kan vi kanske besluta att använda en kortfattad notation för denna och andra framtida ersättningsregler genom att skriva:

::= Buffalo{pn} buffalo{n}

var ::= betyder “Vad som finns på vänster sida kan ersättas med vad som finns på höger sida”. Det är viktigt att vi inte vill att det här förhållandet ska gå åt andra hållet. föreställ dig hur galet Boulder buffeln skulle bli!

Genom att använda vår ersättningsregel på hela meningen skulle det ändras till:

buffalo{v} buffalo{v}

Nu är detta fortfarande lite förvirrande, för i den här meningen finns det en smal relativ klausul, som kan ses mycket tydligare genom att infoga ordet “det” i den första delen av vår mening, d.v.s. *that* buffalo{v}....

Så låt oss göra en substitutionsregel som grupperar den relativa klausulen i , och säg:

::= buffalo{v}

Eftersom en relativ klausul egentligen bara gör en förtydligande om en substantivfras, motsvarar de två sammantaget bara en annan substantivfras:

::=

Med dessa regler definierade och tillämpade kan vi skriva meningen som:

buffalo{v}

Det verkar ganska bra, och verkligen får kärnförhållandet denna dumma mening uttrycker: En särskild grupp bison som skrämmer en annan grupp bison.

Vi har tagit det hittills, så varför inte gå hela vägen? Närhelst ‘buffalo’ som ett verb föregår ett substantiv, kan vi kalla det ett verbfras, eller och definiera en regel:

::= buffalo{v}

Och med det har vi vår enda fullständiga giltiga mening, som vi kan kalla S:

S ::=

Det vi har gjort här kan vara bättre visuellt:

buffel

Den strukturen ser nyfiken bekant ut, eller hur?

Buffelexemplet är lite dumt och inte särskilt strängt, men det är tillräckligt nära för att visa vad som händer med det konstiga matematiska språket i Witness Specification, som jag har väldigt snyggt introducerat i min rant om buffalo. Det heter Backus-Naur-form notering, och den används ofta i formella specifikationer som denna, i en mängd olika verkliga scenarier.

De “substitutionsreglerna” som vi definierade för vårt begränsade engelskspråk hjälpte till att se till att vi, med tanke på en flock “buffel”, kunde konstruera en “giltig” mening utan att behöva veta någonting om vad ordet buffel betyder i den verkliga världen. I klassificeringen som först klargjorts av Chomsky kallas ett språk som har tillräckligt exakta regler för grammatik som gör att du kan göra detta sammanhang fritt språk.

Ännu viktigare är att reglerna säkerställer att för alla möjlig mening som består av ordet buffalo{np|n|v}, det finns ett och bara ett sätt att konstruera datastrukturen illustrerad i trädschemat ovan. O-tvetydighet FTW!

Gå framåt och läs specifikationen

Vittnen är i grunden bara ett enda stort objekt, kodat i en byte-grupp. Från (antropomorfe) perspektivet för en statslös klient, kan den matrixen av byte se lite ut som en lång mening bestående av mycket liknande ord. Så länge alla klienter följer samma uppsättning regler, bör matrisen av byte konverteras till en och en enda hashad datastruktur, oavsett hur implementeringen väljer att representera den i minnet eller på disken.

Produktionsreglerna, som skrivs ut i avsnitt 3.2, är lite mer komplexa och mycket mindre intuitiva än de som vi använde för vårt leksaksexempel, men andan är väldigt densamma: Att vara entydig riktlinjer för en statslös klient (eller en utvecklare som skriver en klient) att följa och vara vissa de får rätt.

Jag har glansat över en hel del i den här utställningen, och kaninhålet med formella språk går mycket djupare, för att vara säker. Mitt mål här var att bara ge tillräckligt med en introduktion och grund för att övervinna det första hindret för förståelse. Nu när du har rensat det hinderet är det dags att öppna wikipedia och tackla resten själv!

Som alltid, om du har feedback, frågor eller önskemål om ämnen, vänligen @gichiba eller @JHancock på twitter.

LEAVE A REPLY

Please enter your comment!
Please enter your name here