Taxas de transação e arquitetura de rede como proteção contra spam
Ao contrário do Bitcoin ou Ethereum, que operam num mercado de taxas tradicional, Cardano emprega um sistema de taxas fixas e previsíveis. Essas taxas, embora não sejam exorbitantes, são fixadas em um nível que efetivamente dissuade ataques de spam. Por outro lado, as taxas de transação extremamente baixas de Solana são uma faca de dois gumes. Embora tornem as transações acessíveis, também levam a uma alta taxa de falhas – atualmente, cerca de 75% das transações dos usuários não são realizadas. A rede está inundada com transações geradas por bots.
Além das taxas de transação, a camada de rede desempenha um papel crucial na prevenção de transações de spam. O nó Cardano emprega mem-pool e seu protocolo é arquitetado de maneira orientada à demanda. Este design permite que cada nó, e cada peer vinculado a ele, regule a taxa de chegada de dados e a quantidade de dados pendentes. Por outro lado, Solana não utiliza mem-pool, em vez disso, todas as transações são direcionadas diretamente para os próximos validadores. Este artigo irá elucidar por que enviar spam para Solana é relativamente fácil, enquanto fazê-lo com Cardano é desafiador.
Como equilibrar inclusão e segurança?
Determinar as taxas corretas de uso da rede é um desafio que toda equipe de blockchain enfrenta. Estas taxas devem refletir os custos reais de utilização de recursos computacionais numa rede distribuída. A equipe deve considerar as necessidades tanto dos operadores de rede, que executam os nós produtores de blocos, quanto dos usuários. Embora as operadoras busquem recompensas máximas, os usuários preferem taxas mínimas. Equilibrar esses interesses é crucial.
Os mercados de taxas tradicionais, como os usados em Bitcoin ou Ethereum, têm uma desvantagem. Quando a utilização da rede aumenta, também aumentam as taxas, tornando a rede exclusiva e acessível apenas àqueles que podem arcar com custos elevados. Em contraste, Cardano emprega taxas fixas e previsíveis. Os usuários pagam a mesma taxa para transações do mesmo tamanho. A taxa compreende um componente fixo e um componente variável com base no tamanho da transação em bytes.
Para uma transação de 200 bytes no Cardano, a taxa é sempre exatamente 0,164271 ADA – nem mais, nem menos. Essa taxa equivale a aproximadamente US$ 0,1. À medida que o preço do ADA aumenta, também aumenta o valor em dólares da taxa.
Em comparação com Bitcoin ou Ethereum, que utilizam um mercado de taxas tradicional onde as taxas aumentam com a procura da rede, esta taxa é baixa. No Ethereum, as taxas podem variar de 1 a 100 USD (e mais), mesmo se a transação falhar.
A estrutura de taxas da Solana consiste em duas partes: uma taxa básica e uma taxa prioritária. A taxa básica é uma cobrança fixa por transação. Atualmente, a taxa básica está definida em 0,000005 SOL por assinatura. A taxa de prioridade é uma taxa adicional opcional que os usuários podem pagar para aumentar a probabilidade de sua transação ser incluída em um bloco. Isto é particularmente útil para transações urgentes.
As taxas são voláteis e podem mudar com o tempo. Semelhante às redes que utilizam o mercado de taxas, se a rede for mais utilizada, as taxas aumentam.
Atualmente, o custo de transação no Solana varia de 0,00001 a 0,00003 SOL, que é aproximadamente US$ 0,001 a US$ 0,005. Quando comparadas ao Cardano, as taxas da Solana são significativamente mais baixas, com uma diferença de cerca de 20 a 100 vezes.
Embora as taxas baixas sejam atraentes para os usuários, tornando Solana uma rede inclusiva, elas não protegem as transações de spam. Os bots podem enviar milhares de transações por dia por apenas alguns dólares. É por isso que atualmente 75% das transações dos usuários no Solana falham.
Outro aspecto crucial a considerar nas taxas de utilização da rede é a sustentabilidade económica a longo prazo de qualquer blockchain descentralizada. Isto implica que as taxas devem ser suficientes para cobrir os custos operacionais. Os baixos rendimentos das taxas podem ser contrabalançados pela inflação infinita das moedas, mas isso poderia potencialmente desvalorizar as moedas ao longo do tempo devido à inflação infinita.
Solana opera com inflação infinita de moedas, enquanto Cardano possui um número pré-determinado de moedas que circularão. Neste momento, é um desafio determinar qual estratégia é mais benéfica.
Voltando ao tópico da proteção de transações de spam, o mercado de taxas tradicional empregado pelo Bitcoin e pelo Ethereum serve como um impedimento eficaz contra transações de spam. Da mesma forma, as taxas do Cardano são relativamente altas, tornando dispendiosas as tentativas de spam na rede. No entanto, as taxas de Solana são tão baixas que o spam se torna um empreendimento barato.
Uma rede blockchain deve ser universalmente acessível e não discriminatória para com os seus utilizadores. Não requer nenhum procedimento Conheça seu Cliente (KYC). Em essência, a rede não pode censurar transações.
Qualquer usuário que pague por uma transação deve ter uma garantia razoável de que sua transação será incluída no próximo bloco. Portanto, a introdução de qualquer forma de filtro não é viável. A única restrição na utilização da rede são as taxas de transação.
Por que 75% das transações dos usuários falham no Solana?
Para que uma transação seja incluída em um bloco e registrada permanentemente no livro-razão, ela deve atravessar duas camadas subjacentes: a camada de rede e a camada de consenso.
Inicialmente, a transação é processada pela camada de rede no nó. Se atender com sucesso aos critérios de validação desta camada, ele segue para a camada de consenso. A camada de consenso tem a tarefa de determinar o conteúdo de novos blocos e chegar a um acordo sobre o bloco em todos os nós da rede.
Esses princípios são comuns a todas as redes blockchain, embora possam diferir em detalhes.
Em certas blockchains onde as transações exibem comportamento não determinístico, uma transação pode passar para a camada de consenso e ainda assim falhar depois. As razões para isso podem variar. Por exemplo, as condições para executar uma transação de contrato inteligente de acordo com as expectativas do utilizador podem não ser cumpridas. Portanto, a transação é executada, mas falha mesmo que o usuário tenha pago a taxa.
A questão actual com Solana não é que a camada de consenso esteja a abandonar as transacções. Em vez disso, as transações nem sequer passam da camada de rede para a camada de consenso. A camada de rede está tão congestionada que o nó opta por descartar uma parte das transações. Um nó se protege de ficar sobrecarregado e potencialmente travar, o que pode ocorrer devido ao esgotamento de recursos.
Os usuários que tentam utilizar o Solana geralmente descobrem que suas transações falham. Eles serão então solicitados a reenviar a transação, o que pode exigir várias tentativas. Isto ocorre principalmente porque eles estão competindo com transações geradas por bots. Os bots, por serem mais rápidos e capazes de gerar um volume de transações significativamente maior que os usuários, dominam a rede. Um grande número de transações geradas por bots está relacionada à arbitragem. Estima-se que apenas 10% das transações são geradas pelo usuário.
Na imagem, você pode ver como os bots e os usuários competem pelas transações que entram no bloco por meio da rede e das camadas de consenso.
Considere um cenário onde de 100 transações, 10 são de usuários e 90 são de bots. Se um nó decidir descartar 30% das transações, é possível que todas as transações do usuário sejam descartadas em um determinado momento. Se um nó estiver sobrecarregado, ele poderá decidir descartar ainda mais transações. Normalmente, é 50% das transações.
A rede Solana está operacional e os recursos computacionais dos nós não se esgotam com a queda de transações. Como resultado, não há necessidade de reiniciar a rede e o risco de falha do nó é baixo. Uma reinicialização também não resolveria o problema dos bots. O principal problema está na dificuldade que os usuários enfrentam ao tentar enviar transações. Apesar da rede estar funcionando, ela está essencialmente inutilizável. A maioria das transações que entram nos blocos são geradas por bots, sendo apenas algumas transações de usuários.
Na imagem, você pode ver transações vermelhas de bots e usuários que o nó abandonou e várias transações pretas apenas de bots que alcançaram a camada de consenso e têm chance de serem processadas com sucesso (e armazenadas no livro-razão).
É importante observar que, embora cada usuário normalmente tenha uma única conexão para enviar uma transação, os bots podem manter diversas conexões simultaneamente. Isso dá aos bots uma vantagem significativa.
Além disso, é comum que um único bot envie transações de spam para vários nós. Isso ocorre porque os bots pretendem que suas transações sejam processadas o mais rápido possível, e o envio de transações para vários nós aumenta a probabilidade de isso acontecer.
Decidir quais conexões um nó deve abandonar para evitar ficar sobrecarregado com transações é uma questão complexa. Na camada de rede, a análise do conteúdo da transação é um desafio devido aos recursos computacionais necessários para analisar o conteúdo da mensagem. Além disso, distinguir entre transações de usuários e aquelas geradas por bots é quase impossível. Os bots geram transações de spam, mas do ponto de vista da rede e da camada de consenso, pode ser uma transação válida que contém taxas. É uma transação de spam válida. A estratégia mais direta pode ser descartar transações aleatoriamente, mas isso não resolve o problema de maneira eficaz.
Quando um nó Solana abandona uma transação, a taxa de transação não é paga. Isso ocorre porque a taxa de transação só é cobrada quando uma transação é processada com sucesso e incluída em um bloco. Se uma transação for descartada antes de atingir a camada de consenso, é como se a transação nunca tivesse sido enviada e, portanto, nenhuma taxa será cobrada.
O desafio enfrentado pela equipe de Solana é que, mesmo quando as transações geradas por bots são incluídas em um bloco, as taxas associadas são insignificantes em comparação com os lucros potenciais da arbitragem. Isto é válido mesmo que a maioria das transações falhe na camada de consenso e as taxas sejam pagas.
Cálculos
Diariamente, Solana lida com aproximadamente 25 milhões de transações de usuários. A partir dessas transações, as taxas de usuário cobradas variam de US$ 25.000 a US$ 100.000.
Estima-se que as transações dos usuários representem cerca de 10% do total, com os bots respondendo por até 90%. Isso implica que os spammers precisariam gastar cerca de US$ 50.000 (250 SOL) por dia em taxas de transação.
A Ethereum, por outro lado, arrecada cerca de 400 ETH em taxas diárias, o que equivale a cerca de US$ 1,5 milhão. Portanto, enviar spam para Ethereum custaria cerca de 30 vezes mais do que enviar spam para Solana.
O protocolo Cardano cobra cerca de US$ 12.000 em taxas todos os dias. Isso é quase cinco vezes menos que Solana. Então, pode-se perguntar por que Cardano não está sobrecarregado com transações de spam. Iremos nos aprofundar na camada de rede para responder a isso na próxima seção do artigo.
É necessário perceber que se Cardano pudesse processar a mesma quantidade de transações que Solana, e esta capacidade pudesse ser alcançada com Endossantes de Entrada, a rede cobraria aproximadamente 2,5 milhões de dólares por dia em taxas. A proteção contra spam seria suficiente.
Um único bloco na blockchain Cardano pode acomodar aproximadamente 250-300 transações básicas. Se considerarmos uma taxa de transação de 0,1 USD para cada, Cardano receberia um rendimento de 25-30 USD por bloco. Dado que Cardano gera um novo bloco aproximadamente a cada 20 segundos, isto se traduz numa produção diária de 4.320 blocos. Se todos estes blocos fossem preenchidos exclusivamente com transações de spam válidas, o indivíduo que iniciasse o ataque incorreria em custos diários superiores a 100.000 USD em taxas de transação.
Arquitetura de Rede Solana
Na parte anterior do artigo falamos sobre a camada de rede apenas do ponto de vista do nó validador. Isso foi um pouco simplificado.
Tanto os usuários quanto os bots se conectam aos validadores por meio dos servidores RPC. Os usuários não sabem diretamente quem é o validador líder, então eles enviam suas transações para um servidor RPC que encaminha as transações para o validador atual e o próximo de acordo com a programação do líder. Este horário é conhecido antecipadamente.
Vamos traçar o ciclo de vida de uma transação Solana. As transações Solana não são focadas em um pool de memória como em outras redes. Em vez disso, eles devem ser enviados diretamente como um pacote UDP ao líder do protocolo de consenso. Os servidores RPC que conhecem o cronograma líder enviam, portanto, transações diretamente para os validadores que produzirão blocos na próxima rodada.
Solana tenta processar todas as transações enviadas o mais rápido possível. Em vez de difundir as transações para todos os nós (o que leva tempo), as transações são direcionadas para os próximos validadores com a suposição de que todas serão incluídas no próximo bloco.
Em termos mais simples, os validadores são vulneráveis a ataques de bots através de um número limitado de servidores RPC. Isso ocorre porque todas as transações são repassadas aos validadores subsequentes por esses servidores. Quando o volume de um ataque de spam ultrapassa a capacidade de alguns blocos Solana, resulta em congestionamento da rede. Consequentemente, os validadores começam a abandonar as transações.
Isso significa que os bots não precisam ter como alvo muitos validadores Solana, ou melhor, servidores RPC, em toda a rede, pois, por design, todas as novas transações são direcionadas para os próximos validadores, que podem rapidamente ficar inundados com transações.
Na imagem você pode ver como os servidores RPC encaminham todas as transações para o nó validador 1. Ele pode facilmente ficar sobrecarregado com transações e começar a descartá-las. Assim que o nó 1 produz um bloco, os servidores RPC enviam analogicamente todas as transações para o próximo validador, por exemplo, o nó 2. Simplifiquei para facilitar o entendimento.
A localização do envio de uma transação e o servidor RPC específico usado são irrelevantes, pois todos os servidores RPC visam encaminhar a transação para validadores subsequentes. Quando a rede está livre de congestionamentos, o sistema opera perfeitamente, fornecendo aos usuários confirmações de transações quase instantâneas. No entanto, a arquitetura da rede, aliada às taxas baixas, infelizmente a torna suscetível a spam.
É necessário acrescentar que, além das transações dos usuários, as transações de voto são uma parte crucial do mecanismo de consenso da rede Solana. Os validadores da rede Solana enviam votos uns aos outros para confirmar as transações. Esses votos são uma parte fundamental do mecanismo de consenso de Solana que confirma as transações.
Como Cardano é protegido contra transações de spam?
Além das taxas de transação apropriadas, a descentralização é a defesa mais eficaz contra ataques de spam. Com aproximadamente 3.000 pools, Cardano exemplifica isso. Cada pool, que é um nó produtor de blocos, geralmente está vinculado a 2 a 3 nós de retransmissão e é protegido por eles. Este arranjo impede a comunicação direta da rede com o nó produtor de blocos.
Os nós de retransmissão servem como proxies entre os nós principais da rede e a Internet, criando uma barreira de segurança em torno dos nós principais produtores de blocos.
Uma nova transação, uma vez submetida, é transferida de um nó retransmissor para um nó produtor de blocos. Esta transação é então difundida para todos os outros nós produtores de blocos, um processo que também ocorre através de nós de retransmissão.
Ao contrário do Solana, as transações não são processadas instantaneamente. Em vez disso, eles são mantidos em pools de memória em vários nós da rede. O próximo slot líder, que é o nó com o direito de cunhar um novo bloco, recupera as transações do mem-pool e as insere no novo bloco.
Na imagem você pode ver uma transação (caixa vermelha) que gradualmente atinge todos os mem-pools (caixa amarela) através da difusão gradual (setas vermelhas) da transação através dos nós de retransmissão. Simplifiquei a imagem para facilitar o entendimento.
A qualquer momento, o conteúdo dos pools de memória em todos os nós irá variar. Isso ocorre porque as transações são enviadas simultaneamente de vários locais e sua propagação leva tempo. Como resultado, cada mem-pool contém um conjunto de transações único, mas bastante semelhante.
Dos 3.000 nós produtores de blocos, cada um tem o potencial de produzir um novo bloco compreendendo um conjunto comparável de transações. O nó selecionado como próximo líder de slot será responsável pela produção deste novo bloco.
Você provavelmente terá a ideia de que um bot pode facilmente preencher os pools de memória de todos os outros nós da rede por meio de um nó, semelhante ao descrito na próxima imagem. Através do nó 1, todas as transações chegam ao nó 2 e depois ao nó 3.
Em um protocolo de estilo orientado por demanda como o Cardano, cada nó controla a taxa de chegada de dados, a simultaneidade máxima (número de tarefas simultâneas) e a quantidade de dados pendentes (dados que foram enviados, mas ainda não reconhecidos). Isso significa que cada nó só solicita mais trabalho quando está pronto, em vez de receber trabalho.
O protocolo nó a nó (NtN) transfere transações entre nós completos. NtN inclui três miniprotocolos (chain-sync, block-fetch e tx-submission), que são multiplexados em um único canal TCP.
NtN segue uma estratégia baseada em pull, onde o nó iniciador consulta novas transações e o nó respondedor responde com as transações, se houver. Este protocolo se adapta perfeitamente a um ambiente sem confiança, onde ambos os lados precisam ser protegidos contra ataques de consumo de recursos do outro lado.
Observe o contraste entre Cardano e Solana. No caso do Solana, os servidores RPC delegam tarefas aos validadores. No entanto, no cenário de Cardano, cada nó protege proativamente os seus recursos.
Cada nó tem a tarefa de verificar a transação antes de encaminhá-la. Se um nó despachar transações inválidas ou não solicitadas, ele será desconectado por outros nós. Para manter o mesmo número de conexões, tem a opção de estabelecer uma conexão com um nó diferente.
Se um bot despachar transações válidas para um único nó, ele poderá saturar o pool de memória desse nó. Assim que o pool de memória do nó estiver cheio, ele deixará de aceitar novas transações (não as adicionará ao pool de memória). Outros nós só começarão a extrair transações se tiverem espaço disponível em seus mem-pools. As transações que eles adquirem podem ser uma mistura daquelas geradas por bots e de usuários.
Um nó pode receber transações de usuários de seus nós de retransmissão. Se um nó tiver transações suficientes para preencher o pool de memórias, ele não precisará extrair transações de outros nós. Esta é a operação padrão para todos os nós da rede. Se um bot tivesse como alvo um único nó, não seria capaz de impedir que a maioria das transações do usuário fosse incluída em blocos subsequentes.
A probabilidade de ataques bem-sucedidos aumenta com o número de nós visados pelos bots, pois eles preencheriam mais pools de memória com transações de spam válidas. No entanto, isso complica e aumenta significativamente o custo do ataque.
Cada nó que opta por rejeitar transações, considerando-as geradas por bot, protege essencialmente outros nós da rede.
Na imagem, você pode ver que o bot envia transações de spam válidas para o nó 1. O pool de memória do nó 1 pode estar cheio de transações de spam válidas. Alice e Bob enviam transações de usuário válidas para o nó 3. O nó 3 tinha uma sala vazia no pool de memória e extraiu apenas uma transação de spam válida do nó 2. Se o nó 3 se tornasse o líder do slot na próxima rodada, a maioria das transações em o bloqueio seria dos usuários.
Quando um bot envia uma transação, ele é adicionado ao mem-pool, reservando efetivamente o ADA que foi usado como taxa de transação. O mem-pool Cardano tem o dobro da capacidade de um bloco, acomodando aproximadamente 500 a 600 transações. Se um bot pretende preencher 100 mem-pools com transações distintas, isso resultaria em um total de 60.000 transações, custando cerca de US$ 6.000 em taxas. A rede poderia processar esse volume de transações em uma hora. Apesar disso, é provável que a rede continue processando um número significativo de transações de usuários através de nós que o invasor não atingiu diretamente e que contêm transações de usuários em seu pool de memória. No entanto, algumas transações podem ser extraídas de outros nós, portanto podem ser transações de spam válidas.
Conclusão
Em essência, as taxas e a arquitetura da rede são as principais defesas contra transações de spam. Os bots de arbitragem são obrigados a enviar transações válidas, incluindo taxas. Este não é um ataque DDOS tradicional, onde o objetivo é inundar o nó com transações na camada de rede. Se os bots enviarem um grande volume de transações para a rede, os nós poderão começar a descartar as transações dos usuários no nível da rede. Isto representa um risco para todas as redes, pois são transações legítimas que incluem taxas pagas. Se um invasor puder lucrar mais com a arbitragem, as taxas poderão não fornecer proteção adequada contra transações de spam. O invasor não ficará sem fundos e poderá manter o ataque enquanto a arbitragem continuar lucrativa. Portanto, a próxima camada crucial de proteção é a arquitetura de rede.
Ao discutir a descentralização e a produção de blocos, pode-se argumentar que Solana é consideravelmente mais centralizada (e, portanto, mais suscetível a inundações de transações) do que Cardano, dado que o cronograma líder é predeterminado e todas as transações são roteadas para eles. Observe que o número de validadores não importa em nada. A equipe Solana enfrenta a difícil tarefa de lidar com isso, assim como a equipe Cardano, que precisa melhorar a escalabilidade. Nenhum desses desafios é trivial.
Você gostou deste artigo? Por favor, compartilhe, obrigado!
1 post - 1 participant