Crypto Bounty Hunter-1

这几天圈里最扎眼的新闻，恐怕是 ColdCard 硬件钱包被掏空这件事。一个五年前埋下的编译开关，悄悄关掉了硬件随机数发生器，种子直接退化成一个几乎能被预测的伪随机数，上亿美元比特币被一锅端。

看完我只有一句感慨：随机一旦能被提前算出来，就不再随机了。
这让我想起 @Dusk 在共识里反复较真的一个环节：怎么选下一个出块的人？

你可能会问，这事能有多难？要公平，随机结果得人人能验证；要安全，又得没人能提前猜到。这俩要求撞在一起，其实是拧巴的。Dusk 用的确定性抽签，简称 DS，想同时要这两样。

它没搞什么花哨的随机源，#dusk 就是把有资格的质押者排成一队，用当前这轮的“分数”挨个过一遍，谁权重够谁中签。分数怎么来？用 SHA3 把上一区块的种子、轮次、步骤一起哈希出来，结果唯一、可复现，谁都能自己重算核对一遍。

这里头的门道，全在“种子”上。每个新区块，出块者都要拿自己的签名在上一区块种子上再签一次，作为下一轮种子。这就像摇号机——规则公开、人人可复核，可下一期摇出谁，谁也没法提前知道。

$DUSK 在这里就是抽签的权重筹码：质押越多，权重越高，被抽中的概率越大；但每中一次权重减一，防止大户包圆委员会。

我琢磨着，这设计妙就妙在，它没把“随机”交给中心化摇号机，而是用公开可验的规则加上不可预测的种子，把公平和安全焊在一起。当然，前提是种子真不可预测、质押真分散，这些还得看后续数据。DUSK 这个币，功课得自己做，别只听我这一嘴。

Hace un tiempo, unos amigos se pusieron de acuerdo para comprar algo grande en grupo; el dinero iba y venía en el chat. Alguien gritó “ya lo hice bien”, y otro respondió “no lo recibí”. Al final, ni siquiera quedó claro si esa transacción contaba como “cerrada”; la discusión se alargó hasta altas horas de la noche hasta que se aclaró. Después lo pensé: muchas cosas no son tan difíciles por “hacerlas”, sino por “cuándo se consideran válidas”.

En blockchain, esto se llama finalidad: se refiere al intervalo entre que una transacción “parece haberse completado” y que quede “totalmente fijada, sin posibilidad de echarse para atrás”.

Últimamente vi el proyecto @Dusk . Usa un mecanismo de consenso llamado Succinct Attestation, abreviado SA. El objetivo es comprimir ese intervalo hasta el nivel de segundos. ¿Por qué puede ser tan rápido? No porque haga que todos participen a la vez, sino porque, cada vez, se selecciona al azar un pequeño grupo de validadores/participantes (los que han puesto garantías) para formar un comité. Esa gente recorre rápido el proceso de “propuesta, verificación y aprobación”, y luego se usa la firma agregada BLS para condensar los votos de todos en una sola prueba ligera.

A esa prueba se le llama attestation, que literalmente significa “acreditación/constancia”. Convierte el hecho de que “ha estado de acuerdo una cantidad suficiente de personas” en un comprobante ligero que cualquiera puede verificar rápidamente. Como el comité es pequeño, la prueba es pequeña y la verificación es rápida, la velocidad naturalmente sube. #dusk

Creo que lo ingenioso de ese diseño está en esto: no obligó a todos a juntarse y discutir lentamente, sino que intercambia velocidad por “comité pequeño aleatorio + una prueba de agregación”. Por supuesto, el requisito de seguridad de la selección aleatoria y del comité todavía tiene que resistir el análisis; por muy rápido que sea, primero hay que ver si es estable o no. Sobre esta moneda $DUSK , haz tu propia investigación; no te quedes solo con lo que yo diga.

Hace poco me mudé y saqué un montón de fotos antiguas. Para ahorrar tiempo, las fui fotografiando con el móvil una por una y las guardé en la galería, pensando que con eso ya estaba “digitalizado”. Luego descubrí que esas “fotos electrónicas” aparte de poder verse, no servían para nada más: no se pueden ampliar ni retocar, ni tampoco enviar. Resulta que hacer una foto solo le pone una capa encima a lo antiguo, pero no significa que de verdad se haya convertido en algo nativo digital.

