pengenalan

function getAbsolutelyRandomNumer() {
        return 4; // returns absolutely random number!
}

Seperti halnya konsep sandi yang benar-benar kuat dari kriptografi, protokol “Suar Acak yang Dapat Diverifikasi Secara Publik” (selanjutnya disebut PVRB) yang sebenarnya hanya berusaha sedekat mungkin dengan skema yang ideal, karena dalam jaringan nyata hal ini tidak berlaku dalam bentuknya yang murni: satu bit harus disetujui secara ketat, harus ada banyak putaran, dan semua pesan harus sangat cepat dan selalu terkirim. Tentu saja, hal ini tidak terjadi di jaringan nyata. Oleh karena itu, ketika merancang PVRB untuk tugas-tugas tertentu di blockchain modern, selain ketidakmungkinan mengendalikan keacakan dan kekuatan kriptografi yang dihasilkan, banyak masalah arsitektur dan teknis yang lebih murni muncul.

Bagi PVRB, blockchain sendiri pada dasarnya adalah media komunikasi dimana pesan = transaksi. Hal ini memungkinkan Anda untuk mengabstraksi sebagian dari masalah jaringan, tidak terkirimnya pesan, masalah dengan middleware - semua risiko ini ditanggung oleh jaringan yang terdesentralisasi, dan nilai utamanya untuk PVRB adalah ketidakmampuan untuk mencabut atau merusak transaksi yang sudah terkirim - ini tidak tidak mengizinkan peserta untuk menolak berpartisipasi dalam protokol, kecuali mereka berhasil melakukan serangan terhadap konsensus. Tingkat keamanan ini dapat diterima, sehingga PVRB harus tahan terhadap kolusi oleh peserta pada tingkat yang sama seperti rantai blockchain utama. Selain itu, hal ini mengisyaratkan bahwa PVRB harus menjadi bagian dari konsensus jika jaringan menyetujui blockchain utama, meskipun jaringan tersebut juga menyetujui satu-satunya hasil acak yang adil. Atau, PVRB hanyalah sebuah protokol mandiri yang diimplementasikan oleh kontrak pintar yang bekerja secara asinkron terhadap blockchain dan blok. Kedua metode tersebut memiliki kelebihan dan kekurangannya masing-masing, dan pilihan di antara keduanya sangatlah tidak sepele.

Dua cara untuk mengimplementasikan PVRB

Mari kita jelaskan secara lebih rinci dua opsi untuk mengimplementasikan PVRB - versi mandiri, yang bekerja menggunakan kontrak pintar yang independen dari blockchain, dan versi terintegrasi konsensus, yang dibangun ke dalam protokol, yang dengannya jaringan menyetujui blockchain dan transaksi yang harus disertakan. Dalam semua kasus, yang saya maksud adalah mesin blockchain yang populer: Ethereum, EOS, dan semua yang serupa dengan cara mereka menghosting dan memproses kontrak pintar.

Kontrak mandiri

Dalam versi ini, PVRB adalah kontrak pintar yang menerima transaksi dari produsen acak (selanjutnya disebut RP), memprosesnya, menggabungkan hasilnya, dan, sebagai hasilnya, mencapai nilai tertentu yang dapat diterima oleh setiap pengguna dari kontrak ini. Nilai ini tidak dapat disimpan secara langsung dalam kontrak, melainkan hanya diwakili oleh data yang darinya satu dan hanya satu nilai acak yang dihasilkan dapat diperoleh secara deterministik. Dalam skema ini, RP adalah pengguna blockchain, dan siapa pun dapat berpartisipasi dalam proses pembuatannya.

Opsi dengan kontrak mandiri bagus:

• portabilitas (kontrak dapat diseret dari blockchain ke blockchain)
• kemudahan implementasi dan pengujian (kontrak mudah ditulis dan diuji)
• kenyamanan dalam mengimplementasikan skema ekonomi (mudah membuat token Anda sendiri, yang logikanya sesuai dengan tujuan PVRB)
• kemungkinan peluncuran pada blockchain yang sudah berfungsi

Ini juga memiliki kelemahan:

• keterbatasan yang kuat pada sumber daya komputasi, volume transaksi, dan penyimpanan (dengan kata lain, cpu/mem/io)
• pembatasan operasi dalam kontrak (tidak semua instruksi tersedia, sulit untuk menghubungkan perpustakaan eksternal)
• ketidakmampuan untuk mengatur pengiriman pesan lebih cepat daripada transaksi yang dimasukkan dalam blockchain

Opsi ini cocok untuk mengimplementasikan PVRB yang perlu dijalankan pada jaringan yang sudah ada, tidak mengandung kriptografi yang rumit dan tidak memerlukan interaksi dalam jumlah besar.

