Ketika kita melihat visi dan peta jalan dari berbagai solusi rollup, kita akan menemukan bahwa hampir semua rollup memiliki tujuan akhir Jika tujuan ini diringkas menjadi satu kalimat: membangun tumpukan teknologi, memberikannya kepada komunitas, memecahkan Perluasan blockchain, dan pada akhirnya desentralisasi tumpukan teknologi operasi dan tata kelola. Ini mengarah pada istilah rollup terdesentralisasi.
Jadi apa sebenarnya desentralisasi itu? Apa pembagian kerja antara berbagai bagian sistem Rollup? Apakah desentralisasi berarti memaksimalkan peserta operasi sistem? Apa dampak yang akan ditimbulkan oleh penyortir terpusat? Bagaimana seharusnya pemesan bersama dan konsensus lokal L2 dirancang? Apa fungsi dari pembukti unik di ZK-Rollup? Seperti apa tampilan jaringan pembukti terdesentralisasi terbuka? Mengapa kita membutuhkan akselerasi perangkat keras zk? Apa solusi untuk masalah ketersediaan data? ....
Ada diskusi tanpa henti seputar Rollup terdesentralisasi di komunitas, jadi ECN menyusun serangkaian wawancara podcast dengan tema "Rollup Terdesentralisasi", dan mengundang pendiri dan peneliti terkemuka di bidang ini untuk membicarakan pemahaman mereka tentang Rollup terdesentralisasi.
Karena semakin banyak likuiditas mengalir ke platform Layer 2, semakin banyak penyedia layanan rollup muncul, tidak hanya solusi rollup tujuan umum, rantai rollup khusus aplikasi, tetapi juga platform rollup sebagai layanan. Oleh karena itu, semakin banyak orang yang khawatir bahwa peran "sequencer" yang sangat kritis di hampir semua rollup masih terpusat. Apa risiko dari penyortir terpusat? Apakah penyortir yang terdesentralisasi merupakan pekerjaan yang mendesak?
**Di episode kedua, kami mengundang Yaoqi Jia, pendiri AltLayer Network, Toghrul Maharramov, peneliti Scroll, dan Abdelhamid Bakhta, Starknet Exploration Lead, untuk melakukan diskusi meja bundar tentang topik penyortir terdesentralisasi, sehingga penonton dan pembaca dapat memahami saat ini Beberapa kemajuan dan dilema penyortir desentralisasi. **
Pemimpin Eksplorasi Starknet Abdelhamid Bakhta, twitter @dimahledba
Masa lalu
Masalah 1: Bagaimana cara mendesentralisasikan Rollup?
Peneliti Arbitrum Patrick McCorry
Pratinjau
Masalah 3: Buktikan akselerasi jaringan dan perangkat keras zk
Ye Zhang, salah satu pendiri Scroll
Leo Fan, salah satu pendiri Cysic
Masalah 4: Ketersediaan Data dan Penyimpanan Terdesentralisasi
Qi Zhou, pendiri EthStorage
Mendengarkan
Klik untuk berlangganan podcast untuk mempelajari lebih lanjut:
Youtube:
Mikrokosmos:
stempel waktu
00:49 Yaoqi memperkenalkan dirinya
01:37 Abdelhamid memperkenalkan dirinya
02:50 Toghrul memperkenalkan dirinya
04:03 Peran penyortir dalam rollup
08:37 Pemesan terdesentralisasi: Meningkatkan pengalaman pengguna dan mengatasi masalah keaktifan dan penyensoran
19:43 Bagaimana Starknet akan mendesentralisasikan penyortir
22:59 Bagaimana Scroll akan mendesentralisasikan penyortir
26:34 Perbedaan antara konsensus L2 dalam konteks Optimistic rollup dan zkRollup
32:28 zkRollup mendesentralisasikan penyortir dan juga perlu mempertimbangkan pembukti
36:01 Apa itu rollup berbasis?
40:53 Kerugian dari sequencer bersama dan rollup berbasis, serta skenario aplikasinya
49:02 Apa pengaruh pemesan terdesentralisasi terhadap MEV?
Perkenalan tamu
Yaoqi
Saya adalah pendiri AltLayer. AltLayer sedang membangun platform "Rollup as a Service" di mana pengembang cukup mengklik beberapa tombol dan mengonfigurasi parameter. Dengan menggunakan launchpad atau panel kontrol kami, mereka dapat dengan cepat meluncurkan rollup khusus aplikasi dalam hitungan menit. Jadi itulah yang kami coba lakukan sekarang, untuk menyediakan lingkungan eksekusi dan fungsionalitas umum bagi pengembang. Kami juga menyediakan beberapa sequencer, beberapa sistem mesin virtual, dan berbagai sistem pembuktian untuk dipilih oleh pengembang.
Abdelhamid
Saya bekerja di Starkware dan saya adalah pemimpin tim eksplorasi. Tujuan grup ini pada dasarnya adalah untuk meluncurkan proyek sumber terbuka yang mirip penelitian tetapi dengan fokus teknik. Tujuan kami adalah mengerjakan proyek sumber terbuka dengan kolaborasi erat dengan komunitas dan orang-orang dari ekosistem lain. Salah satu proyek tersebut adalah Madara, yang sebenarnya adalah penyortir Starknet. Ini bukan hanya kandidat untuk jaringan publik Starknet, tetapi juga sequencer untuk rantai aplikasi Starknet dan Layer3. Ini juga terkait dengan apa yang dikatakan tamu sebelumnya, kami juga berpikir untuk menyediakan rollup sebagai fungsi layanan, orang dapat meluncurkan rantai aplikasi Starknet mereka dan memilih solusi ketersediaan data yang berbeda dengan cara yang agak modular. Sebelumnya, saya bekerja sebagai pengembang inti Ethereum selama empat tahun, terutama bertanggung jawab atas pekerjaan EIP-1559.
Pilihan
Saya seorang peneliti di Scroll, dan tanggung jawab utama saya di Scroll adalah desain protokol, desain jembatan, desentralisasi, insentif, hal semacam itu. Jadi saat saya tidak berkicau, sebagian besar waktu saya hanya mengerjakan cara mendesentralisasikan protokol atau pemesan, pembukti, hal-hal seperti itu. Seperti Starkware, salah satu hal yang sedang kami kerjakan adalah rollup SDK. Dengan demikian, Anda dapat mengeluarkan rollup berdasarkan Gulir, dan secara modular menggunakan opsi ketersediaan data yang berbeda dan seterusnya. Kami masih mempertimbangkan opsi bahwa rollup berdasarkan Scroll SDK dapat menggunakan penyortir Scroll untuk membantu mereka mencapai desentralisasi tanpa mengharuskan setiap rollup menangani desentralisasi dengan sendirinya. Tentu saja, rencana tersebut belum selesai. Namun, ini juga arah yang sedang kami kerjakan.
bagian Wawancara
topik satu
Jelaskan penyortir rollup?
Abdelhamid
Penyortir adalah komponen yang sangat penting dalam arsitektur layer2, komponen ini menerima transaksi dari pengguna, kemudian mengemas dan membundelnya menjadi blok, mengeksekusi transaksi, dan seterusnya. Ini sangat penting karena ini adalah komponen yang bertanggung jawab untuk membuat blok, karena layer2 juga merupakan blockchain dengan blok transaksi. Pemesan membuat blok ini, dan pembukti membuktikan blok ini.
Yaoqi
Seperti yang disebutkan Abdel, pemesan adalah kombinasi dari banyak fungsi di blockchain. Jadi kami mungkin benar-benar memberi pemesan terlalu banyak tanggung jawab sekarang dibandingkan dengan blockchain publik pada umumnya. Pertama-tama perlu menggabungkan semua transaksi dari pengguna, dan kemudian mengurutkan transaksi tersebut, baik berdasarkan harga bahan bakar atau berdasarkan siapa cepat dia dapat. Setelah itu, sequencer perlu mengeksekusi transaksi ini. Seperti sekarang, beberapa Layer2 menggunakan EVM (Starware memiliki mesin virtual yang berbeda), tetapi pada dasarnya sequencer perlu menggunakan mesin virtual khusus untuk menjalankan transaksi dan menghasilkan status. Kemudian transaksi mencapai tahap pra-konfirmasi, yang berarti bahwa jika Anda melihat waktu konfirmasi satu atau dua detik, atau bahkan sub-detik, itu pada dasarnya adalah status pra-konfirmasi yang diselesaikan oleh sequencer. Kemudian, untuk sebagian besar penyortir, mereka juga perlu mengunggah atau menerbitkan pos pemeriksaan atau menyatakan hash ke L1. Ini adalah konfirmasi di tingkat L1, yang kami sebut ketersediaan data. Jadi penyortir sebenarnya memiliki banyak peran dalam sistem rollup. Namun secara umum, menurut saya ini adalah komponen paling kritis dari sistem rollup.
** Topik 2 **
Mengapa penyortir terdesentralisasi penting? Jika kita menggunakan penyortir terpusat, apa bahaya tersembunyi bagi pengguna dan sistem?
Pilihan
Pertama-tama, perlu kita ketahui bahwa kecuali untuk Bahan Bakar V1 pada tahap saat ini, tidak ada rollup yang sebenarnya, karena rollup lainnya masih memiliki roda latihan.
Namun, kita dapat mengatakan bahwa setelah diklasifikasikan sebagai rollup, itu berarti multi-sig dihapus dan seterusnya. Kemudian masalah desentralisasi penyortir menjadi masalah pengalaman pengguna, bukan masalah keamanan. Jadi ketika orang berbicara tentang, katakanlah, desentralisasi L1, masalahnya sangat berbeda. Karena L1 harus memberikan jaminan untuk pemesanan dan klien ringan. Jadi jika klien ringan ingin memverifikasi bahwa status sudah benar, ia harus mempercayai validator L1. Untuk rollup, ini bukan masalahnya. Karena penyortir hanya menyediakan penyortiran sementara, yang kemudian diselesaikan oleh L1. Dan, karena rollup juga dijamin tahan sensor, kami tidak memerlukan desentralisasi untuk mewujudkannya.
Jadi, ada beberapa alasan mengapa Anda memerlukan penyortir terdesentralisasi. Pertama, jika finalisasi L1 dikatakan lambat (baik karena bukti validitas yang Anda kirimkan terlalu lambat, atau karena mekanisme periode tantangan dari bukti penipuan rollup yang optimis), Anda harus mengandalkan sesuatu untuk mencapai konfirmasi transaksi yang cepat. Pada tahap konfirmasi cepat ini, meskipun Anda dapat percaya bahwa Starkware atau Scroll tidak akan menipu Anda, mereka menunjukkan bahwa setelah pemblokiran dikonfirmasi, tidak akan ada pengaturan ulang. Ini adalah asumsi kepercayaan. Dan desentralisasi dapat menambah beberapa jaminan ekonomi, dan seterusnya.
Namun berdasarkan ini, rollup juga tidak memiliki jaminan finalitas real-time. Pada dasarnya, Anda dapat memaksakan pengemasan transaksi melalui L1, tetapi perlu waktu berjam-jam untuk mengemas transaksi tersebut. Jadi misalnya, jika ada oracle yang bertanggung jawab untuk memperbarui dan waktunya berfluktuasi, maka pada dasarnya jika oracle diperbarui selama satu jam atau lebih, aplikasi dalam rollup tidak akan tersedia. Pada dasarnya, desentralisasi memungkinkan kita untuk memberikan beberapa jaminan tahan sensor real-time yang lebih kuat, karena musuh perlu berkompromi bukan hanya satu entitas atau segelintir entitas, tetapi seluruh jaringan pemesan.
Jadi bagi kami, desentralisasi lebih merupakan solusi untuk meningkatkan pengalaman pengguna atau memperbaiki masalah pembaruan oracle, dan sebagainya. Alih-alih memberikan jaminan keamanan dasar, inilah yang dilakukan L1.
Abdelhamid
Ya, pertanyaan tentang penyortir terdesentralisasi yang Anda sebutkan tidak persis sama dengan L1 terdesentralisasi, yang menurut saya sangat penting. Karena ketika kita melihat beberapa L1 mengkritik penyortir terpusat, mereka tidak benar melihat trade-off yang dibuat oleh penyortir terpusat.
Atas dasar ini, saya ingin menambahkan sesuatu yang berkaitan dengan pengalaman pengguna, terkait dengan aktivitas. Karena jika Anda hanya memiliki satu penyortir, Anda berisiko lebih besar mengalami gangguan penyortir. Oleh karena itu, pemesan yang terdesentralisasi juga meningkatkan ketahanan dan keaktifan di jaringan. Tetapi bahkan dalam konteks terpusat, kami memiliki keamanan yang baik dalam hal keamanan. Karena ketika Anda bisa memaksa transaksi paket melalui L1, perbedaan keduanya hanyalah timeline. Dan memiliki penyortir terdesentralisasi memungkinkan Anda memiliki jaminan tahan sensor yang cepat, seperti yang disebutkan Toghrul. Jadi, saya hanya ingin menambahkan bahwa penting juga bagi liveness untuk memiliki jaringan pemesan yang terdesentralisasi.
Yaoqi
Saya ingin menambahkan sesuatu. Aktivitas mungkin adalah hal terpenting yang perlu kita pertimbangkan pada tahap ini. Kasus airdrop terbaru pada L2 paling populer, seperti Optimism dan Arbitrum, mengalami periode downtime. Oleh karena itu, menurut saya yang perlu kita selesaikan adalah bagaimana menangani ribuan permintaan transaksi per detik ketika kita hanya memiliki satu penyortir. Bahkan secara teori, jika Anda hanya memiliki satu node, itu tidak dapat benar-benar menangani begitu banyak permintaan pada saat yang bersamaan. Jadi, mengenai keaktifan, kita pasti membutuhkan banyak penyortir. Satu titik kegagalan adalah kendala nyata, tidak hanya untuk Web3, bahkan Web2 adalah masalah besar.
Di luar itu, ada masalah sensor. Jika kami hanya memiliki satu koordinator, meskipun kami melihat itu dapat dijalankan oleh tim, Anda masih perlu membuktikan bahwa tim tersebut tidak akan benar-benar meninjau transaksi. Kadang-kadang dimungkinkan dan mampu bagi pihak jahat untuk memasukkan transaksi tertentu ke dalam daftar hitam. Itu adalah sistem pemesan yang terdesentralisasi, mereka juga dapat mencoba mengirim transaksi melalui pemesan lain. Jadi itu sebabnya kami mendapat banyak kritik seputar penyortir tunggal akhir-akhir ini.
Di luar itu, ada beberapa masalah lain seperti MEV dan early run. Dalam sistem dengan penyortir terpusat, terutama untuk protokol DeFi, mereka mungkin dapat memeriksa mempool dengan mudah. Mungkin tidak dalam bentuk pelopor, tetapi mereka memiliki peluang yang lebih baik untuk mengikuti perdagangan dan menengahinya.
Banyak sekali masalah ini, dengan berbagai alasan, padahal kita lihat L2 sangat berbeda dengan L1. Namun pada akhirnya, kita masih perlu membuatnya sedesentralisasi mungkin. Jadi kami harus menghadapi beberapa masalah serupa yang kami miliki dengan blockchain publik atau L1.
Abdelhamid
Ya, saya setuju bahwa penyortir terdesentralisasi itu penting. Tetapi saya juga ingin mengatakan bahwa, seperti yang kita semua tahu, ini bukanlah pertanyaan yang mudah.
Juga, **karena rollup memiliki arsitektur yang sangat spesifik, dengan banyak entitas. Ada satu pemesan yang sedang kita bicarakan, tetapi ada juga pembukti, dan kita perlu mendesentralisasikan keduanya. **Akan ada beberapa trade-off dan beberapa kesulitan dalam menentukan harga transaksi karena berbagai faktor diperlukan untuk menjalankan jaringan. Jadi, bagaimana Anda memberi harga pada kesepakatan itu? Penyortir dan pembukti memiliki persyaratan perangkat keras yang berbeda, pembukti membutuhkan mesin yang sangat kuat, dan seterusnya. Oleh karena itu, transaksi penetapan harga di dunia yang terdesentralisasi juga merupakan masalah yang sangat sulit, oleh karena itu kita perlu waktu untuk bergerak maju secara perlahan.
Jadi kita semua akan menghadapi trade-off seperti itu Jika kita ingin desentralisasi dengan cepat, kita mungkin perlu mengambil beberapa roda pelatihan dan desentralisasi secara bertahap, karena jika kita menginginkan arsitektur yang sempurna secara langsung, itu akan memakan waktu beberapa tahun. Jadi saya pikir kami akan mengambil pendekatan pragmatis dan mencoba melakukan desentralisasi secara bertahap. Setidaknya itulah rencana kami saat ini, seperti mungkin memulai dengan mekanisme konsensus BFT sederhana dan kemudian menambahkan mekanisme konsensus lain dalam jangka pendek atau semacamnya. Jadi saya hanya ingin mengatakan, itu bukan pertanyaan yang mudah. Karena jelas ada trade-off antara kecepatan pengembangan dan seberapa dapat diterapkan arsitektur pada lingkungan yang terdesentralisasi.
Topik 3
Bagaimana cara mendesentralisasikan penyortir?
Abdelhamid
Ada banyak fitur yang ingin kami desentralisasikan, dan semuanya memiliki pengorbanan yang berbeda.
Misalnya, saat melakukan desentralisasi, Anda ingin memperkenalkan semacam mekanisme konsensus. Namun, dalam mekanisme konsensus, ada beberapa bagian. Yang pertama adalah pemilihan pemimpin, yaitu bagaimana memilih siapa yang akan membuat blok, siapa yang akan menjadi pemesan yang bertanggung jawab untuk membuat blok di slot tertentu atau dalam waktu tertentu. ** Apa yang direncanakan tim Starknet adalah memanfaatkan layer1 sebanyak mungkin. Artinya, dalam algoritme pemilihan pemimpin kami, kami ingin mempertaruhkan layer1. Misalnya, kami memiliki token, dan janji akan dilakukan pada kontrak pintar Ethereum layer1, yang digunakan untuk menentukan mekanisme pemilihan pemimpin. **Ini berarti kita perlu melakukan interaksi di mana pemesan L2 akan meminta kontrak cerdas Ethereum untuk mengetahui siapa yang akan menjadi pemimpin berikutnya atau semacamnya. Jadi jelas diperlukan semacam keacakan dan hal-hal lain. Jadi itu bukan pertanyaan sederhana. Tapi itu bagian pertama. Maka Anda perlu memiliki mekanisme untuk konsensus itu sendiri. Ada beberapa opsi: mekanisme rantai terpanjang atau BFT, atau gabungan keduanya. Seperti Ethereum, ia memiliki LMG Ghost dan Casper FFG untuk finalitas.
Jadi kita mungkin mengambil pendekatan pragmatis dan mulai dengan BFT terlebih dahulu. Mengapa? Ketika layer2 mempertimbangkan desentralisasi, tujuan kami bukanlah memiliki skala penyortir sebesar layer1. Misalnya, di Ethereum, tujuannya adalah agar jutaan validator berpartisipasi. Dalam hal ini, Anda tidak bisa begitu saja menggunakan mekanisme BFT, karena akan sangat buruk efisiensinya, dan akan menimbulkan masalah yang sangat besar. Misalnya, jika ada masalah pada jaringan Bitcoin, jika itu adalah mekanisme BFT, rantai akan berhenti total. Namun tidak demikian, jaringan Bitcoin terus membuat blok, hanya mekanisme finalitas yang diserang.
Tapi di layer2, jika targetnya adalah beberapa ratus hingga 1000 sorter, mungkin bagus untuk memulai dengan mekanisme BFT. Jadi, kita punya mekanisme pemilihan pemimpin, kemudian konsensus, dan kemudian ada dua bagian lainnya, tetapi saya akan membiarkan tamu lain terus menambahkan. Tetapi dua bagian lainnya adalah pembaruan status dan pembuatan bukti.
Pilihan
Pertama, di L2, desentralisasi merupakan masalah multifaset, seperti yang dijelaskan oleh Abdel. Terutama di zkRollup, karena ada pembukti dan pemesan, Anda harus berkoordinasi di antara mereka, Anda harus mendesentralisasikan keduanya. Masalah ini sama sekali berbeda dari L1.
Perbedaan lainnya adalah bahwa di L2, semua desain Anda adalah untuk meyakinkan jembatan yang mendasarinya bahwa konsensusnya benar, bukan untuk meyakinkan sejumlah node lain. Anda jelas harus melakukan hal yang sama, tetapi fokus utama Anda harus menjadi jembatan itu sendiri.
Saat ini, kami bekerja dalam dua arah yang berbeda. Nomor satu, saya pikir, seperti orang lain, kami sedang mengerjakan protokol BFT. Ini tidak terlalu efisien dan ada beberapa kekusutan yang perlu diselesaikan. Kami datang dengan solusi kasar, tapi masih belum optimal. Misalnya, salah satu pertanyaannya adalah, bagaimana Anda menyeimbangkan insentif antara pemilah dan pembukti? Karena pemesan mengontrol MEV, dan pembukti tidak memiliki akses ke MEV, ada insentif bagi orang untuk menjalankan pemesan alih-alih pembukti. Namun pada kenyataannya, kami membutuhkan lebih banyak pemberi bukti daripada pemesan, jadi bagaimana Anda menyeimbangkan insentif di antara keduanya? Ini adalah salah satu masalah itu.
Solusi kedua yang sedang kami kerjakan adalah arah lain. Ingat, banyak hal bisa berubah. Proposal baru keluar setiap hari. Misalnya, ada banyak pembicaraan akhir-akhir ini tentang rollup berbasis dan bagaimana Anda dapat mengalihdayakan pengurutan sepenuhnya ke L1. Arah kedua pada dasarnya membuang penyortir seluruhnya dan menggunakan beberapa pembangun eksternal. Misalnya, pembuat ethereum atau Flashbots SUAVE dll. mengusulkan blok yang dipesan dan kemudian menjalankan konsensus di dalam pembukti. Keuntungannya di sini adalah Anda tidak perlu berurusan dengan insentif karena pada dasarnya Anda dapat menggunakan PBS di dalam protokol dan ini membuat protokol yang lebih sederhana. Tetapi kerugiannya adalah karena kita membutuhkan banyak pembukti (karena kita dapat membuktikan secara paralel), cukup sulit untuk menjalankan protokol BFT klasik dengan mereka. Jadi pertanyaannya adalah bagaimana Anda mengoptimalkan protokol BFT yang ada untuk dijalankan dengan ratusan, atau bahkan ribuan, dari pembukti? Dan itu bukan pertanyaan yang mudah untuk dijawab.
Apakah memperkenalkan konsensus L2 diperlukan untuk pemesan yang terdesentralisasi?
Yaoqi
Secara kasar saya dapat menjawab pertanyaan ini karena kami baru saja meluncurkan sesuatu seperti itu.
Jadi apakah akan memperkenalkan konsensus tidak tergantung pada apakah kita menginginkannya atau tidak. Setelah Anda memiliki banyak pemesan atau bahkan hanya node, Anda harus membuat mereka setuju. Itu sangat tergantung pada asumsi Anda. Jika asumsi Bizantium, kita dapat menggunakan BFT atau protokol konsensus Bizantium yang ada. Jika itu adalah pengaturan non-Bizantium, misalnya, jika kita hanya berasumsi bahwa sebuah node hanya bisa online dan offline, dan tidak dapat bertindak jahat, maka kita dapat menggunakan protokol Raft atau protokol konsensus lain yang lebih cepat. Tapi bagaimanapun, jika kita memiliki grup pemesan atau pembukti, jika kita ingin mengatur mereka bersama untuk menghasilkan blok selama periode waktu tertentu, maka Anda harus memiliki protokol konsensus di sekitar mereka.
Jadi, seperti yang baru saja Toghrul dan Abdel sebutkan, saya yakin ada banyak proposal dan topik penelitian tentang bagaimana kita dapat menerapkan sistem pemesanan atau pembuktian yang terdesentralisasi. Jadi, karena kami baru saja meluncurkan testnet untuk sistem rollup multi-penyortir (saat ini hanya mendukung bukti penipuan untuk rollup Optimis), berdasarkan pengalaman desain dan implementasi kami, ada beberapa hal yang dapat saya bagikan tentang kesulitannya. Seperti yang Toghrul sebutkan tadi, kesulitannya bukan terletak pada protokol konsensus itu sendiri, kesulitan sebenarnya terletak pada hal-hal selain itu, seperti bagian pembuktian. Karena jika itu penyortir tunggal, Anda tidak memerlukan banyak node. Kita bisa menganggapnya sebagai EVM, mesin virtual. Jadi, ambil saja transaksi dan jalankan, lakukan transisi status. Pembukti bertanggung jawab untuk menghasilkan bukti untuk transisi status dari rangkaian transaksi sebelumnya. Namun, jika kita menjalankan protokol konsensus untuk collator dan pembukti pada rollup, maka kita perlu memasukkan logika konsensus tambahan di sana. Selain itu, Anda juga memerlukan sistem bukti untuk protokol konsensus. Oleh karena itu, ini akan memperkenalkan banyak pekerjaan untuk menghasilkan sistem pembuktian. Kemudian setelah Anda menghasilkan buktinya, Anda dapat dengan mudah memverifikasinya di L1 Ethereum.
Jadi itulah mengapa, ketika kami meluncurkan testnet multi-pemesan pertama, optimis rollup memiliki beberapa keuntungan dalam hal itu. Secara umum, Anda dapat menyederhanakan banyak hal, seperti tidak mempertimbangkan bagian bukti validitas. Seperti kami, pada dasarnya kami membandingkan semuanya dengan WASM. Jadi pada akhirnya itu adalah instruksi WASM. Jadi, dengan memverifikasi instruksi WASM ini, relatif mudah untuk memverifikasi menggunakan kode Solidity. Jika kami baru saja mengimplementasikan ulang semua interpretasi instruksi WASM di Ethereum.
Namun secara umum, masalahnya tidak tunggal. Jika kami memiliki solusi untuk masalah tersebut, maka akan ada beberapa pekerjaan lanjutan lainnya yang perlu diselesaikan pada saat yang bersamaan. Tentu akan ada masalah MEV, seperti bagaimana kita mendistribusikan MEV secara adil. Anda dapat menetapkan semua pemesan dan pembukti berdasarkan apakah mereka menghasilkan blok atau memvalidasi blok. Namun pada akhirnya, ini benar-benar merupakan kombinasi dari banyak masalah, bukan hanya masalah teknis, tetapi juga insentif ekonomi.
Dan perlu diingat bahwa L2 diusulkan karena kami ingin mengurangi biaya gas secara signifikan. Jadi kita tidak bisa memiliki begitu banyak node. Bahkan dalam menghasilkan bukti, L2 mungkin lebih mahal dari L1. Jadi kita benar-benar perlu menemukan pendekatan yang seimbang untuk masalah seperti ini.
Abdelhamid
Saya ingin menambahkan satu poin lagi. Pertama, saat ini tidak ada bukti penipuan tanpa izin yang sebenarnya untuk rollup optimis. Dan saya terus menekankan hal ini setiap ada kesempatan, karena penting untuk jujur tentang hal ini saat membandingkan. Jadi mereka sama sekali bukan L2. Itu hal pertama.
Kemudian saya ingin menambahkan sesuatu tentang asinkronitas antara penyortiran dan pembuktian, karena ini sangat penting. Seperti yang Anda katakan, kami ingin mengoptimalkan penyortiran, karena saat ini merupakan hambatan untuk semua solusi. Tapi itu bagus dalam konteks pengurutan terpusat, karena kita tahu penyortir hanya akan menghasilkan transisi nilai dan kita akan dapat memverifikasinya. Tetapi akan lebih sulit dalam konteks penyortiran terdesentralisasi, karena mungkin penyortir Anda dapat menghasilkan sesuatu yang tidak dapat diverifikasi. Maka Anda harus berurusan dengan itu nanti.
Dalam konteks penyortiran terpusat, untuk mengoptimalkan penyortiran, karena kami tidak harus membuat bukti selama proses penyortiran, kami dapat mencoba melakukannya dengan kecepatan lokal, yang ingin kami lakukan. Terjemahkan Kairo ke bahasa mesin tingkat rendah seperti LLVM dan jalankan super cepat di penyortir. Kemudian Anda dapat membuktikan secara asinkron. Dan hal paling keren tentang pembuktian adalah Anda bisa melakukannya secara paralel. Paralelisasi besar-besaran dicapai dengan membuktikan bahwa rekursi itu mungkin. Itu sebabnya kami akan dapat mengejar kecepatan penyortir. Tetapi sulit ketika didesentralisasikan, karena kita perlu memastikan bahwa pemesan hanya menghasilkan transisi status yang valid.
Pilihan
Saya akan menambahkan bahwa saya tidak yakin apa yang dilakukan Starknet di sini. Tetapi bagi kami, saya kira itu adalah asumsi umum dari setiap zkRollup bahwa jika Anda mendesentralisasikan penyortir, sistem bukti Anda harus dapat menangani kumpulan yang tidak valid. Jadi pada dasarnya, jika, katakanlah, Anda mengirimkan kumpulan dengan tanda tangan yang tidak valid, Anda harus dapat membuktikan bahwa status yang dihasilkan setara dengan status awal. Jadi akan ada beberapa biaya tambahan. Ini tentang bagaimana Anda meminimalkan kemungkinan hal ini terjadi.
Abdelhamid
Ya itu betul. Itu sebabnya kami memperkenalkan Sierra di Kairo 1 untuk membuat semuanya dapat diverifikasi. Representasi perantara ini akan memastikan bahwa setiap program Kairo 1 dapat diverifikasi sehingga kami dapat menyertakan transaksi pengembalian.
Apa itu rollup Berbasis?
Yaoqi
Rollup berbasis awalnya berasal dari posting blog oleh Justin Drake di forum Ethereum. Salah satu idenya adalah kita dapat menggunakan kembali beberapa pemverifikasi Ethereum untuk memverifikasi transaksi rollup, sehingga kita tidak memerlukan grup node terpisah untuk memverifikasi transaksi rollup yang berbeda. Secara khusus, kami akan memiliki banyak rollup di masa mendatang, termasuk rollup tujuan umum dan banyak rollup khusus aplikasi. Jadi, dalam hal ini, alangkah baiknya jika kita dapat menemukan tempat umum seperti kumpulan validator Ethereum untuk memvalidasi transaksi ini.
Tentu saja, ini hanya sebuah ide, karena juga menimbulkan banyak kesulitan teknis. Misalnya, secara teori, kami dapat meminta validator Ethereum untuk memverifikasi transaksi rollup, tetapi sangat sulit untuk mendapatkan logika verifikasi rollup yang dibundel atau disematkan ke dalam protokol Ethereum itu sendiri. Kami menyebutnya verifikasi dalam protokol, yang memerlukan hard fork node Ethereum. Tentu saja, dalam hal ini, kami dapat memverifikasi beberapa transaksi rollup. Tetapi jika kami melakukannya, Anda akan melihat masalah. Sepertinya kami ingin rollup L2 berbagi tekanan Ethereum, tetapi pada akhirnya kami masih meminta validator Ethereum untuk melakukan beberapa pekerjaan yang diturunkan ke L2. Jadi banyak orang berbicara tentang bagaimana kita bisa melakukan ini.
Kemudian kami berbincang dengan Barnabe, seorang peneliti di Ethereum Foundation yang saat ini sedang mengerjakan PBS. Ini adalah proposal Ethereum, yaitu membagi tugas validator menjadi beberapa peran, pembangun, dan pengusul. Sekarang kami memiliki Flashbots untuk berperan sebagai pembangun di PBS, mereka menyusun semua blok dan mengirimkannya ke pengusul Ethereum. Jadi begitu blok-blok ini dikemas ke dalam jaringan Ethereum, pembangun juga akan mendapatkan beberapa hadiah. Lalu dalam hal ini, bagaimana cara memberi penghargaan kepada validator ini dari jaringan Ethereum? Mereka juga bertanggung jawab atas validasi rollup.
Salah satu solusinya adalah "restaking", yang mungkin sudah sering Anda dengar dari EigenLayer atau beberapa protokol lainnya. Pengguna dapat mempertaruhkan kembali ETH di jaringan penyortiran lainnya. Atau hadiahi validator Ethereum karena benar-benar menjalankan perangkat lunak untuk melakukan pekerjaan validasi untuk rollup. Dalam hal ini, mereka dapat diberi hadiah baik dari L2 maupun melalui protokol staking ulang. Ada banyak proposal sejauh ini, tetapi secara umum ini adalah ide tentang bagaimana dapat menggunakan kembali validator Ethereum yang ada. Bagaimana kami dapat menggunakan kembali ETH yang ada untuk membantu mengantarkan era baru sistem rollup atau L2? Jadi pada dasarnya mencoba menyederhanakan banyak hal untuk proyek rollup. Jika rollup menginginkan penyortir baru, jika mereka menginginkan sumber agunan baru, mereka dapat menggunakan kembali infrastruktur yang ada atau agunan yang ada. Jadi itulah mengapa itu dibangun di atas Ethereum, dan kemudian infrastruktur dan staking lebih lanjut dapat digunakan kembali untuk rollup dan L2 juga.
Kerugian dari sequencer bersama dan rollup berbasis, serta skenario aplikasinya.
Pilihan
Saya ingin mengeluh tentang proposal ini, saya tidak yakin dengan proposal yang terkait dengan sequencer bersama. Tentu saja, mereka masih dalam masa pertumbuhan, dan jika desain ini meningkat di masa mendatang, sangat mungkin saya akan mendukung mereka. Hanya saja bentuk saat ini tidak meyakinkan saya. Ada banyak alasan.
Pertama, bagi saya, proposisi nilai utama dari penyortir bersama adalah untuk memungkinkan pengguna mendapatkan komposisi atom antara rollup tujuan umum seperti Scroll atau Starknet. Namun masalahnya adalah jika Anda memiliki kemampuan menyusun atom, maka rollup Anda sama finalnya dengan rollup paling lambat yang Anda gabungkan. Jadi, dengan asumsi Scroll digabungkan dengan Optimistic Rollup, finality Scroll adalah tujuh hari. Sementara proposisi nilai utama ZKRollup adalah untuk mencapai penyelesaian yang relatif cepat, pengguna dapat menarik diri ke L1 dalam hitungan menit. Dan dalam hal ini, pada dasarnya menyerah pada itu.
Kelemahan lainnya adalah jika Anda menginginkan finalitas off-chain, Anda perlu menjalankan node L2, dan selama data yang dikirimkan ke rantai diselesaikan oleh L1, Anda mendapatkan finalitas secara lokal di L2. Jika setiap gabungan L2 tidak menjalankan simpul penuh, secara praktis tidak mungkin mencapai finalisasi lokal. Ini berarti menjalankan sistem ini bisa lebih mahal daripada menjalankan sistem seperti Solana, karena Anda memiliki banyak node penuh yang berjalan pada saat yang sama, dengan overhead mereka sendiri dan seterusnya.
Jadi untuk alasan itu, menurut saya L2 tidak masuk akal. Ini sedikit berbeda untuk L3, karena jika seseorang ingin membangun rantai khusus aplikasi dan tidak ingin berurusan dengan desentralisasi. Katakanlah saya sedang membuat game dan saya hanya ingin berurusan dengan pembuatan game tersebut, lalu saya dapat mengalihdayakan pekerjaan yang terdesentralisasi. Tapi saya rasa itu tidak masuk akal untuk L2 saat ini.
Untuk rollup berbasis, saya juga memiliki kekhawatiran. Misalnya, bagaimana Anda membagi keuntungan MEV dengan pembukti? Karena jika masalah alokasi tidak diperhatikan, pada dasarnya L1 dapat memperoleh semua keuntungan MEV. Hal kecil lainnya adalah waktu konfirmasinya sama dengan waktu konfirmasi L1 yaitu 12 menit, tidak bisa lebih cepat. Masalah lainnya adalah karena tidak memiliki izin, banyak Pencari dapat mengirimkan kumpulan transaksi pada saat yang sama, yang berarti hasil akhir mungkin terpusat. Karena pembangun diberi insentif untuk memasukkan transaksi mereka jika satu penelusur terhubung lebih mudah daripada yang lain. Oleh karena itu, pada akhirnya hanya satu Seeker yang mengusulkan batch untuk L2, yang pada akhirnya bukanlah solusi yang baik, karena jika ini terjadi, pada dasarnya kita kembali ke titik awal.
Yaoqi
Menariknya, saya baru saja menelepon Ben, pendiri Espresso, sebenarnya minggu lalu. Kami banyak membahas ini dalam topik penyortir bersama. Seperti yang disebutkan Toghrul, menurut saya ada beberapa ketidakpastian tentang skenario penggunaan untuk sistem pemesanan bersama. Ini terutama karena untuk L2 tujuan umum, kami biasanya tidak memiliki banyak penyortir karena efisiensi, kerumitan, dan ekonomi. Dan saya masih merasa bahwa apakah itu untuk sequencer bersama, rollup berbasis, atau pengambilan ulang, kasus penggunaan terbaik sebagian besar adalah untuk RAS (Rollup as a Service) atau platform semacam itu di mana kami dapat meluncurkan banyak rollup. Sejujurnya kami tidak terlalu membutuhkan jaringan penyortiran yang besar jika tidak banyak rollup. Rollup ini sudah memiliki sistem penyortirnya sendiri, dan sudah memiliki komunitas atau mitranya sendiri, ketika hanya ada beberapa L2 generik. Mereka tidak benar-benar perlu memiliki jaringan pihak ketiga yang terpisah. Juga, ini menjadi beban pada jaringan pihak ketiga, karena Anda harus menyesuaikan untuk setiap L2, dan setiap L2 memiliki test stack yang berbeda. Ini membutuhkan banyak perubahan pada jaringan Anda sendiri.
Tetapi pada saat yang sama, seperti yang disebutkan Toghrul, untuk beberapa kasus penggunaan khusus. Misalnya, jika kita ingin memiliki beberapa interoperabilitas di tingkat penyortir, penyortir bersama bisa menjadi cara yang potensial. Misalnya, penyortir yang sama digunakan untuk beberapa pembatalan. Dalam hal ini, penyortir ini pada dasarnya dapat menangani beberapa transaksi lintas rollup untuk memastikan atomisitas lintas rantai antara rollup A, B, dan C.
Tapi Anda juga bisa melihat masalahnya di sini saat saya menjelaskan situasinya. Jika kami benar-benar memiliki banyak dari sequencer bersama ini, mereka akan kembali menjadi hambatan dan satu titik kegagalan baru. Kami memberikan terlalu banyak kekuatan kepada apa yang disebut pemesan bersama ini. Mereka menjadi lebih seperti jaringan, mengendalikan banyak rollup. Terakhir, sekali lagi kami perlu menemukan cara untuk mendesentralisasikan penyortir bersama ini.
Tapi bagaimanapun, saya pikir itu hal yang baik bahwa orang-orang secara bertahap menemukan lebih banyak masalah dan menghasilkan lebih banyak solusi. Secara keseluruhan, menarik untuk melihat apa yang baru di bidang ini setiap hari. Dengan semua solusi baru ini, setidaknya kami berada di jalur yang benar untuk benar-benar mendesentralisasikan seluruh ruang rollup.
Abdel
Ya, saya setuju dengan Anda berdua. Saya pikir itu lebih masuk akal untuk Layer3 dan Lisk karena mereka tidak ingin mengambil tanggung jawab untuk memberi insentif pada jaringan yang terdesentralisasi lagi dan perlu mencari mitra untuk memulai hal-hal seperti penyortir. Jadi saya pikir untuk Lisk, itu masuk akal. Tapi seperti Toghrul, menurut saya itu belum masuk akal untuk Layer2 dulu.
Topik 4
Apa dampak pemesan terdesentralisasi terhadap MEV?
Abdel
Untuk Starknet, dalam konteks sentralisasi, kami tidak melakukan jenis MEV apa pun, dan kami mengadopsi model siapa cepat dia dapat. Artinya, dalam konteks desentralisasi, tentu akan lebih banyak MEV yang dibawa nantinya. Namun terlalu dini untuk mengatakan rasio yang mana, karena juga tergantung pada rancangan mekanisme konsensus dan aspek lainnya.
Pilihan
Tapi masalahnya, meskipun Anda tidak melakukan MEV, mungkin masih ada beberapa MEV yang terjadi di Starknet. Desentralisasi dengan sendirinya tidak benar-benar menurunkan MEV atau meningkatkan MEV. Tentu saja, jika Anda menerapkan semacam protokol pemesanan yang adil atau enkripsi ambang batas, misalnya, ya, Anda meminimalkan MEV. Tapi Anda tidak bisa sepenuhnya menghilangkannya. Filosofi saya adalah: MEV tidak bisa dihilangkan. Tapi katakanlah Anda hanya membuat konsensus BFT, atau membangun sesuatu di atas konsensus BFT. Ini sebenarnya tidak mempengaruhi MEV sama sekali. MEV masih ada, harus menjadi pertanyaan tentang bagaimana pencari bekerja dengan penyortir untuk mengekstrak MEV itu.
Yaoqi
Masalahnya adalah, bahkan model yang pertama datang, yang pertama dilayani memiliki bagian yang rumit. Setelah kami mengekspos mempool ke beberapa pencari, mereka masih memiliki keuntungan untuk bermain lebih banyak. Misalnya, untuk pengurut, mereka setara dengan menunggu di depan pintu kantor Anda. Jadi dalam hal ini, begitu mereka melihat semacam peluang arbitrase, bukan hanya tentang front-running atau serangan sandwich, segera setelah pengguna mengirimkan transaksi, mereka dapat langsung melihatnya di mempool. Jadi, mereka dapat dengan cepat menempatkan perdagangan mereka di depan orang lain. Jadi, mereka memiliki keunggulan dibandingkan pencari lainnya.
Tapi kembali ke desentralisasi, saya pikir ini sebagian besar tentang penolakan sensor, seperti yang kita bahas di awal. Sequencer dikelola oleh tim. Tim dapat mengatakan bahwa mereka bersikap adil kepada semua orang. Tapi ini tidak dicegah dalam kode. Jadi, jika kita dapat memiliki jaringan P2P, alangkah baiknya jika kita merasa node ini memeriksa transaksi saya dan kemudian kita dapat mengirimkannya ke node lain. Jadi, ini benar-benar tentang keadilan pemrosesan transaksi di L2.
Adapun MEV, karena baru-baru ini, selain MEV yang dihasilkan dalam satu rollup, ada beberapa MEV yang dihasilkan melintasi jembatan. Dalam jaringan penyortiran yang relatif terdesentralisasi ini, Anda akan memiliki lebih banyak kesempatan untuk mengekstraksi MEV. Dengan asumsi kita memiliki jaringan pemesanan bersama, jika Anda entah bagaimana dapat memengaruhi pemesan bersama untuk memesan ulang transaksi, pada dasarnya Anda memiliki keuntungan besar dibandingkan orang lain.
Ada keuntungan dan kerugian dari jaringan sequencer bersama. Di sisi positifnya, kita dapat mendesentralisasikan sistem ranker lebih lanjut. Namun di sisi lain, setiap orang memiliki kesempatan untuk menjadi seorang penyortir. Jadi, pada dasarnya mereka dapat melakukan apapun yang mereka inginkan, dan itu adalah hutan yang gelap lagi. Jadi, kami memperkenalkan desentralisasi, dan kemudian kami harus menghadapi masalah serupa yang kami hadapi di Ethereum. Itu sebabnya Flashbots dan orang-orang Ethereum Foundation ingin bergerak maju dengan PBS, memisahkan pengusul dan pembangun, dan kemudian mencoba untuk memiliki satu solusi di sisi pembangun.
Jadi kalau kita lihat masalahnya, bukan hanya satu masalah. Ini bukan lagi masalah satu lawan satu, tapi satu lawan enam, dan banyak lagi.
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.
Dialog dengan tim AltLayer, Scroll, Starknet: Shared Sequencer dan Konsensus L2
Perkenalan
Ketika kita melihat visi dan peta jalan dari berbagai solusi rollup, kita akan menemukan bahwa hampir semua rollup memiliki tujuan akhir Jika tujuan ini diringkas menjadi satu kalimat: membangun tumpukan teknologi, memberikannya kepada komunitas, memecahkan Perluasan blockchain, dan pada akhirnya desentralisasi tumpukan teknologi operasi dan tata kelola. Ini mengarah pada istilah rollup terdesentralisasi.
Jadi apa sebenarnya desentralisasi itu? Apa pembagian kerja antara berbagai bagian sistem Rollup? Apakah desentralisasi berarti memaksimalkan peserta operasi sistem? Apa dampak yang akan ditimbulkan oleh penyortir terpusat? Bagaimana seharusnya pemesan bersama dan konsensus lokal L2 dirancang? Apa fungsi dari pembukti unik di ZK-Rollup? Seperti apa tampilan jaringan pembukti terdesentralisasi terbuka? Mengapa kita membutuhkan akselerasi perangkat keras zk? Apa solusi untuk masalah ketersediaan data? ....
Ada diskusi tanpa henti seputar Rollup terdesentralisasi di komunitas, jadi ECN menyusun serangkaian wawancara podcast dengan tema "Rollup Terdesentralisasi", dan mengundang pendiri dan peneliti terkemuka di bidang ini untuk membicarakan pemahaman mereka tentang Rollup terdesentralisasi.
Karena semakin banyak likuiditas mengalir ke platform Layer 2, semakin banyak penyedia layanan rollup muncul, tidak hanya solusi rollup tujuan umum, rantai rollup khusus aplikasi, tetapi juga platform rollup sebagai layanan. Oleh karena itu, semakin banyak orang yang khawatir bahwa peran "sequencer" yang sangat kritis di hampir semua rollup masih terpusat. Apa risiko dari penyortir terpusat? Apakah penyortir yang terdesentralisasi merupakan pekerjaan yang mendesak?
**Di episode kedua, kami mengundang Yaoqi Jia, pendiri AltLayer Network, Toghrul Maharramov, peneliti Scroll, dan Abdelhamid Bakhta, Starknet Exploration Lead, untuk melakukan diskusi meja bundar tentang topik penyortir terdesentralisasi, sehingga penonton dan pembaca dapat memahami saat ini Beberapa kemajuan dan dilema penyortir desentralisasi. **
Tamu dalam edisi ini:
Masa lalu
Masalah 1: Bagaimana cara mendesentralisasikan Rollup?
Pratinjau
Masalah 3: Buktikan akselerasi jaringan dan perangkat keras zk
Masalah 4: Ketersediaan Data dan Penyimpanan Terdesentralisasi
Mendengarkan
Klik untuk berlangganan podcast untuk mempelajari lebih lanjut:
Youtube:
Mikrokosmos:
stempel waktu
00:49 Yaoqi memperkenalkan dirinya
01:37 Abdelhamid memperkenalkan dirinya
02:50 Toghrul memperkenalkan dirinya
04:03 Peran penyortir dalam rollup
08:37 Pemesan terdesentralisasi: Meningkatkan pengalaman pengguna dan mengatasi masalah keaktifan dan penyensoran
19:43 Bagaimana Starknet akan mendesentralisasikan penyortir
22:59 Bagaimana Scroll akan mendesentralisasikan penyortir
26:34 Perbedaan antara konsensus L2 dalam konteks Optimistic rollup dan zkRollup
32:28 zkRollup mendesentralisasikan penyortir dan juga perlu mempertimbangkan pembukti
36:01 Apa itu rollup berbasis?
40:53 Kerugian dari sequencer bersama dan rollup berbasis, serta skenario aplikasinya
49:02 Apa pengaruh pemesan terdesentralisasi terhadap MEV?
Perkenalan tamu
Yaoqi
Saya adalah pendiri AltLayer. AltLayer sedang membangun platform "Rollup as a Service" di mana pengembang cukup mengklik beberapa tombol dan mengonfigurasi parameter. Dengan menggunakan launchpad atau panel kontrol kami, mereka dapat dengan cepat meluncurkan rollup khusus aplikasi dalam hitungan menit. Jadi itulah yang kami coba lakukan sekarang, untuk menyediakan lingkungan eksekusi dan fungsionalitas umum bagi pengembang. Kami juga menyediakan beberapa sequencer, beberapa sistem mesin virtual, dan berbagai sistem pembuktian untuk dipilih oleh pengembang.
Abdelhamid
Saya bekerja di Starkware dan saya adalah pemimpin tim eksplorasi. Tujuan grup ini pada dasarnya adalah untuk meluncurkan proyek sumber terbuka yang mirip penelitian tetapi dengan fokus teknik. Tujuan kami adalah mengerjakan proyek sumber terbuka dengan kolaborasi erat dengan komunitas dan orang-orang dari ekosistem lain. Salah satu proyek tersebut adalah Madara, yang sebenarnya adalah penyortir Starknet. Ini bukan hanya kandidat untuk jaringan publik Starknet, tetapi juga sequencer untuk rantai aplikasi Starknet dan Layer3. Ini juga terkait dengan apa yang dikatakan tamu sebelumnya, kami juga berpikir untuk menyediakan rollup sebagai fungsi layanan, orang dapat meluncurkan rantai aplikasi Starknet mereka dan memilih solusi ketersediaan data yang berbeda dengan cara yang agak modular. Sebelumnya, saya bekerja sebagai pengembang inti Ethereum selama empat tahun, terutama bertanggung jawab atas pekerjaan EIP-1559.
Pilihan
Saya seorang peneliti di Scroll, dan tanggung jawab utama saya di Scroll adalah desain protokol, desain jembatan, desentralisasi, insentif, hal semacam itu. Jadi saat saya tidak berkicau, sebagian besar waktu saya hanya mengerjakan cara mendesentralisasikan protokol atau pemesan, pembukti, hal-hal seperti itu. Seperti Starkware, salah satu hal yang sedang kami kerjakan adalah rollup SDK. Dengan demikian, Anda dapat mengeluarkan rollup berdasarkan Gulir, dan secara modular menggunakan opsi ketersediaan data yang berbeda dan seterusnya. Kami masih mempertimbangkan opsi bahwa rollup berdasarkan Scroll SDK dapat menggunakan penyortir Scroll untuk membantu mereka mencapai desentralisasi tanpa mengharuskan setiap rollup menangani desentralisasi dengan sendirinya. Tentu saja, rencana tersebut belum selesai. Namun, ini juga arah yang sedang kami kerjakan.
bagian Wawancara
topik satu
Jelaskan penyortir rollup?
Abdelhamid
Penyortir adalah komponen yang sangat penting dalam arsitektur layer2, komponen ini menerima transaksi dari pengguna, kemudian mengemas dan membundelnya menjadi blok, mengeksekusi transaksi, dan seterusnya. Ini sangat penting karena ini adalah komponen yang bertanggung jawab untuk membuat blok, karena layer2 juga merupakan blockchain dengan blok transaksi. Pemesan membuat blok ini, dan pembukti membuktikan blok ini.
Yaoqi
Seperti yang disebutkan Abdel, pemesan adalah kombinasi dari banyak fungsi di blockchain. Jadi kami mungkin benar-benar memberi pemesan terlalu banyak tanggung jawab sekarang dibandingkan dengan blockchain publik pada umumnya. Pertama-tama perlu menggabungkan semua transaksi dari pengguna, dan kemudian mengurutkan transaksi tersebut, baik berdasarkan harga bahan bakar atau berdasarkan siapa cepat dia dapat. Setelah itu, sequencer perlu mengeksekusi transaksi ini. Seperti sekarang, beberapa Layer2 menggunakan EVM (Starware memiliki mesin virtual yang berbeda), tetapi pada dasarnya sequencer perlu menggunakan mesin virtual khusus untuk menjalankan transaksi dan menghasilkan status. Kemudian transaksi mencapai tahap pra-konfirmasi, yang berarti bahwa jika Anda melihat waktu konfirmasi satu atau dua detik, atau bahkan sub-detik, itu pada dasarnya adalah status pra-konfirmasi yang diselesaikan oleh sequencer. Kemudian, untuk sebagian besar penyortir, mereka juga perlu mengunggah atau menerbitkan pos pemeriksaan atau menyatakan hash ke L1. Ini adalah konfirmasi di tingkat L1, yang kami sebut ketersediaan data. Jadi penyortir sebenarnya memiliki banyak peran dalam sistem rollup. Namun secara umum, menurut saya ini adalah komponen paling kritis dari sistem rollup.
** Topik 2 **
Mengapa penyortir terdesentralisasi penting? Jika kita menggunakan penyortir terpusat, apa bahaya tersembunyi bagi pengguna dan sistem?
Pilihan
Pertama-tama, perlu kita ketahui bahwa kecuali untuk Bahan Bakar V1 pada tahap saat ini, tidak ada rollup yang sebenarnya, karena rollup lainnya masih memiliki roda latihan.
Namun, kita dapat mengatakan bahwa setelah diklasifikasikan sebagai rollup, itu berarti multi-sig dihapus dan seterusnya. Kemudian masalah desentralisasi penyortir menjadi masalah pengalaman pengguna, bukan masalah keamanan. Jadi ketika orang berbicara tentang, katakanlah, desentralisasi L1, masalahnya sangat berbeda. Karena L1 harus memberikan jaminan untuk pemesanan dan klien ringan. Jadi jika klien ringan ingin memverifikasi bahwa status sudah benar, ia harus mempercayai validator L1. Untuk rollup, ini bukan masalahnya. Karena penyortir hanya menyediakan penyortiran sementara, yang kemudian diselesaikan oleh L1. Dan, karena rollup juga dijamin tahan sensor, kami tidak memerlukan desentralisasi untuk mewujudkannya.
Jadi, ada beberapa alasan mengapa Anda memerlukan penyortir terdesentralisasi. Pertama, jika finalisasi L1 dikatakan lambat (baik karena bukti validitas yang Anda kirimkan terlalu lambat, atau karena mekanisme periode tantangan dari bukti penipuan rollup yang optimis), Anda harus mengandalkan sesuatu untuk mencapai konfirmasi transaksi yang cepat. Pada tahap konfirmasi cepat ini, meskipun Anda dapat percaya bahwa Starkware atau Scroll tidak akan menipu Anda, mereka menunjukkan bahwa setelah pemblokiran dikonfirmasi, tidak akan ada pengaturan ulang. Ini adalah asumsi kepercayaan. Dan desentralisasi dapat menambah beberapa jaminan ekonomi, dan seterusnya.
Namun berdasarkan ini, rollup juga tidak memiliki jaminan finalitas real-time. Pada dasarnya, Anda dapat memaksakan pengemasan transaksi melalui L1, tetapi perlu waktu berjam-jam untuk mengemas transaksi tersebut. Jadi misalnya, jika ada oracle yang bertanggung jawab untuk memperbarui dan waktunya berfluktuasi, maka pada dasarnya jika oracle diperbarui selama satu jam atau lebih, aplikasi dalam rollup tidak akan tersedia. Pada dasarnya, desentralisasi memungkinkan kita untuk memberikan beberapa jaminan tahan sensor real-time yang lebih kuat, karena musuh perlu berkompromi bukan hanya satu entitas atau segelintir entitas, tetapi seluruh jaringan pemesan.
Jadi bagi kami, desentralisasi lebih merupakan solusi untuk meningkatkan pengalaman pengguna atau memperbaiki masalah pembaruan oracle, dan sebagainya. Alih-alih memberikan jaminan keamanan dasar, inilah yang dilakukan L1.
Abdelhamid
Ya, pertanyaan tentang penyortir terdesentralisasi yang Anda sebutkan tidak persis sama dengan L1 terdesentralisasi, yang menurut saya sangat penting. Karena ketika kita melihat beberapa L1 mengkritik penyortir terpusat, mereka tidak benar melihat trade-off yang dibuat oleh penyortir terpusat.
Atas dasar ini, saya ingin menambahkan sesuatu yang berkaitan dengan pengalaman pengguna, terkait dengan aktivitas. Karena jika Anda hanya memiliki satu penyortir, Anda berisiko lebih besar mengalami gangguan penyortir. Oleh karena itu, pemesan yang terdesentralisasi juga meningkatkan ketahanan dan keaktifan di jaringan. Tetapi bahkan dalam konteks terpusat, kami memiliki keamanan yang baik dalam hal keamanan. Karena ketika Anda bisa memaksa transaksi paket melalui L1, perbedaan keduanya hanyalah timeline. Dan memiliki penyortir terdesentralisasi memungkinkan Anda memiliki jaminan tahan sensor yang cepat, seperti yang disebutkan Toghrul. Jadi, saya hanya ingin menambahkan bahwa penting juga bagi liveness untuk memiliki jaringan pemesan yang terdesentralisasi.
Yaoqi
Saya ingin menambahkan sesuatu. Aktivitas mungkin adalah hal terpenting yang perlu kita pertimbangkan pada tahap ini. Kasus airdrop terbaru pada L2 paling populer, seperti Optimism dan Arbitrum, mengalami periode downtime. Oleh karena itu, menurut saya yang perlu kita selesaikan adalah bagaimana menangani ribuan permintaan transaksi per detik ketika kita hanya memiliki satu penyortir. Bahkan secara teori, jika Anda hanya memiliki satu node, itu tidak dapat benar-benar menangani begitu banyak permintaan pada saat yang bersamaan. Jadi, mengenai keaktifan, kita pasti membutuhkan banyak penyortir. Satu titik kegagalan adalah kendala nyata, tidak hanya untuk Web3, bahkan Web2 adalah masalah besar.
Di luar itu, ada masalah sensor. Jika kami hanya memiliki satu koordinator, meskipun kami melihat itu dapat dijalankan oleh tim, Anda masih perlu membuktikan bahwa tim tersebut tidak akan benar-benar meninjau transaksi. Kadang-kadang dimungkinkan dan mampu bagi pihak jahat untuk memasukkan transaksi tertentu ke dalam daftar hitam. Itu adalah sistem pemesan yang terdesentralisasi, mereka juga dapat mencoba mengirim transaksi melalui pemesan lain. Jadi itu sebabnya kami mendapat banyak kritik seputar penyortir tunggal akhir-akhir ini.
Di luar itu, ada beberapa masalah lain seperti MEV dan early run. Dalam sistem dengan penyortir terpusat, terutama untuk protokol DeFi, mereka mungkin dapat memeriksa mempool dengan mudah. Mungkin tidak dalam bentuk pelopor, tetapi mereka memiliki peluang yang lebih baik untuk mengikuti perdagangan dan menengahinya.
Banyak sekali masalah ini, dengan berbagai alasan, padahal kita lihat L2 sangat berbeda dengan L1. Namun pada akhirnya, kita masih perlu membuatnya sedesentralisasi mungkin. Jadi kami harus menghadapi beberapa masalah serupa yang kami miliki dengan blockchain publik atau L1.
Abdelhamid
Ya, saya setuju bahwa penyortir terdesentralisasi itu penting. Tetapi saya juga ingin mengatakan bahwa, seperti yang kita semua tahu, ini bukanlah pertanyaan yang mudah.
Juga, **karena rollup memiliki arsitektur yang sangat spesifik, dengan banyak entitas. Ada satu pemesan yang sedang kita bicarakan, tetapi ada juga pembukti, dan kita perlu mendesentralisasikan keduanya. **Akan ada beberapa trade-off dan beberapa kesulitan dalam menentukan harga transaksi karena berbagai faktor diperlukan untuk menjalankan jaringan. Jadi, bagaimana Anda memberi harga pada kesepakatan itu? Penyortir dan pembukti memiliki persyaratan perangkat keras yang berbeda, pembukti membutuhkan mesin yang sangat kuat, dan seterusnya. Oleh karena itu, transaksi penetapan harga di dunia yang terdesentralisasi juga merupakan masalah yang sangat sulit, oleh karena itu kita perlu waktu untuk bergerak maju secara perlahan.
Jadi kita semua akan menghadapi trade-off seperti itu Jika kita ingin desentralisasi dengan cepat, kita mungkin perlu mengambil beberapa roda pelatihan dan desentralisasi secara bertahap, karena jika kita menginginkan arsitektur yang sempurna secara langsung, itu akan memakan waktu beberapa tahun. Jadi saya pikir kami akan mengambil pendekatan pragmatis dan mencoba melakukan desentralisasi secara bertahap. Setidaknya itulah rencana kami saat ini, seperti mungkin memulai dengan mekanisme konsensus BFT sederhana dan kemudian menambahkan mekanisme konsensus lain dalam jangka pendek atau semacamnya. Jadi saya hanya ingin mengatakan, itu bukan pertanyaan yang mudah. Karena jelas ada trade-off antara kecepatan pengembangan dan seberapa dapat diterapkan arsitektur pada lingkungan yang terdesentralisasi.
Topik 3
Bagaimana cara mendesentralisasikan penyortir?
Abdelhamid
Ada banyak fitur yang ingin kami desentralisasikan, dan semuanya memiliki pengorbanan yang berbeda.
Misalnya, saat melakukan desentralisasi, Anda ingin memperkenalkan semacam mekanisme konsensus. Namun, dalam mekanisme konsensus, ada beberapa bagian. Yang pertama adalah pemilihan pemimpin, yaitu bagaimana memilih siapa yang akan membuat blok, siapa yang akan menjadi pemesan yang bertanggung jawab untuk membuat blok di slot tertentu atau dalam waktu tertentu. ** Apa yang direncanakan tim Starknet adalah memanfaatkan layer1 sebanyak mungkin. Artinya, dalam algoritme pemilihan pemimpin kami, kami ingin mempertaruhkan layer1. Misalnya, kami memiliki token, dan janji akan dilakukan pada kontrak pintar Ethereum layer1, yang digunakan untuk menentukan mekanisme pemilihan pemimpin. **Ini berarti kita perlu melakukan interaksi di mana pemesan L2 akan meminta kontrak cerdas Ethereum untuk mengetahui siapa yang akan menjadi pemimpin berikutnya atau semacamnya. Jadi jelas diperlukan semacam keacakan dan hal-hal lain. Jadi itu bukan pertanyaan sederhana. Tapi itu bagian pertama. Maka Anda perlu memiliki mekanisme untuk konsensus itu sendiri. Ada beberapa opsi: mekanisme rantai terpanjang atau BFT, atau gabungan keduanya. Seperti Ethereum, ia memiliki LMG Ghost dan Casper FFG untuk finalitas.
Jadi kita mungkin mengambil pendekatan pragmatis dan mulai dengan BFT terlebih dahulu. Mengapa? Ketika layer2 mempertimbangkan desentralisasi, tujuan kami bukanlah memiliki skala penyortir sebesar layer1. Misalnya, di Ethereum, tujuannya adalah agar jutaan validator berpartisipasi. Dalam hal ini, Anda tidak bisa begitu saja menggunakan mekanisme BFT, karena akan sangat buruk efisiensinya, dan akan menimbulkan masalah yang sangat besar. Misalnya, jika ada masalah pada jaringan Bitcoin, jika itu adalah mekanisme BFT, rantai akan berhenti total. Namun tidak demikian, jaringan Bitcoin terus membuat blok, hanya mekanisme finalitas yang diserang.
Tapi di layer2, jika targetnya adalah beberapa ratus hingga 1000 sorter, mungkin bagus untuk memulai dengan mekanisme BFT. Jadi, kita punya mekanisme pemilihan pemimpin, kemudian konsensus, dan kemudian ada dua bagian lainnya, tetapi saya akan membiarkan tamu lain terus menambahkan. Tetapi dua bagian lainnya adalah pembaruan status dan pembuatan bukti.
Pilihan
Pertama, di L2, desentralisasi merupakan masalah multifaset, seperti yang dijelaskan oleh Abdel. Terutama di zkRollup, karena ada pembukti dan pemesan, Anda harus berkoordinasi di antara mereka, Anda harus mendesentralisasikan keduanya. Masalah ini sama sekali berbeda dari L1.
Perbedaan lainnya adalah bahwa di L2, semua desain Anda adalah untuk meyakinkan jembatan yang mendasarinya bahwa konsensusnya benar, bukan untuk meyakinkan sejumlah node lain. Anda jelas harus melakukan hal yang sama, tetapi fokus utama Anda harus menjadi jembatan itu sendiri.
Saat ini, kami bekerja dalam dua arah yang berbeda. Nomor satu, saya pikir, seperti orang lain, kami sedang mengerjakan protokol BFT. Ini tidak terlalu efisien dan ada beberapa kekusutan yang perlu diselesaikan. Kami datang dengan solusi kasar, tapi masih belum optimal. Misalnya, salah satu pertanyaannya adalah, bagaimana Anda menyeimbangkan insentif antara pemilah dan pembukti? Karena pemesan mengontrol MEV, dan pembukti tidak memiliki akses ke MEV, ada insentif bagi orang untuk menjalankan pemesan alih-alih pembukti. Namun pada kenyataannya, kami membutuhkan lebih banyak pemberi bukti daripada pemesan, jadi bagaimana Anda menyeimbangkan insentif di antara keduanya? Ini adalah salah satu masalah itu.
Solusi kedua yang sedang kami kerjakan adalah arah lain. Ingat, banyak hal bisa berubah. Proposal baru keluar setiap hari. Misalnya, ada banyak pembicaraan akhir-akhir ini tentang rollup berbasis dan bagaimana Anda dapat mengalihdayakan pengurutan sepenuhnya ke L1. Arah kedua pada dasarnya membuang penyortir seluruhnya dan menggunakan beberapa pembangun eksternal. Misalnya, pembuat ethereum atau Flashbots SUAVE dll. mengusulkan blok yang dipesan dan kemudian menjalankan konsensus di dalam pembukti. Keuntungannya di sini adalah Anda tidak perlu berurusan dengan insentif karena pada dasarnya Anda dapat menggunakan PBS di dalam protokol dan ini membuat protokol yang lebih sederhana. Tetapi kerugiannya adalah karena kita membutuhkan banyak pembukti (karena kita dapat membuktikan secara paralel), cukup sulit untuk menjalankan protokol BFT klasik dengan mereka. Jadi pertanyaannya adalah bagaimana Anda mengoptimalkan protokol BFT yang ada untuk dijalankan dengan ratusan, atau bahkan ribuan, dari pembukti? Dan itu bukan pertanyaan yang mudah untuk dijawab.
Apakah memperkenalkan konsensus L2 diperlukan untuk pemesan yang terdesentralisasi?
Yaoqi
Secara kasar saya dapat menjawab pertanyaan ini karena kami baru saja meluncurkan sesuatu seperti itu.
Jadi apakah akan memperkenalkan konsensus tidak tergantung pada apakah kita menginginkannya atau tidak. Setelah Anda memiliki banyak pemesan atau bahkan hanya node, Anda harus membuat mereka setuju. Itu sangat tergantung pada asumsi Anda. Jika asumsi Bizantium, kita dapat menggunakan BFT atau protokol konsensus Bizantium yang ada. Jika itu adalah pengaturan non-Bizantium, misalnya, jika kita hanya berasumsi bahwa sebuah node hanya bisa online dan offline, dan tidak dapat bertindak jahat, maka kita dapat menggunakan protokol Raft atau protokol konsensus lain yang lebih cepat. Tapi bagaimanapun, jika kita memiliki grup pemesan atau pembukti, jika kita ingin mengatur mereka bersama untuk menghasilkan blok selama periode waktu tertentu, maka Anda harus memiliki protokol konsensus di sekitar mereka.
Jadi, seperti yang baru saja Toghrul dan Abdel sebutkan, saya yakin ada banyak proposal dan topik penelitian tentang bagaimana kita dapat menerapkan sistem pemesanan atau pembuktian yang terdesentralisasi. Jadi, karena kami baru saja meluncurkan testnet untuk sistem rollup multi-penyortir (saat ini hanya mendukung bukti penipuan untuk rollup Optimis), berdasarkan pengalaman desain dan implementasi kami, ada beberapa hal yang dapat saya bagikan tentang kesulitannya. Seperti yang Toghrul sebutkan tadi, kesulitannya bukan terletak pada protokol konsensus itu sendiri, kesulitan sebenarnya terletak pada hal-hal selain itu, seperti bagian pembuktian. Karena jika itu penyortir tunggal, Anda tidak memerlukan banyak node. Kita bisa menganggapnya sebagai EVM, mesin virtual. Jadi, ambil saja transaksi dan jalankan, lakukan transisi status. Pembukti bertanggung jawab untuk menghasilkan bukti untuk transisi status dari rangkaian transaksi sebelumnya. Namun, jika kita menjalankan protokol konsensus untuk collator dan pembukti pada rollup, maka kita perlu memasukkan logika konsensus tambahan di sana. Selain itu, Anda juga memerlukan sistem bukti untuk protokol konsensus. Oleh karena itu, ini akan memperkenalkan banyak pekerjaan untuk menghasilkan sistem pembuktian. Kemudian setelah Anda menghasilkan buktinya, Anda dapat dengan mudah memverifikasinya di L1 Ethereum.
Jadi itulah mengapa, ketika kami meluncurkan testnet multi-pemesan pertama, optimis rollup memiliki beberapa keuntungan dalam hal itu. Secara umum, Anda dapat menyederhanakan banyak hal, seperti tidak mempertimbangkan bagian bukti validitas. Seperti kami, pada dasarnya kami membandingkan semuanya dengan WASM. Jadi pada akhirnya itu adalah instruksi WASM. Jadi, dengan memverifikasi instruksi WASM ini, relatif mudah untuk memverifikasi menggunakan kode Solidity. Jika kami baru saja mengimplementasikan ulang semua interpretasi instruksi WASM di Ethereum.
Namun secara umum, masalahnya tidak tunggal. Jika kami memiliki solusi untuk masalah tersebut, maka akan ada beberapa pekerjaan lanjutan lainnya yang perlu diselesaikan pada saat yang bersamaan. Tentu akan ada masalah MEV, seperti bagaimana kita mendistribusikan MEV secara adil. Anda dapat menetapkan semua pemesan dan pembukti berdasarkan apakah mereka menghasilkan blok atau memvalidasi blok. Namun pada akhirnya, ini benar-benar merupakan kombinasi dari banyak masalah, bukan hanya masalah teknis, tetapi juga insentif ekonomi.
Dan perlu diingat bahwa L2 diusulkan karena kami ingin mengurangi biaya gas secara signifikan. Jadi kita tidak bisa memiliki begitu banyak node. Bahkan dalam menghasilkan bukti, L2 mungkin lebih mahal dari L1. Jadi kita benar-benar perlu menemukan pendekatan yang seimbang untuk masalah seperti ini.
Abdelhamid
Saya ingin menambahkan satu poin lagi. Pertama, saat ini tidak ada bukti penipuan tanpa izin yang sebenarnya untuk rollup optimis. Dan saya terus menekankan hal ini setiap ada kesempatan, karena penting untuk jujur tentang hal ini saat membandingkan. Jadi mereka sama sekali bukan L2. Itu hal pertama.
Kemudian saya ingin menambahkan sesuatu tentang asinkronitas antara penyortiran dan pembuktian, karena ini sangat penting. Seperti yang Anda katakan, kami ingin mengoptimalkan penyortiran, karena saat ini merupakan hambatan untuk semua solusi. Tapi itu bagus dalam konteks pengurutan terpusat, karena kita tahu penyortir hanya akan menghasilkan transisi nilai dan kita akan dapat memverifikasinya. Tetapi akan lebih sulit dalam konteks penyortiran terdesentralisasi, karena mungkin penyortir Anda dapat menghasilkan sesuatu yang tidak dapat diverifikasi. Maka Anda harus berurusan dengan itu nanti.
Dalam konteks penyortiran terpusat, untuk mengoptimalkan penyortiran, karena kami tidak harus membuat bukti selama proses penyortiran, kami dapat mencoba melakukannya dengan kecepatan lokal, yang ingin kami lakukan. Terjemahkan Kairo ke bahasa mesin tingkat rendah seperti LLVM dan jalankan super cepat di penyortir. Kemudian Anda dapat membuktikan secara asinkron. Dan hal paling keren tentang pembuktian adalah Anda bisa melakukannya secara paralel. Paralelisasi besar-besaran dicapai dengan membuktikan bahwa rekursi itu mungkin. Itu sebabnya kami akan dapat mengejar kecepatan penyortir. Tetapi sulit ketika didesentralisasikan, karena kita perlu memastikan bahwa pemesan hanya menghasilkan transisi status yang valid.
Pilihan
Saya akan menambahkan bahwa saya tidak yakin apa yang dilakukan Starknet di sini. Tetapi bagi kami, saya kira itu adalah asumsi umum dari setiap zkRollup bahwa jika Anda mendesentralisasikan penyortir, sistem bukti Anda harus dapat menangani kumpulan yang tidak valid. Jadi pada dasarnya, jika, katakanlah, Anda mengirimkan kumpulan dengan tanda tangan yang tidak valid, Anda harus dapat membuktikan bahwa status yang dihasilkan setara dengan status awal. Jadi akan ada beberapa biaya tambahan. Ini tentang bagaimana Anda meminimalkan kemungkinan hal ini terjadi.
Abdelhamid
Ya itu betul. Itu sebabnya kami memperkenalkan Sierra di Kairo 1 untuk membuat semuanya dapat diverifikasi. Representasi perantara ini akan memastikan bahwa setiap program Kairo 1 dapat diverifikasi sehingga kami dapat menyertakan transaksi pengembalian.
Apa itu rollup Berbasis?
Yaoqi
Rollup berbasis awalnya berasal dari posting blog oleh Justin Drake di forum Ethereum. Salah satu idenya adalah kita dapat menggunakan kembali beberapa pemverifikasi Ethereum untuk memverifikasi transaksi rollup, sehingga kita tidak memerlukan grup node terpisah untuk memverifikasi transaksi rollup yang berbeda. Secara khusus, kami akan memiliki banyak rollup di masa mendatang, termasuk rollup tujuan umum dan banyak rollup khusus aplikasi. Jadi, dalam hal ini, alangkah baiknya jika kita dapat menemukan tempat umum seperti kumpulan validator Ethereum untuk memvalidasi transaksi ini.
Tentu saja, ini hanya sebuah ide, karena juga menimbulkan banyak kesulitan teknis. Misalnya, secara teori, kami dapat meminta validator Ethereum untuk memverifikasi transaksi rollup, tetapi sangat sulit untuk mendapatkan logika verifikasi rollup yang dibundel atau disematkan ke dalam protokol Ethereum itu sendiri. Kami menyebutnya verifikasi dalam protokol, yang memerlukan hard fork node Ethereum. Tentu saja, dalam hal ini, kami dapat memverifikasi beberapa transaksi rollup. Tetapi jika kami melakukannya, Anda akan melihat masalah. Sepertinya kami ingin rollup L2 berbagi tekanan Ethereum, tetapi pada akhirnya kami masih meminta validator Ethereum untuk melakukan beberapa pekerjaan yang diturunkan ke L2. Jadi banyak orang berbicara tentang bagaimana kita bisa melakukan ini.
Kemudian kami berbincang dengan Barnabe, seorang peneliti di Ethereum Foundation yang saat ini sedang mengerjakan PBS. Ini adalah proposal Ethereum, yaitu membagi tugas validator menjadi beberapa peran, pembangun, dan pengusul. Sekarang kami memiliki Flashbots untuk berperan sebagai pembangun di PBS, mereka menyusun semua blok dan mengirimkannya ke pengusul Ethereum. Jadi begitu blok-blok ini dikemas ke dalam jaringan Ethereum, pembangun juga akan mendapatkan beberapa hadiah. Lalu dalam hal ini, bagaimana cara memberi penghargaan kepada validator ini dari jaringan Ethereum? Mereka juga bertanggung jawab atas validasi rollup.
Salah satu solusinya adalah "restaking", yang mungkin sudah sering Anda dengar dari EigenLayer atau beberapa protokol lainnya. Pengguna dapat mempertaruhkan kembali ETH di jaringan penyortiran lainnya. Atau hadiahi validator Ethereum karena benar-benar menjalankan perangkat lunak untuk melakukan pekerjaan validasi untuk rollup. Dalam hal ini, mereka dapat diberi hadiah baik dari L2 maupun melalui protokol staking ulang. Ada banyak proposal sejauh ini, tetapi secara umum ini adalah ide tentang bagaimana dapat menggunakan kembali validator Ethereum yang ada. Bagaimana kami dapat menggunakan kembali ETH yang ada untuk membantu mengantarkan era baru sistem rollup atau L2? Jadi pada dasarnya mencoba menyederhanakan banyak hal untuk proyek rollup. Jika rollup menginginkan penyortir baru, jika mereka menginginkan sumber agunan baru, mereka dapat menggunakan kembali infrastruktur yang ada atau agunan yang ada. Jadi itulah mengapa itu dibangun di atas Ethereum, dan kemudian infrastruktur dan staking lebih lanjut dapat digunakan kembali untuk rollup dan L2 juga.
Kerugian dari sequencer bersama dan rollup berbasis, serta skenario aplikasinya.
Pilihan
Saya ingin mengeluh tentang proposal ini, saya tidak yakin dengan proposal yang terkait dengan sequencer bersama. Tentu saja, mereka masih dalam masa pertumbuhan, dan jika desain ini meningkat di masa mendatang, sangat mungkin saya akan mendukung mereka. Hanya saja bentuk saat ini tidak meyakinkan saya. Ada banyak alasan.
Pertama, bagi saya, proposisi nilai utama dari penyortir bersama adalah untuk memungkinkan pengguna mendapatkan komposisi atom antara rollup tujuan umum seperti Scroll atau Starknet. Namun masalahnya adalah jika Anda memiliki kemampuan menyusun atom, maka rollup Anda sama finalnya dengan rollup paling lambat yang Anda gabungkan. Jadi, dengan asumsi Scroll digabungkan dengan Optimistic Rollup, finality Scroll adalah tujuh hari. Sementara proposisi nilai utama ZKRollup adalah untuk mencapai penyelesaian yang relatif cepat, pengguna dapat menarik diri ke L1 dalam hitungan menit. Dan dalam hal ini, pada dasarnya menyerah pada itu.
Kelemahan lainnya adalah jika Anda menginginkan finalitas off-chain, Anda perlu menjalankan node L2, dan selama data yang dikirimkan ke rantai diselesaikan oleh L1, Anda mendapatkan finalitas secara lokal di L2. Jika setiap gabungan L2 tidak menjalankan simpul penuh, secara praktis tidak mungkin mencapai finalisasi lokal. Ini berarti menjalankan sistem ini bisa lebih mahal daripada menjalankan sistem seperti Solana, karena Anda memiliki banyak node penuh yang berjalan pada saat yang sama, dengan overhead mereka sendiri dan seterusnya.
Jadi untuk alasan itu, menurut saya L2 tidak masuk akal. Ini sedikit berbeda untuk L3, karena jika seseorang ingin membangun rantai khusus aplikasi dan tidak ingin berurusan dengan desentralisasi. Katakanlah saya sedang membuat game dan saya hanya ingin berurusan dengan pembuatan game tersebut, lalu saya dapat mengalihdayakan pekerjaan yang terdesentralisasi. Tapi saya rasa itu tidak masuk akal untuk L2 saat ini.
Untuk rollup berbasis, saya juga memiliki kekhawatiran. Misalnya, bagaimana Anda membagi keuntungan MEV dengan pembukti? Karena jika masalah alokasi tidak diperhatikan, pada dasarnya L1 dapat memperoleh semua keuntungan MEV. Hal kecil lainnya adalah waktu konfirmasinya sama dengan waktu konfirmasi L1 yaitu 12 menit, tidak bisa lebih cepat. Masalah lainnya adalah karena tidak memiliki izin, banyak Pencari dapat mengirimkan kumpulan transaksi pada saat yang sama, yang berarti hasil akhir mungkin terpusat. Karena pembangun diberi insentif untuk memasukkan transaksi mereka jika satu penelusur terhubung lebih mudah daripada yang lain. Oleh karena itu, pada akhirnya hanya satu Seeker yang mengusulkan batch untuk L2, yang pada akhirnya bukanlah solusi yang baik, karena jika ini terjadi, pada dasarnya kita kembali ke titik awal.
Yaoqi
Menariknya, saya baru saja menelepon Ben, pendiri Espresso, sebenarnya minggu lalu. Kami banyak membahas ini dalam topik penyortir bersama. Seperti yang disebutkan Toghrul, menurut saya ada beberapa ketidakpastian tentang skenario penggunaan untuk sistem pemesanan bersama. Ini terutama karena untuk L2 tujuan umum, kami biasanya tidak memiliki banyak penyortir karena efisiensi, kerumitan, dan ekonomi. Dan saya masih merasa bahwa apakah itu untuk sequencer bersama, rollup berbasis, atau pengambilan ulang, kasus penggunaan terbaik sebagian besar adalah untuk RAS (Rollup as a Service) atau platform semacam itu di mana kami dapat meluncurkan banyak rollup. Sejujurnya kami tidak terlalu membutuhkan jaringan penyortiran yang besar jika tidak banyak rollup. Rollup ini sudah memiliki sistem penyortirnya sendiri, dan sudah memiliki komunitas atau mitranya sendiri, ketika hanya ada beberapa L2 generik. Mereka tidak benar-benar perlu memiliki jaringan pihak ketiga yang terpisah. Juga, ini menjadi beban pada jaringan pihak ketiga, karena Anda harus menyesuaikan untuk setiap L2, dan setiap L2 memiliki test stack yang berbeda. Ini membutuhkan banyak perubahan pada jaringan Anda sendiri.
Tetapi pada saat yang sama, seperti yang disebutkan Toghrul, untuk beberapa kasus penggunaan khusus. Misalnya, jika kita ingin memiliki beberapa interoperabilitas di tingkat penyortir, penyortir bersama bisa menjadi cara yang potensial. Misalnya, penyortir yang sama digunakan untuk beberapa pembatalan. Dalam hal ini, penyortir ini pada dasarnya dapat menangani beberapa transaksi lintas rollup untuk memastikan atomisitas lintas rantai antara rollup A, B, dan C.
Tapi Anda juga bisa melihat masalahnya di sini saat saya menjelaskan situasinya. Jika kami benar-benar memiliki banyak dari sequencer bersama ini, mereka akan kembali menjadi hambatan dan satu titik kegagalan baru. Kami memberikan terlalu banyak kekuatan kepada apa yang disebut pemesan bersama ini. Mereka menjadi lebih seperti jaringan, mengendalikan banyak rollup. Terakhir, sekali lagi kami perlu menemukan cara untuk mendesentralisasikan penyortir bersama ini.
Tapi bagaimanapun, saya pikir itu hal yang baik bahwa orang-orang secara bertahap menemukan lebih banyak masalah dan menghasilkan lebih banyak solusi. Secara keseluruhan, menarik untuk melihat apa yang baru di bidang ini setiap hari. Dengan semua solusi baru ini, setidaknya kami berada di jalur yang benar untuk benar-benar mendesentralisasikan seluruh ruang rollup.
Abdel
Ya, saya setuju dengan Anda berdua. Saya pikir itu lebih masuk akal untuk Layer3 dan Lisk karena mereka tidak ingin mengambil tanggung jawab untuk memberi insentif pada jaringan yang terdesentralisasi lagi dan perlu mencari mitra untuk memulai hal-hal seperti penyortir. Jadi saya pikir untuk Lisk, itu masuk akal. Tapi seperti Toghrul, menurut saya itu belum masuk akal untuk Layer2 dulu.
Topik 4
Apa dampak pemesan terdesentralisasi terhadap MEV?
Abdel
Untuk Starknet, dalam konteks sentralisasi, kami tidak melakukan jenis MEV apa pun, dan kami mengadopsi model siapa cepat dia dapat. Artinya, dalam konteks desentralisasi, tentu akan lebih banyak MEV yang dibawa nantinya. Namun terlalu dini untuk mengatakan rasio yang mana, karena juga tergantung pada rancangan mekanisme konsensus dan aspek lainnya.
Pilihan
Tapi masalahnya, meskipun Anda tidak melakukan MEV, mungkin masih ada beberapa MEV yang terjadi di Starknet. Desentralisasi dengan sendirinya tidak benar-benar menurunkan MEV atau meningkatkan MEV. Tentu saja, jika Anda menerapkan semacam protokol pemesanan yang adil atau enkripsi ambang batas, misalnya, ya, Anda meminimalkan MEV. Tapi Anda tidak bisa sepenuhnya menghilangkannya. Filosofi saya adalah: MEV tidak bisa dihilangkan. Tapi katakanlah Anda hanya membuat konsensus BFT, atau membangun sesuatu di atas konsensus BFT. Ini sebenarnya tidak mempengaruhi MEV sama sekali. MEV masih ada, harus menjadi pertanyaan tentang bagaimana pencari bekerja dengan penyortir untuk mengekstrak MEV itu.
Yaoqi
Masalahnya adalah, bahkan model yang pertama datang, yang pertama dilayani memiliki bagian yang rumit. Setelah kami mengekspos mempool ke beberapa pencari, mereka masih memiliki keuntungan untuk bermain lebih banyak. Misalnya, untuk pengurut, mereka setara dengan menunggu di depan pintu kantor Anda. Jadi dalam hal ini, begitu mereka melihat semacam peluang arbitrase, bukan hanya tentang front-running atau serangan sandwich, segera setelah pengguna mengirimkan transaksi, mereka dapat langsung melihatnya di mempool. Jadi, mereka dapat dengan cepat menempatkan perdagangan mereka di depan orang lain. Jadi, mereka memiliki keunggulan dibandingkan pencari lainnya.
Tapi kembali ke desentralisasi, saya pikir ini sebagian besar tentang penolakan sensor, seperti yang kita bahas di awal. Sequencer dikelola oleh tim. Tim dapat mengatakan bahwa mereka bersikap adil kepada semua orang. Tapi ini tidak dicegah dalam kode. Jadi, jika kita dapat memiliki jaringan P2P, alangkah baiknya jika kita merasa node ini memeriksa transaksi saya dan kemudian kita dapat mengirimkannya ke node lain. Jadi, ini benar-benar tentang keadilan pemrosesan transaksi di L2.
Adapun MEV, karena baru-baru ini, selain MEV yang dihasilkan dalam satu rollup, ada beberapa MEV yang dihasilkan melintasi jembatan. Dalam jaringan penyortiran yang relatif terdesentralisasi ini, Anda akan memiliki lebih banyak kesempatan untuk mengekstraksi MEV. Dengan asumsi kita memiliki jaringan pemesanan bersama, jika Anda entah bagaimana dapat memengaruhi pemesan bersama untuk memesan ulang transaksi, pada dasarnya Anda memiliki keuntungan besar dibandingkan orang lain.
Ada keuntungan dan kerugian dari jaringan sequencer bersama. Di sisi positifnya, kita dapat mendesentralisasikan sistem ranker lebih lanjut. Namun di sisi lain, setiap orang memiliki kesempatan untuk menjadi seorang penyortir. Jadi, pada dasarnya mereka dapat melakukan apapun yang mereka inginkan, dan itu adalah hutan yang gelap lagi. Jadi, kami memperkenalkan desentralisasi, dan kemudian kami harus menghadapi masalah serupa yang kami hadapi di Ethereum. Itu sebabnya Flashbots dan orang-orang Ethereum Foundation ingin bergerak maju dengan PBS, memisahkan pengusul dan pembangun, dan kemudian mencoba untuk memiliki satu solusi di sisi pembangun.
Jadi kalau kita lihat masalahnya, bukan hanya satu masalah. Ini bukan lagi masalah satu lawan satu, tapi satu lawan enam, dan banyak lagi.