Rollup Layer 2 Modular Evolution: Apa yang Mungkin?

Artikel ini mencoba untuk membahas perkembangan dan evolusi Rollup Layer 2 dari perspektif evolusi, dan terutama menjawab pertanyaan-pertanyaan berikut:

Cara Kerja Rollup:

Evolusi modular rollup

Modularitas membuka kemungkinan

Tren teknologi dalam aplikasi modular

ringkasan

Cara kerja Rollup

“Trilema” blockchain selalu menjadi masalah yang sulit bagi industri, dan jika kita percaya bahwa blockchain Layer 1 pertama-tama harus memastikan “desentralisasi” dan “keamanan”, maka memigrasikan solusi “skalabilitas” dari Layer 1 adalah pilihan alami, maka Layer 2. Tantangan baru adalah bagaimana memastikan keamanan Layer 2 hingga Layer 1.

Awalnya, ada ide untuk secara berkala menulis akar pohon negara dari aplikasi Layer 2 ke Layer 1, sehingga keadaan aplikasi dapat diverifikasi oleh bukti negara, mirip dengan bukti cadangan pada platform perdagangan. Namun, metode ini tidak dapat dilakukan oleh pihak ketiga untuk memverifikasi bahwa kedua transisi negara sudah benar secara publik.

Untuk menggali lebih dalam masalah ini, mari kita abstraksikan bahwa keadaan program apa pun dapat dinyatakan dengan rumus transisi keadaan:

t+1 (t, T)

Formula ini berasal dari Buku Kuning Ethereum, tetapi dapat mewakili program apa pun. Di sini singkatan dari program, yang mewakili negara. Status t + 1 dihitung oleh program Y dari negara t dan transaksi T. Transaksi T mewakili input program. Kapan saja, jika t deterministik, program Y deterministik, dan T deterministik, maka t + 1 deterministik.

Jadi untuk memberikan verifikasi publik, kuncinya adalah bahwa Y tersedia untuk umum, bahwa semua T secara historis tersedia untuk umum dan berurutan, dan bahwa keadaan antara dapat dihitung ulang oleh Y dan T. Ketersediaan publik dari program ini dapat dicapai melalui open source, dan kuncinya adalah bagaimana memastikan ketersediaan publik T, yang memperkenalkan konsep ketersediaan data (DA).

Ketersediaan data memerlukan buku besar publik yang tidak dapat diubah untuk mencatat transaksi aplikasi. Secara alami, buku besar blockchain adalah sistem seperti itu, sehingga transaksi Layer 2 ditulis kembali ke Layer 1 untuk memastikan ketersediaan data, dari situlah nama Rollup berasal.

Oleh karena itu, perlu ada peran dalam sistem Layer 2 yang mengumpulkan transaksi pengguna, mengurutkannya, dan menulisnya ke DA, dan peran ini disebut Sequencer. Urutan transaksi di sini disebut Canonical Transaction Chain.

Ketersediaan data dijamin, dan semua orang bisa mendapatkan keadaan akhir dengan menjalankan program sendiri untuk menjalankan transaksi. Tetapi tidak ada konsensus di sini, karena semua orang tidak yakin apakah hasilnya sama dengan orang lain, lagipula, kegagalan perangkat lunak atau perangkat keras juga dapat menyebabkan inkonsistensi data. Oleh karena itu, peran lain diperlukan untuk mempublikasikan akar pohon status setelah transaksi dijalankan secara teratur agar semua orang dapat memverifikasi status mereka, dan peran ini disebut Pengusul. Status setiap komit di sini juga merupakan urutan keadaan, yang sesuai dengan urutan transaksi, yang disebut Rantai Komitmen Negara.

Pada titik ini, kami telah mencapai verifikasi aplikasi. Jika hasil seseorang tidak sesuai dengan status pengajuan Pengusul dan ditentukan bahwa itu bukan masalah mereka, maka Pengusul curang atau salah, bagaimana Anda memberi tahu orang lain tentang hal itu? Arbiter harus menjadi pihak ketiga yang tepercaya, dan kontrak on-chain dapat mengambil peran ini.

