Smart Contracts And The DAO Implosion

Opublikowane ponownie przez Plato

Obserwuje: 0

Tragiczne połączenie nieuniknionych błędów i niezmiennego kodu

W zeszłym tygodniu nastąpiło katastrofalne wydarzenie w ekosystemie Ethereum, kiedy DAO, inteligentny kontrakt mający mniej niż dwa miesiące, zaczął szybko przeciekać fundusze nieznanej stronie. Patrząc na aktualny zestaw kontraktów Ethereum, wypełnionych kasynami i samozwańczymi schematami Ponzi, może nie wydawać się to wielkim problemem. To znaczy, dopóki nie dowiesz się, że ponad 12 milionów jednostek eteru, kryptowaluty Ethereum, zostało zainwestowanych w The DAO przez prawie 20,000 osób. To około 15% całego istniejącego eteru, wycenionego na ponad 250 milionów dolarów 17 czerwca.

Dwa dni później aktywa DAO spadły poniżej 100 milionów dolarów. Do tego gwałtownego upadku przyczyniły się dwie rzeczy. Po pierwsze, jedna trzecia jej funduszy (wyrażonych w eterze) została już zajęta. Po drugie, wynikająca z tego panika spowodowała, że cena rynkowa eteru spadła ze szczytu przekraczającego 21 USD do bardziej otrzeźwiającego poziomu 10.67 USD. (W momencie publikacji cena powróciła do około 14 USD). Ten drugi efekt był naturalną konsekwencją pierwszego, ponieważ znaczna część niedawnego wzrostu wartości eteru była napędzana przez kupujących go ludzi w celu zainwestowania w The DAO.

DAO obiecało działać jako nowy typ zdecentralizowanego narzędzia do pozyskiwania środków, jak Kickstarter czy Indiegogo, ale bez pośredników i regulacji. Został zaprojektowany, aby umożliwić uczestnikom łączenie ich kryptowalut, zbiorowe głosowanie nad projektami poszukującymi finansowania, a następnie inwestowanie i czerpanie przyszłych korzyści. Zanim wydarzyła się katastrofa, ponad 100 projektów zostały już zaproponowane, z których większość była związana z samym Ethereum. Ponadto DAO umożliwiał uczestnikom wycofanie niezainwestowanych środków w dowolnym momencie, pozycjonując się jako inwestycja niskiego ryzyka.

Jak na ironię, osoba lub grupa, która opróżniła The DAO, zrobiła to, wykorzystując subtelne błędy w tym mechanizmie wycofywania. Podobnie jak wszystkie inteligentne kontrakty w Ethereum, DAO to po prostu fragment kodu komputerowego, który jest „niezmiennie” (tj. Trwale i nieodwracalnie) osadzony w łańcuchu bloków i wykonywany przez każdy węzeł w odpowiedzi na przychodzące transakcje. I jak każdy szanujący się inteligentny kontrakt, DAO zapewnia pełną przejrzystość, udostępniając swój kod źródłowy online. Oznacza to, że każdy może samodzielnie zweryfikować jego funkcjonalność, ale przede wszystkim poszukać luk. A jednak niezmienny charakter łańcuchów bloków uniemożliwia naprawienie takich problemów.

Pod koniec maja kilka krytycznych kwestii zostały wyróżnione na wybitnych Hakowanie rozproszone blog, wraz z zaproszeniem do moratorium na propozycje projektów dla DAO. To właśnie moglibyśmy nazwać podejściem „białego kapelusza”, w którym exploity są zgłaszane dla dobra społeczności. Niemniej jednak nikt nie wydawał się zbyt zmartwiony, ponieważ problemy dotyczyły raczej wypaczonych bodźców ekonomicznych niż ryzyka jawnej kradzieży. Jednocześnie jednak okazuje się, że inni zastanawiali się nad kodem The DAO z większym interesem własnym - a mianowicie, szukając sposobu na zarobienie mnóstwa pieniędzy. A 17 czerwca komuś się udało.

