23 записи с тегом "Sui"

Конфиденциальность становится общественной инфраструктурой. В 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 и начните экспериментировать с примерами из этого руководства. Децентрализованная сеть ждет приложений, которые ставят конфиденциальность и безопасность на первое место.

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

• Talus разрабатывает Nexus — фреймворк на базе Move, который объединяет ончейн- и офчейн-инструменты в проверяемые рабочие процессы в виде направленных ациклических графов (DAG), опосредованные сегодня доверенной службой "Leader" и стремящиеся к защищенным анклавам и децентрализации со временем.
• Стек нацелен на развивающуюся экономику агентов путем интеграции реестров инструментов, платежных систем, бюджетирования газа и торговых площадок, чтобы разработчики инструментов и операторы агентов могли монетизировать использование с возможностью аудита.
• Дорожная карта к выделенному Protochain (Cosmos SDK + Move VM) является публичной, но Sui остается живым координационным слоем; интеграция Sui + хранилища Walrus обеспечивает текущую производственную основу.
• Планы по токенам развиваются: материалы ссылаются на исторические концепции $TAI и Litepaper 2025 года, который представляет экосистемный токен$US для платежей, стейкинга и механик приоритезации.
• Риск исполнения сосредоточен на децентрализации Leader, окончательной доработке токеномики и демонстрации производительности Protochain при сохранении удобства для разработчиков в Sui, Walrus и офчейн-сервисах.

Что строит Talus — и что не строит​

Talus позиционирует себя как слой координации и монетизации для автономных ИИ-агентов, а не как рынок необработанного вывода ИИ. Основной продукт, Nexus, позволяет разработчикам упаковывать вызовы инструментов, внешние вызовы API и ончейн-логику в рабочие процессы DAG, выраженные в Sui Move. Дизайн подчеркивает проверяемость, доступ на основе возможностей и поток данных, управляемый схемой, так что каждый вызов инструмента может быть проверен ончейн. Talus сочетает это с торговыми площадками — Tool Marketplace, Agent Marketplace и Agent-as-a-Service — чтобы помочь операторам находить и монетизировать функциональность агентов.

Напротив, Talus не управляет собственными большими языковыми моделями или сетью GPU. Вместо этого он ожидает, что разработчики инструментов будут оборачивать существующие API или сервисы (OpenAI, векторный поиск, торговые системы, поставщики данных) и регистрировать их в Nexus. Это делает Talus дополнительным к вычислительным сетям, таким как Ritual или Bittensor, которые могут выступать в качестве инструментов в рабочих процессах Nexus.

Архитектура: Ончейн-плоскость управления, офчейн-исполнение​

Ончейн (Sui Move)​

Ончейн-компоненты находятся в Sui и обеспечивают плоскость координации:

• Движок рабочих процессов – Семантика DAG включает группы входа, варианты ветвления и проверки параллелизма. Статическая валидация пытается предотвратить состояния гонки до исполнения.
• Примитивы – ProofOfUID обеспечивает аутентифицированный обмен сообщениями между пакетами без жесткой привязки; OwnerCap/CloneableOwnerCap предоставляют разрешения на основе возможностей; структуры ProvenValue и NexusData определяют, как данные передаются встроенно или через удаленные ссылки на хранилище.
• Default TAP (Talus Agent Package) – Эталонный агент, который демонстрирует, как создавать рабочие листы (объекты доказательства), запускать оценку рабочего процесса и подтверждать результаты инструмента, соответствуя Nexus Interface v1.
• Реестр инструментов и защита от спама – Создатели инструментов должны внести заблокированное на время обеспечение для публикации определения инструмента, что препятствует спаму, сохраняя при этом регистрацию без разрешений.
• Газовая служба – Общие объекты хранят ценообразование для каждого инструмента, пользовательские бюджеты газа и газовые билеты с истечением срока действия или ограничениями использования. События записывают каждое требование, чтобы операторы могли проверять расчеты для владельцев инструментов и Leader.

Офчейн-Leader​

Управляемая Talus служба Leader прослушивает события Sui, извлекает схемы инструментов, организует офчейн-исполнение (LLM, API, вычислительные задачи), проверяет входные/выходные данные на соответствие объявленным схемам и записывает результаты обратно в ончейн. Возможности Leader представлены как объекты Sui; неудачная транзакция Sui может "повредить" возможность, предотвращая немедленное повторное использование до смены эпохи. Talus планирует усилить путь Leader через доверенные среды исполнения (TEE), нескольких операторов и, в конечном итоге, участие без разрешений.

Хранение и проверяемость​

Walrus, децентрализованный уровень хранения Mysten Labs, интегрирован для памяти агентов, артефактов моделей и больших наборов данных. Nexus сохраняет Sui для детерминированной плоскости управления, перенося более тяжелые полезные нагрузки в Walrus. Публичные материалы указывают на поддержку нескольких режимов верификации — оптимистичного, с нулевым разглашением или доверенного исполнения — выбираемых в соответствии с требованиями рабочего процесса.

Опыт разработчиков и ранние продукты​

Talus поддерживает SDK на Rust, инструменты CLI и документацию с пошаговыми инструкциями (создание DAG, интеграция LLM, защита инструментов). Каталог стандартных инструментов — завершение чата OpenAI, операции X (Twitter), адаптеры хранилища Walrus, математические утилиты — снижает трение при прототипировании. На стороне потребителя флагманские продукты, такие как IDOL.fun (рынки прогнозирования "агент против агента") и AI Bae (геймифицированные ИИ-компаньоны), служат доказательством концепции и каналами распространения для рабочих процессов, ориентированных на агентов. Talus Vision, конструктор без кода, позиционируется как предстоящий интерфейс торговой площадки, который абстрагирует проектирование рабочих процессов для неразработчиков.

Экономический дизайн, планы по токенам и обработка газа​

В текущем развертывании Sui пользователи финансируют рабочие процессы в SUI. Газовая служба конвертирует эти бюджеты в билеты, специфичные для инструментов, обеспечивает истечение срока действия или ограничения области применения и регистрирует требования, которые могут быть сверены ончейн. Владельцы инструментов определяют ценообразование, в то время как Leader получает оплату через тот же поток расчетов. Поскольку Leader в настоящее время может запрашивать бюджеты после успешного исполнения, пользователи должны доверять оператору — но генерируемые события обеспечивают возможность аудита.

Дизайн токена остается в стадии разработки. Сторонние объяснения ссылаются на более раннюю концепцию $TAI**, тогда как Litepaper Talus 2025 года предлагает экосистемный токен под названием **$US с общим объемом в 10 миллиардов. Заявленные роли включают служение средством для платежей за инструменты и Leader, стейкинг для гарантий обслуживания и предоставление привилегий приоритезации. Материалы предполагают, что избыточный SUI, уплаченный при исполнении, может быть конвертирован в $US через рыночные свопы. Инвесторы должны рассматривать эти детали как предварительные до окончательной доработки токеномики.

Финансирование, команда и партнерства​

Talus объявил о стратегическом раунде в размере $6 миллионов** (общая сумма привлеченных средств **$9 миллионов) под руководством Polychain при заявленной оценке в $150 миллионов в конце 2024 года. Вырученные средства предназначены для развития Nexus, инкубации потребительских приложений и создания Protochain, предлагаемого выделенного L1 для агентов. Публичные источники называют Майка Ханоно (CEO) и Бена Фригона (COO) ключевыми руководителями. Объявления об интеграции подчеркивают сотрудничество с экосистемами Sui и Walrus, подтверждая инфраструктуру Mysten Labs как текущую среду исполнения.

Конкурентный анализ​

• Ritual фокусируется на децентрализованных вычислениях ИИ (Infernet) и интеграциях EVM, подчеркивая проверяемый вывод, а не оркестрацию рабочих процессов.
• Autonolas (Olas) координирует офчейн-агентские сервисы с ончейн-стимулами; он разделяет тезис об экономике агентов, но не имеет слоя исполнения DAG на базе Move, как Nexus.
• Fetch.ai предлагает Agentverse и uAgents для подключения автономных сервисов; Talus отличается ончейн-верификацией каждого шага рабочего процесса и встроенным учетом газа.
• Bittensor вознаграждает вклад в модели машинного обучения через подсети TAO — рынок вычислений, который может быть интегрирован в Nexus как поставщик инструментов, но не предоставляет рельсы монетизации, на которые нацелен Talus.

В целом, Talus занимает нишу плоскости координации и расчетов для агентских рабочих процессов, оставляя необработанные вычисления и вывод специализированным сетям, которые могут подключаться в качестве инструментов.

Ключевые риски и открытые вопросы​

1. Доверие к Leader – Пока не будут реализованы TEE и поддержка нескольких операторов, разработчики должны доверять Leader Talus в добросовестном исполнении и возврате точных результатов.
2. Неопределенность токена – Брендинг и механика изменились с $TAI на$US; графики выпуска, распределение и экономика стейкинга остаются неокончательными.
3. Исполнение Protochain – Публичные материалы описывают цепочку Cosmos SDK с поддержкой Move VM, но репозитории кода, бенчмарки и аудиты безопасности пока недоступны.
4. Качество инструментов и спам – Требования к обеспечению сдерживают спам, однако долгосрочный успех зависит от валидации схем, гарантий бесперебойной работы и разрешения споров по поводу офчейн-выводов.
5. Сложность UX – Координация Sui, Walrus и различных офчейн-API создает операционные издержки; SDK и инструменты без кода должны абстрагировать это для поддержания внедрения среди разработчиков.

Важные этапы, за которыми стоит следить в 2025–2026 годах​

