Tadge Dryja, występujący w publikacjach jako Thaddeus Dryja, jest badaczem protokołów Bitcoina. Wraz z Josephem Poonem napisał propozycję Lightning Network. Jego inne prace obejmują Discreet Log Contracts, wykorzystujące podpisane informacje z zewnątrz, oraz Utreexo, sposób zmniejszenia ilości danych reprezentujących bieżący stan Bitcoina.
Wyobraź sobie, że węzły na całym świecie, czyli komputery sprawdzające zasady Bitcoina, muszą osobno sprawdzić każdą opłaconą kawę. Jak umożliwić więcej płatności bez coraz mocniejszych komputerów potrzebnych do prowadzenia własnego węzła? Joseph Poon i Thaddeus Dryja szukali odpowiedzi w sieci kanałów płatniczych. Podlinkowany whitepaper, czyli dokument wyjaśniający projekt, nosi datę 14 stycznia 2016 i oznaczenie DRAFT 0.5.9.2. To historyczna propozycja pomagająca zrozumieć początek pomysłu. Dokładnych zasad dzisiejszych programów trzeba szukać w ich własnej dokumentacji. [1]
Kanał płatniczy można sobie wyobrazić jako aktualizowaną umowę o podziale wcześniej wpłaconych bitcoinów. Każda płatność zmienia kwotę należną każdej stronie. Uczestnicy podpisują zmiany, ale nie publikują każdej z nich w blockchainie, wspólnej historii transakcji. Gdy współpraca się kończy, podział można wyegzekwować za pomocą transakcji Bitcoin. Lightning przenosi więc wiele aktualizacji poza blockchain, natomiast ostateczne rozliczenie nadal opiera się na zasadach Bitcoina. [1]
Wcześniejsza umowa może przyznawać większą kwotę komuś, kto zdążył już część wydać. W opisanym modelu unieważniania stanów publikacja starego stanu pozwala drugiej stronie odpowiedzieć transakcją karną. Trzeba jednak zdążyć w określonym terminie. Dlatego uczestnik albo upoważniony podmiot musi obserwować blockchain. Ma to praktyczne znaczenie: sama kryptografia nie sprawia, że trwałe odłączenie bez nadzoru jest bezpieczne. Zapewnienie niezawodnego monitorowania stanowi część ochrony środków. [1]
Bitcoin sam nie zna kursu waluty w uzgodnionym dniu. Discreet Log Contracts, czyli DLC, dotyczą umów, których rozliczenie zależy od takiej informacji. Dwaj uczestnicy przygotowują warunki i możliwe wypłaty. Wybrany oracle, zewnętrzne źródło danych, później podpisuje ogłoszenie wyniku. Uczestnicy wykorzystują je do odpowiedniego rozliczenia. Oracle w tym modelu nie przechowuje ich środków i nie musi wiedzieć, kto korzysta z ogłoszeń. Dostarcza informację, zamiast zarządzać cudzym portfelem. [2]
Podpis cyfrowy pomaga ustalić autora wiadomości i sprawdzić, czy została zmieniona. Nie dowodzi jednak prawdziwości danych. Oracle może podać niewłaściwy kurs albo niczego nie ogłosić. Na wypadek milczenia Dryja opisuje przygotowaną wcześniej transakcję zwrotu, możliwą do opublikowania po uzgodnionym czasie. Pieniądze nie wracają same: tę możliwość trzeba przewidzieć w umowie, a ktoś musi z niej skorzystać. Wybór wiarygodnego źródła i plan na jego awarię nadal są ważne. [2]
Dryja badał również ilość danych potrzebnych węzłowi do sprawdzania płatności. UTXO to niewydane wyjścia transakcji: poszczególne kwoty z warunkami ich wydania. Utreexo pozwala przedstawić ich zbiór w weryfikującym węźle za pomocą niewielkiego podsumowania kryptograficznego, zwanego akumulatorem. Do płatności dołącza się dowód, że wydawane wyjście należy do tego zbioru. Oszczędza to miejsce zajmowane przez bieżący stan. Nie znosi weryfikacji reguł ani nie zmniejsza całej historii Bitcoina do maleńkiego pliku. [4]
Dowody Utreexo trzeba także dostarczyć weryfikującemu węzłowi. Mniejszy zapisany stan może zatem oznaczać więcej przesyłanych danych. Abstrakt badawczy opisuje symulację pobierania blockchaina do początku 2019 roku: przy 500 MB przeznaczonych na cache, czyli pamięć podręczną, dowody zwiększyły ilość pobieranych danych o około 25%. Wartość 500 MB nie oznacza całej pamięci węzła. To wynik określonego eksperymentu, a nie gwarancja dzisiejszych wymagań. Oceniając oszczędność, trzeba uwzględnić dysk, pamięć i transmisję. [3]
We wspomnieniu opublikowanym przez MIT DCI Dryja opisuje swój nieformalny początek na MIT: przyniósł komputer, rozmawiał o Bitcoinie i pomagał studentom. Dyrektorka Neha Narula zapytała wtedy, czy chciałby tam pracować. Później wspólnie prowadzili zajęcia. W tym samym pożegnaniu ogłosił przejście do Lightspark i dalszą pracę nad Bitcoinem oraz Lightningiem. Relacja dokumentuje konkretny etap kariery, nie potwierdza obecnego zatrudnienia. Publikacje, kod i wyjaśnione pomysły mówią o jego wkładzie więcej niż jedno stanowisko. [5]
Pełniejszy obraz uzyskasz, czytając to hasło razem z Rusty Russell, Joseph Poon, Lightning Network. Do tego hasła prowadzą również odsyłacze z Rusty Russell, Joseph Poon.