Protokoły tokenów na BSV: Sensible Contract

W następnym artykule z naszej serii wywiadów z założycielami protokołu tokenów na BSV, przeprowadzamy wywiad z Gu Lu, współzałożycielem SatoPlay i współautorem białej księgi Sensible Contract, proponowanego rozwiązania rozwiązania „śledzenia wstecz i współpracy kontraktów” dla

Co może zapewnić protokół Sensible Contract, czego nie może zapewnić żaden inny protokół tokena? Gu Lu: Proszę pozwolić mi wyjaśnić, że Sensible Contract nie jest rozwiązaniem tokenowym, które konkuruje z innymi (jeden przypadek tego robi). Jest to model kontraktowy, który zapewnia śledzenie wsteczne w łańcuchu i współpracę dla istniejących skryptów bitcoin. Włączając te możliwości, możemy bez problemu wdrożyć poręczny system tokenów/NFT, taki jak BCP01 i BCP02. W BCP03 możesz również dowiedzieć się, w jaki sposób Sensible Contract upraszcza tworzenie zwykłej wymiany w łańcuchu, formułując w wdzięczny sposób globalny stan współpracy. Sensible Contract nie jest tutaj, aby konkurować i próbować przewyższyć dany system tokenów od pierwszego dnia. Wręcz przeciwnie, może być wykorzystany do uproszczenia i ułatwienia pisania i utrzymania danego systemu tokenów, jeśli ten system jest napisany w sCrypt. Pomaga ci w dwóch aspektach, w szczególności.

Po pierwsze, ukrywając szczegóły kłopotliwej legalności wstecznego śledzenia i walidacji, pomaga skoncentrować się na logice biznesowej z tokenami lub innymi zdefiniowanymi zasobami bez martwienia się sfałszowanymi danymi wejściowymi od nieznanych stron.

Po drugie, zapewniając mechanizm współpracy, możesz uzyskać dostęp do większej liczby pól danych istotnych dla biznesu, które nie są dostępne w bieżącym kontekście zwykłej transakcji.

Funkcja współpracy otwiera nowe i bardzo rozległe terytorium do zbadania. Komunikacja kontraktowa może być bardzo przydatna do wdrożenia zautomatyzowanej funkcji wielofazowej dla nietrywialnej logiki biznesowej. Mechanizm współpracy składa się z trzech poziomów:

Wiele danych wejściowych identyfikujących się nawzajem w ramach tej samej transakcji (opisanej w białej księdze)

Wiele modułów w tym samym skrypcie blokującym; (działa to w kontekście włączonej „funkcji dynamicznego składania/rozwijania funkcji”, przy użyciu przeskakiwania stanu w celu dynamicznego zminimalizowania rozmiaru skryptu środowiska wykonawczego poprzez złożenie tych funkcji, które nie są używane i rozwinięcie ich w razie potrzeby)

Propagując określone pola segmentu danych w treści skryptu blokującego, kontrakt może współpracować asynchronicznie z innym kontraktem nie w tym samym kontekście.

Jak widać, zapewnia to wiele elastyczności z różnych wymiarów, co przynosi korzyści znacznie szerszemu spektrum zastosowań i wykracza daleko poza białą księgę, która w tym czasie zawiera tylko pierwszy poziom. Jesteśmy w bardzo aktywnym cyklu rozwoju na tym niczyim terytorium, aby ulepszyć zarówno sam model umowy, jak i aplikacje, które inkubuje.

Sensible Whitepaper wykonał świetną robotę, podkreślając, w jaki sposób wszystkie protokoły tokenów mierzą się z problemem śledzenia wstecznego (aka Back to Genesis) – dlaczego tak ważne są protokoły tokenów, aby to złagodzić?

Gu Lu:

Zanim omówię problem ze śledzeniem, powiedziałbym, że wspomniane rozwiązania warstwy 2 (przy użyciu rozwiązania opartego na op-returnach, takiego jak warstwa Omni używana przez USDT i przy użyciu usługi zewnętrznej do walidacji transakcji) nie powinny w ogóle mieć tego problemu przede wszystkim dlatego, że zawsze możesz zapewnić legalność, ulepszając zewnętrzną usługę poza łańcuchem. Ale używając tego, prawdopodobnie w ogóle nie potrzebujesz programowalności bitcoinów i nie są to już „programowalne pieniądze”, dosłownie mówi „stwórzmy system znaczników dla gotówki i egzekwujmy zasady, interpretując znaczniki razem”. Wykorzystując skrypt Bitcoin, aby zapewnić legalność Twoich aktywów w łańcuchu, śledzenie wstecz jest z natury nieuniknionym problemem, jeśli chcesz rozwiązać problem w granicach wirtualnej maszyny bitcoin. Ponieważ wartość satoshi pochodzi z oprogramowania węzła. Sam system zapewnia, że ​​satoshi jest czymś, czego nie da się stworzyć, powielić, usunąć itp. Ale wszystkie zasoby utworzone przez skrypt nie dzielą tego „pierwszej klasy przywileju”, istnieją tysiące sposobów na złamanie do systemu tokenów, tworząc niełatwe do rozpoznania fałszywe dane wejściowe, jeśli nie możesz prześledzić wstecz do jego genezy w bardzo szybki i skuteczny sposób. Szczerze mówiąc, wstecznie śledzące łaty załatają największą dziurę, ale nie wszystkie. Programista nadal musi uważać, aby nie napisać złego kodu, aby przypadkowo nie zrujnować zasobu w nieoczekiwany sposób w swoim kodzie. To (aktywa mogą zostać zerwane, jeśli kontrakt zawiera przeoczone błędy) to ten sam przypadek w przypadku solidności Ethereum. Jednak w nowoczesnych środowiskach, takich jak Cadence in Flow, jest to rozwiązany problem dzięki zastosowaniu paradygmatu „zorientowanego na zasoby”. Zasoby tworzone w tych środowiskach są dobrze zdefiniowanymi „obywatelami pierwszej klasy”, takimi jak wspomniana powyżej wartość satoshi, i nie można ich przypadkowo powielić lub usunąć. Szczegóły śledzenia wstecz można znaleźć w tej prezentacji: Tutaj znajdziesz plik PDF i pełną treść w języku chińskim (przepraszam, ale może być przetłumaczony automatycznie).

Czy zwolennicy Sensible Contract nadal proszą o zmianę protokołu w celu rozwiązania problemu śledzenia wstecznego?

Gu Lu: Nie. Po poznaniu nastawienia nChain nie będziemy już wzywać do aktualizacji węzła, gdy tylko się o tym dowiemy, ponieważ chcemy bardziej efektywnie budować prototypy i produkty, a nie wielokrotnie argumentować i opowiadać się za „akceptacją”. Najważniejsze jest to, czy pomaga w rozwoju aplikacji, z tak zwaną „zmianą protokołu” lub bez niej (co technicznie nie jest). Sensible Contract działa dobrze ze 100% obiecanymi funkcjami bez aktualizacji PreImage. Następna wersja białej księgi zostałaby mocno zrewidowana z dodanymi znacznie bardziej wartościowymi fragmentami, a „Aktualizacja wstępnego obrazu” zostałaby przeniesiona do obszaru przypisów w sekcji implementacji, aby uniknąć niepotrzebnych kłótni.

Czy uważasz, że problem śledzenia wstecznego można rozwiązać bez zmiany protokołu?

Gu Lu: To może być w przyszłości. Ludzie nadal aktywnie nad tym pracują i jest za wcześnie, aby powiedzieć, że to ślepy zaułek.

Dlaczego wymagane jest zwiększenie rozmiaru skryptu transakcji Bitcoin, aby umożliwić uruchamianie aplikacji takich jak TokenSwap?

