Título del Artículo Original: ¿Cuál es el siguiente paso para Solana | Anatoly Yakovenko

Traducción Original: Ismay, BlockBeats

Nota del Editor: La semana pasada, SOL superó los $248, estableciendo un nuevo segundo precio histórico desde el Thunderbolt de FTX, a solo un 4% de la alta histórica del 6 de noviembre de 2021 de $259. El podcast Lightspeed invitó al cofundador de Solana Labs, Anatoly Yakovenko y al CEO de la empresa Solana RPC Helius, Mert, para profundizar en las tarifas de transacción de Solana, cómo mantenerse competitivo en el campo de las criptomonedas, la inflación de SOL, la competencia con Apple y Google, si Solana tiene una ventaja competitiva, y otros temas.

Directorio de Preguntas

1. ¿Por qué Solana todavía tiene tantas transacciones de front-running?

2. ¿Puede la arquitectura L2 realmente resolver problemas de congestión?

3. ¿Puede una cadena centrada en la optimización de un solo hilo realmente desafiar la ventaja de consenso global de Solana?

4. ¿Es el espacio de bloque compartido una "tragedia de los comunes" o la clave para la eficiencia de capital en DeFi?

5. ¿Cuál es la competitividad central de Solana?

6. ¿Disminuirá la tasa de inflación de Solana?

7. ¿Es demasiado alto el costo de desarrollo integral de FireDancer?

8. ¿Cómo compite Solana con Ethereum?

1. ¿Por qué Solana todavía tiene tantas transacciones de front-running?

Mert: Entonces, comencemos, Anatoly, empecemos desde cero. Una de las razones por las que fundaste Solana es porque estabas cansado de ser superado en los mercados tradicionales. Querías lograr a través de Solana la sincronización de información globalmente a la velocidad de la luz, maximizando la competencia, minimizando el arbitraje, pero nada de esto se ha logrado hasta ahora, casi todos están siendo constantemente superados. No solo el MEV se ha disparado, sino que la propina de Jito a menudo ha superado la tarifa de prioridad de Solana. ¿Cómo ves este problema? ¿Por qué está sucediendo esto?

Anatoly: Puedes configurar tu propio nodo validador y enviar tus transacciones sin interferencia de otros, ¿verdad? En los mercados tradicionales, no tienes esa opción en absoluto, y aquí es exactamente donde entra en juego la funcionalidad de descentralización de Solana, que de hecho funciona.

El desafío actual radica en que configurar un nodo validador no es fácil. No es simple hacer que un nodo apueste lo suficiente para alcanzar una posición significativa, y es aún más difícil encontrar otros nodos dispuestos a ordenar transacciones de la manera que esperas. Sin embargo, todo esto es alcanzable; solo requiere tiempo y esfuerzo. El mercado actual no está lo suficientemente maduro como para tener competencia suficiente. Por ejemplo, la competencia entre Jito y sus competidores no es lo suficientemente fuerte como para permitir que los usuarios elijan fácilmente entre "solo envío a creador de flujo de órdenes Y, no a creador de flujo de órdenes K."

A un nivel fundamental, como entusiasta, puedo lanzar mi propio nodo validador, apostar una cantidad, ejecutar mi algoritmo y enviar mis transacciones directamente. Nadie puede detenerme de hacer esto; todo es posible. La verdadera pregunta ahora es si hemos madurado hasta un punto en el que los usuarios siempre pueden elegir la mejor manera de enviar transacciones. Creo que estamos lejos de alcanzar esa etapa.

En mi opinión, el método para lograr este objetivo es en realidad simple pero increíblemente desafiante: aumentar el ancho de banda, reducir la latencia, optimizar la red tanto como sea posible, eliminar cuellos de botella que hagan que el sistema sea injusto, incluyendo mecanismos con múltiples proponentes de bloques paralelos. Si hay un solo líder por ranura, y tienes un 1% de participación, tendrás aproximadamente una oportunidad cada 100 ranuras. Pero si hay dos líderes por ranura, y tienes un 1% de participación, tendrás aproximadamente una oportunidad cada 50 ranuras. Por lo tanto, cuanto más líderes podamos agregar, menos participación necesitarás, permitiéndote operar tu algoritmo con la calidad de servicio que requieres.

Alguien creó un sitio web llamado el Mapa de Ruta de Solana. Al abrirlo, muestra "Aumentar el Ancho de Banda, Reducir la Latencia." Anatoly pregunta quién lo hizo.

Mert: Actualmente, la situación es que necesitas reunir una cierta cantidad de participación para priorizar el procesamiento de tu transacción, incluso si no es así. Parece que tener más participación en el sistema no solo ayuda a obtener tu propio espacio de bloques, etc., sino que hay una relación dinámica aquí: cuanto más rico eres, mayor es tu ventaja, ¿es esto aceptable?

Anatoly: Las mejoras de rendimiento disminuyen la barrera para que los participantes honestos cambien la dinámica del mercado. Si tenemos dos líderes por segundo, la cantidad apostada necesaria para proporcionar el mismo servicio se reduce a la mitad, disminuyendo así la barrera económica de entrada, permitiendo que más personas compitan. Se puede decir: "Oye, soy el mejor validador; deberías enviar todas las transacciones de Jupiter a mí, y haré lo que quieras." De esta manera, puedo operar un negocio, ofrecerlo a los usuarios, y la competencia forzará al mercado a alcanzar el punto de equilibrio más justo. Ese es el objetivo final.

Sin embargo, para lograr este objetivo, creo que una diferencia significativa entre Solana y Ethereum es que creo que esto es solo un problema de ingeniería. Solo necesitamos optimizar la red, aumentar el ancho de banda, por ejemplo, más líderes por segundo, aumentar el tamaño del bloque, todo escala hasta que la competencia obligue al mercado a alcanzar un estado óptimo.

2. ¿Puede la arquitectura L2 realmente resolver problemas de congestión?

Mert: Hablando de un problema de ingeniería, la razón por la que la propina de Jito supera la tarifa de prioridad no solo se debe a MEV, sino también al proceso de aterrizaje de transacciones, o más precisamente, la operación del mercado de tarifas local no siempre funciona de manera determinista, a veces es simplemente inestable. ¿Cuál es la razón de esto?

Anatoly: Esto se debe a que la implementación actual del procesamiento de transacciones está lejos de ser óptima. En escenarios de carga muy alta, funciona sin problemas cuando la carga es baja. Durante el mini mercado bajista en los últimos seis meses, he visto tiempos de confirmación de menos de un segundo de principio a fin, y todo funciona muy bien porque el número de transacciones enviadas al líder es mínimo. Estas colas, listas de acceso rápido y otros recursos no están llenos, y no hay acumulación de colas debido a cuellos de botella de rendimiento.

Cuando estas colas están congestionadas, no puedes priorizar estas colas antes del programador, lo que interrumpe el mercado de tarifas local. Así que, en mi opinión, este también es un problema de ingeniería y quizás el área que necesita más esfuerzo de ingeniería en el ecosistema actual es la optimización extrema de estos pipelines de procesamiento.

Mert: Dada la existencia de estos problemas, parece que tu respuesta es que estos problemas sí existen, pero son problemas de ingeniería y, por lo tanto, pueden ser resueltos, y las iteraciones futuras los abordarán. Algunos podrían decir que estos problemas no existen en L2 debido a su arquitectura, ¿verdad? Porque puedes lograr el primero en llegar, primero en servir a través de secuenciadores centralizados.

Anatoly: El primero en llegar, primero en servir también llevaría a los mismos problemas, incluso Arbitrum tiene canales de prioridad. Así que, si implementas primero en llegar, primero en servir, alentaría transacciones de spam, que también es el mismo problema. Si tienes un L2 de propósito general que apoya múltiples aplicaciones, eventualmente encontrará el mismo problema también.

Algunos pueden argumentar que debido a que L2 no tiene un consenso y un ecosistema verticalmente integrado como Solana, pueden iterar más rápido, como una empresa Web2 que lanza una nueva versión cada 48 horas y soluciona rápidamente problemas a través de secuenciadores centralizados. Pero aún enfrentan los mismos problemas que Solana.

Podrías decir que Jito tiene una oportunidad para abordar estos problemas porque su reenvío puede actualizarse cada 24 horas o lanzar actualizaciones continuamente. Sin embargo, lo que actualmente no están haciendo es tener suficiente programación y filtrado de datos para limitar el tráfico que proviene de estos reenvíos a lo que el programador de validadores puede manejar, pero puedes lograr un efecto similar.

Así que no creo que L2 pueda abordar estos problemas. L2 solo es efectivo cuando lanzas, solo para una aplicación popular, y solo cuando no hay otras aplicaciones alrededor para abordar el problema. Y esto ni siquiera se aplica a la propia aplicación; si tienes una aplicación con múltiples mercados, la congestión en el Mercado A afectará a todos los demás mercados.

3. ¿Puede una cadena centrada en la optimización de un solo punto realmente desafiar la ventaja de consenso global de Solana?

Mert: Veámoslo desde un ángulo diferente. Si esto no es un L2 general, sino una cadena como Atlas que se centra en DeFi y ejecuta SVM, ¿cómo competiría Solana con una cadena así? Atlas no tiene que preocuparse por la sobrecarga del consenso o los problemas de espacio de bloque compartido; puede centrarse en la optimización de DeFi e incluso lograr un mercado sin tarifas a través de SVM.

Anatoly: Lo que describes es en realidad la competitividad de Solana en un escenario de conjunto de validadores más pequeño. En este caso, solo hay un nodo, lo que es más fácil de optimizar ya que puedes usar hardware más grande. Este es el problema central: ¿Es la composibilidad sincrónica importante a gran escala? Esta red más pequeña solo puede cubrir la región donde se encuentra este hardware, por lo que la información aún necesita propagarse globalmente, y en el estado final de Solana, hay múltiples validadores capaces de sincronizar globalmente las presentaciones de transacciones de manera abierta y sin permisos.

Si se aborda este problema, el resultado final es Solana. Ya sea que los datos se envíen a L2 o no, el problema clave es cómo sincronizar la información globalmente y alcanzar consenso rápidamente. Una vez que comiences a abordar este problema, ya no es algo que una sola máquina en Nueva York o Singapur pueda resolver; necesitas alguna forma de consenso, consistencia y linealización. Incluso si más adelante dependes de L2 para garantías de liquidación más estrictas, aún enfrentarás los problemas actuales de Solana. Así que, en mi opinión, estos SVM de nodo único son básicamente no diferentes de Binance.

Cómo competir con Binance es una pregunta más interesante. Si eliges, puedes usar SVM, pero los usuarios preferirán Binance debido a su mejor experiencia de usuario. Así que necesitamos convertirnos en la mejor versión de un intercambio centralizado. Y para lograr este objetivo, la única forma es adoptar el concepto de una arquitectura descentralizada de múltiples proponentes.

Mert: Otra ventaja es que Solana misma debe abordar estos problemas, y a través de L2, pueden resolverlos más rápidamente. Es más fácil resolver problemas en una sola caja que en 1500 cajas. De esta manera, atraerán más atención y construirán efectos de red desde el principio. Independientemente de cómo lo haga Solana, necesita abordar estos problemas, y dado que utilizan la misma arquitectura, pueden aprender de ello y potencialmente lanzar más rápido.

Anatoly: El desafío de la competencia empresarial es si estas cajas individuales pueden sobrevivir bajo una cierta carga. Construir una caja única no resuelve inmediatamente todos los problemas; todavía enfrentas desafíos de ingeniería casi idénticos. Especialmente cuando consideras que la discusión ya no trata sobre la sobrecarga del consenso de Solana, sino sobre el proceso de envío de transacciones.

El pipeline de envío de transacciones en sí puede ser centralizado en Solana, al igual que en algunas soluciones L2. De hecho, Solana emplea un reenvío de caja única para recibir una gran cantidad de transacciones y luego intentar enviarlas a los validadores. La tasa de transferencia de datos entre el reenvío y los validadores puede limitarse a un nivel más bajo, asegurando que los validadores siempre puedan procesar estas transacciones sin problemas.

Además, este diseño permite a componentes como Jito iterar a un ritmo más rápido. Por lo tanto, creo que la ventaja de este diseño en L2 es en realidad menor de lo que la gente imagina.

4. ¿Es el Espacio de Bloque Compartido una "Tragedia de los Comunes" o la clave para la Eficiencia de Capital en DeFi?

Mert: Si ampliamos la discusión, Solana, como L1, involucra un espacio de bloque compartido, lo que puede llevar al problema de la "Tragedia de los Comunes", similar al uso excesivo de un recurso de piscina pública. Sin embargo, en L2, especialmente aquellos que no son necesariamente un L2 de cadena de aplicaciones, los desarrolladores pueden tener espacio de bloque independiente sin compartir con otros.

Anatoly: Esta independencia puede ser más atractiva para los desarrolladores de aplicaciones, pero este entorno necesita ser autorizado. Porque una vez que adoptes validadores o secuenciadores sin permisos, cuando múltiples aplicaciones se ejecutan simultáneamente, perderás este control.

Incluso en un entorno de una sola aplicación como Uniswap, si la plataforma tiene múltiples mercados, estos mercados pueden interferir entre sí. Por ejemplo, un token meme desconocido puede afectar la prioridad de órdenes de los mercados principales. Viéndolo desde una perspectiva de producto y imaginando un futuro donde todos los activos están tokenizados, como CEO de una empresa recién creada, decido en qué plataforma salir a bolsa. Si veo un alto volumen de comercio de SHIB en Uniswap causando una severa congestión, hasta el punto de que los activos principales no pueden comerciar correctamente, este sería sin duda un estado fallido para este L2 enfocado en aplicaciones.

Por lo tanto, los desafíos que enfrentan estos L2s enfocados en aplicaciones son similares a los de Solana, ya que todos necesitan aislar sus respectivos estados de una manera que no impacte a otras aplicaciones. Porque incluso una sola aplicación como Uniswap, si uno de sus mercados experimenta congestión causando que todos los demás mercados se vean afectados, en un entorno como este, eso es inaceptable para un CEO de una empresa como la mía. No quiero que mi mercado principal sea el tipo en el que todos están comerciando. Quiero que cada par de comercio opere de manera independiente.

Mert: ¿Pero si es autorizado, entonces? Dado que hay un mecanismo de salida, ¿no funcionaría?

Anatoly: Incluso en un entorno autorizado, aún necesitas abordar el problema de la aislamiento local. Abordar este problema de aislamiento en un entorno autorizado no es fundamentalmente diferente de abordarlo en un reenvío o programador.

Mert: ¿Crees que esta analogía de mercado puede aplicarse a cualquier tipo de aplicación?

Anatoly: Algunas aplicaciones no tienen estas características, como pagos simples entre pares con muy poca congestión y programación sencilla. Así que, el desafío de diseñar mecanismos de aislamiento y todas estas cosas aparentemente complejas radica en el hecho de que si no puedes asegurar que un solo mercado o aplicación no cause congestión global, entonces empresas como Visa introducirán su L2 de pago dedicada porque sus transacciones nunca compiten. No les importa la prioridad; solo les importa el TPS. No importa si mi deslizar de tarjeta es la primera o la última transacción en el bloque; lo que importa es que puedo irme en dos segundos y medio después de deslizar mi tarjeta. Así que, en un escenario de pago, el mecanismo de prioridad no es crucial, pero es de hecho un escenario de aplicación del mundo real muy importante.

Mi opinión es que si no podemos implementar adecuadamente los mecanismos de aislamiento, entonces la idea de una máquina de estado composable a gran escala se vuelve sin sentido, ya que verás la aparición de cadenas de pago y L2s dedicadas a mercados únicos. Imagina que soy el CEO de una empresa que sale a bolsa, ¿por qué elegiría lanzar en la cadena de Uniswap en los próximos 20 años? ¿Por qué no lanzar mi propio L2 que solo soporte mis pares de comercio para asegurar un buen rendimiento?

Este es un futuro posible, pero creo que desde una perspectiva de ingeniería, no hay razón para hacerlo a menos que haya otras razones. Si podemos resolver los problemas de ingeniería, entonces creo que lograr la composibilidad en un solo entorno tiene una gran ventaja, ya que la fricción de la transferencia de capital entre todos los estados y la liquidez puede ser enormemente reducida, lo que es una característica muy importante para mí. Creo que DeFi de Solana puede sobrevivir en un mercado bajista y soportar un golpe mayor que cualquier otro precisamente por su composibilidad, lo que hace que su eficiencia de capital sea más alta.

Mert: Vitalik afirmó recientemente que "en mi opinión, la composibilidad está sobrevalorada." Creo que probablemente llegó a esta conclusión basada en datos empíricos, creyendo que no hay demasiadas instancias en cadena utilizándola. ¿Qué opinas?

