Vänner,

Från vårt team till dig och ditt, hoppas vi att alla och deras familjer har det bra och håller sig trygga under dessa komplicerade veckor. För att hjälpa till att gå lite tid medan vi alla sitter fast i dörrar är det dags igen att uppdatera gemenskapen om framsteg som gjorts av några av de EF-stödda projekten som inte omfattas av förra veckans ESP Allocation Update. Medan den senaste vinterutgåvan i denna serie publicerades för bara några månader sedan, har vi alla kommit långt sedan lanseringen av uppgraderingen av nätverket i Istanbul, och många lag har nyheter att dela.

Som alltid fokuserar dessa uppdateringar på EF-stödda team och ansträngningar vars medlemmar arbetar för att växa och förbättra Ethereum som helhet. I denna utgåva ingår uppdateringar från många lag som lyfts fram i föregående rapportoch andra nya och roterande nyheter.

Njut av!

Aleth / C ++ Ethereum


Författad av Paweł Bylica

I december 2019, 1.8.0 versionen av Aleth släpptes. Den innehåller ett antal korrigeringar och förbättringar relaterade till en mängd olika aspekter av hur denna C ++ Ethereum-nod fungerar. I synnerhet gjorde vi förbättringar av RPC-gränssnittet, blockchain-synk och nätverksprotokoll och testverktyg (testeth, aleth-vm). Ser CHANGELOG för mer detaljer.

Denna utgåva innehåller också betydande arbete relaterat till konsensusmekanismen:

  • Muir Glacier stöd för nätverksuppgradering.
  • EIP-1380 ”Reducerad gaskostnad för call to self” -implementering.
  • EIP-2046 “Reducerad gaskostnad för statiska samtal för förkompilerade” implementering.
  • Stöd för individuell EIP-aktivering för att underlätta EIP-centrerad nätverksuppgraderingsprocess.

Aleth 1.8.0 är den senaste planerade versionen. Från och med nu har vi bara åtagit oss att grundläggande underhåll av koden, Pull Request-granskning och uppfylla de återstående behoven för testning och EIP-granskningar. Vid denna tidpunkt vill jag tacka alla Aleth-bidragsgivare, särskilt Nils-Erik Frantzell som lagt ner mycket arbete i projektet under det gångna året.

Det är också värt att nämna underhållsreleaser för syskonprojekt:

Sist men inte minst har vi publicerat en artikel om Effektiv gasberäkningsalgoritm för EVM, senare ingår i Devcon 5-presentation Optimeringstekniker för implementering av EVM.

Tillämpad ZKP


Författad av Koh Wei Jie och Kobi Gurkan

Applied ZKP-teamet arbetar för att överbrygga klyftan mellan banbrytande forskning i nollkännedom och applikationsutveckling på Ethereum.

Evighetsmakten i Tau

I september 2019 lanserade vi Evighetsmakten från Tau-ceremonin (PPot). PPOT syftar till att gynna ekosystemet med nollkännedom, särskilt zk-SNARK-projekt byggda på Ethereum, genom att delvis underlätta bördan för betrodda inställningsceremonier. Varje zk-SNARK-projekt kräver två faser av parametergenerering, och PPOT ersätter den första fasen, som kan delas av alla kretsar. Enskilda team kan välja vilket bidrag som helst från ceremonin för att grenas ut och utföra sin egen fas 2-installation.

Denna ceremoni stöder kretsar upp till 2 ^ 28 begränsningar, vilket innebär att varje bidrag kräver en nedladdning av 97G, en 1-dagars beräkning och en 49G-överföring. I skrivande stund samlade vi 29 bidrag från 28 unika individer, och alla bidragsfiler kan laddas ner och oberoende verifieras mot en offentligt ceremoniutskrift.

Semafor

Semaphore är Applied ZKP: s flaggskeppsprojekt som initierades i mitten av 2019. Det är en generisk integritetsgadget som gör det möjligt att använda fall som blandare, anonym inloggning och anonym röstning. Ett användningsfall av Semaphore, utvecklat av Chih-Cheng Liang, är Semaphore Autentisering, vilket möjliggör anonyma inloggningar med skydd mot Sybil-attacker. Vi uppmuntrar läsarna att kolla in detta förklarande blogginlägg att förstå vad Semaphore är och hur det fungerar.

Säkerhetsrevision och kodrelease

Vi engagerade ABDK Consulting för att utföra en säkerhetsrevision av Semaphores zk-SNARK-kretskod och soliditetskontrakt. Vi fixade de problem som de avslöjade, och släppte den slutliga källkoden. Vi har inkluderat i revisionen många komponenter från circom standardbibliotek, vilket ger en större uppsättning verktyg som ska användas av det bredare samhället av SNARK-utvecklare som använder circom.

Fas 2 ceremoni

