Encaminhe o Título Original '系统解读Fiber：把闪电网络嫁接到CKB上的宏大实验'

Em 23 de agosto, a CKB lançou oficialmente a Rede de Fibra, uma solução de Lightning Network baseada na CKB. Esta notícia rapidamente desencadeou intensas discussões na comunidade, levando a um aumento de quase 30% no preço da CKB em apenas um dia. A forte reação pode ser atribuída à narrativa convincente da Lightning Network e ao fato de que a Fibra oferece uma solução aprimorada em relação à Lightning Network tradicional, com inúmeras melhorias. Por exemplo, a Fibra suporta vários tipos de ativos nativamente, incluindo CKB, BTC e stablecoins, e se beneficia das taxas de transação mais baixas da CKB e dos tempos de resposta mais rápidos, o que possibilita avanços significativos na experiência do usuário. Além disso, a Fibra fez várias otimizações em termos de privacidade e segurança. Além disso, a Fibra e a Lightning Network do BTC podem se interconectar, formando uma rede P2P maior. Os funcionários da CKB até mencionaram que planejam instalar 100.000 nós físicos na Fibra e na Lightning Network durante eventos offline para aprimorar e avançar a rede de pagamentos P2P. Isso sem dúvida representa uma história grandiosa e sem precedentes.

Se a visão oficial da CKB for realizada no futuro, isso seria uma grande vantagem para a Lightning Network, CKB e o ecossistema Bitcoin em geral. De acordo com dados da mempool, a Lightning Network do BTC atualmente possui mais de $300 milhões em fundos, com aproximadamente 12.000 nós e quase 50.000 canais de pagamento estabelecidos entre eles.

No spendmybtc.com, podemos observar que um número crescente de comerciantes está a apoiar pagamentos da Rede Lightning. À medida que o reconhecimento do BTC cresce, o aumento das soluções de pagamento fora da cadeia, como a Rede Lightning e a Fiber, provavelmente ganhará impulso. Para analisar sistematicamente a solução técnica da Fiber, o “Geek Web3” produziu este relatório de pesquisa sobre a solução geral da Fiber. Como uma implementação da Rede Lightning baseada em CKB, os princípios da Fiber são em grande parte consistentes com a Rede Lightning do Bitcoin, mas incluem otimizações em muitos detalhes. A arquitetura geral da Fiber é composta por quatro componentes principais: canais de pagamento, WatchTower, roteamento de vários saltos e pagamentos entre domínios. Vamos começar explicando o componente mais importante: canais de pagamento.

A Fundação da Rede Lightning e Fiber: Canais de Pagamento

Os canais de pagamento essencialmente movem as transações para fora da cadeia, com o estado final liquidado on-chain após algum tempo. Como as transações são concluídas off-chain, muitas vezes ignoram as limitações de desempenho da cadeia principal, como o BTC. Por exemplo, se Alice e Bob abrirem um canal juntos, eles primeiro criam uma conta multi-assinatura on-chain e depositam alguns fundos, digamos, 100 unidades cada, como seu saldo no canal off-chain. Eles podem então realizar várias transações dentro do canal e, quando fecham o canal, sincronizam os saldos finais on-chain, com a conta multiassinatura fazendo pagamentos para ambas as partes — esta é a "liquidação".

Por exemplo, se ambas as partes começarem com 100 unidades cada, e Alice transfere 50 unidades para Bob, seguido por outra transferência de 10 unidades, e então Bob transfere 30 unidades de volta para Alice, seus saldos finais seriam: Alice - 70 unidades, Bob - 130 unidades. O saldo total permanece inalterado, como ilustrado pelo exemplo de contas de ábaco. Se uma das partes sair do canal, os saldos finais (Alice: 70, Bob: 130) são sincronizados on-chain, e as 200 unidades da conta multi-assinatura são distribuídas de acordo com esses saldos finais para completar o acordo.

Embora este processo pareça simples, na prática envolve considerações complexas. Não se pode prever quando a outra parte escolherá sair do canal. Por exemplo, o Bob poderia sair após a segunda transação ou mesmo após a primeira, uma vez que o canal permite que os participantes saiam livremente. Para lidar com isso, o sistema assume que qualquer pessoa pode sair a qualquer momento, e qualquer uma das partes poderia submeter o saldo final à cadeia para liquidação. Isto é gerido através de “transações de compromisso”, que registam os saldos mais recentes no canal. Cada transação gera uma transação de compromisso correspondente. Para sair do canal, submete a transação de compromisso mais recente à cadeia para retirar a sua parte da conta multi-assinatura.

