導入

「世界中の誰よりも、より小さく、より速く、より安くを知っていましたが、今、それらのコンセプトをブロックチェーンに適用しています。」- グレッグ·フィッツジェラルド、Solanaの共同創設者

Solanaは、その速度、効率、およびユーザーエクスペリエンスへの注力で知られる、高性能で低レイテンシーなブロックチェーンです。その独自の統合アーキテクチャにより、グローバルに分散したネットワーク上で1秒あたり数千件の取引が可能となります。ブロックタイムは400ミリ秒で、取引手数料もわずかなセント単位です。その速度とコスト効率の両方を実現しています。このレポートでは、Solanaの設計と運用の複雑さについて掘り下げ、その能力に貢献する主要なメカニズムとネットワークトポロジーを探求しています。

ソラナは、ブロックチェーンの開発に統合的なアプローチを取り、創設チームの数十年にわたる分散システム構築の経験を活かしています。ソラナの中心的な原則の1つは、ソフトウェアがハードウェアの邪魔をすることはないということです。つまり、ソフトウェアは実行されるハードウェアを最大限に活用し、それとスケーリングします。統合されたエコシステムとして、この単一のブロックチェーン上に構築されたすべてのアプリケーションはコンポーザビリティを継承し、シームレスに相互作用し合い、お互いに構築することができます。このアーキテクチャは、ブリッジング、別々のチェーンID、または流動性の断片化が不要で、わかりやすく直感的なユーザーエクスペリエンスを確保します。

ソラナは急速に進化しており、最近の進展にはSVMロールアップなどが含まれていますZK圧縮重要なスケーリングソリューションとしての地位を築く可能性がある一方で、これらのプロジェクトは将来的にはソラナに対する私たちの認識を形作るかもしれませんが、現在は開発や採用の非常に初期の段階にあり、このレポートでは取り上げられません。

取引ライフサイクル

このレポートを通じてSolanaを理解するための主要な視点は、典型的な取引のライフサイクルです。 Solana取引を理解するための基本モデルを構築するために、プロセスを次のように概説することができます。

• ユーザーはトランザクションを開始し、すべてのトランザクションは現在のリードブロックプロデューサー（リーダーとしても知られています）に送信されます。リーダーはこれらのトランザクションをブロックにまとめ、実行してローカル状態を更新します。
• このトランザクションのブロックは、他の検証者が実行および確認するためにネットワーク全体に伝播されます。

このレポートの後続のセクションでは、このモデルを拡大し、このプロセスについて詳細に掘り下げます。まず、キーパートナーであるユーザーから始めます。

思い出

コアSolanaプロトコルへの実質的な変更は、形式的で透明な手続きを経ますプロセスソラナ改善文書（SIMD）を提出することで、コミュニティメンバーやコアエンジニアリングが公に批評します。 SIMDはその後、ネットワークによって投票されます。

六つの段階

このレポート全体で上記に示されている6段階のビジュアルを参照します。これは、Solanaの中核要素間の関係を理解するための一貫した枠組みを提供しています。

前の章はこれらの6つの段階に従って配置されています。最終の章であるゴシップ、アーカイブ、経済、そしてジトは、どんな疑問点も解決します。いくつかの章は複数の段階にまたがり、いくつかの段階は複数の章に現れることに注意することが重要です。

このオーバーラップは避けられません。なぜなら、6段階のフレームワークには限界があります。実際、Solanaは多くの相互依存要素を持つ複雑な分散システムです。

ユーザー

「ソラナは暗号通貨のAppleになる可能性がある」とソラナの共同創設者であるRaj Gokalは述べています

ユーザーの旅は通常、ウォレットアプリの設定と資金調達から始まります。 Solana用には、ネイティブモバイルアプリケーションまたはブラウザ拡張機能として利用可能な人気のあるウォレットアプリケーションが複数あります。

ウォレットは、公開キーと秘密キーからなるユーザーのキーペアを暗号的に生成します。公開キーは、そのアカウントの一意の識別子として機能し、ネットワーク内のすべての参加者によって知られています。Solana上のユーザーのアカウントは、Solanaブロックチェーンとのやり取りに関連する情報と状態を保持するデータ構造と見なすことができます。このように、公開キーはファイル名に類似しています。ファイル名がファイルシステム内のファイルを一意に識別するのと同様に、Solanaの公開キーはSolanaブロックチェーン上のアカウントを一意に識別します。Solana上の公開キーは、32バイトのBase58エンコードされた文字列として表されます。

FDKJvWcJNe6wecbgDYDFPCfgs14aJnVsUfWQRYWLn4Tn

プライベートキー（秘密鍵とも呼ばれる）は、アカウントにアクセスして変更する権限を付与するパスワードやアクセスキーとして考えることができます。秘密鍵で署名することは、ブロックチェーンが認可を処理する方法です。秘密鍵の知識はアカウントに対する絶対的な権限を与えます。Solanaの秘密鍵も32バイトの長さです。キーペアは公開（前半）と秘密（後半）キーの64バイトの組み合わせです。例：

3j15jr41S9KmdfughusutvvqBjAeEDbU5sDQp8EbwQ3Hify2pfM1hiEsuFFAVq8bwGywnZpswrbDzPENbBZbd5nj

[63,107,47,255,141,135,58,142,191,245,78,18,90,162,107,197,8,33,211,15,228,235,250,30,185,122,105,23,147,115,115,86,8,155,67,155,110,51,117,0,19,150,143,217,132,205,122,91,167,61,6,246,107,39,51,110,185,81,13,81,16,182,30,71]

秘密鍵は、通常12語または24語のニーモニックシードフレーズからも導出できます。この形式は、より簡単なバックアップとリカバリーのためにウォレットでよく使用されます。1つのシードフレーズから決定論的に複数のキーを導出することができます。

Solanaは利用しますEd25519,広く使用されている楕円曲線デジタル署名アルゴリズム、その公開鍵暗号ニーズのためにEd25519を選んでいます。Ed25519は小さな鍵サイズ、小さな署名サイズ、高速な計算、多くの一般的な攻撃への免疫性から好まれています。それぞれのSolanaウォレットアドレスはEd25519楕円曲線上の点を表しています。

