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. Essa notícia rapidamente provocou intensas discussões na comunidade, levando a um aumento de quase 30% no preço da CKB em um único 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 menores taxas de transação da CKB e 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 representantes da CKB até mencionaram que planejam estabelecer 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 representa, sem dúvida, uma história grandiosa e sem precedentes.

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

Em spendmybtc.com, podemos observar que um número crescente de comerciantes está apoiando pagamentos da Lightning Network. À medida que o reconhecimento do BTC cresce, o surgimento de soluções de pagamento off-chain como a Lightning Network e a Fiber provavelmente ganhará impulso. Para analisar sistematicamente a solução técnica da Fiber, a “Geek Web3” produziu este relatório de pesquisa sobre a solução geral da Fiber. Como uma implementação da Lightning Network baseada em CKB, os princípios da Fiber são amplamente consistentes com a Lightning Network do Bitcoin, mas incluem otimizações em muitos detalhes. A arquitetura geral da Fiber é composta por quatro componentes principais: canais de pagamento, WatchTower, roteamento multi-hop e pagamentos multi-domínio. Vamos começar explicando o componente mais importante: canais de pagamento.

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

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

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, conforme ilustrado pelo exemplo de ábaco. Se uma das partes sair do canal, os saldos finais (Alice: 70, Bob: 130) são sincronizados na cadeia, e as 200 unidades da conta multi-assinatura são distribuídas de acordo com esses saldos finais para completar o ajuste.

Embora esse processo pareça simples, na prática envolve considerações complexas. Não é possível prever quando a outra parte escolherá sair do canal. Por exemplo, Bob poderia sair após a segunda transação ou até mesmo após a primeira, já 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 enviar o saldo final para a cadeia para liquidação. Isso é gerenciado por meio de “transações de compromisso”, que registram os saldos mais recentes no canal. Cada transação gera uma transação de compromisso correspondente. Para sair do canal, você envia a transação de compromisso mais recente para a cadeia para retirar 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 enviar a última transação de compromisso para sair do canal. No entanto, há um cenário malicioso crucial: Bob pode enviar um saldo desatualizado e uma transação de compromisso para a cadeia. Por exemplo, depois de gerar o Commit Tx3, o saldo de Bob é de 130 unidades. Mas, para sua vantagem, Bob pode enviar o Commit Tx2 desatualizado, que mostra um saldo de 160 unidades. Esse saldo desatualizado representa um ataque clássico de “double-spending”.

Para evitar tais cenários de gasto duplo, devem existir medidas de penalidade apropriadas. O design dessas medidas de penalidade está no cerne do sistema de canal de pagamento um para um, e entender isso é essencial para compreender como os canais de pagamento funcionam. No design do canal, se uma das partes enviar um estado desatualizado e uma transação de compromisso para a cadeia, em vez de se beneficiar, descobrirá que a outra parte pode sacar 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 as “transações de compromisso assimétricas” usando o Commit Tx3 como exemplo.

Nesse cenário, Bob cria uma transação de compromisso e a envia para Alice para que ela a resolva. Como mostrado, essa transação envolve uma transferência de 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", impondo restrições mais rígidas a Alice e beneficiando Bob.

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

É crucial observar que essa transação de compromisso é construída por Bob e possui condições desfavoráveis a Alice. Alice tem a escolha de aceitar ou rejeitá-la, mas precisamos garantir que ela mantenha alguma autonomia. No projeto dos canais de pagamento, apenas Alice pode enviar a transação de compromisso "desfavorável" à cadeia, pois as transações de compromisso requerem uma assinatura multi-assinada 2/2. Depois que Bob constrói a transação localmente, ela possui apenas sua assinatura e falta a assinatura de Alice.

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

Aqui está o ponto-chave: 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 criar cada um transações de compromisso que sejam favoráveis a si mesmos, especificando seus respectivos saldos ou quantias a serem recebidas ao sair, e então enviar essas transações um ao outro para processamento.

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

Como explicado anteriormente, cada transação de compromisso requer uma multi-assinatura 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 multi-assinatura 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 cheque e equilíbrio. A mesma lógica se aplica inversamente.

