Diteruskan Judul Asli: Desainer Blockspace: Masa Depan Lingkungan Eksekusi

Dalam sembilan tahun sejak Ethereum meluncurkan blockchain terdesentralisasi dan dapat diprogram pertama, kripto telah menghadapi berbagai rintangan dalam upaya untuk memperluas aplikasi terdesentralisasi untuk miliaran pengguna. Dan untuk mengembangkan solusi penskalaan untuk mengatasi hal ini, industri kripto terus mendanai dan mengembangkan jenis-jenis blockchain baru sepenuhnya untuk memecahkan 'masalah kinerja'.

Namun, "masalah kinerja" telah didefinisikan dan diukur dengan buruk. Meme sintetis seperti "transaksi per detik" telah mengemas dengan rapi apa yang sebenarnya perbandingan apel-ke-jeruk antara transaksi yang tidak memerlukan pekerjaan komputasi yang setara. Kurangnya nuansa dalam metrik ini juga menyelimuti kemampuan kami untuk menilai dampak independen dari komponen blockchain pada kinerja, mengalihkan perhatian kami dari pendekatan berprinsip untuk mengidentifikasi set pengoptimalan yang dapat kami lakukan untuk memecahkan masalah yang sangat saling bergantung.

Meskipun kabut ini, kami telah melihat peningkatan skala blockchain yang kredibel dan berkelanjutan terjadi selama beberapa tahun terakhir. Saat Ethereum melalui peta jalan yang berpusat pada rollup-nya, gelombang baru rollup, coprocessor,ketersediaan data(DA) lapisan, dan L1 yang bersaing muncul - masing-masing dengan pilihan desain unik untuk memberikan lingkungan yang lebih performa kepada pengembang untuk membangun dapps yang dapat diskalakan dan ramah pengguna.

Hari ini, pengenalan EIP4844 dan lapisan DA alternatif telah meredakan bottleneck DA yang kritis. Meskipun pencapaian penting ini, bukti menunjukkan bahwa bottleneck penting lainnya harus diatasi. Bulan lalu, Dasarmengumpulkan$1.57 juta dalam biaya transaksi dalam satu harisaat membayar hanya $5K dalam biaya ketersediaan data ke Ethereum. Hal ini menunjukkan bahwa pekerjaan komputasi yang diperlukan untuk memvalidasi dan memproses pembaruan status tetap menjadi hambatan kritis dan peluang untuk perbaikan.

Potongan ini akan mengevaluasi pilihan desain yang dibuat oleh lingkungan eksekusi terintegrasi dan modular dalam perjalanannya untuk memecahkan masalah kinerja yang lebih tinggi dan memperluas cakupan aplikasi yang dapat berada di onchain.

Tantangan Hari Ini

Kinerja lapisan eksekusi dapat diuji coba berdasarkan pekerjaan komputasi yang dicapai oleh node-node yang mengeksekusi relatif terhadap waktu blok rantai mereka, atau "gas yang dihitung per detik."

Dengan ini diingat, kita dapat menyempitkan bottleneck lapisan eksekusi menjadi dua faktor yang saling terhubung: akses keadaan yang tidak efisien dan komputasi yang tidak efisien.

Akses keadaan yang tidak efisien merujuk pada beban dari pengambilan dan pembaruan keadaan blockchain, yang dapat memperlambat pemrosesan transaksi. Di sisi lain, komputasi yang tidak efisien adalah fungsi dari beban yang ditimbulkan oleh algoritma yang mengeksekusi operasi dan transisi keadaan, yang dapat mencakup segalanya mulai dari transfer sederhana hingga kontrak pintar kompleks dan verifikasi tanda tangan.

Bottleneck-bottleneck ini saling memperkuat satu sama lain—keterlambatan dalam akses keadaan dapat memperpanjang waktu komputasi, sementara praktik komputasi yang tidak efisien dapat membebani manajemen keadaan. Selain itu, perbaikan yang diusulkan untuk mengatasi masalah-masalah ini seringkali memerlukan perbaikan sistemik seperti sharding atau mengadopsi arsitektur tanpa keadaan, yang meningkatkan akses keadaan dan efisiensi komputasi untuk meningkatkan kinerja eksekusi.

Bottleneck #1: Akses Keadaan yang Tidak Efisien

Biaya dan kecepatan yang diperlukan untuk mengakses keadaan blockchain adalah bottleneck kritis untuk lingkungan eksekusi yang performa dan dapat diuraikan menjadi masalah pembengkakan keadaan.

Dalam blockchain, keadaan dunia dikelola dan diperbarui melalui struktur data khusus yang disebut pohonPohon-pohon sangat penting bagi blockchain, menyediakan cara yang aman dan efisien untuk memberikan jaminan kepada pihak-pihak eksternal terkait keadaan yang benar dari blockchain yang sedang dieksekusi. Setiap pembaruan dalam sebuah trie menghasilkan hash root baru, yang dapat diacu oleh klien-klien ringan untuk memverifikasi transaksi dan saldo akun tanpa harus mempertahankan seluruh rantai.

Ethereum khususnya bergantung pada struktur data yang dikenal sebagai trie Patricia Merkle (MPT), yang terdiri dari@chiqing/merkle-patricia-trie-dijelaskan-ae3ac6a7e123">empat sub-tries.

Ketika Ethereum menambahkan lebih banyak kontrak pintar dan token ke dalam statusnya, trie statusnya menjadi lebih besar dan lebih kompleks. Seiring dengan pertumbuhan status, diperlukan lebih banyak ruang penyimpanan, sumber daya komputasi lebih banyak untuk diproses, dan bandwidth lebih banyak untuk ditransmisikan. Pada saat yang sama, kendala perangkat keras node tetap sekitar sama.

Pertumbuhan negara ini secara langsung memengaruhi kinerja Ethereum karena negara disimpan di disk, dan operasi disk menimbulkan overhead yang tinggi. Sementara mengakses data dari register CPU membutuhkan waktu 0.1 nanodetik, bisa memakan waktu antara 10 dan 100 mikrodetik (100x–1000x lebih lambat)untuk mengakses data dari disk, secara kasar diterjemahkan menjadi 200.000 instruksi CPU yang bisa dieksekusi dalam waktu tersebut. Itu setara dengan perkiraan konservatif dari 36 transfer ERC-20 yang bisa dilakukan!

Memperburuk masalah ini, blockchain memiliki banyak pola akses yang tidak efisien untuk membaca dan menulis ke dalam status. Sebagai contoh, struktur non-urut dari trie Merkle Patricia secara inheren mengakibatkan operasi masukan/keluaran (I/O) disk membaca dari dan menulis ke berbagai lokasi yang tidak terduga pada disk. Sifat acak dari masukan transaksi dan perubahan status yang kemudian mereka picu mengakibatkan pola akses data yang tersebar yang secara signifikan memperlambat proses verifikasi dan pembaruan status dan hanya memanfaatkan sebagian dari sebuahkapasitas perangkat keras.

Secara keseluruhan, primitif manajemen negara untuk blockchain masih jauh dari mencapai potensi absolutnya, dan banyak kemajuan dapat dilakukan untuk meningkatkan efisiensi komputasi.

Bottleneck #2: Komputasi yang Tidak Efisien

Lapisan eksekusi juga menghadapi bottleneck komputasi yang tidak efisien, yang muncul dalam berbagai cara.

Untuk satu, banyak proses transaksi secara berurutan, tidak memanfaatkan prosesor multi-core modern yang mampu menangani beberapa operasi secara bersamaan. Eksekusi berurutan ini menyebabkan waktu tidak aktif CPU yang tak terhindarkan di antara transaksi, menyia-nyiakan sumber daya komputasi berharga.

Selain itu, menggunakan mesin virtual melibatkan menerjemahkan operasi kontrak pintar tingkat tinggi menjadi bytecode—kode tingkat rendah yang independen platform—yang kemudian dieksekusi instruksi demi instruksi. Proses terjemahan dan eksekusi ini memperkenalkan beban yang signifikan, terutama untuk aplikasi dengan tugas aplikasi yang kompleks dan sering diulang.

Ketidaksempurnaan ini menyebabkan penggunaan sumber daya komputasi yang kurang optimal dan menghambat kinerja lapisan eksekusi.

Solusi: Akses Keadaan yang Tidak Efisien

