Введение

«Мы знали, что меньше, быстрее, дешевле лучше, чем у кого-либо еще в мире, и теперь мы применяем эти концепции к блокчейну». — Грег Фицджеральд, сооснователь Solana

Solana - высокопроизводительный блокчейн с низкой задержкой, известный своей скоростью, эффективностью и акцентом на пользовательский опыт. Его уникальная интегрированная архитектура позволяет проводить тысячи транзакций в секунду по всему миру на глобально децентрализованной сети. Со временем блока 400 миллисекунд и комиссиями за транзакцию, которые являются долей цента, он обеспечивает как скорость, так и экономическую выгоду. В этом отчете рассматриваются тонкости дизайна и функционирования Solana, исследуя ключевые механизмы и топологию сети, которые способствуют его возможностям.

Solana принимает комплексный подход к развитию блокчейна, используя десятилетний опыт основной команды в построении распределенных систем. Одним из основных принципов Solana является то, что программное обеспечение никогда не должно мешать аппаратному обеспечению. Это означает, что программное обеспечение максимально использует аппаратное обеспечение, на котором оно работает, и масштабируется с ним. Как объединенная экосистема, все приложения, построенные поверх этого единого блокчейна, наследуют композицию, что позволяет им взаимодействовать и строить друг на друге без проблем. Эта архитектура также обеспечивает простой и интуитивный пользовательский опыт без необходимости в мостах, отдельных идентификаторах цепей или фрагментации ликвидности.

Solana стремительно развивается, в последние времена произошли такие события, как SVM rollups иZK Сжатиекак важные решения по масштабированию. Хотя эти проекты когда-нибудь могут сформировать наше будущее представление о Solana, они находятся на очень ранних стадиях развития или принятия и не будут рассмотрены в данном отчете.

Жизненный цикл транзакции

Наш основной метод для понимания Solana в этом отчете будет жизненный цикл типичной транзакции. Чтобы построить базовую модель для понимания транзакций Solana, мы можем описать процесс следующим образом:

• Пользователи инициируют транзакции, все они отправляются текущему ведущему производителю блоков (известному как лидер). Лидер компилирует эти транзакции в блок, выполняя их, тем самым обновляя свое локальное состояние.
• Этот блок транзакций затем распространяется по всей сети для выполнения и подтверждения другими валидаторами.

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

Помнить

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

Шесть этапов

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

Предыдущие главы расположены в соответствии с этими шестью этапами. Окончательные главы - Gossip, Archive, Economics и Jito - устраняют любые недочеты. Важно отметить, что некоторые главы охватывают несколько этапов, а некоторые этапы появляются в нескольких главах.

Это перекрытие неизбежно, потому что шестиступенчатая структура имеет свои ограничения. На самом деле, Solana - это сложная распределенная система с множеством взаимозависимых элементов.

Пользователи

«У Solana есть потенциал стать Apple в мире криптовалют» — Радж Гокал, сооснователь Solana

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

Кошельки криптографически генерируют пользовательские ключевые пары, состоящие из открытого и закрытого ключей. Открытый ключ действует как уникальный идентификатор для их учетной записи и известен всем участникам сети. Учетная запись пользователя в Solana может рассматриваться как структура данных, которая содержит информацию и состояние, связанные с их взаимодействием с блокчейном Solana. Таким образом, открытый ключ похож на имя файла: так же как имя файла уникально идентифицирует файл в файловой системе, открытый ключ Solana уникально идентифицирует учетную запись в блокчейне Solana. Открытые ключи на Solana представлены в виде строк Base58, закодированных 32 байтами.

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 utilizesEd25519, широко используемый алгоритм цифровой подписи на эллиптических кривых, для своих потребностей в криптографии с открытым ключом. Ed25519 предпочтителен из-за небольшого размера ключа, небольшого размера подписи, быстрого вычисления и устойчивости к многим распространенным атакам. Каждый адрес кошелька Solana представляет собой точку на эллиптической кривой Ed25519.

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

Транзакции Solana

