決定論の境界で：Solana SealevelとSui Object Runtimeにおけるトランザクションのライフサイクル

ブロックチェーントランザクションのライフサイクルとは？

ブロックチェーンはトランザクションを処理します。トランザクションは状態、つまりブロックチェーン上のアカウントの更新後の状態に影響します。トランザクションのライフサイクルを理解することは、ブロックチェーンの設計思想を最も明確に把握する方法の一つです。スループットと安全性に向けた最適化、決定性の保証、相対的なエンジニアリングコスト、実環境で生じ得る問題点について、技術関係者に重要な知見を提供します。

以降のセクションでは、トランザクションが送信から確定までに通過する各段階と、そのプロセスが各チェーン内のさまざまなレベルで実行に与える影響を検証します。

Solanaのトランザクションライフサイクル

Solanaブロックチェーンは、コンセンサスメカニズムとしてProof-of-Stake（PoS）を、トランザクションを効率的に順序付ける計時メカニズムとしてProof-of-History（PoH）を利用する独自設計に基づいています。

Solanaの設計モデルはアカウント中心です。これは「Solana上のすべてはアカウントである」ということでもあります。

アカウントは、状態や実行可能バイナリ（プログラムコード）を含むデータの保存に使用されます。トランザクションには、アカウントの状態を変更する命令が含まれます。トランザクション処理を伴うネットワークのコンセンサスに参加するノードは、バリデータと呼ばれます。アカウントを変更するためにトランザクションを処理するプロセスはパイプライン処理と呼ばれ、ライフサイクル内でトランザクションが位置する各処理点はステージと呼ばれます。

Solanaトランザクション

Solanaにおけるトランザクションは、Messageのアカウントキーの先頭キーによって署名された、シリアライズ済みメッセージの署名セットです。

トランザクション内のメッセージは、ヘッダー、アカウントキー、直近のブロックハッシュ、命令を含むデータ構造です。ヘッダーにはMessageHeaderが含まれ、Messageのアカウントキーの構成を記述します。

各命令は、アクセス可能なアカウントと、それぞれに必要な権限を明示的に定義します。これらの権限は、アカウントが読み取り専用か読み書き可能か、またその命令を含むトランザクションへの署名が必要かを示します。

pub struct Message {
pub header: MessageHeader,
pub account_keys: Vec<Pubkey>,
pub recent_blockhash: Hash,
pub instructions: Vec<CompiledInstruction>,
}

個々の命令には、アクセスする可能性があるすべてのアカウントのリストと、各アカウントに必要な権限が含まれます。

Messageには、トランザクション内のすべての命令が必要とする全アカウントをまとめた、単一の共有フラットリストが含まれます。このフラットリストはMessageの構築時に作成され、命令は一連のCompiledInstructionsへ変換されます。これらのCompiledInstructionsは、必要なアカウントを単一の共有アカウントリストからインデックスで参照します。

共有アカウントリストは、アカウントに必要な権限に従って並べられます。

• 書き込み可能で署名者であるアカウント。
• 読み取り専用で署名者であるアカウント。
• 書き込み可能で署名者ではないアカウント。
• 読み取り専用で署名者ではないアカウント。

この順序に基づき、MessageHeaderのフィールドは、トランザクション内のどのアカウントにどの権限が必要かを記述します。

pub struct MessageHeader { 
pub num_required_signatures: u8,
pub num_readonly_signed_accounts: u8,
pub num_readonly_unsigned_accounts: u8,
}

複数のトランザクションが同じ読み取り専用アカウントにアクセスする場合、ランタイムはそれらを単一のPoHエントリ内で並列処理できます。同じ読み書き可能アカウントにアクセスするトランザクションは、順次処理されます。

トランザクションは、Solanaのトランザクション転送プロトコルであるGulf Streamを通じてクライアントに送信され、バリデータ内のTransaction Processing Unit（TPU）とTransaction Validation Unit（TVU）という、複数ステージからなる2つのパイプライン処理を経ます。

これらのプロセスはランタイムと連携し、異なるアカウント状態を変更するトランザクションを並列処理し、同じアカウント状態を変更するトランザクションを順次処理します。

TPUはバリデータがリーダーモード、つまりブロック生成中に動作し、TVUはバリデータがバリデータモード、つまりブロック検証中に動作します。どちらの場合も、ネットワーク入力、ディスクへの書き込み、ネットワーク出力など、パイプライン化されたハードウェアは類似しています。ただし、そのハードウェアで行う処理は異なります。簡単に言えば、TPUは台帳エントリの作成に使われ、TVUはエントリの検証に使われます。