Ada beberapa cara berbeda yang tim gunakan untuk meningkatkan kecepatan dalam mengambil dan memperbarui status dari perangkat keras node yang sedang dieksekusi, termasuk menyederhanakan struktur data kompleks dan menemukan cara untuk mengurangi operasi disk yang mahal yang menyebabkan pembengkakan status.

Statelessness & In-Memory Computing

Beberapa lapisan eksekusi mengatasi pembengkakan status dengan hanya menerimanya dalam jangka pendek. Mereka memindahkan penyimpanan data status dari sistem berbasis disk yang lebih lambat ke memori akses acak (RAM) yang lebih cepat. Mengakses informasi status di RAM secara signifikan mengurangi overhead yang terkait dengan operasi disk, yang lebih lambat dan lebih intensif sumber daya.

Namun, pendekatan ini menantang prinsip inti desentralisasi. Menyimpan jumlah data status yang semakin besar di RAM memerlukan perangkat keras yang lebih canggih dan mahal, yang dapat membatasi kemampuan individu untuk berpartisipasi sebagai operator node. Oleh karena itu, seiring dengan meningkatnya persyaratan perangkat keras, semakin sedikit entitas yang mampu menjalankan node-node ini.

Untuk menyeimbangkan daya tarik komputasi di memori dengan minimasi kepercayaan, baik L1s (seperti Ethereum) maupun L2s mengejar peta jalan skalabilitas yang bergantung pada memisahkan peran validator menjadi node pelaksana terpusat terpisah dengan banyak node verifikasi. Dalam model ini, produsen blok yang sangat performan dengan persyaratan perangkat keras untuk menghitung di memori bertanggung jawab untuk menghasilkan blok, dan bukti kriptografis (bukti penipuan dan keabsahan) dimanfaatkan oleh node verifikasi untuk mempertanggungjawabkan produsen blok.

Sebagai hasilnya, sistem-sistem ini seharusnya memungkinkan produsen blok untuk memaksimalkan kecepatan mereka karena dapat diharapkan untuk menghitung di memori, menghilangkan I/O disk sepenuhnya selama eksekusi. Karena laten RAM biasanya di bawah 100 nanodetik, laten akses keadaan dikurangi hingga 1000x relatif terhadap implementasi berbasis disk.

Secara paralel, bukti kecurangan dan validitas digunakan sebagai pengganti konsensus terdesentralisasi untuk meningkatkan sifat trust-minimization sistem beserta throughput-nya. Sebagai hasilnya, node penghasil blok terpusat yang kuat seimbang dengan node verifikasi yang dapat dijalankan pada perangkat keras yang jauh lebih murah. Node-node ini melakukan fungsi kritis dari memverifikasi bukti transisi status secara independen (atau transisi status tidak valid) untuk mempertahankan pandangan yang akurat dari status tanpa beban penyimpanan seluruh status blockchain.

Untuk memfasilitasi proses ini dengan mode minimalkan kepercayaan, lapisan pelaksanaan harus menerapkan tingkatstatelessness, yang paling populer adalah konsep dari “kelemahan tanpa negara.” Kelemahan tanpa negara dicapai dengan mewajibkan produsen blok untuk memberikan suatu penegasan kriptografis yang dikenal sebagai sebuah saksike sebuah node verifikasi. Saksi ini menggabungkan semua perubahan status yang diusulkan oleh blok baru, memungkinkan validator untuk memverifikasi perubahan tersebut tanpa data historis tambahan.

Meskipun konsep ini dapat diterapkan menggunakan berbagai struktur pohon, pohon Verkle seringkali lebih disukai daripada pohon Merkle karena efisiensinya. Pohon Merkle memerlukan inklusi dari semua hash simpul saudara sepanjang jalur dari titik data (daun) ke akar pohon untuk membuktikan integritas data. Persyaratan ini berarti bahwa ukuran saksi (bukti integritas) tumbuh seiring dengan tinggi pohon, karena setiap tingkat memerlukan hash tambahan. Akibatnya, memverifikasi integritas data dalam pohon Merkle menjadi intensif secara komputasi dan mahal, terutama untuk kumpulan data besar. Sebaliknya, pohon Verkle menyederhanakan proses ini, mengurangi beban yang terkait dengan komputasi dan penyimpanan dalam menghasilkan dan memverifikasi blok-blok baru.

Verkle tree scaling dari 'Verkle Tree' Ethereum yang Inevitable

Pohon Verkle meningkatkan struktur pohon Merkle tradisional dengan menyederhanakan hubungan antara daun dan akar dan menghilangkan kebutuhan untuk menyertakan node saudara dalam proses verifikasi. Dalam pohon Verkle, memverifikasi bukti melibatkan hanya nilai di node daun, komitmen terhadap node akar, dan komitmen vektor tunggal berdasarkan komitmen polinomial, yang menggantikan komitmen berbasis hash ganda yang ditemukan di pohon Merkle. Perubahan ini memungkinkan pohon Verkle untuk mempertahankan saksi berukuran tetap, yang tidak meningkat dengan tinggi pohon atau jumlah daun yang diverifikasi, secara signifikan meningkatkan efisiensi penyimpanan dan komputasi selama verifikasi data.

Selama beberapa tahun mendatang, kita akan melihat implementasi tanpa keadaan terjadi pada tingkat L1 dan L2 dengan konfigurasi yang bervariasi. Menurut peta jalan Ethereum terbaru, para validator dapat mengandalkan pembangun blok untuk menyediakan bukti Verkle mengenai keadaan blok tertentu dan memverifikasi bukti ringan ini daripada memelihara keadaan Ethereum secara langsung.

Pada level L2, tim seperti MegaETHsedang menerapkan konsep tanpa keadaan ke desain optimistic rollups. Dalam desain mereka, node sequencer menghasilkan saksi untuk setiap blok yang berisi nilai-nilai keadaan yang diperlukan dan hash-hasil perantara sambil mengeluarkan delta keadaan yang mewakili perubahan dalam keadaan. Node verifikasi kemudian dapat menjalankan ulang blok apa pun dengan mengambil saksi dari lapisan DA atau jaringan peer-to-peer tanpa menyimpan seluruh keadaan. Secara paralel, node lengkap memperbarui keadaan mereka dengan menerapkan delta keadaan yang disebarkan melalui jaringan, memungkinkan mereka tetap disinkronkan tanpa menjalankan ulang transaksi atau menyimpan seluruh riwayat keadaan.

Namun, juga perlu dicatat bahwa manfaat ketiadaan status dan kemampuan komputasi dalam memori bukanlah solusi ajaib untuk kinerja lapisan eksekusi.

TPS real-time dari “Understanding Ethereum Execution Layer Performance” MegaETH

Sebagai salah satu pendiri MegaETH, Yilong Li, mengidentifikasi dalam hal berikutpresentasi penelitianpada eksekusi Ethereum, ada ketidaksempurnaan lain pada struktur data dan pola akses onchain yang tetap dioptimalkan.

Meningkatkan Basis Data

Tim yang bekerja pada lapisan eksekusi sedang mencari cara untuk meningkatkan struktur basis data ini sendiri untuk menghilangkan beberapa bottleneck yang dialami oleh Ethereum dan blockchain lain yang kompatibel dengan EVM dalam menangani akses state yang tidak efisien, yang memiliki efek domino pada efisiensi komputasi.

Sebenarnya, keterbatasan desain database yang ada yang ditemukan dalam EVM memberi informasiMonad’s* keputusan untuk melampaui hanya mengoptimalkan efisiensi komputasi untuk mencapai paralelisasi. Monad menemukan bahwa bahkan setelah mengimplementasikan eksekusi paralel, mereka hanya melihat peningkatan kecepatan kecil dalam kinerja karena permintaan baca-tulis multithreaded ke database saling memblokir satu sama lain. Sebagai hasilnya, Monad mengimplementasikan database yang kompatibel dengan asynchronous IO (AIO), atau akses paralel, sebagai bagian penting dari solusi.

Async I/O

Operasi I/O—seperti membaca dari atau menulis ke perangkat penyimpanan—seringkali menciptakan bottleneck, terutama dengan hard disk drive mekanik (HDD). Drive-drive ini memerlukan pergerakan fisik dari kepala baca/tulis untuk mengakses data, yang dapat secara signifikan melambatkan pemrosesan data.

