Profundizando en EVM: cómo funciona Ethereum entre bastidores

Una explicación definitiva y detallada de cómo funciona EVM. Esta publicación es una continuación de mi iniciada en un esfuerzo por proporcionar una comprensión más profunda del funcionamiento interno y otras cosas interesantes sobre Ethereum y blockchain en general que no encontrará fácilmente en la web. Aquí están las partes anteriores de la serie en caso de que te las hayas perdido: serie Getting Deep Into Profundizando en Geth: por qué sincronizar el nodo Ethereum es lento Profundizando en Ethereum: ¿Cómo se almacenan los datos en Ethereum? En esta parte, vamos a explorar, explicar y describir en detalle el comportamiento central del EVM. Veremos cómo se crean los contratos, cómo funcionan las llamadas de mensajes y echaremos un vistazo a todo lo relacionado con la gestión de datos, como el almacenamiento, la memoria, los datos de llamadas y la pila. Para comprender mejor este artículo, debe estar familiarizado con los conceptos básicos de Ethereum. Si no lo eres, te recomiendo leer estas publicaciones primero. 5 recursos para comenzar con ethereum A lo largo de este post ilustraremos algunos ejemplos y demostraciones usando contratos modelo que puedes encontrar en . Clónelo, ejecute npm install y compruébelo antes de comenzar. este repositorio Disfrute, y no dude en comunicarse con preguntas, sugerencias o comentarios. EVM: Perspectiva de 10,000 pies Antes de profundizar en la comprensión de cómo funciona EVM y verlo funcionar a través de ejemplos de código, veamos dónde encaja EVM en Ethereum y cuáles son sus componentes. No se asuste con estos diagramas porque tan pronto como termine de leer este artículo, podrá encontrar mucho sentido a estos diagramas. El siguiente diagrama muestra dónde encaja EVM en Ethereum. El siguiente diagrama muestra la arquitectura básica de EVM. El siguiente diagrama muestra cómo las diferentes partes de EVM interactúan entre sí para hacer que Ethereum haga su magia. Hemos visto cómo se ve EVM. Ahora es el momento de comenzar a comprender cómo estas partes juegan un papel importante en la forma en que funciona Ethereum. Contratos de Ethereum Lo esencial Los contratos inteligentes son solo programas de computadora, y podemos decir que los contratos de Ethereum son contratos inteligentes que se ejecutan en la máquina virtual de Ethereum. El EVM es el tiempo de ejecución de espacio aislado y un entorno completamente aislado para contratos inteligentes en Ethereum. Esto significa que cada contrato inteligente que se ejecuta dentro de la EVM no tiene acceso a la red, el sistema de archivos u otros procesos que se ejecutan en la computadora que aloja la VM. Como ya sabemos, existen dos tipos de cuentas: contratos y cuentas externas. Cada cuenta se identifica mediante una dirección y todas las cuentas comparten el mismo espacio de direcciones. El EVM maneja direcciones de 160 bits de longitud. Cada cuenta consta de un saldo, un nonce, un código de bytes y datos almacenados ( ). Sin embargo, existen algunas diferencias entre estos dos tipos de cuentas. Por ejemplo, el código y el almacenamiento de las cuentas externas están vacíos, mientras que las cuentas de contrato almacenan su código de bytes y el hash raíz de Merkle de todo el árbol de estado. Además, mientras que las direcciones externas tienen una clave privada correspondiente, las cuentas de contrato no la tienen. Las acciones de las cuentas de contrato están controladas por el código que alojan además de la firma criptográfica regular de cada transacción de Ethereum. almacenamiento Creación La creación de un contrato es simplemente una transacción en la que la dirección del destinatario está vacía y su campo de datos contiene el código de bytes compilado del contrato que se creará (esto tiene sentido: los contratos también pueden crear contratos). Veamos un ejemplo rápido. Abra el directorio del ; en él encontrarás un contrato llamado MyContract con el siguiente código: ejercicio 1 pragma solidity ^0.4.21; contract MyContract { event Log(address addr); function MyContract() public { emit Log(this); } function add(uint256 a, uint256 b) public pure returns (uint256) { return a + b; } } Abramos una consola de truffle en modo de desarrollo ejecutando truffle Develop. Una vez dentro, siga los siguientes comandos para implementar una instancia de MyContract: truffle(develop)> compile truffle(develop)> sender = web3.eth.accounts[0] truffle(develop)> opts = { from: sender, to: null, data: MyContract.bytecode, gas: 4600000 } truffle(develop)> txHash = web3.eth.sendTransaction(opts) Podemos comprobar que nuestro contrato se ha implementado correctamente ejecutando el siguiente código: truffle(develop)> receipt = web3.eth.getTransactionReceipt(txHash) truffle(develop)> myContract = new MyContract(receipt.contractAddress) truffle(develop)> myContract.add(10, 2) { [String: '12'] s: 1, e: 1, c: [ 12 ] } Profundicemos más para analizar lo que acabamos de hacer. Lo primero que sucede cuando se implementa un nuevo contrato en la cadena de bloques de Ethereum es que se crea su cuenta.¹ Como puede ver, registramos la dirección del contrato en el constructor en el ejemplo anterior. Puede confirmarlo comprobando que recibo.logs[0].data es la dirección de los 32 bytes del contrato y que recibo.logs[0].topics es el hash keccak-256 de la cadena "Registro(dirección)" . Qué sucede entre bastidores cuando llamas a una función en tu contrato Como siguiente paso, los datos enviados con la transacción se ejecutan como código de bytes. Esto inicializará las variables de estado almacenadas y determinará el cuerpo del contrato que se está creando. Este proceso se ejecuta solo una vez durante el ciclo de vida de un contrato. El código de inicialización no es lo que se almacena en el contrato; en realidad produce como valor de retorno el código de bytes que se almacenará. Tenga en cuenta que una vez que se ha creado una cuenta de contrato, no hay forma de cambiar su código.² Dado el hecho de que el proceso de inicialización devuelve el código del cuerpo del contrato para almacenarlo, tiene sentido que este código no sea accesible desde la lógica del constructor. Por ejemplo, echemos un vistazo al contrato imposible del : ejercicio 1 contract Impossible { function Impossible() public { this.test(); } function test() public pure returns(uint256) { return 2; } } Si intenta compilar este contrato, recibirá una advertencia que indica que está haciendo referencia a esto dentro de la función del constructor, pero se compilará. Sin embargo, si intenta implementar una nueva instancia, se revertirá. Esto se debe a que no tiene sentido intentar ejecutar un código que aún no está almacenado.³ Por otro lado, pudimos acceder a la dirección del contrato: la cuenta existe, pero aún no tiene ningún código. Sin embargo, la ejecución de un código puede producir otros eventos, como alterar el almacenamiento, crear más cuentas o realizar más llamadas de mensajes. Por ejemplo, echemos un vistazo al código de AnotherContract: contract AnotherContract { MyContract public myContract; function AnotherContract() public { myContract = new MyContract(); } } Veamos cómo funciona ejecutando los siguientes comandos dentro de una consola de truffle: truffle(develop)> compile truffle(develop)> sender = web3.eth.accounts[0] truffle(develop)> opts = { from: sender, to: null, data: AnotherContract.bytecode, gas: 4600000 } truffle(develop)> txHash = web3.eth.sendTransaction(opts) truffle(develop)> receipt = web3.eth.getTransactionReceipt(txHash) truffle(develop)> anotherContract = AnotherContract.at(receipt.contractAddress) truffle(develop)> anotherContract.myContract().then(a => myContractAddress = a) truffle(develop)> myContract = MyContract.at(myContractAddress) truffle(develop)> myContract.add(10, 2) { [String: '12'] s: 1, e: 1, c: [ 12 ] } Además, los contratos se pueden crear utilizando el código de operación CREAR, que es lo que compila la nueva construcción de Solidity. Ambas alternativas funcionan de la misma manera. Sigamos explorando cómo funcionan las llamadas de mensajes. Mensaje de llamadas Los contratos pueden llamar a otros contratos a través de llamadas de mensajes. Cada vez que un contrato de Solidity llama a una función de otro contrato, lo hace produciendo una llamada de mensaje. Cada llamada tiene un remitente, un destinatario, una carga útil, un valor y una cantidad de gas. La profundidad de la llamada de mensaje está limitada a menos de 1024 niveles. Solidity proporciona un método de llamada nativo para el tipo de dirección que funciona de la siguiente manera: .llamada.gas( ).valor( )( ) dirección gas valor datos gas es la cantidad de gas que se reenviará, address es la dirección a la que se llamará, value es la cantidad de Ether que se transferirá en wei y data es la carga útil que se enviará. Tenga en cuenta que el valor y el gas son parámetros opcionales aquí, pero tenga cuidado porque casi todo el gas restante del remitente se enviará por defecto en una llamada de bajo nivel. mapa de gastos de gas Como puede ver, cada contrato puede decidir la cantidad de gas a reenviar en una llamada. Dado que cada llamada puede terminar en una excepción de falta de gasolina (OOG), para evitar problemas de seguridad, se ahorrará al menos 1/64 de la gasolina restante del remitente. Esto permite a los remitentes manejar los errores de falta de combustible de las llamadas internas, de modo que puedan finalizar su ejecución sin quedarse sin combustible y, por lo tanto, aumentar la excepción. Mapa de excepciones de EVM Echemos un vistazo al contrato Caller del : ejercicio 2 contract Implementation { event ImplementationLog(uint256 gas); function() public payable { emit ImplementationLog(gasleft()); assert(false); } } contract Caller { event CallerLog(uint256 gas); Implementation public implementation; function Caller() public { implementation = new Implementation(); } function () public payable { emit CallerLog(gasleft()); implementation.call.gas(gasleft()).value(msg.value)(msg.data); emit CallerLog(gasleft()); } } El contrato de llamada tiene solo una función alternativa que redirige cada llamada recibida a una instancia de implementación. Esta instancia simplemente lanza una afirmación (falso) en cada llamada recibida, que consumirá todo el gas dado. Entonces, la idea aquí es registrar la cantidad de gas en la persona que llama antes y justo después de reenviar una llamada a Implementación. Abramos una consola de trufas y veamos qué sucede: truffle(develop)> compile truffle(develop)> Caller.new().then(i => caller = i) truffle(develop)> opts = { gas: 4600000 } truffle(develop)> caller.sendTransaction(opts).then(r => result = r) truffle(develop)> logs = result.receipt.logs truffle(develop)> parseInt(logs[0].data) //4578955 truffle(develop)> parseInt(logs[1].data) //71495 Como puede ver, es aproximadamente la parte 64 de . Este ejemplo demuestra claramente que podemos manejar una excepción OOG desde una llamada interna. 71495 4578955 Solidity también proporciona el siguiente código de operación, lo que nos permite administrar llamadas con ensamblaje en línea: call(g, a, v, in, insize, out, outsize) Donde g es la cantidad de gas que se reenviará, a es la dirección a la que se llamará, v es la cantidad de Ether que se transferirá en wei, in indica la posición de la memoria de los bytes de tamaño pequeño donde se guardan los datos de la llamada, y out y outsizestate donde los datos de retorno se almacenarán en la memoria. La única diferencia es que una llamada de ensamblaje nos permite manejar los datos devueltos, mientras que la función solo devolverá 1 o 0, ya sea que falle o no. El EVM admite una variante especial de una llamada de mensaje denominada llamada delegada. Una vez más, Solidity proporciona un método de dirección incorporado además de una versión de ensamblaje en línea. La diferencia con una llamada de bajo nivel es que el código objetivo se ejecuta dentro del contexto del contrato de llamada, y msg.sender y msg.value no cambian.⁴ Analicemos el siguiente ejemplo para comprender mejor cómo funciona una llamada de delegado. Empecemos con el contrato de Greeter: contract Greeter { event Thanks(address sender, uint256 value); function thanks() public payable { emit Thanks(msg.sender, msg.value); } } Como puede ver, el contrato de Greeter simplemente declara una función de agradecimiento que emite un evento que lleva los datos msg.value y msg.sender. Podemos probar este método ejecutando las siguientes líneas en una consola de truffle: truffle(develop)> compile truffle(develop)> someone = web3.eth.accounts[0] truffle(develop)> ETH_2 = new web3.BigNumber('2e18') truffle(develop)> Greeter.new().then(i => greeter = i) truffle(develop)> opts = { from: someone, value: ETH_2 } truffle(develop)> greeter.thanks(opts).then(tx => log = tx.logs[0]) truffle(develop)> log.event //Thanks truffle(develop)> log.args.sender === someone //true truffle(develop)> log.args.value.eq(ETH_2) //true Ahora que hemos confirmado su funcionalidad, prestemos atención al contrato de Wallet: contract Wallet { Greeter internal greeter; function Wallet() public { greeter = new Greeter(); } function () public payable { bytes4 methodId = Greeter(0).thanks.selector; require(greeter.delegatecall(methodId)); } } Este contrato solo define una función alternativa que ejecuta el método Greeter#thanks a través de una llamada de delegado. Veamos qué sucede cuando llamamos a Greeter#thanks a través del contrato de Wallet: truffle(develop)> Wallet.new().then(i => wallet = i) truffle(develop)> wallet.sendTransaction(opts).then(r => tx = r) truffle(develop)> logs = tx.receipt.logs truffle(develop)> SolidityEvent = require('web3/lib/web3/event.js') truffle(develop)> Thanks = Object.values(Greeter.events)[0] truffle(develop)> event = new SolidityEvent(null, Thanks, 0) truffle(develop)> log = event.decode(logs[0]) truffle(develop)> log.event // Thanks truffle(develop)> log.args.sender === someone // true truffle(develop)> log.args.value.eq(ETH_2) // true Como habrás notado, acabamos de confirmar que la función de llamada del delegado conserva msg.value y msg.sender . Esto significa que un contrato puede cargar código dinámicamente desde una dirección diferente en tiempo de ejecución. El almacenamiento, la dirección actual y el saldo todavía se refieren al contrato de llamada, solo el código se toma de la dirección llamada. Esto hace posible implementar la función de 'biblioteca' en Solidity”. ⁵ Hay una cosa más que debemos explorar acerca de las llamadas delegadas. Como se mencionó anteriormente, el almacenamiento del contrato de llamada es al que accede el código ejecutado. Veamos el contrato de la Calculadora: contract ResultStorage { uint256 public result; } contract Calculator is ResultStorage { Product internal product; Addition internal addition; function Calculator() public { product = new Product(); addition = new Addition(); } function add(uint256 x) public { bytes4 methodId = Addition(0).calculate.selector; require(addition.delegatecall(methodId, x)); } function mul(uint256 x) public { bytes4 methodId = Product(0).calculate.selector; require(product.delegatecall(methodId, x)); } } contract Addition is ResultStorage { function calculate(uint256 x) public returns (uint256) { uint256 temp = result + x; assert(temp >= result); result = temp; return result; } } contract Product is ResultStorage { function calculate(uint256 x) public returns (uint256) { if (x == 0) result = 0; else { uint256 temp = result * x; assert(temp / result == x); result = temp; } return result; } } El contrato Calculator tiene solo dos funciones: agregar y producir. El contrato de la Calculadora no sabe sumar ni multiplicar; en su lugar, delega esas llamadas a los contratos Addition y Product respectivamente. Sin embargo, todos estos contratos comparten el mismo resultado de variable de estado para almacenar el resultado de cada cálculo. Veamos cómo funciona esto: truffle(develop)> Calculator.new().then(i => calculator = i) truffle(develop)> calculator.addition().then(a => additionAddress=a) truffle(develop)> addition = Addition.at(additionAddress) truffle(develop)> calculator.product().then(a => productAddress = a) truffle(develop)> product = Product.at(productAddress) truffle(develop)> calculator.add(5) truffle(develop)> calculator.result().then(r => r.toString()) // 5 truffle(develop)> addition.result().then(r => r.toString()) // 0 truffle(develop)> product.result().then(r => r.toString()) // 0 truffle(develop)> calculator.mul(2) truffle(develop)> calculator.result().then(r => r.toString()) // 10 truffle(develop)> addition.result().then(r => r.toString()) // 0 truffle(develop)> product.result().then(r => r.toString()) // 0 Acabamos de confirmar que estamos utilizando el almacenamiento del contrato Calculator. Además, el código que se está ejecutando se almacena en los contratos de Adición y de Producto. Además, en cuanto a la función de llamada, hay una versión de código de operación de ensamblaje de Solidity para delegar llamada. Echemos un vistazo al contrato Delegator para ver cómo podemos usarlo: contract Implementation { event ImplementationLog(uint256 gas); function() public payable { emit ImplementationLog(gasleft()); assert(false); } } contract Delegator { event DelegatorLog(uint256 gas); Implementation public implementation; function Delegator() public { implementation = new Implementation(); } function () public payable { emit DelegatorLog(gasleft()); address _impl = implementation; assembly { let ptr := mload(0x40) calldatacopy(ptr, 0, calldatasize) let result := delegatecall(gas, _impl, ptr, calldatasize, 0, 0) } emit DelegatorLog(gasleft()); } } Esta vez estamos usando ensamblado en línea para ejecutar la llamada delegada. Como habrás notado, aquí no hay un argumento de valor, ya que msg.value no cambiará. Quizás se pregunte por qué cargamos la dirección 0x40 o qué son calldatacopy y calldatasize. No se asuste, los describiremos en la próxima publicación de la serie. Mientras tanto, no dude en ejecutar los mismos comandos en una consola de trufas para validar su comportamiento. Una vez más, es importante comprender claramente cómo funciona una llamada de delegado. Cada llamada desencadenada se enviará desde el contrato actual y no desde el contrato llamado delegado. Además, el código ejecutado puede leer y escribir en el almacenamiento del contrato de la persona que llama. Si no se implementa correctamente, incluso el más pequeño de sus errores puede generar pérdidas millonarias. Aquí hay una lista de los errores más costosos en la historia de Ethereum. HackPedia: 16 Solidity Hacks/Vulnerabilidades, sus correcciones y ejemplos del mundo real Gestión de datos El EVM gestiona diferentes tipos de datos según su contexto, y lo hace de diferentes maneras. Podemos distinguir al menos cuatro tipos principales de datos: pila, calldata, memoria y almacenamiento, además del código de contrato. Analicemos cada uno de estos: Pila La EVM es una máquina de pila, lo que significa que no opera en registros sino en una pila virtual. La pila tiene un tamaño máximo de 1024. Los elementos de la pila tienen un tamaño de 256 bits; de hecho, el EVM es una máquina de palabras de 256 bits (esto facilita el esquema hash Keccak256 y los cálculos de curva elíptica). Aquí es donde la mayoría de los códigos de operación consumen sus parámetros. El EVM proporciona muchos códigos de operación para modificar la pila directamente. Algunos de estos incluyen: POP elimina el elemento de la pila. PUSH_n_ coloca el siguiente elemento de bytes en la pila, con de 1 a 32. n n DUP_n_ duplica el _n_ésimo elemento de la pila, con de 1 a 32. n SWAP_n_ intercambia el primer y el n_ésimo elemento de la pila, con de 1 a 32. n datos de llamada Calldata es un espacio direccionable por bytes de solo lectura donde se guarda el parámetro de datos de una transacción o llamada. A diferencia de la pila, para usar estos datos, debe especificar un desplazamiento de bytes exacto y la cantidad de bytes que desea leer. Los códigos de operación proporcionados por el EVM para operar con los datos de llamada incluyen: CALLDATASIZE indica el tamaño de los datos de la transacción. CALLDATALOAD carga 32 bytes de los datos de la transacción en la pila. CALLDATACOPY copia una cantidad de bytes de los datos de la transacción en la memoria. Solidity también proporciona una versión de ensamblaje en línea de estos códigos de operación. Estos son calldatasize, calldataload y calldatacopy respectivamente. El último espera tres argumentos (t, f, s): copiará s bytes de calldata en la posición f en la memoria en la posición t. Además, Solidity le permite acceder a los datos de llamadas a través de msg.data. Como habrás notado, usamos algunos de estos códigos de operación en algunos ejemplos de la publicación anterior. Echemos un vistazo al bloque de código ensamblador en línea de una llamada de delegado nuevamente: assembly { let ptr := mload(0x40) calldatacopy(ptr, 0, calldatasize) let result := delegatecall(gas, _impl, ptr, calldatasize, 0, 0) } Para delegar la llamada a la dirección _impl, debemos reenviar msg.data. Dado que el código de operación de la llamada del delegado opera con datos en la memoria, primero debemos copiar los datos de la llamada en la memoria. Es por eso que usamos calldatacopy para copiar todos los datos de llamada a un puntero de memoria (tenga en cuenta que estamos usando calldatasize). Analicemos otro ejemplo usando calldata. Encontrará un Calldatacontrat en la carpeta del con el siguiente código: ejercicio 3 contract Calldata { function add(uint256 _a, uint256 _b) public view returns (uint256 result) { assembly { let a := mload(0x40) let b := add(a, 32) calldatacopy(a, 4, 32) calldatacopy(b, add(4, 32), 32) result := add(mload(a), mload(b)) } } } La idea aquí es devolver la suma de dos números pasados por argumentos. Como puede ver, una vez más estamos cargando un puntero de memoria que lee desde 0x40, pero ignórelo por ahora; lo explicaremos justo después de este ejemplo. Estamos almacenando ese puntero de memoria en la variable a y almacenando en b la siguiente posición que es de 32 bytes justo después de a. Luego usamos calldatacopy para almacenar el primer parámetro en a. Es posible que haya notado que lo estamos copiando desde la cuarta posición de los datos de llamada en lugar de su comienzo. Esto se debe a que los primeros 4 bytes de los datos de la llamada contienen la que se llama, en este caso bytes4(keccak256("add(uint256,uint256)")); esto es lo que usa EVM para identificar qué función debe ejecutarse en una llamada. Luego, almacenamos el segundo parámetro en b copiando los siguientes 32 bytes de los datos de la llamada. Finalmente, solo nos falta calcular la suma de ambos valores cargándolos de memoria. firma de la función a la Puede probar esto usted mismo con una consola de truffle ejecutando los siguientes comandos: truffle(develop)> compile truffle(develop)> Calldata.new().then(i => calldata = i) truffle(develop)> calldata.add(1, 6).then(r => r.toString()) // 7 Memoria La memoria es un espacio direccionable de bytes de lectura y escritura volátil. Se utiliza principalmente para almacenar datos durante la ejecución, principalmente para pasar argumentos a funciones internas. Dado que esta es un área volátil, cada llamada de mensaje comienza con una memoria borrada. Todas las ubicaciones se definen inicialmente como cero. Como datos de llamada, la memoria se puede direccionar a nivel de byte, pero solo puede leer palabras de 32 bytes a la vez. Se dice que la memoria se “expande” cuando escribimos una palabra en ella que no se usó previamente. Además del costo de la escritura en sí, hay un costo para esta expansión, que aumenta linealmente durante los primeros 724 bytes y cuadráticamente después de eso. El EVM proporciona tres códigos de operación para interactuar con el área de memoria: MLOAD carga una palabra de la memoria en la pila. MSTORE guarda una palabra en la memoria. MSTORE8 guarda un byte en la memoria. Solidity también proporciona una versión de ensamblaje en línea de estos códigos de operación. Hay otra cosa clave que necesitamos saber sobre la memoria. Solidity siempre almacena un puntero de memoria libre en la posición 0x40, es decir, una referencia a la primera palabra no utilizada en la memoria. Es por eso que cargamos esta palabra para operar con ensamblaje en línea. Dado que los 64 bytes iniciales de memoria están reservados para EVM, así es como podemos asegurarnos de que no estamos sobrescribiendo la memoria que Solidity usa internamente. Por ejemplo, en el ejemplo de llamada de delegado presentado anteriormente, estábamos cargando este puntero para almacenar los datos de llamada dados para reenviarlo. Esto se debe a que la llamada del delegado del código de operación del ensamblado en línea necesita obtener su carga útil de la memoria. Además, si presta atención a la salida del código de bytes del compilador de Solidity, notará que todos comienzan con 0x6060604052..., lo que significa: PUSH1 : EVM opcode is 0x60 0x60 : The free memory pointer PUSH1 : EVM opcode is 0x60 0x40 : Memory position for the free memory pointer MSTORE : EVM opcode is 0x52 Debe tener mucho cuidado al operar con memoria a nivel de ensamblaje. De lo contrario, podría sobrescribir un espacio reservado. Almacenamiento El almacenamiento es un espacio direccionable de palabras persistente de lectura y escritura. Aquí es donde cada contrato almacena su información persistente. A diferencia de la memoria, el almacenamiento es un área persistente y solo puede abordarse con palabras. Es un mapeo clave-valor de 2²⁵⁶ slots de 32 bytes cada uno. Un contrato no puede leer ni escribir en ningún almacenamiento que no sea el suyo propio. Todas las ubicaciones se definen inicialmente como cero. La cantidad de gas requerida para guardar los datos en el almacenamiento es una de las más altas entre las operaciones del EVM. Este costo no es siempre el mismo. Modificar una ranura de almacenamiento de un valor cero a uno distinto de cero cuesta 20.000. Mientras que almacenar el mismo valor distinto de cero o establecer un valor distinto de cero en cero cuesta 5.000. Sin embargo, en el último escenario, cuando un valor distinto de cero se establece en cero, se otorgará un reembolso de 15,000. El EVM proporciona dos códigos de operación para operar el almacenamiento: SLOAD carga una palabra del almacenamiento en la pila. SSTORE guarda una palabra en el almacenamiento. Estos códigos de operación también son compatibles con el ensamblaje en línea de Solidity. Solidity asignará automáticamente cada variable de estado definida de su contrato a un espacio de almacenamiento. La estrategia es bastante simple: las variables de tamaño estático (todo excepto las asignaciones y las matrices dinámicas) se colocan de forma contigua en el almacenamiento a partir de la posición 0. Para arreglos dinámicos, esta ranura (p) almacena la longitud de la matriz y sus datos se ubicarán en el número de ranura que resulta del hash p(keccak256(p)). Para asignaciones, esta ranura no se usa y el valor correspondiente a una clave k se ubicará en keccak256 (k, p). Tenga en cuenta que los parámetros de keccak256 (k y p) siempre se rellenan a 32 bytes. Echemos un vistazo a un ejemplo de código para entender cómo funciona esto. Dentro de la carpeta de contratos del encontrarás un contrato de Almacenamiento con el siguiente código: ejercicio 3 contract Storage { uint256 public number; address public account; uint256[] private array; mapping(uint256 => uint256) private map; function Storage() public { number = 2; account = this; array.push(10); array.push(100); map[1] = 9; map[2] = 10; } } Ahora, abramos una consola de trufas para probar su estructura de almacenamiento. Primero, compilaremos y crearemos una nueva instancia de contrato: truffle(develop)> compile truffle(develop)> Storage.new().then(i => storage = i) Entonces podemos asegurar que la dirección 0 tiene un número 2 y la dirección 1 tiene la dirección del contrato: truffle(develop)> web3.eth.getStorageAt(storage.address, 0) // 0x02 truffle(develop)> web3.eth.getStorageAt(storage.address, 1) // 0x.. Podemos verificar que la posición de almacenamiento 2 contiene la longitud de la matriz de la siguiente manera: truffle(develop)> web3.eth.getStorageAt(storage.address, 2) // 0x02 Finalmente, podemos verificar que la posición de almacenamiento 3 no se usa y los valores de mapeo se almacenan como describimos anteriormente: truffle(develop)> web3.eth.getStorageAt(storage.address, 3) // 0x00 truffle(develop)> mapIndex = '0000000000000000000000000000000000000000000000000000000000000003' truffle(develop)> firstKey = '0000000000000000000000000000000000000000000000000000000000000001' truffle(develop)> firstPosition = web3.sha3(firstKey + mapIndex, { encoding: 'hex' }) truffle(develop)> web3.eth.getStorageAt(storage.address, firstPosition) // 0x09 truffle(develop)> secondKey = '0000000000000000000000000000000000000000000000000000000000000002' truffle(develop)> secondPosition = web3.sha3(secondKey + mapIndex, { encoding: 'hex' }) truffle(develop)> web3.eth.getStorageAt(storage.address, secondPosition) // 0x0A ¡Excelente! ¡Hemos demostrado que la estrategia de almacenamiento de Solidity funciona tal como la entendemos! Para obtener más información sobre cómo Solidity mapea las variables de estado en el almacenamiento, lea la . documentación oficial Eso es todo. Espero que ahora comprenda mucho mejor el papel que juega EVM en la infraestructura de Ethereum. ¹ "La dirección de la nueva cuenta se define como los 160 bits más a la derecha del hash Keccak de la codificación RLP de la estructura que contiene solo el remitente y la cuenta nonce". ( ) Papel amarillo Ethereum ² Uno de los pilares de zeppelin_os es la actualización por contrato. En Zeppelin, hemos estado explorando diferentes estrategias para implementar esto. Puedes leer más sobre esto . aquí ³ Solidity verificará antes de llamar a una función externa que la dirección tenga un código de bytes y, de lo contrario, revertirá. Gracias por leer;) Sobre el Autor es cofundador de Vaibhav Saini TowardsBlockchain , una startup incubada por el MIT Cambridge Innovation Center. Trabaja como desarrollador senior de blockchain y ha trabajado en varias plataformas de blockchain, incluidas Ethereum, Quorum, EOS, Nano, Hashgraph, IOTA, etc. Actualmente es estudiante de segundo año en . IIT Delhi ¿Aprendiste algo? Mantenga presionado el 👏 para decir "¡gracias!" y ayudar a otros a encontrar este artículo. ¡Mantén presionado el botón de aplaudir si te gustó el contenido! Me ayuda a ganar exposición. ¿Querer aprender más? Echa un vistazo a mis artículos anteriores. ConsensusPedia: una enciclopedia de 30 algoritmos de consenso ContractPedia: una enciclopedia de 40 plataformas de contratos inteligentes Diferencia entre SideChains y State Channels EOS 101: Primeros pasos con EOS, Parte 1 Aplaude 50 veces y sígueme en Twitter: @vasa_develop

Profundizando en EVM: cómo funciona Ethereum entre bastidores

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

Nómadas digitales escuchen: lo que necesitan saber sobre la nueva visa DTV de Tailandia

Valhalla de Floki se une como patrocinador asociado de la gira de la India por Sri Lanka

Una breve introducción a la teoría del cerebro de Boltzmann

Creación de productos criptográficos centrados en el usuario: la importancia de los comentarios de los clientes

Nómadas digitales escuchen: lo que necesitan saber sobre la nueva visa DTV de Tailandia

Valhalla de Floki se une como patrocinador asociado de la gira de la India por Sri Lanka

Una breve introducción a la teoría del cerebro de Boltzmann

Creación de productos criptográficos centrados en el usuario: la importancia de los comentarios de los clientes

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps