El cofundador de Solana, Anatoly Yakovenko, ha nombrado cinco aplicaciones principales como prioridades más altas para la optimización de la red que los validadores, desarrolladores, creadores de mercado o ingenieros centrales, argumentando que los productos que poseen activos sustanciales y manejan volumen de trading minorista merecen la mayor atención.
Resumen
- Cinco aplicaciones encabezaron la lista de Yakovenko de grupos para los que Solana debería optimizar su red.
- Atribuyó a la Fundación Ethereum el haber atendido la necesidad de Aave de un acceso confiable a las transacciones.
- Su publicación respondió a las críticas sobre la experiencia personal de los diseñadores de Ethereum al usar la red.
- Los comentarios no contenían ninguna actualización específica, asignación de fondos ni cambio en las reglas de participación de los validadores.
Anatoly Yakovenko hizo los comentarios en una publicación en X del 23 de octubre, nombrando a Phantom, Pump.fun, Fomo, Jupiter y Kamino mientras respondía a las críticas sobre cómo los diseñadores del protocolo de Ethereum usan su propia red.
Las aplicaciones más grandes de Solana encabezan la lista de prioridades de Yakovenko
Yakovenko identificó los activos bajo gestión y la actividad minorista como las dos medidas detrás de su preferencia. Su publicación no proporcionó cifras para ninguna de las dos medidas ni clasificó los cinco productos nombrados entre sí.
“Los productos con una tonelada de aum y una tonelada de volumen minorista son los dos grupos más importantes para optimizar”, escribió.
El cofundador luego colocó las cinco aplicaciones por delante de los validadores, desarrolladores, creadores de mercado e ingenieros centrales. Su redacción abordó las necesidades de quién deberían guiar la optimización, sin especificar una propuesta técnica ni un calendario para implementar una.
Phantom, Pump.fun, Fomo, Jupiter y Kamino fueron ejemplos en su argumento. La publicación no anunció un acuerdo con esos equipos, no les otorgó autoridad de gobernanza ni identificó una configuración de red que cambiaría en su nombre.
En una respuesta visible debajo de la publicación, describió al usuario prioritario en términos más generales.
“El usuario más importante es el fontanero, el fontanero institucional o minorista”.
Las críticas a Ethereum provocan elogios a las necesidades de confiabilidad de Aave
La discusión comenzó con el argumento de otro autor de que muchas personas que diseñan el protocolo de Ethereum no lo usan ellos mismos. El autor argumentó que los diseñadores deberían depender de su propio producto y enfrentar pérdidas cuando este falle.
Citando esa crítica, Yakovenko dio a la Fundación Ethereum un elogio con reservas. Dijo que había hecho un trabajo decente optimizando para Aave porque la incapacidad de incluir transacciones durante una interrupción o congestión rompería la plataforma de préstamos.
Las tarifas de las aplicaciones aparecieron en un debate anterior sobre Robinhood
Yakovenko argumentó anteriormente que una empresa podría construir sobre Solana, subsidiar los costos de transacción y cobrar a los clientes a través de su propia interfaz. Como crypto.news informó anteriormente el 6 de septiembre, su posición provocó una respuesta del cofundador de Offchain Labs, Steven Goldfeder, sobre la decisión de Robinhood de usar la tecnología de Arbitrum.
Goldfeder defendió la capacidad de Robinhood de retener los ingresos de la cadena, diciendo que podría conservar aproximadamente el 90% bajo el Programa de Expansión de Arbitrum. Contrastó ese acuerdo con una aplicación que paga por usar Solana.
El acuerdo reportado envía el 10% de los ingresos netos del protocolo al ecosistema de Arbitrum, dividido entre una asignación del 8% a su DAO y un 2% para su Gremio de Desarrolladores. El porcentaje se refiere a los ingresos netos después de los gastos relevantes de la red, incluidos los costos de publicación de datos en Ethereum.
El intercambio Robinhood concernía a la infraestructura y el modelo de ingresos de una correduría estadounidense. La publicación de Yakovenko del 23 de octubre no anunció ningún cambio en el acceso a productos para clientes estadounidenses.
Los preparativos de Alpenglow establecen funciones separadas para los equipos de aplicaciones y los validadores
La cobertura anterior de la actualización de Solana documentó requisitos diferentes para los desarrolladores de aplicaciones y los operadores que suministran su infraestructura. El 26 de septiembre, Alpenglow llegó a devnet, tras su transición a testnet, dando a los equipos de aplicaciones acceso al nuevo comportamiento de consenso antes de un traspaso a mainnet.
La guía de la Fundación, descrita en esa cobertura, indicaba que las aplicaciones que solo envían transacciones y leen saldos no necesitarían una migración. Los servicios que procesan bloques o rastrean la actividad de los validadores enfrentaron cambios en la forma en que leen los datos de la red.
Un informe del 14 de agosto sobre el objetivo de finalidad de Alpenglow documentó un objetivo de aproximadamente 150 milisegundos, en comparación con unos 12,8 segundos bajo TowerBFT. La cobertura distinguió la finalidad de consenso de una indicación inicial de que una transacción se registró.
Los reportes posteriores sobre los cambios en las tarifas de los validadores describieron el plan de la Fundación de reemplazar las tarifas individuales de votación en la cadena por un cargo de admisión fijo de 0,8 SOL por época, quemado en su totalidad. Los operadores deben financiar ese cargo por encima del mínimo exento de renta de su cuenta de votación.
La misma guía establece el pago con una época de anticipación. Un validador que no pueda pagar pierde el permiso para votar o producir bloques en la época siguiente.
La documentación para operadores descrita en la cobertura de octubre matiza el objetivo de finalidad para los nodos fuera del conjunto de validadores admitidos. Esos nodos normalmente conocen el resultado a partir de los certificados incluidos en un bloque posterior, lo que potencialmente añade un intervalo de bloque producido, con esperas más largas si se omiten o retrasan bloques.
Para la etapa de pruebas anterior, la cobertura de septiembre distinguió las dos redes públicas. Devnet permite a los equipos de aplicaciones verificar software usando tokens sin valor real, mientras que testnet permite a los validadores y operadores de infraestructura someter el software de la red a condiciones más exigentes. Anza anunció públicamente la exitosa transición a devnet el 25 de septiembre, un día después de que testnet completara su cambio.
