შესავალი

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 განხორციელებების აღწერისას, ვერანაირად ვერ აიცილებთ საბოლოო საკითხებს. საბოლოოობა არის მექანიზმი, რომელიც გამოიყენება დეტერმინისტულ კონსენსუსებში, რომელიც იკეტება ბლოკში (და მისკენ მიმავალ ჯაჭვში), რომელიც საბოლოოა და არასოდეს გადაიყრება, თუნდაც პარალელური ჩანგალი მოხდეს. მაგალითად, ბიტკოინში ასეთი მექანიზმი არ არსებობს - თუ თქვენ გამოაქვეყნებთ უფრო დიდი სირთულის ჯაჭვს, ის ჩაანაცვლებს ნებისმიერ ნაკლებად რთულს, მიუხედავად ჯაჭვების სიგრძისა. EOS-ში კი, მაგალითად, ბოლოებია ეგრეთ წოდებული Last Irreversible Blocks, რომლებიც ჩნდება საშუალოდ ყოველ 432 ბლოკში (12*21 + 12*15, წინასწარი ხმა + წინასწარი ჩადება). ეს პროცესი არსებითად ელოდება ბლოკის მწარმოებლების (შემდგომში BP) ხელმოწერების 2/3-ს. როდესაც ჩნდება ჩანგლები, რომლებიც უფრო ძველია, ვიდრე ბოლო LIB, ისინი უბრალოდ განადგურდებიან. ეს მექანიზმი შესაძლებელს ხდის გარანტიას იმისა, რომ ტრანზაქცია შედის ბლოკჩეინში და არასოდეს დაბრუნდება უკან, არ აქვს მნიშვნელობა რა რესურსები აქვს თავდამსხმელს. ასევე, საბოლოო ბლოკები არის ბლოკები, რომლებიც ხელმოწერილია 2/3 BP-ის მიერ Hyperledger, Tendermint და სხვა pBFT-ზე დაფუძნებული კონსენსუსებით. ასევე, აზრი აქვს შედგეს პროტოკოლს საბოლოოობის უზრუნველსაყოფად, როგორც დანამატი კონსენსუსის შესახებ, რადგან მას შეუძლია ასინქრონულად იმუშაოს ბლოკების წარმოებასთან და გამოქვეყნებასთან. აი ერთი კარგი სტატიის Ethereum-ში საბოლოოობის შესახებ.

საბოლოოობა ძალზე მნიშვნელოვანია მომხმარებლებისთვის, რომლებიც ამის გარეშე შეიძლება აღმოჩნდნენ "ორმაგი დახარჯვის" თავდასხმის მსხვერპლი, სადაც BP "ინახავს" ბლოკებს და აქვეყნებს მათ მას შემდეგ, რაც ქსელი "ხედავს" კარგ ტრანზაქციას. თუ საბოლოო არ არის, მაშინ გამოქვეყნებული ჩანგალი ბლოკს ცვლის "კარგი" ტრანზაქციის სხვაგან, "ცუდი" ჩანგალით, რომელშიც იგივე თანხები გადაირიცხება თავდამსხმელის მისამართზე. PVRB-ის შემთხვევაში, საბოლოოობის მოთხოვნები კიდევ უფრო მკაცრია, რადგან PVRB-სთვის ჩანგლების აშენება ნიშნავს თავდამსხმელს შესაძლებლობას მოამზადოს რამდენიმე შემთხვევითი ვარიანტი, რათა გამოაქვეყნოს ყველაზე მომგებიანი და შესაძლო თავდასხმის დროის შეზღუდვა არის კარგი გამოსავალი.

აქედან გამომდინარე, საუკეთესო ვარიანტია PVRB და საბოლოო ჯამში ერთ პროტოკოლში გაერთიანება - შემდეგ დასრულებული ბლოკი = დასრულებული შემთხვევითი და ეს არის ზუსტად ის, რის მისაღებადაც გვჭირდებოდა. ახლა მოთამაშეები მიიღებენ გარანტირებულ შემთხვევითობას N წამში და დარწმუნებული იქნებიან, რომ მისი უკან დაბრუნება ან ხელახლა დაკვრა შეუძლებელია.

კონსენსუსის ინტეგრირებული ვარიანტი კარგია:

• ასინქრონული განხორციელების შესაძლებლობა ბლოკების წარმოებასთან დაკავშირებით - ბლოკები იწარმოება ჩვეულებისამებრ, მაგრამ ამის პარალელურად, PVRB პროტოკოლმა შეიძლება იმუშაოს, რომელიც არ წარმოქმნის შემთხვევითობას ყველა ბლოკისთვის.
• მძიმე კრიპტოგრაფიის განხორციელების უნარიც კი, სმარტ კონტრაქტებზე დაწესებული შეზღუდვების გარეშე
• შეტყობინებების გაცვლის უფრო სწრაფად ორგანიზების შესაძლებლობა, ვიდრე ტრანზაქციები შედის ბლოკჩეინში, მაგალითად, პროტოკოლის ნაწილს შეუძლია იმუშაოს კვანძებს შორის ქსელში შეტყობინებების განაწილების გარეშე.

მას ასევე აქვს უარყოფითი მხარეები:

• სირთულეები ტესტირებასა და განვითარებაში - თქვენ მოგიწევთ ქსელის შეცდომების, დაკარგული კვანძების, ქსელის მყარი ჩანგლების მიბაძვა
• დანერგვის შეცდომებს სჭირდება ქსელის მყარი ფორკი