全体像としては、トランザクションはクライアント経由で送信され、Gulf StreamからQUICを介してリーダーのTPUで処理されます。トランザクションは検証チェックを受け、バンキングステージによって実行スケジュールが決定されます。状態更新はBankのインメモリ状態に書き戻されます。バリデータはゴシップを通じてブロックに投票し、ステーク加重のロックアウトメカニズムを備えたPBFTの派生形であるTower BFTを使用してブロックを確定します。

Gulf Stream

多くのブロックチェーンでは、ユーザーが送信したトランザクションはmempool（文字どおり「メモリプール」）に「キューイング」され、ネットワークによる処理を待ちます。ネットワークが最適な状態でない場合や実行条件が満たされない場合、署名済みトランザクションはmempoolに長期間、場合によっては無期限に残り、どのブロックにも含まれないことがあります。

Solanaは、ステーク加重アルゴリズムの影響を受ける決定論的なリーダースケジュールに依存することで、グローバルmempoolを不要にしています。このアルゴリズムはStake-Weighted Quality of Service（SWQoS）と呼ばれ、ステークされたバリデータ経由でルーティングされるトランザクションメッセージを優先します。

リーダースケジュールはすべてのアクティブノードに事前に共有されるため、トランザクションメッセージを効率的に分散できます。これにより、次のリーダーはブロック生成の担当時刻より前に、処理に十分なトランザクションを受け取れます。また、バリデータは署名を検証し、重複または不正な形式のトランザクションを事前に排除することで、トランザクションを前処理できます。

Gulf Streamにはもう一つの利点があります。mempoolを使用する従来型チェーンでは、ブロック生成者が同じトランザクションをブロック内で再送信する必要があるため、各トランザクションはネットワークを通じて少なくとも2回伝播されます。Solanaでは、保留中のトランザクションを同期するためにゴシップへ過剰な負荷をかける必要がありません。また、トランザクションはガスオークションでブロックスペースを競うのではなく、スケジュールに基づいて分散されます。

Transaction Processing Unit（TPU）

TPUは、ブロック生成を担うバリデータの中核ロジックです。トランザクションはクライアントから取得され、QUIC streamerというコンポーネントを通じてデータパケットとして転送されます。このコンポーネントはパケットメモリを割り当て、QUICエンドポイントからデータを読み取ります（「Fetch Stage」と呼ばれます）。各ストリームは、クライアント（IPアドレス、ノード公開鍵）とサーバーによって識別されるQUIC転送制約内でパケットを送信します。

次にパケットはSigverify Stageへ送られ、過剰なパケットを除去する特殊な負荷制御メカニズムによって重複排除されます。重複排除されたパケットから無効な署名を持つものが除外され、バンキングステージへ転送されます。

バンキングステージはSolanaのランタイム実行における主要コンポーネントです。受信パケットをスケジュールし、競合をさらにフィルタリングしたうえで、バッチ単位で処理、保持、転送のいずれが可能かを評価します。ノードがブロック生成者であると判断すると、保持中および新たに受信したパケットをBankコンポーネントで処理します。Bankコンポーネントは、特定のスロットにおける台帳の全状態をインメモリで表現したものです。

バンキングステージとスケジューラコンポーネント内では、トランザクションは次の2つの状態で追跡されます。

• トランザクションがスケジュール可能な未処理状態
• トランザクションが現在スケジュール中または処理中の保留状態

トランザクションの処理が完了した後、再試行できる場合があります。再試行可能な場合は未処理状態へ戻され、それ以外の場合は状態が破棄されます。正常に処理されたトランザクションは、PoH tickによって「Entry」に形成され、ブロックにまとめられます。その後、Solanaのブロック伝播プロトコルであるTurbineを通じてshredとしてネットワークピアへブロードキャストされます。Turbineは、Broadcast Stageで適切なネットワークピアへパケットを送信する前に、失われたデータパケットを「再生成」するための消失訂正符号を生成します。

Transaction Validation Unit（TVU）

TVUは、非リーダーのバリデータノード内でブロックの検証と伝播を担うロジックです。TVUでは、データパケットが確定前にマルチスレッドの各ステージで処理されます。これには、shredの取得、署名検証、再送信、リプレイの各ステージが含まれます。

Shred Fetch StageとShred Verify Leader signature stageでは、非リーダーがUDP経由で他のノードからshredを受信し、署名を一括検証します。有効なshredはRetransmit Stageでピアノードへ再送信され、各トランザクションはReplay Stageで順番に再実行されます。

リプレイステージではランタイムが呼び出され、すべてのトランザクションを決定論的に再実行します。これにより、すべての状態変更、プログラム属性、Bankハッシュがリーダーの出力と完全に一致することを確認します。

