📣 Gate.io Post Kripto Observer Panggilan untuk Bertindak!
📈 Bagikan Berita Kripto & Menangkan Hadiah Besar Setiap Minggu!
💓 Jangan ragu, bergabung sekarang ⏬
1. Bagikan berita kripto harian, tren pasar, dan wawasan ke dalam kiriman Anda.
2. Masukkan #CryptoObservers# untuk berpartisipasi dengan sukses.
🎁 10 pengamat "Kripto" beruntung akan mendapatkan $20 poin setiap Jumat!
📌 Daftar pemenang akan diumumkan setiap Jumat, dengan hadiah yang didistribusikan pada hari yang sama.
📌 Catatan: Posting mungkin hanya mencakup tag #CryptoObservers# ; jika tidak, tidak ada reward.
💪 Pengamat Kripto
IOSG: Apa kebutuhan Unichain? Apakah Informasi menguntungkan atau informasi tidak menguntungkan?
Penulis IOSG Ventures
Pendahuluan
Selama bertahun-tahun, Uniswap terus mendorong reformasi fitur dan inovasi untuk membuat pertukaran lebih ramah pengguna dan adil. Misalnya, kami melihat Uniswap Mobile versi mobile, Fillers Network di UniswapX, ERC-7682 untuk standar niat lintas rantai yang seragam, dan hook yang akan segera dibuka di Uniswap V4 untuk kustomisasi kolam AMM, dan sebagainya.
Pada 10 Oktober, Uniswap mengumumkan Rollup optimis mereka secara keseluruhan, Unichain. Rantai ini bertujuan untuk menjadi pusat likuiditas satu atap di ekosistem Superchain, memberi para pedagang pengalaman pertukaran yang hampir instan dan spread yang lebih rendah, sambil memaksimalkan privasi dan integritas peserta MEV dalam prosesnya, menggunakan TEE dalam prosesnya. Meskipun visi ini mengesankan, pengguna mempertanyakan perlunya L2 lain, dengan beberapa, termasuk Vitalik, mengomentari Unichain = "Ini berlaku untuk salinan Uniswap di setiap Rollup". Dengan kata lain, dia berpendapat bahwa meluncurkan klon Uniswap pada rantai baru sebenarnya memiliki tujuan yang sama dengan meluncurkan Unichain itu sendiri. Jadi, apakah Unichain baik atau buruk? Artikel hari ini akan mengeksplorasi arsitektur Unichain dan memahami "kebutuhan" Unichain.
1.1 Rollup Boost: Pemisahan Sequencer Proposer (SBS) dari Pembangunan Blok (Block Building) adalah kunci untuk menyelesaikan masalah MEV. Sebelum MEV Boost, Ethereum mengalami risiko audit dan masalah pengalaman pengguna yang buruk. Karena persaingan sengit antara penelusur yang memasukkan pesanan yang didorong oleh keuntungan, pengguna menghadapi biaya transaksi yang tinggi dan masalah transaksi yang tertunda. Untuk mengatasi masalah ini, flashbot membangun MEV-boost. MEV Boost mengumpulkan peran pembangun blok dan proposer dengan memperkenalkan relay, dan menyerahkan blok yang paling menguntungkan kepada proposer untuk ditandatangani, sehingga memisahkan peran pembangun blok dan proposer. Desain ini secara efektif memecah ekstraksi MEV dan mendemokratisasi keuntungan MEV antara validator dan pembangun profesional.
Konsep Rollup Boost mirip dengan MEV Boost, di mana L2 yang menggunakan SBS (Sequencer Builder Separation) dapat memisahkan proses pembangunan blok dari mesin eksekusi sequencer melalui sistem yang disebut "Block Builder Sidecar". Secara singkat, ada 4 komponen utama dalam sistem ini: • OP-node • OP-geth • Sidecar / Blockbuilder Sidecar • External Block Builder Berikut adalah diagram arsitektur optimism, di mana kita dapat melihat node sequencer (juga dikenal sebagai op-chain) terdiri dari Op-geth dan Op-node.
Untuk membedakan peran pembangun blok dan pengusul dalam sorter, sebuah komponen bernama Sidecar ditambahkan. Sidecar memungkinkan node OP menerima blok dari pembangun eksternal, sehingga menciptakan pasar antara pembangun blok dan pengusul. Prosesnya sebagai berikut: 1. Node OP mengirim pembaruan ke sidecar. 2. Sidecar sebagai perantara meneruskan pembaruan ke op-geth. 3. Ketika node OP meminta blok dari OP-geth, sidecar akan mengintersep permintaan tersebut. 4. Kemudian, sidecar akan meneruskan permintaan tersebut ke pembangun blok eksternal yang merupakan 'celah' yang dapat ditawar dan diperlombakan oleh pembangun eksternal. 5. Setelah menerima blok eksternal/pemenang, sidecar akan mengirimkannya ke node OP. 6. Jika tidak ada blok yang diterima, sidecar akan meneruskan blok yang dihasilkan secara lokal. Manfaat utama dari pembangun blok sidecar adalah tidak perlu mengubah klien rantai OP saat melakukan peningkatan, serta memungkinkan aturan pengurutan transaksi menjadi lebih fleksibel, sederhana, dan dapat diperiksa. Namun, karena ditambahkan perantara (sidecar), mungkin terjadi sedikit keterlambatan.
1.2 Rollup Boost: Sequencer Proposer Separation (SBS) Rollup Boost memastikan integritas transaksi dengan memperkenalkan lingkungan eksekusi tepercaya (TEE) ke dalam proses pembangunan blok, menjadikan proses tersebut lebih lanjut. Berkat kemajuan perangkat keras terbaru seperti Intel TDX, kinerja real-time menjadi mungkin. Bagi yang tidak akrab dengan TEE, itu adalah area aman di prosesor atau perangkat keras yang meningkatkan privasi dengan mencegah entitas yang tidak sah mengakses data eksternal. Sementara itu, TEE mempertahankan tingkat integritas yang tinggi karena kode di dalam TEE tidak dapat diubah atau digantikan.
Dalam konteks Rollup Boost, Unichain akan menggunakan pembangun TEE untuk mengurangi risiko kebocoran MEV. Ini berarti bahwa ketika bundel atau transaksi dikirim ke pembangun blok TEE, integritas TEE dapat menjamin bahwa urutan transaksi yang sampai ke pembangun tidak akan terpengaruh oleh pihak eksternal yang mencoba mengekstrak lebih banyak MEV.
Selain itu, TEE menyediakan perlindungan pemulihan tanpa kepercayaan yang dapat melindungi pengguna dari dampak transaksi yang gagal, karena TEE dapat menjalankan simulasi dan akan dideteksi dan dihapus sebelum memproses transaksi pemulihan apa pun. Ini tidak hanya meningkatkan efisiensi AMM (karena tidak akan ada transaksi gagal yang lolos), tetapi juga meningkatkan pengalaman pengguna secara keseluruhan, terutama saat volume transaksi besar.
Untuk meningkatkan transparansi dalam proses pengurutan dan pembangunan blok, bukti eksekusi akan dipublikasikan kepada pengguna setelah blok dibuat. Bukti ini sangat penting untuk memverifikasi urutan prioritas, konsep ini akan dijelaskan dalam paragraf berikutnya.
1.3 Flashblock dan Konstruksi Blok Verifiable Rata-rata waktu blok Ethereum adalah 12 detik, sangat lambat, tidak dapat memenuhi kebutuhan pengalaman transaksi yang dapat diterima saat ini. Selain itu, waktu blok yang lambat membuat jaringan menghadapi lebih banyak kesempatan MEV, dan membuatnya rentan terhadap kemacetan jaringan pada serangan transaksi sampah. L2 bertujuan untuk meningkatkan skalabilitas Ethereum dengan mengikat transaksi di bawah rantai dan mengajukan bukti kebenaran perhitungan. Untuk memberikan pengalaman transaksi yang lebih lancar, tujuan Unichain adalah mencapai waktu blok 250ms. Namun, untuk mencapai hal ini, Unichain memerlukan sistem yang mampu mentransfer blok secara berkelanjutan dengan keterlambatan rendah dan waktu konfirmasi hampir instan. Solana dapat memproses secara paralel 440M, namun untuk mencapai kecepatan seperti itu, mengorbankan tingkat desentralisasi tertentu. Sebelumnya, dalam sebagian besar proposal blok L2, pengurutan data dan penciptaan root status akan menimbulkan keterlambatan, membuat waktu blok cepat tidak layak. Untuk mengatasi masalah ini, flashbot menciptakan flashblock, yang menguraikan blok menjadi potongan yang lebih kecil, mempersingkat waktu antar blok, untuk memaksimalkan keuntungan UX/LP. Flashblock adalah konfirmasi pra-konfirmasi yang dikeluarkan oleh pembangun blok TEE untuk konfirmasi sebagian tetapi cepat. Pertama, transaksi dikirimkan secara streaming ke pembangun blok TEE. Jika L2 mengaktifkan SBS, maka pembangun blok akan dipisahkan dari sorter. Setelah diurutkan dan dibundel, transaksi secara bertahap terbentuk menjadi konfirmasi sebagian yang disebut Flashblock. Flashblock akan disiarkan oleh sorter setiap 250 milidetik untuk divalidasi oleh node lain. Karena keterlambatan disebabkan oleh pembangkitan dan serialisasi root status di L2, Unichain secara signifikan mengurangi keterlambatan dengan menghitung biaya pembangunan blok dan penyebaran konsensus hanya sekali untuk beberapa blok sebagian. Singkatnya, Flashblock menjadi kuat karena: • Waktu pembangunan blok yang lebih singkat mengurangi risiko biaya pemilihan balik LP. • Flashblock menyediakan status eksekusi awal dari status yang ada, membuat integrasi dompet dan antarmuka pengguna lebih mudah. • Transaksi cepat memberikan pengalaman pengguna (UX) yang luar biasa. Selain itu, karena TEE dapat menerapkan pengurutan prioritas di setiap Flashblock, aplikasi dan smart contract sekarang dapat memungut pajak MEV, menghasilkan kepentingan diri sendiri sejak adanya pengurutan prioritas, dan membagi ulang MEV kepada LP dan pengguna. Seperti yang ditekankan oleh Dan Robinson dalam tweet-nya, memungkinkan aplikasi dan pengguna 'mengontrol' MEV mereka adalah salah satu fitur/tujuan utama Unichain. Yang lebih baik lagi, pengurutan prioritas dapat diverifikasi dengan bukti eksekusi publik di TEE. Ini memungkinkan pengguna untuk memverifikasi dengan tepat bagaimana transaksi mereka dieksekusi. Hal ini sangat penting karena ini adalah satu-satunya cara bagi pengguna untuk memastikan pengurutan prioritas dilakukan dengan adil.
1.4 Jaringan Verifikasi Unichain (UVN) Saat ini, sebagian besar sorter L2 adalah terpusat, perilaku sorter tunggal akan memengaruhi keadilan MEV, keaktifan blok, atau finalitas. Misalnya, jika sorter merilis blok yang tidak valid, dan mengajukan bukti penipuan untuk menantangnya, maka pembalikan rantai yang dihasilkan akan benar-benar memengaruhi kecepatan rantai. Untuk mengatasi kegagalan titik tunggal yang potensial di sorter, Unichain memperkenalkan Jaringan Verifikasi Unichain (UVN). UVN dengan fokus pada validasi blok oleh validator berdasarkan spesifikasi bukti (seperti Ethereum) saat mengusulkan blok, menambahkan lapisan finalitas tambahan. Proses ini mirip dengan pekerjaan paralel, di mana berbagai tahap pembangunan blok dapat terjadi secara bersamaan dalam satu periode. Namun, tanpa detail lebih lanjut dari dokumen, saat ini membuat asumsi berlebihan terlalu dini.
1.5 token $UNI dan token $Uni saat ini bukan hanya token tata kelola, tetapi juga token yang digunakan. Untuk menjadi validator, operator harus pertama-tama menggadaikan $Uni di mainnet sebagai jaminan. Kontrak pintar akan melacak saldo dan memperbarui status melalui jembatan asli Unichain. Pada awal setiap periode, saldo gadai saat ini akan diambil snapshot, dan biaya akan didistribusikan secara proporsional berdasarkan bobot gadai. Validator dengan bobot gadai $UNI tertinggi akan dipilih sebagai validator aktif, di mana mereka dapat mengirimkan bukti untuk mendapatkan sebagian hadiah validasi. Validator yang melewatkan atau tidak mengirimkan bukti tidak akan mendapatkan hadiah, dan hadiah akan ditahan hingga periode berikutnya. Berdasarkan informasi publik yang terbatas, kita dapat menyimpulkan bahwa hadiah validasi akan menjadi: (Biaya L2 yang dibayarkan oleh pengguna Unichain - pajak MEV yang dikenakan aplikasi - biaya pengiriman bundle ke lapisan 1). 2. Unichain vs Appchain vs General Rollup
Faktor perbedaan utama antara Unichain/通用 Rollup dan rantai aplikasi adalah MEV, konfirmasi sebelumnya, dan persaingan ruang blok.
Karena rantai aplikasi dapat menyesuaikan arsitektur mereka dengan fleksibel, mereka dapat menerapkan mekanisme MEV yang berbeda untuk mengatasi masalah seperti menghilangkan risiko sensor atau mengurangi kebocoran MEV.
Pada saat yang sama, karena sifat integritas yang disediakan oleh TEE, Unichain mengurangi dan mengelompokkan MEV dengan memastikan bahwa urutan transaksi tidak dipengaruhi oleh pihak ketiga mana pun. Penyusunan prioritas yang dapat diverifikasi juga memastikan MEV yang adil, dan kemungkinan mengalihkan pendapatan MEV kembali kepada pengguna dan penyedia likuiditas.
Sebagian besar sorter di pasar adalah terpusat, memungkinkan mereka untuk mendapatkan nilai maksimum dari aliran pesanan. Sebaliknya, Unichain mengambil pendekatan yang lebih 'untuk kepentingan umum', karena mekanisme redistribusi MEV-nya secara tertentu membatasi jumlah MEV yang dapat ditangkap oleh sorter asli.
Unichain dibangun di atas OpStack, yang merupakan standar tunggal dari Optimistic Chain yang memungkinkan Unichain membaca pesan dan mentransfer aset di atas supernode melalui pengiriman pesan yang aman, sehingga mencapai keterlambatan rendah (sekitar 2 detik) melalui desain interoperabilitas optimisnya yang asli. Di sisi lain, aplikasi rantai dapat memanfaatkan berbagai solusi interoperabilitas, seperti bergabung dengan ekosistem IBC atau membangun L3 di Arbitrum Orbit (meskipun ini tidak umum untuk L2 OpStack).