blog 1NieuwsOntwikkelaarsEnterpriseBlockchain ExplainedEvenementen en conferentiesPersNieuwsbrieven

Abonneer op onze nieuwsbrief.

E-mailadres

Wij respecteren uw privacy

HomeBlogBlockchain-ontwikkeling

Formeel verifiëren van de Ethereum 2.0 Phase 0-specificaties

Een update van ConsenSys R&D over hun inspanningen om de Beacon Chain en de kernfundamenten van Eth2 betrouwbaar te maken. door Franck Cassez10 augustus 2020Geplaatst op 10 augustus 2020

dafny verifieer blogheld

Het geautomatiseerde verificatieteam op ConsenSys R&D heeft een aantal maanden gewerkt aan een formele specificatie en verificatie van de Beacon Chain. We zijn blij te kunnen melden dat er veel vooruitgang is geboekt en hoewel het nog niet compleet is, zijn we erin geslaagd om ons te ontwikkelen een solide en formeel geverifieerde kern van de Beacon Chain. Voor het eerst biedt ons werk een ongeëvenaard niveau van betrouwbaarheid voor de kernfundamenten van de Eth2.0-infrastructuur.

Methodologie

Verificatie versus testen

We gebruikten de bekroond verificatiebewuste programmeertaal Dafny om een formeel (functioneel en logisch) specificatie van elke Beacon Chain-functie, een implementatie van elke functie, en een bewijs dat de implementatie overeenkomt met de specificatie. Met andere woorden, we hebben de afwezigheid van bugs wiskundig geverifieerd. De implementaties waarvan we uiteindelijk hebben bewezen dat ze correct zijn, zijn gebaseerd op de officiële Eth2.0-specificaties met het voorbehoud dat we enkele bugs en inconsistenties hebben opgelost en gerapporteerd.

Onze methodologie is net als wij anders dan testen wiskundig bewijzen conformiteit van de functies met hun specificaties, voor alle ingangen. Testen kan niet oneindig veel invoer omvatten, en als gevolg daarvan kunnen bugs worden ontdekt, maar niet de afwezigheid van bugs bewijzen.

En het beste is dat we geen paper hoeven te publiceren, noch de bewijzen hoeven te herzien. De bewijzen maken deel uit van de codebasis en zijn geschreven als programma’s. Ja, in Dafny kun je een proef schrijven als een ontwikkelaarsvriendelijk programma. Ook de bewijzen worden mechanisch gecontroleerd door een stellingbewijzer, waardoor er geen ruimte is voor onvolledige of gebrekkige bewijzen.

Eigenschappen die we hebben bewezen 

De eigenschappen variëren van het ontbreken van rekenkundige onder / overlopen en index buiten de grenzen, de conformiteit van elke functie met logische (eerste-orde logica) pre / post-voorwaarden (merkelise voorbeeld hier), tot meer complexe die betrekking hebben op de composities van functies. We hebben bijvoorbeeld het volgende eigendom van de SSZ Serialiseren / deserialiseren functies: voor elk object x, Deserialiseren (Serialise (x)) = x, d.w.z. deserialiseren van een geserialiseerd object retourneert het oorspronkelijke object. We hebben ook een aantal invarianten, en gebruikte ze om te bewijzen dat de kernactiviteiten van de Beacon Chain en ForkChoice (state_transition, on_block) werkelijk bouw een ketting van blokken: voor elk blok b in de winkel vormen de voorouders van b een eindige totaal geordende reeks die leidt naar het genesisblok, dat de belangrijkste eigenschap is van een blockchain!

De voordelen van formele verificatie

Elke formele methodist zou erop staan ​​dat verificatie een best practice is op het gebied van beveiliging. Dit is precies hoe deze methodologie zorgt voor een veilige en betrouwbare infrastructuur voor Ethereum 2.0.


Functionele specificatie

Ten eerste hebben we de officiële Eth2.0-specificaties opgetild naar een formele logische en functionele specificatie. Voor elke functie definiëren we formeel wat de functie naar verwachting zal berekenen, niet hoe. Dit zorgt voor taalonafhankelijke ontwikkelaarsvriendelijke referentiespecificaties die kunnen worden gebruikt om veiligere implementaties te ontwikkelen, met minder moeite. 

Modulariteit

Ten tweede zijn onze specificaties, implementaties en proof-architectuur modulair. Daardoor kunnen we gemakkelijk experimenteer met nieuwe implementaties (bijv. optimalisaties) en controleer hun impact op het algehele systeem. Denk aan een slimme hack om een ​​functie te implementeren? Wijzig de implementatie en vraag Dafny om te controleren of deze nog steeds aan de specificatie voldoet. Als dit het geval is, heeft dit geen invloed op de bewijzen van de componenten die deze functie gebruiken.

