Розробники 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. Заплановані зміни до стандарту очікують, що розробка затягнеться на один-два місяці, тому учасники погодилися відкласти його, щоб уникнути затримки випуску.

Тестування об'єднаних змін: комісії за виконання та білий список

Фактори комісії за виконання змінено, а підтримка безкоштовних транзакцій на основі білого списку вже об'єднана для v3.9.0. Спеціальна проблема визначить контрольний список для тестування цих функцій перед публікацією остаточних бінарних файлів.

Заохочувався ширший перегляд від кількох учасників, особливо для запитів на злиття, які стосуються поведінки на рівні протоколу. Намір полягає в зменшенні ризику розбіжностей у поведінці між експлораторами, гаманцями та альтернативними реалізаціями вузлів після розгортання оновлення.

Розгляд підтримки BLS, сумісної з Ethereum, у CryptoLib

Розробники також розглянули пропозицію додати сумісні з Ethereum псевдоніми для BLS12-381 у рідному контракті CryptoLib.

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

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

Інструмент управління для заблокованих коштів

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

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

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