Ethereum com Symbiotic¶

Introdução¶

O protocolo Tanssi cuida de componentes críticos de infraestrutura, facilitando que desenvolvedores lancem suas redes em poucos minutos. Além da produção de blocos, recuperabilidade de dados e integrações com ferramentas essenciais como carteiras, endpoints RPC, exploradores de blocos e outras, outro grande desafio é fornecer segurança para a rede.

O Tanssi foi criado para oferecer aos desenvolvedores um Template de segurança compartilhada, evitando que eles tenham de buscar segurança econômica suficiente ou negociar com operators para rodar nós que façam opt-in para suas redes. Ao implantar redes por meio da Tanssi e escolher o Symbiotic como provedor de segurança, os desenvolvedores se beneficiam de segurança em nível de Ethereum, aproveitando bilhões de dólares em segurança compartilhada de ETH em stake.

As seções a seguir descrevem como funciona o protocolo Symbiotic e como as redes Tanssi podem aproveitá-lo como mecanismo de consenso.

Segurança em Nível de Ethereum com Symbiotic¶

O Symbiotic é um protocolo de segurança compartilhada projetado para ser permissionless, multi-ativo e agnóstico à rede. Ele promove eficiência de capital ao permitir que usuários estendam a funcionalidade de seus ativos em stake para proteger outras redes, oferecendo utilidade adicional.

O protocolo fornece uma camada de coordenação para seus principais componentes e participantes, alinhando incentivos entre as partes enquanto minimiza riscos na camada de execução ao implantar contratos centrais não atualizáveis no Ethereum. O diagrama a seguir resume todos os componentes e atores que participam do protocolo:

flowchart TD
    %% Vaults subgraph
    subgraph Ethereum["Ethereum/Symbiotic"]
        slash[/Eventos de Slashing/]
        Restakers -- Depositar Ativos --> Vaults
        manager["Gerentes de Vaults"] -- Administram --> Vaults
        Resolvers -- Decidem Sobre --> slash
        slash -- Executa Em --> Vaults
    end

    %% Operators subgraph
    subgraph Operators
        direction BT
        operators["Operators (Validadores)"]
        node_operators["Operators de Nós"]
        node_operators -- Operam --> operators
    end

    %% Networks subgraph
    subgraph Networks
        direction BT
        developers["Desenvolvedores"]
        networks["Redes Descentralizadas"]
        developers -- Lançam --> networks
    end

    Vaults <--> Tanssi
    Tanssi <--> Operators
    Tanssi <--> Networks

O design flexível do Symbiotic permite que cada parte decida configurações que melhor atendam seus casos de uso. Por exemplo, os vaults podem escolher quais tipos de colateral aceitam, os operators podem determinar para quais redes querem prestar serviços e as redes descentralizadas podem personalizar seu caso de uso e definir o nível de segurança (quais colaterais são aceitos, por exemplo) de que precisam.

As seções a seguir descrevem os principais componentes do protocolo.

Vaults¶

Os Vaults são o alicerce econômico do protocolo Symbiotic. Eles gerenciam liquidez e depósitos de restakers, conectam operators e redes e definem estratégias de delegação.

Cada vault está vinculado a um token específico que atende à interface ERC20 e é aceito como colateral. Internamente, os fundos dentro do vault são representados como shares, o que fornece um mecanismo para rastrear propriedade e distribuir recompensas. No entanto, o token de recompensa pode ser diferente do token de colateral.

Um vault é composto por três módulos principais, cada um com uma função distinta: o slasher, o delegator e o módulo de contabilidade. A implementação desses módulos pode variar dependendo das decisões do gerente do vault.

Módulo Slasher - implementa a lógica de slashing, que penaliza maus atores
Módulo Delegator - define como os fundos são delegados entre operators e redes. Diversas estratégias estão disponíveis, permitindo ao gerente do vault selecionar quais operators e redes deseja atender
Módulo de Contabilidade - lida com as operações financeiras do vault, incluindo processar depósitos de usuários, gerenciar pedidos de saque, rastrear saldos ativos e oferta total, e implementar contabilidade baseada em épocas para saques e eventos de slashing. A implementação padrão do módulo de contabilidade é o ERC-4626, que oferece um sistema de shares embutido

