W tym tygodniu przyjrzymy się kilku bardziej technicznym aspektom stojącym za Bitcoin BSV i leasingodawcą znanym pod maską komponentów, które są bardziej interesujące dla studentów informatyki. Porozmawiamy o kompilatorach, kodzie bajtowym i BSV jako komputerze. Więc jeśli to twoja filiżanka herbaty, załóż garnitur, chwyć swoją tarczę i miecz, mężny rycerzu, bo dzisiaj zabijemy smoki!
Kiedy byłem na uniwersytecie, w budynku Matematyki był specjalny pokój, w którym znajdował się dział informatyki, ze złowieszczym napisem nad drzwiami, który głosił: „Porzućcie wszelką nadzieję wy, którzy tu wchodzicie!”
To była oczywiście siedziba klubu informatycznego… grupa samotników maniaków, którzy mają niezdrowe upodobanie do modeli pociągów. W rzeczywistości w jednym z pokoi znajdował się gigantyczny zestaw modeli, który był częścią czwartego roku kursu na temat systemów operacyjnych czasu rzeczywistego. W tym czasie żywiłem ogólną niechęć do mieszkańców, którzy bywali w tym pokoju, częściowo dlatego, że często mówili językiem, którego nie mogłem zrozumieć, choć głównie z powodu bezbożnego zapachu, który przenikał z jego wilgotnych wnętrz.
W tamtym czasie nie wiedziałem, że praktykowane wewnątrz sztuki mistyczne będą czymś, w czym pochłonie mnie jakieś 25 lat później… a mianowicie ta mroczna sztuka kompilatorów języków komputerowych. Dlaczego kompilatory są ważne? Bo BSV to komputer. Mówiąc dokładniej, jest to maszyna wirtualna. W początkach komputerów każdy procesor miał inny zestaw instrukcji, a kompilatorzy mieli trudne zadanie przetłumaczenia kodu komputerowego wysokiego poziomu na inną formę kodu maszynowego, która była specyficzna dla sprzętu komputerowego, na którym chcesz uruchomić program . To był w dużej mierze powód, dla którego była to taka „czarna sztuka”, a praktycy-eksperci w tej dziedzinie byli często uważani za „czarodziejów”.
W ostatnich latach spopularyzowała się koncepcja maszyny wirtualnej, czyli maszyny symulowanej, ze wspólnym językiem kodu bajtowego i znacznie uprościła zadanie kompilacji języka. Ponieważ kompilatory nie musiały już tłumaczyć języków na każdy indywidualny kod maszynowy, ale tylko na tymczasowy kod bajtowy, który został zaprojektowany na tyle uniwersalnie, że konkretne implementacje maszyn wirtualnych przetwarzające ten uniwersalny kod bajtowy mogły być uruchamiane na dowolnym konkretnym sprzęcie. wyeliminowanie zbyt wielu zadań translacyjnych, które kompilatory musiały obsługiwać.
Najczęstszym przypadkiem sukcesu zastosowania maszyny wirtualnej jest Java, wciąż najpopularniejszy język do tworzenia aplikacji korporacyjnych. Ostatnio, w projektach takich jak LLVM i WebAssembly, pomysł, że języki powinny budować na pośredniej reprezentacji (lub IR), która może być następnie oddzielnie kompilowana na konkretnym sprzęcie lub wykonywana bezpośrednio na maszynie wirtualnej, naprawdę podkreślił moc tego modelu.
Jak więc Bitcoin pasuje do tego wszystkiego? Jak już wspomniano, BSV jest samą maszyną wirtualną. Wszystkie węzły, które weryfikują transakcje w łańcuchu blokowym, obsługują zestaw instrukcji, który jest kompletny według Turinga — o ile nie ma teoretycznych ograniczeń rozmiaru skryptów — co oznacza, że można zaprogramować sieć tak, aby obliczała wszystko, co da się obliczyć. Ten skrypt bitcoin można traktować jako kod bajtowy BSV. A programowanie do tego jest prostym zadaniem opracowania kompilatorów, które mogą przekształcić języki wysokiego poziomu w kod bajtowy BSV. Niektóre projekty, takie jak Scrypt, już robią wielkie postępy w tej przestrzeni.
Jednak w porównaniu ze standardowym FORTH, kod bajtowy BSV VM nie ma kilku kluczowych funkcji (kody OP):
OP_CALL czyli możliwość przekazania wykonania do podprogramów
OP_LOOP czyli możliwość ponownego wykonania podanych bloków kodu
Identyfikatory
Bezpośrednie przydzielanie/dostęp do pamięci
Bez tych pozornie istotnych cech języka, jak maszyna może być Turing Complete? Cóż, wystarczy powiedzieć, że są to pytania najlepiej zadawane ekspertom informatyki, którzy bez wątpienia byliby w stanie odpowiedzieć na te pytania bardziej zwięźle w sposób, który zadowoliłby najbardziej wymagających ekspertów. Nie jestem jedną z takich osób. Jednak w prostych słowach laika, każda z tych funkcji jest tylko narzędziem wygody, a nie podstawowym wymogiem działania zwykłego komputera. Na przykład: możliwość wywołania podprogramów zdefiniowanych zewnętrznie (OP_CALL) można uniknąć, zastępując wywołanie samym kodem podprogramu w linii.
Potrzebę zapętlania (OP_LOOP) można zastąpić po prostu iteracją kodu pętli dosłownie w programie, z odpowiednimi zmiennymi iteracji umieszczonymi na stosie, w rzeczywistości jest to i tak zaimplementowana pętla rekurencyjna pod okładkami. Bez potrzeby wywoływania podprogramów identyfikatory nie są potrzebne, biorąc pod uwagę, że wszystkie zmienne można zastąpić ich wartościami czasu wykonywania, do czego przyzwyczajeni są już doświadczeni programiści FORTH, ponieważ lokalni rzadko są nazywani, jeśli w ogóle.
Wreszcie, potrzeby bezpośredniego dostępu do pamięci można uniknąć, jeśli wszystkie potrzeby dotyczące tymczasowej pamięci masowej można pokryć za pomocą głównego i alternatywnego stosu programów. W rzeczywistości z trzech podstawowych cech programowania strukturalnego: sekwencjonowania, selekcji i powtarzania, BSV obsługuje natywnie pierwsze dwie i może naśladować trzecią.
Spośród wszystkich ograniczeń, ostatnie ograniczające dostęp do pamięci losowej wydaje się być najbardziej restrykcyjne, ponieważ ogranicza to programy do pracy we własnej tymczasowej piaskownicy, nie mogąc wykorzystać zasobów pamięci i pamięci platformy sprzętowej, z którymi mogą się zdarzyć być uruchomione, ale jest to zaletą, jeśli weźmiesz pod uwagę, że chcesz, aby programy były uruchamiane uniwersalnie w heterogenicznej sieci maszyn, od serwerów o dużej mocy w centrum danych po niskonakładowe Raspberry Pi, a nawet urządzenia wbudowane o małej mocy .
Wymuszenie tego ograniczenia na programie oznacza, że wszelkie informacje, do których program musi uzyskać dostęp, muszą być mu dostarczone w transakcji, w której znajduje się UTXO programu, transakcji, która je „wydaje”, co w tym przypadku byłoby bardziej właściwe jest powiedzenie „wykonywanie”, co jest możliwe dzięki inteligentnym protokołom kontraktowania na BSV, takim jak STAS, które pozwalają na refleksję, introspekcję i warunki wydatkowania narzucające własne wyniki transakcji. Jak widzieliśmy sukces tego modelu obliczeniowego, w ciągu ostatnich kilku dekad z przeglądarkami i Javascriptem, następna iteracja może dotyczyć węzłów obliczeniowych BSV i Bitcoin.
Gdy ludzie zaczną zdawać sobie sprawę, że Bitcoin to tylko nowy rodzaj maszyny wirtualnej, nieuchronnie mądrzy z nas zaczną pracować nad tym, jak skutecznie go zaprogramować, aby robił przydatne rzeczy. Jedną z najbardziej obiecujących ewolucji modeli obliczeniowych w ostatnich czasach jest MapReduce, czyli programowanie zorientowane na dane rozproszone. Zasadniczo obejmuje daną funkcję lub proces, który jest „odwzorowywany” na dużym zbiorze danych, ze sposobem zbierania/agregowania wyników z wielu równoległych wykonawców. Sieć Bitcoin, z dynamicznie dostosowującą się liczbą węzłów i wykonawców, wydaje się być dobrze przygotowana do wykorzystania jako gigantyczna pula pracowników wykonujących zadania obliczeniowe, gotowych i chętnych do wykonywania kodu na publicznych zbiorach danych, generujących wyniki zapisywane w łańcuchu bloków — za odpowiednią cenę, oczywiście.
Autor : BitcoinSV.pl
Źródło : BSV as a virtual machine – CoinGeek