ブロックが有効と評価された場合、バリデータは投票トランザクションに署名し、後続ブロックへ含めるためにその投票をリーダーへ送信します。

ランタイム

ランタイムは、TPUとTVUで共有されるSolanaの並行トランザクションプロセッサです。トランザクションは、明示的な動的メモリ実行を可能にするため、データ依存関係、つまり読み取りまたは書き込みを行うアカウントを事前に指定します。その結果、状態の読み取りをプログラム実行から適切に分離でき、ランタイムは並行アクセスを調整できます。

SolanaランタイムはSealevelという実行エンジンを使用し、読み取り専用アカウントにアクセスするトランザクションを並列実行します。一方、重複する書き込み可能アカウントにアクセスするトランザクションは直列化され、順次実行されます。

ランタイム内では、トランザクションはアトミックに実行されます。トランザクションをBankへコミットするには、そのトランザクション内のすべての命令が正常に実行される必要があり、そうでなければトランザクションは失敗します。

ランタイムは、明確に定義されたインターフェースを持つエントリポイントを通じて各プログラムとやり取りします。このエントリポイントは、すべてのオンチェーンプログラムが実行開始点として明示的に公開するRust関数であり、Solanaランタイムとプログラム間のインターフェースとして機能します。実行エンジンは公開鍵をアカウントへマッピングし、このエントリポイントへルーティングします。ただし、仮想マシンの命令セットアーキテクチャによって定義された、実行ロジックを制御する重要な制約が適用されます。

• アカウントの内容を変更できるのは、所有者のプログラムだけです。
• すべてのアカウントの残高合計はトランザクション実行の前後で等しくなりますが、これは集計値にのみ適用されます。システム送金とバーンではLamportは保存されません。
• トランザクション実行後、読み取り専用アカウントの残高は実行前の残高と等しくなければなりません。
• トランザクション内のすべての命令はアトミックに実行されます。1つでも失敗すると、すべてのアカウント変更が破棄されます。

TPUとTVUのパイプラインは、ランタイムとのやり取りでわずかに異なる経路をたどります。TPUランタイムは、メモリがコミットされる前に「Entry」がPoH tickによって記録されることを保証します。一方、TVUランタイムは、ランタイムがトランザクションを処理する前に「Entry」が検証されることを保証します。

コンセンサス

コンセンサスは、複雑な分散コンピューティングシステムにおける最も基本的なメカニズムの一つです。Solanaのトランザクションライフサイクルでは、コンセンサスはブロックが実行されTVUによって検証された後、確定前に行われます。コンセンサスの中核となる考え方は、ネットワーク参加者が同じ結果に合意し、一度決定した後はその判断を変更できないようにする統一的な合意です。

形式的には、耐障害性を備えたコンセンサスメカニズムは次の性質を満たす必要があります。

• 統一合意：2つのノードが異なる決定を下すことはありません。
• 完全性：どのノードも複数回決定しません。
• 妥当性：ノードがある値を決定した場合、その値は別のノードによって提案されたものです。
• 終了性：クラッシュしなかったすべてのノードは、最終的に何らかの値を決定します。

表面的に見れば、コンセンサスの目的はノード間で何らかの合意を得ることです。Solanaでは、ノード間の合意が必要な状況がいくつかあります。主に次の3つです。

リーダーローテーション

ネットワーク障害によって通信が中断され、複数のノードが同時に自分をリーダーだと誤認するスプリットブレイン状態が起こり得るため、すべてのノードが誰をリーダーとするか合意する必要があります。

リーダースケジュールは、事前定義されたシードを用いて次のアルゴリズムで生成されます。PoH tick height、つまり単調増加するカウンターが、安定した疑似乱数アルゴリズムのシードとして定期的に使用されます。

その高さでBankから、クラスター設定されたtick数の範囲内で投票したリーダーIDを持つ、すべてのステーク済みアカウントが抽出されます。このサンプルはアクティブセットと呼ばれ、ステークの重みによって並べ替えられます。その後、ランダムシードを使用してステーク加重でノードを選択し、ステーク加重の順序を作成します。この順序は、クラスター設定されたtick数の経過後に有効になります。

同期

信頼できるタイムスタンプがなければ、バリデータは受信ブロックの順序を判断できません。Solanaは、コンセンサス処理の前にトランザクションを順序付ける暗号学的時計として、Proof-of-Historyというメカニズムを使用します。同期に関するAnzaのドキュメントでは、次のように説明されています。

