Esta guía será una pequeña actualización de la antigua Guía NaiProxy a NaiProxy V2, además de como aprender actualizar el contrato una vez llege el momento con Cairo 1.0, es necesario comprender cómo funcionan los contratos actualizables para poder migrar con éxito los contratos existentes a Cairo v1.0. En esta sección, aprenderemos cómo crear contratos actualizables mediante la codificación de un token ERC20 actualizable NAI NaiTokenV1. Empezaremos desde 0, primero haremos el deploy del contrato Proxy.cairo con una implementación de nuestro Token ERC20 NAI, al que luego actualizaremos a la versión NaiTokenV2 con un nuevo método para la quema burn.
En términos simples, un contrato actualizable es aquel que le permite cambiar el código/lógica subyacente de su contrato inteligente, sin alterar necesariamente el punto de entrada (dirección del contrato) de su dApp. Esto se hace separando sus contratos en un Proxy y una implementación. El Proxy sirve como punto de entrada y también contiene el almacenamiento del contrato, mientras que la Implementación contiene el código/lógica de su dApp.
Gracias al equipo de Openzeppelin, ya tenemos una buena plantilla a seguir. Primero, necesitamos copiar el contrato de proxy, en nuestro repositorio. Este contrato de proxy contiene algunas funciones importantes que debemos comprender:
-
El
constructorque toma 4 parámetros:implementation_hash(que es el hash de clase de nuestro contrato de implementación),selectorque es el nombre del selector de nuestra función inicializadora (1295919550572838631247819983596733806859788957403169325509326258146877103642),datacall_len(argumentos del constructor del contrato de implementación) que es la longitud de nuestra llamada ycalldataque son los argumentos del constructor del contrato de implementación. El constructor establece el hash de implementación e inicializa el contrato de implementación. -
La función
__default__que es responsable de redirigir cualquier llamada de función cuyo selector no se encuentre en el contrato del proxy a la implementación. -
La función
__l1_default__que se encarga de redirigir cualquier función realizada a un @l1_handler cuyo selector no se encuentra en el contrato del proxy a la implementación.
Finalmente, creamos nuestros contratos de implementación agregando funciones como upgrade para actualizar el hash de implementación, setAdmin para configurar el administrador de proxy, getImplementationHash para obtener el hash de clase de contrato de implementación y getAdmin para obtener el administrador de proxy actual.
Tenga en cuenta que el contrato de implementación nunca debe:
- Ser desplegado como un contrato regular. En su lugar, se debe declarar el contrato de implementación (lo que crea una clase declarada que contiene su hash y abi).
- Establecer su estado inicial con un constructor tradicional (decorado con @constructor). En su lugar, utilice un método de inicialización que invoque al constructor Proxy.
Para una inmersión más profunda, consulte este artículo de David Baretto aquí
Antes de empezar asegurese de tener instalado Protostar. También tiene una guía antigua aqui
Debemos instalar las librerias de OpenZeppelin usando el comando
gh repo clone OpenZeppelin/cairo-contractsTambién podrá clonar esta repo con todas los ajustes
gh repo clone Nadai2010/Nadai-NaiProxyV2-Starknet-ERC20En esta nueva version de protostar 0.9.0 tendremos que crear un perfil que añadirermos en protostar.toml en el que defineremos el usuario de cuenta que pagará el fee. Usaremos los ajustes PARA TESTNET aunque también estan preparados para TESTNET2. La cuenta de ArgentX para la guía será 0x03F878C94De81906ba1A016aB0E228D361753536681a776ddA29674FfeBB3CB0 (EN SU CASO AÑADIR LA VUESTRA) para el deploy del Proxy.cairo. Tendremos que exportar nuestra PRIVATE KEY de esa cuenta de argent y pasarlo a hexa usando Stark-utils.
Recordar que tenemos OPCIONES A - B para TESTNET o TESNET2 y no usar ni compartir ninguna PRIVATE KEY NUNCA, todo ello es provisional hasta la versión de CAIRO 1.0. Al reiniciar el pc o terminal tendrá que volver a exportar la clave.
Con esta opción pasaremos el hexa convertido de nuestra private key para exportarla, usando el siguiente comando. (SUSITITUIR 0x1234 por vuestro hexa).
export PROTOSTAR_ACCOUNT_PRIVATE_KEY=0x1234Otra opción es este método, añadimos en un archivo .env nuestra private key. También tendremos que ajustar el protostar.toml para indicar la ruta de nuestra Private Key, aunque prefiero esta opción. Nunca mostrar tu clave privada. Nunca subir a Git tu archivo .env.
Si queremos realizar el deploy de nuestro contrato en la testnet 2, debemos seguir los mismos pasos que en la testnet. La única diferencia es que necesitaremos utilizar una wallet que esté en la testnet 2 y agregar un perfil específico al archivo de configuración de Protostar. Además, cuando ejecutemos los comandos de Protostar, debemos utilizar el parámetro -p testnet2 en lugar de -p testnet para que la configuración se aplique a la testnet 2. Con estos pasos, podremos realizar el deploy de nuestro contrato en la testnet 2 de manera efectiva.
Ahora compilaremos los 3 contratos para obtener su Class Hash, de los cuales sòlo haremos el declare para los 3 y el deploy sólo para el Proxy. Añadiremos en el archivo Protostar.toml los contratos que vamos a declarar y ejecutamos el siguiente comando.
protostar build
- Ahora realizamos los mismos pasos para NaiTokenV1 y para NaiToken V2, ejecutando dos veces más el
build, que nos creará los dos archivos.jsonrestante para pasar aldeclare.
Ahora pasaremos hacer los declare pero vamos guardando los Class Hash que quedarán de la siguiente manera:
- Proxy = 0xeafb0413e759430def79539db681f8a4eb98cf4196fe457077d694c6aeeb82
- NaiTokenV1 = 0x459d37251c6f901a470d5e68a9ab6db594f79aaed49553975e132f56d2107b0
- NaiTokenV2 = 0x7df12f46fee13fa7279754d62ae8cf4ffc224db70bb5cd90143659ffe9d7ba7
Revisar que la cuenta esté exportada y vamos a pasar los 3 comandos para el declare de cada uno de los contratos.
-
protostar -p testnet declare ./build/Proxy.json --max-fee auto
-
protostar -p testnet declare ./build/NaiTokenV1.json --max-fee auto
-
protostar -p testnet declare ./build/NaiTokenV2.json --max-fee auto
Como vemos por ahora todos deben de coincidir con los iniciales. Ahora haremos el deploy del Proxy usando protostar, auqnue también podriamos usar el UDC por comodidad. Para ello debemos de pasar al constructor que toma 4 parámetros, la implementation_hash (que es el hash de clase de nuestro contrato de implementación), selector que es el nombre del selector de nuestra función inicializadora (1295919550572838631247819983596733806859788957403169325509326258146877103642), datacall_len (argumentos del constructor del contrato de implementación) que es la longitud de nuestra llamada y calldata que son los argumentos del constructor del contrato de implementación. El constructor establece el hash de implementación e inicializa el contrato de implementación. En nuestro sólo necesitamos ajustar la dirreción de ArgentX para este deploy.
protostar -p testnet deploy 0x00eafb0413e759430def79539db681f8a4eb98cf4196fe457077d694c6aeeb82 --max-fee auto -i 0x0459d37251c6f901a470d5e68a9ab6db594f79aaed49553975e132f56d2107b0 0x2dd76e7ad84dbed81c314ffe5e7a7cacfb8f4836f01af4e913f275f89a3de1a 1 0x03F878C94De81906ba1A016aB0E228D361753536681a776ddA29674FfeBB3CB0
Si todo ha ido bien nuestro contrato de Proxy con nuestro Token NaiV1 ha sido desplegado, revise la siguiente foto y podra comprobar que aún no tenemos los métodos de burn que añadiremos a continuación, iremos al upgrade y vamos a pasar NaiV2 (su Class Hash que antes declaramos)
Y ahora después de que se confirme la transacción de nuestra actualización de NaiTokenV2 podremos ver el método burn activo.
La creación de un contrato inteligente actualizable en StarkNet requiere dos contratos inteligentes, la implementación y el proxy. El proceso de implementación requiere múltiples pasos que, aunque es posible hacerlos todos usando la CLI de StarkNet, se recomienda automatizarlos usando un SDK como starknet.py o starknet.js.
El syscall library_call permite que el Proxy use el código de Implementación mientras usa el almacenamiento del Proxy para cualquier variable involucrada. Esto significa que la Implementación se puede cambiar sin afectar el estado interno del contrato inteligente. En otras palabras, sin cambiar el valor de ninguna de las variables de almacenamiento.
Incluso si no es fanático de los contratos inteligentes actualizables, deberá usar este patrón de diseño para permitir una transición sin problemas de su dapp durante Regenesis. La capacidad de actualización se puede eliminar de forma permanente en cualquier momento, ya sea durante la transición de Cairo 1.0 o configurando la dirección 0 como administrador proxy para que nadie pueda llamar a la función de actualización nunca más.