Qué es exactamente MonadDB
MonadDB es una base de datos creada específicamente para Monad. Su trabajo principal es almacenar y recuperar el estado que necesita la capa de ejecución: cuentas, balances, código de contratos y storage, además de otros datos utilizados por el nodo, como cabeceras y payloads de bloques.
Hay una distinción importante: MonadDB no es “la blockchain de Monad” ni una base de datos central a la que se conectan todos los usuarios. Cada nodo completo y validador mantiene su propia instancia local. Si necesitas una introducción a esta diferencia entre estado, bloques y red distribuida, nuestra guía sobre cómo funciona una blockchain te da el contexto previo.
En la documentación técnica también encontrarás el nombre TrieDB. En la práctica, hace referencia al backend de almacenamiento basado en trie utilizado por la implementación de Monad.
Lo que hace especial a MonadDB puede resumirse así:
| Pieza de MonadDB | Para qué sirve |
|---|---|
| Patricia Trie nativo | Evita meter el trie de estado dentro de otra estructura de datos distinta |
| Páginas de 4 KB | Agrupa 128 storage slots relacionados |
| E/S asíncrona | Permite seguir trabajando mientras una lectura del SSD está pendiente |
| Trie persistente | Mantiene versiones consistentes para lectores mientras cambia el estado |
| Escrituras secuenciales | Aprovecha mejor el funcionamiento de los SSD |
| Acceso directo a dispositivo | Puede evitar parte del coste añadido por el sistema de archivos |
| Compactación | Recupera espacio a medida que se descartan versiones antiguas |
La combinación es lo importante. Ninguna de estas técnicas, aislada, explica el rendimiento de Monad.
El problema que MonadDB intenta resolver
Para ejecutar una transacción, una blockchain compatible con la EVM necesita consultar constantemente su estado.
Imagina un contrato que recibe una orden para retirar 100 tokens. Antes de modificar nada, la ejecución puede necesitar comprobar el saldo del usuario, los permisos concedidos al contrato y varias variables internas. En la EVM, muchas de esas consultas terminan convirtiéndose en operaciones como SLOAD y SSTORE.
Si los datos necesarios no están en caché, hay que recuperarlos del almacenamiento.
Y aquí aparece un problema que suele recibir bastante menos atención que los TPS: un procesador muy rápido sirve de poco si pasa parte del tiempo esperando al SSD.
Monad intenta ejecutar muchas transacciones en paralelo. Por tanto, su base de datos también tiene que ser capaz de suministrar una gran cantidad de estado sin transformar esas lecturas en una cola.
Por qué MonadDB almacena el Patricia Trie de forma nativa
Un patrón habitual en clientes EVM consiste en tener dos capas:
- una estructura autenticada, como un Merkle Patricia Trie;
- debajo, una base de datos genérica de clave-valor basada en estructuras como LSM trees o B-trees.
Es decir, conceptualmente tienes un árbol almacenado dentro de otra estructura de datos que no fue diseñada específicamente para ese árbol.
MonadDB elimina parte de esa traducción. Implementa directamente una estructura Patricia Trie tanto en disco como en memoria, optimizada para el tipo de accesos que necesita la ejecución de una blockchain. La propia documentación de Monad identifica esta doble estructura como una de las ineficiencias que MonadDB pretende evitar.
Simplificando bastante:
Diseño habitual
EVM → Merkle Patricia Trie → base de datos clave-valor → SSD
MonadDB
EVM → Patricia Trie nativo de MonadDB → SSD
Eso puede reducir niveles de indirección y operaciones de almacenamiento innecesarias.
No significa que cualquier base de datos genérica sea lenta ni que esta arquitectura sea obligatoriamente superior para cualquier aplicación. MonadDB está extremadamente especializada en el patrón de trabajo de un nodo blockchain, y precisamente por eso puede hacer optimizaciones que tendrían poco sentido en una base de datos de propósito general.
MIP-8 cambió una pieza fundamental: ahora el storage se organiza en páginas
Aquí hay un detalle que deja obsoletas bastantes explicaciones antiguas de MonadDB.
Monad introdujo con MIP-8 un modelo de storage basado en páginas. La propuesta tiene estado Final, y la red principal activó el cambio con la revisión MONAD_TEN el 2 de septiembre de 2026. La documentación operativa de Monad sitúa posteriormente la migración de mainnet en la fase final de retirada de la antigua representación.
Antes de entrar en hashes, merece la pena entender la idea sencilla.
Un storage slot de la EVM ocupa 32 bytes. Monad agrupa 128 slots consecutivos:
128 × 32 bytes = 4.096 bytes = 4 KB
Cada slot puede descomponerse así:
page_index = slot >> 7
offset = slot & 0x7F
Los siete bits inferiores indican en qué posición de la página está el dato; el resto determina a qué página pertenece.
¿Por qué 4 KB?
Porque leer un único valor diminuto desde almacenamiento no significa que el hardware transfiera únicamente esos 32 bytes. Hay unidades de E/S mucho mayores.
El planteamiento de Monad es alinear mejor lo que la EVM considera relacionado, lo que se autentica criptográficamente y lo que finalmente tiene que recuperarse del almacenamiento.
Sin páginas, dos variables contiguas de un contrato pueden acabar implicando accesos independientes. Con MIP-8, si pertenecen a la misma página, cargar la primera permite aprovechar también los datos vecinos.
La especificación MIP-8 explica precisamente este problema: los patrones de almacenamiento de Solidity y el hashing del trie pueden destruir la localidad de unos datos que, lógicamente, están relacionados.
Una página no sustituye al Merkle Patricia Trie
Este punto es fácil de interpretar mal.
MIP-8 no elimina el trie ni convierte MonadDB en una simple colección de bloques de 4 KB. Introduce otra capa dentro del storage.
Una hoja del storage trie pasa a comprometer criptográficamente algo parecido a:
{page_index, page_commitment}
El page_commitment es un valor de 32 bytes que representa criptográficamente el contenido de la página.
Dentro de cada página, Monad utiliza una construcción basada en BLAKE3 denominada Induced Subtree Merkle Commit o ISMC. Solo se tienen en cuenta las partes ocupadas de la página junto con un mapa que indica qué posiciones contienen estado.
Después, esa huella de página se incorpora al Merkle Patricia Trie.
Aquí conviven, por tanto, dos funciones distintas:
- BLAKE3 se utiliza para producir el compromiso del contenido de la página;
- Keccak continúa utilizándose en el Merkle Patricia Trie que compromete las páginas.
Por eso sería incorrecto decir simplemente que «Monad sustituyó Keccak por BLAKE3». No lo hizo. BLAKE3 resuelve el compromiso interno de la página; el trie conserva su propia estructura y hashing.
El efecto de las páginas llega hasta el gas
La organización física del estado no se queda escondida debajo del protocolo. Monad también adapta su modelo de gas para reflejar el coste real de acceder al almacenamiento.
Tras MIP-8, el calentamiento del storage se controla por página y cuenta, no solo por slot individual.
La primera lectura de una página cuesta 8.100 gas. Una vez cargada, leer otro slot de esa misma página cuesta 100 gas durante la transacción.
Un ejemplo sencillo:
- lees
slot 10: 8.100 gas; - lees
slot 11, situado en la misma página: 100 gas; - lees
slot 12: otros 100 gas.
El coste de esas tres lecturas sería 8.300 gas por este concepto.
Si los tres valores estuviesen repartidos entre tres páginas distintas, cada primera lectura volvería a ser fría.
Esto produce una consecuencia interesante: una lectura fría individual es relativamente cara en Monad, pero acceder a varios datos próximos puede amortizar ese coste de forma muy agresiva. La documentación oficial fija el acceso frío de storage en 8.100 gas por página de 128 slots, frente a los 2.100 gas por slot que toma como referencia para Ethereum.
Por eso «compatible con la EVM» no significa «idéntico modelo de gas».
Qué cambia para un contrato Solidity
MIP-8 favorece la localidad del estado sin exigir un lenguaje nuevo ni abandonar Solidity.
Variables declaradas consecutivamente, elementos de un array y campos de una estructura suelen ocupar posiciones consecutivas del storage. Si terminan en la misma página, acceder a una puede dejar calientes las demás.
Piensa en algo como:
Position = { collateral, debt, lastUpdate }
Si un mapping relaciona cada dirección con una Position, el punto de partida de cada entrada continúa derivándose mediante hashing. Pero, una vez localizada esa estructura, sus campos se almacenan de manera contigua y pueden beneficiarse de compartir página.
Esto es bastante más interesante que decir que MonadDB «es una base de datos rápida»: el diseño del almacenamiento acaba influyendo en la economía de ejecución de los contratos.
La propia MIP-8 señala que no se necesita una arquitectura especial para aprovecharlo y que patrones de Solidity ya habituales pueden beneficiarse de la localidad.
E/S asíncrona: el nodo no se queda mirando al SSD
La segunda gran pieza es la entrada/salida asíncrona.
En una operación de disco convencional, una ejecución podría solicitar un dato y quedar esperando hasta recibirlo. Multiplicado por un flujo enorme de transacciones, ese tiempo muerto puede convertirse en un límite serio.
MonadDB está construido para que esa espera no paralice todo el trabajo.
En Linux aprovecha io_uring, una interfaz del kernel diseñada para gestionar operaciones de E/S asíncronas de forma eficiente. Así, conceptualmente, puede ocurrir esto:
- la transacción A necesita un dato del SSD;
- MonadDB inicia la lectura;
- en lugar de bloquear todo el hilo de trabajo, el sistema avanza con B;
- otra transacción solicita otro estado;
- se mantienen múltiples operaciones de E/S pendientes;
- cuando llegan los datos, las ejecuciones correspondientes continúan.
La documentación de MonadDB indica expresamente que el diseño busca evitar tener que crear grandes cantidades de hilos del kernel simplemente para aparentar asincronía.
Y aquí aparece la relación con otra pieza central de Monad: la ejecución paralela.
MonadDB y la ejecución paralela se necesitan mutuamente
Monad ejecuta transacciones de forma optimista y paralela, pero el resultado observable sigue respetando el orden lineal del bloque.
Supongamos que aparecen en este orden:
- A envía fondos a Marta.
- Marta envía parte de esos fondos a Luis.
Monad puede empezar a ejecutar la segunda operación antes de que la primera haya terminado. El problema es evidente: podría leer un saldo de Marta todavía desactualizado.
La solución es registrar qué estado ha leído cada ejecución. Al combinar los resultados en el orden correcto, Monad comprueba si alguna transacción utilizó información invalidada por una transacción anterior.
Si ocurre, se vuelve a ejecutar.
Por eso la ejecución paralela de Monad no significa que varias transacciones puedan imponer versiones incompatibles del estado al mismo tiempo. Los resultados terminan siendo equivalentes a ejecutarlas según su orden canónico.
MonadDB encaja especialmente bien en este modelo porque puede mantener muchas lecturas pendientes en paralelo. Incluso una ejecución especulativa que posteriormente tenga que repetirse puede haber servido para traer desde el SSD al caché buena parte de los datos que volverán a necesitarse.
CPU, caché y SSD dejan así de trabajar como una tubería estrictamente secuencial.
Un único escritor y muchos lectores
Que existan operaciones en paralelo tampoco significa que cualquiera pueda modificar simultáneamente cualquier punto de la base de datos.
La arquitectura documentada de MonadDB está pensada alrededor de un escritor —la ejecución— y múltiples lectores, entre ellos otros componentes del nodo.
Para hacerlo sin bloquear continuamente las lecturas, MonadDB utiliza un Patricia Trie persistente.
«Persistente» aquí no significa simplemente que los datos sobrevivan a un reinicio. Es un concepto de estructura de datos.
Cuando cambia una rama del trie, MonadDB crea una nueva versión de los nodos afectados en vez de destruir inmediatamente la anterior. Como consecuencia, pueden coexistir distintas raíces que representan estados coherentes en momentos diferentes.
Imagina este trie extremadamente simplificado:
Root A → rama X → saldo = 100
Después de una transacción:
Root B → nueva rama X → saldo = 80
Las partes no modificadas pueden seguir siendo compartidas, mientras la nueva raíz apunta a las versiones actualizadas.
Esto facilita que un lector continúe consultando una versión consistente mientras el escritor construye otra. Para el lector, una actualización aparece de forma atómica en lugar de encontrarse una base de datos «a medio cambiar».
Por qué las escrituras secuenciales importan en un SSD
La misma estructura persistente permite otra optimización menos vistosa: favorecer escrituras secuenciales.
Los SSD gestionan internamente bloques de memoria y procesos de garbage collection. Un patrón dominado por pequeñas escrituras aleatorias puede provocar más reorganización interna y mayor write amplification: para modificar una cantidad concreta de información, el dispositivo termina escribiendo físicamente bastante más.
MonadDB intenta aprovechar escrituras más secuenciales.
Según su documentación, esto facilita el trabajo de garbage collection del SSD, reduce la amplificación de escritura y puede beneficiar la longevidad del dispositivo.
Es una buena muestra de hasta dónde llega la optimización de Monad: la arquitectura no termina en el smart contract ni en la máquina virtual; tiene en cuenta cómo acaba comportándose un SSD real.
MonadDB incluso puede saltarse el sistema de archivos
Normalmente una aplicación no decide exactamente en qué posiciones físicas se guardan sus bytes. Pide al sistema de archivos que gestione ese trabajo.
Es muy cómodo, pero esa abstracción tiene un precio:
- metadatos;
- asignación de bloques;
- fragmentación;
- llamadas al sistema;
- posibles lecturas o escrituras adicionales.
MonadDB puede funcionar usando archivos normales, pero también ofrece a los operadores la posibilidad de trabajar directamente sobre un dispositivo de bloques. La documentación de Monad recomienda esta segunda opción cuando se busca el máximo rendimiento.
En otras palabras, el propio motor puede gestionar su organización e índices en lugar de delegar parte del trabajo al sistema de archivos.
Es una optimización potente, aunque tiene un trade-off evidente: cuanto más control asume una base de datos sobre el hardware, más específica y exigente se vuelve su operación.
¿Significa esto que un nodo Monad funciona en cualquier ordenador?
No.
Es fácil pasar de «Monad intenta reducir la dependencia de cantidades enormes de RAM» a «puedes ejecutar un validador con cualquier PC». Son afirmaciones muy distintas.
Los requisitos oficiales para nodos completos y validadores incluyen 32 GB o más de RAM, una CPU de 16 núcleos con una frecuencia base indicada de 4,5 GHz o superior, y un SSD NVMe PCIe Gen4x4 o mejor. Para TrieDB se especifican 2 TB de almacenamiento dedicado. Además, Monad recomienda bare metal y no da soporte oficial a entornos cloud virtualizados para estos nodos.
La aportación de MonadDB está en intentar que el estado pueda vivir principalmente en SSD y seguir siendo accesible con suficiente velocidad, en vez de resolver el rendimiento metiendo cantidades crecientes de estado activo en RAM.
Eso reduce un tipo de presión sobre el hardware, pero no convierte un nodo de alto rendimiento en un proceso ligero.
MonadDB no conserva toda la historia para siempre
Otra idea importante: una estructura persistente no implica que todas sus versiones se mantengan indefinidamente.
Guardar cada estado histórico de una blockchain de alta actividad haría crecer la base de datos sin límite.
MonadDB conserva versiones recientes y va eliminando las más antiguas. La documentación operativa indica que nodos completos y validadores comienzan a sobrescribir datos antiguos cuando el almacenamiento de MonadDB alcanza el 80 % de su capacidad. Por eso, una instancia normal no debe confundirse con un archivo completo de toda la historia de Monad.
Para datos transaccionales antiguos, Monad contempla otras capas:
caché en memoria → MonadDB → Archive Server → object storage
El servidor de archivo puede almacenar bloques, transacciones, recibos, logs y trazas en MongoDB. No es lo mismo que mantener indefinidamente todos los estados históricos dentro de MonadDB.
Este diseño separa dos necesidades que a menudo se mezclan:
- ejecutar el estado reciente con muy poca latencia;
- conservar años de información histórica para consultas.
Optimizar ambas exactamente de la misma manera sería bastante ineficiente.
La compactación evita que las versiones antiguas destrocen el almacenamiento
Crear nuevas versiones del trie continuamente tiene un coste: quedan huecos conforme las versiones antiguas dejan de ser necesarias.
MonadDB ejecuta procesos de compactación mientras actualiza la base de datos. La idea es consolidar información todavía activa y recuperar zonas de almacenamiento que ya pueden reutilizarse.
Es el otro lado del modelo persistente.
Crear nuevas versiones ayuda a la concurrencia y permite patrones de escritura favorables al SSD, pero necesitas después una estrategia para gestionar todo lo que queda obsoleto.
MonadDB intenta solucionar ambas partes dentro del mismo motor.
Un recorrido completo: qué ocurre cuando una transacción necesita estado
Con todas las piezas juntas, el funcionamiento se entiende mejor siguiendo una transacción.
Supón que interactúas con un protocolo y el contrato necesita consultar tres variables de tu posición.
1. La transacción entra en un bloque ordenado
Monad determina un orden canónico de transacciones. Que después se ejecuten en paralelo no elimina ese orden.
2. La ejecución empieza de forma optimista
Distintas transacciones pueden avanzar simultáneamente siempre que haya recursos para hacerlo.
3. El contrato solicita estado
La EVM encuentra un SLOAD. Si la información está en caché, la lectura es barata.
Si no está, hay que acudir a MonadDB.
4. MonadDB localiza la página
El slot se traduce a su page_index y a su posición dentro de esa página.
El backend navega por el Patricia Trie hasta localizar el compromiso correspondiente.
5. Se inicia una lectura asíncrona
Si los datos tienen que recuperarse del NVMe, la ejecución no necesita mantener ocioso todo el sistema mientras llegan.
Pueden avanzar otros trabajos independientes.
6. La página entra en caché
Una vez recuperados los 4 KB correspondientes, otras lecturas de slots contenidos en esa página pueden aprovechar los datos ya disponibles.
7. El contrato produce cambios
Los SSTORE modifican el estado lógico.
Si varias ejecuciones especulativas han utilizado datos incompatibles, Monad detecta el conflicto al integrar los resultados en orden.
8. Se actualiza el trie
Los cambios generan nuevas versiones de los nodos afectados y finalmente una nueva raíz que representa el estado resultante.
9. Otros lectores ven una versión coherente
Gracias a la estructura persistente, no necesitan observar una actualización incompleta mientras se están construyendo las nuevas ramas.
Este recorrido explica mejor MonadDB que cualquier cifra aislada de TPS: su función es mantener alimentada a una máquina de ejecución paralela sin renunciar a un estado único, verificable y determinista.
MonadDB frente al patrón tradicional de almacenamiento EVM
| Aspecto | Patrón habitual en clientes EVM | MonadDB |
|---|---|---|
| Estructura autenticada | Merkle/Patricia trie | Patricia trie |
| Backend | Motor KV genérico con su propia estructura | Trie implementado de forma nativa |
| Unidad de storage | Slot individual en el modelo tradicional | Página de 128 slots con MIP-8 |
| E/S | Depende del motor utilizado | Diseñada para E/S asíncrona |
| Linux | Backend convencional | Uso de io_uring |
| Escrituras | Dependientes del motor | Diseño que favorece escritura secuencial |
| Versionado | Depende del cliente y backend | Trie persistente |
| Sistema de archivos | Habitual | Puede utilizarse o evitarse |
| Historial local | Depende del cliente/configuración | Versiones recientes, con poda según capacidad |
La comparación debe interpretarse como una diferencia de arquitectura, no como «Ethereum lento, Monad rápido». Ethereum y Monad toman decisiones distintas en muchos niveles, y MonadDB es solo una pieza dentro de una arquitectura que también incluye ejecución paralela, ejecución asíncrona, consenso y propagación de bloques.
Lo realmente diferencial de MonadDB
La parte más interesante de MonadDB no es una técnica aislada, sino que varias capas están diseñadas alrededor de la misma realidad física: acceder al estado cuesta E/S.
MIP-8 agrupa datos siguiendo una unidad cercana al trabajo real del almacenamiento. El modelo de gas refleja esa agrupación. La ejecución paralela genera múltiples necesidades de estado simultáneas. La E/S asíncrona permite satisfacerlas sin bloquear la CPU. El trie persistente separa lectores y escritor. Las escrituras secuenciales y la posibilidad de evitar el sistema de archivos intentan aprovechar mejor el NVMe.
Ese encaje explica por qué MonadDB es una parte importante de la arquitectura de Monad y no simplemente una sustitución de RocksDB o LevelDB por una base de datos con otro nombre.
También marca sus límites: es software muy especializado, necesita almacenamiento rápido, no elimina los conflictos entre transacciones, no conserva automáticamente toda la historia y no hace que el rendimiento de Monad dependa únicamente de la base de datos.
Si te quedas con una sola idea, que sea esta: MonadDB intenta hacer que el estado de una blockchain EVM se comporte como un problema diseñado para SSD y paralelismo desde el principio, en vez de tratar el almacenamiento como una capa genérica situada al final del proceso.
