Makalah ini menganalisis teknologi kunci dari sequencer bersama: sangat tahan sensor, mudah diterapkan, dapat dioperasikan, cepat ditentukan, dan instan. Teori agregasi memberikan perspektif baru untuk itu, dan integrasi vertikal memandu perkembangan lebih lanjut.
Judul asli: "The Shared Sequencer"
Ditulis oleh: MAVEN11
Kompilasi: Kxp, BlockBeats
Bayangkan bagaimana jadinya jika Rollup "out of the box" dapat mencapai ketahanan sensor tingkat tinggi, kemudahan penerapan, interoperabilitas, penyelesaian cepat, keaktifan, dan demokratisasi MEV. Itu mungkin tampak seperti tujuan besar, tetapi dengan munculnya Shared Sequencer, itu mungkin akan segera menjadi kenyataan. Namun, tidak semua Rollup sama, jadi kami harus mempertimbangkan cara mendistribusikan hadiah dan MEV di jaringan sequencer bersama. Dalam makalah ini, kami mengeksplorasi bagaimana jaringan ranker bersama diimplementasikan, dan properti yang dapat dicapai.
Shared Sequencer Networks pertama kali diperkenalkan oleh Alex Beckett, kemudian oleh Evan Forbes (dan Radius) dari tim Celestia dan Espresso, dan sebuah artikel baru oleh Jon Charbonneau yang membahas topik tersebut secara lebih mendalam. Josh, Jordan, dan tim Astria mereka sedang membangun jaringan sequencer bersama pertama yang siap produksi. Jaringan Pemesan Bersama Astria adalah blockchain modular yang menggabungkan dan memesan transaksi Rollup tanpa mengeksekusinya.
Dalam penyiapan Astria, penyortir mengirimkan blok yang dipesan ke lapisan DA dan juga ke node Rollup. Rollup mendapatkan jaminan soft finality dari pemesan dan jaminan hard finality dari lapisan DA (setelah blok diselesaikan), dan kemudian mereka akan melakukan transaksi yang valid.
Jaringan sequencer bersama pada dasarnya adalah grup sequencer yang kompatibel dengan Rollup, seperti namanya, dapat menyediakan layanan untuk Rollup yang berbeda. Ini memiliki berbagai pengorbanan dan properti, yang akan kami jelaskan nanti. Pertama, kita harus menjelaskan properti paling penting dari penyortir (atau kumpulan penyortir). Dalam Rollup, persyaratan utama untuk sequencer atau grup sequencer adalah ketahanan sensor atau liveness (beberapa di antaranya berasal dari lapisan dasar, serta keamanan). Ini berarti bahwa transaksi valid yang dikirimkan ke pemesan harus disertakan dalam rantai dalam waktu terbatas (parameter timeout). Grup pemesan bersama hanya perlu memastikan bahwa transaksi disertakan dalam blok (yaitu crLists).
Memuaskan resistensi sensor dan kesegeraan pada saat yang sama cukup sulit, seperti yang kami uraikan di Modular MEV Part II. Dalam algoritme konsensus seperti Tendermint, Anda dapat memastikan pemulihan setelah serangan. Namun, jika terjadi serangan, Anda kehilangan kesegeraan. Pada dasarnya, meminta semua collator lain untuk menandatangani blok, daripada memilih masternode khusus, mungkin tidak optimal. Meskipun hal ini meningkatkan ketahanan sensor, hal ini menimbulkan biaya "sentralisasi" dan ekstraksi MEV ke satu masternode. Mekanisme penyortiran lain yang tersedia dapat dibandingkan dengan Duality's Multiplicity, yang merupakan alat kecil mereka untuk non-masternode (atau penyortir) untuk memasukkan transaksi lain ke dalam blok. Secara keseluruhan, resistensi sensor dan kesegeraan setelah serangan sulit dicapai di sebagian besar protokol konsensus.
Algoritme konsensus lain yang dapat digunakan adalah HotStuff 2, yang memastikan kesegeraan jika terjadi serangan.
Apa yang memungkinkan adalah untuk menghindari menunggu penundaan jaringan maksimum (batas waktu) jika terjadi penyensoran atau unsigned untuk memilih masternode baru. Alasan mengapa ini bisa menjadi algoritme konsensus yang menarik untuk sekumpulan pemesan yang terdesentralisasi adalah karena algoritme ini memecahkan masalah kesegeraan dalam konsensus tanpa menambahkan tahap tambahan. Jika masternode mengetahui kunci tertinggi (jumlah peserta tertinggi yang menyetujui output tertentu), dan dapat meyakinkan pihak yang jujur, masalah terpecahkan. Jika tidak, masternode yang jujur setelah titik tertentu dapat mengambil alih push, membantu masternode berikutnya. Misalnya, node Hotstuff tidak perlu mengakui pesan peralihan sebelum memberi tahu master baru, tetapi dapat langsung beralih ke tampilan baru dan memberi tahu master baru.
Perbedaannya dengan Tendermint adalah, meskipun keduanya dua fase (Hotstuff1 memiliki tiga, Hotstuff2 memiliki dua), Tendermint memiliki komunikasi linier tetapi tidak responsif, sedangkan Hotstuff2 bersifat reaktif. Jika ada rantai masternode yang jujur, protokol merespons secara positif, karena semua langkah kecuali proposal masternode pertama bergantung pada perolehan jumlah informasi dari langkah sebelumnya. Dalam pengaturan pemesan bersama, ini memungkinkan protokol mencapai kesegeraan yang lebih baik tanpa jatuh kembali ke lapisan bawah, sementara tidak membatalkan kemungkinan ini.
Konstruksi kelompok penyortir bersama
Satu set pemesan diizinkan untuk mengirimkan transaksi ke lapisan penyelesaian (lapisan tempat Rollup berada). Anda dapat bergabung dengan grup penyusun ini, asalkan persyaratan tertentu terpenuhi dan jumlah pembuat blok yang diperlukan belum tercapai. Ini mengoptimalkan latensi, throughput, dan lainnya. Persyaratan ini serupa dengan persyaratan untuk menjadi validator blockchain. Misalnya, Anda harus memenuhi persyaratan perangkat keras tertentu, serta setoran awal, terutama jika Anda ingin menawarkan kepastian kondisi keuangan.
Grup pemesan bersama (atau grup pemesan terdesentralisasi) terdiri dari beberapa komponen yang bekerja sama untuk memastikan pemrosesan transaksi yang benar, termasuk:
Sediakan JSON-RPC untuk setiap Rollup untuk pengiriman transaksi (untuk operator node non-penuh) ke node sebagai kumpulan memori, lalu buat dan urutkan. Dalam mempool, diperlukan beberapa mekanisme untuk menentukan antrian, serta proses pemilihan transaksi, untuk memastikan konstruksi blok yang efisien.
Algoritma konstruksi blok/batch, bertanggung jawab untuk memproses transaksi dalam antrian dan mengubahnya menjadi blok atau batch. Langkah ini juga dapat mencakup kompresi untuk mengurangi ukuran blok yang dihasilkan (disebut kompresi data). Seperti disebutkan, ini harus terpisah dari Pengusul, pada dasarnya PBS. Data dapat dikompresi dengan berbagai cara, misalnya:
Tidak ada pengkodean RLP - namun, ini mungkin memerlukan kumpulan collator yang terdesentralisasi untuk membantu menormalkan transfer data antar node, sehingga menghemat ruang.
Abaikan nonce (nomor unik yang memvalidasi data dalam blok tertentu) - dapat dihitung ulang pada waktu eksekusi dengan melihat status rantai sebelumnya.
Penyederhanaan harga gas - mengatur gas berdasarkan kisaran harga tetap.
Penyederhanaan gas - Selain harga gas, ada juga sistem penomoran gas.
Ganti alamat dengan indeks - Rollup dapat menyimpan indeks alamat yang dipetakan alih-alih menyimpan alamat lengkap.
Nilai dinyatakan dalam notasi ilmiah - bidang nilai dalam transaksi Ethereum didenominasi dalam wei, sehingga nilainya besar. Anda tidak dapat menghilangkan bidang numerik atau menguranginya menjadi sekumpulan nilai tetap. Namun, Anda dapat menuliskannya dalam notasi ilmiah untuk mengoptimalkan penyimpanan data:
Penghapusan bidang data: Bidang data tidak diperlukan untuk transfer sederhana, tetapi diperlukan untuk transaksi yang lebih kompleks.
Ganti tanda tangan individu dengan tanda tangan agregat BLS: Tanda tangan adalah komponen terbesar dari transaksi Ethereum. Alih-alih menyimpan setiap tanda tangan, Anda dapat menyimpan tanda tangan agregat BLS untuk sejumlah transaksi tertentu. Anda juga dapat memeriksa tanda tangan agregat BLS terhadap kumpulan pesan dan kumpulan pengirim untuk memastikan validitasnya.
Gunakan bidang Dari sebagai indeks: Seperti bidang Ke, Anda dapat menggunakan bidang Dari sebagai indeks untuk pemetaan.
Konsep desain "modular" yang menarik adalah Anda dapat melakukan penyesuaian dan pertukaran sesuai kebutuhan agar berfungsi untuk Rollup Anda.
Lapisan peer-to-peer akan memungkinkan pemesan menerima transaksi dari pemesan lain dan menyebarkan blok setelah konstruksi. Langkah ini sangat penting untuk memastikan bahwa sequencer bersama beroperasi secara efisien di beberapa rollup.
Algoritme rotasi master untuk set pemesan bersama (tidak diperlukan konsensus dalam kasus pemilihan master tunggal). Anda dapat memilih untuk hanya menyetel algoritme rotasi node master, atau mengambil rute produsen blok multi-konkuren yang diusulkan oleh Duality.
Algoritme konsensus, seperti Tendermint atau Hotstuff2 yang disebutkan di atas, dapat memastikan bahwa node Rollup setuju dengan urutan yang diusulkan oleh ledger.
Klien RPC untuk mengirimkan blok/batch ke lapisan konsensus DA+ yang mendasari sehingga blok/batch dapat ditambahkan dengan aman ke lapisan DA, memastikan finalitas "final" dan membuat semua data transaksi tersedia secara on-chain.
Pisahkan peran pembangun dan produsen blok untuk memastikan keadilan dan konsistensi, dan hindari pencurian MEV. Juga menghapus pengurutan yang dilakukan, yang penting untuk mengoptimalkan efisiensi, mengurangi PGA, dan meningkatkan CR.
*Rollup node menerima blok yang dipesan dari penyortir untuk pengiriman lunak, dan menerima blok lapisan DA yang dipesan untuk pengiriman keras. *
Calldata pertama kali dipublikasikan ke jaringan dasar, di mana konsensus dijalankan untuk menjamin transaksi pengguna dan Rollup. Kemudian, node Rollup mengeksekusi transaksi dan mengirimkan fungsi transisi status ke rantai Rollup kanonis. Jaringan pemesan bersama memberi Rollup kesegeraan dan ketahanan sensor. Rollup mempertahankan kedaulatannya karena semua data transaksi disimpan di lapisan dasar, yang memungkinkannya untuk melakukan fork dari pemesan bersama kapan saja. Akar status fungsi transisi status Rollup (STF) dihitung dari akar transaksi (input) yang dikirim dari pengurut bersama ke lapisan DA. Di Celestia, akar status dihasilkan saat data ditambahkan ke rantai dan konsensus tercapai. Karena Anda sudah memiliki root transaksi (dan semua data tersedia), Celestia dapat menyediakan klien ringan (Rollup node yang berjalan di Celestia) dengan sedikit bukti penyertaan.
Untuk memberikan pengalaman pengguna yang diharapkan pengguna, simpul Rollup menerima blok yang dipesan (yang juga dikirim ke lapisan DA). Hal ini dapat memberikan jaminan deterministik lunak kepada Rollup - jaminan bahwa blok pada akhirnya akan dipesan secara berurutan pada lapisan DA, di mana simpul Rollup mengeksekusi transaksi dan memberikan akar status baru.
Pembuatan Blok dan Slot
Untuk menentukan waktu pembuatan blok, sequencer perlu mengatur slot. Sequencer harus mengirimkan batch pada interval tetap (biasanya X detik), di mana X adalah waktu slot. Hal ini memastikan bahwa transaksi diproses dengan cepat dan efisien, karena jika tidak, masternode untuk slot tertentu akan kehabisan waktu dan kehilangan hadiah penandatanganan (dan hadiah eksekusi). Misalnya, waktu blok Celestia (menurut spesifikasi GitHub) adalah sekitar 15 detik. Karena ini diketahui, kita dapat membuat beberapa asumsi tentang berapa banyak "slot/blok" yang mungkin kita miliki dari kumpulan koorter bersama ke lapisan DA dan node Rollup dimuat ke dalam blok yang diselesaikan. Dalam hal ini, kami dapat merujuk ke Tendermint atau Hotstuff2 yang dioptimalkan.
Dalam slot yang sama, kami dapat mengirimkan beberapa batch transaksi, asalkan desainnya menyertakan mekanisme untuk Rollup node penuh untuk memprosesnya secara efisien menjadi satu blok (dalam periode waktu dan parameter batas waktu tersebut). Ini membantu lebih mengoptimalkan pembuatan blok dan memastikan transaksi diproses dengan cepat. Selain itu, slot juga dapat digunakan untuk memfasilitasi pemilihan node master penyortir. Misalnya, Anda dapat secara acak memilih node master slot dari staking pool berdasarkan bobot staking. Melakukan ini dengan cara yang menjaga kerahasiaan, dan menggunakan sesuatu seperti pemilihan pemimpin rahasia untuk meminimalkan penyensoran adalah pilihan terbaik; atau bahkan menyiapkan teknologi validator terdistribusi seperti solusi seperti Obol/SSV. Latensi dan waktu slot berdampak besar pada pengiriman blok dan pembangunan protokol. Jadi kita perlu melihat bagaimana ini mempengaruhi sistem. Bloxroute memiliki beberapa penelitian hebat dan poin data tentang Ethereum khususnya. Dalam MEV-Boost, produser blok yang berpartisipasi (validator atau sequencer dalam kasus Rollup) meminta GetHeader dari relai. Ini memberi mereka nilai tawaran blok, yang merupakan nilai dari blok tertentu. Ini mungkin blok nilai tertinggi yang diterima setiap kali. Untuk setiap slot, validator biasanya meminta GetHeader sekitar 400 md setelah slot dimulai - karena banyaknya validator, relai sering kali harus mengirimkan banyak permintaan. Ini juga yang dapat terjadi dengan grup penyortir bersama yang besar. Ini berarti Anda memerlukan infrastruktur untuk memfasilitasi proses ini.
Relai juga membantu memfasilitasi pemisahan pembuat dan pembuat blok, sekaligus memverifikasi bahwa pembuat membuat blok yang benar. Mereka juga memeriksa apakah biaya dibayarkan dengan benar dan bertindak sebagai perlindungan DoS. Juga, mereka pada dasarnya adalah penjaga blok dan menangani pendaftaran validator. Ini sangat penting dalam arsitektur sequencer tak terbatas, karena Anda perlu melacak siapa yang berpartisipasi dan siapa yang tidak (misalnya, lapisan sinkronisasi yang dibahas sebelumnya).
Mengenai waktu pemblokiran (yaitu pemblokiran yang dikirimkan oleh pembuat), biasanya terjadi sekitar 200 milidetik. Sebagian besar mulai berjalan sebelum/setelah sekitar 200 md, meskipun seperti GetHeader ada variasi yang cukup besar. Jika pembangun mengirim blok ke beberapa relai, itu akan menyebabkan penundaan yang cukup lama. Bloxroute juga melihat apa yang terjadi ketika blok dikirim ke beberapa relai. Seperti yang Anda duga, penundaan propagasi blok ke lebih banyak relai akan lebih besar. Rata-rata, relai kedua membutuhkan 99 milidetik untuk menghabiskan blok, 122 milidetik ketiga, dan 342 milidetik keempat.
Apa yang mungkin telah kita pelajari selama beberapa bulan terakhir adalah bahwa RPC sangat penting untuk blockchain. Ini adalah beban yang sangat besar tanpa infrastruktur yang tepat, dan memiliki opsi RPC yang tepat juga penting. Dalam hal ini, RPC penting bagi investor ritel untuk mengirimkan transaksinya ke RPC (dan mempool publik). Bloxroute menjalankan tes kecil terhadap 20 transaksi yang dikirim ke berbagai RPC dan mengukur waktu yang diperlukan untuk setiap transaksi dimasukkan ke dalam satu blok.
Sumber: Lab Bloxroute
Menariknya, beberapa RPC tidak menyertakan transaksi hingga beberapa blok kemudian, bergantung pada pembangun mana yang menang di blok berikutnya. Jika RPC mengirimkan transaksi ke lebih banyak pembangun, kemungkinan penyertaan cepat lebih tinggi. Meskipun dimungkinkan bagi pencetus transaksi untuk memanfaatkan posisi unik mereka agar mengalir untuk menargetkan pembangun tertentu atau bahkan membangun blok mereka sendiri.
Performa mereka juga menarik dalam statistik performa relai Ethereum. Ini membantu kami mendapatkan pemahaman yang lebih dalam tentang cara kerja PBS di dunia multi-validator/builder/relay, yang ingin kami capai dengan pemutakhiran Rollup. Metrika memiliki beberapa statistik hebat tentang ini dan semua poin data adalah karena mereka.
Penting untuk dicatat bahwa tawaran yang terlewatkan terjadi saat penyalur diharapkan untuk menawar, tetapi tidak menawar. Ekspektasi target berasal dari validator yang terdaftar dengan relai tertentu untuk setiap slot yang diberikan. Ini bukan kesalahan relay semata, juga tidak ditangani seperti itu di tingkat protokol.
Sumber: app.metrika.co
Jika terjadi kesalahan (seperti relai yang melayani blok yang tidak valid), dan itu bertanggung jawab, itu akan dihitung sebagai kesalahan. Ini biasanya jarang terjadi dan sebagian besar merupakan kegagalan preferensi pendaftaran (yaitu batas bahan bakar atau biaya yang tidak sesuai dengan pendaftaran untuk validator tertentu). Yang lebih jarang lagi adalah kegagalan lapisan konsensus, yang tidak konsisten dengan aturan lapisan konsensus Ethereum, seperti slot yang salah atau hash induk yang tidak selaras dengan blok sebelumnya, dll.
Dalam hal latensi (seperti waktu yang diperlukan validator untuk menerima header blok yang dibuat oleh pembuat), datanya sangat konsisten. Meskipun ada beberapa outlier, seperti relai yang diminta berada di lokasi geografis yang berbeda dengan validator yang dipilih.
Sumber: app.metrika.co
Mengenai pembangun, jumlah pembangun di MEV-boost adalah sekitar 84, dengan tiga pembangun teratas membangun sekitar 65% dari blok yang dibangun. Meskipun ini mungkin agak menyesatkan karena ini juga merupakan pembangun yang berjalan paling lama. Hasilnya serupa jika kerangka waktu dikurangi. Jumlah pembangun aktif sebenarnya jauh lebih rendah, 35 dalam 30 hari terakhir dan 24 dalam seminggu terakhir. Persaingan sengit, dan biasanya pembangun terkuat menang. Aliran pesanan eksklusif mungkin sudah ada, yang hanya akan memperburuk situasi. Kami berharap distribusi pembangun tetap relatif terpusat (karena ini adalah perlombaan untuk aliran pesanan yang optimal dan pengoptimalan perangkat keras) kecuali jika kami melakukan perubahan besar pada penyiapan. Meskipun bukan masalah mendasar, ini masih merupakan kekuatan sentralisasi di tumpukan dan kami akan senang mendengar ide tentang cara menantang status quo di sini. Jika Anda tertarik untuk menggali lebih dalam masalah (serius) ini, kami sangat menyarankan untuk membaca artikel Quintus tentang aliran pesanan, lelang, dan sentralisasi.
Untuk peran Builder di tumpukan modularitas mendatang, kami cukup yakin (setidaknya dalam penyiapan Cosmos SDK) kita akan melihat penyiapan Modul Pembangun seperti Lewati/Mekatek. Solusi lain adalah pengaturan jenis SUAVE, seperti rantai pembangun global spesifik yang menyediakan layanan pembuatan blok dan preferensi tawaran ke sejumlah rantai untuk memastikan PBS. Kami akan mengeksplorasi solusi ini secara lebih mendalam nanti, dan memberikan beberapa jawaban atas pertanyaan yang tidak dibahas di sini.
Mengenai relai, kami sangat menyarankan untuk membaca artikel oleh Ankit Chiplunkar dari Frontier Research dan Mike Neuder dari Ethereum Foundation yang disebut Relai Optimis dan di mana menemukannya. Posting ini merinci bagaimana relai dalam MEV-boost bekerja, pengorbanannya saat ini dan biaya pengoperasian, dan beberapa perubahan yang dapat meningkatkan efisiensi. Menariknya, menjalankan relai di MEV-Boost saat ini menelan biaya sekitar $100.000/tahun menurut perkiraan Flashbot.
Deterministik
Sebelum kita berbicara tentang determinisme blockchain modular (seperti yang terlihat saat ini), mari kita lihat artikel “Modular MEV” kami sebelumnya. Perhatikan bahwa ini bukan tampilan finalitas "resmi" atau komprehensif, tetapi kami yakin ini paling akurat mewakili nuansa finalitas Rollup untuk kemudahan pemahaman.
Pending_On_L2: Rollup orderer menunjukkan komitmen lunak bahwa transaksi pengguna pada akhirnya akan dilakukan dan diselesaikan pada lapisan dasar keamanannya.
Finality_On_L2: Sequencer telah berkomitmen pada fungsi transisi status Rollup, dan blok telah ditambahkan ke rantai kanonis Rollup.
Pending_On_L1: Fungsi transisi input atau output/status dari transaksi telah dipublikasikan ke L1, tetapi bukti validitasnya belum dikeluarkan, atau periode arbitrase belum berakhir - ini membutuhkan Ethereum untuk dua periode berturut-turut. Ini adalah titik di mana sebagian besar Batal Optimis mengatakan mereka telah mencapai finalitas, tetapi masih ada periode tantangan 7 hari yang sewenang-wenang pada titik ini sesuai dengan jembatan lintas rantai spesifikasi.
Finality_On_L1: Untuk Batal Optimis, periode arbitrase telah berakhir, atau bukti validitas yang dipublikasikan dan diverifikasi telah dikonfirmasi oleh supermayoritas dalam dua zaman berturut-turut.
Sekarang, dalam Sovereign Shared Sort Rollup, ini terlihat sedikit berbeda, mari kita coba jelaskan dengan diagram:
Dalam hal ini, secara teoritis kita bisa mendapatkan determinisme pada L1 sebelum L2, dst.? Ya, dalam hal ini L2 berdaulat. Ini dengan asumsi tidak ada bukti penipuan dan periode tantangan, atau Anda menggunakan bukti validitas.
Jadi bagaimana kita mencapai tingkat finalitas ini? Finalitas blok tercapai ketika sebuah blok ditambahkan ke rantai kanonis, yang tidak dapat ditarik. Namun, ada beberapa nuansa di sini, bergantung pada node penuh atau ringan. Dalam kasus blok terurut, ini bersifat deterministik setelah disertakan dalam blok lapisan DA. Blok (dengan akar status) diberlakukan oleh node/validator penuh Rollup, yang memberi mereka jaminan status akar valid yang berasal dari blok terurut dari lapisan dasar. Untuk determinisme di luar simpul penuh (seperti untuk klien ringan atau jembatan rantai silang), Anda harus yakin akan validitas root status ini. Di sini, Anda dapat menggunakan salah satu metode yang dijelaskan di bawah ini. Juga, pendekatan lain adalah membuat validator bertanggung jawab atas bukti yang benar dari akar negara (rute Optimis), melalui ikatan dan bukti penipuan berikutnya. Selain itu, Anda dapat memberikan bukti validitas (ZK).
Berbagai cara untuk mencapai finalitas blok:
Melalui Proof of Work (PoW), LMD+Ghost, Goldfish, Ouroboros (PoS) dan metode probabilistik lainnya.
Metode yang dapat dibuktikan dengan cara anggota komite yang cukup menandatangani blok. (misalnya Tendermint 2/3, Hotshot2 atau jenis PBFT lainnya)
Tergantung pada urutan transaksi/blok pada layer DA, dan aturannya, yaitu aturan canonical chain dan fork selection.
Kita dapat mencapai jenis finalitas yang berbeda melalui mekanisme yang berbeda.
Salah satu jenis finalitas adalah "finalitas lunak" (seperti pending), yang dapat dicapai dengan pemilihan pemimpin tunggal. Dalam hal ini, setiap slot hanya akan memiliki satu atau nol blok (komit atau tidak), dan lapisan sinkronisasi dapat dengan aman mengambil urutan transaksi di blok ini.
Jenis finalitas lainnya adalah "finalitas yang dapat dibuktikan", yang memberikan jaminan yang lebih kuat (pada dasarnya final) daripada finalitas lunak. Untuk mencapai finalitas yang dapat dibuktikan, mayoritas pemesan harus menandatangani blok, dengan demikian menyatakan persetujuan mereka bahwa blok tersebut kanonik. Meskipun pendekatan ini bagus, mungkin tidak diperlukan jika pemilihan pemimpin tunggal telah diterapkan, karena pada dasarnya menjamin pemesanan blok. Jelas, ini tergantung pada algoritma pemilihan pemimpin tertentu yang diterapkan. Misalnya, apakah implementasi 51%, implementasi 66%, atau pemimpin tunggal (sebaiknya acak (VRF) dan pemilihan rahasia). Jika Anda ingin mempelajari lebih lanjut tentang determinisme di Ethereum, baca artikel ini yang sangat kami rekomendasikan, dan artikel yang akan kami rekomendasikan nanti untuk kumpulan penyortir tak terbatas.
berlisensi, semi-lisensi atau tidak diizinkan
Untuk mencegah potensi serangan DoS, hambatan ekonomi harus ditetapkan untuk bergabung dengan grup pemesan dan mengirimkan transaksi ke lapisan pemesan. Dalam grup terbatas (jumlah penyortir terbatas) dan tidak terbatas (jumlah penyortir tidak terbatas), penghalang ekonomi harus diterapkan untuk mengirimkan batch ke lapisan DA untuk mencegah lapisan sinkronisasi (menyebarkan blok di antara penyortir) Memperlambat atau di bawah serangan DDoS . Namun, lapisan DA itu sendiri juga menyediakan beberapa perlindungan, karena mengirimkan data ke lapisan tersebut memerlukan biaya (da_fee). Uang jaminan yang diperlukan untuk bergabung dengan grup tak terbatas harus mencakup biaya tambahan yang diperlukan untuk mencegah lapisan sinkronisasi dari spam. Di sisi lain, margin yang diperlukan untuk bergabung dengan kelompok terbatas akan bergantung pada permintaan (seimbang dari perspektif biaya/pendapatan).
Untuk kumpulan penyortir tak terbatas, kami tidak dapat mencapai finalitas yang dapat dibuktikan pada lapisan penyortir (karena kami tidak pernah tahu persis berapa banyak pemilih/penandatangan aktif yang ada). Di sisi lain, dalam kelompok koorter yang dibatasi, finalitas yang dapat dibuktikan dapat dicapai oleh mayoritas blok penandatanganan koorter. Ini memang membutuhkan lapisan sinkronisasi untuk mengetahui lapisan sequencer dan berapa banyak sequencer yang aktif pada waktu tertentu, yang merupakan tambahan tambahan. Dalam rangkaian penyortir terbatas (mis. hingga 100), Anda juga dapat mengoptimalkan jumlah penyortir untuk meningkatkan "kinerja", meskipun dengan mengorbankan desentralisasi dan resistensi sensor. Pentingnya kelompok terbatas dan jaminan ekonomi untuk memberikan kepastian yang dapat dibuktikan secara "cepat" juga bersifat deterministik.
Jenis penyortir tak terikat dan penyortir terikat juga tercermin dalam blockchain tradisional.Misalnya, PoS (Casper+LMD-GHOST) di Ethereum mengadopsi tipe tak terbatas, sedangkan rantai berdasarkan Cosmos SDK/Tendermint mengadopsi tipe terikat. Pemikiran yang menarik adalah, apakah kita berharap untuk melihat ekonomi dan opsi seperti bukti saham dari komunitas di sekitar pemesan bersama? Dalam hal ini, kami telah melihat pergerakan menuju sentralisasi beberapa entitas (jadi tidak terikat tidak masalah jika Anda sudah memiliki beberapa penyedia/kumpulan bukti saham yang besar). Meskipun mereka "menyembunyikan" sentralisasi, Anda tetap dapat menambang jika Anda mau. Dari sudut pandang ideologis, pilihan harus hampir selalu tidak terbatas - tetapi ingat bahwa prinsip ekonomi membuat mereka sangat mirip. Terlepas dari siapa pesertanya, ekonomi dari apa yang Anda bayar harus tetap sama, seperti biaya DA dan biaya perangkat keras (walaupun ini dapat dikurangi dengan jumlah bukti saham yang Anda alokasikan dan alami, dan efisien pengoperasian infrastruktur). Bahkan di dunia PoS yang terbatas, kami telah melihat sekelompok penyedia infrastruktur menjadi validator terbesar dan paling umum di hampir semua rantai. Di sebagian besar rantai Cosmos, ketergantungan antar validator sudah sangat besar, dan hal ini tentunya menimbulkan bahaya bagi desentralisasi dan resistensi sensor dari rantai tersebut. Namun, fakta yang sangat berbeda adalah bahwa investor ritel mana pun dapat mempertaruhkan jumlah berapa pun dengan validator apa pun yang mereka pilih. Sayangnya, ini biasanya ditempatkan di bagian atas daftar, dan hidup terus berjalan. Kami bertanya lagi: apakah kami mengharapkan model ekonomi serupa di dunia modular? Satu harapan bukan itu masalahnya, tetapi dengan spesialisasi Anda sering membutuhkan yang paling cocok - dan mereka cenderung menjadi penyedia bukti saham profesional. Kami juga akan membahas masalah ekonomi ini di bab terpisah nanti.
Namun, satu hal penting yang perlu diingat dalam semua masalah ini adalah bahwa hal terpenting adalah otentikasi pengguna akhir, yang tersedia untuk siapa saja, di mana pun mereka berada (bahkan di Giza) melalui klien ringan dan piramida DAS).
Sumber: @JosephALChami
Berikut adalah trade-off dan keuntungan dari penyortir yang dibatasi dan tidak dibatasi:
Kumpulan penyortir tak terbatas:
*Siapa pun dengan obligasi/staking yang cukup dapat menjadi penyortir = tingkat desentralisasi yang tinggi
Tidak mungkin memiliki pemilihan pemimpin tunggal, karena penyortir pada dasarnya tidak terbatas.
*Pemilihan pemimpin non-tunggal melalui VRF dimungkinkan, tetapi sulit untuk menentukan parameter VRF karena tidak diketahui berapa banyak pemesan yang akan ada. Ini juga harus menjadi pemilihan pemimpin rahasia jika memungkinkan untuk menghindari serangan DoS.
Tidak ada pemilihan pemimpin = pemborosan sumber daya Masalah: Membangun blok pada dasarnya adalah kompetisi bebas, siapa pun yang mengirimkan blok/batch valid pertama menang, dan semua orang kalah. · · · Tidak ada kepastian yang dapat dibuktikan pada tingkat pemesan, hanya probabilistik: misalnya LMD Ghost+Casper
Finalitas hanya tercapai setelah batch ditulis ke lapisan DA (hanya dibatasi oleh waktu blok yang mendasarinya, 15 detik dalam kasus Celestia).
Perangkat tanpa batas lebih tahan sensor daripada perangkat terbatas.
Set penyortir terbatas:
Ini adalah salah satu solusi Ethereum untuk determinisme slot tunggal, dan memiliki komite "mayoritas" super.
Ada batasan jumlah sequencer yang diperbolehkan pada waktu tertentu.
Himpunan terikat lebih kompleks daripada himpunan tak terbatas.
Pemilihan pemimpin tunggal dapat diterapkan, memberikan jaminan deterministik yang kuat untuk lapisan penyortir.
Lapisan sinkronisasi perlu memahami kumpulan pemesan untuk menentukan blok mana yang valid.
Menulis set penyortir (atau mengatur perubahan) ke blok lapisan penyelesaian (seperti aturan pemilihan garpu), yang ditulis ke lapisan DA, memungkinkan lapisan sinkronisasi untuk secara mandiri menentukan set penyortir. Misalnya, inilah yang dilakukan Rollup Sovereign Labs, perubahan koleksi ditulis menjadi bukti validitas yang dipublikasikan ke lapisan DA.
Jaminan finalitas yang kuat dari lapisan pemesan mungkin tidak diperlukan jika lapisan DA cukup cepat (namun, sebagian besar pengaturan lapisan penyelesaian yang tidak dioptimalkan saat ini memiliki setidaknya 10+ waktu blok kedua).
Ada ruang desain yang cukup besar untuk bagaimana set penyortir ini dipantau dan anggota baru ditambahkan atau dihapus. Misalnya, apakah ini akan dicapai melalui Tata Kelola Tokenholder (bagaimana dengan banyak Token dan Rollup yang berbeda menggunakan koleksi?). Ini berarti bahwa perubahan pensinyalan off-chain dimungkinkan melalui konsensus sosial (misalnya, ambil Ethereum sebagai contoh). Namun, ingatlah bahwa konsensus on-chain yang sebenarnya sudah ditetapkan dengan jelas, dan hukuman untuk pelanggaran aturan konsensus sudah ada.
Mekanisme Ekonomi untuk Penyortir Bersama
Ekonomi berbagi jaringan sequencer memungkinkan beberapa opsi menarik. Seperti yang telah kita bahas sebelumnya, validator dalam jaringan pemesan bersama tidak jauh berbeda dengan validator L1 pada umumnya. Jaringan yang diikutinya lebih dioptimalkan untuk melakukan satu tugas, yaitu menerima maksud (sebelumnya PBS), dan karenanya mengusulkan dan memesan transaksi. Sama seperti validator "biasa", ada komponen pendapatan dan biaya. Di kedua sisi persamaan, ada banyak fleksibilitas dalam jaringan yang diikuti oleh validator, mirip dengan L1 biasa.
Pendapatan berasal dari pengguna atau Rollup yang pada akhirnya ingin berinteraksi dengan membayar biaya tertentu untuk menggunakan sequencer bersama. Biaya ini dapat berupa persentase dari penarikan MEV (memasukkan nomor mungkin sulit diperkirakan), transfer nilai lintas rantai, Gas, atau biaya tetap per interaksi. Solusi pendapatan yang paling tepat mungkin membayar pemesan bersama kurang dari nilai tambahan yang diperoleh melalui pemesan bersama Rollup, bersama dengan manfaat keamanan dan likuiditas bersama. Tetapi sisi negatifnya adalah sulit untuk mengukur manfaat desentralisasi dari bagian lain dari tumpukan. Namun, karena jaringan pemesan bersama tumbuh menjadi ekosistemnya sendiri, kemampuannya untuk menarik biaya dapat meningkat. Hal ini sebagian besar disebabkan oleh kemampuan bawaan mereka untuk berkumpul dengan mudah, dengan skala ekonomi tertentu. Semakin banyak Rollup dan aplikasi bergabung ke jaringan, semakin banyak MEV lintas domain yang dapat diekstrak.
Dari segi biaya, jaringan pemesanan bersama juga memiliki opsi bersaing. Mereka dapat dengan mudah mendanai penggunaan jaringan mereka dengan mendanai biaya penerbitan pada lapisan DA, atau bahkan biaya interaksi dengan aplikasi di Rollup. Ini mirip dengan strategi yang digunakan oleh perusahaan Web 2.0, di mana Anda mengambil kerugian awal pada akuisisi pengguna (atau rollup), berharap pendapatan jangka panjang mereka akan lebih besar daripada biayanya. Metode lain yang lebih baru atau Crypto-native adalah mengizinkan Rollup membayar biaya DA dengan Token aslinya. Di sini, lapisan penyortir bersama menanggung risiko harga antara Token yang diperlukan untuk menerbitkan data pada lapisan DA dan Token asli Rollup. Intinya, ini masih merupakan biaya awal penyortir bersama, tetapi menciptakan konsistensi ekosistem dengan mendapatkan Token dari "pemasok" (yaitu Rollup). Ini agak mirip dengan konstruksi gudang yang kami jelaskan di makalah AppChain, dan berbagai bentuk DA dapat digunakan untuk mengurangi biaya. Tingkat DA yang berbeda akan menawarkan harga yang berbeda karena penggunaan, kemampuan pengguna untuk memverifikasi dengan mudah melalui klien ringan, atau sekadar membuat pilihan ukuran blok yang berbeda. Terakhir, pemesan bersama juga dapat mengelompokkan transaksi sebelum memublikasikan ke lapisan DA. Dalam kasus ZKR, ini dapat mengurangi biaya transaksi melalui sejumlah saldo transaksi, dan dalam hal ORU, Anda dapat melakukan berbagai optimasi Gas pemrosesan batch, yang saat ini dapat kita lihat di berbagai Rollup. Ini akan mengurangi jumlah data yang perlu dipublikasikan ke lapisan DA, sehingga mengurangi biaya jaringan sequencer bersama dan meningkatkan profitabilitas seluruh jaringan. Ini akan datang dengan biaya membatasi interoperabilitas dan mengubah waktu finalitas blok (determinisme pada L1 seperti yang disebutkan sebelumnya).
Secara keseluruhan, ekonomi berbagi jaringan sequencer memungkinkan beberapa eksperimen menarik dan strategi bootstrap. Kami memperkirakan bahwa perbedaan utamanya adalah ukuran ekosistem, sehingga jumlah MEV lintas domain lebih besar daripada aspek biaya. Kami juga sangat merekomendasikan untuk melihat posting blog tim Espresso tentang pemesan bersama, mereka juga mencakup pengorbanan ekonomi (dan positif) dari jenis jaringan ini. Untuk menunjukkan mengapa Rollup termotivasi untuk memanfaatkan penyortir bersama (selain ekonomi), kita dapat mempertimbangkannya dari perspektif teori agregasi.
Teori Agregasi dan Penyortir Bersama
Cara lain untuk mendeskripsikan properti yang dibawa oleh penyortir bersama adalah melalui lensa teori agregasi. Teori agregasi mengacu pada konsep bagaimana platform atau agregator mengintegrasikan platform lain dan penggunanya secara sistematis untuk mendapatkan perhatian pengguna yang signifikan. Anda pada dasarnya memindahkan game dari alokasi sumber daya yang langka (mis., ruang blok) ke kebutuhan untuk mengontrol sumber daya yang melimpah (sekali lagi, ruang blok masuk akal dalam contoh ini). Teori Agregasi sebenarnya menggabungkan pemasok dan produk (yaitu Rollup dan Blockspace) menjadi pengalaman pengguna super untuk melayani basis pengguna agregat. Saat efek jaringan dari agregator ini tumbuh, hubungan ini menjadi semakin eksklusif. Saat ini terjadi, pengalaman pengguna menjadi pembeda utama antara penyiapan serupa. Jika ada insentif untuk menarik pengguna baru (seperti pengalaman pengguna yang baik dan interoperabilitas yang lebih baik), kecil kemungkinan Rollup akan pindah ke jaringannya sendiri atau penyiapan yang berbeda - karena efek jaringan mendorong pemasok baru dan pengguna baru bergabung. Ini menciptakan efek roda gila, tidak hanya dari perspektif penyedia dan pengguna, tetapi juga dari perspektif tahan sensor gabungan.
Sumber: Teori Agregasi 2015, Ben Thompson
Di ranah penyortir bersama, Teori Agregasi dapat dilihat sebagai "kombinasi" dan federasi dari berbagai Rollup, semuanya menggunakan vertikal tumpukan yang serupa - memberdayakan diri mereka sendiri dan orang lain sambil memungkinkan pengguna mendapatkan pengalaman yang sama.
Penyedia (seperti Rollups) secara teoritis tidak eksklusif untuk set coorter bersama, tetapi dalam praktiknya set coorter bersama, rollupnya, dan pengguna mendapat manfaat dari serangkaian loop efek jaringan yang mengarah pada peningkatan penggunaan rollup ini. Manfaat ini memudahkan Rollups dan pengguna untuk mengintegrasikan ke dalam tumpukan bersama karena mereka akan kehilangan lebih banyak jika mereka tidak berpartisipasi. Meskipun manfaat ini mungkin sulit dilihat saat Anda hanya memiliki dua Rollup yang berbagi satu set sequencer, manfaat tersebut menjadi lebih jelas saat Anda menambahkan lebih banyak Rollup dan Pengguna ke dalam persamaan. Kumpulan penyortir bersama memiliki hubungan langsung dengan pengguna, saat mereka memesan transaksi, bahkan jika pengguna itu sendiri tidak tahu bahwa mereka berinteraksi dengan mereka, karena dari sudut pandang mereka, mereka hanya menggunakan Rollup yang memiliki alasan untuk berinteraksi dengan mereka ( Ini berarti pemesanan/penyortir menjadi eksklusif). Satu-satunya biaya penyortir ini sebenarnya adalah biaya perangkat keras untuk menjalankannya, selama ruang blok dan token yang mengamankannya berharga bagi pengguna akhir. Biaya transaksi didigitalkan, dibayarkan dari dompet pengguna, dan mungkin di masa mendatang, bahkan dapat diabstraksi melalui kemajuan seperti host pembayaran dalam abstraksi akun (namun, seseorang harus menanggung biaya DA, pemesanan, dan eksekusi).
Ini lebih masuk akal ketika mempertimbangkan perusahaan Josh dan Jordan sebelumnya di Astria - Google. Sejak awal, produk Google telah terinspirasi oleh ide AT, terutama di Google Search, yang dibuat dengan memodulasi setiap halaman dan artikel, membuatnya dapat diakses langsung melalui jendela pencarian global.
Dalam kasus kumpulan penyortir bersama, pengguna yang menggunakan Rollups (mereka yang berbagi kumpulan penyortir) memiliki biaya akuisisi yang semakin rendah, karena seiring bertambahnya jumlah pemasok (Rollup), mereka cenderung tertarik ke kumpulan tersebut . Ini berarti bahwa, dalam banyak kasus, agregator (atau multi-agregator) memiliki kemungkinan efek win-win, karena nilai agregator meningkat seiring dengan jumlah pemasok (tentu saja selama pengalaman pengguna bagus). Sebaliknya, pada jaringan serial tunggal, akuisisi pelanggan terbatas pada jaringan tunggal dan aplikasinya. Jika pengguna ingin menggunakan aplikasi Rollup pada Rollup yang berbeda, mereka harus (dalam batasan saat ini) keluar dari jaringan seluruhnya. Ini berarti bahwa keterikatan dan nilai pengguna tidak terlalu tinggi, dan itu juga berarti bahwa setiap saat, jika ekosistem Rollup lain bernilai tinggi (atau memiliki lebih banyak insentif), modal dapat hilang.
Ringkasan Atribut dan Pengorbanan
Atribut
Kumpulan penyortir bersama adalah jaringan rollup yang menggabungkan dan mengurutkan transaksi untuk beberapa rollup. Rollup ini berbagi penyortir yang sama. Penggabungan sumber daya ini berarti bahwa Rollups mendapatkan keamanan ekonomi yang lebih kuat dan kemampuan anti-sensor, yang dapat memberikan jaminan deterministik lunak yang cepat dan transaksi lintas-Rollup bersyarat.
Saat ini, ada banyak kebisingan tentang atomisitas di antara Rollup yang berbagi kumpulan penyortir yang sama, sebagian besar seputar apakah itu atom secara default - padahal bukan. Namun, jika Rollup yang dipermasalahkan menerapkan fungsi transisi status (STF) satu sama lain sebagai ketergantungan di antara mereka, yang melibatkan transaksi bersyarat, maka mereka memang dapat mencapai atomisitas di antara mereka - selama Keselarasan slot/blocktime mereka (seperti dengan set penyortir bersama). Dalam hal ini, untuk mendapatkan interoperabilitas atom, Anda benar-benar hanya perlu menjalankan klien ringan rantai B pada rantai A dan sebaliknya (mirip dengan cara kerja IBC). Untuk lebih memperkuat interoperabilitas langkah-langkah keamanan (di luar mempercayai satu simpul penuh sebagai simpul ringan), Anda dapat menerapkan ZKP (Bukti Negara) untuk memecahkan "masalah oracle" untuk memastikan kebenaran keadaan. Ini akan memperjelas untuk melihat apakah transaksi bersyarat atau sesuatu seperti itu telah mencapai jembatan lintas rantai kanonis di antara mereka. Bukti penipuan juga merupakan kemungkinan, tetapi jelas akan meninggalkan periode tantangan (artinya pihak ketiga akan datang untuk menanggung biaya risiko ini). Juga, dalam kasus klien ringan (bukan node penuh), setidaknya akan tertinggal satu blok karena menunggu tajuk tanda tangan + jendela bukti penipuan (jika ada).
Kami percaya bahwa masalah "jembatan lintas rantai" kemungkinan besar akan diselesaikan dengan klien yang ringan dan bukti tanpa pengetahuan. Tantangan dengan menggunakan klien yang ringan (bukan smart contract) dalam hal ini adalah hard fork (peningkatan, dll.) di sisi simpul Rollup perlu berkoordinasi satu sama lain agar jembatan mereka tetap berjalan (seperti halnya IBC perlu mengaktifkan modul negara yang sama). Jika Anda ingin menyelami lebih dalam topik khusus ini (dan cara menanganinya), kami sangat menyarankan untuk melihat presentasi ini.
Alasan pemesan bersama menskala dengan sangat baik adalah karena mereka tidak mengeksekusi dan menyimpan status apa pun (seperti yang dilakukan pemesan terpusat saat ini). Hal yang sama berlaku untuk node Rollup itu sendiri (kecuali jika mereka menginginkan atomisitas di antara mereka sendiri - misalnya klien ringan/bukti status). Node ini hanya menjalankan transaksi yang valid untuk Rollup mereka, dan transaksi lintas domain bersyarat apa pun yang valid untuk mereka. Jika node Rollup harus mengeksekusi dan menyimpan status untuk beberapa Rollup, hal ini akan menghambat skalabilitas dan mengurangi desentralisasi (dan dengan demikian resistensi sensor). Ini juga memperkuat konsep pemisahan produsen-pembangun blok (PBS). Meskipun kami masih perlu memisahkan pembuat dan pembuat blok sepenuhnya. Dalam pengaturan saat ini, pemesan pada dasarnya adalah pembuat dan pembuat blok (walaupun mereka tidak melakukan transaksi). Pengaturan yang ideal mungkin adalah di mana pemesan hanya ada untuk menandatangani blok secara membabi buta dari pengaturan pembangun yang sangat dioptimalkan dan memastikan bahwa blok diterapkan dengan benar (sambil memberikan tingkat kepastian ekonomi dan ketahanan sensor yang tinggi terhadap sertifikasi itu). Dengan cara ini, mereka dapat memberikan tingkat keamanan dan komitmen yang tinggi untuk menjamin soft finality ke node Rollup.
Untuk transaksi bersyarat cross-rollup, mereka juga ada untuk membantu mengaktifkan node rollup (pelaksana) untuk menyediakan akar status perantara, memungkinkan atomisitas antara rollup.
tukar tambah
Parameter batas waktu yang disebutkan di atas memiliki beberapa efek menarik pada MEV dan penyertaan transaksi, tergantung pada mekanisme masternode/konsensus set pemesan. Misalnya, jika parameter batas waktu dijelaskan relatif singkat dalam makalah rantai khusus aplikasi kami, produsen blok dari kumpulan pemesan yang terdesentralisasi harus menerbitkan data secepat mungkin. Di dunia seperti itu, Anda dapat melihat persaingan antara "validator" yang bersaing untuk menjadi master node dan menawar lapisan DA untuk ruang blok hingga tidak lagi menguntungkan.
Seperti yang Evan bahas dalam postingan lazy orderer aslinya di forum Celestia, menunggu transaksi dipublikasikan ke lapisan dasar (Celestia dalam kasus ini) sebelum mengeksekusinya sangat tidak efisien. Karena sekarang Anda dibatasi oleh waktu blok lapisan dasar - yang terlalu lama untuk menunggu pengalaman pengguna. Untuk pengalaman pengguna yang lebih baik, pemesan bersama menyediakan Rollups dengan komitmen deterministik yang lembut (seperti yang dijelaskan sebelumnya), yang memberi pengguna pengalaman pengguna yang biasa mereka dapatkan di Rollup terpusat yang ada (sambil mempertahankan desentralisasi dan ketahanan sensor yang tinggi). Komitmen lunak pada dasarnya hanyalah komitmen pada urutan akhir transaksi, tetapi didukung oleh jaminan ekonomi yang berat dan penyelesaian cepat setelah dikeluarkan. Ini juga dicakup oleh bukti penipuan (sebagaimana disebutkan dalam pendahuluan). Hard finality yang sebenarnya dicapai setelah semua data transaksi dipublikasikan ke lapisan dasar (artinya L1 benar-benar mencapai finality yang lebih cepat). Itu tergantung pada apakah Rollup menggunakan bukti penipuan atau bukti tanpa pengetahuan untuk verifikasi bukti kedaulatannya - yang terjadi pada Rollup. Alasan menginginkan pemisahan ini adalah untuk menghilangkan hambatan besar transisi keadaan dari penyortir. Sebaliknya, node Rollup hanya berurusan dengan node yang valid untuk mereka (artinya kita harus menambahkan transaksi bersyarat, bukti status, atau validasi node ringan untuk interoperabilitas yang tepat). Determinisme keras masih bergantung pada lapisan dasar (tetapi ini dapat mencapai 15 detik di Celestia, dan juga deterministik di bawah Tendermint), yang memberi kami jaminan determinisme keras yang relatif cepat pada Rollup.
Gunakan bukti tanpa pengetahuan di dalam jaringan untuk mengoptimalkan validasi, ukuran transaksi (mis. hanya publikasikan perbedaan status - tetapi ini menambah tingkat kepercayaan yang lebih tinggi hingga ZKP dipublikasikan). Seperti yang disebutkan sebelumnya, bukti status ini dapat digunakan untuk memungkinkan rantai/pembatalan yang terhubung memiliki interoperabilitas yang lebih mudah dan lebih cepat (tanpa menunggu jendela tantangan).
Kelemahan dari transaksi bersyarat ini adalah cenderung lebih mahal, memerlukan verifikasi dan biaya penerbitan yang lebih tinggi (seperti biaya verifikasi tajuk blok Tendermint, yang disubsidi pada rantai Cosmos), dan menambahkan beberapa latensi ke sistem ( tetapi masih lebih cepat daripada Isolated Rollups yang jauh lebih cepat). Atomisitas yang dicapai dengan integrasi bersama secara vertikal dapat mengkompensasi masalah ini.
Selama fase bootstrap rollup baru, menggunakan sekumpulan collator bersama sangat masuk akal, dan keuntungan yang Anda peroleh sebagai penyedia kemungkinan akan lebih besar daripada beberapa pengorbanan yang mungkin "dipaksa" Anda lakukan di tingkat parit. Namun, untuk Rollup yang sudah matang, di mana terdapat banyak transaksi dan aktivitas ekonomi, mungkin tidak masuk akal untuk melepaskan sebagian parit.
Ini menimbulkan pertanyaan apakah kita memerlukan redistribusi berbobot ekonomis/transaksional (per Rollup) serupa dari MEV yang diekstraksi untuk mendorong Rollup yang sudah matang untuk bergabung dengan set bersama - atau bahkan mencegah Rollup yang sangat matang menghasilkan jaringan sendiri. Ini semua cukup teoretis, tetapi tidak diragukan lagi ini merupakan proses pemikiran yang menarik sehubungan dengan bagaimana MEV di dunia vertikal bersama akan diwakili di antara banyak Rollup dengan berbagai tingkat aktivitas. Misalnya, jika Rollup unik yang mendorong nilai berbagi sebagian dari keuntungan ini dengan yang lain (mungkin tidak menghasilkan banyak "nilai") melalui Sequencer Set, maka pasti ada lebih banyak alasan bagi mereka untuk pindah ke sistem silo mereka sendiri. Sreeram oleh EigenLayr juga memiliki beberapa pemikiran tentang ini, yang kami sarankan untuk dibaca juga.
Hal ini menjadi semakin penting ketika mempertimbangkan bahwa ada biaya teknis yang cukup besar bagi para pencari untuk mengembangkan rantai baru, jadi standarisasi dan memberikan kedaulatan atas MEV "mereka" mungkin merupakan tempat yang baik untuk memulai. Dalam praktiknya, dalam MEV, antarmuka (atau perangkat lunak) yang dominan mungkin menang, tetapi sebenarnya memonetisasi perangkat lunak tersebut dengan menjalankan bagian penting infrastruktur sangatlah sulit (mengarah ke sentralisasi). Di tingkat pasar, apa yang disediakan oleh pemesan bersama pada dasarnya adalah kumpulan bersama untuk banyak penyedia, dengan lelang terpusat, yang dapat menghasilkan persaingan yang lebih sehat.
Kekhawatiran di sini adalah bahwa jika dua Rollup menjalankan penyortir di set bersama, maka Rollup dengan nilai "kurang ekonomis" (A) dapat dipilih untuk mengusulkan rollup dengan jumlah biaya MEV + yang tinggi dari Rollup (B). . Dari sudut pandang Rollup B, mereka pada dasarnya kehilangan beberapa nilai yang, dalam pendekatan terisolasi, akan mereka simpan sendiri.
Mengatasi kompromi interoperabilitas
Catatan lain tentang trade-off yang disajikan oleh interoperabilitas, dan cara lain untuk memecahkan beberapa masalah berikut:
Tujuan dari jaringan pemesan bersama adalah untuk memberikan jaminan kanonik untuk banyak rantai, yang jelas merupakan keuntungan besar dalam kasus ini. Ini dapat digabungkan dengan mekanisme untuk menjamin transisi status yang efisien di antara Rollups. Ini bisa berupa pendekatan berbasis komite (mis. PoS), bukti yang diamankan (pendekatan Optimis), atau pilihan kami - ZKP yang didukung oleh tanda tangan komite. Karena penyortir bersama adalah "malas", mereka hanya membuat blok super untuk mengurutkan transaksi dari beberapa Rollup, dan eksekusi transaksi tertentu diserahkan kepada Rollup tertentu. Proofs of state (yaitu Lagrange, Axiom atau Herodotus, dll.) adalah semua solusi yang memungkinkan untuk mendapatkan bukti finalitas di seluruh rollup kedaulatan. Anda bahkan dapat menambahkan bukti finalitas yang dijamin secara ekonomi melalui hal-hal seperti staking pools, EigenLayr, dll. Ide dasarnya adalah bahwa penyortir bersama memberikan jaminan ekonomi pemesanan, dan bukti validitas yang dihasilkan dari penyortiran ini bersifat deterministik. Ide dasarnya adalah bahwa Rollups dapat melakukan transaksi secara sinkron satu sama lain. Misalnya, jaringan dari dua node Rollup dapat secara kondisional mengetahui bahwa kedua riwayat Rollup valid, melalui ZKP dan data yang tersedia (data dipublikasikan ke lapisan DA yang efisien). Dengan memublikasikan awalan blok Rollup tunggal dari jaringan A dan B, node Rollup dapat menyelesaikan dua Rollup secara bersamaan. Satu hal yang perlu diperhatikan adalah bahwa transaksi cross-rollup bersyarat mengkonsumsi sumber daya dari dua sistem terpisah melalui eksekusi bersama, sehingga transaksi cross-rollup atomik (atau sinkron) cenderung lebih mahal daripada transaksi intra-rollup tunggal.
Ringkas juga mencakup transaksi "atomik" lintas rantai antara Rollups dengan pemesan bersama (dan pembukti penipuan bersama) dalam ekosistem hyperchain Optimisme, yang dapat dilihat di sini. Juga, seperti yang dikatakan Bo Du dari Polymer: "Transaksi atom lintas rantai seperti memperoleh kunci antara pecahan basis data saat menulis".
Masa Depan Integrasi Vertikal
Cara kerja rantai SUAVE yang mungkin telah dieksplorasi secara mendalam oleh Jon Charbonneau dkk, jadi kami tidak akan membahas terlalu banyak detail. Jika Anda ingin deskripsi yang lebih rinci, Anda dapat melihat artikelnya. Meskipun demikian, menurut kami integrasi vertikal layak mendapat pengenalan terpisah, baik untuk menyoroti seberapa modular kita (dan mengapa) dan untuk memperkenalkan beberapa masalah dan masalah yang terkait dengan integrasi vertikal.
Meskipun skema pemesan bersama Astria, Espresso, dan Radius saat ini sangat modular, pemesan masih bertindak sebagai pembuat dan pembuat blok (walaupun dalam kasus Astria, mereka tidak melakukan transaksi). Astria juga aktif membangun PBS ke dalam arsitekturnya sejak awal.
Jika PBS tidak dibangun ke dalam protokol, ada beberapa cara untuk mengimplementasikan PBS (walaupun dengan berbagai tingkat desentralisasi). Produk seperti SUAVE, gunakan model offline seperti MEV-Boost, atau implementasikan modul pembuat seperti modul Cosmos SDK yang dibuat oleh Mekatek dan Skip.
Perlu dicatat bahwa tidak satu pun dari metode ini yang saling eksklusif. Anda memiliki fleksibilitas untuk menggunakan beberapa metode berbeda dan membiarkan siapa pun mengekspresikan preferensi mereka. Dengan begitu, Anda bisa membuat para eksekutor bersaing untuk mengisi lowongan tersebut. Menambahkan lebih banyak opsi selalu bagus (dan konsisten dengan keyakinan kami pada modularitas). Namun, implementasi yang berbeda akan memiliki pengorbanan yang berbeda. Misalnya, dalam kasus seperti SUAVE, Anda dapat menambahkan perlindungan privasi melalui teknologi SGX atau Crypto, dan menambahkan keamanan ekonomi Crypto ke kebenaran, alih-alih mengandalkan pembuat PBS terpusat yang tepercaya sepenuhnya. (Terima kasih kepada Jon Charbonneau atas umpan baliknya di sini).
Integrasi vertikal ke dalam rantai pembuat memastikan keadilan tanpa mengambil jalan pintas, menambah latensi, dan menurunkan kinerja. Oleh karena itu, rantai pembuat harus sangat dioptimalkan dan mungkin memerlukan perangkat keras yang mahal dan kuat (mengarah ke sentralisasi). Ini berarti bahwa untuk mendapatkan validasi pengguna akhir, kami mungkin memerlukan semacam node ringan (walaupun mereka harus memercayai node penuh), atau menggunakan bukti penyiapan jenis status untuk memastikan rantai dan pengguna memiliki bukti bahwa preferensi tawaran diisi dan blok sudah benar Bangun.
Rantai seperti ini mungkin sangat membebani negara (kami ingin menghindari ini), meskipun transaksi berat negara ini akan diprioritaskan melalui kontrak pintar. Dalam kasus penawaran prioritas, penawaran tersebut diisi atau tidak diisi (untuk jangka waktu singkat), karena penawaran biasanya hanya berlaku untuk jangka waktu singkat, bergantung pada preferensi. Ini berarti kami mungkin dapat menerapkan kedaluwarsa status yang sangat efisien (dan lebih awal) untuk tawaran - yang akan memungkinkan kami memangkas data dan menjaga rantai "bersih". Tanggal kedaluwarsa ini harus cukup lama untuk tetap memungkinkan tawaran diisi terlebih dahulu, tetapi menurunkannya terlalu banyak akan membuat hampir tidak mungkin untuk mencapai masa depan blockspace futures. Kami tidak perlu memperbarui dan mengambil kontrak penawaran yang kedaluwarsa karena tidak perlu ada selamanya (tidak seperti aplikasi) - ini dapat dilakukan dengan memberikan bukti status/penyimpanan saat penawaran diisi atau dengan solusi penyimpanan DAS (seperti yang diusulkan oleh solusi Joachim Neu) untuk membuatnya lebih "aman" dan dapat dipercaya.
Seperti disebutkan sebelumnya, kebutuhan untuk memverifikasi "keaslian" SUAVE mungkin terbatas pada "jusha" (pengguna tingkat lanjut) platform, karena sebagian besar pengguna dan pelanggan SUAVE dapat memperoleh manfaat ekonomi yang tinggi darinya. Ini mungkin mendorong kita untuk hanya mengizinkan orang menjalankan node penuh jika mereka ingin memvalidasi - meskipun ini mengecualikan sebagian besar orang (bisa dibilang mereka tidak perlu memvalidasi). Ini (menurut kami) kebalikan dari Crypto, di mana kami lebih suka menerapkan verifikasi SUAVE "tanpa kepercayaan" melalui bukti negara atau implementasi ramah klien ringan.
Alasan mengapa hal ini diperlukan adalah Anda ingin memverifikasi bahwa prioritas penawaran Anda diisi dengan benar dan blok tersebut diisi dengan informasi yang benar saat membayar (untuk menghindari rebundling dan bug lainnya). Ini pada dasarnya adalah masalah oracle - sebenarnya ini dapat diselesaikan dengan bukti status (seperti halnya semua SUAVE). Namun, bukti negara ini memunculkan masalah lain saat melintasi rantai, bagaimana cara menyampaikan informasi ini melintasi rantai dengan cara yang tidak dirusak atau disembunyikan? Ini mungkin memerlukan finalitas ekonomi yang kuat (seperti yang diusulkan oleh Lagrangian), dalam hal ini Anda dapat menggunakan validator pengambilan ulang EigenLayr untuk membuktikan finalitas dan keaslian rantai, dan memiliki kendala ekonomi yang sangat kuat. Hal ini kemudian menimbulkan masalah lain (misalnya kontrak penawaran menetapkan bahwa "mesin oracle" - dalam hal ini penjamin kembali - telah menunjuk Token yang dijanjikan dan memberikan pengikatan ekonomi - tetapi bagaimana kita membuat konsensus antara Pemotongan eksternal ini? Sementara Anda dapat menulis kriteria pemotongan, ini tidak ada dalam konsensus, yang berarti pemotongan sosial akan dieksploitasi melalui kontrak pintar (yang hampir tidak pernah "adil" dan dapat menyebabkan masalah). Saat ini terjadi di EigenLayr Salah satu masalah terbesar terkait kehilangan .
Jadi, di mana ini meninggalkan kita? Mungkin, sampai kita mendapatkan on-chain "trustless" pemotongan di luar konsensus, rantai seperti SUAVE mungkin memerlukan algoritme konsensus dan keamanan Cryptoeconomic mereka sendiri untuk membuktikan preferensi tawaran dan membangun kepastian blok— Namun, ini berarti menambahkan lebih banyak vektor serangan cryptoeconomic, terutama jika Rollup nilai blok penyusunnya jauh lebih tinggi daripada keamanan kriptoekonominya sendiri.
Selain itu, masih banyak ruang desain dalam rantai tipe SUAVE dan MEV lintas domain. Berikut adalah beberapa kemungkinan arah penelitian:
Pencocokan niat dan sistem berbasis niat
Optimalisasi cembung dalam perdagangan multi-aset
DSL
Realokasi MEV
Perang yang tertunda
Masalah penskalaan dengan satu set aktor tetapi perlu dibuat untuk beberapa mesin status Rollup
Ekspresi preferensi
Mengenai ekspresi preferensi, untuk berinteraksi dengan kontrak pintar di EVM, panggilan kontrak (pesan) harus dikirim ke fungsi tertentu di alamat kode yang diterapkan yang berisi instruksi eksekusi. Sementara pengguna memberikan masukan, mereka mungkin tidak memiliki kendali atas keluaran karena kemungkinan status.
Sebaliknya, sistem desain ekspresi preferensi (seperti SUAVE dan Anoma) hanya mengharuskan pengguna untuk menandatangani preferensi dengan ikatan, yang dibayarkan kepada pembangun dan produsen blok jika preferensi pencari terpenuhi. Untuk logika kombinatorial yang kompleks, seperti urutan transaksi untuk pencari dan pembuat MEV, berbagai bahasa dan mesin virtual mungkin perlu diimplementasikan. Ini adalah ruang desain baru yang mendapat banyak perhatian akhir-akhir ini, terutama arsitektur Anoma. Juga, kami sangat merekomendasikan artikel singkat ini.
Lihat Asli
Konten ini hanya untuk referensi, bukan ajakan atau tawaran. Tidak ada nasihat investasi, pajak, atau hukum yang diberikan. Lihat Penafian untuk pengungkapan risiko lebih lanjut.
4D Detil Shared Sorter: Prinsip Kerja, Teori Agregasi dan Integrasi Vertikal
Judul asli: "The Shared Sequencer"
Ditulis oleh: MAVEN11
Kompilasi: Kxp, BlockBeats
Bayangkan bagaimana jadinya jika Rollup "out of the box" dapat mencapai ketahanan sensor tingkat tinggi, kemudahan penerapan, interoperabilitas, penyelesaian cepat, keaktifan, dan demokratisasi MEV. Itu mungkin tampak seperti tujuan besar, tetapi dengan munculnya Shared Sequencer, itu mungkin akan segera menjadi kenyataan. Namun, tidak semua Rollup sama, jadi kami harus mempertimbangkan cara mendistribusikan hadiah dan MEV di jaringan sequencer bersama. Dalam makalah ini, kami mengeksplorasi bagaimana jaringan ranker bersama diimplementasikan, dan properti yang dapat dicapai.
Shared Sequencer Networks pertama kali diperkenalkan oleh Alex Beckett, kemudian oleh Evan Forbes (dan Radius) dari tim Celestia dan Espresso, dan sebuah artikel baru oleh Jon Charbonneau yang membahas topik tersebut secara lebih mendalam. Josh, Jordan, dan tim Astria mereka sedang membangun jaringan sequencer bersama pertama yang siap produksi. Jaringan Pemesan Bersama Astria adalah blockchain modular yang menggabungkan dan memesan transaksi Rollup tanpa mengeksekusinya.
Dalam penyiapan Astria, penyortir mengirimkan blok yang dipesan ke lapisan DA dan juga ke node Rollup. Rollup mendapatkan jaminan soft finality dari pemesan dan jaminan hard finality dari lapisan DA (setelah blok diselesaikan), dan kemudian mereka akan melakukan transaksi yang valid.
Jaringan sequencer bersama pada dasarnya adalah grup sequencer yang kompatibel dengan Rollup, seperti namanya, dapat menyediakan layanan untuk Rollup yang berbeda. Ini memiliki berbagai pengorbanan dan properti, yang akan kami jelaskan nanti. Pertama, kita harus menjelaskan properti paling penting dari penyortir (atau kumpulan penyortir). Dalam Rollup, persyaratan utama untuk sequencer atau grup sequencer adalah ketahanan sensor atau liveness (beberapa di antaranya berasal dari lapisan dasar, serta keamanan). Ini berarti bahwa transaksi valid yang dikirimkan ke pemesan harus disertakan dalam rantai dalam waktu terbatas (parameter timeout). Grup pemesan bersama hanya perlu memastikan bahwa transaksi disertakan dalam blok (yaitu crLists).
Memuaskan resistensi sensor dan kesegeraan pada saat yang sama cukup sulit, seperti yang kami uraikan di Modular MEV Part II. Dalam algoritme konsensus seperti Tendermint, Anda dapat memastikan pemulihan setelah serangan. Namun, jika terjadi serangan, Anda kehilangan kesegeraan. Pada dasarnya, meminta semua collator lain untuk menandatangani blok, daripada memilih masternode khusus, mungkin tidak optimal. Meskipun hal ini meningkatkan ketahanan sensor, hal ini menimbulkan biaya "sentralisasi" dan ekstraksi MEV ke satu masternode. Mekanisme penyortiran lain yang tersedia dapat dibandingkan dengan Duality's Multiplicity, yang merupakan alat kecil mereka untuk non-masternode (atau penyortir) untuk memasukkan transaksi lain ke dalam blok. Secara keseluruhan, resistensi sensor dan kesegeraan setelah serangan sulit dicapai di sebagian besar protokol konsensus.
Algoritme konsensus lain yang dapat digunakan adalah HotStuff 2, yang memastikan kesegeraan jika terjadi serangan.
Apa yang memungkinkan adalah untuk menghindari menunggu penundaan jaringan maksimum (batas waktu) jika terjadi penyensoran atau unsigned untuk memilih masternode baru. Alasan mengapa ini bisa menjadi algoritme konsensus yang menarik untuk sekumpulan pemesan yang terdesentralisasi adalah karena algoritme ini memecahkan masalah kesegeraan dalam konsensus tanpa menambahkan tahap tambahan. Jika masternode mengetahui kunci tertinggi (jumlah peserta tertinggi yang menyetujui output tertentu), dan dapat meyakinkan pihak yang jujur, masalah terpecahkan. Jika tidak, masternode yang jujur setelah titik tertentu dapat mengambil alih push, membantu masternode berikutnya. Misalnya, node Hotstuff tidak perlu mengakui pesan peralihan sebelum memberi tahu master baru, tetapi dapat langsung beralih ke tampilan baru dan memberi tahu master baru.
Perbedaannya dengan Tendermint adalah, meskipun keduanya dua fase (Hotstuff1 memiliki tiga, Hotstuff2 memiliki dua), Tendermint memiliki komunikasi linier tetapi tidak responsif, sedangkan Hotstuff2 bersifat reaktif. Jika ada rantai masternode yang jujur, protokol merespons secara positif, karena semua langkah kecuali proposal masternode pertama bergantung pada perolehan jumlah informasi dari langkah sebelumnya. Dalam pengaturan pemesan bersama, ini memungkinkan protokol mencapai kesegeraan yang lebih baik tanpa jatuh kembali ke lapisan bawah, sementara tidak membatalkan kemungkinan ini.
Konstruksi kelompok penyortir bersama
Satu set pemesan diizinkan untuk mengirimkan transaksi ke lapisan penyelesaian (lapisan tempat Rollup berada). Anda dapat bergabung dengan grup penyusun ini, asalkan persyaratan tertentu terpenuhi dan jumlah pembuat blok yang diperlukan belum tercapai. Ini mengoptimalkan latensi, throughput, dan lainnya. Persyaratan ini serupa dengan persyaratan untuk menjadi validator blockchain. Misalnya, Anda harus memenuhi persyaratan perangkat keras tertentu, serta setoran awal, terutama jika Anda ingin menawarkan kepastian kondisi keuangan.
Grup pemesan bersama (atau grup pemesan terdesentralisasi) terdiri dari beberapa komponen yang bekerja sama untuk memastikan pemrosesan transaksi yang benar, termasuk:
Sediakan JSON-RPC untuk setiap Rollup untuk pengiriman transaksi (untuk operator node non-penuh) ke node sebagai kumpulan memori, lalu buat dan urutkan. Dalam mempool, diperlukan beberapa mekanisme untuk menentukan antrian, serta proses pemilihan transaksi, untuk memastikan konstruksi blok yang efisien.
Algoritma konstruksi blok/batch, bertanggung jawab untuk memproses transaksi dalam antrian dan mengubahnya menjadi blok atau batch. Langkah ini juga dapat mencakup kompresi untuk mengurangi ukuran blok yang dihasilkan (disebut kompresi data). Seperti disebutkan, ini harus terpisah dari Pengusul, pada dasarnya PBS. Data dapat dikompresi dengan berbagai cara, misalnya:
Penghapusan bidang data: Bidang data tidak diperlukan untuk transfer sederhana, tetapi diperlukan untuk transaksi yang lebih kompleks.
Ganti tanda tangan individu dengan tanda tangan agregat BLS: Tanda tangan adalah komponen terbesar dari transaksi Ethereum. Alih-alih menyimpan setiap tanda tangan, Anda dapat menyimpan tanda tangan agregat BLS untuk sejumlah transaksi tertentu. Anda juga dapat memeriksa tanda tangan agregat BLS terhadap kumpulan pesan dan kumpulan pengirim untuk memastikan validitasnya.
Gunakan bidang Dari sebagai indeks: Seperti bidang Ke, Anda dapat menggunakan bidang Dari sebagai indeks untuk pemetaan.
Konsep desain "modular" yang menarik adalah Anda dapat melakukan penyesuaian dan pertukaran sesuai kebutuhan agar berfungsi untuk Rollup Anda.
Algoritme rotasi master untuk set pemesan bersama (tidak diperlukan konsensus dalam kasus pemilihan master tunggal). Anda dapat memilih untuk hanya menyetel algoritme rotasi node master, atau mengambil rute produsen blok multi-konkuren yang diusulkan oleh Duality.
Algoritme konsensus, seperti Tendermint atau Hotstuff2 yang disebutkan di atas, dapat memastikan bahwa node Rollup setuju dengan urutan yang diusulkan oleh ledger.
Klien RPC untuk mengirimkan blok/batch ke lapisan konsensus DA+ yang mendasari sehingga blok/batch dapat ditambahkan dengan aman ke lapisan DA, memastikan finalitas "final" dan membuat semua data transaksi tersedia secara on-chain.
Pisahkan peran pembangun dan produsen blok untuk memastikan keadilan dan konsistensi, dan hindari pencurian MEV. Juga menghapus pengurutan yang dilakukan, yang penting untuk mengoptimalkan efisiensi, mengurangi PGA, dan meningkatkan CR.
*Rollup node menerima blok yang dipesan dari penyortir untuk pengiriman lunak, dan menerima blok lapisan DA yang dipesan untuk pengiriman keras. *
Calldata pertama kali dipublikasikan ke jaringan dasar, di mana konsensus dijalankan untuk menjamin transaksi pengguna dan Rollup. Kemudian, node Rollup mengeksekusi transaksi dan mengirimkan fungsi transisi status ke rantai Rollup kanonis. Jaringan pemesan bersama memberi Rollup kesegeraan dan ketahanan sensor. Rollup mempertahankan kedaulatannya karena semua data transaksi disimpan di lapisan dasar, yang memungkinkannya untuk melakukan fork dari pemesan bersama kapan saja. Akar status fungsi transisi status Rollup (STF) dihitung dari akar transaksi (input) yang dikirim dari pengurut bersama ke lapisan DA. Di Celestia, akar status dihasilkan saat data ditambahkan ke rantai dan konsensus tercapai. Karena Anda sudah memiliki root transaksi (dan semua data tersedia), Celestia dapat menyediakan klien ringan (Rollup node yang berjalan di Celestia) dengan sedikit bukti penyertaan.
Untuk memberikan pengalaman pengguna yang diharapkan pengguna, simpul Rollup menerima blok yang dipesan (yang juga dikirim ke lapisan DA). Hal ini dapat memberikan jaminan deterministik lunak kepada Rollup - jaminan bahwa blok pada akhirnya akan dipesan secara berurutan pada lapisan DA, di mana simpul Rollup mengeksekusi transaksi dan memberikan akar status baru.
Pembuatan Blok dan Slot
Untuk menentukan waktu pembuatan blok, sequencer perlu mengatur slot. Sequencer harus mengirimkan batch pada interval tetap (biasanya X detik), di mana X adalah waktu slot. Hal ini memastikan bahwa transaksi diproses dengan cepat dan efisien, karena jika tidak, masternode untuk slot tertentu akan kehabisan waktu dan kehilangan hadiah penandatanganan (dan hadiah eksekusi). Misalnya, waktu blok Celestia (menurut spesifikasi GitHub) adalah sekitar 15 detik. Karena ini diketahui, kita dapat membuat beberapa asumsi tentang berapa banyak "slot/blok" yang mungkin kita miliki dari kumpulan koorter bersama ke lapisan DA dan node Rollup dimuat ke dalam blok yang diselesaikan. Dalam hal ini, kami dapat merujuk ke Tendermint atau Hotstuff2 yang dioptimalkan.
Dalam slot yang sama, kami dapat mengirimkan beberapa batch transaksi, asalkan desainnya menyertakan mekanisme untuk Rollup node penuh untuk memprosesnya secara efisien menjadi satu blok (dalam periode waktu dan parameter batas waktu tersebut). Ini membantu lebih mengoptimalkan pembuatan blok dan memastikan transaksi diproses dengan cepat. Selain itu, slot juga dapat digunakan untuk memfasilitasi pemilihan node master penyortir. Misalnya, Anda dapat secara acak memilih node master slot dari staking pool berdasarkan bobot staking. Melakukan ini dengan cara yang menjaga kerahasiaan, dan menggunakan sesuatu seperti pemilihan pemimpin rahasia untuk meminimalkan penyensoran adalah pilihan terbaik; atau bahkan menyiapkan teknologi validator terdistribusi seperti solusi seperti Obol/SSV. Latensi dan waktu slot berdampak besar pada pengiriman blok dan pembangunan protokol. Jadi kita perlu melihat bagaimana ini mempengaruhi sistem. Bloxroute memiliki beberapa penelitian hebat dan poin data tentang Ethereum khususnya. Dalam MEV-Boost, produser blok yang berpartisipasi (validator atau sequencer dalam kasus Rollup) meminta GetHeader dari relai. Ini memberi mereka nilai tawaran blok, yang merupakan nilai dari blok tertentu. Ini mungkin blok nilai tertinggi yang diterima setiap kali. Untuk setiap slot, validator biasanya meminta GetHeader sekitar 400 md setelah slot dimulai - karena banyaknya validator, relai sering kali harus mengirimkan banyak permintaan. Ini juga yang dapat terjadi dengan grup penyortir bersama yang besar. Ini berarti Anda memerlukan infrastruktur untuk memfasilitasi proses ini.
Relai juga membantu memfasilitasi pemisahan pembuat dan pembuat blok, sekaligus memverifikasi bahwa pembuat membuat blok yang benar. Mereka juga memeriksa apakah biaya dibayarkan dengan benar dan bertindak sebagai perlindungan DoS. Juga, mereka pada dasarnya adalah penjaga blok dan menangani pendaftaran validator. Ini sangat penting dalam arsitektur sequencer tak terbatas, karena Anda perlu melacak siapa yang berpartisipasi dan siapa yang tidak (misalnya, lapisan sinkronisasi yang dibahas sebelumnya).
Mengenai waktu pemblokiran (yaitu pemblokiran yang dikirimkan oleh pembuat), biasanya terjadi sekitar 200 milidetik. Sebagian besar mulai berjalan sebelum/setelah sekitar 200 md, meskipun seperti GetHeader ada variasi yang cukup besar. Jika pembangun mengirim blok ke beberapa relai, itu akan menyebabkan penundaan yang cukup lama. Bloxroute juga melihat apa yang terjadi ketika blok dikirim ke beberapa relai. Seperti yang Anda duga, penundaan propagasi blok ke lebih banyak relai akan lebih besar. Rata-rata, relai kedua membutuhkan 99 milidetik untuk menghabiskan blok, 122 milidetik ketiga, dan 342 milidetik keempat.
Apa yang mungkin telah kita pelajari selama beberapa bulan terakhir adalah bahwa RPC sangat penting untuk blockchain. Ini adalah beban yang sangat besar tanpa infrastruktur yang tepat, dan memiliki opsi RPC yang tepat juga penting. Dalam hal ini, RPC penting bagi investor ritel untuk mengirimkan transaksinya ke RPC (dan mempool publik). Bloxroute menjalankan tes kecil terhadap 20 transaksi yang dikirim ke berbagai RPC dan mengukur waktu yang diperlukan untuk setiap transaksi dimasukkan ke dalam satu blok.
Sumber: Lab Bloxroute
Menariknya, beberapa RPC tidak menyertakan transaksi hingga beberapa blok kemudian, bergantung pada pembangun mana yang menang di blok berikutnya. Jika RPC mengirimkan transaksi ke lebih banyak pembangun, kemungkinan penyertaan cepat lebih tinggi. Meskipun dimungkinkan bagi pencetus transaksi untuk memanfaatkan posisi unik mereka agar mengalir untuk menargetkan pembangun tertentu atau bahkan membangun blok mereka sendiri.
Performa mereka juga menarik dalam statistik performa relai Ethereum. Ini membantu kami mendapatkan pemahaman yang lebih dalam tentang cara kerja PBS di dunia multi-validator/builder/relay, yang ingin kami capai dengan pemutakhiran Rollup. Metrika memiliki beberapa statistik hebat tentang ini dan semua poin data adalah karena mereka.
Penting untuk dicatat bahwa tawaran yang terlewatkan terjadi saat penyalur diharapkan untuk menawar, tetapi tidak menawar. Ekspektasi target berasal dari validator yang terdaftar dengan relai tertentu untuk setiap slot yang diberikan. Ini bukan kesalahan relay semata, juga tidak ditangani seperti itu di tingkat protokol.
Sumber: app.metrika.co
Jika terjadi kesalahan (seperti relai yang melayani blok yang tidak valid), dan itu bertanggung jawab, itu akan dihitung sebagai kesalahan. Ini biasanya jarang terjadi dan sebagian besar merupakan kegagalan preferensi pendaftaran (yaitu batas bahan bakar atau biaya yang tidak sesuai dengan pendaftaran untuk validator tertentu). Yang lebih jarang lagi adalah kegagalan lapisan konsensus, yang tidak konsisten dengan aturan lapisan konsensus Ethereum, seperti slot yang salah atau hash induk yang tidak selaras dengan blok sebelumnya, dll.
Dalam hal latensi (seperti waktu yang diperlukan validator untuk menerima header blok yang dibuat oleh pembuat), datanya sangat konsisten. Meskipun ada beberapa outlier, seperti relai yang diminta berada di lokasi geografis yang berbeda dengan validator yang dipilih.
Sumber: app.metrika.co
Mengenai pembangun, jumlah pembangun di MEV-boost adalah sekitar 84, dengan tiga pembangun teratas membangun sekitar 65% dari blok yang dibangun. Meskipun ini mungkin agak menyesatkan karena ini juga merupakan pembangun yang berjalan paling lama. Hasilnya serupa jika kerangka waktu dikurangi. Jumlah pembangun aktif sebenarnya jauh lebih rendah, 35 dalam 30 hari terakhir dan 24 dalam seminggu terakhir. Persaingan sengit, dan biasanya pembangun terkuat menang. Aliran pesanan eksklusif mungkin sudah ada, yang hanya akan memperburuk situasi. Kami berharap distribusi pembangun tetap relatif terpusat (karena ini adalah perlombaan untuk aliran pesanan yang optimal dan pengoptimalan perangkat keras) kecuali jika kami melakukan perubahan besar pada penyiapan. Meskipun bukan masalah mendasar, ini masih merupakan kekuatan sentralisasi di tumpukan dan kami akan senang mendengar ide tentang cara menantang status quo di sini. Jika Anda tertarik untuk menggali lebih dalam masalah (serius) ini, kami sangat menyarankan untuk membaca artikel Quintus tentang aliran pesanan, lelang, dan sentralisasi.
Untuk peran Builder di tumpukan modularitas mendatang, kami cukup yakin (setidaknya dalam penyiapan Cosmos SDK) kita akan melihat penyiapan Modul Pembangun seperti Lewati/Mekatek. Solusi lain adalah pengaturan jenis SUAVE, seperti rantai pembangun global spesifik yang menyediakan layanan pembuatan blok dan preferensi tawaran ke sejumlah rantai untuk memastikan PBS. Kami akan mengeksplorasi solusi ini secara lebih mendalam nanti, dan memberikan beberapa jawaban atas pertanyaan yang tidak dibahas di sini.
Mengenai relai, kami sangat menyarankan untuk membaca artikel oleh Ankit Chiplunkar dari Frontier Research dan Mike Neuder dari Ethereum Foundation yang disebut Relai Optimis dan di mana menemukannya. Posting ini merinci bagaimana relai dalam MEV-boost bekerja, pengorbanannya saat ini dan biaya pengoperasian, dan beberapa perubahan yang dapat meningkatkan efisiensi. Menariknya, menjalankan relai di MEV-Boost saat ini menelan biaya sekitar $100.000/tahun menurut perkiraan Flashbot.
Deterministik
Sebelum kita berbicara tentang determinisme blockchain modular (seperti yang terlihat saat ini), mari kita lihat artikel “Modular MEV” kami sebelumnya. Perhatikan bahwa ini bukan tampilan finalitas "resmi" atau komprehensif, tetapi kami yakin ini paling akurat mewakili nuansa finalitas Rollup untuk kemudahan pemahaman.
Pending_On_L2: Rollup orderer menunjukkan komitmen lunak bahwa transaksi pengguna pada akhirnya akan dilakukan dan diselesaikan pada lapisan dasar keamanannya.
Finality_On_L2: Sequencer telah berkomitmen pada fungsi transisi status Rollup, dan blok telah ditambahkan ke rantai kanonis Rollup.
Pending_On_L1: Fungsi transisi input atau output/status dari transaksi telah dipublikasikan ke L1, tetapi bukti validitasnya belum dikeluarkan, atau periode arbitrase belum berakhir - ini membutuhkan Ethereum untuk dua periode berturut-turut. Ini adalah titik di mana sebagian besar Batal Optimis mengatakan mereka telah mencapai finalitas, tetapi masih ada periode tantangan 7 hari yang sewenang-wenang pada titik ini sesuai dengan jembatan lintas rantai spesifikasi.
Finality_On_L1: Untuk Batal Optimis, periode arbitrase telah berakhir, atau bukti validitas yang dipublikasikan dan diverifikasi telah dikonfirmasi oleh supermayoritas dalam dua zaman berturut-turut.
Sekarang, dalam Sovereign Shared Sort Rollup, ini terlihat sedikit berbeda, mari kita coba jelaskan dengan diagram:
Dalam hal ini, secara teoritis kita bisa mendapatkan determinisme pada L1 sebelum L2, dst.? Ya, dalam hal ini L2 berdaulat. Ini dengan asumsi tidak ada bukti penipuan dan periode tantangan, atau Anda menggunakan bukti validitas.
Jadi bagaimana kita mencapai tingkat finalitas ini? Finalitas blok tercapai ketika sebuah blok ditambahkan ke rantai kanonis, yang tidak dapat ditarik. Namun, ada beberapa nuansa di sini, bergantung pada node penuh atau ringan. Dalam kasus blok terurut, ini bersifat deterministik setelah disertakan dalam blok lapisan DA. Blok (dengan akar status) diberlakukan oleh node/validator penuh Rollup, yang memberi mereka jaminan status akar valid yang berasal dari blok terurut dari lapisan dasar. Untuk determinisme di luar simpul penuh (seperti untuk klien ringan atau jembatan rantai silang), Anda harus yakin akan validitas root status ini. Di sini, Anda dapat menggunakan salah satu metode yang dijelaskan di bawah ini. Juga, pendekatan lain adalah membuat validator bertanggung jawab atas bukti yang benar dari akar negara (rute Optimis), melalui ikatan dan bukti penipuan berikutnya. Selain itu, Anda dapat memberikan bukti validitas (ZK).
Berbagai cara untuk mencapai finalitas blok:
Melalui Proof of Work (PoW), LMD+Ghost, Goldfish, Ouroboros (PoS) dan metode probabilistik lainnya.
Metode yang dapat dibuktikan dengan cara anggota komite yang cukup menandatangani blok. (misalnya Tendermint 2/3, Hotshot2 atau jenis PBFT lainnya)
Tergantung pada urutan transaksi/blok pada layer DA, dan aturannya, yaitu aturan canonical chain dan fork selection.
Kita dapat mencapai jenis finalitas yang berbeda melalui mekanisme yang berbeda.
Salah satu jenis finalitas adalah "finalitas lunak" (seperti pending), yang dapat dicapai dengan pemilihan pemimpin tunggal. Dalam hal ini, setiap slot hanya akan memiliki satu atau nol blok (komit atau tidak), dan lapisan sinkronisasi dapat dengan aman mengambil urutan transaksi di blok ini.
Jenis finalitas lainnya adalah "finalitas yang dapat dibuktikan", yang memberikan jaminan yang lebih kuat (pada dasarnya final) daripada finalitas lunak. Untuk mencapai finalitas yang dapat dibuktikan, mayoritas pemesan harus menandatangani blok, dengan demikian menyatakan persetujuan mereka bahwa blok tersebut kanonik. Meskipun pendekatan ini bagus, mungkin tidak diperlukan jika pemilihan pemimpin tunggal telah diterapkan, karena pada dasarnya menjamin pemesanan blok. Jelas, ini tergantung pada algoritma pemilihan pemimpin tertentu yang diterapkan. Misalnya, apakah implementasi 51%, implementasi 66%, atau pemimpin tunggal (sebaiknya acak (VRF) dan pemilihan rahasia). Jika Anda ingin mempelajari lebih lanjut tentang determinisme di Ethereum, baca artikel ini yang sangat kami rekomendasikan, dan artikel yang akan kami rekomendasikan nanti untuk kumpulan penyortir tak terbatas.
berlisensi, semi-lisensi atau tidak diizinkan
Untuk mencegah potensi serangan DoS, hambatan ekonomi harus ditetapkan untuk bergabung dengan grup pemesan dan mengirimkan transaksi ke lapisan pemesan. Dalam grup terbatas (jumlah penyortir terbatas) dan tidak terbatas (jumlah penyortir tidak terbatas), penghalang ekonomi harus diterapkan untuk mengirimkan batch ke lapisan DA untuk mencegah lapisan sinkronisasi (menyebarkan blok di antara penyortir) Memperlambat atau di bawah serangan DDoS . Namun, lapisan DA itu sendiri juga menyediakan beberapa perlindungan, karena mengirimkan data ke lapisan tersebut memerlukan biaya (da_fee). Uang jaminan yang diperlukan untuk bergabung dengan grup tak terbatas harus mencakup biaya tambahan yang diperlukan untuk mencegah lapisan sinkronisasi dari spam. Di sisi lain, margin yang diperlukan untuk bergabung dengan kelompok terbatas akan bergantung pada permintaan (seimbang dari perspektif biaya/pendapatan).
Untuk kumpulan penyortir tak terbatas, kami tidak dapat mencapai finalitas yang dapat dibuktikan pada lapisan penyortir (karena kami tidak pernah tahu persis berapa banyak pemilih/penandatangan aktif yang ada). Di sisi lain, dalam kelompok koorter yang dibatasi, finalitas yang dapat dibuktikan dapat dicapai oleh mayoritas blok penandatanganan koorter. Ini memang membutuhkan lapisan sinkronisasi untuk mengetahui lapisan sequencer dan berapa banyak sequencer yang aktif pada waktu tertentu, yang merupakan tambahan tambahan. Dalam rangkaian penyortir terbatas (mis. hingga 100), Anda juga dapat mengoptimalkan jumlah penyortir untuk meningkatkan "kinerja", meskipun dengan mengorbankan desentralisasi dan resistensi sensor. Pentingnya kelompok terbatas dan jaminan ekonomi untuk memberikan kepastian yang dapat dibuktikan secara "cepat" juga bersifat deterministik.
Jenis penyortir tak terikat dan penyortir terikat juga tercermin dalam blockchain tradisional.Misalnya, PoS (Casper+LMD-GHOST) di Ethereum mengadopsi tipe tak terbatas, sedangkan rantai berdasarkan Cosmos SDK/Tendermint mengadopsi tipe terikat. Pemikiran yang menarik adalah, apakah kita berharap untuk melihat ekonomi dan opsi seperti bukti saham dari komunitas di sekitar pemesan bersama? Dalam hal ini, kami telah melihat pergerakan menuju sentralisasi beberapa entitas (jadi tidak terikat tidak masalah jika Anda sudah memiliki beberapa penyedia/kumpulan bukti saham yang besar). Meskipun mereka "menyembunyikan" sentralisasi, Anda tetap dapat menambang jika Anda mau. Dari sudut pandang ideologis, pilihan harus hampir selalu tidak terbatas - tetapi ingat bahwa prinsip ekonomi membuat mereka sangat mirip. Terlepas dari siapa pesertanya, ekonomi dari apa yang Anda bayar harus tetap sama, seperti biaya DA dan biaya perangkat keras (walaupun ini dapat dikurangi dengan jumlah bukti saham yang Anda alokasikan dan alami, dan efisien pengoperasian infrastruktur). Bahkan di dunia PoS yang terbatas, kami telah melihat sekelompok penyedia infrastruktur menjadi validator terbesar dan paling umum di hampir semua rantai. Di sebagian besar rantai Cosmos, ketergantungan antar validator sudah sangat besar, dan hal ini tentunya menimbulkan bahaya bagi desentralisasi dan resistensi sensor dari rantai tersebut. Namun, fakta yang sangat berbeda adalah bahwa investor ritel mana pun dapat mempertaruhkan jumlah berapa pun dengan validator apa pun yang mereka pilih. Sayangnya, ini biasanya ditempatkan di bagian atas daftar, dan hidup terus berjalan. Kami bertanya lagi: apakah kami mengharapkan model ekonomi serupa di dunia modular? Satu harapan bukan itu masalahnya, tetapi dengan spesialisasi Anda sering membutuhkan yang paling cocok - dan mereka cenderung menjadi penyedia bukti saham profesional. Kami juga akan membahas masalah ekonomi ini di bab terpisah nanti.
Namun, satu hal penting yang perlu diingat dalam semua masalah ini adalah bahwa hal terpenting adalah otentikasi pengguna akhir, yang tersedia untuk siapa saja, di mana pun mereka berada (bahkan di Giza) melalui klien ringan dan piramida DAS).
Sumber: @JosephALChami
Berikut adalah trade-off dan keuntungan dari penyortir yang dibatasi dan tidak dibatasi:
Kumpulan penyortir tak terbatas:
*Siapa pun dengan obligasi/staking yang cukup dapat menjadi penyortir = tingkat desentralisasi yang tinggi
Set penyortir terbatas:
Ini adalah salah satu solusi Ethereum untuk determinisme slot tunggal, dan memiliki komite "mayoritas" super.
Ada ruang desain yang cukup besar untuk bagaimana set penyortir ini dipantau dan anggota baru ditambahkan atau dihapus. Misalnya, apakah ini akan dicapai melalui Tata Kelola Tokenholder (bagaimana dengan banyak Token dan Rollup yang berbeda menggunakan koleksi?). Ini berarti bahwa perubahan pensinyalan off-chain dimungkinkan melalui konsensus sosial (misalnya, ambil Ethereum sebagai contoh). Namun, ingatlah bahwa konsensus on-chain yang sebenarnya sudah ditetapkan dengan jelas, dan hukuman untuk pelanggaran aturan konsensus sudah ada.
Mekanisme Ekonomi untuk Penyortir Bersama
Ekonomi berbagi jaringan sequencer memungkinkan beberapa opsi menarik. Seperti yang telah kita bahas sebelumnya, validator dalam jaringan pemesan bersama tidak jauh berbeda dengan validator L1 pada umumnya. Jaringan yang diikutinya lebih dioptimalkan untuk melakukan satu tugas, yaitu menerima maksud (sebelumnya PBS), dan karenanya mengusulkan dan memesan transaksi. Sama seperti validator "biasa", ada komponen pendapatan dan biaya. Di kedua sisi persamaan, ada banyak fleksibilitas dalam jaringan yang diikuti oleh validator, mirip dengan L1 biasa.
Pendapatan berasal dari pengguna atau Rollup yang pada akhirnya ingin berinteraksi dengan membayar biaya tertentu untuk menggunakan sequencer bersama. Biaya ini dapat berupa persentase dari penarikan MEV (memasukkan nomor mungkin sulit diperkirakan), transfer nilai lintas rantai, Gas, atau biaya tetap per interaksi. Solusi pendapatan yang paling tepat mungkin membayar pemesan bersama kurang dari nilai tambahan yang diperoleh melalui pemesan bersama Rollup, bersama dengan manfaat keamanan dan likuiditas bersama. Tetapi sisi negatifnya adalah sulit untuk mengukur manfaat desentralisasi dari bagian lain dari tumpukan. Namun, karena jaringan pemesan bersama tumbuh menjadi ekosistemnya sendiri, kemampuannya untuk menarik biaya dapat meningkat. Hal ini sebagian besar disebabkan oleh kemampuan bawaan mereka untuk berkumpul dengan mudah, dengan skala ekonomi tertentu. Semakin banyak Rollup dan aplikasi bergabung ke jaringan, semakin banyak MEV lintas domain yang dapat diekstrak.
Dari segi biaya, jaringan pemesanan bersama juga memiliki opsi bersaing. Mereka dapat dengan mudah mendanai penggunaan jaringan mereka dengan mendanai biaya penerbitan pada lapisan DA, atau bahkan biaya interaksi dengan aplikasi di Rollup. Ini mirip dengan strategi yang digunakan oleh perusahaan Web 2.0, di mana Anda mengambil kerugian awal pada akuisisi pengguna (atau rollup), berharap pendapatan jangka panjang mereka akan lebih besar daripada biayanya. Metode lain yang lebih baru atau Crypto-native adalah mengizinkan Rollup membayar biaya DA dengan Token aslinya. Di sini, lapisan penyortir bersama menanggung risiko harga antara Token yang diperlukan untuk menerbitkan data pada lapisan DA dan Token asli Rollup. Intinya, ini masih merupakan biaya awal penyortir bersama, tetapi menciptakan konsistensi ekosistem dengan mendapatkan Token dari "pemasok" (yaitu Rollup). Ini agak mirip dengan konstruksi gudang yang kami jelaskan di makalah AppChain, dan berbagai bentuk DA dapat digunakan untuk mengurangi biaya. Tingkat DA yang berbeda akan menawarkan harga yang berbeda karena penggunaan, kemampuan pengguna untuk memverifikasi dengan mudah melalui klien ringan, atau sekadar membuat pilihan ukuran blok yang berbeda. Terakhir, pemesan bersama juga dapat mengelompokkan transaksi sebelum memublikasikan ke lapisan DA. Dalam kasus ZKR, ini dapat mengurangi biaya transaksi melalui sejumlah saldo transaksi, dan dalam hal ORU, Anda dapat melakukan berbagai optimasi Gas pemrosesan batch, yang saat ini dapat kita lihat di berbagai Rollup. Ini akan mengurangi jumlah data yang perlu dipublikasikan ke lapisan DA, sehingga mengurangi biaya jaringan sequencer bersama dan meningkatkan profitabilitas seluruh jaringan. Ini akan datang dengan biaya membatasi interoperabilitas dan mengubah waktu finalitas blok (determinisme pada L1 seperti yang disebutkan sebelumnya).
Secara keseluruhan, ekonomi berbagi jaringan sequencer memungkinkan beberapa eksperimen menarik dan strategi bootstrap. Kami memperkirakan bahwa perbedaan utamanya adalah ukuran ekosistem, sehingga jumlah MEV lintas domain lebih besar daripada aspek biaya. Kami juga sangat merekomendasikan untuk melihat posting blog tim Espresso tentang pemesan bersama, mereka juga mencakup pengorbanan ekonomi (dan positif) dari jenis jaringan ini. Untuk menunjukkan mengapa Rollup termotivasi untuk memanfaatkan penyortir bersama (selain ekonomi), kita dapat mempertimbangkannya dari perspektif teori agregasi.
Teori Agregasi dan Penyortir Bersama
Cara lain untuk mendeskripsikan properti yang dibawa oleh penyortir bersama adalah melalui lensa teori agregasi. Teori agregasi mengacu pada konsep bagaimana platform atau agregator mengintegrasikan platform lain dan penggunanya secara sistematis untuk mendapatkan perhatian pengguna yang signifikan. Anda pada dasarnya memindahkan game dari alokasi sumber daya yang langka (mis., ruang blok) ke kebutuhan untuk mengontrol sumber daya yang melimpah (sekali lagi, ruang blok masuk akal dalam contoh ini). Teori Agregasi sebenarnya menggabungkan pemasok dan produk (yaitu Rollup dan Blockspace) menjadi pengalaman pengguna super untuk melayani basis pengguna agregat. Saat efek jaringan dari agregator ini tumbuh, hubungan ini menjadi semakin eksklusif. Saat ini terjadi, pengalaman pengguna menjadi pembeda utama antara penyiapan serupa. Jika ada insentif untuk menarik pengguna baru (seperti pengalaman pengguna yang baik dan interoperabilitas yang lebih baik), kecil kemungkinan Rollup akan pindah ke jaringannya sendiri atau penyiapan yang berbeda - karena efek jaringan mendorong pemasok baru dan pengguna baru bergabung. Ini menciptakan efek roda gila, tidak hanya dari perspektif penyedia dan pengguna, tetapi juga dari perspektif tahan sensor gabungan.
Sumber: Teori Agregasi 2015, Ben Thompson
Di ranah penyortir bersama, Teori Agregasi dapat dilihat sebagai "kombinasi" dan federasi dari berbagai Rollup, semuanya menggunakan vertikal tumpukan yang serupa - memberdayakan diri mereka sendiri dan orang lain sambil memungkinkan pengguna mendapatkan pengalaman yang sama.
Penyedia (seperti Rollups) secara teoritis tidak eksklusif untuk set coorter bersama, tetapi dalam praktiknya set coorter bersama, rollupnya, dan pengguna mendapat manfaat dari serangkaian loop efek jaringan yang mengarah pada peningkatan penggunaan rollup ini. Manfaat ini memudahkan Rollups dan pengguna untuk mengintegrasikan ke dalam tumpukan bersama karena mereka akan kehilangan lebih banyak jika mereka tidak berpartisipasi. Meskipun manfaat ini mungkin sulit dilihat saat Anda hanya memiliki dua Rollup yang berbagi satu set sequencer, manfaat tersebut menjadi lebih jelas saat Anda menambahkan lebih banyak Rollup dan Pengguna ke dalam persamaan. Kumpulan penyortir bersama memiliki hubungan langsung dengan pengguna, saat mereka memesan transaksi, bahkan jika pengguna itu sendiri tidak tahu bahwa mereka berinteraksi dengan mereka, karena dari sudut pandang mereka, mereka hanya menggunakan Rollup yang memiliki alasan untuk berinteraksi dengan mereka ( Ini berarti pemesanan/penyortir menjadi eksklusif). Satu-satunya biaya penyortir ini sebenarnya adalah biaya perangkat keras untuk menjalankannya, selama ruang blok dan token yang mengamankannya berharga bagi pengguna akhir. Biaya transaksi didigitalkan, dibayarkan dari dompet pengguna, dan mungkin di masa mendatang, bahkan dapat diabstraksi melalui kemajuan seperti host pembayaran dalam abstraksi akun (namun, seseorang harus menanggung biaya DA, pemesanan, dan eksekusi).
Ini lebih masuk akal ketika mempertimbangkan perusahaan Josh dan Jordan sebelumnya di Astria - Google. Sejak awal, produk Google telah terinspirasi oleh ide AT, terutama di Google Search, yang dibuat dengan memodulasi setiap halaman dan artikel, membuatnya dapat diakses langsung melalui jendela pencarian global.
Dalam kasus kumpulan penyortir bersama, pengguna yang menggunakan Rollups (mereka yang berbagi kumpulan penyortir) memiliki biaya akuisisi yang semakin rendah, karena seiring bertambahnya jumlah pemasok (Rollup), mereka cenderung tertarik ke kumpulan tersebut . Ini berarti bahwa, dalam banyak kasus, agregator (atau multi-agregator) memiliki kemungkinan efek win-win, karena nilai agregator meningkat seiring dengan jumlah pemasok (tentu saja selama pengalaman pengguna bagus). Sebaliknya, pada jaringan serial tunggal, akuisisi pelanggan terbatas pada jaringan tunggal dan aplikasinya. Jika pengguna ingin menggunakan aplikasi Rollup pada Rollup yang berbeda, mereka harus (dalam batasan saat ini) keluar dari jaringan seluruhnya. Ini berarti bahwa keterikatan dan nilai pengguna tidak terlalu tinggi, dan itu juga berarti bahwa setiap saat, jika ekosistem Rollup lain bernilai tinggi (atau memiliki lebih banyak insentif), modal dapat hilang.
Ringkasan Atribut dan Pengorbanan
Atribut
Kumpulan penyortir bersama adalah jaringan rollup yang menggabungkan dan mengurutkan transaksi untuk beberapa rollup. Rollup ini berbagi penyortir yang sama. Penggabungan sumber daya ini berarti bahwa Rollups mendapatkan keamanan ekonomi yang lebih kuat dan kemampuan anti-sensor, yang dapat memberikan jaminan deterministik lunak yang cepat dan transaksi lintas-Rollup bersyarat.
Saat ini, ada banyak kebisingan tentang atomisitas di antara Rollup yang berbagi kumpulan penyortir yang sama, sebagian besar seputar apakah itu atom secara default - padahal bukan. Namun, jika Rollup yang dipermasalahkan menerapkan fungsi transisi status (STF) satu sama lain sebagai ketergantungan di antara mereka, yang melibatkan transaksi bersyarat, maka mereka memang dapat mencapai atomisitas di antara mereka - selama Keselarasan slot/blocktime mereka (seperti dengan set penyortir bersama). Dalam hal ini, untuk mendapatkan interoperabilitas atom, Anda benar-benar hanya perlu menjalankan klien ringan rantai B pada rantai A dan sebaliknya (mirip dengan cara kerja IBC). Untuk lebih memperkuat interoperabilitas langkah-langkah keamanan (di luar mempercayai satu simpul penuh sebagai simpul ringan), Anda dapat menerapkan ZKP (Bukti Negara) untuk memecahkan "masalah oracle" untuk memastikan kebenaran keadaan. Ini akan memperjelas untuk melihat apakah transaksi bersyarat atau sesuatu seperti itu telah mencapai jembatan lintas rantai kanonis di antara mereka. Bukti penipuan juga merupakan kemungkinan, tetapi jelas akan meninggalkan periode tantangan (artinya pihak ketiga akan datang untuk menanggung biaya risiko ini). Juga, dalam kasus klien ringan (bukan node penuh), setidaknya akan tertinggal satu blok karena menunggu tajuk tanda tangan + jendela bukti penipuan (jika ada).
Kami percaya bahwa masalah "jembatan lintas rantai" kemungkinan besar akan diselesaikan dengan klien yang ringan dan bukti tanpa pengetahuan. Tantangan dengan menggunakan klien yang ringan (bukan smart contract) dalam hal ini adalah hard fork (peningkatan, dll.) di sisi simpul Rollup perlu berkoordinasi satu sama lain agar jembatan mereka tetap berjalan (seperti halnya IBC perlu mengaktifkan modul negara yang sama). Jika Anda ingin menyelami lebih dalam topik khusus ini (dan cara menanganinya), kami sangat menyarankan untuk melihat presentasi ini.
Alasan pemesan bersama menskala dengan sangat baik adalah karena mereka tidak mengeksekusi dan menyimpan status apa pun (seperti yang dilakukan pemesan terpusat saat ini). Hal yang sama berlaku untuk node Rollup itu sendiri (kecuali jika mereka menginginkan atomisitas di antara mereka sendiri - misalnya klien ringan/bukti status). Node ini hanya menjalankan transaksi yang valid untuk Rollup mereka, dan transaksi lintas domain bersyarat apa pun yang valid untuk mereka. Jika node Rollup harus mengeksekusi dan menyimpan status untuk beberapa Rollup, hal ini akan menghambat skalabilitas dan mengurangi desentralisasi (dan dengan demikian resistensi sensor). Ini juga memperkuat konsep pemisahan produsen-pembangun blok (PBS). Meskipun kami masih perlu memisahkan pembuat dan pembuat blok sepenuhnya. Dalam pengaturan saat ini, pemesan pada dasarnya adalah pembuat dan pembuat blok (walaupun mereka tidak melakukan transaksi). Pengaturan yang ideal mungkin adalah di mana pemesan hanya ada untuk menandatangani blok secara membabi buta dari pengaturan pembangun yang sangat dioptimalkan dan memastikan bahwa blok diterapkan dengan benar (sambil memberikan tingkat kepastian ekonomi dan ketahanan sensor yang tinggi terhadap sertifikasi itu). Dengan cara ini, mereka dapat memberikan tingkat keamanan dan komitmen yang tinggi untuk menjamin soft finality ke node Rollup.
Untuk transaksi bersyarat cross-rollup, mereka juga ada untuk membantu mengaktifkan node rollup (pelaksana) untuk menyediakan akar status perantara, memungkinkan atomisitas antara rollup.
tukar tambah
Parameter batas waktu yang disebutkan di atas memiliki beberapa efek menarik pada MEV dan penyertaan transaksi, tergantung pada mekanisme masternode/konsensus set pemesan. Misalnya, jika parameter batas waktu dijelaskan relatif singkat dalam makalah rantai khusus aplikasi kami, produsen blok dari kumpulan pemesan yang terdesentralisasi harus menerbitkan data secepat mungkin. Di dunia seperti itu, Anda dapat melihat persaingan antara "validator" yang bersaing untuk menjadi master node dan menawar lapisan DA untuk ruang blok hingga tidak lagi menguntungkan.
Seperti yang Evan bahas dalam postingan lazy orderer aslinya di forum Celestia, menunggu transaksi dipublikasikan ke lapisan dasar (Celestia dalam kasus ini) sebelum mengeksekusinya sangat tidak efisien. Karena sekarang Anda dibatasi oleh waktu blok lapisan dasar - yang terlalu lama untuk menunggu pengalaman pengguna. Untuk pengalaman pengguna yang lebih baik, pemesan bersama menyediakan Rollups dengan komitmen deterministik yang lembut (seperti yang dijelaskan sebelumnya), yang memberi pengguna pengalaman pengguna yang biasa mereka dapatkan di Rollup terpusat yang ada (sambil mempertahankan desentralisasi dan ketahanan sensor yang tinggi). Komitmen lunak pada dasarnya hanyalah komitmen pada urutan akhir transaksi, tetapi didukung oleh jaminan ekonomi yang berat dan penyelesaian cepat setelah dikeluarkan. Ini juga dicakup oleh bukti penipuan (sebagaimana disebutkan dalam pendahuluan). Hard finality yang sebenarnya dicapai setelah semua data transaksi dipublikasikan ke lapisan dasar (artinya L1 benar-benar mencapai finality yang lebih cepat). Itu tergantung pada apakah Rollup menggunakan bukti penipuan atau bukti tanpa pengetahuan untuk verifikasi bukti kedaulatannya - yang terjadi pada Rollup. Alasan menginginkan pemisahan ini adalah untuk menghilangkan hambatan besar transisi keadaan dari penyortir. Sebaliknya, node Rollup hanya berurusan dengan node yang valid untuk mereka (artinya kita harus menambahkan transaksi bersyarat, bukti status, atau validasi node ringan untuk interoperabilitas yang tepat). Determinisme keras masih bergantung pada lapisan dasar (tetapi ini dapat mencapai 15 detik di Celestia, dan juga deterministik di bawah Tendermint), yang memberi kami jaminan determinisme keras yang relatif cepat pada Rollup.
Gunakan bukti tanpa pengetahuan di dalam jaringan untuk mengoptimalkan validasi, ukuran transaksi (mis. hanya publikasikan perbedaan status - tetapi ini menambah tingkat kepercayaan yang lebih tinggi hingga ZKP dipublikasikan). Seperti yang disebutkan sebelumnya, bukti status ini dapat digunakan untuk memungkinkan rantai/pembatalan yang terhubung memiliki interoperabilitas yang lebih mudah dan lebih cepat (tanpa menunggu jendela tantangan).
Kelemahan dari transaksi bersyarat ini adalah cenderung lebih mahal, memerlukan verifikasi dan biaya penerbitan yang lebih tinggi (seperti biaya verifikasi tajuk blok Tendermint, yang disubsidi pada rantai Cosmos), dan menambahkan beberapa latensi ke sistem ( tetapi masih lebih cepat daripada Isolated Rollups yang jauh lebih cepat). Atomisitas yang dicapai dengan integrasi bersama secara vertikal dapat mengkompensasi masalah ini.
Selama fase bootstrap rollup baru, menggunakan sekumpulan collator bersama sangat masuk akal, dan keuntungan yang Anda peroleh sebagai penyedia kemungkinan akan lebih besar daripada beberapa pengorbanan yang mungkin "dipaksa" Anda lakukan di tingkat parit. Namun, untuk Rollup yang sudah matang, di mana terdapat banyak transaksi dan aktivitas ekonomi, mungkin tidak masuk akal untuk melepaskan sebagian parit.
Ini menimbulkan pertanyaan apakah kita memerlukan redistribusi berbobot ekonomis/transaksional (per Rollup) serupa dari MEV yang diekstraksi untuk mendorong Rollup yang sudah matang untuk bergabung dengan set bersama - atau bahkan mencegah Rollup yang sangat matang menghasilkan jaringan sendiri. Ini semua cukup teoretis, tetapi tidak diragukan lagi ini merupakan proses pemikiran yang menarik sehubungan dengan bagaimana MEV di dunia vertikal bersama akan diwakili di antara banyak Rollup dengan berbagai tingkat aktivitas. Misalnya, jika Rollup unik yang mendorong nilai berbagi sebagian dari keuntungan ini dengan yang lain (mungkin tidak menghasilkan banyak "nilai") melalui Sequencer Set, maka pasti ada lebih banyak alasan bagi mereka untuk pindah ke sistem silo mereka sendiri. Sreeram oleh EigenLayr juga memiliki beberapa pemikiran tentang ini, yang kami sarankan untuk dibaca juga.
Hal ini menjadi semakin penting ketika mempertimbangkan bahwa ada biaya teknis yang cukup besar bagi para pencari untuk mengembangkan rantai baru, jadi standarisasi dan memberikan kedaulatan atas MEV "mereka" mungkin merupakan tempat yang baik untuk memulai. Dalam praktiknya, dalam MEV, antarmuka (atau perangkat lunak) yang dominan mungkin menang, tetapi sebenarnya memonetisasi perangkat lunak tersebut dengan menjalankan bagian penting infrastruktur sangatlah sulit (mengarah ke sentralisasi). Di tingkat pasar, apa yang disediakan oleh pemesan bersama pada dasarnya adalah kumpulan bersama untuk banyak penyedia, dengan lelang terpusat, yang dapat menghasilkan persaingan yang lebih sehat.
Kekhawatiran di sini adalah bahwa jika dua Rollup menjalankan penyortir di set bersama, maka Rollup dengan nilai "kurang ekonomis" (A) dapat dipilih untuk mengusulkan rollup dengan jumlah biaya MEV + yang tinggi dari Rollup (B). . Dari sudut pandang Rollup B, mereka pada dasarnya kehilangan beberapa nilai yang, dalam pendekatan terisolasi, akan mereka simpan sendiri.
Mengatasi kompromi interoperabilitas
Catatan lain tentang trade-off yang disajikan oleh interoperabilitas, dan cara lain untuk memecahkan beberapa masalah berikut:
Tujuan dari jaringan pemesan bersama adalah untuk memberikan jaminan kanonik untuk banyak rantai, yang jelas merupakan keuntungan besar dalam kasus ini. Ini dapat digabungkan dengan mekanisme untuk menjamin transisi status yang efisien di antara Rollups. Ini bisa berupa pendekatan berbasis komite (mis. PoS), bukti yang diamankan (pendekatan Optimis), atau pilihan kami - ZKP yang didukung oleh tanda tangan komite. Karena penyortir bersama adalah "malas", mereka hanya membuat blok super untuk mengurutkan transaksi dari beberapa Rollup, dan eksekusi transaksi tertentu diserahkan kepada Rollup tertentu. Proofs of state (yaitu Lagrange, Axiom atau Herodotus, dll.) adalah semua solusi yang memungkinkan untuk mendapatkan bukti finalitas di seluruh rollup kedaulatan. Anda bahkan dapat menambahkan bukti finalitas yang dijamin secara ekonomi melalui hal-hal seperti staking pools, EigenLayr, dll. Ide dasarnya adalah bahwa penyortir bersama memberikan jaminan ekonomi pemesanan, dan bukti validitas yang dihasilkan dari penyortiran ini bersifat deterministik. Ide dasarnya adalah bahwa Rollups dapat melakukan transaksi secara sinkron satu sama lain. Misalnya, jaringan dari dua node Rollup dapat secara kondisional mengetahui bahwa kedua riwayat Rollup valid, melalui ZKP dan data yang tersedia (data dipublikasikan ke lapisan DA yang efisien). Dengan memublikasikan awalan blok Rollup tunggal dari jaringan A dan B, node Rollup dapat menyelesaikan dua Rollup secara bersamaan. Satu hal yang perlu diperhatikan adalah bahwa transaksi cross-rollup bersyarat mengkonsumsi sumber daya dari dua sistem terpisah melalui eksekusi bersama, sehingga transaksi cross-rollup atomik (atau sinkron) cenderung lebih mahal daripada transaksi intra-rollup tunggal.
Ringkas juga mencakup transaksi "atomik" lintas rantai antara Rollups dengan pemesan bersama (dan pembukti penipuan bersama) dalam ekosistem hyperchain Optimisme, yang dapat dilihat di sini. Juga, seperti yang dikatakan Bo Du dari Polymer: "Transaksi atom lintas rantai seperti memperoleh kunci antara pecahan basis data saat menulis".
Masa Depan Integrasi Vertikal
Cara kerja rantai SUAVE yang mungkin telah dieksplorasi secara mendalam oleh Jon Charbonneau dkk, jadi kami tidak akan membahas terlalu banyak detail. Jika Anda ingin deskripsi yang lebih rinci, Anda dapat melihat artikelnya. Meskipun demikian, menurut kami integrasi vertikal layak mendapat pengenalan terpisah, baik untuk menyoroti seberapa modular kita (dan mengapa) dan untuk memperkenalkan beberapa masalah dan masalah yang terkait dengan integrasi vertikal.
Meskipun skema pemesan bersama Astria, Espresso, dan Radius saat ini sangat modular, pemesan masih bertindak sebagai pembuat dan pembuat blok (walaupun dalam kasus Astria, mereka tidak melakukan transaksi). Astria juga aktif membangun PBS ke dalam arsitekturnya sejak awal.
Jika PBS tidak dibangun ke dalam protokol, ada beberapa cara untuk mengimplementasikan PBS (walaupun dengan berbagai tingkat desentralisasi). Produk seperti SUAVE, gunakan model offline seperti MEV-Boost, atau implementasikan modul pembuat seperti modul Cosmos SDK yang dibuat oleh Mekatek dan Skip.
Perlu dicatat bahwa tidak satu pun dari metode ini yang saling eksklusif. Anda memiliki fleksibilitas untuk menggunakan beberapa metode berbeda dan membiarkan siapa pun mengekspresikan preferensi mereka. Dengan begitu, Anda bisa membuat para eksekutor bersaing untuk mengisi lowongan tersebut. Menambahkan lebih banyak opsi selalu bagus (dan konsisten dengan keyakinan kami pada modularitas). Namun, implementasi yang berbeda akan memiliki pengorbanan yang berbeda. Misalnya, dalam kasus seperti SUAVE, Anda dapat menambahkan perlindungan privasi melalui teknologi SGX atau Crypto, dan menambahkan keamanan ekonomi Crypto ke kebenaran, alih-alih mengandalkan pembuat PBS terpusat yang tepercaya sepenuhnya. (Terima kasih kepada Jon Charbonneau atas umpan baliknya di sini).
Integrasi vertikal ke dalam rantai pembuat memastikan keadilan tanpa mengambil jalan pintas, menambah latensi, dan menurunkan kinerja. Oleh karena itu, rantai pembuat harus sangat dioptimalkan dan mungkin memerlukan perangkat keras yang mahal dan kuat (mengarah ke sentralisasi). Ini berarti bahwa untuk mendapatkan validasi pengguna akhir, kami mungkin memerlukan semacam node ringan (walaupun mereka harus memercayai node penuh), atau menggunakan bukti penyiapan jenis status untuk memastikan rantai dan pengguna memiliki bukti bahwa preferensi tawaran diisi dan blok sudah benar Bangun.
Rantai seperti ini mungkin sangat membebani negara (kami ingin menghindari ini), meskipun transaksi berat negara ini akan diprioritaskan melalui kontrak pintar. Dalam kasus penawaran prioritas, penawaran tersebut diisi atau tidak diisi (untuk jangka waktu singkat), karena penawaran biasanya hanya berlaku untuk jangka waktu singkat, bergantung pada preferensi. Ini berarti kami mungkin dapat menerapkan kedaluwarsa status yang sangat efisien (dan lebih awal) untuk tawaran - yang akan memungkinkan kami memangkas data dan menjaga rantai "bersih". Tanggal kedaluwarsa ini harus cukup lama untuk tetap memungkinkan tawaran diisi terlebih dahulu, tetapi menurunkannya terlalu banyak akan membuat hampir tidak mungkin untuk mencapai masa depan blockspace futures. Kami tidak perlu memperbarui dan mengambil kontrak penawaran yang kedaluwarsa karena tidak perlu ada selamanya (tidak seperti aplikasi) - ini dapat dilakukan dengan memberikan bukti status/penyimpanan saat penawaran diisi atau dengan solusi penyimpanan DAS (seperti yang diusulkan oleh solusi Joachim Neu) untuk membuatnya lebih "aman" dan dapat dipercaya.
Seperti disebutkan sebelumnya, kebutuhan untuk memverifikasi "keaslian" SUAVE mungkin terbatas pada "jusha" (pengguna tingkat lanjut) platform, karena sebagian besar pengguna dan pelanggan SUAVE dapat memperoleh manfaat ekonomi yang tinggi darinya. Ini mungkin mendorong kita untuk hanya mengizinkan orang menjalankan node penuh jika mereka ingin memvalidasi - meskipun ini mengecualikan sebagian besar orang (bisa dibilang mereka tidak perlu memvalidasi). Ini (menurut kami) kebalikan dari Crypto, di mana kami lebih suka menerapkan verifikasi SUAVE "tanpa kepercayaan" melalui bukti negara atau implementasi ramah klien ringan.
Alasan mengapa hal ini diperlukan adalah Anda ingin memverifikasi bahwa prioritas penawaran Anda diisi dengan benar dan blok tersebut diisi dengan informasi yang benar saat membayar (untuk menghindari rebundling dan bug lainnya). Ini pada dasarnya adalah masalah oracle - sebenarnya ini dapat diselesaikan dengan bukti status (seperti halnya semua SUAVE). Namun, bukti negara ini memunculkan masalah lain saat melintasi rantai, bagaimana cara menyampaikan informasi ini melintasi rantai dengan cara yang tidak dirusak atau disembunyikan? Ini mungkin memerlukan finalitas ekonomi yang kuat (seperti yang diusulkan oleh Lagrangian), dalam hal ini Anda dapat menggunakan validator pengambilan ulang EigenLayr untuk membuktikan finalitas dan keaslian rantai, dan memiliki kendala ekonomi yang sangat kuat. Hal ini kemudian menimbulkan masalah lain (misalnya kontrak penawaran menetapkan bahwa "mesin oracle" - dalam hal ini penjamin kembali - telah menunjuk Token yang dijanjikan dan memberikan pengikatan ekonomi - tetapi bagaimana kita membuat konsensus antara Pemotongan eksternal ini? Sementara Anda dapat menulis kriteria pemotongan, ini tidak ada dalam konsensus, yang berarti pemotongan sosial akan dieksploitasi melalui kontrak pintar (yang hampir tidak pernah "adil" dan dapat menyebabkan masalah). Saat ini terjadi di EigenLayr Salah satu masalah terbesar terkait kehilangan .
Jadi, di mana ini meninggalkan kita? Mungkin, sampai kita mendapatkan on-chain "trustless" pemotongan di luar konsensus, rantai seperti SUAVE mungkin memerlukan algoritme konsensus dan keamanan Cryptoeconomic mereka sendiri untuk membuktikan preferensi tawaran dan membangun kepastian blok— Namun, ini berarti menambahkan lebih banyak vektor serangan cryptoeconomic, terutama jika Rollup nilai blok penyusunnya jauh lebih tinggi daripada keamanan kriptoekonominya sendiri.
Selain itu, masih banyak ruang desain dalam rantai tipe SUAVE dan MEV lintas domain. Berikut adalah beberapa kemungkinan arah penelitian:
Mengenai ekspresi preferensi, untuk berinteraksi dengan kontrak pintar di EVM, panggilan kontrak (pesan) harus dikirim ke fungsi tertentu di alamat kode yang diterapkan yang berisi instruksi eksekusi. Sementara pengguna memberikan masukan, mereka mungkin tidak memiliki kendali atas keluaran karena kemungkinan status.
Sebaliknya, sistem desain ekspresi preferensi (seperti SUAVE dan Anoma) hanya mengharuskan pengguna untuk menandatangani preferensi dengan ikatan, yang dibayarkan kepada pembangun dan produsen blok jika preferensi pencari terpenuhi. Untuk logika kombinatorial yang kompleks, seperti urutan transaksi untuk pencari dan pembuat MEV, berbagai bahasa dan mesin virtual mungkin perlu diimplementasikan. Ini adalah ruang desain baru yang mendapat banyak perhatian akhir-akhir ini, terutama arsitektur Anoma. Juga, kami sangat merekomendasikan artikel singkat ini.