Giriş

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

Kriptoqrafiyadan tamamilə güclü şifrə anlayışında olduğu kimi, həqiqi “İctimaiyyətlə yoxlanıla bilən təsadüfi mayak” (bundan sonra PVRB) protokolları yalnız ideal sxemə mümkün qədər yaxınlaşmağa çalışır, çünki real şəbəkələrdə təmiz formada tətbiq olunmur: bir bit üzərində ciddi şəkildə razılaşmaq lazımdır, çoxlu dövrələr olmalıdır və bütün mesajlar mükəmməl sürətli və həmişə çatdırılmalıdır. Təbii ki, real şəbəkələrdə belə deyil. Buna görə də, müasir blokçeynlərdə xüsusi tapşırıqlar üçün PVRB-lərin layihələndirilməsi zamanı yaranan təsadüfiliyə və kriptoqrafik gücə nəzarətin mümkünsüzlüyündən əlavə, daha çox sırf memarlıq və texniki problemlər yaranır.

PVRB üçün blokçeyn özü mesajların = əməliyyatların olduğu bir ünsiyyət vasitəsidir. Bu, şəbəkə problemlərindən, mesajların çatdırılmamasından, ara proqram təminatı ilə bağlı problemlərdən qismən mücərrəd olmağa imkan verir - bütün bu risklər mərkəzləşdirilməmiş şəbəkə tərəfindən qəbul edilir və PVRB üçün onun əsas dəyəri artıq göndərilmiş əməliyyatı ləğv etmək və ya poza bilməməkdir - bu, konsensusa uğurlu hücum həyata keçirməsələr, iştirakçılara protokolda iştirak etməkdən imtina etmələrinə icazə verməyin. Bu təhlükəsizlik səviyyəsi məqbuldur, ona görə də PVRB əsas blokçeyn zənciri ilə eyni dərəcədə iştirakçıların sövdələşməsinə davamlı olmalıdır. Həmçinin, bu, şəbəkə əsas blokçeynlə razılaşarsa, PVRB-nin konsensusun bir hissəsi olması lazım olduğuna işarə edir, hətta o, yeganə ədalətli təsadüfi nəticə ilə də razılaşsa belə. Və ya, PVRB sadəcə olaraq blokçeyn və bloklarla bağlı asinxron işləyən ağıllı müqavilə ilə həyata keçirilən müstəqil bir protokoldur. Hər iki metodun öz üstünlükləri və mənfi cəhətləri var və onların arasında seçim son dərəcə qeyri-trivialdır.

PVRB-ni həyata keçirməyin iki yolu

Gəlin, PVRB-nin tətbiqi üçün iki variantı daha ətraflı təsvir edək - blokçeynindən asılı olmayaraq ağıllı müqavilədən istifadə edərək işləyən müstəqil versiya və protokola daxil edilmiş konsensusla inteqrasiya olunmuş versiya, buna görə şəbəkə blokçeynlə razılaşır. əməliyyatlar daxil edilməlidir. Bütün hallarda mən məşhur blokçeyn mühərriklərini nəzərdə tutacağam: Ethereum, EOS və ağıllı müqavilələrə ev sahibliyi etmək və emal etmək baxımından onlara oxşar olanların hamısı.

Müstəqil müqavilə

Bu versiyada PVRB təsadüfi istehsalçıların əməliyyatlarını (bundan sonra RP adlandırılacaq) qəbul edən, onları emal edən, nəticələri birləşdirən və nəticədə istənilən istifadəçinin bu müqavilədən ala biləcəyi müəyyən dəyərə çatan ağıllı müqavilədir. Bu dəyər birbaşa müqavilədə saxlanıla bilməz, əksinə yalnız nəticədə təsadüfi olanın bir və yalnız bir dəyərinin determinist şəkildə əldə edilə biləcəyi məlumatlarla təmsil oluna bilər. Bu sxemdə RP-lər blokçeynin istifadəçiləridir və hər kəsin generasiya prosesində iştirakına icazə verilə bilər.

Müstəqil müqavilə ilə seçim yaxşıdır:

• daşınma qabiliyyəti (müqavilələr blokçeyndən blokçeynə sürüklənə bilər)
• icra və sınaq asanlığı (müqavilələri yazmaq və sınaqdan keçirmək asandır)
• iqtisadi sxemlərin həyata keçirilməsində rahatlıq (məntiqi PVRB-nin məqsədlərinə xidmət edən öz nişanınızı düzəltmək asandır)
• artıq işləyən blokçeynlərdə işə salınma imkanı

Onun da mənfi cəhətləri var:

• hesablama resursları, əməliyyat həcmi və saxlama üzrə güclü məhdudiyyətlər (başqa sözlə, cpu/mem/io)
• müqavilə çərçivəsində əməliyyatlara məhdudiyyətlər (bütün təlimatlar mövcud deyil, xarici kitabxanaları birləşdirmək çətindir)
• blokçeynə daxil edilən əməliyyatlardan daha sürətli mesajlaşma təşkil edə bilməməsi

