Pengenalan

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

Seperti konsep sifir yang benar-benar kuat daripada kriptografi, protokol “Publicly Verifiable Random Beacon” (selepas ini PVRB) sebenar hanya cuba mendekati skema yang ideal, kerana dalam rangkaian sebenar ia tidak terpakai dalam bentuk tulennya: adalah perlu untuk bersetuju dengan ketat pada satu bit, mesti ada banyak pusingan, dan semua mesej mesti pantas dengan sempurna dan sentiasa dihantar. Sudah tentu, ini tidak berlaku dalam rangkaian sebenar. Oleh itu, apabila mereka bentuk PVRB untuk tugas-tugas tertentu dalam blockchain moden, sebagai tambahan kepada kemustahilan untuk mengawal rawak dan kekuatan kriptografi yang terhasil, banyak lagi masalah seni bina dan teknikal semata-mata timbul.

Bagi PVRB, blockchain itu sendiri pada asasnya adalah medium komunikasi di mana mesej = transaksi. Ini membolehkan anda mengasingkan sebahagian daripada masalah rangkaian, tidak menghantar mesej, masalah dengan perisian tengah - semua risiko ini diandaikan oleh rangkaian terdesentralisasi, dan nilai utamanya untuk PVRB ialah ketidakupayaan untuk membatalkan atau merosakkan transaksi yang telah dihantar - ini tidak tidak membenarkan peserta enggan menyertai protokol, melainkan mereka berjaya melakukan serangan terhadap konsensus. Tahap keselamatan ini boleh diterima, jadi PVRB harus tahan terhadap pakatan sulit oleh peserta pada tahap yang sama seperti rantaian blok utama. Selain itu, ini membayangkan bahawa PVRB mesti menjadi sebahagian daripada konsensus jika rangkaian bersetuju dengan blockchain utama, walaupun ia juga bersetuju dengan satu-satunya rawak yang terhasil secara adil. Atau, PVRB hanyalah protokol kendiri yang dilaksanakan oleh kontrak pintar yang berfungsi secara tidak segerak berkenaan dengan blok dan blok. Kedua-dua kaedah mempunyai kelebihan dan kekurangan mereka, dan pilihan di antara mereka adalah sangat tidak remeh.

Dua cara untuk melaksanakan PVRB

Mari kita terangkan dengan lebih terperinci dua pilihan untuk melaksanakan PVRB - versi kendiri, yang berfungsi menggunakan kontrak pintar bebas daripada rantaian blok, dan versi bersepadu konsensus, yang dibina ke dalam protokol, mengikut mana rangkaian bersetuju dengan rantaian blok dan transaksi yang perlu disertakan. Dalam semua kes, saya maksudkan enjin blockchain yang popular: Ethereum, EOS, dan semua yang serupa dengannya dalam cara mereka mengehos dan memproses kontrak pintar.

Kontrak bersendirian

Dalam versi ini, PVRB ialah kontrak pintar yang menerima urus niaga pengeluar rawak (selepas ini dirujuk sebagai RP), memprosesnya, menggabungkan keputusan dan, sebagai hasilnya, mencapai nilai tertentu yang boleh diterima oleh mana-mana pengguna daripada kontrak ini. Nilai ini mungkin tidak disimpan secara langsung dalam kontrak, sebaliknya hanya diwakili oleh data yang mana satu dan hanya satu nilai rawak yang terhasil boleh diperoleh secara deterministik. Dalam skim ini, RP adalah pengguna blokchain, dan sesiapa sahaja boleh dibenarkan untuk mengambil bahagian dalam proses penjanaan.

Pilihan dengan kontrak mandiri adalah baik:

• mudah alih (kontrak boleh diseret dari blockchain ke blockchain)
• kemudahan pelaksanaan dan ujian (kontrak mudah ditulis dan diuji)
• kemudahan dalam melaksanakan skim ekonomi (mudah untuk membuat token anda sendiri, yang logiknya memenuhi tujuan PVRB)
• kemungkinan dilancarkan pada blockchain yang sudah berfungsi

Ia juga mempunyai kelemahan:

• had kuat pada sumber pengkomputeran, volum transaksi dan storan (dengan kata lain, cpu/mem/io)
• sekatan ke atas operasi dalam kontrak (tidak semua arahan tersedia, sukar untuk menyambungkan perpustakaan luaran)
• ketidakupayaan untuk mengatur pemesejan lebih cepat daripada urus niaga yang disertakan dalam rantaian blok

Pilihan ini sesuai untuk melaksanakan PVRB yang perlu dijalankan pada rangkaian sedia ada, tidak mengandungi kriptografi yang kompleks dan tidak memerlukan bilangan interaksi yang banyak.

Bersepadu konsensus

