Una vez añadí a todo el mundo a un chat de grupo antes de comprobar quién seguiría disponible cuando comenzara el trabajo real.
Ese pequeño error cambió la forma en que interpreto el diseño del desafiante de @BabylonLabs_io.
Una Bóveda de Bitcoin sin confianza no espera hasta una disputa para decidir quién puede participar. Los reclamantes y los desafiantes quedan fijados cuando se crea la bóveda, porque el proceso de disputa mediante circuito de garbleado funciona entre partes predeterminadas.
Eso hace que el grafo de transacciones sea predecible.
Pero también convierte la seguridad en una lista de participantes elegida antes de conocer las condiciones futuras.
El riesgo oculto no es si BABY tiene desafiantes.
Es si los desafiantes adecuados siguen activos cuando finalmente se los necesita.
Un conjunto fijo de Desafiantes Universales con versiones puede reducir la incertidumbre y evitar que actores aleatorios entren en rutas críticas. Pero si la membresía no es sin permisos, ¿qué tan rápido puede BABY reemplazar a un operador que se vuelve lento, queda con falta de fondos o no está disponible? ¿Y qué ocurre con las bóvedas más antiguas cuando una infraestructura de monitoreo más sólida avanza hacia una versión de registro más nueva?
Una membresía fija es razonable. La participación completamente abierta puede generar spam, responsabilidades poco claras y fallas de coordinación.
Aun así, la preselección de defensores desplaza parte de la seguridad de Babylon de la criptografía a la disponibilidad a largo plazo. El sistema de pruebas puede seguir siendo correcto mientras los participantes que se esperaba que lo activaran lentamente desaparecen.
No creo que esto rompa BABY.
Estoy observando si Babylon puede mantener una estructura de disputa fija sin permitir que la lista de participantes de ayer se convierta en el cuello de botella de la disponibilidad de mañana.
@BabylonLabs_io $BABY #baby
Ese pequeño error cambió la forma en que interpreto el diseño del desafiante de @BabylonLabs_io.
Una Bóveda de Bitcoin sin confianza no espera hasta una disputa para decidir quién puede participar. Los reclamantes y los desafiantes quedan fijados cuando se crea la bóveda, porque el proceso de disputa mediante circuito de garbleado funciona entre partes predeterminadas.
Eso hace que el grafo de transacciones sea predecible.
Pero también convierte la seguridad en una lista de participantes elegida antes de conocer las condiciones futuras.
El riesgo oculto no es si BABY tiene desafiantes.
Es si los desafiantes adecuados siguen activos cuando finalmente se los necesita.
Un conjunto fijo de Desafiantes Universales con versiones puede reducir la incertidumbre y evitar que actores aleatorios entren en rutas críticas. Pero si la membresía no es sin permisos, ¿qué tan rápido puede BABY reemplazar a un operador que se vuelve lento, queda con falta de fondos o no está disponible? ¿Y qué ocurre con las bóvedas más antiguas cuando una infraestructura de monitoreo más sólida avanza hacia una versión de registro más nueva?
Una membresía fija es razonable. La participación completamente abierta puede generar spam, responsabilidades poco claras y fallas de coordinación.
Aun así, la preselección de defensores desplaza parte de la seguridad de Babylon de la criptografía a la disponibilidad a largo plazo. El sistema de pruebas puede seguir siendo correcto mientras los participantes que se esperaba que lo activaran lentamente desaparecen.
No creo que esto rompa BABY.
Estoy observando si Babylon puede mantener una estructura de disputa fija sin permitir que la lista de participantes de ayer se convierta en el cuello de botella de la disponibilidad de mañana.
@BabylonLabs_io $BABY #baby