Апдейт разработки DCG | 11 Июля 2023

Апдейт разработки DCG | 11 Июля 2023

ᴠᴏɴᴄᴀɴ
В течение последних двух недель разработчики DCG работали над шестью основными темами, а также работали над более мелкими проблемами, которые не попадают в эти категории.

Подпишись на Dash on Pulse

  • Versioning: Работа, выполненная Sam и Igor (в роли проверяющего)
  • State Sync: Dima (Tenderdash/Платформа) и Wisdom (GroveDB)
  • Rust SDK: Lucas и Evgeny привлеченные к работе в течение одной недели
  • CI/CD*: Усовершенствования под руководством Ivan и Strophy, ускоряющие процесс и повышающие эффективность разработки

*Continuous Integration - это процесс объединения кода разработчиков в общую основную ветку разработки. Это позволяет регулярно проверять работу и стабильность приложения путем автоматической сборки, запуска тестов и анализа кода. Continuous Deployment - это автоматическое развертывание новых версий приложения на серверах после успешного прохождения всех проверок в процессе Continuous Integration.

  • Сопровождение v24: Ivan, Djavid, Igor
  • Работа Anton над глобальными исправлениями и вопросами голосования мастерно

Javed работал, уделяя особое внимание реализации ABC IRS и кодов ошибок. Первоначально работа носила обобщенный характер, но затем по результатам обсуждений была доработана до более детальной. Однако в ходе текущего спринта акцент сместился на Rust SDK и Rust light client, что привело к паузе в ABC IRS. Целью создания Rust SDK и легкого клиента является внедрение описательного метаязыка, который описывает данные, с которыми производится манипуляция, и инкапсулирует логику внутри клиента. Такой подход упрощает взаимодействие с пользователем за счет внутренней обработки выполнения и проверки, позволяя клиентам отправлять запросы и получать ответы, не заботясь о глубинных процессах. Для этого в ответ были добавлены дополнительные данные, такие как хэш ID блока и Worm тип, а метаданные ответа были обновлены, чтобы включить ID цепочки для проверки подписи при подтверждении доказательства. Команда также устранила различия во временном разрешении, округлив наносекунды до миллисекунд для обеспечения согласованности в рамках всей платформы. В настоящее время команда работает над проверкой доказательств, реализацией кода, модульным тестированием и разработкой привязок UniFFI к различным языкам, включая Swift, Python и Kotlin для легкого клиента.

Реализация CI/CD-кэширования, была на плечах Strophy и Ivan. Они столкнулись с проблемой замедления при проведении побочных тестов и выпуске многоархивных релизов на инфраструктуре GitHub Actions, связанной с необходимостью каждый раз компилировать все бинарные файлы. Чтобы решить эту проблему, они перевели свои раннеры на более мощную инфраструктуру AWS. Однако сборка релизов оставалась медленной, что побудило внедрить бэкенд кэширования S3 для трех ключевых компонентов сборки: кэша слоев Docker, шагов сборки с OpenChange и кэша Docker для компиляции Rust Cargo и привязки узлов. Кэши поддерживают несколько целей сборки и используют высокоскоростные SSD-накопители и параллельные операции копирования для более быстрого заполнения. В результате было создано лучшее в отрасли решение, которым пользуются другие разработчики на GitHub, обеспечивающее значительную экономию времени при выпуске нескольких релизов и положительный результат для разработчиков. Была проделана впечатляющая работа, оказывающая поддержку в повседневном процессе разработки.

Разработчики DCG представляют обновления по нескольким функциям, начиная с транзакций с блоками активов, разработка которых временно приостановлена. Они отмечают успешное рассмотрение библиотек приборных панелей и завершение работы отдела SDK. Ведутся работы по локальной проверке активов на наличие ошибок. Еще одним направлением стало решение проблем со сборкой отличной библиотеки хеширования X11 для различных целей. Для этого используется код x11c из приборной панели, обернутый в Rust по ссылкам, и сборка исполняемых файлов Rust для различных целей, таких как мобильные устройства и ARM64. При сборке для цели WASM возникли проблемы, связанные с отсутствием стандартной библиотеки C, которые были решены. В результате приборная панель теперь полностью функциональна для этих целей.

