Lompat ke konten
Financial Context Wiki

Arsitektur blockchain modular

Panduan berbasis dependensi untuk memisahkan tanggung jawab eksekusi, pengurutan, ketersediaan data, konsensus, penyelesaian, bukti, jembatan, tata kelola, dan pengarsipan.

Diperbarui

Hanya untuk tujuan edukasi; bukan merupakan nasihat investasi atau rekomendasi investasi. Investasi dapat mengakibatkan kerugian.

Jawaban langsung

Arsitektur blockchain modular adalah cara menganalisis pembagian tanggung jawab dalam suatu sistem, bukan kategori produk yang dibakukan. Eksekusi, pengurutan transaksi, komitmen keadaan, bukti atau sengketa, publikasi data dan konsensusnya, penyelesaian, jembatan, tata kelola, serta arsip jangka panjang dapat digabungkan dalam satu protokol, dibagi di antara beberapa sistem, atau diduplikasi oleh beberapa penyedia. Satu lapisan dapat menjalankan beberapa tugas, dan satu tugas dapat bergantung pada beberapa lapisan.

Pertanyaan yang berguna bukan apakah proyek itu “modular”, melainkan komponen mana yang memvalidasi objek tertentu, siapa yang mengendalikannya, apa yang terjadi ketika komponen berhenti, dan bagaimana pengguna memulihkan keadaan atau aset secara mandiri. Tanda terima sequencer bukan ketersediaan data atau finalitas; bukti validitas tidak menyediakan data; komitmen pada rantai penyelesaian tidak membuktikan pengambilan data secara permanen; penyelesaian bersama tidak menciptakan komposabilitas sinkron lintas rollup.

Cara kerja

  1. Tetapkan sistem yang diterapkan: chain ID eksekusi dan penyelesaian, versi protokol, mesin virtual, kontrak, alamat jembatan dan aset, mode ketersediaan data, operator, administrator, serta blok atau waktu pengamatan. Taksonomi pemasaran tidak dapat menggantikan konfigurasi yang benar-benar diterapkan.
  2. Susun matriks tanggung jawab. Pisahkan penerimaan dan pengurutan transaksi, eksekusi deterministik, komitmen keadaan dan bukti atau sengketa kesalahan, publikasi DA dan konsensusnya, penerimaan penyelesaian dan finalitas, jembatan dan pesan lintas domain, peningkatan dan jeda, serta penyimpanan historis. Catat tumpang tindih, bukan memaksakan satu tugas pada satu lapisan.
  3. Telusuri satu transaksi dan batch dari awal hingga akhir: masukan yang ditandatangani, tanda terima sequencer atau lokal, eksekusi terurut, batch yang dienkode dan dikompresi, publikasi melalui calldata, blob, atau DA eksternal, klaim keadaan dan bukti atau sengketa, finalitas penyelesaian, lalu eksekusi pesan atau penarikan. Simpan hash, versi, tanda terima, dan waktu pada setiap batas.
  4. Identifikasi setiap objek yang diverifikasi dan asumsi kepercayaannya. Bedakan komitmen data dari byte, ketersediaan selama jendela protokol dari pengambilan kemudian, validitas eksekusi dari finalitas konsensus, serta pembukuan jembatan dari likuiditas aset. Nyatakan siapa yang dapat memutar ulang, membuktikan, menantang, menyensor, meningkatkan, menjeda, atau menahan setiap objek.
  5. Rekonstruksi buku besar kapasitas dan biaya. Ukur byte mentah dan terkompresi, keterisian batch, harga DA, overhead bukti dan penyelesaian, biaya eksekusi dan operator, gas jembatan, serta biaya likuiditas. Alokasi batch rata-rata tidak sama dengan tagihan aktual pengguna atau biaya marginal satu transaksi tambahan.
  6. Uji kegagalan, bukan hanya membaca throughput jalur normal. Hentikan sequencer, pengirim batch, pembukti, penantang, layanan DA, RPC penyelesaian, dan relay jembatan; uji inklusi paksa, derivasi independen, rekonstruksi data, bukti atau sengketa, percobaan ulang, keluar, dan pemulihan arsip ketika terjadi kepadatan dan pada batas peningkatan.
  7. Rekonsiliasi dengan bukti kanonis. Cocokkan tanda terima eksekusi dan akar keadaan dengan komitmen batch, inklusi DA, status bukti atau permainan, finalitas penyelesaian, pesan jembatan, serta saldo aset akhir. Ulangi peninjauan dependensi setelah reorganisasi, perubahan parameter, peningkatan kontrak, atau migrasi DA.

