Comenzó con una publicación:

André Cronje:

Por qué L2 como cadena de aplicaciones no es razonable para los desarrolladores:

  • Casi no hay soporte de infraestructura durante la implementación, como monedas estables, oráculos y custodia institucional.

  • Falta de fundamento o soporte de laboratorio.

  • Centralizado y vulnerable a ataques.

  • Esto conduce a una liquidez dispersa y a la necesidad de depender de cadenas cruzadas.

  • Falta de comunidades de usuarios y desarrolladores.

  • Se dedica tiempo a abordar estos problemas en lugar de centrarse en la aplicación y los usuarios.

  • Reducir los efectos de la red.

  • Todavía hay largos tiempos de confirmación de transacciones (algunos proveedores no trabajarán con usted)

  • Desarrollado solo, sin apoyo de equipo.

Fuente: X

Esta experiencia me expuso a muchas recomendaciones de productos, y una en particular me llamó la atención (junto con muchos otros productos interesantes, por supuesto);

Fuente: X

Sorprendentemente, lanzaron mi propia cadena de aplicaciones en tan solo unos minutos.

Fuente: X

Esto fue muy emocionante para mí desde una perspectiva técnica porque había muchas soluciones nuevas a las que no había estado expuesto antes y siempre estoy interesado en aprender nuevas tecnologías, así que comencé a profundizar en ellas.

La idea de tener su propia pila de tecnología, incluidas monedas estables nativas, oráculos, sistemas de prueba, efectos de red, cadenas cruzadas e interoperabilidad, suena realmente buena.

Esto suena poco realista (pero no del todo), así que comenzaré con los que considero los dos mayores obstáculos: la emisión nativa de monedas estables y los oráculos confiables. Pasar por este proceso con el reciente lanzamiento de Sonic (y gastar más de 5 millones de dólares en él) me hizo darme cuenta de lo humillante y ligeramente vergonzoso que sería obtener todo esto gratis.

De las muchas recomendaciones, noble.xyz es la que más me interesa porque afirma proporcionar USDC y CCTP nativos para cualquier cadena habilitada para IBC. En primer lugar, este es un producto genial, pero no es un USDC o CCTP nativo, sino un puente para emitir activos a través de su blockchain y luego transferirlos a otros a través de IBC (la versión de interoperabilidad del ecosistema Cosmos, que es excelente). Cadena de integración. No es automático, no es gratuito y no es nativo ni CCTP.

Dicho esto, también podemos mirar otras soluciones como LayerZero y AcrossProtocol, que son excelentes protocolos. Trabajamos mucho con LayerZero y son excelentes y recomendaría ampliamente a cualquier cadena que trabaje con ellos, pero esta todavía no es una versión local. Sé que esto es quisquilloso, pero después de experimentar varios problemas con los puentes, nada supera a la distribución local en términos de confianza y escala. Si desea distribución local, necesita tener los fondos listos.

Por parte de Oracle, recibí recomendaciones para skipprotocol, storkoracle y redstone_defi, pero desafortunadamente ninguno de estos productos es plug-and-play y requiere integración, y no estoy seguro de si habrá algún costo adicional. Aquí creo que es necesario discutir la cuestión de la escala. Mi suposición es que cualquiera que quiera ser L1 o L2 quiere estar entre los 50, 20 o 10 primeros (ya sea por volumen, total bloqueado o capitalización de mercado). Sin embargo, esto no siempre es así y algunas aplicaciones no necesitan ser tan grandes. Experimenté esto con la red Keep3r, donde todos esperaban que fuera otro Yearn, pero nunca fue la intención. Yearn es similar a una empresa de gestión de activos, mientras que Keep3r es una herramienta de operación y mantenimiento especializada. Los dos no necesitan los mismos criterios de evaluación. Entonces, este post no es para devaluar estos productos, como dije, todos son excelentes, pero si hipotéticamente lanzas una cadena de aplicaciones L2 o L1 para competir con Arbitrum, Optimism, Solana, Avax, etc., estos El plan no parece ser lo suficientemente completo.

A continuación, hablemos de las herramientas de desarrollo y las billeteras, que son compatibles con cualquier cadena nueva, pero los usuarios y desarrolladores deben configurar manualmente esos RPC. Si bien esto no es gran cosa, agrega cierta fricción innecesaria.

