Byteball: zdecentralizowany system przechowywania i transferu wartościAnton Churyumovtonych@byteball.org

Streszczenie Byteball to zdecentralizowany system umożliwiający bezpieczne przechowywanie dowolnych danych, w tym także danych dotyczących transferowalnych wartości w postaci walut, tytułów własności do nieruchomości, informacji o zadłużeniach, udziałów, itp. Jednostki, w których dane są przechowywane są ze sobą połączone w taki sposób, że każda jednostka przechowująca zawiera jedną lub więcej liczb haszujących wcześniejszych jednostek, które wykorzystywane są zarówno w celu potwierdzenia wcześniejszych zdarzeń, jak i ich wstępnego uszeregowania. Zbiór połączeń pomiędzy poszczególnymi jednostkami tworzy DAG - directed acyclic graph – skierowany graf acykliczny. Nie istnieje żadna centralna jednostka, która zarządzałaby lub koordynowała proces wprowadzania nowych jednostek do baz danych; wszyscy mogą umieszczać nowe jednostki pod warunkiem, że je podpiszą i dokonają opłaty równej rozmiarowi dodanych danych w bajtach. Opłaty są pobierane przez innych użytkowników, którzy następnie zatwierdzają nowo dodane jednostki umieszczając swoją liczbę haszującą we własnych jednostkach. W miarę dodawania kolejnych jednostek, każda poprzednia otrzymuje coraz więcej akceptacji (potwierdzeń) przez następujące po nich, które zawierają jej liczbę haszującą pośrednio lub bezpośrednio.

Istnieje wewnętrzna waluta nazywana “bajtami”, która jest wykorzystywana w celu opłacenia usługi związanych z umieszczeniem danych w zdecentralizowanej bazie danych. Inne waluty (aktywa/środki) mogą być także swobodnie wysyłane przez dowolne osoby jako dowód posiadania/przekazania tytułu własności, zadłużenia, udziałów, itp. Użytkownicy mogą przekazywać sobie wzajemnie zarówno bajty jak i inne waluty w celu sfinansowania zakupu towarów/usług lub wymiany jednej waluty na inną; transakcje, które przenoszą wartości są wprowadzane do bazy danych jako jednostki składowania. Jeżeli dwie transakcje podejmują próbę wysłania tych samych wartości/danych wyjściowych (podwójne wydatkowanie) i nie ma żadnego choćby częściowego ładu chronologicznego (sekwencji) pomiędzy nimi, obie transakcje są wprowadzane do bazy danych, ale tylko jedna z nich – ta, która występuje jako pierwsza w ogólnym porządku jest uznana za ważną. Ogólne uporządkowanie/uszeregowanie transakcji powstaje dzięki wybraniu jednego łańcucha w DAG (łańcuch główny), który jest przyciągany przez jednostki podpisane przez znanych użytkowników nazywanych świadkami. Jednostka, które wartość haszująca została wcześniej umieszczona w łańcuchu jest uznawana za wcześniej występującą w ogólnym uszeregowaniu (szyku) transakcji. Użytkownicy dokonują wyboru świadka, któremu ufają określając jego nazwę w każdej składowanej jednostce. Świadkowie są renomowanymi użytkownikami posiadającymi rzeczywiste tożsamości (w świecie rzeczywistym), a użytkownicy, którzy się na nich powołują oczekują, że nigdy nie podejmą próby podwójnego wydatkowania transakcji. Tak długo jak większość świadków zachowuje się zgodnie z oczekiwaniami, wszelkie próby podwójnego wydatkowania są wykrywane na czas i odpowiednio oznaczane w systemie. W miarę jak jednostki autoryzowane przez świadków zaczynają się gromadzić po jednostce wysłanej przez użytkownika, pojawiają się kryteria deterministyczne (a nie probabilistyczne), kiedy ogólne uszeregowanie wszystkich jednostek użytkownika zostaje uznane za ostateczne.

Użytkownicy przechowują swoje środki finansowe pod adresami, które mogą wymagać więcej niż jednego podpisu, aby fundusze mogły być wydatkowane (multisig). Transakcje te mogą także

wymagać spełnienia innych warunków, w tym warunków, które są oceniane z perspektywy szczególnych danych umieszczanych w bazie danych (oracles).

Użytkownicy mogą emitować nowe środki i definiować zasady ich przekazywania. Zasady te mogą obejmować ograniczenia w postaci wymogu kontrasygnaty przez wysyłającego środki, który ma charakter jednokierunkowy, aby zapewnić instytucjom finansowym zgodność z obowiązującymi przepisami. Użytkownicy mogą także wysyłać/emitować środki, których transfer nie będzie publikowany w bazie i tym samym będzie niewidoczny dla stron trzecich, informacje te są wymienia niepublicznie (prywatnie) pomiędzy użytkownikami i jedynie liczba haszująca transakcji oraz wysłany proof (zapobiegający podwójnemu wydatkowaniu) jest publikowany w bazie danych.

1. WprowadzenieIn orwellowskiej powieści zatytułowanej: 1984, główny bohater - Winston Smith – pracuje w Departamencie Rejestrów Ministerstwa Prawdy jako redaktor zajmujący się weryfikacją zapisków historycznych w celu zrównania zdarzeń z przeszłości do stale zmieniającej się linii politycznej i usuwa wszelkie odniesienia do osób, które nie są osobami – które zostały „wyparowane”, tzn. nie tylko zlikwidowane przez państwo, ale także takie, którym odmówiono przywileju istnienia w historii lub (zbiorowej) pamięci [1]. W niniejszym materiale przedstawiamy możliwość/sposób przechowywania danych, którego nie można zmienić – przepisać/nadpisać. Jest to rozproszona, zdecentralizowana baza danych, której rekordy nie mogą być ani całkowicie zmienione, ani usunięte bez śladu. Bitcoin [2] był pierwszym systemem, który wprowadził chronione rekordy zaprojektowane w szczególnym celu: aby śledzić, kolejne zmiany właścicieli walut elektronicznych znanych także pod nazwa bitcoin. W systemie Bitcoin, wszystkie transakcje transferu walut są przedstawiane jako transakcje posiadające podpis cyfrowy złożony przez bieżącego właściciela coinów, a transakcje są powiązane w bloki, które z kolei tworzą łańcuchy (blockchainy) zabezpieczone algorytmem proof of work (PoW), który gwarantuje, zaangażowanie ogromnych zasobów obliczeniowych w proces budowy łańcucha. Wszelkie próby zmiany (przepisania) elementów łańcucha będą w związku z tym wymagać jeszcze większych zasobów obliczeniowych, niż te, które właśnie zostały poniesione.

Wkrótce po pojawieniu się Bitcoina, stało sią oczywiste, że jest on czymś więcej niż tylko elektroniczną walutą typu trust-free P2P. Leżącą u jego podstaw technologia stała się źródłem inspiracji dla nowych pomysłów i rozwiązań zupełnie innych problemów. Jednocześnie, wszystkie niedociągnięcia i ograniczenia Bitcoina ujrzały światło dzienne. System Byteball powstał w celu nadania Bitcoinowi bardziej ogólnego, uniwersalnego charakteru i przekształcenia go w bezpieczny system do przechowywania dowolnych danych, a nie tylko do obsługi transakcji zawartych w elektronicznych jednostkach walutowych, a także w celu usunięcia z Bitcoina niego najbardziej kłopotliwych niedociągnięć utrudniających szersze jego wykorzystanie i rozwój.

Bloki. W systemie Bitcoin, transakcję są wiązane w bloki, które z kolei są łączone w jeden łańcuch. Ponieważ bloki są łączone ze sobą liniowo, ich odległość w czasie, a także rozmiar są zoptymalizowane w taki sposób, aby osiągnąć stan zbliżony do pełnej synchronizacji

pomiędzy węzłami, aby te mogły dzielić się nowym blokiem ze sobą o wiele szybciej niż ma to miejsce w przypadku tworzenia zupełnie nowego bloku. Podejście to gwarantuje, że węzły będą najprawdopodobniej widzieć ten sam blok jako ostatni poziom osierocenia zostanie zredukowany do minimum. W miarę wzrostu Bitcoina, bloki stają się w coraz większym stopniu „nieporęczne” i trudne w obsłudze. Albo ich rozmiar jest ograniczony, w którym to przypadku wzrost jest także ograniczony, albo są zbyt długie, aby można było je upowszechnić we wszystkich węzłach sieci, w którym to przypadku istnieje większa niepewność odnośnie do tego, który blok jest ostatni i pojawia się konieczność poświęcenia znaczniejszych na rozszerzenie łańcucha, który następnie zostanie osierocony. W systemie Byteball nie ma żadnych bloków; to transakcje tworzą swoje własne bloki i nie muszą przy tym łączyć się w jeden łańcuch. Zamiast tego, transakcja może być połączona z wieloma wcześniej wprowadzonymi do systemu transakcjami, a zbiór transakcji nie będzie tworzyć łańcucha, ale DAG - directed acyclic graph – ukierunkowany graf acykliczny. Projekty oparte na DAG cieszą się w ostatnim czasie dużym zainteresowaniem [3-5].

Koszty. Transakcje bitcoinowe są bezpieczne, ponieważ “przerobienie” wszystkich PoW wprowadzonych do bloków utworzonych po danej transakcji jest absurdalnie drogie. Oznacza to także, że konieczne jest dokonanie opłaty za zbudowanie legalnego PoW, który będzie silny, że zdoła odstraszyć wszelkich atakujących. Opłaty te są wydawane na prąd konieczny do zbudowania PoW. W tym miejscu warto podkreślić, że środki te wychodzą poza ekosystem Bitcoina – są kierowane do firm dostarczających energię elektryczną – co oznacza, że społeczność posiadaczy Bitcoinów jako taka pozbywa się kapitału. W Byteball nie ma żadnych PoW; zamiast tego, wykorzystujemy inny algorytm konsensusu oparty na starym pomyśle zrodzonym na długo zanim pojawił się Bitcoin.

Nieodwołalność (ostateczność). Nieodwołalność transakcji w Bitcoinie ma charakter probabilistyczny. Nie istnieją żadne ściśle określone i proste kryteria, aby móc powiedzieć, że transakcja nigdy nie zostanie odwrócona. Można jedynie dowodzić, że prawdopodobieństwo, że transakcja zostanie odwrócona (cofnięta) zmniejsza się wykładniczo w miarę pojawiania się coraz to nowych bloków. Chociaż koncepcja ta jest absolutnie czytelna, dla osób znających zasady matematyki, może okazać się nieco trudniejsza do zrozumienia dla przeciętnego Kowalskiego, który jest przyzwyczajony do biało-czarnego obrazu w kwestiach dotyczących własności środków finansowych. Aby sprawy jeszcze bardziej skomplikować, nieodwracalność transakcji jest także uwarunkowana kwotą. Jeżeli jest ona niewielka, można mieć uzasadnioną pewność, że nikt nie będzie podejmować próby jej podwójnego wydatkowania na Waszą niekorzyść. Jeżeli natomiast kwota ta przekracza wartość nagrody z bloku (w chwili opracowywania niniejszego materiału jest to równowartość 12,5 BTC), można zastanawiać się nad tym, czy odbiorcy nie opłacałoby się wynająć okresowo mocy haszującej, aby wydobyć kolejny łańcuch bloków, które nie zawierają transakcji zawierającej należne Wam środki. Dlatego też, musicie poczekać na uzyskanie większej liczby akceptacji (potwierdzeń), zanim nabierzecie pewności, że transakcja o dużej wartości ma charakter ostateczny. W Byteball, stosowane są kryteria deterministyczne dla ustalenia czy i kiedy transakcja jest ostateczna bez względu na jej wielkość.

Kurs wymiany. Wartość (cena) Bitcoina jest dość niestabilna. Większym problemem jest jednak to, że jest ona nie tylko niestabilna, ale także z niczym nie powiązana. Ceny akcji i towarów są także bardzo lotne, ale stoją za nimi pewne fundamentalne wartości. Cena akcji stanowi w dużej mierze funkcję przychodów, obrotów firmy, stosunku zadłużenia do kapitału, etc. Ceny towarów są uwarunkowane między innymi kosztami produkcji ponoszonymi przez różnych dostawców. Na przykład, jeżeli cena ropy spadnie poniżej kosztów produkcji u niektórych producentów i stan ten utrzymywać się będzie przez długi czas to będą oni zmuszeni do zakończenia swojej działalności przyczyniając się zmniejszenia produkcji i jednocześnie wzrostu cen. Mamy tu do czynienia z negatywnym sprzężenie zwrotnym. W Bitcoinie nie mamy do czynienia z żadnymi wartościami fundamentalnymi, ani z negatywnym sprzężeniem zwrotnym. Cena bitcoinów na poziomie $500 jest bardziej uzasadniona niż $50,000, czy $5. Jeżeli cena bitcoina zmieni swoją wartość w stosunku do obecnej, to ruch ten jako taki nie wywoła żadnych reperkusji ekonomicznych, które przyczyniłyby się do przywrócenia wcześniejszego poziomu. Wszystko jest kwestią przypadku. W Byteball, podstawowa waluta - byte (bajty) jest wykorzystywana w celu realizacji opłat za umieszczenie danych w bazie Byteball. Koszt dodania 1 Kb danych wynosi 1 000 byte’ów. Jest to miara przydatności składowania danych w tej bazie; użytkownicy sami sobie wyrobią opinię na temat poziomu ceny, która uważać będą za rozsądną. Jeżeli cena byte’ów wzrośnie powyżej pułapu, który uznacie za rozsądny, znajdziecie sposoby na składowanie mniejszej ilości byte’ów i tym samym będziecie musieli zapłacić mniej za mniej byte’ów; jeżeli spanie popyt, cena także spada. Jest to negatywne sprzężenie, właściwe wszystkim towarom/usługom, na które popyt jest uzależniony od potrzeb, a nie spekulacje. Poza płatnościami w byte’ach, można także wysłać inne środki i wykorzystać je jako środki płatnicze. Mogą one reprezentować na przykład zadłużenie wyrażone w walutach fiducjarnych lub w jednostkach naturalnych (np. kWh lub baryłkach ropy). Cena takich aktywów jest w sposób naturalny powiązana z walutami lub towarami bazowymi.

Prywatność. Wszystkie transakcje bitcoinowe oraz salda we wszystkich adresach są widoczne w blockchainie. Chociaż istnieją sposoby zaciemnienia należącego do kogoś salda lub transakcji, nie jest to jednak coś, czego generalnie oczekuje się od waluty. Transakcje zawierane w byte’ach (waluta bazowa) w systemie Byteball są widoczne, ale istnieje także druga waluta (blackbyte’y), która jest znacznie trudniejsza do śledzenia.

Zgodność. Bitcoin został zaprojektowany jako anonimowy system walutowy, w którym użytkownicy (ludzie) zachowują całkowitą kontrolę nad swoimi pieniędzmi. Cel ten został osiągnięty; nie mniej jednak sprawia on, że Bitcoin nie jest zgodny z obowiązującymi przepisami i tym samym nie może być wykorzystywany przez sektor finansowy. W Byteball, można emitować środki w oparciu o dowolne zasady w zakresie ich transferowalności, bez żadnych ograniczeń, podobnie jak Bitcoin, aż po dowolne ograniczenia no. w postaci obowiązku podpisania każdego transferu przez wystawcę (np. bank) lub ograniczenia do skończonego zbioru użytkowników umieszczonych na białych listach.

2. Struktura bazy danych

Użytkownik podejmując decyzje od umieszczeniu danych w bazie tworzy nową jednostkę składowania i przekazuje informacje o tym innym użytkownikom posiadający równe prawa - peers. Jednostka składowania zawiera (między innymi):

Dane, które mają być składowane. Jednostka może zawierać więcej niż jeden pakiet danych, który jest nazywany wiadomością. Istnieje wiele różnych rodzajów wiadomości, a każda z nich ma swoją własną strukturę. Jeden z tych rodzajów do wiadomość zawierająca informacje o płatności, która jest wykorzystywana do wysyłania bajtów lub innych aktywów do współużytkowników.

Podpis(y) złożone przez jednego lub więcej użytkowników, którzy utworzyli jednostkę. Użytkownicy są identyfikowani za pośrednictwem swoich adresów. Każdy użytkownik może (a nawet jest zachęcany do posiadania) więcej niż jednego adresu, podobnie jak w Bitcoinie. W najprostszym przypadku, adres jest pozyskiwany z klucza publicznego – co znowu przypomina rozwiązanie przyjęte w Bitcoinie.

Odniesienia do jednej lub kilku wcześniejszych jednostek (rodziców), które są identyfikowane przez ich liczby haszujące.

Odniesienie do rodziców jest elementem porządkującym (póki co jedynie częściowo) jednostki i jednocześnie umożliwia generalizację struktury blockchaina. Ponieważ nie jesteśmy przywiązani do relacji one-parent–one-child (jedno dziecko, jeden rodzic) pomiędzy poszczególnymi blokami, nie musimy starać się o uzyskanie warunków zbliżonych do pełnej synchronizacji i możemy dość bezpiecznie tolerować znaczne opóźnienia i dużą ilość przepływających danych: będziemy mieć tylko więcej rodziców i dzieci w każdej jednostce. Śledząc dalej historię wzdłuż linków rodzice-dzieci (parent-child), zauważymy wiele rozwidleń, w sytuacji, w której ta sama jednostka posiada odsyłacze ze strony wielu późniejszych jednostek, które często łączą się, kiedy ta sama jednostka zawiera odnośniki do wielu wcześniejszych jednostek (programiści zdążyli się już przyzwyczaić do ich obecności w repozytorium git). Struktura ta jest znana w teorii grafów jako ukierunkowany graf acykliczny - directed acyclic graph (DAG). Jednostki są punktami a linki typu parent-child stanowią krawędzie grafu.

Rys. 1. Jednostki składowania połączone w układ DAG. Strzałki biegną od dziecka do rodzica; G oznacza jednostkę Genesis.

W szczególnych przypadkach, kiedy nowe jednostki pojawiają się bardzo rzadko, DAG będzie przypominać niemal zupełnie łańcuch z rozrzuconymi rozwidleniami i szybkimi połączeniami.

Podobnie jak w blockchainach, gdzie każdy nowy blok potwierdza wszystkie wcześniejsze (wraz z zapisanymi w nich transakcjami), każda nowa jednostka – dziecko w DAG akceptuje (potwierdza) swojego rodzica, wszystkich rodziców rodziców, rodziców rodziców rodziców, etc. Podejmując próbę edytowania jednostki, trzeba będzie także zmienić jej liczbę haszującą. Oczywiście spowoduje to rozerwanie wszystkich jednostek-dzieci, które zawierają odnośniki do niej w postaci liczby haszujące, ponieważ zarówno podpisy, jak i liczby haszujące ich dzieci są zależne od liczb haszujących rodziców. Dlatego trudno jest powtórzyć jednostkę bez współpracy ze wszystkimi jej dziećmi albo ukraść ich klucze prywatne. Dzieci z kolei nie mogą zmienić swoich jednostek bez współpracy ze swoimi dziećmi (wnukami jednostki oryginalne [źródłowej])), itd. Po upublicznieniu jednostki w sieci i uruchomieniu procesu budowy jednostek przez innych użytkowników w oparciu o tę jednostkę (z odnośnikiem do jednostki jako transakcji rodzicielskiej), liczba wtórnych zmian wymaganych do edycji danej jednostki rozrasta się niczym kula śniegowa. Dlatego właśnie nazywamy to rozwiązanie Byteball – kulą bajtową – nasze płatki to bajty danych).

W odróżnieniu od blockchainów, w których blok jest rzadko spotykanym wydarzeniem I tylko uprzywilejowana kasta użytkowników bierze praktyczny udział w tej czynności, w nowym systemie Byteball jednostki zaczynają gromadzić potwierdzenia natychmiast po ich wysłaniu; akceptacje te mogą pochodzić od dowolnego użytkownika i za każdym razem wysyłana jest nowa jednostka. Nie istnieje żaden system dualistyczny (two-tier) system użytkowników i górników. Zamiast tego, użytkownicy pomagają sobie wzajemnie: dodając nową jednostkę, jej autor weryfikuje także wszystkie wcześniejsze transakcje.

W odróżnieniu od Bitcoina, w którym próba wprowadzenia zmian do wcześniejszej transakcji wymaga dużego wysiłku obliczeniowego, próba modyfikacji historycznego rekordu w Byteball łączy się z koniecznością koordynacji (współpracy) z dużą i stale rosnącą liczbą innych użytkowników, z których większość jest anonimowa. Brak możliwości zmiany historycznych rekordów oparty jest zatem na złożoności procesu koordynacji z uwagi na dużą liczbę obcych (nieznajomych), z którymi trudno nawiązać kontakt i którzy nie są zainteresowani współpracą; jest to także rozwiązanie, w którym każdy z nieznajomych może zawetować zmiany.

