Танилцуулга

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

Криптографийн туйлын хүчтэй шифрийн тухай ойлголтын нэгэн адил бодит "Олон нийтэд баталгаажуулах санамсаргүй дохио" (цаашид PVRB) протоколууд нь зөвхөн хамгийн тохиромжтой схемд аль болох ойртохыг хичээдэг. Бодит сүлжээнд үүнийг цэвэр хэлбэрээр ашиглах боломжгүй: нэг бит дээр хатуу тохиролцох шаардлагатай, олон тойрог байх ёстой, бүх мессеж төгс хурдан бөгөөд үргэлж хүргэх ёстой. Мэдээжийн хэрэг, энэ нь бодит сүлжээнд тийм биш юм. Тиймээс орчин үеийн блокчэйн дэх тодорхой ажлуудад зориулж PVRB-ийг зохион бүтээхдээ үүссэн санамсаргүй байдал, криптографийн хүчийг хянах боломжгүйгээс гадна илүү олон цэвэр архитектур, техникийн асуудлууд гарч ирдэг.

PVRB-ийн хувьд блокчэйн нь өөрөө мессеж = гүйлгээ бүхий харилцааны хэрэгсэл юм. Энэ нь сүлжээний асуудал, мессежийг хүргэхгүй байх, дунд програм хангамжийн асуудлаас хэсэгчлэн салгах боломжийг олгодог - эдгээр бүх эрсдлийг төвлөрсөн бус сүлжээ хариуцдаг бөгөөд PVRB-ийн гол үнэ цэнэ нь аль хэдийн илгээсэн гүйлгээг хүчингүй болгох, эвдэх боломжгүй юм. оролцогчид зөвшилцөлд амжилттай халдлага үйлдээгүй бол протоколд оролцохоос татгалзахыг зөвшөөрөхгүй. Энэхүү аюулгүй байдлын түвшин нь хүлээн зөвшөөрөгдөхүйц тул PVRB нь үндсэн блокчейн сүлжээтэй яг ижил хэмжээнд оролцогчдын тохиролцоонд тэсвэртэй байх ёстой. Түүнчлэн, энэ нь сүлжээ нь үндсэн блокчейн дээр санал нийлж байгаа бол PVRB нь зөвшилцлийн нэг хэсэг байх ёстойг сануулж байна, тэр ч байтугай санамсаргүй байдлаар үр дүнд хүрсэн цорын ганц зөвшилцөлд хүрсэн ч гэсэн. Эсвэл PVRB нь блокчэйн болон блокуудын хувьд асинхроноор ажилладаг ухаалаг гэрээгээр хэрэгждэг бие даасан протокол юм. Хоёр арга хоёулаа давуу болон сул талуудтай бөгөөд тэдгээрийн хоорондох сонголт нь маш энгийн зүйл биш юм.

PVRB-ийг хэрэгжүүлэх хоёр арга зам

PVRB-ийг хэрэгжүүлэх хоёр сонголтыг илүү дэлгэрэнгүй тайлбарлая: блокчэйн-аас хамааралгүй ухаалаг гэрээг ашиглан ажилладаг бие даасан хувилбар, протоколд суулгасан зөвшилцөлд суурилсан хувилбар, үүний дагуу сүлжээ блокчэйн болон гүйлгээг тохиролцдог. оруулах. Ямар ч тохиолдолд би алдартай блокчейн хөдөлгүүрүүдийг хэлэх болно: Ethereum, EOS болон ухаалаг гэрээг зохион байгуулж, боловсруулах арга барилаараа тэдэнтэй төстэй.

Бие даасан гэрээ

Энэхүү хувилбарт PVRB нь санамсаргүй үйлдвэрлэгчдийн гүйлгээг (цаашид RP гэх) хүлээн авч, тэдгээрийг боловсруулж, үр дүнг нэгтгэж, үр дүнд нь ямар ч хэрэглэгч энэхүү гэрээнээс авах боломжтой тодорхой утгыг олж авах ухаалаг гэрээ юм. Энэ утгыг гэрээнд шууд хадгалахгүй, харин зөвхөн санамсаргүй үр дүнгийн нэг бөгөөд зөвхөн нэг утгыг тодорхойлох боломжтой өгөгдлөөр төлөөлдөг. Энэ схемд RP нь блокчейн хэрэглэгчид бөгөөд хэн ч үүсгэх процесст оролцохыг зөвшөөрч болно.

Бие даасан гэрээтэй сонголт нь сайн:

• зөөврийн чадвар (гэрээг блокчэйнээс блокчэйн рүү чирж болно)
• хэрэгжүүлэх, туршихад хялбар (гэрээг бичих, шалгахад хялбар)
• эдийн засгийн схемийг хэрэгжүүлэхэд хялбар байх (логик нь PVRB-ийн зорилгод нийцсэн өөрийн жетон хийхэд хялбар)
• аль хэдийн ажиллаж байгаа блокчейн дээр эхлүүлэх боломж

Энэ нь бас сул талуудтай:

• Тооцооллын нөөц, гүйлгээний хэмжээ, хадгалалтын хүчтэй хязгаарлалт (өөрөөр хэлбэл cpu/mem/io)
• гэрээний хүрээнд үйл ажиллагааны хязгаарлалт (бүх заавар байхгүй, гадаад номын санг холбоход хэцүү)
• гүйлгээг блокчэйнд оруулахаас илүү хурдан мессежийг зохион байгуулах чадваргүй байх

Энэ сонголт нь одоо байгаа сүлжээнд ажиллах шаардлагатай, нарийн төвөгтэй криптограф агуулаагүй, олон тооны харилцан үйлчлэл шаарддаггүй PVRB-ийг хэрэгжүүлэхэд тохиромжтой.

Зөвшилцөлд нэгдсэн

