01 fundo
Qtum tem se concentrado na pesquisa da infraestrutura subjacente do blockchain e itera continuamente com base em Bitcoin e EVM. O mainnet Qtum tem operado de forma estável por quase dois anos, e algumas falhas no sistema e regras de consenso também foram expostas no processo. Essas deficiências têm dificultado o desenvolvimento e a aplicação da tecnologia blockchain até certo ponto.
Para se adaptar aos cenários de aplicação em constante mudança da tecnologia blockchain, Qtum irá atualizar gradualmente o protocolo subjacente e lançar Qtum 2.0. O hard fork descrito neste artigo será a primeira atualização relacionada ao Qtum 2.0.
Sobre QIP (Proposta de Melhoria Qtum)
Qtum Improvement Proposals (QIP) é uma série de sugestões específicas sobre a atualização da tecnologia subjacente do Qtum proposta pelos desenvolvedores do Qtum e pela comunidade. Todas as propostas são publicadas no github e todos podem discutir as propostas publicamente. A proposta amplamente reconhecida será implementada pela equipe de desenvolvimento do Qtum.
Qtum QIP: https://github.com/qtumproject/qips/issues
02 Objetivo e motivação
Este hard fork é a maior iteração de versão desde o lançamento do mainnet do Qtum. É a base técnica do Qtum como a futura infraestrutura de aplicativo blockchain. Inclui quatro atualizações de QIP relacionadas ao consenso. Eles são:
-
QIP-5: Adicionar verificação de assinatura ao script de saída de transações de contrato
https://github.com/qtumproject/qips/issues/6
-
QIP-6: Adicionar contrato pré-compilado btc_ecrecover à máquina virtual EVM da Qtum
https://github.com/qtumproject/qips/issues/7
-
QIP-7: Atualize a máquina virtual Qtum EVM para a versão mais recente de Ethereum Constantinople (Constantinopla)
https://github.com/qtumproject/qips/issues/8
-
QIP-9: Modifique o algoritmo de ajuste de dificuldade para tornar o tempo de bloqueio mais estável
https://github.com/qtumproject/qips/issues/9
Entre eles, QIP-5 e QIP-7 adicionaram vários novos recursos ao Qtum para se adaptar a cenários de aplicação de contrato inteligente mais complexos na realidade, e também são a base técnica para atualizações subsequentes (como ativos de privacidade); QIP-6 melhora o desenvolvimento de contrato inteligente Conveniência, enquanto reduz o custo de uso, o QIP-9 melhora ainda mais a estabilidade da rede Qtum.
Por que precisamos de uma atualização "hard fork"?
Qtum é uma rede completamente descentralizada. Cada nó executa um programa de nó / carteira independente. Ninguém pode controlar a versão do programa que cada nó executa, mas todos os nós podem usar uma regra de consenso unificada para todas as transações na rede Qtum. Aceita. Se alguns nós adotarem regras de consenso diferentes de outros nós, eles se "bifurcarão" em duas cadeias.
As atualizações comuns não modificam nenhuma regra de consenso e, mesmo que alguns nós não tenham concluído a atualização, a rede não bifurcará. No entanto, todas as mudanças envolvidas nesta atualização estão relacionadas às regras de consenso, o que significa que os nós atualizados e os nós não atualizados adotarão regras de consenso diferentes, resultando em um hard fork. É altamente recomendável que todos os usuários concluam a atualização o mais rápido possível para evitar perdas desnecessárias devido à não mudança para a nova versão.
03 Visão geral do QIP relacionado ao garfo rígido
QIP-5
descrição
Adicione a verificação de assinatura ao script de saída da transação do contrato, para que a propriedade possa ser comprovada e o contrato possa ser chamado sem o endereço que possui qualquer QTUM.
motivação
Invocar qualquer contrato inteligente no Qtum requer o pagamento das taxas de gás correspondentes. Cada vez que um contrato é chamado, um saldo é exigido no endereço do contrato de chamada (mesmo se o saldo for muito pequeno). Por exemplo, a transferência do token QRC20 é uma das chamadas de contrato mais comuns. Supondo que haja 1000 QC no endereço A (uma moeda estável QRC20 publicada no Qtum), para enviar este QC 1000, você deve exigir uma certa quantia no endereço A QTUM para provar ao contrato que você possui o endereço. Se o endereço A não tiver saldo, nenhum contrato pode ser chamado, ou seja, o QC 1000 não pode ser utilizado. No momento, a única solução é transferir algum QTUM para o endereço A primeiro e, em seguida, chamar o contrato para enviar o token. No entanto, isso não apenas desperdiça recursos valiosos do conjunto de dados UTXO na cadeia, mas também afeta muito a experiência do usuário. Ao mesmo tempo, para cenários de aplicativos de contratos inteligentes mais complexos (como aplicativos de previsão de mercado, trocas descentralizadas, etc.), essa restrição aumentou significativamente o limite para os usuários usarem aplicativos de blockchain.
beneficiar
Ao adicionar o opcode OP_SENDER, o QIP-5 fornece um mecanismo para provar a propriedade do endereço de chamada do contrato, para que ele possa fornecer a prova sem qualquer QTUM do endereço e, em seguida, chamar o contrato inteligente. Embora o sistema original não tenha mudado muito, ele trouxe mudanças importantes para o ecossistema de contrato inteligente existente:
-
Os endereços podem chamar contratos inteligentes (como enviar e receber tokens QRC20) sem possuir tokens QTUM para melhorar a experiência de recebimento e envio de tokens de usuários comuns. Nota: Não é gratuito ligar para o contrato, mas pode ser pago por outros endereços
-
Serão gerados serviços mais diversificados, o provedor de serviço pagará a taxa de serviço e o usuário só precisará utilizar o serviço, que está mais próximo do cenário real de aplicação
-
É possível permitir que vários endereços chamem vários contratos em uma transação, aumentando a flexibilidade das chamadas de contrato
-
Economize espaço para conjuntos de dados UTXO na cadeia
Possível risco
O QIP-5 adiciona regras de consenso adicionais, mas ainda é compatível com as regras originais, portanto, teoricamente, não trará riscos de segurança. Mas terá algum impacto na infraestrutura existente:
-
Necessidade de desenvolver comandos RPC adicionais para usar esta função corretamente, os provedores de serviços precisam sincronizar a infraestrutura para atualizar
-
Devido à adição de scripts adicionais, os provedores de serviços precisam realizar verificações adicionais nos scripts, caso contrário, tais transações não serão reconhecidas
QIP-6
descrição
Adicione o contrato pré-compilado btc_ecrecover à máquina virtual EVM do Qtum para chamada direta por contratos comuns.
motivação
No Solidiy, a função ecrecover pode restaurar a assinatura da curva elíptica para o endereço de chave pública correspondente. O msg.sender no contrato inteligente do Qtum usa um endereço P2PKH semelhante ao Bitcoin, e o formato do endereço retornado pela função ecrecover é o mesmo que o do Ethereum, e os dois não podem ser comparados diretamente. Para os desenvolvedores, isso tornará alguns julgamentos lógicos no contrato complicados. O método comum atual para resolver esse problema é convocar contratos adicionais de biblioteca, mas consumirá mais gás e aumentará o custo de uso de contratos inteligentes.
beneficiar
QIP-6 implementa uma função chamada btc_ecrecover por meio de contratos pré-compilados. Embora a nova função seja compatível com todas as interfaces da função original, ela pode trazer os seguintes benefícios:
-
O tipo de endereço retornado por btc_ecrecover é completamente consistente com o formato de endereço msg.sender, que pode ser comparado diretamente, o que simplifica o julgamento lógico no processo de desenvolvimento do contrato
-
Contratos pré-compilados podem economizar muito no consumo de gás e reduzir o custo do uso de contratos inteligentes
Possível risco
O QIP-6 não faz nenhuma alteração no sistema original e a nova função é totalmente compatível com a interface da função original, portanto, teoricamente, não trará nenhum risco.
QIP-7
descrição
Atualize a máquina virtual Qtum EVM para a versão mais recente do Ethereum Constantinople (Constantinopla).
motivação
Atualmente o Qtum usa uma versão anterior da máquina virtual EVM. Depois que o mainnet Qtum foi lançado, EVM foi atualizado para Bizantino e Constantinopla. Muitos novos recursos amigáveis ao desenvolvedor foram adicionados à nova versão da máquina virtual, como o retorno de dados de comprimento variável e chamadas de contratos estáticos. Mais e mais desenvolvedores precisam contar com esses novos recursos para contrato e desenvolvimento de aplicativos.
beneficiar
O QIP-7 inclui todos os novos recursos das versões EVM Bizantino e Constantinopla, permitindo contratos e aplicativos inteligentes mais complexos. Por exemplo, para os ativos de privacidade que a Qtum planeja oferecer suporte no QIP-19, os contratos inteligentes relacionados precisam contar com os novos recursos fornecidos na nova versão do EVM. Além disso, depois que a atualização for concluída, teoricamente todos os contratos e aplicativos inteligentes no Ethereum podem ser transplantados para o Qtum e, ao mesmo tempo, a segurança e estabilidade exclusivas do modelo UTXO subjacente podem ser obtidas.
Possível risco
Ambas as versões EVM Bizantina e Constantinopla foram ativadas na rede principal Ethereum, sua estabilidade foi verificada e elas são totalmente compatíveis com o futuro. No entanto, a camada inferior do Qtum usa o modelo UTXO, que é inconsistente com o modelo de conta EVM. Os desenvolvedores precisam prestar atenção às características da versão Qtum do EVM ao migrar os contratos existentes.
QIP-9
descrição
O QIP-9 realmente inclui duas atualizações:
1. Modificar o algoritmo de ajuste de dificuldade de mineração (estacagem) da mainnet Qtum para tornar o tempo de geração de blocos mais estável e mais próximo do tempo esperado; (relacionado ao consenso)
2. Modifique o algoritmo de estimativa de peso de toda a rede para torná-lo mais próximo do valor real. (Não relacionado ao consenso)
motivação
O intervalo de bloco projetado por Qtum é de 128 segundos. Em teoria, quando o intervalo de bloco flutua, o mecanismo de consenso irá estender ou encurtar o intervalo de bloco ajustando o valor de dificuldade, de modo que o tempo médio de geração de bloco permaneça em 128 segundos. No entanto, o algoritmo de ajuste de dificuldade atualmente usado pelo Qtum flutua muito. O resultado direto é que o tempo médio de geração de blocos da rede principal é de cerca de 144 segundos, o que significa que o TPS é potencialmente reduzido em cerca de 12%.
Por outro lado, o peso da rede Qtum (que pode ser entendido como a soma das moedas em piquetagem) reflete a segurança de toda a rede e também determina os benefícios esperados do piqueteamento (mineração). Como Qtum é uma rede completamente descentralizada, o peso de toda a rede só pode ser estimado pela dificuldade de mineração. No entanto, o algoritmo de estimativa de peso existente flutua muito e, de acordo com os resultados da simulação, sua variação em relação ao peso real é grande, portanto, ele não pode refletir com precisão o estado atual da rede.
beneficiar
-
O QIP-9 fornece um algoritmo de ajuste de dificuldade aprimorado, que ajusta a dificuldade de acordo com a média móvel exponencial do intervalo de bloco, o que pode tornar o tempo médio de geração de bloco mais próximo de 128 segundos. O tempo médio de confirmação das transações também será reduzido em conformidade
-
QIP-9 melhora o algoritmo de estimativa do peso da rede e usa a média móvel para estimar. Em comparação com o algoritmo original, a variação entre o novo algoritmo e o peso real é menor e a flutuação é menor, o que pode refletir com mais precisão o status de piquetagem da rede atual
Possível risco
-
O algoritmo de ajuste de dificuldade envolvido no QIP-9 não apresenta riscos de segurança.
-
Embora o algoritmo de estimativa de peso da rede suavize o valor estimado, ele não pode refletir as mudanças no estado da rede a tempo quando o peso real flutua acentuadamente, portanto, ainda há espaço para melhorias no futuro. Mas esta atualização não envolve um mecanismo de consenso, portanto, pode ser modificada novamente em atualizações regulares subsequentes
04 plano de liberação de garfo rígido
Todos os códigos relacionados a este garfo rígido foram desenvolvidos e testados por quase meio ano. A atualização do hard fork primeiro será ativada na rede de teste e, depois que a rede de teste estiver funcionando de maneira estável, ela será ativada na rede principal do Qtum.
A atualização da altura é ativada automaticamente no bloco predefinido, a altura da bifurcação da rede de teste é 446.320 (estimada em 20 de setembro de 2019 ), a altura da bifurcação da rede principal Qtum é 466.600 (tempo estimado para outubro de 2019 16 Dia 17 de outubro ). Recomenda-se que os usuários mantenham as carteiras que são sempre a última versão oficialmente lançada para que a atualização possa ser concluída automaticamente.
Possível impacto
-
Quando a atualização é ativada, se ainda houver um grande número de nós que não concluíram a atualização, eles podem se dividir em duas cadeias por um curto período quando a atualização for ativada, até que a maioria dos nós seja atualizada. Neste momento, há a possibilidade de ataques de gasto duplo. Se a atualização não for concluída, o peso de toda a rede pode ser instável, resultando em grandes flutuações no tempo de geração do bloco, e o tempo de confirmação de todas as transações pode se tornar mais longo (como depósitos de câmbio e retiradas)
-
Após a atualização ser ativada, se uma grande vulnerabilidade relacionada ao consenso for encontrada, a equipe de desenvolvimento pode precisar corrigi-la rapidamente e lembrar os usuários de atualizar, caso contrário, a bifurcação pode ocorrer novamente
Contramedida
Para o problema de os nós não estarem totalmente atualizados, Qtum notificará todas as trocas, provedores de serviços (carteiras, navegadores), Staker (mineradores) e usuários comuns para concluir a atualização com antecedência para garantir que a maioria dos nós sejam atualizados antes que a rede principal seja ativada, e a atualização é garantida Vá com calma
Em relação às vulnerabilidades da atualização em si, a equipe de desenvolvimento do Qtum conduziu testes internos por meio ano antes do lançamento, e todos os testes foram aprovados. Ao mesmo tempo, esta atualização será ativada na rede de teste com três meses de antecedência para garantir que todas as vulnerabilidades sejam encontradas e corrigidas antes que a rede principal seja ativada e atualizada.
Todos os usuários devem manter o nó atualizado com a versão mais recente e, durante o período de ativação hard fork, confirmar todas as transações várias vezes ou esperar que a rede se estabilize antes de transferir.
Haverá uma bifurcação difícil no futuro?
Enquanto as atualizações relacionadas ao consenso podem exigir um hard fork, um processo semelhante a este será adotado para notificar os usuários sobre a atualização. A Qtum subsequente planeja lançar máquinas virtuais x86, ativos privados e recursos de mineração de contrato inteligente, que podem exigir garfos rígidos. A equipe de desenvolvimento do Qtum irá mesclar atualizações que requerem forks para minimizar o número de atualizações hard fork.
O que os usuários precisam fazer?
De uma perspectiva de segurança, todos os usuários que estão executando nós / carteiras Qtum precisam atualizar para a versão mais recente da carteira antes que a rede principal seja ativada.
Preste atenção às informações de lançamento da versão mais recente da carteira:
-
https://github.com/qtumproject/qtum/releases/
-
https://qtumeco.io/wallet
E atualize assim que a nova versão for lançada.
Para diferentes participantes da rede, é recomendado fazer todos os preparativos para a atualização:
Bolsa, carteira
-
Antes e depois do hard fork ser ativado, você precisa prestar atenção aos registros de depósito e retirada de tokens QTUM e QRC20 e confirmar o depósito e retirada após a transação ter sido confirmada pela cadeia principal o suficiente;
-
Para a retirada de tokens QRC20, os procedimentos de suporte (relacionados ao QIP-5) podem ser atualizados com antecedência, de modo que os novos recursos possam ser usados para pagar as taxas de gás o mais rápido possível.
Provedor de serviços (por exemplo, navegador)
-
Recomenda-se desenvolver programas de suporte relacionados ao QIP-5 com antecedência para evitar a falha em reconhecer a saída da transação com OP_SENDER quando a atualização for ativada.
Mineiro (piscina de mineração, staker pessoal)
-
Antes e depois da ativação do upgrade, é necessário sempre prestar atenção ao peso da rede e ajustar a receita do usuário e a taxa de manuseio de acordo com a receita esperada.
Desenvolvedores
-
Você pode primeiro usar a rede de teste para desenvolver contratos e aplicativos com novos recursos, que podem ser implantados quando a rede principal é ativada. (QIP-7)
-
Considere mais cenários de aplicação em conjunto com QIP-5.
usuário geral
-
Sempre faça backup de sua carteira.
05 Link de referência
-
Para a implementação específica de QIP-5, consulte:
https://github.com/qtumproject/qips/issues/6
-
Para a implementação específica de QIP-6, consulte:
https://github.com/qtumproject/qips/issues/7
-
Para a implementação específica do QIP-7, consulte:
https://github.com/qtumproject/qips/issues/8
-
Para a implementação específica do QIP-9, consulte:
https://github.com/qtumproject/qips/issues/9
-
Bizantino ： https: //blog.ethereum.org/2017/10/12/byzantium-hf-announcement/
-
Constantinopla ： https: //blog.ethereum.org/2019/02/22/ethereum-constantinople-st-petersburg-upgrade-announcement/
-
QIP-19 ： https: //github.com/qtumproject/qips/issues/19