Dzięki odnośnikom do rodziców, jednostka zawiera w sobie część rodzica. Nie jest to kompletny rodzic; nowa jednostka czerpie swoje informacje z liczby haszującej rodzica. W taki sam sposób, jest ona pośrednio uzależniona od i w związku z tym zawiera także informacje o rodzicu rodzica, ich rodzicach itd., aby w efekcie zawierać w sobie także cząstkę jednostki genesis.

Istnieje pewna Zasada protokołu, która mówi, że jednostka nie może zawierać odnośników do redundantnych rodziców – tzn. rodziców, z których jeden zawiera w sobie fragment drugiego. Na przykład, jeżeli jednostka B zawiera fragment jednostki A, to jednostka C nie może zawierać odnośników zarówno do A jak i do B jednocześnie. A jest w pewien sposób

jednocześnie częścią B. Zasada ta pozwala usunąć niepotrzebne linki, które nie wnoszą żadnych nowych, użytecznych informacji o połączeniach do grafu.

3. Waluta krajowa: bajtyNastępnie musimy wprowadzić pewne niedogodności w celu zabezpieczenia przed spamowaniem bazy danych bezużytecznymi wiadomościami. Zapora powinna w przybliżeniu odzwierciedlać jakość składowania dla użytkownika oraz koszty składowania dla sieci. Najprostszym środkiem w obu przypadkach jest odpowiedni rozmiar jednostki składowanej. W związku z tym, aby przechowywać dane w globalnej, zdecentralizowanej bazie danych trzeba dokonać opłaty w wewnętrznej walucie nazywanej byte’ami, a wpłacona kwota jest równa wielkości danych, które mają być składowane (w tym nagłówki, podpisy, etc.). Podobnie jak w przypadku funta sterlinga, który odpowiadał jednemu funtowi srebra, kiedy został wprowadzony po raz pierwszy, nazwa waluty odzwierciedla jej wartość.

Aby zachęty były zbieżne z interesami sieci, stosuje się jest pewien wyjątek od zasad obliczania rozmiaru. Aby obliczyć rozmiar (wielkość)n jednostki, zakłada się, że jednostka ta posiada dokładnie dwoje rodziców niezależnie od ich faktycznej liczby. W związku z tym, rozmiar dwóch liczb haszujących jednostek rodzicielskich zawsze stanowi część wielkości jednostki. Wyjątek ten uniemożliwia użytkownikom skuteczne podejmowanie prób umieszczenia tylko jednego rodzica w celu obniżenia kosztów. Koszt pozostaje taki sam niezależnie od tego ilu rodziców zostało ujawnionych.

Aby DAG był możliwie jak najwęższy, zapewniamy bodźce dla użytkowników, aby wprowadzali do system jak największą liczbę rodziców (co jak wspomnieliśmy nie ma ujemnego wpływu na rozmiar i związane z nim opłaty)), możliwie jak najmniej odległych czasowo, dokonując opłaty części opłaty jednostkowe na rzecz tych, którzy umieścili tę transakcję jako swojego rodzica. W dalszej części opracowania przedstawimy dokładna definicję słowa “pierwsi”.

Byte’y mogą wykorzystywane nie tylko w celu dokonania płatności opłat za składowanie (nazywanych także prowizjami), ale mogą być także wysyłane do pozostałych użytkowników w celu dokonania płatności za towary lub usługi lub w zamian za inne środki. Aby dokonać płatności (wysłać ją), użytkownik tworzy nową jednostkę, która zawiera wiadomość dotyczącą płatności taką jak przedstawiona poniżej (od tej pory, będzie używać skrótu JSON w odniesieniu do struktur danych):{

inputs: [{

unit: "hash of input unit",message_index: 2, // index of message where this utxowas createdoutput_index: 0 // index of output where this utxowas created

},…

],outputs: [

{address: "RECEIVER ADDRESS",amount: 15000 // in bytes

},…

]}

Wiadomość ta zawiera: Macierz danych wyjściowych: jeden lub więcej adresów, które otrzymują bajty oraz

odpowiadające im kwoty. Macierz danych wejściowych: jeden lub więcej odnośników do wcześniejszych

danych wyjściowych, które są wykorzystywane do sfinansowania transferu. Są to dane wyjściowe, które zostały wysłane na adres(y) autora w przeszłości, ale nie zostały jeszcze wydatkowane.

Suma danych wejściowych powinna być równa sumie danych wyjściowych plus prowizja (kwoty odpowiadające danym wejściowym są odczytywane z wcześniejszych danych wyjściowych i nie są w sposób wyraźny określone podczas wydatkowania). Jednostka jest podpisana kluczem prywatnym autora.

Łączna liczba bajtów w obrocie sięga 1015 i jest wartością stałą. Wszystkie bajty są wysłane w jednostce genesis, a następnie przekazywane od jednego użytkownika do drugiego. Opłaty są gromadzone przez użytkowników, którzy pomagają utrzymać odpowiedni stan sieci (więcej informacji na ten temat znajduje się w kolejnych rozdziałach), aby zachować je w obiegu. Liczba 1015 została wybrana jako największa całkowita liczba, która może być reprezentowana w JavaScript. Kwoty mogą być wyrażone wyłącznie jako liczby całkowite. Większe jednostki walutowe uzyskujemy dodając odpowiednie, standardowe przedrostki do jednostek podstawowych: 1 kilobajt (Kb) to1 000 bajtów, 1 megabajt (Mb) to 1 milion bajtów, etc.

4. Transakcje podwójnie wydatkowaneW sytuacji, gdy użytkownik podejmuje próbę wydania tych samych kwot – danych wyjściowych dwukrotnie, istnieją dwa potencjalne scenariusze1. istnieje częściowy ład (szyk) pomiędzy dwiema jednostkami, które podejmują próbę wydatkowania tych samych danych wyjściowych, tzn. jedna jednostka (bezpośrednio lub pośrednio) włącza drugą jednostkę i ustawia się za nią. W takim przypadku jest oczywiste, że tę późniejszą możemy bezpiecznie odrzucić.2. nie ma żadnego częściowego ładu między nimi i wtedy akceptujemy obie transakcje. Ustalamy łączny porządek między nimi nieco później, kiedy zostaną dość głęboko zakopane nowymi jednostkami (patrz: tekst poniżej zawierający instrukcje, jak tego dokonać). Ta jednostka, która pojawi się szybciej w ogólnym porządku jest uznawana za ważną, a druga jest odrzucana.

Jest jeszcze jedna reguła protokołu, która upraszcza definicję ładu/uszeregowania/porządku ogólnego. Wprowadzony został wymóg, nakazujący w przypadku wysyłania z tego samego adresu więcej niż jednej jednostki umieszczenie (pośrednio lub bezpośrednio) wszystkich wcześniejszych jednostek do każdej kolejnej jednostki, tzn. powinien być zachowany częściowych porządek pomiędzy kolejnymi jednostkami zapisanymi pod tym samym adresem. Innymi słowy, wszystkie jednostki tego samego autora powinny być seryjne.

W przypadku naruszenia tej zasady i upublicznienia dwóch jednostek, pomiędzy którymi nie występuje częściowe uporządkowanie (jednostki nieseryjne), obie jednostki są traktowane jako podwójnie wydatkowane nawet jeśli nie podejmują próby wydatkowania tych samych danych wyjściowych. Takie jednostki nieseryjne są opisane w przypadku 2 powyżej.

Rys. 2 Transakcje podwójnie wydatkowane. Brak częściowego ładu pomiędzy nimi.

Jeżeli użytkownik stosuje się do tej zasady, ale w dalszym ciągu jednak podejmuje próbę dwukrotnego wydatkowania tych samych kwot, podwójnie wykorzystane kwoty są porządkowane w sposób jednoznaczny i możemy bezpiecznie odrzucić tę, która jest ostatnia (druga) podobnie jak na przykładzie 1 powyżej. Podwójnie wydatkowane kwoty są jednocześnie nieseryjne i w związku z tym łatwe do wychwycenia i usunięcia.

Zasada ta jest dość naturalna. Kiedy użytkownik tworzy nową jednostkę, dokonuje wyboru pozostałych, najnowszych jednostek jako rodziców swoich. Umieszczając je na liście swoich rodziców, składa jednocześnie deklarację dotycząca swojej wizji świata, co oznacza, że widział te jednostki wcześniej. Jednocześnie miał okazję zapoznać się ze wszystkimi rodzicami rodziców, rodzicami rodziców rodziców, etc., aż do jednostki genesis. Ten ogromny zbiór powinien także zawierać wszystko, co on sam wyprodukował i w konsekwencji zobaczył.

Nie włączając danej jednostki (nawet pośrednio przez rodziców), użytkownik zaprzecza, izby je kiedykolwiek widział. Jeżeli robi to nie podając informacji o swoich wcześniejszych jednostkach, użytkownik oświadcza, że nigdy ich nie widział, a my dochodzimy do wniosku, że coś tu jest nie tak jak należy. System nie zachęca do takich zachowań.

5. Łańcuch główny

Nasz graf DAG ma szczególny charakter. W normalnym trybie użytkowania, nowe jednostki są przeważnie łączone z nieco starszymi powodując, że DAG rozrasta się tylko w jednym kierunku. Można to sobie wyobrazić jako grubą linę skręconą z licznych sznurków. Właściwość ta sugeruje, że moglibyśmy wybrać pojedynczy łańcuch wzdłuż połączeń dziecko-rodzic w ramach DAG, a następnie powiązać wszystkie jednostki z tym łańcuchem. Wszystkie jednostki zostaną umieszczone w tym łańcuchu albo bezpośrednio i wtedy będziemy mieć do czynienia z łańcuchem głównym, albo będą z niego dostępne dla niewielkiej liczby przeskoków na krawędziach grafu. Przypomina to trochę autostradę z plątaniną połączonych z nią dróg podrzędnych.

Jednym ze sposobów zbudowania głównego łańcucha jest opracowanie algorytmu, który mając do dyspozycji wszystkich rodziców zapisanych w danej jednostce, dokona wybory jednego z nich, jako “najlepszego rodzica”. Algorytm wyboru powinien być oparty wyłącznie na wiedzy dostępnej danej jednostce, tzn. na danych w niej zawartych oraz wszystkich jej przodkach. Zaczynając od tipu (jednostki nieposiadającej dzieci) w DAG, zaczynamy się cofać się w historii wzdłuż najlepszych linków do rodziców. Dokonując takiego przemieszczenia, zaczynamy budować łańcuch główny i w efekcie docieramy do jednostki genesis. Należy zauważyć, że budowa łańcucha głównego zaczynająca się od specyficznej jednostki nigdy nie zmieni się w miarę dodawania coraz to nowych jednostek. Dzieje się tak dlatego, że na każdym kroku przemieszczamy się od dziecka do rodzica, a istniejąca jednostka nie może pozyskać nowych rodziców.

Zaczynając od kolejnego tipu przystępujemy do budowy kolejnego łańcucha głównego. To właśnie w tym miejscu dwa główne łańcuchy krzyżują się ze sobą odbywając podróż w przeszłość, a następnie – po przecięciu - podążają tą samą ścieżką. W najgorszym przypadku, łańcuchy główne skrzyżują się dopiero w punkcie genesis. Zważywszy, że proces generowania jednostki nie jest skoordynowany pomiędzy użytkownikami, można jednak oczekiwać, że pojawi się możliwość znalezienia klasy łańcuchów głównych, które zbiegną się w niezbyt dużej odległości od tipów.

Rys. 3. Łańcuchy główne zbudowane w oparciu o różnorodne jednostki nieposiadające dzieci przecinają się ze sobą, a następnie podążają ta samą ścieżką. W przypadku dwóch transakcji dwukrotnie wydatkowanych, ta z niższym indeksem łańcucha głównego (5) wygrywa, podczas gdy druga (o wartości MCI=6) zostaje uznana za nieważną.

Po zbudowaniu łańcucha głównego (MC (main chain)), możemy stworzyć ogólny porządek (uszeregowanie) pomiędzy dwoma skonfliktowanymi (sprzecznymi) jednostkami nieseryjnymi. Określmy najpierw indeks jednostek, które znajdują bezpośrednio na łańcuchu głównym. Jednostka genesis posiada indeks 0; kolejna jednostka MC, która jest dzieckiem genesis posiada indeks równy 1, i tak przesuwając się po kolei wzdłuż łańcucha głównego przypisujemy indeksy jednostkom stanowiącym część MC. W przypadku jednostek, które nie zostały w nim umieszczone, istniej możliwość ustalenia indeksu MC w sytuacji, gdy dana jednostka umieszczana jest po raz pierwszy (bezpośrednio lub pośrednio). W ten właśnie sposób każdej jednostce można przypisać indeks MC (MCI).

Następnie z dwóch nieseryjnych transakcji, za ważną i wcześniejszą uznana zostaje ta, która ma niższy indeks MCI podczas gdy druga jest unieważniona. W sytuacji, gdy obie transakcje nieseryjne będą mieć tę samą wartość MCI, stosuje się zasadę tiebreaker (przełamania remisu), która mówi, że jednostka o niższej wartości haszującej (dostępna w systemie kodowania łańcucha base64) jest ważna. Należy podkreślić, że zachowujemy wszystkie wersje transakcji podwójnego wydatkowania – także te, które ostatecznie przegrają. DagCoin [3] to pierwsza opublikowana praca, która zasugerowała przechowywanie wszystkich skonfliktowanych transakcji oraz podjęcie decyzji, którą z nich uznać za ważną.

Łańcuch MC zbudowany w oparciu o specyficzne jednostki mówi nam, co autor tej jednostki myśli na temat kolejności wydarzeń mających miejsce w przeszłości, tzn. przedstawia jego punkt widzenia odnośnie do zdarzeń historycznych. Uszeregowanie wydarzeń następnie implikuje te jednostki nieseryjne, które należy uznać za ważne, zgodnie z opisem powyżej. Należy podkreślić, że dokonując wyboru najlepszego spośród wszystkich rodziców danej jednostki, dokonujemy jednocześnie wyboru spośród wszystkich MC: łańcuch główny danej jednostki będzie zatem łańcuchem głównym jej najlepszego rodzica rozszerzonym o jeden link.

Uznając, że wiele (a nawet wszystkie) jednostki rodzicielskie mogą być utworzone przez atakującego oraz pamiętając, że wybór najlepszego rodzica jest wyborem jednej z wersji historii, powinniśmy żądać, aby algorytm wyboru najlepszego rodzica jednocześnie faworyzował (wybierał) historie, które są “realne/prawdziwe” z punktu widzenia jednostki - dziecka. Dlatego konieczne jest stworzenie “testu prawdziwości” (reality test), który nasz algorytm uruchomi w celu sprawdzenia wszystkich potencjalnych MC, aby wybrać jeden – ten, który uzyska najlepszy wynik.

6. Świadkowie (witnesses)W poszukiwaniu “testu prawdziwości” warto zauważyć, że niektórzy uczestnicy naszej sieci nie są anonimowi, są to osoby lub firmy od długiego czasu cieszące się uznaniem lub firmy zainteresowane utrzymaniem dobrego stanu sieci. Jednostki te nazywamy witnesses - świadkami. Chociaż zasadne jest oczekiwanie uczciwego zachowania z ich strony, całkowite zaufaniu jednemu świadkowi nie jest działanie rozsądnym. Jeżeli znane nam są adresy Byteball kilku świadków, z których przewidujemy, że będą wysyłane dość często

wiadomości, to aby zmierzyć prawdziwość kandydującego MC można cofnąć się w czasie wzdłuż danego MC i zliczyć jednostki autoryzowane przez danego świadka (jeżeli ten sam świadek wystąpi więcej niż jeden raz, nie zostanie więcej uwzględniony). Naszą podróż kończymy, gdy tylko napotkamy większość świadków. Następnie dokonamy pomiaru długości grafu od punktu, w którym dotarliśmy do genesis. Odcinek ten nazywamy poziomem jednostki w punkcie zatrzymania oraz poziomem świadka rodzica, którego MC testujemy. Kandydujący MC, który pozwala uzyskać wyższy poziom świadka jest uznawany za bardziej “realny”, a rodzić, który zawiera ten łańcuch główny jest wybierany jako najlepszy rodzic. W sytuacji, gdy mamy do czynienia z kilkoma pretendentami o maksymalnym poziomie świadka, wybierzemy rodzica, którego poziom własny jest najniższy. Jeżeli remis w dalszym ciągu się utrzymuje, dokonamy wyboru rodzica o najmniejszej wartości liczby haszującej jednostki (w przypadku kodowania łańcucha base64).

Algorytm ten umożliwia dokonanie wybory MC, który będzie ciążyć w kierunku jednostek, których autorami są świadkowie uznani za dających świadectwo prawdzie. Jeżeli na przykład atakujący opuszcza (buduje rozwidlenie) uczciwą część sieci i sekretnie buduje długi łańcuch swoich własnych jednostek (shadow chain), z których jedna zawiera podwójnie wydatkowaną transakcję, a następnie łączy rozwidlenie z uczciwym DAG, to algorytm wyboru najlepszego rodzica w punkcie połączenia dokona wyboru tego rodzica, który doprowadza łańcuch główny do uczciwego DAG, gdyż jest to miejsce, w którym świadkowie są aktywni. Świadkowie nie zdołali umieścić transakcji w łańcuchu cieni (shadow chain) po prostu dlatego, że nie widzieli go przed zlaniem. Taki wybór łańcucha głównego (MC) odzwierciedla porządek wydarzeń w taki sposób, w jaki widzą go świadkowie oraz użytkownicy, którzy ich wybrali. Po zakończeniu ataku, cały łańcuch cieni zbiegnie się w MC w jednym punkcie, a transakcje podwójne umieszczone w shadow chain będą uznane za nieważne, ponieważ ich prawdziwe – ważne odpowiedniki pojawią się wcześniej, przed punktem połączenia.

Rys. 4. Kiedy atakujący przyłącza swój DAG cieni (shadow DAG) do grafu świetlonego (lit DAG), jego jednostki przegrywają walkę o tytuł najlepszego rodzica, ponieważ algorytm wybiera tę ścieżkę, która ma więcej świadków (oznaczoną literką w).Przykład ten ilustruje, dlaczego większość świadków musi być świadkami zaufanymi, aby wysyłać wiadomości wyłącznie w trybie seryjnym. Większość z nich nie powinna być w zmowie z atakującym i umieszczać postów w jego łańcuchu cieni. Należy podkreślić, że nasze zaufanie wobec świadków dotyczy prawdziwości oraz nieumieszczania żadnych nieseryjnych jednostek w którymkolwiek z łańcuchów cieni. Nie przekazujemy im żadnej kontroli nad siecią lub jej elementami. Nawet w przypadku tego niewielkiego obowiązku, to użytkownicy wyznaczają świadków oraz mogą zmieniać swoje decyzje w czasie.

Pomysł postrzegania znanej jednostki jako prawdziwej nie jest nowy. Jest on od lat znany, a niektóre firmy nawet prowadzą działalność polegającą na tym, że aby potwierdzić, że niektóre dane istniały zanim powstały inne, można ohaszować dane i upublicznić tę wartość w mediach niepodlegających modyfikacji, np. gazetach w tradycyjnej postaci (papierowej) [6]. Świadkowie w Byteballu spełniają tę samą rolę co gazeta. Podobnie jak ona są powszechnie znani i cieszą się zaufaniem. W przypadku gazet, zaufanie jest ograniczone do powierzania publikacji danych; w Byteball świadkowie mogą publikować jedynie posty seryjne i nic więcej. Podobnie jak w przypadku gazet, świadkowie nie wiedzą co kryje się za haszami, które poświadczają i istnieje niewiele powodów, dla których mieliby to wiedzieć. Drukowane wersje gazet trudno zmodyfikować (chociaż jest to potencjalnie możliwe – przynajmniej w 1984 było), podczas gdy wszystko co opracują świadkowie jest chronione podpisami cyfrowymi, które uniemożliwiają jakiekolwiek zmiany. Jeżeli chodzi o wiarygodność to mamy kilku świadków, a nie tylko jednego, a jeżeli chodzi o prędkości wygodę to są oni dostępni online.

Podjąwszy decyzję odnośnie do listy świadków, możemy następnie wybrać najlepszego rodzica oraz odpowiednie historie, które są najbardziej dopasowane do definicji rzeczywistości: “miejsce, w którym mieszkają świadkowie”. Jednocześnie, sami rodzice mogą dysponować innymi listami świadków i w konsekwencji zupełnie innymi definicjami rzeczywistości. Chcemy, aby definicje rzeczywistości oraz historie z nimi związane zbiegały się w pewnym wspólnym punkcie.

“Zasada bliskiej zgodności” (near-conformity rule): najlepsi rodzice muszą być wybrani wyłącznie z spośród tych, których listy świadków różnią się od list świadków dzieci o nie więcej niż jedna mutację. Zasada ta sprawia, że listy świadków sąsiadujących ze sobą jednostek w łańcuchu głównym (MC) są dostatecznie zbliżone i dlatego ich historie w większości w większości zgadzają się ze sobą. Rodzice, których listy różnią się o 0 lub 1 mutację będą nazywane kompatybilnymi (w tym jednostka, w której są one bezpośrednio zawarte), podczas gdy pozostałe są niekompatybilne. Niekompatybilni rodzice są w dalszym ciągu dopuszczani, ale pozbawieni szansy na to, aby zostać najlepszym rodzicem. W sytuacji, gdy nie ma potencjalnych, kompatybilnych rodziców wśród jednostek nieposiadających dzieci (atakujący może zalać sieć swoimi jednostkami, które będą zawierać całkowicie odmienne listy świadków), należy wybrać rodziców ze starszych jednostek.

