Twórcy obalają Vitalika: założenia są błędne, a RISC-V nie jest najlepszym wyborem

Ten artykuł pochodzi z: Kompilacja dewelopera Ethereum levochka.eth

|Odaily Planet Daily (@OdailyChina); @azuma_eth Uwaga redaktora

:

Wczoraj współzałożyciel Ethereum, Vitalik, opublikował radykalny artykuł na temat aktualizacji warstwy wykonawczej Ethereum (zobacz "Radical New Article: Execution Layer Scaling "Doesn't Break, Doesn't Stand", EVM Must Be Iterated in the Future), wspominając, że ma nadzieję zastąpić go RISC-V EVM jako język maszyn wirtualnych dla inteligentnych kontraktów.

Gdy tylko ukazał się ten artykuł, natychmiast wywołał oburzenie w społeczności programistów Ethereum, a wiele technicznych grubych ryb wyraziło różne poglądy na temat planu. Wkrótce po opublikowaniu artykułu, deweloper Ethereum Tier-1 levochka.eth napisał długi artykuł poniżej oryginalnego artykułu, obalając argument Vitalika, że Vitalik przyjął błędne założenia dotyczące systemu dowodowego i jego wydajności, a RISC-V może nie być najlepszym wyborem, ponieważ nie może zrównoważyć "skalowalności" i "łatwości utrzymania".

Poniżej znajduje się oryginalny artykuł na levochka.eth, opracowany przez codzienną gazetę Odaily.

Proszę, nie rób tego.

Ten plan nie ma sensu, ponieważ przyjmujesz błędne założenia dotyczące udowadniania systemu i jego wydajności.

Hipoteza walidacji

Jak rozumiem, głównymi argumentami przemawiającymi za tym schematem są "skalowalność" i "łatwość utrzymania".

Po pierwsze, chcę porozmawiać o łatwości utrzymania.

W rzeczywistości wszystkie maszyny wirtualne RISC-V zk-VM wymagają "prekompilacji" do obsługi operacji intensywnie korzystających z obliczeń. Wstępnie skompilowaną listę SP 1 można znaleźć w dokumentacji Succinct i przekonasz się, że obejmuje ona prawie wszystkie ważne "obliczeniowe" kody operacyjne w EVM.

W rezultacie, wszystkie modyfikacje prymitywów kryptograficznych warstwy podstawowej wymagają napisania i sprawdzenia nowych "obwodów" dla tych prekompilacji, co jest poważnym ograniczeniem.

Rzeczywiście, jeśli wydajność jest wystarczająco dobra, może być stosunkowo łatwo wykonać zadanie serwisowania części klienta "nie-EVM". Nie jestem pewien, czy jest to wystarczająco dobre, ale jestem mniej pewny swojej części z następujących powodów:

• "obliczenia drzewa stanów" mogą być rzeczywiście znacznie przyspieszone dzięki przyjaznej prekompilacji, takiej jak Poseidon.

• Nie jest jednak jasne, czy "deserializacja" może być obsługiwana w elegancki i łatwy w utrzymaniu sposób.
  

• Ponadto istnieją pewne skomplikowane szczegóły (takie jak pomiar gazu i różne kontrole), które mogą wchodzić w zakres "czasu oceny bloku", ale w rzeczywistości powinny być klasyfikowane jako części "inne niż EVM", które są bardziej podatne na presję konserwacyjną.

Po drugie, część dotycząca skalowalności.

Muszę powtórzyć, że RISC-V nie jest w stanie obsłużyć obciążeń EVM bez użycia prekompilacji, absolutnie nie.

Tak więc stwierdzenie w oryginalnym tekście, że "czas ostatecznego dowodu zostanie zdominowany przez obecną operację prekompilacji" jest technicznie poprawne, ale jest zbyt optymistyczne - zakłada, że w przyszłości nie będzie prekompilacji, podczas gdy w rzeczywistości (w tym przyszłym scenariuszu) prekompilacja nadal będzie istnieć, i jest dokładnie taka sama, jak intensywne obliczeniowo kody operacyjne w EVM (takie jak sygnatury, skróty i możliwie duże analogi).

Trudno jest ocenić przykład Fibonacciego bez wchodzenia w najsubtelniejsze szczegóły, ale zalety są przynajmniej częściowe:

• różnica między interpretacją a narzutem wykonania;

• Cykliczne odwijanie (zmniejszanie "przepływu sterowania" RISC-V, nie jest pewne, czy Solidity może zostać zaimplementowane, ale nawet pojedynczy kod operacyjny może nadal generować dużą liczbę przepływów sterowania/dostępów do pamięci z powodu narzutu interpretacji);

• używać mniejszych typów danych;

W tym miejscu chciałbym zwrócić uwagę, że aby zrealizować korzyści płynące z punktu 1 i punktu 2, należy wyeliminować "narzut interpretacyjny". Jest to zgodne z filozofią RISC-V, ale nie jest to RISC-V, o którym obecnie dyskutujemy, a raczej podobny "(?)RISC-V" - wymaga pewnych dodatkowych możliwości, takich jak wsparcie dla koncepcji kontraktowych.

Tu pojawia się problem

, więc są tu pewne problemy.

• Aby poprawić łatwość utrzymania, potrzebujesz RISC-V (z prekompilacją), który kompiluje EVM - to prawie wszystko.

• Aby poprawić skalowalność, potrzebne jest coś zupełnie innego – nowa architektura, która może być podobna do RISC-V, która rozumie koncepcję "kontraktów", jest kompatybilna z ograniczeniami czasu wykonywania Ethereum i może wykonywać kod kontraktu bezpośrednio (bez "narzutu interpretacji").

Zakładam teraz, że odnosisz się do drugiego przypadku (ponieważ reszta artykułu wydaje się to sugerować). Muszę zwrócić uwagę na fakt, że cały kod poza tym środowiskiem nadal będzie napisany w obecnym języku RISC-V zkVM, co ma znaczący wpływ na utrzymanie.

Alternatywnie

możemy skompilować kod bajtowy z kodu operacyjnego EVM wysokiego poziomu. Kompilator jest odpowiedzialny za zapewnienie, że konstruktor pozostaje niezmienny, na przykład nie występuje "przepełnienie stosu". Chciałbym, aby to było pokazane w normalnym EVM. Prawidłowo skompilowane SNARK mogą być dostarczane z instrukcjami wdrażania kontraktów.

Można też skonstruować "dowód formalny" który dowodzi że niektóre niezmienniki są zachowane. O ile mi wiadomo, to podejście (nie "wirtualizacja") było używane w niektórych kontekstach przeglądarek. Generując SNARKi tego formalnego dowodu, można osiągnąć podobne wyniki. 

Oczywiście najłatwiejszą opcją jest zaciśnięcie zęba i zrobienie ......

Zbudowanie minimalnego "łańcuchowego" MMU

, co możesz niejawnie wyrazić w artykule, ale pozwól, że ostrzegę, że jeśli chcesz wyeliminować narzut związany z wirtualizacją, musisz wykonać skompilowany kod bezpośrednio — co oznacza, że musisz jakoś zapobiec zapisowi kontraktu (teraz wykonywalnego) do pamięci jądra (nie implementacji EVM).

W związku z tym potrzebujemy pewnego rodzaju "jednostki zarządzania pamięcią" (MMU). Mechanizm przywoławczy tradycyjnych komputerów może nie być konieczny, ponieważ "fizyczna" przestrzeń pamięci jest prawie nieskończona. To MMU powinno być tak oszczędne, jak to tylko możliwe (ponieważ jest na tym samym poziomie abstrakcji, co sama architektura), ale niektóre cechy, takie jak niepodzielność transakcji, można przenieść do tej warstwy.

W tym momencie możliwy do udowodnienia EVM staje się programem jądra działającym na tej architekturze.

RISC-V może nie być najlepszą opcją

Co ciekawe, we wszystkich tych warunkach, najlepszą "architekturą zestawu instrukcji" (ISA) do tego zadania może nie być RISC-V, ale coś podobnego do EOF-EVM z następujących powodów:

• "Małe" kody operacyjne w rzeczywistości skutkują dużym dostępem do pamięci, co jest trudne do efektywnej obsługi przez istniejące metody atestracji.

• Aby zmniejszyć obciążenie związane z rozgałęzieniami, pokazaliśmy, jak udowodnić kod "statycznych skoków" (EOF) z wydajnością na poziomie prekompilacji w naszym ostatnim artykule, Morgana.

Moja sugestia jest taka, aby zbudować nową, przyjazną dla dowodów architekturę z minimalnym MMU, która pozwala na działanie kontraktu jako oddzielnego pliku wykonywalnego. Nie wydaje mi się, żeby to miał być RISC-V, ale raczej nowy ISA zoptymalizowany pod kątem ograniczeń protokołu SNARK, a nawet ISA, który częściowo dziedziczy podzbiór kodów operacyjnych EVM, może być lepszy - jak wiemy, prekompilacja zostanie z nami na dłużej, czy nam się to podoba, czy nie, więc RISC-V nie przynosi tutaj żadnych uproszczeń.