ユーザーは、プライベートキーで取引に署名します。この署名は取引データと一緒に含まれ、送信者の公開鍵を使用して他の参加者によって検証することができます。このプロセスにより、取引が改ざんされていないことが保証され、対応するプライベートキーの所有者によって承認されていることが確認されます。署名はまた、取引の一意の識別子としても機能します。

ソラナ トランザクション

トランザクションを送信することは、Solanaで状態を変異させる唯一の方法です。どんな書き込み操作もトランザクションを介して行われ、トランザクションはアトミックです。つまり、トランザクションが試みるすべてのことが起こるか、トランザクションが失敗します。トランザクションは、より正式には「トランザクションメッセージ」として知られる4つのセクションで構成されます：ヘッダー、口座アドレスのリスト、最新のブロックハッシュ、および命令。

• ヘッダー：ヘッダーには、アカウントアドレスリストへの参照が含まれており、取引に署名する必要があるアカウントを示しています。
• アカウントアドレス：このリストには、トランザクション中に読み取られるか書き込まれるすべてのアカウントが含まれています。すべてのトランザクションに対してこのようなリストを作成することは、Solanaに固有の要件であり、開発者にとっては課題となることがあります。ただし、トランザクションがどの状態と対話するかを事前に知っていることにより、他の多くのブロックチェーンでは不可能な最適化を実現できます。
• 最近のブロックハッシュ：これは重複した取引と古い取引を防ぐために使用されます。 最近のブロックハッシュは150ブロック（約1分）後に期限切れになります。 デフォルトでは、RPCは取引が確定するか、最近のブロックハッシュが期限切れになるまで、取引を2秒ごとに転送しようと試みます。その時点で取引は破棄されます。
• 手順：これらは取引の中心部分を形成します。各手順は特定の操作（例：転送、鋳造、燃やす、口座を作成、口座を閉じる）を表します。各手順は実行するプログラム、必要なアカウント、および手順の実行に必要なデータを指定します。

トランザクション内の命令数は、まずそのサイズによって制限されます。これは最大1,232バイトまでです。参照できるアカウントの数にも制限があります。最後に、トランザクションの複雑さにも制限があり、処理されるトランザクションの計算リソースを測定するコンピューティングユニット（CU）で表されます。

思い出す

SOLの最小単位は「ラムポート」として知られており、1 SOLの10億分の1に相当し、ビットコインのサトシに似ています。ラムポートは～に名付けられましたレスリー・ランポート, 現代の分散システムの多くの理論的基盤を確立したコンピュータサイエンティスト兼数学者。

トランザクションを実行するためのSOLコストは、ベース料金と優先料金の2つに分かれます。ベース料金は、通常、トランザクションの複雑さに関係なく、署名ごとに固定の5000ラムポートです。通常、トランザクションごとに1つの署名があります。

優先料金は技術的には任意ですが、ブロックスペースの需要が高い期間には必要になります。これらの料金は、計算ユニットあたりのマイクロラムポート（ラムポートの百万分の一）で価格設定されています。その目的は、トランザクションをブロックに含めるために検証ノードにとって経済的に魅力的にする価格シグナルとして機能することです。

合計手数料 = 優先手数料 + 基本手数料

優先手数料 = コンピュートユニット価格（マイクロラムポート）×コンピュートユニット制限

現在、すべての取引に関連する手数料の50%が焼却され、このSOLが循環から永久に削除されます。残りの50%はブロック生産者に支払われます。新しい変更（SIMD 96）が近く導入され、優先手数料の100%がブロック生産者に支払われるようになります。基本手数料は変更されません。

‍

トランザクションを送信する

ユーザーは、ウォレットをアプリケーションに接続し、アプリケーションがユーザーの公開鍵を読むことを許可します。秘密鍵は暗号化され、アプリケーションとは別の環境で安全にサンドボックス化されています。

アプリケーションは、ユーザーの相互作用に基づいて取引メッセージのパラメータを構築します。たとえば、ユーザーが2つのトークンを交換したい場合、トークンの購入数量、売却する対応するトークン、および許容可能な取引スリッページを指定する必要があります。

トランザクションメッセージが準備できると、ユーザーの秘密鍵で署名されるためにウォレットに送信されます。この時点で、ユーザーはトランザクションを行う意思を確認するためにポップアップウィンドウが表示されます。このポップアップにはトランザクションの結果のシミュレーションが含まれる場合があります。署名された後、トランザクションメッセージと署名がアプリに返され、その後、アプリはトランザクションを自分自身のRPCプロバイダーに転送するか、またはウォレットのプロバイダーを使用して転送できます。

RPC（Remote Procedure Call）プロバイダーは、アプリケーションとブロックを構築するバリデーターとの間の仲介者として機能します。これは、アプリケーションが可能にする必須のサービスです提出するまたは署名されたトランザクションをシミュレートし、効率的にオンチェーンデータを取得します。ネットワークとやり取りしたいアプリケーションは、JSON-RPCエンドポイントまたはWebSocketエンドポイントを介して行います（ドキュメント).

思い出

Solanaでの「失敗したトランザクション」という用語は誤解を招き、かなりの混乱を引き起こしています。これらのトランザクションは手数料が発生し、サインされた通りにランタイムによって正常に実行されます。これらはトランザクション自体のロジックによって「失敗」します。 「失敗した」トランザクションのうち80％は、スリッページ量を超えるためのコードである0x1771のエラーコードから発生しています。データ). 特に、これらの取引の95%は、アクティブなSolanaアドレスのわずか0.1%によって提出されており、主に時間的に敏感な価格の裁定機会を利用しようとする自動化されたボットです。

Gulf Stream

「ソラナの目標は文字通り、ニュースが世界中を駆け巡る速さで取引を行うことです-つまり、光ファイバーを通過する光速です。 我々が競争している相手はNASDAQとニューヨーク証券取引所です。」-アナトリー・ヤコヴェンコ、ソラナ共同創設者

RPC（Remote Procedure Calls）はRPCノードを指します。これらのノードは、ネットワークからデータを読み取りややり取りするためのゲートウェイと考えることができます。これらはフルバリデーターと同じソフトウェアを実行していますが、異なる設定で実行されており、トランザクションを正確にシミュレートし、現在の状態の最新ビューを維持することができます。現時点では、Solanaネットワークには4,000を超えるRPCノードがあります。