Powyższy wywód oznacza, że każda jednostka musi zawierać listy swoich świadków i umożliwiać ich porównanie. Wymagamy, aby liczba świadków wynosiła zawsze dokładnie 12. Liczba ta została wybrana z następujących względów:

Jest dostatecznie duża, aby chronić przed jednostkowymi błędami popełnionymi przez kilku świadków (mogą oni kazać się nieuczciwi, ulec atakowi hackerskiemu, utracić dostęp do sieci na dłuższy okres czasu lub zgubić swoje klucze prywatne i całkowicie stracić dostęp do sieci);

Jest dostatecznie mała, aby użytkownicy byli w stanie śledzić wszystkich świadków i wiedzieć jednocześnie który jest którym oraz w razie potrzeby zmieniać listę;

Jedyna dopuszczalna mutacja jest jednocześnie dostatecznie mała w porównaniu z 11 niezmienionymi świadkami.

W sytuacji, gdy użytkownik uzna, że świadkowie utracili swoją wiarygodność lub że znajdują się lepsi kandydaci, może on zastąpić ich nowymi na swojej liście pamiętając, że lista jego świadków nie może różnić się od tej właściwej dla pozostałych jednostek o więcej niż jedną pozycję. Oznacza to, że wszelkie zmiany mogą się dokonywać stopniowo i wymagany jest ogólny konsensus w celu wprowadzenia zmian wykraczających poza jedną pozycję.

7. Ostateczny charakter / niezmiennośćW miarę napływu coraz to nowych jednostek, każdy użytkownik śledzi swój własny bieżący łańcuch główny, który jest tak zbudowany, jak gdyby miał wystawić nową jednostkę w oparciu o obecnie bezdzietne jednostki. Bieżący łańcuch główny może różnić się w zależności od węzłów, ponieważ mogą one widzieć całkowicie odmienne jednostki nieposiadające dzieci. Wymagamy, aby bieżący MC był konstruowany niezależnie od listy świadków, tzn. własna lista świadków użytkownika nie powinna mieć znaczenia i dopuszcza się możliwość wyboru rodziców niekompatybilnych jako najlepszych rodziców. Oznacza to, że jeżeli dwoje użytkowników posiada ten sam zestaw bezdzietnych jednostek, ale odmienne listy świadków, ich bieżące łańcuchy MC będą w dalszym ciągu tożsame. Aktualny łańcuch MC będzie ulegać stałym zmianom w miarę napływu nowych jednostek, nie mniej jednak - jak za chwilę wykażemy - część obecnego łańcucha MC, która ma dość długa historie pozostanie niezmieniona.

Oczekujemy, że świadkowie będą zachowywać się (a raczej znakomita ich większość) w sposób uczciwy i dlatego obowiązkowo umieszczamy ich poprzednie jednostki w kolejnej, której autorem jest ten sam świadek. Oznacza to, że kiedy świadek skomponuje nową jednostkę, tylko najnowsze w łańcuchu będą odpowiednimi kandydatami na rodziców. W związku z tym można oczekiwać, że wszystkie przyszłe aktualne łańcuchy MC zbiegną się punkcie, który nie będzie bardziej odległy (podczas podróży w czasie), niż dany punkt stabilności (stability point). W istocie, jednostka genesis jest naturalnym, wyjściowym punktem stabilności. Załóżmy, że zbudowaliśmy aktualny łańcuch MC wykorzystując bieżący zbiór jednostek bezdzietnych oraz że mamy pewien punkt w tym łańcuchu, który został wcześniej uznany za stabilny, tzn. wszystkie budowane w przyszłości aktualne łańcuchy MC będą uznane za zbiegające się w lub przed tym punktem (jak poprzednio

podczas podróży w czasie), a następnie przemieszczające się wzdłuż tej samej ścieżki. Jeżeli nie znajdziemy sposób na przesunięcie tego punktu do przodu (oddalenia od genesis), to jesteśmy w stanie dowieść, w drodze indukcji, że punkt stabilności istnieje.

Warto zauważyć, że jeżeli pominiemy wszystkich rodziców za wyjątkiem najlepszego, nasz graf DAG zostanie zredukowany do drzewka składającego się jedynie z linków najlepszych rodziców. Jest oczywiste, że wszystkie łańcuchy MC podążać będą trasami wyznaczonymi przez gałęzie tego drzewa. Następnie przystępujemy do rozważenia następujących dwóch przypadków – jednego, w którym drzewo buduje gałąź w aktualnym punkcie stabilności i drugiego, w którym tego nie robi – podejmując decyzję o tym, czy możemy przenieść punkt stabilności do kolejnego indeksu MCI.

Rys. 5. Drzewko składające się z linków najlepszych rodziców. Wszystkie za wyjątkiem jednej gałęzi przestają rozrastać się po osiągnięciu pewnego punktu.

Najpierw należy założyć, że drzewo nie tworzy gałęzi. Następnie, trzeba uwzględnić możliwość, że nowe gałęzie będą jednak dodawane iw jakimś stopniu wspierane przez świadków w taki sposób, że przerosną one istniejące gałęzie. Inna możliwość zakłada, że świadkowie włożą tyle wysiłku wspierając istniejącą gałąź, że wymóg umieszczenia poprzedniej jednostki nie pozostawi im żadnej możliwości wyboru poza kontynuacją wspierania istniejącej gałęzi. Rozważmy teraz te druga opcję. Pamiętajmy, że najlepszy rodzic jest wybierany jako ten, który posiada najwyższy poświadczony (przez świadków) poziom. Udajmy się teraz w podróż w czasie wzdłuż aktualnego łańcucha MC, aż do momentu, w którym napotkamy większość świadków (odnosimy się teraz do świadków zdefiniowanych przez jednostkę znajdujących się w aktualnym punkcie stabilności). Jeżeli co najmniej jeden z nich położony jest wcześniej w stosunku do aktualnego punktu stabilności, nie podejmujemy próby przesunięcia go; w pozostałych przypadkach tak. W tej sytuacji, wszyscy świadkowie są już “zainwestowani” w aktualny łańcuch MC. Pośród tych świadków, musimy zatem znaleźć minimalny poświadczony poziom minowo. Kiedy dowolny świadek publikuje nową jednostkę, jednostka ta może mieć rodziców, których łańcuch MC doprowadzi nas do bieżącego łańcucha MC oraz rodziców, których MC doprowadzi na do konkurencyjnej gałęzi, a rodzice z najwyższym poświadczonym poziomem zostaną wybrani jako najlepsi i zdefiniują kierunek kolejnego aktualnego łańcucha MC. Ponieważ świadek musi podać poprzednią jednostkę, poziom poświadczony prowadzący do bieżącego łańcucha MC będzie wynosić co najmniej min_wl. Poświadczony poziom dowolnego rodzica

prowadzący do alternatywnej gałęzi nigdy nie przekroczy poziomu bieżącego punktu stabilności, nawet w sytuacji, gdy pozostali świadkowie (mniejszość) będą gromadzić się w alternatywnej gałęzi. Dlatego, jeżeli bieżący łańcuch MC rozrośnie się na tyle daleko, że min_wl będzie większy niż poziom aktualnego punktu stabilności, większość świadków będzie musiała zwiększyć swoje wsparcie dla istniejących aktualnych łańcuchów MC, a gałąź alternatywna utraci swoje szanse na wygraną; wtedy będziemy mogli dokonać przesunięcia punktu stabilności do przodu ku kolejnemu indeksowi MCI.

Następnie załóżmy, że drzew tworzy gałąź. Musimy teraz znaleźć warunek, w którym alternatywne gałęzie stracą możliwość rozbudowania bieżącego łańcucha MC. Zacznijmy od zdefiniowana min_wl podobnie jak poprzednio. Spośród wszystkich jednostek znajdujących się na gałęziach alternatywnych, dokonujemy wybory tych, które zwiększają poziom poświadczony, tzn. ich własny poziom poświadczony będzie większy od poziomu każdego rodzica. Wśród nich znajdujemy poziom maksymalny. Następnie, nawet jeżeli wszyscy pozostali (mniejszość) świadkowie zgromadzą się na alternatywnych gałęziach, poziom poświadczony na alternatywnych gałęziach nigdy nie przekroczy tego maksymalnego poziomu. W związku z tym, poziom maksymalny będzie niższy niż min_wl, a gra jest skończona dla gałęzi alternatywnych i możemy przenieść punkt stabilizacji wzdłuż aktualnego łańcucha MC.

Dlatego też w bieżącym łańcuchu MC istnieje punkt, przed którym MC nigdy nie ulegnie zmianie (zakładając, że większość świadków nie umieści w nim nieseryjnych jednostek). Ogólny porządek zdefiniowany w odniesieniu do tego łańcucha MC ma w związku z tym charakter ostateczny. Jeżeli będziemy mieć do czynienia z tworami nieseryjnymi, to nasza decyzja odnośnie do ich ważności ma także ostateczny charakter. Jeżeli kiedykolwiek pojawi się nowy element nieseryjny będący w konflikcie z elementami już umieszczonymi w stabilnym łańcuchu MC, to nowa jednostka nieseryjna zostanie z sposób ostateczny uporządkowana po tym, jak stary odpowiednik oraz nowy zostaną uznane za nieważne. Dlatego, każda płatność dokonana w jednostce będącej częścią stabilnego łańcucha MC ma charakter nieodwracalny. W przeciwieństwie do Bitcoina, gdzie ostateczny charakter transakcji jest jedynie probabilistyczny, w tym przypadku ostateczny charakter transakcji jest ustalany w sposób deterministyczny.

Każdy użytkownik buduje swój własny (subiektywny) bieżący łańcuch MC oparty na jednostkach, które widzi. Ponieważ powielanie nowych jednostek nie jest zjawiskiem krótkotrwałym i jednostki mogą pojawiać się w różnym uszeregowaniu u różnych użytkowników, użytkownicy mają do dyspozycji różne aktualne łańcuchy MC oraz różne opinie na temat ostatniego punktu stabilizacji łańcucha MC w danym czasie. Ponieważ jednak aktualny łańcuch MC jest zdefiniowany wyłącznie jako zbiór jednostek znanych użytkownikowi, w sytuacji, gdy użytkownik B nie dokonał jeszcze przesunięcia swojego punktu stabilizacji do tego samego punktu jak w przypadku użytkownika A, niewątpliwie dokona tego później – tzn., gdy tylko otrzyma te same jednostki jak użytkownik A lub więcej. W związku z tym opinie różnych użytkowników na temat stanu dowolnej jednostki staną się w ostatecznym efekcie spójne.

8. Przechowywanie jednostek nieseryjnychStwierdzając, że dana jednostka nie jest seryjna, mamy w dalszym ciągu obowiązek zachowania jej. Nie mniej jednak część dany zostanie zastąpioną wartością haszującą dane. Zasada ta ma na zapewnić osiągnięcie dwóch celów. Po pierwsze, zmniejszyć ilość przechowywanych danych skonsumowanych przez jednostkę, za które nikt nie zapłacił (cała zawartość jednostki nieseryjnej jest uznana za nieważną w tym także zapłacone prowizje). Po drugie, aby zredukować użyteczność nieseryjnych transakcji dla użytkownika, który je wysłał, ponieważ wartość haszująca zastępuje wszystkie wartościowe dane, które autor chciał zachować (nieodpłatnie). To rozwiązanie pozwala atakującym uniknąć niewłaściwego wykorzystywania transakcji nieseryjnych jako sposobu na przechowywanie dużych ilości danych bez ponoszenia kosztów.

Wartość haszująca jest przechowywana zamiast pełnej zawartości, ale w dalszym ciągu może być użyteczna dla atakującego, gdyż może on zachować oryginalne dane dla siebie oraz wykorzystywać tę wartość celu wykazania, że dane te rzeczywiście istniały. Należy jednak pamiętać, że:1. W dalszym ciągu musi dokonać opłaty za jedna jednostkę, która jest uznana za ważną2. Jeżeli agresor już posada wewnętrznie zapisane metadane niezbędne do poprawnego zinterpretowania danych Byteball, może tego dokonać także łącząc wszystkie swoje dane w postaci drzewka Merklego i wykorzystując Byteball wyłącznie w celu zapisania (przechowywania) tylko swojego korzenia Merklego za cenę jednej niedużej jednostki.

W tym paradygmacie nie występują zatem żadne ukryte interesy własne w podejmowaniu próby wysyłania tych transakcji nieseryjnych.

Należy wspomnieć, że nie możemy odrzucić transakcji nieseryjnych, kiedy widzimy je po raz pierwszy. Gdybyśmy tak zrobili, atakujący może przesłać je do pozostałych użytkowników w zupełnie innym porządku. Różni użytkownicy będą wtedy mieli możliwość trzymania się wersji, które otrzymali jako pierwsze, a następnie odrzucenia wszystkie co opierać się będzie na zupełnie innej wersji przyczyniając się do skutecznego podziału sieci przez atakującego. Dlatego właśnie musimy przechowywać obie wersję, a następnie podjąć decyzję w sprawie ich uporządkowania. Co więcej, użytkownicy powinni przesłać transakcje nieseryjne do pozostałych równoprawnych użytkowników (peers) wraz z pozostałymi jednostkami, ponieważ im szybciej dowiedzą się o istnieniu transakcji nieseryjnych, tym lepiej.

W dalszym ciągu jednak, w miarę możliwości unikamy umieszczania transakcji nieseryjnych: algorytm wyboru rodzica wyklucza stosowanie transakcji nieseryjnych tak długo jako pozostają „bezdzietne”. Z tego właśnie powodu konieczne jest możliwie jak najszybsze przekazywanie informacji o nich pozostałym uczestnikom.

9. Balls - KuleKiedy jednostka ustabilizuje się (tzn. zostanie umieszczona w stabilnej części łańcucha MC), zaczynamy tworzyć nową strukturę w oparciu o tę jednostkę, którą nazywamy ball (kulą):

ball: {unit: "hash of unit",parent_balls: [array of hashes of balls based on parent units],is_nonserial: true, // this field included only if the unit isnonserialskiplist_balls: [array of earlier balls used to build skiplist]

}

Każda kula zawiera informacje na temat kul swoich przodków (za pośrednictwem rodziców), stąd ilość informacji, od których jest uzależniona do rozrasta się niczym kula śnieżna. Kula posiada także flagę, która mówi nam, czy została ona unieważniona (uznana za nieseryjną), oraz odnośniki do starszych kul, które wykorzystamy później, aby zbudować proofs (dowody) dla lekkich klientów.

Kule możemy zbudować wyłącznie, kiedy odpowiednia jednostka ustabilizuje się oraz kiedy będziemy wiedzieć na pewno, czy jest ona seryjna. Ponieważ aktualne łańcuchy MC widzialne dla różnych użytkowników stają się ostatecznie spójne, przyczynia się także do zbudowania takiej samej kuli w oparciu o tę samą jednostkę.

10. Last ball – Ostatnia kulaAby zabezpieczyć kule (w szczególności zaś flagę nieseryjności) przed modyfikacjami, konieczne jest, aby każda nowa jednostka zaopatrzona była w wartość haszującą właściwą dla ostatniej znanej autorowi kuli (która jest kulą zbudowana w oparciu o ostatnią stabilną jednostkę i która znajduje się w łańcuchu MC). W ten sposób, ostatnia kula będzie chroniona przez podpis autora. Następnie, nowa jednostka zostanie włączona (pośrednio lub bezpośrednie) przez świadków.

Jeżeli użytkownik nieposiadający całej bazy danych Byteball będzie zainteresowany poznaniem ustalenie, czy dana jednostka jest seryjna, przekaże nam listę świadków, którym ufa i uważa za uczciwych, a my zbudujemy łańcuch najnowszych jednostek, które będą zawierać większość z wymienionych świadków, a następnie odczyta treść ostatniej kuli z najstarszej jednostki danego łańcucha i wykorzysta kule, aby zbudować drzewko wartości haszujących, w którym ostatnia kula będzie znajdować się na jego szczycie, a wymagane jednostki będą umieszczone poniżej. Drzewko to będzie zbliżone swoją strukturą do wysokiego drzewka Merklego, przy czym dodatkowe dane będą wprowadzane w poszczególnych węzłach. Drzewko można zoptymalizować za pomocą skiplist (listy z przeskokami).

Odniesienie do ostatniej kuli również pozawala użytkownikom przekonać się, co pozostali użytkownicy myślą na temat punktu stabilizacji łańcucha MC oraz porównują te informacje ze swoją własną wizją.

Wymagamy także, aby ostatnie kula nie poprzedzała ostatniej kuli każdego rodzica. Wymóg ten zapewnia, że ostatnia kula, albo przemieszcza się do przodu wzdłuż łańcucha MC, albo pozostaje w tym samym miejscu, nigdy jednak nie cofając się.

Aby jeszcze bardziej zredukować stopień swobody adwersarzy, wprowadzamy jeszcze jeden wymów: lista świadków jednostki musi być kompatybilna z listą każdej jednostki znajdującej się na elementach powiązanych z łańcuchem jednostki pomiędzy samą jednostką a jednostka ostatniej kuli. Wymóg ten zapewnia, że wszelkie modyfikacje listy świadków najpierw osiągną punkt stabilizacji zanim podejmą próbę wprowadzenia kolejnej zmiany. W przeciwnym razie, atakujący może wprowadzić do układu łańcucha MC znacznie zmodyfikowaną listę świadków i wstrzymać przekazywanie wiadomości z adresów nowych świadków. W takich przypadkach, punkt stabilności nie będzie w stanie wyjść poza obszar zajmowany przez świadków atakującego.

Wymóg, aby listy świadków wszystkich współczesnych jednostek były do siebie zbliżone oznacza, że wszyscy użytkownicy mają mniej więcej te same poglądy na temat tego, komu można zaufać i obdarzyć rolą „latarni morskiej” wskazującej drogę użytkownikom w danym czasie. Rozwiązanie to jest zbliżone do rozwiązań obserwowanych w naturze, gdzie organizmy tych samych gatunków muszą mieć w większości te same geny. Nieduże odchylenia w listach świadków umożliwiają zmiany ewolucyjne, które pozwalają jednak utrzymać spójność całego układu.

11. Jednostka listy świadkówOczekuje się, że wielu użytkowników będzie chciało korzystać z dokładnie tych samych list. W takim przypadku, aby oszczędzić miejsca, nie wymieniają one adresów wszystkich 12 świadków. Zamiast tego zawierają odnośnik do innych, wcześniejszych jednostek, które posiadają na swoich listach tych świadków. Jednostka listy świadków musi być stabilna z punktu widzenia jednostki referencyjnej, tzn. musi być umieszczona w ostatniej jednostki kuli.

12. Struktura jednostkiPoniżej przedstawiona jest przykładowa jednostka:{

version: '1.0',alt: '1',messages: [ {

app: 'payment',payload_location: 'inline',payload_hash:'AegecfpDzh8xvdyIABdynrcP6CTd4Pt42gvRiv0Ftjg=',payload: {

inputs: [{unit:'7yctnKyuAk5P+mFgFQDdDLza88nkceXYjsTs4e3doQA=',message_index: 0,

output_index: 1} ],outputs: [

{ address: 'DJ6LV5GPCLMGRW7ZB55IVGJRPDJPOQU6',amount: 208 },{ address: 'Z36JFFX2AH7X5JQ2V2C6AQUUOWFESKZ2',amount: 3505 }

]}

} ],authors: [ {

address: 'DJ6LV5GPCLMGRW7ZB55IVGJRPDJPOQU6',authentifiers: {

r:'3eQPIFiPVLRwBwEzxUR5thqn+zlFfLXUrzAmgemAqOk35UvDpa4h79Fd6TbPbGfb8VMiJzqdNGHCKyAjl786mw=='

}} ],parent_units: [

'B63mnJ4yNNAE+6J+L6AhQ3EY7EO1Lj7QmAM9PS8X0pg=','D6O1/D9L8vCMhv+8f70JecF93UoLKDp3e2+b92Yh2mI=','ZxqzWP6q6hDNF50Wax8HUK212lH/KSIRdW5a6T9h3DM='

],last_ball: '8S2ya9lULt5abF1Z4lIJ4x5zYY9MtEALCl+jPDLsnsw=',last_ball_unit: 'bhdxFqVUut6V3N2D6Tyt+/YD6X0W+QnC95dMcJJWdtw=',witness_list_unit:'f252ZI2MN3xu8wFJ+LktVDGsay2Udzi/AUauE9ZaifY='

}

W tym przypadku: Wersja to numer wersji protokołu. Jednostka zostanie zinterpretowana według

wersji protokołu; alt jest identyfikatorem waluty alternatywnej, która będzie nieco bardziej

