! [Skalabilitas DA: Status Tersedia Saat Ini] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-d4e2f4e2b4-dd1a6f-cd5cc0.webp)
Ketika pengguna mulai mengintegrasikan Avail ke dalam desain rantai mereka, pertanyaan sering muncul: "Berapa banyak transaksi yang dapat diproses Avail?" Dalam posting ini, kami akan membandingkan throughput Ethereum dan Avail berdasarkan arsitektur kedua rantai saat ini.
Ini adalah yang pertama dalam seri skalabilitas Avail yang akan membahas kinerja Avail saat ini dan kemampuannya untuk skala dalam waktu dekat dan jangka panjang.
Tersedia vs Ethereum
Blok Ethereum dapat menyimpan hingga 1,875 MB data dan memiliki waktu blok sekitar 13 detik. Namun, blok Ethereum biasanya tidak terisi. Hampir setiap blok tidak akan mencapai batas atas data karena mencapai batas gas, karena baik eksekusi maupun penyelesaian mengkonsumsi gas. Akibatnya, jumlah data yang disimpan di setiap blok bervariasi.
Kebutuhan untuk menggabungkan eksekusi, penyelesaian, dan ketersediaan data di blok yang sama adalah masalah sentral dengan arsitektur blockchain tunggal. Rollup L2 memulai gerakan untuk blockchain modular, memungkinkan operasi eksekusi ditangani pada satu rantai, dan blok rantai didedikasikan untuk eksekusi. Avail mengambil langkah lebih jauh dengan mengadopsi desain modular yang memisahkan ketersediaan data juga, memungkinkan blok rantai didedikasikan untuk ketersediaan data.
! [Skalabilitas DA: Status Tersedia Saat Ini] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-60a64e927d-dd1a6f-cd5cc0.webp)
Saat ini, waktu blok Tersedia adalah 20 detik, dan setiap blok dapat menampung sekitar 2 MB data. Dengan asumsi ukuran transaksi rata-rata 250 byte, setiap blok Avail dapat menampung sekitar 8.400 transaksi hari ini (420 transaksi per detik).
Terlebih lagi, Avail selalu dapat mengisi blok hingga batas penyimpanan dan meningkatkan ukuran sesuai kebutuhan. Kami memiliki sejumlah tuas yang dapat dengan cepat disesuaikan untuk meningkatkan jumlah transaksi per blok menjadi lebih dari 500.000 (25.000 transaksi per detik) bila diperlukan.
Bisakah kita meningkatkan throughput?
Untuk meningkatkan throughput (terutama transaksi per detik), arsitek rantai perlu meningkatkan ukuran blok atau mengurangi waktu blok.
Untuk ditambahkan ke rantai, setiap blok harus menghasilkan komitmen, membangun bukti, menyebarkannya, dan meminta semua node lain memverifikasi bukti tersebut. Langkah-langkah ini selalu membutuhkan waktu, yang menetapkan batas atas alami pada waktu yang dibutuhkan untuk blok yang akan dihasilkan dan dikonfirmasi.
Oleh karena itu, kita tidak bisa begitu saja mengurangi waktu blok menjadi, katakanlah, satu detik. Ini tidak memiliki cukup waktu untuk menghasilkan komitmen, menghasilkan bukti, dan menyebarkan bagian-bagian itu ke semua peserta di seluruh jaringan. Dalam waktu blok satu detik teoretis, bahkan jika setiap peserta jaringan menjalankan mesin paling kuat yang mampu menghasilkan komitmen dan bukti dalam sekejap, hambatannya terletak pada propagasi data. Karena keterbatasan kecepatan internet, jaringan tidak dapat memberi tahu semua node penuh blok dengan cukup cepat. Jadi kita harus memastikan bahwa waktu blok cukup tinggi untuk memungkinkan data didistribusikan ke jaringan setelah konsensus tercapai.
Sebaliknya, dimungkinkan juga untuk meningkatkan throughput dengan meningkatkan ukuran blok, yaitu meningkatkan jumlah data yang dapat kita isi di setiap blok.
Arsitektur Saat Ini: Tambahkan blok ke rantai
Pertama, mari kita lihat langkah-langkah yang diperlukan untuk menambahkan blok ke rantai. Ada tiga langkah utama yang diperlukan untuk menambahkan setiap blok ke rantai. Ini termasuk waktu yang diperlukan untuk menghasilkan blok, menyebarkannya, dan memvalidasinya.
! [Skalabilitas DA: Status Tersedia Saat Ini] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-8d735187bc-dd1a6f-cd5cc0.webp)
1. Pembuatan blok
Langkah ini mencakup waktu yang diperlukan untuk mengumpulkan dan mengurutkan transaksi Avail, membangun komitmen, dan menskalakan (penghapusan coding) matriks data.
Pembuatan blok mengukur waktu yang diperlukan untuk menghasilkan blok, karena ini akan selalu memakan waktu setidaknya beberapa waktu. Oleh karena itu, kita harus memperhitungkan tidak hanya waktu dalam kasus terbaik, tetapi juga situasi rata-rata dan waktu dalam kasus terburuk pada mesin yang berbeda.
Mesin terlemah yang dapat berpartisipasi dalam pembuatan blok baru adalah mesin yang rata-rata mencapai batas kinerja. Semua mesin yang lebih lambat pada akhirnya akan tertinggal karena mereka tidak dapat mengejar mesin yang lebih cepat.
2. Penundaan propagasi
Penundaan propagasi adalah ukuran waktu yang diperlukan untuk menyebarkan blok dari produsen ke validator dan jaringan peer-to-peer.
Saat ini, ukuran blok Avail adalah 2 MB. Dalam batas waktu blok 20 detik saat ini, ukuran blok tersebut dapat disebarkan. Ukuran blok yang lebih besar membuat propagasi lebih rumit.
Misalnya, jika kami meningkatkan Avail untuk mendukung blok 128 MB, perhitungan mungkin dapat diskalakan (sekitar 7 detik). Namun, kemacetan menjadi waktu yang diperlukan untuk mengirim dan mengunduh blok-blok ini di jaringan.
Mengirim blok 128 MB ke dunia melalui jaringan peer-to-peer dalam 5 detik mungkin merupakan batas dari apa yang saat ini dapat dicapai.
Batas 128 MB tidak ada hubungannya dengan ketersediaan data atau skenario komitmen kami, melainkan masalah keterbatasan bandwidth komunikasi.
Kebutuhan untuk memperhitungkan latensi propagasi ini memberi kita batas ukuran blok teoretis Avail saat ini.
3. Validasi blok
Setelah disebarkan, validator yang berpartisipasi tidak hanya mempercayai blok yang diberikan kepada mereka oleh pengusul blok – mereka perlu memverifikasi bahwa blok yang dihasilkan benar-benar berisi data yang diklaim oleh produsen.
Ada ketegangan tertentu antara ketiga langkah ini. Kami dapat membuat semua validator menjadi mesin yang kuat dan terhubung erat oleh jaringan yang sangat baik di pusat data yang sama – ini akan mengurangi waktu produksi dan validasi, dan memungkinkan kami untuk menyebarkan lebih banyak data. Namun, karena kami juga ingin memiliki jaringan yang terdesentralisasi dan beragam dengan berbagai jenis peserta, ini bukan pendekatan yang ideal.
Sebaliknya, peningkatan throughput akan dicapai dengan memahami langkah-langkah yang diperlukan untuk menambahkan blok ke rantai Avail, dan langkah-langkah mana yang dapat dioptimalkan.
! [Skalabilitas DA: Status Tersedia Saat Ini] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-1d534dd1ad-dd1a6f-cd5cc0.webp)
Saat ini, validator yang menggunakan Avail mengambil seluruh blok dan menyalin semua komitmen yang dihasilkan oleh pengusul untuk memvalidasi blok. Ini berarti bahwa produsen blok dan semua validator perlu melakukan setiap langkah dalam bagan di atas.
Dalam satu blockchain, ini adalah praktik default untuk setiap validator untuk merekonstruksi seluruh blok. Namun, pada rantai seperti Avail, di mana transaksi tidak dieksekusi, pembangunan kembali ini tidak diperlukan. Oleh karena itu, salah satu cara kami dapat mengoptimalkan Avail adalah dengan memungkinkan validator mencapai jaminan ketersediaan data mereka sendiri melalui pengambilan sampel, bukan dengan merekonstruksi blok. Ini kurang intensif sumber daya untuk validator daripada mengharuskan mereka untuk mereplikasi semua komitmen. Lebih lanjut tentang ini di artikel mendatang.
Bagaimana cara kerja pengambilan sampel ketersediaan data eksplorasi?
Di Avail, klien ringan menggunakan tiga alat inti untuk mengonfirmasi ketersediaan data: sampel, komitmen, dan bukti.
Saat ini klien ringan melakukan operasi sampel yang meminta nilai sel tertentu dan bukti validitas terkait dari jaringan Avail. Semakin banyak sampel yang mereka ambil, semakin yakin mereka bahwa semua data tersedia.
Komitmen dihasilkan oleh pengusul blok dan merangkum seluruh baris data dalam blok Avail. (Petunjuk: Ini adalah langkah yang akan kita optimalkan nanti dalam seri ini.) ）
Setiap sel dalam jaringan menghasilkan bukti. Klien ringan menggunakan pengesahan dan janji untuk memverifikasi bahwa nilai sel yang diberikan kepada mereka sudah benar.
Dengan menggunakan alat-alat ini, klien cahaya kemudian melakukan tiga langkah.
Keputusan: Keyakinan ketersediaan yang diperlukan menentukan jumlah sampel untuk eksekusi klien ringan. Mereka tidak membutuhkan banyak sampel (8-30 sampel) untuk mencapai jaminan ketersediaan lebih dari 99,95%.
Unduh: Klien ringan kemudian meminta sampel ini dan bukti terkaitnya dan mengunduhnya dari jaringan (node penuh atau klien ringan lainnya).
Validasi: Mereka melihat janji di header blok (yang selalu dapat diakses oleh klien ringan) dan memverifikasi bukti setiap sel terhadap janji.
Dengan ini saja, klien ringan dapat mengkonfirmasi ketersediaan semua data dalam blok tanpa harus mengunduh sebagian besar konten blok. Langkah-langkah lain yang diambil oleh klien ringan juga berkontribusi pada keamanan Avail, tetapi tidak tercantum di sini. Misalnya, klien ringan dapat berbagi sampel dan bukti yang mereka unduh dengan klien ringan lainnya jika perlu. Tapi itulah prosedur untuk klien ringan untuk mengkonfirmasi ketersediaan data!
Di bagian kedua dari seri ini, kita akan mengeksplorasi cara untuk meningkatkan throughput Avail dalam jangka pendek. Kami akan menjelaskan mengapa kami yakin Avail dapat memenuhi kebutuhan jaringan apa pun di tahun mendatang, dan bagaimana kami dapat meningkatkan jaringan untuk memenuhi tantangan di tahun-tahun mendatang.
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.
Skalabilitas DA: Status ketersediaan saat ini
! [Skalabilitas DA: Status Tersedia Saat Ini] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-d4e2f4e2b4-dd1a6f-cd5cc0.webp)
Ketika pengguna mulai mengintegrasikan Avail ke dalam desain rantai mereka, pertanyaan sering muncul: "Berapa banyak transaksi yang dapat diproses Avail?" Dalam posting ini, kami akan membandingkan throughput Ethereum dan Avail berdasarkan arsitektur kedua rantai saat ini.
Ini adalah yang pertama dalam seri skalabilitas Avail yang akan membahas kinerja Avail saat ini dan kemampuannya untuk skala dalam waktu dekat dan jangka panjang.
Tersedia vs Ethereum
Blok Ethereum dapat menyimpan hingga 1,875 MB data dan memiliki waktu blok sekitar 13 detik. Namun, blok Ethereum biasanya tidak terisi. Hampir setiap blok tidak akan mencapai batas atas data karena mencapai batas gas, karena baik eksekusi maupun penyelesaian mengkonsumsi gas. Akibatnya, jumlah data yang disimpan di setiap blok bervariasi.
Kebutuhan untuk menggabungkan eksekusi, penyelesaian, dan ketersediaan data di blok yang sama adalah masalah sentral dengan arsitektur blockchain tunggal. Rollup L2 memulai gerakan untuk blockchain modular, memungkinkan operasi eksekusi ditangani pada satu rantai, dan blok rantai didedikasikan untuk eksekusi. Avail mengambil langkah lebih jauh dengan mengadopsi desain modular yang memisahkan ketersediaan data juga, memungkinkan blok rantai didedikasikan untuk ketersediaan data.
! [Skalabilitas DA: Status Tersedia Saat Ini] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-60a64e927d-dd1a6f-cd5cc0.webp)
Saat ini, waktu blok Tersedia adalah 20 detik, dan setiap blok dapat menampung sekitar 2 MB data. Dengan asumsi ukuran transaksi rata-rata 250 byte, setiap blok Avail dapat menampung sekitar 8.400 transaksi hari ini (420 transaksi per detik).
Terlebih lagi, Avail selalu dapat mengisi blok hingga batas penyimpanan dan meningkatkan ukuran sesuai kebutuhan. Kami memiliki sejumlah tuas yang dapat dengan cepat disesuaikan untuk meningkatkan jumlah transaksi per blok menjadi lebih dari 500.000 (25.000 transaksi per detik) bila diperlukan.
Bisakah kita meningkatkan throughput?
Untuk meningkatkan throughput (terutama transaksi per detik), arsitek rantai perlu meningkatkan ukuran blok atau mengurangi waktu blok.
Untuk ditambahkan ke rantai, setiap blok harus menghasilkan komitmen, membangun bukti, menyebarkannya, dan meminta semua node lain memverifikasi bukti tersebut. Langkah-langkah ini selalu membutuhkan waktu, yang menetapkan batas atas alami pada waktu yang dibutuhkan untuk blok yang akan dihasilkan dan dikonfirmasi.
Oleh karena itu, kita tidak bisa begitu saja mengurangi waktu blok menjadi, katakanlah, satu detik. Ini tidak memiliki cukup waktu untuk menghasilkan komitmen, menghasilkan bukti, dan menyebarkan bagian-bagian itu ke semua peserta di seluruh jaringan. Dalam waktu blok satu detik teoretis, bahkan jika setiap peserta jaringan menjalankan mesin paling kuat yang mampu menghasilkan komitmen dan bukti dalam sekejap, hambatannya terletak pada propagasi data. Karena keterbatasan kecepatan internet, jaringan tidak dapat memberi tahu semua node penuh blok dengan cukup cepat. Jadi kita harus memastikan bahwa waktu blok cukup tinggi untuk memungkinkan data didistribusikan ke jaringan setelah konsensus tercapai.
Sebaliknya, dimungkinkan juga untuk meningkatkan throughput dengan meningkatkan ukuran blok, yaitu meningkatkan jumlah data yang dapat kita isi di setiap blok.
Arsitektur Saat Ini: Tambahkan blok ke rantai
Pertama, mari kita lihat langkah-langkah yang diperlukan untuk menambahkan blok ke rantai. Ada tiga langkah utama yang diperlukan untuk menambahkan setiap blok ke rantai. Ini termasuk waktu yang diperlukan untuk menghasilkan blok, menyebarkannya, dan memvalidasinya.
! [Skalabilitas DA: Status Tersedia Saat Ini] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-8d735187bc-dd1a6f-cd5cc0.webp)
1. Pembuatan blok
Langkah ini mencakup waktu yang diperlukan untuk mengumpulkan dan mengurutkan transaksi Avail, membangun komitmen, dan menskalakan (penghapusan coding) matriks data.
Pembuatan blok mengukur waktu yang diperlukan untuk menghasilkan blok, karena ini akan selalu memakan waktu setidaknya beberapa waktu. Oleh karena itu, kita harus memperhitungkan tidak hanya waktu dalam kasus terbaik, tetapi juga situasi rata-rata dan waktu dalam kasus terburuk pada mesin yang berbeda.
Mesin terlemah yang dapat berpartisipasi dalam pembuatan blok baru adalah mesin yang rata-rata mencapai batas kinerja. Semua mesin yang lebih lambat pada akhirnya akan tertinggal karena mereka tidak dapat mengejar mesin yang lebih cepat.
2. Penundaan propagasi
Penundaan propagasi adalah ukuran waktu yang diperlukan untuk menyebarkan blok dari produsen ke validator dan jaringan peer-to-peer.
Saat ini, ukuran blok Avail adalah 2 MB. Dalam batas waktu blok 20 detik saat ini, ukuran blok tersebut dapat disebarkan. Ukuran blok yang lebih besar membuat propagasi lebih rumit.
Misalnya, jika kami meningkatkan Avail untuk mendukung blok 128 MB, perhitungan mungkin dapat diskalakan (sekitar 7 detik). Namun, kemacetan menjadi waktu yang diperlukan untuk mengirim dan mengunduh blok-blok ini di jaringan.
Mengirim blok 128 MB ke dunia melalui jaringan peer-to-peer dalam 5 detik mungkin merupakan batas dari apa yang saat ini dapat dicapai.
Batas 128 MB tidak ada hubungannya dengan ketersediaan data atau skenario komitmen kami, melainkan masalah keterbatasan bandwidth komunikasi.
Kebutuhan untuk memperhitungkan latensi propagasi ini memberi kita batas ukuran blok teoretis Avail saat ini.
3. Validasi blok
Setelah disebarkan, validator yang berpartisipasi tidak hanya mempercayai blok yang diberikan kepada mereka oleh pengusul blok – mereka perlu memverifikasi bahwa blok yang dihasilkan benar-benar berisi data yang diklaim oleh produsen.
Ada ketegangan tertentu antara ketiga langkah ini. Kami dapat membuat semua validator menjadi mesin yang kuat dan terhubung erat oleh jaringan yang sangat baik di pusat data yang sama – ini akan mengurangi waktu produksi dan validasi, dan memungkinkan kami untuk menyebarkan lebih banyak data. Namun, karena kami juga ingin memiliki jaringan yang terdesentralisasi dan beragam dengan berbagai jenis peserta, ini bukan pendekatan yang ideal.
Sebaliknya, peningkatan throughput akan dicapai dengan memahami langkah-langkah yang diperlukan untuk menambahkan blok ke rantai Avail, dan langkah-langkah mana yang dapat dioptimalkan.
! [Skalabilitas DA: Status Tersedia Saat Ini] (https://img-cdn.gateio.im/webp-social/moments-7f230462a9-1d534dd1ad-dd1a6f-cd5cc0.webp)
Saat ini, validator yang menggunakan Avail mengambil seluruh blok dan menyalin semua komitmen yang dihasilkan oleh pengusul untuk memvalidasi blok. Ini berarti bahwa produsen blok dan semua validator perlu melakukan setiap langkah dalam bagan di atas.
Dalam satu blockchain, ini adalah praktik default untuk setiap validator untuk merekonstruksi seluruh blok. Namun, pada rantai seperti Avail, di mana transaksi tidak dieksekusi, pembangunan kembali ini tidak diperlukan. Oleh karena itu, salah satu cara kami dapat mengoptimalkan Avail adalah dengan memungkinkan validator mencapai jaminan ketersediaan data mereka sendiri melalui pengambilan sampel, bukan dengan merekonstruksi blok. Ini kurang intensif sumber daya untuk validator daripada mengharuskan mereka untuk mereplikasi semua komitmen. Lebih lanjut tentang ini di artikel mendatang.
Bagaimana cara kerja pengambilan sampel ketersediaan data eksplorasi?
Di Avail, klien ringan menggunakan tiga alat inti untuk mengonfirmasi ketersediaan data: sampel, komitmen, dan bukti.
Dengan menggunakan alat-alat ini, klien cahaya kemudian melakukan tiga langkah.
Dengan ini saja, klien ringan dapat mengkonfirmasi ketersediaan semua data dalam blok tanpa harus mengunduh sebagian besar konten blok. Langkah-langkah lain yang diambil oleh klien ringan juga berkontribusi pada keamanan Avail, tetapi tidak tercantum di sini. Misalnya, klien ringan dapat berbagi sampel dan bukti yang mereka unduh dengan klien ringan lainnya jika perlu. Tapi itulah prosedur untuk klien ringan untuk mengkonfirmasi ketersediaan data!
Di bagian kedua dari seri ini, kita akan mengeksplorasi cara untuk meningkatkan throughput Avail dalam jangka pendek. Kami akan menjelaskan mengapa kami yakin Avail dapat memenuhi kebutuhan jaringan apa pun di tahun mendatang, dan bagaimana kami dapat meningkatkan jaringan untuk memenuhi tantangan di tahun-tahun mendatang.