Blockchains de Capa 3: ¿Solución de escalabilidad o 'branding' manipulador?

Las blockchains de Capa 1 fueron en su origen grandes plazas públicas. Bitcoin era una plaza de liquidación sobria, austera y sin adornos, rígida e implacable. Ethereum aportó la programabilidad a la ecuación, y de pronto apareció una plaza pública donde era posible construir plataformas de emisión de tokens, exchanges, juegos, protocolos de préstamos, marketplaces de NFTs, DAOs, mercados de predicción y maquinaria financiera que solo tenía sentido en presencia de abogados.

Pero lo que tienen las plazas públicas es que atraen a la gente.

¡En los inicios, eso era una ventaja! La actividad en la cadena era señal de vitalidad, y todos —desde desarrolladores hasta mineros, inversores y fundadores— querían que esa vitalidad creciera. Querían que su rincón del internet cripto fuera el lugar donde se liquidara el valor. Nadie quería que su plaza on-chain estuviera vacía. La congestión era una insignia de honor, al menos al principio, una prueba de que el mundo se había fijado en ellos.

La congestión no tardó en convertirse en una carga. Los usuarios de Ethereum conocen de sobra el mal trago de pagar comisiones exorbitantes para que se procese una transacción. Es mucho más probable que el usuario promedio cierre la pestaña del navegador si tiene que pagar $500 por transferir unos pocos NFTs o una cantidad modesta de tokens. Durante los mercados alcistas, la jerarquía social en la cadena se invierte: las ballenas siguen moviendo enormes sumas de valor, mientras el resto observa el oráculo del precio del gas y se retira.

Y así, los primeros indicios de escalar la Capa 1 aparecieron, no en un 'white paper' o en una nota de investigación, sino en las mentes y corazones de desarrolladores, usuarios, inversores y protocolos.

Todos ellos sufrieron el problema a su manera. Los usuarios finales estaban frustrados porque su actividad on-chain recibía un gravamen desmedido. Los desarrolladores solían quedarse impotentes ante los costes crecientes, incapaces de subsidiar a sus usuarios y limitados en su capacidad de construcción. Los inversores contemplaban con desánimo cómo los costes de infraestructura asfixiaban la demanda. Y los creadores de protocolos estaban molestos porque sus soluciones se comparaban en una relación de valor contra coste y todo el sistema tenía que justificarse en función de los costes ahorrados por un competidor. Todo el mundo tenía incentivos para ampliar las tuberías, y cada voz fue escuchada en el desarrollo de soluciones de escalabilidad alternativas.

Las cadenas de Capa 1 optaron por desarrollarse sobre sí mismas, prometiendo un mayor rendimiento a menores costes —aunque no siempre—, o bien buscaron redefinir la velocidad y la eficiencia como propuestas de valor en sí mismas. Ethereum eligió esto último: una versión más limpia de sí misma en la capa base mientras la mayor parte de la acción on-chain sucedería en otro lugar. Una ficción cortés, quizás, pero no del todo deshonesta, ya que era cierto que las capas superiores funcionaban, en muchos aspectos, como un anexo a la cadena principal.

La Capa 2 no fue un accidente

El auge de las redes de Capa 2 tampoco fue fruto de la casualidad. Nadie quería renunciar al prestigio percibido y la seguridad de Ethereum, pero todos querían una infraestructura más barata para su rincón particular de la economía de las aplicaciones, y los rollups fueron el punto de encuentro. Al procesar las complejas transacciones on-chain en otro sitio y dejar que los smart contracts resolvieran las diferencias de forma verificable, los desarrolladores y usuarios podían disfrutar de lo mejor de ambos mundos. La reputación de Ethereum se mantuvo intacta mientras los demás se beneficiaban de transacciones más baratas y rápidas con menos complicaciones.

Fue una solución tanto política como técnica. Ethereum no tuvo que convertirse en Solana y los desarrolladores no tuvieron que huir del ecosistema. Las firmas de capital de riesgo no tuvieron que admitir que la demanda de aplicaciones cripto había quedado por debajo de sus altas expectativas, mientras que los usuarios pudieron seguir creyendo en la promesa de descentralización y apertura de Ethereum a la par que disfrutaban de transacciones más rápidas y tarifas más baratas. Todos mantuvieron su narrativa y todos obtuvieron lo que querían.