Dalam versi ini, PVRB dilaksanakan dalam kod nod blockchain, terbina dalam atau berjalan selari dengan pertukaran mesej antara nod blockchain. Keputusan protokol ditulis terus ke dalam blok yang dihasilkan, dan mesej protokol dihantar melalui rangkaian p2p antara nod. Oleh kerana protokol menghasilkan nombor yang akan ditulis dalam blok, rangkaian mesti mencapai kata sepakat mengenainya. Ini bermakna mesej PVRB, seperti transaksi, mesti disahkan oleh nod dan disertakan dalam blok supaya mana-mana peserta rangkaian boleh mengesahkan pematuhan dengan protokol PVRB. Ini secara automatik membawa kita kepada penyelesaian yang jelas - jika rangkaian bersetuju dengan konsensus tentang blok dan transaksi di dalamnya, maka PVRB harus menjadi sebahagian daripada konsensus, dan bukan protokol yang berdiri sendiri. Jika tidak, ada kemungkinan blok itu sah dari sudut pandangan konsensus, tetapi protokol PVRB tidak diikuti, dan dari sudut pandangan PVRB blok itu tidak boleh diterima. Jadi jika pilihan "bersepadu konsensus" dipilih, PVRB menjadi bahagian penting dalam konsensus.

Apabila menerangkan pelaksanaan PVRB di peringkat konsensus rangkaian, seseorang tidak boleh dengan apa-apa cara mengelak isu muktamad. Kemuktamadan ialah mekanisme yang digunakan dalam konsensus deterministik yang mengunci blok (dan rantaian yang membawa kepadanya) yang muktamad dan tidak akan dibuang begitu sahaja, walaupun garpu selari berlaku. Sebagai contoh, dalam Bitcoin tidak ada mekanisme sedemikian - jika anda menerbitkan rantaian yang lebih kompleks, ia akan menggantikan mana-mana yang kurang kompleks, tanpa mengira panjang rantai. Dan dalam EOS, sebagai contoh, yang terakhir adalah apa yang dipanggil Blok Tidak Boleh Balik Terakhir, yang muncul secara purata setiap 432 blok (12*21 + 12*15, pra-undi + pra-komit). Proses ini pada asasnya sedang menunggu 2/3 daripada pengeluar blok (selepas ini dirujuk sebagai BP) tandatangan. Apabila garpu kelihatan lebih tua daripada LIB yang terakhir, ia dibuang begitu sahaja. Mekanisme ini memungkinkan untuk menjamin bahawa urus niaga itu termasuk dalam rantaian blok dan tidak akan ditarik balik, tidak kira apa sumber yang dimiliki oleh penyerang. Juga, blok terakhir ialah blok yang ditandatangani oleh 2/3 BP dalam Hyperledger, Tendermint dan konsensus berasaskan pBFT yang lain. Juga, adalah wajar untuk membuat protokol untuk memastikan kemuktamadan sebagai tambahan kepada konsensus, kerana ia boleh berfungsi secara tidak segerak dengan pengeluaran dan penerbitan blok. Ini yang bagus artikel tentang muktamad dalam Ethereum.

Kesempurnaan adalah amat penting bagi pengguna, yang tanpanya mungkin mendapati diri mereka mangsa serangan "berbelanja dua kali", di mana BP "memegang" sekatan, dan menerbitkannya selepas rangkaian "melihat" transaksi yang baik. Jika tiada muktamad, maka garpu yang diterbitkan menggantikan blok dengan transaksi "baik" dengan yang lain, daripada garpu "buruk", di mana dana yang sama dipindahkan ke alamat penyerang. Dalam kes PVRB, keperluan untuk muktamad adalah lebih ketat, kerana membina garpu untuk PVRB bermakna peluang untuk penyerang menyediakan beberapa pilihan rawak untuk menerbitkan pilihan yang paling menguntungkan, dan mengehadkan masa kemungkinan serangan adalah penyelesaian yang baik.

Oleh itu, pilihan terbaik ialah menggabungkan PVRB dan muktamad menjadi satu protokol - kemudian blok yang dimuktamadkan = dimuktamadkan rawak, dan inilah yang kami perlukan untuk mendapatkannya. Kini pemain akan menerima rawak terjamin dalam N saat, dan boleh memastikan bahawa adalah mustahil untuk melancarkannya semula atau memainkannya semula.

Pilihan bersepadu konsensus adalah baik:

• kemungkinan pelaksanaan tak segerak berhubung dengan pengeluaran blok - blok dihasilkan seperti biasa, tetapi selari dengan ini, protokol PVRB boleh berfungsi, yang tidak menghasilkan rawak untuk setiap blok
• keupayaan untuk melaksanakan kriptografi walaupun berat, tanpa sekatan yang dikenakan ke atas kontrak pintar
• keupayaan untuk mengatur pertukaran mesej lebih cepat daripada urus niaga termasuk dalam rantaian blok, sebagai contoh, sebahagian daripada protokol boleh berfungsi antara nod tanpa mengedarkan mesej melalui rangkaian

Ia juga mempunyai kelemahan:

• Kesukaran dalam ujian dan pembangunan - anda perlu meniru ralat rangkaian, nod yang hilang, garpu keras rangkaian
• Ralat pelaksanaan memerlukan hardfork rangkaian

Kedua-dua kaedah melaksanakan PVRB mempunyai hak untuk hidup, tetapi pelaksanaan pada kontrak pintar dalam blok blok moden masih agak terhad dalam sumber pengkomputeran, dan sebarang peralihan kepada kriptografi yang serius selalunya mustahil. Dan kami memerlukan kriptografi yang serius, seperti yang akan ditunjukkan di bawah. Walaupun masalah ini jelas bersifat sementara, kriptografi yang serius dalam kontrak diperlukan untuk menyelesaikan banyak masalah, dan ia secara beransur-ansur muncul (contohnya, kontrak sistem untuk zkSNARK dalam Ethereum)

Blockchain, yang menyediakan saluran pemesejan protokol yang telus dan boleh dipercayai, tidak melakukannya secara percuma. Mana-mana protokol terdesentralisasi mesti mengambil kira kemungkinan serangan Sybil; sebarang tindakan boleh dilakukan oleh kuasa bersepadu berbilang akaun, oleh itu, apabila mereka bentuk, adalah perlu untuk mengambil kira keupayaan penyerang untuk mencipta bilangan protokol yang sewenang-wenangnya. peserta yang bertindak bersubahat.

PVRB dan pembolehubah blok.

Saya tidak berbohong apabila saya mengatakan bahawa belum ada sesiapa yang melaksanakan PVRB yang baik, diuji oleh banyak aplikasi perjudian, dalam rantaian blok. Dari mana datangnya begitu banyak aplikasi perjudian di Ethereum dan EOS? Ini mengejutkan saya sama seperti mengejutkan anda, di manakah mereka mendapat begitu banyak rawak "berterusan" dalam persekitaran yang benar-benar deterministik?

Cara kegemaran untuk mendapatkan rawak dalam rantaian blok adalah dengan mengambil beberapa jenis maklumat "tidak dapat diramalkan" dari blok dan membuat satu rawak berdasarkannya - hanya dengan mencincang satu atau lebih nilai. Artikel yang baik tentang masalah skim tersebut di sini. Anda boleh mengambil mana-mana nilai "tidak dapat diramalkan" dalam blok, sebagai contoh, cincang blok, bilangan transaksi, kerumitan rangkaian dan nilai lain yang tidak diketahui terlebih dahulu. Kemudian cincang mereka, satu atau lebih, dan, secara teori, anda harus mendapat rawak sebenar. Anda juga boleh menambah pada kertas whiite bahawa skim anda adalah "selamat selepas kuantum" (kerana terdapat fungsi cincang kalis kuantum :)).

Tetapi cincang selamat selepas kuantum tidak mencukupi, malangnya. Rahsianya terletak pada keperluan untuk PVRB, izinkan saya mengingatkan anda tentangnya dari artikel sebelumnya:

1. Hasilnya mesti mempunyai pengedaran seragam yang terbukti, iaitu berdasarkan kriptografi yang terbukti kukuh.
2. Ia tidak mungkin untuk mengawal mana-mana bit hasil. Akibatnya, hasilnya tidak dapat diramalkan terlebih dahulu.
3. Anda tidak boleh mensabotaj protokol penjanaan dengan tidak mengambil bahagian dalam protokol atau dengan membebankan rangkaian dengan mesej serangan
4. Semua perkara di atas mestilah tahan terhadap pakatan sulit bilangan peserta protokol yang tidak jujur ​​yang dibenarkan (contohnya, 1/3 daripada peserta).