AIO mengatasi tantangan ini dengan memungkinkan program untuk melakukan operasi I/O secara bersamaan dengan proses lain. Pada dasarnya, sebuah program dapat memulai operasi I/O dan melanjutkan tanpa harus menunggu operasi tersebut selesai. Hal ini dilakukan dengan mendaftarkan fungsi panggilan balik atau sebuah janji bahwa sistem operasi atau perpustakaan I/O akan penuhi setelah operasi I/O selesai. Pendekatan ini secara asinkron memungkinkan program utama untuk terus melaksanakan tugas-tugas lain, meningkatkan efisiensi secara keseluruhan dengan tidak terhenti untuk menunggu tugas-tugas I/O selesai.

I/O Asynchronous dapat diimplementasikan dengan baik HDD tradisional maupun solid-state drive (SSD), meskipun manfaatnya lebih terasa dengan SSD. HDD dapat melakukan AIO, tetapi sifat mekanikalnya berarti HDD secara inheren lebih lambat dibandingkan SSD yang menyimpan data pada memori flash dan tidak memiliki bagian yang bergerak, sehingga menghasilkan waktu akses yang lebih cepat.

Sebagai contoh, Monad menggunakan backend state kustom yang dioptimalkan untuk penyimpanan SSD, yang mendukung tingkat pemrosesan data paralel yang tinggi dan mengurangi laten I/O. Pengaturan ini lebih efisien daripada sistem yang hanya mengandalkan penyimpanan berbasis disk tradisional atau yang menggunakan basis data di memori, yang mungkin masih mengalami penundaan dari seringnya penulisan dan pembacaan data dari media penyimpanan yang lebih lambat.

Demikian pula, Reth menggunakan metode yang memisahkan operasi database dari mesin eksekusi inti EVM. Penyiapan ini memungkinkan bytecode EVM untuk dieksekusi secara berurutan pada satu utas saja untuk menjaga konsistensi sementara tugas I/O database dipindahkan ke proses-paralel. Reth menggunakan model aktor—suatu pola arsitektur perangkat lunak—untuk mengelola proses-paralel ini secara efektif, memastikan bahwa operasi I/O tidak mengganggu penerjemah EVM.

Frekuensi Merklisasi State

Vektor lain untuk optimisasi adalah frekuensi merklisasi status. Model saat ini dari Ethereum merklisisasi status setelah setiap blok memperkenalkan overhead yang signifikan, memerlukan penulisan dan pembacaan yang sering dari disk dan penyeberangan trie yang kontinu. Pohon Merkle biasanya bekerja dengan mengelompokkan hash-hashing intermediate ke dalam set 16 (disebut node) dan menyimpannya dalam database toko kunci-nilai di mana kunci adalah hash node dan nilai adalah node itu sendiri.

Mentransversalkan pohon ini untuk menemukan dan memperbarui data memerlukan satu akses disk acak untuk setiap lapisan pohon yang akan dilalui, dan menelusuri pohon Merkle yang naif akan membutuhkan kira-kiradelapan kueri database berurutan per entri.

Pendekatan Solana dalam memperbarui komitmen status hanya pada akhir setiap epoch memungkinkan untuk mengamortisasi biaya penulisan selama banyak transaksi dalam periode tersebut. Jika entri status dimodifikasi beberapa kali dalam satu epoch yang sama, setiap penulisan tidak memerlukan pembaruan langsung ke Merkle root. Hal ini mengurangi overhead komputasi keseluruhan yang terkait dengan pembaruan status selama epoch. Akibatnya, biaya yang terkait dengan membaca dari status tetap konstan, atau O(1), karena status dapat dibaca langsung tanpa perlu menelusuri jalur Merkle setiap kali.

Mengurangi frekuensi merklisasi di Ethereum dapat mengurangi overhead dari pembacaan dan penulisan status, meningkatkan kinerja. Namun, klien ringan perlu memutar ulang perubahan blok untuk melacak status antara epoch atau mengirimkan transaksi onchain untuk verifikasi status, dan perubahan tersebut saat ini tidak kompatibel dengan Ethereum.

Struktur Data yang Efisien & Khusus

Selain itu, struktur pohon berlapis dalam klien Ethereum yang ada umumnya menyebabkan pola akses keadaan yang tidak efisien, yang lebih lanjut menyumbang pada pembengkakan keadaan. Sementara keadaan Ethereum terstruktur sebagai MPT, kemudian disimpan dalam basis data klien Ethereum seperti LevelDB,PebbleDB(digunakan oleh go-ethereum), atau MDBX (digunakan oleh Erigon) yang menyimpan data dalam pohon Merkle seperti sebuah Pohon BatauLSM-Tree.

Dalam pengaturan ini, sebuah struktur data ditanamkan ke dalam struktur data lain dari jenis yang terpisah, menciptakan “penguatan bacaan” dari menavigasi struktur pohon internal di atas klien yang beroperasi di bawah sistem berbasis pohon Merkle lainnya. Penguatan bacaan dapat dipahami sebagai hasil dari langkah-langkah multiple untuk mengakses atau memperbarui informasi yang terkandung dalam suatu keadaan, yang memerlukan navigasi pohon luar untuk menemukan titik masuk ke dalam MPT sebelum menjalankan operasi yang diperlukan. Akibatnya, jumlah akses disk untuk baca acak dikalikan dengan faktor log(n).

Untuk mengatasi hal ini, Monad secara alami memanfaatkan struktur data Patricia trie pada disk dan dalam memori. Dari perspektif teknis, Patricia trie seringkali lebih unggul daripada struktur pohon Merkle lainnya karena kombinasi uniknya dari efisiensi ruang, pencocokan awalan yang efisien, dan traversing simpul minimal. Desain trie menggabungkan simpul dengan anak tunggal dan menyederhanakan pencarian, penyisipan, dan penghapusan, mengurangi jumlah operasi I/O disk atau jaringan yang diperlukan. Selain itu, keahlian Patricia trie dalam menangani pencocokan awalan meningkatkan kinerja dalam aplikasi yang membutuhkan pencarian kunci parsial yang cepat.

Bottleneck lain yang khusus untuk struktur berbasis pohon adalah bahwa mengakses atau memperbarui data memerlukan penelusuran melalui beberapa lapisan, yang mengakibatkan banyak akses disk sekuensial.Sovereign Labsmengatasi ketidak efisienan ini dengan menganjurkan konfigurasi pohon Merkle biner. Pergeseran penting ke struktur biner ini secara drastis mengurangi jumlah lintasan potensial selama penelusuran pohon, secara langsung mengurangi perhitungan hash yang diperlukan untuk pembaruan, penyisipan, dan bukti kriptografis.

Konfigurasi pohon Merkle biner dari "Merkelisasi Keadaan Hampir Optimal" Sovereign Labs

Contoh tambahan dalam kategori ini adalah tim Reth mengkonfigurasi Reth untukmengambil simpul trie intermediate dari disk selama eksekusidengan memberitahukan layanan akar negara tentang slot penyimpanan dan akun yang terkena.

Kedaluwarsa Negara

Kadaluwarsa status adalah mekanisme untuk mengelola dan mengurangi ukuran status blockchain dengan menghapus data yang tidak diakses selama jangka waktu tertentu. Meskipun kadaluwarsa seringkali dikategorikan dalam kategori "tanpa status", sangat penting untuk membedakan konsep-konsep ini dalam konteks eksekusi.

Tanpa keadaan meningkatkan eksekusi dengan meningkatkan kemampuan node yang menjalankan untuk menghitung dalam memori, tetapi peningkatan eksekusi berasal dari persyaratan perangkat keras yang lebih kuat di sejumlah node yang menjalankan transaksi. Sebaliknya, kadaluarsa keadaan dapat diterapkan pada blockchain dengan sedikit maupun banyak node yang menjalankan.

Ada beberapa metode yang umum dibahas untuk mengimplementasikan kedaluwarsa negara:

• Kedaluwarsa oleh Sewa: Metode ini melibatkan pengisian biaya pemeliharaan, atau "sewa," untuk menjaga akun tetap aktif dalam database negara. Jika sewa tidak dibayar, akun akan diarsipkan sampai biaya dibayarkan untuk memulihkannya.
• Kadaluarsa oleh Waktu: Di sini, akun dianggap tidak aktif jika tidak diakses—artinya tidak ada transaksi atau interaksi—selama durasi tertentu.

