TeleportDAO: Menyeimbangkan Keamanan Verifikasi Data dan Efisiensi - Praktik Terbaru dalam Desain Light Node

Lanjutan7/14/2024, 3:12:39 PM
TeleportDAO dan Eigen Labs baru-baru ini bersama-sama menulis sebuah makalah yang membahas masalah keamanan dan efisiensi yang dihadapi oleh light node dalam mengakses dan memverifikasi data on-chain dalam rantai blok Proof of Stake (PoS). Makalah ini memperkenalkan solusi baru yang meningkatkan keamanan dan efisiensi light node di rantai blok PoS melalui berbagai tindakan seperti insentif ekonomi, mekanisme pra-keamanan yang diasuransikan, "keamanan yang dapat diprogramkan" yang dapat disesuaikan, dan efektivitas biaya.

Singkatnya;

teleportdao dan eigen labs baru-baru ini menerbitkan makalah yang berfokus pada tantangan keamanan dan efisiensi yang dihadapi oleh light node di blockchain proof of stake (pos) ketika mengakses dan memverifikasi data on-chain. makalah tersebut mengusulkan solusi baru untuk memastikan keamanan dan efisiensi light node di blockchain pos melalui insentif ekonomi, mekanisme pre-security yang diasuransikan, "keamanan dapat diprogram," dan efektivitas biaya. pendekatan inovatif ini layak untuk penelitian lebih lanjut. catatan: eigen labs, pengembang di balik protokol restaking eigenlayer dan eigenda, telah mengumpulkan lebih dari $150 juta dari perusahaan modal ventura ternama seperti a16z, polychain, dan blockchain capital. teleportdao, yang berbasis di Vancouver, Kanada, berfokus pada infrastruktur komunikasi lintas rantai antara bitcoin dan evm public chains. protokol ini berhasil mengumpulkan $9 juta melalui penjualan publik di coinlist, dengan investor termasuk appworks, oig capital, definancex, oak grove ventures, candaq ventures, ton, across, dan bitsmiley.

masalah dengan desain light node

Saat ini, dalam blockchain pos (proof of stake), validator memastikan keamanan jaringan dengan mengunci sejumlah stake tertentu (seperti 32 eth di ethereum) untuk berpartisipasi dalam jaringan konsensus. Ini berarti bahwa keamanan blockchain pos dijaga secara ekonomi: semakin besar total stake, semakin tinggi biaya atau potensi kerugian bagi siapa pun yang mencoba menyerang jaringan. Mekanisme pengorbanan ini bergantung pada fitur yang dikenal sebagai “keamanan pertanggungjawaban,” yang memungkinkan pengorbanan stake validator jika mereka menandatangani keadaan yang saling bertentangan. Node penuh sangat penting dalam menjaga integritas blockchain pos. Mereka menyimpan semua data transaksi, memverifikasi tanda tangan konsensus, menjaga riwayat transaksi lengkap, dan menjalankan pembaruan keadaan. Tugas-tugas ini membutuhkan sumber daya komputasi yang signifikan dan perangkat keras canggih; misalnya, menjalankan node ethereum penuh membutuhkan setidaknya 2 tb penyimpanan ssd. Di sisi lain, node ringan mengurangi tuntutan sumber daya komputasi dengan hanya menyimpan header blok, sehingga cocok untuk memverifikasi transaksi/keadaan tertentu dalam aplikasi seperti dompet seluler dan jembatan lintas rantai. Namun, node ringan bergantung pada node penuh untuk informasi blok selama verifikasi transaksi. Saat ini, pangsa pasar penyedia layanan node cukup terpusat, yang mengompromikan keamanan, kemandirian, dan kecepatan. Artikel ini menjelajahi solusi untuk menyeimbangkan biaya perolehan data dan latenitas untuk mencapai keamanan optimal bagi node ringan.

solusi desain light node yang ada

bitcoin memperkenalkan verifikasi pembayaran sederhana (spv) sebagai protokol untuk light node. spv memungkinkan light node untuk memverifikasi apakah sebuah transaksi termasuk dalam blok tertentu menggunakan merkle proof dan header blok. ini berarti light node hanya perlu mengunduh header blok untuk memverifikasi finalitas transaksi dengan memeriksa kedalaman blok. akibatnya, biaya komputasi untuk verifikasi konsensus light node di bitcoin relatif rendah. namun, dalam blockchain pos seperti ethereum, pemeriksaan konsensus secara inheren lebih kompleks. mereka melibatkan pemeliharaan seluruh set validator, melacak perubahan stak mereka, dan melakukan banyak pemeriksaan tanda tangan untuk jaringan konsensus. selain itu, keamanan light node pow bergantung pada asumsi bahwa sebagian besar full node jujur. untuk mengatasi keterbatasan spv, flyclient dan bukti kerja non-interaktif (nipopow) menawarkan bukti biaya sublinear kepada klien. namun, metode ini kurang efektif untuk model konsensus pos.

dalam blockchain pos, keamanan dicapai melalui mekanisme pengorbanan. sistem ini mengasumsikan bahwa peserta konsensus adalah rasional, artinya mereka tidak akan menyerang jaringan jika biayanya melebihi potensi keuntungan apa pun. untuk menurunkan biaya verifikasi, protokol node ringan ethereum saat ini menggunakan komite sinkronisasi dari 512 validator yang dipilih secara acak, masing-masing melakukan staking 32 eth, tetapi proses penandatanganan tidak tunduk pada pengorbanan. desain non-pengorbanan ini memiliki kelemahan keamanan utama; tanda tangan tidak jujur ​​dalam komite sinkronisasi dapat menyesatkan node ringan untuk menerima data yang tidak valid tanpa hukuman apa pun. bahkan dengan mekanisme pengorbanan, total staking komite sinkronisasi kecil dibandingkan dengan kolam besar validator ethereum (lebih dari 1 juta pada Maret 2024). oleh karena itu, metode ini tidak memberikan node ringan keamanan yang setara dengan kumpulan validator ethereum. model ini adalah varian khusus dari komputasi multi-pihak di bawah pengaturan rasional tetapi tidak memiliki jaminan ekonomi dan gagal mengatasi ancaman dari penyedia data jahat, tidak rasional.

untuk mengatasi tantangan keamanan dan efisiensi dalam proses bootstrapping pos, popos memperkenalkan game tersegmentasi untuk secara efektif menantang merkle tree jahat dari pos timing. sambil mencapai persyaratan ruang minimal dan menghindari kebutuhan bagi klien untuk selalu online dan mempertahankan kepemilikan, masalah memungkinkan klien untuk offline dan bergabung kembali ke jaringan tanpa menimbulkan biaya yang signifikan masih belum terpecahkan.

