Омилено прашање за кој било дистрибуиран систем од нетехничко лице е „Колку tps има на вашиот блокчејн? Меѓутоа, бројот што е даден како одговор обично има малку заедничко со она што прашувачот би сакал да го слушне. Всушност, тој сакаше да праша „дали вашиот блокчејн одговара на моите деловни барања“, и овие барања не се еден број, туку многу услови - тука се толеранцијата на грешки во мрежата, барањата за конечност, големини, природата на трансакциите и многу други параметри. Значи, одговорот на прашањето „колку tps“ веројатно нема да биде едноставен и речиси никогаш не е целосен. Дистрибуиран систем со десетици или стотици јазли кои вршат доста сложени пресметки може да биде во огромен број различни состојби поврзани со состојбата на мрежата, содржината на блокчејнот, технички неуспеси, економски проблеми, напади на мрежата и многу други причини . Фазите во кои се можни проблеми со перформансите се разликуваат од традиционалните услуги, а блокчејн мрежен сервер е мрежна услуга која ја комбинира функционалноста на базата на податоци, веб-серверот и клиентот за торент, што го прави исклучително сложен во однос на профилот на оптоварување на сите потсистеми. : процесор, меморија, мрежа, складирање

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

Фази на барање за услуга од клиент на блокчејн

За да зборувате искрено за квалитетот на која било повеќе или помалку сложена услуга, треба да ги земете предвид не само просечните вредности, туку и максимумот/минимумот, медијаните, перцентилите. Теоретски, можеме да зборуваме за 1000 tps во некој блокчејн, но ако 900 трансакции беа завршени со огромна брзина, а 100 беа „заглавени“ неколку секунди, тогаш просечното време собрано за сите трансакции не е сосема фер метрика за клиентот. кој не можев да ја завршам трансакцијата за неколку секунди. Привремените „дупки“ предизвикани од пропуштени кругови на консензус или поделба на мрежата може многу да ја уништат услугата што покажала одлични перформанси на тест клупи.

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

1. трансакцијата се формира на клиентот
2. трансакцијата е потпишана на клиентот
3. клиентот избира еден од јазлите и ја испраќа својата трансакција до него
4. клиентот се претплати на ажурирања на државната база на податоци на јазолот, чекајќи да се појават резултатите од неговата трансакција
5. јазолот ја дистрибуира трансакцијата преку p2p мрежата
6. неколку или еден БП (производител на блокови) обработува акумулирани трансакции, ажурирајќи ја државната база на податоци
7. BP формира нов блок откако ќе го обработи потребниот број трансакции
8. BP дистрибуира нов блок преку p2p мрежата
9. новиот блок се доставува до јазолот до кој пристапува клиентот
10. јазолот ја ажурира државната база на податоци
11. јазолот го гледа ажурирањето во врска со клиентот и му испраќа известување за трансакцијата

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

Подготовка на трансакција на страната на клиентот

Да почнеме со првите две точки: трансакцијата е формирана и потпишана од клиентот. Чудно е доволно, но ова може да биде и тесно грло на перформансите на блокчејн од гледна точка на клиентот. Ова е невообичаено за централизираните сервиси, кои ги преземаат сите пресметки и операции со податоци, а клиентот едноставно подготвува кратко барање со кое може да побара голема количина на податоци или пресметки, добивајќи готов резултат. Во блокчејновите, кодот на клиентот станува сè помоќен, а јадрото на блокчејн станува сè полесно, а масивни компјутерски задачи обично се пренесуваат на клиентскиот софтвер. Во блокчејновите, постојат клиенти кои можат да подготват една трансакција прилично долго време (зборувам за различни докази за меркл, прегледни докази, потписи на прагови и други сложени операции на страната на клиентот). Добар пример за лесна проверка на синџирот и тешка подготовка на трансакција на клиентот е доказ за членство во список заснован на Merkle-tree, овде Член.

Исто така, не заборавајте дека кодот на клиентот не едноставно испраќа трансакции до блокчејнот, туку прво ја прашува состојбата на блокчејнот - и оваа активност може да влијае на застојот на мрежата и блокчејн јазлите. Значи, кога се прават мерења, би било разумно да се емулира однесувањето на кодот на клиентот што е можно поцелосно. Дури и ако во вашиот блокчејн има обични лесни клиенти кои ставаат редовен дигитален потпис на наједноставната трансакција за да пренесат некое средство, секоја година сè уште има се помасовни пресметки на клиентот, крипто алгоритмите стануваат се посилни, а овој дел од обработката може да се претвори во значајно тесно грло во иднина. Затоа, бидете внимателни и не пропуштајте ја ситуацијата кога во трансакција во траење од 3.5 секунди, се трошат 2.5 секунди за подготовка и потпишување на трансакцијата, а 1.0 за испраќање на мрежата и чекање одговор. За да ги процените ризиците од ова тесно грло, треба да собирате метрика од машините на клиентите, а не само од блокчејн јазлите.

