¿Te ha pasado algo así alguna vez? El envío muestra “entregado y firmado”, pero tú ni siquiera has visto el paquete. Revisas las cámaras y resulta que el repartidor sí lo dejó en la puerta… pero luego alguien se lo llevó. La información de la mensajería es verdadera de principio a fin, pero el resultado no es el que esperas. En la cadena de bloques también hay momentos extraños de “el registro está bien, pero las consecuencias no”, y están escondidos en un componente mencionado de pasada en la sección 9 del whitepaper.
@BabylonLabs_io En la sección 9, al hablar del despliegue en múltiples cadenas, se menciona que cada cadena conectada a la bóveda debe ejecutar un “cliente ligero de Bitcoin” para verificar que tu BTC realmente se bloquea de forma honesta y correcta en la cadena de Bitcoin. El cliente ligero se las arregla con muy poco: solo sincroniza los encabezados de bloque y luego usa pruebas de Merkle para confirmar la existencia de una transacción. Suena bastante fiable, pero hay una vulnerabilidad raramente discutida: las reorganizaciones de la cadena.
La cadena de Bitcoin a veces se reorganiza: faltan uno o más bloques y, en el caso más profundo registrado, se pueden llegar a “expulsar” decenas de bloques. El cliente ligero solo acepta encabezados de bloque y, en su vista, solo existe “la cadena más larga”. Pero si la transacción de tu bóveda se empaqueta en un bloque que después queda aislado, cuando termina la reorganización el cliente ligero se da cuenta de algo: ¡ese depósito se evapora por arte de magia! ¿Dónde está el problema? Durante esos minutos en que ocurre la reorganización, el collBTC en la cadena de contratos quizá ya se había acuñado. La mensajería insiste en que el paquete fue entregado; abres la caja y está vacía.#baby
El mecanismo de gobernanza del Babylon whitepaper, $BABY , se plantea precisamente para hacer frente a este tipo de casos “de baja probabilidad y, si explotan, rompen el cielo”: ¿cuántos bloques de confirmación se exigen? ¿Con 6 confirmaciones basta, o mejor ser conservadores y esperar hasta 12? ¿Durante la reorganización la bóveda se detiene en seco o sigue funcionando con normalidad? Estos parámetros no se “cocan” dentro del código de la bóveda; en el fondo no es un problema técnico, sino de tolerancia al riesgo. Quien tiene en la mano los votos de BABY, en esencia está marcando una línea de graduación para la “tolerancia a la incertidumbre” de todo el sistema.
Lo que la minimización de confianza intenta eliminar con empeño es la motivación de hacer el mal por parte de las personas. Pero la reorganización no es maldad: es una ley física. El código puede mantener a los malos fuera de la puerta, pero no puede impedir que la probabilidad se cuele en silencio. DYOR.
@BabylonLabs_io En la sección 9, al hablar del despliegue en múltiples cadenas, se menciona que cada cadena conectada a la bóveda debe ejecutar un “cliente ligero de Bitcoin” para verificar que tu BTC realmente se bloquea de forma honesta y correcta en la cadena de Bitcoin. El cliente ligero se las arregla con muy poco: solo sincroniza los encabezados de bloque y luego usa pruebas de Merkle para confirmar la existencia de una transacción. Suena bastante fiable, pero hay una vulnerabilidad raramente discutida: las reorganizaciones de la cadena.
La cadena de Bitcoin a veces se reorganiza: faltan uno o más bloques y, en el caso más profundo registrado, se pueden llegar a “expulsar” decenas de bloques. El cliente ligero solo acepta encabezados de bloque y, en su vista, solo existe “la cadena más larga”. Pero si la transacción de tu bóveda se empaqueta en un bloque que después queda aislado, cuando termina la reorganización el cliente ligero se da cuenta de algo: ¡ese depósito se evapora por arte de magia! ¿Dónde está el problema? Durante esos minutos en que ocurre la reorganización, el collBTC en la cadena de contratos quizá ya se había acuñado. La mensajería insiste en que el paquete fue entregado; abres la caja y está vacía.#baby
El mecanismo de gobernanza del Babylon whitepaper, $BABY , se plantea precisamente para hacer frente a este tipo de casos “de baja probabilidad y, si explotan, rompen el cielo”: ¿cuántos bloques de confirmación se exigen? ¿Con 6 confirmaciones basta, o mejor ser conservadores y esperar hasta 12? ¿Durante la reorganización la bóveda se detiene en seco o sigue funcionando con normalidad? Estos parámetros no se “cocan” dentro del código de la bóveda; en el fondo no es un problema técnico, sino de tolerancia al riesgo. Quien tiene en la mano los votos de BABY, en esencia está marcando una línea de graduación para la “tolerancia a la incertidumbre” de todo el sistema.
Lo que la minimización de confianza intenta eliminar con empeño es la motivación de hacer el mal por parte de las personas. Pero la reorganización no es maldad: es una ley física. El código puede mantener a los malos fuera de la puerta, pero no puede impedir que la probabilidad se cuele en silencio. DYOR.