Cómo configurar el control de acceso para contratos inteligentes

Cuando uno busca distinguir entre Web2 y Web3, un valor clave que diferencia a los dos es el concepto de propiedad.

En pocas palabras, lo que creas es lo que posees y puedes monetizar. Tal como debería ser. Nada menos, nada más. De hecho, el día que acuña su primer NFT es cuando lo ha hecho en Web3 como propietario, gracias a la inmutabilidad de la cadena de bloques. En todo caso, la sensación de estar protegido no tiene precio.

Hablando de eso, este concepto de propiedad es tan importante para los contratos inteligentes con respecto a las funciones accesibles y el cambio de estado permitido.

Su primer vistazo a la propiedad con contratos inteligentes

Entonces, ¿por qué importa que seas "dueño" del contrato inteligente que has escrito?

Piénselo: si tuviera una bicicleta, ¿dudaría en llevar registros de propiedad? ¿En caso de que alguien lo robara y lo usara con fines nefastos? Por supuesto que no.

Es por la misma razón por la que querría probar su propiedad de un NFT o un contrato inteligente. Bueno, alguien podría obtener acceso no autorizado y beneficiarse económicamente de ello, ¿verdad?

Supongamos que trabaja con Dunzo y ha escrito este contrato inteligente en el que puede establecer el precio del paquete más los gastos de envío junto con si el comprador lo pagó o no.

En el escenario ideal, puede establecer el nombre del comprador, el precio total del paquete y la entrega en una cantidad determinada y establecer setPackageDelivered en verdadero. Una vez que haya terminado de entregar el paquete, por supuesto.

Pero, como todos sabemos, nada sale según lo planeado.

Ahora, ¿qué pasaría si el comprador tuviera acceso a las funciones del contrato y la capacidad de restablecer el valor de packageDelivered a falso o cambiar el valor de packageDeliveryPrice a uno menor? No solo pueden pagar menos por el producto, sino que pueden salirse con la suya sin pagar nada en absoluto.

Claramente, aparte de Dunzo, nadie más debería tener acceso para realizar dichos cambios, y por eso es importante configurar el control de acceso.

Por qué es importante establecer el control de acceso correcto en un contrato inteligente

Ahora, implementemos este contrato inteligente y veamos cuán fácil es para un intruso alterar los valores en las variables de estado.

Con las funciones setPrice y setPackageDelivered accesibles, cualquiera puede realizar cambios que pueden resultar en pérdidas financieras para la entrega de Dunzo.

Si Dunzo había fijado el precio original del artículo en 5 ETH, el cliente ahora puede cambiar ese valor a 3 ETH. Por supuesto, dado que el cliente también puede acceder a la función setPackageDelivered y cambiar el valor booleano a falso, es posible que reciba otra entrega del mismo artículo. Entonces, en cualquier caso, Dunzo puede perder dinero y es posible que ni siquiera se dé cuenta hasta que sea demasiado tarde.

Por ejemplo, supongamos que el producto que se entrega vale 5 ETH, como se muestra a continuación:

Tras el despliegue, nadie más que Dunzo debería poder modificar los términos del contrato. Aún así, cuando cambiamos las direcciones en Remix y restablecemos el precio a 3, esto es posible debido a que no existe protección.

Incluso podemos cambiar el estado setPackageDelivered de verdadero a falso. Incluso si el paquete ya ha sido entregado al cliente.

Como puede ver, es importante distinguir entre el propietario y otros usuarios para dicho contrato inteligente. Entonces, veamos 4 correcciones que establecerán el control de acceso adecuado para este contrato inteligente y, como resultado, garantizarán su seguridad.

4 formas de configurar controles de acceso de forma segura para su contrato inteligente

Entonces, ¿cómo se puede diferenciar entre el propietario y otros usuarios al escribir contratos inteligentes?

Claramente, esto es necesario debido a la pérdida financiera en la que se puede incurrir si se ignora.

Método n.º 1: utilice una instrucción require

Como puede ver en el código a continuación, se agregó un nuevo propietario de variable de estado del tipo de dirección junto con una declaración 'requerir'. En el constructor, la variable de estado del propietario almacena la dirección que se usa al implementar el contrato. Como sabe, los constructores en los contratos inteligentes se invocan solo una vez, por lo que la dirección no se puede cambiar.