Más tarde, al ver el proyecto @Dusk , noté que en el tema de los RWA (activos del mundo real) también divide el camino en dos tipos, parecido a la diferencia entre “tomar fotos” y la digitalización nativa.

Una forma es la tokenización; dicho en simple, es “tomar una foto”. Por ejemplo, propiedades inmobiliarias, bonos y participaciones de fondos: esos activos siguen existiendo en los sistemas tradicionales. En la cadena solo se emite un token que los replica, como un espejo. Pero los pasos clave como la verificación de la titularidad, la compensación y el reparto de dividendos siguen teniendo que hacerse de manera presencial, paso a paso.

La otra forma es la emisión nativa, equivalente a “digitalizar directamente”. Los activos caen en la cadena desde el mismo día en que nacen, y el proceso de emisión, registro, transferencia, pago de intereses y reembolso se realiza, en la medida de lo posible, todo en la cadena. Cuanto más largo sea el “eslabón”, más cosas puede gestionar la cadena y menos intermediarios se necesitan. Por ejemplo, los intereses y los dividendos pueden enviarse automáticamente según la participación en cadena, sin tener que esperar a que una entidad de custodia haga conciliaciones una por una. Lo que #dusk intenta aportar es la infraestructura base para soportar ese flujo de emisión nativa; claro que, como condición previa, la institución y el mercado de negociación deben contar con las licencias y la configuración de producto correspondientes.

Me puse a pensarlo: la tokenización, a corto plazo, parece un camino inevitable; pero a largo plazo se ve más como una solución de transición. La emisión nativa es el objetivo final, solo que traslada todos esos viejos problemas—regulación, leyes, compensación—de golpe a la cadena, así que el nivel de dificultad es mucho mayor. La dirección la veo con buenos ojos a largo plazo, pero a corto plazo no esperes que se resuelva de la noche a la mañana. Con esta $DUSK , el trabajo de investigación lo tienes que hacer tú; no te quedes solo con lo que te diga yo.

Hace poco ayudé a un amigo a cuadrar cuentas, pero se negó en rotundo a compartir capturas del extracto bancario. Al principio me quedé intrigado: ¿qué tenía de malo para su seguridad? Luego lo entendí: en una captura del extracto, el importe, la dirección y con quién se hizo la transferencia quedan a la vista, todo clarito. La demanda de privacidad de un adulto no consiste en cerrar la puerta con llave; más bien es que la gente adecuada pueda ver, y quien no deba ver, que no pueda tocar nada.

Recientemente revisé el proyecto @Dusk y vi que precisamente intenta hacer algo de este tipo. En el whitepaper, plantea querer reunir privacidad, cumplimiento y escalabilidad a la vez. Suena como si estuviera luchando contra el triángulo imposible, pero en realidad apunta directo a la piedra de toque del “enlace” tradicional en la cadena.

Ethereum, Bitcoin y otros libros contables públicos: la transparencia es, literalmente, transparente. Pero en cuanto las operaciones financieras se suben ahí, tu posición, tus contrapartes y tus movimientos quedan expuestos bajo el sol; los secretos comerciales, en la práctica, quedan como si fueran a la intemperie. Zcash y Monero, en cambio, se esconden bastante. El problema es que lo hacen demasiado bien: la capacidad de auditoría y cumplimiento no alcanza, y las instituciones por miedo a asumir riesgos no se atreven a usarlos de verdad. Al final, el atasco es uno solo: o bien transparentas hasta que no hay secretos, o bien preservas la privacidad hasta desaparecer en la niebla; justo en el medio falta un estado “que pueda entregarse al regulador sin emitirlo a todo el mundo”.

$DUSK no te obliga a elegir entre una de dos opciones; te instala un sistema de permisos por niveles. Para el público general, es una niebla; pero para los auditores o reguladores que tengan la clave, pueden abrir la parte que sí deben ver. En su implementación, directamente hace dos modelos de transacción: Moonlight usa cuentas transparentes, Phoenix usa privacidad. Cada uno decide cuál le encaja. Ellos lo llaman “privacidad programable + divulgación selectiva”; en otras palabras, privacidad y transparencia según se necesite.

