meneruskan judul asli 'kita semua membangun hal yang sama'

pengenalan

pos ini menganalisis hal berikut

• eksekusi asinkron - mengapa blockchain terintegrasi berkinerja tinggi (misalnya,SolanadanMonad) akan memisahkan eksekusi dari konsensus atas pengurutan (penyusunan).
• urutan malas - bagaimana mereka akan mencerminkan desain dari sequencer malas (misalnya,@astriaorg/hj6ccpp9t">astria).
• pra-konfirmasi - pra-konfirmasi pada ethereum l1 dan rollups berbasis.
• berbasis vs. non-berbasis - membandingkan rollups berbasis + preconfs vs. rollups non-berbasis + lapisan dasar fallback.
• komposabilitas sinkron universal - melalui inklusi atomik (dari pengurut bersama) + keamanan kriptografi (misalnya, )AggLayerdan/atau membuktikan waktu nyata)
• rollups berbasis cepat - rollups berbasis seharusnya hanya memiliki lapisan dasar yang cepat.
• permainan waktu - Waktu adalah uang, dan bagaimana itu menjadi dasar perbedaan akhir antara solana vs. ethereum.
• desentralisasi untuk ketahanan sensorship - bagaimanapemisahan pemberi saksi dan pengusulmelaluilelang eksekusimungkin menjaga validator terdesentralisasi yang dapat menegakkan resistensi sensorship dengandaftar inklusi.

terakhir, dan yang paling penting, kita akan melihat mengapakita semua sedang membangun hal yang sama sialanjadi mungkin kita seharusnya hanya...

mengoptimalkan replikasi mesin keadaan (smr)

