Shardeum dan Sharding Status Dinamis: kemungkinan lain dari sharding

Pada 15 September 2022, Ethereum menyelesaikan penggabungan yang telah lama dinantikan (Merge). Ini adalah momen bersejarah, Ethereum telah mempersiapkannya selama 5 tahun dan menunda 6 kali. Karena debugging yang berulang dan pengembangan jangka panjang, banyak orang salah paham bahwa penggabungan akan secara alami membawa skalabilitas, keamanan, dan keberlanjutan yang lebih tinggi, tetapi sebenarnya tidak demikian. Transisi dari PoW ke PoS hanyalah mengganti rel dan roda, itu tidak akan langsung membawa kecepatan yang lebih cepat, kapasitas yang lebih besar, atau biaya yang lebih rendah. Yang benar-benar dapat mewujudkan ini adalah rangkaian solusi yang lengkap: jaringan utama yang memiliki kemampuan Sharding dipadukan dengan solusi Layer2 yang meningkatkan skalabilitas.

Seperti yang ditunjukkan oleh pendiri Ethereum Vitalik Buterin, Sharding adalah solusi skalabilitas untuk tantangan trilema skalabilitas, dengan membagi node dalam jaringan menjadi kelompok yang lebih kecil, memproses kumpulan transaksi yang berbeda, dan mewujudkan pemrosesan paralel. Dengan membagi beban pemrosesan data besar yang diperlukan untuk agregasi di seluruh jaringan, seperti saat kita berbelanja dan membayar di supermarket, dengan membuka beberapa jalur kasir, kita dapat secara intuitif mengurangi waktu antrean dan meningkatkan efisiensi pembayaran.

Ini adalah logika Sharding, langsung dan sederhana, namun, masalah terletak pada detailnya. Prinsip dan arah tidak salah, tetapi dalam pelaksanaannya selalu ada banyak masalah. Artikel ini ingin merapikan arah dan dilema dalam perjalanan "Sharding", menggambar peta penjelajah Sharding yang mengamati bintang dan berpijak di tanah. Sambil membandingkan solusi Sharding yang ada, menemukan beberapa masalah umum, dan mengusulkan arah eksplorasi yang layak: Shardeum dan Sharding dinamis.

Satu, tentang "Sharding"

Secara sederhana, mempertimbangkan batasan dari segitiga ketidakmungkinan, dengan Ethereum sebagai titik koordinat (0,0), berdasarkan dua pemikiran "vertikal" dan "horizontal", kita membagi metode skalabilitas blockchain saat ini menjadi dua kategori besar:

Skalabilitas Vertikal (: Mencapai dengan meningkatkan kinerja perangkat keras yang ada dalam sistem. Membangun jaringan terdesentralisasi, di mana setiap node dalam jaringan memiliki kemampuan komputasi super, yaitu setiap node memerlukan perangkat keras yang "lebih baik". Cara ini sederhana dan efektif, dapat mencapai perbaikan awal dalam throughput, terutama cocok untuk perdagangan frekuensi tinggi, permainan, dan aplikasi lain yang sensitif terhadap latensi. Namun, cara skalabilitas ini akan membatasi tingkat desentralisasi jaringan, karena biaya untuk menjalankan node validasi atau node penuh meningkat. Mempertahankan tingkat desentralisasi dibatasi oleh laju pertumbuhan kinerja perangkat keras komputasi yang kira-kira ) inilah yang disebut "Hukum Moore": jumlah transistor di chip akan berlipat ganda setiap dua tahun, dan biaya komputasi akan setengah (.

Horizontal Scaling): Horizontal scaling biasanya memiliki beberapa pendekatan. Salah satunya adalah dalam konteks blockchain, mendistribusikan beban transaksi dari suatu ekosistem ke beberapa blockchain independen, di mana setiap rantai memiliki produsen blok dan kemampuan eksekusi sendiri. Pendekatan ini memungkinkan penyesuaian penuh pada lapisan eksekusi setiap rantai, seperti persyaratan perangkat keras node, fungsi privasi, biaya gas, mesin virtual, dan pengaturan izin. Pendekatan horizontal scaling lainnya adalah blockchain modular, yang membagi infrastruktur blockchain menjadi lapisan eksekusi, lapisan ketersediaan data(DA), dan lapisan konsensus. Mekanisme modular blockchain yang paling umum adalah rollup. Selain itu, ada juga pendekatan membagi satu blockchain menjadi banyak shard yang dieksekusi secara paralel. Setiap shard dapat dianggap sebagai satu blockchain, artinya banyak blockchain dapat dieksekusi secara paralel. Selain itu, biasanya akan ada satu rantai utama, yang tugasnya hanya untuk menjaga semua shard tetap sinkron.

