23 postagens marcadas com "Sui"

A privacidade está se tornando infraestrutura pública. Em 2025, desenvolvedores precisam de ferramentas que tornem a criptografia tão fácil quanto armazenar dados. O Seal da Mysten Labs oferece exatamente isso—gerenciamento descentralizado de segredos com controle de acesso onchain. Este tutorial te ensinará como construir aplicações Web3 seguras usando criptografia baseada em identidade, segurança threshold e políticas de acesso programáveis.

Introdução: Por que o Seal Importa para Web3​

Aplicações cloud tradicionais dependem de sistemas centralizados de gerenciamento de chaves onde um único provedor controla o acesso aos dados criptografados. Embora conveniente, isso cria pontos únicos perigosos de falha. Se o provedor for comprometido, ficar offline ou decidir restringir o acesso, seus dados se tornam inacessíveis ou vulneráveis.

Seal muda completamente esse paradigma. Construído pela Mysten Labs para a blockchain Sui, Seal é um serviço de gerenciamento descentralizado de segredos (DSM) que possibilita:

• Criptografia baseada em identidade onde o conteúdo é protegido antes de deixar seu ambiente
• Criptografia threshold que distribui acesso às chaves entre múltiplos nós independentes
• Controle de acesso onchain com time locks, token-gating e lógica de autorização customizada
• Design agnóstico de armazenamento que funciona com Walrus, IPFS ou qualquer solução de armazenamento

Seja construindo aplicações de mensagens seguras, plataformas de conteúdo restrito por tokens ou transferências de ativos com time lock, Seal fornece as primitivas criptográficas e infraestrutura de controle de acesso que você precisa.

Primeiros Passos​

Pré-requisitos​

Antes de mergulhar, certifique-se de ter:

• Node.js 18+ instalado
• Familiaridade básica com TypeScript/JavaScript
• Uma carteira Sui para testes (como Sui Wallet)
• Entendimento de conceitos blockchain

Instalação​

Instale o SDK Seal via npm:

npm install @mysten/seal

Você também vai querer o SDK Sui para interações blockchain:

npm install @mysten/sui

Configuração do Projeto​

Crie um novo projeto e inicialize-o:

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

Crie uma configuração TypeScript simples:

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

Conceitos Fundamentais: Como o Seal Funciona​

Antes de escrever código, vamos entender a arquitetura do Seal:

1. Criptografia Baseada em Identidade (IBE)​

Diferente da criptografia tradicional onde você criptografa para uma chave pública, IBE permite criptografar para uma identidade (como um endereço de email ou endereço Sui). O destinatário só pode descriptografar se conseguir provar que controla essa identidade.

2. Criptografia Threshold​

Em vez de confiar em um único servidor de chaves, Seal usa esquemas t-of-n threshold. Você pode configurar 3-de-5 servidores de chaves, significando que qualquer 3 servidores podem cooperar para fornecer chaves de descriptografia, mas 2 ou menos não conseguem.

3. Controle de Acesso Onchain​

Políticas de acesso são aplicadas por smart contracts da Sui. Antes que um servidor de chaves forneça chaves de descriptografia, ele verifica se o solicitante atende aos requisitos da política onchain (propriedade de tokens, restrições de tempo, etc.).

4. Rede de Servidores de Chaves​

Servidores de chaves distribuídos validam políticas de acesso e geram chaves de descriptografia. Esses servidores são operados por diferentes partes para garantir que não haja um único ponto de controle.

Implementação Básica: Sua Primeira Aplicação Seal​

Vamos construir uma aplicação simples que criptografa dados sensíveis e controla o acesso através de políticas blockchain da Sui.

Passo 1: Inicializar o Cliente Seal​

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

export async function createSealClient() {
  // Inicializar cliente Sui para testnet
  const suiClient = new SuiClient({
    url: 'https://fullnode.testnet.sui.io'
  });

  // Configurar cliente Seal com servidores de chaves da testnet
  const sealClient = new SealClient({
    suiClient,
    keyServers: [
      'https://keyserver1.seal-testnet.com',
      'https://keyserver2.seal-testnet.com',
      'https://keyserver3.seal-testnet.com'
    ],
    threshold: 2, // threshold 2-de-3
    network: 'testnet'
  });

  return { sealClient, suiClient };
}

Passo 2: Criptografia/Descriptografia Simples​

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

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

  // Dados para criptografar
  const sensitiveData = "Esta é minha mensagem secreta!";
  const recipientAddress = "0x742d35cc6d4c0c08c0f9bf3c9b2b6c64b3b4f5c6d7e8f9a0b1c2d3e4f5a6b7c8";

  try {
    // Criptografar dados para um endereço Sui específico
    const encryptedData = await sealClient.encrypt({
      data: Buffer.from(sensitiveData, 'utf-8'),
      recipientId: recipientAddress,
      // Opcional: adicionar metadados
      metadata: {
        contentType: 'text/plain',
        timestamp: Date.now()
      }
    });

    console.log('Dados criptografados:', {
      ciphertext: encryptedData.ciphertext.toString('base64'),
      encryptionId: encryptedData.encryptionId
    });

    // Depois, descriptografar os dados (requer autorização adequada)
    const decryptedData = await sealClient.decrypt({
      ciphertext: encryptedData.ciphertext,
      encryptionId: encryptedData.encryptionId,
      recipientId: recipientAddress
    });

    console.log('Dados descriptografados:', decryptedData.toString('utf-8'));

  } catch (error) {
    console.error('Falha na criptografia/descriptografia:', error);
  }
}

basicExample();

Controle de Acesso com Smart Contracts da Sui​

O verdadeiro poder do Seal vem do controle de acesso programável. Vamos criar um exemplo de criptografia com time lock onde os dados só podem ser descriptografados após um tempo específico.

Passo 1: Implementar Contrato de Controle de Acesso​

Primeiro, precisamos de um smart contract Move que define nossa política de acesso:

// 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
    }
}

Passo 2: Integrar com 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();

  // Criar política de acesso na Sui
  const txb = new TransactionBlock();

  const unlockTime = Date.now() + 60000; // Desbloquear em 1 minuto
  const authorizedUser = "0x742d35cc6d4c0c08c0f9bf3c9b2b6c64b3b4f5c6d7e8f9a0b1c2d3e4f5a6b7c8";

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

  // Executar transação para criar política
  const result = await suiClient.signAndExecuteTransactionBlock({
    transactionBlock: txb,
    signer: yourKeypair, // Seu keypair Sui
  });

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

  // Agora criptografar com esta política
  const sensitiveData = "Isso será desbloqueado em 1 minuto!";

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

  console.log('Dados com time lock criados. Tente descriptografar após 1 minuto.');

  return {
    encryptedData,
    policyId,
    unlockTime
  };
}

Exemplos Práticos​

Exemplo 1: Aplicação de Mensagens Seguras​

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

    // Armazenar mensagem criptografada em armazenamento descentralizado (Walrus)
    return this.storeOnWalrus(encryptedMessage);
  }

  async readMessage(encryptionId: string, recipientKeypair: any) {
    // Recuperar do armazenamento
    const encryptedData = await this.retrieveFromWalrus(encryptionId);

    // Descriptografar com 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) {
    // Integração com armazenamento Walrus
    // Isso faria upload dos dados criptografados para Walrus
    // e retornaria o blob ID para recuperação
  }

  private async retrieveFromWalrus(blobId: string) {
    // Recuperar dados criptografados do Walrus usando blob ID
  }
}

Exemplo 2: Plataforma de Conteúdo com Token-Gating​

