perkenalan

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

Salaku kalawan konsép hiji cipher pancen kuat ti kriptografi, nyata "Publicly Verifiable Random Beacon" (hereinafter PVRB) protokol ngan nyoba meunang sacaket mungkin ka skéma idéal, sabab. dina jaringan nyata teu lumaku dina formulir murni na: perlu satuju ketat dina hiji bit, kudu aya loba rounds, sarta sakabeh pesen kudu sampurna gancang sarta salawasna dikirimkeun. Tangtosna, ieu sanés kasus dina jaringan nyata. Ku alatan éta, nalika ngarancang PVRBs pikeun tugas husus dina blockchains modern, sajaba impossibility ngadalikeun randomness hasilna tur kakuatan cryptographic, loba masalah arsitéktur sarta teknis langkung murni timbul.

Pikeun PVRB, blockchain sorangan dasarna mangrupikeun média komunikasi dimana pesen = transaksi. Ieu ngidinan Anjeun pikeun sawaréh abstrak tina masalah jaringan, non-pangiriman pesen, masalah sareng middleware - sagala resiko ieu dianggap ku jaringan desentralisasi, sarta nilai utamana pikeun PVRB nyaeta henteu mampuh nyabut atawa ngaruksak transaksi geus dikirim - ieu teu teu ngidinan pamilon nolak ilubiung dina protokol, iwal aranjeunna dilumangsungkeun serangan suksés on konsensus. Tingkat kaamanan ieu bisa ditarima, jadi PVRB kudu tahan ka kolusi ku pamilon persis extent sarua salaku ranté blockchain utama. Ogé, ieu petunjuk yén PVRB kudu jadi bagian tina konsensus lamun jaringan satuju dina blockchain utama, sanajan eta oge satuju kana hijina adil hasilna acak. Atanapi, PVRB ngan saukur protokol mandiri anu dilaksanakeun ku kontrak pinter anu tiasa dianggo asynchronously sareng blok blok. Kadua metodeu gaduh kaunggulan sareng kalemahanana, sareng pilihan antara aranjeunna henteu sepele.

Dua cara pikeun nerapkeun PVRB

Hayu urang ngajelaskeun dina leuwih jéntré dua pilihan pikeun nerapkeun PVRB - versi mandiri, nu gawéna ngagunakeun kontrak pinter bebas tina blockchain, sarta versi konsensus-terintegrasi, diwangun kana protokol, nurutkeun nu jaringan satuju kana blockchain jeung transaksi kudu kaasup. Dina sagala hal, kuring bakal hartosna mesin blockchain populér: Ethereum, EOS, sareng sadaya anu sami sareng aranjeunna dina cara aranjeunna janten host sareng ngolah kontrak pinter.

Kontrak mandiri

Dina vérsi ieu, PVRB mangrupikeun kontrak pinter anu nampi transaksi produsén acak (saterusna disebut RP), ngolah aranjeunna, ngagabungkeun hasil, sareng, salaku hasilna, dugi ka nilai anu tangtu anu tiasa ditampi ku pangguna tina kontrak ieu. nilai ieu bisa jadi teu disimpen langsung dina kontrak, tapi rada digambarkeun ngan ku data ti nu hiji na ngan hiji nilai acak dihasilkeun deterministically bisa diala. Dina skéma ieu, RPs mangrupakeun pamaké tina blockchain, sarta saha bisa diwenangkeun pikeun ilubiung dina prosés generasi.

Pilihan kalawan mandiri-kontrak téh alus:

• portability (kontrak bisa nyeret tina blockchain ka blockchain)
• betah palaksanaan sareng uji (kontrak gampang ditulis sareng diuji)
• genah dina ngalaksanakeun skéma ékonomi (gampang ngadamel token anjeun nyalira, anu logikana pikeun tujuan PVRB)
• kamungkinan launching on blockchains geus digawé

Éta ogé ngagaduhan kalemahan:

• watesan kuat dina sumber komputasi, volume transaksi jeung neundeun (dina basa sejen, cpu/mem/io)
• larangan dina operasi dina kontrak (teu sakabeh parentah sadia, hese nyambungkeun perpustakaan éksternal)
• henteu mampuh pikeun ngatur olahtalatah leuwih gancang ti transaksi kaasup kana blockchain nu

Pilihan ieu cocog pikeun ngalaksanakeun hiji PVRB anu kedah dijalankeun dina jaringan anu tos aya, henteu ngandung kriptografi rumit sareng henteu ngabutuhkeun sajumlah ageung interaksi.

Konsensus-terpadu