• Реализация дорожной карты Leader с усилением TEE, правилами слэшинга и публичным онбордингом для дополнительных операторов.
• Расширение Tool Marketplace: количество зарегистрированных инструментов, модели ценообразования и метрики качества (время безотказной работы, прозрачность SLA).
• Метрики внедрения для IDOL.fun, AI Bae и Talus Vision как индикаторы пользовательского спроса на агентские продукты.
• Данные о производительности при выполнении значительных рабочих процессов на Sui + Walrus: задержка, пропускная способность и потребление газа.
• Публикация окончательной токеномики, включая график выпуска предложения, вознаграждения за стейкинг и путь конвертации SUI→$US.
• Выпуск репозиториев Protochain, тестовых сетей и планов совместимости (например, поддержка IBC) для подтверждения тезиса о выделенной цепочке.

Как могут участвовать разработчики и операторы​

• Быстрое прототипирование – Объедините Default TAP со стандартными инструментами (OpenAI, X, Walrus) в DAG из трех узлов для автоматизации приема данных, их суммирования и ончейн-действий.
• Монетизация специализированных инструментов – Оберните проприетарные API (финансовые данные, проверки соответствия, специализированные LLM) как инструменты Nexus, определите ценообразование и выпускайте газовые билеты с истечением срока действия или ограничениями использования для управления спросом.
• Подготовка к участию в Leader – Отслеживайте документацию на предмет требований к стейкингу, логики слэшинга и механик обработки сбоев, чтобы поставщики инфраструктуры могли выступать в качестве дополнительных Leader, когда сеть откроется.
• Оценка потребительских циклов – Анализируйте удержание и расходы в IDOL.fun и AI Bae, чтобы оценить, могут ли потребительские продукты, ориентированные на агентов, стимулировать более широкий спрос на инструменты.

Итог​

Talus предлагает убедительный план для ончейн-экономики агентов, сочетая проверяемые рабочие процессы на базе Move, композицию инструментов, управляемую возможностями, и явные рельсы монетизации. Успех теперь зависит от доказательства того, что модель масштабируется за пределы доверенного Leader, окончательной доработки устойчивых токеновых стимулов и демонстрации того, что Protochain может расширить уроки эпохи Sui в выделенную среду исполнения. Разработчики, которым нужны прозрачные расчеты и компонуемые рабочие процессы агентов, должны включить Nexus в свой список для тщательной проверки, отслеживая, насколько быстро Talus сможет устранить эти открытые вопросы.

Публичные блокчейны предоставляют каждому участнику синхронизированный, проверяемый реестр, но по умолчанию они также раскрывают каждую часть данных. 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, затем итерируйте к комбинации провайдеров и операционных контролей, которые соответствуют профилю риска вашего приложения.

Представьте себе мир, где пользователи могут беспрепятственно взаимодействовать с вашим dApp, не имея нативных токенов (SUI). Это больше не далёкая мечта. С помощью Gas Station Sui (также известного как Paymaster) разработчики могут покрывать комиссии за газ от имени своих пользователей, полностью устраняя один из самых больших барьеров для новичков в Web3 и обеспечивая по-настоящему беспрепятственный ончейн-опыт.

Эта статья представляет собой полное руководство по обновлению вашего dApp до безгазового состояния. Мы подробно рассмотрим основные концепции Sui Paymaster, его архитектуру, шаблоны реализации и лучшие практики.

1. Предыстория и основные концепции: Что такое спонсируемая транзакция?​

В мире блокчейна каждая транзакция требует сетевой комиссии, или «газа». Для пользователей, привыкших к бесшовному опыту Web2, это является значительным когнитивным и операционным препятствием. Sui решает эту проблему на уровне протокола с помощью спонсируемых транзакций.

Основная идея проста: позволить одной стороне (Спонсору) оплачивать комиссии за газ SUI для транзакции другой стороны (Пользователя). Таким образом, даже если у пользователя нет SUI в кошельке, он всё равно может успешно инициировать ончейн-действия.

Paymaster ≈ Газовая станция​

В экосистеме Sui логика спонсирования транзакций обычно обрабатывается офчейн- или ончейн-сервисом, называемым Gas Station или Paymaster. Его основные обязанности включают:

1. Оценка транзакции: Он получает данные безгазовой транзакции пользователя (GasLessTransactionData).
2. Предоставление газа: Он блокирует и выделяет необходимую комиссию за газ для транзакции. Обычно это управляется через газовый пул, состоящий из множества объектов SUI Coin.
3. Генерация подписи спонсора: После одобрения спонсорства Gas Station подписывает транзакцию своим приватным ключом (SponsorSig), подтверждая свою готовность оплатить комиссию.
4. Возврат подписанной транзакции: Он отправляет обратно TransactionData, которая теперь включает данные о газе и подпись спонсора, чтобы дождаться окончательной подписи пользователя.

Короче говоря, Gas Station действует как служба заправки для пользователей вашего dApp, гарантируя, что их «транспортные средства» (транзакции) могут беспрепятственно перемещаться по сети Sui.

2. Высокоуровневая архитектура и поток взаимодействия​

Типичная безгазовая транзакция включает координацию между пользователем, фронтендом dApp, Gas Station и полной нодой Sui. Последовательность взаимодействия следующая:

Разбор потока:

1. Пользователь выполняет действие в пользовательском интерфейсе dApp, которое формирует пакет данных транзакции без какой-либо информации о газе.
2. dApp отправляет эти данные в свою назначенную Gas Station для запроса спонсорства.
3. Gas Station проверяет действительность запроса (например, проверяет, имеет ли пользователь право на спонсорство), затем заполняет транзакцию Gas Coin и своей подписью, возвращая полузавершенную транзакцию dApp.
4. Пользователь видит полные детали транзакции в своём кошельке (например, «Купить один NFT») и предоставляет окончательную подпись. Это важный шаг, который гарантирует, что пользователь сохраняет согласие и контроль над своими действиями.
5. dApp транслирует полную транзакцию, содержащую подписи как пользователя, так и спонсора, в полную ноду Sui.
6. После завершения транзакции в сети Gas Station может подтвердить это, прослушивая ончейн-события или квитанции, а затем уведомить бэкенд dApp через вебхук, чтобы завершить бизнес-процесс.

3. Три основные модели взаимодействия​

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

Модель 1: Инициировано пользователем → Одобрено спонсором (наиболее распространённая)​

Это стандартная модель, подходящая для подавляющего большинства взаимодействий внутри dApp.

1. Пользователь формирует GasLessTransactionData: Пользователь выполняет действие внутри dApp.
2. Спонсор добавляет GasData и подписывает: Бэкенд dApp отправляет транзакцию в Gas Station, которая одобряет её, прикрепляет Gas Coin и добавляет свою подпись.
3. Пользователь просматривает и даёт окончательную подпись: Пользователь подтверждает окончательные детали транзакции в своём кошельке и подписывает её. Затем dApp отправляет её в сеть.

Эта модель обеспечивает отличный баланс между безопасностью и пользовательским опытом.

Модель 2: Аирдропы/стимулы, инициированные спонсором​

Эта модель идеально подходит для аирдропов, пользовательских стимулов или пакетного распределения активов.

1. Спонсор предварительно заполняет TransactionData + подписывает: Спонсор (обычно команда проекта) предварительно формирует большую часть транзакции (например, аирдроп NFT на определённый адрес) и прикрепляет свою спонсорскую подпись.
2. Вторая подпись пользователя делает её действительной: Пользователю достаточно подписать эту «предварительно одобренную» транзакцию один раз, чтобы она была выполнена.

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

Модель 3: Wildcard GasData (модель кредитной линии)​

Это более гибкая модель, основанная на разрешениях.

1. Спонсор передаёт объект GasData: Спонсор сначала создаёт один или несколько объектов Gas Coin с определённым бюджетом и передаёт право собственности непосредственно пользователю.
2. Пользователь свободно тратит в пределах бюджета: Затем пользователь может свободно использовать эти Gas Coins для оплаты любых транзакций, которые он инициирует, в пределах лимитов бюджета и срока действия.
3. Gas Coin возвращается: После исчерпания или истечения срока действия объект Gas Coin может быть разработан таким образом, чтобы автоматически уничтожаться или возвращаться Спонсору.

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

4. Типичные сценарии применения​

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

Сценарий 1: Платные стены (Paywalls)​

Многие контентные платформы или dApp-сервисы требуют от пользователей соответствия определённым критериям (например, владение VIP NFT, достижение определённого уровня членства) для доступа к функциям. Paymaster может идеально реализовать эту логику.

• Поток: Пользователь запрашивает действие → бэкенд dApp проверяет квалификацию пользователя (например, владение NFT) → если пользователь соответствует требованиям, он вызывает Paymaster для спонсирования комиссии за газ; в противном случае он просто отклоняет запрос на подписание.
• Преимущество: Эта модель по своей природе устойчива к ботам и злоупотреблениям. Поскольку решение о спонсорстве принимается на бэкенде, злоумышленники не могут обойти проверку квалификации, чтобы истощить газовые средства.

Сценарий 2: Оформление заказа в один клик​

В сценариях электронной коммерции или внутриигровых покупок упрощение процесса оплаты имеет решающее значение.

• Поток: Пользователь нажимает «Купить сейчас» на странице оформления заказа. dApp формирует транзакцию, которая включает бизнес-логику (например, transfer_nft_to_user). Пользователю нужно только подписать, чтобы одобрить бизнес-транзакцию в своём кошельке, не беспокоясь о газе. Комиссия за газ покрывается Спонсором dApp.
• Преимущество: Вы можете закодировать бизнес-параметры, такие как order_id, непосредственно в ProgrammableTransactionBlock, что позволяет точно атрибутировать ончейн-данные для бэкенд-заказов.

Сценарий 3: Атрибуция данных​

