Modelo de estado basado en cuentas

Comprenda el modelo basado en cuentas de Ethereum mediante campos de cuenta, raices de estado y almacenamiento, ejecucion ordenada, gas y reversiones, almacenamiento de tokens, delegacion EIP-7702, listas de acceso, trazas y finalidad.

Solo con fines educativos; no constituye asesoramiento de inversión. Invertir puede ocasionar pérdidas.

Respuesta directa

Un modelo basado en cuentas representa el estado de ejecucion como datos indexados por direccion. En la capa de ejecucion de Ethereum, una hoja de cuenta contiene [nonce, balance, storageRoot, codeHash]. El balance nativo se expresa en wei; los datos del contrato se encuentran tras el storageRoot de esa cuenta; y el stateRoot posterior a la ejecucion del bloque compromete el estado global resultante. Una cartera, proveedor RPC o explorador lee e interpreta ese estado, pero no almacena el saldo canonico por el usuario.

Los saldos ERC-20, allowances, deuda de prestamos y garantia suelen ser valores del almacenamiento de contratos, no campos adicionales de la cuenta de protocolo del titular. Asimismo, una “transaccion interna” mostrada por un explorador suele ser una llamada de mensaje EVM reconstruida mediante trazas, no una transaccion Ethereum firmada por separado con hash y nonce propios.

La distincion tradicional entre cuenta de propiedad externa (EOA) y cuenta de contrato sigue siendo util, pero “una EOA siempre carece de codigo” ya no es absoluto en una cadena con EIP-7702. Una EOA puede contener el indicador de delegacion 0xef0100 || address y ejecutar el codigo delegado sin perder su autoridad para iniciar transacciones. La clasificacion debe usar las reglas de la cadena y el codigo real, no una etiqueta antigua de interfaz.

Auditoria de la transicion de estado en siete pasos

Fije la observacion: red, chainId, reglas del fork, numero y hash del bloque, timestamp y etiqueta como pending, latest, safe o finalized. El estado cercano a la cabecera puede cambiar tras una reorganizacion; no mezcle datos de bloques distintos sin indicarlo.
Lea los campos de protocolo: nonce, balance nativo, storageRoot y codeHash. Si el codigo es un indicador EIP-7702, resuelva el delegado conforme al fork. En proxies y cuentas delegadas, identifique por separado implementacion, control de actualizacion y layout de almacenamiento.
Localice los saldos de aplicacion. ETH modifica el saldo nativo; un ERC-20 suele modificar un mapping en el contrato del token; allowances, deuda, garantia y recompensas pueden residir en otros contratos y slots. Decimales y logs ayudan a interpretar, pero no son campos de la hoja de cuenta.
Decodifique y precompruebe la transaccion de nivel superior: tipo, dominio de cadena, firma, nonce del remitente, destinatario o creacion, valor, input, limite de gas, topes de comision y lista de acceso o autorizaciones EIP-7702 opcionales. El remitente debe cubrir valor y compromiso maximo de comisiones. Una transaccion rechazada no se incluye ni consume gas on-chain.
Ejecute las transacciones en orden de bloque desde el estado anterior. La EVM procesa llamadas de mensaje anidadas y marcos de creacion, cada uno con caller, callee, valor, calldata, gas y resultado. Las lecturas y escrituras compartidas hacen que el resultado dependa del orden. Una lista EIP-2930 precalienta cuentas y slots y cambia el calculo de gas; no prohibe accesos no declarados ni demuestra paralelismo seguro.
Aplique limites de commit y rollback. Un marco correcto confirma estado y logs salvo que luego revierta un padre. REVERT revierte escrituras, transferencias y logs del marco fallido y devuelve el gas no usado; un contrato exterior puede capturar un fallo hijo y aun terminar correctamente. Un fallo superior incluido tiene recibo status = 0, pero incrementa el nonce del remitente y paga el gas consumido. Las autorizaciones EIP-7702 tienen reglas propias de persistencia aunque la ejecucion posterior revierta.
Concilie el estado posterior. Compare variaciones de ETH y tokens, almacenamiento, estado del recibo, gas usado, precio efectivo, logs y trazas del proveedor con las raices comprometidas del bloque. Trate las trazas como reconstrucciones, no transacciones de consenso independientes. Espere la finalidad necesaria y gestione reemplazos, reorgs, revisiones del indexador, bridges, rollups y reversiones contables.

Cuatro ejemplos desarrollados