Gu Lu: Chcemy większego limitu rozmiaru dla pojedynczego skryptu blokującego, abyśmy nie musieli selektywnie usuwać wielu kodów biznesowych i funkcji, aby przebić go przez bramkę 10 KB. Tak jak po prostu chcemy, aby większe bloki niż 1 MB zawierały więcej transakcji. To takie proste. Współpracowaliśmy z TAAL i w ostatnich miesiącach mieliśmy 500 KB. Działa to dobrze, więc uważamy, że prawdopodobnie dobrym kandydatem na propozycję jest poproszenie opiekuna oprogramowania węzła o podniesienie limitu do 500 KB, aby inni górnicy mogli również kopać te transakcje w swoich blokach, a my moglibyśmy uzyskać ogólnie skrócony średni czas potwierdzenia. Jednak problem z rozmiarem można zoptymalizować, zarówno po stronie toolchaina, jak i po stronie aplikacji. Żyjemy w erze, w której zarówno łańcuchy narzędzi, jak i kod umowy aplikacji nie są jeszcze dojrzałe. We wcześniejszych dniach Visual Studio programiści narzekali na rozmiar pliku wykonywalnego generowanego przez Visual C++ na platformie Windows przy użyciu wcześniejszych wersji Visual Studio: „Dlaczego jednowierszowy program „hello-world” generuje tak ogromny plik wykonywalny (2 5 MB pliku .exe)?” Microsoft wysłuchał ich i zoptymalizował swoje kompilatory w późniejszych iteracjach. Właśnie teraz stworzyłem nowy projekt w Visual Studio 2017 kilka minut temu i przeprowadziłem eksperyment. Wynik rozmiaru pliku .exe to 47 KB w debugowaniu i 10 KB w wydaniu (oba używają domyślnych opcji optymalizacji) Jest 10-100 razy mniejszy. Jeśli spojrzysz na wygenerowany skrypt bitcoin danych wyjściowych sCrypt, zdasz sobie sprawę, że to samo mogłoby/powinno się wydarzyć. Xiaohui potwierdził również, że ma dużo miejsca na optymalizację w kierunku znacznie bardziej kompaktowej kompilacji, ale generalnie ma niski priorytet, ponieważ oskryptowana transakcja jest nadal rzadkością w dzisiejszych czasach. Dlatego będziemy współpracować, aby mieć ogólnie mniejszy skrypt blokujący, aby transakcje skryptowe były bardziej zwarte w przyszłych iteracjach.

Co najbardziej Cię cieszy, gdy zobaczysz, jak powstanie na bazie Sensible Contract?

Gu Lu: SatoPlay NFTex (wymiana NFT), SensibleSwap (wcześniej znany jako TokenSwap), SensibleScan (przeglądarka zasobów jak Etherscan). Nie widzimy ich budowania, wkładamy się w ich budowanie z ich programistami. To są trzy projekty bliskie uruchomienia i wiemy, że jest więcej projektów w fazie rozwoju. Aktywnie testujemy pod kątem współdziałania, czy aktywa i tokeny mogą być płynnie przenoszone między tymi produktami. To będzie najbardziej ekscytująca funkcja w najbliższej przyszłości.

Sensible jest stosunkowo mniej znany w przestrzeni BSV ze względu na jego niedawną premierę i pochodzenie na rynku chińskim. Jak planujesz uzyskać bardziej ogólne przyjęcie protokołu?

Gu Lu: Generalnie nie robimy zbyt wiele, aby zwrócić na siebie uwagę, ponieważ mamy ograniczony czas i zasoby. Musimy umieścić je w najbardziej krytycznych częściach naszych badań i inżynierii, aby posuwać sprawy do przodu, próbować szybko ponosić porażkę, eksperymentować z wieloma możliwościami, aby ogólnie osiągnąć większy postęp w danym przedziale czasowym. Osoby, które dobrze znają się na skrypcie Bitcoin, jakoś nas znajdą i generalnie są chętne do prowadzenia z nami świetnych rozmów. To byłoby o wiele bardziej produktywne dla nas wszystkich.