Anatoly: ¿No es Jupiter el epítome de la composibilidad? Creo que él solo se centra en Ethereum, desafortunadamente, Jupiter tiene una gran cuota de mercado en Solana y una cuota de mercado significativa en todo el espacio cripto. Para lograr la composibilidad, Jupiter es indispensable. Sin composibilidad, Jupiter no puede funcionar. Mira a 1inch, es un competidor en Ethereum, incapaz de escalar porque incluso transferir entre L2 y el mismo L1 es extremadamente costoso y lento.

Creo que se equivoca. Creo que los sistemas financieros pueden ser asincrónicos, que es cómo operan la mayoría de los sistemas financieros hoy en día. No es que estos sistemas fallarían o colapsarían por eso. Pero si Solana tiene éxito y el ecosistema aborda todos estos problemas a este ritmo actual, incluso si mantenemos el nivel de ejecución actual cada año, verías mejoras significativas. En última instancia, creo que la composibilidad surgirá como la ganadora.

5. ¿Cuál es la ventaja competitiva central de Solana?

Mert: Vamos a dejar de lado momentáneamente los problemas de ingeniería, asumiendo que la ingeniería no es una ventaja competitiva, y otras cadenas pueden lograr los mismos resultados. Por ejemplo, una cadena como Sui también podría lograr composibilidad y tener un conjunto más pequeño de validadores. Asumiendo que algunos L2 enfrentarían problemas similares a los mencionados, pero también podrían abordar estos problemas. Te pregunté antes, cuando la ingeniería ya no es la ventaja competitiva, ¿cuál es la ventaja competitiva? Dijiste que es contenido y funcionalidad.

Anatoly: Sí, Solana no estableció un objetivo específico de validadores. La red de pruebas tiene alrededor de 3500 validadores, y la red principal tiene una gran escala porque quería que fuera lo más grande posible para preparar el futuro de la red. Si deseas la mayor cantidad de productores de bloques en todo el mundo, necesitas un gran conjunto de validadores, permitiendo que cualquiera se una y participe en cada parte de la red sin permisos.

Deberías probar lo más rápido posible porque actualmente el costo de resolver estos problemas es bajo. Solana no está manejando trillones de dólares en fondos de usuarios ahora; eso es lo que hace Wall Street. Solana trata con criptomonedas, lo que nos da la oportunidad de que las personas más inteligentes del mundo resuelvan estos rompecabezas y se vean obligadas a enfrentar estos desafíos.

Así que mi punto es, en lugar de que Solana reduzca el tamaño del conjunto de validadores por rendimiento, es más probable que Sui y Aptos necesiten aumentar su conjunto de validadores. Si encuentras PMF, todos querrían ejecutar su propio nodo porque proporciona aseguramiento. A medida que crece el conjunto de validadores, si comienzas a limitar a los participantes, limitas la escalabilidad de la red.

Mert: Está bien, mencionaste un problema que quiero discutir. Aunque ese es el objetivo, si miras los datos, el número de nodos validador está disminuyendo con el tiempo. Parece que piensas que esto se debe a una falta de ajuste entre producto y mercado, por lo que no tienen la motivación para ejecutar el equipo de nodos ellos mismos, ¿verdad? ¿O cuál es la razón?

Anatoly: Sí, parte de la razón es el soporte de staking de la Fundación Solana. Pero realmente estoy interesado en saber cuántos nodos validador son autosuficientes, ¿está creciendo ese número?

Mert: Espera, tenemos alrededor de 420 nodos validador que son autosuficientes.

Anatoly: Pero, ¿cómo era hace dos años?

Mert: Puede que no tengamos esos datos. Pero sabemos que la cantidad total apostada por la Fundación Solana ha disminuido significativamente desde hace dos años.

Anatoly: Mientras que las tarifas también están aumentando. Así que mi suposición es que el número de nodos que podrían autosostenerse hace dos años era mucho menor, aunque el número total de nodos era más alto en ese momento. Así que mi punto es, necesitamos que la red escale para apoyar a todos los que quieran ejecutar equipo de nodos. Este es también uno de los principales propósitos del plan de delegación, para atraer a más personas a ejecutar nodos y poner un poco de presión sobre ellos en la red de pruebas.

Pero la red de pruebas nunca puede simular completamente las características de la red principal, ¿verdad? No importa cuántas pruebas de validador realicen en la red de pruebas, la situación de la red principal seguirá siendo bastante diferente. Así que, mientras el número de nodos autosuficientes esté creciendo, lo veo como una tendencia positiva. La red debe ser físicamente capaz de escalar para soportar tal escala, de lo contrario, limitará el crecimiento.

Mert: Entonces, básicamente, quieres decir que el mecanismo de delegación ayuda a la red a hacer pruebas de estrés en diferentes escalas de nodos validador, pero fundamentalmente, lo único importante, o lo más importante, es el número de nodos validador autosuficientes.

Anatoly: Exactamente, esto puede proponer teóricamente algunos argumentos, como la afirmación de que en un caso extremo un solo nodo puede no ser autosuficiente. Pero incluso en una falla catastrófica, si ese es el único nodo sobreviviente, realmente proporciona asistencia. Sin embargo, esto cae bajo el ámbito del problema de "descentralización en guerra nuclear" del juego final.

Fundamentalmente, lo que realmente importa es si la red está creciendo y teniendo éxito, lo que depende de validadores autosuficientes que puedan cubrir sus propias cuentas y tienen suficiente interés en la red para estar dispuestos a invertir recursos comerciales para mejorar continuamente, profundizar en los datos y hacer su trabajo correctamente.

Mert: En un mundo donde cualquiera puede ejecutar un sistema rápido, de bajo costo y sin permisos, ¿por qué la gente seguiría eligiendo Solana en el estado final?

