Sharding de Ethereum: una introducción al sharding de blockchain
Escrito por Alchemy
¿Qué es el sharding de blockchain?
El Sharding de Ethereum fue reemplazado por danksharding, que da soporte al escalamiento de layer 2 en lugar de escalar directamente la mainnet.
Nota: El siguiente artículo describe los planes abandonados para shardear la mainnet de Ethereum. Parte de la información puede estar desactualizada. Consulta el artículo sobre danksharding enlazado arriba para obtener la información más actualizada sobre el roadmap de escalamiento de Ethereum.
Durante años, la cuestión de la escalabilidad de blockchain se ha debatido en las comunidades de desarrolladores. Las redes de blockchain públicas, como Ethereum, requieren que varios nodos validen las transacciones, lo que limita su capacidad de escalar.
Ethereum, por ejemplo, puede procesar alrededor de 10-13 transacciones por segundo. Esto es insignificante en comparación con sistemas centralizados como VISA, capaz de manejar hasta 24,000 TPS.
Para que las blockchains —y las aplicaciones descentralizadas que corren sobre ellas— logren una adopción masiva, se necesita escalabilidad a nivel poblacional.
Además de las blockchains de layer 2, el sharding es una solución propuesta para escalar Ethereum y dar soporte a más usuarios. La idea del sharding es dividir la blockchain principal en segmentos separados, de modo que los nodos solo necesiten verificar un subconjunto de transacciones.
Con los nodos validando transacciones en paralelo, el throughput de la red puede aumentar, y las apps pueden escalar para satisfacer las necesidades de un número creciente de usuarios.
¿Qué es el sharding de bases de datos?
Una técnica común en la gestión de bases de datos centralizadas, el sharding de bases de datos es el proceso de dividir una base de datos grande en fragmentos más pequeños ("shards") para mejorar la eficiencia y la escalabilidad de la aplicación, distribuyendo una base de datos entre varias máquinas en paralelo.
A medida que aumenta el número de usuarios u operaciones ejecutadas en un software, también aumentan los datos almacenados en su base de datos. Una base de datos sobrecargada afectará el rendimiento de la app y perjudicará la experiencia del usuario. Por eso, el sharding es necesario para aliviar las bases de datos y mejorar los tiempos de carga.
Ejemplo de sharding de base de datos
Imagina que existe una base de datos que contiene registros personales de 100,000 residentes de una ciudad.
Encontrar información de un individuo requeriría procesar cerca de 100,000 transacciones, una tarea costosa y que consume mucho tiempo.
Pero, ¿qué sucede si dividimos esta gran base de datos en bases de datos más pequeñas?
Por ejemplo, agrupando a todos los residentes de la ciudad cuyos apellidos comienzan con letras específicas en un servidor único, encontrar información requiere menos recursos computacionales, las tareas requieren menos tiempo para completarse, y la base de datos se vuelve más fácil de administrar.
Aquí hay una ilustración con otro ejemplo de sharding de base de datos:
¿Qué es un shard?
Un "shard" significa una "parte pequeña del todo." En la gestión de bases de datos, un shard es un subconjunto de una base de datos grande alojado en un servidor separado. Aunque cada shard contiene fragmentos de datos, todos forman un único conjunto de datos lógico.
Usando nuestro ejemplo anterior, podríamos tener un shard, "Shard 1," para los residentes de la ciudad cuyos apellidos comienzan con 'A', "Shard 2," para los que empiezan con 'B', y así sucesivamente.
Si combinas estos shards lógicos, obtendrías un único conjunto de datos con los registros de todos los residentes de la ciudad.
Sharding en redes blockchain
El sharding en redes blockchain sigue el mismo proceso que en las bases de datos centralizadas, donde una red blockchain puede "shardearse" o dividirse en segmentos distintos, en los que cada shard almacena una parte de los datos de la blockchain y procesa un conjunto único de transacciones.
Con el sharding, las redes blockchain pueden mejorar la latencia de la red y la escalabilidad.
¿Qué problema busca resolver el sharding en las redes blockchain?
Debido a que todos los nodos deben llegar a un consenso (es decir, estar de acuerdo) sobre la validez de las transacciones, las redes blockchain solo pueden procesar un número reducido de transacciones a la vez.
Normalmente, cada nodo almacena el historial completo de la blockchain y procesa cada transacción. Esto es lo que hace que redes blockchain como Ethereum y Bitcoin sean "descentralizadas".
Con cada nodo completo teniendo una copia del historial completo de la red, resulta más difícil para actores maliciosos secuestrar la red y potencialmente revertir o reescribir transacciones.
Sin embargo, garantizar la descentralización y seguridad de la blockchain tiene un costo en escalabilidad.
Las blockchains shardeadas permiten a los nodos evitar descargar el historial completo de la blockchain o validar cada transacción que pasa por la red, lo que aumenta la eficiencia de la red y permite a las blockchains escalar el soporte para una mayor demanda de usuarios.