Opróżnianie DAO

Ogólnie rzecz biorąc, atak powstał w wyniku interakcji między lukami w kodzie DAO a innym kodem, który został zaprojektowany w celu ich wykorzystania. Widzisz, analizowany osobno DAO nie zawierał żadnych oczywistych błędów i rzeczywiście został wydany dopiero po szeroko zakrojonym audycie bezpieczeństwa. Ale z perspektywy czasu i wielu innych oczu, od tamtej pory znaleziono znaczną liczbę błędów.

Nie podam tutaj pełnego opisu technicznego mechanizmu exploita, ponieważ inni opublikowali już świetne i szczegółowe sekcje zwłok (patrz tutaj, tutaj i tutaj). Ale wyjaśnię jedną konkretną lukę, która była obecna, ponieważ została odkryta w wiele innych inteligentnych kontraktów i służy jako pouczający przykład.

Załóżmy, że inteligentny kontrakt przechowuje środki w imieniu wielu użytkowników i umożliwia im wypłacanie środków na żądanie. Logika tego procesu może wyglądać mniej więcej tak:

Poczekaj, aż użytkownik zażąda wypłaty.
Sprawdź, czy saldo tego użytkownika jest wystarczające.
Jeśli tak, wyślij żądaną ilość na adres użytkownika.
Sprawdź, czy płatność się powiodła.
Jeśli tak, odejmij ilość z salda użytkownika.

To wszystko wygląda wyjątkowo rozsądnie i przypomina bankomat, który daje ci trochę gotówki i odejmuje odpowiednią kwotę z twojego konta bankowego.

Jak więc ten prosty proces może się nie udać? Okazuje się, że jeśli adres Ethereum należy do umowy, a nie do zwykłego użytkownika, to ta umowa może uruchomić jakiś kod w odpowiedzi na otrzymanie środków. A ten kod może z kolei wyzwolić inne fragmenty kodu w łańcuchu blokowym Ethereum. Co najważniejsze, może nawet wywołać ten sam fragment kodu, który spowodował, że został zapłacony w pierwszej kolejności.

Oznacza to, że podczas kroku 3 powyżej adres odbiorcy może wysłać nowe żądanie wypłaty, rozpoczynając nowy proces w kroku 1, zanim poprzedni proces się zakończy. Ponieważ saldo użytkownika jest zmniejszane dopiero w kroku 5, nowa wypłata zostanie zatwierdzona na podstawie poprzedniego salda, a ta sama kwota zostanie wypłacona ponownie. W odpowiedzi na tę drugą płatność, umowa przyjmująca może zażądać trzeciej, a następnie czwartej i tak dalej, aż środki zostaną wyczerpane lub osiągnięty zostanie inny limit. W tym momencie saldo użytkownika będzie ostatecznie zostać zmniejszona o odpowiednią kwotę, wchodząc na terytorium ujemne, któremu miał zapobiec krok 2.

Ekwiwalentem byłby bankomat, który dostarcza banknoty, które po machnięciu ręką na ekranie wyzwalają możliwość darmowego ponownego wypłaty. Pierwszy klient, który się o tym dowie, może całkowicie opróżnić bankomat.

Ta zdolność fragmentu kodu do wywoływania samego siebie nazywa się rekurencja, i jest bardzo przydatną techniką w ogólnym programowaniu komputerowym. Jednak w przypadku The DAO utorowało to drogę do tego zgubnego exploita. Niemniej jednak, gdyby był to jedyny problem, potencjał ataku zostałby ograniczony, ponieważ Ethereum stosuje ograniczenie dotyczące tego, jak głęboka rekursja może wystąpić. Niestety, kilka dalszych błędów w The DAO wzmocniło efekty, prowadząc do ostatecznej utraty dziesiątek milionów dolarów.