Отправка транзакции - единственный способ изменить состояние на Solana. Любая операция записи выполняется с помощью транзакции, а транзакции атомарны - либо все действия транзакции выполняются, либо транзакция завершается неудачей. Транзакция, более формально известная как «транзакционное сообщение», состоит из четырех разделов: заголовка, списка адресов аккаунтов, последнего блокхэша и инструкций.

• Заголовок: Заголовок содержит ссылки на список адресов учетных записей, указывающих, какие учетные записи должны подписать транзакцию.
• Адреса учетных записей: Этот список включает все учетные записи, которые будут прочитаны или записаны во время транзакции. Построение такого списка для каждой транзакции является уникальным требованием Solana и может быть вызовом для разработчиков. Тем не менее, знание заранее, с какими частями состояния будет взаимодействовать транзакция, позволяет оптимизировать то, что невозможно на многих других блокчейнах.
• Последний хэш блока: это используется для предотвращения дублирования и устаревших транзакций. Последний хэш блока истекает через 150 блоков (примерно 1 минуту). По умолчанию RPC пытается пересылать транзакции каждые 2 секунды, пока транзакция либо не завершится, либо последний хэш блока не истечет, после чего транзакция отбрасывается.
• Инструкции: Эти составляют основную часть транзакции. Каждая инструкция представляет собой определенную операцию (например, передачу, эмиссию, сжигание, создание учетной записи, закрытие учетной записи). Каждая инструкция определяет программу для выполнения, необходимые учетные записи и данные, необходимые для выполнения инструкции.

Количество инструкций в транзакции ограничивается в первую очередь ее размером, который может составлять до 1 232 байт. Существуют также ограничения на количество учетных записей, на которые можно ссылаться. Наконец, есть ограничения на сложность транзакции, измеряемую в единицах вычислений (CUs). CUs количественно характеризуют вычислительные ресурсы, затраченные на обработку транзакций.

Помнить

Самая маленькая единица SOL известна как "лампорт", эквивалентная одной миллиардной SOL, аналогично сатоши в Bitcoin. Лампорт назван в честьЛесли Лэмпорт, компьютерный ученый и математик, чьи исследования заложили много теоретических основ современных распределенных систем.

Стоимость выполнения транзакции в SOL разделяется на 2 части - базовую плату и плату за приоритет. Базовая плата составляет фиксированные 5000 лампортов за стоимость подписи, независимо от сложности транзакции, обычно в транзакции 1 подпись.

Сборы за приоритет являются технически опциональными, но в периоды повышенного спроса на блок-пространство становятся необходимыми. Эти сборы ценообразованы в микро-лампортах (миллионных частях лампорта) за вычислительную единицу. Их целью является действие в качестве сигнала цены, делая транзакции более экономически обоснованными для узлов-валидаторов для включения их в свои блоки.

общая комиссия = комиссия приоритизации + базовая комиссия

плата за приоритет = цена вычислительной единицы (микролампортов) x предел вычислительной единицы

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

‍

Отправка транзакций

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

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

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

Поставщики RPC (удаленного вызова процедур) выступают в качестве посредников между приложениями и валидаторами, которые создают блоки. Они являются важным сервисом, который позволяет приложениямпредставитьили моделировать подписанные транзакции и эффективно извлекать данные с цепи. Приложения, которые хотят взаимодействовать с сетью, делают это через точку JSON-RPC или WebSocket ( документы).

Помнить

Термин «неудачная транзакция» на Solana вводит в заблуждение и вызывает значительное недопонимание. Эти транзакции влекут за собой комиссии и выполняются успешно исполнителем именно так, как задумал подписант. Они «проваливаются» из-за логики транзакции, требующей этого. +80% «неудачных» транзакций происходят из-за кода ошибки 0x1771, который указывает на превышение суммы проскальзывания (данные). Известно, что 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, повысив требования к пересылке транзакций лидеру и снизив эффективность спам-атак. Эти изменения стимулировали приложения с высоким трафиком к вертикальной интеграции своей деятельности. Запуская собственные валидаторные узлы или имея доступ к заложенным соединениям, приложения могут обеспечить себе привилегированный доступ к лидеру, тем самым улучшив свои возможности по обработке транзакций.

