Hai,

Skalabilitas transaksi telah menjadi pembicaraan di kota. Kami telah menjelajahi bagaimana Monad membantu meningkatkan TPS selama beberapa minggu terakhir.

Catatan di bawah ini adalah pembahasan tentang bagaimana Monad bekerja yang ditulis oleh @desh_saurabhPertimbangkan untuk mendaftar diDecentralised.cojika Anda menikmati membaca penjelas data-driven tentang semua hal Web3. Sampai jumpa di sisi lain!

TPS adalah metrik yang kami obsesifkan. Kami ingin rantai kami mendukung TPS yang lebih tinggi karena mereka dapat mendukung lebih banyak pengguna dan aplikasi. Grafik di bawah ini menunjukkan angka TPS untuk Ethereum dan L2s. Tidak satu pun rantai pernah melebihi angka 100 TPS. Perhatikan bahwa TPS adalah istilah umum untuk mengukur skala. TPS tidak akurat karena tidak semua transaksi sama, karena berbeda dalam kompleksitas. Namun, kami menggunakan TPS sebagai ukuran skala untuk kesederhanaan.

Apa yang harus kita lakukan jika kita ingin meningkatkan TPS?

1. Salah satu pendekatan adalah membangun sistem yang benar-benar baru, seperti yang dilakukan Solana. Ia mengorbankan kompatibilitas EVM demi kecepatan. Ia menggunakan eksekusi multi-threaded daripada single-threaded (bayangkan CPU multi-core vs. CPU single-core), memparalelkan transaksi, dan menggunakan mekanisme konsensus yang berbeda.
2. Pendekatan kedua adalah dengan menggunakan eksekusi di luar rantai dan memperluas Ethereum dengan pengurutan terpusat.
3. Yang ketiga adalah memecah EVM menjadi komponen-komponen terpisah dan mengoptimalkannya untuk meningkatkan skalabilitas.

Monad, sebuah L1 baru yang kompatibel dengan EVM yang baru saja mengumpulkan $225 juta, sedang membangun EVM dari awal daripada menggunakannya apa adanya. Itu memilih pendekatan ketiga ini untuk meningkatkan skalabilitas.

Kami membahas beberapa perubahan penting yang Monad bawa ke meja.

Eksekusi Paralel

Mesin Virtual Ethereum (EVM) menjalankan transaksi secara serial. Sampai satu transaksi dijalankan, transaksi berikutnya harus menunggu. Bayangkan begini. Katakan ada platform di gudang perakitan sepeda motor. Beberapa truk menjatuhkan bagian sepeda motor (dengan cara bahwa setiap truk memiliki semua bagian yang diperlukan untuk membuat 50 sepeda motor). Gudang perakitan melakukan empat fungsi berbeda dengan tim yang ditugaskan - pembongkaran, penyortiran, perakitan, dan pemuatan.

Dengan pengaturan EVM saat ini, hanya ada satu platform, dan spot yang sama digunakan untuk memuat dan membongkar. Jadi ketika truk diparkir, komponen sepeda motor dibongkar, disortir, dirakit, dan dimuat ke truk yang sama. Sementara tim pengurutan bekerja, tim lainnya hanya menunggu. Jadi, jika Anda mempertimbangkan pekerjaan mereka sebagai slot yang berbeda, setiap tim hanya bekerja sekali dalam empat slot. Hal ini menyebabkan ketidakefisienan yang signifikan, menyoroti kebutuhan akan pendekatan yang lebih efisien.

Sekarang, bayangkan ada empat platform dengan area pemuatan dan pembongkaran yang berbeda. Bahkan jika tim pembongkaran hanya dapat bekerja dengan satu truk pada satu waktu, mereka tidak perlu menunggu untuk tiga slot berikutnya. Mereka dapat langsung beralih ke truk berikutnya.

Hal yang sama berlaku untuk tim pengurutan, perakitan, dan pemuatan. Begitu muatan truk selesai dimuat, truk bergerak ke area pemuatan dan menunggu tim pemuatan untuk memuat sepeda motor yang sudah dirakit. Jadi, gudang dengan hanya satu platform dan area muat/unload menjalankan segalanya secara berurutan, sedangkan yang memiliki 4 platform dan area muat/unload yang berbeda melakukan proses secara paralel.