Энэ хувилбарт PVRB нь блокчэйн зангилааны кодонд суулгагдсан эсвэл блокчейн зангилааны хооронд мессеж солилцохтой зэрэгцэн ажилладаг. Протоколын үр дүнг үйлдвэрлэсэн блокуудад шууд бичиж, протоколын мессежийг p2p сүлжээгээр зангилаа хооронд илгээдэг. Протоколын үр дүнд блокоор бичигдэх тоонууд гарч ирдэг тул сүлжээ нь тэдгээрийн талаар зөвшилцөлд хүрэх ёстой. Энэ нь гүйлгээ гэх мэт PVRB мессежийг зангилаагаар баталгаажуулж, блокуудад оруулах ёстой гэсэн үг бөгөөд ингэснээр сүлжээний аль ч оролцогч PVRB протоколд нийцэж байгаа эсэхийг баталгаажуулах боломжтой болно. Энэ нь биднийг автоматаар тодорхой шийдэлд хүргэдэг - хэрэв сүлжээ нь блок болон түүн дэх гүйлгээний талаар зөвшилцөлд хүрсэн бол PVRB нь бие даасан протокол биш харин зөвшилцлийн нэг хэсэг байх ёстой. Үгүй бол зөвшилцлийн үүднээс блок хүчинтэй байж болох ч PVRB протоколыг дагаж мөрдөөгүй, PVRB үүднээс блокыг хүлээн авах боломжгүй. Тиймээс хэрэв "зөвшилцөлд нэгдсэн" хувилбарыг сонгосон бол PVRB нь зөвшилцлийн чухал хэсэг болно.

PVRB-ийн хэрэгжилтийг сүлжээний зөвшилцлийн түвшинд тайлбарлахдаа эцсийн байдлаар шийдвэрлэх асуудлуудаас зайлсхийх боломжгүй. Төгсгөл гэдэг нь эцсийнх бөгөөд зэрэгцээ салаа үүссэн ч хэзээ ч хаягдахгүй блок (болон түүн рүү хөтлөх гинж)-д түгжигддэг детерминист зөвшилцөлд ашиглагддаг механизм юм. Жишээлбэл, Bitcoin-д ийм механизм байдаггүй - хэрвээ та илүү нарийн төвөгтэй гинжийг нийтлэх юм бол энэ нь гинжний уртаас үл хамааран бага төвөгтэй нэгийг солих болно. Жишээлбэл, EOS дээр сүүлчийнх нь 432 блок тутамд (12*21 + 12*15, урьдчилсан санал хураалт + урьдчилсан үүрэг) гарч ирдэг Сүүлийн эргэлт буцалтгүй блокууд юм. Энэ үйл явц нь үндсэндээ блок үйлдвэрлэгчдийн 2/3 (цаашид АД гэх) гарын үсгийг хүлээж байна. Сүүлчийн LIB-ээс хуучин сэрээ гарч ирэхэд тэдгээрийг зүгээр л хаядаг. Энэ механизм нь халдагч ямар нөөцтэй байсан ч гүйлгээ блокчэйнд багтсан бөгөөд хэзээ ч буцаагдахгүй гэдгийг баталгаажуулах боломжтой болгодог. Мөн эцсийн блокууд нь Hyperledger, Tendermint болон бусад pBFT-д суурилсан зөвшилцөлд 2/3 BP-ийн гарын үсэг зурсан блокууд юм. Түүнчлэн, блок үйлдвэрлэх, хэвлэн нийтлэхтэй асинхрон ажиллах боломжтой тул эцсийн байдлыг баталгаажуулах протоколыг зөвшилцлийн нэмэлт болгох нь зүйтэй юм. Энд нэг сайн байна нийтлэл Ethereum дахь эцсийн байдлын тухай.

Эцсийн шийдэл нь хэрэглэгчдэд маш чухал бөгөөд үүнгүйгээр "давхар зардал"-ын халдлагад өртөж, BP блокуудыг "барьж", сүлжээ сайн гүйлгээг "харсны" дараа нийтэлдэг. Хэрэв эцсийн шийдэл байхгүй бол хэвлэгдсэн сэрээ нь блокыг "сайн" гүйлгээгээр сольж, "муу" салаагаар сольж, ижил мөнгийг халдагчийн хаяг руу шилжүүлдэг. PVRB-ийн хувьд эцсийн шатанд тавигдах шаардлагууд бүр ч хатуу байдаг, учир нь PVRB-д зориулсан сэрээ барих нь халдагчид хамгийн ашигтай хувилбарыг нийтлэхийн тулд хэд хэдэн санамсаргүй хувилбаруудыг бэлтгэх боломжийг олгодог бөгөөд болзошгүй халдлагын хугацааг хязгаарлах явдал юм. сайн шийдэл.

Тиймээс, хамгийн сайн сонголт бол PVRB болон эцсийн байдлыг нэг протоколд нэгтгэх явдал юм - дараа нь эцсийн блок = эцсийн байдлаар санамсаргүй байдлаар, бид яг үүнийг авах шаардлагатай байсан. Одоо тоглогчид N секундын дотор баталгаатай санамсаргүй тоглоомыг хүлээн авах бөгөөд үүнийг буцаах эсвэл дахин тоглуулах боломжгүй гэдэгт итгэлтэй байж болно.

Зөвшилцлийн нэгдсэн сонголт нь сайн:

• блок үйлдвэрлэхтэй холбоотой асинхрон хэрэгжүүлэх боломж - блокуудыг ердийн байдлаар үйлдвэрлэдэг боловч үүнтэй зэрэгцэн PVRB протокол ажиллах боломжтой бөгөөд энэ нь блок бүрт санамсаргүй байдлыг үүсгэдэггүй.
• ухаалаг гэрээнд тавьсан хязгаарлалтгүйгээр хүнд криптографийг ч хэрэгжүүлэх чадвар
• гүйлгээг блокчэйнд оруулснаас илүү хурдан мессеж солилцох чадвар, жишээлбэл, протоколын нэг хэсэг нь сүлжээгээр мессеж түгээхгүйгээр зангилаа хооронд ажиллах боломжтой.

