Satu-satunya Blockchain Dengan Dukungan Rollups asli di konsensus layer.
Disclaimer : Publikasi ini merupakan terjemahan dari Ambasador Oasis. Pemeriksaan teliti dilakukan guna memberikan terjemahan yang akurat. Mereka mungkin melakukan kesalahan atau kelalaian, pihak Oasis tidak bertanggung jawab atas keakuratan dan ketelitiannya. Silahkan Kunjungi artikel asli di sini
Solusi peningkatan Layer 2 berevolusi dari “sidechains” menjadi “commitchains”, “rollup”, dan memvalidasi bridge. “Rollup” mengacu untuk menjalankan mesin virtual smart contract (VM) di mana status VM diverifikasi secara teratur dan dilakukan pada dasar blockchain untuk menyediakan fungsionalitas smart contract dengan biaya yang lebih murah dan tingkat throughput yang lebih tinggi, dibandingkan dengan menjalankan smart contract secara langsung pada Blockchain tersebut. Verifikasi yang dilakukan pada dasar blockchain mengamankan transisi status, dan komputasi off-chain yang memungkinkan untuk meningkatkan eksekusi smart contract.
Kami tidak menyebutnya itu rollups, akan tetapi itulah bagaimana jaringan Paratime atau layer komputasi bekerja.
Jika dibandingkan, jaringan Oasis telah memisahkan komputasi dari Konsensus sebagai sebuah prinsip modular. Pemisahan ini memiliki arti bahwa entitas layer Paratime hanya untuk mengatasi eksekusi smart contract, dan entitas konsensus layer hanya mengatasi konsensus. Dan keduanya telah sangat disederhanakan. Ini memiliki banyak manfaat termasuk memberikan kemudahan dalam pengeditan, isolasi kesalahan, dan mengurangi replikasi komputasi tanpa mengorbankan keamanan. Pemisahan ini, setelah mengkomputasi dilakukan di mesin virtual (rollup) dan hasilnya diverifikasi yang masuk ke blockchain, itulah yang dimaksud dengan rollup.
Jaringan Oasis bukan hanya sebuah jaringan yang mendukung rollups secara alami, arsitektur rollup nya pun dioptimalkan dan rollup satu-satunya: ini mencegah menempatkan perhitungan umum di lapisan konsensus, dan hanya mengizinkan kontrak bawaan yang berjalan di sana. Kontrak bawaan ini adalah kontrak jembatan yang memvalidasi dalam istilah rollup. Meskipun tujuan arsitektur jaringan Oasis dirancang untuk blockchain Layer-1 modular yang mendukung smart contract, seseorang mungkin beragumentasi bahwa hasil dari modularitas adalah supaya layer Konsensus oasis merupakan sebuah Blockchain yang mendukung rollups, karena terlihat melalui lensa rollup semua ParaTimes adalah mesin virtual rollup Layer 2.
Khususnya, validasi bridge Oasis dalam layer konsensus menggunakan teknik fraud proof yang disebut “discrepancy detection” untuk mengvalidasi hasil dari layer komputasi. Teknik ini, dihasilkan dari fraud detection dan desain bersama arsitektur sistem, menggunakan “bare metal proofs” yang sederhana dan dengan demikian lebih dapat dipercaya karena lebih sedikit kesalahan. Seperti yang akan kita lihat, kesederhanaan bare metal proofs juga menjadikan para desainer Paratime lebih headroom: mengimplementasikan lingkungan eksekusi smart contract di mana smart contract tersebut adalah kode asli sandbox yang menjadi layak, memberikan peningkatan kinerja sistem headroom di luar eksekusi ParaTime bersamaan.
Seseroang juga mungkin berkata bahwa jaringan Oasis adalah jaringan pertama yang secara alami mendukung rollups. yang nomenklatur “Lapisan 1”/”Lapisan 2” nya tidak cukup deskriptif/tepat.
Sebut saja itu desain konvergen. Mari kita buka apa artinya barang ini dan masuk ke beberapa detailnya.
Properti Rollups
Rollup intinya didesain untuk mempercepat pemrosesan smart contract Ethereum. Lebih spesifik nya, mereka dirancang untuk mengeksekusi smart contract Ethereum, tetapi dalam mesin virtual independen yang terpisah, berbeda dengan Ethereum Virtual Machine (EVM) pada “rantai dasar” Ethereum Layer 1, untuk mengurangi beban kerja Layer 1. Satu-satunya pekerjaan yang dilakukan blockchain dasar yaitu dengan memvalidasi eksekusi mesin virtual rollup menggunakan smart contract “validating bridge”. Biasanya, mesin virtual rollup juga merupakan linstansi dari EVM, dan dalam beberapa desain, misalnya, Arbitrum, mesin virtual rollup di-tweak untuk membuat validasi di rantai dasar lebih mudah. Selama pemeriksaan validasi di Layer 1 lebih murah daripada menjalankan rollup smart contract secara langsung di Layer 1, kami memiliki sebuah peningkatan efisiensi karena eksekusi mesin Layer 2 memang seharusnya lebih murah. Inilah inti dari bagaimana rollup meraih skabilitas throughput transaksi.
Perlu digaris bawahi bahwa Blockchain Layer 1 diatas, bisa saja terdapat banyak mesin virtual Layer 2. Tidak ada batasan arsitektular selain dari validasi throughput layer 1. Semakin efisien memvalidasi bridge contract akan semakin sedikit eksekusi non-bridge smart contract untuk menjalankan blockchain Layer 1, semakin banyak rollups yang dapat didukung. Tentu, mungkin terdapat sebuah tipe bridge contract yang memvalidasi dan berjalan di dalam rollup juga, tetapi ada batasan pada rekursi ini yang tidak akan kami bahas disini.
Kebanyakan desain rollups melakukan transaksi data ke rantai dasar dulu dan kemudian nantinya komit status yang dihasilkan dari mesin virtual rollup kedalam transaksi berikutnya. Ini memberikan finalitas pesanan transaksi, dan, dengan cara tertentu, memecahkan masalah ketersediaan data karena status mesin virtual rollup dapat direkonstruksi dari data transaksi dengan biaya eksekusi ulang semua transaksi sejak status genesis mesin virtual rollup. Memvalidasi bridge bisa lebih umum dengan penyimpanan status off-chain yang dapat diverifikasi menggunakan Proofs Merkle sehingga solusi ketersediaan data yang terpisah dimungkinkan, misalnya, data transaksi dapat diringkas secara kriptografis dengan cara yang sama seperti keadaan mesin virtual, mengurangi Layer 1 biaya penyimpanan, memisahkan ketersediaan, disediakan oleh penyimpanan off-chain, dari keaslian data. Ini memiliki trade-off dengan validasi: masalah throughput ketersediaan data sementara karena mengakses data input yang diperlukan untuk verifikasi mungkin lambat yang dapat menunda validasi.
Cara rollup tersebut melakukan validasi mesin virtual hadir dalam 2 bentuk:
- Rollup optimistis, dimana hasil eksekusi yang diakui dan dicatat secara publik berpotensi ditantang.
- Zk rollups dimana SNARKs digunakan sebagai bukti kebenaran.
Kunci Perbedaannya adalah bahwa rollup optimistis menggunakan “fraud proofs” di mana para pesaing mengumpulkan bukti untuk membuktikan bahwa hasil eksekusi yang diklaim tidak benar atau curang, dan rollup zk menggunakan “validity proofs” yang diterbitkan oleh eksekutor bersama dengan status mesin virtual rollup, dan memvalidasi smart contract bridge yang memverifikasi bukti kebenaran. Pada kedua kasus tersebut, waktu diperlukan untuk memungkinkan partisipan lain melihat kondisi baru dan untuk menemukan bahwa kondisi itu tidak benar dan mongkonstrusikan sebuah Fraud proof.dalam kasus rollup optimistis; atau mengeksekusi algoritma bukti verifikasi untuk menolak bukti dugaan bahwa ketika itu tidak benar dalam kasus zk rollup.
Meskipun mungkin tampak perbedaan kecil, dalam kedua kasus, pekerjaan harus dilakukan baik untuk membangun bukti penipuan atau untuk memeriksa apakah bukti validitas itu benar. Perbedaannya adalah bahwa biasanya fraud proofs melibatkan pelaksanaan ulang transaksi, sedangkan pemeriksaan bukti validitas seharusnya lebih murah, menggunakan teknik kriptografi (bukti yang dapat diperiksa secara probabilistik; SNARK). Dalam praktiknya, teknik kriptografi melibatkan overhead yang signifikan dan tidak (belum) menggeneralisasi ke eksekusi smart contract yang sewenang-wenang.
Mengingat bahwa, secara umum rollup mesin virtual tidak harus selalu kompitabel dengan Ethereum, Mekanisme validasi juga tidak harus dijalankan di atas Ethereum. Setiap substrate komputasi yang terdesentralisasi akan melakukannya, memperluas keamanannya ke mesin virtual rollup. Tentu saja, memiliki mesin virtual rollup yang Kompatibel Ethereum membuatnya disepelekan untuk mem-port kode EVM yang ada.
Flavors Fraud Proofs
Untuk mengetahui mengapa deteksi fraud jaringan osis dan arsitektur co-design nya menghasilkan skema yang lebih efisien dan lebih umum, pertama-tama kami perlu membahas macam-macam jenis fraud proofs nya dulu.
Simulasi Proofs
Cara sistem optimistis rollup seperti Arbitrum dan Optimsm bekerja adalag bahwa para pesaung yang mengaku bahwa komputasi yang salah harus menyerahkan sebuah fraud proofs. Frauf proofs ini seharusnya ditampilkan supaya komputasi yang memicu pada kondisi yang salah menyimpang dari eksekusi mesin virtual yang benar dalam satu instruksi VM, yang dapat “dengan mudah” diverifikasi menggunakan simulator mesin virtual rollup yang berjalan di rantai dasar.
Hal ini tidak mudah dan sangat luar biasa. Yang menggabungkan set instruksi mesin virtual rollup dengan memvalidasi implementasi kontrak bridge. Kunci untuk mampu mengecek eksekusi tersebut tidaklah mensimulasikan seluruh eksekusi rollup mesin virtual, karena itu dapat menghasilkan biaya gas yang sangat tinggi. Terkecuali, para pesaing bermaksud untuk menyediakan bukti yang tak terbantahkan supaya pernyataan pelaksana mengenai output rollup VM menyatakan dengan menunjuk pada instruksi VM yang tepat yang tidak dijalankan dengan benar, menggunakan kondisi bisection comparing execution dan proofs Merkle. Pembangunan Proofs dapat dilakukan secara offline, dan hanya verifikasi saja yang perlu dilakukan secara online, dengan memvalidasi kontrak bridge, dengan memeriksa bahwa memang eksekusi instruksi VM yang ditunjukkan tidak mematuhi semantik VM.
Untuk semua ini berhasil, validasi kontrak bridge harus mampu mensimulasi setiap perintah rollup VM. Menjamin bahwa simulator benar dan supaya itu secara semantik setara dengan rollup VM yang sebenarnya secara teknis menantang. Sementara kompleksitas simulator tergantung pada kompleksitas set instruksi VM, kemungkinan akan membutuhkan banyak orang orang dan upaya untuk membangun simulator yang akurat dan kuat bertahun-tahun, seperti halnya Arbitrum dan Optimism.
Para pesaing yang mengklaim fraud diharapkan untuk menyerahkan fraud proofs bersama dengan klaim baru untuk status hasil yang benar. jejak eksekusi palsu F menyimpang dari jejak eksekusi yang benar pada suatu waktu t_0, pesaing dapat membuat jejak eksekusi C yang menyimpang dari jejak yang benar pada beberapa waktu kemudian langkah t_1> t_0 dan menyerahkan fraud proofs yang akan berhasil membatalkan F tetapi itu sendiri hasil fraud. Jadi, fraud proofs terhadap F tidak membuktikan bahwa C benar, dan tantangan yang berhasil dengan hasil yang berbeda harus mengatur ulang jam pengiriman tantangan sehingga C sendiri dapat ditantang. Tantangan yang berhasil bukanlah bukti konklusif bahwa hasil yang terkait dengan C adalah benar tanpa pemeriksaan tambahan oleh verifikator lain.
Sebuah manfaat dari simulasi proof ini adalah supaya mereka tetap berharga, dan diasumsikan semuanya berjalan, kami tentu yakin ketika hasilnya salah karena kami tahu di mana semantik VM dilanggar. Namun, memvalidasi bridge adalah smart contract yang di eksekusi pada Blockchain dan kebenaran hasilnya hanya probabilistik, apakah konsensus tentang pelaksanaannya terjadi pada rantai PoW atau PoS. (Dalam kasus sebelumnya, probabilitas terjadinya serangan 50%+ε yang berhasil; dalam kasus terakhir, probabilitas total taruhan berada di bawah kendali aktor Bizantium. Dalam kedua kasus, ada juga kemungkinan kegagalan mode umum seperti sebagai kerentanan zero-day dalam kode blockchain yang mendasarinya atau sistem operasi host yang memungkinkan kegagalan yang meluas.) Karena pemeriksaan bukti penipuan bersifat probabilistik, keuntungan memiliki bukti deterministik lebih teoretis daripada aktual.
Proof Bare metal
Apa yang kita maksudkan denf “bare metal proofs”? Skema bare metal proof:
- Harus kokoh. Proof ini dapat bersifat probabilistik (seperti ZKP), dengan kemampuan untuk memilih parameter keamanan yang mendorong kemungkinan kesalahan menjadi mendekati nol.
- Harus bekerja dengan mesin virtual (deterministik) apa pun tanpa adaptasi khusus mesin, termasuk VM yang merupakan ekstensi sederhana dari arsitektur set instruksi umum seperti x86–64. Skema tersebut harus memungkinkan menjalankan binari kode asli sandbox (dengan batasan untuk menghindari perilaku non-deterministik) dengan kecepatan penuh, “bare metal”, dengan ekstensi instruksi blockchain sebagai fungsi panggilan.
Secara khusus, persyaratan ini berarti bahwa sistem yang didasarkan pada bare metal fraud proofs akan jauh lebih sederhana daripada yang didasarkan pada simulasi proofs. Memvalidasi kontrak bridge tidak memerlukan akses ke status rollup mesin virtual, karena memverifikasi status memerlukan pengetahuan tentang jenis struktur data Merklized yang digunakan dan cara memeriksanya, yang khusus untuk rollup VM: ini akan memperkenalkan kebutuhan akan interface/ mekanisme untuk dasar blockchain yang memiliki akses ke status rollup dan membuat modul interface lebih kompleks. Terlebih lagi, tidak diperlukan simulasi instruksi tingkat khusus VM. Menghindari kompleksitas (yang tidak perlu) adalah tujuan keamanan yang penting karena kompleksitas menimbulkan bug.
Menariknya, dengan mengharuskan skema fraud proofs ini menjadi lebih umum, ini juga melonggarkan kendala pada desain mesin virtual rollup. Meskipun kami dapat terus mencatat smart contract dalam bahasa yang dikompilasi ke bytecode dan menggunakan penerjemah bytecode sebagai mesin virtual (yang memudahkan untuk satu langkah dan mengumpulkan jejak eksekusi Merklized), kami tidak lagi dibatasi oleh pendekatan ini. Teknik yang lebih maju dan efisien dapat diterapkan sehingga ada banyak ruang untuk peningkatan efisiensi smart contract. Misalnya, instruksi/bytecode mesin virtual dapat dikompilasi ke kode mesin untuk dijalankan di kotak pasir Software Fault Isolation (SFI) seperti RLBox, mencapai kinerja kode yang mendekati asli.
Paratime Oasis
Pada kasus Oasis, pemisahan eksekusi smart contract dari Konsesus memiliki tujuan supaya kami berakhir dengan desain bergaya rollup. Ada ParaTime yang kompatibel dengan EVM, Emerald ParaTime, antara lain yang menjalankan smart contract berbasis Rust, yang semuanya menggunakan validasi smart contract tunggal, bawaan, berorientasi objek. Tidak ada blockchain lain yang membatasi rantai dasar untuk hanya menjalankan kontrak validasi rollup.
Deteksi ketidaksesuain fraud proofs
Kami sebelumnya telah menyebutkan bahwa Oasis hanya menjalankan kontrak validasi bawaan di layer konsensus. Saat ini, ini merupakan validasi bridge gaya anti fraud bare metal di mana kami menggunakan teknik yang disebut “detection discrepancy ” untuk mendeteksi fraud dan, jika terdeteksi, “resolusi perbedaan” untuk menyelesaikannya. Gagasan utama di balik “discrepancy detection” adalah bahwa kita dapat lebih efisien dalam mendeteksi fraud daripada mengoreksi fraud itu sendiri, serupa dengan bagaimana bit redundan tambahan dalam teori pengkodean dapat digunakan untuk mendeteksi lebih banyak kesalahan daripada yang dapat mereka perbaiki. Dengan asumsi bahwa mereka menunjukkan independensi kegagalan, musuh yang mengkompromikan satu node eksekusi tidak membantu mereka berkompromi dengan yang lain, misalnya, menyuap staf operasional, menebak kata sandi mereka, dll., kita dapat menggunakan komite komputasi yang lebih kecil di mana kita mengharuskan semua tiba di titik yang sama. Hasil eksekusi smart contract.
Keamanan praktis dari desain ini lebih mudah dipahami. Desain berbasis komite menyediakan parameter keamanan yang diketahui publik, ukuran komite, yang mengeksekusi kontrak secara semi-sinkron sehingga pengguna mengetahui jumlah pemeriksaan silang serta mengetahui kapan pemeriksaan silang akan selesai, komite anggota memiliki SLA dan dapat dipotong karena kurangnya ketersediaan. kontras ini dengan rollup optimistis, di mana pengguna menunggu jumlah waktu yang tetap untuk jumlah pesaing yang potensial yang tidak diketahui atau memverifikasi perhitungan itu sendiri. Perlu dicatat, bahwa desain tidak menghalangi anggota non-komite untuk mengirimkan fraud froops, dan bahkan fraud proofs“terlambat” dari anggota non-komite dapat ditangani, lihat bagian pos pemeriksaan di artikel ini di bawah ini, jadi validasi tertutup.
Ketika terjadi ketidaksesuain fase resolusi/pemulihan perbedaan dijalankan. Untuk hasil panitia semi sinkron, kami langsung menjalankan panitia yang lebih besar untuk mencari tahu mana hasil yang benar. Ukuran komite resolusi ini jauh lebih besar — resolusi dapat dijalankan oleh seluruh komite konsensus, misalnya — sehingga akan ada kepercayaan pada hasil ini. Meskipun ini lebih mahal dalam hal komputasi dan komunikasi yang direplikasi, tidak apa-apa: ini harus sangat jarang, dan biaya diamortisasi untuk sebagian besar kasus di mana resolusi tidak diperlukan.
Tujuan efisiensi Disebabkan oleh penerapan jalur cepat/optimasi jalur lambat yang umum dalam desain sistem. Kemungkinan kasus tanpa Fraud/tanpa discrepancy yang ditangani secara efisien, dan kasus yang tidak mungkin terjadi karena harus menentukan mana dari dua atau lebih hasil yang tidak sesuai yang benar bisa lebih lambat. Lihat di sini untuk detail tentang parameter keamanan.
Layer konsensus Jaringan Oasis tidak menjalankan smart contract umum. Terkecuali, kami memanggangnya dalam memvalidasi fungsionalitas bridge yang sebaliknya dipakai sebagai smart contract dalam rollup berbasis Ethereum. Kami menggunakan deteksi discrepancy untuk memvalidasi hasil dari node di layer komputasi (ParaTime) karena lebih efisien dan lebih umum.
Untuk memahami mengapa deteksi ketidaksesuain lebih efisien, ijinkan kami untuk mempertimbangkan jumlah waktu yang diperlukan sebelum pemilihan anggota komite komputasi memungkinkan lawan berkompromi dengan komputasi. Jika dari total 100 kandidat paling banyak 33 adalah Bizantium dan kami secara acak memilih 20 untuk melayani sebagai komite komputasi, bahkan jika komposisi komite baru dipilih dengan kecepatan 100.000 per jam, musuh yang mengendalikan 33 simpul Bizantium tersebut harus menunggu 1.066 tahun yang diharapkan sebelum komite semua-Bizantium akan dipilih dan dapat digunakan untuk menyerang sistem. Skema toleransi kesalahan Bizantium yang umum dapat menggunakan replikasi 100 arah untuk mencapai konsensus; di sini, kami mereplikasi perhitungan hanya 20 kali.
Rincian analisis teknis kalkulasi dan mengapa deteksi ketidaksesuain lebih efisien dapat ditemukan di lampiran di whitepaper kami.
Karena deteksi ketidaksesuain hanya membandingkan hasil dari komputasi, itu lebih umum daripada setiap skema yang memerlukan perbandingan status perantara melalui eksekusi langkah tunggal, pendekatan yang digunakan dalam sebagian besar desain rollup optimistis. Pekerjaan yang perlu dilakukan oleh deteksi ketidaksesuain yang memvalidasi kontrak bridge di layer konsensus kecil, sehingga mudah untuk mengukur sistem secara sewenang-wenang dengan menjalankan beberapa ParaTimes secara bersamaan untuk eksekusi paralel.
Ekstensibilitas untuk skema fraud proof/validitas lainnya
Catat, bahwa meskipun layer konsensus Jaringan Oasis memanggang dalam deteksi ketidaksesuain, itu tetap dapat diperluas secara arsitektur untuk memungkinkan teknik validasi eksekusi rollup lainnya untuk diimplementasikan. Kami belum melihat kebutuhan untuk melakukannya.
Jika/ketika skema bukti zk-rollup cukup matang untuk komputasi umum, verifier zkSNARK akan menjadi tambahan yang bagus; karena jembatan validasi yang dipanggang diimplementasikan di Go, jembatan ini juga harus berjalan jauh lebih cepat daripada smart contract Solidity.
Masih ada banyak variasi/dimensi dalam ruang fraud proof yang kita tidak dapat jabarkan disini. Lihat informasi lebih lanjut mengenai desain fraud proof di sini.
Checkpointing
Deteksi ketidaksesuain memungkinkan kita untuk mengatur ukuran parameter komite supaya meyakinkan bahwa kemungkinan kompromi seluruh komite dapat diabaikan. Masih terdapat dua masalah:
- Detesi ketidaksesuain—seaindainyadilakukan untuk komite komputasi, tidak akan sepenuhnya terbuka, karena untuk memenuhi syarat sebagai node komputasi, batasan sumber daya kandidat seperti pasak diperlukan untuk mencegah serangan Sybil
- Kegagalan Mode Umum, seperti kesalahan pemrograman dalam kode Jaringan Oasis atau kernel Linux, dapat memungkinkan musuh menggunakan kompromi zero-day untuk mengambil alih semua komputasi — dan konsensus! – node jaringan.
Perlu dicatat bahwa kekhawatiran mengenai kesalahan pemrograman yang ada pada setiap jaringan, tentu saja, dan sama sekali tidak unik untuk Oasis. Faktanya, kami percaya bahwa kualitas kode Oasis dan proses peninjauan adalah yang terbaik di kelasnya.
Menangani kerentanan zero-day itu sulit. Sebenernya, seperti semua sistem perangkat lunak, tidak ada blockchain yang memiliki solusi umum selain kemungkinan melakukan hard fork. Di Oasis, kami menangani kegagalan besar skenario yang sangat tidak mungkin seperti semua komite, eksploitasi kerentanan zero-day / kegagalan mode umum, dll. — dengan membedakan penentuan pesanan transaksi dan penentuan hasil transaksi yang memungkinkan siapa pun untuk menantang hasil transaksi.
Ini artinya kami akan menambahkan pencatatan yang aman dari hash pos pemeriksaan status periodik dan pemesanan transaksi. Data ini memudahkan untuk memutar ulang transaksi dari pos pemeriksaan yang dikenal baik setelah kegagalan besar yang diidentifikasi melalui tantangan dan ditangani.
Logging harus monoton/memiliki finalitas karena kami menyertakan serangan jarak jauh/kehilangan kontrol kunci kriptografis sebagai mode kegagalan potensial. Properti ini dapat dicapai dengan menulis log ke buku besar khusus tambahan yang didistribusikan seperti blockchain lain, misalnya, Ethereum; dengan menulis ke media yang hanya ditambahkan secara fisik, misalnya, printer pengumpanan kontinu; dengan menulis ke media tulis-sekali (CD-R/DVD-R); dengan menulis ke media yang secara berkala disalin ke layanan pencadangan offline; dll. Menulis ke Ethereum akan menggunakan finalitas Ethereum untuk pada dasarnya mencap waktu pembuatan catatan log, sedangkan menulis ke mekanisme lain yang hanya menambahkan akan memerlukan verifikasi, misalnya, dengan membandingkan salinan independen, bahwa media bukanlah salinan baru tetapi diubah dari log yang sah . Lihat makalah Shades of Finality (akan segera dirilis) untuk diskusi lebih mendalam tentang finalitas pesanan transaksi dan finalitas nilai status.
Ketika ini selesai, siapapun dapat dapat menantang hasil dari lapisan komputasi, bahkan setelah deteksi perbedaan menerima hasilnya. Ini artinta bahwa kegagalan katastropik seperti komite semua-Bizantium atau kerentanan zero-day dapat ditangani jika terdeteksi secara tepat waktu. Selama ada pos pemeriksaan status valid yang mendahului kegagalan katastropik, kita memiliki kondisi yang diketahui dengan baik untuk digunakan sebagai dasar pemulihan.
Kebijakan yang direkomendasikan untuk menangani kegagalan katastropik adalah untuk menghargai urutan transaksi. Ini artinya bahwa jika seorang pesaing menunjukkan bahwa status transisi yang salah terjadi, kami dapat memutar ulang transaksi yang dicatat yang dikirimkan setelah status diketahui-baik untuk menghitung status saat ini yang benar menggunakan replikasi/verifikasi sebanyak yang diperlukan. Seperti deteksi perbedaan yang memungkinkan jalur cepat dan efisien pada kasus tanpa perbedaan versus skema yang lebih mahal untuk kasus yang jarang terjadi ketika perbedaan terdeteksi, pos pemeriksaan dan pemutaran ulang untuk memulihkan dari kegagalan katastropik bisa mahal karena kegagalan katastropik seperti itu sangat kecil kemungkinannya.
Kesimpulan
Arsitektur Jaringan Oasis dihasilkan dari desain bersama antara deteksi fraud dan arsitektur sistem. Terdapat sebuah pemisahan tugas modular antara komputasi dan Konsesus layer, dengan interface antara keduanya yang mengandung bare-metal yang sederhana dan efisien.
Manfaat-manfaat desain Oasis adalah sebagai berikut:
- Rapi, arsitektur modular, membuat desain tersebut lebih mudah difahami dan alasan tentang daripada desain monolitik. Modularitas juga di artikan kedalam implementasi yang lebih jernih, yang membuat audit keamanan akan lebih mudah.
- Deteksi fraud yang efisien, dengan parameter keamanan eksplisit yang memungkinkan desainer ParaTime memilih parameter yang sesuai untuk kasus penggunaan yang dimaksud.
- Fraud proofs bare-metal memungkinkan pengembangan masa depan lingkungan eksekusi smart contract yang berkinerja tinggi seperti kode asli sandbox, membuat smart contract komputasi atau data-intensif layak di masa depan.
- Para pengguna mengetahui batas rendah pada seberapa banyak verifikasi independen dilakukan, daripada berharap supaya validator tersedia/beroperasi selama periode tantangan, seperti dalam kasus rollup optimistis.
Hasilnya adalah bahwa Jaringan Oasis merupakan sebuah Blockchain gaya rollup, dimana konsnesus layar hanya menjalankan validasi contract bridge. Beberapa ParaTimes — mesin virtual rollup independen — telah berhasil digunakan di atas layer konsensus Oasis. Saat ini, Paratime Emerald menyediakan eksekusi smart contract yang Kompatibel dengan EVM, dan Cihper paratime akan menyediakan sebuah Lingkungan ekesekusi smart contract Konfidensial setelah dirilis pad Q1 2022.