Optimism, Arbitrum y Base, además de otros rollups basados en tecnología optimistic o de zero-knowledge, junto con zkSync, Starknet y las diversas iniciativas de escalabilidad de Polygon —e incluso la concepción general del sector sobre lo que representa una Capa 2—, se fundamentaron en esta visión compartida del problema y en esta solución particular. Más allá de los detalles técnicos sobre pruebas de fraude, pruebas de validez, entornos de ejecución, capas de liquidación y cadenas de liquidación, cada actor del espacio coincidía en las líneas generales del problema y la solución. Los desarrolladores que construían sobre Ethereum querían maximizar su rendimiento de transacciones, pero también reducir al mínimo los costes y quebraderos de cabeza para sus usuarios finales. En otras palabras, todos querían lo que tienen hoy en Base, Optimism, Arbitrum, etc.: una cadena de liquidación con transacciones más baratas y rápidas que, de algún modo, siguiera haciéndose pasar por Ethereum.

La Capa 2 tenía todo el sentido como respuesta a la congestión de la primera capa y al consecuente disparo de las tarifas. Y esa es, en parte, la razón por la que ahora hablamos de una Capa 3: porque la Capa 2 resolvió el problema de la congestión en la primera capa y todo el mundo ya tiene la vista puesta en el siguiente nivel de escalabilidad.

La propuesta de la Capa 3

Una Capa 3, al menos según el discurso oficial, consta de blockchains específicas para aplicaciones ('appchains') construidas sobre redes de Capa 2. En otras palabras, aplicaciones concretas pueden forjarse su propio nicho dentro del ecosistema más amplio. Un juego no necesita ejecutarse en el mismo entorno que una plataforma de redes sociales, y un protocolo de préstamos no comparte su capa de liquidación con un mercado de predicción. Una plataforma de fidelización podría desear su propio token de gas, mientras que un 'shooter' competitivo podría requerir su propia capa de liquidación para procesar transacciones de alta frecuencia. Una aplicación empresarial podría dar prioridad a la privacidad, la gestión de permisos y un rendimiento predecible, mientras que un exchange de derivados buscaría tiempos de bloque más rápidos y menores latencias para sus libros de órdenes.

Un ecosistema tan diverso como el cripto necesita una capa de liquidación tan polifacética como Ethereum, argumenta la propuesta. Sin embargo, los desarrolladores y usuarios de aplicaciones específicas no quieren compartir sus smart contracts, wallets, tokens de gas, puentes ni disponibilidad de datos con nadie más. Todos quieren una Capa 3.

Arbitrum Orbit y el ZK Stack de zkSync ofrecen un vistazo al futuro: uno en el que los desarrolladores pueden construir sus propios ZK-Rollups u Optimistic Rollups personalizados, cada uno con su propio token de gas, soluciones de disponibilidad de datos, estructuras de gobernanza, supuestos de liquidación, rendimiento y características de desempeño. Arbitrum Orbit, por ejemplo, permite a los desarrolladores crear sus propias cadenas sobre Arbitrum One o Nova, con opciones de personalización que van desde la capa de liquidación hasta la disponibilidad de datos. El vocabulario es sumamente atractivo, como cabe esperar de un sector que vive y muere por la financiación del capital de riesgo —rendimiento dedicado, desempeño específico para la aplicación, gas tokenizado, UX mejorada, todo con la comodidad de disponer de una cadena propia—, pero las realidades económicas y técnicas subyacentes son difíciles de ignorar. Un rollup construido sobre otro rollup puede ser lo que todos necesitan, o bien el inicio de una pendiente resbaladiza.