Испраќање трансакција и следење на нејзиниот статус

Следниот чекор е да ја испратите трансакцијата до избраниот блокчејн јазол и да го добиете статусот на прифаќање во базенот на трансакции. Оваа фаза е слична на редовен пристап до базата на податоци; јазолот мора да ја сними трансакцијата во базенот и да започне со дистрибуција на информации за неа преку p2p мрежата. Пристапот за оценување на перформансите овде е сличен на проценката на перформансите на традиционалните микросервиси на Web API, а самите трансакции во блокчејн може да се ажурираат и активно да го менуваат нивниот статус. Општо земено, ажурирањето на информациите за трансакциите на некои блокчејнови може да се случи повеќе пати, на пример кога се префрлате помеѓу вилушките на синџирот или кога BP ја објавуваат својата намера да вклучат трансакција во блок. Ограничувањата на големината на овој базен и бројот на трансакции во него може да влијаат на перформансите на блокчејнот. Ако збирот на трансакции е исполнет до максималната можна големина или не се вклопува во RAM меморијата, перформансите на мрежата може нагло да паднат. Блокчејновите немаат централизирано средство за заштита од поплава од непотребни пораки и ако блокчејн поддржува трансакции со голем обем и ниски такси, тоа може да предизвика прелевање на базенот на трансакции - уште едно потенцијално тесно грло во перформансите.

Во блокчејн, клиентот испраќа трансакција до кој било блокчејн јазол што му се допаѓа, хашот на трансакцијата обично му е познат на клиентот пред да испрати, така што сè што треба да направи е да ја постигне врската и, по преносот, да почека блокчејнот да се промени. неговата состојба, овозможувајќи му на трансакцијата. Забележете дека со мерење на „tps“ може да добиете сосема различни резултати за различни методи на поврзување со блокчејн јазол. Ова може да биде обичен HTTP RPC или WebSocket што ви овозможува да ја имплементирате шемата „претплата“. Во вториот случај, клиентот ќе добие известување порано, а јазолот ќе потроши помалку ресурси (главно меморија и сообраќај) на одговорите за статусот на трансакцијата. Значи, при мерење на „tps“ потребно е да се земе предвид начинот на кој клиентите се поврзуваат со јазлите. Затоа, за да се проценат ризиците од ова тесно грло, блокчејнот на репер мора да може да ги емулира клиентите и со WebSocket и со HTTP RPC барања, во пропорции што одговараат на реалните мрежи, како и да ја менува природата на трансакциите и нивната големина.

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

Пренос на трансакции и блокови преку p2p мрежа

Во блокчејновите, вмрежувањето peer-to-peer (p2p) се користи за пренос на трансакции и блокови помеѓу учесниците. Трансакциите се шират низ мрежата, почнувајќи од еден од јазлите, сè додека не стигнат до производителите на врсни блокови, кои пакуваат трансакции во блокови и, користејќи го истиот p2p, дистрибуираат нови блокови до сите мрежни јазли. Основата на повеќето модерни p2p мрежи се различните модификации на протоколот Kademlia. тука е добро резиме на овој протокол, и тука - статија со различни мерења во мрежата BitTorrent, од која може да се разбере дека овој тип на мрежа е покомплексен и помалку предвидлив од строго конфигурирана мрежа на централизирана услуга. Исто така, тука статија за мерење на различни интересни метрики за јазлите на Ethereum.

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

Значи, трансакцијата сега треба да се дистрибуира низ мрежата за да можат производителите на блокови да ја видат и да ја вклучат во блокот. Јазолот активно „дистрибуира“ нова трансакција до сите и ја слуша мрежата, чекајќи блок во чиј индекс ќе се појави потребната трансакција за да го извести клиентот што чека. Времето што и е потребно на мрежата да префрли информации за нови трансакции и блокови едни на други во p2p мрежите зависи од многу голем број фактори: бројот на искрени јазли кои работат во близина (од мрежна гледна точка), „топол- горе“ од кешовите на овие јазли, големината на блоковите, трансакциите, природата на промените, географијата на мрежата, бројот на јазли и многу други фактори. Комплексните мерења на метриката на перформансите во таквите мрежи се сложена работа; потребно е истовремено да се процени времето за обработка на барањата и на клиентите и на врсниците (блокчејн јазли). Проблеми во кој било од механизмите p2p, неправилно исфрлање и кеширање на податоци, неефикасно управување со списоци на активни врсници и многу други фактори може да предизвикаат одложувања кои влијаат на ефикасноста на целата мрежа како целина, а ова тесно грло е најтешко да се анализира , тест и интерпретација на резултатите.

Обработка на блокчејн и ажурирање на државната база на податоци