Dina versi ieu, PVRB dilaksanakeun dina kode titik blockchain, diwangun-di atawa ngajalankeun dina paralel jeung bursa pesen antara titik blockchain. Hasil tina protokol ditulis langsung kana blok dihasilkeun, sarta pesen protokol dikirim ngaliwatan jaringan p2p antara titik. Kusabab protokol ngahasilkeun angka anu ditulis dina blok, jaringan kedah ngahontal konsensus ngeunaan aranjeunna. Ieu ngandung harti yén seratan PVRB, kawas transaksi, kudu disahkeun ku titik sarta kaasup dina blok ku kituna sagala pamilon jaringan bisa sangkan méré konfirmasi patuh kana protokol PVRB. Ieu otomatis ngabalukarkeun urang kana leyuran atra - lamun jaringan satuju kana konsensus ngeunaan hiji blok jeung transaksi di dinya, teras PVRB kedah janten bagian tina konsensus, sarta lain protokol mandiri. Upami teu kitu, kasebut nyaéta dimungkinkeun yén blok hiji valid ti titik konsensus of view, tapi protokol PVRB teu dituturkeun, sarta ti sudut pandang PVRB block teu bisa ditarima. Janten upami pilihan "consensus-integrated" dipilih, PVRB janten bagian penting tina konsensus.

Nalika ngajéntrékeun palaksanaan PVRB dina tingkat konsensus jaringan, hiji jalma henteu tiasa ngahindarkeun masalah finalitas. Finality mangrupakeun mékanisme dipaké dina consensuses deterministik nu ngonci dina blok (jeung ranté ngarah ka dinya) nu final sarta moal pernah dialungkeun jauh, sanajan garpu paralel lumangsung. Contona, dina Bitcoin euweuh mékanisme misalna - lamun nyebarkeun ranté tina pajeulitna gede, éta bakal ngaganti sagala kirang kompléks, paduli panjang ranté. Sareng dina EOS, contona, anu terakhir nyaéta anu disebut Blok Anu Teu Bisa Dibalikkeun Terakhir, anu rata-rata muncul unggal 432 blok (12 * 21 + 12 * 15, pre-vote + pre-commit). Prosés ieu dasarna ngantosan 2/3 tina blok-produser (saterusna disebut BP) tanda tangan. Nalika garpu muncul anu langkung lami tibatan LIB anu terakhir, aranjeunna ngan saukur dipiceun. Mékanisme ieu ngamungkinkeun pikeun ngajamin yén urus éta kalebet dina blokchain sareng moal pernah digulung deui, euweuh urusan naon sumber daya panyerang. Ogé, blok ahir nyaéta blok anu ditandatanganan ku 2/3 BP di Hyperledger, Tendermint sareng konsensus dumasar pBFT anu sanés. Ogé, masuk akal pikeun ngadamel protokol pikeun mastikeun finalitas tambihan kana konsensus, sabab tiasa dianggo asynchronously sareng produksi sareng publikasi blok. Di dieu hiji alus artikel ngeunaan finality dina Ethereum.

Finality penting pisan pikeun pamaké, anu tanpa eta bisa manggihan diri korban serangan "ganda méakkeun", dimana BP "nyepeng" blok, sarta publishes aranjeunna sanggeus jaringan geus "nempo" transaksi alus. Upami teu aya finalitas, maka garpu anu diterbitkeun ngagentos blok ku transaksi "alus" sareng anu sanés, tina garpu "goréng", dimana dana anu sami ditransferkeun ka alamat panyerang. Dina kasus PVRB, sarat pikeun finalitas malah langkung ketat, sabab ngawangun garpu pikeun PVRB hartosna kasempetan pikeun panyerang nyiapkeun sababaraha pilihan acak pikeun nyebarkeun anu paling nguntungkeun, sareng ngawatesan waktos serangan anu mungkin nyaéta a solusi alus.

Ku alatan éta, pilihan pangalusna nyaéta ngagabungkeun PVRB na finality kana hiji protokol - lajeng blok finalized = finalized acak, sarta ieu kahayang urang diperlukeun pikeun meunangkeun. Ayeuna pamaén baris nampa hiji acak dijamin dina N detik, tur tiasa pastikeun yén éta téh teu mungkin mun gulung deui atawa replay deui.

Pilihan anu terintegrasi konsensus saé:

• kamungkinan palaksanaan asynchronous dina hubungan produksi blok - blok dihasilkeun sakumaha biasa, tapi sajajar jeung ieu, protokol PVRB bisa jalan, nu teu ngahasilkeun randomness pikeun unggal blok.
• kamampuhan pikeun nerapkeun kriptografi malah beurat, tanpa palarangan ditumpukeun dina kontrak pinter
• Kamampuhan pikeun ngatur bursa pesen anu langkung gancang tibatan transaksi kalebet dina blockchain, contona, bagian tina protokol tiasa dianggo antara titik tanpa nyebarkeun pesen dina jaringan.