pendekatan penelitian lain menggunakan bukti pengetahuan nol untuk membuat bukti yang ringkas. misalnya, mina dan plumo memfasilitasi verifikasi konsensus ringan menggunakan kombinasi snark rekursif dan bukti transisi keadaan berbasis snark. Namun, metode ini memberikan beban komputasi yang signifikan pada produsen blok untuk menghasilkan bukti dan tidak menangani pembayaran ganti rugi untuk node ringan. dalam protokol pos lainnya (seperti protokol tendermint di cosmos), peran node ringan telah dieksplorasi dalam protokol komunikasi antar-blockchain (ibc) mereka. Namun, implementasi ini disesuaikan dengan ekosistem spesifik mereka dan tidak langsung berlaku untuk ethereum atau blockchain pos lainnya.

desain rencana light node baru

Secara umum, rencana baru mencakup modul keamanan ekonomi untuk mencapai “keamanan yang dapat diprogram,” memungkinkan node ringan memilih desain yang berbeda berdasarkan kebutuhan keamanan khusus mereka. Asumsi keamanan mengikuti prinsip 1/n + 1/m, yang berarti bahwa selama ada setidaknya satu node jujur dan efektif di kedua jaringan node penuh dan jaringan inspektur, jaringan dapat berfungsi dengan baik.

modul/peran yang terlibat

  • blockchain: protokol ini dibangun di atas blockchain yang dapat diprogram dengan aturan yang ditentukan untuk finalitas blok. misalnya, pada blockchain ethereum, sebuah blok dianggap final setelah setidaknya dua epoch berikutnya, biasanya memakan waktu sekitar 13 menit.
  • kontrak pintar penggelembungan: protokol ini mencakup kontrak penggelembungan on-chain yang mengikuti abstraksi kontrak pintar standar. Hal ini dapat mengakses hash blok dari blok sebelumnya di blockchain. Semua pihak dapat mengirim informasi ke kontrak ini.
  • penyedia data: penyedia data menjalankan node penuh dan melakukan pelacakan terhadap status terbaru blockchain. Mereka menjanjikan aset dan menawarkan layanan untuk memverifikasi keabsahan status yang diminta oleh light node. Mereka menandatangani semua data yang dikirim ke light node dengan kunci yang sesuai dengan kunci publik mereka, memastikan sumber data dan integritasnya.
  • inspektur: inspektur adalah node penuh yang terhubung ke light node yang membantu memverifikasi data. siapa pun dapat menjadi inspektur dan mendapatkan imbalan dengan memantau dan memberi hukuman pada pihak yang berperilaku buruk. untuk kesederhanaan, rencana berikut mengasumsikan setiap light node terhubung setidaknya ke satu inspektur jujur.
  • node ringan: node ringan bertujuan untuk memverifikasi apakah suatu status/transaksi tertentu terdapat dalam blockchain dengan biaya minimal. mereka terhubung ke sekelompok penyedia data dan pemeriksa selama proses verifikasi.
  • jaringan: penyedia data membentuk jaringan peer-to-peer (p2p) dan menggunakan protokol gossip untuk menyebarkan data. light node terhubung ke beberapa penyedia data untuk mengirim permintaan dan menerima respons.

rencana 1: keamanan pertama

rencana 1 berfokus pada memastikan keandalan data melalui periode tantangan dan jaringan inspektur. dalam istilah sederhana, setelah light node menerima data yang ditandatangani oleh penyedia, ia meneruskan data ini ke jaringan inspektur untuk ditinjau. jika ada data palsu yang terdeteksi dalam periode tertentu, inspektur akan memberi tahu light node bahwa data tidak dapat dipercaya, dan modul penghukuman dari kontrak pintar akan menyita token yang dipertaruhkan dari penyedia data. sebaliknya, light node dapat mempercayai keandalan data tersebut. proses spesifik bagi light node untuk meminta data adalah sebagai berikut:

  1. node ringan memperoleh daftar penyedia data terbaru dari jaringan saat ini dan node ringan mengambil daftar penyedia data terbaru dari jaringan saat ini dan menetapkan periode tantangan. perhatikan bahwa periode tantangan independen untuk setiap node ringan, tetapi ada periode tantangan maksimum yang berlaku untuk semua node ringan. periode tantangan adalah waktu maksimum jaringan pemeriksa memiliki untuk memverifikasi kehandalan data, jadi semakin lama periode tersebut, semakin lama penundaan untuk transaksi tunggal.
  2. setelah mendapatkan daftar, light node memilih sekelompok penyedia data dan memastikan bahwa dana yang mereka pertaruhkan melebihi nilai transaksi saat ini. secara teori, semakin tinggi dana yang dipertaruhkan, semakin tinggi biaya bagi penyedia data untuk bertindak secara jahat, dan semakin rendah biaya kepercayaan bagi light node.
  3. Node ringan mengirim permintaan data ke kelompok penyedia data ini, termasuk nomor blok dan status target (bukti inklusi dari transaksi).
  4. penyedia data memberikan respon dengan hash blok yang sesuai dan bukti inklusi transaksi, serta tanda tangan mereka.
  5. Setelah menerima informasi ini, node ringan meneruskannya ke jaringan inspektor terhubung. Jika tidak ada peringatan keandalan data yang diterima pada akhir periode tantangan, node ringan memverifikasi tanda tangan dan, jika benar, mengkonfirmasi keandalan data.

  1. Namun, jika ada peringatan yang diterima dari jaringan inspektor, light node harus membuang tanda tangan yang sebelumnya diterima. Jaringan inspektor akan mengirimkan bukti ke modul penghilangan paksa kontrak pintar. Jika kontrak pintar memverifikasi bahwa aktivitas jahat terjadi, taruhan penyedia data akan disita. Karena beberapa atau semua penyedia data terpilih telah dikenai hukuman, light node perlu mendapatkan daftar penyedia data baru dari jaringan saat ini untuk mengonfirmasi peristiwa penghilangan paksa.

