ソラナ：高性能ブロックチェーンのための新しいアーキテクチャ
Abstract
В данной статье представлена новая архитектура высокопроизводительного блокчейна. Solana реализует новый механизм хронометража под названием Proof of History (PoH) -- доказательство для верификации порядка и хода времени между событиями. PoH используется для кодирования хода времени без необходимости доверия в леджере, создавая исторический реестр, доказывающий, что событие произошло в определённый момент времени.
Ключевая инновация заключается в том, что PoH позволяет узлам сети устанавливать временной порядок событий без необходимости взаимодействия друг с другом. Используя верифицируемую функцию задержки, реализованную в виде последовательной цепочки хешей, система генерирует криптографические часы, предоставляющие способ верификации хода времени между событиями. Это позволяет сети обрабатывать тысячи транзакций в секунду, сохраняя при этом децентрализацию и безопасность.
PoH интегрирован с механизмом консенсуса Proof of Stake (PoS). Такая комбинация обеспечивает высокооптимизированную архитектуру блокчейна, в которой валидаторы могут верифицировать транзакции параллельно и эффективно достигать консенсуса. Система спроектирована для масштабирования в соответствии с законом Мура, используя повышение производительности аппаратного обеспечения для увеличения пропускной способности без ущерба для гарантий безопасности децентрализованной сети.
Abstract
本論文は、高性能ブロックチェーンのための新しいアーキテクチャを提示する。SolanaはProof of History（PoH）と呼ばれる新しい時間管理メカニズムを実装している。これはイベント間の順序と時間の経過を検証するための証明である。PoHは信頼不要な時間の経過を台帳にエンコードするために使用され、特定の時点でイベントが発生したことを証明する履歴記録を作成する。
重要なイノベーションは、PoHによりネットワーク内のノードが互いに通信することなくイベントの時間的順序を確立できることである。逐次的ハッシュチェーンとして実装された検証可能な遅延関数を使用することで、システムはイベント間の時間の経過を検証する方法を提供する暗号学的時計を生成する。これにより、ネットワークは分散化とセキュリティを維持しながら、毎秒数千のトランザクションを処理できる。
PoHはProof of Stake（PoS）コンセンサスメカニズムと統合されている。この組み合わせにより、バリデータがトランザクションを並列に検証し、効率的にコンセンサスに達することができる高度に最適化されたブロックチェーンアーキテクチャが可能になる。このシステムはムーアの法則に合わせてスケールするように設計されており、分散型ネットワークのセキュリティ保証を犠牲にすることなく、ハードウェア性能の向上を活用してスループットを改善する。
Introduction
Фундаментальная проблема блокчейн-систем заключается в достижении высокой пропускной способности транзакций при сохранении децентрализации и безопасности. Текущие реализации блокчейнов ограничены механизмами консенсуса, которые требуют обширной коммуникации между узлами для согласования времени и порядка событий. Эти координационные накладные расходы создают узкое место, препятствующее масштабированию существующих блокчейнов для удовлетворения потребностей глобальных приложений.
Ключевая проблема — время. В распределённых системах узлы не могут полагаться на внешние часы, поскольку не могут доверять точности временных меток других узлов. Традиционные протоколы консенсуса блокчейна решают эту проблему путём обширной коммуникации узлов для согласования текущего состояния и порядка транзакций. Эти коммуникационные накладные расходы фундаментально ограничивают пропускную способность, так как сеть может обрабатывать транзакции лишь с той скоростью, с которой узлы достигают консенсуса по их порядку.
Solana представляет Proof of History как решение проблемы синхронизации. PoH обеспечивает криптографический способ доказательства того, что между событиями прошло определённое количество времени, без необходимости полагаться на временные метки от потенциально злонамеренных участников. Создавая верифицируемую историческую запись, PoH позволяет узлам обрабатывать транзакции независимо, при этом сохраняя возможность доказать порядок происхождения событий. Этот прорыв позволяет сети параллелизировать обработку транзакций и значительно увеличить пропускную способность.
Ключевое понимание состоит в том, что если мы создадим доверенный источник времени, не требующий доверия, мы сможем устранить координационное узкое место из консенсуса. При наличии криптографических часов PoH валидаторы могут обрабатывать транзакции параллельно и взаимодействовать только для определения канонического порядка. Это архитектурное изменение позволяет Solana достигать уровней производительности, ранее считавшихся невозможными в децентрализованном блокчейне.
Introduction
ブロックチェーンシステムにおける根本的な課題は、分散化とセキュリティを維持しながら高いトランザクションスループットを達成することである。現在のブロックチェーン実装は、時間とイベントの順序付けについて合意するためにノード間の広範な通信を必要とするコンセンサスメカニズムによって制限されている。この調整のオーバーヘッドがボトルネックを生み出し、既存のブロックチェーンがグローバル規模のアプリケーションの需要に対応するためのスケーリングを妨げている。
核心的な問題は時間である。分散システムにおいて、ノードは他のノードのタイムスタンプが正確であることを信頼できないため、外部の時計に依存することができない。従来のブロックチェーンコンセンサスプロトコルは、ノードが現在の状態とトランザクションの順序について合意するために広範に通信することでこの問題を解決している。この通信のオーバーヘッドはスループットを根本的に制限する。ネットワークはノードが順序付けについてコンセンサスに達する速度でしかトランザクションを処理できないからである。
SolanaはこのタイミングProblemの解決策としてProof of Historyを導入する。PoHは、潜在的に悪意のあるアクターからのタイムスタンプに依存することなく、イベント間に一定の時間が経過したことを証明する暗号学的方法を提供する。検証可能な履歴記録を作成することで、PoHはノードがトランザクションを独立して処理しながら、イベントが発生した順序を証明できるようにする。このブレークスルーにより、ネットワークはトランザクション処理を並列化し、スループットを劇的に向上させることができる。
重要な洞察は、信頼不要な時間源を作成できれば、コンセンサスから調整のボトルネックを除去できるということである。PoHが暗号学的時計を提供することで、バリデータはトランザクションを並列に処理でき、正規の順序付けを確定するためにのみ通信する必要がある。このアーキテクチャの転換により、Solanaは分散型ブロックチェーンでは不可能と考えられていたパフォーマンスレベルを達成できる。
Outline
В данной работе описывается техническая архитектура Solana с акцентом на то, как Proof of History обеспечивает высокопроизводительную работу блокчейна. Документ сначала объясняет сам механизм PoH — как последовательная хеш-цепочка создаёт верифицируемый временной порядок событий. Мы подробно описываем криптографические свойства, обеспечивающие безопасность PoH, и демонстрируем, как валидаторы могут эффективно проверять последовательность PoH.
Затем статья исследует интеграцию PoH с консенсусом Proof of Stake. Мы описываем Tower BFT — алгоритм PoS, специально разработанный для использования временных свойств PoH. Интеграция позволяет валидаторам голосовать за состояние реестра при определённых временных метках PoH, создавая механизм консенсуса, который является одновременно быстрым и безопасным. Мы также объясняем условия штрафов, предотвращающих злонамеренное поведение.
Далее мы представляем сетевой дизайн Solana и протоколы распространения данных. Протокол Gulf Stream обеспечивает пересылку транзакций без необходимости в мемпуле, позволяя клиентам отправлять транзакции непосредственно предстоящим лидерам. Мы описываем работу ротации лидеров и способы поддержания высокой пропускной способности сети при смене лидерства.
Наконец, мы обсуждаем архитектуру системы, включая Transaction Processing Unit (TPU), параллельную среду выполнения Sealevel и Proof of Replication для верификации хранения данных. Прогнозы производительности показывают, что Solana может обрабатывать более 700 000 транзакций в секунду в стандартной гигабитной сети, при этом пропускная способность масштабируется с улучшением оборудования.
Outline
本論文では、Proof of Historyが高性能ブロックチェーン運用をいかに実現するかに焦点を当て、Solanaの技術アーキテクチャを説明する。まず、PoHメカニズム自体について説明する。逐次的ハッシュチェーンがいかにしてイベントの検証可能な時間的順序付けを作成するかを解説する。PoHを安全にする暗号学的特性を詳述し、バリデータがPoHシーケンスを効率的に検証する方法を示す。
次に、PoHがProof of Stakeコンセンサスとどのように統合されるかを探る。PoHの時間的特性を活用するために特別に設計されたPoSアルゴリズムであるTower BFTについて説明する。この統合により、バリデータは特定のPoHタイムスタンプにおける台帳の状態に投票でき、高速かつ安全なコンセンサスメカニズムが実現される。また、悪意ある行動を防止するスラッシング条件についても説明する。
続いて、Solanaのネットワーク設計とデータ伝播プロトコルを提示する。Gulf Streamプロトコルは、mempoolを必要とせずにトランザクション転送を可能にし、クライアントが今後のリーダーに直接トランザクションを送信できるようにする。リーダーローテーションの仕組みと、リーダーシップが変わっても高スループットを維持する方法を説明する。
最後に、Transaction Processing Unit（TPU）、Sealevel並列ランタイム、データストレージ検証のためのProof of Replicationを含むシステムアーキテクチャについて論じる。性能予測は、Solanaが標準的なギガビットネットワーク上で毎秒70万以上のトランザクションを処理でき、ハードウェアの改善に伴いスループットがスケールすることを示している。
Network Design
Сетевой дизайн Solana основан на системе ротации лидеров, где валидаторы по очереди производят блоки. Лидер отвечает за упорядочивание входящих транзакций в поток PoH и публикацию результирующих блоков в сети. Лидеры выбираются с помощью алгоритма, взвешенного по стейку, а расписание ротации известно заранее, что позволяет сети оптимизировать пересылку транзакций.
Протокол Gulf Stream устраняет необходимость в традиционном мемпуле, позволяя клиентам пересылать транзакции непосредственно предстоящим лидерам. Когда клиент отправляет транзакцию, она пересылается ожидаемому лидеру на основе расписания ротации. Если текущий лидер не может обработать транзакцию, она пересылается следующему ожидаемому лидеру. Такой дизайн снижает задержку подтверждения и позволяет валидаторам выполнять транзакции заранее, дополнительно оптимизируя пропускную способность.
Распространение транзакций использует многоуровневый подход. Клиенты отправляют транзакции валидаторам, которые пересылают их текущему или предстоящему лидеру. Лидер упорядочивает транзакции в потоке PoH, создавая полный порядок. После упорядочивания лидер передаёт поток PoH и данные транзакций валидаторам, которые проверяют последовательность PoH и выполняют транзакции параллельно.
Сетевой дизайн также включает протокол распространения блоков Turbine, который разбивает блоки на более мелкие пакеты и распространяет их по сети в древовидной структуре. Этот подход минимизирует требования к пропускной способности для отдельных валидаторов, обеспечивая быстрое распространение блоков. В сочетании со способностью PoH верифицировать порядок транзакций эта архитектура позволяет Solana достигать высокой пропускной способности без ущерба для децентрализации.
Network Design
Solanaのネットワーク設計は、バリデータが交代でブロックを生成するローテーションリーダーシステムを中心としている。リーダーは、着信トランザクションをPoHストリームに順序付けし、結果のブロックをネットワークに公開する責任を持つ。リーダーはステーク加重アルゴリズムによって選出され、ローテーションスケジュールは事前に知られているため、ネットワークはトランザクション転送を最適化できる。
Gulf Streamプロトコルは、クライアントが今後のリーダーに直接トランザクションを転送できるようにすることで、従来のmempoolの必要性を排除する。クライアントがトランザクションを送信すると、ローテーションスケジュールに基づいて予想されるリーダーに転送される。現在のリーダーがトランザクションを処理できない場合、次の予想リーダーに転送される。この設計により確認レイテンシが短縮され、バリデータが事前にトランザクションを実行できるため、スループットがさらに最適化される。
トランザクション伝播はマルチレイヤーアプローチを使用する。クライアントはバリデータにトランザクションを送信し、バリデータは現在のリーダーまたは今後のリーダーに転送する。リーダーはトランザクションをPoHストリームに順序付けし、全体の順序付けを作成する。順序付けが完了すると、リーダーはPoHストリームとトランザクションデータをバリデータに送信し、バリデータはPoHシーケンスを検証してトランザクションを並列に実行する。
ネットワーク設計には、ブロックをより小さなパケットに分割し、ツリー構造でネットワーク全体に配布するTurbineブロック伝播プロトコルも含まれている。このアプローチにより、迅速なブロック伝播を確保しながら、個々のバリデータの帯域幅要件を最小化する。PoHのトランザクション順序検証能力と組み合わせることで、このアーキテクチャはSolanaが分散化を犠牲にすることなく高スループットを達成することを可能にする。
Proof of History
Proof of History — это верифицируемая функция задержки, реализованная в виде последовательной хеш-цепочки с использованием SHA-256. Генератор PoH непрерывно вычисляет хеши SHA-256, используя каждый выход в качестве входа для следующего хеша. Это создаёт последовательную цепочку, где каждый хеш может быть вычислен только после предыдущего, устанавливая верифицируемый временной порядок. Вычислительные требования для генерации каждого хеша обеспечивают минимальную временную задержку между событиями.
Ключевое свойство PoH заключается в том, что верификация обходится дёшево, а производство — дорого. Верификатор может проверить всю последовательность хешей параллельно, разделив её на сегменты и проверив каждый сегмент независимо, а затем убедившись, что сегменты правильно соединяются. Однако генерация должна быть последовательной — нет способа предсказать выход хеш-цепочки без фактического вычисления каждого промежуточного шага. Эта асимметрия между генерацией и верификацией делает PoH практичным.
Внешние события и данные транзакций вставляются в последовательность PoH путём их смешивания с хеш-цепочкой. Когда поступает транзакция, её хеш комбинируется с текущим состоянием PoH, создавая запись, доказывающую существование транзакции в данной точке последовательности. Генератор PoH периодически фиксирует контрольные точки, публикуя текущее значение хеша вместе с количеством хешей, вычисленных с последней контрольной точки. Эти контрольные точки позволяют валидаторам эффективно проверять последовательность PoH без пересчёта каждого хеша.
Последовательность PoH служит криптографическими часами для всей сети. Поскольку хеш-цепочка является последовательной и верифицируемой, любой узел может доказать, что между двумя событиями прошло определённое количество времени, просто показав хеши, вычисленные за этот интервал. Это устраняет необходимость для узлов доверять внешним временным меткам или координироваться друг с другом для установления временного порядка, устраняя фундаментальное узкое место в традиционном консенсусе блокчейна.
Proof of History
Proof of Historyは、SHA-256を使用した逐次的ハッシュチェーンとして実装された検証可能な遅延関数である。PoHジェネレータは継続的にSHA-256ハッシュを計算し、各出力を次のハッシュの入力として使用する。これにより、各ハッシュは前のものが計算された後にのみ計算できる逐次的なチェーンが作成され、検証可能な時間的順序付けが確立される。各ハッシュを生成するための計算要件により、イベント間の最小時間遅延が強制される。
PoHの重要な特性は、検証は安価だが生成は高コストであることである。検証者はハッシュシーケンス全体をセグメントに分割し、各セグメントを独立して並列にチェックし、セグメントが適切に接続されていることを確認することで検証できる。しかし、生成は逐次的でなければならない。すべての中間ステップを実際に計算せずにハッシュチェーンの出力を予測する方法はない。生成と検証の間のこの非対称性がPoHを実用的にしている。
外部イベントとトランザクションデータは、ハッシュチェーンに混合されることでPoHシーケンスに挿入される。トランザクションが到着すると、そのハッシュは現在のPoH状態と結合され、トランザクションがシーケンスのその時点で存在したことを証明する記録が作成される。PoHジェネレータは定期的にチェックポイントを記録し、最後のチェックポイント以降に計算されたハッシュ数とともに現在のハッシュ値を公開する。これらのチェックポイントにより、バリデータはすべてのハッシュを再計算することなくPoHシーケンスを効率的に検証できる。
PoHシーケンスはネットワーク全体の暗号学的時計として機能する。ハッシュチェーンは逐次的で検証可能であるため、任意のノードは、その間隔中に計算されたハッシュを示すだけで、2つのイベント間に一定の時間が経過したことを証明できる。これにより、ノードが外部のタイムスタンプを信頼したり、時間的順序付けを確立するために互いに調整したりする必要がなくなり、従来のブロックチェーンコンセンサスにおける根本的なボトルネックが除去される。
Proof of History Sequence
Последовательность Proof of History представляет собой непрерывную цепочку хешей SHA-256, где каждый хеш зависит от предыдущего выхода. Последовательность начинается с начального значения-зерна, которое хешируется для получения первого выхода. Этот выход становится входом для следующего хеша, и процесс повторяется бесконечно. Генератор также ведёт счётчик, отслеживающий общее количество вычисленных хешей, который служит «временной меткой» PoH для событий в реестре.
Когда данные необходимо вставить в последовательность (например, хеши транзакций или подписи валидаторов), они комбинируются с текущим состоянием хеша с использованием детерминированной функции смешивания. Например, если текущее состояние хеша — hash_n и мы хотим вставить данные D, мы вычисляем hash_{n+1} = SHA256(hash_n || D), где || обозначает конкатенацию. Точка вставки записывается вместе со значением счётчика, доказывая, что данные D существовали в этой конкретной точке последовательности.
Верификация последовательности PoH может быть распараллелена путём разделения цепочки на сегменты. Например, валидатор может получать контрольные точки PoH каждые 10 000 хешей. Для верификации последовательности между контрольными точками валидатор может разделить 10 000 хешей на 100 сегментов по 100 хешей, проверить каждый сегмент независимо и параллельно, а затем убедиться, что сегменты правильно соединяются. Это позволяет верификации горизонтально масштабироваться с количеством доступных ядер CPU.
Последовательность также поддерживает эффективные доказательства того, что два события произошли в определённом порядке. При наличии двух вставок данных при значениях счётчика n и m, где n m, любой может проверить, что событие при n произошло до события при m, проверив хеш-цепочку между этими точками. Это свойство позволяет Solana создавать верифицируемую историческую запись всех событий в сети без необходимости постоянного нахождения узлов в сети или доверия внешним источникам времени.
Proof of History Sequence
Proof of Historyシーケンスは、各ハッシュが前の出力に依存するSHA-256ハッシュの連続的なチェーンである。シーケンスは初期シード値から始まり、それがハッシュされて最初の出力を生成する。この出力が次のハッシュの入力となり、プロセスは無限に繰り返される。ジェネレータは計算されたハッシュの総数を追跡するカウンタも維持しており、台帳内のイベントのPoH「タイムスタンプ」として機能する。
データをシーケンスに挿入する必要がある場合（トランザクションハッシュやバリデータの署名など）、決定論的な混合関数を使用して現在のハッシュ状態と結合される。例えば、現在のハッシュ状態がhash_nで、データDを挿入する場合、hash_{n+1} = SHA256(hash_n || D)を計算する。ここで||は連結を表す。挿入ポイントはカウンタ値とともに記録され、データDがシーケンスのその特定の時点で存在したことを証明する。
PoHシーケンスの検証は、チェーンをセグメントに分割することで並列化できる。例えば、バリデータは10,000ハッシュごとにPoHチェックポイントを受信する場合がある。チェックポイント間のシーケンスを検証するために、バリデータは10,000ハッシュを100ハッシュの100セグメントに分割し、各セグメントを独立して並列に検証し、セグメントが適切に接続されていることを確認できる。これにより、検証は利用可能なCPUコア数に応じて水平にスケールできる。
シーケンスは、2つのイベントが特定の順序で発生したことの効率的な証明もサポートする。カウンタ値nとm（n m）における2つのデータ挿入がある場合、nのイベントがmのイベントより前に発生したことを、それらの間のハッシュチェーンを確認することで誰でも検証できる。この特性により、Solanaはノードが継続的にオンラインであったり外部の時間源を信頼したりする必要なく、ネットワーク内のすべてのイベントの検証可能な履歴記録を作成できる。
Timestamp
Proof of History функционирует как децентрализованные часы, присваивающие временные метки событиям без зависимости от реального времени. Каждый хеш PoH представляет дискретный «тик» криптографических часов, а значение счётчика служит временной меткой. Поскольку хеш-цепочка является последовательной и верифицируемой, эти временные метки не требуют доверия — любой наблюдатель может проверить легитимность временной метки, проверив хеш-цепочку.
В Solana каждый валидатор может генерировать собственную последовательность PoH при работе в качестве лидера. При ротации лидерства валидаторы синхронизируют свои последовательности PoH, используя последнюю подтверждённую контрольную точку предыдущего лидера. Это обеспечивает непрерывность временной записи даже при смене валидаторов, производящих блоки. Сеть устанавливает каноническую временную линию путём достижения консенсуса о том, какие последовательности PoH принимать как часть официального реестра.
Система справляется с дрейфом часов и различиями в производительности оборудования посредством комбинации ротации лидеров и консенсуса. Если злонамеренный или неисправный лидер пытается генерировать временные метки PoH с неправильной скоростью (слишком быстро или слишком медленно), валидаторы могут обнаружить это, сравнив частоту тиков PoH со своими локальными генераторами PoH. Значительные отклонения от ожидаемой частоты указывают на проблему, и валидаторы могут отклонить блоки от лидеров, чьи последовательности PoH слишком сильно отклоняются от медианы сети.
Этот механизм временных меток решает одну из фундаментальных проблем распределённых систем: установление общего понятия времени без доверенного центрального органа. Используя PoH в качестве децентрализованных часов, Solana позволяет валидаторам обрабатывать транзакции параллельно, поддерживая глобально согласованный порядок. Временные метки также обеспечивают основу для функций, основанных на времени, таких как истечение срока транзакций, запланированные операции и измерение производительности.
Timestamp
Proof of Historyは、壁時計時間に依存せずにイベントにタイムスタンプを割り当てる分散型時計として機能する。各PoHハッシュは暗号学的時計の離散的な「ティック」を表し、カウンタ値がタイムスタンプとして機能する。ハッシュチェーンは逐次的で検証可能であるため、これらのタイムスタンプは信頼不要である。任意の観察者がハッシュチェーンを確認することでタイムスタンプの正当性を検証できる。
Solanaでは、各バリデータがリーダーとして行動する際に独自のPoHシーケンスを生成できる。バリデータがリーダーシップをローテーションする際、前のリーダーからの最後の確認済みチェックポイントを使用してPoHシーケンスを同期する。これにより、異なるバリデータが交代でブロックを生成しても、時間記録の連続性が確保される。ネットワークは、どのPoHシーケンスを公式台帳の一部として受け入れるかについてコンセンサスに達することで、正規のタイムラインを確立する。
システムはクロックドリフトとハードウェア性能のばらつきを、リーダーローテーションとコンセンサスの組み合わせで処理する。悪意のあるまたは故障したリーダーが不正な速度（速すぎるまたは遅すぎる）でPoHタイムスタンプを生成しようとした場合、バリデータは自身のローカルPoHジェネレータとPoHティックレートを比較することでこれを検出できる。予想レートからの大幅な逸脱は問題を示し、バリデータはPoHシーケンスがネットワーク中央値から大きく逸脱するリーダーからのブロックを拒否できる。
このタイムスタンプメカニズムは、分散システムにおける根本的な問題の1つを解決する。信頼できる中央機関なしに共通の時間概念を確立することである。PoHを分散型時計として使用することで、Solanaはバリデータがグローバルに一貫した順序付けを維持しながらトランザクションを並列に処理できるようにする。タイムスタンプはまた、トランザクションの有効期限、スケジュールされた操作、パフォーマンス測定などの時間ベースの機能の基盤も提供する。
Proof of Stake Consensus
Механизм консенсуса Solana, называемый Tower BFT, представляет собой алгоритм Proof of Stake, специально разработанный для использования временных свойств Proof of History. Валидаторы стейкают токены SOL для участия в консенсусе и получения вознаграждений за корректную валидацию блоков. Система голосования, взвешенная по стейку, гарантирует, что валидаторы с большей экономической заинтересованностью в сети имеют пропорционально большее влияние на решения консенсуса.
Ключевая инновация Tower BFT — использование периодов блокировки, экспоненциально возрастающих с каждым последовательным голосом. Когда валидатор голосует за хеш PoH, он берёт на себя обязательство по данному форку реестра на определённое количество тиков PoH. Если он голосует за следующий блок в том же форке, период блокировки удваивается. Это создаёт сильный экономический стимул для валидаторов продолжать голосовать за тот же форк, поскольку переключение на другой форк потребует ожидания истечения предыдущих блокировок.
Конкретно, если валидатор голосует за блок при временной метке PoH t, он не может голосовать за конфликтующий форк, пока не пройдёт 2^n тиков, где n — количество последовательных голосов на текущем форке. Этот механизм экспоненциальной блокировки делает систему устойчивой к атакам дальнего действия, одновременно обеспечивая быструю финализацию. Как только суперБольшинство стейка проголосовало за блок с достаточной глубиной, этот блок фактически финализирован.
Условия штрафования обеспечивают честное поведение. Если валидатор голосует за два конфликтующих форка в период, когда он должен быть заблокирован, он штрафуется — его застейканные токены частично уничтожаются и он исключается из набора валидаторов. Это делает экономически иррациональным попытки двойного голосования или иного византийского поведения. Сочетание верифицируемых временных меток PoH и экспоненциальных блокировок Tower BFT создаёт механизм консенсуса, который является одновременно быстрым и безопасным, достигая финализации за секунды при сохранении гарантий безопасности традиционных BFT-систем.
Proof of Stake Consensus
SolanaのコンセンサスメカニズムはTower BFTと呼ばれ、Proof of Historyの時間的特性を活用するために特別に設計されたProof of Stakeアルゴリズムである。バリデータはSOLトークンをステークしてコンセンサスに参加し、ブロックの正確な検証に対して報酬を得る。ステーク加重投票システムにより、ネットワークにより多くの経済的利害関係を持つバリデータがコンセンサス決定に比例してより多くの影響力を持つことが保証される。
Tower BFTの核心的なイノベーションは、連続投票ごとに指数関数的に増加するロックアウト期間の使用である。バリデータがPoHハッシュに投票すると、一定数のPoHティックの間、台帳のそのフォークにコミットする。そのフォークの次のブロックに投票すると、ロックアウト期間は倍増する。これにより、バリデータが同じフォークで投票を続ける強い経済的インセンティブが生まれる。フォークの切り替えには以前のロックアウトの期限切れを待つ必要があるからである。
具体的には、バリデータがPoHタイムスタンプtでブロックに投票した場合、2^nティックが経過するまで競合するフォークに投票できない。ここでnは現在のフォークで行った連続投票の数である。この指数関数的ロックアウトメカニズムにより、システムは高速なファイナリティを可能にしながら、長距離攻撃に対して安全になる。ステークの超過半数が十分な深さでブロックに投票すると、そのブロックは事実上確定される。
スラッシング条件は正直な行動を強制する。バリデータがロックアウトされているはずの期間中に2つの競合するフォークに投票した場合、スラッシングされる。ステークされたトークンは部分的に破壊され、バリデータセットから除外される。これにより、二重投票やその他のビザンチン行動を試みることが経済的に非合理的になる。PoHの検証可能なタイムスタンプとTower BFTの指数関数的ロックアウトの組み合わせにより、従来のBFTシステムのセキュリティ保証を維持しながら、数秒でファイナリティを達成する高速かつ安全なコンセンサスメカニズムが実現される。
Streaming Proof of Replication
Proof of Replication (PoRep) — это механизм, позволяющий валидаторам доказать, что они хранят данные реестра, не раскрывая сами данные и не требуя интенсивных вычислений. Solana реализует потоковую версию PoRep, где валидаторы непрерывно демонстрируют репликацию состояния блокчейна. Это необходимо для безопасности сети, так как обеспечивает правильное распределение данных реестра между валидаторами, а не их концентрацию в нескольких местах.
Механизм PoRep работает следующим образом: валидаторы шифруют сегменты реестра с использованием шифрования в режиме CBC (Cipher Block Chaining) с уникальным ключом валидатора, полученным из его идентификатора. Процесс шифрования таков, что каждый зашифрованный блок зависит от предыдущего, создавая цепочку, уникальную для каждого валидатора. Это предотвращает простое копирование зашифрованных данных между валидаторами — каждый валидатор должен хранить и обрабатывать исходные данные реестра для генерации своей уникальной зашифрованной версии.
Периодически сеть выдаёт задания валидаторам, требуя предоставить определённые зашифрованные блоки. Поскольку шифрование является цепочечным, валидатор должен хранить все предшествующие блоки для генерации правильного ответа. Валидатор предоставляет свой зашифрованный блок вместе с доказательством Меркла, показывающим его положение в зашифрованном реестре. Сеть может быстро проверить это доказательство без необходимости расшифровки или повторного шифрования данных.
Этот потоковый подход к PoRep имеет низкие накладные расходы по сравнению с традиционными системами доказательства хранения. Валидаторы могут шифровать данные по мере их поступления и отвечать на задания с минимальной задержкой. Система также обеспечивает восстановление в случае потери данных — если валидатор теряет часть реестра, он может загрузить её у других валидаторов и повторно зашифровать. Сочетание PoRep с временными метками PoH создаёт полную систему подотчётности, где сеть может проверить как время создания данных, так и их правильное хранение по всей сети валидаторов.
Streaming Proof of Replication
Proof of Replication（PoRep）は、バリデータがデータ自体を明かしたり計算集約的な処理を必要としたりすることなく、台帳データを保存していることを証明できるメカニズムである。SolanaはPoRepのストリーミングバージョンを実装しており、バリデータはブロックチェーンの状態を複製していることを継続的に実証する。これはネットワークセキュリティにとって不可欠であり、台帳データがバリデータ間で適切に分散され、少数の場所に集中していないことを保証する。
PoRepメカニズムは、バリデータがそのIDから派生したバリデータ固有のキーを使用して、CBC（Cipher Block Chaining）モード暗号化で台帳のセグメントを暗号化することで機能する。暗号化プロセスは、各暗号化ブロックが前のブロックに依存するようになっており、各バリデータに固有のチェーンを作成する。これにより、バリデータが互いの暗号化データを単にコピーすることが防止される。各バリデータは、固有の暗号化バージョンを生成するために、元の台帳データを保存して処理しなければならない。
定期的に、ネットワークはバリデータに特定の暗号化ブロックの提供を要求するチャレンジを発行する。暗号化はチェーンされているため、バリデータは正しい応答を生成するためにすべての先行ブロックを保存していなければならない。バリデータは暗号化ブロックとともに、暗号化台帳内のその位置を示すMerkle証明を提出する。ネットワークはデータを復号化または再暗号化する必要なく、この証明を迅速に検証できる。
このPoRepへのストリーミングアプローチは、従来のproof-of-storageシステムと比較して低いオーバーヘッドを持つ。バリデータはデータの到着時に暗号化でき、最小限のレイテンシでチャレンジに応答できる。システムはデータ損失の場合のリカバリも可能にする。バリデータが台帳の一部を失った場合、他のバリデータからダウンロードして再暗号化できる。PoRepとPoHタイムスタンプの組み合わせにより、ネットワークがデータの作成時期とバリデータネットワーク全体に適切に保存されていることの両方を検証できる完全な説明責任システムが作成される。
System Architecture
Системная архитектура Solana спроектирована как конвейер, где различные стадии обработки транзакций выполняются параллельно. Transaction Processing Unit (TPU) — центральный компонент, отвечающий за обработку входящих транзакций. TPU состоит из нескольких стадий: fetch (сбор транзакций), верификация подписей, banking (выполнение транзакций) и write (запись в хранилище). Каждая стадия работает параллельно над разными транзакциями, аналогично конвейеру процессора.
Верификация подписей ускоряется с помощью GPU, которые высокоэффективны в операциях криптографии на эллиптических кривых, необходимых для проверки подписей транзакций. Перенося эту вычислительно интенсивную задачу на GPU, Solana может проверять подписи со скоростью более 900 000 в секунду на стандартном оборудовании. Эта параллельная верификация подписей предотвращает превращение криптографической проверки в узкое место даже при очень высоких скоростях обработки транзакций.
Среда выполнения Sealevel — это параллельный движок исполнения смарт-контрактов Solana. В отличие от традиционных блокчейнов, выполняющих транзакции последовательно, Sealevel анализирует транзакции для определения используемых аккаунтов и выполняет неконфликтующие транзакции параллельно на нескольких ядрах CPU. Транзакции, обращающиеся к одним и тем же аккаунтам, выполняются последовательно для поддержания согласованности, но транзакции, обращающиеся к разным аккаунтам, могут выполняться одновременно. Этот параллелизм возможен благодаря глобальному порядку, установленному PoH — валидаторы могут выполнять транзакции в любом порядке, если применяют их к состоянию в последовательности, определённой PoH.
Архитектура также включает оптимизированные компоненты для распространения и хранения блоков. Протокол распространения блоков Turbine использует стирающее кодирование для разбиения блоков на более мелкие пакеты, распространяемые по сети в древовидной структуре, минимизируя требования к пропускной способности. Сеть Archivers обеспечивает децентрализованное хранение исторических данных реестра, используя PoRep для гарантии доступности данных. Вместе эти компоненты создают систему, способную обрабатывать сотни тысяч транзакций в секунду, сохраняя свойства децентрализации и безопасности блокчейна.
System Architecture
Solanaのシステムアーキテクチャは、トランザクション処理の異なる段階が並列に行われるパイプラインとして設計されている。Transaction Processing Unit（TPU）は、着信トランザクションの処理を担当する中核コンポーネントである。TPUはいくつかの段階で構成される：fetch（トランザクションの収集）、署名検証、banking（トランザクション実行）、write（ストレージへのコミット）。各段階は異なるトランザクションに対して並列に動作し、CPUパイプラインと同様の仕組みである。
署名検証はGPUを使用して加速される。GPUはトランザクション署名の検証に必要な楕円曲線暗号演算において非常に効率的である。この計算集約的なタスクをGPUにオフロードすることで、Solanaはコモディティハードウェア上で毎秒900,000を超える速度で署名を検証できる。この並列署名検証により、非常に高いトランザクションレートでも暗号学的検証がボトルネックになることが防止される。
Sealevelランタイムは、Solanaの並列スマートコントラクト実行エンジンである。トランザクションを逐次的に実行する従来のブロックチェーンとは異なり、Sealevelはトランザクションを分析してアクセスするアカウントを特定し、競合しないトランザクションを複数のCPUコアで並列に実行する。同じアカウントにアクセスするトランザクションは一貫性を維持するために逐次的に実行されるが、異なるアカウントにアクセスするトランザクションは同時に実行できる。この並列処理はPoHがグローバルな順序付けを確立するため可能である。バリデータは、PoHで指定されたシーケンスで状態に適用する限り、任意の順序でトランザクションを実行できる。
アーキテクチャには、ブロック伝播とストレージのための最適化されたコンポーネントも含まれている。Turbineブロック伝播プロトコルは、イレイジャーコーディングを使用してブロックをより小さなパケットに分割し、ツリー構造でネットワーク全体に配布することで帯域幅要件を最小化する。Archiversネットワークは、PoRepを使用してデータの可用性を確保しながら、履歴台帳データの分散ストレージを提供する。これらのコンポーネントが一体となり、ブロックチェーンの分散化とセキュリティ特性を維持しながら毎秒数十万のトランザクションを処理できるシステムを構築する。
Performance
Архитектура Solana разработана для достижения уровней производительности, масштабирующихся с улучшением оборудования в соответствии с законом Мура. При стандартном гигабитном сетевом подключении теоретическая максимальная пропускная способность составляет примерно 710 000 транзакций в секунду при размере транзакции 176 байт (включая подписи и метаданные). Этот расчёт основан на пропускной способности сети как основном узком месте, при этом вычислительные узкие места устранены посредством параллелизации.
Верификация подписей, часто являющаяся ограничивающим фактором производительности блокчейна, ускоряется с помощью параллелизации на GPU. Один GPU может проверять более 900 000 подписей ed25519 в секунду, что превышает предел пропускной способности сети. Это означает, что верификация подписей не ограничивает производительность системы — узкое место смещается к пропускной способности сети и выполнению транзакций. Для простых транзакций, только переводящих значение без сложной логики смарт-контрактов, стадия banking может обрабатывать транзакции со скоростью, соответствующей входной скорости сети.
Генератор PoH работает на выделенном ядре CPU, производя примерно 4 000 хешей в миллисекунду на процессоре 4 ГГц. При такой скорости последовательность PoH обеспечивает временные метки с точностью 0,25 микросекунды, что достаточно для упорядочивания миллионов транзакций в секунду. Последовательная природа генерации PoH означает, что этот компонент не может быть распараллелен, но пропускная способность достаточно высока, чтобы не ограничивать общую производительность системы.
По мере улучшения оборудования пропускная способность Solana масштабируется соответственно. Более быстрые сети, более мощные GPU и улучшенные CPU — всё это способствует увеличению скорости обработки транзакций. Система спроектирована для использования этих улучшений без необходимости изменения протокола. Этот подход к масштабированию контрастирует с блокчейнами, фундаментально ограниченными последовательными механизмами консенсуса, позволяя Solana достигать уровней производительности, ранее считавшихся невозможными в децентрализованной системе, при сохранении гарантий безопасности и децентрализации.
Performance
Solanaのアーキテクチャは、ムーアの法則に従ってハードウェアの改善とともにスケールするパフォーマンスレベルを達成するように設計されている。標準的な1ギガビットネットワーク接続では、理論上の最大スループットは1トランザクションあたり176バイト（署名とメタデータを含む）を想定すると、毎秒約710,000トランザクションである。この計算はネットワーク帯域幅を主要なボトルネックとし、計算上のボトルネックは並列化によって除去されている。
署名検証はブロックチェーンパフォーマンスの制限要因となることが多いが、GPUの並列化を使用して加速される。単一のGPUは毎秒900,000以上のed25519署名を検証でき、これはネットワークスループット制限を超えている。これは署名検証がシステムのパフォーマンスを制約しないことを意味する。ボトルネックはネットワーク帯域幅とトランザクション実行に移行する。複雑なスマートコントラクトロジックを含まない単純な価値移転トランザクションの場合、bankingステージはネットワーク入力レートに匹敵するレートでトランザクションを処理できる。
PoHジェネレータは専用のCPUコア上で動作し、4GHzプロセッサ上でミリ秒あたり約4,000ハッシュを生成する。このレートで、PoHシーケンスは0.25マイクロ秒の粒度のタイムスタンプを提供し、毎秒数百万のトランザクションの順序付けに十分である。PoH生成の逐次的な性質はこのコンポーネントを並列化できないことを意味するが、スループットは十分に高く、全体的なシステムパフォーマンスを制限しない。
ハードウェアが改善されるにつれて、Solanaのスループットはそれに応じてスケールする。より高速なネットワーク、より強力なGPU、改善されたCPUはすべてより高いトランザクションレートに貢献する。システムはプロトコルの変更を必要とせずにこれらの改善を活用するように設計されている。このスケーラビリティアプローチは、逐次的コンセンサスメカニズムによって根本的に制限されるブロックチェーンとは対照的であり、Solanaがセキュリティと分散化の保証を維持しながら、分散型システムでは不可能と考えられていたパフォーマンスレベルを達成することを可能にする。
Conclusion
Proof of History представляет собой фундаментальный прорыв в архитектуре блокчейна, решая проблему синхронизации, которая ограничивала масштабируемость распределённых реестров. Создавая верифицируемые криптографические часы, PoH позволяет валидаторам устанавливать временной порядок событий без обширных коммуникационных накладных расходов, требуемых традиционными механизмами консенсуса. Эта инновация устраняет критическое узкое место и позволяет параллелизировать обработку транзакций по всей сети.
Интеграция PoH с оптимизированными системными компонентами — верификацией подписей с ускорением на GPU, параллельным выполнением транзакций через Sealevel и эффективными протоколами распространения блоков — создаёт блокчейн, способный обрабатывать сотни тысяч транзакций в секунду на стандартном оборудовании. Важнее всего то, что архитектура спроектирована для масштабирования с улучшением оборудования, что означает продолжение роста производительности по мере ускорения процессоров и повышения возможностей сетей.
Дизайн Solana демонстрирует, что высокая производительность и децентрализация не являются взаимоисключающими. Используя PoH в качестве основы для консенсуса и координации системы, сеть достигает уровней пропускной способности, сопоставимых с централизованными базами данных, сохраняя при этом свойства безопасности и устойчивости к цензуре децентрализованного блокчейна. Механизм консенсуса Tower BFT, взвешенный по стейку, обеспечивает безопасность сети от византийских участников при достижении быстрой финализации.
Реализация этой архитектуры обеспечивает практический путь к глобальному принятию технологии блокчейн. Приложения, требующие высокой пропускной способности транзакций — такие как децентрализованные биржи, игровые платформы и финансовые системы — теперь могут быть построены на по-настоящему децентрализованной инфраструктуре без компромиссов в производительности. Proof of History открывает дверь новому поколению блокчейн-приложений, ранее невозможных из-за ограничений масштабируемости.
Conclusion
Proof of Historyは、分散型台帳のスケーラビリティを制限してきたタイミング問題を解決することで、ブロックチェーンアーキテクチャにおける根本的なブレークスルーを表している。検証可能な暗号学的時計を作成することで、PoHはバリデータが従来のコンセンサスメカニズムで必要とされる広範な通信オーバーヘッドなしにイベントの時間的順序付けを確立できるようにする。このイノベーションにより重要なボトルネックが除去され、トランザクション処理をネットワーク全体で並列化できるようになる。
PoHと最適化されたシステムコンポーネント（GPU加速署名検証、Sealevelによる並列トランザクション実行、効率的なブロック伝播プロトコル）の統合により、コモディティハードウェア上で毎秒数十万のトランザクションを処理できるブロックチェーンが実現される。さらに重要なのは、アーキテクチャがハードウェアの改善とともにスケールするように設計されており、プロセッサが高速化しネットワークがより高性能になるにつれてパフォーマンスが向上し続けることである。
Solanaの設計は、高性能と分散化が相互に排他的ではないことを実証している。PoHをコンセンサスとシステム調整の基盤として活用することで、ネットワークは分散型ブロックチェーンのセキュリティと検閲耐性の特性を維持しながら、中央集権型データベースに匹敵するスループットレベルを達成する。ステーク加重Tower BFTコンセンサスメカニズムにより、高速なファイナリティを達成しながら、ビザンチンアクターに対するネットワークの安全性が確保される。
このアーキテクチャの実装は、ブロックチェーン技術がグローバルな採用へとスケールするための実用的な道筋を提供する。高いトランザクションスループットを必要とするアプリケーション（分散型取引所、ゲームプラットフォーム、金融システムなど）は、パフォーマンスを犠牲にすることなく、真に分散化されたインフラストラクチャ上に構築できるようになった。Proof of Historyは、スケーラビリティの制約のために以前は実現不可能であった新世代のブロックチェーンアプリケーションへの扉を開く。