Ada dua opsi untuk arbitrase:

Setiap kali Pengusul mengajukan suatu negara, ia juga memberikan Bukti Validitas transisi negara dari negara sebelumnya, yang diverifikasi oleh kontrak arbitrase pada rantai. Bukti yang valid biasanya dihasilkan menggunakan teknologi tanpa pengetahuan, yang disebut ZK Rollup.

Diasumsikan bahwa hasil Pengusul benar, tetapi jika ditemukan ketidakkonsistenan, Bukti Penipuan diajukan, dan kontrak arbitrase memutuskan. Jika kontrak kuorum menentukan bahwa Pengusul curang, Pengusul dihukum dan Rantai Komitmen Negara dikembalikan ke keadaan sebelum transaksi penipuan. Tentu saja, untuk memastikan keamanan, periode tantangan yang relatif lama umumnya ditetapkan untuk mencapai finalitas penyelesaian transaksi on-chain. Ini disebut rollup optimis.

Kita juga perlu menerapkan interoperabilitas aset antara Layer 1 dan Layer 2. Oleh karena itu, jembatan antara Layer 1 dan Layer 2 dibangun, dan penyelesaian aset dilakukan melalui proof of state. Keadaan Layer 2 di Layer 1 dijamin oleh kontrak arbitrase Layer 1, dan kita dapat mengasumsikan bahwa keamanan jembatan ini juga dijamin oleh kontrak arbitrase.

Sejauh ini, kami memiliki solusi Rollup Layer 2 yang dijamin oleh Layer 1 dan dapat beroperasi dengan Layer 1.

Tentu saja, ada beberapa kompromi yang dibuat oleh solusi Rollup:

Menulis transaksi ke Layer 1 berarti skalabilitas Layer 2 masih dibatasi oleh ukuran blok Layer 1. Mengambil Ethereum sebagai contoh, Layer 2 sepenuhnya menempati semua blok Ethereum, dan TPS rata-rata yang dapat disediakan hanya beberapa ratus, dan skalabilitasnya dibatasi oleh DA.

Untuk menghemat biaya gas, Sequencer menulis transaksi ke DA dalam batch, dan sebelum menulis ke DA, Sequencer dapat menipu dengan menyesuaikan urutan transaksi.

Berikut ringkasan keamanan Layer 2 dan finalitas transaksi:

Jika pengguna menjalankan node Layer 2 dan dengan setia mengeksekusi urutan transaksi DA, pengguna dapat mengasumsikan bahwa transaksi dikonfirmasi secara instan dan diselesaikan, karena jika hasil eksekusi pengguna berbeda dari Pengusul, itu berarti bahwa Pengusul menipu dan perlu memutar kembali keadaan rantai, dan hasilnya akan sama dengan node pengguna sendiri. Risiko utama di sini adalah risiko Sequencer yang disebutkan sebelumnya menyesuaikan urutan transaksi yang belum ditulis ke DA jika data disinkronkan dari Sequencer secara real time.

Jika pengguna tidak dapat menjalankan node sendiri, ia harus bergantung pada penyedia RPC, dan pengguna harus menanggung risiko kepercayaan tertentu. Namun, risiko ini mirip dengan risiko yang ditimbulkan oleh pengguna yang mempercayai node RPC di Layer 1. Risiko tambahan di sini masih risiko Sequencer menjatuhkan atau memesan ulang transaksi.

Jika Pengusul membuat kesalahan, tetapi tidak ada node yang memulai tantangan, dan periode tantangan terlampaui, keadaan yang salah tidak dapat dibatalkan, dan keadaan hanya dapat diperbaiki melalui hard fork konsensus sosial.

Evolusi modular rollup

