Optimización de blockchain: principales cuellos de botella

Para el usuario promedio, la blockchain de criptomonedas puede parecer una máquina perfecta y fluida, sin imperfecciones. Sin embargo, solo muestran sus fallos a medida que se utilizan — como cuando las transacciones se quedan atascadas, los servidores se caen o surge algún error, etc. ¿Qué hay detrás de todo esto? Para los no iniciados, la blockchain es un libro de contabilidad digital místico, una criatura efímera que vive en todas partes y en ninguna, procesando transferencias de valor de forma inmediata y sin error alguno.

Pero la verdad es que es mucho más terrenal. Cuando una transacción se queda atascada en la mempool durante horas, haciendo que un usuario pierda una liquidación DeFi importante, o cuando la congestión de la red durante un minteo popular de NFT borra toda esperanza de completar una operación rentable debido a que las comisiones de gas superan el valor total de la transacción, no se trata de simples errores de software. Son los efectos secundarios de los cuellos de botella inherentes a toda red descentralizada.

Estos problemas no se deben a una programación descuidada o a la falta de esfuerzo. Por el contrario, algunos de los mejores científicos informáticos y criptógrafos del mundo trabajan día y noche para resolverlos. Sin embargo, se han topado con los límites físicos infranqueables, la capacidad del hardware y los inevitables compromisos de los sistemas distribuidos. Para entender por qué su transacción está atascada o por qué la red va lenta, debemos echar un vistazo bajo el capó a los engranajes y palancas que hacen funcionar esta máquina, incluyendo la fricción que la ralentiza.

El trilema de la escalabilidad y los límites del rendimiento

El trilema de la escalabilidad es probablemente el cuello de botella más conocido en el mundo blockchain. La teoría del triángulo de las blockchains de Vitalik establece que una blockchain solo puede poseer dos de las siguientes características: descentralización, seguridad y escalabilidad. No se pueden tener todas al máximo. No se trata de una regla codificada algorítmicamente, sino de una restricción natural en el funcionamiento de las redes distribuidas.

Si quieres una red que sea muy rápida (escalable) y segura, a menudo tienes que hacer concesiones en las que la descentralización se reduce al tener menos nodos verificando las transacciones. Tienes un dilema: si quieres que sea tanto descentralizada como segura, como en la red Bitcoin o Ethereum, sacrificas la velocidad. Es por eso que Bitcoin puede realizar alrededor de 7 transacciones por segundo (TPS) y Ethereum hace unas 15 — 30 TPS en la capa base, mientras que Visa puede procesar decenas de miles.

Aquí, el cuello de botella es el tamaño y el tiempo de bloque. Una solución fácil y obvia para aumentar el rendimiento sería aumentar el tamaño del bloque para dar cabida a más transacciones, o reducir el tiempo de bloque para minar bloques más rápido. Pero aquí nos topamos con una limitación física: el retraso de propagación. Cuando un minero o validador descubre un nuevo bloque, ese bloque debe enviarse a todos los demás nodos de la red. Estos datos viajan a través de los cables de internet, fibra óptica y routers de todo el mundo. Hay límites, por supuesto: la velocidad de la luz y el ancho de banda de la infraestructura de internet. Si un bloque es demasiado pesado, puede tardar más en descargarse y verificarse. Diferentes mineros podrían producir demasiados bloques demasiado rápido de forma simultánea, antes de que el penúltimo bloque se haya propagado, lo que daría lugar a "bifurcaciones" Si no hay un límite en la cantidad de cómputo que puede contener un bloque, un atacante podría saturar la red con transacciones complejas que tarden una eternidad en procesarse y congelen todo el sistema.

Capa 2 y el cuello de botella de la escalabilidad debido a la disponibilidad de datos

Para sortear las restricciones de la Capa 1, la industria ha inventado soluciones de Capa 2, en particular los "rollups". Estos protocolos ejecutan transacciones fuera de la cadena (off-chain), las agrupan en un bloque y luego devuelven una versión comprimida o una prueba criptográfica a la cadena principal (Capa 1). Parece una idea perfecta; sin embargo, conlleva una carga adicional: la DA (disponibilidad de datos). Incluso si el cómputo ocurre fuera de la cadena, debe haber suficiente información en la cadena (on-chain) para "reconstruir" el estado del rollup, de modo que cualquiera pueda verificarlo.