Assim, Alice e Bob só podem enviar transações de compromisso que são desfavoráveis a si 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 "gastos duplos" discutido anteriormente, se alguém apresentar 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 exemplo do diagrama, supondo que a última transação de compromisso seja Commit Tx3 e Tx2 esteja desatualizada, se Bob enviar a Tx2 desatualizada, Alice pode agir dentro do período de bloqueio de tempo usando a chave de revogação da 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á após a criação do Tx4 no futuro. Isso ocorre devido à natureza da criptografia de chave pública/privada e das propriedades UTXO. Por brevidade, os detalhes de implementação das chaves de revogação não são discutidos aqui.

A ideia 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 de forma maliciosa, Bob pode aplicar a mesma penalidade contra ela. Esse mecanismo garante que os canais de pagamento um a um evitem efetivamente gastos duplos, pois participantes racionais evitariam ações maliciosas.

Nesse 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 nativamente apenas Bitcoin. Mesmo com a atualização de ativos Taproot, 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 abrir e fechar canais são significativamente menores em comparação com a Rede Lightning do BTC. Isso reduz os custos de transação do usuário, representando uma clara vantagem em termos de experiência do usuário (UX).

24/7 segurança: 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 comprometimento 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 o Fiber quanto a Rede Lightning do Bitcoin 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 enviar uma transação de compromisso desatualizada, o WatchTower tomará uma ação oportuna para proteger o canal e os fundos. Aqui está como funciona:

Após a transação de compromisso concluída, 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 mesmos). Em seguida, eles fornecem o texto simples dessa transação de penalidade ao WatchTower.

Quando o WatchTower detecta que uma transação de compromisso desatualizada está sendo enviada à cadeia, ele também envia a transação de penalidade preparada, impondo a penalidade e protegendo a integridade do canal.

O 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 a WatchTower. Dessa forma, a WatchTower inicialmente só conhece o hash da transação de compromisso, não o seu texto simples. A 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 a WatchTower só verá o histórico de transações de um participante se houver uma má conduta real e, mesmo assim, verá apenas uma única transação.

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

Por outro lado, a Fiber emprega o protocolo Daric, que modifica o design da chave de revogação para tornar uma única chave de revogação aplicável a várias transações de compromisso desatualizadas. Essa abordagem reduz significativamente as demandas de armazenamento para WatchTowers e clientes do usuário.

Sobre sistemas de tráfego de rede: Canais de pagamento são adequados para transações de um para um, mas a Rede Relâmpago suporta pagamentos de várias etapas, permitindo transações entre partes que não possuem um canal direto, roteando 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 'roteamento de múltiplos saltos' aumenta 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 de toda a 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 lidar com a questão da confiança nos intermediários: como garantir que eles sejam 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. Suponha que Alice queira pagar a Daniel 100 unidades, mas eles não têm um canal direto. Alice descobre que pode encaminhar o pagamento por meio dos intermediários Bob e Carol. O HTLC é introduzido como o canal de pagamento: Alice primeiro inicia a solicitação para Daniel, que então fornece a Alice um hash r, mas Alice não sabe a imagem anterior R correspondente a r.

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

Daniel entende que a chave R solicitada por Carol é na verdade o que Alice quer, pois apenas Alice está interessada no valor de R. Então, 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 para Bob e recebe 101 unidades. Bob então fornece a chave R para Alice e recebe 102 unidades. Observando os ganhos e perdas de todos, Alice perde 102 unidades, Bob e Carol cada um ganham um líquido de 1 unidade, 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 do pagamento, como Carol, não forneça a chave R para o downstream Bob, isso não resulta em perda para Bob: após o tempo limite, Bob pode sacar o HTLC que 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 longo 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 vazar privacidade. Embora o roteamento de cebola possa fornecer alguma proteção de privacidade, criptografando as informações de roteamento em cada salto, para que cada participante conheça apenas seus vizinhos imediatos e não o caminho completo, os HTLCs ainda são suscetíveis a inferências de relacionamentos. De uma perspectiva mais ampla, o caminho de roteamento completo ainda pode ser deduzido.

Suponha que Bob e Daniel sejam controlados pela mesma entidade e recebam muitos HTLCs todos os dias. Eles percebem que a chave R solicitada por Alice e Carol é sempre a mesma e que o nó downstream Eve, conectado a Daniel, sempre conhece o conteúdo da chave R. Portanto, Daniel e Bob podem inferir que existe um caminho de pagamento entre Alice e Eve, já que sempre lidam com a mesma chave e podem monitorar seu relacionamento. Para resolver isso, o Fiber usa PTLCs, que melhoram a privacidade sobre os HTLCs usando chaves diferentes para desbloquear cada PTLC no caminho de pagamento. Observar apenas os PTLCs não pode determinar os relacionamentos entre os nós. Ao combinar os PTLCs com o roteamento de cebola, o Fiber se torna uma solução ideal para pagamentos que preservam a privacidade.

