Pambuka

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

Kaya konsep cipher sing kuat banget saka kriptografi, protokol "Beacon Acak sing Bisa Diverifikasi Umum" (sabanjure PVRB) mung nyoba nyedhaki skema sing cocog, amarga ing jaringan nyata iku ora ditrapake ing wangun murni: iku perlu kanggo setuju strictly ing siji dicokot, kudu akeh babak, lan kabeh pesen kudu sampurna cepet lan tansah dikirim. Mesthine, iki ora kedadeyan ing jaringan nyata. Mulane, nalika ngrancang PVRBs kanggo tugas tartamtu ing pamblokiran modern, saliyane mokal kanggo ngontrol acak lan kekuatan kriptografi sing diasilake, akeh masalah arsitektur lan teknis sing luwih murni.

Kanggo PVRB, pamblokiran dhewe minangka media komunikasi sing pesen = transaksi. Iki ngidini sampeyan sebagian abstrak saka masalah jaringan, ora ngirim pesen, masalah karo middleware - kabeh risiko iki dianggep dening jaringan desentralisasi, lan nilai utamane kanggo PVRB yaiku ora bisa mbatalake utawa ngrusak transaksi sing wis dikirim - iki ora ora ngidini peserta nolak kanggo melu ing protokol, kajaba padha nindakake serangan sukses ing konsensus. Tingkat keamanan iki bisa ditampa, mula PVRB kudu tahan kolusi dening peserta kanthi persis padha karo rantai pamblokiran utama. Uga, iki menehi pitunjuk yen PVRB kudu dadi bagian saka konsensus yen jaringan setuju karo pamblokiran utama, sanajan uga setuju mung kanthi acak asil adil. Utawa, PVRB mung minangka protokol mandiri sing dileksanakake dening kontrak cerdas sing kerjane ora sinkron babagan pamblokiran lan pamblokiran. Kaloro cara kasebut duwe kaluwihan lan kekurangan, lan pilihan ing antarane ora pati penting.

Rong cara kanggo ngetrapake PVRB

Ayo kita njlèntrèhaké kanthi luwih rinci rong opsi kanggo ngleksanakake PVRB - versi mandiri, sing bisa digunakake kanthi nggunakake kontrak cerdas bebas saka pamblokiran, lan versi terintegrasi konsensus, dibangun ing protokol, miturut jaringan kasebut setuju karo pamblokiran lan transaksi kanggo kalebu. Ing kabeh kasus, aku bakal tegese mesin pamblokiran populer: Ethereum, EOS, lan kabeh sing padha karo cara sing dadi tuan rumah lan ngolah kontrak cerdas.

Kontrak mandiri

Ing versi iki, PVRB minangka kontrak pinter sing nampa transaksi saka produser acak (sabanjuré diarani RP), ngolah, nggabungake asil, lan, minangka asil, teka ing nilai tartamtu sing bisa ditampa dening pangguna saka kontrak iki. Nilai iki bisa uga ora disimpen langsung ing kontrak, nanging mung diwakili dening data saka kang siji lan mung siji nilai acak asil bisa deterministically dijupuk. Ing skema iki, RP minangka pangguna pamblokiran, lan sapa wae bisa diijini melu proses generasi.

Opsi kanthi kontrak mandiri apik:

• portabilitas (kontrak bisa diseret saka blockchain menyang blockchain)
• gampang implementasine lan tes (kontrak gampang ditulis lan diuji)
• penak kanggo ngleksanakake skema ekonomi (gampang nggawe token dhewe, sing logikane kanggo tujuan PVRB)
• kamungkinan diluncurake ing blockchain sing wis digunakake

Uga duwe kekurangan:

• watesan kuwat ing sumber daya komputasi, volume transaksi lan panyimpenan (kanthi tembung liya, cpu/mem/io)
• Watesan operasi ing kontrak (ora kabeh instruksi kasedhiya, angel nyambungake perpustakaan eksternal)
• ora bisa ngatur olahpesen luwih cepet tinimbang transaksi sing kalebu ing pamblokiran

Opsi iki cocok kanggo ngetrapake PVRB sing kudu ditindakake ing jaringan sing wis ana, ora ngemot kriptografi kompleks lan ora mbutuhake interaksi sing akeh.

Konsensus-integrated

