Publicación
Comparte tu conocimiento.
Módulo de control de acceso en movimiento: restricción de la observación de campo en función de la propiedad
Me pregunto si está permitido acceder a los campos de un objeto, como en Solidity, si el propietario del objeto no es el remitente de la transacción. Por ejemplo, considere el siguiente fragmento de código:
public entry fun observe(obj: &CustomStruct, ctx: &mut TxContext) {
// ...
}
En esta función, si el propietario del objeto proporcionado como entrada no es el mismo que el remitente de la transacción, ¿infringe esto alguna regla o restricción de Solidity? ¿Intentar acceder a los campos del obj se consideraría ilegal en este contexto? Gracias por la aclaración.
- Move
- Smart Contract
Respuestas
2Por supuesto, vas por buen camino. En Move, para acceder a los campos de un objeto desde otro módulo de Move es necesario tener muy en cuenta los límites de los módulos. Si tienes un objeto, por ejemplo X, declarado en el módulo A, y quieres acceder a los datos de X en el módulo B, debes definir funciones de acceso dentro del módulo A. Estas funciones actuarán como puentes y permitirán un acceso controlado a los datos de X.
Este control de acceso se basa en los límites del módulo Move, no necesariamente en si el remitente es el propietario del objeto. El enfoque de Move con respecto a la propiedad de los objetos es estricto, y los módulos externos solo pueden acceder a los objetos a través de las funciones predefinidas proporcionadas por el módulo propietario.
Por lo tanto, asegúrese de tener definidas las funciones de acceso adecuadas en el módulo en el que se declara el objeto (en su caso, el módulo A). Estas funciones permitirán el acceso controlado a los campos del objeto desde otros módulos, manteniendo la integridad y la seguridad de tu base de código.
En Solidity, no hay restricciones para leer los campos de un objeto si el propietario del objeto no es el remitente de la transacción. El remitente de la transacción puede leer cualquier variable de estado pública de un contrato. Sin embargo, solo pueden modificar las variables de estado si tienen los permisos adecuados.
CustomStruct
En el fragmento de código que has proporcionado, la función de observación intenta acceder a los campos de un objeto. CustomStruct
Si el CustomStruct
objeto se define como una variable de estado pública en un contrato, cualquier usuario puede llamar a la función de observación y leer los campos del objeto. No es necesario que el remitente de la transacción sea el propietario del CustomStruct
objeto.
Este es un ejemplo de cómo puedes definir un CustomStruct
objeto y una función de observación en Solidity:
pragma solidity ^0.8.4;
contract MyContract {
struct CustomStruct {
uint data;
}
CustomStruct public obj;
function observe() public view returns (uint) {
return obj.data;
}
}
En este ejemplo, la función observe devuelve el campo de datos del objeto obj. Cualquier usuario puede llamar a la función observar y leer el campo de datos del objeto obj, independientemente de quién sea el propietario del objeto obj.
Sin embargo, si el CustomStruct
objeto no está definido como una variable de estado pública, el remitente de la transacción no puede acceder a sus campos. En ese caso, tendrás que incluir una función pública en el contrato que devuelva los campos del CustomStruct
objeto.
Tenga en cuenta que, si bien el remitente de la transacción puede leer cualquier variable de estado pública de un contrato, solo puede modificar las variables de estado si tiene los permisos adecuados. Por ejemplo, puedes usar el onlyOwner
modificador para restringir la modificación de las variables de estado al propietario del contrato fravoll.github.io.
Sabes la respuesta?
Inicie sesión y compártalo.