Обзор Solana для руководителей

Введение

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

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

Solana быстро развивается. Среди недавних нововведений — роллапы SVM и ZK Compression как важные решения для масштабирования. Возможно, однажды эти проекты изменят наше восприятие Solana, но сейчас они находятся на самых ранних стадиях разработки или внедрения, поэтому в этом отчёте не рассматриваются.

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

В этом отчёте мы будем рассматривать Solana прежде всего через жизненный цикл типичной транзакции. Базовую модель транзакций Solana можно представить следующим образом: 

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

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

Шесть этапов

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

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

Такое пересечение неизбежно, поскольку модель из шести этапов имеет свои ограничения. В действительности 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]

Закрытые ключи также можно получить из мнемонических seed-фраз, обычно состоящих из 12 или 24 слов. Этот формат часто используется в кошельках для упрощения резервного копирования и восстановления. Из одной seed-фразы можно детерминированно получить несколько ключей.

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

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

Транзакции Solana‍

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

Заголовок

Заголовок содержит ссылки на список адресов аккаунтов и указывает, какие аккаунты должны подписать транзакцию.

Адреса аккаунтов

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

Недавний хеш блока

Он используется для предотвращения дублирующихся и устаревших транзакций. Недавний хеш блока истекает через 150 блоков, то есть примерно через 1 минуту. По умолчанию RPC пытаются пересылать транзакции каждые 2 секунды, пока транзакция не будет финализирована или пока не истечёт недавний хеш блока. После этого транзакция отбрасывается.

Инструкции

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

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

Стоимость выполнения транзакции в SOL состоит из двух частей: базовой комиссии и комиссии за приоритет. Базовая комиссия фиксирована и составляет 5 000 лампортов за подпись независимо от сложности транзакции. Обычно на одну транзакцию приходится одна подпись.

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

total fee = prioritization fee + base fee

prioritization fee = compute unit price (micro-lamports) x compute unit limit

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

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

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

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

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

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

Gulf Stream

RPC (Remote Procedure Calls) означает RPC-ноды. Такие ноды можно рассматривать как шлюзы для взаимодействия с сетью и чтения данных из неё. Они используют то же программное обеспечение, что и полноценные валидаторы, но с другими настройками. Благодаря этому они могут точно симулировать транзакции и поддерживать актуальное представление о текущем состоянии. На момент написания статьи в сети Solana насчитывается более 4 000 RPC-нод.

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

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

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

Взвешенное по стейку качество обслуживания — SWQoS

В начале 2024 года Solana внедрила новый механизм для предотвращения спама и повышения устойчивости к атакам Сивиллы — Stake-Weighted Quality of Service (SWQoS). Эта система позволяет лидерам отдавать приоритет сообщениям транзакций, которые проксируются через других валидаторов со стейком. Валидаторы с более высоким стейком получают пропорционально большую пропускную способность для передачи пакетов сообщений транзакций лидеру. Такой подход эффективно снижает риск атак Сивиллы со стороны нод без стейка по всей сети.

‍В рамках этой модели валидаторы также могут заключать соглашения о предоставлении RPC-нодам своей взвешенной по стейку пропускной способности. Взамен RPC-ноды получают более широкую полосу пропускания, что повышает вероятность включения их транзакций в блоки. При этом 80% пропускной способности лидера, или 2 000 подключений, зарезервировано для SWQoS. Оставшиеся 20%, или 500 подключений, выделяются для сообщений транзакций от нод без стейка. Такая стратегия распределения похожа на платные скоростные полосы на автомагистралях, где водители платят за возможность избежать пробок.

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

Примечание о QUIC

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

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

Создание блоков

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

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

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

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

‍Этап Banking

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

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

Транзакции параллельно обрабатывают шесть потоков: четыре предназначены для обычных транзакций, а два — исключительно для транзакций голосования, которые составляют неотъемлемую часть механизма консенсуса Solana. Вся параллельная обработка выполняется несколькими ядрами CPU; валидаторам не требуются GPU (документация).‍

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

Клиенты

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

Изначально Solana запустилась с единственным клиентом валидатора — клиентом Solana Labs, который теперь известен как клиент Agave и написан на Rust. С тех пор разнообразие клиентов остаётся приоритетом, а запуск клиента Firedancer позволит в полной мере реализовать эту цель. Firedancer — это полностью переписанный с нуля на языке C первоначальный клиент. Его разработала опытная команда высокочастотной трейдинговой компании Jump. Ожидается, что он станет самым производительным клиентом валидатора среди всех блокчейнов.

Proof of History

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

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

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

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

Модель аккаунтов

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

Со временем число аккаунтов Solana выросло до сотен миллионов. Отчасти это связано с популярным среди разработчиков Solana выражением: «В Solana всё является аккаунтом!»