I skrivande stund genomför vi en kretsspecifik inställningsceremoni för flera partier. Processen vi följer är dokumenterad här. Vi samarbetade med Överstatlig, en medlem av VDF Alliance, för att köra en verifierbar fördröjningsfunktion (VDF) på en pre-meddelade Ethereum block hash, och använde utdata från nämnda VDF på utmaningsfil # 25 från ceremonin Perpetual Powers of Tau (se nedan), och startade den kretsspecifika ceremonin den 6 april 2020.

Tack vare utmärkt arbete av Brian Gu, vi kunde återanvända Aztec ProtocolProgramvara för tändningsceremoni för vår ceremoni. Läs mer om denna ceremoni genom att läsa den deltagarguide.

Diskutera gärna i Semaphore Society Telegram chattgrupp.

Semaphore RLN

Semaphore RLN ger ett sätt att utföra hastighetsbegränsning i en P2P-inställning – istället för att förlita sig på en kedje nullifieringskarta för att förhindra dubbel signalering, använder vi Shamir Secret Sharing för att exponera andelar i programföretagens privata nyckel. Flera publicerade aktier från samma programföretag kan användas för att rekonstruera den privata nyckeln, vilket öppnar upp för att den ursprungliga innehavaren av den privata nyckeln kan rivas.

Maci

Ursprungligen föreslagen av Vitalik Buterin i en ethresear.ch post, system byggda med MACI gör samverkan mellan deltagare svår, samtidigt som man behåller censurmotstånd och fördelar med korrekt utförande av smarta kontrakt. Även om MACI endast kan tillhandahålla samverkansmotstånd om koordinatorn är ärlig, kan en oärlig koordinator varken censurera eller manipulera med dess utförande.

I slutet av 2019 började vi arbeta med en teknisk specifikation och implementering och vi närmar oss färdigställandet av en minimal livskraftig produkt.

Framtida arbete: lägga till anonymisering till MACI

MACI använder en koordinator för bearbetning, där koordinatorn använder SNARK för att bevisa integritet, så att en skadlig koordinator bara kan skada samverkansresistensegenskaper. En nackdel med den nuvarande strategin är att samordnaren kan koppla varje användares ursprungliga nyckel till sin slutliga nyckel, eftersom de ser alla nyckeländringarna.
Vi försöker förbättra integriteten gentemot samordnaren genom att låta anonyma nyckeländringar från användare. Läs mer om detta ethresear.ch post.

MiMC-belöning

MiMC har blivit en populär kryptografisk hashfunktion i SNARKs på grund av dess stora prestanda. Även om det är den äldsta av gruppen i “hash-funktioner med låg multiplikativ komplexitet” -familj av funktioner, tyckte vi att det borde få mer kritisk uppmärksamhet. Vi initierade en vinst för kollisionsupptäckt i MiMC, som vi också planerar att utvidga till Poseidon.

Optimistisk samlad hub + ZK Optimistisk rullning

Optimistisk insamling möjliggör större skalbarhet i lager 2 med användning av tillgänglighet i kedjan och bedrägeribevis. Hubkedjan möjliggör vidare enkel massvandring mellan olika rullar. Navet möjliggör enkel massmigrering.

ZK Optimistic Rollup bygger på samma idé men för anonyma överföringar. Istället för att ha alla transaktionsmetadata tydliga, är varje transaktion i samlingen en 2 till 2 anonym överföring.

PeekABook

PeekABook tillåter två användare att matcha beställningar privat, så att ingen användare kan upptäcka mer information om en beställning som gjorts av en annan användare om de inte har en beställning som skulle uppfylla den.

Experimentella anvisningar

Fram till nu har vi beskrivit projekt som vi har släppt – antingen som mogna kod, specifikationer eller konkreta planer. Vi undersöker kontinuerligt nya experimentområden som vi hoppas kommer att mogna till fullfjädrade projekt.
Några av dessa inkluderar:

  • Verifiera en STARK i SNARK – möjliggör någon form av rekursion av lager 1
  • Blind Find – En MPC-baserad konstruktion som bevisar att det finns en sökväg mellan användare i ett p2p-nätverk, utan att avslöja själva banan.
  • Fraktal på Ethereum
  • RSA-baserad sammanläggning

Och mer 🙂

Ekosystem Support Program


Den 1 april publicerade vi ESP Allocation Update, där vi delade något av det arbete vi har gjort för att förbättra våra processer såväl som en lista över de projekt som fick ekonomiskt stöd 2019. Titta på bloggen för fler uppdateringar och följ oss på Twitter (@EF_ESP) för att behålla upp med det senaste om de projekt vi stöder!

Ewasm


Författad av Alex Beregszaszi

Sedan den senaste uppdateringen i december har teamet fortsatt att arbeta med Eth 2.0-fas 2 och börjat också ta en mer aktiv del i Eth 1x-forskningen.