Энэ нь бас сул талуудтай:

• Туршилт, хөгжүүлэлтийн хүндрэлүүд - та сүлжээний алдаа, дутуу зангилаа, сүлжээний хатуу сэрээ зэргийг дуурайх хэрэгтэй болно.
• Хэрэгжүүлэлтийн алдаа нь сүлжээний хатуу бэхэлгээг шаарддаг

PVRB-ийг хэрэгжүүлэх хоёр арга хоёулаа амьд явах эрхтэй боловч орчин үеийн блокчэйн дэх ухаалаг гэрээг хэрэгжүүлэх нь тооцоолох нөөцийн хувьд нэлээд хязгаарлагдмал хэвээр байгаа бөгөөд ноцтой криптограф руу шилжих нь ихэвчлэн боломжгүй юм. Бидэнд ноцтой криптограф хэрэгтэй болно, үүнийг доор харуулах болно. Хэдийгээр энэ асуудал түр зуурынх нь тодорхой боловч олон асуудлыг шийдвэрлэхийн тулд гэрээнд ноцтой криптограф хийх шаардлагатай бөгөөд энэ нь аажмаар гарч ирж байна (жишээлбэл, Ethereum дахь zkSNARK-ийн системийн гэрээнүүд)

Ил тод, найдвартай протоколын мессежийн сувгийг хангадаг блокчейн нь үүнийг үнэ төлбөргүй хийдэггүй. Аливаа төвлөрсөн бус протокол нь Sybil халдлагын боломжийг харгалзан үзэх ёстой; аливаа үйлдлийг олон тооны дансны нэгдсэн хүчнүүд хийх боломжтой тул дизайн хийхдээ халдагчид дурын тооны протокол үүсгэх чадварыг харгалзан үзэх шаардлагатай. харилцан тохиролцож үйл ажиллагаа явуулж буй оролцогчид.

PVRB болон блок хувьсагч.

Олон мөрийтэй тоглоомын программуудаар туршсан сайн PVRB-ийг блокчейн дээр хэн ч хэрэгжүүлээгүй гэж хэлэхэд би худлаа хэлээгүй. Ethereum болон EOS дээр ийм олон мөрийтэй тоглоомын програмууд хаанаас ирдэг вэ? Энэ нь таныг гайхшруулж байгаа шиг намайг гайхшруулж байна, тэд бүрэн тодорхойлогч орчинд ийм олон "тогтвортой" санамсаргүй зүйлийг хаанаас олж авсан бэ?

Блокчейн дэх санамсаргүй байдлыг олж авах хамгийн дуртай арга бол блокоос ямар нэгэн "урьдчилан таамаглах боломжгүй" мэдээллийг авч, түүн дээр үндэслэн санамсаргүй мэдээлэл хийх явдал юм - зүгээр л нэг буюу хэд хэдэн утгыг хэшлэх замаар. Ийм схемийн асуудлын талаар сайн нийтлэл энд. Та блок дахь "урьдчилан таамаглах боломжгүй" утгуудын аль нэгийг авч болно, жишээлбэл, блок хэш, гүйлгээний тоо, сүлжээний нарийн төвөгтэй байдал болон бусад урьдчилан мэдэгдээгүй утгууд. Дараа нь тэдгээрийг нэг буюу хэд хэдэн хэш болгож, онолын хувьд та жинхэнэ санамсаргүй байдлаар авах хэрэгтэй. Та цаасан дээр өөрийн схемийг "квантын дараах аюулгүй" гэж нэмж болно (учир нь квант хамгаалалттай хэш функцүүд байдаг :)).

Гэвч квантын дараах аюулгүй хэшүүд ч хангалтгүй, харамсалтай нь. Нууц нь PVRB-д тавигдах шаардлагад оршдог тул өмнөх нийтлэлээс танд сануулъя.

1. Үр дүн нь нотлохуйц жигд тархалттай байх ёстой, өөрөөр хэлбэл баттай хүчтэй криптограф дээр суурилсан байх ёстой.
2. Үр дүнгийн аль нэг битийг хянах боломжгүй. Үүний үр дүнд үр дүнг урьдчилан таамаглах боломжгүй юм.
3. Протоколд оролцохгүй байх эсвэл халдлагын мессежээр сүлжээг хэт ачаалах замаар та үүсгэх протоколыг эвдэж чадахгүй.
4. Дээр дурдсан бүх зүйл нь протоколын шударга бус оролцогчдын зөвшөөрөгдөх тооны (жишээлбэл, оролцогчдын 1/3) тохиролцоонд тэсвэртэй байх ёстой.

Энэ тохиолдолд зөвхөн 1-р шаардлага хангагдсан бөгөөд 2-р шаардлага хангагдаагүй байна. Блокоос урьдчилан тааварлах боломжгүй утгыг хэш болгосноор бид жигд тархалт, сайн санамсаргүй тоо авах болно. Гэхдээ BP-д ядаж "блокыг нийтлэх эсвэл гаргахгүй байх" сонголт бий. Тиймээс АД хамгийн багадаа санамсаргүй хоёр хувилбараас сонгох боломжтой: "өөрийнх нь" ба өөр хэн нэгэн блок хийвэл гарах хувилбар. BP нь блок нийтлэх юм бол юу болохыг урьдчилан "мэдэгдэж", үүнийг хийх эсэхээ шийддэг. Тиймээс, жишээ нь рулетк дээр "тэгш сондгой" эсвэл "улаан/хар" тоглож байхдаа зөвхөн ялалтыг харсан тохиолдолд л блок нийтлэх боломжтой. Энэ нь жишээлбэл, "ирээдүйгээс" блок хэшийг ашиглах стратегийг ажиллах боломжгүй болгодог. Энэ тохиолдолд тэд "санамсаргүй байдлаар ашиглах болно, энэ нь одоогийн өгөгдөл болон ирээдүйн блокийн хэшийг хэшлэх замаар олж авсан, жишээ нь N + 42 өндөртэй N нь одоогийн блокийн өндөр юм. Энэ нь бүдүүвчийг бага зэрэг бэхжүүлж байгаа ч АД-ыг ирээдүйд ч гэсэн блок барих эсвэл нийтлэх эсэхээ сонгох боломжийг олгодог.