Éta ogé ngagaduhan kalemahan:

• Kasesahan dina nguji sareng pamekaran - anjeun kedah niru kasalahan jaringan, titik anu leungit, garpu keras jaringan
• Kasalahan palaksanaan merlukeun hardfork jaringan

Duanana métode palaksanaan PVRB boga hak pikeun hirup, tapi palaksanaan on kontrak pinter dina blockchains modern masih rada kawates dina sumberdaya komputasi, sarta sagala transisi ka kriptografi serius mindeng saukur teu mungkin. Sareng urang peryogi kriptografi anu serius, sapertos anu bakal ditingalikeun di handap ieu. Sanajan masalah ieu jelas samentara, kriptografi serius dina kontrak diperlukeun pikeun ngajawab loba masalah, sarta eta laun muncul (contona, kontrak sistem pikeun zkSNARKs di Ethereum)

Blockchain, anu nyayogikeun saluran olahtalatah protokol anu transparan sareng dipercaya, henteu ngalakukeunana gratis. Sakur protokol desentralisasi kedah merhatikeun kamungkinan serangan Sybil; tindakan naon waé tiasa dilakukeun ku kakuatan gabungan tina sababaraha akun, janten, nalika ngarancang, kedah diperhatoskeun kamampuan panyerang nyiptakeun jumlah protokol anu sawenang. pamilon akting dina kolusi.

PVRB jeung variabel blok.

Kuring henteu ngabohong nalika kuring nyarios yén teu aya anu parantos ngalaksanakeun PVRB anu saé, diuji ku seueur aplikasi judi, dina blockchain. Dimana datangna loba aplikasi judi on Ethereum na EOS? Ieu kaget kuring saloba éta kaget anjeun, dimana maranéhna meunang jadi loba "pengkuh" randoms dina lingkungan lengkep deterministik?

Cara anu paling dipikaresep pikeun kéngingkeun acak dina blokchain nyaéta nyandak sababaraha inpormasi anu "teu diprediksi" tina blok sareng ngadamel acak dumasar kana éta - ngan ukur ku hashing hiji atanapi langkung nilai. Tulisan anu saé ngeunaan masalah skéma sapertos kitu di dieu. Anjeun tiasa nyandak salah sahiji nilai "teu bisa diprediksi" dina blok, contona, blok Hash, jumlah transaksi, pajeulitna jaringan, sareng nilai sanés anu teu dipikanyaho sateuacanna. Teras Hash aranjeunna, hiji atanapi langkung, sareng, dina tiori, anjeun kedah nampi acak nyata. Anjeun malah bisa nambahkeun kana wiitepaper yén skéma anjeun "pos-kuantum aman" (saprak aya fungsi hash kuantum-bukti :)).

Tapi sanajan hashes aman pos-kuantum teu cukup, sayang. Rahasiana aya dina sarat pikeun PVRB, hayu atuh ngingetkeun anjeun tina tulisan sateuacana:

1. Hasilna kedah gaduh distribusi anu seragam, nyaéta dumasar kana kriptografi anu kuat.
2. Teu mungkin ngadalikeun salah sahiji bit hasilna. Hasilna, hasilna teu bisa diprediksi sateuacanna.
3. Anjeun teu tiasa sabotase protokol generasi ku henteu milu dina protokol atanapi ku ngabebankeun jaringan ku pesen serangan.
4. Sadaya di luhur kedah tahan kana kolusi jumlah anu diidinan pamilon protokol anu teu jujur ​​(contona, 1/3 pamilon).

Dina hal ieu, ngan sarat 1 patepung, sarta sarat 2 teu patepung. Ku hashing nilai unpredictable tina blok, urang bakal meunang distribusi seragam jeung randoms alus. Tapi BP sahenteuna ngagaduhan pilihan pikeun "medarkeun blok atanapi henteu." Ku kituna, BP sahenteuna bisa milih ti DUA pilihan acak: "sorangan" jeung hiji nu bakal ngahurungkeun kaluar lamun batur nyieun blok. BP tiasa "snoop" sateuacanna naon anu bakal kajadian lamun anjeunna publishes blok a, sarta ngan mutuskeun ngalakukeun atawa henteu. Ku kituna, nalika maén, Contona, "malah-ganjil" atawa "beureum / hideung" dina roulette, anjeunna tiasa nyebarkeun blok ngan lamun manehna nilik win a. Ieu ogé ngajadikeun strategi ngagunakeun, contona, blok Hash "ti mangsa nu bakal datang" unworkable. Dina hal ieu, aranjeunna nyarios yén "acak bakal dianggo, anu dicandak ku hashing data ayeuna sareng hash blok kahareup kalayan jangkungna, contona, N + 42, dimana N nyaéta jangkungna blok ayeuna. Ieu strengthens skéma saeutik, tapi masih ngamungkinkeun BP, sanajan dina mangsa nu bakal datang, pikeun milih naha nyekel blok atawa nyebarkeun.

