Вступ

“Ми знали про менші, швидші, дешевші речі краще за будь-кого іншого у світі, і зараз ми застосовуємо ці концепції до блокчейну.” — Грег Фіцджеральд, співзасновник Solana

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

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

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

Цикл життя транзакції

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

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

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

Пам'ятайте

Значні зміни у базовому протоколі Solana проходять формальний, прозорий процеспроцесщодо подання Документа про покращення Solana (SIMD), який члени спільноти та основні інженери будуть публічно критикувати. Потім SIMD обговорюються у мережі.

Шість етапів

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

Раніше розділи були розташовані відповідно до цих шести етапів. Останні розділи - Плітки, Архів, Економіка і Джіто - зав'язують всі нитки. Важливо зауважити, що деякі розділи будуть охоплювати кілька етапів, а деякі етапи з'являтимуться у декількох розділах.

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

Користувачі

«Solana має потенціал стати Apple у криптосвіті» — Радж Гокал, співзасновник Solana

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

Гаманці криптографічно генерують пари ключів користувачів, що складаються з відкритого та закритого ключів. Публічний ключ виступає в якості унікального ідентифікатора їх облікового запису і відомий всім учасникам мережі. Обліковий запис користувача в Solana можна вважати структурою даних, яка містить інформацію та стан, пов'язані з його взаємодією з блокчейном Solana. Таким чином, відкритий ключ схожий на ім'я файлу: подібно до того, як ім'я файлу унікально ідентифікує файл у файловій системі, відкритий ключ Solana унікально ідентифікує обліковий запис у блокчейні Solana. Публічні ключі в Solana представлені у вигляді 32-байтових рядків, закодованих Base58.

FDKJvWcJNe6wecbgDYDFPCfgs14aJnVsUfWQRYWLn4Tn

Приватний ключ — також відомий як секретний ключ — може розглядатися як пароль або ключ доступу, який надає дозвіл на доступ та модифікацію облікового запису. Підписання за допомогою приватних ключів - це спосіб, яким блокчейни керують авторизацією. Знання приватного ключа дає абсолютну владу над обліковим записом. Приватні ключі Solana також мають довжину 32 байти. Ключові пари - це комбінації з 64 байтів публічних (перша половина) та приватних (друга половина) ключів. Приклади:

3j15jr41S9KmdfughusutvvqBjAeEDbU5sDQp8EbwQ3Hify2pfM1hiEsuFFAVq8bwGywnZpswrbDzPENbBZbd5nj

[63,107,47,255,141,135,58,142,191,245,78,18,90,162,107,197,8,33,211,15,228,235,250,30,185,122,105,23,147,115,115,86,8,155,67,155,110,51,117,0,19,150,143,217,132,205,122,91,167,61,6,246,107,39,51,110,185,81,13,81,16,182,30,71]

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

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

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

Транзакції Solana

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

• Заголовок: Заголовок містить посилання на список адрес рахунків, що показує, які облікові записи повинні підписати транзакцію.
• Адреси облікових записів: Цей список включає всі облікові записи, які будуть зчитуватися або записуватися під час транзакції. Побудова такого списку для кожної транзакції є вимогою, унікальною для Solana, і може бути викликана викликом для розробників. Однак заздалегідь знати, з якими частинами стану буде взаємодіяти транзакція, дозволяє оптимізацію, яка неможлива на багатьох інших блокчейнах.
• Останній блокхеш: Це використовується для запобігання дублювання та застарілих транзакцій. Останній блокхеш стає недійсним після 150 блоків (близько 1 хвилини). За замовчуванням, RPC намагається переслати транзакції кожні 2 секунди, поки транзакція не буде завершена або останній блокхеш не стане недійсним, після чого транзакція відхиляється.
• Інструкції: Це становить основну частину угоди. Кожна інструкція представляє собою конкретну операцію (наприклад, передачу, виготовлення, знищення, створення облікового запису, закриття облікового запису). Кожна інструкція вказує програму для виконання, необхідні облікові записи та дані, необхідні для виконання інструкції.

Кількість інструкцій у транзакції спочатку обмежується її розміром, який може становити до 1,232 байтів. Існують також обмеження на кількість облікових записів, на які можна посилатися. Нарешті, існують обмеження на складність транзакції, виміряну в обчислювальних одиницях (CUs). CUs вимірюють обчислювальні ресурси, витрачені на обробку транзакцій.

