განაწილებული რეესტრი Wheelsets-ისთვის: გამოცდილება Hyperledger Fabric-თან

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

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

პრობლემა: ბლოკჩეინები ჯერ არ არის მასშტაბირებადი

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

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

თეთრი ქაღალდისა და მედიის სლოგანები გვპირდებიან, რომ შემდეგი განვითარება წამში მილიონობით ტრანზაქციის საშუალებას მისცემს. მართლა რა არის?

Mainnet Ethereum ამჟამად მუშაობს ~30 tps-ზე. მხოლოდ ამის გამო, ძნელია მისი აღქმა, როგორც ბლოკჩეინი, რომელიც რაიმე ფორმით შესაფერისია კორპორატიული საჭიროებისთვის. ნებადართულ გადაწყვეტილებებს შორის ცნობილია საორიენტაციო ნიშნები, რომლებიც აჩვენებს 2000 tps (ქვორუმი) ან 3000 tps (ჰიპერლინგერის ქსოვილი, პუბლიკაციაში ცოტა ნაკლებია, მაგრამ გაითვალისწინეთ, რომ ეტალონი განხორციელდა ძველ კონსენსუსის ძრავზე). იყო ქსოვილის რადიკალურად გადამუშავების მცდელობა, რომელმაც არ მისცა ყველაზე ცუდი შედეგი, 20000 tps, მაგრამ ჯერჯერობით ეს მხოლოდ აკადემიური კვლევებია, რომელიც ელოდება მათ სტაბილურ განხორციელებას. ნაკლებად სავარაუდოა, რომ კორპორაცია, რომელსაც შეუძლია შეინარჩუნოს ბლოკჩეინის დეველოპერების დეპარტამენტი, შეეგუოს ასეთ მაჩვენებლებს. მაგრამ პრობლემა მხოლოდ გამტარუნარიანობაში არ არის, ასევე არის შეყოვნება.

შეყოვნება

შეფერხება ტრანზაქციის დაწყებიდან სისტემის მიერ მის საბოლოო დამტკიცებამდე, დამოკიდებულია არა მხოლოდ შეტყობინებების სიჩქარეზე, რომელიც გადის ვალიდაციისა და შეკვეთის ყველა ეტაპზე, არამედ ბლოკის ფორმირების პარამეტრებზეც. მაშინაც კი, თუ ჩვენი ბლოკჩეინი საშუალებას მოგვცემს ჩავაბაროთ 1000000 tps, მაგრამ 10 წუთი სჭირდება 488MB ბლოკის ჩამოყალიბებას, გაგვიადვილდება ეს?

მოდით უფრო ახლოს მივხედოთ ტრანზაქციის სასიცოცხლო ციკლს Hyperledger Fabric-ში, რათა გავიგოთ, რას მოითხოვს დრო და როგორ უკავშირდება ის ბლოკის ფორმირების პარამეტრებს.

აქედან აღებული: hyperledger-fabric.readthedocs.io/en/release-1.4/arch-deep-dive.html#swimlane

(1) კლიენტი აყალიბებს ტრანზაქციას, აგზავნის მას ინდოსირებულ თანატოლებთან, ეს უკანასკნელნი ახდენენ ტრანზაქციის სიმულაციას (გამოიყენებენ ჯაჭვის კოდით განხორციელებულ ცვლილებებს მიმდინარე მდგომარეობაზე, მაგრამ არ ავალდებულებენ წიგნს) და იღებენ RWSet - გასაღების სახელებს, ვერსიებს და CouchDB-ში კოლექციიდან აღებული მნიშვნელობები, (2) ინდოსატორები უგზავნიან ხელმოწერილ RWSet-ს კლიენტს, (3) კლიენტი ან ამოწმებს ყველა საჭირო თანატოლის (ინდოსატორების) ხელმოწერებს და შემდეგ აგზავნის ტრანზაქციას შეკვეთის სერვისში , ან აგზავნის მას გადამოწმების გარეშე (დადასტურება მოგვიანებით მოხდება), შეკვეთის სერვისი ქმნის ბლოკს და (4) აგზავნის უკან ყველა თანატოლს და არა მხოლოდ ინდოსერს; თანატოლები ამოწმებენ, რომ გასაღებების ვერსიები წაკითხულ კომპლექტში ემთხვევა მონაცემთა ბაზაში არსებულ ვერსიებს, ყველა დამხმარე ხელმოწერებს და ბოლოს ახორციელებენ ბლოკს.

