Artikel yang menerangkan cara Ethereum Reth mencapai 1GB gas sesaat

Bagaimana Ethereum Reth mencapai gas 1GB sesaat? Kami mula membina Reth pada tahun 2022 untuk memberikan keanjalan untuk Ethereum L1 sambil menyelesaikan masalah penskalaan lapisan pelaksanaan pada L2. Hari ini, kami teruja untuk berkongsi cara Reth merancang untuk mencapai 1GB gas sesaat L2 pemprosesan pada tahun 2024, dan pelan hala tuju jangka panjang kami tentang cara untuk melebihi matlamat tersebut. Kami menjemput seluruh ekosistem untuk menyertai kami dalam mendorong sempadan prestasi dan penanda aras yang ketat dalam crypto. Hari ini, editor laman web ini akan memberi anda pengenalan terperinci tentang cara Reth mencapai gas 1GB sesaat. Rakan-rakan yang suka Ethereum Reth tidak boleh ketinggalan!

Kami menekankan gas sesaat dan menggunakannya untuk menilai secara menyeluruh prestasi rangkaian EVM sambil menangkap kos pengkomputeran dan penyimpanan. Rangkaian seperti Solana, Sui atau Aptos tidak disertakan kerana model kosnya yang unik. Kami menggalakkan usaha untuk menyelaraskan model kos merentas semua rangkaian blockchain untuk membolehkan perbandingan yang komprehensif dan saksama.

Kami sedang membangunkan satu set alat penanda aras tanpa henti untuk Reth untuk meniru beban kerja sebenar. Keperluan kami untuk nod adalah untuk mematuhi penanda aras TPC.

2. Bagaimanakah Reth mencapai 1GB gas sesaat? Atau lebih tinggi lagi?

Sebahagian daripada motivasi kami untuk mencipta Reth pada tahun 2022 ialah kami sangat memerlukan pelanggan yang dibina khusus untuk rollup web. Kami percaya laluan kami ke hadapan adalah menjanjikan.