Anton рассказал о новых функциях, над которыми ведется работа в платформе. Первой обсуждаемой функцией является PoC голосования мастернод, которая позволит мастернодам голосовать по документам, в частности, по регистрации имен пользователей. Эта функция будет реализована поэтапно, причем на начальном этапе можно будет голосовать за регистрацию имени. Будет установлен обязательный период голосования, и если в течение этого периода голосование не будет завершено, то имя перейдет к тому, кто пытался его зарегистрировать. Вторая упомянутая возможность - версионирование контрактов данных и обеспечение кворума. После обсуждения с Ivan было принято решение реализовать эту функциональность в два этапа. Текущая задача сосредоточена на создании бэкенда для методов dApp и функционала SDK для просмотра истории контрактов данных. В дальнейшем планируется расширить функциональность за счет новых методов в SDK, например, выводить список изменений без возврата самих контрактов данных и получать контракты данных по версии. Также обсуждался вопрос о работе с кворумом при ротации, который был решен.

В тестовой сети Tender Dash была обнаружена высокая загрузка процессора, что объясняется включением функции обнаружения тупиковых ситуаций. Отключение этих функций позволило решить проблему и снизить нагрузку на процессор. Наконец, в настоящее время ведется работа над реализацией синхронизации. Они частично поддерживают ее на стороне TenderDash и теперь сосредоточились на реализации в платформе методов, взаимодействующих с TenderDash, таких как моментальные снимки. Снимки делаются каждые 1000 блоков и служат копией состояния GroveDB для проверки по всей сети.

Поясним, что такое State Sync для тех, кто с ней не знаком. Будучи владельцами мастернод, люди могли столкнуться с необходимостью повторной синхронизации блокчейна, что может занять много времени. С учетом того, что в TenderDash ожидается меньшее время работы блока, количество блоков, которые необходимо синхронизировать, значительно возрастет. Чтобы решить эту проблему, State Sync реплицирует данные о состоянии с разных узлов платформы, подобно тому, как происходит загрузка торрент-фильмов. Пользователи получают различные фрагменты информации с разных узлов, чтобы восстановить состояние, распределяя нагрузку и ускоряя процесс. Команда работает над тем, чтобы сделать процесс репликации в Group DB совместимым с State Sync, подключаясь к нескольким узлам и получая случайные фрагменты данных. Первоначально они планировали внедрить State Sync после первого релиза в основной сети, но поняли, что необходимо завершить работу раньше, чтобы решить проблему синхронизации для пользователей, которые оказываются заблокированными во время работы над версиями.

Более того, была исправлена проблема с рабочим процессом аудита CI, связанная с устаревшей версией gRPC, используемой для связи между SDK и сетью. Для устранения сбоя в аудите была обновлена версия Yarn в проекте. Во-вторых, введена функция "Настройка сетевого интерфейса в Dashmate", которая позволяет запускать несколько мастернод на одной машине за счет возможности конфигурирования параметров сетевого интерфейса. Ранее сетевые значения задавались жестко, но данная функция позволяет настраивать сетевые значения для мастернод. Наконец, разработчики обсуждают стабилизацию сквозного тестирования в проекте Dashmate. Они столкнулись с проблемами, связанными с настройкой и сборкой помощника Dashmate, а также с проблемами, связанными с портами в средах Linux. И они в данный момент активно работают над решением этих проблем для повышения стабильности.

Sam объясняет, что, хотя работа еще не закончена, проделана значительная работа. В настоящее время запрос на изменение версий состоит из 52 000 строк кода в дополнение к 10 000 уже объединенных строк. Он отмечаtт завершение работы над identity, GroveDB и верификацией. Работы по интеграции оцениваются в 25%, учитывая возможность возникновения сбоев и проблем, которые могут потребовать дополнительного внимания. Несмотря на то, что версионирование находится в хорошей форме, могут возникнуть проблемы, требующие дальнейшей работы.

