Kami mulai membangun Reth pada tahun 2022 untuk memberikan ketahanan pada Ethereum L1, dan menyelesaikan skalabilitas lapisan eksekusi di Layer 2.

Hari ini kami sangat senang untuk berbagi jalur Reth menuju 1 gigagas per detik di L2 pada tahun 2024, dan peta jalan jangka panjang kami untuk melampaui itu.

Kami mengundang ekosistem untuk berkolaborasi dengan kami saat kami mendorong batas kinerja dan benchmarking yang ketat dalam dunia kripto.

Apakah kita sudah diukur?

Ada jalan yang sangat sederhana bagi cryptocurrency untuk mencapai skala global dan menghindari spekulasi sebagai penggunaan utama: Transaksi perlu murah dan cepat.

Bagaimana Anda mengukur kinerja? Apa arti gas per detik?

Kinerja biasanya diukur dengan metrik 'Transaksi Per Detik' (TPS). Khususnya untuk Ethereum dan blockchain lainnya yang menggunakan EVM, ukuran yang lebih halus dan mungkin lebih akurat adalah 'gas per detik.' Metrik ini mencerminkan jumlah pekerjaan komputasi yang dapat ditangani oleh jaringan setiap detik, di mana 'gas' adalah satuan yang mengukur upaya komputasi yang diperlukan untuk mengeksekusi operasi seperti transaksi atau kontrak pintar.

Mengadopsi gas per detik sebagai metrik kinerja memungkinkan pemahaman yang lebih jelas tentang kapasitas dan efisiensi blockchain. Ini juga membantu dalam menilai implikasi biaya pada sistem, melindungi terhadap potensi serangan Denial of Service (DOS) yang bisa mengeksploitasi pengukuran yang kurang halus. Metrik ini membantu membandingkan kinerja di berbagai rantai yang kompatibel dengan Ethereum Virtual Machine (EVM).

Kami mengusulkan kepada komunitas EVM untuk mengadopsi gas per detik sebagai metrik standar, sekaligus menggabungkannya dimensi lain dari harga gasuntuk membuat standar kinerja komprehensif.

Dimana kita berada hari ini?

Gas per detik ditentukan dengan membagi penggunaan gas target per blok dengan waktu blok. Di sini, kami memperlihatkan throughput gas per detik dan laten gas saat ini di berbagai rantai EVM L1 dan L2 (tidak lengkap):

Kami menekankan gas per detik untuk menilai kinerja jaringan EVM secara menyeluruh, menangkap biaya komputasi dan penyimpanan. Jaringan seperti Solana, Sui, atau Aptos tidak termasuk karena model biaya yang berbeda. Kami mendorong upaya untuk menyelaraskan model biaya di semua jaringan blockchain untuk memungkinkan perbandingan yang komprehensif dan adil.

Kami sedang mengerjakan rangkaian pembandingan berkelanjutan untuk Reth yang mereplikasi beban kerja nyata, jika Anda ingin berkolaborasi dalam hal ini, silakan hubungi. Kami membutuhkan TPC Benchmarkuntuk node.

Bagaimana Reth akan mencapai 1 gigagas per detik? Melampaui itu?

Kami sebagian terdorong untuk membangun Reth pada tahun 2022 oleh kebutuhan mendesak untuk memiliki klien yang dibangun khusus untuk rollups skala web. Kami pikir kami memiliki jalan yang menjanjikan ke depan.

Reth sudah mencapai 100-200mgas/s selama sinkronisasi langsung (termasuk pemulihan pengirim, mengeksekusi transaksi, dan menghitung trie pada setiap blok); 10x dari sini membawa kami ke tujuan jangka pendek kami yaitu 1 gigagas/s.

Saat kami memajukan pengembangan Reth, rencana skalabilitas kami harus seimbang dengan efisiensi:

• Penskalaan Vertikal: Tujuan kami di sini adalah untuk memaksimalkan penggunaan setiap "kotak" hingga potensinya penuh. Dengan mengoptimalkan bagaimana setiap sistem individu menangani transaksi dan data, kami dapat sangat meningkatkan kinerja secara keseluruhan, sambil juga membuatnya lebih efisien untuk operator node individu.
• Penskalaan Horizontal: Meskipun telah dilakukan optimisasi, jumlah transaksi pada skala web melebihi kapasitas yang dapat ditangani oleh satu server tunggal. Untuk mengatasi hal ini, kami ingin menerapkan arsitektur skala horizontal, mirip dengan model Kubernetes untuk node blockchain. Ini berarti mendistribusikan beban kerja di beberapa sistem untuk memastikan tidak ada satu node pun yang menjadi bottleneck.

Optimisasi yang kami telusuri di sini tidak melibatkan penyelesaian pertumbuhan negara, yang sedang kami teliti secara terpisah.

Berikut ringkasan bagaimana kami bermaksud untuk mencapainya:

Di seluruh tumpukan, kami juga mengoptimalkan IO dan CPU menggunakan model aktor, untuk memungkinkan setiap bagian dari tumpukan untuk diterapkan sebagai layanan dengan kontrol yang baik atas penggunaannya. Terakhir, kami secara aktif mengevaluasi database alternatif, tetapi belum memutuskan kandidatnya.