kami akan membangun dari dasar untuk melihat bahwa akhirnya untuk blockchain berkinerja tinggi (misalnya, Solana, Monad, @patrickogradyPendekatan HyperSDK dalam mitigasi strategi memungkinkan pembangun untuk memaksimalkan keuntungan dan meminimalkan invalid TPS.urutan malas (misalnya, @astriaorg/hj6ccpp9t" >astria). kita akan kembali ke titik awal nanti untuk membandingkannya dengan rollups berbasis ethereum + preconfs.

urutan vs. pelaksanaan

blockchain adalahmesin negara yang direplikasinode terdesentralisasi masing-masing menyimpan dan memperbarui salinan dari status sistem mereka sendiri. untuk memajukan rantai, node menjalankan fungsi transisi status (stf) di atas status saat ini + input baru (misalnya, transaksi baru). ini menghasilkan status baru.

kami akan menggunakan istilah-istilah berikut sepanjang bagian ini:

• validitas sintaksis - transaksi ini terbentuk dengan struktur transaksi yang benar dan tanda tangan yang tepat.
• saatnya valid - transaksi melakukan transisi keadaan yang valid (misalnya, membayar biaya yang diperlukan).
• urutan - menentukan urutan dan inklusi data.
• menjalankan - menginterpretasikan dan bertindak atas data sesuai dengan stf.
• membangun - membuat blok (atau potongan blok/chunk/shred) dari transaksi yang disimpan secara lokal.
• memverifikasi - melakukan verifikasi sintaksis dan/atau semantik yang diperlukan dari blok (atau bagian blok yang terpotong).
• replikasi - menyebarkan blok (atau potongan blok/chunk/shred) ke validator lain.

Mari kita fokus pada urutan dan eksekusi, karena ini adalah sub-tugas inti yang diperlukan untuk menghitung status rantai:

Selain itu, node-node memverifikasi dan mereplikasi data di seluruh jaringan. Node-node mencapai konsensus untuk menjaga pandangan yang konsisten terhadap rantai.

Namun, arsitektur rantai yang berbeda berbeda secara signifikan dalam hal siapa yang bertanggung jawab atas tugas-tugas ini dan kapan mereka melakukannya (misalnya, pembangunan dan verifikasi blok mungkin atau mungkin tidak termasuk eksekusi). Waktu end-to-end dari keseluruhan replikasi mesin keadaan (smr)loop menentukan batas bawah latency sistem. konstruksi yang berbeda dapat menghasilkan waktu yang sangat bervariasi, sehingga proses smr yang efisien pipa-pipatugas-tugas ini diperlukan untuk kinerja rendah-latensi dan tinggi-throughput.

pada bagian-bagian berikutnya, kita akan melihat bahwa inti dari pemipilan yang efisien adalah berfokus pada pencapaian konsensus atas input eksekusi daripada hasil eksekusi. hal ini membutuhkan relaksasi beberapa batasan tentang transaksi yang dapat dimasukkan. kita kemudian perlu memperkenalkan beberapa batasan yang lebih lemah untuk memastikan bahwa sistem tetap berguna dan tahan terhadap serangan (misalnya, menghindari vektor dos dari transaksi yang tidak membayar biaya).

smr tradisional

smr tradisional (misalnya, ethereum) erat memasangkan urutan dan eksekusi. node lengkap terus menerus mensekuensikan dan menjalankan semua transaksi lapisan dasar - keduanya merupakan prasyarat agar node mencapai konsensus. selain memverifikasi bahwa semua data blok tersedia (dan terurut), node juga harus menjalankan blok untuk memverifikasi bahwa:

• semua transaksi adalah valid secara sintaksis dan semantik
• negara baru yang dihitung cocok dengan yang disediakan oleh pemimpin

validator hanya akan memilih untuk sebuah blok dan membangunnya setelah mereka secara independen memverifikasi keadaannya. ini berarti eksekusi dilakukan setidaknya dua kali sebelum konsensus dapat dicapai (yaitu, produsen blok menjalankan selama membangun + validator penerima menjalankan kembali untuk memverifikasi).

dalam model tradisional ini, pembangunan dan verifikasi keduanya mencakup eksekusi.

sumber: @patrickogrady/rys8mdl5p#membuat-argumen-untuk-replikasi-mesin-keadaan-terlepas-dsmr">vryx: memperkuat replikasi mesin keadaan terlepas

streaming smr

streaming smr (misalnya, solana) adalah bentuk yang efisien dari pipelining di mana produsen blok secara terus-menerus “menyiar” potongan-potongan blok(disebut serpihanatau potongan) saat mereka dibangun. node lain menerima dan memverifikasi (termasuk eksekusi) serpihan ini secara kontinyu, bahkan saat sisa blok masih dalam pembangunan. ini memungkinkan pemimpin berikutnya untuk mulai membangun blok mereka lebih awal.

sumber: @patrickogrady/rys8mdl5p#membuat-argumen-untuk-replikasi-mesin-stan-tak-terkait-dsmr">vryx: memperkuat replikasi mesin stan tak terkait

dalam model streaming ini, pembangunan dan verifikasi masih mencakup pengurutan dan eksekusi. hal ini meningkatkan efisiensi smr dibandingkan dengan smr tradisional tanpa mengurangi batasan bahwa semua transaksi yang termasuk harus semantik dan sintaktik valid.

eksekusi asynchronous

pendekatan terpadu

sekarang, bisakah kita mendapatkan performa yang lebih baik jika kita melonggarkan batasan-batasan tersebut?

eksekusi asinkron menghilangkan eksekusi dari jalur panas konsensus - node hanya mencapai konsensus tentang urutan data tanpa terlebih dahulu menjalankan data tersebut. ini lebih efisien, itulah sebabnya SolanadanMonadkeduanya berencana untuk melaksanakan eksekusi asinkron.

pemimpin akan membangun dan mereplikasi blok (atau serpihan) tanpa perlu menjalankannya. kemudian, validator lain akan memberikan suara tanpa menjalankannya juga. node hanya mencapai konsensus tentang urutan dan ketersediaan transaksi. ini sudah cukup karena dengan stf yang deterministik, semua orang pada akhirnya akan menghitung keadaan yang sama. eksekusi tidak perlu menahan konsensus - itu bisa berjalan secara asinkron. ini dapat membuka anggaran eksekusi bagi node (memberi mereka lebih banyak waktu untuk dihabiskan pada eksekusi) sambil mengurangi langkah-langkah yang diperlukan (dan oleh karena itu waktu) untuk mencapai konsensus.

pengurutan menentukan kebenaran. eksekusi hanya mengungkapkannya. siapa pun dapat mengeksekusi data untuk mengungkap kebenaran begitu pengurutannya selesai.

mungkin itulah sebabnya Keone percaya bahwa pada akhirnya setiap blockchain akan menggunakan eksekusi asinkron, dan ini adalah bagian kunci dari Visi akhir Toly untuk solana:

“eksekusi sinkron membutuhkan semua node yang memberikan suara dan membuat blok untuk memiliki sumber daya lebih dari waktu eksekusi terburuk dalam setiap blok... node konsensus dapat melakukan pekerjaan lebih sedikit sebelum memberikan suara. pekerjaan dapat diagregatkan dan dikelompokkan, sehingga dieksekusi dengan efisien tanpa adanya cache miss. bahkan dapat dieksekusi pada mesin yang berbeda sama sekali dari node konsensus atau pemimpin. pengguna yang menginginkan eksekusi sinkron dapat mengalokasikan sumber daya perangkat keras yang cukup untuk menjalankan setiap perubahan status secara real time tanpa harus menunggu jaringan lainnya.

saat ini, validator memutar ulang semua transaksi secepat mungkin pada setiap blok dan hanya memberikan suara sekali saat perhitungan status lengkap untuk blok tersebut selesai. tujuan dari proposal ini adalah untuk memisahkan keputusan memberikan suara pada fork dari perhitungan transisi status lengkap untuk blok tersebut.

Perlu dicatat bahwa kami juga ingin memastikan bahwa kebenaran dapat terungkap dengan mudah kepada pengguna, dan itu berarti dukungan yang kuat untuk klien ringan. Beberapa desain yang menunda eksekusi secara signifikan akan membuat ini menantang (misalnya, Solana mempertimbangkan hanya memerlukannya sekali per epoch) vs. yang memberikan akar negara pada penundaan yang lebih singkat (misalnya, seperti dalam hypersdk).

pendekatan modular

pengelompokan urutan dan eksekusi mungkin terdengar sangat familiar karena ini juga adalah pendekatan “modular”! padukan berbagai lapisan yang mengkhususkan diri dalam tugas-tugas yang berbeda. pemisahan urutan dan eksekusi adalah prinsip desain kunci dari sequencer yang malas (misalnya, astria):

• sequencing - node sequencer hanya mencapai konsensus tentang urutan dan ketersediaan data rollup (yaitu, mereka menyusun tetapi tidak mengeksekusi).
• Node rollup melakukan eksekusi data masing-masing setelah sequencer telah mengkomitnya.

Perbedaan utama di sini adalah bahwa node rantai terintegrasi dieksekusi setelah pengurutan sedangkan sequencer malas mendorongnya ke sekumpulan aktor yang benar-benar berbeda dan beragam. Sequencer malas sama sekali tidak mengetahui mesin negara rollup. Mereka tidak pernah mengeksekusi transaksi ini. Rollup menangani eksekusi asinkron.

pendekatan terintegrasi memberikan interoperabilitas yang lebih lancar antara pengguna lingkungan eksekusi, tetapi secara arah mengurangi fleksibilitas bagi pengembang aplikasi (misalnya, vm kustom, waktu slot yang berbeda)aturan penetapan harga dan urutan transaksi yang diberlakukan konsensus khusus aplikasi, dll.pendekatan modular memberikan fleksibilitas dan kedaulatan yang lebih besar bagi pengembang untuk memiliki domain yang disesuaikan, tetapi lebih sulit untuk menyatukan pengalaman di antara mereka.

Dalam kedua kasus, pipa yang besar dan cepat untuk memesan data adalah elemen dasar yang kita butuhkan:

Namun, Anda harus mencatat bahwa pada dasarnya Anda dapat menggunakan hampir setiap rantai sebagai pengurut yang malas. Pada akhirnya, ini hanya pipa data besar. Sebuah rollup dapat dengan naif melemparkan data sewenang-wenangnya ke lapisan dasarnya pilihan (baik itu ethereum, bitcoin, monad, dll.) untuk secara implisit menggunakannya sebagai pengurut mereka. Node rollup kemudian dapat menjalankan data secara asinkron setelahnya.

Perbedaan dalam praktiknya adalah rantai yang kami sebut sebagai 'lazy sequencers' secara khusus untuk tugas ini, yang jauh lebih mudah dikatakan daripada dilakukan (misalnya, mendukung jenis transaksi yang diperlukan, mengekspos antarmuka yang mudah, mengimplementasikan infrastruktur mev, waktu slot yang cepat, inklusi transaksi yang dapat diandalkan, bandwidth tinggi, dll.). Akibatnya, node untuk rantai terintegrasi pada akhirnya akan menjalankan sebagian besar data yang mereka sertakan, sementara lazy sequencers mengandalkan rollups untuk itu secara utama.

Itulah mengapa tidak semudah 'mengapa kita tidak hanya menggunakan Solana (atau rantai lain ketika itu bukan tujuan desain) sebagai pengurut gulungan?' :

• kurangnya infrastruktur mev yang diperlukan yang dirancang khusus untuk rollups (misalnya, infrastruktur pbs yang diperlukan, mekanisme interoperabilitas lintas-rantai, komposer untuk abstraksi pembayaran biaya bagi pengguna rollup dalam token gas lapisan dasar, dll.)
• kurangnya tipe transaksi asli yang dirancang untuk rollups memposting data.
• berkompetisi melawan lingkungan eksekusi asli (misalnya, dirancang secara eksplisit untuk mengonsumsi semua atau sebanyak mungkin data yang disediakan, meninggalkan ruang yang lebih sedikit dan inklusi transaksi yang dapat diandalkan, dll).
• bersaing untuk dukungan pengembang umum dan prioritisasi upgrade. Anda mungkin lebih cenderung pergi ke protokol dan tim yang mengkhususkan diri dalam membantu Anda meluncurkan rollups dan merancang protokol mereka secara khusus dengan Anda dalam pikiran dibandingkan dengan yang mana sebagian besar komunitas berpikir rollups agak bodoh.

memperkuat smr yang terputus

Sekarang, bisakah kita mengatasi masalah-masalah yang kita dapatkan dengan merilekskan kendala-kendala ini? Singkatnya, ya implementasi naif memang memperkenalkan masalah seperti memungkinkan transaksi yang tidak valid yang tidak dapat membayar biaya (yang akan menjadi vektor dos jika diimplementasikan secara naif), tetapi masalah-masalah tersebut dapat diatasi sehingga tidak menjadi masalah serius.

kami tidak akan terlalu terjebak dalam detail di sini, tetapi Anda dapat merujuk kePatrick o’grady’spekerjaan yang luar biasa di@patrickogrady/rys8mdl5p#menguatkan-desentralisasi replikasi mesin keadaan (DSMR)">vryx untuk memperkuat DSMR terpisah, toly'spermainan akhir eksekusi asinkron, dan Implementasi biaya kandang Monadtentang cara mengatasi masalah-masalah ini. sekali lagi, solusi-solusi untuk masalah-masalah ini tidak terlalu berbeda di sisi modular maupun sisi terintegrasi.

tldr adalah bahwa Anda dapat memperkenalkan beberapa batasan yang jauh lebih lemah (dibandingkan dengan eksekusi sinkron dengan verifikasi penuh) yang mempertahankan sebagian besar manfaat kinerja tanpa membuka banyak serangan.

aktor dalam protokol vs. aktor di luar protokol

Yang lebih penting, kita harus menyadari bahwa proses di atas hanya menghitung akun dalam protokol secara naif. Dalam kenyataannya, akun di luar protokol memainkan peran yang besar dalam rantai pasokan transaksi ini. Ini adalah apa yang kita lihat sebelumnya untuk validator (dalam protokol) dalam smr tradisional:

sumber: @patrickogrady/rys8mdl5p#membuat-alasan-untuk-replikasi-mesin-keadaan-terputus-terkait-dsmr">vryx: memperkuat replikasi mesin keadaan terputus

dalam praktiknya,hampir semua validator ethereum mengoutsourcing pembangunan blok melalui mev-boostdengan tiga pembangun teratas (beaver, titan, dan rsync) hampir membangun semua blok ini. perlu dicatat bahwa beaver dan rsync menyensor transaksi ofac sedangkan titan tidak.

sumber: mevboost.pics

relay mengelola replikasi blok-blok ini ke seluruh jaringan. Mereka juga relatif terpusat, dengan empat operator teratas (ultra sound, bloxroute, agnostic, dan flashbots) yang meneruskan sebagian besar blok. Bloxroute dan flashbots menyensor transaksi OFAC, sementara agnostic dan ultra sound tidak.

sumber:mevboost.pics

tidak mengherankan jika kita melihat tren yang sangat mirip dalam optimasi latensi di sini seperti yang kita bahas sebelumnya. trennya adalah menujurelay yang optimisyang tidak lagi melakukan verifikasi blok sebelum replikasi karena lebih cepat. sequencer malas dapat dilihat sebagai jaringan relay yang mendapat insentif.

contoh-contoh ini menyoroti bagaimana mekanisme eksekusi transaksi (MEV) memiringkan insentif keuntungan dalam sistem-sistem ini. validator mengalihkan produksi blok karena pembangun yang canggih dapat menangkap lebih banyak nilai dibandingkan dengan blok yang disusun secara naif.

Bahkan dalam eksekusi asinkron, seringkali akan ada produsen blok di luar protokol yang menjalankan transaksi selama pembangunan untuk memaksimalkan nilai. Misalnya, sangat mungkin bahwa urutan malas akan memiliki pembangun yang memaksimalkan keuntungan dalam beberapa bentuk pbs. Fakta bahwa produsen blok eksternal selalu termotivasi untuk tetap sepenuhnya menjalankan dan mengoptimalkan nilai blok sebenarnya dapat berguna dalam pengaturan di mana kita merelaksasi batasan dalam eksekusi asinkron. Namun, validator lain tidak perlu mengeksekusi ulang sebelum memilih.

komposabilitas sinkron universal

definisi

Sekarang, bisakah kita mendapatkan kedaulatan dan fleksibilitas yang ditawarkan oleh rantai modular, tetapi menyatukannya untuk terasa seperti rantai terintegrasi? Bisakah kita memiliki kue kita dan memakannya juga, atau apakah kita hanya akan membangun solana dengan langkah-langkah ekstra?

ketika mendengarkan orang berbicara tentang memperbaiki fragmen rollup, Anda mungkin telah mendengar kata-kata besar yang beredar di sekitarnyakomposabilitas sinkron universal(USC). Namun, ini mungkin telah menjadi reaksi Anda:

semua istilah ini sering disalahartikan dengan berbagai makna, dan beberapa istilah sering digunakan secara keliru secara bergantian. kita perlu menetapkan beberapa definisi yang konkret. kita mendefinisikan istilah-istilah yang diperlukan di bawah ini dalam konteks komposabilitas lintas-rantai.

perhatikan bahwa kami akan membahas "rollups" di sisa laporan ini, tetapi banyak konsep ini juga berlaku untuk jenis "l2s" lain seperti validiums.Saya hanya tidak ingin bertengkar lagi tentang apa itu l2.

dalam contoh-contoh berikut:

• r_sebuah = rollup a
• r_b = rollup b
• t_a1 = transaksi 1 di r_seorang
• t_B1= transaksi 1 di r_b
• b_a1blok 1 pada r_satu
• b_b1 = blok 1 pada r_b
  

perlu dicatat bahwa kita mendefinisikan 'waktu' sebagai 'tinggi slot' di sini. waktu sepenuhnya relatif terhadap pengamat. satu-satunya konsep objektif dari waktu yang kita miliki adalah pengurutan relatif oleh pengamat bersama, yakni konsensus bersama (di mana 'konsensus' tersebut dapat berupa satu aktor atau mekanisme terdesentralisasi).

jika kedua rollup masing-masing memiliki mekanisme konsensus yang menyediakan pengurutan, kita dapat menegaskan:

• b_A1 adalah sebelum b_a2
• b_b1ada di depan b_b2

namun, satu-satunya cara untuk menegaskan:

• b_a1 adalah pada saat yang sama di b_B1, dan karena itu
• t_a1dan t_b1terjadi secara bersamaan, adalah jika
• mereka berbagi pemesanan yang disediakan oleh konsensus bersama untuk slot tertentu tersebut.

Oleh karena itu, definisi komposabilitas simultan lintas-rantai secara definisi memerlukan beberapa jenis pengurut bersama untuk ketinggian slot tersebut. Rantai tanpa pengurut hanya bisa memiliki komposabilitas asinkron.

Namun, perhatikan bahwa kita dapat memiliki komposabilitas atom asinkron. Sayangnya, saya sering melihat orang menggunakan "atom" dan "sinkron" secara bergantian, tetapi mereka memang istilah yang berbeda.

setelah itu, mari kita lihat apakah kita dapat menghadirkan komposabilitas sinkron ke dalam rantai modular. jika kita bisa, maka itu mungkin akan meningkatkan nilai rantai terintegrasi. ini adalah tldr yang akan kita telusuri:

• sekuensing bersama dapat memberikan inklusi atomik simultan sendiri (yang jauh lebih lemah daripada komposabilitas).
• menggabungkan sekuen yang dibagikan dengan beberapa mekanisme keamanan kriptografi (misalnya, agglayer) dapat memperkuat jaminan inklusi ini menjadi komposabilitas yang sebenarnya.
• jaminan keamanan yang diberikan oleh agglayer untuk keamanan lintas-rantai juga dapat digunakan tanpa sequencer bersama (yaitu, dalam pengaturan asinkron).
• Kita akan melihat bagaimana kita juga dapat mensimulasikan efek komposabilitas sinkron, meskipun dengan cara yang kurang efisien modal, menggunakan cryptoeconomics (secara langsung menjamin transaksi lintas rantai).

inklusi atom - urutan bersama

Sequencing bersama berarti bahwa untuk ketinggian slot tertentu, satu entitas tunggal (yang disebut sebagai 'pengurut' atau 'penyusun tawaran') memiliki hak monopoli untuk mengurutkan (yaitu, mengusulkan blok untuk) beberapa rantai. Untuk menegaskan kembali, para pengurut bersama yang kita bicarakan secara umum adalah...urutan malas. mereka mencapai konsensus tentang urutan dan ketersediaan data rollup, tetapi mereka tidak menjalankannya. mereka sama sekali tidak tahu tentang mesin state rollups.

Seperti yang pernah saya tulis sebelumnya, ini berarti bahwa shared sequencers yang malas dapat memberikan komitmen yang dapat dipercaya untuk menyertakan bundel cross-chain (yaitu, kumpulan transaksi):

• atomically - baik semua transaksi akan disertakan atau tidak akan ada yang disertakan, dan
• secara sinkron - pada saat yang sama (tinggi slot)

ini memungkinkan ekstraksi mev yang lebih efisien olehsuper builders(yaitu, pembangun lintas-rantai) saat melakukan tindakan lintas-rantai, karena mereka tidak lagi harus menentukan harga risiko bahwa salah satu kaki paket lintas-rantai mungkin gagal. sinkronisasi di sini mampu secara implisit memberikan mereka atomisitas.

pemisahan lintas-rantai

sekarang, bagaimana tepatnya kita melakukannya tanpa sepenuhnya mempercayai builder dan/atau proposer aktif untuk urutan bersama? jika kita hanya mengirimkan dua transaksi yang ditandatangani secara independen (t₁dan t₂) untuk setiap rollup, sequencer bersama masih bisa memutuskan untuk hanya menyertakan satu atau yang lain.

misalnya, saat ini tidak ada konsep format bundel asli di evm, itulah mengapa pencari sepenuhnya mempercayai pembangun/relay untuk tidak membuka bundel tersebut. siapa pun yang melihat bundel transaksi yang ditandatangani secara independen sebelum mereka diakui oleh pemimpin saat ini dapat membukanya. ini umumnya baik, karena pembangun dan relay memiliki insentif untuk menjaga reputasi mereka dan melindungi bundel pencari, tetapi ketika kepercayaan itu tergoyahkan (atau mereka dibodohi oleh peserta yang tidak jujur untuk mengungkapkan transaksi),membongkar-pasang dapat sangat menguntungkan.

Kami membutuhkan jaminan keamanan yang jauh lebih kuat di sini jika kami menginginkan interoperabilitas lintas rantai yang nyata. Kami tidak hanya berbicara tentang mengambil sejumlah uang dari pencari. Jika kontrak DeFi lintas rantai adalah untuk merancang diri mereka sendiri dengan asumsi bahwa bundel lintas rantai akan dihormati, tetapi kemudian kepercayaan ini rusak, hasilnya akan menjadi bencana besar bagi protokol tersebut (misalnya, dalam bundel jembatan lintas rantai burn-and-mint, Anda dapat meninggalkan pembakaran tetapi mencetak dana di sisi lain).

kita membutuhkan jaminan keamanan yang kuat untuk menerapkan interoperabilitas lintas-rantai. itu berarti kita harus mendefinisikan format transaksi yang memastikan bahwa beberapa transaksi dalam bundel lintas-rantai termasuk bersama-sama. jika salah satunya termasuk tanpa yang lain, kita membutuhkan jaminan keamanan bahwa yang termasuk tidak valid.

ini berarti kita perlu membuat struktur transaksi baru untuk paket cross-chain yang tidak dapatdipisahkan. solusi naif adalah 'mari kita buat jenis transaksi baru untuk rollup ini', tetapi itu tidaklah mudah. Ini akan memerlukan perubahan vm untuk rollup ini, sehingga kehilangan kompatibilitas mundur. Anda juga akan memasangkan rollup secara ketat dengan memodifikasi mesin status mereka sehingga setiap transaksi hanya valid bersama dengan yang lain dimasukkan.

Namun, ada cara yang lebih bersih untuk melakukannyaAnda dapat membuat setiap transaksi dalam bundle juga menandatangani hash bundle, kemudian menambahkan hash digest ke dalam field transaksi gratis (misalnya, calldata di evm). Rollup harus memodifikasi jalur turunan mereka untuk memeriksa ini, tetapi vm dapat tetap tidak berubah. Dengan ini, pengguna rollup dapat mengirimkan bundle lintas-rantai yang mereka yakin tidak dapat dibundel. Mencoba untuk melakukannya akan membuatnya tidak valid.

sumber:Ben fisch

Jaminan inklusi vs. jaminan negara

Dengan hal di atas, kami sekarang telah menetapkan bagaimana sequencer berbagi malas:

• dapat memberikan komitmen kredibel untuk inklusi sinkronisasi atomik untuk bundel lintas rantai (yaitu, bahwa semua transaksi akan disertakan, atau tidak ada yang akan disertakan)
• tidak dapat memberikan komitmen yang kredibel di sekitar keadaan yang dihasilkan dari transaksi tersebut dimasukkan (misalnya, ada kemungkinan bahwa kedua transaksi disertakan, tetapi beberapa transaksi lain mendarat di depannya dan menyebabkannya kembali)

Sayangnya, inklusi atom sendiri adalah jaminan yang jauh lebih lemah. Komitmen terhadap inklusi atom ini cukup bagi pembangun untuk memiliki keyakinan tinggi bahwa blok cross-rollup yang mereka bangun akan menciptakan keadaan yang dihasilkan yang mereka inginkan jika dikonfirmasi. Pembangun tentu tahu keadaan blok yang dihasilkan, karena mereka mengeksekusinya untuk membangunnya.

Namun kita masih memiliki masalah - bagaimana semua orang tahu dengan pasti apa keadaannya?

pertimbangkan contoh berikut:

• kami memiliki dua rollups (ra dan rb) yang membagi penyelesaian yang sama
• Saya ingin menggunakan jembatan burn-and-mint antara RA → RB yang secara bersamaan terbakar pada RA dan mint pada RB
• Kontrak jembatan pencetakan di rb membutuhkan jaminan transisi status pada ra (pembakaran) untuk mencetak di rb, namun kontrak tidak dapat mengetahui apakah token benar-benar dibakar pada ra pada saat eksekusi karena tidak memiliki akses ke status ra

jika kita mengirimkan bundle yang tepat, maka sequencer yang malas dapat menjamin bahwa transaksi pembakaran telah termasuk dalam aliran transaksi untuk ra, tetapi Anda tidak tahu misalnya jika mungkin ada transaksi lain yang mendarat di depannya yang menghapusnya (artinya token sebenarnya tidak terbakar).

Hanya berbagi pengisi urutan malas tidak cukup untuk memungkinkan rantai mengakses status satu sama lain selama eksekusi bundel. Komposabilitas sinkron memerlukan kemampuan untuk mesin negara setiap rantai untuk mengakses status rantai lain (misalnya, kontrak jembatan itu sendiri di rb perlu mengetahui status ra) pada saat pelaksanaan. Kemampuan itu tepat yang memungkinkan komposabilitas penuh dalam satu rantai terpadu.

pembangun tidak bisa hanya mengatakan kepada kontrak 'percayalah padaku, bro, ini akan berjalan dengan baik.' kita melihat bahwa inklusi atomik adalah alat yang bagus bagi para pencari yang percaya pada pembangun untuk secara tepat mengesekusi bundel mereka, tetapi itu tidak mencukupi untuk mengabstraksi interoperabilitas antara blockchain.

untuk memperbaiki ini, kita perlu menambahkan mekanisme lain selain dari urutan berbagi:

seperti yang kami sebutkan, pembangun secara pribadi tahu apa keadaan akhirnya akan menjadi meskipun jika bundel disertakan secara atomik. jadi bagaimana mereka bisa memberikan komitmen yang kredibel untuk meyakinkan semua orang tentang apa keadaan akhirnya akan menjadi jika transaksi mereka disertakan?

mereka secara umum memiliki dua pilihan:

• kriptoekonomi - pembangun dapat mempertaruhkan sejumlah besar modal untuk sepenuhnya menggadai tindakan lintas-rantai mereka.Ini seringkali tidak efisien dan dapat dikatakan komposabilitasnya disimulasikan, tetapi ini adalah contoh yang berguna untuk mendemonstrasikan fungsionalitasnya.
• kriptografi - kita dapat memiliki mekanisme yang memberikan jaminan kriptografi bahwa transaksi akan menghasilkan keadaan yang diinginkan.

keamanan kripto-ekonomi - obligasi pembangun

Mari kita berjalan melalui contoh untuk melihat bagaimana kriptoekonomi bisa mensimulasikan efek komposabilitas sinkron. Contoh klasik yang digunakan adalahflashloan cross-chain. saya ingin mengambil pinjaman kilat di ra, menggunakannya untuk arbitrase di rb, dan mengembalikannya di ra dalam satu slot yang sama. ini memungkinkan jika protokol defi di sini mengimplementasikan fungsi lintas-rantai yang disesuaikan dengan apa yang kita sebut sebagai 'kontrak bank' di setiap sisi:

sekarang untuk masalah keamanan itu - kontrak pada ra dan rb perlu saling mengetahui status rantai masing-masing untuk melakukannya dengan aman, tetapi kami belum melakukan apa-apa untuk menangani ini. nah, 'solusi' kriptoekonomi di sini sebenarnya agak kasar - Anda memiliki super builder bertindak sebagai penyedia likuiditas dan menempatkan nilai penuh pinjaman kilat. jika transaksi gagal, maka protokol peminjaman tetap mempertahankan saham mereka. Anda bisa melihat mengapa ini bukan 'solusi' yang paling memuaskan.

keamanan kriptografi - aglomerasi

apa itu

yang AggLayer adalah protokol terdesentralisasi yang memberikan tiga manfaat utama:

1. keamanan untuk komposabilitas cross-chain yang cepat - menghasilkan bukti zk yang memberikan keamanan kriptografi untuk interoperabilitas cross-chain atomik dengan latensi rendah (lebih cepat dari blok ethereum) saat beroperasi asinkron atau sinkron. desainnya secara unik mengisolasi kesalahan rantai sehingga dapat mendukung lingkungan dan pembuktian eksekusi apa pun.
2. Fungibilitas aset cross-chain - memiliki jembatan bersama untuk memastikan fungibilitas aset di seluruh aggchain (yaitu, rantai yang menggunakannya) sehingga pengguna tidak berakhir dengan sekelompok aset terbungkus. Kontrak jembatan berada pada ethereum yang merupakan lapisan penyelesaian(perhatikan bahwa rantai yang berbeda masih dapat memiliki asumsi keamanan yang berbeda karena implementasi, yang dibahas lebih lanjut di bawah.)
3. optimasi gas - ini aggreGate.ios membuktikan aggchains untuk mengamortisasi biaya tetap di banyak rantai. Kontrak deposit bersama juga mengoptimalkan biaya gas dengan memungkinkan transfer L2-ke-L2 langsung tanpa menyentuh L1.

sumber:Petani Brendan, Blockchain yang teragregasi

untuk menjelaskan dua kesalahpahaman umum tentang apa yang bukan agglayer:

• Agglayer bukan hanya layanan untuk membuktikan aggreGate.io - Ini membingungkan karena sebenarnya aggreGate.io bukti, dan mereka menempatkan "agregasi" atas nama benda itu. Namun, tujuan Agglayer adalah menggabungkan rantai. Perbedaan penting untuk tujuan posting ini adalah bahwa agregasi bukti saja tidak melakukan apa pun untuk mencapai jaminan keamanan yang kita butuhkan di sini.
• Agglayer dan sequencers bersama bukanlah desain yang saling bertentangan- meskipun mereka tidak perlu digunakan bersama-sama,mereka sebenarnya adalah pelengkap yang sempurnayang memberikan jaminan yang berbeda. agglayer sepenuhnya tidak peduli dengan bagaimana aggchains disusun. itu tidak menangani pesan antara rantai, jadi sebenarnya tergantung pada infrastruktur koordinasi pasar bebas secara eksplisit (misalnya, relay, pembangun, sekuenator terisolasi, sekuenator bersama, dll.) untuk menggabungkan rantai.

sekarang mari kita jelajahi bagaimana cara kerjanya.

jembatan itu buruk

menghubungkan antara rollups saat ini sangat sulit. katakanlah Anda ingin menghubungkan eth antara dua rollup optimistik ethereum (oru)_sebuahdan atau_b:

• melalui jembatan asli - Anda akan membayar biaya gas ethereum l1 yang mahal (yaitu, menghubungkan dari oru_sebuah → Ethereum + Ethereum → ORU_b) , dan perjalanan pulang-pergi akan memakan waktu lebih dari seminggu (karena jendela bukti kesalahan).
• rollup langsung → rollup - eth yang dikemas yang Anda terima di oru_bsebenarnya tidak dapat dipertukarkan dengan eth asli untuk oru_sebuah. ketergantungan jalur yang melewati jembatan yang berbeda memecahkan fungibilitas. misalnya, jika yang atau_sebuahjembatan dikeringkan, maka eth yang dibungkus yang Anda jembatankan ke orub akan tidak didukung, sementara eth asli di oru_b akan baik-baik saja. Fragmentasi likuiditas menyebalkan, jadi ini bukan sesuatu yang diinginkan pengguna. Dalam praktiknya, pengguna langsung menjembatani melalui penyedia likuiditas. Seseorang akan menghadap Anda ETH di ORU_bdan simpan dana Anda di oru_sebuah. mereka dapat menarik melalui jembatan asli dan menunggu, tetapi mereka akan dikenakan biaya mahal untuk risiko dan biaya modal yang tinggi yang mereka tanggung.

Anda mungkin berpikir bahwa zk rollups dapat menyelesaikan masalah ini dengan mudah, tetapi sebenarnya tidak. Implementasi yang naif masih memerlukan Anda untuk mengirimkan transaksi l1, yang lagi-lagi mahal dan biasanya cukup lambat (misalnya, karena waktu finalitas ethereum, waktu pembuatan bukti, seberapa sering bukti diposting dalam praktik, dll.).

pengguna tidak ingin berurusan dengan ini. mereka hanya ingin memiliki dana dan menggunakan aplikasi. pemutusan harus sepenuhnya diabstraksikan - aset harus dapat dipertukarkan dan bergerak dengan cepat, murah, dan aman.

ini adalah tempat dimana berbagi kontrak jembatan masuk. kontrak jembatan bersama membuka pintu bagi rantai yang menggunakannya untuk menjembatani langsung antara satu sama lain tanpa melalui l1.

token juga dapat menjadi dapat dipertukarkan di seluruh aggchain sebagai hasilnya. merentangkan eth dari r_sebuah → r_b atau r_c → r_bmembakar dan mencetak token yang sama. ini bukan aset yang dibungkus kunci dan dicetak. ini adalah eth asli. ini memungkinkan karena semua aset disimpan bersama dan diselesaikan melalui jembatan unifikasi. ini merupakan titik rintangan utama bagi l2s hari ini yang perlu ditangani.

Namun, perhatikan bahwa pengguna yang memegang ETH pada R_sebuahvs. r_bprofil risiko dapat berbeda jika rantai yang berbeda menggunakan pemeriksa yang berbeda (misalnya, mungkin Anda pindah dari rantai yang aman ke salah satu dengan bug sirkuit). profil risiko tetap sama di antara rantai yang menggunakan standar umum di sini (yang dalam praktiknya adalah norma saat ini). standar yang lebih seragam dan verifikasi formal hanya akan meningkatkan ini seiring waktu meskipun domain heterogen ditambahkan.

Bukti pesimistis

aggchains mengirimkan pembaruan status dan bukti ke node yang dipertaruhkan di lapisan agglayer yang mengatur mereka, menghasilkan komitmen untuk semua pesan, dan membuat bukti rekursif. Kemudian agglayer menghasilkan satu bukti zk aggreGate.iod tunggal (yang mereka sebut sebagai bukti pesimis”) untuk menyelesaikan ke ethereum untuk semua aggchains. Karena pengumpulan bukti di sini mengamortisasi biaya di seluruh rantai dengan sembarang banyak, dari perspektif biaya, praktis untuk mempostingnya ke ethereum untuk penyelesaian cepat secepat mungkin. Program bukti yang pesimis ditulis dalam kode rust reguler, menggunakan,zkvm sp1 Succinctuntuk kemudahan pengembangan dan kinerja tinggi.

bukti-bukti pesimis ini memperkuat:

• akuntansi antar rantai - membuktikan bahwa semua invarian jembatan dihormati (yaitu, tidak ada rantai yang dapat menarik lebih banyak token daripada yang telah disetor ke dalamnya).
• Validitas AggChains - membuktikan bahwa setiap rantai telah memperbarui statusnya dengan jujur, tanpa ekuivokasi rantai atau blok yang tidak valid.
• keamanan lintas-rantai - membuktikan bahwa pembaruan status yang merupakan hasil dari transaksi lintas-rantai dengan latensi lebih rendah dari ethereum adalah konsisten, dan dapat diselesaikan dengan aman ke ethereum l1. ini termasuk eksekusi atomik yang berhasil dari paket lintas-rantai baik secara sinkron maupun asinkron.

Dengan ini, agglayer memastikan penyelesaian terjadi di Ethereum hanya jika dan hanya jika kondisi di atas terpenuhi. Jika kondisi tersebut tidak terpenuhi, maka rantai yang bersangkutan tidak dapat menyelesaikan. Oleh karena itu, agglayer dapat memungkinkan koordinator (misalnya, sekuen pembangun bersama) untuk melewati pesan antar rantai dengan latensi rendah tanpa harus mempercayai koordinator tersebut untuk keamanan.

interoperabilitas lintas-rantai yang cepat & aman

aggchains dapat menggunakan jaminan yang disediakan di sini baik dalam pengaturan interoperabilitas asinkron maupun sinkron untuk mengekspresikan batasan pada validitas blok relatif terhadap rollup lainnya.

ini akan memungkinkan pengguna untuk mengirimkan bundel cross-chain yang harus berhasil dieksekusi secara atom pada kedua sisi. bukan hanya inklusi atomik. Anda benar-benar memaksa keadaan hasil dari mereka harus berhasil. ini adalah pasangan yang sempurna untuk meningkatkan persis apa yang kami sebut sebagai kekurangan dalam jaminan inklusi atomik dari sequencer bersama.

sumber: Petani Brendan, Blockchain yang teragregasi

mengambil contoh kita dari sebelumnya:

• Kami memiliki dua rollup (R_sebuahdan r_b) berbagi sequencer malas dan agglayer yang sama
• Saya mengirim bundel lintas-rantai untuk secara bersamaan membakar eth di r_sebuahdan mint eth di r_b
• seorang pembangun super membangun blok untuk kedua rantai melakukannya, yang disepakati secara bersama oleh penjadwal urutan
• kontrak jembatan pencetakan di r_bdapat dengan optimis mencetak eth tergantung pada keadaan r_sebuah (Dalam hal ini, berhasil mengeksekusi pembakaran ETH)
• blok-blok ini dan bukti-bukti ini dikirimkan ke agglayer, yang membuktikan bahwa kedua rantai beraksi dengan cara yang valid (baik secara mandiri maupun saling berkaitan) dan bahwa jembatan bersama itu digunakan dengan aman

Agar ini diselesaikan ke ethereum dengan sukses, kedua kaki dari bundel harus dieksekusi dengan benar. Jika salah satu pihak gagal, maka blok akan menjadi tidak valid dan tidak dapat diselesaikan. Itu berarti bahwa jika katakanlah sequencer bersama menandatangani blok di mana eth tidak terbakar pada r_atapi di-minted eth pada r_bJika itu terjadi, maka blok tersebut akan direorganisasi. Hal ini menjamin keamanan semua rantai dan mencegah tindakan lintas-rantai yang tidak jujur dari diselesaikan.

ada dua hal yang perlu diingat mengenai reorg ini:

• mereka akan sangat singkat karena mereka akan terdeteksi dan terbukti segera.
• mereka hanya bisa terjadi jika koordinator (misalnya, sequencer dan/atau builder) dari rantai yang Anda terhubung secara aktif bersifat jahat.

reorg ini seharusnya sangat jarang dan minimal karena poin di atas, tetapi karena ini aggchains akan memiliki kendali penuh atas rantai mana yang ingin mereka susun secara atomik dan di bawah asumsi kepercayaan apa. misalnya, r_sebuahmungkin menerima status rantai dari r_buntuk menggubah berdasarkan konsensus sequencer mereka, tetapi untuk r_cmungkin juga ingin bukti yang diajukan, dan untuk r_d Mungkin mereka ingin mereka mengamankan semua ketergantungan atom lintas rantai secara kripto-ekonomi. Setiap rantai dapat membuat pengorbanan mereka sendiri yang dapat disesuaikan di sini untuk latensi rendah dan liveness. Agglayer hanya menyediakan fondasi yang fleksibel secara maksimal dan berpendirian minimal bagi rantai untuk memiliki interaksi lintas rantai yang aman.

Anda juga dapat melihat di sini mengapa desain seperti itu dalam praktiknya tidak kompatibel dengan desain berbasis bukti kesalahan. Secara teori mereka bisa melakukan ini, tetapi dalam kasus itu akan mungkin untuk mengalami reorg yang sangat dalam. Dengan cepat membuktikan dan menyelesaikan semua rantai membatasi kasus terburuk menjadi sangat singkat, yang juga bertindak sebagai pencegah alami untuk setiap upaya jahat.

isolasi kesalahan untuk penyedia heterogen

Yang penting, agglayer secara unik memungkinkan rantai yang benar-benar heterogen. Anda dapat memiliki aggchain dengan vm kustom apa pun, prover, lapisan da, dll. sambil aman berbagi jembatan dengan semua orang.

bagaimana ini mungkin? alasan mengapa ini biasanya tidak dapat diterima adalah karena peserta yang cacat tunggal (misalnya, dengan bug sirkuit) biasanya dapat menipu jembatan dan mengosongkannya dari semua dana. Nah, disinilah bukti akuntansi antar rantai disebutkan di atas masuk. bukti ini memastikan bahwa invarian jembatan semuanya dihormati, sehingga bahkan dalam kasus pembuktian yang tidak sehat, hanya dana yang disetor ke rantai yang terkena dampak yang bisa dikuras. kesalahan benar-benar terisolasi.

netralitas yang kredibel

Jenis infrastruktur ini sangat diuntungkan oleh netralitas kredibel, itulah mengapa kode sumber sepenuhnya open-source untuk agglayer adalah wilayah netral.Dalam semangat yang sama, agglayer akan menggunakan eth sebagai token gas tunggal untuk membayar biaya agregasi bukti.

namun, tentu saja tidak sempurna. terutama pada awalnya, hal itu tidak akan sepenuhnya netral yang dapat dipercaya. kemungkinan ada peningkatan kontrak dalam perjalanan menuju kekekalan dan pengakuan sebagai kebaikan publik.

Namun, hal itu tidak harus benar-benar netral secara kredibel, tidak ada yang sempurna. (kita akan melihatnya lagi di bawah dengan rollups berbasis.) Dalam praktiknya, ini mungkin menawarkan visi bersaing teknis yang paling meyakinkan, dan mengambil sikap minimalis yang disengaja terhadap keterikatan dan ekstraksi sewa. Tujuannya adalah memungkinkan aggchains untuk mempertahankan kedaulatan sebanyak mungkin, sambil tetap dapat mengabstraksi komposabilitas lintas rantai yang terjamin kepercayaannya.

aggchains tidak memerlukan vm spesifik, lingkungan eksekusi, sequencer, lapisan da, token staking, token gas, atau tata kelola umum. rantai dapat pergi kapan pun mereka mau. tidak ada persyaratan bagi pendapatan bersama. Anda tidak perlu mendeploy sebagai l3 di rantai orang lain.

Alasan untuk meluncurkan L3 di atas L2 umum sebagian besar dalam pandangan saya adalah band-aids sementara arsitektur yang mirip dengan Agglayer sedang dibangun. Untuk lebih jelasnya, itu adalah alasan yang benar-benar valid untuk meluncurkannya hari ini. V1 Agglayer hanyalah kontrak jembatan bersama yang sederhana. V2 dengan agregasi bukti dan kemampuan untuk mendapatkan interop latensi rendah yang aman bahkan tidak hidup. Anda tidak dapat mengharapkan orang untuk menunggu selama bertahun-tahun ketika mereka memiliki urgensi untuk mengirimkan sesuatu hari ini yang akan memberi mereka distribusi tercepat.

proving waktu nyata

meskipun masih beberapa tahun lagi untuk menjadi praktis dalam setiap pengaturan low-latency, kita harus mencatat bahwa real-time proving juga berpotensi digunakan bersamaan dengan urutan bersama untuk keamanan cross-chain. Ini juga keren, jadi kita akan membahasnya secara singkat. Lebih spesifik, "real-time" proving merujuk pada waktu pembuktian yang lebih pendek dari waktu slot rantai yang bersangkutan. Mari kita pertimbangkan contoh jembatan cross-chain mint-and-burn lagi:

• kami memiliki dua rollup (r_satudan r_b) berbagi urutan yang sama yang malas
• Saya ingin menggunakan jembatan burn-and-mint antara ra → rb yang secara bersamaan membakar di ra dan mencetak di rb
• super builder menciptakan blok cross-chain yang mencakup sekelompok transaksi cross-chain ini. di dalam blok, builder menyertakan bukti transisi status yang sedang disertakan di rollup lainnya.

kami sudah memiliki jaminan pengurutan bersama dari inklusi bundel atomik sinkron, dan sekarang setiap kontrak dapat memverifikasi bukti dari status rantai lainnya untuk mengetahui bahwa itu akan dieksekusi dengan sukses.

untuk pembuktian waktu nyata, kita sebaiknya ingin waktu pembuktian hanya menjadi sebagian kecil dari total waktu slot, sehingga memaksimalkan 'jendela sinkronisasi.' ini adalah bagian dari waktu slot di mana Anda dapat memproses transaksi yang akan beroperasi secara sinkron melintasi blockchain, karena Anda perlu menganggarkan waktu yang cukup dalam slot untuk membuat bukti dan menempatkannya di dalam blok.

sumber: Justin Drake, pembuktian waktu nyata

Perhatikan bahwa kita akan secara implisit menggabungkan atau menggabungkan pembangun dan pembuktinya di sini. Ada insentif yang jelas bagi pembangun untuk mengoptimalkan kecepatan pembuktian sehingga mereka dapat membangun hingga detik terakhir dan memuat sebanyak mungkin di blok mereka.

sumber: Justin drake, pembuktian real-time

Jika insentif yang tinggi untuk pembuktian real-time benar-benar terwujud dalam beberapa tahun ke depan, kita juga harus mencatat bahwa ini tentu tidak ramah terhadap pembuktian terdesentralisasi. Pembuktian harus relatif terpusat karena mereka digabungkan atau digabungkan dengan pembangun.

ringkasan

universal synchronous composability sangat keren, tetapi tidak begitu jelas seberapa berharganya itu. internet semuanya asinkron dan kamu tidak akan pernah tahu itu. itu karena cepat dan kompleksitasnya diabstraksikan. itu semua yang pengguna inginkan.

Saya berharap bahwa sebagian besar nilai dari menggunakan sesuatu seperti agglayer tidak hanya berada di pengaturan segera. Sebaliknya, itu adalah fakta bahwa itu dapat bertindak sebagai bentuk abstraksi rantai cross-rollup. Membuat banyak rantai terasa lebih seperti satu dengan aspek yang diperlukan oleh pengguna (misalnya, aset asli yang lebih mudah diperdagangkan, fungsionalitas aplikasi lintas rantai yang native, interoperabilitas cepat, dll.).

komposabilitas sinkron jelas bernilai secara finansial (misalnya, memungkinkan likuidasi, arbitrase yang lebih efisien, refinancing yang lebih efisien menggunakan pinjaman kilat). Namun, mirip dengan bagaimana internet bersifat asinkron dan tetap berjalan dengan baik, tradfi tentu bersifat asinkron. Wajar untuk ingin menjadi lebih baik dari tradfi, tetapi kita harus jelas bahwa sinkronisitas universal bukanlah kebutuhan untuk eksekusi yang baik. Ada juga biaya nyata untuk membangun dan menyediakan infrastruktur sinkron.

Menurut pendapat saya, argumen terbaik yang mendukung kebutuhan USC adalah bahwa dalam praktiknya memang mengarah pada UX dan devex yang lebih baik. Ini tidak mungkin untuk menyangkal manfaat besar yang telah diberikan kepada ekosistem seperti Solana. Namun, ini semoga lebih merupakan masalah hari ini daripada masalah yang abadi.

Fakta sederhana dari masalah ini adalah juga agak sulit bagi siapa pun untuk bernalar pada tahap ini. Ini bukan biner "segala sesuatu di crypto sinkron" atau "semuanya asinkron." Saya pikir kita pada dasarnya perlu memecahkan dan tertarik pada yang terakhir, tetapi keduanya bisa ada secara ad hoc.

rollups berbasis ethereum

OK, jadi sekarang kita harus memiliki ide bagus tentang ruang solusi untuk mengatasi fragmentasi dalam rollup. Pertanyaan selanjutnya adalah bagaimana seharusnya kita melibatkan lapisan dasar dalam semua ini? Apa peran Ethereum di sini?

Kami akan menggunakan singkatan berikut di seluruh:

• BL - lapisan dasar
• Rollup berbasis BR
• pra-konfirmasi - pra-konfirmasi

kecuali dinyatakan lain, bl dalam pertanyaan yang akan kita bahas adalah ethereum, dan brs adalah brs ethereum. namun, konsep dasar berlaku secara luas karena Anda dapat meluncurkan brs di mana saja.

rollup berbasis vanilla

implementasi rollup awal beberapa tahun yang lalu sebenarnyadijadwalkan menjadi brs, tetapi adalah ditinggalkan demi pengusun terpusat untuk latensi rendah dan efisiensi tinggiapa yang sekarang kita sebut sebagai sekuensing berbasis, vitalik sebut sebagai "..."Anarki total"pada waktu itu. itu relatif tidak praktis dan tidak efisien sebelum evolusi infrastruktur pbs ethereum (dengan pembangun yang canggih)."

brs kemudian kembali menjadi sorotan pada bulan Maret 2023,di mana mereka didefinisikan sebagai berikut:

"Sebuah rollup dikatakan berbasis, atau L1-sequenced, ketika urutannya didorong oleh basis L1. Lebih konkretnya, rollup berbasis adalah salah satu di mana pengusul L1 berikutnya dapat, bekerja sama dengan pencari dan pembangun L1, tanpa izin memasukkan blok rollup berikutnya sebagai bagian dari blok L1 berikutnya. "

mereka seharusnya menawarkan manfaat berikut:

"Pengurutan rollup semacam itu — sekuensing berbasis — secara maksimal sederhana dan mewarisi L1 Liveness dan desentralisasi. Selain itu, rollup berbasis sangat ekonomis selaras dengan basis L1 mereka. "

Secara khusus, Anda mendapatkan keamanan real-time dari ethereum:

“Anda mewarisi ketahanan sensor dan kehidupan ethereum. Jadi tidak hanya Anda memiliki jaminan penyelesaian ethereum, tetapi Anda juga memiliki ketahanan sensor, ketahanan sensor waktu nyata, bukan yang tertunda dengan lubang pelarian, tetapi yang waktu nyata.”

Menjadi rollup berbasis adalah desain logis setelah Anda memilih lapisan dasar:

"Ethereum memaksimalkan dua properti ini, keamanan dan netralitas yang kredibel, ini hampir merupakan definisi rollup yang tepat ... Rollup adalah salah satu yang telah membeli asumsi keamanan Ethereum. Anda tidak menambahkan asumsi keamanan baru. Anda tidak jatuh ke tautan terlemah. Anda hanya menggunakan kembali asumsi keamanan yang ada. Dan dua adalah Anda telah menerima Ethereum sebagai platform netral yang kredibel, jika tidak, Anda akan memilih rantai lain. Dan sekarang Anda bisa bertanya pada diri sendiri mengapa tidak semua orang hanya menggunakan layer one sequencing? "

dalam bentuk yang paling sederhana, brs tentu bisa mencapai tujuan desain di atas. jika rollup tidak mengimplementasikan sequencer sendiri, maka secara implisit proposer ethereum saat ini yang akan memutuskan apa yang akan dimasukkan setiap 12 detik (waktu slot ethereum).

Namun, sekuensing berdasarkan tetap memiliki kekurangan, yang persisnya itu.Mengapa rollup biasanya menerapkan sequencer mereka sendiri:

• Preconfs cepat - Pengguna rollup tidak ingin menunggu 12S+ untuk blok Ethereum.
• Prekonf aman - terkadang blok Ethereum mengalami reorganisasi, sehingga pengguna harus menunggu lebih lama agar aman, hal ini tidak disukai oleh pengguna. Sequencer dapat memberikan prekonf yang tidak bergantung pada blok Ethereum yang belum final dan oleh karena itu tidak perlu mengalami reorganisasi bahkan jika Ethereum sendiri mengalami reorganisasi singkat.
• Posting batch yang efisien - sequencer dapat mengumpulkan banyak data, mengompresnya, dan secara berkala mempostingnya ke BL dengan cara yang dioptimalkan biaya (misalnya, memastikan penggunaan blob penuh).

berdasarkan rollups + preconfs

Jadi, apakah kita bisa memiliki kue kita dan memakannya juga? Masukkanberdasarkan preconfs.

kami akan menjelaskan intuisi di balik preconfs berbasis di sini secara relatif singkat sehingga kita dapat membandingkan brs + preconfs vs. rollups tradisional. nanti, kita akan kembali untuk menganalisis preconfs lebih lanjut secara umum (yaitu, baik br preconfs maupun bl preconfs pada transaksi ethereum l1).

Ide intinya adalah bahwa preconfs BR harus berasal dari pengusul BL. Untuk menyediakan preconfs, para pengusul ini harus memasang beberapa jaminan (misalnya, restaking) dan memilih kondisi pemotongan tambahan (yaitu, bahwa preconfs yang mereka berikan memang akan membuatnya onchain seperti yang dijanjikan). Setiap pengusul yang bersedia melakukannya dapat bertindak sebagai sequencer BR dan memberikan preconfs.

perlu dicatat bahwa para pengusul (yaitu, validator) sebenarnya diharapkan untuk mendeleGate.io peran ini dalam memberikan preconfs ke entitas yang lebih spesialis seperti "Gate.ioways". Memberikan preconfs akan memerlukan entitas yang relatif canggih, dan ethereum ingin menjaga agar para pengusul tetap tidak canggih.

Namun, diharapkan relai yang ada akan mengambil alih peran ini juga. Gate.ioway hanya akan berinteraksi antara pengguna dan relai, jadi menambahkan entitas independen lain hanya menambah kompleksitas dan latensi (meskipun latensi juga dapat diatasi dengan lokasi bersama). Relai sudah dipercaya oleh pembangun dan pengusul, jadi kami akan menambahkan persyaratan kepercayaan lain pada mereka dari pengguna di sini.

perhatikan bahwa meskipun validator saat ini berfungsi sebagai proposer blok ethereum, ada pertimbangan untuk melakukan upgrade di mana protokol itu sendiri akan langsung melelang hak proposal melaluiEksekusi LelangIni akan memungkinkan entitas yang canggih untuk membeli hak proposal langsung, sehingga menghindari kebutuhan bagi validator (para proposer saat ini) untuk memberi DeleGate.io kepada mereka seperti yang dipertimbangkan di sini.

Dalam hal apapun, titik pentingnya adalah bahwa preconf mana pun yang lebih cepat dari konsensus ethereum (12s) memerlukan pihak ketiga yang dapat dipercaya (ttp). Baik ttp Anda adalah validator yang ditransfer ulang, dipertaruhkan.Eksekusi Lelang pemenang, deleGate.iod Gate.ioway, atau apa pun - pada dasarnya tidak dapat memberikan keamanan ethereum real-time. Apakah Coinbase memberi Anda "preconf berbasis" sebagai pengusul Ethereum atau "preconf tradisional" sebagai sequencer rollup - Anda mempercayai Coinbase. Mereka juga dapat memasang ikatan beberapa ETH, tetapi dalam kedua kasus ini tidak tergantung pada keamanan konsensus Ethereum.

Kita harus memperhatikan bahwa setiap desain preconf berbasis tentu mengurangi tujuan BR yang kita mulai (kesederhanaan dan keamanan BL). Preconfs berbasis semakin kompleks, dan mereka tidak dapat memberikan jaminan keamanan waktu nyata dari ethereum.

Namun, Anda harus tetap mempertahankan kemampuan untuk memaksa transaksi secara langsung melalui transaksi bl jika preconfers ini offline atau mulai disensor. Jaminan ini dari ethereum seharusnya menjadi lebih kuat ketika daftar inklusidiimplementasikan.

Untuk BRS - TTP menyediakan preconfs cepat, dan BL memberikan keamanan akhirnya.

rollups non-basis + fallback berbasis

Sekarang mari kita pertimbangkan rollup tradisional (yaitu, yang tidak berbasis). Sequencer mereka sendiri (baik terpusat maupun terdesentralisasi) memberikan preconfs yang cepat. Kemudian, pengguna mereka mendapatkan keamanan ethereum penuh dengan keterlambatan. Ini meliputi kelangsungan hidup (pertumbuhan ledger + resistensi sensor) yang berasal dari beberapa jenis.inclusion yang dipaksaatauBL fallbackmehanisme.

Seperti yang saya catat di Apakah rollups mewarisi keamanan?:

rollup memiliki kemampuan untuk mengekspos aturan konfirmasi dengan properti keamanan yang setara dengan rantai induk mereka. Mereka dapat menerima properti ini paling cepat pada kecepatan konsensus rantai induk mereka (dan dalam praktiknya seringkali sedikit lebih lambat tergantung seberapa sering rollup mengirimkan ke rantai induk).

rollup juga dapat menyediakan aturan konfirmasi yang lebih longgar “jalur bahagia” (yaitu, pengurutan) untuk pengalaman pengguna yang lebih baik, tetapi mereka tetap mempertahankan cadangan dalam kejadian kegagalan. jika pengurut Anda berhenti, Anda dapat tetap bergerak.

perhatikan bahwawaktu untuk keamanan akhirnyaadalah variabel kunci untuk dioptimalkan di sini:

asumsi bahwa pengguna rollup dapat kembali ke kehidupan setara dengan rantai induk mengasumsikan bahwa Anda dapat memaksa inklusi tepat pada kecepatan blok rantai induk (misalnya, jika pengurut rollup sedang menyensor Anda, Anda dapat memaksa inklusi transaksi dalam blok ethereum berikutnya).

Dalam praktiknya, umumnya ada penundaan singkat. Jika Anda mengizinkan inklusi paksa langsung, Anda dapat mengeksposSensor Mev yang Menguntungkandi antara kompleksitas lainnya. Namun, ada desain yang dapat memberikan jaminan kehidupan yang hampir real-timedari rantai host (misalnya, mungkin dengan kecepatan beberapa blok rantai host daripada satu blok).

dalam semangat ini, Sovereign labs memiliki desainyang melakukan hal berikut ini:

• Urutan yang Diizinkan - Rollup mengatur sequencer yang diizinkan yang transaksinya diproses segera setelah dimasukkan ke dalam BL. Karena mereka memiliki kunci tulis pada status rollup, mereka dapat memberikan preconf yang andal lebih cepat daripada waktu blok BL.
• berbasis sekuensing - pengguna juga dapat mengirimkan transaksi langsung ke bl mereka, tetapi mereka diproses dengan penundaan blok n (di mana n cukup kecil). ini sangat mengurangi "waktu untuk keamanan akhir", dan bahkan mereka menyebut desain itu "berbasis sekuensing dengan konfirmasi lunak" karena itu! (perhatikan bahwa definisi brs ini akan bertentangan dengan definisi yang kami berikan sebelumnya, yaitu bahwa penyusun bl harus memiliki hak untuk mengurutkan br atau dideleGate.iod oleh mereka.)

Untuk non-BR - TTP menyediakan preconf cepat, dan BL memberikan keamanan akhirnya.

kenapa?

Seperti yang dapat kita lihat, kedua jalur yang dijelaskan di atas kemudian menghasilkan hasil yang efektif yang sama:

BRS ini dengan preconfs tidak lagi memberikan kesederhanaan atau keamanan real-time dari Ethereum. Jadi apa arti dari semua ini sekarang? Mengapa kita tidak hanya memperketat fallback pada rollup “tradisional”? Apa bahkan “based rollup” pada titik ini?

ini sebenarnya kembali ke sayaBukti tata kelolaposting dari tahun lalu di mana saya membahas kasus penggunaan fundamental untuk restaking khusus ethereum:

1) teknis (komitmen pengusul) - tidak ada jalan lain - jika Anda menginginkan komitmen yang dapat dipercaya terhadap pengurutan blok ethereum, itu harus berasal dari validator ethereum.MEV-Boost++adalah salah satu contoh aplikasi hipotetis yang bisa masuk ke dalam kategori ini.

2) sosial - saya melihat penyelarasan ethereum sebagai kasus penggunaan utama untuk sebagian besar aplikasi restaking saat ini, bukan penggabungan keamanan ekonomi atau desentralisasi. Ini membuat kita bisa mengatakan lihat, kami adalah proyek ethereum!” itu sebagian besar alasan mengapa rantai terus-menerus menyebut diri mereka ethereum l2sterlepas dari arsitektur.