La lógica de #dusk me convence mucho. Fue la primera vez que me hizo pensar que cumplimiento y privacidad no tienen por qué ser enemigos: más bien son como dos caras del mismo camino. ¿No es justo ese el rompecabezas que siempre le ha faltado a la banca tradicional? Pero, dicho sea de paso, por muy bonito que sea el concepto, al final hay que pasar la prueba de la realidad. Que las instituciones quieran pagar, que el regulador lo acepte y que, al ejecutarlo de verdad, todo funcione bien… todo depende de validarlo con el tiempo. Con la moneda DUSK, no te subas a la ola por un eslogan: el trabajo (la investigación) sigue siendo tu responsabilidad.

Las imágenes del sistema de videovigilancia muestran que el miércoles por la tarde, a las tres, una persona entró en el recinto por la puerta. Pero las grabaciones solo muestran; no determinan si esa persona es un ladrón. La determinación corresponde al personal de seguridad, a la administración del inmueble y a la policía. El mundo cripto es igual: los datos son datos, el juicio es juicio, pero muchas personas los confunden.

En el libro blanco @BabylonLabs_io aparece repetidamente una palabra: "price oracle", oráculo de precios. En la tabla comparativa de la Sección 4, la primera fila dice: "todas las soluciones dependen de un oráculo de precios confiable: una necesidad que no se puede evitar en el préstamo con garantía". El libro blanco usa dos términos para describirlo: "trusted" y "unavoidable"; confiable e inevitable. Luego salta al siguiente párrafo, como si pasara junto a una habitación en la que no quiere quedarse.

El problema de los oráculos no es que puedan ser atacados; de eso ya se ha hablado bastante. El verdadero problema es que incrustan juntos "hechos objetivos" y "juicios humanos". Si el precio del BTC cae por debajo de 50.000 dólares, se ejecuta la liquidación: parece una condición objetiva, verificable y ejecutada de forma mecánica. Pero las palabras "precio del BTC" en sí mismas son un paquete completo de valoraciones: ¿el precio de qué exchange? ¿promedio ponderado por volumen o por tiempo? ¿se incluye la volatilidad implícita del mercado de opciones? ¿contar o no una caída del tipo "flash crash"? El oráculo no entrega hechos objetivos, sino un producto de datos que ha sido procesado mediante una metodología específica.

Las transacciones prefirmadas del bóveda se activan cuando se cumple la "condición de precio", pero no distingue si ese precio proviene del promedio ponderado de 20 exchanges, o si proviene de una cotización instantánea de un exchange pequeño con liquidez agotada. La Sección 5 menciona que el liquidador "supervisa el precio y el estado de la bóveda": esa acción de "supervisar" ya implica un juicio. El liquidador no es una máquina; elegirá en qué fuente de datos confiar y en qué momento actuar. Aunque un sistema esté diseñado como "ejecución mecánica", el último ejecutor sigue siendo humano. #baby

El rol de gobernanza de $BABY : lo que realmente hay que definir no son parámetros técnicos, sino "los límites entre los hechos y el juicio". La elección del oráculo, las reglas para gestionar precios anómalos y la ventana de revisión manual después del disparo de la liquidación: estas son las piezas duras que debe masticar la gobernanza. La ejecución hace liquidaciones con código, pero el código no sabe lo que significa un "precio razonable". DYOR.

¿Alguna vez has probado a comprar cosas en sociedad con alguien? Por ejemplo, alquilar en común una videoconsola: acordáis que cada uno la use durante tres días. La primera semana todo va bastante bien; la segunda, alguien empieza a retrasarse; para el tercer mes, no se sabe ya ni en qué casa está la consola. El peor enemigo de los bienes compartidos, a menudo, no es la mala intención, sino el desgaste cotidiano de la colaboración.