Podemos concluir que as transações de compromisso são usadas para liquidar os saldos de ambas as partes no canal on-chain, com qualquer uma das partes capaz de submeter a última transação de compromisso para sair do canal. No entanto, há um cenário malicioso crucial: Bob pode submeter um saldo desatualizado e uma transação de compromisso para a cadeia. Por exemplo, após gerar Commit Tx3, o saldo de Bob é de 130 unidades. Mas, para sua vantagem, Bob pode submeter o Commit Tx2 desatualizado, que mostra um saldo de 160 unidades. Este saldo desatualizado representa um ataque clássico de "gasto duplo".

Para evitar estes cenários de duplicação de despesas, devem ser previstas medidas sancionatórias adequadas. O desenho dessas medidas de penalidade está no centro do sistema de canais de pagamento um-para-um, e entender isso é essencial para entender como os canais de pagamento funcionam. No design do canal, se uma das partes apresentar uma transação de estado e compromisso desatualizada para a cadeia, em vez de beneficiar, descobrirá que a outra parte pode retirar todos os fundos. Isso utiliza os conceitos de "transações de compromisso assimétricas" e "chaves de revogação", que são cruciais. Vamos primeiro explicar "transações de compromisso assimétricas" usando Commit Tx3 como exemplo.

Nesse cenário, Bob cria uma transação de compromisso e a envia para Alice para seu manuseio. Como mostrado, esta transação envolve uma transferência Bitcoin, declarando que 70 unidades da conta multi-assinatura são alocadas para Alice e 130 unidades para Bob. No entanto, as condições de desbloqueio são "assimétricas", colocando restrições mais duras em Alice e beneficiando Bob.

Quando Alice recebe a transação de compromisso de Bob, ela pode adicionar sua assinatura para atender ao requisito de multiassinatura 2/2. Alice pode então optar por submeter esta transação de compromisso on-chain para sair do canal. Alternativamente, ela pode continuar a fazer transações dentro do canal se não a submeter.

É crucial notar que esta transação de compromisso é construída por Bob e tem condições desfavoráveis para Alice. Alice tem a escolha de aceitar ou rejeitá-la, mas precisamos garantir que ela mantenha alguma autonomia. No design dos canais de pagamento, apenas Alice pode submeter a transação de compromisso "desfavorável" à cadeia, porque as transações de compromisso requerem uma multi-assinatura 2/2. Depois de Bob construir a transação localmente, ela só terá a sua assinatura e faltará a assinatura de Alice.

Alice pode "aceitar a assinatura de Bob, mas reter a sua". Isto é semelhante a um contrato que exige assinaturas duplas. Se Bob assinar primeiro e enviar o contrato para Alice, ela pode optar por não fornecer sua assinatura. Para tornar o contrato efetivo, Alice precisaria assiná-lo e depois submetê-lo; caso contrário, pode abster-se de o assinar ou de o apresentar. Assim, neste caso, Alice tem os meios para limitar as ações de Bob.

O ponto chave aqui é: Cada vez que ocorre uma transação dentro do canal, um par de transações de compromisso é gerado, com duas versões espelhadas, como ilustrado abaixo. Alice e Bob podem cada um criar transações de compromisso que lhes sejam favoráveis, especificando os seus saldos ou montantes a receber na saída, e depois enviar estas transações um ao outro para serem tratadas.

Curiosamente, enquanto as duas transações de compromisso declaram o mesmo “montante a ser recebido na saída,” suas condições de retirada diferem. Isso ilustra o conceito de “transações de compromisso assimétricas” mencionado anteriormente.

Como explicado anteriormente, cada transação de compromisso requer uma assinatura múltipla 2/2 para ser válida. A transação de compromisso criada por Bob que favorece a si mesmo não atende ao requisito de assinatura múltipla 2/2, enquanto a transação de compromisso que atende a esse requisito é mantida por Alice e só pode ser enviada por ela, criando um mecanismo de verificação e equilíbrio. A mesma lógica se aplica ao contrário.

