Topic: Co nowego w sieci Bitcoin (Read 144 times)

wczoraj pojawiły się bardzo interesujące informacje na temat Taproot Assets, protokołu opracowanego przez lightning labs w celu mapowania dowolnych aktywów bezpośrednio na Bitcoin i - przynajmniej w przyszłości - wysyłania ich szybko i tanio za pośrednictwem sieci lightning.
wraz z wydaniem wersji alfa 0.3 deweloperzy powinni mieć teraz wszystkie narzędzia potrzebne do wydawania i zarządzania aktywami, takimi jak stablecoiny, on-chain.

kto chciałby dowiedzieć się więcej o TA 0.3, może przeczytać angl. artykuł, do którego link znajduje się poniżej
https://lightning.engineering/posts/2023-10-18-taproot-assets-v0.3/

https://github.com/lightninglabs/taproot-assets/releases/tag/v0.3.0

Czemu nie, aczkolwiek kojarzę parę starszych wpisów tego typu, które się przewinęły, gdy Taproot był wprowadzany i gdy jeszcze trwała sygnalizacja górników i mining pooli.

Zdajesz sobie sprawę, jakie to ma konsekwencje? Otóż na przykład takie, że możesz napisać coś takiego: "OP_SHA256 OP_CHECKSIG". Jeśli punkt bazowy został wygenerowany w specjalny sposób, to pomyśl, że taki Script mógłby realnie się udać. Oczywiście, pewnie nie na secp256k1, bo tamtejsza połówka punktu bazowego ma za dużo zer i raczej nikt tego nie wykopywał do takiego stopnia, ale w ogólnym przypadku, w kontekście na przykład Pedersen Commitments, to by mogło być ciekawe.

Poza tym, zobacz na to z tej strony: jak sobie rozpiszesz to na takich samych literach, jak przy zwykłych sygnaturach, to zapewne zauważysz, że przy odpowiednich wartościach, dałoby się wyłuskać z-value. A wtedy... No właśnie, wtedy na stos mógłbyś wsunąć prosto z mostu "taggedHash(R||P||m)". Ciekawe, prawda? Oczywiście, odzyskiwanie klucza w klasycznym stylu nie działa, no ale skoro sygnatury można składać, to można je równie dobrze rozbijać i z jednej sygnatury zrobić kilka. A to już otwiera ciekawe możliwości obliczeniowe! Zwłaszcza w kontekście OP_CHECKSIGADD, gdzie można byłoby udowodnić, że "s = s1 + s2", dobierając sobie wszystko poza s-value. A potem już z górki...

Piękne zdanie. W przypadku Taproota jest tylko lepiej. Klucze publiczne są tam zawsze 256-bitowe i mają niejawny prefix "02". Zaś opkod OP_CHECKSIGADD powoduje, że mamy wbudowane w Bitcoina dodawanie 256-bitowych liczb! To jest niesamowite: wystarczy umieścić parę sygantur Schnorra na stosie i zrobić OP_CHECKSIGADD i wtedy te wartości zostaną dodane do siebie! To jest coś na miarę OP_ADD, tylko że na 256-bitowych zmiennych. A to otwiera niesamowite możliwości.

Edit: W sumie to chyba nie wyraziłem się wystarczająco jasno i niektórzy mogą nie zrozumieć, co mam na myśli. Otóż OP_CHECKSIGADD może być zastąpiony przez "OP_ROT OP_SWAP OP_CHECKSIG OP_ADD". Ktoś mógłby zapytać: no i gdzie tu masz dodawanie 256-bitowych liczb, co? Odpowiadam: w sygnaturach Schnorra. Jeśli mamy klasyczną sygnaturę, to oczywiście " OP_SWAP OP_CHECKSIG" pozwala na odzyskanie klucza publicznego z sygnatury. W przypadku sygnatur Schnorra działa to nieco inaczej, bo klucz, który moglibyśmy w ten sposób odzyskać, stanowi składową z-value, więc klasyczne tricki nie przejdą.

