Protokół płatności offline BRC20 tokenów oparty na ulepszonych kontraktach z blokadą czasową (HTLC) oraz częściowo podpisanych transakcjach bitcoinowych (PSBT)
Streszczenie
Niniejszy dokument przedstawia protokół technologiczny o nazwie Bitcoin-itip, mający na celu realizację transferu wartości BRC20 tokenów w całkowicie offline'owym środowisku. Protokół ten oparty jest na połączeniu ulepszonych kontraktów z blokadą czasową opartych na haszach (HTLC) oraz architekturze częściowo podpisanych transakcji bitcoinowych (PSBT), a także na mechanizmie zobowiązań stanowych opartym na indeksatorze BRC20, co pozwala na stworzenie bezpiecznej, weryfikowalnej warstwy płatności offline, ostatecznie rozliczanej w głównej sieci bitcoin. Rozwiązanie to nie polega na żadnych scentralizowanych serwerach ani łańcuchach bocznych, ściśle przestrzega założeń bezpieczeństwa sieci bitcoin oraz specyfikacji protokołu BRC20, oferując innowacyjne rozwiązania dla obiegu aktywów cyfrowych w scenariuszach bez sieci, ze słabą siecią lub o wysokiej latencji.
1. Wprowadzenie: problemy i cele
Standard tokenów BRC20 wykorzystuje protokół Ordinals Bitcoina do grawerowania danych tokenów na satoshich, ale jego transfer całkowicie polega na nadawaniu transakcji w sieci Bitcoin w celu aktualizacji stanu indeksera. Powoduje to, że funkcjonalność płatności w scenariuszach bez połączenia z internetem (np. w odległych regionach, płatnościach awaryjnych, w środowiskach o wysokich wymaganiach bezpieczeństwa) jest nieskuteczna. Tradycyjne podwójne płatności offline napotykają na wyzwania związane z „atakami podwójnego wydania” i „opóźnieniami synchronizacji stanu”.
Celem protokołu Bitcoin-itip jest:
1. Realizacja całkowitych płatności offline: pozwala na bezpieczne przenoszenie zobowiązań własności tokenów BRC20 między dwoma urządzeniami offline.
2. Zapobieganie atakom podwójnego wydania: zapewnienie unikalności i pewności każdej transakcji offline w momencie jej ostatecznego umieszczenia na łańcuchu przez zastosowanie kryptografii i umów na łańcuchu.
3. Zachowanie zgodności z BRC20: wszystkie operacje offline są ostatecznie przekształcane w transakcje na łańcuchu zgodne z standardem BRC20.
4. Minimalizacja założeń dotyczących zaufania: polega wyłącznie na bezpieczeństwie sieci Bitcoin i tymczasowym stanie urządzeń obu stron.
2. Kluczowe zasady
Rdzeniem protokołu jest podział jednej płatności offline na trzy nierozłączne etapy, których logiczne relacje i przepływ danych przedstawiono na poniższym rysunku:
```mermaid
flowchart TD
subgraph A [Pierwszy etap: Przygotowania online]
direction LR
A1[„Utwórz i zasil <br> portfel z wieloma podpisami”] --> A2[„Wygeneruj i zsynchronizuj <br> dowód początkowego salda (S0)”]
end
subgraph B [Drugi etap: Płatność offline]
direction LR
B1[„Weryfikacja dowodu odbiorcy (Rx) <br> z bieżącym stanem (Sx)”] --> B2[„Wspólne budowanie i wymiana <br> P
SBT z odszyfrowanym cCiphertext (Cx)”]
B2 --> B3[„Aktualizacja lokalnego stanu do Sx+1”]
end
subgraph C [Trzeci etap: Rozliczenie online]
C1[„Nadawanie ostatecznego dowodu stanu (Sfinal) <br> do sieci Bitcoin”] --> C2[„BRC20 indeksator <br> analizuje i aktualizuje saldo”]
end
A -- „Inicjalizacja stanu portfela offline” --> B
B -- „Ostateczne rozliczenie stanu na łańcuchu” --> C
Pierwszy etap (przygotowania online) stanowi podstawę wszystkich operacji offline. Obie strony płatności muszą wcześniej utworzyć adres Bitcoin kontrolowany przez 2-of-2 wieloma podpisami (P2WSH) i przelać do tego adresu tokeny BRC20 przeznaczone do obiegu offline. Adres ten wiąże się z starannie zaprojektowanym ulepszonym skryptem HTLC, który nie tylko zarządza Bitcoinem, ale także rejestruje stan salda tokenów BRC20 (S0) poprzez specyficzne grawerowanie danych (Commitment Inscription). Synchronizacja online na tym etapie zapewnia, że obie strony osiągnęły konsensus co do stanu początkowego.
Drugi etap (płatność offline) stanowi rdzeń protokołu. Gdy oba urządzenia są offline, proces płatności odbywa się poprzez cztery kroki interakcji kryptograficznej:
1. Weryfikacja i inicjacja: płacący weryfikuje dowód odbioru (Rx) dostarczony przez odbiorcę i porównuje go z lokalnie przechowywanym dowodem bieżącego stanu (Sx), aby potwierdzić zdolność do płatności.
2. Budowanie transakcji: obie strony na podstawie Sx współpracują przy wykorzystaniu ram PSBT, aby zbudować „niedokończoną” transakcję Bitcoin. Ta transakcja zawiera dwa wyjścia: jedno wskazujące na pierwotny adres z wieloma podpisami (ale kwota jest mniejsza, co reprezentuje transfer tokenów), a drugie jako reszta. Kluczowe jest to, że wydanie odpowiadające UTXO Sx musi spełniać warunki skryptu HTLC.
3. Wymiana warunków: płacący generuje losowy klucz (Preimage) i oblicza jego hasz (H). Wstawia H do transakcji, a część PSBT z obietnicą nowego stanu (Sx+1) podpisuje częściowo i przekazuje odbiorcy. Równocześnie przesyła zaszyfrowany Preimage (Cx) offline (np. za pomocą NFC lub kodu QR).
4. Aktualizacja stanu: odbiorca odszyfrowuje Cx, uzyskuje Preimage i dokonuje ostatecznego podpisu na PSBT, aby uzyskać ważną transakcję z pełnym podpisem. Obie strony lokalnie aktualizują stan do Sx+1. W tym momencie offline'owa własność tokenów BRC20 została przeniesiona, ale stan na łańcuchu Bitcoin nie zmienił się.
Trzeci etap (rozliczenie online) realizuje ostateczne określenie wartości. Po ponownym połączeniu się urządzenia którejkolwiek ze stron, można nadać ostateczny dowód stanu (Sfinal) odpowiadający całkowicie podpisanej transakcji wygenerowanej przez ostatnią płatność offline do sieci Bitcoin. Górnicy zweryfikują, czy ta transakcja spełnia warunki skryptu HTLC (tj. czy dostarczono poprawny Preimage). Po potwierdzeniu transakcji, indeksator BRC20 zinterpretuje transakcję i grawerowaną nową obietnicę stanu, aktualizując publiczne salda obu stron na łańcuchu, co zamyka cały cykl płatności offline.
3. Kluczowe komponenty technologiczne
3.1 Ulepszony skrypt umowy o czasowe blokady (HTLC)
Ten skrypt jest kluczowy dla bezpieczeństwa funduszy i wykonania logiki. Standardowy skrypt płatności wygląda następująco:
OP_IF
<H> OP_SHA256 OP_EQUALVERIFY
<Payee Public Key>
OP_ELSE
<Locktime> OP_CHECKLOCKTIMEVERIFY OP_DROP
<Payer Public Key>
OP_ENDIF
OP_CHECKSIG
Ulepszeniem Bitcoin-itip jest:
· Powiązanie stanu: <H> nie tylko jest haszem losowego Preimage, ale także pochodzi z „hasza poprzedniego stanu (Sx) + szczegóły nowej transakcji”, co powoduje, że każdy Preimage jest ważny tylko dla jednego konkretnego przesunięcia stanu.
· Podwójne wyjścia: gałąź OP_ELSE pozwala płacącemu na odzyskanie funduszy po okresie blokady (np. 24 godziny), zapobiegając sytuacji, w której odbiorca nigdy nie nadaje transakcji.
· Nośnik danych: wyjście transakcji zawiera specjalne wyjście OP_RETURN, które graweruje haszową obietnicę nowego stanu Sx+1, aby umożliwić identyfikację przez indeksera BRC20.
3.2 Ramy częściowych podpisów transakcji Bitcoin (PSBT)
PSBT pozwala na stopniowe budowanie i podpisywanie transakcji między wieloma stronami, idealnie dopasowane do wiele interakcji w scenariuszach offline. W Bitcoin-itip jedna płatność offline PSBT zawiera:
· Niezatwierdzone wejścia (wskazujące na UTXO zawierające tokeny BRC20).
· Oczekujące wyjścia (nowe przydziały tokenów i reszta).
· Niezbędne informacje o skryptach i haszach blokujących.
· Podpisy dodawane przez obie strony po kolei.
3.3 Kanał transmisji offline
Protokół nie ogranicza warstwy fizycznej, może wykorzystywać:
· Kod QR: wyświetlany jednokierunkowo lub dwukierunkowo, kodujący dane PSBT, zaszyfrowany Preimage lub podpis.
· NFC: do interakcji w bliskim zasięgu, zapewniająca bardziej płynne doświadczenie.
· Bluetooth: odpowiednie dla wielu kolejnych płatności.
4. Szczegółowy opis kroków operacyjnych
Krok 1: Inicjalizacja portfela i zasilenie funduszy (online)
1. Aplikacje portfeli płacącego i odbiorcy generują specjalny zestaw kluczy offline do płatności BRC20.
2. Wspólne stworzenie adresu P2WSH z 2-of-2 wieloma podpisami oraz wygenerowanie obietnicy stanu początkowego S0.
3. Płacący inicjuje standardową transakcję przelewu BRC20, wysyłając określoną ilość tokenów do adresu P2WSH. Po potwierdzeniu tej transakcji na łańcuchu zakładany jest offline'owy zbiornik funduszy.
Krok 2: Proces jednorazowej płatności offline (offline)
1. Negocjacje: urządzenia obu stron ustanawiają sesję w dowolny sposób offline. Odbiorca przedstawia dowód odbioru zawierający swój klucz publiczny i bieżący numer transakcji Rx.
2. Budowanie: portfel płacącego weryfikuje Rx, na podstawie bieżącego stanu Sx i kwoty płatności, tworzy nowy szkic PSBT, oblicza nowy hasz stanu Sx+1.
3. Zablokowanie: płacący generuje losową liczbę R, oblicza H = SHA256(Sx || R || Amount), a następnie ustawia H w warunkach skryptu PSBT. Zaszyfrowane R uzyskuje postać Cx, używając klucza publicznego odbiorcy.
4. Wymiana: płacący dokonuje pierwszego częściowego podpisu na PSBT, a następnie wysyła PSBT i Cx do odbiorcy.
5. Odblokowanie: odbiorca odszyfrowuje Cx, uzyskuje R, weryfikuje H ?= SHA256(Sx || R || Amount). Po weryfikacji używa R do dokonania drugiego podpisu na PSBT. W tym momencie transakcja jest całkowicie podpisana, ale nie została nadana.
6. Potwierdzenie: odbiorca zwraca podpisaną wersję transakcji do płacącego. Obie strony lokalnie bezpiecznie przechowują tę transakcję i aktualizują księgę stanu do Sx+1.
Krok 3: Ostateczne rozliczenie (online)
1. Gdy urządzenie (płacący lub odbiorca) połączy się z siecią, portfel automatycznie lub ręcznie nada ostatnią całkowicie podpisaną transakcję z lokalnych zasobów o najwyższym numerze seryjnym (czyli najnowszą) do sieci Bitcoin.
2. Górnicy sieci przetwarzają tę transakcję. Po dostarczeniu poprawnego R, weryfikacja skryptu przechodzi, a transakcja jest pakowana w bloku.
3. Indeksator BRC20 skanuje ten blok, identyfikuje dane OP_RETURN w transakcji (zawierające Sfinal) i analizuje zmiany w rozdziale tokenów, aktualizując salda obu stron w bazie danych offline.
5. Analiza bezpieczeństwa i ryzyka
· Ochrona przed atakami podwójnego wydania: każda płatność offline jest unikalnie powiązana z jednym UTXO na łańcuchu i ciągłym szeregiem stanów (S0, S1, S2…). Każda próba nadania transakcji z różnymi ostatecznymi stanami (Sfinal) zostanie odrzucona przez sieć Bitcoin po potwierdzeniu pierwszego z nich, ponieważ wydają ten sam UTXO. Sam PSBT wymiany offline jest nieważny, aż do dostarczenia poprawnego Preimage.
· Ryzyko odmowy usługi: odbiorca, po uzyskaniu podpisanej transakcji, odmawia nadawania połączeń, co może prowadzić do zablokowania funduszy płacącego. Dzięki gałęzi OP_ELSE HTLC, płacący może jednostronnie odzyskać fundusze po okresie blokady, co zapewnia podstawowe bezpieczeństwo.
· Rozważania dotyczące prywatności: szczegóły płatności offline są przekazywane tylko między stronami, aż do momentu ostatecznego nadania transakcji, gdy stają się publiczne na łańcuchu, co zapewnia dodatkową warstwę prywatności.
· Bezpieczeństwo urządzenia: bezpieczne przechowywanie kluczy prywatnych jest podstawowym warunkiem, zaleca się korzystanie z elementu bezpieczeństwa (SE) lub zaufanego środowiska wykonawczego (TEE).
6. Ograniczenia i przyszła praca
· Złożoność: protokół obejmuje wiele podpisów, złożone skrypty i interakcje offline, stawiając wysokie wymagania przed deweloperami portfeli i doświadczeniem użytkowników.
· Ograniczenia pojemności: przestrzeń blokowa Bitcoina jest ograniczona, a częste rozliczenia małych płatności offline są kosztowne. W przyszłości można zbadać możliwość łączenia wielu transakcji offline w jedną transakcję rozliczeniową na łańcuchu (sieć kanałów).
· Zależność od indeksatora: ostateczna aktualizacja salda BRC20 zależy od wsparcia indeksatora dla analizy konkretnego formatu Bitcoin-itip, co wymaga konsensusu społeczności.
· Koszty wstępne: każda para kontrahentów musi wstępnie utworzyć i zasilić dedykowany adres z wieloma podpisami, co wiąże się z pewnymi kosztami inicjalizacyjnymi.
7. Wnioski
Protokół Bitcoin-itip po raz pierwszy systematycznie udowodnił wykonalność bezpiecznych płatności offline dla tokenów BRC20. Dzięki sprytnemu połączeniu programowalności skryptów Bitcoina, elastyczności interakcji PSBT oraz ciągłości obietnicy stanu, protokół zbudował solidną warstwę przesyłania wartości offline, nie wprowadzając dodatkowych założeń dotyczących zaufania. Rozszerza granice zastosowania Bitcoina i tokenów BRC20, oferując kluczowe techniczne ścieżki dla budowy bardziej elastycznej i inkluzywnej infrastruktury finansowej. Wdrożenie tego protokołu zależy od wspólnego wsparcia dostawców portfeli, usług indeksacyjnych oraz społeczności, a jego udane wdrożenie stanie się ważnym kamieniem milowym innowacji na warstwie aplikacji Bitcoina.
Zastrzeżenie: Protokół opisany w tym białym dokumencie jest propozycją techniczną, która nie przeszła jeszcze szerokiej audytów bezpieczeństwa ani testów w praktyce. Deweloperzy i użytkownicy powinni być w pełni świadomi ryzyk podczas eksperymentalnego wdrażania. Bitcoin i ekosystem BRC20 wciąż szybko się rozwijają, a szczegóły realizacji mogą wymagać dostosowania w miarę aktualizacji protokołu.
#比特赏银itip #比特币生态 #Bitcoin谷歌搜索量暴升
Kontakt do głównej społeczności protokołu BRC20 itip: itip2024@outlook.com
@币安广场 @Binance BiBi @CZ @Sun Research 孙宇晨研究 @Jiayi Li @迪大户 @唐华斑竹 @周周1688 @金先生聊MEME @欧吉巴克 @Yi He @Luna春婷 @Walrus 🦭/acc