Oczywiście, gdyby tylko kilka wierszy kodu The DAO zostało napisanych inaczej, nic z tego nie mogłoby się wydarzyć. Na przykład, w powyższym pięciostopniowym procesie, jeśli saldo użytkownika jest zmniejszone zanim środki są wysyłane, wtedy wywołanie rekurencyjne byłoby całkowicie bezpieczne. Ale niestety, nawet jeśli intencje twórców były czyste, rzeczywisty kod DAO był głęboko wadliwy. A komputery mają paskudny zwyczaj ślepego wykonywania instrukcji, które otrzymują, nawet jeśli pięciolatek widzi, że wyniki nie mają sensu. Będąc niezmiennie osadzonym w łańcuchu blokowym Ethereum, wadliwy DAO otrzymał od hordy naiwnych inwestorów zarządzanie w wysokości ponad setek milionów dolarów, a następnie spektakularnie stanął w płomieniach. DAO okazał się kompletnym i kompletnym chaosem, którego nigdy nie da się naprawić.

Problem z kodem

Choć może to być kuszące, nie jestem tutaj, aby ciągnąć programistów DAO przez węgle techniczne. Patrząc na podstawowy kod źródłowy, wydaje się dość dobrze zaprojektowany, z dobrą funkcją i nazwami zmiennych oraz przejrzystą dokumentacją wewnętrzną. Chociaż nic z tego nie dowodzi jego jakości, zwykle istnieje wysoka korelacja między wyglądem kodu a jego działaniem, z tego samego powodu, z którego CV ze słabą interpunkcją ostrzegają przed niechlujnymi pracownikami. W każdym razie nie wątpię, że autorzy The DAO są kompetentnymi programistami - faktycznie, fakt, że przeszedł obszerną recenzję kodu, sugeruje, że podstawowa logika była rozsądna.

Jeśli więc problemem nie są ludzie, którzy pracowali nad tym projektem, ani praca, którą wykonali, to co to jest? Faktem jest, że pisanie dużych fragmentów kodu wolnego od błędów jest niezwykle trudne, jeśli nie niemożliwe. W swojej karierze pracowałem z naprawdę wybitnymi programistami, z takimi, którzy potrafią generować kod w tempie dziesięć razy szybszym od przeciętnego programisty i z dziesięciokrotnie mniejszą liczbą błędów. A jednak nawet te niezwykłe osoby popełniają błędy, które prowadzą do nieprawidłowego działania oprogramowania. Donald knuth, prawdopodobnie największy programista wszechczasów, złożył słynną obietnicę dostarczenia wykładniczo rosnąca nagroda finansowa każdemu, kto znalazł błąd w swoim oprogramowaniu do składu TeX-a. I wysłał więcej niż kilka czeków.

Żeby było jasne, nie mówię o głupich wpadkach z nazwami typu „off-by-one”, „niezainicjalizowana zmienna” i „pierwszeństwo operatorów”. Często powodują one widoczną awarię przy pierwszym uruchomieniu programu i można je łatwo wykryć, przeglądając lokalny fragment kodu, w którym się znajdują. I nie mówię nawet o lukach w zabezpieczeniach, takich jak „niewalidowane dane wejściowe”, „wstrzyknięcie SQL” i „przepełnienia bufora”, które mogą nie pojawić się w zwykłym użyciu programu, ale mimo to powinny być brane pod uwagę przez każdego doświadczonego programistę.

Mówię raczej o trudniejszych problemach, takich jak „warunki wyścigu” i „impas”. Wynikają one z konfliktów między równoległymi procesami i zwykle pojawiają się tylko sporadycznie, co utrudnia ich wykrycie i odtworzenie. W rezultacie można je zrozumieć tylko poprzez rozważenie systemu jako całości i interakcji jego części składowych. Jest to o wiele trudniejsze niż zwykłe programowanie, ponieważ wymaga od programistów myślenia poza indywidualnym fragmentem kodu, nad którym pracują. Często zdarza się, że programiści spędzają kilka dni na „debugowaniu” w celu rozwiązania jednego z tych problemów. I to jest dokładnie ten rodzaj holistycznego myślenia, które było potrzebne, aby przewidzieć, w jaki sposób DAO może być podatny na ataki.