「リーダーノードは、前回の証明から一定時間が経過したことを示す暗号学的証明によってブロックに『タイムスタンプ』を付けます。証明にハッシュされたすべてのデータは、確実に証明の生成前に発生しています。その後、ノードは新しいブロックをバリデータノードと共有し、バリデータノードはそれらの証明を検証できます。ブロックは任意の順序でバリデータへ到着する可能性があり、数年後に再実行される可能性もあります。このような信頼性の高い同期保証により、SolanaはブロックをEntryと呼ばれる小さなトランザクションバッチへ分割できます。その後、ブロックコンセンサスという概念が成立する前に、Entryがリアルタイムでバリデータへストリーミングされます」。

Proof-of-Historyはコンセンサスメカニズムではありませんが、SolanaのProof-of-Stakeコンセンサスの性能に大きな影響を与えることを忘れてはなりません。

アトミックコミット

ノード間で合意が必要なもう一つのプロセスは、アトミックコミットです。Solanaのような高性能システムでは、あるトランザクションが一部のノードでは失敗し、他のノードでは成功する可能性があります。

部分的な実行を避けるため、SolanaはACIDの意味でランタイム内のアトミック性を保証します。また、問題が発生した場合はロールバックし、問題がなければコミットするという、トランザクションの結果についてすべてのノードが合意することも保証します。

Solanaにおけるコミットメントは、そのブロック（スロット）へ投票したバリデータ数と、Tower BFTのロックアウトメカニズムにおける投票の深さに基づいて、ブロックのファイナリティを測定します。これは、バリデータによる投票に基づき、特定のスロットについてネットワークがどの程度強く合意しているかを示します。各バリデータはスロット、具体的にはブロック高へ投票し、競合するフォークには投票しないことを約束します。Tower BFTのロックアウトが、この仕組みを確実に適用します。

Solanaには、processed、confirmed、finalizedという3つのコミットメントステータスがあります。ステーク済みバリデータの圧倒的多数（≥66%）が投票するとブロックはconfirmedとなり、その上に少なくとも32個のconfirmedブロックが構築されるとfinalizedとなります。

楽観的な並列実行と非同期のリーダースケジュールの直接的な結果として、Solanaは「まず実行し、後で投票する」モデルを採用しています。プロトコルは、新たに生成されたブロックについて全バリデータの合意を待たずに次のブロックを生成します。このため、2つ以上の競合チェーンが同時に存在するフォークが発生する可能性もあります。スロットが確定すると、競合するすべてのフォークは破棄され、そのフォークが正規チェーンとなります。

Alpenglow

本記事の執筆時点では、SolanaはTower BFTとPoH台帳を使用し、一部の参加者が障害を起こした場合でもネットワークがコンセンサス状態へ到達できるようにしています。

最近、Anzaの研究チームは、Alpenglowと呼ばれる、よりシンプルで高性能な新しいコンセンサスプロトコル設計を提案しました。Alpenglowは、Proof of History、Tower BFT、投票伝播へのゴシップの使用など、現在のコンセンサス設計に含まれるレガシーコンポーネントの刷新を目指しています。

Alpenglowは、その中核でVotorとRotorを使用してSolanaのコンセンサスを高速化します。

Votorは2段階の投票メカニズムであり、ステークの80%が応答する場合は1ラウンド、少なくとも60%が応答する場合は2ラウンドでブロックのファイナリティを実現するよう設計されています。

Rotorは、shredの配布を処理する単一レイヤーのリレーノードを採用し、既存のTurbineプロトコルを改良します。またRotorは、参加ノードのステークに比例して帯域幅を活用することで、ホップ数を減らしSolanaのスループットを最適化します。 

Sui

アカウント中心モデルを採用するSolanaとは異なり、Suiブロックチェーンはオブジェクト指向のデータモデルを使用し、状態データを一意の識別子、プロパティ、メソッドを持つオブジェクトとして表現します。

Suiでは、スマートコントラクトもオブジェクトを操作する一意の識別子を持つSui Move packageというオブジェクトです。これらのSui Move packageは、一連のSui Moveバイトコードモジュールで構成されます。各モジュールは、その名前と、packageのオンチェーンIDとモジュール名の組み合わせによって一意に識別されます。

オブジェクト設計とメタデータの詳細は本記事の範囲外ですが、すべてのオブジェクトには、そのオブジェクトをトランザクションでどのように使用できるかを決める所有者がいることが重要です。

オブジェクトには次の所有権モデルがあります。

• アドレス所有オブジェクト： アドレス所有オブジェクトは、アカウントアドレスまたはオブジェクトIDのいずれかである、特定の32バイトアドレスによって所有されます。アクセスできるのは所有者だけです。
• 不変オブジェクト： 不変オブジェクトは変更、譲渡、削除できません。所有者を持たず、誰でもグローバルにアクセスして使用できます。
• 共有オブジェクト： 共有オブジェクトは共有され、誰でもアクセスできるオブジェクトです。
• ラップされたオブジェクト： オブジェクトを別のオブジェクト内にラップします。ラップされたオブジェクトは独立性を持たず、ラップするオブジェクトを通じてのみアクセスできます。