Anatoly: Creo que el futuro ganador podría ser Solana porque este ecosistema ha demostrado una ejecución sobresaliente y ya ha avanzado en abordar todos estos problemas. O, el ganador podría ser un proyecto idéntico a Solana, pero no Solana simplemente porque ejecutó más rápido, lo suficiente para superar los efectos de red existentes de Solana.

Así que creo que la ejecución es la única ventaja competitiva. Si se ejecuta mal, serás superado. Pero el que te supera tiene que desempeñarse excepcionalmente bien para convertirse en un producto killer. PMF se refiere a Product-Market Fit, lo que significa que resulta en un cambio de comportamiento en los usuarios.

Por ejemplo, si las tarifas de transacción son diez veces más baratas, ¿los usuarios cambiarán de Solana a otro proyecto? Si los usuarios solo tienen que pagar medio centavo, puede que no. Pero si cambiarse a otro lugar puede reducir significativamente el deslizamiento, esto puede ser suficiente para atraerlos o a los comerciantes a cambiar.

De hecho, es necesario observar el comportamiento general de los usuarios para ver si hay alguna mejora fundamental lo suficientemente significativa como para hacer que elijan otro producto. Hay de hecho una diferencia entre Solana y Ethereum. Para los usuarios, cuando firman una transacción, y muestra que necesitan pagar $30 para recibir un token ERC-20, incluso solo para completar un cambio de estado muy básico, este precio es exorbitante, superando las expectativas de los usuarios, llevándolos a optar por una alternativa más rentable.

Otro factor es el tiempo; no puedes esperar dos minutos para una confirmación de transacción; eso es demasiado tiempo. El tiempo promedio de confirmación actual de Solana es de alrededor de dos segundos, a veces alcanzando un máximo de 8 segundos, pero se dirige hacia 400 milisegundos, un incentivo significativo de cambio de comportamiento para los usuarios, suficiente para hacer que estén dispuestos a cambiar a un nuevo producto.

Pero esto aún es desconocido. Sin embargo, en la tecnología de Solana, no hay barreras que impidan que la red continúe optimizando para mejorar la latencia y el rendimiento. Así que, cuando la gente pregunta por qué el crecimiento de Solana es más rápido que el de Ethereum, algunos pueden pensar que el próximo proyecto lo superará. Pero en realidad, la diferencia marginal entre Solana y el siguiente competidor es muy pequeña, lo que hace que sea más difícil crear una diferencia lo suficientemente significativa como para influir en el comportamiento del usuario, lo cual es un gran desafío.

Mert: Si la velocidad de ejecución es un factor clave, entonces fundamentalmente, esto se convierte en un problema organizativo o de coordinación. La diferencia entre la visión de Solana y lo que se puede llamar modularidad (aunque este no es un término formal) es que si, por ejemplo, eres un desarrollador de aplicaciones como Drip, y tu aplicación está construida en Solana, necesitas esperar a que L1 haga algunos cambios, como abordar la congestión o arreglar errores.

Sin embargo, si está en L2 o en una cadena de aplicaciones, puedes abordar estos problemas directamente tú mismo. Quizás desde esta perspectiva: en esta otra cadena, puedes ejecutar operaciones más rápidamente que depender del espacio compartido. Así que si esto es cierto, la velocidad de ejecución general será más rápida.

Anatoly: Con el tiempo, esta diferencia se irá reduciendo gradualmente. Por ejemplo, Ethereum solía ser muy lento. Si estuvieras ejecutando Drip en Ethereum y las tarifas de transacción se dispararan a $50, irías y preguntarías a Vitalik (el fundador de Ethereum) cuándo se podría resolver este problema. Él podría responder: "Tenemos una hoja de ruta de seis años, amigo, esto tomará algo de tiempo." Mientras que si preguntas a equipos como Fire Dancer o Agave, dirían: "Ya hay un equipo trabajando duro para solucionar este problema y con la meta de resolverlo lo más rápido posible en el próximo lanzamiento."

Esta es una diferencia cultural. El equipo central de L1, incluido todo el equipo de infraestructura como ustedes, a lo largo del proceso de envío de transacciones, todos entienden que cuando la red se ralentiza o hay una congestión global, este es un problema más crítico (p0) que todos deben abordar de inmediato. Por supuesto, a veces pueden surgir problemas inesperados, como ajustes en el diseño del mercado de tarifas.

Estos problemas se vuelven cada vez menos comunes a medida que la utilización de la red aumenta. No creo que actualmente haya desafíos que requieran cambios de diseño urgentes y tomen de seis meses a un año en desplegarse. No veo tales desafíos en el camino por delante en este momento.

Sin embargo, sabes que definitivamente habrá algunos errores u otros problemas inesperados en el momento del lanzamiento, lo que requiere que la gente trabaje horas extras los fines de semana, lo cual también es parte del trabajo. Si tienes tu propia cadena de aplicaciones L2 dedicada, no necesitas compartir recursos y tienes control total de esta capa de infraestructura, entonces puedes moverte más rápido, pero a un costo más alto, que no todos pueden permitirse.

Por lo tanto, una capa de infraestructura compartida y composable puede ser más barata y más rápida para la gran mayoría de los casos de uso, como una capa de infraestructura de software como servicio que puede ser compartida y utilizada por todos. Con correcciones de errores y mejoras continuas, esta brecha se volverá cada vez más pequeña.

6. ¿Disminuirá la Tasa de Inflación de Solana?

Mert: Otro punto relacionado de crítica es el mecanismo de inflación de Sol, ya que muchas personas creen que esto se hace aumentando las recompensas para ayudar a más validadores. Sin embargo, el costo de hacerlo puede ser a expensas de esos inversores puros. Cuando la gente dice que la tasa de inflación de Solana es demasiado alta, ¿cuál es tu primera reacción? ¿Cómo ves esto?