Kedua metode tersebut bertujuan untuk menjaga hanya data yang digunakan secara aktif dalam keadaan segera dan dapat diakses sementara mendorong data yang lebih lama dan jarang diakses ke dalam keadaan terarsip yang tidak membebani sistem utama.

Dengan mempertahankan keadaan yang lebih kecil dan lebih mudah dikelola, kedaluwarsa negara mengurangi "negara mengasapi" yang dapat sangat menghambat kinerja blockchain. Ukuran state yang lebih kecil memungkinkan node untuk menavigasi dan memperbarui state dengan cepat, diterjemahkan ke eksekusi yang lebih cepat karena node menghabiskan lebih sedikit waktu pemindaian dan lebih banyak waktu pemrosesan.

Eksekusi Sharding

Sharding mengoptimalkan pemanfaatan sumber daya dan kinerja dengan mendistribusikan tugas dan data di sejumlah node khusus (tidak setiap node menjalankan status global).

Dalam arsitektur blockchain yang di-shard, status global dibagi menjadi partisi yang berbeda yang disebut shard. Setiap shard mempertahankan bagian dari status dan bertanggung jawab untuk memproses subset transaksi jaringan. Transaksi ditugaskan ke shard tertentu berdasarkan fungsi sharding deterministik, yang mempertimbangkan berbagai faktor seperti alamat pengirim, alamat penerima, dan hash data transaksi. Hal ini meminimalkan kebutuhan komunikasi lintas shard dan memungkinkan eksekusi transaksi yang lebih efisien.

Diagram Sharding dari "Batasan Skalabilitas Blockchain" oleh Vitalik

Hal ini menjadi jelas saat menjelajahi NEAR Protocol’sdesain sharding,Nightshade, yang mencapai tanpa keadaan untuk penskalaan sharding tanpa mengorbankan minimasi kepercayaan.

Di Nightshade, blockchain terstruktur sebagai rantai logis tunggal, dengan setiap blok terdiri dari beberapa 'chunk' dan satu chunk dialokasikan per shard. 'Chunk' ini berisi transaksi dan transisi state yang spesifik untuk setiap shard. Memasukkan chunk dari semua shard dalam satu blok memungkinkan untuk melihat keseluruhan status blockchain secara bersatu dan menyederhanakan proses komunikasi lintas shard.

Sama seperti pemisahan pembangun yang benar (PBS) di Ethereum, Nightshade dengan tegas membedakan peran dari node-stateful dan stateless. Di NEAR, validator-stateful ditugaskan ke shard tertentu dan bertanggung jawab untuk mengumpulkan transaksi, menjalankannya, dan memproduksi chunk khusus-shard. Mereka memelihara seluruh status dari shard yang ditugaskan dan menghasilkan saksi status untuk validator digunakan selama proses validasi.

Sementara itu, validator tidak berkebangsaan secara acak ditugaskan untuk memvalidasi shard-spesifik pada basis per blok. Mereka tidak perlu mempertahankan status yang ter-sharded sepenuhnya dan mengandalkan saksi status yang disediakan oleh produsen blok dari shard lain untuk memvalidasi transisi status dan transaksi dalam sebuah chunk. Penugasan acak validator ke shard membantu menjamin keamanan dan integritas jaringan, karena hal ini membuat lebih sulit bagi pelaku jahat untuk berkolusi dan mengontrol shard tertentu.

Karena setiap node dalam jaringan hanya perlu menangani data untuk shard masing-masing daripada seluruh data jaringan, beban penyimpanan dan komputasi pada node individu berkurang.

Solusi: Komputasi yang Tidak Efisien

Eksekusi Paralel

Saatnya mengatasi masalah yang besar: paralelisasi. Paralelisasi eksekusi transaksi memungkinkan pemrosesan beberapa transaksi dengan menggunakan sumber daya komputasi secara bersamaan. Hal ini memungkinkan peningkatan throughput karena sumber daya hardware ditingkatkan selama periode permintaan tinggi.

Namun, penting untuk mempertimbangkan bahwa komponen eksekusi ganda dapat diparalelkan, banyak di antaranya diimplementasikan oleh coprocessors seperti Lagrange* dan klien blockchain alternatif seperti Firedanceruntuk meningkatkan kinerja blockchain secara signifikan. Secara khusus, paralelisasi dapat melibatkan:

• Akses Keadaan Paralel
• Mengparalleling Operasi Tertentu
• Paralelkan Konsensus dan Eksekusi

Menggandakan Akses Negara

Mempercepat akses keadaanmenghadirkan dua manfaat krusial:

• EVM paralel mendistribusikan pemrosesan transaksi di beberapa inti CPU. Pengaturan ini memungkinkan beberapa transaksi ditangani secara bersamaan daripada memaksa mereka antri untuk sumber daya tunggal.
• Ketika transaksi menunggu data dari penyimpanan—yang dapat memperkenalkan latensi yang signifikan—sistem tidak tetap menganggur. Sebaliknya, sistem dapat beralih ke transaksi lain yang siap dieksekusi. Hal ini memungkinkan karena beberapa core dapat menangani tugas yang berbeda secara independen dan simultan.

Tantangan utama dalam memparallelkan eksekusi transaksi berasal dari mengelola akses konkuren ke status global bersama tanpa melanggar ASAMaturan untuk memperbarui sistem terdistribusi. Jika blockchain memiliki sekelompok transaksi yang dieksekusi secara paralel, beberapa di antaranya akan bertentangan. Sebagai hasilnya, dua metodologi utama untuk memparallelkan akses keadaan berbeda dalam hal saat mereka mengalokasikan sumber daya untuk menyelesaikan konflik: model eksekusi pesimis (atau kunci memori) dan model eksekusi optimis.

Eksekusi Pesimis

Model eksekusi pesimis adalah pendekatan pemrosesan transaksi yang memerlukan transaksi untuk mendeklarasikan variabel status yang akan diakses (baca atau tulis) selama eksekusi. Informasi ini disertakan dalam metadata transaksi, memungkinkan runtime untuk menganalisis pola akses sebelum eksekusi.

Dengan memeriksa pola akses baca-tulis, runtime dapat mengidentifikasi transaksi dengan set akses yang tidak tumpang tindih, memungkinkan eksekusi paralel transaksi yang tidak tumpang tindih dan hanya baca, serta meningkatkan throughput. Runtime membuat antrian transaksi paralel untuk setiap utas CPU pada node validator, memastikan bahwa transaksi dengan pola akses yang tidak bertentangan diproses secara bersamaan.

Sebagai hasil dari pilihan desain ini, model eksekusi pesimis mendapat manfaat dari kontrol yang sangat halus terhadap alokasi sumber daya, memungkinkan untuk membagi atau mempartisi ruang keadaan blockchain.

Paralelisasi efektif menciptakan beberapa shard eksekusi independen secara sinkron yang didukung oleh model keamanan yang terpadu. Ini membantu mengatasi kemacetan jaringan dan mengoptimalkan biaya gas melalui manajemen sumber daya yang tepat dan pasar biaya dinamis. Dengan mengidentifikasi 'hotspot' akses ke state (area dengan permintaan transaksional tinggi), sistem dapat menerapkan optimisasi yang ditargetkan seperti penetapan harga biaya yang berbeda, pembatasan laju, atau mengalokasikan sumber daya tambahan ke state kontens tinggi. Penting untuk dicatat bahwa implementasi paralelisasi Solana saat ini tidak sepenuhnya menyadari potensi pasar biaya lokal.

Untuk memastikan konsistensi data dalam akses bersamaan, model eksekusi pesimis menggunakan mekanisme penguncian. Sebelum transaksi dapat mengakses variabel status tertentu, transaksi harus memperoleh kunci pada variabel tersebut. Kunci memberikan akses eksklusif pada variabel tersebut, mencegah transaksi lain untuk memodifikasinya secara bersamaan. Kunci dilepaskan setelah transaksi dieksekusi, memungkinkan transaksi lain untuk mengakses variabel tersebut.