Dalam kes ini, hanya keperluan 1 dipenuhi, dan keperluan 2 tidak dipenuhi. Dengan mencincang nilai yang tidak dapat diramalkan daripada blok, kita akan mendapat pengedaran seragam dan rawak yang baik. Tetapi BP sekurang-kurangnya mempunyai pilihan untuk "menerbitkan blok itu atau tidak." Oleh itu, BP sekurang-kurangnya boleh memilih daripada DUA pilihan rawak: "sendiri" dan pilihan yang akan berlaku jika orang lain membuat blok. BP boleh "mengintip" terlebih dahulu apa yang akan berlaku jika dia menerbitkan blok, dan hanya memutuskan untuk melakukannya atau tidak. Oleh itu, apabila bermain, sebagai contoh, "ganjil genap" atau "merah/hitam" dalam rolet, dia boleh menerbitkan blok hanya jika dia melihat kemenangan. Ini juga menjadikan strategi menggunakan, sebagai contoh, cincangan blok "dari masa depan" tidak dapat dilaksanakan. Dalam kes ini, mereka mengatakan bahawa "rawak akan digunakan, yang diperolehi dengan pencincangan data semasa dan cincang blok masa depan dengan ketinggian, sebagai contoh, N + 42, di mana N ialah ketinggian blok semasa. Ini mengukuhkan sedikit skim itu, tetapi masih membenarkan BP, walaupun pada masa hadapan, memilih sama ada untuk memegang blok atau menerbitkan.

Perisian BP dalam kes ini menjadi lebih rumit, tetapi tidak banyak. Secara mudah, apabila mengesahkan dan memasukkan transaksi dalam blok, terdapat semakan pantas untuk melihat sama ada akan ada kemenangan, dan, mungkin, pemilihan satu parameter transaksi untuk mendapatkan kebarangkalian yang tinggi untuk menang. Pada masa yang sama, hampir mustahil untuk menangkap BP pintar untuk manipulasi sedemikian; setiap kali anda boleh menggunakan alamat baharu dan menang sedikit demi sedikit tanpa menimbulkan syak wasangka.

Jadi kaedah menggunakan maklumat dari blok tidak sesuai sebagai pelaksanaan universal PVRB. Dalam versi terhad, dengan sekatan pada saiz pertaruhan, sekatan pada bilangan pemain dan/atau pendaftaran KYC (untuk menghalang seorang pemain daripada menggunakan berbilang alamat), skim ini boleh berfungsi untuk permainan kecil, tetapi tidak lebih.

PVRB dan komit-dedah.

Okey, terima kasih kepada pencincangan dan sekurang-kurangnya ketidakpastian relatif cincang blok dan pembolehubah lain. Jika anda menyelesaikan masalah pelombong hadapan, anda harus mendapatkan sesuatu yang lebih sesuai. Mari tambah pengguna pada skim ini - biarkan mereka turut mempengaruhi kerawak: mana-mana pekerja sokongan teknikal akan memberitahu anda bahawa perkara yang paling rawak dalam sistem IT ialah tindakan pengguna :)

Skim naif, apabila pengguna hanya menghantar nombor rawak dan hasilnya dikira sebagai, sebagai contoh, cincang jumlah mereka, tidak sesuai. Dalam kes ini, pemain terakhir boleh, dengan memilih rawaknya sendiri, mengawal keputusannya. Inilah sebabnya mengapa corak commit-reveal yang digunakan secara meluas digunakan. Peserta mula-mula menghantar cincang daripada rawak mereka (komit), dan kemudian membuka rawak itu sendiri (mendedahkan). Fasa "pendedahan" bermula hanya selepas komitmen yang diperlukan telah dikumpulkan, jadi peserta boleh menghantar cincang rawak yang mereka hantar sebelum ini. Sekarang mari kita letakkan semua ini bersama-sama dengan parameter blok, dan lebih baik daripada yang diambil dari masa depan (kerawak hanya boleh didapati di salah satu blok masa depan), dan voila - kerawak sudah sedia! Kini mana-mana pemain mempengaruhi rawak yang terhasil, dan boleh "mengalahkan" BP berniat jahat dengan mengatasinya dengan rawak miliknya sendiri, tidak diketahui terlebih dahulu... Anda juga boleh menambah perlindungan terhadap sabotaj protokol dengan tidak membukanya pada peringkat pendedahan - hanya dengan menghendaki jumlah tertentu dilampirkan pada transaksi apabila melakukan — deposit keselamatan, yang akan dikembalikan hanya semasa prosedur mendedahkan. Dalam kes ini, melakukan dan tidak mendedahkan akan menjadi tidak menguntungkan.

Ia adalah percubaan yang baik, dan skim sedemikian juga wujud dalam DApps permainan, tetapi malangnya, ini sekali lagi tidak mencukupi. Kini bukan sahaja pelombong, tetapi juga mana-mana peserta dalam protokol boleh mempengaruhi hasilnya. Ia masih mungkin untuk mengawal nilai itu sendiri, dengan kurang kebolehubahan dan pada kos, tetapi, seperti dalam kes pelombong, jika hasil lukisan lebih berharga daripada bayaran untuk penyertaan dalam protokol PVRB, maka rawak -producer(RP) boleh memutuskan sama ada untuk mendedahkan dan masih boleh memilih daripada sekurang-kurangnya dua pilihan rawak.
Tetapi ia menjadi mungkin untuk menghukum mereka yang melakukan dan tidak mendedahkan, dan skim ini akan berguna. Kesederhanaannya adalah kelebihan yang serius - protokol yang lebih serius memerlukan pengiraan yang lebih berkuasa.

