Vitalikin pitkän aikavälin L1-johtotason ehdotuksen koko teksti: EVM:n korvaaminen RISC-V:llä

Lähde: Vitalik Buterin

Kokoelma: KarenZ, Ennakointiuutiset

Huhtikuun 20. päivänä Vitalik Buterin esitteli tärkeän ehdotuksen Ethereum Magicians -alustasta Ethereumin pitkäaikaiselle L1-suorituskerrokselle. Hän ehdotti nykyisen EVM:n (Ethereum Virtual Machine) korvaamista RISC-V-arkkitehtuurilla virtuaalikoneen kielenä älykkäiden sopimusten kirjoittamiseen, jonka tavoitteena on parantaa perusteellisesti Ethereumin suorituskerroksen toiminnallista tehokkuutta, murtaa yksi nykyisistä suurimmista skaalauksen pullonkauloista ja yksinkertaistaa huomattavasti suorituskerroksen yksinkertaisuutta.

Foresight News on koonnut ehdotuksen koko tekstin auttaakseen lukijoita ymmärtämään tätä teknistä visiota. Seuraavassa on kooste alkuperäisestä ehdotuksesta:

Tässä artikkelissa esitetään radikaali ajatus Ethereumin toteutuskerroksen tulevaisuudesta, joka ei ole vähemmän kunnianhimoinen kuin konsensuskerroksen Beam Chain -aloitteet. Ehdotuksen tavoitteena on parantaa dramaattisesti Ethereumin toteutuskerroksen tehokkuutta, puuttua yhteen suurimmista skaalauksen pullonkauloista ja yksinkertaistaa merkittävästi toteutuskerrosta – itse asiassa tämä voi olla ainoa tapa saavuttaa tämä.

Ydinidea: Korvaa EVM RISC-V:llä älykkäiden sopimusten virtuaalikonekielenä.

Tärkeitä huomautuksia:

• Käsitteet, kuten tilijärjestelmä, sopimusten väliset puhelut, tallennus jne., säilytetään täysin. Nämä abstraktit mallit toimivat hyvin ja kehittäjät ovat tottuneet käyttämään niitä. OPKOODIT, KUTEN SLOAD, SSTORE, BALANCE, CALL JNE., MUUNNETAAN RISC-V-JÄRJESTELMÄKUTSUIKSI.

• Tässä tilassa älykkäitä sopimuksia voidaan kirjoittaa Rustissa, mutta odotan useimpien kehittäjien jatkavan sopimusten kirjoittamista Solidityssä (tai Vyperissä), joka mukautuu RISC-V:hen uutena taustajärjestelmänä. Koska Rustilla kirjoitetut älykkäät sopimukset ovat itse asiassa vähemmän luettavia, kun taas Solidity ja Vyper ovat selkeämpiä ja helpompia lukea. Kehityskokemukseen ei ehkä juurikaan vaikuta, eivätkä kehittäjät välttämättä edes huomaa muutosta.

• Vanha EVM-sopimus jatkuu ja on täysin kaksisuuntaisesti yhteensopiva uuden RISC-V-sopimuksen kanssa. On olemassa useita tapoja tehdä tämä, joista keskustellaan tarkemmin myöhemmin tässä artikkelissa.

Nervos CKB VM on luonut ennakkotapauksen ja on pohjimmiltaan RISC-V-toteutus.

Miksi?

Lyhyellä aikavälillä tulevat EIP:t (esim. lohkotason käyttöoikeusluettelot, lykätty toteutus, hajautettu historian tallennus ja EIP-4444) käsittelevät Ethereum L1:n suurimpia skaalauspullonkauloja. Lisää ongelmia ratkaistaan keskipitkällä aikavälillä valtiottomuuden ja ZK-EVM:n avulla. Pitkällä aikavälillä Ethereum L1:n skaalauksen tärkeimpiä rajoittavia tekijöitä ovat:

1. Tietojen saatavuuden, näytteenoton ja historiallisten tallennusprotokollien vakaus

2. Kilpailun kysynnän ylläpitäminen lohkotuotantomarkkinoilla

3. Todiste ZK-EVM:stä

Väitän, että ZK-EVM:n korvaaminen RISC-V:llä voi ratkaista keskeiset pullonkaulat kohdissa (2) ja (3).

Seuraava taulukko havainnollistaa Concinct ZK-EVM Proof EVM -suorituskerroksen kutakin vaihetta varten tarvittavien syklien määrän:

Kaavion kuvaus: Neljä tärkeintä aikaa vievää segmenttiä ovat deserialize_inputs, initialize_witness_db, state_root_computation ja block_execution

initialize_witness_db ja state_root_computation liittyvät tilapuihin, ja niihin liittyy deserialize_inputs lohko- ja todistajatietojen muuntaminen sisäisiksi esityksiksi – joista yli 50 % on itse asiassa verrannollinen todistajatietojen kokoon.