Pertimbangkan Monad sebagai infrastruktur yang setara dengan gudang dengan beberapa platform truk – tetapi tidak sesederhana itu. Kompleksitas meningkat ketika truk tergantung. Misalnya, bagaimana jika satu truk tidak memiliki semua bagian untuk membuat 50 sepeda motor? Transaksi mungkin tidak selalu independen. Jadi, ketika Monad mengeksekusinya secara paralel, ia harus berurusan dengan transaksi yang bergantung satu sama lain.

Bagaimana? Ini melakukan sesuatu yang disebut sebagai eksekusi paralel optimis. Protokol hanya dapat menjalankan transaksi independen secara paralel. Sebagai contoh, pertimbangkan 4 transaksi dengan saldo Joel sebesar 1 ETH -

1. Joel mengirimkan 0.2 ETH ke Saurabh.
2. Sid membuat sebuah NFT.
3. Joel mengirim 0.1 ETH ke Sid.
4. Shlok membeli PEPE.

Semua transaksi ini dieksekusi secara paralel dengan hasil yang tertunda yang di-commit satu per satu. Transaksi dijalankan ulang jika output hasil tertunda bertentangan dengan input asli transaksi mana pun. Transaksi 2 dan 4 tidak memiliki hasil tertunda yang bertentangan dengan input transaksi lain karena mereka independen satu sama lain. Namun 1 dan 3 tidak independen.

Perhatikan bahwa karena semua 4 transaksi dimulai dari keadaan yang sama, yang menjadi perhatian di sini adalah saldo Joel sebesar 1 ETH. Hasil dari Joel mengirim 0,2 ETH menghasilkan 0,8 ETH. Setelah Joel mengirim 0,1 ETH ke Sid, saldo nya menjadi 0,9 ETH. Hasilnya dikonfirmasi satu per satu, memastikan bahwa output tidak bertentangan dengan salah satu input. Setelah hasil yang tertunda sebesar 1 dikonfirmasi, saldo baru Joel adalah 0,8 ETH.

Output ini bertentangan dengan input dari 3. Jadi sekarang 3 dijalankan ulang dengan input 0.8 ETH. Setelah 3 dijalankan, saldo Joel adalah 0.7 ETH.

MonadDb

Pada titik ini, pertanyaan yang jelas adalah bagaimana kita tahu bahwa kita tidak perlu mengeksekusi ulang sebagian besar transaksi. Jawabannya terletak pada kenyataan bahwa mengeksekusi ulang bukanlah bottleneck. Bottleneck-nya adalah mengakses memori Ethereum. Ternyata cara Ethereum menyimpan statusnya di database membuatnya sulit (memakan waktu dan mahal) untuk mengakses status tersebut. Di sinilah perbaikan lain Monad masuk ke dalam gambar - MonadDb. Monad telah membangun basis datanya dengan cara yang mengurangi overhead yang terkait dengan operasi baca.

Ketika sebuah transaksi harus dijalankan ulang, semua input sudah berada di memori cache, yang jauh lebih mudah diakses dibandingkan dengan keadaan keseluruhan.

Solana memiliki 50k TPS di testnet-nya tetapi hanya ~1k di mainnet sekarang. Monad mengklaim telah mencapai 10k TPS nyata di internal testnet-nya. Meskipun ini tidak selalu mencerminkan kinerja dunia nyata, kami sangat ingin melihat bagaimana Monad bekerja di alam liar.

Pernyataan:

1. Artikel ini yang berjudul asli “Memahami Monad” direproduksi dari [Gatechaincatcher]. Semua hak cipta milik penulis asli [Decentralised.Co]. Jika Anda memiliki keberatan terhadap pembaruan, silakan hubungi Tim Gate Belajar, tim akan menanganinya sesegera mungkin.

2. Penyangkalan: Pandangan dan opini yang terdapat dalam artikel ini hanya mewakili pandangan pribadi penulis dan tidak merupakan saran 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.