@BabylonLabs_io En el “whitepaper” hay una frase tranquila que se queda ahí, casi nadie la lee dos veces: “A cada bóveda le corresponde un UTXO”. El significado técnico es muy directo: tu bitcoin no entra en una gran piscina, sino que queda bloqueado en una salida de transacción que puede ser señalada con claridad en el libro mayor de Bitcoin. Pero el significado económico es mucho más profundo: esa bóveda es un bien compartido entre ti y la contraparte, aunque su “prueba de propiedad” en la cadena es de sí o no: o todavía no se ha gastado, o ya se ha gastado. Esas relaciones complejas de copropiedad, en la cadena no se ven.

Y de ahí surge un problema. Bob y Larry se enfrascan en una disputa durante la ejecución de la bóveda: no es un conflicto malicioso que requiera activar un mecanismo de desafío, sino una fricción de nivel civil. Bob quiere amortizar antes; Larry no. Larry quiere ceder el crédito a un tercero; Bob no reconoce a ese cesionario. No hay fraude de por medio; además, en las transacciones prefirmadas no se les dejaron rutas alternativas para estos casos, y en la cadena de Bitcoin tampoco existe un mecanismo de mediación. Así que los dos solo pueden hablar en privado. ¿Y si no llegan a un acuerdo? Entonces la bóveda se convierte en una especie de cárcel que no se puede abrir.#baby

$BABY En la gobernanza descrita en el whitepaper, a largo plazo podría montarse aquí una capa de coordinación “blanda”: introducir plantillas estandarizadas de arbitraje, listas blancas para la cesión de créditos, o incluso establecer un periodo de enfriamiento para la negociación. Pero esto no son huesos que la criptografía pueda “morder”; es construcción institucional. El UTXO le da a la bóveda una atomicidad limpia y directa, pero también le corta, de un tajo, el espacio gris que hace falta para los bienes compartidos.

Un enigma bastante interesante: la seguridad de la bóveda proviene precisamente de que no tiene zonas ambiguas, pero las actividades financieras a las que tiene que servir—préstamos, garantías, liquidaciones—están llenas, de principio a fin, de zonas grises que requieren juicio humano. BABY, probablemente sea esa línea que los tenedores de moneda trazan a pulso entre claridad y ambigüedad. DYOR.

¿Alguna vez has perdido un encendedor desechable? No te lo robaron: lo usaste y, sin querer, lo dejaste por ahí. Desde el día de su fabricación estaba destinado a alcanzar solo para encender unas decenas de cigarrillos, y luego se convertía en un simple residuo de plástico. En el mundo cifrado también existe algo “desechable” de este tipo, solo que fue diseñado a propósito para ser así.
@BabylonLabs_io , cuando describe el flujo del desafío, se llevó de paso un detalle con sabor claramente técnico: la parte desafiada debe presentar una “firma de Lamport” para responder en juicio. La firma de Lamport es una de las propuestas más antiguas de firmas poscuánticas en criptografía, pero tiene un temperamento bastante especial: un par de claves solo se puede usar una vez. Después de firmar una vez, la clave queda inutilizable; reutilizarla hace que la seguridad caiga a cero de inmediato. El whitepaper la toma como herramienta para verificar el desafío, pero, casi sin querer, introduce un contador “invisible” dentro del sistema del monedero.

¿Qué significa esto? Que cada vez que Bob o Larry es desafiado, y cada vez que se le obliga a comparecer, va quemando un conjunto de material de clave que solo puede usarse una vez. No son claves generadas temporalmente: se calculan con antelación y se almacenan cuando se crea el monedero. Si una persona interviene en varios monederos, o si el mismo monedero es desafiado repetidamente, su reserva de claves se irá agotando poco a poco. ¿Qué hacer cuando se acaban? El whitepaper no da respuesta. ¿Se congela el monedero? ¿Se cierra forzosamente? ¿Se cambia automáticamente a un plan de respaldo? Es una deuda técnica que se salta en silencio.

La función de gobernanza de $BABY , en cambio, aquí sí puede servir. Cuántos conjuntos de claves Lamport se preconfiguran por cada monedero, cuál es la estrategia de respaldo cuando se agotan, y si en un estado de emergencia se puede forzar la liberación mediante votación de gobernanza… son preguntas que la capa de gobernanza tarde o temprano tendrá que contestar. El problema es que la velocidad a la que se consume una firma de Lamport depende totalmente de lo frenético que sea un desafío malicioso, y la frecuencia de esos desafíos maliciosos no se puede predecir. Un monedero al que apuntan para asediarlo hasta la muerte podría quemar toda su reserva de claves en cuestión de horas. #baby