El espacio de bloque en la cadena principal es valioso y escaso. Por ejemplo, resultaría costoso publicar grandes cantidades de *calldata* en Ethereum. Por eso también vemos propuestas como la EIP-4844 (Proto-Danksharding), que plantea la noción de "blobs": un nuevo tipo de almacenamiento de datos más económico y efímero, diseñado exclusivamente para rollups. No obstante, incluso con los blobs, existe un límite en la cantidad de datos que se pueden transmitir por la red sin saturar los nodos. Cuando la capa de DA se llena, el coste de usar esas Capas 2 aumenta significativamente, ya que los rollups compiten por entrar en ese espacio limitado para publicar sus lotes (*batches*). Esto da lugar a un mercado donde el precio de una transacción en una L2 económica depende directamente de la congestión de una L1 costosa. Se trata de un equilibrio entre el compromiso con la seguridad y el coste de asegurarla (publicación en L1) y el uso real.

La carga de la historia: expansión del estado y almacenamiento

Una de las burbujas más importantes —e igualmente olvidadas— es el llamado "crecimiento excesivo del estado" (*state bloat*). Una blockchain consiste en una copia idéntica de cada transacción que se ha realizado. A medida que más personas utilizan la red, este historial se expande. Pero no es solo el historial; es el "estado" (state): el saldo actual de cada cuenta y las tenencias de cada contrato inteligente. Un nodo debe ser capaz de verificar una transacción para poder conocer cuál es el estado actual. Debe asegurar de alguna manera que Alice posee, de hecho, los 10 tokens que desea enviar a Bob. Cuanto más grande se vuelve el estado, más memoria RAM y almacenamiento SSD se necesitan para acceder a él rápidamente.

Si el estado es demasiado grande para caber en hardware de consumo, solo los grandes centros de datos podrán permitirse ejecutar nodos. Esto perjudica la descentralización. Optimizar esto es increíblemente difícil. No se pueden simplemente podar los datos antiguos, porque todo depende del historial completo de la cadena desde el bloque génesis. Los desarrolladores están experimentando con "clientes sin estado" (stateless clients) y "caducidad del estado" (state expiry), registrando datos antiguos y utilizando en su lugar solo la prueba necesaria de los mismos. Pero estas son soluciones criptográficas sofisticadas que tardan años en implementarse de forma segura. Siempre estamos luchando contra la acumulación de datos.

Cada contrato que despliegas, cada token que acuñas es un peso que un nodo debe cargar por la eternidad. Este consumo de recursos es la razón por la cual algunas redes adoptan modelos de recursos como Energía y Ancho de Banda. Es posible que los usuarios necesiten recargar puntos de Energía para interactuar con un contrato inteligente sin gastar tokens, u obtener Energía de TRON con la cual las transacciones se procesan mucho más rápido. Tales modelos son un esfuerzo por cobrar correctamente por la carga en la red: las personas que utilizan un estado deben pagar para mantenerlo. Sin tales mecanismos, la «tragedia de los comunes» daría lugar a una cadena que se saturaría y se volvería inutilizable.

El consenso y su sobrecarga a través de los mecanismos de consenso

En el corazón de cada blockchain se encuentra un mecanismo de consenso: la forma en que miles de desconocidos pueden ponerse de acuerdo colectivamente sobre una única verdad. Independientemente de si se habla de PoW o PoS, el consenso siempre implica cierto nivel de comunicación y cómputo. En PoW, la ralentización se debe en gran medida a la cantidad de energía y hardware necesarios para asegurar la red. El desafío del ajuste de dificultad consiste en mantener la generación de bloques a un ritmo que no sea ni demasiado rápido (seguridad) ni demasiado lento (velocidad). En el caso de PoS, al ser eficiente energéticamente, el cuello de botella se manifiesta en términos de sobrecarga de comunicación.

Los validadores necesitan intercambiar conjuntos de mensajes constantemente para atestiguar cómo deben considerarse válidos los bloques. A medida que el número de validadores aumenta para incrementar la descentralización, también lo hace el número de mensajes (exponencialmente). Este «chatter» (tráfico de mensajes) puede sobrecargar la red. Optimizar el algoritmo de consenso para que escale cómodamente a miles de validadores sin reducir la velocidad de las transacciones a un ritmo ínfimo es una tarea titánica. Utiliza matemáticas exóticas y técnicas de «agregación de firmas» (similares a las firmas BLS) para condensar miles de votos en un único y diminuto fragmento de datos. Además, la «finalidad» de una transacción —la garantía de que es irrevocable— también tiende a ser probabilística.