PVRB დანერგვის ორივე მეთოდს აქვს სიცოცხლის უფლება, მაგრამ ჭკვიან კონტრაქტებზე დანერგვა თანამედროვე ბლოკჩეინებში ჯერ კიდევ საკმაოდ შეზღუდულია გამოთვლითი რესურსებით და სერიოზულ კრიპტოგრაფიაზე გადასვლა ხშირად უბრალოდ შეუძლებელია. და ჩვენ დაგვჭირდება სერიოზული კრიპტოგრაფია, როგორც ქვემოთ იქნება ნაჩვენები. მიუხედავად იმისა, რომ ეს პრობლემა აშკარად დროებითია, კონტრაქტებში სერიოზული კრიპტოგრაფიაა საჭირო მრავალი პრობლემის გადასაჭრელად და ის თანდათან ჩნდება (მაგალითად, სისტემური კონტრაქტები zkSNARK-ებისთვის Ethereum-ში)

ბლოკჩეინი, რომელიც უზრუნველყოფს გამჭვირვალე და საიმედო პროტოკოლის შეტყობინებების არხს, ამას უფასოდ არ აკეთებს. ნებისმიერმა დეცენტრალიზებულმა პროტოკოლმა უნდა გაითვალისწინოს Sybil-ის შეტევის შესაძლებლობა; ნებისმიერი ქმედება შეიძლება განხორციელდეს მრავალი ანგარიშის შეთანხმებული ძალებით, ამიტომ, დიზაინის შექმნისას აუცილებელია გავითვალისწინოთ თავდამსხმელების შესაძლებლობა შექმნან პროტოკოლის თვითნებური რაოდენობა. მონაწილეები, რომლებიც მოქმედებენ შეთქმულებაში.

PVRB და ბლოკის ცვლადები.

მე არ მოვიტყუე, როცა ვთქვი, რომ ჯერ არავის დაუნერგავს კარგი PVRB, რომელიც გამოცდილია მრავალი სათამაშო აპლიკაციით, ბლოკჩეინში. მაშინ საიდან მოდის ამდენი სათამაშო აპლიკაცია Ethereum-სა და EOS-ზე? ეს მე ისევე მიკვირს, როგორც შენ, საიდან მოიტანეს ამდენი "მუდმივი" შემთხვევითობა სრულიად დეტერმინისტულ გარემოში?

ბლოკჩეინში შემთხვევითობის მიღების საყვარელი გზა არის ბლოკიდან რაიმე სახის „არაპროგნოზირებადი“ ინფორმაციის აღება და მასზე დაყრდნობით შემთხვევითი ინფორმაციის გაკეთება - უბრალოდ ერთი ან მეტი მნიშვნელობის ჰეშირებით. კარგი სტატია ასეთი სქემების პრობლემების შესახებ აქ. თქვენ შეგიძლიათ აიღოთ ბლოკში ნებისმიერი „არაპროგნოზირებადი“ მნიშვნელობა, მაგალითად, ბლოკის ჰეში, ტრანზაქციების რაოდენობა, ქსელის სირთულე და სხვა წინასწარ უცნობი მნიშვნელობები. შემდეგ გახეხეთ ისინი, ერთი ან მეტი, და, თეორიულად, თქვენ უნდა მიიღოთ რეალური შემთხვევითი. თქვენ შეგიძლიათ დაამატოთ ისიც კი, რომ თქვენი სქემა არის „პოსტ-კვანტური უსაფრთხო“ (რადგან არის კვანტური მტკიცებულების ჰეშის ფუნქციები :)).

მაგრამ პოსტ-კვანტური უსაფრთხო ჰეშებიც კი არ არის საკმარისი, სამწუხაროდ. საიდუმლო მდგომარეობს PVRB-ის მოთხოვნებში, შეგახსენებთ მათ წინა სტატიიდან:

1. შედეგს უნდა ჰქონდეს დასამტკიცებლად ერთიანი განაწილება, ანუ დაფუძნებული უნდა იყოს დასამტკიცებლად ძლიერ კრიპტოგრაფიაზე.
2. შედეგის რომელიმე ნაწილის კონტროლი შეუძლებელია. შედეგად, შედეგის წინასწარ პროგნოზირება შეუძლებელია.
3. თქვენ არ შეგიძლიათ გენერაციის პროტოკოლის საბოტაჟი პროტოკოლში არ მონაწილეობით ან ქსელის გადატვირთვით თავდასხმის შეტყობინებებით.
4. ყოველივე ზემოთქმული უნდა იყოს მდგრადი პროტოკოლის არაკეთილსინდისიერი მონაწილეთა დასაშვები რაოდენობის შეთქმულების მიმართ (მაგალითად, მონაწილეთა 1/3).

