Web3 Advent Calendar 2025

デジタルプラットフォーマー株式会社　エンジニアLab

非EVM入門（XRPL, Solana, Sui）

Last updated at 2025-12-10Posted at 2025-12-09

はじめに

最近EVM以外を調べてみたので、ざっくりまとめておきます。間違いなどあったらご指摘頂いたら幸いです。

また、言語についての記述はありますが、コードの書き方については特にここでは解説していません。

XRPL

概要

XRP Ledger (XRPL) は、Ripple Labs によって開発された分散型台帳（Distributed Ledger Technology, DLT）です。
主な目的は、高速で低コストな国際送金や価値の移転を可能にすることです（ネイティブ通貨はXRP）。
いわゆるブロックに相当するものは、XRPLでは「ledger version」もしくは「ledger」と呼ばれており、状態のスナップショットが連続的に合意され更新されていきます。

ちなみに、いわゆるRipple（リップル）は開発会社名で、トークン自体はXRP（エックスアールピー）と読みますし、XRP Ledger（エックスアールピーレッジャー）がチェーン名です。

コンセンサスアルゴリズム

XRPL のコンセンサスは Proof of Work や Proof of Stake ではない、独自の Ripple Protocol Consensus Algorithm (RPCA) を採用しています。
これは、信頼できるノード集合（UNL: Unique Node List）による投票型コンセンサスです。

1. UNL（Unique Node List）

各ノードは「信頼できる検証者（validator）のリスト」を保持しています。
Ripple社が推奨するUNL（Default UNL）もあるが、ノード運営者は独自のUNLを設定可能です。

2. コンセンサスの流れ

XRPL のコンセンサスは約 3〜5秒 で1つの ledger を確定させます。

Validatorがtxを提案（UNLに送る）
複数 validator が共通して含めている tx を自分の候補セットに入れる
複数ラウンドの投票を行い、ラウンドごとに採用条件の閾値を上げていきます
1. UNLが10個あった場合に最初は5つのノードが提案したらそれを採用し、それ以外のtxはdropします）
2. 次のラウンドで残ったtxのうち、次は6つのノードが提案していたらそれを採用し、それ以外はdrop
3. 最終的に80%のノードが支持したtxが残る

上記のような流れです。ここで気になるのは、UNLが被ってなかったら全然別のtx通らない？ってところです。

これはそもそもUNLは90%以上重複している必要があるそうで、それ未満だとforkする可能性があるそうです公式Doc。

そのため、基本的にはDefault UNLを使う必要があり、そのリスト自体も元々はリップル社関連が多く、そこが中央集権じゃないかっていう批判を浴びた理由っぽいですね。今もノードの情報自体は全て公開されているわけではなさそうですが。

ただこの辺は織り込み済みで、中央集権性を欠いているもの、パフォーマンスを重視しているのだと思います。それが良いかどうかは各々の意見によりますが、合理的判断ではあるのかなと思います。

特徴

高速（3〜5秒で確定）
手数料が極小（数千分の1ドル）
エネルギー効率が非常に高い（PoWと比較して桁違い）
UNL の設計により「許可不要（permissionless）」と「信頼性」のバランスを取る

スマートコントラクト

XRPLはネイティブにスマートコントラクトをサポートしていませんが、FTやNFT、またMPT（Multi Purpose Token）と呼ばれるFTとNFTの両方の性質を持たせられるようなトークンがネイティブにサポートされています。mintやtransferのような基本的な機能は持っているものの、プログラマブルなメソッドやプロパティは追加できません。

一方でXRPLにはサイドチェーンも存在し、XahauやXRPL EVMなどではスマートコントラクトを扱うことができます。Xahauについてはちゃんと調べられていないのですが、XRPL EVMはEVM互換なのでSolidityでスマートコントラクトが開発できます。自分が見た範囲ではガス代はEthereumよりは安いですが、安いL2よりは高いっていう感じです。

また、HooksというWASMを使ったスマートコントラクトをL1で使う構想もあるようですが、現状テストネットでしか使えないようです。（Mainnetへの適用はロードマップとかが見つけられず不明です）

Solana

概要