Jednakże, sama sygnatura Schnorra pozwala na wiele. Jeśli mamy sygnaturę (r1,s1) oraz (r2,s2) i chcemy je złożyć, to powstanie z tego ((R1+R2).x,s1+s2). Patrząc na s-value widzimy piękne dodawanie na 256 bitach, w dodatku dodawanie modulo, więc nie musimy się martwić, że kiedykolwiek wyjdziemy poza zakres (w przypadku 32-bitowych zmiennych możemy dostać 33-bitowy wynik i trzeba na to uważać).

Myślę, że na horyzoncie widać co najmniej dwa ciekawe tematy do opisania na bitcointalku: jeden to sygnatury Schnorra, a drugi to "tagged hash". Zapytam vjudeu, czy weźmie ten drugi temat na siebie, bo ostatnio siedzi głębiej w funkcjach skrótu. Ja z kolei siedzę w krzywych eliptycznych, więc może dałoby się nawet machnąć jakiś prosty przykład. Pogadamy, zobaczymy, fajny temat na niedzielny wieczór.

Krótkoterminowo tak. Długoterminowo? To zależy. Bo owszem, jest wiele powodów, dla których giełdy lubią mieć własne tokeny. Ale prawda jest też taka, że jeśli te giełdy dostaną w swoje ręce możliwość spięcia swoich własnych tokenów z Bitcoinem i to będzie tak silne połączenie, jak pomiędzy Lightning Network, a główną warstwą, to mogą się na to zgodzić.

Chodzi o to, że jeśli samo połączenie będzie wymagało na przykład jedynie podpisania swoich własnych Bitcoinów, to giełda może stwierdzić: w sumie czemu nie? Bo tak naprawdę, to jeśli masz własny token, to jego kurs może być bardzo różny. Ale jeśli zamiast tego pokażesz komuś: patrzcie, tutaj jest adres, na którym leży 1000 BTC i jest podpisany przez naszą giełdę, to już taka deklaracja wygląda znacznie poważniej. Zwłaszcza, że niektóre połączenia nie wymagają przesuwania monet, sam podpis jest w stanie udowodnić wiele.

Cała sieć Lightning Network jest "tylko dwustronna", bo mamy adresy 2-of-2 multisig. Dołożenie routingu rozwiązuje ten problem (i tworzy nowe, analogiczne do tych, które istnieją w LN).

Można, jeśli mamy do czynienia z federacją, czyli sidechainem, w którym istnieją walidatorzy. Ogólnie rzecz biorąc, wszelkie systemy, w których są walidatorzy i które opierają się na Proof of Stake, mogłyby z łatwością wpiąć się do Bitcoina. Dobrym pytaniem jest: dlaczego tego nie robią? Bo nie ma technicznych przeszkód, żeby w systemie, gdzie jest na przykład 20 walidatorów, zrobić na przykład 11-of-20 multisig na Taproocie.

Dokładnie w ten sam sposób każda zmiana stanu kanału w Lightning Network wymaga nowej transakcji off-chain. Piękno tego systemu polega na tym, że nie trzeba tych wszystkich transakcji wypychać na główny łańcuch. Co oznacza, że jeśli dwa węzły mają bezpośredni kanał, to mogą zrobić wszystko. Na przykład: jedna osoba może wykopywać DOGE, a druga płacić jej w millisatoshi za każdy share. Da się? Da się.

Pierwsze próby zbudowania takiego systemu istniały już od dawna. W prastarych czasach dyskutowało się na temat OP_EVAL, obecnie widziałem dyskusję na temat OP_FOLD. Najciekawszy wpis, który sobie przypominam, pojawił się w lutym 2022: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/020021.html