Ing versi iki, PVRB dileksanakake ing kode simpul pamblokiran, dibangun ing utawa mlaku bebarengan karo ijol-ijolan pesen antarane simpul pamblokiran. Asil saka protokol ditulis langsung menyang pamblokiran diprodhuksi, lan pesen protokol dikirim liwat jaringan p2p antarane kelenjar. Wiwit protokol kasebut ngasilake angka sing bakal ditulis ing blok, jaringan kudu entuk konsensus babagan kasebut. Iki tegese pesen PVRB, kaya transaksi, kudu divalidasi dening simpul lan dilebokake ing blok supaya peserta jaringan bisa ngesyahke kepatuhan karo protokol PVRB. Iki kanthi otomatis nuntun kita menyang solusi sing jelas - yen jaringan setuju karo konsensus babagan blok lan transaksi kasebut, mula PVRB kudu dadi bagian saka konsensus, lan dudu protokol sing mandiri. Yen ora, bisa uga pamblokiran bener saka sudut pandang konsensus, nanging protokol PVRB ora dituruti, lan saka sudut pandang PVRB, blok kasebut ora bisa ditampa. Dadi yen opsi "consensus-integrated" dipilih, PVRB dadi bagean penting saka konsensus.

Nalika njlentrehake implementasi PVRB ing tingkat konsensus jaringan, siji ora bisa ngindhari masalah finalitas. Finalitas minangka mekanisme sing digunakake ing konsensus deterministik sing ngunci blok (lan rantai sing mimpin menyang) sing pungkasan lan ora bakal dibuwang, sanajan ana garpu paralel. Contone, ing Bitcoin ora ana mekanisme kasebut - yen sampeyan nerbitake rantai kerumitan sing luwih gedhe, bakal ngganti sing kurang kompleks, preduli saka dawa rantai kasebut. Lan ing EOS, contone, sing pungkasan yaiku sing diarani Pamblokiran Irreversible Terakhir, sing katon rata-rata saben 432 blok (12*21 + 12*15, pre-vote + pre-commit). Proses iki ateges ngenteni 2/3 saka blok-produser (sabanjuré diarani minangka BP) teken. Nalika garpu katon luwih lawas tinimbang LIB pungkasan, mung dibuwang. Mekanisme iki ndadekake bisa njamin yen transaksi kasebut kalebu ing pamblokiran lan ora bakal digulung maneh, ora ketompo apa wae sumber daya sing diduweni penyerang. Uga, pamblokiran pungkasan minangka blok sing ditandatangani dening 2/3 BP ing Hyperledger, Tendermint lan konsensus adhedhasar pBFT liyane. Kajaba iku, penting kanggo nggawe protokol kanggo mesthekake finalitas minangka tambahan kanggo konsensus, amarga bisa uga ora sinkron karo produksi lan publikasi blok. Iki sing apik artikel babagan finality ing Ethereum.

Finalitas penting banget kanggo pangguna, sing tanpa bisa uga dadi korban serangan "ganda", ing ngendi BP "nyepeng" pamblokiran, lan nerbitake sawise jaringan wis "ndeleng" transaksi sing apik. Yen ora ana finalitas, banjur garpu sing diterbitake ngganti blok kasebut kanthi transaksi "apik" karo liyane, saka garpu "ala", ing ngendi dana sing padha ditransfer menyang alamat penyerang. Ing kasus PVRB, syarat finalitas luwih ketat, amarga nggawe garpu kanggo PVRB tegese kesempatan kanggo panyerang nyiyapake sawetara opsi acak kanggo nerbitake sing paling nguntungake, lan mbatesi wektu serangan sing bisa ditindakake yaiku solusi apik.

Mulane, pilihan sing paling apik kanggo gabungke PVRB lan finality dadi siji protokol - banjur blok finalized = dirampungaké acak, lan iki persis apa kita needed kanggo njaluk. Saiki pemain bakal nampa acak dijamin ing N detik, lan bisa manawa iku mokal kanggo muter maneh utawa muter maneh.

Opsi terintegrasi konsensus apik:

• kamungkinan implementasine bedo ing hubungane karo produksi pamblokiran - pamblokiran diprodhuksi kaya biasanipun, nanging ing podo karo iki, protokol PVRB bisa digunakake, kang ora gawé acak kanggo saben blok.
• kemampuan kanggo ngleksanakake malah kriptografi abot, tanpa watesan dileksanakake ing kontrak pinter
• kemampuan kanggo ngatur ijol-ijolan pesen luwih cepet tinimbang transaksi kalebu ing blockchain, contone, bagean saka protokol bisa digunakake ing antarane simpul tanpa nyebarake pesen liwat jaringan.

Uga duwe kekurangan:

• Kesulitan ing tes lan pangembangan - sampeyan kudu niru kesalahan jaringan, node sing ilang, garpu hard jaringan
• Kesalahan implementasine mbutuhake hardfork jaringan

Loro-lorone cara ngleksanakake PVRB duwe hak kanggo urip, nanging implementasine ing kontrak cerdas ing pamblokiran modern isih cukup winates ing sumber daya komputasi, lan transisi menyang kriptografi serius asring mung ora mungkin. Lan kita butuh kriptografi sing serius, kaya sing bakal dituduhake ing ngisor iki. Senajan masalah iki cetha sak wentoro, kriptografi serius ing kontrak dibutuhake kanggo ngatasi akeh masalah, lan mboko sithik katon (contone, kontrak sistem kanggo zkSNARKs ing Ethereum)

Blockchain, sing nyedhiyakake saluran olahpesen protokol sing transparan lan dipercaya, ora nindakake kanthi gratis. Sembarang protokol desentralisasi kudu nyathet kemungkinan serangan Sybil; tindakan apa wae bisa ditindakake dening pasukan gabungan saka pirang-pirang akun, mulane, nalika ngrancang, perlu nganggep kemampuan panyerang kanggo nggawe nomer protokol sing sewenang-wenang. peserta tumindak ing collusion.

PVRB lan variabel pamblokiran.

Aku ora ngapusi nalika aku ngomong sing durung ana siji wis dipun ginakaken PVRB apik, dites dening akeh aplikasi gambling, ing blockchains. Endi banjur akeh aplikasi gambling teka saka Ethereum lan EOS? Iki surprises kula minangka akeh minangka surprises sampeyan, ngendi padha njaluk supaya akeh "terus-terusan" acak ing lingkungan rampung deterministik?

Cara sing paling disenengi kanggo entuk acak ing pamblokiran yaiku njupuk informasi "ora bisa ditebak" saka blok kasebut lan nggawe acak adhedhasar - mung kanthi hashing siji utawa luwih nilai. Artikel sing apik babagan masalah skema kasebut kene. Sampeyan bisa njupuk salah sawijining nilai "ora bisa ditebak" ing blok kasebut, contone, hash blok, jumlah transaksi, kerumitan jaringan, lan nilai liyane sing ora dingerteni sadurunge. Banjur hash mau, siji utawa luwih, lan, ing teori, sampeyan kudu njaluk acak nyata. Sampeyan bisa uga nambahake menyang whitipaper manawa skema sampeyan "aman pasca-kuantum" (amarga ana fungsi hash kuantum-bukti :)).

Nanging malah hash aman pasca-kuantum ora cukup, sayange. Rahasia kasebut ana ing syarat-syarat kanggo PVRB, supaya aku ngelingake sampeyan saka artikel sadurunge:

1. Asil kasebut kudu duwe distribusi sing seragam, yaiku adhedhasar kriptografi sing kuwat.
2. Iku ora bisa kanggo ngontrol samubarang bit saka asil. Akibaté, asil ora bisa diprediksi sadurunge.
3. Sampeyan ora bisa sabotase protokol generasi kanthi ora melu protokol utawa kanthi overloading jaringan kanthi pesen serangan
4. Kabeh kasebut ing ndhuwur kudu tahan kanggo kolusi saka jumlah peserta protokol sing ora jujur ​​(contone, 1/3 saka peserta).