Kita bisa memodernisasi ini dalam konteks menanyakan apa nilai dari 'br + preconfs' dibandingkan dengan 'rollup tradisional + fallback cepat'?

1) teknis (komitmen proposer) - ethereum brs dengan preconfs memiliki satu manfaat teknis mendasar - mereka dapat mendapatkan komitmen yang kredibel dari proposer ethereum saat ini mengenai inklusi dan urutan konten dari blok ethereum. ini potensial berharga untuk alasan yang sama persis mengapa kita potensial ingin sekelompok rollups untuk berbagi sequencer. jika proposer bl juga proposer br (yaitu, sequencer), maka mereka dapat memberikan jaminan inklusi atomik yang sama dengan bl seperti yang Anda dapatkan antara rollups yang berbagi sequencer. mereka memiliki monopoli atas kedua rantai. sekarang, seberapa berharganya ini? kita akan kembali ke itu dalam sedikit waktu.

2) sosial (keselarasan / netralitas kredibel) - suka atau benci, Ethereum alignmentIni adalah titik penjualan menjadi br. Aku akan jujur, aku tidak tahu banyak tentang taiko selain "mereka adalah orang-orang br," dan mungkin aku tidak akan tahu siapa mereka jika mereka bukan orang-orang br. Semua orang menginginkan beberapa pemasaran bersama yang bagus. Ada nilai menjadi orang-orang yang bergerak pertama di sini, tetapi saya curiga ini bukan nilai yang abadi dan tidak berlaku untuk banyak br potensial di masa depan. Demikian pula, kita semua pernah mendengar beberapa avss pertama, tetapi bisakah kamu sebutkan semua yang sekarang? Aku tidak bisa.