PVRB dan tandatangan deterministik.

Terdapat satu lagi cara untuk memaksa RP menyediakan nombor rawak semu yang tidak boleh dipengaruhi jika ia disediakan dengan "praimej" - ini adalah tandatangan deterministik. Tandatangan sedemikian adalah, sebagai contoh, RSA, dan bukan ECS. Jika RP mempunyai sepasang kunci: RSA dan ECC, dan dia menandatangani nilai tertentu dengan kunci peribadinya, maka dalam kes RSA dia akan mendapat SATU DAN SAHAJA SATU tandatangan, dan dalam kes ECS dia boleh menjana sebarang nombor tandatangan sah yang berbeza. Ini kerana apabila mencipta tandatangan ECS, nombor rawak digunakan, dipilih oleh penandatangan, dan ia boleh dipilih dalam apa jua cara, memberi peluang kepada penandatangan untuk memilih salah satu daripada beberapa tandatangan. Dalam kes RSA: "satu nilai input" + "satu pasangan kunci" = "satu tandatangan". Adalah mustahil untuk meramalkan tandatangan yang akan diperolehi oleh RP lain, jadi PVRB dengan tandatangan deterministik boleh dianjurkan dengan menggabungkan tandatangan RSA beberapa peserta yang menandatangani nilai yang sama. Sebagai contoh, rawak sebelumnya. Skim ini menjimatkan banyak sumber, kerana tandatangan adalah kedua-dua pengesahan tingkah laku yang betul mengikut protokol dan sumber rawak.

Walau bagaimanapun, walaupun dengan tandatangan deterministik, skim ini masih terdedah kepada masalah "pelakon terakhir". Peserta terakhir masih boleh memutuskan sama ada untuk menerbitkan tandatangan atau tidak, dengan itu mengawal keputusan. Anda boleh mengubah suai skema, menambah cincang blok padanya, membuat pusingan supaya hasilnya tidak dapat diramalkan terlebih dahulu, tetapi semua teknik ini, walaupun mengambil kira banyak pengubahsuaian, masih meninggalkan masalah pengaruh satu peserta pada kolektif yang tidak dapat diselesaikan. mengakibatkan persekitaran yang tidak dipercayai dan hanya boleh bekerja di bawah kekangan ekonomi dan masa. Di samping itu, saiz kunci RSA (1024 dan 2048 bit) adalah agak besar, dan saiz untuk urus niaga blockchain adalah parameter yang sangat penting. Nampaknya tiada cara mudah untuk menyelesaikan masalah, mari kita teruskan.

PVRB dan skim perkongsian rahsia

Dalam kriptografi, terdapat skim yang boleh membenarkan rangkaian bersetuju dengan satu dan hanya satu nilai PVRB, manakala skim tersebut tahan terhadap sebarang tindakan berniat jahat sesetengah peserta. Satu protokol berguna yang patut dibiasakan ialah skim perkongsian rahsia Shamir. Ia berfungsi untuk membahagikan rahsia (contohnya, kunci rahsia) kepada beberapa bahagian, dan mengedarkan bahagian ini kepada N peserta. Rahsia itu diedarkan sedemikian rupa sehingga M bahagian daripada N cukup untuk memulihkannya, dan ini boleh menjadi mana-mana bahagian M. Jika menggunakan jari, kemudian mempunyai graf fungsi yang tidak diketahui, peserta bertukar mata pada graf, dan selepas menerima mata M, keseluruhan fungsi boleh dipulihkan.
Penjelasan yang baik diberikan dalam wiki tetapi bermain dengannya secara praktikal untuk memainkan protokol di kepala anda berguna untuk demo muka surat.

Sekiranya skim FSSS (Perkongsian Rahsia Fiat-Shamir) digunakan dalam bentuk tulennya, ia akan menjadi PVRB yang tidak boleh dihancurkan. Dalam bentuk yang paling mudah, protokol mungkin kelihatan seperti ini:

• Setiap peserta menjana rawak mereka sendiri dan mengedarkan bahagian daripadanya kepada peserta lain
• Setiap peserta mendedahkan bahagiannya tentang rahsia peserta lain
• Jika seorang peserta mempunyai lebih daripada M saham, maka bilangan peserta ini boleh dikira, dan ia akan menjadi unik, tanpa mengira set peserta yang didedahkan
• Gabungan rawak yang didedahkan ialah PVRB yang dikehendaki

