8 инноваций, которые делают Solana первым блокчейном веб-масштаба

Познакомьтесь с технологическими новшествами Solana, которые делают возможной блокчейн-сеть с 50 000 транзакций в секунду.

Solana была задумана в 2017 году, когда ее основатель Анатолий Яковенко искал способ создания децентрализованной сети узлов, которая соответствовала бы производительности одного узла. Ни один из главных блокчейнов не приблизился к достижению этого свойства. Решение этой задачи – путеводная звезда Solana.

Системы Proof of Work, такие как Bitcoin и Ethereum, поддерживают около 10 транзакций в секунду (т/сек). Практические византийские системы, основанные на отказоустойчивости (PBFT), такие как Tendermint, поддерживают около 1000 т/сек со 100–200 узлами. Solana, подобно блокчейну PBFT PoS, поддерживает свыше 50 000 т/сек с более чем 200 узлами на текущих итерациях тестовой сети, что делает его самым производительным блокчейном и первой  децентрализованной сетью  такого масштаба в мире.

С момента своего создания команда Solana, состоящая из новаторов-технологов из Qualcomm, Intel, Netscape и Google, сосредоточилась на создании технологий, необходимых Solana для работы с этими революционными стандартами производительности.

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

  • Proof of History (POH)— часы перед консенсусом;
  • Tower BFT — PoH-оптимизированная версия PBFT;
  • Turbine — протокол распространения блоков;
  • Gulf Stream — протокол пересылки транзакций без Mempool;
  • Sealevel — параллельно исполняемые смарт-контракты;
  • Pipelining — юнит обработки транзакций для оптимизации валидации;
  • Cloudbreak — база данных горизонтально масштабируемых учетных записей;
  • Archivers — распределенное хранение реестра.

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

Proof of History (PoH)

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

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

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

Сегодняшние сети на основе блокчейна имеют проблему с часами. Их часы «тикают» всякий раз, когда производится новый блок. Для Ethereum это происходит раз в пятнадцать секунд, и в одном блоке можно разместить только этот объем информации. Эквивалентом TDMA для сетей на основе блокчейн были бы часы с частотой менее одной секунды, с которой согласуются все проверяющие узлы, чтобы они смогли более эффективно обрабатывать транзакции.

Основным нововведением Solana является Proof of History (Доказательство истории), глобально доступный, надежный источник времени в сети, который работает до достижения консенсуса. PoH не является протоколом консенсуса или механизмом против атак Сивиллы.  PoH – это решение проблемы с часами.

В то время как другие блокчейны требуют, чтобы валидаторы общались друг с другом, чтобы согласиться с тем, что время прошло, каждый валидатор Solana поддерживает свои собственные часы, кодируя ход времени в простой SHA-256, функции задержки с возможностью последовательного хеширования (VDF). Солана не использует VDF для случайности. Вместо этого каждый валидатор использует VDF для поддержания своих собственных часов. Поскольку каждый валидатор поддерживает свои собственные часы, выбор лидера запланирован заранее на всю эпоху. Как и Tendermint, график эпохи длится тысячи блоков. Однако, в отличие от Tendermint, сеть никогда не ждет неисправный узел. Каждый валидатор запускает VDF, чтобы доказать, что он получил свой слот для передачи блока и валидаторов. И каждый валидатор получает компенсацию за это, потому что производитель блока вознаграждается за создание блока.

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

Это ключевое новшество, войдя в стек, открыло пространство для дизайна. В дополнение к предоставлению часов, которые можно использовать для отметки времени, PоH позволяет Solana оптимизировать время блока (800мс), распространение блока (log200(n)), пропускную способность (50-80=K т)) и хранение реестра (петабайты) доступного в сети.

Tower BFT

Помимо технологии Proof of History, Solana использует Tower Consensus – алгоритм консенсуса, подобный PBFT, специально разработанный для использования синхронизированных часов. В отличие от PBFT, алгоритм Tower Consensus предпочитает жизнеспособность, а не последовательность. Как и в PBFT, узлы экспоненциально увеличивают свое время ожидания, чтобы прийти к соглашению, но поскольку реестр также является ненадежным источником времени, узлы могут наблюдать и проверять время ожидания всех других валидаторов в сети. Чтобы лучше понять это, давайте рассмотрим пример:

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

