Conectar una aplicación descentralizada (dApp) a la blockchain implica enlazar tu front-end con un contrato inteligente ya desplegado, usando una librería como ethers.js y un proveedor como MetaMask. Aquí aprendes cómo hacer esa conexión paso a paso, por qué se elige ethers sobre web3, y cómo invocar funciones del contrato desde JavaScript.

¿Cómo se comunica una dApp con la blockchain?

Una dApp no habla directamente con Ethereum. Necesita un intermediario que firme transacciones, pague gas y envíe instrucciones a la red.

El flujo tiene tres piezas claras:

• Una aplicación web en HTML, CSS y JavaScript que muestra la interfaz al usuario.
• Un proveedor, en este caso MetaMask, que firma las transacciones y conecta con la red.
• La blockchain de Ethereum, donde se ejecuta el contrato inteligente (en este ejemplo, la red de pruebas Goerli).

El usuario interactúa con la web, MetaMask firma y paga el gas, y la red devuelve el resultado de la computación. Sin proveedor, no hay firma. Sin firma, no hay transacción.

¿Qué es un proveedor en ethers.js? Es un objeto que conecta tu aplicación con la blockchain. Cuando usas Web3Provider con window.ethereum, le dices a ethers que use MetaMask para firmar y enviar transacciones.

¿Por qué usar ethers.js en lugar de web3.js?

Las dos librerías cumplen el mismo propósito: conectar JavaScript con Ethereum. La diferencia está en su tamaño, eficiencia y comunidad [02:05].

• web3.js fue la primera librería en aparecer y tiene una comunidad más grande por su antigüedad.
• ethers.js es más liviana, más eficiente y ha ganado popularidad rápidamente.

Para una aplicación menos abultada y más rápida, ethers.js es la opción recomendada. Por eso se usa en este flujo.

¿Cómo instalo ethers.js en mi proyecto?

La forma más rápida es desde la documentación oficial en docs.ethers.io/v5/. En la sección Getting started encuentras el snippet del CDN para pegarlo directo en tu HTML [02:55]. Esto evita configuraciones extra y te permite empezar a programar de inmediato.

¿Qué es el ABI y por qué lo necesita tu dApp?

El ABI (Application Binary Interface) es la traducción que tu aplicación necesita para entender qué funciones tiene tu contrato y cómo llamarlas. Sin ABI, JavaScript no sabe que existen métodos como increment o getCounter.

Después de compilar con Hardhat, encuentras el ABI dentro de la carpeta artifacts/contracts/Counter.json. Ahí hay un objeto JSON grande, pero solo te interesa el arreglo bajo la clave abi [03:50].

¿Qué incluye el ABI? Las declaraciones de cada función del contrato, sus parámetros de entrada y los tipos de datos que devuelve. Es el manual que tu dApp consulta para saber qué puede pedirle al contrato.

Una vez copiado el arreglo, lo guardas en una constante junto con la dirección del contrato desplegado:

javascript const CONTRACT_ABI = [ /* arreglo copiado del JSON */ ]; const CONTRACT_ADDRESS = "0x..."; // dirección del contrato desplegado

¿Cómo creo el proveedor y el signer con ethers?

El proveedor abre el canal de comunicación. El signer es quien firma las transacciones, normalmente la cuenta activa en MetaMask.

Primero creas el proveedor usando Web3Provider y le pasas window.ethereum, que existe en el navegador siempre que MetaMask esté instalado. El segundo parámetro es el nombre de la red, en este caso goerli.

javascript const provider = new ethers.providers.Web3Provider(window.ethereum, "goerli");

Luego pides las cuentas conectadas. Aunque normalmente tengas una sola, MetaMask siempre devuelve un arreglo porque podrías tener más de una cuenta vinculada [06:45].

javascript provider.send("eth_requestAccounts", []).then(async (accounts) => { const signer = provider.getSigner(accounts[0]); const contract = new ethers.Contract(CONTRACT_ADDRESS, CONTRACT_ABI, signer); });

Con esos tres parámetros, dirección, ABI y signer, ya tienes una referencia funcional al contrato lista para llamar sus métodos.

¿Cómo llamo funciones del contrato desde el front-end?

Una vez creado el objeto contract, invocar funciones es tan simple como llamar métodos de un objeto JavaScript. La diferencia: son funciones asíncronas porque dependen de la blockchain y tardan en responder.

Mantener los mismos nombres entre el front-end y el contrato ayuda a la consistencia del código:

javascript async function increment() { await contract.increment(); }

async function getCounter() { const counter = await contract.getCounter(); }

increment ejecuta una transacción que modifica el estado y requiere gas. getCounter solo lee datos, así que es gratis y casi instantánea.

¿Por qué las funciones son async? Porque cada llamada viaja a la blockchain, espera confirmación de la red y regresa con el resultado. Sin await, tu código intentaría usar datos que aún no existen.

Con el proveedor activo, el signer asignado y el contrato referenciado, tu dApp ya puede leer y escribir en Ethereum. Falta sumar el HTML que dispare estas funciones desde botones, algo que se construye en la siguiente clase. ¿Qué función vas a probar primero en tu propio contrato?