Suiトランザクション

Suiでは、トランザクションは入力に対して実行され、トランザクションの結果を定義するコマンド群で構成されます。このコマンド群はProgrammable Transaction Block（PTB）と呼ばれ、Sui上のすべてのユーザートランザクションを定義します。PTBを使用すると、新しいMove packageを公開することなく、単一のトランザクション内で複数のMove関数を呼び出し、オブジェクトと「coin」を管理できます。

PTBの構造は次のように定義されます。

{
    inputs: [Input],
    commands: [Command],
}

inputsは、オブジェクトまたは純粋値である引数のベクターです。これらのオブジェクトは送信者が所有する場合も、共有または不変である場合もあります。commandsフィールドは、高レベルのトランザクション命令のベクターです。

PTBの実行中、入力ベクターには入力オブジェクトまたは純粋値のバイト列が設定されます。その後、トランザクションコマンドが順番に実行され、結果が結果ベクターへ保存されます。これは値の配列で、各値はコマンド固有の任意のMove型を取ることができます。入力とは異なり、値はオブジェクトや純粋値に限定されません。最後に、トランザクションの効果がアトミックに適用されます。 

Sui PTBの内部構造は複雑な別テーマであるため本記事では扱いませんが、実行開始時にPTBランタイムが読み込み済みの入力オブジェクトを入力配列へ格納する点は重要です。オブジェクトは、存在や有効な所有権などのルールを確認することで、すでにネットワークによって検証されています。純粋値のバイト列も配列へ読み込まれますが、使用されるまで検証されません。

この段階では、ガスコインへの影響が非常に重要です。ここで最大ガス予算がガスコインから差し引かれます。最大ガス予算は通常、トランザクション送信時に送信者が指定し、そのトランザクションが消費できるガスの最大量を表します。未使用のガスは、コインの所有者が変わった場合でも、実行終了時にガスコインへ返却されます。その後、各トランザクションコマンドが順番に実行されます。

送信後、Full nodeはトランザクションをバリデータノードへ送信し、提供されたすべてのメタデータを認証します（認証ステージ）。バリデータノードはトランザクションに必要なすべての有効性チェックを実行し、合格した場合は有効性を確認するために署名します。バリデータノードが有効なトランザクションとみなすには、次の条件を満たす必要があります。

• 有効なユーザー署名があること。
• トランザクションの開始者が、トランザクションで使用するすべての所有済み入力オブジェクトへアクセスできること。
• トランザクションで使用する共有入力オブジェクトが存在すること。
• トランザクションのガス予算で指定された量以上のガスを含むこと。

すべてのチェックに合格すると、バリデータは各所有済み入力が一度に1回だけ使用されるように、すべての所有済みinputsオブジェクトを指定された「トランザクションダイジェスト」へロックしようとします。

ロック処理に成功すると、バリデータはトランザクションへ署名し、その署名をFull nodeへ返します。

SuiのFull nodeは、基本的にネットワーク状態の読み取り専用ビューです。バリデータノードとは異なり、Full nodeはトランザクションへ署名できませんが、バリデータのクォーラムが以前コミットしたトランザクションを再実行して、チェーンの完全性を検証できます。Full nodeは単一のバリデータ署名だけでなく、可能な限り多くのバリデータ署名を並列収集します。ただし、トランザクション証明書の作成に必要なのは圧倒的多数（ステークの⅔超）のみです。

実行とチェックポイント

トランザクションに証明書が発行されると、実行のためにバリデータ委員会、つまり各エポックで固定される独立したバリデータの集合へ送信されます。バリデータがトランザクションを再検証する必要はなく、証明書上の署名を検証するだけです。証明書上の署名が有効であれば、バリデータはトランザクションが有効だと確信できます。

実行時、トランザクションは所有オブジェクトトランザクションと共有オブジェクトトランザクションの2種類に分類されます。

所有オブジェクトトランザクション

所有オブジェクトトランザクションは共有入力オブジェクトへアクセスせず、即座に実行されます。これらはfastpathトランザクションとも呼ばれ、検証後に実行され、正規チェーンへコミットされます。これらのトランザクションはコンセンサスを「通過」しません（fastpathトランザクションも最終的にはコンセンサスを通過しますが、チェックポイントへ含めるための正規順序を作成する目的に限られます）。オブジェクトを変更できるのは所有者だけであり、書き込み競合のリスクがないため、技術的に可能です。 