Vår intuition är att vissa delar av forskningen behövs av båda och kan delas mellan de två insatserna.

Eth 1.x / Stateless Ethereum

I en statslös modell förväntas inte att alla behåller en kopia av hela blockchainens tillstånd. Istället kommer varje block med ett bevis (det så kallade vittnet) för den del av staten som drabbats. Optimal skapande, distribution och verifiering av vittnen blir en avgörande del av detta nya statslösa system. Utmaningen med skapande och verifiering är det som intresserar vårt team mest.

Det finns olika idéer för att minska blockvittensstorleken, av vilka Paul har samlat in en undersökning. Med tanke på vår bakgrund i instruktionsuppsättningar är det första problemet vi tittade på att minska kodstorleken. Detta är viktigt eftersom koden också måste inkluderas i vittnet. Två tillvägagångssätt kommer att tänka på: komprimering och merklisering. En tidig fas experimentera föreslår att vi kan sänka mängden kod som överförts som en del av blockvittnet med 40-60%.

Vi planerar vidare att utforska alternativ till

  1. minska lagringsdelen av vittnet,
  2. att noggrant debitera för vittnesstorleken (”vittnesmätning”),
  3. och att delta i att skapa en vittnesspecifikation.

Eth 2.0

Det måste noteras, eftersom exekveringsmodellen för Eth 2.0 också är statslös, blir det arbete som görs som en del av Eth 1x också tillämpligt här.

Tvärskärmdesign

Utan förmågan att effektivt överföra Ether (och eventuellt andra tokens) blir betalning för utförande och transaktioner en komplicerad fråga. Förra året kom ett antal modeller fram, inklusive kvitton med ackumulatorer, köer och balanskartor. Casey har föreslagit ett alternativ som heter EthTransfer-objekt.

Förutom Ether-överföring kan kontrakt kanske kunna kommunicera med andra kontrakt på olika skärvor och potentiellt utföra atomoperationer. Allt detta leder till ett stort designutrymme för fas 2, som vi hittills har utforskat.

Som ett experiment, från några veckor sedan, har vi arbetat med Eth1x64. Detta minskar designutrymmet och bör möjliggöra snabba iterationer av olika mönster.

Under Eth1x64 är varje skärv homogen och kör en instans av Eth 1.x, där skäret 0 är den aktuella Eth 1.0-mainnet. Vi arbetar med flera små förslag som alla fokuserar på olika sätt att åstadkomma kommunikation mellan skärmar.

Detta arbete kommer att ge en uppfattning om komplexiteten i att införa skärmning i Eth1, vilket gör att vi kan samla bredare feedback från Dapp-utvecklare, och vi kan ta resultaten till att förfina de WebAssemble-baserade fas 2-designen.

Fart

Nollkunskapsprotokoll blir allt viktigare. Det måste säkerställas att de kan stöds effektivt på Eth 2.0. En optimerad implementering i AssemblyScript av det SNARK-vänliga MiMC-hashfunktion och ett zkSNARKs-baserat tokenexempel har utvecklats. Detta exempel fungerar bra som en exekveringsmiljö. Benchmarks visar att båda kan uppnå jämförbar prestanda som kompilatormotorer och EVM-baserade (förkompilerade hjälpmedel) implementationer. Ser Jareds sammanfattning för siffror.

Detta arbete vägledde också ytterligare granskningar av det stora heltal-API: et, som är en viktig del av ett kraftfullt och säkert, WebAssemble-baserat utförande.

WebAssembly

De senaste månaderna har varit en givande tid för WebAssemble med lanseringen av den stabila 1.0-versionen av specifikationen. Ett antal nya lovande tolkprojekt har tillkännagivits och / eller släppts. Vi håller noga med på dessa och avser att inkludera dem i vår benchmarkingrapport.

I januari började vi arbeta med Mousserande, en ny webbmonteringsmotor. Funktioner som endast heltalstöd (inga operationer med flytande punkt) och exekvering av tolkar gör det väl lämpat för fall med blockchain-användning. Dessutom syftar en ren kodbas skriven i modern C ++ 17 och målet med enkel inbäddbarhet att göra Fizzy till en livskraftig, modulär komponent för implementering av Eth 2.0-klienter. Vid denna uppdatering kan Fizzy passera nästan alla officiella testfall (med undantag för Wasm-validering, som ännu inte har implementerats) och jämför mycket bra med hastighetsnormer.

Formell verifiering


Författad av Leo Alt och Martin Lundfall

spela teater

spela teater är ett enkelt och effektivt specifikationsspråk för att skriva formella specifikationer. Det utvecklas med input från flera grupper, och vi hoppas att det i framtiden kommer att vara vanligt att använda Act för att specificera smarta kontrakt.