ამ შემთხვევაში დაკმაყოფილებულია მხოლოდ მოთხოვნა 1 და მოთხოვნა 2 არ არის დაკმაყოფილებული. ბლოკიდან არაპროგნოზირებადი მნიშვნელობების ჰეშირებით მივიღებთ ერთგვაროვან განაწილებას და კარგ შემთხვევითობას. მაგრამ BP-ს მაინც აქვს შესაძლებლობა "გამოაქვეყნოს ბლოკი თუ არა". ამრიგად, BP-ს შეუძლია მინიმუმ ორი შემთხვევითი ვარიანტიდან აირჩიოს: „საკუთარი“ და ის, რომელიც გამოვა, თუ ვინმე სხვა გააკეთებს ბლოკს. BP-ს შეუძლია წინასწარ „ჩათვალოს“ რა მოხდება, თუ ის გამოაქვეყნებს ბლოკს და უბრალოდ გადაწყვეტს ამის გაკეთებას თუ არა. ამრიგად, რულეტში, მაგალითად, „ლუწი-კენტი“ ან „წითელი/შავი“ თამაშისას, მას შეუძლია ბლოკის გამოქვეყნება მხოლოდ იმ შემთხვევაში, თუ დაინახავს გამარჯვებას. ეს ასევე უვარგისს ხდის, მაგალითად, ბლოკ ჰეშის „მომავლიდან“ გამოყენების სტრატეგიას. ამ შემთხვევაში, ისინი ამბობენ, რომ ”გამოიყენება შემთხვევითი, რომელიც მიიღება მიმდინარე მონაცემების და მომავალი ბლოკის ჰეშირებით, რომლის სიმაღლეა, მაგალითად, N + 42, სადაც N არის მიმდინარე ბლოკის სიმაღლე. ეს ოდნავ აძლიერებს სქემას, მაგრამ მაინც საშუალებას აძლევს BP-ს, თუმცა მომავალში, აირჩიოს დაბლოკოს თუ გამოაქვეყნოს.

BP პროგრამული უზრუნველყოფა ამ შემთხვევაში უფრო რთული ხდება, მაგრამ არც ისე ბევრი. უბრალოდ, ბლოკში ტრანზაქციის ვალიდაციის და ჩართვისას ხდება სწრაფი შემოწმება, იქნება თუ არა მოგება და, შესაძლოა, ერთი ტრანზაქციის პარამეტრის შერჩევა მოგების მაღალი ალბათობის მისაღებად. ამავდროულად, მსგავსი მანიპულაციებისთვის ჭკვიანი BP-ის დაჭერა თითქმის შეუძლებელია; ყოველ ჯერზე შეგიძლიათ გამოიყენოთ ახალი მისამართები და ნელ-ნელა მოიგოთ ეჭვის გაჩენის გარეშე.

ასე რომ, ბლოკიდან ინფორმაციის გამოყენების მეთოდები არ არის შესაფერისი, როგორც PVRB-ის უნივერსალური განხორციელება. შეზღუდული ვერსიით, ფსონების ზომებზე შეზღუდვებით, მოთამაშეთა რაოდენობის შეზღუდვით და/ან KYC რეგისტრაციაზე (იმისთვის, რომ ერთი მოთამაშე არ გამოიყენოს მრავალი მისამართი), ეს სქემები შეიძლება იმუშაოს მცირე თამაშებზე, მაგრამ მეტი არაფერი.

PVRB და commit-revel.

კარგი, ჰეშირების და ბლოკის ჰეშის და სხვა ცვლადების შედარებით არაპროგნოზირებადობის წყალობით. თუ თქვენ მოაგვარებთ წინამორბედ მაინერების პრობლემას, უნდა მიიღოთ რაიმე უფრო შესაფერისი. მოდით დავუმატოთ მომხმარებლები ამ სქემას - მათაც ახდენენ გავლენას შემთხვევითობაზე: ტექნიკური მხარდაჭერის ნებისმიერი თანამშრომელი გეტყვით, რომ IT სისტემებში ყველაზე შემთხვევითი რამ არის მომხმარებლების ქმედებები :)

გულუბრყვილო სქემა, როდესაც მომხმარებლები უბრალოდ აგზავნიან შემთხვევით რიცხვებს და შედეგი გამოითვლება, როგორც, მაგალითად, მათი ჯამის ჰეში, არ არის შესაფერისი. ამ შემთხვევაში, ბოლო მოთამაშეს შეუძლია, საკუთარი შემთხვევითი არჩევით, გააკონტროლოს რა შედეგი იქნება. სწორედ ამიტომ გამოიყენება ძალიან ფართოდ გამოყენებული commit-reveal ნიმუში. მონაწილეები ჯერ აგზავნიან ჰეშებს თავიანთი რანდომებიდან (კომიტაციები), შემდეგ კი თავად ხსნიან შემთხვევითობას (ავლენს). "გამოვლენის" ფაზა იწყება მხოლოდ მას შემდეგ, რაც შეგროვდება საჭირო ვალდებულებები, ასე რომ მონაწილეებს შეუძლიათ გაგზავნონ ზუსტად შემთხვევითი ჰეში, საიდანაც ადრე გაგზავნეს. ახლა მოდით ეს ყველაფერი ბლოკის პარამეტრებთან ერთად გავაერთიანოთ და უკეთესია, ვიდრე მომავლისგან აღებული (შემთხვევითობა მხოლოდ ერთ მომავალ ბლოკშია შესაძლებელი), ხოლო ვოილა - შემთხვევითობა მზად არის! ახლა ნებისმიერი მოთამაშე გავლენას ახდენს მიღებულ შემთხვევითობაზე და შეუძლია მავნე BP-ის „დამარცხება“ საკუთარი, წინასწარ უცნობი შემთხვევითობით... თქვენ ასევე შეგიძლიათ დაამატოთ დაცვა პროტოკოლის საბოტაჟისგან, თუ არ გახსნით მას გამოვლენის ეტაპზე - უბრალოდ. განხორციელებისას ტრანზაქციაზე გარკვეული თანხის დამაგრების მოთხოვნით - გარანტიის დეპოზიტი, რომელიც დაბრუნდება მხოლოდ გამოვლენის პროცედურის დროს. ამ შემთხვევაში ჩადენა და არ გამჟღავნება წამგებიანი იქნება.