software BP dina hal ieu jadi leuwih pajeulit, tapi teu pira. kantun, nalika validating tur kaasup urus di blok a, aya cek rusuh pikeun nempo lamun bakal aya win a, jeung, kamungkinan, Pilihan hiji parameter urus pikeun ménta kamungkinan luhur meunang. Dina waktos anu sami, ampir teu mungkin pikeun nyekel BP pinter pikeun manipulasi sapertos kitu; unggal waktos anjeun tiasa nganggo alamat énggal sareng kéngingkeun sakedik-sakedik tanpa ngahudangkeun kacurigaan.

Jadi métode ngagunakeun informasi ti blok teu cocog salaku palaksanaan universal PVRB. Dina versi kawates, kalawan larangan dina ukuran alungan, larangan dina Jumlah pamaén sarta / atanapi pendaptaran KYC (pikeun nyegah hiji pamuter ti pamakéan sababaraha alamat), schemes ieu tiasa dianggo pikeun kaulinan leutik, tapi euweuh deui.

PVRB sarta komitmen-ngalaan.

Oké, hatur nuhun kana hashing sarta sahenteuna unpredictability relatif blok Hash jeung variabel séjén. Lamun ngajawab masalah panambang hareup-ngajalankeun, Anjeun kudu meunang hal nu leuwih merenah. Hayu urang tambahkeun pamaké kana skéma ieu - hayu aranjeunna ogé mangaruhan randomness nu: sagala pagawe rojongan teknis bakal ngabejaan Anjeun yen hal paling acak dina sistem IT nyaéta lampah pamaké :)

A skéma naif, lamun pamaké saukur ngirimkeun angka acak sarta hasilna diitung salaku, contona, Hash tina jumlah maranéhanana, teu cocog. Dina hal ieu, pamuter panungtungan bisa, ku milih acak sorangan, ngadalikeun naon hasilna bakal. Ieu sababna pola commit-reveal anu seueur dianggo dianggo. Pamilon mimitina ngirim hashes ti randoms maranéhanana (commits), lajeng muka randoms sorangan (nembongkeun). Fase "ngalaan" dimimitian ngan sanggeus commits diperlukeun geus dikumpulkeun, jadi pamilon bisa ngirim persis Hash acak ti mana maranéhna dikirim saméméhna. Ayeuna hayu urang nempatkeun sadayana ieu sareng parameter blok, sareng langkung saé tibatan anu dicandak tina masa depan (kaacak ngan ukur tiasa dipendakan dina salah sahiji blok ka hareup), sareng voila - acakna parantos siap! Ayeuna sagala pamuter pangaruh randomness hasilna, sarta bisa "ngelehkeun" BP jahat ku overriding eta kalawan sorangan, kanyahoan sateuacanna, randomness ... Anjeun oge bisa nambahkeun panyalindungan ngalawan sabotaging protokol ku teu muka eta dina tahap nembongkeun - saukur ku merlukeun jumlah nu tangtu napel transaksi nalika committing - a deposit kaamanan, nu bakal dipulangkeun ngan salila prosedur nembongkeun. Dina hal ieu, committing jeung teu nembongkeun bakal unprofitable.

Ieu usaha alus, sarta skéma kitu ogé aya dina DApps kaulinan, tapi Alas, ieu deui teu cukup. Ayeuna teu ngan panambang, tapi ogé sagala pamilon dina protokol bisa pangaruh hasilna. Ieu masih mungkin pikeun ngadalikeun nilai sorangan, kalawan kirang variability na di ongkos, tapi, sakumaha dina kasus panambang, lamun hasil gambar nu leuwih berharga ti fee pikeun partisipasi dina protokol PVRB, lajeng acak. -produser (RP) bisa mutuskeun pikeun nembongkeun tur masih bisa milih ti sahenteuna dua pilihan acak.
Tapi janten mungkin pikeun ngahukum jalma anu bunuh jeung teu nembongkeun, sarta skéma ieu bakal datang dina gunana. Kesederhanaanna mangrupikeun kauntungan anu serius - protokol anu langkung serius peryogi itungan anu langkung kuat.

PVRB sareng tanda tangan deterministik.

