44 篇博文 含有标签「密码学」

2026 年 4 月 20 日，Vitalik Buterin 走上香港会议展览中心的舞台，参加年度 Web3 嘉年华，并发表了他职业生涯中技术针对性最强的主旨演讲之一。大多数媒体的头条都集中在他对克隆链 L2 的直言不讳的否定上。但在演讲中——以及在此前数月的潜心研究和基金会公告中——隐藏着一个影响深远的信息：量子计算已经从理论关注转变为 Ethereum（以太坊）的活跃工程优先级，而且准备窗口期比业界预想的要短。

这就是这个故事的背景：为什么这很重要，Ethereum 正在构建什么来应对它，以及这对当今链上构建的每个协议、钱包和开发人员意味着什么。

隐私正在成为公共基础设施。在 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
    // 查询 Sui 的 NFT 所有权
  }
}

示例 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}`);
  }
}

资源和后续步骤​

官方文档​

• Seal 文档: https://seal-docs.wal.app/
• GitHub 仓库: https://github.com/MystenLabs/seal
• Sui 文档: https://docs.sui.io/
• Walrus 文档: https://docs.wal.app/

社区和支持​

• 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 并开始尝试本教程中的示例。去中心化网络正在等待将隐私和安全放在首位的应用程序。

公有链为所有参与者提供同步且可审计的账本，但默认暴露所有数据。2025 年 9 月 3 日正式登陆 Sui 主网的 Seal，通过将链上策略逻辑与去中心化密钥管理结合，让 Web3 构建者能够精确控制谁能解密哪些载荷。

摘要​

• 产品定位： 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 门控策略做原型，然后迭代出与应用风险画像匹配的服务商组合与运营控制。

在人工智能与区块链快速融合的时代，对信任与透明度的需求前所未有。我们如何确保 AI 模型的输出准确且未被篡改？我们又如何在不牺牲安全性或可扩展性的前提下，对海量链上数据执行复杂计算？Lagrange Labs 正在通过其零知识（ZK）基础设施套件正面回应这些问题，致力于构建“可证明的 AI”。本文客观概述其使命、技术以及近期突破，重点聚焦其最新的动态 zk‑SNARKs 论文。

1. 团队与使命​

Lagrange Labs 正在构建基础设施，为任何 AI 推理或链上应用生成密码学证明。其目标是让计算可验证，为数字世界注入全新信任层。生态系统围绕三大核心产品线：

• ZK Prover Network：由超过 85 个证明节点组成的去中心化网络，提供从 AI、Rollup 到去中心化应用（dApp）等多种证明任务所需的计算能力。
• DeepProve（zkML）：专用于生成神经网络推理的 ZK 证明。Lagrange 声称其速度比竞争方案快 158 倍，让可验证 AI 成为可落地的现实。
• ZK Coprocessor 1.0：首个基于 SQL 的 ZK 协处理器，允许开发者对海量链上数据执行自定义查询，并获得可验证的准确结果。

2. 可验证 AI 的路线图​

Lagrange 按部就班执行路线图，逐步解决 AI 可验证性难题。

• 2024 年 Q3：ZK Coprocessor 1.0 发布：引入超并行递归电路，平均提升约 2 倍。Azuki、Gearbox 等项目已在链上数据需求中 使用该协处理器。
• 2025 年 Q1：DeepProve 正式亮相：Lagrange 宣布推出针对零知识机器学习（zkML）的 DeepProve，支持 MLP、CNN 等主流网络结构。系统在一次性设置、证明生成、验证三个关键阶段均实现数量级加速，最高可达 158 倍。
• 2025 年 Q2：动态 zk‑SNARKs 论文（最新里程碑）：该论文提出突破性的 “update” 算法。无需每次数据或计算变更时重新生成完整证明，而是将旧证明 (π) 打补丁 成新证明 (π')，复杂度仅为 O(√n log³n)，大幅优于全量重算。此创新尤为适用于持续学习的 AI 模型、实时游戏逻辑以及可演化的智能合约。

3. 动态 zk‑SNARKs 的意义​

可更新证明的出现标志着零知识技术成本模型的根本转变。

• 全新成本范式：行业从“每次都全量重算”转向“基于变更规模的增量证明”，显著降低频繁小幅更新应用的计算与费用开支。

• 对 AI 的影响：

  • 持续微调：当模型参数微调幅度低于 1% 时，证明生成时间几乎与变更参数数量 (Δ 参数) 成线性关系，而非与模型整体规模成正比。
  • 流式推理：这 使得证明生成可以与推理过程同步进行，大幅压缩 AI 决策到链上结算并验证的延迟，开启链上 AI 服务、Rollup 压缩证明等新用例。

• 对链上应用的影响：

  • 动态 zk‑SNARKs 为频繁小幅状态变更的场景（如 DEX 订单簿、演化游戏状态、频繁增删的账本）带来巨大的 Gas 与时间优化。

4. 技术栈概览​

Lagrange 的强大基础设施基于以下集成技术栈：

• 电路设计：系统灵活，可直接在电路中嵌入 ONNX（开放神经网络交换）模型、SQL 解析器以及自定义算子。
• 递归与并行：ZK Prover Network 支持分布式递归证明，ZK Coprocessor 通过 “微电路” 分片实现任务并行执行，最大化效率。
• 经济激励：Lagrange 计划发行原生代币 LA，并将其纳入 双拍卖递归拍卖（DARA） 机制，构建完善的计算竞价市场，配套激励与惩罚以确保网络完整性。

5. 生态与真实落地​

Lagrange 的技术已被多个项目在不同领域采纳：

• AI 与 ML：如 0G Labs、Story Protocol 等使用 DeepProve 验证 AI 输出，确保来源可信。
• Rollup 与基础设施：EigenLayer、Base、Arbitrum 等作为验证节点或集成伙伴加入 ZK Prover Network，提升网络安全与算力。
• NFT 与 DeFi：Azuki、Gearbox 等项目利用 ZK Coprocessor 增强数据查询可信度与奖励分配的公正性。

6. 挑战与前路​

尽管进展显著，Lagrange Labs 与整个 ZK 领域仍面临若干障碍：

• 硬件瓶颈：即便拥有分布式网络，可更新 SNARK 仍需高带宽，并依赖 GPU 友好的密码曲线以实现高效运算。
• 标准化缺失：将 ONNX、PyTorch 等 AI 框架映射到 ZK 电路的过程尚未形成统一接口，导致开发者摩擦。
• 竞争激烈：zkVM 与通用 zkCompute 平台的竞争日趋白热化，Risc‑Zero、Succinct 等竞争者亦在快速迭代。最终的胜者或许是最先实现商业化、开发者友好、社区驱动的完整工具链者。

7. 结论​

Lagrange Labs 正在通过 可验证性 的视角系统性重塑 AI 与区块链的交叉领域。其整体解决方案包括：

• DeepProve：解决 可信推理 的难题。
• ZK Coprocessor：解决 可信数据 的难题。
• 动态 zk‑SNARKs：将 持续更新 的真实需求直接嵌入证明系统。

只要 Lagrange 能保持性能优势、突破标准化瓶颈并继续壮大其网络，它有望成为新兴 “AI + ZK 基础设施” 领域的基石玩家。

简介​

Ika 是一个由 Sui 基金会战略支持的并行多方计算 (MPC) 网络。Ika 前身为 dWallet Network，旨在以高速和大规模实现零信任的跨链互操作性。它允许智能合约 (尤其是在 Sui 区块链上) 安全地控制和协调其他区块链上的资产，而无需使用传统的跨链桥。本报告从创始人的视角深入探讨 Ika 的技术架构和密码学设计，并对其团队、融资、代币经济学、采用情况和竞争格局进行商业和投资分析。报告还包含一个 Ika 与其他基于 MPC 的网络 (Lit Protocol、Threshold Network 和 Zama) 的总结对比表，以供参考。

技术架构与特性 (创始人视角)​

架构与密码学原语​

Ika 的核心创新是一种新颖的 “2PC-MPC” 密码学方案——即在多方计算框架内的两方计算。简单来说，签名过程始终涉及两方：(1) 用户 和 (2) Ika 网络。用户保留一个私钥分片，而由许多独立节点组成的网络则持有另一个分片。只有在双方共同参与的情况下才能生成签名，这确保了网络本身永远无法在没有用户参与的情况下伪造签名。网络方并非单一实体，而是由 N 个验证者组成的分布式 MPC，它们共同扮演第二方的角色。这些节点中至少有三分之二的门限必须达成一致 (类似于拜占庭容错共识)，才能生成网络的签名分片。这种_嵌套式 MPC_ 结构 (用户 + 网络) 使得 Ika 非共谋：即使所有 Ika 节点合谋，它们也无法窃取用户资产，因为用户的参与 (他们的密钥分片) 在密码学上是必需的。换句话说，Ika 实现了**“零信任” 安全**，维护了 Web3 的去中心化和用户所有权原则——没有任何单一实体或小团体可以单方面危及资产。

图：Ika 的 2PC-MPC 架构示意图——用户作为一方 (持有一个私钥分片)，由 N 个验证者组成的 Ika 网络通过 MPC 门限协议 (t-out-of-N) 构成另一方。这保证了用户和去中心化节点的超多数必须合作才能生成有效签名。

从技术上讲，Ika 是一个从 Sui 代码库分叉出来的独立区块链网络。它运行自己的 Sui 高性能共识引擎实例 (Mysticeti，一种基于 DAG 的 BFT 协议) 来协调 MPC 节点。值得注意的是，Ika 版本的 Sui 禁用了智能合约 (Ika 链仅用于运行 MPC 协议)，并包含了用于 2PC-MPC 签名算法的自定义模块。Mysticeti 在节点之间提供了一个可靠的广播通道，取代了传统 MPC 协议使用的复杂点对点消息网格。通过利用基于 DAG 的共识进行通信，Ika 避免了早期门限签名方案的指数级通信开销，后者要求 n 方中的每一方都向所有其他方发送消息。相反，Ika 的节点通过共识广播消息，实现了线性的 O(n) 通信复杂度，并使用批处理和聚合技术，使得即使 N 变得很大，每个节点的成本也几乎保持不变。这代表了门限密码学的一大突破：Ika 团队用高效的广播和聚合取代了点对点的“单播”通信，使得协议能够支持成百上千的参与者而不会减速。

零知识集成： 目前，Ika 的安全性是通过门限密码学和 BFT 共识实现的，而非明确的零知识证明。其核心签名过程不依赖于 zk-SNARKs 或 zk-STARKs。然而，Ika 使用链上_状态证明_ (轻客户端证明) 来验证来自其他链的事件，这是一种密码学验证形式 (例如，验证区块头或状态的 Merkle 证明)。该设计为未来集成零知识技术留下了空间——例如，在不泄露敏感数据的情况下验证跨链状态或条件——但截至 2025 年，Ika 公布的架构中并未包含任何特定的 zk-SNARK 模块。其重点在于通过 2PC-MPC 方案实现的“零信任”原则 (即无信任假设)，而非零知识证明系统。

性能与可扩展性​

Ika 的一个主要目标是克服以往 MPC 网络的性能瓶颈。传统的门限签名协议 (如 Lindell 的 2PC ECDSA 或 GG20) 难以支持超过少数几个参与者，通常需要数秒或数分钟才能生成一个签名。相比之下，Ika 的优化协议实现了亚秒级延迟的签名，并且可以并行处理非常高的签名请求吞吐量。基准测试声称，Ika 可以在大型节点集群中扩展到约每秒 10,000 次签名，同时保持安全性。这得益于前述的线性通信和大量使用批处理：网络可以在一轮协议中并发生成许多签名，从而极大地摊销了成本。据团队称，在负载下，Ika 可以比现有 MPC 网络**“快 10,000 倍”。实际上，这意味着实时、高频的交易 (如交易或跨链 DeFi 操作) 可以得到支持，而不会出现门限签名通常的延迟。延迟在亚秒级最终性**的量级，意味着签名 (以及相应的跨链操作) 几乎可以在用户请求后立即完成。

同样重要的是，Ika 在实现这一点的同时，还扩展了签名者的数量以增强去中心化。传统的 MPC 设置通常使用一个由 10-20 个节点组成的固定委员会，以避免性能崩溃。Ika 的架构可以扩展到成百上千的验证者参与签名过程，而不会出现显著的减速。这种大规模的去中心化提高了安全性 (攻击者更难腐蚀大多数节点) 和网络鲁棒性。其底层共识是拜占庭容错的，因此网络可以容忍多达三分之一的节点被攻破或离线，并仍然正常运行。在任何给定的签名操作中，只需要一个 t-of-N 的节点门限 (例如 N 的 67%) 积极参与；根据设计，如果太多节点宕机，签名可能会延迟，但系统被设计为能够优雅地处理典型的故障场景 (类似于区块链的共识活性和安全性属性)。总而言之，Ika 同时实现了高吞吐量和高验证者数量，这一组合使其区别于那些不得不在去中心化和速度之间做出权衡的早期 MPC 解决方案。

开发者工具与集成​

Ika 网络被构建为对开发者友好，特别是对于那些已经在 Sui 上构建的开发者。开发者不是在 Ika 本身上编写智能合约 (因为 Ika 的链不运行用户定义的合约)，而是从其他链与 Ika 交互。例如，一个 Sui Move 合约可以调用 Ika 的功能来签署外部链上的交易。为方便这一点，Ika 提供了强大的工具和 SDK：

• TypeScript SDK： Ika 提供了一个 TypeScript SDK (Node.js 库)，其风格与 Sui SDK 相似。该 SDK 允许构建者创建和管理 dWallets (去中心化钱包)，并从他们的应用程序向 Ika 发出签名请求。使用 TS SDK，开发者可以生成密钥对、注册用户分片，并调用 Ika 的 RPC 来协调门限签名——所有这些都使用了 Sui API 中熟悉的模式。该 SDK 抽象了 MPC 协议的复杂性，使其变得像调用一个函数来请求 (例如) 一个比特币交易签名一样简单，只要有适当的上下文和用户批准。

• CLI 和本地网络： 为了更直接的交互，提供了一个名为 dWallet CLI 的命令行界面 (CLI)。开发者可以通过分叉开源仓库来运行一个本地 Ika 节点，甚至是一个本地测试网络。这对于在开发环境中进行测试和集成非常有价值。文档指导用户如何设置本地开发网络、获取测试网代币 (DWLT——测试网代币) 以及创建第一个 dWallet 地址。

• 文档和示例： Ika 的文档包括针对常见场景的逐步教程，例如**“你的第一个 dWallet”**。这些教程展示了如何建立一个对应于另一条链上地址的 dWallet (例如，一个由 Ika 密钥控制的比特币地址)，如何加密用户的密钥分片以安全保管，以及如何发起跨链交易。示例代码涵盖了诸如通过 Sui 智能合约调用转移 BTC，或安排未来交易 (Ika 支持的一项功能，即在特定条件下预先签署交易) 等用例。

• Sui 集成 (轻客户端)： Ika 开箱即用地与 Sui 区块链紧密集成。Ika 网络内部运行一个 Sui 轻客户端，以无需信任地读取 Sui 链上数据。这意味着一个 Sui 智能合约可以发出一个事件或调用，Ika 将通过状态证明识别其为执行某个操作的触发器。例如，一个 Sui 合约可能会指示 Ika：“当事件 X 发生时，签署并在以太坊上广播一笔交易”。Ika 节点将使用轻客户端证明验证 Sui 事件，然后共同为以太坊交易生成签名。签名的有效载荷随后可以被传递到目标链 (可能由链下中继器或用户传递) 以执行所需的操作。目前，Sui 是第一个完全支持的控制链 (鉴于 Ika 起源于 Sui)，但其架构是天生多链的。支持其他链的状态证明和集成已在路线图上——例如，团队提到将 Ika 扩展到与 Polygon Avail 生态系统中的 Rollup 合作 (在以 Avail 作为数据层的 Rollup 上提供 dWallet 功能)，以及未来支持其他 Layer-1。

• 支持的加密算法： Ika 的网络可以为几乎任何区块链的签名方案生成密钥/签名。它最初支持 ECDSA (比特币、以太坊的 ECDSA 账户、BNB 链等使用的椭圆曲线算法)。在短期内，计划支持 EdDSA (Ed25519，被 Solana 和一些 Cosmos 链等使用) 和Schnorr 签名 (例如比特币 Taproot 的 Schnorr 密钥)。这种广泛的支持意味着一个 Ika dWallet 可以在比特币上有一个地址，在以太坊上有一个地址，在 Solana 上有一个地址等等——所有这些都由同一个底层的分布式密钥控制。因此，Sui 或其他平台上的开发者可以通过一个统一的框架 (Ika) 将这些链中的任何一个集成到他们的 dApp 中，而无需处理特定于链的桥或托管方。

总而言之，Ika 提供了类似于与区块链节点或钱包交互的开发者体验，抽象了繁重的密码学。无论是通过 TypeScript SDK 还是直接通过 Move 合约和轻客户端，它都力求使跨链逻辑对构建者来说**“即插即用”**。

安全性、去中心化与容错性​

安全性在 Ika 的设计中至关重要。零信任模型意味着用户在任何时候都无需信任 Ika 网络单方面控制其资产。如果用户创建一个 dWallet (比如一个由 Ika 管理的 BTC 地址)，该地址的私钥绝不会由任何单一实体持有——甚至用户自己也不单独持有。相反，用户持有一个秘密分片，网络则共同持有另一个分片。两者都是必需的才能签署任何交易。因此，即使发生最坏的情况 (例如，许多 Ika 节点被攻击者攻破)，他们_仍然无法移动资金_，因为没有用户的秘密密钥分片。这一特性解决了传统桥梁中的一个主要风险，即一定数量的验证者可以合谋窃取锁定的资产。Ika 通过从根本上改变访问结构来消除这种风险 (门限的设置使得网络_本身_永远不够——门限实际上包括了用户)。在文献中，这是一种新的范式：一个非共谋的 MPC 网络，其中资产所有者通过设计成为签名群体的一部分。

在网络方面，Ika 使用委托权益证明模型 (继承自 Sui 的设计) 来选择和激励验证者。IKA 代币持有者可以将权益委托给验证者节点；权益加权排名前列的验证者成为一个纪元 (epoch) 的权威，并且在每个纪元中都是拜占庭容错的 (2/3 诚实)。这意味着系统假设少于 33% 的权益是恶意的以维持安全性。如果一个验证者行为不端 (例如，试图产生不正确的签名分片或审查交易)，共识和 MPC 协议会检测到它——不正确的签名分片可以被识别出来 (它们无法组合成有效的签名)，而恶意节点可以被记录下来，并可能在未来的纪元中被罚没或移除。同时，只要有足够多的节点 (>67%) 参与，活性就能得到维持；即使许多节点意外崩溃或离线，共识仍能继续最终确定操作。这种容错性确保了服务的鲁棒性——不存在单点故障，因为有数百个位于不同司法管辖区的独立运营商参与。参与者的数量进一步加强了去中心化：Ika 不局限于一个固定的小型委员会，因此它可以接纳更多的验证者来提高安全性，而不会牺牲太多性能。事实上，Ika 的协议被明确设计为**“超越 MPC 网络的节点限制”**并允许大规模的去中心化。

最后，Ika 团队已将其密码学提交给外部审查。他们在 2024 年发布了一份详尽的白皮书，详细介绍了 2PC-MPC 协议，并且迄今为止至少进行了一次第三方安全审计。例如，在 2024 年 6 月，Symbolic Software 的一次审计审查了 Ika 的 2PC-MPC 协议的 Rust 实现及相关的加密库。该审计会重点验证密码学协议的正确性 (确保门限 ECDSA 方案、密钥生成或分片聚合中没有缺陷) 并检查潜在的漏洞。其代码库是开源的 (在 dWallet Labs GitHub 下)，允许社区检查并为其安全性做出贡献。在 alpha 测试网阶段，团队也提醒说该软件仍处于实验阶段，尚未经过生产环境审计，但在主网上线前，持续的审计和安全改进是首要任务。总而言之，Ika 的安全模型是可证明的密码学保证 (来自门限方案) 和区块链级别的去中心化 (来自 PoS 共识和大型验证者集) 的结合，并经过专家审查，以提供对外部攻击者和内部共谋的强大保障。

兼容性与生态互操作性​

Ika 是专门为成为一个互操作性层而构建的，最初是为 Sui 设计，但可扩展到许多生态系统。从第一天起，它与 Sui 区块链的集成最为紧密：它实际上充当了 Sui 的一个附加模块，赋予 Sui dApp 多链能力。这种紧密结合是设计使然——Sui 的 Move 合约和以对象为中心的模型使其成为 Ika dWallets 的一个良好“控制器”。例如，一个 Sui DeFi 应用程序可以使用 Ika 随时从以太坊或比特币获取流动性，使 Sui 成为多链流动性的中心。Sui 基金会对 Ika 的支持表明了一种将 Sui 定位为_“所有链的基础链”_的战略，利用 Ika 连接外部资产。实际上，当 Ika 主网上线后，一个 Sui 构建者可能会创建一个 Move 合约，比如说，接受 BTC 存款：在幕后，该合约会通过 Ika 创建一个比特币 dWallet (一个地址)，并在需要时发出移动 BTC 的指令。最终用户体验到的就好像比特币只是 Sui 应用内管理的另一种资产，尽管 BTC 在一个有效的门限签名交易移动它之前，一直原生存在于比特币上。

除了 Sui，Ika 的架构还支持其他 Layer-1 区块链、Layer-2，甚至链下系统。该网络可以同时托管多个轻客户端，因此它可以验证来自以太坊、Solana、Avalanche 或其他链的状态——从而使这些链上的智能合约 (或其用户) 也能利用 Ika 的 MPC 网络。虽然这些功能可能会逐步推出，但其设计目标是_链无关_。在此期间，即使没有深度的链上集成，Ika 也可以以更手动的方式使用：例如，以太坊上的一个应用程序可以通过 Oracle 或链下服务调用 Ika API，来请求一个以太坊交易或消息的签名。因为 Ika 支持 ECDSA，它甚至可以用来以去中心化的方式管理一个以太坊账户的密钥，类似于 Lit Protocol 的 PKP 的工作方式 (我们稍后会讨论 Lit)。Ika 还展示了诸如在 Rollup 上控制比特币的用例——一个例子是与 Polygon Avail 框架集成，允许 Rollup 用户在不信任中心化托管方的情况下管理 BTC。这表明 Ika 可能会与各种生态系统 (Polygon/Avail、Celestia Rollup 等) 合作，作为去中心化密钥基础设施的提供商。

总而言之，从技术角度来看，Ika 与任何依赖数字签名的系统兼容——这基本上涵盖了所有区块链。它在 Sui 上的初始部署仅仅是个开始；长期愿景是一个通用的 MPC 层，任何链或 dApp 都可以接入，以进行安全的跨链操作。通过支持常见的密码学标准 (ECDSA、Ed25519、Schnorr) 并提供所需的轻客户端验证，Ika 可能成为整个 Web3 的一种_“MPC 即服务”_网络，以信任最小化的方式连接资产和操作。

商业与投资视角​

创始团队与背景​

Ika 由一支经验丰富的密码学和区块链专家团队创立，主要位于以色列。该项目的创始人和 CEO 是 Omer Sadika，一位在加密安全领域拥有深厚背景的企业家。Omer 此前曾联合创立 Odsy Network，这是另一个专注于去中心化钱包基础设施的项目，他也是 Ika 背后的公司 dWallet Labs 的创始人/CEO。他的背景包括在 Y Combinator 的培训 (YC 校友)，并专注于网络安全和分布式系统。Omer 在 Odsy 和 dWallet Labs 的经验直接启发了 Ika 的愿景——本质上，Ika 可以被看作是 Odsy 致力于的“动态去中心化钱包”概念的演进，现在作为 Sui 上的一个 MPC 网络实现。

Ika 的 CTO 和联合创始人是 Yehonatan Cohen Scaly，一位密码学专家，他共同撰写了 2PC-MPC 协议。Yehonatan 领导 Ika 新颖密码学算法的研发，并曾在网络安全领域工作 (可能在密码学方面有学术研究)。他曾被引述讨论现有门限方案的局限性以及 Ika 的方法如何克服这些局限性，反映了他在 MPC 和分布式密码学协议方面的深厚专业知识。另一位联合创始人是 David Lachmish，他负责产品开发。David 的角色是将核心技术转化为对开发者友好的产品和现实世界的用例。Omer、Yehonatan 和 David 三人组——以及像 Dolev Mutzari 博士 (dWallet Labs 研究副总裁) 这样的其他研究人员——构成了 Ika 的领导核心。总的来说，该团队的资历包括之前的创业经历、学术研究贡献以及在加密、安全和区块链交叉领域的经验。正是这种深度使得 Ika 被描述为由“世界上一些顶尖的密码学专家”创建。

除了创始人，Ika 更广泛的团队和顾问可能还包括具有强大密码学背景的个人。例如，上面提到的 Dolev Mutzari 是技术论文的合著者，并在协议设计中发挥了重要作用。这样的人才存在让投资者相信 Ika 的复杂技术掌握在能干的人手中。此外，有一位已经成功融资并围绕 Odsy/dWallet 概念建立社区的创始人 (Omer)，意味着 Ika 受益于该想法先前迭代中吸取的经验教训。团队的基地在以色列——一个以其密码学和网络安全行业而闻名的国家——也使他们处于一个丰富的人才库中，便于招聘开发人员和研究人员。

融资轮次与主要支持者​

Ika (及其母公司 dWallet Labs) 自成立以来已吸引了大量风险投资和战略投资。迄今为止，它已在多轮融资中筹集了超过 2100 万美元。该项目最初的种子轮在 2022 年 8 月为 500 万美元，考虑到当时的熊市环境，这相当引人注目。该种子轮包括了众多知名的加密投资者和天使投资人。值得注意的参与者包括 Node Capital (领投)、Lemniscap、Collider Ventures、Dispersion Capital、Lightshift Capital、Tykhe Block Ventures、Liquid2 Ventures、Zero Knowledge Ventures 等。著名的个人投资者也加入了，如 Naval Ravikant (AngelList 联合创始人及著名科技投资者)、Marc Bhargava (Tagomi 联合创始人)、Rene Reinsberg (Celo 联合创始人) 以及其他几位行业人物。这样的支持者阵容凸显了即使在概念阶段，市场对 Ika 的去中心化托管方法的强烈信心。

在 2023 年 5 月，Ika 在一轮似乎是 A 轮或战略轮的融资中又筹集了约 750 万美元，据报道估值约为 2.5 亿美元。此轮融资由 Blockchange Ventures 和 Node Capital (再次) 领投，Insignius Capital、Rubik Ventures 等参与。到那时，可扩展 MPC 网络的论点已获得关注，Ika 的进展可能吸引了这些投资者加倍下注。对于一个相对早期的网络来说，2.5 亿美元的估值反映了市场预期 Ika 可能成为 Web3 的基础性基础设施 (在价值上与 L1 区块链或主要 DeFi 协议相当)。

最引人注目的投资发生在 2025 年 4 月，当时 Sui 基金会宣布对 Ika 进行战略投资。这次与 Sui 生态系统基金的合作使 Ika 的总融资额超过 2100 万美元，并巩固了其与 Sui 区块链的紧密联盟。虽然 Sui 基金会投资的确切金额未公开披露，但很明显这是一次重要的认可——可能在数百万美元的量级。Sui 基金会的支持不仅是财务上的；它还意味着 Ika 在 Sui 生态系统内获得了强大的市场推广支持 (开发者外展、集成支持、市场营销等)。根据新闻稿，“Ika……宣布获得 Sui 基金会的战略投资，使其总融资额超过 2100 万美元。” 这次战略轮，而非传统的 VC 股权轮，突显了 Sui 将 Ika 视为其区块链未来的关键基础设施 (类似于以太坊基金会可能直接支持一个有益于以太坊的 Layer-2 或互操作性项目)。

除了 Sui，其他值得注意的支持者还有 Node Capital (一家以早期基础设施投资闻名的中国加密基金)、Lemniscap (一家专注于早期协议创新的加密风投) 和 Collider Ventures (一家以色列风投，可能提供本地支持)。Blockchange Ventures 领投 2023 年的融资值得注意；Blockchange 是一家投资了多个加密基础设施项目的风投，他们的领投表明他们认为 Ika 的技术可能定义一个类别。此外，根据 Omer 的一篇 LinkedIn 帖子，Digital Currency Group (DCG) 和 Node Capital 在 Ika 更名之前为 dWallet Labs 领投了一轮 500 万美元的融资——DCG 的参与 (通过公司早期的一轮融资) 表明背后还有更多的支持。

总而言之，Ika 的融资历程显示了传统风投和战略合作伙伴的混合。Sui 基金会的参与尤其突出，因为它不仅提供了资本，还提供了一个集成的生态系统来部署 Ika 的技术。投资者基本上是在押注 Ika 将成为跨多个网络的_去中心化密钥管理和桥接的首选解决方案_，并相应地对该项目进行了估值。

代币经济学与经济模型​

Ika 将拥有一个名为 $IKA 的原生实用代币，它是网络经济和安全模型的核心。独特的是，IKA 代币正在在 Sui 区块链上作为 SUI 原生资产推出，尽管 Ika 网络本身是一个独立的链。这意味着 IKA 将作为一种可以在 Sui 上像任何其他 Sui 资产一样持有和转移的代币存在，并且它将以双重方式使用：在 Ika 网络内用于质押和支付费用，在 Sui 上用于治理或在 dApp 中进行访问。其代币经济学可以概述如下：

• Gas 费： 正如 ETH 是以太坊的 Gas 或 SUI 是 Sui 的 Gas 一样，IKA 作为 Ika 网络上 MPC 操作的 Gas/支付。当用户或 dApp 请求签名或 dWallet 操作时，会向网络支付一笔 IKA 费用。这些费用补偿验证者运行门限签名协议的计算和通信工作。白皮书将 IKA 的角色比作 Sui 的 Gas，确认所有由 Ika 促成的跨链交易都将产生少量 IKA 费用。费用表可能与操作的复杂性成正比 (例如，单个签名可能花费一个基准费用，而更复杂的多步工作流可能花费更多)。

• 质押与安全： IKA 也是一个质押代币。Ika 网络中的验证者节点必须被委托一定数量的 IKA 权益才能参与共识和签名。共识遵循类似于 Sui 的委托权益证明机制：代币持有者将 IKA 委托给验证者，每个验证者在共识中的权重 (以及因此在门限签名过程中的权重) 由权益决定。在每个纪元中，验证者被选出，他们的投票权是权益的函数，整个集合是拜占庭容错的 (意味着如果一个验证者集总共有 $X 的权益，最多约$X/3 的权益可以是恶意的而不会破坏网络保证)。质押者 (委托人) 通过质押奖励获得激励：Ika 的模型可能包括在纪元结束时将收集到的费用 (以及可能的通胀奖励) 分配给验证者及其委托人。确实，文档指出所有收集到的交易费用都分配给权威，他们可能会与委托人分享一部分作为奖励。这反映了 Sui 奖励服务提供商吞吐量的模型。

• 供应与分配： 截至目前 (2025 年第二季度)，关于 IKA 的总供应量、初始分配和通胀的细节尚未完全公开。然而，鉴于融资轮次，我们可以推断出一些结构。很可能，一部分 IKA 分配给了早期投资者 (种子轮和系列轮) 和团队，大部分保留用于社区和未来的激励。可能计划有社区销售或空投，特别是因为 Ika 曾举办过一次著名的 NFT 活动，筹集了 140 万 SUI (这是 Sui 上的一个 NFT 艺术活动，创下了记录；该活动的参与者可能会获得 IKA 奖励或早期访问权)。这次 NFT 活动表明了一种让社区参与并向用户而非仅仅是 VC 引导代币分配的策略。

• 代币上线时间： Sui 基金会 2024 年 10 月的公告指出，“IKA 代币将在 Sui 上原生上线，解锁去中心化安全中的新功能和实用性”。主网计划于 2024 年 12 月上线，因此代币生成事件 (TGE) 可能会同时或稍后发生。如果主网按计划上线，IKA 代币可能在 2024 年底或 2025 年初开始分发。然后，该代币将开始用于 Ika 网络的 Gas 和质押。在此之前，在测试网上，一个临时代币 (测试网上的 DWLT) 被用作 Gas，它没有实际价值。

• 用例与价值累积： IKA 作为一项投资的价值取决于 Ika 网络的使用情况。随着更多的跨链交易通过 Ika 流通，更多的费用以 IKA 支付，从而产生需求。此外，如果许多人想运行验证者或保护网络，他们必须获取并质押 IKA，这会锁定供应 (减少流通量)。因此，IKA 具有实用性加治理的性质——实用性在于支付服务和质押，并且很可能在指导协议未来方面具有治理作用 (尽管治理尚未明确提及，但这类网络通常最终会通过代币投票实现控制的去中心化)。可以想象，未来 IKA 代币持有者可以投票决定增加对新链的支持、调整费用参数或其他协议升级。

总的来说，IKA 的代币经济学旨在平衡网络安全性和可用性。通过在 Sui 上推出，他们使 Sui 生态系统的用户可以轻松获取和使用 IKA (代币本身无需单独的链上引导)，这可以快速启动采用。投资者将关注诸如质押供应比例 (表明安全性)、费用收入 (表明使用情况) 和推动交易的合作伙伴关系 (表明对代币的需求) 等指标。

商业模式与上市策略​

Ika 的商业模式是区块链生态系统中的基础设施提供商。它不提供面向消费者的产品；相反，它提供一种协议服务 (去中心化的密钥管理和交易执行)，供其他项目集成。因此，主要的收入 (或价值捕获) 机制是服务费——即使用网络时以 IKA 支付的 Gas 费。可以将 Ika 比作一个去中心化的 AWS，用于密钥签名：任何开发者都可以接入并使用它，按次付费。从长远来看，随着网络的去中心化，dWallet Labs (创始公司) 可能会通过持有网络股份和代币增值来捕获价值，而不是收取 SaaS 风格的链下费用。

上市 (GTM) 策略： 早期，Ika 的目标是需要跨链功能或托管解决方案的区块链开发者和项目。与 Sui 的结盟为其提供了一个现成的开发者池。Sui 本身作为一个较新的 L1，需要独特的功能来吸引用户——而 Ika 在 Sui 上提供了跨链 DeFi、比特币访问等引人注目的功能。因此，Ika 的 GTM 策略搭上了 Sui 不断增长的生态系统的顺风车。值得注意的是，即使在主网上线之前，已有几个 Sui 项目宣布正在集成 Ika：

• 像 Full Sail、Rhei、Aeon、Human Tech、Covault、Lucky Kat、Native、Nativerse、Atoma 和 Ekko (都是 Sui 上的构建者) 这样的项目已经**“宣布他们即将推出的产品将利用 Ika”**，涵盖了从 DeFi 到游戏的各种用例。例如，Full Sail 可能正在构建一个可以通过 Ika 交易 BTC 的交易所；Lucky Kat (一个游戏工作室) 可以使用 Ika 来实现在多个链上存在的游戏内资产；Covault 可能涉及托管解决方案等。通过早期确保这些合作伙伴关系，Ika 确保了在上线时将有即时的交易量和展示其能力的真实应用。

• Ika 也强调机构用例，例如_为机构提供去中心化托管_。在新闻稿中，他们强调 Ika 在托管方面为“机构和个人用户提供无与伦比的安全性”。这表明 Ika 可以被推广给加密托管机构、交易所，甚至那些希望以更安全的方式管理私钥的传统金融 (TradFi) 参与者 (或许可以作为 Fireblocks 或 Copper 的替代或补充，后者使用 MPC 但在中心化的企业环境中)。事实上，作为一个去中心化的网络，Ika 可以让托管领域的竞争对手都依赖于同一个强大的签名网络，而不是各自构建自己的。这种合作模式可能会吸引那些偏好为某些资产使用中立、去中心化托管方的机构。

• 另一个角度是AI 集成：Ika 提到_“AI 代理护栏”_作为一个用例。这是具有前瞻性的，利用了 AI 自主性 (例如，AI 代理在区块链上执行) 的趋势。Ika 可以确保一个 AI 代理 (比如一个被赋予控制某些资金的自主经济代理) 不能带着资金跑路，因为代理本身不是密钥的唯一持有者——它仍然需要用户的分片或遵守 Ika 中的条件。将 Ika 营销为为 Web3 中的 AI 提供安全护栏是一个新颖的角度，可以吸引该领域的兴趣。

在地理上，Node Capital 等公司的存在也暗示了除了西方市场之外，对亚洲市场的关注。Sui 在亚洲 (尤其是在中国) 拥有强大的社区。Ika 在 Sui 上的 NFT 活动 (筹集了 140 万 SUI 的艺术活动) 表明了一种社区建设的努力——可能吸引了在 Sui NFT 领域非常活跃的中国用户。通过进行 NFT 销售或社区空投，Ika 可以培养一个持有 IKA 代币并有动力推广其采用的草根用户基础。

随着时间的推移，商业模式可以扩展到提供高级功能或企业集成。例如，虽然公共 Ika 网络是无需许可的，但 dWallet Labs 可以为某些客户启动私有实例或联盟版本，或为集成 Ika 的项目提供咨询服务。他们也可以通过早期运行一些验证者 (引导阶段) 来赚取部分费用。

总而言之，Ika 的 GTM 策略与生态系统合作伙伴关系紧密相连。通过深入嵌入 Sui 的路线图 (Sui 的 2025 年目标包括跨链流动性和独特用例)，Ika 确保它将乘着该 L1 的增长浪潮。同时，它将自己定位为多链协调的通用解决方案，一旦在 Sui 上取得成功，就可以推广给其他链上的项目。Sui 基金会的支持和早期的集成公告，使 Ika 在信誉和采用方面比孤立推出具有显著的领先优势。

生态采用、合作伙伴关系与路线图​

即使在早期阶段，Ika 已经建立了一个令人印象深刻的生态系统合作名录：

• Sui 生态系统采用： 如前所述，多个基于 Sui 的项目正在集成 Ika。这意味着在 Ika 主网上线后，我们预计会看到 Sui dApp 启用诸如_“由 Ika 驱动”_的功能——例如，一个允许用户存入 BTC 的 Sui 借贷协议，或者一个在 Sui 上的 DAO 使用 Ika 在多个链上持有其金库。像 Rhei、Atoma、Nativerse (可能是 DeFi 项目) 和 Lucky Kat (游戏/NFT) 这样的名字的加入表明，Ika 的适用性涵盖了各个垂直领域。

• 战略合作伙伴关系： Ika 最重要的合作伙伴是 Sui 基金会本身，它既是投资者也是推广者。Sui 的官方渠道 (博客等) 已经重点介绍了 Ika，实际上是将其认可为 Sui 的互操作性解决方案。此外，Ika 可能一直在与其他基础设施提供商合作。例如，鉴于提到了 zkLogin (Sui 的 Web2 登录功能) 和 Ika，可能存在一个组合用例，其中 zkLogin 处理用户认证，Ika 处理跨链交易，共同提供无缝的用户体验。此外，Ika 在其博客中提到 Avail (Polygon)，这表明在该生态系统中存在合作或试点项目：也许是与 Polygon Labs 或在 Avail 上构建 Rollup 的团队合作，使用 Ika 将比特币桥接到这些 Rollup。另一个潜在的合作领域是托管方——例如，将 Ika 与像 Zengo 这样的钱包提供商 (值得注意的是，ZenGo 的联合创始人曾是 Omer 之前的项目) 或与像 Fireblocks 这样的机构托管技术集成。虽然尚未确认，但这些将是合乎逻辑的目标 (实际上 Fireblocks 在其他地方与 Sui 有合作；可以想象 Fireblocks 利用 Ika 在 Sui 上进行 MPC)。

• 社区与开发者参与： Ika 运营一个 Discord，并可能举办黑客松，以吸引开发者使用 dWallets 进行构建。这项技术是新颖的，因此通过教育来宣传它至关重要。他们网站上的“用例”和“构建者”部分，以及解释核心概念的博客文章，表明了他们正在努力让开发者熟悉 dWallets 的概念。开发者越了解他们可以在不使用桥梁 (且不损害安全) 的情况下构建跨链逻辑，有机采用就会越多。

• 路线图： 截至 2025 年，Ika 的路线图包括：

  • Alpha 和测试网 (2023–2024)： alpha 测试网于 2024 年在 Sui 上启动，允许开发者试验 dWallets 并提供反馈。此阶段用于完善协议、修复错误和进行内部审计。
  • 主网上线 (2024 年 12 月)： Ika 计划在 2024 年底上线主网。如果实现，到目前 (2025 年中)，Ika 的主网应该已经运行。上线可能包括对一组链的初始支持：至少比特币和以太坊 (ECDSA 链) 会在第一时间支持，因为这些在市场营销中被大量提及。
  • 2025 年上线后目标： 在 2025 年，我们预计重点将是扩大使用量 (通过 Sui 应用并可能扩展到其他链)。团队将在上线后不久致力于增加对 Ed25519 和 Schnorr 的支持，从而实现与 Solana、Polkadot 和其他生态系统的集成。他们还将实现更多的轻客户端 (可能是 Ika 的以太坊轻客户端、Solana 轻客户端等)，以扩大无需信任的控制范围。另一个路线图项目可能是无需许可的验证者扩展——鼓励更多独立的验证者加入，并进一步去中心化网络。由于代码是 Sui 的一个分叉，运行一个 Ika 验证者类似于运行一个 Sui 节点，许多运营商都可以做到。
  • 功能增强： 博客中暗示了两个有趣的功能是_加密用户分片_和_未来交易签名_。加密用户分片意味着用户可以选择性地加密他们的私有分片并将其存储在链上 (可能在 Ika 或其他地方)，其方式只有他们自己可以解密，从而简化了恢复过程。未来交易签名意味着 Ika 能够预先签署一个在满足条件时稍后执行的交易。这些功能提高了可用性 (如果用户预先批准了某些逻辑，他们就不必为每个操作都保持在线，同时还能保持非托管的安全性)。在 2025 年交付这些功能将进一步区分 Ika 的产品。
  • 生态系统增长： 到 2025 年底，Ika 的目标可能是让多个链生态系统积极使用它。我们可能会看到，例如，一个以太坊项目通过 Oracle 使用 Ika (如果直接的链上集成尚未实现)，或者与像 Wormhole 或 LayerZero 这样的跨链项目合作，Ika 可以作为安全消息传递的签名机制。

竞争格局也将塑造 Ika 的战略。它并非唯一提供去中心化密钥管理的公司，因此其路线图的一部分将涉及突出其性能优势和独特的两方安全模型，以区别于其他公司。在下一节中，我们将 Ika 与其著名的竞争对手 Lit Protocol、Threshold Network 和 Zama 进行比较。

竞争分析：Ika vs. 其他 MPC/门限网络​

Ika 在一个前沿的密码学网络领域运营，其中一些项目正以不同的方法追求类似的目标。以下是 Ika 与 Lit Protocol、Threshold Network 和 Zama (每个都是去中心化密钥基础设施或隐私计算领域的代表性竞争对手) 的总结比较：

Ika 的竞争优势： Ika 的差异化在于其规模化性能和独特的安全模型。与 Lit Protocol 相比，Ika 可以支持更多的签名者和更高的吞吐量，使其适用于 Lit 网络难以处理的用例 (如高容量交易或游戏)。Ika 也不依赖于可信执行环境，一些开发者对此持谨慎态度 (由于 SGX 中潜在的漏洞)；相反，Ika 纯粹通过密码学和共识实现无需信任。相对于 Threshold Network，Ika 提供了一个更通用的平台。Threshold 主要专注于比特币↔以太坊桥接 (tBTC) 和一些密码学服务，如代理重加密，而 Ika 是一个灵活的互操作性层，可以开箱即用地与任何链和资产合作。此外，Ika 的用户参与模型意味着它不需要对存款进行超额抵押或保险 (tBTC v2 使用一个强大但复杂的经济模型来保护 BTC 存款，而在 Ika 中，用户从一开始就从未放弃控制权)。与 Zama 相比，Ika 解决的是一个不同的问题——Zama 针对隐私，而 Ika 针对互操作性。然而，可以想象未来两者可以互补 (例如，在 Ika 存储的资产上使用 FHE)。目前，Ika 的优势在于它能在一个有即时需求的细分市场中更早地投入运营 (如今需要桥和 MPC 网络，而 FHE 仍在成熟中)。

Ika 的一个潜在挑战是市场教育和信任。它正在引入一种进行跨链交互的新方式 (dWallets 而非传统的锁定-铸造桥)。它需要随着时间的推移在实践中证明其安全性，以赢得与 Threshold Network 逐渐赢得的同等信任水平 (Threshold 在早期版本因风险暂停后，不得不证明 tBTC 的可靠性)。如果 Ika 的技术如宣传的那样运作，它实际上通过解决 MPC 领域的去中心化、安全性和速度三难问题，超越了竞争对手。来自 Sui 的强力支持以及广泛的审计/论文为其增添了可信度。

总之，Ika 因其雄心勃勃的可扩展性和以用户为中心的安全模型而在 MPC 网络中脱颖而出。投资者将其视为对跨链协调未来的押注——一个用户可以无缝地在多个区块链之间移动价值和逻辑，而无需放弃对其密钥的控制。如果 Ika 获得广泛采用，它可能成为 Web3 基础设施中与跨链消息协议或主要 Layer-1 区块链本身一样不可或缺的一部分。未来一年 (2025 年) 将至关重要，因为 Ika 的主网和首批用例将上线，证明这种尖端密码学是否能在真实市场条件下兑现其承诺。早期的迹象——强大的技术基础、活跃的集成渠道和大量的投资者支持——表明 Ika 有真正的机会用 MPC 重新定义区块链的互操作性。

来源： 主要信息收集自 Ika 的官方文档和白皮书、Sui 基金会的公告、新闻稿和融资新闻，以及竞争对手的技术文档和分析以供参考 (Lit Protocol 的 Messari 报告、Threshold Network 文档和 Zama 的 FHE 描述)。所有信息截至 2025 年均为最新。

公共区块链以牺牲隐私为代价提供了透明度和完整性——每笔交易和合约状态都对所有参与者公开。这种开放性带来了诸如 MEV (矿工可提取价值) 攻击、复制交易以及敏感商业逻辑泄露等问题。可编程隐私旨在通过允许在不泄露数据本身的情况下对私有数据进行计算来解决这些问题。两种新兴的密码学范式正在使这成为可能：全同态加密虚拟机 (FHE-VM) 和零知识 (ZK) 协处理器。这些方法实现了链下或加密计算与链上验证，在保留信任的同时保护了机密性。在本报告中，我们将深入探讨 FHE-VM 和 ZK 协处理器的架构，比较它们的优缺点，并探索它们在金融、身份、医疗、数据市场和去中心化机器学习等领域的用例。

全同态加密虚拟机 (FHE-VM)​

全同态加密 (FHE) 允许在不解密数据的情况下对加密数据进行任意计算。FHE 虚拟机将此功能集成到区块链智能合约中，实现了加密的合约状态和逻辑。在一个支持 FHE 的区块链（对于 EVM 兼容的设计，通常称为 fhEVM）中，所有输入、合约存储和输出在整个执行过程中都保持加密状态。这意味着验证者可以在不了解任何敏感值的情况下处理交易和更新状态，从而实现具有数据机密性的链上执行。

FHE-VM 的架构与设计​

一个典型的 FHE-VM 扩展了标准的智能合约运行时（如以太坊虚拟机），增加了对加密数据类型和操作的原生支持。例如，Zama 的 FHEVM 引入了加密整数（euint8、euint32 等）、加密布尔值（ebool），甚至加密数组作为一等类型。像 Solidity 这样的智能合约语言通过库或新的操作码进行了增强，使开发者可以直接对密文执行算术（add、mul 等）、逻辑和比较操作。在底层，这些操作调用 FHE 原语（例如，使用 TFHE 库）来操作加密位并产生加密结果。

加密状态存储也得到支持，以便合约变量在区块链状态中保持加密。执行流程通常如下：

1. 客户端加密： 用户在发送交易前，使用公共 FHE 密钥在本地加密其输入。加密密钥是公开的（用于加密和评估），而解密密钥则保持私密。在某些设计中，每个用户管理自己的密钥；在其他设计中，使用单个全局 FHE 密钥（下文将讨论）。
2. 链上同态计算： 矿工/验证者使用加密的操作码执行合约。他们对密文执行相同的确定性同态操作，因此可以在加密的新状态上达成共识。关键是，验证者永远看不到明文数据——他们只看到“乱码”的密文，但仍然可以一致地处理它。
3. 解密（可选）： 如果需要公开或在链下使用某个结果，拥有私钥的授权方可以解密输出的密文。否则，结果将保持加密状态，并可用作后续交易的输入（允许对持久的加密状态进行连续计算）。

一个主要的设计考虑是密钥管理。一种方法是每个用户一个密钥，即每个用户持有自己的私钥，只有他们才能解密与他们相关的输出。这最大限度地保护了隐私（其他任何人都无法解密你的数据），但同态操作无法混合使用不同密钥加密的数据，除非使用复杂的多密钥协议。另一种方法，被 Zama 的 FHEVM 采用，是全局 FHE 密钥：一个单一的公钥加密所有合约数据，而一组分布式的验证者持有门限解密密钥的份额。公共加密和评估密钥在链上发布，因此任何人都可以向网络加密数据；私钥被分割给验证者，他们可以在门限方案下集体解密（如果需要）。为了防止验证者串通损害隐私，Zama 采用了一种门限 FHE 协议（基于他们的 Noah’s Ark 研究），并使用“噪声泛洪”来确保部分解密的安全性。只有当足够数量的验证者合作时，才能恢复明文，例如响应一个读取请求。然而，在正常操作中，没有任何单个节点能看到明文——数据在链上始终保持加密。

访问控制是另一个关键组成部分。FHE-VM 实现包括细粒度的控制，以管理谁（如果有的话）可以触发解密或访问某些加密字段。例如，Cypher 的 fhEV M支持对密文的访问控制列表，允许开发者指定哪些地址或合约可以与某些数据交互或重新加密。一些框架支持重加密：即在不暴露明文的情况下，将一个加密值从一个用户的密钥转移到另一个用户的密钥。这对于数据市场等场景非常有用，数据所有者可以用自己的密钥加密数据集，在购买后，将其重加密为买家的密钥——所有操作都在链上完成，无需公开解密。

确保正确性和隐私性​

有人可能会问：如果所有数据都是加密的，我们如何强制执行合约逻辑的正确性？如果链无法“看到”值，它如何防止无效操作？FHE 本身不提供正确性证明——验证者可以执行同态步骤，但他们无法在不解密的情况下判断用户的加密输入是否有效，或者是否应该执行某个条件分支。零知识证明 (ZKPs) 可以补充 FHE 来解决这个问题。在 FHE-VM 中，通常用户在需要时必须提供一个 ZK 证明来证实某些明文条件。例如，Zama 的设计在每个加密输入中都附带一个明文知识的零知识证明 (ZKPoK)。这证明了用户知道其密文对应的明文，并且该明文符合预期标准，而无需透露明文本身。这种**“认证密文”**可以防止恶意用户提交格式错误的加密或超出范围的值。同样，对于需要决策的操作（例如，确保账户余额 ≥ 提款金额），用户可以在执行加密操作之前提供一个 ZK 证明，证明该条件在明文上成立。这样，链既不解密也不查看值，但它能确信加密交易遵循了规则。

FHE Rollup 中的另一种方法是使用 ZKPs 进行链下验证。Fhenix（一个使用 FHE 的 L2 Rollup）选择了一种乐观模型，其中一个名为门限服务网络的独立网络组件可以解密或验证加密结果，任何不正确的计算都可以通过欺诈证明进行挑战。总的来说，结合 FHE + ZK 或欺诈证明可以确保加密执行保持无需信任。验证者要么仅在授权时集体解密，要么验证每个加密状态转换都是有效的证明，而无需看到明文。

性能考虑： FHE 操作的计算量非常大——比普通算术慢几个数量级。例如，在以太坊上进行一次简单的 64 位加法大约花费 3 Gas，而在 Zama 的 FHEVM 下对一个加密的 64 位整数 (euint64) 进行加法大约需要 188,000 Gas。即使是 8 位的加法也可能花费约 94k Gas。这种巨大的开销意味着在现有节点上直接实现将非常缓慢且成本高昂。FHE-VM 项目通过优化的密码学库（如 Zama 用于二进制门自举的 TFHE-rs 库）和定制的 EVM 修改来解决这个问题。例如，Cypher 修改后的 Geth 客户端增加了新的操作码，并在 C++/汇编中优化了同态指令的执行，以最小化开销。尽管如此，要实现可用的吞吐量还需要加速。正在进行的工作包括使用 GPU、FPGA 甚至专门的光子芯片来加速 FHE 计算。Zama 报告称，自 2024 年以来，他们的 FHE 性能提高了 100 倍，并计划通过 GPU/FPGA 加速实现数千 TPS。专用的 FHE 协处理器服务器（如 Optalysys 的 LightLocker Node）可以插入验证者节点，将加密操作卸载到硬件上，支持每个节点每秒超过 100 次加密的 ERC-20 转账。随着硬件和算法的改进，FHE 与明文计算之间的差距将缩小，使私有合约能够接近更实用的速度。

兼容性： FHE-VM 设计的一个关键目标是与现有的开发工作流程保持兼容。Cypher 和 Zama 的 fhEVM 实现允许开发者使用 Solidity 编写合约，只需进行最小的更改——使用一个库来声明加密类型和操作。以太坊工具链的其余部分（Remix、Hardhat 等）仍然可以使用，因为底层的修改主要在客户端/节点级别。这降低了入门门槛：开发者无需成为密码学专家就能编写机密智能合约。例如，两个数的简单加法可以写成 euint32 c = a + b;，FHEVM 会在幕后处理与加密相关的细节。这些合约甚至可以与普通合约互操作——例如，一个加密合约如果需要，可以向一个标准合约输出一个解密结果，从而允许在一个生态系统中混合使用私有和公共部分。

当前的 FHE-VM 项目： 有几个项目正在开拓这一领域。Zama（一家总部位于巴黎的 FHE 初创公司）开发了核心的 FHEVM 概念和库（TFHE-rs 和一个 fhevm-solidity 库）。他们不打算推出自己的链，而是为他人提供基础设施。Inco 是一个 L1 区块链（基于 Cosmos SDK 和 Evmos 构建），它集成了 Zama 的 FHEVM，创建了一个模块化的机密链。他们的测试网（名为 Gentry 和 Paillier）展示了加密的 ERC-20 转账和其他私有 DeFi 原语。Fhenix 是一个以太坊二层乐观 Rollup，使用 FHE 实现隐私。它选择了乐观（欺诈证明）方法而不是 ZK-Rollup，因为对每个区块同时进行 FHE 和 ZK 的成本非常高。Fhenix 使用相同的 TFHE-rs 库（进行了一些修改），并引入了一个门限服务网络来以去中心化的方式处理解密。还有一些独立的团队，如 Fhenix (现已更名) 和一些初创公司正在探索 MPC + FHE 的混合方案。此外，Cypher (由 Z1 Labs 开发) 正在构建一个专注于 AI 和隐私的三层网络，使用一个具有秘密存储和联邦学习支持等功能的 fhEVM。这个生态系统虽然 nascent 但发展迅速，并得到了大量资金的支持——例如，Zama 在 2025 年前筹集了超过 1.3 亿美元，成为“独角兽”，以推进 FHE 技术。

总之，FHE-VM 通过在链上对加密数据执行所有逻辑，实现了保护隐私的智能合约。这种范式确保了最大的机密性——在交易或状态中永远不会暴露任何敏感信息——同时利用现有的区块链共识来保证完整性。其代价是增加了验证者的计算负担以及密钥管理和证明集成的复杂性。接下来，我们将探讨一种替代范式，它将计算完全卸载到链下，仅使用链进行验证：零知识协处理器。

零知识协处理器 (ZK 协处理器)​

ZK 协处理器是一种新的区块链架构模式，其中昂贵的计算在链下执行，其正确性的简洁零知识证明则在链上进行验证。这使得智能合约能够利用比链上执行所允许的更大的计算能力和数据，而无需牺牲无需信任性。术语协处理器是类比于硬件协处理器（如数学协处理器或 GPU），它们为 CPU 处理专门任务。在这里，区块链的“CPU”（如 EVM 等原生虚拟机）将某些任务委托给一个零知识证明系统，该系统充当密码学协处理器。ZK 协处理器返回一个结果和一个证明该结果计算正确的证明，链上合约可以验证并使用该结果。

架构与工作流程​

在典型设置中，dApp 开发者识别出其应用逻辑中对于链上执行来说过于昂贵或复杂的部分（例如，对历史数据的大量计算、重型算法、机器学习模型推理等）。他们将这些部分实现为一个链下程序（使用高级语言或电路 DSL），该程序可以为其执行生成零知识证明。链上组件是一个验证者智能合约，它检查证明并使结果可用于系统的其余部分。流程可以总结如下：

1. 请求 – 链上合约触发一个请求，要求在链下完成某个计算。这可以由用户交易发起，也可以由一个合约调用 ZK 协处理器的接口。例如，一个 DeFi 合约可能会调用 “proveInterestRate(currentState)”，或者一个用户调用 “queryHistoricalData(query)”。
2. 链下执行与证明 – 一个链下服务（可能是一个去中心化的证明者网络或一个受信任的服务，取决于设计）接收请求。它收集所有需要的数据（链上状态、链下输入等），并在一个特殊的 ZK 虚拟机 (ZKVM) 或电路中执行计算。在执行过程中，会生成一个证明轨迹。最后，该服务生成一个简洁证明（例如，SNARK 或 STARK），证明*“在输入 X 上计算函数 F 得到输出 Y”*，并可选地证明数据完整性（下文将详细介绍）。
3. 链上验证 – 证明和结果被返回到区块链（通常通过回调函数）。验证者合约使用高效的密码学验证（配对检查等）来检查证明的有效性。如果有效，合约现在可以信任输出 Y 是正确的。结果可以存储在状态中，作为事件发出，或输入到进一步的合约逻辑中。如果证明无效或在某个时间内未提供，请求可以被视为失败（并可能触发一些回退或超时逻辑）。

图 1：ZK 协处理器的架构（以 RISC Zero Bonsai 为例）。在链下，一个程序在 ZKVM 上运行，输入来自智能合约调用。执行证明通过一个中继合约返回到链上，该合约用验证后的结果调用一个回调函数。

关键是，无论链下计算有多复杂，链上验证的 Gas 成本是恒定的（或增长非常缓慢）。验证一个简洁证明可能花费几十万 Gas（以太坊区块的一小部分），但该证明可能代表了在链下完成的数百万个计算步骤。正如一位开发者所说，“想证明一个数字签名？大约 15 美元。想证明一百万个签名？也是大约 15 美元。”。这种可扩展性是一个巨大的优势：dApp 可以提供复杂的功能（大数据分析、复杂的金融模型等），而不会堵塞区块链。

ZK 协处理器系统的主要组件是：

• 证明生成环境： 这可以是一个通用的 ZKVM（能够运行任意程序）或为特定计算量身定制的自定义电路。方法各不相同：
  • 一些项目为每个支持的查询或函数使用手工制作的电路（最大化该函数的效率）。
  • 其他项目提供一个领域特定语言 (DSL) 或嵌入式 DSL，开发者用它来编写他们的链下逻辑，然后编译成电路（在易用性和性能之间取得平衡）。
  • 最灵活的方法是 zkVM：一个虚拟机（通常基于 RISC 架构），程序可以用标准语言（Rust、C 等）编写并自动证明。这牺牲了性能（在电路中模拟 CPU 会增加开销），但换来了最佳的开发者体验。
• 数据访问与完整性： 一个独特的挑战是为链下计算提供正确的数据，特别是如果这些数据位于区块链上（过去的区块、合约状态等）。一个简单的解决方案是让证明者从一个存档节点读取并信任它——但这引入了信任假设。相反，ZK 协处理器通常通过链接到 Merkle 证明或状态承诺来证明所使用的任何链上数据都是真实的。例如，查询程序可能会接收一个区块号和一个存储槽或交易的 Merkle 证明，电路将根据已知的区块头哈希验证该证明。存在三种模式：
  1. 内联数据： 将所需数据放在链上（作为验证者的输入），以便直接检查。这对于大数据来说成本非常高，并且破坏了整个目的。
  2. 信任预言机： 让一个预言机服务将数据提供给证明并为其担保。这更简单，但重新引入了对第三方的信任。
  3. 通过 ZK 证明数据包含： 在零知识电路本身中包含数据在链历史中的包含证明。这利用了每个以太坊区块头都提交了整个先前状态（通过状态根）和交易历史的事实。通过在电路内验证数据的 Merkle Patricia 证明，输出证明向合约保证*“此计算使用了来自区块 N 的真实区块链数据”，无需额外的信任。 第三种方法是最无需信任的，并被像 Axiom 和 Xpansion 这样的高级 ZK 协处理器使用（它确实增加了证明成本，但为了安全性是可取的）。例如，Axiom 的系统在其电路中模拟了以太坊的区块结构、状态树和交易树，因此它可以证明诸如“账户 X 在区块 N 时的余额为 Y”或“一个具有某些属性的交易发生在区块 N”*之类的陈述。它利用了这样一个事实：给定一个最近的可信区块哈希，可以递归地证明历史数据的包含，而无需信任任何外部方。
• 验证者合约： 这个链上合约包含验证密钥和接受或拒绝证明的逻辑。对于像 Groth16 或 PLONK 这样的 SNARKs，验证者可能会进行一些椭圆曲线配对；对于 STARKs，它可能会进行一些哈希计算。聚合和递归等性能优化可以最小化链上负载。例如，RISC Zero 的 Bonsai 使用一个 STARK-to-SNARK 包装器：它在链下运行一个基于 STARK 的 VM 以提高速度，然后生成一个小的 SNARK 证明来证明 STARK 的有效性。这将证明大小从几百千字节缩小到几百字节，使得链上验证变得可行且便宜。然后，Solidity 验证者只需检查 SNARK（这是一个常数时间操作）。

在部署方面，ZK 协处理器可以作为类似二层的网络或纯粹的链下服务运行。一些，如 Axiom，最初是作为以太坊的专门服务（得到 Paradigm 的支持），开发者向 Axiom 的证明者网络提交查询，并在链上获得证明。Axiom 的口号是为以太坊合约提供*“对所有链上数据和对其的任意表达性计算的无需信任的访问”*。它实际上充当了一个查询预言机，其中答案由 ZKPs 而不是信任来验证。其他的，如 RISC Zero 的 Bonsai，提供了一个更开放的平台：任何开发者都可以上传一个程序（编译成与 RISC-V 兼容的 ZKVM），并通过一个中继合约使用 Bonsai 的证明服务。如图 1 所示的中继模式涉及一个合约，该合约协调请求和响应：dApp 合约调用中继来请求一个证明，链下服务监听此请求（例如，通过事件或直接调用），计算证明，然后中继在 dApp 合约上调用一个回调函数，并附带结果和证明。这种异步模型是必要的，因为证明可能需要几秒到几分钟，具体取决于复杂性。它引入了延迟（以及证明者会响应的活性假设），而 FHE-VM 计算则在块内同步发生。设计应用程序以处理这种异步工作流（可能类似于预言机响应）是使用 ZK 协处理器的一部分。

著名的 ZK 协处理器项目​

• Axiom: Axiom 是一个为以太坊量身定制的 ZK 协处理器，最初专注于证明历史链上数据查询。它使用 Halo2 证明框架（一种 Plonk-ish SNARK）来创建包含以太坊密码学结构的证明。在 Axiom 的系统中，开发者可以查询诸如*“合约 X 在区块 N 的状态是什么？”或对某个范围内的所有交易进行计算。在底层，Axiom 的电路必须实现以太坊的状态/树逻辑，甚至在电路内部执行椭圆曲线操作和 SNARK 验证以支持递归。Trail of Bits 在一次审计中指出了 Axiom 的 Halo2 电路模拟整个区块和状态的复杂性。审计后，Axiom 将其技术推广到一个 OpenVM，允许使用相同的基于 Halo2 的基础设施来证明任意 Rust 代码。（这反映了从领域特定电路转向更通用的 ZKVM 方法的趋势。）Axiom 团队展示了以太坊原生无法完成的 ZK 查询，实现了对任何历史数据的无状态访问*和密码学完整性。他们还强调了安全性，捕获并修复了约束不足的电路错误并确保了可靠性。虽然 Axiom 的初始产品在其转型期间被关闭，但他们的方法仍然是 ZK 协处理器领域的一个里程碑。
• RISC Zero Bonsai: RISC Zero 是一个基于 RISC-V 架构的 ZKVM。他们的 zkVM 可以执行任意程序（用 Rust、C++ 和其他编译到 RISC-V 的语言编写）并生成一个 STARK 执行证明。Bonsai 是 RISC Zero 的云服务，按需提供这种证明，充当智能合约的协处理器。要使用它，开发者编写一个程序（例如，一个执行复杂数学或验证链下 API 响应的函数），将其上传到 Bonsai 服务，并部署一个相应的验证者合约。当合约需要该计算时，它会调用 Bonsai 中继，触发证明生成并通过回调返回结果。一个展示的应用示例是链下治理计算：RISC Zero 展示了一个 DAO 使用 Bonsai 在链下统计投票并计算复杂的投票指标，然后发布一个证明，以便链上治理合约能够以最小的 Gas 成本信任结果。RISC Zero 的技术强调开发者可以使用熟悉的编程范式——例如，编写一个 Rust 函数来计算某些东西——而电路创建的繁重工作由 zkVM 处理。然而，证明可能很大，因此如前所述，他们为链上验证实现了一个 SNARK 压缩。2023 年 8 月，他们成功地在以太坊的 Sepolia 测试网上验证了 RISC Zero 证明，每个证明的成本约为 30 万 Gas。这为以太坊 dApp 今天使用 Bonsai 作为扩展和隐私解决方案打开了大门。（Bonsai 仍处于 alpha 阶段，尚未准备好生产，并使用一个没有仪式的临时 SNARK 设置。）
• 其他: 还有许多其他参与者和研究计划。Expansion/Xpansion（如一篇博客中所述）使用一种嵌入式 DSL 方法，开发者可以用一种专门的语言编写对链上数据的查询，它在内部处理证明生成。StarkWare 的 Cairo 和 Polygon 的 zkEVM 是更通用的 ZK-Rollup VM，但它们的技术可以通过在 L1 合约内验证证明来重新用于类似协处理器的用途。我们还看到 ZKML (ZK 机器学习) 领域的项目，它们实际上充当协处理器，在链上验证 ML 模型推理或训练结果。例如，一个 zkML 设置可以证明*“在私有输入上进行的神经网络推理产生了分类 X”*，而无需透露输入或在链上进行计算。这些是协处理器概念应用于 AI 的特例。

信任假设： ZK 协处理器依赖于密码学证明的可靠性。如果证明系统是安全的（并且任何可信设置都是诚实完成的），那么一个被接受的证明就保证了计算是正确的。不需要对证明者有额外的信任——即使是恶意的证明者也无法让验证者相信一个错误的陈述。然而，存在一个活性假设：必须有人实际执行链下计算并生成证明。在实践中，这可能是一个去中心化的网络（有激励或费用来完成工作）或一个单一的服务运营商。如果没有人提供证明，链上请求可能会保持未解决状态。另一个微妙的信任方面是对于不在区块链上的链下输入的数据可用性。如果计算依赖于某些私有或外部数据，验证者无法知道该数据是否被诚实提供，除非使用额外的措施（如数据承诺或预言机签名）。但对于纯粹的链上数据计算，所描述的机制确保了与链本身等效的无需信任性（Axiom 认为他们的证明为历史查询提供了“与以太坊在密码学上等效的安全性”）。

隐私： 零知识证明本身也支持隐私——证明者可以在证明关于它们陈述的同时保持输入隐藏。在协处理器上下文中，这意味着一个证明可以允许合约使用从私有数据派生的结果。例如，一个证明可能显示*“用户的信用评分 > 700，因此批准贷款”，而无需透露实际的信用评分或原始数据。Axiom 的用例更多是关于公开已知的数据（区块链历史），所以隐私不是重点。但 RISC Zero 的 zkVM 可以用来证明关于用户提供的秘密数据的断言：数据保留在链下，只有需要的结果上链。值得注意的是，与 FHE 不同，ZK 证明通常不提供状态的持续机密性——它是一次性的证明。如果一个工作流需要跨交易维护一个秘密状态，可以通过让合约存储一个状态的承诺*，并且每个证明都显示从旧承诺到新承诺的有效状态转换，同时隐藏秘密来构建它。这基本上是用于私有交易的 zk-rollups（如 Aztec 或 Zcash）的工作方式。因此，ZK 协处理器可以促进完全私有的状态机，但实现并非易事；它们通常用于一次性计算，其中输入或输出（或两者）可以根据需要保持私有。

开发者体验： 使用 ZK 协处理器通常需要学习新工具。编写自定义电路（上述选项 (1)）相当复杂，通常只用于狭窄的目的。像 DSLs 或 zkVMs 这样的更高级别的选项使生活更容易，但仍然增加了开销：开发者必须编写和部署链下代码并管理交互。与 FHE-VM 相比，在 FHE-VM 中，加密主要在幕后处理，开发者编写正常的智能合约代码，而在这里，开发者需要划分他们的逻辑，并可能需要用不同的语言（Rust 等）为链下部分编写代码。然而，像 Noir、Leo、Circom DSLs 或 RISC Zero 的方法这样的举措正在迅速提高可访问性。例如，RISC Zero 提供了模板和 Foundry 集成，这样开发者可以在本地模拟他们的链下代码（为了正确性），然后通过 Bonsai 回调无缝地将其挂钩到 Solidity 测试中。随着时间的推移，我们可以期待开发框架能够抽象出一段逻辑是通过 ZK 证明还是在链上执行——编译器或工具可能会根据成本来决定。

FHE-VM vs ZK 协处理器：比较​

FHE-VM 和 ZK 协处理器都实现了一种*“在私有数据上计算并进行链上保证”*的形式，但它们在架构上根本不同。下表总结了主要区别：

这两种方法都在积极改进中，我们甚至看到了融合：如前所述，ZKPs 被用于 FHE-VM 内部进行某些检查，反之，一些研究人员建议使用 FHE 来保持 ZK 中证明者输入的私密性（这样云证明者就看不到你的秘密数据）。可以想象未来的系统会将它们结合起来——例如，在链下执行 FHE，然后向链证明其正确性，或者在链上使用 FHE，但向轻客户端 ZK 证明加密操作是正确完成的。每种技术都有其优势：FHE-VM 提供持续的隐私和实时交互，但计算成本高昂；而 ZK 协处理器提供可扩展性和灵活性，但有延迟和复杂性的代价。

用例与影响​

可编程隐私的出现为各行各业开启了大量新的区块链应用。下面我们探讨 FHE-VM 和 ZK 协处理器（或混合方案）如何通过实现保护隐私的智能合约和安全的数据经济来赋能各个领域。

机密 DeFi 与金融​

在去中心化金融中，隐私可以减轻抢先交易、保护交易策略，并在需要时满足合规要求，而无需牺牲透明度。机密 DeFi 可以让用户与协议互动，而无需向全世界透露他们的头寸。

• 私密交易与隐藏余额： 使用 FHE，可以在区块链 L1 上实现机密代币转账（加密的 ERC-20 余额和交易）或屏蔽池。没有观察者能看到你持有或转移了多少代币，从而消除了基于持仓的定向攻击风险。ZK 证明可以确保余额保持同步且没有双重花费（类似于 Zcash，但在智能合约平台上）。一个例子是机密 AMM (自动做市商)，其中池子的储备和交易在链上是加密的。套利者或抢先交易者无法利用该池，因为他们在交易结算前无法观察到价格滑点，从而减少了 MEV。只有在一定延迟后或通过访问控制机制，某些数据才可能被披露以供审计。
• 抗 MEV 的拍卖与交易： 矿工和机器人利用交易透明度来抢先交易。通过加密，你可以拥有一个加密的内存池或批量拍卖，其中订单以密文形式提交。只有在拍卖清算后，交易才会解密。这个概念，有时被称为公平订单流，可以通过门限解密（多个验证者集体解密批次）或通过 ZK 证明拍卖结果而无需透露单个出价来实现。例如，一个 ZK 协处理器可以在链下处理一批密封的出价，计算拍卖清算价格，并只输出该价格和获胜者以及证明。这保护了失败出价的公平性和隐私。
• 机密借贷与衍生品： 在 DeFi 借贷中，用户可能不希望透露他们的贷款或抵押品规模（这会影响市场情绪或招致利用）。FHE-VM 可以维护一个加密的贷款账本，其中每笔贷款的细节都是加密的。智能合约逻辑仍然可以通过操作加密的健康因子来强制执行清算条件等规则。如果一笔贷款的抵押率低于阈值，合约（在 ZK 证明的帮助下）可以标记其进行清算，而无需暴露确切的值——它可能只在明文中产生一个“是/否”标志。同样，秘密的衍生品或期权头寸可以在链上管理，只披露聚合的风险指标。这可以防止复制交易并保护专有策略，从而鼓励更多机构参与。
• 合规隐私： 并非所有金融环境都希望完全匿名；有时为了监管需要选择性披露。有了这些工具，我们可以实现受监管的隐私：例如，交易对公众是私密的，但受监管的交易所可以解密或接收关于某些属性的证明。可以通过 ZK 证明*“这笔交易不涉及黑名单地址，且双方都经过 KYC 验证”*，而无需向链透露身份。这种平衡可以满足反洗钱 (AML) 规则，同时对其他人保密用户的身份和头寸。FHE 可以允许一个链上合规官合约扫描加密交易以寻找风险信号（例如，解密密钥仅在法院命令下才能访问）。

数字身份与个人数据​

身份系统将从链上隐私技术中获益匪浅。目前，由于隐私法和用户的不情愿，将个人凭证或属性放在公共账本上是不切实际的。有了 FHE 和 ZK，自主身份可以以保护隐私的方式实现：

• 零知识凭证： 使用 ZK 证明（在一些身份项目中已经很常见），用户可以证明诸如*“我已年满 18 岁”、“我有有效的驾驶执照”或“我的收入超过 5 万美元（用于信用评分）”*之类的陈述，而无需透露任何其他个人信息。ZK 协处理器可以通过在链下处理更复杂的检查来增强这一点，例如，通过以类似 Axiom 的方式查询私有信用数据库来证明用户的信用评分高于某个阈值，只向区块链输出一个“是/否”的结果。
• DeFi 上的机密 KYC： 想象一个 DeFi 协议，根据法律必须确保用户经过 KYC。使用 FHE-VM，用户的凭证可以加密存储在链上（或通过 DID 引用），智能合约可以执行 FHE 计算来验证 KYC 信息是否符合要求。例如，一个合约可以同态地检查加密用户配置文件中的姓名和社保号是否与受制裁用户列表（也加密）匹配，或者用户的国家是否不受限制。合约只会得到一个加密的“通过/失败”，可以由网络验证者门限解密为一个布尔标志。只有用户是否被允许的事实被揭示，保护了个人身份信息 (PII) 的机密性，并符合 GDPR 原则。这种选择性披露确保了合规性和隐私。
• 基于属性的访问与选择性披露： 用户可以持有一堆可验证的凭证（年龄、公民身份、技能等）作为加密属性。他们可以授权某些 dApp 对其进行计算，而无需披露所有内容。例如，一个去中心化的招聘 DApp 可以通过对加密的简历进行搜索（使用 FHE）来筛选候选人——例如，计算工作年限、检查是否有某个认证——只有在找到匹配项时，才在链下联系候选人。候选人的私人细节保持加密，除非他们选择透露。ZK 证明还可以让用户选择性地证明他们拥有属性的组合（例如，超过 21 岁且在某个邮政编码内），而无需透露实际值。
• 多方身份验证： 有时用户的身份需要由多方审查（例如，公司 A 的背景调查，公司 B 的信用检查）。使用同态和 ZK 工具，每个验证者可以贡献一个加密的分数或批准，智能合约可以将这些聚合为一个最终决定，而无需暴露单个贡献。例如，三个机构提供加密的“通过/失败”位，如果三个都是通过，合约就输出一个批准——用户或依赖方只看到最终结果，而不是哪个特定机构可能让他们失败，从而保护了用户在每个机构的记录隐私。这可以减少与例如一次失败的检查揭示特定问题相关的偏见和污名。

医疗保健与敏感数据共享​

医疗数据高度敏感且受监管，但将来自多个来源的数据结合起来可以释放巨大价值（用于研究、保险、个性化医疗）。如果隐私问题得到解决，区块链可以为数据交换提供一个信任层。机密智能合约可以催生新的健康数据生态系统：

• 安全的医疗数据交换： 患者可以将其医疗记录的引用以加密形式存储在链上。一个支持 FHE 的合约可以允许研究机构对一组患者数据进行分析，而无需解密。例如，一个合约可以计算一种药物在加密的患者结果中的平均疗效。只有聚合的统计结果被解密出来（并且可能只有在包含最少数量的患者时，以防止重新识别）。患者可以通过贡献他们的加密数据进行研究而获得微支付，因为他们知道自己的隐私得到了保护，因为即使是区块链和研究人员也只能看到密文或聚合证明。这促进了一个尊重隐私的医疗保健数据市场。
• 保护隐私的保险理赔： 健康保险理赔处理可以通过智能合约自动化，这些合约可以在不向保险公司暴露数据的情况下验证医疗数据的条件。一份理赔可以包括一个加密的诊断代码和加密的治疗费用；合约使用 FHE 检查保单规则（例如，覆盖范围、免赔额）对该加密数据。它可以输出一个批准和支付金额，而无需向保险公司的区块链透露实际诊断（只有患者和医生有密钥）。ZK 证明可以用来证明患者的数据来自认证医院的记录（使用类似 Axiom 的东西来验证医院的签名或记录包含），而无需透露记录本身。这确保了患者隐私，同时防止了欺诈。
• 基因组与个人数据计算： 基因组数据极其敏感（它实际上是一个人的 DNA 蓝图）。然而，分析基因组可以提供有价值的健康见解。公司可以使用 FHE-VM 对用户上传的加密基因组进行计算。例如，一个智能合约可以在加密的基因组数据和加密的环境数据（可能来自可穿戴设备）上运行一个基因-环境风险模型，输出一个只有用户才能解密的风险评分。逻辑（可能是一个多基因风险评分算法）被编码在合约中并同态运行，因此基因组数据永远不会以明文形式出现。这样，用户可以在不向公司提供原始 DNA 数据的情况下获得见解——从而减轻了隐私和数据所有权方面的担忧。
• 流行病学与公共卫生： 在大流行等情况下，共享数据对于模拟疾病传播至关重要，但隐私法可能会阻碍数据共享。ZK 协处理器可以允许公共卫生当局通过证明向医院网络的数据提交诸如*“X 地区在过去 24 小时内有多少人检测呈阳性？”*之类的查询。每家医院将患者测试记录保留在链下，但可以向当局的合约证明阳性计数，而无需透露是谁。同样，接触者追踪可以通过匹配加密的位置轨迹来完成：合约可以计算患者加密位置历史的交集以识别热点，只输出热点位置（以及可能只有卫生部门才能解密的受影响 ID 的加密列表）。个人的原始位置轨迹保持私密。

数据市场与协作​

在不泄露数据的情况下对其进行计算的能力为数据共享开辟了新的商业模式。实体可以在知道其专有数据不会被暴露的情况下进行计算协作：

• 安全的数据市场： 卖家可以在区块链市场上以加密形式提供数据。买家可以付费通过智能合约在加密数据集上运行特定的分析或机器学习模型，获得训练好的模型或聚合结果。卖家的原始数据永远不会向买家或公众透露——买家可能只收到一个模型（其权重中仍可能泄露一些信息，但差分隐私或控制输出粒度等技术可以减轻这种情况）。ZK 证明可以向买家保证计算是在承诺的数据集上正确完成的（例如，卖家不能通过在虚拟数据上运行模型来作弊，因为证明将其与承诺的加密数据集联系起来）。这种情况鼓励了数据共享：例如，一家公司可以通过允许批准的算法在加密的用户行为数据上运行来将其货币化，而无需交出数据本身。
• 联邦学习与去中心化 AI： 在去中心化机器学习中，多方（例如，不同的公司或设备）希望在不相互共享数据的情况下共同训练一个模型。FHE-VM 在这里表现出色：它们可以实现联邦学习，其中各方的模型更新由合约进行同态聚合。因为更新是加密的，所以没有参与者能了解其他人的贡献。合约甚至可以在链上加密地执行部分训练循环（如梯度下降步骤），产生一个只有授权方才能解密的更新模型。ZK 可以通过证明各方的更新是按照训练算法计算的来补充这一点（防止恶意参与者毒害模型）。这意味着一个全局模型可以在链上进行完全可审计的训练，而每个贡献者的训练数据都保持私密。用例包括跨银行联合训练欺诈检测模型，或在不集中原始数据的情况下使用来自许多用户的数据改进 AI 助手。
• 跨组织分析： 考虑两家公司希望为合作活动找到他们的客户交集，而不想向对方暴露他们完整的客户列表。他们可以各自加密他们的客户 ID 列表并上传一个承诺。一个支持 FHE 的合约可以在加密集上计算交集（使用像通过 FHE 的私有集交集等技术）。结果可能是一个加密的共同客户 ID 列表，只有相互信任的第三方（或客户自己，通过某种机制）才能解密。或者，一种 ZK 方法：一方以零知识向另一方证明*“我们有 N 个共同客户，这里是这些 ID 的加密”*，并附带一个证明，证明该加密确实对应于共同条目。这样，他们就可以对这 N 个客户进行营销活动，而无需交换完整的明文列表。类似的情景：在不透露单个供应商细节的情况下计算跨竞争对手的供应链指标，或银行在不共享完整客户数据的情况下整理信用信息。
• 区块链上的安全多方计算 (MPC)： FHE 和 ZK 基本上将 MPC 概念带到了链上。跨多个组织的复杂业务逻辑可以编码在智能合约中，使得每个组织的输入都是秘密共享或加密的。合约（作为 MPC 协调者）产生每个人都可以信任的输出，如利润分配、成本计算或联合风险评估。例如，假设几家能源公司希望结算一个电力交易市场。他们可以将加密的出价和报价输入到一个智能合约拍卖中；合约在加密的出价上计算清算价格和分配，并将每个公司的分配和成本只输出给该公司（通过加密到他们的公钥）。没有公司能看到其他公司的出价，保护了竞争信息，但拍卖结果是公平且可验证的。这种区块链透明度与 MPC 隐私的结合可以彻底改变目前依赖可信第三方的联盟和企业联盟。

去中心化机器学习 (ZKML 和 FHE-ML)​

以可验证和私密的方式将机器学习引入区块链是一个新兴的前沿领域：

• 可验证的 ML 推理： 使用 ZK 证明，可以证明*“机器学习模型 f，在给定输入 x 时，产生输出 y”，而无需透露 x（如果它是私有数据）或 f 的内部工作原理（如果模型权重是专有的）。这对于区块链上的 AI 服务至关重要——例如，一个提供预测或分类的去中心化 AI 预言机。ZK 协处理器可以在链下运行模型（因为模型可能很大且评估成本高昂）并发布结果的证明。例如，一个预言机可以证明陈述“提供的卫星图像显示至少 50% 的树木覆盖率”*以支持碳信用合约，而无需透露卫星图像，甚至可能无需透露模型。这被称为 ZKML，并且有项目正在优化适合电路的神经网络。它确保了智能合约中使用的 AI 输出的完整性（没有作弊或任意输出），并可以保护输入数据和模型参数的机密性。
• 具有隐私和可审计性的训练： 训练一个 ML 模型计算量更大，但如果可以实现，它将允许基于区块链的模型市场。多个数据提供者可以在 FHE 下为训练模型做出贡献，以便训练算法在加密数据上运行。结果可能是一个只有买家才能解密的加密模型。在整个训练过程中，可以定期提供 ZK 证明，以证明训练遵循了协议（例如，防止恶意训练者插入后门）。虽然完全在链上进行 ML 训练由于成本原因还很遥远，但一种混合方法可以使用链下计算和 ZK 证明来处理关键部分。可以想象一个去中心化的类似 Kaggle 的竞赛，参与者在私有数据集上训练模型，并提交模型在加密测试数据上准确性的 ZK 证明来确定获胜者——所有这些都无需透露数据集或测试数据。
• 个性化 AI 与数据所有权： 有了这些技术，用户可以保留其个人数据的所有权，同时仍然受益于 AI。例如，用户的移动设备可以使用 FHE 加密其使用数据，并将其发送到一个分析合约，该合约仅为他们计算一个个性化的 AI 模型（如推荐模型）。该模型是加密的，只有用户的设备才能解密和在本地使用。平台（也许是社交网络）永远看不到原始数据或模型，但用户获得了 AI 的好处。如果平台想要聚合的见解，它可以向合约请求某些聚合模式的 ZK 证明，而无需访问个人数据。

其他领域​

• 游戏： 链上游戏通常难以隐藏秘密信息（例如，隐藏的牌手、策略游戏中的战争迷雾）。FHE 可以实现隐藏状态游戏，其中游戏逻辑在加密状态上运行。例如，一个扑克游戏合约可以洗牌并发放加密的牌；玩家获得自己牌的解密，但合约和其他人只看到密文。下注逻辑可以使用 ZK 证明来确保玩家没有在某个行动上虚张声势（或者在最后以可验证的公平方式揭示获胜的手牌）。同样，用于 NFT 铸造或游戏结果的随机种子可以生成并证明其公平性，而无需暴露种子（防止操纵）。这可以极大地增强区块链游戏，使其能够支持与传统游戏相同的动态。
• 投票与治理： DAO 可以使用隐私技术进行链上秘密投票，消除买票和压力。FHE-VM 可以统计以加密形式投出的选票，只有最终总数被解密。ZK 证明可以确保每张选票都是有效的（来自合格的选民，且未投过两次票），而无需透露谁投了什么票。这提供了可验证性（每个人都可以验证证明和计票），同时保持个人投票的秘密——这对于无偏见的治理至关重要。
• 安全供应链与物联网： 在供应链中，合作伙伴可能希望共享某些属性的证明（来源、质量指标），而不想向竞争对手暴露全部细节。例如，食品运输上的物联网传感器可以持续向区块链发送加密的温度数据。合约可以使用 FHE 检查在整个运输过程中温度是否保持在安全范围内。如果超过了阈值，它可以触发警报或罚款，但不必公开整个温度日志——也许只公开一个证明或一个聚合值，如*“第 90 百分位的温度”*。这在尊重过程数据机密性的同时，建立了对供应链自动化的信任。

这些用例中的每一个都利用了核心能力：在不泄露数据的情况下对数据进行计算或验证。这种能力可以从根本上改变我们在去中心化系统中处理敏感信息的方式。它减少了在处理私有数据的领域中限制区块链采用的透明度与隐私之间的权衡。

结论​

区块链技术正在进入一个可编程隐私的新时代，数据机密性与智能合约功能齐头并进。FHE-VM 和 ZK 协处理器的范式，虽然在技术上截然不同，但都致力于通过将我们能计算什么与我们必须揭示什么解耦来扩展区块链应用范围。

全同态加密虚拟机将计算保持在链上并加密，保留了去中心化和可组合性，但要求在效率上取得进步。零知识协处理器将繁重的工作转移到链下，在密码学保证下实现了几乎无限的计算，并已在扩展和增强以太坊方面证明了其价值。它们（及其混合方案）之间的选择将取决于用例：如果需要与私有状态进行实时交互，FHE 方法可能更合适；如果需要极其复杂的计算或与现有代码集成，ZK 协处理器可能是更好的选择。在许多情况下，它们是互补的——事实上，我们看到 ZK 证明增强了 FHE 的完整性，而 FHE 可能通过为证明者处理私有数据来帮助 ZK。

对于开发者来说，这些技术将引入新的设计模式。我们将把加密变量和证明验证视为 dApp 架构的一等元素来思考。工具正在迅速发展：高级语言和 SDK 正在抽象化密码学细节（例如，Zama 的库使 FHE 类型像原生类型一样易于使用，或者 RISC Zero 的证明请求模板）。几年后，编写一个机密智能合约可能会感觉几乎和编写一个普通合约一样直接，只是默认“内置”了隐私。

对数据经济的影响是深远的。当个人和企业能够控制其数据的可见性时，他们将更愿意将数据或逻辑放在链上。这可以解锁以前因隐私问题而无法实现的跨组织协作、新金融产品和 AI 模型。监管机构也可能开始接受这些技术，因为它们允许通过密码学手段进行合规检查和审计（例如，在链上证明税款已正确支付，而无需暴露所有交易）。

我们仍处于早期阶段——目前的 FHE-VM 原型有性能限制，而 ZK 证明虽然比以前快得多，但对于极其复杂的任务仍然可能成为瓶颈。但持续的研究和工程努力（包括专用硬件，如 Optalysys 等公司推动的光学 FHE 加速所证明的）正在迅速消除这些障碍。涌入该领域的资金（例如，Zama 的独角兽地位，Paradigm 对 Axiom 的投资）突显了一种强烈的信念，即隐私功能将像透明度对 Web1/2 一样对 Web3 至关重要。

总之，通过 FHE-VM 和 ZK 协处理器实现的可编程隐私预示着一类新的 dApp，它们是无需信任、去中心化和机密的。从不透露任何细节的 DeFi 交易，到保护患者数据的健康研究，再到在世界各地训练而无需暴露原始数据的机器学习模型——可能性是巨大的。随着这些技术的成熟，区块链平台将不再强迫在效用和隐私之间做出权衡，从而在需要机密性的行业中实现更广泛的采用。Web3 的未来是，*用户和组织可以自信地在链上处理和计算敏感数据，因为他们知道区块链将在保护他们秘密的同时验证完整性*。

来源： 本报告中的信息来自该领域领先项目的技术文档和最新研究博客，包括 Cypher 和 Zama 的 FHEVM 文档、Trail of Bits 对 Axiom 电路的详细分析、RISC Zero 的开发者指南和博客文章，以及强调机密区块链技术用例的行业文章。这些来源及更多内容已在全文中引用，以提供进一步的阅读和对所描述的架构和应用的证据。