Perlu dicatat bahwa semua pemikiran tentang skala di atas tidak berdiri sendiri, setiap solusi merupakan titik kompromi yang ditemukan dalam segitiga yang tidak mungkin, dipadukan dengan desain mekanisme insentif yang diciptakan oleh kekuatan ekonomi dalam sistem, untuk mencapai keseimbangan yang efektif pada tingkat makro dan mikro.

Untuk membahas "Sharding", kita perlu mulai dari awal.

Masih mengasumsikan skenario seperti ini, saat belanja di supermarket, untuk meningkatkan efisiensi pembayaran dan mengurangi waktu tunggu pelanggan, kita memperluas dari satu jalur pembayaran menjadi 10 jendela pembayaran. Untuk menghindari kesalahan dalam buku kas, saat ini kita perlu menetapkan aturan yang seragam:

Pertama, jika kita memiliki 10 kasir, bagaimana kita harus membagi mereka untuk bekerja di jendela mana?

Kedua, jika kita memiliki 1000 pelanggan yang antre menunggu, bagaimana kita menentukan setiap pelanggan pergi ke jendela mana untuk membayar?

Ketiga, bagaimana cara mengkonsolidasikan 10 buku besar terpisah yang sesuai dengan 10 jendela ini?

Keempat, untuk menghindari ketidakcocokan akun, bagaimana cara mencegah kesalahan yang dibuat oleh kasir?

Ketiga masalah ini sebenarnya berkaitan dengan beberapa masalah kunci dalam Sharding, yaitu:

Bagaimana cara menentukan node/validator mana yang termasuk dalam shard di seluruh jaringan? Yaitu: bagaimana cara melakukan pemisahan jaringan (Network Sharding);

Bagaimana cara menentukan setiap transaksi dialokasikan ke shard mana? Yaitu: bagaimana melakukan transaksi sharding (Transaction Sharding);

Bagaimana data blockchain disimpan di berbagai Sharding? Yaitu: bagaimana melakukan status sharding (State Sharding);

Kompleksitas berarti risiko, berdasarkan semua hal di atas, bagaimana cara menghindari perpecahan keamanan keseluruhan sistem?

( 01 Jaringan Sharding ) Network Sharding ###

Jika kita memahami blockchain secara sederhana sebagai buku besar terdesentralisasi, baik mekanisme konsensus PoS maupun PoW bertujuan agar setiap node bersaing untuk mendapatkan hak pencatatan berdasarkan aturan yang sudah ditetapkan, sambil memastikan keakuratan buku besar dalam proses tersebut. Sedangkan pemotongan jaringan adalah suatu hal yang memerlukan aturan yang sudah ditetapkan lain, untuk membagi jaringan blockchain menjadi beberapa bagian, dengan mengurangi komunikasi antar bagian sebisa mungkin, di mana masing-masing bagian menangani transaksi di blockchain dan bersaing untuk mendapatkan hak pencatatan - yaitu, aturan pengelompokan node.

Namun, masalah yang dihadapi dalam proses ini adalah, seiring dengan pemisahan node dalam blockchain menjadi berbagai Sharding, kesulitan dan biaya bagi penyerang akan menurun secara drastis. Kita bisa menyimpulkan, dengan asumsi bahwa aturan dan hasil dari proses pengelompokan ini tetap dan dapat diprediksi, maka penyerang yang ingin mengendalikan seluruh jaringan blockchain hanya perlu mengendalikan secara terarah salah satu Sharding, dan membeli beberapa node di dalam Sharding tersebut.

