No tienes acceso a esta clase

¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera

¿Cómo construir un compilador a la EVM?

17/32
Recursos

Aportes 2

Preguntas 0

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad?

Una nota importante aquí es que incorrectamente me referí a la memoria en todo momento cuando quise decir storage para la mayoría de los casos.

En solidity, un struct puede viajar en calldata a través de parámetros o en memory, pero generalmente esto sólo es importante cuando se guarda en storage.

Menos slots == Menos storage costs

El storage cost es el más alto en la EVM.

2 cosas que creo que faltaron mencionar es por ejemplo el caso de los “short arrays” vs “long arrays”. Para el caso de los strings y los bytes menores a 31 bytes (short arrays) la indexación es directa también en un mismo slot y no es a través de punteros y el byte menos significativo tendrá la longitud * 2, al pasarnos ya no será directo y tendremos el slot principal la longitud * 2 +1 (El objetivo de que se multiplique por 2 la longitudes es para que sin importar el valor que sea el primer bit sea 0 para el caso corto y 1 para el caso largo y así poderlos identificar fácilmente), la información luego estará guardada en el keccak256 de esa posición principal continuando de forma contigua para el largo. En caso de que usaramos byte1[] es diferente, el valor estará alineado incurriendo en un desperdicio de 255 bytes por cada elemento,por lo cual no es aconsejable. La otra cuestión es que si bien al crear información bien acomodadas en los slots para lograr un menor numero de ellos ahorrando espacios y recursos, en ciertas ocasiones eso puede generar un mayor computo en operaciones que podrían tener que enmascarar esos valores para tratarlos. Por eso también es que el compilador no sabe de por sí que le conviene a nuestra aplicación y está en nuestras manos acomodarlo de la mejor forma posible.