Kehittäjät kumoavat Vitalikin: oletukset ovat vääriä, eikä RISC-V ole paras valinta

Tämä artikkeli on lähde: Ethereum-kehittäjä levochka.eth-kokoelma

|Odaily Planet Daily (@OdailyChina); @azuma_eth Toimittajan

huomautus:

Ethereumin perustaja Vitalik julkaisi eilen radikaalin artikkelin Ethereumin suorituskerroksen päivityksestä (katso "Vitalik's Radical New Article: Execution Layer Scaling "Doesn't Break, Doesn't Stand", EVM Must Be Iterated in the Future), jossa hän mainitsi, että hän toivoo voivansa korvata sen RISC-V:llä EVM älykkäiden sopimusten virtuaalikonekielenä.

Heti kun tämä artikkeli ilmestyi, se aiheutti välittömästi kohua Ethereumin kehittäjäyhteisössä, ja monet tekniset suurmiehet ilmaisivat erilaisia näkemyksiä suunnitelmasta. Pian artikkelin julkaisemisen jälkeen Tier-1 Ethereumin kehittäjä levochka.eth kirjoitti alkuperäisen artikkelin alle pitkän artikkelin, jossa hän kumosi Vitalikin väitteen, jonka mukaan Vitalik oli tehnyt vääriä oletuksia todistusjärjestelmästä ja sen suorituskyvystä ja että RISC-V ei ehkä ole paras valinta, koska se ei pystynyt tasapainottamaan "skaalautuvuutta" ja "ylläpidettävyyttä".

Seuraava on alkuperäinen artikkeli levochka.eth:ssä, jonka on koonnut Odaily-päivälehti.

Älä tee tätä.

Tässä suunnitelmassa ei ole järkeä, koska teet vääriä oletuksia järjestelmän ja sen suorituskyvyn todistamisesta.

Validointihypoteesi

Ymmärtääkseni tämän järjestelmän tärkeimmät argumentit ovat "skaalautuvuus" ja "ylläpidettävyys".

Ensinnäkin haluan puhua ylläpidettävyydestä.

Itse asiassa kaikki RISC-V zk-VM:t vaativat "esikäännöksiä" laskentaintensiivisten toimintojen käsittelemiseksi. Valmiiksi koottu luettelo SP 1:stä löytyy Succinctin dokumentaatiosta, ja huomaat, että se kattaa lähes kaikki tärkeät EVM:n "laskennalliset" opkoodit.

Tämän seurauksena kaikki peruskerroksen salausprimitiivien muutokset edellyttävät uusien "piirien" kirjoittamista ja auditointia näille esikäännöksille, mikä on vakava rajoitus.

Todellakin, jos suorituskyky on riittävän hyvä, voi olla suhteellisen helppoa suorittaa asiakkaan "ei-EVM" -osan huollettavuus. En ole varma, onko se tarpeeksi hyvä, mutta en ole yhtä varma tästä osasta seuraavista syistä:

• "tilapuun laskentaa" voidaan todellakin nopeuttaa huomattavasti Poseidonin kaltaisella ystävällisellä esikääntämisellä.

• Ei kuitenkaan ole selvää, voidaanko "deserialisointia" hoitaa tyylikkäällä ja ylläpidettävällä tavalla.
  

• Lisäksi on joitain hankalia yksityiskohtia (kuten kaasunmittaus ja erilaiset tarkastukset), jotka voivat kuulua "lohkon arviointiajan" alle, mutta jotka pitäisi itse asiassa luokitella "ei-EVM" -osiksi, jotka ovat yleensä alttiimpia huoltopaineelle.

Toiseksi skaalautuvuutta koskeva osa.

Minun on toistettava, että RISC-V:n on mahdotonta käsitellä EVM-kuormia ilman esikäännöstä, ehdottomasti ei.

Joten alkuperäisen tekstin väite, että "lopullista todistusaikaa hallitsee nykyinen esikäännösoperaatio" on teknisesti oikea, mutta se on liian optimistinen - se olettaa, että esikäännöstä ei tule tulevaisuudessa, kun itse asiassa (tässä tulevassa skenaariossa) esikäännös on edelleen olemassa, ja se on täsmälleen sama kuin EVM:n laskennallisesti intensiiviset opkoodit (kuten allekirjoitukset, hajautusarvot ja mahdollisesti suuret analogit).

Fibonaccin esimerkkiä on vaikea arvioida menemättä hienovaraisimpiin yksityiskohtiin, mutta edut tulevat ainakin osittain

• ero tulkinnan ja toteutuksen välillä;

• Syklinen purkaminen (vähentää RISC-V:n "ohjausvirtaa", on epävarmaa, voidaanko Solidity toteuttaa, mutta yksikin opkoodi voi silti tuottaa suuren määrän ohjausvirran/muistin käyttöoikeuksia tulkintakustannusten vuoksi);

• käyttää pienempiä tietotyyppejä;

huomauttaa, että kohtien 1 ja 2 etujen toteuttamiseksi "tulkintakustannukset" on poistettava. Tämä on linjassa RISC-V:n filosofian kanssa, mutta tämä ei ole se RISC-V, josta keskustelemme parhaillaan, vaan pikemminkin samanlainen "(?)RISC-V" - se vaatii tiettyjä lisäominaisuuksia, kuten sopimuskonseptien tukea.

Tässä tulee ongelma,

joten tässä on joitain ongelmia.

• Ylläpidettävyyden parantamiseksi tarvitset RISC-V:n (esikäännöksellä), joka kääntää EVM:n - siinä se on.

• Skaalautuvuuden parantamiseksi tarvitaan jotain aivan muuta – uusi arkkitehtuuri, joka saattaa olla samanlainen kuin RISC-V, joka ymmärtää "sopimusten" käsitteen, on yhteensopiva Ethereumin ajonaikaisten rajoitusten kanssa ja voi suorittaa sopimuskoodin suoraan (ilman "tulkintakustannuksia").

Oletan nyt, että viittaat toiseen tapaukseen (koska artikkelin loppuosa näyttää viittaavan siihen). Minun on kiinnitettävä huomionne siihen, että kaikki tämän ympäristön ulkopuolinen koodi kirjoitetaan edelleen nykyisellä RISC-V zkVM -kielellä, jolla on merkittävä vaikutus ylläpitoon.

Vaihtoehtoisesti

voimme kääntää tavukoodin korkean tason EVM-opkoodista. Kääntäjä on vastuussa siitä, että rakentaja pysyy muuttumattomana, kuten ei koe "pinon ylivuotoa". Haluaisin nähdä tämän näytettävän tavallisessa EVM:ssä. Oikein laadituille SNARKeille voidaan toimittaa sopimuksen käyttöönotto-ohjeet.

Voimme myös rakentaa "muodollisen todisteen", joka todistaa, että jotkut invariantit ovat säilyneet. Sikäli kuin voin sanoa, tätä lähestymistapaa (ei "virtualisointia") on käytetty joissakin selainyhteyksissä. Luomalla SNARK:t tästä muodollisesta todistuksesta voit saavuttaa samanlaisia tuloksia. 

Tietysti helpoin vaihtoehto on purra luotia ja tehdä ......

Minimaalisen "ketjutetun" MMU:n rakentaminen

, jonka voit epäsuorasti ilmaista artikkelissa, mutta haluan varoittaa, että jos haluat eliminoida virtualisointikustannukset, sinun on suoritettava käännetty koodi suoraan — mikä tarkoittaa, että sinun on jotenkin estettävä sopimusta (nyt suoritettava) kirjoittamasta ytimen (ei EVM-toteutuksen) muistiin.

Siksi tarvitsemme jonkinlaisen "muistinhallintayksikön" (MMU). Perinteisten tietokoneiden hakumekanismi ei ehkä ole tarpeen, koska "fyysinen" muistitila on lähes ääretön. Tämän MMU:n tulisi olla mahdollisimman kevyt (koska se on samalla abstraktiotasolla kuin itse arkkitehtuuri), mutta joitain ominaisuuksia, kuten transaktioiden atomisuus, voidaan siirtää tälle tasolle.

Tässä vaiheessa todistettavasta EVM:stä tulee tällä arkkitehtuurilla toimiva ydinohjelma.

RISC-V ei ehkä ole paras vaihtoehto

Mielenkiintoista on, että kaikissa näissä olosuhteissa paras "käskyjoukkoarkkitehtuuri" (ISA) tähän tehtävään ei välttämättä ole RISC-V, vaan jotain EOF-EVM:n kaltaista seuraavista syistä:

• "Pienet" opkoodit johtavat itse asiassa suureen muistiin, jota nykyisten todennusmenetelmien on vaikea käsitellä tehokkaasti.

• Haaroittumiskustannusten vähentämiseksi näytimme äskettäisessä Morgana-artikkelissamme, kuinka "staattiset hypyt" (EOF) -koodi voidaan todistaa esikäännöstason suorituskyvyllä.

Ehdotukseni on rakentaa uusi todistusystävällinen arkkitehtuuri minimaalisella MMU:lla, joka mahdollistaa sopimuksen toimimisen erillisenä suoritettavana tiedostona. En usko, että sen pitäisi olla RISC-V, vaan pikemminkin uusi ISA, joka on optimoitu SNARK-protokollan rajoituksiin, ja jopa ISA, joka perii osittain osan EVM-opkoodeista, voisi olla parempi - kuten tiedämme, esikääntäminen on tullut jäädäkseen, halusimme tai emme, joten RISC-V ei tuo tähän mitään yksinkertaistamista.