Дистрибуиран регистар за Wheelsets: искуство со Hyperledger Fabric

Здраво, јас работам во тимот на проектот DRD KP (дистрибуиран регистар на податоци за следење на животниот циклус на сетови на тркала). Овде сакам да го споделам искуството на нашиот тим во развојот на блокчејн на претпријатија за овој проект под ограничувањата на технологијата. Најмногу ќе зборувам за Hyperledger Fabric, но пристапот опишан овде може да се екстраполира на кој било дозволен блокчејн. Крајната цел на нашето истражување е да подготвиме решенија за блокчејн на претпријатија, така што финалниот производ е пријатен за употреба и не е премногу тежок за одржување.

Нема да има откритија, неочекувани решенија и нема да бидат истакнати уникатни случувања овде (затоа што немам). Сакам само да го споделам моето скромно искуство, да покажам дека „тоа беше можно“ и, можеби, да прочитам за искуствата на другите луѓе за донесување добри и не толку добри одлуки во коментарите.

Проблем: блокчејните сè уште не се зголемуваат

Денес, напорите на многу програмери се насочени кон тоа блокчејнот да биде навистина погодна технологија, а не темпирана бомба во убава обвивка. Државните канали, оптимистичкото соединување, плазмата и делењето веројатно ќе станат вообичаени. Некој ден. Или можеби TON повторно ќе го одложи лансирањето за шест месеци, а следната Плазма група ќе престане да постои. Можеме да веруваме во следниот патоказ и да читаме брилијантни бели весници ноќе, но овде и сега треба да направиме нешто со она што го имаме. Направете срање.

Задачата поставена за нашиот тим во тековниот проект генерално изгледа вака: има многу субјекти, кои достигнуваат неколку илјади, кои не сакаат да градат односи на доверба; Неопходно е да се изгради решение на DLT што ќе работи на обични компјутери без посебни барања за изведба и ќе обезбеди корисничко искуство не полошо од кој било централизиран сметководствен систем. Технологијата зад решението мора да ја минимизира можноста за злонамерна манипулација со податоците - затоа блокчејн е тука.

Паролите од белата книга и медиумите ни ветуваат дека следниот развој ќе ни овозможи да направиме милиони трансакции во секунда. Што е тоа навистина?

Mainnet Ethereum моментално работи со ~ 30 tps. Само поради ова, тешко е да се сфати како блокчејн на кој било начин погоден за корпоративните потреби. Меѓу дозволените решенија има репери кои покажуваат 2000 tps (кворум) или 3000 tps (Хиперлегер ткаенина, има малку помалку во публикацијата, но треба да се земе предвид дека реперот беше спроведен на стариот консензус мотор). Беше обид за радикална обработка на ткаенина, кој не даде најлоши резултати, 20000 tps, но засега ова е само академско истражување, кое чека стабилна имплементација. Малку е веројатно дека корпорацијата која може да си дозволи да одржува оддел на развивачи на блокчејн ќе ги поднесе таквите индикатори. Но, проблемот не е само пропусната моќ, има и латентност.

Латентност

Доцнењето од моментот кога трансакцијата е иницирана до нејзиното конечно одобрување од системот не зависи само од брзината со која пораката поминува низ сите фази на валидација и нарачка, туку и од параметрите за формирање блок. Дури и ако нашиот блокчејн ни дозволува да се заложиме со брзина од 1000000 tps, но потребни се 10 минути за да генерира блок од 488 MB, дали ќе ни биде полесно?

Ајде внимателно да го разгледаме животниот циклус на трансакцијата во 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 конфликтите предизвикани од голема големина на блок, кој може да вклучува различни RWSets со иста верзија. Очигледно, на страната на клиентот (во однос на блокчејн мрежата, ова може да биде задниот дел, и мислам на тоа) ви треба MVCC управувач со конфликти, што може да биде или посебна услуга или обичен декоратор над повикот што ја иницира трансакцијата со логика за повторен обид.

Обидете се повторно може да се имплементира со експоненцијална стратегија, но тогаш доцнењето ќе се деградира исто толку експоненцијално. Значи, треба да користите или рандомизирано повторно обид во одредени мали граници, или константно. Со поглед на можните судири во првата опција.

Следниот чекор е да ја направиме интеракцијата на клиентот со системот асинхрона за да не чека 15, 30 или 10000000 секунди, кои ќе ги поставиме како BatchTimeout. Но, во исто време, неопходно е да се одржи способноста да се потврди дека промените иницирани од трансакцијата се/не се евидентирани во блокчејнот.
Може да се користи база на податоци за складирање на статусот на трансакцијата. Наједноставната опција е CouchDB поради неговата леснотија на користење: базата на податоци има интерфејс надвор од кутијата, REST API, и лесно можете да поставите репликација и споделување за неа. Можете едноставно да креирате посебна колекција во истиот примерок на CouchDB што користи Fabric за складирање на нејзината светска состојба. Треба да ги складираме овие типови документи.

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