Uitvoerbaarheid

Ten derde zijn onze implementaties uitvoerbaar. We kunnen een Dafny-programma compileren en uitvoeren. Beter nog, u kunt automatisch code genereren in een aantal populaire programmeertalen zoals C #, Go (en binnenkort Java) vanuit de Dafny-code. Dit kan worden gebruikt om bestaande codebases aan te vullen of om te genereren gecertificeerde tests. De te testen implementatie kan onze bewezen-correct-functies gebruiken om het verwachte resultaat van een test te berekenen en te vergelijken met zijn eigen resultaat.   

Alles in één taal

Last but not least is onze codebasis op zichzelf staand. Het bevat de specificaties, implementaties, documentatie en bewijzen, allemaal in een enkele, leesbare, eenvoudige en semantisch goed gedefinieerde programmeertaal.

Vragen en overwegingen 

Hoe zit het met de degelijkheid van de verificatie-engine?

Je vraagt ​​je misschien af: “wat als de Dafny-compiler / verificator fouten bevat?” We weten eigenlijk dat Dafny een buggy is (dafny repo-problemen), maar we vertrouwen niet op de afwezigheid van bugs in Dafny. We vertrouwen op Dafny (en zijn verificatie-engine) geluid. Deugdelijkheid betekent dat wanneer Dafny meldt dat bewijzen correct zijn, ze inderdaad correct zijn. 

Wat als de specificatie die we hebben geschreven niet de juiste is?? 

In dit geval zouden we conformiteit met een verkeerde vereiste aantonen. Ja, dit kan gebeuren en er is geen wondermiddel om dit probleem op te lossen. Zoals we eerder vermeldden, is Dafny echter uitvoerbaar. Dit stelt ons in staat om de code uit te voeren en er zeker van te zijn dat onze specificaties de juiste zijn. En onze specificaties zijn geschreven in eerste orde logica zonder enige ruimte voor betwisting over de betekenis, dus als u een probleem opmerkt, laat het ons weten en wij zullen het oplossen.

Wat als Dafny niet kan bewijzen dat een implementatie aan een specificatie voldoet?? 

Dit kan gebeuren, maar in dit geval heeft Dafny een aantal feedbackmechanismen om te helpen onderzoeken welke stappen van een bewijs niet kunnen worden geverifieerd. En tot nu toe zijn we er altijd in geslaagd om bewijzen te bouwen die Dafny automatisch kan controleren.

We stellen uw feedback op prijs, dus kijk alsjeblieft onze eth2.0-dafny repository. We zijn verheugd om te zien hoe de ontwikkeling van Ethereum 2.0 zijn recente mijlpalen in het testnet bereikt, en we kijken ernaar uit om met teams in het hele ecosysteem samen te werken om ervoor te zorgen dat de volgende fase van het netwerk op een rotsvaste basis wordt gebouwd..

Erkenning: met dank aan mijn teamgenoten Joanne Fuller, Roberto Saltini (geautomatiseerd verificatieteam), Nicolas Liochon en aan Avery Erwin voor opmerkingen over een voorlopige versie van dit bericht.

Blijf op de hoogte van Ethereum 2.0

Abonneer u op de ConsenSys-nieuwsbrief om het laatste Eth2-nieuws rechtstreeks in uw inbox te ontvangen. Ethereum 2.0 Onderzoek en ontwikkeling Beveiliging Nieuwsbrief Abonneer u op onze nieuwsbrief voor het laatste Ethereum-nieuws, bedrijfsoplossingen, bronnen voor ontwikkelaars en meer.Hoe u een succesvol blockchain-product bouwtWebinar

Hoe u een succesvol blockchain-product bouwt

Hoe u een Ethereum-knooppunt instelt en uitvoertWebinar

Hoe u een Ethereum-knooppunt instelt en uitvoert

Hoe u uw eigen Ethereum-API kunt bouwenWebinar

Hoe u uw eigen Ethereum-API kunt bouwen

Hoe u een sociaal token maaktWebinar

Hoe u een sociaal token maakt

Beveiligingshulpmiddelen gebruiken bij slimme contractontwikkelingWebinar

Beveiligingshulpmiddelen gebruiken bij slimme contractontwikkeling

De toekomst van digitale activa en defiWebinar

De toekomst van financiën: digitale activa en deFi

Mike Owergreen Administrator
Sorry! The Author has not filled his profile.
follow me