Smarta kontrakt och DAO-implosionen

Återutgiven av Platon

anhängare: 0

Den tragiska kombinationen av oundvikliga buggar och oföränderlig kod

Förra veckan bevittnades en katastrofal händelse i Ethereum-ekosystemet, när DAO, ett smart kontrakt mindre än två månader gammalt, började snabbt läcka medel till en okänd part. Titta på nuvarande uppsättning av Ethereum-kontrakt, fyllda med kasinon och självdeklarerade Ponzi-system, verkar detta kanske inte som en stor sak. Det vill säga tills du lär dig att över 12 miljoner enheter eter, Ethereum cryptocurrency, hade investerats i DAO av nästan 20,000 15 människor. Det är cirka 250% av all eter som finns, värderad till över 17 miljoner dollar den XNUMX juni.

Två dagar senare doppade DAO: s tillgångar under 100 miljoner dollar. Två saker bidrog till detta brant fall. Först hade en tredjedel av dess medel (som denominerad i eter) redan tagits. Och för det andra skickade den resulterande paniken marknadspriset på eter som kraschar ned från sin topp på över $ 21 till en mer nykterande $ 10.67. (Vid tidpunkten för publiceringen hade priset återhämtat sig till cirka $ 14.) Denna andra effekt var en naturlig följd av den första, eftersom mycket av eters senaste värdeökning drevs av människor som köpte den för att investera i DAO.

DAO hade lovat att agera som en ny typ av decentraliserad crowddsourcing-fordon, som Kickstarter eller Indiegogo men utan mellanhand och regler. Den var utformad för att låta deltagarna samla sin cryptocurrency, kollektivt rösta på projekt som letar efter finansiering, sedan investera och skörda framtida belöningar. Innan katastrofen började över 100 projekt hade redan föreslagits, varav de flesta var relaterade till själva Ethereum. Dessutom tillät DAO deltagarna att dra tillbaka sina oinvesterade fonder när som helst och positionerade sig som en lågriskinvestering.

Ironiskt nog gjorde individen eller gruppen som tappade DAO det genom att utnyttja subtila fel i denna uttagsmekanism. Som alla smarta kontrakt i Ethereum är DAO bara en bit datorkod, som är "oförändrad" (dvs. permanent och irreversibelt) inbäddad i blockchain och utförs av varje nod som svar på inkommande transaktioner. Och som alla själv respekterande smarta kontrakt ger DAO full öppenhet genom att göra sin källkod lättillgänglig online. Detta innebär att vem som helst kan oberoende verifiera dess funktionalitet men också, avgörande, leta efter sårbarheter. Och ändå förhindrar den oföränderliga karaktären av blockchains att sådana problem fixas.

I slutet av maj, flera kritiska frågor var markerade på det enastående Hackadistribuerad blogg, tillsammans med ett krav på ett moratorium för projektförslag för DAO. Det här är vad vi kan kalla den "vita hatten" -metoden, där rapporteras om utnyttjanden till förmån för samhället. Ingen verkade dock alltför orolig, eftersom problemen relaterade till snedställda ekonomiska incitament snarare än en risk för direkt stöld. Samtidigt verkar det emellertid som om andra fördjupade DAO: s kod med större egenintresse - nämligen att leta efter ett sätt att tjäna massor av pengar. Och den 17 juni lyckades någon.

Tömning av DAO

I allmän mening härstod attacken från interaktionen mellan sårbarheter i DAO: s kod och annan kod som var utformad för att utnyttja dem. Du ser, när man tittade på isolerat, DAO innehöll inga uppenbara misstag, och det släpptes faktiskt först efter en omfattande säkerhetsrevision. Men med fördel i efterhand och många fler ögon har ett betydande antal fel hittats sedan dess.

Jag kommer inte att ge en fullständig teknisk beskrivning av exploateringsmekanismen här, eftersom andra redan har publicerat fantastiska och detaljerade efterlämningar (se här., här. och här.). Men jag kommer att förklara en viss sårbarhet som var närvarande, eftersom den har upptäckts i många andra smarta kontrakt och fungerar som ett lärorikt exempel.

Låt oss säga att ett smart kontrakt innehar medel för ett antal användares räkning och gör det möjligt för dessa användare att ta ut sina medel på begäran. Logiken för processen kan se ut så här:

Vänta tills en användare begär ett uttag.
Kontrollera om användarens balans är tillräcklig.
Skicka i så fall den begärda mängden till användarens adress.
Kontrollera att betalningen lyckades.
Om så är fallet drar du mängden från användarens saldo.

Allt ser väldigt förnuftigt ut, och snarare som en bankomat som ger dig lite kontanter och drar ut det korrekta beloppet från ditt banksaldo.

Så hur kan den här enkla processen gå fel? Det visar sig att om en Ethereum-adress tillhör ett kontrakt snarare än en vanlig användare, så kan det här kontraktet köra viss kod som svar på att ta emot medel. Och den här koden kan i sin tur utlösa andra kodstycken på Ethereum blockchain. Av avgörande betydelse kan det till och med utlösa samma kodkod som fick den att betalas i första hand.

Detta innebär att under steg 3 ovan kan den mottagande adressen skicka en ny begäran om återkallande, påbörja en ny process vid steg 1 innan den tidigare processen har slutförts. Eftersom användarens saldo endast reduceras i steg 5 kommer ett nytt uttag att godkännas baserat på det tidigare saldot, och samma belopp kommer att betalas ut igen. Som svar på den andra betalningen kan mottagningskontraktet begära en tredje, och sedan en fjärde, och så vidare tills medlen dräneras eller någon annan gräns har uppnåtts. Vid denna punkt är användarens balans kommer slutligen reduceras med lämpligt belopp, in i det negativa territoriet som steg 2 skulle förhindra.

Motsvarande skulle vara en ATM som levererar sedlar som utlöser en fri återupptagning när de vinkas vid skärmen. Den första kunden som fick reda på den kunde tömma ut bankomaten helt.

Denna förmåga för ett kodstycke att avveckla sig själv kallas rekursion, och är en mycket användbar teknik i allmän datorprogrammering. Men i fallet med DAO banade det vägen för denna förstörande exploatering. Ändå, om detta hade varit det enda problemet, hade attackens potential varit innesluten, eftersom Ethereum tillämpar en gräns för hur djupt rekursion kan inträffa. Tyvärr förstärkte flera ytterligare buggar i DAO effekterna, vilket ledde till en eventuell förlust på tiotals miljoner dollar.

Om bara några rader av DAO: s kod hade skrivits annorlunda, kunde inget av detta ha hänt. Till exempel, i 5-stegsprocessen ovan, om användarens balans minskas innan pengarna skickas, då skulle rekursiv samtal vara helt säkert. Men tyvärr, även om skaparens avsikter var rena, var DAO: s faktiska kod djupt felaktig. Och datorer har en otäck vana att blint följa anvisningarna som de ges, även om en femåring kan se att resultaten inte är vettiga. Efter att ha inbäddats obestämligt i Ethereum blockchain, fick den felaktiga DAO förvaltarskap över hundratals miljoner dollar av en horde naiva investerare och gick sedan spektakulärt upp i lågor. DAO visade sig vara en fullständig och fullständig beskjutning, och den kan aldrig åtgärdas.

Problemet med kod

Frestande som det kan vara, jag är inte här för att dra DAO: s programmerare över de tekniska kolen. Titta på underliggande källkod, det verkar ganska väl architected, med bra funktion och variabla namn och tydlig intern dokumentation. Inget av detta bevisar dess kvalitet, men det finns en hög korrelation mellan hur koden ser ut och hur bra den fungerar, av samma anledning som CV med dålig skiljetecken varnar för slarviga anställda. I vilket fall som helst tvivlar jag inte på att DAO: s författare är behöriga utvecklare - det faktum att det passerade en omfattande kodgranskning tyder på att den grundläggande logiken var sund.

Så om problemet inte är de människor som arbetade med detta projekt eller det arbete de producerade, vad är det då? Det är det faktum att Att skriva stora bitar av felfri kod är extremt svårt, om inte omöjligt. Jag har arbetat med några verkligen enastående programmerare i min karriär, den typ som kan skicka ut kod i tio gånger den genomsnittliga utvecklarens takt, och med tio gånger färre defekter. Och ändå gör även dessa anmärkningsvärda personer misstag som leder till programvarufel. Donald knuth, kanske den största dataprogrammeraren genom tiderna, gav ett berömt löfte att tillhandahålla en exponentiellt ökande ekonomisk belöning till varje person som hittade ett fel i sin TeX-typprogramvara. Och han har skickat ut mer än några få checkar.