Точное отслеживание данных является основополагающим для оптимизации бизнеса.

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

5. Скелет кода (на основе Rust SDK)​

Вот упрощённый фрагмент кода, демонстрирующий основные шаги взаимодействия.

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

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

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

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

Для полной реализации обратитесь к официальному Руководству по Gas Station в документации Sui, которое предлагает готовые примеры кода.

6. Риски и защита​

Хотя Gas Station является мощным инструментом, развёртывание его в производственной среде требует тщательного рассмотрения следующих рисков:

• Двусмысленность (двойная трата): Злоумышленник может попытаться использовать один и тот же Gas Coin для нескольких транзакций параллельно, что приведёт к блокировке Gas Coin сетью Sui. Это можно эффективно смягчить, назначая уникальный Gas Coin для каждого пользователя или транзакции, ведя чёрный список и ограничивая частоту запросов на подписание.
• Управление газовым пулом: В сценариях с высокой конкуренцией один Gas Coin большой стоимости может стать узким местом производительности. Сервис Gas Station должен быть способен автоматически разделять крупные SUI Coin на множество Gas Coin меньшей стоимости и эффективно возвращать их после использования. Профессиональные поставщики Gas Station, такие как Shinami, предлагают зрелые, управляемые решения для этого.
• Авторизация и ограничение скорости: Вы должны установить строгие политики авторизации и ограничения скорости. Например, управлять лимитами и частотой спонсорства на основе IP-адреса пользователя, адреса кошелька или токенов API, чтобы предотвратить истощение сервиса злоумышленниками.

7. Инструменты экосистемы​

Экосистема Sui уже предлагает богатый набор инструментов для упрощения разработки и развёртывания Paymaster:

• Официальные SDK (Rust/TypeScript): Включают высокоуровневые API, такие как sponsor_transaction_block(), значительно снижая сложность интеграции.
• Shinami Gas Station: Предоставляет комплексный управляемый сервис, включающий автоматическое разделение/возврат Gas Coin, детальный мониторинг метрик и уведомления через вебхуки, что позволяет разработчикам сосредоточиться на бизнес-логике.
• Enoki / Mysten Demos: Сообщество и Mysten Labs также предоставляют реализации Paymaster с открытым исходным кодом, которые можно использовать в качестве эталона для создания собственного сервиса.

8. Контрольный список реализации​

Готовы обновить свой dApp до безгазовой эры? Пройдите по этому контрольному списку, прежде чем начать:

• Спланируйте поток финансирования: Определите источник финансирования Спонсора, бюджет и стратегию пополнения. Настройте мониторинг и оповещения для ключевых метрик (например, баланс газового пула, скорость потребления).
• Зарезервируйте поля атрибуции: При разработке параметров транзакции обязательно зарезервируйте поля для бизнес-идентификаторов, таких как order_id или user_id.
• Разверните политики борьбы со злоупотреблениями: Вы должны внедрить строгие механизмы авторизации, ограничения скорости и логирования перед запуском.
• Отрепетируйте в Testnet: Независимо от того, создаёте ли вы свой собственный сервис или интегрируете сторонний Gas Station, всегда сначала проводите тщательное тестирование параллелизма и стресс-тестирование в тестовой сети (testnet) или сети разработки (devnet).
• Постоянно оптимизируйте: После запуска постоянно отслеживайте показатели успешности транзакций, причины сбоев и затраты на газ. Корректируйте свой бюджет и стратегии на основе данных.

Заключение​

Sui Paymaster (Gas Station) — это больше, чем просто инструмент для покрытия комиссий за газ для пользователей. Это мощная парадигма, которая элегантно сочетает пользовательский опыт «ноль SUI в сети» с бизнес-потребностью в «атрибуции на уровне заказа в сети» в рамках одной атомарной транзакции. Он открывает путь пользователям Web2 в Web3 и предоставляет разработчикам беспрецедентную гибкость для настройки бизнеса.

С постоянно развивающейся экосистемой инструментов и текущими низкими затратами на газ в сети Sui, сейчас самое подходящее время для обновления платёжных и интерактивных потоков вашего dApp до безгазовой эры.

Мы рады объявить о запуске стейкинга токенов SUI на BlockEden.xyz! Начиная с сегодняшнего дня, вы можете стейкать свои токены SUI непосредственно через нашу платформу и зарабатывать 2.08% годовых, поддерживая при этом безопасность и децентрализацию сети SUI.

Что нового: Беспрепятственный опыт стейкинга SUI​

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

Ключевые особенности​

Стейкинг в один клик Стейкинг SUI никогда не был таким простым. Просто подключите свой кошелек Suisplash, введите сумму SUI, которую вы хотите стейкать, и подтвердите транзакцию. Вы начнете получать вознаграждения почти сразу, без каких-либо сложных процедур.

Конкурентные вознаграждения Зарабатывайте конкурентоспособные 2.08% годовых на ваших застейканных SUI. Наша комиссия в размере 8% прозрачна, что гарантирует, что вы точно знаете, чего ожидать. Вознаграждения распределяются ежедневно по завершении каждой эпохи.

Надежный валидатор Присоединяйтесь к растущему сообществу, которое уже застейкало более 22 миллионов SUI с валидатором BlockEden.xyz. У нас есть проверенный опыт надежных услуг валидации, поддерживаемый инфраструктурой корпоративного уровня, которая обеспечивает 99.9% времени бесперебойной работы.

Гибкое управление Ваши активы остаются гибкими. Стейкинг мгновенен, что означает, что ваши вознаграждения начинают накапливаться сразу же. Если вам потребуется доступ к вашим средствам, вы можете начать процесс отмены стейкинга в любое время. Ваши SUI будут доступны после стандартного периода разблокировки сети SUI в 24-48 часов. Вы можете отслеживать свои стейки и вознаграждения в режиме реального времени через нашу панель управления.

Почему стоит стейкать SUI с BlockEden.xyz?​

Выбор валидатора — это критически важное решение. Вот почему BlockEden.xyz — это разумный выбор для ваших потребностей в стейкинге.

Надежность, которой вы можете доверять​

BlockEden.xyz является краеугольным камнем блокчейн-инфраструктуры с момента нашего основания. Наша инфраструктура валидатора обеспечивает работу корпоративных приложений и поддерживает исключительное время бесперебойной работы в нескольких сетях, обеспечивая постоянное получение вознаграждений.

Прозрачно и честно​

Мы верим в полную прозрачность. Нет скрытых комиссий — только четкая комиссия в размере 8% от полученных вами вознаграждений. Вы можете отслеживать производительность вашего стейкинга с помощью отчетов в реальном времени и проверять активность нашего валидатора в блокчейне.

• Открытый адрес валидатора: 0x3b5664bb0f8bb4a8be77f108180a9603e154711ab866de83c8344ae1f3ed4695

Бесшовная интеграция​

Наша платформа разработана для простоты. Нет необходимости создавать учетную запись; вы можете стейкать прямо из своего кошелька. Опыт оптимизирован для кошелька Suisplash, а наш чистый, интуитивно понятный интерфейс создан как для новичков, так и для экспертов.

Как начать​

Начать стейкинг SUI на BlockEden.xyz занимает менее двух минут.

Шаг 1: Посетите страницу стейкинга​

Перейдите на blockeden.xyz/dash/stake. Вы можете начать процесс немедленно без какой-либо регистрации учетной записи.

Шаг 2: Подключите свой кошелек​

Если у вас его еще нет, установите кошелек Suisplash. Нажмите кнопку "Подключить кошелек" на нашей странице стейкинга и подтвердите подключение в расширении кошелька. Ваш баланс SUI будет отображен автоматически.

Шаг 3: Выберите сумму стейка​

Введите сумму SUI, которую вы хотите стейкать (минимум 1 SUI). Вы можете использовать кнопку "МАКС", чтобы удобно застейкать весь ваш доступный баланс, оставив небольшую сумму для оплаты комиссий за газ. В сводке будет показана сумма вашего стейка и предполагаемые годовые вознаграждения.

Шаг 4: Подтвердите и начните зарабатывать​

Нажмите "Стейкать SUI" и подтвердите окончательную транзакцию в вашем кошельке. Ваш новый стейк появится на панели управления в режиме реального времени, и вы начнете накапливать вознаграждения немедленно.

Экономика стейкинга: Что вам нужно знать​

Понимание механики стейкинга является ключом к эффективному управлению вашими активами.

Структура вознаграждений​

• Базовый APY: 2.08% годовых
• Частота вознаграждений: Распределяется каждую эпоху (приблизительно 24 часа)
• Комиссия: 8% от заработанных вознаграждений
• Компаундинг: Вознаграждения добавляются в ваш кошелек и могут быть повторно застейканы для достижения сложного роста.

Примеры заработка​

Вот простой расчет потенциального заработка на основе 2.08% годовых, после 8% комиссии.

Примечание: Это оценки. Фактические вознаграждения могут варьироваться в зависимости от условий сети.

Соображения по рискам​

Стейкинг сопряжен с определенными рисками, о которых вам следует знать:

• Период разблокировки: Когда вы отменяете стейкинг, ваши SUI подлежат периоду разблокировки в 24-48 часов, в течение которого они недоступны и не приносят вознаграждений.
• Риск валидатора: Хотя мы поддерживаем высокие стандарты, любой валидатор несет операционные риски. Выбор надежного валидатора, такого как BlockEden.xyz, важен.
• Сетевой риск: Стейкинг является формой участия в сети и подвержен присущим рискам базового блокчейн-протокола.
• Рыночный риск: Рыночная стоимость токена SUI может колебаться, что повлияет на общую стоимость ваших застейканных активов.

Техническое превосходство​

Корпоративная инфраструктура​

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

Открытый исходный код и прозрачность​

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

