Continuar haciendo grandes esfuerzos y pasar de la posición 750 al top 100 no fue una tarea fácil. Fue compromiso y constancia con respecto a la calidad del contenido. Cuando estaba en la posición 750, en ese momento mi mente estaba estancada y tomé algunas entradas equivocadas en $BANK & $SKYAI , pero después mi mente se convirtió totalmente hacia @BabylonLabs_io .
Hoy estaba leyendo sobre el backend de staking de Babylon y me encontré con algo que sinceramente no había esperado.
¿Cuánto de lo que parece ser estado en cadena realmente pasa primero por infraestructura fuera de la cadena, antes de que lo veas?
El indexer de staking, un servicio específico dentro del conjunto de backend de Babylon, sincroniza eventos de delegación, el estado de los proveedores de finalidad y los parámetros globales de staking desde Bitcoin y Babylon Genesis hacia su propia base de datos. El frontend y el servicio de la API de staking leen desde ese indexer, no directamente desde ninguna de las dos cadenas, y honestamente no me lo había imaginado hasta que lo vi plasmado.
Mi primera lectura fue: vale, esto es solo una capa de caché para la velocidad. Conveniente, no crítico.
No del todo. Si el indexer se queda atrás sincronizando, lo que un usuario ve sobre su propio staking empieza a desviarse de lo que realmente es cierto en la cadena, aunque no haya cambiado nada en ninguna de las dos cadenas.
Aun así, me molesta un poco lo fácil que es pasarlo por alto.
Las cadenas se mantienen precisas todo el tiempo. Es la capa de traducción, en medio, la que puede desviarse en silencio.
No sé cuántas instancias del indexer se ejecutan en paralelo ahora mismo, ni qué tan centralizado está realmente este componente hoy en día. Eso no se desglosa en la documentación general de la arquitectura, y no voy a fingir que tengo un número que no tengo.
La primera vez que un staker ve un estado incorrecto porque el indexer se retrasó, no porque su staking realmente cambió: ¿eso cambia la forma en que la gente piensa sobre lo que realmente significa "en cadena" día a día?
¿En qué deberías confiar más en los datos?
@BabylonLabs_io #baby $BABY
Hoy estaba leyendo sobre el backend de staking de Babylon y me encontré con algo que sinceramente no había esperado.
¿Cuánto de lo que parece ser estado en cadena realmente pasa primero por infraestructura fuera de la cadena, antes de que lo veas?
El indexer de staking, un servicio específico dentro del conjunto de backend de Babylon, sincroniza eventos de delegación, el estado de los proveedores de finalidad y los parámetros globales de staking desde Bitcoin y Babylon Genesis hacia su propia base de datos. El frontend y el servicio de la API de staking leen desde ese indexer, no directamente desde ninguna de las dos cadenas, y honestamente no me lo había imaginado hasta que lo vi plasmado.
Mi primera lectura fue: vale, esto es solo una capa de caché para la velocidad. Conveniente, no crítico.
No del todo. Si el indexer se queda atrás sincronizando, lo que un usuario ve sobre su propio staking empieza a desviarse de lo que realmente es cierto en la cadena, aunque no haya cambiado nada en ninguna de las dos cadenas.
Aun así, me molesta un poco lo fácil que es pasarlo por alto.
Las cadenas se mantienen precisas todo el tiempo. Es la capa de traducción, en medio, la que puede desviarse en silencio.
No sé cuántas instancias del indexer se ejecutan en paralelo ahora mismo, ni qué tan centralizado está realmente este componente hoy en día. Eso no se desglosa en la documentación general de la arquitectura, y no voy a fingir que tengo un número que no tengo.
La primera vez que un staker ve un estado incorrecto porque el indexer se retrasó, no porque su staking realmente cambió: ¿eso cambia la forma en que la gente piensa sobre lo que realmente significa "en cadena" día a día?
¿En qué deberías confiar más en los datos?
@BabylonLabs_io #baby $BABY
Direct chain query
50%
Indexer/dashboard
25%
Both, equally
25%
Depends on timing
0%
4 Votos • Votación cerrada