Pada tingkat yang lebih tinggi, Anda tidak akan mendapatkan semua rollups ethereum untuk memilih masuk ke (hipotesis) “optimisme shared sequencer” atau “arbitrum shared sequencer”. Namun, Anda memiliki peluang lebih baik untuk membuat mereka semua memilih masuk ke “ethereum shared sequencer.” Tidak ada token baru, tidak ada merek baru, tidak ada konsensus baru. Jika Anda berpikir bahwa berharga bagi semua l2 ethereum untuk bersatu dalam urutan, maka netralitas kredibel ini potensial menjadi titik schelling yang paling kuat untuk mencapai tujuan tersebut.

Netralitas kredibel ini kemungkinan paling berharga bagi pengembang rollups yang mencoba menarik pengguna lintas-ekosistem (misalnya, aplikasi dengan infrastruktur dasar seperti ens). Mereka mungkin ragu untuk menggunakan urutan optimisme jika itu akan mengasingkan pengguna arbitrum, atau sebaliknya.

kami akan membahas masing-masing ini lebih detail di bawah ini.

Netralitas yang kredibel

Masuk lebih dalam pada titik sosial itu, BRS sering dilihat sebagai opsi "Ethereum Aligned" secara maksimal. Mengesampingkan penilaian siapa pun tentang nilai ini, poin pentingnya adalah bahwa ini mengandaikan tingkat netralitas kredibel yang tinggi untuk setiap desain BR.