Bu seçim mövcud şəbəkədə işə salınmalı olan, mürəkkəb kriptoqrafiyaya malik olmayan və çoxlu sayda qarşılıqlı əlaqə tələb etməyən PVRB-nin tətbiqi üçün uyğundur.

Konsensus-inteqrasiya

Bu versiyada PVRB blokçeyn qovşaqları kodunda quraşdırılmış və ya blokçeyn qovşaqları arasında mesaj mübadiləsi ilə paralel olaraq həyata keçirilir. Protokolun nəticələri birbaşa istehsal edilmiş bloklara yazılır və protokol mesajları p2p şəbəkəsi üzərindən qovşaqlar arasında göndərilir. Protokol bloklarda yazılacaq rəqəmlərlə nəticələndiyi üçün şəbəkə onlar üzrə konsensusa gəlməlidir. Bu o deməkdir ki, əməliyyatlar kimi PVRB mesajları qovşaqlar tərəfindən təsdiq edilməli və bloklara daxil edilməlidir ki, istənilən şəbəkə iştirakçısı PVRB protokoluna uyğunluğu təsdiq edə bilsin. Bu, avtomatik olaraq bizi aşkar həll yoluna aparır - əgər şəbəkə blok və onun içindəki əməliyyatlar haqqında konsensusa razılaşarsa, o zaman PVRB müstəqil protokol deyil, konsensusun bir hissəsi olmalıdır. Əks halda, konsensus baxımından blokun etibarlı olması mümkündür, lakin PVRB protokoluna əməl olunmur və PVRB nöqteyi-nəzərindən blok qəbul edilə bilməz. Beləliklə, əgər “konsensus-inteqrasiya edilmiş” variantı seçilərsə, PVRB konsensusun vacib hissəsinə çevrilir.

Şəbəkə konsensus səviyyəsində PVRB tətbiqlərini təsvir edərkən, heç bir halda sonluq məsələlərindən qaçmaq olmaz. Sonluq, deterministik konsensuslarda istifadə edilən, son olan blokda (və ona aparan zəncirdə) kilidlənən və paralel çəngəl baş versə belə, heç vaxt atılmayacaq mexanizmdir. Məsələn, Bitcoin-də belə bir mexanizm yoxdur - daha mürəkkəb bir zəncir dərc etsəniz, zəncirlərin uzunluğundan asılı olmayaraq daha az mürəkkəb olanı əvəz edəcəkdir. Və EOS-da, məsələn, sonuncular, orta hesabla hər 432 blokdan bir (12*21 + 12*15, əvvəlcədən səsvermə + əvvəlcədən qəbul edilmiş) görünən Son Geri Dönməz Bloklar adlananlardır. Bu proses mahiyyətcə blok istehsalçılarının (bundan sonra BP adlandırılacaq) 2/3 imzasını gözləyir. Sonuncu LIB-dən daha köhnə çəngəllər göründükdə, sadəcə atılır. Bu mexanizm əməliyyatın blokçeynə daxil olmasına və təcavüzkarın hansı resurslara malik olmasından asılı olmayaraq heç vaxt geri çəkilməyəcəyinə zəmanət verməyə imkan verir. Həmçinin, son bloklar Hyperledger, Tendermint və digər pBFT əsaslı konsensuslarda 2/3 BP tərəfindən imzalanmış bloklardır. Bundan əlavə, konsensusa əlavə olaraq yekunluğu təmin etmək üçün bir protokol etmək mənasızdır, çünki o, blokların istehsalı və nəşri ilə asinxron şəkildə işləyə bilər. Budur yaxşı biri məqalə Ethereum-da sonluq haqqında.

Yekunluq, BP-nin blokları “tutduğu” və şəbəkə yaxşı əməliyyatı “gördükdən” sonra dərc etdiyi “ikiqat xərcləmə” hücumunun qurbanı ola biləcək istifadəçilər üçün son dərəcə vacibdir. Heç bir yekun yoxdursa, dərc edilmiş çəngəl bloku digəri ilə "yaxşı" bir əməliyyatla, eyni vəsaitlərin təcavüzkarın ünvanına köçürüldüyü "pis" çəngəl ilə əvəz edir. PVRB vəziyyətində, sonluq tələbləri daha sərtdir, çünki PVRB üçün çəngəllərin qurulması təcavüzkarın ən sərfəli variantı dərc etmək üçün bir neçə təsadüfi variant hazırlamaq imkanı deməkdir və mümkün hücum vaxtını məhdudlaşdırmaq yaxşı həll.

Buna görə də, ən yaxşı seçim PVRB və sonluğu bir protokolda birləşdirməkdir - sonra yekunlaşdırılmış blok = yekunlaşdırılmış təsadüfi və bu, əldə etmək üçün lazım olan şeydir. İndi oyunçular N saniyə ərzində zəmanətli təsadüfi alacaqlar və arxayın ola bilərlər ki, onu geri qaytarmaq və ya yenidən oynatmaq mümkün deyil.

Konsensusa inteqrasiya olunmuş seçim yaxşıdır:

• blokların istehsalı ilə əlaqədar asinxron həyata keçirmək imkanı - bloklar adi olaraq istehsal olunur, lakin buna paralel olaraq hər blok üçün təsadüfi olmayan PVRB protokolu işləyə bilər.
• ağıllı müqavilələrə qoyulan məhdudiyyətlər olmadan hətta ağır kriptoqrafiyanı həyata keçirmək imkanı
• blokçeynə daxil edilən əməliyyatlardan daha sürətli mesaj mübadiləsini təşkil etmək imkanı, məsələn, protokolun bir hissəsi mesajları şəbəkə üzərində yaymadan qovşaqlar arasında işləyə bilər.

Onun da mənfi cəhətləri var:

• Test və inkişafda çətinliklər - şəbəkə səhvlərini, çatışmayan qovşaqları, şəbəkə sərt çəngəllərini təqlid etməli olacaqsınız
• İcra xətaları şəbəkə hardforkunu tələb edir

PVRB-nin həyata keçirilməsinin hər iki üsulu yaşamaq hüququna malikdir, lakin müasir blokçeynlərdə smart müqavilələr üzrə tətbiq hələ də hesablama resurslarında kifayət qədər məhduddur və ciddi kriptoqrafiyaya hər hansı keçid çox vaxt sadəcə mümkün deyil. Və aşağıda göstərildiyi kimi ciddi kriptoqrafiyaya ehtiyacımız olacaq. Bu problem açıq-aydın müvəqqəti olsa da, bir çox problemlərin həlli üçün müqavilələrdə ciddi kriptoqrafiyaya ehtiyac var və o, tədricən ortaya çıxır (məsələn, Ethereum-da zkSNARK-lar üçün sistem müqavilələri)

Şəffaf və etibarlı protokol mesajlaşma kanalı təmin edən Blockchain bunu pulsuz etmir. İstənilən qeyri-mərkəzləşdirilmiş protokol Sybil hücumunun mümkünlüyünü nəzərə almalıdır; hər hansı bir hərəkət bir neçə hesabın razılaşdırılmış qüvvələri tərəfindən edilə bilər, buna görə də dizayn edərkən təcavüzkarların ixtiyari sayda protokol yaratmaq qabiliyyətini nəzərə almaq lazımdır. sövdələşmə ilə hərəkət edən iştirakçılar.

PVRB və blok dəyişənləri.

Heç kimin blokçeynlərdə bir çox qumar proqramları tərəfindən sınaqdan keçirilmiş yaxşı bir PVRB tətbiq etmədiyini söylədikdə yalan danışmadım. Ethereum və EOS-da bu qədər qumar proqramı haradan gəlir? Bu sizi təəccübləndirdiyi qədər məni də təəccübləndirir, onlar tamamilə deterministik bir mühitdə bu qədər “davamlı” təsadüfi haradan əldə ediblər?

Blockchain-də təsadüfi əldə etməyin ən sevimli yolu blokdan bir növ "gözlənilməz" məlumat almaq və onun əsasında təsadüfi məlumat yaratmaqdır - sadəcə olaraq bir və ya bir neçə dəyəri heshing etməklə. Bu cür sxemlərin problemləri haqqında yaxşı məqalə burada. Blokdakı "gözlənilməz" dəyərlərdən hər hansı birini götürə bilərsiniz, məsələn, blok hashı, əməliyyatların sayı, şəbəkə mürəkkəbliyi və əvvəlcədən bilinməyən digər dəyərlər. Sonra onları, bir və ya daha çox hash edin və nəzəri olaraq, real təsadüfi əldə etməlisiniz. Siz hətta kağıza əlavə edə bilərsiniz ki, sizin sxeminiz “post-kvant təhlükəsizdir” (çünki kvantdan qorunan hash funksiyaları var :)).

Təəssüf ki, hətta post-kvant təhlükəsiz həşlər də kifayət deyil. Sirr PVRB tələblərindədir, onları əvvəlki məqalədən xatırlatmaq istərdim:

1. Nəticə sübut edilə bilən vahid paylanmaya malik olmalıdır, yəni sübut edilə bilən güclü kriptoqrafiyaya əsaslanmalıdır.
2. Nəticənin bitlərindən heç birinə nəzarət etmək mümkün deyil. Nəticədə, nəticəni əvvəlcədən proqnozlaşdırmaq mümkün deyil.
3. Protokolda iştirak etməməklə və ya şəbəkəni hücum mesajları ilə həddən artıq yükləməklə nəsil protokolunu sabotaj edə bilməzsiniz.
4. Yuxarıda göstərilənlərin hamısı icazə verilən sayda vicdansız protokol iştirakçılarının (məsələn, iştirakçıların 1/3 hissəsi) sövdələşməyə davamlı olmalıdır.