共有オブジェクトトランザクション

共有オブジェクトトランザクションは共有オブジェクトへアクセスするため、同じ共有オブジェクトを使用する他のトランザクションとの関係で、コンセンサスによる順序付けを経てから実行する必要があります。これらはslowpathトランザクションとも呼ばれます。関係するオブジェクトには複数のユーザーがアクセスして変更できるため、一貫性を確保するには完全なコンセンサスプロセスを経る必要があります。 

従来、SuiのmempoolであるNarwhalは、トランザクションの配布と順序付けを分離し、認証および署名済みのトランザクションを自ら順序付けることなく有向非巡回グラフ（DAG）に保持することで、一般的な混雑を回避していました。その後、Bullsharkがコンセンサスによる順序付けを行っていました。

性能と耐障害性をさらに向上させるため、Bullsharkを強化するHammerHeadプロトコルが導入され、スコアに基づく動的なリーダー選択が実装されました。これにより、特に障害またはクラッシュしたリーダーが存在する場合のレイテンシが大幅に低減され、スループットが向上しました。

これらの進歩を基盤として、現在はMysticetiがNarwhalとBullsharkの両方を置き換え、トランザクションの配布と順序付けを単一のプロトコルへ統合しています。Mysticetiはトランザクションを全順序で並べ、プロセスをさらに効率化して、より低いレイテンシと高いスループットを実現します。さらに、Suiのオブジェクト中心の所有権モデルにより、大半のトランザクションは独立したままであり、グローバルな順序付けスロットを競う必要がありません。

トランザクションの実行後、バリデータはトランザクションの効果に署名し、Full nodeへ返します。トランザクション効果とは基本的に、変更されたすべてのオブジェクト、消費されたガス、トランザクションの実行ステータスなど、トランザクションが行ったすべての処理の一覧です。

効果署名は、Full nodeが圧倒的多数のバリデータから収集した効果証明書の集合を構成し、トランザクションが確定したことを保証します。

トランザクションがライフサイクルの最終段階を示すチェックポイントへ含まれる時点では、そのトランザクションによる状態変更はすでに確定し、ネットワークへ適用されています。

所有済み入力オブジェクトのみを含むトランザクションでは、バリデータがトランザクションを実行して確定した後、順序付けのためにコンセンサスレイヤーへ送信します。

一方、共有入力オブジェクトを含むトランザクションは、実行前に順序付けのためコンセンサスへ送信され、チェックポイントへ含めるために再送信されることはありません。

バリデータは、因果順序が付けられた完全なトランザクションのまとまりをコンセンサスレイヤーから収集し、チェックポイントを構築します。チェックポイントには、トランザクションダイジェストの一覧と、各トランザクション効果に対応するダイジェストの両方が含まれます。その結果、チェックポイントはネットワーク内で確定したすべての状態遷移を記録する不変の記録となります。

ファイナリティ

Suiのトランザクションは、バリデータの圧倒的多数 (2𝑓 + 1) がトランザクション証明書を承認して副署した時点で、その証明書がコンセンサスによって順序付けまたは実行される前であってもファイナリティに到達します。この時点で競合するトランザクションは発生できず、トランザクションを取り消すこともできません。所有オブジェクトのみを含むトランザクションでは、ファイナリティ到達時に実行結果が直ちに判明します。共有オブジェクトトランザクションでは、証明書がコンセンサスによって順序付けられた後にのみ結果が確定します。トランザクションのファイナリティには、ネットワークで2往復する間に到達します。

決済は、トランザクションが圧倒的多数のバリデータによって実行され、効果証明書が作成された時点で成立します。所有オブジェクトトランザクションでは、コンセンサスを待たずに即座に実行されます。共有オブジェクトトランザクションでは、証明書がコンセンサスによって順序付けられた直後に実行と決済が行われます。いずれの場合も、決済がチェックポイント作成によって遅延することはないため、チェックポイント処理よりもレイテンシが低くなります。

トランザクション証明書はファイナリティを強く示しますが、絶対的な保証を提供するのは効果証明書または認証済みチェックポイントへの取り込みだけです。これらには、圧倒的多数のバリデータによるトランザクション効果の実行とコミットが必要だからです。

大局的には、Suiのトランザクションライフサイクルは、オブジェクト中心モデルを活用して並列性と効率を最大化します。トランザクションが認証のために送信されると、バリデータは参照先である入力オブジェクトの特定バージョンをロックしようとします。

所有オブジェクトでは、認証時にこれらのロックが即座に取得され、排他的アクセスを確保して二重支払いを防ぎます。共有オブジェクトでは、Suiのコンセンサスプロトコルによってトランザクションが順序付けられた後にのみロックが確立されます。