Genom att låta egenskaper uttryckas på olika nivåer är huvudmålet för Act som ett verktyg att möjliggöra modulär verifiering. Specifikationen kan verifieras som ett fristående dokument, där kontraktsinventerare kan kontrolleras från den angivna funktionens pre / post-villkor och postvillkoren kan kontrolleras från en funktions lagringsuppdateringar. Helst kommer den modulära verifieringen att göra det mycket lättare för andra verktyg att verifiera att källkoden / bytkoden är korrekt.

Vi arbetar för närvarande med tre bevis backends för mellanliggande bevis:

  1. Coq-definitioner
  2. K-specifikationer
  3. SMT-teorem

Var och en av backendarna har sina egna fördelar och nackdelar, och vi hoppas kunna uppnå goda prestanda och täckning genom att utveckla alla fronter samtidigt.

Vi hoppas kunna släppa en prototyp av varje bevisbackend och studera hur man uttrycker loopinvarianter fram till juni 2020.

Vi kommer snart att släppa en detaljerad teknisk post om lag. Bidrag till förvaret är alltid välkomna!

SMTChecker

SMTChecker är en modellkontroll baserad statisk analysmodul i Fasthet kompilator som försöker verifiera påståenden om källkod under kompileringstiden. Förra året a ny motor baserad på begränsade hornklasser lades till. Denna motors huvudfunktion är att den automatiskt kan hitta induktiva invarianter som används för att bevisa påståenden, vilket möjliggör stöd för slingor och statliga egenskaper.

Vi har nyligen lagt till interna funktionssamtal till motorn och fortsätter att förbättra stödet för språket Solidity. Under de kommande tre månaderna kommer vi att fortsätta arbeta med att öka språkstöd, motexempel på generation / presentation och externa funktionssamtal, som förhoppningsvis kommer att börja överföra SMTChecker från experimentellt till ett användbart och kraftfullt verktyg.

I framtiden vill vi också:

  1. Kombinera SMTChecker och Act, och studera fantastiska saker som syntes av saknad kod för att matcha specifikationer / syntes av motståndskod.
  2. Skapa ett Remix-plugin för SMTChecker som skulle förbättra användbarheten kraftigt.

Verifierad ABI-kodning / avkodning

Vi samarbetar med ConsenSys FoU som arbetar med en verifierad ABI-kodare / avkodare med Yul-Isabelle. Idén och diskussionerna började vid Devcon V, och sedan dess gjordes goda framsteg och vi är nära en prototyp.

Ursprungligen avser vi att använda det tillsammans med Soliditet Fuzzer för att hitta buggar relaterade till optimering och ABI-kodning / avkodning. Vår sista och lite ambitiösa dröm är att använda den verifierade ABI-kodaren / avkodaren som en del av Solidity-sammanställningsprocessen. Detta skulle innebära att en väsentlig del av kodgenerering verifieras!

eth2

Vi har kontinuerligt stött Runtime Verification för att upprätthålla KEVM formell semantik och verifiera insättningsavtalet och beacon chain specifikationer. Insättningsavtalet är också ett av våra viktigaste riktmärken när vi utvecklar lagen. Vi vill tillhandahålla en alternativ specifikation för insättningsavtalet och bevis för de inkrementella Merkle-trädegenskaperna via lag senast i juli, då vi också tänker studera Eth2-fas 1 och fas 2-egenskaper som måste bevisas.

Hevm

Hevm, en haskell EVM-utvärderare och felsökare kan nu användas för fastighetsbaserad testning.
Användare av dapp utvecklingsverktyg kan nu skriva soliditetstester vars argument genereras slumpmässigt och som körs flera gånger mot korrekthetskriterier. Detta ger ett sätt för smarta kontraktsutvecklare att massivt öka testtäckningen på ett relativt enkelt sätt.

Framöver kommer vi att utforska utvidga hevm med symboliska exekveringsfunktioner. Detta skulle göra det möjligt att använda hevm för att formellt verifiera EVM-bytekod.

Geth


Författad av Péter Szilágyi

Under det senaste kvartalet har Geth-teamet varit upptagna med nätverks VVS och lagt grunden för framtida utsläpp. Det här inlägget kommer bara att räkna med några av de viktigaste funktionerna; För en detaljerad vy av punktpunkterna, se vår släppanteckningar.

DNS-upptäckt

En funktion som vi har angett för ungefär två år sedan och skickat förra kvartalet är DNS-baserad peer-upptäckt. I framtiden har Geth v1.9.11 + -noder två oberoende mekanismer för att hitta kamrater. DNS-listorna fungerar som en fallbackmekanism när kamrater inte kan hittas via DHT. De kan också vara utgångspunkten för en Tor-integration.

