Hoy enviaron el calendario de turnos en el grupo de la empresa. Quién debe abrir la puerta, a qué hora debe presentarse, y el número de teléfono de contacto… todo está escrito de forma clara y sin ambigüedades.
Al principio pensé que la organización era bastante formal. Pero luego lo pensé mejor: si no se trata de un turno normal, sino de una lista de “quién se encarga de custodiar las llaves del cofre”, publicarlo con antelación no es necesariamente transparencia; más bien parece darles a la gente un objetivo con bandeja.
Tanto es así que después de revisar el tablero, fui a buscar en el Libro Blanco @Dusk uno de esos diseños que antes no había desarmado con atención: Proof-of-Blind Bid.
Muchas cadenas PoS solo hablan de quién aporta más stake y quién tiene más probabilidad de proponer bloques. Pero Dusk añade una capa más: si el siguiente proponente de bloque se ve con antelación, ¿podría ser atacado, sobornado, e incluso que le corten el acceso a la red antes de que llegue su turno?
Lo que hace es bastante interesante. La puja de los participantes entra en un Merkle Tree. En él no se guarda la información “al descubierto”, sino un compromiso (commitment) y los datos relacionados con la cantidad de stake $DUSK .
Los candidatos pueden usar pruebas de conocimiento cero para explicar “mi puja es válida y cumplo los requisitos”, sin necesidad de revelar antes su identidad ni la cantidad exacta de stake. El Generator que cumpla con las condiciones de extracción se encarga de proponer el bloque, y luego un comité de Provisioner seleccionado mediante un sorteo determinista realiza la Reduction y el Agreement, cerrando la verificación y la confirmación final.
En palabras llanas: quien escribe la respuesta guarda primero el número de asiento; quien corrige el examen saca la papeleta aparte, y así se intenta evitar que un atacante se ponga a acechar con antelación.
Esa es, para mí, precisamente la parte interesante de #dusk : la privacidad no solo sirve para las transferencias, sino que también se integra en el diseño de seguridad de los participantes del consenso.
No se trata de esconder todo para siempre, sino de reducir la probabilidad de que los papeles clave queden fijados y localizados con antelación.
Claro, antes de seguir, hay que mojar la pólvora con la prioridad de salvar vidas: ocultar la información de la puja no equivale a anonimato absoluto en la capa de red. La IP de los nodos, el modo de despliegue y la concentración del stake igual hay que mirarlos. PoBB resuelve riesgos de tipo “exposición anticipada del proponente”, no es un escudo todoterreno.
Pero comparado con solo imprimir el TPS en un cartel publicitario, prefiero fijarme en estos detalles poco llamativos que, si llega un ataque de verdad, podrían salvar vidas.
Entonces, ¿qué tipo de riesgo crees que una cadena PoS necesita prevenir primero?
$BTC
$ETH