För att vara tydlig talar jag inte om dumma utdragningar med namn som "off-by-one", "uninitialized variabel" och "operator presedence". Dessa orsakar ofta ett synligt fel första gången ett program körs och kan lätt upptäckas genom att granska den lokala kodkod där de finns. Och jag talar inte ens om säkerhetssårbarheter som "ovaliderade ingångar", "SQL-injektion" och "buffertöverskridningar", som kanske inte dyker upp i programmets regelbundna användning, men som ändå borde vara framme för alla erfarna utvecklare.

Snarare talar jag om svårare problem som "rasförhållanden" och "dödlås". Dessa härrör från konflikter mellan parallella processer och tenderar att bara dyka upp ibland, vilket gör dem svåra att upptäcka och reproducera. Som ett resultat kan de bara förstås genom att betrakta ett system som helhet och hur dess beståndsdelar interagerar. Detta är mycket svårare än vanlig programmering, eftersom det kräver att utvecklare tänker bortom den enskilda kodkod som de arbetar med. Det är inte ovanligt att kodarna tillbringar flera dagar på "felsökning" för att spika ett av dessa problem. Och detta är just den typ av helhetstänkande som behövdes för att förutse hur DAO kan vara sårbar.

Med alla dessa svårigheter kanske man legitimt undrar varför vår alltmer koddrivna värld inte smular runt oss. Lyckligtvis har de flesta programvaror tre kritiska faktorer som fungerar till sin fördel - gradvis antagande, regelbundna uppdateringar och tid.

Så här fungerar det: En ny mjukvaruprodukt skapas för att möta ett tillväxtmarknadsbehov. Till att börja med är marknaden liten, så bara ett fåtal människor vet att de behöver produkten. Och eftersom produkten är ny kommer ett ännu mindre antal faktiskt att hitta den. Dessa ”tidiga adoptörer” är en modig och hård gäng som tycker om att leva på den tekniska kanten trots de tillhörande riskerna. Så de testar den nya produkten, ser några saker de gillar, ber om en massa saker som saknas och bäst av allt, rapporterar eventuella problem. Varje bra mjukvaruentreprenör vet att de här människorna får kärlek och hjälp och tacka dem för varje bit av feedback de ger. För medan det suger att höra om en defekt i din produkt, suger det mycket mer inte att höra om det.

Helst, inom en månad eller mindre, släpps en ny version av produkten, fixar de rapporterade buggarna och lägger till några begärda funktioner. De tidiga adoptörerna är nöjda och mer återkoppling flyter in, eftersom den senaste versionen läggs igenom dess steg, och runt den går igen. När marknaden växer ökar antalet personer som använder produkten. Och när produkten stadigt förbättras, berättar fler och fler av dessa människor andra om den. Ännu bättre, ju fler människor som använder produkten, desto mer troligt är det att någon någonstans kommer att skapa den exakta och osannolika situation där ett otydligt fel kommer att dyka upp. Med lite tur låter de dig veta, och du kommer att skrapa huvudet i misstro, be om mer information, så småningom hitta och lösa problemet och andas ett lättnads suck.

Med några få undantag är det så dagens utvecklingsprogramvara, eftersom det är det mest effektiva sättet att skapa enastående produkter. Naturligtvis kommer ett bra programteam också att utveckla en omfattande intern testsvit för att fånga så många fel som möjligt innan de når användare och se till att nya versioner inte bryter något som tidigare fungerat. Men ändå är de flesta av oss också beroende av våra användarbaser, för det finns helt enkelt inget sätt att vi har råd att föreställa oss och testa alla möjliga sätt på vilka våra produkter kan användas. Och om du tror att detta inte gäller de stora killarna kan du inte ha mer fel. Hur många "automatiska uppdateringar" har laddats ner till ditt Windows-, Mac- eller Linux-system under det senaste året? Och om du använder Chrome eller Firefox uppdaterar din webbläsare sig själv automatiskt och tyst, i genomsnitt en gång per månad.

Denna iterativa process tar mycket tid, med vilken jag menar några år eller mer. Fortfarande, efter att en produkt har utvecklats tillräckligt länge och dess användarbas har blivit tillräckligt stor, och dessa användare har (medvetet) testat den i tillräckligt olika situationer, händer något magi. Denna magi kallas "mognad", och det är vad alla programvaruprodukter måste sträva efter att uppnå. Mognad innebär att en produkt fungerar riktigt bra för nästan alla som använder den, och det finns inga genvägar att komma dit. Men om du får rätt tidpunkt kommer din produkt att mogna ungefär den tidpunkt då din målmarknad sammanfaller, dvs. när ett stort antal kunder faktiskt är villiga att stubba upp och betala för det. Och sedan, som de säger, sannolikt kommer ni att tjäna.