poin lainnya:

  • setiap node penuh dapat bergabung atau meninggalkan jaringan penyedia data dengan mengirimkan permintaan 'registrasi' dan 'penarikan' ke kontrak pintar. ada persyaratan minimum untuk bergabung dengan jaringan penyedia data. begitu node penuh memulai penarikan, statusnya berubah menjadi 'keluar', dan tidak akan lagi menerima permintaan dari node ringan untuk mencegah perilaku jahat yang cepat masuk dan keluar. selain itu, jaringan penyedia data memperbarui daftar penyedia aktif secara berkala. selama periode ini, penyedia data tidak dapat menarik dana mereka, dan permintaan penarikan akan berlaku pada akhir periode pembaruan saat ini. frekuensi pembaruan lebih tinggi dari periode tantangan maksimum untuk memastikan penyelesaian semua tes ketersediaan data node ringan. karena aktivitas jaringan, node ringan perlu mendapatkan daftar penyedia aktif baru pada setiap siklus pembaruan. jika siklus pembaruan diperpanjang, node ringan dapat menikmati proses verifikasi yang lebih sederhana (dengan memperkirakan daftar aktif berdasarkan permintaan 'registrasi' dan 'penarikan' sebelumnya), tetapi node yang ingin keluar akan menghadapi waktu tunggu yang lebih lama.
  • Ketika jaringan inspektur menerima tanda tangan data, ia memeriksa apakah tanda tangan milik penyedia data dan apakah data telah "akhirnya dikonfirmasi" dalam jaringan konsensus. Jika data tidak muncul pada rantai yang valid, ada dua kemungkinan. Pertama, data belum akhirnya dikonfirmasi oleh blockchain, karena rantai yang berbeda memiliki aturan finalitas yang berbeda, seperti prinsip rantai terpanjang. Kedua, transaksi berada dalam blok pada rantai lain yang valid. Jika data tersebut palsu, jaringan inspektur akan mengirimkan permintaan penyitaan ke kontrak pintar, termasuk kunci publik, tanda tangan, dan nomor blok penyedia data, bersama dengan bukti peristiwa penyitaan untuk memperingatkan simpul cahaya. Kontrak pintar akan menggunakan prinsip finalitas lapisan konsensus untuk membandingkan nomor blok yang saat ini dikonfirmasi dengan data yang diterima. Jika tidak cocok, peristiwa penyitaan dipicu. Selain itu, jika penyedia data dihukum karena serangkaian permintaan data lain setelah dipilih oleh simpul cahaya, jaringan inspektur akan segera memberi tahu simpul cahaya tentang keandalan penyedia data yang lebih rendah, mendorong simpul cahaya untuk mendapatkan daftar baru dan memilih penyedia lain.

evaluasi:

  • keamanan: light node menggunakan modul staking dan jaringan inspector untuk menentukan biaya tindakan jahat bagi penyedia data yang rasional maupun irasional, sehingga meningkatkan keandalan data. Namun, karena seluruh protokol ini didasarkan pada jaringan konsensus (diuji pada ethereum dalam makalah ini), jika lapisan konsensus diserang, protokol ini juga akan menghadapi potensi krisis kepercayaan. Oleh karena itu, mekanisme reputasi dapat diperkenalkan untuk memastikan keamanan sistem dalam kasus-kasus ekstrem.
  • keamanan tingkat node penuh: solusi ini bertujuan untuk menawarkan asumsi keamanan yang setara dengan pos ethereum, yang berarti bahwa node penuh harus memikul risiko penyitaan jika mereka membuat pernyataan palsu.
  • aktivitas jaringan: jika jaringan saat ini hanya memiliki beberapa penyedia data rasional, light node akan mengalami beberapa kali penundaan. Namun, karena throughput setiap penyedia data bukan nol, setiap permintaan masih dapat diselesaikan. Oleh karena itu, selama ada satu full node rasional dalam jaringan, jaringan dapat terus beroperasi. Selain itu, karena pendapatan penyedia data terkait dengan jumlah staking mereka, ini mendorong full node untuk melakukan staking berlebihan untuk melindungi jaringan.
  • efisiensi: para penulis memperkirakan bahwa validator ethereum akan menjadi pengguna utama yang berpartisipasi sebagai penyedia data karena mereka sudah menjalankan node penuh dan dapat menghasilkan pendapatan tambahan melalui protokol ini. Transaksi kecil mungkin mendapatkan data yang dapat diandalkan dari satu penyedia data (hanya memerlukan satu verifikasi untuk node ringan), sementara transaksi besar mungkin memerlukan beberapa penyedia data untuk mendapatkan data yang dapat diandalkan (jumlah verifikasi meningkat secara linear dengan jumlah penyedia).

rencana 2: utamakan efisiensi

rencana 2 membangun pada rencana satu dengan memperkenalkan mekanisme asuransi untuk konfirmasi data yang cepat. dengan kata sederhana, setelah node ringan menentukan asuransi berdasarkan jumlah dan durasi kebijakan, sebagian atau seluruh taruhan penyedia data dapat digunakan untuk mengganti kerugian berikutnya yang ditimbulkan oleh node ringan karena data jahat. ini memungkinkan node ringan untuk menetapkan kredibilitas awal data segera setelah menerima dan memverifikasi tanda tangan data dari penyedia. proses spesifik untuk node ringan meminta data adalah sebagai berikut:

  1. node ringan menghitung kerugian maksimum potensial dari transaksi saat ini dan kemudian menetapkan jumlah kebijakan dan durasi. dana yang dipertaruhkan oleh penyedia data dalam asuransi harus melebihi jumlah kebijakan untuk memastikan kompensasi yang memadai.
  2. node ringan menentukan periode tantangan untuk transaksi. penting untuk dicatat bahwa periode kebijakan dapat mencakup pengecekan inklusi dari beberapa transaksi, sehingga total periode tantangan yang dipilih oleh node ringan tidak boleh melebihi periode kebijakan; jika tidak, beberapa transaksi mungkin tidak dijamin.
  3. setelah memilih parameter (jumlah kebijakan, periode kebijakan, jumlah dana yang dipertaruhkan oleh penyedia data dalam asuransi, dan daftar niat penyedia data), light node mengirim permintaan ke kontrak pintar. setelah menunggu waktu konfirmasi blok terakhir, ia memverifikasi apakah pembelian asuransi berhasil. jika gagal, mungkin karena light node lain juga memilih penyedia data yang sama dan menyelesaikan terlebih dahulu, sehingga sisa taruhan tidak mencukupi untuk memenuhi permintaan asli.
  4. node ringan mengirim permintaan data, yang mencakup nomor blok, status target (bukti inklusi transaksi), dan nomor asuransi.
  5. Penyedia data mengirimkan data dan tanda tangan, yang diverifikasi oleh light node dan diteruskan ke jaringan peninjau. Transaksi kemudian dikonfirmasi secara preliminari.
  6. Setelah menerima data dan tanda tangan, inspektur awalnya memverifikasi kredibilitas data. Jika perilaku berbahaya terdeteksi, bukti diserahkan ke kontrak pintar, dan penyedia data yang sesuai dihukum, dengan penalti didistribusikan ke simpul cahaya.