Di Solana Tingkat Lautwaktu proses yang menerapkan model eksekusi pesimis ini, transaksi menentukan akun yang akan dibaca atau ditulis selama eksekusi. Sealevel menganalisis pola akses dan membuat antrian transaksi paralel untuk setiap utas CPU pada node validator. Jika sebuah akun diakses beberapa kali, itu akan terdaftar secara berurutan dalam satu antrian untuk mencegah konflik. Transaksi yang tidak diproses dalam waktu blok node pemimpin dikumpulkan dan diteruskan ke pemimpin berikutnya yang dijadwalkan untuk diproses.

Sistem berbasis Output Transaksi Belum Dibelanjakan (UTXO) meningkatkan efisiensi komputasi dengan cara yang sama. UTXO melibatkan unit-unit mata uang tertentu—UTXO—yang terkait dengan dompet individu. Untuk setiap transaksi dompet tersebut, UTXO dikeluarkan dan digantikan dengan yang baru; satu atau lebih UTXO diciptakan untuk penerima, mewakili pembayaran, dan biasanya satu lagi diciptakan untuk pengirim, mewakili kembalian yang harus dikembalikan.

Dengan menentukan kontrak mana yang akan disentuh, transaksi yang menyentuh kumpulan kontrak yang saling lepas dapat dieksekusi secara paralel oleh node-node pelaksana (yang dapat dicapai dalam model data “akun” dengan daftar akses yang ketat). Namun, untuk mendapatkan kompatibilitas dengan kontrak pintar gaya Ethereum, skema UTXO seperti yang ada pada Fuel membatasi node-node pembuat blok untuk mengeksekusi transaksi dengan daftar akses yang tumpang tindih secara berurutan.

Namun, model eksekusi yang pesimis memiliki keterbatasan. Transaksi harus dengan tepat mendeklarasikan pola akses mereka di muka, yang dapat menjadi tantangan bagi transaksi yang kompleks atau dinamis di mana pola akses dapat bergantung pada data masukan atau logika kondisional. Deklarasi pola akses yang tidak akurat atau tidak lengkap dapat menyebabkan kinerja suboptimal dan kesalahan waktu jalankan potensial. Selain itu, mekanisme penguncian dapat memperkenalkan laten dan mengurangi konkurensi ketika banyak transaksi bersaing untuk variabel keadaan yang sama. Persaingan ini dapat membentuk bottlenecks kinerja, karena transaksi mungkin menghabiskan sebagian besar waktu eksekusi mereka menunggu untuk mengakuisisi kunci pada variabel keadaan yang sangat diminati.

Lebih pentingnya lagi, model ini menempatkan beban yang cukup besar pada para pengembang, yang harus memiliki pemahaman mendalam tentang ketergantungan data kontrak mereka untuk menentukan akses keadaan yang diperlukan sebelumnya dengan akurat. Kompleksitas ini dapat menimbulkan tantangan, terutama dalam merancang aplikasi dengan interaksi keadaan yang dinamis dan kompleks, seperti pertukaran terdesentralisasi atau pembuat pasar otomatis.

Eksekusi Optimis

Sebaliknya, model eksekusi optimis mengadopsi pendekatan “spekulatif” terhadap eksekusi transaksi, memungkinkan transaksi dieksekusi secara paralel tanpa perlu deklarasi akses keadaan di awal.

Alih-alih mencegah konflik sebelum terjadi, transaksi dieksekusi secara optimis secara paralel, dengan asumsi mereka independen. Runtime menggunakan teknik seperti kontrol konkurensi multi-versi(MVCC) danmemori transaksi perangkat lunak(STM) untuk melacak set baca dan tulis selama eksekusi. Setelah eksekusi, runtime mendeteksi konflik atau ketergantungan apa pun. Ini mengambil langkah korektif, seperti membatalkan dan mengeksekusi ulang transaksi yang bertentangan, tetapi dapat melakukannya dengan membaca dari memori daripada disk untuk mengidentifikasi transaksi yang bertentangan.

Model eksekusi optimis menyederhanakan proses pengembangan, memungkinkan para programer fokus pada menulis logika kontrak tanpa perlu khawatir tentang mendeklarasikan pola akses keadaan. Karena transaksi tidak perlu mendeklarasikan interaksi keadaan mereka di awal, para pengembang memiliki kebebasan lebih dalam merancang kontrak pintar mereka, memungkinkan interaksi yang lebih kompleks dan dinamis dengan keadaan blockchain. Model eksekusi optimis sangat cocok untuk platform yang mendukung volume transaksi tinggi dan dapps kompleks, karena dapat menawarkan throughput dan skalabilitas yang lebih tinggi daripada model pesimis.

Salah satu implementasi yang mencolok dari model ini ditemukan di Aptosdan MoveVM dariGerakan Labs*, yang menggunakan teknik yang dikenal sebagai Block-STMDi Block-STM, transaksi pertama kali dieksekusi secara paralel; kemudian, transaksi yang bertentangan diidentifikasi dan dijadwalkan ulang untuk dieksekusi berdasarkan dependensi yang terdeteksi. Pendekatan ini memastikan sumber daya pemrosesan terus digunakan, meningkatkan throughput sambil mempertahankan integritas alur kerja transaksional.

Block-STM Aptos dari “Scaling Blockchain Execution by Turning Ordering Curse to a Performance Blessing”

Meskipun memiliki kelebihannya, model eksekusi optimis juga datang dengan tantangan. Kebutuhan akan deteksi konflik waktu jalannya dan kemungkinan pembatalan transaksi dan percobaan ulang memperkenalkan beban komputasi dan kompleksitas. Selain itu, mempertahankan beberapa versi dari keadaan dan mengelola beban yang terkait dengan resolusi konflik memerlukan desain sistem yang canggih dan mekanisme kontrol konkurensi yang tangguh untuk memastikan integritas dan kinerja blockchain.

Block-STM memanfaatkan MVCC untuk mengelola penulisan konkuren secara efektif dan mempertahankan beberapa versi data, sehingga mencegah konflik antara operasi penulisan simultan. Ini mencakup penjadwal kolaboratif untuk mengkoordinasikan tugas-tugas eksekusi dan validasi di beberapa thread, memastikan bahwa transaksi dikonfirmasi dalam urutan mereka dimulai. Penyiapan ini meminimalkan pembatalan transaksi dengan menggunakan estimasi dependensi dinamis, yang memungkinkan transaksi dengan dependensi untuk menunggu dan menyelesaikan dependensi ini dengan efisien sebelum melanjutkan.

Selain itu, model akun yang digunakan oleh MoveVM berbeda dari EVM Ethereum, yang mengarah ke lebih sedikit tabrakan. Di Ethereum, token biasanya dikelola oleh satu kontrak pintar, yang berpotensi menyebabkan beberapa transaksi token berinteraksi melalui alamat kontrak yang sama, meningkatkan kemungkinan konflik. Sebaliknya, MoveVM memberikan token kepada akun pengguna individual, mengurangi kemungkinan konflik seperti setiap transaksi biasanya berinteraksi dengan alamat akun yang berbeda.

Di Monad, set awal transaksi yang dieksekusi secara paralel dapat diformulasikan sebagai fase I/O, yang mungkin menghasilkan hasil yang dapat segera di-commit, dan fase “retry” berikutnya, yang memerlukan sedikit pekerjaan untuk membersihkan transaksi yang tersisa yang konflik. Transisi yang konflik ini muncul dan ditarik ke cache, memungkinkan overhead eksekusi dikurangi karena mereka berada di memori. Sementara kebanyakan state berada di disk, transaksi yang konflik diakses dengan cepat pada saat eksekusi.

Model eksekusi pesimis dan optimis menawarkan pendekatan yang berbeda dalam menangani eksekusi transaksi dan manajemen status dalam blockchain. Pemilihan antara model-model ini melibatkan pertukaran antara kompleksitas awal dalam spesifikasi akses status dan beban komputasi yang terkait dengan resolusi konflik dinamis.

Paralelisme Data & Tugas

Paralelisme data dan tugas berfokus pada mengoptimalkan kinerja dengan mendistribusikan beban komputasi di sepanjang beberapa prosesor: paralelisme data membagi dataset untuk diproses secara simultan, sementara paralelisme tugas menugaskan tugas yang berbeda ke berbagai prosesor untuk beroperasi secara bersamaan.

Optimisasi-optimalisasi ini berbeda namun saling bergantung dengan paralelisme akses keadaan, yang mengelola dan menyelaraskan akses ke sumber daya bersama seperti memori atau basis data untuk mencegah konflik dan memastikan integritas data ketika beberapa proses atau utas beroperasi secara bersamaan.

