14 januari tl; dc (för länge, ringde inte)

varning: Detta är en uppfattning om ämnen som diskuteras i det återkommande Eth1.x-forskningssamtalet och representerar inte slutförda planer eller åtaganden för uppgraderingar av nätverket.

De viktigaste ämnena för detta samtal var

  • Grova data som kvantifierar fördelarna med att byta till en binär trie-struktur
  • Övergångsstrategier och potentiella utmaningar för en övergång till binära försök
  • “Merklizing” kontraktskod för vittnen och konsekvenser för gasplanering / mätning
  • Beskärning av kedjor och historisk kedja / tillståndsdata – nätverkskonsekvenser och metoder för distribution

logistik

Helgen efter EthCC (7–8 mars) kommer det att finnas ett litet forskningstoppmöte med 1,x, med avsikt att ha några dagar av solid diskussion och arbete med de aktuella ämnena. Sessionen kommer att vara avslutad (med platsbegränsningar) vid 40 deltagare, vilket borde vara mer än tillräckligt för deltagarna som förväntas.

Det kommer sannolikt också att finnas någon informell, ad hoc-samling runt Stanford Blockchain-veckan och ETHDenver, men ingenting planeras uttryckligen.

Nästa samtal planeras tentativt för den första eller andra veckan i februari – halvvägs mellan nu och toppmötet i Paris.

Teknisk diskussion

EIP # 2465

Även om det inte är direkt relaterat till statslös ethereum, förbättrar detta EIP nätverksprotokollet för transaktionsutbredning och är därmed en ganska enkel förbättring som rör saker i rätt riktning för vad forskningen arbetar med. Stöd!

Binary Trie storlek besparingar

Övergång till en binär trie-struktur (istället för den nuvarande hexary trie-strukturen) bör i teorin minska storleken på vittnen med något som 3,75x, men i praktiken kan den minskningen bara vara ungefär hälften beroende på hur du ser på det..

Vittnen är cirka 30% kod och 70% hashes. Hashar inom trie reduceras med 3x, men koden förbättras inte med en binär trie, eftersom den alltid måste inkluderas i vittnet. Så att byta till ett binärt trie-format kommer att ge vittnesstorlekar till ~ 300-1400 kB, ner från ~ 800-3.400 kB i hexary-trie.

Gör omkopplaren

Att utta den faktiska övergången till en binär trie är en annan sak, med några få frågor som måste utplanteras. Det finns i huvudsak två olika möjliga strategier som kan följas:

progressiv övergång – Detta är en “Ship of Theseus” -modell för övergång där hela statstrie migreras till ett binärt format konto-för-konto och storageSlot-by-storageSlot, eftersom varje del av staten berörs av EVM-körning. Detta innebär att Ethereums tillstånd för alltid skulle vara en hexary / binär hybrid och att konton skulle behöva “pokas” för att uppdateras till det nya trieformatet (kanske med en POKE-kod). Fördelarna är att detta inte avbryter kedjans normala funktion och inte kräver storskalig samordning för uppgradering. Nackdelen är komplexitet: både hexary- och binära trie-format måste redovisas i klienter, och processen skulle aldrig “slutföras”, eftersom vissa delar av staten inte kan nås externt och måste behöva expliceras av deras ägare vilket förmodligen inte kommer att hända för hela staten. Den progressiva strategin skulle också kräva att kunder modifierar sin databas för att vara en slags ‘virtualiserad’ binär trie inuti en hexary-databaslayout, för att undvika en plötslig dramatisk ökning av lagringskraven för alla klienter (Obs: denna databasförbättring kan ske oberoende av den fulla “progressiva” övergången och skulle fortfarande vara fördelaktig ensam).

beräkna och rengöra – Detta skulle vara en “på en gång” övergång som utförs över en eller flera hårddiskar, varvid ett datum i framtiden skulle väljas för omkopplaren, och då skulle alla deltagare i nätverket behöva beräkna staten som en binär trie, och växla sedan till det nya formatet tillsammans. Denna strategi skulle på något sätt vara “enklare” att genomföra eftersom den är enkel på ingenjörssidan. Men det är mer komplicerat ur ett samordningsperspektiv: Det nya binära trie-tillståndet måste förberäknas före gaffeln som kan ta en timme (eller däremot) – under det fönstret är det inte klart hur transaktioner och nya block skulle hanteras (eftersom de skulle behöva inkluderas i den ännu icke-beräknade binära tillståndstrie och / eller den äldre trie). Denna process skulle försvåras av det faktum att många gruvarbetare och utbyten föredrar att uppgradera klienter i sista stund. Alternativt kan vi tänka oss att stoppa hela kedjan under en kort tid för att beräkna det nya tillståndet – en process som kan vara ännu svårare och potentiellt kontroversiell att samordna.

Båda alternativen är fortfarande “på bordet” och kräver ytterligare övervägande och diskussion innan några beslut fattas när det gäller nästa steg. I synnerhet väga avvägningarna mellan implementeringskomplexitet å ena sidan och samordningsutmaningar å andra sidan.

Kod “chunking”