Turbine

Учитывая, что консенсусный уровень Solana не зависит от одноранговых сообщений, Solana может оптимизировать передачу блоков по сети независимо от консенсуса. В Solana есть техника распространения блоков Turbine, которая в значительной степени заимствована у BitTorrent. Когда блок передается в потоковом режиме, он разбивается на маленькие пакеты вместе с кодами восстановления, а затем распространяется по большому набору случайных узлов. При распределении на 200 узлов второй уровень сети может охватывать уже 40000 валидаторов. Таким образом, валидаторы могут распространять блоки с log200(n) влиянием на окончательное решение. Для всех практических целей, если каждое соединение составляет 100 мс, репликация может быть достигнута за 400 мс, а окончательное решение за 500 мс для сети с 40 000 узлов.

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

Gulf Stream

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

Клиенты, такие как кошельки, подписывают транзакции, которые ссылаются на определенный хеш блоков. Клиенты выбирают недавний хеш блоков, который был полностью подтвержден сетью. Блоки предлагаются примерно каждые 800 мс и требуют экспоненциально увеличивающегося времени ожидания для развертывания с каждым дополнительным блоком. Используя нашу кривую времени ожидания по умолчанию и полностью подтвержденные хэши блоков в худшем случае это 32 блока. Предполагая, что время блока составляет 800 мс, это время равняется 25,6 секундам.

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

Sealevel

Чтобы воспользоваться преимуществами высокопроизводительной сети Solana, мы создали гиперпараллельный механизм обработки транзакций Sealevel, разработанный для горизонтального масштабирования с использованием графических карт и дисков SSD. Обратите внимание, что все остальные блокчейны являются однопоточными компьютерами. Solana – единственный блокчейн, поддерживающий выполнение параллельных транзакций (а не только проверку подписи) в одном сегменте.

Решение этой проблемы в значительной степени заимствовано из метода работы драйвера операционной системы, называемого алгоритм scatter-gather. Транзакции заранее указывают, какое состояние они будут читать и записывать во время выполнения. Среда выполнения может найти все непересекающиеся функции перехода состояний, происходящие в блоке, и выполнять их параллельно – что называется параллельным выполнением – при оптимизации планирования чтения и записи состояния для массива SSD-накопителей уровня RAID 0.

Хотя сам Sealevel является виртуальной машиной, которая планирует транзакции, Sealevel фактически не выполняет транзакции в виртуальной машине. Вместо этого Sealevel передает транзакции, которые должны выполняться на оборудовании, с использованием проверенного в отрасли байт-кода, называемого Berkeley Packet Filter (BPF), который предназначен для высокопроизводительных фильтров пакетов. Этот байт-код был оптимизирован с начала 90-х годов и был развернут в производстве на миллионах коммутаторов по всему миру для обработки 60 миллионов пакетов в секунду в 40-гигабитной сети в одном коммутаторе.

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

Мы используем компилятор LLVM, который предназначен для WASM, мы предоставляем разработчикам большой набор инструментов для написания высокопроизводительных смарт-контрактов на C/C ++ и Rust, которые исполняют контракты на графических процессорах. Хотя Solana не использует WASM, разработчики могут скомпилировать код C и Rust, написанный для компиляторов WASM в компиляторе Solana с минимальными изменениями. Таким образом, разработчики могут легко перенести свои приложения из других крупных сетей WASM, таких как Dfinity, EOS, Polkadot и Ethereum 2.0.

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

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

Язык Move представил ресурсы и сценарии как концепции высокого уровня. Оба естественно вписываются в среду исполнения Solana Sealevel и то, как мы спроектировали наши нативные программы. Наша цель состоит в том, чтобы поддерживать Move как язык первого уровня, поэтому ресурсы ведут себя как нативные программы Solana и могут разрабатываться и создаваться с помощью Move или с помощью нашего собственного родного Rust ABI без каких-либо компромиссов в отношении производительности или безопасности.

