Cardano ищет стандарт для программного обеспечения производителей блоков

Cardano Problem Statement ищет общий метод для идентификации программного обеспечения, используемого для производства отдельных блоков. Обсуждение CPS-0036 было открыто 2 сентября и получило метку Confirmed 16 сентября, но предложение остается открытым и не устанавливает технический стандарт.

Его цель состоит в том, чтобы определить проблему до того, как отдельный Cardano Improvement Proposal задаст формат сигнализации, реестр программного обеспечения и правила реализации.

Cardano выходит за рамки одной реализации ноды

Исторически Cardano опиралась на основанную на Haskell cardano-node, а дополнительные реализации сейчас разрабатываются по тем же правилам консенсуса. CPS-0036 называет Amaru и Dingo, а в обсуждении предложения также упоминается Gerolamo.

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

Независимые реализации могут повысить устойчивость, поскольку дефект, затрагивающий одну кодовую базу, может отсутствовать в другой. Эта выгода зависит от внедрения. Если один клиент продолжает производить большинство блоков, сеть остается операционно зависимой от этой реализации даже при наличии альтернатив.

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

Активность в сети сделала вопрос более насущным. Рецензент yHSJ сообщил, что Dingo и Gerolamo уже производили блоки, используя поле минорной версии протокола в качестве идентификатора программного обеспечения, а Amaru планирует следовать тому же подходу.

CPS-0036 описывает добровольную сигнализацию программного обеспечения

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

В обсуждении описаны два существующих подхода. Один использует четыре байта из поля минорной версии протокола в заголовке блока. Другой использует маркерную транзакцию приблизительно на 60 байт. Без общей спецификации реализации могут принять разные форматы и заставить поставщиков инфраструктуры поддерживать отдельные правила декодирования.

Предложение также призывает к открытому реестру с управлением сообществом, который присваивает распознаваемый идентификатор каждой реализации. Обозреватели, исследователи и дашборды смогут затем единообразно интерпретировать сигнал по всей сети.

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

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

Данные о клиентах могут усилить мониторинг сети Cardano

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

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

Обсуждение указывает, что вокруг поля минорной версии протокола уже может формироваться практическая конвенция. Редактор CIP Robert Phair сказал, что нацеленная на решение CIP на основе текущей практики может предоставить более прямой путь, чем простое документирование проблемы.

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