¿Cómo aseguran los bloques de Ethereum el historial de la red?

La arquitectura fundamental de los bloques de Ethereum

Los bloques de Ethereum constituyen la piedra angular de la integridad de la red, funcionando como contenedores de datos meticulosamente estructurados que, en conjunto, forjan la blockchain. Mucho más que simples listas de transacciones, cada bloque encapsula una instantánea del estado de la red en un momento determinado, junto con las operaciones que condujeron a ese estado. Este diseño intrincado garantiza la continuidad, inmutabilidad y el entendimiento compartido de toda la historia de Ethereum entre todos los participantes. Comprender cómo se construyen y vinculan estos bloques es fundamental para entender el modelo de seguridad de la red.

Anatomía de la estructura del bloque de Ethereum

Un bloque de Ethereum se compone de dos componentes principales: la cabecera del bloque (block header) y el cuerpo del bloque (block body). La cabecera contiene una gran cantidad de metadatos sobre el bloque, mientras que el cuerpo alberga principalmente las transacciones. Esta separación permite procesos de verificación eficientes.

La cabecera del bloque (Block Header) comprende varios campos críticos:

• Hash del padre (Parent Hash): Un hash criptográfico de la cabecera del bloque anterior. Esta es la pieza fundamental del enlace cronológico e inmutable de la blockchain.
• Hash de ommers (o Hash de tíos): Un hash de las cabeceras de los "ommers" (bloques huérfanos) que no se incluyeron en la cadena principal pero que se minaron aproximadamente al mismo tiempo. Este campo era relevante durante la era de Proof-of-Work para recompensar a los mineros por los bloques "casi logrados". En Proof-of-Stake, este concepto es reemplazado por "atestaciones" para las recompensas de los proponentes.
• Dirección Coinbase (o Beneficiaria): La dirección a la que se envía la recompensa del bloque (y las comisiones por transacción, antes del mecanismo de quema de tarifas de la EIP-1559). En Proof-of-Stake, esta es la dirección del validador que propuso el bloque.
• Raíz de estado (State Root): Un hash de 256 bits del nodo raíz del Merkle Patricia Trie que representa el estado completo de la red Ethereum después de que se hayan procesado todas las transacciones del bloque. Esto incluye saldos de cuentas, almacenamiento de contratos y nonces. Este hash único compromete criptográficamente todo el estado de la red.
• Raíz de transacciones (Transactions Root): Un hash de 256 bits del nodo raíz del Merkle Patricia Trie que contiene todas las transacciones incluidas en el bloque. Esto permite una verificación eficiente de que una transacción específica es, de hecho, parte del bloque.
• Raíz de recibos (Receipts Root): Un hash de 256 bits del nodo raíz del Merkle Patricia Trie que contiene todos los recibos de las transacciones incluidas en el bloque. Los recibos contienen información sobre el resultado de las transacciones, como los registros (logs) generados por los contratos inteligentes.
• Filtro de Bloom: Una estructura de datos probabilística utilizada para la búsqueda eficiente de registros dentro de un bloque. Ayuda a determinar rápidamente si un bloque contiene registros de eventos específicos sin tener que iterar por todos los recibos.
• Dificultad: Un valor que representa el esfuerzo computacional requerido para minar el bloque (relevante en Proof-of-Work). En Proof-of-Stake, este campo se establece en 0.
• Número de bloque: La altura del bloque en la blockchain, comenzando desde 0 para el bloque génesis.
• Límite de Gas: La cantidad máxima de gas que pueden consumir todas las transacciones del bloque.
• Gas usado: La cantidad total de gas consumida por todas las transacciones del bloque.
• Marca de tiempo (Timestamp): La marca de tiempo Unix de cuando se creó el bloque.
• Datos extra (Extra Data): Datos arbitrarios opcionales incluidos por el productor del bloque.
• Mix Hash y Nonce: Parámetros utilizados en Proof-of-Work para demostrar que se realizó suficiente trabajo computacional. En Proof-of-Stake, estos campos suelen establecerse en 0 o tienen propósitos específicos relacionados con las firmas de los validadores.
• Tarifa base por gas (Base Fee Per Gas): (Post-EIP-1559) El precio mínimo del gas, que es quemado por el protocolo. Esta tarifa dinámica ayuda a gestionar la congestión de la red.

El cuerpo del bloque (Block Body) contiene:

• Transacciones: Una lista de todas las transacciones validadas y procesadas incluidas en el bloque. Estas transacciones definen los cambios de estado con los que el bloque se compromete.
• Ommers/Tíos: Una lista de hasta dos cabeceras de bloques "ommer" (en Proof-of-Work) que son recompensadas.

El fundamento criptográfico: Hashing e inmutabilidad

En el corazón de la seguridad de los bloques se encuentra el hashing criptográfico. Una función hash toma una entrada (en este caso, la cabecera completa del bloque o los datos dentro de un árbol de Merkle) y produce una cadena de caracteres única y de tamaño fijo. Las propiedades clave de las funciones hash criptográficas son cruciales aquí:

1. Determinismo: La misma entrada siempre produce la misma salida.
2. Resistencia a la preimagen: Es computacionalmente inviable revertir un hash para encontrar la entrada original.
3. Resistencia a colisiones: Es computacionalmente inviable encontrar dos entradas diferentes que produzcan la misma salida hash.
4. Efecto avalancha: Incluso un cambio minúsculo en la entrada cambia drásticamente la salida del hash.

El campo Parent Hash en cada cabecera de bloque utiliza estas propiedades para crear una cadena ininterrumpida. Al incluir el hash del bloque anterior, cada nuevo bloque se compromete implícitamente con toda la historia que lo precede. Si se alterara cualquier dato dentro de un bloque antiguo, su hash cambiaría. Este cambio se propagaría en cascada hacia adelante, invalidando el hash del padre en el bloque siguiente, y así sucesivamente, haciendo que sea inmediatamente evidente que la cadena ha sido manipulada. Este mecanismo fundamental de vinculación es lo que otorga a la blockchain su cualidad casi inmutable y garantiza que la historia de la red, una vez registrada, sea excepcionalmente difícil de reescribir.

Construcción del registro cronológico: El principio de la blockchain

El término "blockchain" describe directamente esta estructura: una cadena de bloques. Esta vinculación secuencial y criptográfica no es solo una elección de diseño inteligente; es el mecanismo central que asegura la historia de la red, garantizando un registro compartido y verificable de todos los eventos.

Génesis y la extensión de la cadena

Cada blockchain comienza con un "bloque génesis" – el Bloque 0. Este bloque inaugural está codificado en el software de la red y no tiene bloque padre. Establece el estado inicial de la red, incluyendo la distribución inicial de Ether (ETH) y cualquier despliegue inicial de contratos.

A partir de este bloque génesis, la cadena se extiende indefinidamente. Se proponen y añaden continuamente nuevos bloques, cada uno con el hash de su predecesor directo. Esta extensión continua construye una historia lineal y cronológica de todas las transacciones y cambios de estado.

• El Bloque N contiene el hash del Bloque N-1.
• El Bloque N-1 contiene el hash del Bloque N-2.
• ...y así sucesivamente, regresando hasta el Bloque 0.

Esta estructura significa que para verificar la validez del bloque actual, uno verifica implícitamente la validez de cada bloque precedente. Cualquier intento de alterar un bloque anterior requeriría volver a calcular los hashes de todos los bloques subsiguientes, lo cual, especialmente para una cadena madura como Ethereum, demanda una cantidad imposible de potencia computacional o una acción maliciosa coordinada de la mayoría de los participantes de la red.

Agregación y ordenamiento de transacciones dentro de los bloques

Los bloques no son solo contenedores abstractos; son el mecanismo a través del cual se procesan y ordenan las transacciones. Cuando los usuarios envían transacciones (por ejemplo, enviar ETH o interactuar con un contrato inteligente), estas se transmiten a la red y se mantienen en una "mempool" (un grupo de transacciones pendientes) por los nodos de la red.

Cuando un validador (anteriormente un minero en Proof-of-Work) es seleccionado para proponer un nuevo bloque, selecciona un subconjunto de estas transacciones pendientes de la mempool. Los criterios de selección a menudo priorizan las transacciones que ofrecen tarifas de gas más altas, lo que garantiza una inclusión más rápida. Una vez seleccionadas, estas transacciones se ordenan de manera determinante dentro del bloque, se procesan secuencialmente y se registran los cambios de estado resultantes.

El papel crucial del bloque aquí es doble:

1. Procesamiento por lotes: Agrupa múltiples transacciones, permitiendo que se procesen y confirmen juntas, en lugar de individualmente.
2. Ordenamiento definitivo: Una vez que una transacción se incluye en un bloque, su posición dentro de ese bloque, y la posición del bloque en la cadena, establece su orden definitivo en relación con todas las demás transacciones de la red. Este ordenamiento es crítico para prevenir problemas como el doble gasto y asegurar transiciones de estado consistentes. Sin este orden definitivo, diferentes nodos podrían procesar transacciones en secuencias distintas, lo que llevaría a estados de red divergentes.

Asegurando el estado: Mecanismos de consenso y finalidad del bloque

La integridad del registro cronológico y el acuerdo constante sobre el orden de las transacciones se mantienen mediante el mecanismo de consenso de Ethereum. Este mecanismo dicta cómo se crean, validan y añaden los nuevos bloques a la blockchain. Ethereum ha pasado por una transición significativa en su mecanismo de consenso, pasando de Proof-of-Work (PoW) a Proof-of-Stake (PoS), cada uno con distintas implicaciones para la seguridad de los bloques.

De Proof-of-Work a Proof-of-Stake

Proof-of-Work (PoW): En la era PoW, los mineros competían para resolver un complejo rompecabezas criptográfico. El primer minero en encontrar una solución (un "nonce" que, combinado con la cabecera del bloque, producía un hash por debajo de un cierto "objetivo de dificultad") proponía el siguiente bloque. Este proceso era computacionalmente intensivo y consumía muchos recursos, siendo conocido por su consumo de energía. La seguridad de los bloques PoW derivaba del costo computacional puro requerido para producirlos; para reescribir la historia, un atacante necesitaría superar en computación al resto de la red, una hazaña cada vez más costosa.

Proof-of-Stake (PoS): La transición de Ethereum a PoS, a través del evento "The Merge", alteró fundamentalmente la forma en que se aseguran los bloques. En lugar de mineros, la red ahora depende de "validadores". Los validadores depositan (stake) una cantidad mínima de ETH (32 ETH) en un contrato inteligente como garantía. El protocolo selecciona aleatoriamente a un validador para proponer un nuevo bloque en cada "slot" (un intervalo de 12 segundos). Otros validadores luego "atestiguan" la validez de este bloque propuesto, votando efectivamente por él.

La seguridad de los bloques PoS proviene de incentivos económicos y penalizaciones:

• Recompensas: Los validadores son recompensados por proponer y atestiguar bloques válidos.
• Slashing: El comportamiento malicioso (por ejemplo, proponer bloques contradictorios, doble atestación) resulta en que una parte del ETH en stake del validador sea "slasheado" (quemado o entregado a un denunciante), con una posible expulsión forzada del conjunto de validadores.
• Liveness (Vitalidad): La inactividad (validadores fuera de línea) también incurre en penalizaciones menores.

Este modelo de seguridad económica hace que reescribir la historia sea increíblemente costoso de una manera diferente. Un atacante necesitaría adquirir y poner en stake una mayoría de todo el ETH (o al menos una parte significativa para interrumpir significativamente la cadena), y luego arriesgarse a que ese inmenso capital sea slasheado.

El papel de los validadores y las atestaciones

Bajo PoS, el ciclo de vida de un bloque implica:

1. Propuesta de bloque: Un validador seleccionado aleatoriamente propone un nuevo bloque, que contiene transacciones de la mempool y referencia al hash del bloque anterior.
2. Atestaciones: Un comité de otros validadores también es seleccionado aleatoriamente para cada slot. Su función es "atestiguar" la validez del bloque propuesto, confirmando su estructura, la validez de sus transacciones y que referencia correctamente al bloque padre.
3. Inclusión: Si se reúnen suficientes atestaciones, el bloque se considera válido y se añade a la cadena.

Estas atestaciones se incluyen a su vez en bloques posteriores, creando efectivamente un sistema de votación distribuido y criptográficamente verificable que asegura la cadena.

Lograr la finalidad de las transacciones

Un concepto crucial relacionado con la seguridad de los bloques es la "finalidad" (finality). En PoW, la finalidad de las transacciones era probabilística; cuantos más bloques se apilaban sobre el bloque de una transacción, más segura se consideraba. Siempre existía una minúscula posibilidad teórica de una reorganización profunda de la cadena si una supermayoría del poder de hash conspiraba.

