Апдейт разработки DCG #3

Апдейт на основе стрима DCG, который был проведен 6 Февраля 2024

Держи руку на пульсе Dash ➯ Подпишись | Читать прошлый апдейт

Команда разработки платформы

Давайте быстро подведем итоги спринта:

• Лукаш занимался улучшением стабильности TenderDash

• Игорь, Иван, Лукаш, а также Константин и Одиссеас интегрировали вывод средств в платформы.

• Пол продолжил заниматься стратегиями

Во время этого спринта команда занималась тестированием TenderDash, в частности её стабильности в том числе и в режиме серьезной нагрузки. Были выявлены некоторые возможные пути улучшений, но над ними в данный момент еще ведется работа.

Лукаш получил обратную связь от коммьюнити по процессу сборки TenderDash и реализовал необходимые изменения, они в основном коснулись документации и зависимостей. Так же он решил несколько незначительных проблем, связанных с образами Docker для различных осей и линтером. А также провел очистку и улучшение кода.

Для совместимости TenderDash c функционалом вывода средств с платформы, была проведена довольно большая работа и релиз 0.14.0-dev.2 включил в себя THRESHOLD_RAW расширение. Основная цель этой работы заключалась в создании формата подписи, который гармонично бы работал со всеми уровнями (Core, Drive ABCI и TenderDash) и позволял подписывать транзакции на вывод и в дальнейшем полагаться на них, обеспечивая безопасность и консенсус.

Эта неделя в основном была посвящена доработке различных аспектов функции вывода средств с платформы. В процессе интеграции с Core через RPC-метод, возникли проблемы детерминизма. Для решения этой проблемы команде пришлось указать высоту блока в Core чейне, до которой следует предоставить статус транзакции вывода средств с платформы. В результате этих действий достигнута детерминированная логика, позволяющая Drive корректно определять завершенность транзакций вывода, что является ключевым элементом в обеспечении надежности и правильного функционирования системы.

Помимо решения конкретных проблем, неделя была посвящена комплексной оптимизации, рефакторингу кода и общей чистке кода. Было проведено множество тестов, охватывающих различные сценарии. Среди них были интеграционные тесты, тесты стратегий, специально разработанных для снятия средств, а также включение новых функциональных стратегий для различных переходов между состояниями. Кроме того, были проведены сквозные тесты, охватывающие различные сценарии, чтобы убедиться в прочности и надежности реализованного функционала.

Также в этом спринт апдейте Игорь Маркин продемонстрировал и объяснил работу тестов. А Иван Шумков представил полезную инфографику, которая поможет понять работу ввода средств на Dash Platform, а также их вывода.

Пол работал над улучшением функциональности TUI и созданием стратегий для тестирования Dash Platform. Он добился прогресса в улучшении системы для регистрации нескольких личностей в одном блоке, а также в решении проблем, связанных с переводом кредитов и переходами состояний. Пол исправил критическую ошибку, которая заключалась в несоответствии между ожидаемыми форматами хэшей во время трансляций переходов состояний. Эта проблема возникла в результате слияния последней ветки разработки с его рабочей веткой.

Он также доработал уже имеющиеся тесты, добавив в них тестирование включения нескольких переходов состояний в один блок, что расширило возможности тестирования. Было решено существенно изменить подход к тестированию, перейдя от тестовой сети к локальной. Это изменение было необходимо из-за проблем с подключением в тестовой сети, которые могли быть вызваны тем, что узлы интерпретировали стресс-тесты как вредоносную активность. Локальная сеть обеспечивает впечатляющую скорость до 500 переходов состояний в одном блоке, что резко контрастирует с ограничениями, с которыми сталкивалась тестовая сеть.

Пол работает над улучшением операций с контрактами, увеличивая скорость и количество регистрации и обновления контрактов. Для этого необходимо расширить возможности платформы по обработке идентификационных операций и управлению документами, оптимизировав процесс регистрации и обновления данных. Сейчас эти операции выполняются медленно из-за блокировки активов и ожидания подтверждения от Core.

Было проведено множество проверок, чтобы убедиться в эффективности и работоспособности созданного DCG решения. Также версия с интегрированным решением спокойно проработала в течение недели и никаких проблем обнаружено не было. Поэтому после всех проверок и тестирований, наконец-то решение было полноценно интегрированно.

Для начала вспомним что проверка на основе состояния требует больших затрат компьютерных ресурсов.. Переходы между состояниями должны быть оплачены, если они требуют проверки состояния, даже если они не проходят проверку, в противном случае система легко подвергается атаке. Но такая механика, также открыло другой вектор атаки.

Например два пользователя хотят получить один и тот же юзернейм, но только 1 его получит.

Два пользователя создают переход состояния в одно и тоже время, и хотя переход состояния пользователя B будет отклонен, он все равно заплатит небольшую комиссию за обработку.

И тут появляется пользователь C, который вновь транслирует провальный переход состояния пользователя B и он опять проверяется и отклоняется, и атакующий может ддосить, использую при этом чужой баланс.

