De tragische combinatie van onvermijdelijke bugs en onveranderlijke code

Vorige week was er sprake van een catastrofale gebeurtenis in het Ethereum-ecosysteem, wanneer De DAO, een slim contract van minder dan twee maanden oud, begon snel geld te lekken naar een onbekende partij. Kijken naar de huidige set van Ethereum-contracten, gevuld met casino's en zelfverklaarde Ponzi-schema's, lijkt dit misschien geen probleem. Dat wil zeggen, totdat je hoort dat meer dan 12 miljoen ethereenheden, de Ethereum-cryptocurrency, door bijna 20,000 mensen in The DAO zijn geïnvesteerd. Dat is ongeveer 15% van alle ether die er bestaat, met een waarde van meer dan $ 250 miljoen op 17 juni.

Twee dagen later zakten de activa van de DAO onder de $ 100 miljoen. Twee dingen hebben bijgedragen aan deze steile val. Ten eerste was een derde van zijn fondsen (uitgedrukt in ether) al ingenomen. En ten tweede zorgde de resulterende paniek ervoor dat de marktprijs van ether ineenstortte van de piek van meer dan $ 21 naar een meer ontnuchterende $ 10.67. (Op het moment van publicatie was de prijs hersteld tot ongeveer $ 14.) Dit tweede effect was een natuurlijk gevolg van het eerste, aangezien een groot deel van de recente waardestijging van ether werd veroorzaakt door mensen die het kochten om in The DAO te investeren.

De DAO had beloofd op te treden als een nieuw type gedecentraliseerd crowdsourcing-voertuig, zoals Kickstarter of Indiegogo, maar zonder tussenpersoon en regelgeving. Het is ontworpen om deelnemers hun cryptocurrency te laten bundelen, gezamenlijk te laten stemmen op projecten die op zoek zijn naar financiering, vervolgens te investeren en de toekomstige beloningen te oogsten. Voordat de catastrofe toesloeg, meer dan 100 projecten was al voorgesteld, waarvan de meeste gerelateerd waren aan Ethereum zelf. Bovendien stond de DAO toe dat deelnemers hun niet-geïnvesteerde geld op elk moment konden opnemen, waardoor ze zichzelf positioneerden als een investering met een laag risico.

Ironisch genoeg deed het individu of de groep die de DAO leeghaalde dit door gebruik te maken van subtiele fouten in dit opnamemechanisme. Zoals alle slimme contracten in Ethereum, is de DAO slechts een stukje computercode, die "onveranderlijk" (dwz permanent en onomkeerbaar) is ingebed in de blockchain en wordt uitgevoerd door elk knooppunt als reactie op inkomende transacties. En zoals elk zichzelf respecterend smart contract, biedt The DAO volledige transparantie door de broncode gemakkelijk online toegankelijk te maken. Dit betekent dat iedereen onafhankelijk de functionaliteit ervan kan verifiëren, maar ook, cruciaal, naar kwetsbaarheden kan zoeken. En toch voorkomt de onveranderlijke aard van blockchains dat dergelijke problemen worden opgelost.

Eind mei, verschillende kritieke problemen werden benadrukt op de uitstaande Hacking verspreid blog, naast een oproep voor een moratorium op projectvoorstellen voor The DAO. Dit is wat we de 'white hat'-benadering zouden kunnen noemen, waarin exploits worden gerapporteerd voor het welzijn van de gemeenschap. Toch leek niemand zich al te veel zorgen te maken, aangezien de problemen eerder verband hielden met scheve economische prikkels dan met het risico van regelrechte diefstal. Tegelijkertijd lijkt het erop dat anderen de code van de DAO met meer eigenbelang bestuderen - namelijk om een ​​manier te zoeken om een ​​hoop geld te verdienen. En op 17 juni is het iemand gelukt.

De DAO aftappen

In algemene zin kwam de aanval voort uit de interactie tussen kwetsbaarheden in de code van de DAO en andere code die was ontworpen om deze te misbruiken. Zie je, afzonderlijk bekeken, bevatte de DAO geen duidelijke fouten en werd het pas vrijgegeven na een uitgebreide beveiligingsaudit. Maar met het voordeel van achteraf en veel meer ogen, is sindsdien een aanzienlijk aantal fouten gevonden.