Sebuah br netral yang dapat dipercaya mudah untuk dirancang dalam kasus vanilla, tetapi seperti yang kita catat, tidak ada yang benar-benar menginginkannya. Oleh karena itu, preconfs secara perlu memerlukan proposer untuk memilih ke dalam kondisi slashing tambahan. Kondisi slashing tambahan ini mengharuskan proposer untuk menggunakan beberapa sistem tambahan (misalnya, mungkin restaking eigenlayer,Symbiotic, atau standar lain) untuk membuat komitmen. Rollup mungkin senang memilih "Ethereum Sequencer" yang netral secara kredibel secara abstrak, tetapi netralitas yang kredibel kemungkinan hilang jika Anda menggunakan proyek yang didanai secara pribadi, bahkan mungkin dengan token mereka sendiri.

Ada beberapa pertanyaan terbuka mengenai agunan di sini:

ukuran jaminan

Desain awal berasumsi bahwa pengusul secara pribadi harus memasang jumlah jaminan yang sangat tinggi pada urutan 1000 ETH. Masalahnya adalah bahwa pada dasarnya seorang pengusul selalu dapat mengingkari janji mereka untuk deleGate.io dan membangun sendiri blok, equivocating pada preconfs. Ini bisa sangat berharga, dan 1000 ETH nyaman di atas pembayaran tertinggi yang pernah diamati yang telah melalui MEV-Boost sejak awal. Kelemahannya adalah bahwa ini tentu saja menciptakan penghalang tinggi untuk masuk bagi pengusul yang lebih kecil, sementara yang lebih besar (misalnya, Coinbase) dapat lebih masuk akal memasang 1000 ETH sambil mendapatkan hadiah pada semua bobot saham mereka (>13% dari total eth yang dipertaruhkan) karena pendaftar dapat menempatkan satu obligasi untuk semua validator mereka. ada ide-ide lain untuk memungkinkan proposer dengan bond yang jauh lebih kecil, meskipun tentu saja datang dengan tradeoff. ruang desain di sini hanya tidak pasti.

penting untuk dicatat bahwaEksekusi Lelangakan mengurangi kekhawatiran ini, karena kita dapat mengasumsikan bahwa semua pengusul kemudian akan menjadi aktor yang canggih dengan mudah mampu melakukan hal ini.

sumber: Barnabé monnot, dari mev-boost ke epbs ke aps

Namun, bahkan operator besar pun enggan menempatkan jumlah besar, karena potensi masalah kelangsungan hidup yang mengakibatkan pemotongan (kegagalan kelangsungan hidup dari pihak operator, memberikan preconfs kami kemudian turun sebelum mereka dimasukkan dalam blok, adalah kegagalan keamanan yang sama bagi pengguna, dan perlu dikenai hukuman dengan keras).

jenis agunan

vanilla eth kemungkinan merupakan satu-satunya jaminan netral yang dapat dipercaya dalam situasi ini. Namun, secara alami akan ada keinginan untuk menggunakan aset yang lebih efisien secara modal (misalnya, steth). Ada beberapa ide untuk memiliki penjamin menangani konversi ini, sebagaimana yang dijelaskan oleh mteam di sini.

balei-balei

Tidak akan sangat "netral secara kredibel" jika "preconfs berbasis Ethereum" lebih seperti "preconfs berbasis Eigenlayer" atau "preconfs berbasis simbiosis." Ada tim yang berencana untuk pergi ke arah ini, tetapi itu bukan persyaratan ketat untuk menggunakan platform seperti itu. Dimungkinkan untuk membuat standar umum dan netral untuk digunakan semua orang, dan sistem seperti itu tampaknya lebih baik diposisikan untuk adopsi umum sebagai opsi yang paling berbasis.

adopsi standar barang publik akan diperlukan untuk desain berbasis preconf agar dapat dianggap 'netral dengan kredibilitas'.

pra-konfirmasi

inklusi vs. pra-konferensi negara

Sekarang kita akan membahas preconfs secara lebih rinci. Meskipun kita membahas jenis preconf tertentu sebelumnya (preconf br pada state), kita harus mencatat bahwa mereka adalah konsep yang sepenuhnya umum. Anda dapat menawarkan preconf pada transaksi bl serta br, dan Anda dapat menawarkan kekuatan preconf yang berbeda:

• Inklusi preconfs - komitmen yang lebih lemah bahwa suatu transaksi pada akhirnya akan dimasukkan ke dalam rantai onchain.
• state preconfs - komitmen terkuat bahwa transaksi pada akhirnya akan disertakan onchain dan jaminan keadaan hasilnya.

yang terakhir (pra-konfirmasi negara) tentunya adalah yang diinginkan pengguna dalam dompet mereka untuk ditampilkan:

saya menukar 1 eth dengan $4000 usdc dan membayar 0.0001 eth sebagai biaya

tidak termasuk preconfs:

transaksi saya mencoba menukar 1 eth dengan $4000 usdc dan membayar hingga 0.0001 eth dalam biaya akhirnya akan mendarat di rantai, tapi mungkin berhasil, mungkin gagal, kita akan lihat

Namun, perlu dicatat bahwa inclusion preconfs secara efektif dapat dipertukarkan dengan state preconfs dalam kasus tindakan pengguna yang diambil pada state yang tidak kontroversial (misalnya, transfer sederhana di mana hanya pengguna itu sendiri yang dapat membatalkan transaksi). Dalam hal ini, janji bahwa misalnya "transfer usdc milik alice ke bob akan dimasukkan dalam beberapa blok berikutnya" sudah cukup baik untuk wallet hanya menunjukkan kepada pengguna "Anda telah mengirim usdc Anda ke bob."

