Разработчики Neo Core завершили определение объема v3.9, продвигаются в тестировании и разработке CryptoLib.

Источник: CryptoNewsNet Оригинальное название: Разработчики Neo Core завершили определение объема v3.9, продолжают тестирование и работу над дизайном CryptoLib Оригинальная ссылка: https://cryptonews.net/news/blockchain/32063611/ На последнем заседании Neo Core разработчики продвинули тестирование изменений в комиссиях за исполнение и в белом списке, уточнили планы по поддержке BLS, совместимой с Ethereum, в нативном контракте CryptoLib, и оценили новый механизм управления для обработки заблокированных средств. В ходе встречи также были рассмотрены варианты, чтобы убедиться, что кандидаты в валидаторы управляют реальными узлами, включая конструкции на основе стекинга и штрафов.

Обеспечение работы кандидатов в валидаторы на реальных узлах

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

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

Прогресс к Neo v3.9.0

Разработчики согласились, что ветка v3.9.0 почти завершена. Обсуждалось предложение включить поддержку произвольной подписи сообщений, перенесённую из Flamingo. Поскольку функциональность зависит от дополнительного запроса на внесение изменений и четкой спецификации семантики подписанных сообщений, её могут запланировать на более поздний релиз, если документация не будет завершена вовремя.

Один элемент, NEP-25, не будет включен в v3.9.0. Ожидается, что запланированные изменения в стандарте отложат разработку на один-два месяца, поэтому участники согласились отложить его, чтобы избежать задержки выпуска.

Тестирование объединенных изменений: сборы за выполнение и белый список

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

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

Переосмысление поддержки совместимости BLS с Ethereum в CryptoLib

Разработчики также рассмотрели предложение о добавлении совместимых с Ethereum псевдонимов для BLS12-381 в нативном контракте CryptoLib.

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

Предпочтительное направление заключается в том, чтобы согласовать поддержку BLS, совместимую с Ethereum, с установленным стилем интерфейса, добавив методы сериализации для формата Ethereum при выполнении операций над внутренними представлениями точек BLS. Совместимость с форматом сериализации Ethereum является главным требованием, а не зеркальной поверхностью API. Подробности реализации будут уточнены как в узле C#, так и в neo-go для обеспечения согласованного поведения.

Инструмент управления для заблокированных средств

Группа также рассмотрела изменение в управлении, которое позволит Совету Neo переводить средства с заблокированных счетов после определенного периода, требуя 19 из 21 подписи.

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

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