> ## Documentation Index > Fetch the complete documentation index at: https://www.helius.dev/docs/llms.txt > Use this file to discover all available pages before exploring further. # Глоссарий Helius: определения терминов Solana и Helius > Определения для разработчиков терминов, используемых в документации Helius и экосистеме Solana: DAS, LaserStream, предварительные подтверждения, приоритетные комиссии, PDA и многое другое. Краткие определения терминов, используемых в документации Helius и в Solana. Каждая статья содержит ссылку на соответствующую страницу продукта или руководство, если применимо. Перейти к разделу: * [Продукты и платформа Helius](#продукты-и-платформа-helius) * [Основы Solana](#основы-solana) * [Механика транзакций](#механика-транзакций) * [Токены и активы](#токены-и-активы) * [Подключение и потоковая передача](#подключение-и-потоковая-передача) * [Экосистема](#экосистема) *** ## Продукты и платформа Helius ### Автомасштабирование Механизм Helius для автоматического пополнения кредитов в тарифах с оплатой фиатной валютой. Когда месячный лимит кредитов исчерпан, автомасштабирование покупает дополнительные кредиты в пределах установленного пользователем максимума, чтобы ошибки `429` не прерывали рабочий трафик. В криптовалютных тарифах автомасштабирование недоступно. Вместо него используются [предоплаченные кредиты](/docs/ru/billing/additional-credits#предоплаченные-кредиты-тарифы-с-оплатой-криптовалютой), которые приобретаются вручную. См. [Автомасштабирование](/docs/ru/billing/additional-credits). ### Кредит Единица, в которой Helius учитывает использование API и потоковой передачи. Для методов RPC, вызовов DAS и пропускной способности потоков установлена определенная стоимость в кредитах. Каждый тариф включает месячный лимит кредитов, который сбрасывается в каждом платежном цикле. Неиспользованные кредиты не переносятся. Полную таблицу стоимости см. в разделе [Кредиты](/docs/ru/billing/credits). ### DAS API Digital Asset Standard — открытая спецификация унифицированного интерфейса для цифровых активов Solana: NFT, сжатых NFT и взаимозаменяемых токенов. Реализация DAS API от Helius возвращает расширенные метаданные, сведения о владении и цены в одном структурированном ответе, избавляя от необходимости создавать собственные парсеры ончейн-данных об активах. См. [DAS API](/docs/ru/das-api). ### Выделенные узлы Частные RPC-узлы Helius без ограничений частоты запросов и учета кредитов, оплачиваемые по фиксированной месячной ставке. Они подходят для узкоспециализированных сценариев, где требуется неограниченная пропускная способность. Для большинства приложений лучше подходит обычный RPC Helius благодаря более высокой производительности, отказоустойчивости и функциональности. См. [Выделенные узлы](/docs/ru/dedicated-nodes). ### Расширенные транзакции API Helius для разбора транзакций, который декодирует необработанные транзакции Solana в понятные человеку события: переводы токенов, продажи NFT, обмены, операции стейкинга и многое другое. При этом не требуются отдельные парсеры инструкций для каждой программы. См. [Расширенные транзакции](/docs/ru/enhanced-transactions/overview). ### Коды ошибок Стандартные коды состояния HTTP, возвращаемые API Helius, с учетом специфики Helius: * `400 Bad Request` — недопустимые параметры или некорректный запрос (например, неверный формат адреса, отсутствие обязательных полей или некорректный JSON) * `401 Unauthorized` — отсутствующий или недействительный ключ API * `403 Forbidden` — доступ запрещен, как правило, из-за ограничений по IP, отсутствия конечной точки в подписке или недостаточных разрешений ключа API * `404 Not Found` — нет данных для запрошенного ресурса (это нормально при поиске идентификационных данных неизвестных кошельков) * `429 Too Many Requests` — исчерпан лимит кредитов, превышено ограничение частоты запросов или достигнут лимит одновременных запросов * `5xx` — проблемы на стороне Helius; повторите запрос с экспоненциальной задержкой Полные сведения и инструкции по устранению неполадок см. в разделе [Коды ошибок](/docs/ru/faqs/error-codes). ### Gatekeeper Пограничный шлюз Helius, который обеспечивает значительно меньшую задержку по сравнению со стандартными вызовами RPC, направляя запросы через глобально распределенный парк прокси-серверов. Чтобы использовать его, замените `mainnet.helius-rpc.com` на `beta.helius-rpc.com` в URL RPC. Архитектура описана в разделе [Gatekeeper](/docs/ru/gatekeeper/overview) и публикации [Представляем Gatekeeper](https://www.helius.dev/blog/introducing-gatekeeper). ### LaserStream Высокопроизводительный сервис потоковой передачи gRPC от Helius для ончейн-данных Solana с историческим воспроизведением, переключением между регионами при сбоях и самым широким набором возможностей среди продуктов Helius для потоковой передачи. Официальные SDK доступны для JavaScript/TypeScript, Rust и Go. [LaserStream WebSocket](#laserstream-websocket) работает в той же инфраструктуре. Подробный обзор показателей производительности SDK см. в разделе [LaserStream](/docs/ru/laserstream) и публикации [Производительность SDK LaserStream](https://www.helius.dev/blog/laserstream-sdks). ### LaserStream WebSocket Сервис Helius для постоянной потоковой передачи через WebSocket. Он предоставляет как стандартные методы WebSocket Solana, так и расширения Helius (`transactionSubscribe` и улучшенный `accountSubscribe` с более широкими возможностями фильтрации) через единую конечную точку. LaserStream WebSocket использует тот же серверный компонент, что и gRPC-сервис [LaserStream](#laserstream). См. [LaserStream WebSocket](/docs/ru/rpc/websocket). ### Preconfirmations Сигнал транзакции Helius с минимальной задержкой. Он передает транзакции до того, как они будут собраны в записи и разделены на шреды: предварительные подтверждения Helius поступают в момент выполнения транзакции лидером вместе с ее статусом выполнения, а предварительные подтверждения BAM — когда валидатор обязуется выполнить транзакцию, до ее фактического выполнения. Они поступают раньше, чем [Shred Delivery](#shred-delivery), и раньше потоков с уровнем подтверждения processed. Доставляются через подписку WebSocket `preconfSubscribe`. Требуется тариф Professional или выше. Тарификация составляет 10 кредитов за сообщение при минимуме 300 кредитов за каждый охваченный слот для каждой подписки. Охват зависит от того, какие валидаторы передают свой поток в Helius, поэтому поток данных не является непрерывным. См. [Preconfirmations](/docs/ru/pre-confirmations/overview) и [`preconfSubscribe`](/docs/ru/pre-confirmations/preconf-subscribe). ### API приоритетных комиссий Конечная точка Helius для оценки комиссий, которая возвращает рекомендуемые значения приоритетной комиссии на основе текущей ситуации на ончейн-рынках комиссий. Она позволяет устанавливать конкурентоспособную комиссию без догадок и переплаты в периоды перегрузки. См. [API приоритетных комиссий](/docs/ru/priority-fee-api). ### Ограничение частоты запросов Максимальное число запросов в секунду, разрешенное для конкретного тарифа Helius. Ограничения частоты запросов зависят от уровня тарифа и семейства API: стандартного RPC, расширенных API или потоковой передачи. При превышении возвращается `429 Too Many Requests`. См. [Ограничения частоты запросов](/docs/ru/billing/rate-limits). ### Sender Специализированный сервис Helius для включения транзакций в блок, созданный для трейдеров, которым важна низкая задержка. Он объединяет приоритетные комиссии, чаевые Jito и маршрутизацию через стейкинговые подключения, чтобы максимально повысить долю успешно включенных транзакций. Доступен по адресу `https://sender.helius-rpc.com/fast`. См. [Sender](/docs/ru/sending-transactions/sender). ### Shred Delivery Сервис Helius для потоковой передачи необработанных шредов Solana по UDP до окончательной сборки блока. Helius агрегирует шреды из распределенной по регионам сети валидаторов, чтобы минимизировать влияние географического положения отдельного валидатора на задержку. Подходит для высокочастотной торговли, арбитража и других приложений, требующих низкой задержки. Необработанные шреды можно самостоятельно подключить на [панели Helius](https://dashboard.helius.dev/shred-delivery-seats) — \$1 000 USD в месяц за IP-адрес (\$800 USD в месяц за IP-адрес на тарифах Pro). См. [Shred Delivery](/docs/ru/shred-delivery) и публикацию [Как выиграть миллисекунды: шреды, LaserStream и преимущество Solana](https://www.helius.dev/blog/solana-shreds) с подробным описанием работы шредов. ### Стейкинговые подключения Стандартный способ отправки транзакций для платных тарифов Helius. Стейкинговые подключения направляют транзакции будущим лидерам блоков с помощью механизма Solana Stake-Weighted Quality of Service (SWQoS) на уровне протокола. Он предоставляет приоритетные слоты подключений в зависимости от стейка валидатора и сокращает потерю пакетов при перегрузке. Пользователи платных тарифов Helius получают это преимущество без необходимости самостоятельно управлять валидатором с крупным стейком. См. [Оптимизация транзакций](/docs/ru/sending-transactions/optimizing-transactions) и публикацию [Stake-Weighted Quality of Service: все, что нужно знать](https://www.helius.dev/blog/stake-weighted-quality-of-service-everything-you-need-to-know). ### API кошельков REST API Helius для получения балансов, истории транзакций, переводов, идентификационных данных и источника финансирования кошелька Solana. Он возвращает структурированные ответы с ценами в USD вместо необработанного вывода RPC. Помимо адресов, API принимает доменные имена SNS `.sol` и ANS. См. [API кошельков](/docs/ru/wallet-api/overview). *** ## Основы Solana ### Аккаунт Контейнер для постоянного хранения данных в Solana, идентифицируемый 32-байтовым открытым ключом. Все ончейн-состояние — балансы пользователей, код программ, метаданные токенов — хранится в аккаунтах, включая сами программы. У каждого аккаунта есть владелец — программа, которой разрешено изменять его данные или выводить лампорты. Для постоянного существования аккаунт должен поддерживать минимальный баланс SOL, освобождающий его от арендной платы. Подробности см. в публикации [Модель программирования Solana: введение в разработку на Solana](https://www.helius.dev/blog/the-solana-programming-model-an-introduction-to-developing-on-solana). ### Agave Текущий канонический клиент валидатора Solana, поддерживаемый Anza и являющийся переименованным преемником исходного клиента Solana Labs. Ссылки на конкретные выпуски Agave, например минимальный порог стейка [SWQoS](#stake-weighted-quality-of-service-swqos) в v1.17.31, обычно привязывают поведение к определенной версии клиента. [Jito-Solana](#jito) — форк Agave с интегрированным движком блоков, а [Firedancer](#firedancer) — независимая альтернатива на языке C, разработанная Jump Crypto. Описание модели SVM, реализуемой Agave, см. в публикации [Виртуальная машина Solana](https://www.helius.dev/blog/solana-virtual-machine). ### Аирдроп Начисление SOL или токенов SPL на адрес. В Devnet и Testnet аирдропом обычно называют небольшое количество тестовых SOL из крана для финансирования кошельков разработчиков. В Mainnet это массовое распределение токенов среди существующих держателей. Аирдропы Devnet доступны через [кран Devnet](/docs/ru/rpc/devnet-sol). ### Ассоциированный аккаунт токена (ATA) Детерминированно производный аккаунт токена, который хранит определенный токен SPL для заданного адреса кошелька. У каждого кошелька может быть не более одного ATA для каждого выпуска токена, поэтому ATA служит стандартным источником данных о балансе токена пользователя. Он выводится с использованием адреса кошелька и выпуска токена в качестве начальных значений. ### Блок Структура данных, содержащая набор транзакций и важные метаданные, включая хеш блока и хеш предыдущего блока, которые образуют неизменяемую цепочку. Блоки создаются во время слотов: назначенный [лидер](#лидер--расписание-лидеров) [слота](#слот) проверяет входящие транзакции, упаковывает их в блок и распространяет блок по сети через [Turbine](#turbine). Блок создается не в каждом слоте. Если лидер не успевает создать его вовремя, слот пропускается и сеть продолжает работу. Когда блок получает голоса [валидаторов](#валидатор), представляющих квалифицированное большинство стейка, он считается подтвержденным. См. [Уровень подтверждения](#уровень-подтверждения). Подробности см. в публикации [Слоты, блоки и эпохи в Solana](https://www.helius.dev/blog/solana-slots-blocks-and-epochs). ### Уровень подтверждения Степень уверенности в том, что транзакция включена в блокчейн: * `processed` — транзакция получена текущим лидером, но голосование по ней еще не состоялось; она все еще может быть отброшена, если блок не достигнет консенсуса (\~0,4 с) * `confirmed` — за блок отдано ≥66% голосов валидаторов с учетом веса стейка; исторически ни один подтвержденный блок не был отменен (\~0,6 с) * `finalized` — блок получил ≥66% голосов, и поверх него создан еще 31 блок, то есть достигнута максимальная блокировка Tower BFT, что делает его фактически необратимым (\~13 с) Рекомендуемое значение по умолчанию — `confirmed`. Используйте `processed` для обратной связи в пользовательском интерфейсе, а `finalized` — для операций с высокой стоимостью, таких как депозиты на биржи или межсетевые мосты. Хеши блоков, полученные на уровне `finalized`, истекают раньше, чем полученные на уровне `confirmed`, что сокращает время до истечения срока действия транзакции. Подробности см. в публикации [Что такое уровни подтверждения Solana?](https://www.helius.dev/blog/solana-commitment-levels). ### Вычислительные единицы (CU) Мера вычислительной работы, выполняемой транзакцией в Solana, аналогичная газу в Ethereum. Каждая транзакция указывает лимит вычислительных единиц и цену вычислительной единицы — приоритетную комиссию в микролампортах за CU. Их произведение определяет общую приоритетную комиссию. При превышении лимита транзакция завершается с ошибкой. ### CPI (межпрограммный вызов) Механизм Solana, позволяющий одной ончейн-[программе](#программа) вызывать другую, передавая аккаунты и данные инструкций. Это базовый механизм, обеспечивающий компонуемость Solana. CPI доступны через системный вызов `sol_invoke_signed`, который проверяет наличие у вызывающей стороны необходимых разрешений для передаваемых аккаунтов. [PDA](#адрес-производный-от-программы-pda) позволяют программам подписывать данные от имени принадлежащих им аккаунтов. Вызванная программа работает в пределах оставшегося [вычислительного бюджета](#вычислительные-единицы-cu) вызывающей программы. Если она исчерпывает бюджет или превышает установленный лимит, вся цепочка вызовов, включая исходную транзакцию, завершается с ошибкой. Подробности см. в публикации [Виртуальная машина Solana](https://www.helius.dev/blog/solana-virtual-machine). ### Эпоха Группа приблизительно из 432 000 слотов Solana — организационный интервал верхнего уровня, на котором Solana обновляет набор валидаторов, расписание лидеров, делегирование стейка и распределение вознаграждений. При текущем целевом времени слота каждая эпоха длится около двух дней. Подробности см. в публикации [Слоты, блоки и эпохи в Solana](https://www.helius.dev/blog/solana-slots-blocks-and-epochs). ### Firedancer Второй независимый клиент [валидатора](#валидатор) Solana, написанный Jump Crypto с нуля на языке C. Заявленные цели Firedancer: (1) документирование и стандартизация протокола Solana с помощью независимой реализации, (2) повышение разнообразия клиентов, чтобы ни один клиент не контролировал более 33% стейка, и (3) повышение производительности экосистемы. Архитектура модульная: множество однозадачных процессов Linux, называемых «плитками» (плитка QUIC, плитка проверки и т. д.), взаимодействуют через общую память. Это отличается от однопроцессной архитектуры [Agave](#agave). Frankendancer — их промежуточная гибридная система, сочетающая высокопроизводительный сетевой код Firedancer на C со средой выполнения и кодом консенсуса Agave на Rust. Подробности см. в публикации [Что такое Firedancer?](https://www.helius.dev/blog/what-is-firedancer). ### Инструкция Наименьшая единица работы в транзакции Solana: отдельный вызов программы с соответствующими аккаунтами и данными. Транзакция объединяет одну или несколько инструкций, которые выполняются атомарно: либо все завершаются успешно, либо все вместе отменяются. Подробности см. в публикации [Модель программирования Solana: введение в разработку на Solana](https://www.helius.dev/blog/the-solana-programming-model-an-introduction-to-developing-on-solana). ### Лампорт Минимальная единица SOL: 1 SOL = 1 000 000 000 лампортов (10⁻⁹ SOL). Она названа в честь Лесли Лэмпорта, лауреата премии Тьюринга за основополагающие работы в области распределенных систем. Необработанные методы RPC Solana возвращают балансы и комиссии в лампортах. [API кошельков](/docs/ru/wallet-api/overview) Helius выполняет преобразование автоматически. Приоритетные комиссии указываются в микролампортах — миллионных долях лампорта (10⁻¹⁵ SOL). ### Лидер / расписание лидеров Лидер — это [валидатор](#валидатор), назначенный для предложения нового [блока](#блок) в течение определенного [слота](#слот). Лидеры выбираются в соответствии со случайным расписанием с учетом веса стейка, которое рассчитывается в начале каждой [эпохи](#эпоха). Поэтому любой валидатор может самостоятельно определить, кто будет лидером каждого слота в предстоящем периоде длительностью около 2–3 дней. Каждому лидеру назначаются четыре последовательных слота — около 1,6 секунды при длительности слота примерно 400 мс, — что дает ему короткий период для последовательного создания блоков. Если лидер не создает блок в своем слоте, слот пропускается: сеть продолжает работу, не ожидая отсутствующий блок. Сервисы отправки транзакций, такие как [Sender](#sender), направляют подписанные транзакции текущему и двум следующим лидерам, чтобы максимально повысить вероятность включения. Подробности см. в публикации [Консенсус в Solana: Tower BFT и Proof of History](https://www.helius.dev/blog/consensus-on-solana). ### Дерево Меркла Криптографическая древовидная структура, в которой каждый нелистовой узел представляет собой хеш дочерних узлов, поэтому единственный корневой хеш фиксирует весь набор данных. Чтобы проверить принадлежность элемента данных дереву, нужны только хеши соседних узлов на пути от листа к корню — доказательство Меркла. Объем этих данных составляет O(log n) независимо от размера дерева. Для дерева глубиной 26 такое доказательство содержит 26 соседних хешей (около 832 байт). Это небольшой объем, но он по-прежнему требуется для каждого листа. Доказательства такой формы используются [сжатыми NFT](#сжатый-nft-cnft). [ZK Compression](#zk-compression) заменяет их одним [доказательством действительности](#доказательство-действительности) постоянного размера, которое не увеличивается вместе с набором данных. См. публикацию [Основы криптографических инструментов: хеш-функции и деревья Меркла](https://www.helius.dev/blog/cryptographic-tools-101-hash-functions-and-merkle-trees-explained). ### Программа Исполняемый аккаунт, содержащий скомпилированный байт-код sBPF, то есть смарт-контракт Solana. Программы не имеют собственного состояния: они читают и записывают принадлежащие им аккаунты данных и идентифицируются идентификатором программы — своим 32-байтовым адресом. Solana включает набор нативных программ (System, Stake, Vote и т. д.), встроенных в среду выполнения. Все остальные программы развертываются пользователями. Подробности см. в публикации [Модель программирования Solana: введение в разработку на Solana](https://www.helius.dev/blog/the-solana-programming-model-an-introduction-to-developing-on-solana). ### Адрес, производный от программы (PDA) Детерминированный адрес, производный от идентификатора программы и набора начальных значений. PDA позволяют программам подписывать данные от имени контролируемых ими аккаунтов, поэтому они необходимы для проектирования программ с состоянием. PDA намеренно не принадлежат эллиптической кривой, поэтому закрытых ключей для них не существует. ### Proof of History (PoH) Примитив синхронизации Solana, а не алгоритм консенсуса. PoH предоставляет криптографическую функцию временных меток, которая позволяет валидаторам согласовать порядок событий без обмена данными друг с другом. Реализация представляет собой последовательную цепочку хешей SHA-256, непрерывно выполняемую на одном ядре CPU каждого валидатора. Результат каждой итерации используется как входные данные следующей. Генерация выполняется последовательно в одном потоке, а проверка допускает распараллеливание. PoH предоставляет «тики», определяющие действительность [блока](#блок). Лидеры должны публиковать блоки в заданном диапазоне тиков PoH. Блок за пределами диапазона считается пропущенным. PoH работает вместе с [Tower BFT](#tower-bft), который является фактическим механизмом консенсуса. Подробности см. в публикации [Proof of History, Proof of Stake и Proof of Work](https://www.helius.dev/blog/proof-of-history-proof-of-stake-proof-of-work-explained). ### Аренда / освобождение от аренды Баланс SOL, который должен храниться в каждом аккаунте Solana для его существования в блокчейне и который зависит от объема хранилища аккаунта. Аккаунты должны создаваться освобожденными от арендной платы: транзакции, после которых баланс аккаунта оказался бы ниже минимального, завершаются с ошибкой. Получив освобождение от аренды, аккаунт сохраняется неограниченно долго без дополнительных платежей. ### Sealevel Движок параллельного выполнения транзакций Solana. В отличие от последовательных виртуальных машин, таких как EVM, Sealevel одновременно выполняет несколько транзакций на разных ядрах CPU. Это возможно потому, что каждая транзакция Solana до начала выполнения явно объявляет, какие [аккаунты](#аккаунт) она будет читать и изменять. Поэтому планировщик может определять неконфликтующие группы без анализа во время выполнения. Правила планирования просты: транзакции, обращающиеся к разным аккаунтам, выполняются параллельно; транзакции, которые только читают одни и те же аккаунты, также выполняются параллельно, поскольку чтение не создает конфликтов; транзакции, записывающие данные в одни и те же аккаунты, выполняются последовательно для предотвращения состояний гонки. Подробности см. в публикации [Виртуальная машина Solana](https://www.helius.dev/blog/solana-virtual-machine). ### Слот Основная единица времени Solana, в течение которой назначенный валидатор-лидер может создать блок. Текущая целевая длительность слота составляет 400 мс, хотя фактическая длительность может зависеть от состояния сети. Если лидер не создает блок в течение своего слота, слот пропускается: сеть переходит к следующему слоту, а не ожидает. Поэтому блок создается не в каждом слоте. Подробности см. в публикации [Слоты, блоки и эпохи в Solana](https://www.helius.dev/blog/solana-slots-blocks-and-epochs). ### SVM (виртуальная машина Solana) Полный стек выполнения транзакций Solana, а не узкоспециализированный интерпретатор байт-кода. SVM включает компонент Bank, который координирует выполнение, планировщик Banking Stage, загрузчики BPF и саму виртуальную машину sBPF — регистровую VM с 11 регистрами общего назначения и примерно 100 кодами операций, использующую JIT-компиляцию для повышения производительности. Этим SVM отличается от EVM, под которой однозначно понимается единый исполнитель байт-кода. Программы Solana компилируются в sBPF — форк Linux eBPF от Solana. Для sBPF можно использовать любой язык с интерфейсом LLVM: C, C++, Rust или Zig. Обязательное предварительное объявление доступа транзакций к аккаунтам обеспечивает параллельное выполнение [Sealevel](#sealevel) и локализованные рынки комиссий Solana. Подробности см. в публикации [Виртуальная машина Solana](https://www.helius.dev/blog/solana-virtual-machine). ### Tower BFT Механизм консенсуса Solana. Tower BFT — алгоритм, похожий на pBFT и использующий синхронизированные часы [Proof of History](#proof-of-history-poh), что устраняет необходимость в синхронном раунде консенсуса для каждого слота. Валидаторы строят «башню голосов» — последовательный стек голосов, в котором каждый новый голос удваивает период блокировки всех предыдущих голосов, экспоненциально увеличивая потенциальную потерю стейка при переходе на другую ветвь. Пороги подтверждения: блок считается **подтвержденным**, когда за него отдано ≥2/3 голосов с учетом веса стейка. Для нарушения окончательности пришлось бы изъять не менее 4,6% общего стейка. Блок считается **окончательным**, когда он получил голоса и поверх него создан еще 31 блок, что соответствует максимальной блокировке Tower BFT. Рекомендации по использованию см. в разделе [Уровень подтверждения](#уровень-подтверждения). Подробности см. в публикации [Консенсус в Solana: Tower BFT и Proof of History](https://www.helius.dev/blog/consensus-on-solana). ### Turbine Протокол распространения блоков Solana. Лидер разделяет каждый блок на [шреды](#шред) размером MTU и восстановительные шреды с кодированием стираний Рида — Соломона. Коэффициент FEC, обычно 32:32, позволяет сети восстановить блок даже при потере около 33% пакетов. Затем лидер передает шреды по детерминированному дереву одноранговых валидаторов, взвешенному по стейку и инициализируемому для каждой группы шредов значением `(leader id, slot, shred index, shred type)`, вместо прямой рассылки полного блока каждому валидатору. Дерево (`DATA_PLANE_FANOUT = 200`) сохраняет исходящую пропускную способность лидера примерно постоянной независимо от числа валидаторов и позволяет блокам достигать сети за 2–3 перехода вместо O(n). См. публикацию [Turbine: распространение блоков в Solana](https://www.helius.dev/blog/turbine-block-propagation-on-solana). ### Валидатор Узел сети Solana, участвующий в консенсусе путем создания блоков в назначенные ему лидерские слоты и голосования за блоки других валидаторов. Валидаторы выбираются для лидерских слотов пропорционально своему активному стейку. *** ## Механика транзакций ### Таблица поиска адресов (ALT) Ончейн-таблица адресов Solana, на которые версионированная транзакция может ссылаться с помощью однобайтового индекса вместо полного 32-байтового открытого ключа. Благодаря этому одна транзакция может ссылаться на 256 аккаунтов. ALT необходимы для сложных операций DeFi, которые иначе превысили бы ограничения размера транзакции. ### Хеш блока 32-байтовый хеш, идентифицирующий недавний блок и включаемый в каждую транзакцию Solana для подтверждения ее актуальности. Срок действия хешей блоков истекает примерно через 150 слотов, или около минуты. Транзакции с истекшими хешами блоков отклоняются. Клиенты получают недавний хеш блока через [`getLatestBlockhash`](/docs/ru/api-reference/rpc/http/getlatestblockhash) непосредственно перед подписанием. ### Приоритетная комиссия Доплата за каждую вычислительную единицу, выплачиваемая валидаторам, чтобы транзакция получила приоритет перед другими и была быстрее включена. Приоритетные комиссии задаются в микролампортах на вычислительную единицу (µLamports/CU). [API приоритетных комиссий](/docs/ru/priority-fee-api) Helius возвращает актуальные оценки на основе недавней ситуации на ончейн-рынках комиссий. ### Шред Наименьшая единица блока Solana. Блоки разделяются на шреды для параллельного распространения по сети валидаторов через [Turbine](https://www.helius.dev/blog/turbine-block-propagation-on-solana). Доступ на уровне шредов предоставляет трейдерам ончейн-сигналы со сверхнизкой задержкой еще до сборки блока. Однако [Preconfirmations](#preconfirmations) поступают еще раньше — до разделения записей на шреды. См. [Необработанные шреды (UDP)](/docs/ru/shred-delivery/raw-shreds) и [обзор Shred Delivery](/docs/ru/shred-delivery). ### Stake-Weighted Quality of Service (SWQoS) Механизм уровня протокола Solana, который определяет приоритет входящих транзакций для текущего и будущих лидеров на основе стейка отправителя. SWQoS был внедрен после сбоя Solana 30 апреля 2022 года в качестве меры защиты от атак Сивиллы. Он не позволяет одноранговым узлам с небольшим или нулевым стейком монополизировать пропускную способность лидера во время перегрузки. Лидер предоставляет два пула входящих подключений: около 500 открытых подключений совместно используются всеми одноранговыми узлами без стейка, а около 2 000 взвешенных по стейку подключений распределяются пропорционально между валидаторами со стейком. Валидатор, владеющий X% общего активного стейка, может отправить лидеру до X% пакетов. Валидаторы с активным стейком менее примерно 15 000 SOL — около 1/25 000 общего стейка сети — считаются не имеющими стейка. Минимальный порог стейка появился в Agave v1.17.31. [Стейкинговые подключения](#стейкинговые-подключения) Helius получают это преимущество при включении транзакций, направляя клиентские транзакции через крупнейший валидатор Solana. Поэтому вызывающие стороны могут использовать SWQoS, не управляя напрямую валидатором с крупным стейком. См. публикацию [Stake-Weighted Quality of Service: все, что нужно знать](https://www.helius.dev/blog/stake-weighted-quality-of-service-everything-you-need-to-know). ### Версионированная транзакция Формат транзакции Solana, идентифицируемый байтом версии в начале сериализованной транзакции. В версии 0 (v0) появились таблицы поиска адресов, позволяющие одной транзакции ссылаться на 256 аккаунтов вместо примерно 35 в устаревших транзакциях. В версии 1 (v1, [SIMD-0385](https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0385-transaction-v1.md), Agave 4.2) подписи перемещены в конец транзакции, а вычислительный бюджет передается в поле заголовка `transactionConfig` вместо инструкций ComputeBudget. Укажите `maxSupportedTransactionVersion: 1` в запросах RPC, чтобы получать транзакции всех версий. См. [Поддержка транзакций v1](/docs/ru/rpc/transaction-v1). *** ## Токены и активы ### Сжатый аккаунт Сжатый аккаунт — это аккаунт Solana, данные которого фиксируются в реестре через журналы транзакций, а в состоянии валидатора хранится только хеш-отпечаток. Полные данные при этом не занимают традиционный слот аккаунта на дисках валидатора. Разработчики могут работать со сжатыми аккаунтами как с обычными. Индексаторы, такие как Photon, анализируют журналы транзакций для восстановления текущего состояния, а доказательство с нулевым разглашением Groth16 постоянного размера проверяет целостность при чтении или изменении аккаунтов через ZK Compression. Эта модель лучше всего подходит для аккаунтов с небольшим объемом данных: при размере более примерно 100 байт сжатие становится непрактичным. ### Сжатый NFT (cNFT) NFT Solana, представленный в виде листа параллельного ончейн-дерева Меркла, а не отдельного аккаунта. Дерево хранится в аккаунте Solana, а переходы его состояния защищены реестром. Текущее состояние NFT выводится индексаторами из истории транзакций. Индексаторы создают доказательства Меркла, которые можно проверить по ончейн-корню дерева. Поэтому для чтения cNFT требуется индексатор, например [DAS API](/docs/ru/das-api): стандартный RPC Solana не может напрямую возвращать данные cNFT. Эта модель снижает стоимость выпуска до 99% по сравнению со стандартными NFT. ### Параллельное дерево Меркла Специальный вариант [дерева Меркла](#дерево-меркла) для Solana, позволяющий нескольким записывающим сторонам обновлять дерево в одном слоте, не делая доказательства друг друга недействительными. В ончейн-аккаунте хранится не только текущий корень, но и буфер журнала изменений с недавними действительными корнями, а также крона — кэшированное подмножество верхних узлов дерева. Это позволяет валидаторам проверять доказательства, созданные для любого корня, который еще находится в окне буфера. Дерево определяется тремя параметрами: максимальной глубиной, ограничивающей число листьев значением 2^depth; размером буфера — глубиной журнала изменений, определяющей, сколько операций записи может произойти до признания более старых обрабатываемых доказательств недействительными; и глубиной кроны, которая увеличивает ончейн-аренду в обмен на уменьшение доказательств в транзакциях. Допустимые пары (глубина, буфер) находятся в диапазоне от (3, 8) до (30, 2048). Для практической компонуемости сохраняйте `maxDepth − canopyDepth ≤ 10`. Параллельные деревья Меркла реализуются программой SPL Account Compression и служат основой для [сжатых NFT](#сжатый-nft-cnft), которые выпускаются в виде листьев через Metaplex Bubblegum. См. публикацию [Все, что нужно знать о сжатии в Solana](https://www.helius.dev/blog/all-you-need-to-know-about-compression-on-solana). ### Groth16 Система доказательств zk-SNARK, создающая доказательства с нулевым разглашением постоянного размера — 128 байт на кривой BN254 при использовании сжатия точек — независимо от сложности утверждения, с проверкой за O(1). [ZK Compression](#zk-compression) использует Groth16 для создания [доказательств действительности](#доказательство-действительности), подтверждающих, что сжатый аккаунт принадлежал известному состоянию с известным корнем. Именно небольшой размер доказательства обеспечивает низкую стоимость транзакций со сжатыми аккаунтами. См. публикацию [Разработчики Solana: ZK Compression](https://www.helius.dev/blog/solana-builders-zk-compression). ### Аккаунт выпуска Ончейн-аккаунт, определяющий свойства токена SPL: объем предложения, число десятичных знаков и полномочия на выпуск или заморозку. Адрес аккаунта выпуска является каноническим идентификатором токена — аналогом «адреса контракта» в Ethereum. ### Токен SPL Токен в Solana, выпущенный через Token Program из библиотеки Solana Program Library (SPL). Взаимозаменяемые токены, такие как USDC, BONK и JUP, являются токенами SPL. Стандартные несжатые NFT также являются токенами SPL, выпущенными с предложением 1 и 0 десятичных знаков. Токены SPL приблизительно соответствуют ERC-20 и ERC-721 в Ethereum. Token-2022 — более новая программа, расширяющая этот интерфейс дополнительными функциями, такими как комиссии за переводы и конфиденциальные переводы. ### Дерево состояния Дерево Меркла, которое [ZK Compression](#zk-compression) использует для хранения хешей сжатых аккаунтов. Ончейн-аккаунт содержит только текущий корень и минимум метаданных. Фактические сжатые данные хранятся в журналах транзакций и восстанавливаются индексаторами, такими как [Photon](#photon). Программы читают или изменяют сжатое состояние, передавая [доказательство действительности](#доказательство-действительности), подтверждающее, что хеш заявленного содержимого аккаунта соответствует листу под текущим корнем. См. [ZK Compression](/docs/ru/api-reference/zk-compression). ### Аккаунт токена Ончейн-аккаунт, хранящий баланс определенного токена SPL для конкретного владельца. Кошелек может владеть произвольными аккаунтами токенов, но принято использовать ассоциированный аккаунт токена (ATA) — детерминированно производный аккаунт токена для каждой пары (кошелек, выпуск), создаваемый программой Associated Token Account. ### Token-2022 (расширения токенов) Вариант SPL Token Program, поддерживающий дополнительные расширения, например комиссии за переводы, конфиденциальные переводы, токены с начислением процентов и непередаваемые токены. Token-2022 работает как отдельная ончейн-программа с собственным идентификатором, но спроектирована как совместимый преемник классической Token Program, поэтому SDK обычно могут работать с обеими. Для использования расширений выпуски должны создаваться в программе Token-2022. См. публикацию [Что такое расширения токенов?](https://www.helius.dev/blog/what-is-token-2022). ### Доказательство действительности Доказательство с нулевым разглашением [Groth16](#groth16) постоянного размера, подтверждающее, что заявленное содержимое сжатого аккаунта существовало в [дереве состояния](#дерево-состояния) с определенным корнем. Программам [ZK Compression](#zk-compression) требуется доказательство действительности при каждом чтении или изменении сжатых аккаунтов. Оно позволяет программе проверять офчейн-состояние без хранения этих данных валидатором в блокчейне. [Photon](#photon) предоставляет вызывающим сторонам доказательства действительности через метод RPC [`getValidityProof`](/docs/ru/api-reference/zk-compression/getvalidityproof). Доказательства действительности отличают ZK Compression от [сжатых NFT](#сжатый-nft-cnft): cNFT используют обычные доказательства Меркла — список соседних хешей от листа до корня, растущий вместе с глубиной дерева, — тогда как ZK-доказательство постоянного размера в ZK Compression не раскрывает путь или состояние окружающих узлов дерева. См. публикацию [Разработчики Solana: ZK Compression](https://www.helius.dev/blog/solana-builders-zk-compression). ### ZK Compression ZK Compression — примитив Solana, разработанный Helius и Light Protocol и значительно сокращающий стоимость ончейн-хранилища за счет фиксации данных аккаунтов в журналах транзакций реестра и хранения в состоянии валидатора только хеш-отпечатка. Криптографическая целостность сохраняется с помощью доказательств с нулевым разглашением Groth16 постоянного размера, создаваемых на основе проиндексированных данных транзакций. Этот примитив отличается от сжатых NFT, использующих параллельные деревья Меркла без доказательств с нулевым разглашением. Подробности см. в разделе [ZK Compression](/docs/ru/api-reference/zk-compression) и публикации [Разработчики Solana: ZK Compression](https://www.helius.dev/blog/solana-builders-zk-compression). *** ## Подключение и потоковая передача ### Geyser Система плагинов Solana для потоковой передачи внешним потребителям в реальном времени изменений состояния валидатора: аккаунтов, транзакций, слотов и блоков. Валидаторы загружают плагины Geyser как динамические библиотеки. Плагин получает обновления состояния по мере их обработки валидатором, устраняя необходимость опрашивать RPC для обнаружения изменений. Yellowstone gRPC — основной плагин Geyser — предоставляет эти обновления через gRPC. [LaserStream](#laserstream) от Helius реализует интерфейс Yellowstone gRPC и добавляет такие функции, как историческое воспроизведение — до примерно 48 часов, или около 691 200 слотов при текущей скорости сети — и переключение между регионами при сбоях. ### gRPC gRPC — универсальный высокопроизводительный двоичный протокол RPC. Его название является рекурсивным акронимом от «gRPC Remote Procedure Call». В контексте Solana под «gRPC» обычно понимается Yellowstone gRPC — интерфейс потоковой передачи на основе системы плагинов Geyser в Solana, который предоставляет через gRPC обновления аккаунтов и транзакций. Сервис [LaserStream](/docs/ru/laserstream) от Helius построен на интерфейсе на основе Yellowstone и добавляет историческое воспроизведение, переключение между регионами при сбоях и управляемую инфраструктуру. ### RPC RPC означает Remote Procedure Call — общий шаблон вызова серверного метода так, как если бы он был локальной функцией. В Solana под «RPC» чаще всего понимается RPC-узел: узел, который отслеживает состояние Solana, но не участвует в консенсусе и специализируется на обработке запросов данных через интерфейс JSON-RPC, например о состоянии аккаунтов и истории транзакций, а также на отправке транзакций. Валидаторы, напротив, создают блоки и голосуют за них. Сервис RPC Helius — это глобально распределенный парк RPC-узлов, оптимизированный для рабочих нагрузок в производственной среде. Подробности см. в публикации [Узлы Solana: основы RPC Solana, валидаторов и поставщиков RPC](https://www.helius.dev/blog/solana-nodes-a-primer-on-solana-rpcs-validators-and-rpc-providers). ### Вебхук Вебхук — это запрос HTTP POST, который сервер отправляет на URL получателя при возникновении события, на которое оформлена подписка. Это «обратный» HTTP, при котором вызов инициирует сервер. [Вебхуки](/docs/ru/webhooks) Helius отправляют ончейн-события Solana — переводы, продажи NFT, активность пользовательских программ — на зарегистрированную конечную точку, устраняя необходимость в опросе. ### WebSocket (WSS) WebSocket — постоянное двунаправленное TCP-соединение, полученное путем обновления HTTP и используемое для потоковой передачи данных Solana на основе push-модели без повторных запросов HTTP. WSS (WebSocket Secure) — тот же протокол, работающий через TLS. Именно он используется для производственных подключений Solana. [LaserStream WebSocket](/docs/ru/rpc/websocket) — продукт Helius для потоковой передачи через WebSocket, включающий стандартные методы Solana и расширения Helius, такие как `transactionSubscribe`, — использует WSS. *** ## Экосистема ### Anchor Anchor — фреймворк Rust для быстрой и безопасной разработки программ Solana. Он берет на себя шаблонный код, включая сериализацию и проверку аккаунтов и диспетчеризацию инструкций, с помощью процедурных макросов. Благодаря этому разработчики могут сосредоточиться на логике программы, а не на низкоуровневых деталях. Большинство разработчиков Solana используют Anchor вместо написания программ на чистом Rust. Подробности см. в публикации [Введение в Anchor: руководство для начинающих по созданию программ Solana](https://www.helius.dev/blog/an-introduction-to-anchor-a-beginners-guide-to-building-solana-programs). ### IDL IDL означает Interface Definition Language. IDL — схема JSON, описывающая инструкции, аккаунты и типы данных программы Solana. Клиенты используют ее для создания транзакций и декодирования данных программ без ручного определения структуры инструкций. Anchor автоматически создает IDL и по умолчанию публикует их в блокчейне в отдельном аккаунте для общего доступа. ### Jito Компания из экосистемы Solana, управляющая основным движком блоков сети — инфраструктурным уровнем MEV (максимальной извлекаемой ценности), который принимает пакеты транзакций, то есть атомарные группы транзакций, выполняемые либо вместе, либо не выполняемые вовсе, и позволяет поисковикам платить валидаторам чаевые за приоритетное включение. Клиент валидатора Jito-Solana — форк Agave с интегрированным движком блоков. Для включения пакета требуются чаевые не менее 10 000 лампортов, а Jito-Relayer удерживает входящий трафик примерно 200 мс для проведения офчейн-аукциона пакетов. [Sender](#sender) от Helius одновременно отправляет транзакции через стейкинговые подключения и движок блоков Jito, используя путь, который первым обеспечит включение. См. публикацию [MEV в Solana: введение](https://www.helius.dev/blog/solana-mev-an-introduction). ### Light Protocol Команда протокола Solana, которая совместно с Helius разработала [ZK Compression](#zk-compression). Helius создала канонический индексатор ([Photon](#photon)) и управляет общедоступным RPC, а Light Protocol разрабатывает ончейн-программы и стек доказательств, от которых зависит индексатор. См. [github.com/Lightprotocol/light-protocol](https://github.com/Lightprotocol/light-protocol). ### Photon Индексатор [ZK Compression](#zk-compression) с открытым исходным кодом, созданный Helius. Данные сжатых аккаунтов хранятся в журналах транзакций Solana, а не в состоянии аккаунтов, поэтому валидаторы не предоставляют их через стандартный RPC. Photon анализирует транзакции Solana, восстанавливает состояние сжатых аккаунтов и предоставляет его через интерфейс JSON-RPC, который повторяет нативный RPC Solana и добавляет методы для ZK Compression, такие как [`getCompressedAccount`](/docs/ru/api-reference/zk-compression/getcompressedaccount) и [`getValidityProof`](/docs/ru/api-reference/zk-compression/getvalidityproof). Разработчики могут самостоятельно развернуть его из [github.com/helius-labs/photon](https://github.com/helius-labs/photon) или использовать размещенную конечную точку Helius. См. [ZK Compression](/docs/ru/api-reference/zk-compression). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.