Ik zal hier geen volledige technische beschrijving geven van het mechanisme van de exploit, aangezien anderen al uitstekende en gedetailleerde post mortems hebben gepubliceerd (zie hier, hier en hier). Maar ik zal een bepaalde kwetsbaarheid uitleggen die aanwezig was, omdat deze is ontdekt in veel andere slimme contracten en dient als een leerzaam voorbeeld.

Laten we zeggen dat een slim contract geld vasthoudt namens een aantal gebruikers en dat die gebruikers hun geld op verzoek kunnen opnemen. De logica voor het proces kan er ongeveer zo uitzien:

1. Wacht tot een gebruiker een opname aanvraagt.
2. Controleer of het saldo van die gebruiker voldoende is.
3. Stuur dan het gevraagde aantal naar het adres van de gebruiker.
4. Controleer of de betaling is gelukt.
5. Dan trekt u de hoeveelheid af van het saldo van de gebruiker.

Dit ziet er allemaal bij uitstek verstandig uit, en eerder als een geldautomaat die u wat contant geld geeft en het juiste bedrag van uw banksaldo aftrekt.

Dus hoe kan dit eenvoudige proces fout gaan? Welnu, het blijkt dat als een Ethereum-adres bij een contract hoort in plaats van bij een gewone gebruiker, dit contract een code kan uitvoeren als reactie op het ontvangen van geld. En deze code kan op zijn beurt andere stukjes code op de Ethereum-blockchain activeren. Cruciaal is dat het zelfs hetzelfde stuk code kan activeren dat ervoor heeft gezorgd dat het in de eerste plaats werd betaald.

Dit betekent dat het ontvangende adres tijdens stap 3 hierboven een nieuw verzoek tot opname kan verzenden en een nieuw proces kan beginnen bij stap 1 voordat het vorige proces is voltooid. Omdat het saldo van de gebruiker pas in stap 5 wordt verlaagd, wordt een nieuwe opname goedgekeurd op basis van het vorige saldo en wordt hetzelfde bedrag opnieuw uitbetaald. Als reactie op deze tweede betaling kan het ontvangende contract een derde en vervolgens een vierde aanvragen, enzovoort, totdat het geld op is of een andere limiet is bereikt. Op dit punt is het saldo van de gebruiker wil ten slotte worden verminderd met het juiste bedrag, waardoor het negatieve gebied wordt betreden dat stap 2 had moeten voorkomen.

Het equivalent zou een geldautomaat zijn die bankbiljetten afgeeft die een gratis herhaalde opname activeren wanneer naar het scherm wordt gezwaaid. De eerste klant die erachter komt, kan de geldautomaat helemaal leegmaken.

Dit vermogen om een ​​stuk code te laten eindigen door zichzelf te bellen, wordt genoemd herhaling, en is een zeer nuttige techniek bij algemene computerprogrammering. In het geval van The DAO maakte het echter de weg vrij voor deze rampzalige prestatie. Als dit echter het enige probleem was geweest, zou het potentieel van de aanval beperkt zijn geweest, omdat Ethereum een ​​limiet toepast op hoe diep recursie kan optreden. Helaas versterkten verschillende andere bugs in The DAO de effecten, wat uiteindelijk leidde tot het verlies van tientallen miljoenen dollars.

Als slechts een paar regels van de DAO-code anders waren geschreven, had dit natuurlijk niet kunnen gebeuren. Bijvoorbeeld, in het 5-stappenproces hierboven, als het saldo van de gebruiker verminderd is vaardigheden het geld wordt verzonden, dan is recursief bellen volkomen veilig. Maar helaas, zelfs als de bedoelingen van de makers puur waren, was de eigenlijke code van de DAO zeer gebrekkig. En computers hebben de vervelende gewoonte om blindelings de instructies op te volgen die ze krijgen, zelfs als een vijfjarige kan zien dat de resultaten niet kloppen. Na onveranderlijk ingebed te zijn in de Ethereum-blockchain, kreeg de defecte DAO het rentmeesterschap over honderden miljoenen dollars van een horde naïeve investeerders, en ging vervolgens spectaculair in vlammen op. De DAO bleek een complete en volslagen puinhoop te zijn en kan nooit worden opgelost.

Het probleem met code