Wielu szaleńców robiło to od dawna. Jednym z przykładów szaleństwa w czystej postaci były próby społeczności BSV, która naiwnie ładowała ZK-proof w megabajtowych transakcjach, zamiast zrozumieć, że skoro ich Script ma aktywny OP_CAT, to mogą działać na prostych, 256-bitowych liczbach i klepnąć to przez zwyczajne OP_CHECKSIG, jedyne, czego potrzebują, to sprawdzić, czy R-value w sygnaturze jest takie, jakie ma być. Ale nie, oni wolą wypchnąć na łańcuch jedną transakcję o rozmiarze 10 MB, zamiast jednej transakcji z OP_CAT, która jeśli ważyłaby choćby 10 kB, to musiałaby być gigantyczna.

Podział obliczeń na wiele transakcji jest możliwy od dawna. Najprostszym dowodem tego jest federacja, gdzie obaj użytkownicy mogą podać swoje klucze publiczne i zablokować monety na adresie 2-of-2 multisig, oprócz tego dorzucając garść opkodów. Wtedy albo obie strony wykonają kontrakt, albo monety zostaną zablokowane. Żeby uniknąć blokady, można wykonać podejście a'la LN, czyli przygotować transakcje zamykające, zanim kontrakt zacznie być wykonywany. Ewentualnie można założyć timelocka, żeby ludziom się nie chciało czekać i wspólnie policzyli to, co trzeba, zanim timelock wygaśnie.

Ja tam wolę od razu skupić się na wydajności. Gdybym myślał inaczej, to mempool zajmowałby parę terabajtów. I tak dziwi mnie, że ludzie zrobili bramkę NAND aż tak późno, sam pamiętam, jak kiedyś robiłem takie rzeczy w regteście używając takiego zestawu czterech opkodów: OP_TRUE, OP_FALSE, OP_NOT, OP_EQUAL. Całość była w systemie czwórkowym, dwa bity na opkod i jazda. Wtedy jeszcze chciało mi się bawić w takie ezoteryczne języki, jak Brainfork (do dzisiaj mam pliki tekstowe z rozszerzeniem *.bf oraz niedokończony "projekt BF", w którym chciałem pisać własny system operacyjny, oparty na "czterobitowej architekturze BF").

Czekam, aż ludzie przestaną używać 32-bitowych kawałków i będą od razu ogarniać 256-bitowe fragmenty za pomocą OP_CHECKSIG. Przykładowo, jeśli chcemy coś liczyć na 256-bitowych liczbach, to możemy włożyć sygnaturę i zrobić " OP_SWAP OP_CHECKSIG". Wtedy 257-bitowy klucz publiczny jest jedynym poprawnym rozwiązaniem.

znany deweloper @super_testnet opracował swoją pierwszą implementację BitVM, która umożliwia dodawanie 32-bitowych liczb. całość może być teraz wypróbowana przez wszystkich w sieci testnet.


https://supertestnet.github.io/tapleaf-circuits/

a inny deweloper @mononautical 'uruchomił' wysokopoziomową instrukcję BitVM, którą nazywa 'jet leaf'.
zamiast setek pojedynczych binarnych bramek logicznych w oddzielnych tapleaves, transakcja ta (w sieci testowej) wykonuje skrypt taproot leaf, który implementuje komponent obwodu BitVM w celu dodania dwóch 31-bitowych liczb całkowitych bez znaku. sprawia to, że komponent ten łączy całą operację w jeden duży 'jet leaf'


https://mempool.space/signet/tx/be9fc1759fea33534fabac244a8fb002d18d9261316f3433deab6b5d720a4f30

Dzięki wielkie za podzielenie się. Widzę, że sprawa rozwija się dynamicznie. Pomyslałem, że warto jest mieć to tutaj po polsku:

"BitVM: Ograniczenia i Kierunek Rozwoju

To jest aktualizacja 48-godzinna (i ostatnia na razie) mojej serii BitVM. Oto aktualne ograniczenia BitVM i na co zwrócić uwagę w miarę postępu:

Ograniczenie 1: System tylko dwustronny