Biorąc pod uwagę wszystkie te trudności, można słusznie zastanawiać się, dlaczego nasz coraz bardziej oparty na kodach świat nie rozpada się wokół nas. Na szczęście większość oprogramowania ma trzy krytyczne czynniki działające na jego korzyść - stopniowe wdrażanie, regularne aktualizacje i czas.

Oto jak to działa: Nowe oprogramowanie jest tworzone, aby odpowiedzieć na pojawiające się potrzeby rynku. Na początku rynek jest mały, więc tylko kilka osób wie, że potrzebuje produktu. A ponieważ produkt jest nowy, jeszcze mniej osób go znajdzie. Ci „pierwsi naśladowcy” to odważna i wytrzymała gromada, która mimo związanego z tym ryzyka lubi żyć na krawędzi technologicznej. Dlatego wypróbowują nowy produkt, widzą rzeczy, które im się podobają, proszą o kilka brakujących rzeczy, a co najważniejsze, zgłaszają wszelkie napotkane problemy. Każdy dobry przedsiębiorca zajmujący się oprogramowaniem wie, jak obsypywać tych ludzi miłością i pomocą oraz dziękuje im za każdy kęs ich opinii. Bo chociaż słyszenie o usterce produktu jest do bani, to o wiele bardziej nie usłyszeć o tym.

Idealnie byłoby, gdyby w ciągu miesiąca lub krócej została wydana nowa wersja produktu, naprawiająca zgłoszone błędy i dodająca kilka żądanych funkcji. Pierwsi użytkownicy są zadowoleni i napływa więcej informacji zwrotnych, ponieważ najnowsza wersja jest poddawana próbom i znowu trwa. Wraz z rozwojem rynku rośnie liczba osób korzystających z produktu. A ponieważ produkt stale się poprawia, coraz więcej osób mówi o nim innym. Co więcej, im więcej osób korzysta z produktu, tym większe jest prawdopodobieństwo, że ktoś gdzieś stworzy tę precyzyjną i mało prawdopodobną sytuację, w której pojawi się niejasny błąd. Przy odrobinie szczęścia dadzą ci znać, a ty podrapiesz się w głowę z niedowierzaniem, poprosisz o więcej informacji, w końcu znajdziesz i rozwiążesz problem, po czym odetchniesz z ulgą.

Z nielicznymi wyjątkami tak działa dzisiejsze tworzenie oprogramowania, ponieważ jest to najbardziej efektywny sposób tworzenia wyjątkowych produktów. Oczywiście dobry zespół programistów opracuje również obszerny zestaw testów wewnętrznych, aby wyłapać jak najwięcej błędów, zanim dotrą one do użytkowników, i upewnić się, że nowe wersje nie zepsują niczego, co działało wcześniej. Mimo to większość z nas polega również na naszych bazach użytkowników, ponieważ po prostu nie możemy sobie pozwolić na wyobrażenie sobie i przetestowanie wszystkich możliwych sposobów wykorzystania naszych produktów. A jeśli uważasz, że to nie dotyczy dużych facetów, nie możesz się bardziej mylić. Ile „automatycznych aktualizacji” zostało pobranych do Twojego systemu Windows, Mac lub Linux w ciągu ostatniego roku? Jeśli używasz przeglądarki Chrome lub Firefox, Twoja przeglądarka internetowa aktualizuje się teraz automatycznie i cicho, średnio raz w miesiącu.

Ten iteracyjny proces zajmuje dużo czasu, przez co mam na myśli kilka lat lub więcej. Mimo to, gdy produkt był już wystarczająco długo rozwijany, a baza użytkowników wystarczająco się rozrosła, a użytkownicy (nieświadomie) testowali go w wystarczająco różnych sytuacjach, dzieje się coś magicznego. Ta magia nazywa się „dojrzałością” i do tego musi dążyć każdy produkt programowy. Dojrzałość oznacza, że produkt działa naprawdę dobrze dla prawie każdego, kto go używa, i nie ma żadnych dróg na skróty. Ale jeśli trafisz we właściwy moment, Twój produkt dojrzeje mniej więcej w czasie, gdy Twój rynek docelowy połączy się, tj. Kiedy duża liczba klientów będzie rzeczywiście gotowa zaatakować i zapłacić. A potem, jak mówią, naprawdę skorzystacie.

