Sejauh ini, mitos kesejahteraan dalam lingkaran mata uang/industri blockchain terus berlanjut, dan bidang penting berikutnya dalam "menciptakan kekayaan" adalah fokus pada "jalur permainan". Proyek XAI sedang mengadakan acara Odyssey. Jika Anda tertarik, silakan berpartisipasi dalam artikel saya ini di alun-alun: Panduan Pemula Acara Odyssey Rantai Publik Game XAI Tanpa Biaya
Pada artikel ini, saya akan memberikan Anda penjelasan mendetail tentang node Sentry dari rantai publik game XAI! Artikel ini relatif teknis, jadi jika Anda tertarik menghasilkan uang, Anda harus membacanya dengan cermat. Karena hanya jika Anda memahami "logika" diri Anda dan meningkatkan kognisi Anda, Anda dapat memiliki peluang menghasilkan uang!
Jika ingin melihat langsung tentang node Sentry, baca langsung bagian pertama tanpa membaca nanti; jika ingin loop tertutup logis, maka Anda perlu membaca bagian kedua, ketiga, dan keempat!
Yang ingin saya tekankan adalah Xai menerima dukungan teknis langsung dari Offchain Labs. Dukungan semacam ini tidak terbayangkan untuk rantai Orbit lainnya! dan merupakan komponen kunci dari rencana permainan strategis Xai dalam ekosistem Arbitrum.
Bagian 1: Penjelasan simpul penjaga
Node Sentry adalah node observasi yang memantau protokol rollup Xai dan jika ada blok buruk yang diajukan, ia akan mengeluarkan peringatan (dengan cara apa pun yang dipilih operatornya) sehingga orang lain dapat melakukan intervensi. Tujuan dari sentinel node adalah untuk memecahkan dilema verifikator (lihat Bagian IV untuk rincian dilema verifikator).
Klik di sini untuk melihat video promosinya:
Jalankan node Xai dan dapatkan token Xai dengan satu klik!
Node sentinel dapat berjalan di laptop, desktop, atau bahkan cloud anggota komunitas. Selama node berjalan, terdapat algoritma probabilistik yang menentukan apakah operator node akan diberi hadiah token esXai dari jaringan. Dengan mempertaruhkan Xai, Anda meningkatkan kemungkinan algoritma. Jika Anda belum tahu tentang esXai, silakan berpartisipasi dalam artikel saya di lapangan: Interpretasi “Ekonomi Token” dari proyek XAI
1. Prinsip kerja simpul sentinel
Protokol Attention Challenge v2 melibatkan banyak peserta, termasuk rantai Xai, rantai induk (Arbitrum One), penantang tepercaya, penjaga Xai dan kunci lisensinya, serta kontrak Wasit (wasit). Penantang membuat pasangan kunci BLS, mendaftarkan kunci publik ke kontrak wasit, dan menandatangani klaim yang dibuat oleh validator dalam protokol rollup Xai di Arbitrum One. Tanda tangan ini diverifikasi oleh kontrak wasit dan dicatat sebagai tantangan yang terkait dengan klaim tersebut.
Xai Sentinel dapat mendaftar ke kontrak wasit dengan membeli kunci lisensi Sentinel agar memenuhi syarat untuk mempublikasikan pernyataan tentang klaim. Mereka mendapatkan akar negara bagian dari pernyataan yang benar yang akan menjadi penerus pernyataan yang mengeluarkannya. Jika syarat tertentu terpenuhi, mereka mengeluarkan pernyataan tentang pernyataan tersebut dengan meminta kontrak wasit. Jika pernyataan tindak lanjut dibuat dan dikonfirmasi, dan Sentinel mengeluarkan pernyataan yang benar, Sentinel akan menghubungi kontrak wasit untuk mengeluarkan transaksi penukaran. Wasit akan memverifikasi beberapa kondisi sebelum membayar hadiah kepada Sentinel.
Protokol ini memastikan bahwa setiap klaim harus sepenuhnya menggunakan pesan kotak masuk yang ada saat klaim pendahulunya dibuat. Artinya, setelah klaim dibuat, akar status dari klaim berikutnya yang benar sepenuhnya ditentukan dan dapat dihitung oleh node mana pun. Hal ini mendorong setiap penjaga untuk menentukan root keadaan berikutnya yang benar. Imbalan sentinel ditentukan oleh ID izin negara bagian sentinel, akar negara berikutnya, dan nilai tantangan yang tidak diketahui sampai akar negara berikutnya ditentukan sepenuhnya.
2. Siapa yang dapat menjalankan node tersebut?
Siapa pun dapat mengoperasikan Sentinel dengan mengunduh perangkat lunak, menginstalnya, dan menjalankannya. Namun, untuk menerima hadiah token, setidaknya satu kunci lisensi Sentinel harus dibeli.
Pembeli harus berhasil melewati pemeriksaan KYC untuk memastikan mereka:
bukan di Amerika Serikat
Tidak terkena sanksi OFAC AS (OFAC tercermin dalam daftar sanksi AS)
Node Sentinel yang tidak berjalan atau tidak memiliki dana yang sesuai untuk membayar biaya bahan bakar (GAS) tidak akan memperoleh imbalan, bahkan dengan kunci lisensi. Oleh karena itu, operator ingin memastikan bahwa node mereka didanai, online, dan berjalan.
3. Kontrak wasit (wasit).
Wasit adalah kontrak pintar yang dirancang untuk menegakkan kepatuhan terhadap aturan yang telah ditentukan, memverifikasi asal usulan, dan mendistribusikan hadiah kepada pemenang dalam sistem. Kontrak pintar wasit adalah komponen kunci dalam ekosistem Xai, yang bertanggung jawab untuk mengelola dan memvalidasi klaim yang dibuat oleh node sentinel di jaringan. Kontrak ini mempunyai beberapa fungsi utama:
3.1 Penyampaian pernyataan
Kontrak wasit memungkinkan node sentinel untuk mengajukan klaim terhadap tantangan. Fungsi ini hanya dapat dipanggil oleh pemilik kunci lisensi Sentinel atau alamat mereka yang disetujui dalam kontrak ini. Fungsi ini memeriksa apakah tantangan masih terbuka untuk diajukan dan apakah NodeLicense telah dikirimkan untuk tantangan ini.
3.2 Menerima hadiah
Kontrak tersebut berisi fitur yang memungkinkan pengguna mengklaim imbalan atas klaim yang berhasil. Fungsi ini memeriksa apakah tantangan telah ditutup untuk diserahkan dan memeriksa apakah pemilik kunci simpul telah menyelesaikan KYC. Jika ketentuan ini terpenuhi dan klaim memenuhi syarat untuk pembayaran, hadiah akan dikirimkan kepada pengguna.
3.3 Buat hash klaim dan periksa pembayaran.
Kontrak memiliki fungsi yang membuat hash dari ID izin sentinel, ID tantangan, ChallengerSignedHash dalam tantangan, dan root status berikutnya. Ia kemudian memeriksa apakah hash berada di bawah ambang batas tertentu, yang dihitung berdasarkan jumlah total lisensi Sentinel yang telah dicetak. Jika hash berada di bawah ambang batas, klaim memenuhi syarat untuk dibayar.
Kontrak wasit memastikan integritas jaringan Xai dengan memvalidasi klaim dan memberi penghargaan kepada klaim yang berhasil, sehingga memberikan insentif kepada node sentinel untuk memantau jaringan secara akurat dan rajin.
4. Komponen penantang
Penantangnya adalah entitas tepercaya di ekosistem Xai. Ini menciptakan pasangan kunci BLS dan mendaftarkan kunci publik ke kontrak wasit. Ketika validator membuat klaim dalam protokol rollup Xai, penantang menandatangani klaim menggunakan kunci pribadinya dan menyerahkan tanda tangan tersebut kepada wasit. Wasit memverifikasi tanda tangan dan mencatatnya sebagai tantangan terkait dengan pernyataan tersebut. Proses ini memastikan integritas klaim yang dibuat dalam protokol rollup Xai.
5. Kunci (Izin kunci simpul Sentinel, berdasarkan NFT)
Kunci Lisensi Sentinel adalah token unik dan non-fungible (NFT) yang diperlukan untuk mengoperasikan node Sentinel di jaringan Xai. Lisensi sentinel berfungsi sebagai bukti kelayakan node untuk mengajukan klaim dan menerima hadiah. Itu dicetak dengan mengirimkan jumlah ETH yang benar, dan harga pencetakan ditentukan oleh sistem ambang batas yang meningkat.
Lisensi node memainkan peran penting dalam kontrak wasit. Saat sebuah node ingin mengajukan klaim terhadap suatu tantangan, node tersebut harus memberikan ID izin Sentinelnya. Kontrak wasit memeriksa apakah lisensi Sentinel valid dan apakah node tersebut adalah pemilik lisensi Sentinel atau operator yang disetujui (bagian KYC di atas). Jika kondisi ini terpenuhi, klaim node akan diajukan ke tantangan.
Izin penjaga juga berperan saat mengklaim hadiah atas klaim yang berhasil. Kontrak wasit memeriksa apakah pemilik lisensi Sentinel telah menyelesaikan KYC dan apakah pernyataan tersebut memenuhi syarat untuk pembayaran. Jika ketentuan ini terpenuhi, hadiah akan dikirimkan kepada pemilik lisensi Sentinel.
Singkatnya, izin Sentinel adalah komponen kunci dalam jaringan Xai, yang mengatur pengoperasian node Sentinel, pengajuan klaim, dan distribusi hadiah.
6. Unduh dan jalankan node
Untuk menjalankan sentinel node, pengguna hanya perlu mengunduh paket perangkat lunak tertentu. Paket ini dapat digunakan dalam aplikasi desktop atau sebagai alat baris perintah di komputer Anda. Sederhananya, aplikasi ini adalah alat yang membuat perangkat lunak Sentinel lebih mudah digunakan. Tujuan dari paket ini adalah untuk mengotomatiskan semua operasi yang diperlukan untuk menjalankan Sentinel, membuatnya sangat mudah untuk diatur dan digunakan, bahkan jika Anda bukan ahli teknis.
Paket ini membantu pengguna dengan tugas-tugas seperti pengaturan, manajemen, dan interaksi dengan bagian lain, dan memiliki antarmuka yang mudah digunakan yang memungkinkan pengguna untuk melihat dan menyesuaikan pengaturan dengan mudah. Dengan menggunakan paket ini, pengguna dapat lebih fokus pada cara berjalan lebih baik dan mendapatkan lebih banyak hadiah token. Pengguna dapat memilih untuk menjalankan paket ini menggunakan aplikasi desktop atau alat baris perintah, keduanya sangat mudah digunakan dan membuat proses pengoperasian menjadi sangat lancar.
7. Fungsi dompet penjaga
Di ekosistem Xai, dompet Sentinel memainkan peran penting dalam interaksi antara node Sentinel dan kontrak pintar wasit. Dompet Sentinel bertindak sebagai agen perantara dan bertanggung jawab untuk mengirimkan pernyataan kepada wasit atas nama Sentinel terkait. Hal ini dicapai melalui fungsi khusus dalam kontrak wasit yang hanya dapat dipanggil oleh pemilik kunci lisensi Sentinel atau alamat mereka yang disetujui dalam kontrak ini.
Dompet Sentinel dapat mengirimkan pernyataan ke tantangan dengan memanggil fungsi submitAssertionToChallenge dalam kontrak wasit. Fungsi ini memeriksa apakah tantangan masih terbuka untuk diajukan dan apakah kunci simpul telah dikirimkan untuk tantangan ini.
Dompet Penjaga juga dapat mengklaim hadiah untuk klaim yang berhasil dengan memanggil fungsi klaimReward dalam kontrak referensi. Fitur ini memeriksa apakah tantangan telah ditutup untuk pengajuan dan memeriksa apakah pemilik lisensi Sentinel telah menyelesaikan pemeriksaan "KYC". Jika ketentuan ini terpenuhi dan klaim memenuhi syarat untuk pembayaran, hadiah akan dikirimkan kepada pemilik Sentinel.
Singkatnya, Dompet Sentinel bertindak sebagai pembawa pesan, memfasilitasi interaksi antara node dan wasit, sehingga memastikan kelancaran pengoperasian jaringan Xai.
8. Lisensi
Hubungan antara jumlah lisensi dan kemampuan penyerahan node sangatlah mendasar. Meskipun mungkin saja sebuah node memiliki beberapa lisensi yang terkait dengannya, penting untuk menyadari bahwa jumlah lisensi secara langsung mempengaruhi kemampuan node untuk melakukan commit. Pada dasarnya, untuk memastikan kuota penerapan yang adil, rasio lisensi terhadap instance node dipertahankan pada 1:1. Dengan mengikuti prinsip-prinsip di atas, sistem ini menetapkan pendekatan terstruktur terhadap perizinan, penyerahan hak, dan pengoperasian simpul secara keseluruhan dalam ekosistem.
9. Persyaratan perangkat lunak dan perangkat keras simpul penjaga
Perangkat lunak node sentinel mendukung desktop Windows, Mac dan Linux (memerlukan 64-bit). Berikut ini adalah sumber daya saat ini yang diperlukan untuk menjalankan perangkat lunak simpul Sentinel hingga 100 kunci lisensi:
RAM 4GB
2 inti CPU
Ruang disk 60 GB
Prosesor x86/X64 (mendukung prosesor ARM, seperti chip Apple M1/M2)
Koneksi internet yang stabil
Saat menambahkan kunci tambahan ke sebuah node, idealnya kemampuan perangkat keras harus meningkat. Namun, tidak wajib untuk menetapkan mesin terpisah untuk setiap kunci. Sistem ini diharapkan dapat diskalakan untuk mengakomodasi lusinan kunci pada satu mesin, dan mungkin lebih.
Catatan: Persyaratan perangkat keras ini dapat berubah.
10. Perkiraan imbalan jaringan node Sentry
Model ekonomi token XAI, silakan lihat: Interpretasi "Ekonomi Token" dari proyek XAI
Berikut adalah tiga skenario untuk memperkirakan imbalan Xai yang mungkin Anda peroleh dari menjalankan node Sentry. Ketiga skenario ini didasarkan pada asumsi berikut:
Jumlah XAI dan esXAI tidak akan pernah melebihi 2.500.000.000. Mengingat ekosistem Xai bersifat dinamis, tidak mungkin memprediksi secara akurat hadiah token bulanan untuk setiap kunci Sentry.
100% GAS dibakar, jadi tidak ada jaminan pasokan akan selalu inflasi, bisa saja deflasi.
Xai Foundation tidak akan menjual lebih dari 50.000 kunci Sentry (satu node dapat memuat banyak kunci). Hal ini diperkirakan akan memakan waktu 2-3 tahun. Kunci penjaga menjadi lebih mahal seiring waktu.
Jumlah esXAI bulanan per kunci Sentry juga dapat berfluktuasi berdasarkan jumlah peserta staking di ekosistem.
Arti dari tiga tabel berikut adalah bahwa di bawah sirkulasi token XAI dan esXAI yang berbeda, jumlah kunci node yang diaktifkan di jaringan dan imbalan token bulanan yang diharapkan per kunci:
Skenario Perkiraan: Jika total ada 750.000 token XAI dan esXAI yang beredar, maka setiap kunci Sentry akan menerima hadiah esXAI sesuai tabel berikut:
Perkiraan Skenario B: Jika total ada 1.250.000.000 token XAI dan esXAI yang beredar, maka setiap kunci Sentry akan menerima hadiah esXAI sesuai tabel berikut:
Perkiraan Skenario C: Jika total ada 2.187.500.000 token XAI dan esXAI yang beredar, maka setiap kunci Sentry akan menerima hadiah esXAI sesuai tabel berikut:
Bagian 2: XAI dikembangkan dan dikelola oleh Arbitrum (ARB), jadi kita harus menjelaskan arsitektur Arbitrum:
1. Keputusan Nitro
Semua rantai Arbitrum dibangun di atas Arbitrum Nitro, yang merupakan teknologi dasar untuk semua rantai di ekosistem. Nitro menjalankan Geth versi bercabang dan menggunakan WebAssembly sebagai mesin virtual yang mendasari anti penipuan.
2. Keputusan kepercayaan apa pun
Anytrust adalah protokol Arbitrum yang mengelola ketersediaan data melalui kumpulan pemberi lisensi yang disebut Komite Ketersediaan Data (DAC). Protokol ini mengurangi biaya transaksi dengan memperkenalkan asumsi kepercayaan tambahan mengenai ketersediaan data, daripada menggunakan mekanisme ketersediaan data Ethereum yang tidak dapat dipercaya.
3. Pengenalan Arbitrum 2 layer yang mungkin anda ketahui
Arbitrum Nova adalah contoh rantai AnyTrust; Arbitrum One adalah rantai alternatif lain yang mengimplementasikan protokol Arbitrum Rollup yang murni tidak dapat dipercaya (dan lebih intensif gas L1). Kedua rantai dibangun di atas Nitro.
4. Rantai orbit
Arbitrum Orbit memungkinkan pihak ketiga membuat rantai Arbitrum Rollup dan AnyTrust yang dikelola sendiri. Arbitrum menawarkan teknologi Rollup dan AnyTrust untuk fleksibilitas maksimum saat membangun rantai Orbit. Seperti semua rantai di ekosistem Arbitrum, baik Arbitrum Rollup maupun rantai Arbitrum Anytrust Orbit dibuat menggunakan Nitro sebagai teknologi dasarnya.
5. Memahami situasi dasar Xai
Mari kita pahami Xai dalam konteks di atas. Xai beroperasi sebagai rantai Arbitrum Orbit, memanfaatkan teknologi Anytrust untuk kecepatan maksimum dan biaya minimum. Tidak seperti kebanyakan rantai Orbit yang “berpemerintahan sendiri”, Xai mendapat manfaat dari dukungan teknis langsung dari Offchain Labs. Dukungan semacam ini tidak terbayangkan untuk rantai Orbit lainnya! dan merupakan komponen kunci dari rencana permainan strategis Xai dalam ekosistem Arbitrum.
Part 3: Setelah Anda memiliki konsep di atas, mari kita pahami lebih jauh arsitekturnya:
1.AnyTrust: Infrastruktur Blockchain Revolusioner
Dalam kerangka AnyTrust dan sebagai varian mutakhir dari teknologi Arbitrum Nitro, Offchain Labs memanfaatkan inovasi untuk memecahkan beberapa tantangan paling mendesak di bidang blockchain. AnyTrust memberi kita perspektif baru dengan memasukkan asumsi kepercayaan yang ringan, mengurangi biaya secara signifikan sekaligus memastikan ketersediaan dan keamanan data yang kuat.
2. Mengurangi biaya melalui asumsi kepercayaan
Inti dari protokol Arbitrum, semua node Arbitrum (termasuk validator yang memverifikasi kebenaran rantai dan mempertaruhkan hasil yang akurat) perlu mengakses data setiap transaksi lapisan dua (L2) di kotak masuk rantai Arbitrum. Secara tradisional, Arbitrum rollup memastikan akses data dengan menerbitkan data sebagai calldata pada lapisan satu (L1) Ethereum, sebuah proses yang menghasilkan biaya gas Ethereum yang signifikan, yang merupakan komponen biaya utama di Arbitrum.
3. Fleksibilitas Ketset
Ketset memainkan peran penting dalam arsitektur AnyTrust. Mereka menentukan kunci publik anggota komite dan jumlah tanda tangan yang diperlukan untuk memverifikasi Sertifikat Ketersediaan Data (DACert). Ketset memberikan fleksibilitas untuk mengganti anggota komite dan memungkinkan anggota komite memperbarui kunci mereka sesuai kebutuhan.
4. Sertifikat Ketersediaan Data (DACerts)
Di AnyTrust, konsep dasarnya adalah sertifikat ketersediaan data (DACert). DACert terdiri dari hash blok data, waktu kedaluwarsa, dan bukti bahwa anggota komite N-1 telah menandatangani pasangan (hash, waktu kedaluwarsa). Bukti ini mencakup hash dari kumpulan kunci yang digunakan untuk tanda tangan, bitmap yang menunjukkan anggota komite mana yang menandatangani, dan tanda tangan agregat BLS pada kurva BLS12-381, yang membuktikan penandatangan.
Karena asumsi kepercayaan 2-of-N, DACert berfungsi sebagai bukti bahwa data blok akan tersedia untuk setidaknya satu anggota komite yang jujur hingga waktu kedaluwarsa yang ditentukan. Asumsi kepercayaan ini menjadi dasar keandalan dan keamanan ketersediaan data dalam kerangka AnyTrust.
5. Mekanisme rilis data ganda
AnyTrust memperkenalkan metode ganda untuk menerbitkan blok data di L1. Selain metode tradisional dalam menerbitkan blok data lengkap, ini juga memungkinkan penerbitan DACerts, yaitu sertifikat yang membuktikan ketersediaan data. Kontrak kotak masuk L1 memverifikasi validitas DACerts, termasuk referensi ke Keset valid yang ditentukan dalam DACert.
Kode L2 yang bertanggung jawab untuk membaca data dari kotak masuk dirancang untuk menangani kedua format data dengan lancar. Ketika DACert ditemukan, DACert melakukan pemeriksaan validitas, termasuk memastikan bahwa jumlah penandatangan memenuhi persyaratan Ketsets, memvalidasi tanda tangan agregat, dan mengonfirmasi kedaluwarsa di luar stempel waktu L2 saat ini. DACerts yang valid memastikan bahwa blok data dapat diakses dan dapat dieksploitasi oleh kode L2.
6. Server Ketersediaan Data (DAS)
Anggota komite mengoperasikan Server Ketersediaan Data (DAS), yang menyediakan dua API utama:
(1) API Penyortir: Dirancang untuk digunakan oleh penyortir rantai Arbitrum, antarmuka JSON-RPC ini memungkinkan penyortir mengirimkan blok data ke DAS untuk disimpan.
(2) REST API: Dirancang untuk aksesibilitas yang lebih luas, protokol berbasis RESTful HTTP(S) memungkinkan pengambilan potongan data melalui hash. Ini sepenuhnya dapat di-cache dan dapat digunakan bersama dengan proxy caching atau CDN untuk meningkatkan skalabilitas dan melindungi terhadap potensi serangan DoS.
7. Interaksi Komite Penyortir
Ketika penyortir Arbitrum bermaksud untuk mempublikasikan sekumpulan data melalui komite, ia mengirimkan data dan waktu kedaluwarsa ke semua anggota komite secara paralel melalui RPC. Setiap anggota komite menyimpan data, menandatangani pasangan (hash, waktu kedaluwarsa) menggunakan kunci BLS-nya, dan mengembalikan tanda tangan dan indikator keberhasilan ke sequencer. Setelah cukup tanda tangan dikumpulkan, sequencer mengumpulkannya untuk membuat DACert yang valid untuk pasangan (hash, waktu kedaluwarsa). DACert ini kemudian dipublikasikan ke kontrak kotak masuk L1, sehingga dapat diakses oleh perangkat lunak rantai AnyTrust L2. Jika sequencer tidak dapat mengumpulkan cukup tanda tangan dalam jangka waktu yang ditentukan, sequencer akan mengadopsi strategi "fallback to rollup" dan mempublikasikan data lengkap langsung ke rantai L1. Perangkat lunak L2 unggul dalam memahami format penerbitan data (melalui DACert atau data lengkap) dan menangani setiap format dengan tepat. Singkatnya, AnyTrust, sebagai inovasi inovatif dalam ekosistem Offchain Labs, mewakili kemajuan penting dalam mengatasi ketersediaan data, keamanan, dan efisiensi biaya infrastruktur blockchain. Melalui asumsi kepercayaan yang masuk akal dan pendekatan baru terhadap penerbitan data, AnyTrust membuka jalan bagi solusi blockchain yang lebih terukur, mudah diakses, dan aman.
Bagian 4: Dengan mempertimbangkan konsep di atas, sekarang mari kita jelaskan mengapa sentinel node penting: masalah pemeriksaan cheater, mengapa dilema validator lebih sulit dari yang Anda kira, dan solusinya!
Penulisnya adalah Ed Felten, kepala ilmuwan di Arbitrum
Dalam sistem blockchain, pola desain yang umum adalah meminta satu pihak melakukan suatu pekerjaan dan menyimpan deposit untuk perilaku yang benar, lalu mengundang pihak lain untuk memverifikasi pekerjaan tersebut dan mengambil deposit tersebut jika mereka mengetahui pekerja tersebut melakukan kecurangan. Anda bisa menyebutnya pola desain "tantangan tegas". Kami melakukan ini di Arbitrum dan telah melihat proposal seperti Optimistic Rollup di berita baru-baru ini.
Sistem ini mungkin terpengaruh oleh dilema validator, yang pada dasarnya adalah pengamatan bahwa tidak ada gunanya memeriksa karya seseorang jika Anda tahu mereka tidak akan menyontek, namun jika Anda tidak memeriksanya, mereka memiliki insentif untuk berbuat curang; Jika Anda seorang desainer, Anda ingin membuktikan bahwa sistem Anda kompatibel dengan insentif, artinya jika setiap orang berperilaku konsisten dengan insentifnya, tidak akan terjadi kecurangan. Ini adalah area di mana intuisi bisa membawa Anda salah. Masalah ini jauh lebih sulit daripada yang terlihat, seperti yang akan kita lihat ketika kita menguraikan insentif dari pihak-pihak di bawah ini.
Model yang sangat sederhana
Kita mulai dengan membangun model paling sederhana yang kita bisa. Misalkan ada dua pemain. Penegas membuat pernyataan, yang mungkin benar atau salah. Pemeriksa dapat memeriksa klaim penegas, atau pemeriksa dapat memilih untuk tidak melakukan apa pun, mungkin dengan asumsi bahwa penegas mungkin mengatakan yang sebenarnya. Kita asumsikan biaya pengecekan yang dikeluarkan pemeriksa adalah C. Jika pemeriksa memeriksa dan menemukan bahwa penegas melakukan kecurangan, maka pemeriksa akan menerima imbalan sebesar R. (R mencakup semua manfaat yang diperoleh pemeriksa sebagai akibat dari tertangkapnya kecurangan. Ini mencakup manfaat yang diperoleh “di luar sistem” serta manfaat apa pun yang diperoleh karena meningkatnya kepercayaan terhadap sistem.) Jika penegas tidak tertangkap, Di bawah kecurangan , pemeriksa kehilangan L, misalnya karena penegas yang curang dapat dengan curang mengambil barang berharga dari pemeriksa.
Kini kita mempunyai dua ancaman yang perlu dikhawatirkan: penyuapan dan kemalasan. Suap adalah kemungkinan bahwa penegas dapat menyuap pemeriksa agar tidak memeriksa, sehingga memungkinkan penegas melakukan kecurangan tanpa terdeteksi. Kita dapat mencegah hal ini terjadi dengan memastikan bahwa penegas menyimpan deposit yang sangat besar yang lebih besar dari nilai total dalam sistem dan membayar pemeriksa ketika kecurangan terdeteksi, sehingga penegas tidak bersedia membayar lebih besar dari imbalan pemeriksa R. menyuap. Hal ini akan mencegah penyuapan, namun sistem ini memerlukan jaminan penuh, dan hal ini bisa memakan biaya yang sangat mahal.
Ancaman lainnya adalah kemalasan, risiko pemeriksa memutuskan untuk tidak memeriksa pekerjaan penegas. (Ingat, para pemeriksa mungkin mengatakan bahwa mereka sedang memeriksa namun sebenarnya tidak melakukan hal tersebut.) Mari kita lihat insentif bagi para pemeriksa untuk melihat apakah ini merupakan strategi yang masuk akal.
Misalkan si penegas berbuat curang dengan probabilitas X. Sekarang, utilitas inspektur adalah sebagai berikut:
Jika reviewer memeriksa: RX-C
Jika pemeriksa tidak memeriksa: -XL
Pengecekan hanya bermanfaat jika kegunaan pengecekan lebih besar dibandingkan kegunaan tidak pengecekan, yaitu jika X > C/(R+L). Inilah kabar buruknya: penegas dapat melakukan kecurangan secara acak, dengan probabilitas kurang dari C/(R+L), pemeriksa rasional tidak akan pernah memeriksa, sehingga penegas tidak akan pernah ketahuan melakukan kecurangan.
Mari kita masukkan beberapa nomor. Jika biaya pemeriksaan setiap transaksi adalah $0,10, dan pemeriksa menerima hadiah sebesar $75 jika mendeteksi kecurangan, tetapi kehilangan $25 jika gagal mendeteksi kecurangan, maka penegas dapat menipu dengan impunitas Seribu kali. Jika kita ingin sistem ini menjalankan ribuan transaksi, maka kita mempunyai masalah besar. Jelas tidak ada yang bisa kita lakukan dalam model ini untuk mengurangi kemungkinan kecurangan menjadi nol. Kita hanya bisa berharap adanya sistem overcollateralized sehingga penyebut C/(R+L) menjadi lebih besar.
Ini adalah hasil yang sangat kuat—dalam arti yang buruk. Hal ini sama sekali tidak bergantung pada insentif dari pihak yang menegaskan. Selama penegas mendapat keuntungan bukan nol dari kecurangan yang berhasil, ia dapat melakukannya dengan beberapa kemungkinan, karena mengetahui bahwa upaya pemeriksa untuk memeriksanya tidak sepadan. Hasil ini juga tidak bergantung pada berapa banyak waktu yang kita berikan kepada inspektur untuk menyelesaikan pekerjaannya, atau apakah kita membayar untuk (yang konon) inspektur tersebut. Mungkin Anda sekarang berpikir, masalahnya hanya ada satu inspektur. Apakah menambahkan lebih banyak checker akan mengurangi kemungkinan terjadinya kecurangan? Anehnya, ternyata tidak.
Menambahkan sensor tidak membantu mencegah kecurangan
Sekali lagi, mari kita rumuskan model yang paling sederhana. Sekarang ada dua inspektur yang bertindak independen. Masing-masing pemeriksa membayar C jika ia melakukan pengecekan, dan jika ada yang memeriksa dan menangkap penegas kecurangan, maka imbalan sebesar R dibayarkan kepada pemeriksa yang berhasil, atau jika keduanya melakukan pengecekan, maka imbalannya dibagi rata di antara keduanya. (Jika Anda suka, Anda dapat memberi salah satu dari mereka hadiah penuh acak sebesar R jika mereka semua melakukan check. Ini tidak memengaruhi strategi atau hasil siapa pun.) Seperti sebelumnya, setiap checker akan kehilangan L jika penegasnya Curang tanpa mendapatkan tertangkap.
Tetap saja jika penegas melakukan kecurangan kurang dari C/(R+L) pada waktunya, maka tidak ada gunanya bagi pemeriksa untuk memeriksa, karena kegunaan pemeriksaan lebih kecil daripada kegunaan tidak memeriksa. Faktanya, masalah insentif lebih buruk dari sebelumnya, karena biaya pengecekan per checker masih C, namun imbalan yang diharapkan bagi pemeriksa yang berhasil menangkap kecurangan kurang dari R, karena imbalannya terkadang perlu dibagi - imbalan yang diharapkan akan menjadi lebih besar. berada di R/2 dan R. Jika imbalan yang diharapkan adalah bR, dengan b antara 0,5 dan 1, maka penegas dapat melakukan kecurangan hingga waktu C/(bR+L) - ini lebih merupakan kecurangan yang tidak terdeteksi dibandingkan jika hanya ada satu pemeriksa! (Perhitungan menjadi sedikit rumit karena nilai b bergantung pada strategi pemeriksa, dan strategi mereka bergantung pada b, namun harus jelas bahwa terkadang mereka perlu membagi hadiahnya. Selain itu, nilai efektif L juga berkurang , karena seseorang tidak melakukan Checker tidak akan kehilangan L-nya untuk diperiksa oleh checker lain).
Salah satu hal di mana penambahan sensor akan sangat membantu adalah dalam mencegah penyuapan. Dengan dua checker, penegas harus membayar suap lebih dari R kepada masing-masing penegas, menjadikan suap dua kali lebih mahal, sehingga memungkinkan 50% pertaruhan daripada pertaruhan penuh. Namun dampaknya adalah jumlah kecurangan meningkat.
Saya tidak akan membahas seluruh perhitungannya di sini, namun berdasarkan asumsi yang masuk akal, meningkatkan dari satu checker menjadi dua dapat menghasilkan peningkatan 50% dalam kecurangan yang tidak terdeteksi.
Menambahkan sensor memperburuk keadaan!
Anda dapat menambahkan lebih banyak checker dan segalanya akan menjadi lebih buruk. Seiring bertambahnya jumlah pemeriksa, pemeriksa perlu lebih khawatir tentang pembagian hadiah dalam beberapa cara, sehingga imbalan yang diharapkan untuk setiap pemeriksa yang berhasil secara bertahap menurun, menyebabkan kemungkinan penegas untuk melakukan kecurangan dengan aman meningkat secara bertahap. Dari perspektif ini, skenario terburuknya adalah semua orang di dunia bisa menjadi sensor. Hal ini tidak terlalu buruk, karena keadaan menjadi lebih buruk seiring dengan bertambahnya sensor, namun hal ini tentu saja tidak akan membantu mencegah kecurangan, meskipun hal ini secara efektif menghilangkan risiko penyuapan.
Apakah Anda yakin sistem Anda kompatibel dengan insentif?
Jika Anda memiliki sistem yang cocok dengan model seperti ini, dan menurut Anda sistem tersebut kompatibel dengan insentif, Anda perlu memikirkan alasannya dengan cermat. Secara khusus, Anda perlu menjelaskan mengapa pemeriksa melakukan tugas pemeriksaan, meskipun menurut mereka penegas tidak mungkin berbuat curang. Mendapat hukuman kecurangan yang besar saja tidak cukup. Mendapatkan hadiah untuk menangkap cheater saja tidak cukup. Memiliki banyak checker saja tidak cukup - bahkan, hal ini dapat memperburuk keadaan. Mengapa sistem Anda kebal?
Tantangan ini berlaku untuk sistem seperti Optimistic Rollup. Ketika kita berbicara tentang Arbitrum, itu juga berlaku bagi kita.
Dengan mempertimbangkan hal-hal di atas, metode pemeriksaan insentif tradisional tidak mencapai hasil yang diinginkan - terdapat tingkat kecurangan dasar yang di bawahnya maka pemeriksa akan menganggap cek tersebut tidak bermanfaat. Kesimpulannya:
Ada dua pemain, seorang penegas, yang membuat klaim apakah klaim tersebut benar atau salah, dan seorang pemeriksa, yang dapat memeriksa klaim tersebut dengan biaya komputasi tertentu. Jika pemeriksa melakukan pengecekan maka utilitasnya adalah RX-C, jika tidak melakukan pengecekan maka utilitasnya adalah -XL, dimana R adalah imbalan jika menangkap kecurangan, C adalah biaya pengecekan, dan L adalah kerugian pemeriksa karena tidak mendeteksi kecurangan. , X adalah probabilitas dari penegas kecurangan (dipilih oleh penegas). Beberapa aljabar menunjukkan bahwa jika
Untuk mengatasi masalah ini dan menciptakan situasi di mana pengulas yang didorong oleh insentif akan selalu melakukan pemeriksaan, kita harus mengubah insentif pengulas. Masalah mendasarnya adalah bahwa dalam model awal, insentif positif bagi pemeriksa untuk melakukan pengecekan semuanya proporsional Jika kita menginginkan insentif cek yang tetap berjalan, kita perlu menciptakan insentif atau disinsentif cek untuk tidak melakukan pemeriksaan yang tidak bergantung pada tindakan pihak yang menegaskan.
TrueBit berupaya melakukan hal ini dengan sengaja menambahkan klaim palsu ke kumpulan pernyataan, yang pada dasarnya menggantikan X dengan X ditambah sebuah konstanta. Ada beberapa masalah dengan pendekatan ini. (Makalah Arbitrum asli memiliki bagian tentang masalah motivasi TrueBit.)
Fokus pada tantangan
Kami menggunakan pendekatan berbeda yang kami sebut fokus pada tantangan. Idenya adalah jika penegas menghitung nilai f(x), ia terlebih dahulu mengeluarkan x dan tantangan kriptografi. Untuk menjawab tantangan dengan benar, pemeriksa perlu mengetahui f(x). Hanya setelah tantangan terjadi barulah penegas mempublikasikan f(x) - pada titik ini, pemeriksa telah melakukan kerja keras menghitung f(x), sehingga tidak ada insentif untuk bermalas-malasan. (Detail lebih lanjut tentang perjanjian tersebut menyusul.)
Untuk mengurangi jumlah transaksi on-chain yang diperlukan, kami akan mengatur berbagai hal sehingga respons yang tepat terhadap tantangan yang dilakukan oleh pemeriksa biasanya adalah diam. Namun dalam kasus yang jarang terjadi, pemeriksa harus mempublikasikan transaksi yang sangat kecil pada rantai tersebut. Jika pemeriksa memberikan jawaban yang salah - diam saat harus dilepaskan, atau diam saat harus dilepaskan - ia akan kehilangan sedikit deposit.
Mari kita sesuaikan model insentif awal untuk memasukkan tantangan perhatian. Kita memerlukan dua parameter baru (keduanya dapat kita pilih): P, persentase waktu pengeposan jawaban yang benar, dan A, penalti jika pemeriksa memberikan jawaban yang salah. Sekarang, utilitas inspektur adalah:
Jika dicentang: RX-C
Jika tidak centang: -LX-PA
Pengamatan kuncinya adalah selama PA > C, maka pengecekan adalah strategi yang optimal, tidak peduli berapapun X (probabilitas kecurangan).
Biaya yang sangat rendah
Untuk mengevaluasi biayanya, mari kita lihat contoh nyata. Anggaplah ada pernyataan setiap lima menit dan biaya pengecekannya adalah $0,001. Jika kita menetapkan probabilitas P menjadi 0,3%, pemeriksa harus membayar deposit sebesar $3. Sekarang, biaya pemeriksa per pernyataan adalah $0,0003 dalam biaya bahan bakar (biaya bahan bakar $0,10 untuk memposting respons non-diam, dikalikan dengan probabilitas 0,3% yang harus diposting), ditambah sekitar $0,0003 untuk mengunci taruhan $3 selama lima menit. biaya bunga adalah $0,0006 per pernyataan.
Perpanjangan untuk beberapa inspektur
Tantangan fokus berskala baik dengan banyak penguji. Protokol mengeluarkan tantangan yang mempengaruhi setiap pemeriksa secara berbeda, memaksa setiap pemeriksa menghitung f(x) sendiri. Setiap pemeriksa akan dikenakan biaya yang sama (dalam kasus kami, $0,0006 per pernyataan).
Dalam sistem terbuka, siapa pun berhak untuk memeriksa perhitungan, dan Anda dapat mengizinkan siapa pun untuk mendaftar sebagai pemeriksa dan melakukan deposit kecil yang diperlukan. Hal ini akan membuat mereka memenuhi syarat untuk menerima tantangan perhatian dan berpotensi menerima kompensasi dari pengembang dapp. Siapa pun dapat menantang klaim salah seorang penegas, namun hanya pemeriksa terdaftar yang menghadapi tantangan perhatian.
Rincian teknis perjanjian
Sekarang setelah kita memahami manfaat fokus pada tantangan bagi kita, mari selami detail teknis tentang cara kerjanya.
Setiap pemeriksa memiliki kunci privat k dan kunci publik terkait gᵏ, yang ditentukan dalam grup yang sesuai. Kunci publik dari setiap pemeriksa diketahui semua orang. Kami juga akan mengandalkan fungsi hash H yang sesuai.
Untuk memberikan tantangan pada perhitungan f(x), dimana fungsi f telah diketahui sebelumnya, penegas menghasilkan nilai acak r dan kemudian mengeluarkan (x, gʳ) sebagai tantangan.
Pemeriksa yang memiliki kunci pribadi k harus merespons tantangan tersebut dengan menerbitkan transaksi kecil hanya jika H(gʳᵏ, f(x)) < T, di mana T adalah ambang batas yang dipilih secara sesuai. Perhatikan bahwa hanya penegas (yang mengetahui r) dan pemeriksa tertentu (yang mengetahui kunci privatnya k) yang dapat menghitung hash, karena merekalah satu-satunya yang dapat menghitung gʳᵏ. Perhatikan juga bahwa menghitung hash memerlukan pengetahuan f(x).
Setelah pemeriksa mempunyai waktu untuk mengirimkan tanggapan mereka terhadap tantangan, penegas dapat memposting f(x)-nya dan jika ada pemeriksa yang tidak setuju dengan itu, pemeriksa tersebut akan ditantang seperti biasa. Pada titik ini, penegas dapat menuduh pemeriksa mana pun memberikan tanggapan yang salah; penegas harus mengeluarkan r untuk mendukung tuduhannya. Penambang atau kontrak dapat memeriksa apakah tuduhan tersebut benar dan menghukum pelanggar; tetapi jika pernyataan penegas tentang f(x) pada akhirnya tidak diterima sebagai kebenaran, tuduhan tersebut akan diabaikan. Jika ada pemeriksa yang didenda, penegas akan menerima setengah dari dana yang hangus dan separuh lainnya akan dimusnahkan.
Pendekatan ini memberi pemeriksa insentif yang tepat. Mengetahui bagaimana pemeriksa harus merespons suatu tantangan memerlukan mengetahui kunci pribadi pemeriksa dan f(x), sehingga setiap pemeriksa ingin menghitung f(x). Kecuali pemeriksa menghitung f(x) sendiri, pemeriksa tidak dapat menerapkan protokol dengan aman. Respons pemeriksa lain tidak berguna dalam menentukan f(x) karena bergantung pada kunci privat pemeriksa tersebut. Jika pemeriksa bergantung pada orang lain yang memberitahukannya f(x), ia tidak memiliki cara untuk memverifikasi nilai yang diklaim tersebut (selain menghitung f(x) itu sendiri), dan pemeriksa tersebut berisiko terkena penalti jika salah. Bahkan ada insentif bagi satu pihak untuk mencoba menyesatkan pemeriksa tentang f(x) - yaitu penegas, yang mendapat keuntungan dari kesalahan pemeriksa dan mungkin menggunakan keuntungan ini untuk menyuap "teman" pemeriksa agar memberikan informasi yang salah kepada pemeriksa. .
Optimasi dan kesimpulan
Ada beberapa trik untuk membuat protokol ini lebih efektif. Misalnya, kita dapat menggabungkan pernyataan dengan tantangan berikutnya ke dalam transaksi on-chain sehingga tantangan tersebut tidak meningkatkan jumlah transaksi. Jika P kecil (misalnya, 0,3% dalam contoh kita) dan jumlah checker tidak terlalu besar, maka checker jarang perlu menulis transaksi pada rantai, sehingga dampak keseluruhan dari protokol pada jumlah transaksi on-chain akan menjadi lebih besar. menjadi yang terkecil.
Dengan implementasi yang cerdas, biaya protokol ini akan sangat rendah dibandingkan dengan biaya di muka untuk mengeluarkan pernyataan secara on-chain. Dalam kasus kami, menambahkan tantangan perhatian pada protokol tantangan-pernyataan yang ada akan meningkatkan total biaya kurang dari 1%.
Dan keuntungannya sangat besar – kita mendapatkan protokol pemeriksaan yang kompatibel dengan insentif dan kebal terhadap dilema validator. Selama setidaknya ada satu pemeriksa yang rasional, klaim penegas akan selalu diperiksa.
Untuk informasi lain tentang proyek ini, silakan merujuk ke: Rantai publik game Xai: database Binance Square
