Salom, men DRD KP loyihasi jamoasida ishlayman (g'ildirak to'plamlarining hayot aylanishini kuzatish uchun tarqatilgan ma'lumotlar reestri). Bu erda men texnologiya cheklovlari ostida ushbu loyiha uchun korporativ blokcheynni ishlab chiqish bo'yicha jamoamiz tajribasini baham ko'rmoqchiman. Men asosan Hyperledger Fabric haqida gapiraman, ammo bu erda tasvirlangan yondashuv har qanday ruxsat etilgan blokcheynga ekstrapolyatsiya qilinishi mumkin. Tadqiqotimizning yakuniy maqsadi - yakuniy mahsulot foydalanish uchun yoqimli va uni saqlash juda qiyin bo'lmasligi uchun korporativ blokcheyn yechimlarini tayyorlash.
Bu erda hech qanday kashfiyotlar, kutilmagan echimlar bo'lmaydi va hech qanday noyob ishlanmalar ta'kidlanmaydi (chunki menda yo'q). Men oddiy tajribam bilan o'rtoqlashmoqchiman, "bu mumkin edi" deb ko'rsatmoqchiman va, ehtimol, sharhlarda boshqa odamlarning yaxshi va unchalik yaxshi bo'lmagan qarorlar qabul qilish tajribasi haqida o'qing.
Muammo: blokcheynlar hali miqyosda emas
Bugungi kunda ko'plab ishlab chiquvchilarning sa'y-harakatlari blokcheynni chiroyli o'ramdagi vaqtli bomba emas, balki haqiqatan ham qulay texnologiyaga aylantirishga qaratilgan. Davlat kanallari, optimistik to'plam, plazma va sharding, ehtimol, odatiy holga aylanadi. Bir kun. Yoki, ehtimol, TON yana ishga tushirishni olti oyga kechiktiradi va keyingi Plazma guruhi o'z faoliyatini to'xtatadi. Biz keyingi yo'l xaritasiga ishonishimiz va tunda yorqin oq qog'ozlarni o'qishimiz mumkin, ammo bu erda va hozir bizda mavjud narsalar bilan nimadir qilishimiz kerak. Ishni bajaring.
Joriy loyihada jamoamiz oldiga qo'yilgan vazifa umuman olganda shunday ko'rinadi: munosabatlarni ishonch asosida qurishni istamaydigan bir necha mingga yetadigan sub'ektlar ko'p; Maxsus ishlash talablarisiz oddiy shaxsiy kompyuterlarda ishlaydigan va har qanday markazlashtirilgan buxgalteriya tizimlaridan yomonroq bo'lmagan foydalanuvchi tajribasini ta'minlaydigan DLT-da yechim yaratish kerak. Yechim ortidagi texnologiya ma'lumotlarni zararli manipulyatsiya qilish imkoniyatini minimallashtirishi kerak - shuning uchun blokcheyn bu erda.
Oq qog'ozlar va ommaviy axborot vositalarining shiorlari bizga keyingi rivojlanish soniyada millionlab tranzaktsiyalarni amalga oshirishga imkon berishini va'da qilmoqda. Bu aslida nima?
Mainnet Ethereum hozirda ~ 30 tps da ishlaydi. Faqat shu sababli, uni korporativ ehtiyojlar uchun mos keladigan blokcheyn sifatida qabul qilish qiyin. Ruxsat berilgan echimlar orasida 2000 tps ni ko'rsatadigan ko'rsatkichlar mavjud () yoki 3000 osh qoshiq (, nashrda biroz kamroq narsa bor, lekin siz benchmark eski konsensus dvigatelida o'tkazilganligini hisobga olishingiz kerak). edi , bu eng yomon natijalarni bermadi, 20000 XNUMX tps, lekin hozircha bu faqat akademik tadqiqot bo'lib, uning barqaror bajarilishini kutmoqda. Blokcheyn ishlab chiquvchilari bo‘limini saqlashga qodir bo‘lgan korporatsiya bunday ko‘rsatkichlarga chidashi dargumon. Ammo muammo nafaqat o'tkazish qobiliyati, balki kechikish ham mavjud.
Kechikish
Tranzaktsiya boshlangan paytdan boshlab tizim tomonidan yakuniy tasdiqlanishigacha kechikish nafaqat xabarni tekshirish va buyurtma qilishning barcha bosqichlaridan o'tish tezligiga, balki blokni shakllantirish parametrlariga ham bog'liq. Bizning blokcheynimiz bizga 1000000 10 488 tps tezlikda ishlashga imkon bersa ham, lekin XNUMX MB blokni yaratish uchun XNUMX daqiqa kerak bo'lsa ham, bu biz uchun osonroq bo'ladimi?
Keling, Hyperledger Fabric-dagi tranzaksiyaning hayot aylanishini batafsil ko'rib chiqaylik, bu vaqt qayerda sarflanishi va uning blok yaratish parametrlari bilan qanday bog'liqligini tushunish uchun.
shu yerdan olingan:
(1) Mijoz tranzaktsiyani yaratadi, uni tasdiqlovchi tengdoshlariga yuboradi, ikkinchisi tranzaktsiyani taqlid qiladi (hozirgi holatga zanjir kodi bilan kiritilgan o'zgarishlarni qo'llang, lekin buxgalteriya kitobiga kiritmang) va RWSet - kalit nomlari, versiyalari va qiymatlarini oladi CouchDB to'plamidan olingan, (2) indossorlar imzolangan RWSet-ni mijozga qaytarib yuboradi, (3) mijoz barcha kerakli tengdoshlarning (indossorlar) imzolari mavjudligini tekshiradi va keyin tranzaktsiyani buyurtma xizmatiga yuboradi. , yoki uni tasdiqlamasdan yuboradi (tekshiruv hali ham keyinroq amalga oshiriladi), buyurtma xizmati blokni tashkil qiladi va (4) faqat indosserlarga emas, balki barcha tengdoshlarga yuboradi; tengdoshlar o'qish to'plamidagi asosiy versiyalar ma'lumotlar bazasidagi versiyalarga mos kelishini, barcha indosserlarning imzolari borligini tekshiradi va nihoyat blokirovka qiladi.
Lekin bu hammasi emas. "Buyurtma beruvchi blokni tashkil qiladi" so'zlari nafaqat tranzaktsiyalar tartibini, balki etakchidan izdoshlarga va orqaga 3 ta ketma-ket tarmoq so'rovlarini yashiradi: lider jurnalga xabar qo'shadi, uni izdoshlarga yuboradi, ikkinchisi uni qo'shadi. ularning jurnaliga, rahbarga muvaffaqiyatli replikatsiya tasdiqlovini yuboradi, lider xabarni yuboradi, izdoshlarga majburiyatni tasdiqlaydi, izdoshlar majburiyatini oladi. Blokni shakllantirish hajmi va vaqti qanchalik kichik bo'lsa, buyurtma berish xizmati konsensusni o'rnatishi kerak bo'ladi. Hyperledger Fabric blokni shakllantirish uchun ikkita parametrga ega: BatchTimeout - blokni shakllantirish vaqti va BatchSize - blok hajmi (tranzaksiyalar soni va blokning o'zi baytlarda o'lchami). Parametrlardan biri chegaraga yetgandan so'ng, yangi blok chiqariladi. Buyurtma tugunlari qancha ko'p bo'lsa, bu shunchalik uzoq davom etadi. Shuning uchun siz BatchTimeout va BatchSize-ni oshirishingiz kerak. Ammo RWSets versiyalanganligi sababli, biz yaratgan blok qanchalik katta bo'lsa, MVCC ziddiyatlari ehtimoli shunchalik yuqori bo'ladi. Bundan tashqari, BatchTimeout ortishi bilan UX halokatli darajada yomonlashadi. Ushbu muammolarni hal qilishning quyidagi sxemasi men uchun oqilona va ravshan ko'rinadi.
Blok tugashini kutishdan qanday qochish va tranzaksiya holatini kuzatish qobiliyatini yo'qotmaslik kerak
Shakllanish vaqti va blok hajmi qanchalik uzoq bo'lsa, blokcheynning o'tkazish qobiliyati shunchalik yuqori bo'ladi. Biri boshqasidan to'g'ridan-to'g'ri ergashmaydi, lekin esda tutish kerakki, RAFTda konsensusni o'rnatish uchun etakchidan izdoshlarga va orqaga uchta tarmoq so'rovi kerak bo'ladi. Buyurtma tugunlari qancha ko'p bo'lsa, bu shunchalik uzoq davom etadi. Blok shakllanishining hajmi va vaqti qanchalik kichik bo'lsa, bunday shovqinlar shunchalik ko'p bo'ladi. Yakuniy foydalanuvchi uchun tizimning javob vaqtini oshirmasdan, yaratish vaqtini va blok hajmini qanday oshirish mumkin?
Birinchidan, biz bir xil versiyaga ega turli RWSetlarni o'z ichiga olishi mumkin bo'lgan katta blok o'lchamidan kelib chiqqan MVCC ziddiyatlarini qandaydir tarzda hal qilishimiz kerak. Shubhasiz, mijoz tomonida (blokcheyn tarmog'iga nisbatan, bu orqa tomon bo'lishi mumkin va men shuni nazarda tutyapman) sizga kerak MVCC ziddiyatli ishlov beruvchi, bu alohida xizmat yoki qayta urinish mantig'i bilan tranzaktsiyani boshlaydigan qo'ng'iroq ustidagi oddiy dekorator bo'lishi mumkin.
Qayta urinish eksponensial strategiya bilan amalga oshirilishi mumkin, ammo keyin kechikish ham xuddi eksponent tarzda pasayadi. Shunday qilib, siz ma'lum bir kichik chegaralar ichida tasodifiy qayta urinishdan yoki doimiydan foydalanishingiz kerak. Birinchi variantda yuzaga kelishi mumkin bo'lgan to'qnashuvlarni hisobga olgan holda.
Keyingi qadam, mijozning tizim bilan o'zaro ta'sirini 15, 30 yoki 10000000 soniya kutmasligi uchun asinxron qilishdir, biz buni BatchTimeout sifatida o'rnatamiz. Biroq, shu bilan birga, tranzaktsiya tomonidan boshlangan o'zgarishlar blokcheynda qayd etilmaganligini tekshirish qobiliyatini saqlab qolish kerak.
Tranzaksiya holatini saqlash uchun ma'lumotlar bazasidan foydalanish mumkin. Foydalanish qulayligi tufayli eng oddiy variant CouchDB hisoblanadi: maʼlumotlar bazasida UI, REST API mavjud va siz uning uchun replikatsiya va shardingni osongina sozlashingiz mumkin. Siz shunchaki CouchDB misolida dunyo holatini saqlash uchun Fabric-dan foydalanadigan alohida to'plam yaratishingiz mumkin. Biz bunday turdagi hujjatlarni saqlashimiz kerak.
{
Status string // Статус транзакции: "pending", "done", "failed"
TxID: string // ID транзакции
Error: string // optional, сообщение об ошибке
}Ushbu hujjat tranzaksiya tengdoshlarga yuborilishidan oldin ma'lumotlar bazasiga yoziladi, agar bu yaratish operatsiyasi bo'lsa, ob'ekt identifikatori foydalanuvchiga qaytariladi (bir xil identifikator kalit sifatida ishlatiladi), so'ngra Status, TxID va Xato maydonlari tengdoshlardan tegishli ma'lumotlar olingani uchun yangilanadi.
Ushbu sxemada foydalanuvchi 10 soniya davomida ekranda aylanayotgan g'ildirakni kuzatib, blokning nihoyat shakllanishini kutmaydi, u tizimdan bir zumda javob oladi va ishlashni davom ettiradi.
Tranzaksiya holatini saqlash uchun BoltDB-ni tanladik, chunki biz xotirani tejashimiz kerak va alohida ma'lumotlar bazasi serveri bilan tarmoq o'zaro aloqasiga vaqt sarflashni istamaymiz, ayniqsa bu o'zaro aloqa oddiy matn protokoli yordamida sodir bo'lganda. Aytgancha, CouchDB-dan yuqorida tavsiflangan sxemani amalga oshirish uchun foydalanasizmi yoki oddiygina dunyo holatini saqlash uchun foydalanasizmi, har qanday holatda ham CouchDB-da ma'lumotlarni saqlash usulini optimallashtirish mantiqiy. Odatiy bo'lib, CouchDB-da b-daraxt tugunlarining o'lchami 1279 baytni tashkil qiladi, bu diskdagi sektor o'lchamidan ancha kichikdir, ya'ni daraxtni o'qish va muvozanatlash diskka ko'proq jismoniy kirishni talab qiladi. Optimal o'lcham standartga mos keladi va 4 kilobaytni tashkil qiladi. Optimallashtirish uchun biz parametrni o'rnatishimiz kerak btree_chunk_size 4096 ga teng CouchDB konfiguratsiya faylida. BoltDB uchun bunday qo'lda aralashuv .
Orqa bosim: bufer strategiyasi
Lekin juda ko'p xabarlar bo'lishi mumkin. Diagrammada ko'rsatilganlardan tashqari o'nlab boshqa xizmatlar bilan resurslarni almashish tizimning qo'lidan ko'ra ko'proq - va bularning barchasi hatto Intellij Idea bilan ishlash juda zerikarli bo'ladigan mashinalarda ham mukammal ishlashi kerak.
Ishlab chiqaruvchi va iste'molchi aloqa tizimlarining turli xil quvvatlari muammosi turli yo'llar bilan hal qilinadi. Keling, nima qilishimiz mumkinligini ko'rib chiqaylik.
O'chirish: Biz T soniya ichida eng ko'p X tranzaktsiyalarni qayta ishlashga qodir ekanligimizni da'vo qilishimiz mumkin. Ushbu chegaradan oshib ketgan barcha so'rovlar bekor qilinadi. Bu juda oddiy, ammo keyin siz UX haqida unutishingiz mumkin.
Boshqarish: iste'molchi yukga qarab ishlab chiqaruvchining TPS-ni boshqarishi mumkin bo'lgan qandaydir interfeysga ega bo'lishi kerak. Yomon emas, lekin bu interfeysni amalga oshirish uchun yukni yaratuvchi mijozni ishlab chiquvchilarga majburiyatlarni yuklaydi. Bu biz uchun qabul qilinishi mumkin emas, chunki blokcheyn kelajakda uzoq vaqtdan beri mavjud bo'lgan ko'plab tizimlarga integratsiya qilinadi.
Tamponlash: Kirish ma'lumotlar oqimiga qarshilik ko'rsatish o'rniga, biz ushbu oqimni buferlashimiz va uni kerakli tezlikda qayta ishlashimiz mumkin. Shubhasiz, agar biz yaxshi foydalanuvchi tajribasini taqdim qilmoqchi bo'lsak, bu eng yaxshi yechim. Biz RabbitMQ-da navbat yordamida buferni amalga oshirdik.
Sxemaga ikkita yangi harakat qo'shildi: (1) API ga so'rov kelgandan so'ng, tranzaktsiyani chaqirish uchun zarur bo'lgan parametrlarga ega xabar navbatga qo'yiladi va mijoz tranzaksiya tomonidan qabul qilinganligi haqida xabar oladi. tizim, (2) backend ma'lumotlarni navbatdan konfiguratsiyada ko'rsatilgan tezlikda o'qiydi; tranzaktsiyani boshlaydi va holat do'konidagi ma'lumotlarni yangilaydi.
Endi siz foydalanuvchidan kechikishlarni yashirib, shakllanish vaqtini o'zingiz xohlagancha oshirishingiz va sig'imni bloklashingiz mumkin.
Boshqa vositalar
Bu erda zanjir kodlari haqida hech narsa aytilmagan, chunki, qoida tariqasida, unda optimallashtirish uchun hech narsa yo'q. Chaincode iloji boricha sodda va xavfsiz bo'lishi kerak - undan talab qilinadigan narsa shu. Ramka bizga zanjir kodini sodda va xavfsiz yozishga yordam beradi S7 Techlab va statik analizatordan .
Bundan tashqari, bizning jamoamiz Fabric bilan ishlashni sodda va yoqimli qilish uchun bir qator yordamchi dasturlarni ishlab chiqmoqda: , uchun yordamchi dastur (tashkilotlarni qo'shish/o'chirish, RAFT tugunlari), yordamchi dastur . Agar siz hissa qo'shmoqchi bo'lsangiz, marhamat.
xulosa
Ushbu yondashuv Hyperledger Fabric-ni Quorum, boshqa xususiy Ethereum tarmoqlari (PoA yoki hatto PoW) bilan osongina almashtirishga, haqiqiy o'tkazuvchanlikni sezilarli darajada kamaytirishga, lekin ayni paytda oddiy UXni saqlab qolishga imkon beradi (brauzerdagi foydalanuvchilar uchun ham, o'rnatilgan tizimlar uchun ham). Sxemada Fabric-ni Ethereum bilan almashtirganda, siz faqat qayta urinish xizmati/dekorator mantig'ini MVCC ziddiyatlarini qayta ishlashdan atomik bo'lmagan o'sish va qayta yuborishga o'zgartirishingiz kerak bo'ladi. Buferlash va holatni saqlash blokni shakllantirish vaqtidan javob vaqtini ajratish imkonini berdi. Endi siz minglab buyurtma tugunlarini qo'shishingiz mumkin va bloklar juda tez-tez hosil bo'lishidan qo'rqmaysiz va buyurtma xizmatini yuklashingiz mumkin.
Umuman olganda, men baham ko'rmoqchi bo'lgan narsam shu edi. Agar bu kimgadir ishida yordam bersa, xursand bo'laman.
Manba: www.habr.com