Энэ тохиолдолд АД-ын програм хангамж илүү төвөгтэй болох боловч тийм ч их биш юм. Энгийнээр, гүйлгээг блокт баталгаажуулж, оруулахдаа хожих эсэхийг хурдан шалгах, магадгүй хожих магадлал өндөртэй байхын тулд нэг гүйлгээний параметрийг сонгох боломжтой. Үүний зэрэгцээ, ийм заль мэх хийхэд ухаалаг АД-ыг барих нь бараг боломжгүй бөгөөд та шинэ хаяг ашиглах бүртээ сэжиг төрүүлэхгүйгээр бага багаар ялах боломжтой.

Тиймээс блокийн мэдээллийг ашиглах аргууд нь PVRB-ийн бүх нийтийн хэрэгжилтийн хувьд тохиромжгүй юм. Хязгаарлагдмал хувилбарт бооцооны хэмжээ, тоглогчдын тоо болон/эсвэл KYC бүртгэлийн хязгаарлалт (нэг тоглогч олон хаяг ашиглахаас сэргийлэхийн тулд) эдгээр схемүүд нь жижиг тоглоомуудад ажиллах боломжтой, гэхдээ үүнээс өөр зүйл байхгүй.

PVRB болон commit-илчлэх.

За, хэш болон блок хэш болон бусад хувьсагчийн харьцангуй урьдчилан таамаглах боломжгүй байдлын ачаар. Урд талын уурхайчдын асуудлыг шийдэж өгвөл илүү тохиромжтой зүйл авах хэрэгтэй. Энэ схемд хэрэглэгчдийг нэмье - тэд ч бас санамсаргүй байдалд нөлөөлнө үү: МТ систем дэх хамгийн санамсаргүй зүйл бол хэрэглэгчдийн үйлдэл гэдгийг техникийн тусламжийн ажилтан танд хэлэх болно :)

Хэрэглэгчид зүгээр л санамсаргүй тоо илгээж, үр дүнг нь жишээ нь тэдний нийлбэрийн хэш гэж тооцдог гэнэн схем тохиромжгүй. Энэ тохиолдолд сүүлчийн тоглогч өөрийн санамсаргүй сонголтоор үр дүн нь ямар байхыг хянах боломжтой. Ийм учраас маш өргөн хэрэглэгддэг commit-reveal загварыг ашигладаг. Оролцогчид эхлээд санамсаргүй сонголтоосоо хэш илгээдэг (амлалт), дараа нь өөрсдөө санамсаргүй нээдэг (илчилдэг). "Илчлэх" үе шат нь зөвхөн шаардлагатай амлалтуудыг цуглуулсны дараа эхэлдэг тул оролцогчид өмнө нь илгээсэн санамсаргүй хэшийг яг илгээх боломжтой. Одоо энэ бүгдийг блокийн параметрүүдтэй хамтад нь авч үзье, мөн ирээдүйгээс авсан нэгээс илүү (санамсаргүй байдлыг зөвхөн ирээдүйн блокуудын аль нэгэнд нь олж болно), мөн voila - санамсаргүй байдал бэлэн боллоо! Одоо ямар ч тоглогч үүссэн санамсаргүй байдалд нөлөөлж, хорлонтой АД-ыг өөрийн, урьдчилан мэдэгдээгүй, санамсаргүй байдлаар дарж "ялах" боломжтой ... Мөн та протоколыг илчлэх үе шатанд нээхгүй байх замаар хорлон сүйтгэхээс хамгаалах хамгаалалтыг нэмж болно. гүйлгээ хийхдээ тодорхой хэмжээний төлбөрийг гүйлгээнд хавсаргахыг шаардах замаар - зөвхөн илчлэх ажиллагааны явцад буцааж өгөх баталгааны барьцаа. Энэ тохиолдолд үйлдэж, илчлэхгүй байх нь ашиггүй болно.

Энэ бол сайн оролдлого байсан бөгөөд ийм схемүүд тоглоомын DApp-д ч байдаг, гэхдээ харамсалтай нь энэ нь дахин хангалтгүй юм. Одоо зөвхөн уурхайчин төдийгүй протоколын аль ч оролцогч үр дүнд нөлөөлж чадна. Өөрчлөлт багатай, өртөг зардлаар үнэ цэнийг өөрөө хянах боломжтой хэвээр байгаа боловч олборлогчийн нэгэн адил хэрэв зургийн үр дүн PVRB протоколд оролцох хураамжаас илүү үнэ цэнэтэй бол санамсаргүй байдлаар -producer(RP) нь илчлэх эсэхээ шийдэж, дор хаяж хоёр санамсаргүй сонголтоос сонгох боломжтой.
Гэхдээ үйлдсэн, илчлээгүй хүмүүсийг шийтгэх боломжтой болсон бөгөөд энэ схем хэрэг болно. Түүний энгийн байдал нь ноцтой давуу тал юм - илүү ноцтой протоколууд нь илүү хүчирхэг тооцоолол шаарддаг.