Пам'ятайте

Найменша одиниця SOL відома як "лампорт," еквівалентна одній мільярдній частині SOL, схожа на сатоші в Bitcoin. Лампорт названий на честьLeslie Lamport, комп'ютерний вчений та математик, чиї дослідження заклали багато теоретичних засад сучасних розподілених систем.

Вартість у SOL для виконання операції розділена на 2 частини - базова плата та плата за пріоритет. Базова плата становить фіксований витрат 5000 лампортів на вартість підпису без врахування складності транзакції - зазвичай є 1 підпис на операцію.

Вартість пріоритетних внесків технічно є необов'язковою, але під час періодів великого попиту на блокпростір вони стають необхідними. Ці внески цінуються в мікро-лампортах (мільйонна частина лампорта) за одиницю обчислення. Їх мета - діяти як сигнал ціни, роблячи транзакції економічно більш привабливими для вузлів валідаторів для включення в їх блоки.

загальна плата = плата за пріоритет + базова плата

пріоритетна плата = ціна обчислювальної одиниці (мікролампорти) x ліміт обчислювальної одиниці

На даний момент 50% усіх зборів, пов'язаних з транзакціями, згорають, назавжди вилучаючи цей SOL з обігу, а решта 50% йде до блокувальника. Згодом буде представлено нова зміна (SIMD 96), яка дозволить 100% плати за пріоритет перейти до блокувальника. Базові збори залишаються без змін.

‍

Відправлення транзакцій

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

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

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

Постачальники RPC (віддаленого виклику процедур) виступають посередниками між програмами та валідаторами, які формують блоки. Це є невід'ємною послугою, яка дозволяє програмамподатиабо симулювати підписані транзакції та ефективно отримувати дані з ланцюжка. Додатки, які бажають спілкуватися з мережею, роблять це через кінцеву точку JSON-RPC або WebSocket (документи.

Пам'ятайте

Термін “невдала транзакція” на Solana є вводячим і викликав значну плутанину. Ці транзакції супроводжуються комісією й успішно виконуються рантаймом точно так, як підписник цього бажав. Вони “зазнають невдачі” через власну логіку транзакції, що вимагає цього. +80% “невдалих” транзакцій походить з коду помилки 0x1771, коду для перевищення обсягу усунення (slippage amount)дані). Зокрема, 95% цих транзакцій подаються лише 0,1% активних адрес Solana, переважно автоматизовані боти, які намагаються скористатися можливостями арбітражу цін, що чутливі до часу.

Гольфстрім

«Буквально мета Solana - переносити транзакції так швидко, як новини поширюються по всьому світу - отже, швидкість світла через оптоволокно. З ким ми конкуруємо - це NASDAQ та Нью-Йоркська фондова біржа.» - Анатолій Яковенко, співзасновник Solana

RPC (Віддалені виклики процедур) посилаються на вузли RPC. Ці вузли можна розглядати як шлюзи для взаємодії та читання даних з мережі. Вони працюють з тим самим програмним забезпеченням, що й повноцінні перевіряючі, але з різними налаштуваннями, що дозволяє їм точно симулювати транзакції та підтримувати актуальний стан. На момент написання цього тексту на мережі Solana більше 4 000 вузлів RPC.

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

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

Виклик

Solana працює на чотирьох кластерах: Localnet, Testnet, Devnet та Mainnet-Beta. Коли люди посилаються на Solana або мережу Solana, вони майже завжди посилаються на Mainnet-Beta. Mainnet-Beta - це єдиний кластер, де токени мають реальну вартість, тоді як інші кластери використовуються виключно для тестування.

Якщо RPC отримує повідомлення про транзакцію для включення в блок, його необхідно переслати лідеру. Розклад лідера створюється перед кожною епохою (приблизно кожні два дні). Наступна епоха розділена на слоти, кожен з фіксованою тривалістю 400 мілісекунд, і для кожного слоту обирається лідер. Валідатори з вищим стейком частіше обираються лідерами протягом кожної епохи. Під час кожного слоту повідомлення про транзакції пересилаються лідеру, у якого є можливість створити блок. Коли черга до валідатора, вони переходять у «режим лідера», починають активно обробляти транзакції та розповсюджувати блоки по всій мережі.

Стейк-зважена якість обслуговування - SWQoS