Assim, Alice e Bob só podem enviar transações de compromisso que sejam desfavoráveis a eles mesmos. Se qualquer uma das partes enviar uma transação de compromisso para a cadeia e ela se tornar efetiva, o canal é fechado.

Em relação ao cenário de "gasto duplo" discutido anteriormente, se alguém enviar uma transação de compromisso desatualizada para a cadeia, o conceito de "chaves de revogação" entra em jogo. Por exemplo, se Bob enviar o Tx2 desatualizado para a cadeia, Alice pode usar a chave de revogação associada ao Tx2 para retirar os fundos que Bob deveria receber.

No diagrama de exemplo, supondo que a última transação de compromisso seja Commit Tx3 e Tx2 esteja desatualizado, se Bob enviar o Tx2 desatualizado, Alice pode agir dentro do período de bloqueio de tempo usando a chave de revogação do Tx2 para retirar os fundos de Bob.

Em relação ao último Tx3, Alice não possui sua chave de revogação e só a receberá depois que o Tx4 for criado no futuro. Isso ocorre devido à natureza da criptografia de chave pública/privada e às propriedades UTXO. Por brevidade, os detalhes de implementação das chaves de revogação não são discutidos aqui.

A conclusão principal é que, se Bob ousar enviar uma transação de compromisso desatualizada para a cadeia, Alice pode usar a chave de revogação para retirar os fundos de Bob como penalidade. Da mesma forma, se Alice agir maliciosamente, Bob pode aplicar a mesma penalidade contra ela. Esse mecanismo garante que os canais de pagamento um a um evitem efetivamente a dupla despesa, pois os participantes racionais evitariam ações maliciosas.

Neste contexto, a Fiber, baseada em CKB, oferece melhorias substanciais em relação à Lightning Network do Bitcoin. Ela suporta nativamente transações e transferências de vários tipos de ativos, incluindo CKB, BTC e stablecoins RGB++, enquanto a Lightning Network suporta apenas o Bitcoin nativamente. Mesmo com a atualização Taproot Asset, a Lightning Network do Bitcoin ainda não pode suportar nativamente ativos não BTC e só pode suportar stablecoins indiretamente.

(Fonte das imagens: Dapangdun) Além disso, como o Fiber depende do CKB como sua cadeia principal de Camada 1, as taxas para a abertura e fecho de canais são significativamente mais baixas em comparação com a Rede Lightning BTC. Isso reduz os custos de transação do usuário, representando uma clara vantagem em termos de experiência do usuário (UX).

Segurança 24/7: WatchTower

Um desafio com chaves de revogação é que os participantes do canal devem monitorar constantemente uns aos outros para evitar a submissão de transações de compromisso desatualizadas. No entanto, ninguém pode estar online 24/7, então o que acontece se uma parte age maliciosamente enquanto a outra está offline? Tanto a Fiber quanto a Bitcoin Lightning Network abordam esse problema com o design dos WatchTowers.

Os WatchTowers são projetados para monitorar as atividades on-chain 24 horas por dia. Se alguém submeter uma transação de compromisso desatualizada, o WatchTower tomará uma ação oportuna para proteger o canal e os fundos. Veja como funciona:

Após a criação de uma transação de compromisso atualizada, Alice ou Bob podem preparar antecipadamente uma transação de penalidade correspondente (usando a chave de revogação para lidar com a transação de compromisso desatualizada, com o beneficiário declarado como eles próprios). Em seguida, eles fornecem o texto sem formatação dessa transação de penalidade para a WatchTower.

Quando o WatchTower deteta uma transação de compromisso desatualizada sendo submetida à cadeia, também submeterá a transação de penalização preparada, aplicando a penalização e salvaguardando a integridade do canal.

A Fiber protege a privacidade dos participantes, exigindo que os usuários enviem apenas o “hash da transação de compromisso desatualizada + texto simples da transação de penalidade” para o WatchTower. Dessa forma, o WatchTower inicialmente só conhece o hash da transação de compromisso, não o seu texto simples. O WatchTower só vê o texto simples se alguém realmente enviar a transação de compromisso desatualizada na cadeia, momento em que também enviará a transação de penalidade. Isso garante que o WatchTower só verá o registro de transação de um participante se houver má conduta real e, mesmo assim, verá apenas uma única transação.