poin lainnya:

  • token yang dipertaruhkan oleh penyedia data dalam asuransi bersifat independen untuk permintaan node ringan yang berbeda untuk mencegah risiko pembayaran asuransi ganda. begitu node ringan memilih penyedia data, kontrak pintar mengunci token yang dipertaruhkan yang sesuai dalam asuransi, dan node ringan lain tidak dapat mengalokasikan taruhan ini hingga periode kebijakan berakhir. jika transaksi independen, jumlah kebijakan sama dengan jumlah transaksi maksimum. jika transaksi tidak independen, jumlah kebijakan sama dengan jumlah transaksi total. dengan jumlah yang dipertaruhkan yang sama, node ringan umumnya akan memilih se sedikit mungkin penyedia data untuk memastikan efisiensi verifikasi.
  • Penyedia data dapat mengajukan permintaan "penarikan" sebelum periode asuransi berakhir, tetapi jumlah penarikan hanya akan diterima setelah periode polis berakhir.
  • secara ketat, periode kebijakan harus lebih lama dari waktu konfirmasi akhir blok + periode tantangan total + keterlambatan komunikasi + keterlambatan komputasi/verifikasi. semakin banyak penyedia data yang dipilih, semakin lama periode kebijakan yang diperlukan berdasarkan periode tantangan total.

evaluasi:

  • Scalabilitas: skalabilitas dari rencana dua tergantung pada jumlah total token yang disetor oleh penyedia data dalam asuransi.
  • biaya kebijakan: karena tingkat keamanan yang lebih tinggi terkait dengan periode tantangan, penyedia data harus melakukan penjatahan untuk jangka waktu yang sama atau lebih lama dari periode tantangan. oleh karena itu, persyaratan keamanan yang lebih tinggi mengakibatkan periode penjatahan yang lebih lama dan biaya yang lebih tinggi bagi light node. dalam istilah formula, biaya penjatahan untuk penyedia data dihitung sebagai pendapatan node penyedia data / (rata-rata penggunaan penjatahan tahunan dikalikan dengan total jumlah blok per tahun). harga yang harus dibayar oleh light node adalah biaya penjatahan dikalikan dengan periode kebijakan dan ukuran kebijakan.

efektivitas rencana

Pertama, mengenai efisiensi komputasi node ringan, kedua rencana untuk node ringan menunjukkan efisiensi verifikasi tingkat milidetik (node ringan hanya perlu memverifikasi data sekali). Kedua, mengenai laten node ringan, di bawah konfigurasi eksperimental yang berbeda (seperti yang ditunjukkan dalam gambar di bawah), laten juga berada pada tingkat milidetik. Penting untuk dicatat bahwa laten meningkat secara linear dengan jumlah penyedia data tetapi selalu tetap berada pada tingkat milidetik. Selain itu, pada rencana pertama, karena node ringan perlu menunggu hasil periode tantangan, laten adalah 5 jam. Jika jaringan pemeriksa dapat diandalkan dan cukup efisien, keterlambatan 5 jam ini dapat dikurangi secara signifikan.

Ketiga, dalam hal biaya light node, dalam praktiknya, light node menimbulkan dua biaya utama: biaya gas dan premi asuransi, keduanya meningkat dengan jumlah kebijakan. Selain itu, bagi pemeriksa, biaya gas yang terlibat dalam mengirim data akan dikembalikan oleh jumlah yang disita untuk memastikan insentif partisipasi yang cukup.

arah ekspansi

  • jaminan lebih: saat ini, penyedia data mempertaruhkan token eth, tetapi informasi transaksi dihitung dalam satuan usd. ini membutuhkan light node untuk menilai nilai tukar eth setiap kali mereka mendapatkan data untuk memastikan jaminan yang cukup. mengizinkan beberapa token untuk pertaruhan akan memberikan penyedia data lebih banyak pilihan dan mengurangi risiko yang terkait dengan satu mata uang.
  • otorisasi: mirip dengan penambangan bersama, beberapa investor ritel dapat memberikan otorisasi eth mereka kepada node penuh untuk berpartisipasi dalam jaringan penyedia data, dengan pendapatan didistribusikan sesuai dengan kesepakatan mereka, mirip dengan lsd.
  • Jaminan Blok: Untuk menghindari menunggu periode konfirmasi akhir (12-13 detik di Ethereum), Light Nodes dapat menggunakan jaminan untuk mengurangi waktu tunggu ini. Light node menambahkan simbol/pengidentifikasi saat membuat permintaan data dan menentukan jenis jaminan yang dibutuhkan (konfirmasi akhir/usulan). Penyedia data kemudian memberikan data dan tanda tangan yang sesuai setelah menerima permintaan. Jika penyedia data gagal mengusulkan blok di bawah skenario "jaminan yang diusulkan", mereka akan dihukum.

catatan: blok yang diusulkan pada akhirnya akan difinalisasi atau menjadi blok uncle.

  • biaya dan tarif: untuk jaringan inspektor, mereka perlu mempertaruhkan sejumlah token tertentu (lebih besar dari biaya gas) untuk mengirimkan bukti ke kontrak pintar. selain itu, menggunakan bukti pengetahuan nol (zkp) dapat mengurangi biaya yang terkait dengan bukti-bukti ini. di bawah mekanisme asuransi, premi yang dibayar oleh light node diberikan kepada penyedia data, sementara jaringan inspektor mengambil bagian dari pendapatan yang dirampas dari penyedia yang jahat.
  • ketersediaan data: penyedia data pada dasarnya adalah node penuh. Selain berpartisipasi dalam jaringan lapisan konsensus, mereka juga dapat memverifikasi ketersediaan data. Ada dua skema untuk memverifikasi ketersediaan: skema tarik (pull model) dan skema dorong (push model). Skema tarik melibatkan light node secara acak mengambil sampel data dari node penuh. Skema dorong melibatkan produsen blok mendistribusikan blok yang berbeda ke penyedia data. Penyedia data yang menggunakan skema tarik bertanggung jawab untuk menanggapi permintaan sampel. Light node mengirimkan data yang diterima ke node/validator terpercaya, yang mencoba merekonstruksi blok. Jika mereka tidak bisa, penyedia data akan dikenakan sanksi. Protokol light node yang diusulkan dalam makalah ini memperkenalkan mekanisme asuransi, menyediakan arah baru untuk penelitian ketersediaan data.

ringkasan dan evaluasi

Skema simpul cahaya yang diusulkan dalam makalah ini menawarkan "keamanan yang dapat diprogram" untuk memenuhi kebutuhan keamanan dalam berbagai situasi. Skema satu memprioritaskan keamanan yang lebih tinggi dengan biaya peningkatan latensi, sedangkan skema dua menggunakan mekanisme asuransi untuk menawarkan layanan "konfirmasi instan" light node. Skema ini berlaku dalam skenario yang memerlukan finalitas transaksi, seperti transaksi atom dan transaksi lintas rantai.

disclaimer:

  1. artikel ini diambil dari [iniMitramitra Eureka]. semua hak cipta milik penulis asli [ andy, arthur]. Jika ada keberatan terhadap reprint ini, silakan hubungi Gate belajartim, dan mereka akan menanganinya dengan segera.
  2. penyangkalan tanggung jawab: pandangan dan opini yang terdapat 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.