Аккаунты Solana

Аккаунт — это контейнер для постоянного хранения данных, похожий на файл на компьютере. Аккаунты бывают нескольких типов:

• Пользовательские аккаунты: у таких аккаунтов есть закрытый ключ. Обычно программное обеспечение кошелька создает их для пользователя.
• Аккаунты данных: в них хранится информация о состоянии, например количество определенных токенов у пользователя.
• Аккаунты программ: это более крупные аккаунты с исполняемым байт-кодом, приблизительно эквивалентные файлу .exe в Windows или .app в Mac.
• Аккаунты нативных программ: это специальные предварительно развернутые аккаунты программ, которые реализуют различные основные функции сети. Среди примеров — Vote Program и BPF Loader.

Все аккаунты содержат следующие поля:

Программы‍

Аккаунты программ Solana содержат только исполняемую логику. При запуске программа изменяет состояние других аккаунтов, но сама остается неизменной. Такое разделение кода и состояния отличает Solana от других блокчейнов и лежит в основе многих оптимизаций. Разработчики в основном пишут эти программы на Rust — универсальном языке программирования с особым вниманием к безопасности и производительности. Кроме того, несколько SDK на TypeScript и Python упрощают создание пользовательских интерфейсов приложений и программное взаимодействие с сетью.

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

Рента

Рента — это механизм, который стимулирует пользователей закрывать аккаунты и сокращать разрастание состояния. Чтобы создать новый аккаунт, на нем необходимо держать минимальный баланс SOL, называемый суммой «освобождения от ренты». Его можно считать платой за хранение, необходимой для поддержания аккаунта в памяти валидатора. Если объем данных аккаунта увеличивается, требование к минимальному балансу ренты растет пропорционально. Когда аккаунт больше не нужен, его можно закрыть, а рента возвращается владельцу. 

Например, если пользователь владеет стейблкоином, номинированным в долларах, это состояние хранится в токен-аккаунте. Сейчас сумма освобождения от ренты для токен-аккаунта составляет 0,002 SOL. Если пользователь переведет весь баланс стейблкоина другу, токен-аккаунт можно закрыть и вернуть пользователю 0,002 SOL. Программы часто автоматически закрывают аккаунты за пользователей. Несколько приложений помогают удалить старые неиспользуемые аккаунты и вернуть небольшие суммы SOL, которые в них хранятся.

Владение

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

Хранение состояния

Программы Solana представляют собой исполняемые файлы только для чтения, поэтому они должны хранить состояние с помощью «адресов, производных от программы» (Program Derived Addresses, PDA). PDA — это особые типы аккаунтов, связанные с программой и принадлежащие ей, а не конкретному пользователю. Обычные пользовательские адреса Solana выводятся из открытого ключа пары ключей Ed25519, но у PDA нет закрытого ключа. Вместо этого их открытый ключ выводится из сочетания параметров — часто ключевых слов или адресов других аккаунтов — и ID (адреса) программы-владельца.

Адреса PDA находятся «вне кривой», то есть, в отличие от обычных адресов, не принадлежат кривой Ed25519. Только программа-владелец PDA может программно создавать для него подписи. Это гарантирует, что лишь она может изменять состояние PDA.

Turbine

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

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

‍Для этого Turbine разбивает данные транзакций на «шреды» в ходе процесса, называемого «шреддингом». Шреды — небольшие пакеты данных размером до 1280 байт, похожие на отдельные кадры видеопотока. Собрав шреды обратно, валидаторы могут воспроизвести весь блок. Шреды передаются между валидаторами через интернет по UDP и используют коды стирания для обработки потери или злонамеренного отбрасывания пакетов. Кодирование стирания — основанная на многочленах схема обнаружения и исправления ошибок — обеспечивает целостность данных. Даже если часть шредов потеряна, блок все равно можно восстановить.

Шреды объединяются в группы прямой коррекции ошибок (FEC). По умолчанию каждая группа состоит из 64 шредов: 32 шредов данных и 32 шредов восстановления. Данные восстанавливаются отдельно для каждой группы FEC. Поэтому даже при потере или повреждении до половины пакетов группы все данные можно восстановить. Для каждой группы из 64 шредов строится дерево Меркла, корень которого подписывает лидер и связывает с предыдущей группой. Благодаря цепочке корней Меркла шреды можно безопасно получать с любой ноды сети, которая ими располагает: существует проверяемый путь подтверждения подлинности и целостности.

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

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

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

Консенсус

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

