Ten artykuł dotyczy koncepcji technologicznej opartej na proponowanej aktualizacji protokołu Taproot. Jeśli nie znasz jeszcze podstaw działania Taproot, zalecamy, abyś najpierw przeczytał ten wyjaśniający.
Macica, potencjalna aktualizacja do protokołu Bitcoin, zaproponowana po raz pierwszy przez współpracownika Bitcoin Core, Gregory'ego Maxwella, jest na późnym etapie rozwoju. Technologia składa się z sprytnego połączenia sztuczek kryptograficznych, które pozwoliłyby użytkownikom ukryć złożone inteligentne kontrakty w ramach normalnie wyglądających transakcji - złożoność ujawnia się tylko wtedy, gdy strony umowy nie chcą współpracować.
Wykorzystując ten pomysł, współtwórcy Bitcoin Core, w tym (między innymi) Jeremy Rubin, Antoine Riard, Gleb Naumenko i sam Gregory Maxwell spekulowali na temat ogólnej koncepcji określanej jako pule płatności, wspólne pule lub pule monet. Te pule - na razie będziemy nazywać je pulami płatności - pozwoliłyby grupom użytkowników dzielić własność tych samych monet (technicznie: UTXO), jak zapisane w łańcuchu bloków Bitcoin, jednocześnie pozwalając każdemu z tych użytkowników dokonywać (lub otrzymywać) płatności z nimi. Ponieważ grupa i jej poszczególni członkowie „chowają się” w strukturze Taproot, wszyscy cieszą się większą prywatnością, elastycznością inteligentnych kontraktów i innymi korzyściami… i potencjalnie nawet korzystają z tych korzyści poza łańcuchem, co sprawia, że pule płatności stają się nowym rozwiązaniem warstwy drugiej.
Chociaż szczegóły projektu różnią się nieco w zależności od propozycji puli płatności, ogólna koncepcja jest taka sama. Oto podstawowa idea…
Dzielenie się monetą
Po pierwsze, aby utworzyć pulę płatności, użytkownicy łączą swoje monety (ułamki), agregując je we wspólnym adresie Taproot. Powiedzmy, że Alicja ma trzy monety, Bob ma dwie monety, a Carol jedną monetę, w sumie sześć. Wspólnie tworzą transakcję, która wysyła te monety na wspólny adres, tworząc pulę płatności z sześcioma monetami.
W łańcuchu bloków adres puli płatności wygląda jak zwykły adres Bitcoin, w którym znajduje się teraz sześć monet. Ale pod powierzchnią Alice, Bob i Carol sprytnie wykorzystali Taproot, aby zapewnić, że każdy z nich ma kontrolę nad własnym udziałem monet w puli płatności. Alicja może w dowolnym momencie odebrać trzy monety z adresu, Bob może w dowolnym momencie odebrać dwie, a Carol jedną.
Dzieje się tak, ponieważ istnieją tylko dwie główne opcje wydawania monet z adresu.
Pierwsza opcja polega na wydaniu bezpośrednio z adresu, pod względem technicznym ścieżki klucza Taproot. Wymaga to współpracy (czyli podpisów kryptograficznych) od wszystkich trzech uczestników. Jeśli Alice, Bob i Carol wszyscy się zgodzą, sześć monet można wydać w dowolny sposób, a to będzie wyglądać jak każda inna zwykła transakcja w sieci Bitcoin. Trio może na przykład zdecydować o wysłaniu swoich sald z powrotem na indywidualne adresy: trzy dla Alice, dwa dla Boba i jeden dla Carol. Ale gdyby tak wybrali, mogliby również współpracować, aby przekazać wszystkie sześć monet Julianowi lub wydać je w inny sposób, na jaki się zgodzą. Ważne jest to, że wszyscy trzej muszą uczestniczyć, więc nikt nie traci równowagi bez jego własnej współpracy.
Druga główna opcja w rzeczywistości składa się z kilku podwariantów. Przed wysłaniem swoich monet do puli płatności Alice, Bob i Carol ukryli coś w drzewie kryptograficznym za adresem Taproot: uwzględnili alternatywne sposoby przesyłania środków z puli płatności. (Obecnie można to zrealizować, zlecając wszystkim trzem uczestnikom wstępne podpisywanie transakcji z tych ścieżek, co wymagałoby pewnej złożoności w celu skonfigurowania wszystkich opcji i nie skaluje się zbyt dobrze; proponowane aktualizacje protokołów mogą potencjalnie ułatwić to w przyszłości .)
Jeśli jeden z uczestników zdecydowałby się wydać monety z puli płatności za pośrednictwem alternatywnej ścieżki Taproot, zazwyczaj wysyłałby kwotę odpowiadającą saldzie tego uczestnika na wybrany przez siebie adres, taki jak indywidualny adres, który kontroluje. (W przypadku Alice trzy monety na jej własny adres, w przypadku Boba dwie na jego adres, aw przypadku Carol jedną).
Korzystając z tej alternatywnej ścieżki, pozostałe monety również są automatycznie wydawane. Można to zrobić na kilka sposobów, w zależności od projektu puli płatności, oferując różne kompromisy pod względem złożoności i skalowalności.
Najprostszym rozwiązaniem jest przesłanie wszystkim pozostałym uczestnikom udziału w monetach pod wskazany przez nich adres. Innymi słowy: jeśli jeden użytkownik opuści pulę, wszyscy opuszczają pulę.
Drugim rozwiązaniem, preferowanym przez Riarda i Naumenko, jest wysłanie wszystkich pozostałych monet do nowa pula płatności, która wygląda dokładnie tak, jak pierwsza pula płatności, po prostu pozbawiona wszystkiego, co dotyczyło już opuszczonego użytkownika. Ten projekt zapewnia najlepsze wrażenia użytkownika, ale jest najtrudniejszy do skalowania, co najważniejsze, ponieważ konieczne jest przygotowanie na wszystkie możliwe scenariusze wyjścia, w tym wszystkie możliwe scenariusze wyjścia dla wszystkich potencjalnych nowych pul. Skalę można jednak osiągnąć dzięki jeszcze nie nazwanej potencjalnej aktualizacji protokołu Bitcoin, aby zapewnić, że zasady z poprzedniej puli płatności zostaną przeniesione do nowej puli płatności.
Rubin uważa jednak, że to drugie rozwiązanie jest niepraktyczne i woli wybrać coś pomiędzy pierwszym a drugim rozwiązaniem: niektórzy uczestnicy natychmiast otrzymują swoje monety na wybrany przez siebie adres, inni uczestnicy wysyłają swoje monety do nowej puli płatności. Ten projekt oferuje mniej idealne wrażenia użytkownika, ale lepiej skaluje się, a potencjalna aktualizacja protokołu OP_CHECKTEMPLATEVERIFY pomogłaby uprościć projekt i jeszcze bardziej zwiększyć skalę. (Wyjście nastąpiłoby za pośrednictwem płatności w drzewie; te typy płatności są analizowane w dalszej części ten artykuł.)
(Istnieje więcej kompromisów między drugim a trzecim rozwiązaniem, ale szczegóły wszystkich za i przeciw są poza zakresem tego artykułu; przeczytaj Dyskusja na liście mailingowej bitcoin-dev dla szczegółów.)
Aby zobaczyć, co to znaczy, że pozostałe monety są wysyłane do nowej puli płatności, powiedzmy, że Alicja, Bob i Carol wybierają drugą opcję, gdzie cała kolekcja pozostałe monety są wysyłane do nowej puli płatności. Jeśli w tym projekcie Alicja opuści pierwszą pulę płatności, trzy monety są wysyłane na wybrany przez nią adres, podczas gdy pozostałe trzy monety są wysyłane do nowej puli płatności między Bobem i Karolem. W tym momencie Alice ponownie ma wyłączną kontrolę nad swoimi własnymi monetami, podczas gdy dla Boba i Carol niewiele się zmieniło. Obaj mogą nadal współpracować, aby wydać pozostałe trzy monety, jak chcą, lub każdy z nich może jednostronnie wyjść, tak jak zrobiła to Alice wcześniej.
Jeśli Bob następnie jednostronnie wyjdzie z drugiej puli płatności, wysyła dwie monety na wybrany przez siebie adres i jedną monetę do jeszcze nowszej puli płatności (trzeciej), w której pozostała tylko Karolina. (Oczywiście w tym uproszczonym przykładzie projekt, w którym ostatnia pula płatności jest zastępowana adresem wybranym przez Carol, miałby w rzeczywistości więcej sensu, ale to jest szczegół implementacji).
Ważnym wnioskiem jest to, że uczestnicy puli płatności mogą współpracować, aby dokonać dowolnego rodzaju płatności z puli, którą chcą, podczas gdy każdy z nich może w dowolnym momencie wyjść z własnymi monetami, pozostawiając innym uczestnikom kontrolę nad swoimi.
Umieszczanie płatności w puli płatności
Dlatego ustaliliśmy, że wszyscy uczestnicy mogą indywidualnie wypłacić swoje saldo z puli płatności lub - jeśli wszyscy się zgodzą - wydać z puli. To właśnie ta druga opcja faktycznie umożliwia coś sprytnego: pula płatności może być dynamiczna. Dopóki wszyscy uczestnicy się zgodzą, nie mogą po prostu zwrócić sobie swoich funduszy lub zapłacić innym (jak Julian), ale mogą zrobić coś jeszcze ciekawszego. Mogą przenosić swoje fundusze do nowszych wersji puli płatności, z różnymi projektami.
To na przykład pozwala każdemu z nich wydać z puli.
Powiedzmy, że Alicja kupuje nowy samochód i chce za niego zapłacić jednym bitcoinem. Alice, Bob i Carol mogą następnie utworzyć transakcję z puli płatności, która wysyła jedną monetę do salonu samochodowego, a pozostałe pięć monet do nowa pula płatności, która wygląda tak samo jak pierwsza, z tym wyjątkiem, że tym razem Alicja może wyjść z niej jednostronnie tylko z dwoma monetami, o jedną mniej niż wcześniej.
W międzyczasie transakcja wyglądała jak każda inna zwykła transakcja Bitcoin. Sprzedawca samochodów (lub szpiedzy blockchain) może dojść do wniosku, że Alicja była właścicielem wszystkich sześciu monet i po prostu wykorzystała jedną do zakupu samochodu, a pozostałe pięć zachowała jako zmianę. Nie mieliby pojęcia, że niektóre monety należą do Boba i Carol lub że w ogóle byli zaangażowani w transakcję.
Następnym razem, gdy Bob dokona płatności, a Alice i Carol współpracują, jest ona dokonywana z tej samej puli płatności, ponownie wyglądając jak zwykła transakcja Bitcoin dla świata zewnętrznego. W wynikowej iteracji puli płatności Bob może wyjść z jedną monetą zamiast dwóch. W międzyczasie ci sami szpiedzy blockchainowi mogli pomyśleć, że Alice ponownie dokonuje płatności, co jeszcze bardziej ich dezorientuje. (I nawet gdyby szpiedzy blockchainowi w jakiś sposób zorientowali się, że adres jest tak naprawdę pulą płatności między Alice, Bobem i Carol, nadal nie mogliby powiedzieć, który z tych trzech dokonał ostatniej płatności.)
Za każdym razem, gdy Alicja, Bob lub Carol wydają monety, transakcja może pochodzić od któregokolwiek z nich i nikt spoza puli płatności nie może stwierdzić różnicy.
Pule płatności nie tylko pozwalają na wydawanie pieniędzy. Jeśli Alicja chce uzupełnić swoje „saldo” w puli płatności, też mogłaby to zrobić. W tym przypadku Alicja, Bob i Carol współpracowaliby w celu przeniesienia obecnych pięciu monet na nowy adres Taproot, na który Alicja w tej samej transakcji wysłałaby jedną dodatkową monetę z jednego ze swoich (indywidualnych) adresów. Nowy adres Taproot znów będzie zawierał sześć monet, z których trzy należą do Alicji, co odzwierciedla jej opcja jednostronnego wyjścia.
W ten sam sposób do puli płatności mogli dołączyć także zupełnie nowi użytkownicy. Jeśli Alice, Bob i Carol zgodzą się pozwolić Dave'owi uczestniczyć, cała trójka współpracuje z Dave'em, aby stworzyć transakcję, która wyśle środki z puli płatności wraz z nowymi monetami Dave'a do nowej puli płatności, zaprojektowanej tak, aby również Dave mógł wziąć udział - i wyjść gdyby tak wybrał.
Ponadto uczestnicy z puli płatności mogą płacić sobie nawzajem. Gdyby na przykład Alicja zapłaciła Bobowi jedną monetę, cała trójka mogłaby współpracować w celu wysłania środków do nowej puli płatności, w której Alice ma monetę odjętą od jej salda, a Bob ma dodaną monetę. Na blockchain znowu wyglądałoby to jak zwykła płatność, a szpiedzy na blockchainie nie mieliby pojęcia, kto zapłacił komu i ile. (Warto zaznaczyć, że Dave mógł w podobny sposób wejść do puli, otrzymując wewnętrzną wpłatę od jednego z dotychczasowych uczestników.)
Przy odrobinie dodatkowej złożoności (i najlepiej z co najmniej jednym dodatkowym uaktualnieniem protokołu Bitcoin, takim jak Brak wejścia), transfery mogą być realizowane nawet poza łańcuchem. Kiedy Alicja płaci Bobowi, wszyscy uczestnicy w tym przypadku utworzyliby transakcję wydatkującą fundusze na nową pulę płatności, ale ta transakcja byłaby dzielona tylko między nimi - nie transmitowana do sieci (chyba że ktoś kiedykolwiek próbowałby oszukiwać). W ten sposób Alice, Bob i Carol mogli aktualizować swoje saldo „wewnętrznie”, a nawet wpuścić Dave'a do puli w pewnym momencie. Kiedy wszyscy zgodzą się na zamknięcie puli, mogą utworzyć ostateczną transakcję, która wydaje z pierwotnej puli płatności, przyznając każdemu ostatnie saldo.
Podobny do starszego pomysłu znanego jako Fabryki kanałów, te typy puli płatności mogą w końcu być nawet używane do obsługi kanałów Lightning, skarbców lub innych protokołów warstwy drugiej. Może to stwarzać możliwość „zawinięcia” dowolnej dodatkowej warstwy protokołu w takie pule, ukrywając w ten sposób całą ich złożoność w identycznych i wyglądających normalnie transakcjach.