TeleportDAO: Menyeimbangkan Keamanan Verifikasi Data dan Efisiensi - Praktik Terbaru dalam Desain Light Node

Lanjutan7/14/2024, 3:12:39 PM
TeleportDAO dan Eigen Labs baru-baru ini bersama-sama menulis sebuah makalah yang membahas masalah keamanan dan efisiensi yang dihadapi oleh light node dalam mengakses dan memverifikasi data on-chain dalam rantai blok Proof of Stake (PoS). Makalah ini memperkenalkan solusi baru yang meningkatkan keamanan dan efisiensi light node di rantai blok PoS melalui berbagai tindakan seperti insentif ekonomi, mekanisme pra-keamanan yang diasuransikan, "keamanan yang dapat diprogramkan" yang dapat disesuaikan, dan efektivitas biaya.

Singkatnya;

teleportdao dan eigen labs baru-baru ini menerbitkan makalah yang berfokus pada tantangan keamanan dan efisiensi yang dihadapi oleh light node di blockchain proof of stake (pos) ketika mengakses dan memverifikasi data on-chain. makalah tersebut mengusulkan solusi baru untuk memastikan keamanan dan efisiensi light node di blockchain pos melalui insentif ekonomi, mekanisme pre-security yang diasuransikan, "keamanan dapat diprogram," dan efektivitas biaya. pendekatan inovatif ini layak untuk penelitian lebih lanjut. catatan: eigen labs, pengembang di balik protokol restaking eigenlayer dan eigenda, telah mengumpulkan lebih dari $150 juta dari perusahaan modal ventura ternama seperti a16z, polychain, dan blockchain capital. teleportdao, yang berbasis di Vancouver, Kanada, berfokus pada infrastruktur komunikasi lintas rantai antara bitcoin dan evm public chains. protokol ini berhasil mengumpulkan $9 juta melalui penjualan publik di coinlist, dengan investor termasuk appworks, oig capital, definancex, oak grove ventures, candaq ventures, ton, across, dan bitsmiley.

masalah dengan desain light node

Saat ini, dalam blockchain pos (proof of stake), validator memastikan keamanan jaringan dengan mengunci sejumlah stake tertentu (seperti 32 eth di ethereum) untuk berpartisipasi dalam jaringan konsensus. Ini berarti bahwa keamanan blockchain pos dijaga secara ekonomi: semakin besar total stake, semakin tinggi biaya atau potensi kerugian bagi siapa pun yang mencoba menyerang jaringan. Mekanisme pengorbanan ini bergantung pada fitur yang dikenal sebagai “keamanan pertanggungjawaban,” yang memungkinkan pengorbanan stake validator jika mereka menandatangani keadaan yang saling bertentangan. Node penuh sangat penting dalam menjaga integritas blockchain pos. Mereka menyimpan semua data transaksi, memverifikasi tanda tangan konsensus, menjaga riwayat transaksi lengkap, dan menjalankan pembaruan keadaan. Tugas-tugas ini membutuhkan sumber daya komputasi yang signifikan dan perangkat keras canggih; misalnya, menjalankan node ethereum penuh membutuhkan setidaknya 2 tb penyimpanan ssd. Di sisi lain, node ringan mengurangi tuntutan sumber daya komputasi dengan hanya menyimpan header blok, sehingga cocok untuk memverifikasi transaksi/keadaan tertentu dalam aplikasi seperti dompet seluler dan jembatan lintas rantai. Namun, node ringan bergantung pada node penuh untuk informasi blok selama verifikasi transaksi. Saat ini, pangsa pasar penyedia layanan node cukup terpusat, yang mengompromikan keamanan, kemandirian, dan kecepatan. Artikel ini menjelajahi solusi untuk menyeimbangkan biaya perolehan data dan latenitas untuk mencapai keamanan optimal bagi node ringan.

solusi desain light node yang ada

bitcoin memperkenalkan verifikasi pembayaran sederhana (spv) sebagai protokol untuk light node. spv memungkinkan light node untuk memverifikasi apakah sebuah transaksi termasuk dalam blok tertentu menggunakan merkle proof dan header blok. ini berarti light node hanya perlu mengunduh header blok untuk memverifikasi finalitas transaksi dengan memeriksa kedalaman blok. akibatnya, biaya komputasi untuk verifikasi konsensus light node di bitcoin relatif rendah. namun, dalam blockchain pos seperti ethereum, pemeriksaan konsensus secara inheren lebih kompleks. mereka melibatkan pemeliharaan seluruh set validator, melacak perubahan stak mereka, dan melakukan banyak pemeriksaan tanda tangan untuk jaringan konsensus. selain itu, keamanan light node pow bergantung pada asumsi bahwa sebagian besar full node jujur. untuk mengatasi keterbatasan spv, flyclient dan bukti kerja non-interaktif (nipopow) menawarkan bukti biaya sublinear kepada klien. namun, metode ini kurang efektif untuk model konsensus pos.

dalam blockchain pos, keamanan dicapai melalui mekanisme pengorbanan. sistem ini mengasumsikan bahwa peserta konsensus adalah rasional, artinya mereka tidak akan menyerang jaringan jika biayanya melebihi potensi keuntungan apa pun. untuk menurunkan biaya verifikasi, protokol node ringan ethereum saat ini menggunakan komite sinkronisasi dari 512 validator yang dipilih secara acak, masing-masing melakukan staking 32 eth, tetapi proses penandatanganan tidak tunduk pada pengorbanan. desain non-pengorbanan ini memiliki kelemahan keamanan utama; tanda tangan tidak jujur ​​dalam komite sinkronisasi dapat menyesatkan node ringan untuk menerima data yang tidak valid tanpa hukuman apa pun. bahkan dengan mekanisme pengorbanan, total staking komite sinkronisasi kecil dibandingkan dengan kolam besar validator ethereum (lebih dari 1 juta pada Maret 2024). oleh karena itu, metode ini tidak memberikan node ringan keamanan yang setara dengan kumpulan validator ethereum. model ini adalah varian khusus dari komputasi multi-pihak di bawah pengaturan rasional tetapi tidak memiliki jaminan ekonomi dan gagal mengatasi ancaman dari penyedia data jahat, tidak rasional.

untuk mengatasi tantangan keamanan dan efisiensi dalam proses bootstrapping pos, popos memperkenalkan game tersegmentasi untuk secara efektif menantang merkle tree jahat dari pos timing. sambil mencapai persyaratan ruang minimal dan menghindari kebutuhan bagi klien untuk selalu online dan mempertahankan kepemilikan, masalah memungkinkan klien untuk offline dan bergabung kembali ke jaringan tanpa menimbulkan biaya yang signifikan masih belum terpecahkan.

