01 antecedentes
Qtum se ha centrado en la investigación de la infraestructura subyacente de la cadena de bloques e itera continuamente sobre la base de Bitcoin y EVM. La red principal de Qtum ha estado funcionando de forma estable durante casi dos años, y en el proceso también se han expuesto algunas fallas en el sistema y las reglas de consenso. Estas deficiencias han obstaculizado el desarrollo y la aplicación de la tecnología blockchain hasta cierto punto.
Para adaptarse a los escenarios de aplicación en constante cambio de la tecnología blockchain, Qtum actualizará gradualmente el protocolo subyacente y lanzará Qtum 2.0. El hard fork descrito en este artículo será la primera actualización relacionada con Qtum 2.0.
Acerca de QIP (propuesta de mejora de Qtum)
Las propuestas de mejora de Qtum (QIP) son una serie de sugerencias específicas sobre la actualización de la tecnología subyacente de Qtum propuesta por los desarrolladores de Qtum y la comunidad. Todas las propuestas se publican en github y todos pueden discutir las propuestas públicamente. La propuesta ampliamente reconocida será implementada por el equipo de desarrollo de Qtum.
Qtum QIP: https://github.com/qtumproject/qips/issues
02 Propósito y motivación
Este hard fork es la iteración de la versión más grande desde el lanzamiento de la red principal de Qtum. Es la base técnica de Qtum como la futura infraestructura de aplicaciones blockchain. Incluye cuatro actualizaciones de QIP relacionadas con el consenso. Son:
-
QIP-5: agregar verificación de firma al script de salida de transacciones de contrato
https://github.com/qtumproject/qips/issues/6
-
QIP-6: agregue el contrato precompilado btc_ecrecover a la máquina virtual EVM de Qtum
https://github.com/qtumproject/qips/issues/7
-
QIP-7: actualice la máquina virtual Qtum EVM a la última versión de Ethereum Constantinople (Constantinople)
https://github.com/qtumproject/qips/issues/8
-
QIP-9: modifica el algoritmo de ajuste de dificultad para que el tiempo de bloqueo sea más estable
https://github.com/qtumproject/qips/issues/9
Entre ellos, QIP-5 y QIP-7 han agregado varias características nuevas a Qtum para adaptarse a escenarios de aplicaciones de contratos inteligentes más complejos en la realidad, y también son la base técnica para actualizaciones posteriores (como activos de privacidad); QIP-6 mejora el desarrollo de contratos inteligentes. Conveniencia, al tiempo que reduce el costo de uso; QIP-9 mejora aún más la estabilidad de la red Qtum.
¿Por qué necesitamos una actualización "hard fork"?
Qtum es una red completamente descentralizada. Cada nodo ejecuta un programa de billetera / nodo independiente. Nadie puede controlar la versión del programa que ejecuta cada nodo, pero todos los nodos pueden usar una regla de consenso unificada para todas las transacciones en la red Qtum. De acuerdo. Si algunos nodos adoptan diferentes reglas de consenso de otros nodos, se "bifurcarán" en dos cadenas.
Las actualizaciones ordinarias no modifican ninguna regla de consenso, e incluso si algunos nodos no han completado la actualización, la red no se bifurcará. Sin embargo, todos los cambios involucrados en esta actualización están relacionados con las reglas de consenso, lo que significa que los nodos actualizados y los no actualizados adoptarán diferentes reglas de consenso, lo que resultará en un hard fork. Se recomienda encarecidamente que todos los usuarios completen la actualización lo antes posible para evitar pérdidas innecesarias por no cambiar a la nueva versión.
03 Descripción general de QIP relacionado con hard fork
QIP-5
descripción
Agregue la verificación de firma al script de salida de la transacción del contrato, de modo que se pueda demostrar la propiedad y se pueda llamar al contrato sin que la dirección posea ningún QTUM.
motivación
Invocar cualquier contrato inteligente en Qtum requiere el pago de las tarifas de gas correspondientes. Cada vez que se llama a un contrato, se requiere un saldo en la dirección del contrato de llamada (incluso si el saldo es muy pequeño). Por ejemplo, la transferencia del token QRC20 es una de las llamadas de contrato más comunes. Suponiendo que hay 1000 QC en la dirección A (una moneda estable QRC20 publicada en Qtum), para enviar este 1000 QC, debe requerir una cierta cantidad en la dirección A QTUM para demostrar al contrato que eres el propietario de la dirección. Si la dirección A no tiene saldo, no se puede llamar a ningún contrato, es decir, no se puede utilizar el 1000 QC. En la actualidad, la única solución es transferir algo de QTUM a la dirección A primero y luego llamar al contrato para enviar el token. Sin embargo, esto no solo desperdicia recursos valiosos del conjunto de datos UTXO en la cadena, sino que también afecta en gran medida la experiencia del usuario. Al mismo tiempo, para escenarios de aplicaciones de contratos inteligentes más complejos (como aplicaciones de mercado de predicción, intercambios descentralizados, etc.), esta restricción ha aumentado significativamente el umbral para que los usuarios utilicen aplicaciones de blockchain.
beneficio
Al agregar el código de operación OP_SENDER, QIP-5 proporciona un mecanismo para demostrar la propiedad de la dirección de llamada del contrato, de modo que pueda proporcionar pruebas sin ningún QTUM de la dirección y luego llamar al contrato inteligente. Aunque el sistema original no ha cambiado mucho, ha traído cambios importantes al ecosistema de contrato inteligente existente:
-
Las direcciones pueden llamar a contratos inteligentes (como enviar y recibir tokens QRC20) sin poseer tokens QTUM para mejorar la experiencia de recepción y envío de tokens de los usuarios comunes. Nota: No es gratis llamar al contrato, pero se puede pagar en otras direcciones.
-
Se generarán servicios más diversificados. El proveedor del servicio pagará la tarifa del servicio y el usuario solo necesita usar el servicio, que está más cerca del escenario de aplicación real.
-
Es posible permitir que múltiples direcciones llamen a múltiples contratos en una transacción, aumentando la flexibilidad de las llamadas de contrato
-
Ahorre espacio para conjuntos de datos UTXO en la cadena
Posible riesgo
QIP-5 agrega reglas de consenso adicionales, pero aún es compatible con las reglas originales, por lo que teóricamente no traerá riesgos de seguridad. Pero tendrá algún impacto en la infraestructura existente:
-
Es necesario desarrollar comandos RPC adicionales para utilizar esta función correctamente, los proveedores de servicios deben sincronizar la infraestructura para actualizar
-
Debido a la adición de scripts adicionales, los proveedores de servicios deben realizar una verificación adicional en los scripts; de lo contrario, dichas transacciones no serán reconocidas.
QIP-6
descripción
Agregue el contrato precompilado btc_ecrecover a la máquina virtual EVM de Qtum para la llamada directa mediante contratos ordinarios.
motivación
En Solidiy, la función ecrecover puede restaurar la firma de la curva elíptica a la dirección de clave pública correspondiente. El msg.sender en el contrato inteligente de Qtum usa una dirección P2PKH similar a Bitcoin, y el formato de dirección devuelto por la función ecrecover es el mismo que el de Ethereum, y los dos no se pueden comparar directamente. Para los desarrolladores, esto hará que algunos juicios lógicos en el contrato sean engorrosos. El método común actual para resolver este problema es llamar a contratos de biblioteca adicionales, pero consumirá más gas y aumentará el costo de usar contratos inteligentes.
beneficio
QIP-6 implementa una función denominada btc_ecrecover mediante contratos precompilados. Si bien la nueva función es compatible con todas las interfaces de la función original, puede traer los siguientes beneficios:
-
El tipo de dirección devuelto por btc_ecrecover es completamente consistente con el formato de dirección msg.sender, que se puede comparar directamente, lo que simplifica el juicio lógico en el proceso de desarrollo del contrato
-
Los contratos precompilados pueden ahorrar enormemente el consumo de gas y reducir el costo de usar contratos inteligentes
Posible riesgo
QIP-6 no realiza ningún cambio en el sistema original y la nueva función es totalmente compatible con la interfaz de la función original, por lo que, en teoría, no implicará ningún riesgo.
QIP-7
descripción
Actualice la máquina virtual Qtum EVM a la última versión de Ethereum Constantinople (Constantinople).
motivación
Actualmente, Qtum usa una versión anterior de la máquina virtual EVM. Después de que se lanzó la red principal de Qtum, EVM se actualizó a Byzantine y Constantinople. Se han agregado muchas características nuevas para desarrolladores a la nueva versión de la máquina virtual, como la devolución de datos de longitud variable y las llamadas de contratos estáticos. Cada vez más desarrolladores necesitan confiar en estas nuevas funciones para el desarrollo de aplicaciones y contratos.
beneficio
QIP-7 incluye todas las características nuevas de las versiones EVM Byzantine y Constantinople, lo que permite contratos y aplicaciones inteligentes más complejos. Por ejemplo, para los activos de privacidad que Qtum planea admitir en QIP-19, los contratos inteligentes relacionados deben depender de las nuevas funciones proporcionadas en la nueva versión de EVM. Además, una vez completada la actualización, teóricamente todos los contratos y aplicaciones inteligentes en Ethereum se pueden trasplantar a Qtum y, al mismo tiempo, se puede obtener la seguridad y estabilidad únicas del modelo UTXO subyacente.
Posible riesgo
Ambas versiones EVM Byzantine y Constantinople se han activado en la red principal de Ethereum, se ha verificado su estabilidad y son totalmente compatibles con versiones posteriores con bajo riesgo. Sin embargo, la capa inferior de Qtum usa el modelo UTXO, que es inconsistente con el modelo de cuenta EVM. Los desarrolladores deben prestar atención a las características de la versión Qtum de EVM al migrar contratos existentes.
QIP-9
descripción
QIP-9 en realidad incluye dos actualizaciones:
1. Modifique el algoritmo de ajuste de dificultad de minería (participación) de la red principal de Qtum para que el tiempo de generación del bloque sea más estable y más cercano al tiempo esperado; (relacionado con el consenso)
2. Modifique el algoritmo de estimación de peso de toda la red para acercarlo al valor real. (No relacionado con el consenso)
motivación
El intervalo de bloque diseñado por Qtum es de 128 segundos. En teoría, cuando el intervalo de bloque fluctúa, el mecanismo de consenso extenderá o acortará el intervalo de bloque ajustando el valor de dificultad, de modo que el tiempo promedio de generación de bloque permanece en 128 segundos. Sin embargo, el algoritmo de ajuste de dificultad utilizado actualmente por Qtum varía enormemente. El resultado directo es que el tiempo medio de generación de bloques de la red principal es de unos 144 segundos, lo que significa que el TPS se reduce potencialmente en un 12%.
Por otro lado, el peso de la red Qtum (que puede entenderse como la suma de las monedas que se están apostando) refleja la seguridad de toda la red y también determina los beneficios esperados de la apuesta (minería). Dado que Qtum es una red completamente descentralizada, el peso de toda la red solo puede estimarse por la dificultad de la minería. Sin embargo, el algoritmo de estimación de peso existente fluctúa mucho y, según los resultados de la simulación, su variación con respecto al peso real es grande, por lo que no puede reflejar con precisión el estado actual de la red.
beneficio
-
QIP-9 proporciona un algoritmo de ajuste de dificultad mejorado, que ajusta la dificultad de acuerdo con el promedio móvil exponencial del intervalo de bloque, lo que puede hacer que el tiempo promedio de generación de bloque se acerque a 128 segundos. El tiempo medio de confirmación de las transacciones también se reducirá en consecuencia.
-
QIP-9 mejora el algoritmo de estimación del peso de la red y utiliza la media móvil para estimar. En comparación con el algoritmo original, la varianza entre el nuevo algoritmo y el peso real es menor y la fluctuación es menor, lo que puede reflejar con mayor precisión el estado actual de replanteo de la red
Posible riesgo
-
El algoritmo de ajuste de dificultad involucrado en QIP-9 no tiene riesgos de seguridad.
-
Aunque el algoritmo de estimación del peso de la red suaviza el valor estimado, no puede reflejar los cambios en el estado de la red en el tiempo cuando el peso real fluctúa bruscamente, por lo que todavía hay margen de mejora en el futuro. Pero esta actualización no implica un mecanismo de consenso, por lo que se puede modificar nuevamente en actualizaciones periódicas posteriores.
04 plan de liberación de horquilla dura
Todos los códigos relacionados con este hard fork se han desarrollado y probado durante casi medio año. La actualización de la bifurcación dura se activará primero en la red de prueba y, una vez que la red de prueba funcione de manera estable, se activará en la red principal de Qtum.
La actualización de la altura se activa automáticamente en el bloque preestablecido, la altura de la bifurcación de la red de prueba es 446,320 (se estima que será el 20 de septiembre de 2019 ), la altura de la bifurcación de la red principal de Qtum es 466,600 (tiempo estimado para octubre de 2019 16 Día 17 de octubre ). Se recomienda que los usuarios sigan ejecutando billeteras que son siempre la última versión lanzada oficialmente para que la actualización se pueda completar automáticamente.
Posible impacto
-
Cuando se activa la actualización, si todavía hay una gran cantidad de nodos que no han completado la actualización, se pueden dividir en dos cadenas durante un tiempo breve cuando se activa la actualización, hasta que la mayoría de los nodos se actualicen. En este momento, existe la posibilidad de ataques de doble gasto; al mismo tiempo, si el nodo minero Si la actualización no está completa, el peso de toda la red puede ser inestable, lo que da como resultado grandes fluctuaciones en el tiempo de generación del bloque, y el tiempo de confirmación de todas las transacciones puede ser más largo (como depósitos y retiros de divisas).
-
Una vez activada la actualización, si se encuentra una vulnerabilidad importante relacionada con el consenso, es posible que el equipo de desarrollo deba corregirla rápidamente y recordar a los usuarios que actualicen; de lo contrario, la bifurcación puede volver a ocurrir.
Contramedida
Para el problema de que los nodos no se actualizan por completo, Qtum notificará a todos los intercambios, proveedores de servicios (billeteras, navegadores), Staker (mineros) y usuarios comunes para completar la actualización con anticipación para asegurarse de que la mayoría de los nodos se actualicen antes de que se active la red principal, y la actualización está garantizada. Ve suavemente
Con respecto a las vulnerabilidades de la actualización en sí, el equipo de desarrollo de Qtum ha realizado pruebas internas durante medio año antes del lanzamiento, y todas las pruebas han pasado. Al mismo tiempo, esta actualización se activará en la red de prueba con tres meses de anticipación para garantizar que todas las vulnerabilidades se encuentren y solucionen antes de que se active y actualice la red principal.
Todos los usuarios deben mantener el nodo actualizado a la última versión y, durante el período de activación de la bifurcación, confirmen todas las transacciones varias veces o esperen a que la red se estabilice antes de realizar la transferencia.
¿Habrá un hard fork en el futuro?
Siempre que las actualizaciones relacionadas con el consenso requieran una bifurcación, se adoptará un proceso similar a este para notificar a los usuarios que deben actualizar. Posteriormente, Qtum planea lanzar máquinas virtuales x86, activos privados y funciones de minería de contrato inteligente, que pueden requerir bifurcaciones duras. El equipo de desarrollo de Qtum fusionará las actualizaciones que requieren bifurcaciones para minimizar la cantidad de actualizaciones de bifurcaciones.
¿Qué deben hacer los usuarios?
Desde una perspectiva de seguridad, todos los usuarios que ejecutan nodos / billeteras de Qtum deben actualizar a la última versión de la billetera antes de que se active la red principal.
Preste atención a la información de publicación de la última versión de la billetera:
-
https://github.com/qtumproject/qtum/releases/
-
https://qtumeco.io/wallet
Y actualice tan pronto como se lance la nueva versión.
Para los diferentes participantes en la red, se recomienda hacer los preparativos completos para la actualización:
Exchange, billetera
-
Antes y después de que se active la bifurcación, debe prestar atención a los registros de depósito y retiro de tokens QTUM y QRC20, y confirmar el depósito y retiro después de que la transacción haya sido confirmada lo suficiente por la cadena principal;
-
Para el retiro de tokens QRC20, los procedimientos de soporte (relacionados con QIP-5) se pueden actualizar con anticipación, de modo que las nuevas funciones se puedan usar para pagar las tarifas del gas lo antes posible.
Proveedor de servicios (por ejemplo, navegador)
-
Se recomienda desarrollar programas de soporte relacionados con QIP-5 con anticipación para evitar no reconocer la salida de la transacción con OP_SENDER cuando se activa la actualización.
Minero (grupo de minería, staker personal)
-
Antes y después de que se active la actualización, siempre debe prestar atención al peso de la red y ajustar los ingresos del usuario y la tarifa de gestión de acuerdo con los ingresos esperados.
Desarrolladores
-
Primero puede usar la red de prueba para desarrollar contratos y aplicaciones con nuevas características, que se pueden implementar cuando se activa la red principal. (QIP-7)
-
Considere más escenarios de aplicación junto con QIP-5.
usuario general
-
Siempre haga una copia de seguridad de su billetera.
05 Enlace de referencia
-
Para la implementación específica de QIP-5, consulte:
https://github.com/qtumproject/qips/issues/6
-
Para la implementación específica de QIP-6, consulte:
https://github.com/qtumproject/qips/issues/7
-
Para la implementación específica de QIP-7, consulte:
https://github.com/qtumproject/qips/issues/8
-
Para la implementación específica de 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