Jalan BNB Chain menuju blok-blok besar

Jalan Blok Besar di Rantai BNB

Serupa dengan Solana, Heco, dan rantai publik lainnya yang didukung oleh bursa, rantai publik BNB Chain, BNB Smart Chain (BSC) telah lama mengejar kinerja tinggi. Sejak diluncurkan pada tahun 2020, BSC telah menetapkan batas kapasitas gas untuk setiap blok menjadi 30 juta, dengan interval blok yang stabil selama 3 detik. Dengan parameter tersebut, BSC mencapai TPS maksimum (TPS dengan berbagai transaksi yang bercampur menjadi satu) lebih dari 100. Pada bulan Juni 2021, batas gas blok BSC ditingkatkan menjadi 60 juta. Namun, pada bulan Juli di tahun yang sama, sebuah permainan berantai yang disebut CryptoBlades meledak di BSC, menyebabkan volume transaksi harian melebihi 8 juta dan menghasilkan biaya yang meroket. Ternyata hambatan efisiensi dari BSC masih cukup jelas terlihat pada saat itu.

(Sumber: BscScan)

Untuk mengatasi masalah kinerja jaringan, BSC sekali lagi menaikkan batas gas untuk setiap blok, yang tetap stabil di sekitar 80-85 juta untuk waktu yang lama. Pada bulan September 2022, batas gas per blok BSC Chain ditingkatkan menjadi 120 juta, dan pada akhir tahun, dinaikkan menjadi 140 juta, hampir lima kali lipat dari tahun 2020. Sebelumnya, BSC telah merencanakan untuk meningkatkan batas kapasitas gas blok menjadi 300 juta, tetapi mungkin mengingat beban berat pada node Validator, proposal untuk blok super besar tersebut belum diimplementasikan.

sumber: YCHARTS

Belakangan, BNB Chain tampaknya lebih fokus pada jalur modular/Layer2 daripada bertahan dalam ekspansi Layer1. Niat ini menjadi semakin nyata dengan diluncurkannya zkBNB pada paruh kedua tahun lalu ke GreenField pada awal tahun ini. Karena ketertarikan yang kuat terhadap blockchain modular/Layer2, penulis artikel ini akan menggunakan opBNB sebagai objek penelitian untuk mengungkap hambatan kinerja Rollup dengan membandingkannya dengan Ethereum Layer2.

Peningkatan throughput tinggi BSC ke lapisan DA opBNB

Seperti yang kita ketahui, Celestia telah merangkum empat komponen utama sesuai dengan alur kerja blockchain modular: Lapisan Eksekusi: Mengeksekusi kode kontrak dan menyelesaikan transisi status; Lapisan Penyelesaian: Menangani bukti penipuan/bukti validitas dan menangani masalah yang menjembatani antara L2 dan L1. Lapisan Konsensus: Mencapai konsensus pada pemesanan transaksi. Lapisan Ketersediaan Data (DA): Menerbitkan data terkait buku besar blockchain, yang memungkinkan validator mengunduh data ini.

Di antara mereka, lapisan DA sering digabungkan dengan lapisan konsensus. Sebagai contoh, data DA Optimistic Rollup berisi sekumpulan urutan transaksi dalam blok L2. Ketika node penuh L2 mendapatkan data DA, mereka mengetahui urutan setiap transaksi dalam batch ini. (Untuk alasan ini, komunitas Ethereum percaya bahwa lapisan DA dan lapisan konsensus saling terkait ketika melapisi Rollup).

