El próximo hardfork de Conflux Network incluirá 6 CIP (propuestas de mejora de Conflux) y la adición de una capa PoS : CIP-43, CIP-64, CIP-71, CIP-72, CIP-76 y CIP-78. A continuación se presenta un resumen de cada propuesta.
CIP-43
Resumen simple
Proponemos introducir la finalidad de la cadena Conflux mediante la votación entre los titulares de CFX apostados. Esto aumentará la confianza de las transacciones de alto valor que se realicen en Conflux y protegerá a Conflux contra posibles ataques del 51% de PoW.
Resumen
Introducir una cadena Proof of Stake autónoma, que supervise el proceso de la estructura del árbol-grafo de Proof of Work y llegue a un consenso para los bloques pivotantes confirmados bajo la regla de confirmación PoW. Una vez que la cadena PoS considera un bloque pivote como confirmado, todos los mineros PoW deben seguirlo. Esto protegerá eficazmente a la cadena Conflux de los ataques de largo alcance del 51% de PoW.
Los titulares de CFX pueden depositar en un contrato específico para reclamar derechos de voto en la cadena PoS. La cadena PoS utiliza una fuente de aleatoriedad verificable para seleccionar los nodos con derecho a voto. El comité es temporal y rotará periódicamente cada seis horas. Los mandatos son escalonados, aproximadamente una sexta parte de los puestos del comité son elegidos cada hora (El diseño de este CIP es relativamente complejo, y puede haber un ajuste de los parámetros más adelante). El interés sólo puede generarse haciendo staking en la cadena de PoS. Próximamente se darán más detalles sobre el modelo económico.
Motivación
En la fase inicial del desarrollo ecológico de una cadena pública, la cantidad total de potencia de cálculo es relativamente insuficiente. Esto da lugar a un bajo coste de ataque para lanzar ataques del 51% y robar los fondos de la cadena mediante el doble gasto. En el último año, Ethereum Classic, Grin y Verge sufrieron ataques del 51%. Para mitigar la amenaza del atacante, estamos añadiendo la finalidad de PoS, que forma un comité de staking que recomienda bloques de pivote confirmados que los nodos PoW deben seguir.
Consideraciones de seguridad
Un mecanismo de consenso PoW suele proporcionar seguridad cuando el atacante controla <50% de potencia de cálculo. Pero, ¿cuál es el caso después de activar el CIP-43? He aquí algunos escenarios que ayudan a explicarlo.
Ataque del 51%
Si el atacante controla >51% de poder de cómputo y la cadena PoS funciona bien, los bloques pivote que han sido decididos por la cadena PoS siguen siendo seguros. Sin embargo, la cadena PoW puede perder liveness porque los nodos PoS no pueden confirmar ningún bloque nuevo. Si el atacante desaparece, el protocolo de consenso puede ejecutarse como siempre.
Ataque de staking del 17%
Si el atacante controla >17% de los miembros del comité, la cadena PoS puede perder liveness. Entonces la cadena Conflux se ejecuta como si CIP-43 no estuviera activado. Si el atacante desaparece, el protocolo de consenso puede ejecutarse como siempre.
Ataque de staking del 84%
Si el atacante controla >84% de los miembros del comité, puede generar bloques PoS conflictivos. En este caso, la cadena PoW divergirá, incluso si el atacante desaparece.
Ataque de largo alcance
A diferencia del ataque de estacionamiento del 84%, en un ataque de largo alcance, un nodo PoS se vuelve malicioso, no porque tenga la intención de romper el consenso, sino porque ha perdido las claves privadas. Así que asumimos que el atacante sólo puede controlar el comité mayoritario en una fase muy temprana. Si el atacante controla >51% de potencia de cálculo y puede revertir la cadena PoW desde la etapa inicial, se produce un ataque de doble gasto. De lo contrario, el protocolo de consenso puede ejecutarse como siempre.
CIP-64
Resumen simple
Actualmente, las transacciones en Conflux no tienen acceso directo al número de la época en la que se ejecutan. Para mantener la compatibilidad con EVM, este CIP introduce un nuevo contrato interno que pone esta información a disposición de los contratos.
Resumen
Una técnica común en el desarrollo de dapp es almacenar el número de bloque correspondiente a un evento en el almacenamiento de un contrato y posteriormente utilizar esta información para consultar el contrato. Por ejemplo, es posible que se quiera empezar a consultar los registros a partir de la creación del contrato. Sin embargo, las APIs de consulta de Conflux trabajan con números de época, no con números de bloque, lo que hace inviable esta técnica. Este CIP introduce un nuevo contrato interno que pone a disposición de los contratos el número de época de ejecución.
Motivación
Hay dos casos de uso comunes para utilizar números de bloque (block.number) en los contratos inteligentes.
El primer caso de uso es la sincronización. La tasa de crecimiento de los números de bloque es relativamente estable y difícil de influir, lo que los hace adecuados para aplicaciones como los bloqueos de tiempo.
El segundo caso de uso es la consulta. Por ejemplo, un contrato podría almacenar su número de bloque de creación y los clientes podrían leerlo para saber a partir de qué bloque tienen que empezar a consultar los eventos del contrato.
Este último caso de uso no es factible en Conflux, ya que nuestras API de consulta (RPC) sólo admiten la consulta por número de época, no por número de bloque.
CIP-71
Resumen simple
Permitir que el desarrollador del contrato desactive la anti-reentrada para su contrato.
Resumen
Actualmente, Conflux VM tiene un mecanismo anti-reentrada. Cuando un contrato aparece dos veces en la pila de llamadas, Conflux prohibirá todas las operaciones de escritura posteriores como SSTORE, LOG0 a LOG4 y CALL con un saldo distinto de cero. Este CIP pretende hacer que esta característica sea configurable. Se debe introducir un nuevo contrato interno que permita al propio contrato o a su administrador activar o desactivar esta función.
Motivación
Conflux introduce un mecanismo anti-reentrada para evitar algunos ataques a las aplicaciones Defi. Sin embargo, esto también prohibirá algunas operaciones válidas. Por ejemplo, si un contrato de prestatario llama a un contrato de préstamo flash y el contrato de préstamo flash llama a la función “callback” del contrato de prestatario. Entonces el contrato prestatario aparecerá dos veces en la pila de llamadas y todas las operaciones de escritura posteriores estarán prohibidas. Aunque los desarrolladores pueden evitar este problema cambiando la lógica de interacción entre contratos, esto introduce tareas adicionales para la migración de contratos.
Conflux prohibirá las operaciones de escritura (activará el mecanismo antireentrada) sólo si una dirección de contrato que no permite la reentrada aparece dos veces en la pila de llamadas.
CIP-72
Resumen simple
Conflux reconocerá y aceptará las firmas de las carteras de Ethereum, como Metamask.
Resumen
Conflux tiene un formato de transacción diferente al de Ethereum, por lo que Metamask no puede producir una firma de transacción aceptada por Conflux. Este CIP planea hacer que Conflux trate las transacciones con época de destino u64::MAX como transacción de tipo Ethereum y utiliza una forma diferente de verificar las transacciones.
Motivación
Este CIP permitirá a los usuarios interactuar con contratos inteligentes en la cadena Conflux con carteras de Ethereum como Metamask. Creemos que esto puede atraer a más usuarios a experimentar la cadena Conflux.
Consideraciones de seguridad
Si un transmisor malicioso intenta manipular la transacción tipo Ethereum, no podrá cambiarla por una transacción diferente que pueda pasar la verificación de la firma.
CIP-76
Resumen simple
Deberíamos eliminar las restricciones relacionadas con la VM en la sincronización de bloques, como exigir que las transacciones tengan un límite de gas suficiente.
Resumen
Actualmente, antes de añadir nuevos bloques a los gráficos de sincronización, comprobamos varias restricciones. Una de ellas requiere que el límite de gas de las transacciones supere un umbral mínimo. Sin embargo, este umbral depende del plan de gas de la máquina virtual, que puede cambiar en futuras actualizaciones. Este CIP propone eliminar las restricciones relacionadas con la máquina virtual en la sincronización de bloques y evitar la introducción de reglas similares en el futuro.
Motivación
Desacoplar el componente de consenso con el componente de ejecución es vital para los futuros planes de actualización. El protocolo de consenso debe ser transparente para el componente de ejecución.
Sin embargo, si el gráfico de sincronización lee los parámetros relacionados con la VM al comprobar la validez de un bloque recibido, cualquier cambio en el nivel de la VM puede provocar una bifurcación dura en el protocolo de consenso.
La restricción para el límite de gas de las transacciones no puede evitar que un minero malicioso complete un bloque con transacciones inútiles porque no comprobamos si el remitente tiene suficiente saldo para pagar la tasa de gas. El minero malicioso puede empaquetar un montón de transacciones cuyo remitente tiene saldo cero.
Especificación
Después de una altura de época determinada, el protocolo de consenso ya no comprueba las alturas de los bloques para las transacciones.
Consideraciones de seguridad
Como se ha descrito en la parte de motivación, la implementación actual no puede evitar que un minero malicioso llene de transacciones inútiles un bloque. Por lo tanto, la eliminación de una restricción no la empeorará.
CIP-78
Resumen simple
Corregir los campos incorrectos en la recepción de transacciones.
Resumen
Actualmente, el recibo de la transacción indica que la transacción no está patrocinada cuando su ejecución falla, aunque el patrocinador pague realmente la tasa de gas. Además, cuando el patrocinador no tiene saldo suficiente para la garantía de almacenamiento, el remitente se hace cargo de la garantía de almacenamiento. Sin embargo, el recibo deja constancia de que la transacción está patrocinada.
Motivación
Pase lo que pase, los campos “is_sponsored” en el recibo de la transacción deben ser siempre coherentes con si el patrocinador paga.
CIP-64
Las transacciones en Conflux tendrán acceso directo al número de la época en que se ejecutan. Para mantener la compatibilidad con EVM, este CIP introduce un nuevo contrato interno que pone esta información a disposición de los contratos.
CIP-71
Permitir al desarrollador del contrato desactivar la anti-reentrada para su contrato.
CIP-72
Conflux aceptará las firmas de los monederos de Ethereum, como Metamask.
CIP-76
Eliminaremos las restricciones relacionadas con la VM en la sincronización de bloques, como el requerimiento de que las transacciones tengan suficiente límite de gas.
CIP-78
Arreglamos los campos incorrectos en la recepción de transacciones.
Conecta con nosotros:
Website / Github / Twitter / Discord / Telegram / Reddit / YouTube / Forum