szczegółowo omówiona w dalszej części opracowania; wiadomości to macierz jednej lub więcej wiadomości zawierająca rzeczywiste dane;

o app oznacza typa wiadomości, np. “płatność” w przypadku płatności, „tekst” w przypadku dowolnych wiadomości, etc.;

o payload_location mówi nam o tym, gdzie znaleźć payload wiadomości. Informacje te mogą znajdować się w ‘liniach’, jeżeli payload stanowi część wiadomości, w ‘uri’ jeżeli payload jest dostępny pod wskazanym adresem internetowym, jako ‘none’ (brak), jeżeli payload nie został w ogóle opublikowany, informacja ta jest zapisywana i/lub przekazywania w sposób poufny a payload_hashserves ma na celu wykazanie, że istniała ona w określonym czasie;

o payload_hash jest liczbą haszującą payload w kodowaniu base64;o payload stanowi także rzeczywisty payload (ponieważ umieszczony jest

wewnątrz ‘linii’ w tym przykładzie). Struktura payload jest specyficzna dla aplikacji (app-specific). Płatności są opisane w sposób następujący:

dane wejściowe to macierz coinów wejściowych konsumowanych przez opłatę. Wszyscy właściciele coinów wejściowych muszą znajdować się wśród osób podpisujących (autorów) jednostek; jednostka jest to wartość haszująca jednostki, w której powstał coin.

Aby stał się jednostką płatniczą, jednostka musi być umieszczona w ostatniej jednostce kuli - last_ball_unit;

message_index jest to indeks macierzy wiadomości jednostki wyjściowej. Wskazuje on wiadomość, w której coin został wyprodukowany;

output_index jest to indeks macierzy wyjściowych wiadomości kolejnej message_index jednostki wejściowej. Wskazuje on wiadomość, w której coin został wyprodukowany;

dane wyjściowe to macierz danych wyjściowych, które zawierają informacje o tym, kto jest uprawniony do odbioru pieniędzy;

adres jest adresem Byteball odbiorcy; kwota jest kwotą należna odbiorcy;

autorzy to macierz autorów, którzy utworzyli I podpisali tę jednostkę. Wszystkie coiny wejściowe muszą należeć to autorów;

o adres jest adresem autora adresu Byteball;o elementy uwierzytelniające (authentifiers) jest to struktura danych, która

potwierdza autentyczność autora. Najczęściej, są to podpisy ECDSA; parent_units jest to macierz liczb haszujących jednostek macierzystych. Musi być

sortowana alfabetycznie; last_ball oraz last_ball_unit są to liczby haszujące ostatniej kuli oraz jej jednostki

odpowiednio; witness_list_unit jest to liczba haszująca jednostki, w której można znaleźć listę

świadków.

Wszystkie liczby haszujące są kodowane w systemie base64.

Należy podkreślić, że nie ma pola znacznika czasowego w strukturze jednostki. W Byteball, nie ma zasad protokołów, które oparte byłyby na czasie zegarowym – po prostu nie ma takiej potrzeby – zasada szeregu zdarzeń jest wystarczająca.

Znacznik czasowy jest dalej umieszczany w jednostkach, które są przesyłane z jednego węzła do drugiego. Jest to jednak funkcja doradcza i wykorzystywana przez lekkich klientów, aby w ramach portfela wykazać przybliżony czas wygenerowania jednostki, który może znacznie różnić się od godziny odbioru, ponieważ klienci light mogą być niedostępni przez długie okresy czasu.

13. ProwizjeJak wspomnieliśmy, koszty przechowywania jednostki zależne są od jej wielkości wyrażonej jako bajty. Prowizja jest podzielona na dwie części: prowizja za nagłówki oraz prowizja

związana payload. Prowizja za payload jest równa rozmiarowi wiadomości; prowizja za nagłówki związana jest z rozmiarem pozostałych danych. Obydwa rodzaje prowizji są dystrybuowane odmiennie.

Prowizja za nagłówki przechodzi do jednej z przyszłych (nowych) jednostek, która przyjmuje płatnika jednostki jako rodzica. Odbiorca jest wybierany wyłącznie po tym, jak zarówno indeks MCI jednostki jak i kolejny indeks MCI ustabilizują się. Aby ustalić odbiorcę, wybieramy te dzieci, których indeks MCI jest równy lub większy o 1 niż indeks MCI płacącego. Liczby haszujące każdego z dzieci są łączone z wartością haszującą jednostki znajdującej się w kolejnym indeksie MCI (związanej z płacącym), a dziecko o najmniejszej wartości haszującej (w systemie szesnastkowym) wygrywa prowizję. Takie haszowanie z wykorzystaniem kolejnej jednostki MC ma na celu wprowadzenie elementu nieprzewidywalności (następna jednostka MC nie jest znana wcześniej) i uzyskanie sytuacji, w której wszelkie próby poprawy szans na uzyskanie prowizji poprzez manipulowanie liczbami haszującymi własnych jednostek okaże się całkowicie nieużyteczne. jednocześnie, ograniczenie kandydatów to tych, których indeksy MCI są nie więcej niż o 1 większe niż indeks MCI płacącego, stanowi zachętę do wyboru najnowszych jednostek jako rodziców. Utrzymywanie DAG w możliwie jak najwęższym kształcie jest bardzo dobrym rozwiązaniem.

Dokonujemy jedynie płatności za nagłówek, a nie całą prowizję osobom, które szybko wybiorą nas na swoich rodziców z następujących przyczyn. Gdybyśmy zapłacili całą prowizję, to stanowiłoby to zachętę do zachowań nieuczciwych: podział danych na kilka fragmentów oraz zbudowanie długiego łańcucha własnych jednostek, z których każda przechowywałaby jeden fragment w jednostce. Wszystkie prowizję zapłacone w poprzedniej jednostce byłyby następnie natychmiast zrealizowane przez tego samego użytkownika w kolejnej jednostce. Ponieważ płacimy tylko prowizję za nagłówki, zachowanie takie nie przynosi zysków, ponieważ, aby wyprodukować pojedynczy, dodatkowy element łańcucha trzeba wydać dodatkową prowizję za nagłówek – w przybliżeniu równy zarobkowi. Pozostałą prowizję (payload) wykorzystujemy, aby zachęcić innych, których działalność jest ważna dla utrzymania dobrej kondycji całej sieci.

Prowizja za payload przekazywana jest świadkom. Aby zachęcić świadków do odpowiednio częstego wysyłania wiadomości, dzielimy prowizję payload równo pomiędzy wszystkimi świadkami, którzy dość szybko umieszczą informację w 100 indeksach MC po jednostce płacącej (im szybciej taką informację umieszczą, tym szybciej jednostka się ustabilizuje). Jeżeli wszyscy 12 świadkowie umieszczą informacje w tym przedziale czasowym, każdy z nich otrzyma 1/12 prowizji payloadowej. Jeżeli tylko jeden świadek zdoła to zrobić to otrzyma całą prowizję za payload. W szczególnym przypadku, w którym żaden świadek nie opublikuje informacji w tym przedziale czasowym, wszyscy otrzymają 1/12 prowizji payloadowej. Jeżeli po podziale uzyskujemy liczbę ułamkową, to jest ona zaokrąglana zgodnie z zasadami matematycznymi. Z uwagi na to zaokrąglenie łączna prowizja wypłacona świadkowi może nie być równa łącznej prowizji z jednostki autora(ów), a zatem łączna suma ulegnie drobnej zmianie. Naturalnie, dystrybucja zachodzi tylko wtedy, gdy MCI+100 ustabilizuje się, gdzie indeks MCI jest indeksem MCI jednostki dokonującej płatności.

Aby wydatkować zarobione prowizje nagłówkowe lub prowizje dla świadków, wykorzystuje się następujące dane:

inputs: [{

type: "headers_commission",from_main_chain_index: 123,to_main_chain_index: 196

},{

type: "witnessing",from_main_chain_index: 60,to_main_chain_index: 142

},…

]

Takie dane wejściowe wymiatają wszystkie prowizje nagłówkowe lub za poświadczanie zarobione przez autora z jednostek wypłacających prowizję, które zostały wysłane pomiędzy głównymi łańcuchami indeksów from_main_chain_index oraz to_main_chain_index. Naturalnie, to_main_chain_index musi być ustabilizowany.

Kiedy jednostka jest podpisana przez więcej niż jednego autora, któremu należna jest prowizja nagłówkowa, do tej pory nie ma jasności w jaki sposób podzielić prowizje pomiędzy autorów. Aby wyeliminować te dwuznaczność, każda jednostka podpisywana przez więcej niż jednego autora musi zawierać strukturę danych, która definiuje proporcjonalny udział w dochodach:

unit: {…earned_headers_commission_recipients: [

{address: "ADDRESS1", earned_headers_commission_share: 30},{address: "ADDRESS2", earned_headers_commission_share: 70}

],…

}

Adresy, które otrzymają prowizje nie muszą być tożsame z adresami autora – prowizja może być wysłana na dowolny adres. Nawet jeżeli jednostka jest podpisana przez pojedynczegoautora, może zawierać to pole, aby przekierowywać prowizje nagłówkowe w inne miejsce.

14. Czas potwierdzaniaCzas potwierdzania jest to czas, który upływa od momentu wejścia jednostki do bazy danych uzyskania stabilizacji. Jest on uzależniony od częstotliwości umieszczania wiadomości, ponieważ, aby osiągnąć stabilność musimy zgromadzić dostatecznie dużo poświadczonych – autorskich jednostek w łańcuchu MC po wprowadzeniu nowej jednostki. Aby zminimalizować czas potwierdzania, świadkowie powinni publikować wiadomość dość

często (do czego są już zachęcani dzięki zasadom podziału prowizji), ale nie za często. Jeżeli dwóje lub więcej świadków wysyła swoje jednostki niemal jednocześnie (szybciej niż to z reguły się dzieje w przypadku wysyłania nowej jednostki do pozostałych świadków), może to przyczynić się do powstania zbędnych rozgałęzień w drzewku, co opóźni stabilizację. Z tego też powodu, najlepszy czas potwierdzania można osiągnąć, kiedy świadkowie są ze sobą dobrze skomunikowani i posiadają szybkie urządzenia umożliwiające natychmiastową walidację nowych jednostek. Szacujemy, że najlepszy czas potwierdzenie oscyluje wokół 30 sekund; można go osiągnąć, jeżeli przepływ nowych jednostek jest na tyle duży, aby świadkowie mogli uzyskać większe dochody z prowizji dla świadków, niż wydatkują na wysyłanie swoich własnych jednostek.

Pomimo, że czas niezbędny na pełne potwierdzenie jest dość długi, węzeł, który ufa swoim równorzędnym użytkownikom na tyle aby przyjmować nowe jednostki bez stosowania filtrów, może mieć także uzasadnioną pewność, że kiedy jednostka zostanie umieszczona przez co najmniej jednego świadka w połączeniu z upływem standardowego opóźnienia (czas konieczny, aby nowa jednostka dotarła od jednego użytkownika do drugiego - peer to peer), jednostka bardzo prawdopodobnie osiągnie ostateczny charakter i zostanie uznana za ważną. Nawet jeżeli później pojawi się transakcja podwójnego wydatkowani, będzie bardzo prawdopodobne, że zostanie umieszczona (uszeregowana) po tej jednostce.

15. Ryzyko podziałuSieć węzłów Byteball nie może nigdy być podzielona na dwie części, które mogłyby działać bez odnotowania tego faktu. Nawet w przypadku globalnej awarii sieci takiej jak np. przecięcie kabla biegnącego po dnie Atlantyku przez szczura łączącego Europę i Amerykę, co najmniej jedna strona podziału zauważy, że straciła połowę swoich świadków, co oznacza, że może ona przesunąć punkt stabilizacji i nikt nie będzie mógł wykorzystywać danych wyjściowych znajdujących się w nieustabilizowanej części łańcucha MC. Nawet jeżeli ktoś podejmie próbę podwójnego wydatkowania, to pozostanie ona niestabilna (a tym samym nieuznana) do chwili przywrócenia połączenia. Druga strona podziału, w której znajduje się większość świadków, będzie kontynuować normalne funkcjonowanie.

16. CenzuraSystem Byteball jest tak zaprojektowany, aby nie było w nim możliwości modyfikowania lub kasowania rekordów historycznych. Trudno jest w nim także uniemożliwić wprowadzenie pewnych typów danych do bazy danych.

Po pierwsze, dane jako takie mogą zostać ukryte i tylko ich wartość haszująca może być wprowadzona do bazy, w celu wykazania, że dane faktycznie istniały. Dane mogą być ujawnione po zapisaniu wartości haszującej i włączeniu jej jednostki do innych jednostek w taki sposób, że stanie się ona nieodwracalna.

Po drugie, nawet, jeżeli dane będą otwarte, decyzja w sprawie wprowadzenia lub niewprowadzenia jej do bazy danych jest przeniesiona na licznych anonimowych użytkowników, którzy mogą (i są zachęcani. aby) przyjąć nową jednostkę jako rodzica. Osoba, która podejmuje próbę ocenzurowania niepożądanych jednostek będzie musiała nie tylko unikać ich bezpośredniego włączania (jako rodziców), ale także pośredniego przez inne jednostki. (Jest to rozwiązanie odmienne niż w Bitcoinie, w którym górnicy lub pole górnicze mogą i wykorzystują tę możliwość, aby filtrować poszczególne transakcje bezpośrednio. Poza tym, użytkownicy Bitcoina nie decydują o tym, kto zostaje górnikiem.) Podobnie jak liczba jednostek, które zawierają “obraźliwe” jednostki kul śnieżnych, wszelkie próby uniknięcia jej mogą wiązać się z samo cenzurą. Tylko większość świadków może skuteczne narzucać zasady dotyczące treści zakazanych – jeżeli użytkownicy dokonają wyboru takich świadków.

17. Wybór świadkówŚwiadkowie to ten element Byteballa, który osadza go w rzeczywistości i jednocześnie sprawia, że staje się on uzależniony od decyzji podejmowanej przez człowieka. Zdrowie system jest zależne od odpowiedzialnego tworzenia list zaufanych świadków przez użytkowników. Proces ten nie może być bezpiecznie zautomatyzowany; na przykład, jeżeli większość użytkowników zacznie auto-aktualizację swoich list świadków, aby dostosować je to list ostatnio zaobserwowanych jednostek, tylko po to, aby zapewnić im zgodność, czynność ta może być z łatwością wykorzystana przez atakującego, który zaleje sieć swoimi własnymi jednostkami, które będą stopniowo zmieniać dominującą listę świadków na listę, wybraną (określoną) przez atakującego.

Chociaż maksymalistyczna rekomendacja może brzmieć: “Zawsze edytuj listy świadków ręcznie”, co jest zbyt obciążające dla większości użytkowników, bardziej praktyczne podejście do zarządzania listami świadków zakłada śledzenie oraz pewnego rodzaju uśrednianie list świadków należących do kilku “kapitanów sektora (captains of industry)”, którzy albo są zainteresowani sprawowaniem opieki nad dobra kondycją sieci, albo którzy zdobyli wcześniej dobrą reputację w związku z działaniami niekoniecznie związanymi z Byteballem. Niektórzy z nich mogą występować w charakterze świadków. W przeciwieństwie do list świadków, listy kapitanów sektora nie muszą być kompatybilne, a brak aktualizacji listy wcale nie ma żadnych natychmiastowych negatywnych skutków w postaci np. uniemożliwienia znalezienia kompatybilnych rodziców i wysyłania nowych jednostek. Oczekujemy, że większość użytkowników będzie stosować jeden ze względnie niedużej liczy najbardziej popularnych portfeli, które będą ustawianie domyślnie w taki sposób, aby wykorzystywać listę świadków dostawcy portfela, który z kolei najprawdopodobniej obserwuje listy innych, prominentnych graczy.

Świadkowie także mają swoje listy świadków; zaleca się aby użytkownicy wybierali tych świadków, których listy uważają za odzwierciedlające przekonanie zwykłych użytkowników. Jest to niezwykle istotne, ponieważ żadna zmiana głównych list świadków nie może dokonać się bez zgody większości aktualnych świadków. Zaleca się, aby świadkowie i potencjalni świadkowie złożyli publiczną deklarację (oświadczenie) dotyczącą

ich własnej polityki w zakresie list świadków (np. o stosowaniu i uśrednianiu list świadków innych renomowanych użytkowników), oraz, aby użytkownicy dokonali oceny ich przydatności w oparciu o założenia tej polityki, jako jedno z kryteriów. Wszelkie naruszenia zadeklarowanej polityki będą natychmiast zauważone i najprawdopodobniej przyczynią się do uruchomienia kampanii na rzecz zmiany świadka. Takie samo podejście stosuje się w przypadku nieuzasadnionej zmiany do polityki. Polityka jest dla świadka wiążąca i sprawia, że musi się liczyć z opinią publiczną, nawet, jeśli zwraca się ona przeciwko świadkowi lub jego przyjaciołom.

Jak już wspomnieliśmy wcześnie, zasady naszego protokołu wymagają, aby:1. najlepszy rodzic został wybrany wyłącznie spośród rodziców, których listy świadków mają nie więcej niż 1 mutację;2. nie powinna istnieć więcej niż 1 mutacja związana z listą świadków ostatnie jednostki kuli;3. nie powinna istnieć więcej niż 1 mutacja związana z listą świadków wszystkich nieustabilizowanych jednostek łańcucha MC, aż do ostatniej jednostki kuli;4. punkt stabilizacji jest przenoszony wyłącznie wtedy, gdy aktualni świadkowie (zdefiniowani w bieżącym punkcie stabilizacji) opublikują dostatecznie dużo jednostek za bieżącym punktem stabilizacji.

Zasady te są projektowane, aby chronić system przed złośliwymi lub przypadkowymi rozwidleniami. Jednocześnie, implikują, że wszelkie zmiany głównych list świadków muszą by tworzone stopniowo, a każdy krok zatwierdzony przez większość aktualnych świadków. Jedno pozycyjna zmiana musi najpierw osiągnąć stabilizację i uznanie większości starych świadków zanim będzie można wprowadzić kolejną zmianę. Jeżeli społeczność podejmie nieprzemyślaną (szybką) decyzję o natychmiastowej wymianie dwóch świadków, to po tym jak zmiana dotrze do łańcucha MC, druga zmiana zostanie zablokowana przez zasadę 3 (powyżej) aż do chwili osiągnięcia stabilizacji przez pierwszą zmianę.

Pomimo wszystkich powyższych rekomendacji w dalszym ciągu istnieje możliwość, że wskutek zaniedbania liderów sektora, zostaną wybrani tacy świadkowie, którzy później utworzą kartel i dokonają kolektywnej blokady wszelkich prób wymiany, któregokolwiek z nich kierując się chęcią utrzymania dochodów z prowizji za pełnienie funkcji świadka. Jeżeli takie zachowania wystąpią, staną się oczywiste dla wszystkich, ponieważ ich listy świadków pozostaną niezmienione, podczas, gdy listy świadków większości liderów będą różnić się o jedną mutacje (jest to maksymalna, dopuszczalną wartość, aby zachować kompatybilność). Jeżeli starzy świadkowie nie poddają się pomimo tak oczywistych nacisków jedynym środkiem, dostępnym użytkownikom opowiadającym się za zmianą jest wszczęcie “rewolucji” – tzn. uruchomienie nowego coina, który odziedziczy wszystkie salda, adresy użytkowników, etc. ze starego coina w pewnym punkcie, ale uruchomi nową listę świadków i wprowadzi specjalna zasadę protokołu, która będzie w stanie rozwiązać tę niekompatybilną zmianę w momencie podziału (schizmy). Aby odróżnić się od starego coina, trzeba będzie następnie przypisać nową wartość do pola ‘alt’ (do tego właśnie służy ‘alt’) oraz wykorzystać go we wszystkich jednostkach wystawionych w ramach nowego coina. W efekcie, użytkownicy będą mieć dwa coiny (stary alt=”1” oraz nowy, np. alt=”2”) i

będą w stanie wydawać obywa zupełnie niezależnie. Jeżeli podział (split) był uzasadniony, stary coin zostanie najprawdopodobniej opuszczony, ale wszystkie dane zakumulowane do chwili wystąpienia schizmy będą dostępne jako normalne dane w nowym coinie. Ponieważ protokół jest niemal identyczny (za wyjątkiem zasady, rozwiązującej kwestię podziału oraz zmienionego alta), aktualizacja oprogramowania będzie łatwa do przeprowadzenia na wszystkich urządzenia kupieckich lub użytkowników.

Jeżeli ktoś chce po prostu uruchomić nowego coina, aby przeprowadzić eksperyment z innym zbiorem reguł protokołu, to może on wykorzystać pole ‘alt’, aby odziedziczyć wszystko, co należy do starego coina, sprawiając, że zmiana będzie komfortowa dla użytkowników i stworzyć duży zbiór użytkowników z saldach z dnia pierwszego.