Em termos de otimização, a Fiber melhora a abordagem da Bitcoin Lightning Network aos mecanismos de penalização. O "LN-Penalty" da Lightning Network tem uma desvantagem notável: as WatchTowers devem armazenar todos os hashes de transações de compromisso desatualizados e as chaves de revogação correspondentes, levando a uma pressão de armazenamento significativa. Em 2018, a comunidade Bitcoin propôs uma solução chamada "eltoo" para resolver esse problema. A Eltoo permitiria que a última transação de compromisso penalizasse as desatualizadas, reduzindo a necessidade de armazenar todas as transações anteriores. No entanto, esta solução requer a ativação do SIGHASH_ANYPREVOUT opcode, que ainda não foi implementado.

Por outro lado, a Fiber utiliza o protocolo Daric, que modifica o design da chave de revogação para que uma única chave de revogação seja aplicável a várias transações de compromisso desatualizadas. Esta abordagem reduz consideravelmente as exigências de armazenamento para WatchTowers e clientes.

Relativamente aos sistemas de tráfego de rede: Os canais de pagamento são adequados para transações de um para um, mas a Lightning Network suporta pagamentos multi-hop, permitindo transações entre partes que não têm um canal direto, encaminhando-se através de nós intermediários. Por exemplo, se Alice e Ken não têm um canal direto, mas Ken e Bob têm, e Bob e Alice têm, Bob pode atuar como intermediário para facilitar transações entre Alice e Ken.

O “roaming multi-hop” melhora a flexibilidade e a cobertura da rede. No entanto, os remetentes precisam estar cientes do status de todos os nós e canais públicos. No Fiber, a estrutura inteira da rede, incluindo todos os canais públicos, é totalmente transparente, permitindo que qualquer nó acesse informações da rede de outros nós. Como o estado da rede na Lightning Network está em constante mudança, o Fiber usa o algoritmo de Dijkstra para encontrar o caminho de roteamento mais curto, minimizando o número de intermediários e estabelecendo um caminho de transação entre as duas partes.

Para resolver o problema da confiança com os intermediários: Como pode garantir que são honestos? Por exemplo, se Alice precisa fazer um pagamento de 100 unidades para Ken, mas Bob, que é um intermediário entre eles, pode reter os fundos. HTLC e PTLC são usados para evitar esse comportamento malicioso. Suponhamos que Alice queira pagar a Daniel 100 unidades, mas elas não têm um canal direto. Alice descobre que pode encaminhar o pagamento através dos intermediários Bob e Carol. HTLC é introduzido como o canal de pagamento: Alice primeiro inicia o pedido para Daniel, que então fornece a Alice um hash r, mas Alice não sabe a pré-imagem R correspondente a r.

Então, Alice constrói os termos de pagamento com Bob via HTLC: Alice está disposta a pagar a Bob 102 unidades, mas Bob deve revelar a chave R dentro de 30 minutos; caso contrário, Alice irá retirar o dinheiro. Da mesma forma, Bob cria um HTLC com Carol: Bob pagará a Carol 101 unidades, mas Carol deve revelar a chave R dentro de 25 minutos; caso contrário, Bob irá retirar o dinheiro. Carol faz o mesmo com Daniel: Carol está disposta a pagar a Daniel 100 unidades, mas Daniel deve revelar a chave R dentro de 20 minutos; caso contrário, Carol irá retirar o dinheiro.

Daniel percebe que a chave R pedida por Carol é na verdade o que Alice quer, já que apenas Alice está interessada no valor de R. Assim, Daniel coopera com Carol, fornece a chave R e recebe 100 unidades de Carol. Dessa forma, Alice alcança seu objetivo de pagar 100 unidades a Daniel.

Posteriormente, Carol fornece a chave R a Bob e recebe 101 unidades. Bob então fornece a chave R a Alice e recebe 102 unidades. Observando os ganhos e perdas para todos, Alice perde 102 unidades, Bob e Carol ganham 1 unidade líquida cada, e Daniel recebe 100 unidades. A 1 unidade ganha por Bob e Carol é sua taxa extraída de Alice.