Seorang pendiri blockchain menjelaskan masalah ini: jika sebuah rantai tunggal dengan X validator memutuskan untuk hard fork menjadi rantai sharding dan membagi X validator menjadi 10 sharding, setiap sharding sekarang hanya memiliki X/10 validator, merusak satu sharding hanya memerlukan merusak 5,1% ( 51% / 10) dari total validator. Ini mengarah pada poin kedua: siapa yang memilih validator untuk setiap sharding? Hanya ketika semua 5,1% validator berada di sharding yang sama, mengendalikan 5,1% validator menjadi berbahaya. Jika validator tidak dapat memilih di mana mereka akan memvalidasi di sharding, maka partisipan yang mengendalikan 5,1% validator sangat tidak mungkin menempatkan semua validator dalam sharding yang sama, sehingga secara signifikan mengurangi kemampuan mereka untuk merusak sistem.

Sistem sharding harus mengembangkan mekanisme untuk mempercayai bahwa jaringan tidak akan membalikkan transaksi ini dari shard eksternal. Hingga saat ini, kemungkinan jawaban terbaik adalah memastikan jumlah validator dalam shard lebih tinggi dari ambang minimum tertentu, sehingga kemungkinan validator yang tidak jujur menguasai shard tunggal sangat rendah. Cara yang paling umum adalah membangun tingkat ketidakberpihakan tertentu, bergantung pada matematika, untuk meminimalkan probabilitas keberhasilan penyerang. Misalnya, Ethereum, solusi Ethereum adalah secara acak memilih validator untuk shard tertentu dari semua validator, dan setiap 6,4 menit ( panjang epoch ) mengganti validator.

Secara sederhana, ini berarti membagi node menjadi kelompok secara acak, kemudian membagikan pekerjaan untuk diverifikasi secara independen oleh masing-masing kelompok node.

Namun perlu dicatat bahwa keacakan dalam blockchain adalah topik yang sangat menantang, secara logis, proses penghasil angka acak ini tidak seharusnya bergantung pada perhitungan dari sharding tertentu. Untuk perhitungan ini, banyak desain yang ada saat ini adalah mengembangkan blockchain terpisah, yang memelihara seluruh jaringan. Rantai seperti itu disebut Beacon chain di Ethereum dan Near, Relay chain di PolkaDot, dan Cosmos Hub di Cosmos.

( 02 Transaksi Sharding)

Fragmentasi transaksi mengacu pada pembuatan aturan tentang "transaksi mana yang akan dialokasikan ke fragmen mana", sehingga dapat mencapai tujuan pemrosesan paralel dan menghindari terjadinya masalah pengeluaran ganda. Perbedaan dalam model buku besar blockchain akan mempengaruhi pengembangan fragmentasi transaksi.

Saat ini terdapat dua jenis metode pencatatan dalam jaringan blockchain, yaitu model UTXO### Unspent Transaction Outputs dan model akun/balance, di mana yang pertama diwakili oleh BTC dan yang kedua oleh ETH.

Model UTXO: Dalam transaksi BTC, setiap transaksi akan memiliki satu atau lebih output, UTXO merujuk pada output transaksi blockchain yang belum digunakan, yang dapat digunakan sebagai input untuk transaksi baru, sementara output transaksi yang sudah digunakan tidak dapat digunakan lagi, mirip dengan situasi transaksi uang kertas di mana pelanggan memberikan satu atau lebih uang kertas kepada penjual, dan penjual kemudian mengembalikan satu atau lebih uang kertas sebagai kembalian kepada pelanggan. Di bawah model UTXO, sharding transaksi memerlukan komunikasi antar shard. Sebuah transaksi dapat mencakup beberapa input dan beberapa output, tanpa konsep akun, dan tidak akan ada catatan saldo, salah satu cara yang mungkin adalah: dengan menempatkannya dalam fungsi hash sesuai dengan nilai input transaksi tertentu untuk menghasilkan nilai hash diskret yang menentukan data harus pergi ke shard mana.