完全な検証ノードとは異なり、RPCノードにはネットワークにステークを保有することはありません。ステークがないため、投票やブロックの構築はできません。この設定は、ほとんどの他のブロックチェーンとは異なります。そこでは、検証ノードとRPCノードが通常は同じです。RPCノードはステーキング報酬を受け取らないため、Solanaアプリケーションを実行する開発者向けの有料サービスとして運営される多くのバリデータとは異なる経済的な側面があります。

Solanaは、最初からメモリプールなしで動作するよう設計されているため、注目されています。ネットワーク全体にトランザクションをランダムかつ広く伝播させるためにゴシッププロトコルを使用する従来のブロックチェーンとは異なり、Solanaはすべてのトランザクションを事前に決められたリードバリデータ、つまり各スロットのリーダーに転送します。

コールアウト

ソラナは4つのクラスタを運用しています: ローカルネット、テストネット、デブネット、そしてメインネット-ベータ。ソラナやソラナネットワークに言及する際、ほとんどの場合、メインネット-ベータを指します。メインネット-ベータはトークンが実際の価値を持つ唯一のクラスタであり、他のクラスタはテスト目的でのみ使用されます。

RPCがブロックに含める取引メッセージを受信すると、リーダーに転送しなければなりません。リーダースケジュールは、各エポック（おおよそ2日ごと）の前に生成されます。次のエポックはスロットに分割され、各スロットは400ミリ秒で固定され、各スロットにリーダーが選ばれます。より高いステークを持つ検証者は、各エポック内でより頻繁にリーダーに選ばれます。各スロットでは、取引メッセージがリーダーに転送され、リーダーはブロックを生成する機会があります。検証者の番が回ってきたとき、彼らは「リーダーモード」に切り替わり、積極的に取引を処理し、ブロックをネットワークの他の部分にブロードキャストします。

ステークウェイト付きサービス品質 - SWQoS

2024年初頭、Solanaはスパムの防止とシビル耐性の向上を目的とした新しいメカニズム、「Stake-Weighted Quality of Service（SWQoS）」を導入しました。このシステムにより、リーダーは他のステークを持つバリデータを介してプロキシされたトランザクションメッセージを優先順位付けすることができます。ここでは、より高いステークを持つバリデータには、トランザクションメッセージパケットをリーダーに送信する能力が比例して与えられます。このアプローチにより、ネットワーク全体の非ステークノードからのシビル攻撃を効果的に緩和します。

このモデルでは、バリデータは、RPCノードにステーク重み付け容量をリースするための契約にも参加できます。その見返りとして、RPCノードは増加した帯域幅を得て、ブロック内での取引含有率を向上させることができます。特筆すべきは、リーダーの容量の80％（2,000接続）がSWQoS用に予約されていることです。残りの20％（500接続）は、ステークされていないノードからの取引メッセージ用に割り当てられています。この割り当て戦略は、高速道路の優先レーンに似ており、ドライバーは渋滞を避けるために通行料を支払います。

SWQoSは、トランザクションをリーダーに転送する要件を引き上げ、スパム攻撃の効果を低下させることで、Solanaエコシステムに影響を与えています。この変更により、高トラフィックのアプリケーションは、自らのバリデータノードを運用するか、ステーク済みの接続にアクセスすることで、リーダーへの特権アクセスを確保し、トランザクション処理能力を向上させることができます。

QUICノート

2022年末、Solanaは採用しましたQUICネットワーキングプロトコルリーダーへのトランザクションメッセージ送信を管理します。この移行は、ボットがチェーン上のNFTミントにスパムを送信し、ネットワークの混乱を引き起こしたことによって促されました。QUICは迅速で非同期な通信を容易にします。

最初に開発されましたGoogle2012年にQUICは両方の利点を提供しようと試みました。それはUDPと同様の迅速で非同期の通信を容易にし、しかしTCPの安全なセッションと高度なフロー制御戦略を備えています。これにより、トラフィックの個々のソースに制限を設けることができ、ネットワークは本物のトランザクションの処理に集中できます。また、独立したストリームのコンセプトを持っているため、1つのトランザクションがドロップされても、残りのトランザクションをブロックする必要はありません。要するに、QUICはTCPとUDPの最良の特性を組み合わせようとする試みと考えることができます。

コールアウトボックス

ステークウェイトは、ソラナのシステム全体に見られる繰り返し原則であり、投票報酬、タービンツリー、リーダースケジュール、ガルフストリーム、およびゴシップネットワークを包括しています。より多くのステークを持つ検証者は、より高い信頼とネットワーク内での優先された役割が与えられます。

ブロックビルディング

「現時点で、SVM（Solana Virtual Machine）は仮想マシン技術の中で最も優れていると考えています。」- Andre Cronje、Fantom Foundation

多くのブロックチェーンネットワークは、離散的なブロック構築として知られる、完全なブロックを構築してからブロードキャストします。それに対して、Solanaは、割り当てられた時間枠中に作成されるブロックを動的に組み立ててストリーミングする、連続的なブロック構築を採用しており、遅延を大幅に削減しています。

各スロットは400ミリ秒続き、各リーダーは次のリーダーに交代する前に4つの連続したスロット（1.6秒）が割り当てられます。ブロックが受け入れられるためには、それに含まれるすべての取引が有効であり、他のノードによって再現可能である必要があります。

リーダーシップを引き継ぐ2つのスロット前に、バリデータはその来るべき作業の準備のためにトランザクションの転送を停止します。この間、インバウンドトラフィックが急増し、ネットワーク全体がパケットを着信リーダーに向けて1秒あたり1ギガバイト以上に達します。

受信後、トランザクションメッセージはブロックの生成を担当するバリデータのコアロジックであるトランザクション処理ユニット（TPU）に入ります。ここでは、トランザクション処理シーケンスはフェッチステージから始まり、QUICを介してトランザクションが受信されます。その後、トランザクションはSigVerifyステージに進み、厳密な検証チェックを受けます。ここでは、バリデータは署名の有効性を確認し、正しい署名の数を確認し、重複するトランザクションを排除します。

バンキング ステージ

銀行業はブロック構築段階として説明できます。これは、「銀行」からその名前を取ったTPUの最も重要な段階です。銀行は単なる特定のブロックの状態です。各ブロックについて、Solanaにはそのブロックの状態にアクセスするために使用される銀行があります。十分なバリデータがそのブロックに投票した後、ブロックは最終化され、銀行からディスクにアカウントの更新がフラッシュされ、それらは永続的になります。チェーンの最終状態はすべての確認済みトランザクションの結果です。この状態は常にブロックチェーンの履歴から決定論的に再作成できます。

