メインコンテンツまでスキップ

「Sui」タグの記事が 23 件 件あります

Sui ブロックチェーンと Move プログラミング言語に関するコンテンツ

すべてのタグを見る

@mysten/sealで分散暗号化を構築する:開発者向けチュートリアル

· 約 16 分
Dora Noda
Software Engineer

プライバシーは公共インフラになりつつあります。2025年、開発者にはデータ保存と同じくらい簡単に暗号化を行うツールが必要です。Mysten LabsのSealは、まさにそれを提供します—オンチェーンアクセス制御を備えた分散シークレット管理。このチュートリアルでは、アイデンティティベース暗号化、閾値セキュリティ、プログラマブルアクセスポリシーを使用して安全なWeb3アプリケーションを構築する方法を教えます。


導入:なぜSealがWeb3にとって重要なのか

従来のクラウドアプリケーションは、単一のプロバイダーが暗号化データへのアクセスを制御する集中型キー管理システムに依存しています。便利ですが、これは危険な単一障害点を作り出します。プロバイダーが侵害されたり、オフラインになったり、アクセスを制限することを決定した場合、あなたのデータはアクセス不可能または脆弱になります。

Sealは、このパラダイムを完全に変えます。Mysten LabsがSuiブロックチェーン向けに構築したSealは、分散シークレット管理(DSM)サービスで、以下を可能にします:

  • アイデンティティベース暗号化:コンテンツが環境を離れる前に保護される
  • 閾値暗号化:複数の独立したノード間でキーアクセスを分散
  • オンチェーンアクセス制御:タイムロック、トークンゲーティング、カスタム認証ロジック
  • ストレージ非依存設計:Walrus、IPFS、または任意のストレージソリューションと連携

安全なメッセージングアプリ、ゲート付きコンテンツプラットフォーム、タイムロック資産転送を構築する場合、Sealは必要な暗号プリミティブとアクセス制御インフラストラクチャを提供します。


はじめに

前提条件

開始する前に、以下があることを確認してください:

  • Node.js 18+がインストールされていること
  • TypeScript/JavaScriptの基本的な知識
  • テスト用のSuiウォレット(Sui Walletなど)
  • ブロックチェーンの概念の理解

インストール

npm経由でSeal SDKをインストールします:

npm install @mysten/seal

ブロックチェーンインタラクション用にSui SDKも必要です:

npm install @mysten/sui

プロジェクトセットアップ

新しいプロジェクトを作成し、初期化します:

mkdir seal-tutorial
cd seal-tutorial
npm init -y
npm install @mysten/seal @mysten/sui typescript @types/node

シンプルなTypeScript設定を作成します:

// tsconfig.json
{
"compilerOptions": {
"target": "ES2020",
"module": "commonjs",
"strict": true,
"esModuleInterop": true,
"skipLibCheck": true,
"forceConsistentCasingInFileNames": true
}
}

コアコンセプト:Sealの仕組み

コードを書く前に、Sealのアーキテクチャを理解しましょう:

1. アイデンティティベース暗号化(IBE)

公開キーに暗号化する従来の暗号化とは異なり、IBEではアイデンティティ(メールアドレスやSuiアドレスなど)に暗号化できます。受信者は、そのアイデンティティを制御していることを証明できる場合にのみ復号化できます。

2. 閾値暗号化

単一のキーサーバーを信頼する代わりに、Sealはt-of-n閾値スキームを使用します。3-of-5キーサーバーを設定することで、任意の3つのサーバーが協力して復号化キーを提供できますが、2つ以下では不可能です。

3. オンチェーンアクセス制御

アクセスポリシーはSuiスマートコントラクトによって強制されます。キーサーバーが復号化キーを提供する前に、要求者がオンチェーンポリシー要件(トークン所有権、時間制約など)を満たしていることを確認します。

4. キーサーバーネットワーク

分散キーサーバーはアクセスポリシーを検証し、復号化キーを生成します。これらのサーバーは、単一の制御点を確保しないよう、異なる当事者によって運営されます。


基本実装:最初のSealアプリケーション

Suiブロックチェーンポリシーを通じてアクセスを制御し、機密データを暗号化するシンプルなアプリケーションを構築しましょう。

ステップ1:Sealクライアントの初期化

// src/seal-client.ts
import { SealClient } from '@mysten/seal';
import { SuiClient } from '@mysten/sui/client';

export async function createSealClient() {
// テストネット用のSuiクライアントを初期化
const suiClient = new SuiClient({
url: 'https://fullnode.testnet.sui.io'
});

// テストネットキーサーバーでSealクライアントを設定
const sealClient = new SealClient({
suiClient,
keyServers: [
'https://keyserver1.seal-testnet.com',
'https://keyserver2.seal-testnet.com',
'https://keyserver3.seal-testnet.com'
],
threshold: 2, // 2-of-3閾値
network: 'testnet'
});

return { sealClient, suiClient };
}

ステップ2:シンプルな暗号化/復号化

// src/basic-encryption.ts
import { createSealClient } from './seal-client';

async function basicExample() {
const { sealClient } = await createSealClient();

// 暗号化するデータ
const sensitiveData = "これは私の秘密メッセージです!";
const recipientAddress = "0x742d35cc6d4c0c08c0f9bf3c9b2b6c64b3b4f5c6d7e8f9a0b1c2d3e4f5a6b7c8";

try {
// 特定のSuiアドレス用にデータを暗号化
const encryptedData = await sealClient.encrypt({
data: Buffer.from(sensitiveData, 'utf-8'),
recipientId: recipientAddress,
// オプション:メタデータを追加
metadata: {
contentType: 'text/plain',
timestamp: Date.now()
}
});

console.log('暗号化されたデータ:', {
ciphertext: encryptedData.ciphertext.toString('base64'),
encryptionId: encryptedData.encryptionId
});

// 後でデータを復号化(適切な認証が必要)
const decryptedData = await sealClient.decrypt({
ciphertext: encryptedData.ciphertext,
encryptionId: encryptedData.encryptionId,
recipientId: recipientAddress
});

console.log('復号化されたデータ:', decryptedData.toString('utf-8'));

} catch (error) {
console.error('暗号化/復号化に失敗しました:', error);
}
}

basicExample();

Suiスマートコントラクトによるアクセス制御

Sealの真の力は、プログラマブルアクセス制御にあります。特定の時間後にのみデータを復号化できるタイムロック暗号化の例を作成しましょう。

ステップ1:アクセス制御コントラクトのデプロイ

まず、アクセスポリシーを定義するMoveスマートコントラクトが必要です:

// contracts/time_lock.move
module time_lock::policy {
use sui::clock::{Self, Clock};
use sui::object::{Self, UID};
use sui::tx_context::{Self, TxContext};

public struct TimeLockPolicy has key, store {
id: UID,
unlock_time: u64,
authorized_user: address,
}

public fun create_time_lock(
unlock_time: u64,
authorized_user: address,
ctx: &mut TxContext
): TimeLockPolicy {
TimeLockPolicy {
id: object::new(ctx),
unlock_time,
authorized_user,
}
}

public fun can_decrypt(
policy: &TimeLockPolicy,
user: address,
clock: &Clock
): bool {
let current_time = clock::timestamp_ms(clock);
policy.authorized_user == user && current_time >= policy.unlock_time
}
}

ステップ2:Sealとの統合

// src/time-locked-encryption.ts
import { createSealClient } from './seal-client';
import { TransactionBlock } from '@mysten/sui/transactions';

async function createTimeLocked() {
const { sealClient, suiClient } = await createSealClient();

// Sui上でアクセスポリシーを作成
const txb = new TransactionBlock();

const unlockTime = Date.now() + 60000; // 1分後にアンロック
const authorizedUser = "0x742d35cc6d4c0c08c0f9bf3c9b2b6c64b3b4f5c6d7e8f9a0b1c2d3e4f5a6b7c8";

txb.moveCall({
target: 'time_lock::policy::create_time_lock',
arguments: [
txb.pure(unlockTime),
txb.pure(authorizedUser)
]
});

// ポリシーを作成するトランザクションを実行
const result = await suiClient.signAndExecuteTransactionBlock({
transactionBlock: txb,
signer: yourKeypair, // あなたのSuiキーペア
});

const policyId = result.objectChanges?.find(
change => change.type === 'created'
)?.objectId;

// このポリシーで暗号化
const sensitiveData = "これは1分後にアンロックされます!";

const encryptedData = await sealClient.encrypt({
data: Buffer.from(sensitiveData, 'utf-8'),
recipientId: authorizedUser,
accessPolicy: {
policyId,
policyType: 'time_lock'
}
});

console.log('タイムロックされたデータが作成されました。1分後に復号化を試してください。');

return {
encryptedData,
policyId,
unlockTime
};
}

実用的な例

例1:安全なメッセージングアプリケーション

// src/secure-messaging.ts
import { createSealClient } from './seal-client';

class SecureMessenger {
private sealClient: any;

constructor(sealClient: any) {
this.sealClient = sealClient;
}

async sendMessage(
message: string,
recipientAddress: string,
senderKeypair: any
) {
const messageData = {
content: message,
timestamp: Date.now(),
sender: senderKeypair.toSuiAddress(),
messageId: crypto.randomUUID()
};

const encryptedMessage = await this.sealClient.encrypt({
data: Buffer.from(JSON.stringify(messageData), 'utf-8'),
recipientId: recipientAddress,
metadata: {
type: 'secure_message',
sender: senderKeypair.toSuiAddress()
}
});

// 暗号化されたメッセージを分散ストレージ(Walrus)に保存
return this.storeOnWalrus(encryptedMessage);
}

async readMessage(encryptionId: string, recipientKeypair: any) {
// ストレージから取得
const encryptedData = await this.retrieveFromWalrus(encryptionId);

// Sealで復号化
const decryptedData = await this.sealClient.decrypt({
ciphertext: encryptedData.ciphertext,
encryptionId: encryptedData.encryptionId,
recipientId: recipientKeypair.toSuiAddress()
});

return JSON.parse(decryptedData.toString('utf-8'));
}

private async storeOnWalrus(data: any) {
// Walrusストレージとの統合
// 暗号化されたデータをWalrusにアップロードし
// 取得用のblob IDを返します
}

private async retrieveFromWalrus(blobId: string) {
// blob IDを使用してWalrusから暗号化されたデータを取得
}
}

例2:トークンゲート付きコンテンツプラットフォーム

// src/gated-content.ts
import { createSealClient } from './seal-client';

class ContentGating {
private sealClient: any;
private suiClient: any;

constructor(sealClient: any, suiClient: any) {
this.sealClient = sealClient;
this.suiClient = suiClient;
}

async createGatedContent(
content: string,
requiredNftCollection: string,
creatorKeypair: any
) {
// NFT所有権ポリシーを作成
const accessPolicy = await this.createNftPolicy(
requiredNftCollection,
creatorKeypair
);

// NFTアクセス要件でコンテンツを暗号化
const encryptedContent = await this.sealClient.encrypt({
data: Buffer.from(content, 'utf-8'),
recipientId: 'nft_holders', // NFTホルダー用の特別な受信者
accessPolicy: {
policyId: accessPolicy.policyId,
policyType: 'nft_ownership'
}
});

return {
contentId: encryptedContent.encryptionId,
accessPolicy: accessPolicy.policyId
};
}

async accessGatedContent(
contentId: string,
userAddress: string,
userKeypair: any
) {
// まずNFT所有権を確認
const hasAccess = await this.verifyNftOwnership(
userAddress,
contentId
);

if (!hasAccess) {
throw new Error('アクセスが拒否されました:必要なNFTが見つかりません');
}

// コンテンツを復号化
const decryptedContent = await this.sealClient.decrypt({
encryptionId: contentId,
recipientId: userAddress
});

return decryptedContent.toString('utf-8');
}

private async createNftPolicy(collection: string, creator: any) {
// NFT所有権をチェックするMoveコントラクトを作成
// ポリシーオブジェクトIDを返す
}

private async verifyNftOwnership(user: string, contentId: string) {
// ユーザーが必要なNFTを所有しているかチェック
// NFT所有権についてSuiにクエリ
}
}

例3:タイムロック資産転送

// src/time-locked-transfer.ts
import { createSealClient } from './seal-client';

async function createTimeLockTransfer(
assetData: any,
recipientAddress: string,
unlockTimestamp: number,
senderKeypair: any
) {
const { sealClient, suiClient } = await createSealClient();

// Sui上でタイムロックポリシーを作成
const timeLockPolicy = await createTimeLockPolicy(
unlockTimestamp,
recipientAddress,
senderKeypair,
suiClient
);

// 資産転送データを暗号化
const transferData = {
asset: assetData,
recipient: recipientAddress,
unlockTime: unlockTimestamp,
transferId: crypto.randomUUID()
};

const encryptedTransfer = await sealClient.encrypt({
data: Buffer.from(JSON.stringify(transferData), 'utf-8'),
recipientId: recipientAddress,
accessPolicy: {
policyId: timeLockPolicy.policyId,
policyType: 'time_lock'
}
});

console.log(`資産は${new Date(unlockTimestamp)}までロックされています`);

return {
transferId: encryptedTransfer.encryptionId,
unlockTime: unlockTimestamp,
policyId: timeLockPolicy.policyId
};
}

async function claimTimeLockTransfer(
transferId: string,
recipientKeypair: any
) {
const { sealClient } = await createSealClient();

try {
const decryptedData = await sealClient.decrypt({
encryptionId: transferId,
recipientId: recipientKeypair.toSuiAddress()
});

const transferData = JSON.parse(decryptedData.toString('utf-8'));

// 資産転送を処理
console.log('資産転送のロックが解除されました:', transferData);

return transferData;
} catch (error) {
console.error('転送がまだアンロックされていないか、アクセスが拒否されました:', error);
throw error;
}
}

Walrus分散ストレージとの統合

SealはSuiの分散ストレージソリューションであるWalrusとシームレスに連携します。両方を統合する方法は以下の通りです:

// src/walrus-integration.ts
import { createSealClient } from './seal-client';

class SealWalrusIntegration {
private sealClient: any;
private walrusClient: any;

constructor(sealClient: any, walrusClient: any) {
this.sealClient = sealClient;
this.walrusClient = walrusClient;
}

async storeEncryptedData(
data: Buffer,
recipientAddress: string,
accessPolicy?: any
) {
// Sealで暗号化
const encryptedData = await this.sealClient.encrypt({
data,
recipientId: recipientAddress,
accessPolicy
});

// 暗号化されたデータをWalrusに保存
const blobId = await this.walrusClient.store(
encryptedData.ciphertext
);

// SealとWalrusの両方の情報を含む参照を返す
return {
blobId,
encryptionId: encryptedData.encryptionId,
accessPolicy: encryptedData.accessPolicy
};
}

async retrieveAndDecrypt(
blobId: string,
encryptionId: string,
userKeypair: any
) {
// Walrusから取得
const encryptedData = await this.walrusClient.retrieve(blobId);

// Sealで復号化
const decryptedData = await this.sealClient.decrypt({
ciphertext: encryptedData,
encryptionId,
recipientId: userKeypair.toSuiAddress()
});

return decryptedData;
}
}