Algunas de las motivaciones están claramente explicadas, mientras que otras son más difusas. Los usuarios finales no se preocupan por las capas en sí, pero a menudo son muy conscientes de los costes y beneficios a nivel de UX. El desarrollador de un juego podría estar dispuesto a asumir mayores costes de infraestructura a cambio de una mejor retención de usuarios, pero ese mismo desarrollador podría preferir que sus usuarios ignoren que operan en un entorno de liquidación alternativo. Dicho de otro modo, una Capa 3 es fantástica siempre que los usuarios no tengan que pensar en ella. Si la UX del juego es suficientemente buena, el jugador casual puede ni siquiera percatarse de que existe una diferencia entre una Capa 1 y una Capa 3.

La propuesta para los desarrolladores es similar pero con más matices: en teoría, un rollup soberano y específico para una aplicación ofrece pura potencia, rendimiento y capacidad de procesamiento, con pocas distracciones para el protocolo en sí; en la práctica, el desarrollador tiene que ocuparse de cada uno de los aspectos de la infraestructura y las operaciones, desde la seguridad del puente hasta la UX de la wallet, la capacidad de actualización y los costes de transacción. Un desarrollador que construye sobre Ethereum sabe que comparte el mismo entorno de liquidación con todos los demás, lo cual sirve de recordatorio de que solo es un engranaje dentro de una máquina inmensa; no obstante, la soberanía acarrea su propio conjunto de cargas.

La propuesta para las empresas resulta más compleja. Trata sobre rendimiento, pero también sobre posicionamiento: a todo el mundo le gusta una buena historia, y a los desarrolladores les encanta decirles a sus usuarios que están en su propia cadena. En el mundo del capital de riesgo, no hay demasiada diferencia entre «hemos creado un contrato interesante» y «hemos lanzado una revolucionaria Capa 3».

La empresa que descubre una nueva capa

Un día, en la sede de Moonforge Studios, una empleada levanta la vista de su almuerzo y se da cuenta de que el único juego de la empresa, sus dos proto-juegos, su token, su exhausto gestor de comunidad y su CEO —que habla demasiado sobre fosos de infraestructura— corren el riesgo de caer en el olvido en los mercados cripto. Los costes de los juegos no son desorbitados, pero tampoco favorecen el crecimiento orgánico de usuarios, y la economía del token, el comercio de objetos en NFT y las compras generales dentro del juego pasan factura al usuario medio. El equipo de producto consulta a los ingenieros sobre la abstracción del gas, las tarifas de transacción y los costes de fabricación de objetos, preguntando si una cadena a medida sería capaz de absorber parte de estos gastos mejorando al mismo tiempo la UX general del producto. Los ingenieros están deseando exponer sus propias ideas, pero el CTO no tarda en recordar a todos que deben garantizar la compatibilidad con el resto del ecosistema. El responsable de producto quiere que cada usuario pueda interactuar con el juego sin pensar en blockchains, wallets o tokens: las comisiones de gas deberían ser invisibles para él, al igual que la UX de retirada en caso de que quiera monetizar sus activos del juego. El CFO está más interesado en cómo las tarifas de la cadena podrían monetizar el juego: ¿podría el token de gas convertirse en una vía de ingresos? ¿Se podrían ajustar las 'tokenomics' del token interno para fomentar la adopción? El equipo del token quiere vincularlo todo a su propia moneda, pero el equipo de marketing prefiere hablar de una narrativa global sobre el metaverso. El CEO escucha todo esto y piensa en el impacto que tendría en la nota de prensa el anuncio del lanzamiento por parte de Moonforge de una Capa 3 de alto rendimiento para economías de fantasía on-chain.

No hay nada de malo en este caso hipotético, salvo quizás la suposición de que un juego necesite una capa de liquidación propia desde un primer momento.

Si existe suficiente demanda, una Capa 3 diseñada a medida podría servir para optimizar el rendimiento de una economía concreta al tiempo que aísla a los usuarios de los costes, riesgos y complicaciones de interactuar con el ecosistema de Ethereum en general. Los desarrolladores podrían subsidiar su propio gas, dictar sus propios términos y condiciones, y proporcionar un entorno más propicio para el éxito de su producto. En teoría, un entorno de liquidación adaptado y específico para la aplicación podría mejorar la experiencia de todos los involucrados.