トランザクションは並列で処理され、それぞれが64の競合しないトランザクションのバッチである「エントリー」にパッケージ化されます。Solana上の並列トランザクション処理は容易に行われます。なぜなら、各トランザクションは読み取りおよび書き込みを行うすべてのアカウントの完全なリストを含める必要があるからです。この設計の選択肢は開発者に負担をかけますが、検証者は各エントリー内で競合しないトランザクションのみを簡単に選択して実行することで競合状態を回避することができます。トランザクションは、同じアカウントに書き込もうとする場合（2回の書き込み）または1つが同じアカウントから読み取ろうとし、もう1つが書き込もうとする場合（読み取り+書き込み）に競合します。したがって、競合するトランザクションは異なるエントリーに入り、順次実行されます。一方、競合しないトランザクションは並列で実行されます。

トランザクション処理を並列で行うスレッドが6つあり、そのうち4つは通常のトランザクションに専念し、2つはSolanaのコンセンサスメカニズムに不可欠な投票トランザクションのみを処理しています。処理のすべての並列化は複数のCPUコアを介して達成されます。バリデーターにはGPUの要件はありません。ドキュメント。

トランザクションがエントリにグループ化されると、それらはSolana Virtual Machine（SVM）によって実行される準備が整います。 トランザクションに必要なアカウントはロックされます。トランザクションが最近のものであることが確認されますが、すでに処理されていないことも確認されます。 アカウントがロードされ、トランザクションロジックが実行され、アカウントの状態が更新されます。 エントリのハッシュは、記録するためにProof of Historyサービスに送信されます（次のセクションで詳しく説明します）。 記録プロセスが成功すると、すべての変更が銀行にコミットされ、最初のステップで各アカウントに配置されたロックが解除されます。 実行はSVMによって行われ、Solanaのフォークを使用して構築された仮想マシンです。rBPF, JITコンパイルと、eBPFプログラムのための仮想マシンで動作するライブラリです。Solanaはブロック内のトランザクションの順序付けを検証者がどのように選択するかを指示しません。この柔軟性は、後にこのレポートのEconomics + Jitoセクションで再度取り上げる重要なポイントです。

覚えています

用語SVMは曖昧であり、それは「Solana Virtual Machine」または「Sealevel Virtual Machine」のいずれかを指す可能性があるため、両方の用語はSolanaのランタイム環境の名前であるSealevelを含め、同じ概念を説明します。最近の努力にもかかわらず、用語SVMは依然として適切に扱われていないことに注意が必要です。その境界を定義する.

クライアント

ソラナは、千を超える独立して運営されているノードが協力して、単一の統合された台帳を維持するネットワークです。各ノードは、『クライアント』として知られる同じオープンソースソフトウェアを実行する高性能マシンを構成しています。

ソラナは、最初はSolana Labsクライアントとして知られる単一のバリデータクライアントソフトウェアでローンチされました。アガベクライアントRustで書かれた。クライアントの多様性拡大は常に優先事項であり、それは本当に果たされるであろう、ソラナの発売と共に。Firedancer clientFiredancerは、元のクライアントをCプログラミング言語で完全に書き直したものです。ハイ・フリークエンシー・トレーディング企業Jumpの経験豊富なチームによって作成され、任意のブロックチェーンで最も高性能な検証クライアントになることを約束しています。

Proof of History

「私はコーヒーを2杯飲んでビールを1杯飲んだので、午前4時まで起きていました。同じSHA-256の事前画像耐性ハッシュ関数を使用したプルーフ・オブ・ワークに似たパズルに関するこのアイデアがひらめいた...私は時間の矢を持っているとわかりました。」- ソラナ共同創設者、アナトリー・ヤコベンコ

Proof of History (PoH)はSolanaの秘密のソースであり、ネットワーク全体での同期を容易にする各バリデータ内の特別なクロックのように機能します。PoHはイベントの順序と時間の経過の信頼性のある情報源を確立します。最も重要なのは、リーダースケジュールへの遵守を確保します。類似した名前であるにもかかわらず、Proof of HistoryはProof of Workのようなコンセンサスアルゴリズムではありません。

ノード間の通信オーバーヘッドは、通常、ネットワークが拡大するにつれて増加し、調整がますます複雑になります。Solanaは、ノード間通信をPoHローカル計算で置き換えることで、これを緩和します。これにより、検証者は単一の投票ラウンドでブロックにコミットできます。メッセージ中の信頼されたタイムスタンプにより、検証者が互いに重なり合うことなくブロックを早めに開始することはできません。

PoHの基本となるのは、ハッシングアルゴリズムの固有の特性です。SHA256:

• データ指向: 同じ入力は常に同じハッシュを生成します。
• 固定サイズ: 入力サイズに関係なく、出力ハッシュは常に256ビットです。
• 効率的: 任意の入力に対するハッシュを計算するのは速いです。
• 事前イメージ耐性: ハッシュ出力から元の入力を見つけることは、計算上不可能です。
• アバランチ効果：入力のわずかな変更（たとえ1ビットでも）でも、大幅に異なるハッシュが生成されるという特性、これをアバランチ効果と呼びます。
• 衝突耐性: 同じハッシュ出力を生成する2つの異なる入力を見つけることは不可能です。

各検証者クライアント内で、専用の「履歴の証明サービス」が継続的にSHA256ハッシュアルゴリズムを実行し、ハッシュの連鎖を作成しています。各ハッシュの入力は前のハッシュの出力です。この連鎖は検証可能な遅延関数と同じように機能し、ハッシュの作業は順次行われなければならず、将来のハッシュの結果は事前にはわからない必要があります。PoHサービスが千のハッシュの連鎖を作成した場合、それぞれのハッシュを順次計算するために時間が経過したことがわかります。これは「マイクロプルーフオブワーク」と考えることができます。ただし、他の検証者は、各ハッシュの入出力がネットワークにブロードキャストされているため、将来のハッシュの結果が事前にわからないため、千のハッシュの正確性を並行してより早い速度で検証できます。したがって、PoHを生成することは難しいですが、検証することは簡単です。

異なるCPU上でのSHA-256の計算性能の範囲は驚くほど狭く、最速のマシンの間にはわずかな違いしかありません。ビットコインがこれに依存しているため、この機能を最適化するために多くの時間と労力が費やされてきましたが、既に一般的な上限に達しています。