Bu halda, yalnız 1-ci tələb yerinə yetirilir, 2-ci tələb isə yerinə yetirilmir.Blokdan gözlənilməz dəyərləri hashing etməklə, vahid paylama və yaxşı təsadüflər əldə edəcəyik. Lakin BP-nin ən azı “blok dərc edib-etməmək” seçimi var. Beləliklə, BP ən azı İKİ təsadüfi variantdan birini seçə bilər: “özünün” və bloku başqası edərsə, ortaya çıxacaq variant. BP blok dərc edərsə, nə baş verəcəyini əvvəlcədən “gözləyə” bilər və sadəcə olaraq bunu edib-etməmək qərarına gəlir. Beləliklə, məsələn, ruletdə “cüt-tək” və ya “qırmızı/qara” oynayarkən, o, yalnız qələbə gördüyü halda blok dərc edə bilər. Bu, həmçinin, məsələn, “gələcəkdən” blok hash-dan istifadə strategiyasını işlək olmur. Bu halda, onlar deyirlər ki, “təsadüfi istifadə olunacaq, bu, cari məlumatların və gələcək blokun hündürlüyü, məsələn, N + 42 hündürlüyü ilə hash etməklə əldə edilir, burada N cari blok hündürlüyüdür. Bu, sxemi bir az da gücləndirir, lakin yenə də BP-yə gələcəkdə də olsa, blokun saxlanması və ya dərc edilməsini seçmək imkanı verir.

Bu vəziyyətdə BP proqramı daha mürəkkəb olur, lakin çox deyil. Sadəcə olaraq, tranzaksiyanı təsdiqləyərkən və bloka daxil edərkən, uduşun olub-olmadığını yoxlamaq üçün sürətli yoxlama və ehtimal ki, yüksək uduş ehtimalını əldə etmək üçün bir əməliyyat parametrinin seçilməsi var. Eyni zamanda, bu cür manipulyasiyalar üçün ağıllı BP-ni tutmaq demək olar ki, mümkün deyil, hər dəfə şübhə doğurmadan yeni ünvanlardan istifadə edib az-az qalib gələ bilərsiniz.

Beləliklə, blokdan məlumat istifadə edən üsullar PVRB-nin universal tətbiqi kimi uyğun deyil. Məhdud versiyada mərc ölçülərinə məhdudiyyətlər, oyunçuların sayına məhdudiyyətlər və/və ya KYC qeydiyyatı (bir oyunçunun birdən çox ünvandan istifadəsinin qarşısını almaq üçün) ilə bu sxemlər kiçik oyunlar üçün işləyə bilər, lakin başqa heç nə yoxdur.

PVRB və törətmək-aşkar etmək.

Tamam, hashing və ən azı blok hash və digər dəyişənlərin nisbi gözlənilməzliyi sayəsində. Öndə işləyən madencilerin problemini həll etsəniz, daha uyğun bir şey almalısınız. İstifadəçiləri bu sxemə əlavə edək - onlar da təsadüfiliyə təsir göstərsinlər: istənilən texniki dəstək işçisi sizə İT sistemlərində ən təsadüfi şeyin istifadəçilərin hərəkətləri olduğunu söyləyəcək :)

İstifadəçilər sadəcə təsadüfi nömrələr göndərdikdə və nəticə, məsələn, onların cəminin hash kimi hesablandıqda sadəlövh bir sxem uyğun deyil. Bu halda, sonuncu oyunçu öz təsadüfi seçimini edərək, nəticənin nə olacağını idarə edə bilər. Buna görə çox geniş istifadə olunan commit-reveal modelindən istifadə olunur. İştirakçılar əvvəlcə öz təsadüflərindən hash göndərirlər (təhsil edir), sonra isə təsadüfiləri özləri açır (açıqlayır). “Açıq” mərhələsi yalnız lazımi öhdəliklər toplandıqdan sonra başlayır, beləliklə iştirakçılar əvvəllər göndərdikləri təsadüfi hashı tam olaraq göndərə bilərlər. İndi bütün bunları bir blokun parametrləri ilə birləşdirək və gələcəkdən götürülmüşdən daha yaxşı (təsadüfilik yalnız gələcək bloklardan birində tapıla bilər) və voila - təsadüfilik hazırdır! İndi istənilən oyunçu yaranan təsadüfiliyə təsir edir və zərərli BP-ni özünə məxsus, əvvəlcədən bilinməyən, təsadüfiliyi ilə üstün tutaraq “məğlub edə” bilər... Siz həmçinin protokolu aşkarlama mərhələsində açmamaqla onu sabotajdan qoruya bilərsiniz - sadəcə olaraq əməliyyatı həyata keçirərkən müəyyən məbləğin əlavə edilməsini tələb etməklə — yalnız aşkarlama proseduru zamanı qaytarılacaq təminat depoziti. Bu halda, törətmək və ifşa etməmək faydasız olacaq.

Bu yaxşı cəhd idi və bu cür sxemlər oyun DApp-larında da mövcuddur, amma təəssüf ki, bu yenə də kifayət deyil. İndi nəinki mədənçi, həm də protokolun istənilən iştirakçısı nəticəyə təsir edə bilər. Dəyərin özünü daha az dəyişkənliklə və xərclə idarə etmək hələ də mümkündür, lakin mədənçinin vəziyyətində olduğu kimi, tirajın nəticələri PVRB protokolunda iştirak haqqından daha dəyərlidirsə, təsadüfi -producer(RP) aşkar edib-etməmək qərarına gələ bilər və yenə də ən azı iki təsadüfi seçimdən birini seçə bilər.
Amma törədənləri və ifşa etməyənləri cəzalandırmaq mümkün oldu və bu sxem işə yarayacaq. Onun sadəliyi ciddi bir üstünlükdür - daha ciddi protokollar daha güclü hesablamalar tələb edir.

