Ekspansi selalu menjadi salah satu topik yang tidak dapat dihindari oleh Ethereum. Jika Ethereum ingin menjadi "komputer dunia" yang sesungguhnya, Ethereum harus memiliki skalabilitas, keamanan, dan desentralisasi pada saat yang bersamaan Waktu yang dikenal di industri sebagai "Segitiga Blockchain yang Tidak Mungkin" adalah masalah besar yang belum terpecahkan di seluruh industri.
Namun, pada akhir tahun 2021, peneliti dan pengembang Ethereum Dankrad Feist mengusulkan Danksharding, solusi sharding baru untuk Ethereum, yang tampaknya telah membawa solusi revolusioner pada "segitiga blockchain yang mustahil" dan bahkan mungkin menulis ulang seluruh aturan permainan .
Laporan penelitian ini akan mencoba menjelaskan dalam bahasa sederhana apa solusi sharding baru Ethereum Danksharding dan asal-usulnya. Alasan saya menulis laporan penelitian ini adalah karena artikel berbahasa Mandarin tentang Danksharding sangat sedikit dan sebagian besar memerlukan tingkat pengetahuan yang tinggi. Oleh karena itu, Spinach akan mencoba menguraikan prinsip-prinsip rumit di baliknya untuk Anda, dan menggunakan bahasa sehari-hari yang sederhana untuk membuat pemula Web3 memahami solusi sharding baru Ethereum, Danksharding, dan solusi pendahulunya EIP-4844.
Penulis: Bayam Bayam
Jumlah kata: Laporan penelitian ini lebih dari 10.000 kata, dan perkiraan waktu membaca adalah 21 menit
Daftar isi
Mengapa Ethereum perlu berekspansi?
Latar Belakang Skala Ethereum
Apa itu segitiga mustahil blockchain?
Apa solusi penskalaan saat ini untuk Ethereum?
Solusi sharding awal Ethereum Sharding 1.0
Bagaimana mekanisme konsensus POS Ethereum bekerja?
Apa solusi sharding awal Sharding1.0?
Apa kerugian dari solusi sharding awal Sharding1.0?
Apa solusi sharding baru Ethereum Danksharding?
Solusi awal EIP-4844: Proto-Danksharding — Jenis transaksi baru Blob
Danksharding — Solusi Penskalaan Lengkap
Pengambilan Sampel Ketersediaan Data
Pengkodean Penghapusan
Komitmen KZG
Pemisahan Pengusul/Pembangun
Daftar Tahan Sensor (crList)
双槽 PBS（Pemisahan Pengusul-Pembangun Dua Slot）
Meringkaskan
Referensi
Mengapa Ethereum perlu berekspansi?
Setelah pendiri Ethereum Vitalik Buterin menerbitkan white paper Ethereum “Generasi Berikutnya dari Kontrak Cerdas dan Platform Aplikasi Terdesentralisasi” pada tahun 2014, blockchain menandai dimulainya era baru. Kelahiran kontrak pintar memungkinkan orang membuat aplikasi terdesentralisasi (DApps) di Ethereum, dan juga membawa serangkaian inovasi ke ekosistem blockchain seperti NFT, DeFi, GameFi, dll.
Latar Belakang Skala Ethereum
Seiring berkembangnya ekosistem rantai Ethereum, semakin banyak orang mulai menggunakan Ethereum, dan masalah kinerja Ethereum mulai terungkap. Ketika banyak orang berinteraksi di Ethereum pada saat yang sama, blockchain akan "macet", seperti waktu lampu lalu lintas di jalan yang ditetapkan, dan sejumlah kendaraan tertentu tidak akan menyebabkan kemacetan lalu lintas, tetapi tiba-tiba banyak mobil melaju menuju jalan ini selama jam sibuk, dan jumlah kendaraan yang meninggalkan jalan saat lampu berwarna hijau jauh lebih sedikit daripada jumlah kendaraan baru yang memasuki jalan sambil menunggu lampu lalu lintas, yang akan menyebabkan kemacetan besar, dan waktu bagi semua kendaraan untuk melewati jalan ini akan diperpanjang. Hal yang sama berlaku di blockchain, dan waktu konfirmasi untuk permintaan interaksi semua orang akan diperpanjang.
Namun dalam blockchain, bukan hanya waktu yang diperpanjang, tetapi juga biaya Gas yang tinggi (Biaya Gas dapat dipahami sebagai biaya kerja keras yang dibayarkan kepada penambang, yang bertanggung jawab untuk mengemas dan memproses semua transaksi dalam blockchain). Karena penambang akan memberikan prioritas pada transaksi dengan tawaran tertinggi, hal ini akan menyebabkan semua orang menaikkan biaya Gas untuk mendapatkan konfirmasi permintaan interaksi yang lebih cepat, yang memicu "Perang Gas". Insiden yang terkenal adalah meledaknya popularitas CryptoKitties, sebuah proyek NFT pada tahun 2017, yang mendorong biaya gas hingga beberapa ratus dolar per interaksi. Sangat mahal untuk menghabiskan puluhan atau bahkan ratusan dolar dalam biaya gas untuk satu interaksi di Ethereum.
Alasan utama mahalnya biaya gas tersebut adalah karena kinerja Ethereum tidak lagi dapat memenuhi kebutuhan interaksi pengguna yang ada. Dalam hal kalkulasi kinerja, Ethereum berbeda dengan Bitcoin. Karena Bitcoin hanyalah buku besar sederhana yang memproses informasi transfer, TPS-nya ditetapkan pada 7 transaksi per detik, tetapi berbeda di Ethereum.
Karena adanya kontrak pintar di Ethereum, konten setiap transaksi berbeda-beda, jadi jumlah transaksi yang dapat diproses setiap blok (TPS) bergantung pada jumlah data yang terkandung dalam satu blok. Jumlah data untuk setiap transaksi ditentukan berdasarkan permintaan waktu nyata. Kita dapat mempelajari tentang mekanisme kinerja Ethereum: (Informasi berikut ini bermanfaat untuk memahami Danksharding, pastikan untuk membacanya~)
Ethereum menetapkan batas atas jumlah data dalam satu blok berdasarkan biaya gas. Satu blok dapat menampung data maksimum 30 juta GAS.
Ethereum tidak ingin jumlah data di setiap blok terlalu besar, sehingga setiap blok memiliki Target Gas sebesar 15 juta Gas.
Ethereum memiliki seperangkat standar konsumsi data untuk Gas. Berbagai jenis data mengonsumsi jumlah Gas yang berbeda. Namun, menurut perkiraan kami, setiap blok berukuran sekitar 5kb hingga 160kb, dan ukuran rata-rata satu blok sekitar 60 hingga 70kb.
Bila konsumsi gas suatu blok melampaui target gas, yaitu 15 juta gas, biaya pokok blok berikutnya akan lebih mahal 12,5%. Bila lebih rendah, biaya pokok akan dikurangi. Mekanisme ini merupakan mekanisme penyesuaian dinamis otomatis yang dapat meningkatkan biaya untuk mengurangi kemacetan saat jam sibuk perdagangan, dan mengurangi biaya untuk menarik lebih banyak transaksi saat jam sepi perdagangan.
Dengan memahami mekanisme di atas, kita dapat mengetahui bahwa TPS Ethereum bersifat mengambang. **Kita dapat menggunakan peramban blockchain untuk melihat jumlah transaksi di setiap blok guna menghitung perkiraan TPS. Berdasarkan gambar di bawah, kita dapat melihat bahwa rata-rata, ada sekitar 160 transaksi dalam satu blok berdasarkan Target Gas, dan yang tertinggi dapat mencapai lebih dari 300 transaksi. Berdasarkan waktu blok 12 detik untuk setiap blok, TPSnya sekitar 13 hingga 30 transaksi, tetapi menurut pengetahuan saat ini, TPS Ethereum dapat mencapai hingga 45 transaksi per detik.
Artikel ini: Mainnet | Beacon Chain Explorer (Fase 0) untuk Ethereum 2.0 – BeaconScan
Jika kita mengambil sistem transaksi VISA yang terkenal di dunia, yang dapat memproses puluhan ribu transaksi per detik, Ethereum, yang ingin menjadi "komputer dunia", hanya dapat memproses paling banyak 45 transaksi per detik, yang terlalu lemah. Oleh karena itu, Ethereum sangat perlu memperluas kapasitasnya untuk memecahkan masalah kinerja, yang terkait dengan masa depan Ethereum, tetapi perluasan bukanlah tugas yang mudah karena ada "segitiga mustahil" dalam industri blockchain.
Apa itu segitiga mustahil blockchain?
"Segitiga Blockchain yang Mustahil" mengacu pada fakta bahwa blockchain publik tidak dapat secara bersamaan memenuhi tiga karakteristik: desentralisasi, keamanan, dan skalabilitas.
Desentralisasi: mengacu pada tingkat desentralisasi node. Semakin banyak node, semakin terdesentralisasi node tersebut.
Keamanan: mengacu pada keamanan seluruh jaringan blockchain. Semakin tinggi biaya serangan, semakin aman jaringan tersebut.
Skalabilitas: mengacu pada kinerja pemrosesan transaksi blockchain. Semakin banyak transaksi yang dapat diproses per detik, semakin besar skalabilitasnya.
Jika kita melihat pentingnya ketiga poin ini, kita akan menemukan bahwa desentralisasi dan keamanan memiliki bobot tertinggi. Desentralisasi adalah landasan Ethereum. Desentralisasilah yang memberikan Ethereum kenetralan, ketahanan terhadap penyensoran, keterbukaan, kepemilikan data, dan keamanan yang hampir tidak dapat dipecahkan. Pentingnya keamanan sudah jelas, tetapi visi Ethereum adalah mencapai skalabilitas sambil mempertahankan desentralisasi dan keamanan. Kesulitan untuk mencapainya dapat dibayangkan, jadi ini juga disebut "segitiga mustahil blockchain".
Sumber gambar: Ethereum Vision | ethereum.org
Apa solusi penskalaan saat ini untuk Ethereum?
Kita tahu bahwa dalam "Segitiga Blockchain yang Mustahil", premis bagi Ethereum untuk mencapai ekspansi adalah memastikan desentralisasi dan keamanan. Untuk memastikan desentralisasi dan keamanan, persyaratan kapasitas untuk node tidak boleh terlalu banyak ditingkatkan selama ekspansi. Karena node merupakan peran yang sangat penting dalam memelihara seluruh jaringan Ethereum, node dengan persyaratan tinggi akan menghalangi lebih banyak orang untuk menjadi node dan membuatnya semakin tersentralisasi. Tentu saja, semakin rendah ambang batas untuk node, semakin baik. Node dengan ambang batas rendah akan memungkinkan lebih banyak orang untuk berpartisipasi dan membuat Ethereum lebih terdesentralisasi dan aman.
Saat ini ada dua rencana ekspansi untuk Ethereum: Layer 2 dan Sharding. Layer 2 adalah solusi off-chain untuk memperluas blockchain yang mendasarinya (Layer 1). Prinsipnya adalah mengeksekusi permintaan pada blockchain off-chain. Ada beberapa solusi Layer2. Laporan penelitian ini hanya berfokus pada satu solusi Layer2, yaitu Rollup: Prinsip Rollup adalah mengemas ratusan transaksi menjadi satu transaksi seperti pancake off-chain dan mengirimkannya ke Ethereum untuk mencapai perluasan kapasitas. Dengan cara ini, biaya pengunggahan Ethereum ke semua orang akan sangat murah, sekaligus mewarisi keamanan Ethereum.
Rollup saat ini terbagi menjadi dua jenis: Optimism Rollup dan ZK Rollup (zero-knowledge proof Rollup). Perbedaan antara kedua Rollup ini adalah bahwa Optimism Rollup mengasumsikan bahwa semua transaksi jujur dan dapat dipercaya, memadatkan banyak transaksi menjadi satu transaksi dan mengirimkannya ke Ethereum. Setelah pengiriman, akan ada periode waktu (periode tantangan - saat ini satu minggu), dan siapa pun dapat mempertanyakan dan memulai tantangan untuk memverifikasi keaslian transaksi. Namun, jika pengguna ingin mentransfer ETH pada OP Rollup ke Ethereum, ia harus menunggu hingga periode tantangan berakhir sebelum mendapatkan konfirmasi akhir.
ZK Rollup menghasilkan bukti tanpa pengetahuan untuk membuktikan bahwa semua transaksi valid, dan mengunggah perubahan status akhir setelah semua transaksi dieksekusi ke Ethereum. Dibandingkan dengan Optimism Rollup, ZK Rollup lebih menjanjikan. ZK Rollup tidak perlu mengunggah semua detail transaksi terkompresi seperti Optimism Rollup. Ia hanya perlu mengunggah bukti tanpa pengetahuan dan data perubahan status akhir. Ini berarti ia dapat mengompresi lebih banyak data daripada OP Rollup dalam hal skalabilitas, dan tidak perlu menunggu periode tantangan selama seminggu seperti OP Rollup. Namun, kelemahan terbesar ZK Rollup adalah sangat sulit dikembangkan, jadi dalam jangka pendek, Optimism Rollup akan menempati pasar L2 yang besar.
Selain Layer2, ada solusi perluasan lain, yaitu Sharding, yang menjadi protagonis artikel ini. Kita tahu bahwa Layer2 menempatkan transaksi pada Ethereum di luar rantai untuk diproses. Tetapi tidak peduli bagaimana Layer2 memproses data, kinerja Ethereum sendiri tetap tidak berubah, jadi efek perluasan yang dapat dicapai Layer2 sebenarnya tidak begitu signifikan.
Sharding bertujuan untuk mencapai perluasan pada level Layer 1 Ethereum, tetapi kita tahu bahwa premis pencapaian perluasan pada Ethereum adalah untuk memastikan desentralisasi dan keamanan Ethereum, jadi kita tidak dapat terlalu menambah beban pada node.
Rencana implementasi spesifik sharding selalu menjadi topik diskusi di komunitas Ethereum. Rencana terbaru adalah Danksharding, yang menjadi subjek artikel ini. Disebutkan pula bahwa Danksharding merupakan rencana sharding terbaru. Sebelum membahas Danksharding, kami juga akan memperkenalkan secara singkat seperti apa rencana sharding lama dan mengapa rencana tersebut tidak diadopsi.
Solusi sharding awal Ethereum Sharding 1.0
Sebelum berbicara tentang solusi Sharding 1.0, saya perlu terlebih dahulu memperkenalkan cara kerja mekanisme konsensus POS Ethereum saat ini, karena ini adalah pengetahuan prasyarat yang diperlukan untuk memahami solusi Sharding 1.0 dan Danksharding. Saya akan meringkasnya secara singkat saat berbicara tentang solusi Sharding 1.0 (hanya tahu apa yang harus dilakukan secara kasar).
Bagaimana mekanisme konsensus POS Ethereum bekerja? [7]
Mekanisme konsensus adalah sistem yang memungkinkan semua node dalam blockchain yang mengelola jaringan untuk mencapai konsensus. Pentingnya mekanisme ini sudah jelas. Pada tanggal 15 September 2022, Ethereum menyelesaikan "Penggabungan" dalam fase peningkatan Ethereum 2.0, yaitu penggabungan mainnet Ethereum POW proof-of-work dan rantai suar mekanisme POS proof-of-stake. Mekanisme POS proof-of-stake secara resmi menggantikan mekanisme POW proof-of-work dan menjadi mekanisme konsensus Ethereum.
Kita tahu bahwa dalam mekanisme proof-of-work POW, para penambang bersaing untuk mendapatkan hak memproduksi blok dengan menumpuk daya komputasi mereka. Dalam mekanisme proof-of-stake POS, para penambang bersaing untuk mendapatkan hak memproduksi blok dengan mempertaruhkan 32 ETH untuk menjadi node verifikasi Ethereum (metode pertaruhan tidak akan diperkenalkan secara rinci di sini).
Selain perubahan dalam mekanisme konsensus, waktu blok Ethereum juga telah berubah dari waktu blok mengambang sebelumnya menjadi waktu tetap, yang dibagi menjadi dua unit: slot dan epoch: Slot adalah 12 detik dan epoch adalah 6,4 menit. Epoch berisi 32 slot. Secara sederhana, satu blok diproduksi setiap 12 detik, dan 32 blok diproduksi dalam 6,4 menit sebagai satu siklus (Epoch).
Ketika seorang penambang menjanjikan 32 ETH untuk menjadi node verifikasi, rantai suar akan menggunakan algoritma acak untuk memilih node verifikasi sebagai node penghasil blok untuk mengemas blok. Node penghasil blok akan dipilih secara acak untuk setiap blok. Pada saat yang sama, di setiap Epoch, rantai suar akan secara merata dan acak menetapkan semua simpul verifikasi ke sekelompok "Komite" yang terdiri dari setidaknya 128 simpul verifikasi untuk setiap blok.
Dengan kata lain, setiap blok akan diberi 1/32 dari jumlah simpul verifikasi dari semua simpul, dan "Komite" yang terdiri dari simpul verifikasi ini perlu memverifikasi dan memberikan suara pada blok yang dikemas oleh setiap simpul penghasil blok. Ketika node penghasil blok mengemas blok, blok dapat berhasil diproduksi jika lebih dari dua pertiga node verifikasi memberikan suara mendukung.
Apa solusi sharding awal Sharding1.0? [7]
Dalam konsep desain solusi sharding awal Sharding1.0, Ethereum dirancang dari satu rantai utama asli hingga maksimum 64 rantai shard, dan perluasan dicapai dengan menambahkan beberapa rantai baru. Dalam skema ini, setiap rantai pecahan bertanggung jawab untuk memproses data Ethereum dan menyerahkannya ke rantai suar, yang bertanggung jawab untuk mengoordinasikan seluruh Ethereum. Node blok dan komite dari setiap rantai pecahan ditetapkan secara acak oleh rantai suar.
Rantai suar dan rantai pecahan dihubungkan melalui tautan silang. Blok rantai suar akan memberikan nilai hash ke blok pecahan dari blok yang sama, lalu blok pecahan akan memberikan nilai hash ini ke blok suar berikutnya untuk mencapai tautan silang. Jika terlewat, nilai hash akan diberikan ke blok suar berikutnya.
Apa kerugian dari solusi sharding awal Sharding1.0?
Sederhananya, solusi Sharding 1.0 adalah membagi Ethereum menjadi beberapa rantai pecahan untuk memproses data bersama-sama dan kemudian menyerahkan data tersebut ke rantai beacon untuk mencapai perluasan, tetapi solusi ini memiliki banyak kelemahan:
**Kesulitan pengembangan: **Membagi Ethereum menjadi 64 rantai pecahan sambil memastikan operasi normal secara teknis sangat sulit dicapai, dan semakin kompleks sistemnya, semakin besar kemungkinan sistem tersebut memiliki beberapa kerentanan yang tidak dapat diprediksi. Begitu masalah terjadi, akan menyebabkan banyak masalah untuk memperbaikinya.
**Masalah sinkronisasi data: **Rantai suar akan mengatur ulang "komite" yang bertanggung jawab atas verifikasi setiap Epoch. Oleh karena itu, setiap realokasi node verifikasi merupakan sinkronisasi data jaringan berskala besar, karena jika sebuah node ditetapkan ke rantai shard baru, node tersebut perlu menyinkronkan data rantai shard ini. Karena lebar pita kinerja node bervariasi, sulit untuk memastikan bahwa sinkronisasi dapat diselesaikan dalam waktu yang ditentukan. Namun, jika node diizinkan untuk langsung menyinkronkan data semua rantai pecahan, beban pada node akan sangat meningkat, yang akan membuat Ethereum semakin tersentralisasi. [2]
**Masalah pertumbuhan volume data: **Meskipun kecepatan pemrosesan Ethereum telah meningkat pesat, pemrosesan data secara bersamaan oleh beberapa rantai shard juga telah menyebabkan peningkatan besar dalam jumlah data yang disimpan. Tingkat ekspansi volume data Ethereum akan jauh lebih cepat dari sebelumnya, dan persyaratan kinerja penyimpanan untuk node akan terus meningkat, yang mengarah ke lebih banyak sentralisasi.
**Tidak ada cara untuk menyelesaikan masalah MEV:** Nilai Ekstraksi Maksimum (MEV) adalah jumlah maksimum yang dapat diekstraksi dari produksi blok di luar imbalan blok standar dan biaya gas dengan menambahkan dan mengecualikan transaksi dari blok dan mengubah urutan transaksi dalam blok. Setelah transaksi dimulai di Ethereum, transaksi tersebut akan ditempatkan di mempool (kumpulan yang menyimpan transaksi yang akan dieksekusi) dan menunggu untuk dikemas oleh penambang. Kemudian penambang dapat melihat semua transaksi di mempool, dan penambang memiliki kekuatan yang besar. Penambang mengendalikan penyertaan, pengecualian, dan urutan transaksi. Jika seseorang mendapat untung dengan membayar lebih banyak biaya gas untuk menyuap penambang agar menyesuaikan urutan transaksi dalam kumpulan transaksi, ini adalah nilai maksimum yang dapat diekstraksi MEV. [6]
Misalnya:
Ada metode MEV yang disebut "serangan sandwich" atau "serangan penjepit". Metode ekstraksi MEV ini adalah untuk memantau transaksi DEX besar pada rantai. Misalnya, seseorang ingin membeli mata uang rumahan senilai 1 juta dolar AS di Uniswap, dan transaksi ini akan meningkatkan harga mata uang rumahan ini banyak. Ketika transaksi ini dimasukkan ke dalam mempool, robot pemantau dapat mendeteksi transaksi ini. Pada saat ini, robot menyuap penambang yang mengemas blok ini untuk menempatkan operasi pembelian mata uang rumahan ini di depan orang ini, dan kemudian melakukan operasi penjualan setelah operasi pembelian orang ini, seperti sandwich, menjepit orang yang melakukan transaksi DEX besar di tengah. Dengan cara ini, orang yang meluncurkan "serangan sandwich" memperoleh keuntungan dari mata uang rumahan karena transaksi skala besar orang ini, sementara orang yang melakukan transaksi skala besar menderita kerugian. [6]
Keberadaan MEV juga membawa beberapa dampak negatif bagi Ethereum, seperti kerugian dan pengalaman pengguna yang lebih buruk yang disebabkan oleh "serangan sandwich", kemacetan jaringan yang disebabkan oleh persaingan terdepan, biaya gas yang tinggi, dan bahkan masalah sentralisasi node. Hal ini karena node yang memperoleh nilai MEV lebih banyak dapat terus menempati bagian yang lebih besar dalam jaringan melalui pendapatan, karena lebih banyak pendapatan = lebih banyak ETH = lebih banyak ekuitas yang dipertaruhkan. Selain itu, biaya tinggi yang dibawa oleh MEV (kemacetan jaringan dan GAS tinggi yang disebabkan oleh front-running) akan menyebabkan pengguna Ethereum terus kehilangan pengguna. Bahkan jika nilai MEV secara signifikan melebihi hadiah blok, hal itu akan menyebabkan konsensus dan keamanan seluruh Ethereum menjadi tidak stabil. Solusi Sharding 1.0 tidak dapat menyelesaikan serangkaian masalah yang dibawa oleh MEV.
Setelah peneliti dan pengembang Ethereum Dankrad Feist mengusulkan solusi sharding Ethereum baru Danksharding pada akhir tahun 2021, Danksharding secara bulat diakui oleh komunitas Ethereum sebagai solusi terbaik untuk mencapai perluasan sharding, dan bahkan mungkin membawa revolusi baru ke Ethereum.
Danksharding menggunakan ide sharding baru untuk memecahkan masalah skalabilitas Ethereum, yaitu solusi sharding berdasarkan Rollup Layer2. Solusi sharding baru ini dapat memecahkan masalah skalabilitas tanpa meningkatkan beban node secara signifikan dan memastikan desentralisasi dan keamanan, sekaligus memecahkan dampak negatif MEV.
Kita dapat melihat dari gambar di bawah bahwa tujuan dari tahap peningkatan Ethereum berikutnya "The Surge" dan "The Scourge" adalah: untuk mencapai 100.000+ TPS dalam Rollup dan untuk menghindari sentralisasi yang dibawa oleh MEV dan risiko protokol lainnya.
Gambar / Sumber: vitalik.eth Terjemahan: ethereum.cn
Jadi bagaimana Danksharding memecahkan masalah skalabilitas Ethereum? Mari kita mulai dengan pendahulu Danksharding EIP-4844: Proto-Danksharding.
Solusi awal EIP-4844: Proto-Danksharding — Jenis transaksi baru Blob
EIP-4844 memperkenalkan jenis transaksi baru ke Ethereum - Transaksi Blob. Jenis transaksi baru ini Blob dapat menyediakan basis data plug-in tambahan untuk Ethereum:
Ukuran Blob sekitar 128KB
Suatu transaksi dapat membawa hingga dua blob - 256KB
Setiap blok memiliki 8 Target Blob berukuran 1MB, dan dapat membawa maksimal 16 Blob berukuran 2MB (konsep Target disebutkan dalam latar belakang ekspansi)
Data blob disimpan sementara dan akan dihapus setelah jangka waktu tertentu (saat ini komunitas merekomendasikan 30 hari)
Saat ini, ukuran rata-rata setiap blok Ethereum hanya sekitar 85KB. Ruang penyimpanan tambahan yang dibawa Blob ke Ethereum sangat besar. Perlu dicatat bahwa total ukuran data semua buku besar Ethereum sejak kelahiran Ethereum hanya sekitar 1TB, dan Blob dapat membawa 2,5TB~5TB data tambahan ke Ethereum setiap tahun, yang beberapa kali lipat ukuran data seluruh buku besar Ethereum.
Transaksi Blob yang diperkenalkan oleh EIP-4844 dapat dikatakan dibuat khusus untuk Rollup. Data Rollup diunggah ke Ethereum dalam bentuk Blob. Ruang data tambahan memungkinkan Rollup untuk mencapai TPS yang lebih tinggi dan biaya yang lebih rendah, sekaligus membebaskan ruang blok yang awalnya ditempati oleh Rollup ke lebih banyak pengguna.
Karena data Blob disimpan sementara, peningkatan volume data secara tiba-tiba tidak akan menyebabkan peningkatan beban pada kinerja penyimpanan node. Jika hanya data Blob selama satu bulan yang disimpan sementara, maka dari perspektif jumlah data yang disinkronkan, setiap node blok perlu mengunduh data tambahan sebesar 1MB~2MB, yang tampaknya tidak menjadi beban pada persyaratan bandwidth node. Dari perspektif penyimpanan data, node hanya perlu mengunduh dan menyimpan sejumlah data tetap sekitar 200~400GB (data satu bulan). Sambil memastikan desentralisasi dan keamanan, mereka hanya membayar sedikit biaya untuk meningkatkan beban node. Sebagai gantinya, peningkatan TPS dan pengurangan biaya dihitung puluhan atau bahkan ratusan kali lipat. Ini adalah solusi yang sangat baik untuk memecahkan masalah skalabilitas Ethereum.
Bagaimana jika data dihapus dan pengguna ingin mengakses data sebelumnya?
Pertama-tama, tujuan protokol konsensus Ethereum bukanlah untuk memastikan penyimpanan permanen semua data historis. Sebaliknya, tujuannya adalah untuk menyediakan papan buletin waktu nyata yang sangat aman dan penyimpanan jangka panjang untuk protokol terdesentralisasi lainnya. Tujuan dari papan buletin adalah untuk memastikan bahwa data yang diunggah di papan buletin bertahan cukup lama. Setiap pengguna atau protokol yang menginginkan data ini memiliki cukup waktu untuk menangkap dan menyimpan data tersebut. Oleh karena itu, tanggung jawab untuk menyimpan data Blob ini diberikan kepada peran lain seperti pihak proyek Layer2, protokol penyimpanan terdesentralisasi, dll. [3]
Danksharding — Solusi Penskalaan Lengkap
EIP-4844 mewujudkan langkah pertama perluasan Ethereum di sekitar Rollup, tetapi efek perluasan yang dicapai oleh EIP-4844 masih jauh dari cukup untuk Ethereum. Solusi Danksharding yang lengkap selanjutnya memperluas jumlah data yang dapat dibawa Blob dari 1~2MB per blok menjadi 16MB~32MB, dan mengusulkan mekanisme baru, pemisahan produsen-pengemas blok (PBS), untuk memecahkan masalah yang disebabkan oleh MEV.
Jadi kita perlu mengetahui kesulitan apa yang akan timbul jika kita terus memperluas kapasitas berdasarkan EIP-4844:
**Node kelebihan beban: **Kami mengetahui bahwa peningkatan beban pada node dari blob sebesar 1~2 MB di EIP-4844 sepenuhnya dapat diterima, tetapi jika ukuran blob ditingkatkan 16 kali menjadi 16~32 MB, beban pada sinkronisasi data dan penyimpanan data akan membuat node kelebihan beban, sehingga mengurangi derajat desentralisasi Ethereum.
**Masalah ketersediaan data: **Jika node tidak mengunduh semua data Blob, node tersebut akan menghadapi masalah ketersediaan data, karena data tersebut tidak terbuka di rantai dan dapat diakses kapan saja. Misalnya, node Ethereum memiliki keraguan tentang transaksi di Optimism Rollup dan ingin mengajukan keberatan, tetapi Optimism Rollup tidak menyerahkan data tersebut. Kemudian, tanpa data asli, node tersebut tidak dapat membuktikan bahwa transaksi tersebut bermasalah. Oleh karena itu, untuk mengatasi masalah ketersediaan data, perlu dipastikan bahwa data tersebut terbuka dan dapat diakses kapan saja.
Jadi bagaimana Danksharding memecahkan masalah ini?
Pengambilan Sampel Ketersediaan Data
Danksharding mengusulkan solusi - Pengambilan Sampel Ketersediaan Data untuk mengurangi beban node sambil memastikan ketersediaan data.
Ide di balik Data Availability Sampling (DAS) adalah memotong data dalam Blob menjadi fragmen-fragmen data, dan membiarkan node-node berubah dari mengunduh data Blob menjadi memeriksa fragmen-fragmen data Blob secara acak, sehingga fragmen-fragmen data Blob tersebut tersebar di setiap node Ethereum, tetapi keseluruhan data Blob tersimpan di seluruh buku besar Ethereum, asalkan jumlah nodenya cukup dan terdesentralisasi.
Misalnya, jika data Blob dipotong menjadi 10 fragmen, dan ada 100 node di seluruh jaringan, setiap node akan secara acak memilih dan mengunduh fragmen data dan mengirimkan nomor fragmen yang dipilih ke blok. Selama semua fragmen bernomor dapat dikumpulkan dalam satu blok, Ethereum akan menganggap bahwa data Blob ini tersedia, dan data asli dapat dipulihkan dengan menyatukan fragmen-fragmen tersebut. Namun, ada kemungkinan yang sangat rendah bahwa tidak satu pun dari 100 node akan menggambar fragmen dengan nomor tertentu, sehingga data akan hilang, yang akan mengurangi keamanan sampai batas tertentu, tetapi masih dapat diterima dalam hal probabilitas.
Danksharding menggunakan dua teknologi untuk mencapai Data Availability Sampling (DAS): Erasure Coding dan KZG Commitment
Pengkodean Penghapusan
Erasure Coding merupakan teknologi pengkodean yang toleran terhadap kesalahan. Penggunaan erasure coding untuk memisahkan data memungkinkan semua node Ethereum untuk memulihkan data asli ketika hanya lebih dari 50% fragmen data yang tersedia, yang sangat mengurangi kemungkinan kehilangan data. Prinsip implementasi spesifiknya relatif rumit. Di sini kami menggunakan rumus matematika untuk memberikan contoh guna menjelaskan prinsipnya secara kasar: [2]
Pertama, buatlah sebuah fungsi f(x) = ax + b, dan pilih secara acak 4 nilai x
Dengan asumsi m = f(0) = b, n = f(1) = a + b, kita dapat menyimpulkan bahwa a = n – b, b = m
Misalkan p = f(2) dan q = f(3), maka kita peroleh p = 2a + b = 2n – m, q = 3a + b = 3n – 2m
Kemudian keempat fragmen m, n, p, dan q tersebar di antara simpul-simpul seluruh jaringan.
Menurut rumus matematika, kita hanya perlu menemukan dua fragmen untuk mengetahui dua fragmen lainnya.
Jika kita menemukan n dan m, kita dapat langsung menghitung q=3n-2m dan p=2n-m
Jika kita menemukan q dan p, kita dapat menambahkan (2p=4n-2m)-(q=3n-2m) untuk mendapatkan 2p-q=n dan kemudian kita dapat langsung menghitung m.
Sederhananya, kode penghapusan menggunakan prinsip matematika untuk memotong data Blob menjadi banyak fragmen data. Node Ethereum tidak perlu mengumpulkan semua fragmen data. Node hanya perlu mengumpulkan lebih dari 50% fragmen untuk memulihkan data asli Blob. Hal ini sangat mengurangi kemungkinan pengumpulan fragmen yang tidak memadai, dan kemungkinan tersebut dapat diabaikan.
Komitmen KZG
Komitmen KZG adalah teknik kriptografi yang digunakan untuk memecahkan masalah integritas data kode penghapusan. Karena node hanya memeriksa fragmen data secara acak setelah dipotong oleh kode penghapusan, node tidak mengetahui apakah fragmen data benar-benar berasal dari data asli Blob, sehingga peran yang bertanggung jawab untuk pengkodean juga perlu menghasilkan komitmen polinomial KZG untuk membuktikan bahwa fragmen data dari kode penghapusan memang merupakan bagian dari data asli. Peran KZG agak mirip dengan pohon Merkle tetapi bentuknya berbeda. Semua pembuktian KZG berada pada polinomial yang sama.
Danksharding mengimplementasikan Data Availability Sampling (DAS) melalui kode penghapusan dan komitmen polinomial KZG, yang sangat mengurangi beban pada node ketika data tambahan yang dibawa oleh Blob diperluas hingga 16MB~32MB. Komunitas Ethereum juga telah mengusulkan solusi yang disebut skema KZG 2D untuk lebih memangkas fragmen data guna mengurangi kebutuhan bandwidth dan komputasi, tetapi komunitas tersebut masih mendiskusikan algoritma spesifik yang akan digunakan, termasuk desain DAS, yang juga terus dioptimalkan dan ditingkatkan.
Untuk Ethereum, Data Availability Sampling (DAS) memecahkan masalah perluasan volume data Blob menjadi 16MB~32MB sambil mengurangi beban pada node, tetapi tampaknya ada masalah: siapa yang akan mengkodekan data asli?
Jika Anda ingin mengodekan data mentah Blob, prasyaratnya adalah node yang melakukan pengodean harus memiliki data mentah yang lengkap. Untuk mencapai ini, persyaratan yang lebih tinggi akan ditetapkan pada node tersebut. Seperti yang disebutkan sebelumnya, Danksharding mengusulkan mekanisme baru **Blocker-Packager Separation (PBS)** untuk mengatasi masalah yang disebabkan oleh MEV. Faktanya, solusi ini tidak hanya mengatasi masalah MEV, tetapi juga mengatasi masalah pengkodean.
Pemisahan Pengusul/Pembangun
Pertama-tama, kita tahu bahwa Data Availability Sampling (DAS) mengurangi beban verifikasi node Blob dan mewujudkan verifikasi terdesentralisasi dan berkonfigurasi rendah. Namun, untuk membuat blok ini, diperlukan data Blob yang lengkap dan mengodekannya, yang meningkatkan persyaratan untuk banyak node penuh Ethereum. Proposer-Packard Separation (PBS) mengusulkan untuk membagi node menjadi dua peran: Builder dan Proposer. Node dengan kinerja tinggi dapat menjadi Builder, sedangkan node dengan kinerja rendah dapat menjadi Proposer.
Saat ini, ada dua jenis node Ethereum: node penuh dan node ringan. Node penuh perlu menyinkronkan semua data di Ethereum, seperti daftar transaksi dan badan blok, dll. Node penuh memainkan dua peran: pengemasan blok dan verifikasi blok. Karena simpul penuh dapat melihat semua informasi dalam blok, simpul penuh dapat menyusun ulang atau menambah atau menghapus transaksi dalam blok untuk memperoleh nilai MEV. Node ringan tidak perlu menyinkronkan semua data, mereka hanya perlu menyinkronkan header blok dan memverifikasi blok. [1]
Setelah menerapkan pemisahan pengusul-pengemas (PBS):
Node dengan konfigurasi kinerja tinggi dapat menjadi pengemas (Builder). Pengemas hanya bertanggung jawab untuk mengunduh data Blob untuk pengodean dan pembuatan blok, lalu menyiarkannya ke node lain untuk pemeriksaan acak. Untuk pengemas (Builder), karena persyaratan tinggi untuk volume data dan bandwidth yang tersinkronisasi, semuanya akan relatif tersentralisasi.
Node dengan konfigurasi kinerja yang lebih rendah dapat menjadi pengusul. Pengusul hanya perlu memverifikasi validitas data dan membuat serta menyiarkan header blok. Namun, bagi pengusul, volume data sinkronisasi dan persyaratan bandwidth lebih rendah, sehingga akan terdesentralisasi.
PBS mewujudkan pembagian kerja di antara node dengan memisahkan peran pengemasan dan verifikasi. Node dengan konfigurasi kinerja tinggi bertanggung jawab untuk mengunduh semua data untuk pengodean dan distribusi, sementara node dengan konfigurasi kinerja rendah bertanggung jawab untuk pemeriksaan acak dan verifikasi. Jadi, bagaimana masalah MEV dipecahkan?
Daftar Tahan Sensor (crList)
Karena PBS memisahkan pekerjaan pengemasan dan verifikasi, pengemas (Builder) sebenarnya memiliki kemampuan lebih besar untuk menyensor transaksi. Pengemas dapat dengan sengaja mengabaikan transaksi tertentu dan secara acak menyortir dan memasukkan transaksi yang ingin dimasukkannya untuk memperoleh MEV, tetapi daftar anti-sensor (crList) memecahkan masalah ini.
Mekanisme daftar anti-sensor (crList):[1]
Sebelum Builder mengemas transaksi blok, Proposer akan terlebih dahulu menerbitkan daftar yang tahan sensor (crList), yang memuat semua transaksi dalam mempool.
Builder hanya dapat memilih untuk mengemas dan mengurutkan transaksi dalam crList, yang berarti bahwa Builder tidak dapat memasukkan transaksi privatnya sendiri untuk mendapatkan MEV, juga tidak dapat dengan sengaja menolak transaksi (kecuali batas Gas penuh)
Setelah Builder mengemas daftar transaksi, Builder menyiarkan versi akhir Hash daftar transaksi kepada Proposer. Proposer memilih salah satu daftar transaksi untuk membuat header blok dan menyiarkannya.
Saat sebuah node menyinkronkan data, node tersebut memperoleh tajuk blok dari pengusul, lalu memperoleh badan blok dari pembangun untuk memastikan bahwa badan blok merupakan versi final yang dipilih.
Dampak negatif MEV seperti "serangan sandwich" diatasi melalui daftar tahan sensor (crList), dan node tidak dapat lagi memperoleh MEV serupa dengan memasukkan transaksi privat.
Rencana implementasi khusus Ethereum untuk PBS masih dalam pembahasan, dan kemungkinan rencana implementasi awal saat ini adalah PBS slot ganda.
双槽 PBS（Pemisahan Pengusul-Pembangun Dua Slot）
PBS slot ganda menggunakan model penawaran untuk menentukan blok: [2]
Setelah menerima crList, Builder membuat tajuk blok dari daftar transaksi dan mengajukan tawaran.
Pengusul memilih header blok dan pengemas (Builder) terakhir yang berhasil, dan pengusul menerima biaya tawaran pemenang tanpa syarat (terlepas dari apakah blok yang valid dihasilkan)
Komite verifikasi (Komite) mengkonfirmasi header blok pemenang
Pembangun mengungkapkan blok pemenang Tubuh
Komite verifikasi mengonfirmasi badan blok pemenang dan melakukan pemungutan suara verifikasi (jika lolos, blok akan diproduksi. Jika pengemas sengaja tidak memberikan badan blok, blok akan dianggap tidak ada)
Meskipun pembangun masih dapat memperoleh MEV dengan menyesuaikan urutan transaksi, mekanisme penawaran PBS slot ganda menyebabkan "involusi" di antara pembangun ini. Ketika semua orang harus menawar dan bersaing untuk mendapatkan blok, keuntungan yang diperoleh oleh pengemas terpusat melalui MEV akan terus ditekan, dan keuntungan akhir akan didistribusikan ke pengusul yang terdesentralisasi. Ini memecahkan masalah pengemas terpusat yang menjadi semakin tersentralisasi dengan memperoleh MEV.
Namun, PBS dua slot memiliki cacat desain: kita dapat melihat bahwa nama desain ini mengandung "dua slot", yang berarti ada dua slot. Ini berarti bahwa waktu blok efektif dalam skema ini diperpanjang hingga 24 detik (satu slot = 12 detik). Cara mengatasi masalah ini telah dibahas dengan hangat di komunitas Ethereum.
Meringkaskan
Danksharding menyediakan solusi revolusioner bagi Ethereum untuk memecahkan "segitiga blockchain yang mustahil", yaitu, untuk mencapai skalabilitas sambil memastikan desentralisasi dan keamanan Ethereum:
Jenis transaksi baru Blob diperkenalkan melalui pra-solusi EIP-4844: Proto-Danksharding. Data tambahan sebesar 1MB~2MB yang dibawa oleh Blob dapat membantu Ethereum mencapai TPS yang lebih tinggi dan biaya yang lebih rendah pada Rollup.
Pengambilan Sampel Ketersediaan Data (DAS) diimplementasikan melalui pengkodean penghapusan dan komitmen polinomial KZG, yang memungkinkan node memverifikasi ketersediaan data dengan memeriksa secara acak hanya beberapa fragmen data dan mengurangi beban pada node.
Dengan menerapkan Data Availability Sampling (DAS), volume data tambahan Blob diperluas hingga 16MB~32MB, sehingga efek perluasan menjadi lebih baik.
Melalui pemisahan pengusul-pengemas (PBS), pekerjaan blok verifikasi dan pengemasan dipisahkan menjadi dua peran node, mencapai desentralisasi parsial node pengemasan dan desentralisasi node verifikasi.
Dampak negatif MEV sangat berkurang melalui daftar anti-sensor (crList) dan PBS slot ganda. Pengemas tidak dapat memasukkan transaksi pribadi atau menyensor transaksi.
Jika tidak terjadi hal yang tidak terduga, solusi pendahulu Danksharding EIP-4844 akan secara resmi diimplementasikan dalam pemutakhiran Cancun setelah pemutakhiran Ethereum di Shanghai. Setelah solusi EIP-4844 diimplementasikan, manfaat paling langsungnya adalah Rollup di Layer2 dan ekosistem di Rollup. TPS yang lebih tinggi dan biaya yang lebih rendah sangat cocok untuk aplikasi frekuensi tinggi pada rantai. Kita juga dapat membayangkan bahwa beberapa "aplikasi pembunuh" mungkin akan lahir. Produksi blok terpusat + verifikasi terdesentralisasi + anti-sensor yang dicapai oleh Danksharding akan membawa babak baru narasi rantai publik ke Ethereum. Selain Layer2, reaksi kimia seperti apa yang akan dihasilkan blockchain modular dan Ethereum setelah Danksharding?
Kami percaya bahwa penerapan Danksharding akan menulis ulang aturan permainan, dan Ethereum akan memimpin industri blockchain ke era baru!
Referensi
[1] Ketersediaan Data, perluasan penyimpanan blockchain
[2] Artikel untuk memahami rencana peningkatan Ethereum baru Danksharding
[3] FAQ Proto-Danksharding – HackMD
[4] Apa itu “Danksharding”?
[5] V God merekomendasikan: Untuk mendapatkan pemahaman yang lebih dalam tentang peta jalan sharding Ethereum, cukup baca laporan ini
[6] Artikel Buidler DAO: Bagaimana cara menyelamatkan NFT dari peretas setelah dompet dicuri?
[7] Sejarah terulang kembali? Ethereum 2.0 dan Hard Fork Dijelaskan