Mesmo que alguém no caminho de pagamento, como a Carol, falhe em fornecer a chave R para o downstream Bob, isso não resulta em perda para Bob: após o tempo limite, Bob pode retirar o HTLC que ele construiu. O mesmo se aplica a Alice. No entanto, a Lightning Network tem seus problemas: os caminhos não devem ser muito longos. Se o caminho for muito extenso, com muitos intermediários, pode reduzir a confiabilidade do pagamento. Alguns intermediários podem estar offline ou não ter saldo suficiente para construir um HTLC específico (por exemplo, cada intermediário no exemplo anterior precisa ter mais de 100 unidades). Portanto, adicionar mais intermediários aumenta a probabilidade de erros.

Além disso, os HTLCs podem comprometer a privacidade. Embora o roteamento de cebola possa fornecer alguma proteção de privacidade, criptografando as informações de roteamento em cada salto, de modo que cada participante conheça apenas seus vizinhos imediatos e não o caminho completo, os HTLCs ainda são susceptíveis a inferência de relacionamentos. De uma perspectiva mais elevada, o caminho completo de roteamento ainda pode ser deduzido.

Suponha que Bob e Daniel são controlados pela mesma entidade e recebem muitos HTLCs todos os dias. Eles notam que a chave R solicitada por Alice e Carol é sempre a mesma, e que o nó a jusante Eve, conectado a Daniel, sempre sabe o conteúdo da chave R. Portanto, Daniel e Bob podem inferir que existe um caminho de pagamento entre Alice e Eva, pois eles lidam sempre com a mesma chave e podem monitorar seu relacionamento. Para resolver isso, a Fiber usa PTLCs, que aumentam a privacidade sobre HTLCs usando chaves diferentes para desbloquear cada PTLC no caminho de pagamento. A observação de PTLCs por si só não pode determinar as relações entre nós. Ao combinar PTLCs com roteamento de cebola, a fibra se torna uma solução ideal para pagamentos que preservam a privacidade.

Além disso, a Lightning Network tradicional é vulnerável a um "ataque de ciclo de substituição", que pode resultar no roubo de ativos de intermediários no caminho de pagamento. Esse problema levou o desenvolvedor Antoine Riard a se retirar do desenvolvimento da Lightning Network. A partir de agora, a Bitcoin Lightning Network carece de uma solução fundamental para este problema, tornando-o um ponto problemático. Atualmente, o CKB aborda esse cenário de ataque por meio de melhorias no nível do pool de transações, permitindo que a Fiber mitiGate o problema. Como o ataque de ciclismo de substituição e suas soluções são bastante complexos, este artigo não se aprofundará mais nele. Os leitores interessados podem consultar artigos relacionados do BTCStudy e recursos oficiais do CKB para obter mais informações.

No geral, Fiber representa uma melhoria significativa em relação à rede Lightning tradicional, tanto em termos de privacidade quanto de segurança. Fiber melhora os pagamentos atômicos entre domínios cruzados entre si e a Rede Lightning do Bitcoin.

Usando HTLC e PTLC, a Fiber pode alcançar pagamentos entre domínios com a Bitcoin Lightning Network, garantindo "atomicidade de ações entre domínios", o que significa que todas as etapas da transação entre domínios são totalmente bem-sucedidas ou totalmente falhadas, sem sucesso ou falha parcial. Com a atomicidade entre domínios assegurada, o risco de perda de ativos é mitiGated. Isso permite que a Fiber se interconecte com a Bitcoin Lightning Network, permitindo pagamentos diretos da Fiber para usuários na BTC Lightning Network (com o recetor limitado a BTC) e permitindo conversões de CK

Ativos B e RGB++ em Bitcoin equivalente dentro da Rede Lightning BTC.

Aqui está uma explicação simplificada do processo: Suponha que Alice opera um nó dentro da rede Fiber e Bob opera um nó dentro da Rede Bitcoin Lightning. Se Alice quiser transferir algum dinheiro para Bob, ela pode fazer isso por meio de um intermediário entre domínios, Ingrid. Ingrid executará nós tanto nas redes Fiber quanto na BTC Lightning, atuando como intermediário no caminho de pagamento.

Se Bob quiser receber 1 BTC, Alice pode negociar uma taxa de câmbio com Ingrid, estabelecendo 1 CKB igual a 1 BTC. Alice então enviaria 1.1 CKB para Ingrid dentro da rede Fiber, e Ingrid enviaria 1 BTC para Bob na Rede Lightning do Bitcoin, mantendo 0.1 CKB como taxa.