У початку 2024 року Solana впровадила новий механізм, спрямований на запобігання спаму та підвищення стійкості до Сібіла, відомий як "Стейк-зважений якість обслуговування" (SWQoS). Ця система дозволяє лідерам пріоритизувати повідомлення про транзакції, які проксіюються через інших відданих валідаторів. Тут відданим з вищим стейком надається пропорційно вища можливість передачі пакетів повідомлень про транзакції лідеру. Цей підхід ефективно пом'якшує атаки Сібіла від невідданих вузлів по всій мережі.

За цією моделлю валідатори також можуть укладати угоди про оренду своєї ємності, зваженої за ставкою, до вузлів RPC. Натомість вузли RPC отримують збільшену пропускну здатність, що дозволяє їм досягати більших швидкостей включення транзакцій в блоки. Значно варто відзначити, що 80% ємності лідера (2 000 з'єднань) зарезервовано для SWQoS. Решта 20% (500 з'єднань) виділяється для транзакційних повідомлень від невкладених вузлів. Ця стратегія розподілу відображає пріоритетні смуги на шосе, де водії платять мито, щоб уникнути заторів.

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

Швидка замітка

У кінці 2022 року Solana прийнялапротокол мережевого взаємодії QUICдля керування передачею повідомлення про транзакцію лідеру. Цей перехід був спричинений мережевими розладами, спричиненими ботами, які спамлять онлайнові мінти NFT. QUIC сприяє швидкій асинхронній комунікації.

Спочатку розробленийGoogleУ 2012 році QUIC намагається пропонувати найкраще з обох світів. Він сприяє швидкій, асинхронній комунікації, схожій на UDP, але з безпечними сеансами та передовими стратегіями керування потоком TCP. Це дозволяє обмежувати джерела трафіку, щоб мережа могла фокусуватися на обробці справжніх транзакцій. Він також має концепцію окремих потоків; тому якщо одна транзакція втрачена, це не потрібно блокувати решту. Коротко кажучи, QUIC можна вважати спробою поєднати найкращі характеристики TCP та UDP.

Callout box

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

Блок-будівництво

«Ми вважаємо SVM (Solana Virtual Machine) найкращим у сфері технології віртуальних машин на сьогодні.» — Андре Кроньє, Фонд Фантом

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

Кожен слот триває 400 мілісекунд, і кожному лідеру призначають чотири послідовні слоти (1,6 секунди) перед переходом до наступного лідера. Щоб блок отримав прийняття, всі транзакції всередині нього повинні бути дійсними та відтворюваними іншими вузлами.

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

Після отримання повідомлень про транзакції вони потрапляють в Одиницю обробки транзакцій (TPU), основну логіку перевірки блоків валідатора. Тут послідовність обробки транзакцій починається з етапу отримання (Fetch Stage), де транзакції отримуються через QUIC. Наступною є етап перевірки підпису (SigVerify Stage), де вони проходять важкі перевірки валідації. Тут валідатор перевіряє валідність підписів, перевіряє правильну кількість підписів та усуває дубльовані транзакції.

Банківська сцена

Банківський етап можна охарактеризувати як етап будівництва блоків. Це найважливіший етап ТПУ, який отримав свою назву від «банку». Банк – це просто держава в даному блоці. Для кожного блоку Solana має банк, який використовується для доступу до стану в цьому блоці. Коли блок завершується після того, як за нього проголосує достатня кількість валідаторів, вони видаляють оновлення облікового запису з банку на диск, роблячи їх постійними. Остаточний стан ланцюжка є результатом всіх підтверджених транзакцій. Цей стан завжди можна відтворити з історії блокчейну детерміністично.

Транзакції обробляються паралельно і упаковуються в «записи» бухгалтерського обліку, які є пакетами з 64 неконфліктуючих транзакцій. Паралельна обробка транзакцій у Solana спрощується, оскільки кожна транзакція повинна включати повний список усіх облікових записів, на які вона читатиме та записуватиметься. Такий вибір дизайну накладає тягар на розробників, але дозволяє валідатору уникнути умов гонки, легко вибираючи для виконання лише неконфліктні транзакції в кожному записі. Транзакції конфліктують, якщо вони обидва намагаються записувати дані на один і той самий рахунок (два записи) або якщо один намагається читати з одного облікового запису, а інший записує на той самий рахунок (читання + запис). Таким чином, конфліктуючі транзакції потрапляють в різні записи і виконуються послідовно, в той час як неконфліктні транзакції виконуються паралельно.