Anatoly: Este es un debate sin fin, cambiar los números en la caja negra realmente no cambia nada. Puedes hacer algunos ajustes para que afecte a ciertas personas, de modo que la caja negra no pueda operar normalmente, pero esto en sí no crea ni destruye ningún valor, es solo una operación contable.

La razón por la cual el mecanismo de inflación es como es ahora es porque copió directamente el mecanismo de Cosmos, ya que muchos de los validadores iniciales eran validadores de Cosmos. Sin embargo, ¿afecta la inflación a la red en su conjunto? Puede tener un impacto en individuos bajo un régimen fiscal específico, pero para toda la red, es un costo para los no apostadores y una ganancia equivalente para los apostadores, que matemáticamente suma cero. Así que desde una perspectiva contable, la inflación no afecta a la red en su conjunto como una caja negra.

Mert: He visto a personas decir que dado que es arbitrario, ¿por qué no simplemente bajarlo?

Anatoly: Adelante, propone un cambio, personalmente no me importa; lo he dicho innumerables veces, cámbialo al valor que quieras y convence a los validadores para que lo acepten. Cuando estos números se establecieron originalmente, la consideración principal no era causar un desastre completo, y dado que Cosmos no tuvo un problema debido a esta configuración, fue lo suficientemente razonable.

7. ¿Es demasiado alto el costo general de desarrollo de FireDancer?

Mert: Así que volvamos al desafío de coordinación. Hemos estado promoviendo FireDancer últimamente, y Jerry mencionó recientemente que algunas personas están comenzando a sentir que FireDancer está un poco sobrevalorado. Sin embargo, Jerry también mencionó que FireDancer realmente ha ralentizado un poco a las personas porque los ingenieros de Anza y los ingenieros de Fire claramente necesitan alinearse en ciertas cosas antes de que puedan avanzar, por lo que hay efectivamente un cierto retraso inicialmente. Tu perspectiva parece ser que una vez que se aclaren las especificaciones y las interfaces, la velocidad de iteración aumentará, ¿verdad?

Anatoly: Sí, puede descomponerse esencialmente en tres pasos: el primer paso es la fase de diseño, donde necesitas construir consenso sobre lo que necesita hacerse; el siguiente es la fase de implementación, donde ambos equipos pueden trabajar en paralelo; y luego hay la fase de prueba y validación para asegurar que no haya problemas de seguridad o de disponibilidad. Creo que la fase de diseño puede tomar más tiempo, pero la implementación es paralela, por lo que ambos equipos pueden avanzar simultáneamente, y la fase de prueba y auditoría será más rápida porque la probabilidad de que ambos equipos independientes introduzcan el mismo error es menor.

Creo que la mayor diferencia es que Ethereum generalmente opera así: lanzaremos una versión importante que incluye todas las características dirigidas a esa versión, centrándonos en un conjunto de características más que en una fecha de lanzamiento. Mientras que Solana opera casi exactamente al revés, estableciendo una fecha de lanzamiento, y si tu característica no está lista, se elimina, lo que resulta en una cadencia de lanzamiento mucho más rápida.

En teoría, si hay dos equipos que quieren acelerar la velocidad de iteración, el ciclo de iteración podría acelerarse aún más. Pero esto requiere que los ingenieros centrales tengan ese sentido de urgencia, sintiendo que "necesitamos sacar estos contenidos lo antes posible." En este caso, puedes confiar en cierta redundancia en la implementación. Creo que desde una perspectiva cultural, ambos equipos tienen un trasfondo similar ya que no son equipos académicos, sino que han crecido en una olla a presión tecnológica.

Mert: Esto me lleva al tercer punto que quería hacer: FireDancer. Debes asumir que no tienes capacidades de ejecución porque estás trabajando para un teléfono, no ayudando con el desarrollo de L1 o coordinando estos equipos de clientes. ¿Es realmente esta la elección óptima para un individuo?

Anatoly: El último cambio importante en el que estuve involucrado con FireDancer fue mover el índice de la base de datos de cuentas fuera de la memoria. En ese momento, podría escribir una propuesta de diseño y una implementación a pequeña escala para probar su viabilidad. Sin embargo, el problema es que para completar este trabajo, se requiere un ingeniero a tiempo completo dedicado a esta tarea. Podría entregar esta tarea a Jash, quien es responsable de hacerlo, pero incluyendo el ciclo de prueba y lanzamiento, todo el proceso tomaría un año.

Para mí, sería genial si pudiera unirme a Anzar Fire Dancer como un mero contribuyente individual (IC), responsable únicamente de centrarme en Grafana (una herramienta de monitoreo de rendimiento) y desarrollar algunas cosas. Sin embargo, la realidad es que mi energía se dispersa entre innumerables proyectos. Así que, encuentro que el lugar donde puedo tener el impacto más significativo es donde puedo definir el estado del problema, como problemas de crecimiento, problemas de liderazgo en concurrencia, problemas de revisión, problemas de competencia MEV, etc. Puedo proponer soluciones, discutir con todos, y eventualmente hacer que todos estén de acuerdo en que mi análisis del problema es correcto y presentar sus posibles soluciones. Iteramos juntos en el diseño, eventualmente lo moldeamos y lo solidificamos.

Luego, cuando el sentido de urgencia que anticipé se intensifica gradualmente, las personas ya tienen la solución de diseño. La parte más desafiante—la alineación entre los dos equipos—ha sido completada, y lo único que queda es la implementación y las pruebas. Así que, mi papel es casi como el de un Ingeniero Principal en una gran empresa. No escribo código; en cambio, me comunico con múltiples equipos, diciendo: "Noté que estás enfrentando dificultades en un área determinada, y otros equipos también. Necesitas resolver el problema de esta manera para que podamos alinearnos en este aspecto." Esta es probablemente la oportunidad donde puedo tener el impacto más significativo en el dominio central.