På oföränderlig kod

Så här kommer vi till det grundläggande problemet med smarta kontrakt, vilket demonstreras så kraftfullt av DAO:

Genom design är smarta kontrakt inbyggda inbäddade i en blockchain och kan därför inte uppdateras. Detta förhindrar dem från att nå mognad.

I tidigare inlägg har jag diskuterat andra problem med smarta kontrakt, till exempel deras effekt på blockchainprestanda och det faktum att de är det mindre kraftfull än vad många föreställer sig. Av dessa och andra skäl har vi (ännu) inte implementerat smarta kontrakt i MultiKedja blockchain-plattform. Men tills jag bevittnade misslyckandet med DAO hade jag inte tagit tillräckligt med tanke på en mycket mer grundläggande fråga: alla icke-triviala smarta kontrakt kan troligen innehålla fel som inte kan åtgärdas.

För den moderna mjukvaruutvecklaren är ofodbar kod en ut-och-ut mardröm som ställer in fältet högre än de flesta kan nå. Men vi stöter på den här typen av kod i vissa situationer, till exempel utformningen av mikroprocessorer som ligger i hjärtat av varje dator och smartphone. Denna kod, skriven på språk som Verilog och VHDL, definierar den fysiska layouten för ett kiselchip, som inte kan ändras när den har tillverkats. I situationer som dessa tenderar vi att se flera egenskaper: (a) koden är skriven på ett språk som har utformats med säkerhet i åtanke, (b) ett stort antal människor arbetar med den under flera år, (c) det är ämnet till omfattande automatiserad testning och formell verifiering, och (d) om slutprodukten levereras med en defekt, faller kostnaden för en återkallelse kvadratiskt på axlarna hos den ansvariga parten (se till exempel den ökända Pentium-bugg).

Det säger sig självt att inget av detta gäller skaparna av DAO, eller verkligen något annat smart kontrakt. Men kodimmutabilitet är inte den enda utmaningen för smarta kontraktutvecklare. Ett antal andra faktorer samverkar för att göra Ethereum betydligt farligare än de flesta datormiljöer:

Som diskuterats tidigare avslöjar de flesta kontrakt sina källkoder för att få förtroende hos potentiella användare. Detta gör buggar lätt att hitta och utnyttja. Medan ordinarie kod kan åtgärdas när ett problem hittas, kan med angripande kod bara angripare dra nytta av.
Som på de flesta programmeringsspråk kan en "funktion" (kodkod) på blockchainen "ringa" (trigga) en annan för att skapa kaskadeffekter. Ethereum är emellertid ovanligt när det gäller att aktivera direkta funktionssamtal mellan koden skriven av parter som inte känner varandra och vars intressen kan kollidera. Detta är ett perfekt recept för motsatt och oväntat beteende.
Som nämnts tidigare, om ett Ethereum-avtal skickar medel till ett annat, har det senare möjlighet att utföra någon kod som svar. Den här koden kan medvetet utformas så att sändningsfunktionen misslyckas, potentiellt utlösande alla slags ytterligare förödelse.
När en funktion ringer en annan, och den andra funktionen kallar en tredje, skapas en "stack" av samtal och subsamtal. Att hålla reda på denna stack innebär en beräkningskostnad, så Ethereum inkluderar en "call stack limit" som begränsar hur djup den kan gå. Det här är rättvist. Men om gränsen nås av ett visst funktionssamtal, Ethereum-miljön tyst hoppar över att ringa, snarare än att säkert avsluta hela transaktionen och avlinda dess effekter. Med andra ord, någon kod i ett smart kontrakt bara kanske inte körs, och detta icke-utförande kan medvetet orsakas av att utlösa det kontraktet från en tillräckligt djup stack. Det här ser mig som ett verkligt avskyvärt designval och bryter den mentala modellen som varje programvaruutvecklare är van vid. Den som fattade detta beslut förmodligen skall dras över kolen, men det finns nu tack och lov a förslag att ändra det.
Ethereum har också en ”gasgräns”, som förhindrar missbruk i offentliga blockchains genom att transaktioner betalar för de beräkningsresurser de konsumerar. Avsändaren av en transaktion avgör hur mycket gas de är villiga att spendera, och om detta slutar innan transaktionen slutförs avbryts den säkert. Även om detta förmodligen är den bästa lösningen på ett svårt problem, kan det få obehagliga konsekvenser. Vissa kontrakt visar sig behöva mer gas än väntat, medan andra kan inte köras alls.
Det offentliga Ethereum-nätverkets cryptocurrency tillåter defekter i smarta kontrakt att skicka riktiga pengar till fel plats, utan någon enkel metod för återhämtning. Medan Ethereum gruvarbetare verkar vara rösta för av en "mjuk gaffel" för att frysa de medel som tappas från DAO, detta är inte en hållbar lösning.