Існує шість потоків, які обробляють транзакції паралельно, чотири з них призначені для звичайних транзакцій, а два виключно обробляють транзакції голосування, які є невід'ємною частиною механізму консенсусу Solana. Усі паралельні операції обробки виконуються за допомогою кількох ядер процесора; валідатори не мають вимог до GPU.документація).

Після того як транзакції були згруповані в записи, вони готові до виконання віртуальною машиною Solana (SVM). Рахунки, необхідні для транзакції, заблоковані; запускаються перевірки для підтвердження того, що транзакція є останньою, але її ще не оброблено. Рахунки завантажуються, і виконується логіка транзакції, оновлюючи стани рахунків. Хеш запису буде відправлений до служби Proof of History для запису (про це докладніше у наступному розділі). Якщо процес запису вдалий, всі зміни будуть зафіксовані в банку, і блокування на кожному рахунку, встановлені на першому кроці, будуть зняті. Виконання здійснюється SVM, віртуальною машиною, побудованою з використанням гілки Solana rBPF, бібліотека для роботи з JIT компіляцією та віртуальними машинами для програм eBPF. Зверніть увагу, що Solana не наказує валідаторам вибирати спосіб упорядкування транзакцій у межах блоку. Ця гнучкість є важливою точкою, на яку ми повернемося пізніше в розділі Економіка + Jito цього звіту.

Пам'ятай

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

Клієнти

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

Solana запустила з одним клієнтом-валідатором програмного забезпечення — спочатку клієнт Solana Labs, тепер відомий якКлієнт Agave— написаний на Rust. Розширення різноманітності клієнтів було пріоритетом з моменту запуску і це дійсно збудеться зі стартомКлієнт FiredancerFiredancer - це повний перепис клієнта з нуля на мові програмування C. Розроблений досвідченою командою з фірми з високочастотним трейдингом Jump, він обіцяє бути найпродуктивнішим клієнтом валідатора на будь-якому блокчейні.

Доказ історії

«Я випив дві кави і пиво, і не ліг спати до 4:00 ранку. У мене був цей еврейський момент, що головоломка [sic] схожа на доказ роботи, використовуючи ту саму функцію хешування зі стійкістю до попереднього образу SHA-256... Я знав, що у мене був цей стрілець часу.» — Анатолій Яковенко, співзасновник Solana

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

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

Основні властивості PoH - це унікальні властивості алгоритмів хешування, зокремаSHA256:

• Детермінований: Той же ввід завжди вироблятиме той же хеш.
• Фіксований розмір: Незалежно від розміру введення, вихідний хеш завжди має розмір 256 бітів.
• Ефективний: Обчислення хешу для будь-якого введення відбувається швидко.
• Стійкість до образів: Знаходження початкового вводу з хеш-виводу обчислювально неможливо.
• Ефект лавини: Навіть невелика зміна в введенні (навіть один біт) призводить до значно різних хеш-значень, властивість, відому як ефект лавини.
• Стійкість до зіткнень: Неможливо знайти два різних входи, які виробляють однаковий вихідний хеш.

У межах кожного клієнта-валідатора постійно працює відділений "сервіс доказу історії", який безперервно виконує хеш-алгоритм SHA256, створюючи ланцюжок хешів. Вхідним для кожного хешу є вихід попереднього хешу. Цей ланцюжок працює так само, як функція перевірки затримки, оскільки хешування має виконуватися послідовно, і результатів майбутніх хешів не можна знати заздалегідь. Якщо сервіс PoH створює ланцюжок тисячі хешів, ми знаємо, що пройшов час для обчислення кожного хешу послідовно - це можна розглядати як "мікродоказ роботи". Однак інші валідатори можуть перевірити правильність тисячі хешів паралельно набагато швидше, ніж вони були створені, оскільки вхід і вихід кожного хешу були розіслані в мережу. Таким чином, PoH складно виробляти, але легко перевіряти.

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

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

У єдиному блоку є 800 000 хешів. Потік PoH також включає "тики", які є порожніми записами, що вказують на активність лідера та проміжок часу, що приблизно відповідає дрібній частині секунди. Кожні 6,25 мілісекунд відбувається тік, що призводить до 64 тіків на блок та загального часу блоку у 400 мілісекунд.

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

Пам'ятай