Na niezmiennym kodzie

Więc tutaj dochodzimy do podstawowego problemu z inteligentnymi kontraktami, jak dobitnie zademonstrował The DAO:

Z założenia inteligentne kontrakty są niezmiennie osadzone w łańcuchu bloków, więc nie można ich aktualizować. To uniemożliwia im osiągnięcie dojrzałości.

W poprzednich postach omówiłem inne problemy z inteligentnymi kontraktami, takie jak ich wpływ na wydajność łańcucha bloków i fakt, że są mniej silny niż wielu ludzi sobie wyobraża. Z tych i innych powodów nie wdrożyliśmy (jeszcze) inteligentnych kontraktów w MultiChain platforma blockchain. Ale dopóki nie byłem świadkiem niepowodzenia The DAO, nie zastanawiałem się wystarczająco nad znacznie bardziej fundamentalną kwestią: każdy nietrywialny inteligentny kontrakt prawdopodobnie zawiera wady, których nie da się naprawić.

Dla współczesnego programisty, niemożliwy do naprawienia kod jest koszmarem, który stawia poprzeczkę wyżej niż większość jest w stanie dosięgnąć. Ale tego rodzaju kod napotykamy w niektórych sytuacjach, na przykład przy projektowaniu mikroprocesorów, które są sercem każdego komputera i smartfona. Ten kod, napisany w językach takich jak Verilog i Vhdl, definiuje fizyczny układ chipa krzemowego, którego nie można zmienić po wyprodukowaniu. W takich sytuacjach mamy do czynienia z kilkoma cechami: (a) kod jest napisany w języku zaprojektowanym z myślą o bezpieczeństwie, (b) duża liczba osób pracuje nad nim przez kilka lat, (c) podlega do szeroko zakrojonych testów automatycznych i weryfikacji formalnej oraz (d) jeśli produkt końcowy jest wysyłany z wadą, koszt wycofania spada bezpośrednio na barki odpowiedzialnej strony (patrz na przykład niesławny Błąd Pentium).

Jest rzeczą oczywistą, że nic z tego nie dotyczy twórców The DAO, ani też żadnej innej inteligentnej umowy. Jednak niezmienność kodu nie jest jedynym wyzwaniem dla programistów inteligentnych kontraktów. Szereg innych czynników powoduje, że Ethereum jest znacznie bardziej niebezpieczny niż większość środowisk komputerowych:

Jak wspomniano wcześniej, większość umów ujawnia swój kod źródłowy, aby zdobyć zaufanie potencjalnych użytkowników. To sprawia, że błędy są łatwe do znalezienia i wykorzystania. Podczas gdy zwykły kod można naprawić po znalezieniu problemu, w przypadku kodu niezmiennego korzyści odnoszą tylko osoby atakujące.
Jak w większości języków programowania, jedna „funkcja” (fragment kodu) w łańcuchu bloków jest w stanie „wywołać” (wyzwolić) inną, tworząc efekt kaskadowy. Jednak Ethereum nietypowo umożliwia bezpośrednie wywoływanie funkcji między kodem napisanym przez strony, które się nie znają i których interesy mogą kolidować. To doskonały przepis na wrogie i nieoczekiwane zachowanie.
Jak wspomniano wcześniej, jeśli jedna umowa Ethereum wysyła środki do drugiej, ta druga ma możliwość wykonania kodu w odpowiedzi. Ten kod może być celowo zaprojektowany tak, aby spowodować niepowodzenie operacji wysyłania, potencjalnie wyzwalające wszelkiego rodzaju dalsze spustoszenie.
Kiedy jedna funkcja wywołuje inną, a ta druga wywołuje trzecią, tworzony jest „stos” wywołań i wywołań podrzędnych. Śledzenie tego stosu wiąże się z kosztami obliczeniowymi, dlatego Ethereum zawiera „limit stosu wywołań”, który ogranicza jego głębokość. To jest w porządku. Ale jeśli limit zostanie osiągnięty przez określone wywołanie funkcji, środowisko Ethereum bezgłośnie pomija to wywołanie, zamiast bezpiecznie kończyć całą transakcję i cofać jej skutki. Innymi słowy, jakiś kod w inteligentnej umowie po prostu może nie zostać wykonany, a to niewykonanie może być celowo spowodowane wyzwalaniem kontraktu z wystarczająco głębokiego stosu. Wydaje mi się, że jest to naprawdę ohydny wybór projektowy, przełamujący mentalny model, do którego przyzwyczaił się każdy programista. Prawdopodobnie ten, kto podjął tę decyzję powinien być ciągniętym przez węgle, chociaż na szczęście jest teraz sugestia, aby to zmienić.
Ethereum ma również „limit gazu”, który zapobiega nadużyciom w publicznych łańcuchach bloków, powodując, że transakcje płacą za zużywane zasoby obliczeniowe. Nadawca transakcji decyduje, ile gazu chce wydać, a jeśli skończy się to przed zakończeniem transakcji, jest bezpiecznie przerywana. Chociaż jest to prawdopodobnie najlepsze rozwiązanie trudnego problemu, może mieć nieprzyjemne konsekwencje. Niektóre kontrakty wymagają więcej gazu, niż przewidywano, podczas gdy inne nie można w ogóle uruchomić.
Kryptowaluta publicznej sieci Ethereum umożliwia defektom inteligentnych kontraktów wysyłanie prawdziwych pieniędzy w niewłaściwe miejsce, bez łatwej metody ich odzyskania. Chociaż wydaje się, że górnicy Ethereum głosowanie za „miękkiego widelca” w celu zamrożenia funduszy odprowadzonych z DAO, nie jest to trwałe rozwiązanie.

Podsumowując, w porównaniu do zwykłych scentralizowanych systemów komputerowych Ethereum jest znacznie trudniejszym środowiskiem do bezpiecznego kodowania. A jednak jego zasada niezmienności służy zapobieganiu aktualizacji błędnego oprogramowania. Innymi słowy, inteligentne kontrakty to oprogramowanie, którego błędy są widoczne, nie można ich naprawić i bezpośrednio kontrolują prawdziwe pieniądze ludzi. Jest to oczywiście wysoce toksyczna mieszanka.

Zwolennicy inteligentnych kontraktów w stylu Ethereum w prywatny blockchainy mogą pokusić się o świętowanie upadku DAO, ale nie sądzę, aby ta odpowiedź była zasłużona. Z wyjątkiem dwóch ostatnich punktów powyżej, wszystkie problemy z Ethereum dotyczą w równym stopniu dozwolonych łańcuchów bloków, które nadal opierają się na niezmiennych inteligentnych kontraktach - chociaż w tym przypadku niezmienność jest gwarantowana przez grupę zidentyfikowanych stron, a nie anonimowych górników. Jeśli chcesz twierdzić, że prywatne łańcuchy bloków pozwalają na łatwiejsze przewijanie, zastępowanie lub ignorowanie wadliwych inteligentnych kontraktów, to tak naprawdę mówisz, że inteligentne kontrakty nie mają żadnego celu w tych łańcuchach bloków. Mówiąc prościej, jeśli coś nie ma być niezmienne, nie powinno być przechowywane w łańcuchu bloków. Zamiast tego trzymaj się starych, dobrych dokumentów prawnych i scentralizowanej logiki aplikacji, używając łańcucha do: (a) niezmiennego przechowywania dane od której zależy ta logika, oraz b) przedstawiający ostateczny zgodny wynik jej zastosowania. (Ten wzorzec projektowy został nazwany Proste umowy przez innych.)

