Graduaci贸n

1

Proyectos desarrollados por los estudiantes

Introducci贸n al Ethereum Developer Program

2

驴C贸mo convertirse en blockchain developer?

3

驴Qu茅 es el Ethereum Developer Program?

4

Ethereum Developer Program: Plan de Contenido

5

Ethereum Developer Program: Gu铆a de estudio

Semana 1: Importancia del Manejo de Memoria

6

Importancia del Manejo de Memoria

7

Importancia del Manejo de Memoria: Actividades

8

C贸mo se almacenan los datos en Ethereum

Semana 2: Web3-react

9

Salto de Web2 a Web3: React

10

Salto de Web2 a Web3: Actividades

11

Web3 Stack

12

驴Qu茅 es Web3-React y c贸mo usarlo en tu pr贸ximo proyecto?

Semana 3: Ethereum Virtual Machine y Criptograf铆a

13

Infraestructura y Funcionamiento de la Ethereum Virtual Machine

14

Fundamentos de Criptograf铆a y EVM

15

Criptograf铆a y Funcionamiento de la Ethereum Virtual Machine: Actividades

Semana 4: Creando tu primer Smart Contract

16

Crea tu primer smart contract

17

Crea tu primer smart contract: Actividades

Semana 5: Solidity

18

Aprendiendo Solidity desde cero

Superando la primera etapa del Ethereum Developer Program

19

RETO: NFT din谩micos con datos Off Chain

Semana 6: Tokens y Tokenizaci贸n

20

Tokens y Tokenizaci贸n

Semana 7: Testing Tools y Despliegue

21

Testing Tools y Despliegue: Actividades de la semana

22

Testing Tools y Despliegue

Semana 9: Auditor铆a y Seguridad de Smart Contracts

23

Auditor铆a y Seguridad de Smart Contracts

24

Auditoria y Seguridad de Smart Contracts: Resumen y actividades

Semana 10: Integraciones en Web3: Web3.js vs. Ether.js

25

Integraciones en Web3: Web3.js Vs Ether.js

Semana 11: Monetizaci贸n para Blockchain Developers

26

Monetizaci贸n para Blockchain Developers

Recursos Adicionales

27

Consideraciones de seguridad para smart contracts

28

Memory vs. Storage en Solidity

Memory vs. Storage en Solidity

28/28

Lectura

Solidity tiene 2 palabras reservadas para el almacenamiento de datos: memory y storage. Como desarrollador es importante que conozcas las diferencias entre ellas y cuando debes usar una u otra.

De acuerdo con la documentaci贸n de Solidity, estas dos palabras clave se utilizan para referenciar tipos de datos donde鈥

Los tipos complejos, es decir, los tipos que no siempre caben en 256 bits, deben manejarse con m谩s cuidado que los tipos de valor que ya hemos visto. Dado que copiarlos
puede ser bastante costoso, debemos pensar si queremos que se almacenen en memory -memoria- (que no es persistente) o en storage -almacenamiento-
(donde las variables de estado son preservadas).

Cada tipo complejo, es decir, matrices y estructuras, tiene una anotaci贸n adicional, la 鈥渦bicaci贸n de datos鈥, sobre si se almacena en la memoria o en el almacenamiento.

Ahora es importante ver d贸nde la Ethereum Virtual Machine (EVM) almacena datos:

La m谩quina virtual Ethereum tiene tres 谩reas donde puede almacenar elementos.

El primero es 鈥storage鈥 -almacenamiento-, donde residen todas las variables de estado del contrato. Cada contrato tiene su propio almacenamiento y es persistente entre llamadas de funci贸n y bastante costoso de usar.

El segundo es 鈥memory鈥 -memoria-, se utiliza para almacenar valores temporales. Se borra entre llamadas de funciones (externas) y es m谩s barato de usar.

El tercero es 鈥渟tack鈥, que se utiliza para contener peque帽as variables locales. Es de uso casi gratuito, pero solo puede contener una cantidad limitada de valores.

M谩s importante,

Si, por ejemplo, se pasan tales variables en llamadas a funciones, sus datos no se copian si pueden permanecer en la memoria o en el almacenamiento.

Aqu铆 es donde se vuelve confuso, pero ten presente los siguientes puntos:

  1. Las palabras clave storage y memory se utilizan para hacer referencia a datos en el almacenamiento y la memoria, respectivamente.
  2. El almacenamiento del contrato se asigna previamente durante la construcci贸n del contrato y no se puede crear en la llamada de una funci贸n. Despu茅s de todo, tiene poco sentido crear una nueva variable en el almacenamiento de una funci贸n si se va a conservar.
  3. La memoria no se puede asignar durante la construcci贸n del contrato, sino que se crea en la ejecuci贸n de una funci贸n. La variable de estado del contrato siempre se declara en el almacenamiento. Nuevamente, tiene poco sentido tener una variable de estado que no pueda persistir.
  4. Cuando asignamos una variable con referencia memory a partir de una variable de referencia de storage, estamos copiando datos de la memoria al almacenamiento. No se crea ning煤n nuevo almacenamiento.
  5. Cuando asignamos una variable con referencia storage a partir de una variable con referencia a memory, estamos copiando datos del almacenamiento a la memoria. Se asigna nueva memoria.
  6. Cuando una variable de storage se crea en funci贸n localmente mediante la b煤squeda, simplemente hace referencia a los datos ya asignados en el almacenamiento. No se crea ning煤n nuevo almacenamiento.