Овој документ се запишува во базата на податоци пред трансакцијата да биде испратена до врсниците, ID на ентитетот се враќа на корисникот (истата ID се користи како клуч) ако ова е операција за создавање, а потоа полињата Статус, TxID и Грешка се се ажурираат како што се добиваат релевантни информации од врсниците.

Во оваа шема, корисникот не чека блокот конечно да се формира, гледајќи го тркалото што се врти на екранот 10 секунди, тој добива моментален одговор од системот и продолжува да работи.

Го избравме BoltDB за складирање на статуси на трансакции затоа што треба да заштедиме меморија и не сакаме да губиме време на мрежна интеракција со посебен сервер за бази на податоци, особено кога оваа интеракција се јавува со помош на протокол за обичен текст. Патем, без разлика дали користите CouchDB за имплементирање на шемата опишана погоре или едноставно за складирање на светската состојба, во секој случај има смисла да се оптимизира начинот на складирање на податоците во CouchDB. Стандардно, во CouchDB, големината на јазлите b-дрво е 1279 бајти, што е многу помало од големината на секторот на дискот, што значи дека и читањето и ребалансирањето на дрвото ќе бараат поголем физички пристап до дискот. Оптималната големина одговара на стандардот Напреден формат и е 4 килобајти. За да се оптимизира, треба да го поставиме параметарот btree_chunk_size еднаква на 4096 во конфигурациската датотека CouchDB. За BoltDB таква рачна интервенција не е потребно.

Повратен притисок: тампон стратегија

Но, може да има многу пораки. Повеќе отколку што може да поднесе системот, споделување ресурси со дузина други услуги покрај оние прикажани на дијаграмот - и сето тоа би требало да функционира беспрекорно дури и на машините на кои работењето на Intellij Idea би било крајно досадно.

Проблемот со различните капацитети на комуникациските системи, производител и потрошувач, се решава на различни начини. Ајде да видиме што би можеле да направиме.

Спуштање: Можеме да тврдиме дека сме способни да обработиме најмногу X трансакции за T секунди. Сите барања што ја надминуваат оваа граница се отфрлени. Ова е прилично едноставно, но тогаш можете да заборавите на UX.

Контролирање: потрошувачот мора да има некаков интерфејс преку кој, во зависност од оптоварувањето, може да го контролира TPS на производителот. Не е лошо, но им наметнува обврски на развивачите на клиентот што го создаваат оптоварувањето за имплементација на овој интерфејс. Ова е неприфатливо за нас, бидејќи блокчејн во иднина ќе биде интегриран во голем број одамна постоечки системи.

Буферинг: Наместо да се обидуваме да се спротивставиме на протокот на влезни податоци, можеме да го одбраниме овој поток и да го обработиме со потребната брзина. Очигледно ова е најдоброто решение доколку сакаме да обезбедиме добро корисничко искуство. Ние го имплементиравме баферот користејќи редица во RabbitMQ.

Две нови дејства се додадени во шемата: (1) откако ќе пристигне барање до API, во редот се става порака со параметрите неопходни за повикување трансакција, а клиентот добива порака дека трансакцијата е прифатена од системот, (2) задниот дел ги чита податоците со брзината наведена во конфигурацијата од редот; иницира трансакција и ги ажурира податоците во продавницата за статус.
Сега можете да го зголемите времето на формирање и да го блокирате капацитетот колку што сакате, криејќи ги доцнењата од корисникот.

Други алатки

Ништо не беше кажано овде за верижниот код, бидејќи, како по правило, нема што да се оптимизира во него. Синџирниот код треба да биде што е можно поедноставен и безбеден - тоа е сè што се бара од него. Рамката ни помага да напишеме верижен код едноставно и безбедно CCKit од S7 Techlab и статички анализатор оживее^CC.

Покрај тоа, нашиот тим развива збир на комунални услуги за да ја направи работата со Fabric едноставна и пријатна: истражувач на блокчејн, алатка за автоматски промени на мрежната конфигурација (додавање/отстранување на организации, RAFT јазли), алатка за одземање на потврди и отстранување на идентитетот. Доколку сакате да придонесете, добредојдени сте.

Заклучок

Овој пристап ви овозможува лесно да го замените Hyperledger Fabric со Quorum, други приватни мрежи на Ethereum (PoA или дури и PoW), значително да ја намалите вистинската пропусност, но во исто време да одржувате нормален UX (и за корисниците во прелистувачот и за интегрираните системи). Кога го заменувате Fabric со Ethereum во шемата, ќе треба само да ја смените логиката на услугата/декораторот за повторно обид од обработка на MVCC конфликти до атомско зголемување и повторно испраќање. Баферирањето и складирањето на статусот овозможија да се одвои времето на одговор од времето на формирање блок. Сега можете да додадете илјадници јазли за нарачки и да не се плашите дека блоковите се формираат премногу често и да ја вчитате услугата за нарачки.

Во суштина, тоа е сè што сакав да споделам. Ќе ми биде драго ако ова некому му помогне во работата.

Извор: www.habr.com