Covenants

Anna oszczędza w Bitcoinie. Portfel to aplikacja lub urządzenie do odbierania i wysyłania bitcoinów. Saldo widoczne w jej portfelu składa się z niewydanych jeszcze wyjść wcześniejszych transakcji, nazywanych UTXO. Każde wyjście zawiera kwotę oraz warunki jej wydania, zapisane w krótkim programie Bitcoin Script. Podpis cyfrowy potwierdza autoryzację płatności za pomocą klucza prywatnego, czyli tajnej wartości liczbowej, bez ujawniania tego klucza. Multisig może wymagać kilku podpisów, a Timelock dodaje warunek oczekiwania. Covenant może również ograniczyć konstrukcję następnej transakcji, na przykład wyjścia, do których mają trafić środki. Takiej reguły musiałby przestrzegać nawet złodziej z właściwym kluczem. Trzeba jednak uwzględnić wszystkie możliwe ścieżki wydania: jeśli inna gałąź pozwala ominąć ograniczenie, nie można na nim polegać. [1] [5] [9] [11]

Wyobraźmy sobie, że Anna umieszcza oszczędności w skarbcu z opóźnieniem. Skarbiec nie oznacza tu specjalnego urządzenia, lecz układ reguł wydawania. Jej codzienny klucz mógłby rozpocząć wypłatę, ale środki najpierw trafiłyby do wyjścia z okresem oczekiwania. Dopiero po jego upływie mogłyby zostać przekazane zamierzonemu odbiorcy. Gdyby wypłatę rozpoczął złodziej, Anna mogłaby w czasie oczekiwania skorzystać z przygotowanej wcześniej ścieżki ratunkowej i przenieść środki pod bezpieczniejsze warunki. Musi jednak zauważyć wypłatę i uzyskać potwierdzenie transakcji ratunkowej w bloku na czas. Blok grupuje transakcje w pakiet dołączany do wspólnej historii. Nie jest to cofnięcie zakończonej płatności ani automatyczny ratunek bez interwencji. Dokładne możliwości zależą od konstrukcji skarbca. [6] [10]

Obietnica aplikacji, że odczeka przed wypłatą, może być wyłącznie obietnicą jej operatora. Regułę w skrypcie Bitcoina sprawdzają natomiast węzły, czyli programy weryfikujące transakcje według wspólnych zasad sieci. Przy odpowiedniej konstrukcji covenant muszą odrzucić transfer naruszający ograniczenie. Przykładem proponowanego narzędzia jest OP_CHECKTEMPLATEVERIFY, czyli CTV, opisane w BIP119. BIP to dokument z propozycją dotyczącą Bitcoina. CTV porównywałoby hash wybranych danych sprawdzanej transakcji z odciskiem zapisanym wcześniej. Hash można tu rozumieć jako krótki, sprawdzalny odcisk danych. Zmiana ustalonego odbiorcy lub kwoty zmieniłaby odcisk, więc transfer niezgodny z szablonem nie przeszedłby kontroli. Sam napis „skarbiec” w aplikacji takiej ochrony nie zapewnia. [2]

CTV wiąże transakcję z przygotowanym wcześniej szablonem, w tym z jej wyjściami. Badane są też inne podejścia. BIP443 proponuje OP_CHECKCONTRACTVERIFY dla wyjść zawierających weryfikowalne zobowiązanie do określonych danych. Zobowiązanie oznacza tu, że nie można później podstawić innej wartości bez wykrycia niezgodności podczas kontroli. Dane mogą opisywać stan kontraktu, na przykład aktualny podział wspólnych środków; następne wyjście mogłoby przenosić zaktualizowany stan, jeśli spełnia ustalone reguły. CTV i ta propozycja nie są więc dwiema nazwami tego samego rozwiązania. W każdym projekcie należy ustalić, co trzeba określić wcześniej, co wolno zmieniać później i jakich dodatkowych narzędzi wymaga cała konstrukcja. [2] [7]

Rekurencyjna konstrukcja może wymagać, by następne wyjście ponownie zawierało określone ograniczenie. Reguła trwa wówczas przez kolejne transakcje, na przykład przy stopniowej zmianie stanu kontraktu. Nie oznacza to nieskończonej pętli podczas sprawdzania jednego skryptu. Russell O’Connor i Marta Piekarska opisali takie konstrukcje w pracy z 2017 roku; możliwość powtarzania zależy od konkretnej propozycji. [3]

Niektóre ograniczenia da się przygotować z użyciem wcześniej podpisanych transakcji, blokad czasowych i zarządzania kluczami. Może to jednak wymagać niezawodnego usunięcia klucza, zachowania wszystkich transakcji lub dalszej współpracy. Multisig oparty na odmowie drugiego podpisującego wobec niepożądanej płatności wprowadza inne założenie dotyczące zaufania. Podobna obsługa nie oznacza identycznego egzekwowania reguł ani odzyskiwania środków. [5] [6]

Poza skarbcami bada się współdzielenie UTXO oraz przygotowywanie płatności rozliczanych w różnym czasie. Celem może być mniejsza potrzeba ciągłej współpracy albo lepsze wykorzystanie miejsca w blokach. Nie oznacza to nieograniczonych transakcji ani gwarancji niskich opłat. Projekt musi też wyjaśniać samodzielne wyjście uczestnika, niedostępność pozostałych i zapłatę opłaty przy przeciążeniu sieci. [2] [7]

Na 17 października 2026 roku BIP119 i BIP443 mają status Draft, czyli pozostają propozycjami w opracowaniu. Starszy BIP345, OP_VAULT, ma status Closed i wskazuje BIP443 jako proponowanego następcę. Zamknięcie tego dokumentu nie oznacza końca badań nad skarbcami. Podobnie nadanie numeru BIP nie oznacza, że sieć przyjęła zmianę. Sieć testowa lub demonstracyjny portfel mogą pokazywać funkcję, podczas gdy reguły głównej sieci Bitcoina, mainnetu, pozostają niezmienione. Gdy usługa oferuje skarbiec oparty na covenants, sprawdź, w jakiej sieci i według jakich reguł naprawdę działa. [6] [8]

Zbyt wąski szablon lub błąd w kwocie, skrypcie czy obsłudze opłat może uniemożliwić zamierzone wydanie. Nowe operacje poszerzają również zakres bezpiecznej weryfikacji wymaganej od implementacji. Dlatego zmiany konsensusu ocenia się według dokładnej specyfikacji i zachowania przy błędach. Sam covenant nie daje obcej osobie prawa do późniejszej zmiany warunków twoich istniejących UTXO. [4] [8]

Przy konkretnym rozwiązaniu zapytaj, kto uruchamia wypłatę lub ratunek, ile czasu jest na reakcję i czy ktoś musi stale obserwować łańcuch. Sprawdź też kopie zapasowe, opłaty, możliwość wyjścia i sieć, w której rozwiązanie rzeczywiście działa. Covenants mogą poszerzyć własną kontrolę nad pieniędzmi, ale samo słowo w opisie produktu jej nie dowodzi. [3] [6]