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

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

全てのタグを見る

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

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

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

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

    $Net Rewardsepoch=$Rewardsepoch$Costepoch\text{\$Net Rewards}_{\text{epoch}} = \text{\$Rewards}_{\text{epoch}} - \text{\$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によるシームレスなオンランプ

· 約7分
Dora Noda
Software Engineer

BlockEden のロゴ

注目: zkLogin は、ユーザー体験を根本から変える可能性があります。


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

UX リサーチャーは、ウォレットのプロンプトが表示された瞬間に 87% の離脱が起きることを観測しました。ある実験では、そのプロンプトをチェックアウトプロセスの後半に回すだけで完了率が 94% に転換しました。暗号に興味はあるものの、ユーザーの主な不安は「間違ったボタンを押したら資金を失うかもしれない」というものです。この単一の恐怖感のあるステップを取り除くことが、指数的成長への鍵となります。


zkLogin の仕組み(平易な説明)

zkLogin は、すべてのインターネットユーザーがすでに信頼している技術を利用して、ウォレット問題を巧みに回避します。以下の数ステップで裏側で魔法が起きます:

  1. エフェメラルキー・ペア:ユーザーがサインインしようとすると、ブラウザ内で一時的な単一セッション用キー・ペアがローカルに生成されます。これはこのセッションだけ有効な一時的なパスキーと考えてください。

  2. OAuth フロー:ユーザーは Google、Apple、またはその他のソーシャルアカウントでサインインします。アプリはこのログインリクエストにユニークな値(nonce)を巧みに埋め込みます。

  3. ZKP サービス:ログインが成功すると、ZKP(ゼロ知識証明)サービスが暗号証明を生成します。この証明は「この OAuth トークンは一時的なパスキーの所有者を認可する」ことを確認しますが、ユーザーの個人情報をオンチェーンで公開することはありません。

  4. アドレス導出:OAuth プロバイダーから取得したユーザーの JWT(JSON Web Token)をユニークな salt と組み合わせ、決定的に永続的な Sui アドレスを生成します。salt はクライアント側または安全なバックエンドで非公開に保持されます。

  5. トランザクション送信:アプリは一時的なキーでトランザクションに署名し、ZK 証明を添付します。Sui バリデータはオンチェーンで証明を検証し、ユーザーが従来のウォレットを必要とせずに取引の正当性を確認します。


ステップバイステップ統合ガイド

実装の準備はできましたか?以下は TypeScript SDK を使用した簡単なガイドです。Rust や Python でも同様の原則が適用されます。

1. SDK のインストール

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

npm install @mysten/sui

2. Generate Keys & Nonce

まず、エフェメラルキー・ペアと、Sui ネットワーク上の現在エポックに紐付く nonce を作成します。

// TypeScript の例
import { SuiClient } from "@mysten/sui.js";
const client = new SuiClient({ url: "https://fullnode.devnet.sui.io:443" });

3. Redirect to OAuth

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

4. Decode JWT & Fetch User Salt

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

// TypeScript の例
const urlParams = new URLSearchParams(window.location.search);
const idToken = urlParams.get("id_token");
// バックエンドから salt を取得し、アドレスを導出

5. Request ZK Proof

JWT をプローバーサービスに送信して ZK 証明を取得します。開発環境では Mysten のパブリックプローバーを利用できます。本番環境では自前のプローバーをホストするか、Enoki のようなサービスを利用すべきです。

// TypeScript の例
const proofResponse = await fetch("https://prover.mystenlabs.com", {
method: "POST",
body: JSON.stringify({ jwt: idToken }),
});
const zkProof = await proofResponse.json();

6. Sign & Send

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

// TypeScript の例
const tx = await client.signAndExecuteTransactionBlock({
transactionBlock: transaction,
signer: temporaryKeyPair,
zkLoginInputs: zkProof,
});

7. Persist Session

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


KPI Projection Template

zkLogin がもたらす違いは定性的だけでなく、定量的にも測れます。典型的なオンボーディングファネルと zkLogin を活用したファネルを比較してみましょう:

ファネル段階ウォレットポップアップあり(従来)zkLogin 使用時差分
Landing → Sign-in100 %100 %
サインイン → ウォレット準備完了15 % (インストール、シードフレーズ)55 % (ソーシャルログイン)+40 pp
ウォレット準備完了 → 初回取引23 %90 %+67 pp
全体取引コンバージョン3 %≈ 25‑40 %8‑13×

👉 意味するところ: 1 万人のユニーク訪問者を集めるキャンペーンでは、300 件の初日オンチェーンアクションと、2,500 件以上の差が生まれます。


Best Practices & Gotchas

よりシームレスな体験を実現するため、以下のポイントに留意してください:

  • スポンサー付きトランザクションを使用:ユーザーの最初の数回の取引手数料を支払います。これによりすべての摩擦が除去され、驚きの「 aha 」体験が得られます。
  • Salt の取り扱いに注意:ユーザーの salt を変更すると新しいアドレスが生成されます。信頼できるリカバリーパスを確保できる場合にのみ実施してください。
  • Sui アドレスを公開:サインアップ後にユーザーにオンチェーンアドレスを表示します。上級ユーザーは後で従来のウォレットにインポートできるようになります。
  • リフレッシュループ防止:JWT とエフェメラルキー・ペアを有効期限までキャッシュし、ユーザーに繰り返しログインさせるのを防ぎます。
  • プローバーのレイテンシ監視:証明生成の往復時間を監視します。2 秒を超える場合は、地域プローバーをホストして高速化を検討してください。

Where BlockEden.xyz Adds Value

zkLogin がユーザー向けフローを完璧にする一方で、スケールさせると新たなバックエンド課題が生じます。そこで BlockEden.xyz の出番です。

  • API レイヤー:高スループットでジオルーティングされた RPC ノードにより、ユーザーの所在地に関係なく zkLogin トランザクションが最小レイテンシで処理されます。
  • 可観測性:証明レイテンシ、成功/失敗比率、コンバージョンファネルの健全性などの主要指標を追跡できるダッシュボードがすぐに利用可能です。
  • コンプライアンス:法定通貨へのブリッジを行うアプリ向けに、オプションの KYC モジュールがユーザーの検証済み身元から直接コンプライアンス対応のオンランプを提供します。

Ready to Ship?

使いにくく威圧的なウォレットフローの時代は終わりました。zkLogin サンドボックスを立ち上げ、BlockEden のフルノードエンドポイントを接続すれば、サインアップグラフが上向きに伸びるのが見えるでしょう—ユーザーは「ウォレット」という言葉すら聞くことはありません。😉

# デプロイ用のコマンド例
npm run build && npm publish

2025年のSui DeFiエコシステム:流動性、抽象化、そして新しいプリミティブ

· 約7分
Dora Noda
Software Engineer

1. 流動性とSui DeFiの成長

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

総ロック価値(TVL)急増: Sui ネットワークの DeFi 流動性は過去 1 年で爆発的に拡大しました。2024 年末の 600MTVLから、2025年中頃には 600M TVL** から、2025 年中頃には ** 2B 超 に急上昇しました。実際、2025 年 5 月 21 日には 2.55BTVLのピークを記録し、第2四半期の大半で 2.55B TVL** のピークを記録し、第2四半期の大半で ** 2B 超 を維持しました。この 300% + の増加(2025 年第2四半期までの 480% の伸び)により、Sui の TVL は数十億ドル規模に達しました。流動性の増加は $ 1.8B 超の TVL をもたらし、主要な DEX とレンディング プロトコルが牽引しています。

Sui の DEX は 1.2B超の取引ボリュームを処理し、流動性提供者は 1.2B** 超の取引ボリュームを処理し、流動性提供者は ** 500M 超の報酬を獲得しました。流動性の増加は $ 102M 超の BTC 系資産が Sui のレンディング プラットフォームに流入したことでも裏付けられます。

2. 主要な DEX とプロトコル

  • Cetus:Sui 上で最大級の AMM として機能し、流動性プールは $ 300M 超をロックしています。集中型流動性提供とマルチプール戦略により、スリッページを最小化しつつ取引手数料を最大化しています。
  • Bluefin:高速取引と機関投資家向け機能を提供。第2四半期には Spot 2.0 アップグレードで MEV 抵抗型 RFQ マッチングを実装し、低レイテンシ取引を実現しました。
  • Momentum:CLMM(集中型流動性プール)を導入し、資本効率を向上させました。第2四半期には $ 150M 超の流動性を集中させ、スリッページを 0.1% 未満に抑えました。
  • Magma:ALMM(適応型流動性マーケットメイカー)を展開し、流動性の動的再配分と低スリッページ取引を実現しました。

2. アカウント抽象化とユーザー体験の向上

Sui のアカウント抽象化は、ユーザーがウォレットや認証手段をシームレスに切り替えられるように設計されています。これにより、以下が可能になりました。

  • ソーシャルログイン:Google、Twitter、Discord などの ID プロバイダーでのサインインが可能です。
  • マルチシグウォレット:複数署名者がトランザクションを承認でき、資金の安全性が向上します。
  • プラグイン認証:ZK プルーフや生体認証を組み込んだカスタム認証モジュールを簡単に統合できます。

これらの機能により、Sui の DeFi エコシステムは $ 1.8B 超の TVL を達成し、ユーザーエクスペリエンスが大幅に向上しました。

3. 次世代プリミティブとイノベーション

ネイティブステーブルコイン

  • Agora Finance の AUSD:2024 年末にリリースされた完全 USD バックのステーブルコイン。2025 年第2四半期までに循環供給は数千万単位に達し、規制対応型代替資産として広く採用されました。
  • Bucket Protocol の BUCK:過剰担保型ステーブルコインで、USD にペッグされています。2025 年第2四半期には 60M60M – 66M の供給に達し、プロトコル全体の TVL の $ 69M を支えました。
  • Ondo Finance の USDY:米国短期国債利回りをトークン化したイールドベアリングステーブルコイン。2025 年までに Sui エコシステム内で $ 200M 超の資産を管理しています。

BTCfi(Bitcoin DeFi)イノベーション

  • Threshold Network の tBTC:2025 年第2四半期に Sui 上でリリースされ、$ 500M 超 の BTC 流動性を提供。ユーザーは BTC をロックせずに 1:1 の tBTC をミントし、貸付や取引に利用できます。
  • Stacks の sBTC:2025 年第2四半期までに TVL の 10% 超が BTC 系資産で構成され、$ 102M 超の Bitcoin ベース資産が Sui のレンディング プラットフォームにロックされました。

高性能 DEX と HFT

  • Bluefin Institutional HFT:2025 年第3四半期にインスティテューショナル向け高頻度取引戦略を導入。Sui の並列実行により、取引レイテンシがミリ秒単位に短縮され、MEV 抵抗型 RFQ マッチングが実装されました。

新しい金融商品とパートナーシップ

  • Graviton:シリーズ A で $ 50M を調達し、モジュラー型トレーディング・レンディング・クロスマージニングプラットフォームを構築中。dYdX に匹敵するプロフェッショナル向け DeFi スーパ―アプリを目指しています。
  • xMoney / xPortal:Sui ベースの資産で利用できる MasterCard を開発中。小売ユーザーが日常の支払いに暗号資産を使用できるようになります。
  • 21Shares:米国で SUI 上場投資信託(ETF)を申請。伝統的投資家に Sui エコシステムへのエクスポージャーを提供します。

4. 開発者コミュニティとエコシステムの活性化

2025 年中頃、Sui のオープンソース Move エコシステムは週次コミット数とリポジトリフォーク数で Solana と Near を上回り、ツールチェーン、zk‑proof 統合、クロスチェーンプロトコル開発が急増しています。ハッカソンプロジェクトではオンチェーンオプション市場、分散型保険、インテントベース貸付などが試みられ、Lotus Finance が分散型オプション AMM として Q2 にローンチしました。さらに、Google Cloud との提携によりオンチェーンデータインデックスと AI 推論ツールが提供され、AI オラクルを活用した動的価格設定や BTC ステーキングサービス(SatLayer)などの新プリミティブが実装されています。

5. まとめ

2025 年の Sui DeFi エコシステムは、流動性の拡大、抽象化によるユーザー体験の向上、そして次世代プリミティブの波 によって急速に成熟しています。主要 DEX(Cetus、Bluefin、Momentum)とレンディング プラットフォーム(Suilend、SuiLend など)が深い流動性を支え、アカウント抽象化が新規ユーザー層を呼び込み、ネイティブステーブルコインや BTCfi、先進的 AMM、パーペチュアル・フューチャー、実世界資産トークンが DeFi の可能性を拡大しています。インフラプロバイダー、トラディショナル金融機関、クロスチェーンネットワークとのハイプロファイルなパートナーシップが Sui の勢いをさらに加速させ、2025 年までに リーディング DeFi ハブ としての地位を確固たるものにしています。

出典:

  • Sui Foundation – Sui Q2 2025 DeFi Roundup (July 15, 2025)
  • Sui Foundation – NEAR Intents Brings Lightning-Fast Cross-chain Swaps to Sui (July 17, 2025)
  • Sui Foundation – Sui to Support sBTC and Stacks (BTCfi Use Cases) (May 1, 2025)
  • Sui Foundation – All About Account Abstraction (Oct 4, 2023)
  • Ainvest News – Sui Network TVL Surpasses $ 1.4B Driven by DeFi Protocols (Jul 14, 2025)
  • Ainvest News – Sui DeFi TVL Surges 480% to $ 1.8B... (Jul 12, 2025)
  • Suipiens (Sui community) – tBTC Integration Brings Bitcoin Liquidity to Sui (Jul 17, 2025)
  • Suipiens – Inside Suilend: Sui’s Leading Lending Platform (Jul 3, 2025)
  • The Defiant – Ondo to Bring RWA-Backed Stablecoins onto Sui (Feb 7, 2024)
  • Official Sui Documentation – Intro to Sui: User Experience (account abstraction features)

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 が高頻度の消費者インタラクションを支配する形です。最終的に大衆採用を実現するチェーンは、選択したドメインでパフォーマンスとユーザー体験を徹底的に最適化し続ける側になるでしょう。