Hoe verleidelijk het ook mag zijn, ik ben hier niet om de programmeurs van de DAO over de technische kolen te slepen. Kijken naar de onderliggende broncode, het lijkt redelijk goed ontworpen, met goede functie- en variabelenamen en duidelijke interne documentatie. Hoewel dit allemaal niet de kwaliteit bewijst, is er vaak een sterke correlatie tussen hoe code eruitziet en hoe goed deze functioneert, om dezelfde reden dat cv's met een slechte interpunctie waarschuwen voor slordige werknemers. In ieder geval twijfel ik er niet aan dat de auteurs van de DAO bekwame ontwikkelaars zijn - inderdaad, het feit dat het een uitgebreide codereview heeft doorstaan, suggereert dat de basislogica goed was.

Dus als het probleem niet de mensen zijn die aan dit project hebben gewerkt, of het werk dat ze hebben geproduceerd, wat is het dan? Het is het feit dat het schrijven van grote stukjes foutvrije code is extreem moeilijk, zo niet onmogelijk. Ik heb in mijn carrière met een aantal echt uitstekende programmeurs gewerkt, het soort dat code tien keer sneller kan maken dan de gemiddelde ontwikkelaar, en met tien keer minder defecten. En toch maken zelfs deze opmerkelijke individuen fouten die tot softwarestoringen leiden. donald knuth, mogelijk de grootste computerprogrammeur aller tijden, deed een beroemde belofte om een exponentieel toenemende financiële beloning aan iedereen die een bug in zijn TeX-zetprogrammatuur heeft gevonden. En hij heeft meer dan een paar cheques verstuurd.

Voor de duidelijkheid, ik heb het niet over dwaze misstapjes met namen als "off-by-one", "uninitialized variable" en "operatorprioriteit". Deze veroorzaken vaak een zichtbare storing de eerste keer dat een programma wordt uitgevoerd, en kunnen gemakkelijk worden opgemerkt door het lokale stuk code waarin ze zich bevinden te bekijken. En dan heb ik het niet eens over beveiligingskwetsbaarheden zoals "niet-gevalideerde invoer", "SQL-injectie" en "bufferoverflows", die misschien niet voorkomen in het normale gebruik van een programma, maar die toch voor ogen zouden moeten staan ​​bij elke ervaren ontwikkelaar.

Ik heb het eerder over lastiger problemen zoals "race conditions" en "deadlocks". Deze komen voort uit conflicten tussen parallelle processen en komen meestal slechts af en toe voor, waardoor ze moeilijk te detecteren en te reproduceren zijn. Als gevolg hiervan kunnen ze alleen worden begrepen door een systeem als geheel te beschouwen en hoe de samenstellende delen op elkaar inwerken. Dit is veel moeilijker dan normaal programmeren, omdat het vereist dat ontwikkelaars verder denken dan het individuele stuk code waaraan ze werken. Het is niet ongebruikelijk dat codeurs meerdere dagen bezig zijn met "debuggen" om een ​​van deze problemen op te lossen. En dit is precies het soort holistisch denken dat nodig was om te voorzien hoe de DAO kwetsbaar zou kunnen zijn.

Met al deze moeilijkheden zou je je terecht kunnen afvragen waarom onze steeds meer codegedreven wereld niet om ons heen instort. Gelukkig werken de meeste software drie cruciale factoren in het voordeel: geleidelijke acceptatie, regelmatige updates en tijd.

Dit is hoe het werkt: er wordt een nieuw softwareproduct gemaakt om in een opkomende marktbehoefte te voorzien. In het begin is de markt klein, dus maar een paar mensen weten dat ze het product nodig hebben. En aangezien het product nieuw is, zal een nog kleiner aantal het ook daadwerkelijk vinden. Deze “early adopters” zijn een dapper en sterk stelletje dat ondanks de bijbehorende risico's graag leeft op het technologische randje. Dus proberen ze het nieuwe product uit, bekijken wat ze leuk vinden, vragen om een ​​heleboel dingen die ontbreken en, het beste van alles, melden eventuele problemen die ze tegenkomen. Elke goede softwareondernemer weet deze mensen te overladen met liefde en hulp, en bedankt hen voor elk stukje feedback dat ze geven. Want hoewel het stom is om te horen over een defect in uw product, is het veel meer waard niet om erover te horen.