PVRB və deterministik imzalar.

RP-ni "preimage" ilə təmin olunarsa təsir edə bilməyəcəyi psevdo-təsadüfi nömrə verməyə məcbur etməyin başqa bir yolu var - bu deterministik imzadır. Belə bir imza, məsələn, RSA-dır və ECS deyil. Əgər RP-nin bir cüt açarı varsa: RSA və ECC və o, şəxsi açarı ilə müəyyən bir dəyəri imzalayırsa, RSA vəziyyətində o, BİR VƏ YALNIZ bir imza alacaq, ECS vəziyyətində isə istənilən sayda imza yarada bilər. müxtəlif etibarlı imzalar. Bunun səbəbi, ECS imzası yaratarkən təsadüfi nömrədən istifadə olunur, imzalayan tərəfindən seçilir və o, istənilən şəkildə seçilə bilər və imzalayana bir neçə imzadan birini seçmək imkanı verir. RSA vəziyyətində: “bir giriş dəyəri” + “bir açar cütü” = “bir imza”. Başqa bir RP-nin hansı imza alacağını təxmin etmək mümkün deyil, buna görə də eyni dəyəri imzalayan bir neçə iştirakçının RSA imzalarını birləşdirərək deterministik imzaları olan PVRB təşkil edilə bilər. Məsələn, əvvəlki təsadüfi. Bu sxem çoxlu resurslara qənaət edir, çünki imzalar həm protokola uyğun olaraq düzgün davranışın təsdiqi, həm də təsadüfilik mənbəyidir.

Bununla belə, deterministik imzalarla belə, sxem hələ də “sonuncu aktor” probleminə qarşı həssasdır. Son iştirakçı hələ də imzanı dərc edib-etməmək barədə qərar verə bilər və bununla da nəticəyə nəzarət edir. Sxemi dəyişdirə, ona blok hashləri əlavə edə, nəticəni əvvəlcədən proqnozlaşdırmaq mümkün olmamaq üçün dövrə vura bilərsiniz, lakin bütün bu üsullar, hətta bir çox dəyişiklikləri nəzərə alaraq, bir iştirakçının kollektivə təsiri problemini hələ də həll olunmamış qoyur. etibarsız mühitlə nəticələnir və yalnız iqtisadi və vaxt məhdudiyyətləri altında işləyə bilər. Bundan əlavə, RSA açarlarının ölçüsü (1024 və 2048 bit) kifayət qədər böyükdür və blokçeyn əməliyyatları üçün ölçü son dərəcə vacib parametrdir. Görünür, problemi həll etməyin sadə yolu yoxdur, davam edək.

PVRB və gizli paylaşma sxemləri

Kriptoqrafiyada şəbəkəyə bir və yalnız bir PVRB dəyəri ilə razılaşmağa imkan verən sxemlər mövcuddur, halbuki belə sxemlər bəzi iştirakçıların hər hansı zərərli hərəkətlərinə davamlıdır. Şamirin gizli paylaşma sxemi ilə tanış olmağa dəyər bir faydalı protokol. O, sirri (məsələn, gizli açarı) bir neçə hissəyə bölməyə və bu hissələri N iştirakçıya paylamağa xidmət edir. Sirr elə paylanır ki, onu bərpa etmək üçün N-dən M hissəsi kifayətdir və bunlar istənilən M hissə ola bilər. Əgər barmaqlarda naməlum funksiyanın qrafiki varsa, iştirakçılar qrafikdə xal mübadiləsi aparır və M xalını aldıqdan sonra bütün funksiya bərpa oluna bilər.
Yaxşı izahat verilir wiki ancaq protokolu başınızda oynamaq üçün praktik olaraq onunla oynamaq faydalıdır demo səhifə.

FSSS (Fiat-Shamir Secret Sharing) sxemi təmiz formada tətbiq oluna bilsəydi, bu, sarsılmaz PVRB olardı. Ən sadə formada protokol belə görünə bilər:

• Hər bir iştirakçı öz təsadüfini yaradır və ondan payları digər iştirakçılara paylayır
• Hər bir iştirakçı digər iştirakçıların sirlərinin öz hissəsini açır
• Əgər iştirakçının M-dən çox payı varsa, o zaman bu iştirakçının sayı hesablana bilər və aşkar edilmiş iştirakçılar dəstindən asılı olmayaraq unikal olacaqdır.
• Aşkar edilmiş təsadüflərin birləşməsi arzu olunan PVRB-dir

Burada fərdi iştirakçı, təsadüfi açıqlama həddinə nail olunmasının yalnız ondan asılı olduğu hallar istisna olmaqla, artıq protokolun nəticələrinə təsir göstərmir. Buna görə də, bu protokol, protokol üzərində işləyən və mövcud olan RP-lərin tələb olunan nisbəti varsa, işləyir, kriptoqrafik güc tələblərini həyata keçirir və “son aktor” probleminə davamlıdır.