Solanaは高速かつ低コストの取引を可能にしたチェーンです。Solanaではtxは1秒未満で完了し、コストもEVM L2と比較しても低いです。
PoH（Proof of History）という仕組みを使って高速化していますが、コンセンサスアルゴリズムのベースとしてはPoSを採用しています。

概要は記述してますが、もう少し細かく知りたい場合はこちらの記事がより網羅的に扱っています。
Solana - How it works (by Helius) 日本語訳

Everything is an Account

Linuxの思想を文字っただけなのでオフィシャルにこんな文言があるか分かりません（All data on the Solana network is stored in accountsとは書いてあります）が、Solanaでは全てがアカウントで管理されます。

EVMのアカウントのことは一旦忘れて頂いて、Solanaでは全部がアカウントという単位で管理されています。

以下の画像で、Programはevmでいうところのコントラクトで、これもアカウントです。Walletも当然アカウントです。Mint AccountというのがNFTのことで、これもアカウントです。

(https://hanzochang.com/articles/28 より引用)

EVMではWorld Stateということで全ての状態を一つのstateで管理（というと言い過ぎかもですが）していますが、Solanaではアカウント単位での管理のため独立したアカウント間の処理であれば並列計算が可能です。これがSolanaの処理速度が速い理由の一つです。

PoH（Proof of History）

PoHではローカルタイムスタンプの代わりにハッシュ値の計算を何回繰り返したかを時間の代わりとして使用します。大体1ハッシュの計算ってどのコンピュータでも同じようなものだから、わざわざ全体でタイムスタンプで同期せずとも同じような時間の流れでシステムを構築できるよねっていう発想です。

この連続したハッシュ値の一連をPoHと呼びます。ハッシュ値の説明は割愛しますが、例えばある文字列"aaa"のハッシュ値を取ります。そのハッシュ値のハッシュ値を取ります。これを100回繰り返して得られるハッシュ値はハッシュ値の計算を100回直列で繰り返す以外に計算する方法はありません。

Solana How it works より引用

一方でVerifyは途中のハッシュ値さえ分かれば並列で計算できます。例えば、最初の文字列、10個目のハッシュ値、20個目...100個目のハッシュ値の11個を手に入れればそれぞれ10回のハッシュ計算を並列で行うことでこの直列のハッシュ計算が正しいか判断できます。

この直列の連続のハッシュ値の中にtxの情報を含むことで、txの順序を保証します。15個目のハッシュ値を計算するときにHash(14個目のハッシュ値 + txの情報)とすることで、後でVerifyするときに15個目にtxが入ったことが保証されます。

SolanaではEthereumと同様にブロックごとにBlock Producer(SolanaではLeaderと呼ぶ)が決まっていて、LeaderがこのPoHを計算し、上記のようにいくつかのポイントのハッシュ値も他のValidatorにbroadcastし、Validatorはそれを並列計算することで、PoHの検証をします。

この後に、正当なPoHの中でそれぞれ投票を行って一番票が多いブロックが正しいブロックとして繋がれていくっていう流れです。

このPoHは非同期的にどんどん進めることができて、ちょっとでも前のLeaderからデータが遅れたら次のLeaderはPoHの計算を始めてしまうみたいなことが起きるため、数ブロックはロールバックの可能性が高いです。ロールバックというかOrphanブロックができやすい状態ですね。次の章でもう少し詳しく説明しています。

PoHについてはこちらの記事が詳しいです。
【完全保存版】SolanaのPoHの徹底解説（初めから丁寧に）

トランザクション

EVMでは1txあたり、1 function callでしたが、Solanaでは1txに複数のfunction call（Solanaではinstructionと呼びます）が可能です。これを1つの署名にまとめるため、全体としてはデータ量が圧縮できるのかと思います。

トランザクションというかブロックですが、約400msごとに生成されます。ただし、SolanaではCommitment Levelというものが存在し、processed -> confirmed -> finalizedという順番でステータスが変わります。confirmedまでは5ブロック前後で、そこまでステータスが変わればロールバックされることはほとんどないようです。processedまでだと、orphanブロックがたくさんできる可能性があります。

finalizedまでは32ブロック以上で、だいたい十数秒程度かかるようです。

開発言語

Solana上で動くスマートコントラクトはProgramと呼ばれます。
Program自体はBPF（Berkeley Packet Filter）向けのバイトコードとしてデプロイされますが、一般にはRustで開発します（C, C++でも開発できるようですが、Rustがデファクトになっています）。

AnchorというRust用のフレームワークがあり、基本的にはほとんどのケースでこのフレームワークが使われます。もう少し低レベルな実装をしたい場合にはPure Rustで実装されます。

Rust
- 事実上の標準言語です。
- 公式の Solana Program Library (SPL) も Rust で書かれています。
- メモリ安全・型安全で、低レベル最適化もしやすいのがメリットです。
C / C++
- Rust の前はC/C++で書かれることもありましたが、
  現在はエコシステム的にRustが主流になっています。
Anchor（フレームワーク）
- Rust 製のフレームワークで、アカウント構造の定義やシリアライズ、IDL生成などを自動化してくれます。
- Solana の生の開発よりもボイラープレートがかなり減るので、
  新規で書くなら 「Rust + Anchor」 が定番の組み合わせです。

Off-chain / クライアント

TypeScript / JavaScript
- @solana/web3.js を使ってフロントエンドやNode.jsからSolanaとやり取りします。
- トランザクションの組み立て・署名・送信、アカウント情報の取得などはだいたいここから行います。
その他の言語
- Rust / Go / Python など向けにも SDK が存在し、バックエンド側から Solana に接続する際に使われます。
- ただ、ドキュメントやサンプルの多さという意味では TypeScript / JavaScript が一歩抜けています。

Sui

概要

Suiは 「オブジェクトベースの並列実行」 を中心に設計された高性能なレイヤー1ブロックチェーンです。
コンセンサスアルゴリズムはNarwhal（メモリプール＋DAG）とBullshark（コンセンサス）に分離された構造を採用しており、
トランザクションの多くをコンセンサス不要（＝高速処理）で実行することで、
低レイテンシと高スループットを実現しています。

さらに独自の Sui Move (Move 言語を Sui に最適化した方言) によって、
資産（オブジェクト）の所有権管理が型レベルで保証され、安全性とパフォーマンスを両立しています。

ちなみにSuiは日本語の水から来ているそうです。ちょっと親近感湧きますね。

まずは大まかな比較を公式ドキュメントから引用します。

トピック	Sui	Ethereum
署名アルゴリズム	Ed25519, secp256k1, secp256r1	secp256k1
Consensus mechanism	DPoS	PoS
VM と使用言語	MoveVM, Move Lang	EVM, Solidity, Vyper
Chain data structure	DAG	Blocks
共通規格（coin, token, NFT など）	Currency Standard, Closed-Loop Token	ERC-20, ERC-721, ERC-1155
コイン名・最小単位	SUI, MIST	ETH, Wei
利用可能な開発フレームワーク	Sui CLI	Foundry, Hardhat
L1/L2	L2 なし、高速 L1 に依存	多数の L2 あり
ガバナンス	On-chain governance	EIP + ノードオペレーターのコンセンサス
Bridges	Supported	Supported
ネットワークセキュリティ（支配に必要なステーク量）	総ステークの 66%	総ステークの 51%
スマートコントラクト監査	少ない監査で済む（object model による安全性）	言語的安全性が低く、多くの監査が必要
Private transactions	Public by design	Public by design（L2 や第三者により private 対応あり）
TVL	約 10 億ドル	約 460 億ドル
クライアント実装言語	Rust, TypeScript	多数
Eventing	sender, object ID, type, timestamp で index	topic で index
Indexing	高レベルのトランザクションデータ + objects, coins など	高レベルのトランザクションデータのみ
Oracles	第三者提供	第三者提供
ネットワークアップグレード戦略	validator による投票で protocol flags と framework を更新し有効化	EIP + ハードフォーク（on-chain 機構なし）
IDE	VSCode	多数
Transaction lifecycle	クライアント→validator 2 往復で transaction certificate を生成（実行保証）、共有 object の順序保証のためさらに往復。非常に低レイテンシ。	トランザクションがネットワークにゴシップされ、検証され mempool に追加。validator がブロック提案し投票。複数ブロック経過後に最終確定。高レイテンシ。
Parallel execution	並列可能なトランザクションは並列実行	全トランザクションは逐次実行
Storage fees / rebates	低コスト、object 破棄でリベートあり	高コスト、リベートなし
Contract immutability	upgrade capability により mutable / immutable 両方をネイティブサポート	ネイティブではなく、Solidity コード解析が必要。opcode で判断できる場合もある
Contract upgrading	ネイティブ（upgrade capability を使用）	Proxy pattern による delegate call
Composability	PTB により 1 トランザクション内で複数関数を呼び出し、結果を次に渡して atomicity を保証	各呼び出しが個別トランザクションで逐次処理され atomicity なし
Token royalties	チェーンレベルで強制	マーケットプレイスのみで強制可能

Everything is an Object

Solanaのように、Suiも同様な設計思想を持ちます。似たような文言も公式ドキュメントにありましたが、NFTのページにまさにそのまま書いてました（Create a Non-Fungible Token）。

Suiにおいて、オンチェーンに存在する全てのデータは Object（オブジェクト） として管理されます。

ユーザーの持つNFT → Object
コイン（SUIトークン）→ Object
スマートコントラクトで管理される状態 → Object
コントラクト自体の定義（Package）→ 特殊な Object

オブジェクトには必ず Owner（所有者） が存在し、Move の型システムにより所有権が厳密に管理されます。
この「所有権モデル」こそが Sui の高速化の核です。

所有権モデルの種類

Suiではオブジェクトの所有権は次のいずれかとして分類されます。

Owned（単一所有）
　→ 特定のアカウントが所有。並列実行が可能。
Shared（共有オブジェクト）
　→ 複数アカウントが同時にアクセス。コンセンサスを必要とし、やや重い。
Immutable（不変オブジェクト）
　→ 誰でも読めるが変更不可。

Owned object 同士は完全に独立しているため、並列実行（パラレル処理）が極めて簡単に可能 になります。
SuiもSolana同様、World Stateは持たず、オブジェクト間の依存関係だけで並列性を判断できる構造になっています。

Sui Move（Move言語のSui拡張）

Sui Move は Libra Move をベースとした言語ですが、Sui に最適化された拡張を含みます。

Move の特徴は「資産（リソース）を型として管理でき、複製不可・破棄不可を保証できる」点です。
Sui はさらに次のような機能を追加しています：

Dynamic Fields：動的にフィールドを追加し、複雑なデータ構造を表現できる
Object Wrapping：オブジェクトを別のオブジェクトに包む（所有構造の表現）

これにより、「NFTに装備アイテムを紐づける」「インベントリ管理」「ゲームのキャラクターと関連資産」など複雑な状態が安全に実装できます。

以下SolidityとMoveの比較表です。（公式ドキュメントより引用）

トピック	Solidity	Move
Account vs object-centric models	`mapping` を用いたコントラクト内でのカスタム所有権ロジック。Ethereum では coin がグローバル API を持つ唯一の first-class citizen。その他の所有権 API はコントラクト固有。	Sui では object の所有権が言語レベルで組み込まれており、object が first-class citizen。Sui 上で owned なものすべてが object として扱われる。
Data storage	データはスマートコントラクト内に保存される。	データは Move object に保存される。
Inheritance	多重継承やポリモーフィズムをサポート。	interface なし、ポリモーフィズムなし。ただし Move には `Type<T>` のような generics がある。
Dynamic dispatch	OK	NG
Asset/Token accessibility	資産はスマートコントラクトに紐づく。	共有 object は誰でもアクセス可能。owned object は所有者のみがアクセス可能。
Access control	`Ownable` や `AccessControl` による identity/role-based access control。	主に capability-based access control を owned object を通じて実現。identity/role-based access も可能。
Contract upgrades	Proxy contract がユーザーのトランザクションをフォワードして実現。	新しいコントラクトは古いものと layout-compatible である必要がある。shared object の versioning を考慮する必要あり。
Development environment	Hardhat, Foundry	Move VSCode extension
Mutate contract state	compile-time の ABI interface を通じてトランザクションを送信することで state を変更。	runtime における programmable transaction block (PTB) を構築して送信することで state を変更。

パラレル実行（並列処理）

Suiの最大の特徴の1つが 「所有オブジェクト単位での並列処理」 です。

EVMでは全トランザクションが基本的に直列実行であるため、スループットには限界があります。
Solanaはアカウントの read/write の組み合わせで並列化できるのに対し、

Sui は “Owned Object” をキーに完全に独立性を判定できるため
極めて高い並列性能を得られます。

具体例：

Alice が所有するオブジェクト A
Bob が所有するオブジェクト B

この場合は全く独立しているため、
コンセンサスを必要とせず、並列実行（fast path）が可能です。

txを受け取ったValidatorは署名を検証して、問題なければこれを処理します。この段階でそのValidatorのローカル内ではtxが実行されたと同義です。

その後CheckPointというそれぞれのValidatorがローカルで処理したtxを共有します。Owned Objectはそれぞれ独立してるため、特にコンセンサスを取らずtxの検証をするだけでチェーンに取り込まれます。このCheckPointは秒間4回発生（公式DOC）するため、Suiでは高速にtxが処理されます。

一方、Shared Object を操作する場合のみコンセンサスが走ります。コンセンサスについては次節で解説します。

Narwhal & Bullshark（コンセンサス）

Sui におけるコンセンサスは Narwhal（メモリプール/DAG） と Bullshark（コンセンサス） の2段構造になっています。

Narwhal

各Validatorがトランザクションをバッチとして受け取り DAG（有向非巡回グラフ） に格納
全Validatorが効率的にデータを受け取ることで「データ可用性」を担保
（データを失わせず全員が読める状態）

Bullshark

Narwhalが構築したDAGを元に 合意順序を決めるレイヤー
BFT系のアルゴリズムで安全にトランザクション順序を確定

自分もここはまだあまり理解できていないのですが、すごく大雑把に言うとNarwhalでそれぞれのValidatorがtxを持ち寄って大きなDAGを作り、そのDAGに順序を与えるのがBullsharkです。

例えばDAGだとAからB,C,Dと順番になっていた場合、AとB, AとC, AとDには順序が存在しますが、B,C,Dには存在しません。これの順序付けがBullsharkの仕事です。

B    C    D
 \   |   /
   \ |  /
     A

まとめるとSuiの特徴的な点は、

「Owned Object の操作にはそもそもコンセンサスが不要」
「Shared Object のときのみ Narwhal, Bullshark が動く」

という構造になっており、これにより高速なトランザクション処理が可能です。

zkLogin（ゼロ知識ログイン）

Sui特有の機能として zkLogin があります。

Google / Facebook / Twitch などのOAuthログインを
ゼロ知識証明により「本人がログインしたことだけを証明」し
その情報をSuiチェーン上のアドレスにマッピングする

という仕組みです。

特徴：

秘密鍵をユーザーに管理させる必要がない
しかし OAuth プロバイダにユーザーのオンチェーン行動を追跡させない
ZKにより「なりすましの不可能性」も確保

ウォレットっていう概念をユーザーに意識させなくできるという意味でこれは非常に大きいですね。
というかもはやこれだけでSuiを使う理由にもなるくらい便利機能な気がします。

細かい仕組みはこちらの記事が詳しいです。
https://zenn.dev/mashharuki/articles/sui_zklogin_1

一点気になるとすれば、OAuthプロバイダー側が撤退したりaudを勝手に変えられたら当該ウォレット使えなくなってしまうので、これとは別にバックアップウォレットとか必要になる気がします。

トランザクション

Suiのトランザクションは次のような特徴を持ちます。

① 複数の Move Call を1つの tx にまとめられる

Solanaのinstructionに似ていますが、
Suiでは 複数の Move function call を1つのトランザクションにまとめられます。

② オブジェクト単位でのアクセス

トランザクション内でどの Object を read/write するかが明確で、
これにより並列化が可能になります。

③ ガス料金はオブジェクト・実行内容によって決定

単純なオペレーションの場合は極めて安価です。

まとめ

EVM系しか触ったことなかったのですが、色々調べてみると各チェーン特徴があって面白かったです。次はそれぞれ実装してみたいと思います。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up