// 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
  ) {
    // Criar política de propriedade de NFT
    const accessPolicy = await this.createNftPolicy(
      requiredNftCollection,
      creatorKeypair
    );

    // Criptografar conteúdo com requisito de acesso por NFT
    const encryptedContent = await this.sealClient.encrypt({
      data: Buffer.from(content, 'utf-8'),
      recipientId: 'nft_holders', // Destinatário especial para portadores de NFT
      accessPolicy: {
        policyId: accessPolicy.policyId,
        policyType: 'nft_ownership'
      }
    });

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

  async accessGatedContent(
    contentId: string,
    userAddress: string,
    userKeypair: any
  ) {
    // Verificar propriedade de NFT primeiro
    const hasAccess = await this.verifyNftOwnership(
      userAddress,
      contentId
    );

    if (!hasAccess) {
      throw new Error('Acesso negado: NFT necessário não encontrado');
    }

    // Descriptografar conteúdo
    const decryptedContent = await this.sealClient.decrypt({
      encryptionId: contentId,
      recipientId: userAddress
    });

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

  private async createNftPolicy(collection: string, creator: any) {
    // Criar contrato Move que verifica propriedade de NFT
    // Retorna ID do objeto de política
  }

  private async verifyNftOwnership(user: string, contentId: string) {
    // Verificar se usuário possui NFT necessário
    // Consultar Sui para propriedade de NFT
  }
}

Exemplo 3: Transferência de Ativos com Time Lock​

// 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();

  // Criar política de time lock na Sui
  const timeLockPolicy = await createTimeLockPolicy(
    unlockTimestamp,
    recipientAddress,
    senderKeypair,
    suiClient
  );

  // Criptografar dados de transferência de ativo
  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(`Ativo bloqueado até ${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'));

    // Processar a transferência de ativo
    console.log('Transferência de ativo desbloqueada:', transferData);

    return transferData;
  } catch (error) {
    console.error('Transferência ainda não desbloqueada ou acesso negado:', error);
    throw error;
  }
}

Integração com Armazenamento Descentralizado Walrus​

Seal funciona perfeitamente com Walrus, a solução de armazenamento descentralizado da Sui. Veja como integrar ambos:

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

    // Armazenar dados criptografados no Walrus
    const blobId = await this.walrusClient.store(
      encryptedData.ciphertext
    );

    // Retornar referência que inclui informações tanto do Seal quanto do Walrus
    return {
      blobId,
      encryptionId: encryptedData.encryptionId,
      accessPolicy: encryptedData.accessPolicy
    };
  }

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

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

    return decryptedData;
  }
}

// Exemplo de uso
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('Conteúdo de documento importante');
  const recipientAddress = '0x...';

  // Armazenar criptografado
  const result = await integration.storeEncryptedData(
    fileData,
    recipientAddress
  );

  console.log('Armazenado com Blob ID:', result.blobId);

  // Depois, recuperar e descriptografar
  const decrypted = await integration.retrieveAndDecrypt(
    result.blobId,
    result.encryptionId,
    recipientKeypair
  );

  console.log('Dados recuperados:', decrypted.toString());
}

Configuração Avançada de Criptografia Threshold​

Para aplicações de produção, você vai querer configurar criptografia threshold customizada com múltiplos servidores de chaves:

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

async function setupProductionSeal() {
  // Configurar com múltiplos servidores de chaves independentes
  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, // threshold 3-de-5
    network: 'mainnet',
    // Opções avançadas
    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 = "Dados criptografados de missão crítica";

  // Criptografar com altas garantias de segurança
  const encrypted = await sealClient.encrypt({
    data: Buffer.from(criticalData, 'utf-8'),
    recipientId: '0x...',
    // Exigir todos os 5 servidores para máxima segurança
    customThreshold: 5,
    // Adicionar redundância
    redundancy: 2,
    accessPolicy: {
      // Requisitos multifator
      requirements: ['nft_ownership', 'time_lock', 'multisig_approval']
    }
  });

  return encrypted;
}

Melhores Práticas de Segurança​

1. Gerenciamento de Chaves​

// src/security-practices.ts

// BOM: Usar derivação segura de chaves
import { generateKeypair } from '@mysten/sui/cryptography/ed25519';

const keypair = generateKeypair();

// BOM: Armazenar chaves de forma segura (exemplo com variáveis de ambiente)
const keypair = Ed25519Keypair.fromSecretKey(
  process.env.PRIVATE_KEY
);

// RUIM: Nunca hardcodar chaves
const badKeypair = Ed25519Keypair.fromSecretKey(
  "hardcoded-secret-key-12345" // Não faça isso!
);

2. Validação de Política de Acesso​

// Sempre validar políticas de acesso antes da criptografia
async function secureEncrypt(data: Buffer, recipient: string) {
  const { sealClient } = await createSealClient();

  // Validar endereço do destinatário
  if (!isValidSuiAddress(recipient)) {
    throw new Error('Endereço de destinatário inválido');
  }

  // Verificar se política existe e é válida
  const policy = await validateAccessPolicy(policyId);
  if (!policy.isValid) {
    throw new Error('Política de acesso inválida');
  }

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

3. Tratamento de Erros e Fallbacks​

// Tratamento robusto de erros
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('Acesso negado: Verifique suas permissões');
    } else if (error.code === 'KEY_SERVER_UNAVAILABLE') {
      // Tentar com configuração de backup
      return await retryWithBackupServers(encryptionId, userKeypair);
    } else if (error.code === 'THRESHOLD_NOT_MET') {
      throw new Error('Servidores de chaves insuficientes disponíveis');
    } else {
      throw new Error(`Falha na descriptografia: ${error.message}`);
    }
  }
}

4. Validação de Dados​

// Validar dados antes da criptografia
function validateDataForEncryption(data: Buffer): boolean {
  // Verificar limites de tamanho
  if (data.length > 1024 * 1024) { // Limite de 1MB
    throw new Error('Dados muito grandes para criptografia');
  }

  // Verificar padrões sensíveis (opcional)
  const dataStr = data.toString();
  if (containsSensitivePatterns(dataStr)) {
    console.warn('Aviso: Dados contêm padrões potencialmente sensíveis');
  }

  return true;
}

Otimização de Performance​

1. Operações em Lote​

// Agrupar múltiplas criptografias para eficiência
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 de Respostas de Servidores de Chaves​

// Cache de sessões de servidores de chaves para reduzir latência
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);
  }
}

Testando Sua Integração Seal​

Testes Unitários​

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

describe('Integração Seal', () => {
  it('deve criptografar e descriptografar dados com sucesso', async () => {
    const { sealClient } = await createSealClient();
    const testData = Buffer.from('mensagem de teste');
    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('mensagem de teste');
  });

  it('deve aplicar políticas de controle de acesso', async () => {
    // Testar que usuários não autorizados não podem descriptografar
    const { sealClient } = await createSealClient();

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

    await expect(
      sealClient.decrypt({
        ciphertext: encrypted.ciphertext,
        encryptionId: encrypted.encryptionId,
        recipientId: 'unauthorized-user'
      })
    ).rejects.toThrow('Acesso negado');
  });
});

Deploy para Produção​

Configuração de Ambiente​

// 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,
  // Configurações de segurança
  maxDataSize: 1024 * 1024, // 1MB
  sessionTimeout: 3600000, // 1 hora
  retryAttempts: 3
};

Monitoramento e Logging​

// utils/monitoring.ts
export class SealMonitoring {
  static logEncryption(encryptionId: string, recipient: string) {
    console.log(`[SEAL] Dados criptografados ${encryptionId} para ${recipient}`);
    // Enviar para seu serviço de monitoramento
  }

  static logDecryption(encryptionId: string, success: boolean) {
    console.log(`[SEAL] Descriptografia ${encryptionId}: ${success ? 'SUCESSO' : 'FALHA'}`);
  }

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

Recursos e Próximos Passos​

Documentação Oficial​

• Documentação Seal: https://seal-docs.wal.app/
• Repositório GitHub: https://github.com/MystenLabs/seal
• Documentação Sui: https://docs.sui.io/
• Documentação Walrus: https://docs.wal.app/

Comunidade e Suporte​

• Discord Sui: Junte-se ao canal #seal para suporte da comunidade
• GitHub Issues: Reporte bugs e solicite funcionalidades
• Fóruns de Desenvolvedores: Fóruns da comunidade Sui para discussões

Tópicos Avançados para Explorar​

1. Políticas de Acesso Customizadas: Construa lógica de autorização complexa com contratos Move
2. Integração Cross-Chain: Use Seal com outras redes blockchain
3. Gerenciamento de Chaves Empresarial: Configure sua própria infraestrutura de servidores de chaves
4. Auditoria e Compliance: Implemente logging e monitoramento para ambientes regulamentados

Aplicações de Exemplo​

• App de Chat Seguro: Mensagens criptografadas de ponta a ponta com Seal
• Gerenciamento de Documentos: Compartilhamento de documentos empresariais com controles de acesso
• Gerenciamento de Direitos Digitais: Distribuição de conteúdo com políticas de uso
• Analytics Preservando Privacidade: Workflows de processamento de dados criptografados

Conclusão​

Seal representa uma mudança fundamental em direção a tornar privacidade e criptografia preocupações de nível de infraestrutura em Web3. Ao combinar criptografia baseada em identidade, segurança threshold e controle de acesso programável, ele fornece aos desenvolvedores ferramentas poderosas para construir aplicações verdadeiramente seguras e descentralizadas.

As principais vantagens de construir com Seal incluem:

• Sem Ponto Único de Falha: Servidores de chaves distribuídos eliminam autoridades centrais
• Segurança Programável: Políticas de acesso baseadas em smart contracts fornecem autorização flexível
• Amigável ao Desenvolvedor: SDK TypeScript integra-se perfeitamente com ferramentas Web3 existentes
• Agnóstico de Armazenamento: Funciona com Walrus, IPFS ou qualquer solução de armazenamento
• Pronto para Produção: Construído pela Mysten Labs com padrões de segurança empresariais

Seja protegendo dados de usuários, implementando modelos de assinatura ou construindo aplicações complexas multipartidárias, Seal fornece as primitivas criptográficas e infraestrutura de controle de acesso que você precisa para construir com confiança.

Comece a construir hoje, e junte-se ao crescente ecossistema de desenvolvedores tornando a privacidade uma parte fundamental da infraestrutura pública.

Pronto para começar a construir? Instale @mysten/seal e comece a experimentar com os exemplos deste tutorial. A web descentralizada está esperando por aplicações que colocam privacidade e segurança em primeiro lugar.

TL;DR​

• A Talus está lançando o Nexus, um framework baseado em Move que compõe ferramentas on-chain e off-chain em fluxos de trabalho verificáveis em formato DAG, hoje coordenados por um serviço "Leader" confiável e com planos de evoluir para enclaves seguros e descentralização.
• A pilha mira a nascente economia de agentes, integrando registro de ferramentas, trilhos de pagamento, orçamentos de gás e marketplaces para que criadores de ferramentas e operadores de agentes monetizem o uso com auditoria.
• Existe um roteiro público para uma Protochain dedicada (Cosmos SDK + Move VM), mas Sui permanece como a camada de coordenação ativa; a integração Sui + Walrus fornece o substrato operacional atual.
• O desenho do token está em evolução: materiais mencionam o conceito histórico de $TAI e um Litepaper 2025 que apresenta o token de ecossistema$US para pagamentos, staking e mecanismos de priorização.
• Os principais riscos concentram-se em descentralizar o Leader, finalizar a economia do token e demonstrar o desempenho da Protochain enquanto se mantém uma boa experiência de desenvolvedor entre Sui, Walrus e serviços off-chain.

O que a Talus Está Construindo (e o que Não Está)​

A Talus se posiciona como uma camada de coordenação e monetização para agentes autônomos de IA, e não como um marketplace bruto de inferência. Seu produto central, Nexus, permite empacotar invocações de ferramentas, chamadas a APIs externas e lógica on-chain em fluxos DAG expressos em Sui Move. O design enfatiza verificabilidade, acesso baseado em capacidades e fluxos de dados regidos por esquemas, permitindo auditoria on-chain de cada invocação. A empresa complementa isso com marketplaces—Tool Marketplace, Agent Marketplace e Agent-as-a-Service—para facilitar descoberta e monetização de funcionalidades agênticas.

Em contraste, a Talus não opera seus próprios modelos de linguagem ou rede de GPUs. Ela espera que criadores de ferramentas envolvam APIs ou serviços existentes (OpenAI, busca vetorial, sistemas de trading, provedores de dados) e os registrem no Nexus. Assim, a Talus é complementar a redes de computação como Ritual ou Bittensor, que podem aparecer como ferramentas dentro dos fluxos Nexus.

Arquitetura: Plano de Controle On-Chain e Execução Off-Chain​

On-Chain (Sui Move)​

Os componentes on-chain vivem em Sui e entregam o plano de coordenação:

• Motor de fluxo de trabalho – A semântica do DAG inclui grupos de entrada, variantes ramificadas e verificações de concorrência. A validação estática busca prevenir condições de corrida antes da execução.
• Primitivos – ProofOfUID possibilita mensagens autenticadas entre pacotes sem forte acoplamento; OwnerCap/CloneableOwnerCap fornecem controle baseado em capacidades; ProvenValue e NexusData definem como os dados trafegam em linha ou por referências de armazenamento remoto.
• Default TAP (Talus Agent Package) – Agente de referência que demonstra como criar worksheets (objetos de prova), disparar execuções e confirmar resultados conforme a Nexus Interface v1.
• Registro de ferramentas e anti-spam – Criadores depositam colateral com bloqueio temporal para publicar uma definição de ferramenta, desincentivando spam sem retirar a permissão aberta.
• Serviço de gás – Objetos compartilhados guardam preços por ferramenta, orçamentos de gás e tickets com expiração ou limites de uso. Eventos registram cada reivindicação para auditar a liquidação entre donos de ferramentas e o Leader.

Leader Off-Chain​

O Leader operado pela Talus escuta eventos de Sui, busca esquemas de ferramentas, orquestra execuções off-chain (LLMs, APIs, jobs de computação), valida entradas/saídas frente aos esquemas declarados e envia os resultados de volta on-chain. Capacidades do Leader são objetos em Sui; uma transação falha pode "danificar" uma capacidade e impedir sua reutilização até o próximo epoch. A Talus pretende reforçar essa trilha com TEEs, múltiplos operadores e eventual participação permissionless.

Armazenamento e Verificabilidade​

O Walrus, camada de armazenamento descentralizado da Mysten Labs, é usado para memória de agentes, artefatos de modelos e grandes datasets. O Nexus mantém Sui como plano de controle determinístico e delega cargas mais pesadas ao Walrus. Materiais públicos indicam suporte a múltiplos modos de verificação—otimista, de conhecimento zero ou execução confiável—selecionáveis conforme o uso.

Experiência do Desenvolvedor e Produtos Iniciais​

A Talus mantém SDK em Rust, ferramentas de CLI e documentação com guias (construir DAGs, integrar LLMs, proteger ferramentas). Um catálogo de ferramentas padrão—completions da OpenAI, operações no X (Twitter), adaptadores Walrus, utilidades matemáticas—reduz a fricção para protótipos. No front consumer, experiências como IDOL.fun (mercados de previsão agente vs. agente) e AI Bae (companheiros de IA gamificados) funcionam como prova e canal de distribuição. O Talus Vision, construtor no-code, está posicionado como futura interface de marketplace que abstrai o design de fluxos para não desenvolvedores.

Desenho Econômico, Token e Gestão de Gás​

No deployment ativo em Sui, usuários financiam fluxos com SUI. O Serviço de Gás converte esses orçamentos em tickets específicos por ferramenta, aplica expiração ou limites e registra reivindicações reconciliáveis on-chain. Donos de ferramentas definem preços e o Leader é pago pelo mesmo fluxo. Como o Leader pode reivindicar orçamentos após execução bem-sucedida, os usuários precisam confiar no operador—mas os eventos emitidos oferecem trilhas de auditoria.

O desenho do token permanece fluido. Explicadores de terceiros referenciam o antigo $TAI**, enquanto o Litepaper 2025 propõe o token de ecossistema **$US com fornecimento de 10 bilhões. As funções declaradas incluem meio de pagamento para ferramentas e Leaders, staking com garantias de serviço e privilégios de priorização. Materiais indicam que SUI excedente pago na execução poderia ser convertido para $US via mercados. Investidores devem tratar essas informações como provisórias até a tokenomics final.

Financiamento, Equipe e Parcerias​

A Talus anunciou uma rodada estratégica de US$6 milhões** (total **US$ 9 milhões) liderada pela Polychain, com avaliação de US$ 150 milhões no final de 2024. Os recursos se destinam a avançar o Nexus, incubar aplicativos de consumo e construir a Protochain, L1 dedicada proposta para agentes. Fontes públicas citam Mike Hanono (CEO) e Ben Frigon (COO) como executivos-chave. Anúncios de integração destacam colaboração com os ecossistemas Sui e Walrus, reforçando a infraestrutura da Mysten Labs como ambiente atual.

Panorama Competitivo​

• Ritual se concentra em computação de IA descentralizada (Infernet) e integrações EVM, priorizando inferência verificável em vez de orquestração de fluxos.
• Autonolas (Olas) coordena serviços de agentes off-chain com incentivos on-chain; compartilha a tese da economia de agentes, mas não possui a camada de execução DAG em Move do Nexus.
• Fetch.ai oferece Agentverse e uAgents para conectar serviços autônomos; a Talus se diferencia pela verificação on-chain de cada etapa e contabilidade de gás embutida.
• Bittensor recompensa contribuição de modelos de ML via sub-redes TAO—um marketplace de computação que pode se integrar como ferramenta, mas não entrega os trilhos de monetização que a Talus busca.

No conjunto, a Talus pretende ocupar o plano de coordenação e liquidação dos fluxos agênticos, deixando o compute bruto e a inferência para redes especializadas plugadas como ferramentas.

Principais Riscos e Questões em Aberto​

1. Confiança no Leader – Até que TEEs e suporte multioperador sejam lançados, desenvolvedores precisam confiar que o Leader da Talus executará corretamente e retornará resultados fiéis.
2. Incerteza do token – A marca e as mecânicas migraram de $TAI para$US; cronogramas de fornecimento, distribuição e economia de staking ainda não foram finalizados.
3. Execução da Protochain – Materiais públicos descrevem uma cadeia Cosmos SDK com Move VM, mas repositórios, benchmarks e auditorias ainda não são públicos.
4. Qualidade das ferramentas e spam – O colateral desestimula spam, porém o sucesso de longo prazo depende de validação de esquemas, garantias de disponibilidade e resolução de disputas sobre resultados off-chain.
5. Complexidade de UX – Coordenar Sui, Walrus e APIs diversas adiciona sobrecarga operacional; o SDK e ferramentas no-code precisam abstrair isso para manter a adoção.

Marcos a Acompanhar em 2025–2026​

• Publicação do roadmap do Leader com endurecimento via TEE, regras de slashing e onboarding público de novos operadores.
• Expansão do Tool Marketplace: número de ferramentas registradas, modelos de precificação e métricas de qualidade (uptime, transparência de SLA).
• Adoção de IDOL.fun, AI Bae e Talus Vision como indicadores de demanda por experiências nativas de agentes.
• Dados de performance de fluxos robustos em Sui + Walrus: latência, throughput e consumo de gás.
• Divulgação da tokenomics final: cronograma de fornecimento, recompensas de staking e caminho de conversão SUI→$US.
• Liberação de repositórios, testnets e planos de interoperabilidade (ex. suporte IBC) da Protochain para validar a tese da cadeia dedicada.

Como Construtores e Operadores Podem se Engajar​

• Prototipe rápido – Combine o Default TAP com ferramentas padrão (OpenAI, X, Walrus) em um DAG de três nós para automatizar ingestão de dados, sumarização e ações on-chain.
• Monetize ferramentas especializadas – Empacote APIs proprietárias (dados financeiros, checagens de compliance, LLMs customizados) como ferramentas Nexus, defina preços e emita tickets de gás com expiração ou limite de uso para gerenciar demanda.
• Prepare-se para operar Leaders – Acompanhe documentação sobre requisitos de staking, lógica de slashing e procedimentos de falha para que provedores de infraestrutura possam atuar como Leaders adicionais quando a rede abrir.
• Avalie os flywheels de consumo – Analise retenção e gasto em IDOL.fun e AI Bae para entender se produtos consumer centrados em agentes podem impulsionar a demanda por ferramentas.

Conclusão​

A Talus apresenta um plano crível para a economia de agentes on-chain ao unir fluxos verificáveis em Move, composição de ferramentas controlada por capacidades e trilhos explícitos de monetização. O sucesso agora depende de provar que o modelo escala além de um Leader confiável, finalizar incentivos sustentáveis para o token e demonstrar que a Protochain consegue levar as lições de Sui a um ambiente dedicado. Construtores que precisam de liquidação transparente e fluxos agênticos componíveis devem manter o Nexus em seu radar enquanto acompanham o ritmo com que a Talus reduz essas incertezas.

Blockchains públicas oferecem um livro-razão sincronizado e auditável, mas expõem todos os dados por padrão. Lançado na Sui Mainnet em 3 de setembro de 2025, o Seal resolve esse dilema ao combinar lógica de políticas on-chain com gerenciamento descentralizado de chaves, permitindo que builders decidam exatamente quem pode descriptografar cada payload.

Resumo​

• O que é: Seal é uma rede de gestão de segredos que permite aos contratos inteligentes da Sui aplicar políticas de descriptografia on-chain enquanto os clientes criptografam dados com criptografia baseada em identidade (IBE) e dependem de servidores de chaves com limiar para derivar as chaves.
• Por que importa: Em vez de backends personalizados ou scripts opacos fora da cadeia, privacidade e controle de acesso tornam-se primitivas de Move de primeira classe. Os desenvolvedores podem armazenar os cifrados em qualquer lugar—Walrus é o complemento natural—e ainda controlar quem pode ler.
• Quem se beneficia: Equipes que entregam conteúdo tokenizado, revelações com bloqueio temporal, mensagens privadas ou agentes de IA guiados por políticas podem integrar o SDK do Seal e focar na lógica do produto, não na infraestrutura criptográfica.

A lógica de políticas vive em Move​

Os pacotes do Seal incluem funções Move seal_approve* que definem quem pode solicitar chaves para um determinado identificador e em quais condições. As políticas podem combinar propriedade de NFT, listas de permissão, bloqueios temporais ou sistemas de papéis personalizados. Quando um usuário ou agente solicita descriptografia, os servidores de chaves avaliam essas políticas consultando o estado de um full node da Sui e só aprovam se a cadeia concordar.

Como as regras de acesso fazem parte do seu pacote on-chain, elas são transparentes, auditáveis e versionadas junto com o restante do código do contrato inteligente. Atualizações de governança podem ser implementadas como qualquer upgrade de Move, com revisão da comunidade e histórico on-chain.

Criptografia de limiar gerencia as chaves​

O Seal criptografa dados para identidades definidas pela aplicação. Um comitê de servidores de chaves independentes—escolhido pelo desenvolvedor—compartilha o segredo mestre de IBE. Quando a verificação de política é aprovada, cada servidor deriva uma fração de chave para a identidade solicitada. Quando o quórum de t servidores responde, o cliente combina as frações para obter uma chave de descriptografia utilizável.

Você controla o equilíbrio entre disponibilidade e confidencialidade ao escolher os membros do comitê (Ruby Nodes, NodeInfra, Overclock, Studio Mirai, H2O Nodes, Triton One ou o serviço Enoki da Mysten) e definir o limiar. Precisa de mais disponibilidade? Selecione um comitê maior com limiar menor. Quer garantias de privacidade mais fortes? Endureça o quórum e privilegie provedores permissionados.

Experiência do desenvolvedor: SDK e chaves de sessão​

O Seal oferece um SDK TypeScript (npm i @mysten/seal) que cuida dos fluxos de criptografia/descriptografia, formatação de identidades e batching. Ele também emite chaves de sessão para evitar que carteiras recebam prompts constantes quando o app precisa de acesso repetido. Para fluxos avançados, contratos Move podem solicitar descriptografia on-chain em modos especiais, permitindo que lógicas como revelações em escrow ou leilões resistentes a MEV sejam executadas diretamente no código do contrato.

Como o Seal é agnóstico quanto ao armazenamento, as equipes podem combiná-lo com Walrus para blobs verificáveis, com IPFS ou até com repositórios centralizados quando o cenário operacional exigir. O limite de criptografia—e a aplicação das políticas—acompanha os dados independentemente de onde o cifrado esteja armazenado.

Boas práticas ao projetar com Seal​

• Modele o risco de disponibilidade: Limiares como 2-de-3 ou 3-de-5 se traduzem diretamente em garantias de uptime. Implantações em produção devem misturar provedores, monitorar telemetria e estabelecer SLA antes de delegar fluxos críticos.
• Atenção à variação de estado: A avaliação de políticas depende de chamadas dry_run em full nodes. Evite regras que dependam de contadores que mudam rapidamente ou da ordenação dentro do checkpoint para prevenir aprovações inconsistentes entre servidores.
• Planeje a higiene das chaves: As chaves derivadas residem no cliente. Implemente logs, gire chaves de sessão e considere criptografia envelope—use o Seal para proteger uma chave simétrica que cifra o payload maior—para limitar o impacto caso um dispositivo seja comprometido.
• Projete para rotação: O comitê usado em um cifrado fica fixo no momento da criptografia. Crie caminhos de upgrade que recriptografem os dados com novos comitês quando for necessário trocar provedores ou ajustar as hipóteses de confiança.

Próximos passos​

O roadmap do Seal aponta para servidores MPC operados por validadores, ferramentas de cliente no estilo DRM e opções de KEM pós-quântico. Para builders que exploram agentes de IA, conteúdo premium ou fluxos de dados regulados, a versão atual já oferece um plano claro: codifique sua política em Move, componha um comitê de chaves diversificado e entregue experiências criptografadas que respeitem a privacidade do usuário sem sair da zona de confiança da Sui.

Se estiver avaliando o Seal para seu próximo lançamento, comece prototipando uma política simples com NFT e um comitê aberto 2-de-3, depois evolua para a combinação de provedores e controles operacionais que correspondam ao perfil de risco do seu aplicativo.

Imagine um mundo onde os usuários podem interagir com seu dApp de forma fluida, sem precisar possuir nenhum token nativo (SUI). Isso já não é mais um sonho distante. Com a Gas Station da Sui (também conhecida como Paymaster), desenvolvedores podem cobrir as taxas de gas em nome de seus usuários, removendo completamente uma das maiores barreiras para novos entrantes no Web3 e permitindo uma experiência on‑chain verdadeiramente sem atritos.

Este artigo fornece um guia completo para transformar seu dApp em uma solução sem gas. Vamos mergulhar nos conceitos centrais do Sui Paymaster, sua arquitetura, padrões de implementação e melhores práticas.

1. Contexto e Conceitos Principais: O que é uma Transação Patrocinada?​

No universo blockchain, toda transação requer uma taxa de rede, ou “gas”. Para usuários acostumados às experiências fluidas do Web2, isso representa um obstáculo cognitivo e operacional significativo. A Sui resolve esse desafio ao nível do protocolo com Transações Patrocinadas.

A ideia central é simples: permitir que uma parte (o Patrocinador) pague as taxas de gas SUI pela transação de outra parte (o Usuário). Dessa forma, mesmo que o usuário não tenha SUI em sua carteira, ele ainda pode iniciar ações on‑chain com sucesso.

Paymaster ≈ Gas Station​

No ecossistema Sui, a lógica de patrocínio de transações costuma ser gerida por um serviço off‑chain ou on‑chain chamado Gas Station ou Paymaster. Suas principais responsabilidades incluem:

1. Avaliar a Transação: Recebe os dados da transação sem gas do usuário (GasLessTransactionData).
2. Fornecer Gas: Bloqueia e aloca a taxa de gas necessária para a transação. Isso geralmente é gerido por um pool de gas composto por vários objetos SUI Coin.
3. Gerar a Assinatura do Patrocinador: Após aprovar o patrocínio, a Gas Station assina a transação com sua chave privada (SponsorSig), certificando sua disposição em pagar a taxa.
4. Retornar a Transação Assinada: Envia de volta o TransactionData, que agora inclui os dados de gas e a assinatura do patrocinador, aguardando a assinatura final do usuário.

Em resumo, uma Gas Station funciona como um serviço de reabastecimento para os usuários do seu dApp, garantindo que seus “veículos” (transações) possam viajar suavemente na rede Sui.

2. Arquitetura de Alto Nível e Fluxo de Interação​

Uma transação sem gas típica envolve a coordenação entre o usuário, o frontend do dApp, a Gas Station e um Full Node Sui. A sequência de interação é a seguinte:

Desdobramento do Fluxo:

1. O Usuário realiza uma ação na UI do dApp, que constrói um pacote de dados de transação sem informações de gas.
2. O dApp envia esses dados ao Gas Station designado para solicitar patrocínio.
3. O Gas Station verifica a validade da solicitação (por exemplo, checa se o usuário é elegível), então preenche a transação com um Gas Coin e sua assinatura, retornando a transação semipreenchida ao dApp.
4. O Usuário visualiza os detalhes completos da transação em sua carteira (ex.: “Comprar um NFT”) e fornece a assinatura final. Essa etapa garante que o usuário mantenha consentimento e controle sobre suas ações.
5. O dApp transmite a transação completa, contendo ambas as assinaturas, ao Full Node Sui.
6. Após a finalização on‑chain, o Gas Station pode confirmar o evento escutando receipts ou eventos, e então notificar o backend do dApp via webhook, fechando o ciclo do processo de negócio.

3. Três Modelos Principais de Interação​

Você pode usar os três modelos a seguir individualmente ou combinados, conforme as necessidades do seu negócio.

Modelo 1: Usuário Inicia → Patrocinador Aprova (Mais Comum)​

Este é o modelo padrão, adequado para a maioria das interações dentro do dApp.

1. Usuário constrói GasLessTransactionData: O usuário executa uma ação no dApp.
2. Patrocinador adiciona GasData e assina: O backend do dApp envia a transação ao Gas Station, que aprova, anexa um Gas Coin e adiciona sua assinatura.
3. Usuário revisa e fornece assinatura final: O usuário confirma os detalhes finais na carteira e assina. O dApp então submete a transação à rede.

Esse modelo oferece um excelente equilíbrio entre segurança e experiência do usuário.

Modelo 2: Patrocinador Inicia Airdrops/Incentivos​

Ideal para airdrops, incentivos a usuários ou distribuições em lote.

1. Patrocinador pré-preenche TransactionData + assina: O patrocinador (geralmente a equipe do projeto) constrói a maior parte da transação (ex.: airdrop de NFT para um endereço específico) e anexa sua assinatura de patrocínio.
2. Segunda assinatura do Usuário a torna efetiva: O usuário só precisa assinar essa transação “pré‑aprovada” uma vez para que seja executada.

Isso cria uma experiência extremamente fluida. Com apenas um clique para confirmar, usuários podem reivindicar recompensas ou concluir tarefas, aumentando drasticamente as taxas de conversão de campanhas de marketing.

Modelo 3: GasData Coringa (Modelo de Linha de Crédito)​

Um modelo mais flexível e baseado em permissões.

1. Patrocinador transfere um objeto GasData: Primeiro, o patrocinador cria um ou mais objetos Gas Coin com um orçamento específico e transfere a propriedade diretamente ao usuário.
2. Usuário gasta livremente dentro do orçamento: O usuário pode usar esses Gas Coins para pagar quaisquer transações que iniciar, respeitando limites de valor e período de validade.
3. Gas Coin é devolvido: Quando esgotado ou expirado, o objeto Gas Coin pode ser projetado para ser destruído automaticamente ou retornado ao patrocinador.

Esse modelo equivale a oferecer ao usuário um “cartão de crédito de taxas de gas” limitado no tempo e no valor, adequado para cenários que exigem alta autonomia do usuário, como oferecer uma experiência free‑to‑play durante uma temporada de jogo.

4. Cenários de Aplicação Típicos​

O poder do Sui Paymaster vai além de resolver o problema das taxas de gas; ele permite integração profunda com a lógica de negócio para criar novas possibilidades.

Cenário 1: Paywalls​

Plataformas de conteúdo ou serviços dApp frequentemente exigem que usuários cumpram certos critérios (ex.: possuir um NFT VIP, alcançar um nível de membresia) para acessar funcionalidades. O Paymaster pode implementar essa lógica de forma perfeita.

• Fluxo: O usuário solicita uma ação → o backend do dApp verifica as qualificações (ex.: propriedade de NFT) → se elegível, chama o Paymaster para patrocinar a taxa de gas; caso contrário, nega a solicitação de assinatura.
• Vantagem: Modelo inerentemente resistente a bots e abusos. Como a decisão de patrocínio ocorre no backend, usuários maliciosos não podem contornar a verificação para drenar fundos de gas.

Cenário 2: Checkout com Um Clique​

Em e‑commerce ou compras dentro de jogos, simplificar o processo de pagamento é crucial.

• Fluxo: O usuário clica em “Comprar Agora”. O dApp constrói uma transação que inclui a lógica de negócio (ex.: transfer_nft_to_user). O usuário só precisa assinar para aprovar a ação em sua carteira, sem se preocupar com gas. A taxa de gas é coberta pelo Patrocinador do dApp.
• Vantagem: Você pode codificar parâmetros de negócio como order_id diretamente no ProgrammableTransactionBlock, permitindo atribuição on‑chain precisa para pedidos no backend.

Cenário 3: Atribuição de Dados​

Rastreamento preciso de dados é fundamental para otimização de negócios.

• Fluxo: Ao construir a transação, escreva um identificador único (como order_hash) nos parâmetros da transação ou em um evento que será emitido na execução.
• Vantagem: Quando o Gas Station recebe o receipt on‑chain de uma transação bem‑sucedida, ele pode extrair facilmente esse order_hash analisando o evento ou os dados da transação. Isso permite mapear com precisão mudanças de estado on‑chain a pedidos ou ações específicas no backend.

5. Esqueleto de Código (Baseado no SDK Rust)​

A seguir, um trecho simplificado demonstrando os passos principais da interação.

// 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)?;

Para uma implementação completa, consulte o Tutorial de Gas Station na documentação oficial da Sui, que oferece exemplos de código prontos para uso.

6. Riscos e Proteções​

Embora poderoso, implantar uma Gas Station em produção requer atenção cuidadosa aos seguintes riscos:

• Equivocação (Double‑Spending): Um usuário malicioso pode tentar usar o mesmo Gas Coin em múltiplas transações paralelas, o que faria o Gas Coin ficar bloqueado pela rede Sui. Isso pode ser mitigado atribuindo um Gas Coin único por usuário ou por transação, mantendo uma blacklist e aplicando limites de taxa.
• Gerenciamento do Pool de Gas: Em cenários de alta concorrência, um único Gas Coin de valor elevado pode se tornar um gargalo de desempenho. O serviço de Gas Station deve ser capaz de dividir automaticamente grandes SUI Coins em vários Gas Coins menores e recolhê‑los eficientemente após o uso. Provedores profissionais como a Shinami oferecem soluções gerenciadas maduras para isso.
• Autorização e Rate Limiting: É imprescindível estabelecer políticas rígidas de autorização e limitação de taxa. Por exemplo, controlar limites de patrocínio e frequência com base em IP, endereço de carteira ou tokens de API, evitando que o serviço seja drenado por atores maliciosos.

7. Ferramentas do Ecossistema​

O ecossistema Sui já disponibiliza um conjunto rico de ferramentas para simplificar o desenvolvimento e a implantação de Paymasters:

• SDKs Oficiais (Rust/TypeScript): Incluem APIs de alto nível como sponsor_transaction_block(), reduzindo significativamente a complexidade de integração.
• Shinami Gas Station: Serviço gerenciado tudo‑em‑um, com divisão/recolhimento automático de Gas Coins, monitoramento detalhado de métricas e notificações via webhook, permitindo que desenvolvedores foquem na lógica de negócio.
• Enoki / Mysten Demos: A comunidade e a Mysten Labs oferecem implementações open‑source de Paymaster que podem servir como referência para construir seu próprio serviço.

8. Checklist de Implementação​

Pronto para levar seu dApp à era sem gas? Confira esta lista antes de iniciar:

• Planeje seu Fluxo de Financiamento: Defina a fonte de fundos do Patrocinador, orçamento e estratégia de reposição. Configure monitoramento e alertas para métricas chave (ex.: saldo do pool de gas, taxa de consumo).
• Reserve Campos de Atribuição: Ao projetar os parâmetros da transação, reserve campos para identificadores de negócio como order_id ou user_id.
• Implemente Políticas Anti‑Abuso: Autorizações estritas, limitação de taxa e mecanismos de logging são obrigatórios antes de ir ao ar.
• Teste em Testnet: Seja construindo seu próprio serviço ou integrando um Gas Station de terceiros, realize testes de concorrência e stress em testnet ou devnet primeiro.
• Otimize Continuamente: Após o lançamento, acompanhe taxas de sucesso, motivos de falha e custos de gas. Ajuste orçamento e estratégias com base nos dados coletados.

Conclusão​

O Sui Paymaster (Gas Station) é mais do que uma ferramenta para cobrir taxas de gas dos usuários. É um paradigma poderoso que combina elegantemente uma experiência “zero SUI on‑chain” para o usuário com a necessidade de negócios de “atribuição on‑chain ao nível de ordem” dentro de uma única transação atômica. Ele abre caminho para que usuários Web2 entrem no Web3 e oferece aos desenvolvedores flexibilidade sem precedentes para personalização de negócios.

Com um ecossistema de ferramentas cada vez mais maduro e os atuais baixos custos de gas na rede Sui, nunca houve momento melhor para atualizar os fluxos de pagamento e interação do seu dApp para a era sem gas.

Estamos felizes em anunciar o lançamento do staking de token SUI na BlockEden.xyz! A partir de hoje, você pode fazer staking dos seus tokens SUI diretamente através da nossa plataforma e ganhar um APY de 2,08% enquanto apoia a segurança e a descentralização da rede SUI.

O que há de novo: uma experiência de staking SUI sem atritos​

Nosso novo recurso de staking traz staking de nível institucional para todos, com uma interface simples e intuitiva que torna a obtenção de recompensas sem esforço.

Principais recursos​

Staking de Um Clique Fazer staking de SUI nunca foi tão fácil. Basta conectar sua carteira Suisplash, inserir a quantidade de SUI que deseja fazer staking e aprovar a transação. Você começará a ganhar recompensas quase imediatamente, sem procedimentos complexos.

Recompensas Competitivas Ganhe um APY de 2,08% competitivo sobre seu SUI em staking. Nossa taxa de comissão de 8% é transparente, garantindo que você saiba exatamente o que esperar. As recompensas são distribuídas diariamente ao final de cada epoch.

Validador Confiável Junte‑se a uma comunidade em crescimento que já fez staking de mais de 22 milhões de SUI com o validador BlockEden.xyz. Temos um histórico comprovado de serviços de validação confiáveis, suportados por infraestrutura de nível empresarial que garante 99,9% de uptime.

Gestão Flexível Seus ativos permanecem flexíveis. O staking é instantâneo, o que significa que suas recompensas começam a acumular imediatamente. Caso precise acessar seus fundos, você pode iniciar o processo de unstaking a qualquer momento. Seu SUI ficará disponível após o período padrão de desbloqueio da rede SUI, de 24 a 48 horas. Você pode acompanhar seus stakes e recompensas em tempo real através do nosso painel.

Por que fazer staking de SUI com a BlockEden.xyz?​

Escolher um validador é uma decisão crítica. Veja por que a BlockEden.xyz é uma escolha sólida para suas necessidades de staking.

Confiabilidade em que você pode confiar​

A BlockEden.xyz tem sido um alicerce da infraestrutura de blockchain desde a sua criação. Nossa infraestrutura de validadores alimenta aplicações empresariais e tem mantido uptime excepcional em múltiplas redes, garantindo geração consistente de recompensas.

Transparente e Justa​

Acreditamos em total transparência. Não há taxas ocultas — apenas uma comissão de 8% clara sobre as recompensas que você ganha. Você pode monitorar seu desempenho de staking com relatórios em tempo real e verificar a atividade do nosso validador on‑chain.

• Endereço do Validador Aberto: 0x3b5664bb0f8bb4a8be77f108180a9603e154711ab866de83c8344ae1f3ed4695

Integração Sem Atritos​

Nossa plataforma foi projetada para simplicidade. Não há necessidade de criar uma conta; você pode fazer staking diretamente da sua carteira. A experiência é otimizada para a carteira Suisplash, e nossa interface limpa e intuitiva foi construída tanto para iniciantes quanto para especialistas.

Como Começar​

Começar a fazer staking de SUI na BlockEden.xyz leva menos de dois minutos.

Etapa 1: Visite a página de Staking​

Acesse blockeden.xyz/dash/stake. Você pode iniciar o processo imediatamente, sem registro de conta.

Etapa 2: Conecte sua Carteira​

Se ainda não a tem, instale a carteira Suisplash. Clique no botão “Connect Wallet” na nossa página de staking e aprove a conexão na extensão da carteira. Seu saldo de SUI será exibido automaticamente.

Etapa 3: Escolha o Valor do Stake​

Insira a quantidade de SUI que deseja fazer staking (mínimo 1 SUI). Você pode usar o botão “MAX” para fazer staking de todo o saldo disponível, deixando uma pequena quantia para taxas de gas. Um resumo mostrará o valor do stake e as recompensas anuais estimadas.

Etapa 4: Confirme e Comece a Ganhar​

Clique em “Stake SUI” e aprove a transação final na sua carteira. Seu novo stake aparecerá no painel em tempo real, e você começará a acumular recompensas imediatamente.

Economia do Staking: O que Você Precisa Saber​

Entender a mecânica do staking é fundamental para gerir seus ativos de forma eficaz.

Estrutura de Recompensas​

• APY Base: 2,08% ao ano
• Frequência de Recompensa: Distribuída a cada epoch (aproximadamente 24 horas)
• Comissão: 8% das recompensas ganhas
• Capitalização: As recompensas são adicionadas à sua carteira e podem ser re‑staked para alcançar crescimento composto.

Exemplo de Ganhos​

A seguir, uma divisão simples dos ganhos potenciais baseada em um APY de 2,08%, após a taxa de comissão de 8%.

Nota: Estes são estimativas. As recompensas reais podem variar conforme as condições da rede.

Considerações de Risco​

O staking envolve certos riscos que você deve conhecer:

• Período de Unbonding: Ao fazer unstaking, seu SUI fica sujeito a um período de 24‑48 horas em que não pode ser acessado nem gera recompensas.
• Risco do Validador: Embora mantenhamos altos padrões, todo validador tem riscos operacionais. Escolher um validador reputado como a BlockEden.xyz é importante.
• Risco da Rede: O staking é uma forma de participação na rede e está sujeito aos riscos inerentes ao protocolo blockchain subjacente.
• Risco de Mercado: O valor de mercado do token SUI pode flutuar, afetando o valor total dos seus ativos em staking.

Excelência Técnica​

Infraestrutura Empresarial​

Nossos nós de validador são construídos sobre uma base de excelência técnica. Utilizamos sistemas redundantes distribuídos em múltiplas regiões geográficas para garantir alta disponibilidade. Nossa infraestrutura é monitorada 24/7 com recursos automáticos de failover, e uma equipe profissional de operações gerencia o sistema continuamente. Também realizamos auditorias de segurança regulares e verificações de conformidade.

Código Aberto e Transparência​

Comprometemo‑nos com os princípios de código aberto. Nossa integração de staking foi desenvolvida para ser transparente, permitindo que os usuários inspecionem os processos subjacentes. Métricas em tempo real estão disponíveis publicamente nos exploradores da rede SUI, e nossa estrutura de taxas é totalmente aberta, sem custos ocultos. Também participamos ativamente da governança da comunidade para apoiar o ecossistema SUI.

Apoio ao Ecossistema SUI​

Ao fazer staking com a BlockEden.xyz, você faz mais do que ganhar recompensas. Você contribui ativamente para a saúde e o crescimento de toda a rede SUI.

• Segurança da Rede: Seu stake aumenta o total que protege a rede SUI, tornando-a mais robusta contra possíveis ataques.
• Descentralização: Apoiar validadores independentes como a BlockEden.xyz reforça a resiliência da rede e impede a centralização.
• Crescimento do Ecossistema: As taxas de comissão que recebemos são reinvestidas na manutenção e desenvolvimento de infraestrutura crítica.
• Inovação: A receita apoia nossa pesquisa e desenvolvimento de novas ferramentas e serviços para a comunidade blockchain.

Segurança e Melhores Práticas​

Priorize a segurança dos seus ativos.

Segurança da Carteira​

• Nunca compartilhe suas chaves privadas ou frase‑semente com ninguém.
• Use uma carteira hardware para armazenar e fazer staking de grandes quantias.
• Sempre verifique os detalhes da transação na sua carteira antes de assinar.
• Mantenha seu software de carteira atualizado para a versão mais recente.

Segurança no Staking​

• Se você é novo no staking, comece com um valor pequeno para se familiarizar com o processo.
• Considere diversificar seu stake entre múltiplos validadores reputados para reduzir risco.
• Monitore regularmente seus ativos em staking e recompensas.
• Certifique‑se de entender o período de unbonding antes de comprometer seus fundos.

Junte‑se ao Futuro do Staking SUI​

O lançamento do staking de SUI na BlockEden.xyz é mais do que um novo recurso; é uma porta de entrada para participação ativa na economia descentralizada. Seja você um usuário experiente de DeFi ou esteja apenas começando, nossa plataforma oferece uma forma simples e segura de ganhar recompensas enquanto contribui para o futuro da rede SUI.

Pronto para começar a ganhar?

Visite blockeden.xyz/dash/stake e faça staking dos seus primeiros tokens SUI hoje mesmo!

Sobre a BlockEden.xyz​

A BlockEden.xyz é um provedor líder de infraestrutura de blockchain que oferece serviços confiáveis, escaláveis e seguros para desenvolvedores, empresas e a comunidade Web3 em geral. De serviços de API a operações de validadores, estamos comprometidos em construir a base para um futuro descentralizado.

• Fundada: 2021
• Redes Suportadas: mais de 15 redes blockchain
• Clientes Empresariais: mais de 500 empresas ao redor do mundo
• Valor Total Garantido: mais de US$ 100 milhões em todas as redes

Nos siga no Twitter, participe do nosso Discord e explore nossa suíte completa de serviços em BlockEden.xyz.

Aviso: Este post de blog tem fins informativos apenas e não constitui aconselhamento financeiro. O staking de criptomoedas envolve riscos, incluindo a possível perda do principal. Por favor, faça sua própria pesquisa e considere sua tolerância ao risco antes de fazer staking.

Introdução​

Anunciada para lançamento público em 3 de maio de 2023, após um extenso testnet de três ondas, a blockchain Sui introduziu um sistema inovador de precificação de gas projetado para beneficiar tanto usuários quanto validadores. No seu cerne está o Preço de Gas de Referência (RGP), uma taxa base de gas em toda a rede que os validadores concordam no início de cada época (aproximadamente 24 horas).

Este sistema visa criar um ecossistema mutuamente benéfico para detentores do token SUI, validadores e usuários finais, oferecendo custos de transação baixos e previsíveis ao mesmo tempo em que recompensa validadores por comportamento eficiente e confiável. Este relatório aprofunda como o RGP é determinado, os cálculos que os validadores realizam, seu impacto na economia da rede, sua evolução por meio da governança e como ele se compara a outros modelos de gas em blockchains.

O Mecanismo de Preço de Gas de Referência (RGP)​

O RGP da Sui não é um valor estático, mas é reestabelecido a cada época por meio de um processo dinâmico conduzido pelos validadores.

• A Pesquisa de Preço de Gas: No início de cada época, cada validador submete seu “preço de reserva” — o preço mínimo de gas que está disposto a aceitar para processar transações. O protocolo então ordena essas submissões por stake e define o RGP para aquela época no percentil de 2/3 ponderado por stake. Esse design garante que validadores que representam uma supermaioria (pelo menos dois terços) do stake total estejam dispostos a processar transações a esse preço, assegurando um nível confiável de serviço.

• Cadência de Atualização e Requisitos: Embora o RGP seja definido a cada época, os validadores precisam gerenciar ativamente suas cotações. Segundo as diretrizes oficiais, os validadores devem atualizar sua cotação de preço de gas pelo menos uma vez por semana. Além disso, se houver uma mudança significativa no valor do token SUI, como uma flutuação de 20 % ou mais, os validadores devem atualizar sua cotação imediatamente para garantir que o RGP reflita com precisão as condições de mercado atuais.

• Regra de Contagem e Distribuição de Recompensas: Para garantir que os validadores cumpram o RGP acordado, a Sui emprega uma “regra de contagem”. Ao longo de uma época, os validadores monitoram o desempenho uns dos outros, verificando se seus pares estão processando prontamente transações precificadas pelo RGP. Esse monitoramento gera uma pontuação de desempenho para cada validador. No final da época, essas pontuações são usadas para calcular um multiplicador de recompensa que ajusta a parte de cada validador nas recompensas de stake.

  • Validadores que tiveram bom desempenho recebem um multiplicador de ≥1, aumentando suas recompensas.
  • Validadores que atrasaram, pararam ou falharam em processar transações ao RGP recebem um multiplicador de <1, efetivamente reduzindo parte de seus ganhos.

Esse sistema de duas partes cria uma estrutura de incentivos poderosa. Ele desencoraja validadores de cotar um preço irrealisticamente baixo que não possam sustentar, pois a penalidade financeira por desempenho insuficiente seria severa. Em vez disso, os validadores são motivados a submeter o menor preço que possam manejar de forma sustentável e eficiente.

Operações de Validador: Calculando a Cotação de Preço de Gas​

Do ponto de vista de um validador, definir a cotação do RGP é uma tarefa operacional crítica que impacta diretamente a lucratividade. Requer a construção de pipelines de dados e camadas de automação para processar diversos inputs de fontes on‑chain e off‑chain. Os principais inputs incluem:

• Unidades de gas executadas por época
• Recompensas de staking e subsídios por época
• Contribuições ao fundo de armazenamento
• Preço de mercado do token SUI
• Despesas operacionais (hardware, hospedagem em nuvem, manutenção)

O objetivo é calcular uma cotação que garanta recompensas líquidas positivas. O processo envolve várias fórmulas chave:

1. Calcular Custo Operacional Total: Determina as despesas do validador em moeda fiduciária para uma dada época.

   $$\text{Custo}_{\text{época}} = (\text{Unidades de Gas Totais}_{\text{época}}) \times (\text{Custo em \$ por Unidade de Gas}_{\text{época}})$$

2. Calcular Recompensas Totais: Determina a receita total do validador em moeda fiduciária, proveniente tanto de subsídios do protocolo quanto de taxas de transação.

   $$\text{\$Recompensas}_{\text{época}} = (\text{Recompensas de Stake Totais em SUI}_{\text{época}}) \times (\text{Preço do Token SUI})$$

   Onde Recompensas de Stake Totais é a soma de quaisquer Subsídios de Stake fornecidos pelo protocolo e das Taxas de Gas coletadas das transações.

3. Calcular Recompensas Líquidas: Medida final de lucratividade para um validador.

   $$\text{\$Recompensas Líquidas}_{\text{época}} = \text{\$Recompensas}_{\text{época}} - \text{\$Custo}_{\text{época}}$$

Modelando seus custos e recompensas esperados em diferentes níveis de RGP, os validadores podem determinar uma cotação ótima a ser submetida à Pesquisa de Preço de Gas.

No lançamento da mainnet, a Sui definiu o RGP inicial como um 1.000 MIST fixo (1 SUI = 10⁹ MIST) nas primeiras uma a duas semanas. Isso proporcionou um período operacional estável para que os validadores coletassem dados suficientes de atividade da rede e estabelecessem seus processos de cálculo antes que o mecanismo dinâmico de pesquisa entrasse em pleno efeito.

Impacto no Ecossistema Sui​

O mecanismo RGP molda profundamente a economia e a experiência do usuário em toda a rede.

• Para Usuários: Taxas Previsíveis e Estáveis: O RGP funciona como uma âncora credível para os usuários. A taxa de gas de uma transação segue a fórmula simples: Preço de Gas do Usuário = RGP + Gorjeta. Em condições normais, nenhuma gorjeta é necessária. Durante congestionamento da rede, os usuários podem adicionar uma gorjeta para ganhar prioridade, criando um mercado de taxas sem alterar o preço base estável dentro da época. Esse modelo oferece muito mais estabilidade de taxa do que sistemas onde a taxa base muda a cada bloco.

• Para Validadores: Uma Corrida à Eficiência: O sistema fomenta competição saudável. Validadores são incentivados a reduzir seus custos operacionais (por meio de otimização de hardware e software) para poder cotar um RGP mais baixo de forma lucrativa. Essa “corrida à eficiência” beneficia toda a rede ao reduzir os custos de transação. O mecanismo também empurra os validadores a manter margens de lucro equilibradas; cotar muito alto corre o risco de ser excluído do cálculo do RGP, enquanto cotar muito baixo leva a perdas operacionais e penalidades de desempenho.

• Para a Rede: Descentralização e Sustentabilidade: O mecanismo RGP ajuda a garantir a saúde de longo prazo da rede. A “ameaça de entrada” de novos validadores mais eficientes impede que os validadores existentes colaborem para manter preços altos. Além disso, ao ajustar suas cotações com base no preço de mercado do token SUI, os validadores asseguram coletivamente que suas operações permaneçam sustentáveis em termos reais, isolando a economia de taxas da rede da volatilidade do preço do token.

Governança e Evolução do Sistema: SIP‑45​

O mecanismo de gas da Sui não é estático e evolui por meio da governança. Um exemplo proeminente é o SIP‑45 (Submissão Prioritária de Transações), proposto para refinar a priorização baseada em taxas.

• Problema Abordado: Análises mostraram que simplesmente pagar um preço de gas alto nem sempre garante inclusão mais rápida da transação.
• Mudanças Propostas: A proposta incluiu aumentar o preço máximo de gas permitido e introduzir uma “difusão amplificada” para transações que pagam significativamente acima do RGP (por exemplo, ≥5× RGP), garantindo que sejam rapidamente disseminadas pela rede para inclusão prioritária.

Isso demonstra o compromisso de iterar o modelo de gas com base em dados empíricos para melhorar sua eficácia.

Comparação com Outros Modelos de Gas em Blockchains​

O modelo RGP da Sui é único, especialmente quando comparado ao EIP‑1559 da Ethereum.

Críticas Potenciais e Desafios​

Apesar de seu design inovador, o mecanismo RGP enfrenta desafios potenciais:

• Complexidade: O sistema de pesquisas, regras de contagem e cálculos off‑chain é intricado e pode representar uma curva de aprendizado para novos validadores.
• Reação Lenta a Picos: O RGP é fixo por época e não pode reagir a surtos repentinos de demanda no meio da época, o que pode gerar congestionamento temporário até que os usuários comecem a adicionar gorjetas.
• Potencial de Conluio: Em teoria, validadores poderiam coludir para definir um RGP alto. Esse risco é mitigado principalmente pela natureza competitiva do conjunto de validadores permissionless.
• Ausência de Queima de Taxas: Diferente da Ethereum, a Sui recicla todas as taxas de gas para validadores e o fundo de armazenamento. Isso recompensa os operadores da rede, mas não cria pressão deflacionária sobre o token SUI, recurso valorizado por alguns detentores.

Perguntas Frequentes (FAQ)​

Por que fazer staking de SUI? Staking de SUI assegura a rede e gera recompensas. Inicialmente, essas recompensas são fortemente subsidiadas pela Sui Foundation para compensar a baixa atividade da rede. Esses subsídios diminuem 10 % a cada 90 dias, com a expectativa de que as recompensas provenientes de taxas de transação cresçam e se tornem a principal fonte de rendimento. SUI em stake também concede direitos de voto na governança on‑chain.

Meu SUI em stake pode ser slashado? Sim. Enquanto os parâmetros ainda são finalizados, aplica‑se o “Slash de Regra de Contagem”. Um validador que receba pontuação de desempenho zero de 2/3 de seus pares (por baixo desempenho, comportamento malicioso, etc.) terá suas recompensas slashadas por um valor a ser determinado. Stakers também podem perder recompensas se seu validador escolhido apresentar downtime ou cotar um RGP subótimo.

As recompensas de staking são compostas automaticamente? Sim, as recompensas de staking na Sui são distribuídas e re‑stakadas (compostas) automaticamente a cada época. Para acessar as recompensas, é necessário fazer o unstake explicitamente.

Qual é o período de desbloqueio (unbonding) do SUI? Inicialmente, stakers podem desbloquear seus tokens imediatamente. Espera‑se a implementação de um período de desbloqueio, onde os tokens ficam bloqueados por um tempo definido após o unstake, sujeito à governança.

Mantenho a custódia dos meus tokens SUI ao fazer staking? Sim. Ao fazer staking de SUI, você delega seu stake, mas continua com controle total sobre seus tokens. Você nunca transfere a custódia para o validador.

Como eliminar o atrito da carteira, manter os usuários fluindo e prever o potencial de crescimento

E se seu aplicativo Web3 tivesse o mesmo fluxo de cadastro perfeito de um serviço Web2 moderno? Essa é a promessa central do zkLogin na blockchain Sui. Ele funciona como OAuth para Sui, permitindo que os usuários façam login com contas familiares do Google, Apple, X e outras. Uma prova de conhecimento zero então vincula de forma segura essa identidade Web2 a um endereço Sui on‑chain — sem pop‑ups de carteira, sem frases‑semente, sem churn de usuários.

O impacto é real e imediato. Com centenas de milhares de contas zkLogin já ativas, estudos de caso relatam ganhos massivos na conversão de usuários, saltando de um desanimador 17 % para um saudável 42 % após remover as barreiras tradicionais de carteira. Vamos detalhar como funciona e o que pode fazer pelo seu projeto.

Por que as Carteiras Matam a Conversão na Primeira Visita​

Você construiu um dApp inovador, mas seu funil de aquisição de usuários está vazando. O culpado quase sempre é o mesmo: o botão “Conectar Carteira”. O onboarding padrão Web3 é um labirinto de instalações de extensões, avisos de frase‑semente e quizzes de jargões cripto.

É uma barreira enorme para iniciantes. Pesquisadores de UX observaram um abandono impressionante de 87 % no momento em que o prompt de carteira aparece. Em um experimento revelador, simplesmente redirecionar esse prompt para uma fase posterior do checkout elevou a taxa de conclusão para 94 %. Mesmo para usuários curiosos sobre cripto, o medo principal é: “Posso perder meus fundos se clicar no botão errado.” Remover esse único passo intimidador é a chave para desbloquear um crescimento exponencial.

Como o zkLogin Funciona (em Português Simples)​

zkLogin contorna elegantemente o problema da carteira usando tecnologias que todo usuário de internet já confia. A mágica acontece nos bastidores em alguns passos rápidos:

1. Par de Chaves Efêmero: Quando o usuário quer fazer login, um par de chaves temporário, de sessão única, é gerado localmente no navegador. Pense nisso como uma chave‑passe temporária, válida apenas para esta sessão.
2. Dança OAuth: O usuário faz login com sua conta Google, Apple ou outra rede social. Seu app insere de forma inteligente um valor único (nonce) nessa solicitação de login.
3. Serviço ZKP: Após o login bem‑sucedido, um serviço de ZKP (Zero‑Knowledge Proof) gera uma prova criptográfica. Essa prova confirma, “Este token OAuth autoriza o proprietário da chave‑passe temporária,” sem jamais revelar a identidade pessoal do usuário on‑chain.
4. Derivar Endereço: O JWT (JSON Web Token) do provedor OAuth é combinado com um salt único para gerar determinísticamente o endereço Sui permanente do usuário. O salt permanece privado, seja no cliente ou em um backend seguro.
5. Submeter Transação: Seu app assina transações com a chave temporária e anexa a prova ZK. Os validadores Sui verificam a prova on‑chain, confirmando a legitimidade da transação sem que o usuário precise de uma carteira tradicional.

Guia de Integração Passo a Passo​

Pronto para implementar? Aqui está um guia rápido usando o SDK TypeScript. Os princípios são idênticos para Rust ou Python.

1. Instalar SDK​

O pacote @mysten/sui inclui todos os helpers zklogin que você precisará.

pnpm add @mysten/sui

2. Gerar Chaves & Nonce​

Primeiro, crie um par de chaves efêmero e um nonce ligado ao epoch atual na rede Sui.

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

3. Redirecionar para OAuth​

Construa a URL de login OAuth apropriada para o provedor que você está usando (por exemplo, Google, Facebook, Apple) e redirecione o usuário.

4. Decodificar JWT & Buscar Salt do Usuário​

Depois que o usuário fizer login e for redirecionado de volta, capture o id_token da URL. Use‑o para buscar o salt específico do usuário no seu backend e, então, derive o endereço 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. Solicitar Prova ZK​

Envie o JWT para um serviço provedor e obtenha a prova ZK. Para desenvolvimento, você pode usar o provedor público da Mysten. Em produção, hospede seu próprio provedor ou use um serviço como Enoki.

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

6. Assinar & Enviar​

Agora, construa sua transação, defina o remetente como o endereço zkLogin do usuário e execute‑a. O SDK cuida de anexar automaticamente os zkLoginInputs (a prova). ✨

const tx = new TransactionBlock();
tx.moveCall({ target: "0x2::example::touch_grass" }); // Qualquer chamada Move
tx.setSender(address);
tx.setGasBudget(5_000_000);

await suiClient.signAndExecuteTransactionBlock({
  transactionBlock: tx,
  zkLoginInputs: proof, // A mágica acontece aqui
});

7. Persistir Sessão​

Para uma experiência de usuário ainda mais fluida, criptografe e armazene o par de chaves e o salt no IndexedDB ou local storage. Lembre‑se de rotacioná‑los a cada alguns epochs para melhorar a segurança.

Modelo de Projeção de KPIs​

A diferença que o zkLogin traz não é apenas qualitativa; é quantificável. Compare um funil de onboarding típico com um alimentado por zkLogin:

👉 O que isso significa: Para uma campanha que gera 10 000 visitantes únicos, isso equivale a 300 ações on‑chain no primeiro dia versus mais de 2 500.

Boas Práticas & Armadilhas​

Para criar uma experiência ainda mais fluida, tenha estas dicas em mente:

• Use Transações Patrocinadas: Pague as taxas das primeiras transações dos seus usuários. Isso elimina todo o atrito e entrega um momento “aha” incrível.
• Manuseie os Salts com Cuidado: Alterar o salt de um usuário gera um novo endereço. Só faça isso se você controlar um caminho de recuperação confiável.
• Exponha o Endereço Sui: Após o cadastro, mostre aos usuários seu endereço on‑chain. Isso capacita usuários avançados a importá‑lo para uma carteira tradicional, se desejarem.
• Previna Loops de Atualização: Cache o JWT e o par de chaves efêmero até que expirem, evitando solicitar login repetidamente.
• Monitore a Latência do Provedor: Fique de olho no tempo de ida‑e‑volta da geração da prova. Se ultrapassar 2 segundos, considere hospedar um provedor regional para manter a experiência ágil.

Onde a BlockEden.xyz Agrega Valor​

Enquanto o zkLogin aperfeiçoa o fluxo voltado ao usuário, escalar isso traz novos desafios de backend. É aí que a BlockEden.xyz entra.

• Camada API: Nossos nós RPC de alta taxa de transferência, roteados geograficamente, garantem que suas transações zkLogin sejam processadas com latência mínima, independentemente da localização do usuário.
• Observabilidade: Dashboards prontos para uso que monitoram métricas chave como latência de prova, razões de sucesso/falha e a saúde do seu funil de conversão.
• Conformidade: Para apps que fazem ponte para fiat, nosso módulo opcional de KYC oferece um on‑ramp compliance direto a partir da identidade verificada do usuário.

Pronto para Lançar?​

A era dos fluxos de carteira engessados e intimidador acabou. Crie um sandbox zkLogin, conecte‑se ao endpoint de full‑node da BlockEden e veja seu gráfico de cadastros subir — enquanto seus usuários nunca precisam ouvir a palavra “carteira”. 😉

1. Liquidez e Crescimento do DeFi da Sui​

Figura: TVL do DeFi da Sui (linha azul) e volume da DEX (barras verdes) cresceram dramaticamente até o Q2 de 2025.

Surto de Valor Total Bloqueado (TVL): A liquidez DeFi da rede Sui cresceu explosivamente ao longo do último ano. De aproximadamente $600 M de TVL no final de 2024, o TVL da Sui disparou para mais de $2 bi até meados de 2025. Na verdade, a Sui atingiu o pico de cerca de $2,55 bi de TVL em 21 de maio de 2025 e manteve‑se bem acima de $2 bi durante grande parte do Q2. Esse aumento de mais de 300 % (um crescimento de 480 % ano‑sobre‑ano desde maio de 2023) posiciona a Sui firmemente entre as top 10 blockchains por TVL DeFi, superando o crescimento de redes como Solana. Os principais catalisadores incluíram adoção institucional e a integração do suporte ao stablecoin USDC nativo, que juntos atraíram grandes fluxos de capital. Notavelmente, os volumes mensais de negociação DEX da Sui subiram para o topo de todas as cadeias – ultrapassando $7–8 bi por mês até meados de 2025 (classificando‑se em 8.º lugar no setor). A liquidez de stablecoins circulante na Sui ultrapassou $1 bi em meados de 2025, após crescer 180 % desde o início do ano, indicando um aprofundamento da liquidez on‑chain. Capital cross‑chain também está fluindo; cerca de $2,7 bi de ativos foram ponteados para o ecossistema Sui, incluindo liquidez de Bitcoin (detalhes abaixo). Essa tendência de crescimento rápido sublinha um ano de entradas líquidas e expansão de usuários para o DeFi da Sui.

Principais DEXs e Provedores de Liquidez: As exchanges descentralizadas são a espinha dorsal da liquidez DeFi da Sui. O protocolo Cetus – um market maker automatizado (AMM) e agregador – tem sido a DEX‑estrela, oferecendo swaps de stablecoins e pools de liquidez concentrada. O Cetus lidera consistentemente em volume (facilitando mais de $12,8 bi em negociações apenas no Q2 2025) enquanto mantém cerca de $80 M de TVL. Outro player chave é o Bluefin, uma DEX multifacetada que opera tanto um AMM spot quanto uma exchange de futuros perpétuos. O Bluefin expandiu suas ofertas em 2025 com recursos inovadores: lançou o BluefinX, o primeiro sistema RFQ (request‑for‑quote) da Sui para melhorar a execução de preços, e integrou otimizações de trading de alta frequência para reduzir a diferença entre desempenho de DEX e CEX. Até o Q2, o AMM do Bluefin detinha cerca de $91 M de TVL e registrou mais de $7,1 bi em volume spot trimestral. Momentum é outra DEX em ascensão – lançou um market maker de liquidez concentrada (CLMM) que rapidamente acumulou $107 M em liquidez, oferecendo um novo primitivo de exchange. O Bucket Protocol introduziu o BUCK, stablecoin over‑collateralizada semelhante ao DAI, mas para Sui. O Bucket mantém o peg a USD por meio de módulos de estabilidade on‑chain. O Bucket também oferece pools de liquidez para tokens como BTC, ETH e SUI. A Bucket tem TVL de aproximadamente $69 M, principalmente sustentando o BUCK. A Momentum também oferece opções de yield trading e recompensas de pontos, combinando gamificação com farming.

Abstração de Conta: A Sui implementou abstração de conta que permite que carteiras de camada‑2 e contratos inteligentes gerenciem a autenticação do usuário, reduzindo a necessidade de interações on‑chain complexas. Essa camada de usabilidade simplifica a experiência do usuário, permitindo login via wallets sociais, autenticação biométrica e até login via e‑mail, tudo sem expor chaves privadas.

Abstração de Conta: A Sui introduziu recursos de abstração de conta que permitem que carteiras de camada‑2 e contratos inteligentes gerenciem a autenticação do usuário, reduzindo a necessidade de interações on‑chain complexas. Essa camada de usabilidade simplifica a experiência do usuário, permitindo login via wallets sociais, autenticação biométrica e até login via e‑mail, tudo sem expor chaves privadas.

2. Abstração de Conta e Experiência do Usuário​

Recursos de Abstração de Conta: A Sui oferece login social, autenticação sem chave privada e RFQ (request‑for‑quote) integrado nas DEXs. Usuários podem conectar suas contas via Google, Apple ou Discord e negociar diretamente sem precisar assinar transações manualmente. Essa abordagem reduz drasticamente a fricção para novos usuários e abre caminho para adoção em massa.

Benefícios de Usabilidade: A abstração de conta elimina a necessidade de criar e gerenciar endereços de contrato complexos. Em vez disso, os usuários interagem com endereços de conta “smart” que podem ser atualizados, revogadas ou delegadas a serviços de custódia. Isso permite recuperação de conta, multisig e autorização baseada em tempo, tudo configurável via UI amigável.

2. Abstração de Conta e Experiência do Usuário​

Recursos de Abstração de Conta: A Sui oferece login social, autenticação sem chave privada e RFQ (request‑for‑quote) integrado nas DEXs. Usuários podem conectar suas contas via Google, Apple ou Discord e negociar diretamente sem precisar assinar transações manualmente. Essa abordagem reduz drasticamente a fricção para novos usuários e abre caminho para adoção em massa.

Benefícios de Usabilidade: A abstração de conta elimina a necessidade de criar e gerenciar endereços de contrato complexos. Em vez disso, os usuários interagem com endereços de conta “smart” que podem ser atualizados, revogados ou delegados a serviços de custódia. Isso permite recuperação de conta, multisig e autorização baseada em tempo, tudo configurável via UI amigável.

3. Próximas Primitivas e Inovações​

Stablecoins Nativas: Em 2024, a Agora Finance lançou o AUSD, o primeiro stablecoin 100 % lastreado em USD nativo da Sui. Até o Q2 2025, o supply de BUCK (stablecoin over‑collateralizada) atingiu $60–66 M, tornando‑se um dos maiores stablecoins nativos da Sui. A Ondo Finance introduziu o USDY, um stablecoin “yield‑bearing” que tokeniza rendimentos de títulos do Tesouro dos EUA.

Integração Bitcoin (BTCfi): Em 2025, a Sui incorporou tBTC da Threshold Network e sBTC da Stacks, trazendo mais de $500 M de liquidez Bitcoin para o ecossistema. Mais de 10 % do TVL da Sui passou a ser composto por ativos derivados de BTC, permitindo que holders de Bitcoin usem seus ativos como colateral em plataformas de empréstimo como a Suilend, que detinha $102 M em ativos baseados em Bitcoin até o Q2.

Primitivas Avançadas de DEX: Protocolos como Magma (ALMM) e Momentum (CLMM) continuam a melhorar a eficiência de capital. O Bluefin lançou estratégias de trading de alta frequência institucional, aproveitando a execução paralela da Sui para reduzir latência e melhorar throughput.

Novos Instrumentos Financeiros e Parcerias: O projeto Graviton, que levantou $50 M em Série A, está construindo uma plataforma modular de trading, lending e cross‑margining na Sui, comparável ao dYdX. Parcerias como xMoney/xPortal para lançar um MasterCard cripto‑potenciado e o pedido da 21Shares por um ETF SUI nos EUA demonstram a convergência entre CeFi e DeFi.

Resumo: Em 2025, o ecossistema DeFi da Sui está florindo com inovação. A liquidez atingiu níveis de múltiplos bilhões de dólares, sustentada por DEXs e lenders de grande porte, e impulsionada por fluxos constantes de capital e crescimento de usuários. Por meio da abstração de conta e do design centrado no usuário, a Sui melhorou drasticamente a experiência DeFi, atraindo um público mais amplo. Com a próxima onda de primitivas – stablecoins nativas, integração de Bitcoin, AMMs avançados, perps e tokens lastreados em ativos reais – a Sui está expandindo os limites do que é possível nas finanças descentralizadas, consolidando‑se como um hub DeFi líder até 2025, caracterizado por profunda liquidez, usabilidade fluida e inovação incessante em primitivas financeiras.

Fontes:

• Sui Foundation – Sui Q2 2025 DeFi Roundup (15 de julho de 2025)
• Sui Foundation – NEAR Intents Brings Lightning‑Fast Cross‑chain Swaps to Sui (17 de julho de 2025)
• Sui Foundation – Sui to Support sBTC and Stacks (BTCfi Use Cases) (1 de maio de 2025)
• Sui Foundation – All About Account Abstraction (4 de outubro de 2023)
• Ainvest News – Sui Network TVL Surpasses $1.4B Driven by DeFi Protocols (14 de julho de 2025)
• Ainvest News – Sui DeFi TVL Surges 480% to $1.8B... (12 de julho de 2025)
• Suipiens (comunidade Sui) – tBTC Integration Brings Bitcoin Liquidity to Sui (17 de julho de 2025)
• Suipiens – Inside Suilend: Sui’s Leading Lending Platform (3 de julho de 2025)
• The Defiant – Ondo to Bring RWA‑Backed Stablecoins onto Sui (7 de fevereiro de 2024)
• Documentação Oficial da Sui – Intro to Sui: User Experience (recursos de abstração de conta)

Visão Geral​

Aptos e Sui se apresentam como a próxima geração de blockchains Layer-1, ambas originárias da linguagem Move inicialmente concebida pelo projeto Libra/Diem da Meta. Embora compartilhem uma linhagem comum, seus históricos de equipe, objetivos centrais, estratégias de ecossistema e caminhos evolutivos divergiram significativamente.

Aptos enfatiza versatilidade e desempenho de nível empresarial, visando tanto casos de uso DeFi quanto institucionais. Em contraste, Sui está focada em otimizar seu modelo de objeto único para impulsionar aplicações de consumo em massa, particularmente em jogos, NFTs e redes sociais. Qual cadeia se distinguirá finalmente dependerá de sua capacidade de evoluir a tecnologia para atender às demandas de seu nicho de mercado escolhido, ao mesmo tempo em que estabelece uma vantagem clara em experiência do usuário e facilidade para desenvolvedores.

1. Jornada de Desenvolvimento​

Aptos​

Nascida da Aptos Labs — uma equipe formada por ex‑funcionários da Meta Libra/Diem — Aptos iniciou testes fechados no final de 2021 e lançou sua mainnet em 19 de outubro de 2022. O desempenho inicial da mainnet gerou ceticismo na comunidade, com menos de 20 TPS, conforme notado pela WIRED, mas iterações subsequentes nas camadas de consenso e execução elevaram gradualmente seu throughput para dezenas de milhares de TPS.

Até o segundo trimestre de 2025, Aptos atingiu um pico de 44,7 milhões de transações em uma única semana, com endereços ativos semanais ultrapassando 4 milhões. A rede cresceu para mais de 83 milhões de contas cumulativas, com volume diário de negociação DeFi consistentemente acima de US$ 200 milhões (Fonte: Aptos Forum).

Sui​

Iniciada pela Mysten Labs, cujos fundadores eram membros centrais da equipe da carteira Novi da Meta, Sui lançou sua testnet incentivada em agosto de 2022 e entrou em operação na mainnet em 3 de maio de 2023. Desde as primeiras testnets, a equipe priorizou o refinamento de seu “modelo de objeto”, que trata ativos como objetos com propriedade e controles de acesso específicos para melhorar o processamento paralelo de transações (Fonte: Ledger).

Em meados de julho de 2025, o Total Value Locked (TVL) do ecossistema Sui alcançou US$ 2,326 bilhões. A plataforma viu crescimento rápido no volume mensal de transações e no número de engenheiros ativos, mostrando especial popularidade nos setores de jogos e NFTs (Fonte: AInvest, Tangem).

2. Comparação de Arquitetura Técnica​

3. Ecossistema On‑Chain e Casos de Uso​

3.1 Escala e Crescimento do Ecossistema​

Aptos No primeiro trimestre de 2025, Aptos registrou quase 15 milhões de usuários ativos mensais e aproximou‑se de 1 milhão de carteiras ativas diárias. Seu volume de negociação DeFi disparou 1000 % ano a ano, consolidando‑se como um hub para stablecoins e derivativos de grau financeiro (Fonte: Coinspeaker). Movimentos estratégicos incluem a integração do USDT via Upbit para impulsionar penetração nos mercados asiáticos e a atração de diversas DEXs, protocolos de empréstimo e plataformas de derivativos (Fonte: Aptos Forum).

Sui Em junho de 2025, o TVL do ecossistema Sui atingiu um novo recorde de US$ 2,326 bilhões, impulsionado principalmente por projetos sociais, de jogos e NFTs de alta interação (Fonte: AInvest). O ecossistema é definido por projetos centrais como marketplaces de objetos, pontes Layer‑2, carteiras sociais e SDKs de motores de jogo, que atraíram um grande número de desenvolvedores Web3 de jogos e detentores de IP.

3.2 Casos de Uso Dominantes​

• DeFi & Integração Empresarial (Aptos): Com sua finalização BFT madura e um conjunto rico de ferramentas financeiras, Aptos está mais bem posicionada para stablecoins, empréstimos e derivativos — cenários que exigem altos níveis de consistência e segurança.
• Jogos & NFTs (Sui): A vantagem de execução paralela da Sui é clara aqui. Sua latência baixa e taxas quase nulas são ideais para interações de alta concorrência e baixo valor típicas de jogos, como abertura de loot boxes ou transferência de itens in‑game.

4. Evolução & Estratégia​

Aptos

• Otimização de Performance: Continuação da pesquisa em sharding, planejamento de liquidez cross‑chain multirregional e atualização do AptosVM para melhorar a eficiência de acesso ao estado.
• Incentivos ao Ecossistema: Um fundo de centenas de milhões de dólares foi criado para apoiar infraestrutura DeFi, pontes cross‑chain e aplicações empresariais em conformidade.
• Interoperabilidade Cross‑Chain: Fortalecimento de integrações com pontes como Wormhole e construção de conexões com Cosmos (via IBC) e Ethereum.

Sui

• Iteração do Modelo de Objeto: Expansão da sintaxe Move para suportar tipos de objeto customizados e gerenciamento complexo de permissões, ao mesmo tempo otimizando o algoritmo de agendamento paralelo.
• Impulsionar Adoção de Consumidores: Busca de integrações profundas com motores de jogo como Unreal e Unity para reduzir barreiras ao desenvolvimento de jogos Web3, além do lançamento de plugins sociais e SDKs.
• Governança Comunitária: Promoção do SuiDAO para capacitar comunidades de projetos centrais com capacidades de governança, permitindo iteração rápida em recursos e modelos de taxas.

5. Diferenças Principais & Desafios​

• Segurança vs. Paralelismo: A semântica estrita de recursos e o consenso consistente da Aptos oferecem segurança de nível DeFi, mas podem limitar o paralelismo. O modelo altamente paralelo da Sui precisa provar continuamente sua resiliência contra ameaças de segurança em larga escala.
• Profundidade vs. Amplitude do Ecossistema: Aptos cultivou raízes profundas no setor financeiro com fortes laços institucionais. Sui acumulou rapidamente uma gama ampla de projetos voltados ao consumidor, mas ainda não alcançou um breakthrough decisivo em DeFi de grande escala.
• Desempenho Teórico vs. Throughput Real: Embora a Sui tenha TPS teórico maior, seu throughput real ainda é limitado pela atividade do ecossistema. Aptos também experimentou congestionamento em períodos de pico, indicando necessidade de sharding mais eficaz ou soluções Layer‑2.
• Narrativa de Mercado & Posicionamento: Aptos se promove como segurança e estabilidade de grau empresarial, mirando finanças tradicionais e indústrias reguladas. Sui utiliza o apelo de uma “experiência semelhante ao Web2” e “onboarding sem atrito” para atrair um público consumidor mais amplo.

6. O Caminho para a Adoção em Massa​

Em última análise, não se trata de um jogo de soma zero.

No médio a longo prazo, se o mercado consumidor (jogos, social, NFTs) continuar seu crescimento explosivo, a execução paralela da Sui e a baixa barreira de entrada podem posicioná‑la para adoção rápida entre dezenas de milhões de usuários mainstream.

No curto a médio prazo, a finalização BFT madura da Aptos, suas taxas baixas e parcerias estratégicas oferecem uma proposta mais atraente para finanças institucionais, DeFi focado em compliance e pagamentos transfronteiriços.

O futuro tende a ser simbiótico, com as duas cadeias coexistindo e criando um mercado estratificado: Aptos alimentando infraestrutura financeira e empresarial, enquanto Sui domina interações de alta frequência voltadas ao consumidor. A cadeia que alcançar a adoção em massa será aquela que otimizar incansavelmente desempenho e experiência do usuário dentro de seu domínio escolhido.