La fragilidad de un sistema de no-confianza, a veces, no está escondida en las arterias principales, sino en los rincones del manejo de recursos. La firma de Lamport es precisamente un “recorte” de este tipo: pequeña, nadie la menciona normalmente, pero cuando llega el momento de usarla y ya se termina, se vuelve un asunto enorme. DYOR.

加密圈对“池”这个字有种莫名的迷恋——流动性池、借贷池、抵押池。听得久了，你很容易生出一种错觉，以为钱往池子里一倒，就自动融成了一种均匀的、随处可舀的液体。可比特币金库压根不是池子，是保险柜。一池水跟一排保险柜，是两样完全不同的东西。

@BabylonLabs_io 白皮书讲借贷金库设计时，埋了一句特别容易被扫过去的话：“金库创建需要 k-of-n 个清算人共同签名。”乍看就是个技术参数，但它其实悄悄定义了整套系统的物理形态——不是一大口池子，而是 n 个独立保险柜，每个柜子上挂 n 把锁，凑够任意 k 把就能开。这就不由得让人多想一步：不同保险柜上的那排锁，是同一批人吗？

要是同一批清算人管着所有金库，那这系统骨子里还是池子——清算风险被集中到了同几个人身上。可如果每个金库都由不同的清算人组合来管，这帮人彼此之间怎么协调？白皮书里补了一句“大额出资人也能参与签名”，却没回答一个更扎手的操作问题：当某个金库触发清算条件，那 k 个攥着钥匙的人里头，到底谁去执行？是头一个抢到机会的人独吞，还是按比例分配？要是前者，清算人之间就成了抢跑游戏，慢的永远喝不到汤，慢慢就没人干了。要是后者，就得有一套分配规则——谁写？怎么强制？#baby

$BABY 的治理功能，真正要解的就是这类协调死结。清算人怎么注册、怎么轮换、收益怎么分、抢跑怎么防，这些全不在金库的预签名交易里，全在治理参数里蜷着。金库只管锁的结构长什么样，可谁管钥匙、管钥匙的人之间怎么排班干活，这些问题被白皮书用“k-of-n”四个字符一把打包压缩了。

去中心化从来不是把一个大锁敲碎成一堆小锁就完事了。真正的坎，是锁和钥匙之间怎么配。DYOR。

¿Alguna vez te has quedado mirando la ranura de salida de una máquina expendedora esperando a que caiga algo? Echas la moneda, presionas los botones, escuchas un “¡clonc!” apagado desde adentro… y se atora. No cae la mercancía, pero el dinero ya te lo han cobrado. Le tomas fotos a la máquina, contactas con soporte, completas un ticket… te pasas un buen rato; no es solo por esos pocos billetes, es por la falta de respeto. El proceso se queda a la mitad, en un estado intermedio: que se trabe de esa forma molesta más que si ni siquiera llegara a empezar.

@BabylonLabs_io El whitepaper de “paper blanco” dibuja con claridad la ruta feliz del cofre del tesoro: depósito, acuñación de monedas, retiro y destrucción; principio y fin encajan, como un mapa de líneas de metro. Pero no desarrolla un fantasma que todos los sistemas de cross-chain inevitablemente tienen que enfrentar: el fallo de la confirmación entre pasos. Se supone que el prestatario envía la información UTXO del cofre a la cadena de contratos, y después de que un cliente ligero valida con éxito, se acuña el collBTC. La descripción promete que es “de una sola vez”, en orden. En la realidad, eso es como el apretón de manos entre dos redes asíncronas: Bitcoin suele generar un bloque cada diez minutos, mientras que la cadena de contratos puede generar uno en cuestión de segundos. En la diferencia de tiempos en que la información llega, el estado del cofre queda separado en dos cadenas.

