7 записей с тегом "Криптография"

Конфиденциальность становится общественной инфраструктурой. В 2025 году разработчикам нужны инструменты, которые сделают шифрование таким же простым, как хранение данных. Seal от Mysten Labs предоставляет именно это — децентрализованное управление секретами с контролем доступа в блокчейне. Это руководство научит вас создавать безопасные Web3-приложения, используя шифрование на основе идентификаторов, пороговую безопасность и программируемые политики доступа.

Введение: Почему Seal важен для Web3​

Традиционные облачные приложения полагаются на централизованные системы управления ключами, где один провайдер контролирует доступ к зашифрованным данным. Хотя это удобно, это создает опасные единые точки отказа. Если провайдер скомпрометирован, отключается или решает ограничить доступ, ваши данные становятся недоступными или уязвимыми.

Seal полностью меняет эту парадигму. Разработанный Mysten Labs для блокчейна Sui, Seal — это децентрализованный сервис управления секретами (DSM), который обеспечивает:

• Шифрование на основе идентификаторов, при котором контент защищается до того, как покинет вашу среду
• Пороговое шифрование, которое распределяет доступ к ключам между несколькими независимыми узлами
• Контроль доступа в блокчейне с временными блокировками, токен-гейтингом и настраиваемой логикой авторизации
• Независимый от хранилища дизайн, который работает с Walrus, IPFS или любым другим решением для хранения

Независимо от того, создаете ли вы безопасные приложения для обмена сообщениями, платформы с ограниченным доступом к контенту или переводы активов с временной блокировкой, Seal предоставляет необходимые криптографические примитивы и инфраструктуру контроля доступа.

Начало работы​

Предварительные требования​

Прежде чем приступить к работе, убедитесь, что у вас есть:

• Установленный Node.js 18+
• Базовое знакомство с TypeScript/JavaScript
• Кошелек Sui для тестирования (например, Sui Wallet)
• Понимание концепций блокчейна

Установка​

Установите SDK Seal через npm:

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-из-n пороговые схемы. Вы можете настроить 3 из 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() {
  // Initialize Sui client for testnet
  const suiClient = new SuiClient({
    url: "https://fullnode.testnet.sui.io",
  });

  // Configure Seal client with testnet key servers
  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 threshold
    network: "testnet",
  });

  return { sealClient, suiClient };
}

Шаг 2: Простое шифрование/дешифрование​

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

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

  // Data to encrypt
  const sensitiveData = "This is my secret message!";
  const recipientAddress =
    "0x742d35cc6d4c0c08c0f9bf3c9b2b6c64b3b4f5c6d7e8f9a0b1c2d3e4f5a6b7c8";

  try {
    // Encrypt data for a specific Sui address
    const encryptedData = await sealClient.encrypt({
      data: Buffer.from(sensitiveData, "utf-8"),
      recipientId: recipientAddress,
      // Optional: add metadata
      metadata: {
        contentType: "text/plain",
        timestamp: Date.now(),
      },
    });

    console.log("Encrypted data:", {
      ciphertext: encryptedData.ciphertext.toString("base64"),
      encryptionId: encryptedData.encryptionId,
    });

    // Later, decrypt the data (requires proper authorization)
    const decryptedData = await sealClient.decrypt({
      ciphertext: encryptedData.ciphertext,
      encryptionId: encryptedData.encryptionId,
      recipientId: recipientAddress,
    });

    console.log("Decrypted data:", decryptedData.toString("utf-8"));
  } catch (error) {
    console.error("Encryption/decryption failed:", 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();

  // Create access policy on Sui
  const txb = new TransactionBlock();

  const unlockTime = Date.now() + 60000; // Unlock in 1 minute
  const authorizedUser =
    "0x742d35cc6d4c0c08c0f9bf3c9b2b6c64b3b4f5c6d7e8f9a0b1c2d3e4f5a6b7c8";

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

  // Execute transaction to create policy
  const result = await suiClient.signAndExecuteTransactionBlock({
    transactionBlock: txb,
    signer: yourKeypair, // Your Sui keypair
  });

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

  // Now encrypt with this policy
  const sensitiveData = "This will unlock in 1 minute!";

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

  console.log("Time-locked data created. Try decrypting after 1 minute.");

  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(),
      },
    });

    // Store encrypted message on decentralized storage (Walrus)
    return this.storeOnWalrus(encryptedMessage);
  }

  async readMessage(encryptionId: string, recipientKeypair: any) {
    // Retrieve from storage
    const encryptedData = await this.retrieveFromWalrus(encryptionId);

    // Decrypt with 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) {
    // Integration with Walrus storage
    // This would upload the encrypted data to Walrus
    // and return the blob ID for retrieval
  }

  private async retrieveFromWalrus(blobId: string) {
    // Retrieve encrypted data from Walrus using blob ID
  }
}