Pipelining

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

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

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

Cloudbreak

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

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

В сочетании с нашим механизмом транзакций эта архитектура поддерживает выполнение транзакций AOT (Ahead Of Time). Как только валидатор обнаружит транзакцию, Sealevel может начать предварительную загрузку всех учетных записей с диска и подготовку среды к исполнению. Валидаторы и производители блоков могут даже начинать выполнять транзакции до того, как они будут закодированы в блок, что позволяет нам дополнительно оптимизировать время блока и задержку подтверждения.

Archivers

При скорости 1 Гбит/с сеть блокчейна будет генерировать 4 петабайта данных в год для реестра. Хранение данных быстро станет основным вектором централизации, мешая реализации блокчейна в процессе.

В Solana хранилище данных находится не у валидаторов, а в сети узлов, называемых архиваторами. Архиваторы не участвуют в консенсусе. История состояния разбита на множество частей и закодирована. Архиваторы хранят небольшие фрагменты состояния. Время от времени сеть будет просить архиваторов доказать, что они хранят данные, которые они должны хранить. Сеть Solana использует метод Proofs of Replication (PoRep), который в основном позаимствован у Filecoin.

Мы можем использовать наши часы до консенсуса Proof of History, чтобы оптимизировать создание PoReps. Узлы репликатора, которые не участвуют в консенсусе, используют PoH для генерации облегченных доказательств, с помощью которых фрагменты реестра были реплицированы, валидаторы могут проверять их в очень больших пакетах с помощью графических карт.

Архиваторы могут быть слабыми узлами (например, ноутбуками). Благодаря кодам восстановления и избыточности сеть архиваторов может предложить гарантии доступности данных, превосходящие все, о чем AWS и GCE могли только мечтать.

Заключение

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

Программное обеспечение Solana предназначено для того, чтобы не мешать оборудованию работать на полную мощность. Таким образом, Solana естественным образом масштабируется по пропускной способности сети, дисков SSD и ядрам графических карт. Это единственный в своем роде блокчейн, именно поэтому Solana достигает 50 000 TPS в сети из 200 физических отдельных узлов по всему миру.

Для более глубокого изучения 8 инноваций, которые делают существование сети Solana возможным, обратитесь к публикация в блоге по ссылкам ниже:

  • Proof of History (POH)— часы перед консенсусом;
  • Tower BFT — PoH-оптимизированная версия PBFT;
  • Turbine — протокол распространения блоков;
  • Gulf Stream — протокол пересылки транзакций без Mempool;
  • Sealevel — Параллельно исполняемые смарт-контракты;
  • Pipelining — a Transaction Processing Unit for validation optimization 
  • Cloudbreak — База данных горизонтально масштабируемых учетных записей;
  • Archivers — Distributed ledger store

Состояние сети

Тестет Solana работает уже сегодня. Вы можете увидеть его по адресу testnet.solana.com. В целях экономии мы используем только несколько узлов. Однако во многих случаях мы распространили его более чем на 200 физических отдельных узлов (не на совместно используемом оборудовании) в 23 центрах обработки данных в AWS, GCE и Azure для сравнительного анализа.

Среда выполнения также работает уже сегодня, и разработчики могут развернуть код в тестовом режиме уже сейчас. Сегодня разработчики могут создавать смарт-контракты на C, мы активно работаем над набором инструментов Rust. Rust будет основным языком для разработки смарт-контрактов Solana. Набор инструментов Rust общедоступен как часть Solana Javascript SDK, мы продолжаем работу над пакетом разработки ПО.

Вскоре Solana запустит общедоступную бета-версию, стимулирующую валидаторов для запуска узлов через программу Tour de SOL — по аналогии с программой “Game of Stakes” у Cosmos, которая ставит перед обществом задачу протестировать пределы сети Solana, зарабатывая при этом токены.