ეს კარგი მცდელობა იყო და ასეთი სქემები ასევე არსებობს სათამაშო DApps-ში, მაგრამ სამწუხაროდ, ეს ისევ არ არის საკმარისი. ახლა არა მხოლოდ მაინერს, არამედ პროტოკოლის ნებისმიერ მონაწილესაც შეუძლია გავლენა მოახდინოს შედეგზე. ჯერ კიდევ შესაძლებელია თავად ღირებულების კონტროლი, ნაკლები ცვალებადობით და დანახარჯით, მაგრამ, როგორც მაინერის შემთხვევაში, თუ ნახაზის შედეგები უფრო ღირებულია, ვიდრე PVRB პროტოკოლში მონაწილეობის საფასური, მაშინ შემთხვევითი -პროდიუსერს (RP) შეუძლია გადაწყვიტოს გამოავლინოს თუ არა და მაინც შეუძლია აირჩიოს მინიმუმ ორი შემთხვევითი ვარიანტიდან.
მაგრამ შესაძლებელი გახდა მათი დასჯა, ვინც ჩაიდინა და არ ამხელს და ეს სქემა გამოგადგებათ. მისი სიმარტივე სერიოზული უპირატესობაა - უფრო სერიოზული პროტოკოლები მოითხოვს ბევრად უფრო მძლავრ გამოთვლებს.

PVRB და დეტერმინისტული ხელმოწერები.

არსებობს კიდევ ერთი გზა, რათა აიძულოთ RP-ს მიაწოდოს ფსევდო შემთხვევითი რიცხვი, რომელზეც მას არ შეუძლია გავლენა მოახდინოს, თუ მას მიეწოდება „პრეიმიჯი“ - ეს არის დეტერმინისტული ხელმოწერა. ასეთი ხელმოწერა არის, მაგალითად, RSA და არ არის ECS. თუ RP-ს აქვს წყვილი გასაღებები: RSA და ECC და ის ხელს აწერს გარკვეულ მნიშვნელობას თავისი პირადი გასაღებით, მაშინ RSA-ს შემთხვევაში ის მიიღებს ერთ და მხოლოდ ერთ ხელმოწერას, ხოლო ECS-ის შემთხვევაში მას შეუძლია შექმნას ნებისმიერი რაოდენობის სხვადასხვა მოქმედი ხელმოწერები. ეს იმიტომ ხდება, რომ ECS ხელმოწერის შექმნისას გამოიყენება შემთხვევითი რიცხვი, რომელიც არჩეულია ხელმომწერის მიერ და მისი არჩევა შესაძლებელია ნებისმიერი გზით, რაც ხელმომწერს აძლევს შესაძლებლობას აირჩიოს რამდენიმე ხელმოწერიდან ერთი. RSA-ს შემთხვევაში: „ერთი შეყვანის მნიშვნელობა“ + „ერთი გასაღების წყვილი“ = „ერთი ხელმოწერა“. შეუძლებელია იმის პროგნოზირება, თუ რა ხელმოწერას მიიღებს სხვა RP, ამიტომ PVRB დეტერმინისტული ხელმოწერებით შეიძლება ორგანიზებული იყოს რამდენიმე მონაწილის RSA ხელმოწერების კომბინაციით, რომლებმაც ხელი მოაწერეს იმავე მნიშვნელობას. მაგალითად, წინა შემთხვევითი. ეს სქემა დაზოგავს უამრავ რესურსს, რადგან ხელმოწერები არის როგორც პროტოკოლის მიხედვით სწორი ქცევის დადასტურება, ასევე შემთხვევითობის წყარო.

თუმცა, დეტერმინისტული ხელმოწერების შემთხვევაშიც კი, სქემა კვლავ დაუცველია „ბოლო აქტორის“ პრობლემის მიმართ. ბოლო მონაწილეს მაინც შეუძლია გადაწყვიტოს გამოაქვეყნოს თუ არა ხელმოწერა, რითაც აკონტროლებს შედეგს. თქვენ შეგიძლიათ შეცვალოთ სქემა, დაამატოთ მასში ბლოკის ჰეშები, გააკეთოთ რაუნდები ისე, რომ შედეგის წინასწარ პროგნოზირება შეუძლებელია, მაგრამ ყველა ეს ტექნიკა, თუნდაც მრავალი მოდიფიკაციის გათვალისწინებით, მაინც გადაუჭრელ ტოვებს კოლექტივზე ერთი მონაწილის გავლენის პრობლემას. იწვევს არასანდო გარემოს და შეუძლია მუშაობა მხოლოდ ეკონომიკური და დროის შეზღუდვების პირობებში. გარდა ამისა, RSA გასაღებების ზომა (1024 და 2048 ბიტი) საკმაოდ დიდია, ხოლო ბლოკჩეინ ტრანზაქციების ზომა უაღრესად მნიშვნელოვანი პარამეტრია. როგორც ჩანს, პრობლემის გადაჭრის მარტივი გზა არ არსებობს, მოდით გადავიდეთ.

PVRB და საიდუმლო გაზიარების სქემები