必要なロックがすべて取得されると、トランザクションの実行がスケジュールされます。この設計により、互いに素なオブジェクト集合を操作するトランザクションは独立かつ並列に実行でき、状態の無関係な部分間での競合と混雑を大幅に削減できます。

正常に実行された後、バリデータはトランザクション効果へ署名し、圧倒的多数の署名が収集されると効果証明書が作成されます。この証明書は決済のファイナリティを保証し、トランザクションが不可逆となり、その効果が永続化されたことを示します。

チェックポイントは、トランザクションの実行またはファイナリティに至るクリティカルパスの一部ではありません。実行後に構築され、トランザクションの正規順序を提供するとともに、実行に直接関与しなかったノードの状態同期を支援します。

Suiのオブジェクトモデルは、オブジェクトレベルでの正確な依存関係追跡を可能にし、グローバルな状態同期を不要にします。このアーキテクチャは、ハードウェア性能の向上に依存してスループットを高めるのではなく、汎用ハードウェア上でスケーラブルな分散実行を実現します。

実行、スケーラビリティ、設計上のトレードオフに関する考察

前述のとおり、トランザクションのライフサイクルを理解することは、ブロックチェーンの設計思想を最も明確に把握する方法の一つです。SolanaとSuiのトランザクションライフサイクルの違いからは、実行効率、スケーラビリティの限界、設計上のトレードオフという3つの重要な軸における、実行モデルの根本的な思想が明らかになります。

実行

アカウント中心のチェーンであるSolanaは、Banking Stageでアカウントをロックして競合を動的に検出します。これにより、同じアカウントを変更しないトランザクションは並列処理し、競合するトランザクションは順次処理します。

この種のアカウント検出メカニズムは、特にプログラムが他のプログラムに存在するロジックを実行する必要がある負荷の高いDeFi環境で、追加のランタイムコストを生じさせる可能性があります。この仕組みはCross-Program Invocationと呼ばれます。それでもSolanaの実行エンジンは、動的な競合検出によって大規模な並列性を実現でき、極めて低い手数料でトランザクションをほぼ瞬時に実行できます。

一方、Suiでは、オブジェクト中心の所有権モデルによって並列性がコンパイル時に推論されるため、トランザクションの競合を懸念する必要がありません。共有オブジェクトと所有オブジェクトのモデルによって競合を静的に推論でき、所有オブジェクトトランザクションのランタイムコストをほぼゼロにできます。

スケーラビリティの限界

スケーリングの観点では、Suiは所有オブジェクトトランザクションをグローバルコンセンサスなしで処理することにより、水平方向のスケーラビリティを実現し、オブジェクトパーティションに応じて線形に拡張できます。これにより、ほぼ即時となる1秒未満のファイナリティと、利用可能なハードウェアだけを上限とするスループットを実現します。共有オブジェクトトランザクションにはコンセンサスが必要ですが、Mysticetiへのアップグレードにより、こちらも1秒未満のファイナリティと高スループットを実現しています。Suiのアーキテクチャでは、リソースの追加によりブロックの配布と実行の両方を弾力的にスケールでき、増加するワークロードを効率的に処理できます。ただし、コンセンサス経路は所有オブジェクトのfast pathほど無制限ではありません。

Solanaは、単一リーダー方式と、アカウント競合によって制限される実行ファンアウトを採用しています。そのため、グローバルな単一shardの状態モデルと、スロットごとにリーダーを中心としてトランザクションを取り込む構造により、一定の水平スケーリング限界に達するように見えます。しかし、PoHによって補完された明確なパイプライン処理により、この限界内で積極的に最適化しています。トランザクションは正確に順序付けられ、400ms未満で処理され、1秒未満で楽観的確認に到達できます。垂直スケーリングでは、Solanaはバリデータのハードウェア、特にCPUコアとRAMの強化によって大幅にスケールします。これはSolana本来の設計と完全に一致しています。

Solanaが水平スケーリングではなく垂直スケーリングを選択し、上限に達するのは、アーキテクチャの欠陥ではなく設計上のトレードオフによるものだと明確に区別することが重要です。現在、いくつかの水平的アプローチが開発中です。たとえば、ローカル手数料市場、仮想サブネット、CMTによる状態の最小化などです。

設計上のトレードオフ

Solanaは、厳格なランタイム制約、アカウントの分離、決定論的なリーダースケジュールによって決定性を保証します。動的なアカウント競合の解決と明確なパイプライン処理は、プログラム間の密接な連携に適しており、高いコンポーザビリティを実現します。