Заметка о QUIC

В конце 2022 года Solana принялапротокол сетевого взаимодействия QUICдля управления передачей сообщений о транзакции лидеру. Этот переход был вызван сетевыми нарушениями, вызванными ботами, спамящими монеты NFT на цепочке. QUIC облегчает быструю асинхронную коммуникацию.

Изначально разработанGoogleВ 2012 году QUIC пытается предложить лучшее из обоих миров. Он облегчает быструю асинхронную связь, аналогичную UDP, но с безопасными сеансами и продвинутыми стратегиями управления потоком TCP. Это позволяет устанавливать ограничения на отдельные источники трафика, чтобы сеть могла сосредоточиться на обработке подлинных транзакций. Он также имеет концепцию отдельных потоков; таким образом, если одна транзакция отбрасывается, это не обязательно блокировать оставшиеся. Короче говоря, QUIC можно рассматривать как попытку объединить лучшие характеристики TCP и UDP.

Callout box

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

Строительство блоков

«Мы считаем SVM (Solana Virtual Machine) лучшей в терминах технологии виртуальной машины на данный момент.» — Андре Кронье, Фонд Фантом

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

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

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

После получения сообщения о транзакции они попадают в блок обработки транзакций (TPU), основную логику валидатора, ответственную за создание блоков. Здесь начинается последовательность обработки транзакций с этапа Fetch, где транзакции получаются через QUIC. Далее транзакции проходят на этап SigVerify, проходя жесткие проверки валидации. Здесь валидатор проверяет правильность подписей, проверяет правильное количество подписей и устраняет дублирующиеся транзакции.

Банковская сцена

Банковский этап можно описать как этап построения блока. Это самый важный этап TPU, который получил свое название от «банка». Банк представляет собой состояние на определенном блоке. Для каждого блока у Solana есть банк, который используется для доступа к состоянию на этом блоке. Когда блок становится окончательным после того, как достаточное количество валидаторов проголосовали за него, они сбросят обновления счетов из банка на диск, сделав их постоянными. Окончательное состояние цепочки является результатом всех подтвержденных транзакций. Это состояние всегда может быть детерминированно воссоздано из истории блокчейна.

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

Шесть потоков обрабатывают транзакции параллельно, из которых четыре посвящены обычным транзакциям, а два исключительно обрабатывают транзакции голосов, которые являются неотъемлемой частью механизма согласования Solana. Вся параллелизация обработки достигается за счет множества ядер ЦП; у валидаторов нет требований к графическим процессорам (GPU).документация).

После того, как транзакции были сгруппированы в записи, они готовы к выполнению виртуальной машиной Solana (SVM). Счета, необходимые для транзакции, заблокированы; выполняются проверки для подтверждения того, что транзакция является недавней, но еще не была обработана. Счета загружаются, и выполняется логика транзакции, обновляя состояния счетов. Хэш записи будет отправлен в службу Proof of History для записи (подробнее об этом в следующем разделе). Если процесс записи прошел успешно, все изменения будут зафиксированы в банке, и блокировки на каждом счете, установленные на первом этапе, будут сняты. Выполнение выполняется SVM, виртуальной машиной, построенной с использованием форка Solana rBPF, библиотека для работы с JIT-компиляцией и виртуальными машинами для программ eBPF. Обратите внимание, что Solana не указывает, как валидаторы выбирают порядок транзакций в блоке. Эта гибкость является ключевым моментом, к которому мы вернемся позже в разделе Economics + Jito этого отчета.

Помните

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

Клиенты

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

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

Доказательство истории

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

Proof of History (PoH) - это секретный ингредиент Solana, функционирующий как специальные часы в каждом валидаторе, обеспечивающие синхронизацию по всей сети. PoH устанавливает надежный источник правды для порядка событий и прошедшего времени. Самое важное, что он обеспечивает соблюдение графика лидеров. Несмотря на сходные названия, Proof of History не является алгоритмом консенсуса, таким как Proof of Work.

