Разработчик XRPL Денис Ангелл на этой неделе запустил интерактивную панель, которая оценивает каждую поправку XRP Ledger по тому, насколько её функциональность была фактически протестирована в devnet до выхода в основную сеть (mainnet).

Инструмент превращает готовность поправок — ранее вопрос доверия к процессу — в публичный рейтинг, который точно показывает, какие типы транзакций, поля и коды результатов ни разу не были задействованы реальной транзакцией.

Что именно отслеживает панель

Ангелл создал инструмент, размещённый на amendments-staging.xrpl.foundation, чтобы считывать полную спецификацию каждой поправки напрямую с ноды, а не поддерживать её вручную. Сюда входят все типы транзакций, необязательные поля, флаги, коды результатов и записи леджера, которые вводит поправка.

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

Разработчик прямо объяснил логику проекта, сказав:

“Каждая новая функция XRPL выпускается в виде поправки. Валидаторы голосуют за неё, и как только она активирована, она навсегда становится частью протокола. Это заслуживает реальных доказательств того, что функция была протестирована сквозным образом в devnet, а не просто изолированно.”

На этой неделе панель отслеживает 16 поправок в реальном времени в devnet, и у 13 из них всё ещё есть непротестированные участки.

Самые большие пробелы приходятся на более новые поправки: у Sponsor 65 из 107 возможных проверок ни разу не выполнены, у XChainBridge не хватает 30 из 40, а у MPTokensV1 — 27 из 102.

Сканирование этой недели также выявило 59 находок по всему набору: две ошибки в спецификации, 23 пробела в документации и 34 пробела в тестировании.

Одна поправка, XLS-75 (делегирование прав), которая позволяет аккаунту передавать другому ключу узкие полномочия — например, только заморозку доверительных линий и ничего больше, — на этой неделе закрыла все оставшиеся пробелы в тестировании.

По словам Ангелла, команда добавила логику, сопоставляющую каждую делегированную транзакцию с конкретным разрешением, стоящим за ней, а затем задействовала все оставшиеся ячейки в devnet, доведя все 122 проверки по 12 детализированным разрешениям до полного покрытия.

Он представил эту инициативу как краудсорсинговую, призвав разработчиков XRPL “находить красные ячейки” и самостоятельно выполнять недостающие транзакции, поскольку панель фиксирует новую активность в течение секунд.

Тестирование поправок происходит на фоне отставания внедрения

Стремление к более строгому тестированию перед активацией последовало за непростым циклом обновлений. Как сообщало издание CryptoPotato в июле, обновление Ripple v3.2.0, которое переименовало основное серверное ПО с rippled на xrpld и сократило использование памяти нодами на 30–40%, спустя недели после релиза оставалось не внедрённым более чем на половине нод XRPL, хотя 89% доверенного набора валидаторов сети уже перешли на него.

Source: CryptoPotato