Что такое загруженность сети биткоин и как с ней справляться?
По данным CoinSpot, ежедневно в сети биткоина обрабатывается более 360 тысяч транзакций. Из-за ограничения в размере блока BTC, а также все возрастающей популярности этого актива, возникают значительные очереди при переводе монет. В некоторых случаях пользователи сети могут ждать коины на свой счет до двух дней. Это создает определенные неудобства, особенно если ВТС нужен быстро.
Итак, что такое загруженность сети биткоина и как узнать, существует ли очередь транзакций? Читайте об этом в нашей статье.
Почему в сети биткоина появляются очереди?
Очередь транзакций биткоин представляет собой некоторое количество операций в блокчейне, которые находятся в режиме ожидания подтверждения. Такая ситуация может возникнуть при наличии большого количества транзакций с низкой комиссией или при значительном повышении нагрузки на сеть по разным факторам. Конечно, это не единственные причины. А приемлемую работоспособность всей сети BTC обеспечивают майнеры со своими вычислительными мощностями. Именно они получают награду за добытый блок и оплату за все транзакции в нем.
В цепочке транзакций в первую очередь идет подтверждение тех из них, которые имеют самую высокую комиссию. Именно они имеют большой шанс «пройти» без задержек, т. к. они наиболее приоритетны для сети биткоина. Если экономить, то операция может исполняться даже более трех суток. В тех случаях, когда транзакция из-за низко установленной комиссии не может попасть в блок, все монеты возвращаются отправителю. Обычно это происходит по истечении трех суток.
Следует понимать, что обработка большого количества платежей в блокчейне BTC невозможна. Это связано с тем, что новый блок в сети появляется приблизительно каждые 10 минут. И в одном блоке может быть записано, а значит и проведено, около двух тысяч транзакций. В те моменты, когда биткоин «на коне» и его популярность растет, увеличивается и количество операций с ним. Если блокчейн чисто технически не успевает все обрабатывать вовремя, в мемпуле возникает очередь неподтвержденных транзакций биткоин.
Итак, на снижение скорости перевода BTC влияют такие факторы:
- небольшая плата за комиссию — менее дорогие сделки остаются в хвосте очереди;
- большое число сделок в очереди — блокчейн биткоина технически ограничен количеством возможных транзакций;
- небольшое количество переводимых монет, что сразу относит операцию в категорию низкоприоритетных.
Что делать с неподтвержденными транзакциями?
Если операция никак не проходит, а нагрузка блокчейна сети биткоина велика, это значит, что транзакция не может включиться в блок. Когда перевод не проходит уже длительное время, следует попробовать такие действия:
- Повысить размер комиссии. Для владельцев устаревших кошельков такое действие не подходит, т. к. у них нет такой возможности.
- Создать новый платеж и увеличить комиссию. С большой долей вероятности через некоторое время система отменит транзакцию с низкой комиссией, а проведет ― с более высокой. Однако также есть риск, что будут исполнены два платежа (а платежи в блокчейне необратимы).
- Применить CPFP. В этом случае отправитель может создать дочернюю организацию с более высоким вознаграждением.
- Использовать мультиподпись. С ее помощью возможно уменьшить количество затраченного времени на проведение сделки. Также это значительно повышает надежность транзакций.
При этом многие кошельки и онлайн-сервисы позволяют либо устанавливать комиссию за перевод, либо выбирать из предложенных вариантов (например, высокая, средняя или низкая). Для новичков можно рекомендовать использование средней комиссии: таким образом они смогут как избежать излишних расходов, так и не сталкиваться с ситуацией, когда их транзакция окажется неподтвержденной.
Сеть биткоина перегружена. О чем это может говорить
После халвинга в сети биткоина произошел резкий рост количества неподтвержденных транзакций. Согласно данным blockchain.com, к текущему моменту этот показатель достиг 72 МБ, в моменте поднимаясь до 98 МБ. С начала года он колебался в диапазоне от 0,3 до 15 МБ, изредка превышая это значение.
Текущий показатель в 72 МБ является вторым по величине с декабря 2017 г. и говорит о перегруженности сети монеты, то есть о переполнении мемпула. Сформировалась очередь из пользователей, желающих перевести биткоины. Но текущего количества майнеров недостаточно, чтобы удовлетворить спрос.
Это предположение подтверждается двумя другими метриками. Во-первых, упал хешрейт в сети первой криптовалюты. Он снизился на 40% после халвинга и теперь составляет 86 EH/s. Во-вторых, выросла средняя величина комиссии, которую берут майнеры за подтверждение транзакций. В апреле этот показатель варьировался до $0,4 до $0,9, сейчас достиг $6,6. Это говорит о том, что пользователи готовы платить больше, чтобы их средства перевели раньше других. Данные предоставлены сервисом bitinfocharts.com.
Перегруженность сети биткоина может говорить в пользу роста его стоимости. Например, 26 марта 2019 г. количество неподтвержденных транзакций в сети BTC в течение 10 дней взлетело на 24 500%, достигнув 43 МБ. Одновременно с этим начался рост стоимости первой криптовалюты, и за три месяца она подорожала с $4000 до $14 000.
Аналогичное переполнение сети произошло в начале ноября 2017 года. После этого курс главного цифрового актива в течение месяца вырос с $6000 до $20 000. Однако есть исключения. Например, последняя перегрузка блокчейна BTC случилась 15 ноября прошлого года. За ней ралли криптовалюты не последовало. Причиной переполнения мемпула мог быть сбой в системе сервиса Blockchain.com или же атака на блокчейн монеты сторонниками Bitcoin SV. Эта дата считается днем независимости проекта, так как тогда произошел хардфорк Bitcoin Cash, после которого появился альткоин BSV.
Другой причиной текущей перегрузки сети могло стать то, что часть майнинг-ферм в китайской провинции Сычуань отключила оборудование из-за нехватки электричества. С начала месяца нагрузка на сети региона выросла на 22%, в то же время объем воды в реках снизился на 20%, что привело к дефициту гидроэлектроэнергии. Это привело к падению хешрейта биткоина, а затем к заполнению мемпула.
Если цена биткоина будет оставаться на прежнем уровне или упадет, ситуация с перегрузкой сети может только усугубиться. Майнеры начнут отключать оборудование, так как добыча криптовалюты стала менее рентабельна после халвинга. В таком случае хешрейт продолжит снижаться, а нагрузка на блокчейн — расти.
Больше новостей о криптовалютах вы найдете в нашем телеграм-канале РБК-Крипто.
Как измерять производительность блокчейн сетей. Основные метрики
Существует много метрик, относящихся к логике и качеству работы блокчейна. Они помогают определить узкие места в коде и найти логические и оптимизационные проблемы в алгоритмах консенсуса и финальности в блокчейнах. Любая разработка распределенных систем, в том числе блокчейнов, требует анализа работы сразу множества узлов. Они позволяют команде проекта следить за состоянием всей блокчейн-сети, видеть проблемы с отдельными нодами, детектировать появление DoS атак на сеть и многое другое. Давайте рассмотрим основные из них. Let’s dive in.
“Transactions-per-second”
В случае распределенных систем, TPS — это очень капризное и неоднозначное число, которое не всегда отражает реальное качество предоставляемого пользователям сервиса. Измерения TPS пришли к нам из распределенных баз данных. TPS в базах данных — это некоторые стандартизованные для теста транзакции или их наборы (сколько то INSERT, сколько-то UPDATE, столько DELETE-ов на фоне постоянных SELECT) для жестко заданной конфигурации кластера или вообще на одной машине. Эти метрики обычно дают только приближенные оценки производительности распределенных БД или блокчейнов, так как время процессинга транзакции может сильно варьироваться в зависимости от множества факторов.
Базы данных, ориентированные на консистентность (см. “CAP-теорема”) не фиксируют транзакцию, пока не получат достаточное число подтверждений от других нод и это медленно. А базы данных, ориентированные на Availability, считают успешной транзакцию, которую просто удалось записать на диск. Они сразу отдают клиенту обновленные данные и это очень быстро (хотя в будущем, эта транзакция может быть откачена назад). Также, если транзакции, используемые в бенчмарке, обновляют лишь одну ячейку с данными, TPS явно будет выше, чем в случаях, когда транзакции могут затрагивать много ячеек и блокировать друг друга. Алгоритмы работы с этими блокировками в каждой БД реализованы по своему — как раз поэтому мы и не видим “соревнований по TPS” между Oracle, MSSQL, PostgreSQL с одной стороны и MongoDB, Redis, Tarantool с другой — уж очень разные внутренние механизмы и разные задачи.
По моему мнению, “измерить TPS” блокчейна означает провести полный комплекс измерений его производительности:
- в повторяемых условиях
- с близким к реальности числом валидаторов, производящих блоки
- используя различные виды транзакций:
- типовые для исследуемого блокчейна (например transfer() основной криптовалюты)
- нагружающие storage подсистему (большой объем изменений от каждой транзакции)
- нагружающие bandwidth (большой объем транзакции)
- нагружающие CPU (в случае массивных криптопреобразований или вычислений)
Чтобы говорить о заветных “transactions per second”, нужно описать все условия (число валидаторов, их гео-распределение, уровень packetloss и т.п.) и описать логику бенчмаркинга. В блокчейнах просто накатить транзакцию на внутреннюю БД не означает ее принятие консенсусом. Например, в случае c Proof-of-Work, статистически, транзакции не завершаются вообще никогда, и, если транзакция включена в блок на одной машине, это не означает, что она будет принята всей сетью (например, в случае победы другого форка).
Если в блокчейне есть дополнительный алгоритм обеспечения финальности транзакций (EOS, Ethereum 2.0, парачейны Polkadot, использующие консенсус с финальностью GRANDPA), то временем процессинга транзакции можно считать промежуток между тем, как нода “увидела” транзакцию и следующим финализированным блоком, куда эта транзакция была включена. Такие, более близкие к реальности “TPS” нечасто встретишь в обещаниях проектов. Они, естественно, ниже описанных в Whitepaper-ах, но зато максимально информативны.
Так что еще раз предупреждаю, в термин “TPS” может быть вложено очень много разных смыслов. Будьте скептичны и требуйте подробностей.
Метрики, специфичные для блокчейн сетей
Local TPS
Число обработанных нодой транзакций и max/avg/min время их обработки на локальной ноде очень удобно измерять, так как функции, выполняющие эту операцию, обычно явно выделены в коде. Можно просто измерить, сколько времени транзакция работала, обновляя state database. Эти транзакции, возможно, пока не приняты консенсусом, но уже прошли валидацию, и нода уже может отдавать клиенту обновленные данные (рассчитывая, что не появится форк цепочки).
Эта метрика не очень честная: если в качестве основной будет выбран другой форк цепочки, то статистику по откаченным транзакциям нужно тоже откатывать. Но для тестирования этим почти всегда можно пренебречь.Часто, именно это число пишут в кратких отчетах: “у нашего блокчейна вчера получилось 8 000 tps”, так как ее просто измерить — достаточно одной запущенной ноды и скрипта, который ее нагружает. В этом случае отсутствует сетевая задержка, которая замедляет достижение сетью консенсуса, а метрика показывает быстродействие state database без влияния сети. Это число не является реальной пропускной способностью блокчейн-сети, но показывает предел, к которому она будет стремиться, если консенсус и сеть будут достаточно быстрыми.
Результат работы любой блокчейн-транзакции — несколько атомарных обновлений storage. Например, платежная транзакция в Bitcoin — это удаление нескольких старых UTXO (delete) и добавление нескольких новых UTXO (insert), а в Ethereum — это исполнение короткого кода смарт-контракта и, опять же, обновление нескольких пар “ключ-значение”. Количество этих “атомарных” операций записи могут быть отличной метрикой, позволяющей определять узкие места в storage-подсистеме и внутренней логике транзакций.
Также, блокчейн-ноды могут быть реализованы на нескольких языках программирования — так надежнее. Это нужно учитывать, оценивая производительность сети, например, нода Ethereum существует в имплементациях на Rust и Go. Другие блокчейны также стремятся иметь дополнительные имплементации для надежности.
Local produced blocks amount
Эта несложная метрика показывает, какой валидатор сколько блоков произвел. Она является продуктом консенсуса и ее можно считать основной для оценки “полезности” для сети отдельных валидаторов.
Зарабатывая на каждом блоке, валидаторы заинтересованы в стабильной работе и безопасности своих машин. Это число помогает определить, кто из валидаторов-кандидатов наиболее квалифицирован, защищен и подготовлен для работы в публичной сети с активами реальных пользователей. Значение метрики можно публично проверить, просто скачав блокчейн и посчитав кто сколько блоков произвел.
Finality и Last Irreversible Block
В сетях с явно реализованой финальностью (EOS, Ethereum, Tendermint, Polkadot, etc ) помимо основного, быстрого консенсуса (в котором достаточно одной подписи валидатора на блок) часть блоков требует согласования группой валидаторов. Эти блоки считаются финальными, а алгоритм сбора подписей — финальностью. Задача финальности — сделать так, чтобы все транзакции, включенные в блокчейн до финализированного блока уже никогда не были бы откачены и не заменены другим форком цепочки. Это защита от атаки double spend в proof-of-stake сетях, и способ быстро, за несколько секунд, вернуть пользователю надежное подтверждение криптовалютной транзакции.
С точки зрения пользователя блокчейна, транзакция завершается не в тот момент, когда он принята нодой, а когда появился блок, который финализирует цепочку, в которой находится транзакция. Чтобы финализировать блок, валидаторы должны получить этот блок по p2p сети, и обменяться подписями друг с другом. Именно здесь и проверяется реальная скорость блокчейна, ведь пользователю важен именно момент финализации блока с его транзакцией, а не просто принятие и запись ее на диск одной из нод.
Алгоритмы финальности также различаются, пересекаются и объединяются с основным консенсусом (to read: Casper в Ethereum, Last Irreversible Blocks в EOS, GRANDPA в Parity Polkadot и их модификации, например MixBytes RANDPA).
Для сетей, где финализируется не каждый блок, полезной метрикой является отставание последнего финализированного блока от текущего последнего блока. Это число показывает, насколько отстают валидаторы, согласуя правильную цепочку. Если отставание большое, значит алгоритм финализации требует дополнительного анализа и оптимизации.
Другие блокчейн-метрики
Остальные метрики обычно сильно зависят от типа консенсуса, поэтому представлять их в числе основных не очень правильно. В числе таких параметров, например: количество форков цепочки, их длина в блоках, заполняемость блоков транзакциями и т.п. По ним можно определить ситуации разделения сети или быстро локализовать проблемы конкретного валидатора.
P2P слой
Крайне важно помнить о промежуточной основе блокчейн-сетей — peer-to-peer подсистеме. Именно она вносит неопределенные задержки в доставке блоков и транзакций между валидаторами. Когда количество валидаторов небольшое, они локализованы, списки peer-ов жестко прописаны, все работает хорошо и быстро. Но стоит добавить валидаторов, разнести ноды географически и сэмулировать packetloss, как в “tps” появляются существенные провалы.
Например, при тестировании консенсуса EOS с дополнительным алгоритмом finality, увеличение числа валидаторов даже до 80-100 машин, разнесенных по четырем континентам несильно повлияло на скорость достижения finality. В то же время, увеличение packetloss сильно повлияло на отставание финальности, что говорит о необходимости дополнительной настройки p2p слоя для большей устойчивости к потере сетевых пакетов, а не к большому latency. К сожалению, различных настроек и факторов велико, поэтому, только бенчмарки позволяют понять эффективное количество валидаторов, которые обеспечивают достаточно комфортную скорость работы блокчейна.
Устройство p2p подсистемы можно понять из документации, например, по libp2p или документацию по протоколу Kademlia или BitTorrent.
Важными метриками для p2p являются:
- объем inbound-outbound трафика
- количество успешных/неуспешных соединений с другими peer-ами
- сколько раз были отданы ранее закешированные chunk-и данных, и сколько раз пришлось пересылать запрос далее в поисках нужного chunk-а (аналог cache hits/misses)
Например, большое число misses при обращении к данным означает, что запрашиваемыми данными обладают лишь небольшое число нод, и они не успевают раздать их всем желающим, а объем принятого/отданного p2p трафика позволит установить ноду, имеющую проблемы с сетевой конфигурацией или каналом.
Системные метрики блокчейн-нод
Стандартные системные метрики блокчейн-нод описаны в большом числе источников, поэтому опишу их кратко. Их роль — помогать искать узкие места и ошибки во всех частях кода, показывая какие подсистемы ноды наиболее загружены и какими задачами.
Говорят о том, сколько вычислений выполняет процессор. Если CPU load высокий, значит нода что-то вычисляет, активно использует логику или FPU (в блокчейнах почти не используется). В блокчейнах это может быть, например, из за того, что нода проверяет электронные подпиcи, процессит транзакции с тяжелой криптографией или делает сложные вычисления.
CPU можно “разрезать” ещё на несколько полезных метрик, чтобы понять, какие части кода наиболее затратны. Например, system — код ядра, user — пользовательские процессы, io — ожидание i/o от медленных внешних устройств(диск/сеть) и т.д. Вот хорошая статья по теме.
Memory
Современные блокчейны используют key-value базы-данных (LevelDB, RocksDB), которые постоянно держат в памяти “горячие” данные. Как и в любых нагруженных сервисах, здесь всегда возможны утечки памяти в результате ошибок или целенаправленных атак на код ноды. Если потребление нодой памяти растет, либо резко увеличилось, то, скорее всего, это вызвано увеличением числа ключей в state database, большими очередями транзакций, либо увеличением числа сообщений между разными подсистемами ноды. Недозагрузка памяти может говорить о возможном увеличении лимитов на данные в блоках или максимальную сложность транзакции.
Для full-нод, котоhttps://habrastorage.org/webt/qa/sn/m5/qasnm5bougkjuagneevjkpg9x0w.pngрые отвечают клиентам сети, важными также являются метрики файлового кеша. Клиенты обращаются к различным частям state database и логу транзакций. Это порождает подъем с диска старых блоков, которые могут вытеснять новые блоки, что, в свою очередь замедляет отдачу ответов клиенту.
Network
Основные внутренние метрики network — это объем трафика в байтах, число отправленных и принятых сетевых пакетов по каждому и протоколов, packet loss ratio. В блокчейнах тим метрикам часто не уделяют большого внимания, т.к. блокчейны пока еще не обрабатывают траназакции со скоростью в 1 Gbit/sec.
Существуют блокчейн-проекты, позволяющие пользователям делиться своим wifi или предоставлять услуги хранения и передачи файлов или сообщений. При тестировании таких сетей, количество и качество трафика через сетевой интерфейс становится крайне важными метриками, так переполненный сетевой канал влияет на все остальные сервисы на машине без исключения.
Storage
Дисковая подсистема — это самый медленный компонент в любых сервисах и часто бывает причиной серьезных проблем с производительностью. Избыточное логгирование, неожиданно пришедший backup, неудобный паттерн чтения/записи, большой суммарный объем блокчейна — все это может привести к существенному замедлению работы ноды или к серьезно завышенным требованиям к железу.
Лог транзакций технически можно рассматривать как WAL (WAL ) для state database, поэтому важны те метрики storage, которые позволяют искать узкие места в механизмах современных key-value баз данных. Это количество read/write IOPS, max/min/avg latency и множество других метрик, помогающих оптимизировать дисковые операции.
Заключение
Итак, мы рассмотрели несколько наборов метрик, которые могут давать очень ценную информацию о работе блокчейн сети и возможностях для ее оптимизации. Подытоживая, можно собрать их в три группы:
- блокчейн-метрики нод:
число производимых блоков, число обрабатываемых транзакций, время их процессинга, время финализации, и т.п. - метрики p2p подсистемы:
число hit/miss запросов, число активных peers, объем и структура p2p трафика т.п. - системные метрики нод:
cpu, memory, storage, network и и т.п.
Каждая из групп важна по своему, так как в каждой из подсистем возможно существование ошибок, ограничивающих работу других компонентов, а замедление даже небольшого количества валидаторов может оказывать серьезное влияние на всю сеть. Также, наиболее хитрые ошибки в алгоритмах консенсуса и финальности возникают только при большом потоке транзакций или изменении параметров консенсуса. Для их анализа требуются воспроизводимые условия тестирования и сложные сценарии нагрузки.
Разработка блокчейнов — это всегда оркестрация несколькими машинами, скрипты для раскладки конфигов и согласованного запуска нод и бенчмарков, сервера для сбора метрик и логов со всех машин. Поэтому, при разработке своего блокчейна, предусмотрите найм квалифицированного девопса — он окажет неоценимую поддержку команде разработки. Удачи!
Источник https://ispace.news/teach-crypto/cto-takoe-zagruzennost-seti-bitkoin/
Источник https://www.rbc.ru/crypto/news/5ec67a2b9a7947be0dcede97
Источник https://habr.com/ru/post/473846/