Idealiter wordt binnen een maand of minder een nieuwe versie van het product uitgebracht, waarin de gerapporteerde bugs worden verholpen en enkele gevraagde functies worden toegevoegd. De early adopters zijn blij en er stroomt meer feedback binnen, terwijl de nieuwste versie op de proef wordt gesteld, en rond is het weer. Naarmate de markt groeit, neemt het aantal mensen dat het product gebruikt toe. En naarmate het product gestaag verbetert, vertellen steeds meer van deze mensen het aan anderen. Sterker nog, hoe meer mensen het product gebruiken, hoe waarschijnlijker het is dat iemand ergens die precieze en onwaarschijnlijke situatie zal creëren waarin een obscure bug zal verschijnen. Met een beetje geluk laten ze het je weten, en je krabt vol ongeloof op je hoofd, vraagt ​​om meer informatie, vindt uiteindelijk het probleem en lost het op, en slaakt opgelucht adem.

Op enkele uitzonderingen na, is dit hoe de huidige softwareontwikkeling werkt, omdat het de meest efficiënte manier is om uitstekende producten te maken. Natuurlijk zal een goed softwareteam ook een uitgebreide interne testsuite ontwikkelen, om zoveel mogelijk fouten op te vangen voordat ze gebruikers bereiken, en ervoor te zorgen dat nieuwe versies niets kapotmaken dat eerder werkte. Maar toch vertrouwen de meesten van ons ook op onze gebruikersbestanden, omdat we het ons eenvoudigweg niet kunnen veroorloven om elke mogelijke manier waarop onze producten kunnen worden gebruikt, voor te stellen en te testen. En als je denkt dat dit niet van toepassing is op de grote jongens, kun je niet meer verkeerd zijn. Hoeveel "automatische updates" zijn er het afgelopen jaar gedownload naar uw Windows-, Mac- of Linux-systeem? En als u Chrome of Firefox gebruikt, wordt uw webbrowser nu automatisch en geruisloos bijgewerkt, gemiddeld één keer per maand.

Dit iteratieve proces kost veel tijd, waarmee ik een paar jaar of meer bedoel. Maar nadat een product lang genoeg in ontwikkeling is geweest, en het gebruikersbestand groot genoeg is geworden, en die gebruikers het (onbewust) hebben getest in genoeg verschillende situaties, gebeurt er iets magisch. Deze magie wordt "volwassenheid" genoemd, en dat is wat elk softwareproduct moet nastreven. Volwassenheid betekent dat een product echt goed werkt voor vrijwel iedereen die het gebruikt, en er zijn geen snelkoppelingen om daar te komen. Maar als u de juiste timing krijgt, zal uw product volwassen worden rond de tijd dat uw doelmarkt zich verenigt, dwz wanneer grote aantallen klanten daadwerkelijk bereid zijn om ervoor te betalen. En dan, zoals ze zeggen, zult u waarlijk profiteren.

Op onveranderlijke code

Dus hier komen we bij het fundamentele probleem met slimme contracten, zoals zo krachtig is aangetoond door The DAO:

Door hun ontwerp zijn slimme contracten onveranderlijk ingebed in een blockchain en kunnen ze dus niet worden bijgewerkt. Dit voorkomt dat ze volwassen worden.

In eerdere berichten heb ik andere problemen met slimme contracten besproken, zoals hun effect op blockchain-prestaties en het feit dat ze dat zijn minder krachtig dan veel mensen denken. Om deze en andere redenen hebben we (nog) geen slimme contracten geïmplementeerd in de MultiChain blockchain-platform. Maar totdat ik getuige was van het falen van The DAO, had ik niet genoeg nagedacht over een veel fundamentelere kwestie: elk niet-triviaal smart contract bevat waarschijnlijk defecten die niet kunnen worden verholpen.

Voor de moderne softwareontwikkelaar is niet-herstelbare code een regelrechte nachtmerrie, waarbij de lat hoger wordt gelegd dan de meesten kunnen bereiken. Maar we komen dit soort code in sommige situaties wel tegen, zoals het ontwerp van de microprocessors die in het hart van elke computer en smartphone liggen. Deze code is geschreven in talen als Verilog en VHDL, definieert de fysieke lay-out van een siliciumchip, die na vervaardiging niet kan worden gewijzigd. In situaties als deze hebben we de neiging om verschillende kenmerken te zien: (a) de code is geschreven in een taal die ontworpen is met het oog op veiligheid, (b) grote aantallen mensen werken er meerdere jaren aan, (c) het is onderwerp tot uitgebreide geautomatiseerde tests en formele verificatie, en (d) als het eindproduct met een defect wordt verzonden, vallen de kosten van een terugroepactie volledig op de schouders van de verantwoordelijke partij (zie bijvoorbeeld de beruchte Pentium-bug).