// 使用例
async function walrusExample() {
const { sealClient } = await createSealClient();
const walrusClient = new WalrusClient('https://walrus-testnet.sui.io');

const integration = new SealWalrusIntegration(sealClient, walrusClient);

const fileData = Buffer.from('重要なドキュメントの内容');
const recipientAddress = '0x...';

// 暗号化して保存
const result = await integration.storeEncryptedData(
fileData,
recipientAddress
);

console.log('Blob IDで保存されました:', result.blobId);

// 後で取得して復号化
const decrypted = await integration.retrieveAndDecrypt(
result.blobId,
result.encryptionId,
recipientKeypair
);

console.log('取得されたデータ:', decrypted.toString());
}

閾値暗号化の高度な設定

本番アプリケーションでは、複数のキーサーバーでカスタム閾値暗号化を設定したいでしょう:

// src/advanced-threshold.ts
import { SealClient } from '@mysten/seal';

async function setupProductionSeal() {
// 複数の独立したキーサーバーで設定
const keyServers = [
'https://keyserver-1.your-org.com',
'https://keyserver-2.partner-org.com',
'https://keyserver-3.third-party.com',
'https://keyserver-4.backup-provider.com',
'https://keyserver-5.fallback.com'
];

const sealClient = new SealClient({
keyServers,
threshold: 3, // 3-of-5閾値
network: 'mainnet',
// 高度なオプション
retryAttempts: 3,
timeoutMs: 10000,
backupKeyServers: [
'https://backup-1.emergency.com',
'https://backup-2.emergency.com'
]
});

return sealClient;
}

async function robustEncryption() {
const sealClient = await setupProductionSeal();

const criticalData = "ミッションクリティカルな暗号化データ";

// 高いセキュリティ保証で暗号化
const encrypted = await sealClient.encrypt({
data: Buffer.from(criticalData, 'utf-8'),
recipientId: '0x...',
// 最大セキュリティのため全5サーバーを要求
customThreshold: 5,
// 冗長性を追加
redundancy: 2,
accessPolicy: {
// 多要素要件
requirements: ['nft_ownership', 'time_lock', 'multisig_approval']
}
});

return encrypted;
}

セキュリティベストプラクティス

1. キー管理

// src/security-practices.ts

// 良い例:安全なキー導出を使用
import { generateKeypair } from '@mysten/sui/cryptography/ed25519';

const keypair = generateKeypair();

// 良い例:キーを安全に保存(環境変数の例)
const keypair = Ed25519Keypair.fromSecretKey(
process.env.PRIVATE_KEY
);

// 悪い例:キーをハードコードしない
const badKeypair = Ed25519Keypair.fromSecretKey(
"hardcoded-secret-key-12345" // これはしないでください!
);

2. アクセスポリシーの検証

// 暗号化前に必ずアクセスポリシーを検証
async function secureEncrypt(data: Buffer, recipient: string) {
const { sealClient } = await createSealClient();

// 受信者アドレスを検証
if (!isValidSuiAddress(recipient)) {
throw new Error('無効な受信者アドレスです');
}

// ポリシーが存在し有効であることをチェック
const policy = await validateAccessPolicy(policyId);
if (!policy.isValid) {
throw new Error('無効なアクセスポリシーです');
}

return sealClient.encrypt({
data,
recipientId: recipient,
accessPolicy: policy
});
}

3. エラーハンドリングとフォールバック

// 堅牢なエラーハンドリング
async function resilientDecrypt(encryptionId: string, userKeypair: any) {
const { sealClient } = await createSealClient();

try {
return await sealClient.decrypt({
encryptionId,
recipientId: userKeypair.toSuiAddress()
});
} catch (error) {
if (error.code === 'ACCESS_DENIED') {
throw new Error('アクセスが拒否されました:権限を確認してください');
} else if (error.code === 'KEY_SERVER_UNAVAILABLE') {
// バックアップ設定で再試行
return await retryWithBackupServers(encryptionId, userKeypair);
} else if (error.code === 'THRESHOLD_NOT_MET') {
throw new Error('利用可能なキーサーバーが不十分です');
} else {
throw new Error(`復号化に失敗しました: ${error.message}`);
}
}
}

4. データ検証

// 暗号化前にデータを検証
function validateDataForEncryption(data: Buffer): boolean {
// サイズ制限をチェック
if (data.length > 1024 * 1024) { // 1MB制限
throw new Error('暗号化するにはデータが大きすぎます');
}

// 機密パターンをチェック(オプション)
const dataStr = data.toString();
if (containsSensitivePatterns(dataStr)) {
console.warn('警告:データに潜在的に機密のパターンが含まれています');
}

return true;
}

パフォーマンス最適化

1. バッチ操作

// 効率性のため複数の暗号化をバッチ処理
async function batchEncrypt(dataItems: Buffer[], recipients: string[]) {
const { sealClient } = await createSealClient();

const promises = dataItems.map((data, index) =>
sealClient.encrypt({
data,
recipientId: recipients[index]
})
);

return Promise.all(promises);
}

2. キーサーバーレスポンスのキャッシュ

// レイテンシを減らすためキーサーバーセッションをキャッシュ
class OptimizedSealClient {
private sessionCache = new Map();

async encryptWithCaching(data: Buffer, recipient: string) {
let session = this.sessionCache.get(recipient);

if (!session || this.isSessionExpired(session)) {
session = await this.createNewSession(recipient);
this.sessionCache.set(recipient, session);
}

return this.encryptWithSession(data, session);
}
}

Seal統合のテスト

ユニットテスト

// tests/seal-integration.test.ts
import { describe, it, expect } from 'jest';
import { createSealClient } from '../src/seal-client';

describe('Seal統合', () => {
it('データを正常に暗号化および復号化する必要があります', async () => {
const { sealClient } = await createSealClient();
const testData = Buffer.from('テストメッセージ');
const recipient = '0x742d35cc6d4c0c08c0f9bf3c9b2b6c64b3b4f5c6d7e8f9a0b1c2d3e4f5a6b7c8';

const encrypted = await sealClient.encrypt({
data: testData,
recipientId: recipient
});

expect(encrypted.encryptionId).toBeDefined();
expect(encrypted.ciphertext).toBeDefined();

const decrypted = await sealClient.decrypt({
ciphertext: encrypted.ciphertext,
encryptionId: encrypted.encryptionId,
recipientId: recipient
});

expect(decrypted.toString()).toBe('テストメッセージ');
});

it('アクセス制御ポリシーを強制する必要があります', async () => {
// 権限のないユーザーが復号化できないことをテスト
const { sealClient } = await createSealClient();

const encrypted = await sealClient.encrypt({
data: Buffer.from('秘密'),
recipientId: 'authorized-user'
});

await expect(
sealClient.decrypt({
ciphertext: encrypted.ciphertext,
encryptionId: encrypted.encryptionId,
recipientId: 'unauthorized-user'
})
).rejects.toThrow('アクセスが拒否されました');
});
});

本番環境へのデプロイ

環境設定

// config/production.ts
export const productionConfig = {
keyServers: [
process.env.KEY_SERVER_1,
process.env.KEY_SERVER_2,
process.env.KEY_SERVER_3,
process.env.KEY_SERVER_4,
process.env.KEY_SERVER_5
],
threshold: 3,
network: 'mainnet',
suiRpc: process.env.SUI_RPC_URL,
walrusGateway: process.env.WALRUS_GATEWAY,
// セキュリティ設定
maxDataSize: 1024 * 1024, // 1MB
sessionTimeout: 3600000, // 1時間
retryAttempts: 3
};

モニタリングとログ

// utils/monitoring.ts
export class SealMonitoring {
static logEncryption(encryptionId: string, recipient: string) {
console.log(`[SEAL] ${recipient}用にデータ${encryptionId}を暗号化しました`);
// モニタリングサービスに送信
}

static logDecryption(encryptionId: string, success: boolean) {
console.log(`[SEAL] 復号化 ${encryptionId}: ${success ? '成功' : '失敗'}`);
}

static logKeyServerHealth(serverUrl: string, status: string) {
console.log(`[SEAL] キーサーバー ${serverUrl}: ${status}`);
}
}

リソースと次のステップ

公式ドキュメント

コミュニティとサポート

  • Sui Discord: コミュニティサポートのため#sealチャンネルに参加
  • GitHub Issues: バグ報告と機能リクエスト
  • 開発者フォーラム: ディスカッション用Suiコミュニティフォーラム

探索すべき高度なトピック

  1. カスタムアクセスポリシー: Moveコントラクトで複雑な認証ロジックを構築
  2. クロスチェーン統合: 他のブロックチェーンネットワークでSealを使用
  3. エンタープライズキー管理: 独自のキーサーバーインフラストラクチャを設定
  4. 監査とコンプライアンス: 規制環境向けのログとモニタリングを実装

サンプルアプリケーション

  • 安全なチャットアプリ: Sealによるエンドツーエンド暗号化メッセージング
  • ドキュメント管理: アクセス制御付きエンタープライズドキュメント共有
  • デジタル権利管理: 使用ポリシー付きコンテンツ配信
  • プライバシー保護分析: 暗号化データ処理ワークフロー

結論

Sealは、Web3におけるプライバシーと暗号化をインフラストラクチャレベルの関心事にする根本的な変化を表しています。アイデンティティベース暗号化、閾値セキュリティ、プログラマブルアクセス制御を組み合わせることで、開発者に真に安全で分散化されたアプリケーションを構築するための強力なツールを提供します。

Sealで構築することの主な利点には以下があります:

  • 単一障害点の排除: 分散キーサーバーが中央権威を排除
  • プログラマブルセキュリティ: スマートコントラクトベースのアクセスポリシーが柔軟な認証を提供
  • 開発者フレンドリー: TypeScript SDKが既存のWeb3ツールとシームレスに統合
  • ストレージ非依存: Walrus、IPFS、または任意のストレージソリューションと連携
  • 本番環境対応: エンタープライズセキュリティ標準でMysten Labsが構築

ユーザーデータの保護、サブスクリプションモデルの実装、複雑なマルチパーティアプリケーションの構築のいずれであっても、Sealは自信を持って構築するために必要な暗号プリミティブとアクセス制御インフラストラクチャを提供します。

今日から構築を始めて、プライバシーを公共インフラストラクチャの基本的な部分にする開発者の成長するエコシステムに参加しましょう。


構築を始める準備はできましたか? @mysten/sealをインストールして、このチュートリアルの例を試してみてください。分散ウェブは、プライバシーとセキュリティを第一に考えるアプリケーションを待っています。

Talus Nexus: オンチェーンAIエコノミーに向けたエージェント型ワークフロー層の評価

· 約 10 分
Dora Noda
Software Engineer

TL;DR

  • TalusはNexusを提供している。Moveベースのフレームワークで、オンチェーンとオフチェーンのツールを検証可能なDAG(有向非巡回グラフ)ワークフローとして構成し、現在は信頼された「Leader」サービスが調整し、今後は安全なエンクレーブと分散化を目指す。
  • このスタックは新興のエージェント経済を狙い、ツール登録、決済レール、ガス予算、マーケットプレイスを統合し、ツールビルダーとエージェント運用者が利用状況を監査可能な形で収益化できるようにする。
  • Cosmos SDK + Move VMで構築する専用チェーンProtochainへのロードマップが公開されているが、現行の調整レイヤーはSuiであり、SuiとWalrusストレージの統合が実運用基盤となっている。
  • トークン計画は進化途上。過去のTAI構想と、支払い・ステーキング・優先権に用いるエコシステムトークンTAI構想と、支払い・ステーキング・優先権に用いるエコシステムトークンUSを導入した2025年ライトペーパーが併記されている。
  • 実行リスクはLeaderの分散化、トークン経済の確定、Protochain性能の実証に集中しており、Sui・Walrus・オフチェーンサービスを跨ぐ開発者体験を維持できるかが鍵となる。

Talusが構築しているもの/していないもの

Talusは、AI推論そのもののマーケットではなく、自律エージェントの調整と収益化を担うレイヤーとして自らを位置づけている。中核製品のNexusは、ツール呼び出し、外部API、オンチェーンロジックをSui Moveで記述されたDAGワークフローにまとめられる。設計は検証可能性、権限キャップに基づくアクセス制御、スキーマに基づくデータフローを重視し、各ツール呼び出しをオンチェーンで監査できる。Talusはこれを、Tool Marketplace、Agent Marketplace、Agent-as-a-Serviceといったマーケット層で補完し、エージェント機能の発見と収益化を支援する。

一方、Talusは自前の大規模言語モデルやGPUネットワークを運営していない。ツールビルダーが既存のAPIやサービス(OpenAI、ベクター検索、トレーディングシステム、データ提供など)をラップし、Nexusに登録することを想定している。このため、RitualやBittensorのような計算ネットワークとは補完関係にあり、Nexusワークフロー内のツールとして組み込むことができる。

アーキテクチャ:オンチェーン制御プレーンとオフチェーン実行

オンチェーン(Sui Move)

オンチェーンコンポーネントはSui上に存在し、調整プレーンを提供する。

  • ワークフローエンジン – DAGのセマンティクスはエントリーグループ、分岐バリアント、並行性チェックを含む。実行前に競合状態を防ぐ静的検証も行う。
  • プリミティブProofOfUIDはパッケージ間の認証済みメッセージングを緩やかな結合で実現し、OwnerCap/CloneableOwnerCapは能力ベースの権限管理を提供する。ProvenValueNexusData構造体は、データをインラインまたはリモートストレージ参照として渡す方法を定義する。
  • Default TAP(Talus Agent Package) – ワークシート(証明オブジェクト)の作成、ワークフロー実行のトリガー、ツール結果の確認を、Nexus Interface v1に沿って示すリファレンスエージェント。
  • ツール登録とスパム対策 – ツール作成者は定義を公開する際に時間ロック付き担保を預ける必要があり、スパムを抑制しつつパーミッションレス性を維持する。
  • ガスサービス – 共有オブジェクトにツール毎の価格、ユーザーのガス予算、使用期限や回数制限付きのガスチケットを保持する。イベントで各請求を記録し、ツール提供者とLeader向けの決済を監査可能にする。

オフチェーンLeader

