El camino a Qtum 2.0 — El primer Fork

Qtum Español
12 min readOct 10, 2019

--

Qtum

Oct 2 · 11 min read

Antecedentes

Qtum se ha centrado en desarrollar la infraestructura subyacente de nuestra blockchain, mientras continuamos manteniéndonos actualizados con las últimas iteraciones técnicas basadas en Bitcoin y la máquina virtual Ethereum (EVM). Desde Septiembre de 2017, Qtum Mainnet ha estado funcionando de manera estable. En el proceso, se descubrió y reparó una imperfección sutil en nuestro algoritmo de consenso de prueba de participación junto con algunas adiciones de código de operación de contrato inteligente que se han propuesto y agregado para mejorar la funcionalidad del contrato inteligente.

Para adaptarse a los escenarios de aplicaciones 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 (propuestas de mejora de Qtum)

Las propuestas de mejora de Qtum (QIP) son una serie de recomendaciones específicas de desarrolladores de Qtum y miembros de la comunidad sobre la actualización de la tecnología Qtum subyacente. Todas las propuestas se publican en GitHub (https://github.com/qtumproject/qips/issues), y todos pueden discutir la propuesta públicamente. El equipo de desarrollo de Qtum implementará propuestas ampliamente aceptadas.

Propósito y Motivación

Esta será el primer hard fork desde el lanzamiento de Qtum Mainnet. Incluye cuatro actualizaciones QIP relacionadas con el consenso:

  • QIP-5: Agregue verificación de firma al script de salida de la transacción del contrato;
  • QIP-6: Agregue el contrato precompilado btc_ecrecover al Qtum EVM;
  • QIP-7: Actualice el Qtum EVM al último Ethereum EVM Constantinople;
  • QIP-9: Modifique el algoritmo de ajuste de dificultad para que el tiempo de bloqueo sea más estable.

Entre ellos, QIP-5 y QIP-7 agregan varias características nuevas a Qtum para adaptarse a los complejos escenarios de aplicación de los contratos inteligentes, y también son la base técnica para actualizaciones posteriores (como activos privados); QIP-6 facilita el desarrollo de contratos inteligentes al tiempo que reduce el costo de uso; y 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 decentralizada, donde cada nodo ejecuta un programa de billetera y nodo separado. Solo los usuarios individuales pueden controlar la versión del programa que se ejecuta en su nodo, mientras que todos los nodos pueden llegar a un acuerdo sobre todas las transacciones y bloques en la red Qtum a través de reglas de consenso uniformes. Si algunos nodos adoptan reglas de consenso diferentes de otros nodos, se dividirán en dos cadenas.

Las actualizaciones comunes no modifican las reglas de consenso. Incluso si algunos nodos no completan la actualización, la red no va a bifurcarse porque la actualizacion del software es compatible con versiones anteriores. Sin embargo, dado que los cambios involucrados en esta actualización modifican las reglas de consenso, los nodos actualizados y los nodos no actualizados no serán compatibles, lo que lleva a un hard fork.

Tenga en cuenta que este hard fork es aceptado y deseado por la comunidad, por lo que la mayoría de los nodos se actualizarán para admitir el hard fork. Todos los nodos o billeteras que pierdan la actualización se desconectarán automáticamente de la red y se quedarán atrapados en una cadena dividida moribunda, incapaz de completar las transacciones y potencialmente apostando sus monedas en la cadena dividida, que son muy difíciles de recuperar. Para ahorrar problemas, se recomienda actualizar para el hard fork.

Descripción general de QIP relacionada con el hard fork

QIP-5

Descripción

La verificación de firma se agrega al script de salida de la transacción del contrato para probar la propiedad e invocar el contrato sin tener ningúna QTUM en la dirección.

Motivación

Llamar a cualquier contrato inteligente en Qtum requiere una tarifa de gas para la ejecución del contrato inteligente. Para cada invocación de contrato, se requiere un saldo en la dirección que llama al contrato (incluso si el saldo es muy pequeño). Por ejemplo, la transferencia de tokens QRC20 es la invocación de contrato más común. Suponga que hay 1000 tokens QC (una moneda estable QRC20 lanzada en Qtum) vinculados a la dirección A. Para enviar estos 1000 QC, se requiere una cierta cantidad de QTUM en la dirección A para pagar el gas por la transferencia de tokens (típicamente 0.04 a 0.10 QTUM) . Si la dirección A no tiene ningún saldo QTUM, no puede pagar la tarifa de gas y el 1000 QC no se puede enviar a una nueva dirección.

La única solución actualmente es transferir algo de QTUM a la dirección A y luego enviar los tokens de control de calidad. Sin embargo, esto no solo desperdicia valiosos recursos 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 aplicación más complejos de contratos inteligentes (como pronósticos de aplicaciones de mercado, intercambios descentralizados, etc.), esta limitación aumenta significativamente el umbral para que los usuarios usen aplicaciones blockchain.

Beneficios

Al agregar el código de operación OP_SENDER, QIP-5 proporciona un mecanismo para probar la propiedad de la dirección de invocación del contrato, que puede ofrecer pruebas sin QTUM en la dirección y luego invocar el contrato inteligente. Aunque se han realizado pocos cambios en el sistema original, se han producido cambios importantes en el ecosistema de contrato inteligente existente:

  • Las direcciones pueden invocar contratos inteligentes (como enviar y recibir tokens QRC20) sin QTUM, lo que mejora la experiencia de transferencia de tokens para usuarios comunes. Nota: Esto no significa que el contrato pueda invocarse sin cargo, sino que puede pagarse en otras direcciones;
  • Surgirán servicios más diversificados. Los proveedores de servicios pagarán la tarifa, mientras que los usuarios solo necesitan usar el servicio, que está más cerca del escenario real de la aplicación;
  • Permite que múltiples direcciones invoquen múltiples contratos en una transacción, aumentando la flexibilidad de la invocación de contratos;
  • Guarde los recursos del conjunto de datos UTXO en la cadena.

Posibles riesgos

QIP-5 agrega reglas de consenso adicionales, pero sigue siendo compatible con las reglas originales, por lo que no hay riesgo de seguridad en teoría. Pero tendrá algún impacto en la infraestructura existente:

  • Se deben desarrollar comandos RPC adicionales para usar esta función de manera adecuada, y los proveedores de servicios deben sincronizar las actualizaciones de infraestructura;
  • Debido a los scripts adicionales, los proveedores de servicios deberán realizar una validación adicional en los scripts, de lo contrario, no podrán identificar tales transacciones.

Para la implementación específica de QIP-5, consulte este documento.

QIP-6

Descripción

Agregue un contrato precompilado btc_ecrecover a Qtum EVM para la invocación directa de contratos comunes.

Motivación

En Solidity, la función de encubierto puede restaurar una firma de 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, mientras que el formato de dirección devuelto por la función ecrecover es el mismo que el de Ethereum, por lo que los dos no se pueden comparar directamente. Para los desarrolladores, esto tomará algunas decisiones lógicas en el contrato engorroso. En la actualidad, la forma común de resolver este problema es invocar contratos de biblioteca adicionales, pero eso consumirá más gas, aumentando el costo del uso de contratos inteligentes.

Beneficios

QIP-6 implementa una función llamada btc_recover mediante la precompilación de contratos. La nueva función, si bien es compatible con todas las interfaces de la función original, puede brindar los siguientes beneficios:

  • El tipo de dirección devuelto por btc_recover es idéntico al formato de dirección de msg.sender, que permite la comparación directa y simplifica la decisión lógica en el proceso de desarrollo del contrato.
  • Los contratos precompilados pueden ahorrar mucho el consumo de gas y reducir el costo del uso de contratos inteligentes.

Posibles riesgos

QIP-6 no realiza ningún cambio en el sistema original, y la nueva función es totalmente compatible con la interfaz de función original, por lo que no hay riesgo en teoría.

Para la implementación específica de QIP-6, consulte este documento.

QIP-7

Descripción

Actualice Qtum EVM a la última versión de Ethereum de Constantinople.

Motivación

Actualmente, Qtum usa una versión anterior del EVM. Después del lanzamiento de Qtum MainNet, el EVM se ha actualizado a Byzantine y Constantinople. Se han agregado muchas características nuevas para desarrolladores a la nueva versión de la máquina virtual, como devolver datos de longitud variable e invocar contratos estáticos. Cada vez más desarrolladores necesitan confiar en estas nuevas características para el desarrollo de contratos y aplicaciones.

Beneficios

QIP-7 incluye todas las nuevas características de las versiones EVM Byzantine y Constantinopla, lo que permite contratos y aplicaciones inteligentes más complejos. Por ejemplo, Qtum planea admitir activos privados en QIP-19, donde los contratos inteligentes relacionados se basan en las nuevas características proporcionadas en el nuevo EVM. Además, después de la actualización, todos los contratos y aplicaciones inteligentes en Ethereum se pueden trasplantar teóricamente a Qtum mientras se obtiene la seguridad y la estabilidad únicas del modelo UTXO subyacente.

Posibles riesgos

Tanto el EVM Byzantine como Constantinopla se han activado en Ethereum Mainnet, de la que se ha verificado la estabilidad, y son totalmente compatibles con el bajo riesgo. Sin embargo, la capa inferior de Qtum adopta el modelo UTXO, que es inconsistente con el modelo de cuenta de EVM. Los desarrolladores deben prestar atención a las características de Qtum EVM al trasplantar contratos existentes.

Para la implementación específica de QIP-7, consulte este documento.

QIP-9

Descripción

QIP-9 en realidad dos actualizaciones:

  1. Modifique el algoritmo de ajuste de dificultad para Qtum Proof-of-Stake para que el tiempo de bloqueo sea más estable y reduzca el tiempo promedio de bloqueo a 128 segundos como se indica en el diseño original.
  2. Modifique el algoritmo de estimación de peso de red para acercarlo al valor real (no relacionado con el consenso).

Motivación

Qtum fue diseñado para un intervalo de bloque de 128 segundos. En el proceso descentralizado de Prueba de participación de Qtum, el tiempo de los bloques reales debe mostrar una variación aleatoria de alrededor de 128 segundos, y el algoritmo de ajuste de dificultad ajustará la dificultad hacia arriba o hacia abajo para mantener este promedio. Desafortunadamente, un error sutil en el algoritmo de ajuste de dificultad ha causado dos problemas, 1) algunos intervalos largos excesivos para los bloques y 2) un intervalo promedio de bloque de 144 segundos. Este intervalo promedio más alto significa que la blockchain se ejecuta un poco más lento que el diseño, y que las transacciones por segundo son 12.5% bajas y las recompensas de bloque de apuestas son 12.5% bajas.