DNS-baserad upptäckt är en centraliserad mekanism, men vi har försökt att göra denna mekanism så transparent och tillåtningsfri som möjligt. De offentliga listorna som används som standard genereras genom att genomsöka upptäckten DHT. Noder som kör alla Ethereum-klienter som implementerar EIP-868 och EIP-2124 visas automatiskt i de offentliga listorna. Om du vill skapa en DNS-baserad nodlista för ditt privata eller offentliga nätverk, kolla in vår Installationsguide för DNS Discovery.

För närvarande finns ~ 1150 offentligt dirigerade Ethereum mainnet-noder i standardlistan; och våra offentliga listor betjänar också testnätverket Ropsten, Goerli och Rinkeby. För närvarande genererar nätverket 8 miljoner DNS-frågor per dag till denna upptäckningsmekanism.

Transaktionsförökning

I ett par år nu blandade de flesta nätverksbandbredden som används av Ethereum-noder transaktioner runt. Tyvärr har denna mekanism aldrig optimerats sedan starten, så var den mycket slösaktig. Under det senaste kvartalet har vi specificerat en uppdatering till eth protokoll (EIP 2464) som gör det möjligt att tillkännage transaktioner mellan noder och endast överföras på begäran.

Detta nya protokoll släpptes i Geth v1.9.11, är redan implementerat av Nethermind och pågår också för Open Ethereum. Eftersom bara cirka 30% av nätverket stöder det är mängden bandbredd som sparas globalt fortfarande en fråga, men att köra en eth/64 mot. eth/65 bootnode-experiment med 250 kamrater har lovande resultat.

Baserat på förra veckans trafik, eth/65 kan reducera bandbredd för transaktionsutbredning med cirka 75%. För en startnod av oss med 250 fullständiga node-kamrater sparas 750 kB / s, eller ungefär 1,8 TB bandbredd per månad. Vi är säkra på att det fortfarande finns utrymme för förbättringar, men låt oss ta det ett steg i taget.

Förutom eth/65, Geth levererade stöd för större än 32KB-transaktioner tillbaka i januari (med tillstånd av StarkWare), med en mjuk gräns ursprungligen på 64KB och höjdes snart till 128KB (högre gränser förlitar sig starkt på hur eth/65 fungerar globalt).

Dynamiska ögonblicksbilder

En stor flaskhals när det gäller att driva EVM och göra en första synkronisering kretsar kring statens representation i Ethereum: Merkle Patricia-trie. Eftersom all tillståndsdata är utformad i ett trädformat tar åtkomst till valfritt konto ungefär 6-8 slumpmässiga diskuppslag för närvarande på mainnet. Under snabb synkronisering behöver samma slumpmässiga mellanliggande noder laddas ner en efter en för att komma till faktiska data.

En funktion som vi har arbetat med aktivt i ett halvt år nu är dynamiska tillståndsbilder: kort sagt, skapa en platt accelerationsstruktur på disken som gör att alla konton eller lagringsplatser kan laddas med en diskuppslag. Detta liknar Open Ethereums fatdb layout, förutom den här är dynamisk: snapshot-mekanismen i Geth kan hålla accelerationsstrukturen uppdaterad när kedjan fortskrider (inklusive minigaflarna).

En fördel med de dynamiska ögonblicksbilderna är O (1) läsning av EVM-tillstånd. Även om detta kan låta som en helig gral, så är det inte. De flesta avrättningar av kontrakt går inte galen med skivläsningar, så fördelen är begränsad, och de flesta kontrakt gör också massor av skrivningar, som fortfarande måste skjutas in i Merkle-trie. De dynamiska ögonblicksbilderna tillåter dock eth_call Verksamheten går snabbt och de gör DoS-transaktioner betydligt svårare att dra av.

EN mycket mer intressant funktion som aktiveras av de dynamiska ögonblicksbilderna är ett nytt synkroniseringsprotokoll, som vi har försökt fastställa i två år nu (ursprungligen kallade leaf sync). Protokollet är fortfarande ett pågående arbete, men om våra länkar är korrekta, bör det göra det möjligt att synkronisera Ethereum-staten betydligt snabbare.

Upptäckt v5

Den ursprungliga versionen av nästa generations upptäcktsprotokoll implementerades i Geth, även om det ännu inte är aktiverat. Medan specifikationen och implementeringen fortfarande är flytande, synkroniseras med Eth 2.0-kraven, är det är en enorm milstolpe för att ha en fungerande version i den levande kodbasen.

Javascript Team


Författad av: Holger Drewes, Philipp Langhans

Förra kvartalet var spännande för laget. För första gången träffades vi personligen i början av mars under EthCC i Paris, fördjupade relationerna och diskuterade teamsamarbete, möjliga samarbeten och framtidsplaner. Räkna med att höra mer om det när saker börjar bära frukter.

Ethers.js