Поддержка экосистемы SUI​

Стейкая с BlockEden.xyz, вы делаете больше, чем просто зарабатываете вознаграждения. Вы активно способствуете здоровью и росту всей сети SUI.

• Безопасность сети: Ваш стейк увеличивает общую сумму, обеспечивающую безопасность сети SUI, делая ее более устойчивой к потенциальным атакам.
• Децентрализация: Поддержка независимых валидаторов, таких как BlockEden.xyz, повышает устойчивость сети и предотвращает централизацию.
• Рост экосистемы: Комиссионные сборы, которые мы получаем, реинвестируются в поддержание и развитие критически важной инфраструктуры.
• Инновации: Доход поддерживает наши исследования и разработку новых инструментов и услуг для блокчейн-сообщества.

Безопасность и лучшие практики​

Пожалуйста, уделяйте приоритетное внимание безопасности ваших активов.

Безопасность кошелька​

• Никогда не делитесь своими приватными ключами или сид-фразой ни с кем.
• Используйте аппаратный кошелек для хранения и стейкинга больших сумм.
• Всегда проверяйте детали транзакции в вашем кошельке перед подписанием.
• Обновляйте программное обеспечение вашего кошелька до последней версии.

Безопасность стейкинга​

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

Присоединяйтесь к будущему стейкинга SUI​

Запуск стейкинга SUI на BlockEden.xyz — это больше, чем просто новая функция; это ворота к активному участию в децентрализованной экономике. Независимо от того, являетесь ли вы опытным пользователем DeFi или только начинаете свой путь, наша платформа предоставляет простой и безопасный способ получения вознаграждений, одновременно способствуя будущему сети SUI.

Готовы начать зарабатывать?

Посетите blockeden.xyz/dash/stake и застейкайте свои первые токены SUI сегодня!

О BlockEden.xyz​

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

• Основан: 2021
• Поддерживаемые сети: 15+ блокчейн-сетей
• Корпоративные клиенты: 500+ компаний по всему миру
• Общая заблокированная стоимость: $100M+ во всех сетях

Следите за нами в Twitter, присоединяйтесь к нашему Discord и изучайте полный спектр наших услуг на BlockEden.xyz.

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

Введение​

Блокчейн Sui, анонсированный к публичному запуску 3 мая 2023 года после обширного трехволнового тестнета, представил инновационную систему ценообразования на газ, разработанную для выгоды как пользователей, так и валидаторов. В её основе лежит Эталонная цена на газ (RGP) — базовая сетевая комиссия за газ, которую валидаторы согласовывают в начале каждой эпохи (примерно 24 часа).

Эта система направлена на создание взаимовыгодной экосистемы для держателей токенов SUI, валидаторов и конечных пользователей, обеспечивая низкие, предсказуемые транзакционные издержки и одновременно вознаграждая валидаторов за производительное и надёжное поведение. В этом отчёте подробно рассматривается, как определяется RGP, какие расчёты выполняют валидаторы, её влияние на экономику сети, её эволюция через управление и как она сравнивается с другими моделями газа в блокчейне.

Механизм эталонной цены на газ (RGP)​

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

• Опрос по цене на газ: В начале каждой эпохи каждый валидатор представляет свою «резервную цену» — минимальную цену на газ, которую он готов принять за обработку транзакций. Затем протокол упорядочивает эти заявки по доле стейка и устанавливает RGP для данной эпохи на уровне 2/3 перцентиля, взвешенного по доле стейка. Такая конструкция гарантирует, что валидаторы, представляющие супербольшинство (не менее двух третей) от общего стейка, готовы обрабатывать транзакции по этой цене, обеспечивая надёжный уровень обслуживания.

• Частота и требования к обновлению: Хотя RGP устанавливается каждую эпоху, валидаторы обязаны активно управлять своими котировками. Согласно официальным рекомендациям, валидаторы должны обновлять свою котировку цены на газ не реже одного раза в неделю. Кроме того, если происходит значительное изменение стоимости токена SUI, например, колебание на 20% или более, валидаторы должны немедленно обновить свою котировку, чтобы гарантировать, что RGP точно отражает текущие рыночные условия.

• Правило подсчёта и распределение вознаграждений: Чтобы гарантировать соблюдение валидаторами согласованной RGP, Sui использует «правило подсчёта». В течение эпохи валидаторы отслеживают производительность друг друга, проверяя, оперативно ли их коллеги обрабатывают транзакции по цене RGP. Этот мониторинг приводит к получению оценки производительности для каждого валидатора. В конце эпохи эти оценки используются для расчёта множителя вознаграждения, который корректирует долю каждого валидатора в вознаграждениях за стейкинг.

  • Валидаторы, показавшие хорошие результаты, получают множитель ≥1, увеличивая свои вознаграждения.
  • Валидаторы, которые задерживали, откладывали или не смогли обработать транзакции по RGP, получают множитель <1, что фактически сокращает часть их заработка.

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

Операции валидатора: Расчёт котировки цены на газ​

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

• Единицы газа, выполненные за эпоху
• Вознаграждения за стейкинг и субсидии за эпоху
• Взносы в фонд хранения
• Рыночная цена токена SUI
• Операционные расходы (оборудование, облачный хостинг, обслуживание)

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

1. Расчёт общих операционных затрат: Это определяет расходы валидатора в фиатной валюте за данную эпоху.

   $$\text{Cost}_{\text{epoch}} = (\text{Total Gas Units Executed}_{\text{epoch}}) \times (\text{Cost in \$ per Gas Unit}_{\text{epoch}})$$

2. Расчёт общих вознаграждений: Это определяет общий доход валидатора в фиатной валюте, полученный как от субсидий протокола, так и от комиссий за транзакции.

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

   Где Total Stake Rewards — это сумма любых предоставленных протоколом Stake Subsidies и Gas Fees, собранных с транзакций.

3. Расчёт чистых вознаграждений: Это окончательная мера прибыльности для валидатора.

   $$\text{\$Net Rewards}_{\text{epoch}} = \text{\$Rewards}_{\text{epoch}} - \text{\$Cost}_{\text{epoch}}$$

   Моделируя свои ожидаемые затраты и вознаграждения при различных уровнях RGP, валидаторы могут определить оптимальную котировку для представления в Опросе по цене на газ.

При запуске основной сети Sui установил начальную RGP на фиксированном уровне 1 000 MIST (1 SUI = 10⁹ MIST) на первые одну-две недели. Это обеспечило стабильный период работы для валидаторов, чтобы собрать достаточные данные об активности сети и наладить свои процессы расчёта до того, как динамический механизм опроса вступил в полную силу.

Влияние на экосистему Sui​

Механизм RGP глубоко формирует экономику и пользовательский опыт всей сети.

• Для пользователей: Предсказуемые и стабильные комиссии: RGP служит надёжным ориентиром для пользователей. Комиссия за газ для транзакции следует простой формуле: Цена газа пользователя = RGP + Чаевые. В нормальных условиях чаевые не требуются. Во время перегрузки сети пользователи могут добавить чаевые для получения приоритета, создавая рынок комиссий без изменения стабильной базовой цены в рамках эпохи. Эта модель обеспечивает значительно большую стабильность комиссий, чем системы, где базовая комиссия меняется с каждым блоком.

• Для валидаторов: Гонка за эффективностью: Система способствует здоровой конкуренции. Валидаторы стимулируются снижать свои операционные расходы (за счёт оптимизации аппаратного и программного обеспечения), чтобы иметь возможность прибыльно предлагать более низкую RGP. Эта «гонка за эффективностью» приносит пользу всей сети, снижая транзакционные издержки. Механизм также подталкивает валидаторов к сбалансированной прибыли; слишком высокая котировка рискует быть исключённой из расчёта RGP, в то время как слишком низкая приводит к операционным убыткам и штрафам за производительность.

• Для сети: Децентрализация и устойчивость: Механизм RGP помогает обеспечить долгосрочное здоровье сети. «Угроза входа» новых, более эффективных валидаторов предотвращает сговор существующих валидаторов с целью поддержания высоких цен. Кроме того, корректируя свои котировки на основе рыночной цены токена SUI, валидаторы коллективно обеспечивают устойчивость своих операций в реальном выражении, защищая экономику комиссий сети от волатильности цены токена.

Управление и эволюция системы: SIP-45​

Механизм газа Sui не статичен и развивается посредством управления. Ярким примером является SIP-45 (Приоритетная отправка транзакций), который был предложен для уточнения приоритезации на основе комиссий.

• Решаемая проблема: Анализ показал, что простая оплата высокой цены на газ не всегда гарантировала более быстрое включение транзакции.
• Предлагаемые изменения: Предложение включало увеличение максимально допустимой цены на газ и введение «усиленной трансляции» для транзакций, оплачивающих значительно выше RGP (например, ≥5x RGP), гарантируя их быстрое распространение по сети для приоритетного включения.

Это демонстрирует приверженность итеративному развитию модели газа на основе эмпирических данных для повышения её эффективности.

Сравнение с другими моделями газа в блокчейне​

Модель RGP Sui уникальна, особенно в сравнении с EIP-1559 Ethereum.

Потенциальные критические замечания и вызовы​

Несмотря на свою инновационную конструкцию, механизм RGP сталкивается с потенциальными вызовами:

• Сложность: Система опросов, правил подсчёта и офчейн-расчётов сложна и может представлять собой кривую обучения для новых валидаторов.
• Медленная реакция на пики: RGP фиксируется на эпоху и не может реагировать на внезапные всплески спроса в середине эпохи, что может привести к временной перегрузке, пока пользователи не начнут добавлять чаевые.
• Потенциал сговора: Теоретически, валидаторы могли бы сговориться, чтобы установить высокую RGP. Этот риск в основном снижается конкурентным характером децентрализованного набора валидаторов.
• Отсутствие сжигания комиссий: В отличие от Ethereum, Sui перераспределяет все комиссии за газ валидаторам и в фонд хранения. Это вознаграждает операторов сети, но не создаёт дефляционного давления на токен SUI — функцию, которую ценят некоторые держатели токенов.

