Sigo dando vueltas a una pregunta cuando estoy construyendo programas SVM para Fogo: ¿cuánto de la red puedo falsificar localmente sin mentirme a mí mismo? Solía tratar testnet como mi sandbox por defecto, pero últimamente he estado deseando bucles de retroalimentación más ajustados. Cuando cada pequeño cambio significa esperar un RPC externo, mi atención se dispersa y empiezo a "probar" por esperanza en lugar de por evidencia. Fogo está impulsando tiempos de bloque extremadamente cortos en testnet, y también rota zonas a medida que las épocas avanzan, por lo que la cadencia de confirmaciones y liderazgo puede sentirse diferente de entornos más lentos. Esa velocidad es increíble para aplicaciones en tiempo real, pero puede ser difícil cuando estás depurando. Pequeñas suposiciones de temporización se rompen, los registros se desordenan y casos extremos de instrucciones extrañas aparecen antes de lo que esperas. He aprendido a tratar las pruebas locales como mi "sala lenta", donde puedo agregar mejor visibilidad y hacer que el programa muestre su trabajo antes de introducirlo en una cadena de movimiento rápido. No es emocionante. Esa es exactamente la razón por la que funciona. Puedo repetirlo a diario.
En la parte inferior de mi escalera están las pruebas que se ejecutan completamente en proceso. El atractivo es simple: puedo crear cuentas, ejecutar transacciones e inspeccionar resultados sin iniciar un validador completo o pelear por puertos. LiteSVM se inclina hacia esto al incrustar una VM de Solana dentro del proceso de prueba, lo que hace que las pruebas se sientan más cercanas a pruebas unitarias que a “mini despliegues”. Lo que me sorprende es cuánta inercia tiene este estilo en este momento. Algunas opciones más antiguas de “local rápido” han sido desaprobadas o dejadas sin mantenimiento, y bibliotecas más nuevas están tratando de hacer que la velocidad sea la predeterminada en lugar de un truco especial.
Cuando necesito algo más cercano al mundo real, subo a un validador local. El validador de prueba de Solana es básicamente una cadena privada con soporte completo de RPC, reinicios fáciles y la capacidad de clonar cuentas o programas de un clúster público para que puedas reproducir interacciones complicadas. Si estoy usando Anchor, me gusta la prueba de anclaje porque puede iniciar una red local, desplegar nuevas construcciones de programas, ejecutar las pruebas de integración y apagar todo de nuevo, lo que evita que mi computadora portátil se convierta en un cementerio de validadores en medio de funcionamiento.
La parte que la gente omite, y la parte que muerde más tarde, es la desviación de características y versiones. Las herramientas te permiten inspeccionar el estado de las características en tiempo de ejecución e incluso desactivar características específicas en el génesis en un libro mayor reiniciado, lo que es una forma práctica de hacer que tu cadena local se comporte más como cualquier clúster al que vayas a desplegar. También observo la pila de pruebas en sí: la crate solana-program-test, por ejemplo, ahora marca partes de su interfaz como moviéndose hacia una API inestable, lo que es un recordatorio de que el arnés merece fijación de versión y cuidado, no actualizaciones casuales.
Para cuando finalmente apunto a mi cliente a la red de prueba o red principal de Fogo, quiero que las preguntas restantes sean del tipo correcto: latencia, presión de tarifas y comportamiento bajo tráfico real, no si olvidé validar a un propietario de cuenta. Las pruebas locales no pueden reemplazar la red, pero pueden hacer que la red sea el último lugar donde descubro algo obvio.
@Fogo Official #fogo #Fogo $FOGO