För att sammanfatta, jämfört med vanliga centraliserade datorsystem, är Ethereum en mycket svårare miljö att säkra för. Och ändå fungerar dess princip om oföränderlighet för att förhindra att buggy-programvara uppdateras. Med andra ord är smarta kontrakt programvara vars buggar är synliga, inte kan åtgärdas och direkt kontrollerar riktiga människors pengar. Detta är ganska uppenbart en mycket giftig blandning.

Förespråkare av smarta kontrakt i Ethereum-stil i privat blockchains kan frestas att fira DAO: s undergång, men jag tror inte att detta svar är berättigat. Med undantag för de två sista punkterna ovan gäller alla frågorna med Ethereum lika för tillåtna blockchains, som fortfarande förlitar sig på oföränderliga smarta kontrakt - även om i detta fall garanteras oföränderligheten av en grupp identifierade parter snarare än anonyma gruvarbetare. Om du vill hävda att privata blockchains tillåter att buggy smarta kontrakt lättare kan spolas upp, bytas ut eller ignoreras, vad du verkligen säger är att smarta kontrakt inte har något syfte i dessa blockchains alls. Enkelt uttryckt, om något inte är tänkt att vara oföränderligt, bör det inte lagras i en blockchain. Håll dig istället vid goda gammaldags juridiska dokument och centraliserad applikationslogik, med hjälp av kedjan för: (a) oföränderligt lagring av datum som den logiken beror på och (b) representerar det slutliga samtyckliga resultatet av att tillämpa den. (Detta designmönster har fått namnet Enkla kontrakt av andra.)

Ändå är riskerna i det offentliga Ethereum-nätverket utan tvekan sämre, eftersom dåligt skrivna smarta kontrakt snabbt och irreversibelt kan skicka stora mängder verkligt värde (i form av cryptocurrency) till användare vars identitet är okänd. Finns det verkligen något bättre sätt för ett ondt geni att döda än: (a) skriva ett smart kontrakt som utseende rätt och rättvist, (b) tillåta den att köra säkert och konsekvent under flera år, (c) väntar på att den samlar in en stor summa pengar från investerare, och sedan (d) utlöser en dunkel sårbarhet för att överlåta dessa fonder. Medan jag inte föreslår att DAO: s misslyckande var medvetet, kommer det säkert att inspirera andra att göra liknande "misstag".

Om jag var tvungen att sammanfatta de faktorer som ligger till grund för Ethereums design, kan jag använda frasen ”oerfarligt geni”. Geni, för jag tror att det är en verkligt lysande uppfinning som lägger till två viktiga innovationer till cryptocurrency-systemen som kom före: (a) Ethereum Virtual Machine som utför smarta kontrakt och dess metod för att tilldela kostnad till beräkning, och (b) användningen av Patricia träd för att möjliggöra kompakta bevis på alla aspekter av blockchains tillstånd. Och ändå, oerfaren också, eftersom några av Ethereums designval är så uppenbarligen fruktansvärda, såsom den tysta men våldsamma samtalstackgränsen, eller en betalningsmottagares förmåga att rekursivt utlösa koden som betalade den.

Inget av detta skulle vara ett problem om Ethereum behandlades som ett experiment, värt att utforska men med kritiska problem som återstår att lösa. Motsvarande bitcoin kanske under de första åren, då dess totala börsvärde inte överskred några miljoner dollar. Tyvärr har Ethereum till följd av spekulationer och uppblåsta förväntningar inte fått samma möjlighet att hitta sina ordspråkiga fötter. Istället, på mindre än ett år gammal, har den en miljard dollar i marknadsvärde. Ethereum är som ett litet barn som tvingas laga mat, eller en nybörjare som är ordförande i Federal Reserve. Jag tror att det är dags att erkänna att omognadsproblemet med enskilda smarta kontrakt också gäller Ethereum som helhet.