Namun, untuk Ethereum Layer2, throughput data dari lapisan DA (Ethereum) telah menjadi hambatan terbesar yang membatasi kinerja Rollup. Hal ini dikarenakan throughput data Ethereum saat ini terlalu rendah, sehingga memaksa Rollup untuk menekan TPS-nya sebanyak mungkin untuk mencegah mainnet Ethereum tidak dapat menanggung data yang dihasilkan oleh L2. Pada saat yang sama, throughput data yang rendah menyebabkan sejumlah besar instruksi transaksi dalam jaringan Ethereum berada dalam kondisi tertunda, yang menyebabkan biaya gas terdorong ke tingkat yang sangat tinggi dan semakin meningkatkan biaya publikasi data untuk Layer2. Akhirnya, banyak jaringan Layer2 harus mengadopsi lapisan DA di luar Ethereum, seperti Celestia, dan opBNB, yang dekat dengan air, telah memilih untuk secara langsung menggunakan throughput tinggi BSC untuk mengimplementasikan DA guna memecahkan masalah kemacetan publikasi data. Untuk memudahkan pemahaman, mari kita perkenalkan metode publikasi data DA untuk Rollup. Mengambil Arbitrum sebagai contoh, rantai Ethereum yang dikendalikan oleh alamat EOA sequencer Layer2 akan secara berkala mengirim Transaksi ke kontrak yang ditentukan. Dalam parameter input calldata dari instruksi ini, data transaksi yang dipaketkan ditulis, dan peristiwa on-chain yang sesuai dipicu, meninggalkan catatan permanen dalam log kontrak.

Dengan cara ini, data transaksi Layer2 disimpan dalam blok Ethereum untuk waktu yang lama. Orang-orang yang mampu menjalankan node L2 dapat mengunduh catatan yang sesuai dan mengurai data yang sesuai, tetapi node Ethereum sendiri tidak melakukan transaksi L2 ini. Sangat mudah untuk melihat bahwa L2 hanya menyimpan data transaksi dalam blok Ethereum, yang menimbulkan biaya penyimpanan, sementara biaya komputasi untuk mengeksekusi transaksi ditanggung oleh node L2 itu sendiri. Hal yang disebutkan di atas adalah metode implementasi DA Arbitrum, sedangkan Optimism menggunakan alamat EOA yang dikendalikan oleh sequencer untuk mentransfer ke alamat EOA lain yang ditentukan, membawa kumpulan data transaksi Layer2 baru dalam data tambahan. Sedangkan untuk opBNB, yang menggunakan OP Stack, metode penerbitan data DA-nya pada dasarnya sama dengan Optimism.

Jelas bahwa throughput dari lapisan DA akan membatasi ukuran data yang dapat dipublikasikan oleh Rollup dalam satu unit waktu, sehingga membatasi TPS. Mempertimbangkan bahwa setelah EIP1559, kapasitas gas setiap blok ETH stabil pada 30 juta, dan waktu blok setelah penggabungan adalah sekitar 12 detik, Ethereum dapat menangani maksimum hanya 2,5 juta gas per detik. Sebagian besar waktu, gas yang dikonsumsi untuk mengakomodasi data transaksi L2 per byte dalam calldata adalah 16, sehingga Ethereum dapat menangani ukuran calldata maksimum hanya 150 KB per detik. Sebaliknya, rata-rata ukuran calldata maksimum BSC yang diproses per detik adalah sekitar 2910 KB, yang merupakan 18,6 kali lipat dari Ethereum. Perbedaan antara keduanya sebagai lapisan DA sangat jelas.

Sebagai rangkuman, Ethereum dapat membawa sekitar 150 KB data transaksi L2 per detik. Bahkan setelah peluncuran EIP 4844, angka ini tidak akan banyak berubah, hanya mengurangi biaya DA. Jadi, berapa banyak data transaksi yang dapat dimasukkan dalam sekitar 150KB per detik? Di sini kami perlu menjelaskan tingkat kompresi data Rollup. Vitalik terlalu optimis pada tahun 2021, memperkirakan bahwa Optimistic Rollup dapat mengompresi ukuran data transaksi hingga 11% dari ukuran aslinya. Sebagai contoh, transfer ETH dasar, yang awalnya menggunakan ukuran calldata 112 byte, dapat dikompresi menjadi 12 byte dengan Optimistic Rollup, transfer ERC-20 dapat dikompresi menjadi 16 byte, dan transaksi Swap di Uniswap dapat dikompresi menjadi 14 byte. Menurut perkiraannya, Ethereum dapat mencatat sekitar 10.000 transaksi L2 per detik (dengan berbagai jenis yang bercampur menjadi satu). Namun, menurut data yang diungkapkan oleh tim Optimism pada tahun 2022, tingkat kompresi data yang sebenarnya dapat mencapai maksimum hanya sekitar 37%, atau 3,5 kali lebih rendah dari perkiraan Vitalik.