Оверхед коммуникации между узлами обычно возрастает по мере расширения сетей, и координация становится все более сложной. Solana смягчает это, заменяя межузловую коммуникацию локальным вычислением PoH. Это означает, что валидаторы могут фиксировать блок всего одним раундом голосования. Доверенные метки времени в сообщениях гарантируют, что валидаторы не могут перешагнуть друг друга и начать свои блоки преждевременно.

Основные свойства PoH - это уникальные свойства хэширующих алгоритмов, в частностиSHA256:

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

В каждом клиенте валидатора посвященная служба «Proof of History» непрерывно запускает алгоритм хеширования SHA256, создавая цепочку хешей. Входными данными каждого хеша является выход предыдущего хеша. Эта цепь действует так же, как проверяемая функция задержки, учитывая, что хеширование должно выполняться последовательно, и результаты будущих хешей невозможно знать заранее. Если служба PoH создает цепочку из тысячи хешей, мы знаем, что для вычисления каждого хеша последовательно должно пройти время — это можно представить как «микроподтверждение работы». Тем не менее, другие валидаторы могут проверить правильность тысячи хешей параллельно с намного более высокой скоростью, чем они были созданы, поскольку входные и выходные данные каждого хеша были переданы по сети. Следовательно, PoH сложно создать, но легко проверить.

Диапазон производительности при вычислении SHA-256 на разных процессорах удивительно узкий, с незначительными различиями среди самых быстрых машин. Общий верхний предел уже достигнут, несмотря на значительное время и усилия, затраченные на оптимизацию этой функции, в значительной степени из-за зависимости биткойна от нее.

Во время слота лидера сервис PoH получит вновь обработанные записи с банковского этапа. Текущий хэш PoH плюс хэш всех транзакций в записи объединяются в следующий хэш PoH. Это служит отметкой времени, вставляющей запись в цепочку хэшей, доказывая последовательность обработки транзакций. Этот процесс не только подтверждает прохождение времени, но и служит криптографической записью транзакций.

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

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

Помнить

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

Модель учетных записей

«Разделение кода и состояния в SVM было лучшим дизайнерским решением. Блаженны встроенные разработчики систем, которые религиозно вбили этот концепт мне в голову.» — Анатолий Яковенко, сооснователь Solana

Внутри валидатора Solana глобальное состояние поддерживается в базе данных учетных записей, известной как AccountsDB. Эта база данных отвечает за хранение всех учетных записей, как в памяти, так и на диске. Основная структура данных в индексе учетных записей - это hashmap, что практически делает 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) гарантирует, что у каждого кошелька может быть только одна ассоциированная учетная запись токена для каждого типа токена, обеспечивая стандартизированный способ управления учетными записями токенов.

Turbine

«Самое интересное в Solana — это не распараллеливание, SVM и не твиты Толи. Это то, о чем вы, вероятно, не слышали: турбина», — Мерт Мумтаз, Helius.

На этапе банковских операций транзакции организуются в записи и отправляются в поток Proof of History для отметки времени. Банк блока обновляется, и записи теперь готовы к следующей фазе — Turbine.

Турбина - это процесс, с помощью которого лидер распространяет свой блок по остальной сети. ВдохновленныйBitTorrent, он разработан для быстроты и эффективности, снижая нагрузку на коммуникацию и минимизируя объем данных, который необходимо отправить лидеру.

Turbine достигает этого путем разбиения данных транзакции на "лоскутки'' через процесс, называемый "измельчение". Лоскутки - это маленькие пакеты данных, до 1280 байт, аналогичные отдельным кадрам в видеопотоке. При повторной сборке эти лоскутки позволяют валидаторам воспроизвести весь блок. Лоскутки отправляются по Интернету между валидаторами с использованием UDP и используют кодирование стирания для обработки потери пакетов или злонамеренного отбрасывания пакетов.Кодирование стирания, аполиномСхема обнаружения и исправления ошибок на основе блоков обеспечивает целостность данных. Даже если некоторые фрагменты потеряны, блок все равно может быть восстановлен.