Ing kasus iki, mung requirement 1 ketemu, lan syarat 2 ora ketemu. Kanthi hashing nilai ranyono saka blok, kita bakal entuk distribusi seragam lan acak apik. Nanging BP paling ora duwe pilihan kanggo "nerbitake blok kasebut utawa ora." Mangkono, BP paling ora bisa milih saka TWO opsi acak: "dhewe" lan siji sing bakal metu yen wong liya nggawe pemblokiran. BP bisa "snoop" ing advance apa sing bakal kelakon yen nerbitaké pemblokiran, lan mung arep nindakake utawa ora. Mangkono, nalika muter, contone, "malah-aneh" utawa "abang / ireng "ing roulette, kang bisa nerbitaké pemblokiran mung yen ndeleng menang . Iki uga nggawe strategi nggunakake, umpamane, blok hash "saka mangsa ngarep" ora bisa ditindakake. Ing kasus iki, dheweke ujar manawa "acak bakal digunakake, sing diduweni kanthi hashing data saiki lan hash saka blok mangsa kanthi dhuwur, contone, N + 42, ing ngendi N minangka dhuwur blok saiki. Iki nguatake skema kasebut, nanging isih ngidini BP, sanajan ing mangsa ngarep, milih arep nyekel blok kasebut utawa nerbitake.

Piranti lunak BP ing kasus iki dadi luwih rumit, nanging ora akeh. Cukup, nalika validasi lan kalebu transaksi ing pemblokiran, ana mriksa cepet kanggo ndeleng yen bakal menang, lan, bisa, pilihan saka siji paramèter transaksi diwenehi kemungkinan dhuwur saka menang. Ing wektu sing padha, meh ora bisa nyekel BP sing cerdas kanggo manipulasi kasebut, saben-saben sampeyan bisa nggunakake alamat anyar lan menang sithik-sithik tanpa nyebabake rasa curiga.

Dadi cara nggunakake informasi saka blok ora cocok minangka implementasi universal saka PVRB. Ing versi winates, karo Watesan ing ukuran nang, Watesan ing nomer pemain lan / utawa registrasi KYC (kanggo nyegah siji pemain saka nggunakake sawetara alamat), rencana iki bisa kanggo game cilik, nanging ora luwih.

PVRB lan tundhuk-ngungkapake.

Oke, thanks kanggo hashing lan paling ora bisa diprediksi relatif saka hash blok lan variabel liyane. Yen sampeyan ngatasi masalah penambang ngarep, sampeyan kudu entuk sing luwih cocog. Ayo nambah pangguna menyang skema iki - supaya wong-wong mau uga mengaruhi randomness: karyawan dhukungan teknis bakal ngandhani yen sing paling acak ing sistem IT yaiku tumindak pangguna :)

Skema naif, nalika pangguna mung ngirim nomer acak lan asil diitung minangka, contone, hash saka jumlahe, ora cocok. Ing kasus iki, pemain pungkasan bisa, kanthi milih acak dhewe, ngontrol apa asil bakal. Mulane pola commit-reveal sing digunakake banget digunakake. Peserta pisanan ngirim hash saka randoms sing (komit), lan banjur mbukak acak dhewe (ngumumke). Fase "ngungkapake" diwiwiti mung sawise komit sing dibutuhake wis diklumpukake, supaya peserta bisa ngirim persis hash acak sing dikirim sadurunge. Saiki ayo sijine kabeh iki bebarengan karo paramèter saka pamblokiran, lan luwih apik saka siji dijupuk saka mangsa (randomness mung bisa ditemokaké ing salah siji saka pamblokiran mangsa), lan voila - randomness siap! Saiki sembarang pemain pengaruh acak asil, lan bisa "ngalahake" BP angkoro dening overriding karo dhewe, dingerteni ing advance, randomness ... Sampeyan uga bisa nambah pangayoman marang sabotaging protokol dening ora mbukak ing tataran mbukak - mung kanthi mbutuhake jumlah tartamtu kanggo ditempelake ing transaksi nalika nindakake - simpenan keamanan, kang bakal bali mung sak prosedur mbukak. Ing kasus iki, nglakoni lan ora mbukak bakal ora nguntungake.

Iki minangka upaya sing apik, lan skema kasebut uga ana ing DApps game, nanging sayang, iki ora cukup maneh. Saiki ora mung penambang, nanging uga peserta ing protokol bisa mengaruhi asil. Sampeyan isih bisa ngontrol nilai kasebut dhewe, kanthi variasi sing kurang lan kanthi biaya, nanging, kaya ing kasus penambang, yen asil gambar luwih larang tinimbang biaya kanggo partisipasi ing protokol PVRB, banjur acak. -produser (RP) bisa mutusaké apa bakal mbukak lan isih bisa milih saka ing paling rong opsi acak.
Nanging bisa ngukum wong-wong sing nglakoni lan ora mbukak, lan rencana iki bakal migunani. Kesederhanaan minangka kauntungan serius - protokol sing luwih serius mbutuhake petungan sing luwih kuat.