O processo envolve estabelecer um caminho de pagamento entre Alice, Ingrid e Bob, usando HTLC. Bob deve fornecer a Ingrid a chave R para receber os fundos. Assim que Ingrid tiver a chave R, ela pode desbloquear os fundos que Alice bloqueou no HTLC.

As ações entre domínios cruzados entre a Rede Lightning BTC e a Fiber são atômicas, o que significa que ambos os HTLCs são desbloqueados e o pagamento entre domínios cruzados é executado com sucesso, ou nenhum é desbloqueado e o pagamento falha. Isso garante que Alice não perca dinheiro se Bob não o receber.

Ingrid poderia potencialmente não desbloquear o HTLC de Alice depois de conhecer a chave R, mas isso prejudicaria Ingrid, não Alice. Portanto, o design do Fiber garante segurança para os usuários e não exige confiança em terceiros, possibilitando transferências entre diferentes redes P2P com modificações mínimas.

Outras vantagens do Fiber em comparação com BTC Lightning Network

Anteriormente, mencionamos que a Fiber suporta ativos nativos CKB e ativos RGB++ (especialmente stablecoins), o que lhe confere um potencial significativo para pagamentos em tempo real e a torna adequada para transações diárias de pequeno porte.

Em contraste, um problema importante com a Rede Lightning do Bitcoin é a gestão da liquidez. Como discutimos no início, o saldo total em um canal de pagamento é fixo. Se o saldo de uma das partes for esgotado, ela não pode transferir fundos para a outra parte a menos que a outra parte envie dinheiro primeiro. Isso requer recarregar fundos ou abrir um novo canal.

Além disso, numa rede complexa de vários saltos, se alguns nós intermédios tiverem saldo insuficiente e não puderem encaminhar pagamentos, isso pode fazer com que todo o percurso de pagamento falhe. Este é um dos pontos problemáticos da Lightning Network. A solução típica envolve a implementação de mecanismos eficientes de injeção de liquidez para garantir que a maioria dos nós possa injetar fundos conforme necessário.

No entanto, na Bitcoin Lightning Network, a injeção de liquidez, bem como a abertura ou fechamento do canal, ocorrem no blockchain do Bitcoin. Se as taxas da rede Bitcoin são muito altas, isso afeta negativamente a experiência do usuário dos canais de pagamento. Por exemplo, se você quiser abrir um canal com uma capacidade de US $ 100, mas a taxa de configuração é de US $ 10, isso significa que 10% de seus fundos são consumidos apenas para configurar o canal, o que é inaceitável para a maioria dos usuários. A mesma questão se aplica à injeção de liquidez.

Em contraste, o Fiber oferece vantagens significativas. Em primeiro lugar, o TPS (transações por segundo) do CKB é muito maior do que o do Bitcoin, com taxas chegando a custos em centavos. Em segundo lugar, para resolver o problema de escassez de liquidez e garantir transações suaves, o Fiber planeja colaborar com a Mercury Layer para introduzir novas soluções que eliminem a necessidade de operações on-chain para injeção de liquidez, solucionando assim problemas de UX e custo.

Agora, sistematicamente delineamos a arquitetura técnica geral da Fiber, com um resumo comparando-a à Rede Lightning do Bitcoin, conforme mostrado na imagem acima. Dada a complexidade e amplitude dos tópicos abordados pela Fiber e pela Rede Lightning, um único artigo pode não ser capaz de abordar todos os aspectos. No futuro, lançaremos uma série de artigos com foco em vários aspectos tanto da Rede Lightning quanto da Fiber. Fique atento para mais atualizações.

Aviso Legal:

1. Este artigo é reproduzido a partir de [极客web3].Encaminhe o título original 'Sistema de interpretação Fiber: Um experimento grandioso para conectar a rede relâmpago à CKB'. Todos os direitos autorais pertencem ao autor original [Faust & Nickqiao, 极客web3]. Se houver objeções a esta reimpressão, entre em contato com o Gate Aprenderequipa, e eles vão lidar com isso prontamente.
2. Aviso de responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outras línguas são feitas pela equipe Gate Learn. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.