Menurut analisis sebelumnya, dalam solusi Rollup, beberapa kontrak pada rantai mengasumsikan fungsi yang berbeda dan mewakili modul yang berbeda. Pikiran alami adalah apakah modul dapat dibagi menjadi beberapa rantai untuk mencapai skalabilitas yang lebih tinggi. Itulah ide di balik blockchain modular dan rollup modular.

Modularitas memiliki dua arti di sini:

Melalui desain modular, sistem menjadi sistem pluggable. Pengembang dapat merakit modul untuk memenuhi kebutuhan skenario aplikasi yang berbeda.

Berdasarkan kemampuan yang disediakan oleh 1, implementasi lapisan modul tidak terikat pada Lapisan 1 yang sama, menghasilkan skalabilitas yang lebih baik.

Kita dapat memikirkan tiga lapisan modul utama:

Ketersediaan Data: Menjamin bahwa data transaksi dari lapisan eksekusi dapat diperoleh secara publik, dan urutan transaksi yang dijamin.

Penyelesaian: Selesaikan aset dan status antara Layer 1 dan Layer 2. Ini berisi Rantai Komitmen Negara dan Jembatan.

Arbitrase: Verifikasi bukti penipuan dan buat putusan (Optimis) atau verifikasi bukti yang valid (ZK). Lapisan kuorum harus mampu memanipulasi Rantai Komitmen Negara.

Modularitas DA

Manfaat utama dari migrasi fungsi DA ke solusi mandiri adalah bahwa biaya gas transaksi Layer 2 dikurangi setidaknya satu urutan besarnya.

Dari perspektif keamanan, bahkan jika desentralisasi rantai DA lebih lemah daripada Ethereum, jaminan keamanan di lapisan DA terutama adalah transaksi selama periode tantangan.

Rantai pribadi DA dapat menyediakan bandwidth penyimpanan yang lebih tinggi dan biaya penyimpanan yang lebih rendah, dan dirancang khusus untuk beberapa aplikasi untuk berbagi DA. Ini juga merupakan pijakan rantai DA saat ini seperti Celestia dan Polygon Avail.

Setelah memisahkan layer DA, kita mendapatkan arsitektur diagram berikut:

Pada gambar di atas, DA bertanggung jawab untuk menyimpan Canonical Transaction Chain, dan L1ToL2 Transaction Queue ditinggalkan untuk Layer1 untuk mewujudkan komunikasi pesan antara Layer1 dan Layer2, dan pengguna juga dapat menulis transaksi langsung ke antrian ini untuk memastikan bahwa Layer2 adalah Permissionless, dan Sequencer tidak dapat mengaudit pengguna atau transaksi.

Salah satu solusinya adalah memiliki jembatan lintas rantai antara rantai DA dan rantai arbitrase untuk memverifikasi bukti data yang diberikan oleh rantai DA dalam kontrak arbitrase. Namun, solusi ini bergantung pada implementasi jembatan lintas rantai antara DA dan rantai lainnya, dan pilihan solusi DA akan terbatas. Pilihan lain adalah memperkenalkan bukti penyortiran.

Bukti Urutan

Kita dapat menganggap Sequencer sebenarnya sebagai bagian dari skema DA, dan itu setara dengan DA Khusus Aplikasi karena alasan berikut:

Sequencer perlu memberikan jaminan DA untuk periode sebelum penulisan massal ke rantai DA.

Sequencer bertanggung jawab untuk memvalidasi transaksi, mengurutkan, dan akhirnya menuliskannya ke DA.

Jika Anda meminta Sequencer untuk menghasilkan Bukti Urutan untuk setiap transaksi, Anda dapat menyelesaikan dua masalah:

Memberikan jaminan untuk transaksi yang belum ditulis ke rantai DA, sehingga Sequencer tidak berani sewenang-wenang menyesuaikan urutan transaksi atau membuangnya. Jika tidak ada jembatan lintas rantai antara rantai DA dan rantai kuorum, data dapat dijamin tersedia melalui mekanisme tantangan Bukti Urutan.