En Ethereum PoS, se introduce un concepto más fuerte de "finalidad económica". La Beacon Chain, que coordina el consenso PoS, utiliza un mecanismo que involucra "épocas" (periodos de 32 slots o 6.4 minutos). Dentro de una época, si dos tercios del total de ETH en stake atestigua un bloque, ese bloque y todos los anteriores en su cadena se consideran "justificados". Si dos épocas consecutivas están justificadas, los bloques en la primera de esas dos épocas se consideran "finalizados".

Una vez que un bloque está finalizado:

• Es virtualmente imposible revertirlo sin slashear una parte significativa (más de 1/3) de todo el ETH en stake.
• La red garantiza que los bloques finalizados seguirán siendo parte de la cadena canónica.
• Esto proporciona una garantía mucho más sólida de inmutabilidad de las transacciones en comparación con la finalidad probabilística de PoW. Esta finalidad económica es una mejora clave en la forma en que los bloques aseguran la historia de la red, brindando a los usuarios un alto grado de confianza en que sus transacciones son irreversibles.

La realidad compartida de la red: Transiciones de estado y sincronización de nodos

Más allá de simplemente ordenar transacciones, los bloques de Ethereum son los portadores de las transiciones de estado. Cada transacción incluida en un bloque modifica el estado global de la red, y los bloques aseguran que todos los participantes estén de acuerdo sobre cuál es ese estado en cualquier momento dado. Este acuerdo es fundamental para la funcionalidad y seguridad de un sistema descentralizado.

El estado de Ethereum y su evolución

El "estado de Ethereum" es una estructura de datos global y única que representa la condición actual de toda la red. Incluye:

• Saldos de cuentas: Cuánto ETH tiene cada dirección.
• Código de contrato: El bytecode de todos los contratos inteligentes desplegados.
• Almacenamiento de contratos: Los datos persistentes almacenados por los contratos inteligentes.
• Nonces de cuenta: Un contador de transacciones para cada cuenta, que previene ataques de replicación (replay attacks).

Este estado se almacena en una estructura de datos compleja llamada Merkle Patricia Trie (MPT). El hash State Root en cada cabecera de bloque es el hash raíz de este MPT, representando el estado exacto de la red después de que se hayan ejecutado todas las transacciones de ese bloque.

Cuando un nodo procesa un nuevo bloque:

1. El nodo toma el State Root del bloque anterior.
2. Ejecuta todas las transacciones dentro del nuevo bloque, en su orden definido.
3. Cada transacción modifica el estado (por ejemplo, cambia el saldo de una cuenta, llama a una función de un contrato inteligente, despliega un nuevo contrato).
4. Después de procesar todas las transacciones, se calcula un nuevo State Root.
5. Este nuevo State Root debe coincidir con el State Root proporcionado en la cabecera del bloque. Si no coincide, el bloque es inválido.

Este proceso garantiza que cada bloque válido haga la transición de la red de un estado válido al siguiente de forma correcta, creando una cadena ininterrumpida de actualizaciones de estado que refleja el historial de transacciones.

Cómo los nodos mantienen una visión consistente

Ethereum es una red descentralizada, lo que significa que miles de computadoras independientes (nodos) ejecutan el software cliente de Ethereum. Estos nodos juegan un papel crucial en asegurar la historia de la red:

• Validación: Los nodos completos (full nodes) descargan y verifican cada bloque y cada transacción dentro de esos bloques, desde el bloque génesis en adelante. Vuelven a ejecutar las transacciones para asegurar que el State Root coincida y que todas las pruebas criptográficas sean correctas. Esta verificación independiente es cómo confirman la legitimidad de toda la historia de la blockchain.
• Propagación: Los nodos retransmiten nuevos bloques y transacciones por toda la red, asegurando que la información se propague de manera eficiente y que todos los nodos eventualmente se sincronicen al mismo estado.
• Cumplimiento del consenso: Al aceptar y construir únicamente sobre bloques válidos, los nodos imponen colectivamente las reglas del protocolo y rechazan cualquier intento de manipulación o creación de una historia inválida.

La sincronización continua de estos nodos, impulsada por la aplicación consistente de las reglas de procesamiento de bloques y transiciones de estado, crea una "realidad compartida" de la historia y el estado actual de la red. Si un nodo intentara mantener una historia diferente, sería rápidamente rechazado por la gran mayoría de los demás nodos que se adhieren a la cadena canónica, aislándolo efectivamente de la red.