Para recapitular, volvamos a la documentaci贸n:

"Ubicaci贸n de datos forzada:

  • par谩metros (no devueltos) de funciones externas: calldata

  • variables de estado: storage

Ubicaci贸n de datos predeterminada:

  • par谩metros (devueltos) de funciones: memory

  • todas las otras variables locales: storage"

Podemos cambiar la ubicaci贸n de los datos solo para par谩metros de funciones y variables locales en funci贸n. Cada vez que una referencia de storage se env铆a a memory, se realiza una copia y la modificaci贸n adicional en el objeto no se propaga de nuevo al estado del contrato. Datos con referencia memory solo se puede 鈥渁signar鈥 a storage si los datos de la memoria se pueden copiar a una variable de estado preasignada.


Veamos algunos ejemplos para ilustrar mejor lo visto anteriormente.

Empecemos viendo el caso de algunos getters.

function getUsingStorage(uint _itemIdx)
public
// definir como non-view para calcular gas
// view
returns (uint)
{
Item storage item = items[_itemIdx];
return item.units;
}

function getUsingMemory(uint _itemIdx)
public
// definir como non-view para calcular gas
// view
returns (uint)
{
Item memory item = items[_itemIdx];
return item.units;
}

Ambas funciones devuelven el mismo resultado, excepto que en getUsingMemory se crea una nueva variable y se usa m谩s gas:

// getUsingStorage
"gasUsed": 21849

// getUsingMemory
"gasUsed": 22149

Por otro lado, para los setters:

function addItemUsingStorage(uint _itemIdx, uint _units)
public
// definir como non-view para calcular gas
// view
{
Item storage item = items[_itemIdx];
item.units += _units;
}

function addItemUsingMemory(uint _itemIdx, uint _units)
public
// definir como non-view para calcular gas
// view
{
Item memory item = items[_itemIdx];
item.units += _units;
}

Solo addItemUsingStorage modifica la variable de estado (consumiendo m谩s gas):

// addItemUsingStorage
// `units` cambia en `items`
"gasUsed": 27053

// addItemUsingMemory
// `units` no cambia en `items`
"gasUsed": 22287

Para concluir, los puntos m谩s importantes son:

  1. memory y storage especifica a qu茅 ubicaci贸n de datos se refiere la variable.
  2. No se puede crear una nueva variable con referencia a storage en una funci贸n. Cualquier variable con referencia a storage en una funci贸n siempre hace referencia a un dato preasignado en el almacenamiento del contrato (variable de estado). Cualquier mutaci贸n persiste despu茅s de la llamada a la funci贸n.
  3. Nuevas variables con referencia a memory solo se pueden crear en una funci贸n. Pueden ser tipos complejos instanciados recientemente como arrays o structs (por ejemplo, a trav茅s de new int[鈥) o copiados desde una variable de storage.
  4. Como las referencias se pasan internamente a trav茅s de los par谩metros de la funci贸n, recuerde que est谩n predeterminadas a memory y, si la variable estuviera en storage, se crear铆a una copia y cualquier modificaci贸n no persistir铆a.

馃挕 Para mayor referencia, visita el texto original 鈥Ethereum Solidity: Memory vs Storage & When to Use Them.

Aportes 2

Preguntas 2

Ordenar por:

驴Quieres ver m谩s aportes, preguntas y respuestas de la comunidad?

Resumen

Almacenamiento de datos v铆a palabras reservadas en Solidity: memory y storage

Item storage item = items[_itemIdx];
Item memory item = items[_itemIdx];

Mediante el uso de estas palabras reservadas en nuestro script le decimos al a EVM la forma en que queremos guardar ciertos datos:

  • temporalmente (memory), se borran con el llamado de la funci贸n. Barato.
  • persistente a las llamadas (storage) y es m谩s costoso. Actualiza estado de las variables del contrato.

Tambi茅n est谩 el stack que guarda peque帽as variables locales. S贸lo puede guardar una cantidad limitada de valores.

Te lo resumo as铆

**Storage variables **se refiere a las variables almacenadas permanentemente en la cadena de bloques. Las variables de estado (variables declaradas fuera de las funciones) se almacenan por defecto y se escriben permanentemente en la cadena de bloques.

Memory variables son temporales y se borran entre llamadas a funciones externas a su contrato. Las variables declaradas dentro de las funciones son de tipo memory y desaparecer谩n cuando finalice la llamada a la funci贸n.

La palabra clave ac谩 es que una permanece en la blockchain (storage) vrs otra que solo mientras corra alg煤n evento/function (memory)