Terintegrasi dengan konsensus

Dalam versi ini, PVRB diimplementasikan dalam kode node blockchain, built-in atau berjalan secara paralel dengan pertukaran pesan antar node blockchain. Hasil dari protokol ditulis langsung ke dalam blok yang dihasilkan, dan pesan protokol dikirim melalui jaringan p2p antar node. Karena protokol menghasilkan angka-angka yang akan ditulis dalam blok, jaringan harus mencapai konsensus mengenai angka-angka tersebut. Artinya, pesan PVRB, seperti halnya transaksi, harus divalidasi oleh node dan disertakan dalam blok sehingga setiap peserta jaringan dapat memvalidasi kepatuhan terhadap protokol PVRB. Hal ini secara otomatis membawa kita pada solusi yang jelas - jika jaringan menyetujui konsensus mengenai blok dan transaksi di dalamnya, maka PVRB harus menjadi bagian dari konsensus, dan bukan protokol yang berdiri sendiri. Jika tidak, ada kemungkinan suatu blok sah dari sudut pandang konsensus, tetapi protokol PVRB tidak diikuti, dan dari sudut pandang PVRB blok tersebut tidak dapat diterima. Jadi jika opsi “konsensus terintegrasi” dipilih, PVRB menjadi bagian penting dari konsensus.

Ketika menggambarkan implementasi PVRB pada tingkat konsensus jaringan, kita tidak dapat menghindari masalah finalitas. Finalitas adalah mekanisme yang digunakan dalam konsensus deterministik yang mengunci sebuah blok (dan rantai yang mengarah ke sana) yang bersifat final dan tidak akan pernah dibuang, bahkan jika terjadi percabangan paralel. Misalnya, di Bitcoin tidak ada mekanisme seperti itu - jika Anda menerbitkan rantai dengan kompleksitas yang lebih besar, rantai tersebut akan menggantikan rantai yang kurang rumit, berapa pun panjang rantainya. Dan di EOS, misalnya, yang terakhir adalah apa yang disebut Last Irreversible Blocks, yang muncul rata-rata setiap 432 blok (12*21 + 12*15, pre-vote + pre-commit). Proses ini pada dasarnya menunggu 2/3 dari produsen blok (selanjutnya disebut BP) tanda tangan. Ketika muncul garpu yang lebih tua dari LIB terakhir, garpu tersebut dibuang begitu saja. Mekanisme ini memungkinkan untuk menjamin bahwa transaksi tersebut termasuk dalam blockchain dan tidak akan pernah dibatalkan, tidak peduli sumber daya apa pun yang dimiliki penyerang. Selain itu, blok terakhir adalah blok yang ditandatangani oleh 2/3 BP di Hyperledger, Tendermint, dan konsensus berbasis pBFT lainnya. Selain itu, masuk akal untuk menjadikan protokol untuk memastikan finalitas sebagai tambahan pada konsensus, karena protokol tersebut dapat bekerja secara asinkron dengan produksi dan publikasi blok. Ini yang bagus artikel tentang finalitas di Ethereum.

Finalitas sangat penting bagi pengguna, yang tanpanya mungkin akan menjadi korban serangan “pembelanjaan ganda”, di mana BP “menahan” blok, dan menerbitkannya setelah jaringan “melihat” transaksi yang baik. Jika tidak ada finalitas, maka fork yang diterbitkan akan menggantikan blok tersebut dengan transaksi “baik” dengan transaksi lain, dari fork “buruk”, di mana dana yang sama ditransfer ke alamat penyerang. Dalam kasus PVRB, persyaratan finalitas bahkan lebih ketat, karena membangun fork untuk PVRB berarti peluang bagi penyerang untuk menyiapkan beberapa opsi acak untuk mempublikasikan opsi yang paling menguntungkan, dan membatasi waktu kemungkinan serangan adalah sebuah solusi yang bagus.

Oleh karena itu, opsi terbaik adalah menggabungkan PVRB dan finalitas ke dalam satu protokol - maka blok yang diselesaikan = acak yang diselesaikan, dan inilah yang perlu kami dapatkan. Sekarang pemain akan menerima jaminan acak dalam N detik, dan dapat dipastikan bahwa tidak mungkin untuk memutarnya kembali atau memutarnya lagi.

Opsi yang terintegrasi dengan konsensus adalah hal yang baik:

• kemungkinan implementasi asynchronous dalam kaitannya dengan produksi blok - blok diproduksi seperti biasa, tetapi secara paralel dengan ini, protokol PVRB dapat bekerja, yang tidak menghasilkan keacakan untuk setiap blok
• kemampuan untuk menerapkan kriptografi berat sekalipun, tanpa batasan yang diberlakukan pada kontrak pintar
• kemampuan untuk mengatur pertukaran pesan lebih cepat daripada transaksi yang termasuk dalam blockchain, misalnya, bagian dari protokol dapat bekerja antar node tanpa mendistribusikan pesan melalui jaringan

Ini juga memiliki kelemahan:

• Kesulitan dalam pengujian dan pengembangan - Anda harus meniru kesalahan jaringan, node yang hilang, hard fork jaringan
• Kesalahan implementasi memerlukan hardfork jaringan

Kedua metode penerapan PVRB memiliki hak untuk hidup, namun penerapan kontrak pintar di blockchain modern masih sangat terbatas dalam sumber daya komputasi, dan transisi apa pun ke kriptografi yang serius seringkali tidak mungkin dilakukan. Dan kita memerlukan kriptografi yang serius, seperti yang akan ditunjukkan di bawah ini. Meskipun masalah ini jelas bersifat sementara, kriptografi yang serius dalam kontrak diperlukan untuk menyelesaikan banyak masalah, dan masalah ini muncul secara bertahap (misalnya, kontrak sistem untuk zkSNARK di Ethereum)

Blockchain, yang menyediakan saluran pesan protokol yang transparan dan andal, tidak melakukannya secara gratis. Setiap protokol terdesentralisasi harus memperhitungkan kemungkinan serangan Sybil; tindakan apa pun dapat dilakukan oleh kekuatan gabungan dari banyak akun, oleh karena itu, ketika merancang, perlu memperhitungkan kemampuan penyerang untuk membuat sejumlah protokol yang berubah-ubah. peserta bertindak secara kolusi.

PVRB dan variabel blok.

Saya tidak berbohong ketika saya mengatakan bahwa belum ada yang menerapkan PVRB yang bagus, yang telah diuji oleh banyak aplikasi perjudian, di blockchain. Lalu dari mana datangnya begitu banyak aplikasi perjudian di Ethereum dan EOS? Hal ini mengejutkan saya dan juga Anda, dari mana mereka mendapatkan begitu banyak acak yang “persisten” dalam lingkungan yang sepenuhnya deterministik?

Cara favorit untuk mendapatkan keacakan dalam blockchain adalah dengan mengambil semacam informasi yang “tidak dapat diprediksi” dari blok dan membuat informasi acak berdasarkan informasi tersebut - cukup dengan melakukan hashing pada satu atau lebih nilai. Artikel bagus tentang masalah skema tersebut di sini. Anda dapat mengambil salah satu nilai “tidak dapat diprediksi” di blok, misalnya hash blok, jumlah transaksi, kompleksitas jaringan, dan nilai lain yang tidak diketahui sebelumnya. Kemudian hash mereka, satu atau lebih, dan, secara teori, Anda akan mendapatkan yang benar-benar acak. Anda bahkan dapat menambahkan ke kertas putih bahwa skema Anda “aman pasca-kuantum” (karena ada fungsi hash tahan kuantum :)).

Namun sayangnya, hash aman pasca-kuantum saja tidak cukup. Rahasianya terletak pada persyaratan PVRB, izinkan saya mengingatkan Anda dari artikel sebelumnya:

1. Hasilnya harus memiliki distribusi yang seragam, yaitu didasarkan pada kriptografi yang terbukti kuat.
2. Tidak mungkin untuk mengontrol bagian mana pun dari hasilnya. Akibatnya, hasilnya tidak dapat diprediksi sebelumnya.
3. Anda tidak dapat menyabotase protokol pembangkitan dengan tidak berpartisipasi dalam protokol atau dengan membebani jaringan dengan pesan serangan
4. Semua hal di atas harus tahan terhadap kolusi sejumlah peserta protokol yang tidak jujur ​​(misalnya, 1/3 dari peserta).