Het behoeft geen betoog dat dit allemaal niet van toepassing is op de makers van The DAO, of zelfs op enig ander slim contract. Maar de onveranderlijkheid van code is niet de enige uitdaging voor slimme contractontwikkelaars. Een aantal andere factoren zorgen ervoor dat Ethereum aanzienlijk gevaarlijker is dan de meeste computeromgevingen:

• Zoals eerder besproken, onthullen de meeste contracten hun broncode om het vertrouwen van potentiële gebruikers te winnen. Hierdoor zijn bugs gemakkelijk te vinden en te exploiteren. Hoewel gewone code kan worden opgelost wanneer er een probleem wordt gevonden, kunnen alleen aanvallers profiteren van onveranderlijke code.
• Zoals in de meeste programmeertalen, kan een "functie" (stuk code) op de blockchain een andere "oproepen" (triggeren) om trapsgewijze effecten te creëren. Ethereum is echter ongebruikelijk in het mogelijk maken van directe functieaanroepen tussen de code die is geschreven door partijen die elkaar niet kennen en wiens belangen kunnen botsen. Dit is een perfect recept voor vijandig en onverwacht gedrag.
• Zoals eerder vermeld, als het ene Ethereum-contract geld naar het andere stuurt, heeft laatstgenoemde de mogelijkheid om als reactie een code uit te voeren. Deze code kan met opzet zijn ontworpen om ervoor te zorgen dat de verzendoperatie mislukt, mogelijk triggers allerlei verdere ravage.
• Wanneer de ene functie een andere aanroept, en deze tweede functie een derde, wordt een "stapel" aanroepen en suboproepen gecreëerd. Het bijhouden van deze stack brengt rekenkosten met zich mee, dus Ethereum bevat een "call stack-limiet" die beperkt hoe diep het kan gaan. Dit is eerlijk genoeg. Maar als de limiet wordt bereikt door een bepaalde functieaanroep, de Ethereum-omgeving zwijgend slaat die oproep over, in plaats van de hele transactie veilig te beëindigen en de effecten ervan af te wikkelen. Met andere woorden, wat code in een slim contract misschien niet worden uitgevoerd, en deze niet-uitvoering kan opzettelijk worden veroorzaakt door het activeren van dat contract vanuit een voldoende diepe stapel. Dit lijkt me echt een afschuwelijke ontwerpkeuze, waarmee het mentale model wordt doorbroken waaraan elke softwareontwikkelaar gewend is. Degene die deze beslissing heeft genomen waarschijnlijk moet worden over de kolen gesleept, hoewel er gelukkig nu een suggestie om het te veranderen.
• Ethereum heeft ook een 'gaslimiet', die misbruik in openbare blockchains voorkomt door transacties te laten betalen voor de rekenkracht die ze verbruiken. De afzender van een transactie beslist hoeveel gas hij wil uitgeven, en als dit op is voordat de transactie is voltooid, wordt het veilig afgebroken. Hoewel dit waarschijnlijk de beste oplossing is voor een moeilijk probleem, kan het onaangename gevolgen hebben. Sommige contracten blijken meer gas nodig te hebben dan verwacht, terwijl andere kan helemaal niet worden uitgevoerd.
• De cryptocurrency van het openbare Ethereum-netwerk maakt het mogelijk dat defecten in slimme contracten echt geld naar de verkeerde plaats sturen, zonder gemakkelijke herstelmethode. Terwijl Ethereum-mijnwerkers lijken te zijn stemmen voor van een "zachte vork" om het geld te bevriezen dat uit de DAO wordt afgevoerd, is dit geen duurzame oplossing.

Samenvattend, in vergelijking met reguliere gecentraliseerde computersystemen, is Ethereum een ​​veel lastiger omgeving om veilig te coderen. En toch dient het principe van onveranderlijkheid om te voorkomen dat software met fouten wordt bijgewerkt. Met andere woorden, slimme contracten zijn software waarvan de bugs zichtbaar zijn, niet kunnen worden verholpen en rechtstreeks het geld van echte mensen beheren. Dit is nogal duidelijk een zeer giftige mix.