Sequence Proof memiliki beberapa fitur berikut:

Ini membawa tanda tangan Sequencer, membuktikan bahwa itu dikeluarkan oleh Sequencer. Ini membuktikan posisi transaksi di seluruh urutan transaksi. Ini adalah jenis bukti akumulator. Setiap transaksi ditambahkan untuk menghasilkan hasil baru yang berkorelasi dengan semua transaksi historis sebelumnya, sehingga sulit untuk dirusak. Salah satu opsi untuk akumulator adalah Akumulator Merkle, yang menghasilkan bentuk akar pohon Merkle.

Cara kerja Sequence Proof:

Pengguna atau node eksekusi mengirimkan transaksi ke Sequencer, dan Sequencer mengembalikan Bukti Urutan kepada pengguna dan menyinkronkannya ke node lain. Jika Sequencer membuang atau merusak urutan transaksi sebelum mengirimkannya ke DA, pengguna atau node lain dapat menghukum Sequencer dengan mengirimkan Bukti Urutan ke kontrak kuorum. Kontrak kuorum perlu membaca akar akumulator transaksi dari kontrak Rantai Komitmen Negara untuk memverifikasi Bukti Urutan.

Mari kita bahas skenario berikut:

Sequencer membuang atau mengalirkan ulang transaksi pengguna. Hal ini menyebabkan Sequencer menghasilkan dua Sequence Proof di lokasi yang sama. Ketika pengguna mengirimkan Bukti Urutan ke kontrak arbitrase, Sequencer perlu memberikan bukti bahwa transaksi tersebut termasuk dalam akar akumulator transaksi terbaru, dan jika tidak bisa, Sequencer akan dihukum.

Sequencer tidak menulis transaksi dengan benar ke rantai DA, dan bersekongkol dengan Pengusul untuk menyembunyikan transaksi. Jika rantai kuorum dan rantai DA memiliki jembatan, jembatan digunakan untuk memvalidasinya, menghukum sequencer. Jika tidak, pengguna dapat menantang Sequencer untuk memberikan bukti transaksi di lokasi tertentu, bersama dengan informasi asli. Namun, dalam hal ini, kontrak arbitrase tidak dapat menentukan apakah pengguna adalah tantangan berbahaya, jadi jika Sequencer memberikan data, itu tidak menghukum Sequencer. Bagi pengguna, tantangan jahat menyakiti orang lain dan diri mereka sendiri, dan ada juga kurangnya motivasi ekonomi.

Kami telah membuat protokol Layer 2 lebih aman dengan memperkenalkan Sequence Proof.

Pipeline Transaksi dan Eksekusi Paralel

Manfaat lain dari membagi Sequencer menjadi DA, yang hanya bertanggung jawab untuk validasi dan pemesanan transaksi, adalah kemudahan merampingkan transaksi dan eksekusi paralel.

Saat memverifikasi transaksi, Anda perlu memverifikasi tanda tangan dan apakah ada cukup biaya gas, dan verifikasi biaya gas harus bergantung pada negara. Jika kami mengizinkan Sequencer untuk mengizinkan penundaan (dalam detik) antara keadaan di mana transaksi verifikasi bergantung dan keadaan terbaru untuk memastikan bahwa transaksi validasi tidak diblokir oleh transaksi eksekusi, validasi gas akan tidak akurat dan ada risiko serangan DDoS.

Tapi kami berpikir bahwa menjadi DA adalah arah yang tepat untuk Sequencer, jadi ada baiknya melihat lebih jauh. Misalnya, Anda dapat membagi bagian DA dari biaya transaksi dan mengungkapkannya melalui Sui Move Object (UTXO), yang dapat mengurangi biaya deteksi biaya gas.