etrar v5 går igenom det sista betaversioner före den sista lanseringen. Många korrigeringar och förbättringar av användbarhet (som mer passande namn för API-samtal) som diskuterats med samhället har använts för att förbereda en stabil och robust slutversion. Anmärkningsvärda nya funktioner som har lagts till nyligen är de nya WebSocketProvider och experimentell EIP-1193 (Ethereum Provider JavaScript API) support.

Web3.js

Efter att ha varit huvudansvarig för Web3.js-biblioteket i mer än ett år har Samuel beslutat att det nu är dags att fortsätta med nya äventyr (tack Samuel för allt ditt fantastiska arbete! ♥ ️). Vi har haft ett sista samarbete under dagarna kring EthCC. Bibliotekets utveckling kommer nu att övertas av andra gruppmedlemmar på gemensam basis.

För tillfället har vi ett starkt fokus på att säkerställa en stabil frisättningsprocess och vi arbetar med att bekanta oss med teknikbunten och förfarandena sedan Samuel var den största experten här. Tänk på att vi därför är mycket selektiva när det gäller att lägga till nya funktioner på kort sikt. För tillfället – och av samma resonemang – kommer vi inte heller att utveckla den 2.x gren (för närvarande släppt som en alfaversion av biblioteket.

EthereumJS

Vi flyttade EthereumJS VM till en monorepo, kombinera strukturellt relaterade bibliotek (tx, block, blockchain, HF-konfiguration (vanligt)) under ett tak. Detta kommer att underlätta VM-utvecklingen betydligt i framtiden och möjliggöra integrerade PR: er. Det finns en v5 släpps av VM baserat på denna nya strukturella grund som planeras släppas snart vilket kommer att införa flera brytande förändringar. Känn dig gärna in och gå med (och forma) diskussionen.

Tack vare det fantastiska arbetet med dryajov vi har nu också fungerat TypeScript genomförande av devp2p stack. En utgåva om detta är överhängande.

Rutnät

Ethereum Grid delades upp i två delar: skrivbordsapplikationen och en kärnmodul som kan tillhandahålla binär hantering utanför Electrons sammanhang, t.ex. på CLI eller i andra verktyg som testlöpare eller IDE: er (Remix, VSCode). Målet med kärnan är att tillhandahålla en motor som i sig är mycket liten men kan utökas via plugins. De nödvändiga mekanismerna som möjliggör en säker och stabil förlängning utan att behöva ändra Grid i framtiden har implementerats. Detta var huvudmålet för refactoring och en övergång till en slutlig produkt.

Rutnätet kan utökas med små skript, så kallade arbetsflöden, som interagerar med binärer. En mängd av dem har skapats och demoterats på EthCC: Grid Workflows

Python ekosystem [PyEVM / Trinity / Web3.py / Vyper]


Författad av Piper Merriam

Web3.py

Web3.py-biblioteket har fortsatt arbetet med stegvisa förbättringar och stabilitet. Tack vare några bidrag från tredje part, förväntar vi oss att få ett preliminärt stöd för mnemonic fras och HD-konton som släpps inom en snar framtid. Vi fortsätter också att arbeta för fullt async-stöd, även om det fortfarande finns ett anständigt grundläggande arbete som måste göras på denna front.

Trinity

Trinity-klienten fortsätter arbetet på både 1.x- och 2.0-fronterna. Arbetet fortsätter med Trinity Eth2-klienten när vi närmar oss att ha stabila, längre levande offentliga testnät. På Eth1.x-sidan fortsätter vi att arbeta mot en funktionell mainnet-klient. En av de största sakerna som har kommit ut ur vårt arbete under de senaste två åren är “Stateless Ethereum” -insatsen som utformas för att omvandla Ethereum-mainnet under de kommande 18-24 månaderna.

EthPM

EthPM-teamet samarbetar med Solidity-teamet för att integrera förpackningsstandarden så att kompilatorn kan kompilera resurserna i ett paket, producera paket med de sammanställda resurserna och använda EthPM-specifikationerna för verifiering av metadata / kontrakt.

Remix

Känn dig fri att kolla in våra medelstora inlägg för mer detaljerat innehåll.
Vår offentlig webbplats har precis släppts;)

Remix IDE – Live && Desktop-app

  • Fullt stöd för Solidity 0.6.0 brytande förändringar och funktioner har lagts till i Solidity Plugin.
  • Interaktion på låg nivå är nu möjlig (Soliditetsmottagning och fallback)
  • Light och Dark teman har lagts till. Vi redesignade användargränssnitt för Solidity Plugin och distribuera & kör plugin.
  • Det senaste Remix Plugin Engine(v0.2.0) har integrerats med framgång i Remix IDE, såväl som remix-simulator (Ethereum dev-nod i webbläsaren).
  • Från och med nu, skrivbordsversionen följer Remix live release.

