Співзасновник Solana: створення глобальної державної машини та аналіз остаточної архітектури Solana

**Слова: Анатолій Яковенко, CEO (Co-Founder & CEO), Solana

Упорядник: 1912212.eth, Foresight News

Мета Solana полягає в тому, щоб якомога швидше синхронізувати єдину глобальну державну машину без дозволу відповідно до законів фізики. Я вважаю, що архітектура, яка зможе цього досягти, виглядатиме так:

• Велика кількість повних вузлів, понад 10 000 (N > 10 000)

Для того, щоб мережа функціонувала як глобальна машина станів, вона повинна підтримувати численні повні ноди. Turbine довела, що швидка реплікація в дуже великі мережі масштабується на сучасному обладнанні та мережах.

• Велика кількість лідерів генерації блоків, понад 10 000 (N > 10 000)
• Паралельні лідери виробляють блоки одночасно, випадковим чином вибрані в діапазоні від 4 до 16.

Concurrency Leader дозволяє мережі мати кілька локацій по всьому світу для замовлення транзакцій користувачів. Це скорочує відстань між користувачами та мережею, усуваючи необхідність повної перевірки вузла перед додаванням транзакцій до ланцюжка.

• Час блоку становить 120 мілісекунд

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

• Деякі з вузлів консенсусу для голосування в підкомітеті з питань схвалення, числом від 200 до 400, вибираються випадковим чином і змінюються кожні 4-8 годин в епоху.

Консенсус має важливе значення для вибору форку, який відбувається через розбиття мережі на розділи. Вибірка з 200 або більше вузлів буде статистично репрезентативною для всіх основних розділів мережі і точно відповідатиме їх фактичному розподілу. Тому всі повні голоси ноди не потрібні, достатньо 200. Обмежте схвалення підкомітетів, щоб зменшити пропускну здатність пам’яті та мережі, необхідні для підтримки блоків 120 мс. Скорочення часу блокування, природно, збільшує кількість голосів, що надсилаються в секунду, чинячи певний тиск на ресурси, виділені для досягнення консенсусу.

Справжня проблема в блоці 120 мс полягає в тому, щоб відтворити всі транзакції користувача. Оскільки мережа інклюзивна, вкрай складно гарантувати однорідне середовище виконання з надійним часом виконання довільного коду користувача. Хоча така можливість існує, її можна досягти лише шляхом обмеження доступних обчислювальних ресурсів для транзакцій користувачів і забезпечення перерозподілу кожного вузла за найгіршим сценарієм.

Однак немає причин застосовувати повний стан для вузлів консенсусу, які голосують за форк, або лідера, який будує на форку. Для того, щоб синхронізувати схвалення вузлів консенсусу та лідерів, стан потрібно обчислювати лише один раз за період.

Асинхронне виконання

Мотивація

Синхронне виконання вимагає, щоб усі вузли, які голосують і створюють блоки, були суперналаштовані в будь-якому блоці, щоб визначити найгірший час виконання. Асинхронне виконання є одним з небагатьох випадків, коли компромісів небагато. Вузли консенсусу можуть виконувати менше роботи перед голосуванням. Роботу можна агрегувати та групувати, що робить її ефективною у виконанні без втрати кешу. Він навіть може бути виконаний на зовсім іншій машині, ніж вузол консенсусу або лідер. Користувачі, яким потрібне синхронне виконання, можуть виділити достатньо апаратних ресурсів для виконання кожного переходу станів у режимі реального часу, не чекаючи на всю мережу.

З огляду на різноманітність додатків і основних розробників, варто планувати серйозну зміну протоколу щороку. Якби мені довелося вибрати один з них, моїм вибором було б виконання асинхронно.

ОГЛЯД

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

Валідатори, які голосують за схвалення, повинні лише вибрати форк; їм взагалі не потрібно виконувати будь-яку стан. Тільки в кожну епоху їм потрібен статус, щоб обчислити наступне схвалення.

Процедуру голосування скоригували таким чином, щоб її можна було проводити самостійно. Вузли виконують процедури голосування тільки перед голосуванням. Оскільки валідатори не займають багато місця, вимоги до пам’яті повинні бути відносно невеликими. Оскільки голосування має дуже передбачуваний час виконання, у виконанні процедури голосування практично не повинно бути хвилювань.

Всі транзакції, що не мають права голосу, можуть розраховуватися асинхронно. Це дозволяє replay виконувати всі транзакції без голосування пакетами, попередньо витягувати та JIT усі програми заздалегідь, практично усуваючи всі втрати кешу. Довгострокова мета полягає в тому, щоб для цього завдання були налаштовані лише машини, які потребують обчислень у реальному часі з низькою затримкою та повним станом. Імовірно, користувачі заплатять за додаткове обладнання.

Після того, як вибір форку та виконання стану розділені, пришвидшити роботу стає простіше:

• Асинхронне виконання
• Кожна епоха змінює фіксовану кількість виборчих комісій
• Час блокування 200 мс

Оскільки повтор транзакцій користувача не блокує вибір форку, волатильність більше не є проблемою при відніманні часу блоку. Єдине, що потрібно враховувати, це те, що через 200 мілісекунд показник голосування валідатора подвоюється. Внесення досить прямих змін до того, як розраховується квота для схвалень, дозволить нам зафіксувати розмір схвалення на рівні 200 або 400, або будь-яке інше число, яке здається доцільним.

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

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

Проголосувати