კრიპტოგრაფიაში არსებობს სქემები, რომლებიც საშუალებას აძლევს ქსელს შეათანხმოს ერთ და მხოლოდ ერთ PVRB მნიშვნელობაზე, მაშინ როცა ასეთი სქემები მდგრადია ზოგიერთი მონაწილის ნებისმიერი მავნე ქმედების მიმართ. ერთი სასარგებლო პროტოკოლი, რომლის გაცნობაც ღირს, არის შამირის საიდუმლო გაზიარების სქემა. ის ემსახურება საიდუმლოს (მაგალითად, საიდუმლო გასაღების) რამდენიმე ნაწილად დაყოფას და ამ ნაწილების N მონაწილეებს განაწილებას. საიდუმლო ნაწილდება ისე, რომ N-დან M ნაწილები საკმარისია მის აღსადგენად და ეს შეიძლება იყოს ნებისმიერი M ნაწილი. თუ თითებზე, მაშინ უცნობი ფუნქციის გრაფიკის მქონე, მონაწილეები ცვლიან ქულებს გრაფიკზე და M ქულების მიღების შემდეგ, შესაძლებელია მთელი ფუნქციის აღდგენა.
კარგი ახსნაა მოცემული ვიკი მაგრამ მასთან თამაში პრაქტიკულად იმისთვის, რომ პროტოკოლი თქვენს თავში დაუკრათ, სასარგებლოა დემო გვერდი.

თუ FSSS (Fiat-Shamir Secret Sharing) სქემა გამოყენებული იქნებოდა მისი სუფთა სახით, ეს იქნებოდა ურღვევი PVRB. უმარტივესი ფორმით, პროტოკოლი შეიძლება ასე გამოიყურებოდეს:

• თითოეული მონაწილე ქმნის საკუთარ შემთხვევითობას და ანაწილებს მისგან სხვა მონაწილეებს
• თითოეული მონაწილე ავლენს სხვა მონაწილეთა საიდუმლოების თავის ნაწილს
• თუ მონაწილეს აქვს M-ზე მეტი აქცია, მაშინ ამ მონაწილის რაოდენობა შეიძლება გამოითვალოს და ის უნიკალური იქნება, გამოვლენილი მონაწილეების სიმრავლის მიუხედავად.
• გამოვლენილი შემთხვევითობების კომბინაცია არის სასურველი PVRB

აქ ცალკეული მონაწილე აღარ ახდენს გავლენას პროტოკოლის შედეგებზე, გარდა იმ შემთხვევებისა, როდესაც შემთხვევითობის გამჟღავნების ზღვრის მიღწევა მხოლოდ მასზეა დამოკიდებული. ამიტომ, ეს პროტოკოლი, თუ არსებობს პროტოკოლზე მომუშავე RP-ების საჭირო პროპორცია და ხელმისაწვდომია, მუშაობს, ახორციელებს კრიპტოგრაფიული სიძლიერის მოთხოვნებს და მდგრადია „ბოლო მოქმედი“ პრობლემის მიმართ.

ეს შეიძლება იყოს იდეალური ვარიანტი, ეს PVRB სქემა, რომელიც დაფუძნებულია Fiat-Shamir-ის საიდუმლო გაზიარებაზე, აღწერილია მაგალითად ამ სტატია. მაგრამ, როგორც ზემოთ აღინიშნა, თუ თქვენ ცდილობთ მის გამოყენებას ბლოკჩეინში, ტექნიკური შეზღუდვები გამოჩნდება. აქ არის EOS სმარტ კონტრაქტში პროტოკოლის სატესტო განხორციელების მაგალითი და მისი ყველაზე მნიშვნელოვანი ნაწილი - გამოქვეყნებული წილის მონაწილის შემოწმება: კოდი. კოდიდან ხედავთ, რომ მტკიცებულების ვალიდაცია მოითხოვს რამდენიმე სკალარული გამრავლებას და გამოყენებული რიცხვები ძალიან დიდია. უნდა გვესმოდეს, რომ ბლოკჩეინებში გადამოწმება ხდება იმ მომენტში, როდესაც ბლოკ-პროდიუსერი ამუშავებს ტრანზაქციას და ზოგადად, ნებისმიერმა მონაწილემ ადვილად უნდა გადაამოწმოს პროტოკოლის სისწორე, ამიტომ გადამოწმების ფუნქციის სიჩქარის მოთხოვნები ძალიან სერიოზულია. . ამ ვარიანტში, ვარიანტი არაეფექტური აღმოჩნდა, რადგან გადამოწმება არ ჯდებოდა ტრანზაქციის ლიმიტის ფარგლებში (0.5 წამი).

გადამოწმების ეფექტურობა არის ერთ-ერთი ყველაზე მნიშვნელოვანი მოთხოვნა ბლოკჩეინში, ზოგადად, ნებისმიერი მოწინავე კრიპტოგრაფიული სქემის გამოყენებისთვის. მტკიცებულებების შექმნა, შეტყობინებების მომზადება - ეს პროცედურები შეიძლება განხორციელდეს ჯაჭვის გარეშე და შესრულდეს მაღალი ხარისხის კომპიუტერებზე, მაგრამ ვერიფიკაციის გვერდის ავლა შეუძლებელია - ეს არის კიდევ ერთი მნიშვნელოვანი მოთხოვნა PVRB-სთვის.

PVRB და ბარიერი ხელმოწერები

საიდუმლო გაზიარების სქემის გაცნობის შემდეგ, ჩვენ აღმოვაჩინეთ პროტოკოლების მთელი კლასი, რომელიც გაერთიანებულია საკვანძო სიტყვით „ბარიერი“. როდესაც ზოგიერთი ინფორმაციის გამჟღავნება მოითხოვს N-დან M პატიოსანი მონაწილეების მონაწილეობას, ხოლო პატიოსანი მონაწილეთა ნაკრები შეიძლება იყოს N-ის თვითნებური ქვეჯგუფი, ჩვენ ვსაუბრობთ „ზღურბლზე“ სქემებზე. სწორედ ისინი გვაძლევენ საშუალებას გავუმკლავდეთ „ბოლო მსახიობის“ პრობლემას, ახლა თუ თავდამსხმელი საიდუმლოს თავის ნაწილს არ გაუმჟღავნებს, ამას სხვა, პატიოსანი მონაწილე გააკეთებს მის ნაცვლად. ეს სქემები იძლევა შეთანხმებას ერთ და მხოლოდ ერთ მნიშვნელობაზე, მაშინაც კი, თუ პროტოკოლი დარღვეულია ზოგიერთი მონაწილეს მიერ.