Protokoły tokenów Czy możesz wyrazić swoje przemyślenia na temat etykiet „Warstwa” dla Tokenów? (np. STAS jako L0, sCrypt jako L1 i Tokenized jako L2)?

Gu Lu: Słyszeliśmy różne podejścia do „warstwowania”. Nie planuję ich szczegółowego porównywania, tak jak robiłem to za pomocą diagramu od L2 do L1 we wcześniejszych rozmowach w lutym. Ponieważ bez względu na to, jak zaimplementowany jest system tokenów, wszystko jest w porządku. Każdy z nich zasługuje na szansę wykorzystania przez innych. Liczy się to, czy system jest stale szeroko stosowany. Nie chodzi o to, czy Twój projekt jest czysty i elegancki, ale o to, czy w przyszłości zamierzasz włożyć w niego znacznie więcej brudnej roboty, aby mieć coraz więcej projektów, w których wierzysz, że Twoje rozwiązanie jest mocnym fundamentem, który jest niezawodny i stabilny być dobrze utrzymane i powtarzane w przewidywalnej przyszłości.

Jakie są twoje przemyślenia na temat używania satoshi jako tokenów?

Gu Lu: Robiąc to, satoshi są „krojone/zakładane/spalane” na żetony, które można odzyskać w razie potrzeby (lub nie). Jest opłacalne, ale bardzo trudne (jeśli nie niemożliwe) korzystanie z bogatych funkcji finansowania kontraktowego, które można ogólnie znaleźć w innych sieciach. Więc tak, prawdopodobnie w niektórych przypadkach byłoby to wystarczająco dobre, aby mieć prosty token oparty na satoshi.

Czy uważasz, że może istnieć wiele protokołów Token na szczycie BSV? Jeśli tak, dlaczego? Czym się to różni od twierdzenia, że ​​wiele kryptowalut może współistnieć?

Gu Lu: Szczerze nie wiem. Generalnie nie upraszczam zbytnio rzeczy, zwłaszcza jeśli chodzi o tak globalnie ewoluujący złożony system. Posiadanie „jednego łańcucha do rządzenia wszystkimi” może zająć znacznie więcej czasu niż większość bitcoinerów. Inżynierowie wprowadzają różne koncepcje i metody, aby radzić sobie z różnymi sytuacjami i dokonywać różnych kompromisów między wieloma aspektami, używając różnych protokołów tokenów (lub nawet połączonych w niektórych przypadkach) w celu utworzenia różnych rozwiązań, tak jak używają różnych języków programowania, frameworków, bibliotek skutecznie wyrażać swój pomysł. Ignorowanie złożoności i różnorodności oraz zmuszanie ludzi do ujednolicania „czegoś” może nie być dobrym pomysłem. Wolałbym zachęcać do bardziej integracyjnej atmosfery, która umożliwia ludziom wyrażanie swoich pomysłów i pokazywanie swoich talentów bez obaw o izolację.

Ethereum

Jak BSV może konkurować z Ethereum?

Gu Lu: To ogromne pytanie i nie byłem jeszcze przygotowany, aby na nie odpowiedzieć. Ogólnie rzecz biorąc, BSV może zawierać znacznie więcej transakcji o rzędach wielkości niż ETH. Ale czy wszystkie aplikacje działające na EVM można migrować, aby działały wystarczająco dobrze na maszynie wirtualnej bitcoin? To nie jest jasne i oczywiste. Solidność oraz model kont i zdarzeń z pewnością nie są wystarczająco wyrafinowane, ale przynoszą wartość, której nie można łatwo zastąpić zakontraktowanymi aplikacjami opartymi na UTXO. Jednak zbyt mało wiemy o bitcoinie i wciąż się uczymy, mam nadzieję, że następnym razem, gdy zadam to pytanie, będę mógł być bardziej pewny siebie.