Niemniej jednak zagrożenia w publicznej sieci Ethereum są niewątpliwie większe, ponieważ źle napisane inteligentne kontrakty mogą szybko i nieodwracalnie wysłać duże ilości realnej wartości (w postaci kryptowaluty) do użytkowników, których tożsamość jest nieznana. Rzeczywiście, czy istnieje lepszy sposób na dokonanie zabójstwa przez złego geniusza niż: (a) napisanie inteligentnego kontraktu, który wygląd słuszne i uczciwe, (b) pozwalając mu działać bezpiecznie i konsekwentnie przez kilka lat, (c) czekając, aż zgromadzi dużą sumę pieniędzy od inwestorów, a następnie (d) wywołując niejasną podatność na wyprowadzenie tych funduszy. Chociaż nie sugeruję, że niepowodzenie DAO było zamierzone, z pewnością zainspiruje innych do popełnienia podobnych „błędów”.

Gdybym miał podsumować czynniki leżące u podstaw projektu Ethereum, mógłbym użyć określenia „niedoświadczony geniusz”. Geniusz, ponieważ uważam, że jest to naprawdę genialny wynalazek, dodający dwie kluczowe innowacje do systemów kryptowalut, które pojawiły się wcześniej: (a) maszyna wirtualna Ethereum, która wykonuje inteligentne kontrakty i jej metodę przypisywania kosztów do obliczeń, oraz (b) użycie z Drzewa Patricia aby umożliwić zwięzłe dowody dowolnego aspektu stanu łańcucha bloków. A jednak niedoświadczony, ponieważ niektóre z wyborów projektowych Ethereum są tak oczywiste okropne, takie jak limit stosu cichych, ale gwałtownych połączeń lub zdolność odbiorcy płatności do rekurencyjnego wyzwalania kodu, który go zapłacił.

Nic z tego nie stanowiłoby problemu, gdyby Ethereum było traktowane jako eksperyment, godny eksploracji, ale z krytycznymi problemami do rozwiązania. Być może odpowiednik bitcoina w ciągu pierwszych kilku lat, kiedy jego całkowita kapitalizacja rynkowa nie przekraczała kilku milionów dolarów. Niestety, w wyniku spekulacji i zawyżonych oczekiwań, Ethereum nie dostało takiej samej okazji, aby znaleźć swoje przysłowiowe stopy. Zamiast tego, mając mniej niż rok, ma wartość rynkową miliarda dolarów. Ethereum jest jak małe dziecko zmuszane do gotowania obiadu lub nowicjusz ekonomii przewodniczący Rezerwy Federalnej. Uważam, że nadszedł czas, aby uznać, że problem niedojrzałości poszczególnych inteligentnych kontraktów dotyczy również Ethereum jako całości.

Droga naprzód Ethereum

Chociaż nie widzę jeszcze mocnych przypadków użycia inteligentnych kontraktów w prywatnych lub dozwolonych łańcuchach bloków, myślę, że prawdopodobnie mają one miejsce w publicznych łańcuchach z powiązanymi kryptowalutami. To znaczy, jeśli akceptujesz podstawową przesłankę systemów finansowych wolnych od cenzury, które w równym stopniu pomagają wykluczonym finansowo i autorom oprogramowania ransomware. Odkładając na bok tę debatę, z pewnością tak techniczny zasługuje na kryptowalutę, która obsługuje arbitralną logikę, w rodzaju, którego nie można zaimplementować w łańcuchach bloków „pierwszej generacji”, takich jak bitcoin. Przynajmniej na razie Ethereum jest pierwszą i jedyną przekonującą próbą zbudowania takiego systemu, za którą stoi mnóstwo pieniędzy i rozmach.

Niemniej jednak, jako ekosystem programisty, Ethereum wydaje się być zasadniczo zepsuty. Chociaż DAO jest najbardziej kosztowną i głośną awarią, wiele innych umów tak cierpi na podobne problemy. Jak więc Ethereum może oczyścić swój akt?