Talusが運用するLeaderサービスは、Suiイベントを監視し、ツールスキーマを取得し、オフチェーン実行(LLM、API、計算ジョブ)をオーケストレーションし、宣言されたスキーマに照らして入出力を検証した上で結果をオンチェーンに書き戻す。Leaderの権限はSuiオブジェクトで表現され、失敗したSuiトランザクションはキャパビリティを「破損」させ、次のエポックまで再利用を防ぐ。Talusは、TEE、複数オペレーター、最終的なパーミッションレス化でこの経路を強化する計画だ。

ストレージと検証性

Mysten Labsの分散ストレージ層であるWalrusが、エージェントメモリ、モデルアーティファクト、大規模データセットに利用される。Nexusは決定的な制御プレーンとしてSuiを維持し、重量級のペイロードはWalrusにオフロードする。公開資料では、オプティミスティック検証、ゼロ知識検証、信頼実行など複数モードをケースに応じて選択できるとされている。

開発者体験と初期プロダクト

TalusはRust製SDK、CLIツール、DAG構築・LLM統合・ツール保護を解説するドキュメントを提供する。標準ツールのカタログ(OpenAIのチャット補完、X〈Twitter〉操作、Walrusアダプター、数学ユーティリティなど)がプロトタイプの摩擦を減らす。コンシューマ向けには、IDOL.fun(エージェント対エージェントの予測市場)やAI Bae(ゲーミフィケーションされたAIコンパニオン)が実証とディストリビューションの役割を果たす。ノーコードビルダーのTalus Visionは、非開発者向けにワークフロー設計を抽象化するマーケットプレイスUIとして位置づけられている。

経済設計、トークン計画、ガス処理

現行のSui展開では、ユーザーがSUIでワークフローを資金提供する。ガスサービスは予算をツール固有のチケットに変換し、有効期限やスコープ制限を適用し、オンチェーンで照合できる請求ログを残す。ツール提供者が価格を設定し、Leaderも同じ決済フローで支払われる。Leaderは実行成功後に予算を請求できるため、利用者はオペレーターを信頼する必要があるが、発行イベントにより監査は可能だ。

トークン設計は依然として過渡期にある。外部の解説では従来の**TAIが言及される一方、Talus2025年ライトペーパーでは総供給100億のエコシステムトークンTAI**が言及される一方、Talusの2025年ライトペーパーでは総供給100億のエコシステムトークン**US**が提案されている。用途はツールおよびLeaderへの支払い、サービス保証のためのステーキング、優先権付与など。実行時に余剰で支払われたSUIを市場スワップで$USに変換する仕組みも示唆されている。これらは最終的なトークノミクス確定までは暫定情報として扱うべきだ。

資金調達、チーム、パートナーシップ

Talusは2024年末にPolychainがリードした600万ドルの戦略ラウンド(累計900万ドル調達、評価額1億5000万ドル)を発表した。資金はNexusの高度化、コンシューマアプリの育成、エージェント向け専用L1であるProtochainの構築に充てられる。公開情報では、**Mike Hanono(CEO)Ben Frigon(COO)**が主要メンバーとして紹介されている。SuiとWalrusとの統合発表は、Mysten Labsインフラが現行の実行環境であることを強調する。

競合環境

  • Ritualは分散型AI計算(Infernet)とEVM統合に注力し、ワークフローオーケストレーションよりも検証可能な推論を重視する。
  • **Autonolas(Olas)**はオフチェーンエージェントサービスをオンチェーンインセンティブで調整する。エージェント経済というビジョンは共通だが、MoveベースのDAG実行レイヤーは持たない。
  • Fetch.aiはAgentverseやuAgentsで自律サービスを接続するが、Talusは各ワークフロー手順のオンチェーン検証とガス会計を組み込む点で差別化する。
  • BittensorはTAOサブネットでMLモデル貢献に報酬を与える計算マーケットであり、Nexusのツールとして統合は可能だが、Talusが狙う収益化レールは提供しない。

総じてTalusは、ワークフローの調整と決済プレーンを担い、生の計算や推論は専用ネットワークに接続させる戦略をとっている。

主なリスクと未解決の問い

  1. Leaderへの信頼 – TEEや複数オペレーター対応が実装されるまで、開発者はTalusのLeaderが正確に実行し結果を返すと信頼する必要がある。
  2. トークンの不確実性 – ブランドと仕組みがTAIからTAIからUSへ変化しており、供給スケジュールや配布、ステーキング経済は未確定。
  3. Protochainの実行力 – Cosmos SDKとMove VMを備えるとされるが、コードリポジトリ、ベンチマーク、セキュリティ監査は未公開。
  4. ツール品質とスパム – 担保要件はスパム抑止になるものの、長期的成功にはスキーマ検証、稼働保証、オフチェーン結果を巡る紛争解決が必要。
  5. UXの複雑さ – Sui、Walrus、多様なオフチェーンAPIを調整する運用負荷があり、SDKやノーコードツールがこれを十分に抽象化できるかが課題。

2025~2026年に注目すべきマイルストーン

  • Leaderロードマップの公開:TEE強化、スラッシングルール、追加オペレーターの公開オンボーディング。
  • Tool Marketplaceの拡充:登録ツール数、価格モデル、品質指標(稼働率、SLAの透明性)。
  • IDOL.fun、AI Bae、Talus Visionの利用指標:エージェントネイティブ体験への需要を測るリード指標。
  • Sui + Walrus上で大規模ワークフローを動かした際の性能データ:レイテンシ、スループット、ガス消費。
  • 最終的なトークノミクス公開:供給スケジュール、ステーキング報酬、SUI→$US変換プロセス。
  • Protochainのリポジトリ、テストネット、IBC対応などの公開で、専用チェーン構想を検証。

ビルダーとオペレーターが関与する方法

  • 素早くプロトタイピング – Default TAPと標準ツール(OpenAI、X、Walrus)を組み合わせ、データ取得→要約→オンチェーン処理の3ノードDAGを構築する。
  • 特化ツールを収益化 – 自社API(金融データ、コンプライアンスチェック、特注LLMなど)をNexusツールとしてラップし、価格を設定、期限付きや回数制限付きのガスチケットを発行して需要を管理する。
  • Leader参入に備える – ステーキング要件、スラッシングロジック、障害時対応のドキュメントを追跡し、ネットワーク解放時に追加Leaderとして参加できるよう準備する。
  • コンシューマ向けフライホイールを評価 – IDOL.funとAI Baeのリテンションや支出を分析し、エージェント起点のコンシューマプロダクトがツール需要拡大の起爆剤になるか検証する。

まとめ

Talusは、Moveベースで検証可能なワークフロー、キャパビリティ制御されたツール構成、明示的な収益化レールを組み合わせ、オンチェーンエージェント経済の実現に向けた確かな青写真を提示している。今後の成否は、信頼型Leaderを超えてスケールできるか、持続可能なトークンインセンティブを確定できるか、ProtochainがSui期の知見を専用実行環境へと拡張できるかにかかっている。透明な決済とコンポーザブルなエージェントワークフローを求めるビルダーは、Talusがこれらの課題をどれだけ早く低減できるかを注視しながら、Nexusを検討リストに入れておく価値がある。

Sui 上の Seal: オンチェーンで制御できるプログラマブルなシークレットレイヤー

· 約 6 分
Dora Noda
Software Engineer

パブリックブロックチェーンは、すべての参加者に同期された監査可能な元帳を提供しますが、同時にデータをデフォルトで公開します。2025 年 9 月 3 日に Sui Mainnet で稼働を開始した Seal は、オンチェーンのポリシーロジックと分散型キー管理を組み合わせることで、どのペイロードを誰が復号できるかを開発者が細かく制御できるようにします。

TL;DR

  • 概要: Seal は、Sui スマートコントラクトがオンチェーンで復号ポリシーを強制し、クライアントはアイデンティティベース暗号(IBE)でデータを暗号化し、しきい値キーサーバーから鍵を取得できるようにするシークレット管理ネットワークです。
  • 重要な理由: 独自バックエンドやブラックボックスなオフチェーンスクリプトを作るのではなく、プライバシーとアクセス制御を一級の Move プリミティブとして扱えます。暗号文はどこにでも保存でき(Walrus との組み合わせが自然)、誰が読むかを制御し続けられます。
  • 想定ユーザー: トークンゲートされたコンテンツ、タイムロック公開、プライベートメッセージング、ポリシー対応 AI エージェントを構築するチームは、Seal の SDK を組み込むだけで暗号の下回りではなくプロダクトロジックに集中できます。

ポリシーロジックは Move に記述

Seal のパッケージには seal_approve* という Move 関数が用意されており、特定のアイデンティティ文字列に対して誰がどの条件で鍵を要求できるかを定義します。ポリシーには NFT 所有、許可リスト、タイムロック、独自のロールシステムを組み合わせられます。ユーザーやエージェントが復号を要求すると、キーサーバーは Sui フルノードの状態を参照してポリシーを評価し、チェーンが承認した場合にのみ応答します。

アクセスルールはパッケージ内のオンチェーンコードとして存在するため、透明で監査可能、かつ他のスマートコントラクトコードと同じようにバージョン管理できます。ガバナンスの更新も、コミュニティレビューとオンチェーン履歴を伴いながら、通常の Move アップグレードと同様に展開できます。

しきい値暗号が鍵管理を担う

Seal はアプリケーションが定義するアイデンティティに対してデータを暗号化します。開発者が選定した独立したキーサーバー委員会が IBE のマスターシークレットを共有します。ポリシーチェックを通過すると、各サーバーが要求されたアイデンティティの鍵シェアを導出します。t 台のサーバーから応答が集まると、クライアントはそれらを結合して復号に使える鍵を得ます。

委員会メンバー(Ruby Nodes、NodeInfra、Overclock、Studio Mirai、H2O Nodes、Triton One、Mysten の Enoki サービスなど)としきい値を選ぶことで、可用性と機密性のトレードオフを調整できます。可用性を重視するなら、大きな委員会と低いしきい値を選びましょう。プライバシー保証を高めたいなら、クォーラムを厳しく設定し、パーミッション型プロバイダーを活用してください。

開発者体験: SDK とセッションキー

Seal には暗号化・復号フロー、アイデンティティの整形、バッチ処理を支援する TypeScript SDK(npm i @mysten/seal)が用意されています。アプリが繰り返しアクセスする必要がある場合でもウォレットに承認要求を連発しないよう、セッションキーの発行もサポートしています。高度なワークフローでは、Move コントラクトが専用モードでオンチェーン復号を要求できるため、エスクロー開示や MEV 耐性オークションなどのロジックをスマートコントラクト内で直接実行できます。

Seal はストレージに依存しないため、Walrus と組み合わせて検証可能な BLOB ストレージを実現したり、IPFS や運用上必要な場合は中央集権型ストアとも併用したりできます。暗号化の境界とポリシーの適用は、暗号文がどこに存在してもデータとともに移動します。

Seal を設計に組み込むためのベストプラクティス

  • 可用性リスクをモデリングする: 2-of-3 や 3-of-5 などのしきい値は、そのまま稼働率保証に直結します。本番導入ではプロバイダーを組み合わせ、テレメトリを監視し、重要なワークフローを任せる前に SLA を取り決めましょう。
  • 状態のばらつきに注意: ポリシー評価はフルノードの dry_run 呼び出しに依存します。急速に変化するカウンターやチェックポイント内の順序に依存するルールは避け、サーバー間で不一致の承認が出ないようにしてください。
  • 鍵の衛生管理を計画する: 導出された鍵はクライアント側に保存されます。ログを整備し、セッションキーをローテーションし、必要に応じてエンベロープ暗号化(Seal で大きなペイロードを暗号化する対称鍵を保護)を採用して、端末侵害時の影響範囲を限定しましょう。
  • ローテーションを設計する: 暗号文の委員会構成は暗号化時点で固定されます。プロバイダーを変更したり信頼モデルを調整したりする必要がある場合に備えて、データを新しい委員会で再暗号化するアップグレード経路を用意しましょう。

今後の展望

Seal のロードマップには、バリデータが運用する MPC サーバー、DRM スタイルのクライアントツール、ポスト量子 KEM などが示されています。AI エージェント、プレミアムコンテンツ、規制対象データフローを検討するビルダーにとって、今回のリリースだけでも十分な設計図が得られます。Move でポリシーを記述し、多様なキー委員会を組み合わせ、Sui の信頼境界内でユーザープライバシーを尊重する暗号化体験を提供しましょう。

次回のローンチで Seal の採用を検討しているなら、まずは 2-of-3 のオープン委員会を使ったシンプルな NFT ゲートポリシーを試作し、アプリのリスクプロファイルに合ったプロバイダー構成と運用コントロールへとブラッシュアップしていくのがおすすめです。

Sui Paymasterでガスレス体験を構築する:アーキテクチャと実装ガイド

· 約 10 分
Dora Noda
Software Engineer

ユーザーがネイティブトークン(SUI)を保持せずに dApp とシームレスにやり取りできる世界を想像してください。これはもはや遠い夢ではありません。Sui の Gas Station(Paymaster とも呼ばれる)を利用すれば、開発者がユーザーに代わってガス代を負担でき、Web3 への新規参入障壁を大幅に下げ、真に摩擦のないオンチェーン体験を実現できます。

本記事では、dApp をガスレス化するための完全ガイドを提供します。Sui Paymaster のコア概念、アーキテクチャ、実装パターン、ベストプラクティスを徹底解説します。

1. 背景とコアコンセプト:スポンサー付きトランザクションとは?

ブロックチェーンの世界では、すべてのトランザクションにネットワーク手数料(「ガス」)が必要です。Web2 のシームレスな体験に慣れたユーザーにとって、これは大きな認知的・操作的ハードルとなります。Sui はこの課題に対し、プロトコルレベルで スポンサー付きトランザクション を提供しています。

基本的な考え方はシンプルです。ある当事者(スポンサー)が別の当事者(ユーザー)のトランザクションに対して SUI ガス代を支払うことを許可します。これにより、ユーザーのウォレットに SUI がゼロでもオンチェーンアクションを実行できます。

Paymaster ≈ Gas Station

Sui エコシステムでは、スポンサー付きトランザクションのロジックは通常、オフチェーンまたはオンチェーンのサービス Gas Station(または Paymaster)が担います。その主な責務は以下の通りです。

  1. トランザクションの評価:ユーザーから送られたガスレストランザクションデータ(GasLessTransactionData)を受け取ります。
  2. ガスの提供:必要なガス代をロックし、割り当てます。これは多数の SUI Coin オブジェクトで構成されたガスプールで管理されます。
  3. スポンサー署名の生成:スポンサーシップを承認した後、Gas Station はプライベートキーでトランザクションに署名(SponsorSig)し、支払い意思を証明します。
  4. 署名済みトランザクションの返却:ガス情報とスポンサー署名が付加された TransactionData を返し、ユーザーの最終署名を待ちます。

要するに、Gas Station は dApp ユーザーの「車」(トランザクション)に燃料を供給するリフューリングサービスです。