მაგრამ ეს ყველაფერი არ არის. სიტყვების მიღმა „შეკვეთა აყალიბებს ბლოკს“ იმალება არა მხოლოდ ტრანზაქციების შეკვეთა, არამედ ლიდერის ზედიზედ 3 ქსელური მოთხოვნა მიმდევრებისადმი და უკან: ლიდერი ამატებს შეტყობინებას ჟურნალში, აგზავნის მიმდევრებს, ეს უკანასკნელნი ამატებენ მათი ჟურნალი, გაუგზავნეთ ლიდერს წარმატებული რეპლიკაციის დადასტურება, ლიდერი ახორციელებს შეტყობინებას, უგზავნის ვალდებულების დადასტურებას მიმდევრებს, მიმდევრები ასრულებენ. რაც უფრო მცირეა ბლოკის ზომა და დრო, მით უფრო ხშირად მოუწევს შეკვეთის სერვისს კონსენსუსის დამყარება. Hyperledger Fabric-ს აქვს ბლოკის ფორმირების ორი პარამეტრი: BatchTimeout - ბლოკის ფორმირების დრო და BatchSize - ბლოკის ზომა (ტრანზაქციის რაოდენობა და თავად ბლოკის ზომა ბაიტებში). როგორც კი ერთ-ერთი პარამეტრი მიაღწევს ლიმიტს, გაიცემა ახალი ბლოკი. რაც უფრო მეტი დამკვეთი კვანძია, მით მეტი დრო დასჭირდება ამას. ამიტომ, თქვენ უნდა გაზარდოთ BatchTimeout და BatchSize. მაგრამ რადგან RWSets არის ვერსიული, რაც უფრო დიდს ვაკეთებთ ბლოკს, მით უფრო მაღალია MVCC კონფლიქტების ალბათობა. გარდა ამისა, BatchTimeout-ის მატებასთან ერთად, UX კატასტროფულად მცირდება. გონივრული და გასაგები მეჩვენება ამ პრობლემების გადაჭრის შემდეგი სქემა.

როგორ ავიცილოთ თავიდან ბლოკის დასრულებას მოლოდინი და არ დაკარგოთ ტრანზაქციის სტატუსი

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

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

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

შემდეგი ნაბიჯი არის კლიენტის ინტერაქცია სისტემასთან ასინქრონული, რათა ის არ დაელოდოს 15, 30 ან 10000000 წამს, რომელსაც ჩვენ დავაყენებთ BatchTimeout-ად. მაგრამ ამავდროულად, აუცილებელია შევინარჩუნოთ შესაძლებლობა, დავრწმუნდეთ, რომ ტრანზაქციის მიერ ინიცირებული ცვლილებები დაფიქსირებულია/არ ჩაიწერება ბლოკჩეინში.
მონაცემთა ბაზა შეიძლება გამოყენებულ იქნას ტრანზაქციების სტატუსის შესანახად. უმარტივესი ვარიანტია CouchDB მისი გამოყენების სიმარტივის გამო: მონაცემთა ბაზას აქვს UI out of box, REST API და თქვენ შეგიძლიათ მარტივად დააყენოთ რეპლიკაცია და გაზიარება. თქვენ შეგიძლიათ შექმნათ ცალკე კოლექცია იმავე CouchDB მაგალითში, რომელსაც Fabric იყენებს თავისი მსოფლიო მდგომარეობის შესანახად. ჩვენ გვჭირდება ამ ტიპის დოკუმენტების შენახვა.

{
 Status string // Статус транзакции: "pending", "done", "failed"
 TxID: string // ID транзакции
 Error: string // optional, сообщение об ошибке
}

ეს დოკუმენტი იწერება მონაცემთა ბაზაში ტრანზაქციის თანატოლებთან გაგზავნამდე, ერთეულის ID უბრუნდება მომხმარებელს (იგივე ID გამოიყენება როგორც გასაღები), თუ ეს არის შექმნის ოპერაცია, შემდეგ კი Status, TxID და Error ველები. განახლებულია, როგორც შესაბამისი ინფორმაცია მიიღება თანატოლებისგან.

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