tidak mengherankan, komitmen yang lebih kuat (state preconfs) lebih sulit didapatkan. Pada dasarnya, mereka membutuhkan sebuah komitmen yang dapat dipercayadari entitas yang saat ini memiliki monopoli dalam mengusulkan blok (yaitu, kunci tulis pada status rantai). dalam kasus prekonfigurasi ethereum l1, ini selalu adalah pengusul ethereum l1 saat ini. dalam kasus prekonfigurasi br, ini mungkin adalah pengusul ethereum l1 berikutnya dalam tampilan ke depan br (sehingga menjadikan mereka pengusul saat ini untuk br), seperti yang akan kita lihat di bawah. pengusul dan pengurut umumnya adalah istilah yang dapat dipertukarkan, dengan istilah pertama lebih sering digunakan dalam konteks l1 dan yang kedua dalam konteks l2.

harga pra-konferensi

perbedaan besar lain yang perlu kita buat adalah jenis negara apa yang disentuh oleh preconfs ini:

• negara non-kontroversial - tidak ada orang lain yang membutuhkan akses ke negara ini (misalnya, alice ingin mentransfer usdc ke bob)
• negara kontroversial - yang lain ingin mengakses negara ini (misalnya, pertukaran dalam kolam amm eth/usdc)

preconfs adalah kendala pada blok yang akhirnya dapat diproduksi. semua hal lain sama, membatasi ruang pencarian untuk pembangun secara inheren hanya dapat mengurangi nilai potensial yang dapat mereka tangkap dari memesannya. itu berarti nilai yang lebih sedikit akan dikembalikan kepada pemberi tawaran. untuk menjadikannya kompatibel insentif, Gate.io perlu mengenakan biaya preconf ≥ mev potensial yang hilang dari membatasi hasilnya.

ini cukup sederhana ketika mekanisme eksekusi yang hilang adalah ~0 (misalnya, seperti dalam transfer usdc). dalam skenario ini, membebankan biaya tetap nominal bisa wajar. tetapi kita memiliki masalah besar - bagaimana cara menentukan harga preconfs pada kondisi yang kontroversial? Menentukan harga preconfs sebelum waktunya vs. tepat pada waktunya nampaknya akan membayar lebih sedikit. Dengan segala sesuatu yang sama, paling menguntungkan bagi pembangun untuk menunggu hingga detik terakhir mungkin untuk menangkap dan menentukan harga MEV dengan akurat.

Mari kita asumsikan meskipun ada permintaan pengguna yang cukup untuk preconfs cepat pada keadaan yang kontroversial (mempertimbangkan pencari yang canggih dan pengguna biasa), sehingga pada beberapa waktu akan ada harga penyelesaian yang menguntungkan bagi semua orang. Sekarang, bagaimana tepatnya Anda menentukan harga preconf untuk transaksi pada keadaan yang kontroversial yang sebenarnya bisa Anda masukkan kapan saja dalam 12 detik ke depan, berpotensi mengabaikan peluang yang lebih menguntungkan yang tidak akan lagi mungkin?

preconfs pada negara yang diperebutkan yang ditayangkan sepanjang blok akan bertentangan dengan cara pembangun membuat blok. menentukan harga preconfs secara akurat memerlukan estimasi dampak mev secara real-time dari memasukkannya sekarang daripada menundanya, yang berarti menjalankan dan mensimulasikan hasil yang mungkin. itu berarti Gate.io sekarang harus menjadi pencari/pembangun yang sangat canggih.

kami sudah mengasumsikan bahwa Gate.ioway dan relay akan bergabung. jika mereka perlu terus-menerus memasang harga preconfs, maka mereka juga akan bergabung dengan builder. kami juga menerima bahwa usc akan mempercepat penggabungan builder dan prover. tampaknya juga seperti itu Eksekusi Lelangakan menjual hak proposer secara langsung kepada aktor yang terampil (mungkin pembangun) yang mampu menentukan harganya.

ini menyatukan seluruh rantai pasokan transaksi ethereum l1 dan br menjadi satu kotak yang memiliki kunci tulis monopoli pada status semua rantai untuk periode tersebut.

kebijakan pemesanan layanan pra-konf tidak jelas (misalnya, apakah mereka selalu menjalankan fcfs atau mengurutkannya dengan cara lain). juga mungkin bagi Gate.io untuk menjalankan lelang atas semua pra-konf (misalnya, memungkinkan pencari untuk membidding pra-konf), meskipun tidak jelas seperti apa desain seperti itu, dan itu akan berarti latency yang lebih tinggi secara wajar.

masalah pertukaran yang adil

ada masalah pertukaran yang adil dengan preconfs di mana Gate.io tidak benar-benar memiliki insentif langsung untuk melepaskan preconf.

pertimbangkan contoh berikut:

• Gate.ioway saat ini memiliki monopoli selama 12 detik
• seorang pengguna mengirimkan permintaan transaksi pra-pengaturan tepat di awal slot (t = 0)
• Gate.ioway menunggu hingga t = 11,5 untuk melepaskan semua preconfs yang mereka buat selama slot mereka, dengan memberikan buffer 500ms untuk mendapatkannya semua dengan blok mereka. pada saat itu, mereka dapat memutuskan preconfs mana yang akan dimasukkan jika menguntungkan, dan mana yang akan dikecualikan.

dalam skenario ini, pengguna bisa saja membayar untuk preconf meskipun sebenarnya mereka tidak menerimanya sampai akhir slot. Gate.ioway juga bisa saja memutuskannya di akhir slot jika mereka memutuskan bahwa tidak menguntungkan untuk menyertakannya. penahanan oleh Gate.ioway ini bukan merupakan kesalahan yang secara objektif dapat diatributkantetapi hal itu dapat secara intersubjektif diatribusikan).

Sebenarnya, ada insentif bagi Gate.ioways untuk menahan preconfs sampai akhir.Di mana ada asimetri informasi, di situlah mev. menjaga transaksi tetap privat akan memungkinkan seorang pembangun untuk memiliki pandangan yang lebih mutakhir tentang keadaan dunia, sehingga mereka dapat lebih baik dalam menentukan harga risiko dan menangkap MEV. tidak ada konsensus tentang kumpulan preconfs yang diberikan kepada pengguna, jadi Gate.ioway tidak dapat dipertanggungjawabkan di sini.

Harus ada standar yang diterapkandan harapan untuk preconfermer untuk segera membicarakan secara publik semua preconfs. ini akan memberikan pengguna apa yang mereka inginkan segera dan memungkinkan orang lain melihat bahwa Gate.ioway memberikan layanan yang diharapkan. jika mereka gagal melakukannya di masa depan, maka pengguna tidak akan percaya kepada mereka dan membayar mereka untuk preconfs. reputasi Gate.ioway memiliki nilai. walaupun demikian, itu juga bisa menjadisangat berhargaberbuat tidak jujur di sini dan melanggar prakonferensi.

l1 basis lapisan prekonf

dengan poin prekonf umum sudah selesai, kita akan membahas nuansa prekonf l1 sekarang. meskipun tidak disebutkan sebelumnya, ada proyek-proyek yang membangun ini, dan interaksi mereka dengan prekonf br akan penting.

misalnya, Baut adalah salah satu protokol yang ingin memungkinkan pengusul Ethereum untuk membuat komitmen yang kredibel tentang konten blok mereka. Pengusul terdaftar dapat menjalankan sespan baut untuk menerima permintaan preconf dari pengguna, mengonfirmasinya, kemudian mengirim informasi ini ke relai dan pembangun yang dapat mengembalikan blok yang menghormati batasan ini (yaitu, sehingga mereka mengembalikan blok yang mencakup transaksi yang diberikan pengusul preconfs).

penting untuk dicatat di sini bahwaBaut v1yang dijelaskan di sini hanya mendukung inklusi transaksi sederhana preconfs untuk keadaan yang tidak kontroversial di mana hanya pengguna yang dapat membatalkan preconf. seperti yang kita bahas sebelumnya, ini adalah komitmen yang paling sederhana dan lemah untuk memberikan.

semua tim pra-konferensi ini memiliki ambisi yang lebih besar (misalnya, pra-konferensi negara, pelelangan blok sebagian, pelelangan slot atau slot sebagian), jadi apa yang menghalangi mereka?

• akuntabilitas - pelanggaran komitmen harus dapat dibuktikan di onchain untuk pemangkasan yang objektif. relatif mudah untuk membuktikan inklusi transaksi, tetapi tidak begitu jelas bagaimana menegakkan komitmen lain seperti lelang slot.
• persyaratan modal - memberikan komitmen sewenang-wenang berarti bahwa nilai pelanggaran komitmen bisa sangat tinggi secara sewenang-wenang. Gate.io kemungkinan besar akan akhirnya perlu bertaruh jumlah yang sangat besar (misalnya, ribuan eth) untuk menyediakannya. ini mungkin saja akhirnya akan terakumulasi, menguntungkan entitas terbesar (misalnya, perusahaan perdagangan besar atau coinbase) dan meninggalkan entitas yang lebih kecil.
• harga - ada banyak pertanyaan terbuka seputar bagaimana cara menentukan harga untuk sesuatu seperti pra-konferensi status yang ditransmisikan secara kontinu, bahkan jika kita memutuskan bahwa hal itu layak dan bernilai.
• partisipasi jaringan - ini mungkin merupakan titik paling penting dan fundamental. seperti yang kami sebutkan, hanya proposer saat ini yang memiliki write-lock pada state yang dapat memberikan komitmen seperti state preconfs. dalam teori, 100% proposer dapat memilih masuk ke dalam sistem ini dan meniru hal ini. dalam praktiknya, itu tidak akan terjadi.

mev-boost, produk yang lebih sederhana dengan catatan track record selama bertahun-tahun yang sangat menguntungkan untuk dijalankan, memiliki>92% partisipasiuntuk konteks (mungkin bahkan sedikit lebih tinggi karena ini tidak memperhitungkan bagiannya)tawaran minimum). layanan pra-konf baru pasti akan memiliki tingkat partisipasi yang lebih rendah. tetapi bahkan jika dapat mencapai rentang ~90%, ini tidak terlihat sebagai produk yang berguna bagi pengguna normal. Anda tidak dapat memberi tahu pengguna 10% dari waktu "oh maaf tidak ada preconfs tersedia saat ini, coba lagi nanti."

paling tidak ini terasa seperti pra-konflik negara hanya akan menjadi alat opsional bagi pencari dan pedagang yang canggih yang mungkin ingin mendapatkan komitmen lebih awal dalam blok ketika slot itu kebetulan memiliki proposer yang memilih masuk. itu mungkin berharga, tetapi tidak ada fragmentasi atau ux yang terbuka di sini.

prakonf lapisan l2

prekonf harus berasal dari para pengaju blok (itulah sebabnya mereka “bertumpu”). ini mengharuskan mereka untuk mempertaruhkan sejumlah jaminan dan memilih kondisi pemotongan tambahan (yaitu, bahwa prekonf yang mereka sediakan benar-benar akan masuk ke dalam rantai seperti yang dijanjikan). setiap pengaju yang bersedia melakukannya dapat bertindak sebagai pengurut br dan menyediakan prekonf.

Yang penting, br preconfs ini adalah preconfs negara bukan hanya preconfs inklusi. Ini dimungkinkan karena brs memilih untuk masuk ke desain di mana mereka memberikan monopoli sequencer berputar kepada bl proposers yang mendaftar untuk menjadi Gate.ioways.

hari ini, satu validator ethereum bertindak sebagai proposer untuk setiap slot, dan jadwal proposer selalu diketahui untuk epoch saat ini dan yang akan datang. Satu epoch terdiri dari 32 slot, sehingga kita selalu tahu 32-64 proposer berikutnya pada waktu tertentu. Desain ini bekerja dengan memberikan kekuasaan monopoli kepada sequencer aktif berikutnya (yaitu sequencer berikutnya dalam lookahead) untuk mengurutkan transaksi untuk brs yang memilih sistem preconf ini. Gate.ioways harus menandatangani untuk memajukan keadaan br chains.

perlu diketahui bahwa setiap pengusul (termasuk yang belum memilih untuk menjadi Gate.ioway) memiliki hak tetapi tidak memiliki kewajiban untuk menyertakan transaksi yang telah diberikan preconfs oleh sequencers (yaitu, pengusul yang telah memilih untuk menjadi Gate.ioway). Mereka dapat bertindak sebagai penyertakan selama mereka memiliki daftar lengkap transaksi yang telah diprekonfirmasi hingga saat itu (sequencer dapat membuat bl blob yang memiliki transaksi br dan menyebarkannya secara rahasia).

sumber: Sequencing Ethereum, justin drake

alur transaksi bekerja sebagai berikut:

1. Pengguna br mengirimkan transaksi mereka ke penjadwal berikutnya dalam tampilan ke depan (penyaji slot n+1 pada gambar di bawah)
2. sekuen langsung memberikan prakonfirmasi untuk keadaan hasil (misalnya, pengguna menukar 1 eth dengan $4000 usdc di br dan membayar 0.0001 eth dalam biaya)
3. Pada titik ini, setiap includer dapat menyertakan transaksi yang diurutkan (pengusul slot n melakukannya pada gambar di bawah)

sumber: Sequencing Ethereum, justin drake

jika inkluder lain tidak menyertakan pra-konfigurasi, maka sequencer yang memberikannya dapat dengan mudah menyertakannya onchain saat gilirannya sebagai proposer bl. misalnya, pada gambar di atas, katakanlah inkluder slot n memutuskan untuk tidak menyertakan pra-konfigurasi yang diberikan oleh sequencer slot n+1. maka sequencer slot n+1 akan bertanggung jawab untuk menyertakan semua pra-konfigurasi yang diberikannya selama slot n dan slot n+1 saat mengirimkan blok bl untuk n+1. ini memungkinkan sequencer dengan percaya diri memberikan pra-konfigurasi selama periode penuh antara mereka dan sequencer terakhir.

untuk menyederhanakan penjelasan di atas, kami hanya mengasumsikan bahwa pelopor l1 akan memenuhi peran ini sebelumnya. seperti yang dijelaskan sebelumnya, namun, ini kemungkinan besar tidak akan terjadi. ini akan membutuhkan entitas yang canggih untuk memperkirakan preconfs, menjalankan node penuh untuk semua br, memiliki perlindungan dos dan bandwidth yang cukup untuk semua transaksi br, dll. ethereum ingin menjaga validator sangat tidak terlatih, sehingga pelopor kemungkinan akan mengoutsourcing preconfs ke entitas lain dengan cara yang sama seperti mereka mengoutsourcing produksi blok l1 penuh melalui mev-boost hari ini.

