Разпределен регистър за комплекти колела: Опит с Hyperledger Fabric

Здравейте, работя в екипа на проекта DRD KP (разпределен регистър на данни за наблюдение на жизнения цикъл на колоосите). Тук бих искал да споделя опита на нашия екип в разработването на корпоративен блокчейн за този проект при ограниченията на технологиите. В по-голямата си част ще говоря за Hyperledger Fabric, но подходът, описан тук, може да бъде екстраполиран към всеки разрешен блокчейн. Крайната цел на нашето изследване е да подготвим корпоративни блокчейн решения по такъв начин, че крайният продукт да е приятен за използване и да не е твърде труден за поддръжка.

Тук няма да има открития, неочаквани решения и уникални разработки (защото ги нямам). Просто искам да споделя своя скромен опит, да покажа, че „е възможно“ и може би да прочета за опита на някой друг във вземането на добри и не толкова добри решения в коментарите.

Проблем: блоковите вериги все още не могат да се мащабират

Днес усилията на много разработчици са насочени към превръщането на блокчейна в наистина удобна технология, а не в тиктакаща бомба със закъснител в красива обвивка. Държавни канали, оптимистичен сбор, плазма и шардинг може да станат обичайни. Някой ден. Или може би TON отново ще отложи стартирането с шест месеца и следващата Plasma Group ще престане да съществува. Можем да вярваме в друга пътна карта и да четем брилянтни бели книги през нощта, но тук и сега трябва да направим нещо с това, което имаме. Свърши глупостите.

Задачата, възложена на нашия екип в настоящия проект, изглежда най-общо така: има много субекти, достигащи няколко хиляди, които не искат да изграждат отношения на доверие; необходимо е да се изгради на DLT решение, което ще работи на обикновени компютри без специални изисквания за производителност и ще осигури потребителско изживяване не по-лошо от всички централизирани счетоводни системи. Технологията зад решението трябва да сведе до минимум възможността за злонамерено манипулиране на данни – ето защо блокчейн е тук.

Лозунги от бели книги и медии ни обещават, че следващото развитие ще позволи милиони транзакции в секунда. Какво всъщност е?

В момента Mainnet Ethereum работи с ~30 tps. Само поради това е трудно да се възприеме като блокчейн, който по някакъв начин е подходящ за корпоративни нужди. Сред разрешените решения са известни бенчмаркове, показващи 2000 tps (кворум) или 3000 tps (Плат за хиперлингер, има малко по-малко в публикацията, но имайте предвид, че бенчмаркът е извършен на стария консенсусен двигател). Беше опит за радикално преработване на Fabric, което не даде най-лошите резултати, 20000 XNUMX tps, но засега това са само академични изследвания, които чакат своето стабилно внедряване. Малко вероятно е корпорация, която може да си позволи да поддържа отдел от разработчици на блокчейн, да се примири с такива показатели. Но проблемът не е само в пропускателната способност, има и забавяне.

латентност

Забавянето от момента на иницииране на транзакция до нейното окончателно одобрение от системата зависи не само от скоростта на преминаване на съобщението през всички етапи на валидиране и подреждане, но и от параметрите за формиране на блока. Дори ако нашата блокова верига ни позволява да се ангажираме с 1000000 10 488 tps, но отнема XNUMX минути, за да формираме XNUMXMB блок, ще стане ли по-лесно за нас?

Нека да разгледаме по-подробно жизнения цикъл на транзакция в 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 XNUMX XNUMX секунди, което ще зададем като BatchTimeout. Но в същото време е необходимо да се запази способността да се гарантира, че промените, инициирани от транзакцията, са записани / не са записани в блокчейна.
Може да се използва база данни за съхраняване на състоянието на транзакциите. Най-лесният вариант е CouchDB поради лесната му употреба: базата данни има потребителски интерфейс от кутията, REST API и можете лесно да настроите репликация и шардинг за нея. Можете просто да създадете отделна колекция в същия екземпляр на CouchDB, който Fabric използва за съхраняване на световното си състояние. Трябва да съхраняваме документи от този вид.

{
 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 би била изключително досадна.

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

отпадането: можем да твърдим, че можем да обработим най-много X транзакции за T секунди. Всички заявки, които надвишават този лимит, се премахват. Доста е просто, но тогава можете да забравите за UX.

Контролиране: потребителят трябва да има някакъв интерфейс, чрез който в зависимост от натоварването да контролира tps на производителя. Не е лошо, но налага задължение на разработчиците на клиента за зареждане да внедрят този интерфейс. За нас това е неприемливо, тъй като блокчейн в бъдеще ще бъде интегриран в голям брой отдавна съществуващи системи.

буфериране: вместо да се опитваме да се съпротивляваме на входния поток от данни, можем да буферираме този поток и да го обработваме с необходимата скорост. Очевидно това е най-доброто решение, ако искаме да осигурим добро потребителско изживяване. Ние внедрихме буфера, използвайки опашка в RabbitMQ.

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

Други инструменти

Тук не беше казано нищо за верижния код, защото обикновено в него няма какво да се оптимизира. Верижният код трябва да бъде възможно най-прост и сигурен - това е всичко, което се изисква от него. Рамката ни помага много да пишем верижен код просто и безопасно. CSKit от S7 Techlab и статичен анализатор съживявам^CC.

В допълнение, нашият екип разработва набор от помощни програми, за да направи работата с Fabric проста и приятна: блокчейн изследовател, помощна програма за автоматично преконфигуриране на мрежата (добавяне/премахване на организации, RAFT възли), помощна програма за анулиране на сертификат и премахване на самоличност. Ако искате да допринесете, добре дошли.

Заключение

Този подход улеснява замяната на Hyperledger Fabric с Quorum, други частни Ethereum мрежи (PoA или дори PoW), значително намалява реалната пропускателна способност, но в същото време поддържа нормален UX (както за потребителите в браузъра, така и от страна на интегрираните системи ). Когато замените Fabric с Ethereum в схемата, само логиката на услугата за повторен опит/декоратора ще трябва да бъде променена от обработка на MVCC конфликти към атомно nonce увеличение и повторно изпращане. Буферирането и съхранението на състоянието направиха възможно отделянето на времето за реакция от времето за формиране на блок. Сега можете да добавите хиляди възли за поръчка и да не се страхувате, че блоковете се формират твърде често и зареждат услугата за поръчка.

Общо взето това е всичко, което исках да споделя. Ще се радвам, ако помогне на някого в работата му.

Източник: www.habr.com