Чтобы решить эту проблему, команда разработала решение с использованием nonce, основанных на контракте идентификации. По сути, для каждого контракта между идентификатором и парой контрактов хранится свой nonce. Эта информация хранится в информационном пространстве контрактов в состоянии каждого идентификатора. Каждый раз, когда идентификатор взаимодействует с контрактом, значение nonce увеличивается. Переходы между состояниями транслируются с целью обновления текущего nonce до nonce плюс один. Кроме того, nonce проверяется при переходах состояния документа, таких как добавление, обновление или удаление. Теперь пользователям разрешено совершать до 20 переходов состояния для одного и того же контракта в одном блоке, что эффективно решает проблему.

Несмотря на некоторые трудности, возникшие при внедрении этого решения, упорные усилия в конечном итоге привели к его успешному завершению.

Одной из важных задач было устранение проблем с детерминизмом, связанных с методом RPC, используемым Core. Чтобы обеспечить точную отчетность по операциям разблокировки активов, были внесены корректировки, определяющие высоту, до которой Core должно предоставлять информацию. Команда оптимизировала, рефакторизовала и очистила код. Также были внедрены протоколы комплексного тестирования, включая интеграционные тесты, тесты стратегий для сценариев вывода средств и сквозные тесты. Такое тщательное тестирование обеспечивает прочность и надежность кода при различных сценариях использования.

Были решены задачи, которые решали проблемы в логике выполнения Drive ABCI. Эта логика управляет собственным состоянием, включая текущий уровень и общую информацию между блоками или этапами выполнения блока. Она также хранит основную информацию, такую как ключи для проверки подписей. Первоначально возникли проблемы с сериализацией и хранением на диске, в частности конфликт хранения версии протокола с другими данными состояния. Чтобы решить эту проблему, команда выделила версию протокола в отдельный ключ, что позволило более плавно анализировать состояние. Они также выявили неэффективность при установке диска, связанную с кэшированием системных контрактов данных. Поскольку системные контракты, такие как DPNS и withdrawals, интенсивно используются во время выполнения блока и обработки Drive, команда внедрила отдельный кэш для версий контрактов, чтобы оптимизировать производительность и избежать ненужных вычислений. Эти улучшения повышают стабильность и эффективность платформы Drive ABCI.

Команда Core разработки

Команда Core завершила выполнение задач по бэкпортированию Bitcoin Core, намеченных на январь. Эти работы включали в себя бэкпорт 20-й версии Bitcore и значительный прогресс в версиях с 21 по 24. В частности, все бэкпорты для версии 20 уже завершены, что открывает путь для будущих улучшений.

Кроме того, близится к завершению реализация HD-кошельков по умолчанию, которая находится в стадии окончательной проверки. Их интеграции приведет к выпуску 20.1 rc1, что положит начало циклу релиз-кандидатов для тестирования любых потенциальных проблем перед официальным выпуском версии 20.1 в ближайшее время.

Команда также работает над получением сертификата, чтобы подписывать релизы, хотя стоит отметить, что прогресс идет медленнее, чем ожидалось, из-за различных требований. Кроме того, есть ряд небольших элементов, которые планируется включить в 20.1, например, дескрипторные кошельки, которые уже близки к завершению и могут быть включены в качестве дополнительных и экспериментальных функций.

Некоторые запланированные функции, такие как Assume UTXO и Process Separation, были перенесены в версию 21, поскольку стало очевидно, что они не будут готовы к включению в 20.1. Хотя соответствующий код существует в 20.1, окончательные функции разрабатываются для будущих выпусков. В целом, январское внимание к бэкпорту привело к значительным техническим улучшениям и рефакторингу, хотя многие из этих изменений не так легко заметны, но, тем не менее, они ценны.

За последние две недели команда интегрировала несколько пулреквестов (PR), сосредоточившись в основном на бэкпортах. Хотя количество интегрированных PR может показаться ограниченным, каждый PR на бэкпорты представляет собой значительный объем работы, часто включающий от 10 до 25 коммитов. Учитывая размер этих отдельных бэкпортов, в совокупности они представляют собой значительный объем работы, вероятно, около 100-200 в целом.

Команда Mobile разработки

В ходе последнего спринта команда Android столкнулась с проблемой, характерной для Android 6. После оценки пользовательской базы, которая насчитывала чуть более 100 пользователей, было принято решение отказаться от поддержки Android 6, в соответствии с общепринятой практикой постепенного прекращения поддержки старых версий операционных систем.

Кроме того, был достигнут прогресс по нескольким направлениям: продвинута работа по CoinJoin, решена проблема обработки ошибок, почти завершено тестирование надежности и стабильности.

Среди других разработок - улучшения в Maya, в частности, упрощение ввода адресов назначения и получения, связанных с кошельками адресов coinbase и uphold. В частности, DashDirect будет заменен на DashSpend в качестве нового бренда, и в настоящее время продолжается рассмотрение нового API от CTX.

Хотя интеграция с новыми библиотеками Rust остается приоритетной задачей, команда также сосредоточена на балансировании разработки функций между Maya и Dash Spend.

В последнем обновлении было также уделено внимание библиотекам. Усилия в первую очередь направлены на создание системы идентификации, которая в настоящее время является главным приоритетом команды.

Среди заметных достижений - исправление ошибок, связанных с сортировкой coinbase и Dash Merchant в функции Explore.

Кроме того, продолжается работа над бэкендом для CoinJoin, а также незначительные исправления в APY CrowdNode для приведения в соответствие с новыми расчетами v20