Reth ​​​​sudah mencapai 100-200MB gas sesaat semasa penyegerakan langsung (termasuk pemulihan penghantar, melaksanakan transaksi dan mengira percubaan untuk setiap blok, jadi untuk mencapai matlamat jangka pendek kami sebanyak 1GB gas sesaat, kami perlu membuat skala lagi 10 kali.

Semasa Reth berkembang, rancangan pengembangan kami mesti mencari keseimbangan antara kebolehskalaan dan kecekapan:

• Peluasan menegak: Matlamat kami adalah untuk memaksimumkan penggunaan setiap "kotak" ke potensi penuhnya. Dengan mengoptimumkan cara setiap sistem individu memproses urus niaga dan data, kami boleh meningkatkan prestasi keseluruhan dengan sangat baik sambil turut menjadikan pengendali nod individu lebih cekap.

• Penskalaan Mendatar: Walaupun pengoptimuman, jumlah urus niaga yang banyak pada skala web melebihi kapasiti pemprosesan mana-mana pelayan tunggal. Untuk menangani situasi ini, kami mempertimbangkan untuk menggunakan seni bina penskalaan mendatar yang serupa dengan model Kubernetes nod blockchain. Ini bermakna menyebarkan beban kerja merentasi pelbagai sistem untuk memastikan tiada satu nod boleh menjadi hambatan.

Pengoptimuman yang kita bincangkan di sini tidak akan melibatkan penyelesaian pertumbuhan negeri, bahagian ini adalah sesuatu yang akan kita bincangkan secara berasingan dalam artikel lain. Berikut ialah gambaran keseluruhan rancangan kami untuk mencapai matlamat ini:

Sepanjang tindanan teknologi, kami juga telah mengoptimumkan IO dan CPU menggunakan model pelakon, membolehkan setiap bahagian tindanan digunakan sebagai perkhidmatan dan berbutir halus kawalan ke atas penggunaannya. Akhir sekali, kami sedang menilai secara aktif pangkalan data alternatif tetapi belum memuktamadkan satu lagi.

Pelan Hala Tuju Penskalaan Menegak untuk 2.1 Reth

Matlamat kami untuk penskalaan menegak adalah untuk memaksimumkan prestasi dan kecekapan pelayan atau komputer riba yang menjalankan Reth.

(1) EVM (Just-In-Time) Malah dan Ahead-of-Time (Ahead-of-Time) EVM

Dalam persekitaran blockchain seperti Mesin Maya Ethereum (EVM), pelaksanaan bytecode ditafsirkan oleh Jurubahasa (jurubahasa), jurubahasa memproses arahan mengikut urutan. Kaedah ini akan membawa sedikit overhed, kerana arahan pemasangan asli tidak dilaksanakan secara langsung, tetapi operasi dilakukan melalui lapisan VM.

Kompilasi Just-in-time (JIT) menyelesaikan masalah ini dengan menukar bytecode kepada kod mesin asli sebelum pelaksanaan, sekali gus meningkatkan prestasi dengan memintas proses tafsiran VM. Teknologi ini boleh menyusun kontrak ke dalam kod mesin yang dioptimumkan terlebih dahulu dan telah digunakan dengan baik dalam mesin maya lain seperti Java dan WebAssembly.

Walau bagaimanapun, JIT mungkin terdedah kepada kod hasad yang direka untuk mengeksploitasi kelemahan proses JIT atau terlalu lambat untuk dijalankan dalam masa nyata semasa pelaksanaan. Reth akan menyusun kontrak yang paling mendesak sebelum masa (AOT) dan menyimpannya pada cakera, menghalang bytecode yang tidak dipercayai daripada cuba menyalahgunakan proses penyusunan kod asli kami semasa pelaksanaan langsung.

Kami telah membangunkan pengkompil JIT/AOT untuk Revm dan kini sedang mengintegrasikannya dengan Reth. Kami akan membuka sumbernya sebaik sahaja kami melengkapkan penanda aras dalam beberapa minggu akan datang. Secara purata, kira-kira 50% daripada masa pelaksanaan dibelanjakan dalam penterjemah EVM, jadi kira-kira 2x peningkatan dalam pelaksanaan EVM perlu diperlukan, tetapi dalam beberapa kes dengan permintaan pengiraan yang lebih besar, kesannya mungkin lebih besar. Dalam beberapa minggu akan datang, kami akan berkongsi penanda aras kami dan menyepadukan JIT EVM kami sendiri dalam Reth.

(2) Parallel EVM

Konsep Mesin Maya Parallel Ethereum (Parallel EVM) menyokong pemprosesan berbilang transaksi pada masa yang sama, yang berbeza daripada model pelaksanaan bersiri EVM tradisional. Kami mempunyai dua laluan berikut:

• Penyegerakan sejarah: Penyegerakan sejarah membolehkan kami mengira jadual selari yang terbaik dengan menganalisis transaksi sejarah dan mengenal pasti semua konflik keadaan sejarah.

• Penyegerakan masa nyata: Untuk penyegerakan masa nyata, kami boleh menggunakan teknologi seperti Block STM untuk melaksanakan pelaksanaan spekulatif tanpa sebarang maklumat tambahan (seperti senarai akses). Algoritma berprestasi lemah semasa tempoh perbalahan keadaan yang teruk, jadi kami ingin meneroka penukaran antara pelaksanaan bersiri dan selari berdasarkan keadaan beban kerja, serta meramalkan secara statik slot storan yang akan diakses untuk meningkatkan kualiti selari.

Menurut analisis sejarah kami, kira-kira 80% daripada slot storan Ethereum boleh diakses secara bebas, yang bermaksud bahawa selari boleh meningkatkan kecekapan pelaksanaan EVM sebanyak 5 kali ganda.

(3) Mengoptimumkan komitmen negeri

Dalam model Reth, pengiraan punca keadaan adalah proses yang bebas daripada melaksanakan transaksi, membenarkan penggunaan storan KV standard tanpa mendapatkan maklumat percubaan. Pada masa ini, ini mengambil masa >75% daripada masa hujung ke hujung untuk menutup blok, yang merupakan kawasan pengoptimuman yang sangat menarik.

Kami mengenal pasti dua "kemenangan mudah" berikut untuk meningkatkan prestasi akar negeri sebanyak 2-3x tanpa sebarang perubahan protokol:

• Sejajarkan sepenuhnya punca keadaan: kini kami hanya menyamakannya semula Kirakan pokok storan untuk akaun yang diubah, tetapi kita boleh melangkah lebih jauh dan mengira pepohon akaun secara selari sementara tugas akar storan selesai di latar belakang.

• Akar keadaan berpaip: Semasa pelaksanaan, nod trie perantaraan diambil dari cakera dengan memberitahu perkhidmatan akar keadaan slot dan akaun storan yang terlibat.

Selain itu, kita juga boleh meneroka beberapa laluan ke hadapan dengan menyimpang daripada aktiviti akar keadaan Ethereum L1:

• Pengiraan punca keadaan yang lebih kerap: tidak mengira punca keadaan pada setiap blok, tetapi setiap Blok T adalah dikira sekali. Ini mengurangkan jumlah masa yang dihabiskan untuk melabur dalam akar keadaan keseluruhan sistem, yang mungkin merupakan penyelesaian yang paling mudah dan paling berkesan.

• Jejaki punca keadaan: Daripada mengira punca keadaan pada blok yang sama, biarkan ia berada beberapa blok di belakang. Ini membolehkan pelaksanaan untuk maju tanpa menyekat pengiraan akar keadaan.

• Ganti pengekod RLP & Keccak256: Mungkin lebih murah untuk menggabungkan bait secara langsung dan menggunakan fungsi cincang yang lebih pantas seperti Blake3 daripada menggunakan pengekodan RLP.

• Ujian Lebih Luas: Tingkatkan N-arity nod anak pokok untuk mengurangkan peningkatan IO disebabkan oleh kedalaman logN trie.

Beberapa soalan di sini:

• Apakah kesan kedua daripada perubahan di atas pada pelanggan ringan, L2, jambatan, pemproses bersama dan protokol lain yang bergantung pada akaun yang kerap dan bukti penyimpanan?

• Bolehkah kita mengoptimumkan komitmen negeri untuk pembuktian SNARK dan kelajuan pelaksanaan asli pada masa yang sama?

• Apakah komitmen negeri yang paling luas yang boleh kita perolehi dengan alatan sedia ada kita? Apakah kesan sekunder pada saiz saksi?

Scale-out Roadmap for Reth 2.2

Kami akan melaksanakan banyak perkara di atas sepanjang 2024 untuk mencapai matlamat 1GB gas sesaat.

Walau bagaimanapun, penskalaan menegak akhirnya menghadapi batasan fizikal dan praktikal. Tiada mesin tunggal boleh mengendalikan keperluan pengkomputeran dunia. Kami percaya bahawa terdapat dua laluan di sini yang boleh menyokong kami untuk berkembang dengan memperkenalkan lebih banyak kotak selepas beban meningkat:

(1) Multiple Rollup Reth

Timbunan L2 hari ini perlu menjalankan pelbagai perkhidmatan untuk menjejak rantai: L1 CL, L1 EL, L1 -> fungsi terbitan L2 (mungkin digabungkan dengan L2 EL) dan L2 EL. Walaupun ini bagus untuk modulariti, perkara menjadi lebih rumit apabila menjalankan berbilang susunan nod. Bayangkan perlu menjalankan 100 rollups!

Kami mahu membenarkan rollup dikeluarkan serentak semasa Reth berkembang dan mengurangkan kos operasi menjalankan beribu-ribu rollup kepada hampir sifar.

Kami sedang mengusahakan perkara ini dalam projek Penskalaan Pelaksanaan kami, dengan lebih banyak lagi akan datang dalam beberapa minggu akan datang.

(2) Reth asli awan

Penyusun berprestasi tinggi mungkin mempunyai banyak permintaan pada satu rantai, ia perlu diskalakan dan satu mesin tidak dapat memenuhi keperluannya. Ini tidak boleh dilakukan dengan penggunaan nod tunggal hari ini.

Kami berharap dapat menyokong nod Reth asli awan yang sedang dijalankan, menggunakan ia sebagai tindanan perkhidmatan yang boleh menskala secara automatik berdasarkan keperluan pengkomputeran dan menggunakan storan objek awan yang kelihatan tidak terhad untuk storan berterusan. Ini adalah seni bina biasa dalam projek pangkalan data tanpa pelayan seperti NeonDB, CockroachDB atau Amazon Aurora.

3. Prospek masa depan

Kami berharap dapat melancarkan pelan hala tuju ini secara beransur-ansur kepada semua pengguna Reth. Misi kami adalah untuk menjadikan 1GB gas sesaat dan seterusnya tersedia kepada semua orang. Kami akan menguji pengoptimuman pada Reth AlphaNet dan kami berharap orang ramai akan menggunakan Reth sebagai SDK untuk membina nod berprestasi tinggi yang dioptimumkan.

Terdapat beberapa soalan yang kami belum temui jawapannya.

• Bagaimana Reth membantu meningkatkan prestasi keseluruhan ekosistem L2?

• Bagaimanakah kita mengukur dengan betul senario kes terburuk yang mungkin berlaku dengan beberapa pengoptimuman kita secara umum?

• Bagaimana kita menangani potensi perselisihan antara L1 dan L2?

Kami belum mempunyai jawapan kepada banyak soalan ini, tetapi kami mempunyai banyak idea awal yang menjanjikan yang akan membuatkan kami sibuk buat sementara waktu, dan kami berharap dapat melihat usaha ini membuahkan hasil dalam beberapa bulan akan datang.

Atas ialah kandungan terperinci Artikel yang menerangkan cara Ethereum Reth mencapai 1GB gas sesaat. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!