Oznacza to, że dwie osoby mogą wykonywać działania przypominające umowy inteligentne, ale jeszcze nie można tego uogólnić do kontekstu sidechain lub rollup. To dość poważne ograniczenie, które ogranicza to, co można zrobić z BitVM.

Postęp

W Telegramie BitVM jest wiele pomysłów na to, jak może działać system wielostronny, ale żaden z nich jeszcze nie działa. Oczywiście, minęły zaledwie 48 godzin. Z czasem sądzę, że prawdopodobne jest znalezienie dobrego sposobu na stworzenie wielostronnej umowy inteligentnej BitVM, co otworzy cały zestaw rozwiązań.

Ograniczenie 2: Jednorazowe umowy inteligentne

To związane z Ograniczeniem 1. W obecnej formie, aby użyć BitVM, tworzysz transakcję Bitcoinową między dwiema osobami: weryfikatorem i dowodzącym. Oznacza to, że każda interakcja umowy inteligentnej między dwiema osobami musi być nową transakcją Bitcoinową.

Dlatego nazywam to „jednorazowymi umowami inteligentnymi”.

Nie masz trwałych adresów umów inteligentnych, tak jak na Ethereum, które każdy może wywołać w dowolnym momencie. Zamiast tego masz mnóstwo otwartego kodu źródłowego, którego możesz użyć do utworzenia umowy inteligentnej (inaczej transakcji Bitcoinowej) z inną osobą, kiedy chcesz.

Postęp

To istotne ograniczenie, o którym mało się dyskutuje. BitVM w swojej obecnej formie bardziej przypomina protokół peer-to-peer niż pełnoprawną drugą warstwę Bitcoin z umowami inteligentnymi podobnymi do Ethereum.

Postęp może nadejść, gdy uda się uruchomić w BitVM weryfikator ZK. Jeśli to możliwe, można mieć prawdziwe drugie warstwy na Bitcoinie, gdzie dowody z drugiej warstwy są weryfikowane w weryfikatorze ZK w BitVM.

W tym przypadku BitVM nie jest warstwą na Bitcoinie, ale ułatwia mniejsze założenia co do zaufania w łączeniu z warstwą drugą, a także ułatwia mniejsze założenia co do transakcji na warstwie drugiej. BitVM może być kluczem do uzyskania warstw drugich na Bitcoinie bez konieczności aktualizacji.

Ograniczenie 3: Ręcznie wykonane układy (zobacz wideo)

Aby zbudować coś w BitVM w tej chwili, musisz to zrobić na najniższym poziomie programowania. W zasadzie zajmujesz się projektowaniem układów. Oznacza to, że trzeba zbudować milion różnych komponentów i połączyć je, aby uzyskać język programowania wyższego poziomu (lub nawet tylko weryfikator ZK) w BitVM.

Postęp

Dziś Super Testnet potwierdził, że mamy teraz 2 (!) funkcje w BitVM. Jedna zlicza zera, a druga obsługuje większe niż mniejsze. To lepsze niż 1 funkcja i znacznie lepsze niż 0 funkcji!

Rzeczywisty postęp nastąpi, gdy ktoś z zespołu badawczego stworzy istniejący język niskiego poziomu, który można bezpośrednio podłączyć do BitVM. Gdy będziemy mogli wykorzystać istniejący kod i narzędzia do budowy bloków BitVM, rzeczy będą się poruszać znacznie szybciej.

Ograniczenie 4: Złożoność i Koszt

W obecnie zrozumianej formie, i w najgorszym przypadku, potrzebujesz 250 transakcji Bitcoinowych, aby przejść przez całą serię wyzwań/ dowodów i rozstrzygnąć sporną transakcję.

Tak, ponieważ to jest optymistyczne ustawienie dowodowe, jeśli napotkasz scenariusz, w którym nie zgadzasz się z dowodzącym co do kodu, który został wykonany, w zależności od złożoności umowy inteligentnej, może być potrzebnych 250 transakcji w najgorszym przypadku, aby rozstrzygnąć spór.