Основна перевага PoH полягає в тому, що вона гарантує, що правильний графік лідера повинен дотримуватися, навіть якщо виробник блоків не в мережі - стан, відомий як «дебітор». PoH запобігає зловживання зловмисного валідатора у виробництві блоків до їх черги.

Модель рахунків

«Відокремлення коду та стану в SVM було найкращим рішенням дизайну. Благословенні вбудовані розробники систем, які релігійно вбивали цей концепцію у мою голову.» — Анатолій Яковенко, співзасновник Solana

У мережі валідаторів Solana глобальний стан зберігається в базі даних рахунків, відомій як AccountsDB. Ця база даних відповідає за зберігання всіх рахунків, як в оперативній пам'яті, так і на диску. Основна структура даних у індексі рахунків - це хеш-таблиця, що робить AccountsDB по суті обширноюсховище ключ-значенняТут ключ - це адреса облікового запису, а значення - це дані облікового запису.

З часом кількість облікових записів Solana зросла до сотень мільйонів. Ця велика кількість частково пояснюється тим, що, як люблять казати розробники Solana, «Все на Solana - це обліковий запис!»

Облікові записи Solana

Акаунт є контейнером, який постійно утримує дані, схожий на файл на комп'ютері. Вони надходять у різних формах:

• Облікові записи користувачів: Ці облікові записи мають приватний ключ і зазвичай генеруються програмним забезпеченням гаманця для користувача.
• Облікові записи даних: Ці облікові записи зберігають інформацію про стан, таку як кількість певного токена, яку утримує користувач.
• Облікові записи програм: Це великі облікові записи, які містять виконуваний байт-код, що в деякій мірі еквівалентний файлу .exe в Windows або файлу .app на Mac.
• Нативні облікові записи програми: Це спеціальні передвстановлені облікові записи програми, які виконують різноманітні основні функціональні можливості мережі.Прикладивключають Програму Голосу та Завантажувач BPF.

У всіх облікових записах є такі поля:

Програми

Облікові записи програм Solana містять лише виконавчу логіку. Це означає, що під час виконання програми відбувається мутація стану інших облікових записів, а сама програма залишається незмінною. Це розділення коду та стану відрізняє Solana від інших блокчейнів та підтримує багато з його оптимізацій. Розробники в першу чергу пишуть ці програми на мові програмування Rust, загального призначеннявідомийза своєю сильною увагою до безпеки та продуктивності. Крім того, доступні кілька SDK на TypeScript та Python для сприяння створенню фронтендів додатків та забезпечення програмного взаємодії з мережею.

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

Оренда

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

Наприклад, якщо користувач утримує стабільну монету, яка деномінована в доларах, цей стан зберігається на рахунку токенів. Наразі розмір, звільнений від оренди, для рахунку токенів становить 0,002 SOL. Якщо користувач передає всю свою стабільну монету другу, рахунок токенів може бути закритий, і користувач отримає назад свої 0,002 SOL. Програми часто автоматично обробляють закриття рахунків для користувачів. Декілька програм доступні для допомоги користувачам у прибиранні старих, не використовуваних рахунків та відновленні невеликих сум SOL, які в них зберігаються.

Власність

Під час читання даних облікового запису загальновідомо, що власність Solana покращує безпеку, обмежуючи точно, хто може змінювати (писати) дані облікового запису. Ця концепція є важливою для здійснення правил та дозволів на блокчейні Solana. У кожного облікового запису є програмний «власник». Власник облікового запису відповідає за його управління, забезпечуючи, що лише авторизовані програми можуть змінювати дані облікового запису. Важливим винятком з цього правила є передача лампортів (найменшої одиниці SOL) - збільшення балансу лампортів облікового запису загальновідомо дозволене, незалежно від власності.

Зберігання стану

Програми Solana, які є лише виконуваними файлами для читання, повинні зберігати стан, використовуючи «Адреси, похідні від програми» (PDAs). PDAs - це спеціальні типи облікових записів, які пов'язані із програмою та власником якої є програма, а не конкретний користувач. Хоча звичайні адреси користувачів Solana походять від публічного ключа пари ключів Ed25519, у PDAs немає приватного ключа. Замість цього їх публічний ключ походить від комбінації параметрів — часто ключових слів або інших адрес облікових записів — разом із ідентифікатором програми (адресою), яка є власником.

Адреси PDA існують "поза кривою", що означає, що вони не знаходяться на кривій Ed25519, як звичайні адреси. Лише програма, яка володіє PDA, може програмно генерувати підписи для неї, забезпечуючи, що лише вона може змінювати стан PDA.