‍Этот процесс выполняет модуль проверки транзакций (Transaction Validation Unit, TVU), аналогичный модулю обработки транзакций лидера (Transaction Processing Unit, TPU). Он содержит основную логику обработки шредов и проверки блоков. Как и в TPU, поток TVU разделен на несколько этапов. Сначала на этапе получения шредов (Shred Fetch Stage) шреды поступают через Turbine. Затем на этапе проверки подписи лидера (Shred Verify Leader Signature Stage) выполняется несколько базовых проверок шредов. Главная из них — проверка подписи лидера, подтверждающая, что полученные шреды действительно исходят от него. ‍

На этапе ретрансляции (Retransmit Stage) валидатор пересылает шреды соответствующим нижестоящим валидаторам с учетом своего положения в дереве Turbine. На этапе воспроизведения (Replay Stage) валидатор точно воссоздает каждую транзакцию в правильном порядке и одновременно обновляет локальную версию банка.

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

Консенсус

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

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

Голосование

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

Форки

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

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

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

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

Запомните:

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

• Обработана: транзакция включена в блок.
• Подтверждена: за блок транзакции проголосовало квалифицированное большинство в две трети.
• Финализирована: поверх блока транзакции создано более 31 блока.

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

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

Gossip и архив

Gossip

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

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

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

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

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

1. Push: наиболее распространенные сообщения, которые передают информацию подмножеству «push-пиров».
2. Pull и Pull Response: периодически проверяют наличие пропущенных сообщений, а ответы pull возвращают информацию, которой нет у нод.
3. Prune: позволяют нодам избирательно сокращать число поддерживаемых соединений.
4. Ping и Pong: проверяют работоспособность нод. После отправки ping ожидается pong, подтверждающий, что пир по-прежнему активен.

Данные gossip хранятся в реплицированном хранилище данных кластера (Cluster Replicated Data Store, CrdsTable). Эта структура данных может сильно разрастаться, поэтому ее необходимо периодически очищать.

Архив

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

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

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

Экономика и Jito

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

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

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

‍Отправляя голос, валидатор получает кредит, если голос правильный и успешный. Транзакции голосования стоят 0,000005 SOL и освобождены от приоритетных комиссий. Расходы на голосование составляют примерно 1 SOL в день на валидатор, поэтому это основные операционные затраты на его работу. В течение эпохи валидаторы накапливают кредиты за голосование, которые в конце эпохи могут обменять на долю инфляционной эмиссии.

Самые эффективные валидаторы успешно голосуют примерно в 90% слотов. Учтите, что доля слотов без блоков, или доля пропущенных слотов, составляет от 2% до более 10%, и за эти слоты голосовать нельзя. Средний валидатор успешно голосует примерно в 80% слотов и получает 345 600 кредитов за эпоху из 432 000 слотов.

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

Поэтому валидатор с 1% общего стейка и средним числом кредитов должен получить примерно 1% всей инфляционной эмиссии. Если число его кредитов выше или ниже среднего, вознаграждение соответственно меняется.‍

Различия в эффективности голосования — одна из причин, по которым доходность валидаторов для стейкеров, измеряемая в APY, различается. Другой фактор — комиссия валидатора: процент от общего инфляционного вознаграждения, направленного этому валидатору. Кроме того, на доходность существенно влияет отсутствие валидатора в сети или его рассинхронизация с блокчейном, известная как состояние delinquent.

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

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

Ликвидный стейкинг

Ликвидный стейкинг стал популярной альтернативой нативному стейкингу. За размещение SOL в стейкинге участники получают токен, известный как токен ликвидного стейкинга (Liquid Staking Token, LST) или дериватив ликвидного стейкинга (Liquid Staking Derivative, LSD). Обычно SOL размещаются в пуле, который делегирует токены нескольким валидаторам. Полученные LST представляют долю пользователя в SOL, размещенных в стейкинге. Эти токены можно продавать, использовать в приложениях или передавать другим, продолжая получать вознаграждения за стейкинг. Главное преимущество такой системы — значительное повышение эффективности капитала.

Price of LST = (total staked SOL in pool * price of SOL) / total LST minted

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

Jito

На момент написания более 80% стейка Solana (источник) использует клиентское ПО валидатора Jito. Этот клиент, форк исходного клиента Agave, добавляет внепротокольный аукцион пространства блоков, который дает валидаторам дополнительные экономические стимулы за счет чаевых. Этот стимул — важный фактор широкого распространения клиента Jito среди валидаторов.

Когда лидеры используют клиент валидатора Jito, их транзакции сначала направляются в Jito-Relayer. Это ПО с открытым исходным кодом работает как прокси-маршрутизатор транзакций. Другие ноды сети не знают о существовании Jito-Relayer. Они просто отправляют транзакции на адрес и порт, которые лидер объявил через сеть gossip в качестве своего ingress_socket, считая их адресом и портом лидера.

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

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