pendekatan penelitian lain menggunakan bukti pengetahuan nol untuk membuat bukti yang ringkas. misalnya, mina dan plumo memfasilitasi verifikasi konsensus ringan menggunakan kombinasi snark rekursif dan bukti transisi keadaan berbasis snark. Namun, metode ini memberikan beban komputasi yang signifikan pada produsen blok untuk menghasilkan bukti dan tidak menangani pembayaran ganti rugi untuk node ringan. dalam protokol pos lainnya (seperti protokol tendermint di cosmos), peran node ringan telah dieksplorasi dalam protokol komunikasi antar-blockchain (ibc) mereka. Namun, implementasi ini disesuaikan dengan ekosistem spesifik mereka dan tidak langsung berlaku untuk ethereum atau blockchain pos lainnya.

desain rencana light node baru

Secara umum, rencana baru mencakup modul keamanan ekonomi untuk mencapai “keamanan yang dapat diprogram,” memungkinkan node ringan memilih desain yang berbeda berdasarkan kebutuhan keamanan khusus mereka. Asumsi keamanan mengikuti prinsip 1/n + 1/m, yang berarti bahwa selama ada setidaknya satu node jujur dan efektif di kedua jaringan node penuh dan jaringan inspektur, jaringan dapat berfungsi dengan baik.

modul/peran yang terlibat

  • blockchain: protokol ini dibangun di atas blockchain yang dapat diprogram dengan aturan yang ditentukan untuk finalitas blok. misalnya, pada blockchain ethereum, sebuah blok dianggap final setelah setidaknya dua epoch berikutnya, biasanya memakan waktu sekitar 13 menit.
  • kontrak pintar penggelembungan: protokol ini mencakup kontrak penggelembungan on-chain yang mengikuti abstraksi kontrak pintar standar. Hal ini dapat mengakses hash blok dari blok sebelumnya di blockchain. Semua pihak dapat mengirim informasi ke kontrak ini.
  • penyedia data: penyedia data menjalankan node penuh dan melakukan pelacakan terhadap status terbaru blockchain. Mereka menjanjikan aset dan menawarkan layanan untuk memverifikasi keabsahan status yang diminta oleh light node. Mereka menandatangani semua data yang dikirim ke light node dengan kunci yang sesuai dengan kunci publik mereka, memastikan sumber data dan integritasnya.
  • inspektur: inspektur adalah node penuh yang terhubung ke light node yang membantu memverifikasi data. siapa pun dapat menjadi inspektur dan mendapatkan imbalan dengan memantau dan memberi hukuman pada pihak yang berperilaku buruk. untuk kesederhanaan, rencana berikut mengasumsikan setiap light node terhubung setidaknya ke satu inspektur jujur.
  • node ringan: node ringan bertujuan untuk memverifikasi apakah suatu status/transaksi tertentu terdapat dalam blockchain dengan biaya minimal. mereka terhubung ke sekelompok penyedia data dan pemeriksa selama proses verifikasi.
  • jaringan: penyedia data membentuk jaringan peer-to-peer (p2p) dan menggunakan protokol gossip untuk menyebarkan data. light node terhubung ke beberapa penyedia data untuk mengirim permintaan dan menerima respons.

rencana 1: keamanan pertama

rencana 1 berfokus pada memastikan keandalan data melalui periode tantangan dan jaringan inspektur. dalam istilah sederhana, setelah light node menerima data yang ditandatangani oleh penyedia, ia meneruskan data ini ke jaringan inspektur untuk ditinjau. jika ada data palsu yang terdeteksi dalam periode tertentu, inspektur akan memberi tahu light node bahwa data tidak dapat dipercaya, dan modul penghukuman dari kontrak pintar akan menyita token yang dipertaruhkan dari penyedia data. sebaliknya, light node dapat mempercayai keandalan data tersebut. proses spesifik bagi light node untuk meminta data adalah sebagai berikut:

  1. node ringan memperoleh daftar penyedia data terbaru dari jaringan saat ini dan node ringan mengambil daftar penyedia data terbaru dari jaringan saat ini dan menetapkan periode tantangan. perhatikan bahwa periode tantangan independen untuk setiap node ringan, tetapi ada periode tantangan maksimum yang berlaku untuk semua node ringan. periode tantangan adalah waktu maksimum jaringan pemeriksa memiliki untuk memverifikasi kehandalan data, jadi semakin lama periode tersebut, semakin lama penundaan untuk transaksi tunggal.
  2. setelah mendapatkan daftar, light node memilih sekelompok penyedia data dan memastikan bahwa dana yang mereka pertaruhkan melebihi nilai transaksi saat ini. secara teori, semakin tinggi dana yang dipertaruhkan, semakin tinggi biaya bagi penyedia data untuk bertindak secara jahat, dan semakin rendah biaya kepercayaan bagi light node.
  3. Node ringan mengirim permintaan data ke kelompok penyedia data ini, termasuk nomor blok dan status target (bukti inklusi dari transaksi).
  4. penyedia data memberikan respon dengan hash blok yang sesuai dan bukti inklusi transaksi, serta tanda tangan mereka.
  5. Setelah menerima informasi ini, node ringan meneruskannya ke jaringan inspektor terhubung. Jika tidak ada peringatan keandalan data yang diterima pada akhir periode tantangan, node ringan memverifikasi tanda tangan dan, jika benar, mengkonfirmasi keandalan data.

  1. Namun, jika ada peringatan yang diterima dari jaringan inspektor, light node harus membuang tanda tangan yang sebelumnya diterima. Jaringan inspektor akan mengirimkan bukti ke modul penghilangan paksa kontrak pintar. Jika kontrak pintar memverifikasi bahwa aktivitas jahat terjadi, taruhan penyedia data akan disita. Karena beberapa atau semua penyedia data terpilih telah dikenai hukuman, light node perlu mendapatkan daftar penyedia data baru dari jaringan saat ini untuk mengonfirmasi peristiwa penghilangan paksa.