Suiは、オブジェクト所有権の分析によって決定される組み込みの実行経路を通じて、決定性を保証します。同時に、Suiのオブジェクト中心モデルは、共有オブジェクトとProgrammable Transaction Block（PTB）によってコンポーザビリティを実現し、複数のコントラクトとユーザーにまたがる複雑な連携とアトミックな処理を可能にします。これは、あるオブジェクトの所有者を別のオブジェクトにできるためであり、オブジェクトレベルの相互運用性と、オブジェクトを所有権ツリーへ編成する仕組みを実現します。このような構造は、オブジェクトが頻繁に一緒に使用される場合や、実行時にどのオブジェクトを操作するか判断するためのランタイム検索が必要な場合に特に有用です。

まとめ

送信からファイナリティまでトランザクションを処理する仕組みが、SolanaとSuiの驚異的な高性能を支えています。トランザクションのライフサイクルを調べることで、両チェーンの低レイテンシと高スループットを実現する、緻密に設計されたパイプラインを理解できます。

Solanaはアカウント中心モデルに基づいて設計され、トランザクションは有効性を確保するために、一連のマルチスレッド処理とパイプラインを通過します。トランザクションはリーダーへ送信され、リーダーはTPUパイプラインを実行して検証し、適切にスケジュールします。競合しない場合は並列に、競合する場合は順次処理します。バリデータがブロックを生成していないときは、TVUパイプラインを実行してトランザクションを複製、検証します。TPUとTVUはどちらもランタイムを使用します。その結果、ランタイムは重複しないアカウントを事前かつ決定論的に推論し、競合しないトランザクションを並列実行できるため、Solanaは非常に短い時間で数千件のトランザクションを処理します。このため、高頻度取引、高度にコンポーザブルなDeFi、インフラストラクチャ負荷の高いdApp、低レイテンシのコンシューマー向けdAppなど、実環境のユースケースに最適です。

一方、Suiは、一意の識別子で各オブジェクトを追跡するオブジェクト中心モデルを採用しています。オブジェクトの所有権を推論することで、互いに素なオブジェクト集合にアクセスするトランザクションを並列実行できるか静的に判断できます。所有オブジェクトトランザクションと共有オブジェクトトランザクションに分離し、署名済みチェックポイントを使用してFull nodeの同期を維持するデュアル実行経路モデルにより、コンセンサスレイヤーへ負荷をかけずに軽量なトランザクションを処理できます。同時に、信頼性が高く高速なファイナリティと、新規ノードの効率的な同期も実現します。これにより、負荷の増加に応じて水平スケールでき、DeFi、ゲーム、資産中心の取引所、プログラム可能な資産など、大量のオブジェクト連携を伴うアプリケーションに非常に適しています。

参考資料

• Solana公式ドキュメント
• Anza公式ドキュメント
• Sui公式ドキュメント
• Gulf Stream：Solanaのmempoolを使用しないトランザクション転送プロトコル
• Sealevel — 数千のスマートコントラクトを並列処理
• Cross-Program InvocationとPDA — Anchorにおける2つの強力なメカニズムの組み合わせ
• NarwhalとTusk：DAGベースのMempoolと効率的なBFTコンセンサス
• PilotfishによるSui実行のスケールアウト
• SUIとSolanaの比較 - TrustWallet
• Tower BFT：SolanaによるPBFTの高性能な実装
• David J DeWitt、Jim N Gray：「並列データベースシステム：高性能データベースシステムの未来」Communications of the ACM、第35巻、第6号、85～98ページ、1992年6月。doi:10.1145/129888.129894
• Jim N Gray、Leslie Lamport：「トランザクションコミットに関するコンセンサス」ACM Transactions on Database Systems（TODS）、第31巻、第1号、133～160ページ、2006年3月。doi:10.1145/1132863.1132867
• Leslie Lamport：「分散システムにおける時間、時計、イベントの順序付け」Communications of the ACM、第21巻、第7号、558～565ページ、1978年7月。
• Michael J Fischer、Nancy Lynch、Michael S Paterson：「1つの障害プロセスがある場合の分散コンセンサスの不可能性」Journal of the ACM、第32巻、第2号、374～382ページ、1985年4月。doi:10.1145/3149.214121
• Kushal Babel、Andrey Chursin、George Danezis、Anastasios Kichidis、Lefteris Kokoris-Kogias、Arun Koshy、Alberto Sonnino、Mingwei Tian：「MYSTICETI：未認証DAGでレイテンシの限界へ到達」、[cs.DC]、2024年7月。
• Giorgos Tsimos、Anastasios Kichidis、Alberto Sonnino、Lefteris Kokoris-Kogias：「HammerHead：動的スケジューリングのためのリーダー評価」、[cs.CR]、2023年9月。