Artículos técnicos sobre modelos de ejecución, consenso, fundamentos de EVM e IA verificable. Cada análisis hace Web3 más claro.
Selección editorialTres caminos maduros rompen el techo de la ejecución de un solo hilo: la predeclaración determinista al estilo Sealevel, el control de concurrencia optimista al estilo Block-STM y los modelos de objetos al estilo Sui. Este artículo compara sus supuestos, sus costos para el desarrollador y su encaje con la compatibilidad con EVM.
Leer artículo →
Las variables de estado caen en slots de 32 bytes en el orden de declaración: los tipos pequeños comparten slot, los mappings y los arrays dinámicos derivan su posición de un hash, y el orden de herencia desplaza en bloque los números de slot. Estas reglas de ubicación determinan por qué un proxy actualizable debe esquivar los slots que asignaría el compilador.
Las cuatro instrucciones de llamada solo se diferencian en unos pocos números dentro del bytecode, pero su semántica decide en qué contexto se ejecuta el código, sobre qué almacenamiento escribe y en qué se convierten `msg.sender` y `address(this)`. Comparar una por una CALL, CALLCODE, DELEGATECALL y STATICCALL permite ver por qué los proxies dependen de DELEGATECALL y por qué se introdujo STATICCALL.
Desglose de la ABI a partir del calldata en bruto: el selector de 4 bytes procede del truncamiento de la firma canónica, los tipos estáticos ocupan una palabra entera y los dinámicos se direccionan en dos niveles mediante desplazamiento y longitud; los eventos escriben los parámetros indexed en topics a cambio de ganar capacidad de búsqueda. La ABI no se autodescribe, de modo que tanto la decodificación como las actualizaciones quedan condicionadas.
El Yellow Paper de Ethereum escribe la transición de estado a nivel de bloque como una llamada anidada, así que el orden de evaluación forma parte de la especificación. De dónde viene la semántica de la ejecución serial transacción a transacción, por qué los conflictos de conjuntos de lectura/escritura no se pueden determinar de antemano, qué se compra con el determinismo y la simplicidad de la verificación, y qué propuestas responden de frente a este punto de origen son el hilo conductor a partir de aquí.
El stateRoot de la cabecera de un bloque ocupa solo 32 bytes, pero ata los saldos, los nonces, el código y el almacenamiento de contratos de todas las cuentas de la red. Este artículo desmonta la estructura de nodos del Merkle Patricia Trie y el trie de almacenamiento colgado de cada cuenta, explica cómo las pruebas de Merkle sostienen la verificación fuera de cadena y sobre quién recae el costo del crecimiento del estado.
El gas es la unidad de medida de recursos de la EVM, y su precio lo determina el mercado de comisiones; confundir ambos planos lleva a juzgar mal las fronteras de la escalabilidad y de la detención de la ejecución. A continuación se desglosan el costo intrínseco y el costo dinámico, se explica qué devuelven out-of-gas y REVERT, y a quién va cada parte de la comisión base y de la comisión de prioridad de EIP-1559.
Los mismos 32 bytes de datos guardados en memory, storage o transient storage pueden costar dos órdenes de magnitud en gas, y su ciclo de vida es por completo distinto. Este artículo separa las tres clases de almacenamiento según tres ejes —propiedad, vida útil y tarificación— y explica dónde debe ir cada cosa: un bloqueo de reentrada, un array temporal o una variable de estado.
La EVM es una máquina de pila sin registros: palabras de 256 bits, una pila de 1024 elementos y un contador de programa que solo puede saltar a JUMPDEST. El ciclo de captación, decodificación y ejecución explica por qué el subdesbordamiento y el desbordamiento de pila consumen todo el gas, y también qué gana y qué paga una máquina de pila frente a una máquina de registros.
Tomar Ethereum por un libro contable que registra transferencias deja fuera su parte más importante: las variables de lectura y escritura libres del almacenamiento de las cuentas. Según la función de transición de estado Υ(σ, T) del Yellow Paper, Ethereum es una máquina de estados distribuida, y la EVM es la especificación de ejecución de esa transición de estado. Que toda la red la repita bit a bit impone además un conjunto de restricciones duras a la semántica de ejecución.
La EVM paralela rara vez falla en los benchmarks de transferencias, pero suele colapsar con el tráfico de AMM, préstamos y acuñaciones de NFT. Este artículo explica cómo se forman los hotspots de conflicto, cómo la granularidad de los conjuntos de lectura/escritura determina la tasa de conflicto y cómo el TPS pico se degrada bajo cargas reales.
¿Un TPS más alto se compra con hardware más caro y menos validadores? Este artículo desglosa dimensiones comprobables —requisitos de validadores, geografía y diversidad de clientes— y discute respuestas de ingeniería como la agregación BLS, sin hype. No es asesoramiento de inversión.
TPS, BPS, latencia de confirmación, finalidad y tasa de conflicto se mezclan sistemáticamente. Este artículo ofrece definiciones reutilizables, patrones de mal uso comunes y la lista de divulgación que conviene exigir a cualquier benchmark. No es asesoramiento de inversión.
Los desarrolladores de contratos, los ingenieros de cliente y los investigadores se interesan por la EVM paralela por razones distintas. Este artículo ofrece tres rutas de lectura que apuntan solo a artículos ya publicados en este sitio, para que cada audiencia encuentre qué leer y qué saltarse.
«Compatible con EVM» suele aplanarse en una línea de marketing. Lo que de verdad determina el costo de migración es la semántica del bytecode, el conjunto de precompilados, el comportamiento de JSON-RPC y si Foundry/Hardhat siguen funcionando sin cambios. Este artículo separa esas cuatro capas y explica por qué el paralelismo hace más difícil mantener la compatibilidad.
Elegir un Layer 1 con EVM paralela optimista implica trade-offs simultáneos en el dominio de liquidación, la compatibilidad y la estrategia de paralelismo. Este artículo expone qué resuelve Bitroot y qué no resuelve —límites, no eslóganes— y cómo sus piezas técnicas se sostienen entre sí.
El control de concurrencia optimista nació en la investigación de bases de datos de 1981 y hoy sostiene muchas EVM paralelas. Esta introducción explica las fases de lectura–validación–escritura, contrasta el OCC con el bloqueo pesimista y el MVCC, y nombra las restricciones adicionales de determinismo y de entorno bizantino que añaden las cadenas de bloques.
Tres caminos maduros rompen el techo de la ejecución de un solo hilo: la predeclaración determinista al estilo Sealevel, el control de concurrencia optimista al estilo Block-STM y los modelos de objetos al estilo Sui. Este artículo compara sus supuestos, sus costos para el desarrollador y su encaje con la compatibilidad con EVM.
La «escalabilidad» suele tratarse como un solo problema. Este artículo la divide en consenso, disponibilidad de datos, ejecución y liquidación, y ubica en ese mapa a las L2, el sharding, la DA independiente y la ejecución paralela en L1, incluido el lugar que ocupa la EVM paralela.
Los grandes episodios de congestión de Ethereum comparten una misma raíz de diseño: la EVM ejecuta las transacciones una por una. Este artículo explica por qué subir el límite de gas y EIP-1559 no pueden reescribir ese modelo de ejecución, y cómo el retraso de confirmación amplifica el techo del hilo único.
Por qué los aportantes de datos, modelos y cómputo rara vez reciben pagos automáticos en la IA —y qué resuelven y qué no resuelven los índices de metadatos en cadena, el particionado por umbral, la auditoría asistida por TEE y los repartos por contrato inteligente—, además de cómo los derechos se apoyan en la liquidación y la computación confiable.