Como os operators recebem stake delegado do vault e podem ser alvo de slashing, eles devem ser aprovados previamente pelos gerentes de vault. Da mesma forma, os gerentes de vault analisam e autorizam cada rede que o vault protegerá, considerando, por exemplo, as recompensas que a rede oferece.

Os gerentes de vault também designam resolvers, responsáveis por aprovar ou vetar eventos de slashing causados por operators em redes com suporte a veto-slashing, como a Tanssi Network.

Operators¶

Os node operators são entidades ou indivíduos responsáveis por executar os nós (também conhecidos como operators ou validadores), que são os componentes computacionais que validam as transações das redes. Eles são responsáveis pela configuração dos nós, setup de hardware, disponibilidade e desempenho.

Os node operators fazem opt-in para prestar serviços a redes, que precisam aceitar sua solicitação. Eles também fazem opt-in para prestar serviços em vaults, que igualmente precisam aceitar seu pedido.

Depois que um operator é aceito por um vault e por uma rede conectada a esse vault, o nó pode começar a fornecer serviços de validação para essa rede, recebendo recompensas em troca.

Redes¶

As Redes são os serviços ou redes ativamente validados. Essas blockchains específicas de aplicação podem ser de uma ampla gama de setores, como Gaming, DeFi, RWAs e outros, e são as plataformas com as quais, por meio de dApps, os usuários finais interagem.

Como os operators fazem opt-in para prestar serviços às redes e os gerentes de vault precisam aceitar as redes, os desenvolvedores são responsáveis por definir, controlar e adaptar sua metodologia para onboarding, recompensa e slashing de operators.

Note

As redes implantadas por meio da Tanssi não precisam trabalhar o relacionamento com vaults e operators, pois o protocolo Tanssi lida com essas complexidades.

Tanssi com Symbiotic¶

Desenvolvedores que lançam redes por meio da Tanssi se beneficiam dos serviços de produção de blocos, recuperabilidade de dados como serviço e do Template de segurança compartilhada derivado de todos os vaults que fazem opt-in para suportar o protocolo Tanssi. Isso elimina o obstáculo de lidar com componentes de infraestrutura e segurança que, de outra forma, os desenvolvedores precisariam assumir.

Gerentes de vaults podem se candidatar a oferecer os colaterais em restaking como segurança econômica para a Tanssi Network. Como as redes Tanssi rodam em um ambiente semelhante a um sandbox, e o protocolo Tanssi gerencia todas as responsabilidades relacionadas às redes, os gerentes de vaults só precisam analisar e fazer opt-in para o protocolo Tanssi, independentemente da qualidade e quantidade de redes que estejam rodando pelo protocolo Tanssi em qualquer momento.

Operators que fazem opt-in para prestar serviços ao protocolo Tanssi (desde que participem de um vault que suporta o protocolo Tanssi) têm a vantagem de rodar o mesmo setup para fornecer serviços de produção de blocos e validação para a Tanssi Network e, consequentemente, para todas as redes implantadas via Tanssi. Essa arquitetura única facilita todas as tarefas relacionadas a executar e manter os operators, já que não há mudanças no setup quando uma nova rede Tanssi é lançada ou desativada.

Note

O protocolo Tanssi efetivamente abstrai os detalhes do conjunto ativo de redes para longe dos gerentes de vaults e operators. Particularidades das redes não exigem qualquer configuração adicional dos operators nem representam riscos aos ativos do vault.

Tudo isso forma um ecossistema funcional e elegante no qual os desenvolvedores podem se concentrar em criar e inovar. O Tanssi cuida dos componentes de infraestrutura, garantindo disponibilidade e desempenho, e o Symbiotic fornece os mecanismos econômicos que asseguram a validade das operações.

flowchart LR
    subgraph Symbiotic
        direction LR
        Operators
        Vaults
    end
    Symbiotic  -- Valida/Protege --> tanssi["Tanssi Network"]
    tanssi -- Serviços de Produção de Blocos--> Networks
    tanssi -- Segurança--> Networks
    tanssi -- Recuperação de Dados--> Networks

    class Symbiotic custom-container

