! [Apa masalah dengan ketersediaan data?] (https://piccdn.0daily.com/202310/25080444/tnfnxd82p4sv8fpe.jpg!webp)
Dalam jaringan blockchain, bagaimana node memastikan bahwa semua data untuk blok yang baru diusulkan tersedia?
Dalam posting ini, kami akan menyelami lebih dalam masalah ketersediaan data dan bagaimana pengaruhnya terhadap skalabilitas Ethereum.
Apa masalah ketersediaan data?
Masalah ketersediaan data (DA): Bagaimana node dalam jaringan blockchain memastikan bahwa semua data dalam blok yang baru diusulkan benar-benar tersedia, dan jika data tidak tersedia, blok tersebut mungkin berisi transaksi berbahaya yang disembunyikan oleh produsen blok. Bahkan jika blok berisi transaksi yang tidak berbahaya, menyembunyikannya dapat mengancam keamanan sistem.
Misalnya, katakanlah Alice adalah operator ZK-Rollup. Dia mengajukan ZK-Proof di Ethereum dan diverifikasi. Jika dia tidak mengirimkan semua data transaksi di Ethereum, pengguna rollup mungkin masih tidak tahu tentang saldo akun mereka saat ini, meskipun buktinya mengkonfirmasi bahwa semua transisi status yang dibuat dalam rollup itu valid. Karena sifat tanpa pengetahuan, bukti yang diajukan tidak dapat mengungkapkan informasi tentang keadaan saat ini.
Dalam kasus Optimistic Rollup, ada contoh serupa di mana Alice mengajukan pernyataan tentang Ethereum, tetapi peserta dalam OPR tidak dapat menghitung ulang atau menantang klaim karena data transaksi tidak tersedia.
Menanggapi hal di atas, baik OPR dan ZKR dirancang untuk mengharuskan operator mengirimkan semua detail transaksi ke Ethereum sebagai "calldata". Meskipun ini memungkinkan mereka untuk menghindari masalah DA dalam jangka pendek, karena jumlah transaksi dalam rollup meningkat, begitu juga jumlah data yang perlu dikirimkan, membatasi jumlah penskalaan yang dapat disediakan oleh rollup ini.
Lebih buruk lagi, ketidaktersediaan data adalah kesalahan yang tidak dapat dikaitkan secara unik. Ini berarti bahwa peserta tidak dapat membuktikan kepada node lain bahwa blok data tertentu hilang. Ini karena Bob dapat menyiarkan bahwa blok yang dikirimkan oleh Alice adalah data yang hilang, tetapi Charlie dapat memberikan data kepada Alice ketika dia menanyainya.
Bagaimana masalah ketersediaan data memengaruhi blockchain saat ini?
Untuk menjawab pertanyaan ini, pertama-tama mari kita tinjau struktur blok umum blockchain seperti Ethereum, dan jenis klien yang ada di jaringan blockchain mana pun.
Sebuah blok dapat dibagi menjadi dua bagian utama:
Block Header: Header blok kecil berisi ringkasan dan metadata yang terkait dengan transaksi yang terkandung dalam blok.
Block Body: Berisi semua data transaksi dan membentuk bagian utama dari blok.
Dalam protokol blockchain tradisional, semua node dianggap node penuh, dan mereka menyinkronkan seluruh blok dan memverifikasi semua transisi status. Mereka membutuhkan banyak sumber daya untuk memeriksa validitas transaksi dan menyimpan blok. Keuntungannya adalah node ini tidak akan menerima transaksi yang tidak valid.
Mungkin ada jenis node lain yang tidak memiliki (atau tidak ingin menghabiskan) sumber daya untuk memvalidasi setiap transaksi. Sebaliknya, mereka terutama tertarik untuk memahami keadaan blockchain saat ini dan apakah beberapa transaksi yang terkait dengannya termasuk dalam rantai. Idealnya, klien ringan ini juga harus dilindungi dari tipuan oleh rantai yang berisi transaksi tidak valid. Ini sebenarnya dapat dicapai dengan menggunakan apa yang dikenal sebagai bukti penipuan. Pesan singkat ini menunjukkan bahwa blok tertentu berisi transaksi yang tidak valid. Setiap full node dapat menghasilkan bukti penipuan seperti itu, sehingga klien ringan tidak perlu mempercayai full node tertentu untuk jujur. Mereka hanya perlu memastikan bahwa mereka terhubung dengan baik ke jaringan gosip yang memastikan bahwa jika ada bukti penipuan dari header blok yang tersedia, mereka akan menerimanya.
Namun, ada masalah dengan sistem ini: bagaimana jika produsen blok tidak mengungkapkan seluruh data di balik blok? Dalam hal ini, full node jelas akan menolak blok karena, menurut pendapat mereka, jika blok tidak datang dengan badan blok, maka itu bahkan bukan blok. Namun, klien ringan dapat terkena header blok dan tidak menyadari bahwa data hilang. Pada saat yang sama, full node tidak dapat menghasilkan bukti penipuan karena mereka tidak memiliki data yang diperlukan untuk membuat bukti penipuan.
Untuk mengatasi hal ini, kami memerlukan mekanisme bagi klien ringan untuk memverifikasi ketersediaan data. Ini akan memastikan bahwa produsen blok yang menyembunyikan data tidak dapat dihindari dengan meyakinkan klien ringan. Ini juga akan memaksa produsen blok untuk mengungkapkan beberapa data, memungkinkan seluruh jaringan untuk mengakses data untuk seluruh blok secara kolaboratif.
Mari kita lihat lebih dalam masalah ini dengan sebuah contoh. Katakanlah produser blok Alice membangun blok B yang berisi transaksi tx 1, tx 2, 、...、 txn. Katakanlah tx 1 adalah transaksi berbahaya. Jika tx 1 disiarkan, setiap node penuh dapat memverifikasi bahwa itu berbahaya dan mengirimkan informasi ini sebagai bukti penipuan ke klien ringan, yang akan segera tahu bahwa blok tersebut tidak dapat diterima. Namun, jika Alice ingin menyembunyikan tx 1, dia hanya mengungkapkan header dan semua data transaksi kecuali tx 1. Node penuh tidak dapat memverifikasi kebenaran tx 1.
Orang mungkin berpikir bahwa solusi sederhana adalah meminta semua klien ringan mengambil sampel transaksi secara acak, dan jika mereka menemukan bahwa sampel mereka tersedia, mereka dapat yakin bahwa blok tersebut tersedia. Namun, jika simpul cahaya diminta untuk menanyakan transaksi apa pun secara acak, probabilitas bahwa klien ringan akan menanyakan tx 1 adalah 1/n. Akibatnya, Alice hampir selalu dapat mengelabui klien ringan agar menerima transaksi berbahaya. Dengan kata lain, sebagian besar klien ringan dipalsukan. Karena sifat non-atribusi, node penuh tidak dapat membuktikan dengan cara apa pun bahwa tx 1 tidak tersedia. Sayangnya, meningkatkan ukuran sampel tidak membuat segalanya menjadi lebih baik.
Jadi, bagaimana kita mengatasi masalah ini?
Solusi untuk masalah ini terletak pada memperkenalkan redundansi dalam blok. Ada seperangkat literatur yang kaya yang dapat membantu kita memecahkan masalah ini ketika datang ke teori pengkodean, terutama pengkodean penghapusan.
Singkatnya, pengkodean penghapusan memungkinkan kita untuk memperluas n blok data menjadi 2 n blok sehingga n dari setiap 2 n cukup untuk merekonstruksi data asli (parameternya dapat disesuaikan, tetapi di sini kami mempertimbangkan kasus ini demi penyederhanaan).
Jika kita memaksa produsen blok untuk menghapus transaksi tx 1, tx 2, 、...、 txn, maka untuk menyembunyikan satu transaksi, perlu menyembunyikan n + 1 potongan, karena setiap n potongan sudah cukup untuk membangun seluruh rangkaian transaksi. Dalam hal ini, sejumlah kecil kueri dapat memberi klien ringan tingkat kepercayaan yang tinggi bahwa data yang mendasarinya memang tersedia.
Woah, jadi begitu?
Tidak. Meskipun trik sederhana ini membuatnya lebih sulit untuk menyembunyikan data, masih mungkin bahwa produsen blok sengaja menghapus pengkodean dengan cara yang salah. Namun, full node dapat memverifikasi bahwa pengkodean penghapusan ini dilakukan dengan benar, dan jika tidak, dapat membuktikannya kepada klien ringan. Ini adalah jenis lain dari bukti penipuan, sama seperti transaksi jahat yang disebutkan di atas. Menariknya, yang diperlukan hanyalah simpul penuh yang jujur untuk bertindak sebagai tetangga klien ringan, memastikan bahwa jika sebuah blok berbahaya, maka ia akan menerima bukti penipuan. Ini memastikan bahwa klien ringan dapat mengakses rantai dengan probabilitas yang sangat tinggi untuk bebas dari transaksi berbahaya.
Tapi ada tangkapan. Jika dilakukan terlalu sederhana, beberapa bukti penipuan mungkin sebesar ukuran blok itu sendiri. Asumsi sumber daya kami untuk klien ringan melarang kami menggunakan desain seperti itu. Perbaikan telah dilakukan melalui penggunaan teknik pengkodean penghapusan multidimensi yang telah mengurangi ukuran bukti penipuan, tetapi dengan biaya meningkatkan ukuran janji. Demi singkatnya, kami tidak akan membahas secara rinci tentang ini di sini, tetapi makalah ini memberikan analisis terperinci tentang mereka.
Masalah dengan solusi proof-of-fraud adalah bahwa klien ringan tidak pernah dapat sepenuhnya yakin akan blok apa pun yang belum menerima bukti penipuan. Pada saat yang sama, mereka terus percaya bahwa node penuh mereka jujur. Node yang jujur juga perlu diberi insentif untuk secara konsisten meninjau blok.
Apa yang kita lihat di sini adalah sistem-sistem yang menjamin bahwa jika pengkodean blok tidak valid, node penuh dapat mendeteksi dan memberikan bukti kepada klien ringan untuk meyakinkan mereka tentang kesalahan. Namun, di bagian selanjutnya, kami akan fokus pada kode blok yang menjamin bahwa hanya kode valid yang dapat dikirimkan ke rantai. Ini menghilangkan kebutuhan akan bukti penipuan yang perlu membuktikan kesalahan pengkodean. Solusi proof-of-validity memungkinkan aplikasi untuk menggunakan sistem tanpa harus menunggu node penuh untuk memberikan jenis bukti penipuan ini.
Jadi, bagaimana cara kerja solusi ini?
Baru-baru ini, janji-janji polinomial telah memicu minat baru di ruang blockchain. Komitmen polinomial ini, terutama komitmen KZG / Kate ukuran konstan untuk polinomial, dapat digunakan untuk merancang skema ketersediaan data bersih (DA) yang tidak memerlukan bukti penipuan. Singkatnya, janji KZG memungkinkan kita untuk berkomitmen pada polinomial menggunakan elemen grup kurva eliptik tunggal. Selain itu, skema ini memungkinkan kita untuk membuktikan bahwa pada titik tertentu i, nilai φ polinomial adalah φ (i), menggunakan saksi ukuran konstan. Skema komitmen ini mengikat secara komputasi dan homomorfik, memungkinkan kami untuk secara cerdik menghindari bukti penipuan.
Kami memaksa produsen blok untuk mengatur data transaksi mentah ke dalam matriks dua dimensi ukuran n x m. Ini menggunakan interpolasi polinomial untuk memperluas ukuran n dari setiap kolom ke kolom ukuran 2 n. Setiap baris matriks yang diperluas ini menghasilkan komitmen polinomial dan mengirimkan komitmen tersebut sebagai bagian dari header blok. Representasi skematis dari blok diberikan di bawah ini.
Klien ringan menanyakan sel apa pun dari matriks yang diperluas ini untuk bukti, yang memungkinkannya diverifikasi terhadap header blok secara instan. Identifikasi anggota ukuran konstan membuat pengambilan sampel menjadi sangat efisien. Homomorfisme berkomitmen memastikan bahwa bukti hanya dapat diverifikasi jika blok dibangun dengan benar, sementara interpolasi polinomial memastikan jumlah sampel sukses yang konstan yang berarti bahwa kemungkinan ketersediaan data sangat tinggi.
! [Apa masalah dengan ketersediaan data?] (https://piccdn.0daily.com/202311/17064433/5gjxe19ptk6oa203.png!webp)
Representasi skematis dari sebuah blok
Bagian yang lebih rinci dari skenario ini, serta pengoptimalan lebih lanjut dan perkiraan biaya, berada di luar cakupan artikel ini. Namun, kami ingin menunjukkan bahwa sementara kita berbicara tentang skema 2D di sini, jaminan serupa juga dapat diberikan melalui skema 1D dengan ukuran header blok yang lebih kecil, tetapi dengan biaya paralelisme yang berkurang dan efisiensi pengambilan sampel klien yang ringan. Kami akan mengeksplorasi ini secara lebih mendalam dalam artikel lanjutan.
Apa alternatif lain? Apa yang terjadi selanjutnya?
Pengkodean penghapusan dimensi tinggi dan komitmen KZG bukan satu-satunya cara untuk menyelesaikan masalah ketersediaan data. Kami telah melewatkan beberapa pendekatan lain di sini, seperti pengkodean pohon Merkle, pengkodean pohon yang disisipkan, FRI, dan metode berbasis STARK, tetapi masing-masing memiliki kelebihan dan kekurangan.
Di Avail, kami telah menggunakan komitmen KZG untuk mengembangkan solusi ketersediaan data. Dalam artikel berikutnya, kami akan membahas detail implementasi, cara menggunakannya, dan bagaimana kami berencana untuk mengubah ruang masalah ketersediaan data. Untuk mempelajari lebih lanjut tentang Avail, ikuti kami di Twitter
Twitter adalah platform layanan jejaring sosial yang berasal dari Amerika Serikat. Pada 27 Oktober 2022, Musk menyelesaikan akuisisi Twitter dan menggabungkannya menjadi perusahaan "X" yang baru dibentuk. Menurut pesan Twitter Musk sebelumnya, ia akan membuat aplikasi all-inclusive, dan menyebutkan bahwa membeli Twitter dapat mempercepat keinginan ini.
, dan bergabunglah dengan server Discord kami.
Twitter:
Perselisihan:
Ikuti Modular 101 di Twitter di @Modular 101
Lihat Asli
Halaman ini mungkin berisi konten pihak ketiga, yang disediakan untuk tujuan informasi saja (bukan pernyataan/jaminan) dan tidak boleh dianggap sebagai dukungan terhadap pandangannya oleh Gate, atau sebagai nasihat keuangan atau profesional. Lihat Penafian untuk detailnya.
Apa masalahnya dengan ketersediaan data?
! [Apa masalah dengan ketersediaan data?] (https://piccdn.0daily.com/202310/25080444/tnfnxd82p4sv8fpe.jpg!webp)
Dalam jaringan blockchain, bagaimana node memastikan bahwa semua data untuk blok yang baru diusulkan tersedia?
Dalam posting ini, kami akan menyelami lebih dalam masalah ketersediaan data dan bagaimana pengaruhnya terhadap skalabilitas Ethereum.
Apa masalah ketersediaan data?
Masalah ketersediaan data (DA): Bagaimana node dalam jaringan blockchain memastikan bahwa semua data dalam blok yang baru diusulkan benar-benar tersedia, dan jika data tidak tersedia, blok tersebut mungkin berisi transaksi berbahaya yang disembunyikan oleh produsen blok. Bahkan jika blok berisi transaksi yang tidak berbahaya, menyembunyikannya dapat mengancam keamanan sistem.
Misalnya, katakanlah Alice adalah operator ZK-Rollup. Dia mengajukan ZK-Proof di Ethereum dan diverifikasi. Jika dia tidak mengirimkan semua data transaksi di Ethereum, pengguna rollup mungkin masih tidak tahu tentang saldo akun mereka saat ini, meskipun buktinya mengkonfirmasi bahwa semua transisi status yang dibuat dalam rollup itu valid. Karena sifat tanpa pengetahuan, bukti yang diajukan tidak dapat mengungkapkan informasi tentang keadaan saat ini.
Dalam kasus Optimistic Rollup, ada contoh serupa di mana Alice mengajukan pernyataan tentang Ethereum, tetapi peserta dalam OPR tidak dapat menghitung ulang atau menantang klaim karena data transaksi tidak tersedia.
Menanggapi hal di atas, baik OPR dan ZKR dirancang untuk mengharuskan operator mengirimkan semua detail transaksi ke Ethereum sebagai "calldata". Meskipun ini memungkinkan mereka untuk menghindari masalah DA dalam jangka pendek, karena jumlah transaksi dalam rollup meningkat, begitu juga jumlah data yang perlu dikirimkan, membatasi jumlah penskalaan yang dapat disediakan oleh rollup ini.
Lebih buruk lagi, ketidaktersediaan data adalah kesalahan yang tidak dapat dikaitkan secara unik. Ini berarti bahwa peserta tidak dapat membuktikan kepada node lain bahwa blok data tertentu hilang. Ini karena Bob dapat menyiarkan bahwa blok yang dikirimkan oleh Alice adalah data yang hilang, tetapi Charlie dapat memberikan data kepada Alice ketika dia menanyainya.
Bagaimana masalah ketersediaan data memengaruhi blockchain saat ini?
Untuk menjawab pertanyaan ini, pertama-tama mari kita tinjau struktur blok umum blockchain seperti Ethereum, dan jenis klien yang ada di jaringan blockchain mana pun.
Sebuah blok dapat dibagi menjadi dua bagian utama:
Dalam protokol blockchain tradisional, semua node dianggap node penuh, dan mereka menyinkronkan seluruh blok dan memverifikasi semua transisi status. Mereka membutuhkan banyak sumber daya untuk memeriksa validitas transaksi dan menyimpan blok. Keuntungannya adalah node ini tidak akan menerima transaksi yang tidak valid.
Mungkin ada jenis node lain yang tidak memiliki (atau tidak ingin menghabiskan) sumber daya untuk memvalidasi setiap transaksi. Sebaliknya, mereka terutama tertarik untuk memahami keadaan blockchain saat ini dan apakah beberapa transaksi yang terkait dengannya termasuk dalam rantai. Idealnya, klien ringan ini juga harus dilindungi dari tipuan oleh rantai yang berisi transaksi tidak valid. Ini sebenarnya dapat dicapai dengan menggunakan apa yang dikenal sebagai bukti penipuan. Pesan singkat ini menunjukkan bahwa blok tertentu berisi transaksi yang tidak valid. Setiap full node dapat menghasilkan bukti penipuan seperti itu, sehingga klien ringan tidak perlu mempercayai full node tertentu untuk jujur. Mereka hanya perlu memastikan bahwa mereka terhubung dengan baik ke jaringan gosip yang memastikan bahwa jika ada bukti penipuan dari header blok yang tersedia, mereka akan menerimanya.
Namun, ada masalah dengan sistem ini: bagaimana jika produsen blok tidak mengungkapkan seluruh data di balik blok? Dalam hal ini, full node jelas akan menolak blok karena, menurut pendapat mereka, jika blok tidak datang dengan badan blok, maka itu bahkan bukan blok. Namun, klien ringan dapat terkena header blok dan tidak menyadari bahwa data hilang. Pada saat yang sama, full node tidak dapat menghasilkan bukti penipuan karena mereka tidak memiliki data yang diperlukan untuk membuat bukti penipuan.
Untuk mengatasi hal ini, kami memerlukan mekanisme bagi klien ringan untuk memverifikasi ketersediaan data. Ini akan memastikan bahwa produsen blok yang menyembunyikan data tidak dapat dihindari dengan meyakinkan klien ringan. Ini juga akan memaksa produsen blok untuk mengungkapkan beberapa data, memungkinkan seluruh jaringan untuk mengakses data untuk seluruh blok secara kolaboratif.
Mari kita lihat lebih dalam masalah ini dengan sebuah contoh. Katakanlah produser blok Alice membangun blok B yang berisi transaksi tx 1, tx 2, 、...、 txn. Katakanlah tx 1 adalah transaksi berbahaya. Jika tx 1 disiarkan, setiap node penuh dapat memverifikasi bahwa itu berbahaya dan mengirimkan informasi ini sebagai bukti penipuan ke klien ringan, yang akan segera tahu bahwa blok tersebut tidak dapat diterima. Namun, jika Alice ingin menyembunyikan tx 1, dia hanya mengungkapkan header dan semua data transaksi kecuali tx 1. Node penuh tidak dapat memverifikasi kebenaran tx 1.
Orang mungkin berpikir bahwa solusi sederhana adalah meminta semua klien ringan mengambil sampel transaksi secara acak, dan jika mereka menemukan bahwa sampel mereka tersedia, mereka dapat yakin bahwa blok tersebut tersedia. Namun, jika simpul cahaya diminta untuk menanyakan transaksi apa pun secara acak, probabilitas bahwa klien ringan akan menanyakan tx 1 adalah 1/n. Akibatnya, Alice hampir selalu dapat mengelabui klien ringan agar menerima transaksi berbahaya. Dengan kata lain, sebagian besar klien ringan dipalsukan. Karena sifat non-atribusi, node penuh tidak dapat membuktikan dengan cara apa pun bahwa tx 1 tidak tersedia. Sayangnya, meningkatkan ukuran sampel tidak membuat segalanya menjadi lebih baik.
Jadi, bagaimana kita mengatasi masalah ini?
Solusi untuk masalah ini terletak pada memperkenalkan redundansi dalam blok. Ada seperangkat literatur yang kaya yang dapat membantu kita memecahkan masalah ini ketika datang ke teori pengkodean, terutama pengkodean penghapusan.
Singkatnya, pengkodean penghapusan memungkinkan kita untuk memperluas n blok data menjadi 2 n blok sehingga n dari setiap 2 n cukup untuk merekonstruksi data asli (parameternya dapat disesuaikan, tetapi di sini kami mempertimbangkan kasus ini demi penyederhanaan).
Jika kita memaksa produsen blok untuk menghapus transaksi tx 1, tx 2, 、...、 txn, maka untuk menyembunyikan satu transaksi, perlu menyembunyikan n + 1 potongan, karena setiap n potongan sudah cukup untuk membangun seluruh rangkaian transaksi. Dalam hal ini, sejumlah kecil kueri dapat memberi klien ringan tingkat kepercayaan yang tinggi bahwa data yang mendasarinya memang tersedia.
Woah, jadi begitu?
Tidak. Meskipun trik sederhana ini membuatnya lebih sulit untuk menyembunyikan data, masih mungkin bahwa produsen blok sengaja menghapus pengkodean dengan cara yang salah. Namun, full node dapat memverifikasi bahwa pengkodean penghapusan ini dilakukan dengan benar, dan jika tidak, dapat membuktikannya kepada klien ringan. Ini adalah jenis lain dari bukti penipuan, sama seperti transaksi jahat yang disebutkan di atas. Menariknya, yang diperlukan hanyalah simpul penuh yang jujur untuk bertindak sebagai tetangga klien ringan, memastikan bahwa jika sebuah blok berbahaya, maka ia akan menerima bukti penipuan. Ini memastikan bahwa klien ringan dapat mengakses rantai dengan probabilitas yang sangat tinggi untuk bebas dari transaksi berbahaya.
Tapi ada tangkapan. Jika dilakukan terlalu sederhana, beberapa bukti penipuan mungkin sebesar ukuran blok itu sendiri. Asumsi sumber daya kami untuk klien ringan melarang kami menggunakan desain seperti itu. Perbaikan telah dilakukan melalui penggunaan teknik pengkodean penghapusan multidimensi yang telah mengurangi ukuran bukti penipuan, tetapi dengan biaya meningkatkan ukuran janji. Demi singkatnya, kami tidak akan membahas secara rinci tentang ini di sini, tetapi makalah ini memberikan analisis terperinci tentang mereka.
Masalah dengan solusi proof-of-fraud adalah bahwa klien ringan tidak pernah dapat sepenuhnya yakin akan blok apa pun yang belum menerima bukti penipuan. Pada saat yang sama, mereka terus percaya bahwa node penuh mereka jujur. Node yang jujur juga perlu diberi insentif untuk secara konsisten meninjau blok.
Apa yang kita lihat di sini adalah sistem-sistem yang menjamin bahwa jika pengkodean blok tidak valid, node penuh dapat mendeteksi dan memberikan bukti kepada klien ringan untuk meyakinkan mereka tentang kesalahan. Namun, di bagian selanjutnya, kami akan fokus pada kode blok yang menjamin bahwa hanya kode valid yang dapat dikirimkan ke rantai. Ini menghilangkan kebutuhan akan bukti penipuan yang perlu membuktikan kesalahan pengkodean. Solusi proof-of-validity memungkinkan aplikasi untuk menggunakan sistem tanpa harus menunggu node penuh untuk memberikan jenis bukti penipuan ini.
Jadi, bagaimana cara kerja solusi ini?
Baru-baru ini, janji-janji polinomial telah memicu minat baru di ruang blockchain. Komitmen polinomial ini, terutama komitmen KZG / Kate ukuran konstan untuk polinomial, dapat digunakan untuk merancang skema ketersediaan data bersih (DA) yang tidak memerlukan bukti penipuan. Singkatnya, janji KZG memungkinkan kita untuk berkomitmen pada polinomial menggunakan elemen grup kurva eliptik tunggal. Selain itu, skema ini memungkinkan kita untuk membuktikan bahwa pada titik tertentu i, nilai φ polinomial adalah φ (i), menggunakan saksi ukuran konstan. Skema komitmen ini mengikat secara komputasi dan homomorfik, memungkinkan kami untuk secara cerdik menghindari bukti penipuan.
Kami memaksa produsen blok untuk mengatur data transaksi mentah ke dalam matriks dua dimensi ukuran n x m. Ini menggunakan interpolasi polinomial untuk memperluas ukuran n dari setiap kolom ke kolom ukuran 2 n. Setiap baris matriks yang diperluas ini menghasilkan komitmen polinomial dan mengirimkan komitmen tersebut sebagai bagian dari header blok. Representasi skematis dari blok diberikan di bawah ini.
Klien ringan menanyakan sel apa pun dari matriks yang diperluas ini untuk bukti, yang memungkinkannya diverifikasi terhadap header blok secara instan. Identifikasi anggota ukuran konstan membuat pengambilan sampel menjadi sangat efisien. Homomorfisme berkomitmen memastikan bahwa bukti hanya dapat diverifikasi jika blok dibangun dengan benar, sementara interpolasi polinomial memastikan jumlah sampel sukses yang konstan yang berarti bahwa kemungkinan ketersediaan data sangat tinggi.
! [Apa masalah dengan ketersediaan data?] (https://piccdn.0daily.com/202311/17064433/5gjxe19ptk6oa203.png!webp)
Representasi skematis dari sebuah blok
Bagian yang lebih rinci dari skenario ini, serta pengoptimalan lebih lanjut dan perkiraan biaya, berada di luar cakupan artikel ini. Namun, kami ingin menunjukkan bahwa sementara kita berbicara tentang skema 2D di sini, jaminan serupa juga dapat diberikan melalui skema 1D dengan ukuran header blok yang lebih kecil, tetapi dengan biaya paralelisme yang berkurang dan efisiensi pengambilan sampel klien yang ringan. Kami akan mengeksplorasi ini secara lebih mendalam dalam artikel lanjutan.
Apa alternatif lain? Apa yang terjadi selanjutnya?
Pengkodean penghapusan dimensi tinggi dan komitmen KZG bukan satu-satunya cara untuk menyelesaikan masalah ketersediaan data. Kami telah melewatkan beberapa pendekatan lain di sini, seperti pengkodean pohon Merkle, pengkodean pohon yang disisipkan, FRI, dan metode berbasis STARK, tetapi masing-masing memiliki kelebihan dan kekurangan.
Di Avail, kami telah menggunakan komitmen KZG untuk mengembangkan solusi ketersediaan data. Dalam artikel berikutnya, kami akan membahas detail implementasi, cara menggunakannya, dan bagaimana kami berencana untuk mengubah ruang masalah ketersediaan data. Untuk mempelajari lebih lanjut tentang Avail, ikuti kami di Twitter
Twitter adalah platform layanan jejaring sosial yang berasal dari Amerika Serikat. Pada 27 Oktober 2022, Musk menyelesaikan akuisisi Twitter dan menggabungkannya menjadi perusahaan "X" yang baru dibentuk. Menurut pesan Twitter Musk sebelumnya, ia akan membuat aplikasi all-inclusive, dan menyebutkan bahwa membeli Twitter dapat mempercepat keinginan ini.
, dan bergabunglah dengan server Discord kami.
Twitter:
Perselisihan:
Ikuti Modular 101 di Twitter di @Modular 101