poin lainnya:

  • setiap node penuh dapat bergabung atau meninggalkan jaringan penyedia data dengan mengirimkan permintaan 'registrasi' dan 'penarikan' ke kontrak pintar. ada persyaratan minimum untuk bergabung dengan jaringan penyedia data. begitu node penuh memulai penarikan, statusnya berubah menjadi 'keluar', dan tidak akan lagi menerima permintaan dari node ringan untuk mencegah perilaku jahat yang cepat masuk dan keluar. selain itu, jaringan penyedia data memperbarui daftar penyedia aktif secara berkala. selama periode ini, penyedia data tidak dapat menarik dana mereka, dan permintaan penarikan akan berlaku pada akhir periode pembaruan saat ini. frekuensi pembaruan lebih tinggi dari periode tantangan maksimum untuk memastikan penyelesaian semua tes ketersediaan data node ringan. karena aktivitas jaringan, node ringan perlu mendapatkan daftar penyedia aktif baru pada setiap siklus pembaruan. jika siklus pembaruan diperpanjang, node ringan dapat menikmati proses verifikasi yang lebih sederhana (dengan memperkirakan daftar aktif berdasarkan permintaan 'registrasi' dan 'penarikan' sebelumnya), tetapi node yang ingin keluar akan menghadapi waktu tunggu yang lebih lama.
  • Ketika jaringan inspektur menerima tanda tangan data, ia memeriksa apakah tanda tangan milik penyedia data dan apakah data telah "akhirnya dikonfirmasi" dalam jaringan konsensus. Jika data tidak muncul pada rantai yang valid, ada dua kemungkinan. Pertama, data belum akhirnya dikonfirmasi oleh blockchain, karena rantai yang berbeda memiliki aturan finalitas yang berbeda, seperti prinsip rantai terpanjang. Kedua, transaksi berada dalam blok pada rantai lain yang valid. Jika data tersebut palsu, jaringan inspektur akan mengirimkan permintaan penyitaan ke kontrak pintar, termasuk kunci publik, tanda tangan, dan nomor blok penyedia data, bersama dengan bukti peristiwa penyitaan untuk memperingatkan simpul cahaya. Kontrak pintar akan menggunakan prinsip finalitas lapisan konsensus untuk membandingkan nomor blok yang saat ini dikonfirmasi dengan data yang diterima. Jika tidak cocok, peristiwa penyitaan dipicu. Selain itu, jika penyedia data dihukum karena serangkaian permintaan data lain setelah dipilih oleh simpul cahaya, jaringan inspektur akan segera memberi tahu simpul cahaya tentang keandalan penyedia data yang lebih rendah, mendorong simpul cahaya untuk mendapatkan daftar baru dan memilih penyedia lain.

evaluasi:

  • keamanan: light node menggunakan modul staking dan jaringan inspector untuk menentukan biaya tindakan jahat bagi penyedia data yang rasional maupun irasional, sehingga meningkatkan keandalan data. Namun, karena seluruh protokol ini didasarkan pada jaringan konsensus (diuji pada ethereum dalam makalah ini), jika lapisan konsensus diserang, protokol ini juga akan menghadapi potensi krisis kepercayaan. Oleh karena itu, mekanisme reputasi dapat diperkenalkan untuk memastikan keamanan sistem dalam kasus-kasus ekstrem.
  • keamanan tingkat node penuh: solusi ini bertujuan untuk menawarkan asumsi keamanan yang setara dengan pos ethereum, yang berarti bahwa node penuh harus memikul risiko penyitaan jika mereka membuat pernyataan palsu.
  • aktivitas jaringan: jika jaringan saat ini hanya memiliki beberapa penyedia data rasional, light node akan mengalami beberapa kali penundaan. Namun, karena throughput setiap penyedia data bukan nol, setiap permintaan masih dapat diselesaikan. Oleh karena itu, selama ada satu full node rasional dalam jaringan, jaringan dapat terus beroperasi. Selain itu, karena pendapatan penyedia data terkait dengan jumlah staking mereka, ini mendorong full node untuk melakukan staking berlebihan untuk melindungi jaringan.
  • efisiensi: para penulis memperkirakan bahwa validator ethereum akan menjadi pengguna utama yang berpartisipasi sebagai penyedia data karena mereka sudah menjalankan node penuh dan dapat menghasilkan pendapatan tambahan melalui protokol ini. Transaksi kecil mungkin mendapatkan data yang dapat diandalkan dari satu penyedia data (hanya memerlukan satu verifikasi untuk node ringan), sementara transaksi besar mungkin memerlukan beberapa penyedia data untuk mendapatkan data yang dapat diandalkan (jumlah verifikasi meningkat secara linear dengan jumlah penyedia).

rencana 2: utamakan efisiensi

rencana 2 membangun pada rencana satu dengan memperkenalkan mekanisme asuransi untuk konfirmasi data yang cepat. dengan kata sederhana, setelah node ringan menentukan asuransi berdasarkan jumlah dan durasi kebijakan, sebagian atau seluruh taruhan penyedia data dapat digunakan untuk mengganti kerugian berikutnya yang ditimbulkan oleh node ringan karena data jahat. ini memungkinkan node ringan untuk menetapkan kredibilitas awal data segera setelah menerima dan memverifikasi tanda tangan data dari penyedia. proses spesifik untuk node ringan meminta data adalah sebagai berikut:

  1. node ringan menghitung kerugian maksimum potensial dari transaksi saat ini dan kemudian menetapkan jumlah kebijakan dan durasi. dana yang dipertaruhkan oleh penyedia data dalam asuransi harus melebihi jumlah kebijakan untuk memastikan kompensasi yang memadai.
  2. node ringan menentukan periode tantangan untuk transaksi. penting untuk dicatat bahwa periode kebijakan dapat mencakup pengecekan inklusi dari beberapa transaksi, sehingga total periode tantangan yang dipilih oleh node ringan tidak boleh melebihi periode kebijakan; jika tidak, beberapa transaksi mungkin tidak dijamin.
  3. setelah memilih parameter (jumlah kebijakan, periode kebijakan, jumlah dana yang dipertaruhkan oleh penyedia data dalam asuransi, dan daftar niat penyedia data), light node mengirim permintaan ke kontrak pintar. setelah menunggu waktu konfirmasi blok terakhir, ia memverifikasi apakah pembelian asuransi berhasil. jika gagal, mungkin karena light node lain juga memilih penyedia data yang sama dan menyelesaikan terlebih dahulu, sehingga sisa taruhan tidak mencukupi untuk memenuhi permintaan asli.
  4. node ringan mengirim permintaan data, yang mencakup nomor blok, status target (bukti inklusi transaksi), dan nomor asuransi.
  5. Penyedia data mengirimkan data dan tanda tangan, yang diverifikasi oleh light node dan diteruskan ke jaringan peninjau. Transaksi kemudian dikonfirmasi secara preliminari.
  6. Setelah menerima data dan tanda tangan, inspektur awalnya memverifikasi kredibilitas data. Jika perilaku berbahaya terdeteksi, bukti diserahkan ke kontrak pintar, dan penyedia data yang sesuai dihukum, dengan penalti didistribusikan ke simpul cahaya.