(Estimasi Vitalik tentang efek skalabilitas Rollup menyimpang secara signifikan dari kondisi aktual)

(Tingkat kompresi aktual yang dicapai oleh berbagai algoritme kompresi yang diungkapkan oleh Optimism)

Jadi, mari kita berikan angka yang masuk akal: bahkan jika Ethereum mencapai batas throughput-nya, TPS maksimum dari semua Optimistic Rollups yang digabungkan hanya sedikit di atas 2000. Dengan kata lain, jika blok Ethereum seluruhnya digunakan untuk membawa data yang diterbitkan oleh Optimistic Rollups, seperti yang didistribusikan di antara Arbitrum, Optimism, Base, dan Boba, TPS gabungan dari Optimistic Rollups ini bahkan tidak akan mencapai 3000, bahkan di bawah algoritme kompresi yang paling efisien. Selain itu, kita harus mempertimbangkan bahwa setelah EIP1559, kapasitas gas setiap blok rata-rata hanya 50% dari nilai maksimum, sehingga angka di atas harus dikurangi setengahnya. Setelah peluncuran EIP4844, meskipun biaya transaksi untuk mempublikasikan data akan berkurang secara signifikan, ukuran blok maksimum Ethereum tidak akan banyak berubah (karena terlalu banyak perubahan akan mempengaruhi keamanan rantai utama ETH), sehingga perkiraan nilai di atas tidak akan berkembang banyak.

Menurut data dari Arbiscan dan Etherscan, satu batch transaksi di Arbitrum berisi 1115 transaksi, menghabiskan 1,81 juta gas di Ethereum. Dengan ekstrapolasi, jika lapisan DA diisi di setiap blok, batas TPS teoritis Arbitrum adalah sekitar 1500. Tentu saja, dengan mempertimbangkan masalah reorganisasi blok L1, Arbitrum tidak dapat mempublikasikan batch transaksi pada setiap blok Ethereum, sehingga angka-angka di atas saat ini hanya bersifat teoritis. Selain itu, dengan meluasnya adopsi dompet pintar yang terkait dengan EIP 4337, masalah DA akan menjadi lebih parah. Karena dengan dukungan untuk EIP 4337, cara pengguna memverifikasi identitas mereka dapat disesuaikan, seperti mengunggah data biner sidik jari atau iris mata, yang selanjutnya akan meningkatkan ukuran data yang ditempati oleh transaksi reguler. Oleh karena itu, throughput data Ethereum yang rendah merupakan hambatan terbesar yang membatasi efisiensi Rollup, dan masalah ini mungkin tidak akan terselesaikan dengan baik untuk waktu yang lama. Di sisi lain, dalam Rantai BNB dari rantai publik BSC, rata-rata ukuran calldata maksimum yang diproses per detik adalah sekitar 2910 KB, yang merupakan 18,6 kali lipat dari Ethereum. Dengan kata lain, selama lapisan eksekusi dapat mengimbangi, batas atas TPS teoritis dari Layer2 dalam ekosistem Rantai BNB dapat mencapai sekitar 18 kali lipat dari ARB atau OP. Jumlah ini dihitung berdasarkan kapasitas maksimum blok gas BNB Chain saat ini sebesar 140 juta, dengan waktu blok 3 detik.