Часто задаваемые вопросы (FAQ)​

Зачем стейкать SUI? Стейкинг SUI обеспечивает безопасность сети и приносит вознаграждения. Изначально эти вознаграждения сильно субсидируются Sui Foundation для компенсации низкой сетевой активности. Эти субсидии уменьшаются на 10% каждые 90 дней, с ожиданием, что вознаграждения от транзакционных комиссий станут основным источником дохода. Застейканные SUI также предоставляют право голоса в ончейн-управлении.

Могут ли мои застейканные SUI быть слэшированы? Да. Хотя параметры всё ещё дорабатываются, применяется «слэшинг по правилу подсчёта». Валидатор, получивший нулевую оценку производительности от 2/3 своих коллег (из-за низкой производительности, злонамеренного поведения и т. д.), будет иметь свои вознаграждения слэшированы на определённую сумму. Стейкеры также могут упустить вознаграждения, если выбранный ими валидатор имеет простой или предлагает неоптимальную RGP.

Автоматически ли реинвестируются вознаграждения за стейкинг? Да, вознаграждения за стейкинг в Sui автоматически распределяются и реинвестируются (компаундируются) каждую эпоху. Чтобы получить доступ к вознаграждениям, вы должны явно их разстейкать.

Каков период разблокировки (unbonding period) Sui? Изначально стейкеры могут разблокировать свои токены немедленно. Ожидается, что будет реализован период разблокировки, когда токены будут заблокированы на определённое время после разстейкинга, и это будет предметом управления.

Сохраняю ли я контроль над своими токенами SUI при стейкинге? Да. Когда вы стейкаете SUI, вы делегируете свой стейк, но остаётесь в полном контроле над своими токенами. Вы никогда не передаёте хранение валидатору.

Как уменьшить трение при использовании кошелька, сохранить поток пользователей и спрогнозировать рост

Что, если бы ваше Web3-приложение имело такой же бесшовный процесс регистрации, как и современный Web2-сервис? Это основное обещание zkLogin на блокчейне Sui. Он функционирует как OAuth для Sui, позволяя пользователям входить в систему с помощью привычных аккаунтов Google, Apple, X и других. Затем доказательство с нулевым разглашением безопасно связывает эту Web2-идентичность с ончейн-адресом Sui — без всплывающих окон кошелька, без сид-фраз, без оттока пользователей.

Влияние реально и немедленно. С сотнями тысяч уже активных аккаунтов zkLogin, тематические исследования сообщают о значительном росте конверсии пользователей, подскочившей с удручающих 17% до здоровых 42% после устранения традиционных барьеров, связанных с кошельками. Давайте разберем, как это работает и что это может дать вашему проекту.

Почему кошельки убивают конверсию при первом взаимодействии​

Вы создали новаторское dApp, но ваша воронка привлечения пользователей протекает. Виновник почти всегда один и тот же: кнопка «Подключить кошелек». Стандартный Web3-онбординг — это лабиринт из установки расширений, предупреждений о сид-фразах и викторин по крипто-жаргону.

Это огромный барьер для новичков. UX-исследователи наблюдали ошеломляющий 87%-ный отток в тот момент, когда появлялся запрос кошелька. В показательном эксперименте простое перенаправление этого запроса на более поздний этап процесса оформления заказа увеличило коэффициент завершения до 94%. Даже для пользователей, интересующихся криптовалютой, основной страх заключается в следующем: «Я могу потерять свои средства, если нажму не ту кнопку». Устранение этого единственного, пугающего шага является ключом к разблокированию экспоненциального роста.

Как работает zkLogin (простым языком)​

zkLogin элегантно обходит проблему кошельков, используя технологии, которым уже доверяет каждый интернет-пользователь. Магия происходит за кулисами в несколько быстрых шагов:

1. Эфемерная пара ключей: Когда пользователь хочет войти в систему, временная, односессионная пара ключей генерируется локально в его браузере. Думайте об этом как о временном пропуске, действительном только для этой сессии.
2. OAuth-танец: Пользователь входит в систему со своим аккаунтом Google, Apple или другим социальным аккаунтом. Ваше приложение умело встраивает уникальное значение (nonce) в этот запрос на вход.
3. ZKP-сервис: После успешного входа в систему ZKP-сервис (Zero-Knowledge Proof) генерирует криптографическое доказательство. Это доказательство подтверждает: "Этот OAuth-токен авторизует владельца временного пропуска," не раскрывая при этом личную идентичность пользователя в блокчейне.
4. Вывод адреса: JWT (JSON Web Token) пользователя от OAuth-провайдера объединяется с уникальным salt для детерминированного генерирования его постоянного адреса Sui. Salt хранится в секрете, либо на стороне клиента, либо в безопасном бэкенде.
5. Отправка транзакции: Ваше приложение подписывает транзакции временным ключом и прикрепляет ZK-доказательство. Валидаторы Sui проверяют доказательство в блокчейне, подтверждая легитимность транзакции без необходимости использования пользователем традиционного кошелька.

Пошаговое руководство по интеграции​

Готовы к реализации? Вот краткое руководство с использованием SDK на TypeScript. Принципы идентичны для Rust или Python.

1. Установите SDK​

Пакет @mysten/sui включает все необходимые вспомогательные функции zklogin.

pnpm add @mysten/sui

2. Сгенерируйте ключи и Nonce​

Сначала создайте эфемерную пару ключей и nonce, привязанный к текущей эпохе в сети Sui.

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

3. Перенаправление на OAuth​

Сформируйте соответствующий URL для входа через OAuth для используемого провайдера (например, Google, Facebook, Apple) и перенаправьте пользователя.

4. Декодируйте JWT и получите Salt пользователя​

После того как пользователь войдет в систему и будет перенаправлен обратно, получите id_token из URL. Используйте его для получения специфичного для пользователя salt из вашего бэкенда, затем выведите его адрес Sui.

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

5. Запросите ZK-доказательство​

Отправьте JWT в службу доказывания, чтобы получить ZK-доказательство. Для разработки вы можете использовать публичный провайдер Mysten. В продакшене вам следует разместить свой собственный или использовать такой сервис, как Enoki.

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

6. Подпишите и отправьте​

Теперь создайте свою транзакцию, установите отправителя на zkLogin-адрес пользователя и выполните ее. SDK автоматически прикрепляет zkLoginInputs (доказательство). ✨

const tx = new TransactionBlock();
tx.moveCall({ target: "0x2::example::touch_grass" }); // Любой вызов Move
tx.setSender(address);
tx.setGasBudget(5_000_000);

await suiClient.signAndExecuteTransactionBlock({
  transactionBlock: tx,
  zkLoginInputs: proof, // Магия происходит здесь
});

7. Сохраните сессию​

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

Шаблон прогнозирования KPI​

Разница, которую вносит zkLogin, не только качественная, но и количественная. Сравните типичную воронку онбординга с воронкой, работающей на zkLogin:

👉 Что это значит: Для кампании, привлекающей 10 000 уникальных посетителей, это разница между 300 ончейн-действиями в первый день и более 2 500.

Лучшие практики и подводные камни​

Чтобы создать еще более бесшовный опыт, имейте в виду эти профессиональные советы:

• Используйте спонсируемые транзакции: Оплачивайте первые несколько комиссий за транзакции ваших пользователей. Это устраняет все трения и дарит невероятный «момент озарения».
• Осторожно обращайтесь с Salt: Изменение salt пользователя сгенерирует новый адрес. Делайте это только в том случае, если вы контролируете надежный путь восстановления для них.
• Показывайте адрес Sui: После регистрации покажите пользователям их ончейн-адрес. Это дает продвинутым пользователям возможность импортировать его в традиционный кошелек позже, если они захотят.
• Предотвращайте циклы обновления: Кэшируйте JWT и эфемерную пару ключей до истечения их срока действия, чтобы не просить пользователя входить в систему повторно.
• Мониторьте задержку провайдера доказательств: Следите за временем кругового обхода генерации доказательств. Если оно превышает 2 секунды, рассмотрите возможность размещения регионального провайдера, чтобы все работало быстро.

Где BlockEden.xyz добавляет ценность​

В то время как zkLogin совершенствует пользовательский интерфейс, его масштабирование создает новые проблемы для бэкенда. Именно здесь BlockEden.xyz приходит на помощь.

• Уровень API: Наши высокопроизводительные, гео-маршрутизируемые RPC-ноды обеспечивают обработку ваших zkLogin-транзакций с минимальной задержкой, независимо от местоположения пользователя.
• Наблюдаемость: Получите готовые дашборды для отслеживания ключевых метрик, таких как задержка доказательств, соотношение успехов/неудач и состояние вашей воронки конверсии.
• Соответствие требованиям: Для приложений, которые интегрируются с фиатом, наш опциональный модуль KYC обеспечивает соответствующий требованиям онбординг непосредственно с проверенной личности пользователя.

Готовы к запуску?​

Эпоха неуклюжих, пугающих потоков кошельков закончилась. Запустите песочницу zkLogin, подключите конечную точку полной ноды BlockEden и наблюдайте, как ваш график регистраций пойдет вверх — при этом вашим пользователям даже не придется слышать слово «кошелек». 😉

1. Ликвидность и рост Sui DeFi​

Рисунок: TVL Sui DeFi (синяя линия) и объем DEX (зеленые столбцы) значительно выросли во втором квартале 2025 года.