Вище: Облікові записи токенів Solana є конкретними прикладами адрес, похідних від програм (PDAs). Вони використовуються для утримання токенів та живуть "поза кривою". Програма Асоційованого Облікового Запису (ATA) забезпечує, що кожний гаманець може мати лише один асоційований обліковий запис токенів для кожного типу токенів, забезпечуючи стандартизований спосіб управління обліковими записами токенів.

Турбіна

«Найцікавіша частина про Solana - це не паралелізація, МСВ чи твіти Толі. Це щось, про що ви, ймовірно, не чули: Турбіна.» - Мерт Мумтаз, Helius

Під час банківської стадії транзакції організовані у записи та відправлені в потік Proof of History для відмітки часу. Банк блоку оновлюється, і записи тепер готові до наступної фази - Турбіна.

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

Turbine досягає цього, розбиваючи дані транзакцій на «шматочки» через процес, що називається «розрізанням». Шматочки - це невеликі пакети даних, до 1280 байт, схожі на окремі кадри в потоці відео. Після збирання ці шматочки дозволяють валідаторам відтворювати весь блок. Шматочки надсилаються по Інтернету між валідаторами за допомогою UDP та використовують кодування знищення для обробки втрати пакетів або зловживання втратою пакетів.Кодування затирання, аполіном-заснована схема виявлення та виправлення помилок, гарантує цілісність даних. Навіть якщо деякі шматки втрачені, блок все одно може бути відновлений.

Фрагменти групуються в партії, відомі як партії корекції помилок вперед (FEC). За замовчуванням ці партії складаються з 64 фрагментів (32 фрагменти даних + 32 фрагменти відновлення). Відновлення даних відбувається за кожною партією FEC, що означає, що до половини пакетів у партії можуть бути втрачені або пошкоджені, і всі дані все ще можна відновити. Кожну партію з 64 фрагментів маркується коренем, який підписується лідером, та ланцюгом до попередньої партії. Цей процес забезпечує, що фрагменти можна безпечно отримати з будь-якого вузла в мережі, який їх має, оскільки ланцюг коренів Меркла надає перевірний шлях автентичності та цілісності.

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

Дерево зазвичай охоплює два або три кроки, в залежності від кількості активних перевіряючих. Для візуальної простоти вище зображено фанаут 3, але фактичне значення фанауту Solana наразі встановлено на 200. З міркувань безпеки порядок дерева обертається для кожної нової порції обривів.

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

Консенсус

"Деякі розумні люди кажуть мені, що в Solana є серйозна розробницька спільнота... Я сподіваюсь, що спільнота отримає свій справедливий шанс процвітати" — Віталік Бутерін, співзасновник Ethereum

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

Цей процес обробляється Одиницею перевірки транзакцій (TVU), яка аналогічна Одиниці обробки транзакцій (TPU) лідера, що відповідає як основна логіка для обробки фрагментів та перевірки блоку. Подібно до TPU, потік TVU розбивається на кілька етапів, починаючи з етапу отримання фрагментів, де фрагменти отримуються через турбіну. На наступному етапі перевірки підпису лідера фрагменту, фрагменти проходять кілька перевірок розумності, зокрема перевірку підпису лідера, що забезпечує, що отримані фрагменти походять від лідера.

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

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

Вище: етап повторення відповідає за переключення валідатора в режим лідера та початок виробництва блоків. Оригінальне візуальне зображення: Джастін Старрі, Анза

Консенсус

Для досягнення консенсусу Solana використовує Tower BFT (TBFT), власну реалізацію добре відомого ПрактичногоВізантійська вадаАлгоритм терпимості (PBFT), який загалом використовується більшістю блокчейнів для узгодження стану ланцюжка. Як і всі блокчейни, Solana припускає наявність зловмисних вузлів у мережі, тому система повинна витримувати не лише відмовки вузлів, а й певний рівень атак.

Tower BFT відрізняється від інших ланцюжків тим, що використовує синхронізований годинник, наданий Proof of History. У той час як традиційний PBFT потребує декількох раундів комунікації для узгодження порядку транзакцій, вузли Solana використовують попередньо встановлений порядок подій, що значно зменшує накладні витрати на повідомлення.

Голосування