PVRB ба детерминистик гарын үсэг.

RP-г "урьдчилсан зураг" -аар хангасан тохиолдолд нөлөөлөх боломжгүй псевдо санамсаргүй дугаар өгөхийг албадах өөр нэг арга бий - энэ нь тодорхойлогч гарын үсэг юм. Ийм гарын үсэг нь жишээлбэл, RSA бөгөөд ECS биш юм. Хэрэв RP нь RSA болон ECC гэсэн хос түлхүүртэй бөгөөд тэрээр хувийн түлхүүрээрээ тодорхой утгыг гарын үсэг зурсан бол RSA-ийн хувьд ГАНЦХАН гарын үсэг авах ба ECS-ийн хувьд тэрээр хэдэн ч тооны гарын үсэг үүсгэх боломжтой. өөр өөр хүчинтэй гарын үсэг. Учир нь ECS гарын үсгийг бүтээхдээ гарын үсэг зурсан хүний ​​сонгосон санамсаргүй тоог ашигладаг бөгөөд үүнийг ямар ч аргаар сонгож болох нь гарын үсэг зурсан хүнд хэд хэдэн гарын үсгийн аль нэгийг сонгох боломжийг олгодог. RSA-ийн хувьд: "нэг оролтын утга" + "нэг түлхүүрийн хос" = "нэг гарын үсэг". Өөр RP ямар гарын үсэг авахыг урьдчилан таамаглах боломжгүй тул ижил утгатай гарын үсэг зурсан хэд хэдэн оролцогчдын RSA гарын үсгийг нэгтгэх замаар тодорхойлогч гарын үсэг бүхий PVRB зохион байгуулж болно. Жишээлбэл, өмнөх санамсаргүй. Энэ схем нь маш их нөөцийг хэмнэдэг, учир нь Гарын үсэг нь протоколын дагуу зөв зан үйлийн баталгаа бөгөөд санамсаргүй байдлын эх үүсвэр юм.

Гэсэн хэдий ч детерминист гарын үсэгтэй байсан ч энэ схем нь "сүүлчийн үүрэг гүйцэтгэгч" асуудалд өртөмтгий хэвээр байна. Сүүлийн оролцогч гарын үсгээ нийтлэх эсэхээ шийдэж, үр дүнг хянах боломжтой хэвээр байна. Та схемийг өөрчилж, түүнд блок хэш нэмж, үр дүнг урьдчилан таамаглах боломжгүй тойрог хийж болно, гэхдээ эдгээр бүх аргууд нь олон өөрчлөлтийг харгалзан үзсэн ч нэг оролцогчийн хамтын нийгэмлэгт үзүүлэх нөлөөллийн асуудлыг шийдээгүй хэвээр байна. найдваргүй орчинд үр дүнд нь зөвхөн эдийн засгийн болон цаг хугацааны хязгаарлалтын дор ажиллах боломжтой. Үүнээс гадна RSA түлхүүрүүдийн хэмжээ (1024 ба 2048 бит) нь нэлээд том бөгөөд блокчейн гүйлгээний хэмжээ нь маш чухал параметр юм. Асуудлыг шийдэх энгийн арга байхгүй бололтой, цаашаа явцгаая.

PVRB болон нууц хуваалцах схемүүд

Криптографийн хувьд сүлжээнд зөвхөн нэг PVRB утгыг тохиролцох боломжийг олгодог схемүүд байдаг бол ийм схемүүд нь зарим оролцогчдын аливаа хорлонтой үйлдэлд тэсвэртэй байдаг. Танилцах нь зүйтэй нэг ашигтай протокол бол Шамирын нууц хуваалцах схем юм. Энэ нь нууцыг (жишээ нь, нууц түлхүүр) хэд хэдэн хэсэгт хувааж, эдгээр хэсгийг N оролцогчдод тараахад үйлчилдэг. Нууц нь N-ээс M хэсэг нь сэргээхэд хангалттай байхаар тархсан бөгөөд эдгээр нь ямар ч M хэсэг байж болно. Хэрэв хуруугаараа үл мэдэгдэх функцийн график байгаа бол оролцогчид график дээр оноо солилцож, M оноо авсны дараа функцийг бүхэлд нь сэргээж болно.
Сайхан тайлбар орууллаа вики Гэхдээ протоколыг толгойдоо тоглуулахын тулд үүнтэй тоглох нь ашигтай байдаг Демо хуудас.

Хэрэв FSSS (Fiat-Shamir Secret Sharing) схемийг цэвэр хэлбэрээр нь ашиглах боломжтой байсан бол энэ нь үл эвдрэх PVRB байх болно. Хамгийн энгийнээр бол протокол дараах байдалтай байж болно.

• Оролцогч бүр өөрийн санамсаргүй байдлаар үүсгэж, үүнээс бусад оролцогчдод хувьцаа тараадаг
• Оролцогч бүр бусад оролцогчдын нууцын өөрийн хэсгийг илчилдэг
• Хэрэв оролцогч М-ээс олон хувьцаатай бол энэ оролцогчийн тоог тооцоолж болох бөгөөд энэ нь илчлэгдсэн оролцогчдын багцаас үл хамааран өвөрмөц байх болно.
• Илчлэгдсэн санамсаргүй тоонуудын хослол нь хүссэн PVRB юм

Энд санамсаргүй байдлын илчлэлтийн босгонд хүрэх нь зөвхөн түүнээс хамаарахаас бусад тохиолдолд оролцогч хувь хүн протоколын үр дүнд нөлөөлөхгүй. Тиймээс энэхүү протокол нь хэрэв протокол дээр ажиллаж байгаа RP-ийн шаардлагатай хувь хэмжээ байгаа бөгөөд бэлэн байгаа бол криптографийн бат бөх байдлын шаардлагыг хэрэгжүүлж, "сүүлчийн үүрэг гүйцэтгэгч" асуудалд тэсвэртэй ажилладаг.