Bu ideal seçim ola bilər, Fiat-Şamir gizli paylaşımına əsaslanan bu PVRB sxemi məsələn aşağıda təsvir edilmişdir. bu məqalə. Ancaq yuxarıda qeyd edildiyi kimi, onu blokçeynində baş-başa tətbiq etməyə çalışsanız, texniki məhdudiyyətlər görünür. Budur, EOS smart müqaviləsində protokolun test tətbiqi nümunəsi və onun ən vacib hissəsi - dərc edilmiş pay iştirakçısının yoxlanılması: kod. Koddan görə bilərsiniz ki, sübutun yoxlanılması bir neçə skalyar vurma tələb edir və istifadə olunan rəqəmlər çox böyükdür. Başa düşmək lazımdır ki, blokçeynlərdə verify blok istehsalçısı əməliyyatı emal etdiyi anda baş verir və ümumiyyətlə, hər hansı bir iştirakçı protokolun düzgünlüyünü asanlıqla yoxlamalıdır, buna görə də yoxlama funksiyasının sürətinə olan tələblər çox ciddidir. . Bu seçimdə seçim səmərəsiz oldu, çünki yoxlama əməliyyat limitinə (0.5 saniyə) uyğun gəlmədi.

Yoxlamanın effektivliyi, ümumiyyətlə, blokçeynində hər hansı qabaqcıl kriptoqrafik sxemlərin istifadəsi üçün ən vacib tələblərdən biridir. Sübutların yaradılması, mesajların hazırlanması - bu prosedurlar zəncirdən kənar götürülə və yüksək performanslı kompüterlərdə yerinə yetirilə bilər, lakin yoxlamadan yan keçə bilməz - bu, PVRB üçün başqa bir vacib tələbdir.

PVRB və hədd imzaları

Gizli paylaşma sxemi ilə tanış olduqdan sonra biz “ərəfəsində” açar sözü ilə birləşdirilən bütün protokollar sinfini kəşf etdik. Bəzi məlumatların açıqlanması N-dən M vicdanlı iştirakçıların iştirakını tələb etdikdə və dürüst iştirakçılar çoxluğu N-in ixtiyari alt çoxluğu ola bildikdə, biz “həddi” sxemlərindən danışırıq. Məhz onlar bizə “sonuncu aktyor” problemi ilə məşğul olmağa imkan verirlər, indi təcavüzkar sirrin öz hissəsini açıqlamasa, başqa, vicdanlı iştirakçı bunu onun yerinə edəcək. Bu sxemlər bəzi iştirakçılar tərəfindən protokol sabotaj edilsə belə, bir və yalnız bir məna üzərində razılaşmaya imkan verir.

Deterministik imzaların və hədd sxemlərinin birləşməsi PVRB-nin həyata keçirilməsi üçün çox rahat və perspektivli bir sxem hazırlamağa imkan verdi - bunlar deterministik hədd imzalarıdır. Burada məqalə eşik imzalarının müxtəlif istifadələri haqqında, amma burada başqa bir yaxşısı var uzun oxumaq Dashdan.

Son məqalə BLS imzalarını təsvir edir (BLS Boneh-Lynn-Shacham, burada məqalə), proqramçılar üçün çox vacib və son dərəcə əlverişli keyfiyyətə malikdir - açıq, gizli, açıq açarlar və BLS imzaları sadə riyazi əməliyyatlardan istifadə etməklə bir-biri ilə birləşdirilə bilər, eyni zamanda onların birləşmələri etibarlı açarlar və imzalar olaraq qalır və bir çoxunu asanlıqla birləşdirməyə imkan verir. imzaları bir, bir çox açıq açarları isə birinə. Onlar da deterministikdir və eyni giriş məlumatları üçün eyni nəticə verir. Bu keyfiyyət sayəsində, BLS imzalarının birləşmələri özləri etibarlı açarlardır və bu, M-dən çox iştirakçının Mth tərəfindən açılana qədər deterministik, açıq şəkildə yoxlanıla bilən və gözlənilməz olan bir və yalnız bir imza istehsal etdiyi seçimi həyata keçirməyə imkan verir. iştirakçı.

Həddi BLS imzaları olan bir sxemdə hər bir iştirakçı BLS-dən istifadə edərək nəyisə imzalayır (məsələn, əvvəlki təsadüfi) və ümumi hədd imzası istənilən təsadüfi imzadır. BLS imzalarının kriptoqrafik xassələri təsadüfi keyfiyyət tələblərinə cavab verir, eşik hissəsi “son aktordan” qoruyur və açarların unikal birləşməsi, məsələn, protokol mesajlarının səmərəli birləşməsinə imkan verən daha çox maraqlı alqoritmləri həyata keçirməyə imkan verir. .