Најважниот дел од блокчејнот е консензусниот алгоритам, неговата примена на новите блокови добиени од мрежата и обработката на трансакциите со евидентирање на резултатите во државната база на податоци. Додавањето нов блок на ланецот и потоа изборот на главниот синџир треба да работи што е можно побрзо. Меѓутоа, во реалниот живот, „треба“ не значи „работи“, и може, на пример, да се замисли ситуација кога два долги конкурентни синџири постојано се префрлаат меѓу себе, менувајќи ги метаподатоците на илјадници трансакции во базенот на секој прекинувач. , и постојано враќање назад на државната база на податоци. Оваа фаза, во смисла на дефинирање на тесно грло, е поедноставна од p2p мрежниот слој, бидејќи извршувањето на трансакциите и алгоритмот за консензус се строго детерминистички, и тука е полесно да се измери било што.
Главната работа е да не се меша случајната деградација во изведбата на оваа фаза со мрежните проблеми - јазлите се побавни во доставувањето блокови и информации за главниот синџир, а за надворешен клиент ова може да изгледа како бавна мрежа, иако проблемот лежи во сосема друго место.

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

Трансакциите што ги обработуваат виртуелната машина можат да бидат корисен извор на информации што може да ја оптимизираат работата на блокчејнот. Бројот на распределби на меморијата, бројот на инструкции за читање/запишување и други метрики поврзани со ефикасноста на извршувањето на кодот на договорот може да обезбедат многу корисни информации за програмерите. Во исто време, паметните договори се програми, што значи дека теоретски тие можат да потрошат кој било од ресурсите: процесор/меморија/мрежа/меморија, така што обработката на трансакциите е прилично неизвесна фаза, која, покрај тоа, многу се менува кога се движите помеѓу верзии и при промена на шифрите на договор. Затоа, потребни се и метрика поврзани со обработката на трансакциите за ефикасно да се оптимизираат перформансите на блокчејнот.

Прием од клиентот за известување за вклучување на трансакција во блокчејн

Ова е последната фаза од клиентот на блокчејн кој ја добива услугата; во споредба со другите фази, нема големи трошоци, но сепак вреди да се разгледа можноста клиентот да добие обемен одговор од јазолот (на пример, паметен договор враќајќи низа податоци). Во секој случај, оваа точка е најважна за оној што го постави прашањето „колку tps има во вашиот блокчејн?“, бидејќи Во овој момент се евидентира времето на добивање на услугата.

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

Заклучок

Како резултат на тоа, можеме да ги опишеме типовите на операции извршени на блокчејн и да ги поделиме во неколку категории:

1. криптографски трансформации, доказна конструкција
2. peer-to-peer вмрежување, трансакција и блок репликација
3. обработка на трансакции, извршување на паметни договори
4. примена на промени во блокчејнот во државната база на податоци, ажурирање на податоците за трансакциите и блоковите
5. барања само за читање за наведена база на податоци, API за блокчејн јазол, услуги за претплата

Општо земено, техничките барања за модерни блокчејн јазли се исклучително сериозни - брзи процесори за криптографија, голема количина RAM меморија за складирање и брз пристап до државната база на податоци, мрежна интеракција со користење на голем број истовремено отворени врски и големо складирање. Ваквите високи барања и изобилството на различни видови операции неизбежно водат до фактот дека јазлите можеби немаат доволно ресурси, а потоа која било од фазите дискутирани погоре може да стане уште едно тесно грло за севкупните перформанси на мрежата.

При дизајнирање и оценување на перформансите на блокчејновите, ќе мора да ги земете предвид сите овие точки. За да го направите ова, треба да собирате и анализирате метрика истовремено од клиентите и мрежните јазли, да барате корелации меѓу нив, да го процените времето потребно за обезбедување услуги на клиентите, да ги земете предвид сите главни ресурси: процесор/меморија/мрежа/меморија , разбираат како се користат и влијаат еден на друг. Сето ова го прави споредувањето на брзините на различни блокчејнови во форма на „колку TPS“ крајно неблагодарна задача, бидејќи има огромен број различни конфигурации и состојби. Во големите централизирани системи, кластери од стотици сервери, овие проблеми се исто така сложени и исто така бараат собирање на голем број различни метрики, но во блокчејните, поради p2p мрежите, виртуелните машини кои обработуваат договори, внатрешните економии, бројот на степени слободата е многу поголема, што го прави тестот дури и на неколку сервери, не е индикативен и покажува само крајно приближни вредности кои речиси немаат врска со реалноста.

Затоа, кога се развиваме во јадрото на блокчејнот, за да ги оцениме перформансите и да одговориме на прашањето „дали е подобрено во споредба со минатиот пат? ; без овие информации е исклучително тешко да се дебагира протоколите што работат со повеќе учесници.

Затоа, кога ќе го добиете прашањето „колку TPS има во вашиот блокчејн?“, понудете му чај и прашајте го дали е подготвен да погледне десетина графикони и да ги слуша сите три кутии со проблеми со перформансите на блокчејнот и вашите предлози за решавајќи ги...

Извор: www.habr.com