Ethereums väg framåt

Medan jag ännu inte har sett starka användningsfall för smarta kontrakt i privata eller tillåtna blockchains, tror jag att de förmodligen har en plats i offentliga kedjor med tillhörande cryptocurrencies. Det vill säga, om du accepterar den grundläggande förutsättningen för censurfria finansiella system, som hjälper de ekonomiskt uteslutna och ransomware-författarna i lika stor utsträckning. Att lägga denna debatt åt sidan finns det verkligen teknisk meriter på ett cryptocurrency som stöder godtycklig logik, av den typ som inte kan implementeras på “första generationens” blockchains som bitcoin. För närvarande är Ethereum det första och enda övertygande försöket att bygga ett sådant system, med massor av pengar och fart bakom sig.

Ändå som utvecklarekosystem verkar Ethereum vara grundläggande trasig. Medan DAO är dess mest kostsamma och högprofilerade misslyckande, är det många andra kontrakt lider av liknande problem. Så hur kan Ethereum städa upp sin handling?

Skicka ett tydligt meddelande om att ingen, åtminstone under de kommande två åren, inte ska skicka några medel till ett smart kontrakt om de inte är glada att förlora dem i namnet självutbildning.
Fixa några bländande problem med Ethereum Virtual Machine (“EVM”), nämligen: (a) ta bort gränsen för samtalsstapel, (b) tillhandahålla ett sätt att skicka eter utan att utlösa kod, och (c) tillåta kontrakt att markeras som " non-reentrant ”, vilket betyder att deras funktioner inte kan kallas medan de redan är mitt i något.
Utveckla ett nytt programmeringsspråk för smarta kontrakt, som använder en mer restriktiv metod för att uttrycka beräkning som är möjlig att använda formella bevis på korrekthet. Tio år av forskning har redan investerats på detta område, så det finns mycket befintligt arbete som ska utnyttjas. (Detta kräver inte ändringar av själva EVM, eftersom det valda språket fortfarande kan kompileras till vanlig ”bytecode”.)
Bygg upp en officiell uppsättning säkra smarta kontrakt och funktioner, som har granskats till döds och visat sig pålitliga i många olika situationer. Detta är besläktat med standardbibliotek som är tillgängliga för många mogna programmeringsspråk. (Även om det just nu är frestande att fråga: varför inte bara koda funktionaliteten för dessa bibliotek till EVM och njuta av mycket bättre prestanda som ett resultat? Svar: Eftersom Ethereum var speciellt utformat för att flytta bort från blockchains med hårdkodad Funktionsuppsättningar. Men ändå får det dig att undra.)

Det nuvarande alternativet att manuellt ingripa som svar på misslyckandet med specifika smarta kontrakt kommer inte att vara livskraftigt i större skala om Ethereum ska behålla sin identitet som en tillförlitlig och decentraliserad datorplattform. Vissa gör faktiskt ett trovärdigt fall som denna enda bedömningsbaserade handlingshandling redan har förstörde Ethereums rykte. Och vi bör notera att DAO: er Villkor uttryckligen uttryckligen att ingenting "får ändra eller lägga till några ytterligare skyldigheter eller garantier utöver vad som anges i DAO: s kod". Med andra ord, den som tappade DAO agerade i enlighet med dess publicerade villkor och är därför förmodligen på rätt sida av lagen.

Vi måste också acceptera möjligheten att Ethereum efter flera år av bra arbete fortfarande kan vara för svårt för utvecklare att arbeta med säkert. I så fall kommer det att försvinna som en matchmakingtjänst mellan anonyma bedragare och deras dumma märken. Men det skulle inte betyda att det var slöseri med tid - i det minste är Ethereum ett fascinerande experiment, från vilket blockchain-samhället kommer att lära sig mycket.

Under tiden, för användare av privata blockchains, kan jag bara upprepa det jag har sagt tidigare:

Om din ansökan inte kräver smarta kontrakt använder du en enklare blockchain-arkitektur.

Medan detta råd tidigare var motiverat vad gäller prestanda, förstärks det nu av den uppenbara svårigheten att få smarta kontrakt rätt. Och om du inte är säker på om ditt användningsfall kräver smarta kontrakt, känn dig fri att göra det maila oss med några detaljer, så meddelar vi dig gärna.

Skicka eventuella kommentarer på Link.