リーダーのスロット中、PoHサービスは銀行段階から新しく処理されたエントリを受け取ります。現在のPoHハッシュにエントリ内のすべての取引のハッシュを加え、次のPoHハッシュに組み合わせます。これは取引が処理された順序を証明するハッシュチェーンにエントリを挿入するタイムスタンプとして機能します。このプロセスは時間の経過を確認するだけでなく、取引の暗号記録としても機能します。

1ブロックには、800,000のハッシュが含まれています。 PoHストリームには、リーダーの生存性と時間の経過を示す空のエントリである「ティック」も含まれています。 ティックは6.25ミリ秒ごとに発生し、1ブロックあたり64のティックが発生し、合計ブロック時間は400ミリ秒です。

バリデータは、リーダーでない場合でもPoHクロックを常に実行し続け、ノード間の同期プロセスにおいて重要な役割を果たしています。

思い出す

PoHの主な利点は、ブロックプロデューサーがオフラインであっても正しいリーダースケジュールに従わなければならないことを保証することです。これは「不履行」として知られる状態です。 PoHは、悪意のある検証者が自分の番になる前にブロックを生成するのを防ぎます。

アカウントモデル

「SVMのコードと状態を分離することは、最高の設計上の決定でした。この概念を私の脳に信仰深く刻み込んでくれた組み込みシステム開発者に祝福があります。」- アナトリー・ヤコヴェンコ、Solana共同創設者

Solanaバリデータ内では、AccountsDBとして知られるアカウントデータベースでグローバルステートが維持されます。このデータベースはメモリとディスクの両方にすべてのアカウントを格納する責任があります。アカウントインデックスの主要なデータ構造はハッシュマップであり、AccountsDBは実質的には広範なものです。キーバリューストアここでは、キーはアカウントアドレスであり、値はアカウントデータです。

時間とともに、ソラナのアカウント数は数億に急増しました。この多くの数は、ソラナの開発者が言うように、「ソラナ上のすべてがアカウントである」ということの一部です。

ソラナアカウント

アカウントは、コンピュータ上のファイルに類似したデータを永続的に保持するコンテナです。さまざまな形式で提供されています:

• ユーザーアカウント：これらのアカウントにはプライベートキーがあり、通常、ユーザーのためにウォレットソフトウェアによって生成されます。
• データアカウント：これらのアカウントは、ユーザーが保持している特定トークンの数など、状態情報を保存します。
• Program accounts: これは実行可能なバイトコードを含む大きなアカウントであり、Windowsの.exeファイルやMacの.appファイルに若干相当します。
• ネイティブプログラムアカウント：これらはネットワークのさまざまなコア機能を実行する特別な事前展開されたプログラムアカウントです。例Vote ProgramとBPF Loaderを含める。

すべてのアカウントには、次のフィールドがあります：

プログラム

Solanaプログラムアカウントには実行可能なロジックのみが含まれています。つまり、プログラムが実行されると、他のアカウントの状態を変異させますが、それ自体は変わりません。このコードと状態の分離は、Solanaを他のブロックチェーンと区別し、その多くの最適化をサポートしています。開発者は主に、汎用プログラミング言語であるRustでこれらのプログラムを記述しています既知セーフティとパフォーマンスに強い焦点を当てています。さらに、TypeScriptとPythonの複数のSDKが利用可能で、アプリケーションのフロントエンドの作成を容易にし、ネットワークとのプログラム的なやり取りを可能にします。

多くの一般的な機能は、ネイティブプログラムによって箱から提供されます。たとえば、Solanaは、開発者にコードを展開してトークンを作成することを要求しません。その代わりに、指示は、トークンのメタデータを格納するアカウントを設定するために事前に展開されたネイティブプログラムに送信されます。

家賃

レントは、ユーザーに口座を閉じるように促すために設計されたメカニズムです。状態の膨張を減らすためのものです。新しい口座を作成するには、口座に保持されているSOLとして知られる最低残高、つまり「レント免除」金額が必要です。これは、バリデータのメモリ内で口座を維持するために発生するストレージコストと考えることができます。口座のデータサイズが増加すると、最低残高のレント要件も比例して増加します。口座が不要になった場合、口座を閉じることができ、レントは口座所有者に返金されます。

例えば、ユーザーがドル建てのステーブルコインを保有している場合、この状態はトークンアカウントに格納されます。現在、トークンアカウントの家賃免除額は0.002 SOLです。ユーザーが全体のステーブルコイン残高を友達に送金する場合、トークンアカウントを閉じることができ、ユーザーは0.002 SOLを返金されます。プログラムはしばしばユーザーのためにアカウントのクローズを自動的に処理します。古く使用されていないアカウントを整理し、それらに格納されている少額のSOLを回収するのを手助けするいくつかのアプリケーションが利用可能です。

所有権

アカウントデータを読むことは普遍的に許可されていますが、Solanaの所有モデルは、アカウントのデータを変更（書き込み）できるのは正確に誰かを制限することでセキュリティを向上させています。この概念は、Solanaブロックチェーン上でルールや権限を強制するために極めて重要です。すべてのアカウントにはプログラム「オーナー」があります。アカウントのオーナーはその管理を担当し、認可されたプログラムだけがアカウントのデータを変更できるようにします。このルールの注目すべき例外は、lamports（SOLの最小単位）の転送です。アカウントのlamports残高を増やすことは所有権に関係なく普遍的に許可されています。

状態の保管

Solanaプログラムは読み取り専用の実行可能ファイルであるため、「プログラムデリバードアドレス」（PDAs）を使用して状態を保存する必要があります。PDAsは特定のユーザーではなくプログラムに関連付けられ、所有される特別なタイプのアカウントです。通常のSolanaユーザーアドレスはEd25519キーペアの公開キーから派生していますが、PDAsには秘密鍵がありません。その代わりに、彼らの公開キーは、所有するプログラムのプログラムID（アドレス）と一緒にパラメーター（しばしばキーワードや他のアカウントアドレス）の組み合わせから派生しています。

PDAアドレスは通常のアドレスのようにEd25519曲線上にないため、「オフカーブ」に存在します。 PDAを所有するプログラムだけが、それに対してプログラム的に署名を生成でき、PDAの状態を変更できる唯一のものであることを保証します。