Beləliklə, blokçeyninizdə PVRB qurursanız, çox güman ki, BLS hədd imzaları sxemi ilə başa çatacaqsınız, bir neçə layihə artıq ondan istifadə edir. Məsələn, DFinity (burada sxemi həyata keçirən etalon və burada yoxlanıla bilən məxfi paylaşmanın nümunə tətbiqi) və ya Keep.network (burada onların təsadüfi mayakıdır sarı kağızAmma misal protokola xidmət edən ağıllı müqavilə).

PVRB-nin həyata keçirilməsi

Təəssüf ki, biz hələ də öz təhlükəsizliyini və sabitliyini sübut edən PVRB blokçeynlərində həyata keçirilən hazır protokolu görmürük. Protokolların özləri hazır olsa da, texniki cəhətdən onları mövcud həllərə tətbiq etmək asan deyil. Mərkəzləşdirilmiş sistemlər üçün PVRB mənasızdır və mərkəzləşdirilməmiş sistemlər bütün hesablama resurslarında ciddi şəkildə məhduddur: CPU, yaddaş, saxlama, giriş/çıxış. PVRB-nin layihələndirilməsi, ən azı bəzi canlı blokçeyn üçün bütün tələblərə cavab verən bir şey yaratmaq üçün müxtəlif protokolların birləşməsidir. Bir protokol daha səmərəli hesablayır, lakin RP-lər arasında daha çox mesaj tələb edir, digəri isə çox az mesaj tələb edir, lakin sübut yaratmaq onlarla dəqiqə, hətta saatlar çəkən bir iş ola bilər.

Keyfiyyətli PVRB seçərkən nəzərə almalı olduğunuz amilləri sadalayacağam:

• Kriptoqrafik güc. Sizin PVRB bir biti idarə etmək qabiliyyəti olmadan ciddi şəkildə qərəzsiz olmalıdır. Bəzi sxemlərdə bu belə deyil, ona görə də kriptoqrafı çağırın
• “Sonuncu aktyor” problemi. PVRB bir və ya daha çox RP-yə nəzarət edən təcavüzkarın iki nəticədən birini seçə biləcəyi hücumlara qarşı davamlı olmalıdır.
• Protokol təxribat problemi. PVRB, bir və ya bir neçə RP-yə nəzarət edən təcavüzkarın təsadüfi olub-olmamağa qərar verdiyi və ya zəmanət verilə biləcəyi, ya da buna təsir etmək ehtimalı olan hücumlara davamlı olmalıdır.
• Mesajların sayı problemi. RP-ləriniz blokçeynə minimum mesaj göndərməli və “Mən bəzi məlumat göndərdim, konkret iştirakçıdan cavab gözləyirəm” kimi vəziyyətlər kimi sinxron hərəkətlərdən mümkün qədər çəkinməlidir. P2p şəbəkələrində, xüsusən də coğrafi cəhətdən səpələnmiş şəbəkələrdə, sürətli cavaba arxalanmamalısınız
• Hesablama mürəkkəbliyi problemi. PVRB on-zəncirinin istənilən mərhələsinin yoxlanılması son dərəcə asan olmalıdır, çünki bu, şəbəkənin bütün tam müştəriləri tərəfindən həyata keçirilir. Tətbiq ağıllı müqavilədən istifadə edilməklə həyata keçirilirsə, sürət tələbləri çox sərtdir
• Əlçatanlıq və canlılıq problemi. Sizin PVRB, şəbəkənin bir hissəsinin müəyyən müddət ərzində əlçatmaz olduğu və RP-nin bir hissəsinin sadəcə olaraq fəaliyyətini dayandırdığı vəziyyətlərə qarşı davamlı olmağa çalışmalıdır.
• Etibarlı quraşdırma və ilkin açar paylanması problemi. Əgər PVRB-niz protokolun əsas konfiqurasiyasından istifadə edirsə, bu, ayrı bir böyük və ciddi hekayədir. Burada misal. İştirakçılar protokola başlamazdan əvvəl bir-birlərinə açarlarını söyləməlidirlərsə, iştirakçıların tərkibi dəyişirsə, bu da problemdir.
• İnkişaf problemləri. Tələb olunan dillərdə kitabxanaların olması, onların təhlükəsizliyi və performansı, aşkarlığı, kompleks testləri və s.

Məsələn, eşik BLS imzalarının əhəmiyyətli bir problemi var - işə başlamazdan əvvəl iştirakçılar eşik həddi işləyəcək bir qrup təşkil edərək açarları bir-birinə paylamalıdırlar. Bu o deməkdir ki, mərkəzləşdirilməmiş şəbəkədə ən azı bir mübadilə raundu gözləməli olacaq və yaradılan randın, məsələn, oyunlarda, demək olar ki, real vaxtda lazım olduğunu nəzərə alsaq, bu, bu mərhələdə protokolun təxribatının mümkün olduğunu göstərir. , və eşik sxeminin üstünlükləri itirilir. Bu problem artıq əvvəlkilərdən daha sadədir, lakin yenə də əmanətlərin qoyulması və tələblərə əməl etməyən iştirakçılardan vəsaitlərin çıxarılması (kəsmə) yolu ilə iqtisadi cəhətdən qorunmalı olan hədd qruplarının formalaşdırılması üçün ayrıca prosedurun işlənib hazırlanmasını tələb edir. protokol. Həmçinin, məqbul təhlükəsizlik səviyyəsi ilə BLS yoxlanışı, məsələn, standart EOS və ya Ethereum əməliyyatına uyğun gəlmir - yoxlama üçün sadəcə kifayət qədər vaxt yoxdur. Müqavilə kodu virtual maşın tərəfindən icra edilən WebAssembly və ya EVM-dir. Kriptoqrafik funksiyalar yerli olaraq (hələ) həyata keçirilmir və adi kriptoqrafik kitabxanalardan onlarla dəfə yavaş işləyir. Bir çox protokollar sadəcə əsas həcmə əsaslanan tələblərə cavab vermir, məsələn, RSA üçün 1024 və 2048 bit, Bitcoin və Ethereum-da standart əməliyyat imzasından 4-8 dəfə böyükdür.