När det gäller koddelens vittne har det varit ett visst prototyparbete som utförts med kod “merklisering”, vilket i huvudsak gör det möjligt att dela upp kontraktskoden i bitar innan de läggs in i ett vittne. Den grundläggande idén är att, om en metod i ett smart kontrakt kallas, skulle vittnet bara behöva inkludera de delar av kontraktskoden som faktiskt kallades, snarare än hela kontraktet. Detta är fortfarande mycket tidigt forskning, men det antyder en ytterligare ~ 50% minskning av kodpartiet för ett vittne. Mer ambitiöst kan utövandet av kodkodning utvidgas för att skapa en enda global ‘kodtrie’, men detta är inte en väl utvecklad idé och har troligen sina egna utmaningar som motiverar ytterligare utredning.

Det finns olika metoder med vilka kod kan delas upp i bitar och sedan användas för att generera vittnen. Den första är “dynamisk”, i det att den förlitar sig på att hitta JUMPDEST-instruktioner och klyva sig nära dessa punkter, vilket resulterar i variabla storleksstorlekar beroende på koden som bryts upp. Den andra är “statisk”, som skulle dela upp koden i fasta storlekar och lägga till några nödvändiga metadata som anger var korrekta hoppdestinationer är i biten. Det verkar som att någon av dessa två tillvägagångssätt skulle vara giltiga, och båda kan vara kompatibla och kan lämnas åt användarna att bestämma vilka de ska anställa. Hur som helst, chunking möjliggör en ytterligare krympning av vittne storlekar.

(O) gas

En öppen fråga är vilka förändringar som skulle vara nödvändiga eller önskvärda vid gasplanering med införandet av blockvittnen. Vittnegenerering måste betalas med gas. Om koden chunkas, inom ett block skulle det finnas viss överlappning där flera transaktioner täcker samma kod, och därmed delar av ett blockvittne betalas mer än en gång av alla inkluderade transaktioner i blocket. Det verkar som en säker idé (och en som skulle vara bra för gruvarbetare) skulle vara att lämna den till affischen för en transaktion för att betala hela kostnaden för sitt eget transaktions vittne och sedan låta gruvarbetaren behålla överbetalningen. Detta minimerar behovet av förändringar i gaskostnader och stimulerar gruvarbetare att producera vittnen, men tyvärr bryter den nuvarande säkerhetsmodellen för att bara lita på subsamtal (i en transaktion) med en del av den totala engagerade gasen. Hur denna förändring av säkerhetsmodellen hanteras är något som måste beaktas fullt ut och noggrant. I slutet av dagen är målet att debitera varje transaktion kostnaden för att producera sitt eget vittne, proportionellt mot koden den berör.

Wei Tangs UNGAS-förslag kan göra ändringar i EVM lättare att utföra. Det är inte strikt nödvändigt för statslös Ethereum, men det är en idé för hur man kan underlätta framtida brytningar av gasplaner. Frågan att ställa är “Hur ser förändringarna ut både utan och med UNGAS – och de saker som beaktas gör UNGAS faktiskt det här väsentligt lättare att genomföra?”. För att svara på detta behöver vi experiment som kör saker med merkliserad kod och nya tillämpade gasregler, och sedan se vad som ska förändras med avseende på kostnader och exekvering i EVM.

Beskärning och leverans av data

I en statslös modell behöver noder som inte har någon del av eller hela staten ett sätt att signalera till resten av nätverket vilken data de har och vilken data de saknar. Detta har konsekvenser för nätverkstopologi – statslösa klienter som saknar data måste kunna pålitligt och snabbt hitta den information de behöver någonstans i nätverket, såväl som att sända upp den information de inte har (och kanske behöver). Att lägga till en sådan funktion till en av EIP: s kedjan-beskärning är en protokollförändring i nätverk (men inte konsensus), och det är något som också kan göras nu.

Den andra sidan av detta problem är var man ska lagra historiska data, och den bästa lösningen som hittills föreslagits är ett Et-specifikt distribuerat lagringsnätverk som kan tjäna efterfrågad information. Detta kan komma i många smaker; det fullständiga tillståndet kan vara mottagligt för “chunking”, liknande kontraktskod; partiella tillståndsnoder kunde vakta över (slumpmässigt tilldelade) delstater och tjäna dem på begäran på nätverkets kanter; klienter kan använda ytterligare datarutingsmekanism så att en statslös nod fortfarande kan få saknade data via en mellanhand (som inte har de data den behöver, men är ansluten till en annan nod som gör det). Men hur det är implementerat är det allmänna målet att klienter ska kunna gå med i nätverket och kunna få all information de behöver, pålitligt och utan att jocka för position som ansluter till en fullständig nod, vilket är effektivt vad som händer med LES noder nu. Arbetet kring dessa idéer är fortfarande i tidiga stadier, men geth-teamet har några lovande resultat som experimenterar med “state tiling” (chunking), och turbo-geth arbetar med datarutning för att skvallra delar av staten.


Som alltid, om du har frågor om Eth1x-ansträngningar, förfrågningar om ämnen eller vill bidra, delta i ett evenemang, kom presentera dig på ethresear.ch eller nå ut till @gichiba och / eller @JHancock på twitter.

LEAVE A REPLY

Please enter your comment!
Please enter your name here