- Starknet Doc - Documentos oficiales de Starknet
- Starknet Book - Libro de Starknet
- Cairo Doc - Documentos oficiales de de Cairo
- Libro Cairo - Libro de Cairo
- Libro L2 en Español - Libro escrito por el equipo de L2 en Español sobre el ecosistema de Starknet, Criptografía Básica y temas más profundos de la arquitectura y en general de Starknet.
- Sintaxis Cairo by Nethermind | Sintaxis Cairo by LambdaClass | Starklings | CairoPractice - Colecciones de ejemplos y tutoriales interactivos de aprendizaje en Cairo.
- Stark Utils - Herramienta para convertir tus valores de Cairo, convierte
felt
,hex
,string
,selector
... - Diapositivas Clase 1 - Introducción a Layers 2 | Diapositivas Clase 2 - Profundizando en Starknet | Diapositivas Clase 3 - Primeros Pasos en el Desarrollo | Diapositivas Clase 4 - Profundizando en AA nativo en Starknet
- Pre-requisitos
- Git
- Curl
- Clonado Repositorio
- Instalación de Starkli
- Instalación de Scarb
- Instalación de Dojo y Katana
- Conseguir Faucet
- Crear Contrato de Cuenta y Firmantes
- Creación de Firmantes con Starkli
- Integrando Scarb en tu Flujo de Desarrollo
- Katana
- Workshop de Mensajes L2<->L1 📨
- Gestión de Dependencias Externas en Scarb
- Comandos Starkli
- RPC
- MIN Deploy💥
Antes de empezar, asegúrese de tener instalados los siguientes pre-requisitos en su sistema:
Git: Será necesario tener Git
instalado. A continuación, se muestra el comando para instalar Git
en Ubuntu. Recuerda verificar las versiones disponibles para tu sistema operativo en el enlace proporcionado:
apt-get install git
Si se produce un error y te solicita entrar como administrador, agrega sudo
al principio del comando. Se abrirá una ventana para ingresar tu contraseña (que será invisible) y luego puedes presionar Enter para continuar.
sudo apt-get install git
El procedimiento para instalar cURL
en Ubuntu Linux es el siguiente:
- Actualiza tu sistema Ubuntu ejecutando:
sudo apt update && sudo apt upgrade
- A continuación, instala cURL ejecutando:
sudo apt install curl
- Verifica la instalación de cURL en Ubuntu ejecutando:
curl --version
Ahora podrá proceder a hacer un clone
de nuestro repositorio para obtener toda la configuración y contratos preparados para compilar y deplegar, para ello deberá pasar el comando:
git clone git@github.com:Layer2es/Workshop-Mensajes-Ethereum-Starknet.git
Starkli es una interfaz de línea de comandos que te permite interactuar con Starknet. Esta es una de las herramientas que nos permite interactuar con Starknet, sin embargo, no es la única. Starkliup es el instalador del entorno Starkli, y se puede instalar fácilmente utilizando la línea de comando con curl:
curl https://get.starkli.sh | sh
Puede que necesites reiniciar tu sesión de shell para que el comando starkliup esté disponible. Una vez que esté disponible, ejecuta el comando starkliup:
starkliup
Starkliup detecta la plataforma de tu dispositivo y descarga automáticamente el binario precompilado adecuado. También configura las autocompletaciones de la shell. Es posible que necesites reiniciar tu sesión de shell para que las autocompletaciones comiencen a funcionar.
Ejecutar estos comandos instalará starkli para ti y lo actualizará a la última versión si ya está instalado.
Reinicie el terminal y ejecute el siguiente comando para verificar la instalación:
starkli --version
Para actualizar a la última versión de Starkli, simplemente siga los pasos anteriores nuevamente.
Scarb es el administrador de paquetes para Cairo. Entre otras cosas, nos permite compilar código Cairo a Sierra, el lenguaje intermedio entre el Cairo de alto nivel y el ensamblador Cairo de bajo nivel (CASM). Para usuarios de macOS y Linux, abra su terminal y ejecute el siguiente comando:
curl --proto '=https' --tlsv1.2 -sSf https://docs.swmansion.com/scarb/install.sh | sh
Reinicie el terminal y ejecute el siguiente comando para verificar la instalación:
scarb --version
Puede ejecutar el mismo comando para actualizarlo o directamente añadir la versión manual de la versión que necesite de aquí
curl --proto '=https' --tlsv1.2 -sSf https://docs.swmansion.com/scarb/install.sh | sh -s -- -v 2.4.0-rc6
Ejecute el siguiente comando para verificar su nueva versión, está vez la 2.4.0-rc6
:
scarb --version
Si bien se proporciona esta información para aquellos que deseen instalar una versión específica, se recomienda encarecidamente la instalación de la versión estable utilizando el primer comando o siempre verificar las compatibilidades de las versiones del compilador aquí.
Para aprovechar al máximo esta potente combinación de herramientas para Starknet y Cairo, ahora puede confirmar si tanto Scarb
como Starkli
están instalados y listos. Hemos configurado estas versiones como las más estables y actualizadas para esta guía:
scarb --version
starkli --version
Katana, creada por el equipo de Dojo, está diseñada para facilitar el desarrollo local. Esta herramienta permite realizar todas las actividades relacionadas con Starknet en un entorno local, lo que la convierte en una plataforma eficiente para el desarrollo y las pruebas.
Para instalar este entorno local, necesitaremos instalar Dojo con el siguiente comando:
curl -L https://install.dojoengine.org | bash
dojoup
Una vez instalado katana
, podemos verificar su versión con el siguiente comando:
katana --version
Con katana
, tenemos la opción de levantar este nodo local para interactuar con él. Aunque katana
por sí solo debería ser suficiente, recomendamos ejecutarlo con la opción --disable-fee
para evitar problemas de costes de gas por transacción. En este ejemplo, configuramos katana
para lanzar solo 3 cuentas
en lugar de las 10 cuentas
predeterminadas:
katana --disable-fee --accounts 3
Si todo ha funcionado correctamente, Katana
debería estar activo y listo para ser configurado con diversas opciones. Se integra perfectamente con el flujo de trabajo de otras herramientas como starkli.
Aquí hay varios enlaces y métodos que le proporcionaremos para que pueda desplegar su contrato de cuenta. En este caso, utilizaremos la red de prueba de Goerli
en Starknet, aunque a finales del 2023 será deprecada y se recomienda empezar a usar Sepolia
siguiendo el mismo proceso, en estas redes de prueba podrá recibir fondos ETH de varias maneras:
-
Desde un Faucet de Starknet: Puede obtener fondos ETH de forma gratuita en la red Goerli de Starknet utilizando el Faucet Starknet.
-
A través de Starkgate Bridge L1-L2: También puede transferir fondos desde la capa 1 (L1) de Ethereum en Goerli a la capa 2 (L2) de Starknet utilizando el Starkgate Bridge L1-L2.
-
Depositando ETH desde otra dirección: Tienes la opción de depositar ETH en su contrato de cuenta desde otra dirección de prueba de Starknet o cualquier otra billetera compatible con la red de prueba.
Las billeteras inteligentes en Starknet se componen de dos elementos: un firmante
y un descriptor de cuenta
. Estos elementos son esenciales para interactuar con Starknet, permitiendo firmar transacciones y proporcionando información relevante sobre la billetera inteligente.
- El
firmante
es un contrato inteligente capaz de firmar transacciones, cuya clave privada es necesaria para su creación. - El
descriptor de cuenta
es un archivo JSON que contiene información crítica sobre la billetera inteligente, como su dirección y clave pública.
Usaremos 2 opciones para crear nuestra cuenta:
-
Opción A: Configuraremos nuestro entorno de desarrollo utilizando las lógicas de OZ (OpenZeppelin) y Starknet para crear un nuevo Contrato de Cuenta.
-
Opción B: Crearemos la cuenta a través de Argent o Braavos, exportando nuestra clave privada.
Starkli emplea firmantes
o signers
para autorizar transacciones. Estos pueden ser contratos inteligentes o archivos que almacenan claves privadas. Aquí se presenta cómo crear un firmante utilizando Starkli:
-
Crear un Firmante: Utilice Starkli para generar un archivo
keystore
que proteja la clave privada de su billetera inteligente. Para ello, crearemos una carpetastarkli-wallets/deployer
que podrá encontrar oculta en sus archivos. EnLinux
, puede mostrar archivos ocultos presionandoCtrl + h
. En este paso se le pedirá una contraseña que podrá añadir o dejar vacía. Por seguridad, la contraseña permanece oculta, por lo que no verá en su pantalla su contraseña, pero estará escribiéndola.mkdir -p ~/.starkli-wallets/deployer starkli signer keystore new ~/.starkli-wallets/deployer/Signer_WorkshopL2.json
Esto generará un archivo cifrado llamado
Signer_WorkshopL2.json
(Modifique el nombre del Signer que usted quiera) y lo guardará en la ruta especificada~/.starkli-wallets/deployer
, además de suPublic Key
. -
Establecer Variable de Entorno: Cree una variable de entorno
STARKNET_KEYSTORE
para facilitar la gestión de claves, y ejecútelo en su misma terminal, además deberemos exportar nuestro RPC que tendrá diversas opciones, recomendamos crearse el suyo con su propiaAPI KEY
y no depender de públicos, ahora usaremos unoOpen de Blast
para este workshop:export STARKNET_KEYSTORE=~/.starkli-wallets/deployer/Signer_WorkshopL2.json export STARKNET_RPC="https://starknet-testnet.public.blastapi.io"
-
Crear Descriptor de Cuenta: Crea la cuenta que estará controlada por el
signer
que se ha creado:starkli account oz init ~/.starkli-wallets/deployer/Account_WorkshopL2.json
Este archivo
Account_WorkshopL2.json
estará en estadoundeployed
, listo para ser desplegado después de recibir saldo. -
Fondear Cuenta: Nuestro Contrato de Cuenta necesita fondos para cobrar vida, en este caso usaremos el Faucet, puede revisar las otras pociones aquí
-
Desplegar Cuenta: Ahora todo está listo para desplegar nuestro Contrato de Cuenta del Estándar de OZ ejecutando el comando
starkli account deploy
con la ruta donde añadimos nuestra Cuenta.starkli account deploy /home/nadai/.starkli-wallets/deployer/Account_WorkshopL2.json
Primeramente, se le preguntará si tiene fondos. Una vez confirmado, presione Enter y su cuenta debería ser desplegada.
Ahora podrá revisar su descriptor de cuenta como ha pasado de
undeployed
adeployed
. Ya tiene todo listo para empezar a crear sus primeros contratos en Starknet.
-
Crear Billetera Inteligente: Siga las instrucciones proporcionadas por las extensiones del navegador Braavos o Argent X para crear una billetera inteligente.
-
Exportar Clave Privada: Exporte la clave privada desde la configuración de su cuenta en Braavos o Argent X, en este Workshop hemos usado Braavos.
- Para Argent X: Puede encontrarla en la sección "Configuración" → Seleccione su cuenta → "Exportar clave privada".
- Para Braavos: Puede encontrarla en la sección "Configuración" → "Privacidad y seguridad" → "Exportar clave privada".
-
Cree un firmante: Con Starkli y utilizando la clave privada que tendrá que añadir, más un password si quiere añadir una contraseña para su seguridad, esto configurará su Contrato de Cuenta desde Argent o Braavos, para ello creemos el
signer
con el siguiente comando:starkli signer keystore from-key ~/.starkli-wallets/deployer/Signer_Braavos.json
Con esta parte, habremos configurado nuestro firmante, y a continuación, definiremos cómo utilizaremos nuestro Contrato de Cuenta creando un Descriptor de Cuenta con la información necesaria.
-
Crear Descriptor de Cuenta: Crea la cuenta que estará controlada por el
signer
que se ha creado, pero primero deberemos exportar un punto de RPC para que pueda conseguir los datos de nuestro contrato de cuenta para crear el Descriptor usando el siguiente comando:export STARKNET_RPC="https://starknet-testnet.public.blastapi.io"
Ahora podremos pasar el comando con la dirección de nuestra cuenta de Braavos o Argent para crear nuestro Descriptor de Cuenta:
starkli account fetch 0x027f68d0d0f474b1a25f359a42dc49a3003a3522d71765a5e7658e68520d7826 --output ~/.starkli-wallets/deployer/Account_Braavos.json
Esto nos dará nuestro archivo
.json
con toda la información relevante para poder usar nuestra cuenta recien exportada.
Con estas 2 opciones conseguimos tener nuestra cuenta exportada e integrada en nuestro flujo de trabajo para desarrollar con ellas.
Acceda directamente aquí si quiere ir directamente a diversas formas de trabajar con las variables de entorno de la forma que vea más útil.
Estos pasos te guiarán a través de un flujo de trabajo típico para desarrollar un contrato Starknet utilizando Scarb. Si has clonado este repositorio y quieres seguir solo los procesos, puedes ir directamente al paso 5.
-
Inicialización del Proyecto: Comienza ejecutando
scarb new workshop
para crear un nuevo proyecto con el nombre "workshop". Este comando generará automáticamente la estructura básica del proyecto, incluyendo un archivo de configuraciónScarb.toml
y un archivo inicialsrc/lib.cairo
. -
Desarrollo del Contrato: Escribe tu código Cairo y guárdalo en el directorio
src
. En este caso, utilizaremos como base varios contratos:Hola.cairo
,Owner.cairo
y el contratoWorkshopMensajesL2.cairo
. -
Optimización de Módulos: Utilizaremos el archivo
lib.cairo
para añadir los módulosmod Hola
,mod Owner
ymod WorkshopMensajesL2
, que indicarán qué contratos de Cairo se utilizarán. -
Gestión de Dependencias: Si tu contrato depende de bibliotecas externas, usa
scarb add
para incluir fácilmente estas dependencias en tu proyecto, incluso de una versión específica. Además, puedes utilizarscarb rm
para eliminarlas. Por ejemplo:scarb add alexandria_math --git https://github.com/keep-starknet-strange/alexandria.git --rev 27fbf5b
Eliminar:
scarb rm alexandria_math
-
Compilación del Contrato: Ejecuta
scarb build
para compilar tu contrato en código Sierra. Este código resultante puede ser examinado con más detalle o utilizado como entrada para otras herramientas o procesos.
Integrar Scarb en tu flujo de trabajo te permite aprovechar sus características para hacer tu proceso de desarrollo más eficiente y manejable.
Una vez hayas copiado los pasos anteriores de este taller, deberás guardar todos los cambios en tu editor de código y proceder a modificar tu archivo Scarb.toml
. En la sección [dependencies]
, podrás añadir dependencias externas como por ejemplo las de OpenZeppelin u otras que necesites. Además, asegúrate de que en la sección [[target.starknet-contract]]
de tu archivo Scarb.toml
especifiques sierra = true
para que la compilación genere el código en la representación intermedia de Sierra en formato .json
.
Es importante señalar que si no indicas sierra = true
en la sección correspondiente, la compilación generará el código en formato casm
, que es una versión cruda de Cairo. Dado que necesitamos la representación intermedia de Sierra para que el contrato sea más legible y tenga propiedades de seguridad, es esencial habilitar esta opción.
Tu archivo Scarb.toml
utilizado para este Workshop será:
[package]
name = "workshop_l2"
version = "1.0.0"
cairo-version = "2.3.1"
authors = ["L2 Español, SEED Latam, StarknetEs - Starknet"]
description = "Workshop de 0 a Heroe. Envio de mensajes entre Ethereum <-> Starknet"
[dependencies]
starknet = ">=2.3.1"
[[target.starknet-contract]]
sierra = true
Para trabajar con la sintaxis de Cairo de manera efectiva y detectar automáticamente la versión del compilador, así como facilitar la corrección de errores, es altamente recomendable utilizar la extensión Cairo 1
en VS Code. Siga estos pasos para configurarla:
-
Abra Visual Studio Code.
-
Diríjase a la sección de extensiones. Puede hacerlo haciendo clic en el ícono de
Extensiones
en la barra lateral izquierda o presionandoCtrl + Shift + X
. -
En la barra de búsqueda de extensiones, escriba
Cairo 1
. -
Aparecerá la extensión
Cairo 1
. Haga clic enInstalar
para descargarla e instalarla en su entorno de VS Code. -
Una vez que la extensión esté instalada, podrá detectar automáticamente la versión del compilador Cairo a partir del archivo de manifiesto de su proyecto
Scarb
. Asegúrese de tenerScarb
instalado correctamente. También puede configurar su activación desde los ajustes revisando el estado activo de las casillasCairo1: Enable Scarb
, o en caso de que siga teniendo problemas después de reiniciar, añadir las rutas del paquete binario de Scarb enCairo1: Scarb Path
.
Esto facilita la corrección de errores y asegura que su código se ajuste a la versión específica del compilador.
Con la extensión Cairo 1
configurada en su entorno de Visual Studio Code, estará listo para trabajar de manera eficiente con la sintaxis de Cairo y aprovechará las funciones de detección de errores y corrección automática proporcionadas por la extensión. Esto es especialmente útil para desarrollar aplicaciones en Cairo de manera más efectiva y sin problemas.
Ahora procederemos a compilar nuestros contratos definidos en lib.cairo
, en este caso recordamos que será un Hola.cairo
, el Owner.cairo
y el WorkshopMensajesL2.cairo
. Si ha clonado este repositorio (recuerde que puede hacerlo con el comando git clone git@github.com:Layer2es/Workshop-Mensajes-Ethereum-Starknet.git
), tendremos que entrar en la carpeta de Workshop-Mensajes-Ethereum-Starknet/l2
en la que se encontrarán los contratos de Cairo y le bastará con ejecutar un comando para llevar a cabo la compilación:
scarb build
Si todo ha ido bien, se debería crear una carpeta dev/target
que contendrá los archivos workshop_l2_hola.contract_class.json
, workshop_l2_Ownable.contract_class.json
y workshop_l2_WorkshopMensajesL2.contract_class.json
más un archivo con los artifacts
. Aunque nos centraremos en Hola.cairo
, podría realizar la misma acción para el resto, estos archivos en versión Sierra con terminación en .json
, son los que necesitaremos para llevar a cabo las operaciones de Declare
y Deploy
Si, por cualquier motivo, no se genera este archivo, puede intentar borrar la carpeta target
y luego volver a ejecutar el comando scarb build
.
Una vez tengamos todo preparado realizaremos la declaración del Hola.cairo
, está declaración nos servirá para establecer una estrucutra que nos sirva para usar en el futuro y si queremos volver a usar este contrato, solo usar su mismo Class Hash
que nos ha dado, y pasar los argumentos del construcutor que queremos, asi podrimaos tener un Class hash
por ejemplo de un ERC-20
standard o con ciertas propiedades, pero cada uno con su owner, nombre, simbolo, total supply o diferentes lógicas que sean programadas.
Siempre es importante verificar que los EXPORT
se hayan realizado correctamente para interactuar con la red de Starknet, podemos definir 3 maneras útiles para manejar nuestras variables de entorno necesarias.
- Manual:
Deberemos definir cada vez que habramos la terminal el keystore
o firmante que tengamos añadido, el account
o contrato de cuenta que vamos a utilizar y el rpc
que podremos definir uno propio y manejar los diferentes puntos de conexión a las redes mainnet
, goerli
, o sepolia
.
export STARKNET_KEYSTORE=~/.starkli-wallets/deployer/Signer_WorkshopL2.json
export STARKNET_ACCOUNT=~/.starkli-wallets/deployer/Account_WorkshopL2.json
export STARKNET_RPC="https://starknet-testnet.public.blastapi.io"
Ejemplos que puede usar para cada una de sus cuentas Workshop con OZ
, Katana
o Braavos
, en este caso indicamos un API KEY
propioi creado en Infura, pero recuerde revisar todas las posibilidades en Sección de RPC
export STARKNET_ACCOUNT=~/.starkli-wallets/deployer/Account_WorkshopL2.json
export STARKNET_KEYSTORE=~/.starkli-wallets/deployer/Signer_WorkshopL2.json
export STARKNET_RPC="https://starknet-goerli.infura.io/v3/6e7788ff3c784159993c45a949172f0e"
Variables de Entorno de Starknet Braavos/Argent
export STARKNET_ACCOUNT=~/.starkli-wallets/deployer/Account_Braavos.json
export STARKNET_KEYSTORE=~/.starkli-wallets/deployer/Signer_Braavos.json
export STARKNET_RPC="https://starknet-goerli.infura.io/v3/6e7788ff3c784159993c45a949172f0e"
Variables de Entorno de Katana
export STARKNET_ACCOUNT=~/.starkli-wallets/deployer/AccountKatana_Workshop.json
export STARKNET_KEYSTORE=~/.starkli-wallets/deployer/SignerKatana_Workshop.json
- Archivo bash:
La otra opción es crear un archivo envars que gestione nuestros keystore
, account
y rpc
, lo ideal sería en la raíz de donde hemos creado nuestras cuentas de OZ
la de Braavos
o la de Katana
crear un envars.sh, en este caso utilizaremos envarsWorkshop.sh
aunque dejaremos al final la configuración de todas ellas, podrá encontrarlas en el repo aquí.
Deberemos crear primero el archivo:
touch ~/.starkli-wallets/deployer/envarsWorkshop.sh
Ahora podremos editarlo y añadir nuestras variables:
#!/bin/bash
export STARKNET_ACCOUNT=~/.starkli-wallets/deployer/Account_WorkshopL2.json
export STARKNET_KEYSTORE=~/.starkli-wallets/deployer/Signer_WorkshopL2.json
export STARKNET_RPC="https://starknet-testnet.public.blastapi.io"
Todo listo para activar nuestras variables, sólo tendremos que ejecutar el comando llamando al archivo con la configuración que queramos usar:
source ~/.starkli-wallets/deployer/envarsWorkshopL2.sh
Ejemplos que puede usar para cada una de sus cuentas Workshop con OZ
, Katana
o Braavos
touch ~/.starkli-wallets/deployer/envarsKatana.sh
touch ~/.starkli-wallets/deployer/envarsBraavos.sh
touch ~/.starkli-wallets/deployer/envarsWorkshop.sh
Katana
#!/bin/bash
export STARKNET_ACCOUNT=~/.starkli-wallets/deployer/AccountKatana_Workshop.json
export STARKNET_KEYSTORE=~/.starkli-wallets/deployer/SignerKatana_Workshop.json
export STARKNET_RPC=http://0.0.0.0:5050
Braavos
#!/bin/bash
export STARKNET_ACCOUNT=~/.starkli-wallets/deployer/Account_Braavos.json
export STARKNET_KEYSTORE=~/.starkli-wallets/deployer/Signer_Braavos.json
export STARKNET_RPC="https://starknet-goerli.infura.io/v3/6e7788ff3c784159993c45a949172f0e"
OpenZeppelin
#!/bin/bash
export STARKNET_ACCOUNT=~/.starkli-wallets/deployer/Account_Workshop.json
export STARKNET_KEYSTORE=~/.starkli-wallets/deployer/Signer_Workshop.json
export STARKNET_RPC="https://starknet-goerli.infura.io/v3/6e7788ff3c784159993c45a949172f0e"
source ~/.starkli-wallets/deployer/envarsKatana.sh
source ~/.starkli-wallets/deployer/envarsBraavos.sh
source ~/.starkli-wallets/deployer/envarsWorkshop.sh
- Env:
También hemos dejado unos .env.example
que definiran .env
si quiere utilizar este método, recordamos que los .env
no son subidos a github y permaneceran seguros en ese archivo.
Deberemos crear primero nuestro archivo .env
escogiendo el example deseado, en este caso seguiremos con example con la configuración del account de Workshop
, para ello ejecutaremos el siguiente comando:
cp .env.example .env
source .env
Si nos encontramos en la carpeta raíz de nuestro proyecto, tenemos dos opciones: ir directamente a nuestra carpeta dev
y ejecutar declare
con starkli
:
starkli declare workshop_l2_hola.contract_class.json
O indicar directamente la ubicación de nuestro archivo:
starkli declare ./target/dev/workshop_l2_hola.contract_class.json
Si recibes algún error, revisa si se debe a la falta de encontrar el archivo, lo que indicaría un error en la ruta o el nombre. También verifica si al abrir una nueva terminal olvidaste exportar las variables de entorno necesarias o ingresaste incorrectamente tu contraseña.
El resultado esperado incluye datos como la red utilizada, la versión de compilación, el hash de la transacción y la compilación a Sierra desde Casm. Esto generará un Class hash
que debemos guardar para nuestro despliegue. También puede indicar que tu class
ya ha sido declarada.
En este ejemplo, usaremos Class hash declared: 0x07f445377d79d98b866338dcfae6f9003f43b26124f84dcb2d4cda4542f1599c
, el cual ya ha sido declarado.
Ahora que hemos declarado nuestro contrato, si no se había hecho anteriormente y es único, podemos omitir la declaración y proceder directamente al despliegue. Para ello, debemos asegurarnos de revisar los argumentos que se pasan al constructor del contrato. En primer lugar, debemos proporcionar el Class hash
del contrato que queremos desplegar, en este caso será 0x07f445377d79d98b866338dcfae6f9003f43b26124f84dcb2d4cda4542f1599c
.
Además, en el constructor (en caso de que lo haya) debemos revisar los argumentos que necesitamos para desplegar nuestro contrato, en este caso sólo necesitamos un Nombre
que queramos guardar en nuestro storage
del contrato para el Hola.cairo
pero debemos revisar cada constructor para el resto de contratos de Owner.cairo
y WorkshopMensajesL2.cairo
Aquí revisamos este caso concreto que necesita el constructor:
#[constructor]
fn constructor(ref self: ContractState, name: felt252) {
self.name.write(name);
}
Para pasar nuestro nombre que queramos guardar a felt
o a hexa
podemos utilizar el comando de Starkli y añadir el string, en este caso pondremos Nadai
:
starkli to-cairo-string Nadai
Y vemos que la salida convertida que deberemos pasar es 0x4e61646169
. También podemos utilizar la herramienta Stark.utils para hacer la conversión. Por lo tanto, ejecutamos el siguiente comandos y añadimos los argumentos requeridos:
starkli deploy 0x07f445377d79d98b866338dcfae6f9003f43b26124f84dcb2d4cda4542f1599c 0x4e61646169
Puedes consultar el enlace del contrato del "Hola" para asegurarte de que todo esté correcto y que se guardado el nombre de Nadai
para ello podemos revisar la función de read obtener_nombre
, que deberá dar la data recién guardada.
Además, con Starkli, puedes realizar llamadas directas al contrato para verificar que todo esté en orden indicando call
seguido del contract
y el nombre del selector
, en este caso el selectro que vamos a llamar es obtener_nombre
:
starkli call 0x012db11f112b48ce84c7943b7c62777abc776773eafcc60f394103b5b450adb8 obtener_nombre
Podemos convertir este valor de nuevo a un string que deberá dar el nombre de Nadai
, utilizando Stark.utils o con Starkli y el comando:
starkli parse-cairo-string 0x0000000000000000000000000000000000000000000000000000004e61646169
Ahora para finalizar haremos un invoke
, el cual modificará el estado del contrato y por lo tanto de la red, para ello escogemos un nuevo Name
, usaremos L2enEspanol
para convertirlo, usando el comando anterior:
starkli to-cairo-string L2enEspanol
Ahora pasaremos el valor 0x4c32656e457370616e6f6c
como argumento con el comando de Starkli invoke
en el cual deberemos indicar el contract
, el nombre del selector
, en este caso el selector que vamos a llamar es escoger_nombre
seguido del nuevo nombre:
starkli invoke 0x012db11f112b48ce84c7943b7c62777abc776773eafcc60f394103b5b450adb8 escoger_nombre 0x4c32656e457370616e6f6c
Y podemos comprobar con el comando anterior para obtener_nombre
que el estado del contrato ha sido cambiado correctamente:
starkli call 0x02edd5e8f285ef73e78fcdb46e667e2d3a47b960e0575c1b6c2a5b4d91c6b0f3 obtener_nombre
También podemos revisar en los explorer que todo ha sido actualizado y la invoación a la función escoger_nombre
está funcionando correctamente.
Ahora con Katana, configuraremos un Owner. Podríamos usar un keystore similar al de las otras cuentas. Primero, accederemos a katana
. Tenemos la opción de levantar este nodo local para interactuar con él. Recomendamos ejecutarlo con la opción --disable-fee
para evitar problemas de costos de gas por transacción. En este ejemplo, configuraremos katana
para lanzar solo 3 cuentas
, en lugar de las 10 cuentas
predeterminadas. Luego, dividiremos la terminal en dos para continuar.
katana --disable-fee --accounts 3
Una vez levantado Katana, configuramos nuestra cuenta de Katana como un signer y establecemos las cuentas que han sido pre-desplegadas para usarlas en este entorno. También creamos nuestro descriptor de cuenta:
starkli signer keystore from-key ~/.starkli-wallets/deployer/SignerKatana_Workshop.json
Luego, utilizamos las variables de diferentes maneras, ya sea mediante env
, un archivo envars
, o bien configurándolas manualmente:
export STARKNET_ACCOUNT=~/.starkli-wallets/deployer/AccountKatana_Workshop.json
export STARKNET_KEYSTORE=~/.starkli-wallets/deployer/SignerKatana_Workshop.json
Pasamos a declarar y desplegar nuestro contrato Owner.cairo. Después de haber ejecutado scarb build
, estamos listos para el declare
y deploy
, debiendo indicar el rpc de katana
:
starkli declare target/dev/workshop_l2_Ownable.contract_class.json --rpc http://0.0.0.0:5050 --account ~/.starkli-wallets/deployer/AccountKatana_Workshop.json --keystore ~/.starkli-wallets/deployer/SignerKatana_Workshop.json
Luego, indicamos el Class hash
del contrato a desplegar y los argumentos requeridos por Owner.cairo
. Por ejemplo, una dirección de quien será el propietario, como una de las cuentas de Katana que no haya sido utilizada.
starkli deploy 0x0539a4c86c5f2a93977c227d2ff7777ec895418961b824b5cb1ad3eadce9b0e3 0x5686a647a9cdd63ade617e0baf3b364856b813b508f03903eb58a7e622d5855 --rpc http://0.0.0.0:5050 --account ~/.starkli-wallets/deployer/AccountKatana_Workshop.json --keystore ~/.starkli-wallets/deployer/SignerKatana_Workshop.json
Usamos Starkli
para realizar call
y invoke
, añadiendo el rpc
y las variables adecuadas. Por ejemplo, para verificar get_owner
:
starkli call 0x04bcc6a7571624b8f082507512dbb91e3b380eb138067ff5bf103a72faeaae42 get_owner --rpc http://0.0.0.0:5050
Para realizar un transfer_ownership
, solo necesitamos la dirección del contrato y el nuevo propietario. Antes de ejecutar este comando, es necesario configurar la segunda cuenta que acabamos de hacer propietaria para poder realizar el invoke
con esa cuenta.
-
Crear Signer Cuenta 3:
starkli signer keystore from-key ~/.starkli-wallets/deployer/SignerKatana3_Workshop.json
-
Crear Descriptor y Cuenta 3:
starkli account fetch 0x5686a647a9cdd63ade617e0baf3b364856b813b508f03903eb58a7e622d5855 --rpc http://0.0.0.0:5050 --output ~/.starkli-wallets/deployer/AccountKatana3_Workshop.json
Una vez configurada, hacemos el invoke
hacia la tercera cuenta de Katana, por ejemplo:
export STARKNET_ACCOUNT=~/.starkli-wallets/deployer/AccountKatana3_Workshop.json
export STARKNET_KEYSTORE=~/.starkli-wallets/deployer/SignerKatana3_Workshop.json
starkli invoke 0x04bcc6a7571624b8f082507512dbb91e3b380eb138067ff5bf103a72faeaae42 transfer_ownership 0x765149d6bc63271df7b0316537888b81aa021523f9516a05306f10fd36914da --rpc http://0.0.0.0:5050 --account ~/.starkli-wallets/deployer/AccountKatana3_Workshop.json --keystore ~/.starkli-wallets/deployer/SignerKatana3_Workshop.json
Para verificar que todo ha salido bien, puedes revisar que Katana haya minado tres bloques o transacciones. Además, puedes volver a ejecutar una llamada al contrato usando starkli call
para confirmar que el owner
ha cambiado correctamente hacia la nueva cuenta de Katana 3:
starkli call 0x04bcc6a7571624b8f082507512dbb91e3b380eb138067ff5bf103a72faeaae42 get_owner --rpc http://0.0.0.0:5050
Este contrato se encarga de recibir mensajes en L2
provenientes de L1
y manejar estos datos utilizando el selector
correspondiente y otros valores que veremos posteriormente. Es esencial indicar al sistema que manejará estas funciones de mensajes con #[l1_handler]
. Nuestro contrato WorkshopMensajesL2.cairo
también puede enviar mensajes desde L2
hacia L1
para ser consumidos.
Para comenzar, desplegaremos nuestros contratos WorkshopMensajesL1.sol y WorkshopMensajesL2.cairo. Usaremos Remix para desplegar nuestros contratos en Ethereum y en Cairo de manera sencilla.
Comencemos creando un nuevo Workspace en blanco y asignando el nombre deseado, por ejemplo, Workshop L2 en Español
.
Ahora subiremos la carpeta que hemos clonado del Workshop, la cual contendrá la carpeta l1
para desplegar nuestro contrato de Solidity en Ethereum y nuestros contratos en Cairo para Starknet.
Luego, procederemos a compilar el proyecto. Deberemos asegurarnos de seleccionar WorkshopMensajesL1
, compilar y dirigirnos a la sección de despliegue. Aquí deberemos indicar la conexión que utilizaremos; en este caso, Injected Provider - Metamask
para utilizar una cuenta de Goerli con fondos de faucet.
Tendremos que indicar los valores que necesita el constructor para desplegar. En este caso, la dirección del Contrato del Starknet Core desplegado en Goerli, que controla y es responsable de todas las syscall. La dirección en Goerli de Ethereum es 0xde29d060D45901Fb19ED6C6e959EB22d8626708e
.
Una vez confirmada la transacción, nuestro contrato estará desplegado. Para interactuar con él desde el Explorador, deberemos verificar este contrato. Podemos bajarnos el plugin de Contract verification - Etherscan
, pero primero necesitaremos crearnos una API KEY
para poder verificarlo correctamente.
También pueden usar el contrato desplegado aquí si no consiguen Verificarlo.
Para verificar con la API KEY, primero tendremos que crear una desde Etherscan. Crea una cuenta, inicia sesión y accede a la pestaña de tu perfil y Api Key
.
Simplemente presiona Add
y crea una nueva con el nombre que desees, luego copia tu Api Key Token para pegarlo en Remix y poder verificar tu Contrato.
A veces, la verificación básica puede causar problemas. Para prevenirlo, prueba en Remix antes de verificar crear un flatten
del contrato WorkshopMensajeL1.sol
.
Podrás verificar que tu contrato no esté verificado previamente y que no puedas modificarlo ni acceder a sus funciones desde el explorador. Una vez ingreses al plugin de Verificación, en el ícono Home
, se te pedirá tu Api Key Token
. Después de agregarlo, selecciona los argumentos del constructor 0xde29d060D45901Fb19ED6C6e959EB22d8626708e
y la dirección del Contrato desplegado, en nuestro caso 0xF2dcF405fE5cE4000F1637e9B65aC6F7416e43A0
.
A pesar de que podríamos seguir utilizando Remix para desplegar Workshop Mensajes L2, nos enfocaremos en la CLI para practicar. Utilizaremos la cuenta de Braavos para llevar a cabo este proceso.
Primero, configuramos las variables. Aunque dejaremos las variables aquí para configurarlas manualmente, recuerda que existen diversos métodos para gestionarlas.
export STARKNET_ACCOUNT=~/.starkli-wallets/deployer/Account_Braavos.json
export STARKNET_KEYSTORE=~/.starkli-wallets/deployer/Signer_Braavos.json
export STARKNET_RPC="https://imited-rpc.nethermind.io/goerli-juno"
Dentro de la carpeta l2
, ejecutamos scarb build
. En el comando declare
, indicamos el contrato WorkshopMensajesL2
en formato .json
en Sierra.
starkli declare ./target/dev/workshop_l2_WorkshopMensajesL2.contract_class.json
Si no hemos realizado cambios, veremos la notificación de que el contrato ya ha sido declarado. Procedemos al deploy, sin necesidad de argumentos del constructor.
starkli deploy 0x03ac40c1e3bde07fe4fb81623fdbb72fd1c34a6bcb492712c38997f1adcadea5
El contrato de Mensajería de L2 en Cairo está listo para ser utilizado.
Ahora procederemos a enviar nuestros mensajes entre L1<->L2. Es esencial comprender el manejo de mensajes y sus estados:
- Enviado a L2: El mensaje es enviado desde L1->L2, donde es recibido y registrado en la red de L2 para su procesamiento posterior.
- Consumido en L2: Una vez recibido en L2, el mensaje es procesado y utilizado por los contratos o la lógica implementada en Starknet.
- Finalizado en L1: Después de haber sido consumido y procesado en Starknet, se informa a la capa 1 sobre la finalización del mensaje, actualizando su estado para reflejar que la acción se ha completado.
- Enviado a L1: El mensaje es enviado desde L2->L1, listo para ser recibido y procesado por la red de L1.
- Adjuntado a L1: Una vez que el mensaje llega L1, se adjunta a la red para su procesamiento posterior. En este estado, el mensaje está disponible pero aún no ha sido consumido.
- Consumido en L1: Finalmente, el mensaje podrá ser consumido por L1 y su contenido es utilizado según lo previsto en la lógica implementada en esa capa.
Estos estados reflejan cómo los mensajes atraviesan diferentes capas (L1 y L2) y cómo se procesan y utilizan en cada una de ellas hasta su estado finalizado o consumido.
Para enviar mensajes, es necesario tener #[l1_handler]
indicado para realizar una syscall
y el selector de la función deseada, como recibir_mensaje_valor_l1
. Además, el valor enviado desde L1 debe cumplir con condiciones específicas, como la carga útil añadida en assert(value == 123)
, y especificar from_address
del contrato de L1 que envía el mensaje (WorkshopMensajesL1).
#[l1_handler]
fn recibir_mensaje_valor_l1(ref self: ContractState, from_address: felt252, value: felt252) {
// assert(from_address == ...);
// Valor fijo para ser válido == 123
assert(value == 123, 'Valor inválido');
}
Podríamos calcular el selector directamente con un keccak256, pero es más sencillo usar Stark Utils o convertirlo con starkli selector recibir_mensaje_valor_l1
, donde obtendremos el selector en felt o en hexa. En este caso, usaremos 488620836784764677921038031667344270694842985450521428815152577605510277981
.
Pero si pasamos el comando para conseguir el selector de un nombre nos devolverá el valor en hexa, que también nos valdría:
starkli selector recibir_mensaje_valor_l1
Este será el valor del selector que utilizaremos al enviar el mensaje de L1->L2 si queremos utilizar esa función específica. Para ello, debemos ir al contrato desplegado en L1 e indicar los valores correspondientes para enviar_Mensaje_Starknet:
- PayableAmount: Cantidad de ETH a enviar para pagar, que puede ser 0.000001
- ContractAddress: Dirección del Contrato de L2 que recibirá el mensaje (WorkshopMensajeL2.cairo)
- Selector: Función interna en el Contrato de L2 indicada con L1 Handler que queremos utilizar
- Payload: Valor que queremos pasar
Observamos que el mensaje llega casi instantáneamente de L1 a L2 con el estado Enviado a L2
.
Si todo ha salido bien, no deberás realizar ningún paso adicional. Verificarás que, a medida que avancen los estados de pendiente en L1 o cuando se actualice el estado final en L1, el mensaje habrá pasado por los tres estados correctamente, siempre que el selector y los demás valores sean correctos. Puedes verificar si tu mensaje ha sido consumido en L2, lo que significa que ha interactuado correctamente con el selector, verificando que los hashes sean iguales.
Podemos verificar otra vez pasado las 4 o 6 horas, que el mismno hash
ahora tiene otro evento de mensajes, en este caso es la finalización del contrato en L1
Ahora, para realizar un Envío de Mensaje de L2->L1, vamos a proceder desde nuestro contrato en L2. Necesitaremos indicar la dirección del contrato con el cual interactuaremos en L1, siempre y cuando tenga la capacidad de recibir y enviar mensajes. Una vez que el mensaje llegue (este proceso puede tardar entre 4 a 6 horas), podremos consumirlo desde L1.
Ahora observaremos la actualización de mensajes enviados desde L2->L1.
Este mensaje no podrá ser consumido hasta que se adjunte a L1. Este paso se realiza manualmente para evitar posibles ataques y garantizar una seguridad de 2FA. Solo nosotros podremos consumir ese mensaje y aceptar lo que conlleva, como un dato de Valor 123
. Puedes revisar cómo falla la transacción si indicamos valores incorrectos al intentar consumir el mensaje enviado desde L2.
Una vez consumido correctamente, podemos verificar en el registro de L2->L1 que el mensaje ha sido consumido en L1
de manera adecuada.
Con esta sección, hemos interactuado con todos los posibles estados de mensajes entre L2<->L1, creando envíos cross-chain sin depender de un tercero de confianza. Hemos establecido nuestro propio sistema para enviar acciones desde L1->L2. Podemos considerar, en lugar de enviar un valor que solo se refleje en L2, bloquear una cantidad de tokens en el contrato de L1 y mintear su equivalencia en L2. Hemos creado nuestros propios contratos para interactuar entre L1<->L2. ¡Felicidades!
En Scarb, puedes añadir y gestionar las dependencias desde el archivo Scarb.toml
. Añadir una dependencia es fácil y se puede hacer de varias maneras, una de ellas es utilizando el comando scarb add
, que admite una variedad de parámetros para expresar tus dependencias. También puede mantener automáticamente la lista de dependencias ordenada, si no lo está. A continuación, se muestra un ejemplo de cómo agregar una dependencia, como alexandria_math:
scarb add alexandria_math --git https://github.com/keep-starknet-strange/alexandria.git --rev 27fbf5b
Para eliminar una dependencia, simplemente debes eliminar las líneas relacionadas en tu archivo Scarb.toml. Como atajo rápido, puedes utilizar el comando scarb remove
, también conocido como scarb rm
, que limpiará automáticamente el manifiesto de dependencias, debes indicar cual quieres eliminar como se muestra aquí:
scarb rm alexandria_math
Con estas herramientas, puedes gestionar tus dependencias de manera eficiente en Scarb y mantener tu proyecto organizado.
Desde Starkli, puedes cambiar el estado de un contrato, realizar operaciones o hacer consultas a datos y estados de la blockchain. Así que comprobemos si nuestro contrato de Owner.cairo
tiene la dirección del contrato de la cuenta que hemos añadido. Para ello, debemos realizar una call
e indicar qué función queremos invocar. Lo bueno de Starknet son los selectores, y en este caso, llamaremos a la función get_owner
del contrato para obtener información sobre quién es el propietario, en este caso sólo es una call
que no modifica el estado.
starkli call 0x028491f9e3d8b0005a649e08833330de371b5e227be05a0e0575f247df8691a5 get_owner
Desde Starkli, tienes la capacidad de llevar a cabo una invocación invoke
. Esta característica te permite realizar operaciones que tienen el potencial de modificar el estado de un contrato en la blockchain. Para ejecutar un invoke
, debes proporcionar ciertos parámetros clave, como la dirección del contrato
que deseas modificar y la función específica que deseas ejecutar en ese contrato, en este ejemplo, transfer_ownership
. Además, es necesario indicar los argumentos necesarios para la función que estás invocando, como la nueva dirección 0x027f68d0d0f474b1a25f359a42dc49a3003a3522d71765a5e7658e68520d7826
. Esta acción podría resultar en una transferencia de propiedad en el contrato, lo que modificaría su estado interno.
starkli invoke --watch 0x028491f9e3d8b0005a649e08833330de371b5e227be05a0e0575f247df8691a5 transfer_ownership 0x027f68d0d0f474b1a25f359a42dc49a3003a3522d71765a5e7658e68520d7826
Para obtener el class hash
de un contrato desplegado, es necesario proporcionar la dirección del contrato. En este ejemplo, utilizaremos el contrato WorkshopMensajesL2.cairo, cuya dirección es 0x0771b629cb3ff29a7af8369a18e02050b2cccd53bcd4594c9d96718dc3edd9ef
. Este comando proporcionará el class hash
del contrato.
starkli class-hash-at 0x0771b629cb3ff29a7af8369a18e02050b2cccd53bcd4594c9d96718dc3edd9ef
Para visualizar el archivo Sierra.json
desplegado en la red, incluyendo las funciones/selector o el ABI del contrato en formato Sierra, podemos utilizar el comando starkli class-by-hash
o starkli class-at
. Ambos comandos deberían proporcionar el mismo resultado:
starkli class-by-hash 0x03ac40c1e3bde07fe4fb81623fdbb72fd1c34a6bcb492712c38997f1adcadea5
starkli class-at 0x0771b629cb3ff29a7af8369a18e02050b2cccd53bcd4594c9d96718dc3edd9ef
Estos comandos devolverán la información solicitada, incluyendo el Sierra.json
del contrato desplegado y sus detalles asociados.
Podemos conseguir el selector de cualqueir función indicando su nombre con el comando siguiente:
starkli selector nombre_funcion
Una forma sencilla de saber nuestro balance de ETH
en las cuentas sin tener que ir a la wallet o al explorador es consultandolo con el siguiente comando:
starkli balance 0x027f68d0d0f474b1a25f359a42dc49a3003a3522d71765a5e7658e68520d7826
Se puede obtener información sobre la sincronización actual del nodo en la red Starknet, incluyendo detalles desde el bloque inicial hasta el bloque actual y el bloque más alto, utilizando el siguiente comando:
starkli syncing
Este comando devuelve un conjunto de datos que incluyen:
starting_block_hash
: Hash del bloque desde el cual comenzó la sincronización.starting_block_num
: Número del bloque desde el cual comenzó la sincronización.current_block_hash
: Hash del bloque actual en el que se encuentra el nodo.current_block_num
: Número del bloque actual en el que se encuentra el nodo.highest_block_hash
: Hash del bloque más alto sincronizado hasta el momento.highest_block_num
: Número del bloque más alto sincronizado hasta el momento.
Estos datos son útiles para verificar el estado de sincronización del nodo Starknet y determinar la última información disponible en la red.
Puede revisar el resto de comandos con --help
, esto le mostrará todas las opciones disponibles para que pruebe e interactue en saber interpretar los datos provenientes de Starknet.
starkli --help
RPC (Remote Procedure Call) es un protocolo que permite a un programa solicitar servicios a otro a través de una red, incluso en sistemas remotos. En el contexto de Starknet, el RPC es la interfaz que permite a los desarrolladores interactuar con la red Starknet para realizar diversas operaciones y acceder a funciones específicas.
Con el lanzamiento de la versión 0.13.0 de Starknet, se desactivará el uso del gateway del secuenciador, lo que significa que los usuarios ya no podrán acceder a ciertas funcionalidades a través de ese método, eliminando poco a poco la confianza de los nodos sobre el secuenciador. En su lugar, se requerirá el acceso a través del protocolo RPC para realizar acciones y acceder al estado o servicios en la red Starknet, también se lanzará SEPOLIA.
Es importante tener en cuenta esta actualización en camino a la descentralización, ya que cualquier interacción previa que se realizara utilizando el gateway del secuenciador deberá ser modificada para utilizar las nuevas funciones y servicios disponibles a través de los RPC disponibles en la versión 0.13.0 y posteriores de Starknet.
Para obtener detalles específicos sobre las versiones y las funciones disponibles en el RPC de Starknet, puedes consultar la versión oficial de los documentos que se encuentra en la documentación oficial. Las tablas posteriores proporcionan información más detallada sobre las versiones específicas y sus funcionalidades asociadas.
Nombre Provider | Sitio del Provider | Open API endpoint |
---|---|---|
Alchemy | www.alchemy.com/starknet | |
Blast API | blastapi.io/public-api/starknet | https://blastapi.io/public-api/starknet |
Chainbase | chainbase.com/chainNetwork/Starknet | |
Chainstack | chainstack.com/build-better-with-starknet | |
Infura | www.infura.io/networks/ethereum/starknet | |
Lava Protocol | www.lavanet.xyz | https://www.lavanet.xyz/get-started/starknet |
Nethermind | starknetrpc.nethermind.io | http://starknetrpc.nethermind.io |
Algunas endpoint son abiertos y públicos sin la necesidad de crear uno propio y aprovechar su servicio, aunque recomendamos que cada uno se cre su propio API KEY del rpc.
Aquí podremos ver la compatiblidad de las Versiones de Starknet.js
, Devnet-rs
y Starknet.go
RPC Version | Starknet.js Release | Devnet-rs Release | Starknet.go Release |
---|---|---|---|
v0.4.0 | v5.22.0 | Tag | v0.4.6 |
v0.5.0 | v5.23.0 | Tag | v0.5.0 |
v0.5.1 | v5.24.3 | Latest Main Branch Commit | v0.5.0 |
v0.6.0 | TBD | TBD | TBC |
Aquí podremos ver la compatiblidad de las Versiones fijandonos en los nodes de Pathfinder
, Juno
y Papyrus
RPC Version | Pathfinder + Pathfinder powered providers | Juno | Papyrus |
---|---|---|---|
v0.4.0 | - Blast public: https://starknet-testnet.public.blastapi.io/rpc/v0.4 - Blast for user: https://starknet-testnet.blastapi.io/xxx6/rpc/v0.4 - Lava public: https://json-rpc.starknet-testnet.public.lavanet.xyz - Alchemy: https://starknet-goerli.g.alchemy.com/v2/ + apiKey - Infura: https://starknet-goerli.infura.io/v3/ + apiKey |
/v0_4 endpoint | |
v0.5.0 | - Blast public: https://starknet-testnet.public.blastapi.io/rpc/v0.5 - Blast for user: https://starknet-testnet.blastapi.io/xxx6/rpc/v0.5 - Alchemy: https://starknet-goerli.g.alchemy.com/starknet/version/rpc/v0.5/ + apiKey |
||
v0.5.1 | - Chainstack: https://{node-id}.p2pify.com/{apiKey} | https://limited-rpc.nethermind.io/goerli-juno/v0_5 https://free-rpc.nethermind.io/goerli-juno/v0_5 |
|
v0.6.0 | https://github.com/eqlabs/pathfinder/releases/tag/v0.10.0 |
- Clonar el repositorio:
git clone git@github.com:Layer2es/Workshop-Mensajes-Ethereum-Starknet.git
- Instalar Scarb, Starkli y Katana:
curl https://get.starkli.sh | sh
starkliup
curl --proto '=https' --tlsv1.2 -sSf https://docs.swmansion.com/scarb/install.sh | sh
curl -L https://install.dojoengine.org | bash
dojoup
- Verificar Versiones:
starkli --version
scarb --version
katana --version
- Crear Cuenta:
mkdir -p ~/.starkli-wallets/deployer
starkli signer keystore new ~/.starkli-wallets/deployer/Signer_Min.json
- Configurar Variables:
export STARKNET_KEYSTORE=~/.starkli-wallets/deployer/Signer_Min.json
export STARKNET_RPC="https://starknet-testnet.public.blastapi.io"
starkli account oz init ~/.starkli-wallets/deployer/Account_Min.json
Enviar fondos, revise faucet y desplege la cuenta:
starkli account deploy /home/nadai/.starkli-wallets/deployer/Account_Min.json
- Compilar, Declarar y Desplegar el Contrato:
Dentro de la carpeta l2
y compile usando Scarb:
scarb build
- Ahora declaremos el contrato, primero pasamos las 3 Variables junto con el
declare
:
export STARKNET_KEYSTORE=~/.starkli-wallets/deployer/Signer_Min.json
export STARKNET_ACCOUNT=~/.starkli-wallets/deployer/Account_Min.json
export STARKNET_RPC="https://starknet-testnet.public.blastapi.io"
starkli declare ./target/dev/workshop_l2_hola.contract_class.json
Finalmente, desplegar el contrato Hola.cairo
, asegurándote de revisar los argumentos del constructor, en este caso es un name
que se guarda en el storage
y deberemos pasar también el class contract
que queremos desplegar.
starkli deploy 0x07f445377d79d98b866338dcfae6f9003f43b26124f84dcb2d4cda4542f1599c 0x4e61646169