上記：Solanaトークンアカウントは、プログラム派生アドレス（PDAs）の具体的な例です。これらはトークンを保持し、“曲線外”で運用されます。関連トークンアカウント（ATA）プログラムにより、各ウォレットは各トークンタイプに対して関連するトークンアカウントを1つだけ持つことができ、トークンアカウントを管理する標準化された方法を提供します。

タービン

「Solanaの最も興味深い部分は、並列化、SVM、またはTolyのツイートではありません。おそらく聞いたことのないものがあります：タービン。」— Mert Mumtaz、Helius

銀行業務段階では、取引はエントリに整理され、タイムスタンプのために履歴の証明ストリームに送信されます。ブロックの銀行が更新され、エントリは次の段階であるタービンの準備が整いました。

タービンは、リーダーが自分のブロックをネットワーク全体に伝播させるプロセスです。インスパイアBitTorrentは、高速かつ効率的に設計されているため、通信のオーバーヘッドが削減され、リーダーが送信する必要があるデータの量が最小限に抑えられます。

Turbineは、トランザクションデータを「シュレッド」と呼ばれるプロセスを通じて小さなデータパケットに分解することによってこれを実現します。 シュレッドとは、個々のビデオストリームのフレームに類似した、最大1280バイトの小さなデータパケットです。 これらのシュレッドを再構成すると、バリデータは全体のブロックを再生できます。 シュレッドは、UDPを使用してバリデータ間でインターネットを介して送信され、パケットロスや悪意のあるパケットの削除を処理するために消し去り符号化を利用します。イレイシャコーディング, a多項式ベースのエラー検出および訂正スキームは、データの整合性を保証します。いくつかの断片が失われても、ブロックは再構築できます。

シュレッドは、フォワードエラーコレクション（FEC）バッチとしてグループ化されます。デフォルトでは、これらのバッチは64個のシュレッド（32個のデータシュレッド+32個のリカバリシュレッド）で構成されています。データのリカバリはFECバッチごとに行われ、つまりバッチ内のパケットの最大半分が失われたり破損しても、すべてのデータを復旧できます。各64シュレッドのバッチは、リーダーによって署名されたルートでメルカライズされ、前のバッチにチェーンされます。このプロセスにより、シュレッドはそれらを所有するネットワーク内の任意のノードから安全に取得できます。メルケルルートのチェーンにより、確認可能な認証と整合性の経路が提供されます。

リーダーは最初に単一のルートノードにブロードキャストし、その後、そのノードが他のすべての検証ノードにシュレッドを拡散します。このルートノードは各シュレッドごとに変更されます。検証者は「タービンツリー」を形成するレイヤーに組織されています。より大きなステーク額を持つ検証者は通常、ツリーのトップに配置され、より小さなステークを持つ検証者は通常、ツリーの底に配置されています。

ツリーは通常、アクティブなバリデータの数に応じて2または3ホップに広がります。視覚的なシンプリシティのために、上記ではファンアウト3が描かれていますが、Solanaの実際のファンアウト値は現在200に設定されています。セキュリティ上の理由から、ツリーの順序は各新しいシュレッドのバッチごとに回転します。

そのようなシステムの主な目標は、リーダーおよびルートノードのアウトバウンドデータ脱出圧を緩和することです。送信と再送信のシステムを利用することで、負荷がリーダーと再送信者の間で分散され、単一ノードへの負荷が軽減されます。

コンセンサス

「ソラナには熱心なスマートな開発者コミュニティがあると賢い人たちが私に伝えてくれました... コミュニティが繁栄するために公平なチャンスを得られることを願っています」と、イーサリアムの共同創設者ヴィタリック・ブテリンは述べています

バリデータがリーダーからTurbine経由で新しいブロックを受信すると、それぞれのエントリ内のすべてのトランザクションを検証する必要があります。これには、ブロック全体を再生し、PoHハッシュを並行して検証し、PoHによって指示された順序でトランザクションを再作成し、ローカルバンクを更新する作業が含まれます。

このプロセスは、リーダーのトランザクション処理ユニット (TPU) に類似したトランザクション検証ユニット (TVU) によって処理され、シュレッドとブロック検証の処理を担当するコア ロジックとして機能します。TPU と同様に、TVU フローはいくつかの段階に分かれており、Turbine で細断が受信される Shred Fetch Stage から始まります。その後の Shred Verify Leader Signature ステージでは、シュレッドは複数のサニティ チェック、特にリーダーの署名の検証を受け、受信したシュレッドがリーダーから発信されたことを確認します。

再送信段階では、バリデータはタービンツリー内の位置に基づいて、シュレッドを適切な下流バリデータに転送します。再生段階では、バリデータは各トランザクションを正確に再作成し、正しい順序で更新しながら、銀行のローカルバージョンを更新します。

Replay StageはTPUのバンキングステージに類似しており、最も重要なステージであり、ブロック検証ステージとより直接的に表現できます。Replayは、投票、PoHクロックのリセット、銀行の切り替えなど、多くの重要な操作を組み立てるシングルスレッドプロセスループです。

上記：リプレイステージは、バリデータをリーダーモードに切り替え、ブロックの生成を開始する責任があります。オリジナルビジュアル：Justin Starry、Anza

コンセンサス

コンセンサスを達成するために、SolanaはTower BFT（TBFT）を使用しており、これはよく知られたPracticalのカスタム実装ですビザンティン障害Tolerance (PBFT) algorithm, commonly used by most blockchains to agree on the state of the chain. Like all blockchains, Solana assumes the presence of malicious nodes in the network, so the system must withstand not only node failures but also certain levels of attacks.

Tower BFTは、ポブ・オブ・ヒストリーによって提供される同期クロックを活用することで、他のチェーンと差別化しています。従来のPBFTでは、トランザクションの順序に合意するために複数の通信ラウンドが必要ですが、Solanaノードは事前に確立されたイベントの順序を利用しており、メッセージングのオーバーヘッドを大幅に削減しています。

投票

コンセンサスに参加して報酬を獲得するために、バリデータは有効であると信じるブロックに投票を提出します（つまり、二重支出や不正な署名などの問題がない）​​、および正規のユーザートランザクションと一緒にブロックに含まれるべきであると考えます。 バリデータはこれらの投票に対して取引手数料を支払い、リーダーによって処理され、通常のユーザートランザクションと一緒にブロックに含まれます。 これがSolanaトランザクションが投票トランザクションと非投票トランザクションに頻繁に分類される理由です。 バリデータが正確かつ成功した投票を行うと、クレジットを獲得します。 このメカニズムにより、バリデータは含まれる可能性が最も高いと考えるフォークに投票することが奨励されます、つまり、「最も重い」フォークです。