Untuk memastikan bahwa entri ditempatkan di shard yang benar dengan cara yang konsisten, nilai yang dimasukkan ke dalam fungsi hash harus berasal dari kolom yang sama. Kolom ini disebut Shard Key. Selanjutnya, transaksi yang menghasilkan nilai 1 akan dimasukkan ke dalam shard 1, sedangkan transaksi yang menghasilkan nilai 2 akan dimasukkan ke dalam shard 2. Namun, kelemahan dari cara ini adalah bahwa shard harus berkomunikasi satu sama lain untuk menghindari serangan double spend. Jika transaksi lintas shard dibatasi, maka itu akan membatasi ketersediaan platform, sedangkan jika transaksi lintas shard diizinkan, maka harus ada pertimbangan antara biaya komunikasi lintas shard dan keuntungan dari peningkatan kinerja.

Model Akun/Saldo: Sistem mencatat saldo setiap akun, saat melakukan transaksi, sistem memeriksa apakah akun memiliki saldo yang cukup untuk pembayaran, mirip dengan transfer bank, di mana bank mencatat saldo setiap akun, hanya ketika saldo akun lebih besar dari jumlah transfer yang diperlukan, transaksi dapat dilakukan. Dalam model akun/saldo, karena sebuah transaksi hanya memiliki satu input, selama transaksi dipecah berdasarkan alamat pengirim, dapat dipastikan bahwa beberapa transaksi dari akun yang sama diproses dalam shard yang sama, secara efektif mencegah double spending. Oleh karena itu, sebagian besar blockchain yang menggunakan teknologi sharding, adalah sistem buku besar akun seperti Ethereum.

( 03 Status Sharding )State Sharding (

Status Sharding mengacu pada bagaimana data blockchain dialokasikan untuk disimpan di berbagai sharding.

Masih menggunakan contoh antrean di supermarket kita, setiap jendela memiliki satu buku kas, bagaimana buku kas mereka mencatatnya? Jika: pelanggan antre di jalur mana, maka catat di buku kas mana, contohnya pelanggan A pergi ke jendela A, lalu keesokan harinya pelanggan tersebut pergi ke jendela pembayaran lain seperti jendela B, sementara jendela B tidak memiliki informasi akun sebelumnya dari pelanggan tersebut ), misalnya yang melibatkan metode pembayaran seperti kartu prabayar ###, apa yang harus dilakukan? Mengambil informasi akun pelanggan tersebut dari jendela A?

Sharding status adalah tantangan terbesar dalam sharding, lebih rumit dibandingkan dengan sharding jaringan dan sharding transaksi yang disebutkan di atas. Karena dalam mekanisme sharding, transaksi akan diproses dalam shard yang berbeda berdasarkan alamat, artinya, status hanya akan disimpan dalam shard tempat alamat tersebut berada. Saat ini, salah satu masalah yang dihadapi adalah, transaksi tidak akan hanya dilakukan dalam satu shard, sering kali melibatkan lintas shard (Cross-Sharding).

Pertimbangkan situasi transfer, Akun A mentransfer 10U ke Akun B, dan alamat A dialokasikan di Sharding 1, catatan transaksi juga akan disimpan di Sharding 1. Alamat B dialokasikan di Sharding 2, catatan transaksi akan disimpan di Sharding 2.

Ketika A ingin mentransfer uang ke B, akan terbentuk transaksi lintas Sharding, Sharding 2 akan memanggil catatan transaksi sebelumnya dari Sharding 1 untuk mengonfirmasi validitas transaksi. Jika A sering mengirimkan koin ke B, Sharding 2 harus terus-menerus berinteraksi dengan Sharding 1, yang akan mengurangi efisiensi pemrosesan transaksi. Namun, jika tidak diunduh dan diverifikasi