Solana разработчики рассматривают новый протокольный свод правил, призванный сделать независимо разработанное программное обеспечение валидаторов более надежным и легким в поддержке.
Предложение proposal, опубликованное 30 октября, поступило от Бреннана Уотта, генерального директора Anza, компании по инженерии блокчейна, стоящей за Agave, одной из основных программных платформ, используемых для функционирования сети Solana.
Watt хочет, чтобы Solana разработала единый авторитетный спецификация, определяющая, как её блокчейн обрабатывает транзакции, проверяет блоки и достигает консенсуса, вместо того чтобы полагаться на правила, рассеянные по существующему программному обеспечению и отдельным техническим предложениям.
Изменение может решить растущую проблему, поскольку Solana расширяется за пределы своего исходного программного обеспечения валидатора, включая независимо разработанные альтернативы, такие как Firedancer, созданный торговой фирмой Jump Crypto.
Валидаторы — это компьютеры, которые проверяют транзакции и помогают обеспечивать безопасность блокчейна. Хотя различные разработчики могут создавать программное обеспечение для этих компьютеров, каждая реализация должна следовать одним и тем же базовым правилам для поддержания согласия в сети.
Разногласия по поводу этих правил могут привести к тому, что валидаторы будут обрабатывать идентичные транзакции по-разному, что потенциально создаст противоречивые представления о блокчейне и угрожает надежности сети.
Уотт утверждает, что существующий процесс разработки Solana делает для независимых команд излишне сложным определение того, как именно должна функционировать сеть.
В текущей системе изменения протокола предлагаются через Solana Improvement Documents, известные как SIMD. Эти документы описывают отдельные обновления, но полные правила работы сети не объединены в один авторитетный справочник.
В результате разработчикам иногда приходится изучать существующий код валидатора или воссоздавать предыдущие решения по обновлению, чтобы понять, какие правила активны.
Уотт сказал, что такой подход может приводить к повторяющимся или несогласованным описаниям существующего поведения, затрудняя выявление всех частей протокола, затрагиваемых предложенным обновлением.
Новый регламент может изменить процесс обновления Solana
В рамках предложения разработчики продолжат обсуждение потенциальных обновлений через существующий процесс SIMD, но формальные технические изменения будут представляться в виде правок в общем протокольном спецификации.
Каждая поправка будет точно описывать, как обновление влияет на транзакции, сетевую связь, консенсус и другие соответствующие функции.
Изменения пройдут технический обзор и необходимые процедуры управления перед включением в официальную спецификацию при активации на мейннете Solana.
Это позволит командам, разрабатывающим Agave, Firedancer и будущее программное обеспечение валидаторов, работать по одним и тем же задокументированным требованиям, а не полагаться на код другой реализации в качестве основного источника.
Где начинается клиент?
Строительство дочернего банка применяет переход границы эпохи-E один раз перед своими транзакциями.
Общая инструкция делает цель явной. Начальное доверие и следующая эпоха остаются отдельными требованиями.
Это черновой спецификация, а не принятые изменения протокола. Она не обеспечивает корректность начального состояния, воспроизведение истории или непрерывную работу в E+1. Выгода в надежности клиента не количественно оценена.
Это также может сделать тестирование программного обеспечения более эффективным. Когда независимые валидаторы дают разные результаты, разработчики будут иметь общий стандарт, по которому можно проанализировать расхождения и определить, какая реализация требует исправления.
Watt уже опубликовал черновик спецификации, охватывающий 18 аспектов работы Solana, включая обработку транзакций, сетевую связь, консенсус, комиссии и вознаграждения валидаторов.
Однако черновик ограничен определенным периодом истории блокчейна Solana и предполагает, что разработчики начинают с уже доверенного состояния сети. Для охвата последующих обновлений и подтверждения совместимости реализаций с течением времени потребуется дополнительная работа.