Sequencer mengurutkan transaksi dan mengeluarkannya ke dalam pipa transaksi, yang kemudian disinkronkan ke Proposer dan node lainnya. Setiap node dapat memilih skema paralel sesuai dengan situasi servernya sendiri. Setiap node perlu memastikan bahwa hanya transaksi tanpa hubungan sebab akibat yang paralel, dan bahwa transaksi dengan hubungan kausal harus dieksekusi dalam urutan Sequencer, dan bahwa hasil akhirnya akan konsisten.

Pengusul perlu secara berkala melakukan root pohon negara, serta akar akumulator ke kontrak Rantai Komitmen Negara on-chain.

Jadi kami mendapatkan Layer 2 modular dengan biaya gas rendah, TPS tinggi, dan keamanan lebih: Rooch.

MoveOS: Ini berisi MoveVM dan StateDB, yang merupakan mesin eksekusi dan penyimpanan status sistem. StateDB dibangun dari dua lapisan pohon Merkle yang jarang yang memberikan bukti keadaan. Berdasarkan analisis sebelumnya, dapat disimpulkan bahwa pohon negara dan bukti negara adalah komponen yang sangat diperlukan dari aplikasi rollup.

RPC: Memberikan pertanyaan eksternal, mengirimkan transaksi, dan berlangganan layanan. Antarmuka RPC yang dapat kompatibel dengan rantai lain dapat ditengahi.

Sequencer: Memvalidasi transaksi, mengurutkan transaksi, memberikan bukti urutan, dan mengeluarkan transaksi ke Pipeline Transaksi.

Pengusul: Dapatkan transaksi dari Pipeline Transaksi, jalankan dalam batch, dan kirimkan ke Rantai Komitmen Negara on-chain secara teratur.

Penantang: Dapatkan transaksi dari Pipa Transaksi, jalankan dalam batch, dan bandingkan dengan Rantai Komitmen Negara untuk memutuskan apakah akan meluncurkan tantangan.

DA &; Settlement &; Arbitration Interface: Abstraksi dan enkapsulasi lapisan modul yang berbeda untuk memastikan bahwa beralih di antara implementasi yang berbeda tidak mempengaruhi logika bisnis lapisan atas.

Bukti penipuan interaktif dengan dukungan multi-rantai

Dalam skema rollup optimis, bagaimana kontrak arbitrase on-chain menentukan bahwa kesalahan eksekusi transaksi off-chain selalu menjadi masalah yang sulit. Ide awalnya adalah untuk mengeksekusi kembali transaksi Layer 2 pada Layer 1, tetapi masalah dengan solusi ini adalah bahwa kontrak Layer 1 perlu mensimulasikan pelaksanaan transaksi Layer 2, yang sangat mahal dan akan membatasi kompleksitas transaksi Layer 2.

Akhirnya, industri telah mengeksplorasi skema bukti interaktif. Karena setiap transaksi kompleks pada akhirnya akan diubah menjadi eksekusi instruksi mesin, jika kita menemukan instruksi yang menghasilkan divergensi, kita hanya perlu mensimulasikan eksekusi instruksi pada rantai.

Gunakan juga rumus transisi status di atas:

t+1 (t, T)

Di sini T adalah singkatan dari instruksi dan T adalah singkatan dari input instruksi, yang mewakili keadaan memori di mana instruksi bergantung. Jika selama eksekusi, buat sertifikat status untuk setiap . Melalui interaksi, penuntut dan pembela dapat menemukan titik ketidaksepakatan m antara kedua belah pihak, dan menyerahkan status m-1 dan instruksi m ke kontrak arbitrase on-chain untuk eksekusi simulasi, dan kontrak arbitrase dapat ditentukan setelah dieksekusi.

Jadi pertanyaan yang tersisa adalah bagaimana menghasilkan bukti, dan ada dua opsi utama:

Ini diimplementasikan langsung dalam mesin virtual bahasa kontrak, seperti AVM Arbitrum dan FuelVM Bahan Bakar.

Menerapkan simulator berdasarkan set instruksi yang ada dan memberikan kemampuan bukti dalam simulator. Contohnya termasuk meriam berbasis MIPS Optimisme, Nitro berbasis WASM baru Arbitrum, dan OMO berbasis MIPS Rooch.

OMO adalah simulator bytecode tujuan umum dengan kemampuan proof-of-state satu langkah, yang dirancang untuk lingkungan eksekusi multi-rantai. Dengan dukungan OMO, modularitas lapisan kuorum dapat terwujud. Setiap rantai yang mendukung kontrak Turing-complete dapat meniru instruksi OMO dalam kontrak sebagai lapisan kuorum.

ZK + Skema Kombo Optimis

Ada banyak perdebatan di industri tentang manfaat Optimistic Rollup dan ZK Rollup, tetapi kami percaya bahwa menggabungkan keduanya dapat memberi Anda yang terbaik dari kedua dunia.

Atas dasar solusi Optimis sebelumnya, kami memperkenalkan karakter baru, ZK Prover. Ini menghasilkan bukti yang valid tentang status transaksi yang diajukan oleh Pengusul dalam batch dan menyerahkannya ke kontrak arbitrase. Setelah kontrak arbitrase diverifikasi, dapat ditentukan bahwa transaksi telah mencapai finalitas pada Layer 1, dan transaksi penarikan dari Layer 2 ke Layer 1 dapat diselesaikan.

Keuntungan dari pendekatan ini:

Masalah kinerja ZK tidak akan membatasi throughput keseluruhan Layer 2. ZK dapat mempersingkat siklus tantangan Optimis dan meningkatkan pengalaman pengguna.

Sebelum solusi dan akselerasi hardware ZK matang, kita dapat membangun ekosistem melalui Optimistic, dan solusi modular dapat membuat ZK akhirnya terintegrasi dengan mulus.

Penyelesaian multi-rantai

Jika kita berpikir lebih jauh tentang tren modularitas, wajar untuk berpikir bahwa karena DA dapat dimigrasikan ke rantai lain, dapatkah lapisan penyelesaian juga digunakan ke rantai lain?

Penyelesaian aset antara Layer 1 dan Layer 2 terutama tergantung pada dua komponen, satu adalah Jembatan dan yang lainnya adalah Rantai Komitmen Negara. Bridge tentu saja dapat digunakan ke beberapa rantai, tetapi Rantai Komitmen Negara hanya dapat memiliki satu versi otoritatif, dijamin oleh kontrak kuorum.

Arah ini masih perlu dipelajari secara mendalam, tetapi ada rencana awal. Rantai Komitmen Negara pada rantai lain adalah bayangan cermin dari Ethereum. Gambar ini tidak perlu menyinkronkan semua Layer2 State Root ke rantai lain, tetapi dipetakan oleh pengguna melalui bukti status Ethereum sesuai permintaan.

Tentu saja, rantai lain juga harus dapat memverifikasi bukti keadaan di Ethereum, jadi Anda perlu mengetahui akar keadaan di Ethereum. Saat ini, ada dua skenario untuk menyinkronkan root of state pada Ethereum ke node lain:1. Andalkan Oracle. 2. Sematkan simpul cahaya Ethereum dan verifikasi header blok Ethereum.

Dengan cara ini, kita bisa mendapatkan solusi Layer 2 yang mendukung penyelesaian multi-rantai, tetapi keamanannya dijamin oleh Ethereum.

Perbedaan antara solusi ini dan lintas rantai:

Jika itu adalah solusi lintas rantai yang bergantung pada rantai relai, dapat dianggap bahwa Lapisan 2 menggantikan rantai relai dan merupakan lapisan relai yang keamanannya dijamin oleh kontrak arbitrase.