Pero, ¿y si esa demanda no existe? ¿Qué ocurre si un token a medida, al igual que una economía de tokens personalizada, no logra tracción? ¿Qué pasa si la promesa de un rollup soberano se utiliza como excusa para engrosar la base de usuarios mediante promociones superficiales antes de haber creado un valor real? ¿Y si el deseo de construir una infraestructura de UX autónoma y de alto rendimiento es solo una cortina de humo para posicionar el proyecto como algo moderno, innovador y visionario? ¿Y si una Capa 3 no es lo que el producto realmente necesita?

Todo depende de quién formule la pregunta. Una empresa que construya el entorno de liquidación para el juego, la aplicación de redes sociales, el paquete corporativo o el DEX de derivados puede tener prioridades muy distintas a las de un equipo de protocolo que lance un producto en dicho entorno. Para la empresa, una cadena personalizada es una declaración de intenciones; para el equipo del protocolo, supone un obstáculo para la adopción y una ofensa al espíritu de Ethereum. Una empresa que cree su propia wallet, secuenciador, puente, token de liquidación, disponibilidad de datos, mecanismo de gobernanza y capa de UX intentará convencer a sus usuarios de que todo gira en torno a una experiencia fluida, cuando en realidad se trata de diferenciación, posicionamiento y atractivo para el capital de riesgo.

Donde la palabra de moda se desmorona

Existen razones de peso por las que las redes de Capa 3 pueden fracasar, o al menos rendir por debajo de lo esperado. La primera tiene que ver con la complejidad, tanto a nivel técnico como político.

Las capas de liquidación liquidan, pero también deben gestionar una lista interminable de servicios secundarios: disponibilidad de datos, compatibilidad con wallets, puentes, nodos RPC, exploradores de bloques, indexación, monitorización, pruebas de fraude, actualizaciones, fijación del precio del gas, etc. Si un entorno de liquidación específico para una aplicación resulta demasiado complejo de operar, monitorizar y mantener, fracasará. Si el propio protocolo —y por extensión, la empresa que lo respalda— no puede absorber estos costes, fracasará. Dicho de otro modo: dotar a tu aplicación de su propia capa de liquidación no es una salida fácil. De hecho, es una de las vías más complicadas para construir un negocio sostenible en el sector cripto. Si ya es difícil operar un rollup, construir un rollup sobre otro rollup supone un reto por las razones equivocadas.

La principal debilidad de una Capa 3 radica, sin embargo, en su herencia de seguridad, que a menudo ignora las realidades prácticas del mantenimiento de una cadena. Las capas de liquidación se liquidan sobre otras capas de liquidación, las cuales a su vez se liquidan sobre Ethereum. Con frecuencia da la sensación de que todos quieren una Capa 3 porque buscan disfrutar de los beneficios de la seguridad de Ethereum esquivando los costes de su finalidad de liquidación. Por definición, cada capa adicional suma más supuestos al modelo de seguridad, más vectores de ataque y más oportunidades de cometer errores. Una capa de liquidación construida sobre una L2 es vulnerable, a su vez, a los mismos riesgos que una Capa 2: pruebas de fraude, riesgos de publicación de datos, censura por parte de los secuenciadores y centralización en la gestión de claves. Esos mismos riesgos se trasladan a una capa de liquidación construida sobre una cadena de Capa 3. Si la seguridad de la cadena es cuestionable o sus premisas son defectuosas, los usuarios sufren las consecuencias. En la práctica, esto suele traducirse en una menor seguridad en las wallets, una peor UX en los puentes, un modelo de gobernanza on-chain inseguro, una estrategia de disponibilidad de datos poco fiable, una monitorización y auditoría insuficientes y un proceso de resolución de disputas problemático.