Энэ нь хамгийн тохиромжтой сонголт байж болох тул Fiat-Shamir-ийн нууцыг хуваалцахад суурилсан энэхүү PVRB схемийг жишээ нь доор тайлбарласан болно. энэ нь нийтлэл. Гэхдээ дээр дурьдсанчлан, хэрэв та үүнийг блокчэйнд шууд ашиглахыг оролдвол техникийн хязгаарлалт гарч ирнэ. EOS ухаалаг гэрээнд протоколын туршилтын хэрэгжилтийн жишээ ба түүний хамгийн чухал хэсэг болох нийтлэгдсэн хувьцааны оролцогчийг шалгах жишээ энд байна. код. Баталгаажуулалтын баталгаажуулалт нь хэд хэдэн скаляр үржүүлэлтийг шаарддаг бөгөөд ашигласан тоо нь маш том гэдгийг та кодоос харж болно. Блокчейн дээр баталгаажуулалт нь блок үйлдвэрлэгч гүйлгээг боловсруулах үед тохиолддог бөгөөд ерөнхийдөө аливаа оролцогч протоколын зөв эсэхийг хялбархан шалгах ёстой тул шалгах функцийн хурдад тавигдах шаардлага маш ноцтой байдаг гэдгийг ойлгох хэрэгтэй. . Энэ сонголтод баталгаажуулалт нь гүйлгээний хязгаарт (0.5 секунд) багтахгүй тул сонголт үр дүнгүй болсон.

Баталгаажуулалтын үр ашиг нь ерөнхийдөө блокчейн дэх аливаа дэвшилтэт криптографийн схемийг ашиглахад тавигдах хамгийн чухал шаардлагуудын нэг юм. Нотолгоо үүсгэх, мессеж бэлтгэх - эдгээр процедурыг сүлжээнээс салгаж, өндөр хүчин чадалтай компьютер дээр хийж болох боловч баталгаажуулалтыг тойрч гарах боломжгүй - энэ нь PVRB-д тавигдах бас нэг чухал шаардлага юм.

PVRB болон босго гарын үсэг

Нууц хуваалцах схемтэй танилцсаны дараа бид "босго" гэсэн түлхүүр үгээр нэгдсэн протоколуудын бүхэл бүтэн ангиллыг олж мэдсэн. Зарим мэдээллийг задруулахад N-аас M шударга оролцогчдын оролцоо шаардлагатай бөгөөд шударга оролцогчдын багц нь N-ийн дурын дэд олонлог байж болох үед бид "босго" схемийн тухай ярьдаг. Тэд л бидэнд "сүүлчийн жүжигчин"-ийн асуудлыг шийдэх боломжийг олгож байгаа бөгөөд хэрэв халдлага үйлдэгч нууцынхаа хэсгийг задруулахгүй бол өөр, шударга оролцогч түүний өмнөөс үүнийг хийх болно. Эдгээр схемүүд нь протоколд оролцогчдын зарим нь хорлон сүйтгэсэн ч гэсэн ганцхан утгаараа тохиролцох боломжийг олгодог.

Тодорхойлолттой гарын үсэг ба босго схемийн хослол нь PVRB-ийг хэрэгжүүлэхэд маш тохиромжтой, ирээдүйтэй схемийг боловсруулах боломжтой болсон - эдгээр нь детерминист босго гарын үсэг юм. Энд нийтлэл босго гарын үсгийн янз бүрийн хэрэглээний талаар, бас нэг сайн зүйл энд байна удаан уншсан Дашаас.

Сүүлийн нийтлэлд BLS гарын үсгийг тайлбарласан (BLS нь Боне-Линн-Шачам, болгоогтун нийтлэл), программистуудад маш чухал бөгөөд нэн тохиромжтой чанартай байдаг - нийтийн, нууц, нийтийн түлхүүрүүд болон BLS гарын үсгийг энгийн математик үйлдлүүдийг ашиглан бие биетэйгээ нэгтгэж болох бөгөөд тэдгээрийн хослолууд нь хүчинтэй түлхүүр, гарын үсэг хэвээр үлдэж, олон түлхүүрийг хялбархан нэгтгэх боломжийг танд олгоно. гарын үсгийг нэг болгож, олон нийтийн түлхүүрийг нэг болгон хувиргана. Тэд мөн тодорхойлогч бөгөөд ижил оролтын өгөгдөлд ижил үр дүнг гаргадаг. Энэхүү чанарын ачаар BLS гарын үсгийн хослол нь өөрөө хүчинтэй түлхүүр бөгөөд энэ нь Mth-ээр нээгдэх хүртэл N оролцогчид тодорхой, олон нийтэд баталгааждаг, урьдчилан таамаглах боломжгүй ганцхан гарын үсэг зурах сонголтыг хэрэгжүүлэх боломжийг олгодог. оролцогч.

Босго BLS гарын үсэг бүхий схемд оролцогч бүр BLS (жишээлбэл, өмнөх санамсаргүй) ашиглан ямар нэгэн зүйлд гарын үсэг зурдаг бөгөөд нийтлэг босго гарын үсэг нь хүссэн санамсаргүй гарын үсэг юм. BLS гарын үсгийн криптограф шинж чанар нь санамсаргүй чанарын шаардлагыг хангаж, босго хэсэг нь "сүүлчийн оролцогч"-оос хамгаалдаг бөгөөд түлхүүрүүдийн өвөрмөц хослол нь протоколын мессежийг үр дүнтэй нэгтгэх боломжийг олгодог олон сонирхолтой алгоритмуудыг хэрэгжүүлэх боломжийг олгодог. .