En muchas cadenas, hay que esperar un número determinado de bloques para tener la certeza absoluta. Este desfase temporal se debe a la convergencia del consenso de la red. Es una característica de seguridad, no un error, pero puede parecer un cuello de botella para el usuario que espera la confirmación. Además, el problema del «Nothing at Stake» (nada en juego) de los primeros diseños de PoS hizo necesarios complicados mecanismos de «slashing» para penalizar las conductas indebidas, lo que añadió aún más lógica a procesar en cada bloque. Otro cuello de botella oculto es la “diversidad de clientes”. Cuando todos ejecutan el mismo cliente de software (por ejemplo, Geth), un solo error puede derribar toda la red. Es importante fomentar la diversidad del ecosistema en cuanto a los clientes para proporcionar resiliencia, pero esto añade mucha carga de desarrollo.

El impuesto oculto: MEV y los cuellos de botella de ejecución

La Máquina Virtual (VM): Este es el entorno de ejecución para los contratos inteligentes. La Ethereum Virtual Machine (EVM) es la norma, pero inicialmente no fue diseñada para operaciones paralelas de alto rendimiento. Recibe las transacciones una a una y las procesa en el orden en que se reciben. Si una transacción es realmente complicada y tarda una eternidad en procesarse, todos los demás tienen que esperar en fila. Esto equivale a una sola fila de caja en un supermercado. Las blockchains contemporáneas están intentando lograr la “ejecución paralela”, en la que las transacciones que no entran en conflicto (por ejemplo, Alice pagando a Bob y Charlie pagando a Dave) pueden procesarse simultáneamente mediante diferentes núcleos de CPU. Pero a veces eso es más fácil decirlo que hacerlo. Identificar qué transacciones interfieren entre sí en tiempo real es un problema desafiante de las ciencias de la computación.

Y aparte de la velocidad de ejecución, está el cuello de botella del MEV. Dado que la mayoría de las transacciones pueden verse al ser enviadas a la mempool, bots avanzados pueden realizar front-running o ataques sándwich a las transacciones de los usuarios para lucrarse. Esto es, en efecto, un impuesto oculto para los usuarios, lo que conlleva peores tasas de intercambio y transacciones fallidas. Está inundando la red con spam de bots que luchan entre sí. La solución al MEV es uno de los problemas de gradiente en la optimización de blockchain.

Enfoques como la “separación entre proponente y constructor” (proposer-builder separation) trabajan para factorizar el determinante de manera implícita, pero sigue siendo una ineficiencia persistente que deriva en una experiencia de usuario nefasta.

El mundo fragmentado: desafíos de interoperabilidad

Con la transición al mundo multicadena, ha surgido un nuevo cuello de botella: la interoperabilidad. Hemos construido pequeñas islas de valor. Transferir activos de Ethereum a Solana o de Bitcoin a una red de Capa 2 requiere “puentes” (bridges). Estos puentes son los puntos débiles del ecosistema, vulnerables a hackeos y exploits. El “envoltorio” (wrapping) de tokens es una capa adicional de complejidad y riesgo potencial. El cuello de botella en este sentido es la ausencia de un protocolo de comunicación universal. Cada blockchain habla un idioma diferente y tiene un consenso distinto sobre el tiempo y la finalidad.

Construir un puente “trustless” (sin necesidad de confianza) —uno que no dependa de un custodio centralizado— es matemáticamente muy difícil. Requiere que una de las dos cadenas opere un “cliente ligero” (por ejemplo, para verificar cabeceras y pruebas). Esto también requiere un uso intensivo de datos y computación. Más allá de la complicación de mover liquidez entre cadenas, esto fragmenta el mercado y lo vuelve ineficiente. Los usuarios se quedan atrapados en una cadena sin una forma sencilla de recargar Energía en la red TRON y mover sus activos hacia donde se encuentre el mejor rendimiento, a menos que naveguen por una red de protocolos complicados y propensos a riesgos. Además, la “componibilidad atómica” —la idea de que puedo transaccionar con múltiples protocolos a la vez en una sola transacción— se pierde al moverse entre cadenas. No se puede obtener un préstamo relámpago (flash loan) en la Cadena A para arbitrar algo extraño que suceda en la Cadena B sin un riesgo y retraso considerables.