Ahora, cuando invoca la función setPrice con un valor menor y una dirección diferente, la transacción se revierte al estado inicial, como el mensaje a continuación:

Como puede ver, el motivo proporcionado por el contrato implica el mensaje de error que agregamos a la declaración 'requerir'. Dicho esto, nadie más que el propietario del contrato, Dunzo, en este caso, puede cambiar los términos de venta.

Método #2: Usa un modificador de función

Tan simple como agregar una declaración 'requerir' con la condición correcta, un modificador es un bloque de código que puede usar repetidamente. Esto sin duda tiene mucho más sentido que escribir numerosas declaraciones 'requeridas' para tal verificación.

En el código compartido anteriormente, solo la función setPrice está protegida por una instrucción 'requerir', pero aquí no se ha hecho nada para la función setPackageDelivered. El uso de un modificador debería funcionar, como se muestra en el código de Solidity a continuación:

Ahora, si intenta acceder a las funciones setPrice o setPackageDelivered, obtendrá el mismo mensaje de error obtenido anteriormente, y como se muestra a continuación:

Método n.º 3: propiedad

Esta solución requiere que use el contrato inteligente Ownable proporcionado por OpenZeppelin. Primero, debe importar el contrato inteligente Ownable y luego agregar el modificador onlyOwner a las funciones que le gustaría proteger. Entonces, como se muestra a continuación, las funciones setPrice y setPackageDelivered tienen el modificador onlyOwner a continuación.

Ahora, dado que el contrato inteligente dunzoDelivery utilizará algunas de las funciones de Ownable.sol, también se agrega "is Ownable" al nombre del contrato.

Dicho esto, hay otras dos funciones a las que se puede acceder cuando se utiliza el contrato inteligente Ownable: renunciar a la propiedad y transferir la propiedad. Si bien la cuenta que se usó para implementar el contrato generalmente se considera el propietario, esto se puede cambiar usando estas funciones.

Además de ver la dirección del propietario y los demás detalles del acuerdo, puede ver las funciones de renuncia de propiedad y transferencia de propiedad para su uso a continuación:

Como era de esperar, cuando intenta invocar la función setPrice usando otra dirección, la transacción no se realizará. En cambio, vuelve al estado original, con el motivo que se proporciona a continuación:

El uso del contrato inteligente Ownable es bueno si necesita un solo propietario entre otros usuarios. Si está buscando más jerarquía, debe usar el contrato inteligente AccessControl.sol.

Método #4: Control de acceso

Esta última solución requiere que acceda al contrato inteligente AccessControl de Open Zeppelin.

Para empezar, debe agregar el hipervínculo de Control de acceso a la declaración de importación, así como agregar "es AccessControl" a la declaración del contrato.

Como se mencionó anteriormente, este contrato inteligente le permite agregar una serie de roles dentro de una jerarquía y que debe declarar, como en las dos primeras líneas del contrato inteligente que se muestra a continuación:

En este contrato, hay dos roles, a saber, Dunzo y Cliente. Ahora, cuando implemente el contrato, deberá asignar los roles declarados antes mencionados a dichas direcciones, para determinar quién puede acceder a qué. Además, se agregaron dos declaraciones 'requerir' a las funciones setPrice y setPackageDelivered.

Como puede ver, solo la cuenta a la que se le ha asignado el rol de Dunzo podrá modificar los términos de venta mencionados durante el tiempo de implementación, pero ninguna otra. Dicho esto, puede asignar una serie de roles con diferentes niveles de acceso a las funciones de un contrato inteligente utilizando AccessControl.sol, mientras que Ownable.sol no profundizará tanto.

Una nota sobre otras correcciones de control de acceso para contratos inteligentes de Ethereum

Ahora bien, estas no son las únicas soluciones disponibles para implementar el control de acceso en los contratos inteligentes. RBAC.sol y WhitelistCrowdSale.sol también han estado disponibles en el pasado y también pueden asociar roles con direcciones, al igual que AccessControl.sol y Ownable.sol.

Por lo tanto, si desea obtener una comprensión profunda de la evolución de la implementación del control de acceso, valdrá la pena revisar el código en estos dos contratos inteligentes también.

También publicado aquí.

La imagen principal de este artículo fue generada porAI Image Generator de HackerNoon a través del mensaje "escaneo biométrico de acceso denegado".