Di sini, peserta individu tidak lagi mempengaruhi keputusan protokol, kecuali dalam kes di mana pencapaian ambang pendedahan rawak hanya bergantung kepadanya. Oleh itu, protokol ini, jika terdapat bahagian RP yang diperlukan yang bekerja pada protokol dan tersedia, berfungsi, melaksanakan keperluan untuk kekuatan kriptografi, dan tahan terhadap masalah "pelaku terakhir".

Ini boleh menjadi pilihan yang ideal, skim PVRB ini berdasarkan perkongsian rahsia Fiat-Shamir diterangkan sebagai contoh dalam ini artikel. Tetapi, seperti yang dinyatakan di atas, jika anda cuba menerapkannya secara langsung dalam rantaian blok, batasan teknikal muncul. Berikut ialah contoh pelaksanaan ujian protokol dalam kontrak pintar EOS dan bahagian terpentingnya - menyemak peserta saham yang diterbitkan: kod. Anda boleh melihat daripada kod bahawa pengesahan bukti memerlukan beberapa pendaraban skalar, dan nombor yang digunakan adalah sangat besar. Perlu difahami bahawa dalam rantaian blok, pengesahan berlaku pada masa ketika pengeluar blok memproses transaksi, dan secara umum, mana-mana peserta mesti dengan mudah mengesahkan ketepatan protokol, jadi keperluan untuk kelajuan fungsi pengesahan adalah sangat serius . Dalam pilihan ini, pilihan tersebut ternyata tidak berkesan, kerana pengesahan tidak sesuai dalam had transaksi (0.5 saat).

Kecekapan pengesahan adalah salah satu keperluan terpenting untuk penggunaan, secara umum, sebarang skim kriptografi lanjutan dalam rantaian blok. Mencipta bukti, menyediakan mesej - prosedur ini boleh diketepikan dan dilakukan pada komputer berprestasi tinggi, tetapi pengesahan tidak boleh dipintas - ini adalah satu lagi keperluan penting untuk PVRB.

PVRB dan tandatangan ambang

Setelah mengetahui skim perkongsian rahsia, kami menemui seluruh kelas protokol yang disatukan oleh kata kunci "ambang". Apabila pendedahan beberapa maklumat memerlukan penyertaan peserta jujur ​​M daripada N, dan set peserta jujur ​​boleh menjadi subset N yang sewenang-wenangnya, kita bercakap tentang skim "ambang". Merekalah yang membenarkan kami menangani masalah "pelakon terakhir", sekarang jika penyerang tidak mendedahkan bahagian rahsianya, peserta lain yang jujur ​​akan melakukannya untuknya. Skim ini membenarkan persetujuan pada satu dan hanya satu makna, walaupun protokol disabotaj oleh sesetengah peserta.

Gabungan tandatangan deterministik dan skim ambang memungkinkan untuk membangunkan skim yang sangat mudah dan menjanjikan untuk melaksanakan PVRB - ini adalah tandatangan ambang deterministik. Di sini artikel tentang pelbagai kegunaan tandatangan ambang, dan inilah satu lagi yang bagus longread daripada Dash.

Artikel terakhir menerangkan tandatangan BLS (BLS bermaksud Boneh-Lynn-Shacham, di sini artikel), yang mempunyai kualiti yang sangat penting dan sangat mudah untuk pengaturcara - awam, rahsia, kunci awam dan tandatangan BLS boleh digabungkan antara satu sama lain menggunakan operasi matematik yang mudah, sementara kombinasinya kekal kunci dan tandatangan yang sah, membolehkan anda mengagregatkan banyak dengan mudah. tandatangan menjadi satu dan banyak kunci awam menjadi satu. Mereka juga bersifat deterministik dan menghasilkan hasil yang sama untuk data input yang sama. Terima kasih kepada kualiti ini, gabungan tandatangan BLS sendiri adalah kunci yang sah, yang membolehkan pelaksanaan pilihan di mana peserta M daripada N menghasilkan satu dan hanya satu tandatangan yang bersifat deterministik, boleh disahkan secara terbuka dan tidak dapat diramalkan sehingga ia dibuka oleh Mth peserta .

Dalam skema dengan tandatangan BLS ambang, setiap peserta menandatangani sesuatu menggunakan BLS (contohnya, rawak sebelumnya), dan tandatangan ambang biasa ialah rawak yang diingini. Sifat kriptografi bagi tandatangan BLS memenuhi keperluan untuk kualiti rawak, bahagian ambang melindungi daripada "aktor terakhir", dan kebolehgabungan unik kunci memungkinkan untuk melaksanakan lebih banyak algoritma menarik yang membolehkan, sebagai contoh, pengagregatan mesej protokol yang cekap .