¿Y si la transacción de acuñación se envía y, justo en ese momento, en Bitcoin se dispara un gasto inesperado? ¿Y si el cliente ligero, debido a una bifurcación transitoria, sincroniza con el encabezado de un bloque incorrecto? Eso no es un ataque: es una respiración normal a nivel de red. Pero la lógica de prefirmas del cofre asume que el mundo es un bloque de metal: si bloqueas, entonces está bloqueado; si acuñas, entonces está acuñado. Capa por medio, ese estado gris, suspendido e que requiere juicio humano, todo queda aplastado por el whitepaper en el hueco vacío entre flecha y flecha. #baby

$BABY Estar en esa posición no es un asunto técnico, sino de gobernanza. Cuando ese estado intermedio de verdad cae y el sistema no te prepara una ruta automatizada para manejarlo, ¿quién decide y arbitra? El marco de gobernanza del whitepaper, dicho en pocas palabras, es dejar una puerta trasera para excepciones que el código no puede cubrir. Pero el problema es que la respuesta de la gobernanza se mide en días e incluso semanas, mientras que el “derrape” del estado en la cadena se mide en segundos. Cuando termines de votar aquí, de seguro para allá ya estará todo pasado.

Esto no es un callejón sin salida que tenga que enfrentar solo Babylon. Cualquier sistema que intente construir lógica síncrona sobre redes asíncronas tiene que convivir con este fantasma. El whitepaper no lo escribe no porque no exista, sino porque sencillamente no se puede escribir en un whitepaper. DYOR.

Hay una regla no escrita en los casinos: si ganas demasiadas veces seguidas, el casino puede pedirte que te vayas. No es que te hayan pillado haciendo trampas; es que has roto el modelo de probabilidades. Esto me recuerda a un diseño sumamente sutil en el libro blanco @BabylonLabs_io — “Fracaso en el desafío: cancelación del derecho a retiros futuros”.

El libro blanco de Babylon explica con bastante claridad el proceso de desafíos de BitVM3: si Larry inicia un desafío malicioso, confunde el circuito para que lo desmonten y Bob se lleva en una sola jugada el secreto, entonces no solo pierde la fianza, sino que también “pierde el derecho a retirar en el futuro tras el desafío”. Esa frase está incrustada en medio de una maraña de descripciones técnicas, pasa casi desapercibida; pero es precisamente ese el muro invisible que sostiene todo el sistema de juego.

En realidad, este diseño intenta prevenir algo que está muy escondido: no la malicia directa, sino la “malicia de prueba”. Piensa esto: si un liquidado pudiera lanzar desafíos una y otra vez —pierde y paga un poco, y luego vuelve a jugar— tendría incentivos para usar desafíos de alta frecuencia como sondas, pinchando los límites del sistema ronda tras ronda. Apuesta a que el otro no se atreve a responder, o a que él mismo acabará chocando contra un punto que pruebe una vulnerabilidad. Así, convierte el “fallo del desafío” en una guerra de desgaste. Pero la penalización de “cancelar el derecho futuro” corta el bucle de golpe: haces una sola ronda fallida, y si fallas, quedas fuera. No es un “sigue pagando para repetir”; es un billete de ida.

Sin embargo, con un diseño así también surge un nuevo problema: ¿y si hay una falsa acusación por buena fe? ¿Si el retador por retrasos del oráculo, desajustes de sincronización de datos, o simplemente por pulsar mal el cálculo, lanza un desafío que es sincero pero técnicamente sale mal, también queda automáticamente fuera para siempre? El libro blanco no distingue “malicia” de “mala interpretación”; la capa de ejecución solo mira el resultado. Esto equivale a aplastar la zona gris donde el juez tiene discreción y convertirla en un interruptor binario y frío. #baby

$BABY está justo en el lugar del libro blanco donde se puede rellenar ese vacío. La gobernanza puede decidir directamente cuánto tiempo se cancela la elegibilidad, si existe un canal de apelación y cómo puede la gente que fue malinterpretada volver poco a poco. El código solo se encarga de ejecutar la sanción con frialdad e imparcialidad; y la gobernanza es la que define qué cuenta como “malicia”. En otras palabras, BABY es la última porción de “humanidad” que los titulares de la moneda mantienen bien agarrada como poder de discreción. DYOR.