Paralelisme Data

Paralelisme data melibatkan parallelisasi operasi tertentu di sepanjang elemen data secara bersamaan. Pendekatan ini terutama bermanfaat ketika operasi yang sama perlu diterapkan pada kumpulan data besar atau saat melakukan operasi komputasi intensif pada beberapa nilai input. Kunci pemecahannya datang dari mendistribusikan data di sepanjang unit pemrosesan yang berbeda dan menjalankan operasi yang sama secara bersamaan pada elemen data yang berbeda.

Salah satu teknik umum untuk paralelisme data adalah instruksi-tunggal, data-multiple(SIMD), yang memungkinkan satu instruksi dieksekusi secara bersamaan pada elemen data multipel. CPU modern sering kali memiliki kemampuan SIMD bawaan, memungkinkan mereka melakukan operasi paralel pada titik data multipel. Dengan memanfaatkan instruksi SIMD, pengembang dapat mencapai peningkatan kecepatan yang signifikan untuk jenis operasi tertentu, seperti komputasi matematika, transformasi data, atau pemrosesan sinyal.

Sebagai contoh, pertimbangkan sebuah skenario di mana Anda harus menerapkan fungsi matematika kompleks pada larik angka yang besar. Alih-alih memproses setiap angka secara berurutan, SIMD dapat beroperasi pada beberapa angka secara bersamaan. Pengolahan simultan ini dicapai dengan memuat subset angka ke dalam register SIMD CPU, mengeksekusi fungsi matematika pada semua angka yang dimuat secara paralel, dan kemudian menyimpan hasilnya kembali ke memori. Dengan memproses beberapa angka sekaligus, SIMD dapat sangat mengurangi waktu eksekusi secara keseluruhan.

Pekerjaan Firedancer pada ED25519verifikasi tanda tangan menunjukkan kekuatan SIMD untuk mengoptimalkan komputasi kompleks. Proses verifikasi tanda tangan melibatkan operasi aritmatika dalam Galois Fields, yang dapat memakan waktu komputasi. Dengan memanfaatkan instruksi SIMD, Firedancer dapat melakukan operasi tersebut pada beberapa elemen data secara bersamaan, menghasilkan peningkatan kinerja yang signifikan. Optimisasi ini akan menjadi krusial dalam meningkatkan kinerja Solana, yang sudah menerapkan paralelisasi akses keadaan.

Paralelisme Tugas

Paralelisme tugas melibatkan memparallelkan berbagai tugas atau operasi dalam sebuah program di beberapa unit pemrosesan. Pendekatan ini berguna ketika sebuah program terdiri dari beberapa tugas independen yang dapat dilakukan secara bersamaan. Dengan menugaskan setiap tugas ke unit pemrosesan yang terpisah, seperti inti CPU atau GPU, waktu eksekusi secara keseluruhan dapat dikurangi.

Paralelisme tugas umumnya digunakan dalam skenario di mana sebuah program perlu melakukan beberapa operasi kompleks secara bersamaan. Misalnya, pertimbangkan aplikasi pemrosesan video yang perlu menerapkan filter dan efek berbeda ke aliran video secara real-time. Alih-alih menggunakan setiap unit komputasi untuk secara kolektif menerapkan setiap filter secara berurutan, paralelisme tugas dapat mendistribusikan beban kerja di seluruh unit pemrosesan yang berbeda. Satu unit pemrosesan dapat bertanggung jawab untuk menerapkan filter kabur sementara unit lain menerapkan filter koreksi warna, dan seterusnya. Dengan menjalankan tugas-tugas ini secara paralel, aplikasi dapat mencapai pemrosesan yang lebih cepat dan menjaga pengalaman pengguna yang lancar.

Lagrange’s @lagrangelabs/a-big-data-primer-introducing-zk-mapreduce-12cf404eab75">ZK MapReduce (ZKMR) memanfaatkan paralelisme data dan tugas untuk secara efisien memparalelkan dan menghasilkan bukti perhitungan terdistribusi pada kumpulan data besar. Pada fase peta, dataset input dipartisi menjadi potongan-potongan yang lebih kecil, dan setiap potongan diproses secara independen oleh pekerja pemeta terpisah atau mesin secara paralel (paralelisme tugas). Operasi "peta" dapat diparalelkan dalam setiap tugas pemeta di beberapa core atau prosesor (paralelisme data). Demikian pula, dalam fase pengurangan, operasi "mengurangi" pada nilai-nilai yang terkait dengan setiap kunci dapat diparalelkan dalam setiap tugas peredam (paralelisme data). Sebaliknya, tugas peredam dijalankan paralel di beberapa pekerja (paralelisme tugas).

Dengan menggabungkan paralelisme data dan paralelisme tugas, ZKMR dapat mencapai skalabilitas dan kinerja yang efisien untuk perhitungan kompleks pada kumpulan data besar sambil tetap mempertahankan jaminan pengetahuan nol melalui komposisi bukti rekursif.

Memverifikasi prosedur MapReduce sembarang di ZK dari Lagrange's “Memperkenalkan ZK MapReduce

Kemampuan Lagrange untuk menghasilkan bukti penyimpanan untuk komputasi SQL di atas @lagrangelabs/mengumumkan-testnet-euclid-database-verifiable-pertama-ethereum-dan-zk-coprocessor-cc4a5595365c">888,888 slot penyimpanan dalam 1 menit dan 20 detik menunjukkan kekuatan ZKMR, serta paralelisme tugas dan data yang mendasarinya. Selain itu, penemuan terbaru LagrangePohon Recklepaper menekankan perlunya paralelisme dalam memastikan bahwa bukti batch dari data onchain juga dapat dihitung dalam 𝑂(log𝑛), independen dari ukuran batch.

Parallelizing Consensus & Execution

Meskipun bagian ini tidak membahas konsensus, blockchain juga dapat memparallelkan proses konsensus dan eksekusi. Blockchain tradisional seringkali memproses transaksi secara berurutan, mencapai konsensus tentang transaksi blok (blok N) sebelum menjalankannya. Pengolahan paralel dari fase konsensus dan eksekusi secara signifikan meningkatkan efisiensi eksekusi dan merupakan teknik yang dicontohkan oleh sistem seperti Monad. Ketika jaringan mencapai konsensus untuk blok N, secara bersamaan menjalankan transaksi untuk blok sebelumnya (N-1).

Strategi ini memastikan penggunaan sumber daya komputasi yang kontinu dan efisien, dengan efektif mengurangi waktu tidak aktif dan meningkatkan kemampuan jaringan untuk memproses transaksi dengan cepat. Peningkatan ini meningkatkan throughput sistem dan biaya modal yang diperlukan untuk spam jaringan.

Juru Bahasa & Mengurangi Overhead

Ketika kontrak pintar ditulis dalam bahasa seperti Solidity, mereka pertama kali dikompilasi menjadi bytecode tingkat rendah. Kemudian, EVM menggunakan penterjemah untuk menjalankan bytecode ini. Penterjemah membaca dan menjalankan setiap instruksi secara berurutan, mirip dengan menerjemahkan bahasa asing secara real-time saat sedang diucapkan. Paradigm's artikel terbaru tentang Rethmenunjukkan bahwa hal ini menyebabkan overhead karena setiap instruksi harus diproses secara individual dan dikonversi dari bytecode ke instruksi mesin selama runtime.

Reth sedang mengatasi ketidak efisienan EVM dengan menggabungkan compiler just-in-time (JIT). Compiler ini menerjemahkan bytecode menjadi kode mesin asli sesaat sebelum eksekusi, menghindari proses interpretasi yang membutuhkan sumber daya intensif yang biasanya diperlukan selama runtime.

The Artikel Rethmenyebutkan bahwa 50% dari waktu eksekusi EVM di bawah sistem berbasis interpreter didedikasikan untuk proses yang teoretisnya bisa dioptimalkan oleh JIT, menunjukkan kemungkinan untuk menggandakan kecepatan eksekusi dengan implementasi JIT. Namun, seperti yang ditunjukkan oleh Yilong dalam presentasi ini, sementara JIT dapat secara signifikan mengurangi waktu yang dibutuhkan untuk memproses opcode tertentu, hal itu mungkin tidak secara drastis memengaruhi eksekusi secara keseluruhan. Hal ini karena sebagian besar dari 50% waktu eksekusi EVM yang diambil oleh JIT melibatkanoperasi "host" dan "system"(Slide 13), yang tidak dapat dioptimalkan oleh JIT seperti “aritmetika” atau “kontrol” karena sifat non-komputasional mereka.