2. ハイレベルアーキテクチャとインタラクションフロー

典型的なガスレス取引は、ユーザー、dApp フロントエンド、Gas Station、Sui フルノードの 4 つが協調して動作します。シーケンスは以下の通りです。

フローの分解

  1. ユーザー が dApp UI 上でアクションを起こし、ガス情報なしのトランザクションデータを生成します。
  2. dApp がこのデータを指定された Gas Station に送信し、スポンサーシップを依頼します。
  3. Gas Station がリクエストの妥当性(例:ユーザーがスポンサー対象か)を検証し、ガスコインと署名を付与した半完成トランザクションを dApp に返します。
  4. ユーザー はウォレット上で最終取引内容(例:「NFT を 1 枚購入」)を確認し、最終署名を行います。これにより、ユーザーは自らの意思とコントロールを保持します。
  5. dApp はユーザー署名とスポンサー署名の両方が入った完全トランザクションを Sui フルノード に送信します。
  6. トランザクションがオンチェーンで確定した後、Gas Station はイベントやレシートを監視し、必要に応じて Webhook で dApp に成功を通知できます。

3. 3 つのコアインタラクションモデル

ビジネス要件に合わせて、以下の 3 つのモデルを単独または組み合わせて利用できます。

モデル 1:ユーザー発起 → スポンサー承認(最も一般的)

標準的なモデルで、ほとんどの dApp インタラクションに適しています。

  1. ユーザーが GasLessTransactionData を構築:dApp 内でアクションを実行。
  2. スポンサーが GasData を付与し署名:dApp バックエンドが Gas Station に送信し、ガスコインとスポンサー署名を取得。
  3. ユーザーが最終署名:ウォレットで取引内容を確認し署名。dApp がネットワークに送信。

セキュリティとユーザー体験のバランスが最適です。

モデル 2:スポンサー発起のエアドロップ/インセンティブ

エアドロップや報酬付与、バッチ配布に最適です。

  1. スポンサーが TransactionData を事前に作成し署名:プロジェクト側が取引(例:NFT エアドロップ)を組み立て、スポンサー署名を付与。
  2. ユーザーの二重署名で実行:ユーザーは「事前承認済み」取引に対して 1 回だけ署名すれば完了。

クリック一つで報酬受取やタスク完了が可能になり、コンバージョン率が大幅に向上します。

モデル 3:ワイルドカード GasData(クレジットラインモデル)

柔軟かつ許可ベースのモデルです。

  1. スポンサーが GasData オブジェクトを転送:予算上限と有効期間を設定したガスコインをユーザーに直接所有権移転。
  2. ユーザーは予算内で自由に使用:ユーザーはこのガスコインで任意の取引を支払える。
  3. ガスコインの回収:残高がなくなるか期限切れになると、自動的に破棄またはスポンサーへ返却できるよう設計。

実質的に「ガス手数料クレジットカード」をユーザーに提供するイメージで、ゲームシーズン中のフリープレイ体験などに最適です。

4. 典型的な活用シナリオ

Sui Paymaster の価値はガス代問題の解決だけでなく、ビジネスロジックと深く統合できる点にあります。

シナリオ 1:ペイウォール

コンテンツプラットフォームや dApp サービスで、特定条件(例:VIP NFT 保有、会員レベル)を満たすユーザーのみ機能を提供したい場合。

  • フロー:ユーザーがアクション要求 → dApp バックエンドが資格(NFT 所有等)を検証 → 条件合致なら Paymaster がガス代をスポンサー、合致しなければ署名リクエストを拒否。
  • メリット:バックエンドで資格判定を行うため、ボットや不正利用に強い。スポンサー資金が無駄に消費されるリスクが低減。

シナリオ 2:ワンクリック決済

e コマースやゲーム内購入で、決済プロセスを極限まで簡素化したい場合。

  • フロー:ユーザーが「今すぐ購入」ボタンをクリック → dApp が transfer_nft_to_user 等のビジネスロジックを組み込んだトランザクションを生成 → ユーザーはビジネスロジックに対して署名するだけで、ガス代はスポンサーが負担。
  • メリットorder_id などのビジネスパラメータを ProgrammableTransactionBlock に直接埋め込めるため、オンチェーン上で正確な注文紐付けが可能。

シナリオ 3:データアトリビューション

ビジネス最適化に不可欠な正確なデータトラッキング。

  • フロー:トランザクション生成時に一意の識別子(例:order_hash)をパラメータやイベントに書き込む。
  • メリット:Gas Station が成功レシートを取得した際に、イベントやトランザクションデータから order_hash を抽出でき、オンチェーン状態変化とバックエンド注文を正確に紐付けられる。

5. コードスケルトン(Rust SDK ベース)

以下はコアインタラクションを示す簡易コード例です。

// Assume tx_builder, sponsor, and wallet have been initialized

// Step 1: On the user or dApp side, construct a gas-less transaction
let gasless_transaction_data = tx_builder.build_gasless_transaction_data(false)?;

// Step 2: On the Sponsor (Gas Station) side, receive the gasless_transaction_data,
// fill it with a Gas Coin, and return the transaction data with the Sponsor's signature.
// The sponsor_transaction_block function handles gas allocation and signing internally.
let sponsored_transaction = sponsor.sponsor_transaction_block(gasless_transaction_data, user_address, gas_budget)?;

// Step 3: The dApp sends the sponsored_transaction back to the user,
// who signs and executes it with their wallet.
let response = wallet.sign_and_execute_transaction_block(&sponsored_transaction)?;

完全な実装例は、公式 Sui ドキュメントの Gas Station Tutorial を参照してください。

6. リスクと保護策

強力な機能である一方、プロダクション環境で Gas Station を運用する際は以下のリスクに注意が必要です。

  • 二重支払い(Equivocation):悪意あるユーザーが同一の Gas Coin を並行して複数トランザクションに使用しようとすると、Sui ネットワークでコインがロックされます。対策としては、ユーザーまたはトランザクションごとに一意の Gas Coin を割り当て、ブラックリストやレートリミットで署名リクエストを制御します。
  • ガスプール管理:高並列環境では、単一の大口 SUI Coin がボトルネックになる可能性があります。Gas Station は大口コインを自動的に多数の小口コインに分割し、使用後に再集約できる仕組みが必須です。Shinami などのプロバイダーは成熟したマネージドサービスを提供しています。
  • 認可とレートリミティング:厳格な認可ポリシーとレートリミットを設定し、IP、ウォレットアドレス、API トークン単位でスポンサーシップの上限や頻度を管理しないと、サービスが枯渇する危険があります。

7. エコシステムツール

Sui エコシステムは Paymaster 開発・デプロイを支援するツールが豊富です。

  • 公式 SDK(Rust / TypeScript)sponsor_transaction_block() などの高レベル API が用意されており、統合コストを大幅に削減。
  • Shinami Gas Station:ガスコインの自動分割・回収、メトリクス監視、Webhook 通知を含むフルマネージドサービスで、ビジネスロジックに集中できます。
  • Enoki / Mysten デモ:コミュニティや Mysten Labs が提供するオープンソース実装が多数あり、独自サービス構築時のリファレンスとして活用可能。

8. 実装チェックリスト

ガスレス時代への dApp アップグレードを始める前に、以下の項目を必ず確認してください。

  • 資金フローの設計:スポンサー資金の出所、予算、補充戦略を定義し、ガスプール残高や消費レートの監視アラートを設定。
  • アトリビューションフィールドの確保:取引パラメータに order_iduser_id などビジネス識別子用のフィールドを予約。
  • 不正防止ポリシーの導入:認可、レートリミット、ロギングを本番前に実装。
  • テストネットでのリハーサル:独自サービスでもサードパーティ Gas Station でも、テストネット/デブネットで同時実行・負荷テストを徹底。
  • 継続的最適化:ローンチ後は成功率、失敗要因、ガスコストを定期的に分析し、予算や戦略をチューニング。

結論

Sui Paymaster(Gas Station)は、単なるガス代負担ツールを超えたパラダイムです。「SUI を持たない」ユーザー体験と「取引単位でのオンチェーンアトリビューション」を同時に実現でき、開発者はビジネスロジックに専念できます。この記事で紹介した概念・アーキテクチャ・実装パターンを活用し、次世代のシームレスな dApp を構築しましょう。

BlockEden.xyzでSUIトークンステーキングを導入:ワンクリックで簡単に2.08% APYを獲得

· 約 8 分
Dora Noda
Software Engineer

BlockEden.xyzで SUI トークンステーキング の開始をお知らせできることを嬉しく思います!本日から、当プラットフォームを通じて SUI トークンを直接ステーキングし、 2.08% の APY を獲得しながら SUI ネットワークのセキュリティと分散化を支援できます。

新機能:シームレスな SUI ステーキング体験

新しいステーキング機能は、シンプルで直感的なインターフェースにより、機関レベルのステーキングを誰でも手軽に利用できるようにします。

主な特徴

ワンクリックステーキング
SUI のステーキングはこれまでになく簡単です。Suisplash ウォレットを接続し、ステーキングしたい SUI の数量を入力してトランザクションを承認するだけで、ほぼ即座に報酬が得られます。

競争力のある報酬
ステーキングした SUI に対して 2.08% の APY を提供します。報酬からは 8% の手数料 が差し引かれますが、手数料は透明で事前に把握できます。報酬は各エポック終了時に毎日分配されます。

信頼できるバリデータ
すでに 2,200 万 SUI をステーキングしている BlockEden.xyz バリデータのコミュニティに参加できます。当バリデータは実績のある信頼性の高いサービスを提供し、 99.9% の稼働率 を誇ります。

柔軟な管理
ステーキングは即時に反映され、報酬はすぐに蓄積され始めます。資金が必要な場合はいつでもアンステーク手続きを開始でき、標準的な SUI ネットワークのアンボンド期間(24〜48 時間)後に SUI が利用可能になります。ダッシュボードでステークと報酬をリアルタイムに確認できます。

なぜ BlockEden.xyz で SUI をステーキングするのか?

バリデータ選択は重要な決断です。以下の理由から BlockEden.xyz は信頼できる選択肢です。

信頼性

BlockEden.xyz は創業以来、ブロックチェーンインフラの要として多くのエンタープライズアプリケーションを支えてきました。複数ネットワークで高い稼働率を維持し、安定した報酬生成を実現しています。

透明性と公平性

隠れた手数料は一切ありません。報酬の 8% 手数料 が明示されており、リアルタイムのレポートでステーキングパフォーマンスを監視できます。オンチェーンでバリデータの活動を検証可能です。

  • 公開バリデータアドレス: 0x3b5664bb0f8bb4a8be77f108180a9603e154711ab866de83c8344ae1f3ed4695

シームレスな統合

アカウント作成は不要で、ウォレットから直接ステーキングできます。Suisplash ウォレットに最適化されたクリーンで直感的な UI は、初心者から上級者まで快適に利用できます。

始め方

BlockEden.xyz で SUI ステーキングを開始するのにかかる時間は 2 分未満です。

ステップ 1:ステーキングページへ移動

blockeden.xyz/dash/stake にアクセスしてください。アカウント登録は不要ですぐに手続きを開始できます。

ステップ 2:ウォレットを接続

まだインストールしていない場合は、Suisplash ウォレット をインストールしてください。ステーキングページの「Connect Wallet」ボタンをクリックし、拡張機能で接続を承認します。SUI 残高が自動的に表示されます。

ステップ 3:ステーク金額を選択

ステーキングしたい SUI の数量(最低 1 SUI)を入力します。「MAX」ボタンで利用可能残高全額をステークでき、ガス代分だけ少量を残すことができます。サマリーにステーク金額と年間推定報酬が表示されます。

ステップ 4:確認して獲得開始

「Stake SUI」ボタンをクリックし、ウォレットで最終トランザクションを承認します。新しいステークがダッシュボードにリアルタイムで表示され、即座に報酬が蓄積され始めます。

ステーキング経済学:知っておくべきこと

ステーキングの仕組みを理解することは、資産管理の鍵です。

報酬構造

  • 基本 APY2.08% 年率
  • 報酬頻度:各エポック(約 24 時間)ごとに分配
  • 手数料:報酬の 8%
  • 複利:報酬はウォレットに自動的に追加され、再ステークで複利効果が得られます。

例:想定収益

以下は 2.08% の APY と 8% 手数料を考慮した概算です。

ステーク金額年間報酬月間報酬日間報酬
100 SUI2.08 SUI0.17 SUI0.0057 SUI
1,000 SUI20.8 SUI1.73 SUI0.057 SUI
10,000 SUI208 SUI17.3 SUI0.57 SUI

注:上記は概算です。実際の報酬はネットワーク状況により変動します。

リスク考慮事項

  • アンボンド期間:アンステーク後は 24〜48 時間アクセスできず、報酬も発生しません。
  • バリデータリスク:高い基準を維持していますが、バリデータには運用リスクが伴います。信頼できるバリデータ選択が重要です。
  • ネットワークリスク:ステーキングはブロックチェーンプロトコル固有のリスクに依存します。
  • 市場リスク:SUI トークンの価格変動により、ステーク資産の総価値が変わります。

技術的卓越性

エンタープライズインフラ

バリデータノードは冗長構成で複数地域に分散し、高可用性を実現しています。24 時間体制の監視と自動フェイルオーバーに加え、専門チームが常時運用・保守を行っています。定期的なセキュリティ監査とコンプライアンスチェックも実施しています。

オープンソースと透明性

オープンソースの精神を重視し、ステーキング統合は誰でもプロセスを検証できるように設計しています。リアルタイムメトリクスは SUI ネットワークエクスプローラーで公開され、手数料構造は完全にオープンです。コミュニティガバナンスにも積極的に参加し、SUI エコシステムの発展を支援しています。

SUI エコシステムへの貢献

BlockEden.xyz でステーキングすることで、単なる報酬獲得以上の価値を提供します。

  • ネットワークセキュリティ:ステーク額が増えるほど SUI ネットワークは堅牢になります。
  • 分散化:独立したバリデータを支えることで、ネットワークの耐障害性と分散性が向上します。
  • エコシステム成長:手数料収入はインフラ維持・開発に再投資されます。
  • イノベーション:収益はブロックチェーンコミュニティ向け新ツール・サービスの研究開発に活用されます。

セキュリティとベストプラクティス

資産の安全を最優先してください。

ウォレットのセキュリティ

  • 決して プライベートキーやシードフレーズを他人と共有しない。
  • 大量の資産はハードウェアウォレットで保管・ステーキングする。
  • 署名前にトランザクション内容を必ず確認する。
  • ウォレットソフトは常に最新バージョンに保つ。

ステーキングの安全性

  • 初めての場合は少額から始め、手順に慣れる。
  • 複数の信頼できるバリデータに分散ステークしてリスクを低減。
  • ステーク資産と報酬を定期的にモニタリング。
  • アンボンド期間を十分に理解した上で資金をロックする。