Jika itu adalah skema lintas rantai yang memverifikasi bukti keadaan antar rantai, skema penyelesaian multi-rantai berbagi skema teknis sinkronisasi akar negara dengannya, tetapi jauh lebih disederhanakan. Karena dalam skema penyelesaian multi-rantai, persyaratan sinkronisasi root negara adalah satu arah, dan hanya perlu disinkronkan dari rantai kuorum ke rantai lain, bukan dua per dua.

Modularitas membuka kemungkinan

Melalui modularitas, pengembang dapat menggabungkan aplikasi yang berbeda dengan Rooch.

Rooch Ethereum Layer2 = Rooch + Ethereum (Penyelesaian + Arbitrase) + DA。 Ini adalah jaringan yang akan dijalankan Rooch. Menyediakan platform runtime Move yang dijamin oleh keamanan Ethereum dan dapat beroperasi dengan aset di Ethereum. Di masa depan, itu dapat diperluas ke penyelesaian multi-rantai.

Rooch Layer3 Rollup DApp = Rooch + Kontrak Pindah DApp + Rooch Ethereum Layer2 (Penyelesaian + Arbitrase) + DA Jika aplikasi menyebarkan penyelesaian dan arbitrasenya sendiri ke Rooch Layer 2, itu adalah aplikasi Rooch Layer 3.

XChain Rollup DApp = Rooch + Kontrak Pindah DApp + XChain (Penyelesaian + Arbitrase) + DA Rantai apa pun dapat memberi pengembang satu set toolkit Rollup DApp berdasarkan bahasa Move melalui Rooch. Pengembang hanya perlu menulis logika aplikasi mereka sendiri melalui bahasa Move untuk menjalankan aplikasi rollup di lingkungan independen yang aman dan dilindungi oleh XChain, dan aset dapat dioperasikan dengan XChain. Tentu saja, ini perlu dikembangkan bekerja sama dengan pengembang masing-masing rantai publik.

Aplikasi Sovereign Rollup DApp = Rooch + DApp Move Contract + DA juga dapat menggunakan Rooch sebagai Sovereign Rollup SDK, tanpa menerapkan kontrak Bridge dan Arbitrase, dan State Commitment Chain juga disimpan dalam DA untuk memastikan verifikasi dan keamanan dengan konsensus sosial.

Arweave SCP DApp = Rooch + DApp Move Contract + DA (Arweave)SCP mirip dengan Sovereign Rollup, karena SCP mengharuskan kode aplikasi disimpan ke DA juga. Di Rooch, penyebaran dan peningkatan kontrak semuanya adalah transaksi, dan kode kontrak akan ditulis ke lapisan DA dalam transaksi, jadi kami yakin itu memenuhi standar SCP.

Move DApp Chain = Cosmos SDK + MoveOS + DApp Move Contract MoveOS dapat disematkan ke dalam lingkungan runtime rantai apa pun sebagai lingkungan runtime Move independen untuk membangun rantai aplikasi atau rantai publik baru.

Proyek non-blockchain Proyek non-blockchain dapat menggunakan MoveOS sebagai database dengan kemampuan validasi data dan kemampuan bukti penyimpanan. Misalnya, gunakan untuk membuat sistem blog lokal, dan struktur data serta logika bisnis diekspresikan melalui Move. Ketika infrastruktur matang di masa depan, itu dapat langsung terhubung dengan ekosistem blockchain. Contoh lain adalah dapat digunakan sebagai layanan FaaS dalam komputasi awan, di mana pengembang dapat menulis Fungsi di FaaS melalui Move, platform menghosting status, dan fungsi antar pengguna juga dapat digabungkan dan dipanggil satu sama lain. Ada lebih banyak kemungkinan untuk dijelajahi.

Pendekatan modular Rooch dapat disesuaikan dengan berbagai jenis dan tahapan aplikasi. Misalnya, pengembang pertama-tama dapat memverifikasi ide-ide mereka di Rooch Ethereum Layer 2 dengan menerapkan kontrak, dan kemudian memigrasikan aplikasi ke Rollup Khusus Aplikasi independen yang dibangun di Rooch setelah mereka dewasa.