Резкий рост общей заблокированной стоимости (TVL): Ликвидность DeFi в сети Sui взрывообразно выросла за последний год. С примерно $600 млн TVL в конце 2024 года** TVL Sui взлетел до **более чем$2 млрд к середине 2025 года. Фактически, Sui достиг пика примерно в $2,55 млрд TVL 21 мая 2025 года** и удерживался значительно выше$2 млрд большую часть второго квартала. Этот ~300%+ рост** (480% годового роста с мая 2023 года) прочно позиционирует Sui среди 10 крупнейших блокчейнов по TVL DeFi, опережая рост таких сетей, как Solana. Основными катализаторами стали институциональное принятие и интеграция нативной поддержки стейблкоина USDC, что в совокупности привлекло крупные притоки капитала. Примечательно, что ежемесячные объемы торгов на DEX Sui поднялись в верхний эшелон всех сетей – превысив $7–8 млрд в месяц к середине 2025 года** (занимая \~8-е место в отрасли). Циркулирующая **ликвидность стейблкоинов на Sui превысила$1 млрд к середине 2025 года, увеличившись на 180% с начала года, что указывает на углубление ончейн-ликвидности. Кросс-чейн капитал также поступает; около $2,7 млрд активов было переведено в экосистему Sui, включая ликвидность Bitcoin (подробности ниже). Эта быстрая тенденция роста подчеркивает год чистого притока и расширения пользовательской базы для Sui DeFi.

Крупные DEX и поставщики ликвидности: Децентрализованные биржи составляют основу ликвидности Sui DeFi. Протокол Cetus – автоматический маркет-мейкер (AMM) и агрегатор – был флагманским DEX, предлагая свопы стейблкоинов и пулы концентрированной ликвидности. Cetus постоянно лидирует по объему (обеспечив **более $12,8 млрд сделок только во втором квартале 2025 года**), при этом удерживая около$80 млн TVL. Другим ключевым игроком является Bluefin, многофункциональный DEX, который управляет как спотовым AMM, так и биржей бессрочных фьючерсов. Bluefin расширил свои предложения в 2025 году инновационными функциями: он представил BluefinX, первую систему RFQ (запрос котировок) на Sui для улучшения исполнения цен, и даже интегрировал оптимизации для высокочастотной торговли, чтобы сократить разрыв между производительностью DEX и CEX. Ко второму кварталу AMM Bluefin удерживал около $91 млн TVL и имел более$7,1 млрд квартального спотового объема. Momentum – еще один растущий DEX – запустил маркет-мейкер концентрированной ликвидности (CLMM), который быстро накопил **107 млн ликвидности** и сгенерировал \~4,6 млрд объема торгов вскоре после запуска. Сектор DEX Sui также включает MovEX (гибридный AMM + биржу с книгой ордеров) и Turbos (ранний последователь CLMM), среди прочих, каждый из которых вносит свой вклад в разнообразный ландшафт ликвидности. Примечательно, что Sui поддерживает нативную ончейн-книгу лимитных ордеров под названием DeepBook, разработанную совместно с MovEX, которая предоставляет общую ликвидность книги ордеров любому dApp Sui. Эта комбинация AMM, агрегаторов и ончейн-CLOB дает Sui одну из самых надежных экосистем DEX в DeFi.

Рынки кредитования и протоколы доходности: Платформы кредитования и заимствования Sui привлекли значительный капитал, составляя большую долю TVL. Протокол Suilend выделяется как крупнейшая DeFi-платформа Sui, с примерно **$700 млн+ TVL ко второму кварталу 2025 года** (перешагнув отметку в$1 млрд в начале 2025 года). Suilend является расширением Solend от Solana, перенесенным на среду выполнения Move от Sui, и быстро стал флагманским денежным рынком на Sui. Он предлагает услуги по депозитам и заимствованиям под залог для таких активов, как SUI и USDC, и внедрил инновации, запустив сопутствующие продукты – например, SpringSui (модуль ликвидного стейкинга) и STEAMM, AMM, который обеспечивает «сверхтекучее» использование ликвидности внутри платформы. За счет геймификации вовлеченности пользователей (через кампании с баллами и NFT) и выпуска токена управления $SEND** с распределением доходов, Suilend обеспечил быстрое принятие – сообщив о **более чем 50 000 ежемесячно активных кошельков** к середине 2025 года. Сразу за Suilend следует **Navi Protocol** (также называемый Astros), который аналогичным образом достиг порядка **$600–700 млн TVL в своих пулах кредитования. Navi отличается тем, что сочетает рынки кредитования со стратегиями доходности и даже интеграцией Bitcoin DeFi: например, Navi провел кампанию для пользователей по стейкингу xBTC (прокси BTC на Sui) через OKX Wallet, стимулируя держателей Bitcoin участвовать в возможностях доходности Sui. Другие известные платформы кредитования включают Scallop (~146 млн TVL) и **AlphaLend** (\~137 млн), которые вместе указывают на конкурентный рынок заимствований и кредитования на Sui. Агрегация доходности также начала набирать обороты – протоколы, такие как AlphaFi и **Kai Finance**, каждый управляют десятками миллионов активов (например, ~$40 млн TVL) для оптимизации доходности на фермах Sui. Хотя и меньшие по масштабу, эти оптимизаторы доходности и структурированные продукты (например, структурированные хранилища доходности MovEX) добавляют глубину предложениям Sui DeFi, помогая пользователям максимизировать прибыль от растущей базы ликвидности.

Ликвидный стейкинг и деривативы: Параллельно, деривативы ликвидного стейкинга (LSD) Sui и платформы для торговли деривативами представляют собой важную часть ликвидности экосистемы. Поскольку Sui является блокчейном с доказательством доли владения (proof-of-stake), протоколы, такие как SpringSui, Haedal и Volo, представили токены, которые оборачивают застейканные SUI, позволяя стейкерам оставаться ликвидными. SpringSui – запущенный командой Suilend – быстро стал доминирующим LSD, удерживая около **$189 млн застейканных SUI** к концу второго квартала. Вместе с Haedal ($150 млн) и другими, платформы LSD Sui дают пользователям возможность получать вознаграждения валидаторов, одновременно перераспределяя токены стейкинга в DeFi (например, используя застейканные SUI в качестве залога для кредитования или в доходных фермах). На фронте деривативов Sui теперь размещает несколько ончейн-бирж бессрочных фьючерсов. Мы упоминали DEX бессрочных фьючерсов Bluefin (Bluefin Perps), который обрабатывал миллиарды квартального объема. Кроме того, Typus Finance запустил Typus Perp (TLP) во втором квартале 2025 года, выйдя на рынок бессрочных фьючерсов Sui с впечатляющим дебютом. Sudo (с его интеграцией протокола ZO) представил геймифицированные бессрочные свопы и «интеллектуальные» продукты с кредитным плечом, увеличив свою пользовательскую базу и ликвидность более чем на 100% за последний квартал. Протокол Magma даже разработал новую модель AMM – Adaptive Liquidity Market Maker (ALMM) – стремясь к сделкам с нулевым проскальзыванием и большей капитальной эффективности в свопах. Эти инновационные дизайны DEX и деривативов привлекают собственную ликвидность (например, TVL Magma удвоился во втором квартале) и повышают репутацию Sui как испытательного полигона для примитивов DeFi нового поколения.

Тенденции притока капитала и пользователей: Общая тенденция ликвидности на Sui была сильно положительной, подпитываемой как розничными, так и институциональными притоками. Растущий авторитет Sui (например, HSBC и DBS Bank присоединились в качестве валидаторов сети) и высокая производительность привлекли новый капитал. Значительная часть активов, переведенных в Sui, – это «голубые фишки» и стейблкоины – например, USDC от Circle был запущен нативно на Sui, а USDT от Tether стал доступен через мосты, что привело к надежному сочетанию стейблкоинов (USDC ~775 млн, USDT \~100 млн в обращении ко второму кварталу). Возможно, наиболее примечательно, что ликвидность Bitcoin поступила в Sui в значительном объеме (через обернутые или застейканные BTC – подробно в Разделе 3), составляя более 10% TVL. Со стороны пользователей, улучшенная поддержка кошельков и абстракция (см. Раздел 2) стимулировали принятие. Популярный кошелек Phantom (с ~7 млн пользователей) расширил поддержку Sui, облегчая широкому криптосообществу доступ к dApps Sui. Аналогично, кошельки централизованных бирж, такие как OKX и Binance, интегрировали функции Sui DeFi (например, кошелек Chrome от Binance добавил интеграцию Simple Yield с протоколом Scallop от Sui). Эти онрампы способствовали росту числа пользователей Sui: к началу 2025 года Sui имел сотни тысяч активных адресов, а ведущие dApps, такие как Suilend, сообщают о десятках тысяч ежемесячных пользователей. В целом, ликвидность на Sui демонстрировала восходящую тенденцию в 2025 году, поддерживаемая постоянными притоками и расширяющимся участием пользователей – резкий контраст со стагнацией, наблюдаемой в некоторых других сетях в тот же период.

2. Абстракция: упрощение пользовательского опыта на Sui​