Voorstanders van slimme contracten in Ethereum-stijl in privaat blockchains zouden in de verleiding kunnen komen om de ondergang van The DAO te vieren, maar ik denk niet dat dit antwoord de moeite waard is. Met uitzondering van de laatste twee punten hierboven, zijn alle problemen met Ethereum in gelijke mate van toepassing op toegestane blockchains, die nog steeds afhankelijk zijn van onveranderlijke slimme contracten - hoewel in dit geval de onveranderlijkheid wordt gegarandeerd door een groep geïdentificeerde partijen in plaats van anonieme mijnwerkers. Als je wilt beweren dat privé-blockchains ervoor zorgen dat slimme contracten met bugs gemakkelijker kunnen worden teruggespoeld, vervangen of genegeerd, dan zeg je eigenlijk dat slimme contracten helemaal geen doel hebben in deze blockchains. Simpel gezegd, als iets niet onveranderlijk bedoeld is, mag het niet in een blockchain worden opgeslagen. Houd in plaats daarvan vast aan ouderwetse juridische documenten en gecentraliseerde applicatielogica, en gebruik de ketting voor: (a) het onveranderlijk opslaan van de gegevens waarvan die logica afhangt, en (b) het uiteindelijke consensuele resultaat vertegenwoordigen van de toepassing ervan. (Dit ontwerppatroon is genoemd Eenvoudige contracten door anderen.)

Desalniettemin zijn de risico's in het openbare Ethereum-netwerk ongetwijfeld erger, omdat slecht geschreven slimme contracten snel en onomkeerbaar grote hoeveelheden echte waarde (in de vorm van cryptocurrency) kunnen verzenden naar gebruikers van wie de identiteit onbekend is. Er is inderdaad een betere manier voor een kwaadaardig genie om te doden dan: (a) het schrijven van een slim contract dat er gezonder uitzien juist en eerlijk, (b) het gedurende meerdere jaren veilig en consistent laten werken, (c) wachten tot het een grote som geld van investeerders verzamelt, en dan (d) een of andere duistere kwetsbaarheid opwekken om die fondsen over te hevelen. Hoewel ik niet suggereer dat het falen van de DAO opzettelijk was, zal het anderen zeker inspireren om soortgelijke "fouten" te maken.

Als ik de factoren die ten grondslag liggen aan het ontwerp van Ethereum zou moeten samenvatten, zou ik de uitdrukking "onervaren genie" kunnen gebruiken. Geniaal, omdat ik geloof dat het een echt briljante uitvinding is, die twee belangrijke innovaties toevoegt aan de cryptocurrency-systemen die eerder kwamen: (a) de Ethereum Virtual Machine die slimme contracten uitvoert en zijn methode om kosten toe te wijzen aan berekeningen, en (b) het gebruik van Patricia bomen om compacte bewijzen van elk aspect van de staat van een blockchain mogelijk te maken. En toch, ook onervaren, omdat sommige ontwerpkeuzes van Ethereum zo overduidelijk vreselijk zijn, zoals de stille maar gewelddadige call-stack-limiet, of het vermogen van een betalingsontvanger om de code die het heeft betaald recursief te activeren.

Dit zou geen probleem zijn als Ethereum zou worden behandeld als een experiment dat het waard is om te worden onderzocht, maar met kritieke problemen die nog moeten worden opgelost. Misschien wel het equivalent van bitcoin tijdens de eerste paar jaar, toen de totale marktkapitalisatie niet verder ging dan een paar miljoen dollar. Helaas heeft Ethereum, als gevolg van speculatie en opgeblazen verwachtingen, niet dezelfde kans gekregen om zijn spreekwoordelijke voeten te vinden. In plaats daarvan heeft het op minder dan een jaar oud een marktwaarde van een miljard dollar. Ethereum is als een peuter die gedwongen wordt om te koken, of een eerstejaars economie die de Federal Reserve voorzit. Ik denk dat het tijd is om te erkennen dat het onvolwassenheidsprobleem van individuele slimme contracten ook van toepassing is op Ethereum als geheel.

Ethereum's weg vooruit

Hoewel ik nog geen sterke use-cases zie voor slimme contracten in privé- of toegestane blockchains, denk ik dat ze waarschijnlijk wel een plaats hebben in openbare ketens met bijbehorende cryptocurrencies. Tenminste, als je het uitgangspunt accepteert van censuurvrije financiële systemen, die de financieel uitgesloten en ransomware-auteurs in gelijke mate helpen. Afgezien van dit debat, is er zeker technisch verdienste in een cryptocurrency die willekeurige logica ondersteunt, van het soort dat niet kan worden geïmplementeerd op "eerste generatie" blockchains zoals bitcoin. Ethereum is voorlopig de eerste en enige overtuigende poging om een ​​dergelijk systeem te bouwen, met een hoop geld en momentum erachter.