Para pengusul dapat mengalihkan Gate.io ke Gate.ioways melalui mekanisme onchain atau offchain, dan ini dapat dilakukan sampai sebelum slot mereka. Seperti yang telah disebutkan sebelumnya, peran ini kemungkinan besar akan diambil alih oleh relay dalam praktiknya. Kemungkinan juga bahwa mereka perlu bergabung dengan pembangun juga.

sumber: Sequencing berbasis, justin drake

Seperti yang dijelaskan sebelumnya, hanya satu entitas yang dapat ditugaskan menjadi Gate.ioway pada satu waktu tertentu. Hal ini diperlukan untuk memberikan preconf. keadaan yang dapat diandalkan. Uis (misalnya, dompet seperti metamask) akan mencari siapa Gate.ioway berikutnya, dan mereka akan mengirim transaksi pengguna ke sana.

ethereum rollups - seberapa berdasarkan mereka akan?

dengan latar belakang yang cukup tersedia sekarang - apakah rollups ethereum harus didasarkan? sebenarnya ada dua pertanyaan tertanam di sini:

1. Haruskah banyak rollups ethereum membagi urutan?
2. jika ya, apakah itu harus menjadi pengurut berbasis (yaitu, melibatkan proposer ethereum bl dan infrastruktur mev sekitarnya)?

Pertama, penting untuk dicatat bahwa Anda dapat berbagi sequencer dengan rantai lain secara ad-hoc. Misalnya, pengusul Ethereum dapat mengurutkan satu blok untuk Anda jika mereka menawar tertinggi, maka beberapa konsensus BFT lainnya dapat mengurutkan blok Anda berikutnya jika mereka menawar tertinggi. Namun, ini masih membutuhkan rantai untuk sepenuhnya memilih ke dalam lelang bersama seragam ini yang dapat berjalan serentak dengan rantai lain ini, sehingga masih ada pengorbanan mengenai kontrol dan fleksibilitas (misalnya, waktu blok bersama). Hanya saja entitas sequencer yang menang bisa bergeser.

Bagaimanapun, mari kita asumsikan syarat 1 terpenuhi. Saya pikir kita memiliki bukti yang meyakinkan pada titik ini bahwa ada permintaan yang memadai untuk menggunakan sequencer bersama terdesentralisasi. Bahkan jika mereka kurang peduli tentang 'aspek bersama', saya pikir ada nilai yang sangat tinggi dalam dapat membeli sequencer terdesentralisasi layaknya layanan siap pakai (bahkan saya pikir ini adalah nilai terbesar di sini).

Sekarang, seharusnya sequencer bersama ini menjadi sequencer berbasis Ethereum?

teknis (komitmen pengusul)

Saya tidak melihat argumen teknis yang kuat untuk menggunakan sequencer berbasis Ethereum. Setiap interoperabilitas antara BR dan Ethereum L1 akan sangat terbatas karena ketidakmampuan untuk mengeksekusi dengan andal terhadap L1 (yaitu, tidak secara konsisten memiliki kunci tulis pada status L1), waktu blok yang lama (12 detik), dan fakta bahwa transaksi BR yang memang ingin berinteraksi dengan L1 kemudian harus melakukan reorg di sampingnya. Tidak ada makan siang gratis di sini. Ini tidak membuka kunci produk yang dihadapi pengguna yang berharga vs. sequencer bersama eksternal lainnya.

nilai utama yang saya lihat adalah bahwa menambahkan ethereum l1 ke dalam lelang kombinatorial yang lebih besar ini mungkin menghasilkan nilai aggreGate.io yang lebih tinggiMemungkinkan L1 untuk menangkap lebih banyak nilai. membawa logika ini ke ekstrem, kita mungkin seharusnya memasukkan segala sesuatu di dunia ke dalam lelang yang sama. lelang universal ini juga harus mengurutkan tiket konser Taylor Swift. aku belum sampai di situ.

ini hanya untuk menyoroti bahwa ada kompleksitas teknis dan sosial yang nyata dalam menciptakan dan mengadopsi semua orang ke dalam lelang bersama ini yang memiliki biaya nyata, yang dalam pikiran saya kemungkinan melebihi nilai tambahan teoritis yang diciptakan di sini. Anda dapat dengan mudah membangun desain teknis yang jauh lebih baik untuk menjalankan ini dari prinsip-prinsip pertama jika kita tidak mencoba memasangkannya di atas ethereum l1 (misalnya, hanya memiliki mekanisme konsensus cepat sederhana yang dibangun untuk tujuan ini). Belum lagi fakta bahwa lelang kombinatorial seperti itu akan menciptakan kompleksitas yang meledak secara eksponensial.

Dalam praktiknya, ada risiko yang berarti bagi saya bahwa ini mungkin benar-benar menjadi kontraproduktif secara serius bagi ethereum, karena arsitektur pra-konferensi ini tampaknya berpotensi mempercepat infrastruktur MEV ketika rantai pasokan ethereum sudah agak rapuh. Ini berisiko mengancam desentralisasi dan resistensi sensor jaringan - hal-hal yang membuatnya berharga pada awalnya.

sosial (netral yang dapat dipercaya)

Saya melihat argumen sosial yang valid untuk sebuah urutan berbasis Ethereum.

Seperti disebutkan sebelumnya, tidak diragukan lagi bahwa "Alignment" adalah penjualan untuk BR awal. Tidak apa-apa, tapi saya rasa ini tidak bertahan lama. Sangat keren menjadi BR pertama, tidak keren menjadi yang ke-8. Perlu ada nilai tambah lainnya.

Saya pikir bahwa netralitas yang dapat dipercaya dari pengurutan berbasis Ethereum mungkin nilainya. Ini kemungkinan argumen terkuat yang mendukung desain seperti itu setidaknya. Ada banyak rantai yang ingin mendapatkan pengurut terdesentralisasi siap pakai. Jika kita akhirnya dapat mendesain infrastruktur yang cukup di atas hal ini sehingga meningkatkan pengalaman pengguna lintas-rantai, maka lebih baik lagi. Dari proyek-proyek yang menginginkan desain seperti itu, saya bayangkan banyak dari mereka enggan untuk “memihak” pada protokol pihak ketiga mana pun. Seperti yang disebutkan sebelumnya, bayangkan Anda adalah sebuah rantai-aplikasi dengan beberapa infrastruktur umum dasar seperti ens, dan Anda menginginkan rollup. Anda tidak ingin memilih pengurut bersama arbitrum (hipotesis) dan menolak kelompok optimisme, atau sebaliknya.

Mungkin satu-satunya solusi untuk masalah koordinasi sosial di sini adalah memiliki pengatur ulang bersama yang netral secara kredibel, yang jelas merupakan kandidat terkuat untuk ethereum. Perhatikan bahwa ini menempatkan tingkat penekanan yang bahkan lebih tinggi pada poin yang saya buat sebelumnya mengenai netralitas kredibel - jika ini adalah nilai tambah utama dari layanan tersebut, maka itu harus menjadi tujuan desain yang sangat penting dalam menciptakannya. Ini tidak akan berhasil jika terlihat sebagai proyek pihak ketiga dengan motif laba-laba sendiri. Ini harus menjadi pengatur ulang bersama ethereum yang sebenarnya.

Harus diingat bahwa ada juga kritik yang masuk akal bahwa "netral" di sini adalah kode untuk "ethereum." Artinya, motivasi utamanya adalah untuk menguntungkan ethereum dan infrastruktur sekitarnya. Dan tentu saja, sistem seperti ini akan menguntungkan pihak-pihak tersebut. Ini akan berarti lebih banyak nilai yang diambil oleh aset eth, dan lebih banyak keuntungan bagi pembangun ethereum, relai, dan pencari.

rollups berbasis cepat

lapisan dasar cepat

sekarang kita harus memahami bahwa Anda dapat memiliki brs pada bl yang lambat seperti ethereum, Anda dapat menambahkan preconfs yang dapat dipercaya untuk ux yang lebih cepat, dan Anda bahkan dapat memastikan keamanan saat berpindah antar rantai melalui jaminan kriptoeconomik atau kriptografi.

Seperti dicatat, bagaimana jika kita hanya merancang hal ini dari awal. Tidak berurusan dengan hutang teknologi dan keputusan dari rantai yang ada. apa cara yang jelas untuk membangun benda itu ...

Sebelumnya, kita membahas bagaimana satu-satunya alasan teknis untuk menjadi br dengan prekonf untuk bl tertentu (misalnya, ethereum) adalah agar proposernya dapat memberikan komitmen yang dapat dipercaya pada waktu tertentu mengenai inklusi atomik synchronous dengan bl tersebut.

Namun, kami tidak serius membahas kemampuan untuk menjadi BR tanpa preconfs. Kami pada dasarnya membuang ini ke luar jendela karena Ethereum lambat dan pengguna tidak sabar.

Jadi mengapa kita tidak hanya menggunakan bl cepat untuk brs?

ini menyelesaikan hampir semua kasus tepi kompleks dan kekhawatiran yang kita miliki sebelumnya. kita tidak menginginkan kasus tepi aneh di mana Gate.ioways mengalami kegagalan kehidupan (yang memiliki hasil yang sama dengan kegagalan keselamatan di sini), kita tidak ingin mereka mundur dari preconfs yang dijanjikan (yaitu, kegagalan keselamatan), dan kita tidak menginginkan reorgs ethereum. inilah sebabnya mengapa konsensus ada.

layer-layer sudah mati, hidup layer-layer pengurutan!

sebagian besar percakapan mengenai urutan malas mempertimbangkan mereka sebagai urutan rollup yang kemudian membuang data nya pada beberapa lapisan data lainnya. misalnya, dua rollup pertama astria (FormadanApi) akan menggunakan celestia sebagai lapisan da mereka. Konsensus astria akan mensekuensikan rollup ini, kemudian akan meneruskan data mereka ke celestia.

Kombinasi ini sangat bagus karena keduanya saling melengkapi - Astria menyediakan seluruh infrastruktur sekuensing dan Celestia menyediakan verifikasi tanpa kepercayaan melalui Pengambilan sampel ketersediaan data (DAS).

namun, astria juga bisa digunakan untuk mengurutkan rollup yang asli untuk ethereum, bitcoin, solana, atau apa pun yang Anda inginkan. sebagai contoh, itu bahkan bisa diatur untuk digunakan sebagai preconfer untuk ethereum "brs with preconfs" (misalnya, alih-alih Gate.io terpusat, karena penjurusan malas pada dasarnya hanya relay yang terincentivasi dan terdesentralisasi).

Namun, setiap rantai adalah lapisan data availability (DA). Node penuh selalu dapat memeriksa DA. Ini adalah bagian dari kondisi validitas setiap rantai bahwa data tersebut tersedia, jadi konsensus selalu menandatangani bahwa data tersebut tersedia. Node ringan yang memeriksa tanda tangan mereka memiliki asumsi mayoritas jujur. Satu-satunya perbedaan adalah apakah rantai menyediakan opsi lain bagi klien ringan untuk mengambil sampel langsung untuk DA daripada meminta konsensus.

namun, seperti yang saya catat di Apakah rollups mewarisi keamanan?, rantai cepat seperti Astria secara teknis dapat menambahkan jalur lambat untuk DAS (untuk meningkatkan verifikasi), dan rantai lambat seperti Celestia dapat menambahkan jalur cepat untuk pengurutan (dengan asumsi kepercayaan mayoritas dan tanpa DAS), yang disebut "blok cepat persegi lambat.”

bergerak untuk mengintegrasikan secara vertikal lapisan khusus seperti urutan atau das akan lebih mempersempit perbedaan antara blockchain modular vs. terintegrasi. hal ini berlaku secara serupa untuk integrasi vertikal dari lapisan penyelesaiandengan menambahkanAkun verifier ZK ke lapisan dasar celestia.

Namun, ada nilai yang berarti dalam menjaga layanan-layanan ini terpisah daripada menggabungkannya. Ini adalah pendekatan modular yang memungkinkan rollup untuk memilih fitur-fitur yang mereka inginkan dari rak (misalnya, saya ingin membeli pengurutan terdesentralisasi dengan blok cepat, tetapi saya tidak ingin membayar untuk das, atau sebaliknya). Para peneliti telah menunjukkan bahwa mereka menginginkan das, tetapi pengguna sejauh ini hanya menginginkan blok cepat.

Layanan bundling seperti pada "blok cepat kotak lambat“akan sangat berpendapat dan terintegrasi. Ini pasti akan menambah kompleksitas dan biaya. Efek panjang slot padapermainan berdasarkan waktu (dan dengan demikian desentralisasi berpotensi) yang sekarang meresap di Ethereum juga menjadi pertimbangan.

lapisan dasar cepat vs. lambat + pra-konfigurasi

tapi Anda juga dapat menggunakan astria sebagai bl untuk rollups. Sequencer bersama bisa dianggap sebagai bls yang dioptimalkan untuk brs mereka sendiri.

ketika bl Anda cepat, br Anda tidak perlu preconfs karena hanya mendapatkan konfirmasi cepat secara otomatis! kemudian rollup Anda sebenarnya mendapatkan keamanan real-time dari bl Anda, tidak seperti br + preconfs yang secara tidak langsung kehilangan ini.

brs tanpa preconfs sebenarnya adalah cara paling logis untuk membangun rollup. itulah mengapa rollup saat ini semuanya dimulai dari sana:

Jelas bahwa BL dengan blok cepat memperbaiki sebagian besar masalah kami di "Based rollups + preconfs." Sequencer bersama secara alami dibangun lebih dari pendekatan prinsip pertama "Hai pengembang aplikasi hanya ingin meluncurkan rantai yang cepat, andal, dan terdesentralisasi - bagaimana cara memberikannya kepada mereka?" mencoba menambahkan preconfs setelah fakta ke lapisan dasar yang lebih lambat seperti Ethereum menghasilkan kompleksitas yang telah kami jelaskan di atas.

kita semua sedang membangun hal yang sama

modularitas tidak dapat dihindari