Dalam hal ini, hanya persyaratan 1 yang terpenuhi, dan persyaratan 2 tidak terpenuhi.Dengan melakukan hashing pada nilai yang tidak dapat diprediksi dari blok, kita akan mendapatkan distribusi yang seragam dan acak yang baik. Namun BP setidaknya memiliki pilihan untuk “memublikasikan pemblokiran tersebut atau tidak.” Dengan demikian, BP setidaknya dapat memilih dari DUA opsi acak: “miliknya” dan opsi yang akan muncul jika orang lain melakukan pemblokiran. BP dapat “mengintip” terlebih dahulu apa yang akan terjadi jika dia menerbitkan sebuah blok, dan memutuskan untuk melakukannya atau tidak. Jadi, ketika bermain, misalnya, “genap-ganjil” atau “merah/hitam” dalam roulette, dia dapat menerbitkan blok hanya jika dia melihat kemenangan. Hal ini juga membuat strategi penggunaan, misalnya, hash blok “dari masa depan” tidak bisa dijalankan. Dalam hal ini, mereka mengatakan bahwa “acak akan digunakan, yang diperoleh dengan melakukan hashing pada data saat ini dan hash dari blok masa depan dengan tinggi, misalnya, N + 42, di mana N adalah tinggi blok saat ini. Hal ini sedikit memperkuat skema tersebut, namun tetap memungkinkan BP, meskipun di masa depan, untuk memilih apakah akan menahan pemblokiran atau menerbitkannya.

Software BP dalam hal ini menjadi lebih rumit, tapi tidak banyak. Sederhananya, saat memvalidasi dan memasukkan transaksi ke dalam blok, ada pemeriksaan cepat untuk melihat apakah akan ada kemenangan, dan, mungkin, pemilihan salah satu parameter transaksi untuk mendapatkan kemungkinan menang yang tinggi. Pada saat yang sama, hampir tidak mungkin untuk menangkap BP yang cerdas untuk manipulasi seperti itu; setiap kali Anda dapat menggunakan alamat baru dan menang sedikit demi sedikit tanpa menimbulkan kecurigaan.

Jadi metode yang menggunakan informasi dari blok tidak cocok sebagai implementasi PVRB secara universal. Dalam versi terbatas, dengan pembatasan ukuran taruhan, pembatasan jumlah pemain dan/atau pendaftaran KYC (untuk mencegah satu pemain menggunakan banyak alamat), skema ini dapat berfungsi untuk permainan kecil, tetapi tidak lebih.

PVRB dan pengungkapan komitmen.

Oke, berkat hashing dan setidaknya hash blok dan variabel lainnya yang relatif tidak dapat diprediksi. Jika Anda memecahkan masalah penambang terdepan, Anda harus mendapatkan sesuatu yang lebih cocok. Mari tambahkan pengguna ke skema ini - biarkan mereka juga memengaruhi keacakan: setiap karyawan dukungan teknis akan memberi tahu Anda bahwa hal paling acak dalam sistem TI adalah tindakan pengguna :)

Skema yang naif, ketika pengguna hanya mengirimkan nomor acak dan hasilnya dihitung sebagai, misalnya, hash dari jumlah mereka, tidak cocok. Dalam hal ini, pemain terakhir, dengan memilih acaknya sendiri, dapat mengontrol hasil yang akan diperoleh. Inilah sebabnya mengapa pola commit-reveal yang sangat banyak digunakan digunakan. Peserta pertama-tama mengirimkan hash dari acaknya (commit), dan kemudian membuka acaknya sendiri (mengungkapkan). Fase “pengungkapan” dimulai hanya setelah komitmen yang diperlukan dikumpulkan, sehingga peserta dapat mengirimkan hash acak yang sama persis dengan yang mereka kirim sebelumnya. Sekarang mari kita gabungkan semua ini dengan parameter sebuah blok, dan lebih baik daripada yang diambil dari masa depan (keacakan hanya dapat ditemukan di salah satu blok masa depan), dan voila - keacakan sudah siap! Sekarang pemain mana pun memengaruhi keacakan yang dihasilkan, dan dapat "mengalahkan" BP jahat dengan menimpanya dengan miliknya sendiri, yang tidak diketahui sebelumnya, keacakan... Anda juga dapat menambahkan perlindungan terhadap sabotase protokol dengan tidak membukanya pada tahap pengungkapan - cukup dengan mengharuskan sejumlah tertentu untuk dilampirkan pada transaksi ketika melakukan — uang jaminan, yang akan dikembalikan hanya selama prosedur pengungkapan. Dalam hal ini, melakukan dan tidak mengungkapkan tidak akan menguntungkan.

Itu adalah upaya yang bagus, dan skema seperti itu juga ada di DApps game, tapi sayangnya, ini sekali lagi tidak cukup. Kini tidak hanya penambang, tetapi juga peserta protokol mana pun dapat memengaruhi hasilnya. Masih mungkin untuk mengontrol nilai itu sendiri, dengan variabilitas yang lebih kecil dan dengan biaya yang lebih kecil, namun, seperti dalam kasus penambang, jika hasil pengundian lebih berharga daripada biaya untuk berpartisipasi dalam protokol PVRB, maka nilai acak -produser(RP) dapat memutuskan apakah akan mengungkapkan dan masih dapat memilih dari setidaknya dua opsi acak.
Namun menjadi mungkin untuk menghukum mereka yang melakukan dan tidak mengungkapkannya, dan skema ini akan berguna. Kesederhanaannya merupakan keuntungan yang serius - protokol yang lebih serius memerlukan perhitungan yang jauh lebih kuat.