18. Lista z przeskokami (skiplist)Niektóre z kulek zawierają macierz list z przeskokami, która umożliwia szybsze budowanie proofs dla lekkich klientów (patrz: omówienie poniżej). Jedynie te kule, które leżą bezpośrednio na łańcuchu MC i których indeks jest podzielny przez 10 posiadają listę z przeskokami. Skiplisty zwierają dane najbliższych, wcześniejszych kul łańcucha MC, których indeks ma taką samą lub mniejsza liczbę zer na końcu. Na przykład, kula w MCI 190 posiada skiplistę, która zawiera odnośnik do kuli znajdującej się w MCI 180. Kula w MCI 3000 ma listę z przeskokami, która zawiera odnośniki do kul w MCIs 2990, 2900 oraz 2000.

19. Klienci lightKlienci light nie przechowują całej bazy danych Byteball. Zamiast tego, pobierają podzbiór interesujących ich danych, np. tylko transakcje, w których adresy użytkowników są wydawane lub fundowane. Klienci light łączą się z pełnymi węzłami, aby pobrać interesujące ich jednostki. Klient light przekazuje pełnemu węzłowi listę świadków, którym ufa (niekoniecznie tożsamą ze świadkami, których wykorzystuje w celu utworzenia nowych jednostek) wraz z listą swoich własnych adresów.

Pełny węzeł wyszukuje jednostki, którymi jest zainteresowany klient light i konstruuje łańcuch proof dla każdej jednostki w następujący sposób:1. Cofnij się w czasie wzdłuż łańcucha MC, aż do momentu spotkania większości wymaganych świadków. Zbierz wszystkie te jednostki łańcucha MC.2. Z ostatniej jednostki w tym zbiorze (który jest jednocześnie najwcześniejszym, jeżeli idzie o czas), odczytaj ostatnią kulę.3. Zaczynając od tej ostatniej kuli, cofnij się w czasie wzdłuż łańcucha MC, aż do momentu, w którym dowolna kula zawierającą listę z przeskokami zostanie napotkana. Zbierz wszystkie takie kule.4. Wykorzystując skiplistę, przeskocz do wcześniejszej kuli odnośnik do której znajdował się na liście. Kula ta także posiada swoją skiplistę, wykonaj kolejny przeskok. Jeżeli w macierzy skiplist znajduje się kilka kul, zawsze przeskakuj o największą, możliwą odległość, aby przyśpieszyć przeskok najpierw o 10 indeksów, następnie o 100, 1000, etc.

5. Jeżeli kolejny skok wykonany w oparciu o dane z listy wyrzuci nas poza docelową kulę, można zwolnić i wykonywać krótsze skoki. W końcu, można zostawić skiplistę i przejść wzdłuż jednego indeksu łańcucha MC za każdym razem wykorzystując odnośniki do rodziców.

Łańcuch ten posiada jednostki świadków-autorskie na początku, co sprawia, że jest on godny zaufania z punktu widzenia klientów light. Wszystkie elementy łańcucha są połączone za pomocą albo linków jednostek rodzicielskich (powstałych podczas gromadzenia świadków), albo za pośrednictwem odnośnika ostatniej kuli, lub odnośnika kuli rodzica lub skiplisty. Na końcu łańcucha znajduje się jednostka, której istnienia należało dowieść.

20. Podpisy wielostronne (Multilateral signing)Jednostka może być podpisana przez wiele różnych stron. W takich sytuacjach, macierz autorska w danej jednostce posiada jeden lub więcej elementów.Rozwiązanie to może być przydatne np. kiedy dwie lub więcej stron chcą podpisać kontrakt (zwykły, stary, kontrakt typu dumb, a nie kontrakt typu smart). Obie strony będą podpisywać tę samą jednostkę, która zawiera wiadomość tekstową (app=’text’). Użytkownicy nie muszą zachowywać pełnej treści kontraktu w publicznej bazie danych i dokonywać opłat za to – wystarczy wprowadzenie wartości haszującej (payload_location=’none’), a same strony mogą przechowywać ten tekst w swoich prywatnych zasobach. Inne zastosowanie podpisów wielostronnych (multilateral signing) to wymiana zasobów. Załóżmy, że użytkownik A chce wysłać pewną wartość X do użytkownika B w zamian za Y (lokalna waluta w postaci ‘bajtów’ również stanowi pewną wartość – wartość bazową). Następnie, użytkownicy przystępują do komponowania jednostki, która będzie zawierać dwie wiadomość dotyczące opłat: jedna z nich wyśle aktywa oznaczone jako X z A do B, druga wyśle środki Y z B do A. Obie odpisują jednostkę posiadającą dwóch autorów I publikują ją. Wymiana ma charakter atomowy, tzn. Albo obie transakcje zostaną zrealizowane jednocześnie, albo żadna z nich nie zostanie zrealizowana. Jeżeli jedna z płatności okaże się transakcją podwójnie wydatkowaną, cała jednostka zostanie uznana za nieważną, a płatność nie zostanie zrealizowana.Ta prosta konstrukcja umożliwia użytkownikom bezpośrednią wymianę aktywów, bez powierzania środków zcentralizowanym pośrednikom.

21. AdresyUżytkownicy są identyfikowani za pośrednictwem adresów; dane wyjściowe transakcji są wysyłane na odpowiednie adresy i podobnie jak w systemie Bitcoin, zaleca się, aby użytkownicy posiadali więcej niż jeden adres i unikali ich wielokrotnego użycia. W niektórych przypadkach jednak takie wielokrotne użycia jest zjawiskiem normalnym. Na przykład, oczekuje się, że świadkowie będą w sposób powtarzalny wysyłać wiadomości z tego samego adresu. Adres odzwierciedla definicję, która stanowi wyrażenie logiczne (dość odległe od podobnego skryptu bitcoinowego). Kiedy użytkownik składa podpis pod

jednostką, dostarcza on również zestawów elementów weryfikacyjnych (z reguły są to podpisy ECDSA), które po podstawieniu do wzoru definicji muszą dokonać oceny jako prawdziwe, aby udowodnić, że dany użytkownik był uprawniony do złożenia podpisu pod tą jednostką. Definicje są kodowane w JSON. Dla przykładu: poniżej przedstawiamy definicję adres, który wymaga podpisu ECDSA, aby podpis był ważny:

["sig",{"pubkey":"Ald9tkgiUZQQ1djpZgv2ez7xf1ZvYAsTLhudhvn0931w"}]

Definicja wskazuje, że właściciel adresu posiada klucz prywatny, którego publiczny odpowiednik jest zawarty w treści definicji (przy wykorzystaniu kodowania base64 ) oraz że użytkownik podpisze wszystkie jednostki za pomocą tego właśnie klucza prywatnego. Powyższa definicja uznaje za prawdziwe dane, jeżeli podpis zawarty w odpowiednim elemencie weryfikującym jest ważny; w przeciwnym razie dane zostaną oznaczone jako fałszywe. Podpis jest obliczany w odniesieniu do wszystkich danych zawartych w jednostce za wyjątkiem elementów weryfikujących.

Mając do dyspozycji obiekty definicji, odpowiedni adres jest tylko wartością haszującą pierwotnego obiektu definicji plus suma kontrolna. Suma kontrolna jest dodawana w celu uniknięcia błędów w pisowni. W przeciwieństwie do standardowej konstrukcji sumy kontrolnej, bity tej sumy kontrolnej nie są po prostu dodawane na końcu danych nieopatrzonych tą sumą. Zamiast tego, są one umieszczane w wielu miejscach wewnątrz danych. Takie rozwiązanie utrudnia wprowadzenie długich strumieni nielegalnych danych do pól, w których ma być umieszczony adres. Adres jest konstruowany za pomocą kodu base32. Powyższa definicja odpowiada adresowi:A2WWHN7755YZVMXCBLMFWRSLKSZJN3FU.

Kiedy adres jest finansowany, wysyłający płatność zna i określa jedynie adres (wartość haszującą wraz z sumą kontrolną definicji) w danych wyjściowych płatności.Definicja nie jest ujawniania i pozostaje nieznana dla wszystkich poza właścicielem do momentu wydatkowania środków.

Kiedy użytkownik wyśle swoją pierwszą jednostkę z danego adresu jest zobowiązany do ujawnienia definicji (w celu umożliwienia weryfikacji podpisu) w macierzy autorskiej:

unit: {…authors: [ {

address: 'DJ6LV5GPCLMGRW7ZB55IVGJRPDJPOQU6',definition: [

"sig",{"pubkey":"AsnvZ3w7N1lZGJ+P+bDZU0DgOwJcGJ51bjsWpEqfqBg6"}

],authentifiers: {

r:'3eQPIFiPVLRwBwEzxUR5thqn+zlFfLXUrzAmgemAqOk35UvDpa4h79Fd6TbPbGfb8VMiJzqdNGHCKyAjl786mw=='

}} ],

…}

Jeżeli użytkownik wyślę kolejną jednostkę z tego samego adresu, musi pominąć definicję (jest ona już znana systemowi Byteball). Może on wysłać drugą jednostkę dopiero po ustabilizowaniu się definicji, tzn. Jednostka, w której definicja została ujawniona musi zostać umieszczona w ostatniej jednostce kuli drugiej jednostki.

Użytkownicy mogą aktualizować swoje adresy zachowując jednocześnie stary adres. Dla przykładu: aby obrócić klucz prywatny połączony z danym adresem, użytkownik musi wysłać jednostkę, która zawiera wiadomość w postaci:unit: {

…messages: [

…{

app: "address_definition_change",definition_chash: "I4Z7KFNIYTPHPJ5CA5OFC273JQFSZPOX"

},…

],…

}

W tym miejscu, definition_chash wskazuje liczbę haszującą wraz z sumą kontrolną nowej definicji adresu (która nie jest ujawniania, aż do kolejnych etapów), a sama jednostka musi być podpisana przez stary klucz prywatnych. Następna jednostka z tego adresu musi:tę jednostkę address_definition_change w ostatniej jednostce kuli, tzn. musi być już ustabilizowana;ujawniać nową definicję w macierz autorskiej w taki sam sposób jak w przypadku pierwszej wiadomości wysłanej z danego adresu.

Po dokonaniu zmiany, adres już nie odpowiada wartości haszującej wraz z sumą kontrolną aktualnej definicji. Zamiast tego, odpowiada on wartości haszującej wraz z sumą kontrolną swojej pierwotnej definicji.

Zmiana definicji jest użyteczna, w sytuacji gdy użytkownik zechce zmienić klucz(e)(np. Podczas migracji do nowego urządzenia) zachowując stary adres, tzn. jeżeli adres ten już uczestniczy w innych “długowiecznych” definicjach (patrz: tekst poniżej).

21.1. Składnia definicji21.1.1. Operatory logiczne

Definicja może zawierać warunki typu “i”, na przykład:["and", [

["sig", {pubkey: "one pubkey in base64"}],["sig", {pubkey: "another pubkey in base64"}]

]]

co jest bardzo przydatnym rozwiązaniem podczas podpisywania transakcji, podpisy pochodzące z dwóch niezależnych urządzeń są wymagane na przykład z laptopa i smartfona.

Warunki typu “lub” takie, jak:["or", [

["sig", {pubkey: "laptop pubkey"}],["sig", {pubkey: "smartphone pubkey"}],["sig", {pubkey: "tablet pubkey"}]

]]są użyteczne, kiedy użytkownik chce wykorzystać ten sam adres, ale korzystając z wielu różnych urządzeń.

Warunki można zagnieździć:["and", [

["or", [["sig", {pubkey: "laptop pubkey"}],["sig", {pubkey: "tablet pubkey"}]

]],["sig", {pubkey: "smartphone pubkey"}]

]]

Definicja może wymagać minimalnej liczby warunków, które mają być prawdziwe spośród większego zbioru, np. 2-z-3 podpisów:

["r of set", {required: 2,set: [

["sig", {pubkey: "laptop pubkey"}],["sig", {pubkey: "smartphone pubkey"}],["sig", {pubkey: "tablet pubkey"}]

]}]

(“r” oznacza “wymagane”) co oznacza, zarówno zabezpieczenia dwóch obowiązkowych podpisów jak i wiarygodność, że w przypadku zagubienia kluczy, adres będzie w dalszym ciągu możliwy do wykorzystania i może być także wykorzystany w celu zmiany definicji i zastąpienia zagubionego trzeciego klucza nowym.

Ponadto, różne warunki mogą otrzymać różne wagi dla których minimalne wymagania są następujące:

["weighted and", {required: 50,set: [

{weight: 40, value: ["sig", {pubkey: "CEO pubkey"}] },{weight: 20, value: ["sig", {pubkey: "COO pubkey"}] },{weight: 20, value: ["sig", {pubkey: "CFO pubkey"}] },{weight: 20, value: ["sig", {pubkey: "CTO pubkey"}] }

]}]

21.1.2. Delegowanie na inne adresy

Adres może zawierać odnośniki do innych adresów:

["and", [["address", "ADDRESS 1 IN BASE32"],["address", "ADDRESS 2 IN BASE32"]

]]

delegując podpis do innego adresu, który jest przydatny podczas budowania wspólnych adresów kontrolnych (adresy kontrolowane przez kilku użytkowników). Opisana składnia zapewnia użytkownikom elastyczność w zakresie zmiany definicji ich własnych komponentów adresowych, kiedy tylko uznają to za konieczne bez angażowania użytkownika.

21.1.3. Podpisy i elementy uwierzytelniające (weryfikacji)

W większości przypadków, definicja będzie zawierać co najmniej jeden podpis (bezpośrednio lub pośrednio):

["sig", {pubkey: "pubkey in base64"}]

Zamiast podpisu, definicja może wymagać utworzenia i przekazania wstępnego obrazu:

["hash",{"hash":"value of sha256 hash in base64"}]

Co może być pożyteczne w przypadku algorytmów wymiany pomiędzy łańcuchami (cross-chain exchange algorithms) [7]. W takim przypadku, hash preimage jest wprowadzany jako jeden a elementów weryfikacji.

Domyślny algorytm podpisu to ECDSA na krzywej secp256k1 (takiej samej jak Bitcoin). Początkowo, jest to jedyny wspierany algorytm. Jeżeli w przyszłości zostaną dodane inne algorytmy, identyfikator algorytmu zostanie wykorzystany w odpowiedniej części definicji takie jak algorytm NTRU odporny na obliczenia kwantowe:

["sig", {algo: "ntru", pubkey: "NTRU public key in base64"}]

Definicje multisig umożliwiają bezpieczne eksperymentowanie z niepotwierdzonymi (unproven) schematami podpisów, kiedy są one łączone z bardziej konwencjonalnymi podpisami.

Obiekt elementów weryfikujących w nagłówkach jednostki zawiera podpisy lub inne dane (np. preimage haszujący) wprowadzone przez ścieżkę subdefinicji wymagającej elementów weryfikacji w definicji adresu. W przypadku adresu z pojedynczym podpisem takiego jak

["sig", {pubkey: "pubkey in base64"}]

Ścieżka wynosi po prostu “r” (r oznacza root, czyli korzeń). Jeżeli subdefinicja wymagające podania elementu weryfikacji jest częścią innej definicji (np. i/lub), ścieżka jest rozszerzania przez indeks na macierz, w której subdefifnicja jest zawarta, a komponenty ścieżki zostaną określone przez kropki (dot). na przykład, w przypadku definicji adresu:["and", [

["sig", {pubkey: "one pubkey in base64"}],["sig", {pubkey: "another pubkey in base64"}]

]]

Ścieżki są określone odpowiednio jako “r.0” oraz “r.1”. W przypadku głębiej zagnieżdżonej definicji:

["and", [["or", [

["sig", {pubkey: "laptop pubkey"}],["sig", {pubkey: "tablet pubkey"}]

]],["sig", {pubkey: "smartphone pubkey"}]

]]Ścieżki są określone jako “r.0.0”, “r.0.1”, oraz “r.1”. W przypadku podpisów opcjonalnych takich jak 2-z-3, ścieżki mówią nam, które klucze zostały faktycznie wykorzystane.

21.1.4. Szablon definicji

Definicja może także zawierać odnośnik do szablonu definicji:

["definition template", ["hash of unit where the template was defined",{param1: "value1", param2: "value2"}

]]

Parametry określają wartości zmiennych, które mają być zastąpione innymi w szablonie. Szablon musi być zapisany wcześniej (i jak zwykle musi ustabilizować się zanim zostanie wykorzystany) jako specjalny typ wiadomości: app=’definition_template’; sam szablon umieszczony jest w elemencie payload wiadomości wygląda jak normalna definicja, ale może zawierać odnośniki do zmiennych w składni: @param1, @param2. Szablony definicji umożliwiają ponowne wykorzystanie kodu. Mogą także zawierać odnośniki do innych szablonów.

21.1.5. Współpodpisanie (Cosigning)

Sub-definicja może wymagać, aby jednostka została podpisana przez inne adresy:

["cosigned by", "ANOTHER ADDRESS IN BASE32"]

21.1.6. Sprawdzanie (zapytanie) wcześniejszego wykorzystania adresu

Inny, potencjalny wymóg dotyczący sub-definicji: adres musi wcześniej wystąpić jako autor w co najmniej jednej jednostce zawartej w ostatniej jednostce kuli:

["seen address", "ANOTHER ADDRESS IN BASE32"]

21.1.7. Wprowadzanie danych

Jednym z bardziej użytecznych warunków, jaki może być wykorzystany w celu sprawdzenia wcześniej zapisanych w Byteball danych jest:

["in data feed", [["ADDRESS1", "ADDRESS2", …],"data feed name","=","expected value"

]]

Warunek ten ocenia dane jako prawdziwe, jeżeli występuje, co najmniej jedna wiadomość, która posiada "data feed name" równe "expected value" wśród wiadomości data feed, których autor znajduje się pod adresem umieszczonym na liście:"ADDRESS1", "ADDRESS2", .. (oracles). Data feed to rodzaj wiadomości, który wygląda w sposób następujący:

unit: {…messages: [

…{

app: "data_feed",payload_location: "inline",payload_hash: "hash of payload",payload: {

"data feed name": "value","another data feed name": "value2",…

}},…

],…

}