poin lainnya:

  • token yang dipertaruhkan oleh penyedia data dalam asuransi bersifat independen untuk permintaan node ringan yang berbeda untuk mencegah risiko pembayaran asuransi ganda. begitu node ringan memilih penyedia data, kontrak pintar mengunci token yang dipertaruhkan yang sesuai dalam asuransi, dan node ringan lain tidak dapat mengalokasikan taruhan ini hingga periode kebijakan berakhir. jika transaksi independen, jumlah kebijakan sama dengan jumlah transaksi maksimum. jika transaksi tidak independen, jumlah kebijakan sama dengan jumlah transaksi total. dengan jumlah yang dipertaruhkan yang sama, node ringan umumnya akan memilih se sedikit mungkin penyedia data untuk memastikan efisiensi verifikasi.
  • Penyedia data dapat mengajukan permintaan "penarikan" sebelum periode asuransi berakhir, tetapi jumlah penarikan hanya akan diterima setelah periode polis berakhir.
  • secara ketat, periode kebijakan harus lebih lama dari waktu konfirmasi akhir blok + periode tantangan total + keterlambatan komunikasi + keterlambatan komputasi/verifikasi. semakin banyak penyedia data yang dipilih, semakin lama periode kebijakan yang diperlukan berdasarkan periode tantangan total.

evaluasi:

  • Scalabilitas: skalabilitas dari rencana dua tergantung pada jumlah total token yang disetor oleh penyedia data dalam asuransi.
  • biaya kebijakan: karena tingkat keamanan yang lebih tinggi terkait dengan periode tantangan, penyedia data harus melakukan penjatahan untuk jangka waktu yang sama atau lebih lama dari periode tantangan. oleh karena itu, persyaratan keamanan yang lebih tinggi mengakibatkan periode penjatahan yang lebih lama dan biaya yang lebih tinggi bagi light node. dalam istilah formula, biaya penjatahan untuk penyedia data dihitung sebagai pendapatan node penyedia data / (rata-rata penggunaan penjatahan tahunan dikalikan dengan total jumlah blok per tahun). harga yang harus dibayar oleh light node adalah biaya penjatahan dikalikan dengan periode kebijakan dan ukuran kebijakan.

efektivitas rencana

Pertama, mengenai efisiensi komputasi node ringan, kedua rencana untuk node ringan menunjukkan efisiensi verifikasi tingkat milidetik (node ringan hanya perlu memverifikasi data sekali). Kedua, mengenai laten node ringan, di bawah konfigurasi eksperimental yang berbeda (seperti yang ditunjukkan dalam gambar di bawah), laten juga berada pada tingkat milidetik. Penting untuk dicatat bahwa laten meningkat secara linear dengan jumlah penyedia data tetapi selalu tetap berada pada tingkat milidetik. Selain itu, pada rencana pertama, karena node ringan perlu menunggu hasil periode tantangan, laten adalah 5 jam. Jika jaringan pemeriksa dapat diandalkan dan cukup efisien, keterlambatan 5 jam ini dapat dikurangi secara signifikan.

Ketiga, dalam hal biaya light node, dalam praktiknya, light node menimbulkan dua biaya utama: biaya gas dan premi asuransi, keduanya meningkat dengan jumlah kebijakan. Selain itu, bagi pemeriksa, biaya gas yang terlibat dalam mengirim data akan dikembalikan oleh jumlah yang disita untuk memastikan insentif partisipasi yang cukup.

arah ekspansi

  • jaminan lebih: saat ini, penyedia data mempertaruhkan token eth, tetapi informasi transaksi dihitung dalam satuan usd. ini membutuhkan light node untuk menilai nilai tukar eth setiap kali mereka mendapatkan data untuk memastikan jaminan yang cukup. mengizinkan beberapa token untuk pertaruhan akan memberikan penyedia data lebih banyak pilihan dan mengurangi risiko yang terkait dengan satu mata uang.
  • otorisasi: mirip dengan penambangan bersama, beberapa investor ritel dapat memberikan otorisasi eth mereka kepada node penuh untuk berpartisipasi dalam jaringan penyedia data, dengan pendapatan didistribusikan sesuai dengan kesepakatan mereka, mirip dengan lsd.
  • Jaminan Blok: Untuk menghindari menunggu periode konfirmasi akhir (12-13 detik di Ethereum), Light Nodes dapat menggunakan jaminan untuk mengurangi waktu tunggu ini. Light node menambahkan simbol/pengidentifikasi saat membuat permintaan data dan menentukan jenis jaminan yang dibutuhkan (konfirmasi akhir/usulan). Penyedia data kemudian memberikan data dan tanda tangan yang sesuai setelah menerima permintaan. Jika penyedia data gagal mengusulkan blok di bawah skenario "jaminan yang diusulkan", mereka akan dihukum.

catatan: blok yang diusulkan pada akhirnya akan difinalisasi atau menjadi blok uncle.

  • biaya dan tarif: untuk jaringan inspektor, mereka perlu mempertaruhkan sejumlah token tertentu (lebih besar dari biaya gas) untuk mengirimkan bukti ke kontrak pintar. selain itu, menggunakan bukti pengetahuan nol (zkp) dapat mengurangi biaya yang terkait dengan bukti-bukti ini. di bawah mekanisme asuransi, premi yang dibayar oleh light node diberikan kepada penyedia data, sementara jaringan inspektor mengambil bagian dari pendapatan yang dirampas dari penyedia yang jahat.
  • ketersediaan data: penyedia data pada dasarnya adalah node penuh. Selain berpartisipasi dalam jaringan lapisan konsensus, mereka juga dapat memverifikasi ketersediaan data. Ada dua skema untuk memverifikasi ketersediaan: skema tarik (pull model) dan skema dorong (push model). Skema tarik melibatkan light node secara acak mengambil sampel data dari node penuh. Skema dorong melibatkan produsen blok mendistribusikan blok yang berbeda ke penyedia data. Penyedia data yang menggunakan skema tarik bertanggung jawab untuk menanggapi permintaan sampel. Light node mengirimkan data yang diterima ke node/validator terpercaya, yang mencoba merekonstruksi blok. Jika mereka tidak bisa, penyedia data akan dikenakan sanksi. Protokol light node yang diusulkan dalam makalah ini memperkenalkan mekanisme asuransi, menyediakan arah baru untuk penelitian ketersediaan data.

ringkasan dan evaluasi

Skema simpul cahaya yang diusulkan dalam makalah ini menawarkan "keamanan yang dapat diprogram" untuk memenuhi kebutuhan keamanan dalam berbagai situasi. Skema satu memprioritaskan keamanan yang lebih tinggi dengan biaya peningkatan latensi, sedangkan skema dua menggunakan mekanisme asuransi untuk menawarkan layanan "konfirmasi instan" light node. Skema ini berlaku dalam skenario yang memerlukan finalitas transaksi, seperti transaksi atom dan transaksi lintas rantai.

disclaimer:

  1. artikel ini diambil dari [iniMitramitra Eureka]. semua hak cipta milik penulis asli [ andy, arthur]. Jika ada keberatan terhadap reprint ini, silakan hubungi Gate belajartim, dan mereka akan menanganinya dengan segera.
  2. penyangkalan tanggung jawab: pandangan dan opini yang terdapat 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.
Mulai Sekarang
Daftar dan dapatkan Voucher
$100
!