El peso de la red es una estimación del total de monedas en juego en la red Qtum y se utiliza para calcular los rendimientos esperados para el staking (tiempo esperado para una recompensa en bloque). Dado que Qtum es una red completamente descentralizada, el peso de toda la red solo puede estimarse por la dificultad de staking. Sin embargo, el cálculo del peso de red existente fluctúa mucho y no refleja con precisión el estado actual de la red.

Beneficios

  • QIP-9 proporciona un algoritmo de ajuste de dificultad mejorado que se ajusta a la dificultad en función de un promedio móvil exponencial de intervalos de bloque. Este algoritmo mejorado tiene los beneficios de eliminar los intervalos de bloqueo muy largos y proporcionar un intervalo de bloqueo promedio de 128 segundos. Este intervalo de bloqueo promedio más rápido significa que las transacciones de red por segundo y las recompensas de bloque para las billeteras de apuestas aumentarán en un 12.5%.
  • QIP-9 mejora la estimación del peso de la red al cambiar el cálculo para usar un divisor fijo para el intervalo de 128 segundos. En comparación con el enfoque original de Peso de red, la variación entre el nuevo Peso de red y el peso real es menor, y la fluctuación es menor, lo que significa una estimación más precisa del estado actual de la red.

Posibles riesgos

  • El algoritmo de ajuste de dificultad involucrado en QIP-9 no tiene riesgos de seguridad.
  • Aunque el cálculo de la estimación del peso de la red proporciona valores relativamente suaves, no puede reflejar el cambio del peso de la red si el peso real fluctúa bruscamente, por lo que todavía hay margen de mejora. Sin embargo, la actualización de Peso de red no involucra el mecanismo de consenso, por lo que puede modificarse nuevamente en actualizaciones comunes posteriores.