Dengan kata lain, batas TPS agregat saat ini dari semua Rollup dalam ekosistem BNB Chain adalah 18,6 kali lipat dari Ethereum (bahkan ketika mempertimbangkan ZKRollup). Dari perspektif ini, mudah untuk memahami mengapa begitu banyak proyek Layer2 menggunakan lapisan DA di bawah rantai Ethereum untuk mempublikasikan data, karena perbedaannya cukup jelas. Namun, masalahnya tidak sesederhana itu. Selain masalah throughput data, stabilitas Layer1 itu sendiri juga dapat mempengaruhi Layer2. Sebagai contoh, sebagian besar Rollup sering kali menunggu selama beberapa menit sebelum menerbitkan sekumpulan transaksi ke Ethereum, dengan mempertimbangkan kemungkinan reorganisasi blok Layer1. Jika blok Layer1 direorganisasi, ini akan mempengaruhi buku besar blockchain Layer2. Oleh karena itu, sequencer akan menunggu beberapa blok Layer1 baru untuk diterbitkan setelah setiap rilis batch transaksi L2, yang secara signifikan mengurangi kemungkinan rollback blok, sebelum menerbitkan batch transaksi L2 berikutnya. Hal ini sebenarnya menunda waktu ketika blok L2 akhirnya dikonfirmasi, mengurangi kecepatan konfirmasi transaksi besar (transaksi besar membutuhkan hasil yang tidak dapat diubah untuk memastikan keamanan). Singkatnya, transaksi yang terjadi di L2 hanya menjadi ireversibel setelah dipublikasikan di blok lapisan DA dan setelah lapisan DA menghasilkan sejumlah blok baru. Ini adalah alasan penting yang membatasi kinerja Rollup. Akan tetapi, Ethereum memiliki kecepatan pembuatan blok yang lambat, membutuhkan waktu 12 detik untuk menghasilkan sebuah blok. Dengan asumsi Rollup menerbitkan satu batch transaksi L2 setiap 15 blok, akan ada interval 3 menit di antara batch yang berbeda, dan setelah setiap batch diterbitkan, ia masih perlu menunggu beberapa blok Layer1 dihasilkan sebelum menjadi ireversibel (dengan asumsi tidak ditantang). Jelas, waktu dari inisiasi hingga ireversibilitas transaksi pada Layer2 Ethereum cukup lama, menghasilkan kecepatan penyelesaian yang lambat; sedangkan, Rantai BNB hanya membutuhkan waktu 3 detik untuk menghasilkan satu blok, dan blok menjadi ireversibel hanya dalam waktu 45 detik (waktu yang dibutuhkan untuk menghasilkan 15 blok baru). Berdasarkan parameter saat ini, dengan asumsi jumlah transaksi L2 yang sama dan mempertimbangkan ireversibilitas blok L1, berapa kali opBNB dapat mempublikasikan data transaksi dalam satu unit waktu dapat mencapai 8,53 kali lipat dari Arbitrum (sekali setiap 45 detik untuk yang pertama, dan sekali setiap 6,4 menit untuk yang terakhir). Jelas, kecepatan penyelesaian transaksi besar di opBNB jauh lebih cepat daripada di Layer2 Ethereum. Selain itu, ukuran data maksimum yang diterbitkan oleh opBNB setiap kali dapat mencapai 4,66 kali lipat dari Layer2 Ethereum (batas gas blok L1 Ethereum adalah 140 juta, sedangkan yang terakhir adalah 30 juta). 8.53 * 4.66 = 39.74. Hal ini menunjukkan kesenjangan antara opBNB dan Arbitrum dalam hal batas TPS dalam implementasi praktis (saat ini, untuk alasan keamanan, ARB tampaknya secara aktif mengurangi TPS, tetapi secara teoritis, jika TPS ditingkatkan, masih akan berkali-kali lipat lebih rendah dibandingkan dengan opBNB).

(Sequencer Arbitrum menerbitkan batch transaksi setiap 6-7 menit)

(Sequencer opBNB menerbitkan batch transaksi setiap 1-2 menit, dengan waktu tercepat hanya 45 detik). Tentu saja, ada masalah krusial lain yang perlu dipertimbangkan, yaitu biaya gas di lapisan DA. Setiap kali L2 menerbitkan batch transaksi, ada biaya tetap sebesar 21.000 gas yang tidak terkait dengan ukuran calldata, yang merupakan biaya. Jika biaya gas untuk lapisan DA/L1 tinggi, menyebabkan biaya tetap penerbitan batch transaksi pada L2 tetap tinggi, sequencer akan mengurangi frekuensi penerbitan batch transaksi. Selain itu, ketika mempertimbangkan komponen biaya L2, biaya lapisan eksekusi sangat rendah dan sering kali dapat diabaikan, dengan hanya berfokus pada dampak biaya DA pada biaya transaksi. Singkatnya, meskipun penerbitan calldata dengan ukuran yang sama mengkonsumsi jumlah gas yang sama di Ethereum dan BNB Chain, harga gas yang dibebankan oleh Ethereum sekitar 10 hingga puluhan kali lebih tinggi daripada BNB Chain. Diterjemahkan ke dalam biaya transaksi L2, biaya transaksi pengguna saat ini di Ethereum Layer2 juga sekitar 10 hingga puluhan kali lebih tinggi daripada biaya transaksi di opBNB. Secara keseluruhan, perbedaan antara opBNB dan Optimistic Rollup di Ethereum cukup jelas.

