The TAO -Tritium update #2

Colin Cantrell -blog

Dzisiejszy wpis Colina. zdecydowanie łatwiej z nim rozmawiać niż go czytac . :) Geniusz . Nic z tego nie rozumiem :)
Dużo zmian. , było łącznie 5 885 nowych linii kodu, z zastąpieniem 3 980 linii. Ogólnie oznacza to, że jakiś starszy kod został zastąpiony nowym, lepszym kodem, a także prawie 2000 linii nowego i świeżego kodu.
ZMIANY:
Sieć
Od ostatniej aktualizacji wprowadziliśmy kilka ulepszeń do sieci LLP w naszej instancji.
Sieć jest odpowiedzialna za całą komunikację typu end-to-end.
Jeśli sieć nie może propagować wiadomości, rdzeniowa sieć równorzędna nie będzie mogła działać. W naszym przypadku krypto (LLC) jest nakładką dla pewnych wiadomości sieciowych,, takimi jak nasze transakcje lub bloki.
ponieważ LLL jest podstawą TAO, stąd nazwa repozytorium LLL-TAO
Kolejnym aspektem sieci, który został formalnie zademonstrowany przez Dino Farinacciego, jest architektura LISP w celu zapewnienia bezpieczniejszej warstwy danych w Internecie. Jak wiemy teraz, istnieje wiele takich samych problemów z tożsamością: kiedyś było widać, że Internet był miejscem pełnym fałszywych rachunków, trolli i dezinformacji. Ostatnio jednak odkryliśmy, że internet może być pełen niesamowitych rzeczy i niesamowitych możliwości promowania idei wolności i dobrobytu.
Teraz jednym z powodów, dla których sieć była nękana negatywnymi aspektami, jest brak warstwy zaufania w rzeczywistym systemie. Nie mamy możliwości zidentyfikowania kogoś innego niż jego adres IP, który jest łatwy do podrobienia w dowolny sposób. Może to powodować problemy, ponieważ nie można wiarygodnie wiedzieć, z kim się komunikujesz. (nie oznacza to, że muszą znać dane osobowe, ale raczej spójność tożsamości). Teraz, łącząc LISP i Nexus razem , tworzymy możliwość ustalenia tożsamości kryptograficznej użytkownika. Dzieje się tak w sieci ze statycznym identyfikatorem EID w LISP-ie w łańcuchu sygnatur dla użytkownika. Staje się to bardzo ważne dla ograniczenia oszustw i kradzieży tożsamości, co jest jednym z głównych punktów Nexusa.
Księga główna
Księga składa się z serii zdarzeń, które ustanawiają własność każdego rejestru w stosie. To sprawia, że ​​księga działa bardzo szybko, ponieważ nie ma niewiarygodnego nadmiaru w wymaganiach przetwarzania poza ogólnymi funkcjami kryptograficznymi. Największe wąskie gardło księgi Ledger należy do LLC (Kryptografia niższego poziomu), ponieważ dzieje się to w przypadku weryfikacji kryptograficznej. Najnowsze wyniki testu skalowania księgi (tylko transakcje, brak bloków w tym teście) pokazują ponad 4,3 tys ttansakcji / s, które mogą być przetwarzane przez pojedynczy węzeł.
Daje to dobry obraz tego, jak mógłby wyglądać pełny stos LLL, który zawiera prawdziwe dane transakcji. To pokazuje, że LLD łatwo nadąża za żądaniem pisania ponad ~ 1500 Kb / s (Bitcoin ma maksymalnie ~ 1,7 Kb / s). Przyczyną spowolnienia w Bitcoinie jest ograniczenie rozmiaru bloku do 1Mb co 10 minut. W tym przypadku chcieliśmy zademonstrować wydajność stosu LLL w jego zdolności do obsługi dużych ilości danych. Ten konkretny przykład pokazuje maksymalne możliwości przetwarzania jednego węzła, które w zasadzie byłyby ograniczeniami jednego kanału przetwarzania stanu L1. Agregacja sygnatur przekazywana z węzłów weryfikacyjnych L1 do L2 do L1 w 3DC umożliwiłaby wyższy poziom skalowalności bez poświęcania bezpieczeństwa globalnego zestawu walidatorów konsensusu.
Łańcuch podpisów
Działa dobrze, z prostą strukturą danych, która umożliwia łatwe indeksowanie i lokalizowanie historii transakcji łańcucha podpisów oraz identyfikację własności rejestru. Ponieważ łańcuch sygnatur GenesisID ma 256-bitową przestrzeń numeryczną, łatwo jest przenieść uprawnienia rejestru do właściciela łańcucha podpisów lub po prostu innego rejestru. Ustawia to teraz podstawę Nexus Digital Identity System.
Rejestr
Rejestr to obiekt danych, który zmienia stan za pomocą globalnego konsensusu lub aplikacji warstwy logicznej.
Dlaczego rejestry są ważne?
Komputery są z natury maszynami państwowymi. Zawierają one wartość, która koreluje z czymś w świecie zewnętrznym i zmieniają tę wartość na podstawie sekwencji logiki.
To skomplikowane, ale w rzeczywistości jest to dość proste. Jeśli mam 5 jabłek, zapisuję tę liczbę w rejestrze, który posiadam, aby udowodnić, że mam te 5 jabłek. Kiedy inni ludzie mogą zapytać mnie, ile mam jabłek, mogę podać im mój adres rejestracyjny, a oni widzą, ahh, rzeczywiscie ma 5 jabłek. Teraz, jeśli sprzedam jabłko,mówię sieci, że daje ci to 1 jabłko, jeśli dasz mi 0,1 NXS, wtedy będziemy mogli mieć zmiany stanu zarejestrowane i zweryfikowane przez sieć, skorelowane z transakcjami finansowymi. Oznacza to, że gdyby ktoś dokonał tego przeniesienia to przez smartcontrakt , mógłby dokonać zmiany stanu moich jabłek na 4, a ja wyślę jabłko do uroczego klienta. Jest to prosty przykład, wiem, ale jego intencją nie jest wykazanie bezpiecznej logiki programowej, ale raczej logika pokazująca użycie rejestru na Nexusie.
Każdy z tych 4 obiektów to obiekty, które mogą zmienić stan za pomocą mechanizmu konsensusu księgi. Jest to ważne w przypadku tokenów, depozytów, zleceń i kont, ponieważ nie powinienem móc modulować salda na moim koncie bez zgody sieci. Minusem tego, że księga dokonuje całej zmiany stanu rejestrów za pomocą kodów operacji, jest zapotrzebowanie na zasoby wszystkich węzłów do przetwarzania tej zmiany stanu i zapewnienie, że nie powoduje ona konfliktu z innym stanem. Bardzo ważne staje się znalezienie równowagi pomiędzy zmianami stanu logicznego i księgowego, ponieważ sieć nie zawsze musi wiedzieć wszystko, co robi warstwa logiczna, a warstwa logiczna nie powinna robić wszystkiego, co robi księga. Rozróżnienie to jest ważne dla zrozumienia, w jaki sposób zaawansowane umowy Nexusa będą skalowane do poziomów wymagań dotyczących masowej adopcji
. Z drugiej strony rejestry stanu rejestrowego są określane na podstawie specyfikacji na warstwie logicznej. Działają bardzo szybko, ponieważ węzły muszą tylko zapisywać dane, adres i właściciela rejestru. Tylko właściciel tego rejestru będzie mógł zapisać do niego nowy stan, jeśli nie jest zdefiniowany jako tylko do odczytu. Umożliwia to warstwom logicznym / interfejsem (przestrzeń aplikacji) zapisywanie ważnych danych w swoim systemie, takich jak hashe do plików IPFS, prywatne transakcje bazy danych, a nawet tworzenie obiektów autoryzacji w celu modulowania stanu ich bazy danych na podstawie działań użytkownika. Operacje następujące są w pełni implementowane, a funkcjonalność jest realizowana za pośrednictwem elementu danych vchLedgerData w klasie Transakcji Trytu Nowy stan na adres rejestru podany jako parametr kodu operacji. OP_REGISTER: Utwórz nowy rejestr w sieci. Musi zawierać unikatowy adres rejestru, żądający go dla tego łańcucha podpisów. OP_TRANSFER: Przeniesie własność rejestru na inny łańcuch podpisów lub na inny adres rejestru. Jest to ważna funkcja do ustalenia własności danych przez łańcuch podpisów i łańcuchdostaw, który przenosi je z jednego właściciela na następny.4. OP_DEBIT: obciążenie tokena z danego rejestru obiektów konta. Jest to operacja polegająca na zaangażowaniu środków finansowych, która daje odbiorcy możliwość roszczenia z odpowiednim kredytem. Saldo zadłużenia, o które można się ubiegać, zależy od wartości procentowej własności wyświetlanej w czasie. 5. OP_CREDIT: Rzaądanie salda odwołującego się do debetu transakcyjnego, który został użyty do zatwierdzenia środków na dane konto odbiorcze. Jeśli kredyt pobiera fundusz debetowy z konta, który jest współwłaścicielem łańcucha rejestrów, wymagany jest dowód czasowy, aby spełnić warunki wyświetlania praw własności. Ta metoda jest odpowiedzialna za zmianę stanów na poziomie księgi, ponieważ operacje są instrukcjami dla węzłów przetwarzania, aby modulować stan rejestru poprzez globalny konsensus. Warstwy operacji i rejestrów są projektowane tak, aby były przetwarzane na wyższych poziomach3DC (mianowicie L2) w celu zapewnienia, że ​​przetwarzanie transakcji jest dzielone na wiele warstw węzłowych, co zwiększa naszą zdolność do skalowania zaawansowanego przetwarzania kontraktów.
Weryfikacja
Po kodzie znajduje się skrypt sprawdzania poprawności, który będzie wymagał sprawdzenia poprawności logiki boolowskiej w celu sprawdzenia wartości , jeśli kod operacji ma być zgłaszany jako dowód. Oznacza to, że pewna logika musi być prawdziwa, aby można było zażądać tej operacji. Przykładem może być: "Nie dzwoń do mnie po 21:00", jeśli ktoś próbowałby zadzwonić, połączenie nie byłoby możliwe.
API
Interfejs programowania aplikacji użyje tak zwanego JSON (Java Script Object Notation) do przesyłania poleceń do węzłów, które tworzą te zmiany stanu w rejestrze, co skutkuje logiką programu, która daje nam możliwość korzystania z zaawansowanych kontraktów.
Interfejs API będzie składał się z dwóch komponentów: publicznego i prywatnego.
Jest to ważne, ponieważ publiczny interfejs API będzie zawsze rozwijany przy użyciu środków publicznych za pośrednictwem wielu Ambasad Nexus i zapewni wymaganą funkcjonalność do użytku publicznego. Obejmuje to większość przypadków użycia i programowalną logikę.
Prywatny
Powodem tego jest integracja firm, które wymagają pewnej logiki aplikacji, aby były bardziej wyspecjalizowane w zakresie funkcjonalności API, ze względu na zastrzeżony charakter ich rozwoju. Staje się to również szansą na integrację "oprogramowania jako usługi" dla ambasady w celu wygenerowania dodatkowych źródeł przychodów, w których zyski mogą zostać ponownie wykorzystane w procesie rozwoju
.
Logiczne i interfejs
Nowy portfel Nexus Tritium znajduje się teraz w publicznej wersji beta. Uruchomienie tego przyniosło niesamowitą ilość informacji zwrotnych i zgłoszeń błędów, aby ulepszyć interfejs i warstwy logiczne. Jak wielu z was już wie, zapewniamy jeden wspólny interfejs dla takiej funkcjonalności, gdzie każdy inny twórca aplikacji rozproszonych będzie mógł sam się rozwijać.
Warstwa logiczna jest tam, gdzie większość przetwarzania jest wykonywana. Jest to rozszerzona przestrzeń aplikacji przez OSI.
Ważne jest, aby to zrozumieć, ponieważ idea blockchain ma wiele konotacji, które wykraczają poza samą księgę. Może koordynować wiele systemów, mieć prywatne sieci, które działają i rejestrować stan z księgi głównej, schematy kontroli dostępu, rejestrowanie stanu w oparciu o działania użytkowników, a lista może być kontynuowana. Chcielibyśmy pozostawić tę dziedzinę otwartą dla każdego nowego typu programisty, aby rozszerzyć swoją przestrzeń zastosowań z konwencjonalnego projektu OSI.
Przyszłość
Jak widać z tego posta na blogu, większość rozwoju TRITIUM jest teraz kompletna . Oznacza to, że jesteśmy w fazie tkania kodu w sieci, ustanawiania lokalnych baz danych do obsługi indeksów sigchain i rejestrów oraz dodawania komend RPC niższego poziomu do interakcji z Księgą, przy czym API wyższego poziomu jest interfejsem w komendzie zestaw.
Co to znaczy?
Tritium zostanie wydane pod koniec stycznia 2019 roku. Tak Jak zauważyliśmy w ciągu ostatniego roku, usunięcie map drogowych i osi czasu nie przyniosło zamierzonych rezultatów, spowodowało jedynie dalszą niepewność i pogłoski w projekcie. Przechodząc do trzeciego rozdziału naszych książek historycznych z rozproszonymi ambasadami, nowszą architekturą i rozproszonymi modelami zarządzania, uważamy, że należy uzupełnić to zobowiązaniami ze strony zespołu programistów, aby ustalić i dotrzymać terminów.
Do następnego razu, moi przyjaciele.