Mert: Esta es de hecho la responsabilidad de este rol, pero no es fácil. Así que, ¿estás diciendo: "Jack Dorsey puede hacerlo, Elon Musk puede hacerlo, así que yo también puedo desarrollar un teléfono mientras hago estas tareas"?

Anatoly: No es así, en realidad. Hay un ingeniero excepcional que está a cargo del lado móvil, es un amigo cercano mío desde hace más de diez años, ha estado involucrado en la construcción de BlackBerry, iPhone, y casi todos los teléfonos que puedas imaginar. Y hay un gerente general muy excelente. Estos dos gestionan todo el equipo juntos, y yo soy responsable de establecer la visión.

No creo que la gente entienda completamente esta visión, pero si miras a Android o iOS, en realidad son una especificación de firmware firmada criptográficamente que define toda la plataforma. Todos tienen un dispositivo así y aseguran su seguridad a través de arranque de confianza cuando recibes una actualización de firmware, verifica la corrección de la firma del firmware y reescribe todo el sistema del teléfono.

Y la parte más crítica de esto es esa firma criptográfica, ya que podría ser generada completamente por un DAO, que firma todo el firmware y es responsable de su lanzamiento. Imagina si el propio certificado de firma criptográfica de Apple estuviera controlado por un DAO, todo el concepto de la plataforma de software se vería interrumpido. Es esa mentalidad "hacker" extremadamente genial y algo peculiar.

Además, mi trabajo principal es establecer una visión así, impulsar al equipo a vender más teléfonos, hacer de esto un producto verdaderamente significativo y, en última instancia, alcanzar el hito donde todo el ecosistema pueda controlar su propio firmware. No me involucro en el trabajo de ejecución diaria.

En cuanto a Elon Musk, creo que su forma de trabajar podría ser así: tiene una gran idea, luego encuentra un ingeniero que puede decirle de manera convincente: "Puedo implementar todo el proyecto de principio a fin." Si puedes encontrar a tal persona, entonces lo único que necesitas hacer es proporcionar financiamiento para acelerar este proceso. Después de darle a esa persona el financiamiento, completará todo el proyecto por su cuenta y luego contratará personas para acelerar su progreso.

Intento operar de esta manera, no estoy seguro de si esto es lo mismo que el enfoque de Elon, pero creo que este es un método que puede manejar múltiples proyectos a la vez: tener una gran visión, un objetivo muy específico, y luego encontrar a alguien verdaderamente capaz de lograrlo. Si el tiempo es ilimitado, puedo construir cada parte. Y después de darles financiamiento, acelerarán para lograr todo esto.

Mert: Mencionaste que la visión es clara, pero el resultado ideal parece ser así: supongamos que tienes éxito, vendiendo una gran cantidad de estos teléfonos, incluso teniendo un impacto revolucionario en Crypto Twitter y Apple. Entonces, Apple podría reducir sus tarifas. En otras palabras, lo que estás haciendo cambia el mundo.

Anatoly: De hecho, ha traído cambio. Las empresas de software en el Medio Oeste ya no tienen que pagar un rescate similar al 30% de Apple, y se pueden desarrollar software y juegos más eficientes. Esto es de hecho bueno.

Mert: Pero esto parece más un esfuerzo altruista que un movimiento comercial, ¿verdad?

Anatoly: Solo cuando este acto altruista también pueda tener éxito como un movimiento comercial puede realizarse verdaderamente. Si Apple va a reducir sus tarifas, debe sentir la presión competitiva de un ecosistema en crecimiento y viable comercialmente. De lo contrario, solo se quedarán estancados hasta que ese ecosistema muera por falta de viabilidad comercial. Por lo tanto, este ecosistema debe encontrar el ajuste producto-mercado y tener la capacidad de autosostenerse.

Pero esto no significa que no cambiará el mundo. Si puede hacer que la participación de ingresos de Apple sea más pequeña, esa es la esencia del capitalismo: cuando ves a un grupo extrayendo renta al 30%, y tú proporcionas el mismo servicio al 15%, cambias la economía de mercado, beneficiando a todos, incluidos los consumidores.

Mert: Entonces, quieres decir que tienes que creer que puedes, en cierto sentido, superar a una de las empresas más grandes del mundo, Apple y Google. Entonces, ¿por qué crees que puedes competir con ellos?

Anatoly: Claramente, un 30% de participación en los ingresos es de hecho demasiado alto, ya que alguien como Tim Sweeney los está demandando en todas partes, se ha convertido en un punto crítico para las empresas que utilizan los canales de distribución de Apple y Google. Apple y Google extraen renta de esta manera, y a los consumidores no les importan estos costos porque están ocultos para ellos. Los consumidores pagan una cantidad fija a la aplicación, y Apple se queda con el 30% de eso.

Resolver este problema es un desafío en la construcción de redes, y creo que el campo cripto tiene una ventaja en este sentido. Cripto puede financiar activos digitales y escasez de una manera diferente a la Web 2. Pero aun así, esto puede fallar. La razón del fracaso no es que los desarrolladores de aplicaciones no quieran tarifas más bajas, lo cual es claramente cierto. La razón del fracaso es que aún no hemos encontrado una manera de aprovechar los incentivos proporcionados por la tecnología cripto para escalar la red.

Este es un problema realmente complicado. No es un problema de producto, no es un problema de modelo de negocio, sino una pregunta de cómo podemos forzar a los usuarios a cambiar su comportamiento y cambiarse a otras redes.