PVRB lan teken deterministik.

Ana cara liya kanggo meksa RP kanggo nyedhiyani nomer pseudo-acak sing ora bisa pengaruhe yen diwenehake karo "preimage" - iki teken deterministik. Tandha kasebut, contone, RSA, lan dudu ECS. Yen RP duwe sepasang kunci: RSA lan ECC, lan dheweke menehi tandha nilai tartamtu nganggo kunci pribadine, mula ing kasus RSA dheweke bakal entuk tandha siji lan siji, lan ing kasus ECS, dheweke bisa ngasilake nomer apa wae. teken beda sah. Iki amarga nalika nggawe tandha ECS, nomer acak digunakake, dipilih dening signer, lan bisa milih ing sembarang cara, menehi tandha kesempatan kanggo milih salah siji saka sawetara teken. Ing kasus RSA: "siji nilai input" + "siji pasangan kunci" = "siji teken". Sampeyan ora bisa prédhiksi apa teken RP liyane bakal entuk, supaya PVRB kanthi teken deterministik bisa diatur kanthi nggabungake teken RSA saka sawetara peserta sing mlebu nilai sing padha. Contone, acak sadurungé. Skema iki nyimpen akeh sumber daya, amarga teken iku loro konfirmasi prilaku bener miturut protokol lan sumber randomness.

Nanging, sanajan kanthi teken deterministik, skema kasebut isih rentan kanggo masalah "aktor pungkasan". Peserta pungkasan isih bisa mutusake arep nerbitake teken utawa ora, saengga bisa ngontrol asil kasebut. Sampeyan bisa ngowahi skema kasebut, nambah hashes blok kasebut, nggawe babak supaya asil ora bisa diprediksi sadurunge, nanging kabeh teknik kasebut, sanajan akeh modifikasi, isih tetep ora ngrampungake masalah pengaruh siji peserta ing kolektif. nyebabake lingkungan sing ora dipercaya lan mung bisa digunakake ing watesan ekonomi lan wektu. Kajaba iku, ukuran tombol RSA (1024 lan 2048 bit) cukup gedhe, lan ukuran kanggo transaksi blockchain minangka parameter sing penting banget. Ketoke ora ana cara sing gampang kanggo ngatasi masalah kasebut, ayo nerusake.

PVRB lan rencana enggo bareng rahasia

Ing kriptografi, ana skema sing bisa ngidini jaringan setuju karo siji lan mung siji nilai PVRB, dene skema kasebut tahan kanggo tumindak ala saka sawetara peserta. Salah sawijining protokol migunani sing kudu dingerteni yaiku skema sharing rahasia Shamir. Iku serves kanggo dibagi rahasia (contone, kunci rahasia) menyang sawetara bagéan, lan disebaraké bagean iki kanggo N peserta. Rahasia kasebut disebarake supaya bagean M saka N cukup kanggo mbalekake, lan iki bisa dadi bagean M. Yen nganggo driji, banjur duwe grafik fungsi sing ora dingerteni, para peserta ngganti poin ing grafik kasebut, lan sawise nampa poin M, kabeh fungsi bisa dibalekake.
Panjelasan sing apik diwenehake ing wiki nanging muter karo prakteke kanggo muter protokol ing sirah migunani kanggo Tur kaca.

Yen skema FSSS (Fiat-Shamir Secret Sharing) ditrapake ing wangun murni, iku bakal dadi PVRB sing ora bisa dirusak. Ing wangun sing paling gampang, protokol bisa katon kaya iki:

• Saben peserta ngasilake acak dhewe lan nyebarake saham kasebut menyang peserta liyane
• Saben peserta mbukak bagean rahasia saka peserta liyane
• Yen peserta duwe luwih saka M Enggo bareng, banjur nomer peserta iki bisa diwilang, lan bakal unik, preduli saka set peserta dicethakaké ana.
• Kombinasi randoms dicethakaké ana PVRB dikarepake

Ing kene, peserta individu ora ana maneh pengaruhe asil protokol, kajaba ing kasus-kasus ing ngendi prestasi ambang pambocoran randomness mung gumantung marang dheweke. Mulane, protokol iki, yen ana proporsi sing dibutuhake saka RP sing digunakake ing protokol lan kasedhiya, bisa digunakake, ngleksanakake syarat kanggo kekuatan kriptografi, lan tahan kanggo masalah "aktor pungkasan".