PVRB dan tanda tangan deterministik.

Ada cara lain untuk memaksa RP memberikan nomor pseudo-acak yang tidak dapat dipengaruhi jika dilengkapi dengan "preimage" - ini adalah tanda tangan deterministik. Tanda tangan seperti itu, misalnya, adalah RSA, dan bukan ECS. Jika RP memiliki sepasang kunci: RSA dan ECC, dan dia menandatangani nilai tertentu dengan kunci pribadinya, maka dalam kasus RSA dia akan mendapatkan SATU DAN HANYA SATU tanda tangan, dan dalam kasus ECS dia dapat menghasilkan sejumlah kunci apa pun. tanda tangan sah yang berbeda. Hal ini karena saat membuat tanda tangan ECS, nomor acak digunakan, dipilih oleh penandatangan, dan dapat dipilih dengan cara apa pun, memberikan kesempatan kepada penandatangan untuk memilih salah satu dari beberapa tanda tangan. Dalam kasus RSA: “satu nilai masukan” + “satu pasangan kunci” = “satu tanda tangan”. Tidak mungkin untuk memprediksi tanda tangan apa yang akan diperoleh RP lain, sehingga PVRB dengan tanda tangan deterministik dapat disusun dengan menggabungkan tanda tangan RSA dari beberapa peserta yang menandatangani nilai yang sama. Misalnya acak sebelumnya. Skema ini menghemat banyak sumber daya, karena tanda tangan merupakan konfirmasi atas perilaku yang benar menurut protokol dan sumber keacakan.

Namun, bahkan dengan penandatanganan yang bersifat deterministik, skema ini masih rentan terhadap masalah “pihak terakhir”. Peserta terakhir masih dapat memutuskan apakah akan mempublikasikan tanda tangannya atau tidak, sehingga mengontrol hasilnya. Anda dapat memodifikasi skema, menambahkan hash blok ke dalamnya, melakukan putaran sehingga hasilnya tidak dapat diprediksi sebelumnya, tetapi semua teknik ini, bahkan dengan mempertimbangkan banyak modifikasi, masih menyisakan masalah pengaruh satu peserta pada tim yang belum terselesaikan. menghasilkan lingkungan yang tidak dapat dipercaya dan hanya dapat bekerja dalam batasan ekonomi dan waktu. Selain itu, ukuran kunci RSA (1024 dan 2048 bit) cukup besar, dan ukuran transaksi blockchain merupakan parameter yang sangat penting. Tampaknya tidak ada cara sederhana untuk menyelesaikan masalah tersebut, mari kita lanjutkan.

PVRB dan skema pembagian rahasia

Dalam kriptografi, terdapat skema yang memungkinkan jaringan menyetujui satu dan hanya satu nilai PVRB, sementara skema tersebut tahan terhadap tindakan jahat dari beberapa partisipan. Salah satu protokol berguna yang patut Anda pahami adalah skema pembagian rahasia Shamir. Ini berfungsi untuk membagi suatu rahasia (misalnya kunci rahasia) menjadi beberapa bagian, dan mendistribusikan bagian tersebut kepada N peserta. Rahasianya didistribusikan sedemikian rupa sehingga M bagian dari N cukup untuk memulihkannya, dan ini bisa berupa M bagian apa saja. Jika di jari, kemudian memiliki grafik fungsi yang tidak diketahui, peserta menukar poin pada grafik, dan setelah menerima M poin, seluruh fungsi dapat dipulihkan.
Penjelasan yang baik diberikan dalam wiki tetapi memainkannya secara praktis untuk memainkan protokol di kepala Anda berguna demo halaman.

Jika skema FSSS (Fiat-Shamir Secret Sharing) dapat diterapkan dalam bentuknya yang murni, maka skema tersebut akan menjadi PVRB yang tidak dapat dihancurkan. Dalam bentuknya yang paling sederhana, protokolnya mungkin terlihat seperti ini:

• Setiap peserta menghasilkan acaknya sendiri dan mendistribusikan bagiannya ke peserta lain
• Masing-masing peserta mengungkapkan rahasia peserta lainnya
• Jika seorang peserta memiliki lebih dari M saham, maka jumlah peserta ini dapat dihitung, dan itu akan unik, terlepas dari kumpulan peserta yang terungkap.
• Kombinasi acak yang terungkap merupakan PVRB yang diinginkan

