Los diferentes tipos de visibilidades que puedes declarar en un contrato inteligente pueden tener diversas vulnerabilidades. Estas no necesariamente pueden ser un problema, pero debes conocerlas para evitar ataques.
Tipos de visibilidad en Solidity y variables privadas
Solidity es un lenguaje de programación orientado a objetos y como tal, permite configurar la visibilidad de los atributos y métodos de todo el contrato. Podemos declarar atributos y funciones públicas, privadas, internas y externas.
Public: variables y métodos totalmente accesibles.
Private: accesible únicamente a través de una función dentro del contrato.
Internal: métodos accesibles solo a través de una función incluida en el mismo contrato. No podrán ser accedidas desde llamadas externas de otros contratos.
External: caso contrario a internal, son métodos a los cuales puedes acceder desde otro contrato, pero no desde el mismo.
De alguna forma u otra, todo en Blockchain es accesible. No existe posibilidad de bloquear por completo un dato y ocultarlo.
La visibilidad por defecto de una variable es internal mientras que la visibilidad de las funciones es public. Si declaras variables del tipo public, al compilar el contrato inteligente se crearán métodos del tipo view para obtener sus valores.
Problemas con la visibilidad con las variables privadas
Si decidimos declarar variables privadas, tienes que saber que es posible el acceso a estos datos de todos modos.
Las variables privadas de un contrato pueden ser accedidas a través de su índice en memoria con ayuda de librerías como Truffle que permiten acceder a los datos privados de un contrato inteligente con métodos como web3.eth.getStorageAt("<contract_address>", index). El mismo devolverá el valor de la variable codificado en Base64, muy fácilmente decodificable para obtener su verdadero valor.
En síntesis, utiliza los diferentes tipos de visibilidad que Solidity tiene para ofrecer dependiendo la regla de negocio, pero sabiendo que todos los datos son visibles de alguna u otra manera. No guardes contraseñas o secretos en variables privadas, no han sido implementados para eso.
Entiendo que la información que se recupera siempre estará asociada a los datos procesados durante la última ejecución del contrato o es posible indicar más parámetros en el script y recuperar el valor de esas variables en una fecha determinada?
Hola Aldana, es correcto hay un parámetro que le indica al script qué bloque estás viendo. Por defecto es el último bloque pero puedes ver el estado en un bloque anterior. Eso sí, no sería por fecha si no por número de bloque
la recomendación cual seria a la hora de necesitar una variable critica? utilizar una variable de entorno para llamar el dato critico? o cual seria la mejor practica para llamar estos datos criticos?
Hola Juan Manuel, yo creo que lo mejor en ese caso es no almacenar datos críticos en los contratos. Los contratos deberían funcionar para validar reglas y asegurar que se cumplan. Por ejemplo, es necesario guardar documentación de un usuario ? Lo mejor es manejar a los usuarios como direcciones, y luego en caso de necesitarse, puede existir un registro externo que relacione usuarios con direcciones. De hecho, así funcionan la mayoría de exchanges en la actualidad.
Podria ser una opcion, sin embargo creo que seria mejor preguntarse si vale la pena guardar información crítica en un contrato. No digo que no pueda suceder, pero muchas veces es mejor directamente no almacenar esos datos en el contrato