(Transaksi yang menghabiskan 150.000 gas di Optimism dikenakan biaya $0,21)

(Transaksi yang menggunakan 130.000 gas di opBNB dikenakan biaya $0,004) Namun, meningkatkan throughput data pada lapisan DA, meskipun dapat meningkatkan throughput keseluruhan sistem Layer2, masih memiliki dampak yang terbatas pada peningkatan kinerja masing-masing Rollups. Ini karena lapisan eksekusi sering kali tidak memproses transaksi dengan cukup cepat. Bahkan jika keterbatasan lapisan DA dapat diabaikan, lapisan eksekusi menjadi hambatan berikutnya yang mempengaruhi kinerja Rollup. Jika kecepatan eksekusi lapisan eksekusi Layer2 lambat, limpahan permintaan transaksi akan menyebar ke Layer2 lainnya, yang pada akhirnya menyebabkan fragmentasi likuiditas. Oleh karena itu, meningkatkan kinerja lapisan eksekusi juga sangat penting, berfungsi sebagai ambang batas lain di atas lapisan DA.

Peningkatan opBNB di Lapisan Eksekusi: Pengoptimalan Cache

Ketika kebanyakan orang mendiskusikan hambatan kinerja lapisan eksekusi blockchain, mereka pasti menyebutkan dua hambatan penting: eksekusi serial berulir tunggal dari EVM yang gagal memanfaatkan CPU sepenuhnya, dan pencarian data yang tidak efisien dari Merkle Patricia Trie yang diadopsi oleh Ethereum. Pada intinya, strategi penskalaan untuk lapisan eksekusi berkisar pada penggunaan sumber daya CPU yang lebih efisien dan memastikan bahwa CPU dapat mengakses data secepat mungkin.

Solusi pengoptimalan untuk eksekusi EVM serial dan Merkle Patricia Trie sering kali rumit dan menantang untuk diimplementasikan, sementara upaya yang lebih hemat biaya cenderung berfokus pada pengoptimalan cache. Faktanya, pengoptimalan cache membawa kita kembali ke poin-poin yang sering dibahas dalam konteks Web2 tradisional dan bahkan buku teks.

Biasanya, kecepatan CPU mengambil data dari memori ratusan kali lebih cepat daripada mengambil data dari disk. Sebagai contoh, mengambil data dari memori mungkin hanya memerlukan waktu 0,1 detik, sedangkan mengambil data dari disk mungkin memerlukan waktu 10 detik. Oleh karena itu, mengurangi overhead yang dihasilkan oleh pembacaan dan penulisan disk, yaitu pengoptimalan cache, menjadi aspek penting dalam mengoptimalkan lapisan eksekusi blockchain.

Dalam Ethereum dan sebagian besar rantai publik lainnya, database yang mencatat status alamat on-chain disimpan sepenuhnya pada disk, sedangkan yang disebut trie World State hanyalah sebuah indeks dari database ini, atau sebuah direktori yang digunakan untuk pencarian data. Setiap kali EVM mengeksekusi kontrak, EVM perlu mengakses status alamat yang relevan. Mengambil data dari basis data berbasis disk satu per satu akan memperlambat eksekusi transaksi secara signifikan. Oleh karena itu, menyiapkan cache di luar basis data/disk adalah cara yang diperlukan untuk mempercepat.

opBNB secara langsung mengadopsi solusi pengoptimalan cache yang digunakan oleh BNB Chain. Menurut informasi yang diungkapkan oleh mitra opBNB, NodeReal, rantai BSC yang paling awal menyiapkan tiga lapisan cache antara EVM dan database LevelDB yang menyimpan status. Konsep desainnya mirip dengan cache tiga tingkat tradisional, di mana data dengan frekuensi akses yang lebih tinggi disimpan dalam cache. Hal ini memungkinkan CPU untuk terlebih dahulu mencari data yang diperlukan dalam cache. Jika hit rate cache cukup tinggi, CPU tidak perlu terlalu mengandalkan disk untuk mengambil data, sehingga menghasilkan peningkatan yang signifikan dalam kecepatan eksekusi secara keseluruhan.

