Solana розробники розглядають новий протокольний збірник правил, призначений для збільшення надійності та спрощення підтримки валідаторного програмного забезпечення, розробленого незалежно.
Пропозиція proposal, опублікована 30 жовтня, походить від Бреннана Ватта, генерального директора Anza, компанії з інженерії блокчейну, яка розробила Agave, одну з основних програмних платформ, використовуваних для функціонування мережі Solana.
Watt вимагає, щоб Solana встановила єдину, авторитетну специфікацію, яка визначає, як її блокчейн обробляє транзакції, підтверджує блоки і досягає згоди, замість покладання на правила, розсіяні між існуючим програмним забезпеченням та окремими технічними пропозиціями.
Зміна може вирішити зростаючий виклик, оскільки Solana розширюється за межі своєї початкової програми валідатора, додаючи незалежно розроблені альтернативи, такі як Firedancer, створений торговою фірмою Jump Crypto.
Валідатори — це комп’ютери, які перевіряють транзакції та допомагають забезпечити блокчейн. Хоча різні розробники можуть створювати програмне забезпечення для цих комп’ютерів, кожна реалізація повинна дотримуватися тих самих базових правил, щоб забезпечити згоду в мережі.
Розбіжності щодо цих правил можуть призвести до того, що валідатори будуть обробляти однакові транзакції по-різному, що може створити суперечливі уявлення про блокчейн і загрожувати надійності мережі.
Ватт стверджує, що існуючий процес розробки Solana робить надмірно складним для незалежних команд визначити, як саме має поводитися мережа.
За поточної системи зміни протоколу пропонуються через Solana Improvement Documents, відомі як SIMDs. Ці документи описують окремі оновлення, але повні правила роботи мережі не зведені в єдиний авторитетний довідник.
Як наслідок, розробникам іноді доводиться перевіряти існуючий код валідатора або відновлювати попередні рішення щодо оновлення, щоб зрозуміти, які правила є активними.
Ватт сказав, що такий підхід може призводити до повторюваних або несумісних описів існуючої поведінки, одночасно ускладнюючи виявлення всіх частин протоколу, що стосуються запропонованого оновлення.
Новий правилами може змінити процес оновлення Solana
За пропозицією розробники продовжуватимуть обговорення потенційних оновлень через існуючий процес SIMD, але формальні технічні зміни будуть подаватися у вигляді редагувань спільного протокольного специфікації.
Кожна поправка точно описуватиме, як оновлення впливає на транзакції, мережеві комунікації, консенсус та інші відповідні функції.
Зміни пройдуть технічний огляд та необхідні процедури управління перед тим, як стати частиною офіційної специфікації при активації на мейннеті Solana.
Це дозволить командам, що розробляють Agave, Firedancer та майбутнє програмне забезпечення валідаторів, працювати зі спільними документованими вимогами, а не покладатися на код іншої реалізації як на основний джерело посилання.
Де починається клієнт?
Конструкція дитячого банку застосовує перехід межі епохи-E один раз перед своїми транзакціями.
Загальний правилами робить мету явною. Початковий стан довіри та наступна епоха залишаються окремими вимогами.
Це проект специфікації, а не прийнятий протокольний зміна. Він не встановлює коректність початкового стану, історичного відтворення чи безперервної роботи до E+1. Не квантифіковано отримання надійності клієнта.
Це також може зробити тестування програмного забезпечення більш ефективним. Коли незалежні валідатори отримують різні результати, розробники матимуть загальний стандарт, за яким можна дослідити розбіжності та визначити, яка реалізація потребує виправлення.
Watt вже опублікував проект специфікації, який охоплює 18 аспектів роботи Solana, включаючи обробку транзакцій, мережеві комунікації, консенсус, комісії та винагороди валідаторів.
Однак проект залишається обмеженим певним періодом історії блокчейну Solana і передбачає, що розробники починають з вже довіреної стану мережі. Для охоплення подальших оновлень та підтвердження сумісності реалізацій із часом необхідні додаткові роботи.