Meskipun penerjemah dapat membatasi kinerja, mereka menciptakan kesempatan untuk "terjemahan," yang meningkatkan cakupan kode yang dapat memanfaatkan mesin virtual baru, mengurangi overhead bagi pengembang untuk menggunakan ruang blok desainer. Sebagai contoh, Movement Labs telah mengembangkan Fractal, memungkinkan pengembang untuk mendeploy kontrak berbasis Solidity mereka di MoveVM. Fractal bekerja dengan mengompilasi Solidity ke dalam Bahasa Perantara yang berisi instruksi-artikulasi dalam opcode EVM, yang kemudian dipetakan ke padanan bytecode MoveVM mereka, memungkinkan kontrak Solidity berjalan di lingkungan MoveVM.

Mesin Negara Khusus & Disesuaikan

Menyesuaikan lapisan eksekusi melibatkan merancang mesin negara khusus yang dioptimalkan untuk aplikasi tertentu. Ini tidak hanya berarti bahwa lingkungan eksekusi dapat menghilangkan kebutuhan akan mesin virtual sepenuhnya, tetapi juga memungkinkan aplikasi untuk menyesuaikan arsitektur set instruksi (ISA), struktur data, dan model eksekusi untuk kebutuhan spesifik mereka. Manfaat kinerja utama dari menyesuaikan ISA dengan aplikasi tertentu berasal dari mengurangi overhead menerjemahkan pola komputasi aplikasi ke dalam instruksi tujuan umum dari ISA tradisional. CPU tujuan umum menggunakan set instruksi dasar (yaitu, tambah, muat, cabang) untuk mendukung menjalankan berbagai jenis perangkat lunak. Namun, ketika aplikasi sering mengulangi operasi multistep yang sama, menerapkan pola-pola ini menggunakan urutan instruksi sederhana menjadi tidak efisien.

Sebagai contoh, aplikasi database mungkin perlu secara konstan menelusuri struktur data pohon, mencari entri, memperbarui nilai, dan menyeimbangkan pohon. Pada CPU normal, memetakan operasi tingkat yang lebih tinggi ini memerlukan memecahnya menjadi urutan panjang mikro-op level rendah, seperti muatan, penyimpanan, cabang, dan aritmatika, dieksekusi secara individu pada perangkat keras umum. Sebaliknya, sebuah ISA yang disesuaikan untuk database dapat menyatukan pola berulang ini ke dalam instruksi yang lebih luas yang dioptimalkan yang memanfaatkan perangkat keras khusus. Instruksi "TraverseTree" dapat menghitung alamat memori, memuat node yang relevan, dan membandingkan kunci menggunakan sirkuit perbandingan paralel yang dirancang untuk operasi tersebut. "UpdateEntry" dapat langsung mengumpulkan entri dari tata letak penyimpanan database yang dioptimalkan, memodifikasinya, dan mengonfirmasi status baru semua dalam satu instruksi.

Ini menghilangkan beban yang berlebihan dari menerjemahkan operasi tingkat tinggi menjadi instruksi sederhana. Ini juga memungkinkan perangkat keras untuk menjalankan aplikasi secara optimal menggunakan instruksi paralel yang lebih sedikit namun lebih luas, yang disesuaikan secara tepat dengan kebutuhannya.

LayerN’s Nord menunjukkan manfaat kinerja dari lingkungan eksekusi khusus dan struktur data melalui kasus penggunaan khusus dari buku pesanan yang dapat diverifikasi. Pendekatan LayerN berfokus pada optimalisasi penempatan perdagangan ke dalam struktur data buku pesanan, sementara mekanisme pipelining mereka dirancang untuk secara efisien memasukkan pesanan baru ke posisi yang sesuai dalam pohon data buku pesanan. Dengan menyesuaikan struktur data dan algoritma penyisipan dengan persyaratan spesifik buku pesanan, LayerN mencapai penempatan pesanan latensi rendah dan throughput tinggi.

Sebagai alternatif, memungkinkan untuk fokus pada lingkungan eksekusi serbaguna yang memungkinkan modul yang dapat diprogram secara sembarangan yang dapat dihubungkan aplikasi untuk mengoptimalkan kinerjanya. Pendekatan ini memprioritaskan pengalaman pengembang atas kinerja mentah.

LancardanCWDmemanfaatkan strategi yang seimbang antara optimasi kinerja komputasi murni dan meningkatkan pengalaman pengembang serta kompatibilitas ekosistem. Pendekatan ini berfokus pada penggunaan WebAssembly (Wasm) sebagai VM untuk menjalankan kode. Wasm telah menjadi pilihan utama dalam pengembangan web karena dukungan bahasa yang luas dan tingkat adopsi yang luas.

Keputusan pengembang untuk menggunakan Wasm daripada eksekusi klien asli mencerminkan preferensi strategis untuk fleksibilitas dan aksesibilitas luas dari lingkungan eksekusi berbasis tujuan umum. Meskipun eksekusi asli, yang menjalankan kode langsung pada perangkat keras tanpa mesin virtual, dapat menawarkan kinerja yang lebih baik, namun membatasi kompatibilitas lintas platform dan kurang dapat diakses oleh pengembang. Sebaliknya, Wasm memastikan lingkungan eksekusi yang seragam dan aman di berbagai platform meskipun tidak mencapai kecepatan mentah yang sama seperti eksekusi asli. Pengorbanan ini sejalan dengan filosofi desain Fluent dan CWD, yang memprioritaskan produktivitas pengembang dan integrasi ekosistem yang lebih luas daripada efisiensi kinerja maksimum.

Penugasan CosmWasm (CWD), khususnya, menggambarkan pendekatan ini dengan tidak hanya menggunakan Wasm untuk eksekusi kontrak cerdas tetapi juga mengintegrasikannya ke dalam kerangka kerja yang lebih luas yang dirancang untuk mendukung kompleksitas operasi blockchain. Diperkaya dengan 'logika perifer', kerangka kerja ini menawarkan manajemen akun canggih, mekanisme gas yang dapat disesuaikan, dan pengurutan transaksi yang dioptimalkan. Fitur-fitur ini berkontribusi pada lingkungan pengembangan yang fleksibel, efisien, dan aman yang memberdayakan pengembang untuk membangun dapps yang dapat diskalakan dan kompleks dengan relatif mudah.

Stackr* mengambil pendekatan yang berbeda dengan menggabungkan manfaat lingkungan eksekusi yang disesuaikan dengan fleksibilitas platform kontrak pintar tradisional. Stackr memungkinkan pengembang untuk mengode aplikasi sebagai rollups, memungkinkan mereka untuk menentukan aturan mereka sendiri untuk urutan transaksi, eksekusi, dan konfigurasi. Dalam model Stackr, pengembang dapat memilih ISA, struktur data, dan model eksekusi yang paling sesuai dengan persyaratan aplikasi mereka.

Desain mikro-rollup Stackr dari "Memperkenalkan Stackr SDK"

Dengan Stackr, pengembang dapat menerapkan aturan transisi keadaan langsung di waktu runtime aplikasi daripada terikat oleh aturan VM umum, memberi mereka kemampuan untuk menyusun set instruksi mereka agar lebih efisien dan mendefinisikan kembali set hal yang dapat dilakukan dalam lingkungan runtime.

Ini menghasilkan eksekusi yang lebih ringan dan efisien, karena logika bisnis diimplementasikan pada tingkat klien, menghilangkan kebutuhan akan pemanggilan kontrak cerdas yang mahal dan validasi. Sebagai hasilnya, kemungkinan seputar bagaimana aplikasi dikonfigurasi berkembang dalam hal berbagai jenis bahasa, struktur data, dan tanda tangan yang dapat digunakan pengembang untuk satu aplikasi tanpa mengorbankan kinerja.

Kesimpulan

Ada beberapa jalur menuju kinerja lapisan eksekusi optimal.

Tidak ada optimisasi tunggal untuk akses keadaan atau paralelisasi yang menonjol sebagai titik diferensiasi teknis eksklusif antara lapisan eksekusi saat mencoba menangkap dapps. Saat kami melalui, manfaat paralelisasi berbasis sumber daya pada Solana dapat sama-sama diterapkan pada model UTXO Fuel. Siapa pun dapat menggunakan Amazon'ssolusi yang informatif untuk meningkatkan skalabilitas horizontal melalui shardingdan meningkatkan kinerja lapisan eksekusi.

Sementara kinerja lapisan eksekusi adalah vektor kritis untuk menarik pembangun aplikasi terdesentralisasi, L1 dan L2 baru yang berpusat pada peningkatan eksekusi harus bersaing dalam variabel lain, termasuk keamanan, interoperabilitas, dan kompatibilitas dengan alat yang sudah ada. Oleh karena itu, penyebaran lapisan interoperabilitas baru - dari Nebra hingga Statenet hingga AggLayer Polygon - akan menjadi kritis bagi pengembang yang membeli ruang blok desainer, karena mereka dapat membangun atau membeli ruang blok khusus tanpa mengorbankan komposabilitas sinkron dan likuiditas bersama dari L1 umum tradisional.

Peningkatan manajemen keadaan dan efisiensi komputasi saling terkait.

Di antara komunitas yang merancang lapisan eksekusi baru, paralelisasi akses keadaan telah menjadi meme yang menentukan bagi peningkatan kinerja yang mereka janjikan. Meskipun ini adalah hal yang wajar, karena ini bisa mengarah kePeningkatan 5x dalam pelaksanaan EVM, bukti dari eksperimen awal Monad dengan paralelisasi menunjukkan bahwa peranannya terlalu ditekankan jika perbaikan lain, seperti async I/O, tidak dikembangkan secara bersamaan.

Berdasarkan hal ini, kita dapat menyimpulkan bahwa efisiensi komputasi sering kali hanya tercapai ketika kita meningkatkan cara akses dan penyimpanan status. Manajemen status yang efisien mengurangi waktu dan sumber daya yang diperlukan untuk mengakses dan memanipulasi data, yang mempercepat pemrosesan dan mengurangi beban komputasi.

Mengambil langkah ini lebih jauh, pihak yang sudah ada mungkin membuat pilihan yang tergantung pada jalur yang menghambat kemampuan mereka untuk bersaing dengan desain blockchain baru yang memperbarui bagaimana keadaan dikelola dan diperbarui, mengingat inersia yang terkandung dalam hard fork. Sebagai hasilnya, lapisan eksekusi modular khusus dan alternatif L1 mungkin mampu menciptakan pertahanan seputar pilihan desain untuk penyimpanan keadaan yang lebih efisien dan protokol untuk membaca dan menulis ke dalamnya. Keputusan desain ini menawarkan keunggulan kompetitif, karena pihak yang sudah ada mungkin mengalami inersia dalam memperbarui struktur basis data mereka tanpa hard fork.

Pada akhirnya, nilai-nilai ruang blok memengaruhi ruang desain untuk lapisan eksekusi.

Dalam memahami bagaimana kita dapat meningkatkan lapisan eksekusi, kita sekarang dapat membedakan bahwa kelas-kelas optimisasi berbeda tergantung pada dua pilihan desain kritis—siapa yang mengeksekusi transaksi, dan berapa banyak node yang perlu terlibat? Teknik yang tersedia bagi pengembang untuk menyelesaikan bottleneck eksekusi berbeda secara signifikan tergantung pada jawaban awal tim terhadap pertanyaan-pertanyaan ini.

Di satu sisi, L1 monolitik seperti Solana dan Monad tidak menerima pemisahan peran validator ke dalam node-node kuat dan lemah yang berbeda untuk mempercepat kinerja. 'Menerima' penumpukan data dalam jangka pendek bukanlah solusi yang layak, jadi mereka mengandalkan peningkatan pada lapisan basis data dan komponen lain dari mesin produksi blok, seperti konsensus, untuk mengimbangi jumlah node yang lebih luas yang dianggap sebagai komponen kritis dan nilai inti dari jaringan. Karena model keamanan L1 ini bergantung pada konsensus dari kumpulan validator yang lebih terdistribusi dengan persyaratan hardware yang lebih lemah, data mereka harus ditulis ke basis data yang berada di disk, yang secara tidak langsung lebih murah untuk blockchain yang tidak memerlukan izin dan sangat terdesentralisasi.

Di sisi lain, proyek-proyek seperti Ethereum dan L2nya sedang mengejar peta jalan yang cenderung ke arah sentralisasi di seluruh node pelaksanaan mereka melalui pembangun blok terpusat yang bertanggung jawab kepada node proposer verifikasi yang lebih lemah melalui bukti penipuan atau validitas.

Dianggaplah “pengurus” terpusat dari transaksi dan perubahan keadaan dapat diterima dalam mengejar masa depan terdesentralisasi. Dalam hal ini, hukum fisika menyatakan bahwa sistem yang dapat 1) menambahkan blok ke rantai tanpa memerlukan beberapa pelaku untuk mengeksekusi ulang transaksi, 2) meningkatkan persyaratan validator untuk memaksimalkan komputasi di memori (dan mengabaikan masalah pembengkakan keadaan), dan 3) mengurangi latensi dan penghambat konsensus jelas unggul dibandingkan dengan sistem yang mengandalkan desentralisasi dan konsensus yang luas di antara simpul.

Dalam mencari keseimbangan antara skalabilitas dan minimisasi kepercayaan, menjadi jelas bahwa tujuan lapisan eksekusi seharusnya bukanlah mengoptimalkan desentralisasi secara buta, dan eksekusi tidak selalu harus benar-benar tanpa izin.

Saat kami mengembangkan dan menerapkan berbagai alat kriptografis, seperti validitas dan bukti kecurangan, kami secara efektif mengurangi jumlah node yang diperlukan untuk melawan sensor dan menjaga keamanan serta kelangsungan hidup. Pendekatan ini, bagaimanapun, melibatkan tradeoff, yang berpotensi memengaruhi ketahanan sensor, integritas pesanan, dan jaminan kelangsungan hidup karena kemungkinan sentralisasi pengurus.

Seperti yang dicatat oleh Sreeram, 'minimum viable decentralization' tidak berarti 'validasi harus tanpa izin', tetapi harus 'diinsentifasi dengan benar'. Ini mengimplikasikan bahwa sistem yang dipantau dengan baik, di mana validator menghadapi konsekuensi yang signifikan atas pelanggaran, dapat menjaga keamanan dan kelangsungan hidup tanpa perlu terlalu terdesentralisasi (.h/t Sreeram.

Model-model tata kelola semacam itu sudah diuji coba dalam aplikasi praktis. Misalnya, rollups seperti Arbitrum sedang mengeksplorasi sistem berbasis tata kelola atau komite untuk menegakkan aturan pengurutan transaksi dan pemilihan pemimpin, dan mereka sedang mempertimbangkan mekanisme di mana sequencer menggunakan data onchain untuk menegakkan kebijakan pengurutan transaksi.

Terlepas dari kemajuan ini, tidak ada "batas optimal pareto" yang pasti untuk menyeimbangkan desentralisasi dengan kinerja.

Pertimbangan ideologis dan teknis terus mendukung desentralisasi node pelaksana untuk memvalidasi status. Sementara node sentralisasi mengurangi overhead konsensus dan peningkatan perangkat keras dapat secara signifikan meningkatkan kinerja, masih perlu dilihat apakah optimalisasi ini akan menarik pengembang yang fokus pada menciptakan aplikasi tahan sensor dan sejauh mana ketahanan sensor tetap menjadi nilai inti dalam industri.

*menunjukkan perusahaan portofolio Archetype

Penafian:

1. Artikel ini dicetak ulang dari [Gate.io]cermin )], Teruskan Judul Asli 'Designer Blockspace: Masa Depan Lingkungan Pelaksanaan', Semua hak cipta milik penulis asli [GateBenjamin Funk]. Jika ada keberatan terkait pencetakan ulang ini, silakan hubungi Gate Belajartim, dan mereka akan menanganinya dengan segera.

2. Penolakan Tanggung Jawab: Pandangan dan opini yang terdapat dalam artikel ini semata-mata milik penulis dan tidak merupakan saran 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.