Jadi, jika anda membina PVRB pada blockchain anda, kemungkinan besar anda akan berakhir dengan skim tandatangan ambang BLS, beberapa projek sudah menggunakannya. Contohnya, DFinity (di sini penanda aras yang melaksanakan litar, dan di sini contoh pelaksanaan perkongsian rahsia yang boleh disahkan), atau Keep.network (berikut ialah suar rawak mereka kertas kuning, Tapi contoh kontrak pintar melayani protokol).

Pelaksanaan PVRB

Malangnya, kami masih tidak melihat protokol siap sedia dilaksanakan dalam blok blok PVRB yang telah membuktikan keselamatan dan kestabilannya. Walaupun protokol itu sendiri sudah sedia, secara teknikal menerapkannya pada penyelesaian sedia ada bukanlah mudah. Untuk sistem terpusat, PVRB tidak masuk akal, dan sistem terdesentralisasi adalah terhad dalam semua sumber pengkomputeran: CPU, memori, storan, I/O. Mereka bentuk PVRB ialah gabungan protokol yang berbeza untuk mencipta sesuatu yang memenuhi semua keperluan untuk sekurang-kurangnya beberapa blockchain yang berdaya maju. Satu protokol mengira dengan lebih cekap, tetapi memerlukan lebih banyak mesej antara RP, manakala yang lain memerlukan sangat sedikit mesej, tetapi mencipta bukti boleh menjadi tugas yang mengambil masa berpuluh-puluh minit, atau bahkan berjam-jam.

Saya akan menyenaraikan faktor yang perlu anda pertimbangkan semasa memilih PVRB yang berkualiti:

• Kekuatan kriptografi. PVRB anda mestilah tidak biasa, tanpa keupayaan untuk mengawal sedikit pun. Dalam sesetengah skim ini tidak berlaku, jadi hubungi jurukriptografi
• Masalah "pelakon terakhir".. PVRB anda mesti tahan terhadap serangan di mana penyerang yang mengawal satu atau lebih RP boleh memilih satu daripada dua hasil.
• Masalah sabotaj protokol. PVRB anda mesti tahan terhadap serangan di mana penyerang yang mengawal satu atau lebih RP memutuskan sama ada secara rawak atau tidak dan sama ada boleh dijamin atau dengan kebarangkalian tertentu untuk mempengaruhi ini
• Bilangan masalah mesej. RP anda harus menghantar mesej minimum kepada blokchain dan mengelakkan tindakan segerak sebanyak mungkin seperti situasi seperti "Saya menghantar beberapa maklumat, saya sedang menunggu jawapan daripada peserta tertentu." Dalam rangkaian p2p, terutamanya yang tersebar secara geografi, anda tidak seharusnya mengharapkan respons pantas
• Masalah kerumitan pengiraan. Pengesahan mana-mana peringkat dalam rantaian PVRB sepatutnya sangat mudah, kerana ia dilakukan oleh semua pelanggan penuh rangkaian. Sekiranya pelaksanaan dilakukan menggunakan kontrak pintar, maka keperluan kelajuan adalah sangat ketat
• Masalah kebolehcapaian dan keaktifan. PVRB anda harus berusaha untuk berdaya tahan terhadap situasi di mana sebahagian daripada rangkaian menjadi tidak tersedia untuk satu tempoh masa dan sebahagian daripada RP hanya berhenti berfungsi
• Masalah persediaan yang dipercayai dan pengedaran kunci awal. Jika PVRB anda menggunakan persediaan utama protokol, maka ini adalah cerita besar dan serius yang berasingan. Di sini contoh. Jika peserta mesti memberitahu satu sama lain kunci mereka sebelum memulakan protokol, ini juga menjadi masalah jika komposisi peserta berubah
• Masalah pembangunan. Ketersediaan perpustakaan dalam bahasa yang diperlukan, keselamatan dan prestasinya, publisiti, ujian kompleks, dsb.

Sebagai contoh, tandatangan BLS ambang mempunyai masalah yang ketara - sebelum mula bekerja, peserta mesti mengedarkan kunci kepada satu sama lain, mengatur kumpulan di mana ambang akan berfungsi. Ini bermakna bahawa sekurang-kurangnya satu pusingan pertukaran dalam rangkaian terdesentralisasi perlu menunggu, dan memandangkan rand yang dijana, sebagai contoh, diperlukan dalam permainan, hampir dalam masa nyata, ini bermakna sabotaj protokol adalah mungkin pada peringkat ini. , dan kelebihan skim ambang hilang . Masalah ini sudah lebih mudah daripada yang sebelumnya, tetapi masih memerlukan pembangunan prosedur berasingan untuk pembentukan kumpulan ambang, yang perlu dilindungi dari segi ekonomi, melalui deposit dan pengeluaran dana (slashing) daripada peserta yang tidak mengikuti protokol. Selain itu, pengesahan BLS dengan tahap keselamatan yang boleh diterima sememangnya tidak sesuai, contohnya, ke dalam transaksi EOS atau Ethereum standard - tiada masa yang cukup untuk pengesahan. Kod kontrak ialah WebAssembly atau EVM, dilaksanakan oleh mesin maya. Fungsi kriptografi tidak dilaksanakan secara asli (belum lagi), dan berfungsi berpuluh kali lebih perlahan daripada perpustakaan kriptografi konvensional. Banyak protokol tidak memenuhi keperluan hanya berdasarkan volum utama, contohnya 1024 dan 2048 bit untuk RSA, 4-8 kali lebih besar daripada tandatangan transaksi standard dalam Bitcoin dan Ethereum.