Iki bisa dadi pilihan becik, iki skema PVRB adhedhasar Fiat-Shamir rahasia sharing diterangake contone ing iki artikel. Nanging, kaya sing kasebut ing ndhuwur, yen sampeyan nyoba ngetrapake ing blockchain, watesan teknis katon. Iki minangka conto implementasi tes protokol ing kontrak cerdas EOS lan bagean sing paling penting - mriksa peserta saham sing diterbitake: kode. Sampeyan bisa ndeleng saka kode sing validasi bukti mbutuhake sawetara multiplications skalar, lan nomer digunakake gedhe banget. Perlu dimangerteni manawa ing blokchain, verifikasi kedadeyan nalika pamblokiran-produser ngolah transaksi kasebut, lan umume, peserta apa wae kudu gampang verifikasi kebeneran protokol kasebut, saengga syarat kanggo kacepetan fungsi verifikasi kasebut serius banget. . Ing pilihan iki, pilihan kasebut ora efektif, amarga verifikasi ora cocog karo watesan transaksi (0.5 detik).

Efisiensi verifikasi minangka salah sawijining syarat sing paling penting kanggo nggunakake, umume, skema kriptografi canggih ing pamblokiran. Nggawe bukti, nyiapake pesen - prosedur kasebut bisa dicopot lan ditindakake ing komputer kanthi kinerja dhuwur, nanging verifikasi ora bisa dilewati - iki minangka syarat penting liyane kanggo PVRB.

PVRB lan teken ambang

Sawise kenal karo skema enggo bareng rahasia, kita nemokake kabeh kelas protokol sing digabung karo tembung kunci "ambang". Nalika pambocoran sawetara informasi mbutuhake partisipasi peserta jujur ​​M metu saka N, lan pesawat saka peserta jujur ​​bisa dadi subset kasepakatan saka N, kita ngomong bab "ambang" rencana. Dheweke ngidini kita ngatasi masalah "aktor pungkasan", saiki yen panyerang ora mbukak bagean rahasia kasebut, peserta liyane sing jujur ​​bakal nindakake kanggo dheweke. Skema kasebut ngidini persetujuan babagan siji lan mung siji makna, sanajan protokol kasebut disabotase dening sawetara peserta.

Kombinasi teken deterministik lan skema ambang bisa nggawe skema sing trep lan janjeni kanggo ngetrapake PVRB - iki minangka tandha ambang deterministik. kene artikel babagan macem-macem nggunakake teken ambang, lan iki siji liyane apik dawa diwaca saka Dash.

Artikel pungkasan nggambarake tanda tangan BLS (BLS singkatan saka Boneh-Lynn-Shacham, lah artikel), sing nduweni kualitas sing penting lan trep banget kanggo programer - umum, rahasia, kunci umum lan tanda tangan BLS bisa digabungake karo siji liyane kanthi nggunakake operasi matematika sing prasaja, dene kombinasi kasebut tetep tombol lan teken sing bener, ngidini sampeyan kanthi gampang nglumpukake akeh. teken dadi siji lan akeh kunci umum dadi siji. Dheweke uga deterministik lan ngasilake asil sing padha kanggo data input sing padha. Thanks kanggo kualitas iki, kombinasi teken BLS minangka kunci sing bener, sing ngidini kanggo ngetrapake pilihan ing peserta M saka N ngasilake siji lan mung siji teken sing deterministik, bisa diverifikasi publik, lan ora bisa ditebak nganti dibukak dening Mth. peserta .

Ing skema kanthi teken BLS batesan, saben peserta menehi tandha soko nggunakake BLS (contone, acak sadurunge), lan tandha ambang umum minangka acak sing dikarepake. Properti kriptografi saka tandha BLS nyukupi syarat kanggo kualitas acak, bagean ambang nglindhungi "aktor pungkasan", lan kombinasi tombol sing unik ndadekake akeh algoritma sing luwih menarik sing ngidini, contone, agregasi pesen protokol sing efisien. .