Функции абстракции учетных записей: Краеугольным камнем дизайна Sui является абстракция учетных записей, которая значительно улучшает удобство использования, скрывая сложности блокчейна от конечных пользователей. В отличие от традиционных Layer-1, где пользователи должны управлять ключами и газом для каждой транзакции, Sui обеспечивает более плавный опыт благодаря нативным функциям. В частности, Sui поддерживает вход по сторонним учетным данным и спонсирование газа на уровне протокола. Разработчики могут интегрировать zkLogin – позволяя пользователям создавать кошелек Sui и входить с помощью привычных учетных данных Web2 (Google, Facebook, Twitch и т. д.) вместо сид-фраз. Одновременно Sui предлагает спонсируемые транзакции, что означает, что разработчики dApp могут оплачивать комиссии за газ от имени пользователей через ончейн-механизм «газовой станции». Вместе zkLogin и спонсирование газа устраняют две основные проблемы (управление сид-фразами и приобретение нативных токенов) для новых пользователей. Пользователь Sui может, например, зарегистрироваться с помощью электронной почты/пароля (через OAuth) и немедленно начать использовать DeFi-приложение без необходимости вносить токены SUI заранее. Этот уровень абстракции отражает простоту использования Web2 и сыграл решающую роль в привлечении «следующей волны» пользователей, которые ожидают беспрепятственной регистрации и бесплатных пробных версий. Многие приложения Sui и даже Web3-игры теперь используют эти функции – недавний запуск NFT-игры похвастался потоком «входа без кошелька» для игроков, основанным на абстракции учетных записей Sui и возможностях социального входа. В целом, автоматизируя управление ключами и обработку газа, Sui значительно снижает барьер для входа в DeFi, что, в свою очередь, способствует более высокому удержанию пользователей и активности.

Абстракция смарт-контрактов и Move: Помимо входа в систему и транзакций, объектно-ориентированная модель программирования Sui обеспечивает абстракцию на уровне смарт-контрактов. Нативный язык Move от Sui рассматривает объекты (а не внешне принадлежащие учетные записи) как базовую единицу хранения, с богатыми метаданными и гибкими структурами владения. Это означает, что разработчики могут создавать объекты смарт-контрактов, которые действуют как прокси для учетных записей пользователей, автоматизируя задачи, которые традиционно требовали бы подписей пользователей. Например, приложение на Sui может развернуть программируемый объект для обработки повторяющихся платежей или сложных многоэтапных сделок от имени пользователя, без того, чтобы этот пользователь вручную инициировал каждый шаг. Эти объекты могут содержать разрешения и логику, эффективно абстрагируя повторяющиеся действия от конечного пользователя. Кроме того, Sui представил программируемые блоки транзакций (PTB) как способ объединения нескольких операций в единую полезную нагрузку транзакции. Вместо того, чтобы требовать от пользователя подписывать и отправлять 3–4 отдельные транзакции (например, одобрить токен, затем обменять, затем застейкать), Sui PTB может скомпоновать эти шаги и выполнить их все сразу. Это не только уменьшает трение и запросы подтверждения для пользователя, но и улучшает производительность (меньше ончейн-транзакций означает меньший общий газ и более быстрое выполнение). С точки зрения пользователя, сложная серия действий может ощущаться как одно плавное взаимодействие – критическое улучшение UX. Move от Sui был создан с учетом такой компонуемости и абстракции, и это позволяет разработчикам создавать dApps, которые гораздо больше похожи на традиционные финтех-приложения. В качестве дополнительного бонуса, криптографическая гибкость Sui поддерживает несколько схем подписи (Ed25519, secp256k1 и т. д.), что позволяет кошелькам использовать различные типы ключей (включая те, которые используются в Ethereum или Bitcoin). Эта гибкость облегчает интеграцию функциональности Sui в мультивалютные кошельки и даже закладывает основу для квантово-устойчивой криптографии в будущем.

Кросс-чейн абстракция – интенты и интеграция: Sui также совершает прорыв в кросс-чейн пользовательском опыте через абстракцию. Ярким примером является интеграция NEAR Intents, новой кросс-чейн системы координации, в экосистему Sui в июле 2025 года. Благодаря этой интеграции пользователи Sui могут беспрепятственно обменивать активы между более чем 20 другими сетями (включая Ethereum, Bitcoin, Solana, Avalanche и т. д.) за один шаг, без ручного бриджинга. Базовая модель «интентов» означает, что пользователь просто выражает что он хочет (например, «обменять 1 ETH на Ethereum на SUI на Sui»), и сеть автоматизированных решателей находит наиболее эффективный способ выполнить этот запрос между сетями. Пользователю больше не нужно жонглировать несколькими кошельками или комиссиями за газ в разных сетях – система абстрагирует все это. Обмен активами на Sui становится таким же простым, как транзакция в один клик, без необходимости даже держать токены газа в исходной сети. Это значительный скачок в UX для кросс-чейн DeFi. К середине 2025 года NEAR Intents был запущен, и пользователи Sui могли привлекать внешнюю ликвидность за считанные секунды, что позволяло использовать такие сценарии, как кросс-чейн арбитраж и онбординг активов от держателей, не являющихся Sui, практически без трения или риска хранения. Представители Sui Foundation подчеркнули, что «обмен нативных активов в один клик… абстрагирует сложность, сохраняя при этом все ончейн, безопасным и компонуемым». Параллельно Sui получил выгоду от крупных интеграций кошельков, которые скрывают сложность для пользователей. Как отмечалось, мультивалютный кошелек Phantom теперь поддерживает Sui, а другие популярные кошельки, такие как OKX и Binance Wallet, имеют встроенную поддержку dApps Sui. Например, кошелек Binance позволяет пользователям напрямую получать доступ к доходным фермам на Sui (через Scallop) через простой интерфейс, а кошелек OKX нативно интегрировал потоки стейкинга BTC на Sui (xBTC от Navi). Эти интеграции означают, что пользователи могут взаимодействовать с Sui DeFi без переключения приложений или беспокойства о технических деталях – их привычный кошелек абстрагирует это для них. Все эти усилия, от свопов на основе интентов до пользовательских интерфейсов кошельков, служат цели сделать кросс-чейн и ончейн DeFi легким на Sui. В результате Sui становится все более доступным не только для крипто-энтузиастов, но и для массовых пользователей, которые требуют простоты.

Влияние на пользовательский опыт: Благодаря уровням абстракции Sui, пользовательский опыт в протоколах Sui DeFi стал одним из самых удобных в блокчейне. Новые пользователи могут начать работу с социальным входом и без первоначальных затрат, выполнять сложные транзакции с минимальными подтверждениями и даже перемещать активы из других сетей с помощью свопов в один клик. Этот подход реализует миссию Sui по «знакомому онбордингу» и массовому принятию. Для сравнения, так же как пользователю iPhone не нужно понимать код Swift, чтобы использовать приложение, пользователю Sui DeFi не нужно разбираться в приватных ключах или механике мостов. Этика абстракции учетных записей Sui охватывает эту философию, «предлагая путь к бесшовному и приятному пользовательскому опыту» для блокчейн-финансов. Делая взаимодействие с Web3 более похожим на Web2 по простоте, Sui снижает барьеры для следующей волны пользователей DeFi, которые ценят удобство. Этот ориентированный на пользователя дизайн является ключевым фактором растущего принятия Sui и закладывает основу для более широкого участия в DeFi в 2025 году и далее.

3. Следующая волна примитивов DeFi на Sui​

Распространение нативных стейблкоинов: На Sui появляется множество новых стейблкоинов и токенов, обеспеченных активами, предоставляющих фундаментальные строительные блоки для DeFi. В конце 2024 года AUSD от Agora Finance был запущен как первый полностью обеспеченный долларом США стейблкоин, нативный для Sui. Позиционируемый как стейблкоин институционального уровня, запуск AUSD сразу же добавил ликвидности и стал благом для роста Sui DeFi (TVL Sui составлял около 600 млн, когда появился AUSD, и продолжал расти). К середине 2025 года AUSD имел оборотное предложение в десятки миллионов (с большим количеством на Ethereum и Avalanche) и стал **регулируемой альтернативой USDC/USDT в экосистеме Sui**. Примерно в то же время **Bucket Protocol** представил **BUCK**, стейблкоин с избыточным обеспечением, похожий на DAI, но для Sui. Пользователи могут минтить BUCK, депонируя SUI, BTC, ETH и другие активы в качестве залога. BUCK **привязан к USD** и поддерживается через ончейн-коэффициенты обеспечения и механизмы стабильности (Bucket включает модуль стабильности привязки, CDP-хранилища и т. д., аналогично MakerDAO). Ко второму кварталу 2025 года **предложение BUCK достигло \~60–66 млн**, что сделало его одним из крупнейших нативных стейблкоинов Sui (TVL протокола Bucket составлял ~$69 млн в этот период, в основном обеспечивая BUCK). Еще одним заметным дополнением является USDY от Ondo Finance – доходный «стейблкоин», который токенизирует доходность краткосрочных казначейских облигаций США. Ondo развернул USDY на Sui в начале 2024 года, ознаменовав выход Sui на рынок токенов, обеспеченных реальными активами (RWA). USDY фактически является токенизированным облигационным фондом, который приносит проценты держателям (его цена немного колеблется, отражая полученную доходность). Это предоставляет пользователям Sui нативный, ориентированный на соблюдение требований стабильный актив, который генерирует доходность без необходимости стейкинга или фарминга. К 2025 году ландшафт стейблкоинов Sui также включал First Digital USD (FDUSD), привнесенный через партнерства в Азии, и обернутые версии основных стейблкоинов. Разнообразие примитивов стейблкоинов – от децентрализованных с CDP-обеспечением (BUCK) до полностью обеспеченных фиатом (AUSD) и доходных (USDY) – расширяет ончейн-ликвидность и позволяет использовать новые стратегии DeFi (например, использование BUCK в качестве залога по кредиту или хранение USDY в качестве низкорискового источника доходности). Эти стабильные активы составляют основу для других протоколов, таких как DEX и кредиторы, и их присутствие является сильным сигналом зрелости экосистемы DeFi.