• Виборчі рахунки повинні мати достатню кількість SOL, щоб покрити голоси 2-х епох.
• Транзакції голосування повинні бути простими. Непросте голосування приречене на провал. Генератори блоків повинні відмовитися від складного голосування.
• Зняття SOL з виборчих рахунків дозволяється за умови, що баланс не впаде до рівня менше 1 епохи голосів.
• Для того, щоб обнулити всі лампоти, директива Vote CLOSE повинна вимагати, щоб минула повна епоха. Облікові записи для голосування позначаються як ЗАКРИТІ в Ері 1, але можуть бути ЗАКРИТІ лише в Еру 2. CLOSE дозволяє вивести всі SOL і видалити облікові записи для голосування. Після того, як обліковий запис позначено як ЗАКРИТИЙ, його можна лише повністю видалити і не можна відкрити знову.
• Голоси містять VoteBankHash замість звичайного BankHash.

Регламент та затвердження лідера

Тільки валідатори відповідають наступним критеріям:

• Сума ставки > X
• А також SOL > 2 епохи голосування
• і не позначений як ЗАКРИТИ

щоб увійти до розкладу лідерів і зарахувати до затвердження. Для версії 2 ми можемо відокремити LeaderSchedule від Quorum, і вони не обов’язково повинні мати однакові вимоги.

Розрахунок VoteBankHash

На відміну від Bankhash, який обчислює всі транзакції, валідатори обчислюють VoteBankHash лише для простих транзакцій голосування, пов’язаних із валідаторами в LeaderScheduler. Всі інші транзакції ігноруються. Після повторного відтворення всіх голосів VoteBankHash розраховується в тому ж форматі, що і поточний BankHash.

VoteBankHash повинен накопичувати попередній VoteBankHash, а не повний BankHash.

Розрахунки BankHash

Для всіх оптимістичних підтверджених блоків (налаштовується для всіх блоків) валідатор починає обчислення UserBankHash, який включає всі переходи станів, але виключає транзакції, які були враховані при розрахунку VoteBankHash.

Потім BankHash є похідним від накопичення (VoteBankHash, UserBankHash). 99,5% найкращих валідаторів подають BankHash як частину свого голосування кожні 100 часових слотів. Незважаючи на те, що він виконується кожні 100 часових проміжків, він розраховується в кожному часовому слоті. Варто зазначити, що, можливо, невеликому відсотку вузлів варто послідовно подавати BankHash у плітках як м’який сигнал без недетермінованих спостережень.

Якщо менше 67% валідаторів подають повні розрахунки BankHash, лідери повинні скоротити блоковий простір, доступний для транзакцій користувачів і облікових записів, на 50%. Цей захід покликаний захистити ланцюг від зловживань, які можуть надмірно збільшити час відтворення.

BankHash повинен накопичити попередні BankHashes.

Ідіть до керівника банку

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

• Лідери ведуть кеш оплачених залишків на рахунках.
• Якщо платний аккаунт використовується як джерело для системних переказів, або як записуваний аккаунт, переданий разом із системною програмою іншій програмі, то баланс оплаченого рахунку встановлюється рівним 0.
• Блоки упаковуються відповідно до заявлених обчислювальних одиниць (CU) в порядку пріоритету локальної комісії до тих пір, поки блоки не будуть заповнені.
• Комісії списуються з кешу оплаченого балансу рахунку.
• Кешування оплаченого балансу доповнюється розрахунками BankHash.

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

Враховуючи, що валідатори вже прагнуть максимізувати свій заробіток, у них є достатньо стимулів для підтримки точного кешу платних облікових записів. Крім того, якщо немає штрафу, будь-хто в будь-якій мережі може легко обслуговувати кеш у довгостроковій перспективі. У разі пошкодження сервера оператор безбанківського лідера повинен мати можливість легко перемикатися або брати вибірку з кількох джерел.

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

Компроміси

Основним компромісом є відсутність підпису підтвердження на повному вузлі, який обслуговує стан користувача, щоб підтвердити, що його статус доставки точно такий же, як і затверджений решта. Єдине авторитетне пояснення стану має залишатися незмінним, навіть якщо кожна транзакція послідовно відтворюється в книзі. Будь-яка оптимізація продуктивності не повинна впливати на результати. Таким чином, після того, як форк завершено, для обчислення залишається лише правильний стан, якщо реалізація середовища виконання є безпомилковою.

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

Користувачі також можуть підписувати транзакції, які підтверджують BankHash або ініціюють переривання. Решта мережі виконає ці транзакції тільки в тому випадку, якщо точний розрахований BankHash точно збігається з BankHash, наданим користувачеві постачальником RPC.

Довгострокова дорожня карта вузлів консенсусу без стану

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

Якщо схвалення не збігається з повним вузлом, повний вузол, який відстежує як схвалення, так і статус, припинить роботу. Це означає, що якщо виникнуть розбіжності між схваленням і статусом, біржа, фіатний канал, RPC, міст і т.д. перестануть функціонувати. Для цього потрібен лише дуже малий відсоток дефектних вузлів консенсусу без стану.

Безбанківські лідери можуть покладатися на вибірку з кількох повних вузлів, щоб забезпечити кеш початкового балансу платного рахунку. Навіть якщо він недосконалий, результатом буде спам у блоці, а не збій консенсусу. Оператори повинні мати можливість стежити за здоров’ям своїх керівників і відсотком спаму, який вони вводять у свої блоки, і швидко реагувати на збої.