Los problemas de infraestructura de Degen Chain sirvieron como una valiosa lección para el ecosistema. Concebida como una Capa 3 rápida, de bajo coste y orientada a la comunidad, conectada a Base a través de las herramientas de Arbitrum Orbit, atrajo a usuarios que buscaban una alternativa a la UX de Ethereum, conocida por ser lenta y devoradora de gas. En el momento del incidente, la mayoría de los usuarios desconocía en gran medida los entresijos técnicos sobre el funcionamiento de la Capa 3; sin embargo, en cuanto surgieron los fallos de infraestructura —una actualización con pruebas deficientes por parte de un proveedor de infraestructura que causó tiempos de inactividad, corrupción de estado y pérdida de activos—, no tardaron en culpar al equipo por la migración, la seguridad del puente y el robo de gas. En su nivel más elemental, los problemas reflejaban una falta de comprensión sobre cómo operaba la seguridad de los puentes y de la liquidación. Los usuarios con un perfil más técnico —aquellos familiarizados con las herramientas de Arbitrum Orbit, la cadena de liquidación de Base y la propia prueba de concepto de Degen Chain— se mostraron más escépticos ante las afirmaciones que garantizaban que la Capa 3 era segura, disponible y fiable. En la práctica, parece que muy pocos comprendían que sus claves no eran las únicas: el proceso de migración y verificación de la raíz de estado había dependido de un amplio número de entidades externas de confianza, ninguna de las cuales —a ojos de muchos— resultaba especialmente fiable.

Esto no es necesariamente una crítica hacia Degen Chain; es la constatación de que muy pocos comprenden cómo funciona una infraestructura de liquidación de Capa 3, y de que construir una es sumamente complejo desde el punto de vista técnico y operativo. Los inconvenientes en Degen Chain no distaron de los problemas vistos en otras fases iniciales de cadenas de Capa 2, con la salvedad de que casi nadie percibe hasta qué punto una capa de liquidación de Capa 3 depende de entidades externas de confianza para operar, monitorizarse y mantenerse. Es difícil anticipar con certeza cuáles eran los riesgos a largo plazo, pero sí es posible proyectar los de corto plazo. Una cantidad de usuarios, liquidez o desarrolladores inferior a la prevista sería perjudicial para el futuro de una capa de liquidación, especialmente cuando la pugna por la misma audiencia es feroz. Un soporte deficiente de wallets o una liquidez escasa supondrían una carga añadida para un entorno incipiente. Peor aún: un fallo operativo podría dinamitar la confianza en Degen Chain y, por consiguiente, en las herramientas subyacentes de Arbitrum Orbit. Cualquiera de estos problemas, o una combinación de ellos, perjudicaría a una joven Capa 3.

Otra flaqueza de un entorno de liquidación a medida es el aislamiento de la liquidez, un desafío operativo que rara vez se menciona en debates teóricos. El problema se produce porque la mayoría de las cadenas de Capa 3 de menor tamaño no lograrán reunir la liquidez suficiente para respaldar a sus usuarios. Los activos en estas cadenas pueden contar con una tokenomía deficiente, carecer de puentes nativos hacia otras cadenas o hacia otras Capa 3, adolecer de falta de soporte en wallets o no disponer de datos on-chain accesibles para exploradores de bloques estándar. En otras palabras, una cadena de liquidación de Capa 3 con pocos usuarios y escasa liquidez puede verse en la indeseable situación de desincentivar una mayor provisión de liquidez y adopción. Los desarrolladores también pueden calcular mal el grado de fricción en la UX que sus usuarios están dispuestos a asumir a cambio de un entorno centrado en una sola aplicación. En la práctica, esto deriva a menudo en una cadena teóricamente capaz de soportar millones de transacciones por segundo pero incapaz de atraer a un solo usuario debido a su precaria integración con la infraestructura existente y a una tokenomía poco competitiva.

Cadenas reales y resultados reales

Los argumentos más sólidos a favor de una Capa 3 se encuentran en el sector de los videojuegos y las aplicaciones sociales, donde el valor obtenido por cada transacción es bajo pero el volumen resulta masivo. Xai, una infraestructura para juegos basada en ZKP y desarrollada sobre Arbitrum Orbit, es el claro ejemplo de un entorno de liquidación diseñado para juegos. Creada para permitir que los juegos adopten la propiedad de activos sin tener que cargar con los costes de UX de una cadena compartida, ha registrado una adopción considerable en títulos como The Lost Glitches y Tollan Universe, con millones de transacciones registradas en su Ecosystem. El mismo razonamiento se aplica a las cadenas Apex y Boss de Proof of Play, concebidas igualmente para videojuegos y que han propiciado el crecimiento de aplicaciones como Pirate Nation y otros títulos 'play-to-earn' on-chain. El valor capturado por transacción en los juegos es reducido, pero la frecuencia es excepcionalmente alta en comparación con otras aplicaciones cripto nativas, por lo que aislar los costes de gas y la fricción general de la UX resulta muy valioso tanto para los creadores como para los jugadores.