Dadi, yen sampeyan mbangun PVRB ing pamblokiran sampeyan, sampeyan bakal entuk skema tandha ambang BLS, sawetara proyek wis nggunakake. Contone, DFinity (kene pathokan sing ngleksanakake sirkuit, lan kene conto implementasi enggo bareng rahasia sing bisa diverifikasi), utawa Keep.network (kene suar acak kertas kuninglan kene conto kontrak pinter nglayani protokol).

Implementasi PVRB

Sayange, kita isih ora weruh protokol sing wis siap dileksanakake ing blockchains PVRB sing wis mbuktekake keamanan lan stabilitas. Sanajan protokol kasebut wis siyap, kanthi teknis ngetrapake solusi sing wis ana ora gampang. Kanggo sistem terpusat, PVRB ora ana gunane, lan desentralisasi diwatesi kanthi ketat ing kabeh sumber daya komputasi: CPU, memori, panyimpenan, I / O. Ngrancang PVRB minangka kombinasi saka protokol sing beda-beda kanggo nggawe barang sing nyukupi kabeh syarat kanggo paling ora sawetara pamblokiran sing sregep. Siji protokol ngetung luwih irit, nanging mbutuhake pesen liyane antarane RPs, nalika liyane mbutuhake banget sawetara pesen, nanging nggawe bukti bisa dadi tugas sing njupuk puluhan menit, utawa malah jam.

Aku bakal dhaptar faktor sing kudu sampeyan pertimbangake nalika milih PVRB kualitas:

• Kekuwatan kriptografi. PVRB sampeyan kudu banget ora bisa digunakake, tanpa bisa ngontrol apa wae. Ing sawetara skema, iki ora kedadeyan, mula nelpon cryptographer
• Masalah "aktor pungkasan".. PVRB sampeyan kudu tahan serangan ing ngendi panyerang sing ngontrol siji utawa luwih RP bisa milih salah siji saka rong asil.
• Masalah sabotase protokol. PVRB sampeyan kudu tahan kanggo serangan ing ngendi panyerang sing ngontrol siji utawa luwih RP mutusake manawa bakal acak utawa ora lan bisa dijamin utawa kanthi kemungkinan tartamtu kanggo mengaruhi iki.
• Masalah nomer pesen. RP sampeyan kudu ngirim pesen minimal menyang blockchain lan ngindhari tumindak sing sinkron sabisa-bisa kayata kahanan kaya "Aku ngirim sawetara informasi, aku ngenteni respon saka peserta tartamtu." Ing jaringan p2p, utamane sing kasebar sacara geografis, sampeyan ora kudu nganggep respon cepet
• Masalah kerumitan komputasi. Verifikasi tahapan apa wae ing rantai PVRB kudu gampang banget, amarga ditindakake dening kabeh klien jaringan lengkap. Yen implementasine wis rampung nggunakake kontrak pinter, syarat kacepetan banget ketat
• Masalah aksesibilitas lan liveness. PVRB sampeyan kudu ngupayakake tahan kanggo kahanan nalika bagean saka jaringan dadi ora kasedhiya kanggo sawetara wektu lan bagean saka RP mung mandheg digunakake
• Masalah persiyapan dipercaya lan distribusi kunci wiwitan. Yen PVRB sampeyan nggunakake persiyapan utama protokol, mula iki minangka crita gedhe lan serius sing kapisah. kene conto. Yen peserta kudu ngandhani kunci saben liyane sadurunge miwiti protokol, iki uga dadi masalah yen komposisi peserta diganti
• Masalah pembangunan. Kasedhiya perpustakaan ing basa sing dibutuhake, keamanan lan kinerja, publisitas, tes kompleks, lsp.

Contone, teken BLS batesan duwe masalah sing signifikan - sadurunge miwiti kerja, para peserta kudu mbagekake kunci siji-sijine, ngatur klompok ing ambang kasebut. Iki tegese ing paling siji babak ijol-ijolan ing jaringan desentralisasi kudu ngenteni, lan diwenehi yen rand kui, contone, perlu ing game, meh ing wektu nyata, iki tegese sabotase saka protokol bisa ing tataran iki. , lan kaluwihan saka skema ambang wis ilang. Masalah iki wis luwih prasaja tinimbang sing sadurunge, nanging isih mbutuhake pangembangan prosedur sing kapisah kanggo pambentukan kelompok ambang, sing kudu direksa kanthi ekonomi, liwat simpenan lan penarikan dana (slashing) saka peserta sing ora ngetutake aturan kasebut. protokol. Uga, verifikasi BLS kanthi tingkat keamanan sing bisa ditampa mung ora cocog, umpamane, menyang transaksi EOS utawa Ethereum standar - mung ora cukup wektu kanggo verifikasi. Kode kontrak yaiku WebAssembly utawa EVM, dieksekusi dening mesin virtual. Fungsi kriptografi durung dileksanakake kanthi asli (durung), lan kerjane kaping puluhan luwih alon tinimbang perpustakaan kriptografi konvensional. Akeh protokol ora nyukupi syarat mung adhedhasar volume tombol, contone 1024 lan 2048 bit kanggo RSA, 4-8 kaping luwih gedhe tinimbang teken transaksi standar ing Bitcoin lan Ethereum.

