La arquitectura de pallets de Substrate es una de las diferencias más distintivas entre EmpoorioChain y las cadenas al estilo de Ethereum. Esta página explica qué significa eso en la práctica.
En Ethereum, toda aplicación se distribuye como un contrato inteligente: bytecode desplegado en una cuenta de contrato, ejecutado por la EVM cada vez que una transacción lo tiene como destino. Cualquiera puede desplegar un nuevo contrato en cualquier momento, y cada contrato tiene su propio almacenamiento.
EmpoorioChain, construida sobre Substrate, adopta un enfoque distinto para su funcionalidad nativa: un pallet es un módulo de Rust compilado directamente dentro del binario del runtime. EmpoorioChain incluye actualmente más de 100 pallets nativos — que cubren activos fungibles, NFT, gobernanza, primitivas DeFi, mercados de almacenamiento, funcionalidad relacionada con IA y mucho más — ensamblados en tiempo de compilación mediante `construct_runtime!`, y no desplegados uno a uno por los usuarios finales.
Un pallet define sus propios elementos de almacenamiento, eventos, errores y llamadas 'dispatchable' (el equivalente en pallets a las funciones públicas de un contrato), además de pesos opcionales para la medición de comisiones. Como los pallets residen dentro del runtime, pueden llamarse entre sí directamente y compartir acceso a las primitivas centrales (saldos, cuentas, información de bloque) sin el sobrecoste de llamadas entre contratos medidas en gas que pagan los contratos de Ethereum.
Por eso EmpoorioChain no tiene un contrato ERC-20 separado por cada token, por ejemplo — tiene un único módulo pallet-emp-assets que gestiona cada activo fungible como una entrada en su propio mapa de almacenamiento, igual que pallet-uniques gestiona cada colección de NFT.
Esta es la diferencia práctica más importante para un desarrollador de aplicaciones que viene de Ethereum. En Ethereum, escribir una nueva aplicación normalmente implica escribir y desplegar un nuevo contrato inteligente. En EmpoorioChain, la mayoría de las aplicaciones no escriben ninguna lógica on-chain nueva — llaman a las funciones 'dispatchable' de pallets ya existentes (transferir un activo, acuñar un NFT, abrir una propuesta de gobernanza, registrar un contrato de almacenamiento) mediante extrínsecos, del mismo modo que una aplicación web llama a una API bien definida en lugar de distribuir su propio servidor.
La nueva lógica on-chain (un nuevo pallet, o un cambio en uno existente) se añade mediante una actualización de runtime gobernada, no mediante un despliegue sin permisos — lo cual es un modelo de seguridad y operaciones sensiblemente distinto al de "cualquiera puede desplegar un contrato en cualquier momento".
Nodo que almacena todo el historial y participa en el consenso
Nodo que produce/finaliza bloques
Nodo que sirve RPC sin validar
| Ethereum | EmpoorioChain | |
| Unidad de lógica | Contrato inteligente (bytecode desplegado) | Pallet (compilado dentro del runtime) |
| Quién puede añadir lógica | Cualquiera, sin permisos | Actualización de runtime aprobada por gobernanza |
| Almacenamiento de estado | Almacenamiento por contrato | Elementos de almacenamiento por pallet, estado de runtime compartido |
| Capacidad de actualización | Inmutable salvo que se use un proxy | Actualizable en el runtime mediante gobernanza |
Para los equipos que específicamente quieran un flujo de despliegue por aplicación más cercano al de Ethereum, EmpoorioChain también incluye un pallet de compatibilidad EVM: los contratos en Solidity pueden desplegarse y llamarse a través de él usando las herramientas estándar de Ethereum (Hardhat, Foundry, ethers.js/viem) apuntando al endpoint EVM-JSON-RPC de EmpoorioChain, con el chain ID EVM registrado 2026. Esto ofrece a los desarrolladores de Ethereum una vía familiar de despliegue de contratos que convive con la arquitectura nativa de pallets, en lugar de sustituirla.
| Entorno | Lenguaje | Modelo de despliegue |
| Pallets nativos | Rust | Compilados dentro del runtime, actualizados por gobernanza |
| Pallet EVM | Solidity | Despliegue de contrato estándar al estilo Ethereum, chain ID 2026 |
En Ethereum, desplegar un contrato es inmediato y sin permisos: envías una transacción, pagas el gas y obtienes una nueva dirección de contrato. Actualizar la lógica después requiere un patrón proxy, ya que el bytecode desplegado es, por lo demás, inmutable.
En EmpoorioChain, añadir o actualizar un pallet implica proponer un nuevo blob WASM de runtime a través del proceso de gobernanza de la cadena; una vez aprobado, la nueva lógica se activa simultáneamente para todas las cuentas de la red, sin volver a desplegar nada por aplicación. Los contratos en Solidity desplegados a través del pallet EVM, en cambio, siguen el modelo habitual de Ethereum: inmutables salvo que se use un proxy.
// Ejemplo: un contador en Solidity, desplegable hoy mismo mediante el pallet EVM de EmpoorioChain
contract Counter {
int private count = 0;
function incrementCounter() public {
count += 1;
}
function getCount() public view returns (int) {
return count;
}
}La funcionalidad nativa equivalente — por ejemplo, un contador vinculado a una cuenta — normalmente residiría como almacenamiento dentro de un pallet existente o creado a propósito, invocado mediante un extrínseco en lugar de un despliegue de contrato por aplicación. La mayoría de los equipos que construyen en EmpoorioChain usarán pallets existentes directamente a través del SDK/CLI, en lugar de escribir código nuevo de runtime en Rust.
El compromiso central: el modelo de contratos inteligentes de Ethereum optimiza el despliegue sin permisos por aplicación, a costa del sobrecoste de las llamadas entre contratos y la complejidad de las actualizaciones. El modelo de pallets de EmpoorioChain optimiza una funcionalidad nativa estrechamente integrada y eficiente en gas, a costa de requerir gobernanza para la nueva lógica — al tiempo que ofrece el pallet EVM como puerta de entrada para los equipos que quieran específicamente el modelo de despliegue de Ethereum.
EVM A EMPOORIOCHAIN