Time warps, vulnerabilidades de mineração, ataques DOS e muito mais.
Mining in Verge: quando 5 algoritmos são exagerados
Tradicionalmente, em criptomoedas baseadas no protocolo de prova de trabalho, os blocos são extraídos usando um único algoritmo, geralmente SHA-256. No Verge, era possível usar 5 algoritmos diferentes (para os curiosos - Scrypt, X17, Lyra2rev2, myr-groestl e blake2s.). O motivo do uso de vários algoritmos é descrito abaixo.
Alguns críticos do Bitcoin argumentam que ao longo do tempo Mineração de bitcoin tornou-se muito especializado e centralizado, a maior parte da mineração é feita em ASICs (abreviação de circuito integrado específico do aplicativo) - dispositivos projetados exclusivamente para mineração de moeda, e a maior parte da mineração de Bitcoin é feita em vários pools de mineração por grupos de mineradores que agrupam seus recursos e compartilham o que ganham entre si. Essas tendências para diferentes tipos de "centralização", dizem eles, contradizem o princípio fundamental das criptomoedas. Usar uma moeda com vários algoritmos de mineração contrabalança essas tendências. O raciocínio é que gerenciar cinco algoritmos diferentes em termos de hardware, produção e gerenciamento de recursos será inevitavelmente mais difícil do que controlar um algoritmo, permitindo que a Verge alcance uma maior descentralização e distribuição da mineração.
A situação é a seguinte: a única maneira de conseguir uma operação correta - e o conceito de "operação correta" neste caso inclui manter um intervalo de 30 segundos entre os blocos, mantendo a viabilidade econômica de todos os cinco algoritmos para mineradores e evitando o domínio de um algoritmo (o que tornaria todo o experimento sem sentido) - fazer com que cada algoritmo tenha seu próprio parâmetro de dificuldade, que seria ajustado independentemente dos outros quatro. Em outras palavras, a dificuldade de mineração no algoritmo Scrypt é ajustada para observar um intervalo de 30 segundos para cada bloco, como no X17 e outros algoritmos.
Isso significa que nosso hacker não reduziu realmente a dificuldade de mineração de toda a rede; ele rebaixou apenas para aqueles que mineraram com um dos cinco algoritmos - Scrypt. E enquanto os mineiros Scrypt desfrutavam de mineração ridiculamente fácil, para o resto dos mineiros trabalhando em outros algoritmos, a complexidade das tarefas não diminuiu, o que significa que todo o seu poder combinado não ajudará a garantir a segurança da rede. Isso significava que o invasor trabalhava apenas com o algoritmo Scrypt e tinha que competir com outros usuários que faziam o mesmo; portanto, o poder de hash necessário para o nosso invasor não era superior a 50% (domínio sobre toda a rede), mas apenas superior a 10% (domínio sobre outros mineradores Scrypt).
Iremos agora para o reino da especulação, mas parece que a situação era ainda pior. Assumimos um valor de 10%, com base no fato de que aproximadamente a mesma quantidade de recursos deve ser alocada para cada algoritmo (esta é a essência do mecanismo para definir a dificuldade de mineração). Na realidade, porém, os axiomas de uma economia de mercado livre nem sempre são observados. Acredita-se na comunidade que vários fatores - por exemplo, a existência de ASICs não ativados para Scrypt, bem como recursos gratuitos disponíveis para aluguel através de Nicehash, etc. - levaram ao fato de que o domínio da mineração em Scrypt durante o ataque foi muito mais barato do que qualquer outro dos quatro algoritmos. É seguro presumir que a taxa de hash necessária acabou sendo muito menor que 10% - de acordo com algumas estimativas preliminares fornecidas no Reddit, a taxa de hash poderia ser tão baixa quanto 0,4%.
Para resumir: carimbos de data / hora falsos reduziram drasticamente a complexidade da mineração; a utilização de cinco algoritmos permitiu reduzir a complexidade de apenas um deles, o que simplificou muito a captura de toda a rede; a situação econômica e de produção desse algoritmo de mineração em particular tornou a captura ainda mais fácil; e, finalmente, devido à reduzida complexidade da mineração, o tempo para formação do bloco foi drasticamente reduzido, o que tornou o ataque cerca de 30 vezes mais lucrativo.
Lições aprendidas
Que conclusão podemos tirar dessa situação? As consequências de curto prazo do hack foram previsivelmente caóticas e incompreensíveis. Poucos dias depois, os principais desenvolvedores corrigiram vários bugs com a ajuda de utilitários, nos quais também podem ocorrer erros e, eventualmente, um hard fork foi realizado na rede, o que poderia ter acontecido inicialmente por acidente (ou não por acidente) . Em termos de reação global, na semana após o hack, o preço do Verge aumentou 30%, e na semana seguinte foi anunciado que a moeda Verge seria aceita como taxa de assinatura no pornhub.com. Como o maior hack de criptomoeda em nível de protocolo pode ter levado ao crescimento dessa moeda em valor e, posteriormente, à conclusão de uma parceria com o site pornográfico mais visitado - vou deixar essa questão em aberto. Pessoalmente, acho que não há sentido no mundo e as pessoas são completamente malucas.
Mas estou divagando. Mais globalmente, existem várias lições que podemos aprender com esta situação:
Primeiro, a técnica de usar carimbos de data / hora para reduzir artificialmente a complexidade já é conhecida há muito tempo e até conseguiu o nome - a vulnerabilidade de "distorção do tempo". Vários anos atrás, um vetor de ataque foi discutido no fórum Bitcoin. Até certo ponto, o uso do algoritmo de ajuste de dificuldade mais recente Dark Gravity Well, no qual a dificuldade é ajustada a cada novo bloco, ajudou a implementar o ataque à Verge. No Bitcoin, a dificuldade só muda a cada 2016 blocos. Apesar do fato de que essa configuração de dificuldade intermitente e prolongada pelo tempo pode parecer uma decisão estranha, o hack do Verge deixou claro que é na verdade uma medida de segurança: se existe alguma maneira no Bitcoin de reduzir a complexidade da mineração, então um o invasor pode fazer isso apenas uma vez a cada 2 semanas, o que torna os resultados do ataque insignificantes em comparação com o Verge, onde os hackers podem diminuir a dificuldade de mineração a cada 30 segundos.
Curiosamente, uma das supostas vantagens do Dark Gravity Wave é que ele deve ser imune a uma vulnerabilidade de dobra do tempo. Dado o quão fortemente esta suposição foi refutada, outras moedas que usam este algoritmo deveriam pelo menos ficar nervosas.
Quanto ao uso dos cinco algoritmos: embora à primeira vista pareça um experimento valioso em um ambiente descentralizado economicamente estimulante, ele introduz novas complexidades que inevitavelmente aumentam a probabilidade de ocorrência de vulnerabilidades imprevistas.
Em ambos os casos, esse hack constitui um forte argumento a favor de mecanismos comprovados e pede cautela ao complicar e introduzir riscos desnecessários associados aos ativos financeiros das pessoas. Nesses assuntos, a equipe Bitcoin mostrou-se no seu melhor.
A questão é um pouco mais ampla: os desenvolvedores de software, embora relutem em admitir, são apenas humanos. Mesmo quando os princípios básicos de segurança parecem perfeitamente sólidos, sempre pode haver espaço para erros. Existem ataques inesperados, compromissos nem sempre compensam e, claro, ninguém cancelou a possibilidade de bons e velhos bugs. O software nem sempre funciona da maneira que queremos, e ninguém em 2018 ficará surpreso que bugs como esse possam levar à perda de fundos. Mas quando o software o mesmo é dinheiro, precisamos ter um cuidado especial.
Visto que a maioria de nós não tem tempo para analisar completamente o código de cada projeto em que investimos, a melhor defesa contra desastres é confiar em sistemas comprovados com experiência de trabalho positiva e uma abordagem conservadora para o desenvolvimento.
E se você quiser apostar em alguns fundos em projetos piloto relacionados a transferências de dinheiro, pelo menos deve estar ciente dos riscos. Em última análise, a melhor defesa é quando a comunidade exige que as medidas adequadas sejam tomadas para prevenir desastres futuros. Se não me engano, George Santayana disse: "Aqueles que não conseguem aprender com as vulnerabilidades de segurança do passado estão condenados a repeti-las continuamente no futuro." Essas palavras devem ser lembradas para que, inesperadamente para nós mesmos, não repitamos os erros do passado.