🚨RGB 0.12 RC1 jest już dostępny W ciągu 2 lat śledzenia protokołu RGB był to prawdopodobnie najbardziej ekscytujący moment Zaledwie 14 godzin temu, na githubie RGB-WG, Maxim w końcu ogłosił wersję RC1, która będzie najbardziej stabilną wersją RGB, a także zasugerował, aby wszyscy twórcy RGB przeszli na najnowszą wersję tak szybko, jak to możliwe, a nadchodzi kolejny rozdział ekosystemu BTC Zanurzmy się w 👇 🧵 ———————— 🔶 Uproszczenie protokołu Tym razem zmiana dotyczy głównie warstwy konsensusu, a nowa architektura wprowadza po raz pierwszy zk-AluVM, kompaktową, wysokowydajną maszynę wirtualną zk z kompletnym Turingiem, przeznaczoną do weryfikacji klienta Jeśli nie wiesz zbyt wiele o RGB, możesz pomyśleć, że jest to najbardziej natywny system inteligentnych kontraktów BTC, oczywiście nie tylko BTC, ale wszystkie publiczne łańcuchy w trybie UTXO mogą korzystać z protokołu RGB do realizacji inteligentnych kontraktów poza łańcuchem Wracając do aktualizacji, w architekturze są też pewne optymalizacje refaktoryzacji stanu kontraktu + weryfikacji konsensusu, które nie będą tutaj szczegółowo pokazane Według Githuba, tym razem v0.12 - 4-krotne zmniejszenie ilości kodu konsensusu > i 2-krotne zmniejszenie ilości biblioteki standardowej; - > zmniejszenie liczby typów danych o 30% w parametrach ogólnych w API 🔶 Państwo jest zjednoczone Być może dla zwykłych ludzi najbardziej zauważalną zmianą jest unifikacja państwa kontraktu, które kiedyś miało trzy rodzaje stanów kontraktu (FT/NFT/inne), a teraz wszystkie są zunifikowane i może być potrzebny nowy szablon tokena (poprzedni szablon v0.11 powinien być nieważny) 🔶 Ulepszenia płatności Jest tu kilka głównych ulepszeń, a ja wybiorę najważniejsze z nich 1. Kontrakty obejmujące wiele aktywów Obecnie możliwe jest dołączenie wielu interoperacyjnych tokenów do kontraktu, które mogą być wywoływane niezależnie lub łącznie Na przykład, mogę zdefiniować 100 monet + 500 NFT + kilka innych załączników w kontrakcie (najbardziej podstawowe) 2. Skrypty płatności Na przykład wielopodpisowe CoinJoin/PayJoin, przetwarzanie wsadowe transakcji, obsługa kanału Lightning itp., obsługa jeden-do-wielu lub wiele-do-jednego 🔶 Optymalizacja wydajności Stara wersja danych przesyłowych musi być w pełni załadowana do pamięci, wersja 0.12 została zmieniona na uwierzytelnianie strumieniowe, pamięć zajmuje tylko kilkaset bajtów i nadaje się do portfeli mobilnych/sprzętowych Nie będę się więcej rozpisywał, a będzie to coś innego niż u każdego