Wyślij jasny komunikat, że przynajmniej przez najbliższe dwa lata nikt nie powinien przesyłać żadnych środków na inteligentny kontrakt, chyba że z radością je straci w imię samokształcenia.
Napraw kilka rażących problemów z maszyną wirtualną Ethereum („EVM”), a mianowicie: (a) usunięcie limitu stosu wywołań, (b) zapewnienie sposobu na wysyłanie eteru bez uruchamiania kodu oraz (c) zezwolenie na oznaczanie kontraktów jako „ niewtajemniczeni ”, co oznacza, że ich funkcji nie można nazwać, gdy są już w środku czegoś.
Opracuj nowy język programowania dla inteligentnych kontraktów, który wykorzystuje bardziej restrykcyjną metodę wyrażania obliczeń, która jest dostępna dla formalne dowody poprawności. W tej dziedzinie zainwestowano już dziesięciolecia w badania, więc istnieje wiele istniejących prac do wykorzystania. (Nie będzie to wymagało zmian w samym EVM, ponieważ wybrany język można nadal skompilować do zwykłego „kodu bajtowego”).
Stwórz oficjalny zestaw bezpiecznych inteligentnych kontraktów i funkcji, które zostały sprawdzone przez specjalistów i sprawdziły się w wielu różnych sytuacjach. Jest to podobne do standardowe biblioteki które są dostępne dla wielu dojrzałych języków programowania. (Chociaż w tym momencie kuszące jest pytanie: dlaczego po prostu nie zakodować na stałe funkcjonalności tych bibliotek w EVM i w rezultacie cieszyć się znacznie lepszą wydajnością? Odpowiedź: Ponieważ Ethereum został specjalnie zaprojektowany, aby odejść od łańcuchów bloków z zakodowanym na stałe zestawy funkcji. Mimo to zastanawiasz się).

Obecna opcja ręcznej interwencji w odpowiedzi na niepowodzenie określonych inteligentnych kontraktów nie będzie opłacalna na większą skalę, jeśli Ethereum ma zachować swoją tożsamość jako pozbawionej zaufania i zdecentralizowanej platformy obliczeniowej. Rzeczywiście, niektórzy przedstawiają wiarygodną argumentację, że ten pojedynczy akt zarządzania oparty na osądach już się odbył zniszczył reputację Ethereum. Powinniśmy zauważyć, że DAO Regulamin wyraźnie stwierdza, że nic „nie może modyfikować ani dodawać żadnych dodatkowych zobowiązań lub gwarancji poza tymi określonymi w kodzie DAO”. Innymi słowy, ktokolwiek opróżnił DAO działał zgodnie z opublikowanymi warunkami, a zatem prawdopodobnie znajduje się po właściwej stronie prawa.

Musimy również zaakceptować możliwość, że po kilku kolejnych latach dobrej pracy Ethereum może nadal okazać się dla programistów zbyt trudny do bezpiecznej pracy. W takim przypadku będzie marnował się jako usługa kojarzenia między anonimowymi oszustami i ich głupimi znakami. Nie oznaczałoby to jednak, że była to strata czasu - przynajmniej Ethereum to fascynujący eksperyment, z którego społeczność blockchain wiele się nauczy.

W międzyczasie dla użytkowników prywatnych łańcuchów bloków mogę tylko powtórzyć to, co powiedziałem wcześniej:

Jeśli Twoja aplikacja nie wymaga inteligentnych kontraktów, użyj prostszej architektury blockchain.

Podczas gdy wcześniej ta rada była uzasadniona pod względem wydajności, obecnie jest ona wzmocniona przez widoczną trudność we właściwym wykonaniu inteligentnych kontraktów. A jeśli nie masz pewności, czy Twój przypadek użycia wymaga inteligentnych kontraktów, nie wahaj się napisz do nas ze szczegółami, a my z przyjemnością Cię powiadomimy.

Prosimy o umieszczanie komentarzy na LinkedIn.