დეტერმინისტული ხელმოწერებისა და ბარიერის სქემების ერთობლიობამ შესაძლებელი გახადა PVRB-ს განხორციელებისთვის ძალიან მოსახერხებელი და პერსპექტიული სქემის შემუშავება - ეს არის დეტერმინისტული ბარიერი ხელმოწერები. Აქ სტატიის ბარიერის ხელმოწერების სხვადასხვა გამოყენების შესახებ და აქ არის კიდევ ერთი კარგი დიდი ხნის განმავლობაში ტირედან.

ბოლო სტატია აღწერს BLS ხელმოწერებს (BLS ნიშნავს Boneh-Lynn-Sacham, აქ სტატია), რომლებსაც აქვთ ძალიან მნიშვნელოვანი და ძალიან მოსახერხებელი ხარისხი პროგრამისტებისთვის - საჯარო, საიდუმლო, საჯარო გასაღებები და BLS ხელმოწერები შეიძლება გაერთიანდეს ერთმანეთთან მარტივი მათემატიკური ოპერაციების გამოყენებით, ხოლო მათი კომბინაციები რჩება მოქმედი გასაღებები და ხელმოწერები, რაც საშუალებას მოგცემთ მარტივად დააგროვოთ ბევრი. ხელმოწერები ერთში და ბევრი საჯარო გასაღები ერთში. ისინი ასევე განმსაზღვრელია და აწარმოებენ იგივე შედეგს ერთი და იგივე შეყვანის მონაცემებისთვის. ამ ხარისხის წყალობით, BLS ხელმოწერების კომბინაციები თავისთავად მოქმედი გასაღებებია, რაც საშუალებას იძლევა განხორციელდეს ვარიანტი, რომელშიც N-დან M მონაწილეები აწარმოებენ ერთ და მხოლოდ ერთ ხელმოწერას, რომელიც არის განმსაზღვრელი, საჯაროდ შემოწმებადი და არაპროგნოზირებადი, სანამ ის არ გაიხსნება Mth-ით. მონაწილე .

ბარიერის BLS ხელმოწერების სქემაში, თითოეული მონაწილე ხელს აწერს რაღაცას BLS-ის გამოყენებით (მაგალითად, წინა შემთხვევითი), და საერთო ბარიერის ხელმოწერა არის სასურველი შემთხვევითი. BLS ხელმოწერების კრიპტოგრაფიული თვისებები აკმაყოფილებს შემთხვევითი ხარისხის მოთხოვნებს, ზღვრული ნაწილი იცავს "ბოლო მოქმედისაგან" და გასაღებების უნიკალური კომბინირებულობა შესაძლებელს ხდის მრავალი სხვა საინტერესო ალგორითმის დანერგვას, რომლებიც, მაგალითად, პროტოკოლის შეტყობინებების ეფექტური აგრეგაციის საშუალებას იძლევა. .

ასე რომ, თუ თქვენ აშენებთ PVRB-ს თქვენს ბლოკჩეინზე, თქვენ სავარაუდოდ დაასრულებთ BLS ბარიერის ხელმოწერების სქემით, რამდენიმე პროექტი უკვე იყენებს მას. მაგალითად, DFinity (აქ ნიშნული, რომელიც ახორციელებს წრედს და აქ დამადასტურებელი საიდუმლო გაზიარების განხორციელების მაგალითი), ან Keep.network (აქ არის მათი შემთხვევითი შუქურა ყვითელი ქაღალდი, მაგრამ მაგალითად ჭკვიანი კონტრაქტი ემსახურება პროტოკოლს).

PVRB-ის დანერგვა

სამწუხაროდ, ჩვენ ჯერ კიდევ ვერ ვხედავთ PVRB ბლოკჩეინებში დანერგილ მზა პროტოკოლს, რომელმაც დაამტკიცა მისი უსაფრთხოება და სტაბილურობა. მიუხედავად იმისა, რომ თავად პროტოკოლები მზადაა, მათი ტექნიკურად გამოყენება არსებულ გადაწყვეტილებებზე ადვილი არ არის. ცენტრალიზებული სისტემებისთვის PVRB-ს აზრი არ აქვს და დეცენტრალიზებული მკაცრად შეზღუდულია ყველა გამოთვლით რესურსში: CPU, მეხსიერება, საცავი, I/O. PVRB-ის დაპროექტება არის სხვადასხვა პროტოკოლების ერთობლიობა, რათა შეიქმნას რაღაც, რომელიც აკმაყოფილებს ყველა მოთხოვნას მინიმუმ რამდენიმე სიცოცხლისუნარიანი ბლოკჩეინისთვის. ერთი პროტოკოლი ითვლის უფრო ეფექტურად, მაგრამ მოითხოვს მეტ შეტყობინებას RP-ებს შორის, ხოლო მეორე მოითხოვს ძალიან ცოტა შეტყობინებებს, მაგრამ მტკიცებულების შექმნა შეიძლება იყოს ამოცანა, რომელსაც ათეულ წუთს ან საათებსაც კი დასჭირდება.

მე ჩამოვთვლი ფაქტორებს, რომლებიც უნდა გაითვალისწინოთ ხარისხის PVRB არჩევისას:

• კრიპტოგრაფიული სიძლიერე. თქვენი PVRB უნდა იყოს მკაცრად მიუკერძოებელი, ერთი ბიტის კონტროლის გარეშე. ზოგიერთ სქემაში ეს ასე არ არის, ამიტომ დარეკეთ კრიპტოგრაფს
• "ბოლო მსახიობის" პრობლემა. თქვენი PVRB უნდა იყოს მდგრადი შეტევების მიმართ, სადაც თავდამსხმელს, რომელიც აკონტროლებს ერთ ან მეტ RP-ს, შეუძლია აირჩიოს ორი შედეგიდან ერთი.
• პროტოკოლის დივერსიის პრობლემა. თქვენი PVRB უნდა იყოს მდგრადი თავდასხმების მიმართ, როდესაც თავდამსხმელი, რომელიც აკონტროლებს ერთ ან მეტ RP-ს, გადაწყვეტს იყოს თუ არა შემთხვევითი და შეიძლება იყოს გარანტირებული ან მოცემული ალბათობით, მოახდინოს გავლენა ამაზე.
• შეტყობინებების რაოდენობის პრობლემა. თქვენმა RP-ებმა უნდა გაუგზავნონ მინიმალური შეტყობინებები ბლოკჩეინში და მაქსიმალურად მოერიდონ სინქრონულ ქმედებებს, როგორიცაა სიტუაციები, როგორიცაა „მე გავგზავნე გარკვეული ინფორმაცია, ველოდები პასუხს კონკრეტული მონაწილისგან“. p2p ქსელებში, განსაკუთრებით გეოგრაფიულად გაფანტულ ქსელებში, არ უნდა გქონდეთ იმედი სწრაფ პასუხზე
• გამოთვლითი სირთულის პრობლემა. PVRB-ის ჯაჭვის ნებისმიერი ეტაპის შემოწმება უნდა იყოს ძალიან მარტივი, რადგან მას ასრულებენ ქსელის ყველა სრული კლიენტი. თუ განხორციელება ხდება ჭკვიანი კონტრაქტის გამოყენებით, მაშინ სიჩქარის მოთხოვნები ძალიან მკაცრია
• ხელმისაწვდომობისა და სიცოცხლისუნარიანობის პრობლემა. თქვენი PVRB უნდა შეეცადოს იყოს მდგრადი სიტუაციების მიმართ, როდესაც ქსელის ნაწილი გარკვეული პერიოდის განმავლობაში მიუწვდომელია და RP-ის ნაწილი უბრალოდ წყვეტს მუშაობას.
• სანდო დაყენების და გასაღების საწყისი განაწილების პრობლემა. თუ თქვენი PVRB იყენებს პროტოკოლის პირველად დაყენებას, მაშინ ეს ცალკე დიდი და სერიოზული ამბავია. Აქ მაგალითად. თუ მონაწილეებმა პროტოკოლის დაწყებამდე უნდა აცნობონ ერთმანეთს გასაღებები, ეს ასევე პრობლემაა, თუ შეიცვლება მონაწილეთა შემადგენლობა
• განვითარების პრობლემები. ბიბლიოთეკების ხელმისაწვდომობა საჭირო ენებზე, მათი უსაფრთხოება და შესრულება, საჯაროობა, რთული ტესტები და ა.შ.

მაგალითად, ბარიერის BLS ხელმოწერებს აქვს მნიშვნელოვანი პრობლემა - მუშაობის დაწყებამდე მონაწილეებმა უნდა დაურიგონ გასაღებები ერთმანეთს, მოაწყონ ჯგუფი, რომლის ფარგლებშიც იმუშავებს ბარიერი. ეს ნიშნავს, რომ დეცენტრალიზებულ ქსელში გაცვლის მინიმუმ ერთი რაუნდი უნდა დაელოდო და იმის გათვალისწინებით, რომ გენერირებული რენდი, მაგალითად, აუცილებელია თამაშებში, თითქმის რეალურ დროში, ეს ნიშნავს, რომ ამ ეტაპზე შესაძლებელია პროტოკოლის საბოტაჟი. , და ბარიერის სქემის უპირატესობები იკარგება . ეს პრობლემა უკვე უფრო მარტივია, ვიდრე წინა, მაგრამ მაინც მოითხოვს ცალკეული პროცედურის შემუშავებას ზღვრული ჯგუფების ფორმირებისთვის, რომლებიც უნდა იყოს დაცული ეკონომიურად, დეპოზიტებისა და სახსრების გატანის გზით (შემცირებით) მონაწილეებისგან, რომლებიც არ იცავენ ოქმი. ასევე, უსაფრთხოების მისაღები დონით BLS გადამოწმება უბრალოდ არ ჯდება, მაგალითად, სტანდარტულ EOS ან Ethereum ტრანზაქციაში - უბრალოდ არ არის საკმარისი დრო გადამოწმებისთვის. კონტრაქტის კოდი არის WebAssembly ან EVM, რომელიც შესრულებულია ვირტუალური მანქანით. კრიპტოგრაფიული ფუნქციები არ არის განხორციელებული ბუნებრივად (ჯერჯერობით) და მუშაობს ათჯერ უფრო ნელა, ვიდრე ჩვეულებრივი კრიპტოგრაფიული ბიბლიოთეკები. ბევრი პროტოკოლი არ აკმაყოფილებს მოთხოვნებს უბრალოდ გასაღების მოცულობაზე დაყრდნობით, მაგალითად 1024 და 2048 ბიტი RSA-სთვის, 4-8-ჯერ მეტი ვიდრე სტანდარტული ტრანზაქციის ხელმოწერა Bitcoin-სა და Ethereum-ში.