Poza rozstrzyganiem sporów, ponieważ tutaj ręcznie projektujemy układy, prawdopodobne jest, że staną się one bardzo duże, wymagając przesyłania dużej ilości danych poza łańcuchem między weryfikatorem a dowodzącym.

Postęp

Im bardziej wydajny może być każdy liść w drzewie taproot, tym lepiej. Im więcej bramek możemy umieścić w jednym liściu, tym lepiej. A im lepsze kody operacyjne, tym mniej bramek potrzebujemy.

To, że w ogóle można podzielić obliczenia między transakcjami (a może nawet adresami) jest szalone. Najpierw pokaż, że to jest możliwe. Potem spraw, by to było bardziej wydajne. Teraz jesteśmy w fazie „zrobienia tego bardziej wydajnym”.

Podsumowanie

BitVM to jedno z najbardziej ekscytujących osiągnięć technicznych w obszarze Bitcoin w ciągu ostatniego roku. BitVM prawdopodobnie pozostanie z nami"
[tłumaczenie z pomocą chatGPT]

udało mi się znaleźć jeszcze dwa interesujące tweety od użytkownika @BobBodily, który dokładnie przyjrzał się całej sprawie i szczegółowo opisał ją w swoich tweetach (niestety tylko w języku angielskim)

https://twitter.com/BobBodily/status/1711942512603181145

https://twitter.com/BobBodily/status/1712305639366811997

I dla takich informacji zakładałem ten wątek. super news, dzięki za podzielenie się. Pytanie tylko, czy faktycznie jest to kuloodporne rozwiązanie i czy sieć to przyjmie, ale z tego co rozumiem, to nie musi, bo zmiana ta nie wymaga forka:

"this requires no changes to the network's consensus rules".

Czy alty staną się niepotrzebne? Tylko te od smart kontraktów. Na przykład tokeny giełdowe, albo tokeny wyrażające udział w jakimś przedsięwzięciu swoją wartość utrzymają.

tak, prawdopodobnie masz rację. link służyłby wtedy tylko jako pomoc, jeśli szukasz wyjaśnienia konkretnego bipa, który już znasz.

---

wygląda na to, że dziś opublikowano coś bardzo ważnego dla dalszego rozwoju Bitcoina. pewny Robin Linus opublikował dziś swój whitepaper zatytułowany 'BitVM: Compute Anything on Bitcoin', który umożliwia wszystkie narzędzia altcoinowe na Bitcoinie! od dziś można również powiedzieć, że altcoiny są w 100% niepotrzebne...


https://bitvm.org/bitvm.pdf

Właśnie brakowało mi tutaj rozmów czysto o bitcoinie i sieci. Sam nie mam podstaw technicznych, by poprowadzić ten wątek, ale wiem, że jest tu co najmniej dwóch bardzo dobrze obeznani użytkowników. Osobiście jestem ciekaw tego, jaki jeszcze potencjał ma sieć i gdzie możemy być za kilka lat.


Dzięki za link, ale bez dokładnej znajomości kodu i sieci raczej ciężko coś wyciągnąc dla siebie nie?

bardzo dobry pomysł, aby otworzyć tego rodzaju wątek tutaj. nie mogę powiedzieć od ręki, nad czym obecnie pracują deweloperzy, aby zaimplementować to w protokole bitcoin, ale chciałem podzielić się interesującym linkiem do githuba w tym wątku, gdzie można zobaczyć wszystkie bipy, które zostały do tej pory zaimplementowane:

https://github.com/bitcoin/bips/tree/master

Proponuję wrzucać tu informacje o nowościach w sieci bitcoin. Nad czym obecnie najpilniej pracują deweloperzy. Co jest blisko dodania do protokołu w postaci forka, a może coś już niedługo będzie działać, co nawet nie wymaga forka.