Тиймээс, хэрэв та блокчэйн дээрээ PVRB барьж байгаа бол BLS босго гарын үсгийн схемтэй болох магадлалтай, хэд хэдэн төсөл үүнийг аль хэдийн ашиглаж байна. Жишээлбэл, DFinity (энд хэлхээг хэрэгжүүлдэг жишиг, ба энд баталгаажуулах боломжтой нууц хуваалцах жишээний хэрэгжилт), эсвэл Keep.network (энд тэдний санамсаргүй дохио юм шар цаас, бас энд жишээ нь протоколд үйлчилдэг ухаалаг гэрээ).

PVRB-ийн хэрэгжилт

Харамсалтай нь, PVRB блокчейн дээр хэрэгжсэн, аюулгүй байдал, тогтвортой байдлыг нь баталсан бэлэн протоколыг бид хараахан хараагүй байна. Протоколууд өөрсдөө бэлэн болсон ч одоо байгаа шийдлүүдэд тэдгээрийг техникийн хувьд ашиглах нь тийм ч хялбар биш юм. Төвлөрсөн системүүдийн хувьд PVRB нь утгагүй бөгөөд төвлөрсөн бус системүүд нь CPU, санах ой, санах ой, оролт гаралт зэрэг бүх тооцоолох нөөцөд хатуу хязгаарлагддаг. PVRB-ийг зохион бүтээх нь хамгийн багадаа амьдрах чадвартай блокчейн бүх шаардлагыг хангасан зүйлийг бий болгохын тулд өөр өөр протоколуудын хослол юм. Нэг протокол нь илүү үр дүнтэй тооцоолдог боловч RP хооронд илүү олон мессеж шаарддаг бол нөгөө нь маш цөөхөн мессеж шаарддаг боловч нотлох баримт үүсгэх нь хэдэн арван минут, бүр хэдэн цаг зарцуулдаг ажил байж болно.

Чанартай PVRB сонгохдоо анхаарах ёстой хүчин зүйлсийг би жагсаах болно.

• Криптографийн хүч чадал. Таны PVRB нь нэг битийг хянах чадваргүй, хатуу шударга байх ёстой. Зарим схемд энэ нь тийм биш тул криптографийг дуудах хэрэгтэй
• "Сүүлчийн жүжигчин" асуудал. Нэг буюу хэд хэдэн RP-г удирдаж буй халдагч хоёр үр дүнгээс аль нэгийг нь сонгох боломжтой тохиолдолд таны PVRB халдлагад тэсвэртэй байх ёстой.
• Протоколын хорлон сүйтгэх асуудал. Таны PVRB нь нэг буюу хэд хэдэн RP-г удирдаж буй халдагч санамсаргүй байх эсэхээ шийдэх халдлагад тэсвэртэй байх ёстой бөгөөд үүнд нөлөөлөх нь баталгаатай эсвэл өгөгдсөн магадлалтай байх ёстой.
• Зурвасын тоо асуудал. Таны RP нь блокчэйнд хамгийн бага мессеж илгээж, "Би зарим нэг мэдээлэл илгээсэн, би тодорхой оролцогчийн хариуг хүлээж байна" гэх мэт нөхцөл байдлаас аль болох синхрончлохоос зайлсхийх хэрэгтэй. P2p сүлжээнд, ялангуяа газарзүйн хувьд тархай бутархай сүлжээнд та хурдан хариу өгөхөд найдаж болохгүй
• Тооцооллын нарийн төвөгтэй байдлын асуудал. PVRB гинжин хэлхээний аль ч үе шатыг шалгах нь маш хялбар байх ёстой, учир нь үүнийг сүлжээний бүх бүрэн үйлчлүүлэгчид гүйцэтгэдэг. Хэрэв хэрэгжилт нь ухаалаг гэрээг ашиглан хийгдсэн бол хурдны шаардлага маш хатуу байна
• Хүртээмжтэй байдал, амьдрах чадварын асуудал. Таны PVRB сүлжээний хэсэг хэсэг хугацаанд ажиллах боломжгүй болж, RP-ийн нэг хэсэг нь зүгээр л ажиллахаа больсон нөхцөл байдалд тэсвэртэй байхыг хичээх ёстой.
• Итгэмжлэгдсэн тохиргоо болон анхны түлхүүр түгээлтийн асуудал. Хэрэв таны PVRB протоколын үндсэн тохиргоог ашигладаг бол энэ нь тусдаа том бөгөөд ноцтой түүх юм. Энд жишээ нь. Хэрэв оролцогчид протокол эхлэхээс өмнө түлхүүрээ бие биедээ хэлэх ёстой бол оролцогчдын бүрэлдэхүүн өөрчлөгдсөн тохиолдолд энэ нь бас асуудал болно.
• Хөгжлийн асуудал. Шаардлагатай хэл дээрх номын сангийн бэлэн байдал, тэдгээрийн аюулгүй байдал, гүйцэтгэл, сурталчилгаа, нарийн төвөгтэй тестүүд гэх мэт.

