CIP 90: un espacio totalmente compatible con EVM

Resumen sencillo

Introduce un nuevo espacio que es totalmente compatible con EVM.

General

Este CIP tiene como objetivo introducir un nuevo espacio totalmente compatible con EVM. El nuevo espacio se llama EVM Space y el espacio actual se llama Native Space. EVM Space sigue la misma regla que EVM y admite rpc de eth como eth_getBalance, por lo que las herramientas de ethereum se pueden usar directamente en Conflux.

Las cuentas en dos espacios están separadas. Una cuenta de espacio nativo solo puede interactuar con otras cuentas en espacio nativo con el tipo de transacciones de Conflux original. Una cuenta de espacio EVM solo puede interactuar con otras cuentas en el espacio EVM con el tipo de transacciones Ethereum EIP-155. Se implementará un nuevo contrato interno para activos y datos entre espacios. A diferencia de las operaciones entre cadenas, las entre espacios son atómicas y con seguridad de capa 1.

Motivación

Conflux tiene una máquina virtual que es similar a EVM. Sin embargo, todavía existen algunas diferencias entre Conflux VM y Ethereum VM. Conflux tiene un formato de transacción diferente y una regla diferente para generar direcciones a partir de claves públicas. Esto impide que las dApps compatibles con EVM se transfieran a Conflux directamente. Los anteriores CIP-72 y CIP-80 intentan solucionar estos obstáculos. Pero eso influirá en las aplicaciones actuales. Entonces, este CIP presenta un nuevo espacio que sea totalmente compatible con EVM sin cambiar las cuentas y transacciones existentes.

Especificación

Direcciones

A nivel de usuario, el espacio nativo aún usa direcciones de formato base32 como cfx:aa... y el espacio EVM usa direcciones de suma de verificación hexadecimal como 0xaAD8... . A nivel de sistema, tanto el espacio nativo como el espacio EVM están en formato de 160 bits. Una dirección en dos espacios son dos cuentas diferentes. Sus saldos y nonces se computarán por separado.

Clave de almacenamiento

Conflux usa Delta MPT como la estructura de datos autenticados para el estado del libro mayor. Delta MPT proporciona una interfaz clave-valor para la máquina virtual.

Al calcular la clave de almacenamiento para las cuentas en el espacio EVM, calculamos la clave de almacenamiento para la cuenta con la misma dirección en el espacio nativo e insertamos el byte 0x81 en la posición 20 (el índice comenzó en 0).

Al calcular la clave de almacenamiento del conjunto delta (consulta la sección 3.2.2) para las cuentas en el espacio EVM, calculamos la clave de almacenamiento para la cuenta con la misma dirección en el espacio nativo e insertamos el byte 0x81 en la posición 32 (el índice comienza en 0 ).

Maquina Virtual

  • Admite los contratos precompilados en Ethereum desde la dirección 0x00..01 hasta la dirección 0x00..08.
  • El opcode NUMBER devolverá el número de época.
  • El opcode BLOCKHASH solo puede tomar NUMBER-1 como entrada. (A diferencia de Ethereum, que toma cualquier número entero en NUMBER-256 a NUMBER-1 como entrada).
  • Sin reembolso de gas en el opcode STORE y SUICIDE.
  • Las operaciones que ocupan almacenamiento tienen un costo de gas diferente.
    • STORE cuesta 40,000 de gas (en lugar de 20,000 de gas en Ethereum) al cambiar una entrada de almacenamiento de cero a una distinta de cero.
    • Al implementar un nuevo contrato, cada byte cuesta 400 gas (en lugar de 200 gas en Ethereum).
    • Al crear una nueva cuenta por CALL o SUICIDE, consume 50,000 gas (en lugar de 25,000 gas en Ethereum).

Operaciones de espacio cruzado

Cuenta asignada

Cada cuenta del espacio nativo tiene una cuenta asignada en el espacio EVM. La dirección de la cuenta asignada son los últimos 160 bits del valor hash keccak de la cuenta original. Con la suposición de la seguridad de la función hash keccak, la dirección asignada nunca chocará con las direcciones generadas por las herramientas de Ethereum. La cuenta del espacio nativo puede retirar el saldo de la cuenta asignada.

Contrato Interno

Se implementará un nuevo contrato interno denominado contrato CrossSpace en la dirección 0x0888000000000000000000000000000000000006 con las siguientes interfaces. El usuario/contrato del espacio nativo puede interactuar con las cuentas en el espacio EVM y procesar el valor devuelto en la misma transacción. Entonces las operaciones de espacio cruzado pueden ser atómicas.

Al realizar una llamada de espacio cruzado, solo se puede pasar 1/10 del gas disponible en el espacio EVM. Esto tiene como objetivo limitar el uso de gas en una llamada entre espacios.

pragma solidity >=0.5.0;

interface CrossSpace {

    event Call(bytes20 indexed sender, bytes20 indexed receiver, uint256 value, uint256 nonce, bytes data);

    event Create(bytes20 indexed sender, bytes20 indexed contract_address, uint256 value, uint256 nonce, bytes init);

    event Withdraw(bytes20 indexed sender, address indexed receiver, uint256 value);

    function createEVM(bytes calldata init) external payable returns (bytes20);

    function transferEVM(bytes20 to) external payable returns (bytes memory output);

    function callEVM(bytes20 to, bytes calldata data) external payable returns (bytes memory output);

    function staticCallEVM(bytes20 to, bytes calldata data) external view returns (bytes memory output);

    function withdrawFromMapped(uint256 value) external;

    function mappedBalance(address addr) external view returns (uint256);

    function mappedNonce(address addr) external view returns (uint256);
}

Límite de gas del bloque

Solo el bloque cuya altura de bloque es un múltiplo de 5 puede empaquetar transacciones de tipo Ethereum. El límite de gas total de estas transacciones no puede exceder la mitad del límite de gas del bloque.

Razón fundamental

Acerca de la clave de almacenamiento

En la implementación actual, el byte 21 de la clave de almacenamiento codificada es un carácter ASCII válido. Por lo tanto, establecer el bit más alto del byte 21 puede distinguir las nuevas claves de almacenamiento de las claves existentes.

Acerca de la interfaz de los contratos internos

Los contratos internos utilizan el tipo bytes20 para indicar una dirección en el espacio EVM. Porque una dirección de espacio EVM puede no ser válida en el espacio de Conflux y ser rechazada por algunas interfaces en RPC.

Compatibilidad

Este CIP está rompiendo las especificaciones.

Casos de prueba.

Por actualizar…

Implementación

Por actualizar…

Consideraciones de Seguridad

Por actualizar…

Derechos de autor

Derechos de autor y derechos relacionados renunciados a través deCC0.

4 Likes

Muy buena información :smiley::smiley:

1 Like

Conflux ofrece una robusta escalabilidad y rapidez en las transacciones

2 Likes

Excelente artículo!!

1 Like

Que bien conflux …

1 Like