Transferencia ETH EIP-1559. A parte con 5 ETH y nonce 12; B con 1 ETH. A envia 1 ETH usando 21,000 gas, con base fee 20 gwei, priority cap 3 gwei y max fee 40 gwei. El precio efectivo es min(40, 20 + 3) = 23 gwei; la comision total es 21,000 × 23 gwei = 0.000483 ETH, de los cuales 0.000420 ETH se queman y 0.000063 ETH son prioridad. El requisito maximo al firmar es 1 ETH + 21,000 × 40 gwei = 1.000840 ETH. Los saldos finales son A 3.999517 ETH, B 2 ETH, y el nonce de A es 13.
Transaccion incluida que revierte. A parte con 2 ETH y nonce 7. Llama a un contrato con 0.50 ETH; la ejecucion superior revierte tras 80,000 gas a 25 gwei, por lo que la comision es 80,000 × 25 gwei = 0.002000 ETH. Escrituras, logs y transferencia de 0.50 ETH revierten, mientras A termina con 1.998000 ETH, nonce 8 y recibo status = 0. Un fallo hijo capturado podria coexistir con recibo exterior status = 1.
El saldo del token es almacenamiento contractual. El contrato registra para Alice 1,000 units y Bob 200 units. Transferir 250 units con exito deja a Alice 750 units y Bob 450 units, conservando 1,200 units. Si la transaccion de Alice usa 60,000 gas × 20 gwei = 0.001200 ETH, su ETH nativo disminuye por separado. Cambian el storageRoot del token y el stateRoot global; el principal del token nunca fue saldo nativo de Alice.
Persistencia EIP-7702. Un sponsor envia una set-code transaction con autorizacion de A en nonce 5 para delegar en D. El protocolo escribe el indicador de 23-byte 0xef0100 || 20-byte address e incrementa el nonce de autoridad de A a 6. Si luego revierte la ejecucion exterior, indicador y nonce de autorizacion ya procesados permanecen. No es el mismo limite de rollback que el almacenamiento EVM ordinario de la llamada fallida.

Riesgos y controles

Leer cadena, fork, hash o etiqueta de bloque equivocados genera una instantanea incoherente.
Un RPC obsoleto o no fiable puede omitir o informar mal el estado de cabecera.
Carreras, huecos y reemplazos de nonce pendiente pueden invalidar supuestos.
“Cancelar” en una cartera suele ser reemplazar la transaccion, no borrarla del protocolo.
Saldo insuficiente para valor mas comision maxima impide la inclusion.
Movimientos de base fee o errores de topes retrasan la inclusion o cambian el coste.
EIP-7702 puede hacer que heuristicas antiguas clasifiquen mal una EOA.
Delegado malicioso, mala inicializacion o replay pueden comprometer una cuenta EIP-7702.
Upgrades y delegate calls pueden cambiar con el tiempo la interpretacion de codigo y storage.
Errores de clave, dominio de firma o chain ID permiten robo o replay.
Reentrancy y orden del estado compartido pueden alterar saldos durante una ejecucion.
Un hijo puede fallar y ser capturado mientras la transaccion exterior figura correcta.
Revert superior u out-of-gas consume gas e incrementa el nonce.
Decimales, fee-on-transfer, rebasing y hooks invalidan aritmetica simple de tokens.
Allowances, deuda, garantia y recompensas se omiten si solo se concilian saldos.
Los logs pueden faltar, revertir, inducir a error o no demostrar el estado final.
“Transacciones internas” y trazas pueden variar porque son vistas reconstruidas.
Una access list puede ser incompleta, duplicada o antieconomica y no bloquea lecturas/escrituras.
Orden del estado compartido, priority fees y MEV pueden cambiar resultados.
Reorgs, pruning, pruebas no disponibles, transiciones L2 y finalidad de bridges pueden revertir u ocultar la contabilidad.

Errores comunes

“La cartera almacena el saldo on-chain”. Guarda credenciales y presenta estado obtenido de la red.
“Cada direccion es para siempre una EOA sin codigo o un contrato ordinario”. EIP-7702 cambia esa heuristica.
“Cada transferencia mostrada es una transaccion Ethereum”. Eventos de token y trazas de llamadas no son transacciones firmadas superiores.
“Una transaccion fallida no cambia nada ni cuesta nada”. Si se incluye, puede consumir gas y avanzar el nonce.
“El modelo de cuentas o una access list garantiza mas paralelismo que UTXO”. Rendimiento y conflictos dependen del protocolo y la carga.