Пример 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,
  ) {
    // Create NFT ownership policy
    const accessPolicy = await this.createNftPolicy(
      requiredNftCollection,
      creatorKeypair,
    );

    // Encrypt content with NFT access requirement
    const encryptedContent = await this.sealClient.encrypt({
      data: Buffer.from(content, "utf-8"),
      recipientId: "nft_holders", // Special recipient for NFT holders
      accessPolicy: {
        policyId: accessPolicy.policyId,
        policyType: "nft_ownership",
      },
    });

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

  async accessGatedContent(
    contentId: string,
    userAddress: string,
    userKeypair: any,
  ) {
    // Verify NFT ownership first
    const hasAccess = await this.verifyNftOwnership(userAddress, contentId);

    if (!hasAccess) {
      throw new Error("Access denied: Required NFT not found");
    }

    // Decrypt content
    const decryptedContent = await this.sealClient.decrypt({
      encryptionId: contentId,
      recipientId: userAddress,
    });

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

  private async createNftPolicy(collection: string, creator: any) {
    // Create Move contract that checks NFT ownership
    // Returns policy object ID
  }

  private async verifyNftOwnership(user: string, contentId: string) {
    // Check if user owns required NFT
    // Query Sui for NFT ownership
  }
}

Пример 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();

  // Create time-lock policy on Sui
  const timeLockPolicy = await createTimeLockPolicy(
    unlockTimestamp,
    recipientAddress,
    senderKeypair,
    suiClient,
  );

  // Encrypt asset transfer data
  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(`Asset locked until ${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"));

    // Process the asset transfer
    console.log("Asset transfer unlocked:", transferData);

    return transferData;
  } catch (error) {
    console.error("Transfer not yet unlocked or access denied:", error);
    throw error;
  }
}

Интеграция с децентрализованным хранилищем Walrus​

Seal бесшовно работает с Walrus, децентрализованным решением для хранения данных от Sui. Вот как интегрировать оба:

// 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,
  ) {
    // Encrypt with Seal
    const encryptedData = await this.sealClient.encrypt({
      data,
      recipientId: recipientAddress,
      accessPolicy,
    });

    // Store encrypted data on Walrus
    const blobId = await this.walrusClient.store(encryptedData.ciphertext);

    // Return reference that includes both Seal and Walrus info
    return {
      blobId,
      encryptionId: encryptedData.encryptionId,
      accessPolicy: encryptedData.accessPolicy,
    };
  }

  async retrieveAndDecrypt(
    blobId: string,
    encryptionId: string,
    userKeypair: any,
  ) {
    // Retrieve from Walrus
    const encryptedData = await this.walrusClient.retrieve(blobId);

    // Decrypt with Seal
    const decryptedData = await this.sealClient.decrypt({
      ciphertext: encryptedData,
      encryptionId,
      recipientId: userKeypair.toSuiAddress(),
    });

    return decryptedData;
  }
}

// Usage example
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("Important document content");
  const recipientAddress = "0x...";

  // Store encrypted
  const result = await integration.storeEncryptedData(
    fileData,
    recipientAddress,
  );

  console.log("Stored with Blob ID:", result.blobId);

  // Later, retrieve and decrypt
  const decrypted = await integration.retrieveAndDecrypt(
    result.blobId,
    result.encryptionId,
    recipientKeypair,
  );

  console.log("Retrieved data:", decrypted.toString());
}

Пороговое шифрование: Расширенная конфигурация​

Для производственных приложений вам потребуется настроить пользовательское пороговое шифрование с несколькими серверами ключей:

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

async function setupProductionSeal() {
  // Configure with multiple independent key servers
  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 threshold
    network: "mainnet",
    // Advanced options
    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 = "Mission critical encrypted data";

  // Encrypt with high security guarantees
  const encrypted = await sealClient.encrypt({
    data: Buffer.from(criticalData, "utf-8"),
    recipientId: "0x...",
    // Require all 5 servers for maximum security
    customThreshold: 5,
    // Add redundancy
    redundancy: 2,
    accessPolicy: {
      // Multi-factor requirements
      requirements: ["nft_ownership", "time_lock", "multisig_approval"],
    },
  });

  return encrypted;
}

Лучшие практики безопасности​

1. Управление ключами​

// src/security-practices.ts

// GOOD: Use secure key derivation
import { generateKeypair } from "@mysten/sui/cryptography/ed25519";

const keypair = generateKeypair();

// GOOD: Store keys securely (example with environment variables)
const keypair = Ed25519Keypair.fromSecretKey(process.env.PRIVATE_KEY);

// BAD: Never hardcode keys
const badKeypair = Ed25519Keypair.fromSecretKey(
  "hardcoded-secret-key-12345", // Don't do this!
);

2. Проверка политики доступа​

// Always validate access policies before encryption
async function secureEncrypt(data: Buffer, recipient: string) {
  const { sealClient } = await createSealClient();

  // Validate recipient address
  if (!isValidSuiAddress(recipient)) {
    throw new Error("Invalid recipient address");
  }

  // Check policy exists and is valid
  const policy = await validateAccessPolicy(policyId);
  if (!policy.isValid) {
    throw new Error("Invalid access policy");
  }

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

3. Обработка ошибок и запасные варианты​

// Robust error handling
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("Access denied: Check your permissions");
    } else if (error.code === "KEY_SERVER_UNAVAILABLE") {
      // Try with backup configuration
      return await retryWithBackupServers(encryptionId, userKeypair);
    } else if (error.code === "THRESHOLD_NOT_MET") {
      throw new Error("Insufficient key servers available");
    } else {
      throw new Error(`Decryption failed: ${error.message}`);
    }
  }
}

4. Проверка данных​

// Validate data before encryption
function validateDataForEncryption(data: Buffer): boolean {
  // Check size limits
  if (data.length > 1024 * 1024) {
    // 1MB limit
    throw new Error("Data too large for encryption");
  }

  // Check for sensitive patterns (optional)
  const dataStr = data.toString();
  if (containsSensitivePatterns(dataStr)) {
    console.warn("Warning: Data contains potentially sensitive patterns");
  }

  return true;
}

Оптимизация производительности​

1. Пакетные операции​

// Batch multiple encryptions for efficiency
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. Кэширование ответов сервера ключей​

// Cache key server sessions to reduce latency
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 Integration", () => {
  it("should encrypt and decrypt data successfully", async () => {
    const { sealClient } = await createSealClient();
    const testData = Buffer.from("test message");
    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("test message");
  });

  it("should enforce access control policies", async () => {
    // Test that unauthorized users cannot decrypt
    const { sealClient } = await createSealClient();

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

    await expect(
      sealClient.decrypt({
        ciphertext: encrypted.ciphertext,
        encryptionId: encrypted.encryptionId,
        recipientId: "unauthorized-user",
      }),
    ).rejects.toThrow("Access denied");
  });
});

Развертывание в продакшене​

Конфигурация среды​

// 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,
  // Security settings
  maxDataSize: 1024 * 1024, // 1MB
  sessionTimeout: 3600000, // 1 hour
  retryAttempts: 3,
};

Мониторинг и логирование​

// utils/monitoring.ts
export class SealMonitoring {
  static logEncryption(encryptionId: string, recipient: string) {
    console.log(`[SEAL] Encrypted data ${encryptionId} for ${recipient}`);
    // Send to your monitoring service
  }

  static logDecryption(encryptionId: string, success: boolean) {
    console.log(
      `[SEAL] Decryption ${encryptionId}: ${success ? "SUCCESS" : "FAILED"}`,
    );
  }

  static logKeyServerHealth(serverUrl: string, status: string) {
    console.log(`[SEAL] Key server ${serverUrl}: ${status}`);
  }
}

Ресурсы и дальнейшие шаги​

Официальная документация​

• Seal Documentation: https://seal-docs.wal.app/
• GitHub Repository: https://github.com/MystenLabs/seal
• Sui Documentation: https://docs.sui.io/
• Walrus Documentation: https://docs.wal.app/

Сообщество и поддержка​

• Sui Discord: Присоединяйтесь к каналу #seal для поддержки сообщества
• GitHub Issues: Сообщайте об ошибках и запрашивайте функции
• Форумы для разработчиков: Форумы сообщества Sui для обсуждений

Расширенные темы для изучения​

1. Пользовательские политики доступа: Создавайте сложную логику авторизации с помощью контрактов Move
2. Кросс-чейн интеграция: Используйте Seal с другими блокчейн-сетями
3. Управление ключами для предприятий: Настройте собственную инфраструктуру серверов ключей
4. Аудит и соответствие требованиям: Внедрите логирование и мониторинг для регулируемых сред

Примеры приложений​

• Приложение для безопасного чата: Сквозное шифрование сообщений с помощью Seal
• Управление документами: Обмен корпоративными документами с контролем доступа
• Управление цифровыми правами: Распространение контента с политиками использования
• Аналитика, сохраняющая конфиденциальность: Рабочие процессы обработки зашифрованных данных

Заключение​

Seal представляет собой фундаментальный сдвиг в сторону превращения конфиденциальности и шифрования в инфраструктурные проблемы в Web3. Объединяя шифрование на основе идентификаторов, пороговую безопасность и программируемый контроль доступа, он предоставляет разработчикам мощные инструменты для создания по-настоящему безопасных и децентрализованных приложений.

Основные преимущества использования Seal включают:

• Отсутствие единой точки отказа: Распределенные серверы ключей устраняют центральные органы
• Программируемая безопасность: Политики доступа на основе смарт-контрактов обеспечивают гибкую авторизацию
• Удобство для разработчиков: SDK TypeScript легко интегрируется с существующими инструментами Web3
• Независимость от хранилища: Работает с Walrus, IPFS или любым другим решением для хранения
• Готовность к продакшену: Создан Mysten Labs с учетом корпоративных стандартов безопасности

Независимо от того, защищаете ли вы пользовательские данные, внедряете модели подписки или создаете сложные многосторонние приложения, Seal предоставляет криптографические примитивы и инфраструктуру контроля доступа, необходимые для уверенного создания.

Начните создавать сегодня и присоединяйтесь к растущей экосистеме разработчиков, которые делают конфиденциальность фундаментальной частью общественной инфраструктуры.

Готовы начать создавать? Установите @mysten/seal и начните экспериментировать с примерами из этого руководства. Децентрализованная сеть ждет приложений, которые ставят конфиденциальность и безопасность на первое место.

Публичные блокчейны предоставляют каждому участнику синхронизированный, проверяемый реестр, но по умолчанию они также раскрывают каждую часть данных. Seal, запущенный в основной сети Sui (Sui Mainnet) 3 сентября 2025 года, решает эту проблему, объединяя логику политики в блокчейне с децентрализованным управлением ключами, чтобы разработчики Web3 могли точно определять, кто получает доступ к расшифровке каких полезных данных.

Краткое содержание​

• Что это: Seal — это сеть управления секретами, которая позволяет смарт-контрактам Sui принудительно применять политики дешифрования в блокчейне, в то время как клиенты шифруют данные с помощью шифрования на основе идентификаторов (IBE) и полагаются на пороговые ключевые серверы для вывода ключей.
• Почему это важно: Вместо пользовательских бэкендов или непрозрачных внесетевых скриптов, конфиденциальность и контроль доступа становятся первоклассными примитивами Move. Разработчики могут хранить зашифрованные тексты где угодно — Walrus является естественным дополнением — но при этом ограничивать, кто может их читать.
• Кто выигрывает: Команды, выпускающие медиаконтент с токен-доступом, раскрытие информации по истечении времени, приватные сообщения или ИИ-агентов, осведомленных о политиках, могут подключиться к SDK Seal и сосредоточиться на продуктовой логике, а не на специализированной криптографической инфраструктуре.

Логика политики находится в Move​

Пакеты Seal поставляются с функциями Move seal_approve*, которые определяют, кто может запрашивать ключи для данной строки идентификатора и при каких условиях. Политики могут сочетать владение NFT, белые списки, временные блокировки или пользовательские системы ролей. Когда пользователь или агент запрашивает дешифрование, ключевые серверы оценивают эти политики через состояние полного узла Sui и одобряют запрос только в том случае, если блокчейн согласен.

Поскольку правила доступа являются частью вашего пакета в блокчейне, они прозрачны, проверяемы и версионируемы наряду с остальным кодом вашего смарт-контракта. Обновления управления могут быть развернуты, как любое другое обновление Move, с проверкой сообщества и историей в блокчейне.

Пороговая криптография управляет ключами​

Seal шифрует данные для идентификаторов, определенных приложением. Комитет независимых ключевых серверов, выбранных разработчиком, разделяет главный секрет IBE. Когда проверка политики пройдена, каждый сервер выводит долю ключа для запрошенного идентификатора. Как только кворум из t серверов отвечает, клиент объединяет доли в пригодный для использования ключ дешифрования.

Вы можете установить компромисс между живучестью и конфиденциальностью, выбирая членов комитета (Ruby Nodes, NodeInfra, Overclock, Studio Mirai, H2O Nodes, Triton One или сервис Enoki от Mysten) и выбирая порог. Нужна более высокая доступность? Выберите более крупный комитет с более низким порогом. Хотите более высокие гарантии конфиденциальности? Ужесточите кворум и полагайтесь на авторизованных провайдеров.

Опыт разработчика: SDK и сеансовые ключи​

Seal поставляется с TypeScript SDK (npm i @mysten/seal), который обрабатывает потоки шифрования/дешифрования, форматирование идентификаторов и пакетную обработку. Он также выдает сеансовые ключи, чтобы кошельки не засыпались постоянными запросами, когда приложению требуется повторный доступ. Для расширенных рабочих процессов контракты Move могут запрашивать дешифрование в блокчейне через специализированные режимы, позволяя логике, такой как раскрытие эскроу или аукционы, устойчивые к MEV, выполняться непосредственно в коде смарт-контракта.

Поскольку Seal независим от хранилища, команды могут использовать его в паре с Walrus для проверяемого хранилища больших двоичных объектов, с IPFS или даже с централизованными хранилищами, когда это соответствует операционным реалиям. Граница шифрования — и применение ее политики — перемещается вместе с данными независимо от того, где находится зашифрованный текст.

Проектирование с Seal: Лучшие практики​

• Моделируйте риск доступности: Пороги, такие как 2 из 3 или 3 из 5, напрямую соответствуют гарантиям бесперебойной работы. Промышленные развертывания должны использовать комбинацию провайдеров, отслеживать телеметрию и согласовывать SLA, прежде чем доверять критически важные рабочие процессы.
• Учитывайте изменчивость состояния: Оценка политики зависит от выполнения полными узлами вызовов dry_run. Избегайте правил, которые зависят от быстро меняющихся счетчиков или порядка внутри контрольных точек, чтобы предотвратить непоследовательные одобрения на разных серверах.
• Планируйте гигиену ключей: Производные ключи хранятся на клиенте. Настройте логирование, ротируйте сеансовые ключи и рассмотрите конвертное шифрование — используйте Seal для защиты симметричного ключа, который шифрует более крупную полезную нагрузку — чтобы ограничить радиус поражения в случае компрометации устройства.
• Архитектура для ротации: Комитет зашифрованного текста фиксируется во время шифрования. Создавайте пути обновления, которые повторно шифруют данные через новые комитеты, когда вам нужно сменить провайдеров или скорректировать предположения о доверии.

Что дальше​

Дорожная карта Seal указывает на управляемые валидаторами MPC-серверы, клиентские инструменты в стиле DRM и постквантовые опции KEM. Для разработчиков, исследующих ИИ-агентов, премиум-контент или регулируемые потоки данных, сегодняшний релиз уже предоставляет четкий план: кодируйте свою политику в Move, создайте разнообразный ключевой комитет и предоставляйте зашифрованные возможности, которые уважают конфиденциальность пользователей, не выходя за пределы границы доверия Sui.

Если вы рассматриваете Seal для вашего следующего запуска, начните с прототипирования простой политики с NFT-доступом с открытым комитетом 2 из 3, затем итерируйте к комбинации провайдеров и операционных контролей, которые соответствуют профилю риска вашего приложения.

Блокчейн Sui стал самой технически продвинутой платформой для вычислительных нагрузок следующего поколения, достигая 297 000 транзакций в секунду с финализацией 480 мс, одновременно интегрируя квантово-устойчивую криптографию и специализированную инфраструктуру робототехники. Под руководством главного криптографа Костаса Халкиаса, имеющего более 50 академических публикаций и являющегося пионером криптографических инноваций в проекте Diem от Meta, Sui представляет собой фундаментальное архитектурное отличие от устаревших блокчейнов, разработанное специально для автономных ИИ-агентов, координации нескольких роботов и постквантовой безопасности.

В отличие от конкурентов, адаптирующих блокчейн для передовых вычислений, объектно-ориентированная модель данных Sui, язык программирования Move и протокол консенсуса Mysticeti были разработаны с самого начала для параллельных ИИ-операций, управления робототехникой в реальном времени и криптографической гибкости — возможностей, подтвержденных реальными развертываниями, включая более 50 ИИ-проектов, демонстрации сотрудничества нескольких роботов и первый в мире обратно совместимый путь обновления с квантовой безопасностью для блокчейн-кошельков.

Революционная техническая основа Sui делает невозможное возможным​

Архитектура Sui отличается от традиционных аккаунт-ориентированных блокчейн-моделей благодаря трем синергетическим инновациям, которые уникально позиционируют ее для приложений ИИ, робототехники и квантовых вычислений.

Протокол консенсуса Mysticeti достигает беспрецедентной производительности благодаря несертифицированной DAG-архитектуре, сокращая задержку консенсуса до 390-650 мс (на 80% быстрее, чем его предшественник), при этом поддерживая устойчивую пропускную способность более 200 000 TPS. Это представляет собой фундаментальный прорыв: традиционные блокчейны, такие как Ethereum, требуют 12-15 секунд для финализации, в то время как быстрый путь Sui для транзакций с одним владельцем завершается всего за 250 мс. Несколько лидеров протокола за раунд и механизм неявного подтверждения позволяют создавать циклы принятия решений ИИ в реальном времени и системы управления робототехникой, требующие обратной связи менее чем за секунду — приложения, физически невозможные на цепочках последовательного выполнения.

Объектно-ориентированная модель данных рассматривает каждый актив как независимо адресуемый объект с явным владением и версионированием, что позволяет проводить статический анализ зависимостей до выполнения. Этот архитектурный выбор устраняет накладные расходы на ретроактивное обнаружение конфликтов, характерные для моделей оптимистичного выполнения, позволяя тысячам ИИ-агентов совершать транзакции одновременно без конфликтов. Объекты полностью обходят консенсус, когда принадлежат одной стороне, экономя 70% времени обработки для обычных операций. Для робототехники это означает, что отдельные роботы поддерживают принадлежащие объекты для данных датчиков, координируя свои действия через общие объекты только при необходимости — точно отражая архитектуры автономных систем реального мира.

Язык программирования Move обеспечивает ресурсно-ориентированную безопасность, невозможную в аккаунт-ориентированных языках, таких как Solidity. Активы существуют как типы первого класса, которые нельзя скопировать или уничтожить — только переместить между контекстами — предотвращая целые классы уязвимостей, включая атаки повторного входа, двойные траты и несанкционированное манипулирование активами. Линейная система типов Move и поддержка формальной верификации делают его особенно подходящим для ИИ-агентов, автономно управляющих ценными активами. Программируемые блоки транзакций (PTB) атомарно объединяют до 1024 вызовов функций, обеспечивая сложные многошаговые рабочие процессы ИИ с гарантированной согласованностью.

Костас Халкиас разрабатывает квантовую устойчивость как конкурентное преимущество​

Костас "Криптос" Халкиас привносит беспрецедентный криптографический опыт в стратегию Sui по квантовым вычислениям, являясь автором алгоритма блокчейн-постквантовой подписи (BPQS), руководителем криптографии для блокчейна Diem от Meta и опубликовав более 50 рецензируемых статей, цитируемых более 1374 раз. Его прорывное исследование в июле 2025 года продемонстрировало первый обратно совместимый путь обновления с квантовой безопасностью для блокчейн-кошельков, применимый к цепочкам на основе EdDSA, включая Sui, Solana, Near и Cosmos.

Видение Халкиаса позиционирует квантовую устойчивость не как отдаленную проблему, а как немедленное конкурентное преимущество. В январе 2025 года он предупредил, что "правительства хорошо осведомлены о рисках, связанных с квантовыми вычислениями. Агентства по всему миру издали мандаты о том, что классические алгоритмы, такие как ECDSA и RSA, должны быть устаревшими к 2030 или 2035 году". Его техническое понимание: даже если пользователи сохранят приватные ключи, они могут быть не в состоянии генерировать постквантовые доказательства владения, не подвергая ключи квантовым атакам. Решение Sui использует STARK-доказательства с нулевым разглашением для подтверждения знания сидов генерации ключей без раскрытия конфиденциальных данных — криптографическая инновация, невозможная на блокчейнах, лишенных встроенной гибкости.

Фреймворк криптографической гибкости представляет собой фирменную философию дизайна Халкиаса. Sui использует 1-байтовые флаги для различения схем подписи (Ed25519, ECDSA Secp256k1/r1, BLS12-381, мультиподпись, zkLogin), обеспечивая поддержку новых алгоритмов на уровне протокола без накладных расходов смарт-контрактов или хардфорков. Эта архитектура позволяет "нажатием кнопки" переходить на стандартизированные NIST постквантовые алгоритмы, включая CRYSTALS-Dilithium (подписи 2420 байт) и FALCON (подписи 666 байт), когда материализуются квантовые угрозы. Халкиас разработал несколько путей миграции: проактивный (новые аккаунты генерируют PQ-ключи при создании), адаптивный (STARK-доказательства позволяют PQ-миграцию из существующих сидов) и гибридный (мультиподпись с ограниченным сроком действия, объединяющая классические и квантово-устойчивые ключи).

Его инновация zkLogin демонстрирует криптографическую креативность, примененную к удобству использования. Система позволяет пользователям аутентифицироваться с помощью учетных данных Google, Facebook или Twitch, используя Groth16 доказательства с нулевым разглашением на кривых BN254, с управляемой пользователем солью, предотвращающей корреляцию идентификаторов Web2-Web3. Адреса zkLogin учитывают квантовые соображения с самого начала — STARK-доказательства знания сида обеспечивают постквантовую безопасность, даже когда базовые JWT-подписи переходят от RSA к альтернативам на основе решеток.

На Sui Basecamp 2025 Халкиас представил нативную проверяемую случайность, zk-туннели для оффчейн-логики, молниеносные транзакции (без газа, без задержки) и капсулы времени для зашифрованного доступа к данным в будущем. Эти функции обеспечивают частные симуляции ИИ-агентов, азартные игры, требующие доверенной случайности, и покерные игры с нулевым разглашением — все это невозможно без криптографических примитивов на уровне протокола. Его видение: "Целью Sui было стать первым блокчейном, который примет постквантовые технологии, тем самым улучшив безопасность и подготовившись к будущим нормативным стандартам".

Инфраструктура ИИ-агентов достигает производственной зрелости на Sui​

Sui размещает самую полную в блокчейн-индустрии экосистему ИИ-агентов с более чем 50 проектами, охватывающими инфраструктуру, фреймворки и приложения — все они используют параллельное выполнение Sui и финализацию менее чем за секунду для автономных операций в реальном времени.

Atoma Network была запущена в основной сети Sui в декабре 2024 года как первый полностью децентрализованный уровень вывода ИИ, позиционируя себя как "децентрализованный гиперскейлер для ИИ с открытым исходным кодом". Вся обработка происходит в Доверенных средах выполнения (TEE), обеспечивая полную конфиденциальность и устойчивость к цензуре, сохраняя при этом совместимость API с конечными точками OpenAI. Приложение для чата Utopia демонстрирует готовый к производству ИИ, сохраняющий конфиденциальность, с производительностью, соответствующей ChatGPT, осуществляя платежи и проверку через финализацию Sui менее чем за секунду. Atoma позволяет управлять портфелем DeFi, модерировать контент в социальных сетях и использовать приложения персонального помощника — варианты использования, требующие как интеллекта ИИ, так и расчетов на блокчейне, что невозможно достичь на более медленных цепочках.

OpenGraph Labs совершила технический прорыв, став первой полностью ончейн-системой вывода ИИ, разработанной специально для ИИ-агентов. Их SDK TensorflowSui автоматизирует развертывание моделей машинного обучения Web2 (TensorFlow, PyTorch) на блокчейне Sui, храня данные обучения в децентрализованном хранилище Walrus, а вывод выполняет с использованием Программируемых блоков транзакций. OpenGraph предоставляет три гибких подхода к выводу: вывод PTB для критически важных вычислений, требующих атомарности, разделенные транзакции для оптимизации затрат и гибридные комбинации, настраиваемые для каждого варианта использования. Эта архитектура устраняет риски ИИ "черного ящика" благодаря полностью проверяемым, аудируемым процессам вывода с четко определенным алгоритмическим владением — что критически важно для регулируемых отраслей, требующих объяснимого ИИ.

Talus Network была запущена на Sui в феврале 2025 года с фреймворком Nexus, позволяющим разработчикам создавать компонуемые ИИ-агенты, выполняющие рабочие процессы непосредственно в цепочке. Платформа Idol.fun от Talus демонстрирует потребительские ИИ-агенты как токенизированные сущности, работающие автономно 24/7, принимающие решения в реальном времени, используя наборы данных, хранящиеся в Walrus, для анализа настроений рынка, статистики DeFi и социальных тенденций. Примеры приложений включают динамическое управление профилями NFT, агентов стратегии ликвидности DeFi, загружающих модели в реальном времени, и агентов обнаружения мошенничества, анализирующих исторические шаблоны транзакций из неизменяемых контрольных точек Sui.

Партнерство с Alibaba Cloud, объявленное в августе 2025 года, интегрировало ИИ-помощников по кодированию в платформу разработки ChainIDE с многоязычной поддержкой (английский, китайский, корейский). Функции включают генерацию кода Move из естественного языка, интеллектуальное автозаполнение, обнаружение уязвимостей безопасности в реальном времени и автоматическую генерацию документации — снижая барьеры для 60% целевых разработчиков Sui, не говорящих по-английски. Это партнерство подтверждает позиционирование Sui как платформы для разработки ИИ, а не просто платформы для развертывания ИИ.

Спонсируемые транзакции Sui устраняют трение при оплате газа для ИИ-агентов — разработчики могут покрывать комиссии за транзакции, позволяя агентам работать без хранения токенов SUI. Деноминация MIST (1 SUI = 1 миллиард MIST) позволяет совершать микроплатежи размером в доли цента, что идеально подходит для ИИ-сервисов с оплатой за вывод. При средней стоимости транзакции около 0,0023 доллара США ИИ-агенты могут выполнять тысячи операций ежедневно за копейки, делая экономики автономных агентов экономически жизнеспособными.

Сотрудничество нескольких роботов доказывает преимущество Sui в координации в реальном времени​

Sui продемонстрировала первую в блокчейн-индустрии систему сотрудничества нескольких роботов, использующую консенсус Mysticeti, подтвержденную всесторонним анализом Tiger Research 2025 года. Система позволяет роботам обмениваться согласованным состоянием в распределенных средах, сохраняя при этом Византийскую отказоустойчивость — обеспечивая консенсус даже при сбоях роботов или их компрометации противниками.

Техническая архитектура использует объектную модель Sui, где роботы существуют как программируемые объекты с метаданными, владением и возможностями. Задачи назначаются конкретным объектам роботов, а смарт-контракты автоматизируют правила секвенирования и распределения ресурсов. Система поддерживает надежность без центральных серверов, с параллельными предложениями блоков от нескольких валидаторов, предотвращающими единые точки отказа. Завершение транзакций менее чем за секунду позволяет создавать циклы корректировки в реальном времени — роботы получают подтверждения задач и обновления состояния менее чем за 400 мс, что соответствует требованиям систем управления для оперативной автономной работы.

Физические испытания с роботами, похожими на собак, уже продемонстрировали осуществимость, при этом команды из NASA, Meta и Uber разрабатывают робототехнические приложения на базе Sui. Уникальная функция Sui "безинтернетный режим" — работа через радиоволны без стабильного подключения к Интернету — предоставляет революционные преимущества для развертываний в сельских районах Африки, сельской Азии и в чрезвычайных ситуациях. Эта автономная возможность существует исключительно на Sui среди основных блокчейнов, подтвержденная тестированием во время отключений электроэнергии в Испании/Португалии.

Партнерство с 3DOS, объявленное в сентябре 2024 года, подтверждает возможности Sui в производственной робототехнике в масштабе. 3DOS интегрировала более 79 909 3D-принтеров в более чем 120 странах в качестве эксклюзивного блокчейн-партнера Sui, создав сеть "Uber для 3D-печати", обеспечивающую одноранговое производство. Среди известных клиентов — John Deere, Google, MIT, Harvard, Bosch, Британская армия, ВМС США, ВВС США и NASA — что демонстрирует доверие корпоративного уровня к инфраструктуре Sui. Система позволяет роботам автономно заказывать и печатать запасные части с помощью автоматизации смарт-контрактов, облегчая саморемонт роботов с почти нулевым вмешательством человека. Это решает проблему глобального производственного рынка объемом 15,6 триллиона долларов США за счет производства по требованию, устраняющего запасы, отходы и международную доставку.

Византийская отказоустойчивость Sui оказывается критически важной для критически важных для безопасности робототехнических приложений. Механизм консенсуса допускает до f неисправных/вредоносных роботов в системе 3f+1, обеспечивая координацию парков автономных транспортных средств, складских роботов и производственных систем, несмотря на отдельные сбои. Смарт-контракты обеспечивают соблюдение ограничений безопасности и рабочих границ, а неизменяемые аудиторские следы обеспечивают подотчетность за автономные решения — требования, которые невозможно выполнить с помощью централизованных серверов координации, уязвимых для единых точек отказа.

Дорожная карта квантовой устойчивости обеспечивает криптографическое превосходство​

Стратегия Sui в области квантовых вычислений представляет собой единственный в блокчейн-индустрии комплексный, проактивный подход, соответствующий мандатам NIST, требующим устаревания классических алгоритмов к 2030 году и полной квантово-устойчивой стандартизации к 2035 году.

Прорывное исследование Халкиаса в июле 2025 года продемонстрировало, что цепочки на основе EdDSA, включая Sui, могут реализовать квантово-безопасные обновления кошельков без хардфорков, изменений адресов или замораживания аккаунтов с помощью доказательств с нулевым разглашением, подтверждающих знание сида. Это позволяет безопасно мигрировать даже неактивным аккаунтам — решая экзистенциальную угрозу, стоящую перед блокчейнами, где миллионы кошельков "могут быть мгновенно опустошены" после появления квантовых компьютеров. Техническая инновация использует STARK-доказательства (квантово-устойчивая безопасность на основе хешей) для подтверждения знания сидов генерации ключей EdDSA без раскрытия конфиденциальных данных, позволяя пользователям устанавливать владение PQ-ключом, привязанным к существующим адресам.

Архитектура криптографической гибкости Sui позволяет использовать несколько стратегий перехода: проактивную (PQ-ключи подписывают публичные ключи PreQ при создании), адаптивную (STARK-доказательства мигрируют существующие адреса) и гибридную (мультиподпись с ограниченным сроком действия с классическими и PQ-ключами). Протокол поддерживает немедленное развертывание стандартизированных NIST алгоритмов, включая CRYSTALS-Dilithium (ML-DSA), FALCON (FN-DSA) и SPHINCS+ (SLH-DSA) для постквантовой безопасности на основе решеток и хешей. BLS-подписи валидаторов переходят на альтернативы на основе решеток, хеш-функции обновляются с 256-битных до 384-битных выходов для квантово-устойчивой устойчивости к коллизиям, а схемы zkLogin мигрируют с Groth16 на STARK-доказательства с нулевым разглашением.

Фреймворк Nautilus, запущенный в июне 2025 года, обеспечивает безопасные оффчейн-вычисления с использованием самоуправляемых TEE (Доверенных сред выполнения), в настоящее время поддерживая AWS Nitro Enclaves с будущей совместимостью с Intel TDX и AMD SEV. Для ИИ-приложений Nautilus обеспечивает частный вывод ИИ с криптографическими аттестациями, верифицированными ончейн, решая противоречие между вычислительной эффективностью и проверяемостью. Партнеры по запуску, включая Bluefin (сопоставление ордеров на основе TEE за менее 1 мс), TensorBlock (инфраструктура ИИ-агентов) и OpenGradient, демонстрируют готовность к производству для квантово-устойчивых вычислений, сохраняющих конфиденциальность.

Сравнительный анализ показывает квантовое преимущество Sui: Ethereum остается на стадии планирования, при этом Виталик Бутерин заявляет, что квантовая устойчивость "как минимум через десятилетие", требуя хардфорков и консенсуса сообщества. Solana запустила Winternitz Vault в январе 2025 года как опциональную функцию подписи на основе хешей, требующую согласия пользователя, а не реализации на уровне протокола. Другие крупные блокчейны (Aptos, Avalanche, Polkadot) остаются на стадии исследования без конкретных сроков реализации. Только Sui разработала криптографическую гибкость как основополагающий принцип, позволяющий быстро переходить на новые алгоритмы без битв за управление или разделения сети.

Синтез технической архитектуры создает новые возможности​

Архитектурные компоненты Sui взаимодействуют синергетически, создавая возможности, превосходящие сумму отдельных функций — характеристика, отличающая по-настоящему инновационные платформы от инкрементальных улучшений.

Ресурсная модель языка Move в сочетании с параллельным выполнением объектов обеспечивает беспрецедентную пропускную способность для роев ИИ-агентов. Традиционные блокчейны, использующие аккаунт-ориентированные модели, требуют последовательного выполнения для предотвращения состояний гонки, ограничивая координацию ИИ-агентов однопоточными узкими местами. Явное объявление зависимостей Sui через ссылки на объекты позволяет валидаторам идентифицировать независимые операции до выполнения, планируя тысячи транзакций ИИ-агентов одновременно на ядрах ЦП. Эта параллелизация доступа к состоянию (в отличие от оптимистичного выполнения, требующего обнаружения конфликтов) обеспечивает предсказуемую производительность без ретроактивных сбоев транзакций — что критически важно для ИИ-систем, требующих гарантий надежности.

Программируемые блоки транзакций (PTB) усиливают компонуемость Move, позволяя до 1024 разнородных вызовов функций в атомарных транзакциях. ИИ-агенты могут выполнять сложные рабочие процессы — обменивать токены, обновлять данные оракула, запускать вывод машинного обучения, минтить NFT, отправлять уведомления — все это гарантированно успешно или провально вместе. Эта гетерогенная композиция перемещает логику из смарт-контрактов на уровень транзакций, значительно снижая затраты на газ при одновременном повышении гибкости. Для робототехники PTB позволяют выполнять атомарные многошаговые операции, такие как "проверить инвентарь, заказать детали, авторизовать платеж, обновить статус" с криптографическими гарантиями согласованности.

Быстрый путь обхода консенсуса для объектов с одним владельцем создает двухъярусную модель производительности, идеально соответствующую шаблонам доступа ИИ/робототехники. Отдельные роботы поддерживают частное состояние (показания датчиков, операционные параметры) как принадлежащие объекты, обрабатываемые за 250 мс без консенсуса валидаторов. Точки координации (очереди задач, пулы ресурсов) существуют как общие объекты, требующие 390 мс консенсуса. Эта архитектура отражает реальные автономные системы, где агенты поддерживают локальное состояние, но координируют свои действия через общие ресурсы — объектная модель Sui естественным образом предоставляет блокчейн-нативные примитивы, соответствующие этим шаблонам.

zkLogin решает проблему трения при онбординге, препятствующую массовому внедрению ИИ-агентов. Традиционный блокчейн требует от пользователей управления сид-фразами и приватными ключами — что когнитивно требовательно и подвержено ошибкам. zkLogin позволяет аутентифицироваться с помощью знакомых учетных данных OAuth (Google, Facebook, Twitch) с управляемой пользователем солью, предотвращающей корреляцию идентификаторов Web2-Web3. ИИ-агенты могут работать под аутентификацией Web2, сохраняя при этом безопасность блокчейна, что значительно снижает барьеры для потребительских приложений. Более 10 dApps, уже интегрирующих zkLogin, демонстрируют практическую жизнеспособность для некриптографической аудитории.

Конкурентное позиционирование раскрывает техническое лидерство и рост экосистемы​

Сравнительный анализ основных блокчейнов (Solana, Ethereum, Aptos, Avalanche, Polkadot) показывает техническое превосходство Sui для передовых вычислительных нагрузок, сбалансированное со зрелостью экосистемы Ethereum и текущим внедрением DePIN в Solana.

Метрики производительности устанавливают Sui как лидера по пропускной способности с 297 000 TPS, протестированными на 100 валидаторах с финализацией 480 мс, против теоретических 65 000-107 000 TPS Solana (3 000-4 000 устойчивых) и базового уровня Ethereum 15-30 TPS. Aptos достигает теоретических 160 000 TPS с аналогичной архитектурой на основе Move, но с разными моделями выполнения. Для ИИ-нагрузок, требующих решений в реальном времени, финализация Sui в 480 мс позволяет создавать немедленные циклы ответа, невозможные при финализации Ethereum в 12-15 минут или даже при случайных перегрузках сети Solana (75% сбоев транзакций в апреле 2024 года при пиковой нагрузке).

Анализ квантовой устойчивости показывает Sui как единственный блокчейн с квантово-устойчивой криптографией, разработанной в основной архитектуре с самого начала. Ethereum рассматривает квантовую устойчивость на этапе дорожной карты "The Splurge", но Виталик Бутерин оценивает 20% вероятность того, что квантовые компьютеры взломают криптографию к 2030 году, полагаясь на планы экстренного "форка восстановления", которые являются реактивными, а не проактивными. Winternitz Vault Solana обеспечивает опциональную квантовую защиту, требующую согласия пользователя, а не автоматическую безопасность всей сети. Aptos, Avalanche и Polkadot остаются на стадии исследования без конкретных сроков. Криптографическая гибкость Sui с несколькими путями миграции, zkLogin на основе STARK и дорожная карта, соответствующая NIST, позиционирует ее как единственный блокчейн, готовый к обязательным постквантовым переходам 2030/2035 годов.

Экосистемы ИИ-агентов показывают, что Solana в настоящее время лидирует по внедрению благодаря зрелым инструментам (SendAI Agent Kit, ElizaOS) и крупнейшему сообществу разработчиков, но Sui демонстрирует превосходные технические возможности благодаря пропускной способности 300 000 TPS, задержке менее секунды и более 50 проектам, включая производственные платформы (основная сеть Atoma, Talus Nexus, ончейн-вывод OpenGraph). Ethereum фокусируется на институциональных стандартах ИИ (ERC-8004 для идентификации/доверия ИИ), но базовый уровень 15-30 TPS ограничивает приложения ИИ в реальном времени решениями Layer 2. Партнерство с Alibaba Cloud, позиционирующее Sui как платформу для разработки ИИ (а не просто платформу для развертывания), сигнализирует о стратегическом отличии от чисто финансовых блокчейнов.

Возможности робототехники существуют исключительно на Sui среди основных блокчейнов. Ни один конкурент не демонстрирует инфраструктуру для сотрудничества нескольких роботов, Византийскую отказоустойчивую координацию или автономную работу в "безинтернетном режиме". Анализ Tiger Research приходит к выводу, что "блокчейн может быть более подходящей инфраструктурой для роботов, чем для людей", учитывая способность роботов использовать децентрализованную координацию без централизованного доверия. Поскольку Morgan Stanley прогнозирует 1 миллиард человекоподобных роботов к 2050 году, специально созданная инфраструктура робототехники Sui создает преимущество первопроходца в развивающейся экономике роботов, где автономные системы требуют идентификации, платежей, контрактов и координации — примитивов, которые Sui предоставляет нативно.

Преимущества языка программирования Move позиционируют как Sui, так и Aptos выше цепочек на основе Solidity для сложных приложений, требующих безопасности. Ресурсно-ориентированная модель Move предотвращает классы уязвимостей, которые невозможно исправить в Solidity, о чем свидетельствует потеря более 1,1 миллиарда долларов из-за эксплойтов в 2024 году на Ethereum. Поддержка формальной верификации, линейная система типов и абстракции активов первого класса делают Move особенно подходящим для ИИ-агентов, автономно управляющих ценными активами. Объектно-ориентированный вариант Sui Move (по сравнению с аккаунт-ориентированным Diem Move) обеспечивает преимущества параллельного выполнения, недоступные на Aptos, несмотря на общее языковое наследие.

Реальные внедрения подтверждают технические возможности​

Производственные развертывания Sui демонстрируют переход платформы от технического потенциала к практической полезности в областях ИИ, робототехники и квантовых вычислений.

Зрелость инфраструктуры ИИ показывает явный прогресс с запуском основной сети Atoma Network в декабре 2024 года, обслуживающей производственный вывод ИИ, развертыванием фреймворка Nexus Talus в феврале 2025 года, обеспечивающего компонуемые рабочие процессы агентов, и раундом финансирования Swarm Network на 13 миллионов долларов, поддержанным Костасом Халкиасом, продавшим более 10 000 лицензий ИИ-агентов на Sui. Партнерство с Alibaba Cloud обеспечивает проверку корпоративного уровня с ИИ-помощниками по кодированию, интегрированными в инструменты разработчика, демонстрируя стратегическую приверженность, выходящую за рамки спекулятивных приложений. OpenGraph Labs, занявшая первое место на хакатоне Sui AI Typhoon с ончейн-выводом ML, сигнализирует о технических инновациях, признанных экспертными судьями.

Производственная робототехника достигла коммерческого масштаба благодаря сети 3DOS из 79 909 принтеров в более чем 120 странах, обслуживающей NASA, ВМС США, ВВС США, John Deere и Google. Это крупнейшая в мире интегрированная с блокчейном производственная сеть, обрабатывающая более 4,2 миллионов деталей с более чем 500 000 пользователей. Одноранговая модель, позволяющая роботам автономно заказывать запасные части, демонстрирует автоматизацию смарт-контрактов, устраняющую накладные расходы на координацию в промышленных масштабах — доказательство концепции, подтвержденное требовательными государственными и аэрокосмическими клиентами, требующими надежности и безопасности.

Финансовые метрики показывают растущее внедрение с TVL в 538 миллионов долларов, 17,6 миллиона ежемесячно активных кошельков (пик в феврале 2025 года) и рыночной капитализацией токена SUI, превышающей 16 миллиардов долларов. Mysten Labs достигла оценки более 3 миллиардов долларов при поддержке a16z, Binance Labs, Coinbase Ventures и Jump Crypto — институциональная проверка технического потенциала. Швейцарские банки (Sygnum, Amina Bank), предлагающие хранение и торговлю Sui, предоставляют традиционные финансовые шлюзы, в то время как институциональные продукты Grayscale, Franklin Templeton и VanEck сигнализируют о массовом признании.

Рост экосистемы разработчиков демонстрирует устойчивость благодаря комплексным инструментам (SDK для TypeScript, Rust, Python, Swift, Dart, Golang), ИИ-помощникам по кодированию в ChainIDE и активным хакатон-программам, где 50% победителей сосредоточились на ИИ-приложениях. 122 активных валидатора в основной сети обеспечивают адекватную децентрализацию при сохранении производительности, балансируя безопасность с пропускной способностью лучше, чем высокоцентрализованные альтернативы.

Стратегическое видение позиционирует Sui для эры конвергенции​

Костас Халкиас и руководство Mysten Labs формулируют последовательное долгосрочное видение, отличающее Sui от конкурентов, сосредоточенных на узких вариантах использования или итеративных улучшениях.

Смелое предсказание Халкиаса о том, что "в конечном итоге блокчейн превзойдет даже Visa по скорости транзакций. Это станет нормой. Я не вижу, как мы можем этого избежать", сигнализирует об уверенности в технической траектории, подкрепленной архитектурными решениями, обеспечивающими это будущее. Его заявление о том, что Mysten Labs "может превзойти то, чем является Apple сегодня", отражает амбиции, основанные на создании фундаментальной инфраструктуры для вычислений следующего поколения, а не инкрементальных DeFi-приложений. Решение назвать его сына "Криптос" (греч. "секрет/скрытый") символизирует личную приверженность криптографическим инновациям как цивилизационной инфраструктуре.

Трехстолпная стратегия, интегрирующая ИИ, робототехнику и квантовые вычисления, создает взаимоусиливающие преимущества. Квантово-устойчивая криптография обеспечивает долгосрочную безопасность активов для автономно работающих ИИ-агентов. Завершение транзакций менее чем за секунду поддерживает циклы управления робототехникой в реальном времени. Параллельное выполнение позволяет тысячам ИИ-агентов координировать свои действия одновременно. Объектная модель обеспечивает естественную абстракцию как для состояния ИИ-агента, так и для представления устройства робота. Эта архитектурная согласованность отличает целенаправленный дизайн платформы от прикрученных функций.

Технологические анонсы Sui Basecamp 2025 демонстрируют непрерывные инновации с нативной проверяемой случайностью (устраняет зависимости от оракулов для вывода ИИ), zk-туннелями, позволяющими совершать частные видеозвонки непосредственно на Sui, молниеносными транзакциями для операций без газа в чрезвычайных ситуациях, и капсулами времени для зашифрованного доступа к данным в будущем. Эти функции решают реальные проблемы пользователей (конфиденциальность, надежность, доступность), а не являются академическими упражнениями, с четкими приложениями для ИИ-агентов, требующих доверенной случайности, робототехнических систем, нуждающихся в автономной работе, и квантово-устойчивого шифрования для конфиденциальных данных.

Позиционирование как "уровня координации для широкого спектра приложений" от управления медицинскими данными до владения персональными данными и робототехники отражает амбиции платформы, выходящие за рамки финансовых спекуляций. Идентификация Халкиасом неэффективности медицинских данных как проблемы, требующей общей базы данных, демонстрирует мышление об общественной инфраструктуре, а не о узких нишах блокчечейн-энтузиастов. Это видение привлекает исследовательские лаборатории, аппаратные стартапы и правительства — аудитории, ищущие надежную инфраструктуру для долгосрочных проектов, а не спекулятивное доходное фермерство.

Техническая дорожная карта обеспечивает действенный график выполнения​

Дорожная карта развития Sui предоставляет конкретные вехи, демонстрирующие прогресс от видения к реализации во всех трех областях.

График квантовой устойчивости соответствует мандатам NIST: 2025-2027 годы завершают инфраструктуру и тестирование криптографической гибкости, 2028-2030 годы вводят обновления протокола для подписей Dilithium/FALCON с гибридной PreQ-PQ операцией, 2030-2035 годы достигают полного постквантового перехода, отменяющего классические алгоритмы. Несколько путей миграции (проактивный, адаптивный, гибридный) обеспечивают гибкость для различных сегментов пользователей без навязывания единой стратегии внедрения. Обновления хеш-функций до 384-битных выходов и исследования zkLogin PQ-zkSNARK проводятся параллельно, обеспечивая всестороннюю квантовую готовность, а не фрагментарные исправления.

Расширение инфраструктуры ИИ показывает четкие вехи с запуском основной сети Walrus (Q1 2025), обеспечивающей децентрализованное хранилище для моделей ИИ, фреймворком Talus Nexus, обеспечивающим компонуемые рабочие процессы агентов (развертывание в феврале 2025 года), и фреймворком Nautilus TEE, расширяющимся до Intel TDX и AMD SEV помимо текущей поддержки AWS Nitro Enclaves. Дорожная карта партнерства с Alibaba Cloud включает расширенную языковую поддержку, более глубокую интеграцию ChainIDE и демонстрационные дни в Гонконге, Сингапуре и Дубае, ориентированные на сообщества разработчиков. Ончейн-эксплорер вывода OpenGraph и созревание TensorflowSui SDK предоставляют практические инструменты для ИИ-разработчиков, выходящие за рамки теоретических фреймворков.

Развитие возможностей робототехники прогрессирует от демонстраций сотрудничества нескольких роботов до производственных развертываний с расширением сети 3DOS, возможностями транзакций по радиоволнам в "безинтернетном режиме" и zkTunnels, позволяющими выполнять команды роботов без газа. Техническая архитектура, поддерживающая Византийскую отказоустойчивость, циклы координации менее чем за секунду и автономные M2M-платежи, существует сегодня — барьеры для внедрения являются образовательными и экосистемными, а не техническими ограничениями. Участие выпускников NASA, Meta и Uber сигнализирует о серьезном инженерном таланте, решающем реальные проблемы робототехники, а не академические исследовательские проекты.

Улучшения протокола включают усовершенствования консенсуса Mysticeti, сохраняющие преимущество в сокращении задержки на 80%, горизонтальное масштабирование через многомашинное выполнение Pilotfish и оптимизацию хранилища для растущего состояния. Система контрольных точек (каждые ~3 секунды) предоставляет проверяемые снимки для обучающих данных ИИ и аудиторских следов робототехники. Уменьшение размера транзакций до однобайтовых предустановленных форматов снижает требования к пропускной способности для устройств IoT. Расширение спонсируемых транзакций устраняет трение газа для потребительских приложений, требующих бесшовного UX, похожего на Web2.

Техническое превосходство позиционирует Sui для доминирования в передовых вычислениях​

Комплексный анализ технической архитектуры, видения руководства, реальных внедрений и конкурентного позиционирования показывает, что Sui является блокчейн-платформой, уникально подготовленной к конвергенции ИИ, робототехники и квантовых вычислений.

Sui достигает технического превосходства благодаря измеренным метрикам производительности: 297 000 TPS с финализацией 480 мс превосходят всех основных конкурентов, обеспечивая координацию ИИ-агентов в реальном времени и управление робототехникой, невозможные на более медленных цепочках. Объектно-ориентированная модель данных в сочетании с безопасностью языка Move обеспечивает преимущества модели программирования, предотвращающие классы уязвимостей, характерные для аккаунт-ориентированных архитектур. Криптографическая гибкость, разработанная с самого начала, а не доработанная, обеспечивает квантово-устойчивые переходы без хардфорков или битв за управление. Эти возможности существуют сегодня в производстве в основной сети со 122 валидаторами, а не как теоретические вайтпейперы или далекие дорожные карты.

Визионерское лидерство благодаря более чем 50 публикациям Костаса Халкиаса, 8 патентам США и криптографическим инновациям (zkLogin, BPQS, Winterfell STARK, HashWires) обеспечивает интеллектуальную основу, отличающую Sui от технически компетентных, но неизобретательных конкурентов. Его прорывные исследования в области квантовых вычислений (июль 2025 г.), поддержка инфраструктуры ИИ (поддержка Swarm Network) и публичные выступления (Token 2049, Korea Blockchain Week, London Real) устанавливают лидерство мнений, привлекающее ведущих разработчиков и институциональных партнеров. Готовность к архитектуре на период 2030+ годов по сравнению с ежеквартальными метриками демонстрирует долгосрочное стратегическое мышление, необходимое для инфраструктуры платформы.

Проверка экосистемы через производственные развертывания (вывод ИИ в основной сети Atoma, сеть 3DOS из 79 909 принтеров, фреймворки агентов Talus) доказывает, что технические возможности преобразуются в реальную полезность. Институциональные партнерства (Alibaba Cloud, хранение в швейцарских банках, продукты Grayscale/Franklin Templeton) сигнализируют о массовом признании за пределами блокчейн-энтузиастов. Метрики роста разработчиков (50% победителей хакатонов в области ИИ, комплексное покрытие SDK, ИИ-помощники по кодированию) демонстрируют устойчивое расширение экосистемы, поддерживающее долгосрочное внедрение.

Стратегическое позиционирование как блокчейн-инфраструктуры для экономики роботов, квантово-устойчивых финансовых систем и координации автономных ИИ-агентов создает дифференцированное ценностное предложение по сравнению с конкурентами, сосредоточенными на инкрементальных улучшениях существующих вариантов использования блокчейна. Поскольку Morgan Stanley прогнозирует 1 миллиард человекоподобных роботов к 2050 году, NIST обязывает использовать квантово-устойчивые алгоритмы к 2030 году, а McKinsey прогнозирует 40% прирост производительности от агентского ИИ — технические возможности Sui точно соответствуют макротехнологическим тенденциям, требующим децентрализованной инфраструктуры.

Для организаций, создающих передовые вычислительные приложения на блокчейне, Sui предлагает непревзойденные технические возможности (297K TPS, 480 мс финализация), перспективную квантово-устойчивую архитектуру (единственный блокчейн, разработанный для квантовых вычислений с самого начала), проверенную инфраструктуру робототехники (единственная продемонстрировавшая сотрудничество нескольких роботов), превосходную модель программирования (безопасность и выразительность языка Move) и производительность в реальном времени, позволяющую создавать приложения ИИ/робототехники, физически невозможные на цепочках последовательного выполнения. Платформа представляет собой не инкрементальное улучшение, а фундаментальное архитектурное переосмысление для следующего десятилетия блокчейна.

Блокчейн Sui отличается от конкурентов своей фундаментальной криптографической гибкостью и объектно-ориентированной архитектурой, позиционируя его как единственный крупный блокчейн первого уровня (Layer 1), одновременно продвигающий интеграцию ИИ, координацию робототехники и квантово-устойчивую безопасность. Это не маркетинговое позиционирование, а архитектурная реальность. Соучредитель и главный криптограф Костас «Криптос» Халкиас систематически встраивал эти возможности в базовый дизайн Sui с самого начала, создавая то, что он описывает как инфраструктуру, которая «превзойдет даже Visa по скорости», оставаясь при этом защищенной от квантовых угроз, способных «уничтожить всю современную криптографию» в течение десятилетия.

Техническая основа уже готова к производству: финальность консенсуса в 390 миллисекунд обеспечивает координацию ИИ-агентов в реальном времени, параллельное выполнение обрабатывает 297 000 транзакций в секунду на пике, а схемы подписи EdDSA предоставляют проверенный путь миграции к постквантовой криптографии без необходимости хардфорков. Тем временем Bitcoin и Ethereum сталкиваются с экзистенциальными угрозами со стороны квантовых вычислений без обратно совместимого пути обновления. Видение Халкиаса сосредоточено на трех сходящихся столпах — ИИ как уровне координации, автономных робототехнических системах, требующих финальности менее секунды, и криптографических фреймворках, которые останутся безопасными до 2035 года и далее. Его заявления на конференциях, в исследовательских работах и технических реализациях показывают не спекулятивные обещания, а систематическое выполнение дорожной карты, установленной при основании Mysten Labs в 2022 году.

Это важно не только для блокчейн-трайбализма. К 2030 году мандаты NIST потребуют отказа от текущих стандартов шифрования. Автономные системы, от производственных роботов до ИИ-агентов, будут нуждаться в бездоверительной координации в масштабе. Архитектура Sui одновременно решает обе эти неизбежности, в то время как конкуренты спешат доработать свои решения. Вопрос не в том, сойдутся ли эти технологии, а в том, какие платформы переживут это слияние без потерь.

Криптограф, назвавший сына Криптосом​

Костас Халкиас привносит необычайную авторитетность в пересечение блокчейна с новыми технологиями. До соучредительства Mysten Labs он работал ведущим криптографом в проекте Diem и кошельке Novi компании Meta, сотрудничал с Майком Хирном (одним из первых разработчиков Bitcoin, связанным с Сатоши Накамото) в блокчейне Corda от R3 и имеет докторскую степень по криптографии на основе идентификаторов с более чем 50 научными публикациями, 8 патентами США и 1374 академическими цитированиями. Его преданность этой области простирается до того, что он назвал своего сына Криптосом — «Я настолько глубоко погружен в технологии блокчейна и криптографии, что фактически убедил свою жену назвать ребенка Криптосом», — объяснил он в интервью для блога Sui.

Его карьерный путь демонстрирует постоянное внимание к практической криптографии для массового масштаба. В Facebook он создавал инфраструктуру безопасности для WhatsApp и системы аутентификации, обслуживающие миллиарды пользователей. В R3 он был пионером в области доказательств с нулевым разглашением и постквантовых подписей для корпоративного блокчейна. Его ранняя карьера включала основание Betmanager, платформы на базе ИИ, предсказывающей результаты футбольных матчей с использованием методов фондового рынка — этот опыт повлиял на его текущее видение интеграции блокчейна и ИИ. Такое сочетание опыта в ИИ, производственной криптографии и блокчейн-инфраструктуре уникально позиционирует его для создания систем, объединяющих эти области.

Техническая философия Халкиаса подчеркивает «криптографическую гибкость» — встраивание гибкости в базовые протоколы, а не предположение о постоянстве. На конференции Emergence в Праге (декабрь 2024 года) он сформулировал это мировоззрение: «В конечном итоге блокчейн превзойдет даже Visa по скорости транзакций. Это станет нормой. Я не вижу, как мы можем избежать этого». Но одной скорости недостаточно. Его работа постоянно сочетает производительность с перспективной безопасностью, признавая, что квантовые компьютеры представляют угрозы, требующие действий сегодня, а не тогда, когда опасность материализуется. Этот двойной фокус — текущая производительность и будущая устойчивость — определяет архитектурные решения Sui в области ИИ, робототехники и квантовой устойчивости.

Архитектура, созданная для интеллектуальных агентов​

Техническая основа Sui фундаментально отличается от блокчейнов, основанных на учетных записях, таких как Ethereum и Solana. Каждая сущность существует как объект с глобально уникальным 32-байтовым идентификатором, номером версии, полем владения и типизированным содержимым. Эта объектно-ориентированная модель является не эстетическим предпочтением, а средством обеспечения параллельного выполнения в масштабе. Когда ИИ-агенты работают как принадлежащие им объекты, они полностью обходят консенсус для операций с одним писателем, достигая финальности ~400 мс. Когда несколько агентов координируются через общие объекты, консенсус Mysticeti от Sui обеспечивает задержку в 390 мс — все еще менее секунды, но через византийское отказоустойчивое соглашение.

Язык программирования Move, изначально разработанный в Meta для Diem и усовершенствованный для Sui, обеспечивает безопасность ресурсов на уровне системы типов. Активы не могут быть случайно скопированы, уничтожены или созданы без разрешения. Для ИИ-приложений, управляющих ценными данными или весами моделей, это предотвращает целые классы уязвимостей, поражающих смарт-контракты Solidity. Халкиас подчеркнул это во время Sui Basecamp 2025 в Дубае: «Мы внедрили доказательства с нулевым разглашением, технологии сохранения конфиденциальности в Sui с первого дня. Так что теперь любой может создать систему KYC с такой степенью конфиденциальности, какую он пожелает».

Параллельное выполнение транзакций достигает теоретических пределов благодаря явному объявлению зависимостей. В отличие от оптимистического выполнения, требующего ретроактивной верификации, планировщик Sui заранее идентифицирует непересекающиеся транзакции с помощью уникальных идентификаторов объектов. Независимые операции выполняются одновременно на ядрах валидаторов без помех. Эта архитектура продемонстрировала пиковую пропускную способность 297 000 TPS в ходе тестирования — это не теоретические максимумы, а измеренная производительность на производственном оборудовании. Для ИИ-приложений это означает, что тысячи запросов на вывод обрабатываются одновременно, несколько автономных агентов координируются без блокировки, а принятие решений в реальном времени происходит со скоростью, воспринимаемой человеком.

Протокол консенсуса Mysticeti, представленный в 2024 году, достигает того, что Халкиас и соавторы математически доказали оптимальным: три раунда сообщений для подтверждения. Устранив явную сертификацию блоков и внедрив несертифицированные структуры DAG, Mysticeti сократил задержку на 80% по сравнению с предыдущим консенсусом Narwhal-Bullshark. Протокол подтверждает блоки каждый раунд, а не каждые два раунда, используя прямые и косвенные правила принятия решений, выведенные из паттернов DAG. Для робототехнических приложений, требующих обратной связи в реальном времени, эта финальность менее секунды становится не подлежащей обсуждению. Во время Korea Blockchain Week 2025 Халкиас позиционировал Sui как «уровень координации для приложений и ИИ», подчеркивая, как партнеры в платежах, играх и ИИ используют эту производительную основу.

Walrus: решение проблемы данных ИИ​

Рабочие нагрузки ИИ требуют хранения данных в масштабах, несовместимых с традиционной экономикой блокчейна. Обучающие наборы данных занимают терабайты, веса моделей требуют гигабайтов, а журналы вывода быстро накапливаются. Sui решает эту проблему с помощью Walrus, децентрализованного протокола хранения, использующего кодирование с исправлением ошибок для достижения 4-5-кратной репликации вместо 100-кратной репликации, типичной для внутрицепочечного хранения. Алгоритм «Red Stuff» разбивает данные на фрагменты, распределенные по узлам хранения, оставаясь восстанавливаемым при недоступности 2/3 узлов. Метаданные и доказательства доступности хранятся в блокчейне Sui, в то время как фактические данные находятся в Walrus, создавая криптографически проверяемое хранилище в масштабе эксабайтов.

В течение первого месяца работы тестовой сети Walrus сеть хранила более 4343 ГБ на более чем 25 узлах сообщества, подтверждая жизнеспособность архитектуры. Такие проекты, как TradePort, Tusky и Decrypt Media, интегрировали Walrus для хранения и извлечения медиафайлов. Для ИИ-приложений это позволяет реализовать практические сценарии: обучающие наборы данных токенизируются как программируемые активы с условиями лицензирования, закодированными в смарт-контрактах; веса моделей сохраняются с контролем версий; результаты вывода записываются неизменяемо для аудиторских следов; а контент, сгенерированный ИИ, хранится экономически эффективно. Уровень вывода ИИ Atoma Network, объявленный первым партнером Sui по интеграции блокчейна, использует эту основу хранения для автоматической генерации кода, автоматизации рабочих процессов и анализа рисков DeFi.

Интеграция выходит за рамки хранения данных и распространяется на оркестрацию вычислений. Программируемые блоки транзакций (PTB) Sui объединяют до 1024 разнородных операций атомарно, выполняя их по принципу «все или ничего». Рабочий процесс ИИ может извлекать обучающие данные из Walrus, обновлять веса моделей в смарт-контракте, записывать результаты вывода в блокчейн и распределять вознаграждения среди поставщиков данных — все это в одной атомарной транзакции. Эта компонуемость в сочетании с типовой безопасностью Move создает строительные блоки для сложных ИИ-систем без хрупкости межконтрактных вызовов в других средах.

Халкиас подчеркнул возможности, а не маркетинг, во время подкаста Just The Metrics (июль 2025 года), указав на «неэффективность в управлении медицинскими данными» как на практические области применения. ИИ в здравоохранении требует координации между учреждениями, сохранения конфиденциальности для чувствительных данных и проверяемых вычислений для соблюдения нормативных требований. Архитектура Sui — объединяющая внутрицепочечную координацию, хранилище Walrus и конфиденциальность с нулевым разглашением — решает эти требования технически, а не концептуально. Партнерство с Google Cloud, объявленное в 2024 году, укрепило это направление, интегрировав данные Sui в BigQuery для аналитики и обучив платформу Google Vertex AI на языке Move для разработки с помощью ИИ.

Когда роботам требуется расчет менее чем за секунду​

Видение робототехники материализуется более конкретно через технические возможности, чем через объявленные партнерства. Объектная модель Sui представляет роботов, инструменты и задачи как первоклассных внутрицепочечных граждан с детальным контролем доступа. В отличие от систем, основанных на учетных записях, где роботы взаимодействуют через разрешения на уровне учетной записи, объекты Sui позволяют создавать многоуровневые системы разрешений от базовой операции до полного контроля с требованиями мультиподписи. Интеграция PassKeys и FaceID поддерживает сценарии с участием человека, в то время как zkTunnels обеспечивают передачу команд без газа для удаленного управления в реальном времени.

В ходе обсуждений в социальных сетях Халкиас (публикующий под ником «Kostas Kryptos») рассказал, что инженеры Sui из NASA, Meta и Uber тестируют четвероногих роботов, похожих на собак, в сети. Объектно-ориентированная архитектура подходит для координации робототехники: каждый робот владеет объектами, представляющими его состояние и возможности, задачи существуют как передаваемые объекты с параметрами выполнения, а распределение ресурсов происходит через композицию объектов, а не через централизованную координацию. Производственное предприятие могло бы развернуть флоты роботов, где каждая единица автономно принимает задачи, координируется с коллегами через общие объекты, выполняет операции с криптографической верификацией и осуществляет микроплатежи за оказанные услуги — все это без централизованной власти или вмешательства человека.

Режим транзакций «без интернета», обсуждавшийся во время Sui Basecamp 2025 и подкаста London Real (апрель 2025 года), решает реальные ограничения робототехники. Халкиас описал, как система сохраняла функциональность во время отключений электроэнергии в Испании и Португалии, при этом размеры транзакций были оптимизированы до одного байта с использованием предустановленных форматов. Для автономных систем, работающих в зонах бедствий, сельских районах или средах с ненадежным подключением, эта устойчивость становится критически важной. Роботы могут совершать транзакции peer-to-peer для немедленной координации, синхронизируясь с более широкой сетью при восстановлении подключения.

Проект 3DOS на практике демонстрирует это видение: блокчейн-сеть 3D-печати, обеспечивающая производство по требованию, где машины автономно печатают детали. Будущие итерации предусматривают самовосстанавливающихся роботов, которые обнаруживают отказы компонентов, заказывают замены через смарт-контракты, идентифицируют ближайшие 3D-принтеры через внутрицепочечное обнаружение, координируют печать и доставку, а также устанавливают компоненты — все это автономно. Это не научная фантастика, а логическое расширение существующих возможностей: интеграция микроконтроллеров ESP32 и Arduino уже поддерживает базовые IoT-устройства, BugDar обеспечивает аудит безопасности для робототехнических смарт-контрактов, а одобрения с мультиподписью обеспечивают поэтапную автономию с человеческим контролем для критически важных операций.

Квантовые часы тикают​

Тон Костаса Халкиаса меняется с философского на срочный, когда он обсуждает квантовые вычисления. В исследовательском отчете от июля 2025 года он прямо предупредил: «Правительства хорошо осведомлены о рисках, связанных с квантовыми вычислениями. Агентства по всему миру издали мандаты, согласно которым классические алгоритмы, такие как ECDSA и RSA, должны быть выведены из эксплуатации к 2030 или 2035 году». Его объявление в Twitter сопровождалось прорывным исследованием Mysten Labs, опубликованным в архиве IACR ePrint, демонстрирующим, как блокчейны на основе EdDSA, такие как Sui, Solana, Near и Cosmos, обладают структурными преимуществами для квантового перехода, недоступными для Bitcoin и Ethereum.

Угроза исходит от квантовых компьютеров, выполняющих алгоритм Шора, который эффективно разлагает большие числа — математическую сложность, лежащую в основе криптографии RSA, ECDSA и BLS. Квантовый процессор Google Willow со 105 кубитами сигнализирует об ускоренном прогрессе в создании машин, способных взламывать классическое шифрование. Атака «сохрани сейчас, расшифруй позже» усугубляет срочность: противники собирают зашифрованные данные сегодня, ожидая, пока квантовые компьютеры расшифруют их ретроактивно. Что касается блокчейн-активов, Халкиас объяснил журналу Decrypt: «Даже если кто-то все еще владеет своим приватным ключом Bitcoin или Ethereum, он может быть не в состоянии сгенерировать постквантовое безопасное доказательство владения, и это зависит от того, как этот ключ был изначально сгенерирован и сколько связанных с ним данных было раскрыто со временем».

Особая уязвимость Bitcoin проистекает из «спящих» кошельков с раскрытыми публичными ключами. Приблизительно 1 миллион BTC Сатоши Накамото находится в ранних адресах, использующих формат pay-to-public-key — публичный ключ виден в сети, а не скрыт за хешированными адресами. Как только квантовые компьютеры достигнут достаточного масштаба, эти кошельки станут мгновенно опустошаемыми. Оценка Халкиаса: «Как только появятся квантовые компьютеры, миллионы кошельков, включая кошелек Сатоши, могут быть мгновенно опустошены. Если ваш публичный ключ виден, он в конечном итоге будет взломан». Ethereum сталкивается с аналогичными проблемами, хотя меньшее количество раскрытых публичных ключей снижает непосредственный риск. Обе цепочки требуют общеобщинных хардфорков с беспрецедентной координацией для миграции — при условии формирования консенсуса вокруг постквантовых алгоритмов.

Основа EdDSA от Sui предоставляет элегантный путь отхода. В отличие от случайных приватных ключей ECDSA, EdDSA детерминированно выводит ключи из сида, используя хеш-функции согласно RFC 8032. Это структурное различие позволяет использовать доказательства с нулевым разглашением через zk-STARK (которые являются постквантово-устойчивыми), доказывая знание базового сида без раскрытия данных эллиптической кривой. Пользователи конструируют постквантовые пары ключей из той же случайности сида, представляют ZK-доказательства, демонстрирующие идентичное владение, и переходят к квантово-безопасным схемам, сохраняя адреса — хардфорк не требуется. Халкиас подробно рассказал об этом во время AMA Sui в июне 2022 года: «Если вы используете детерминированные алгоритмы, такие как EdDSA, существует способ с помощью Stark-доказательств подтвердить знание пирамид вашего приватного ключа при генерации ключа EdDSA, потому что он использует хеш-функцию внутри».

Криптографическая гибкость как стратегический ров​

Sui поддерживает несколько схем подписи одновременно через унифицированные псевдонимы типов по всей кодовой базе — EdDSA (Ed25519), ECDSA (для совместимости с Ethereum) и запланированные постквантовые алгоритмы. Халкиас разработал эту «криптографическую гибкость», признавая, что постоянство в криптографии — это фантазия. Архитектура напоминает «смену сердцевины замка», а не перестройку всей системы безопасности. Когда будут развернуты рекомендованные NIST постквантовые алгоритмы — CRYSTALS-Dilithium для подписей, FALCON для компактных альтернатив, SPHINCS+ для схем на основе хешей — Sui интегрирует их посредством простых обновлений, а не фундаментальных переписываний протокола.

Стратегии перехода балансируют между проактивными и адаптивными подходами. Для новых адресов пользователи могут генерировать конфигурации PQ-signs-PreQ, где постквантовые ключи подписывают преквантовые публичные ключи при создании, обеспечивая плавную будущую миграцию. Для существующих адресов метод доказательства zk-STARK сохраняет адреса, доказывая при этом квантово-безопасное владение. Многоуровневая защита приоритизирует ценные данные — приватные ключи кошельков получают немедленную PQ-защиту, в то время как временные данные конфиденциальности следуют по более медленным путям обновления. Выходы хеш-функций расширяются с 256 до 384 бит для устойчивости к коллизиям против алгоритма Гровера, а длины ключей симметричного шифрования удваиваются (AES остается квантово-устойчивым с более крупными ключами).

Системы доказательств с нулевым разглашением требуют тщательного рассмотрения. Линейные PCP, такие как Groth16 (в настоящее время используемые в zkLogin), полагаются на эллиптические кривые, дружественные к спариванию, уязвимые для квантовых атак. Дорожная карта перехода Sui движется к STARK-системам на основе хешей — Winterfell, разработанный Mysten Labs, использует только хеш-функции и остается правдоподобно постквантово-безопасным. Миграция zkLogin сохраняет те же адреса при обновлении внутренних схем, требуя координации с провайдерами OpenID по мере принятия ими токенов PQ-JWT. Маяки случайности и протоколы распределенной генерации ключей переходят от пороговых подписей BLS к альтернативам на основе решеток, таким как схемы HashRand или HERB — внутренние изменения протокола, невидимые для внутрицепочечных API.

Опыт Халкиаса здесь оказывается критически важным. Как автор BPQS (Blockchain Post-Quantum Signature), варианта хеш-схемы XMSS, он привносит опыт реализации, выходящий за рамки теоретических знаний. Его обязательство в июне 2022 года оказалось пророческим: «Мы будем строить нашу цепочку таким образом, чтобы одним нажатием кнопки люди могли фактически перейти на постквантовые ключи». Сроки NIST — 2030 год для прекращения использования классических алгоритмов, 2035 год для полного внедрения PQ — значительно сокращают временные рамки. Ранний старт Sui ставит его в выгодное положение, но Халкиас подчеркивает срочность: «Если ваш блокчейн поддерживает суверенные активы, национальные казначейства в крипто, ETF или CBDC, ему скоро потребуется принять постквантовые криптографические стандарты, если ваше сообщество заботится о долгосрочной надежности и массовом внедрении».

ИИ-агенты уже генерируют ценность в $1,8 миллиарда​

Экосистема выходит за рамки инфраструктуры в производственные приложения. Dolphin Agent (DOLA), специализирующийся на отслеживании и аналитике блокчейн-данных, достиг рыночной капитализации более $1,8 миллиарда — это подтверждает спрос на инструменты блокчейна, улучшенные ИИ. SUI Agents предоставляет развертывание ИИ-агентов в один клик с созданием персоны в Twitter, токенизацией и торговлей в децентрализованных экосистемах. Sentient AI привлек $1,5 миллиона для разговорных чат-ботов, использующих безопасность и масштабируемость Sui. DeSci Agents продвигает научные соединения, такие как Эпиталон и Рапамицин, через круглосуточное взаимодействие, управляемое ИИ, связывая исследования и инвестиции через токенизацию.

Интеграция Atoma Network как первого партнера Sui по выводу ИИ в блокчейне обеспечивает возможности, охватывающие автоматическую генерацию и аудит кода, автоматизацию рабочих процессов, анализ рисков DeFi, генерацию игровых активов, классификацию контента в социальных сетях и управление DAO. Выбор партнерства отражал технические требования: Atoma требовалась низкая задержка для интерактивного ИИ, высокая пропускная способность для масштабирования, безопасное владение ИИ-активами, проверяемые вычисления, экономичное хранение и опции сохранения конфиденциальности. Sui предоставил все шесть. Во время Sui Basecamp 2025 Халкиас выделил такие проекты, как Aeon, ИИ-агенты Atoma и работу Nautilus по проверяемым внецепочечным вычислениям, как примеры того, «как Sui может служить основой для следующей волны интеллектуальных, децентрализованных систем».

Партнерство с Google Cloud углубляет интеграцию через доступ BigQuery к данным блокчейна Sui для аналитики, обучение Vertex AI на языке программирования Move для разработки с помощью ИИ, поддержку zkLogin с использованием учетных данных OAuth (Google) для упрощенного доступа и инфраструктуру, поддерживающую производительность и масштабируемость сети. Интеграция ChainIDE от Alibaba Cloud позволяет использовать запросы на естественном языке для генерации кода Move — разработчики пишут «создать контракт стейкинга с 10% APY» на английском, китайском или корейском языке, получая синтаксически корректный, документированный код Move с проверками безопасности. Эта разработка с помощью ИИ демократизирует создание блокчейна, сохраняя при этом гарантии безопасности Move.

Технические преимущества для ИИ-приложений накапливаются. Модели владения объектами подходят для автономных агентов, работающих независимо. Параллельное выполнение позволяет тысячам одновременных операций ИИ без помех. Финальность менее секунды поддерживает интерактивный пользовательский опыт. Хранилище Walrus экономично обрабатывает обучающие наборы данных. Спонсируемые транзакции устраняют газовые трения для пользователей. zkLogin устраняет барьеры сид-фраз. Программируемые блоки транзакций атомарно оркестрируют сложные рабочие процессы. Опции формальной верификации математически доказывают корректность ИИ-агента. Это не разрозненные функции, а интегрированные возможности, формирующие целостную среду разработки.

Сравнение конкурентов​

Пиковая пропускная способность Sui в 297 000 TPS и задержка консенсуса в 390 мс превосходят среднюю пропускную способность Ethereum в 11,3 TPS и финальность в 12-13 минут на порядки. По сравнению с Solana — ее ближайшим конкурентом по производительности — Sui достигает в 32 раза более быстрой финальности (0,4 секунды против 12,8 секунды), несмотря на 400-миллисекундные слоты Solana, поскольку Solana требует нескольких подтверждений для экономической финальности. Измерения в реальном мире из отчета Phoenix Group за август 2025 года показали, что Sui обрабатывает 3900 TPS против 92,1 TPS Solana, что отражает операционную, а не теоретическую производительность. Стоимость транзакций остается предсказуемо низкой в Sui (в среднем ~$0,0087, менее одного цента) без исторических проблем с перегрузками и сбоями Solana.

Архитектурные различия объясняют разрывы в производительности. Объектно-ориентированная модель Sui обеспечивает внутреннюю параллелизацию — 300 000 простых переводов в секунду не требуют координации консенсуса. Ethereum и Bitcoin обрабатывают каждую транзакцию последовательно через полный консенсус. Solana параллелизует через Sealevel, но использует оптимистическое выполнение, требующее ретроактивной верификации. Aptos, также использующий язык Move, реализует оптимистическое выполнение Block-STM, а не метод доступа к состоянию Sui. Для ИИ и робототехнических приложений, требующих предсказуемо низкой задержки, явное объявление зависимостей Sui обеспечивает детерминизм, который оптимистические подходы не могут гарантировать.

Квантовое позиционирование расходится еще более резко. Bitcoin и Ethereum используют подписи secp256k1 ECDSA без обратно совместимого пути обновления — квантовый переход требует хардфорков, изменения адресов, миграции активов и управления сообществом, что, вероятно, приведет к разделению цепочек. Solana разделяет преимущество EdDSA Sui, позволяя использовать аналогичные стратегии перехода zk-STARK и вводя одноразовые подписи Winternitz Vault на основе хешей. Near и Cosmos также выигрывают от EdDSA. Aptos использует Ed25519, но имеет менее развитую дорожную карту квантовой готовности. В исследовательской работе Халкиаса от июля 2025 года прямо говорится, что результаты «работают для Sui, Solana, Near, Cosmos и других цепочек на основе EdDSA, но не для Bitcoin и Ethereum».

Зрелость экосистемы временно благоприятствует конкурентам. Solana запустилась в 2020 году с устоявшимися протоколами DeFi, NFT-маркетплейсами и сообществами разработчиков. Запуск Ethereum в 2015 году обеспечил преимущества первого хода в смарт-контрактах, институциональном принятии и сетевых эффектах. Sui запустилась в мае 2023 года — ей едва исполнилось два с половиной года — с TVL более $2 миллиардов и 65,9 тысячами активных адресов, быстро растущих, но значительно ниже 16,1 миллиона у Solana. Техническое превосходство создает возможность: разработчики, строящие на Sui сегодня, позиционируют себя для роста экосистемы, а не присоединяются к зрелым, переполненным платформам. Интервью Халкиаса для London Real отразило эту уверенность: «Честно говоря, я ничуть не удивлюсь, если Mysten Labs и все, к чему она прикоснется, превзойдет то, чем является Apple сегодня».

Синергия между, казалось бы, разрозненными видениями​

Нарративы об ИИ, робототехнике и квантовой устойчивости кажутся несвязанными, пока не осознаешь их технические взаимозависимости. ИИ-агентам требуется низкая задержка и высокая пропускная способность — Sui предоставляет и то, и другое. Координация робототехники требует операций в реальном времени без центральной власти — объектная модель Sui и финальность менее секунды обеспечивают это. Постквантовая безопасность нуждается в криптографической гибкости и перспективной архитектуре — Sui построил это с самого начала. Это не отдельные продуктовые линейки, а унифицированные технические требования для технологического ландшафта 2030-2035 годов.

Рассмотрим автономное производство: системы ИИ анализируют прогнозы спроса и доступность материалов, определяя оптимальные графики производства. Роботизированные агенты получают проверенные инструкции через блокчейн-координацию, обеспечивая подлинность без централизованного контроля. Каждый робот работает как принадлежащий ему объект, обрабатывая задачи параллельно, координируясь через общие объекты при необходимости. Микроплатежи мгновенно рассчитываются за оказанные услуги — робот А предоставляет материалы роботу В, робот В обрабатывает компоненты для робота С. Система функционирует без интернета во время сбоев связи, синхронизируясь при восстановлении сетей. И, что критически важно, все коммуникации остаются защищенными от квантовых противников с помощью постквантовых криптографических схем, защищая интеллектуальную собственность и операционные данные от атак «сохрани сейчас, расшифруй позже».

Управление данными в здравоохранении является еще одним примером конвергенции. Модели ИИ обучаются на медицинских наборах данных, хранящихся в Walrus, с криптографическими доказательствами доступности. Доказательства с нулевым разглашением сохраняют конфиденциальность пациентов, одновременно позволяя проводить исследования. Роботизированные хирургические системы координируются через блокчейн для аудиторских следов и документации об ответственности. Постквантовое шифрование защищает конфиденциальные медицинские записи от долгосрочных угроз. Уровень координации (блокчейн Sui) обеспечивает институциональный обмен данными без доверия, вычисления ИИ без ущерба для конфиденциальности и перспективную безопасность без периодической замены инфраструктуры.

Заявление Халкиаса о видении во время Sui Basecamp 2025 отражает этот синтез: позиционирование Sui как «основы для следующей волны интеллектуальных, децентрализованных систем» с «растущей способностью поддерживать ИИ-нативные и ресурсоемкие приложения». Модульная архитектура — Sui для вычислений, Walrus для хранения, Scion для подключения, zkLogin для идентификации — создает то, что члены команды описывают как «операционную систему блокчейна», а не узкий финансовый реестр. Режим без интернета, квантово-безопасная криптография и финальность менее секунды — это не списки функций, а предварительные условия для автономных систем, работающих во враждебных средах с ненадежной инфраструктурой.

Методология инноваций, лежащая в основе технического лидерства​

Понимание подхода Mysten Labs объясняет последовательность выполнения. Халкиас сформулировал философию в своем блоге «Build Beyond»: «Mysten Labs очень хорошо находит новые теории в этой области, которые никто никогда не реализовывал, где некоторые предположения могут быть неточными. Но мы сочетаем это с существующими у нас технологиями, и в конечном итоге это ведет нас к созданию нового продукта». Это описывает систематический процесс: выявление академических исследований с практическим потенциалом, оспаривание непроверенных предположений с помощью инженерной строгости, интеграция с производственными системами и валидация через развертывание.

Протокол консенсуса Mysticeti является примером этого. Академические исследования установили три раунда сообщений как теоретический минимум для подтверждения византийского консенсуса. Предыдущие реализации требовали 1,5 раунда обмена сообщениями с кворумными подписями на блок. Mysten Labs разработала несертифицированные структуры DAG, исключающие явную сертификацию, реализовала оптимальные правила подтверждения через паттерны DAG, а не механизмы голосования, и продемонстрировала сокращение задержки на 80% по сравнению с предыдущим консенсусом Narwhal-Bullshark. Результат: рецензируемая статья с формальными доказательствами, сопровождаемая производственным развертыванием, обрабатывающим миллиарды транзакций.

Аналогичная методология применяется к криптографии. BPQS (постквантовая схема подписи блокчейна Халкиаса) адаптирует хеш-подписи XMSS для ограничений блокчейна. Winterfell реализует первый открытый STARK-доказатель, использующий только хеш-функции для постквантовой безопасности. zkLogin объединяет аутентификацию OAuth с доказательствами с нулевым разглашением, устраняя дополнительных доверенных сторон при сохранении конфиденциальности. Каждая инновация решает практический барьер (постквантовая безопасность, доступность ZK-доказательств, трудности с адаптацией пользователей) посредством новой криптографической конструкции, подкрепленной формальным анализом.

Состав команды усиливает эту способность. Инженеры из Meta создавали аутентификацию для миллиардов, из NASA разрабатывали критически важные распределенные системы, из Uber масштабировали координацию в реальном времени по всему миру. Халкиас привносит криптографический опыт из Facebook/Diem, R3/Corda и академических исследований. Это не традиционная стартап-команда, обучающаяся на ходу, а ветераны, реализующие системы, которые они строили раньше, теперь не ограниченные корпоративными приоритетами. Финансирование в размере $336 миллионов от a16z, Coinbase Ventures и Binance Labs отражает уверенность инвесторов в способности к реализации, а не в спекулятивных технологиях.

Вызовы и соображения за пределами хайпа​

Техническое превосходство не гарантирует принятия рынком — урок, многократно усвоенный в истории технологий. 65,9 тыс. активных адресов Sui меркнут на фоне 16,1 миллиона у Solana, несмотря на, возможно, лучшую технологию. Сетевые эффекты накапливаются: разработчики строят там, где собираются пользователи, пользователи приходят туда, где существуют приложения, создавая преимущества блокировки для устоявшихся платформ. «Медленный и дорогой» блокчейн Ethereum привлекает на порядки больше внимания разработчиков, чем технически превосходящие альтернативы, благодаря своей чистой инерции.

Позиционирование как «операционной системы блокчейна» рискует размыванием — попытка преуспеть одновременно в финансах, социальных приложениях, играх, ИИ, робототехнике, IoT и децентрализованном хранении может привести к посредственности во всех областях, а не к превосходству в одной. Критики, отмечающие эту озабоченность, указывают на ограниченное развертывание робототехники за пределами доказательств концепции, проекты ИИ в основном на стадии спекуляций, а не производственной полезности, и подготовку квантовой безопасности к угрозам, отдаленным на пять-десять лет. Контраргумент состоит в том, что модульные компоненты позволяют сосредоточенно развиваться — команды, создающие ИИ-приложения, используют вывод Atoma и хранилище Walrus, не беспокоясь об интеграции робототехники.

Постквантовая криптография вводит нетривиальные накладные расходы. Подписи CRYSTALS-Dilithium составляют 3293 байта на уровне безопасности 2 против 64 байт Ed25519 — более чем в 50 раз больше. Пропускная способность сети, затраты на хранение и время обработки увеличиваются пропорционально. Улучшения пакетной верификации остаются ограниченными (ускорение на 20-50% по сравнению с независимой верификацией) по сравнению с эффективной пакетной обработкой классических схем. Риски миграции включают ошибки пользователей во время перехода, координацию между участниками экосистемы (кошельки, dApps, биржи), требования обратной совместимости и трудности тестирования в масштабе без реальных квантовых компьютеров. Неопределенность сроков усугубляет проблемы планирования — прогресс квантовых вычислений остается непредсказуемым, стандарты NIST продолжают развиваться, и могут появиться новые криптоаналитические атаки против PQ-схем.

Рыночное время, возможно, представляет наибольший риск. Преимущества Sui наиболее ярко проявляются в период 2030-2035 годов: когда квантовые компьютеры угрожают классической криптографии, когда автономные системы распространяются, требуя бездоверительной координации, когда ИИ-агенты управляют значительной экономической ценностью, требующей безопасной инфраструктуры. Если принятие блокчейна застопорится до этой конвергенции, техническое лидерство станет неактуальным. И наоборот, если принятие ускорится раньше, новой экосистеме Sui может не хватать приложений и ликвидности для привлечения пользователей, несмотря на превосходную производительность. Инвестиционный тезис требует веры не только в технологию Sui, но и в совпадение сроков между созреванием блокчейна и принятием новых технологий.

Десятилетняя ставка на первые принципы​

Называние Костасом Халкиасом своего сына Криптосом — это не просто милая история, а сигнал о глубине его приверженности. Его карьерный путь — от исследований в области ИИ до криптографии, от академических публикаций до производственных систем в Meta, от корпоративного блокчейна в R3 до архитектуры Layer 1 в Mysten Labs — демонстрирует постоянное внимание к фундаментальным технологиям в масштабе. Работа по квантовой устойчивости началась до объявления Google о Willow, когда постквантовая криптография казалась теоретической проблемой. Интеграция робототехники началась до того, как ИИ-агенты получили миллиардные оценки. Архитектурные решения, обеспечивающие эти возможности, предшествовали признанию рынком их важности.

Эта дальновидная ориентация контрастирует с реактивной разработкой, распространенной в криптоиндустрии. Ethereum внедряет Layer 2 роллапы для решения проблем масштабирования, возникающих после развертывания. Solana реализует связь QUIC и QoS, взвешенную по стейку, в ответ на сбои и перегрузки сети. Bitcoin обсуждает увеличение размера блока и внедрение Lightning Network по мере роста комиссий за транзакции. Sui разработал параллельное выполнение, объектно-ориентированные модели данных и криптографическую гибкость до запуска основной сети — решая ожидаемые требования, а не обнаруженные проблемы.

Культура исследований подкрепляет этот подход. Mysten Labs публикует академические статьи с формальными доказательствами, прежде чем заявлять о возможностях. Статья о консенсусе Mysticeti появилась в рецензируемых изданиях с доказательствами корректности и эталонными показателями производительности. Исследование квантового перехода, представленное в архив IACR ePrint, демонстрирует преимущества EdDSA посредством математического построения, а не маркетинговых заявлений. Статья о zkLogin (arXiv 2401.11735) подробно описывает аутентификацию с нулевым разглашением до развертывания. Халкиас активно участвует в GitHub (kchalkias), публикует технические обзоры в LinkedIn и Twitter, выступает на семинарах PQCSA по квантовым угрозам и предметно взаимодействует с криптографическим сообществом, а не исключительно продвигает Sui.

Окончательное подтверждение придет через 5-10 лет, когда квантовые компьютеры созреют, автономные системы распространятся, а ИИ-агенты будут управлять экономиками на триллионы долларов. Если Sui последовательно выполнит свою дорожную карту — развернет постквантовые подписи до крайнего срока NIST 2030 года, продемонстрирует координацию робототехники в масштабе и поддержит уровни вывода ИИ, обрабатывающие миллионы запросов — он станет инфраструктурным уровнем для технологий, преобразующих цивилизацию. Если квантовые компьютеры появятся позже, чем предсказывалось, автономное внедрение застопорится, или конкуренты успешно доработают решения, ранние инвестиции Sui могут оказаться преждевременными. Ставка сосредоточена не на технологических возможностях — Sui явно обеспечивает обещанную производительность — а на рыночном времени и срочности проблемы.

Перспектива Халкиаса, высказанная на конференции Emergence, кратко формулирует это: «В конечном итоге блокчейн превзойдет даже Visa по скорости транзакций. Это станет нормой. Я не вижу, как мы можем избежать этого». Заявление о неизбежности предполагает правильное техническое направление, достаточное качество исполнения и согласованность по времени. Sui позиционирует себя так, чтобы извлечь выгоду, если эти предположения подтвердятся. Объектно-ориентированная архитектура, криптографическая гибкость, финальность менее секунды и систематическая методология исследований — это не доработки, а фундаментальные решения, разработанные для технологического ландшафта, формирующегося в течение следующего десятилетия. Независимо от того, захватит ли Sui лидерство на рынке или эти возможности станут базовыми для всех блокчейнов, Костас Халкиас и Mysten Labs создают инфраструктуру для автономного интеллекта квантовой эры — по одному криптографическому примитиву, по одной миллисекунде сокращения задержки, по одному демонстрационному роботу за раз.

В быстро сближающихся мирах искусственного интеллекта и блокчейна спрос на доверие и прозрачность никогда не был таким высоким. Как мы можем быть уверены, что результат работы модели ИИ точен и не подвергался изменениям? Как мы можем выполнять сложные вычисления на огромных ончейн-наборах данных без ущерба для безопасности или масштабируемости? Lagrange Labs решает эти вопросы напрямую с помощью своего набора инфраструктуры с нулевым разглашением (ZK), стремясь построить будущее "ИИ, который можно доказать". Этот пост представляет объективный обзор их миссии, технологий и недавних прорывов, кульминацией которых стала их последняя статья о динамических zk-SNARKs.

1. Команда и ее миссия​

Lagrange Labs создает базовую инфраструктуру для генерации криптографических доказательств для любого вывода ИИ или ончейн-приложения. Их цель — сделать вычисления проверяемыми, привнося новый уровень доверия в цифровой мир. Их экосистема построена на трех основных продуктовых линейках:

• Сеть ZK-доказателей: Децентрализованная сеть из более чем 85 узлов-доказателей, которая обеспечивает вычислительную мощность, необходимую для широкого спектра задач доказательства, от ИИ и роллапов до децентрализованных приложений (dApps).
• DeepProve (zkML): Специализированная система для генерации ZK-доказательств выводов нейронных сетей. Lagrange утверждает, что она до 158 раз быстрее конкурирующих решений, что делает проверяемый ИИ практической реальностью.
• ZK-сопроцессор 1.0: Первый ZK-сопроцессор на основе SQL, позволяющий разработчикам выполнять пользовательские запросы к массивным ончейн-наборам данных и получать проверяемо точные результаты.

2. Дорожная карта к проверяемому ИИ​

Lagrange методично реализует дорожную карту, разработанную для поэтапного решения проблем проверяемости ИИ.

• 3 квартал 2024 г.: Запуск ZK-сопроцессора 1.0: Этот релиз представил гиперпараллельные рекурсивные схемы, которые обеспечили среднее увеличение скорости примерно в 2 раза. Такие проекты, как Azuki и Gearbox, уже используют сопроцессор для своих потребностей в ончейн-данных.
• 1 квартал 2025 г.: Представление DeepProve: Lagrange анонсировала DeepProve, свое решение для машинного обучения с нулевым разглашением (zkML). Оно поддерживает популярные архитектуры нейронных сетей, такие как многослойные перцептроны (MLP) и сверточные нейронные сети (CNN). Система достигает значительного, на порядок, ускорения на всех трех критических этапах: однократная настройка, генерация доказательства и верификация, при этом ускорение достигает 158x.
• 2 квартал 2025 г.: Статья о динамических zk-SNARKs (Последняя веха): Эта статья представляет новаторский алгоритм "обновления". Вместо повторной генерации доказательства с нуля каждый раз, когда изменяются базовые данные или вычисления, этот метод может "заплатать" старое доказательство (π) в новое доказательство (π'). Это обновление может быть выполнено со сложностью всего O(√n log³n), что является значительным улучшением по сравнению с полной перегенерацией. Это нововведение особенно подходит для динамических систем, таких как постоянно обучающиеся модели ИИ, игровая логика в реальном времени и развивающиеся смарт-контракты.

3. Почему динамические zk-SNARKs важны​

Введение обновляемых доказательств представляет собой фундаментальный сдвиг в модели затрат технологии с нулевым разглашением.

• Новая парадигма затрат: Отрасль переходит от модели "полной перегенерации для каждого доказательства" к "инкрементальному доказательству, основанному на размере изменения". Это значительно снижает вычислительные и финансовые затраты для приложений, которые часто подвергаются незначительным обновлениям.

• Последствия для ИИ:

  • Непрерывная донастройка: При донастройке менее 1% параметров модели время генерации доказательства растет почти линейно с количеством измененных параметров (Δ параметров), а не с общим размером модели.
  • Потоковый вывод: Это позволяет генерировать доказательства одновременно с самим процессом вывода. Это значительно сокращает задержку между принятием решения ИИ и его фиксацией и верификацией в блокчейне, открывая такие варианты использования, как ончейн-сервисы ИИ и сжатые доказательства для роллапов.

• Последствия для ончейн-приложений:

  • Динамические zk-SNARKs предлагают огромную оптимизацию газа и времени для приложений, характеризующихся частыми, небольшими изменениями состояния. Это включает книги ордеров децентрализованных бирж (DEX), развивающиеся игровые состояния и обновления реестра, включающие частые добавления или удаления.

4. Взгляд на технологический стек​

Мощная инфраструктура Lagrange построена на сложном и интегрированном технологическом стеке:

• Проектирование схем: Система является гибкой, поддерживая встраивание моделей ONNX (Open Neural Network Exchange), SQL-парсеров и пользовательских операторов непосредственно в свои схемы.
• Рекурсия и параллелизм: Сеть ZK-доказателей облегчает распределенные рекурсивные доказательства, в то время как ZK-сопроцессор использует шардинг "микросхем" для параллельного выполнения задач, максимизируя эффективность.
• Экономические стимулы: Lagrange планирует запустить нативный токен LA, который будет интегрирован в систему двойного аукциона для рекурсивного аукциона (DARA). Это создаст надежный рынок для торгов за вычисления доказателей, дополненный стимулами и штрафами для обеспечения целостности сети.

5. Экосистема и реальное внедрение​

Lagrange не просто строит в вакууме; ее технология уже интегрируется растущим числом проектов в различных секторах:

• ИИ и МО: Такие проекты, как 0G Labs и Story Protocol, используют DeepProve для верификации результатов своих моделей ИИ, обеспечивая происхождение и доверие.
• Роллапы и инфраструктура: Ключевые игроки, такие как EigenLayer, Base и Arbitrum, участвуют в сети ZK-доказателей в качестве узлов валидации или партнеров по интеграции, способствуя ее безопасности и вычислительной мощности.
• Приложения NFT и DeFi: Такие бренды, как Azuki, и протоколы DeFi, такие как Gearbox, используют ZK-сопроцессор для повышения достоверности своих запросов данных и механизмов распределения вознаграждений.

6. Вызовы и путь вперед​

Несмотря на впечатляющий прогресс, Lagrange Labs и более широкая область ZK сталкиваются с рядом препятствий:

• Аппаратные узкие места: Даже при наличии распределенной сети обновляемые SNARKs по-прежнему требуют высокой пропускной способности и полагаются на криптографические кривые, дружественные к GPU, для эффективной работы.
• Отсутствие стандартизации: Процесс сопоставления фреймворков ИИ, таких как ONNX и PyTorch, с ZK-схемами по-прежнему не имеет универсального, стандартизированного интерфейса, что создает трудности для разработчиков.
• Конкурентная среда: Гонка за создание zkVM и обобщенных платформ zkCompute набирает обороты. Конкуренты, такие как Risc-Zero и Succinct, также добиваются значительных успехов. В конечном итоге победителем может стать тот, кто первым сможет коммерциализировать удобный для разработчиков, управляемый сообществом набор инструментов.

7. Заключение​

Lagrange Labs методично меняет пересечение ИИ и блокчейна через призму проверяемости. Их подход предлагает комплексное решение:

• DeepProve решает проблему доверенного вывода.
• ZK-сопроцессор решает проблему доверенных данных.
• Динамические zk-SNARKs напрямую включают потребность реального мира в непрерывных обновлениях в систему доказательства.

Если Lagrange сможет сохранить свое преимущество в производительности, решить критическую проблему стандартизации и продолжить развивать свою надежную сеть, она имеет хорошие шансы стать краеугольным камнем в развивающемся секторе "ИИ + ZK-инфраструктуры".

title: Сеть MPC Ika при поддержке Sui — Комплексная техническая и инвестиционная оценка description: Подробная оценка Ika (ранее dWallet Network) — параллельной сети MPC при поддержке Sui Foundation, ориентированная на архитектуру 2PC-MPC, производительность и кроссчейн-возможности. keywords:

• Сеть Ika
• блокчейн Sui
• MPC
• многосторонние вычисления
• кроссчейн
• интероперабельность
• инфраструктура блокчейна
• Web3
• dWallet
• 2PC-MPC
• пороговые подписи
• криптография
• инвестиционный анализ
• валидаторы узлов tags: [blockchain, web3, sui, mpc, infrastructure, interoperability] image: "https://opengraph-image.blockeden.xyz/api/og-blockeden-xyz?title=%D0%A1%D0%B5%D1%82%D1%8C%20MPC%20Ika%20%D0%BF%D1%80%D0%B8%20%D0%BF%D0%BE%D0%B4%D0%B4%D0%B5%D1%80%D0%B6%D0%BA%D0%B5%20Sui%20%E2%80%94%20%D0%9A%D0%BE%D0%BC%D0%BF%D0%BB%D0%B5%D0%BA%D1%81%D0%BD%D0%B0%D1%8F%20%D1%82%D0%B5%D1%85%D0%BD%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B0%D1%8F%20%D0%B8%20%D0%B8%D0%BD%D0%B2%D0%B5%D1%81%D1%82%D0%B8%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D0%B0%D1%8F%20%D0%BE%D1%86%D0%B5%D0%BD%D0%BA%D0%B0%22%0A%0A%23%20%D0%A1%D0%B5%D1%82%D1%8C%20MPC%20Ika%20%D0%BF%D1%80%D0%B8%20%D0%BF%D0%BE%D0%B4%D0%B4%D0%B5%D1%80%D0%B6%D0%BA%D0%B5%20Sui%20%E2%80%94%20%D0%9A%D0%BE%D0%BC%D0%BF%D0%BB%D0%B5%D0%BA%D1%81%D0%BD%D0%B0%D1%8F%20%D1%82%D0%B5%D1%85%D0%BD%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B0%D1%8F%20%D0%B8%20%D0%B8%D0%BD%D0%B2%D0%B5%D1%81%D1%82%D0%B8%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D0%B0%D1%8F%20%D0%BE%D1%86%D0%B5%D0%BD%D0%BA%D0%B0%0A%0A%23%23%20%D0%92%D0%B2%D0%B5%D0%B4%D0%B5%D0%BD%D0%B8%D0%B5%0A%0AIka%20%E2%80%94%20%D1%8D%D1%82%D0%BE%20**%D1%81%D0%B5%D1%82%D1%8C%20%D0%BF%D0%B0%D1%80%D0%B0%D0%BB%D0%BB%D0%B5%D0%BB%D1%8C%D0%BD%D1%8B%D1%85%20%D0%BC%D0%BD%D0%BE%D0%B3%D0%BE%D1%81%D1%82%D0%BE%D1%80%D0%BE%D0%BD%D0%BD%D0%B8%D1%85%20%D0%B2%D1%8B%D1%87%D0%B8%D1%81%D0%BB%D0%B5%D0%BD%D0%B8%D0%B9%20(MPC)**, стратегически поддерживаемая Sui Foundation. Ранее известная как dWallet Network, Ika разработана для обеспечения кроссчейн-интероперабельности с нулевым доверием (zero-trust) на высокой скорости и в больших масштабах. Она позволяет смарт-контрактам (особенно в блокчейне Sui) безопасно контролировать и координировать активы в других блокчейнах без использования традиционных мостов. В данном отчете представлен глубокий анализ технической архитектуры и криптографического дизайна Ika с точки зрения основателя, а также бизнес- и инвестиционный анализ, охватывающий команду, финансирование, токеномику, принятие и конкуренцию. Для контекста также включена сводная таблица сравнения Ika с другими сетями на базе MPC (Lit Protocol, Threshold Network и Zama).

Техническая архитектура и особенности (точка зрения основателя)​

Архитектура и криптографические примитивы​

Основная инновация Ika — это новая криптографическая схема «2PC-MPC» — двухсторонние вычисления внутри структуры многосторонних вычислений. Проще говоря, в процессе подписания всегда участвуют две стороны: (1) пользователь и (2) сеть Ika. Пользователь владеет долей закрытого ключа, а сеть, состоящая из множества независимых узлов, владеет другой долей. Подпись может быть создана только при участии обеих сторон, что гарантирует: сеть сама по себе никогда не сможет подделать подпись без участия пользователя. Сторона сети — это не единый субъект, а распределенная MPC среди N валидаторов, которые коллективно действуют как вторая сторона. Для генерации сетевой доли подписи необходимо согласие порога как минимум в две трети этих узлов (аналогично консенсусу Byzantine Fault Tolerance). Эта вложенная структура MPC (пользователь + сеть) делает Ika защищенной от сговора: даже если все узлы Ika вступят в сговор, они не смогут украсть активы пользователя, поскольку участие пользователя (его доля ключа) всегда криптографически необходимо. Другими словами, Ika обеспечивает безопасность «с нулевым доверием», поддерживая принципы децентрализации и владения пользователем, характерные для Web3 — ни одна организация или небольшая группа не может в одностороннем порядке скомпрометировать активы.

Рисунок: Схема архитектуры 2PC-MPC в Ika — пользователь выступает как одна сторона (владея долей закрытого ключа), а сеть Ika из N валидаторов формирует другую сторону через протокол пороговой MPC (t-из-N). Это гарантирует, что для создания действительной подписи должны сотрудничать и пользователь, и подавляющее большинство децентрализованных узлов.

Технически Ika реализована как автономная блокчейн-сеть, ответвленная от кодовой базы Sui. Она запускает собственный экземпляр высокопроизводительного движка консенсуса Sui (Mysticeti, BFT-протокол на основе DAG) для координации узлов MPC. Примечательно, что в версии Sui для Ika отключены смарт-контракты (цепочка Ika существует исключительно для работы протокола MPC) и включены пользовательские модули для алгоритма подписи 2PC-MPC. Mysticeti обеспечивает надежный канал вещания между узлами, заменяя сложную сеть одноранговых сообщений, используемую традиционными протоколами MPC. Используя консенсус на основе DAG для связи, Ika избегает экспоненциальных накладных расходов на связь, характерных для ранних схем пороговой подписи, где каждой из n сторон требовалось отправлять сообщения всем остальным. Вместо этого узлы Ika транслируют сообщения через консенсус, достигая линейной сложности связи O(n) и используя методы пакетирования и агрегации, чтобы затраты на узел оставались почти постоянными даже при значительном росте N. Это представляет собой значительный прорыв в пороговой криптографии: команда Ika заменила связь «точка-точка» (unicast) эффективным вещанием и агрегацией, что позволяет протоколу поддерживать сотни или тысячи участников без замедления.

Интеграция с нулевым разглашением (Zero-knowledge): На данный момент безопасность Ika достигается за счет пороговой криптографии и консенсуса BFT, а не явных доказательств с нулевым разглашением. Система не полагается на zk-SNARK или zk-STARK в своем основном процессе подписания. Однако Ika использует ончейн доказательства состояния (доказательства легкого клиента) для проверки событий из других цепочек, что является формой криптографической верификации (например, проверка доказательств Меркла для заголовков блоков или состояния). Дизайн оставляет место для интеграции методов нулевого разглашения в будущем — например, для проверки кроссчейн-состояния или условий без раскрытия конфиденциальных данных — но по состоянию на 2025 год ни один конкретный модуль zk-SNARK не является частью опубликованной архитектуры Ika. Основное внимание уделяется принципу «нулевого доверия» (отсутствие предположений о доверии) через схему 2PC-MPC, а не системам доказательств с нулевым разглашением.

Производительность и масштабируемость​

Основная цель Ika — преодолеть узкие места в производительности предыдущих сетей MPC. Устаревшие протоколы пороговой подписи (такие как Lindell’s 2PC ECDSA или GG20) с трудом поддерживали более нескольких участников, часто требуя многих секунд или минут для создания одной подписи. Напротив, оптимизированный протокол Ika обеспечивает субсекундную задержку при подписании и может обрабатывать очень высокую пропускную способность запросов на подпись параллельно. Заявленные тесты производительности указывают на то, что Ika может масштабироваться примерно до 10 000 подписей в секунду, сохраняя при этом безопасность в большом кластере узлов. Это возможно благодаря упомянутой линейной связи и активному использованию пакетирования: сеть может одновременно генерировать множество подписей за один раунд протокола, значительно снижая средние затраты. По словам команды, Ika может быть в 10 000 раз быстрее, чем существующие сети MPC под нагрузкой. На практике это означает, что высокочастотные транзакции в реальном времени (такие как торговля или кроссчейн-операции DeFi) могут поддерживаться без обычных задержек порогового подписания. Задержка находится на уровне субсекундной финальности, что означает, что подпись (и соответствующая кроссчейн-операция) может быть завершена почти мгновенно после запроса пользователя.

Не менее важно и то, что Ika достигает этого, увеличивая количество подписантов для усиления децентрализации. Традиционные системы MPC часто использовали фиксированный комитет из 10–20 узлов, чтобы избежать падения производительности. Архитектура Ika может расширяться до сотен или даже тысяч валидаторов, участвующих в процессе подписания без значительного замедления. Такая массовая децентрализация повышает безопасность (злоумышленнику сложнее подкупить большинство) и надежность сети. Лежащий в основе консенсус является византийски отказоустойчивым, поэтому сеть может выдержать компрометацию или отключение до одной трети узлов и продолжать корректно функционировать. В любой конкретной операции подписания активно участвовать должен только порог t-из-N узлов (например, 67% от N); по дизайну, если слишком много узлов отключено, подпись может быть задержана, но система спроектирована так, чтобы корректно обрабатывать типичные сценарии сбоев (аналогично свойствам живучести и безопасности консенсуса блокчейна). Таким образом, 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, разработчики могут генерировать пары ключей, регистрировать доли пользователей и вызывать RPC Ika для координации пороговых подписей — и все это с использованием привычных паттернов API Sui. SDK абстрагирует сложность протокола MPC, делая процесс таким же простым, как вызов функции для запроса (например) подписи транзакции Bitcoin при наличии соответствующего контекста и одобрения пользователя.

• CLI и локальная сеть: Для более прямого взаимодействия доступен интерфейс командной строки (CLI) под названием dWallet CLI. Разработчики могут запустить локальный узел Ika или даже локальную тестовую сеть, создав форк открытого репозитория. Это ценно для тестирования и интеграции в среде разработки. Документация содержит руководства по настройке локальной сети devnet, получению токенов testnet (DWLT — токен тестовой сети) и созданию первого адреса dWallet.

• Документация и примеры: Документация Ika включает пошаговые руководства для распространенных сценариев, таких как «Ваш первый dWallet». В них показано, как создать dWallet, соответствующий адресу в другой цепочке (например, адрес Bitcoin, контролируемый ключами Ika), как зашифровать долю ключа пользователя для безопасного хранения и как инициировать кроссчейн-транзакции. Примеры кода охватывают такие случаи использования, как перевод BTC через вызов смарт-контракта Sui или планирование будущих транзакций (функция, поддерживаемая Ika, позволяющая предварительно подписывать транзакцию при определенных условиях).

• Интеграция с Sui (легкие клиенты): «Из коробки» Ika тесно интегрирована с блокчейном Sui. Сеть Ika внутри себя запускает легкий клиент Sui для бездоверительного чтения данных ончейн Sui. Это означает, что смарт-контракт Sui может сгенерировать событие или вызов, который Ika распознает (через доказательство состояния) как триггер для выполнения действия. Например, контракт Sui может дать указание Ika: «когда произойдет событие X, подпиши и транслируй транзакцию в Ethereum». Узлы Ika проверят событие Sui с помощью доказательства легкого клиента, а затем коллективно создадут подпись для транзакции Ethereum. Подписанные данные затем могут быть доставлены в целевую цепочку (возможно, оффчейн-релейером или пользователем) для выполнения желаемого действия. В настоящее время Sui является первой полностью поддерживаемой управляющей цепочкой (учитывая происхождение Ika на Sui), но архитектура мультичейн-ориентирована по дизайну. Поддержка доказательств состояния и интеграций других цепочек находится в дорожной карте — например, команда упоминала расширение Ika для работы с роллапами в экосистеме Polygon Avail (предоставление возможностей dWallet для роллапов с Avail в качестве уровня данных) и другими Layer-1 в будущем.

• Поддерживаемые криптографические алгоритмы: Сеть Ika может генерировать ключи/подписи для практически любой схемы подписи любого блокчейна. Изначально она поддерживает ECDSA (алгоритм на эллиптических кривых, используемый Bitcoin, аккаунтами Ethereum ECDSA, BNB Chain и т. д.). В ближайшей перспективе планируется поддержка EdDSA (Ed25519, используемый такими цепочками, как Solana и некоторые цепочки Cosmos) и подписей Шнорра (например, ключи Schnorr в Bitcoin Taproot). Эта широкая поддержка означает, что один dWallet Ika может иметь адрес в Bitcoin, адрес в Ethereum, в Solana и так далее — и все они будут контролироваться одним и тем же базовым распределенным ключом. Таким образом, разработчики на Sui или других платформах могут интегрировать любую из этих цепочек в свои dApps через одну унифицированную структуру (Ika) вместо того, чтобы иметь дело со специфическими для каждой цепочки мостами или кастодианами.

Подводя итог, Ika предлагает опыт разработки, аналогичный взаимодействию с узлом блокчейна или кошельком, абстрагируясь от сложной криптографии. Будь то через TypeScript SDK или напрямую через контракты Move и легкие клиенты, она стремится сделать кроссчейн-логику готовой к использованию (plug-and-play) для разработчиков.

Безопасность, децентрализация и отказоустойчивость​

Безопасность имеет первостепенное значение в дизайне Ika. Модель с нулевым доверием означает, что ни одному пользователю не нужно доверять сети Ika единоличный контроль над активами в любой момент времени. Если пользователь создает dWallet (скажем, адрес BTC под управлением Ika), закрытый ключ этого адреса никогда не удерживается какой-либо одной стороной — даже самим пользователем в одиночку. Вместо этого пользователь владеет секретной долей, а сеть коллективно владеет другой долей. Для подписания любой транзакции требуются обе доли. Таким образом, даже если произойдет худший сценарий (например, многие узлы Ika будут скомпрометированы злоумышленником), они все равно не смогут переместить средства без секретной доли ключа пользователя. Это свойство устраняет серьезный риск, характерный для обычных мостов, где кворум валидаторов может вступить в сговор для кражи заблокированных активов. Ika устраняет этот риск, фундаментально меняя структуру доступа (порог установлен таким образом, что одной сети никогда недостаточно — порог фактически включает в себя пользователя). В литературе это новая парадигма: сеть MPC, защищенная от сговора, где владелец актива по дизайну остается частью кворума подписантов.

На стороне сети Ika использует модель делегированного Proof-of-Stake (унаследованную от дизайна Sui) для выбора и стимулирования валидаторов. Держатели токенов IKA могут делегировать стейк узлам-валидаторам; лучшие валидаторы (взвешенные по стейку) становятся авторитетами на время эпохи и являются византийски отказоустойчивыми (2/3 честных) в каждой эпохе. Это означает, что система предполагает, что менее 33% стейка является вредоносным для обеспечения безопасности. Если валидатор ведет себя недобросовестно (например, пытается создать неверную долю подписи или цензурировать транзакции), консенсус и протокол MPC обнаружат это — неверные доли подписи могут быть идентифицированы (они не объединятся в действительную подпись), а вредоносный узел может быть занесен в журнал и потенциально подвергнут слэшингу или удален в будущих эпохах. Между тем, живучесть сохраняется до тех пор, пока участвует достаточное количество узлов (>67%); консенсус может продолжать финализировать операции, даже если многие узлы неожиданно выйдут из строя или отключатся. Такая отказоустойчивость гарантирует надежность сервиса — единой точки отказа не существует, так как в нем участвуют сотни независимых операторов в разных юрисдикциях. Децентрализация дополнительно усиливается огромным количеством участников: Ika не ограничивается фиксированным небольшим комитетом, поэтому она может подключать больше валидаторов для повышения безопасности без ущерба для производительности. Фактически, протокол Ika был специально разработан, чтобы «превзойти лимит узлов сетей MPC» и обеспечить массовую децентрализацию.

Наконец, команда Ika представила свою криптографию для внешнего обзора. В 2024 году они опубликовали подробный whitepaper с описанием протокола 2PC-MPC и на данный момент прошли как минимум один аудит безопасности сторонней организацией. Например, в июне 2024 года аудит компании Symbolic Software изучил реализацию протокола 2PC-MPC на Rust и связанные с ним криптобиблиотеки Ika. Аудит был сосредоточен на проверке правильности криптографических протоколов (гарантия отсутствия недостатков в схеме порогового ECDSA, генерации ключей или агрегации долей) и проверке потенциальных уязвимостей. Код является открытым (в GitHub dWallet Labs), что позволяет сообществу проверять его и вносить вклад в его безопасность. На стадии альфа-тестирования команда также предупредила, что программное обеспечение все еще является экспериментальным и еще не прошло аудит для промышленной эксплуатации, но текущие аудиты и улучшения безопасности были главным приоритетом перед запуском основной сети. Таким образом, модель безопасности Ika представляет собой сочетание доказуемых криптографических гарантий (из пороговых схем) и децентрализации уровня блокчейна (из консенсуса PoS и большого набора валидаторов), проверенных экспертами для обеспечения надежной защиты как от внешних злоумышленников, так и от внутреннего сговора.

Совместимость и интероперабельность экосистемы​

Ika специально создана для использования в качестве уровня интероперабельности, изначально для Sui, но с возможностью расширения на многие другие экосистемы. С первого дня ее самая тесная интеграция реализована с блокчейном Sui: она фактически выступает как дополнительный модуль к Sui, расширяя возможности dApps на базе Sui мультичейн-функциями. Такое тесное взаимодействие не случайно — контракты Move в Sui и объектно-ориентированная модель делают его хорошим «контроллером» для dWallets Ika. Например, DeFi-приложение на Sui может использовать Ika для мгновенного привлечения ликвидности из Ethereum или Bitcoin, превращая Sui в хаб для мультичейн-ликвидности. Поддержка Ika со стороны Sui Foundation указывает на стратегию позиционирования Sui как «базовой цепочки для каждой цепочки», использующей Ika для подключения к внешним активам. На практике, когда основная сеть Ika будет запущена, разработчик на Sui сможет создать контракт Move, который, скажем, принимает депозиты BTC: за кулисами этот контракт создаст dWallet Bitcoin (адрес) через Ika и будет выдавать инструкции на перемещение BTC при необходимости. Конечный пользователь воспринимает это так, как если бы Bitcoin был просто еще одним активом, управляемым внутри приложения Sui, хотя BTC остается нативным в сети Bitcoin до тех пор, пока транзакция, подписанная пороговой подписью, не переместит его.

Помимо Sui, архитектура Ika поддерживает другие блокчейны Layer-1, Layer-2 и даже оффчейн-системы. Сеть может одновременно содержать несколько легких клиентов, поэтому она может проверять состояние Ethereum, Solana, Avalanche или других сетей, позволяя смарт-контрактам в этих цепочках (или их пользователям) также использовать сеть MPC Ika. Хотя такие возможности могут внедряться постепенно, целью дизайна является чейн-агностичность. В промежуточный период, даже без глубокой ончейн-интеграции, Ika может использоваться более ручным способом: например, приложение на Ethereum может вызывать API Ika (через оракул или оффчейн-сервис) для запроса подписи для транзакции Ethereum или сообщения. Поскольку Ika поддерживает ECDSA, ее можно использовать даже для управления ключом аккаунта Ethereum децентрализованным способом, подобно тому, как работают PKP в Lit Protocol (мы обсудим Lit позже). Ika также продемонстрировала такие варианты использования, как управление Bitcoin на роллапах — примером является интеграция с фреймворком Polygon Avail, позволяющая пользователям роллапов управлять BTC без доверия централизованному кастодиану. Это говорит о том, что Ika может сотрудничать с различными экосистемами (Polygon/Avail, роллапы Celestia и т. д.) в качестве поставщика децентрализованной инфраструктуры ключей.

Таким образом, с технической точки зрения Ika совместима с любой системой, полагающейся на цифровые подписи, что, по сути, относится ко всем блокчейнам. Ее первоначальное развертывание на Sui — это только начало; долгосрочное видение заключается в создании универсального уровня MPC, к которому любая цепочка или dApp может подключиться для безопасных кроссчейн-операций. Поддерживая общие криптографические стандарты (ECDSA, Ed25519, Schnorr) и обеспечивая необходимые проверки легких клиентов, Ika может стать своего рода сетью «MPC-как-сервис» для всего Web3, объединяя активы и действия с минимизацией доверия.

title: Бизнес и инвестиционные перспективы description: Глубокий анализ Ika: команда основателей, финансирование на сумму более 21 млн долларов, токеномика $IKA и стратегическое партнерство с Sui Foundation. keywords:

• Ika
• блокчейн-инфраструктура
• токеномика IKA
• криптография MPC
• сеть dWallet
• экосистема Sui
• Web3 инвестиции
• децентрализованное хранение tags: [blockchain, web3] image: "https://opengraph-image.blockeden.xyz/api/og-blockeden-xyz?title=%D0%91%D0%B8%D0%B7%D0%BD%D0%B5%D1%81%20%D0%B8%20%D0%B8%D0%BD%D0%B2%D0%B5%D1%81%D1%82%D0%B8%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D1%8B%D0%B5%20%D0%BF%D0%B5%D1%80%D1%81%D0%BF%D0%B5%D0%BA%D1%82%D0%B8%D0%B2%D1%8B%22%0A%0A%23%23%20%D0%91%D0%B8%D0%B7%D0%BD%D0%B5%D1%81%20%D0%B8%20%D0%B8%D0%BD%D0%B2%D0%B5%D1%81%D1%82%D0%B8%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D1%8B%D0%B5%20%D0%BF%D0%B5%D1%80%D1%81%D0%BF%D0%B5%D0%BA%D1%82%D0%B8%D0%B2%D1%8B%0A%0A%23%23%23%20%D0%9A%D0%BE%D0%BC%D0%B0%D0%BD%D0%B4%D0%B0%20%D0%BE%D1%81%D0%BD%D0%BE%D0%B2%D0%B0%D1%82%D0%B5%D0%BB%D0%B5%D0%B9%20%D0%B8%20%D0%BF%D1%80%D0%B5%D0%B4%D1%8B%D1%81%D1%82%D0%BE%D1%80%D0%B8%D1%8F%0A%0AIka%20%D0%B1%D1%8B%D0%BB%D0%B0%20%D0%BE%D1%81%D0%BD%D0%BE%D0%B2%D0%B0%D0%BD%D0%B0%20%D0%BA%D0%BE%D0%BC%D0%B0%D0%BD%D0%B4%D0%BE%D0%B9%20%D0%BE%D0%BF%D1%8B%D1%82%D0%BD%D1%8B%D1%85%20%D1%81%D0%BF%D0%B5%D1%86%D0%B8%D0%B0%D0%BB%D0%B8%D1%81%D1%82%D0%BE%D0%B2%20%D0%B2%20%D0%BE%D0%B1%D0%BB%D0%B0%D1%81%D1%82%D0%B8%20%D0%BA%D1%80%D0%B8%D0%BF%D1%82%D0%BE%D0%B3%D1%80%D0%B0%D1%84%D0%B8%D0%B8%20%D0%B8%20%D0%B1%D0%BB%D0%BE%D0%BA%D1%87%D0%B5%D0%B9%D0%BD%D0%B0%2C%20%D0%B1%D0%B0%D0%B7%D0%B8%D1%80%D1%83%D1%8E%D1%89%D0%B8%D1%85%D1%81%D1%8F%20%D0%B2%20%D0%BE%D1%81%D0%BD%D0%BE%D0%B2%D0%BD%D0%BE%D0%BC%20%D0%B2%20%D0%98%D0%B7%D1%80%D0%B0%D0%B8%D0%BB%D0%B5.%20%D0%A1%D0%BE%D0%B7%D0%B4%D0%B0%D1%82%D0%B5%D0%BB%D0%B5%D0%BC%20%D0%B8%20%D0%B3%D0%B5%D0%BD%D0%B5%D1%80%D0%B0%D0%BB%D1%8C%D0%BD%D1%8B%D0%BC%20%D0%B4%D0%B8%D1%80%D0%B5%D0%BA%D1%82%D0%BE%D1%80%D0%BE%D0%BC%20%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B0%20%D1%8F%D0%B2%D0%BB%D1%8F%D0%B5%D1%82%D1%81%D1%8F%20**%D0%9E%D0%BC%D0%B5%D1%80%20%D0%A1%D0%B0%D0%B4%D0%B8%D0%BA%D0%B0%20(Omer%20Sadika)**, предприниматель с серьезным опытом в сфере криптобезопасности. Ранее Омер был сооснователем Odsy Network, еще одного проекта, ориентированного на децентрализованную инфраструктуру кошельков, и является основателем / генеральным директором dWallet Labs, компании, стоящей за Ika. Его биография включает обучение в Y Combinator (выпускник YC) и специализацию на кибербезопасности и распределенных системах. Опыт Омера в Odsy и dWallet Labs напрямую повлиял на видение Ika — по сути, Ika можно рассматривать как эволюцию концепции «динамического децентрализованного кошелька», над которой работала Odsy, теперь реализованную в виде сети MPC на базе Sui.

Техническим директором и сооснователем Ika является Йехонатан Коэн Скали (Yehonatan Cohen Scaly), эксперт по криптографии, ставший соавтором протокола 2PC-MPC. Йехонатан руководит исследованиями и разработками новых криптографических алгоритмов Ika, ранее он работал в сфере кибербезопасности (вероятно, занимаясь академическими исследованиями в области криптографии). Его цитировали при обсуждении ограничений существующих пороговых схем и того, как подход Ika преодолевает их, что отражает глубокий опыт в MPC и распределенных криптографических протоколах. Еще одним сооснователем является Давид Лахмиш (David Lachmish), который курирует разработку продукта. Роль Давида заключается в том, чтобы превратить основные технологии в удобные для разработчиков продукты и реальные сценарии использования. Трио Омера, Йехонатана и Давида вместе с другими исследователями, такими как доктор Долев Муцари (вице-президент по исследованиям в dWallet Labs), составляет основу руководства Ika. В совокупности полномочия команды включают создание стартапов, академические исследования и опыт работы на стыке криптографии, безопасности и блокчейна. Именно благодаря такому глубокому опыту Ika описывается как проект, созданный «некоторыми из ведущих мировых экспертов по криптографии».

Помимо основателей, в более широкую команду и состав консультантов Ika, вероятно, входят люди с сильным криптографическим бэкграундом. Например, Долев Муцари (упомянутый выше) является соавтором технического документа и сыграл важную роль в разработке протокола. Наличие таких талантов дает инвесторам уверенность в том, что сложная технология Ika находится в надежных руках. Более того, наличие основателя (Омера), который уже успешно привлекал средства и создавал сообщество вокруг концепций Odsy / dWallet, означает, что Ika извлекает выгоду из уроков, извлеченных в предыдущих итерациях идеи. Базирование команды в Израиле — стране, известной своим сектором криптографии и кибербезопасности, — также обеспечивает им доступ к богатому кадровому резерву для найма разработчиков и исследователей.

Раунды финансирования и ключевые спонсоры​

Ika (и ее материнская компания dWallet Labs) привлекла значительное венчурное финансирование и стратегические инвестиции с момента своего основания. На сегодняшний день проект привлек более 21 миллиона долларов в ходе нескольких раундов. Начальный сид-раунд в августе 2022 года составил 5 миллионов долларов, что было примечательно, учитывая условия медвежьего рынка в то время. В этом раунде участвовал широкий круг известных криптоинвесторов и ангелов. Среди известных участников были Node Capital (лид-инвестор), Lemniscap, Collider Ventures, Dispersion Capital, Lightshift Capital, Tykhe Block Ventures, Liquid2 Ventures, Zero Knowledge Ventures и другие. Также присоединились видные индивидуальные инвесторы, такие как Навал Равикант (сооснователь AngelList и известный технологический инвестор), Марк Бхаргава (сооснователь Tagomi), Рене Райнсберг (сооснователь Celo) и ряд других деятелей индустрии. Такой список спонсоров подчеркнул сильное доверие к подходу Ika к децентрализованному хранению (custody) еще на стадии идеи.

В мае 2023 года Ika привлекла дополнительные ~ 7,5 млн долларов в ходе того, что, по-видимому, было раундом серии А или стратегическим раундом, по сообщениям, при оценке около 250 млн долларов. Этот раунд возглавили Blockchange Ventures и Node Capital (снова), при участии Insignius Capital, Rubik Ventures и других. К этому моменту тезис о масштабируемых сетях MPC набрал обороты, и прогресс Ika, вероятно, побудил этих инвесторов удвоить ставки. Оценка в 250 млн долларов для сети на относительно ранней стадии отражала ожидания рынка относительно того, что Ika может стать фундаментальной инфраструктурой в Web3 (наравне с блокчейнами L1 или крупными протоколами DeFi с точки зрения ценности).

Самая громкая инвестиция состоялась в апреле 2025 года, когда Sui Foundation объявил о стратегических инвестициях в Ika. Это партнерство с фондом экосистемы Sui увеличило общее финансирование Ika до более чем 21 млн долларов и закрепило тесную связь с блокчейном Sui. Хотя точная сумма инвестиций Sui Foundation не разглашалась, ясно, что это было значительное одобрение — вероятно, порядка нескольких миллионов долларов США. Поддержка Sui Foundation не только финансовая; она также означает, что Ika получает мощную помощь в выходе на рынок внутри экосистемы Sui (привлечение разработчиков, поддержка интеграции, маркетинг и т. д.). Согласно пресс-релизам, «Ika… объявила о стратегических инвестициях от Sui Foundation, в результате чего общее финансирование превысило 21 миллион долларов». Этот стратегический раунд, а не традиционный венчурный раунд акций, подчеркивает, что Sui рассматривает Ika как критически важную инфраструктуру для будущего своего блокчейна (аналогично тому, как Ethereum Foundation может напрямую поддерживать проект второго уровня или проект по обеспечению функциональной совместимости, который приносит пользу Ethereum).

Помимо Sui, стоит отметить и других спонсоров: Node Capital (базирующийся в Китае криптофонд, известный ранними инвестициями в инфраструктуру), Lemniscap (крипто-венчурный фонд, ориентированный на инновации в протоколах на ранних стадиях) и Collider Ventures (израильский венчурный фонд, вероятно, обеспечивающий локальную поддержку). Примечательно лидерство Blockchange Ventures в раунде 2023 года; Blockchange — это венчурный фонд, который поддержал несколько инфраструктурных криптопроектов, и их лидерство предполагает, что они увидели в технологии Ika потенциал для определения категории. Кроме того, Digital Currency Group (DCG) и Node Capital возглавили сбор средств в размере 5 миллионов долларов для dWallet Labs до ребрендинга Ika (согласно посту Омера в LinkedIn) — участие DCG (через более ранний раунд для компании) указывает на еще большую поддержку в фоновом режиме.

Подводя итог, можно сказать, что путь финансирования Ika демонстрирует сочетание традиционных венчурных капиталистов и стратегических партнеров. Участие Sui Foundation особенно выделяется, так как оно предоставляет не только капитал, но и интегрированную экосистему для развертывания технологий Ika. Инвесторы, по сути, делают ставку на то, что Ika станет основным решением для децентрализованного управления ключами и мостов между многими сетями, и соответственно оценили проект.

Токеномика и экономическая модель​

У Ika будет собственный служебный токен под названием $IKA, который занимает центральное место в экономике и модели безопасности сети. Примечательно, что токен IKA запускается на блокчейне Sui (как нативный актив SUI), несмотря на то, что сама сеть Ika является отдельной цепочкой. Это означает, что IKA будет существовать как монета, которую можно хранить и передавать в Sui, как и любой другой актив Sui, и она будет использоваться двойным образом: внутри сети Ika для стейкинга и комиссий, и в Sui для управления или доступа в dApps. Токеномику можно описать следующим образом:

• Комиссии за газ: Подобно тому, как ETH является газом в Ethereum, а SUI — в Sui, IKA служит газом / оплатой за операции MPC в сети Ika. Когда пользователь или dApp запрашивает подпись или операцию dWallet, сети выплачивается комиссия в IKA. Эти комиссии компенсируют валидаторам вычислительную и коммуникационную работу по запуску протокола пороговой подписи. В «белой книге» роль IKA сравнивается с газом Sui, подтверждая, что все транзакции между цепочками, осуществляемые Ika, будут облагаться небольшой комиссией в IKA. График комиссий, вероятно, пропорционален сложности операции (например, одна подпись может стоить базовую комиссию, в то время как более сложные многоэтапные рабочие процессы могут стоить дороже).

• Стейкинг и безопасность: IKA также является токеном стейкинга. Узлам-валидаторам в сети Ika должна быть делегирована доля IKA для участия в консенсусе и подписании. Консенсус следует делегированному доказательству доли (DPoS), аналогичному Sui: держатели токенов делегируют IKA валидаторам, а вес каждого валидатора в консенсусе (и, следовательно, в процессах пороговой подписи) определяется ставкой. В каждой эпохе выбираются валидаторы, и их право голоса является функцией ставки, при этом весь набор является византийски отказоустойчивым (это означает, что если набор валидаторов имеет общую ставку X, до \~ X / 3 ставки может принадлежать злоумышленникам без нарушения гарантий сети). Стейкеры (делегаты) поощряются наградами за стейкинг: модель Ika, вероятно, включает распределение собранных комиссий (и, возможно, инфляционных вознаграждений) валидаторам и их делегатам в конце эпох. В документации отмечается, что все собранные комиссии за транзакции распределяются между полномочными органами, которые могут делиться частью со своими делегатами в качестве вознаграждения. Это отражает модель Sui по вознаграждению поставщиков услуг за пропускную способность.

• Предложение и распределение: На данный момент (второй квартал 2025 года) подробности об общем предложении IKA, первоначальном распределении и инфляции не являются полностью публичными. Однако, учитывая раунды финансирования, мы можем сделать вывод о некоторой структуре. Вероятно, часть IKA распределяется между ранними инвесторами (сид-раунды и серии) и командой, а большая часть зарезервирована для сообщества и будущих стимулов. Возможно, планируется продажа сообществу или аирдроп, тем более что Ika провела заметную NFT-кампанию, собравшую 1,4 млн SUI, как упоминалось в новостях (это была художественная NFT-кампания на Sui, установившая рекорд; возможно, участники этой кампании получат вознаграждения IKA или ранний доступ). Кампания NFT указывает на стратегию вовлечения сообщества и стимулирования распределения токенов среди пользователей, а не только среди венчурных капиталистов.

• Сроки запуска токена: В объявлении Sui Foundation в октябре 2024 года указывалось: «Токен IKA будет запущен нативно на Sui, открывая новые функциональные возможности и полезность в децентрализованной безопасности». Запуск основной сети был намечен на декабрь 2024 года, поэтому предположительно событие генерации токенов (TGE) должно совпасть с ним или последовать вскоре после него. Если основная сеть была запущена по графику, токены IKA могли начать распределяться в конце 2024 или начале 2025 года. Затем токен начнет использоваться для оплаты газа в сети Ika и стейкинга. До этого в тестовой сети для оплаты газа использовался временный токен (DWLT в тестовой сети), который не имел реальной ценности.

• Сценарии использования и накопление стоимости: Инвестиционная ценность IKA зависит от использования сети Ika. По мере того как через Ika проходит больше межцепочечных транзакций, выплачивается больше комиссий в IKA, что создает спрос. Кроме того, если многие захотят запустить валидаторы или обезопасить сеть, они должны приобрести и застейкать IKA, что блокирует предложение (уменьшая свободное обращение). Таким образом, IKA имеет природу утилитарности и управления — утилитарность в оплате услуг и стейкинге, и, вероятно, управление в определении будущего протокола (хотя управление еще не упоминалось явно, для таких сетей характерно со временем децентрализовать контроль посредством голосования токенами). Можно представить, как держатели токенов IKA голосуют за добавление поддержки новых цепочек, корректировку параметров комиссий или другие обновления протокола в будущем.

В целом, токеномика IKA направлена на баланс безопасности сети и удобства использования. Запускаясь на Sui, они упрощают пользователям экосистемы Sui получение и использование IKA (для самого токена не требуется отдельного онбординга в новую цепочку), что может ускорить принятие. Инвесторы будут следить за такими показателями, как доля застейканного предложения (указывающая на безопасность), доход от комиссий (указывающий на использование) и партнерства, стимулирующие транзакции (указывающие на спрос на токен).

Бизнес-модель и стратегия выхода на рынок​

Бизнес-модель Ika — это модель инфраструктурного провайдера в экосистеме блокчейна. Она не предлагает продукт для конечного потребителя; вместо этого она предлагает протокольную услугу (децентрализованное управление ключами и исполнение транзакций), которую интегрируют другие проекты. Таким образом, основным механизмом получения дохода (или извлечения стоимости) является плата за услуги — то есть комиссии за газ в IKA за использование сети. Ika можно сравнить с децентрализованным AWS для подписания ключей: любой разработчик может подключиться и использовать его, оплачивая каждое использование. В долгосрочной перспективе, по мере децентрализации сети, dWallet Labs (компания-основатель) может извлекать выгоду за счет владения долей в сети и роста стоимости токенов, а не за счет взимания комиссий по модели SaaS вне сети.

Стратегия выхода на рынок (GTM): На раннем этапе Ika ориентируется на блокчейн-разработчиков и проекты, которым требуется межцепочечная функциональность или решения для хранения. Сотрудничество с Sui обеспечивает готовую базу таких разработчиков. Сама Sui, будучи новой L1-сетью, нуждается в уникальных функциях для привлечения пользователей, и Ika предлагает на Sui межцепочечный DeFi, доступ к Биткоину и многое другое, что является убедительными особенностями. Таким образом, GTM Ika опирается на растущую экосистему Sui. Примечательно, что еще до запуска основной сети несколько проектов Sui объявили об интеграции Ika:

• Проекты, такие как Full Sail, Rhei, Aeon, Human Tech, Covault, Lucky Kat, Native, Nativerse, Atoma и Ekko (все разработчики на Sui), «объявили о своих предстоящих запусках с использованием Ika», охватывая сценарии использования от DeFi до гейминга. Например, Full Sail может создавать биржу, которая может торговать BTC через Ika; Lucky Kat (игровая студия) может использовать Ika для создания внутриигровых активов, находящихся в нескольких цепочках; Covault, вероятно, занимается решениями для хранения и т. д. Закрепляя эти партнерские отношения на ранней стадии, Ika гарантирует, что сразу после запуска будет немедленный объем транзакций и реальные приложения, демонстрирующие ее возможности.

• Ika также делает упор на институциональные сценарии использования, такие как децентрализованное хранение для учреждений. В пресс-релизах они подчеркивают «непревзойденную безопасность для институциональных и индивидуальных пользователей» при хранении через Ika. Это говорит о том, что Ika может позиционироваться для криптокастодианов, бирж или даже игроков TradFi, которым нужен более безопасный способ управления закрытыми ключами (возможно, в качестве альтернативы или дополнения к Fireblocks или Copper, которые используют MPC, но в централизованной корпоративной среде). Фактически, будучи децентрализованной сетью, Ika может позволить конкурентам в сфере кастодиальных услуг полагаться на одну и ту же надежную сеть подписания вместо того, чтобы каждый создавал свою собственную. Эта кооперативная модель могла бы привлечь учреждения, предпочитающие нейтрального децентрализованного кастодиана для определенных активов.

• Еще один аспект — интеграция ИИ: Ika упоминает «защитные механизмы для ИИ-агентов» (AI Agent guardrails) в качестве сценария использования. Это перспективное направление, играющее на тренде автономии ИИ (например, ИИ-агенты, совершающие действия в блокчейне). Ika может гарантировать, что ИИ-агент (скажем, автономный экономический агент, получивший контроль над некоторыми средствами) не сможет сбежать с деньгами, потому что сам агент не является единственным владельцем ключа — ему все равно понадобится доля пользователя или соблюдение условий в Ika. Позиционирование Ika как обеспечивающей безопасность для ИИ в Web3 — это новый подход к привлечению интереса со стороны этого сектора.

Географически наличие Node Capital и других намекает на акцент на Азию в дополнение к западному рынку. У Sui сильное азиатское сообщество (особенно в Китае). Кампания Ika по продаже NFT на Sui (художественная кампания, собравшая 1,4 млн SUI) указывает на усилия по созданию сообщества — возможно, привлечение китайских пользователей, активно работающих в пространстве NFT на Sui. Проводя продажи NFT или аирдропы для сообщества, Ika может сформировать базу рядовых пользователей, которые владеют токенами IKA и заинтересованы в содействии ее внедрению.

Со временем бизнес-модель может расшириться до предложения премиальных функций или корпоративных интеграций. Например, в то время как публичная сеть Ika является общедоступной (permissionless), dWallet Labs может запускать частные экземпляры или версии для консорциумов для определенных клиентов или предоставлять консультационные услуги проектам, интегрирующим Ika. Они также могут зарабатывать, запуская часть валидаторов на раннем этапе (этап начальной загрузки) и, таким образом, собирая часть комиссий.

Подводя итог, можно сказать, что GTM Ika тесно связана с партнерствами внутри экосистемы. Глубоко внедряясь в дорожную карту Sui (где цели Sui на 2025 год включают межцепочечную ликвидность и уникальные сценарии использования), Ika гарантирует, что будет расти вместе с этой L1. Одновременно она позиционирует себя как обобщенное решение для многоцепочечной координации, которое затем может быть предложено проектам в других цепочках после демонстрации успеха на Sui. Поддержка со стороны Sui Foundation и объявления о ранней интеграции дают Ika значительное преимущество в плане доверия и принятия по сравнению с тем, если бы она запускалась в изоляции.

Принятие экосистемой, партнерства и дорожная карта​

Даже на ранней стадии Ika сформировала впечатляющий список взаимодействий в экосистеме:

• Принятие экосистемой Sui: Как уже упоминалось, несколько проектов на базе Sui интегрируют Ika. Это означает, что после запуска основной сети Ika мы ожидаем увидеть dApps на Sui с функциями типа «Powered by Ika» — например, протокол кредитования на Sui, который позволяет пользователям вносить BTC, или DAO на Sui, использующая Ika для хранения своей казны в нескольких цепочках. Тот факт, что в проекте участвуют такие имена, как Rhei, Atoma, Nativerse (вероятно, проекты DeFi) и Lucky Kat (гейминг / NFT), показывает, что применимость Ika охватывает различные вертикали.

• Стратегические партнерства: Самым важным партнером Ika является сама Sui Foundation, которая выступает и как инвестор, и как промоутер. Официальные каналы Sui (блог и т. д.) активно освещали Ika, фактически одобряя ее как решение для функциональной совместимости для Sui. Кроме того, Ika, вероятно, работает с другими поставщиками инфраструктуры. Например, учитывая упоминание zkLogin (функция входа через Web2 от Sui) наряду с Ika, может существовать комбинированный сценарий использования, в котором zkLogin обрабатывает аутентификацию пользователя, а Ika — межцепочечные транзакции, обеспечивая вместе бесшовный UX. Также упоминание Avail (Polygon) в блогах Ika предполагает партнерство или пилотный проект в этой экосистеме: возможно, с Polygon Labs или командами, создающими роллапы на Avail, для использования Ika в качестве моста для Биткоина в эти роллапы. Другая потенциальная область партнерства — с кастодианами: например, интеграция Ika с провайдерами кошельков, такими как Zengo (что примечательно, так как сооснователь ZenGo участвовал в предыдущем проекте Омера), или с институциональными технологиями хранения, такими как Fireblocks. Хотя это не подтверждено, это были бы логичные цели (на самом деле Fireblocks сотрудничает с Sui в других областях; можно представить, как Fireblocks использует Ika для MPC на Sui).

• Взаимодействие с сообществом и разработчиками: Ika ведет Discord и, вероятно, проводит хакатоны, чтобы привлечь разработчиков к созданию приложений с использованием dWallets. Технология является новой, поэтому ключевым моментом является ее популяризация через обучение. Наличие разделов «Сценарии использования» и «Разработчики» на их сайте, а также постов в блоге, объясняющих основные концепции, указывает на стремление приучить разработчиков к концепции dWallets. Чем больше разработчиков поймут, что они могут создавать межцепочечную логику без мостов (и без ущерба для безопасности), тем активнее будет расти органическое внедрение.

• Дорожная карта: По состоянию на 2025 год дорожная карта Ika включала:

  • Альфа-версия и тестовая сеть (2023–2024 гг.): Альфа-тестнет был запущен в 2024 году на Sui, что позволило разработчикам экспериментировать с dWallets и предоставлять обратную связь. Этот этап использовался для доработки протокола, исправления ошибок и проведения внутренних аудитов.
  • Запуск основной сети (декабрь 2024 г.): Ika планировала запустить основную сеть к концу 2024 года. Если это было достигнуто, то к настоящему времени (середина 2025 года) основная сеть Ika должна функционировать. Запуск, вероятно, включал первоначальную поддержку набора цепочек: как минимум Биткоина и Ethereum (цепочки ECDSA) сразу после старта, учитывая, что они активно упоминались в маркетинге.
  • Цели на 2025 год после запуска: В 2025 году ожидается, что основное внимание будет уделено масштабированию использования (через приложения Sui и, возможно, расширение на другие цепочки). Вскоре после запуска команда будет работать над добавлением поддержки Ed25519 и Schnorr, что позволит интегрироваться с Solana, Polkadot и другими экосистемами. Они также внедрят больше легких клиентов (возможно, легкий клиент Ethereum для Ika, легкий клиент Solana и т. д.) для расширения бездоверительного контроля. Еще одним пунктом дорожной карты, вероятно, является расширение списка валидаторов без специального разрешения — поощрение присоединения большего числа независимых валидаторов и дальнейшая децентрализация сети. Поскольку код представляет собой форк Sui, запуск валидатора Ika аналогичен запуску узла Sui, что могут делать многие операторы.
  • Улучшение функций: В блогах упоминались две интересные функции: Зашифрованные доли пользователей (Encrypted User Shares) и Подписание будущих транзакций (Future Transaction signing). Зашифрованная доля пользователя означает, что пользователи могут по желанию зашифровать свою закрытую долю и сохранить ее в блокчейне (возможно, в Ika или где-либо еще) таким образом, чтобы только они могли ее расшифровать, что упрощает восстановление. Подписание будущих транзакций подразумевает возможность предварительного подписания транзакции в Ika, которая выполняется позже при соблюдении определенных условий. Эти функции повышают удобство использования (пользователям не нужно будет быть онлайн для каждого действия, если они предварительно одобрят определенную логику, при этом сохраняя некастодиальную безопасность). Реализация этого в 2025 году еще больше выделит предложение Ika.
  • Рост экосистемы: К концу 2025 года Ika, вероятно, стремится к тому, чтобы ее активно использовали экосистемы нескольких цепочек. Мы можем увидеть, например, проект на базе Ethereum, использующий Ika через оракул (если прямой интеграции в блокчейне еще нет), или сотрудничество с межцепочечными проектами, такими как Wormhole или LayerZero, где Ika могла бы служить механизмом подписания для безопасной передачи сообщений.

Конкурентная среда также будет формировать стратегию Ika. Она не единственная предлагает децентрализованное управление ключами, поэтому часть ее дорожной карты будет включать в себя акцентирование внимания на преимуществе в производительности и уникальной безопасности двух сторон в отличие от других. В следующем разделе мы сравним Ika с ее заметными конкурентами Lit Protocol, Threshold Network и Zama.

Конкурентный анализ: Ika против других сетей MPC / Threshold​

Ika работает в передовой области криптографических сетей, где несколько проектов преследуют схожие цели, используя различные подходы. Ниже приведено краткое сравнение Ika с Lit Protocol, Threshold Network и Zama (каждый из которых является представителем конкурентов в области децентрализованной инфраструктуры ключей или конфиденциальных вычислений):

Конкурентное преимущество Ika: Отличительные черты Ika заключаются в ее производительности при масштабировании и уникальной модели безопасности. По сравнению с Lit Protocol, Ika может поддерживать гораздо больше подписантов и значительно более высокую пропускную способность, что делает ее подходящей для сценариев использования (таких как высокообъемная торговля или игры), с которыми сеть Lit не справилась бы. Ika также не полагается на доверенные среды выполнения (TEE), к которым некоторые разработчики относятся с осторожностью (из-за потенциальных эксплойтов в SGX); вместо этого Ika достигает бездоверительности исключительно с помощью криптографии и консенсуса. В противовес Threshold Network, Ika предлагает более универсальную платформу. Threshold в основном ориентирована на мосты Bitcoin ↔ Ethereum (tBTC) и несколько криптографических сервисов, таких как прокси-перешифрование, в то время как Ika является гибким уровнем совместимости, который может работать с любой сетью и активом «из коробки». Кроме того, модель Ika с участием пользователя означает, что она не требует избыточного обеспечения или страхования депозитов (tBTC v2 использует надежную, но сложную экономическую модель для обеспечения депозитов BTC, тогда как в Ika пользователь изначально не теряет контроль). По сравнению с Zama, Ika решает другую проблему — Zama нацелена на конфиденциальность, а Ika — на совместимость. Однако вполне возможно, что в будущем они смогут дополнять друг друга (например, используя FHE для активов, хранящихся в Ika). На данный момент преимущество Ika в том, что она начнет работать раньше в нише с немедленным спросом (мосты и сети MPC нужны сегодня, в то время как FHE еще созревает).

Одним из потенциальных вызовов для Ika является обучение рынка и доверие. Она внедряет новый способ кросс-чейн взаимодействия (dWallets вместо традиционных мостов с блокировкой и выпуском активов). Ей нужно будет со временем продемонстрировать свою безопасность на практике, чтобы завоевать такой же уровень доверия, какой постепенно заслужила, скажем, Threshold Network (Threshold пришлось доказывать надежность tBTC после того, как ранняя версия была приостановлена из-за рисков). Если технология Ika будет работать так, как заявлено, она фактически опередит конкурентов, решив трилемму децентрализации, безопасности и скорости в пространстве MPC. Сильная поддержка со стороны Sui и обширные аудиты / научные работы добавляют проекту авторитетности.

В заключение, Ika выделяется среди сетей MPC своей амбициозной масштабируемостью и ориентированной на пользователя моделью безопасности. Инвесторы рассматривают ее как ставку на будущее кросс-чейн координации — будущее, в котором пользователи могут беспрепятственно перемещать ценности и логику между множеством блокчейнов, никогда не теряя контроля над своими ключами. Если Ika получит широкое признание, она может стать такой же неотъемлемой частью инфраструктуры Web3, как протоколы обмена сообщениями между сетями или основные блокчейны Layer-1. Предстоящий год (2025) станет критическим, поскольку запуск основной сети Ika и первые варианты использования докажут, сможет ли эта передовая криптография выполнить свои обещания в реальных рыночных условиях. Первые признаки — сильные технические основы, активный пайплайн интеграций и существенная поддержка инвесторов — указывают на то, что у Ika есть реальный шанс переопределить кросс-чейн совместимость с помощью MPC.

Источники: Основная информация была собрана из официальной документации и whitepaper Ika, объявлений Sui Foundation, пресс-релизов и новостей о финансировании, а также технических документов и анализов конкурентов для контекста (отчет Messari по Lit Protocol, документация Threshold Network и описания FHE от Zama). Вся информация актуальна по состоянию на 2025 год.

Публичные блокчейны обеспечивают прозрачность и целостность ценой конфиденциальности — каждая транзакция и состояние контракта открыты для всех участников. Такая открытость создает проблемы, такие как MEV-атаки (Maximum Extractable Value — максимально извлекаемая стоимость), копи-трейдинг и утечка конфиденциальной бизнес-логики. Программируемая конфиденциальность призвана решить эти проблемы, позволяя выполнять вычисления над частными данными без раскрытия самих данных. Это становится возможным благодаря двум развивающимся криптографическим парадигмам: виртуальным машинам с полностью гомоморфным шифрованием (FHE-VM) и копроцессорам с нулевым разглашением (ZK-копроцессорам). Эти подходы позволяют выполнять вычисления вне сети или в зашифрованном виде с верификацией в сети, сохраняя конфиденциальность и обеспечивая бездоверительную корректность. В этом отчете мы подробно рассмотрим архитектуры FHE-VM и ZK-копроцессоров, сравним их компромиссы и изучим варианты использования в финансах, идентификации, здравоохранении, на рынках данных и в децентрализованном машинном обучении.

Виртуальная машина с полностью гомоморфным шифрованием (FHE-VM)​

Полностью гомоморфное шифрование (FHE) позволяет выполнять произвольные вычисления над зашифрованными данными без необходимости их расшифровки. Виртуальная машина FHE интегрирует эту возможность в смарт-контракты блокчейна, обеспечивая зашифрованное состояние и логику контракта. В блокчейне с поддержкой FHE (часто называемом fhEVM для EVM-совместимых разработок) все входные данные, хранилище контрактов и выходные данные остаются зашифрованными на протяжении всего процесса выполнения. Это означает, что валидаторы могут обрабатывать транзакции и обновлять состояние, не узнавая никаких конфиденциальных значений, достигая исполнения в сети при соблюдении конфиденциальности данных.

Архитектура и дизайн FHE-VM​

Типичная FHE-VM расширяет стандартную среду выполнения смарт-контрактов (такую как Ethereum Virtual Machine) встроенной поддержкой зашифрованных типов данных и операций. Например, FHEVM от Zama вводит зашифрованные целые числа (euint8, euint32 и т. д.), зашифрованные логические значения (ebool) и даже зашифрованные массивы в качестве первоклассных типов. Языки смарт-контрактов, такие как Solidity, дополняются библиотеками или новыми кодами операций (opcodes), чтобы разработчики могли выполнять арифметические (add, mul и т. д.), логические операции и сравнения непосредственно над шифротекстами. Внутри эти операции вызывают примитивы FHE (например, с использованием библиотеки TFHE) для управления зашифрованными битами и получения зашифрованных результатов.

Хранение зашифрованного состояния поддерживается таким образом, что переменные контракта остаются зашифрованными в состоянии блокчейна. Процесс выполнения обычно выглядит так:

1. Шифрование на стороне клиента: Пользователи шифруют свои входные данные локально, используя публичный ключ FHE, перед отправкой транзакций. Ключ шифрования является публичным (для шифрования и вычислений), в то время как ключ дешифрования остается в секрете. В некоторых моделях каждый пользователь управляет собственным ключом; в других используется единый глобальный ключ FHE (рассмотрено ниже).
2. Гомоморфные вычисления в сети: Майнеры/валидаторы выполняют контракт с использованием зашифрованных кодов операций. Они выполняют одни и те же детерминированные гомоморфные операции над шифротекстами, что позволяет достичь консенсуса относительно нового зашифрованного состояния. Важно то, что валидаторы никогда не видят открытых данных — они видят только «бессмысленный» шифротекст, но при этом могут последовательно его обрабатывать.
3. Дешифрование (опционально): Если результат необходимо раскрыть или использовать вне сети, авторизованная сторона с закрытым ключом может расшифровать выходной шифротекст. В противном случае результаты остаются зашифрованными и могут быть использованы в качестве входных данных для последующих транзакций (что позволяет проводить последовательные вычисления над постоянным зашифрованным состоянием).

Важным аспектом проектирования является управление ключами. Один из подходов — ключи для каждого пользователя, где каждый пользователь хранит свой секретный ключ, и только он может расшифровать относящиеся к нему выходные данные. Это максимизирует конфиденциальность (никто другой не сможет расшифровать ваши данные), но гомоморфные операции не могут смешивать данные, зашифрованные разными ключами, без сложных протоколов с несколькими ключами. Другой подход, используемый в FHEVM от Zama, — глобальный ключ FHE: единый публичный ключ шифрует все данные контракта, а распределенный набор валидаторов владеет долями ключа пороговой дешифровки. Публичные ключи шифрования и вычислений публикуются в сети, поэтому любой может зашифровать данные для сети; закрытый ключ разделен между валидаторами, которые могут коллективно выполнить дешифрование при достижении порога, если это необходимо. Чтобы предотвратить сговор валидаторов, Zama использует протокол порогового FHE (основанный на их исследовании Noah’s Ark) с механизмом «зашумления» (noise flooding) для обеспечения безопасности частичных дешифровок. Открытый текст может быть восстановлен только в том случае, если кооперируется достаточное количество валидаторов, например, для обслуживания запроса на чтение. Однако при обычной работе ни один узел никогда не видит открытый текст — данные всегда остаются зашифрованными в сети.

Контроль доступа — еще один важный компонент. Реализации FHE-VM включают детализированные средства управления тем, кто (если вообще кто-либо) может инициировать дешифрование или получать доступ к определенным зашифрованным полям. Например, fhEVM от Cypher поддерживает списки контроля доступа (ACL) для шифротекстов, позволяя разработчикам указывать, какие адреса или контракты могут взаимодействовать с определенными данными или перешифровывать их. Некоторые фреймворки поддерживают перешифрование (re-encryption): возможность передачи зашифрованного значения от ключа одного пользователя к ключу другого без раскрытия открытого текста. Это полезно для таких вещей, как рынки данных, где владелец данных может зашифровать набор данных своим ключом, а после покупки перешифровать его ключом покупателя — и все это в сети, без публичного раскрытия данных.

Обеспечение корректности и конфиденциальности​

Возникает вопрос: если все данные зашифрованы, как обеспечить корректность логики контракта? Как сеть может предотвратить недопустимые операции, если она не «видит» значения? FHE сам по себе не предоставляет доказательства корректности — валидаторы могут выполнять гомоморфные шаги, но они не могут изначально определить, были ли зашифрованные входные данные пользователя действительными или следует ли переходить к условной ветке без дешифрования. Доказательства с нулевым разглашением (ZKP) могут дополнить FHE для решения этой проблемы. В FHE-VM пользователи обычно должны предоставлять ZK-доказательство, подтверждающее определенные условия открытого текста, когда это необходимо. Например, в дизайне Zama используется ZK-доказательство знания открытого текста (ZKPoK) для каждого зашифрованного ввода. Это доказывает, что пользователь знает открытый текст, соответствующий его шифротексту, и что он соответствует ожидаемым критериям, не раскрывая сам открытый текст. Такие «сертифицированные шифротексты» не позволяют злоумышленнику отправить некорректное шифрование или значение, выходящее за допустимые пределы. Аналогично, для операций, требующих принятия решения (например, проверка условия «баланс счета ≥ сумма вывода»), пользователь может предоставить ZK-доказательство того, что это условие истинно для открытых текстов, прежде чем будет выполнена зашифрованная операция. Таким образом, сеть не расшифровывает и не видит значения, но получает уверенность в том, что зашифрованные транзакции следуют правилам.

Другой подход в FHE-роллапах заключается в выполнении проверки вне сети с помощью ZKP. Fhenix (L2-роллап на базе FHE) выбирает оптимистичную модель, в которой отдельный сетевой компонент, называемый Threshold Service Network, может расшифровывать или проверять зашифрованные результаты, а любое неверное вычисление может быть оспорено с помощью доказательства мошенничества (fraud-proof). В целом, сочетание FHE + ZK или доказательств мошенничества гарантирует, что зашифрованное исполнение остается бездоверительным. Валидаторы либо коллективно расшифровывают данные только при наличии полномочий, либо проверяют доказательства того, что каждый зашифрованный переход состояния был валидным, без необходимости видеть открытый текст.

Вопросы производительности: FHE-операции требуют больших вычислительных ресурсов — они на много порядков медленнее обычных арифметических операций. Например, простое 64-битное сложение в Ethereum стоит около 3 единиц газа, тогда как сложение зашифрованного 64-битного целого числа (euint64) в FHEVM от Zama стоит примерно 188 000 единиц газа. Даже 8-битное сложение может стоить около 94 000 газа. Такие огромные накладные расходы означают, что прямая реализация на существующих узлах была бы практически невозможной из-за медлительности и стоимости. Проекты FHE-VM решают эту проблему с помощью оптимизированных криптографических библиотек (таких как библиотека TFHE-rs от Zama для бутстраппинга бинарных вентилей) и кастомных модификаций EVM для повышения производительности. Например, модифицированный клиент Geth от Cypher добавляет новые коды операций и оптимизирует выполнение гомоморфных инструкций на C++/ассемблере для минимизации задержек. Тем не менее, для достижения приемлемой пропускной способности требуется аппаратное ускорение. Текущая работа включает использование графических процессоров (GPU), программируемых логических интегральных схем (FPGA) и даже специализированных фотонных чипов для ускорения вычислений FHE. Zama сообщает, что производительность их FHE улучшилась в 100 раз с 2024 года, и целью является достижение тысяч транзакций в секунду (TPS) с ускорением на GPU/FPGA. Специализированные серверы-копроцессоры FHE (такие как узел LightLocker от Optalysys) могут подключаться к узлам валидаторов для разгрузки зашифрованных операций на аппаратное обеспечение, поддерживая более 100 зашифрованных переводов ERC-20 в секунду на один узел. По мере совершенствования оборудования и алгоритмов разрыв между FHE и обычными вычислениями будет сокращаться, что позволит приватным контрактам достичь практически значимых скоростей.

Совместимость: Ключевой целью разработок FHE-VM является сохранение совместимости с существующими рабочими процессами разработки. Реализации fhEVM от Cypher и Zama позволяют разработчикам писать контракты на Solidity с минимальными изменениями, используя библиотеку для объявления зашифрованных типов и операций. Остальную часть инструментария Ethereum (Remix, Hardhat и т. д.) по-прежнему можно использовать, поскольку основные модификации происходят на уровне клиента/узла. Это снижает порог входа: разработчикам не нужно быть экспертами в криптографии для написания конфиденциального смарт-контракта. Например, простое сложение двух чисел может быть записано как euint32 c = a + b;, и FHEVM обработает специфические детали шифрования в фоновом режиме. Контракты могут даже взаимодействовать с обычными контрактами — например, зашифрованный контракт может передавать расшифрованный результат в стандартный контракт, что позволяет смешивать приватные и публичные части в рамках одной экосистемы.

Текущие проекты FHE-VM: Несколько проектов являются первопроходцами в этой области. Zama (парижский стартап в области FHE) разработала концепцию FHEVM и библиотеки (TFHE-rs и библиотеку fhevm-solidity). Они не планируют запускать собственную сеть, а предоставляют инфраструктуру другим. Inco — это L1-блокчейн (построенный на Cosmos SDK с использованием Evmos), который интегрировал FHEVM от Zama для создания модульной конфиденциальной сети. Их тестовые сети (Gentry и Paillier) демонстрируют зашифрованные переводы ERC-20 и другие приватные примитивы DeFi. Fhenix — это оптимистичный роллап второго уровня (L2) для Ethereum, использующий FHE для обеспечения конфиденциальности. Они выбрали оптимистичный подход (с доказательствами мошенничества), а не ZK-роллап, из-за высокой стоимости одновременного выполнения FHE и ZK для каждого блока. Fhenix использует ту же библиотеку TFHE-rs (с некоторыми модификациями) и внедряет Threshold Service Network для децентрализованной обработки дешифрования. Также существуют независимые команды, такие как Fhenix (после ребрендинга), и стартапы, исследующие гибриды MPC + FHE. Кроме того, Cypher (от Z1 Labs) строит сеть третьего уровня (L3), ориентированную на ИИ и конфиденциальность, используя fhEVM с такими функциями, как секретные хранилища и поддержка федеративного обучения. Экосистема находится на начальном этапе, но быстро растет, подкрепляемая значительным финансированием — например, Zama стала «единорогом», привлев более 130 млн долларов к 2025 году для развития технологий FHE.

Таким образом, FHE-VM позволяет создавать смарт-контракты с сохранением конфиденциальности, выполняя всю логику над зашифрованными данными непосредственно в сети. Эта парадигма обеспечивает максимальную конфиденциальность — никакие чувствительные данные никогда не раскрываются в транзакциях или состоянии — при этом для обеспечения целостности используется существующий консенсус блокчейна. Платой за это является повышенная вычислительная нагрузка на валидаторов и сложность в управлении ключами и интеграции доказательств. Далее мы рассмотрим альтернативную парадигму, которая полностью выносит вычисления за пределы сети и использует блокчейн только для верификации: ZK-копроцессор.

ZK-копроцессоры (Zero-Knowledge Coprocessors)​

ZK-копроцессор — это новый паттерн архитектуры блокчейна, при котором ресурсоемкие вычисления выполняются вне сети (off-chain), а лаконичное доказательство с нулевым разглашением их правильности проверяется в сети (on-chain). Это позволяет смарт-контрактам задействовать гораздо большие вычислительные мощности и объемы данных, чем позволяло бы ончейн-выполнение, без ущерба для децентрализации (trustlessness). Термин копроцессор используется по аналогии с аппаратными сопроцессорами (такими как математический сопроцессор или GPU), которые обрабатывают специализированные задачи для центрального процессора. В данном случае «процессор» блокчейна (нативная виртуальная машина, такая как EVM) делегирует определенные задачи системе доказательств с нулевым разглашением, которая выступает в роли криптографического сопроцессора. ZK-копроцессор возвращает результат и доказательство того, что результат был вычислен верно, которое ончейн-контракт может проверить и затем использовать.

Архитектура и рабочий процесс​

В типичной конфигурации разработчик dApp определяет части логики своего приложения, которые слишком дороги или сложны для ончейн-выполнения (например, объемные вычисления на исторических данных, тяжелые алгоритмы, логический вывод моделей машинного обучения и т. д.). Они реализуют эти части как внечейновую программу (на языке высокого уровня или специализированном DSL для схем), которая может генерировать доказательство с нулевым разглашением своего выполнения. Ончейн-компонентом является смарт-контракт верификатор, который проверяет доказательства и предоставляет результаты остальной части системы. Процесс можно резюмировать следующим образом :

1. Запрос (Request) — ончейн-контракт инициирует запрос на выполнение определенных вычислений вне сети. Это может быть инициировано транзакцией пользователя или вызовом интерфейса ZK-копроцессора другим контрактом. Например, DeFi-контракт может вызвать «proveInterestRate(currentState)», или пользователь может вызвать «queryHistoricalData(query)».
2. Внечейновое выполнение и генерация доказательства (Off-Chain Execution & Proving) — внечейновая служба (которая может быть децентрализованной сетью пруверов или доверенным сервисом, в зависимости от дизайна) принимает запрос. Она собирает все необходимые данные (состояние блокчейна, внечейновые входные данные и т. д.) и выполняет вычисления в специальной ZK-виртуальной машине (ZKVM) или схеме. Во время выполнения генерируется трассировка доказательства. В конце служба выдает лаконичное доказательство (например, SNARK или STARK), подтверждающее, что «Вычисление функции F на входных данных X дает результат Y», и, опционально, подтверждающее целостность данных (подробнее об этом ниже).
3. Ончейн-верификация (On-Chain Verification) — доказательство и результат возвращаются в блокчейн (часто через функцию обратного вызова — callback). Контракт-верификатор проверяет валидность доказательства, используя эффективную криптографическую проверку (проверки спаривания и т. д.). Если доказательство валидно, контракт может доверять результату Y как верному. Результат может быть сохранен в состоянии, передан в виде события или использован в дальнейшей логике контракта. Если доказательство недействительно или не предоставлено в течение определенного времени, запрос считается неудачным (и потенциально срабатывает логика резервного копирования или тайм-аута).

Рисунок 1 : Архитектура ZK-копроцессора (на примере RISC Zero Bonsai). Вне сети программа запускается на ZKVM с входными данными из вызова смарт-контракта. Доказательство выполнения возвращается в сеть через реле-контракт, который инициирует обратный вызов с верифицированными результатами.

Крайне важно, что затраты газа в сети на верификацию являются постоянными (или растут очень медленно) независимо от того, насколько сложными были внечейновые вычисления. Верификация лаконичного доказательства может стоить порядка нескольких сотен тысяч единиц газа (небольшая часть блока Ethereum), но это доказательство может представлять миллионы вычислительных шагов, выполненных вне сети. Как пошутил один разработчик : «Хотите доказать одну цифровую подпись? ~ $15. Хотите доказать миллион подписей? Тоже ~ $15». Такая масштабируемость — огромный плюс : dApps могут предлагать сложные функции (аналитика больших данных, сложные финансовые модели и т. д.), не перегружая блокчейн.

Основными компонентами системы ZK-копроцессора являются :

• Среда генерации доказательств (Proof Generation Environment) : это может быть ZKVM общего назначения (способная запускать произвольные программы) или кастомные схемы, адаптированные для конкретных вычислений. Подходы различаются :

  • Некоторые проекты используют созданные вручную схемы (handcrafted circuits) для каждого поддерживаемого запроса или функции (максимизируя эффективность для этой функции).
  • Другие предоставляют предметно-ориентированный язык (DSL) или встроенный DSL (Embedded DSL), который разработчики используют для написания своей внечейновой логики, которая затем компилируется в схемы (балансируя между простотой использования и производительностью).
  • Самым гибким подходом является zkVM : виртуальная машина (часто на основе архитектур RISC), где программы могут быть написаны на стандартных языках (Rust, C и т. д.) и автоматически доказаны. Это требует определенных жертв в производительности (симуляция процессора в схеме добавляет накладные расходы) ради максимального удобства для разработчиков.

• Доступ к данным и их целостность : уникальной задачей является предоставление внечейновым вычислениям корректных данных, особенно если эти данные находятся в блокчейне (прошлые блоки, состояния контрактов и т. д.). Наивное решение — заставить прувера читать данные из архивного узла и доверять ему, но это вводит допущения о доверии. Вместо этого ZK-копроцессоры обычно доказывают, что любые используемые ончейн-данные действительно были аутентичными, связывая их с доказательствами Меркла или обязательствами по состоянию (state commitments). Например, программа запроса может принимать номер блока и доказательство Меркла для слота хранения или транзакции, а схема проверит это доказательство на соответствие известному хешу заголовка блока. Существует три паттерна :

  1. Встроенные данные (Inline Data) : поместить необходимые данные в блокчейн (как входные данные для верификатора), чтобы их можно было проверить напрямую. Это очень дорого для больших объемов данных и сводит на нет весь смысл использования копроцессора.
  2. Доверие оракулу : использовать сервис оракула для передачи данных в доказательство и поручительства за них. Это проще, но снова вводит доверие к третьей стороне.
  3. Доказательство включения данных через ZK : включить доказательства включения данных в историю блокчейна в саму схему с нулевым разглашением. Это использует тот факт, что каждый заголовок блока Ethereum фиксирует все предшествующее состояние (через корень состояния) и историю транзакций. Проверяя доказательства Merkle Patricia для данных внутри схемы, выходное доказательство гарантирует контракту, что «это вычисление использовало подлинные данные блокчейна из блока N» без необходимости в дополнительном доверии.

  Третий подход является наиболее бездоверительным (trustless) и используется продвинутыми ZK-копроцессорами, такими как Axiom и Xpansion (это увеличивает стоимость доказательства, но предпочтительнее с точки зрения безопасности). Например, система Axiom моделирует структуру блоков Ethereum, дерево состояний и дерево транзакций внутри своих схем, поэтому она может доказывать утверждения типа «аккаунт X имел баланс Y в блоке N» или «транзакция с определенными свойствами произошла в блоке N». Это позволяет, имея недавний доверенный хеш блока, рекурсивно доказывать включение исторических данных без доверия к какой-либо внешней стороне.

• Контракт-верификатор (Verifier Contract) : этот ончейн-контракт содержит ключ верификации и логику для принятия или отклонения доказательств. Для SNARK, таких как Groth16 или PLONK, верификатор может выполнять несколько спариваний на эллиптических кривых ; для STARK он может выполнять вычисления хешей. Оптимизация производительности, такая как агрегация и рекурсия, может минимизировать нагрузку на сеть. Например, Bonsai от RISC Zero использует STARK-to-SNARK обертку : он запускает VM на базе STARK вне сети для скорости, но затем генерирует небольшое доказательство SNARK, подтверждающее валидность STARK. Это уменьшает размер доказательства с сотен килобайт до нескольких сотен байт, что делает ончейн-верификацию осуществимой и дешевой. Верификатор на Solidity затем просто проверяет SNARK (что является операцией с константным временем).

С точки зрения развертывания, ZK-копроцессоры могут функционировать как сети, подобные L2, или как чистые внечейновые сервисы. Некоторые, как Axiom, начинались как специализированный сервис для Ethereum (при поддержке Paradigm), где разработчики отправляют запросы в сеть пруверов Axiom и получают доказательства в сети. Слоган Axiom заключался в предоставлении контрактам Ethereum «бездоверительного доступа ко всем ончейн-данным и произвольных выразительных вычислений над ними». Фактически он действует как оракул запросов, где ответы проверяются с помощью ZKP вместо доверия. Другие, такие как RISC Zero Bonsai, предлагают более открытую платформу : любой разработчик может загрузить программу (скомпилированную в ZKVM, совместимую с RISC-V) и использовать сервис доказательства Bonsai через реле-контракт (relay contract). Паттерн реле, как показано на рисунке 1, включает контракт, который опосредует запросы и ответы : контракт dApp вызывает реле, чтобы запросить доказательство, внечейновая служба отслеживает это (например, через событие или прямой вызов), вычисляет доказательство, а затем реле вызывает функцию обратного вызова в контракте dApp с результатом и доказательством. Эта асинхронная модель необходима, поскольку генерация доказательства может занимать от секунд до минут в зависимости от сложности. Это вносит задержку (latency) (и предположение о живучести, что прувер ответит), в то время как вычисления FHE-VM происходят синхронно внутри блока. Проектирование приложения для обработки этого асинхронного рабочего процесса (возможно, аналогично ответам оракулов) является частью использования ZK-копроцессора.

Известные проекты ZK-копроцессоров​

• Axiom : Axiom — это ZK-копроцессор, адаптированный для Ethereum, изначально ориентированный на доказательство запросов к историческим ончейн-данным. Он использует фреймворк доказательства Halo2 (SNARK типа Plonk) для создания доказательств, включающих криптографические структуры Ethereum. В системе Axiom разработчик может запрашивать такие вещи, как «каким было состояние контракта X в блоке N?» или выполнять вычисления по всем транзакциям в диапазоне. «Под капотом» схемы Axiom должны были реализовывать логику состояния/дерева Ethereum, даже выполняя операции на эллиптических кривых и верификацию SNARK внутри схемы для поддержки рекурсии. Trail of Bits в ходе аудита отметили сложность схем Halo2 от Axiom, моделирующих целые блоки и состояния. После аудита Axiom обобщили свою технологию в OpenVM, позволяющую доказывать произвольный код на Rust с использованием той же инфраструктуры на базе Halo2. (Это отражает тенденцию перехода от специализированных схем к более общему подходу ZKVM.) Команда Axiom продемонстрировала ZK-запросы, которые Ethereum нативно выполнять не может, обеспечивая безоборотный доступ (stateless access) к любым историческим данным с криптографической целостностью. Они также уделяли большое внимание безопасности, обнаруживая и исправляя ошибки в недостаточно ограниченных схемах (under-constrained circuits) и обеспечивая обоснованность (soundness). Хотя первоначальный продукт Axiom был закрыт во время их перехода на новую модель, их подход остается вехой в области ZK-копроцессоров.

• RISC Zero Bonsai : RISC Zero — это ZKVM на базе архитектуры RISC-V. Их zkVM может выполнять произвольные программы (написанные на Rust, C++ и других языках, скомпилированных в RISC-V) и генерировать STARK-доказательство выполнения. Bonsai — это облачный сервис RISC Zero, который предоставляет такие доказательства по запросу, выступая в роли копроцессора для смарт-контрактов. Чтобы использовать его, разработчик пишет программу (скажем, функцию, которая выполняет сложные математические вычисления или проверяет ответ внечейнового API), загружает ее в сервис Bonsai и развертывает соответствующий контракт-верификатор. Когда контракту требуется это вычисление, он вызывает реле Bonsai, которое запускает генерацию доказательства и возвращает результат через callback. Одним из продемонстрированных примеров применения стали внечейновые вычисления для управления (governance) : RISC Zero показали, как DAO использует Bonsai для подсчета голосов и вычисления сложных метрик голосования вне сети, а затем публикует доказательство, чтобы ончейн-контракт Governor мог доверять результату с минимальными затратами газа. Технология RISC Zero подчеркивает, что разработчики могут использовать знакомые парадигмы программирования — например, написание функции на Rust для чего-либо — а тяжелая работа по созданию схем берется на себя zkVM. Однако доказательства могут быть большими, поэтому, как отмечалось ранее, они реализовали сжатие SNARK для ончейн-верификации. В августе 2023 года они успешно верифицировали доказательства RISC Zero в тестовой сети Ethereum Sepolia, что стоило порядка 300 тысяч газа за одно доказательство. Это открывает двери для dApps в Ethereum для использования Bonsai уже сегодня в качестве решения для масштабируемости и приватности. (Bonsai все еще находится в стадии альфа-тестирования, не готов к промышленной эксплуатации и использует временную настройку SNARK без церемонии доверенной установки.)

• Другие : существует множество других игроков и исследовательских инициатив. Expansion/Xpansion (как упоминалось в одном из блогов) использует подход со встроенным DSL, где разработчики могут писать запросы к ончейн-данным на специализированном языке, а генерация доказательств происходит внутри системы. Cairo от StarkWare и zkEVM от Polygon — это более общие виртуальные машины ZK-rollup, но их технологии могут быть перепрофилированы для использования в качестве копроцессоров путем верификации доказательств в контрактах L1. Мы также видим проекты в области ZKML (ZK Machine Learning), которые фактически действуют как копроцессоры для верификации вывода моделей машинного обучения или результатов обучения в сети. Например, установка zkML может доказать, что «вывод нейронной сети на частных входных данных дал классификацию X» без раскрытия входных данных и без выполнения вычислений ончейн. Это частные случаи концепции копроцессора, применимые к ИИ.

Допущения о доверии : ZK-копроцессоры полагаются на обоснованность (soundness) криптографических доказательств. Если система доказательств безопасна (и любая доверенная установка выполнена честно), то принятое доказательство гарантирует правильность вычислений. Никакого дополнительного доверия к пруверу не требуется — даже злонамеренный прувер не сможет убедить верификатора в ложном утверждении. Однако существует предположение о живучести (liveness) : кто-то должен фактически выполнить внечейновое вычисление и создать доказательство. На практике это может быть децентрализованная сеть (со стимулами или комиссиями за работу) или оператор одного сервиса. Если никто не предоставит доказательство, ончейн-запрос может остаться нерешенным. Другим тонким аспектом доверия является доступность данных для внечейновых входных данных, которых нет в блокчейне. Если вычисление зависит от каких-то частных или внешних данных, верификатор не может знать, были ли эти данные предоставлены честно, если не используются дополнительные меры (такие как обязательства по данным или подписи оракулов). Но для вычислений на чисто ончейн-данных описанные механизмы обеспечивают бездоверительность, эквивалентную самой сети (Axiom утверждали, что их доказательства обеспечивают «безопасность, криптографически эквивалентную Ethereum» для исторических запросов).

Приватность : доказательства с нулевым разглашением также по своей природе поддерживают приватность — прувер может скрывать входные данные, доказывая утверждения о них. В контексте копроцессора это означает, что доказательство может позволить контракту использовать результат, полученный на основе частных данных. Например, доказательство может показать, что «кредитный рейтинг пользователя > 700, поэтому одобрить кредит» без раскрытия фактического кредитного рейтинга или исходных данных. Вариант использования Axiom был больше связан с общедоступными данными (историей блокчейна), поэтому приватность там не была в центре внимания. Но zkVM от RISC Zero можно использовать для доказательства утверждений о секретных данных, предоставленных пользователем : данные остаются вне сети, и в сеть попадает только необходимый результат. Стоит отметить, что, в отличие от FHE, ZK-доказательство обычно не обеспечивает постоянную конфиденциальность состояния — это разовое доказательство. Если рабочий процесс требует сохранения секретного состояния между транзакциями, его можно построить так, чтобы контракт хранил обязательство (commitment) к состоянию, а каждое доказательство показывало валидный переход из старого обязательства в новое с сохранением секретов в тайне. Именно так работают zk-роллапы для частных транзакций (такие как Aztec или Zcash). Таким образом, ZK-копроцессоры могут способствовать созданию полностью приватных машин состояний, но реализация этого нетривиальна ; часто они используются для разовых вычислений, где либо входные, либо выходные данные (или и то, и другое) могут быть приватными по мере необходимости.

Опыт разработчиков : использование ZK-копроцессора обычно требует освоения новых инструментов. Написание кастомных схем (вариант (1) выше) довольно сложно и обычно делается только для узких целей. Варианты более высокого уровня, такие как DSL или zkVM, облегчают жизнь, но все равно добавляют накладные расходы : разработчик должен написать и развернуть внечейновый код и управлять взаимодействием. В отличие от FHE-VM, где шифрование в основном обрабатывается «за кулисами» и разработчик пишет обычный код смарт-контракта, здесь разработчику нужно разделить свою логику и, возможно, писать на другом языке (Rust и т. д.) для внечейновой части. Тем не менее, такие инициативы, как DSL Noir, Leo, Circom или подход RISC Zero, быстро улучшают доступность. Например, RISC Zero предоставляет шаблоны и интеграцию с Foundry, благодаря чему разработчик может симулировать свой внечейновый код локально (для проверки правильности), а затем беспрепятственно подключить его к тестам на Solidity через callback Bonsai. Со временем можно ожидать появления фреймворков разработки, которые абстрагируют вопрос о том, выполняется ли фрагмент логики через ZK-доказательство или ончейн — компилятор или инструментарий могут принимать решение на основе стоимости.

Сравнение FHE-VM и ZK-копроцессоров​

И FHE-VM, и ZK-копроцессоры позволяют выполнять форму «вычислений на частных данных с ончейн-гарантиями», но они фундаментально различаются по архитектуре. В таблице ниже приведены основные различия :

| Обеспечение целостности | По конструкции все валидаторы гомоморфно пересчитывают следующее состояние, поэтому если злоумышленник предоставит неверный результат в виде шифротекста, остальные обнаружат несоответствие — консенсус не будет достигнут, пока все не получат одинаковый результат. Таким образом, целостность обеспечивается избыточным выполнением (как в обычном блокчейне, только над зашифрованными данными). Дополнительные ZK-доказательства часто используются для обеспечения соблюдения бизнес-правил (например, что пользователь не нарушил ограничение), так как валидаторы не могут напрямую проверять условия в открытом тексте. | Целостность обеспечивается контрактом-верификатором, проверяющим ZK-доказательство. Пока доказательство проходит проверку, результат гарантированно соответствует некоторому валидному выполнению внечейновой программы. Для корректности не требуется предположение о честном большинстве — достаточно даже одного честного верификатора (самого кода контракта). Ончейновый контракт просто отклонит любое ложное или отсутствующее доказательство (подобно тому, как он отклонил бы недействительную подпись). Один нюанс: если прувер прервет работу или задержит её, контракту может понадобиться резервная логика (или пользователям придется повторить попытку позже), но он не примет неверные результаты. | | Опыт разработчика | Плюсы: Можно в значительной степени использовать знакомые языки смарт-контрактов (Solidity и др.) с расширениями. Конфиденциальность обрабатывается платформой — разработчики беспокоятся в основном о том, что именно шифровать и кто владеет ключами. Возможна композиция зашифрованных и обычных контрактов, что сохраняет компонуемость DeFi (просто с зашифрованными переменными). Минусы: Необходимо понимать ограничения FHE — например, отсутствие прямых условных переходов по секретным данным без специальной обработки, ограниченная глубина схемы (хотя бутстрапинг в TFHE позволяет выполнять вычисления произвольной длины за счет времени). Отладка зашифрованной логики может быть сложной, так как вы не можете легко просматривать значения во время выполнения без ключа. Также управление ключами и распределение прав доступа усложняют проектирование контракта. | Плюсы: Потенциальная возможность использовать любой язык программирования для внечейновой части (особенно с zkVM). Использование существующего кода/библиотек во внечейновой программе (с оговорками относительно ZK-совместимости). Разработчику не требуется специальная криптография при использовании общей zkVM — он пишет обычный код и получает доказательство. Кроме того, тяжелые вычисления могут использовать библиотеки (например, код машинного обучения), которые никогда бы не запустились ончейн. Минусы: Разработчики должны координировать внечейновую инфраструктуру или использовать сервис доказательств. Обработка асинхронных рабочих процессов и их интеграция с ончейн-логикой требуют больше проектной работы (например, хранение ожидающего состояния, ожидание обратного вызова). Написание эффективных схем или кода для zkVM может потребовать изучения новых ограничений (например, отсутствие плавающей запятой, использование фиксированной запятой или специальных примитивов; избегание тяжелого ветвления, которое раздувает время доказательства; оптимизация количества ограничений). Также существует нагрузка, связанная с обработкой сбоев доказательств, таймаутов и т. д., которые не являются проблемой в обычном Solidity. Экосистема инструментов растет, но для многих это новая парадигма. |

Оба подхода активно совершенствуются, и мы даже видим их конвергенцию: как уже отмечалось, ZK-доказательства используются внутри FHE-VM для определенных проверок, и наоборот, некоторые исследователи предлагают использовать FHE, чтобы сохранять входные данные прувера приватными в ZK (чтобы облачный прувер не видел ваши секретные данные). Вполне возможно, что будущие системы будут их комбинировать — например, выполнение FHE вне сети с последующим доказательством корректности этого процесса в сети, или использование FHE ончейн, но с ZK-доказательством для легких клиентов о том, что зашифрованные операции были выполнены верно. Каждая техника имеет свои сильные стороны: FHE-VM предлагает непрерывную приватность и взаимодействие в реальном времени ценой тяжелых вычислений, в то время как ZK-копроцессоры предлагают масштабируемость и гибкость ценой задержки и сложности.

Сценарии использования и последствия​

Появление программируемой приватности открывает массу новых блокчейн-приложений в различных отраслях. Ниже мы рассмотрим, как FHE-VM и ZK-копроцессоры (или гибриды) могут расширить возможности различных областей, обеспечивая работу смарт-контрактов с сохранением конфиденциальности и безопасную экономику данных.

Конфиденциальный DeFi и финансы​

В децентрализованных финансах приватность может смягчить проблему фронтраннинга, защитить торговые стратегии и обеспечить соблюдение нормативных требований без ущерба для прозрачности там, где она необходима. Конфиденциальный DeFi позволит пользователям взаимодействовать с протоколами, не раскрывая свои позиции всему миру.

• Приватные транзакции и скрытые балансы: С помощью FHE можно реализовать конфиденциальные переводы токенов (зашифрованные балансы ERC-20 и транзакции) или экранированные пулы на L1 блокчейне. Ни один наблюдатель не сможет увидеть, сколько токенов вы храните или перевели, что устраняет риск целевых атак на основе ваших активов. ZK-доказательства могут гарантировать синхронизацию балансов и отсутствие двойных трат (аналогично Zcash, но на платформах смарт-контрактов). Примером является конфиденциальный AMM (автоматизированный маркет-мейкер), где резервы пула и сделки зашифрованы ончейн. Арбитражники или фронтраннеры не могут эксплуатировать пул, так как они не видят проскальзывание цены до завершения сделки, что снижает MEV. Только после некоторой задержки или через механизм контроля доступа часть данных может быть раскрыта для аудита.

• Аукционы и торговля, устойчивые к MEV: Майнеры и боты используют прозрачность транзакций для фронтраннинга сделок. С помощью шифрования можно создать зашифрованный мемпул или пакетные аукционы, где ордера подаются в виде шифротекста. Сделки дешифруются только после закрытия аукциона. Эта концепция, иногда называемая Fair Order Flow (справедливый поток ордеров), может быть реализована с помощью пороговой дешифровки (несколько валидаторов коллективно расшифровывают пакет) или путем доказательства результатов аукциона через ZK без раскрытия индивидуальных ставок. Например, ZK-копроцессор может принять пакет запечатанных ставок вне сети, вычислить цену закрытия аукциона и выдать только эту цену и список победителей с доказательствами. Это сохраняет справедливость и конфиденциальность проигравших ставок.

• Конфиденциальное кредитование и деривативы: В DeFi-кредитовании пользователи могут не хотеть раскрывать размер своих займов или залога (это может повлиять на рыночные настроения или спровоцировать эксплуатацию). FHE-VM может поддерживать зашифрованную книгу займов, где детали каждого кредита зашифрованы. Логика смарт-контракта по-прежнему может обеспечивать соблюдение правил, таких как условия ликвидации, оперируя зашифрованными показателями здоровья займа. Если коэффициент обеспечения займа падает ниже порогового значения, контракт (с помощью ZK-доказательств) может пометить его для ликвидации, не раскрывая точных значений — он может просто выдать флаг "да/нет" в открытом тексте. Аналогично, секретные позиции по деривативам или опционам могут управляться ончейн с раскрытием только агрегированных показателей риска. Это предотвратит копитрейдинг и защитит проприетарные стратегии, стимулируя участие институционалов.

• Соответствие регуляторным нормам при сохранении приватности: Не во всех финансовых контекстах нужна полная анонимность; иногда для регулирования требуется избирательное раскрытие. С помощью этих инструментов мы можем достичь регулируемой приватности: например, сделки приватны для общественности, но регулируемая биржа может расшифровать или получить доказательства определенных свойств. Можно доказать через ZK, что "эта сделка не связана с адресом из черного списка и обе стороны прошли проверку KYC", не раскрывая личности в сети. Этот баланс может удовлетворить правила по борьбе с отмыванием денег (AML), сохраняя при этом личности и позиции пользователей в секрете от всех остальных. FHE может позволить ончейн-контракту офицера по комлпаенсу сканировать зашифрованные транзакции на наличие сигналов риска (с ключом расшифровки, доступным, например, только по решению суда).

Цифровая идентичность и персональные данные​

Системы идентификации значительно выиграют от технологий ончейн-приватности. В настоящее время размещение личных учетных данных или атрибутов в публичном реестре нецелесообразно из-за законов о конфиденциальности и нежелания пользователей. С FHE и ZK самосуверенная идентичность (SSI) может быть реализована с сохранением приватности:

• Учетные данные с нулевым разглашением: Используя ZK-доказательства (уже распространенные в некоторых проектах идентификации), пользователь может доказать такие утверждения, как "мне больше 18 лет", "у меня есть действующие водительские права" или "мой доход превышает 50 000 долларов (для кредитного скоринга)", не раскрывая никакой другой личной информации. ZK-копроцессоры могут расширить это, обрабатывая более сложные проверки вне сети, например, доказывая, что кредитный рейтинг пользователя выше порога, путем запроса к приватной кредитной базе данных в стиле Axiom, выдавая блокчейну только ответ "да/нет".

• Конфиденциальный KYC в DeFi: Представьте себе DeFi-протокол, который по закону должен гарантировать, что пользователи прошли KYC. С помощью FHE-VM учетные данные пользователя могут храниться в зашифрованном виде ончейн (или по ссылке через DID), а смарт-контракт может выполнять FHE-вычисления для проверки соответствия KYC требованиям. Например, контракт может гомоморфно проверить, совпадают ли имя и номер социального страхования в зашифрованном профиле пользователя со списком санкционных лиц (также зашифрованным), или что страна пользователя не ограничена. Контракт получит только зашифрованный результат "пройдено/не пройдено", который может быть расшифрован валидаторами сети в логический флаг. Раскрывается только факт допуска пользователя, сохраняя конфиденциальность PII (персонально идентифицируемой информации) и соблюдая принципы GDPR. Такое избирательное раскрытие обеспечивает и комлпаенс, и приватность.

• Доступ на основе атрибутов и избирательное раскрытие: Пользователи могут хранить множество верифицируемых учетных данных (возраст, гражданство, навыки и т. д.) как зашифрованные атрибуты. Они могут разрешать определенным dApps выполнять вычисления над ними без раскрытия всего объема данных. Например, децентрализованное приложение для рекрутинга может фильтровать кандидатов, выполняя поиск по зашифрованным резюме (используя FHE) — например, подсчитать годы опыта, проверить наличие сертификата — и только если соответствие найдено, связаться с кандидатом вне сети. Личные данные кандидата остаются зашифрованными, пока он сам не решит их раскрыть. ZK-доказательства также позволяют пользователям выборочно доказывать, что они обладают комбинацией атрибутов (например, старше 21 года и проживают в определенном почтовом индексе) без раскрытия самих значений.

• Многосторонняя проверка личности: Иногда личность пользователя должна быть проверена несколькими сторонами (например, проверка биографии компанией А, кредитная проверка компанией Б). С помощью гомоморфных и ZK-инструментов каждый проверяющий может внести зашифрованный балл или одобрение, а смарт-контракт может агрегировать их для принятия окончательного решения, не раскрывая отдельные вклады. Например, три агентства предоставляют зашифрованные биты "пройдено/не пройдено", и контракт выдает одобрение, если все три — "пройдено". Пользователь или полагающаяся сторона видят только конечный результат, а не то, какое конкретно агентство могло отказать, что сохраняет приватность записей пользователя в каждом агентстве. Это может снизить предвзятость и стигматизацию.

Здравоохранение и обмен конфиденциальными данными​

Медицинские данные строго регулируются, однако объединение данных из нескольких источников может принести огромную пользу (для исследований, страхования, персонализированной медицины). Блокчейн мог бы стать доверительным уровнем для обмена данными, если вопрос приватности будет решен. Конфиденциальные смарт-контракты могут открыть новые экосистемы данных о здоровье:

• Безопасный обмен медицинскими данными: Пациенты могут хранить ссылки на свои медицинские записи в блокчейне в зашифрованном виде. Контракт с поддержкой FHE позволит исследовательскому институту проводить аналитику на когорте данных пациентов, не расшифровывая их. Например, контракт может вычислить среднюю эффективность лекарства на основе зашифрованных результатов лечения. Дешифруются только агрегированные статистические результаты (и, возможно, только если включено минимальное количество пациентов, чтобы предотвратить повторную идентификацию). Пациенты могут получать микроплатежи за предоставление своих зашифрованных данных для исследований, зная, что их приватность сохранена, так как даже блокчейн и исследователи видят только шифротекст или агрегированные доказательства. Это способствует созданию рынка данных для здравоохранения, уважающего частную жизнь.

• Страховые выплаты с сохранением приватности: Обработка претензий по медицинскому страхованию может быть автоматизирована с помощью смарт-контрактов, которые проверяют условия на медицинских данных, не раскрывая их страховщику. Претензия может включать зашифрованный код диагноза и зашифрованную стоимость лечения; контракт, используя FHE, проверяет правила полиса (например, покрытие, франшизу) на этих зашифрованных данных. Он может выдать одобрение и сумму выплаты, так и не раскрыв фактический диагноз в блокчейне страховщика (ключ есть только у пациента и врача). ZK-доказательства могут использоваться для подтверждения того, что данные пациента поступили из сертифицированных записей больницы (используя что-то вроде Axiom для проверки подписи больницы), не раскрывая саму запись. Это обеспечивает приватность пациента при предотвращении мошенничества.

• Вычисления над геномными и персональными данными: Геномные данные чрезвычайно чувствительны (это буквально ДНК-чертеж человека). Однако анализ геномов может дать ценную информацию о здоровье. Компании могут использовать FHE-VM для выполнения вычислений над зашифрованными геномами, загруженными пользователями. Например, смарт-контракт может запустить модель оценки риска "гены-среда" на зашифрованных геномных данных и зашифрованных данных об окружающей среде (возможно, с носимых устройств), выдавая оценку риска, которую может расшифровать только пользователь. Логика (возможно, алгоритм полигенной оценки риска) закодирована в контракте и выполняется гомоморфно, поэтому геномные данные никогда не появляются в открытом виде. Таким образом, пользователи получают ценные сведения, не передавая компаниям необработанные данные ДНК, что снимает опасения как по поводу приватности, так и владения данными.

• Эпидемиология и общественное здравоохранение: В таких ситуациях, как пандемии, обмен данными жизненно важен для моделирования распространения болезней, но законы о приватности могут этому мешать. ZK-копроцессоры могут позволить органам здравоохранения отправлять запросы типа "Сколько людей в регионе X получили положительный результат теста за последние 24 часа?" к сети данных больниц через доказательства. Каждая больница хранит записи тестов пациентов вне сети, но может доказать контракту ведомства количество положительных случаев, не раскрывая имен. Аналогично, отслеживание контактов может выполняться путем сопоставления зашифрованных маршрутов перемещения: контракты могут вычислять пересечения зашифрованных историй местоположений пациентов для выявления очагов, выдавая только координаты очагов (и, возможно, зашифрованный список затронутых ID, который может расшифровать только минздрав). Исходные маршруты перемещения отдельных лиц остаются приватными.

Рынки данных и сотрудничество​

Возможность вычислять данные без их раскрытия открывает новые бизнес-модели. Организации могут сотрудничать в вычислениях, зная, что их проприетарные данные не будут раскрыты:

• Безопасные рынки данных: Продавцы могут выставлять данные в зашифрованном виде на блокчейн-маркетплейсе. Покупатели могут платить за запуск конкретной аналитики или моделей машинного обучения на зашифрованном наборе данных через смарт-контракт, получая либо обученную модель, либо агрегированные результаты. Исходные данные продавца никогда не раскрываются покупателю или общественности — покупатель может получить только модель (которая все еще может давать утечку информации через веса, но такие методы, как дифференциальная приватность или контроль детализации вывода, могут это минимизировать). ZK-доказательства могут гарантировать покупателю, что вычисления были выполнены правильно над обещанным набором данных (например, продавец не может сжульничать, запустив модель на фиктивных данных, потому что доказательство привязывает результат к зашифрованному набору). Это стимулирует общие данные: например, компания может монетизировать данные о поведении пользователей, позволяя одобренным алгоритмам работать с ними под шифрованием, не отдавая сами данные.

• Федеративное обучение и децентрализованный ИИ: В децентрализованном машинном обучении несколько сторон (например, разные компании или устройства) хотят совместно обучить модель на своих объединенных данных, не делясь ими друг с другом. FHE-VM здесь незаменимы: они позволяют реализовать федеративное обучение, где обновления моделей каждой стороны гомоморфно агрегируются контрактом. Поскольку обновления зашифрованы, ни один участник не узнает вклад других. Контракт может даже выполнять части цикла обучения (например, шаги градиентного спуска) ончейн под шифрованием, создавая обновленную модель, которую могут расшифровать только авторизованные стороны. ZK может дополнить это, доказывая, что обновление каждой стороны было вычислено в соответствии с алгоритмом обучения (предотвращая отравление модели вредоносным участником). Это означает, что глобальная модель может быть обучена с полной возможностью аудита ончейн, но обучающие данные каждого участника остаются приватными. Примеры использования включают совместное обучение моделей обнаружения мошенничества в разных банках или улучшение ИИ-ассистентов без централизации необработанных данных.

• Межорганизационная аналитика: Рассмотрим две компании, которые хотят найти пересечение своих клиентов для партнерской кампании, не раскрывая друг другу полные списки клиентов. Они могут зашифровать свои списки идентификаторов клиентов и загрузить обязательство (commitment). Контракт с поддержкой FHE может вычислить пересечение на зашифрованных наборах (используя методы приватного пересечения множеств через FHE). Результатом может быть зашифрованный список общих ID клиентов, который может расшифровать только доверенная третья сторона (или сами клиенты через определенный механизм). Альтернативно, подход ZK: одна сторона доказывает другой с нулевым разглашением, что "у нас есть N общих клиентов, и вот шифрование этих ID" с доказательством того, что шифрование действительно соответствует общим записям. Таким образом, они могут начать кампанию для этих N клиентов, не обмениваясь полными списками в открытом виде. Аналогичные сценарии: вычисление метрик цепочки поставок между конкурентами без раскрытия данных о конкретных поставщиках или объединение кредитной информации банками без обмена полными данными о клиентах.

• Безопасные многосторонние вычисления (MPC) на блокчейне: FHE и ZK, по сути, переносят концепции MPC ончейн. Сложная бизнес-логика, охватывающая несколько организаций, может быть закодирована в смарт-контракте так, что входные данные каждой организации будут секретно распределены или зашифрованы. Контракт (как фасилитатор MPC) выдает результаты, такие как разделение прибыли, расчет затрат или совместная оценка рисков, которым все могут доверять. Например, несколько энергетических компаний хотят провести расчеты на рынке торговли электроэнергией. Они могут подать свои зашифрованные заявки и предложения в аукционный смарт-контракт; контракт вычисляет цены закрытия и распределение на основе зашифрованных заявок и выдает каждой компании её распределение и стоимость только этой компании (путем шифрования на её публичный ключ). Ни одна компания не видит заявок других, что защищает конкурентную информацию, но результат аукциона честен и верифицируем. Эта комбинация прозрачности блокчейна и приватности MPC может произвести революцию в консорциумах и корпоративных объединениях, которые сейчас полагаются на доверенных посредников.

Децентрализованное машинное обучение (ZKML и FHE-ML)​

Внедрение машинного обучения в блокчейны верифицируемым и приватным способом — это новый рубеж:

• Верифицируемый вывод (инференс) ML: Используя ZK-доказательства, можно доказать, что "модель машинного обучения f при заданном входе x выдает результат y", не раскрывая либо x (если это приватные данные), либо внутреннюю работу f (если веса модели проприетарны). Это критически важно для ИИ-сервисов на блокчейне — например, для децентрализованного ИИ-оракула, который предоставляет прогнозы или классификации. ZK-копроцессор может запустить модель вне сети (так как модели могут быть большими и дорогими в расчете) и опубликовать доказательство результата. Например, оракул может доказать утверждение: "Предоставленный спутниковый снимок показывает наличие лесного покрова не менее 50%" для поддержки контракта на углеродные кредиты, не раскрывая сам снимок или, возможно, саму модель. Это известно как ZKML, и проекты работают над оптимизацией нейросетей, "дружественных" к схемам доказательств. Это гарантирует целостность выводов ИИ, используемых в смарт-контрактах, и может сохранять конфиденциальность входных данных и параметров модели.

• Обучение с приватностью и аудитом: Обучение ML-модели требует еще больших вычислительных затрат, но если это станет достижимым, это позволит создать блокчейн-маркетплейсы моделей. Несколько поставщиков данных могли бы участвовать в обучении модели под FHE, чтобы алгоритм обучения работал на зашифрованных данных. Результатом может быть зашифрованная модель, которую может расшифровать только покупатель. На протяжении всего процесса обучения могут периодически предоставляться ZK-доказательства, подтверждающие, что обучение шло по протоколу (предотвращая, например, вставку бэкдора вредоносным тренером). Хотя полностью ончейн-обучение ML пока далеко из-за затрат, гибридный подход может использовать внечейновые вычисления с ZK-доказательствами для критических частей. Можно представить децентрализованное соревнование типа Kaggle, где участники обучают модели на приватных наборах данных и отправляют ZK-доказательства точности модели на зашифрованных тестовых данных для определения победителя — и всё это без раскрытия самих датасетов или тестовых данных.

• Персонализированный ИИ и владение данными: С помощью этих технологий пользователи смогут сохранять право собственности на свои личные данные и при этом пользоваться преимуществами ИИ. Например, мобильное устройство пользователя может использовать FHE для шифрования данных об использовании и отправлять их в аналитический контракт, который вычисляет персонализированную модель ИИ (например, рекомендательную модель) только для него. Модель зашифрована, и только устройство пользователя может расшифровать и использовать её локально. Платформа (возможно, социальная сеть) никогда не видит необработанные данные или модель, но пользователь получает преимущества ИИ. Если платформа хочет получить агрегированную информацию, она может запросить ZK-доказательства определенных агрегированных паттернов у контракта без доступа к индивидуальным данным.

Дополнительные области​

• Игры: Ончейн-игры часто сталкиваются с трудностями при скрытии секретной информации (например, скрытые карты в руке, "туман войны" в стратегиях). FHE позволяет создавать игры со скрытым состоянием, где игровая логика работает на зашифрованном состоянии. Например, контракт для игры в покер может тасовать и раздавать зашифрованные карты; игроки получают дешифровку своих собственных карт, но контракт и другие видят только шифротекст. Логика ставок может использовать ZK-доказательства, чтобы гарантировать, что игрок не блефует по поводу действия (или чтобы раскрыть выигрышную руку в конце верифицируемо честным способом). Аналогично, случайные числа для минтинга NFT или игровых исходов могут генерироваться и доказываться как честные без раскрытия исходного значения (seed), что предотвращает манипуляции. Это может значительно улучшить блокчейн-игры, позволяя им поддерживать ту же динамику, что и традиционные игры.

• Голосование и управление: DAO могут использовать технологии приватности для тайного голосования ончейн, исключая подкуп голосов и давление. FHE-VM может подсчитывать голоса, поданные в зашифрованном виде, и только итоговые суммы будут расшифрованы. ZK-доказательства могут подтвердить, что каждый голос был действительным (поступил от имеющего право голоса участника, который не голосовал дважды), не раскрывая, кто за что проголосовал. Это обеспечивает верифицируемость (каждый может проверить доказательства и подсчет), сохраняя при этом индивидуальные голоса в секрете, что крайне важно для непредвзятого управления.

• Безопасные цепочки поставок и IoT: В цепочках поставок партнеры могут захотеть поделиться доказательством определенных свойств (происхождение, показатели качества), не раскрывая полных деталей конкурентам. Например, датчик IoT на партии продуктов питания может непрерывно отправлять зашифрованные данные о температуре в блокчейн. Контракт может использовать FHE, чтобы проверить, оставалась ли температура в безопасном диапазоне на протяжении всего пути. Если порог был превышен, это может вызвать оповещение или штраф, но при этом нет необходимости публично раскрывать весь журнал температур — возможно, только доказательство или агрегат, такой как "90-й процентиль температуры". Это укрепляет доверие к автоматизации цепочек поставок при соблюдении конфиденциальности технологических данных.

Каждый из этих сценариев использует ключевую возможность: вычислять или проверять данные, не раскрывая их. Эта способность может фундаментально изменить то, как мы работаем с конфиденциальной информацией в децентрализованных системах. Она снижает компромисс между прозрачностью и приватностью, который ограничивал внедрение блокчейна в областях, связанных с частными данными.

title: Заключение: Эра программируемой конфиденциальности description: Узнайте о будущем блокчейн-технологий и программируемой конфиденциальности через призму FHE-VM и ZK-копроцессоров. keywords:

• блокчейн
• программируемая конфиденциальность
• FHE-VM
• ZK-копроцессоры
• Web3
• криптография
• смарт-контракты tags: [blockchain, web3, privacy, cryptography] image: "https://opengraph-image.blockeden.xyz/api/og-blockeden-xyz?title=%D0%97%D0%B0%D0%BA%D0%BB%D1%8E%D1%87%D0%B5%D0%BD%D0%B8%D0%B5%3A%20%D0%AD%D1%80%D0%B0%20%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D1%83%D0%B5%D0%BC%D0%BE%D0%B9%20%D0%BA%D0%BE%D0%BD%D1%84%D0%B8%D0%B4%D0%B5%D0%BD%D1%86%D0%B8%D0%B0%D0%BB%D1%8C%D0%BD%D0%BE%D1%81%D1%82%D0%B8%22%0A%0A%23%23%20%D0%97%D0%B0%D0%BA%D0%BB%D1%8E%D1%87%D0%B5%D0%BD%D0%B8%D0%B5%0A%0A%D0%A2%D0%B5%D1%85%D0%BD%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D1%8F%20%D0%B1%D0%BB%D0%BE%D0%BA%D1%87%D0%B5%D0%B9%D0%BD%20%D0%B2%D1%81%D1%82%D1%83%D0%BF%D0%B0%D0%B5%D1%82%20%D0%B2%20%D0%BD%D0%BE%D0%B2%D1%83%D1%8E%20%D1%8D%D1%80%D1%83%20**%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D1%83%D0%B5%D0%BC%D0%BE%D0%B9%20%D0%BA%D0%BE%D0%BD%D1%84%D0%B8%D0%B4%D0%B5%D0%BD%D1%86%D0%B8%D0%B0%D0%BB%D1%8C%D0%BD%D0%BE%D1%81%D1%82%D0%B8**%2C%20%D0%B3%D0%B4%D0%B5%20%D0%BA%D0%BE%D0%BD%D1%84%D0%B8%D0%B4%D0%B5%D0%BD%D1%86%D0%B8%D0%B0%D0%BB%D1%8C%D0%BD%D0%BE%D1%81%D1%82%D1%8C%20%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85%20%D0%B8%20%D1%84%D1%83%D0%BD%D0%BA%D1%86%D0%B8%D0%BE%D0%BD%D0%B0%D0%BB%D1%8C%D0%BD%D0%BE%D1%81%D1%82%D1%8C%20%D1%81%D0%BC%D0%B0%D1%80%D1%82-%D0%BA%D0%BE%D0%BD%D1%82%D1%80%D0%B0%D0%BA%D1%82%D0%BE%D0%B2%20%D0%B8%D0%B4%D1%83%D1%82%20%D1%80%D1%83%D0%BA%D0%B0%20%D0%BE%D0%B1%20%D1%80%D1%83%D0%BA%D1%83.%20%D0%9F%D0%B0%D1%80%D0%B0%D0%B4%D0%B8%D0%B3%D0%BC%D1%8B%20FHE-VM%20%D0%B8%20ZK-%D0%BA%D0%BE%D0%BF%D1%80%D0%BE%D1%86%D0%B5%D1%81%D1%81%D0%BE%D1%80%D0%BE%D0%B2%2C%20%D1%85%D0%BE%D1%82%D1%8F%20%D0%B8%20%D1%80%D0%B0%D0%B7%D0%BB%D0%B8%D1%87%D0%B0%D1%8E%D1%82%D1%81%D1%8F%20%D1%82%D0%B5%D1%85%D0%BD%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%2C%20%D1%81%D1%82%D1%80%D0%B5%D0%BC%D1%8F%D1%82%D1%81%D1%8F%20%D1%80%D0%B0%D1%81%D1%88%D0%B8%D1%80%D0%B8%D1%82%D1%8C%20%D1%81%D1%84%D0%B5%D1%80%D1%83%20%D0%BF%D1%80%D0%B8%D0%BC%D0%B5%D0%BD%D0%B5%D0%BD%D0%B8%D1%8F%20%D0%B1%D0%BB%D0%BE%D0%BA%D1%87%D0%B5%D0%B9%D0%BD-%D0%BF%D1%80%D0%B8%D0%BB%D0%BE%D0%B6%D0%B5%D0%BD%D0%B8%D0%B9%2C%20%D1%80%D0%B0%D0%B7%D0%B4%D0%B5%D0%BB%D1%8F%D1%8F%20%D1%82%D0%BE%2C%20*%D1%87%D1%82%D0%BE*%20%D0%BC%D1%8B%20%D0%BC%D0%BE%D0%B6%D0%B5%D0%BC%20%D0%B2%D1%8B%D1%87%D0%B8%D1%81%D0%BB%D0%B8%D1%82%D1%8C%2C%20%D0%B8%20%D1%82%D0%BE%2C%20*%D1%87%D1%82%D0%BE*%20%D0%BC%D1%8B%20%D0%B4%D0%BE%D0%BB%D0%B6%D0%BD%D1%8B%20%D1%80%D0%B0%D1%81%D0%BA%D1%80%D1%8B%D1%82%D1%8C.%0A%0A%D0%92%D0%B8%D1%80%D1%82%D1%83%D0%B0%D0%BB%D1%8C%D0%BD%D1%8B%D0%B5%20%D0%BC%D0%B0%D1%88%D0%B8%D0%BD%D1%8B%20%D1%81%20%D0%BF%D0%BE%D0%BB%D0%BD%D0%BE%D1%81%D1%82%D1%8C%D1%8E%20%D0%B3%D0%BE%D0%BC%D0%BE%D0%BC%D0%BE%D1%80%D1%84%D0%BD%D1%8B%D0%BC%20%D1%88%D0%B8%D1%84%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5%D0%BC%20(FHE-VM) сохраняют вычисления ончейн и в зашифрованном виде, поддерживая децентрализацию и компонуемость, но требуя достижений в области эффективности. ZK-копроцессоры переносят тяжелые вычисления в оффчейн, обеспечивая практически неограниченные вычисления под криптографическими гарантиями, и уже доказывают свою ценность в масштабировании и улучшении Ethereum. Выбор между ними (и их гибридами) будет зависеть от конкретного сценария использования: если требуется взаимодействие с приватным состоянием в реальном времени, подход FHE может быть более подходящим; если требуются чрезвычайно сложные вычисления или интеграция с существующим кодом, ZK-копроцессор может стать оптимальным решением. Во многих случаях они дополняют друг друга — действительно, мы видим, как ZK-доказательства укрепляют целостность FHE, а FHE потенциально помогает ZK, обрабатывая частные данные для пруверов (provers).

Для разработчиков эти технологии представят новые паттерны проектирования. Мы будем мыслить категориями зашифрованных переменных и верификации доказательств как первоклассных элементов архитектуры dApp. Инструментарий стремительно развивается: языки высокого уровня и SDK абстрагируют криптографические детали (например, библиотеки Zama делают типы FHE такими же простыми, как нативные типы, или шаблоны RISC Zero для запросов на доказательства). Через несколько лет написание конфиденциального смарт-контракта может стать почти таким же простым, как написание обычного, но с конфиденциальностью, «встроенной» по умолчанию.

Последствия для экономики данных огромны. Частные лица и предприятия будут более охотно размещать данные или логику ончейн, когда смогут контролировать их видимость. Это может открыть путь к межорганизационному сотрудничеству, новым финансовым продуктам и моделям ИИ, которые ранее были невозможны из-за проблем с конфиденциальностью. Регуляторы также могут начать использовать эти методы, поскольку они позволяют проводить проверки на соответствие и аудит криптографическими средствами (например, доказывая правильность уплаты налогов ончейн без раскрытия всех транзакций).

Мы все еще находимся на ранних этапах — текущие прототипы FHE-VM имеют ограничения производительности, а ZK-доказательства, хотя и стали намного быстрее, все еще могут быть узким местом для чрезвычайно сложных задач. Но непрерывные исследования и инженерные усилия (включая специализированное оборудование, например, разработки компаний вроде Optalysys, продвигающих оптическое ускорение FHE) быстро устраняют эти барьеры. Финансирование, вливающееся в это пространство (например, статус «единорога» у Zama, инвестиции Paradigm в Axiom), подчеркивает сильную веру в то, что функции конфиденциальности будут так же фундаментальны для Web3, как прозрачность была для Web1/2.

В заключение, программируемая конфиденциальность на базе FHE-VM и ZK-копроцессоров знаменует появление нового класса dApp, которые являются трастлесс-решениями, децентрализованными и конфиденциальными. От сделок в DeFi, которые не раскрывают деталей, до медицинских исследований, защищающих данные пациентов, и моделей машинного обучения, обучаемых по всему миру без раскрытия исходных данных — возможности безграничны. По мере созревания этих технологий блокчейн-платформы больше не будут вынуждать выбирать между полезностью и конфиденциальностью, что обеспечит более широкое внедрение в отраслях, требующих конфиденциальности. Будущее Web3 — это мир, где пользователи и организации могут уверенно совершать транзакции и проводить вычисления с конфиденциальными данными ончейн, зная, что блокчейн подтвердит их целостность, сохраняя их секреты в безопасности.

Источники: Информация в данном отчете взята из технической документации и недавних блогов разработчиков ведущих проектов в этой области, включая документацию FHEVM от Cypher и Zama, подробные анализы схем Axiom от Trail of Bits, руководства для разработчиков и посты в блогах RISC Zero, а также отраслевые статьи, освещающие варианты использования конфиденциальных блокчейн-технологий. Эти и другие источники цитировались на протяжении всего текста для предоставления дополнительной информации и подтверждения описанных архитектур и приложений.