Desalniettemin lijkt Ethereum als ontwikkelaarsecosysteem fundamenteel gebroken te zijn. Hoewel de DAO de duurste en meest opvallende mislukking is, zijn veel andere contracten dat wel lijdt aan soortgelijke problemen. Dus hoe kan Ethereum zijn act opruimen?

• Stuur een duidelijke boodschap dat, in ieder geval voor de komende twee jaar, niemand geld naar een smart contract mag sturen, tenzij ze het graag willen verliezen in naam van zelfstudie.
• Los een aantal opvallende problemen op met de Ethereum Virtual Machine ("EVM"), namelijk: (a) het verwijderen van de call stack-limiet, (b) het bieden van een manier om ether te verzenden zonder code te activeren, en (c) het toestaan ​​van contracten om te worden gemarkeerd als " non-reentrant ”, wat betekent dat hun functies niet kunnen worden aangeroepen terwijl ze al midden in iets zitten.
• Ontwikkel een nieuwe programmeertaal voor slimme contracten, die een meer beperkende methode gebruikt voor het uitdrukken van berekeningen die vatbaar zijn voor formele bewijzen van juistheid. Er zijn al tientallen jaren onderzoek in dit veld geïnvesteerd, dus er is veel bestaand werk dat kan worden gebruikt. (Dit vereist geen wijzigingen aan de EVM zelf, aangezien de gekozen taal nog steeds kan worden gecompileerd in gewone "bytecode".)
• Bouw een officiële set veilige slimme contracten en functies op, die tot de dood door vakgenoten zijn beoordeeld en die zichzelf in veel verschillende situaties betrouwbaar hebben bewezen. Dit is verwant aan de standaard bibliotheken die beschikbaar zijn voor veel volwassen programmeertalen. (Hoewel het op dit moment verleidelijk is om te vragen: waarom niet gewoon de functionaliteit van deze bibliotheken hard coderen in de EVM, en daardoor veel betere prestaties behalen? Antwoord: Omdat Ethereum specifiek is ontworpen om af te stappen van blockchains met hard-coded functiesets. Maar toch, je vraagt ​​je af.)

De huidige optie, om handmatig in te grijpen als reactie op het falen van specifieke slimme contracten, zal niet op grotere schaal levensvatbaar zijn als Ethereum zijn identiteit als een betrouwbaar en gedecentraliseerd computerplatform wil behouden. Sommigen maken zelfs een aannemelijk argument dat deze enkele op oordelen gebaseerde bestuursdaad al heeft plaatsgevonden vernietigde de reputatie van Ethereum. En we moeten opmerken dat The DAO's algemene voorwaarden expliciet vermelden dat niets "enige aanvullende verplichtingen of garanties mag wijzigen of toevoegen die verder gaan dan die vermeld in de code van de DAO". Met andere woorden, degene die de DAO leegzette, handelde in overeenstemming met de gepubliceerde voorwaarden en staat daarom vermoedelijk aan de rechterkant van de wet.

We moeten ook de mogelijkheid accepteren dat Ethereum, na nog een aantal jaren van goed werk, nog steeds te moeilijk kan blijken te zijn voor ontwikkelaars om veilig mee te werken. In dat geval zal het wegkwijnen als een matchmaking-service tussen anonieme oplichters en hun dwaze tekens. Maar dat zou niet betekenen dat het tijdverspilling was - Ethereum is op zijn minst een fascinerend experiment, waarvan de blockchain-gemeenschap veel zal leren.

In de tussentijd kan ik voor gebruikers van privé-blockchains alleen herhalen wat ik eerder heb gezegd:

Als uw applicatie geen slimme contracten vereist, gebruik dan een eenvoudigere blockchain-architectuur.

Waar dit advies voorheen gerechtvaardigd was in termen van prestaties, wordt het nu versterkt door de kennelijke moeilijkheid om slimme contracten goed te krijgen. En als u niet zeker weet of uw use-case slimme contracten vereist, aarzel dan niet e-mail ons met enkele details, en we laten het je graag weten.

Plaats eventuele opmerkingen op LinkedIn.

Bron: https://www.multichain.com/blog/2016/06/smart-contracts-the-dao-implosion/