En un tribunal existe un rol llamado “testigo experto”. No está del lado del demandante ni del demandado, pero en cuanto habla, la balanza de la sentencia se inclina. En el mundo cripto también hay alguien así, solo que la mayoría nunca lo mira a la cara. El libro blanco le da vueltas y vueltas, pero siempre lo envuelve en una capa de tecnicismos, sin mostrar de verdad la lógica de poder que hay detrás.

@BabylonLabs_io El libro blanco, en su sección 5, habla de préstamos; en la 6, de stablecoins; en la 7, de contratos perpetuos. Tres escenarios que no tienen nada que ver entre sí, pero que sin embargo comparten la misma frase: “Se necesita un oráculo de precios confiable”. Fíjate bien en el adjetivo: “confiable”. Toda la arquitectura del sistema de bóveda está empeñada en minimizar la confianza. Bob no necesita confiar en Larry, y Larry tampoco necesita confiar en Bob. Los liquidadores quedan sujetos a la estructura de juego, y los retadores se ven aprisionados por los depósitos de garantía. Solo el oráculo, el libro blanco lo admite como “inevitable” y luego deja la cosa ahí.

La función del oráculo es tan simple como puede ser: le dice a la bóveda cuánto vale BTC en este momento. Si el precio cae y atraviesa el nivel de liquidación, se activa la liquidación; si el precio vuelve lentamente, todo sigue igual. Pero ese acto de “decir”, precisamente, es el único punto de poder dentro del sistema que no se puede eliminar usando pruebas de conocimiento cero ni circuitos de ofuscación. Lo que el oráculo “alimenta” como precio, la bóveda ejecuta como resultado. No tiene que robar tus claves privadas: solo necesita, en el momento más crucial, dar un precio crucial. Si se informa con más de cien dólares o con menos de cien dólares, eso determina si tu Bitcoin queda tranquilo y seguro, o si el martillo de la liquidación lo corta de un tajo.#baby

$BABY El lugar que ocupa en ese agujero negro de poder es sugerido, en realidad, en la sección 10, aunque sin decirlo del todo: gobernanza. ¿A qué oráculo se elige? ¿Quién es el candidato alternativo? ¿Cuánto retraso en la entrega del precio se considera anómalo? ¿Cuando hay anomalía se pausa la liquidación o se cambia a una fuente de datos de respaldo? Todo eso no está escrito de forma rígida en el código de la bóveda, sino incrustado en los parámetros de gobernanza. Quien tiene en sus manos BABY está, precisamente, cercando esa “única brecha de confianza” con vallas que se colocan una tras otra.

Un techo de seguridad de un sistema sin confianza, finalmente apoyado en el componente que es el que menos confía. El oráculo es ese componente. Por más bonita que esté la bóveda, en última instancia, está trabajando para el oráculo. DYOR.

El “depósito de alquiler” es algo que cuando lo entregas es rápido, pero cuando lo devuelven se vuelve una molestia. El casero siempre encuentra una excusa para descontarte un poco: que se caen trozos de pintura en la pared, que el grifo está flojo, que la campana extractora no se limpió bien. El depósito queda en sus manos, y la capacidad de explicar la situación crece en su boca. Esto me hizo pensar, de golpe, en un detalle en la sección 3 del Libro Blanco: algo mencionado de manera ligera, pero que al pensarlo con calma da escalofríos. El “bond” de la bóveda, esa cantidad de depósito bloqueada por adelantado para evitar el fraude. El equipo del proyecto solo dejó una frase: “Se devolverá después de que la bóveda se cierre”.

“Se devolverá”. ¿Quién lo devuelve? ¿Cómo se devuelve? ¿Cuánto se devuelve? Esas tres preguntas el Libro Blanco no las desarrolló, pero precisamente tocaron la vena más frágil del sistema de la bóveda.