¿Qué es una shard chain?
En el contexto de las redes blockchain, una shard chain contendría una parte de los datos y manejaría una parte de las responsabilidades de procesamiento de transacciones.
Las shard chains son como una colección de mini-blockchains que operan de forma independiente, y para preservar la seguridad, cada shard chain envía un registro de transacciones a la cadena principal (Beacon Chain) a intervalos regulares a través del Validator Manager Contract (VMC).
Debido a que cada shard chain tendrá un historial de transacciones único y un conjunto de nodos para validar nuevas transacciones, múltiples shard chains pueden operar simultáneamente para mejorar la latencia y el throughput de la red mediante procesamiento en paralelo.

¿Qué es el sharding en Ethereum?
Ethereum tenía planeado adoptar el sharding como solución de escalamiento después de sus actualizaciones de PoS de Ethereum, una serie de actualizaciones diseñadas para mejorar la funcionalidad de Ethereum 1.0.
¿Por qué es necesario el sharding?
Hay dos problemas principales que hacen necesario el sharding en Ethereum: la capacidad de soportar un aumento exponencial de usuarios, y la necesidad de mantenerse descentralizado a escala.
1. Dar soporte a un número creciente de usuarios
La estructura actual de Ethereum la hace incapaz de manejar aumentos exponenciales de uso.
Actualmente, todos los nodos de Ethereum almacenan el estado completo de la Ethereum Virtual Machine (EVM), incluyendo el código de los smart contracts y los balances de las cuentas.
Además, las transacciones se ejecutan de forma lineal y requieren confirmación de toda la red.
Transaccionar de forma lineal y requerir que los nodos manejen grandes conjuntos de datos ralentiza la red.
2. Mantener la descentralización a escala
Requerir que los nodos mantengan una copia completa de la blockchain también genera problemas de centralización. Actualmente, el ledger de Ethereum ocupa más de 10 terabytes de espacio de almacenamiento, lo cual es 10 veces lo que puede almacenar una computadora promedio.
A medida que la blockchain de Ethereum sigue creciendo, correr un nodo de Ethereum puede volverse difícil, dejando solo a unos pocos nodos a cargo de asegurar la red. Esto reintroduce los problemas de centralización y de punto único de falla que Ethereum fue diseñada para resolver, reduciendo su valor.
El sharding puede resolver ambos problemas.
El sharding promueve una mejor escalabilidad, ya que los nodos pueden validar diferentes transacciones simultáneamente, y dividir los datos transaccionales en fragmentos más pequeños facilita correr un nodo completo, lo que disminuye el riesgo de centralización.
Terminología del sharding de Ethereum
Antes de explicar cómo funciona el sharding, aquí hay algunas definiciones importantes:
State (estado)
State se refiere a la información sobre un sistema en un momento dado. En Ethereum, el state es una descripción de la red en un momento particular: código de contratos, cuentas, balances de direcciones, etc. Cada nueva transacción altera el state de Ethereum.
Merkle tree
Un Merkle tree o Merkle root es un mecanismo criptográfico que almacena grandes cantidades de información mediante hashes. Los Merkle trees/roots son esenciales para la seguridad de Ethereum, ya que permiten a los nodos verificar rápidamente si un dato forma parte de la estructura más grande.
Collation
Una collation es un grupo de transacciones realizadas en una shard chain, similar a un bloque en proof-of-work (PoW). Las collations se envían a la cadena principal y se enlazan entre sí para formar la blockchain.
Collation header
El collation header es similar a un block header en el consenso de proof-of-work. Un collation header contiene metadatos sobre la información dentro de la collation, tales como:
- El único shard al que pertenece la collation
- El hash raíz de la collation padre
- La Merkle root de todas las transacciones en una collation
- El pre-state root y el post-state root
- Firmas de los notaries
Notaries
Los notaries son validadores asignados aleatoriamente a una shard chain para votar sobre las collations propuestas. Estos votos se llaman "attestations" y prueban la validez de la collation. Cada collation necesita que al menos ⅔ de los collators la firmen antes de ser agregada a la consensus chain.
Proposers
Un proposer es un collator (o validador) seleccionado para crear una collation y proponerla para su validación. El proposer tiene las mismas funciones que un miner en las blockchains de PoW.
Committees
Un committee es un conjunto de validadores o notaries que dan fe de la validez de los shard blocks. Estos committees se reorganizan aleatoriamente a intervalos, de modo que los validadores no pueden predecir en qué committee(s) estarán.
¿Cómo funciona el sharding en Ethereum?
Ante retrasos continuos en el roadmap, la comunidad de Ethereum abandonó sus planes de sharding a favor de un roadmap centrado en layer 2. Esto permitió a los core developers lanzar la actualización de consenso conocida como The Merge, que cambió el consenso de la red a Proof-of-Stake.
La actualización de sharding de Ethereum estaba planeada para dividir la blockchain de Ethereum en 64 shard chains. Cada shard chain tendría un state independiente, lo que significa que los nodos almacenarían un subconjunto de los balances de cuentas, el código de los smart contracts, y procesarían una parte del total de transacciones.
¿Cómo podría haber funcionado en la práctica el sharding de Ethereum PoS?
Imagina que Ethereum tiene 10,000 validadores y 100 shard chains.
Mediante un protocolo pseudoaleatorio, los validadores elegibles, que han depositado ETH en el Validator Manager Contract (VMC), son asignados a los shards 1-100.
En el Shard 1, se selecciona un validador (proposer) para agrupar nuevas transacciones en una collation.
Otros validadores (notaries) descargan la collation y verifican la validez de las transacciones.
Si dos tercios de los notaries dan fe de la collation, esta se envía a la cadena principal a través del VMC.
Es importante notar que la collation completa no se agrega a la Beacon Chain; sería difícil y consumiría mucho tiempo verificar las collations de cada shard.
En cambio, los nodos validadores en la cadena principal simplemente verifican las attestations (firmas) de cada collation para determinar su validez.

