Nuevo Almacenamiento en Ethereum/RSK (2)

Published on Author lopez

Anterior Post

Habiendo implementado el almacenamiento de una cantidad arbitraria de bytes en una celda de alamacenamiento, ahora podemos guardar valores con longitudes dinámicas, de varias formas. Actualmuente, guardar un texto string en un contrato Ethereum es algo no simple, que involucar guardar el string en varias celdas con direcciones calculadas por hash (ver Layout of State Variables in Storage) (ver How does keccak256 concatenate values inside a Solidity smart contract?).

En cambio, en el almacenamiento de contratos de RSK, podríamos emplear las celdas para guardar valores arbitrarios:

Un simple string se podría guardar en una celda simple de tamaño variable. Esto no está todavía implementado. Estos posts son una propuesta personal para implemetar estas extensiones. Pienso que es posible implementarlas sin grandes cambios internos. Pero hay que revisar el cálculo de costo de almacenamiento, agregar algún opcode adicional y agregar soporte de éstos a los compiladores..

Aún arreglos de longitud o tamaño de elemento fijo o variable podrían ser guardados en una celda simple. La dirección de una celda se describe en 32 bytes. Pero internamente, la estructura que guarda los valores y claves, el Trie, puede tener claves más largas, adicionales. Un ejemplo posible para un arreglo de strings:

En este ejemplo, el tamanio del arreglo se guarda como valor de la celda original, pero hay claves adicionales, que se concatenan a la original, para obtener las distintas posiciones por índice.

Aún un mapa de direcciones de balances podría ser almacenada en esta forma:

Para discutir en los próximos posts: los nuevos opcodes, consideraciones para el cálculo de costo de almacenamiento, nueva salida de un compilador.

Nos leemos!

Angel “Java” Lopez
https://github.com/ajlopez
http://www.ajlopez.com
https://twitter.com/ajlopez