Bagaimana rekan-rekan dalam jaringan blockchain dapat yakin bahwa semua data dari blok yang baru diusulkan tersedia? Dan mengapa ini penting?

Dalam pos ini, kami menyelami detail masalah ketersediaan data dan bagaimana hal itu dapat berdampak pada peningkatan skala di Ethereum.

Apa masalah Ketersediaan Data?

Masalah Ketersediaan Data (DA): Bagaimana rekan-rekan dalam jaringan blockchain bisa yakin bahwa semua data dari blok yang baru diusulkan benar-benar tersedia? Jika data tidak tersedia, blok tersebut mungkin mengandung transaksi jahat yang disembunyikan oleh produsen blok. Bahkan jika blok tersebut berisi transaksi non-jahat, menyembunyikannya bisa membahayakan keamanan sistem.

Untuk memberikan contoh, misalkan Alice adalah seorang operator dari sebuah ZK-Rollup (ZKR)Dia mengirimkan Bukti ZK di Ethereum yang diverifikasi. Jika dia tidak mengirimkan semua data transaksional di Ethereum, meskipun buktinya membuktikan bahwa semua transisi status yang diambil dalam rollup valid, pengguna rollup mungkin tidak mengetahui saldo akun saat ini. Bukti yang diajukan tidak memberikan informasi apapun tentang status saat ini karena sifat Pengetahuan Nol dari bukti tersebut.

Ada contoh analog yang ada di Optimistic Rollup (OPR)pengaturan, di mana Alice mengajukan pernyataan di Ethereum, tetapi tidak ada dari peserta OPR yang dapat menantangnya karena data transaksional tidak tersedia dan oleh karena itu mereka tidak dapat menghitung ulang atau menantang pernyataan tersebut.

Untuk mengatasi skenario di atas, desain OPR dan ZKR mewajibkan operator untuk mengirimkan semua detail transaksi pada Ethereumsebagai ‘calldata’. Meskipun ini membuat mereka menghindari masalah DA dalam jangka pendek, seiring dengan bertambahnya jumlah transaksi di dalam rollups, jumlah data yang perlu disampaikan juga akan bertambah, membatasi jumlah skalabilitas yang dapat ditawarkan oleh rollups ini.

Untuk membuat keadaan menjadi lebih buruk, tidak tersedianya data adalah kesalahan yang tidak dapat diatribusikan secara unik. Ini berarti bahwa peserta tidak dapat membuktikan kepada peserta lain bahwa sebagian data tertentu hilang. Hal ini karena Bob dapat menyiarkan bahwa blok yang dikirimkan oleh Alice memiliki data yang hilang, tetapi ketika Charlie menanyai Alice, dia mungkin memberikan data tersebut kepadanya.

Bagaimana ini memengaruhi blockchain hari ini?

Untuk menjawab pertanyaan ini, mari kita pertama-tama mengulang struktur blok umum dari blockchain mirip Ethereum dan jenis klien yang ada di jaringan blockchain mana pun.

Sebuah blok dapat dibagi menjadi dua bagian utama:

• Header Blok: Sebuah header blok kecil berisi digest dan metadata terkait dengan transaksi yang disertakan dalam blok.
• Tubuh Blok: Ini berisi semua data transaksional dan membentuk sebagian besar ukuran blok.

Dalam protokol blockchain konvensional, semua node dianggap sebagai node penuh yang menyinkronkan seluruh blok dan memverifikasi semua transisi status. Mereka perlu menghabiskan sejumlah besar sumber daya untuk memeriksa validitas transaksi dan menyimpan blok. Di sisi positif, node-node ini tidak dapat dipaksa untuk menerima transaksi yang tidak valid.

Mungkin ada kelas node lain yang tidak memiliki (atau tidak ingin menghabiskan) sumber daya untuk memverifikasi setiap transaksi. Sebaliknya, mereka lebih tertarik untuk mengetahui keadaan terkini dari blockchain dan apakah beberapa transaksi, yang relevan bagi mereka, sudah dimasukkan ke dalam rantai atau tidak. Idealnya, klien ringan ini juga harus dilindungi dari mengikuti rantai yang mengandung transaksi yang tidak valid. Ini sebenarnya memungkinkan menggunakan bukti penipuan yang disebut. Ini adalah pesan singkat yang menunjukkan bahwa tubuh blok tertentu mencakup transaksi yang tidak valid. Setiap node penuh dapat menghasilkan bukti penipuan tersebut, dan klien ringan dengan demikian tidak perlu percaya bahwa node penuh tertentu jujur. Mereka hanya perlu memastikan bahwa mereka terhubung dengan baik ke jaringan desas-desus yang memastikan bahwa jika ada bukti penipuan tersedia untuk header blok, mereka akan menerimanya.

Namun, ada satu masalah dengan sistem ini: bagaimana jika seorang produsen blok tidak menampilkan seluruh data di balik suatu blok. Dalam hal ini, node penuh jelas akan menolak blok tersebut karena menurut pandangan mereka, itu bahkan bukanlah blok jika tidak disertai dengan badan blok. Namun, klien ringan dapat diperlihatkan dengan rantai kepala dan tidak memiliki cara untuk mengetahui bahwa data tersebut hilang. Pada saat yang sama, node penuh tidak dapat menghasilkan bukti penipuan, karena mereka akan kehilangan data yang diperlukan untuk membuat bukti penipuan.

Untuk menanggulangi hal ini, kita memerlukan mekanisme bagi klien ringan untuk memverifikasi ketersediaan data. Hal ini akan memastikan bahwa produsen blok yang menyembunyikan data tidak dapat lolos dengan meyakinkan klien ringan sebaliknya. Hal ini juga akan memaksa produsen blok untuk mengungkap bagian dari data, membuat seluruh jaringan memiliki akses ke seluruh blok secara kolaboratif.

Mari kita menjelajahi sedikit lebih dalam masalah dengan bantuan contoh. Misalkan produsen blok Alice membangun blok B dengan transaksi tx1, tx2, …, txn. Mari kita asumsikan tx1 adalah transaksi jahat. Jika tx1 disiarkan, setiap node penuh dapat memverifikasinya sebagai jahat dan mengirimkan ini ke klien ringan sebagai bukti penipuan yang akan segera tahu bahwa blok itu tidak dapat diterima. Namun, jika Alice ingin menyembunyikan tx1, dia mengungkapkan header dan semua data transaksional kecuali tx1. Node penuh tidak dapat memverifikasi kebenaran tx1.

Seseorang mungkin berpikir solusi sederhana adalah jika semua klien ringan hanya sampel transaksi secara acak, dan jika mereka menemukan sampel mereka tersedia, mereka dapat yakin bahwa blok tersebut tersedia. Biarkan node ringan menanyakan satu transaksi, secara merata secara acak. Kemungkinan bahwa klien ringan menanyakan tx1 adalah 1/n. Jadi, dengan kepastian yang besar, Alice dapat menipu klien ringan untuk menerima transaksi jahat. Dengan kata lain, sebagian besar klien ringan akan tertipu. Karena sifat non-atribusi, node penuh tidak dapat membuktikan dengan cara apa pun bahwa tx1 tidak tersedia. Sayangnya, meningkatkan jumlah sampel tidak membuat ini jauh lebih baik.

Jadi, apa yang harus kita lakukan tentang ini?

Solusi atas masalah ini terletak pada memperkenalkan redundansi ke dalam sebuah blok. Ada kumpulan literatur yang kaya tentang teori pengodean secara umum, dan pengodean penghapusan secara khusus, yang dapat membantu kita dengan masalah ini.

Secara singkat, pemrograman penghapusan memungkinkan kita untuk memperpanjang n potongan data menjadi 2n potongan data sedemikian rupa sehingga n dari 2n sudah cukup untuk merekonstruksi potongan data asli (parameter dapat diatur, tetapi di sini kita pertimbangkan hal ini untuk kesederhanaan).

Jika kita memaksa produsen blok untuk mengkode penghapusan transaksi tx1, tx2, ..., txn, maka, untuk menyembunyikan satu transaksi, perlu menyembunyikan n+1 potongan data karena apa pun n sudah cukup untuk membangun seluruh set transaksi. Dalam kasus ini, sejumlah pertanyaan konstan memberikan keyakinan yang sangat tinggi kepada klien ringan bahwa data yang mendasari memang tersedia.

Woah, jadi ini dia?

Tidak. Meskipun trik sederhana ini membuat pekerjaan menyembunyikan lebih sulit, masih mungkin bahwa produsen blok dengan sengaja melakukan pengkodean penghapusan dengan cara yang salah. Namun, node penuh dapat memverifikasi apakah pengkodean penghapusan ini dilakukan dengan benar dan jika tidak, dapat membuktikan hal ini kepada klien ringan. Ini adalah jenis bukti penipuan lainnya, seperti dalam kasus transaksi jahat di atas. Menariknya, ada harus ada tetangga node penuh yang jujur tunggal dari klien ringan agar dapat dipastikan bahwa jika bloknya jahat, maka akan menerima bukti penipuan. Ini memastikan bahwa klien ringan memiliki akses ke rantai tanpa transaksi jahat dengan probabilitas yang sangat tinggi.

Namun ada suatu masalah. Jika dilakukan secara naif, ukuran beberapa bukti penipuan dapat sebesar ukuran blok itu sendiri. Asumsi sumber daya yang kami miliki pada klien ringan melarang kami menggunakan desain seperti itu. Telah terjadi peningkatan dalam hal ini dengan menggunakan teknik pengkodean penghapusan multi-dimensi yang mengurangi ukuran bukti penipuan dengan biaya ukuran komitmen. Untuk kepentingan kekompakan, kami tidak membahas hal ini tapi kertas inimemiliki analisis yang mendetail tentang itu.