Aya cara séjén pikeun maksakeun RP nyadiakeun angka pseudo-acak nu teu bisa mangaruhan lamun disadiakeun kalawan "preimage" - ieu téh tanda tangan deterministik. Tanda tangan sapertos kitu, contona, RSA, sareng sanés ECS. Upami RP gaduh sapasang konci: RSA sareng ECC, sareng anjeunna nandatanganan nilai anu tangtu sareng konci pribadina, maka dina kasus RSA anjeunna bakal nampi HIJI sareng HIJI tandatangan, sareng dina kasus ECS anjeunna tiasa ngahasilkeun jumlah naon waé. tanda tangan valid béda. Ieu kusabab nalika nyiptakeun tanda tangan ECS, jumlah acak dianggo, dipilih ku panandatangan, sareng éta tiasa dipilih ku cara naon waé, masihan kasempetan pikeun milih salah sahiji tina sababaraha tanda tangan. Dina kasus RSA: "hiji nilai input" + "hiji pasangan konci" = "hiji signature". Teu mungkin keur prediksi naon tanda tangan RP sejen bakal meunang, jadi hiji PVRB kalawan tanda tangan deterministik bisa diatur ku ngagabungkeun tanda tangan RSA sababaraha pamilon anu ditandatanganan nilai sarua. Contona, acak saméméhna. skéma ieu ngaheéat loba sumberdaya, sabab tanda tangan duanana konfirmasi tina kabiasaan bener nurutkeun protokol jeung sumber randomness.

Sanajan kitu, sanajan kalawan tanda tangan deterministik, skéma masih rentan ka masalah "aktor panungtungan". Pamilon anu terakhir masih tiasa mutuskeun naha bakal nyebarkeun tanda tangan atanapi henteu, ku kituna ngadalikeun hasilna. Anjeun tiasa ngaropea skéma, tambahkeun blok hashes ka dinya, nyieun rounds ambéh hasilna teu bisa diprediksi sateuacanna, tapi sakabeh téhnik ieu, sanajan nyokot kana akun loba modifikasi, masih ninggalkeun unresolved masalah pangaruh hiji pamilon dina koléktif. nyababkeun lingkungan anu teu dipercaya sareng ngan ukur tiasa dianggo dina konstrain ékonomi sareng waktos. Salaku tambahan, ukuran konci RSA (1024 sareng 2048 bit) lumayan ageung, sareng ukuran pikeun transaksi blockchain mangrupikeun parameter anu penting pisan. Tétéla euweuh cara basajan pikeun ngajawab masalah, hayu urang ngaléngkah.

PVRB jeung skéma babagi rusiah

Dina kriptografi, aya skéma anu tiasa ngamungkinkeun jaringan pikeun satuju kana hiji-hijina nilai PVRB, sedengkeun skéma sapertos kitu tahan kana tindakan jahat sababaraha pamilon. Hiji protokol mangpaat anu patut familiarizing diri jeung skéma babagi rusiah Shamir. Ieu fungsi pikeun ngabagi hiji rusiah (Contona, konci rusiah) kana sababaraha bagian, sarta ngadistribusikaeun bagian ieu N pamilon. Rahasia disebarkeun ku cara anu bagian M kaluar tina N cukup pikeun pulih, sareng ieu tiasa janten bagian M. Upami dina ramo, teras gaduh grafik fungsi anu teu dipikanyaho, pamilon tukeur titik dina grafik, sareng saatos nampi titik M, sadaya fungsi tiasa dibalikeun deui.
Penjelasan anu saé dipasihkeun dina wiki tapi maén kalawan eta praktis dina urutan maén protokol dina sirah anjeun mangpaat pikeun demo kaca.

Lamun FSSS (Fiat-Shamir Secret Sharing) skéma éta lumaku dina formulir murni, éta bakal jadi hiji PVRB indestructible. Dina bentuk pangbasajanna, protokol tiasa katingali sapertos kieu:

• Unggal pamilon ngahasilkeun acak sorangan jeung ngadistribusikaeun biasa ti eta ka pamilon séjén
• Unggal pamilon ngungkabkeun bagian na tina rusiah pamilon séjén
• Upami pamilon ngagaduhan langkung ti saham M, maka jumlah pamilon ieu tiasa diitung, sareng éta bakal unik, henteu paduli set pamilon anu diungkabkeun.
• Kombinasi randoms wangsit teh PVRB dipikahoyong

Di dieu, hiji pamilon individu euweuh pangaruh hasil tina protokol, iwal dina kasus dimana ngahontal bangbarung panyingkepan randomness gumantung solely on anjeunna. Ku alatan éta, protokol ieu, lamun aya saimbang diperlukeun RPs dipake dina protokol jeung sadia, jalan, ngalaksanakeun sarat pikeun kakuatan cryptographic, sarta jadi tahan ka masalah "aktor panungtungan".