Фрагменты группируются в пакеты, известные как пакеты коррекции ошибок в прямом кодировании (FEC). По умолчанию эти пакеты состоят из 64 фрагментов (32 фрагмента данных + 32 фрагмента восстановления). Восстановление данных происходит для каждого пакета FEC, что означает, что до половины пакетов в пакете могут быть потеряны или повреждены, и все данные все равно могут быть восстановлены. Каждый пакет из 64 фрагментов меркелевского дерева подписывается лидером и связывается с предыдущим пакетом. Этот процесс обеспечивает возможность безопасного получения фрагментов от любого узла в сети, который ими обладает, поскольку цепь меркелевских корней обеспечивает проверяемый путь подлинности и целостности.

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

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

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

Консенсус

Некоторые умные люди говорят мне, что в Solana есть серьезное сообщество умных разработчиков... Надеюсь, что сообщество получит свой шанс процветать - Виталик Бутерин, сооснователь Ethereum

Как только валидатор получает новый блок от лидера через Turbine, он должен проверить все транзакции в каждой записи. Это включает повторное воспроизведение всего блока, проверку хэшей PoH параллельно, воссоздание транзакций в последовательности, заданной PoH, и обновление своего локального банка.

Этот процесс обрабатывается Юнитом валидации транзакций (TVU), который аналогичен Юниту обработки транзакций лидера (TPU), являющемуся основной логикой, ответственной за обработку фрагментов и проверку блока. Как и TPU, поток TVU разбит на несколько этапов, начиная с этапа получения фрагментов, где фрагменты получаются через Turbine. На последующем этапе проверки подписи лидера фрагменты проходят через несколько проверок на здравый смысл, в частности проверку подписи лидера, которая гарантирует, что полученные фрагменты происходят от лидера.

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

Этап воспроизведения аналогичен этапу банковского этапа в TPU; это самый важный этап, который можно более прямо описать как этап проверки блока. Replay - это однопоточный цикл процесса, который оркестрирует множество ключевых операций, включая голосование, сброс часов PoH и переключение банков.

Вверху: этап реплея отвечает за перевод валидатора в режим лидера и начало производства блока. Оригинальное изображение: Джастин Старри, Anza

Консенсус

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

Tower BFT отличается от других цепей тем, что использует синхронизированные часы, предоставляемые Доказательством Истории. В то время как традиционному PBFT требуется несколько раундов коммуникации для согласования порядка транзакций, узлы Solana используют заранее установленный порядок событий, что значительно сокращает накладные расходы на обмен сообщениями.

Голосование

Чтобы участвовать в консенсусе и получать вознаграждение, валидаторы отдают голоса за блоки, которые, по их мнению, являются действительными (т. е. свободными от таких проблем, как двойные траты или неправильные подписи) и должны считаться каноническими. Валидаторы платят комиссию за транзакции за эти голоса, которые обрабатываются лидером и включаются в блок вместе с обычными транзакциями пользователей. Вот почему транзакции Solana часто делятся на транзакции с голосованием и без голосования. Когда валидаторы отправляют правильный и успешный голос, они получают кредит. Этот механизм стимулирует валидаторов голосовать за форк, который, по их мнению, имеет наилучшие шансы быть включенным, т.е. за самый «тяжелый» форк.

Форки

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

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

Каждый слот имеет предопределенного лидера, для которого будет принят только блок этого лидера; не может быть двух предложенных блоков для одного слота. Поэтому количество потенциальных вилок ограничено списком пропусков типа "есть/нет" вилок, которые могут возникать на границах слотов смены лидера. Как только валидатор выбирает вилку, он привязан к этой вилке до истечения времени блокировки, что означает, что он должен придерживаться своего выбора в течение определенного минимального периода.

«Пропускной коэффициент» Solana — процент слотов, в которых блок не был создан, варьируется от 2% до 10%, причиной для пропуска слотов являются форки. Другие возможные причины пропуска слотов включают начало новой эпохи, отсутствие лидера или создание недопустимого блока.

Помните

Статус транзакции на Solana варьируется в зависимости от ее текущего этапа в процессе консенсуса:

• Обработано: Транзакция была включена в блок.

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

• Завершено: Более 31 блока было построено поверх блока транзакции.