Fərqli proqramlaşdırma dillərində tətbiqlərin olması da rol oynayır - bunlardan çox azdır, xüsusən də yeni protokollar üçün. Konsensusa inteqrasiya variantı platforma dilində protokolun yazılmasını tələb edir, ona görə də kodu geth üçün Go, Parity üçün Rust, EOS üçün C++-da axtarmalı olacaqsınız. Hər kəs JavaScript kodunu axtarmalı olacaq və JavaScript və kriptoqrafiya o qədər də yaxın dost olmadığından, indi mütləq növbəti vacib İnternet standartı olduğunu iddia edən WebAssembly kömək edəcək.

Nəticə

Əvvəlkidə ümid edirəm məqalə Mən sizi inandıra bildim ki, blokçeynində təsadüfi ədədlər yaratmaq qeyri-mərkəzləşdirilmiş şəbəkələrin həyatının bir çox aspektləri üçün kritikdir və bu məqalə ilə bu vəzifənin son dərəcə iddialı və çətin olduğunu, lakin yaxşı həllərin artıq mövcud olduğunu göstərdim. Ümumiyyətlə, protokolun son dizaynı yalnız quraşdırmadan tutmuş nasazlıq emulyasiyasına qədər bütün aspektləri nəzərə alan kütləvi testlərdən sonra mümkündür, buna görə də komanda sənədlərində və məqalələrində hazır reseptlər tapmaq çətin olacaq və biz əlbəttə ki, etməyəcəyik. növbəti və ya iki ildə qərar verin "bunu bu şəkildə edin, tam olaraq doğru" yazın.

Əlvida, inkişaf etdirilən blokçeyndəki PVRB-miz üçün Haya, biz həddi BLS imzalarından istifadə etməyi qərara aldıq, PVRB-ni konsensus səviyyəsində həyata keçirməyi planlaşdırırıq, çünki məqbul təhlükəsizlik səviyyəsi ilə ağıllı müqavilələrdə yoxlama hələ mümkün deyil. Mümkündür ki, biz eyni anda iki sxemdən istifadə edək: birincisi, uzunmüddətli random_seed yaratmaq üçün bahalı gizli paylaşım, sonra biz onu deterministik hədd BLS imzalarından istifadə edərək yüksək tezlikli təsadüfi nəsil üçün əsas kimi istifadə edirik, bəlkə də özümüzü yalnız bununla məhdudlaşdıracağıq. sxemlərdən biridir. Təəssüf ki, protokolun nə olacağını əvvəlcədən söyləmək mümkün deyil, yeganə yaxşı cəhət odur ki, elmdə olduğu kimi, mühəndislik problemlərində də mənfi nəticə nəticədir və problemin həllinə yönəlmiş hər bir yeni cəhd onun üçün növbəti addımdır. problemlə məşğul olan hər kəsin araşdırması. Biznes tələblərinə cavab vermək üçün biz spesifik praktik problemi həll edirik - oyun proqramlarını etibarlı entropiya mənbəyi ilə təmin edirik, buna görə də biz blokçeynin özünə, xüsusən də zəncirin sonluğu və şəbəkə idarəçiliyi məsələlərinə diqqət yetirməliyik.

Həqiqi tətbiqlər, çoxsaylı yoxlamalar, yüklər və əlbəttə ki, real hücumlar tərəfindən sınaqdan keçirilməsi üçün kifayət qədər vaxt istifadə edilmiş blokçeynlərdə sübut edilmiş davamlı PVRB görməsək də, lakin mümkün yolların sayı bunu təsdiqləyir. bir həll mövcuddur və bu alqoritmlərdən hansılar problemi həll edəcək. Nəticələri bölüşməkdən və mühəndislərə eyni tırmığı iki dəfə addımlamamağa imkan verən məqalələr və kodlar üçün bu məsələ üzərində işləyən digər komandalara təşəkkür etməkdən məmnun olarıq.

Beləliklə, mərkəzləşdirilməmiş təsadüfi dizayn edən bir proqramçı ilə qarşılaşdığınız zaman diqqətli və qayğıkeş olun və lazım olduqda psixoloji yardım göstərin :)

Mənbə: www.habr.com