Fortalecimiento de la integridad de la red: Seguridad mediante el diseño de bloques

El meticuloso diseño de los bloques de Ethereum, junto con su mecanismo de consenso, crea una defensa formidable contra diversas formas de ataque y garantiza la integridad inexpugnable del registro histórico de la red.

Prevención del doble gasto y la manipulación

Una de las garantías de seguridad más fundamentales proporcionadas por los bloques es la prevención del doble gasto. Un ataque de doble gasto ocurre cuando un usuario intenta gastar los mismos fondos más de una vez.

• Ordenamiento secuencial: Debido a que las transacciones se incluyen en bloques y se les asigna un orden definitivo e inalterable, es imposible que los mismos fondos se utilicen en dos transacciones diferentes que estén incluidas en la cadena canónica. La primera transacción que se incluya en un bloque gastará los fondos, y cualquier transacción posterior que intente gastar esos mismos fondos (desde la misma cuenta) será rechazada por inválida, ya que el estado de la red mostrará que los fondos ya no están presentes en esa cuenta.
• Inmutabilidad del bloque: La vinculación criptográfica de los bloques mediante hashing hace que sea virtualmente imposible alterar una transacción pasada. Cambiar una transacción en un bloque antiguo cambiaría el hash de ese bloque, invalidando el hash del padre del bloque siguiente, y así sucesivamente. Para corregir esto, un atacante tendría que volver a calcular todos los bloques subsiguientes, lo cual, especialmente después de la finalidad, es económicamente inviable en Proof-of-Stake.

Resiliencia contra actores maliciosos

El modelo de seguridad basado en bloques y mecanismos de consenso garantiza una resiliencia significativa contra actores maliciosos:

• Ataque del 51% (PoW): En PoW, una entidad maliciosa necesitaría controlar más del 51% de la potencia de hash total de la red para superar consistentemente a los participantes honestos y potencialmente reescribir la historia (por ejemplo, revertir transacciones, realizar doble gasto). Esto requería una inmensa inversión financiera en hardware y electricidad.
• Ataques del 33% / 66% (PoS): En PoS, el umbral de seguridad está ligado a la cantidad de ETH en stake.
  • 1/3 del Stake: Si una entidad maliciosa controla 1/3 del total de ETH en stake, puede evitar que los bloques se finalicen, lo que lleva a un ataque de "vitalidad" (la cadena se detiene o no logra finalizar). Sin embargo, no pueden finalizar bloques incorrectos.
  • 2/3 del Stake: Si una entidad controla 2/3 del ETH en stake, puede finalizar bloques inválidos, censurando potencialmente transacciones o realizando doble gasto.
  • El Slashing como disuasivo: La diferencia crítica es que en PoS, cualquier acción maliciosa que comprometa la finalidad o proponga bloques inválidos resulta en el slashing del ETH en stake del atacante. Esta penalización económica hace que tales ataques sean increíblemente costosos, mucho más allá de las ganancias potenciales, haciéndolos económicamente irracionales. La "seguridad criptoeconómica" de PoS se basa, por lo tanto, en la idea de que atacar la red costaría más de lo que se ganaría.

Este robusto marco de seguridad garantiza que la historia registrada en los bloques de Ethereum sea confiable y que los participantes de la red puedan confiar en su integridad.

La evolución de la seguridad de los bloques: Desafíos y perspectivas futuras

Si bien el diseño de bloques de Ethereum ofrece una seguridad robusta, la red evoluciona continuamente, abordando desafíos y mejorando su arquitectura para mantener la descentralización, la escalabilidad y una seguridad mejorada.

Consideraciones sobre bifurcaciones y reorganizaciones

A pesar de la fuerte seguridad, todavía pueden ocurrir "bifurcaciones" (forks) temporales y "reorganizaciones" (reorgs). Una bifurcación ocurre cuando se proponen dos bloques válidos casi simultáneamente, extendiendo la cadena desde el mismo padre. El mecanismo de consenso de la red (la "regla de elección de bifurcación" o fork-choice rule) dicta cómo los nodos eligen qué cadena seguir. En PoW, esta solía ser la cadena más larga. En PoS, la regla de elección de bifurcación GHOST (Greedy Heaviest Observed SubTree), modificada a LMD-GHOST para PoS, prioriza la cadena apoyada por la mayor cantidad acumulada de atestaciones.