Di sini, seorang peserta tidak lagi mempengaruhi hasil protokol, kecuali dalam kasus di mana pencapaian ambang batas pengungkapan keacakan hanya bergantung padanya. Oleh karena itu, protokol ini, jika ada proporsi RP yang diperlukan yang bekerja pada protokol dan tersedia, berfungsi, menerapkan persyaratan kekuatan kriptografi, dan tahan terhadap masalah “aktor terakhir”.

Ini bisa menjadi pilihan yang ideal, skema PVRB berdasarkan pembagian rahasia Fiat-Shamir dijelaskan misalnya dalam ini artikel. Namun, seperti disebutkan di atas, jika Anda mencoba menerapkannya langsung di blockchain, akan muncul keterbatasan teknis. Berikut adalah contoh implementasi pengujian protokol dalam kontrak pintar EOS dan bagian terpentingnya - memeriksa peserta saham yang dipublikasikan: kode. Terlihat dari kodenya bahwa validasi bukti memerlukan beberapa perkalian skalar, dan angka yang digunakan sangat besar. Perlu dipahami bahwa dalam blockchain, verifikasi terjadi pada saat produsen blok memproses transaksi, dan secara umum, setiap peserta harus dengan mudah memverifikasi kebenaran protokol, sehingga persyaratan untuk kecepatan fungsi verifikasi sangat serius. . Pada opsi ini, opsi tersebut ternyata tidak efektif karena verifikasi tidak sesuai dengan batas transaksi (0.5 detik).

Efisiensi verifikasi adalah salah satu persyaratan terpenting untuk penggunaan, secara umum, skema kriptografi tingkat lanjut apa pun di blockchain. Membuat bukti, menyiapkan pesan - prosedur ini dapat dilakukan secara off-chain dan dilakukan pada komputer berperforma tinggi, namun verifikasi tidak dapat dilewati - ini adalah persyaratan penting lainnya untuk PVRB.

PVRB dan tanda tangan ambang batas

Setelah mengetahui skema pembagian rahasia, kami menemukan seluruh kelas protokol yang disatukan oleh kata kunci “ambang batas”. Ketika pengungkapan beberapa informasi memerlukan partisipasi M peserta yang jujur ​​dari N, dan himpunan peserta yang jujur ​​dapat menjadi subset sembarang dari N, kita menyebutnya skema “ambang batas”. Merekalah yang mengizinkan kita untuk menangani masalah “aktor terakhir”, sekarang jika penyerang tidak mengungkapkan bagian rahasianya, peserta lain yang jujur ​​​​akan melakukannya untuknya. Skema ini memungkinkan adanya kesepakatan mengenai satu makna, bahkan jika protokol tersebut disabotase oleh beberapa peserta.

Kombinasi tanda tangan deterministik dan skema ambang batas memungkinkan untuk mengembangkan skema yang sangat nyaman dan menjanjikan untuk penerapan PVRB - ini adalah tanda ambang batas deterministik. Di Sini artikel tentang berbagai penggunaan tanda ambang batas, dan inilah satu lagi yang bagus longread dari Dash.

Artikel terakhir menjelaskan tanda tangan BLS (BLS adalah singkatan dari Boneh-Lynn-Shacham, di sini artikel), yang memiliki kualitas yang sangat penting dan sangat nyaman bagi pemrogram - publik, rahasia, kunci publik, dan tanda tangan BLS dapat digabungkan satu sama lain menggunakan operasi matematika sederhana, sementara kombinasinya tetap menjadi kunci dan tanda tangan yang valid, sehingga Anda dapat dengan mudah menggabungkan banyak tanda tangan menjadi satu dan banyak kunci publik menjadi satu. Mereka juga deterministik dan menghasilkan hasil yang sama untuk data masukan yang sama. Berkat kualitas ini, kombinasi tanda tangan BLS sendiri merupakan kunci yang valid, yang memungkinkan penerapan opsi di mana peserta M dari N menghasilkan satu dan hanya satu tanda tangan yang bersifat deterministik, dapat diverifikasi secara publik, dan tidak dapat diprediksi hingga dibuka oleh Mth. peserta.

Dalam skema dengan tanda tangan ambang batas BLS, setiap peserta menandatangani sesuatu menggunakan BLS (misalnya, acak sebelumnya), dan tanda tangan ambang batas yang umum adalah acak yang diinginkan. Properti kriptografi tanda tangan BLS memenuhi persyaratan kualitas acak, bagian ambang batas melindungi dari "aktor terakhir", dan kombinasi kunci yang unik memungkinkan penerapan lebih banyak algoritme menarik yang memungkinkan, misalnya, agregasi pesan protokol yang efisien .

