Salam, mən DRD KP layihəsinin komandasında işləyirəm (təkər dəstlərinin həyat dövrünü izləmək üçün paylanmış məlumat reyestri). Burada texnologiyanın məhdudiyyətləri altında bu layihə üçün müəssisə blokçeyninin hazırlanması üzrə komandamızın təcrübəsini bölüşmək istərdim. Çox hissəsi üçün mən Hyperledger Fabric haqqında danışacağam, lakin burada təsvir edilən yanaşma hər hansı icazə verilən blokçeyn üçün ekstrapolyasiya edilə bilər. Tədqiqatımızın son məqsədi müəssisə blokçeyn həllərini elə hazırlamaqdır ki, son məhsul istifadə üçün xoş olsun və saxlanılması çox çətin olmasın.
Burada heç bir kəşf, gözlənilməz həllər və heç bir unikal inkişaf olmayacaq (çünki məndə yoxdur). Mən sadəcə öz təvazökar təcrübəmi bölüşmək, "mümkün olduğunu" göstərmək və bəlkə də şərhlərdə başqasının yaxşı və o qədər də yaxşı olmayan qərarlar qəbul etmə təcrübəsi haqqında oxumaq istəyirəm.
Problem: blokçeynlər hələ ki, genişləndirilə bilməz
Bu gün bir çox tərtibatçının səyləri blokçeyni gözəl bir qablaşdırmada saat bombası deyil, həqiqətən rahat bir texnologiyaya çevirməyə yönəldilmişdir. Dövlət kanalları, optimist yığım, plazma və parçalanma adi hala çevrilə bilər. Bir gün. Və ya bəlkə TON yenidən buraxılışını altı ay təxirə salacaq və növbəti Plazma Qrupu fəaliyyətini dayandıracaq. Başqa bir yol xəritəsinə inanıb gecələr parlaq ağ sənədləri oxuya bilərik, amma burada və indi əlimizdə olanlarla nəsə etməliyik. İşini bitir.
Hazırkı layihədə komandamıza tapşırılan vəzifə ümumi mənada belə görünür: bir neçə minə çatan, etimad əsasında münasibətlər qurmaq istəməyən subyektlər çoxdur; xüsusi performans tələbləri olmadan adi kompüterlərdə işləyəcək və heç bir mərkəzləşdirilmiş uçot sistemlərindən daha pis olmayan istifadəçi təcrübəsini təmin edəcək bir həll DLT üzərində qurmaq lazımdır. Həllin arxasındakı texnologiya zərərli məlumatların manipulyasiyası ehtimalını minimuma endirməlidir – buna görə də blokçeyn buradadır.
Ağ kağızlardan və mediadan gələn şüarlar bizə növbəti inkişafın saniyədə milyonlarla əməliyyata imkan verəcəyini vəd edir. Həqiqətən nədir?
Mainnet Ethereum hazırda ~30 tps ilə işləyir. Təkcə buna görə onu korporativ ehtiyaclar üçün hər hansı bir şəkildə uyğun olan blokçeyn kimi qəbul etmək çətindir. İcazə verilən həllər arasında 2000 t/s göstərən meyarlar məlumdur () və ya 3000 çay qaşığı (, nəşrdə bir az daha az var, lakin nəzərə alın ki, benchmark köhnə konsensus mühərrikində aparılıb). idi , ən pis nəticələr vermədi, 20000 tps, lakin indiyə qədər bunlar sabit tətbiqini gözləyən akademik tədqiqatlardır. Çətin ki, blokçeyn tərtibatçıları departamentini saxlamağa gücü çatan bir korporasiya bu cür göstəricilərə dözsün. Ancaq problem təkcə ötürmə qabiliyyətində deyil, gecikmə də var.
gizlilik
Əməliyyatın başlandığı andan sistem tərəfindən yekun təsdiqinə qədər gecikmə yalnız təsdiqləmə və sifarişin bütün mərhələlərindən keçən mesajın sürətindən deyil, həm də blokun formalaşma parametrlərindən asılıdır. Blockchain-imiz bizə 1000000 tps-də işləməyə imkan versə də, lakin 10MB blok yaratmaq üçün 488 dəqiqə çəksə belə, bu, bizim üçün asanlaşacaqmı?
Gəlin Hyperledger Fabric-də əməliyyatın həyat dövrünə daha yaxından nəzər salaq ki, nə vaxt tələb edir və bunun blok formalaşma parametrləri ilə necə əlaqəsi var.
buradan götürülüb:
(1) Müştəri bir əməliyyat təşkil edir, onu təsdiq edən həmyaşıdlarına göndərir, sonuncu əməliyyatı simulyasiya edir (zəncir kodu ilə edilən dəyişiklikləri cari vəziyyətə tətbiq edir, lakin mühasibat kitabçasına əməl etmir) və RWSet - açar adları, versiyaları və CouchDB-də kolleksiyadan götürülmüş dəyərlər, (2) indossorlar imzalanmış RWSet-i müştəriyə geri göndərir, (3) müştəri ya bütün tələb olunan həmyaşıdların (indossorların) imzalarını yoxlayır və sonra əməliyyatı sifarişçiyə göndərir. xidmət və ya onu yoxlamadan göndərir (yoxlama daha sonra da olacaq), sifariş xidməti blok təşkil edir və (4) yalnız indossorlara deyil, bütün həmyaşıdlarına geri göndərir; həmyaşıdlar oxunan dəstdəki açarların versiyalarının verilənlər bazasındakı versiyalara, bütün indossorların imzalarına uyğun olub-olmadığını yoxlayır və nəhayət bloklamanı həyata keçirir.
Ancaq bu hamısı deyil. "Sifarişçi blok təşkil edir" sözlərinin arxasında təkcə əməliyyatların sifarişi deyil, həm də liderdən ardıcıllara və geriyə 3 ardıcıl şəbəkə sorğusu gizlənir: lider jurnala mesaj əlavə edir, izləyicilərə göndərir, sonuncu əlavə edir. onların jurnalı, liderə uğurlu təkrarlamanın təsdiqini göndərir, lider mesajı qəbul edir, izləyicilərə öhdəlik təsdiqini göndərir, izləyicilər öhdəliyini götürür. Blok ölçüsü və vaxtı nə qədər kiçik olsa, sifariş xidməti bir o qədər tez-tez konsensus yaratmalı olacaq. Hyperledger Fabric iki blok yaratma parametrinə malikdir: BatchTimeout - blokun formalaşma vaxtı və BatchSize - blok ölçüsü (əməliyyatların sayı və blokun özünün baytdakı ölçüsü). Parametrlərdən biri limitə çatan kimi yeni blok verilir. Sifariş qovşağı nə qədər çox olsa, bu, bir o qədər uzun çəkəcək. Buna görə də, BatchTimeout və BatchSize-i artırmalısınız. Lakin RWSets versiyalı olduğundan, bloku nə qədər böyük ediriksə, MVCC konfliktlərinin ehtimalı bir o qədər yüksək olur. Bundan əlavə, BatchTimeout-un artması ilə UX fəlakətli şəkildə pisləşir. Mənə bu problemlərin həlli üçün aşağıdakı sxem ağlabatan və aydın görünür.
Blokların tamamlanmasını gözləmək və əməliyyat statusunu itirməmək üçün necə
Yaratma müddəti və blok ölçüsü nə qədər uzun olsa, blokçeynin ötürmə qabiliyyəti bir o qədər yüksək olar. Biri digərindən birbaşa izlənmir, lakin yadda saxlamaq lazımdır ki, RAFT-də konsensusun qurulması liderdən ardıcıllara və geriyə üç şəbəkə sorğusu tələb edir. Sifariş qovşaqları nə qədər çox olsa, bir o qədər uzun sürəcək. Blokların formalaşmasının ölçüsü və vaxtı nə qədər kiçik olarsa, bu cür qarşılıqlı təsirlər bir o qədər çox olur. Son istifadəçi üçün sistemin cavab müddətini artırmadan formalaşma müddətini və blok ölçüsünü necə artırmaq olar?
Birincisi, eyni versiyaya malik müxtəlif RWSetləri daxil edə bilən böyük blok ölçüsünün səbəb olduğu MVCC münaqişələrini birtəhər həll etməlisiniz. Aydındır ki, müştəri tərəfində (blokçeyn şəbəkəsi ilə əlaqədar olaraq, bu, arxa plan ola bilər və mən bunu nəzərdə tuturam) MVCC münaqişə idarəedicisi, bu, ya ayrıca bir xidmət, ya da təkrar cəhd məntiqi ilə əməliyyat başlatan zəng üzərində adi dekorator ola bilər.
Yenidən cəhd eksponensial strategiya ilə həyata keçirilə bilər, lakin sonra gecikmə də eksponent olaraq azalacaq. Beləliklə, ya müəyyən kiçik məhdudiyyətlər daxilində təsadüfi təkrar cəhddən, ya da daimi olandan istifadə etməlisiniz. Birinci variantda mümkün toqquşmaları nəzərə alaraq.
Növbəti addım müştərinin sistemlə qarşılıqlı əlaqəsini 15, 30 və ya 10000000 saniyə gözləməməsi üçün asinxron etməkdir ki, biz bunu BatchTimeout kimi təyin edəcəyik. Lakin eyni zamanda, əməliyyatın başlatdığı dəyişikliklərin blokçeynində qeydə alındığına/qeyd edilmədiyinə əmin olmaq qabiliyyətini saxlamaq lazımdır.
Verilənlər bazası əməliyyatların vəziyyətini saxlamaq üçün istifadə edilə bilər. İstifadə rahatlığına görə ən asan seçim CouchDB-dir: verilənlər bazası qutudan kənar UI, REST API-yə malikdir və siz onun üçün asanlıqla replikasiya və parçalanma qura bilərsiniz. Siz sadəcə Fabric-in dünya vəziyyətini saxlamaq üçün istifadə etdiyi eyni CouchDB instansiyasında ayrıca kolleksiya yarada bilərsiniz. Bu cür sənədləri saxlamalıyıq.
{
Status string // Статус транзакции: "pending", "done", "failed"
TxID: string // ID транзакции
Error: string // optional, сообщение об ошибке
}Bu sənəd əməliyyat həmyaşıdlarına göndərilməmişdən əvvəl verilənlər bazasına yazılır, əgər bu yaradılış əməliyyatıdırsa, obyekt identifikatoru istifadəçiyə qaytarılır (eyni ID açar kimi istifadə olunur), sonra Status, TxID və Error sahələri həmyaşıdlarından müvafiq məlumat alındıqca yenilənir.
Bu sxemdə istifadəçi blokun nəhayət formalaşmasını gözləmir, 10 saniyə ərzində ekranda fırlanan çarxı izləyir, sistemdən ani cavab alır və işləməyə davam edir.
Tranzaksiya statuslarını saxlamaq üçün BoltDB-ni seçdik, çünki yaddaşa qənaət etməliyik və müstəqil verilənlər bazası serveri ilə şəbəkə qarşılıqlı əlaqəsinə vaxt itirmək istəmirik, xüsusən də bu qarşılıqlı əlaqə adi mətn protokolundan istifadə edildikdə. Yeri gəlmişkən, CouchDB-dən yuxarıda təsvir olunan sxemi həyata keçirmək üçün istifadə etsəniz və ya sadəcə dünya vəziyyətini saxlamaq üçün istifadə etsəniz, istənilən halda məlumatların CouchDB-də saxlanma üsulunu optimallaşdırmaq məna kəsb edir. Varsayılan olaraq, CouchDB-də b-ağac qovşaqlarının ölçüsü 1279 baytdır ki, bu da diskdəki sektor ölçüsündən çox azdır, yəni ağacın oxunması və yenidən balanslaşdırılması daha çox fiziki diskə giriş tələb edəcək. Optimal ölçü standarta cavab verir və 4 kilobaytdır. Optimallaşdırma üçün parametri təyin etməliyik btree_chunk_size 4096-a bərabərdir CouchDB konfiqurasiya faylında. BoltDB üçün belə əl müdaxiləsi .
Arxa təzyiq: bufer strategiyası
Ancaq çoxlu mesajlar ola bilər. Sistemin idarə edə biləcəyindən daha çox, diaqramda göstərilənlərdən başqa bir çox digər xidmətlərlə resursları paylaşır - və bütün bunlar hətta Intellij Idea-nın çox yorucu olacağı maşınlarda belə qüsursuz işləməlidir.
İstehsalçı və istehlakçı rabitə sistemlərinin fərqli ötürmə qabiliyyəti problemi müxtəlif yollarla həll olunur. Gəlin görək nə edə bilərik.
Düşmə: T saniyə ərzində ən çox X əməliyyatı emal edə bildiyimizi iddia edə bilərik. Bu limiti aşan bütün sorğular rədd edilir. Bu olduqca sadədir, lakin sonra UX haqqında unuda bilərsiniz.
Nəzarət: istehlakçı müəyyən interfeysə malik olmalıdır ki, onun vasitəsilə yükdən asılı olaraq istehsalçının tps-lərini idarə edə bilər. Pis deyil, lakin bu interfeysi həyata keçirmək üçün yük müştərisinin tərtibatçılarına bir öhdəlik qoyur. Bizim üçün bu qəbuledilməzdir, çünki gələcəkdə blokçeyn çoxlu sayda uzun müddətdir mövcud olan sistemlərə inteqrasiya olunacaq.
Buffering: giriş məlumat axınına müqavimət göstərmək əvəzinə, bu axını bufer edə və lazımi sürətlə emal edə bilərik. Aydındır ki, yaxşı bir istifadəçi təcrübəsi təmin etmək istəyiriksə, bu ən yaxşı həlldir. Buferi RabbitMQ-da növbədən istifadə edərək həyata keçirdik.
Sxemə iki yeni hərəkət əlavə edildi: (1) API sorğusu alındıqdan sonra, əməliyyata zəng etmək üçün lazım olan parametrlərlə bir mesaj növbəyə qoyulur və müştəri əməliyyatın sistem tərəfindən qəbul edildiyi barədə mesaj alır, ( 2) arxa uç məlumatları növbədən konfiqurasiyada göstərilən sürətlə oxuyur; əməliyyata başlayır və status anbarındakı məlumatları yeniləyir.
İndi siz istifadəçidən gecikmələri gizlədərək, qurma vaxtını və blok tutumunu istədiyiniz qədər artıra bilərsiniz.
Digər alətlər
Burada zəncir kodu haqqında heç nə deyilmədi, çünki adətən onu optimallaşdırmaq üçün heç bir şey yoxdur. Zəncir kodu mümkün qədər sadə və təhlükəsiz olmalıdır - ondan tələb olunanların hamısı budur. Çərçivə bizə zəncir kodunu sadə və təhlükəsiz yazmaqda çox kömək edir. S7 Techlab və statik analizatordan .
Bundan əlavə, komandamız Fabric ilə işləməyi sadə və zövqlü etmək üçün bir sıra kommunal proqramlar hazırlayır: , üçün kommunal (təşkilatlar, RAFT qovşaqları əlavə edin/çıxarın), üçün kommunal . Əgər töhfə vermək istəyirsinizsə, xoş gəlmisiniz.
Nəticə
Bu yanaşma Hyperledger Fabric-i Quorum, digər özəl Ethereum şəbəkələri (PoA və ya hətta PoW) ilə əvəz etməyi asanlaşdırır, real ötürmə qabiliyyətini əhəmiyyətli dərəcədə azaldır, lakin eyni zamanda normal UX-ni saxlayır (həm brauzerdə, həm də inteqrasiya edilmiş sistemlər tərəfdən istifadəçilər üçün). ). Sxemdə Fabric-i Ethereum ilə əvəz edərkən, yalnız təkrar cəhd xidmətinin/dekoratorun məntiqini MVCC konfliktlərini idarə etməkdən atomik olmayan artıma və yenidən göndərməyə dəyişmək lazımdır. Buferləmə və statusun saxlanması cavab vaxtını blokun formalaşma vaxtından ayırmağa imkan verdi. İndi minlərlə sifariş qovşağı əlavə edə bilərsiniz və blokların çox tez-tez formalaşmasından qorxmayın və sifariş xidmətini yükləyin.
Ümumiyyətlə, paylaşmaq istədiyim hər şey bu idi. Kiməsə işində kömək etsə şad olaram.
Mənbə: www.habr.com