Nämä osiot voidaan optimoida huomattavasti korvaamalla nykyinen keccak 16-ary Merkle patricia -puu binääripuulla, joka käyttää helposti todistettavaa hajautusfunktiota. Jos käytämme Poseidonia, voimme todistaa 2 miljoonaa hashia sekunnissa kannettavalla tietokoneella (verrattuna noin 15 000 hashiin/s keccakilla). Poseidonin lisäksi on monia muita vaihtoehtoja. Kaiken kaikkiaan näille komponenteille on paljon optimointivaraa. Lisäksi voimme poistaa accrue_logs_bloom poistamalla kukinnan.

Loput block_execution muodostavat noin puolet nykyisistä kohotussykleistä. Yleisen todistustehokkuuden 100-kertaisen kasvun saavuttamiseksi vaaditaan vähintään 50-kertainen EVM-todistustehokkuus. Yksi ratkaisu on luoda tehokkaampi todistetoteutus EVM:lle, ja toinen on huomata, että nykyinen ZK-EVM-todistaja itse asiassa kääntää EVM:n RISC-V:hen todisteeksi, mikä antaa älykkäiden sopimusten kehittäjille suoran pääsyn RISC-V-virtuaalikoneeseen.

Jotkut tiedot osoittavat, että tietyissä tilanteissa voi tapahtua yli 100-kertaisia tehokkuushyötyjä:

Käytännössä jäljellä oleva kohotusaika voi olla enimmäkseen nykyisen esikäännösoperaation käytössä. Kun RISC-V on ensisijainen virtuaalikone, kaasuaikataulu heijastaa todellista koeaikaa, ja taloudellinen paine saa kehittäjät vähentämään kalliiden esikäännösten käyttöä. Silloinkaan hyödyt eivät ole niin merkittäviä, mutta meillä on hyvä syy uskoa, että ne ovat merkittäviä.

(On syytä huomata, että "EVM-operaatioihin" ja "muihin toimintoihin" kuluva aika tavallisessa EVM:n suorituksessa on myös lähellä 50/50, joten oletamme intuitiivisesti, että EVM:n poistaminen "välikerroksena" tuo yhtä merkittävän hyödyn.)

Toteutuksen yksityiskohdat

Ehdotus voidaan panna täytäntöön useilla eri tavoilla. Vähiten häiritsevä ratkaisu on tukea molempia virtuaalikoneita ja sallia sopimuksen kirjoittaminen jommassakummassa niistä. Molemmilla sopimustyypeillä on pääsy samoihin ominaisuuksiin: pysyvä tallennus (SLOAD/SSTORE), mahdollisuus säilyttää ETH-saldoja, aloittaa/vastaanottaa puheluita ja paljon muuta. EVM- ja RISC-V-sopimuksia voidaan kutsua toisilleen - RISC-V:n näkökulmasta EVM-sopimuksen kutsuminen vastaa järjestelmäkutsun suorittamista erityisillä parametreilla; Viestin vastaanottava EVM-sopimus tulkitsee sen PUHELUKSI.

Radikaalimpi lähestymistapa protokollan näkökulmasta on muuntaa olemassa oleva EVM-sopimus kutsuksi EVM-tulkkisopimukseen, joka on kirjoitettu RISC-V:llä sen olemassa olevan EVM-koodin suorittamiseksi. Toisin sanoen, jos EVM-sopimuksessa on koodi C ja EVM-tulkki on osoitteessa X, sopimus korvataan ylätason logiikalla, joka ulkopuolelta kutsuttaessa kutsuargumentilla D kutsuu X:ää ja syöttää (C, D), odottaa sitten palautusarvoa ja välittää eteenpäin. Jos EVM-tulkki itse soittaa sopimukseen ja pyytää suorittamaan CALL- tai SLOAD/SSTORE-toiminnon, sopimus suorittaa nämä toiminnot.

Kompromissi on toinen vaihtoehto, mutta se tukee nimenomaisesti "virtuaalikoneen tulkin" käsitettä protokollan kautta, joka edellyttää, että sen logiikka on kirjoitettu RISC-V:llä. EVM on ensimmäinen instanssi, joka tukee tulevaisuudessa muita kieliä (Move voi olla ehdokas).

Toisen ja kolmannen vaihtoehdon keskeinen etu on, että ne yksinkertaistavat huomattavasti suorituskerroksen määrittelyä. OTTAEN HUOMIOON, KUINKA VAIKEAA ON POISTAA EDES ASTEITTAISIA YKSINKERTAISTUKSIA, KUTEN ITSETUHOA, TÄMÄ AJATTELUTAPA VOI OLLA AINOA TOTEUTTAMISKELPOINEN TAPA YKSINKERTAISTAA. Tinygrad noudattaa tiukkaa sääntöä "enintään 10 000 koodiriviä", ja optimaalisen taustalla olevan lohkoketjun pitäisi pystyä helposti täyttämään tämä raja ja virtaviivaistamaan sitä entisestään. Beam Chain -aloite lupaa yksinkertaistaa dramaattisesti Ethereumin konsensuskerrosta, ja tällainen radikaali muutos voi olla ainoa tapa saavuttaa samanlainen lisäys toteutuskerroksessa.