-
Notifications
You must be signed in to change notification settings - Fork 0
Blockchain
- Ethereum
- Ethereum Swarm
- Waku
Una forma un tanto primitiva de deployar un sitio web es a través de un smart contract en la blockchain de Ethereum. El smart contract contiene el código HTML y CSS del sitio web almacenado como un string, y el usuario puede acceder a él a través de la blockchain. Sin embargo, esta no es una forma muy eficiente de deployar un sitio web, ya que los smart contracts en Ethereum son muy costosos y lentos de ejecutar.
- El smart contract es bastante fácil de crear.
- Es costoso hacer actualizaciones sobre el sitio, puesto que hay que pagar gas fees por cada una y se está utilizando la red Ethereum (que tiene un costo alto).
- Hay que analizar si se quisiera hacer un sitio ligeramente más complejo, que incluya recursos multimedia (como imágenes, videos, etc.) o el uso de Javascript (que en principio tendría que ir embebido en el HTML).
- No se puede acceder de forma nativa y directa con un navegador. Hay que crear un script que interactúe con la red de Ethereum (mediante web3.js en nuestro caso), y "pintar" el HTML dentro de otro para que el sitio pueda ser visto.
Existe un proyecto llamado Swarm que funciona de manera similar a IPFS, en el cuál se tiene un almacenamiento de archivos de forma descentralizada.
Un ejemplo del sitio web informativo estático deployado en Swarm es el siguiente:
aa67d1c4493681b2c13d6aaf1da898ebb73a896f11fffdc6e0b187d0cfc0e633 es el hash del directorio del sitio web y, en este caso, se está utilizando el gateway que provee Fair Data Society para acceder a la red de Swarm.
También puede ser accedido de manera local levantando un nodo de Swarm y accediendo a:
http://127.0.0.1:1633/bzz/aa67d1c4493681b2c13d6aaf1da898ebb73a896f11fffdc6e0b187d0cfc0e633/
- Los archivos pueden mantenerse por siempre (mientras que se paguen los stamps, que es lo que se necesita para subir archivos a la red).
- El uso de la red tiene un costo monetario (a través del token BZZ).
Para el desarrollo vamos a estar utilizando un nodo testnet para no utilizar dinero real. Siguiendo estos pasos se podrá configurar dicho nodo.
Se pueden seguir los pasos de la documentación: https://docs.ethswarm.org/docs/bee/installation/install/#1-install-bee.
Necesitamos un nodo de la testnet Sepolia para conectarnos, se podría levantar un nodo local, pero para facilidad de desarrollo vamos a utilizar el servicio Infura que provee dicho tipo de nodo.
Crear una cuenta en https://www.infura.io/ y crear una API key siguiendo los pasos de su documentación. Luego, utilizar la API key creada en el siguiente paso.
Configurar el nodo cambiando el contenido del archivo bee.yaml con lo siguiente (recordar reemplazar la API key de Infura):
## Bee configuration - https://docs.ethswarm.org/docs/working-with-bee/configuration
## config file (default is "/home/<user>/.bee.yaml")
config: "/etc/bee/bee.yaml"
## origins with CORS headers enabled
cors-allowed-origins: ['*']
## data directory (default "/home/<user>/.bee")
data-dir: "/var/lib/bee"
## cause the node to start in full mode
full-node: false
## ID of the Swarm network (default 1)
network-id: 10
## path to a file that contains password for decrypting keys
password-file: "/var/lib/bee/password"
## enable swap (default false)
swap-enable: true
## blockchain endpoint (default "")
blockchain-rpc-endpoint: https://sepolia.infura.io/v3/<INFURA_API_KEY>
## triggers connection to main network
mainnet: falseCon esta configuración el nodo ya se debería estar conectando a la testnet en modo ultra-light-node y es suficiente para que funcione en modo read only. Si se quiere deployar contenido a la red utilizando este nodo es necesario convertirlo a light-node, para eso hay que fondear el nodo con sETH y sBZZ que son las monedas utilizadas en la testnet.
Para comprobar que todo esté bien se puede utilizar la herramienta swarm-cli. Con el comando swarm-cli status deberíamos ver que estamos en modo ultra-light y que hay peers conectados.
Este paso sólo es necesario si se quiere utilizar el nodo para subir contenido a la red.
Se requieren dos monedas: sETH y sBZZ. Primero conseguiremos sETH y luego convertiremos un poco de sETH en sBZZ.
Para esto necesitamos la wallet Metamask que funciona mediante una extensión del navegador, se puede instalar desde su sitio web: https://metamask.io/download/.
Una vez instalada Metamask activar la testnet Sepolia dentro de la extensión y seleccionarla.
Para obtener sETH vamos a utilizar el faucet: https://www.alchemy.com/faucets/ethereum-sepolia. Crear una cuenta e ingresar el address de la wallet de Metamask. En unos minutos deberian aparecer 0.1 sETH en la wallet (tener en cuenta que con esta faucet sólo podemos obtener 0.1 sETH cada 72 horas).
Ahora, para obtener sBZZ vamos a utilizar el exchange Uniswap. Ingresar a: https://app.uniswap.org/swap?outputCurrency=0x543dDb01Ba47acB11de34891cD86B675F04840db&inputCurrency=ETH y conectar la Metamask. Luego, activar testnet mode en Uniswap. En Metamask, seleccionar la red Sepolia. Ahora en la UI de UniSwap debería aparecer el intercambio entre sETH y sBZZ, con obtener 100 sBZZ nos alcanza. Ejecutar el intercambio de monedas y en unos minutos debería aparecer sBZZ en nuestra wallet de Metamask. (Nota: si no vemos sBZZ en Metamask, hay que agregar la moneda a la lista de Metamask).
Por último, nos quedaría enviar las monedas a la wallet del nodo. Para esto primero obtenemos el address del nodo de la siguiente manera:
sudo cat /var/lib/bee/keys/swarm.keyEsto nos devuelve un JSON que contiene un atributo address que es el que nos interesa. Desde Metamask podemos enviar a dicha address (recordar agregar 0x al inicio de la address) las monedas que tenemos. Con 0.05 sETH y 100 sBZZ estamos más que bien.
Luego de hacer esto, utilizando swarm-cli status podemos corroborar que el nodo pasa a estar en modo light y que en la wallet del nodo están los montos enviados.
De esta forma, ya tenemos configurado un nodo de Swarm en la testnet Sepolia que puede deployar contenido en la red.
- Comprar stamps:
swarm-cli stamp buy --depth 20 --amount 30000000000 - Exportar código como archivos estáticos:
npm run build. Esto va a generar archivos en el directorio/out. - Deployar en feed de Swarm:
swarm-cli feed upload ./out/ --identity main --stamp <STAMP_ID>.
Para conectarnos a la red de Ethereum e interactuar con los smart contracts usamos la libreria web3.js desde el browser. La librería primero se tiene que conectar a un nodo de Ethereum, este nodo puede ser provisto por nosotros o podemos usar un servicio como Infura que provee nodos. Algunas preguntan que nos surgen son:
-
¿Existen nodos públicos (o alguna especie de bootnodes) en Ethereum? Para no tener que usar un nodo de un servicio “centralizado”.
- Por lo que vi hasta ahora existen bootnodes pero no son nodos comunes de Ethereum, si no que solo sirven para que los full nodes normales puedan encontrar otros nodos.
-
¿Se puede conectar web3.js directamente a algún bootnode de Ethereum?
- Por lo anterior, esto no tiene mucho sentido porque por más que pudieramos conectarnos, estos nodos no interactúan con smart contracts.
- Aunque si se pudiese obtener IPs de otros nodos y luego usar esos para conectarnos podría ser útil. (Investigar)
-
¿Podemos correr un nodo de Ethereum en el browser? De esta forma web3.js se conectaría a este nodo y no a uno externo.
- En principio pareciera que no por almacenamiento y porque se usa devp2p? (A revisar)
-
¿El estado de un smart contract se guarda completo en un nodo o se shardea de alguna forma?
- Se utiliza una estructura llamada Merkle Patricia Trie (https://ethereum.org/en/developers/docs/data-structures-and-encoding/patricia-merkle-trie/), no me queda del todo claro si un nodo tiene el árbol completo de cada smart contract o solo algunos nodos del árbol.
-
¿Por qué no podríamos usar una testnet en producción?
- Por que no es reliable como la red productiva. Se puede resetear o eliminar en cualquier momento (como ya pasó con Rinkeby)
En cuanto a la parte comunitaria de nuestro trabajo, Ethereum lo cumple a medias. Por ejemplo, algunas limitaciones en este aspecto son:
- Como cada smart contract es inmutable, cuando se tenga que cambiar algo del código hay que deployar uno nuevo lo cuál implica una nueva dirección dentro de la blockchain. Esto implica realizar ciertas estrategias para la migración de los datos de un smart contract al nuevo (ver: https://docs.alchemy.com/docs/upgradeable-smart-contracts)