Sam представил обновленную информацию о версионировании Drive ABCI, которое относится к основному приложению, отвечающему за выполнение блоков, инициализацию, проверку транзакций и другие аспекты. Он отмечает, что работа над версией ABCI практически завершена, и в последнее время были исправлены ошибки, связанные с интеграцией Drive. Также как в Drive ABCI, так и в самом Drive осталось выполнить минимальный объем работ.

Версионирование контрактов данных оказывается сложным из-за четырех различных типов версий: пользовательских, структуры данных, сериализации и методов. Sam добился прогресса в разделении версий структуры кода и сериализации. Версионирование документов осуществляется по аналогии с контрактами данных. Переходы состояний подверглись пересмотру схемы версионирования, причем код разделен на несколько файлов для более четкой организации. Переходы документов практически завершены. Валидация в DPP все еще продолжается, и Sam выразил надежду на ее завершение в ближайшем будущем
Sam представляет обновленную информацию о развертывании, сообщая, что деплоймент 9 уже шесть недель работает безупречно и без каких-либо проблем. В ближайшее время планируется обновить ее до версии v20, которая за последние полтора месяца претерпела значительные изменения. Более подробная информация об этом обновлении будет представлена DCG в одном из ближайших апдейтов

Paul с Research команды представляет Dash Data Contract Creator

https://dashpay.io - веб-приложение, написанное на языке Rust. Приложение позволяет пользователям создавать контракты данных для платформы Dash. Пользователи могут описать желаемое приложение с помощью интерфейса, напоминающего чат, или заполнив форму. Приложение использует API OpenAI для создания контрактов на основе данных, введенных пользователем. Кроме того, в нем предусмотрена проверка DPP на совместимость контракта с протоколом платформы Dash. Приложение имеет открытый исходный код и не хранит никаких пользовательских данных. В планах на будущее, интеграция QR-кода для простой регистрации контрактов на данные через приложение Dash Pay, и более красивый UI/UX который уже реализован Ross. Приложение находится в стадии разработки, и приглашает пользователей оставлять свои отзывы.

Докладчик объявляет, что версия 19.2 успешно активирована в сети Dash.

Распределение по версиям

Большинство мастернод обновились до версии 19.2, а старые версии были запрещены. Во время активации небольшое количество мастерном столкнулось с проблемами и вышло из строя. Однако эти проблемы были решены по мере формирования новых кворумов. В настоящее время в сети зарегистрировано и функционирует 17 Evonodes. В целом активация v19.2 прошла успешно и с минимальными проблемами.

Достигнут значительный прогресс в работе над v20 для платформы Dash. В ближайшее время планируется выпустить обновленный релиз devnet, в который будут включены такие функции, как блокировка активов и децентрализованный маяк случайности. Команда с нетерпением ждет возможности протестировать эти функции и продолжить разработку v20. На следующей неделе также ожидается выпуск тестовой сети, причем в процессе тестирования возможно появление нескольких жестких форков. Говоря о планах по созданию хард форков: в первом хард форке будет включена блокировка активов и децентрализованная случайность, во втором будет реализован расширенный хард форк, а в последнем хард форке будет осуществлен переход с v19 на v20.

● Ожидаемый релиз тестнета ~1 неделя; выход обновленного DevNet - ближайшее время

● Принятые PRs (Пулреквесты) : 5449, 5451, 5452, 5453, 5454, 5456, 5457, 5464, 5468, 5465, 5426, 5455, 5443, 5466, 5399, 5472, 5474, 5462, 5476, 5475, 5435, 5478, 5283, 5486, 5377 done

Специально для @Dash_on_pulse by @V_O_NCAN

источник - DCG Devs update

Report Page