Rencana peningkatan vertikal Reth

Tujuan kami di sini adalah memaksimalkan kinerja dan efisiensi dari satu server atau laptop yang menjalankan Reth.

EVM Just-In-Time & Ahead-of-Time

Di lingkungan blockchain seperti Mesin Virtual Ethereum (EVM), eksekusi bytecode terjadi melalui interpreter, yang secara berurutan memproses instruksi. Metode ini memperkenalkan overhead karena tidak menjalankan instruksi perakitan asli secara langsung, melainkan beroperasi melalui lapisan VM.

Kompilasi Just-In-Time (JIT) mengatasi hal ini dengan mengonversi bytecode menjadi kode mesin asli tepat sebelum eksekusi, sehingga meningkatkan kinerja dengan melewati proses interpretatif VM. Teknik ini, yang mengkompilasi kontrak menjadi kode mesin yang dioptimalkan sebelum waktunya, telah mapan di VM lain seperti Java dan WebAssembly.

Namun, JIT bisa rentan terhadap kode berbahaya yang dirancang untuk mengeksploitasi proses JIT, atau mungkin terlalu lambat untuk dijalankan secara langsung selama eksekusi. Reth akan mengompilasi Ahead-of-Time (AOT) kontrak dengan permintaan tertinggi dan menyimpannya di disk, untuk menghindari bytecode yang tidak dipercayai mencoba menyalahgunakan langkah kompilasi kode asli kami selama eksekusi langsung.

Kami telah bekerja pada compiler JIT/AOT untuk Revm, saat ini sedang diintegrasikan dengan Reth. Kami akan membuka sumber ini dalam beberapa minggu mendatang setelah pengujian kinerja selesai. Sekitar 50% waktu eksekusi dihabiskan di interpreter EVM rata-rata, sehingga ini harus memberikan peningkatan eksekusi EVM sekitar 2x, meskipun dalam beberapa kasus yang membutuhkan komputasi lebih berat, kemungkinan akan lebih berdampak. Kami akan membagikan pengujian kinerja dan integrasi JIT EVM kami sendiri di Reth dalam beberapa minggu mendatang.

Parallel EVM

Konsep Mesin Virtual Ethereum Paralel (Parallel EVM) memungkinkan pemrosesan transaksi simultan, berbeda dari model eksekusi serial tradisional dari EVM. Kami memiliki 2 pilihan di sini:

1. Sinkronisasi Historis: Dalam sinkronisasi historis, kita dapat menghitung jadwal paralelisasi terbaik yang memungkinkan dengan menganalisis transaksi masa lalu dan mengidentifikasi semua konflik status historis. Lihat upaya awal kami dalam cabang lama di Github.
2. Sinkronisasi Langsung: Untuk sinkronisasi langsung, kita dapat menggunakan Block STM-seperti teknik untuk melakukan eksekusi spekulatif tanpa informasi tambahan seperti daftar akses. Algoritma ini memiliki kinerja buruk selama periode kontensi state yang padat, jadi kami ingin menjelajahi beralih antara eksekusi serial dan paralel tergantung pada bentuk beban kerja, serta memprediksi secara statis slot penyimpanan mana yang akan diakses untuk meningkatkan kualitas paralelisme. Lihat satu PoC oleh tim pihak ke-3 di sini.

Berdasarkan analisis historis kami, ~80% slot penyimpanan Ethereum diakses secara independen, artinya paralelisme bisa menghasilkan peningkatan hingga 5x dalam eksekusi EVM.

Meningkatkan Komitmen Negara

Kami baru-baru ini menulis tentangdampak dari akar negara dalam kinerja dan perbedaan antara model database Reth dari klien lain, serta mengapa hal ini penting.

Dalam model Reth, menghitung root state adalah proses terpisah dari mengeksekusi transaksi (lihat kita kode), memungkinkan penggunaan toko KV standar yang tidak perlu tahu apa pun tentang trie. Saat ini, ini memakan lebih dari 75% dari waktu akhir untuk menutup blok, dan ini adalah area yang sangat menarik untuk dioptimalkan.

Kami mengidentifikasi 2 "kemenangan mudah" berikut yang dapat memberi kami 2-3x dalam kinerja root status, tanpa perubahan protokol apa pun:

1. Root State Paralel Penuh: Saat ini kami hanya menghitung ulang trie penyimpanan untuk akun yang berubah secara paralel, tetapi kami bisa lebih jauh dan juga menghitung trie akun secara paralel sambil pekerjaan root penyimpanan selesai di latar belakang.
2. Akar Status Pipelined: Pra-pengambilan simpul trie menengah dari disk selama eksekusi dengan memberi tahu layanan akar status tentang slot penyimpanan dan akun yang disentuh.

Melampaui itu, kami melihat beberapa jalan ke depan dengan menyimpang dari perilaku akar status Ethereum L1:

1. State Root yang lebih jarang: Alih-alih menghitung state root pada setiap blok, hitunglah setiap T blok. Hal ini mengurangi persentase waktu secara keseluruhan yang dihabiskan di state root dalam seluruh sistem dan bisa menjadi solusi yang paling mudah dan efektif.
2. Trailing State Root: Alih-alih harus menghitung state root pada blok yang sama, biarkan beberapa blok tertinggal. Hal ini memungkinkan eksekusi berlanjut tanpa terhambat oleh perhitungan state root.
3. Ganti Pemengkode RLP & Keccak256: Alih-alih melakukan encoding dengan RLP, mungkin lebih murah untuk hanya menggabungkan byte dan menggunakan fungsi hash yang lebih cepat seperti Blake3.
4. Trie Lebih Luas: Tingkatkan N-arity dari pohon, untuk mengurangi amplifikasi IO karena kedalaman logN dari trie.

Ada beberapa pertanyaan di sini:

1. Apa dampak orde kedua dari perubahan di atas terhadap klien ringan, L2s, jembatan, koprocesor, dan protokol lain yang mengandalkan bukti akun & penyimpanan yang sering?
2. Dapatkah kita mengoptimalkan komitmen negara untuk pembuktian SNARK dan kecepatan eksekusi asli secara bersamaan?
3. Apa komitmen negara terluas yang bisa kita dapatkan dengan alat yang tersedia untuk kita? Apa efek urutan kedua di sekitar ukuran saksi?

Rencana peningkatan skala horizontal Reth

Kami akan mengeksekusi beberapa poin di atas sepanjang tahun 2024 dan mencapai tujuan kami sebesar 1gigagas/detik.

Namun, penskalaan vertikal pada akhirnya akan menghadapi batasan fisik dan praktis. Tidak ada satu mesin pun yang dapat menangani kebutuhan komputasi dunia. Kami berpikir ada 2 jalur ke depan di sini, yang memungkinkan kami untuk melakukan penskalaan dengan memperkenalkan lebih banyak kotak saat beban yang lebih besar tiba:

Multi-Rollup Reth

Tumpukan L2 hari ini memerlukan menjalankan beberapa layanan untuk mengikuti rantai: L1 CL, L1 EL, fungsi derivasi L1 -> L2 (yang mungkin dikemas dengan L2 EL), dan L2 EL. Meskipun bagus untuk modularitas, ini menjadi rumit saat menjalankan tumpukan node yang berbeda. Bayangkan harus menjalankan 100 rollups!

Kami ingin memungkinkan peluncuran rollups dalam proses yang sama dengan Reth dan mengurangi biaya operasional dari menjalankan ribuan rollups hampir menjadi nol.

Kami sudah mulai dengan ini dengan Proyek Ekstensi Eksekusi([1], [2]) , lebih banyak dalam beberapa minggu mendatang di sini.

Cloud-native Reth

Sequencer kinerja tinggi mungkin memiliki permintaan yang cukup besar pada satu rantai sehingga mereka perlu diperluas ke luar dari satu mesin. Ini tidak mungkin dilakukan dalam implementasi node monolitik saat ini.

Kami ingin memungkinkan menjalankan node Reth Cloud-native, diterapkan sebagai tumpukan layanan yang dapat otomatis skalabilitas dengan permintaan komputasi dan menggunakan penyimpanan objek cloud yang tampaknya tak terbatas untuk ketahanan. Ini adalah arsitektur umum dalam proyek database serverless seperti NeonDB, CockroachDB, atau Amazon Aurora.

Lihat pemikiran awaldari tim kami tentang beberapa cara yang dapat kita lakukan untuk mengatasi masalah ini.

Tinjauan

Kami bermaksud untuk secara bertahap meluncurkan peta jalan ini ke semua pengguna Reth. Misi kami adalah memberikan akses kepada semua orang ke 1 gigagas/s dan di atasnya. Kami akan menguji optimisasi kami di Reth AlphaNet, dan kami berharap orang-orang akan membangun node kinerja tinggi yang dimodifikasi menggunakan Reth sebagai SDK.

Ada beberapa pertanyaan yang belum kita dapatkan jawabannya.

• Bagaimana Reth dapat membantu meningkatkan kinerja di seluruh ekosistem L2?
• Bagaimana kita mengukur skenario terburuk dengan tepat ketika beberapa optimasi kita mungkin untuk kasus rata-rata?
• Bagaimana kita mengelola ketegangan antara L1 dan L2 yang berpotensi berbeda?

Kami tidak memiliki jawaban untuk banyak pertanyaan ini, tetapi kami memiliki cukup petunjuk awal yang menjanjikan untuk membuat kami sibuk untuk sementara waktu dan berharap melihat upaya-upaya ini membuahkan hasil dalam beberapa bulan mendatang.

Penolakan:

1. Artikel ini dicetak ulang dari [paradigma], Semua hak cipta milik penulis asli [Georgios Konstantopoulos]. Jika ada keberatan terhadap cetak ulang ini, harap hubungi Belajar Gatetim, dan mereka akan menanganinya dengan segera.
2. Penafian Tanggung Jawab: Pandangan dan opini yang terdapat dalam artikel ini semata-mata milik penulis dan tidak merupakan nasihat investasi apa pun.
3. Terjemahan artikel ke dalam bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel yang diterjemahkan dilarang.