::put(nonce.wrapping_add(1));
nonce.encode()
}
}
}
```
Para mais informações sobre o processo passo a passo de criação de um módulo feito sob medida para o Runtime, consulte [Adicionar um módulo personalizado](/pt/builders/build/customize/adding-custom-made-module/){target=\_blank} na secção de Builder.
--- END CONTENT ---
Doc-Content: https://docs.tanssi.network/pt/learn/framework/overview/
--- BEGIN CONTENT ---
---
title: Visão Geral da Estrutura de Desenvolvimento de Rede
description: Substrate é uma estrutura de desenvolvimento de blockchain construída na Linguagem de Programação Rust que agiliza e acelera o processo de desenvolvimento de novas redes.
icon: octicons-home-24
categories: Basics
---
# Visão Geral da Estrutura de Desenvolvimento de Rede {: #network-dev-framework-overview }
## Introdução {: #introduction }
A construção de uma rede do zero é uma tarefa muito complexa que exige profundo conhecimento em uma ampla gama de áreas, incluindo (mas não se limitando a):
- **Algoritmos de Consenso** - o consenso garante que todos os participantes da rede blockchain concordem com a validade das transações. Alguns mecanismos de consenso populares incluem Prova de Trabalho (PoW) e Prova de Participação (PoS)
- **Criptografia** - a criptografia desempenha um papel crucial na segurança da blockchain. Você precisará de algoritmos criptográficos para tarefas como criar assinaturas digitais, verificar transações e criptografar dados
- **Rede Distribuída** - uma arquitetura de rede para permitir que os nós se comuniquem, validem transações e sincronizem os dados da blockchain é fundamental para manter um livro-razão compartilhado em uma rede descentralizada
- **Estruturas de Dados** - além da lista de blocos, onde cada bloco contém um conjunto de transações junto com uma referência ao bloco anterior, é necessária uma estratégia otimizada e de alto desempenho para armazenar o estado da rede
- **Governança** - se a rede for projetada para ser sem permissão, um mecanismo de votação é importante para mantê-la evoluindo e refletindo a vontade da comunidade
- **Atualização** - é necessário definir claramente como atualizar, como as modificações são implementadas e como os conflitos são resolvidos dentro da rede
Felizmente, não há necessidade de construir esses componentes de blockchain do zero, graças a uma excelente estrutura de código aberto chamada [Substrate](https://docs.polkadot.com/develop/parachains/intro-polkadot-sdk/){target=\_blank}. A própria Tanssi é construída com essa estrutura, aproveitando suas implementações de base abrangentes, modularidade e flexibilidade para alcançar um alto nível de personalização.
## Estrutura Substrate {: #substrate-framework}
Substrate é uma estrutura extremamente performática, flexível, modular e altamente personalizável para construir blockchains. Essa estrutura é a base e o motor que impulsionam muitos projetos no ecossistema Web3, incluindo a própria rede Tanssi e as redes implantadas por meio da Tanssi.
Muitos de seus ótimos recursos, como desempenho, facilidade de uso e modularidade, resultam da linguagem de programação escolhida para seu desenvolvimento. É aqui que a [Linguagem de Programação Rust](#rust-programming-language) se destaca: ela é rápida, portátil e fornece um Template maravilhoso para lidar com a memória, entre outros motivos detalhados na [próxima seção](#rust-programming-language).
Ao desenvolver uma rede, Substrate representa uma grande vantagem ao fornecer um conjunto de implementações prontas para uso dos principais blocos de construção que um projeto precisa:
- **Algoritmos de Consenso** - existem vários mecanismos de consenso integrados, como Aura (Prova de Autoridade), Babe (Prova de Participação) e Grandpa (finalidade de bloco), mas devido ao alto grau de personalização que Substrate oferece, as equipes podem sempre optar por desenvolver seu consenso específico para se adaptar às necessidades do caso de uso, como a equipe Moonbeam fez com a [Estrutura de Consenso Nimbus Parachain](https://docs.moonbeam.network/learn/features/consensus){target=\_blank}
- **Módulos de Runtime** - muitos módulos integrados (explicados em detalhes na seção [modules](/pt/learn/framework/modules/){target=\_blank}) podem ser selecionados e configurados em sua rede, como contas, saldos, staking, governança, identidade e muito mais
- **Rede** - protocolos e bibliotecas integradas para estabelecer conexões, propagar transações e blocos, sincronizar o estado da blockchain e gerenciar interações de rede
- **Armazenamento** - mecanismos de armazenamento integrados para armazenamento e recuperação de dados eficientes
- **Fila de Transações** - sistema de fila de transações integrado que gerencia a validação, priorização e inclusão de transações em blocos, garantindo a consistência e integridade do estado da rede
- **APIs RPC** - Substrate fornece APIs de Chamada de Procedimento Remoto (RPC) que permitem que aplicativos externos interajam com a rede, consultando dados da blockchain, enviando transações e acessando várias funcionalidades expostas pelo Runtime
Cada recurso que o Substrate oferece pode ser usado como está, estendido, personalizado ou substituído para atender aos requisitos específicos do caso de uso da rede.
Substrate agiliza e acelera o processo de desenvolvimento de novas redes. Quando usado em conjunto com Tanssi, que ajuda a lidar com a infraestrutura e supervisionar a implantação, a tarefa de lançar uma nova rede se torna significativamente mais simples!
## Linguagem de Programação Rust {: #rust-programming-language}
[Rust](https://rust-lang.org/){target=\_blank} é uma linguagem de programação com recursos que os desenvolvedores classificam consistentemente em pesquisas como a [pesquisa anual de desenvolvedores do Stack Overflow](https://survey.stackoverflow.co/){target=\_blank}.
Além de fornecer uma ótima experiência para os desenvolvedores, o Rust se destaca em muitas áreas:
- **Segurança da memória** - O compilador Rust impõe verificações estritas em tempo de compilação para evitar erros de programação comuns, como desreferências de ponteiros nulos, estouros de buffer e condições de corrida de dados. Além disso, a memória é gerenciada por meio de um novo sistema de propriedade (verificado pelo compilador), que elimina a necessidade de um coletor de lixo
- **Desempenho** - Rust atinge um desempenho comparável ao de C e C++, fornecendo controle de baixo nível sobre os recursos do sistema e minimizando a sobrecarga de Runtime. Ele tem um princípio de abstração de custo zero, semelhante a "o que você não usa, você não paga" de C++, o que significa que as abstrações não têm sobrecarga extra
- **Concorrência** - Rust possui recursos integrados que facilitam a escrita de código concorrente e paralelo sem introduzir condições de corrida de dados. Ele fornece threads leves (tarefas) e um Template de propriedade poderoso que garante o compartilhamento seguro de dados entre threads
- **Abstrações expressivas e seguras** - Rust oferece um rico conjunto de recursos de linguagem modernos, como correspondência de padrões, tipos de dados algébricos, closures e inferência de tipos, permitindo que os desenvolvedores escrevam e leiam código expressivo e conciso. O compilador Rust impõe o forte sistema de tipos, evitando muitos erros em Runtime em tempo de compilação
- **Compatibilidade entre plataformas** - Rust foi projetado para funcionar bem em uma variedade de plataformas e arquiteturas. Ele suporta os principais sistemas operacionais como Windows, macOS e Linux, bem como sistemas embarcados e WebAssembly. Essa versatilidade permite que os desenvolvedores escrevam código que pode ser implantado em diferentes ambientes
- **Ecossistema em crescimento** - Rust tem um ecossistema em rápido crescimento com uma comunidade vibrante e uma rica coleção de bibliotecas e ferramentas. O gerenciador de pacotes oficial, Cargo, simplifica o gerenciamento de dependências, construção e teste
- **Interoperabilidade** - Rust fornece interoperabilidade perfeita com bases de código existentes escritas em C e C++. Ele tem uma Interface de Função Estrangeira (FFI) que permite que o código Rust se interface com o código escrito em outras linguagens, permitindo que os desenvolvedores introduzam gradualmente Rust em projetos existentes, como o kernel Linux
--- END CONTENT ---
Doc-Content: https://docs.tanssi.network/pt/learn/framework/xcm/
--- BEGIN CONTENT ---
---
title: Comunicação Nativa Cross-Chain
description: Tanssi networks benefit from XCM, a native cross-chain communication language, which allows fast and secure bridging guaranteed by Polkadot's relay chain.
categories: Basics
---
# Comunicação Nativa Cross-Chain
## Introdução {: #introduction }
Todas as redes Powered by Tanssi têm uma capacidade inerente de se comunicar e interagir com qualquer outra rede no ecossistema. Esse recurso de comunicação cross-chain nativo é possível graças à infraestrutura exclusiva sobre a qual as redes são construídas, alavancando o formato de Mensagem Cross-Consensus (XCM para abreviar), que facilita a comunicação entre diferentes sistemas de consenso.
XCM é uma linguagem de mensagens projetada para ser genérica. Ela não faz nenhuma suposição sobre a cadeia de destino e pode comunicar diferentes intenções entre sistemas de consenso soberanos.
A mensagem XCM é um programa que contém uma ou mais instruções que serão retransmitidas para execução na cadeia de destino. Por si só, cada instrução XCM é sem sentido, mas a combinação de um conjunto específico de instruções pode resultar em uma ação desejada quando a mensagem XCM é executada na cadeia de destino.
Neste artigo, abordamos os conceitos básicos do mecanismo de comunicação cross-chain nativo que permite pontes rápidas e seguras dentro do ecossistema.
## Princípios de Design {: #design-principles }
Concebido com uma mentalidade abstrata, o XCM não foi projetado para estar em conformidade com um caso de uso específico ou configuração de rede de destino específica, minimizando assim o efeito de acoplamento. Seus princípios básicos de design são:
- **Assíncrono** - semelhante ao envio de um cartão postal - mas muito mais rápido - o remetente continuará a realizar suas tarefas como de costume, sem se bloquear ou aguardar uma resposta do destino
- **Absoluto** - as mensagens têm garantia de serem entregues ao destino pretendido, em ordem e em tempo hábil
- **Assimétrico** - as mensagens enviadas não têm contrapartida de resposta. Quaisquer valores de retorno, se necessários, devem ser enviados de volta do destino para o remetente com outra mensagem
- **Agnóstico** - não há qualquer suposição sobre a configuração ou propriedades de duas redes de comunicação. As redes podem diferir em todos os aspectos, exceto na capacidade de entender o XCM. Por exemplo, uma cadeia pode ser compatível com EVM e a outra não, uma cadeia pode ser uma rede DeFi e a outra uma rede de jogos, e assim por diante.
## Taxas {: #fees }
Um usuário que executa uma transação em uma rede deve pagar as taxas derivadas do esforço computacional associado à tarefa, e a execução cross-chain não é exceção a essa regra. Na comunicação cross-chain, uma mensagem requer execução em pelo menos duas cadeias diferentes, e o usuário precisa pagar as taxas associadas ao esforço computacional feito por cada cadeia envolvida. Além dos custos relacionados à execução, as redes Tanssi incluem uma [taxa de entrega](https://paritytech.github.io/polkadot-sdk/master/polkadot_runtime_common/xcm_sender/struct.ExponentialPrice.html){target=\_blank} padrão para evitar spam XCM.
Por exemplo, se um usuário na rede A deseja chamar um contrato inteligente na rede B, o usuário deve ter fundos suficientes para pagar a entrega da mensagem e incluir instruções na mensagem XCM para fornecer um ativo que a rede B aceite como pagamento por seus serviços para cobrir as taxas associadas. Uma vez que esse ativo é fornecido, a execução agora pode ser comprada na cadeia de destino.
!!! note
Como as redes são soberanas, elas decidem quais tokens são válidos para pagar suas taxas de execução XCM.
Por exemplo, se a rede B aceitar tokens da rede A para pagamentos de taxas, qualquer usuário na rede A pode pagar por uma mensagem XCM destinada à rede B usando apenas tokens da rede A.
## Casos de Uso Comuns {: #common-use-cases }
Muitos casos de uso podem ser abordados, beneficiando-se do terreno comum e da versatilidade que o XCM oferece. Dois dos mais recorrentes são transferências de ativos e execução remota.
### Transferências de Ativos {: #asset-transfer }
Mover ativos digitais de uma rede para outra é essencial para criar um ecossistema blockchain mais dinâmico, eficiente e interconectado. O recurso cross-chain nativo permite duas estratégias principais para transferir ativos de uma cadeia para outra:
- **Teleporte** - teletransportar um ativo é um mecanismo simples e eficiente, mas tem uma grande ressalva: requer confiança entre as partes. Essencialmente, quando a rede A deseja enviar X quantidade de ativos para a rede B, ela queima X quantidade de ativos e envia uma mensagem para a rede B instruindo-a a cunhar exatamente X quantidade de ativos, preservando o saldo geral de ativos e concluindo a ação de teletransporte. Nesse processo, a rede A confia na rede B para não cunhar mais tokens do que o transferido, e a rede B confia na rede A para queimar os tokens que foram transferidos
- **Transferência de reserva** - Uma transferência de reserva envolve a **cadeia de reserva** de um ativo, que é a cadeia onde o ativo é nativo (por exemplo, [Moonbeam](https://moonbeam.network/){target=\_blank} é a cadeia de reserva para o token GLMR). Além disso, as redes não reservadas mantêm uma *conta soberana* na cadeia de reserva, uma conta sem chave gerenciada pelo respectivo governador da rede. Assim, quando a rede de reserva A deseja enviar X quantidade de um ativo para a rede não reservada B, ela transfere localmente os ativos para a conta soberana da rede B e, na mesma ação atômica, envia uma mensagem XCM para a rede B com instruções para cunhar X quantidade de uma forma derivada do ativo transferido. Por outro lado, se a rede não reservada B deseja enviar X quantidade de um ativo para a rede de reserva A, as etapas são: a rede B queima a forma derivada do ativo localmente e envia uma mensagem XCM para a rede A, com instruções para transferir os ativos da conta soberana da rede B para a conta de destino da rede A. Mesmo que a rede não reservada cunhe tokens derivados em excesso (ou não queime tokens ao transferir), esses tokens não terão valor real porque não são apoiados um a um na cadeia de reserva
As taxas associadas à execução de transferências são tipicamente deduzidas do valor transferido, para que o destinatário receba a quantia pretendida menos as taxas.
### Execução Remota {: #remote-execution }
A interoperabilidade nativa que o XCM fornece permite que uma rede envie uma mensagem a outra, acionando alguma ação. Por exemplo, se a cadeia de destino for compatível com EVM, a rede A poderá chamar um contrato inteligente implantado na rede B.
Conforme mencionado na [seção de taxas](#fees), para que qualquer solicitação na cadeia seja executada, é necessário cobrir suas taxas associadas. No XCM, a execução remota pode ser comprada com duas etapas:
1. Reservar alguns ativos usando a instrução `WithdrawAsset` XCM, que retira fundos da origem da chamada e os coloca em um registro de retenção
2. Pagar pela execução na cadeia, usando a instrução `BuyExecution` XCM, que usa os ativos previamente retirados
!!! note
Quando uma rede envia uma mensagem XCM, sua fonte padrão no lado receptor é a conta soberana da rede de origem. A rede remetente pode adicionar uma instrução XCM chamada `DescendOrigin` à mensagem, alterando a conta de origem para corresponder à conta do usuário que assina, garantindo que a execução ocorra em nome da mesma entidade que inicia a mensagem XCM na cadeia de origem e evitando um cenário potencialmente inseguro.
Finalmente, a execução ocorre na cadeia de destino, chamando um contrato inteligente ou qualquer outra transação usando a instrução XCM chamada `Transact`.
O fluxo geral para execução remota é representado no seguinte diagrama:
## Estabelecendo Comunicação Cross-Chain {: #channel-registration }
Antes que duas cadeias possam se comunicar, um canal de mensagens deve ser estabelecido. Os canais são unidirecionais, o que significa que canais separados são necessários para enviar mensagens da cadeia A para a cadeia B e da B para a A.
Para que a cadeia A se comunique com a cadeia B, a cadeia A deve enviar uma transação de canal aberto para a cadeia de retransmissão solicitando que um canal seja aberto com a cadeia B. A cadeia B deve então aceitar a solicitação enviando uma mensagem XCM correspondente para a cadeia de retransmissão. Somente quando ambas as cadeias concordam é que o canal é aberto na próxima época. O mesmo processo é necessário para estabelecer um canal da cadeia B para a cadeia A.
É importante notar que um canal entre uma rede e a cadeia de retransmissão é aberto automaticamente mediante registro e integração da rede.
Depois que o canal é estabelecido, as mensagens cross-chain podem ser enviadas entre as redes. Para transferências de ativos, os ativos também precisarão ser registrados antes de serem transferidos.
!!! note
XCM é uma linguagem versionada e em constante evolução. Quando duas redes de comunicação usam versões diferentes do XCM, elas devem usar a versão mais recente com suporte do lado menos atualizado. Para descobrir a versão XCM mais recente com a qual uma rede pode trabalhar, outras redes podem consultá-la e assinar atualizações sempre que isso mudar.
## Destinos de Mensagens {: #message-destinations }
Para compor mensagens significativas em um ambiente multichain, é necessário ter uma maneira precisa e abstrata de referenciar recursos localizados em diferentes sistemas de consenso. Um conceito chamado *multilocalização* é usado para servir a esse propósito e direcionar uma cadeia específica ou qualquer um de seus elementos internos, como uma conta, um ativo ou um contrato inteligente.
Os elementos de destino do XCM são organizados em uma arquitetura hierárquica, onde os elementos estão contidos em outros componentes. Por exemplo, um contrato inteligente é um elemento contido em uma rede, e o mesmo pode ser dito para uma conta ou um ativo ERC20. As redes estão contidas pela cadeia de retransmissão, que desempenha um papel crucial no processo de mensagens cross-chain, retransmitindo mensagens de uma rede para outra.
Multilocalizações não são um localizador de recursos universal. Eles se referem a elementos da perspectiva do remetente e são compostos por dois componentes: `pais` e `interior`. Pais é uma propriedade que indica se a rota deve "subir" na hierarquia, ou seja, de uma rede para a cadeia de retransmissão. Interior é uma lista de junções que definem como localizar o destino. Aqui estão alguns exemplos de multilocalizações:
- **Rede A referencia um contrato inteligente na rede B** - do ponto de vista da rede A, para alcançar um contrato inteligente na rede B, é necessário subir na hierarquia (para a cadeia de retransmissão) e, em seguida, descer para a rede B para, uma vez lá, referenciar o endereço do contrato inteligente. A multilocação é, portanto, definida com um valor de `pais` definido como `1`, que sobe, e duas junções, uma que define qual rede deve receber a mensagem e a outra que define o endereço H160 do contrato inteligente que será chamado
- **Rede A referencia uma conta na cadeia de retransmissão** - do ponto de vista da rede A, para referenciar uma conta na cadeia de retransmissão, é necessário subir e, em seguida, referenciar a conta. A multilocação é definida com um valor de `pais` definido como `1`, que sobe para a cadeia de retransmissão, e uma junção que referencia o endereço de destino do tipo substrato
--- END CONTENT ---
Doc-Content: https://docs.tanssi.network/pt/learn/tanssi/account-types/
--- BEGIN CONTENT ---
---
title: Contas no Protocolo Tanssi
description: Visão geral das chaves criptográficas essenciais para o protocolo Tanssi, detalhando os tipos de contas usados e suas funções gerais.
icon: octicons-key-24
categories: Basics
---
# Contas no Protocolo Tanssi
## Introdução {: #introduction }
A tecnologia blockchain baseia-se na criptografia de chaves [público-privadas](https://en.wikipedia.org/wiki/Public-key_cryptography){target=\_blank} para propriedade segura de ativos e verificação de transações. Chaves privadas autorizam transações, enquanto chaves públicas servem como endereços para verificação. Devido à natureza híbrida [Substrate](/pt/learn/framework/overview/#substrate-framework){target=\_blank} e Ethereum do protocolo Tanssi, entender os diferentes tipos de conta é crucial para usuários e operators.
## Tipos de Conta no Protocolo Tanssi {: #key-types-in-tanssi-protocol }
| **Tipo de Conta** | **Algoritmo Subjacente** | **Uso Principal na Tanssi** |
| --- | --- | --- |
| [Sr25519](https://wiki.polkadot.com/learn/learn-cryptography/){target=\_blank} | Assinaturas Schnorr no grupo Ristretto | Esquema padrão de assinatura para transações baseadas em Substrate e identidade de operator. |
| [Ed25519](https://wiki.polkadot.com/learn/learn-cryptography/){target=\_blank} | EdDSA usando Curve25519 | Usado para funções específicas de consenso (ex.: produção de blocos, finalidade) no Substrate. |
| [ECDSA](https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm){target=\_blank} | Algoritmo de Assinatura Digital de Curva Elíptica | Recebimento de recompensas via protocolo Symbiotic baseado em Ethereum para operators. |
## Identidade e Operações {: #identity-and-operations }
A Tanssi, construída com o framework Substrate, utiliza esquemas criptográficos distintos para funções diferentes, principalmente _Sr25519_ e _Ed25519_. Esses tipos de conta são essenciais para interagir com os componentes Substrate do protocolo, assinando transações.
**Sr25519 (Schnorrkel/Ristretto x25519)** – é o tipo de conta principal usado na maioria das operações voltadas ao usuário dentro da Tanssi. Seus pontos fortes são segurança e eficiência. **Contas Sr25519 servem como sua identidade on-chain, usadas para manter tokens, participar de governança, pagar taxas de transação e outras interações gerais com a rede.**
**Ed25519 (Algoritmo de Assinatura Digital de Curva Edwards)** – enquanto Sr25519 cuida da identidade e transações gerais, Ed25519 é usado por seu alto desempenho em assinatura criptográfica, ideal para operações de consenso. **Na Tanssi, contas Ed25519 são usadas por node operators para mecanismos críticos, como produção de blocos e finalidade.** Usuários comuns normalmente não criam ou usam diretamente contas Ed25519, mas elas são fundamentais para a segurança e operação da rede.
Operators de nó na Tanssi precisam de uma conta Substrate para registrar suas atividades, incluindo validadores que protegem a rede e Sequencers que produzem blocos. Esta conta também rastreia recompensas, com chaves de sessão mapeadas para ela para maior segurança.
## Segurança e Recompensas no Ethereum {: #security-and-rewards-on-ethereum }
O Algoritmo de Assinatura Digital de Curva Elíptica (ECDSA) é fundamental para o Ethereum e é usado pela Tanssi para integrar-se à rede Ethereum via Symbiotic. Essa parceria alavanca a segurança do Ethereum para redes powered by Tanssi.
Operators Tanssi precisam de uma conta ECDSA para receber recompensas distribuídas no Ethereum, geralmente via protocolo Symbiotic. A necessidade de contas Substrate e ECDSA destaca o design híbrido da Tanssi, em que as operações são baseadas em Substrate, e a segurança e as recompensas estão vinculadas ao Ethereum.
## Mapeamentos de Conta na Tanssi {: #account-mappings-in-tanssi }
### Vinculação Interna de Chaves (_Sr25519_ e _Ed25519_)
Dentro do protocolo Substrate da Tanssi, a identidade _Sr25519_ primária de um operator se vincula a chaves _Ed25519_ específicas usadas para tarefas de consenso (como produção de blocos). Os operators criam essa vinculação com uma transação on-chain, mapeando suas chaves públicas internas (“chaves de sessão”) para a conta de stash. Esse registro on-chain garante que a rede atribua corretamente todas as ações das chaves de sessão à identidade primária do operator.
### Mapeamento de Recompensas entre Ecossistemas (_Sr25519_ e _ECDSA_)
Para recompensas no Ethereum (por exemplo, via [Symbiotic](/pt/learn/tanssi/external-security-providers/symbiotic/){target=\_blank}), a identidade _Sr25519_ do operator é mapeada para um endereço _ECDSA_ no Ethereum. As duas contas são vinculadas pelo middleware da Tanssi, garantindo que as recompensas do trabalho do operator na rede Tanssi sejam roteadas para a conta Ethereum designada.
--- END CONTENT ---
Doc-Content: https://docs.tanssi.network/pt/learn/tanssi/external-security-providers/symbiotic/
--- BEGIN CONTENT ---
---
title: Symbiotic como Provedor Externo de Segurança
description: O design da Tanssi permite conectar ao protocolo de re‑staking Symbiotic, aproveitando segurança em nível de Ethereum desde o início.
icon: octicons-shield-check-24
categories: Basics
---
# Ethereum com Symbiotic {: #ethereum-symbiotic }
## Introdução {: #introduction }
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](https://symbiotic.fi/){target=\_blank} 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 {: #symbiotic }
O [Symbiotic](https://symbiotic.fi/){target=\_blank} é 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:
```mermaid
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 {: #vaults }
Os [Vaults](https://docs.symbiotic.fi/modules/vault/introduction){target=\_blank} 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](https://github.com/ethereum/ercs/blob/master/ERCS/erc-20.md){target=\_blank} 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](#slashing-process), que penaliza maus atores
- **Módulo Delegator** - define como os fundos são delegados entre operators e redes. Diversas [estratégias](https://docs.symbiotic.fi/modules/vault/delegator){target=\_blank} 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](https://ethereum.org/developers/docs/standards/tokens/erc-4626/){target=\_blank}, 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](https://docs.symbiotic.fi/modules/counterparties/resolvers){target=\_blank}, responsáveis por aprovar ou vetar [eventos de slashing](https://docs.symbiotic.fi/modules/vault/slasher){target=\_blank} causados por operators em redes com suporte a [veto-slashing](https://docs.symbiotic.fi/modules/vault/slasher#veto-slashing){target=\_blank}, como a Tanssi Network.
### Operators {: #operators }
Os [node operators](/pt/node-operators/){target=\_blank} são entidades ou indivíduos responsáveis por executar os [nós (também conhecidos como operators ou validadores)](https://docs.symbiotic.fi/modules/counterparties/operators){target=\_blank}, 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 {: #networks }
As [Redes](https://docs.symbiotic.fi/modules/counterparties/networks){target=\_blank} 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 {: #tanssi-symbiotic }
Desenvolvedores que lançam redes por meio da Tanssi se beneficiam dos [serviços de produção de blocos](/pt/learn/tanssi/network-services/block-production/){target=\_blank}, 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.
```mermaid
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 {: #tanssi-ethereum-communication }
É 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:
```mermaid
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 {: #from-ethereum-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 {: #from-tanssi-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 {: #rewards }
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](#reward-distribution-phase) e [Fase de Reivindicação de Recompensas](#reward-claiming-phase).
#### Fase de Distribuição de Recompensas {: #reward-distribution-phase }
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:
1. **Cálculo de Recompensas** - o Tanssi calcula recompensas com base na atividade de operators e stakers e então cria uma [raiz de Merkle](https://en.wikipedia.org/wiki/Merkle_tree){target=\_blank}. 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
2. **Dados de Recompensa Enviados via XCM** - os dados de alocação de recompensas são enviados usando [XCM](https://wiki.polkadot.com/learn/learn-xcm/){target=\_blank} (Cross-Consensus Messaging), um protocolo padronizado para comunicação entre blockchains. A [Snowbridge](https://docs.snowbridge.network/){target=\_blank} atua como uma bridge sem confiança entre Tanssi e Ethereum
3. **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
4. **Processamento e Validação da Mensagem** - o `Gateway` encaminha os dados para o [`Middleware`](https://github.com/moondance-labs/tanssi-symbiotic/blob/main/src/contracts/middleware/Middleware.sol){target=\_blank}, que é responsável por várias tarefas, incluindo passar as informações para o contrato `OperatorReward`
5. **Armazenamento e Distribuição de Recompensas** - este é o destino final dos dados. O contrato [`OperatorRewards`](https://github.com/moondance-labs/tanssi-symbiotic/blob/main/src/contracts/rewarder/ODefaultOperatorRewards.sol){target=\_blank} armazena a árvore de Merkle das alocações de recompensa e lida com a transferência de tokens de recompensa quando um claim é feito
```mermaid
%%{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 {: #reward-claiming-phase }
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.
1. **Reivindicação de Recompensa pelo Operator** - operators podem reivindicar sua parcela chamando o contrato `OperatorRewards` usando um recibo criptográfico que comprova seu direito
2. **Liberação de Tokens** - a chamada do operator aciona a liberação de tokens, e o `OperatorRewards` envia o valor estabelecido ao operator
3. **Distribuição de Tokens aos Stakers** - as recompensas restantes são encaminhadas ao contrato `StakerRewards` para posterior reivindicação dos stakers
4. **Alocação dos Stakers** - os 80% restantes das recompensas são direcionados automaticamente ao contrato [`StakerRewards`](https://github.com/moondance-labs/tanssi-symbiotic/blob/main/src/contracts/rewarder/ODefaultStakerRewards.sol){target=\_blank}, onde os stakers podem reivindicar recompensas proporcionais ao seu stake nos vaults
```mermaid
%%{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 {: #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 {: #slashing-process }
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:
1. **Slash Reportado** - o Tanssi envia a solicitação de slashing ao `Middleware` com os parâmetros `operatorKey`, `percentage` e `epoch`
2. **Validação do Operator** - o `Middleware` valida a identidade do operator e verifica se ele está sujeito ao slashing
3. **Recuperar Vaults Ativos** - o `Middleware` percorre todos os vaults ativos durante a época da infração, ignorando qualquer vault inativo
4. **Recuperar Stake do Operator** - para cada vault ativo, o `Middleware` recupera o stake do operator infrator
5. **Calcular Valor do Slash** - o `Middleware` calcula o valor do slashing aplicando a porcentagem de corte ao stake do operator em cada vault
6. **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.
```mermaid
%%{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 {: #burner }
O contrato `Burner` é uma extensão responsável por lidar com ações que seguem um [evento de slashing](#slashing-process), 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.
--- END CONTENT ---
Doc-Content: https://docs.tanssi.network/pt/learn/tanssi/network-features/staking/
--- BEGIN CONTENT ---
---
title: Staking para Produção de Blocos
description: Saiba como a Tanssi implementa um mecanismo de staking para prover disponibilidade por meio de um conjunto descentralizado e trustless de Sequencers para todas as redes powered by Tanssi.
icon: material-hand-coin-outline
categories: Basics
---
# Staking da Tanssi para Produção de Blocos {: #tanssi-staking }
## Introdução {: #introduction }
Uma das propostas centrais da Tanssi é simplificar a complexidade de infraestrutura das redes. Um componente crucial é iniciar um conjunto descentralizado de Sequencers, que a Tanssi oferece por meio de sua arquitetura e mecânica de staking.
A mecânica de staking da Tanssi garante que os Sequencers das redes powered by Tanssi sejam escolhidos de forma descentralizada e trustless, além de incentivar a comunidade a delegar para Sequencers de melhor desempenho ou mais engajados.
Este conteúdo apresenta os conceitos fundamentais do staking da Tanssi e como ele mantém um conjunto descentralizado de produção de blocos que garante a disponibilidade das redes.
## Conceitos Básicos {: #core-concepts }
A mecânica do módulo de staking da Tanssi foi inspirada no conceito de tokens de pool de liquidez (LP tokens) em AMMs tradicionais como Uniswap V2.
Cada Sequencer possui quatro pools de liquidez pelos quais os delegadores passam ao realizar diferentes operações de staking. Cada pool representa um estado do processo: ingresso, recompensas manuais, recompensas com auto-compound e saída. Diferente dos LP tokens tradicionais, os tokens de participação nesses pools não são transferíveis.
O delegador tem quatro transações simples para percorrer os estados (pools): delegar (para recompensas manuais ou auto-compound), undelegar, trocar e executar operações pendentes. Por exemplo, para entrar em um dos pools de recompensas, o usuário delega e entra no Joining Pool imediatamente. Após um atraso, o próprio usuário (ou qualquer pessoa) pode executar a operação pendente e entrar no pool de recompensas escolhido. Depois, pode trocar entre pools de recompensa quando quiser. Por fim, quem está em um pool de recompensas pode usar *undelegate* para ir ao Leaving Pool e remover o stake; após o atraso, qualquer pessoa pode executar a operação pendente e concluir a saída.
Pools de liquidez possuem shares, análogas a LP tokens em AMMs. Ao entrar em um novo pool, o usuário recebe shares conforme o tipo de pool, a quantidade delegada, o total de shares e o total delegado nesse pool.
Recompensas são atribuídas aos pools Manual ou Auto-Compound de um Sequencer quando a Tanssi atesta que o slot de produção de blocos designado foi cumprido com sucesso.
Todas as recompensas (de todos os pools) ficam em uma conta do protocolo, mas o protocolo rastreia internamente os tokens nativos de cada pool. A diferença entre pools Manual e Auto-Compound é como as recompensas são distribuídas: no **Manual Rewards Pool**, o usuário precisa reivindicar; no **Auto-Compound Rewards Pool**, as recompensas são automaticamente reinvestidas a cada bloco da Tanssi.
As operações de delegar e undelegar precisam ser enviadas pelo próprio delegador, sinalizando a intenção e pedindo ao protocolo para realizar as verificações necessárias. Essas ações só podem ser executadas depois de um número de sessões, mas qualquer participante pode realizar a segunda etapa por meio da transação *execute pending operation*.
O diagrama a seguir resume o fluxo de delegar e undelegar para um Sequencer; ações do usuário em ciano e pools em coral.
## Parâmetros de Staking {: #staking-parameters }
=== "Tanssi MainNet"
| Variável | Valor |
|:-------------:|:---------------------------------------------------------------------------------------------------------------------:|
| Joining Delay | {{ networks.mainnet.staking.joining_delay_blocks }} blocos ({{ networks.mainnet.staking.joining_delay_hours }} horas) |
| Leaving Delay | {{ networks.mainnet.staking.leaving_delay_blocks }} blocos ({{ networks.mainnet.staking.leaving_delay_hours }} horas) |
=== "Dancelight TestNet"
| Variável | Valor |
|:-------------:|:---------------------------------------------------------------------------------------------------------------------------:|
| Joining Delay | {{ networks.dancelight.staking.joining_delay_blocks }} blocos ({{ networks.dancelight.staking.joining_delay_hours }} horas) |
| Leaving Delay | {{ networks.dancelight.staking.leaving_delay_blocks }} blocos ({{ networks.dancelight.staking.leaving_delay_hours }} horas) |
## Pools de Staking {: #staking-pools}
Esta seção detalha cada pool que representa uma etapa do processo de staking.
### Joining Pool {: #joining-pool}
Ao delegar para iniciar o staking, o usuário escolhe o mecanismo de recompensas: manual ou auto-compound (cada um é um pool). Após a transação, o usuário entra no Joining Pool e recebe shares proporcionais ao valor delegado. Esse pool oferece estabilidade aos Sequencers, impondo um atraso entre delegar e receber recompensas (pelo menos uma sessão).
Exemplo prático: Alice inicia o staking mirando o Manual Rewards Pool e entra no Joining Pool no meio de uma sessão; ela deve esperar até o fim da sessão seguinte para executar a operação pendente e começar a receber recompensas.
Joining Pools têm proporção 1:1 entre shares e tokens delegados. Se Alice delega 100 tokens, recebe 100 shares do Joining Pool. Quando a operação pendente de delegate é executada, o protocolo consome as shares do Joining Pool em troca dos tokens nativos, que são imediatamente convertidos em shares do Manual ou Auto-Compound Rewards Pool.
O diagrama abaixo supõe que o usuário está direcionando stake para o Manual Rewards Pool.
### Manual Rewards Pool {: #manual-rewards-pool}
Ao entrar no Manual Rewards Pool, o protocolo destrói as shares do Joining Pool em favor do token nativo. No mesmo bloco, calcula quantas shares do Manual Pool podem ser cunhadas com esse valor, com base no preço da share:
```mathematica
SharePrice [Tokens/Shares] = NumberOfTokensInPool / NumberOfSharesInPool
```
Shares não têm decimais; qualquer resto de tokens ao adquirir shares é devolvido ao usuário. O preço da share não muda com novas entradas, pois a razão é mantida. Com shares do Manual Rewards Pool, o usuário passa a acumular recompensas (na mesma sessão) que precisam ser reivindicadas manualmente.
Ao contrário do Auto-Compound, a distribuição no Manual ocorre por um mecanismo de checkpoint de recompensas. Ele rastreia o histórico de tokens nativos por share atribuído pelo protocolo naquele Manual Rewards Pool em um momento específico. Quando a Tanssi atesta um bloco produzido por um Sequencer, novas recompensas são atribuídas ao Manual Rewards Pool para os usuários reivindicarem, e o contador de recompensas aumenta. Assim, as recompensas são refletidas na razão de tokens por share, diferença entre o contador atual do pool e o checkpoint do usuário.
O contador de recompensas por share é essencial para calcular o valor devido ao reivindicar. Após calcular, o protocolo envia os tokens para o usuário e redefine o checkpoint dele para o contador atual do pool, garantindo alinhamento e zero recompensas pendentes.
De forma semelhante, ao adicionar ou remover stake, as recompensas são reivindicadas automaticamente e o checkpoint é redefinido, pois a condição de recompensas para aquele montante muda e precisa ser sincronizada com o pool.
### Auto-Compound Rewards Pool {: #autocompounded-rewards-pool}
Ao entrar no Auto-Compound Rewards Pool, o protocolo destrói as shares do Joining Pool em favor do token nativo. No mesmo bloco, calcula quantas shares de Auto-Compound podem ser cunhadas com esse valor, com base no preço da share:
```mathematica
SharePrice [Tokens/Shares] = NumberOfTokensInPool / NumberOfSharesInPool
```
Shares não têm decimais; qualquer resto é devolvido ao usuário. O preço da share não muda na entrada. Com shares do Auto-Compound Rewards Pool, o usuário acumula recompensas na mesma sessão.
Ao contrário do Manual, as recompensas em tokens nativos no Auto-Compound são atribuídas automaticamente a cada bloco da Tanssi em que o protocolo atesta o Sequencer designado. Como o número de tokens no pool cresce e o de shares permanece, o preço da share sobe; ao resgatar, o usuário recebe mais tokens por share do que na entrada.
As recompensas são reinvestidas como novo stake no Auto-Compound Rewards Pool, caracterizando o auto-compound.
Contudo, quando recompensas auto-compound são atribuídas, elas não ficam no saldo reservado do usuário; ainda estão na conta do protocolo, e o aumento do stake é representado pelo aumento do preço da share. Em alguns cenários, o usuário pode querer que esse saldo conste no estado como saldo reservado (por exemplo, governança).
Por isso, o protocolo oferece uma chamada específica para atualizar o saldo reservado de qualquer delegado, movendo as recompensas auto-compound da conta do protocolo para o saldo reservado do usuário. Isso também é executado automaticamente ao remover liquidez do Auto-Compound Rewards Pool.
### Leaving Pool {: #leaving-pool}
Ao sair de posições no Manual ou Auto-Compound, o usuário pode iniciar uma undelegation. Como na entrada, é um processo em duas etapas: assina a intenção de remover a delegação e aguarda pelo menos uma sessão antes de a operação ser executada por qualquer pessoa.
Ao executar a intenção de saída, o protocolo troca shares do pool específico por tokens nativos ao preço atual. Para o Manual Rewards Pool, recompensas não reivindicadas são atribuídas ao usuário. Em seguida, o protocolo compra shares do Leaving Pool em proporção 1:1 aos tokens nativos recebidos, garantindo que o usuário entre no Leaving Pool com shares equivalentes ao valor a ser retirado.
Após uma sessão, qualquer usuário pode executar a operação pendente; o protocolo então troca shares do Leaving Pool por tokens nativos em proporção 1:1.
O objetivo principal do Leaving Pool é fornecer um buffer para saídas, permitindo implementar mecanismos de slashing para coibir mau comportamento. O slashing não está implementado atualmente, mas pode ser adicionado no futuro.
O diagrama a seguir supõe que o usuário está saindo do Manual Rewards Pool.
### Trocar entre Pools de Recompensa {: #swap-rewards-pool}
O módulo de staking da Tanssi permite trocar o stake de um pool de recompensas para outro, total ou parcialmente, sem passar novamente pelos pools de entrada e saída.
Primeiro, todas as recompensas pendentes do Manual Rewards Pool são reivindicadas em nível de protocolo, pois a liquidez está sendo alterada e o checkpoint precisa ser sincronizado. Em seguida, shares do pool original são consumidas e trocadas por tokens nativos ao preço atual; então, shares do novo pool são adquiridas ao preço do novo pool. Qualquer “poeira” restante é convertida em shares do Leaving Pool. Tudo ocorre no mesmo bloco; não há atraso para começar a receber recompensas no novo pool. A poeira no Leaving Pool pode ser reivindicada após os atrasos necessários.
--- END CONTENT ---
Doc-Content: https://docs.tanssi.network/pt/learn/tanssi/network-services/block-production/
--- BEGIN CONTENT ---
---
title: Serviços de Produção de Blocos
description: A Tanssi abstrai as complexidades de infraestrutura, como a produção de blocos, permitindo lançar redes descentralizadas com segurança de nível Ethereum.
icon: octicons-container-24
categories: Basics
---
# Serviços de Produção de Blocos {: #block-production-services }
## Introdução {: #introduction }
Como apresentado no artigo [Visão Geral](/pt/learn/tanssi/overview/){target=\_blank}, Tanssi é um protocolo de infraestrutura que agiliza a implantação de redes descentralizadas com lógica personalizada que se adequa a uma ampla gama de casos de uso, incluindo DeFi, NFTs, Jogos e qualquer outro caso de uso que as equipes de desenvolvimento possam querer abordar.
A infraestrutura representa um enorme desafio para os desenvolvedores, exigindo que eles inicializem Sequencers, preservadores de dados e endpoints RPC, além de gerenciar integrações, interoperabilidade e segurança. Isso exige tempo e recursos valiosos, desviando o foco do que realmente importa: entregar valor aos seus usuários.
Tanssi orquestra recursos, permitindo que os desenvolvedores implantem redes descentralizadas (também conhecidas como serviços validados ativamente ou AVSs) que são totalmente adaptáveis a qualquer aplicativo ou caso de uso específico. Nesta analogia, a rede Tanssi se assemelha ao [Kubernetes](https://kubernetes.io){target=\_blank} em seu papel como orquestrador, gerenciando recursos para garantir a atividade e o desempenho das redes.
O protocolo também aborda a frente de segurança, permitindo que as redes selecionem e se conectem a provedores de segurança externos (como [Symbiotic](/pt/learn/tanssi/external-security-providers/symbiotic/){target=\_blank}), garantindo segurança de nível Ethereum desde o início.
Este artigo aborda os aspectos necessários a serem considerados ao construir e implantar seu próprio blockchain modular, juntamente com os aspectos técnicos mais relevantes do protocolo Tanssi.
## Produção de Blocos como Serviço {: #block-production-as-a-service }
O protocolo Tanssi fornece produção de blocos como serviço, orquestrando um conjunto descentralizado e confiável de Sequencers, garantindo a atividade das redes. Para fazer isso, o protocolo conecta ambas as extremidades:
- **Operators de nós**: Que executam Sequencers, oferecendo seus serviços de produção de blocos para obter recompensas.
- **Desenvolvedores**: Que lançam redes, que exigem Sequencers.
O protocolo atribui um subconjunto de Sequencers para fornecer serviços a cada rede, rotacionando-os após um período de tempo. Os Sequencers podem servir qualquer rede baseada em Tanssi, independentemente da lógica personalizada que implementam. Por outro lado, as redes implantadas por meio da Tanssi podem personalizar seu Runtime tanto quanto precisarem para se adequar ao seu caso de uso e atualizar a lógica a qualquer momento de forma sem bifurcação, sem se preocupar com a configuração do Sequencer.
O diagrama a seguir ilustra como o Tanssi atribui dois Sequencers a cada rede ativa, selecionando-os de um conjunto descentralizado de Sequencers.
```mermaid
flowchart TB
subgraph network1 [Rede 1]
s1bis[Sequencer 1]
s2bis[Sequencer 2]
end
subgraph network2 [Rede 2]
s3bis[Sequencer 3]
s4bis[Sequencer 4]
end
Tanssi[Rede Tanssi
Orquestrador]
subgraph sequencers [Pool de Sequencers]
direction LR
s1[Sequencer 1]
s2[Sequencer 2]
s3[Sequencer 3]
s4[Sequencer 4]
sn[Sequencer N]
s1 --- s2 --- s3 --- s4 --- sn
end
sequencers -- Gerenciado por --> Tanssi
Tanssi -- Atribui Sequencers --> network1
Tanssi -- Atribui Sequencers --> network2
```
### Processo de Seleção do Sequencer {: #sequencer-selection-process}
A qualquer momento, todas as redes Tanssi exigem um certo número de Sequencers, dependendo do número de redes ativas e da configuração atual de produção de blocos definida na Tanssi. A configuração define o número máximo de Sequencers totais no conjunto e o número de Sequencers que cada rede deve ter atribuído.
=== "Tanssi MainNet"
| Variável | Valor |
|:--------------------------:|:----------------------------------------------------------------------------------:|
| Máx. nº de Sequencers | {{ networks.mainnet.sequencers.configuration.max_block_producers }} |
| nº de Sequencers (Redes) | {{ networks.mainnet.sequencers.configuration.block_producer_per_container }} |
=== "Dancelight TestNet"
| Variável | Valor |
|:--------------------------:|:----------------------------------------------------------------------------------:|
| Máx. nº de Sequencers | {{ networks.dancelight.sequencers.configuration.max_block_producers }} |
| nº de Sequencers (Redes) | {{ networks.dancelight.sequencers.configuration.block_producer_per_container }} |
Assim que o número necessário de Sequencers para uma determinada sessão for conhecido, o Tanssi usa dois mecanismos para decidir o conjunto de Sequencers distribuídos entre todas as redes.
O primeiro mecanismo é através do módulo *Invulneráveis*, que define uma lista de Sequencers fixos priorizados pelo protocolo e garante a estabilidade da produção de blocos em certos cenários, como TestNets.
O segundo mecanismo é através do [módulo de staking da Tanssi](/pt/learn/tanssi/network-features/staking/){target=\_blank}. O módulo ajuda a criar um conjunto descentralizado de Sequencers para todas as redes Tanssi, fornecendo ao protocolo uma lista de Sequencers classificados por valor apostado. O Tanssi anexa a lista classificada por aposta de Sequencers aos invulneráveis (se houver), em seguida, pega da lista apenas a quantidade exata de Sequencers necessária, começando do topo, deixando de fora da próxima sessão aqueles Sequencers que têm menos valor apostado, para finalmente iniciar o processo de atribuição do Sequencer.
### Atribuição de Sequencers {: #block_producers-assignment }
Assim que o conjunto de Sequencers que participará da próxima sessão for conhecido, o Tanssi embaralha a lista e os atribui para fornecer serviços de produção de blocos às redes Tanssi ativas.
O algoritmo de atribuição começará a distribuir os Sequencers que atendem às redes pela data de registro em ordem de chegada. Depois que a atribuição for feita, ela será mantida por pelo menos uma sessão, representando um período medido em blocos com um conjunto constante de Sequencers. No Tanssi MainNet, a duração da sessão padrão é definida como {{ networks.mainnet.session.blocks }} blocos, o que, com um tempo médio de bloco de seis segundos, se traduz em (aproximadamente) {{ networks.mainnet.session.display }} horas.
Cada nova atribuição funciona intencionalmente com um atraso de uma sessão, para que os Sequencers saibam com antecedência a qual das redes eles estão atribuídos. Os Sequencers começarão a sincronizar a nova rede que terão que servir na próxima sessão com um mecanismo de sincronização especial chamado [warp sync](https://spec.polkadot.network/chap-sync#sect-sync-warp){target=\_blank}. O warp sync permite que os Sequencers sincronizem rapidamente a nova rede sem atuar como um nó de arquivo.
Quando uma nova sessão começa, o protocolo Tanssi colocará a atribuição na fila em vigor. Os Sequencers mudarão automaticamente e começarão a produzir blocos na nova rede Tanssi a que foram atribuídos, descartando o estado da cadeia da atribuição anterior. O Tanssi também calculará a nova atribuição, considerando as alterações nas redes Tanssi que podem ter sido ativadas ou desativadas e os Sequencers que podem ter sido adicionados ou removidos do pool ou alterado o valor total apostado. Esta nova atribuição será enfileirada para a próxima sessão.
### O Papel da Rede Tanssi {: #tanssi-newtwork }
Como discutido anteriormente, o protocolo Tanssi atribui Sequencers às redes Tanssi, e o resultado desta atribuição é armazenado no estado da cadeia. Além de executar o nó da rede, os Sequencers também executam o Tanssi. Portanto, ao acessar os dados armazenados nos blocos finalizados da Rede Tanssi, eles podem aprender sua atribuição para a sessão, e as redes Tanssi podem confirmar que um determinado grupo de Sequencers foi atribuído a elas.
À medida que as redes Tanssi produzem blocos, esses blocos precisam ser validados e finalizados por um provedor de segurança externo. Depois que um operator verifica um bloco, uma pequena prova de validade é produzida e armazenada na Tanssi, mantendo o controle das provas para cada bloco de cada cadeia. Esta pequena representação da prova de validade é chamada de [recibo de candidato](https://wiki.polkadot.com/learn/learn-parachains-protocol/#candidate-receipts){target=\_blank} e é composta por um conjunto de valores, incluindo a raiz do estado, que pode ser usada para verificar provas de estado.
Finalmente, o Tanssi pode verificar se o autor de um bloco de rede foi o esperado e recompensá-lo de acordo.
O diagrama a seguir mostra um Template simplificado dos dados que o Tanssi armazena em seu estado interno. Para cada rede ativa (neste exemplo, duas), o Tanssi armazena os Sequencers atribuídos, que são os únicos autorizados a produzir blocos em nome da rede, prova de validade (recibos de candidatos) estendidos pelos operators do provedor de segurança, a raiz do estado mais recente e o Sequencer mais recente.
### O Papel da Rede powered by Tanssi {: #network }
Como um Sequencer atribuído a uma rede powered by Tanssi inclui funcionalidade de nó Tanssi integrada, é tecnicamente viável ler o estado da Rede Tanssi.
Aproveitando essa capacidade de acessar os estados, o Sequencer atual com a autoridade para produzir um bloco lerá o estado do último bloco produzido na cadeia Tanssi. Ele prosseguirá para incluir este estado no bloco da rede, o conjunto atual de Sequencers atribuídos à rede e sua assinatura pública, permitindo que o Tanssi saiba quem produziu o bloco e recompense o operator do nó.
Depois que o bloco for preenchido com as transações da rede, ele será proposto como candidato e entregue à cadeia Tanssi, onde os operators do provedor de segurança garantirão que as provas de estado incluídas correspondam às provas de estado do último estado da Tanssi (impedindo a produção não autorizada de blocos) e que as transações produziram transições de estado válidas. Tendo verificado o trabalho do Sequencer, os operators finalizarão o bloco proposto, incluindo seu recibo de candidato em um bloco de rede Tanssi.
## Taxas de Produção de Blocos {: #block-production-fees }
Como apresentado na [Introdução](#introduction), Tanssi é um protocolo de infraestrutura que aborda as complexidades e os altos custos associados à configuração e manutenção da infraestrutura blockchain, agilizando a implantação de redes. Este protocolo traz benefícios para ambos os participantes:
- **Redes**: As equipes podem se concentrar na lógica principal de seu produto, na UX e na UI, sem lidar com os desafios da inicialização da infraestrutura e seu gerenciamento.
- **Sequencers**: Assumindo a responsabilidade de manter sua configuração de hardware e software em ótimas condições, eles são incentivados a executar transações e produzir blocos em nome das redes Tanssi.
A [produção de blocos como serviço](#block-production-as-a-service) acarreta custos associados que devem ser cobertos pelas redes que desejam alavancar o Tanssi para tal fim. As seções a seguir cobrem os aspectos gerais desses custos e pagamentos de serviços associados.
### Pagamentos de Serviços {: #service-payments }
Existem três custos principais associados à produção de blocos como serviço que qualquer rede deve cobrir usando tokens Tanssi para implantar com sucesso e obter os serviços de produção de blocos:
- **Depósito de registro**: O depósito inicial que é bloqueado da conta que assina a transação de registro da rede.
- **Depósito de armazenamento de registro**: O depósito inicial que é bloqueado da conta que assina a transação de registro da rede. É um valor variável dependendo do tamanho do Runtime da appchain.
- **Atribuição de Sequencers**: Toda vez que o protocolo Tanssi atribui Sequencers, o que acontece uma vez por sessão, uma taxa fixa é cobrada. Esta taxa dá às redes o direito de serem atribuídas Sequencers e desencoraja redes cuja lógica de Runtime não consegue produzir transações ou blocos válidos.
- **Produção de blocos**: As redes devem pagar por cada bloco produzido em seu nome. Como o protocolo seleciona e atribui os Sequencers por sessão, as redes devem ter fundos suficientes para cobrir todos os blocos a serem produzidos em uma sessão inteira para serem atendidos.
A configuração atual é definida da seguinte forma:
=== "Tanssi MainNet"
| Variável | Valor |
|:----------------------------:|:------------------------------------------------------------------------------------------------------------------------------------------:|
| Depósito de registro | {{ networks.mainnet.costs.registration_deposit_fee }} {{ networks.mainnet.token_symbol }} |
| Depósito de armazenamento de registro | {{ networks.mainnet.costs.registration_deposit_per_byte }} x 10-5 {{ networks.mainnet.token_symbol }} por byte de Runtime da appchain |
| Atribuição de Sequencers | {{ networks.mainnet.costs.cost_per_assignment }} {{ networks.mainnet.token_symbol }} por sessão |
| Produção de blocos | {{ networks.mainnet.costs.cost_per_block }} {{ networks.mainnet.token_symbol }} por bloco |
=== "Dancelight TestNet"
| Variável | Valor |
|:---------------------:|:---------------------------------------------------------------------------------------------------:|
| Depósito de registro | {{ networks.dancelight.costs.registration_deposit_fee }} {{ networks.dancelight.token_symbol }} |
| Depósito de armazenamento de registro | {{ networks.dancelight.costs.registration_deposit_per_byte }} x 10-5 {{ networks.dancelight.token_symbol }} por byte de Runtime da appchain |
| Atribuição de Sequencers | {{ networks.dancelight.costs.cost_per_assignment }} x 10-6 {{ networks.dancelight.token_symbol }} por sessão |
| Produção de blocos | {{ networks.dancelight.costs.cost_per_block }} x 10-6 {{ networks.dancelight.token_symbol }} por bloco |
Para garantir a produção de blocos na próxima sessão, o saldo total deve ser pelo menos suficiente para cobrir o custo de atribuição de Sequencers mais o custo de produção dos {{ networks.mainnet.session.blocks }} blocos que compõem uma sessão inteira.
!!! note
Embora os custos de atribuição de Sequencers e produção de blocos sejam atualmente fixos, à medida que o desenvolvimento do protocolo progride, eles podem se tornar dinâmicos, variando em resposta à carga de trabalho da rede.
### Gorjetas {: #tipping }
Em algumas ocasiões, o Tanssi pode experimentar uma alta demanda por seus serviços de produção de blocos que não pode ser atendida com os recursos disponíveis. Por exemplo, se houver dez redes ativas para a próxima sessão e o Tanssi só puder servir oito, duas redes serão paralisadas durante toda a duração da sessão.
Para lidar com esses períodos de alta carga de trabalho, o protocolo Tanssi implementa um mecanismo de gorjeta que permite que as redes compitam por uma prioridade maior em relação ao restante. Semelhante às redes compatíveis com Ethereum, onde uma taxa de prioridade pode ser definida para superar as transações concorrentes e obter tratamento de execução preferencial, as redes Tanssi serão atendidas de acordo com a prioridade dada pelas gorjetas que oferecem. Seguindo o exemplo anterior, se houver dez redes ativas para a próxima sessão e o Tanssi só puder servir oito, apenas as oito redes com maior lance receberão Sequencers atribuídos.
--- END CONTENT ---
Doc-Content: https://docs.tanssi.network/pt/learn/tanssi/overview/
--- BEGIN CONTENT ---
---
title: Visão Geral
description: Tanssi é um protocolo de infraestrutura que simplifica o processo de implantação de appchains descentralizadas, permitindo que os desenvolvedores se concentrem na criação de seus produtos.
icon: octicons-home-24
categories: Basics
---
# O Que é Tanssi? {: #what-is-tanssi }
Tanssi é um protocolo de infraestrutura de appchain descentralizado que permite que os desenvolvedores lancem sua appchain em minutos. Em outras palavras, Tanssi reduz o processo de configuração de seis a doze meses normalmente necessário para qualquer equipe entrar em funcionamento com uma nova cadeia para minutos.
Pode-se pensar em Tanssi como _AWS para appchains_. Em vez de lidar com toda a infraestrutura de rede você mesmo, Tanssi lida com todos os obstáculos, permitindo que você se concentre na criação da lógica do seu aplicativo, no crescimento de sua comunidade e em outras tarefas essenciais para o sucesso do seu produto.
A segurança é outro obstáculo significativo que os desenvolvedores devem enfrentar, assumindo a responsabilidade de atrair ativos em stake para garantir a segurança do consenso e inicializar um conjunto de validadores, o que pode ser particularmente desafiador para projetos em seus estágios iniciais. Todas as appchains powered by Tanssi se beneficiam da segurança de nível Ethereum desde o início e, ao aproveitar o design descentralizado da Tanssi, as appchains não estão expostas a pontos únicos de falha.
As appchains powered by Tanssi também se beneficiam de uma pilha de tecnologia modular, fornecendo controle máximo sobre a lógica que alimenta o Runtime do blockchain, oferecendo uma excelente maneira de os projetos escalarem e construírem soluções otimizadas para seus produtos. Esse controle completo sobre a lógica da appchain e o mecanismo de governança se adequa perfeitamente a uma ampla gama de casos de uso, incluindo protocolos DeFi, Ativos do Mundo Real (RWA), plataformas de jogos e outros.
## O Problema com Appchains {: #the-problem-with-appchains }
Os desenvolvedores que buscam construir appchains descentralizadas geralmente têm que lidar com os seguintes problemas:
- **Gerenciamento de Infraestrutura Complexo**: As implantações de appchain normalmente exigem o manuseio de numerosos componentes de infraestrutura, incluindo bootstrapping de Sequencers, operators (também conhecidos como validadores), carteiras, exploradores de blocos, oracles, indexadores, endpoints RPC e muito mais. O gerenciamento adequado desses componentes consome tempo e recursos.
- **Segurança Fraca e Ineficiente**: As appchains geralmente sofrem por ter um pequeno conjunto de operators ou segurança econômica fraca. Projetos em estágio inicial geralmente carecem de apoio econômico suficiente para oferecer suporte a um mecanismo de consenso robusto. Além disso, os desenvolvedores geralmente têm que pagar pela validação total da capacidade do blockchain, mesmo quando podem não ter alcançado o ajuste produto-mercado, e os blocos podem estar quase vazios. Isso essencialmente significa que os operators estão sendo super pagos, e há um custo de oportunidade significativo, pois esses recursos poderiam ser usados em outros lugares para desenvolver o protocolo.
- **Cross-Chain e Interoperabilidade**: As appchains inerentemente carecem de recursos cross-chain, o que as impede de se conectar a outros ecossistemas de blockchain. Além disso, o desenvolvimento de soluções de interoperabilidade requer expertise especializada e implementação meticulosa.
- **Tempo para o mercado lento**: As complexidades da infraestrutura da appchain desviam o foco dos desenvolvedores da lógica do aplicativo, que é o principal impulsionador de interfaces intuitivas e uma experiência do usuário perfeita, crítica para a adoção.
## O que Tanssi Fornece {: #what-tanssi-provides}
Tanssi aborda os pontos problemáticos mais comuns da appchain:
- **Sequenciamento como Serviço**: As appchains construídas com Tanssi têm seus blocos produzidos pelos trabalhadores incentivados da Tanssi. Tanssi garante a atividade contínua da appchain, orquestrando um conjunto descentralizado de Sequencers.
- **Segurança Econômica por Meio de Provedores Externos**: As appchains implantadas por meio da Tanssi aproveitam a segurança de um provedor de escolha (por exemplo, [Symbiotic](https://symbiotic.fi/){target=\_blank} para Ethereum). O protocolo foi projetado para finalizar as transações de forma determinística em segundos por meio de um conjunto descentralizado de operators.
- **Tanssi/Ethereum Bridge**: Mova a liquidez de e para o Ethereum usando a [bridge integrada](/pt/learn/tanssi/tanssi-ethereum-bridge/){target=\_blank} com base no Snowbridge.
- **Integrações Chave**: As appchains construídas com Tanssi podem acessar componentes de infraestrutura importantes, juntamente com a produção de blocos, de forma totalmente automatizada e padronizada. As appchains powered by Tanssi vêm com suporte integrado para ferramentas essenciais, incluindo carteiras, exploradores de blocos, indexadores, provedores RPC e muito mais, economizando o esforço dos desenvolvedores de integrar esses componentes.
- **Estrutura Modular de Blockchain**: As appchains construídas com Tanssi podem usar uma estrutura de blockchain modular chamada [Substrate](https://docs.polkadot.com/develop/parachains/intro-polkadot-sdk/){target=\_blank}, que permite que os desenvolvedores criem de forma rápida e fácil blockchains otimizadas e personalizáveis para qualquer caso de uso. Tanssi lida com a maioria das complexidades de infraestrutura, permitindo que os desenvolvedores se concentrem na lógica personalizada de sua appchain.
Em resumo, as appchains implantadas por meio da Tanssi são soluções soberanas de Camada 1 projetadas para serem altamente modulares e interconectadas, com foco na simplificação do processo de implantação e no desenvolvimento da personalização da própria appchain. Isso capacita os desenvolvedores a levar seus aplicativos blockchain ao mercado mais rápido, com segurança e com maior potencial de integração e interação nos ecossistemas blockchain mais amplos.
### Principais Aspectos da Tanssi {: #tanssi-key-aspects }
A tabela a seguir resume os principais benefícios que Tanssi traz para seu projeto:
| Aspecto | A solução Tanssi |
|--------------------------|-----------------------------------------------------------------------------------------------------------------------------------|
| Tempo de implantação | - Minutos para implantar
- Tempo mais rápido de lançamento no mercado |
| Produção de bloco | - Sequenciamento como serviço
- Conjunto descentralizado de Sequencers por projeto |
| Segurança | - Segurança de nível Ethereum desde o início |
| Finalidade/Liquidação | - Determinístico
- Finalidade em segundos |
| Custo | - Título de registro + Template de pagamento conforme o uso |
| Personalização | - Escolha o mecanismo de governança que melhor se adapta ao seu projeto
- Estrutura modular
- Personalização completa do Runtime
|
| Integrações e ferramentas | - Ferramentas essenciais disponíveis desde o início |
## Arquitetura Geral da Tanssi e Appchains powered by Tanssi {: #tanssi-architecture }
Como discutido anteriormente, as appchains implantadas por meio da Tanssi são blockchains soberanas e personalizáveis que, entre outros recursos, aproveitam o sequenciamento como serviço e herdam a finalidade do bloco de um provedor de segurança externo.
Uma visão geral de alto nível da arquitetura é apresentada abaixo, apresentando [Symbiotic](https://symbiotic.fi/){target=\_blank} como o provedor de segurança.
O protocolo Tanssi gerencia e orquestra um conjunto descentralizado de Sequencers atribuídos a fornecer serviços de produção de blocos para appchains powered by Tanssi. Os Sequencers executam transações e as incluem em blocos, que os operators do provedor de segurança prosseguem para validar. O protocolo de restaking da Symbiotic permite que seus operators ofereçam segurança econômica de nível Ethereum. O mecanismo de como isso funciona é explicado em dois artigos separados: [Serviços de Produção de Blocos](/pt/learn/tanssi/network-services/block-production/){target=\_blank} e [Ethereum com Symbiotic](/pt/learn/tanssi/external-security-providers/symbiotic/){target=\_blank}.
Embora os Sequencers que fornecem serviços de produção de blocos sejam rotacionados e realocados para uma appchain diferente a cada mudança de sessão, cada appchain terá seu próprio conjunto de Preservadores de Dados executando nós de arquivo completos, garantindo a disponibilidade de dados. Esses Preservadores de Dados fornecerão a infraestrutura RPC para aplicativos e usuários que interagem com appchains powered by Tanssi.
## O Que Vem a Seguir? {: #whats-next }
- Vá para o [Tanssi dApp](https://apps.tanssi.network){target=\_blank} e lance sua appchain.
- Interaja com uma appchain powered by Tanssi ao vivo: a [Tanssi Demo EVM appchain](/pt/builders/tanssi-network/testnet/demo-evm-network/){target=\_blank}.
--- END CONTENT ---
Doc-Content: https://docs.tanssi.network/pt/learn/tanssi/tanssi-ethereum-bridge/
--- BEGIN CONTENT ---
---
title: Bridge Tanssi-Ethereum
description: Descubra como a bridge Tanssi permite interoperabilidade segura e sem confiança, facilitando transferências de ativos e mensagens entre Tanssi e Ethereum.
icon: octicons-link-24
categories: Basics
---
# Bridge Tanssi-Ethereum {: #tanssi-ethereum-bridge }
## Introdução {: #introduction }
Blockchains tradicionais frequentemente criam silos, limitando a interoperabilidade de ativos e funcionalidades. A bridge Tanssi-Ethereum supera essas limitações ao permitir operações multichain contínuas que beneficiam ambos os ecossistemas.
A bridge é mais do que uma troca de ativos. É um protocolo seguro e padronizado para interação direta entre cadeias, sem intermediários centralizados. Seu design sem confiança evita os riscos de pontos centrais de falha que muitas outras pontes enfrentam.
Este artigo apresenta a bridge Tanssi-Ethereum como uma camada fundamental de interoperabilidade entre as duas redes. Você aprenderá como ela funciona, incluindo sua arquitetura, gestão de operators, Template econômico, mecanismos de slashing e transferências de ativos.
Você também conhecerá as camadas de consenso que protegem a comunicação ([BEEFY](https://docs.tanssi.network/learn/tanssi/){target=\_blank} em [Tanssi](/pt/learn/tanssi/){target=\_blank} e a [Beacon Chain do Ethereum](https://ethereum.org/roadmap/beacon-chain/){target=\_blank}), além dos papéis de provers, verifiers e relayers, oferecendo uma visão clara de como ativos e mensagens se movem com segurança entre Tanssi e Ethereum.
## Funções Principais {: #core-functions }
A bridge facilita várias operações críticas entre Tanssi e Ethereum:
- **Gestão de Operators** - mantém informações de stake de operators no Ethereum via o protocolo [Symbiotic](/pt/learn/tanssi/external-security-providers/symbiotic/#tanssi-symbiotic){target=\_blank}, fornecendo esses dados à Tanssi para selecionar operators ativos, descentralizados e economicamente alinhados a cada era
- **Operações Econômicas** - distribui [recompensas](/pt/learn/tanssi/external-security-providers/symbiotic/#rewards){target=\_blank} da Tanssi para stakers e operators no Ethereum
- **Slashing** - processa [solicitações de slashing](/pt/learn/tanssi/external-security-providers/symbiotic/#slashing){target=\_blank} da Tanssi para o Ethereum quando operators violam as regras do protocolo
- **Transferência de Ativos** - permite transferências bilaterais e sem confiança de ativos entre Tanssi e Ethereum, aumentando a liquidez.
Essa interoperabilidade amplia o potencial de aplicações descentralizadas e melhora significativamente a liquidez e a usabilidade de ativos em blockchain.
## Arquitetura da Bridge {: #bridge-architecture }
Entender a funcionalidade de consenso da bridge requer examinar seus componentes principais: provers, verifiers e relayers. Provers geram provas criptográficas, verifiers as validam e relayers transportam dados entre as cadeias.
Os provers incluem o módulo [BEEFY](https://docs.tanssi.network/learn/tanssi/){target=\_blank} da Tanssi e o consenso da [Beacon Chain do Ethereum](https://ethereum.org/roadmap/beacon-chain/){target=\_blank}. Eles produzem dados de consenso transmitidos por relayers especializados.
Cada cadeia executa um [light client](https://ethereum.org/developers/docs/nodes-and-clients/light-clients/){target=\_blank} da outra, atuando como verificador on-chain da legitimidade dos dados. Por exemplo, quando o Tanssi envia uma mensagem ao Ethereum, ele gera provas compactas de eventos ou mudanças de estado baseadas em seu consenso. O light client do Ethereum verifica essas provas antes de agir. Esse método eficiente evita processar todo o estado da cadeia de origem, confiando em vez disso na verificação de provas criptográficas concisas.
### Consenso de Tanssi para Ethereum {: #tanssi-ethereum-consensus }
BEEFY (Bridge Efficiency Enabling Finality Yielder) é o protocolo de consenso da Tanssi, atuando como prover. Ele foi projetado para bridge sem confiança e eficiente para cadeias como o Ethereum, que não são nativamente construídas para interoperabilidade.
```mermaid
sequenceDiagram
%%{init: {'sequence': {'mirrorActors': false}}}%%
participant Tanssi_Pallet as Tanssi
Pallet BEEFY (prover)
participant Beefy_Relayer as Relayer
(Beefy)
participant Eth_BeefyClient as Ethereum
Cliente BEEFY (verifier)
Tanssi_Pallet->>Beefy_Relayer: Gerar compromisso BEEFY
activate Beefy_Relayer
Beefy_Relayer->>Eth_BeefyClient: Enviar compromisso/prova
deactivate Beefy_Relayer
activate Eth_BeefyClient
Eth_BeefyClient->>Eth_BeefyClient: Verificar compromisso
deactivate Eth_BeefyClient
```
### Consenso de Ethereum para Tanssi {: #ethereum-tanssi-consensus }
Para a bridge de Ethereum para Tanssi, o consenso da Beacon Chain do Ethereum é o prover. Ele fornece ao light client on-chain da Tanssi a prova do estado finalizado do Ethereum, incluindo eventos ou mensagens destinadas à Tanssi.
```mermaid
sequenceDiagram
%%{init: {'sequence': {'mirrorActors': false}}}%%
participant Eth_BeaconCons as Ethereum
Consenso da Beacon Chain (Prover)
participant Beacon_Relayer as Relayer
(Beacon)
participant Tanssi_EthClient as Tanssi
Cliente Light de Ethereum (verifier)
Eth_BeaconCons->>Beacon_Relayer: Atualização da Beacon chain (Header/Proof)
activate Beacon_Relayer
Beacon_Relayer->>Tanssi_EthClient: Enviar atualização/prova
deactivate Beacon_Relayer
activate Tanssi_EthClient
Tanssi_EthClient->>Tanssi_EthClient: Verificar atualização/prova
deactivate Tanssi_EthClient
```
Do ponto de vista das mensagens, a bridge usa sua camada de verificação de consenso para comunicação multichain segura. Relayers dedicados transportam mensagens: o Execution Relay para Ethereum → Tanssi e o Tanssi Relay para Tanssi → Ethereum.
Relayers são stateless e apenas submetem provas. Eles não podem forjar mensagens ou roubar fundos, pois o mecanismo de consenso revalida cada prova on-chain. Vários relayers em paralelo melhoram a responsividade sem centralizar poder.
O contrato `Gateway` do Ethereum é o ponto central de mensagens. Ele recebe mensagens da Tanssi via relayers, valida-as usando provas de consenso e executa operações como cunhagem/desbloqueio de tokens ou chamadas de contratos inteligentes.
### Mensagens de Entrada de Ethereum para Tanssi {: #ethereum-tanssi-messages }
Esta seção descreve mensagens de Ethereum para Tanssi, usando o consenso da Beacon Chain do Ethereum para provas e um Execution Relay (ou Beacon Relay).
```mermaid
sequenceDiagram
%%{init: {'sequence': {'mirrorActors': false}}}%%
participant Eth_Gateway as Ethereum
Contrato Gateway
participant Exec_Relay as Relayer
(Execution Relay)
participant Tanssi_InQueue as Tanssi
Fila de Entrada
Note over Eth_Gateway: Mensagem pronta / Evento ocorre
Eth_Gateway->>Exec_Relay: Mensagem + Prova
activate Exec_Relay
Exec_Relay->>Tanssi_InQueue: Submeter mensagem/prova
deactivate Exec_Relay
activate Tanssi_InQueue
Tanssi_InQueue->>Tanssi_InQueue: Processar mensagem de entrada
deactivate Tanssi_InQueue
```
### Mensagens de Saída de Tanssi para Ethereum {: #tanssi-ethereum-messages }
Esta seção descreve mensagens de Tanssi para Ethereum, usando o consenso BEEFY para provar o estado da Tanssi e um Tanssi Relay para a transmissão.
```mermaid
sequenceDiagram
%%{init: {'sequence': {'mirrorActors': false}}}%%
participant Tanssi_OutQueue as Tanssi
Fila de Saída
participant Para_Relay as Relayer
(Tanssi Relay)
participant Eth_Gateway as Ethereum
Contrato Gateway
Note over Tanssi_OutQueue: Mensagem pronta / Prova confirmada
Tanssi_OutQueue->>Para_Relay: Mensagem + Prova
activate Para_Relay
Para_Relay->>Eth_Gateway: Submeter mensagem/prova
deactivate Para_Relay
activate Eth_Gateway
Eth_Gateway->>Eth_Gateway: Processar mensagem de saída
deactivate Eth_Gateway
```
O `Gateway` gerencia as comunicações de saída do Ethereum. Para transferências entre cadeias, ele registra um evento, bloqueia tokens se necessário e empacota os dados para envio à Tanssi. O Tanssi usa duas filas para processar mensagens com eficiência.
A `Fila de Saída` lida com mensagens para o Ethereum. Ela as agrupa e adiciona uma [raiz de Merkle](https://en.wikipedia.org/wiki/Merkle_tree){target=\_blank} (compromisso criptográfico) a cada cabeçalho de bloco. Isso permite que o light client do Ethereum verifique a inclusão de mensagens usando provas de consenso de forma eficiente.
A `Fila de Entrada` processa mensagens vindas do Ethereum. Ela recebe e verifica provas de eventos do Ethereum por meio do light client de Ethereum on-chain da Tanssi. Eventos verificados tornam-se instruções internas na Tanssi. Essa arquitetura em camadas, protegida por consenso, garante interações sem confiança entre cadeias.
## Fluxo de Transferência de Tokens {: #token-transfers-flow }
Esta seção explica como a bridge move ativos e mensagens. Ela envolve o bloqueio/cunhagem de ativos em uma cadeia e uma ação complementar na outra, protegida por provas verificadas. A seguir, são descritas as sequências típicas de transferência.
1. **Início (Cadeia de Origem)** - o usuário inicia a transferência de ativos
2. **Prova via Relay** - relayers off-chain coletam o evento e enviam provas criptográficas para a cadeia de destino
3. **Verificação (Cadeia de Destino)** - light clients on-chain verificam de forma independente as provas enviadas
4. **Execução** - após verificação bem-sucedida, tokens são cunhados/desbloqueados na cadeia de destino
### Transferência de Ethereum para Tanssi
Esta seção detalha a movimentação de ativos do Ethereum para a Tanssi (como ativos derivativos).
1. **Bloquear no Ethereum** - um usuário deposita ativos no contrato da Bridge do Ethereum. O contrato bloqueia os tokens e emite um evento de depósito
2. **Enviar Prova à Tanssi** - um relayer off-chain detecta o evento finalizado, cria um pacote de prova (incluindo o cabeçalho do bloco do Ethereum e a prova de Merkle do depósito) e o envia para a `Fila de Entrada` da Bridge da Tanssi
3. **Verificar na Tanssi** - o módulo `EthereumClient` da Bridge da Tanssi (um light client on-chain) recebe a prova da `Fila de Entrada`. Ele verifica a finalização/validade do cabeçalho do bloco do Ethereum e a autenticidade da prova de Merkle
4. **Cunhar na Tanssi** - após a verificação bem-sucedida pelo `EthereumClient`, a `Fila de Entrada` é notificada e cunha o ativo correspondente na Tanssi
```mermaid
sequenceDiagram
%%{init: {'sequence': {'mirrorActors': false}}}%%
participant User
participant EBridge as Contrato da Bridge
no Ethereum
participant Relayer
participant TBP as Bridge da Tanssi
(Fila de Entrada + Cliente ETH)
participant TAH as Tanssi
User->>EBridge: 1. Depositar ativo
activate EBridge
Note over EBridge: Bloquear tokens e emitir evento
deactivate EBridge
Relayer->>Relayer: Observar evento no Ethereum
Relayer->>TBP: 2. Enviar cabeçalho + prova de Merkle
activate TBP
Note over TBP: Receber prova (Fila de Entrada)
TBP->>TBP: 3. Verificar prova (Pallet EthereumClient)
TBP->>TAH: Enviar solicitação de cunhagem
deactivate TBP
activate TAH
TAH->>TAH: 4. Cunhar ativo
TAH-->>User: (Ativo aparece na conta do destinatário)
deactivate TAH
```
### Transferência de Tanssi para Ethereum
Este fluxo descreve o processo inverso, movendo ativos da Tanssi para o Ethereum.
1. **Iniciar e Confirmar na Tanssi** - o usuário inicia uma transferência na Tanssi. Uma mensagem com os detalhes da transferência vai para a `Fila de Saída` da Bridge. A fila processa, agrupa o payload e confirma sua raiz de Merkle no cabeçalho do bloco da Tanssi, representando todas as mensagens de saída nesse bloco
2. **Enviar Prova ao Ethereum** - um relayer off-chain monitora o Tanssi em busca de blocos finalizados com raízes de Merkle da `Fila de Saída`. Ele obtém as provas: um compromisso BEEFY (declaração assinada de cabeçalhos de bloco finalizados da Tanssi) e uma prova de Merkle do payload da transferência do usuário sob a raiz confirmada
3. **Submeter Compromisso no Ethereum** - o relayer envia o compromisso BEEFY e a prova de Merkle para o contrato `Gateway` do Ethereum
4. **Verificar no Ethereum** - o contrato Beefy Client do Ethereum (light client on-chain da Tanssi) recebe o compromisso BEEFY do `Gateway` e verifica sua validade (incluindo assinaturas)
5. **Validar Payload** - após a verificação do compromisso, o `Gateway` valida a prova de Merkle do payload do usuário
6. **Executar no Ethereum** - com ambas as provas verificadas, o contrato `Gateway` executa a ação, normalmente liberando ativos bloqueados pelo contrato principal da Bridge para o destinatário ou executando uma chamada para o contrato-alvo no Ethereum
O diagrama a seguir ilustra a fase de início e confirmação do processo de transferência de ativos na Tanssi.
```mermaid
sequenceDiagram
%%{init: {'sequence': {'mirrorActors': false}}}%%
participant User
participant TAH as Tanssi
participant TBP as Bridge da Tanssi
(Fila de Saída)
participant Relayer
User->>TAH: 1. Iniciar transferência e depositar ativo
activate TAH
TAH->>TBP: Enviar mensagem para a Fila de Saída
deactivate TAH
activate TBP
Note over TBP: Processar mensagem, agrupar e
confirmar raiz de Merkle no cabeçalho da Tanssi
deactivate TBP
Relayer->>Relayer: 2. Observar cabeçalho da Tanssi /
compromisso BEEFY e obter prova
Note over Relayer: O relayer agora está pronto para interagir
com o Ethereum com base nos dados observados.
```
O diagrama seguinte detalha as etapas de relay, verificação e execução no lado do Ethereum para a transferência de ativos.
```mermaid
sequenceDiagram
%%{init: {'sequence': {'mirrorActors': false}}}%%
participant Relayer
participant EGateway as Contrato Gateway
do Ethereum
participant EBeefy as Contrato Beefy Client
do Ethereum
participant EBridge as Contrato da Bridge
do Ethereum
participant User
Relayer->>EGateway: 3. Submeter compromisso BEEFY + prova de Merkle
activate EGateway
EGateway->>EBeefy: 4. Verificar compromisso BEEFY
activate EBeefy
EBeefy-->>EGateway: Verificação OK
deactivate EBeefy
EGateway->>EGateway: 5. Verificar prova de Merkle do payload
Note over EGateway: Prova validada
EGateway->>EBridge: 6. Executar: desbloquear tokens / chamar contrato-alvo
activate EBridge
Note over EBridge: Ativos transferidos ou
chamada ao contrato-alvo executada
EBridge-->>User: (Tokens recebidos / chamada executada)
deactivate EBridge
deactivate EGateway
```
--- END CONTENT ---
Doc-Content: https://docs.tanssi.network/builders/account-management/identity/
--- BEGIN CONTENT ---
---
title: Set an Account Identity
description: Follow these instructions to establish an identity, including a display name so that you can be more easily recognizable on the Tanssi orchestrator chain.
icon: octicons-person-24
categories: Basics, Appchain
---
# Set Up an On-Chain Identity
## Introduction {: #introduction }
The [Substrate](/learn/framework/overview/#substrate-framework){target=\_blank} Identity [module](/learn/framework/modules/){target=\_blank} is an out-of-the-box solution for adding personal information to your on-chain account. Establishing an identity makes it easier for your account to be recognized by others, as your display name will automatically populate when someone pastes your address into a field on the [developer portal](https://polkadot.js.org/apps/?rpc=wss://{{ networks.mainnet.dns_name }}#/accounts){target=\_blank}.
The identity you configure goes beyond a simple display name. Personal information can include default fields such as your legal name, display name, website, Twitter handle, Discord, and Riot (now known as Element) name. You can also use custom fields to include any other relevant information.
This guide will demonstrate setting up an identity with a display name and additional parameters, enhancing your visibility and recognizability.
## General Definitions {: #general-definitions }
To store your information on-chain, you must bond some funds, which will eventually be returned once the identity has been cleared. There are two categories of fields: default and custom. A basic deposit amount is reserved upon identity creation, and a storage deposit is required for each additional byte of data stored on-chain.
- **Default fields include** - your legal name, display name, website, Twitter handle, Discord, Riot (now known as Element) name
- **Custom fields include** - any other relevant information
- **Subaccounts** - You can link subaccounts underneath a primary account. As an example, a sequencer service that's running multiple different sequencer nodes can establish subaccounts to demonstrate an official link between the nodes
=== "Tanssi MainNet"
| Variable | Definition | Value |
|:---------------------:|:--------------------------------------------------------------------------------:|:------------------------------------------------------------------------------------:|
| Basic deposit | The amount held on deposit for setting an identity | {{ networks.mainnet.identity.basic_deposit }} {{ networks.mainnet.token_symbol }} |
| Deposit per byte | The amount held on deposit per byte of on-chain storage used setting an identity | {{ networks.mainnet.identity.per_byte_deposit }} {{ networks.mainnet.token_symbol }} |
| Max additional fields | Maximum number of additional fields that may be stored in an ID | {{ networks.mainnet.identity.max_fields }} |
| Max subaccounts | Maximum number of subaccounts that can be defined under an account identity | {{ networks.mainnet.identity.max_subaccounts }} |
=== "Dancelight TestNet"
| Variable | Definition | Value |
|:---------------------:|:--------------------------------------------------------------------------------:|:------------------------------------------------------------------------------------------:|
| Basic deposit | The amount held on deposit for setting an identity | {{ networks.dancelight.identity.basic_deposit }} {{ networks.dancelight.token_symbol }} |
| Deposit per byte | The amount held on deposit per byte of on-chain storage used setting an identity | {{ networks.dancelight.identity.per_byte_deposit }} {{ networks.dancelight.token_symbol }} |
| Max additional fields | Maximum number of additional fields that may be stored in an ID | {{ networks.dancelight.identity.max_fields }} |
| Max subaccounts | Maximum number of subaccounts that can be defined under an account identity | {{ networks.dancelight.identity.max_subaccounts }} |
## Checking Prerequisites { : #checking-prerequisites }
To follow along with this guide, you will need the following:
=== "Tanssi MainNet"
- The [developer portal](https://polkadot.js.org/apps/?rpc=wss://{{ networks.mainnet.dns_name }}#/accounts){target=\_blank} open and connected to Tanssi MainNet.
- At least one account funded with `{{ networks.mainnet.token_symbol }}` tokens.
=== "Dancelight TestNet"
- The [developer portal](https://polkadot.js.org/apps/?rpc=wss://{{ networks.dancelight.dns_name }}#/accounts){target=\_blank} open and connected to [Dancelight](/builders/tanssi-network/testnet/dancelight/){target=\_blank}.
- At least one account funded with `{{ networks.dancelight.token_symbol }}` tokens.
If you need help importing your accounts into the developer portal, please check out the [Connecting to the developer portal](/builders/toolkit/substrate-api/wallets/talisman/#connecting-to-polkadotjs){target=\_blank} guide.
## Get Started {: #get-started }
Depending on the information to be included, there are a couple of different ways to set and clear an identity using the developer portal. If you intend to register your identity using only the default fields, you can follow the instructions for [Managing an Identity via the Accounts](#manage-via-accounts) page. **This is the recommended way to set and manage your identity**.
If you want to add custom fields beyond the default fields, follow the instructions for [Managing an Identity via the Extrinsics](#manage-via-extrinsics) page.
!!! note
Please note that using the **Accounts** page on the developer portal is recommended to manage your identity as it provides an easy-to-use interface that enforces character limits. If you use the **Extrinsics** page, please be aware that your input for each field (i.e., name, email, etc.) must be 32 characters or less; otherwise, your information will be cut off.
## Manage an Identity via Accounts {: #manage-via-accounts }
### Set an Identity {: #set-identity-accounts }
To get started with setting an identity using the Accounts page, head to the [**Accounts** tab](https://polkadot.js.org/apps/?rpc=wss://{{ networks.mainnet.dns_name }}#/accounts){target=\_blank} of the developer portal.
You should already have an account connected, so you can click on your account name to verify and note your balances. After you send the transaction to set an identity, the deposit(s) you submitted will be moved from your transferable balance to your reserved balance.
To set your identity, you'll need to:
1. Click on the three vertical dots next to the account you would like to set an identity for
2. A menu will pop up. Click **Set on-chain identity**
Next, the menu to register and set your identity will pop up, and you can start filling in your information. You are not required to enter information for every single field; you can choose to fill in just one field or all of them; it's up to you. For this example:
1. Set your display name
2. Click on the **include field** toggle for email and then enter in your email
3. Click on the **include field** toggle for web and then enter in your website URL
4. Click on the **include field** toggle for Twitter and then enter in your Twitter handle
5. Review the prior data fields and click **Set Identity**
You will then be prompted to sign the transaction. If everything looks good, sign it.
You should see status notifications pop up in the top right-hand corner. Once the transaction has been confirmed, you can click on your account name again, and the panel will slide out on the right side of the page. Your balances will have changed, and you'll also see your new identity information.
If the identity information matches what you entered, you've successfully set an identity!
Once you clear your identity, the deposit in your reserved balance will get transferred back to your transferable balance. If you need to change your identity, you can go through the process of setting your identity again. Please note that you must ensure all fields are re-entered, even if only one field needs to be changed, or they will be overwritten. You will not need to pay another deposit unless custom fields are used, but you will need to pay gas fees.
## Manage an Identity via Extrinsics {: #manage-via-extrinsics }
### Set an Identity {: #set-identity-extrinsics }
To register an identity using the extrinsics page, navigate to the [**Extrinsics** page](https://polkadot.js.org/apps/?rpc=wss://{{ networks.mainnet.dns_name }}#/extrinsics){target=\_blank} of the developer portal. Please ensure your input does not exceed 32 characters for each identity field. To complete your identity, take the following steps:
1. Select your account
2. Select identity from the **submit the following extrinsic** dropdown
3. Then select the **setIdentity(info)** function
4. Select **Raw** as the data format to enter your **Display Name**
5. Enter the data for **Display** in the selected format
6. Select **Raw** as the data format to enter your web address
7. Enter your website URL in the selected format
8. Select **Raw** as the data format to enter your email
9. Enter your email address in the selected format
10. Select **Raw** as the data format to enter your Twitter handle
11. Enter your Twitter in the selected format. Enter the username only, starting with the `@` symbol
12. Review the prepared fields and press **Submit Transaction**
Optionally, if you would like to enter custom fields, take the following steps:
1. Scroll to the top and click on **Add item**
2. Two fields will appear: the first for the field name and the second for the value. Select **Raw** as the data format to enter the field name
3. Enter the field name in the specified format
4. Select **Raw** as the data format to enter the custom value
5. Enter the custom value in the specified format
Finally, once all of your identity information has been added, you can scroll to the bottom of the page and click **Submit Transaction**.
You will then be prompted to sign the transaction. Remember, an additional deposit is required for each additional custom field. If everything looks good, sign the transaction.
You should see status notifications pop up in the top right-hand corner confirming the transaction. If successful, you've set an identity! Congratulations! To ensure everything went through and your identity information looks good, you can verify your identity.
### Confirm an Identity {: #confirm-identity-extrinsics }
To verify the addition of your identity information, you can click on the **Developer** tab and then navigate to [**Chain state**](https://polkadot.js.org/apps/?rpc=wss://{{ networks.mainnet.dns_name }}#/chainstate){target=\_blank}.
On the **Chain State** page, make sure **Storage** is selected. Then you can start to request your identity information:
1. Set **selected state query** to **identity**
2. Select the **identityOf(AccountId)** function
3. Select your account
4. Click the **+** button to get your identity information
You can see now that you've successfully set an identity! Once you clear your identity, the deposit in your reserved balance will get transferred back to your transferable balance. If you need to change your identity, you can go through the process of setting your identity again. Please note that you must ensure all fields are re-entered, even if only one field needs to be changed, or they will be overwritten. You will not need to pay another deposit unless custom fields are used, but you will need to pay gas fees.
## Clear an Identity {: #confirm-identity-extrinsics }
To clear your identity, take the following steps from **Extrinsics** tab of the developer portal:
1. Select your account from the **using the selected account** dropdown
2. Select **identity** from the **submit the following extrinsic** dropdown
3. Then select the **clearIdentity()** function
4. Click **Submit Transaction**
You will then be prompted to sign the transaction. If everything looks good, sign it. You should see status notifications in the top right-hand corner confirming the transaction.
To confirm that your identity information has been successfully removed, revisit the steps outlined in the [Confirm an Identity section](#confirm-identity-extrinsics). This time, instead of displaying your identity details, the response should indicate **none**, confirming that no identity information is currently linked to your account. Additionally, when you check your balances, you will find that the deposit initially made for setting your identity has been credited back to your transferable balance. This completes the process of clearing your identity.
--- END CONTENT ---
Doc-Content: https://docs.tanssi.network/builders/account-management/proxy-accounts/
--- BEGIN CONTENT ---
---
title: Set Up and Manage Proxy Accounts
description: Follow these step-by-step instructions to learn how proxies work and how to create, view, update, and remove proxy accounts from primary (proxied) accounts.
icon: octicons-shield-lock-24
categories: Basics, Appchain
---
# Proxy Accounts
## Introduction {: #introduction }
Proxy accounts can be set up to perform a limited number of actions on behalf of primary accounts and are helpful for keeping the underlying accounts safe. Your proxy account can act as a "hot wallet" to interact with the network on behalf of your "cold wallet" account. For added safety, you can regularly rotate the proxy account.
Proxy accounts can also help you implement the principle of least privilege for access control. For example, if you have multiple team members, you can give them the minimum level of access required to carry out their duties via a specific type of proxy account.
This tutorial will walk you through configuring a proxy account on Dancelight, the Tanssi TestNet, specifically for balance transfers. Then, it will demonstrate performing a balance transfer using the newly created proxy.
## Checking Prerequisites {: #checking-prerequisites }
To follow along with this tutorial, you will need to have:
- [Polkadot.js Apps](https://polkadot.js.org/apps/?rpc=wss://{{ networks.dancelight.dns_name }}#/accounts){target=\_blank} open and connected to [Dancelight](/builders/tanssi-network/testnet/dancelight/){target=\_blank}.
- Create or have two accounts accessible on the developer portal.
- At least one of the accounts will need to be funded with `{{ networks.dancelight.token_symbol }}` tokens.
If you need help importing your accounts into Polkadot.js Apps, please check out the [Connecting to Polkadot.js](/builders/toolkit/substrate-api/wallets/talisman/#connecting-to-polkadotjs){target=\_blank} guide.
## General Definitions {: #general-definitions }
When setting up a proxy account, a bond for the proxy is taken out of your free balance and moved to your reserved balance. The bond is required as adding a proxy requires on-chain storage space, and it is recalculated for each proxy you add or remove. The bond is returned to your free balance after all proxies are removed from your account.
The deposit is calculated based on a deposit base and a deposit factor:
- **Deposit base** - the amount to be reserved for an account to have a proxy list.
- **Deposit factor** - the additional amount to be reserved for every proxy the primary account has.
The equation for calculating the deposit is:
```text
deposit base + deposit factor * number of proxies
```
You can find each of the relevant variables below.
=== "Tanssi MainNet"
| Variable | Value |
|:--------------:|:--------------------------------------------------------------------------------:|
| Deposit base | {{ networks.mainnet.proxy.deposit_base }} {{ networks.mainnet.token_symbol }} |
| Deposit factor | {{ networks.mainnet.proxy.deposit_factor }} {{ networks.mainnet.token_symbol }} |
| Max proxies | {{ networks.mainnet.proxy.max_proxies }} proxies |
=== "Dancelight TestNet"
| Variable | Value |
|:--------------:|:--------------------------------------------------------------------------------------:|
| Deposit base | {{ networks.dancelight.proxy.deposit_base }} {{ networks.dancelight.token_symbol }} |
| Deposit factor | {{ networks.dancelight.proxy.deposit_factor }} {{ networks.dancelight.token_symbol }} |
| Max proxies | {{ networks.dancelight.proxy.max_proxies }} proxies |
## Proxy Types {: #proxy-types }
When creating a proxy account, you must choose a type of proxy that will define how the proxy can be used. The available options are:
- **`Any`** - allows the proxy account to use any function supported by the proxy pallet. There is no filtering of calls.
- **`NonTransfer`** - this type of proxy account is allowed to submit any type of transaction with the exception of balance transfers.
- **`Balances`** - allows the proxy account to only make transactions related to sending funds.
- **`Governance`** - allows the proxy account to only make transactions related to the governance pallet, such as voting or creating democracy proposals. Note, governance is not yet enabled on Tanssi. You can create governance proxy accounts but they will not be able to take any actions until governance is enabled.
- **`Registrar`** - allows the proxy account to only make transactions related to the registrar pallet.
- **`SudoRegistrar`** - allows the proxy account to only make transactions related to the registrar pallet that need to be called by Sudo.
- **`CancelProxy`** - allows the proxy account to reject and remove any announced proxy calls.
- **`Staking`** - allows the proxy account to perform staking-related transactions, such as sequencer and `session()` functions.
- **`SessionKeyManagement`** - allows the proxy account to make key management related transactions included in the session pallet.
For this guide, you will be setting up a proxy account using the balances proxy type. Since this type enables the proxy to spend funds on behalf of the primary account, you should exercise caution and only provide access to accounts you trust. The proxy will have access to transfer all of the funds within the primary account, and if not trusted, the proxy could drain the primary account. Ensure that you maintain oversight of your proxy accounts and remove any proxies that are no longer needed.
## Creating a Proxy Account {: #creating-a-proxy-account }
There are a couple of ways you can create proxy accounts in [Polkadot.js Apps](https://polkadot.js.org/apps/?rpc=wss://{{ networks.dancelight.dns_name }}#/accounts){target=\_blank}, either from the **Extrinsics** page or the **Accounts** page. However, to create a time-delayed proxy, you will need to use the **Extrinsics** page. A time delay provides an additional layer of security to proxies by specifying a delay period based on the number of blocks. This will prevent the proxy account from executing a transaction until the delay period ends. The delay allows time for the primary account that controls the proxy to review pending transactions, potentially for malicious actions, and cancel if necessary before execution.
The following demo will showcase configuring a Balances proxy, which allows for transferring funds, making it perfect for demonstration purposes. After configuring your Balances proxy you can try transferring funds from the primary account via proxy.
To get started creating your proxy account, head to the **Developer** tab and select [**Extrinsics**](https://polkadot.js.org/apps/?rpc=wss://{{ networks.dancelight.dns_name }}#/extrinsics){target=\_blank} from the dropdown. Next, you will need to take the following steps:
1. Select the primary account.
2. From the **submit the following extrinsic** dropdown, select **proxy**.
3. Choose the **addProxy** extrinsic.
4. Choose **Id** from the **AccountIdLookupOf** dropdown.
5. Select the **delegate** account for the proxy.
6. From the **proxyType** dropdown, choose **Balances**.
7. Optionally, you can add a time delay using a specified number of blocks to add an additional layer of security for the primary account to review the pending transaction.
8. Click **Submit Transaction**.
You will then be prompted to authorize and sign the transaction. Click **Sign and Submit** to create the proxy relationship. Once the transaction has been successfully submitted, you will receive some notifications confirming the transaction.
As previously mentioned, you can also create a proxy from the **Accounts** page. To do so, navigate to the **Accounts** page and take the following steps:
1. Select the three vertical dots next to the primary account.
2. Select **Add proxy**.
!!! note
If the account already has a proxy, **Manage proxies** will be displayed as an option instead of **Add proxy**.
A pop-up will appear and you can enter in the required information, such as the proxied/primary account, the proxy account, and type of proxy to create a proxy account. First click **Add Proxy**.
Then, take the following steps:
1. Select the account you would like to set as a proxy.
2. Select the proxy type.
3. Click **Submit** and sign the transaction.
In the next section, you will learn how to verify that your proxy account was set up successfully.
## Verifying Your Proxy Account {: #verifying-your-proxy-account }
You can verify that your proxy account has been successfully set up in a couple of ways: either through the **Accounts** page or via the **Chain state** page.
To check your proxy accounts from the [**Chain state** page](https://polkadot.js.org/apps/?rpc=wss://{{ networks.dancelight.dns_name }}#/chainstate){target=\_blank}, you can take the following steps:
1. From the **selected state query** dropdown, select **proxy**.
2. Choose the **proxies** extrinsic.
3. Select your primary/proxied account.
4. Click on the **+** button to send the query.
The result will appear on the page showing you information about all of your proxies, including the delegate/proxy account address, the proxy type, the delay period if one was specified, and the total bond amount for all of your proxies in Planck.
You can also check your proxy accounts from the **Accounts** page. To do so, navigate to the **Accounts** page, and there should be a Proxy symbol next to the primary account. Hover over the icon and click on **Manage proxies** to review your proxies.
A pop-up will appear where you can see an overview of all of your proxy accounts.
## Executing a Proxy Transaction {: #executing-a-proxy-transaction }
Now that you have created a proxy account and verified that it was successfully set up, you can execute a transaction using the proxy account on behalf of the primary account.
To execute a transaction, you can navigate back to the [**Extrinsics** page](https://polkadot.js.org/apps/?rpc=wss://{{ networks.dancelight.dns_name }}#/extrinsics){target=\_blank} and take the following steps:
1. Select the proxy account to submit the transaction from the **using the select account** dropdown.
2. From the **submit the following extrinsic** menu, select **proxy**.
3. Choose the **proxy** extrinsic.
4. Choose **Id** from the **AccountIdLookupOf** dropdown.
5. Select the primary account from the **real** dropdown.
6. Select the **balances** call.
7. Choose the **transferKeepAlive** extrinsic.
8. Choose **Id** from the **AccountIdLookupOf** dropdown.
9. In the **dest** field, enter the address you would like to send funds to.
10. In the **value** field, enter the amount of {{ networks.dancelight.token_symbol }} tokens to send. For this example, you can send `2` {{ networks.dancelight.token_symbol }} tokens.
11. Click **Submit Transaction**.
A pop-up will appear for you to authorize and sign the transaction. Enter your password for the proxy account and click **Sign and Submit**.
If the transaction successfully went through, you should see a couple of notification pop-ups. If you head over to the **Accounts** page, you'll see that your primary account balance has decreased. If you check the account balance where you sent the funds, you'll notice the balance there has increased.
That's it! You've successfully executed a transaction using a proxy account on behalf of your primary account.
## Removing a Proxy Account {: #removing-a-proxy-account }
Similarly to adding a proxy account, there are a couple of ways that you can remove a proxy account, either from the **Extrinsics** page or the **Accounts** page. Regardless of which page you use, you can elect to remove a single proxy account or all proxies associated with your primary account.
To remove a proxy from the [**Extrinsics** page](https://polkadot.js.org/apps/?rpc=wss://{{ networks.dancelight.dns_name }}#/extrinsics){target=\_blank}, you can take the following steps:
1. From the **using the selected account** dropdown, select your primary account.
2. Then select **proxy**.
3. Choose **removeProxy** to remove a single proxy or **removeProxies** to remove all associated proxies.
4. Choose **Id** from the **AccountIdLookupOf** dropdown.
5. If removing a single proxy, enter the proxy account to remove in the **delegate** field.
6. Select the **proxyType** to remove, in this case choose **Balances**.
7. Optionally, select a delay period in block numbers.
8. Click **Submit Transaction**.
A pop-up will appear asking you to authorize and sign the transaction. You can sign and send the transaction from the primary or proxy account, but the call to remove the proxy must be sent from the primary account. Enter your password and click **Sign and Submit**.
To check that the proxy or proxy accounts have been removed, follow the steps in the [Verifying your Proxy Account](#verifying-your-proxy-account) section.
As previously mentioned, you can also remove a proxy from the **Accounts** page. To do so, on the **Accounts** page, select the three vertical dots next to the primary account and select **Manage Proxies**.
A pop-up will appear showing an overview of your proxy accounts. To remove all proxies, you can click on **Clear all**, then you will automatically be prompted to enter your password and submit the transaction. To remove a single proxy, take the following steps:
1. Click the **X** button next to the proxy to remove
2. Press **Submit**
On the transaction confirmation screen, take the following steps:
1. Ensure that you do not use a proxy for this call (as this example is a balances proxy, the call to remove the proxy needs to come from the primary account rather than the proxy account).
2. Enter your password for the respective account.
3. Press **Sign and Submit**.
Once the transaction has successfully been submitted, you can review your current proxies, or if you removed all proxies, you will notice the proxy icon is no longer being displayed next to the primary account. And that's it! You've successfully created a proxy, reviewed all proxy accounts associated with your primary account, executed a proxy transaction, and removed a proxy account!
{{ trans("disclaimer.third_party") }}
--- END CONTENT ---
Doc-Content: https://docs.tanssi.network/builders/build/templates/overview/
--- BEGIN CONTENT ---
---
title: Requirements and Features of Templates
description: Explore the foundational setup and key features included in each Tanssi template, designed to streamline the building and deployment of Tanssi networks.
icon: octicons-home-24
categories: Basics, Appchain
---
# Templates Overview {: #templates-overview }
## Introduction {: #introduction }
Networks deployed through Tanssi are fully customizable blockchains benefiting from a shared set of sequencers and the security of a provider of their choice. The templates presented in this article implement the necessary functionalities and configurations to support the Tanssi protocol, making development easier.
## Base Setup to Support the Tanssi Protocol {: #base-setup-supporting-tanssi }
Tanssi networks must implement the following modules to support the protocol and benefit safely from Tanssi's block production as a service:
- **Author Noting** - registers the set of sequencers assigned to the network by Tanssi
- **Author Inherent** - allows the sequencer authoring the block to include its identity to get validated and rewarded
If you don't include these modules in the Tanssi network's runtime, there won't be a method to confirm that the blocks are being generated by trustworthy sequencers designated by the Tanssi orchestrator. This could create a vulnerability for malicious actors to exploit and compromise the network. For more information about Tanssi's block production as a service please refer to the [Block Production Services](/learn/tanssi/network-services/block-production/){target=\_blank} article.
Besides block production, there are other essential aspects for any network covered in the templates, such as:
- **Consensus** - networks have the necessary functionality to allow the sequencers to produce blocks, gossip and validate them, and coordinate with the security provider to get notified about the block's finality
- **Networks Interoperability** - handles the ingestion and dispatch of incoming downward and lateral messages, allowing a Tanssi network to communicate and interoperate with the other chains within the ecosystem
- **Runtime Upgrades** - a runtime upgrade in a Tanssi network must be informed to the security provider's operators to allow them to check on the blocks produced by the sequencers of the Tanssi networks
## Included Modules {: #included-modules }
Besides the necessary modules to support the operation of a Tanssi network, many other modules provide functional behavior that the users can interact with.
These are some of the functional modules exposing a behavior to the users that are included in the templates and ready to use:
- **[Balances](https://paritytech.github.io/substrate/master/pallet_balances/index.html){target=\_blank}** - the Balances module provides functions for handling accounts and balances for the Tanssi network native currency
- **[Utility](https://paritytech.github.io/polkadot-sdk/master/pallet_utility/index.html){target=\_blank}** - the Utility module provides functions to execute multiple calls in a single dispatch. Besides batching transactions, this module also allows the execution of a call from an alternative signed origin
- **[Proxy](https://paritytech.github.io/polkadot-sdk/master/pallet_proxy/index.html){target=\_blank}** - the Proxy module provides functions to delegate to other accounts (proxies) the permission to dispatch calls from a proxied origin
- **[Maintenance Mode](https://github.com/moondance-labs/moonkit/blob/tanssi-polkadot-v1.3.0/pallets/maintenance-mode/src/lib.rs){target=\_blank}** - the Maintenance Mode module allows the Tanssi network to be set to a mode where it doesn't execute balance/asset transfers or other transactions. This could be useful when upgrading the runtime in an emergency, when executing large storage migrations, or when a security vulnerability is discovered
- **[Tx Pause](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/frame/tx-pause/src/lib.rs){target=\_blank}** - the Tx Pause module allows a valid origin (typically Root) to pause (and unpause) an entire module or a single transaction. A paused transaction (or all the transactions included in a paused module) will fail when called until it is unpaused. This module provides a higher degree of granularity compared to maintenance mode, making it particularly useful when a faulty or vulnerable transaction is identified in the runtime
- **[Multisig](https://github.com/paritytech/polkadot-sdk/blob/master/substrate/frame/multisig/src/lib.rs){target=\_blank}** - the Multisig module enables transaction dispatches that require -typically- more than one signature. A multisig transaction defines a set of authorized accounts and a threshold for its approval, requiring consensus among multiple parties
## Start Building {: #getting-started }
To start building on top of the provided templates, be it the [baseline Tanssi network template](/builders/build/templates/substrate/){target=\_blank} or the [baseline EVM (Ethereum Virtual Machine) template](/builders/build/templates/evm/){target=\_blank}, the recommended approach is to fork the [Tanssi repository](https://github.com/moondance-labs/tanssi){target=\_blank} and start adding [built-in modules](/builders/build/customize/adding-built-in-module/){target=\_blank} or [custom-made modules](/builders/build/customize/adding-custom-made-module/){target=\_blank} on top of the [latest release](https://github.com/moondance-labs/tanssi/releases/latest){target=\_blank} tag.
This approach comes with some advantages, such as:
- Building on top of the latest and stable release
- Get the Tanssi protocol already configured and included in the template runtime
- Keep your fork up-to-date by syncing with the Tanssi upstream repository
- Run the included tests, ensuring that block production on your Tanssi network works as intended
- Run a complete local environment with the included [Zombienet](https://paritytech.github.io/zombienet){target=\_blank} configuration
If the templates already cover your use case needs, or after building and testing your chain, you can continue with the [Deploy Your Network via the Tanssi DApp](/builders/deploy/dapp/){target=\_blank} article to know how to use the Tanssi dApp to register and get your chain up and running.
--- END CONTENT ---
Doc-Content: https://docs.tanssi.network/builders/interoperability/built-in-bridge/
--- BEGIN CONTENT ---
---
title: Using the Built-In Tanssi Bridge
description: Learn how to use the built-in Tanssi bridge that connects Tanssi and Ethereum to convert TANSSI tokens between their native form and ERC-20 and vice versa.
icon: octicons-arrow-switch-24
categories: Basics
---
# Using the Built-In Tanssi Bridge
## Introduction {: #introduction }
The Tanssi protocol orchestrates infrastructure components, allowing developers to launch their customized appchains in minutes and providing them with out-of-the-box Ethereum-grade economic security. To make the whole process easy for developers, a [top-of-class architecture](/learn/tanssi/overview/#tanssi-architecture){target=\_blank} was designed and implemented.
The [TANSSI token](/builders/tanssi-network/tanssi-token/){target=\_blank} is the engine that enables the integration of different infrastructural components with [external security providers](/learn/tanssi/external-security-providers/symbiotic/){target=\_blank} and aligns incentives across various actors, including token holders, node operators, and appchain builders. To serve different use cases, the token has two versions: the Tanssi network's native currency, TANSSI (Substrate), and its ERC-20 version, on Ethereum.
Users can convert from one version to the other of the token using a [Tanssi built-in trustless bridge](/learn/tanssi/tanssi-ethereum-bridge/){target=\_blank}.
In this guide, you'll learn how to move your assets from Tanssi to Ethereum and vice versa through a secure and user-friendly web interface available at the [Tanssi dApp](https://apps.tanssi.network/bridge){target=\_blank}, making cross-chain transfers accessible for everyone.
## Prerequisites {: #prerequisites }
Before using the Tanssi bridge, ensure you have:
For bridging from Tanssi to Ethereum:
- A [Substrate-compatible wallet](/builders/toolkit/substrate-api/wallets/){target=\_blank}, such as [Talisman](/builders/toolkit/substrate-api/wallets/talisman/){target=\_blank}.
- TANSSI (Substrate) balance to transfer and pay the bridging fees.
- The Ethereum-type destination account.
For bridging from Ethereum to Tanssi:
- An [Ethereum-compatible wallet](/builders/toolkit/ethereum-api/wallets/){target=\_blank}, such as [MetaMask](/builders/toolkit/ethereum-api/wallets/metamask/){target=\_blank}.
- TANSSI (ERC-20) balance to transfer.
- ETH balance to pay the bridging fees.
- The Substrate-type destination account.
## Bridging TANSSI Tokens to Ethereum {: #bridge-to-ethereum }
If you want to convert your TANSSI (Substrate) tokens to TANSSI (ERC-20) on Ethereum, head to the Tanssi dApp, open the [bridge section](https://apps.tanssi.network/bridge){target=\_blank}, and then follow these steps:
1. Select **Mainnet** from the **From** dropdown.
2. Click on **Connect Wallet**. A pop-up will appear, allowing you to select your preferred Substrate wallet and choose the corresponding account.
Now, with your wallet connected:
1. Select the destination account from the **Select recipient address** dropdown, or choose the **Enter a custom address** item and enter the account where you want to receive the ERC-20 tokens manually.
2. Enter the amount to bridge in the **Balance** field. The estimated bridge and transaction fees will be displayed along with the amount the destination account will receive.
3. Click on **Send** and sign the transaction.
And that's it! Your tokens will be bridged when the next session starts. You can see how much time remains in the current session in the progress bar.
!!! note
- You can easily add the TANSSI ERC-20 contract address to your wallet by clicking the **+** icon shown next to your balance.
- Fees to convert your TANSSI (Substrate) tokens to TANSSI (ERC-20) might fluctuate over time and must be paid using TANSSI.
## Bridging ERC-20 TANSSI to Tanssi Network {: #bridge-to-tanssi }
If you want to convert your TANSSI (ERC-20) tokens to TANSSI (Substrate) native on the Tanssi network, head to the Tanssi dApp, open the [bridge section](https://apps.tanssi.network/bridge){target=\_blank}, and then follow these steps:
1. Select **Ethereum** from the **From** dropdown.
2. Click on **Connect Wallet**, select your preferred Ethereum wallet, and choose the account.
Now, with your wallet connected:
1. Enter the Substrate destination account in the **Recipient** field.
2. Enter the amount to bridge in the **Balance** field. The estimated bridge and transaction fees will be displayed along with the amount the destination account will receive.
3. Click on **Send** and sign the transaction.
And that's it! Your tokens will be bridged when the next session starts. You can see how much time remains in the current session in the progress bar.
!!! note
Fees to convert your TANSSI (ERC-20) tokens to TANSSI (Substrate) native on the Tanssi network might fluctuate over time and must be paid using ETH.
--- END CONTENT ---
Doc-Content: https://docs.tanssi.network/builders/tanssi-network/tanssi-token/
--- BEGIN CONTENT ---
---
title: TANSSI Token
description: Learn about the two versions of the Tanssi token - the native Substrate token and the ERC-20 representation on Ethereum, and their utilities and use cases.
icon: octicons-ruby-24
categories: Basics
---
# TANSSI Token {: #tanssi-token }
## Introduction {: #introduction }
The Tanssi network token is the utility token that powers the Tanssi protocol. Considering [Tanssi's architecture](/learn/tanssi/overview/#tanssi-architecture){target=\_blank}, the token exists in two distinct yet interconnected representations: native substrate and Ethereum ERC-20. The two versions can be bridged between each other through the [Tanssi-Ethereum bridge](/learn/tanssi/tanssi-ethereum-bridge/){target=\_blank}.
In this guide, the token's utility and the differences between its two representations are covered, which is crucial for network operators, stakers, appchain managers, and general users who want to participate in the Tanssi ecosystem.
## Token Utility {: #token-utility }
Tanssi is a decentralized infrastructure protocol that makes deploying appchains with custom logic easy. It allows developers to focus on the use case instead of diverting time and energy to manage the [numerous components required](/learn/tanssi/overview/#what-tanssi-provides){target=\_blank} for a network to run smoothly.
Running a healthy decentralized protocol not only requires a robust governance mechanism to ensure that decisions are made transparently but also aligning incentives and coordinating among several ecosystem actors, including appchain developers, node operators, sequencer operators, data availability and RPC providers, as well as general users. The Tanssi token serves as the backbone, providing the economic mechanisms necessary to coordinate, incentivize proper behavior, and secure the entire ecosystem. It enables a verifiable and code-enforced protocol evolution through a fully on-chain decision-making process.
The token has several utilities:
- **On-chain governance**: token holders can use the token to propose and vote in governance decisions, such as software upgrades, how to spend treasury funds, change protocol rules, and more.
- **Appchain deployment**: use the token to register and launch your appchain in minutes.
- **Sequencing as a service payment**: use the token to keep your appchain live.
- **Sequencing and operator services rewarding**: get tokens as rewards for your nodes' services.
- **Staking on sequencers**: token holders can stake on sequencers, getting rewards with no risk of slashing.
- **Staking on operators**: token holders can stake on operators, getting rewards for their validation services.
- **Fees payment**: use the token to pay the fees for interacting with the Tanssi network.
!!! note
All transaction fees on Tanssi are paid using the token, with the full amount going directly to fund the protocol's treasury account. These funds can only be spent via governance.
## Token Representations {: #token-representations }
The Tanssi network is built using the Substrate framework, leveraging its modular architecture and high performance. Therefore, the native token is of a Substrate type. The protocol's minting and burning mechanisms happen on the Tanssi network side, or, in other words, happen on the Substrate token representation.
Additionally, the Tanssi protocol relies on [external security providers](/learn/tanssi/external-security-providers/){target=\_blank}, such as [Symbiotic](/learn/tanssi/external-security-providers/symbiotic/){target=\_blank}, to secure the ecosystem through restaked assets. This restaking mechanism is implemented on Ethereum; therefore, an ERC-20 version of the token also exists to cover user cases on the Ethereum side.
Leveraging Tanssi's [built-in bridging capabilities](/learn/tanssi/tanssi-ethereum-bridge/){target=\_blank}, the token can be converted to (and from) the ERC-20 representation on Ethereum. When the token is bridged to Ethereum, the tokens are locked in the bridge's sovereign account, and a message is sent to the Ethereum contract to mint the equivalent amount in ERC-20. This lock-and-mint mechanism ensures the ERC-20 version is created through a trustless bridging mechanism, maintaining a 1:1 relationship with the native token.
```mermaid
flowchart LR
subgraph Tanssi_Network ["Tanssi Network"]
Tanssi_Substrate["$TANSSI (Substrate)"]
Tanssi_Substrate_Utility["✓ On-chain governance
✓ Appchain deployment
✓ Sequencers rewarding
✓ Staking on sequencers
✓ Fees payment
"]
Tanssi_Substrate --> Tanssi_Substrate_Utility
end
subgraph Ethereum_Network ["Ethereum"]
Tanssi_ERC20["$TANSSI (ERC-20)"]
Tanssi_ERC20_Utility["✓ Operator services rewarding
✓ Staking on operators
"]
Tanssi_ERC20 --> Tanssi_ERC20_Utility
end
Bridge["Trustless Bridge"]
Tanssi_Network <--> Bridge <--> Ethereum_Network
%% Apply custom style to utility nodes
classDef utility_style fill: transparent, stroke: transparent, text-align: start;
class Tanssi_Substrate_Utility,Tanssi_ERC20_Utility utility_style;
%% Make utility arrows transparent
linkStyle 0 stroke:transparent,fill:transparent;
linkStyle 1 stroke:transparent,fill:transparent;
```
### Tanssi (Substrate) - Native Token {: #tanssi-substrate }
The native Tanssi token exists on the Tanssi network as a Substrate-based asset and is the original form of the token that powers the core protocol operations.
This token uses as [Sr25519 subtrate-type account](/learn/tanssi/account-types/#key-types-in-tanssi-protocol){target=\_blank}, so it requires a wallet such as [Talisman](/builders/toolkit/substrate-api/wallets/talisman/){target=\_blank} or any other [substrate-compatible wallet](/builders/toolkit/substrate-api/wallets/){target=\_blank}.
!!! note
The Tanssi (Substrate) native token has twelve (12) decimal places.
### Tanssi (ERC-20) - Ethereum Representation {: #tanssi-erc-20 }
Tanssi's ERC-20 version is a standard Ethereum token that represents the native token on the Ethereum network. This version is created through the trustless bridging mechanism, utilizing a lock-and-mint strategy, thereby maintaining a 1:1 relationship with the native token.
This token, like any other Ethereum asset, uses an [ECDSA account](/learn/tanssi/account-types/#key-types-in-tanssi-protocol){target=\_blank}, so it requires a wallet such as [Metamask](/builders/toolkit/ethereum-api/wallets/metamask/){target=\_blank} or any other [Ethereum-compatible wallet](/builders/toolkit/ethereum-api/wallets/){target=\_blank}.
!!! note
The Tanssi (ERC-20) has twelve (12) decimal places.
### Tanssi (Substrate) and Tanssi (ERC-20) Comparison {: #substrate-erc-20-comparison }
To better understand the differences between the two token representations, the following table provides a summary of their main features:
| **Feature** | **Tanssi (Substrate)** | **Tanssi (ERC-20)** |
|------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **Network** | Tanssi Network | Ethereum MainNet |
| **Token Standard** | Native Substrate asset | ERC-20 standard token |
| **Decimal Places** | Twelve (12) decimals | Twelve (12) decimals |
| **Account Type** | [Sr25519](https://wiki.polkadot.com/learn/learn-cryptography/#keypairs-and-signing){target=_blank} | [ECDSA](https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm){target=_blank} |
| **Compatible Wallets** | [Talisman](/builders/toolkit/substrate-api/wallets/talisman/){target=\_blank}, [SubWallet](/builders/toolkit/substrate-api/wallets/subwallet/){target=\_blank}, and others | [MetaMask](/builders/toolkit/ethereum-api/wallets/metamask/){target=\_blank}, [Talisman](/builders/toolkit/ethereum-api/wallets/talisman/){target=\_blank}, and other Ethereum-compatible wallets |
| **Primary Utilities** | - On-chain governance participation
- Appchain registration and deployment
- Sequencing services payment
- Transaction fees on Tanssi network
- Staking on sequencers
- Sequencer operation rewards | - Operator validation rewards
- Staking on operators |
| **Staking Options** | Sequencer staking (for keeping appchain liveness) | Operator staking (for validating/securing the entire Tanssi ecosystem) |
| **Bridge Conversion** | Can be bridged to ERC-20, paying fees in $TANSSI (Substrate) | Can be bridged to Substrate, paying fees in $ETH |
--- END CONTENT ---
Doc-Content: https://docs.tanssi.network/pt/builders/account-management/identity/
--- BEGIN CONTENT ---
---
title: Definir uma Identidade de Conta
description: Siga estas instruções para estabelecer uma identidade, incluindo um nome de exibição para que você possa ser mais facilmente reconhecido na cadeia do orquestrador Tanssi.
icon: octicons-person-24
categories: Basics, Appchain
---
# Configurar uma Identidade On-Chain
## Introdução {: #introduction }
O [Substrate](/pt/learn/framework/overview/#substrate-framework){target=\_blank} Identity [module](/pt/learn/framework/modules/){target=\_blank} é uma solução pronta para uso para adicionar informações pessoais à sua conta on-chain. O estabelecimento de uma identidade torna mais fácil para sua conta ser reconhecida por outros, pois seu nome de exibição preencherá automaticamente quando alguém colar seu endereço em um campo no [portal do desenvolvedor](https://polkadot.js.org/apps/?rpc=wss://{{ networks.mainnet.dns_name }}#/accounts){target=\_blank}.
A identidade que você configura vai além de um simples nome de exibição. As informações pessoais podem incluir campos padrão, como seu nome legal, nome de exibição, site, identificador do Twitter, Discord e nome do Riot (agora conhecido como Element). Você também pode usar campos personalizados para incluir quaisquer outras informações relevantes.
Este guia demonstrará como configurar uma identidade com um nome de exibição e parâmetros adicionais, aprimorando sua visibilidade e reconhecimento.
## Definições Gerais {: #general-definitions }
Para armazenar suas informações on-chain, você deve vincular alguns fundos, que, eventualmente, serão devolvidos assim que a identidade for limpa. Existem duas categorias de campos: padrão e personalizado. Uma quantia básica de depósito é reservada após a criação da identidade e um depósito de armazenamento é necessário para cada byte adicional de dados armazenados on-chain.
- **Campos padrão incluem** - seu nome legal, nome de exibição, site, identificador do Twitter, Discord, nome do Riot (agora conhecido como Element)
- **Campos personalizados incluem** - quaisquer outras informações relevantes
- **Subcontas** - Você pode vincular subcontas sob uma conta primária. Por exemplo, um serviço de Sequencer que está executando vários nós de Sequencer diferentes pode estabelecer subcontas para demonstrar um link oficial entre os nós
=== "Tanssi MainNet"
| Variável | Definição | Valor |
|:---------------------:|:--------------------------------------------------------------------------------:|:------------------------------------------------------------------------------------:|
| Depósito básico | O valor mantido em depósito para a definição de uma identidade | {{ networks.mainnet.identity.basic_deposit }} {{ networks.mainnet.token_symbol }} |
| Depósito por byte | O valor mantido em depósito por byte de armazenamento on-chain usado na definição de uma identidade | {{ networks.mainnet.identity.per_byte_deposit }} {{ networks.mainnet.token_symbol }} |
| Campos adicionais máx.| Número máximo de campos adicionais que podem ser armazenados em um ID | {{ networks.mainnet.identity.max_fields }} |
| Subcontas máx. | Número máximo de subcontas que podem ser definidas sob uma identidade de conta | {{ networks.mainnet.identity.max_subaccounts }} |
=== "Dancelight TestNet"
| Variável | Definição | Valor |
|:---------------------:|:--------------------------------------------------------------------------------:|:------------------------------------------------------------------------------------------:|
| Depósito básico | O valor mantido em depósito para a definição de uma identidade | {{ networks.dancelight.identity.basic_deposit }} {{ networks.dancelight.token_symbol }} |
| Depósito por byte | O valor mantido em depósito por byte de armazenamento on-chain usado na definição de uma identidade | {{ networks.dancelight.identity.per_byte_deposit }} {{ networks.dancelight.token_symbol }} |
| Campos adicionais máx.| Número máximo de campos adicionais que podem ser armazenados em um ID | {{ networks.dancelight.identity.max_fields }} |
| Subcontas máx. | Número máximo de subcontas que podem ser definidas sob uma identidade de conta | {{ networks.dancelight.identity.max_subaccounts }} |
## Verificando os Pré-requisitos {: #checking-prerequisites }
Para acompanhar este guia, você precisará do seguinte:
=== "Tanssi MainNet"
- O [portal do desenvolvedor](https://polkadot.js.org/apps/?rpc=wss://{{ networks.mainnet.dns_name }}#/accounts){target=\_blank} aberto e conectado à Tanssi MainNet.
- Pelo menos uma conta financiada com tokens `{{ networks.mainnet.token_symbol }}`.
=== "Dancelight TestNet"
- O [portal do desenvolvedor](https://polkadot.js.org/apps/?rpc=wss://{{ networks.dancelight.dns_name }}#/accounts){target=\_blank} aberto e conectado ao [Dancelight](/builders/tanssi-network/testnet/dancelight/){target=\_blank}.
- Pelo menos uma conta financiada com tokens `{{ networks.dancelight.token_symbol }}`.
Se precisar de ajuda para importar suas contas para o portal do desenvolvedor, consulte o guia [Conectando-se ao portal do desenvolvedor](/pt/builders/toolkit/substrate-api/wallets/talisman/#connecting-to-polkadotjs){target=\_blank}.
## Comece {: #get-started }
Dependendo das informações a serem incluídas, existem algumas maneiras diferentes de definir e limpar uma identidade usando o portal do desenvolvedor. Se você pretende registrar sua identidade usando apenas os campos padrão, pode seguir as instruções da página [Gerenciando uma Identidade via Contas](#manage-via-accounts). **Esta é a Maneira Recomendada de Definir e Gerenciar Sua Identidade**.
Se você deseja adicionar campos personalizados além dos campos padrão, siga as instruções para a página [Gerenciando uma Identidade via Extrinsics](#manage-via-extrinsics).
!!! note
Observe que o uso da página **Contas** no portal do desenvolvedor é recomendado para gerenciar sua identidade, pois ela fornece uma interface fácil de usar que impõe limites de caracteres. Se você usar a página **Extrinsics**, esteja ciente de que sua entrada para cada campo (ou seja, nome, e-mail, etc.) deve ter 32 caracteres ou menos; caso contrário, suas informações serão cortadas.
## Gerenciar uma Identidade via Contas {: #manage-via-accounts }
### Definir uma Identidade {: #set-identity-via-accounts }
Para começar a definir uma identidade usando a página Contas, vá para a guia [**Contas**](https://polkadot.js.org/apps/?rpc=wss://{{ networks.mainnet.dns_name }}#/accounts){target=\_blank} do portal do desenvolvedor.
Você já deve ter uma conta conectada, então você pode clicar no nome da sua conta para verificar e observar seus saldos. Depois de enviar a transação para definir uma identidade, os depósitos que você enviou serão movidos do seu saldo transferível para seu saldo reservado.
Para definir sua identidade, você precisará:
1. Clique nos três pontos verticais ao lado da conta para a qual deseja definir uma identidade
2. Um menu aparecerá. Clique em **Set on-chain identity**
Em seguida, o menu para registrar e definir sua identidade aparecerá e você poderá começar a preencher suas informações. Você não é obrigado a inserir informações para todos os campos; você pode escolher preencher apenas um campo ou todos eles; a escolha é sua. Para este exemplo:
1. Defina seu nome de exibição
2. Clique no botão **include field** para e-mail e depois insira seu e-mail
3. Clique no botão **include field** para web e depois insira a URL do seu site
4. Clique no botão **include field** para Twitter e depois insira seu identificador do Twitter
5. Reveja os campos de dados anteriores e clique em **Set Identity**
Você será solicitado a assinar a transação. Se tudo estiver correto, assine-a.
Você deve ver as notificações de status aparecerem no canto superior direito. Depois que a transação for confirmada, você pode clicar no nome da sua conta novamente, e o painel deslizará para fora no lado direito da página. Seus saldos terão sido alterados e você também verá suas novas informações de identidade.
Se as informações de identidade corresponderem ao que você inseriu, você definiu com sucesso uma identidade!
Depois de limpar sua identidade, o depósito em seu saldo reservado será transferido de volta para seu saldo transferível. Se você precisar alterar sua identidade, pode passar pelo processo de configuração da sua identidade novamente. Observe que você deve garantir que todos os campos sejam reinseridos, mesmo que apenas um campo precise ser alterado, ou eles serão substituídos. Você não precisará pagar outro depósito, a menos que campos personalizados sejam usados, mas precisará pagar taxas de gás.
## Gerenciar uma Identidade via Extrinsics {: #manage-via-extrinsics}
### Definir uma Identidade {:#set-identity-extrinsics }
Para registrar uma identidade usando a página de extrínsecos, navegue até a página [**Extrinsics**](https://polkadot.js.org/apps/?rpc=wss://{{ networks.mainnet.dns_name }}#/extrinsics){target=\_blank} do portal do desenvolvedor. Certifique-se de que sua entrada não exceda 32 caracteres para cada campo de identidade. Para concluir sua identidade, siga as etapas a seguir:
1. Selecione sua conta
2. Selecione identidade no menu suspenso **enviar o seguinte extrínseco**
3. Em seguida, selecione a função **setIdentity(info)**
4. Selecione **Raw** como o formato de dados para inserir seu **Nome de Exibição**
5. Insira os dados para **Exibição** no formato selecionado
6. Selecione **Raw** como o formato de dados para inserir seu endereço da web
7. Insira a URL do seu site no formato selecionado
8. Selecione **Raw** como o formato de dados para inserir seu e-mail
9. Insira seu endereço de e-mail no formato selecionado
10. Selecione **Raw** como o formato de dados para inserir seu identificador do Twitter
11. Insira seu Twitter no formato selecionado. Insira apenas o nome de usuário, começando com o símbolo `@`
12. Reveja os campos preparados e pressione **Enviar Transação**
Opcionalmente, se você quiser inserir campos personalizados, siga as seguintes etapas:
1. Role para o topo e clique em **Add item**
2. Dois campos aparecerão: o primeiro para o nome do campo e o segundo para o valor. Selecione **Raw** como o formato de dados para inserir o nome do campo
3. Insira o nome do campo no formato especificado
4. Selecione **Raw** como o formato de dados para inserir o valor personalizado
5. Insira o valor personalizado no formato especificado
Finalmente, depois que todas as informações de identidade forem adicionadas, você pode rolar para a parte inferior da página e clicar em **Submit Transaction**.
Você será solicitado a assinar a transação. Lembre-se, um depósito adicional é necessário para cada campo personalizado adicional. Se tudo estiver correto, assine a transação.
Você deve ver as notificações de status aparecerem no canto superior direito confirmando a transação. Se bem-sucedido, você definiu uma identidade! Parabéns! Para garantir que tudo tenha sido concluído e que suas informações de identidade tenham uma boa aparência, você pode verificar sua identidade.
### Confirmar uma Identidade {: #confirm-identity-extrinsics }
Para verificar a adição de suas informações de identidade, você pode clicar na guia **Developer** e, em seguida, navegar até o [**Chain state**](https://polkadot.js.org/apps/?rpc=wss://{{ networks.mainnet.dns_name }}#/chainstate){target=\_blank}.
Na página **Chain State**, certifique-se de que **Storage** esteja selecionado. Em seguida, você pode começar a solicitar suas informações de identidade:
1. Defina a **selected state query** como **identity**
2. Selecione a função **identityOf(AccountId)**
3. Selecione sua conta
4. Clique no botão **+** para obter suas informações de identidade
Você pode ver agora que você definiu com sucesso uma identidade! Depois de limpar sua identidade, o depósito em seu saldo reservado será transferido de volta para seu saldo transferível. Se você precisar alterar sua identidade, pode passar pelo processo de configuração da sua identidade novamente. Observe que você deve garantir que todos os campos sejam reinseridos, mesmo que apenas um campo precise ser alterado, ou eles serão substituídos. Você não precisará pagar outro depósito, a menos que campos personalizados sejam usados, mas precisará pagar taxas de gás.
## Limpar uma Identidade {: #clear-identity-extrinsics }
Para limpar sua identidade, siga as seguintes etapas na guia **Extrinsics** do portal do desenvolvedor:
1. Selecione sua conta no menu suspenso **usando a conta selecionada**
2. Selecione **identity** no menu suspenso **enviar o seguinte extrínseco**
3. Em seguida, selecione a função **clearIdentity()**
4. Clique em **Enviar Transação**
Você será solicitado a assinar a transação. Se tudo estiver correto, assine-a. Você deve ver as notificações de status no canto superior direito confirmando a transação.
Para confirmar se suas informações de identidade foram removidas com sucesso, revise as etapas descritas na seção [Confirmar uma Identidade](#confirm-identity-extrinsics). Desta vez, em vez de exibir seus detalhes de identidade, a resposta deve indicar **none**, confirmando que nenhuma informação de identidade está atualmente vinculada à sua conta. Além disso, ao verificar seus saldos, você descobrirá que o depósito inicialmente feito para definir sua identidade foi creditado de volta ao seu saldo transferível. Isso conclui o processo de limpeza da sua identidade.
--- END CONTENT ---
Doc-Content: https://docs.tanssi.network/pt/builders/account-management/proxy-accounts/
--- BEGIN CONTENT ---
---
title: Configurar e Gerenciar Contas de Proxy
description: Siga estas instruções passo a passo para entender como as proxies funcionam e como criar, visualizar, atualizar e remover contas de proxy a partir das contas primárias (proxiadas).
icon: octicons-shield-lock-24
categories: Basics, Appchain
---
# Contas Proxy
## Introdução {: #introduction }
As contas proxy podem ser configuradas para executar um número limitado de ações em nome das contas primárias e são úteis para manter as contas subjacentes seguras. Sua conta proxy pode atuar como uma "carteira quente" para interagir com a rede em nome de sua conta de "carteira fria". Para maior segurança, você pode rotacionar regularmente a conta proxy.
As contas proxy também podem ajudá-lo a implementar o princípio do privilégio mínimo para controle de acesso. Por exemplo, se você tiver vários membros da equipe, poderá fornecer a eles o nível mínimo de acesso necessário para realizar suas tarefas por meio de um tipo específico de conta proxy.
Este tutorial o guiará pela configuração de uma conta proxy na Dancelight, o Tanssi TestNet, especificamente para transferências de saldo. Em seguida, demonstrará como realizar uma transferência de saldo usando o proxy recém-criado.
## Verificando os Pré-requisitos {: #verifying-prerequisites }
Para acompanhar este tutorial, você precisará ter:
- [Polkadot.js Apps](https://polkadot.js.org/apps/?rpc=wss://{{ networks.dancelight.dns_name }}#/accounts){target=\_blank} aberto e conectado ao [Dancelight](/pt/builders/tanssi-network/testnet/dancelight/){target=\_blank}.
- Crie ou tenha duas contas acessíveis no portal do desenvolvedor.
- Pelo menos uma das contas precisará ser financiada com tokens `{{ networks.dancelight.token_symbol }}`.
Se precisar de ajuda para importar suas contas para o Polkadot.js Apps, consulte o guia [Conectando-se ao Polkadot.js](/pt/builders/toolkit/substrate-api/wallets/talisman/#connecting-to-polkadotjs){target=\_blank}.
## Definições Gerais {: #general-definitions }
Ao configurar uma conta proxy, uma garantia para o proxy é retirada de seu saldo livre e movida para seu saldo reservado. A garantia é necessária, pois a adição de um proxy requer espaço de armazenamento na cadeia e é recalculada para cada proxy que você adiciona ou remove. A garantia é devolvida ao seu saldo livre após a remoção de todos os proxies da sua conta.
O depósito é calculado com base em uma base de depósito e um fator de depósito:
- **Base do depósito** - o valor a ser reservado para uma conta ter uma lista de proxies.
- **Fator de depósito** - o valor adicional a ser reservado para cada proxy que a conta primária tiver.
A equação para calcular o depósito é:
```text
base do depósito + fator de depósito * número de proxies
```
Você pode encontrar cada uma das variáveis relevantes abaixo.
=== "Tanssi MainNet"
| Variável | Valor |
|:--------------:|:--------------------------------------------------------------------------------:|
| Base do depósito | {{ networks.mainnet.proxy.deposit_base }} {{ networks.mainnet.token_symbol }} |
| Fator de depósito | {{ networks.mainnet.proxy.deposit_factor }} {{ networks.mainnet.token_symbol }} |
| Máx. de proxies | {{ networks.mainnet.proxy.max_proxies }} proxies |
=== "Dancelight TestNet"
| Variável | Valor |
|:--------------:|:--------------------------------------------------------------------------------------:|
| Base do depósito | {{ networks.dancelight.proxy.deposit_base }} {{ networks.dancelight.token_symbol }} |
| Fator de depósito | {{ networks.dancelight.proxy.deposit_factor }} {{ networks.dancelight.token_symbol }} |
| Máx. de proxies | {{ networks.dancelight.proxy.max_proxies }} proxies |
## Tipos de Proxy {: #proxy-types }
Ao criar uma conta proxy, você deve escolher um tipo de proxy que definirá como o proxy pode ser usado. As opções disponíveis são:
- **`Any`** - permite que a conta proxy use qualquer função suportada pela palete proxy. Não há filtragem de chamadas.
- **`NonTransfer`** - este tipo de conta proxy é permitido para enviar qualquer tipo de transação, com exceção de transferências de saldo.
- **`Balances`** - permite que a conta proxy faça apenas transações relacionadas ao envio de fundos.
- **`Governance`** - permite que a conta proxy faça apenas transações relacionadas à palete de governança, como votação ou criação de propostas de democracia. Observe que a governança ainda não está habilitada na Tanssi. Você pode criar contas proxy de governança, mas elas não poderão tomar nenhuma ação até que a governança seja habilitada.
- **`Registrar`** - permite que a conta proxy faça apenas transações relacionadas à palete do registrador.
- **`SudoRegistrar`** - permite que a conta proxy faça apenas transações relacionadas à palete do registrador que precisam ser chamadas por Sudo.
- **`CancelProxy`** - permite que a conta proxy rejeite e remova quaisquer chamadas proxy anunciadas.
- **`Staking`** - permite que a conta proxy execute transações relacionadas a staking, como funções de Sequencer e `session()`.
- **`SessionKeyManagement`** - permite que a conta proxy faça transações relacionadas ao gerenciamento de chaves incluídas na palete de sessão.
Para este guia, você configurará uma conta proxy usando o tipo de proxy de saldos. Como este tipo permite que o proxy gaste fundos em nome da conta primária, você deve ter cuidado e fornecer acesso apenas a contas em que confia. O proxy terá acesso para transferir todos os fundos dentro da conta primária e, se não for confiável, o proxy poderá drenar a conta primária. Certifique-se de manter a supervisão de suas contas proxy e remover todos os proxies que não forem mais necessários.
## Criando uma Conta Proxy {: #creating-a-proxy-account }
Há algumas maneiras de criar contas proxy no [Polkadot.js Apps](https://polkadot.js.org/apps/?rpc=wss://{{ networks.dancelight.dns_name }}#/accounts){target=\_blank}, seja na página **Extrinsics** ou na página **Accounts**. No entanto, para criar um proxy com atraso de tempo, você precisará usar a página **Extrinsics**. Um atraso de tempo fornece uma camada adicional de segurança para proxies, especificando um período de atraso com base no número de blocos. Isso impedirá que a conta proxy execute uma transação até o final do período de atraso. O atraso permite tempo para a conta primária que controla o proxy revisar as transações pendentes, possivelmente para ações maliciosas, e cancelar, se necessário, antes da execução.
A seguinte demonstração mostrará como configurar um proxy Balances, que permite a transferência de fundos, tornando-o perfeito para fins de demonstração. Depois de configurar seu proxy de saldos, você pode tentar transferir fundos da conta primária via proxy.
Para começar a criar sua conta proxy, vá para a aba **Developer** e selecione [**Extrinsics**](https://polkadot.js.org/apps/?rpc=wss://{{ networks.dancelight.dns_name }}#/extrinsics){target=\_blank} no menu suspenso. Em seguida, você precisará seguir as seguintes etapas:
1. Selecione a conta primária.
2. No menu suspenso **submit the following extrinsic**, selecione **proxy**.
3. Escolha a extrínseca **addProxy**.
4. Escolha **Id** no menu suspenso **AccountIdLookupOf**.
5. Selecione a conta **delegate** para o proxy.
6. No menu suspenso **proxyType**, escolha **Balances**.
7. Opcionalmente, você pode adicionar um atraso de tempo usando um número especificado de blocos para adicionar uma camada adicional de segurança para que a conta primária revise a transação pendente.
8. Clique em **Submit Transaction**.
Você será solicitado a autorizar e assinar a transação. Clique em **Sign and Submit** para criar o relacionamento proxy. Depois que a transação for enviada com sucesso, você receberá algumas notificações confirmando a transação.
Como mencionado anteriormente, você também pode criar um proxy na página **Accounts**. Para fazer isso, navegue até a página **Accounts** e siga as seguintes etapas:
1. Selecione os três pontos verticais ao lado da conta primária.
2. Selecione **Add proxy**.
!!! note
Se a conta já tiver um proxy, **Manage proxies** será exibido como uma opção em vez de **Add proxy**.
Aparecerá um pop-up e você poderá inserir as informações necessárias, como a conta proxy/primária, a conta proxy e o tipo de proxy para criar uma conta proxy. Primeiro, clique em **Add Proxy**.
Em seguida, siga as seguintes etapas:
1. Selecione a conta que deseja definir como proxy.
2. Selecione o tipo de proxy.
3. Clique em **Submit** e assine a transação.
Na próxima seção, você aprenderá como verificar se sua conta proxy foi configurada com sucesso.
## Verificando sua Conta Proxy {: #verifying-your-proxy-account }
Você pode verificar se sua conta proxy foi configurada com sucesso de algumas maneiras: na página **Accounts** ou na página **Chain state**.
Para verificar suas contas proxy na página [**Chain state**](https://polkadot.js.org/apps/?rpc=wss://{{ networks.dancelight.dns_name }}#/chainstate){target=\_blank}, você pode seguir as seguintes etapas:
1. No menu suspenso **selected state query**, selecione **proxy**.
2. Escolha a extrínseca **proxies**.
3. Selecione sua conta primária/proxy.
4. Clique no botão **+** para enviar a consulta.
O resultado aparecerá na página, mostrando informações sobre todos os seus proxies, incluindo o endereço da conta delegate/proxy, o tipo de proxy, o período de atraso, se um foi especificado, e o valor total da garantia para todos os seus proxies em Planck.
Você também pode verificar suas contas proxy na página **Accounts**. Para fazer isso, navegue até a página **Accounts** e deverá haver um símbolo Proxy ao lado da conta primária. Passe o mouse sobre o ícone e clique em **Manage proxies** para revisar seus proxies.
Aparecerá um pop-up onde você poderá ver uma visão geral de todas as suas contas proxy.
## Executando uma Transação Proxy {: #executando-uma-transação-proxy }
Agora que você criou uma conta proxy e verificou se ela foi configurada com sucesso, você pode executar uma transação usando a conta proxy em nome da conta primária.
Para executar uma transação, você pode voltar para a página [**Extrinsics**](https://polkadot.js.org/apps/?rpc=wss://{{ networks.dancelight.dns_name }}#/extrinsics){target=\_blank} e seguir as seguintes etapas:
1. Selecione a conta proxy para enviar a transação pelo menu suspenso **using the select account**.
2. No menu **submit the following extrinsic**, selecione **proxy**.
3. Escolha a extrínseca **proxy**.
4. Escolha **Id** no menu suspenso **AccountIdLookupOf**.
5. Selecione a conta primária no menu suspenso **real**.
6. Selecione a chamada **balances**.
7. Escolha a extrínseca **transferKeepAlive**.
8. Escolha **Id** no menu suspenso **AccountIdLookupOf**.
9. No campo **dest**, insira o endereço para o qual você gostaria de enviar fundos.
10. No campo **value**, insira a quantidade de tokens `{{ networks.dancelight.token_symbol }}` para enviar. Para este exemplo, você pode enviar `2` tokens `{{ networks.dancelight.token_symbol }}`.
11. Clique em **Submit Transaction**.
Aparecerá um pop-up para você autorizar e assinar a transação. Insira sua senha para a conta proxy e clique em **Sign and Submit**.
Se a transação for bem-sucedida, você deverá ver alguns pop-ups de notificação. Se você for para a página **Accounts**, verá que o saldo de sua conta primária diminuiu. Se você verificar o saldo da conta para onde enviou os fundos, notará que o saldo aumentou.
É isso! Você executou com sucesso uma transação usando uma conta proxy em nome de sua conta primária.
## Removendo uma Conta Proxy {: #removing-a-proxy-account }
Semelhante à adição de uma conta proxy, há algumas maneiras de remover uma conta proxy, seja na página **Extrinsics** ou na página **Accounts**. Independentemente de qual página você usar, você pode optar por remover uma única conta proxy ou todos os proxies associados à sua conta primária.
Para remover um proxy da página [**Extrinsics**](https://polkadot.js.org/apps/?rpc=wss://{{ networks.dancelight.dns_name }}#/extrinsics){target=\_blank}, você pode seguir as seguintes etapas:
1. No menu suspenso **using the selected account**, selecione sua conta primária.
2. Em seguida, selecione **proxy**.
3. Escolha **removeProxy** para remover um único proxy ou **removeProxies** para remover todos os proxies associados.
4. Escolha **Id** no menu suspenso **AccountIdLookupOf**.
5. Se estiver removendo um único proxy, insira a conta proxy a ser removida no campo **delegate**.
6. Selecione o **proxyType** a ser removido, neste caso, escolha **Balances**.
7. Opcionalmente, selecione um período de atraso em número de blocos.
8. Clique em **Submit Transaction**.
Aparecerá um pop-up pedindo que você autorize e assine a transação. Você pode assinar e enviar a transação da conta primária ou proxy, mas a chamada para remover o proxy deve ser enviada da conta primária. Insira sua senha e clique em **Sign and Submit**.
Para verificar se o proxy ou as contas proxy foram removidos, siga as etapas na seção [Verificando sua Conta Proxy](#verifying-your-proxy-account).
Como mencionado anteriormente, você também pode remover um proxy da página **Accounts**. Para fazer isso, na página **Accounts**, selecione os três pontos verticais ao lado da conta primária e selecione **Manage Proxies**.
Aparecerá um pop-up mostrando uma visão geral de suas contas proxy. Para remover todos os proxies, você pode clicar em **Clear all**, e será automaticamente solicitado que você insira sua senha e envie a transação. Para remover um único proxy, siga as seguintes etapas:
1. Clique no botão **X** ao lado do proxy para remover
2. Pressione **Submit**
Na tela de confirmação da transação, siga as seguintes etapas:
1. Certifique-se de não usar um proxy para esta chamada (como este exemplo é um proxy de saldos, a chamada para remover o proxy precisa vir da conta primária, em vez da conta proxy).
2. Insira sua senha para a conta respectiva.
3. Pressione **Sign and Submit**.
Depois que a transação for enviada com sucesso, você pode revisar seus proxies atuais ou, se removeu todos os proxies, notará que o ícone do proxy não está mais sendo exibido ao lado da conta primária. E é isso! Você criou com sucesso um proxy, revisou todas as contas proxy associadas à sua conta primária, executou uma transação proxy e removeu uma conta proxy!
{{ trans("disclaimer.third_party") }}
--- END CONTENT ---
Doc-Content: https://docs.tanssi.network/pt/builders/interoperability/built-in-bridge/
--- BEGIN CONTENT ---
---
title: Usando a Bridge Tanssi Integrada
description: Saiba como usar a bridge Tanssi integrada que conecta Tanssi e Ethereum para converter tokens TANSSI entre sua forma nativa e ERC-20, e vice-versa.
icon: octicons-arrow-switch-24
categories: Basics
---
# Usando a Bridge Tanssi Integrada
## Introdução {: #introduction }
O protocolo Tanssi orquestra componentes de infraestrutura, permitindo que os desenvolvedores lancem seus appchains personalizados em minutos e fornecendo a eles segurança econômica de nível Ethereum pronta para uso. Para facilitar todo o processo para os desenvolvedores, uma [arquitetura de primeira classe](/pt/learn/tanssi/overview/#tanssi-architecture){target=\_blank} foi projetada e implementada.
O [token TANSSI](/pt/builders/tanssi-network/tanssi-token/){target=\_blank} é o motor que permite a integração de diferentes componentes de infraestrutura com [provedores de segurança externos](/pt/learn/tanssi/external-security-providers/symbiotic/){target=\_blank} e alinha incentivos entre vários atores, incluindo detentores de tokens, node operators e builders de appchain. Para atender a diferentes casos de uso, o token tem duas versões: a moeda nativa da rede Tanssi, TANSSI (Substrate), e sua versão ERC-20, no Ethereum.
Os usuários podem converter de uma versão para outra do token usando uma [bridge sem confiança integrada da Tanssi](/pt/learn/tanssi/tanssi-ethereum-bridge/){target=\_blank}.
Neste guia, você aprenderá como mover seus ativos de Tanssi para Ethereum e vice-versa por meio de uma interface web segura e fácil de usar disponível no [Tanssi dApp](https://apps.tanssi.network/bridge){target=\_blank}, tornando as transferências entre cadeias acessíveis a todos.
## Pré-requisitos {: #prerequisites }
Antes de usar a bridge Tanssi, certifique-se de ter:
Para fazer a bridge de Tanssi para Ethereum:
- Uma [carteira compatível com Substrate](/pt/builders/toolkit/substrate-api/wallets/){target=\_blank}, como [Talisman](/pt/builders/toolkit/substrate-api/wallets/talisman/){target=\_blank}.
- Saldo TANSSI (Substrate) para transferir e pagar as taxas de bridge.
- A conta de destino do tipo Ethereum.
Para fazer a bridge de Ethereum para Tanssi:
- Uma [carteira compatível com Ethereum](/pt/builders/toolkit/ethereum-api/wallets/){target=\_blank}, como [MetaMask](/pt/builders/toolkit/ethereum-api/wallets/metamask/){target=\_blank}.
- Saldo TANSSI (ERC-20) para transferir.
- Saldo ETH para pagar as taxas de bridge.
- A conta de destino do tipo Substrate.
## Fazendo a Bridge de Tokens TANSSI para Ethereum {: #bridge-to-ethereum}
Se você deseja converter seus tokens TANSSI (Substrate) para TANSSI (ERC-20) no Ethereum, acesse o Tanssi dApp, abra a [seção da bridge](https://apps.tanssi.network/bridge){target=\_blank} e siga estas etapas:
1. Selecione **Mainnet** no menu suspenso **From**.
2. Clique em **Connect Wallet**. Uma janela pop-up aparecerá, permitindo que você selecione sua carteira Substrate preferida e escolha a conta correspondente.
Agora, com sua carteira conectada:
1. Selecione a conta de destino no menu suspenso **Select recipient address** ou escolha o item **Enter a custom address** e insira manualmente a conta para onde deseja receber os tokens ERC-20.
2. Insira o valor a ser transferido no campo **Balance**. As taxas estimadas de bridge e transação serão exibidas junto com o valor que a conta de destino receberá.
3. Clique em **Send** e assine a transação.
E é isso! Seus tokens serão transferidos quando a próxima sessão começar. Você pode ver quanto tempo resta na sessão atual na barra de progresso.
!!! note
- Você pode adicionar facilmente o endereço do contrato TANSSI ERC-20 à sua carteira clicando no ícone **+** mostrado ao lado do seu saldo.
- As taxas para converter seus tokens TANSSI (Substrate) para TANSSI (ERC-20) podem flutuar ao longo do tempo e devem ser pagas usando TANSSI.
## Fazendo a Bridge de ERC-20 TANSSI para a Rede Tanssi {: #bridge-to-tanssi }
Se você deseja converter seus tokens TANSSI (ERC-20) para TANSSI (Substrate) nativo na rede Tanssi, acesse o Tanssi dApp, abra a [seção da bridge](https://apps.tanssi.network/bridge){target=\_blank} e siga estas etapas:
1. Selecione **Ethereum** no menu suspenso **From**.
2. Clique em **Connect Wallet**, selecione sua carteira Ethereum preferida e escolha a conta.
Agora, com sua carteira conectada:
1. Insira a conta de destino Substrate no campo **Recipient**.
2. Insira o valor a ser transferido no campo **Balance**. As taxas estimadas de bridge e transação serão exibidas junto com o valor que a conta de destino receberá.
3. Clique em **Send** e assine a transação.
E é isso! Seus tokens serão transferidos quando a próxima sessão começar. Você pode ver quanto tempo resta na sessão atual na barra de progresso.
!!! note
As taxas para converter seus tokens TANSSI (ERC-20) para TANSSI (Substrate) nativo na rede Tanssi podem flutuar ao longo do tempo e devem ser pagas usando ETH.
--- END CONTENT ---
Doc-Content: https://docs.tanssi.network/pt/builders/tanssi-network/tanssi-token/
--- BEGIN CONTENT ---
---
title: Token TANSSI
description: Conheça as duas versões do token Tanssi — o token nativo do Substrate e a representação ERC-20 no Ethereum — e suas utilidades e casos de uso.
icon: octicons-ruby-24
categories: Basics
---
# Token TANSSI {: #tanssi-token }
## Introdução {: #introduction }
O token da rede Tanssi é o token de utilidade que alimenta o protocolo Tanssi. Considerando a [arquitetura da Tanssi](/pt/learn/tanssi/overview/#tanssi-architecture){target=\_blank}, o token existe em duas representações distintas, mas interconectadas: Substrate nativo e ERC-20 Ethereum. As duas versões podem ser interligadas através da [bridge Tanssi-Ethereum](/pt/learn/tanssi/tanssi-ethereum-bridge/){target=\_blank}.
Neste guia, a utilidade do token e as diferenças entre suas duas representações são abordadas, o que é crucial para operators de rede, stakers, gerentes de appchain e usuários em geral que desejam participar do ecossistema Tanssi.
## Utilidade do Token {: #token-utility }
A Tanssi é um protocolo de infraestrutura descentralizado que facilita a implantação de appchains com lógica personalizada. Ele permite que os desenvolvedores se concentrem no caso de uso, em vez de desviar tempo e energia para gerenciar [os vários componentes necessários](/pt/learn/tanssi/overview/#what-tanssi-provides){target=\_blank} para que uma rede funcione sem problemas.
A execução de um protocolo descentralizado saudável não só requer um mecanismo de governança robusto para garantir que as decisões sejam tomadas de forma transparente, mas também o alinhamento de incentivos e coordenação entre vários atores do ecossistema, incluindo desenvolvedores de appchain, node operators, operators de Sequencers, disponibilidade de dados e provedores de RPC, bem como usuários em geral. O token Tanssi serve como a espinha dorsal, fornecendo os mecanismos econômicos necessários para coordenar, incentivar o comportamento adequado e proteger todo o ecossistema. Ele permite uma evolução de protocolo verificável e imposta por código por meio de um processo de tomada de decisão totalmente na cadeia.
O token tem várias utilidades:
- **Governança on-chain**: os detentores de tokens podem usar o token para propor e votar em decisões de governança, como atualizações de software, como gastar fundos do tesouro, alterar regras de protocolo e muito mais.
- **Implantação de Appchain**: use o token para registrar e lançar seu appchain em minutos.
- **Pagamento do serviço de sequenciamento**: use o token para manter seu appchain ativo.
- **Recompensa de serviços de sequenciamento e operator**: obtenha tokens como recompensas pelos serviços de seus nós.
- **Staking em Sequencers**: os detentores de tokens podem apostar em Sequencers, recebendo recompensas sem risco de corte.
- **Staking em operators**: os detentores de tokens podem apostar em operators, recebendo recompensas por seus serviços de validação.
- **Pagamento de taxas**: use o token para pagar as taxas de interação com a rede Tanssi.
!!! note
Todas as taxas de transação na Tanssi são pagas usando o token, com o valor total indo diretamente para financiar a conta do tesouro do protocolo. Esses fundos só podem ser gastos via governança.
## Representações de Token {: #token-representations }
A rede Tanssi é construída usando a estrutura Substrate, aproveitando sua arquitetura modular e alto desempenho. Portanto, o token nativo é do tipo Substrate. Os mecanismos de cunhagem e queima do protocolo acontecem na rede Tanssi, ou, em outras palavras, acontecem na representação do token Substrate.
Além disso, o protocolo Tanssi conta com [provedores de segurança externos](/pt/learn/tanssi/external-security-providers/){target=\_blank}, como o [Symbiotic](/pt/learn/tanssi/external-security-providers/symbiotic/){target=\_blank}, para proteger o ecossistema por meio de ativos reapostados. Esse mecanismo de reaposta é implementado no Ethereum; portanto, uma versão ERC-20 do token também existe para cobrir casos de uso no lado Ethereum.
Aproveitando os [recursos de bridging integrados à](/pt/learn/tanssi/tanssi-ethereum-bridge/){target=\_blank} Tanssi, o token pode ser convertido para (e de) a representação ERC-20 no Ethereum. Quando o token é ponteado para Ethereum, os tokens são travados na conta soberana da bridge, e uma mensagem é enviada ao contrato Ethereum para cunhar a quantia equivalente em ERC-20. Esse mecanismo de travamento e cunhagem garante que a versão ERC-20 seja criada por meio de um mecanismo de bridging sem confiança, mantendo um relacionamento 1:1 com o token nativo.
```mermaid
flowchart LR
subgraph Tanssi_Network ["Rede Tanssi"]
Tanssi_Substrate["$TANSSI (Substrate)"]
Tanssi_Substrate_Utility["✓ Governança on-chain
✓ Implantação de Appchain
✓ Recompensas de Sequencers
✓ Staking em Sequencers
✓ Pagamento de taxas
"]
Tanssi_Substrate --> Tanssi_Substrate_Utility
end
subgraph Ethereum_Network ["Ethereum"]
Tanssi_ERC20["$TANSSI (ERC-20)"]
Tanssi_ERC20_Utility["✓ Recompensa de serviços de operator
✓ Staking em operators
"]
Tanssi_ERC20 --> Tanssi_ERC20_Utility
end
Bridge["Trustless Bridge"]
Tanssi_Network <--> Bridge <--> Ethereum_Network
%% Apply custom style to utility nodes
classDef utility_style fill: transparent, stroke: transparent, text-align: start;
class Tanssi_Substrate_Utility,Tanssi_ERC20_Utility utility_style;
%% Make utility arrows transparent
linkStyle 0 stroke:transparent,fill:transparent;
linkStyle 1 stroke:transparent,fill:transparent;
```
### Tanssi (Substrate) - Token Nativo {: #tanssi-substrate }
O token Tanssi nativo existe na rede Tanssi como um ativo baseado em Substrate e é a forma original do token que alimenta as operações principais do protocolo.
Este token usa como [conta do tipo Substrate Sr25519](/pt/learn/tanssi/account-types/#key-types-in-tanssi-protocol){target=\_blank}, então requer uma carteira como a [Talisman](/pt/builders/toolkit/substrate-api/wallets/talisman/){target=\_blank} ou qualquer outra [carteira compatível com Substrate](/pt/builders/toolkit/substrate-api/wallets/){target=\_blank}.
!!! note
O token nativo Tanssi (Substrate) tem doze (12) casas decimais.
### Tanssi (ERC-20) - Representação Ethereum {: #tanssi-erc-20 }
A versão ERC-20 da Tanssi é um token Ethereum padrão que representa o token nativo na rede Ethereum. Essa versão é criada por meio do mecanismo de bridge sem confiança, utilizando uma estratégia de bloqueio e cunhagem, mantendo assim um relacionamento 1:1 com o token nativo.
Este token, como qualquer outro ativo Ethereum, usa uma [conta ECDSA](/pt/learn/tanssi/account-types/#key-types-in-tanssi-protocol){target=\_blank}, então requer uma carteira como [Metamask](/pt/builders/toolkit/ethereum-api/wallets/metamask/){target=\_blank} ou qualquer outra [carteira compatível com Ethereum](/pt/builders/toolkit/ethereum-api/wallets/){target=\_blank}.
!!! note
O Tanssi (ERC-20) tem doze (12) casas decimais.
### Comparação Tanssi (Substrate) e Tanssi (ERC-20) {: #substrate-erc-20-comparison }
Para entender melhor as diferenças entre as duas representações de token, a tabela a seguir fornece um resumo de seus principais recursos:
| **Recurso** | **Tanssi (Substrate)** | **Tanssi (ERC-20)** |
|------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **Rede** | Rede Tanssi | Ethereum MainNet |
| **Padrão de Token** | Ativo Substrate nativo | Token padrão ERC-20 |
| **Casas Decimais** | Doze (12) decimais | Doze (12) decimais |
| **Tipo de Conta** | [Sr25519](https://wiki.polkadot.com/learn/learn-cryptography/#keypairs-and-signing){target=\_blank} | [ECDSA](https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm){target=\_blank} |
| **Carteiras Compatíveis** | [Talisman](/pt/builders/toolkit/substrate-api/wallets/talisman/){target=\_blank}, [SubWallet](/pt/builders/toolkit/substrate-api/wallets/subwallet/){target=\_blank} e outros | [MetaMask](/pt/builders/toolkit/ethereum-api/wallets/metamask/){target=\_blank}, [Talisman](/pt/builders/toolkit/ethereum-api/wallets/talisman/){target=\_blank} e outras carteiras compatíveis com Ethereum |
| **Principais Utilidades** | - Participação na governança on-chain
- Registro e implantação de Appchain
- Pagamento de serviços de sequenciamento
- Taxas de transação na rede Tanssi
- Staking em Sequencers
- Recompensas de operação do Sequencer | - Recompensas de validação do operator
- Staking em operators |
| **Opções de Staking** | Staking de Sequencer (para manter a atividade da appchain) | Staking de operator (para validar/proteger todo o ecossistema Tanssi) |
| **Conversão de Bridge** | Pode ser ponteado para ERC-20, pagando taxas em $TANSSI (Substrate) | Pode ser ponteado para Substrate, pagando taxas em $ETH |
--- END CONTENT ---