Degen Chain, por su parte, personifica la justificación de los tokens sociales para una capa de liquidación a medida. Al ser una cadena desarrollada sobre Arbitrum Orbit, ha experimentado una explosión en su adopción por parte de proyectos nativos de Farcaster y de desarrolladores que buscan una alternativa a los costes de UX de Ethereum para microtransacciones y actividad de NFTs. No obstante, su futuro se presenta incierto y complicado a causa de sus problemas de infraestructura y de una base de usuarios relativamente pequeña. Aun así, ha demostrado que un entorno de liquidación de Capa 3 posee un atractivo potencial para usuarios, programadores e incluso organizaciones de mayor envergadura que prefieren trasladar sus operaciones a otra parte sin renunciar a las garantías de seguridad de Ethereum.

Lo mismo cabe señalar respecto a ApeChain y Treasure Chain, que representan el otro extremo del espectro: comunidades muy consolidadas o ecosistemas de gaming que prefieren disponer de sus propias liquidaciones en lugar de depender de una única cadena compartida. Argumentos parecidos pueden esgrimirse en favor de Orbs, que no se promociona como una Capa 3 sino como una infraestructura entre cadenas para aplicaciones de DeFi. Busca proveer un entorno de liquidación específico para aplicaciones de DeFi pero con interoperabilidad entre cadenas, incluida Ethereum. Finalmente, las cadenas con ZK Stack y el concepto general de la Elastic Network representan la visión opuesta: un ecosistema de ZK-Rollups interconectados con una capa de liquidación compartida, ofreciendo prestaciones especializadas por cadena y no por desarrollador.

Pensamiento crítico más allá de la infraestructura

No hay nada de malo en un entorno de gas a medida. Sin embargo, es vital recordar que la mayoría de los usuarios del mundo cripto no tiene ningún interés en que se les imponga uno, en especial si su contacto con la tecnología blockchain se limita a una sola aplicación. A los usuarios les importa la experiencia que les brinda el producto, no los cimientos técnicos ni el posicionamiento de la empresa responsable. Si una wallet les obliga a completar un engorroso proceso de retirada en varios pasos cada vez que desean transferir o liquidar sus tokens, difícilmente calificarán la transacción de fluida o práctica, sin importar cuánto presuma la empresa detrás de la wallet de su extraordinaria UX de liquidación. Y lo que es más importante: cualquier compañía que ensalce las virtudes de su propia infraestructura debería tener presente que la financiación de capital riesgo y el 'hype' rara vez son el antídoto adecuado para subsanar un mal diseño de producto.

Los entornos de liquidación de Capa 3 plantean un reto particular a los usuarios finales en materia de UX y captura de valor. Pero es un coste asumible en aras de un mejor diseño de producto, siempre que la empresa no olvide que sus propios puntos fuertes son los que le otorgaron el éxito inicial. Es difícil asegurar con rotundidad si un entorno de gas a medida es categóricamente superior a uno compartido para cualquier aplicación; lo que sí es indiscutible es que ninguna empresa gana nada presentando una u otra opción como el santo grial de la industria cripto.

Ahí es donde el Netts Pricing resulta sumamente práctico en el día a día: permite consultar cuáles son los precios actuales de TRON Energy para poder comprar TRON Energy, buscar el mejor precio de TRON Energy y realizar un análisis de coste-beneficio entre ofertas económicas de TRON Energy antes de realizar una transferencia de USDT y consumir TRON Energy. En otras palabras, la elección de las comisiones se transforma en un valor transparente antes de iniciar la transacción.