Сәлеметсіз бе, мен DRD KP жобасының командасында жұмыс істеймін (доңғалақ жинақтарының өмірлік циклін бақылау үшін таратылған деректер тізілімі). Мұнда мен технологияның шектеулері жағдайында осы жоба үшін кәсіпорын блокчейнін жасау бойынша біздің команданың тәжірибесімен бөліскім келеді. Мен негізінен Hyperledger Fabric туралы айтатын боламын, бірақ мұнда сипатталған тәсілді кез келген рұқсат етілген блокчейнге экстраполяциялауға болады. Біздің зерттеуіміздің түпкі мақсаты - түпкілікті өнімді пайдалану жағымды және оны ұстау қиын емес болуы үшін кәсіпорынның блокчейн шешімдерін дайындау.
Мұнда ешқандай ашылулар, күтпеген шешімдер болмайды және ерекше әзірлемелер болмайды (өйткені менде жоқ). Мен жай ғана қарапайым тәжірибеммен бөліскім келеді, «бұл мүмкін болды» деп көрсеткім келеді және, мүмкін, басқа адамдардың жақсы және соншалықты жақсы емес шешімдер қабылдау тәжірибесі туралы түсініктемелерде оқығым келеді.
Мәселе: блокчейндер әлі масштабталмаған
Бүгінгі күні көптеген әзірлеушілердің күш-жігері блокчейнді әдемі қаптамадағы уақыт бомбасы емес, шын мәнінде ыңғайлы технологияға айналдыруға бағытталған. Мемлекеттік арналар, оптимистік жиынтық, плазма және бөлшектеу әдеттегідей болуы мүмкін. Бір күні. Немесе, мүмкін, TON ұшыруды тағы алты айға кейінге қалдырады, ал келесі плазмалық топ өз жұмысын тоқтатады. Біз келесі жол картасына сене аламыз және түнде керемет ақ қағаздарды оқи аламыз, бірақ осы жерде және қазір бізде бар нәрсемен бір нәрсе істеу керек. Бітіріңдер.
Ағымдағы жобада біздің команданың алдына қойылған міндет жалпы алғанда былай көрінеді: қарым-қатынасты сенім негізінде құрғысы келмейтін бірнеше мыңға жететін көптеген субъектілер бар; DLT-де арнайы өнімділік талаптарынсыз қарапайым компьютерлерде жұмыс істейтін және кез келген орталықтандырылған есеп жүйесінен кем емес пайдаланушы тәжірибесін қамтамасыз ететін шешімді құру қажет. Шешімнің артындағы технология деректерді зиянды манипуляциялау мүмкіндігін барынша азайтуы керек - сондықтан блокчейн осында.
Ақпараттық қағаздар мен БАҚ ұрандар бізге келесі даму секундына миллиондаған транзакцияларды жасауға мүмкіндік береді деп уәде етеді. Бұл шынымен не?
Mainnet Ethereum қазіргі уақытта ~ 30 tps жылдамдығымен жұмыс істейді. Осыған байланысты оны корпоративтік қажеттіліктерге сәйкес келетін блокчейн ретінде қабылдау қиын. Рұқсат етілген шешімдердің арасында 2000 т/с көрсететін эталондар бар () немесе 3000 шай қасық (, жарияланымда азырақ бар, бірақ эталон ескі консенсус қозғалтқышында жүргізілгенін ескеру қажет). болды , бұл ең нашар нәтиже бермеді, 20000 XNUMX т/с, бірақ әзірге бұл тек академиялық зерттеу, оның тұрақты орындалуын күтуде. Блокчейн әзірлеушілер бөлімін ұстауға мүмкіндігі бар корпорацияның мұндай көрсеткіштерге төтеп беруі екіталай. Бірақ мәселе тек өткізу қабілетінде ғана емес, кешіктіру де бар.
Кідіріс
Транзакция басталған сәттен бастап жүйе оны түпкілікті мақұлдауға дейінгі кідіріс хабарламаның валидация мен тапсырыс берудің барлық кезеңдерінен өту жылдамдығына ғана емес, блокты қалыптастыру параметрлеріне де байланысты. Біздің блокчейн бізге 1000000 10 488 tps жылдамдықпен әрекет етуге мүмкіндік берсе де, бірақ XNUMX МБ блокты жасау үшін XNUMX минут қажет болса да, бұл бізге оңайырақ бола ма?
Уақыттың қайда жұмсалатынын және оның блок құру параметрлерімен қалай байланысты екенін түсіну үшін Hyperledger Fabric жүйесіндегі транзакцияның өмірлік циклін толығырақ қарастырайық.
осы жерден алынған:
(1) Клиент транзакция жасайды, оны индоссаторларға жібереді, соңғысы транзакцияны имитациялайды (ағымдағы күйге тізбек кодымен енгізілген өзгертулерді қолданады, бірақ бухгалтерлік кітапқа міндеттеме жасамайды) және RWSet - кілт атауларын, нұсқаларын және мәндерін алады CouchDB коллекциясынан алынған, (2) индоссанттар клиентке қол қойылған RWSet жібереді, (3) клиент не барлық қажетті әріптестердің (индоссанттар) қолдарының бар-жоғын тексереді, содан кейін транзакцияны тапсырыс беру қызметіне жібереді. , немесе оны тексерусіз жібереді (тексеру кейінірек орындалады), тапсырыс беру қызметі блокты құрайды және (4) тек индоссанттарға емес, барлық әріптестерге қайтарады; әріптестер оқу жинағындағы негізгі нұсқалардың дерекқордағы нұсқаларға сәйкестігін, барлық индоссанттардың қолдары бар екенін тексереді және соңында блокты жасайды.
Бірақ бұл бәрі емес. «Тапсырыс беруші блокты құрайды» сөздері транзакциялардың ретін ғана емес, сонымен қатар көшбасшыдан ізбасарларға және кері 3 желілік сұранысты жасырады: көшбасшы журналға хабарлама қосады, оны ізбасарларға жібереді, соңғысы оны қосады. олардың журналына, көшбасшыға сәтті репликацияның растауын жібереді, көшбасшы хабарламаны орындайды, ізбасарларға міндеттеме растауын жібереді, ізбасарлар міндеттейді. Блокты қалыптастырудың мөлшері мен уақыты неғұрлым аз болса, тапсырыс беру қызметі соғұрлым жиі консенсус орнатуға мәжбүр болады. Hyperledger Fabric блокты қалыптастырудың екі параметріне ие: BatchTimeout - блокты қалыптастыру уақыты және BatchSize - блок өлшемі (транзакциялар саны және блоктың байттағы өлшемі). Параметрлердің бірі шекке жеткенде жаңа блок шығарылады. Тапсырыс түйіндері неғұрлым көп болса, соғұрлым бұл ұзаққа созылады. Сондықтан BatchTimeout және BatchSize ұлғайту қажет. Бірақ RWSets нұсқаланғандықтан, біз жасайтын блок неғұрлым үлкен болса, MVCC қақтығыстарының ықтималдығы соғұрлым жоғары болады. Сонымен қатар, BatchTimeout ұлғайған сайын, UX апатты түрде нашарлайды. Бұл мәселелерді шешудің келесі схемасы мен үшін ақылға қонымды және түсінікті болып көрінеді.
Блоктың аяқталуын күтуден қалай аулақ болуға және транзакция күйін бақылау мүмкіндігін жоғалтпауға болады
Қалыптастыру уақыты мен блок өлшемі неғұрлым ұзақ болса, блокчейннің өткізу қабілеті соғұрлым жоғары болады. Біреуі екіншісінен тікелей шықпайды, бірақ RAFT-те консенсус орнату үшін көшбасшыдан ізбасарларға және кері қарай үш желілік сұрау қажет екенін есте ұстаған жөн. Тапсырыс түйіндері неғұрлым көп болса, соғұрлым бұл ұзаққа созылады. Блоктың қалыптасу мөлшері мен уақыты неғұрлым аз болса, соғұрлым мұндай өзара әрекеттесулер көп болады. Түпкі пайдаланушы үшін жүйенің жауап беру уақытын арттырмай, генерациялау уақыты мен блок өлшемін қалай арттыруға болады?
Біріншіден, біз үлкен блок өлшемінен туындаған MVCC қайшылықтарын қандай да бір жолмен шешуіміз керек, олар бірдей нұсқасы бар әртүрлі RWSets қамтуы мүмкін. Әлбетте, клиент жағында (blockchain желісіне қатысты, бұл сервер болуы мүмкін, және мен оны айтамын) сізге қажет MVCC қақтығыс өңдеушісі, ол бөлек қызмет немесе қайталау логикасы бар транзакцияны бастайтын қоңыраудың үстіндегі кәдімгі декоратор болуы мүмкін.
Қайталау экспоненциалды стратегиямен жүзеге асырылуы мүмкін, бірақ кейін кідіріс экспоненциалды түрде төмендейді. Сондықтан сіз белгілі бір шағын шектеулер шегінде рандомизацияланған қайталауды немесе тұрақты әрекетті пайдалануыңыз керек. Бірінші нұсқада ықтимал соқтығыстарды ескере отырып.
Келесі қадам - клиенттің жүйемен әрекеттесуін 15, 30 немесе 10000000 секунд күтпеу үшін асинхронды ету, біз оны BatchTimeout ретінде орнатамыз. Бірақ сонымен бірге транзакциямен басталған өзгерістер блокчейнде жазылмағанын/тіркелмегенін тексеру мүмкіндігін сақтау қажет.
Мәліметтер базасын транзакция күйін сақтау үшін пайдалануға болады. Пайдаланудың қарапайымдылығына байланысты ең қарапайым опция CouchDB болып табылады: дерекқорда қораптан тыс UI, REST API бар және ол үшін репликацияны және бөлшектеуді оңай орнатуға болады. Әлемдік күйді сақтау үшін Fabric қолданбасын пайдаланатын бірдей CouchDB данасында жай ғана бөлек топтама жасауға болады. Бізге осы құжаттардың түрлерін сақтау керек.
{
Status string // Статус транзакции: "pending", "done", "failed"
TxID: string // ID транзакции
Error: string // optional, сообщение об ошибке
}Бұл құжат транзакция әріптестерге жіберілмес бұрын дерекқорға жазылады, егер бұл жасау операциясы болса, нысан идентификаторы пайдаланушыға қайтарылады (сол идентификатор кілт ретінде пайдаланылады), содан кейін Күй, TxID және Қате өрістері сәйкес ақпарат әріптестерден алынған сайын жаңартылады.
Бұл схемада пайдаланушы блоктың түпкілікті қалыптасуын күтпейді, экранда айналу дөңгелегін 10 секунд бақылайды, ол жүйеден жедел жауап алады және жұмысын жалғастырады.
Біз транзакция күйлерін сақтау үшін BoltDB таңдадық, өйткені бізге жадты үнемдеу керек және бөлек дерекқор серверімен желілік өзара әрекеттесу үшін уақытты босқа кетіргіміз келмейді, әсіресе бұл өзара әрекеттесу кәдімгі мәтіндік хаттаманы пайдалану кезінде орын алса. Айтпақшы, сіз CouchDB-ті жоғарыда сипатталған схеманы орындау үшін немесе жай ғана әлемдік күйді сақтау үшін пайдаланасыз ба, кез келген жағдайда CouchDB-де деректерді сақтау жолын оңтайландыру мағынасы бар. Әдепкі бойынша, CouchDB жүйесінде b-ағаш түйіндерінің өлшемі 1279 байт, бұл дискідегі сектор өлшемінен әлдеқайда аз, яғни ағашты оқу және қайта теңестіру дискіге көбірек физикалық қатынасты қажет етеді. Оңтайлы өлшем стандартқа сәйкес келеді және 4 килобайтты құрайды. Оңтайландыру үшін біз параметрді орнатуымыз керек btree_chunk_size 4096-ға тең CouchDB конфигурация файлында. BoltDB үшін мұндай қолмен араласу .
Кері қысым: буферлік стратегия
Бірақ хабарламалар көп болуы мүмкін. Диаграммада көрсетілгендерден басқа ондаған басқа қызметтермен ресурстарды бөлісе отырып, жүйе басқара алатыннан көп - және мұның бәрі Intellij Idea іске қосу өте жалықтыратын машиналарда да мінсіз жұмыс істеуі керек.
Өндіруші мен тұтынушының коммуникациялық жүйелерінің әртүрлі сыйымдылығы мәселесі әртүрлі жолдармен шешіледі. Не істей алатынымызды көрейік.
Тамшы: Біз T секунд ішінде ең көбі X транзакцияны өңдеуге қабілеттіміз деп айта аламыз. Бұл шектен асатын барлық сұраулар қабылданбайды. Бұл өте қарапайым, бірақ содан кейін UX туралы ұмытуға болады.
басқару: тұтынушыда жүктемеге байланысты өндірушінің TPS-ін басқара алатын интерфейстің қандай да бір түрі болуы керек. Жаман емес, бірақ бұл интерфейсті жүзеге асыру үшін жүктемені жасайтын клиенттің әзірлеушілеріне міндеттер жүктейді. Бұл біз үшін қолайсыз, өйткені блокчейн болашақта бұрыннан бар көптеген жүйелерге біріктіріледі.
Буферлеу: Кіріс деректер ағынына қарсы тұрудың орнына, біз бұл ағынды буферлеп, оны қажетті жылдамдықта өңдей аламыз. Егер біз жақсы пайдаланушы тәжірибесін ұсынғымыз келсе, бұл ең жақсы шешім екені анық. Біз буферді RabbitMQ жүйесінде кезек арқылы іске асырдық.
Схемаға екі жаңа әрекет қосылды: (1) API сұрауы келгеннен кейін транзакцияны шақыруға қажетті параметрлері бар хабарлама кезекке қойылады және клиент транзакцияны қабылдағаны туралы хабарлама алады. жүйе, (2) сервер деректерді кезектен конфигурацияда көрсетілген жылдамдықпен оқиды; транзакцияны бастайды және күй қоймасындағы деректерді жаңартады.
Енді сіз пайдаланушыдан кідірістерді жасыра отырып, қалыптастыру уақытын арттырып, сыйымдылықты қалағаныңызша блоктай аласыз.
Басқа құралдар
Мұнда тізбекті код туралы ештеңе айтылмады, өйткені, әдетте, оңтайландыру үшін ештеңе жоқ. Chaincode мүмкіндігінше қарапайым және қауіпсіз болуы керек - бұл оған қажет нәрсе. Рамка бізге тізбекті кодты қарапайым және қауіпсіз жазуға көмектеседі S7 Techlab және статикалық анализатордан .
Сонымен қатар, біздің команда Fabric-пен жұмыс істеуді қарапайым және жағымды ету үшін утилиталар жинағын әзірлеуде: , үшін қызметтік бағдарлама (ұйымдарды, RAFT түйіндерін қосу/жою), утилита . Өз үлесіңізді қосқыңыз келсе, қош келдіңіз.
қорытынды
Бұл тәсіл Hyperledger Fabric-ті Quorum, басқа жеке Ethereum желілерімен (PoA немесе тіпті PoW) оңай ауыстыруға, нақты өткізу қабілеттілігін айтарлықтай азайтуға, бірақ сонымен бірге қалыпты UX деңгейін сақтауға (браузердегі пайдаланушылар үшін де, біріктірілген жүйелер үшін де) мүмкіндік береді. Схемадағы Fabric-ті Ethereum-мен ауыстырған кезде, сізге тек қайталау қызметінің/декоратордың логикасын MVCC қайшылықтарын өңдеуден атомдық емес ұлғаюға және қайта жіберуге өзгерту қажет болады. Буферлеу және күйді сақтау блокты қалыптастыру уақытынан жауап уақытын ажыратуға мүмкіндік берді. Енді сіз мыңдаған тапсырыс түйіндерін қоса аласыз және блоктар тым жиі құрылады деп қорықпай, тапсырыс беру қызметін жүктей аласыз.
Негізінде мен бөліскім келгені осы болды. Бұл біреудің жұмысына көмектессе, мен қуаныштымын.
Ақпарат көзі: www.habr.com