Volvamos al diseño del mecanismo de la sección 3 del Libro Blanco de @BabylonLabs_io : Bob y Larry depositan cada uno una suma en la cadena como penalización por fallar el desafío. La intención original era muy directa: para disuadir los desafíos maliciosos; si tú armas líos y pierdes, pagas. Pero, ¿y si el escenario cambia? Si ambas partes cumplen correctamente, cuando la bóveda llega a su vencimiento y se cierra de forma normal, ¿cómo vuelve ese depósito a su origen? ¿Se reembolsa automáticamente? ¿O requiere que ambas partes vuelvan a firmar en conjunto? Si fuera lo segundo, entonces la devolución del depósito se convierte en un nuevo juego: una parte podría deliberadamente retrasar la firma, usando el costo del tiempo como chantaje para forzar concesiones del otro. El depósito existía para eliminar el juego… pero al final, la devolución del depósito genera otro juego.

$BABY , colocado en ese rincón muerto, resulta muy sutil. La sección 10 lo define como un token de gobernanza, y la “regla de devolución del depósito” justo es un tema de gobernanza por excelencia: ¿cómo se determina el monto del depósito? ¿Cuánto tiempo hay para devolverlo? Si una parte no coopera con la firma, ¿existe un mecanismo de liberación forzosa? En cuanto esos parámetros se incrustan en el código, se vuelven ley. Pero antes de incrustarlos, esos parámetros fueron votados por los tenedores de tokens. BABY no puede controlar las pequeñas artimañas entre Bob y Larry, pero sí encierra las reglas que acotan los límites del juego. #baby

Lo que más teme un sistema sin confianza es que, más que un mal actor que haga daño abiertamente, sean las buenas personas las que, lentamente, se ven forzadas por los huecos de las reglas hasta convertirse en “malas”. Y la acción de “devolver el depósito” es precisamente ese hueco. DYOR.

Cuando se lanzan cohetes, lo que consume combustible de verdad no es flotar en el espacio, sino esos decenas de segundos en los que se empuja con fuerza desde el suelo hacia arriba: la gravedad es más pesada, y cada gramo de peso hay que compensarlo con varias toneladas de empuje. Esto me recuerda un rincón silencioso de la whitepaper del que casi nadie habla: el problema del arranque en frío de un sistema que minimiza la confianza.

@BabylonLabs_io La whitepaper, en la sección 1, lo admite sin rodeos: los puentes actuales de Bitcoin requieren “un comité de firmantes, un grupo de operadores y un grupo de retadores”; las tres partes se controlan entre sí para que el puente pueda funcionar. La lógica de un monedero (vault) que minimiza la confianza es aún más dura: elimina las dos primeras partes y deja solo a los retadores. Pero aquí está el atasco: cuando el sistema parte de cero, ¿quién es el primero en dar el paso con el pie?

La sección 3, eso sí, responde con total honestidad. BitVM3 exige que Bob y Larry generen mutuamente para el otro un circuito de ofuscación de 43GB, pero el requisito para poder hacerlo es que ambas partes ya confíen en que la otra cooperará bien para completar la configuración. Primero tienes que intercambiar claves con la otra parte, verificar que los circuitos sean correctos, y prefirmar conjuntamente las transacciones. Si ese paso no se puede hacer, el monedero no se puede construir. En resumen: arrancar un sistema “sin confiar en nadie” precisamente necesita un breve ritual “intensivo en confianza”. #baby

Este propio dilema no es una brecha, pero aun así fabrica un problema económico bien real: ¿quién corre con el costo de puesta en marcha? El operador tiene que quemar tiempo de CPU generando el circuito, y el liquidador tiene que inmovilizar un depósito para participar en la prefirmación; todo eso, mientras el ecosistema aún no despega, no genera ningún beneficio directo de inmediato. El plan de incentivos de la sección 10 de la whitepaper, $BABY , al final no es más que “inyectar velocidad de escape” en la fase de arranque en frío. Los subsidios de tokens rellenan a la fuerza el vacío de confianza que va de 0 a 1: cuando el sistema no tiene ingresos, los tokens son el motor de gravedad; y cuando el sistema ya se autofinancia, el mecanismo de quema cambia del motor a una bomba de extracción.

Un sistema que presume de eliminar la confianza, al nacer, en realidad tiene que apoyarse en incentivos tempranos para empujar a un grupo de personas a soportar el costo temporal de confianza. Esta contradicción no se disimula, es honesta. Todas las redes descentralizadas crecen así, tropezando y avanzando; solo que muy pocos se animan a escribirlo en la whitepaper con tinta y papel. DYOR.