Jak BSV może zyskać na współpracy z ETH i DeFi?

Gu Lu: ETH/Defi daje nam doskonałe przykłady użycia do zbadania, co możemy zrobić z Sensible Contract. Zrobimy więcej badań i zdobędziemy więcej doświadczeń, analizując, co dzieje się w tych projektach (co poszło dobrze, a co poszło nie tak) Po zbudowaniu prototypu na BSV, który obsługuje podobną logikę biznesową, możemy użyć ETH jako benchmarku dla naszych aplikacji . Porównanie opłat, przepływności transakcji itp., co generalnie pozwala zaoszczędzić dużo czasu.

Generał Jak myślisz, jaki wpływ na BSV miała narracja LAW w odniesieniu do tokenizacji?

Gu Lu: Odpowiedzią poprawności politycznej na to jest „kod jest kodem” i „prawo jest prawem”. Jednak użycie samego blockchaina do automatycznej i natychmiastowej walidacji nie wyłącza działania „prawa”. Nadal możesz używać „prawa”, aby się bronić, kiedy jest to potrzebne, tak jak w przypadku każdego scenariusza, który spotkasz w życiu. Używając kontraktu poprawnie i mądrze, nic nie tracisz (w aspekcie „prawa”), ale zyskujesz sprawnie zautomatyzowaną potwierdzoną transakcję. Dlatego w pierwszej kolejności używamy skryptu bitcoin. Jeśli odwołujesz się do używania op-return w celu naśladowania księgi rachunkowej i korzystania z autorytetu lub zewnętrznych walidatorów (i polegasz na „prawie”, aby je złapać), prawdopodobnie poniesiesz znacznie wyższy koszt niż twój przeciwnik, który używa podejście zautomatyzowanej metody kontraktowej. Tak, możesz wrócić do tradycyjnych sposobów robienia rzeczy i powtarzać ludziom, że „prawo” pomoże. Ale chodzi o to, że „prawo” zawsze powinno/powinno pomóc, niezależnie od tego, jak prowadzisz swoją działalność. Jeśli prawo i tak pomaga, dlaczego nie wybrać opłacalnej metody wykorzystującej zautomatyzowany model kontraktowy, który jest wykonywany i walidowany w łańcuchu? Mając to na uwadze, myślę, że warto wspomnieć, że dobrze sformułowany proces KYC i AML jest bardzo cenny dla osób, które chcą poważnie budować swój biznes na BSV. Działamy również bardzo aktywnie w tym obszarze.

Gdybyś mógł machnąć magiczną różdżką i zmienić coś w kulturze BSV lub środowisku biznesowym, co by to było?

Gu Lu: Od 15 lat jestem weteranem w branży gier. Dowiedziałem się, że na kulturę i środowisko danej branży składa się wiele aspektów, które wpływają na siebie w bardzo skomplikowany sposób, co warto szanować. Rozsądnie jest dostosować się do tego na różne sposoby i sprawdzić, czy możesz wnieść swój wkład w efektywny sposób, czy nie.

Dodatkowo, mam tendencję do myślenia w taki sposób, aby wykorzystać atrybuty, na które BSV może sobie pozwolić, aby zbudować coś dobrego dla moich celów, a nie budować coś, co ekosystem BSV „rozważa”/„akceptuje”, co jest warte zrobienia. Zmuszam się, aby zawsze myśleć z takiego „zewnętrznego punktu widzenia” na społeczność. Ponieważ świat nie powinien/nie powinien „ostrożnie” pomagać BSV w rozwoju i sukcesie. Wręcz przeciwnie, BSV powinno przetrwać i dostarczać wartość innym branżom (w moim przypadku branży gier), aby legitymizować swoje istnienie.

Poniżej załączam schemat ekosystemu Sensible Contract w celach informacyjnych.

Autor : BitcoinSV.pl

Źródło : Token protocols on BSV: Sensible Contract – CoinGeek



Author: BitcoinSV.pl
CEO