SUI ステーキングの未来へ

BlockEden.xyz の SUI ステーキング開始は新機能に留まらず、分散型経済への積極的な参加へのゲートウェイです。DeFi の経験者も、これから始める方も、シンプルかつ安全に報酬を得ながら SUI ネットワークの未来を共に築きましょう。

今すぐ始めませんか?

blockeden.xyz/dash/stake にアクセスし、最初の SUI トークンをステークしてください!


BlockEden.xyz について

BlockEden.xyz は、開発者、エンタープライズ、そして広範な Web3 コミュニティに向けて、信頼性・スケーラビリティ・セキュリティに優れたブロックチェーンインフラサービスを提供するリーディングカンパニーです。API サービスからバリデータ運用まで、分散型未来の基盤構築に注力しています。

  • 設立:2021 年
  • 対応ネットワーク:15 以上のブロックチェーン
  • エンタープライズクライアント:500 社以上(全世界)
  • 保護総額:100 億ドル以上(全ネットワーク合計)

TwitterDiscord、公式サイトで最新情報をご確認ください。

*免責事項:本記事は情報提供を目的としており、金融アドバイスではありません。暗号資産のステーキングには元本割れリスクを含む様々なリスクが伴います。ご自身で十分に調査し、リスク許容度をご確認の上でご利用ください。

Sui のリファレンス ガス価格 (RGP) メカニズム

· 約 9 分
Dora Noda
Software Engineer

はじめに

2023 年 5 月 3 日に公開ローンチが発表され、3 段階にわたるテストネットを経て、Sui ブロックチェーンはユーザーとバリデータの双方に利益をもたらす革新的なガス価格システムを導入しました。その中心にあるのが リファレンス ガス価格(RGP) で、エポック開始時(約 24 時間ごと)にバリデータが合意するネットワーク全体のベースガス料金です。

このシステムは、SUI トークン保有者、バリデータ、エンドユーザーに対し、低く予測可能な取引コストを提供すると同時に、パフォーマンスが高く信頼できるバリデータに報酬を与えることで、相互に利益をもたらすエコシステムの構築を目指しています。本レポートでは、RGP の算出方法、バリデータが行う計算、ネットワーク経済への影響、ガバナンスによる進化、そして他のブロックチェーンのガスモデルとの比較について詳しく解説します。

リファレンス ガス価格(RGP)メカニズム

Sui の RGP は固定値ではなく、エポックごとに動的かつバリデータ主導のプロセスで再設定されます。

  • ガス価格サーベイ: 各エポック開始時に、すべてのバリデータが「予約価格」―取引処理に受け入れる最低ガス価格―を提出します。プロトコルはステーク量でこれらの提出を並べ替え、ステーク加重 2/3 パーセンタイル をそのエポックの RGP とします。この設計により、総ステークの少なくとも 3 分の 2 を占めるバリデータがこの価格で取引を処理する意思があることが保証され、信頼性の高いサービスレベルが確保されます。

  • 更新頻度と要件: RGP はエポックごとに設定されますが、バリデータは見積もりを積極的に管理する必要があります。公式ガイダンスによれば、バリデータは 少なくとも週に一度 ガス価格見積もりを更新しなければなりません。さらに、SUI トークンの価値が 20% 以上変動 した場合は、即座に見積もりを更新して RGP が現在の市場状況を正確に反映するようにします。

  • 集計ルールと報酬分配: バリデータが合意した RGP を遵守しているかを保証するため、Sui は「集計ルール」を採用しています。エポック中、バリデータは互いのパフォーマンスを監視し、ピアが RGP 価格の取引を迅速に処理しているかを追跡します。この監視により各バリデータにパフォーマンススコアが付与され、エポック終了時にそのスコアを用いて報酬乗数が算出され、ステーク報酬のシェアが調整されます。

    • パフォーマンスが良好なバリデータは ≥1 の乗数を受け取り、報酬が増加します。
    • 処理が遅延・停止・RGP 価格で処理できなかったバリデータは <1 の乗数が適用され、報酬の一部が削減されます。

この二段階システムは強力なインセンティブ構造を生み出します。バリデータが支えきれないほど低い価格を提示すると、パフォーマンス不足に対する金銭的ペナルティが甚大になるため、現実的かつ持続可能な最低価格を提示する動機付けが働きます。


バリデータの業務: ガス価格見積もりの算出

バリデータにとって RGP 見積もりを設定することは、収益性に直結する重要な業務です。オンチェーン・オフチェーン両方のデータを処理するためのパイプラインと自動化レイヤーの構築が必要となります。主な入力項目は以下の通りです。

  • エポックあたりの実行ガスユニット数
  • エポックあたりのステーク報酬と補助金
  • ストレージファンドへの拠出
  • SUI トークンの市場価格
  • 運用コスト(ハードウェア、クラウドホスティング、保守)

目的は、純利益がプラスになる見積もりを算出することです。以下の主要な式が使用されます。

  1. 総運用コストの算出: エポックごとの法定通貨ベースのコストを求めます。

    Costepoch=(Total Gas Units Executedepoch)×(Cost in USD per Gas Unitepoch)\text{Cost}_{\text{epoch}} = (\text{Total Gas Units Executed}_{\text{epoch}}) \times (\text{Cost in USD per Gas Unit}_{\text{epoch}})
  2. 総報酬の算出: プロトコル補助金と取引手数料の両方から得られる法定通貨ベースの総収入を求めます。

    USD Rewardsepoch=(Total Stake Rewards in SUIepoch)×(SUI Token Price)\text{USD Rewards}_{\text{epoch}} = (\text{Total Stake Rewards in SUI}_{\text{epoch}}) \times (\text{SUI Token Price})

    ここで Total Stake Rewards は、プロトコル提供の Stake Subsidies と取引から徴収された Gas Fees の合計です。

  3. 純報酬の算出: バリデータの最終的な収益性指標です。

    USD Net Rewardsepoch=USD RewardsepochUSD Costepoch\text{USD Net Rewards}_{\text{epoch}} = \text{USD Rewards}_{\text{epoch}} - \text{USD Cost}_{\text{epoch}}

    さまざまな RGP 水準で期待コストと報酬をモデル化することで、バリデータはガス価格サーベイに提出すべき最適な見積もりを決定できます。

メインネット開始時、Sui は最初の 1〜2 週間にわたり固定 1,000 MIST(1 SUI = 10⁹ MIST)を初期 RGP としました。これにより、バリデータは十分なネットワーク活動データを蓄積し、動的サーベイが本格的に機能する前に計算プロセスを確立できました。


Sui エコシステムへの影響

RGP メカニズムはネットワーク全体の経済とユーザー体験に大きな影響を与えます。

  • ユーザー向け: 予測可能で安定した手数料 RGP はユーザーにとって信頼できる基準となります。取引のガス料金はシンプルに User Gas Price = RGP + Tip で算出されます。通常はチップ不要です。ネットワークが混雑した際はチップを付与して優先度を上げられ、エポック内のベース価格は変わらないため、手数料の安定性が大幅に向上します。ブロックごとにベース料金が変動するシステムに比べ、はるかに安定しています。

  • バリデータ向け: 効率性への競争 バリデータは運用コストを削減(ハードウェア・ソフトウェア最適化)することで、低い RGP を利益を確保しながら提示できるようになります。この「効率性への競争」は、取引コスト全体の低減につながり、ネットワーク全体に利益をもたらします。RGP が高すぎると計算から外れ、低すぎると運用損失とパフォーマンスペナルティが発生するため、バリデータはバランスの取れた利益率を目指すことになります。

  • ネットワーク全体: 分散化と持続可能性 新規参入の効率的なバリデータが価格を引き下げる「参入脅威」により、既存バリデータが価格を固定化して共謀するリスクが抑制されます。また、SUI トークンの市場価格に応じて見積もりを調整することで、バリデータは実際のコスト構造に合わせて運営でき、トークン価格変動による手数料経済への影響を緩和します。


ガバナンスとシステム進化: SIP-45

Sui のガスメカニズムは静的ではなく、ガバナンスを通じて進化します。代表的な例が SIP-45(優先取引送信) で、手数料ベースの優先順位付けを改善するために提案されました。

  • 解決された課題: 高いガス価格を支払っても必ずしも取引が早く取り込まれるわけではないという分析結果。
  • 提案内容: 最大許容ガス価格の引き上げと、RGP の 5 倍以上のガス価格で支払う取引に対して「拡張ブロードキャスト」を導入し、ネットワーク全体に迅速に伝搬させて優先的に取り込む仕組みを追加。

このように、実証データに基づきガスモデルを継続的に改善する姿勢が示されています。


他ブロックチェーンのガスモデルとの比較

Sui の RGP モデルは、特に Ethereum の EIP-1559 と比較すると独自性が際立ちます。

項目Sui(リファレンス ガス価格)Ethereum(EIP-1559)
ベース料金の決定方法バリデータサーベイ(エポック単位・市場駆動)アルゴリズム(ブロック単位・プロトコル駆動)
更新頻度エポックごと(約 24 時間)各ブロックごと(約 12 秒)
手数料の行き先すべての手数料(RGP + tip)がバリデータへ分配ベース料金は バーン、チップのみがバリデータへ
価格安定性高い。日々の変動が予測可能中程度。需要急増で急騰することがある
バリデータインセンティブ低い RGP を提示できる効率性競争が報酬に直結チップ最大化が主目的、ベース料金は制御不可

潜在的な批判と課題

革新的な設計にもかかわらず、RGP メカニズムにはいくつかの課題が指摘されています。

  • 複雑性: サーベイ、集計ルール、オフチェーン計算の全体像は新規バリデータにとって学習コストが高い可能性があります。
  • スパイクへの遅延反応: RGP はエポック単位で固定されるため、エポック途中の急激な需要増加に即座に対応できず、ユーザーがチップを付与するまで一時的な混雑が発生します。
  • 共謀のリスク: 理論上、バリデータが協調して高い RGP を設定する可能性がありますが、オープンなバリデータセットの競争性がリスクを抑制します。
  • バーンがない: Ethereum のようにベース料金をバーンすることでトークン供給を減少させるインフレ抑制効果がない点が指摘されます。

まとめ

Sui のリファレンス ガス価格(RGP)メカニズムは、ステークホルダー主導の動的価格設定とバリデータへの直接的なインセンティブを組み合わせた、予測可能で安定した手数料体系を実現する画期的なアプローチです。ユーザーは取引コストを事前に把握でき、バリデータは効率性競争を通じて報酬を最大化できます。ガバナンスによる継続的な改善と、他チェーンとの明確な差別化により、Sui は独自のエコノミクスを構築しています。今後のアップデートや提案(例: SIP-45)に注目しつつ、エコシステム全体の分散化と持続可能性を支える重要な要素として、RGP メカニズムは引き続き注目されるでしょう。

\end{document}

zkLogin による摩擦のないオンランプ

· 約 9 分
Dora Noda
Software Engineer

ウォレットの摩擦を解消し、ユーザーの流入を維持し、成長の可能性を予測する方法

Web3 アプリが現代の Web2 サービスと同じようにシームレスなサインアップフローを持っていたらどうでしょうか?それが Sui ブロックチェーンにおける zkLogin の核となる約束です。これは Sui のための OAuth のように機能し、ユーザーは Google 、 Apple 、 X などの使い慣れたアカウントでサインインできます。その後、ゼロ知識証明(ZKP)によって、その Web2 の ID がオンチェーンの Sui アドレスに安全に紐付けられます。ウォレットのポップアップ、シードフレーズ、ユーザーの離脱はもうありません。

その影響は現実的かつ即座に現れます。すでに数十万の zkLogin アカウントが稼働しており、ケーススタディでは、従来のウォレットの障壁を取り除いた後、ユーザーのコンバージョン率がわずか 17% から 42% へと大幅に向上したことが報告されています。これがどのように機能し、あなたのプロジェクトに何をもたらすのかを詳しく見ていきましょう。


なぜウォレットが初回コンバージョンを妨げるのか

あなたは画期的な dApp を構築しましたが、ユーザー獲得のファネルからユーザーが流出しています。その原因のほとんどは常に同じ、「ウォレットを接続(Connect Wallet)」ボタンです。標準的な Web3 のオンボーディングは、拡張機能のインストール、シードフレーズの警告、そして暗号資産の専門用語のクイズといった迷路のようなものです。

これは初心者にとって非常に大きな障壁です。UX 研究者によると、ウォレットのプロンプトが表示された瞬間に 87% という驚異的な離脱 が観察されました。ある興味深い実験では、そのプロンプトをチェックアウトプロセスの後の段階に移動させるだけで、完了率が 94% に跳ね上がりました。暗号資産に興味があるユーザーでさえ、主な恐怖は「間違ったボタンをクリックすると資金を失うかもしれない」というものです。このたった一つの威圧的なステップを取り除くことが、飛躍的な成長を解き放つ鍵となります。


zkLogin の仕組み(わかりやすい解説)

zkLogin は、すべてのインターネットユーザーがすでに信頼している技術を使用することで、ウォレットの問題をエレガントに回避します。その魔法は、舞台裏でいくつかの迅速なステップによって行われます:

  1. 一時的なキーペア(Ephemeral Key Pair): ユーザーがサインインしようとすると、ブラウザ内でローカルに一時的なシングルセッションキーペアが生成されます。これは、このセッションの間だけ有効な一時的なパスキーのようなものだと考えてください。
  2. OAuth のプロセス: ユーザーは Google 、 Apple 、またはその他のソーシャルアカウントでサインインします。アプリはこのログインリクエストに、一意の値(ナンス / nonce)を巧みに埋め込みます。
  3. ZKP サービス: ログインに成功すると、ZKP(ゼロ知識証明)サービスが暗号化された証明を生成します。この証明は、ユーザーの個人的な身元をオンチェーンで明かすことなく、「この OAuth トークンは一時的なパスキーの所有者を認証するものである」ことを確認します。
  4. アドレスの導出: OAuth プロバイダーからのユーザーの JWT(JSON Web Token)と一意の ソルト(salt) を組み合わせて、永続的な Sui アドレスを決定論的に生成します。ソルトはクライアント側または安全なバックエンドで秘密に保持されます。
  5. トランザクションの送信: アプリは一時的なキーでトランザクションに署名し、ZK 証明を添付します。Sui のバリデータはオンチェーンで証明を検証し、ユーザーが従来のウォレットを必要とすることなく、トランザクションの正当性を確認します。

ステップバイステップ導入ガイド

準備はできましたか?ここでは TypeScript SDK を使用したクイックガイドを紹介します。原理は Rust や Python でも同じです。

1. SDK のインストール

@mysten/sui パッケージには、必要なすべての zklogin ヘルパーが含まれています。

pnpm add @mysten/sui