Pola danych mogą być wykorzystane w celu skonstruowania definicji zawierających oracles. Jeżeli jedna lub więcej stron ufa, że dana jednostka (oracle) przekaże prawdziwe dane, to mogą one utworzyć wspólny adres kontrolny, który nada stronom różne [prawa w zależności od danych zawartych w oracle. Na przykład, poniższa definicja adresu przedstawia opcję binarną:

["or", [["and", [

["address", "ADDRESS 1"],

["in data feed", [["EXCHANGE ADDRESS"], "EURUSD", ">","1.1500"]]

]],["and", [

["address", "ADDRESS 2"],["in data feed", [["TIMESTAMPER ADDRESS"], "datetime", ">","2016-10-01 00:00:00"]]

]]]]

Początkowo, obie strony finansują adresy określone za pomocą tej definicji (aby usunąć wszelkie wymogi odnośnie do zaufania, wykorzystują one podpisy multisig i wysyłają swoje stosy w pojedynczej jednostce podpisanej przez obie strony). Następnie, jeżeli kurs wymiany EUR/USD opublikowany przez adres kantoru i przekracza 1.1500, to pierwsza strona może zabrać środki. Jeżeli nie nastąpi to do 1 października, 2016r. i jeżeli oracle umieszczająca znacznik czasu wyśle informacje o późniejszej dacie, to druga strona może zabrać fundusze zdeponowane pod tym adresem. Jeżeli obydwa warunki zostaną uznane za prawdziwe i saldo adresów będzie różne od pustego, obie strony mogą podjąć próbę pobrania środków w tym w samym czasie, a kwestia podwójnego wydatkowania zostanie rozwiązana w zwykły sposób.

Operatory porównania mogą być następujące: "=", "!=", ">", ">=", "<" oraz "<=". Wiadomości data feed muszą znaleźć się jak zwykle przed ostatnią jednostką kuli. Aby zredukować ryzyko powstające w sytuacji, gdy dowolna pojedyncza oracle nagle straci dostęp do Internetu, można umieścić na liście kilka adresów dostawcy feed.

Kolejny przykład dotyczy klienta, który kupuje towary w sklepie, ale nie do końca ufa temu sklepowi i chce odzyskać pieniądze w sytuacji, gdy dostawa nie zostanie zrealizowana. Klient dokonuje wpłaty na wspólny adres zdefiniowany jako:

["or", [["and", [

["address", "MERCHANT ADDRESS"],["in data feed", [["FEDEX ADDRESS"], "tracking", "=","123456"]]

]],["and", [

["address", "BUYER ADDRESS"],["in data feed", [["TIMESTAMPER ADDRESS"], "datetime", ">","2016-10-01 00:00:00"]]

]]]]

Definicja zależy od oracle FedEx, która wysyła numery referencyjne wszystkich skutecznie doręczonych przesyłek. Jeżeli przesyłka jest dostarczona, kupiec będzie w stanie odblokować środki w oparciu o pierwszy warunek. Jeżeli przesyłka nie zostanie doręczona przez upływem określonego terminu, klient może wycofać wpłacone środki.

Przykład ten jest nieco szalony, ponieważ zakłada on, że FedEx wysyła informacje dotyczące każdej przesyłki.

21.1.8. Data feeds Merklego

Aby użyć nieco bardziej realistycznej ścieżki pozwalającej osiągnąć ten sam cel, można wykorzystać inną składnię:

["in merkle", [["ADDRESS1", "ADDRESS2", …],"data feed name","hash of expected value"

]]Która pozwala ocenić jako prawdziwe dane, jeżeli podana liczba haszująca przewidywanej wartości została włączona do dowolnego korzenia merklego wysłanego w data feed z adresu "ADDRESS1", "ADDRESS2",… Używając tej składni, FedEx jedynie okresowo publikowałby korzenie merklego dotyczące wszystkich wysyłek zrealizowanych do daty poprzedniej wiadomości. Aby wydatkować środki z tego adresu, sklep musiałby przedstawić ścieżkę merklego, która wykaże, że określona wartość jest rzeczywiście częścią odpowiedniego drzewka merklego. Ścieżka merklego jest podawana jako jeden z elementów weryfikacji.

21.1.9. Auto-inspekcja

Definicja może także zawierać zapytania dotyczące samej jednostki. Poniższa sub-definicja

['has', {what: 'input'|'output',

asset: 'assetID in base64 or "base" for bytes',type: 'transfer'|'issue',own_funds: true,amount_at_least: 123,amount_at_most: 123,amount: 123,address: 'INPUT OR OUTPUT ADDRESS IN BASE32'

}]

ocenia jako prawdziwe, jeżeli jednostka posiada co najmniej jedną jednostkę danych wejściowych lub wyjściowych (w zależności od pola ‘what’), która przejdzie przez wszystkie określone filtry, z których wszystkie będą opcjonalne.

Podobny warunek w postaci ‘has one’ wymaga, aby istniał dokładnie jeden zestaw danych wejściowych I wyjściowych, który zostanie przepuszczony przez wszystkie filtry.

Warunek ‘has’ może być wykorzystany w celu zorganizowania zdecentralizowanego kantoru. Wcześniej omówiliśmy wykorzystanie podpisów multilsig w celu wymiany środków.

Nie mniej jednak samo podpisu multisig nie zawierają żadnego mechanizmy negocjacji ceny. Załóżmy, że użytkownik chce nabyć 1 200 jednostek innej waluty, za które jest skłonny zapłacić nie więcej niż 1 000 bajtów. Ponadto nie jest on skłonny pozostać dostępnym przez

cały czas w oczekiwaniu na sprzedającego. Woli wysłać zamówienie do kantoru I zrealizować, kiedy pojawi się odpowiedni sprzedający. Może także złożyć zlecenie z limitem wysyłając 1 000 bajtów na adres podany w poniższej definicji:

["or", [["address", "USER ADDRESS"],["and", [

["address", "EXCHANGE ADDRESS"],["has", {

what: "output",asset: "ID of alternative asset",amount_at_least: 1200,address: "USER ADDRESS"

}]]]

]]

Pierwsza alternatywa or umożliwia użytkownikowi odebranie swoich bajtów w dowolnym momencie i anulowanie zlecenia. Druga alternatywa deleguje na kantor prawo do wydatkowania funduszy z zastrzeżeniem, że inne dane wyjściowe w tej samej jednostce zwrócą co najmniej 1200 innych jednostek na adres użytkownika. Kantor opublikuje zlecenie, sprzedający znajdzie je, skomponuje jednostkę, która dokona wymiany środków i złoży podpis multisig w kantorze.

Można także wykorzystać warunek ‘has’ w odniesieniu do pożyczek zabezpieczonych. Załóżmy, że pożyczkobiorca posiada pewne środki niepłynne i potrzebuje kilka bajtów (lub inne środki płynne). Pożyczkobiorca oraz pożyczkodawca mogą następnie wielostronnie złożyć podpisy pod daną jednostką. Jedna z części jednostki wysyła niezbędne bajty do pożyczkobiorcy, druga część jednostki blokuje środki nieposiadające płynności na adresie zdefiniowanym jako:

["or", [["and", [

["address", "LENDER ADDRESS"],["in data feed", [["TIMESTAMPER ADDRESS"], "datetime", ">","2017-06-01 00:00:00"]]

]],["and", [

["address", "BORROWER ADDRESS"],["has", {

what: "output",asset: "base",amount: 10000,address: "LENDER ADDRESS"

}]]],["and", [

["address", "LENDER ADDRESS"],["address", "BORROWER ADDRESS"]

]]]]

Pierwsza alternatywa or umożliwia pożyczkodawcy zajęcie zabezpieczenia, w przypadku braku spłaty pożyczki w wyznaczonym terminie. Kolejna alternatywa umożliwia pożyczkobiorcy odebranie zastawu, jeżeli jednocześnie dokona wpłaty 10,000 bajtów (uzgodniona wielkość pożyczki wraz z odsetkami) na rzecz pożyczkodawcy. Inna opcja dopuszcza zmianę warunków umowy za obopólną zgodą.

Poniższe wymogi mogą być także włączone jako część sub-definicji:

['has equal', {equal_fields: ['address', 'amount'],search_criteria: [

{what: 'output', asset: 'asset1', address: 'BASE32'},{what: 'input', asset: 'asset2', type: 'issue', own_funds:true, address: 'ANOTHERBASE32'}

]}]

Pozwala ona ocenić jako prawdziwe dane, jeżeli wystąpi w nich co najmniej jedna para danych wejściowych lub wyjściowych, która spełni kryteria wyszukiwania (pierwszy element pary będzie znaleziony przez pierwszy zbiór filtrów; drugi przez drugi) a niektóre z ich pól będą równe.

Podobny warunek ‘has one equal’ wymaga, aby istniała dokładnie jedna taka para.

Kolejna sub-definicja może porównywać sumy danych wyjściowych lub wejściowych zgodnie z pewnymi kryteriami przyjętymi dla wartości docelowych lub wartości:

['sum', {filter: {

what: 'input'|'output',asset: 'asset or base',type: 'transfer'|'issue',own_funds: true,address: 'ADDRESS IN BASE32'

},at_least: 120,at_most: 130,equals: 123

}]

21.1.10. Negacja

Każdy warunek, który nie zawiera “sig”, “hash”, “address”, “cosigned by”, lub “inmerkle” może być zanegowany:

["not", ["in data feed", [["NOAA ADDRESS"], "wind_speed", ">", "200"]]]

Ponieważ można pełnoprawnie dokonać wyboru bardzo starych rodziców (którzy nie widzieli nowszych feed post-ów danych), można zawsze połączyć warunki negatywne takie jak powyżej z wymogiem, aby znacznik czasu był po pewnej dacie.

21.2. Wymogi ogólne

Definicja adresu musi zawsze mieć co najmniej jeden “sig”, określony w sposób wyraźny bądź nie (np. za pośrednictwem “address”).

Aby uniknąć skonsumowania zbyt wielu środków na walidację, łączna liczba operacji jest ograniczona do 100 dla każdej definicji w tym operacji w definicjach zawartych w odnośnikach takich jak “address” oraz “definition template”.

Liczba ta jest jedną z 9 dowolnych stałych liczb, które mamy w Byteballu, pozostałych 8 to: ogólna liczba świadków: 12; maks. Liczba dopuszczalnych mutacji: 1; maks. Liczba indeksów łańcuchów MC, a by świadek otrzymał wynagrodzenie: 100; liczba rodziców wliczonych w rozmiar nagłówka: 2; maks. Liczba wiadomości w każdej jednostce: 128; maks. liczba danych wejściowych lub wyjściowych w wiadomości: 128; maks. liczba autorów w wiadomości: 16; oraz ogólna ilość przekazywanych środków: 1015. Dla porównania, Bitcoin posiada co najmniej 17 liczb stałych [8], podczas gdy Ethereum definiuje 30 liczb stałych tylko dla harmonogramu płatności [9].

Należy zauważyć, że język definicji opisany powyżej ma charakter deklaratywny I składa się w całości ze zdań logicznych, co zbliża go do języka konwencjonalnych umów prawnych. Nie mniej jednak, jeżeli chodzi o moc jego wyrażania, język ten nawet nie zbliża się do języka inteligentnych kontraktów Ethereum. Tak naprawdę, nie dopuszcza on możliwości napisania zwykłego program powitalnego. To nie był nasz cel. Język definicji Byteball nie został zaprojektowany jako język wszechstronny; raczej w założeniu miał być zrozumiały (czytelny) dla możliwie jak największej liczby osób, które niekoniecznie są programistami. Jego prosta składnia umożliwia każdemu zinterpretowanie i skomponowanie prostych definicji bez pomocy programisty (“prawnika” ery inteligentnych (smart) kontraktów) oraz zmniejsza szanse popełnienia błędu.

22. ProfileUżytkownicy mogą przechowywać swoje profile w Byteballu, jeżeli taką podejmą decyzję. Wykorzystują wtedy takie wiadomości:

unit: {…messages: [

….{

app: "profile",payload_location: "inline",payload_hash: "hash of payload",payload: {

name: "Joe Average",emails: ["joe@example.com", "joe@domain.com"],twitter: "joe"

}},…

],…

}

Ilość danych ujawnianych na własny temat oraz ich prawdziwość jest podsumowana aż do poziomu samych użytkowników. Aby mieć pewność, że dowolna informacja na temat użytkownika jest prawdziwa trzeba poszukać możliwości atestacji.

23. AtestacjeAtestacje potwierdzają, że użytkownik, który je wystawił (atestujący) zweryfikował dane dotyczące atestowanych użytkowników (podmiot). Atestacje są zapisywane w postaci wiadomości takich, jak poniższa:

unit: {…messages: [

…{

app: "attestation",payload_location: "inline",payload_hash: "hash of payload",payload: {

address: "ADDRESS OF THE SUBJECT"profile: {

name: "Joe Average",emails: ["joe@example.com"]

}}

},…

],…

}

Informacje zawarte w atestacji nie muszą być tożsame z profilem opublikowanym przez użytkownika. istotnie, the profil opublikowany przez użytkownika może nawet nie istnieć w rzeczywistości.

Zadanie atestatora jest zbliżone do nowoczesnych jednostek certyfikujących, które weryfikują tożsamość jednostek istniejących w świecie rzeczywistym i zaświadczają, że danych klucz publiczny (lub adres Byteball) rzeczywiście należy do danej osoby lub organizacji. Oczekujemy, że będą one kontynuować tę działalność w Byteballi naliczać opłatę należna od osób, które zechcą udowodnić istnienie powiązania pomiędzy ich rzeczywistym światem, a tożsamościami Byteball’a. świadkowi9e oraz niedoszli

świadkowie będą najprawdopodobniej chcieli otrzymywać atestacje w celu zwiększenia swojego zaufania. Niektóre typy środków mogą wymagać atestacji transakcji za pomocą środków (patrz: poniżej).

W przypadku aplikacji, w których atestacja jest konieczna, ale nazwa podmiotu nie ma znaczenia, istnieje możliwość pominięcia nazwy lub innych informacji umożliwiających identyfikację w atestowanym profilu. Profil ten może nawet nie zawierać żadnych znaczących informacji dotyczących podmiotu sprawiając, że będzie anonimowy dla wszystkich poza jednostką atestującą. Atestujący będzie w dalszym ciągu zapisywać informacje dotyczące podmiotu i może je ujawnić w pewnych okolicznościach zgodnie z warunkami określonymi przez atestującego lub zgodnie z przepisami prawa.

24. AktywaZaprojektowaliśmy bazę danych, która umożliwia niepodlegające mutacji przechowy6wanie dowolnych danych. Ze wszystkich klas danych, najbardziej interesujące w celu przechowywania we wspólnej bazie danych są te, które posiadają wartość społeczną, tzn. dane, które są cenne dla więcej niż jednego lub dwóch uczestników. Jedną z takich klas są aktywa. Aktywa mogą być w posiadaniu dowolnej osoby spośród pewnej grupy osób a właściwości niemutowalności oraz ogólne uszeregowanie wydarzeń, które mamy w Byteballu mają istotne znaczenie dla ustalenia ważności długich łańcuchów zawierających informacje o transferze własności. Aktywa w Byteballu mogą być emitowane, transferowane oraz wymieniane oraz będą zachowywać się w sposób zbliżony do lokalnej waluty - ‘bajtów. Mogą one reprezentować wszystko, co ma jakąkolwiek wartość; na przykład dług, akcje, punkty lojalnościowe, czas przelotu, towary, inne waluty fiducjarne lub kryptowaluty.

Aby zdefiniować nowe aktywa, użytkownik definiujący wysyła następująca wiadomość:

unit: {…messages: [

…{

app: "asset",payload_location: "inline",payload_hash: "hash of payload",payload: {

cap: 1000000,is_private: false,is_transferrable: true,auto_destroy: false,fixed_denominations: false,issued_by_definer_only: true,cosigned_by_definer: false,spender_name_attested: true,attestors: [

"2QLYLKHMUG237QG36Z6AWLVH4KQ4MEY6","X5ZHWBYBF4TUYS35HU3ROVDQJC772ZMG"

]

}},…

],…

}

W tym przykładzie: ograniczenie definiuje maksymalną kwotę, jaka może być wystawiona. Dla

porównania z predefiniowanymi bajtami lokalnej waluty, pułap górny bajtów określony jest jako 1015;

is_private informuje, czy środki są przekazywane przez osobę prywatną lub publiczną (patrz: tekst poniżej). Bajty są publiczne;

is_transferrable informuje, czy środki mogą być transferowane pomiędzy stronami trzecimi bez konieczności przechodzenia przez jednostkę definiująca środki. Jeżeli nie są one transferowalne, definiujący musi zawsze być albo jedynym wysyłającym albo jedynym odbiorcą każdego transferu. Bajty są transferowalne;

auto_destroy informuje o tym, czy środki są niszczone po wysłaniu do definiującego. Bajty nie są jednostkami samoniszczącymi się;

fixed_denominations informuje, czy środki mogą być wysłane w postaci liczby całkowitej (dowolne kwoty) lub w stałych nominałach (np. 1, 2, 5, 10, 20, etc.), jak to ma miejsce w przypadku banknotów i monet. Bajty mogą być wyrażane w dowolnych wielkościach;

issued_by_definer_only – wyrażenie to mówi o tym, czy dana kwota może być wysłana jedynie przez osobę definiująca. Jeżeli chodzi o bajty, to wszystkie środki pieniężne są generowane w jednostce genesisunit;

cosigned_by_definer – wyrażenie to informuje o tym, czy każdy transfer musi być współpodpisany przez definiującego dane środki finansowe. Rozwiązanie to jest przydatne w przypadku walut regulowanych. Transfer wartości w bajtach nie wymaga współpodpisu drugiej osoby;

spender_attested – wyrażenie to wskazuje, czy wydatkujący musi posiadać atest, aby wydatkować środki. Jeżeli otrzymał środki, ale nie uzyskał jeszcze atestu, musi poddać się procesowi atestacji przez jedna z uprawnionych jednostek wymienioną w definicji, aby móc wydatkować środki. Wymogów ten jest także użyteczny w przypadku walut regulowanych. Bajty nie wymagają żadnej atestacji (certyfikacji);

attestors (jednostki atestujące) to po prostu lista adresów zbudowana przez jednostkę definiującą środki finansowe (wyłącznie, gdy wyrażenie spender_attested jest prawdziwe). Lista ta może być następnie zmodyfikowana przez autora definicji za pomocą wiadomości ‘asset_attestors’, która zastępuje listę jednostek atestujących;

denominations (nominały) (nieprzedstawione w tym przykładzie i wykorzystywane wyłącznie w kontekście środków typu fixed_denominations) zawierają listy wszystkich dopuszczalnych nominałów oraz łączną liczbę coinów, jaka może być wystawiona w danych nominale;

transfer_condition jest to definicja warunku, po spełnieniu, którego dana wartość finansowa środek może być transferowana. Definicja jest podana w tym samym języku, co definicja adresu, z tym, że nie może ona zawierać odnośnika do jakiegokolwiek elementu, który wymaga podania elementu weryfikacji, np. “sig”.

Domyślnie, nie ma żadnych ograniczeń poza tymi, które zostały już zdefiniowane przez pozostałe pola;

issue_condition jest taki sam jak transfer_condition dotyczy jednak transakcji wysyłanych/wystawianych.

Dla każdej jednostki może być wykorzystany nie więcej niż 1 ‘środek finansowy’. Po jego zdefiniowaniu, środki są identyfikowane przez wartość haszującą jednostki, w której zostały zdefiniowane (stąd wymóg 1 środka finansowego na jednostkę).

Transfer środków wygląda podobnie jak transfer bajtów z ta różnicą, że dla identyfikatora środków finansowych utworzone jest dodatkowe pole:

unit: {…messages: [

…{

app: "payment",payload_location: "inline",payload_hash: "hash of payload",payload: {

asset: "hash of unit where the asset wasdefined",inputs: [

{unit: "hash of source unit",message_index: 0,output_index: 1

},…

],outputs: [

{address: "BENEFICIARY ADDRESS",amount: 12345

},…

]}

},…

],…

}

Zanim będzie możliwe przekazanie środków, podczas transakcji emisji tworzona jest pewna wartość finansowa. Transakcje emisji mają nieco inny format danych wejściowych:

unit: {…messages: [

…

{app: "payment",payload_location: "inline",payload_hash: "hash of payload",payload: {

asset: "hash of unit where the asset wasdefined",inputs: [

{type: "issue",amount: 1000000,serial_number: 1,address: "ISSUER ADDRESS" // onlywhen multi-authored

},…

],outputs: [

{address: "BENEFICIARY ADDRESS",amount: 12345

},…

]}

},…

],…

}

Łączna podaż środków o dowolnej kwocie i określonym pułapie musi zawrzeć się w jednej transakcji. W szczególności zaś wszystkie bajty są emitowane w transakcji genesis. Jeżeli środki mają wyznaczony limit, numer seryjny emisji musi być równy 1. Jeżeli nie jest on ograniczony numery seryjne poszczególnych emisji wychodzących z tego samego adresu muszą być niepowtarzalne (unique).Środki w danej transakcji są definiowane tylko jeden raz i po emisji nie mogą być zmienione za wyjątkiem list jednostek atestujących.

Jednostka definiująca podejmuje decyzję o tym, jaką wartość środki reprezentują. Jeżeli jest to zadłużenie emitenta, to można w sposób zasadny oczekiwać, że jest jednostka atestowaną lub rezygnuje z anonimowości, aby pozyskać zaufanie kredytodawców.

Chociaż użytkownicy końcowi mają swobodę podejmowania decyzji w sprawie wykorzystania środków lub nie, jednostki definiujące te środki mogą narzucić dowolne wymogi dotyczące transakcji, której są przedmiotem.

Łącząc różne cechy, jednostka definiująca może stworzyć szeroką gamę wymogów w tym także wymogi, które muszą być przestrzegane przez regulowane instytucje finansowe. Dla przykładu: określając wymóg, aby każdy transfer był współpodpisywany przez jednostkę definiującą, instytucje finansowe mogą skuteczne zawetować wszelkie płatności sprzeczne z

zasadami określonymi w przepisach lub odpowiednich kontraktach. Przed złożeniem drugiego podpisu pod płatnością, instytucja finansowa (która jest także jednostką definiującą oraz emitentem) może zweryfikować, czy użytkownik jest rzeczywiście jej klientem, czy odbiorca środków jest jednocześnie klientem, czy obie strony (klienci) zostały poddane procedurom Know Your Client (KYC) (poznaj swojego klienta), czy środki nie są przedmiotem zajęcia komorniczego z nakazu sądu oraz przeprowadzić wszelkie dodatkowe weryfikacje wymagane w świetle stale zmieniających się przepisów, regulacji oraz zasad wewnętrznych z uwzględnieniem tych, które zostały wprowadzone po tym jak została utworzona definicja środków finansowych.

24.1. Środki wysyłane/emitowane przez bank

Posiadając zabezpieczenie w postaci pełnej zgodności (oraz asekurację w postaci znanej nam ostateczności deterministycznej wszystkich transferowanych środków finansowych), banki mogą emitować wartości (środki), które są połączone z walutami lokalnymi (krajowymi) i gwarantowane przez środki bankowe (które podlegają odpowiednim audytom oraz monitoringowi przez banki centralne). Legalny charakter wszystkich operacji na tych środkach jest dokładnie taki sam, jak w przypadku wszystkich pozostałych środków bankowych i znany jest nam wszystkim. Jedyną nowością jest to, że salda oraz transfery są śledzone w bazie Byteball zamiast w wewnętrznej bazie bankowej. Rozwiązanie to ma dwa skutki:

(niezbyt mile widziany) wszystkie operacje są publiczne, co znamy już z Bitcoina i są ograniczone za pomocą częściowo anonimowych adresów i tylko bank wie, kim są osoby, które za nimi stoją. Innym, nieco mocniejszym sposobem zachowania prywatności są prywatne płatności, o których mowa w dalszej części opracowania;

(pozytywny) środki wyemitowane przez bank mogą być wymieniane na bajty lub inne waluty dostępne w łańcuchu, w trybie peer-to-peer, bez konieczności zaufania żadnym stronom trzecim, takim jak np. kantory

Struktura banków zbliżona jest do Ripple gateways.

W przedstawionym powyżej scenariuszu wymiany, jednym z filarów wymiany jest płatność dokonywana przez jednego użytkownika na rzecz drugiego w ramach środków emitowanych przez bank. W sytuacji, gdy obydwaj użytkownicy są klientami tego samego banku, proces ten ma charakter bezpośredni. Jeżeli użytkownicy posiadają rachunki w różnych bankach, Banki te mogą ułatwić międzybankowy transfer środków tworząc rachunki korespondencyjne w swoich oddziałach. Załóżmy, że użytkownik U1 chce przekazać środki na rzecz użytkownika U2 w sytuacji, w której użytkownik U1 posiada rachunek w banku B1 a użytkownik U2 posiada konto w banku B2. Bank B2 również otwiera konto w B1. Następnie U1 dokonuje transferu środków na rachunek B2’s w B1 (jest to zatem wewnętrzny przelew bankowy w ramach B1, który jest współpodpisywany przez B1). Jednocześnie, B2 (który właśnie dokonał zwiększenia swoich środków w B1) wysyła nowe środki na rachunek swojego użytkownika U2. Cały proces musi mieć charakter atomowy. Całą trójka uczestników: (U1, B1 oraz B2) musi zatem podpisywać pojedynczą jednostkę, która zarówno dokonuje transferu środków B1 z rachunku U1 do B2 jak i przekazuje środki B2 do U2.

Wynik netto jest następujący: U1 dokonał zmniejszenia swojego salda w B1, U2 zwiększył swoje saldo w B2, a B2 zwiększył swoje saldo w B1. Bank B1 będzie także posiadać rachunek korespondencyjny w B2, którego saldo będzie wzrastać w miarę przetwarzania transakcji odwrotnych wysyłanych przez użytkowników B2 na rzecz użytkowników B1. Wzajemne zobowiązania (B1 w B2 oraz B2 w B1) mogą być częściowo anulowane przez banki wzajemnie podpisujące transakcję, w ramach której wysyłane są równe kwoty do odpowiednich emitentów/wystawców (wygodnie jest mieć środki, które ulegają autodestrukcji po przekazaniu do wystawcy/emitenta). To co nie zostało anulowane może być okresowo rozliczane w drodze tradycyjnych rozliczeń międzybankowych. Aby uruchomić rozliczenia, bank posiadających dodatnie saldo netto wysyła informacje o tym bankowy – emitującemu, a ponieważ nie występuje transfer odwrotny w ramach tej samej transakcji, czynność ta uruchamia dodatkowe płatności w ramach środków fiducjarnych kierowanych od wystawcy do banku, który je posiada.

W sytuacji, gdy istnieje wiele banków, które nawiązują bezpośrednie relacje korespondencyjne z każdym równouprawnionym bankiem (peer bank) wszelkie interakcje pomiędzy nimi mogą okazać się uciążliwe. W takiej sytuacji, banki wyznaczają centralną stronę/jednostkę C (duży bank członkowski lub zupełnie nową instytucję) przekazują wszystkie płatności wyłącznie za pośrednictwem tej jednostki centralnej i tylko z nią prowadzą wszelkie rozliczenia.

A zatem przekaz tych samych środków od U1 do U2 będzie zrealizowany w drodze 3 transakcji:

1. U1 wysyła środki na rachunek C w B1;2. C wysyła własne środki do B2 (lub C niszczy posiadane środki B2 zwracając je do B2);3. B2 wysyła swoje własne pieniądze do U2.

Wszystkie 3 transakcje są powiązane w jedną i podpisane przez U1, B1 (jako obowiązkowego współpodpisującego wszystkie transakcje U1), C oraz B2.

24.2. środki niefinansowe

Pozostałe aplikacje (zastosowanie), które nie do końca mają charakter finansowy mogą wykorzystywać środki Byteball do transakcji wewnętrznych. Na przykład, w ramach programów lojalnościowych mogą być emitowane punkty w postaci środków i wykorzystywać istniejącą infrastrukturę Byteballa w celu umożliwienia użytkownikom zawierania transakcji z wykorzystaniem tych punktów, w transakcji peer-to-peer (jeżeli są dopuszczane przez reguły programu). Ta sama zasada obowiązuje w przypadku programistów tworzących gry, którzy potrafią śledzić środki zgromadzone w ramach gier w Byteballu.

24.3. Obligacje

Firmy mogą emitować obligacje w systemie Byteball. Struktura prawna emisji jest taka sama, jak w przypadku obligacji konwencjonalnych, z tą różnicą, że depozyt śledzi właścicieli przy pomocy Byteballa, a nie wewnętrznej bazy danych (podobnie jak banki, o

których mowa powyżej). Posiadanie obligacji w Byteballu umożliwia ich posiadaczom bezpośredni obrót bez pośrednictwa zcentralizowanego kantoru. Jeżeli środki pozostające do dyspozycji banku są także w systemie Byteball, możliwa jest realizacji szybkich płatności na podstawie zlecenia (wypłata środków fiducjarnych w tym kontekście) staje się możliwa bez ryzyka drugiej strony oraz bez pośrednictwa jakiejkolwiek instytucji centralnej. Tytuł do obligacji oraz wypłaty środków są przekazywane równolegle, gdy tylko strony podpiszą tę samą jednostkę, która realizuje obydwa transfery.

Obligacje o dostatecznie wysokiej płynności mogą być także wykorzystywane przez strony trzecie jako środki płatnicze.

Kiedy emitowana jest obligacja, emitent oraz inwestor mogą wielostronnie złożyć podpis pod wspólną jednostką, która wyemituje nowe obligacje na rzecz inwestora i jednocześnie prześle bajty (lub inne środki wykorzystane w celu zakupu obligacji, np. wyemitowane przez bank związane środki fiducjarne) od inwestora do pożyczkobiorcy. Po umorzeniu obligacji, strony podpisują kolejną wielostronną jednostkę, która odwraca wymianę (najprawdopodobniej przy wykorzystaniu innego kursu wymiany). Cena obligacji uzyskana podczas wykupu równa jest cenie nominalnej; cena sprzedaży podczas emisji musi być niższa od wartości i uwzględniać odsetki (przyjmując dla uproszczenia obligacje zerokuponowe). W okresie ważności, wtórna cena rynkowa obligacji pozostaje na poziomie poniżej wartości nominalnej i stopniowo zbliża się do niej.

W gospodarce rozwijającej się, gdzie istnieje wiele projektów finansowania, obligacje oraz inne papiery dłużne emitowane w ramach Byteball umożliwiające finansowanie inwestycji będą emitowane częściej niż wykupowane. Jeżeli gospodarka zacznie zwalniać, ogólna podaż obligacje skurczy się i liczba projektów umożliwiających pozyskanie finansowania zmniejszy się. Tym samym, ogólna podaż obligacji podlega autoregulacji, co ma istotne znaczenie w przypadku, gdy są one często wykorzystywane jako środek płatniczy.

W sytuacji, gdy dwie firmy zawierają transakcje z terminem płatności netto 30dni, zarówno kupujący jak i sprzedający mogą wybrać opcję sekurytyzacji kredytu kupieckiego w okresie 30-dniowym. Na przykład, kupujący może wyemitować obligacje 30-dniowe i wykorzystać je w celu natychmiastowej realizacji płatności na rzez zbywającego. Sprzedający może labo poczekać 30 dni, aż obligacje zostaną wykupione albo wykorzystać je jako środek płatniczy na rzecz swoich własnych dostawców. W takim przypadku, dostawcy będą stronami dokonującymi umorzenia obligacji w terminie wykupu.

24.4. Instrumenty towarowe - commodity bonds

Obligacje mogą być emitowane w naturze, a nie tylko w walutach. Na przykład, obligacja o wartości 100 baryłek uprawnia jej posiadacza do odbioru 100 baryłek ropy w terminie wykupu; obligacja na 1kWh uprawnia jej posiadacza do odbioru 1 kWh elektryczności. Jej właściciel może także wybrać opcje pieniężnego wymienionych 100 baryłek lub 1 kWh po cenie obowiązującej w terminie wykupu.

Obligacje te (instrumenty towarowe) są bardzo użyteczne, jeżeli chodzi o ograniczenie (hedging) ryzyka. Rozważmy teraz nowy projekt związany z ropą, który przewidziany jest na okres wielu lat i wiąże się z wysokimi inwestycjami zanim zostanie uruchomiony. Jeżeli finansowanie przewidziane jest wyłącznie w walutach lokalnych, projekt może nigdy nie zostać sfinansowany z uwagi na niepewność cen ropy w chwili uruchomienia sprzedaży przez jednostkę. Kredytodawcy muszą rozważyć ryzyko, że cena okaże się zbyt niska i w efekcie u pożyczko/kredytobiorcy mogą wystąpić zaległości. Pożyczkodawcy chcą, aby ryzyko to zostało uwzględnione w stopie procentowej, co oznacza, że zostanie ona określona na wysokim poziomie i że projekt nigdy nie dojdzie do skutku.

Jeżeli jednak wykonawca projektu będzie mógł zaciągnąć zobowiązanie w baryłkach, to ryzyko zaległości znacznie spada. Teraz, projekt uruchomi się zgodnie z planem I prawdopodobnie przyczyni się do wyprodukowania planowanej ilości [baryłek] ropy. W związku z tym, będzie w stanie wyprodukować oraz spłacić wszystkie zobowiązania w baryłkach w uzgodnionym terminie. Istnieją jeszcze inne ryzyka, ale to główne – ryzyko rynkowe – zostało wyeliminowane. Jest ono zdjęte z pożyczkobiorcy i przeniesione na kredytodawców, którzy teraz muszą uwzględnić możliwość spadku cen ropy i zwrot niższy niż sama inwestycja (jeżeli chodzi o środki pieniężne). Z drugiej strony, jeżeli ceny pójdą w górę, pożyczkodawcy uzyskają możliwość dodatkowego zysku w związku z różnicą cen (należy podkreślić, że zaciągając zobowiązania w baryłkach, storna zobowiązana zrzeka się możliwości wykorzystania wzrostu cenowego), i zawsze znajdą się inwestorzy, którzy zechcą zając pozycje na danych towarze. Ponieważ obligacje są wystawione w Byteballu, kredytodawcy mogą z łatwością sprzedać je w dowolnym terminie. W odróżnieniu od transakcji dotyczących ropy, obrót którymi jest grą z wynikiem zerowym, inwestycja w instrumenty towarowe stanowi źródło finansowania dla sektora. Ponadto, transakcje futures dotyczące ropy są instrumentami krótkoterminowymi, a instrumenty towarowe (obligacje) umożliwiają zakup i przetrzymywanie ich, co jest bardziej atrakcyjnym rozwiązaniem dla inwestorów długoterminowych.

Istnieje jeszcze jedna kategoria potencjalnych pożyczkodawców – są to osoby, które zabezpieczają się (hedge) przed przeciwnym ryzykiem. Na przykład, linie lotnicze chętnie zabezpieczają się na wypadek wzrostu cen ropy, a jednym ze sposobów jest zakup instrumentów towarowych od producentów ropy, które będą korelować z cenami ropy.

Powyższe stwierdzenie sprawdza się w przypadku dowolnych towarów, np. elektryczności, rud żelaza, złota, innych metali, zbóż, etc.

Z punktu widzenia pożyczkobiorcy, instrumenty towarowe mogą być postrzegane jako sposób na sprzedanie tego, co zostanie wyprodukowane w przyszłości po cenach dzisiejszych. Dla pożyczkodawcy, jest to sposób na zakup przyszłych dostaw po cenach obowiązujących dzisiaj.

Jeżeli przeważająca część gospodarki będzie funkcjonować w oparciu o instrumenty towarowe, cykl dźwigni zostanie w sposób naturalny złagodzony, nawet bez interwencji ze strony rządu, ponieważ podczas recesji spadające ceny towarów automatycznie powodują obniżenie kwoty zadłużenia.

24.5. Fundusze

W przypadku użytkowników indywidualnych może okazać się trudne śledzenie dużej liczby obligacji dostępnych na rynku. Są oni raczej zainteresowani inwestycjami w fundusze profesjonalnie zarządzane i posiadaniem dużego, zdywersyfikowanego portfela obligacji. Fundusz może dokonać emisji swoich własnych środków, które będą śledzić zagregowaną wartość portfela funduszu. Za każdym razem, kiedy inwestor dokona zakupu nowej jednostki funduszu, ten ostatni przeznaczy środki na zakup obligacji. W chwili wychodzenia użytkownika z pozycji, fundusz dokonuje sprzedaży niektórych obligacji i umarza aktywa wyemitowane przez siebie i zwrócone przez użytkownika. Aktywa funduszu nie są ograniczone; górny pułap podaży zależny jest od liczby inwestorów przystępujących i wychodzących z pozycji. Wartość funduszu łatwo skontrolować, ponieważ wszystkie obligacje będące w posiadaniu funduszu są uwidocznione w Byteballu. Mając nieco większą płynność niż obligacje, aktywa funduszu mają większe szanse na to, że staną się środkami płatniczymi.

24.6. Rozliczenia

Grupa banków może wykorzystać środki do rozliczeń międzybankowych. Niektóre większe banki emitują aktywa połączone z walutami fiducjarnymi, które mogą wykorzystać wyłącznie certyfikowani (atestowani) użytkownicy – tylko członkowie grupy mogą być atestowani. Aktywa są zabezpieczane na rezerwa banków - emitentów. Kiedy mniejszy bank chce rozliczyć się z innym małym bankiem, po prostu wysyła środki. Bank-odbiorca może je wykorzystać w taki sam sposób, aby rozliczyć się z innymi bankami lub umorzyć je w zamian za walutę fiducjarną z bankiem emitującym. Banki mogą także wymienić środki połączone z euro lub innymi, podobnymi walutami. Wszelkie tego typu transakcje są rozliczane natychmiast, są ostateczne i nieodwoływalne. W systemie SWIFT, banki wymieniają jedynie informacje na temat płatności, a rzeczywisty transfer środków stanowi kolejny krok. W Byteball, informacje stanowią walutę.

25. Płatności prywatne Do tej pory zajmowaliśmy się jedynie płatnościami, które są wysyłane w sposób otwarty, tzn. ich payloady są umieszczone w linii i widoczne dla wszystkich. Należy pamiętać, że Byteball umożliwia wysyłanie prywatnych payloadów: użytkownik zachowuje prywatny charakter payloadu (payload_location=’none’) i wysyła tylko jego wartość haszującą, aby udowodnić, że dany payload istniał w określonym czasie. Aby zastosować to rozwiązanie w odniesieniu do płatności, wysyłający środki musi także wysłać prywatny payload do odbiorcy za pośrednictwem prywatnych kanałów komunikacji. Odbiorca będzie musiał odszukać wartość haszującą payloada w Byteball, aby potwierdzić, że dana transakcja istnieje. Nie wystarczy to jednak, ponieważ ukrywszy treść payloada przed innymi węzłami Byteballa, usuwamy jednocześnie ich zdolność do weryfikacji tych samych danych wyjściowych i wyeliminowania możliwości ich podwójnego wydatkowania. Aby przywrócić

tę zdolność, dodajemy jeszcze jedno pole publiczne do jednostki. Pole to nazywane jest spend proof (potwierdzenie wydatkowania) i jest skonstruowane w taki sposób, że:

Jest całkowicie uzależnione od konsumowanych danych wyjściowych, a zatem każda próba ponownego wydatkowania tych danych wyjściowych wygeneruje ten sam spend proof;

Nie ujawnia żadnych informacji dotyczących wydatkowanych danych wyjściowych.

Łatwo zauważyć, że konstrukcja przedstawiona poniżej spełnia ten wymóg:

spend_proof = hash({asset: payload.asset,unit: input.unit,message_index: input.message_index,output_index: input.output_index,address: src_output.address,amount: src_output.amount,blinding: src_output.blinding

})

W tym miejscu, payload.asset jest identyfikatorem środków przekazywanych w ramach prywatnej transakcji; dane wejściowe odnoszą się do danych wejściowych konsumujących poprzednie dane wyjściowe src_output. Prywatne dane wyjściowe powinny posiadać dodatkowe pole nazywane blinding (zaślepiającym), które stanowi jedynie losowy strumień zaprojektowany w celu uniemożliwienia pre-image konsumowanych danych wyjściowych na podstawie spend proof (wszystkie pozostałe pola pochodzą z dość wąskiego zbioru potencjalnych wartości, które mogą być powtórzone w rozsądnym okresie czasu).

Powyższa konstrukcja spend proof dotyczy transferów. W przypadku wysyłania:

spend_proof = hash({asset: payload.asset,address: "ISSUER ADDRESS",serial_number: input.serial_number, // always 1 for cappedassetsamount: input.amount, // issue amountdenomination: 1 // always 1 for arbitrary-amounts payments

})

Należy podkreślić, że spend proof niezbędny do wysłania transakcji nie zawiera żadnego czynnika blinding. W związku z tym, istnieje możliwość sprawdzenia, czy dany coin został wyemitowany, ale odbiorca coina jest w dalszym ciągu niewidoczny dla stron trzecich. Ponadto, w odniesieniu do transakcji transferowych, ponieważ odbiorca zna wartość czynnika blinding, jest w stanie obliczyć spend proof, który zostanie opublikowany w chwili wydatkowania coina. To z kolei oznacza, że będzie on wiedzieć, kiedy zobowiązany wyda coina, ale nie pozna odbiorcy(ów), ani nowego czynnika blinding – zatem nie będzie w stanie śledzić coina na kolejnych ścieżkach.

Spend proofs są dodawane do jednostki:

unit: {…spend_proofs: [

{spend_proof: "the above hash in base64",address: "SPENDING ADDRESS" // only if multi-authored

},…

],…

}

W związku z tym, aby wysłać prywatną płatność, wysyłający powinien: Dodać losowy czynnik blinding do wszystkich danych wyjściowych; Nie publikować payloadu, ale wysłać go do odbiorcy prywatnym kanałem wraz z

wartością haszującą jednostki, w której ten payload się znajduje; Dla wszystkich danych wejściowych konieczne jest podanie odpowiednich spend

proof i umieszczenie ich w jednostce.

Wszyscy walidujący powinni odrzucić jednostkę, jeżeli zauważą, że ponownie ten spam spend proof został wysłany z tego samego adresu (naturalnie z zastrzeżeniem, że adres dokonuje seryjnej wysyłki). Odbiorca powinien sprawdzić, czy (1) payload otrzymany za pośrednictwem prywatnego kanału jest zgodny z payload_hash wysłanym do Byteballa przez odbiorcę oraz (2) spend proofs obliczone na podstawie prywatnych danych wejściowych są zgodne z tymi, które znajdują się w jednostce.

Kiedy użytkownik otrzymujący płatność prywatną chce wydać posiadane środki, musi on przekazać prywatny payload, który otrzymał nowemu odbiorcy, po to aby ten mógł zweryfikować cały łańcuch transferu własności (historia) do punktu, w którym środki zostały wyemitowane. Długość historii rośnie wraz z każdym transferem.

Należy podkreślić, że w formacie płatności, który rozważaliśmy do tej pory, każda jednostka może „zlewać” się z kilkoma wcześniejszymi jednostkami i generować nowe dane wyjściowe (najczęściej dwie). Każda wcześniejsza jednostka z kolei jest uzależniona od kilku poprzednich i każda jednostka wyjściowa zostanie następnie podzielona na kilka nowych jednostek wyjściowych. Dlatego liczba przyszłych jednostek, które maja co najmniej “kroplę krwi” jednostki wyjściowej rośnie wykładniczo w czasie. I odwrotnie, liczba przodków, którzy mogą wnosić wkład do danych wejściowych jednostki rośnie wykładniczo wraz z liczbą kroków w głąb historii. Aby uniknąć takiego gwałtownego wzrostu historii, musimy ograniczyć podzielność coinów i w tym miejscu bardzo przydaje się środek finansowy, w którym właściwość fixed_denominations ma parametr true – prawda.

26. Waluty o stałych nominałach Waluty o stałych nominałach są rejestrowane w postaci zbioru niepodzielnych niemożliwych do połączenia coinów, bardzo podobnych do tych, które powstają w mennicach i wytwórniach papierów wartościowych, które są nam tak dobrze znane.

Wartość każdego coina musi stanowić jeden mały zbiór dopuszczalnych nominałów, które powinny być wybrane w taki sposób, aby wygodnie reprezentować wszelkie kwoty z maksymalna dokładnością jednocześnie wykorzystując jak najmniejsza ich liczbę. Większość nowoczesnych systemów, posiada nominały, które są zgodne z wzorcem 1-2-5: 1, 2, 5, 10, 20, 50, 100, 200, 500, itp. Wzorzec ten jest także zalecany w przypadku stałych nominałów w systemie Byteball.

Coiny są wstępnie grupowane w pakiety zbliżone do tych, w które są grupowane banknoty. Pakiety te mogą być podzielone na mniejsze lub poszczególne coiny, ale nie łączą się ze sobą. Oznacza to, że każdy transfer musi posiadać dokładnie jeden zestaw danych wejściowych (z uwagi na brak możliwości łączenia), a kwoty wyjściowe muszą być wielokrotnościami nominałów coinowych (ponieważ nominał jest najmniejszą, niepodzielna jednostką).

Każda transakcja, emisja lub transfer, dotyczy coinów z jednym nominałem. Nie może ona wyemitować lub przesłać coinów o innych nominałach w tym samym czasie (ale każda jednostka składowania może zwierać kilka takich transakcji). Transakcje w oparciu o stałe nominały mają niemal ten sam format co transakcje o dowolnej ilości środków, z tą różnicą, że dopuszczalny jest tylko jeden zestaw danych wejściowych, a kwoty muszą być wielokrotnościami jednego nominału i dodawane jest jego pole:

payload: {asset: "hash of unit where the asset was defined",denomination: 100,inputs: [ // exactly one input

{type: "issue",amount: 1000000,serial_number: 1, // always 1 for capped assetsaddress: "ISSUER ADDRESS" // only when multi-authored

}],outputs: [

{address: "BENEFICIARY ADDRESS",amount: 800 // multiple of 100

},{

address: "CHANGE ADDRESS",amount: 999200 // multiple of 100

}]

}

Jeżeli środki są ograniczone, cała podaż w każdym nominale musi być wyemitowana w ramach jednej transakcji. Dlatego, jeżeli środki występują np. w 16 nominałach, pełna emisja środków odbędzie się w 16 transakcjach. Jeżeli środki nie są ograniczone, numery seryjne różnych emisji tego samego nominału z tego samego adresu muszą być unikalne.

W sytuacji, gdy konieczne jest wysłanie lub transfer kilku coinów (co z reguły ma miejsce), płatnik umieszcza kilka wiadomości w tej samej jednostce. W przypadku transferów, coin jest identyfikowany za pomocą jednostki, indeksu wiadomości oraz indeksu danych wyjściowych, w których został uprzednio przekazany do obecnego właściciela.

W przypadku płatności prywatnych, payload podawany jest oddzielnie i dodatkowo ukrywa odbiorców wszystkich danych wyjściowych za wyjątkiem tego, który jest przeznaczony dla odbiorcy:

payload: {asset: "hash of unit where the asset was defined",denomination: 200,inputs: [{

unit: "hash of source unit",message_index: 2,output_index: 0

}],outputs: [

{output_hash: "hash of hidden part of output thatincludes address and blinding factor",amount: 800

},…

]}Informacje dostępne w danych wyjściowych umożliwiają odbiorcy weryfikację, czy suma wszystkich danych wyjściowych odpowiada danym wejściowym. Pojedyncze dane wyjściowe są przeznaczone dla odbiorcy i ujawniane mu w następujący sposób:

output: {address: "BENEFICIARY ADDRESS",blinding: "some random string"

}To z kolei umożliwia odbiorcy weryfikację output_hash oraz skonstruowane spend proof w przyszłości, kiedy postanowi wydatkować środki (output).

W systemie Byteball, mamy [prywatne, stałe nominały blackbyty, które są zdefiniowane przez poniższe właściwości:{

cap: 2,111,100,000,000,000,is_private: true,is_transferrable: true,auto_destroy: false,fixed_denominations: true,issued_by_definer_only: true,cosigned_by_definer: false,spender_name_attested: false,denominations: [

{denomination: 1, count_coins: 10,000,000,000},{denomination: 2, count_coins: 20,000,000,000},{denomination: 5, count_coins: 10,000,000,000},

{denomination: 10, count_coins: 10,000,000,000},{denomination: 20, count_coins: 20,000,000,000},{denomination: 50, count_coins: 10,000,000,000},{denomination: 100, count_coins: 10,000,000,000},{denomination: 200, count_coins: 20,000,000,000},{denomination: 500, count_coins: 10,000,000,000},{denomination: 1000, count_coins: 10,000,000,000},{denomination: 2000, count_coins: 20,000,000,000},{denomination: 5000, count_coins: 10,000,000,000},{denomination: 10000, count_coins: 10,000,000,000},{denomination: 20000, count_coins: 20,000,000,000},{denomination: 50000, count_coins: 10,000,000,000},{denomination: 100000, count_coins: 10,000,000,000}

]}Warto podkreślić, że mamy podwójna liczbę coinów w 2 nominałach, ponieważ są one nam częściej potrzebne. Na przykład: potrzebujemy dwie dwójki dla kwot 4 (2+2) oraz 9 (5+2+2).

Spend proofs odnoszące się do transferów u emisji prywatnych, niepodzielnych środków (o stałych nominałach) są dokładnie takie same, jak w przypadku aktywów o dowolnych nominałach z tym wyjątkiem, że nominały te niekoniecznie muszą wynosić 1.

W odróżnieniu od płatności podzielnych, każdy stały nominał zlewa się z innymi coinami. Dlatego, kiedy coin jest transferowany kanałem prywatnym, jego historia rozrasta się liniowo w czasie, a nie wykładniczo i możliwa jest jej obsługa (uwzględniając, że zasoby obliczeniowe takie jak składowanie, szerokość wiązki oraz moc jednostki przetworzeniowej CPU będzie rosnąć wykładniczo w przewidywalnym okresie w przyszłości).

Wraz z historią, rośnie ryzyko ataku prywatnych payloadów przez strony trzecie będące przyszłymi właścicielami tych samych coinów. Jak wspominano wcześniej, przyrost tern jest dość wolny, a wartość prywatnych payloadów dla adwersarzy stopniowo spada w czasie. Nie mniej jednak należy pamiętać, że duże sklepy i kantory wysyłające I odbierające wiele płatności na co dzień będą prawdopodobnie posiadać bardzo długie (fragmentaryczne) historie. Dlatego należy unikać wielokrotnego wykorzystywania tych samych adresów, nawet w przypadku płatności prywatnych.

Warto zauważyć, że w niektórych przypadkach strony trzecie mogą wywnioskować istotne informacje nawet dotyczące prywatnych płatności. Na przykład, po podziale większości pakietów na poszczególne coiny, kiedy użytkownik wysyła wiele prywatnych płatności w tej samej jednostce, obserwator może stwierdzić, że użytkownik wysyła coiny o maksymalnym nominale, ponieważ, aby wysłać kwotę, która jest znacznie wyższa niż nominał maksymalny trzeba wysłać najprawdopodobniej coiny o maksymalnym nominale. Na tej podstawie obserwator może wywnioskować przybliżoną kwotę transferu (ale nic więcej). Aby uniknąć wycieku tych informacji, zaleca się rozłożenie dużych kwot na liczne adresy i wysyłanie ich w oddzielnych jednostkach.

Podejście w oparciu o spend proof, wybrane przez nas, nie jest jedynym możliwym rozwiązaniem.Aby udowodnić odbiorcy, że środki, które otrzymuje nie zostały wcześniej wykorzystane, płatnik może po prostu wysłać mu wszystkie prywatne payloady, jakie kiedykolwiek wyszły z jego adresu. Odbiorca może następnie sprawdzić każdy z nich pod kątem kwot podwójnie wydatkowanych. Nie zalecamy takiego postępowania, ponieważ wiąże się ono z niepotrzebnym wyciekiem informacji poufnych i przyczynia się do utrudnienia kodowania klienta light. Zamiast tego, proponujemy nieco zwiększyć miejsce i uprościć proces weryfikacji.

27. TekstyDowolne teksty można przechowywać w wiadomości ‘tekstowej’ typu:

unit: {…messages: [

…{

app: "text",payload_location: "inline",payload_hash: "hash of payload",payload: "any text"

},…

],…

}Interpretacja tekstu zależy od autora i docelowych odbiorców; węzły Byteball nie walidują ich, a tylko sprawdzają, czy jest to strumień. Można wykorzystać ten typ wiadomości na przykład, aby przesłać nieusuwalne tweety. Payload może być prywatny a nawet użyteczny w przypadku np. przechowywania wartości haszujących praw własności intelektualnej użytkowników lub do przechowywania wartości haszujących kontraktów znanych tylko kilku stornom.

28. Dane o dowolnej strukturze Dane mogą posiadać dowolna strukturę opartą na wiadomości typu ‘dane’:

unit: {…messages: [

…{

app: "data",payload_location: "inline",payload_hash: "hash of payload",payload: {

key: "value",

another_key: {subkey: "other value",another_subkey: 232

}}

},…

],…

}

Interpretacja tego typu danych zależy od autora i jego partnerów, którzy muszą widzieć dane; węzły Byteballa nie walidują ich, a tylko sprawdzają czy są one obiektowe. Na przykład, ta wiadomość może być wykorzystana w celu wysłania kodu Ethereum odnoszącego się do podzbioru węzłów, które go zrozumieją, ale trzeba pamiętać, że but nie mogą one odrzucić jednostki nawet jeśli kod jest unieważniony przez reguły Ethereum.

Podobnie jak wiadomości ‘płatność’ i ‘tekst’, wiadomości zawierające ‘dane’ mogą być prywatne i wtedy zapisywana jest tylko wartość haszująca. Kontynuując przykład Ethereum, kontrakty tego typu (Ethereum) mogą być przesyłanie prywatnymi kanałami, jeżeli odpowiednie spend proofs zostały skonstruowane.

29. GłosowanieKażdy może stworzyć pulę wysyłając wiadomość app=’poll’:

unit: {…messages: [

…{

app: "poll",payload_location: "inline",payload_hash: "hash of payload",payload: {

question: "Should the United Kingdom remain amember of the European Union or leave theEuropean Union?",choices: ["Leave", "Remain"]

}},…

],…

}

Aby oddać głos, użytkownicy wysyłają wiadomości ‘vote’:

unit: {…messages: [

…{

app: "vote",payload_location: "inline",payload_hash: "hash of payload",payload: {

unit: "hash of the unit where the poll wasdefined",choice: "Leave"

}},…

],…

}Określenie, które głosy są ważne należy do organizatora puli. Byteball nie wymusza niczego za wyjątkiem ustalenia, że dokonane wybory znajdują się w dozwolonym zbiorze. Na przykład, organizator może przyjąć, że głosy pochodzące od atestowanych użytkowników lub od użytkowników znajdujących się na predeterminowanej białej liście użytkowników. Głosy niekwalifikowane będą zapisane, ale powinny być wykluczone przez organizatora podczas zliczania ich liczby.

Ważenie głosów oraz interpretacja wyników jest także zależna od organizatora puli. Jeżeli użytkownicy głosują za pośrednictwem swoich sald, należy pamiętać, że mogą przenieść swoje salda na inne adresy i zagłosować ponownie. Tego typu sytuacje należy odpowiednio rozwiązywać.

30. Prywatne wiadomościAby prywatne płatności zadziałały, użytkownicy muszą mieć sposób, aby bezpiecznie dostarczyć prywatne payloady do siebie wzajemnie. Użytkownicy, a raczej ich urządzenia muszą także posiadać możliwość komunikowania się i gromadzenia podpisów w celów adresów typu multi-sig.

Ponieważ nie możemy oczekiwać, że urządzenia użytkowników będą stale dostępne w trybie online kontakt z nimi będzie zawsze możliwy (większość z nich znajdzie się za NAT), musimy mieć pośrednika typu store-and-forward, który będzie zawsze dostępny, z którym zawsze będzie kontakt i który będzie w stanie okresowo przechowywać dane dowolne dane adresowane do urządzenia użytkownika.

W Byteball, taki pośrednik nazywany jest hubem, a operacje, które wykonuje przypominają wiadomość elektroniczną. Hub jest węzłem a Byteball, który dodatkowo oferuje usługi przechowywania i przesyłania prywatnych wiadomości do podłączonych urządzeń. Może być wiele hubów. Każde urządzenie, które uruchamia kod portfeli subskrybuje hub wybrany przez siebie i może dostępny za pośrednictwem tego właśnie huba (home hub). Home hub może być w dowolnym czasie zmieniony. Każde urządzenie posiada permanentny klucz prywatny, który jest unikalny dla danego urządzenia. Wartość haszująca korespondującego klucza publicznego (to znaczy wartość haszująca definicji

pojedynczego podpisu oparta na tym kluczu publicznym) jest nazywana adresem urządzenia - device address i jest kodowana w base32 podsobnie jak adresy płatności. Pełny adres urządzenia oraz aktualnego huba może być zapisany w postaci: DEVICEADDRESSINBASE32@hubdomainname.com. Jeżeli urządzenie przejdzie do kolejnego huba, część jego pełnego adresu przed @ pozostanie niezmieniona. W przeciwieństwie do wiadomości elektronicznej nazwa nie może być wcześniej “wykorzystana”.

Każde urządzenie łączy się ze swoim hubem home za pomocą websockets. Hub wysyła nowe wiadomości do urządzenia, które jest podłączone do huba w taki sposób, że jeżeli nowa wiadomość przychodzi podczas pracy urządzenia w sieci jest ona przekazywana natychmiast. Hub nie przechowuje kopii wiadomości, które zostały skutecznie zatwierdzone przez urządzenie. Połączenie z hubem jest kodowane w TLS.

Kiedy urządzenie chce wysłać informacje do innego urządzenia, to łączy się ono z hubem odbiorcy i przekazuje wiadomość. W odróżnieniu od wiadomości elektronicznej, nie ma element przekaźnikowego – wysyłający łączy się bezpośrednio z hubem odbiorcy. Cała komunikacja pomiędzy urządzeniami jest szyfrowana w trybie end-to-end I zawiera podpis cyfrowy, którego nawet hub (jedyny pośrednik) nie jest w stanie zmodyfikować. Korzystamy z ECDSA w celu złożenia podpisu i ECDH+AES w celu szyfrowania.

Przed dokonaniem wymiany szyfrowanych wiadomości urządzenia muszą być sparowane, tzn. muszą sobie przekazać swoje klucze publiczne. Mogą tego dokonać na różne sposoby, np. skanując kod QR szyfrujący klucz publiczny oraz nazwę domeny huba jednego z urządzeń lub klikając na link byteball:// na bezpiecznej stronie internetowej.

Aby zagwarantować bezpieczeństwo przesyłanej informacji, każde urządzenie generuje tymczasowy klucz prywatny i pobiera odpowiedni klucz publiczny do swojego huba home. Następnie, urządzenie od czasu do czasu rotuje klucz, ale zachowuje kopię poprzedniego, na wypadek, gdyby ktoś przesłał wiadomość na poprzedni klucz w trakcie zmiany klucza przez hub. Hub przechowuje tylko jedną wersje tymczasowego klucza publicznego w każdym subskrybenckim urządzeniu.

Urządzenie wysyłające realizuje następujące kroki w celu przekazania wiadomości:1. połączenie z hubem odbiorcy;2. pobranie bieżącego, tymczasowego klucza publicznego odbiorcy z huba;3. wygenerowanie swojej własnej, jednorazowej, efemerycznej pary kluczy;4. obliczenie wspólnego sekretu ECDH na podstawie tymczasowego klucza publicznego odbiorcy i własnego, efemerycznego klucza prywatnego;5. Szyfrowanie wiadomości przez AES w oparciu o wspólny sekret;6. Dodanie własnego efemerycznego klucza publicznego;7. Podpisanie pakietu własnym kluczem permanentnym oraz 8. wysłanie do huba.

Urządzenie odbiorcy weryfikuje podpis, oblicza sekret ECDH wykorzystując klucz publiczny efemeryczny równoprawnego użytkownika i odszyfrowuje wiadomość.

Jeżeli urządzenie wysyłające nie połączy się z hubem odbiorcy, szyfruje wiadomość zgodnie z kluczem permanentnym odbiorcy (takie szyfrowanie nie jest bezpieczne (forward secure), ponieważ wykorzystuje klucz permanentny) i przechowuje lokalnie zaszyfrowane wiadomości w celu wykorzystania w przyszłości. Celem tego typu szyfrowania jest unikanie powszechnej dostępności zaszyfrowanych wiadomości. Po podłączeniu do huba odbiorcy, urządzenie wysyła te zaszyfrowane wiadomości i jednocześnie ponownie je szyfruje (tym razem z zabezpieczeniem forward), zatem wiadomość jest podwójnie szyfrowana. Należy zauważyć, że nie dzieje się tak dlatego, że jednokrotne szyfrowanie jest niewystarczające, ale dlatego, że nie chcemy przechowywać niezaszyfrowanych treści przez czas nieokreślony, podczas gdy następują próby połączenia.

Trzeba pamiętać, że komunikacja następuje pomiędzy urządzeniami, a nie użytkownikami. Użytkownicy mogą (i jest to zalecane) posiadać kilka urządzeń takich jak laptop, smartfon, czy tablet i tworzy adresy typu multisig o redundancji (np. 2-z-3), która zależna jest od kluczy zapisanych w różnych urządzeniach. Kiedy użytkownik musi złożyć podpis pod transakcją, uruchamia jedno ze swoich urządzeń, które następnie wysyła częściowo podpisana transakcję do innego urządzenia za pośrednictwem prywatnych wiadomości, gromadzi wszystkie podpisy i upublicznia transakcję. Prywatne klucze zapisane w urządzeniach nigdy nie powinny ich opuścić. Kiedy użytkownik zastępuje jedno ze swoich urządzeń 2-z-3 adresów, po prostu wykorzystuje drugie 2 z urządzeń, aby zmienić definicję adresu i zastąpić klucz starego urządzenia kluczem urządzenia nowego.

Wiadomości prywatne mogą być także wykorzystywane do wymiany szyfrowanych wiadomości pomiędzy urządzeniami. Wiadomości te są wyłącznie typu peer-to-peer i nigdy nie są wprowadzane do bazy Byteballa; mogą też być bezpiecznie wyrzucone po odczytaniu.

Kiedy użytkownicy dokują płatności w blackbytach lub innych środkach prywatnych, muszą wysłać prywatne payloady i bezwzględnie muszą dysponować urządzeniami, które potrafią się ze sobą komunikować. Muszą znać wzajemne adresy urządzeń zanim poznają adres payment. Po nawiązaniu łączności, odbiorca może wysłać swój adres do płatnika za pośrednictwem czatu. Taki scenariusz płatności ułatwia także generowanie unikalnych adresów dla każdej nadchodzącej płatności. Sklep może prowadzić czat bot, ale komunikować się z użytkownikami za pośrednictwem wiadomości tekstowych. Kiedy użytkownik jest gotowy do realizacji płatności, bot generuje nowy adres dla niej i wysyła go do użytkownika na czacie.

31. ZakończenieZaproponowaliśmy system zdecentralizowanego, niemodyfikalnego składowania dowolnych danych w tym danych o wartości społecznej takich jak środki płatnicze. Każda nowa jednostka danych implicytywnie potwierdza istnienie wszystkich wcześniejszych jednostek. Zmiana treści rekordów podobna to tej, która została opisana w 1984 staje się niemożliwa, ponieważ każda nowa jednostka także ten sam sposób chroni wszystkie wcześniejsze jednostki przed zmiana lub usunięciem. Istnieje wewnętrzna waluta, która jest

wykorzystywana w celu dokonania opłaty za umieszczenie danych w zdecentralizowanej bazie. Płatność jest równa rozmiarowi danych, które mają być przechowywane i które nie są płatnościami; nie ma ograniczeń dostępu do bazy. Pozostałe aktywa mogą być także wyemitowane, a ich właścicieli można prześledzić w bazie. W trakcie śledzenia, płatności w wewnętrznej walucie oraz inne aktywa, kwoty podwójnie wydatkowane są rozwiązywane w drodze wyboru wersji historii, która jest poświadczana przez renomowanych użytkowników. Ostateczność rozliczenia ma charakter deterministyczny. Środki mogą być wysyłane w oparciu o dowolne zasady umożliwiające ich transferowalność, co umożliwia instytucjom regulowanym emisję środków spełniających wymogi ustawowe. jednocześnie, transfer może być ukryty przed stronami trzecimi za pomocą prywatnej transmisji treści bezpośrednio pomiędzy płatnikiem a odbiorcą i upublicznienie spend proofs gwarantujących jednorazowe wydatkowanie środków.

Bibliografia1. Cytat z Wikipedii: https://en.wikipedia.org/wiki/Nineteen_Eighty-Four.2. Satoshi Nakamoto. Bitcoin: A Peer-to-Peer Electronic Cash System,https://bitcoin.org/bitcoin.pdf, 2008.3. Sergio Demian Lerner. DagCoin,https://bitslog.files.wordpress.com/2015/09/dagcoin-v41.pdf, 2015.4. Serguei Popov. The Tangle, http://iotatoken.com/IOTA_Whitepaper.pdf,2016.5. TomHolden. Transaction-Directed Acyclic Graphs,https://bitcointalk.org/index.php?topic=1504649.0, 2016.6. Linked timestamping, https://en.wikipedia.org/wiki/Linked_timestamping.7. Atomic cross-chain trading, https://en.bitcoin.it/wiki/Atomic_crosschain_trading.8. https://github.com/bitcoin/bitcoin9. Gavin Wood. Ethereum: A Secure Decentralised Generalised TransactionLedger, http://gavwood.com/Paper.pdf.