Para la implementación específica de QIP-9, consulte este documento.

El plan de lanzamiento de Hard Fork

El código para este hard fork se ha desarrollado y probado completamente durante casi medio año y se ha ejecutado con éxito en redes de prueba privadas. Ya se ha activado en Qtum Testnet a la altura del bloque # 446,320. Después de un período de funcionamiento estable en Testnet, se activará oficialmente en Qtum Mainnet.

La actualización se activó automáticamente a la altura del bloque preestablecido, en Testnet en el bloque 446,320 el 20 de septiembre de 2019, y lo hará en Mainnet en el bloque 466,600 el 17 de octubre de 2019. Se recomienda que los usuarios mantengan la billetera en funcionamiento como el último funcionario Versión de lanzamiento para que las billeteras se actualicen sin problemas.

La actualización solo se aplica a la billetera Qtum Core y a los nodos completos que usan la billetera Qtum Core. No se requieren cambios para los usuarios de otras billeteras QTUM, como Electrum, Ledger o la billetera web Qtum.

El Impacto de no actualizar

Cuando se alcanza la altura del bloque para activar el hard fork, las billeteras actualizadas desconectarán a los pares que no se hayan actualizado. Esto significa que los nodos y billeteras de versiones anteriores que no se han actualizado no podrán realizar transacciones ni apostar en la cadena principal. En cambio, sus transacciones y stakes se llevarán a cabo en una cadena dividida bifurcada que desaparecerá gradualmente a medida que esos nodos se actualicen. Los nodos en la cadena dividida verán un peso de red muy bajo, y las billeteras de staking pueden ver una gran cantidad de recompensas de bloque a medida que se apilan en la cadena dividida. Dado que estas transacciones de apuesta están comprometidas con la cadena dividida, en ese punto incluso después de actualizar la billetera y resincronizar la blockchain, faltarán las apuestas, lo que significa que se necesitarán técnicas de recuperación de billetera más avanzadas.