პროგრამირების სხვადასხვა ენაზე განხორციელების არსებობა ასევე თამაშობს როლს - რომელთაგან ცოტაა, განსაკუთრებით ახალი პროტოკოლებისთვის. კონსენსუსში ინტეგრაციის ვარიანტი მოითხოვს პროტოკოლის დაწერას პლატფორმის ენაზე, ასე რომ თქვენ უნდა მოძებნოთ კოდი Go for geth-ში, Rust-ში Parity-ში, C++-ში EOS-ში. ყველას მოუწევს JavaScript კოდის ძებნა და რადგან JavaScript და კრიპტოგრაფია არ არის განსაკუთრებით ახლო მეგობრები, WebAssembly დაგეხმარებათ, რომელიც ახლა ნამდვილად აცხადებს, რომ არის შემდეგი მნიშვნელოვანი ინტერნეტ სტანდარტი.

დასკვნა

წინას იმედი მაქვს მუხლი მე მოვახერხე დაგარწმუნოთ, რომ ბლოკჩეინზე შემთხვევითი რიცხვების გენერირება კრიტიკულია დეცენტრალიზებული ქსელების ცხოვრების მრავალი ასპექტისთვის და ამ სტატიით ვაჩვენე, რომ ეს ამოცანა უკიდურესად ამბიციური და რთულია, მაგრამ კარგი გადაწყვეტილებები უკვე არსებობს. ზოგადად, პროტოკოლის საბოლოო დიზაინი შესაძლებელია მხოლოდ მასიური ტესტების ჩატარების შემდეგ, რომელიც ითვალისწინებს ყველა ასპექტს დაყენებიდან შეცდომების ემულაციამდე, ასე რომ თქვენ ნაკლებად სავარაუდოა, რომ იპოვოთ მზა რეცეპტები გუნდურ თეთრ ქაღალდებსა და სტატიებში, და ჩვენ ნამდვილად არ ვიპოვით. გადაწყვიტეთ მომდევნო ერთი-ორი წლის განმავლობაში დაწერეთ „გააკეთე ასე, ზუსტად“.

ნახვამდის, ჩვენი PVRB ბლოკჩეინში, რომელიც ვითარდება ჰაია, ჩვენ გადავწყვიტეთ ბარიერის BLS ხელმოწერების გამოყენება, ვგეგმავთ PVRB-ს დანერგვას კონსენსუსის დონეზე, რადგან ჭკვიან კონტრაქტებში გადამოწმება უსაფრთხოების მისაღები დონით ჯერ არ არის შესაძლებელი. შესაძლებელია, რომ ერთდროულად გამოვიყენოთ ორი სქემა: პირველი, ძვირადღირებული საიდუმლო გაზიარება, რათა შევქმნათ გრძელვადიანი random_seed, და შემდეგ ვიყენებთ მას, როგორც მაღალი სიხშირის შემთხვევითი გენერირების საფუძველს დეტერმინისტული ზღურბლის BLS ხელმოწერების გამოყენებით, ალბათ, ჩვენ შემოვიფარგლებით მხოლოდ ერთ-ერთი სქემა. სამწუხაროდ, წინასწარ შეუძლებელია იმის თქმა, როგორი იქნება პროტოკოლი, ერთადერთი კარგი ის არის, რომ როგორც მეცნიერებაში, ასევე საინჟინრო პრობლემებში, უარყოფითი შედეგიც არის შედეგი და პრობლემის გადაჭრის ყოველი ახალი მცდელობა კიდევ ერთი ნაბიჯია. ყველა ადამიანის კვლევა, რომელიც მონაწილეობს პრობლემაში. ბიზნესის მოთხოვნების დასაკმაყოფილებლად, ჩვენ ვწყვეტთ კონკრეტულ პრაქტიკულ პრობლემას - სათამაშო აპლიკაციებს ენტროპიის საიმედო წყაროს უზრუნველსაყოფად, ამიტომ ყურადღება უნდა მივაქციოთ თავად ბლოკჩეინს, კერძოდ, ჯაჭვის საბოლოო და ქსელის მართვის საკითხებს.

და მიუხედავად იმისა, რომ ჩვენ ჯერ არ ვხედავთ დადასტურებულ რეზისტენტულ PVRB-ს ბლოკჩეინებში, რომელიც გამოიყენებოდა საკმარისად დროში, რათა გამოეტესტათ რეალური აპლიკაციებით, მრავალჯერადი აუდიტით, დატვირთვებით და, რა თქმა უნდა, რეალური შეტევებით, მაგრამ შესაძლო გზების რაოდენობა ადასტურებს ამას. გამოსავალი არსებობს და რა - ამ ალგორითმებიდან საბოლოოდ მოაგვარებს პრობლემას. ჩვენ მოხარული ვიქნებით გაგიზიაროთ შედეგები და მადლობა გადავუხადოთ სხვა გუნდებს, რომლებიც ასევე მუშაობენ ამ საკითხზე სტატიებისთვის და კოდისთვის, რომელიც საშუალებას აძლევს ინჟინრებს არ დააბიჯონ ერთსა და იმავე საკომისიოზე ორჯერ.

ასე რომ, როდესაც შეხვდებით პროგრამისტს, რომელიც დეცენტრალიზებულ შემთხვევით დიზაინს ახორციელებს, იყავით ყურადღებიანი და მზრუნველი და საჭიროების შემთხვევაში მიეცით ფსიქოლოგიური დახმარება :)

წყარო: www.habr.com