Kemudian, NodeReal menambahkan fitur di atas ini, yang memanfaatkan inti CPU yang tidak terpakai untuk membaca terlebih dahulu data yang perlu diproses oleh EVM di masa depan dari database dan menyimpannya di cache. Fitur ini disebut "state preloading."

Prinsip dari state preloading adalah sederhana: CPU node blockchain adalah multi-core, sedangkan EVM beroperasi dalam mode eksekusi serial berulir tunggal, hanya menggunakan satu inti CPU, sehingga inti CPU lainnya tidak digunakan. Untuk mengatasi hal ini, inti CPU yang tidak digunakan oleh EVM dapat membantu tugas-tugas dengan memprediksi data yang dibutuhkan EVM dari urutan transaksi yang belum diproses. Inti CPU di luar EVM ini kemudian akan mengambil data yang dibutuhkan EVM dari database, membantu EVM mengurangi overhead pengambilan data dan dengan demikian mempercepat eksekusi.

Dengan optimalisasi cache dan konfigurasi perangkat keras yang memadai, opBNB secara efektif mendorong kinerja lapisan eksekusi simpulnya mendekati batas EVM, memproses hingga 100 juta gas per detik. 100 juta gas ini pada dasarnya adalah batas tertinggi kinerja EVM yang tidak dimodifikasi, seperti yang ditunjukkan oleh data pengujian eksperimental dari rantai publik terkemuka.

Secara ringkas, opBNB dapat memproses hingga 4761 transfer sederhana per detik, 15003000 transfer token ERC20 per detik, dan sekitar 5001000 operasi SWAP per detik berdasarkan data transaksi yang diamati pada penjelajah blockchain. Membandingkan parameter saat ini, batas TPS opBNB adalah 40 kali lipat dari Ethereum, lebih dari 2 kali lipat dari BNB Chain, dan lebih dari 6 kali lipat dari Optimism.

Tentu saja, untuk solusi Ethereum Layer2, karena keterbatasan yang parah dari lapisan DA itu sendiri, kinerjanya didiskon secara signifikan berdasarkan kinerja lapisan eksekusi, ketika mempertimbangkan faktor-faktor seperti waktu pembuatan blok lapisan DA dan stabilitas.

Untuk Rantai BNB dengan lapisan DA throughput tinggi seperti opBNB, efek penggandaan penskalaan sangat berharga, terutama mengingat Rantai BNB dapat menjadi tuan rumah beberapa proyek penskalaan semacam itu. Dapat diramalkan bahwa BNB Chain telah memasukkan solusi Layer2 yang dipimpin opBNB ke dalam rencana strategisnya, dan akan terus melanjutkan proyek-proyek blockchain yang lebih modular, termasuk memperkenalkan bukti ZK ke dalam opBNB dan menyediakan lapisan DA dengan ketersediaan tinggi dengan infrastruktur pelengkap seperti GreenField, dalam upaya untuk bersaing atau bekerja sama dengan ekosistem Ethereum Layer2.

Di era di mana penskalaan berlapis telah menjadi tren, apakah rantai publik lain juga akan terburu-buru untuk mendukung proyek Layer2 mereka sendiri masih harus dilihat, tetapi tidak diragukan lagi, pergeseran paradigma menuju infrastruktur blockchain modular sudah terjadi.

Penafian: Penafian

1. Artikel ini dicetak ulang dari[极客 Web3], Semua hak cipta adalah milik penulis asli[Faust, 极客web3]. Jika ada keberatan dengan pencetakan ulang ini, silakan hubungi tim Gate Learn, dan mereka akan segera menanganinya.
2. Penafian Tanggung Jawab: Pandangan dan pendapat yang diungkapkan dalam artikel ini semata-mata merupakan pandangan dan pendapat penulis dan bukan merupakan saran investasi.
3. Penerjemahan artikel ke dalam bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel terjemahan dilarang.