На сегодняшний день в истории Solana не было случая, когда подтвержденный блок (оптимистично) не стал окончательным.

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

Сплетни + Архив

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

Сплетни

Сеть сплетен можно рассматривать какплоскость управлениядля сети Solana. В отличие от плоскости данных, которая обрабатывает потоки транзакций, управляющая плоскость распространяет важные метаданные о состоянии блокчейна, такие как контактная информация, высота журнала и информация о голосовании. Без сплетен валидаторы и RPC-серверы не узнали бы, какие адреса и порты открыты для связи между различными службами. Новые узлы также полагаются на сплетни, чтобы присоединиться к сети.

Протокол сплетен Solana использует неформальное одноранговое общение с подходом широковещательного дерева, вдохновленный модифицированным алгоритмом PlumTree. Этот метод эффективно распространяет информацию, не полагаясь на какой-либо центральный источник.

Gossip функционирует как изолированная система, независимая от большинства других компонентов валидатора. Валидаторы и RPC обмениваются подписанными объектами данных каждые 0,1 секунды по протоколу UDP через gossip, обеспечивая доступность информации по сети. Все сообщения gossip должны быть меньше или равны максимальному блоку передачи (MTU), равному 1280 байтам, называемому «структурой пакета» в кодовой базе.

Записи о сплетнях - это фактические объекты данных, распространяемые между узлами. Существует примерно 10 различных типов записей, каждая из которых служит разным целям. Записи о сплетнях подписаны, имеют версии и временные метки, чтобы гарантировать целостность и актуальность.

Существует четыре типа сплетенных сообщений:

• Push: Самые распространенные сообщения, обмен информацией с подмножеством "пиры для передачи данных".
• Проверка и ответ на проверку: периодически проверяет пропущенные сообщения, с ответами на проверку, отправляя информацию о том, что узлы не имеют.
• Обрезка: Позволяет узлам выборочно сокращать количество поддерживаемых соединений.
• Ping & Pong: Health checks for nodes—if a ping is sent, a pong is expected back, indicating the peer node is still active.

Данные о сплетнях хранятся в кластеризованном реплицируемом хранилище данных (CrdsTable). Эта структура данных может стать очень большой и время от времени требует очистки.

Архив

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

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

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

2. Экземпляр Google Bigtable: Хранит блочные данные с генезис-блока и далее, отформатированные для обслуживания запросов RPC.

Экономика + Джито

«Люди понимают, что 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, поскольку они просто отправляют транзакции на адрес и конфигурацию порта, которые лидер объявил по сети gossip в качестве их ingress_socket, предполагая, что это адрес лидера.

Реле хранит все транзакции в течение 200 миллисекунд перед их пересылкой лидеру. Этот механизм "скоростного бампера" задерживает входящие сообщения о транзакциях, предоставляя краткое время для проведения аукционов. Через 200 миллисекунд реле оптимистично выпускает транзакции независимо от результатов аукциона.

Аукционы места в блоках происходят вне цепи блоков через движок Jito Block, позволяя искателям и приложениям отправлять группы атомарно выполненных транзакций, известных как пакеты. Эти пакеты обычно содержат срочные транзакции, такие как арбитражи или ликвидации. Jito взимает комиссию в размере 5% на все чаевые, с минимальной чаевой в размере 10 000 лампортов. Чаевые работают полностью вне протокола, отдельно от приоритета и базовых комиссий внутри протокола. Ранее Jito использовал каноническую службу пула памяти вне протокола, которая теперь устарела.

Disclaimer：

1. Эта статья перепечатана из [Solanahelius]. Все авторские права принадлежат оригинальному автору [Lostin]. Если у вас есть возражения к этому повторному изданию, пожалуйста, свяжитесь с Gate Learnкоманда, и они быстро справятся с этим.
2. Ответственность за отказ: Взгляды и мнения, выраженные в этой статье, являются исключительно мнениями автора и не являются инвестиционными советами.
3. Переводы статьи на другие языки выполняются командой Gate Learn. Если не указано иное, копирование, распространение или плагиат переведенных статей запрещены.