フォーク

ソラナの設計の一部である速さは、ネットワークが次のブロックを生成する前にすべての検証者が新しく生成されたブロックに同意するのを待たないためです。その結果、異なる2つのブロックが同じ親ブロックにリンクされることがよくあり、フォークが作成されます。

ソラナの検証者はこれらのフォークに投票し、採用するフォークを決定するために合意アルゴリズムを使用しなければなりません。競合するフォークが存在する場合、ネットワークによって最終的に確定されるのは1つのフォークのみであり、廃棄されたフォークのブロックは放棄されます。

各スロットには事前に決められたリーダーがおり、そのリーダーのブロックのみが受け入れられます。したがって、1つのスロットに対して提案されたブロックは2つ存在することはできません。したがって、潜在的なフォークの数は、リーダーのローテーションスロットの境界で発生するフォークの「ある/ない」スキップリストに限定されます。バリデータがフォークを選択すると、ロックアウト時間が切れるまでこのフォークにコミットされ、つまり最低限の期間この選択を守らなければなりません。

Solanaの「スキップ率」—ブロックが生成されなかったスロットの割合—は、2%から10%の範囲で変動し、フォークがこれらのスキップされたスロットの主な原因です。スキップされたスロットの他の可能性の原因には、新しいエポックの開始、リーダーのオフライン、または無効なブロックの生成が挙げられます。

覚えています

Solanaの取引の状態は、合意プロセスの現在の段階に応じて異なります:

• 処理済み：トランザクションはブロックに含まれています。

• 確認済み：取引のブロックは3分の2の過半数で投票されました。

• 完了：取引ブロックの上に31以上のブロックが構築されました。

今まで、ソラナの歴史で（楽観的に）確認されたブロックが最終化されなかったという事例はありません。

各ブロックごとに、Solanaはそのブロックでの状態にアクセスするために銀行を使用します。銀行が確定されると、その銀行およびその祖先のアカウントの更新がディスクにフラッシュされます。さらに、確定された銀行の祖先ではない以前の銀行からのアカウントの更新は削除されます。このプロセスにより、Solanaは効率的に複数の潜在的な状態を維持できます。

ゴシップ+アーカイブ

「ブロックチェーンには暗号技術、分散システム、オペレーティングシステム、プログラミング言語を巧みに組み合わせる必要があります。 Solanaのスーパーパワーは、各分野の最も興味深い問題から逃げ出すことへの意欲でした。」- Greg Fitzgerald、Solana共同創業者

ゴシップ

ゴシップネットワークは、コントロールプレーンSolanaネットワーク向けのものです。トランザクションフローを処理するデータプレーンとは異なり、コントロールプレーンは、連絡先情報、台帳の高さ、および投票情報など、ブロックチェーンの状態に関する重要なメタデータを伝達します。ゴシップがないと、バリデータとRPCは、さまざまなサービス間で通信するために開いているアドレスとポートを知ることができません。新しいノードもネットワークに参加するためには、ゴシップに頼る必要があります。

Solanaのゴシッププロトコルは、変更されたPlumTreeアルゴリズムに触発されたツリーブロードキャストアプローチを使用した非公式なピアツーピア通信を利用しています。この方法は、どんな中央ソースにも依存せずに情報を効率的に伝播します。

ゴシップは、ほとんどの他の検証コンポーネントとは独立したシステムとして機能します。検証ノードとRPCは、UDPを介してゴシップを通じて0.1秒ごとに署名済みデータオブジェクトを共有し、ネットワーク全体で情報を利用できるようにしています。すべてのゴシップメッセージは、コードベースでは「パケット構造」と呼ばれる1280バイトの最大転送単位（MTU）以下でなければなりません。

ゴシップレコードはノード間で共有される実際のデータオブジェクトです。約10種類の異なるタイプのレコードがあり、それぞれ異なる目的を果たしています。ゴシップレコードは整合性と通貨を確保するために署名され、バージョン管理され、タイムスタンプが付けられています。

ゴシップメッセージには4種類のタイプがあります:

• プッシュ：最も一般的なメッセージ、一部の「プッシュピア」と情報を共有します。
• プル＆プルレスポンス：定期的に未受信メッセージを確認し、プルレスポンスが情報を返信してノードが持っていないことを知らせます。
• Prune: ノードが保持する接続の数を選択的に削減することを可能にします。
• Ping＆Pong：ノードのヘルスチェック- pingが送信されると、ポングが返ってくることが期待され、ピアノードがまだアクティブであることを示します。

ゴシップデータはクラスタレプリケーションデータストア（CrdsTable）に保存されます。このデータ構造は非常に大きくなる可能性があり、定期的に刈り込む必要があります。

アーカイブ

Solanaは、他のブロックチェーンとは異なり、アカウントの現在の状態を決定するために全履歴を必要としません。Solanaのアカウントモデルは、任意のスロットでの状態が既知であることを確認し、バリデータはすべての過去のブロックを処理せずに各アカウントの現在の状態を保存できます。RPCやバリデータは、設計上、全履歴を保持しません。代わりに、通常、トランザクションデータの1つまたは2つのエポック（2〜4日分）だけを保存し、それがチェーンの先端を検証するのに十分です。

アーカイブは、現在、「ウェアハウスノード」によって管理されています。これは、プロのRPCサービスプロバイダやSolana財団、および取引履歴の提供を望む他のエコシステムの参加者によって運営されています。ウェアハウスノードは、通常、次のいずれか、または両方を維持しています。

1. レジャーアーカイブ：スクラッチから再生可能な生の台帳とAccountsDBスナップショットをアップロードします。

2. Google Bigtableインスタンス：ジェネシスブロック以降のブロックデータを格納し、RPCリクエストを処理するためにフォーマットされます。

エコノミクス + Jito

「人々は、Solanaが今日利用可能な中で唯一、メインストリームの消費者向けアプリをサポートする唯一のチェーンであることに気づいています。」— Ted Livingston, Code創設者