Preparativos

Qtum notificará a todos los exchanges, proveedores de servicios (billeteras, exploradores), stakers y usuarios comunes para completar la actualización antes de la activación de hard fork para garantizar una actualización sin problemas.

El equipo de desarrollo de Qtum ha llevado a cabo pruebas internas exitosas durante medio año antes del lanzamiento. La actualización se activará en Testnet un mes antes de Mainnet, para validar aún más las operaciones y verificar los cambios esperados.

Todos los usuarios deben mantener sus billeteras / nodos Qtum Core actualizados a la última versión y estar al tanto de los síntomas de los problemas descritos anteriormente (bajo peso de la red, stakin=]\the excesivo) si sus billeteras no se actualizan por adelantado.

¿Habrá un Hard Forks en el futuro?

Mientras la actualización esté relacionada con el consenso, puede requerir un hard fork. En ese momento, los usuarios serán notificados de la actualización a través de un proceso similar. La posterior máquina virtual x86, los activos privados y las funciones de staking de contratos inteligentes que Qtum planea lanzar pueden requerir hard forks. El equipo de desarrollo de Qtum fusionará las actualizaciones que requieren forks para minimizar las actualizaciones de hard fork.

¿Qué deben hacer los usuarios?

Para operaciones continuas y para evitar el staking en la cadena dividida, todos los usuarios que ejecutan nodos / billeteras Qtum Core necesitan actualizar a la última versión de la billetera antes de la altura del bloque de activación de el hard fork. Estén atentos a https://github.com/qtumproject/qtum/releases/ o https://qtumeco.io/wallet para obtener información sobre el lanzamiento de la billetera y actualizar a la última versión lo antes posible.

Para diferentes participantes en la red, se recomienda estar completamente preparado para la actualización:

Exchanges y billeteras

  • Antes y después de la activación del hard fork, preste atención a los registros de depósito y retiro de tokens QTUM y QRC20, y confirme la transferencia después de que la transacción haya recopilado suficientes confirmaciones en Mainnet;
  • Para retirar los tokens QRC20, es posible actualizar el programa de soporte (relacionado con QIP-5) de antemano para que las nuevas funciones se puedan usar para pagar las tarifas de gas.

Proveedores de servicios (como los exploradores)

  • Se recomienda desarrollar de antemano el soporte relacionado con QIP-5 para evitar ser incapaz de identificar la salida de la transacción con OP_SENDER después de la activación de hard fork.

Stakers (mining pools, personas stakers)

  • Antes y después de que se active la actualización, preste especial atención al Peso de la red y bloquee las recompensas. Las recompensas de bloque aumentarán a medida que el intervalo de bloqueo promedio caiga a 128 segundos (600 bloques por día frente a 675 bloques por día actualmente).

Desarrolladores

  • Los contratos y las aplicaciones con nuevas características pueden desarrollarse primero en Testnet y luego implementarse en Mainnet cuando se activa la red principal. (QIP-7)
  • Considere más escenarios basados en QIP-5.

Cada usuario

  • ¡Siempre respalde sus billeteras!

--

--

No responses yet