La fragmentación divide el trabajo de un sistema en partes llamadas shards. En blockchain puede abarcar ejecución de transacciones, estado almacenado, responsabilidades de red o disponibilidad de datos. Estos diseños están relacionados, pero no son intercambiables: dividir el procesamiento no significa necesariamente dividir todos los datos almacenados.
El trabajo paralelo requiere coordinación
En un diseño con estado fragmentado, distintos grupos pueden mantener y procesar subconjuntos diferentes de cuentas o datos. Esto puede reducir el trabajo por nodo y ampliar la capacidad total mediante procesamiento paralelo.
Una transferencia entre cuentas de shards distintos todavía requiere coordinación. El protocolo debe comunicar resultados y preservar reglas de gasto consistentes en todo el sistema. Añadir shards, por tanto, no multiplica automáticamente el rendimiento útil en la misma proporción.
La seguridad también depende de evitar que un atacante controle un shard y de mantener disponibles los datos necesarios. La asignación y redistribución de validadores, junto con los mensajes entre shards, añaden complejidad y sobrecarga.
El enfoque distinto de Ethereum
La escalabilidad actual de Ethereum se centra en rollups y datos blob, con PeerDAS distribuyendo responsabilidades de disponibilidad de datos entre nodos. Su antiguo plan de cadenas de fragmentos de ejecución separadas ya no forma parte de la hoja de ruta.
Por eso, “sharding de Ethereum” necesita contexto: muestrear datos para rollups difiere de dividir la ejecución de Ethereum en cadenas de fragmentos independientes. Las ventajas y supuestos de seguridad deben evaluarse según el diseño real.