• Reorganizaciones menores: Las reorganizaciones pequeñas de unos pocos bloques son normales y esperadas, particularmente durante periodos de latencia de red o problemas de sincronización de validadores. Las transacciones en estos bloques temporalmente huérfanos suelen volver a incluirse en la cadena ganadora.
• Reorganizaciones profundas: Las reorganizaciones profundas son extremadamente raras, especialmente después de la finalidad de la transacción. Implicarían un fallo significativo del mecanismo de consenso o un ataque altamente coordinado y extremadamente costoso.

El diseño de los bloques y la regla de elección de bifurcación aseguran que la red converja rápidamente en una única historia canónica, incluso en presencia de bifurcaciones menores, preservando así la integridad del registro histórico.

Compromisos entre escalabilidad y descentralización

La estructura detallada de los bloques de Ethereum y el riguroso proceso de verificación, aunque cruciales para la seguridad, pueden plantear desafíos para la escalabilidad. Cada nodo completo necesita descargar, almacenar y procesar cada bloque y cada transacción. A medida que aumenta el volumen de transacciones, también aumentan las exigencias sobre los nodos.

• Tamaño del bloque: Aumentar el tamaño del bloque (para incluir más transacciones) puede provocar mayores tiempos de propagación de bloques y mayores requisitos de almacenamiento, lo que podría centralizar la red al excluir a los operadores de nodos más pequeños.
• Crecimiento del estado: El crecimiento continuo del estado de Ethereum (el Merkle Patricia Trie de todas las cuentas y el almacenamiento de contratos) significa que los nodos necesitan más espacio en disco y potencia computacional para mantenerlo y verificarlo.

Ethereum está trabajando activamente en el "sharding" (fragmentación) para abordar la escalabilidad, donde la red se divide en "shards" más pequeños, cada uno procesando un subconjunto de transacciones. La cadena principal (Beacon Chain) sigue asegurando el estado general, y los bloques desempeñan un papel crucial en la comunicación entre shards y la reconciliación del estado, garantizando una historia unificada y segura en toda la arquitectura fragmentada.

Mejoras continuas en la estructura de bloques y el consenso

La seguridad de los bloques de Ethereum no es estática. La investigación y el desarrollo continuos conducen a actualizaciones del protocolo destinadas a mejorar la eficiencia, la resiliencia y la descentralización:

• EIP-1559 (London Hardfork): Introdujo la Base Fee Per Gas y la quema de tarifas de transacción, haciendo que los precios del gas sean más predecibles y reduciendo los ingresos de los validadores por comisiones de transacción, mitigando así los incentivos para que los validadores manipulen el espacio de los bloques. Esto también hizo que el tamaño del bloque fuera más elástico para manejar picos de demanda.
• Árboles de Verkle (Verkle Trees): Una propuesta de actualización futura para reemplazar los actuales Merkle Patricia Tries para el almacenamiento de estado. Los árboles de Verkle ofrecen tamaños de prueba más pequeños, lo que puede reducir significativamente los requisitos de ancho de banda para clientes sin estado y nodos ligeros, facilitando que más usuarios verifiquen el estado de la cadena sin ejecutar nodos completos, mejorando así la descentralización y la seguridad.
• Separación entre Proponente y Constructor (PBS): Una actualización futura que se está explorando para separar el rol de los proponentes de bloques (validadores) de los constructores de bloques (entidades especializadas que optimizan el orden de las transacciones para obtener el Valor Máximo Extraíble, o MEV). Esto tiene como objetivo reducir los riesgos de centralización asociados con el MEV y hacer que la producción de bloques sea más justa y resistente a la censura.

En conclusión, los bloques de Ethereum son componentes meticulosamente diseñados que, a través del hashing criptográfico, los mecanismos de consenso y las transiciones de estado, forman una historia inmutable y auditable de todas las actividades en la red. Este diseño fundacional garantiza un estado sincronizado entre los participantes y un orden de transacciones universalmente aceptado, asegurando así la integridad y fiabilidad de todo el ecosistema de Ethereum. A medida que la red evolucione, también lo harán los mecanismos dentro y alrededor de estos bloques fundamentales, esforzándose siempre por una mayor seguridad, escalabilidad y descentralización.