2. キーとナンスの生成

まず、一時的なキーペアと、Sui ネットワーク上の現在のエポック(epoch)に関連付けられたナンスを作成します。

const keypair = new Ed25519Keypair();
const { epoch } = await suiClient.getLatestSuiSystemState();
const nonce = generateNonce(keypair.getPublicKey(), Number(epoch) + 2, generateRandomness());

3. OAuth へのリダイレクト

使用しているプロバイダー(Google 、 Facebook 、 Apple など)に適した OAuth ログイン URL を構築し、ユーザーをリダイレクトします。

4. JWT のデコードとユーザーソルトの取得

ユーザーがログインしてリダイレクトで戻ってきた後、URL から id_token を取得します。それを使用してバックエンドからユーザー固有のソルトを取得し、Sui アドレスを導出します。

const jwt = new URLSearchParams(window.location.search).get('id_token')!;
const salt = await fetch('/api/salt?jwt=' + jwt).then(r => r.text());
const address = jwtToAddress(jwt, salt);

5. ZK 証明のリクエスト

JWT をプルーバー(prover)サービスに送信して ZK 証明を取得します。開発用には Mysten の公開プルーバーを使用できます。本番環境では、独自にホストするか、Enoki のようなサービスを使用する必要があります。

const proof = await fetch('/api/prove', {
method:'POST',
body: JSON.stringify({ jwt, ... })
}).then(r => r.json());

6. 署名と送信

次に、トランザクションを構築し、送信者をユーザーの zkLogin アドレスに設定して実行します。SDK が zkLoginInputs(証明)の添付を自動的に処理します。 ✨

const tx = new TransactionBlock();
tx.moveCall({ target:'0x2::example::touch_grass' }); // 任意の Move 呼び出し
tx.setSender(address);
tx.setGasBudget(5_000_000);

await suiClient.signAndExecuteTransactionBlock({
transactionBlock: tx,
zkLoginInputs: proof // ここで魔法が起こります
});

7. セッションの維持

よりスムーズなユーザー体験のために、キーペアとソルトを暗号化して IndexedDB やローカルストレージに保存します。セキュリティ向上のため、数エポックごとにこれらをローテーションすることを忘れないでください。


KPI 予測テンプレート

zkLogin がもたらす違いは、単なる質的なものではなく、数値化できるものです。一般的なオンボーディング・ファネルと、zkLogin を活用したファネルを比較してみましょう。

ファネルの段階一般的なウォレットポップアップzkLogin 利用時差分
ランディング → サインイン100 %100 %
サインイン → ウォレットの準備完了15 % (インストール、シードフレーズ)55 % (ソーシャルログイン)+40 pp
ウォレットの準備完了 → 初回トランザクション~23 %~90 %+67 pp
全体的なトランザクション・コンバージョン率~3 %≈ 25-40 %~8-13 倍

👉 この数値が意味すること: 10,000 人のユニークビジターを誘導するキャンペーンにおいて、初日のオンチェーンアクションが 300 件にとどまるか、2,500 件を超えるかの違いになります。


ベストプラクティスと注意点

さらにシームレスな体験を提供するために、以下のプロのヒントを参考にしてください。

  • スポンサー付きトランザクション (Sponsored Transactions) を活用する: ユーザーの最初の数回のトランザクション手数料を肩代わりしましょう。これにより、あらゆる摩擦が取り除かれ、驚くほどスムーズな「アハ体験」を提供できます。
  • ソルト (Salts) の扱いに注意する: ユーザーのソルトを変更すると、新しいアドレスが生成されます。信頼できるリカバリパスを管理している場合にのみ行ってください。
  • Sui アドレスを表示する: サインアップ後、ユーザーにオンチェーンアドレスを表示しましょう。これにより、上級ユーザーが後で必要に応じて、従来のウォレットにアドレスをインポートできるようになります。
  • リフレッシュループを防止する: JWT と一時的なキーペア (ephemeral keypair) を有効期限が切れるまでキャッシュし、ユーザーに繰り返しログインを求めないようにします。
  • プルーバーのレイテンシを監視する: 証明生成 (proof-generation) の往復時間に注意してください。2 秒を超える場合は、レスポンスを速く保つために、リージョンごとのプルーバーのホスティングを検討してください。

BlockEden.xyz が提供する価値

zkLogin はユーザー向けのフローを最適化しますが、それをスケールさせるにはバックエンドの新たな課題が生じます。そこで BlockEden.xyz の出番です。

  • API レイヤー: 当社の高スループットで地理的にルーティングされた RPC ノードは、ユーザーの場所に関係なく、zkLogin トランザクションを最小限のレイテンシで処理することを保証します。
  • オブザーバビリティ (観測可能性): 証明のレイテンシ、成功/失敗の比率、コンバージョンファネルの健全性などの主要な指標を追跡するための、標準搭載のダッシュボードを提供します。
  • コンプライアンス: 法定通貨へのブリッジを行うアプリ向けに、オプションの KYC モジュールを提供しており、ユーザーの確認済み ID から直接コンプライアンスに準拠したオンランプ (入金) が可能です。

リリースの準備はいいですか?

扱いにくく、威圧的なウォレットフローの時代は終わりました。zkLogin サンドボックスを立ち上げ、BlockEden のフルノードエンドポイントを接続して、ユーザーに「ウォレット」という言葉を一切意識させることなく、サインアップのグラフが右肩上がりに伸びていく様子を見守りましょう。 😉

2025年のSui DeFiエコシステム:流動性、アブストラクション、そして新しいプリミティブ

· 約 31 分
Dora Noda
Software Engineer

1. Sui DeFiの流動性と成長

図:SuiのDeFi TVL(青線)とDEXボリューム(緑の棒グラフ)は、2025年第2四半期にかけて劇的に成長しました。

TVL(預かり資産総額)の急増: SuiネットワークのDeFi流動性は、この1年で爆発的に成長しました。2024年末時点の約6億ドルのTVLから、SuiのTVLは2025年中盤までに20億ドル以上へと急上昇しました。実際、Suiは2025年5月21日に約25.5億ドルのTVLでピークに達し、第2四半期の大部分で20億ドルを大きく上回る水準を維持しました。この約300%以上の増加(2023年5月比で前年比480%増)により、SuiはDeFi TVLでトップ10のブロックチェーンに確固たる地位を築き、Solanaなどのネットワークを上回る成長を遂げました。主な要因には、機関投資家の採用や、ネイティブUSDCステーブルコイン対応の統合があり、これらが合わさって多額の資金流入を呼び込みました。特に、Suiの月間DEX取引高は全チェーンの中でトップクラスに浮上し、2025年中盤までに月間70〜80億ドルを超えました(業界全体で約8位)。Sui上の循環ステーブルコイン流動性は2025年中盤に10億ドルを突破し、年初から180%成長しており、オンチェーン流動性の深化を示しています。クロスチェーンの資金も流入しており、約27億ドルの資産がSuiエコシステムにブリッジされており、これにはビットコインの流動性も含まれます(詳細は後述)。この急速な成長トレンドは、Sui DeFiにおける純流入とユーザー拡大の1年であったことを裏付けています。

主要なDEXと流動性プロバイダー: 分散型取引所(DEX)は、SuiのDeFi流動性のバックボーンを形成しています。オートメーテッド・マーケット・メーカー(AMM)兼アグリゲーターであるCetusプロトコルは、ステーブルコインのスワップと集中流動性プールを提供するフラッグシップDEXとして君臨しています。Cetusは一貫して取引高でリードしており(2025年第2四半期だけで128億ドル以上の取引を促進)、約8,000万ドルのTVLを保持しています。もう一つの主要なプレーヤーはBluefinで、スポットAMMと無期限先物取引所の両方を運営する多機能DEXです。Bluefinは2025年に革新的な機能を備えたサービスを拡大しました。価格執行を改善するためのSui初のRFQ(見積依頼)システムである BluefinX を導入し、さらにDEXとCEXのパフォーマンス差を縮めるために高頻度取引(HFT)の最適化を統合しました。第2四半期までに、BluefinのAMMは約9,100万ドルのTVLを保持し、四半期のスポット取引高は71億ドルを超えました。Momentumも急成長しているDEXで、集中流動性マーケットメーカー(CLMM)を開始し、開始直後に1.07億ドルの流動性を蓄積し、約46億ドルの取引高を記録しました。SuiのDEXセクターには、MovEX(ハイブリッドAMM + オーダーブック取引所)やTurbos(早期のCLMM採用者)なども含まれており、それぞれが多様な流動性環境に貢献しています。特に、SuiはMovEXと共同開発したDeepBookと呼ばれるネイティブ・オンチェーン・セントラル・リミット・オーダーブック(CLOB)をサポートしており、あらゆるSui dAppに共有のオーダーブック流動性を提供しています。AMM、アグリゲーター、オンチェーンCLOBのこの組み合わせにより、SuiはDeFiにおいて最も堅牢なDEXエコシステムの一つを有しています。

レンディング市場とイールドプロトコル: Suiのレンディング(貸借)プラットフォームは多額の資金を引き付け、TVLの大きなシェアを占めています。Suilendプロトコルは、Suiの最大のDeFiプラットフォームとして際立っており、2025年第2四半期までに約7億ドル以上のTVLを記録しました(2025年初頭には10億ドルの大台を突破)。SuilendはSolanaのSolendをSuiのMoveランタイムに拡張したもので、瞬く間にSuiのフラッグシップ・マネーマーケットとなりました。SUIやUSDCなどの資産に対する預金および担保付き貸付サービスを提供しており、SpringSui(リキッドステーキングモジュール)や、プラットフォーム内で流動性を「超流動的(superfluid)」に使用できるようにするAMMのSTEAMMなど、関連製品を立ち上げることで革新を続けています。ユーザーエンゲージメントをゲーミフィケーション化し(ポイントキャンペーンやNFTを通じて)、収益分配機能を持つガバナンストークン $SEND を発行することで、Suilendは急速な採用を促進し、2025年中盤までに月間アクティブウォレット数が5万を超えたと報告しています。Suilendに僅差で続くのがNavi Protocol(Astrosとも呼ばれる)で、同様にレンディングプールで6〜7億ドル規模のTVLに達しました。Naviは、レンディング市場とイールド戦略、さらにはビットコインDeFiの統合を組み合わせることで差別化を図っています。例えば、NaviはOKX Walletを通じてユーザーが xBTC(Sui上のBTCプロキシ)をステークするキャンペーンを実施し、ビットコイン保有者がSuiの収益機会に参加するインセンティブを与えました。その他の注目すべきレンディングプラットフォームには、Scallop(約1.46億ドルのTVL)やAlphaLend(約1.37億ドル)があり、これらはSuiにおける貸借市場の競争力を示しています。イールドアグリゲーションも定着し始めており、AlphaFiKai Financeなどのプロトコルは、それぞれ数千万ドルの資産(例:約4,000万ドルのTVL)を管理し、Suiのファーミング全体の収益を最適化しています。規模は小さいものの、これらのイールド最適化ツールや構造化製品(例:MovEXの構造化イールドヴォルト)は、ユーザーが増大する流動性ベースからリターンを最大化するのを助け、SuiのDeFiサービスに深みを与えています。

リキッドステーキングとデリバティブ: 並行して、Suiのリキッドステーキング派生商品(LSD)およびデリバティブ取引プラットフォームは、エコシステムの流動性の重要な一部を占めています。Suiはプルーフ・オブ・ステーク(PoS)チェーンであるため、SpringSuiHaedalVoloなどのプロトコルは、ステークされたSUIをラップするトークンを導入し、ステーカ―が流動性を維持できるようにしました。Suilendチームによって立ち上げられたSpringSuiは、急速に支配的なLSDとなり、第2四半期末までに約1.89億ドルのステークされたSUIを保持しました。Haedal(1.5億ドル)などと共に、SuiのLSDプラットフォームはユーザーにバリデータ報酬を獲得させつつ、ステーキングトークンをDeFiに再投入する(例:ステークされたSUIをレンディングの担保やイールドファームで使用する)能力を提供しています。デリバティブの面では、Suiは現在、複数のオンチェーン無期限先物取引所をホストしています。前述のBluefinの無期限DEX(Bluefin Perps)は、四半期で数十億ドルの取引高を処理しました。さらに、Typus Financeは2025年第2四半期にTypus Perp (TLP) を立ち上げ、印象的なデビューでSuiの無期限市場に参入しました。Sudo(ZOプロトコルの統合を伴う)は、ゲーミフィケーション化された無期限スワップと「インテリジェント」なレバレッジ製品を導入し、昨四半期でユーザーベースと流動性を100%以上成長させました。Magmaプロトコルは、スワップにおけるスリッページゼロと高い資本効率を目指す新しいAMMモデル、**適応型流動性マーケットメーカー(ALMM)**を開拓しました。これらの革新的なDEXおよびデリバティブのデザインは、独自の流動性を引き付けており(例:MagmaのTVLは第2四半期に倍増)、次世代DeFiプリミティブのテストベッドとしてのSuiの評判を高めています。

資金流入とユーザーの動向: Suiにおける全体的な流動性トレンドは、個人投資家と機関投資家の両方の流入に支えられ、非常にポジティブです。Suiの信頼性の向上(例:HSBCやDBS銀行がネットワークバリデータとして参加)と高いパフォーマンスが、新たな資本を呼び込んでいます。Suiにブリッジされた資産の大部分は、ブルーチップトークンやステーブルコインです。例えば、CircleのUSDCがSui上でネイティブにローンチされ、TetherのUSDTがブリッジ経由で利用可能になったことで、堅牢なステーブルコインミックス(第2四半期までにUSDC約7.75億ドル、USDT約1億ドルの循環)が実現しました。最も注目すべきは、ビットコインの流動性が大規模にSuiに流入したことです(ラップされたBTCやステークされたBTC経由、詳細はセクション3参照)。これはTVLの10%以上を占めています。ユーザー側では、ウォレットサポートの改善とアブストラクション(セクション2参照)が採用を後押ししました。人気のPhantomウォレット(約700万人のユーザー)がSuiのサポートを拡張し、広範なクリプトコミュニティがSui dAppにアクセスしやすくなりました。同様に、OKXやBinanceなどの中央集権型取引所のウォレットもSui DeFi機能を統合しました(例:BinanceのChromeウォレットはSuiのScallopプロトコルを特徴とする Simple Yield 統合を追加)。これらのオンランプはSuiのユーザー成長に貢献しました。2025年初頭までにSuiには数十万のアクティブアドレスが存在し、SuilendのようなトップdAppは数万人の月間ユーザーを報告しています。全体として、Suiの流動性は2025年に上昇傾向にあり、継続的な流入と拡大するユーザー参加に支えられています。これは、同時期に一部の他のチェーンで見られた停滞とは対照的です。