Contoh terhitung

  • Biaya batch dan kompresi. Satu batch berisi 5,000 transaksi, 2,400 KB masukan mentah, dan 300 KB setelah kompresi. Rasio kompresi adalah 2,400 / 300 = 8.0x, dan jumlah byte turun 87.5%. Jika DA berbiaya 0.020 ETH dan overhead bukti serta penyelesaian bersama berbiaya 0.005 ETH, rata-rata biaya bersama adalah (0.020 + 0.005) / 5,000 = 0.000005 ETH/tx. Menambahkan biaya eksekusi dan operator 0.000020 ETH/tx menghasilkan 0.000025 ETH/tx. Ini adalah alokasi, bukan tagihan yang dijamin.
  • Batas model pengambilan sampel. Dalam model pembelajaran, penyerang menahan 25% bagian dan klien mengambil 20 sampel seragam independen dengan pengembalian. Peluang melewatkan semua bagian yang ditahan adalah 0.75^20 = 0.003171211939 = 0.3171211939%; peluang deteksinya 99.6828788061%. Peer yang berkorelasi, penyajian adaptif, kode penghapus, dan aturan sampling protokol sebenarnya dapat membatalkan model sederhana ini.
  • Keamanan dan kelangsungan komite. Komite DA 5-of-7 dapat membentuk pengesahan ambang baru ketika paling banyak 2 anggota tidak tersedia; jika 3 tidak tersedia, hanya tersisa 4 < 5. Dalam aturan pembelajaran berbasis tanda tangan saja, penguasaan 5 penanda tangan berwenang dapat memenuhi ambang. Sertifikat tetap tidak membuktikan bahwa ada lima salinan tahan lama, pengguna dapat mengambil byte sekarang, atau eksekusi dan penyelesaian valid.
  • Beberapa waktu dan keluar cepat. Konfirmasi awal pembelajaran tiba dalam 2 seconds, batch dipublikasikan setelah 8 minutes, dan finalitas penyelesaian 13 minutes kemudian; durasi tepatnya 21 minutes 2 seconds. Jika penarikan optimistis menambah waktu hipotesis 7 days, totalnya 10,101 minutes 2 seconds. Jembatan cepat yang mengenakan 0.15% atas 10,000 USDC mengambil 15 USDC dan mengirim 9,985 USDC; kecepatan menambah asumsi jembatan, penyedia likuiditas, dan reorganisasi, bukan memperpendek waktu protokol.

Risiko

  • Salah mengidentifikasi tanggung jawab atau batas lapisan yang sebenarnya.
  • Penyensoran, pengurutan ulang, atau gangguan sequencer.
  • Inklusi paksa tidak tersedia, berizin, atau terlalu lambat.
  • Gangguan pengirim batch atau pengusul keadaan.
  • Kegagalan pembukti terpusat atau antrean bukti.
  • Tidak ada penantang kesalahan yang aktif, memenuhi syarat, dan didanai.
  • Kegagalan waktu permainan kesalahan, jaminan, oracle, atau verifikator.
  • Cacat sirkuit validitas, sistem pembuktian, atau kunci verifikasi.
  • Penahanan data selama jendela ketersediaan yang diwajibkan.
  • Pengambilan sampel berkorelasi, serangan eclipse, atau kegagalan tampilan jaringan.
  • Kolusi ambang komite DA atau kompromi kunci.
  • Data protokol tersedia tetapi tidak memiliki arsip independen yang tahan lama.
  • Reorganisasi penyelesaian atau kesalahan klasifikasi finalitas.
  • Kegagalan jembatan, pengirim pesan, perlindungan replay, atau eksekusi tujuan.
  • Insolvensi jembatan cepat, kekurangan persediaan, atau harga yang merugikan.
  • Kompromi administrator, multisig, atau dewan keamanan.
  • Peningkatan seketika, versi tidak kompatibel, atau jeda keluar yang tidak memadai.
  • Lonjakan biaya DA, kepadatan blob, batch lebih kecil, atau berakhirnya subsidi.
  • Ketidakcocokan versi keadaan, data, bukti, kontrak, atau klien.
  • Pengurutan lintas domain asinkron, penyelesaian parsial, atau kegagalan komposabilitas.

Kesalahpahaman umum

  • Arsitektur modular otomatis lebih terdesentralisasi daripada desain monolitik.
  • Bukti validitas menggantikan ketersediaan data dan pengambilan historis.
  • Penyelesaian di Ethereum memasukkan setiap sifat keamanan Ethereum ke semua komponen.
  • Pesan sukses dari sequencer berarti penyelesaian final dan penarikan dapat dieksekusi.
  • TPS lebih tinggi, DA bersama, atau penyelesaian bersama menjamin biaya rendah dan komposabilitas sinkron.

Topik terkait

Sumber

Navigasi

Cari di wiki...