Ieu bisa jadi hiji pilihan idéal, skéma PVRB ieu dumasar kana Fiat-Shamir babagi rusiah digambarkeun contona dina ieu artikel. Tapi, sakumaha anu disebatkeun di luhur, upami anjeun nyobian nerapkeun éta dina blockchain, watesan téknis muncul. Ieu conto palaksanaan uji protokol dina kontrak pinter EOS sareng bagian anu paling penting - mariksa pamilon dibagikeun anu diterbitkeun: di. Anjeun tiasa ningali tina kode yén validasi buktina merlukeun sababaraha multiplications skalar, jeung angka nu dipaké pisan badag. Perlu dipikaharti yén dina blockchains, verifikasi lumangsung dina momen nalika block-produser prosés urus, sarta sacara umum, sagala pamilon kudu gampang pariksa correctness tina protokol, jadi sarat pikeun speed fungsi verifikasi pisan serius. . Dina pilihan ieu, pilihan tétéla teu epektip, saprak verifikasi teu pas dina wates urus (0.5 detik).

Efisiensi verifikasi mangrupikeun salah sahiji syarat anu paling penting pikeun dianggo, sacara umum, sagala skéma kriptografi canggih dina blockchain. Nyiptakeun bukti, nyiapkeun pesen - prosedur ieu tiasa dicabut ranté sareng dilaksanakeun dina komputer berprestasi tinggi, tapi verifikasi henteu tiasa dileungitkeun - ieu mangrupikeun sarat penting anu sanés pikeun PVRB.

PVRB jeung tanda tangan bangbarung

Sanggeus jadi acquainted jeung skéma babagi rusiah, urang manggihan sakabeh kelas protokol dihijikeun ku kecap konci "ambang". Nalika panyingkepan sababaraha émbaran merlukeun partisipasi M pamilon jujur ​​kaluar N, sarta susunan pamilon jujur ​​bisa mangrupa sawaréh sawenang tina N, urang nyarita ngeunaan "bangbarung" schemes. Éta aranjeunna anu ngamungkinkeun urang pikeun nungkulan "aktor panungtungan" masalah, ayeuna lamun panyerang teu nembongkeun bagian na rusiah, nu sejen, pamilon jujur ​​bakal ngalakukeun eta pikeun anjeunna. Skéma ieu ngamungkinkeun kasapukan dina hiji-hijina harti, sanajan protokol disabotase ku sababaraha pamilon.

Kombinasi tanda tangan deterministik sareng skéma bangbarung ngamungkinkeun pikeun ngembangkeun skéma anu saé pisan sareng ngajangjikeun pikeun ngalaksanakeun PVRB - ieu mangrupikeun tanda tangan ambang deterministik. Ieuh artikel ngeunaan rupa-rupa kagunaan tanda tangan bangbarung, sareng ieu mangrupikeun anu saé panjang dibaca ti Dash.

Tulisan terakhir ngajelaskeun tanda tangan BLS (BLS nangtung pikeun Boneh-Lynn-Shacham, di dieu artikel), nu boga kualitas pohara penting sarta pohara merenah pikeun programer - publik, rusiah, konci publik jeung tanda tangan BLS bisa digabungkeun saling ngagunakeun operasi matematik basajan, bari kombinasi maranéhanana tetep konci valid tur tanda tangan, sahingga anjeun gampang agrégat loba. tanda tangan kana hiji jeung loba konci publik kana hiji. Éta ogé deterministik sareng ngahasilkeun hasil anu sami pikeun data input anu sami. Hatur nuhun kana kualitas ieu, kombinasi tanda tangan BLS mangrupikeun konci anu sah, anu ngamungkinkeun palaksanaan pilihan dimana peserta M tina N ngahasilkeun hiji-hijina tanda tangan anu deterministik, tiasa diverifikasi sacara umum, sareng teu tiasa diprediksi dugi ka dibuka ku Mth. pamilon.

Dina skéma kalayan tanda tangan BLS bangbarung, unggal pamilon nandatanganan hiji hal nganggo BLS (contona, acak saméméhna), sareng tanda tangan bangbarung umum nyaéta acak anu dipikahoyong. Sipat kriptografi tina tanda tangan BLS nyugemakeun sarat pikeun kualitas acak, bagian bangbarung ngajaga ngalawan "aktor panungtungan", sarta combinability unik tina konci ngamungkinkeun pikeun nerapkeun loba algoritma leuwih metot nu ngidinan, contona, aggregation efisien pesen protokol. .