Por último, está el navegador de bloques, hay que mencionar Blockscout, es el referente de los navegadores gratuitos. No hay mucho más que decir, son excelentes. Sin embargo, los productos pagos como etherscan tienden a tener una ventaja porque cuentan con equipos pagos dedicados.

Por supuesto, esto no resuelve el problema de la interoperabilidad o los efectos de la red. Tomando a Unichain como ejemplo, si Uniswap es la única aplicación en la cadena (aunque supongamos que es poco probable), ¿cuál será su volumen de transacciones? ¿Qué parte del volumen es arbitraje con otras AMM, qué parte es liquidación de posiciones en los mercados monetarios y qué parte es otra actividad de préstamos urgentes incobrables? De forma aislada, las tarifas de transacción se reducen y la componibilidad y la interoperabilidad son las que ayudan.

Leí un poco sobre clusters e hipercadenas y admito que o no lo entendí completamente (lo cual es probable) o realmente no tiene sentido en la práctica.

Ahora bien, la última frase, en realidad no tiene sentido. Ser capaz de poner en marcha tu propio L1 o L2 en minutos, completo con navegador, RPC, cadena cruzada y más, es realmente sorprendente. ¿Pero es realmente práctico?

Tomando a Unichain como ejemplo (lo siento, he estado siguiendo a Unichain, creo que podrían ser una de las pocas excepciones porque tienen enormes efectos de red, pero síganme en este ejemplo), construyen esta cadena. Una razón importante es para valor de captura. Echa un vistazo a esta publicación:

Fuente: X

Sólo Uniswap en Ethereum generó 2.439 millones de dólares en tarifas de gas para los validadores. Esto no incluye la extracción MEV (que como secuenciadores pueden capturar). Estos 2.500 millones de dólares podrían haberlos ganado el propio Uniswap, pero en su lugar fueron a parar a los validadores. Este es un número muy grande.

Entonces, ¿qué pasaría si pudiéramos resolver este problema de manera más práctica sin ejecutar nuestra propia cadena, navegador, proveedor de RPC, o instruir a los usuarios y desarrolladores para que configuren RPC en billeteras y herramientas de desarrollo, o integrar oráculos y monedas estables locales? ¿Cuál es el problema que queremos resolver? La verdadera idea es recuperar el valor para la aplicación, en lugar de que la red se lo quite. ¿No existe una solución sencilla para esto? En nuestra economía creadora, ¿no se ha resuelto básicamente este problema? La respuesta es el reparto de ingresos. Plataformas como YouTube, Twitch y X brindan a los creadores una parte de los ingresos. Entonces, ¿no sería una solución más práctica distribuir estos costos de gas a la aplicación?

Pregunto, ¿qué otras razones prácticas existen? Por supuesto, el problema de la baja latencia se ha resuelto básicamente mediante cadenas de bloques modernas (como Sonic, Avax, suponiendo que necesite EVM, Solana SVM, Sui MoveVM). Nuestro rendimiento también es lo suficientemente alto como para que la mayoría de las cadenas que acabo de mencionar sean más eficientes que la Capa 2 actual. Entonces, si el problema no es la velocidad ni el rendimiento, entonces debe ser la captura de valor. ¿Quién puede culparlos? Las tarifas de clasificación son el nuevo modelo de ingresos (básicamente, guardar todas las tarifas de la red para usted en lugar de compartirlas con validadores de extracción de valor descentralizados, es broma, en realidad me gustan los validadores).

Entonces, reparto de ingresos, ¿verdad? De esta forma se solucionan todos los problemas y se obtienen todos los beneficios.

La cadena de aplicaciones parece una solución de ingeniería que existe para resolver problemas. No me malinterpretes, al experto en tecnología que hay en mí le encanta, pero como desarrollador real, no puedo evitar preguntarme: ¿por qué diablos?

[Descargo de responsabilidad] Existen riesgos en el mercado, por lo que la inversión debe ser cautelosa. Este artículo no constituye un consejo de inversión y los usuarios deben considerar si las opiniones, puntos de vista o conclusiones contenidas en este artículo son apropiadas para sus circunstancias particulares. Invierta en consecuencia y hágalo bajo su propio riesgo.

  • Este artículo se reproduce con permiso de: (Shenchao TechFlow)

  • Autor original: André Cronje