ჩვენ ავირჩიეთ BoltDB ტრანზაქციის სტატუსების შესანახად, რადგან გვჭირდება მეხსიერების დაზოგვა და არ გვინდა დროის დაკარგვა ქსელის ინტერაქციაზე ცალკე მონაცემთა ბაზის სერვერთან, განსაკუთრებით მაშინ, როდესაც ეს ურთიერთქმედება ხდება მარტივი ტექსტური პროტოკოლის გამოყენებით. სხვათა შორის, იყენებთ CouchDB-ს ზემოთ აღწერილი სქემის განსახორციელებლად თუ უბრალოდ მსოფლიო მდგომარეობის შესანახად, ნებისმიერ შემთხვევაში, აზრი აქვს CouchDB-ში მონაცემების შენახვის ოპტიმიზაციას. ნაგულისხმევად, CouchDB-ში, b-tree კვანძების ზომაა 1279 ბაიტი, რაც გაცილებით ნაკლებია ვიდრე სექტორის ზომა დისკზე, რაც ნიშნავს, რომ როგორც წაკითხვა, ასევე ხის ხელახალი ბალანსირება მოითხოვს უფრო მეტ ფიზიკურ დისკზე წვდომას. ოპტიმალური ზომა აკმაყოფილებს სტანდარტს გაფართოებული ფორმატი და არის 4 კილობაიტი. ოპტიმიზაციისთვის ჩვენ უნდა დავაყენოთ პარამეტრი btree_chunk_size უდრის 4096-ს CouchDB კონფიგურაციის ფაილში. BoltDB-სთვის ასეთი ხელით ჩარევა არ არის საჭირო.

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

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

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

ჩამოაგდეს: შეგვიძლია ვთქვათ, რომ შეგვიძლია მაქსიმუმ X ტრანზაქციის დამუშავება T წამში. ყველა მოთხოვნა, რომელიც აღემატება ამ ლიმიტს, გაუქმებულია. ეს საკმაოდ მარტივია, მაგრამ შემდეგ შეგიძლიათ დაივიწყოთ UX.

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

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

სქემას დაემატა ორი ახალი მოქმედება: (1) API მოთხოვნის მიღების შემდეგ, მესიჯი დგას რიგში ტრანზაქციის გამოსაძახებლად საჭირო პარამეტრებით და კლიენტი იღებს შეტყობინებას, რომ ტრანზაქცია მიღებულია სისტემის მიერ, ( 2) backend კითხულობს მონაცემებს რიგიდან კონფიგურაციაში მითითებული სიჩქარით; იწყებს ტრანზაქციას და აახლებს მონაცემებს სტატუსის მაღაზიაში.
ახლა თქვენ შეგიძლიათ გაზარდოთ აშენების დრო და დაბლოკოთ სიმძლავრე რამდენიც გსურთ, მომხმარებლისგან დაფაროთ შეფერხებები.

სხვა იარაღები

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

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

დასკვნა

ეს მიდგომა აადვილებს Hyperledger Fabric-ის ჩანაცვლებას Quorum-ით, სხვა კერძო Ethereum ქსელებით (PoA ან თუნდაც PoW), მნიშვნელოვნად ამცირებს რეალურ გამტარუნარიანობას, მაგრამ ამავე დროს ნორმალური UX-ის შენარჩუნებას (როგორც მომხმარებლებისთვის, ასევე ბრაუზერში, ასევე ინტეგრირებული სისტემების მხრიდან. ). Fabric-ის Ethereum-ით ჩანაცვლებისას სქემაში, მხოლოდ ხელახალი ცდის სერვისის/დეკორატორის ლოგიკა უნდა შეიცვალოს MVCC კონფლიქტების დამუშავებიდან ატომურ არანაირ მატებამდე და ხელახლა გაგზავნამდე. ბუფერირებამ და სტატუსის შენახვამ შესაძლებელი გახადა რეაგირების დროის გამოყოფა ბლოკის ფორმირების დროიდან. ახლა თქვენ შეგიძლიათ დაამატოთ ათასობით შეკვეთის კვანძი და არ შეგეშინდეთ, რომ ბლოკები ძალიან ხშირად იქმნება და დატვირთეთ შეკვეთის სერვისი.

ზოგადად, ეს არის ის, რაც მინდოდა გამეზიარებინა. მოხარული ვიქნები, თუ ეს ვინმეს დაეხმარება სამუშაოში.

წყარო: www.habr.com