Una sola semilla solo puede florecer una vez; al sembrarla, hay que pensarlo bien. Guardar las semillas solo depende de ti.
Esto es lo que me di cuenta en el jardín. La clave WOTS de @BabylonLabs_io es precisamente ese tipo de semilla: uso único. Los materiales de clave usados quedan invalidados; el nuevo flujo debe usar claves nuevas. El protocolo lo fija como de un solo uso, y la responsabilidad de las copias de seguridad recae en el usuario.
Hagamos un experimento mental. Si la clave pudiera reutilizarse, ¿qué ocurriría? La reutilización de materiales de firma equivale a dejarle a un atacante una ventana para aprovechar de nuevo. Si ocurre una filtración, entonces las desgracias se repiten. Yo pensaba que el diseño de uso único era una molestia; al terminar de leerlo, entendí que coloca el riesgo en la primera línea: la clave se usa y se desecha; la ventana de filtración se cierra directamente. En el jardín, una semilla que solo florece una vez es, en realidad, la mejor forma de combatir las plagas: los insectos se la comen una vez, y la siguiente ya no hay flores que comer.
Entonces, ¿qué debe hacer el usuario? Las copias de seguridad. Como la semilla se acaba, antes de sembrar hay que dejar lista la siguiente tanda. El inventario de respaldo debe llevar el registro de la relación con el “bóveda” correspondiente: registrar el estado de uso de las claves de un solo uso, y la ubicación donde se guardan los materiales. Si se omite algo, equivale a perder una temporada de cosecha.
¿En concreto qué debe registrarse en el inventario de respaldo? La relación con la bóveda, el estado de uso de la clave de un solo uso y la ubicación de almacenamiento de los materiales: las tres cosas son indispensables. Solo recordar la ubicación pero no el estado significa que no se sabe si la “semilla” sigue ahí o no. Solo recordar el estado pero no la relación significa que no queda claro a quién corresponde la cosecha. Las reglas del jardín: si marcas todo con claridad, al año siguiente habrá cosecha. En el ecosistema de $BABY , todo lo que diga “solo se puede usar una vez” merece tener dos copias de seguridad.
Para cerrar con una idea: lo “de un solo uso” no es para fastidiar, sino para adelantar el costo de seguridad al día de la creación. El usuario puede ver el costo adelantado; el usuario no ve el riesgo que queda para después. El costo visible es fácil de gestionar; lo invisible es lo que asusta. Quien cultiva flores lo sabe: una buena cosecha empieza por elegir las semillas. Esta lección de las copias de seguridad hay que hacerla antes de sembrar. Los materiales se guardan en tres lugares: en local, en un disco sin conexión (offline) y en papel; en la cadena (on-chain) deja un índice. Si pierdes una copia, aún tendrás dos.
Lee despacio este diseño y notarás que cada vez encaja más: el uso único es el límite de seguridad del protocolo, y las copias de seguridad son el límite de responsabilidad del usuario; cada uno se encarga de lo suyo. Babylon separa el límite y la responsabilidad de forma clara y el usuario solo debe seguirlo. #baby
Esto es lo que me di cuenta en el jardín. La clave WOTS de @BabylonLabs_io es precisamente ese tipo de semilla: uso único. Los materiales de clave usados quedan invalidados; el nuevo flujo debe usar claves nuevas. El protocolo lo fija como de un solo uso, y la responsabilidad de las copias de seguridad recae en el usuario.
Hagamos un experimento mental. Si la clave pudiera reutilizarse, ¿qué ocurriría? La reutilización de materiales de firma equivale a dejarle a un atacante una ventana para aprovechar de nuevo. Si ocurre una filtración, entonces las desgracias se repiten. Yo pensaba que el diseño de uso único era una molestia; al terminar de leerlo, entendí que coloca el riesgo en la primera línea: la clave se usa y se desecha; la ventana de filtración se cierra directamente. En el jardín, una semilla que solo florece una vez es, en realidad, la mejor forma de combatir las plagas: los insectos se la comen una vez, y la siguiente ya no hay flores que comer.
Entonces, ¿qué debe hacer el usuario? Las copias de seguridad. Como la semilla se acaba, antes de sembrar hay que dejar lista la siguiente tanda. El inventario de respaldo debe llevar el registro de la relación con el “bóveda” correspondiente: registrar el estado de uso de las claves de un solo uso, y la ubicación donde se guardan los materiales. Si se omite algo, equivale a perder una temporada de cosecha.
¿En concreto qué debe registrarse en el inventario de respaldo? La relación con la bóveda, el estado de uso de la clave de un solo uso y la ubicación de almacenamiento de los materiales: las tres cosas son indispensables. Solo recordar la ubicación pero no el estado significa que no se sabe si la “semilla” sigue ahí o no. Solo recordar el estado pero no la relación significa que no queda claro a quién corresponde la cosecha. Las reglas del jardín: si marcas todo con claridad, al año siguiente habrá cosecha. En el ecosistema de $BABY , todo lo que diga “solo se puede usar una vez” merece tener dos copias de seguridad.
Para cerrar con una idea: lo “de un solo uso” no es para fastidiar, sino para adelantar el costo de seguridad al día de la creación. El usuario puede ver el costo adelantado; el usuario no ve el riesgo que queda para después. El costo visible es fácil de gestionar; lo invisible es lo que asusta. Quien cultiva flores lo sabe: una buena cosecha empieza por elegir las semillas. Esta lección de las copias de seguridad hay que hacerla antes de sembrar. Los materiales se guardan en tres lugares: en local, en un disco sin conexión (offline) y en papel; en la cadena (on-chain) deja un índice. Si pierdes una copia, aún tendrás dos.
Lee despacio este diseño y notarás que cada vez encaja más: el uso único es el límite de seguridad del protocolo, y las copias de seguridad son el límite de responsabilidad del usuario; cada uno se encarga de lo suyo. Babylon separa el límite y la responsabilidad de forma clara y el usuario solo debe seguirlo. #baby