Жишээлбэл, босго BLS гарын үсэг нь ихээхэн асуудалтай байдаг - ажил эхлэхийн өмнө оролцогчид өөр хоорондоо түлхүүр тарааж, босго нь ажиллах бүлгийг зохион байгуулах ёстой. Энэ нь төвлөрсөн бус сүлжээнд дор хаяж нэг эргэлтийг хүлээх шаардлагатай гэсэн үг бөгөөд жишээлбэл, үүсгэсэн ранд нь тоглоомонд бараг бодит цаг хугацаанд шаардлагатай байдаг тул энэ үе шатанд протоколыг хорлон сүйтгэх боломжтой гэсэн үг юм. , босго схемийн давуу тал алдагдсан . Энэ асуудал нь өмнөхтэй харьцуулахад аль хэдийн хялбар болсон боловч хэм хэмжээг дагаж мөрдөөгүй оролцогчдоос хадгаламж байршуулах, хөрөнгө татах (тасархай) замаар эдийн засгийн хувьд хамгаалах шаардлагатай босго бүлгүүдийг бүрдүүлэх тусдаа журам боловсруулах шаардлагатай хэвээр байна. протокол. Түүнчлэн, аюулгүй байдлын хүлээн зөвшөөрөгдсөн түвшний BLS баталгаажуулалт нь жишээлбэл, стандарт EOS эсвэл Ethereum гүйлгээнд тохирохгүй - баталгаажуулахад хангалттай хугацаа байхгүй. Гэрээний код нь виртуал машинаар гүйцэтгэгддэг WebAssembly эсвэл EVM юм. Криптографийн функцууд нь эхнээсээ хэрэгжээгүй (хараахан) бөгөөд ердийн криптографийн сангаас хэдэн арван дахин удаан ажилладаг. Олон протоколууд нь үндсэн эзэлхүүн дээр суурилсан шаардлагыг хангадаггүй, жишээ нь RSA-д зориулсан 1024 ба 2048 бит нь Bitcoin болон Ethereum дахь стандарт гүйлгээний гарын үсгээс 4-8 дахин их байна.

Янз бүрийн програмчлалын хэл дээрх хэрэгжүүлэлтүүд нь чухал үүрэг гүйцэтгэдэг - эдгээр нь цөөхөн байдаг, ялангуяа шинэ протоколуудын хувьд. Зөвшилцөлд нэгтгэх сонголт нь платформ хэл дээр протокол бичихийг шаарддаг тул та Go for geth, Rust for Parity, EOS-д зориулсан C++ хэл дээр код хайх хэрэгтэй болно. Хүн бүр JavaScript кодыг хайх хэрэгтэй болно, JavaScript болон криптограф нь тийм ч дотно найзууд биш тул WebAssembly туслах болно, энэ нь одоо дараагийн чухал интернет стандарт болно.

дүгнэлт

Би өмнөх хувилбарт найдаж байна нийтлэл Блокчейн дээр санамсаргүй тоо үүсгэх нь төвлөрсөн бус сүлжээнүүдийн амьдралын олон талт чухал ач холбогдолтой гэдгийг би танд ойлгуулж чадсан бөгөөд энэ өгүүллээр би энэ даалгавар нь маш их амбицтай бөгөөд хэцүү боловч сайн шийдлүүд аль хэдийн байгаа гэдгийг харуулсан. Ерөнхийдөө протоколын эцсийн загвар нь тохиргооноос эхлээд алдааны эмуляци хүртэлх бүх талыг харгалзан үзсэн томоохон туршилтуудыг хийсний дараа л боломжтой тул та багийн танилцуулга, нийтлэлээс бэлэн жор олох магадлал багатай бөгөөд бид үүнийг хийхгүй нь гарцаагүй. Дараагийн эсвэл хоёр жилийн хугацаанд шийдээрэй, "энэ аргаар, яг зөв" гэж бичээрэй.

Баяртай, бидний хөгжүүлж буй блокчейн дэх PVRB-ийн хувьд Haya, бид босго BLS гарын үсгийг ашиглахаар шийдсэн, зөвшөөрөгдсөн түвшний аюулгүй байдлын ухаалаг гэрээнд баталгаажуулалт хийх боломжгүй байгаа тул PVRB-ийг зөвшилцлийн түвшинд хэрэгжүүлэхээр төлөвлөж байна. Бид хоёр схемийг нэг дор ашиглах боломжтой: эхлээд урт хугацааны санамсаргүй үрийг үүсгэхийн тулд үнэтэй нууц хуваалцах, дараа нь бид үүнийг тодорхой босго BLS гарын үсгийг ашиглан өндөр давтамжийн санамсаргүй үүсгэх үндэс болгон ашигладаг, магадгүй бид өөрсдийгөө хязгаарлах болно. схемүүдийн нэг. Харамсалтай нь протокол ямар байхыг урьдчилан хэлэх боломжгүй, цорын ганц сайн зүйл бол шинжлэх ухаан, инженерийн асуудалд сөрөг үр дүн гарч ирдэг бөгөөд асуудлыг шийдэх шинэ оролдлого бүр өөр нэг алхам болдог. асуудалд оролцсон хүн бүрийн судалгаа. Бизнесийн шаардлагыг хангахын тулд бид тодорхой практик асуудлыг шийддэг - тоглоомын програмуудыг энтропийн найдвартай эх үүсвэрээр хангадаг тул блокчэйн өөрөө, ялангуяа гинжин хэлхээний эцсийн байдал, сүлжээний засаглалын асуудалд анхаарлаа хандуулах хэрэгтэй.

Хэдийгээр бодит хэрэглээ, олон аудит, ачаалал, мэдээжийн хэрэг бодит халдлагуудаар туршихад хангалттай хугацаа зарцуулагдсан блокчейн дээр батлагдсан тэсвэртэй PVRB-ийг бид хараахан хараагүй байгаа ч боломжит замуудын тоо үүнийг баталж байна. шийдэл байгаа бөгөөд эдгээр алгоритмуудын аль нь асуудлыг шийдэх болно. Бид үр дүнгээ хуваалцахдаа баяртай байх болно, мөн энэ асуудал дээр ажиллаж байгаа бусад багуудад инженерүүдэд нэг тармуур дээр хоёр удаа гишгэхгүй байх боломжийг олгодог нийтлэл, кодын төлөө баярлалаа.

Тиймээс, төвлөрсөн бус санамсаргүй загвар зохион бүтээгч програмисттай уулзахдаа анхааралтай, халамжтай байж, шаардлагатай бол сэтгэлзүйн тусламж үзүүлээрэй :)

Эх сурвалж: www.habr.com