Kehadiran pelaksanaan dalam bahasa pengaturcaraan yang berbeza juga memainkan peranan - yang terdapat sedikit, terutamanya untuk protokol baharu. Pilihan dengan penyepaduan ke dalam konsensus memerlukan penulisan protokol dalam bahasa platform, jadi anda perlu mencari kod dalam Go for geth, dalam Rust for Parity, dalam C++ untuk EOS. Semua orang perlu mencari kod JavaScript, dan memandangkan JavaScript dan kriptografi bukanlah kawan rapat, WebAssembly akan membantu, yang kini pasti mendakwa sebagai standard Internet penting seterusnya.

Kesimpulan

Saya berharap pada yang sebelumnya artikel Saya berjaya meyakinkan anda bahawa menjana nombor rawak pada blockchain adalah penting untuk banyak aspek kehidupan rangkaian terdesentralisasi, dan dengan artikel ini saya menunjukkan bahawa tugas ini sangat bercita-cita tinggi dan sukar, tetapi penyelesaian yang baik sudah wujud. Secara amnya, reka bentuk akhir protokol hanya boleh dilakukan selepas menjalankan ujian besar-besaran yang mengambil kira semua aspek daripada persediaan kepada emulasi kesalahan, jadi anda tidak mungkin menemui resipi siap sedia dalam kertas putih dan artikel pasukan, dan kami pastinya tidak akan buat keputusan dalam satu atau dua tahun akan datang tulis "lakukan dengan cara ini, betul-betul."

Selamat tinggal, untuk PVRB kami dalam blockchain yang sedang dibangunkan Haya, kami memutuskan untuk menggunakan tandatangan BLS ambang, kami merancang untuk melaksanakan PVRB pada peringkat konsensus, memandangkan pengesahan dalam kontrak pintar dengan tahap keselamatan yang boleh diterima masih belum dapat dilakukan. Ada kemungkinan kami menggunakan dua skim serentak: pertama, perkongsian rahsia yang mahal untuk mencipta random_seed jangka panjang, dan kemudian kami menggunakannya sebagai asas untuk penjanaan rawak frekuensi tinggi menggunakan tandatangan BLS ambang penentu, mungkin kami akan mengehadkan diri kami kepada hanya salah satu skim. Malangnya, adalah mustahil untuk mengatakan terlebih dahulu apakah protokol itu; satu-satunya perkara yang baik ialah, seperti dalam sains, dalam masalah kejuruteraan, hasil negatif juga merupakan hasil, dan setiap percubaan baru untuk menyelesaikan masalah itu adalah satu lagi langkah untuk penyelidikan semua orang yang terlibat dalam masalah tersebut. Untuk memenuhi keperluan perniagaan, kami menyelesaikan masalah praktikal khusus - menyediakan aplikasi permainan dengan sumber entropi yang boleh dipercayai, jadi kami juga perlu memberi perhatian kepada rantaian blok itu sendiri, khususnya isu kemuktamadan rantaian dan tadbir urus rangkaian.

Dan walaupun kita masih belum melihat PVRB tahan terbukti dalam blockchain, yang akan digunakan untuk masa yang cukup untuk diuji oleh aplikasi sebenar, berbilang audit, beban, dan sudah tentu, serangan sebenar, tetapi bilangan laluan yang mungkin mengesahkan bahawa penyelesaian wujud, dan apakah -daripada algoritma ini akhirnya akan menyelesaikan masalah. Kami berbesar hati untuk berkongsi keputusan dan berterima kasih kepada pasukan lain yang turut mengusahakan isu ini untuk artikel dan kod yang membolehkan jurutera tidak memijak rake yang sama dua kali.

Jadi, apabila anda bertemu seorang pengaturcara yang mereka bentuk rawak terdesentralisasi, berhati-hati dan prihatin, dan berikan bantuan psikologi jika perlu :)

Sumber: www.habr.com