Atau pengembang dapat meluncurkan aplikasi secara langsung melalui metode Sovereign Rollup, karena aplikasi tidak memiliki persyaratan keamanan yang tinggi pada tahap awal, dan tidak perlu menukar aset dengan rantai lain, sehingga dapat diverifikasi terlebih dahulu. Ketika aplikasi tumbuh dan ada permintaan untuk aset interkoneksi, persyaratan keamanan menjadi lebih tinggi, dan modul penyelesaian dan arbitrase dapat diaktifkan untuk memastikan keamanan aset.

Tren teknologi untuk aplikasi modular

Potensi layer DA belum dimanfaatkan

Seperti yang Anda lihat dari analisis sebelumnya, DA diandalkan terlepas dari kombinasinya. DA memainkan peran serupa dalam aplikasi terdesentralisasi sebagai platform logging untuk sistem Web2, yang dapat digunakan untuk audit, analisis data besar, pelatihan AI, dan banyak lagi. Akan ada banyak aplikasi dan layanan yang dibangun di sekitar DA di masa depan. Saat ini ada Celestia, Polygoin avail, dan di masa depan, EigenLayer, Ethereum danksharding, dll.

Berdasarkan analisis sebelumnya, kami menyimpulkan bahwa peran Sequencer harus menjadi bagian dari DA, dan jika lapisan DA dapat memberikan kemampuan verifikasi transaksi untuk aplikasi, dan memiliki kinerja yang cukup, pada kenyataannya, DA dapat memikul tanggung jawab Sequencer, dan pengguna menulis transaksi langsung ke DA. Tentu saja, apakah Anda dapat menggunakan token aplikasi untuk membayar biaya gas DA adalah masalah lain yang perlu diselesaikan.

Bahasa pemrograman DApp akan meledak

Bentuk aplikasi baru akan menyebabkan ledakan bahasa pemrograman baru, yang telah terbukti di era Web2. Move akan menjadi bahasa terbaik untuk membangun Web3 DApps. Selain sifat linguistik Move itu sendiri, ada alasan berikut:

DApps dapat dengan cepat mengakumulasi pustaka dasar yang diperlukan untuk aplikasi dalam bahasa yang sama, membentuk efek aglomerasi ekologis. Jadi mendukung banyak bahasa bukanlah strategi yang baik pada awalnya.

Paling tidak, aplikasi terdesentralisasi harus dapat diverifikasi, dan bahasa kontrak pintar dapat mengurangi banyak beban mental pada pengembang dalam hal memastikan verifikasi.

Sifat platform-agnostik Move membuatnya mudah untuk beradaptasi dengan platform dan aplikasi yang berbeda.

Status pemindahan terstruktur, yang memfasilitasi representasi struktur data DApp serta pengambilan penyimpanan.

Ringkasan

Saya masuk ke blockchain pada akhir '17 ketika ada begitu banyak tim di industri yang mencoba membangun aplikasi di ruang blockchain. Sayangnya, infrastruktur belum lengkap, dan industri belum menemukan model yang dapat direplikasi untuk membangun aplikasi, dan sebagian besar proyek aplikasi berakhir dengan kegagalan, memukul pengembang dan investor. Bagaimana seharusnya aplikasi dibangun di blockchain? Pertanyaan ini telah memikirkan saya selama lima tahun.

Sekarang, dengan kematangan Layer 1, Layer 2, kontrak pintar, dan infrastruktur modular, jawaban atas pertanyaan ini secara bertahap menjadi lebih jelas.

Saya berharap bahwa dalam ledakan Web3 DApps yang akan datang, Rooch dapat membantu pengembang membangun aplikasi lebih cepat dan benar-benar mendarat.