Além disso, a tradicional Lightning Network é vulnerável a um “ataque de ciclagem de substituição”, que pode resultar no roubo de ativos de intermediários no caminho de pagamento. Este problema levou o desenvolvedor Antoine Riard a se retirar do desenvolvimento da Lightning Network. Até o momento, a Lightning Network do Bitcoin carece de uma solução fundamental para esse problema, tornando-se um ponto doloroso. Atualmente, o CKB aborda esse cenário de ataque por meio de melhorias no nível da pool de transações, permitindo que a Fiber mitigue o problema. Como o ataque de ciclagem de substituição e suas soluções são bastante complexos, este artigo não entrará mais a fundo nisso. Leitores interessados podem consultar artigos relacionados do BTCStudy e recursos oficiais do CKB para mais informações.

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

Usando HTLC e PTLC, o Fiber pode alcançar pagamentos entre domínios com a Rede Lightning do Bitcoin, garantindo a 'atomicidade das 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 falham, sem sucesso ou falha parcial. Com a atomicidade entre domínios assegurada, o risco de perda de ativos é mitigado. Isso permite que o Fiber se interconecte com a Rede Lightning do Bitcoin, possibilitando pagamentos diretos do Fiber para usuários na Rede Lightning do BTC (com o receptor limitado ao BTC) e permitindo a conversão de CKB.

Conversão de ativos B e RGB++ em Bitcoin equivalente dentro da Rede Lightning BTC.

Aqui está uma explicação simplificada do processo: Suponha que Alice opere um nó dentro da rede Fiber, e Bob opere 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 de domínio cruzado, Ingrid. Ingrid executará nós tanto na rede Fiber quanto na BTC Lightning Networks, atuando como intermediária no caminho de pagamento.

Se Bob quer 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. Uma vez que Ingrid tenha a chave R, ela pode desbloquear os fundos que Alice bloqueou no HTLC.

As ações 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 interdomínio é executado com sucesso, ou nenhum deles é 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 requer confiança em terceiros, permitindo transferências entre diferentes redes P2P com modificações mínimas.

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

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 valor.

Em contraste, um grande problema com a Rede Lightning do Bitcoin é a gestão de 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, em uma rede complexa de vários saltos, se alguns nós intermediários tiverem saldo insuficiente e não puderem encaminhar pagamentos, isso pode fazer com que todo o caminho de pagamento falhe. Este é um dos pontos problemáticos da Rede Lightning. 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 Lightning Network do Bitcoin, a injeção de liquidez, bem como a abertura ou fecho de canais, ocorrem todos na blockchain do Bitcoin. Se as taxas da rede Bitcoin forem muito altas, isso impacta negativamente a experiência do usuário dos canais de pagamento. Por exemplo, se você deseja abrir um canal com uma capacidade de $100, mas a taxa de configuração é de $10, isso significa que 10% dos seus fundos são consumidos apenas para configurar o canal, o que é inaceitável para a maioria dos usuários. O mesmo problema se aplica à injeção de liquidez.

Em contraste, a Fiber oferece vantagens significativas. Em primeiro lugar, o TPS (transações por segundo) da CKB é muito maior do que o do Bitcoin, com taxas atingindo custos de centavos. Em segundo lugar, para lidar com a falta de liquidez e garantir transações suaves, a 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 delineamos sistematicamente 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 tanto pela Fiber quanto pela Rede Lightning, um único artigo pode não ser capaz de abordar todos os aspectos. Estaremos lançando uma série de artigos no futuro, focando em vários aspectos tanto da Rede Lightning quanto da Fiber. Fique ligado para mais atualizações.

Aviso legal：

1. Este artigo é reproduzido a partir de [ 极客web3]. Encaminhe o Título Original ‘系统解读Fiber：把闪电网络嫁接到CKB上的宏大实验’. Todos os direitos autorais pertencem ao autor original [Fausto & Nickqiao,极客web3]. Se houver objeções a esta reimpressão, entre em contato com o Gate Aprenderequipe e eles irão lidar com isso prontamente.
2. Isenção 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 outros idiomas são feitas pela equipe Gate Learn. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.