8. ¿En qué se basa Solana para competir con Ethereum?

Mert: Cambiando de tema, me gustaría hablar sobre problemas relacionados con ZK. Una visión final para blockchain parece ser que todo está impulsado por ZK, donde no necesitas ejecutar todas las operaciones en un nodo completo; solo necesitas verificar pruebas. Sin embargo, Solana no parece tener un plan similar.

Anatoly: Si has leído mi artículo sobre APE (Ejecución de Procesamiento Asincrónico), encontrarás que tiene un impacto significativo en cómo funcionan los validadores. Al compartir un probador común, los validadores pueden verificar el estado. Así que puedes tener múltiples validadores compartiendo un entorno de confianza (por ejemplo, TE) o algún modelo de confianza, o incluso utilizando una solución ZK. Cuando APE completa toda la ejecución asincrónica y calcula un hash de instantánea completo, en realidad puedes lograr esta idea: un Rollup basado completamente en verificación ZK. Esto no significa que necesites un Rollup o que un Rollup sea de algún modo incompatible con Solana.

Esta visión es absurda—La Ejecución Asincrónica te permite calcular un hash de instantánea basado en tu propio modelo de confianza, sin importar el entorno que estés utilizando, como ejecutar tu propio nodo completo, compartir un entorno TE, u otros entornos. Estos no afectan a mi nodo completo. Si ejecuto mi propio nodo completo, puedes usar cualquier entorno para hacer lo que quieras.

La pregunta central es: ¿qué distingue a Solana de Ethereum y ZK? Para que la red sobreviva, debe tener viabilidad comercial, lo que significa que necesita ser rentable. En mi opinión, el único modelo comercial para L1 son las tarifas de prioridad, que esencialmente es lo mismo que MEV. Por otro lado, los Rollups crean su propio MEV, realizan secuenciación independiente y compiten con L1, creando un entorno competitivo parasitario para L1.

Toda esta competencia está bien, pero no pertenece al ecosistema de Solana. Esos Rollups son basados en EVM, aprovechando el poder del código abierto para acelerar el desarrollo a nivel mundial, mientras que el ecosistema de Solana se basa en el SVM.

En mi opinión, esta es la diferencia fundamental en cómo se aplica ZK entre Solana y Ethereum. El protocolo ligero es genial porque en la red principal de Solana, la secuenciación es realizada por los validadores de Solana.

Mert: Vamos a dar un ejemplo muy teórico, completamente al revés, asumiendo que el ancho de banda ha sido maximizado, la latencia ha sido minimizada, y la Ley de Moore ha sido completamente aprovechada. Incluso en una situación donde el canal está saturado y solo se necesita un poco más de hardware para resolver el problema. Si realmente logramos todo esto pero aún no es suficiente, ¿qué pasa entonces? Supongamos que la tecnología de cifrado se ha vuelto más generalizada (aunque personalmente no creo que esto necesariamente suceda), ¿qué pasaría entonces?

Anatoly: Bueno, no puedes simplemente iniciar otra red porque los nodos completos de Solana ya han saturado el ancho de banda de los ISP, y cada ISP no tiene más capacidad; hemos consumido todo el ancho de banda disponible.

Mert: Supongo que antes de alcanzar la saturación total, todos los desafíos de ingeniería deben ser abordados.

Anatoly: Hay que darse cuenta de que actualmente casi en todas partes del mundo se puede acceder a velocidades de red de 1 Gbps, y casi cada dispositivo móvil tiene esta capacidad, lo que equivale a procesar 250,000 transacciones por segundo (TPS). Incluso basándose en las especificaciones de eficiencia actuales del protocolo Turbine, esta configuración soportaría 250,000 TPS. Este es un número astronómico, es una cantidad ridícula de capacidad. Saturamos esto primero antes de discutir otros problemas, como los límites de la Ley de Moore.

Pero hasta ahora, Solana todavía está 250x lejos de ese punto en términos de mejora de carga. Necesitamos una mejora de 250x antes de que podamos comenzar a considerar otros problemas. Y este llamado 1 Gbps es un estándar tecnológico con una historia de 25 años y es una tecnología muy madura.

Ni siquiera hemos estado cerca de saturar esta capacidad tecnológica todavía. Creo que cuando alcancemos la saturación total del ancho de banda de 1 Gbps, cuando Turbine esté completamente saturado, ese es el escenario que el equipo de FireDancer ya ha demostrado en un entorno de laboratorio. Por supuesto, este entorno aún está distribuido, pero fundamentalmente es un entorno de laboratorio, aunque esto es de hecho alcanzable.

Sin embargo, para hacer que esta tecnología sea comercialmente viable, aún hay muchos problemas por resolver, y las aplicaciones necesitan poder utilizar efectivamente esta capacidad. Porque actualmente, la mayor parte de la carga en Solana proviene de la actividad del mercado, comenzando con alcanzar la saturación, luego el arbitraje llena el espacio restante en el bloque. Pero esto aún no ha alcanzado lo que yo llamo "saturación económica."

Mert: En un entorno donde Ethereum tiene activos de mayor calidad y un mayor volumen de transacciones debido a los efectos de liquidez existentes, ¿cómo compite Solana? Asumiendo que estos activos, incluso los stablecoins, no han alcanzado el nivel de Ethereum, ¿qué necesita cambiar?

Anatoly: Podemos comenzar a llamar a los activos de Ethereum "Activos Legados," y luego lanzar todas las nuevas cosas en Solana, este meme necesita cambiar, (la nueva versión es) Ethereum es la plataforma para "activos legados," mientras que Solana es el lugar de nacimiento de nuevas cosas.

"Enlace del Artículo Original"