Remix plugin

  • Den senaste versionen kommer med möjligheten att ha websocket plugins och vi kommer att lägga till fler typer (Secure Ecmascript, IPC) snart.
  • Integration med VScode är för närvarande i processen och förhoppningsvis tillgänglig snart.
  • här är dokumentationen för att utveckla plugins.

Externa plugins

  • Vi stöder externa team för att bygga sina plugins och lägga till dem till Remix IDE.
  • Vi har en Gitter-kanal tillägnad Remix-plugins. Du kan föreslå ett plugin till gemenskapen genom att skapa en PR i remix-plugins-katalogförvaret
  • Om du behöver ekonomisk hjälp för att bygga din plugin kan vi förmodligen göra något!
    Här är vad du behöver göra:

    • Skapa ett Github-problem (i förvaret där din plugin finns) för att beskriva vad du tänker göra.
    • Skicka ett mail till oss – remix@ethereum.org – med ett dokument som beskriver projektet, en länk till Github-frågan och ett fakturaförslag.
    • Vi kommer att göra vårt bästa för att kontakta dig och planera för nästa steg.

Remix Simulator

  • Integrationen med Remix IDE är mestadels slutförd.

Statisk analysator för remix

  • Remix Analyzer flyttades till typskript och använder nu det senaste AST (Abstract syntax tree).

Remixtester

  • Vi publicerade nya funktioner nyligen och räckte till Remix-communityn för feedback och fick ett bra resultat. Här är medelstora inlägg: del 1del 2.

Blogginlägg & någonsamhällen

Vi har börjat driva lite nytt innehåll, vilket kommer att vara vårt fokus under de kommande månaderna.
Vi satsar också på workshopens innehåll, inser och främjar det.

E2E-testning

David aka @ioedeveloper gick nyligen till teamet och arbetar med E2E-testning och Remix IDE, med målet att konsolidera vår frisläppningsprocess.

Forskning [Eth1.X (Stateless Ethereum)]


Författad av Griffin Hotchkiss

Uppsättningen av uppgraderingar till det befintliga Ethereum-protokollet kallad ”Eth1.X” har sammanförts till en mer enhetlig ansträngning av forskare att implementera och övergå till ”Stateless Ethereum”. Uppgraderingarna och undersökningsämnen är inte bara relevanta för att förbättra skalbarheten och motståndskraften i den nuvarande kedjan, utan är också relevanta och på många sätt komplementära till tekniska och designutmaningar som hanteras av Eth2-forskargrupper.

Efter EthCC i Paris fanns ett statslöst toppmöte om Ethereum-forskning, som av deltagarna betraktades som spetsfullt och mycket framgångsrikt av alla berättelser.

Uppdateringar om det statlösa Ethereum-initiativet har kroniserats av Griffin Ichiba Hotchkiss i en pågående serie med namnet “The 1.X Files”, som förutom att sammanfatta och smälta månadssamtal dykar djupt in i de grundläggande begreppen som undersöks och vägen framåt.

Forskning [Serenity / Eth2]


Författad av EF Team

Danny Ryan, Carl Beekhuizen och forskargruppen Eth2 har fortsatt regelbundna serier som ‘Eth2 Quick Update’ och ‘Validated: Staking on Eth2’ här på EF-bloggen. För de senaste nyheterna och framstegen när vi närmar oss lanseringen av fas 0, kolla in de senaste inläggen nedan!

Eth2 snabbuppdatering

Validerad, satsar på eth2

säkerhet [Security / Consensus Tests]


Författad av Martin Holst Swende

Ethereum Mainnets hälsa är högsta prioritet, och vi har undersökt och publicerat ett EIP-förslag påföljder för statliga tris missar.

Mot slutet av 2019 betalade vi ut flera belopp. ChainSecurity tjänade ytterligare 8500 poäng, för tre separata rapporter: 1000 poäng för en långsam körning på Geth, på grund av en onödig kopiering av data när CALL-varianter gjordes med stora calldata; 5000 poäng ur “potten” med pengar som avsatts för EIP-granskningar, med deras hjälp för att bedöma säkerheten för EIP-1884 (som också tjänade Neville Gretch (contract-library.com) 5000 poäng). Och lämnade in en DoS-vektor för Geth / Parity, tillsammans med Daniel Perez (delad 50/50), som fick dem 2500 poäng vardera.
I början av 2020 tilldelades den produktiva bughunteren Sam Sun ytterligare 10 000 bonuspoäng för ENS sårbarhet som krävde migrering av alla poster till en ny registrator.

De Go-Evmlab förvaret har uppdaterats för att bättre integreras med Geth och hjälpa till vid analys av kedjedrift, samt skapa anpassade evm-fuzzers.