Anane implementasi ing basa pamrograman sing beda-beda uga nduweni peran - sing ana sawetara, utamane kanggo protokol anyar. Opsi kanthi integrasi menyang konsensus mbutuhake nulis protokol ing basa platform, supaya sampeyan kudu nggoleki kode ing Go for geth, ing Rust for Parity, ing C ++ kanggo EOS. Saben uwong kudu nggoleki kode JavaScript, lan amarga JavaScript lan kriptografi ora dadi kanca sing cedhak, WebAssembly bakal mbantu, sing saiki ngaku minangka standar Internet penting sabanjure.

kesimpulan

Mugi ing sadurunge artikel Aku bisa gawe uwong yakin yen ngasilake nomer acak ing pamblokiran penting kanggo akeh aspek urip jaringan desentralisasi, lan artikel iki aku nuduhake yen tugas iki ambisi banget lan angel, nanging solusi sing apik wis ana. Umumé, desain pungkasan saka protokol mung bisa ditindakake sawise nganakake tes gedhe-gedhe sing nggatekake kabeh aspek saka persiyapan nganti emulasi kesalahan, saengga sampeyan ora bisa nemokake resep-resep sing wis siap ing kertas putih lan artikel tim, lan mesthine ora bakal. mutusake ing taun utawa rong taun sabanjure nulis "lakoni kanthi cara iki, kanthi bener."

Bye, kanggo PVRB kita ing blockchain sing dikembangake Haya, kita mapan ing nggunakake ambang BLS teken, kita rencana kanggo ngleksanakake PVRB ing tingkat konsensus, wiwit verifikasi ing kontrak pinter karo tingkat ditrima keamanan durung bisa. Sampeyan bisa uga nggunakake rong skema bebarengan: pisanan, enggo bareng rahasia sing larang kanggo nggawe random_seed jangka panjang, lan banjur digunakake minangka basis kanggo generasi acak frekuensi dhuwur nggunakake teken BLS ambang deterministik, mbok menawa kita mung bakal mbatesi awake dhewe. salah sawijining skema. Sayange, ora bisa ngomong luwih dhisik apa protokol kasebut; mung sing apik yaiku, kaya ing ilmu pengetahuan, ing masalah teknik, asil negatif uga minangka asil, lan saben upaya anyar kanggo ngatasi masalah kasebut minangka langkah liya kanggo riset saben wong sing melu masalah. Kanggo nyukupi syarat bisnis, kita ngrampungake masalah praktis tartamtu - nyedhiyakake aplikasi game kanthi sumber entropi sing bisa dipercaya, mula kita uga kudu menehi perhatian marang pamblokiran kasebut, utamane masalah finalitas rantai lan tata kelola jaringan.

Lan sanajan kita durung ndeleng PVRB tahan sing wis kabukten ing blokchain, sing bakal digunakake kanggo wektu sing cukup kanggo dites dening aplikasi nyata, akeh audit, beban, lan mesthi, serangan nyata, nanging jumlah dalan sing bisa dikonfirmasi. solusi ana, lan apa - saka algoritma iki pungkasanipun bakal ngatasi masalah. Kita bakal seneng nuduhake asil lan matur nuwun marang tim liyane sing uga nggarap masalah iki kanggo artikel lan kode sing ngidini para insinyur ora mlaku ing rake sing padha kaping pindho.

Dadi, yen sampeyan ketemu programmer sing ngrancang acak terdesentralisasi, ati-ati lan peduli, lan menehi bantuan psikologis yen perlu :)

Source: www.habr.com