Gracias a los collation headers, cualquiera puede verificar la actividad en cada shard.
Los collation headers funcionan como "cross-links" y descripciones del state y las transacciones en distintos shards. Así, la comunicación cross-shard hace posible tener una vista general de la red de Ethereum sin ser parte de cada shard.
Posibles desventajas del sharding
Aunque el sharding de Ethereum prometía muchos beneficios, introdujo un nuevo conjunto de problemas:
- Con menos nodos ejecutando cada shard, la actividad maliciosa, como los ataques del 51%, se vuelve más fácil.
- Con código más complejo, aumenta el riesgo de vulnerabilidades de seguridad en smart contracts.
- Los miembros de un committee pueden coludirse para enviar transacciones maliciosas a la cadena principal.

Sharding de Ethereum: cronología y despliegue por fases
Las discusiones sobre el sharding se han dado en la comunidad de Ethereum desde al menos 2013, pero los desarrolladores han postergado su implementación, y con razón. El sharding es altamente complejo e introduce nuevos riesgos, por lo que se requieren pruebas rigurosas para resolver cualquier problema.
Según Ethereum.org, el sharding se desplegará en Ethereum después de que se haya realizado "The Merge". Para contexto, el Merge se refiere al evento en el que la mainnet de PoW de Ethereum se integra con la Beacon Chain (PoS).
La Beacon Chain es una implementación del sistema de proof-of-stake Casper y produce la aleatoriedad necesaria para crear un sistema de sharding funcional. Esta cadena se lanzó el 1 de diciembre de 2020.
En la siguiente sección, damos una breve descripción de la implementación del sharding en Ethereum:
[Abandonado] Sharding de Ethereum: cronología y despliegue por fases
Las discusiones sobre el sharding se han dado en la comunidad de Ethereum desde 2013, pero los desarrolladores de Ethereum han postergado su implementación porque es altamente complejo e introduce nuevos riesgos, lo que requiere pruebas rigurosas para un lanzamiento exitoso.
Aquí hay una breve descripción de la cronología del sharding de Ethereum:
¿Cuál es la cronología del sharding de ETH 2.0?
Según Ethereum.org, el sharding se implementará en Ethereum después de que haya ocurrido "The Merge", es decir, cuando la mainnet de PoW de Ethereum se integre con la Beacon Chain.
Fase 1 del sharding
Es probable que esta fase comience en 2023, según el cronograma de actualizaciones planeadas de Ethereum. Sin embargo, aún no hay fechas específicas establecidas para la cronología del sharding.
Aquí tienes un resumen de cómo podría verse la primera fase del sharding de Ethereum:
- El Validator Manager Contract (VMC) alojado en la Beacon Chain es responsable de coordinar el proceso de sharding
- Los futuros validadores de ETH2 deben bloquear 32 ETH en el smart contract antes de ser agregados al pool de validadores elegibles
- El VMC asigna validadores a los shards a intervalos para validar y procesar collations de transacciones hacia la consensus chain
- Los shards solo funcionan como "depósitos de datos" para aumentar la capacidad de procesamiento de datos de la red de Ethereum.
Fase 2 del sharding
La segunda fase de la actualización de sharding de ETH PoS está menos definida, ya que los desarrolladores debaten algunos aspectos. Sin embargo, podemos esperar que la fase 2 del sharding de Ethereum se vea así en la práctica:
- Los shards pasan de ser capas de datos a capas de ejecución de código; cada shard tiene un "state" independiente (es decir, un conjunto único de smart contracts, balances de cuentas y direcciones.)
- Cada shard actúa como la Ethereum Mainnet, con soporte completo para smart contracts y dApps
- La comunicación cross-shard permite a los usuarios de diferentes shard chains intercambiar valor.
- Las apps que corren en diferentes shard chains pueden "comunicarse" e interactuar entre sí mediante la comunicación cross-shard, mejorando la funcionalidad de escalabilidad de Ethereum.
Sharding de Ethereum: comentarios finales
Con múltiples shard chains operando simultáneamente, los nodos pueden aumentar su capacidad de procesamiento de transacciones y procesar mayores cantidades de datos on-chain.
Continuando con el ejemplo anterior, si 100 shard chains procesan 100 transacciones por segundo, entonces Ethereum 2.0 podría alcanzar 10,000 TPS.
La única información de los shards que se publica en la cadena de la capa base son los collation headers, pruebas criptográficas de validez, lo que facilita que los nodos validadores confirmen transacciones y las comprometan a la consensus layer chain.
El resultado es una finalidad de transacciones más rápida y una menor latencia de red.
Si bien las estimaciones varían, se espera que la introducción del sharding permita a Ethereum escalar para manejar cientos de miles de transacciones por segundo.
Con tasas de TPS más altas, Ethereum puede ofrecer la escalabilidad que las apps necesitan para manejar picos de uso y miles de millones de usuarios.
Resúmenes relacionados
Ethereum28 de julio de 2026
Lanza una memecoin en Robinhood Chain
Escribe y despliega un ERC20 de suministro fijo en Robinhood Chain mainnet con Foundry y Alchemy RPC, o delega todo el lanzamiento a un coding agent con el Alchemy CLI.
Ethereum18 de noviembre de 2025
¿Qué es la actualización Fusaka de Ethereum? Guía para desarrolladores sobre 12 EIPs
Un desglose práctico de la actualización Fusaka, que explica los 12 EIPs principales y cómo cambian la disponibilidad de datos, la criptografía, los costos de gas y las operaciones de validadores en todo el stack de Ethereum.
Ethereum19 de mayo de 2025
EIP-7702: guía rápida de integración para desarrolladores de Ethereum post-pectra
Ethereum está a punto de recibir una actualización importante con EIP-7702. Aquí hay una guía rápida sobre consideraciones de integración para todos los desarrolladores.

Construye magia blockchain
Alchemy combina los productos y herramientas de desarrollo Web3 más potentes con recursos, comunidad y un soporte legendario.