Vi har också gjort två externa revisioner vid det kommande Upptäckt version 5 protokoll. En utfördes av Least Authority och en annan av Cure53. De är båda tillgängliga här. Protokollet implementeras (men inte aktiverat) i Geth redan – se nedan.

Konsensustester:

Blockchain-testgenereringskoden omarbetades och migrerades till omprövning.
VMTests genereras nu i Blockchain-testformat.
Statistikwebserver inställd på http://retesteth.ethdevops.io/

Fasthet


Författad av Franziska Heintel, Daniel Kirchner och Christian Reitwiessner

Sedan den senaste uppdateringen har Solidity-teamet släppt version 0.6.0. Apart from the abundance of features already announced in our previous post, this also includes “try/catch” as high-level syntax to handle failure conditions for external calls. In the meantime, the 0.6 series has stabilized in multiple minor releases and early planning for the next major release 0.7 has started (a future blog post will announce the features to be expected).

A notable new language feature within the 0.6 series is support for immutable variables. Starting from version 0.6.5 of Solidity state variables can be declared “immutable”. Immutable variables can be assigned once during contract creation and be cheaply read from runtime code. The constructor code will directly insert the values specified for the immutables during construction into the runtime code, so that the runtime cost of an access is merely that of a single PUSH.

Other language features that recently emerged are interface inheritance (which will be supplemented by ERC165 interface IDs in the near future), optional reason strings for internal reverts and the ability to assign storage pointers via inline assembly. The latter enables constructs useful for writing updateable contracts.
Furthermore we introduced syntax for CREATE2 via new C{salt: }() and are simultaneously migrating the syntax for setting gas and value for regular function calls to an analogous syntax: c.f{value: 10 ether}().

The main focus of the Solidity team is on extending the new code generation via Yul as intermediate representation. A variety of language constructs is now supported: recent notable additions include external function calls, try/catch, increased array support, tuples and more.
On the backend side the translation of Yul code to Ewasm is now complete pending some tweaks with regards to types, meaning that finalizing code generation via Yul IR will yield a Solidity to Ewasm compiler.

The Yul optimizer continues to be improved; most notably we are introducing the Yul Phaser. The phaser is a tool that employs a genetic algorithm to find the best sequence of optimizer steps – in the future it could also be possible to use it on individual contracts if you want to spend more time compiling and get a cheaper contract.

Further improvements:
solc-js is now built to WebAssembly instead of asm.js, which should make compilation much faster and increase browser compatibility.
The JSON AST export is now complemented by an AST import that can be used e.g. for mutation testing and other experiments.
There is continued effort towards source verification (at https://github.com/ethereum/source-verify), the effort to build a collection of authenticated ABI and source codes of deployed smart contracts through the metadata hashes in the bytecode and to provide a trustless way to retrieve authoritative ABI information from ipfs or other sources.
The Solidity grammar is now defined via antlr and the antlr-based grammar will be kept up-to-date by the team.

SMT Checker

The SMTChecker module continues to increase its support to Solidity, as well as improving its verification techniques. The new CHC engine now also supports internal function calls and multi-transaction counterexamples (unreleased), showing exactly how each transaction must be called in order to break an assertion. We are currently working on support to external functions and as usual, supporting more features of the Solidity language.

Solidity Summit!

Finally, we are looking forward to the Solidity Summit, which will take place online on April 29-30. The Solidity Summit is an interactive forum with discussions and short talks about Solidity, Yul, language design and tooling. We aim to have useful discussions that result in improvement proposals and pave the way for actual implementations. Furthermore, we want to foster communication between teams working on similar topics and identify needs for the smart contract ecosystem for Ethereum. For information about registration, agenda and the livestream please visit the Solidity Summit website.

Follow us online

For regular updates, you can follow the Solidity team on Twitter or check out more Solidity-related content like feature deep dives, release announcements and bug reports on the recently launched Solidity blog!

ZoKrates


Authored by Jacob Eberhardt

Since the last update, the ZoKrates team designed and released the first version of zokrates.js, a library to compile, execute and prove ZoKrates programs from JavaScript. It uses WASM under the hood and is already being used to power our Remix plugin!

As part of this effort – and to better support programmatic interaction with ZoKrates – a new version of the ZoKrates ABI was developed. It is now capable of exposing complex data types in the same style Solidity does through ABI specifications.

To increase efficiency, we added further optimization techniques to the ZoKrates compiler: memoization of function calls, detection of unconstrained variables, and more. These optimizations are under review and subject to testing and we hope to bring them to you in the next release.

Native verification – a feature commonly requested by our users – is implemented as a prototype and currently undergoing testing.

Finally, the introduction of unsigned integers in ZoKrates which benefit from automatic optimizations is progressing. This is particularly useful when using widespread hash functions such as SHA256 and implementing algorithms that inherently use binary representations.

🦄



LEAVE A REPLY

Please enter your comment!
Please enter your name here