Janten, upami anjeun ngawangun PVRB dina blockchain anjeun, anjeun paling dipikaresep bakal ngeureunkeun skéma tanda tangan bangbarung BLS, sababaraha proyék parantos nganggo éta. Contona, DFinity (di dieu patokan nu implements sirkuit, jeung di dieu conto palaksanaan babagi rusiah verifiable), atawa Keep.network (di dieu nyaeta lantera acak maranéhna kertas konéngsareng di dieu conto kontrak pinter ngalayanan protokol).

Palaksanaan PVRB

Hanjakal, urang masih teu ningali hiji protokol siap-dijieun dilaksanakeun dina blockchains PVRB nu geus kabuktian kaamanan sarta stabilitas na. Sanaos protokolna parantos siap, sacara téknis nerapkeunana kana solusi anu tos aya henteu gampang. Pikeun sistem terpusat, PVRB teu asup akal, sareng anu desentralisasi diwatesan sacara ketat dina sadaya sumber komputasi: CPU, mémori, neundeun, I / O. Ngarancang hiji PVRB mangrupakeun kombinasi protokol béda dina urutan nyieun hiji hal anu meets sagala sarat pikeun sahenteuna sababaraha blockchain giat. Hiji protokol ngitung leuwih éfisién, tapi merlukeun leuwih seratan antara RPs, sedengkeun lianna merlukeun saeutik pisan seratan, tapi nyieun bukti bisa jadi tugas nu butuh puluhan menit, atawa malah jam.

Kuring bakal daptar faktor anu anjeun kedah pertimbangkeun nalika milih PVRB kualitas:

• Kakuatan kriptografi. PVRB anjeun kedah leres-leres teu biasa, sareng teu aya kamampuan pikeun ngontrol sakedik. Dina sababaraha skéma ieu sanés masalahna, janten nyauran cryptographer
• Masalah "aktor panungtungan".. PVRB anjeun kedah tahan kana serangan dimana panyerang anu ngatur hiji atanapi langkung RP tiasa milih salah sahiji tina dua hasil.
• Masalah sabotase protokol. PVRB anjeun kedah tahan kana serangan dimana panyerang anu ngatur hiji atanapi langkung RP mutuskeun naha acak atanapi henteu sareng tiasa dijamin atanapi kalayan kamungkinan anu dipasihkeun pikeun mangaruhan ieu.
• Jumlah pesen masalah. RPs anjeun kedah ngirim pesen minimal ka blockchain sareng nyingkahan tindakan sinkron sabisa-bisa sapertos kaayaan sapertos "Kuring ngirim sababaraha inpormasi, kuring ngantosan réspon ti pamilon khusus." Dina jaringan p2p, khususna anu sumebar sacara geografis, anjeun henteu kedah ngandelkeun réspon anu gancang
• Masalah pajeulitna komputasi. Verifikasi tina sagala tahapan PVRB on-chain kedah pisan gampang, saprak éta dipigawé ku sakabeh klien pinuh jaringan. Upami palaksanaanna dilakukeun nganggo kontrak pinter, maka syarat lajuna ketat pisan
• Masalah aksesibilitas sareng liveness. PVRB anjeun kedah narékahan pikeun tahan kana kaayaan dimana bagian tina jaringan henteu sayogi pikeun sababaraha waktos sareng bagian tina RP ngan saukur lirén damel.
• Masalah pangaturan dipercaya sareng distribusi konci awal. Upami PVRB anjeun nganggo pangaturan primér protokol, maka ieu mangrupikeun carita anu ageung sareng serius. Ieuh conto. Upami pamilon kedah nyarioskeun konci masing-masing sateuacan ngamimitian protokol, ieu ogé janten masalah upami komposisi pamilon robih
• Masalah pangwangunan. Kasadiaan perpustakaan dina basa diperlukeun, kaamanan sarta kinerja maranéhanana, publisitas, tés kompléks, jsb.