Comunicação Tanssi-Ethereum¶

É importante entender como Tanssi e Ethereum trocam dados para compreender a mecânica do protocolo. Eles se conectam por meio de uma bridge bidirecional que permite que se comuniquem entre si. Cada protocolo tem um papel específico para viabilizar operações cross-chain.

Existem três componentes-chave entre Symbiotic e Tanssi:

flowchart LR

Tanssi["Tanssi"] <--> Relayer 
Relayer <--> Gateway 
Gateway["Gateway"] <--> Middleware
Middleware <--> Symbiotic["Symbiotic"]

class Tanssi tanssiNode;

class Middleware middlewareNode;

class Gateway gatewayNode;

class Symbiotic symbioticNode;

class Relayer relayerNode;

Relayer - é o software que monitora continuamente ambas as blockchains e transmite mensagens. Ele habilita comunicação bidirecional confiável entre Tanssi e Ethereum, servindo como a camada de conexão que garante que mensagens sejam entregues corretamente entre as redes
Gateway - opera no lado Ethereum da bridge e cumpre três funções essenciais. Ele recebe, verifica e encaminha mensagens recebidas da Tanssi para garantir que sejam processadas corretamente. O contrato aceita mensagens de saída destinadas à rede Tanssi, preparando-as para o relay. Por fim, lida com funcionalidades de aplicação de nível superior, principalmente transferências de tokens entre as duas redes, fornecendo uma interface segura para movimentação de ativos entre cadeias
Middleware - é a implementação da Tanssi para lidar com eventos e operações da rede. Ele é o elo crítico entre o Gateway e o protocolo central da Tanssi

O Middleware desempenha um papel central na coordenação da rede entre Tanssi e Symbiotic. Ele distribui recompensas a operators e vaults com base em suas contribuições para segurança e desempenho da rede. O contrato ordena os operators por stake para criar um sistema de ranking meritocrático para sua seleção e transmite a lista de chaves de operators ordenadas à Tanssi para atribuição. Além disso, facilita os processos de registro de operators e gerencia os protocolos de recompensa e slashing que mantêm o alinhamento de incentivos da rede.

De Ethereum para Tanssi¶

O Middleware transmite informações sobre o conjunto de operators para a Tanssi para atribuição de sessões por meio da bridge. Ele envia detalhes sobre operators ativos para cada época, ordenando-os por seu stake total agregado em todos os vaults. O Tanssi então usa essas informações para atribuir operators para as próximas sessões, garantindo que os mais alinhados economicamente protejam a rede. Esse mecanismo cria um processo de seleção de operators ponderado por stake, em que a segurança econômica no Ethereum se traduz em segurança operacional na Tanssi.

De Tanssi para Ethereum¶

O Tanssi envia dados operacionais de volta ao Ethereum através do mesmo canal de comunicação. Essa mensagem inclui informações de recompensa que permitem a distribuição adequada aos stakeholders com base no desempenho da rede. A rede também transmite dados de eventos de slashing quando os operators falham em desempenhar corretamente ou violam regras do protocolo, permitindo que o protocolo aplique penalidades. O Tanssi também pode solicitar a criação de novos tokens no Ethereum e registrar tokens, facilitando o gerenciamento de ativos entre as duas redes.

Recompensas¶

Operators e restakers bem-comportados são recompensados por sua participação com tokens TANSSI. O processo de recompensa consiste em duas fases principais: Fase de Distribuição de Recompensas e Fase de Reivindicação de Recompensas.

Fase de Distribuição de Recompensas¶

A fase de distribuição de recompensas calcula e aloca recompensas por meio de cinco etapas principais que envolvem operators, restakers e contratos inteligentes. As etapas são:

Cálculo de Recompensas - o Tanssi calcula recompensas com base na atividade de operators e stakers e então cria uma raiz de Merkle. Essa raiz de Merkle é uma impressão digital criptográfica que resume as alocações de recompensas, indicando quem recebe o quê. Stakers são recompensados de acordo com seu stake em cada vault
Dados de Recompensa Enviados via XCM - os dados de alocação de recompensas são enviados usando XCM (Cross-Consensus Messaging), um protocolo padronizado para comunicação entre blockchains. A Snowbridge atua como uma bridge sem confiança entre Tanssi e Ethereum
Recepção da Mensagem no Ethereum - uma vez que a mensagem é encaminhada para o contrato Gateway, esse contrato serve como ponto de entrada autorizado da Tanssi no Ethereum para a bridge Snowbridge
Processamento e Validação da Mensagem - o Gateway encaminha os dados para o Middleware, que é responsável por várias tarefas, incluindo passar as informações para o contrato OperatorReward
Armazenamento e Distribuição de Recompensas - este é o destino final dos dados. O contrato OperatorRewards armazena a árvore de Merkle das alocações de recompensa e lida com a transferência de tokens de recompensa quando um claim é feito

%%{init: {'sequence': {'mirrorActors': false}}}%%
sequenceDiagram
    participant Rede Tanssi
    participant Snowbridge (XCM)
    participant Gateway
    participant Middleware
    participant OperatorRewards

    Rede Tanssi->>Rede Tanssi: 1. Calcular recompensas e gerar raiz de Merkle
    Rede Tanssi->>Snowbridge (XCM): 2. Dados de recompensa enviados via XCM (raiz de Merkle + dados)
    Snowbridge (XCM)->>Gateway: 3. Repassar a mensagem e enviar ao Ethereum 
    Gateway ->>Middleware: 4. Processamento e validação da mensagem
    Middleware->>OperatorRewards: 5. Armazenamento e distribuição de recompensas

Fase de Reivindicação de Recompensas¶

Na fase de reivindicação de recompensas, operators e stakers podem reivindicar recompensas com base em sua participação na rede. O Tanssi determina a divisão para operators e stakers, atualmente fixada em 20% para operators e 80% para stakers.

Reivindicação de Recompensa pelo Operator - operators podem reivindicar sua parcela chamando o contrato OperatorRewards usando um recibo criptográfico que comprova seu direito
Liberação de Tokens - a chamada do operator aciona a liberação de tokens, e o OperatorRewards envia o valor estabelecido ao operator
Distribuição de Tokens aos Stakers - as recompensas restantes são encaminhadas ao contrato StakerRewards para posterior reivindicação dos stakers
Alocação dos Stakers - os 80% restantes das recompensas são direcionados automaticamente ao contrato StakerRewards, onde os stakers podem reivindicar recompensas proporcionais ao seu stake nos vaults

%%{init: {'sequence': {'mirrorActors': false}}}%%
sequenceDiagram
 participant Operator
 participant OperatorRewards
 participant StakerRewards
 participant Stakers

 Operator->>OperatorRewards: 1. Reivindicação de recompensa pelo operator
 OperatorRewards->>Operator: 2. Liberar recompensas para o operator
 OperatorRewards->>StakerRewards: 3. Encaminhar o restante para o StakerRewards
 Stakers->>StakerRewards: 4. Stakers reivindicam recompensas individuais

Slashing¶

O protocolo Tanssi implementa slashing para penalizar operators por mau comportamento. Quando um evento de slashing é acionado, as autoridades designadas como resolvers pelos gerentes de vault podem aceitar ou reverter essa ação.

As seguintes ações podem acionar eventos de slashing:

Produção de blocos inválidos (por exemplo, blocos que incluem transações inválidas)
Validação inválida (por exemplo, dupla assinatura ou quebra das regras do protocolo)
Tempo de inatividade ou indisponibilidade
Violações de consenso

Note

Eventos de slashing só podem ser acionados por mau comportamento dos operators dentro da Tanssi Network. Mesmo que redes Tanssi sejam defeituosas ou maliciosas, elas operam em um ambiente isolado e não podem causar slashing.

Processo de Slashing¶

O processo de slashing segue um caminho semelhante ao das recompensas. Quando um operator se comporta mal, a Tanssi Network envia uma mensagem de solicitação de slashing para a bridge sem confiança (Snowbridge). A mensagem passa pelo Gateway e chega ao Middleware, onde o método de slashing é chamado.

O método de slashing recebe um identificador exclusivo para a identidade do operator, a severidade do slash como uma porcentagem do stake do operator atribuído em cada vault e o contexto temporal em que a infração ocorreu.