jadi, kita melihat bagaimana kita dapat menggabungkan rantai modular Gate.io kembali bersama, menyediakan komposabilitas sinkron universal (usc). tentu ada kompromi, tetapi mereka memperkenalkan kembali tingkat kesatuan yang bermakna sambil mempertahankan fleksibilitas yang jauh lebih besar daripada menggunakan satu mesin keadaan. juga sangat meyakinkan bagi saya bahwa komposabilitas asinkron adalah semua yang kita butuhkan untuk sebagian besar kasus penggunaan. kita membutuhkan latensi rendah, kinerja, dan ux yang baik. internet bersifat asinkron dan itu bekerja cukup luar biasa mengabstraksikan semua itu. komposabilitas adalah nilai tambah besar dari kripto, tetapi komposabilitas ≠ keselarasan.

Selain manfaat fleksibilitas dan kedaulatan, kebanyakan orang akan setuju bahwa kita pada akhirnya akan memerlukan banyak rantai untuk skala apapun. Hal ini berarti kita akan berakhir dengan banyak sistem yang perlu kita satukan, sehingga arah modular tidak dapat dihindari di sini.

Ethereum + Preconfs → Solana?

Sekarang, mari kita membandingkan akhir permainan di sini. Khususnya kita akan membandingkan akhir permainan solana vs. akhir permainan ethereum jika ini mengikuti jalan memaksimalkan kesatuan dan pengalaman pengguna dengan rollups berbasis + preconfs.

Dalam visi ini, kami memiliki sekelompok brs ini menggunakan sekuen berbasis ethereum. Gate.ioways terus-menerus menyiarkan proposer-promised (yaitu, tanpa bobot konsensus) preconfs ke pengguna dengan latensi rendah, kemudian proposer ethereum mengkomitmen mereka ke dalam blok penuh sekali-sekali. Ini mungkin terdengar familiar karena itu hampir sama dengan apa yang kami deskripsikan untuk solana sebelumnya dengan shred streaming!

Jadi, apakah ini hanya Solana yang lebih rumit? Perbedaan besar di sini terletak pada waktu slot:

Ethereum mencoba menambahkan ini di atas rantai yang lambat jelas menimbulkan masalah pada pandangan pertama:

• konsensus ethereum terlalu lambat bagi pengguna, jadi satu-satunya cara untuk mendapatkan pengalaman pengguna yang cepat secara kredibel adalah dengan prekonfs yang dijanjikan oleh proposer secara sukarela. Engsel utamanya saat ini adalah agregasi tanda tangan sebagai akibat dari ukuran set validator yang besar.MaxEBdan peningkatan agregasi tanda tangan bisa membantu di sini).
• ini mengakibatkan monopoli pengusul yang jauh lebih lama, memberikan insentif yang lebih tinggi dan kebebasan untuk menangkap lebih banyak mev dengan bertindak tidak jujur (misalnya, menahan preconfs).
• jika Gate.ioways mulai menunda atau menahan preconfs, maka kasus terburuk bagi pengguna kembali bergantung pada waktu slot ethereum. Bahkan jika produsen blok Solana menghentikan pembangunan blok berkelanjutan dan streaming dalam monopoli yang dialokasikan (karena sangat mungkin rasional bagi mereka untuk melakukannya sampai batas tertentu dengan alasan yang sama persis) Kemudian, dalam kasus terburuk, bergantung pada konsensus yang berputar dengan cepat. Monopoli empat slot saat ini diperlukan untuk keandalan jaringan.
• Dalam praktiknya, kemungkinan hanya ada sedikit Gate.ioways, setidaknya pada awalnya, yang menghasilkan operator yang lebih terpusat dibandingkan dengan blockchain seperti Solana.
• persyaratan jaminan yang mungkin sangat tinggi untuk para pengusul (mengingat ruang desain masih dalam tahap pengembangan).
• kekhawatiran tentang masalah kehidupan yang sangat mahal di sini (karena masalah kehidupan operator yang menyebabkan preconf yang jatuh menjadi kegagalan keamanan bagi pengguna, dan dengan demikian harus dipotong secara signifikan).

semua ini diatasi dengan konsensus yang cepat. semua sistem ini sebenarnya adalah alasan mengapa kita membuat sistem bft pada awalnya. jadi mengapa ethereum tidak membuat konsensusnya menjadi lebih cepat? apakah ada beberapa kompromi yang kurang jelas dengan memiliki waktu blok lapisan dasar yang sangat rendah?

Untungnya saya tidak ada yang lebih baik untuk dilakukan selain menulis esai tentang apakah waktu blok yang lebih singkat itu baik. Kekhawatiran besar dengan waktu slot yang lebih singkat terkait dengan sentralisasi validator dan operator. Secara khusus, ada kekhawatiran mengenai interaksi waktu slot yang singkat dengan permainan waktu:

Kami melihat permainan waktu berkembang di ethereum sudah. Para pengusul mengajukan blok lebih lambat di slot mereka, membuat lebih banyak uang dengan merugikan orang lain. Relai juga menawarkanpermainan timing sebagai layanan“ dimana mereka juga menunda blok-blok lebih lanjut di dalam slot:

sumber: Data selalu

permainan berdasarkan waktu menjadi topik diskusi yang besar di platform yang agak terkenalPodcast Justin vs. toly banklessdari beberapa minggu yang lalu:

misalnya, katakanlah kamu 100ms lebih cepat dari yang lain

jika Anda memiliki slot 1s, Anda dapat menghasilkan 10% lebih banyak dari orang lain

jika Anda memiliki slot 10s, Anda dapat menghasilkan 1% lebih dari orang lain

— jon charbonneau ( @jon_charb)4 Juni 2024

justin sebagian besar berpendapat bahwa permainan waktu akan menjadi masalah, dan hadiah tambahan akan selalu relevan. toly sebagian besar berpendapat bahwa permainan waktu tidak akan menjadi masalah, dan bahwa hadiah tambahan yang diperoleh dari ekstraksi mev tambahan tidak cukup untuk dikhawatirkan.

Saya pribadi merasa sulit untuk mengabaikan pentingnya waktu bermain di sini:

• kita sudah melihatnya dalam praktek di ethereum hari ini. Argumen Solanaini terjadi hanya karena mev menjadi terjadi secara sosial di ethereum sebelumnya, tetapi ini tidak meyakinkan ketika adaProtes publik yang kuat terhadap permainan waktu yang terlalu dini yang sejak itu berubah menjadi penerimaandari realitas baru ini untuk dirancang sekitar.
• hadiah mev sangat signifikan - kita sudah membicarakannya miliaran dolar dalam pembayaran MEV di sini, bukan uang receh di bawah bantal sofa. Bahkan menghasilkan "hanya beberapa persen lebih banyak" untuk ini adalah jumlah uang yang sangat besar.
• meskipun Anda tidak percaya bahwa staker cukup sensitif terhadap hasil secara margin,operator sebenarnya menjalankan bisnisdan itu langsung masuk ke lini bawah mereka.
• Lebih mudah bagi solana untuk mengandalkan pemegang saham besar yang altruistikmisalnya, yayasan dan investor besar) sebelumnya pada tahap awal siklusnya, tetapiitu tidak dapat dipertahankan karena jaringan semakin terdesentralisasi.

Saya jelas berpikir bahwa ada banyak nilai dalam arah yang diambil oleh solana dan ethereum. Jika tidak ada yang lain, kita akan melihat semuanya bermain dalam praktiknya. Secara strategis, saya juga berpikir bahwa itu masuk akal bagi ethereum untuk mengandalkan apa yang membuatnya berbeda di sini. Maksimalkan desentralisasi sebagai cara untuk mencapai resistensi sensor terhadap keadaan yang bermusuhan. Ethereum telah membuat banyak pengorbanan untuk menjaga protokol yang sangat terdesentralisasi karena itu adalah kebutuhan untuk permainan jangka panjang. Ethereum memiliki keragaman klien yang tak tertandingi, distribusi kepemilikan jaringan, pemangku kepentingan ekosistem, desentralisasi operator, dan lain-lain. Jika (dan kemungkinan besar ketika) solana menghadapi tekanan sensor yang serius di masa depan, akan semakin jelas mengapa ethereum membuat keputusan seperti itu.

Preconf.wtf baru saja terjadi di Zuberlin minggu lalu, dan mungkin tidak mengejutkan semua orang berbicara tentang preconfs dan rollup berbasis. Dan itu semua sangat keren. Tapi saya pribadi menemukan Pembicaraan Vitalikpadadaftar inklusi satu bit per attesterdan pembicaraan barnabé tentangBebani proposer pelaksanaan yang lebih (dari mev-boost ke epbs ke aps)menjadi yang paling penting bagi masa depan ethereum.

sumber: Barnabé monnot, Dari mev-boost ke epbs ke aps

Pertemuan pra-konferensi dan percakapan berbasis rollup baru-baru ini mulai mendapatkan momentum, dan saya pasti masih berada di sisi yang lebih berhati-hati. Vitalik terkenal menetapkan di bawah iniEndgame:

Namun, kami telah bergerak cukup jauh ke dalam "produksi terpusat" tanpa menerapkan perlindungan anti-sensor yang lebih kuat seperti daftar inklusi. Pada dasarnya Ethereum adalah setengah di baris bawah gambar di bawah ini. (Saya katakan setengah karena sensor sebenarnya tidak hitam dan putih, dan Ethereum hanya memiliki "sensor lemah", yaitu, sebagian besar tetapi tidak semua blok disensor, jadi Anda mungkin menunggu sebentar, tetapi kemudian Anda akan dimasukkan):

sumber: Bukti tata kelola

Secara empiris, rantai pasokan MEV L1 Ethereum saat ini menyensor lebih banyak blok secara real-time daripada L2 ini dengan pengurutan terpusat.

l2s sudah bisa mendapatkan cr akhir l1 (yang masih sangat bagus) tanpa menjadi basis. basis preconfs tidak mendapatkan keamanan waktu nyata dari protokol ethereum, mereka mendapatkan keamanan waktu nyata dari beberapa penyedia infrastruktur yang relatif terpusat di sekitarnya. Untuk cr waktu nyata yang lebih baik, pilihan terbaik kemungkinan adalah outsourcing pengurutan ke jenis pengurut terdesentralisasi yang menjalankan konsensus bft sederhana. Ini akan jauh lebih kuat daripada mengcentralisasi banyak rantai menjadi bottleneck yang saat ini relatif terpusat. Situasi ini mungkin membaik dengan perubahan seperti lelang eksekusi dan daftar inklusi, tetapi itu belum tepat di tikungan.

Dengan mempertimbangkan semua ini, bagi saya tidak jelas bahwa memperluas ketergantungan pada infrastruktur mekanisme ekstraksi nilai (MEV) ethereum l1 kemudian memperkuatnya untuk l2 adalah ide bagus pada tahap ini ketika hanya sedikit orang yang membangun dan meneruskan semua blok ethereum, sebagian besar blok ethereum yang bebas sensor saat ini bergantung pada satu pembangun (titan), dan belum ada alat CR yang telah diimplementasikan dalam protokol. Ini terasa sangat akselerasionis di titik yang rapuh. Ethereum tentu harus bekerja untuk meningkatkan pengalaman pengguna (UX) dari l2, tetapi bukan dengan mengorbankan semua sifat dasar yang kita inginkan pada awalnya.

kesimpulan

kita semua sedang membangun hal yang sama.

Yah, agak begitu. jelas hal-hal ini tidak semuanya secara harfiah sama persis. akan selalu ada perbedaan praktis antara sistem-sistem ini. Namun, mega-trend menyeluruh dalam kripto jelas bahwa kita semua sedang menuju pada arsitektur yang semakin mirip.

perbedaan teknis yang halus di antara mereka dalam praktiknya dapat memiliki implikasi yang berarti untuk di mana mereka berakhir, dan kita tidak dapat meremehkan seberapa besar peran ketergantungan jalur dalam sistem-sistem ini bahkan ketika mereka konvergen menuju tujuan akhir yang serupa.

Selain itu, cukup sulit untuk merenungkan tentang beberapa hal ini.Seperti yang diungkapkan oleh Vitalik:

“Satu catatan peringatan yang saya miliki untuk aplikasi adalah bahwa menurut saya dari perspektif teknis yang murni, sebenarnya saya pikir sangat ringan dan kami benar-benar mampu mengatasinya dengan sedikit kemungkinan terjadinya kesalahan teknis... tetapi dari perspektif ekonomi, ada banyak peluang bagi hal-hal untuk salah jalan...

seperti eip-1559 kita bisa mencari tahu dengan teori. kita pergi ke beberapa konferensi ekonomi yang menyenangkan dan belajar tentang bahaya lelang harga pertama dan betapa buruknya, dan mencari tahu bahwa lelang harga kedua tidak dapat dipercaya, dan kemudian menemukan hey mari gunakan mekanisme harga tetap yang terlokalisasi dalam setiap blok, dan kita bisa melakukan banyak hal dengan mikroekonomi.

Tetapi aps tidak seperti itu kan. Dan pertanyaan apakah aps akan mengarah ke citadel atau jane street atau justin sun atau siapa saja yang menghasilkan 1% dari semua blok ethereum atau 99% sangat sulit, mungkin tidak mungkin untuk dihitung dari prinsip-prinsip pertama.

jadi hal yang ingin saya lihat pada saat ini adalah eksperimen langsung... bagi saya pribadi, delta antara hari ini dan saya merasa sangat nyaman dengan aps adalah aps yang berhasil dijalankan di atas ethereum l2 yang memiliki jumlah nilai, aktivitas, komunitas, dan perselisihan aktual yang sedang terjadi dan itu bertahan selama setahun, mungkin lebih lama selama setahun, dan kita benar-benar dapat melihat beberapa konsekuensi langsung.

jadi ya, aku juga tidak tahu apa yang akan terjadi. kita harus menunggu dan melihat saja. dalam hal apapun, saat kita semua menuju ke arah apa pun yang menjadi tujuan akhir ini, kita memiliki lebih banyak kesamaan daripada perbedaan, jadi mari pastikan untuk menyenangkan...

disclaimer:

1. artikel ini dicetak ulang dari [ dba]. meneruskan judul asli 'kita semua sedang membangun hal yang sama'. semua hak cipta milik penulis asli [jon charbonneau]. jika ada keberatan terhadap cetakan ini, silakan menghubungi Belajar Gate.iotim, dan mereka akan menanganinya dengan segera.
2. penyangkalan tanggung jawab: pandangan dan opini yang diungkapkan dalam artikel ini semata-mata milik penulis dan tidak merupakan saran investasi apa pun.
3. terjemahan artikel ke dalam bahasa lain dilakukan oleh tim belajar Gate.io. kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel yang diterjemahkan dilarang.