Щоб взяти участь у консенсусі та отримати винагороду, валідатори подають голоси за блоки, які вони вважають дійсними (тобто вільними від таких проблем, як подвійні витрати або неправильні підписи) і повинні вважатися канонічними. Валідатори платять комісію за транзакції за ці голоси, які обробляються лідером і включаються в блок разом зі звичайними транзакціями користувачів. Ось чому транзакції Solana часто поділяються на транзакції з голосуванням і без голосування. Коли валідатори подають правильний і успішний голос, вони отримують кредит. Цей механізм стимулює валідаторів голосувати за форк, який, на їхню думку, має найкращі шанси бути включеним, тобто «найважчий» форк.

Forks

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

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

Кожен слот має заздалегідь визначеного лідера, для якого буде прийнятий лише блок цього лідера; не може бути два запропонованих блоки для одного слоту. Тому кількість потенційних вілок обмежена "існує/не існує" переліком вілок, які можуть виникнути на межах слотів обертання лідера. Як тільки валідатор вибирає вілку, він зобов'язаний до цієї вілки до закінчення часу блокування, що означає, що він повинен прилипати до свого вибору протягом мінімального періоду.

Пропускна "швидкість" Solana - відсоток слотів, в яких блок не було вироблено, коливається від 2% до 10%, причиною цих пропущених слотів є вілки. Інші можливі причини пропущених слотів включають початок нової епохи, відсутність лідера або виробництво недійсного блоку.

Пам'ятайте

Статус транзакції на Solana змінюється в залежності від її поточного етапу в процесі консенсусу:

• Оброблено: Транзакцію включено в блок.

• Підтверджено: Блок транзакції було схвалено двотретинною супербільшістю голосів.

• Завершено: Понад 31 блок було побудовано на вершині блоку транзакції.

До цього часу в історії Solana не було жодного випадку, коли (оптимістично) підтверджений блок не став остаточним.

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

Чутки + Архів

«Блокчейн вимагає розумного поєднання криптографії, розподілених систем, операційних систем та мов програмування. Суперсила Solana полягала в готовності втікати, кричачи від найцікавіших проблем у кожній дисципліні.» — Грег Фіцджеральд, співзасновник Solana

Плітки

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

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

Плітки працюють в певній мірі як ізольована система, незалежна від більшості інших компонентів валідатора. Валідатори та RPC-сервери обмінюються підписаними об'єктами даних кожні 0,1 секунди через UDP за допомогою пліток, забезпечуючи доступність інформації по всій мережі. Усі повідомлення про плітки повинні бути меншими або рівними максимальному одиниці передачі (MTU) 1280 байт, в кодовій базі вони називаються "структурою пакета".

Записи чуток - це фактичні об'єкти даних, якими діляться вузли. Існує приблизно 10 різних типів записів, кожен з яких служить різним цілям. Записи чуток підписані, мають версії та мітки часу для забезпечення цілісності та актуальності.

Є чотири типи чуток:

• Push: Найбільш поширені повідомлення, які діляться інформацією з підмножиною «підтягуючих пірсів».
• Періодично перевіряє пропущені повідомлення, відправляючи відповіді на запити, які повертають інформацію про те, якої вузли не мають.
• Вирізати: Дозволяє вузлам вибірково зменшувати кількість з'єднань, які вони підтримують.
• Ping & Pong: Перевірки стану вузлів — якщо відправлено пінг, очікується повернення понгу, що показує, що вузол-рівня є активним.

Дані чуток зберігаються в кластерному реплікованому сховищі даних (CrdsTable). Ця структура даних може стати дуже великою і потребує періодичного очищення.

Архів

Solana виділяється серед інших блокчейнів тим, що не потрібно весь час визначати поточний стан облікового запису. Модель облікових записів Solana забезпечує, що стан на будь-якому слоті відомий, що дозволяє валідаторам зберігати поточний стан кожного облікового запису без обробки всіх історичних блоків. RPC та валідатори, за концепцією, не зберігають весь історичний реєстр. Замість цього вони зазвичай зберігають лише дані про 1 або 2 епохи (2-4 дні) транзакцій, що є достатнім для перевірки верхівки ланцюжка.

Архіви в даний час управляються "складськими вузлами," які обслуговуються професійними постачальниками служб RPC, фондом Solana та іншими учасниками екосистеми, які цікавляться забезпеченням доступності історії транзакцій. Складські вузли зазвичай підтримують один або обидва наступні пункти:

1. Архів журналу: Завантажує сирі знімки журналу та бази даних облікових записів, придатні для повторного відтворення з нуля.

2. Інстанція Google Bigtable: Зберігає блокові дані від блоку генезису та далі, відформатовані для обробки запитів RPC.

Економіка + Jito

"Люди усвідомлюють, що Solana єдиний ланцюжок, доступний сьогодні, який підтримуватиме основні споживчі додатки". — Тед Лівінгстон, засновник Code

Solana використовує інфляцію для розподілу винагороди за стейкінг шляхом генерації нових токенів SOL кожної епохи. Цей процес призводить до зменшення частки мережі у нестейкерів в порівнянні зі стейкерами, що призводить до перенесення багатства від нестейкерів до стейкерів. Інфляція розпочалася в початковому вигляді в 2021 році за початковою ставкою 8%, яка зменшується на 15% щорічно до стабілізації на довгостроковій ставці 1,5%.

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

‍

Винагороди за голосування

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

Найкращі перевіряючі успішно голосують приблизно на 90% слотів. Зверніть увагу, що відсоток слотів без блоків (відсоток пропущених слотів) коливається від 2% до понад 10%, і на ці слоти не можна голосувати. Середній перевіряючий успішно голосує приблизно на 80% слотів, заробляючи 345,600 кредитів за епоху з 432,000 слотів.

Загальний пул інфляції спочатку розподіляється на основі зароблених кредитів за епоху. Частина загальної кількості кредитів валідатора (їх кредити, поділені на суму всіх кредитів усіх валідаторів) визначає їх пропорційну винагороду. Це додатково зважується за стейком.

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

Різниця в продуктивності голосування - одна з причин того, чому доходи (вимірювані в APY), які валідатори пропонують стейкерам, відрізняються. Ще одним фактором є комісійна ставка, яку беруть валідатори, яка є відсотком від загальних нагород за інфляцію, спрямованих на їх валідатор. Крім того, валідатор, який знаходиться в автономному режимі або не синхронізований з блокчейном (відомий як прогалина), значно впливає на доходи.

Винагороди за блок

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

Рідке стейкінг

Рідке стейкінг став популярною альтернативою власному стейкінгу. Учасники отримують токен, відомий як токен рідкого стейкінгу (LST) або похідний токен рідкого стейкінгу (LSD), в обмін на стейкінг їх SOL, зазвичай в стейк-пулі, який делегує їхні токени на кілька валідаторів. Нові отримані токени LST представляють частку стейкнутих SOL користувача. Ці токени можна торгувати, використовувати в додатках або передавати іншим, при цьому отримуючи винагороду за стейкінг. Основна перевага цієї системи полягає в тому, що вона значно підвищує капіталовкладеність.

Ціна LST = (загальна кількість SOL, закріплена в пулі * ціна SOL) / всього витрачено LST

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

Jito

На момент написання, понад 80% ( джерелоЧастина ставки на Solana використовує програмне забезпечення валідатора Jito. Цей клієнт, форк оригінального клієнта Agave, вводить аукціон поза протоколом блокпейсу, який надає валідаторам додаткові економічні стимули через чайки. Цей додатковий стимул є основним фактором широкого поширення клієнта Jito серед валідаторів.

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

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

Аукціони місця блоків відбуваються офлайн через Jito Block Engine, що дозволяє пошуковикам та додаткам надсилати групи атомарно виконаних транзакцій, відомих як пакети. Ці пакети зазвичай містять транзакції, які вимагають часових обмежень, такі як арбітражі або ліквідації. Jito бере комісію в розмірі 5% з усіх чайок, з мінімальною чайкою в розмірі 10 000 лампортів. Чайки функціонують абсолютно поза протоколом, окремо від пріоритету та базових комісій у протоколі. Раніше Jito працював над канонічною службою пам'яті поза протоколом, яка зараз застаріла.

Відмова від відповідальності:

1. Ця стаття публікується з [helius]. Усі авторські права належать оригінальному автору [Загублений]. Якщо є виклики до цього повторного друку, будь ласка, зв'яжіться з Gate Learnкоманді, і вони оперативно займуться цим.
2. Відповідальність за відмову: Погляди та думки, висловлені в цій статті, належать виключно автору і не становлять жодної інвестиційної поради.
3. Переклади статті на інші мови виконуються командою Gate Learn. Якщо не зазначено інше, копіювання, поширення або плагіатування перекладених статей заборонене.