Jadi, jika Anda membangun PVRB di blockchain Anda, kemungkinan besar Anda akan mendapatkan skema tanda tangan ambang batas BLS, karena beberapa proyek sudah menggunakannya. Misalnya, Dfinitas (di sini benchmark yang mengimplementasikan rangkaian, dan di sini contoh penerapan pembagian rahasia yang dapat diverifikasi), atau Keep.network (inilah suar acaknya kertas kuning, Tapi contoh kontrak pintar yang melayani protokol).

Implementasi PVRB

Sayangnya, kami masih belum melihat protokol siap pakai yang diterapkan di blockchain PVRB yang telah membuktikan keamanan dan stabilitasnya. Meskipun protokolnya sendiri sudah siap, secara teknis menerapkannya pada solusi yang ada tidaklah mudah. Untuk sistem terpusat, PVRB tidak masuk akal, dan sistem terdesentralisasi sangat terbatas pada semua sumber daya komputasi: CPU, memori, penyimpanan, I/O. Merancang PVRB adalah kombinasi dari berbagai protokol untuk menciptakan sesuatu yang memenuhi semua persyaratan untuk setidaknya beberapa blockchain yang layak. Satu protokol menghitung lebih efisien, namun memerlukan lebih banyak pesan antar RP, sedangkan protokol lainnya memerlukan sangat sedikit pesan, namun membuat bukti bisa menjadi tugas yang memakan waktu puluhan menit, atau bahkan berjam-jam.

Saya akan mencantumkan faktor-faktor yang harus Anda pertimbangkan ketika memilih PVRB yang berkualitas:

• Kekuatan kriptografi. PVRB Anda harus benar-benar tidak dapat diubah, tanpa kemampuan untuk mengontrol sedikit pun. Dalam beberapa skema hal ini tidak terjadi, jadi panggillah seorang kriptografer
• Masalah “aktor terakhir”.. PVRB Anda harus tahan terhadap serangan di mana penyerang yang mengendalikan satu atau lebih RP dapat memilih salah satu dari dua hasil.
• Masalah sabotase protokol. PVRB Anda harus tahan terhadap serangan di mana penyerang yang mengendalikan satu atau lebih RP memutuskan apakah akan acak atau tidak dan dapat dijamin atau dengan probabilitas tertentu untuk mempengaruhi hal ini.
• Masalah jumlah pesan. RP Anda harus mengirimkan pesan minimum ke blockchain dan sebisa mungkin menghindari tindakan sinkron seperti situasi seperti “Saya mengirim beberapa informasi, saya menunggu tanggapan dari peserta tertentu.” Dalam jaringan p2p, terutama yang tersebar secara geografis, Anda tidak boleh mengandalkan respons yang cepat
• Masalah kompleksitas komputasi. Verifikasi setiap tahap on-chain PVRB seharusnya sangat mudah, karena dilakukan oleh semua klien penuh jaringan. Jika implementasinya dilakukan menggunakan kontrak pintar, maka persyaratan kecepatannya sangat ketat
• Masalah aksesibilitas dan keaktifan. PVRB Anda harus berusaha untuk tahan terhadap situasi di mana bagian dari jaringan menjadi tidak tersedia untuk jangka waktu tertentu dan bagian dari RP berhenti bekerja.
• Masalah pengaturan tepercaya dan distribusi kunci awal. Jika PVRB Anda menggunakan pengaturan utama protokol, maka ini adalah cerita besar dan serius yang terpisah. Di Sini contoh. Jika peserta harus saling memberitahukan kuncinya sebelum memulai protokol, hal ini juga menjadi masalah jika komposisi peserta berubah
• Masalah pembangunan. Ketersediaan perpustakaan dalam bahasa yang diperlukan, keamanan dan kinerjanya, publisitas, pengujian kompleks, dll.