2. アブストラクション:Suiにおけるユーザー体験の簡素化

アカウントアブストラクション機能: Suiの設計の礎石はアカウントアブストラクション(Account Abstraction)であり、エンドユーザーからブロックチェーンの複雑さを隠すことで使い勝手を大幅に向上させています。ユーザーがすべてのトランザクションでキーとガス代を管理しなければならない従来のレイヤー1とは異なり、Suiはネイティブ機能を通じてよりスムーズな体験を可能にします。具体的には、Suiはプロトコルレベルでのサードパーティ認証ログインとガスのスポンサーシップをサポートしています。開発者は zkLogin を統合することで、ユーザーがシードフレーズの代わりに馴染みのあるWeb2の認証情報(Google、Facebook、Twitchなど)を使用してSuiウォレットを作成し、ログインできるようにします。同時に、Suiはスポンサー付きトランザクションを提供しており、dApp開発者はオンチェーンの「ガスステーション」メカニズムを通じてユーザーの代わりにガス代を支払うことができます。zkLoginとガスのスポンサーシップが組み合わさることで、新規ユーザーにとっての2つの大きな障壁(シードフレーズの管理とネイティブトークンの入手)が取り除かれます。例えば、Suiのユーザーは、メールアドレスとパスワード(OAuth経由)でサインアップし、事前のSUIトークンを必要とせずにすぐにDeFiアプリの使用を開始できます。このレベルのアブストラクションはWeb2の使いやすさを反映しており、摩擦のないサインアップや無料トライアル体験を求める「次の波」のユーザーをオンボードする上で不可欠です。多くのSuiアプリやWeb3ゲームが現在これらの機能を活用しています。最近のNFTゲームのローンチでは、Suiのアカウントアブストラクションとソーシャルログイン機能を活用した「ウォレット不要のログイン」フローが披露されました。全体として、キー管理とガス処理を自動化することで、SuiはDeFiへの参入障壁を大幅に下げ、それが結果として高いユーザー維持率とアクティビティにつながっています。

スマートコントラクトのアブストラクションとMove: ログインやトランザクション以外にも、Suiのオブジェクト指向プログラミングモデルはスマートコントラクトレベルでのアブストラクションを提供します。Suiのネイティブ言語であるMoveは、外部所有アカウント(EOA)ではなく、豊富なメタデータと柔軟な所有構造を持つ「オブジェクト」をストレージの基本単位として扱います。これは、開発者がユーザーアカウントのプロキシとして機能するスマートコントラクトオブジェクトを作成し、通常はユーザーの署名を必要とするタスクを自動化できることを意味します。例えば、Sui上のアプリは、プログラム可能なオブジェクトをデプロイして、ユーザーが各ステップを手動で開始することなく、ユーザーに代わって定期的な支払い、または複雑なマルチステップの取引を処理できます。これらのオブジェクトは権限とロジックを保持でき、エンドユーザーからの反復的なアクションを効果的に抽象化します。さらに、Suiは複数の操作を単一のトランザクションペイロードにまとめる方法として、プログラマブル・トランザクション・ブロック(PTB)を導入しました。ユーザーに3〜4つの別々のトランザクション(トークンの承認、スワップ、ステーキングなど)への署名と送信を要求する代わりに、SuiのPTBはそれらのステップを構成し、すべて一度に実行できます。これにより、ユーザーの摩擦や確認プロンプトが減少するだけでなく、パフォーマンスも向上します(オンチェーンのトランザクションが減ることで、総ガス代が安くなり、実行が速くなります)。ユーザーの視点からは、一連の複雑なアクションが一つのスムーズな操作のように感じられます。これはUXにおける重要な改善です。SuiのMoveはこのようなコンポーザビリティ(構成可能性)とアブストラクションを念頭に置いて構築されており、開発者が従来のフィンテックアプリに近い感覚のdAppを作成することを可能にしています。さらに、Suiの暗号学的アジリティは複数の署名スキーム(Ed25519、secp256k1など)をサポートしており、ウォレットが異なるキータイプ(EthereumやBitcoinで使用されているものを含む)を使用できるようにします。この柔軟性により、Suiの機能をマルチチェーンウォレットに統合することが容易になり、将来的な量子耐性暗号への道も開かれています。

クロスチェーンアブストラクション — インテントと統合: Suiはアブストラクションを通じてクロスチェーンのユーザー体験においても新境地を拓いています。代表的な例は、2025年7月に導入された、革新的なクロスチェーン調整システムである NEAR Intents のSuiエコシステムへの統合です。この統合により、Suiのユーザーは、手動のブリッジ操作なしで、20以上の他のチェーン(Ethereum、Bitcoin、Solana、Avalancheなど)間で資産をシームレスにスワップできます。基盤となる「インテント」モデルは、ユーザーが単に「何をしたいか」(例:「Ethereum上の1 ETHをSui上のSUIにスワップしたい」)を表明するだけで、自動化されたソルバー(solvers)のネットワークがチェーン間でそのリクエストを満たす最も効率的な方法を見つけ出すことを意味します。ユーザーは、異なるネットワーク上の複数のウォレットやガス代を管理する必要がなくなります。システムがそれらすべてを抽象化するからです。Suiへの資産スワップはワンクリックのトランザクションと同じくらい簡単になり、ソースチェーンでガス代トークンを保持する必要さえありません。これはクロスチェーンDeFiにおける大きなUXの飛躍です。2025年中盤までにNEAR Intentsは稼働しており、Suiユーザーは数秒で外部の流動性を取り込むことが可能になりました。これにより、クロスチェーンの裁定取引や、Sui以外の資産保有者のオンボーディングが、事実上摩擦やカストディリスクなしで実現しました。Sui Foundationの代表者は、「ネイティブ資産をワンクリックでスワップできることは、オンチェーンのセキュリティとコンポーザビリティを維持しながら複雑さを抽象化するものである」と強調しました。並行して、Suiはユーザーの複雑さを隠す主要なウォレット統合の恩恵を受けてきました。前述の通り、PhantomのマルチチェーンウォレットがSuiをサポートし、OKXBinance Walletなどの他の人気ウォレットもSui dAppのサポートを組み込んでいます。例えば、Binanceのウォレットでは、シンプルなインターフェースを通じてSui上のイールドファーム(Scallop経由)に直接アクセスでき、OKXのウォレットはSuiのBTCステーキングフロー(NaviのxBTC)をネイティブに統合しました。これらの統合は、ユーザーがアプリを切り替えたり技術的な詳細を気にしたりすることなく、Sui DeFiと対話できることを意味します。使い慣れたウォレットがそれらを抽象化してくれるからです。インテントベースのスワップからウォレットUIまで、これらすべての努力は、Sui上でクロスチェーンおよびオンチェーンのDeFiを楽に感じさせるという目標に資するものです。その結果、Suiはクリプトネイティブだけでなく、シンプルさを求めるメインストリームのユーザーにとってもますますアクセスしやすいものとなっています。

ユーザー体験への影響: Suiのアブストラクションレイヤーのおかげで、SuiのDeFiプロトコルにおけるユーザー体験は、ブロックチェーンの中で最もユーザーフレンドリーなものの一つとなりました。新規ユーザーは、ソーシャルログインかつ事前コストなしでオンボードでき、最小限の確認で複雑なトランザクションを実行し、さらには他のチェーンからの資産移動もワンクリックのスワップで行えます。このアプローチは、「慣れ親しんだオンボーディング」とマスアダプションというSuiのミッションを実現しています。比較として、iPhoneユーザーがアプリを使うためにSwiftのコードを理解する必要がないのと同様に、Sui DeFiのユーザーも秘密鍵やブリッジの仕組みを把握する必要はありません。Suiのアカウントアブストラクションの精神はその哲学を受け入れ、ブロックチェーン金融のための「シームレスで満足度の高いユーザー体験へのゲートウェイを提供」しています。Web3の対話をWeb2に近い容易さにすることで、Suiは利便性を重視する次世代のDeFiユーザーの障壁を下げています。このユーザー中心の設計は、Suiの成長する採用における重要な要因であり、2025年以降のDeFiへのメインストリーム参加の舞台を整えています。

3. Suiにおける次世代DeFiプリミティブの波

ネイティブステーブルコインの普及: 多様な新しいステーブルコインと資産担保型トークンがSui上に登場しており、DeFiの基礎となるビルディングブロックを提供しています。2024年後半、Agora Financeの AUSD がSuiネイティブの最初の完全米ドル担保型ステーブルコインとして稼働しました。機関投資家グレードのステーブルコインとして販売されたAUSDのローンチは、即座に流動性を追加し、SuiのDeFi成長の起爆剤となりました(AUSDが登場した時のSuiのTVLは約6億ドルで、その後上昇しました)。2025年中盤までに、AUSDの循環供給量は数千万に達し(EthereumやAvalancheにも存在)、Suiエコシステム内におけるUSDC/USDTの規制に準拠した代替手段となりました。ほぼ同時期に、Bucket Protocol は、Sui版DAIのような過剰担保型ステーブルコインである BUCK を導入しました。ユーザーはSUI、BTC、ETHなどの資産を担保として預けることでBUCKをミントできます。BUCKは米ドルにペグされており、オンチェーンの担保率と安定化メカニズム(MakerDAOと同様に、Bucketはペグ安定化モジュールやCDPヴォルトなどを備えています)を通じて維持されています。2025年第2四半期までに、BUCKの供給量は約6,000万〜6,600万ドルに達し、Suiネイティブの最大級のステーブルコインの一つとなりました(BucketプロトコルのTVLはその期間に約6,900万ドルで、その大部分がBUCKの裏付けとなっていました)。もう一つの注目すべき追加は、Ondo Financeによる USDY です。これは、短期米国債の利回りをトークン化した利回り付き「ステーブルコイン」です。Ondoは2024年初頭にSuiにUSDYをデプロイし、Suiの現実資産(RWA)担保型トークンへの進出を印象づけました。USDYは事実上、保有者に利息が蓄積されるトークン化された債券ファンドです(価格は獲得した利回りを反映してわずかに変動します)。これにより、Suiユーザーはステーキングやファーミングを行うことなく、利回りを生み出すコンプライアンス重視の安定資産をネイティブに保有できるようになります。2025年までに、Suiのステーブルコイン環境には、アジアでのパートナーシップを通じて導入された First Digital USD (FDUSD) や、主要なステーブルコインのラップ版も含まれるようになりました。分散型CDP裏付け(BUCK)から、完全な法定通貨裏付け(AUSD)、利回り付き(USDY)まで、多様なステーブルコインプリミティブがオンチェーン流動性を拡大し、新しいDeFi戦略(例:BUCKをローン担保として使用する、または低リスクの利回り源としてUSDYを保持する)を可能にしています。これらの安定資産は、DEXやレンディングなどの他のプロトコルが構築されるための「土台」を形成しており、その存在はDeFiエコシステムの成熟を示す強力なシグナルです。

BTC DeFi(「BTCfi」)の革新: Suiは、ビットコインをDeFiのアクティブなプレーヤーにするための最前線に立っており、ビットコイン中心のDeFiユースケースを指す BTCfi という言葉を生み出しました。2025年、複数のイニシアチブがビットコインの流動性とセキュリティをSuiネットワークに取り込みました。大きな一歩は、Sui上での Threshold Networkの tBTC の統合でした。tBTC は、単一のカストディアンを避けるために閾値署名(分散署名)を使用する、分散型の1:1 BTC担保トークンです。2025年7月にtBTCがSui上で稼働し、Suiプロトコルに対して5億ドル相当以上のBTC流動性へのアクセスが即座に解放されました。これにより、ビットコイン保有者は中央集権的なブリッジにBTCを預けることなく、tBTCを直接Suiにミントし、レンディング、トレーディング、またはイールドファーミングに投入できるようになりました。Suiの高パフォーマンスなインフラ(1秒未満のファイナリティ)は、これらのBTC資産にとって魅力的な拠点となります。並行して、Suiは Stacks エコシステムと提携し、Stacksレイヤー2を介してビットコインのセキュリティに相乗りする別の1:1 BTC表現である sBTC をサポートしました。2025年5月までに、Wormhole、Stacks、Thresholdなどのブリッジがビットコイン接続を強化したことで、SuiのTVLの10%以上がBTCまたはBTC由来の資産で構成されるようになりました。2025年の最初の数ヶ月だけで、600 BTC(6,500万ドル以上)以上がSuiに流入しました。これらのBTCデリバティブは、BTCを担保として使用するといったユースケースをSuiのレンディングプラットフォームで解放しました(実際に、Suilendは第2四半期までに1.02億ドル以上のビットコインベースの資産を保持しており、これは他のどのSuiレンディングよりも多い額です)。また、Sui DEX上でのBTC取引ペアを可能にし、ビットコイン保有者がBTCの所有権を手放すことなくDeFi利回りを獲得することを可能にしました。BTCfiのコンセプトは、ビットコインを「パッシブな」価値保存手段からアクティブな資本資産へと変革することであり、Suiはテクノロジー(高速で並列実行可能なオブジェクトモデルはBTCカストディの表現に理想的)を提供し、ビットコインの流動性を取り込むための提携を築くことで、これを実現しました。Sui FoundationはStacksのバリデータの運営も開始しており、BTC統合へのコミットメントを示しています。要するに、ビットコインは今やSui DeFiの第一級市民であり、この相互作用は2025年の重要なイノベーションです。これは、新しいビットコイン担保型ステーブルコイン、ビットコイン利回り製品、およびビットコインネットワークとSui上のDeFiのギャップを埋めるマルチチェーン戦略への扉を開いています。

高度なDEXプリミティブとHFT: 次のSui DeFiプリミティブの波には、初期のAMMモデルを超えた斬新な取引所デザインと金融商品も含まれています。前述の通り、MagmaのALMMやMomentumのCLMMは、AMMをより高い資本効率(流動性の集中や動的な調整)へと押し進めています。さらに、プロトコルは高パフォーマンスな取引機能の実験を行っています。特に Bluefin は、機関投資家および高頻度トレーダーをターゲットとした機能を展開しました。2025年7月、BluefinはSuiの並列実行を利用してスループットとレイテンシの向上を実現し、SuiベースのDEXに機関投資家グレードの高頻度取引(HFT)戦略を導入することを発表しました。これにより中央集権型取引所とのパフォーマンス差が縮まり、オンチェーンで流動性を提供するクオンツ取引会社を引き付ける可能性があります。このような実行スピードの向上、低スリッページ、およびMEV保護(BluefinのSpot 2.0アップグレードはMEV耐性のあるRFQマッチングで知られています)は、Suiが先駆けて取り組んでいる取引所デザインにおける新しいプリミティブです。