ソラナは、新しいSOLトークンを各エポックで生成することによってステーキング報酬を分配するためにインフレを採用しています。このプロセスにより、非ステーカーのネットワークシェアがステーカーに比べて減少し、非ステーカーからステーカーへの富の移転が引き起こされます。インフレは、2021年初頭に8%の初期率で開始され、年率15%ずつ減少して、長期的な率である1.5%で安定するまで続きます。

任意のSOLトークン保有者は、1つ以上のバリデータにトークンをステーキングしてネットワークを安全に保護し、報酬を得ることができます。バリデータにトークンを割り当てることは、委任として知られています。バリデータにトークンを委任することは、そのバリデータに対する信頼を示します。しかし、これによりバリデータにトークンの所有権や制御権が与えられるわけではありません。すべてのステーキング、アンステーキング、および委任アクションは、次の新しいエポックの開始時に実行されます。

‍

投票報酬

バリデータが投票を提出すると、投票が正確で成功した場合にクレジットを獲得します。投票トランザクションのコストは0.000005 SOLで、優先手数料は免除されます。投票費用は、バリデータ1人当たり1日あたり約1 SOLに相当し、バリデータの運営コストの主たるものとなります。エポック全体で、バリデータは投票によってクレジットを蓄積し、エポックの最後にそのクレジットをインフレーションの一部と交換することができます。

トップパフォーマンスの検証者は、スロットの約90%に成功投票します。ブロックのないスロットの割合（スキップされたスロット率）は、2%から10%以上に及び、これらのスロットには投票できません。平均検証者は、約80%のスロットに成功して投票し、432,000スロットのエポックで345,600クレジットを獲得します。

インフレーション総額はまず、エポックで獲得したクレジットに基づいて分割されます。 各検証者の総クレジットに対する検証者のクレジットの割合（検証者のクレジットをすべての検証者のクレジットの合計で割ったもの）が、その比例報酬を決定します。 さらにこれにステークによる重み付けが行われます。

したがって、合計ステークの1%を持つ検証者は、平均クレジット数を持っている場合、合計インフレーションの約1%を獲得するはずです。 クレジット数が平均よりも高いか低い場合、その報酬はそれに応じて変動します。

投票パフォーマンスの違いは、検証者がステーカーに提供するリターン（APYで測定）が異なる理由の1つです。 もう1つの要因は、検証者が請求する手数料率で、これは彼らの検証者に向けられた総インフレ報酬の一部です。 さらに、検証者がオフラインまたはブロックチェーンと同期していない（怠慢として知られています）ことは、リターンに大きな影響を与えます。

ブロック報酬

特定のブロックのリーダーとして指定された検証者は、追加のブロック報酬を受け取ります。これらの報酬は、ブロック内のすべての取引のベース手数料の50%と優先手数料の50%で構成され、残りの手数料は燃やされます。ブロックを生成した検証者だけがこれらの報酬を受け取ります。エポックごとに分配されるステーキング報酬とは異なり、ブロック報酬はブロックが生成されるとすぐに検証者のアイデンティティアカウントに入金されます。

リキッドステーキング

リキッドステーキングは、ネイティブステーキングに対する人気のある代替手段となっています。参加者は、ステーキングされたSOLの代わりに、リキッドステーキングトークン（LST）またはリキッドステーキングデリバティブ（LSD）として知られるトークンを受け取ります。通常は、複数のバリデータにトークンを委任するステークプールで、新たに受け取ったLSTトークンは、ユーザーのステークされたSOLのシェアを表します。これらのトークンは取引可能であり、アプリケーション間で使用したり、他のユーザーに送金する際も、ステーキング報酬を受け取りながら利用できます。このシステムの主な利点は、資本効率を大幅に向上させることです。

LSTの価格=（プールにステークされたSOLの総額* SOLの価格）/総発行LST

従来のネイティブステーキングでは、時間の経過とともに、ステーカーは直接的により多くのSOLを獲得します。一方、リキッドステーキングでは、報酬がプールに再投資され、LSTのファーバリューが増加します。基礎となるSOLに対してLSTを償還するメカニズムがある限り、アービトラージトレーダーはトークン価格が合理的であることを確認します。

Jito

執筆時点では、80％以上(ソースSolanaのステークのX％は、Jitoクライアントバリデーターソフトウェアを利用しています。このクライアントは、元のアガベクライアントのフォークであり、バリデーターにチップを通じて追加の経済的インセンティブを提供するプロトコル外のブロックスペースオークションを導入しています。この追加のインセンティブは、バリデーターの間でJitoクライアントの広範な採用の大きな要因です。

リーダーがJitoバリデータクライアントを使用すると、彼らのトランザクションは最初にJito-Relayerに送られます。このオープンソースソフトウェアはトランザクションプロキシルーターとして機能します。他のネットワークノードは、リーダーがゴシップネットワーク上で彼らのingress_socketとして広告したアドレスとポート構成にトランザクションを単純に送信するため、Jito-Relayerの存在を知らないままです。

リレーアは、リーダーに転送する前にすべての取引を200ミリ秒保持します。この「スピードバンプ」メカニズムは、取引メッセージの到着を遅らせ、オークションを実施するための短い時間枠を提供します。200ミリ秒後、リレーアはオークションの結果に関係なく、取引を楽観的にリリースします。

Blockspaceオークションは、Jito Block Engineを介してオフチェーンで行われ、サーチャーやアプリケーションがバンドルとして知られるアトミックに実行されるトランザクションのグループを送信できます。これらのバンドルには、アービトラージや清算などの時間的に敏感なトランザクションが通常含まれます。 Jitoは、すべてのチップに5％の手数料を請求し、最低チップは10,000ラムポートです。チップは、プロトコル外で完全に動作し、プロトコル内の優先度およびベース手数料とは別になっています。以前、Jitoはプロトコル外のメンプールサービスを提供していましたが、これは現在非推奨となっています。

免責事項：

1. この記事は[ から転載されましたhelius]. すべての著作権は元の著者に帰属します [Lostin]. If there are objections to this reprint, please contact the Gate Learnチームがすぐに対処します。
2. 責任の免責事項：この記事で表現されている意見や見解は、著者個人のものであり、投資アドバイスを構成するものではありません。
3. 他の言語への記事の翻訳は、Gate Learnチームによって行われます。特に断りがない限り、翻訳された記事のコピー、配布、または盗用は禁止されています。