O processo de slashing consiste nas seguintes etapas:

Slash Reportado - o Tanssi envia a solicitação de slashing ao Middleware com os parâmetros operatorKey, percentage e epoch
Validação do Operator - o Middleware valida a identidade do operator e verifica se ele está sujeito ao slashing
Recuperar Vaults Ativos - o Middleware percorre todos os vaults ativos durante a época da infração, ignorando qualquer vault inativo
Recuperar Stake do Operator - para cada vault ativo, o Middleware recupera o stake do operator infrator
Calcular Valor do Slash - o Middleware calcula o valor do slashing aplicando a porcentagem de corte ao stake do operator em cada vault
Slashing - dependendo da implementação de slashing do vault, existem duas rotas possíveis
- Slashing Instantâneo - se o vault usa slashing instantâneo, o stake é reduzido imediatamente
- Veto Slashing - se o vault usa veto slashing, o Middleware solicita o slashing a um resolver. Uma janela de veto com tempo limitado é criada (por exemplo, 7 dias)
O slashing é cancelado se o resolver vetar a solicitação dentro da janela de tempo. Caso contrário, a penalidade de slashing é executada se nenhum veto ocorrer dentro da janela.

Esse processo garante que o slashing de cada vault seja tratado de forma independente, evitando contaminação cruzada, e oferece slashing instantâneo e com atraso, com mecanismos de resolução de disputas.

%%{init: {'sequence': {'mirrorActors': false}}}%%
sequenceDiagram
    participant Network
    participant Middleware
    participant Vault
    participant Slasher

    Network->>Middleware: 1. Slash reportado
    Middleware->>Middleware: 2. Validação do operator
    loop Cada Vault Ativo
        Middleware->>Vault: 3. Recuperar stake do operator
        Vault-->>Middleware: 4. Recuperar stake do vault
        Middleware->>Middleware: 5. Calcular valor do slash
        alt Slasher Instantâneo
            Middleware->>Slasher: 6.1 Slash
        else Veto Slasher
            Middleware->>Slasher: 6.2 Solicitar slash
            opt Se Não Vetado
                Slasher->>Slasher: 6.2 Executar slash
            end
        end
    end

Burner¶

O contrato Burner é uma extensão responsável por lidar com ações que seguem um evento de slashing, especialmente a queima do colateral slashed. Uma vez que um slash é executado, o contrato Slasher chama o Burner para realizar essas tarefas pós-slashing.

Dentro do protocolo, o contrato Burner desempenha um papel crucial ao decidir o que acontece após o slashing. Embora existam diferentes maneiras de implementar o processo de queima, a abordagem recomendada é queimar os ativos slashed. Quando um slash é executado, a função onSlash do contrato Burner é ativada. Essa função dá início ao processo de queimar os ativos slashed.

O gerente do vault escolhe a implementação específica do processo de queima durante a fase de inicialização do vault e, uma vez definida, o gerente do vault não pode modificá-la. O design exato do contrato Burner pode variar dependendo do tipo de ativo colateral envolvido. Abaixo estão algumas opções de implementação em potencial:

Queima de Tokens - se o colateral slashed for um token ERC-20 comum, o Burner destrói esses tokens, removendo-os permanentemente de circulação
Desembrulhar e Queimar - se os tokens slashed representarem algo como ativos em stake (por exemplo, tokens de staking líquido) ou tokens de provedor de liquidez (LP) de uma DEX, o Burner pode convertê-los de volta à sua forma original antes de queimá-los
Operações entre Cadeias - se os tokens estiverem vinculados a ativos em outra blockchain, o Burner pode desembrulhá-los no Ethereum e acionar o processo de queima na rede original
Tratamento Alternativo - às vezes, queimar não é a melhor opção. Em vez disso, o Burner pode redistribuir os ativos slashed para outros operators, compensar usuários afetados ou bloqueá-los em pools de liquidez — conforme o sistema for projetado para fazer

Queimar o colateral slashed é importante porque penaliza operators que se comportam mal e reduz a oferta total de tokens, o que pode ter efeitos deflacionários.

Última atualização: 30 de dezembro de 2025
| Criada: 26 de novembro de 2025