一方、Sui上のデリバティブや構造化製品はより洗練されてきています。Typusの無期限先物への拡大や、Sudo/ZOによるゲーミフィケーション化された無期限取引について触れましたが、これらはDeFiとトレーディングのゲーミフィケーション、およびユーザーフレンドリーなインターフェースを融合させるトレンドを示しています。別の例としては、新しいインターフェースで「イールド・トレーディング」市場とポイント報酬システムを導入した Nemo があります。これは本質的に、ユーザーが利回りを予測してロイヤルティポイントを獲得することを可能にするもので、典型的なイールドファーミングに独創的なひねりを加えたものです。また、構造化イールド製品も見られます。例えば、MovEX などは、戦略間で資金を自動的に回転させる構造化ヴォルトについて議論しており、ユーザーにパッケージ化された投資商品(DeFi版のETFやトランシェに近いもの)を提供しています。これらは開発中であり、戦略の切り替えなどの複雑さが抽象化され、単一の製品として提供される次世代のイールドファーミングを代表するものです。

新しい金融商品とパートナーシップ: Suiコミュニティとそのパートナーは、次の成長段階を定義しうる全く新しいDeFiプリミティブを積極的に構築しています。注目を集めている今後のプロジェクトの一つは Graviton です。同プロジェクトは、Sui上にモジュール式の取引、貸付、クロス・マージン・プラットフォームを作成するために、Series Aで5,000万ドルを調達しました(a16zとPanteraが主導)。GravitonはしばしばdYdXと比較され、無期限取引、マージン取引、レンディング市場をすべて一つの屋根の下に提供するフルスイートの分散型取引体験でプロのトレーダーをオンボードすることを目指しています。このような多額の資金提供を受けたイニシアチブは、SuiのDeFiポテンシャルに対する信頼を裏付けるものであり、新しいプリミティブである、ワンストップで高性能なDeFi「スーパーアプリ」を約束するものです。さらに、現実世界の金融がSuiと交差しています。Sui Foundationは xMoney/xPortal とのパートナーシップを促進し、個人ユーザー向けにクリプト対応MasterCardをローンチしました。これにより、Suiベースの資産を日常の支払いで使用できるようになります。このようなCeFiとDeFiの架け橋(本質的にDeFiの流動性を販売時点管理に持ち込むこと)は、普及すれば変革をもたらす可能性があります。機関投資家側では、21Sharesが米国でSUIの上場投資信託(ETF)を申請しました。これはDeFiプロトコルではありませんが、ETFは伝統的な投資家にSuiの成長への、そして間接的にそのDeFiエコノミーへの露出機会を提供することになります。

Suiにおけるコミュニティと開発者の活動も、新しいプリミティブの原動力となっています。SuiのオープンソースMoveエコシステムは非常に活発になり、2025年中盤までにSuiは、新しいツール(Move SDK、zk証明の統合、クロスチェーンプロトコルの開発など)の急増により、週間開発者コミット数とリポジトリのフォーク数でSolanaとNearを上回りました。この活気ある開発者コミュニティは、オンチェーンのオプション市場、分散型保険、インテントベースのレンディングなどのアイデアを継続的に実験しています(2025年のハッカソンプロジェクトの中にはこれらの分野に取り組んだものもありました)。その成果が現れ始めています。例えば、Lotus Finance は第2四半期にSui上で分散型オプションAMMとしてローンチし、Turbos は検閲耐性のあるDeFiを推進するために分散型フロントエンドホスティング(Walrus経由)を採用しました。これらのコミュニティ主導のイニシアチブは、Google Cloud との連携(オンチェーンデータのインデックス作成やAI推論ツールの提供)などの正式なパートナーシップと並んで、斬新なプロトコルのための肥沃な土壌を作り出しています。Sui上では、AIオラクルを統合した動的価格設定BTCステーキングサービス(SatLayer)、さらにはクロスチェーン・インテント(NEAR Intentsの統合はクロスチェーン流動性のためのプリミティブと見なせます)を取り入れたDeFiプリミティブが見られ始めています。それぞれが、将来の開発者が新しい金融商品へと組み合わせることができるビルディングブロックを追加しています。

まとめ: 2025年、SuiのDeFiエコシステムはイノベーションと共に繁栄しています。Sui上の流動性は数十億ドル規模に達し、主要なDEXやレンディングによって支えられ、着実な資金流入とユーザーの成長によって強化されています。アカウントアブストラクションとユーザー中心の設計を通じて、SuiはDeFiのユーザー体験を劇的に改善し、より広いオーディエンスを惹きつけています。そして、ネイティブステーブルコインやBTC統合から、高度なAMM、無期限取引、現実資産トークンに至るまで、次世代のプリミティブによって、Suiは分散型金融で可能なことの境界を広げています。主要なプロトコルとコミュニティの努力がこの進化を牽引しています。CetusとBluefin はDEX技術を前進させ、Suilend などはレンディングを新しい資産クラスへと拡大し、Bucket、Agora、Ondo は斬新な資産をオンチェーンにもたらし、さらに多くのプロジェクトが続いています。インフラプロバイダー、TradFi機関、クロスチェーンネットワークとのハイレベルなパートナーシップが、Suiの勢いをさらに加速させています。これらすべての要素は、2025年までにSuiが主要なDeFiハブとしての地位を固めることを示唆しています。それは、深い流動性、シームレスな使いやすさ、そして金融プリミティブにおける絶え間ないイノベーションを特徴とするものです。

情報源:

  • Sui Foundation – Sui Q2 2025 DeFi Roundup (2025年7月15日)
  • Sui Foundation – NEAR Intents Brings Lightning-Fast Cross-chain Swaps to Sui (2025年7月17日)
  • Sui Foundation – Sui to Support sBTC and Stacks (BTCfi Use Cases) (2025年5月1日)
  • Sui Foundation – All About Account Abstraction (2023年10月4日)
  • Ainvest News – Sui Network TVL Surpasses $1.4B Driven by DeFi Protocols (2025年7月14日)
  • Ainvest News – Sui DeFi TVL Surges 480% to $1.8B... (2025年7月12日)
  • Suipiens (Sui community) – tBTC Integration Brings Bitcoin Liquidity to Sui (2025年7月17日)
  • Suipiens – Inside Suilend: Sui’s Leading Lending Platform (2025年7月3日)
  • The Defiant – Ondo to Bring RWA-Backed Stablecoins onto Sui (2024年2月7日)
  • Official Sui Documentation – Intro to Sui: User Experience (アカウントアブストラクション機能)

Aptos vs. Sui: Moveベースの巨人2つの全景分析

· 約 8 分
Dora Noda
Software Engineer

Overview

Aptos と Sui は、Meta の Libra/Diem プロジェクトで最初に考案された Move 言語から派生した次世代レイヤー1ブロックチェーンです。共通の系譜を持つものの、チームの背景、コア目標、エコシステム戦略、進化の道筋は大きく分岐しています。

Aptos は汎用性とエンタープライズ向けパフォーマンスを重視し、DeFi と機関投資家向けユースケースの両方を対象としています。一方、Sui は独自のオブジェクトモデルの最適化に特化し、特にゲーム、NFT、ソーシャルメディアといった大量消費者向けアプリケーションを狙っています。どちらのチェーンが最終的に差別化できるかは、選択した市場ニッチの要求に合わせて技術を進化させ、ユーザー体験と開発者フレンドリーさで明確な優位性を築けるかにかかっています。


1. Development Journey

Aptos

Aptos Labs(元 Meta Libra/Diem の社員で構成)から誕生し、2021 年末にクローズドテストを開始、2022 年 10 月 19 日にメインネットをローンチしました。WIRED が指摘したように、初期メインネットのスループットは 20 TPS 未満と低く、コミュニティの懐疑的な声がありましたが、その後コンセンサス層と実行層の改良を重ね、数万 TPS にまで伸ばしています。

2025 年第2四半期までに、Aptos は単一週で 4,470 万件のトランザクションピークを記録し、週次アクティブアドレスは 400 万を超えました。累計アカウントは 8,300 万を超え、日次 DeFi 取引量は常に 2 億ドル以上(出典:Aptos Forum)です。

Sui

Mysten Labs(元 Meta の Novi ウォレットチームの中心メンバー)が立ち上げ、2022 年 8 月にインセンティブテストネットを開始、2023 年 5 月 3 日にメインネットを稼働させました。初期テストネットから「オブジェクトモデル」の洗練に注力し、資産を所有権とアクセス制御を持つオブジェクトとして扱うことで並列トランザクション処理を強化しています(出典:Ledger)。

2025 年 7 月中旬時点で、Sui のエコシステム TVL は 23.26 億ドルに達しました。月次トランザクション量とアクティブエンジニア数の急速な伸びは、特にゲームと NFT セクターでの人気を裏付けています(出典:AInvest、Tangem)。


2. Technical Architecture Comparison

FeatureAptosSui
Language元の Move 設計を継承し、「リソース」のセキュリティと厳格なアクセス制御を重視。言語は比較的シンプルです。(出典:aptos.dev)標準 Move に「オブジェクト中心」モデルを拡張し、水平スケーラブルな並列トランザクションを実現するカスタム版言語です。(出典:docs.sui.io)
ConsensusAptosBFT:サブ秒ファイナリティを約束する最適化 BFT コンセンサス。セキュリティと一貫性に重点。(出典:Messari)Narwhal + Tusk:コンセンサスとトランザクション順序付けを分離し、並列実行効率を優先して高スループット・低レイテンシを実現。
Execution Modelパイプライン実行モデルを採用し、データ取得・実行・書き戻しの段階でトランザクションを処理。高頻度転送と複雑ロジックに対応。(出典:chorus.one)オブジェクト所有権に基づく並列実行。異なるオブジェクトを扱うトランザクションはグローバルロック不要で、スループットが根本的に向上。
Scalability単一インスタンス最適化に注力しつつ、シャーディングを研究中。コミュニティは AptosCore v2.0 のシャーディング提案を活発に開発中。ネイティブな並列エンジンで水平スケーリングを実現。テストネットではすでに数万 TPS のピークを記録。
Developer Tools公式 SDK、Devnet、Aptos CLI、Explorer、スケーラビリティ向け Hydra フレームワークなど成熟したツールチェーン。Sui SDK、Sui Studio IDE、Explorer、GraphQL API、オブジェクト指向クエリモデルなど包括的なスイート。

3. On-Chain Ecosystem and Use Cases

3.1 Ecosystem Scale and Growth

Aptos
2025 年第1四半期には、月間アクティブユーザーが約 1,500 万人、日間アクティブウォレットが 100 万を超えました。DeFi 取引量は前年同期比で 1,000% 増加し、金融グレードのステーブルコインやデリバティブのハブとして位置付けられています(出典:Coinspeaker)。主な戦略としては、Upbit 経由で USDT を統合しアジア市場への浸透を加速、主要 DEX、レンディング、デリバティブプロトコルの誘致を進めています(出典:Aptos Forum)。

Sui
2025 年 6 月時点でエコシステム TVL は 23.26 億ドルの新高値に達し、主に高インタラクションなソーシャル、ゲーム、NFT プロジェクトが牽引しています(出典:AInvest)。コアプロジェクトはオブジェクトマーケットプレイス、レイヤー2ブリッジ、ソーシャルウォレット、ゲームエンジン SDK などで、Web3 ゲーム開発者や IP 保有者の関心を大きく集めています。

3.2 Dominant Use Cases

  • DeFi & Enterprise Integration(Aptos):成熟した BFT ファイナリティと豊富な金融ツール群により、ステーブルコイン、レンディング、デリバティブといった高い一貫性とセキュリティが求められるシナリオに適しています。
  • Gaming & NFTs(Sui):並列実行の優位性が顕著です。低レイテンシ・ほぼゼロ手数料は、ゲーム内アイテムの転送やルートボックス開封といった高頻度・低価値取引に最適です。

4. Evolution & Strategy

Aptos

  • Performance Optimization:シャーディング研究を継続し、マルチリージョンのクロスチェーン流動性と AptosVM のステートアクセス効率向上を計画。
  • Ecosystem Incentives:数億ドル規模のエコシステム基金を設立し、DeFi インフラ、クロスチェーンブリッジ、コンプライアンス対応エンタープライズアプリを支援。
  • Cross-Chain Interoperability:Wormhole などのブリッジ統合を強化し、Cosmos(IBC)や Ethereum への接続を拡充。

Sui

  • Object Model Iteration:カスタムオブジェクト型と高度な権限管理をサポートする Move 構文拡張と、並列スケジューリングアルゴリズムの最適化を推進。
  • Driving Consumer Adoption:Unreal や Unity といった主要ゲームエンジンとの深い統合を追求し、Web3 ゲーム開発のハードルを低減。ソーシャルプラグインや SDK の提供も拡大。
  • Community Governance:SuiDAO を推進し、コアプロジェクトコミュニティにガバナンス権限を付与、機能や手数料モデルの迅速なイテレーションを実現。

5. Core Differences & Challenges

  • Security vs. Parallelism:Aptos の厳格なリソースセマンティクスと一貫したコンセンサスは DeFi グレードのセキュリティを提供しますが、並列性は制限されがちです。Sui の高度に並列化されたトランザクションモデルは、スケール時のセキュリティ耐性を継続的に証明する必要があります。
  • Ecosystem Depth vs. Breadth:Aptos は金融セクターで深い根を張り、機関投資家との結びつきが強固です。一方、Sui は消費者向けプロジェクトを幅広く集めていますが、規模の大きい DeFi での決定的な突破口はまだです。
  • Theoretical Performance vs. Real-World Throughput:Sui は理論上の TPS が高いものの、実際のスループットはエコシステム活動に左右されます。Aptos もピーク時に混雑が発生し、効果的なシャーディングや Layer‑2 ソリューションが求められています。
  • Market Narrative & Positioning:Aptos はエンタープライズ向けのセキュリティと安定性を前面に出し、伝統的金融や規制産業をターゲットにしています。Sui は「Web2 ライクな体験」や「ゼロフリクションのオンボーディング」を掲げ、広範な消費者層の獲得を狙っています。

6. The Path to Mass Adoption

最終的に、これはゼロサムゲームではありません。

中長期的に、消費者市場(ゲーム、ソーシャル、NFT)が爆発的に成長し続ければ、Sui の並列実行と低参入障壁は数千万規模の主流ユーザーへの急速な採用を後押しする可能性があります。

短中期的に、Aptos の成熟した BFT ファイナリティ、低手数料、戦略的パートナーシップは、機関金融、コンプライアンス重視の DeFi、国境間決済に対してより魅力的な提案となります。

将来的には、両チェーンが共存し、階層化された市場を形成するシナリオが現実味を帯びています。Aptos が金融・エンタープライズインフラを担い、Sui が高頻度の消費者インタラクションを支配する形です。最終的に大衆採用を実現するチェーンは、選択したドメインでパフォーマンスとユーザー体験を徹底的に最適化し続ける側になるでしょう。