Contona, tanda tangan BLS bangbarung gaduh masalah anu signifikan - sateuacan ngamimitian damel, pamilon kedah ngadistribusikaeun konci ka unggal anu sanés, ngatur grup dimana ambangna bakal jalan. Ieu ngandung harti yén sahenteuna hiji babak bursa dina jaringan desentralisasi kudu antosan, sarta nunjukkeun yen rand dihasilkeun, contona, diperlukeun dina kaulinan, ampir sacara real waktu, ieu ngandung harti yén sabotase tina protokol mungkin dina tahap ieu. , sarta kaunggulan tina skéma bangbarung leungit. Masalah ieu parantos langkung saderhana tibatan anu sateuacana, tapi tetep peryogi pamekaran prosedur anu misah pikeun pembentukan kelompok ambang, anu kedah dijagi sacara ékonomis, ngalangkungan deposit sareng ditarikna dana (slashing) ti pamilon anu henteu nuturkeun aturan. protokol. Ogé, verifikasi BLS kalayan tingkat kaamanan anu ditampi ngan saukur teu cocog, contona, kana transaksi EOS atanapi Ethereum standar - ngan saukur teu cekap waktos pikeun verifikasi. Kode kontrak nyaéta WebAssembly atanapi EVM, dieksekusi ku mesin virtual. Fungsi kriptografi henteu dilaksanakeun sacara asli (acan), sareng dianggo puluhan kali langkung laun tibatan perpustakaan kriptografi konvensional. Loba protokol teu minuhan sarat saukur dumasar kana volume konci, contona 1024 jeung 2048 bit pikeun RSA, 4-8 kali leuwih badag batan signature urus baku dina Bitcoin na Ethereum.

Ayana palaksanaan dina basa program anu béda ogé maénkeun peran - anu aya sababaraha, khususna pikeun protokol anyar. Pilihan kalayan integrasi kana konsensus merlukeun nulis protokol dina basa platform, jadi Anjeun kudu néangan kode dina Go for geth, dina Rust pikeun Parity, dina C ++ pikeun EOS. Sarerea kedah milarian kode JavaScript, sareng saprak JavaScript sareng kriptografi henteu janten babaturan anu caket, WebAssembly bakal ngabantosan, anu ayeuna pasti ngaku janten standar Internét anu penting.

kacindekan

Kuring miharep dina saméméhna artikel Kuring junun ngayakinkeun yén ngahasilkeun angka acak dina blockchain mangrupa kritik pikeun loba aspék kahirupan jaringan desentralisasi, sarta kalawan artikel ieu kuring némbongkeun yén tugas ieu pisan ambisius jeung hésé, tapi solusi alus geus aya. Sacara umum, desain ahir protokol ngan ukur tiasa dilakukeun saatos ngalaksanakeun tés masif anu tumut kana sagala aspek ti setup ka emulation lepat, ku kituna anjeun saperti teu mirip manggihan resep siap-dijieun dina whitepaper tim jeung artikel, sarta kami pasti moal. mutuskeun dina atawa dua taun hareup nulis "ngalakukeun cara kieu, persis katuhu."

Aduh, pikeun PVRB kami dina blockchain anu dikembangkeun Haya, urang netep dina ngagunakeun tanda tangan BLS bangbarung, urang rencanana pikeun nerapkeun PVRB di tingkat konsensus, saprak verifikasi dina kontrak pinter jeung tingkat ditarima kaamanan teu acan mungkin. Ieu mungkin nu urang ngagunakeun dua skéma sakaligus: kahiji, babagi rusiah mahal pikeun nyieun jangka panjang random_seed, lajeng urang ngagunakeun eta salaku dadasar pikeun frékuénsi luhur generasi acak ngagunakeun bangbarung deterministik tanda tangan BLS, sugan we bakal ngawatesan diri urang ngan ukur. salah sahiji skéma. Hanjakalna, teu mungkin pikeun nyarios sateuacanna naon protokolna; hiji-hijina hal anu saé nyaéta, sapertos dina élmu, dina masalah rékayasa, hasil négatip ogé hasilna, sareng unggal usaha anyar pikeun ngabéréskeun masalah mangrupikeun léngkah anu sanés. panalungtikan sarerea kalibet dina masalah. Pikeun minuhan sarat bisnis, urang ngajawab masalah praktis husus - nyadiakeun aplikasi kaulinan kalayan sumber dipercaya tina éntropi, jadi urang ogé kudu nengetan blockchain sorangan, hususna isu finality ranté sarta governance jaringan.

Sarta sanajan urang teu acan ningali hiji PVRB tahan kabuktian di blockchains, nu bakal geus dipaké pikeun cukup waktu pikeun diuji ku aplikasi nyata, sababaraha audits, beban, sarta tangtu, serangan nyata, tapi jumlah jalur mungkin confirms yén solusi aya, sarta naon -of algoritma ieu antukna bakal ngajawab masalah. Kami bakal bagja pikeun ngabagi hasil sareng hatur nuhun ka tim sanés anu ogé damel dina masalah ieu pikeun tulisan sareng kode anu ngamungkinkeun para insinyur henteu ngaléngkah rake anu sami dua kali.

Janten, nalika anjeun pendak sareng programer anu ngarancang acak terdesentralisasi, janten attentive sareng paduli, sareng nyayogikeun pitulung psikologis upami diperyogikeun :)

sumber: www.habr.com