El toque humano: gobernanza y capacidad de actualización

Finalmente, el cuello de botella más frustrante de todos podría ser el humano: la gobernanza. Las blockchains son software, y el software necesita actualizarse. Pero en una red descentralizada, ¿cómo se decide cuándo y cómo se lleva a cabo la actualización?

La programación de un “hard fork”, una actualización que no es compatible con versiones anteriores, requiere el acuerdo entre los desarrolladores, quienes operan nodos en la red y los mineros/validadores, así como el consenso general de la comunidad. Si hay desacuerdo, la cadena puede cambiar de dirección, como ocurrió con Ethereum y su posterior división de cadena en lo que ahora son dos monedas: Ethereum y Ethereum Classic.

Este deseo de acuerdo social se interpone no solo en el camino del cambio, sino también de la innovación. Una empresa tecnológica basada en plataformas puede implementar una actualización en sus servidores en cuestión de minutos. Si una blockchain requiere seguir cualquier función f, incluso para la más mínima de las funciones, resulta imposible que la cadena adopte nuevas mejoras con rapidez. Esta “minimización de la gobernanza” es frecuentemente el objetivo, pero en los inicios, una gobernanza activa es esencial para resolver errores y mejorar el protocolo. El equilibrio entre las dimensiones de "moverse rápido y romper cosas" frente a la estabilidad y la inmutabilidad es siempre una fuente de fricción. Es lo que puede convertir algunas de las optimizaciones más cruciales, como un aumento del tamaño del bloque o incluso un cambio en el mecanismo de comisiones, en campos de batalla con carga política que ralentizan el progreso durante años.

Conclusión

Los cuellos de botella de la blockchain —escalabilidad, disponibilidad de datos, crecimiento del estado (state bloat), sobrecarga de consenso, velocidad de ejecución, MEV, interoperabilidad y gobernanza— no son límites arbitrarios. Son el subproducto de una ambiciosa aspiración de construir una computadora mundial segura, descentralizada y que no requiere confianza (trustless). Cada optimización es un compromiso (trade-off). Aumentar el tamaño del bloque perjudica la descentralización. El sharding convierte la seguridad en un desafío mucho más difícil. La ejecución paralela conlleva el riesgo de inconsistencia del estado. Así que fue increíble ver progresos propios del nivel de 2026 en rollups de Capa 2, muestreo y combinación de disponibilidad de datos, y SNARKs de conocimiento cero —por no hablar de las pruebas en general— convertidos en una realidad aquí y ahora gracias a personas que han estado pensando «fuera de lo común» durante algunos años.

Pero gracias al ingenio humano, seguimos superando, lenta pero firmemente, estas limitaciones físicas y lógicas. Sin embargo, los usuarios deben entender que la «fricción» que experimentan es el precio por operar en un sistema basado en las leyes de la física y en un consenso estricto, en lugar de la confianza en una autoridad central. Al igual que se podría necesitar Energía de TRON para costear las transacciones en una red distribuida, la industria necesita un suministro continuo de nuevas innovaciones para escalar estos sistemas a todo el mundo.

Para el caso de quienes lidian con las complejidades de obtener recursos en la red TRON, pueden utilizar herramientas como el Netts Energy Charge Bot. Los cargadores obtienen Energía para transferirla y alquilarla ($) a los usuarios al transferir tethers en Charge_bot (Telegram); de esta manera, se reducen las comisiones de las transferencias de USDT. Los usuarios solo tienen que elegir una billetera y depositar el dinero en ella en TRX; luego pueden usar la moneda intermediaria para recargar Energía durante una hora, de modo que no tengan que quemar grandes cantidades de TRX al realizar transferencias. En cierto modo, simplifica un poco el proceso: solo hay que elegir una billetera, cargarla y realizar la transferencia, y el bot también puede calcular los recursos aproximados gastados. ¡Es una herramienta pequeña pero valiosa para mejorar la experiencia de usuario en un entorno donde los recursos cuentan!