Masalah dengan solusi berbasis bukti kecurangan adalah bahwa klien ringan tidak pernah benar-benar yakin tentang blok mana pun yang belum menerima bukti kecurangan. Mereka juga terus mempercayai rekan node lengkapnya untuk jujur. Node jujur juga perlu didorong untuk terus-menerus melakukan audit blok.

Kami memusatkan perhatian kami di sini pada sistem-sistem yang menjamin jika encoding blok tidak valid, node-node penuh dapat mendeteksinya dan memberikan bukti kepada klien-klien ringan yang meyakinkan mereka akan perilaku yang salah. Namun, di bagian berikutnya, kami akan melihat encoding blok yang menjamin bahwa hanya encoding yang valid yang dapat dimasukkan ke dalam rantai. Hal ini menghilangkan kebutuhan akan bukti penipuan yang membuktikan kesalahan encoding. Solusi-solusi berbasis bukti kevalidan ini memungkinkan aplikasi untuk menggunakan sistem tanpa harus menunggu bukti-bukti penipuan semacam ini dari node-node penuh.

Jadi bagaimana cara kerja solusi-solusi ini?

Baru-baru ini, komitmen polinomial telah menarik minat yang baru dari ruang blockchain. Komitmen polinomial ini, terutama yang komitmen KZG/Kate berukuran konstan untuk polinomial, dapat digunakan untuk merancang skema DA yang rapi tanpa perlu bukti kecurangan. Singkatnya, komitmen KZG memungkinkan kita untuk mengkomitmenkan polinomial menggunakan satu elemen grup kurva eliptik. Selain itu, skema ini mendukung kita untuk membuktikan bahwa pada suatu titik i polinomial φ dievaluasi menjadi φ(i) menggunakan saksi berukuran tetap. Skema komitmen ini secara komputasional mengikat dan juga homomorfik, memungkinkan kita untuk menghindari bukti kecurangan dengan rapi.

Kami memaksa produsen blok untuk mengambil data transaksional asli dan mengatur dalam matriks 2D berukuran n x m. Ini menggunakan interpolasi polinomial untuk memperluas setiap kolom berukuran n menjadi kolom berukuran 2n. Setiap baris dari matriks yang diperluas ini menghasilkan komitmen polinomial dan mengirimkan komitmen ini sebagai bagian dari header blok. Representasi skematis dari blok diberikan di bawah ini.

Klien ringan mengajukan pertanyaan tentang sel mana pun dari matriks yang diperluas ini untuk mendapatkan saksi yang memungkinkannya untuk segera memverifikasinya terhadap header blok. Bukti keanggotaan berukuran konstan membuat sampelannya sangat efisien. Sifat homomorfik dari komitmen memastikan bahwa bukti hanya diverifikasi jika blok dibangun dengan benar dan interpolasi polinomial memastikan bahwa jumlah sampel yang berhasil konstan berarti data tersebut tersedia dengan probabilitas yang sangat tinggi.

Representasi skematis dari blok

Detail-detail yang lebih halus dari skema bersama dengan optimisasi lebih lanjut dan perkiraan biaya berada di luar lingkup artikel ini. Namun, kami ingin menunjukkan bahwa meskipun kami membahas skema 2D di sini, jaminan serupa dapat diberikan dengan skema 1D juga, yang memiliki ukuran header yang lebih kecil dengan biaya kurang paralelisme dan efisiensi sampel klien ringan. Kami akan menyelami lebih dalam dalam artikel lanjutan.

Apa alternatif lainnya dan apa selanjutnya?

Kode penghapusan dimensi yang lebih tinggi dan komitmen KZG bukanlah satu-satunya cara untuk mendekati masalah DA. Ada cara lain yang kami lewati di sini seperti Pohon Merkle Terkode, Pohon Interleaving Terkode, FRI, dan pendekatan berbasis STARK, tetapi masing-masing memiliki kelebihan dan kekurangan.

Di Avail, kami telah bekerja pada solusi Ketersediaan Data menggunakan komitmen KZG. Pada postingan selanjutnya, kami akan membahas detail implementasi, bagaimana Anda dapat menggunakannya hari ini, dan bagaimana kami bertujuan untuk mengubah ruang masalah DA. Untuk informasi lebih lanjut mengenai Avail, ikuti kami di Twitterdan bergabung dengan kamiserver Discord.

Disclaimer：

1. Artikel ini dicetak ulang dari [Gate.io]Tim Tersedia]. Semua hak cipta dimiliki oleh penulis asli [Tim Avail]. Jika ada keberatan terhadap cetak ulang ini, silakan hubungi [GateGate Belajartim, dan mereka akan menanganinya dengan segera.

2. Penafian Tanggung Jawab: Pandangan dan opini yang terdapat dalam artikel ini semata-mata milik penulis dan tidak merupakan nasihat investasi apa pun.

3. Terjemahan artikel ke dalam bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel yang diterjemahkan dilarang.