Tadge Dryja, llamado Thaddeus Dryja en sus publicaciones, es investigador de protocolos Bitcoin. Escribió la propuesta de Lightning Network junto con Joseph Poon. Sus trabajos incluyen Discreet Log Contracts, que utilizan información externa firmada, y Utreexo, una forma de reducir los datos necesarios para representar el estado actual de Bitcoin.
Imagina que los nodos de todo el mundo, los ordenadores que comprueban las reglas de Bitcoin, tuvieran que verificar por separado cada café pagado. ¿Cómo permitir más pagos sin exigir ordenadores cada vez más potentes para mantener un nodo propio? Joseph Poon y Thaddeus Dryja exploraron una red de canales de pago. El whitepaper enlazado, un documento que explica su diseño, está fechado el 14 de enero de 2016 y marcado DRAFT 0.5.9.2. Es una propuesta histórica que ayuda a entender el origen de la idea; las reglas precisas de los programas actuales deben consultarse en su propia documentación. [1]
Un canal de pago puede entenderse como un acuerdo que se actualiza sobre cómo repartir bitcoins depositados de antemano. Cada pago cambia cuánto corresponde a cada parte. Los participantes firman esos cambios sin publicar cada actualización en la blockchain, el historial compartido de transacciones. Cuando termina la cooperación, una transacción Bitcoin permite hacer cumplir el reparto. Lightning puede trasladar muchas actualizaciones fuera de la blockchain, mientras la liquidación final sigue dependiendo de las reglas de Bitcoin. [1]
Un acuerdo anterior puede asignar más dinero a alguien que ya ha gastado parte de él. En el modelo de revocación descrito, publicar un estado invalidado permite que la otra parte responda con una transacción de penalización. Sin embargo, debe hacerlo dentro de un plazo determinado. Por eso, el participante o un vigilante delegado necesita observar la blockchain. La consecuencia práctica es clara: la criptografía no convierte en segura una desconexión permanente sin vigilancia. Organizar una supervisión fiable forma parte de proteger los fondos. [1]
Bitcoin no sabe por sí solo el tipo de cambio de una fecha acordada. Los Discreet Log Contracts, o DLC, permiten abordar contratos cuya liquidación depende de ese dato. Dos participantes preparan las condiciones y los pagos posibles. Un oracle elegido, es decir, una fuente externa de datos, firma después un anuncio del resultado. Los participantes lo utilizan para realizar la liquidación correspondiente. En este modelo, el oracle no custodia sus fondos ni necesita saber quién utiliza sus anuncios. Aporta información en lugar de administrar una cartera ajena. [2]
Una firma digital ayuda a comprobar quién emitió un mensaje y si fue modificado. No demuestra que la información sea verdadera. El oracle puede publicar un tipo de cambio erróneo o no publicar nada. Para ese silencio, Dryja describe una transacción de devolución preparada de antemano, que puede publicarse tras un plazo acordado. El dinero no vuelve solo: esa posibilidad debe estar prevista en el contrato y alguien tiene que utilizarla. Elegir una fuente fiable y planificar qué hacer si falla sigue siendo importante. [2]
Dryja también estudió los datos que necesita un nodo para verificar pagos. Los UTXO son salidas de transacción aún no gastadas: cantidades individuales sujetas a condiciones de gasto. Utreexo permite representar su conjunto en el nodo verificador mediante un resumen criptográfico compacto, llamado acumulador. El pago incorpora una prueba de que la salida utilizada pertenece a ese conjunto. Así se reduce la representación almacenada del estado actual. No desaparece la verificación de las reglas ni se comprime toda la historia de Bitcoin en un archivo diminuto. [4]
Las pruebas de Utreexo también tienen que llegar al verificador. Un estado almacenado menor puede requerir más datos transmitidos. El resumen de investigación describe una simulación de descarga de la blockchain hasta principios de 2019: al reservar 500 MB para caché, una memoria temporal, las pruebas añadían aproximadamente un 25 % de datos descargados. Esos 500 MB no son toda la memoria necesaria para el nodo. Es el resultado de un experimento concreto, no una garantía de los requisitos actuales. Hay que valorar juntos el disco, la memoria y las transferencias. [3]
En su recuerdo publicado por MIT DCI, Dryja cuenta un comienzo informal en el MIT: llevó un ordenador, conversó sobre Bitcoin y ayudó a estudiantes. La directora Neha Narula le preguntó entonces si quería trabajar allí. Más adelante también impartieron clases juntos. En esa misma despedida anunció su incorporación a Lightspark para seguir trabajando en Bitcoin y Lightning. El relato recoge una etapa concreta, no acredita su empleo actual. Sus publicaciones, su código y sus ideas explican mejor su contribución que un único cargo profesional. [5]
Para obtener la imagen más completa, lee esta entrada junto con Rusty Russell, Joseph Poon, Lightning Network. También enlazan con esta entrada Rusty Russell, Joseph Poon.