Инновации BTC DeFi («BTCfi»): Sui находится на переднем крае превращения Bitcoin в активного игрока в DeFi, введя термин BTCfi для сценариев использования DeFi, ориентированных на Bitcoin. В 2025 году несколько инициатив перевели ликвидность и безопасность Bitcoin в сеть Sui. Одним из важных шагов стала интеграция tBTC от Threshold Network на Sui. tBTC – это децентрализованный токен, обеспеченный BTC в соотношении 1:1, который использует пороговую криптографию (распределенную подпись), чтобы избежать единого хранителя. В июле 2025 года tBTC был запущен на Sui, немедленно открыв доступ к более чем $500 млн ликвидности BTC** для протоколов Sui. Это означает, что держатели Bitcoin теперь могут минтить tBTC непосредственно в Sui и использовать его для кредитования, торговли или доходного фермерства **без передачи своих BTC централизованному мосту**. Высокопроизводительная инфраструктура Sui (с завершенностью транзакций менее чем за секунду) делает ее привлекательным домом для этих активов BTC. Параллельно Sui сотрудничал с экосистемой **Stacks** для поддержки **sBTC**, еще одного представления BTC 1:1, которое использует безопасность Bitcoin через слой-2 Stacks. К маю 2025 года более **10$65 млн) поступило в Sui только за первые несколько месяцев 2025 года. Эти производные BTC открывают такие сценарии использования, как использование BTC в качестве залога на кредитных платформах Sui (действительно, Suilend удерживал более $102 млн в активах на основе Bitcoin ко второму кварталу, больше, чем любой другой кредитор Sui). Они также позволяют торговые пары BTC на DEX Sui и позволяют держателям Bitcoin получать доходность DeFi, не отказываясь от владения своими BTC. Концепция BTCfi заключается в превращении Bitcoin из «пассивного» средства сбережения в активный капитальный актив – и Sui принял это, предоставив технологию (быстрое, параллельное выполнение и объектную модель, идеальную для представления хранения BTC) и наладив партнерские отношения для привлечения ликвидности Bitcoin. Sui Foundation даже начал управлять валидатором Stacks, сигнализируя о своей приверженности интеграции BTC. Короче говоря, Bitcoin теперь является первоклассным гражданином в Sui DeFi, и это перекрестное опыление является ключевой инновацией 2025 года. Оно открывает двери для новых стейблкоинов, обеспеченных Bitcoin, продуктов доходности Bitcoin и мультивалютных стратегий, которые устраняют разрыв между сетью Bitcoin и DeFi на Sui.

Продвинутые примитивы DEX и HFT: Следующая волна примитивов Sui DeFi также включает новые дизайны бирж и финансовые инструменты, которые выходят за рамки первоначальных моделей AMM. Ранее мы видели, как ALMM от Magma и CLMM от Momentum продвигают AMM к большей капитальной эффективности (концентрируя ликвидность или динамически ее регулируя). Кроме того, протоколы экспериментируют с высокопроизводительными торговыми функциями: Bluefin в частности представил функционал, ориентированный на институциональных и высокочастотных трейдеров. В июле 2025 года Bluefin объявил, что внедряет институциональные высокочастотные торговые стратегии на свой DEX на базе Sui, используя параллельное выполнение Sui для достижения улучшений пропускной способности и задержки. Это сокращает разрыв в производительности с централизованными биржами и может привлечь количественные торговые фирмы для предоставления ликвидности ончейн. Такие улучшения в скорости исполнения, низком проскальзывании и защите от MEV (обновление Bluefin Spot 2.0 отмечено за устойчивое к MEV RFQ-сопоставление) являются новыми примитивами в дизайне бирж, которые Sui внедряет.

Тем временем деривативы и структурированные продукты на Sui становятся все более сложными. Упоминались расширение Typus на бессрочные фьючерсы и предложение геймифицированных бессрочных фьючерсов Sudo/ZO; это указывает на тенденцию смешивания DeFi с геймификацией торговли и удобными интерфейсами. Еще один пример – Nemo, который представил рынок «торговли доходностью» и систему вознаграждений за баллы в своем новом интерфейсе – по сути, позволяя пользователям спекулировать на ставках доходности и зарабатывать баллы лояльности, что является креативным поворотом в типичном доходном фермерстве. Мы также видим структурированные продукты доходности: например, MovEX и другие обсуждали структурированные хранилища, которые автоматически переключают средства между стратегиями, предоставляя пользователям упакованные инвестиционные продукты (подобно DeFi ETF или траншам). Они находятся в разработке и представляют собой следующее поколение доходного фермерства, где сложность (например, переключение стратегий) абстрагируется и предлагается как единый продукт.

Новые финансовые инструменты и партнерства: Сообщество Sui и его партнеры активно создают совершенно новые примитивы DeFi, которые могут определить следующую фазу роста. Одним из высокопрофильных предстоящих проектов является Graviton, который привлек $50 млн в рамках серии A (под руководством a16z и Pantera) для создания модульной платформы для торговли, кредитования и кросс-маржирования на Sui. Graviton часто сравнивают с dYdX – он нацелен на привлечение профессиональных трейдеров с полным набором децентрализованных торговых возможностей (бессрочные фьючерсы, маржинальная торговля, рынки кредитования под одной крышей). Такая хорошо финансируемая инициатива подчеркивает уверенность в потенциале Sui DeFi и обещает новый примитив: универсальное, высокопроизводительное DeFi «суперприложение» на Sui. Кроме того, финансы реального мира пересекаются с Sui: Sui Foundation наладил партнерские отношения, такие как xMoney/xPortal, для запуска крипто-карты MasterCard для розничных пользователей, которая позволит тратить активы на базе Sui в повседневных покупках. Этот вид моста CeFi–DeFi (по сути, перенос ликвидности DeFi в точки продаж) может быть преобразующим, если он наберет обороты. С институциональной стороны, 21Shares подала заявку на биржевой фонд SUI (ETF) в США – хотя это не протокол DeFi, ETF предоставит традиционным инвесторам доступ к росту Sui и косвенно к его DeFi-экономике.

Активность сообщества и разработчиков на Sui является еще одной движущей силой для новых примитивов. Экосистема Move с открытым исходным кодом Sui стала настолько активной, что к середине 2025 года Sui превзошел Solana и Near по еженедельным коммитам разработчиков и форкам репозиториев, благодаря всплеску новых инструментов (например, Move SDK, интеграции zk-proof, разработка кросс-чейн протоколов). Это живое сообщество разработчиков постоянно экспериментирует с такими идеями, как ончейн-рынки опционов, децентрализованное страхование и кредитование на основе интентов (некоторые хакатон-проекты в 2025 году занимались этими областями). Результаты начинают появляться: например, Lotus Finance был запущен как децентрализованный AMM опционов на Sui во втором квартале, а Turbos принял децентрализованный фронтенд-хостинг (через Walrus), чтобы расширить границы устойчивого к цензуре DeFi. Подобные инициативы, движимые сообществом, наряду с официальными партнерствами (например, сотрудничество Sui с Google Cloud для предоставления инструментов индексации ончейн-данных и вывода ИИ), создают плодотворную почву для новых протоколов. Мы видим примитивы DeFi на Sui, которые интегрируют ИИ-оракулы для динамического ценообразования, сервисы стейкинга BTC (SatLayer) и даже кросс-чейн интенты (интеграция NEAR Intents может рассматриваться как примитив для кросс-чейн ликвидности). Каждый из них добавляет строительный блок, который будущие разработчики могут комбинировать в новые финансовые продукты.

Резюме: В 2025 году экосистема Sui DeFi процветает благодаря инновациям. Ликвидность на Sui достигла многомиллиардного уровня, закрепленная крупными DEX и кредиторами, и подкрепленная стабильными притоками и ростом числа пользователей. Благодаря абстракции учетных записей и ориентированному на пользователя дизайну Sui значительно улучшил пользовательский опыт DeFi, привлекая более широкую аудиторию. А с новой волной примитивов – от нативных стейблкоинов и интеграции BTC до продвинутых AMM, бессрочных фьючерсов и токенов реальных активов – Sui расширяет возможности децентрализованных финансов. Ключевые протоколы и усилия сообщества стимулируют эту эволюцию: Cetus и Bluefin развивают технологию DEX, Suilend и другие расширяют кредитование на новые классы активов, Bucket, Agora, Ondo привносят новые активы ончейн и многие другие. Высокопрофильные партнерства (с поставщиками инфраструктуры, традиционными финансовыми учреждениями и кросс-чейн сетями) еще больше усиливают импульс Sui. Все эти элементы указывают на то, что Sui укрепляет свои позиции в качестве ведущего DeFi-хаба к 2025 году – характеризующегося глубокой ликвидностью, бесшовным удобством использования и неустанными инновациями в финансовых примитивах.

Источники:

• Sui Foundation – Sui Q2 2025 DeFi Roundup (15 июля 2025 г.)
• Sui Foundation – NEAR Intents Brings Lightning-Fast Cross-chain Swaps to Sui (17 июля 2025 г.)
• Sui Foundation – Sui to Support sBTC and Stacks (BTCfi Use Cases) (1 мая 2025 г.)
• Sui Foundation – All About Account Abstraction (4 октября 2023 г.)
• Ainvest News – Sui Network TVL Surpasses $1.4B Driven by DeFi Protocols (14 июля 2025 г.)
• Ainvest News – Sui DeFi TVL Surges 480% to $1.8B... (12 июля 2025 г.)
• Suipiens (сообщество Sui) – tBTC Integration Brings Bitcoin Liquidity to Sui (17 июля 2025 г.)
• Suipiens – Inside Suilend: Sui’s Leading Lending Platform (3 июля 2025 г.)
• The Defiant – Ondo to Bring RWA-Backed Stablecoins onto Sui (7 февраля 2024 г.)
• Официальная документация Sui – Intro to Sui: User Experience (функции абстракции учетных записей)