Quería saber qué pasa en la brecha entre cuando cambia el respaldo real de un proveedor de finalidad y cuando el protocolo admite que cambió. Así que rastreé cómo el módulo de x/epoching de Babylon procesa realmente una nueva delegación.
Los mensajes de staking y unstaking no se ejecutan de inmediato. Se encolan durante la duración de todo un epoch, y luego se procesan en un solo lote en el límite. Hasta que ese límite llegue, el poder de voto de finalidad de la cadena refleja el snapshot antiguo, no el actual. Un proveedor de finalidad podría estar perdiendo delegaciones en tiempo real, podría estar vaciándose económicamente a mitad de epoch, y aun así votar con el peso que tenía antes de que nadie retirara.
Eso no es un bug. Es el intercambio por agrupar miles de delegaciones respaldadas por BTC en un único settlement en vez de procesar cada una individualmente. Pero significa que el respaldo de seguridad criptoeconómica de un bloque dado no es la seguridad que existe en este momento. Es la seguridad que existía al momento del último checkpoint, llevada hacia adelante con la confianza de que no cambió nada material entre medio.
Seguí comparándolo con cómo funciona realmente una línea de crédito. Tu límite no se actualiza al instante en que cambia tu ingreso. Se actualiza en un ciclo, y mientras tanto, el banco está extendiendo confianza basándose en un número que ya está ligeramente equivocado. Babylon hace lo mismo con el peso de Bitcoin, solo que con una criptografía mejor envuelta alrededor de la incorrección.
No creo que esto rompa el modelo. El unbonding rápido, de aproximadamente dos días, mantiene esa ventana corta en comparación con cadenas PoS típicas. Pero corto no es cero, y la parte que vale la pena observar no es el precio del token. Es qué tan amplia se vuelve esa ventana de epoch a medida que escala el conjunto de validadores.
$BABY @BabylonLabs_io #baby $ON $BTC
Los mensajes de staking y unstaking no se ejecutan de inmediato. Se encolan durante la duración de todo un epoch, y luego se procesan en un solo lote en el límite. Hasta que ese límite llegue, el poder de voto de finalidad de la cadena refleja el snapshot antiguo, no el actual. Un proveedor de finalidad podría estar perdiendo delegaciones en tiempo real, podría estar vaciándose económicamente a mitad de epoch, y aun así votar con el peso que tenía antes de que nadie retirara.
Eso no es un bug. Es el intercambio por agrupar miles de delegaciones respaldadas por BTC en un único settlement en vez de procesar cada una individualmente. Pero significa que el respaldo de seguridad criptoeconómica de un bloque dado no es la seguridad que existe en este momento. Es la seguridad que existía al momento del último checkpoint, llevada hacia adelante con la confianza de que no cambió nada material entre medio.
Seguí comparándolo con cómo funciona realmente una línea de crédito. Tu límite no se actualiza al instante en que cambia tu ingreso. Se actualiza en un ciclo, y mientras tanto, el banco está extendiendo confianza basándose en un número que ya está ligeramente equivocado. Babylon hace lo mismo con el peso de Bitcoin, solo que con una criptografía mejor envuelta alrededor de la incorrección.
No creo que esto rompa el modelo. El unbonding rápido, de aproximadamente dos días, mantiene esa ventana corta en comparación con cadenas PoS típicas. Pero corto no es cero, y la parte que vale la pena observar no es el precio del token. Es qué tan amplia se vuelve esa ventana de epoch a medida que escala el conjunto de validadores.
$BABY @BabylonLabs_io #baby $ON $BTC