Misalnya, tanda tangan BLS ambang batas memiliki masalah yang signifikan - sebelum mulai bekerja, peserta harus mendistribusikan kunci satu sama lain, mengatur kelompok di mana ambang batas akan berfungsi. Ini berarti bahwa setidaknya satu putaran pertukaran dalam jaringan terdesentralisasi harus menunggu, dan mengingat bahwa rand yang dihasilkan, misalnya, diperlukan dalam permainan, hampir secara real-time, ini berarti sabotase protokol mungkin terjadi pada tahap ini. , dan keuntungan skema ambang batas pun hilang. Permasalahan ini sudah lebih sederhana dari permasalahan sebelumnya, namun masih memerlukan pengembangan prosedur tersendiri untuk pembentukan kelompok ambang batas, yang harus dilindungi secara ekonomi, melalui penyetoran dan penarikan dana (slashing) dari peserta yang tidak mengikuti. protokol. Selain itu, verifikasi BLS dengan tingkat keamanan yang dapat diterima tidak cocok, misalnya, dengan transaksi standar EOS atau Ethereum - tidak ada cukup waktu untuk verifikasi. Kode kontraknya adalah WebAssembly atau EVM, dijalankan oleh mesin virtual. Fungsi kriptografi belum diimplementasikan secara asli, dan bekerja sepuluh kali lebih lambat dibandingkan perpustakaan kriptografi konvensional. Banyak protokol yang tidak memenuhi persyaratan hanya berdasarkan volume kunci, misalnya 1024 dan 2048 bit untuk RSA, 4-8 kali lebih besar dari tanda tangan transaksi standar di Bitcoin dan Ethereum.

Kehadiran implementasi dalam berbagai bahasa pemrograman juga berperan - yang jumlahnya sedikit, terutama untuk protokol baru. Opsi integrasi ke dalam konsensus memerlukan penulisan protokol dalam bahasa platform, jadi Anda harus mencari kode di Go untuk geth, di Rust untuk Parity, di C++ untuk EOS. Setiap orang harus mencari kode JavaScript, dan karena JavaScript dan kriptografi bukanlah teman dekat, WebAssembly akan membantu, yang sekarang pasti diklaim sebagai standar Internet penting berikutnya.

Kesimpulan

Saya berharap pada yang sebelumnya Artikel Saya berhasil meyakinkan Anda bahwa menghasilkan angka acak di blockchain sangat penting untuk banyak aspek kehidupan jaringan terdesentralisasi, dan dengan artikel ini saya menunjukkan bahwa tugas ini sangat ambisius dan sulit, namun solusi yang baik sudah ada. Secara umum, desain akhir protokol hanya mungkin dilakukan setelah melakukan pengujian besar-besaran yang mempertimbangkan semua aspek mulai dari penyiapan hingga emulasi kesalahan, jadi Anda tidak mungkin menemukan resep yang sudah jadi di whitepaper dan artikel tim, dan kami pasti tidak akan menemukannya. putuskan dalam satu atau dua tahun ke depan tulislah “lakukan dengan cara ini, tepat sekali.”

Sampai jumpa, untuk PVRB kami di blockchain sedang dikembangkan Haya, kami memutuskan untuk menggunakan ambang batas tanda tangan BLS, kami berencana untuk menerapkan PVRB pada tingkat konsensus, karena verifikasi dalam kontrak pintar dengan tingkat keamanan yang dapat diterima belum memungkinkan. Ada kemungkinan bahwa kita menggunakan dua skema sekaligus: pertama, pembagian rahasia yang mahal untuk membuat random_seed jangka panjang, dan kemudian kita menggunakannya sebagai dasar untuk pembangkitan acak frekuensi tinggi menggunakan tanda tangan BLS ambang deterministik, mungkin kita akan membatasi diri hanya pada salah satu skemanya. Sayangnya, tidak mungkin untuk mengatakan sebelumnya protokol apa yang akan digunakan; satu-satunya hal yang baik adalah, seperti dalam sains, dalam masalah teknik, hasil negatif juga merupakan hasil, dan setiap upaya baru untuk memecahkan masalah adalah langkah lain untuk mencapai tujuan tersebut. penelitian semua orang yang terlibat dalam masalah tersebut. Untuk memenuhi kebutuhan bisnis, kami memecahkan masalah praktis tertentu - menyediakan aplikasi game dengan sumber entropi yang andal, jadi kami juga harus memperhatikan blockchain itu sendiri, khususnya masalah finalitas rantai dan tata kelola jaringan.

Dan meskipun kita belum melihat PVRB yang terbukti resisten dalam blockchain, yang akan digunakan dalam waktu yang cukup lama untuk diuji oleh aplikasi nyata, banyak audit, pemuatan, dan tentu saja, serangan nyata, namun jumlah jalur yang mungkin menegaskan hal itu ada solusi, dan algoritma mana yang pada akhirnya akan menyelesaikan masalah. Kami akan dengan senang hati membagikan hasilnya dan berterima kasih kepada tim lain yang juga menangani masalah ini atas artikel dan kode yang memungkinkan para insinyur untuk tidak menginjak risiko yang sama dua kali.

Jadi, ketika Anda bertemu dengan seorang programmer yang merancang desentralisasi acak, berhati-hatilah dan penuh perhatian, dan berikan bantuan psikologis jika diperlukan :)

Sumber: www.habr.com