Odporność na błędy bizantyjskie w systemach peer-to-peer - Instytut ...

Politechnika Warszawska
Wydział Elektroniki i Technik Informacyjnych
Praca Dyplomowa Magisterska
Odporność na błędy bizantyjskie w systemach
peer-to-peer
Łukasz Walkiewicz
praca pod kierunkiem dr inż. Tomasza Jordana Kruka
Instytut Automatyki i Informatyki Stosowanej
Warszawa 2005

Spis treści
1 Wprowadzenie 5
1.1 Zawartość poszczególnych rozdziałów . . . . . . . . . . . . . . . 6
1.2 Geneza systemów peer-to-peer . . . . . . . . . . . . . . . . . . . 7
1.3 Zagadnienia bezpieczeństwa . . . . . . . . . . . . . . . . . . . . 8
1.4 Zastosowania sieci peer-to-peer . . . . . . . . . . . . . . . . . . 10
1.4.1 Współdzielenie plików . . . . . . . . . . . . . . . . . . . 11
1.4.2 Anonimowe połączenia i trasowanie cebulkowe . . . . . 12
1.4.3 Maskowanie usługi . . . . . . . . . . . . . . . . . . . . . 14
2 Architektury systemów peer-to-peer 17
2.1 Nieustrukturalizowane systemy peer-to-peer . . . . . . . . . . . . 20
2.2 Ustrukturalizowane systemy peer-to-peer . . . . . . . . . . . . . 21
2.2.1 Przestrzeń identyfikatorów . . . . . . . . . . . . . . . . . 22
2.2.2 Trasowanie przedrostkowe . . . . . . . . . . . . . . . . . 24
2.2.3 Rozproszone tablice z kodowaniem mieszającym . . . . . 25
2.3 Architektura systemów Chord i Pastry . . . . . . . . . . . . . . . 27
2.3.1 Algorytm routingu . . . . . . . . . . . . . . . . . . . . . 28
2.3.2 Przyłączanie do systemu . . . . . . . . . . . . . . . . . . 29
2.4 Bezpieczeństwo w systemach peer-to-peer . . . . . . . . . . . . . 30
2.4.1 Klasyczne problemy bezpieczeństwa . . . . . . . . . . . 31
2.4.2 Nadawanie identyfikatorów . . . . . . . . . . . . . . . . 32
2.4.3 Przesyłanie komunikatów . . . . . . . . . . . . . . . . . 33
2.4.4 Masowe przyłączanie i odłączanie . . . . . . . . . . . . . 33
3 Bezpieczne bizantyjskie uzgadnianie 35
3.1 Problem bizantyjskich generałów . . . . . . . . . . . . . . . . . 36
3.2 Replikacja z uwzględnieniem błędów bizantyjskich . . . . . . . . 39
3.3 Algorytm BFT . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.3.1 Założenia algorytmu BFT . . . . . . . . . . . . . . . . . 41
3.3.2 Działanie algorytmu BFT . . . . . . . . . . . . . . . . . 42
3.3.3 Optymalizacje zastosowane w BFT . . . . . . . . . . . . 44
3.3.4 Proaktywne odzyskiwanie stanu w BFT . . . . . . . . . . 45

4 SPIS TREŚCI
3.4 Algorytm SC-ABC . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.4.1 Kryptografia progowa . . . . . . . . . . . . . . . . . . . 48
3.4.2 Stos protokołów SC-ABC . . . . . . . . . . . . . . . . . 50
3.4.3 Działanie algorytmu SC-ABC . . . . . . . . . . . . . . . 54
3.5 Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4 Tolerowanie bizantyjskich uszkodzeń 61
4.1 Algorytm naiwny . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.2 Założenia projektowe . . . . . . . . . . . . . . . . . . . . . . . . 63
4.3 Zestaw dostępnych operacji . . . . . . . . . . . . . . . . . . . . . 67
4.4 Protokół zachłanny . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.5 Zatwierdzanie stanu . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.6 Protokół optymistyczny . . . . . . . . . . . . . . . . . . . . . . . 82
4.7 Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
5 Projekt systemu Pastor 85
5.1 Projekt systemu . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
5.1.1 Język implementacji - Java . . . . . . . . . . . . . . . . 86
5.1.2 Bezpieczeństwo wykonania . . . . . . . . . . . . . . . . 86
5.1.3 Postarzanie obiektów . . . . . . . . . . . . . . . . . . . . 89
5.1.4 Zarządzanie dostępem . . . . . . . . . . . . . . . . . . . 92
5.2 Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
A Elementy teorii grafów 97
A.1 Spójność krawędziowa i wierzchołkowa . . . . . . . . . . . . . . 98
A.2 Różne typy grafów . . . . . . . . . . . . . . . . . . . . . . . . . 98
A.2.1 Grafy regularne i grafy losowe . . . . . . . . . . . . . . 99
A.2.2 Grafy Butterfly . . . . . . . . . . . . . . . . . . . . . . . 100
A.2.3 Grafy de Bruijn’a . . . . . . . . . . . . . . . . . . . . . . 100
B Uzgadnianie w asynchronicznym systemie 103
B.1 Brak konsensusu i asynchroniczność . . . . . . . . . . . . . . . . 103
B.2 Uzgadnianie z częściowym zachowaniem poprawności . . . . . . 107

Rozdział 1
Wprowadzenie
Zgodnie z empirycznym prawem Moore’a szybkość komputerów podwaja się
mniej więcej co półtora roku 1 . W przypadku sieci przepustowość łączy podwaja
się średnio co pół roku 2 . Zwiększanie przepustowości sieci powoduje, iż
coraz częściej aplikacje korzystają z przetwarzania rozproszonego. Na chwilę
obecną mówi się o architekturach z rozproszeniem wertykalnym i horyzontalnym
[TS01] oraz typu peer-to-peer. Pierwsze wymienione obejmują architektury
wielowarstwowe, w których aplikacje mają hierarchiczną budowę i najczęściej
stosowane są w aplikacjach biznesowych 3 . Horyzontalne rozproszenie obejmuje
systemy złożone z komponentów o różnym przeznaczeniu współpracujących ze
sobą. Architekturę typu peer-to-peer posiadają systemy składające się z zespołu
współpracujących, logicznie ekwiwalentnych jednostek.
W związku z powyższym coraz częściej naturalnym środowiskiem pracy
różnego typu aplikacji jest globalna sieć - Internet. Systemy informatyczne są
podzielone na fizyczne komponenty częstokroć zlokalizowane w geograficznie
odrębnych zakątkach globu, objęte całkowicie niezależną jurysdykcją.
Ekspozycja środowisk komputerowych w ogólnie dostępnej sieci wymaga
znacznie mocniejszych zabezpieczeń chroniących przed nieautoryzowanym dostępem,
podsłuchem i celowymi atakami. Niejednokrotnie brak mechanizmów
zabezpieczeń zupełnie uniemożliwia systemom bezawaryjne działanie.
W tej pracy przedstawiono zagadnienie zapewnienia tolerancji błędów bizan-
1 Od 2004 roku wydaje się, że zwiększanie mocy obliczeniowej komputerów zaczyna odbiegać
od prawa Moore’a.
2 W przypadku sieci zwiększanie przepustowości następuje rzadziej niż ma to miejsce w
przypadku zwiększania mocy obliczeniowej, ale przeważnie szybkość zmienia się o cały rząd
wielkości (np. 10MBit, 100MBit, 1GBit).
3 Takimi systemami są aplikacje dostępu do bazy danych oparte na tzw. cienkim kliencie
(ang. thin client). Najniższą warstwę w architekturze stanowi baza danych. W kolejnej warstwie
znajduje się serwer aplikacji, który odpowiedzialny jest za wykonanie logiki. Najwyższa warstwa
to wspomniane oprogramowanie dostępowe, czyli cienki klient.

6 Rozdział 1. Wprowadzenie
tyjskich 4 w systemach peer-to-peer oraz pokazano techniki możliwe do wykorzystania
podczas projektowania i implementacji tego typu systemów. Głównym
celem stawianym w pracy jest opracowanie metody bezpiecznej replikacji dla
systemów luźno powiązanych (między innymi peer-to-peer), która wykazywałaby
dużą odporność na uszkodzenia, zarówno uwzględniając całkowite zaprzestanie
działania repliki, jak i jej arbitralne zachowanie. Replikacja jest główną
metodą podnoszenia odporności na awarię i tolerowanie uszkodzeń, jednak wymaga
efektywnych metod synchronizacji, które muszą charakteryzować się dużym
bezpieczeństwem. W systemach peer-to-peer sposobem na podniesienie
bezpieczeństwa może być również wzajemny audyt uczestników. Obie techniki
mogą zostać zrealizowane na bazie algorytmu bizantyjskiego uzgadniania, którego
propozycje zostały szczegółowo opisane.
1.1 Zawartość poszczególnych rozdziałów
W dalszej części pierwszego rozdziału opisano krótko genezę systemów peerto-peer
i przedstawiono problemy bezpieczeństwa występujące w tej klasie systemów.
W rozdziale drugim omówione zostały architektury systemów peer-topeer
z przeznaczeniem większej ilości miejsca dla ustrukturalizowanych systemów
peer-to-peer oraz podstaw teoretycznych ich konstrukcji [LKRG03]. W
tym samym rozdziale pokazane zostały trzy podstawowe usługi budowane na
bazie systemów peer-to-peer: rozproszone tablice z kodowaniem mieszającym
(ang. distributed hashing tables), rozproszona lokalizacja i dostęp do obiektów
(ang. distributed object location and routing) oraz usługa komunikacji grupowej
(ang. multicast, anycast). W rozdziale drugim zostały przedyskutowane problemy
bezpieczeństwa ze szczególnym naciskiem na zagadnienie bezpiecznego
trasowania oraz utrzymania spójności danych w rozproszonych tablicach z kodowaniem
mieszającym. W trzecim rozdziale zebrane zostały informacje dotyczące
protokołów bezpiecznego bizantyjskiego uzgadniania BFT i SC-ABC. Czwarty
rozdział został poświęcony projektowi protokołu bezpiecznego bizantyjskiego
uzgadniania przeznaczonego dla systemów luźno powiązanych. W piątym rozdziale
opisywana jest implementacja testowego systemu Pastor, który zawiera
mechanizmy poprawiające bezpieczeństwo i odporność na uszkodzenia, wykonanego
w ramach pracy magisterskiej. Pastor został oparty na na implementacji
systemu Pastry oraz jednej z jego aplikacji Past. Rozdział pierwszy i drugi oraz
trzeci i czwarty nie są ściśle ze sobą powiązane i mogą być czytane niezależnie,
natomiast rozdział piąty łączy uprzednio poruszaną tematykę i do zrozumienia
wymaga lektury całości materiału.
Dokument ten został napisany z założeniem, że czytelnik nie miał wcześniej
4 Inaczej arbitralnego zachowania elementów.

1.2 Geneza systemów peer-to-peer 7
do czynienia z systemami peer-to-peer, dlatego znaczną część pracy przeznaczono
na poglądowy opis architektur tych systemów, jak również przedstawiono
aspekty teoretyczne ich konstrukcji oparte na teorii grafów. Należy zaznaczyć,
że w momencie powstawania tego opracowania nie była dostępna żadna publikacja
ogólnie traktująca o systemach peer-to-peer zarówno w języku polskim, jak
i w języku angielskim, zatem znaczny nakład pracy włożono w zebranie oraz
podsumowanie aktualnych osiągnięć w tej dziedzinie.
1.2 Geneza systemów peer-to-peer
W 1999 roku, osiemnastolatek, Shawn Fanning zmienił dotychczasowe oblicze
przemysłu fonograficznego tworząc program do wymiany plików o nazwie
Napster. Uderzenie w przemysł fonograficzny spowodowane było tym, iż znakomitą
większość treści możliwych do pobrania dzięki Napsterowi, stanowiły
utwory muzyczne w formacie MP3.
Architektura Napstera była bardzo prosta. Jeden centralny serwer służył do
rejestracji udostępnianych plików. Użytkownik poszukujący określonej treści
wysyłał zlecenie do serwera i otrzymywał listę źródeł, które udostępniały dany
zasób. Następnie aplikacja łączyła się z różnymi komputerami pobierając kolejne
części poszukiwanego pliku. Pomimo wielu niedociągnięć pierwszych wersji,
program zdobył szaloną popularność i szybko pakiety protokołu Napstera zaczęły
dominować w sieci.
Kopiowanie plików muzycznych chronionych prawami autorskimi stanowi
pogwałcenie prawa, dlatego Napster został oskarżony przez organizację RIAA 5
w grudniu 1999 roku. Werdyktem sądu w lutym 2001 roku nakazano zamknięcie
serwisu Napstera.
Z punktu widzenia technicznego Napster nie był wyrafinowanym wynalazkiem,
jednak zainteresowanie ze strony użytkowników oraz precedensowy proces
rozpoczął debatę społeczną dotyczącą aspektów moralnych i prawnych związanych
z ochroną praw autorskich w sieci Internet. W 2000 roku Nullsoft wydał
Gnutellę, pojawiło się również wiele innych aplikacji podobnej architektury (AudioGalaxy,
Morpheus, Bearshare itd.). Pojawienie się Napstera i podobnych systemów
przyciągnęło uwagę badaczy akademickich, którzy rozpoczęli prace nad
systemami, które pozbawione byłyby podstawowych wad pierwszych aplikacji
peer-to-peer:
• Anonimowość - tożsamość użytkowników nie powinna być łatwa do ustalenia.
5 Recording Industry Association of America

8 Rozdział 1. Wprowadzenie
• Bezpieczeństwo - serwowana zawartość nie może odbiegać od sugerowanej
(przejaw zaśmiecania i zatruwania) oraz nie może występować zjawisko
cenzurowania, tzn. dostęp do zasobu nie może być blokowany przez stronę
trzecią.
• Skalowalność - system powinien móc operować przy dużej liczbie użytkowników
np. rzędu milionów.
• Decentralizacja - zastosowana jako mechanizm wprowadzający odporność
na uszkodzenia i wymuszający samoorganizację.
Wbrew ustaleniom sądowym liczba aplikacji typu peer-to-peer służących do
wymiany plików drastycznie wzrosła. Obecnie można pobrać między innymi
następujące aplikacje klienckie najbardziej popularnych sieci: KaZaa, eDonkey,
eMule, DC++, BitTorrent [Coh03]. W porównaniu do Napstera, czy Gnutelli
wymienione aplikacje są znacznie bardziej wyspecjalizowane i wyszukane pod
względem architektury, a liczba ich użytkowników sięga wielu milionów. Na
przykład eMule jest hybrydą sieci Overnet oraz Kademlia [MM02]. Overnet ma
budowę dwuwarstwową z wyróżnieniem serwerów, a Kademlia jest całkowicie
rozproszoną siecią używającą metryki XOR 6 .
Pierwsze systemy peer-to-peer zostały zaprojektowane w celu udostępniania
plików w sieci globalnej między dużą liczbą użytkowników. Obecnie eksperymentuje
się z systemami tej klasy w wielu innych zastosowaniach: usługi
nazewnicze, np. DNS [CMM02], usługi pocztowe, np. E-Mail [KRT03], czy
nawet implementację testową stosu protokołu IPv6 [ZvRM02].
1.3 Zagadnienia bezpieczeństwa
Tematyka bezpieczeństwa przyjmuje w każdym rodzaju systemów pewną postać,
charakterystyczną dla realizowanych funkcjonalności. Inaczej ma się sprawa z
systemami operacyjnymi, gdzie bezpieczeństwo przede wszystkim rozumiane
jest w sensie ochrony danych i zasobów tak, by nikt nieupoważniony nie był w
stanie uzyskać nieautoryzowanego dostępu do elementów kontrolowanych przez
system. W przypadku sieci informatycznych zagadnienia bezpieczeństwa koncentrują
się na zapewnieniu autoryzowanego dostępu do urządzeń dołączonych
do sieci, przeciwdziałaniu nadużyć w postaci nadmiernej ilości przesyłanych
danych 7 , czy podsłuchu i podszywania się.
6 Rozpatrując dwa adresy węzów v oraz u, odległość d między nimi dana jest jako d =
∑ L
i=0 2c(i) ,c= v ⊕ u. L oznacza długość adresu, natomiast c(i) wartość i-tego bitu w liczbie
c.
7 Chodzi głównie o ataki typu odmowy usługi DoS (ang. Denial of Service).

1.3 Zagadnienia bezpieczeństwa 9
Systemy peer-to-peer ze względu na pewne swoiste cechy wymagają zupełnie
innego sposobu analizy aspektów bezpieczeństwa. Oczywiście część z tych
zagadnień pozostaje taka sama, jak w przypadku klasycznych systemów, jednak
znakomita większość wyraźnie od nich odbiega.
Identyfikatory. Każdy węzeł w systemie peer-to-peer rozpoznawany jest za
pomocą unikalnego identyfikatora. Główną trudnością jest zarządzanie identyfikatorami,
nadzorowanie ich przydzielania oraz kontrolowanie sposobu użytkowania.
Ważność tego zagadnienia jest kluczowa dla prawidłowego działania
systemów tej klasy.
Przekazywanie komunikatów. Część komunikacji w powłokach peer-to-peer 8
odbywa się w sposób niebezpośredni. Można porównać działanie węzła w sieci
peer-to-peer do routera, który przekazuje komunikaty w przestrzeni identyfikatorów.
W przypadku fizycznych urządzeń istnieje możliwość wykrycia nadużyć
i niepoprawnego działania. Naprawa usterek i wprowadzenie zabezpieczeń
nie sprawia większego problemu, gdyż zazwyczaj urządzenie znajduje się pod
opieką administratora sieci, który jest fizyczną osobą (np. Janem Kowalskim),
bądź dostawcą usług sieciowych. Sieci peer-to-peer nie posiadają centralnych
mechanizmów administracyjnych, które wymuszałyby na użytkownikach zapewnianie
jakości działania uruchomionych przez nich aplikacji. Nie ma gwarancji
na to, że dany węzeł będzie działał poprawnie lub, że nie zakończy działania w
dowolnej chwili.
Bezpieczna replikacja. Replikacja w systemach peer-to-peer wykorzystywana
jest do zapewnienia większej dostępności informacji oraz odporności na uszkodzenia.
Brak gwarancji odnośnie działania węzłów wprowadza nowe zagadnienia
związane z replikacją i wymaga stosowania znacznie bardziej skomplikowanych
algorytmów (np. bezpiecznego bizantyjskiego uzgadniania), których omówienie
stanowi meritum tej pracy.
Zatruwanie i zaśmiecanie. Gdy mamy do czynienia z systemami, które udostępniają
usługę wstawienia oraz pozyskiwania danych przez użytkownika, często
dochodzi do nadużyć w postaci zatruwania i zaśmiecania [CWC]. Zatruwanie
oznacza wysyłanie treści niezgodnych z ich prawdziwą zawartością, a zaśmiecanie
jest wprowadzaniem danych w sieci, których treść niezgodna jest z sugerowaną
zawartością. Różnica pomiędzy tymi dwoma zachowaniami jest niezwykle
subtelna. Pierwszy atak polega na aktywnym działaniu węzłów i dezorganizacji
działania oprogramowania (np. przesyłaniu niepoprawnych odpowiedzi na
8 Terminy sieci, systemy oraz powłoki peer-to-peer będą w tej pracy stosowany zamiennie.

10 Rozdział 1. Wprowadzenie
torrent
http
http
torrent
torrent
leech
leech
seed
seed
tracker
leech
leech
seed
Rysunek 1.1: Architektura systemu udostępniania plików BitTorrent.
żądania klientów). Zaśmiecanie polega na umieszczaniu obiektu przynęty (ang.
decoy), który imituje prawdziwe obiekty, którymi użytkownicy są zainteresowani
(np. pliki w formacie mp3 zgodne długością i nazwą do popularnych utworów
muzycznych). Szczególnie nagminnie ten rodzaj ataków występuje w przypadku
systemów udostępniania plików, gdyż jest stosowany przez firmy fonograficzne
do obrony i zniechęcania użytkowników do pobierania danych chronionych prawami
autorskimi. Zarówno przed zaśmiecaniem i zatruwaniem użytkownicy
sieci peer-to-peer opracowali metody obrony, jednak nie są one w stanie całkowicie
wyeliminować istnienia tych zjawisk.
Wszystkie wymienione problemy bezpieczeństwa zostaną dokładniej omówione
w rozdziale drugim.
1.4 Zastosowania sieci peer-to-peer
Aplikacje typu peer-to-peer budowane są dzięki istnieniu grupy użytkowników,
którzy widzą potencjalną korzyść z użytkowania systemu, lub grupy organizacji
dysponujących wieloma komputerami połączonymi w sieć, które współdziałając
będę mogły realizować duże zadania, trudne do rozwiązania przez jedną,
nawet bardzo potężną maszynę. Podam kilka przykładów możliwych zastosowań
systemów peer-to-peer poczynając od udostępniania plików, które pomimo
interwencji wydawnictw fonograficznych, nadal jest jednym z najbardziej popularnych
zastosowań tego typu systemów.

1.4 Zastosowania sieci peer-to-peer 11
1.4.1 Współdzielenie plików
Odwołam się do prawdziwego protokołu udostępniania plików BitTorrent 9 ,który
działaniem przypomina bardzo Napstera, jednak jest na tyle dobrze zaprojektowany,
że znacznie przewyższa pierwowzór. BitTorrent składa się z następujących
komponentów (patrz rys. 1.1):
• Obserwator (ang. tracker) - przechowuje informację na temat źródeł i
statusu pobierania.
• Nasionko (ang. seed) - jest to użytkownik, który posiada 100% udostępnionego
udziału.
• Pijawka (ang. leech) - jest to użytkownik, który jest w trakcie pobierania
zasobu.
• Katalog (ang. directory) - jest to katalog plików torrent, dostępny dla
użytkowników, np. baza plików udostępniona używając serwera http.
Użytkownik, który chce udostępnić zasób buduje plik typu torrent, który
składa się z informacji na temat położeniu punktu dostępowego obserwatora
oraz zawiera skrót kryptograficzny i nazwę udostępnianych plików 10 . Zasób dzielony
jest na pewną liczbę fragmentów, która powinna zależeć od wielkości i od
liczby potencjalnych zainteresowanych. W pliku torrent zamieszczane są skróty
wszystkich części zasobu. Plik torrent zostaje umieszczony w dostępnym dla
użytkowników katalogu plików (może to być serwis internetowy). Użytkownicy
pobierają plik torrent i uruchamiają aplikację, która łączy się z obserwatorem.
Ten z kolei rejestruje pobierającego (jego adres i port, na którym nasłuchuje).
Istnienie obserwatora wprowadza nadzór nad procesem pobierania pliku i monitoruje
stan pobrań uczestników. Pobieranie pliku wygląda w ten sposób, że
kawałki zasobu najmniej rozpowszechnione stają się najbardziej prawdopodobne
do pobrania przez tych klientów, którzy mają największe części zasobu skopiowane
oraz odpowiednio szybko wysyłają zawartość innym uczestnikom 11 . Ta
technika dowartościowuje uczestników z szybkim łączem i prowadzi do lepszej
replikacji, która dzięki podziałowi zasobu na fragmenty pozwala maksymalnie
zrównoleglić proces rozsyłania zawartości. Tracker opcjonalnie może wymagać
logowania od pobierających. Komunikacja odbywa się poprzez protokół http lub
https.
9 BitTorrent (http://www.bittorrent.com/)
10 BitTorrent pozwala na udostępnianie wielu plików w ramach jednego zasobu.
11 Protokół wprowadza współczynnik udostępniania równy ilości danych pobranych przez innych
użytkowników, do danych pobranych przez peera.

12 Rozdział 1. Wprowadzenie
Zalety:
Wady:
• Platforma do udostępniania dużych zasobów, popularnych w sieci (np.
dystrybucje systemu Linux), co oszczędza pasmo udostępniającego i przyspiesza
proces pobierania przez zainteresowanych.
• Prosty do zaimplementowania.
• Administrator obserwatora ma pełny dostęp do informacji na temat pobierających
zasób.
• Zoptymalizowany pod względem wykorzystania pasma.
• Mogą służyć do udostępniania treści niezgodnych z prawem.
• Trudne do wyszukania.
1.4.2 Anonimowe połączenia i trasowanie cebulkowe
Anonimowość w Internecie nie tyko jest jednym z najciekawszych zagadnień
współczesnej socjologi, ale również budzącym znaczne kontrowersje i obawy
pośród administratorów sieci komputerowych. Dla użytkownika sieci anonimowość
oznacza, że jest on w stanie wykonać pewne operacje wywierające wpływ
na otoczenie (np. wysłanie wiadomości, rejestracja w serwisie internetowym
itp.) i jednocześnie pozostanie on pewny, że wykonanie tych operacji nie pozwoli
ustalić jego tożsamości. Jako przykład z prawdziwego życia możemy
wyobrazić sobie zakupy w sklepie. Kupując w miejscu, gdzie nikt nas nie zna i
płacąc gotówką, istnieje małe prawdopodobieństwo tego, że ktoś będzie w stanie
ustalić naszą tożsamość bez posiadania dodatkowych informacji na nasz temat.
Anonimowość jest cennym towarem więc wiele osób jest w stanie udostępnić
swoje zasoby uzyskując w ten sposób poczucie nierozpoznawalności. Jedna z
technik, która pozwala uzyskać anonimowość w sieci Internet jest trasowanie
cebulkowe (ang. onion routing). Jego realizacja wymaga użycia systemu peerto-peer
12 .
Trasowanie cebulkowe. Zakładamy, że każdy użytkownik posiada klucz publiczny
i klucz prywatny dla kryptografii z kluczem publicznym [RSA77, MVO96].
Klucz publiczny udostępniony jest dla każdego użytkownika. Chcąc nawiązać
połączenie użytkownik buduje tzw. cebulkę, losując kolejno uczestników do
12 Trasowanie cebulkowe realizowane jest przez oprogramowanie TOR, które wchodzi w skład
projektu FreeHaven (http://www.freehaven.net/).

1.4 Zastosowania sieci peer-to-peer 13
Entry
funnel
Exit
funnel
Service
Rysunek 1.2: Poglądowa architektura systemu wspierającego anonimowe połączenia.
stworzenia tunelu. Budowa cebulki zaczyna się „od końca”, czyli najpierw szyfrowany
jest cel połączenia kluczem publicznym ostatniego węzła. Następnie adres
ostatniego węzła jest szyfrowany kluczem publicznym przedostatniego węzła
itd. (P k−1 (P k(...) , addr k ),P k – szyfrowanie z kluczem publicznym dla węzła k,
addr k - adres węzła k). Po utworzeniu cebulki użytkownik wysyła ją do pierwszego
węzła, on odszyfrowuje swoją część i odczytuje adres kolejnego węzła, z
którym nawiązuje połączenie i wysyła do niego cebulkę. Oczywiście cały mechanizm
wymaga istnienia protokołu nadzoru nad działającym połączeniem. Problemem
może wydawać się konieczność posiadania kluczy publicznych węzłów,
które zostaną użyte w tworzeniu połączenia. Rozwiązanie problemu dostępności
kluczy dostarcza mechanizm rozproszonych tablic z kodowaniem mieszającym
omówiony w kolejnym rozdziale. Poglądowy schemat systemu realizującego
trasowanie cebulkowe pokazano na rys. 1.2.
Pierwszy węzeł, do którego wysyłana jest cebulka nazwano lejkiem wejściowym
(ang. entry funnel), natomiast ostatni węzeł oznaczony jest, jako lejek
wyjściowy (ang. exit funnel). Czytelnik odnajdzie szczegóły na temat trasowania
cebulkowego w [SGR97, DMS04] oraz inne podejście do zagwarantowania
anonimowości zaimplementowane w systemie Tarzan [FM02].
Zalety:
Wady:
• Daje możliwość nawiązywania połączeń, które nie są w łatwy sposób możliwe
do zrekonstruowania, gwarantując anonimowość inicjatora komunikacji.
• Ostatni węzeł w tunelu może zostać pociągnięty do odpowiedzialności za
wykonane operacje, gdyż z poziomu usługi, on jest inicjatorem połączenia.

14 Rozdział 1. Wprowadzenie
Proxy
Beacon
Beacon
Service
Beacon
Proxy
Rysunek 1.3: Poglądowa architektura systemu maskującego usługę.
• Utrudnia wykrycie nadużyć w postaci ataków na systemy komputerowe i
rozsyłania spamu.
1.4.3 Maskowanie usługi
Maskowanie usługi SOS (ang. Security Overlay Services) [KMR02] jest techniką,
która pozwala kontrolować obciążenie chronionego serwisu. Realizacja
techniki podobnie jak w przypadku anonimowych połączeń wymaga użycie systemu
peer-to-peer. Elementy SOS:
• Przekaźnik (ang. proxy) - jest punktem dostępowym znanym użytkownikom.
• Znacznik (ang. beacon) - jest łącznikiem między usługą a przekaźnikiem
bezpośrednio wybieranym przez usługę.
Pewne węzły w systemie peer-to-peer działają jako dobrze znane punkty
dostępowe (przekaźniki), w których rejestrują się znaczniki, wybierane przez
usługę spośród węzłów sieci. Przekaźniki nie mają wiedzy o położeniu usługi,
zatem cały ruch kierują do znaczników. Gdyby, któryś ze znaczników został
uszkodzony, to usługa może wybrać nowy spośród innych węzłów sieci. Liczba
przekaźników może ulegać zmianie i dostosowywać się do bieżącego obciążenia.
Zalety:
• Równoważenie obciążenia.
• Przeciwdziałanie atakom typu DoS.

1.4 Zastosowania sieci peer-to-peer 15
Wady:
• Zmniejszanie możliwości ataków poprzez maskowanie położenia usługi.
• Zmniejsza wydajność usługi.
• Mogą służyć do zamieszczania treści i usług niezgodnych z prawem.
W tym rozdziale chciałem wprowadzić czytelnika w tematykę związaną z
systemami peer-to-peer. Na wstępie przedstawiłem niechlubne pochodzenie tej
klasy oprogramowania, jak również bieżące kierunki jego rozwoju. Przedstawiłem
problemy bezpieczeństwa, które stanowią podstawowe zagadnienia podczas
projektowania aplikacji peer-to-peeroraz przykłady nietypowych zastosowań, takich
jak trasowanie cebulkowe i maskowanie usługi.

Rozdział 2
Architektury systemów peer-to-peer
Rozdział ten przedstawia obecną taksonomię systemów peer-to-peer i podstawy
teoretyczne zastosowane do ich konstrukcji. W pierwszej kolejności zostaną
omówione nieustrukturalizowane systemy peer-to-peer (up2p) (ang. unstructured
peer-to-peer systems), które są często praktycznie stosowane ze względu na ich
prostą budowę i spore doświadczenie projektowe. Drugim omówionym typem
systemów będą ustrukturalizowane systemy peer-to-peer (sp2p) (ang. structured
peer-to-peer systems), których cechą charakterystyczną jest brak jakichkolwiek
punktów centralnych oraz silne podstawy teoretyczne wykorzystane do ich konstrukcji.
Systemy peer-to-peer zostały w naturalny sposób podzielone na dwie grupy.
Pierwszą stanowią systemy nieustrukturalizowane, w których struktura grafu
sieci, jaki tworzy się poprzez dołączanie i odłączanie poszczególnych uczestników
jest dowolna, poza tym dopuszcza się istnienie tzw. super węzłów, które
są punktami przyłączenia oraz organizują komunikację węzłów uczestniczących.
Sposób określania, który z uczestników zostanie super węzłem odbywa się różnie,
bądź to w drodze wolontariatu, bądź za sprawą głosowania.
Interesujące z teoretycznego punktu widzenia wydają się być systemy ustrukturalizowane,
których budowa opiera się na specjalnie opracowanych algorytmach
trasowania w przestrzeni adresów węzłów. Takie systemy mają określoną
strukturę grafową sieci, która charakteryzuje się niską najdłuższą ścieżką oraz
wysokim współczynnikiem podziału na tzw. klastry. Pracą godną polecenia, badającą
aspekty teoretyczne tego typu sieci jest publikacja D. Loguinov i innych
[LKRG03].
Przytoczę roboczą definicję systemów peer-to-peer, która ma tą podstawową
wadę, iż jest restrykcyjna i dyskwalifikuje pewne systemy, które mogłyby być
też uważane jako systemy peer-to-peer. Dalej podam prostszą definicję, jednak
na tyle ogólną, że pozwala podciągnąć pod systemy peer-to-peer wiele innych
systemów, które niekoniecznie można za takie uważać.

18 Rozdział 2. Architektury systemów peer-to-peer
Systemy peer-to-peer są to systemy rozproszone, w których oprogramowanie
uruchomione na każdym węźle spełnia podobne funkcje, a komunikacja
jest symetryczna. Węzły mają swobodę przyłączania i odłączania od systemu.
Przyjęta definicja pochodzi z pracy D. Liben-Nowella i innych [LNBK02],
w której przedstawiono próbę analizy dynamicznych aspektów systemu Chord
[SMK + 01]. Takie określenie, czym są systemy peer-to-peer nie jest wystarczająco
ogólne, gdyż nie pozwala na zaklasyfikowanie, np. systemów nieustrukturalizowanych,
jako systemów peer-to-peer. W up2p dopuszcza się istnienie węzłów
o specjalnym przeznaczeniu, co z kolei sprawia, że te systemy nie są całkowicie
rozproszone, a komunikacja nie w każdym przypadku jest symetryczna. Bardziej
ogólne sformułowanie przedstawiam poniżej:
Systemy peer-to-peer są to systemy rozproszone, w których
podobne oprogramowanie uruchomione na każdym węźle,
komunikuje się bezpośrednio i wspólnie realizuje zadania.
Prostsza definicja jest z kolei niewystarczająca i ma za dużo niedopowiedzeń.
Po pierwsze komunikacja bezpośrednia niekoniecznie neguje istnienie komunikacji
w modelu master-slave, który zakłada podrzędność przy wykonywaniu
zadań, a w systemach peer-to-peer takiej podrzędności nie ma. Komunikacja
odbywa się raczej w modelu master-master, jeżeli wogóle jest to dobre określenie.
Systemy peer-to-peer, wprowadzają zupełnie nowy model komunikacji,
gdzie każdy węzeł może być zleceniodawcą i zleceniobiorcą. Sposób ustanowienia
kanału komunikacyjnego między węzłami w systemach peer-to-peer jest
pozbawiony znaczenia, gdyż połączenie może powstać w sposób dowolny, nawet
używając punktów pośrednich, tak jak odbywa się to w sieciach ustrukturalizowanych.
O poprawnym zaklasyfikowaniu systemu, jako systemu peer-to-peer decydują
pewne swoiste cechy, takie jak skala, swoboda przyłączania i odłączania
się, dążenie do ustanowienia komunikacji bezpośredniej między poszczególnymi
węzłami oraz samoorganizacja ich struktury, co jest cechą nową w stosunku do
wielu istniejących systemów 1 .
Poziom ogólnegnych zastosowań systemów peer-to-peer możemy podzielić
na trzy grupy [DZDS03]:
DHT - rozproszone tablice z kodowaniem mieszającym (ang. distributed
hashing tables)
DOLR - lokalizację obiektów i trasowanie (ang. distributed object location
and routing)
1 Oczywiście wymienione cechy nie stanowią wszystkich: charakterystyczny jest również,
wszechobecny brak zaufania między węzłami, duża awaryjność poszczególnych elementów, konieczność
stosowania technik kryptograficznych itp.

19
Overlay level
A
B
C
TCP
TCP
TCP
Network level
Rysunek 2.1: Dwie warstwy komunikacyjne oraz routing na poziomie aplikacji.
CAST - usługi komunikacji grupowej i rozgłaszania (ang.
multicast, anycast)
broadcast,
Należy zauważyć, że lokalizacja obiektów da się sprowadzić do pierwszego
zastosowania, gdyż każdemu obiektowi możemy nadać unikalny identyfikator
i umieścić parę w rozproszonej tablicy z kodowaniem
mieszającym. Trudniejszą funkcjonalnością do praktycznej realizacji jest
rozgłaszanie, gdyż wymaga mechanizmów tworzenia i utrzymywania grupy komunikacyjnej.
Lokalizacja w przypadku rozgłaszania również może zostać użyta
podczas realizacji, jednak wymagane staje się utworzenie dodatkowych mechanizmów
zarządzania grupą i przesyłania komunikatów. Gdy rozpatrujemy architektury
rozgłaszania o niewielkiej liczbie członków w grupie, powinno dążyć się
do lokalizacji poszczególnych uczestników i zgromadzenia ich adresów sieciowych,
by komunikacja miała charakter bezpośredni. W przypadku dużych grup
postępuje się inaczej, a mianowicie buduje się drzewa komunikacyjne w obrębie
systemu peer-to-peer podobnie, jak zostało to zrobione w systemie komunikacji
grupowej Scribe [CDKR02].
Komunikacja w systemach peer-to-peer odbywa się na dwóch poziomach.
Pierwszy poziom to poziom powłoki (warstwy) (ang. overlay level), gdzie komunikaty
przesyłane są od węzła do węzła używając trasowania w warstwie aplikacji.
Drugi poziom stanowi warstwa sieci (ang. network level). W warstwie
sieci komunikacja odbywa się w sposób bezpośredni między węzłami używając
standardowego protokołu np. TCP/IP (rysunek 2.1).

20 Rozdział 2. Architektury systemów peer-to-peer
2.1 Nieustrukturalizowane systemy peer-to-peer
Powstanie tego typu systemów wywodzi się od pierwszych sieci wymiany plików:
Napster oraz Gnutella. Na bazie tych aplikacji powstało wiele unowocześnionych
i zaprojektowanych od początku systemów wymiany plików. Zainteresowanie
świata naukowego oraz komercyjnego tymi systemami pojawiło się ze względu
na ich skalowalność, odporność na działania intruzów, a może również i rozgłos,
który towarzyszył rozprawie przeciwko firmie NullSoft wytoczony przez
agencję RIAA. Z czasem zaczęły pojawiać się tzw. szkielety (ang. peer-to-peer
frameworks), jako narzędzia do budowy rozproszonych aplikacji przy użyciu
sieci peer-to-peer. Wymienię tutaj dwa wiodące komercyjne projekty: Sun Microsystems
JXTA 2 i Microsoft P2PSDK 3 .
Schemat grafu nieustrukturalizowangeo systemu peer-to-peer, może wyglądać,
tak jak przedstawiono na rysunku 2.2. Ilustracja pokazuje rejestrację zawartości
z przez węzeł k oraz próbę jej lokalizacji przez węzeł a:
1. Węzeł k rejestruje zawartość z w super węźle i.
2. Węzeł a zadaje pytanie super węzłowi c ozawartośćz z parametrem TTL 4
równym 1.
3. Super węzeł c stwierdza, że nie ma zawartości z i przesyła zapytanie do
f i g z TTL równym 2.
4. Węzły f i g również nie znają położenia z więc podbijają TTL i przesyłają
zapytanie do i.
5. Węzeł i odpowiada bezpośrednio do a lub przez super węzły, oznajmujący,
że zawartość z znajduje się u k.
Super węzły w celu zlokalizowania zawartości z rozsyłają między sobą zapytanie
stosując np. protokół plotkarski (ang. gossiping protocol) [CRB01].
Równie dobrze możnaby posłużyć się protokołem plotkarskim bezpośrednio, bez
użycia super węzłów. Niestety takie postępowanie ograniczyłoby skalowalność
sytemu. Na podobny problem natknęli się twórcy Gnutelli, która przestała funkcjonować
ze względu na problemy wydajnościowe.
2 JXTA (http://www.jxta.org)
3 P2PSDK (http://msdn.microsoft.com/library/en-us/p2psdk/p2p/
portal.asp)
4 Time To Leave - parametr oznacza odległość od źródła w skokach. Przy pewnej wartości
progowej, zapytanie nie jest już dalej rozsyłane. Parametr TTL w podobnej postaci jest używany
w stosie protokołów TCP/IP.

2.2 Ustrukturalizowane systemy peer-to-peer 21
e
h
b
f
a?(z#3)
k!z
k
a
a!(z@k#3)
a?(z#2)
a?(z#3)
a?(z#3)
i
a?(z#1)
c
a?(z#2)
g
j
Super węzeł
Węzeł uczestniczący
Rysunek 2.2: Przykład lokalizacji obiektu w nieustrukturalizowanej sieci p2p
2.2 Ustrukturalizowane systemy peer-to-peer
Systemy tej klasy zrodziły się z prób wprowadzenia klarownych reguł dotyczących
przesyłania komunikatów na poziomie aplikacji. Celem twórców było
wskazanie takich algorytmów i architektury, które byłyby skalowalne oraz zapewniały
stabilność bez wyznaczania nadrzędnych elementów. Ustrukturalizowane
systemy peer-to-peer są w pełni rozproszone, brak w nich centralnych punktów
komunikacyjnych i zarządzania.
Problemem, jak dotąd jest stanowczo za mała ilość praktycznych i powszechnie
używanych implementacji, a co za tym idzie, nie są to twory zoptymalizowane
i brakuje konkretnych danych testowych dotyczących ich wydajności i
odporności. Wraz z wzrostem rozproszenia wzrasta również ryzyko na ataki w
tych systemach. Ogólna zasada przy projektowaniu wszelkich elementów systemów
bazujących na ustrutkturalizowanych sieciach peer-to-peer, to unikanie
centralnych punktów odpowiedzialności.
Liczących się projektów ustrukturalizowanych warstw peer-to-peer jest kilkanaście.
Do najczęściej wymienianych w literaturze i z praktycznymi zastosowaniami,
zaliczają się cztery pozycje: Chord [SMK + 01], Pastry [RD01b],
Tapestry [ZHS + 03] oraz CAN - Content Addressable Network [RFH + 00]. Wymienione
systemy wraz z Kademlia [MM02] stanowią fragment projektu IRIS
(ang. Infrastructure for Resilient Internet Systems) 5 .
5 Iris (http://project-iris.net/projects.html)

22 Rozdział 2. Architektury systemów peer-to-peer
Chord. Opracowany w MIT. Każdy węzeł posiada tablicę wskazań na 160
innych węzłów w przestrzeni identyfikatorów modulo rozmiar przestrzeni.
Przekazywanie komunikatów odbywa się w jednym kierunku. Oczekiwana
1
liczba skoków: log 2 2N, gdzie N oznacza spodziewaną liczbę węzłów w
systemie. Przykładem realizacji oprogramowania opartego na sieci Chord
jest CFS - Cooperative File System, który jest rozproszonym systemem
plików przeznaczonym dla dużych intersieci.
Pastry. Opracowany w Rice University. Przesyłanie komunikatów odbywa
się za pomocą specjalnie przygotowanej tablicy tras, której wskazania w
przestrzeni identyfikatorów koncentrują się w bezpośrednim sąsiedztwie
węzła. Oczekiwana liczba skoków: alog 2 bN, gdzie b jest parametrem,
przeważnie b =4oraz a jest stałą.
Tapestry. Opracowany w Berkeley California University. System ten
działa na podobnych zasadach, jak Pastry. Główna różnica znajduje się w
algorytmie routingu, oraz tym, że Tapestry nie korzysta z lokalności węzłów.
Adres skoku w Tapestry ustalany jest przy użyciu operacji mod 2 b na
identyfikatorach węzłów zgodnych prefiksem adresu docelowego o kolejne
słowo. Ta procedura nazwana została trasowaniem surogatowym (ang.
surogate routing) [ZHS + 03, CDG + 02] lub trasowaniem hiperkostkowym
(ang. hipercube routing) [ADS02]. Oczekiwana liczba skoków: log 2 bN.
CAN (ang. Content Addressable Network). Opracowany w Berkeley California
University. Logiczny adres w przypadku tego systemu dzielony jest
na d odcinków. Każdy wpis w tablicy tras posiada d sąsiadów, najbliższych
względem każdego odcinka. Oczekiwana liczba skoków: 1 2 dN 1 d .
2.2.1 Przestrzeń identyfikatorów
Zarówno w sieciach typu up2p oraz sp2p każdy z węzłów posiada unikalny
całkowitoliczbowy identyfikator, który pochodzi z wcześniej ustalonego zakresu
{0, ..., N}, gdzie N =2 n − 1. Różnica między up2p oraz sp2p polega na tym,
iż w up2p węzły mogą dowolnie się łączyć, co prowadzi do stworzenia sieci
o strukturze grafu losowego, za wyjątkiem jednoznacznego określenia węzła,
unikalny identyfikator nie ma tak dużego znaczenia w sieci up2p.
W systemach sp2p każdy węzeł dąży do nawiązania kontaktu z węzłami o
konkretnych identyfikatorach, co możliwe jest dzięki odpowiednim algorytmom
przyłączania i trasowania. Cenę za mniej obciążające wyszukiwanie węzłów
płaci się w postaci konieczności utrzymywania struktury sieci.
Rozważmy dla przykładu hipotetyczny system peer-to-peer, w którym węzły
otrzymują pod jurysdykcję podzbiór adresów z całej przestrzeni adresów N.

2.2 Ustrukturalizowane systemy peer-to-peer 23
0
k 1
u 0
v
u
k 1
v
z
k 1
0
u
v
k 2
k 2
k 2
Rysunek 2.3: Operacje na przestrzeni adresów wykonywane przez hipotetyczny
system sp2p.
1. W pierwszym kroku do systemu włącza się węzeł v o dowolnym identyfikatorze
v id . Ponieważ nie ma innych węzłów w systemie, jest on odpowiedzialny
za obiekty z całej przestrzeni adresowej N.
2. W drugim kroku do systemu włącza się kolejny węzeł u. Mogą zaistnieć
trzy sytuacje. Pierwsza u id >v id w tym przypadku węzeł v dzieli
przestrzeń na dwie połówki, w ten sposób, że najpierw ustalane są końce
przedziałów k 1 ,k 2
k 1 = v id + u id − v id
2
k 2 = N + u id − v id
2
Dzięki temu pierwszy i drugi kraniec przedziału oddalony jest równo od
u i v. Następnie v oddaje pod jurysdykcję przedział identyfikatorów o
krańcach k 1 ,k 2 węzłowi u. W ten sposób oba węzły mają pod jurysdykcją
obszar tej samej wielkości. Drugi przypadek, to gdy u id

24 Rozdział 2. Architektury systemów peer-to-peer
uprzednio opisany przy czym k 2 staje się, którymś krańcem istniejącego
już przedziału. Dalsze podziały niekoniecznie dzielą obszar na dwie równe
części.
4. W miarę coraz większej liczby napływających węzłów liczba przedziałów
będzie rosła. Należy zatem ograniczyć najmniejszą możliwą długość przedziału
do stałej wartości, zależnej od N. Gdy węzeł przybędzie do sieci,
ajegoid przypadnie na przedział, którego nie da się podzielić, to nie
otrzyma on, żadnej przestrzeni pod swoją jurysdykcję z wyjątkiem obiektów
o identyfikatorze równym id. Węzeł będzie mógł przejąć przedział,
gdy węzeł, który się nim opiekuje odłączy się od sieci. Ten węzeł przejmie
przedział, którego id będzie najbliższe do id byłego właściciela.
5. Rozpatrzmy przypadek, gdy węzeł u odłączy się od systemu. Wtedy węzeł
v przejmie pod swoją jurysdykcję obszar, który był przypisany u. Oczywiście
ważne jest, by v zdawał sobie sprawę z istnienia węzła m, który
otrzymał pod swoją jurysdykcję inny obszar. Nakłada to wymóg, żeby
węzeł, który dzieli swój zbiór identyfikatorów przydzielając go przybywającemu
węzłowi informował o tej operacji węzeł, od którego otrzymał
obszar uprzednio.
Opisany powyżej system jest ustrukturalizowanym systemem peer-to-peer,
gdy dodatkowo zastosuje się dla niego odpowiedni algorytm routingu, uwzględniający
jakie węzły mają być utrzymywane w tablicy tras. Przykład nie pochodzi
z literatury i został opracowany na potrzeby tej pracy, chociaż przypomina on
CAN z parametrem d =2.
2.2.2 Trasowanie przedrostkowe
Esencją up2p jest zastosowanie w ich konstrukcji algorytmu trasowania Plaxtona
[PRR97] do nawigacji w przestrzeni identyfikatorów. Działanie algorytmu jest
bardzo proste. Bity identyfikatora węzła dzielone są na słowa o długości b. Gdy
węzeł odbierze komunikat, to sprawdza znane mu adresy węzłów i szuka takiego
węzła, którego identyfikator jest najbardziej zgodny w sensie przedrostka
z identyfikatorem odbiorcy. Jeżeli okazałoby się, że takich identyfikatorów jest
kilka, to wybierany jest ten, który jest najbliżej adresu docelowego. Musi być
spełniony jeszcze jeden warunek, by algorytm przekazywał komunikaty zawsze
w kierunku celu, a mianowicie tylko taka długość przedrostka jest dopuszczalna,
która jest większa od długości zgodnego przedrostka węzła odbierającego komunikat.
Czyli po odebraniu komunikatu węzeł najpierw ustala jak bardzo jego
identyfikator zgodny jest przedrostkiem z identyfikatorem celu. Koniec wę-

2.2 Ustrukturalizowane systemy peer-to-peer 25
drówki komunikatu następuje, gdy nie ma takiego węzła, do którego dałoby się
dalej przesłać komunikat lub odbiorca jest adresatem.
Przestrzenie identyfikatorów ustalane są dzięki przedrostkom, w tym przypadku
można mówić raczej o podziale na strefy. Wędrujący komunikat najpierw
trafia do strefy, gdzie identyfikatory zaczynają się od takiego samego słowa, jak
identyfikator docelowy, lub bliżej itd. Ogólnie odpowiada to sytuacji przedstawionej
na rysunku 2.4.
Pozostaje podać warunek na to by, wierzchołek był osiągalny z każdego
innego dowolnego wierzchołka w sieci stosując trasowanie przedrostkowe. Trasowanie
przedrostkowe nie wymaga, by graf sieć był określonego typu (patrz
Dodatek A), ale sposób połączenia wierzchołków musi spełniać warunek istnienia
cykli w obrębie stref. Warunek istnienia cykli oznacza to, iż musi istnieć
cykl przechodzący przez kolejne strefy jednego poziomu. Identyfikatory węzłów,
które posiadają połączenia należące do różnych stref muszą być graniczne,
tzn. węzeł o największym identyfikatorze w strefie posiada wskazanie do węzła
o najmniejszym identyfikatorze w strefie sąsiedniej i na odwrót. Oczywiście
istnienie połączeń możliwe jest tylko wtedy, gdy istnieją węzły przynależące do
danej strefy. Dla przykładu rozważmy najwyższe strefy z rysunku 2.4. Warunek
osiągalności będzie spełniony, gdy dla każdej pary stref o numerach następujących
po sobie, połączenia węzłów między tymi strefami utworzą cykl, czyli:
{0 → 1 → 0}, {1 → 2 → 1}, {2 → 3 → 2}, {00 → 01 → 00}, {01 → 02 →
01}, {02 → 03 → 02}, {10 → 11 → 10}, {11 → 12 → 11}, {12 → 13 → 12} ...
Dodatkowo wszystkie cykle muszą spełniać warunek, że kolejne wierzchołki w
cyklu połączone są monotonicznie (względem rosnących wartości adresów) i
krawędź prowadząca do innej strefy wychodzi z wierzchołka o najmniejszym
numerze i największym numerze w strefie.
Gdy komunikat jest wysyłany do węzła w obrębie tej samej strefy nadrzędnej,
to nie ma większego problemu z jego dostarczeniem. Jedyny warunek jaki
należy spełnić, to taki, by węzły posiadały połączenie między sobą w obrębie
strefy uwzględniając uporządkowanie identyfikatorów.
2.2.3 Rozproszone tablice z kodowaniem mieszającym
Postanowiłem poświęcić temu zagadnieniu cały podpunkt, gdyż jest to podstawowa
usługa, jaką dostarczają sieci peer-to-peer. Na jej podstawie możne
stworzyć wiele funkcjonalności implementowanych przez rozproszone aplikacje
sieciowe. Na czym polegają DHT i jak są realizowane w ustrutkuralizowanych
systemach peer-to-peer?
W ustrukturalizowanych systemach peer-to-peer używa się specjalnej funkcji,
którą nazywa się funkcją mapującą f k : N → N, odpowiada ona za wyznaczenie
adresu węzła odpowiedzialnego za dany obiekt tzw. replica root. Kolejną

26 Rozdział 2. Architektury systemów peer-to-peer
funkcją, jest funkcja replik f r : N → N, której działanie sprowadza się do wyznaczenia
kilku identyfikatorów węzłów odpowiedzialnych za obiekt o danym
identyfikatorze tzw. replica keys. Funkcja mapująca musi być deterministyczna
i wyznaczać jeden konkretny adres, natomiast funkcja replik niekoniecznie. W
praktyce jednak rzadko stosuje się funkcje mapującą i funkcję replik, chociaż
ich użycie poprawiałoby wydajność zapytań o konkretne obiekty.
Każdemu zestawowi danych (obiektów) możemy przypisać identyfikator id,
najlepiej z tej samej przestrzeni, z której pochodzą identyfikatory węzłów w
sieci, który dalej będziemy nazywali kluczem. Klucz skojarzony jest ze zbiorem
atrybutów, który go określa (np. dla pliku mogą to być poszczególne słowa
występujące w nazwie). Każdemu atrybutowi również możemy przypisać unikalny
identyfikator, gdyż atrybut również jest pewnym zestawem danych. Gdy
użytkownik wprowadza dane do systemu wykonuje operację:
put(lista atrybutów, dane)
W tym momencie dane zostały zapamiętane w systemie wraz z określoną
listą atrybutów. W rzeczywistym systemie odbywa się to tak, że dla każdego
atrybutu wyliczany jest jego identyfikator i węzeł o najbliższym identyfikatorze
do identyfikatora atrybutu zapamiętuje parę < a(i) id ,id >, natomiast węzły
których identyfikatory są najbliższe do id zapamiętują parę .
Użytkownik poszukujący danych podaje bezpośrednio id (sytuacja rzadka),
lub listę atrybutów (sytuacja, częsta), otrzymuje w ten w odpowiedzi listę adresów
dojść do danych odpowiadającą liście atrybutów, lub bezpośrednio dane
wskazane poprzez id. Operacja, która wykonuje zapytanie wygląda następująco:
lista danych = get(lista atrybutów)
W przypadku, gdy lista atrybutów, jest ograniczona do jednej unikalnej wartości,
to otrzymamy prostą tablicę adresowań. W innej sytuacji, gdy przyporządkowanie
jest typu jeden-do-wielu, czyli jeden klucz, dla kilku obiektów,
to usługa działa, jak tablica z kodowaniem mieszającym (ang. hashing table).
Do poprawnego działania pokazanego schematu wystarczy, aby klucz obiektu
był generowany jako wynik działania bezkolizyjnej funkcji skrótu na danych i
atrybutach.
Wymienione uprzednio podstawowe usługi realizowane na warstwie peer-topeer
prowadzą do ogólnej postaci interfejsu programistycznego zaproponowanego
w [DZDS03].
DHT DOLR CAST
put(key, data) publish(objectId) join(groupId)
remove(key) unpublish(objectId) leave(groupId)
data = get(key) sendToObj(msg, objectId, n) multicast(msg, groupId)
anycast(msg, groupId)

2.3 Architektura systemów Chord i Pastry 27
DHT oznacza rozproszone tablice z kodowaniem mieszającym, DOLR, to
rozproszona lokalizacja obiektów, CAST oznacza usługi rozgłaszania. Trudno
rozpatrzeć, czy zaproponowany zestaw operacji, jest wystarczający, na pewno
nie jest kompletny dla wszystkich typów zastosowań.
2.3 Architektura systemów Chord i Pastry
W każdym z opisywanych w tym rozdziale systemów mamy do czynienia z
pewną przestrzenią identyfikatorów (adresów, kluczy). Przestrzeń ta najczęściej
jest niczym innym jak podzbiorem liczb całkowitych 〈0, 2 n − 1〉 znacznie liczniejsza
niż przewidywana liczba węzłów uczestniczących w komunikacji. Węzeł
przyłączając się do systemu otrzymuje identyfikator z tej przestrzeni. Dla systemu
Chord, Pastry i Tapestry przyjęło mówić się o pierścieniu identyfikatorów,
chociaż tak naprawdę jedynie w przypadku Chord’a to stwierdzenie ma sens,
gdyż w tym systemie komunikaty wędrują zgodnie ze wzrastającymi wartościami
adresów, łącznie z przekroczeniem zera.
Chord. Każdemu węzłowi przypisywany jest unikalny identyfikator v id zpewnej
przestrzeni identyfikatorów N. Następnie węzeł v odnajduje swojego poprzednika
i następnika względem identyfikatora id, który istnieje w systemie. Chord
używa 160-bitowych identyfikatorów. W kolejnym kroku węzeł v szuka najbliższych
węzłów względem v id +2 i mod N 7 , gdzie i ∈{0, ..., L(N)}, czyli w
tym przypadku L(N) = 160, i zapamiętuje znalezione identyfikatory węzłów w
tablicy wskazań (ang. finger table). Chord stosuje procedurę odświeżania pierścienia
(ang. idealization), która odszukuje nowego poprzednika i następnika,
jak również uzupełnia wpisy w tablicy wskazań. Zgodnie z trasowaniem prefiksowym
po odebraniu komunikatu przez węzeł sprawdzane jest id odbiorcy i
komunikat przesyłany jest do najbliższego węzła względem identyfikatora, który
znajduje się w tablicy wskazań. Gdyby taki węzeł nie istniał, to komunikat dostarczony
jest do aplikacji i ona podejmuje decyzję, czy został on poprawnie lub
błędnie odebrany.
Pastry. Podobnie, jak w systmie Chord, węzły oznaczone są unikalnymi identyfikatorami.
Każdy węzeł v w Pastry utrzymuje trzy pod-tablice routingu. Pierwsza
została nazwana tablicą liści (ang. leaf set), w której węzeł przechowuj adresy
innych węzłów, których identyfikatory znajdują się w jego otoczeniu (jest to
przedział o krańcach równych v id ± l/2, gdzie L jest parametrem, a v id jest identyfikatorem
węzła v. Liczba węzłów przechowywana w tablicy liści jest zależna
od parametru l. Kolejną jest tablica routingu (ang. route set), która ma log 2 b N
7 Ze względu stosowania operacji dzielenia modulo Chord zasługuje na miano pierścienia.

28 Rozdział 2. Architektury systemów peer-to-peer
Pastry, b=2
v = 0112
0
00 01 02 03
0 1 2 3
2 n - 1
Rysunek 2.4: Wskazania tablicy routingu węzła v na różne framgenty przestrzeni
adresowej w systemie Pastry dla n =8i b =2.
wierszy oraz 2 b kolumn. W wierszu r gromadzi się adresy węzłów, których
identyfikator ma r wspólnych słów o długości b z identyfikatorem v. Kolumna
c ∈{0, ..., 2 b − 1} zawiera identyfikatory z r +1 słowem równym c. Na rysunku
2.4 umieszczono ilustrację wskazań tablicy routingu dla hipotetycznego systemu
Pastry. Charakterystyczne jest, że w Pastry liczba połączeń w sąsiedztwie węzła
rośnie, natomiast w kierunkach dalszych połączeń jest znacznie mniej. Trzecia
tablica nosi nazwę tablicy sąsiadów neighbour set. Sąsiadami oznaczone są te
węzły, które bliskie są węzłowi v używając innej metryki niż tej określonej na
przestrzeni identyfikatorów. Na przykład miarą stosowaną dla tablicy sąsiedztwa
może być odległość w sensie czasu przesyłania komunikatu. Tablica sąsiadów
ma na celu przyspieszenie przesyłania komunikatów wykorzystując rzeczywiste
położenie węzłów w sieci fizycznej.
2.3.1 Algorytm routingu
W ustrukturalizowanych systemach peer-to-peer komunikaty zawsze wędrują poprzez
kilka węzłów. Budzi to uzasadnione obawy, gdyż możemy łatwo wyznaczyć
prawdopodobieństwo p tego, że komunikat zostanie poprawnie dostarczony,
gdy f-ta część węzłów nie działa prawidłowo. Wyraz na prawdopodobieństwo
przyjmuje postać p =(1−f) h , gdzie h oznacza liczbę skoków (hops) jakie musi
wykonać komunikat, by dotrzeć do celu. Jeżeli operujemy w systemie ustrukturalizowanym,
gdzie maksymalna liczba skoków często wyrażana jest przez
a · log 2 bN, gdzie a oraz b to parametry, a N to liczba węzłów uczestniczących
w komunikacji, to p =(1− f) a·log 2 bN . Czyli już dla N =10 6 i b =4, p może
być dosyć małe nawet przy niewielkim f. Rozwiązanie tego problemu wymaga
zastosowania technik bezpiecznego trasowania oraz proaktywnego usuwania niepoprawnie
działających węzłów.

2.3 Architektura systemów Chord i Pastry 29
Routing w Pastry. Niech L oznacza zbiór liści, R tablicę routingu, N zbiór
sąsiadów, d identyfikator węzła docelowego, l ∈ L identyfikatory węzła należącego
do zbioru liści, p(a, b) wspólną długość w znakach współdzieloną między
identyfikatorem a i b, R j i , wpis w tablicy routingu dla kolumny i oraz wiersza
j, d(k) będzie k-tym znakiem w identyfikatorze k.
Każdy węzeł a odbierając komunikat zaadresowany do d wykonuje następujące
kroki:
Jeżeli d ∈ L, to przekaż d do arg min l∈L |d − l|
Niech k = p(a, d). Jeżeli R k d(k) nie jest puste, to przekaż komunikat do
R k d(k) , w przeciwnym razie przekaż komunikat do węzła t ∈ L ∪ R ∪ N
dla, którego spełnione jest p(t, d) ≥ k i |t − d| < |a − d|
Jeżeli adresat należy do zbioru liści, to komunikat zostanie przekazany do
węzła, którego id jest najbliższe względem celu. Gdy adresat jest spoza zakresu
węzłów należących do zbioru liści, to przeglądana jest tablica routingu i wybierany
jest wpis, w którym identyfikator jest najbardziej zgodny przedrostkiem z
celem, o ile takowy istnieje. W innym przypadku przeszukiwane są wszelkie
dostępne zbiory identyfikatorów i jako kolejny skok wybierany jest taki węzeł,
którego cześć wspólna przedrostka identyfikatora zgodna jest przynajmniej tak
dobrze jak węzła, który odebrał komunikat, a odległość od celu określona używając
miary euklidesowej jest mniejsza.
2.3.2 Przyłączanie do systemu
Zilustruję działanie routingu w ustrukturalizowanych sieciach peer-to-peer na
przykładzie przyłączania więzła o identyfikatorze ′ x ′ − 1330 do systemu miniPastry.
Różnica między miniPastry, a Pastry polega na tym, że przestrzeń
identyfikatorów została ograniczona do 2 7 −1. Identyfikatory mogą przyjmować
postać znaków w kodowaniu ASCII, stąd id węzła oznaczono ′ x ′ , czyli 1330 w
zapisie czwórkowym. Na rysunku 2.5 znajduje się tablica trasowań dla węzła
′ W ′ . Dla przypomnienia tablica trasowań w Pastry podzielona jest na trzy części,
pierwsza część gromadzi adresy z bezpośredniego otoczenia, druga część zbiera
adresy w różnych podprzestrzeniach pierścienia (w i-tym wierszu znajdują się
adresy zgodne co do i słów z adresem węzła, dla którego jest tablica, w j-tej
kolumnie znajduje się adres z j tym słowem zgodnym, i oraz j numerowane są
od zera), a trzecia przechowuje wskazania na węzły będące w sąsiedztwie np.
względem metryki. Niech długość słowa w adresie wynosi b =2(stąd zapis
czwórkowy).

30 Rozdział 2. Architektury systemów peer-to-peer
WEZEL W - 1113
t
x
z
2 7 -1
j(x)
S 1103
T 1110
ZBIÓR LISCI
U 1111
X 1120
V 1112
Y1121
ZBIÓR TRAS
Z 1122
[ 1123
W
j(x)
j(x)
x
(sp) 0200
B 1002
R 1102
T 1110
###
###
###
U 1111
} 2001
###
[ 1123
V 1112
###
t 1320
_ 1133
###
0
? 333
ZBIÓR SASIADÓW
###
` 1200
~ 2002
L 1030
### q 1311
###
Rysunek 2.5: Przykład przyłączania do sieci miniPastry
Przyłączanie odbywa się przez węzeł 0. Gdy węzeł x oznajmi chęć przyłączenia
węzłowi 0 ten wysyła specjalny komunikat j(x) w kierunku otoczenia x.
Każdy z węzłów biorący udział w komunikacji odsyła swoją tablicę trasowań do
x, tak że x jest w stanie zbudować własną tablicę trasowań.
Węzeł W po otrzymaniu j(x) sprawdzi swoją tablicę liści i stwierdzi, że nie
ma w niej x dlatego następnie sprawdzi tablicę tras najpierw określając dla ilu
początkowych słów adres x zgadza się z jego własnym adresem, czyli tylko
pierwsze słowo z adresu będzie zgodne z adresem celu, dlatego węzeł W wybierze
wiersz pierwszy (1). Dalej W sprawdzi kolejne słowo adresu x w celu
określenia odpowiedniej kolumny. Wartość słowa na drugiej pozycji to trzy (3),
zatem należy wybrać trzecią kolumnę (czwartą, gdy liczymy od zera). Znajduje
się tam wpis t i on stanie się docelowym punktem, dla komunikatu. Tablica sąsiadów
w Pasty przechowuje wskazania na węzły najbliższych w sensie metryki
dla warstwy sieci (np. czas przesłania komunikatu używając protokołu UDP).
Rodzaj metryki dla tablicy sąsiadów może być różnie określony w zależności od
zastosowania, np. może być to metryka względem czasu przesyłania komunikatu
lub odległości liczonej w skokach. Węzeł W powinien sprawdzić po określeniu
punktu docelowego, czy żaden inny węzeł w tablicy sąsiadów nie leży również
blisko celu, w ten sposób można próbować przyspieszyć przesłanie komunikatu.
2.4 Bezpieczeństwo w systemach peer-to-peer
W pierwszym rozdziale zostały zasygnalizowane problemy bezpieczeństwa, które
mogą wystąpić w systemach peer-to-peer. W tym paragrafie zostaną one ponow-

2.4 Bezpieczeństwo w systemach peer-to-peer 31
nie omówione z szczególnym uwzględnieniem charakterystyki systemów up2p
bez rozpatrywania problemów dotyczących konkretnych zastosowań, takich jak
udostępnianie plików, itp.
2.4.1 Klasyczne problemy bezpieczeństwa
Każda grupa aplikacji, która działa w środowisku otwartym, takim jakim jest sieć
Internet powinna spełniać pewne podstawowe usługi bezpieczeństwa [MVO96]:
• Integralność danych - zawartość komunikatów powinna być możliwa do
weryfikacji, tak by można było ustalić czy podczas przesyłania komunikat
nie został on zmodyfikowany.
• Niezaprzeczalność - powinna istnieć możliwość jednoznacznego określenia
nadawcy informacji. Nadawca nie powinien być w stanie wyprzeć się, że
wiadomość została nadana przez niego.
• Poufność - informacje powinny być możliwe do odczytania tylko przez
adresatów.
• Uwierzytelnianie - powinna istnieć możliwość weryfikacji tożsamości nadawcy.
Powyższe wymagania pozwalają spełnić klasyczne techniki kryptograficzne,
jednak z pewnym wyjątkiem. Niestety usługa niezaprzeczalnościi nie zawsze
jest możliwa do osiągnięcia, gdyż w systemach peer-to-peer rzadko stosuje się
weryfikowalne podpisy cyfrowe, a to z tego powodu iż przy tak dużej ilości
użytkowników jakikolwiek punkt centralnej weryfikacji stanowiłby wąskie gardło.
Często natomiast stosuje się techniki z kluczem publicznym bez zaufanej
strony trzeciej. Użytkownik wystawia certyfikat sobie sam, który wiąże jakieś
charakterystyczne informacje znane użytkownikowi z konkretną instancją aplikacji.
Można się zastanawiać, czy takie postępowanie jest cokolwiek warte? Przy
braku innych metod zapewnienia bezpieczeństwa, jest to przynajmniej jakaś metoda
prewencji.
Do problemów bezpieczeństwa występujących w systemach peer-to-peer z
powodzeniem można dołożyć jeszcze następujące:
• Ataki typu odmowy usługi - problemy z przyłączeniem do sieci. Zdarza
się, że węzeł nie chce przyłączyć użytkownika do sieci. W tym wypadku
najlepszym podejściem jest wybranie sobie innego punktu przyłączenia.
Brzmi to trywialnie, ale unikanie centralnych punktów porażki to podstawowa
technika walki z niepożądanym zachowaniem.

32 Rozdział 2. Architektury systemów peer-to-peer
• Zaśmiecanie - umieszczanie danych niezgodnych z przeznaczeniem. Niestety
idealnej metody walki z tym rodzajem zachowania nie opracowano.
Węzły czasem cenzorują treści wstawiając konkretnym danym oraz węzłom
poziomy zaufania. Prowadzi to do powstania sieci zaufania (ang.
web of trust) pomiędzy węzłami i w powiązaniu do konkretnych danych.
Duża ilość pozytywnych weryfikacji od różnych uczestników może poprawiać
nasze zaufanie danych, z którymi przyjdzie nam pracować. Podobna
technika stosowana jest w JXTA [CY01].
• Wstrzykiwanie wirusów - umieszczanie danych potencjalnie niebezpiecznych
w sieciach. Obrona stosowana w tym przypadku może uwzględniać
filtrowanie, podobne jakie stosuje się wobec spamu. Węzły mogą
współpracować w celu tworzenia sygnatury ataków i organizować wspólną
obronę wymieniając informację między sobą.
• Konie trojańskie - wprowadzanie zmodyfikowanych wersji oprogramowania,
które zawierają wirusy i oprogramowanie szperające typu (ang. spyware).
Użytkownicy powinni pobierać kolejne wersje oprogramowania
tylko z zaufanych źródeł i zawsze weryfikować sygnatury plików.
2.4.2 Nadawanie identyfikatorów
Bezpieczny przydział identyfikatorów jest podstawowym i najpoważniejszy problem
w systemach peer-to-peer. Identyfikatory nie powinny być generowane
przez użytkowników bez żadnych restrykcji. Wiąże się to z jednym z podstawowych
wymagań, które stwierdza, że w sieciach peer-to-peer identyfikatory węzłów
powinny być równomiernie rozprowadzone w systemie, tzn. żeby średnio
w każdej stefie była taka sama liczba identyfikatorów niezależnie od poziomu.
Kolejnym wymaganiem jest, by jeden klient nie był w stanie uzyskać kilku
identyfikatorów bliskich sobie. Gdyby się tak stało, to taki uczestnik może
bez problemu cenzorować ruch w sieci, lub nawet doprowadzić do rozspójnienia
warstwy peer-to-peerprzesyłając fałszywe informacje lub po prostu blokując cały
ruch przepływający przez węzły, które kontroluje.
Problem wielu „tożsamości” przypisanych do jednego użytkownika w literaturze
przedstawiono jako atak typu „Sybil” [Dou02].
Sybil to pseudonim Shirley Ardell Mason, która urodziła się 25 stycznia
1923 roku w Doge Center w Minnesocie. W wieku młodzieńczym trafiła do
psychiatry, dr Cornelii Wilbur, która stwierdziła u niej wielotożsamościowe zaburzenie
poczucia osobowości (ang. Multiple Personality Disorder). Sybil miała
16 różnych tożsamości, które ujawniały się u niej przemiennie lub równocześnie.
Jedynym rozwiązaniem problemu jest wydawanie identyfikatorów i certyfikatów
je potwierdzających przez centrum certyfikacyjne. Wielość tożsamości

2.4 Bezpieczeństwo w systemach peer-to-peer 33
może być użyteczna, gdyż na przykład, węzeł z kilkoma identyfikatorami z różnych
stref działa w ramach jednej instancji aplikacji przesyłając komunikaty. W
ten sposób, działa on, jak HUB skracający, drogę komunikatów w przestrzeni
identyfikatorów.
2.4.3 Przesyłanie komunikatów
Problem zapewnienia bezpieczeństwa przesyłanym komunikatom nie jest trywialny,
gdyż węzły nie wiedzą nic o sobie apriori, a przynajmniej kilka pierwszych
komunikatów wysyłanych gdy węzły chce nawiązać połączenie z innym
węzłem, podróżuje jako datagramy przechodząc przez punkty pośrednie. Ponadto
komunikaty mogą umyślnie być zatrzymywane i niszczone przez niepoprawnie
działające węzły pośredniczące. W pierwszym przypadku obrona jest
możliwa tylko wtedy, gdy węzły współpracują w obrębie jednej rozproszonej
aplikacji, która może mieć zaszytą pewną wspólną tajną informację, co z kolei
może posłużyć do szyfrowania zawartości komunikatów. Drugi problem rozwiązuje
się używając następujących technik: a) randomizacja węzłów używanych
do wysyłania komunikatu (ang. diverse routing) i trasowanie nadmiarowe (ang.
redundant routing) b) technika cofania i retransmisji (ang. backtrace) c)użycie
usztywnionych tablic trasowań [CDG + 02]. Trudność w stosowaniu tych technik
spowodowana jest brakiem komunikacji bezpośredniej oraz asymetrycznością
połączeń pośrednich (odpowiedź może wracać zupełnie inną drogą niż żądanie).
Czytelnika zainteresowanego szczegółami wymienionych technik odsyłam
do publikacji [CDG + 02].
2.4.4 Masowe przyłączanie i odłączanie
Atakujący, któremu udało się opanować dużą liczbę węzłów w systemie peerto-peer
może spróbować rozspójnić sieć. Jest to możliwe szczególnie wtedy,
gdy atakujący zdobył kontrolę nad węzłami których identyfikatory leżą blisko
siebie w przestrzeni identyfikatorów. Zakładając, że niemożliwa jest powyższa
sytuacja (np. istnieje w systemie mechanizm zarządzania identyfikatorami), pozostaje
do rozpatrzenia przypadek, gdy węzły odłączają się od systemu masowo.
Równomierne odłączanie węzłów z całej przestrzeni identyfikatorów nie spowodowałoby
awarii, o ile liczba węzłów nie przekroczyłaby pewnej wartości 8 .
Masowe wyłączenie węzłów bliskich sobie zdezorganizowałoby sieć a nawet
mogłoby doprowadzić do zniszczenia ej struktury.
Masowe przyłączanie może mieć również złe następstwa. Głównym problemem
z masowym przyłączaniem jest odświeżanie tablic trasowania przez
8 Niestety na chwilę obecną brak jest konkretnych danych prezentujących szacunkowe wyliczenia
współczynnika wrażliwości na odłączenia dla różnych systemów peer-to-peer

34 Rozdział 2. Architektury systemów peer-to-peer
węzły. W systemie takim jak Pastry, poprawnie wypełnione tablice trasowania
stanowią o poprawnym przekazywaniu komunikatów. Węzły przyłączające powinny
ograniczać szybkość przyłączania stosownie do obciążenia, ewentualnie
powinny stosować mechanizmy równoważenia obciążenia poprzez przekierowywanie
węzłów przyłączających do innych węzłów sieci i odpowiedni przydział
identyfikatorów.
Odłączanie replik może spowodować utratę danych dlatego koniecznym wydaje
się stosowanie replikacji opartej na algorytmach bezpiecznego uzgadniania,
przedstawionych w kolejnym rozdziale. Istotnym wymaganiem wobec algorytmów
replikacji w systemach peer-to-peerjest łatwa adaptacja do zmieniającego
się składu grupy replik i bezwzględny brak elementów centralnych.

Rozdział 3
Bezpieczne bizantyjskie uzgadnianie
Replikacja jest podstawową techniką stosowaną w DHT do utrzymania danych,
które zostały umieszczone w różnych węzłach systemu peer-to-peer pod odpowiednimi
kluczami. Wprowadzenie replikacji skutkuje podwyższeniem tolerancji
na uszkodzenia, jednak wiąże się z koniecznością synchronizacji danych
między replikami. W systemie, gdzie użytkownicy przyłączają się i odłączają w
losowy sposób, techniki replikacji stają się bardzo skomplikowane. Replikacji
można używać również w związku z różną popularnością obiektów dostępnych
w systemie, dzięki czemu te bardziej pożądane przez użytkowników będą szybciej
i łatwiej osiągalne. Problemy pojawiają się, gdy część replik zawodzi oraz
gdy nie możemy mieć zaufania do działania poszczególnych elementów systemu.
Heterogeniczność oprogramowania i częste umyślne działanie na szkodę systemów
informatycznych wymusza stosowanie takich algorytmów replikacji, które
nie tylko zadbają o atomowy dostęp do pożądanego obiektu, ale zagwarantują
poprawność uzyskanych danych. W systemach peer-to-peer odporność na przypadkowe
bądź złośliwe zachowanie jest koniecznością, gdyż nawet mała liczba
źle działających węzłów może spowodować utratę informacji.
Ten rozdział ma na celu analizę obecnie stosowanych algorytmów replikacji
usługi, które zapewniają tolerancję bizantyjskich uszkodzeń. Na wstępie został
opisany problem bizantyjskich generałów, który jest klasyczną ilustracją zagadnienia
i wprowadzeniem do problemu bizantyjskiego uzgadniania. Następnie
omówiono dwa algorytmy replikacji tolerującej błędy bizantyjskie, które stosują
całkowicie odmienne techniki, by ostatecznie osiągnąć podobny cel. Oba
przedstawione w tym rozdziale algorytmy nie były projektowane z myślą o systemach
słabo powiązanych, jednak stanowią dobrą bazę dla algorytmu, który
nadawałby się do zastosowania w systemach peer-to-peer. Próba opracowania
takiego algorytmu przedstawiona jest w następnym rozdziale.
Większa tolerancja uszkodzeń i maskowanie błędów w systemach rozproszonych
wymaga rozwiązania dwóch podstawowych problemów:

36 Rozdział 3. Bezpieczne bizantyjskie uzgadnianie
• Uszkodzenie/odłączenie repliki (ang. fail-stop behaviour). Replika przestaje
odpowiadać i dalsza komunikacja z nią jest niemożliwa. Replika
może zacząć ponownie odpowiadać.
• Niepoprawne działanie repliki (ang. byzantine behaviour). Replika zarówno
może przestać odpowiadać na zlecenia, jak również może wysyłać
komunikaty niezgodne z prawdziwym stanem usługi.
Technika tolerowania uszkodzeń replik typu fail-stop, wymaga zastosowania
mechanizmu odzyskiwania stanu (ang. state recovery) przez replikę, która uległa
awarii, oraz utworzenia nowej repliki, gdyby uszkodzona replika nie odzyskała
sprawności. Niepoprawne działanie repliki (celowe, bądź przypadkowe, np. wynikające
z ukrytych błędów implementacyjnych) jest poważniejszym problemem,
którego rozwiązanie musi uwzględniać wprowadzenie mechanizmu uzgadniania
stanu (ang. state agreement) oraz proaktywnego odzyskiwania stanu (ang. proactive
state recovery). Bardziej wnikliwe omówienie rodzajów niepoprawnych
zachowań elementów systemów, czytelnik znajdzie w książce A. Tanenbauma i
M. Van Steena [TS01].
Zagadnienie uzgadniania stanu rozdystrybuowanego pomiędzy R uczestników
zostało sformuowane, jako problem bizanyjskich generałów i od jego nazwy
pochodzi określenie bizantyjskiego modelu zachowania (ang. byzantine behaviour).
3.1 Problem bizantyjskich generałów
Nazwa zagadnienia wywodzi się z Bizancjum (Cesarstwo Bizantyjskie), wcześniej
wschodniej części Imperium Rzymskiego, państwa którego dzieje rozciągają
się od około IV wieku n.e., aż po zdobycie Konstantynopola w 1453 roku
przez Turków Osmańskich, która to data niejednokrotnie wskazywana jest, jako
koniec Średniowiecza. Schyłek (tzw. okres późnobizantyjski) istnienia cesarstwa
datuje się od końca 1204 roku, do wyżej wspomnianego zdobycia jego stolicy -
Konstantynopola. W okresie późnobizantyjskim dochodzi do rozbicia cesarstwa
na szereg rywalizujących ze sobą państewek (Cesarstwo Łacińskie, Cesarstwo
Nicejskie, Cesarstwo Epirskie, Cesarstwo Trapezuntu) oraz coraz mocniejszej
ingerencji sułtanów osmańskich w ich politykę. Zdrada stała się częstą przyczyną
porażek militarnych w walkach z najazdem tureckim.
Przykład. Czerwony generał wraz z wielką armią stacjonuje w dolinie 1 . Walczą
z nim czterej niebiescy generałowie, którzy okopali swoje pozycje na wzgórzach
1 Podany przykład pochodzi z książki A. Tanenbauma [TS01], jednak w tej pracy został
szerzej omówiony.

3.1 Problem bizantyjskich generałów 37
1
x 1
1
3
2
y
2
4
z
4
1
2
2
4 2
4
Krok 1- wymiana wartosci
1. (1,2,x,4)
2. (1,2,y,4)
3. (1,2,3,4)
4. (1,2,z,4)
Krok 2 – wymiana wektorów wartosci
1. (1,2,x,4) 2. (1,2,x,4) 3. (1,2,x,4) 4. (1,2,x,4)
(1,2,y,4) (1,2,y,4) (1,2,y,4) (1,2,y,4)
(a,b,c,d) (e,f,g,h) (1,2,3,4) (i,j,k,l)
(1,2,z,4) (1,2,z,4) (1,2,z,4) (1,2,z,4)
Rysunek 3.1: Problem bizantyjskich generałów. Trzech z czterech generałów
jest lojalnych, jeden jest zdrajcą. (a) Krok 1 - następuje wymiana informacji
o liczebności wojska między każdą z par generałów. (b) Krok 2 - generałowie
wymieniają między sobą wektory zawierające liczebność całej armii.
wznoszących się nad doliną. Ich celem jest ustalenie wielkości niebieskiej armii,
tak by określić, czy jest ona silniejsza od armii generała czerwonego, gdyż
jedynie połączony atak może przynieść zwycięstwo. Generałowie mogą komunikować
się między sobą, ale tylko rozłącznie, czyli tylko z jednym w tej samej
chwili, używając niezawodnych kanałów komunikacyjnych. Niestety między generałami
znajduje się jeden zdrajca, który został przekupiony przez czerwonego
generała.
W pierwszym kroku wszyscy k generałowie przesyłają parami nawzajem
liczebność swoich armii, tak, że każdy z nich po zakończeniu wymiany otrzymuje
wektor wartości, w którym i-ta ze współrzędnych odpowiada wielości armii i-
tego generała. Jeżeli zażyłoby się tak, iż i-ty z generałów odmawia przesłania
stanu armii w i-tym polu wprowadza się specjalną pustą wartość, np. NULL.
Kolejny krok polega na wymianie wektorów między generałami, tak, że ostatecznie
każdy z nich będzie posiadał k − 1 wektorów odebranych oraz jeden
własny. Jeżeli istnieje względna większość takich samych wartości w i-tym
elemencie w każdym z wektorów, to generał uznaje tą wartość za prawdziwą.
Na rysunku 3.1 przedstawiono sytuację, gdy jeden z generałów próbuje oszukać
pozostałych trzech. Przesyła w pierwszej kolejności do każdego z nich różne
wartości liczebności swojej armii. W drugim kroku przesyła dowolne wektory,
jako uzyskane po pierwszej turze. Każdy z generałów posiada armię wielkości
odpowiadającej jego numerowi, czyli 1, 2, 3 oraz 4 liczoną w kilo-żołnierzach.
W wyniku działania tego algorytmu każdy z lojalnych generałów posiada następujący
wektor wartości: (1,2,NULL,4).
Łatwo zauważyć, który z generałów okazał się być nielojalny, jednak gdyby
postępował on konsekwentnie, podając wszystkim lojalnym generałom taką samą,

38 Rozdział 3. Bezpieczne bizantyjskie uzgadnianie
niewłaściwą liczebność swojej armii, mógłby ich wprowadzić w błąd. Ten wniosek
jest niezwykle ważny, gdyż pokazuje, że przedstawiony algorytm zezwala na
uzgodnienie szeregu wartość (ang. byzantine agreement) wspólnie przez grupę
uczestniczącą w komunikacji, natomiast nie daje gwarancji poprawności dla tych
wartości! Milcząco zakładaliśmy, że generałowie znają liczbę zdrajców, gdyby
było inaczej problem stałby się jeszcze trudniejszy do rozwiązania. W takim
przypadku generałowie mogliby polegać jedynie na własnej armii, a uzyskanie
informacji o całkowitej liczebności wojsk byłoby niemożliwe.
Gwarant poprawności uzgodnionych wartości można uzyskać jedynie w takiej
sytuacji, gdy stosuje się replikację każdej z nich pomiędzy wielu uczestników i
tylko pod warunkiem, gdy działają oni niezależnie 2 . Zakładając, że atakujący nie
przejmie kontroli nad większością uczestników, jak również nie zdarzy się, że
większość uczestników zacznie działać niepoprawnie, uzgodniona wartość będzie
prawidłowa i poprawna. Sytuacja taka ma miejsce, gdy uzgadniana wartość jest
tylko jedna i dobrze określona, np. jest nią stan usługi, w przeciwieństwie
do przedstawionego przykładu, gdzie tych wartości jest znacznie więcej, bo aż
cztery. Ostatecznie możemy zadać pytanie, jak powinien zostać skonstruowany
algorytm, w którym mamy do czynienia z replikacją typu 1 do wiele oraz wiele
do wiele, czyli gdy wiele różnych wartości rozprowadzanych jest między wiele
replik.
Przypadek, gdy mamy do czynienia tylko z replikacją typu 1dowielerozwiązuje
algorytm odporności na błędy bizantyjskie BFT (ang. byzantine fault
tolerance) [CL99c, CL99a, CL99b, CL00]. Replikacja typu wiele do wiele z
uwzględnieniem zastosowania świadków realizowana jest przez algorytm bezpiecznego
przyczynowego rozgłaszania SC-ABC (ang. secure causal atomic
broadcast) [CKPS01, CKS00]. Oba algorytmy zostały opatentowane 3 .Zarówno
BFT, jak i SC-ABC są uważane przez ich autorów, jako asynchroniczne, chociaż
występują w nich konieczne elementy synchroniczności (patrz Dodatek B). W
przypadku BFT synchronizacja pojawia się w zastosowaniu widoków, pierwszy
raz użytych przez K. Birmana (ang. virtual synchrony) [TS01], w protokole
SC-ABC wykorzystano technikę losowego wykonania, co zostanie dokładniej
wyjaśnione w dalszej części tego rozdziału.
Całkowicie asynchroniczne algorytmy nie mogą zagwarantować, że uczestnicy
protokołu wspólnie dojdą do konsensusu, tak jak to zostało udowodnione
przez Fischera i innych [FLP85].
Twierdzenie 1 Nie istnieje taki protokół asynchronicznego uzgadniania P, który
gwarantowałby całkowitą poprawność, gdy chociaż jeden proces działa błędnie.
2 Dodatkowe repliki często nazwa się świadkami (ang. witness).
3 BFT jest objęty patentem międzynarodowym (nr US6671821 B1, 2003/12/30), SC-ABC jest
również objęty patentem międzynarodowym (nr US2002129087 A1).

3.2 Replikacja z uwzględnieniem błędów bizantyjskich 39
Dowód twierdzenia 1 jest niezmiernie ważny i ma podstawowe znaczenie
praktyczne, dlatego został zamieszczony w Dodatku B. Wniosek, który płynie z
tego twierdzenia, jest następujący: nie możemy projektować algorytmu uzgadniania,
który byłby pozbawiony, nawet w najmniejszym stopniu, komunikacji
synchronicznej między uczestnikami, gdyż dopuszczałby możliwość zaistnienia
sytuacji, w której nie zakończyłby on swojego działania.
Twierdzenie 2 Istnieje częściowo poprawny protokół uzgadniania, w którym
wszystkie poprawnie działające procesy podejmą decyzję, jeżeli tylko stanowią
większość i podczas operacji uzgadniania pozostaną sprawne.
BFT oraz SC-ABC rozwiązują problem uzgadniania w przypadku błędów bizantyjskich
stosując słabsze założenia niż w twierdzeniu 2, dzięki temu możliwe
jest poprawne zakończenie protokołu nawet gdy część uczestników przestanie
odpowiadać w trakcie jego realizacji. Na szczególną uwagę zasługuje algorytm
SC-ABC, który jest prawie całkowicie asynchroniczny, ale może nie zakończyć
poprawnie swojego działania. Przejścia między stanami w SC-ABC dokonują
się częściowo w losowy sposób, co w znacznej mierze utrudnia atakującemu
złamanie protokołu jednak teoretycznie zezwala na niepoprawne zakończenie
działania.
3.2 Replikacja z uwzględnieniem błędów bizantyjskich
Załóżmy, że grupa replik składa się z n uczestników i dostarcza deterministyczną
usługę u z wewnętrznym stanem s, która zwraca wartość v w zależności od
zlecenia i, v = u(i, s), s oznacza aktualny stan usługi. Usługa działająca w sposób
niedeterministyczny, np. optymalizacja przy użyciu metod heurystycznych
wymagałaby określenia progu zgodności zwracanych odpowiedzi. Ta praca rozpatruje
jedynie usługi deterministyczne. Rozpatrzenie przypadków gdy repliki
zwracają niedeterministyczne odpowiedzi mogłoby stanowić odrębne opracowanie
i nie będzie dalej poruszane. Klient c wysyła zlecenie do wszystkich replik
używając i c , jako parametru wywołania. Klient zbiera odpowiedzi v k od każdego
k-tego uczestnika grupy.
Twierdzenie 3 Jeżeli pośród n replik f jest działających w sposób bizantyjski,
to klient c potrzebuje f +1 takich samych odpowiedzi od różnych replik, by
ustalić poprawną zwracaną wartość v dla wywołania usługi u z parametrem i c .

40 Rozdział 3. Bezpieczne bizantyjskie uzgadnianie
Dowód. Załóżmy, że wystarczy f odpowiedzi by ustalić v. Wiedząc, że uszkodzonych
replik jest dokładnie f, to odebranie f takich samych odpowiedzi jeszcze
nie gwarantuje, że posiadamy prawdziwy wynik wywołania usługi, gdyż
wszystkie f odpowiedzi może być wysłane od niepoprawnie działających replik.
Gdy takich samych odpowiedzi jest f +1to wszystkie one są poprawne, gdyż
f +1>f, czyli muszą pochodzić ze zbioru replik działających poprawnie.
Twierdzenie 4 Jeżeli pośród n replik f jest działających w sposób bizantyjski
oraz f ≤ ⌊ ⌋
n−1 4
, to klient c może ustalić poprawną wartość zwracaną v dla
3
wywołania usługi u z parametrem i c .
Dowód. Jeżeli f replik jest niepoprawnie działających, to poprawnie działających
replik zostaje n − f. Ponadto f z replik poprawnie działających, może
zostać uszkodzonych i nie odpowiedzieć na żądanie. Korzystając jednocześnie
z twierdzenia 3 mamy n − 2f ≥ f +1, przepisując n−1 ≥ f, następnie przekształcamy
nierówność jednocześnie gwarantując, że prawa strona zawsze jest
3
całkowita i otrzymujemy ostatecznie f ≤ ⌊ ⌋
n−1
3 .
3.3 Algorytm BFT
Właściwości wskazane w poprzednim paragrafie posiada algorytm tolerancji
uszkodzeń bizantyjskich (ang. byzantine faoult tolerance) BFT, opracowany
przez B. Liskov oraz M. Castro z Programming Methodology Group, MIT w
USA 5 [CL99c, CL99a, CL99b, CL00].
Algorytm BFT zapewnia dwie podstawowe właściwości:
(1) Bezpieczeństwo wykonania (ang. safety). Wszystkie repliki uzgodnią poprawną
sekwencję wykonania zleceń pomimo błędów.
(2) Żywotność (ang. liveness). Klient ma gwarancję otrzymania odpowiedzi
na swoje żądanie w skończonym czasie t

3.3 Algorytm BFT 41
C
0
1
2
pre-prepare prepare commit
3
Rysunek 3.2: Przebieg wykonania zlecenia przez kilenta c w BFT. Trzy fazy:
pre-prepare, prepare oraz commit. Replika 3 zostaje uszkodzona i nie uczestniczy
w fazie commit oraz nie wysyła odpowiedzi.
Właściwość (1) jest niezależna w BFT od liczby niepoprawnie działających
replik, natomiast (2) zakłada, że przez cały czas życia usługi nie zostanie przekroczony
warunek z tw. 4 f ≤ ⌊ ⌋
n−1
3 postawiony na liczbę niepoprawnie działających
replik. Realizacja (1) odbywa się poprzez użycie niezawodnego atomowego
rozgłaszania używając protokołu trójfazowego zatwierdzania i porządkowania,
natomiast drugi warunek (2) został zapewniony przez użycie mechanizmu widoków
wraz z proaktywnym odzyskiwaniem stanu (ang. proactive state recovery).
BFT jest praktycznym algorytmem, którego podstawową cechą jest prostota i
nacisk na mały nakład obliczeń.
3.3.1 Założenia algorytmu BFT
System składa się z R replik świadczących usługę u, która zezwala na wykonanie
różnych operacji o. Wielu klientów może wysyłać zlecenia do usługi
jednocześnie. Numer repliki głównej wyznaczamy jako p = vmod|R|, gdzie
v jest aktualnym numerem widoku.
Repliki są ponumerowane i ∈{1, ..., R} i każda posiada klucz publiczny i
prywatny podpisany przez zaufaną stronę trzecią. Każda para replik i, j, gdzie
i ≠ j posiada dwa klucze symetryczne k ij oraz k ji .Kluczk ij używany jest do
komunikacji w kierunku od i do j, a klucz k ji w kierunku odwrotnym.
Poprzez σi oznaczymy wiadomość m podpisaną przez i-tą replikę,
podpis może zostać wykonany używając MAC (ang. Message Authentication
Code) lub kryptografji z kluczem publicznym. Skrót wiadomości (ang. message
digest) m oznaczymy d = D(m), gdzie D(·) jest jednokierunkową bezkolizyjną
funkcją skrótu zgodną z RFC-2104, np. MD5 lub SHA-1 6 .
6 Zarówno Message Digest 5, jakiSecure Hash Algorithm na chwilę obecną podejrzewane są
o możliwość wystąpienia w nich kolizji.

42 Rozdział 3. Bezpieczne bizantyjskie uzgadnianie
3.3.2 Działanie algorytmu BFT
Klient c wysyła zlecenie do repliki głównej p w postaci m = < REQEST, o, t, c,
d > σc , gdzie o jest operacją do wykonania, t znacznikiem czasowym (dowolny
znacznik, który nadaje klient w celu rozróżnienia odpowiedzi), c identyfikator
klienta, np. adres, d skrót całej wiadomości. Replika główna rozsyła zlecenie do
pozostałych replik. Gdyby klient nie otrzymał odpowiedzi wystarczająco szybko
od którejś z replik lub gdy replika główna nie odpowiada, powinien rozgłosić
zlecenie do wszystkich replik.
Replika główna p stosowana jest do nadania identyfikatora zleceniu, tak by
uporządkować wykonanie równoległych wywołań. Po odebraniu zlecenia wykonywany
jest trójfazowy protokół zatwierdzania, podobny do opisanego w [TS01].
Zastosowanie trójfazowego protokołu gwarantuje, że zlecenia zostaną wykonane
zgodnie z kolejnością nadesłania oraz zapewnia poprawność w przypadku uszkodzenia
repliki głównej. Przykładowe wykonanie algorytmu, gdy jedna z replik
zawodzi, pokazano na rysunku 3.2.
Kolejnym krokiem w algorytmie jest rozgłoszenie przez replikę główną zlecenia
do pozostałych replik σp , m >, które
rozpoczyna fazę przed-przygotowania (ang. pre-prepare) 7 . Zmienna v w wiadomości
jest aktualnym numerem widoku, dla którego rozpoczyna się wykonanie
protokół, początkowo v =0, n jest kolejnym numerem sekwencji wykonania
zlecenia pomiędzy dolnym znacznikiem h oraz górnym znacznikiem H, d jest
skrótem wiadomości m. Znaczniki związane są z mechanizmem zatwierdzania
stanu, h oznacza ostatni numer sekwencji wykonania zlecenia, który został
zatwierdzony. Duży znacznik wyznacza się, jako H = K + h, gdzie K jest
pewną stałą np. 100 lub 200 oznaczającą okres zatwierdzania stanu. Szczegóły
dotyczące znaczników zostaną omówione w punkcie dotyczącym proaktywnego
odzyskiwania stanu.
W odpowiedzi każda z replik wraz z koordynatorem rozsyła wiadomość <
PREPARE, v, n, d, i> σi do pozostałych replik. Jeżeli replika zaakceptowała
wiadomość PRE-PREPARE dla widoku v oraz n oraz otrzymała 2f +1 wiadomości
PREPARE , to rozsyła do pozostałych replik komunikat < COMMIT,
v, n, d, i> σi . Po otrzymaniu 2f +1odpowiedzi COMMIT od różnych replik
wykonuje zlecenie oraz wysyła odpowiedź do klienta < REPLY, t, i, r> σi .
Podsumowując, przy normalnym działaniu przebieg algorytmu jest następujący:
1. Klient c wysyła zlecenie m = < REQEST, o, t, c, d> σc do repliki głownej
p.
7 Skeen oraz Stonebraker nazywają fazę przed-przygotowania, zleceniem głosowania (ang.
vote-request), fazę przygotowania natomiast ozaczają przygotowaniem zatwierdzenia (ang.
prepare-commit), ostatnia faza nazywa się tak samo [TS01].

3.3 Algorytm BFT 43
2. Replika główna p rozgłasza σp ,m>
3. Replika i rozgłasza < PREPARE, v, n, d, i> σi i czeka na 2f +1takich
komunikatów uwzględniając własny.
4. Gdy warunek z poprzedniego punku jest spełniony replika i rozsyła komunikat
< COMMIT, v, n, d, i> σi i czeka na 2f +1 takich samych
komunikatów od innych replik.
5. Gdy warunek z poprzedniego punku jest spełniony replika i wykonuje
zlecenie oraz wysyła odpowiedź do klienta c postaci < REPLY, t, i, r> σi .
Widoki. Mechanizm widoków v jest związany z wprowadzeniem odporności
na uszkodzenie repliki głównej p. Gdy replika główna nie odpowie na zlecenie
klienta, a rozgłoszone zlecenie dotrze do innej repliki, to replika która odebrała
komunikat wysyła < VIEW-CHANGE, v +1, n, C, P, i> σi . C jest zbiorem
2f +1 punktów kontrolnych potwierdzających poprawność stanu s, aP jest
zbiorem zbiorów zleceń P m przygotowanych przez i o znaczniku większym niż
n. Każdy podzbiór P m składa się z wiadomości przed-przygotowania oraz 2f
odpowiadających jej wiadomości przygotowania zgodnych co do v, n oraz m.
Nowa replika główna p po odebraniu 2f komunikatów o zmianie widoku
rozsyła wiadomość < NEW-VIEW, v +1, V, O > σp , gdzie V jest zbiorem
komunikatów zmiany widoku. Zbiór O jest wyznaczany następująco:
1. Replika główna określa dwie wartości min s - numer ostatniego stabilnego
znacznika zatwierdzenia stanu w V oraz max s , najwyższy numer zlecenia
w V.
2. Replika główna przygotowuje nowe wiadomości przed-przygotowania dla
każdego n ∈ (min s ,max s ). Mogą zaistnieć dwa przypadki: (1) istnieje
przynajmniej jeden zbiór w P gdzie wystąpił komunikat zmiany widoku
w V z numerem sekwencji n lub (2) nie ma takiego zbioru. W pierwszym
przypadku replika główna tworzy komunikat < PRE-PREPARE, v +1,
n, d> σp , gdzie d jest skrótem zlecenia o największej sekwencji n w
V. W przeciwnym razie replika główna konstruuje komunikat < PRE-
PREPARE, v+1, n, d null > σp , gdzie d null jest skrótem specjalnego pustego
zlecenia null, które jest obsługiwane przez repliki w taki sam sposób, jak
inne zlecenia, ale nie zmienia stanu. Ta technika ma na celu usunięcie
ewentualnych luk.
Jeżeli min s jest większe od ostatniego stabilnego stanu dla p, top zapamiętuje
dowód stabilności dla min s . Repliki zapasowe wykonują zlecenia nadesłane
przez nową replikę główną dla sekwencji pomiędzy min s oraz max s ,alewysyłają
tylko te odpowiedzi do klientów, które nie zostały im przesłane.

44 Rozdział 3. Bezpieczne bizantyjskie uzgadnianie
3.3.3 Optymalizacje zastosowane w BFT
Redukcja komunikacji. W ostatniej fazie działania protokołu odpowiedź wysyłana
jest do klienta przez wszystkie repliki. Zasadniczym usprawnieniem jest
wybieranie przez klienta tylko jednej z replik do przesłania odpowiedzi na zlecenie,
natomiast reszta replik jedynie wysyła potwierdzenia ze skrótem kryptograficznym
wyniku. Mogłoby się zdarzyć, że odpowiedź jest bardzo duża i
nie da się jej przesłać w pojedynczym komunikacie. W takim wypadku wszystkie
repliki powinny uczestniczyć w wysyłaniu odpowiedzi przesyłając jedynie po
części, tak by klient był w stanie złożyć cały komunikat, można w tym przypadku
zastosować podobne rozwiązania, jakie oferuje protokół BitTorrent [Coh03].W
Kolejne usprawnienie zaproponowane przez autorów zezwala na wykonanie
zlecenia przez replikę i już po fazie przygotowania i wysłanie odpowiedzi do
klienta. Następnie przesłanie tylko potwierdzenia, lub odmowy, gdyby podczas
tej fazy wystąpiła zmiana widoku. W takim przypadku, replika musi cofnąć stan
do tego sprzed wykonania zlecenia.
Trzecia poprawka dotyczy rozróżnienia operacji modyfikujących stan usługi
od takich, które tego nie robią, czyli tylko do odczytu. Klient rozgłasza do
wszystkich replik operację tylko do odczytu i czeka na 2f +1 odpowiedzi.
Replika może przygotować odpowiedź dla klienta wtedy, gdy jej stan będzie
zatwierdzony, gdyż w innym przypadku klient otrzymałby informację o niespójnym
stanie usługi. Operacja tylko do odczytu nie zakończy się poprawnie, gdy
repliki są zajęte, gdyż inne zlecenia modyfikują stan usługi. W tym przypadku
klient musi ponownie rozgłosić żądanie.
Omijanie kryptografii z kluczem publicznym. Do potwierdzania wszystkich
wiadomości w BFT stosuje się MAC, które wyznacza się jednokierunkową bezkolizyjną
funkcją skrótu na konkatenacji wiadomości i symetrycznego klucza
k ij . Ponadto w algorytmie stosuje się wektory MAC nadesłane przez każdą z
replik, tzw. poświadczenia (ang. authenticators), który na j-tej pozycji zawiera
MAC wiadomości m przeznaczonej od repliki j. Stosowanie MAC zamiast podpisów
jest opłacalne wtedy, gdy liczba replik nie jest duża, jednak gdyby było
inaczej podpisy uzyskane przy pomocy technik kryptografii z kluczem publicznym
byłyby znacznie lepsze i bardziej wydajne, gdyż są weryfikowalne nie tylko
przez uczestników grupy replikującej. Jak pokażemy w następnym rozdziale,
weryfikacja ma bardzo duże znaczenie, gdy repliki przyłączają się i opuszczają
grupę.

3.3 Algorytm BFT 45
3.3.4 Proaktywne odzyskiwanie stanu w BFT
Replika zapisuje do dziennika wszytkie operacje, które wykonuje. Zbiór potwierdzonych
i wykonanych zleceń stanowi o stanie usługi s. Stan s określany
jest jako stabilny, jeżeli jest zatwierdzony. Replika chcąc zatwierdzić stan dla
jakiegoś numeru sekwencji n wysyła komunikat postaci < CHECKPOINT, n,
D(s), i> σi . Zatwierdzenie stanu powinno być przeprowadzane co pewną liczbę
zleceń, w zależności od średniego obciążenia usługi, tak by nie występowało ono
za często, ale też nie było za rzadkie, gdyż to może znacznie wydłużyć operację
zmiany widoku opisaną wcześniej. Jeżeli replika odbierze 2f +1 potwierdzeń, to
może zatwierdzić stan. Wszystkie wiadomości otrzymane dla niższych numerów
sekwencji od n mogą zostać usunięte z dziennika repliki i.
Proaktywne odzyskiwanie stanu jest procesem, który odświeża stan repliki.
Twórcy algorytmu zakładają, że wszystkie repliki są uruchamiane i nadzorowane
przez administratora systemu. Nie jest brana pod uwagę sytuacja, gdy
replika została uruchomiona przez atakującego. Jest to poprawne założenie dla
tego przypadku, gdyż jedynie repliki nadzorowane mogą rozpocząć proces odzyskiwania
stanu. Ta technika pozwala przywrócić uszkodzoną replikę, która
zachowuje się w sposób bizantyjski, do poprawnego działania. Niestety trudno
jest określić, czy replika działa poprawnie, czy też nie. W związku z powyższym
każda z replik posiada proces nadzorujący (ang. watchdog), który co ustalony
interwał rozpoczyna kontrolowany restart repliki.
Protokół estymujący. Faza estymacji ma na celu ustalenie, który ostatni numer
sekwencji zleceń repliki uznają za stabilny. Replika i rozgłasza komunikat <
QUERY-STABLE, i, k> σi , gdzie k jest losową liczbą. Kiedy replika j odbierze
komunikat wysyła odpowiedź < REPLY-STABLE, c, e, i, k> σj i, c jest ostatnim
stabilnym numerem sekwencji, e jest ostatnim numerem sekwencji zlecenia
przygotowanym przez j. Replika i zachowuje najmniejszą wartość c oraz największą
e oraz swoje własne. Następnie szacuje H M = L + c M , gdzie L jest
rozmiarem dziennika, natomiast c M musi być większe od jakiegokolwiek ostatniego
znacznika zatwierdzenia, c M jest taką wartością otrzymaną od repliki j,
że przynajmniej 2f replik podało c mniejsze bądź równe od c podanego przez
j oraz f replik różnych od j podało wartości e większe bądź równe c M .
Zlecenie odzyskania stanu. Replika i wysyła zlecenie odzyskania stanu <
REQUEST, < RECOVERY, H M >, t, i > σi . Parametr t w wywołaniu musi być
losowym znacznikiem większym od uprzednio wysłanego. Replika j odrzuci
wiadomość z t mniejszym od uprzedniego, jak również taką wiadomość, która
była nadana przez i w czasie nie większym niż połowa okresu odnowienia repliki.
Takie postępowanie ma na celu wykluczenie ataków zablokowania usługi typu
DoS (ang. denial-of-service), który byłby wynikiem całkowitego obciążenia

46 Rozdział 3. Bezpieczne bizantyjskie uzgadnianie
grupy zleceniami odnowienia stanu.
Podczas odzyskiwania stanu musi nastąpić wymiana kluczy, gdyż stare klucze
mogły zostać przechwycone przez atakującego. Odpowiedź zawiera numer
sekwencji zlecenia n R przez co replika może wyznaczyć H R = ⌊n R /K⌋×K+L,
następnie oblicza H = max(H M ,H R ), która to wartość jest górnym znacznikiem.
Używając wszystkich zebranych informacji rozpoczyna proces pobrania
stanu [CL00] 8 .
Ważnym założeniem jest to, by proaktywne odzyskiwanie stanu nie było
realizowane przez więcej jak jedną replikę równolegle (o ile nie wiadomo ze
100% pewnością, że niepoprawnie realizuje zlecenia), gdyż w ten sposób naraża
się usługę na niepoprawne działanie. Okres w jakim usługa narażona jest na
załamanie jest równy T v =2T k + T r , gdzie T k oznacza czas wymiany kluczy, T r
jest czasem od załamania repliki do czasu odzyskania przez nią pełnej informacji
o aktualnym stanie usługi [CL00].
Do niewątpliwych zalet BFT należy zaliczyć: łatwą implementację i możliwość
adaptacji do wielu systemów. Znacząca wadą tego algorytmu jest konieczność
wykrywania niepoprawnie działającej repliki głównej, czyli uzależnienie od
czasu odpowiedzi tzw. (ang. failure detectors), oraz szeregu parametrów, które
muszą być dostosowane do środowiska, w celu zagwarantowania żywotności i
efektywności.
3.4 Algorytm SC-ABC
SC-ABC jest stosem protokołów używających tzw. kryptografii progowej, nowoczesnej
techniki kryptograficznej, która bardzo ogólnie zostanie omówiona
w kolejnym paragrafie tak, by umożliwić zrozumienie sposóbu działania algorytmu.
SC-ABC został opracowany przez grupę badawczą z laboratorium IBM
w Zurichu, głównie przez K. Kursawe oraz V. Schoupa. Stos protokołów rozpoczyna
binarne bizantyjskie uzgadnianie (ang. Binary Byzantine Agreement)
BBA, następnie wielowartościowe bizantyjskie uzgadnianie (ang. Multi-valued
Byzantine Agreement) MBA, atomowe rozgłaszanie (ang. Atomic Broadcast)
ABC. Protokołem najwyższego poziomu jest algorytm bezpiecznego przyczynowego
rozgłaszania (ang. Secure Causal Atomic Broadcast) SC-ABC. Protokół
jest w większym stopniu asynchroniczny niż miało to miejsce w BFT, poprzez
zastosowanie elementów losowych, co pociąga za sobą istnienie pewnego niezerowego
prawdopodobieństwa tego, iż protokół poprawnie nie zakończy działania.
Twórcy algorytmu tłumaczą, że praktycznie żaden protokół nie gwarantuje
całkowitej poprawności, gdyż zależy od różnych założeń, które w środowisku
usługi.
8 Opis procesu transferu stanu został pominięty, gdyż jego konstrukcja może zależeć od samej

3.4 Algorytm SC-ABC 47
pracy nie zawsze będą spełnione. Według autorów, gdyby realizacja protokołu
nie przyniosła efektu (nie zakończyła się, lub zakończyła się błędnie), należy
przerwać jego wykonanie i rozpocząć je ponownie, gdyż warunki początkowe
uruchomienia mogą ulec zmianie i poprawne zakończenie stanie się możliwe
[CKPS01].
Założenia ogólne. Kanał komunikacyjny jest całkowicie zależny od atakującego.
Wszystkie wiadomości są autoryzowane. Złożoność wykonania poszczególnych
protokołów w stosie jest probabilistycznie jednostajnie ograniczona.
Definicja. Złożoność protokołu X nazywamy probabilistycznie jednostajnie
ograniczoną, jeżeli dla dowolnego wielomianu T (k) i k ≥ 0, istnieje zaniedbywalnie
mała wartość ɛ(k) taka, która spełnia:
Pr[X(k) >T(k)] ≤ ɛ(k),
czyli, że prawdopodobieństwo tego, iż złożoność wykonania protokołu X
będzie większa niż wielomianowa, jest odpowiednio małe. Dla złożenia protokołów
rozumianego w ten sposób, że jeżeli protokół X A używa pod-protokołu
X B i złożoności obu z nich są probabilistycznie jednostajnie ograniczone, złożoność
protokółu X AB jest również probabilistycznie jednostajnie ograniczona 9 .
To rozumowanie pokazuje, że złożoność probabilistycznego protokołu SC-ABC
jest zaniedbywalnie większa od złożoności wielomianowej. Autorzy starają się
udowodnić, że protokoły o losowym charakterze długości wykonania są użyteczne,
jeżeli tylko jesteśmy w stanie zapewnić, że przypadki nieskończenie
długich wykonań będą zdarzały się pomijalnie rzadko. Oczywiście, czy jest
to podejście słuszne, czy nie, jest kwestią dyskusyjną. Zgodzić się można, że
posiadając informację o tym, jak długo zajmuje średnie wykonanie protokołu,
możemy przerwać realizację, a następnie ją ponowić.
Hierarchiczne wywołania. Instancje protokołu mają unikalne ID, które nadawane
jest jednorazowo. Jeżeli uczestnik odbierze komunikat oznaczony uprzednio
otrzymanym ID, który jest zleceniem operacji, która już została wykonana,
to komunikat zostanie zignorowany. Pod-protokoły identyfikowane są poprzez
konkatenację ID protokołu wyższego rzędu oraz unikalnego ID w ramach tego
pod-protokołu, czyli ID|ID ′ |.... Wiadomości nadane przez uczestnika i mogą
być następującej kategorii:
Wejście - ( ID, in , akcja, typ ) i
9 Szczegóły dotyczące definicji złożoności probabilistycznie jednostajnie ograniczonej dostępne
są w pracy [CKPS01].

48 Rozdział 3. Bezpieczne bizantyjskie uzgadnianie
Wyjście - ( ID, out , akcja, typ ) i
Protokół - ( ID, akcja, ··· ) i
Istnieją dwie ważne akcje w przypadku wiadomości kategorii protokołu: (1)
open, która otwiera instancję protokołu, oraz (2) halt, zamykająca wykonanie
instancji protokołu wskazanego przez ID.
Bizantyjskie uzgadnianie. Protokół rozpoczyna działanie gdy do uczestnika i
zostanie doręczony komunikat ( ID, in, propose, v ) i , gdzie v ∈{0, 1}. Zakończenie
protokołu dla i-tego uczestnika następuje gdy nada on komunikat (
ID, out, decide, v ) i . W oparciu o przedstawione założenia, binarne bizantyjskie
uzgadnianie można rozumieć jako protokół spełniający cztery następujące
postulaty:
Poprawność. Wszyscy poprawnie działający uczestnicy protokołu jeżeli
rozpoczynają uzgadnianie podając wartość jako decyzję v, to akceptują
wartość v.
Uczciwość. Jeżeli jakiś poprawnie działający uczestnik zaakceptował v, to
zakończył działanie protokołu z wartością v.
Żywotność.
uzgadnianiu.
Wszyscy poprawnie działający uczestnicy biorą udział w
Wydajność. Protokół jest probabilistycznie jednostajnie ograniczony.
Pierwszy postulat jest bardzo mocny i nie zezwala na początkową niezgodność
co do wartości v zaproponowaną przez uczciwych uczestników. Nie dopuszcza
się do zaistnienia sytuacji, w której jakiś z uczciwych uczestników protokołu się
pomylił.
3.4.1 Kryptografia progowa
SC-ABC używa w dużym stopniu nowoczesnych technik kryptograficznych. Jego
szkielet oparty jest na mechanizmach kryptografii progowej. Prosty schemat
kryptografii progowej z kluczem publicznym przedstawiono na rysunku 3.3.
Współdzielenie sekretu. Najłatwiej zrozumieć działanie kryptografii progowej
na przykładzie prostego algorytmu zaproponowanego przez A. Shamira [Sha79].
Celem tego algorytmu jest umożliwienie k z n uczestników zrekonstruowanie
wiadomości (sekretu) D. Jeżeli uczestników będzie mniej niż k to nie będą
oni w stanie uzyskać jakiejkolwiek informacji o D. Algorytm używa prostej
interpolacji wielomianem:

3.4 Algorytm SC-ABC 49
Rysunek 3.3: Przykład schematu (2 z 3) kryptografii progowej z kluczem publicznym.
Klucz publiczny składa się z trzech udziałów. Ta sama wiadomość
szyfrowana jest przez trzech uczestników. Jeden z uczestników gubi szyfrogram,
lub ulega on zniszczeniu. Odszyfrowanie wiadomości przy pomocy klucza
prywatnego nadal pozostaje możliwe, gdyż wystarczą do tego pozostałe dwa
szyfrogramy.
q(x) =a 0 + a 1 x + a 2 x 2 + a k−1 x k−1 , a 0 = D
w ciele modulo p, gdzie p jest liczbą pierwszą większą od D oraz n. Współczynniki
wielomianu są wylosowane zgodnie z rozkładem jednostajnym a i ∈ [0,p).
Każda z części sekretu D wyznaczona jest w taki sposób, że:
D 1 = q(1),D 2 = q(2) ···,D n = q(n)
Posiadając k z części D wraz z ich identyfikatorami, możliwe jest poprzez
interpolację określenie współczynników w q(x), a co za tym idzie obliczenie
D = q(0), które jest sekretem. Pozostaje pokazać co stanie się gdy ktoś przechwyci
k − 1 udziałów. Dla każdego D ′ ∈ [0,p) może skonstruować wielomian
q ′ (x), któryspełniaD ′ = q ′ (0) oraz D i = q ′ (i). Z założenia każdy z
tych p wielomianów z jednakowym prawdopodobieństwem, jest poszukiwanym
wielomianem q(x). Zatem, jeżeli p jestdużeorazatakującyniemażadnych
dodatkowych informacji o D, to nie będzie w stanie określić właściwego q(x)
stosując inną metodę niż atak brutalny (sprawdzenie wszystkich możliwych wartości).
Ten schemat jest bardzo prosty, jednak wystarczająco dobrze ilustruje
istotę kryptografii progowej.

50 Rozdział 3. Bezpieczne bizantyjskie uzgadnianie
Ogólnie kryptosystem progowy k z n oznaczony (k, n), jest to taki schemat
kryptograficzny, w którym do prawidłowego przeprowadzenia operacji wymagane
jest t ≥ k uczestników.
Istnieją różne typy kryptosystemów progowych, np. takie które uwzględniają
wagę uczestników, schematy te nazywają się ważonymi kryptosystemami
progowymi. Algorytm SC-ABC używa trzech schematów progowych: współdzielonego
sekretu, progowego podrzucania monetą (ang. treshold common coin
tossing) oraz progowych podpisów cyfrowych (ang. treshold signatures).
Współdzielone podrzucanie monetą. Odwzorowanie „podrzucania monetą”
oznaczamy przez F : {0, 1} ∗ −→ {0, 1}. Jest to takie przekształcenie, które
dowolny ciąg bitowy odwzorowuje na 0 lub 1. Progowe podrzucanie monetą
(n, k) polega na tym, że przynajmniej k uczestników musi kooperować w celu
określenia zwracanej wartości przez odwzorowanie F . Wejściowy ciąg znaków
jest ciągiem decyzji, który może być losowy, dlatego wynik działania F nie jest
deterministyczny.
Progowe podpisy cyfrowe. Algorytmy szyfrowania z kluczem publicznym zakładają
istnienie pary kluczy: klucza prywatnego oraz klucza publicznego posiadanego
przez każdego z uczestników komunikacji [RSA77, MVO96]. Klucz
prywatny służy do odszyfrowywania wiadomości wcześniej zaszyfrowanej kluczem
publicznym. Klucz publiczny jest jawny. Podpis wykonuje się kluczem
prywatnym, natomiast jego weryfikacja odbywa się za pomocą klucza publicznego
(tzw. klucza weryfikującego). W schemacie (n, k, t) podpisu progowego,
klucz publiczny jest jeden natomiast klucz prywatny rozdzielony jest na n udziałów.
Do wygenerowania poprawnego podpisu wiadomości m, potrzeba t ≥ k
uczestników podpisujących tę samą wiadomość m, tak by podpis był weryfikowalny.
Kryptosystemy progowe świetnie nadają się do zastosowania przy głosowaniach,
gdyż u podstawy ich konstrukcji zakłada się istnienie większości, koniecznej
do poprawnego działania. Główny problem, który pojawia się podczas
stosowania kryptografii progowej ujawnia się, gdy grupa uczestnicząca w określonym
protokole zmienia skład.
3.4.2 Stos protokołów SC-ABC
Opis algorytmu zaczniemy od najniższej warstwy dotyczących funkcji rozgłaszania.
Często wykorzystywanym mechanizmem komunikacji między współpracującymi
procesami jest niezawodne rozgłaszanie (ang. Reliable Broadcast).
Gwarantuje ono, że komunikat zostanie dostarczony do wszystkich uczestników

3.4 Algorytm SC-ABC 51
Secure Causal Atomic Broadcast SC-ABC
Atomic Broadcast ABC
Multi-valued Byzantine Agreement MBA
Binary Byzantine Agreement BBA
Broadcast Primitives
Treshold cryptography
Rysunek 3.4: Stos protokołów algorytmu SC-ABC. Warstwa wyższa używa warstwy
niższej w celu osiągnięcia wyniku. Stos protokołów korzysta z podstawowych
mechanizmów rozgłaszania oraz kryptografii progowej.
komunikacji. Dodatkową właściwością zapewnianą przez niezawodne rozgłaszanie
jest to, że wysłany komunikat zostanie dostarczony co najwyżej jeden
raz. W większości przypadków złożoność tej operacji wymaga O(n 2 ) komunikatów,
gdzie n oznacza liczbę uczestników. Usługa niezawodnego rozgłaszania
rozwiązuje uprzednio przedstawiony problem bizantyjskich generałów.
Niekiedy ważne jest, by dało się potwierdzić, iż dana wiadomość została
naprawdę dostarczona do wszystkich uczestników. Właściwość taką posiada
weryfikowalne rozgłaszanie (ang. Verifable Broadcast). Ogólnie, jeżeli jakiś
uczestnik nie wie, czy należy odebrać wiadomość m, to inny uczestnik może
wysłać dla niego potwierdzenie, które określi, że wiadomość m powinna być
dostarczona.
Nie zawsze zagwarantowanie, że wszystkie wiadomości zostały dostarczone,
jest możliwe. Może zdarzyć się, że któryś z uczestników nie jest osiągalny
podczas wysyłania komunikatu. Protokół, który zezwala by wiadomość została
doręczona w innym terminie nazywa się spójnym rozgłaszaniem (ang. Consistent
Broadcast). Złożenie opisanego poprzedniego protokołu i opisanego w
tym akapicie prowadzi do weryfikowalnego spójnego rozgłaszania (ang. Verifable
Consistent Broadcast) VCBC, który zakłada weryfikację dostarczenia wiadomości
oraz zezwala na to by nie wszystkie wiadomości były odebrane w tym samym
czasie przez wszystkich uczestników grupy.
Kolejnymi cegiełkami użytymi do konstrukcji algorytmu SC-ABC jest potwierdzone
bizantyjskie uzgadnianie (ang. Validated Byzantine Agreement)VBA,
oraz atomowe rozgłaszanie (ang. Atomic Broadcast) ABC.
Binarne bizantyjskie uzgadnianie (ang. Binary Byzantine Agreement) jest
protokołem potwierdzonego bizantyjskiego uzgadniania, w którym zbiór możliwych
do uzgodnienia wartości ogranicza się tylko do v ∈{0, 1}. Wielowartościowe
bizantyjskie uzgadnianie (ang. Multi-valued Byzantine Agreement) realizuje
protokół potwierdzonego bizantyjskiego uzgadniania. Gdy ograniczymy

52 Rozdział 3. Bezpieczne bizantyjskie uzgadnianie
wartości możliwe do uzgodnienia przez wielowartościowe bizantyjskie uzgadnianie
tylko do v ∈{0, 1} automatycznie uzyskujemy protokół binarnego bizantyjskiego
uzgadniania. Rozróżnienie na te dwa przypadki jest uzasadnione, gdyż
binarne bizantyjskie uzgadnianie stosowane jest wtedy, gdy np. grupa ma na
celu zatwierdzenie transakcji. Przejdę teraz do omówienia po kolei najważniejszych
elementów użytych w algorytmie SC-ABC.
Założenia. Przyjmiemy, że S będzie oznaczać kryptosystem progowego podpisu
cyfrowego, natomiast E będzie progowym schematem szyfrującym. S 1 oznacza
schemat podwójnego progowego podpisu cyfrowego typu (n, ⌈ ⌉
n+t+1
2 ,t). Ogólnie
schemat (n, κ, t) oznacza, taki kryptosystem, w którym do wykonania operacji
potrzeba t

3.4 Algorytm SC-ABC 53
będzie podejmował l, a następnie rozesłać podpis do wszystkich uczestników i
oczekiwać na ⌈ ⌉
n+t+1
2 podpisów od innych uczestników, wtedy każdy w grupie
staje się nadawcą wiadomości m. Innym podejściem jest założenie, że uczestnicy
będą czekali, aż rozsyłający znowu zacznie odpowiadać, ale to może w
ogóle nie nastąpić.
Protokół 3.5.2. VBA ma na celu ustalenie zaproponowanej wartości wspólnie
przez grupę uczestników. Protokół rozpoczyna komunikat ( ID, v-propose, w, π
) l , na który uczestnik odpowiada rozsyłając za pomocą VCBC odpowiedź v-echo
wraz z proponowanymi wartościami w oraz π. Nadawca oczekuje na n − t propozycji
rozgłoszonych w ten sam sposób od różnych j, które spełniają predykat
Q ID . Q ID (w a ,π a ) jest zbiorem możliwych w a i π a , które są poprawne. Forma,
wjakiejQ ID jest zrealizowane, jest dowolna, np. może to być zestaw reguł.
Q ID musi być ogólnie znane, tak by każdy z uczestników mógł przeprowadzić
weryfikację. Uczestnik i buduje tablicę potwierdzeń, gdzie c j =1, gdy j-ty
uczestnik nadesłał poprawne w j , następnie rozgłasza ją do pozostałych uczestników.
Odebranie n − t tablic C j , w których przynajmniej n − t wpisów jest
równych 1, stanowi potwierdzenie, że większość uczestników wysłała poprawne
propozycje. Za pomocą progowego podrzucania monetą zostaje wygenerowane
losowe ziarno S składające się z t +1 udziałów, które służy do utworzenia
permutacji Π. W pętli odbywa się głosowanie według a ←− Π(l) dotyczące
wartości w a . Gdy decyzja zostanie podjęta (⊥ również jest dopuszczalną decyzją),
i zakańcza protokół.
Uwagi. W protokole VBA użyta jest randomizacja. Ta technika została zastosowana,
by uniemożliwić atakującemu przewidzenie, w jakiej kolejności będą
podawane wartości w j do uzgodnienia. W ten sposób stara się uniknąć tego, by
atakujący w momencie uzgadniania wartości, do niektórych uczestników wysłał
propozycje korzystniejsze dla niego.
Protokół 3.5.3. ABC jest pierwszym protokołem, który można nazwać protokołem
wysokiego poziomu. Każdy z uczestników utrzymuje kolejkę q typu FIFO,
wiadomości do dostarczenia oraz zbiór d już dostarczonych wiadomości. Po
odebraniu wiadomości ( ID, in, a-broadcast, m ) m zostaje wstawione na koniec
q, jeżeli m nie jest już w q. W nieskończonej pętli, której każdy przebieg
oznaczany jest jako runda r, uczestnik odbiera nową wiadomość lub obsługuje
wiadomości już zgromadzone w kolejce. Gdy zostanie odebrana nowa wiadomość
a-queue w ←− w l , która nie znajduje się w d, czyli nie jest dostarczona
oraz σ l jest poprawnym podpisem dla w l , to zostaje ona obsłużona. W przypadku
gdy q nie jest pusta, to pierwsza wiadomość z kolejki wysyłkowej będzie
rozesłana do wszystkich uczestników. Po nadaniu komunikatu i czeka na n − t

54 Rozdział 3. Bezpieczne bizantyjskie uzgadnianie
wiadomości a-queue dla tej samej rundy r. Z otrzymanych odpowiedzi konstrułowany
jest wektor W i wektorem podpisów S, dla którego uruchamiany jest
protokół wielowartościowego bizantyjskiego uzgadniania v-propose. Wartości
oznaczone w wektorze V [j] =1rozgłaszane są jako a-delivered ipootrzymaniu
potwierdzenia trafiają do d isąusuwanezq.
Uwagi. Atomowe rozgłaszanie wprowadza porządek odbioru dla nadawanych komunikatów
gwarantując, że nie dojdzie do sytuacji, że komunikaty przez jednego
użytkownika zostaną odebrane w innej kolejności niż przez innych uczestników.
Bizantyjskie uzgadnianie jest techniką, która pozwala ustalić kolejność nadejścia
komunikatów przez użytkowników dla danej rundy r oraz gwarantuje, że wiadomość
zostanie dostarczona do wszystkich poprawnie działających uczestników,
bądź do żadnego z nich.
3.4.3 Działanie algorytmu SC-ABC
SC-ABC rozpoczyna działanie po odebraniu przez i wiadomości ( ID, in, s-
broadcast, c ), która zostaje rozgłoszona do wszystkich uczestników, używając
komunikatu a-broadcast protokołu ABC. Wiadomość c jest zaszyfrowana E 1
kryptosystemem progowym (n, t +1)tak, że zebranie t +1udziałów odszyfrowujących
δ pozwala ją odszyfrować. Po odszyfrowaniu wiadomości c zostaje
wysłanie potwierdzenie do reszty uczestników. Replikacja usługi przy użyciu
SC-ABC obywa się wykonując następujące kroki:
1. Klient wysyła zlecenie c, do jakiejkolwiek z replik.
2. Replika rozgłasza c używając komunikatu s-broadcast, tak, że po odebraniu
t +1udziałów ρ j odszyfrowuje zlecenie m zawarte w szyfrogramie c
i je wykonuje.
3. Replika rozgłasza stan s do innych replik używając komunikatu v-propose.
Gdy stan s zostanie ustalony, jest on oznaczany przez replikę, jako stabilny.
Protokół bezpiecznego atomowego rozgłaszania gwarantuje tajność wiadomości,
gdyż dopiero potwierdzenie przez t+1 uczestników pozwala odszyfrować
nadany komunikat. Kroki wykonywane przez protokół najwyższego poziomu są
oczywiste, dlatego prawdziwa trudność leży w zrozumieniu działania protokółów
niższego rzędu.

3.5 Podsumowanie 55
3.5 Podsumowanie
W tym rozdziale przedstawiłem dwa podejścia do rozwiązania problemu replikacji
odpornej na błędy bizantyjskie. Oba opisane algorytmy uzależnione są od
technik kryptograficznych. Algorytm BFT jest mocno ukierunkowany na rozwiązanie
zadania replikacji usługi i jego działanie sprowadza się do rozwiązania
podstawowych problemów spowodowanych niepoprawnym działaniem repliki.
SC-ABC ma bardzo dobre właściwości ze względu na modularną budowę, ale
nie precyzuje, jak uczestnicy mają postępować w przypadku załamania (rozpadu)
grupy replik. SC-ABC lepiej radzi sobie z uporządkowaniem i bezpieczeństwem
nadawanych wiadomości używając kryptografii progowej, ale przypłaca to brakiem
możliwości rekonfiguracji składu grupy. Wadą obydwu algorytmów jest
brak jednoznacznej reakcji na sytuację, gdy replika całkowicie opuszcza grupę
i należałoby ją wykluczyć z dalszej komunikacji oraz włączenie nowej repliki.
Oba przypadki są podstawowym i najczęściej spotykanym zachowaniem replik w
rozproszonych tablicach z kodowaniem mieszającym implementowanych na bazie
systemów peer-to-peer. Wynika z tego, że potrzebne są algorytmy, które w
łatwy sposób zaradzą tym problemom i jednocześnie będą wystarczająco proste
i efektywne, by móc zastosować je w środowisku całkowicie rozproszonym.

56 Rozdział 3. Bezpieczne bizantyjskie uzgadnianie
Protokół 3.5.1: Verifable Consistent Broadcast - VCBC
dla uczestnika P i oraz znacznika ID.j.s
ROZPOCZĘCIE:
¯m ←⊥;¯μ ←⊥
W d ←∅; r d ← 0 (d ∈{0, 1} k′ )
PO ODEBRANIU WIADOMOŚCI ( ID.j.s, in, c-broadcast, m ):
send ( ID.j.s, c-send, m ) i
PO ODEBRANIU WIADOMOŚCI ( ID.j.s, c-send, m ) l :
if j = l ⎧and ¯m = ⊥
⎪⎨ ¯m ← m
then oblicz udział ν podpisu S 1 dla ( ID.j.s, c-ready, H(m) ) i
⎪⎩ send ( ID.j.s, c-ready, m, ν ) i do P j
PO ODEBRANIU WIADOMOŚCI ( ID.j.s, c-ready, d, ν l ) l :
if i = j and ν l jest poprawnym udziałem w S
⎧
1
W d ← W d ∪{ν l }
⎪⎨
r d ← r d +1
then if r d = ⌈ ⌉
n+t+1
{ 2
scal udziały w Wd w jeden S
⎪⎩ then
1 podpis progowy μ
send ( ID.j.s, c-final, d, μ ) i do wszystkich P
PO ODEBRANIU WIADOMOŚCI ( ID.j.s, c-final, d, ν ) j :
if H(¯m) =d and ¯μ = ⊥ jest poprawnym podpisem S 1
{¯μ ← μ
then
zakończ ( ID.j.s, out, c-deliver, d, ¯m ) i
Realizacja weryfikacji
PO ODEBRANIU WIADOMOŚCI ( ID.j.s, c-request ) l :
if ¯μ ≠ ⊥
then send ( ID.j.s, c-answer, ¯m, ¯μ ) i do P l
PO ODEBRANIU WIADOMOŚCI ( ID.j.s, c-answer, m, μ ) l :
if ¯μ ≠ ⊥ and μ
jest poprawnym
⎧
podpisem S 1 dla ( ID.j.s, c-ready, H(m) ) l
⎪⎨ ¯μ ← μ
then ¯m ← m
⎪⎩ zakończ ( ID.j.s, out, c-deliver, d, ¯m ) i

3.5 Podsumowanie 57
Protokół 3.5.2: Validated Byzantine Agreement - VBA
dla uczestnika P i , znacznika ID oraz predykatu Q ID
ISTNIEJE PREDYKAT V ID|a (v, ρ):
V ID|a (v, ρ) ≡ (v =0)or (v =1and ρ spełnia c-broadcast
dla wiadomości ( v-echo, w a , π a ) oznaczonej ID.a.0 tak, że
Q ID (w a ,π a ) jest spełnione)
PO ODEBRANIU WIADOMOŚCI ( ID, in, v-propose, w, π ):
c-broadcast ( v-echo, w , π ) ozaczone ID|vcbc.i.0
w j ←⊥; π j ←⊥ (1 ≤ j ≤ n)
wait for n − t wiadomości ( v-echo, w j , π j )
c-delivered oznaczonych ID|vcbc.j.0 od różnych P j
takich,
{
że spełnione jest Q ID (w j ,π j )
1 jeżeli wj ≠ ⊥
c j ←
(1 ≤ j ≤ n)
0 w innym wypadku
C ← [c 1 , ···,c n ]
c-broadcast ( v-commit, C ) i oznaczone ID|vcbc.i.0
C j ←⊥ (1 ≤ j ≤ n)
wait for n − t wiadomości ( v-commit, C j ) j
c-delivered oznaczonych ID|vcbc.j.0
takich, że przynajmniej n − t wpisów w C j =1
wygeneruj udział γ w progowym podrzucaniu monetą oznaczoną ID|vba
send( ID, v-coin, γ ) i do wszystkich P
wait for t +1wiadomości zawierających udziały w ID|vba
scal udziały by otrzymać S = F (ID|vba) ∈{0, 1} k′′
wybierz losową permutację Π używając generatora G zziarnemS
l ← 0
repeat
l ← l +1;a ← Π(l)
if w a = ⊥
then
{
send ( ID, v-vote, a, 0, ⊥ ) i do wszystkich P
niech ρ jest wiadomością c-broadcast oznaczoną ID|vcbc.a.0
else
send ( ID, v-vote, a, 1, ρ ) i do wszystkich P
u j ←⊥; r j ←⊥ (1 ≤ j ≤ n)
wait for n − t wiadomości ( ID, v-vote, a, u j , ρ j ) j od różnych P j
takich, że V ID|a jest spełnione oraz C j [a] =0gdy u j =0
if ∃ u j =1
then v ← 1; ρ ← ρ j
else v ← 0; ρ ←⊥
zaproponuj v potwierdzone przez ρ dla BBA w stronę 1 z V ID|a
wait for ustalenie wartości b potwierdzonej przez σ dla ID|a
until b =1if w a = ⊥
{
użyj σ do zakończenia c-broadcast oznaczonego ID|vcbc.a.0
then
oraz c-deliver (ID, v-echo, w a , π a )
zakończ ( ID, out, v-decide, w a , π a ) i , halt

58 Rozdział 3. Bezpieczne bizantyjskie uzgadnianie
Protokół 3.5.3: Atomic Broadcast - ABC
dla uczestnika P i oraz znacznika ID
ISTNIEJE PREDYKAT Q ID|abc.r :
Q ID|abc.r ([w 1 , ···,w n ], [σ 1 , ···,σ n ]) ≡
dla przynajmniej n − t różnych j, σ j jest poprawnym podpisem S
P j dla ( ID, a-queue, r, j, w j ) j
ROZPOCZĘCIE :
q ← [] kolejka FIFO dla wiadomości a-broadcast
d ←∅ zbiór wiadomości a-delivered
r ← 0 bieżąca runda
PO ODEBRANIU WIADOMOŚCI ( ID, in, a-broadcast, m ):
if m/∈ d and m/∈ q
then append(q, m)
ZAWSZE:
w j ←⊥; σ j ←⊥ (1 ≤ j ≤ n)
wait for q ≠[] or odebrano wiadomość ( ID,a-queue,r,l,w l , σ l ) l
taką, że w l /∈ d oraz σ l jest poprawnym podpisem od P l
if q ≠[]
then w ← first(q)
else w ← w l
wyznacz podpis σ dla ( ID,a-queue,r,i,w ) i
send ( ID,a-queue,r,i,w, σ ) i do wszystkich P
wait for n − twiadomości ( ID,a-queue,r,j,w j , σ j ) j ,
takich, że σ j jest poprawnym podpisem od P j
W ← [w 1 , ···,w n ]; S ← [σ 1 , ···,σ n ]
v-propose W potwierdzone przez S
oznaczone ID|abc.r z predykatem Q ID|abc.r
wait for zakończenie VBA z V =[v 1 , ···,v n ] oznaczonego ID|abc.r
b ← ⋃ n
j=1 v j
for m ∈ (b \ d) w uporządkowany sposób
⎧
zakończ ( ID,out,a-deliver,m) i
⎪⎨ wait for potwierdzenie dla m
do
d ← d ∪{m}
⎪⎩
remove(q, m)
r ← r +1

3.5 Podsumowanie 59
Protokół 3.5.4: Secure Causal Atomic Broadcast - SC-ABC
dla uczestnika P i oraz znacznika ID
ROZPOCZĘCIE :
otwórz kanał dla atomowego rozgłaszania ID|scabc
PO ODEBRANIU WIADOMOŚCI ( ID, in, s-broadcast, c ):
a-broadcast c ze znacznikiem ID| scabc
ZAWSZE:
wait for kolejną wiadomość c a-deliver ze znacznikiem ID|scabc
oblicz E 1 udział δ odszyfrowujący dla c oznaczony ID
zakończ ( ID, out, s-schedule, c ) i
send ( ID, s-decrypt, c, δ ) i do wszystkich P
δ j ←⊥ (1 ≤ j ≤ n)
wait for t +1wiadomości ( ID, s-decrypt, c, δ j ) j od różnych j
zawierających poprawny udział odszyfrowujący dla c oznaczony ID
scal wszystkie udziały δ 1 , ···,δ n by uzyskać wiadomość m
zakończ ( ID, out, s-reveal, m ) i
wait for na potwierdzenie
zatwierdź ostatnią wiadomość a-delivered oznaczoną ID|scabc

Rozdział 4
Tolerowanie bizantyjskich
uszkodzeń
Trudno jest spełnić wymagania przedstawionych w poprzednim rozdziale algorytmów,
ale trudno też nie docenić praktycznego podejścia prezentowanego w
BFT oraz matematycznej poprawności SC-ABC. Naturalnym sposobem postępowania
byłoby połączenie obu pomysłów, tak by sprostać wymaganiom, które
stawiają systemy peer-to-peer. Chodzi przede wszystkim o dużą dynamikę zmian
struktury systemu i brak wzajemnego zaufania współpracujących węzłów.
W tym rozdziale przedstawiłem projekt algorytmu tolerowania bizantyjskich
uszkodzeń w systemach peer-to-peer opracowany w ramach pracy magisterskiej.
W pierwszej kolejności umieszczono opis algorytmu naiwnego. Zostały przedstawione
wymagania i założenia projektowe. Opisano pierwszą wersję protokołu,
tzw. zachłanną, by potem przejść do wersji optymistycznej 1 . W następnej kolejności
zostały opisane założenia i właściwości jakie spełnia zaproponowany
algorytm oraz sposóby utworzenia grupy replik, co zostało pominięte przez autorów
algorytmów BFT i SC-ABC. W dalszej części rozdziału przedstawiłem
protokół wykonania zleceń zbudowany na bazie uzgadniania wielowartościowego,
takiego samego jak w BFT. Pokazałem też prostą technikę uzgadniania
stanu wraz ze sterowaniem częstością wykonania migawek. Na koniec zostały
opisane modyfikacje podstawowego algorytmu, które prowadzą do jego wersji
optymistycznej.
1 Zarówno BFT, jak i SC-ABC posiadają wersje optymistyczne, które działają przy słabszych
założeniach. Gdy protokół optymistyczny zawodzi, stosuje się wersję zachłanną
[CL99c, CKPS01].

62 Rozdział 4. Tolerowanie bizantyjskich uszkodzeń
4.1 Algorytm naiwny
W poprzednim rozdziale znalazł się opis dwóch bardzo skomplikowanych algorytmów
tolerowania bizantyjskich uszkodzeń w grupie replik. Rozwiązania te
są kompletne i nadają się do praktycznego zastosowania, jednak w wielu przypadkach
będą trudne do implementacji. Pewien stopień tolerancji bizantyjskiego
zachowania przy bardzo restrykcyjnych założeniach można uzyskać stosując algorytm
uproszczony (naiwny):
• Klient tworzy zlecenie i c , a następnie wyszukuje wszystkie znane mu repliki
świadczące usługę u i zleca wykonanie i c przez każdą z nich.
• Po odebraniu f +1 takich samych odpowiedzi v zwróconych przez repliki,
klient kończy wykonanie, przyjmując v = u(i c ).
• Jeżeli takich samych odpowiedzi jest mniej niż f +1, to doszło do załamania
usługi lub liczba replik jest n

4.2 Założenia projektowe 63
(a)
(b)
Rysunek 4.1: Algorytm naiwny. (a) Klient bezpośrednio rozsyła zlecenia do
replik. (b) Wielu klientów używa pośrednika w celu wysłania zleceń.
BFT, natomiast decentralizacja i techniki kryptograficzne prowadzą do algorytmu
SC-ABC. Okazuje się, że możliwym jest osiągnięcie pośredniego schematu
działania, który nie będzie zakładał istnienia elementu centralnego, co jest
niewskazane w systemach luźno powiązanych (np. peer-to-peer) i który będzie
stosunkowo elastyczny ze względu na zarządzanie składem grupy replik.
4.2 Założenia projektowe
W skład grupy komunikacyjnej wchodzi k replik, gdzie k ≥ 3f +1, f oznacza
liczbę replik działających w sposób bizantyjski, tak jak zostało to zdefiniowane
w poprzednim rozdziale. Każda z replik jest ponumerowana 2 i ∈{0, ..., k}. Replika
i posiada klucze symetryczne używane do komunikacji z każdą inną repliką
wchodzącą w skład grupy sk ij ,i∈{0, ..., k}, i≠ j oraz parę kluczy: klucz publiczny
pk i , klucz prywatny sk i . Repliki działają niezależnie i żadna z replik nie
jest wyróżniona jako replika główna. Wiadomość wysyłaną przez replikę oznaczymy,
podobnie jak w przypadku BFT, przez σi , gdzie σ i oznacza podpis
wykonany przy użyciu funkcji skrótu zainicjowanej kluczem repliki i lub kluczem
prywatnym. Skrót kryptograficzny wiadomości m będzie oznaczany przez
H(m). Zakładamy iż unikamy kryptografii z kluczem publicznym, zatem w domyśle
podpis i jest wykonany przy użyciu odpowiedniego klucza symetrycznego
k ij współdzielonego z repliką j, do której zostanie wysłana wiadomość.
Protokół musi spełniać następujące wymagania:
• Bezpieczeństwo wykonania (ang. safety) - błędy wykonania, bądź uszkodzenia
nie mogą powodować wstrzymania pracy grupy replik.
2 Numerowanie replik wprowadzone jest dla ułatwienia opisu algorytmu. W praktycznej
realizacji wymagane jest tylko, by repliki były w stanie odróżnić siebie nawzajem.

64 Rozdział 4. Tolerowanie bizantyjskich uszkodzeń
• Żywotność (ang. liveness) - zlecone operacje zostaną wykonane w skończonym
czasie t

4.2 Założenia projektowe 65
• Poczta elektroniczna (wielu piszących, jeden czytający). Obiektem jest
skrzynka pocztowa. Wystarczy, że dostęp do skrzynki będzie realizowany z
zachowaniem rozłączności operacji wykonywanych przez różnych klientów
(operacje nie przeplatają się). Nie istnieje operacja modyfikacji uprzednio
wysłanych wiadomości.
• Usługa nazewnicza (jeden piszący, wielu czytających). Obiektem jest pojedynczy
rekord < nazwa, adres >. W tym przypadku, występuje tylko
jeden piszący i w zasadzie nie trzeba się zbytnio przejmować spójnością
danych, za wyjątkiem takich zastosowań, które wymagają bezwzględnej
poprawności i świeżości odczytywanych danych.
• Komunikacja natychmiastowa (ang. instant messaging) (jeden piszący,
jeden czytający). Obiektem jest komunikacyjny bufor wiadomości. To
zastosowanie jest bezpośrednim odzwierciedleniem problemu producentkonsument.
W tym przypadku, ważne jest, by operacje odczytu zwracały
wiadomości zgodnie z ich kolejnością napływania.
• Obliczenia i koordynacja rozproszona (wielu piszących, wielu czytających).
Obiekt jest elementem obliczeniowym lub semaforem. W tym
przypadku kolejność wykonywanych obliczeń ma zasadnicze znaczenie i
ważne jest zagwarantowanie przynajmniej deterministycznego zachowania
usługi, tzn. ta sama sekwencja operacji zlecona przez wielu klientów
zwróci taki sam wynik końcowy przy takim samym stanie początkowym
usługi.
Przytoczone przykłady rzeczywistych zastosowań usprawiedliwiają realizację
słabszego typu spójności niż spójność sekwencyjna, czy nawet liniowa. Wydaje
się, że sprostanie warunkom stawianym przez rzeczywiste zastosowania wymaga
zapewnienia spójności przyczynowej (ang. causal consistency) 5 , chociaż w systemie
peer-to-peer będzie to trudne do zapewnienia.
Niezawodne rozgłaszanie. Protokół uzgadniania wymaga użycia niezawodnego
rozgłaszana podczas wysyłania komunikatów do członków grupy. Dlaczego? W
momencie otrzymania zlecenia od klienta replika powinna rozesłać zlecenie do
wszystkich pozostałych replik, a następnie czekać na nadejście odpowiedzi. Gdy
nie ma gwarancji na dostarczenie komunikatu do wszystkich działających replik,
nadawca nie ma pewności, czy wszystkie poprawnie działające repliki otrzymały
komunikat. Może okazać się, że podczas rozgłaszania, któraś z replik się odłączyła,
nadawca uległ awarii lub zakończył działanie. Niezawodne rozgłaszanie
daje grupie wiedzę na temat jej aktualnego składu, czyli repliki mogą decydować
5 Operacje wpływające na siebie, powinny zachować porządek wykonania.

66 Rozdział 4. Tolerowanie bizantyjskich uszkodzeń
o tym, które zlecenia zostaną wykonane a które nie. Warto zauważyć, że usługa
niezawodnego rozgłaszania nie koniecznie musi gwarantować w tym przypadku
całkowite uporządkowanie komunikatów (ang. totally ordered multicast), czy
właściwość atomowego rozgłaszania (ang. atomic multicast), która zapewnia, że
wiadomość zostanie dostarczona do wszystkich aktywnych uczestników lub do
nikogo. Zapewnienie niezawodnego rozgłaszania jest konieczne, gdyż wszystkie
poprawnie działające repliki muszą dowiedzieć się o tym, które zlecenia zostały
przez nie pominięte i które powinny wykonać, by pozostać w synchronizacji z
innymi replikami.
Ogólny opis działania protokołu. Węzeł po włączeniu się do systemu zostaje
przyłączony do grupy replik, których identyfikatory znajdują się w jego otoczeniu.
Jest on zapraszany do istniejącej grupy replik lub tworzy własną grupę.
W pierwszym przypadku, węzeł pobiera stan i zaczyna uczestniczyć w wykonywaniu
protokołu, natomiast w drugiej sytuacji zaprasza szereg replik do swojej
grupy, do momentu gdy osiągnie ona oczekiwany rozmiar.
Klient c, może wysłać zlecenie r c s do dowolnej repliki i, przy czym zlecenia
muszą być kolejno ponumerowane przez klienta używając odpowiedniego s.
Repliki działają spełniając zlecenia w rundach r g numerowanych kolejno. Runda
składa się z grupy zleceń odebranych przez repliki od momentu rozpoczęcia poprzedniej
rundy do chwili bieżącej. Rundy są mechanizmem, który wprowadza
pewien stopień synchronizacji w protokole, podobnie jak ma to miejsce BFT w
przypadku stosowania techniki widoków.
Zaletą wykonania zleceń w rundach w stosunku do wirtualnej synchroniczności
jest rzadka konieczność interwencji, nawet gdy któraś z replik przestałaby
odpowiadać. W BFT należy przeprowadzić zmianę widoku zawsze gdy zawodzi
replika główna, a wyznaczenie nowej repliki głównej wymaga ponumerowania
replik. Długość rundy może zostać ograniczona, ale wskazane jest, by repliki
dopasowywały długość okna rundy dla wykonania zleceń w zależności od obciążenia,
podobnie jak w sterowaniu częstością zapisu stanu.
Replika otrzymując zlecenie od klienta rozsyła komunikat rozpoczynający
kolejną rundę vote-request i czeka na akceptację od 2f +1 replik uwzględniając
siebie samą, które w odpowiedzi rozgłaszają wektor R j zawierający zlecenia,
które repliki chcą wykonać w danej rundzie. Każda replika składa wszystkie
wektory odpowiednio uwzględniając kolejność wykonania i rozsyła wektor R g
do reszty replik, następnie czeka na 2f +1 takich samych odpowiedzi od różnych
replik uwzględniając siebie samą. Po zebraniu wymaganej liczby komunikatów
replika wybiera pierwsze zlecenie z R g i rozgłasza wiadomość przygotowania
prepare dla tego zlecenia i ponownie czeka na odpowiednią liczbę komunikatów.
W następnej kolejności rozsyła wiadomość pre-commit zawierającą wynik
wykonania zlecenia. Komunikat commit, zostaje wysłany na końcu w celu za-

4.3 Zestaw dostępnych operacji 67
r 1
1
Prepare{r 11 }
Commit{r 11 }
0
1
2
3
r 2
1
R g
{r 1 1 , r 12 }
R g { r 12 }
Vote-request
Pre-commit{r
11 }
Rysunek 4.2: Szkic działania protokołu dla grupy czterech replik i nadesłania
zleceń przez dwóch klientów.
twierdzenia wykonania i musi zostać potwierdzony przez co najmniej f +1
replik. Opisana procedura odpowiada protokołowi trójfazowego zatwierdzania
[TS01].
W przypadku, gdy replika j wysłała już komunikat vote-response z podanym
wektorem R j , wstawia wszystkie napływające zlecenia do swojej kolejki
i po zakończeniu bieżącej rundy sama może zainicjować nowe wykonanie wysyłając
vote-request. Mechanizm rund wprowadza do protokołu pewien stopień
synchroniczności, gdyż repliki muszą uzgodnić wykonanie zanim przejdą do
fazy realizacji zleceń. Tutaj należy mieć na uwadze twierdzenie wprowadzone
w rozdziale trzecim, które neguje istnienie protokołu, który byłby całkowicie
asynchroniczny i pozwalał grupie replik dojść do konsensusu w obecności błędów.
4.3 Zestaw dostępnych operacji
Protokół bizantyjskiego uzgadniania pozwala na replikację usługi, dlatego można
w oparciu o ten protokół zrealizować więcej operacji, niż tylko put,get,delete,
które tworzą ogólny interfejs DHT [DZDS03], ale również zaproponowaną w
BFT operację invoke. Nazewnictwo metod pozostanie zgodne z obowiązującym
wsystemiePast [RD01a], który implementuje rozproszoną tablicę z kodowaniem
mieszającym dla obiektów, zbudowany na bazie warstwy komunikacyjnej
Pastry. Past nie umożliwia zlecania wykonania operacji na obiektach, jak
również nie jest odporny na bizantyjskie uszkodzenia. Zaprojektowano system
bardzo podobny do Past o nazwie OceanStore opracowany w Berkeley University
of California [KBC + 00], w którego prototypie Pond [REG + 03], zaimple-

68 Rozdział 4. Tolerowanie bizantyjskich uszkodzeń
mentowano częściowo algorytm SC-ABC. OceanStore zbudowane jest używając
Tapestry - warstwy komunikacyjnej peer-to-peer, która zdaje się mieć słabszą
wydajność w przekazywaniu komunikatów niż Pastry, jednak gwarantuje większą
niezawodność [LKRG03, ZHS + 03, RD01b]. Projektowany system będzie
realizował następujące, podstawowe operacje:
insert (id, creds, object) - wprowadza obiekt identyfikowany przez globalnie
unikalny identyfikator id do systemu wraz z uprawnieniami creds 6 .
lookup (id, creds, object*) - zwraca obiekt zidentyfikowany przez id weryfikując
operację przy użyciu uprawnień creds.
invoke (id, creds, operation, params, results*) - wywołuje operację na
obiekcie identyfikowanym przez id pod warunkiem poprawnej weryfikacji
uprawnień creds. Wynik operacji zwracany jest w zmiennej results.
remove (id, creds) - usuwa obiekt z systemu o identyfikatorze id pod
warunkiem poprawnej identyfikacji uprawnień creds.
Podział na wyżej wymienione metody wynika z ich różnorakiej obsługi przez
grupę replikującą. Operacja insert rozpoczyna działanie protokołu na rzecz
konkretnego obiektu. Usługa powinna stać się dostępna, gdy będzie wiadomo,
że obiekt został umieszczony w przynajmniej 2f +1 replikach. Na rysunku
4.3 pokazano różne możliwe typy zachowania klienta i grupy replik podczas
wprowadzania obiektu. W pierwszym przypadku (a) klient stara się wprowadzić
obiekt do systemu, jednak replika, do której wysłał zlecenie jest nieuczciwa i nie
wypycha kopii obiektu do innych replik; (b) klient rozsyła wiadomość do kilku
replik i czeka na odpowiedzi; (c) klient ponownie wysyła komunikat do jednej
z replik i czeka na odpowiedź od różnych replik, gdy otrzymają one obiekt.
Gdy obiekt zostanie poprawnie umieszczony w systemie, to grupa replik
może zacząć przetwarzanie napływających zleceń. Rozpatrując operację lookup,
łatwo można zauważyć, że nie modyfikuje ona stanu obiektu i może zostać obsłużona
nawet przez jedną replikę, jednak wymaga również rozpatrzenia kilku
przypadków, gdyż klient może np. wymagać potwierdzenia stanu odebranego
obiektu od większości replik w grupie. Wywołanie invoke jest operacją modyfikującą
stan obiektu, dlatego konieczne jest ustalenie kolejności realizacji zleceń
przez repliki i zatwierdzenie stanu końcowego. Tu niezbędnym jest wprowadzenie
protokołu uzgadniającego stan. Zakończenie działania protokołu na rzecz
obiektu zachodzi, gdy zostanie odebrane zlecenie remove. Usunięcie obiektu
6 Mechanizm zarządzania i weryfikacji uprawnień został naszkicowany w następnym rozdziale,
który dotyczy projektu systemu Pastor. Na chwilę obecną wystarczy założyć, że uprawnienia
jednoznacznie określają, kto i jakie operacje może wykonać.

4.4 Protokół zachłanny 69
(a)
(b)
(c)
Rysunek 4.3: Operacja utworzenia kopii obiektu z uwzględnieniem niepoprawnie
działających replik, f = 1. (a) Klient wykonuje jedną kopię, która zostaje
zniszczona. (b) Klient wykonuje 2f +1kopii, jedna replika nie odpowiada. (c)
Klient wykonuje jedną kopię, która zostaje wysłana do innych replik. Klient
czeka na 2f +1odpowiedzi.
musi odbyć się z zachowaniem kolejności napływających operacji. Dalsze wywołania
dotyczące usuniętego obiektu nie mogą być już dalej obsługiwane.
4.4 Protokół zachłanny
W tym paragrafie zostanie opisany protokół zachłanny, który realizuje pełną replikację
usługi, odporną na błędy bizantyjskie. Protokół gwarantuje poprawność
tak długo, jak tylko liczba replik działających w sposób bizantyjski nie przekracza
f podczas wykonania.
Inicjacja grupy replik 7 . Zakładamy, że replika może zostać zaproszona do
grupy replikującej lub sama zaprosić inne węzły do grupy tworzonej przez siebie
samą, natomiast nie może sama przyłączyć się do którejś z grup. Skąd bierze
się takie ograniczenie? Po podłączeniu do systemu węzeł może być „bezrobotny”
w tym sensie, że nie należy do żadnej grupy replik i nikt jeszcze nie wysłał do
7 Zarówno w SC-ABC, jak i BFT nie opisano, w jaki sposób grupa replik powinna zostać
utworzona zostawiając to zagadnienie do rozpatrzenia przez projektantów systemów pod kątem
konkretnego zastosowania. Tworzenie grupy replik określa się często fazą rozdania (ang. deal
phase).

70 Rozdział 4. Tolerowanie bizantyjskich uszkodzeń
(a)
(b)
group-create
failure-detection
group-invite
Rysunek 4.4: Inicjacja grupy replik. (a) Replika tworzy zupełnie nową grupę
używając komunikatu group-create. (b) Replika jest zaproszona do grupy w
miejsce uszkodzonej, rozgłaszany jest komunikat group-invite.
niego zlecenia zapamiętania obiektu. Nie oznacza to, że w towarzystwie węzła
nie ma grup replikujących, które realizują zlecenia. Widocznie w tym czasie
nowa replika nie jest potrzebna. Pomimo tego, węzeł, który dopiero co włączył
się do systemu, powinien spróbować utworzyć własną grupę replik, gdyż za
chwilę może otrzymać zlecenie zapamiętania obiektu. Nie należy zwlekać, gdyż
tworzenie grupy w chwili otrzymania pierwszego zlecenia znacznie obniżałoby
wydajność, ponieważ utworzenie nowej grupy jest bardzo pracochłonne. Gdybyśmy
zezwolili na swobodne przyłączanie do grupy replik możliwym stałoby
się, że kilka replik sparaliżowałaby pracę przyłączając się i odłączając dowolnie
często.
Rozpatrzę sytuację, gdy nowa grupa replik tworzona jest przez węzeł:
1. Do znanych węzłów rozsyłany jest komunikat propozycji utworzenia grupy
< group-create, i id , g id , G> σi . Identyfikator i id jest identyfikatorem węzła
proponującego utworzenie grupy, g id jest wygenerowanym identyfikatorem
grupy, natomiast G to wektor identyfikatorów węzłów, do których został
nadany komunikat włączając też twórcę grupy.
2. W odpowiedzi węzły rozgłaszają komunikat do wszystkich węzłów w G,
który precyzuje, czy chcą przyłączyć się do grupy, czy też nie 8 < groupjoin,
j id , v> σj , gdzie v = {0, 1} w zależności od odpowiedzi.
3. Każdy z węzłów zbiera odpowiedzi i składa je w wektor J otakimsamym
uporządkowaniu jak G, gdzie J(j) =1, gdy uczestnik o identyfikatorze
8 Nie ma przymusu przy włączaniu się do grupy.

4.4 Protokół zachłanny 71
G(j) wyraził chęć przyłączenia się do grupy J(j) =0, w przypadku odmowy,
oraz J(j) =−1, gdy węzeł odpowiedzi nie otrzymał. Rozpoczęcie
składania wektora J powinno nastąpić w momencie otrzymania:
⌊ ⌋ 2n +1
k> ,
3
gdzie n oznacza liczbę węzłów w G. WektorJ rozgłaszany jest do wszystkich
węzłów w G, < group-prelist, J> σj . Wartość k w tym przypadku
oznacza większość 2 węzłów w G, które odpowiedziały. Jeżeli dalej
3
wszystkie węzły włączą się do grupy to zakładamy, że jedna trzecia z
nich może nadal być nieuczciwa. Wniosek jest taki, że węzeł chcąc osiągnąć
grupę, w której f węzłów może być podejrzanych o nieuczciwość,
musi rozesłać propozycję przyłączenia się do grupy, do co najmniej
n ≥ 9 2 f +1
Ostatnia zależność wynika z warunku na k oraz warunku na liczbę replik
jaka musi istnieć w grupie, by uzgodnienie było możliwe n ≥ 3f +1.
Dla przykładu, gdy f =1,ton musi być większe bądź równe 6. Pojawia
się pytanie, co zrobić gdy nie uda się spełnić tego warunku. Pozostaje
stworzyć grupę z tylu replik, z ilu jest to możliwe.
4. Kolejną fazą jest wymiana kluczy szyfrujących. Każda z replik powinna
posiadać klucze sesyjne współdzielone z innymi replikami należącymi do
grupy, w celu weryfikacji i szyfrowania wysyłanych komunikatów. Węzeł
j wybiera kolejno węzeł G(l), l =(j + i) mod n, i ∈{1,...,n},
dla którego J(k) =1i rozpoczyna z nim proces uzgadniania klucza, np.
używając algorytmu Diffie-Hellman’a [MVO96]. Gdyby wybrany węzeł
nie odpowiedział lub gdy klucz został już ustalony, wybiera się kolejny
węzeł. Przejście po elementach G(l) powinno odbyć się więcej niż jeden
raz, by ponowić próbę ustalenia klucza dla tych węzłów, z którymi
nie udało się tego przeprowadzić w uprzedniej iteracji. Technika przechodzenia
po wektorze G począwszy od kolejnej repliki za inicjującym
negocjację, jest bardzo prostą techniką równoważenia obciążenia podobną
do algorytmu karuzelowego (ang. round robin). Po określonej liczbie prób
węzeł dysponuje kluczami dla grupy replik. Zakończenie tej fazy powinno
być rozgłoszone < group-postlist, Ĵ > σj , gdzie Ĵ jest wektorem o tych
samych elementach co J z naniesioną informacją o tym, z kim udało się
wynegocjować klucz.
5. Odebranie przynajmniej k wiadomości group-postlist, w których przynajmniej
k elementów jest równych 1 kończy fazę tworzenia grupy.

72 Rozdział 4. Tolerowanie bizantyjskich uszkodzeń
Podczas wykonania algorytmu może okazać się, że jakaś z replik przestała
działać, tak jak zostało to przedstawione na rysunku 4.2. Gdy awaria, którejś z
replik zostanie wykryta oraz liczba replik jest na granicy gwarancji poprawnego
działania protokołu, to powinno nastąpić uruchomienie procedury zaproszenia
nowejreplikidogrupy 9 :
1. Replika i rozgłasza komunikat < group-invite, g id , G, r g , j > σi do węzła
j znajdującego się w sąsiedztwie grupy oraz do reszty replik w G. G jest
wektorem wszystkich identyfikatorów replik, które przynależą do grupy
oznaczonej g id .
2. Węzeł zaproszony j odpowiada komunikatem < group-join, j, G> σj do
wszystkich węzłów w G. Następnie j wykonuje procedurę negocjacji klucza
z węzłami w G opisaną uprzednio i buduje wektor J, który rozgłasza
po zakończeniu procedury < group-prelist, J> σj , czeka na odpowiedzi od
poszczególnych uczestników i buduje wektor Ĵ, który następnie rozgłasza.
3. Kolejny krok prowadzi do pobrania i uzgodnienia aktualnego stanu usługi.
Replika wysyła komunikat < state-request, j, r g > σj , gdzie r g jest numerem
rundy, dla której replika zna ostatni stabilny stan 10 . W przypadku, gdy
replika nie zna żadnego stabilnego stanu wysyła r g =0. Odpowiadając
repliki wysyłają < state-response, i, r g , H(s) > σj . Replika po potrzymaniu
2f +1 takich samych odpowiedzi od różnych replik przystępuje do
pobrania stanu. Replika może wykonać tę operację równolegle pobierając
tylko pewne części stanu od różnych replik wysyłając komunikat < statefetch,
j, H(s), p> σj , p oznacza numer fragmentu. Pobranie może być
zrealizowane podobnie, jak w protokole BitTorrent (opisany w rozdziale
pierwszym) odbywa się pobieranie zasobu, gdyby stan usługi okazał się
być bardzo duży (pobranie nawet 1MB na chwilę pisania tej pracy, może
okazać się problematyczne).
4. Oczywiście może okazać się, że stan, którym dysponuje replika tuż po
transferze zdążył się już zestarzeć, dlatego musi on zostać jeszcze odświeżony.
Po zakończeniu pobierania stanu replika rozgłasza < state-update,
j, r g , H(s) > σj . W odpowiedzi repliki wysyłają komunikat < state-renew,
i, r ′ g , R(s) > σ i
, gdzie R(s) jest listą list wszystkich zleceń, które należy
wykonać aby przejść ze stanu s do stanu s ′ i do obowiązującej rundy r ′ g,
spójnej z innymi replikami. Lista R(s) ma r ′ g − r g list, w których znajdują
się zlecenia dla każdej wykonanej rundy.
9 W następnym rozdziale zostanie pokazane, w jaki sposób konstruować rzeczywistą grupę,
by zapewnić maksymalny stopień odporności na uszkodzenia.
10 Ten parametr będzie używany w momencie powtórnego przyłączania repliki.

4.4 Protokół zachłanny 73
Uzgadnianie wielowartościowe. Zanim repliki przystąpią do wykonania zlecenia
muszą tą czynność potwierdzić za pomocą wielowartościowego uzgadniania
opisanego w poprzednim rozdziale. Protokół realizujący wykonanie zleceń nadsyłanych
do grupy przez klientów jest wykonywany w następujących krokach:
1. Gdy replika i otrzyma zlecenie r c s wysyła komunikat < vote-request, r g ,
R i = r c s > σi do wszystkich replik, gdzie r g , to aktualny numer rundy,
a R i , to wektor zleceń, w tym przypadku zakładamy, że replika nie posiadała
żadnych zleceń w kolejce Q i . Gdyby okazało się, że w kolejce
są zlecenia, to powinny zostać umieszczone na początku wektora R i ,tak
by zlecenia były ułożone z rosnącym porządkiem sekwencji s rozpatrując
poszczególnych klientów (np. R i = {r 1 1 ,r 1 2 ,r 3 2 ,,...}). Warto zauważyć,
że sposób uporządkowania elementów w R i ustawia zlecenia nadane przez
tych samych klientów w jednej grupie. Takie postępowanie zapewnia brak
wystąpienia konfliktów typu zapis-zapis w obrębie jednej rundy.
2. Odebranie komunikatu < vote-request, r g , R j = r s c > σj nakłada obowiązek
rozesłania odpowiedzi przez replikę, używając komunikatu < voteresponse,
r g , R i > σi . Jeżeli r g okazałoby się nieprawidłowe, to replika
powinna odpowiedzieć komunikatem z poprawnym r g . Komunikat voteresponse
powinien zostać nadany wtedy i tylko wtedy, gdy replika wcześniej
nie wysłała własnego komunikatu vote-request dla rundy o numerze
r g . Replika otrzymawszy f +1 wiadomości z r g , różnym od własnego, ale
takim samym znaczniku, powinna wprowadzić korektę i rozesłać jeszcze
raz vote-response z poprawnym r g .
3. Zgromadzenie przez i-tą replikę 2f +1 odpowiedzi vote-response uwzględniając
siebie samą i/lub vote-request rozpoczyna fazę uzgadniania. Wektory
R j składane są przez replikę w jeden wektor R g zachowując porządek
taki sam jak w R i , który następnie jest rozgłoszony < request-ready, r g ,
R g > σi .Zebranief +1 takich samych komunikatów request-ready, może
rozpocząć fazę przetwarzania zleceń.
4. Protokół, który realizuje wykonanie każdego zlecenia składa się z trójfazowego
uzgadniania każdego wykonania:
• Pierwszym komunikatem rozsyłanym przez replikę, jest < prepare,
r g , H(R g (k)) > σi dla k-tego zlecenia w wektorze R g .
• Po odebraniu 2f +1 komunikatów prepare dla zlecenia R g (k), replika
wykonuje żądanie i wysyła komunikat < pre-commit, r g , V g (k)
> σi , który po odebraniu od 2f +1 powinien zostać potwierdzony komunikatem
< commit, r g , H(V g (k)) > σi , co ostatecznie zatwierdza
wykonanie operacji R g (k).

74 Rozdział 4. Tolerowanie bizantyjskich uszkodzeń
• Potwierdzenie zebrane od f +1 replik wystarcza, by zatwierdzić
zlecenie i wysłać odpowiedź klientowi 11 , jednak dopiero 2f +1potwierdzeń
jest dowodem tego, że stan replik jest spójny i może zostać
zatwierdzony.
• Przetwarzanie odbywa się tak długo, jak w wektorze R g pozostają
zlecenia do wykonania.
Protokół opisany w tym paragrafie będzie dalej oznaczany symbolem BF2.
Wzajemne wykluczanie. Ponieważ wszystkie repliki w grupie wykonują zlecenia
uporządkowane według kolejności w R g , zatem istnieje potencjalna możliwość
łatwego poszerzenia algorytmu o wzajemne wykluczanie. W tym celu
klient c wysyła na początku specjalne zlecenie zajęcia usługi (ang. lock) . Repliki
napotykając zlecenie lock wwektorzeR g sprawdzają czy wśród reszty
zleceń od tego samego klienta, który zamówił obiekt jest zlecenie zwolnienia
(ang. release). Jeżeli zlecenie release znajduje się w R g to repliki nie robią nic.
Jeżeli natomiast zlecenie to nie występuje, to resztę zleceń ustawiają w kolejce
typu FIFO oznaczonej np. Q Rg , wykonują zlecenia klienta c i przechodzą do
następnej rundy. Zlecenia zebrane w kolejnej rundzie są ustawiane na koniec kolejki
Q Rg jeżeli pochodzą od innych klientów, aż do momentu napotkania relase
od klienta c. Wtedy w kolejnej rundzie wykonuje się zlecenia zebrane w Q Rg .
Należy zagwarantować, by podczas wykonania nie wystąpiło przywłaszczenie
usługi, tzn. że tylko jeden klient ciągle będzie zajmował obiekt. W tym celu
można użyć następującego algorytmu:
Załóżmy, że znamy identyfikatory wszystkich klientów 12 . Z każdym identyfikatorem
kojarzymy licznik początkowo równy zero. Gdy klient otrzyma wyłączny
dostęp do obiektu, to jego licznik zostaje pomniejszony o jeden, a liczniki
wszystkich innych klientów zostają powiększone o jeden. Wartość wskazania
licznika nie może być mniejsza od zera, czyli gdy licznik osiągnie zero to odjęcie
od tej wartości jedności nie zmienia wskazania. W momencie pojawienia się
kolejnego zlecenia zamówienia obiektu dla kilku różnych klientów, sprawdzany
jest stan licznika i ten klient dostanie wyłączny dostęp, dla którego licznik ma
większą wartość. Procedura po przyznaniu wyłącznego dostępu odejmuje jeden
od licznika klienta, natomiast pozostałym dodaje jeden. Algorytm jest odporny
na zagładzanie, jednocześnie gwarantuje, że jeżeli tylko jeden z klientów będzie
nieustannie żądał dostępu, to będzie on mu przyznawany. Ilustrację działania
11 Zalecane jest użycie schematu przyrostowych podpisów cyfrowych, który pozwala zapamiętać
szereg podpisów stanu, jako jeden spójny podpis, który można następnie łatwo weryfikować.
W innym przypadku odpowiedź na zlecenie r s c jest wysyłana przez wszystkie repliki.
12 Takie założenie jest bardzo mocne, ale jest wprowadzone tylko dlatego, żeby łatwiej wyjaśnić
sposób działania algorytmu. Warunek ten zostanie później osłabiony.

4.4 Protokół zachłanny 75
(a)
(b)
K1
K2
K3
K4
K1
K2
K3
K4
lock
lock
lock
Q: {K1}
K1
1
K2
0
K3
1
K4
1
K1
2
K2
1
K3
0
K4
2
Rysunek 4.5: (a) Obiekt jest zamawiany przez klienta K1, liczniki pozostałych
klientów są powiększane. (b) Obiekt chce zająć klient K1 oraz K2. Licznik
K2 był uprzednio większy od K1 dlatego jemu pierwszemu przydzielany jest
wyłączny dostęp. K1 czeka w kolejce.
algorytmu gwarantującego sprawiedliwy dostęp pokazano na rysunku 4.5. W
praktycznej realizacji należy pamiętać liczniki tylko dla klientów wysyłających
zlecenia lock. Dla reszty klientów wartość licznika, jest sumą wszystkich zrealizowanych
leceń, co osłabia początkowe założenie. Sytuacja, w której klient,
blokujący obiekt, ulega awarii wymaga cofnięcia operacji przez niego wykonanych.
Rozpoznanie, czy klient działa prawidłowo można zrealizować poprzez
mechanizm czasowej dzierżawy (ang. lease) [TS01]. Dzierżawa polega na tym,
że klient co jakiś czas wysyła komunikat odnowienia blokowania. Jeżeli zdarzyłoby
się, że zlecenie odnowienia nie przyjdzie w określonym specjalnie interwale
czasu, to obiekt zostaje zwolniony.
Przyłączanie i odłączanie repliki. Często zdarza się, że węzeł odłączy się
jedynie na chwilę, a po upływie niewielkiego czasu powraca do grupy. Oczywiście
dobrze, by przed rozłączeniem replika oznajmiła chęć swojego opuszczenia
grupy np. rozsyłając komunikat < group-leave, i> σi . Ponowne przyłączenie,
może odbyć się po wykonaniu następujących kroków:
1. Replika chcąc przyłączyć się ponownie do grupy, rozgłasza komunikat <
group-rejoin-request, i, r g > σi , podobnie jak miało to miejsce w przypadku
przyłączania nowej repliki. Replika nie posiada informacji o tym, czy stan
grupy zdążył się zmienić od jej ostatniego wyłączenia, dlatego musi tę
wiedzę uzyskać od innych replik.
2. Uprzednio wysłany komunikat może nie dotrzeć do części członków, o
których wiedziała replika j, gdyż stan grupy mógł się zmienić. Repliki

76 Rozdział 4. Tolerowanie bizantyjskich uszkodzeń
(a)
(b)
group-leave
group-rejoin
rejoin
Rysunek 4.6: Odłączanie i przyłączanie repliki do grupy. (a) Replika oznajmia
swoje odłączenie rozsyłając komunikat group-leave. (b) Ponownie włączając się
do grupy replika najpierw rozgłasza group-rejoin. Konieczne jest ustalenie przez
ponownie przyłączającą się replikę, aktualnego składu grupy.
odpowiadają komunikatem < group-rejoin-response, j, r ′ g, H(s), G j > σj ,
gdzie G j jest wektorem węzłów znanych przez replikę j.
3. Replika powiadamia węzły w G, których nie zna, że ponownie przyłącza
się do grupy. Z nieznanymi jej uczestnikami musi wynegocjować klucze
oraz zaktualizować stan podobnie, jak nowo przyłączająca się replika. Węzeł
i wykonuje opisaną procedurę negocjacji klucza z węzłami w G, których
nie zna budując wektor, który rozgłasza po zakończeniu procedury
< group-rejoin-prelist, J > σj , czeka na odpowiedzi od poszczególnych
uczestników i buduje wektor Ĵ, który ponownie rozgłasza < group-rejoinpostlist,
Ĵ> σj .
4. Zakończenie procedury odbywa się po tym, jak replika doprowadzi swój
stan do zgodnego z innymi replikami. W tym celu wysłany jest przez
replikę komunikat state-update, co zostało opisane w punkcie dotyczącym
inicjacji grupy replik i zapraszania repliki do grupy.
Odłączenie, uszkodzenie klienta. Koniecznym wydaje się rozpatrzenie przypadku,
gdy klient zostałby uszkodzony, lub odłączył się od systemu. Nie mamy
gwarancji, że po ponownym uruchomieniu, będzie on pamiętał ostatnią sekwencję
wysłanego zlecenia. Możliwe są trzy podejścia do tego problemu:
• Pierwsze zlecenie wysłane przez klienta po uszkodzeniu powinno być specjalnym
komunikatem typu, client-anounce, który zapozna repliki z klientem
i zawiadomi, że nastąpiło jego ponowne uruchomienie.
• Identyfikator klienta c zmienia się po awarii.

4.4 Protokół zachłanny 77
Zdarzenie Przyczyna Reakcja
A1 Usługa może działać niedeterministycznie,
gdy takie zachowanie występuje
dla grupy z dużą liczbą replik.
A2 Wystąpiła awaria w warstwie komunikacyjnej
lub komunikaty zostały
wstrzymane.
A3 W grupie replik może znajdować
się część węzłów niepoprawnie
działających, których działanie
wynika z błędnej implementacji.
B1 Wystąpiło masowe przyłączanie i
odłączanie węzłów.
B2 Wystąpiła awaria w warstwie komunikacyjnej
lub komunikaty zostały
wstrzymane.
B3 Część z węzłów nie ma połączeń z
resztą grupy.
C1
C2
Stan replik nie jest zsynchronizowany.
Taka sytuacja może być następstwem
A1, lub tym, że protokół
zawiódł.
Uszkodzenia w komunikacji lub za
mała liczba członków grupy.
Rezygnacja z wykonania usługi lub
losowy wybór spośród replik nowego
globalnego stanu.
Ponowienie wysłania ostatniego
komunikatu.
Brak propozycji.
Starać się wynegocjować, jak największą
możliwą grupę.
Ponowienie wysłania ostatniego
komunikatu. Wstrzymanie negocjacji.
Należy ustalić węzły, które mają
najlepszy obraz grupy i próbować
przez nie nawiązać komunikację.
Wstrzymanie transferu stanu i ponowienie
próby po jakimś czasie.
Ponowienie próby transferu po jakimś
czasie lub zaniechanie.
C3 Prawdopodobnie wystąpił A3. Ponowienie próby transferu po jakimś
czasie lub zaniechanie.
Tablica 4.1: Zestawienie incydentów, do których może dojść podczas wykonania
protokołu.
• Nie przejmować się i pracować dalej, jakby nic się nie stało.
Pierwsze i drugie podejście wyklucza zaistnienie problemów z nieprawidłowym
uporządkowaniem zleceń, ale wymaga dodatkowego nakładu pracy. Ostatnie
podejście, chociaż trochę kontrowersyjne, może okazać się wystarczające w
przypadku poprawnie działających aplikacji klienckich. Nie należy obawiać się
klientów, którzy chcieliby zdestabilizować pracę grupy, gdyż jakiekolwiek nieciągłości
w numeracji sekwencji powinny prowadzić do zatrzymania wykonywania
zleceń dla danego klienta, a to, że np. niektóre zlecenia będą posiadały ten sam
numer sekwencji spowoduje tylko, że klient może otrzymać odpowiedzi, które
niekoniecznie będą odzwierciedlały spodziewane działanie usługi. Taka sytuacja
może doprowadzić do powstania błędów przetwarzania, zatem dużo zależy od
poprawnej implementacji.

78 Rozdział 4. Tolerowanie bizantyjskich uszkodzeń
Incydenty. Incydentem nazywamy sytuację, gdy podczas wykonywania protokołu
warunek na liczbę takich samych odpowiedzi od różnych nadawców nie jest
spełniony.
Tak, jak w prawdziwym świecie reakcja na incydent powinna być przemyślana.
Najpierw należy przeanalizować dostępne informacje, następnie wyciągnąć
z nich wnioski i podjąć odpowiednią decyzję. Działanie trzeba podjąć
natychmiast, gdyż często jedynie szybka reakcja potrafi przywrócić właściwy
stan. Incydenty w opisanym protokole mogą pojawiać się w następujących przypadkach:
A. Uzgadnianie stanu po wykonaniu zlecenia.
B. Uzgadnianie składu grupy replik.
C. Transfer stanu między replikami.
Dodatkowo każdy incydent może mieć następujący charakter:
1. Przypadkowy. Nadesłane odpowiedzi mają losowe wartości.
2. Odmowy. Nadesłanych odpowiedzi jest za mało, by zagwarantować
poprawne działanie.
3. „Koordynowanego buntu”. Nadesłane odpowiedzi dają się podzielić na
kilka grup. Niestety żadna nie tworzy wymaganej większości.
Iloczyn kartezjański charakteru incydentu i przypadku występowania prowadzi
do pełnej listy incydentów (patrz tablica 4.1) oraz możliwych reakcji.
4.5 Zatwierdzanie stanu
Opisywana technika transferu stanu wymaga istnienia mechanizmu, który zatwierdzałby
stan usługi, jako stabilny. De facto można w tym miejscu posłużyć
się techniką zatwierdzania stanu (ang. checkpointing) opisaną w poprzednim
rozdziale, użytą w algorytmie BFT.
Pozostaje do rozpatrzenia, czy rzeczywiście zatwierdzanie stanu musi odbywać
się w sposób bezpośrednio koordynowany oraz czy wymaga zebrania „dowodu
stabilności”. Poprzez bezpośrednią koordynację należy rozumieć technikę,
która wymaga komunikacji grupowej oraz doprowadzi do wspólnego zatwierdzenia
stanu.
Na rysunku 4.7 pokazano, że dowolny moment zatwierdzenia stanu przez
replikę może prowadzić do jej awarii. Dlaczego? Przecież można transferować
stan od repliki o numerze trzecim, oraz wszystkie zlecenia, tak, że replika

4.5 Zatwierdzanie stanu 79
0
1
2
3
s 3
s 0
s 1
s 2
{s 0 , s 1 ,s 2 ,s 3 }
Rysunek 4.7: Przebieg z lokalnym zapamiętywaniem stanu przez repliki. Po
ponownym podłączeniu czwarta replika nie jest w stanie odzyskać sprawności.
czwarta będzie odświeżona? Niestety nie można tak postąpić z powodu braku
zaufania, do którejkolwiek z replik. Oczywiście replika, która uległa awarii
ufa samej sobie, dlatego stan s 3 , którym replika dysponuje jest akceptowalny
przez nią samą, jednakże nawet po odczytaniu stanu s 3 nadal będą niedostępne
zlecenia, które przeprowadzą s 3 do aktualnie obowiązującego stanu. Brakujące
zlecenia mogłyby być pobrane od repliki o numerze zero, jednak sytuacja przedstawiona
na rys. 4.7 jest tylko specyficznym przypadkiem. Mogłoby się zdarzyć,
że ostatni zatwierdzony stan przez replikę odbył się w czasie, gdy replika trzecia
uległa awarii, wtedy zleceń nie udałoby się odzyskać.
W protokole BFT pokazano, że zatwierdzanie stanu musi odbywać się w
sposób koordynowany. Częstość zatwierdzania powinna być dopasowana do
obciążenia. Zatwierdzenie stanu powinno odbywać się tak często, jak jest to
możliwe, jednak, nie na tyle często, by w znacznym stopniu obciążać usługę.
Z drugiej strony zatwierdzenie stanu nie może być za rzadkie, gdyż może to
doprowadzić do załamania usługi w przypadku awarii. Generalnie problem częstości
wykonywania migawek należałoby rozwiązać budując odpowiednie prawo
sterowania, co mogłoby stanowić osobne opracowanie i w tej pracy zostało tylko
zasygnalizowane.
Sterowanie czasem zapisu migawki. Przez pojęcie stanu usługi będziemy rozumieli
stabilną migawkę 13 obiektu oraz wszystkie zlecenia, które jeszcze nie
zostały wykonane. Nie uwzględniamy komunikatów, które znajdują się w kanałach
komunikacyjnych i nie zostały potwierdzone przez większość replik.
Możliwe są dwa podejścia wynikające z założenia, jak uwzględniamy czas
potrzebny do wykonania zapisu stanu:
1. Czas odzyskania stanu usługi jest mały w porównaniu do czasu wykonania
zleceń - migawki warto wykonywać, jak najczęściej.
13 Czyli obiekt nie będący podczas tranzycji stanu wewnętrznego (wykonania).

80 Rozdział 4. Tolerowanie bizantyjskich uszkodzeń
35
12
11
30
10
25
20
9
8
7
6
15
0 100 200 300 400 500 600 700 800 900 1000 1100
5
0 100 200 300 400 500 600 700 800 900 1000 1100
Rysunek 4.8: Sterowanie częstością zapisu stanu (prawa strona) dla zmieniającego
się czasu wykonania usługi (lewa strona) (L max = 100, t=20, δ =0.5).
2. Czas wykonania zleceń jest mały w porównaniu do czasu odzyskania usługi
stanu - migawki należy wykonywać w momencie zapełnienia dziennika,
najrzadziej jak to jest możliwe.
Przeanalizuję sytuację drugą, gdyż dla pierwszego przypadku opłaca się archiwizować
dane dowolnie często. T będzie oznaczało ostatni okres wykonania
migawki. Niech t T oznacza średni czas wykonania rundy od ostatniej migawki,
natomiast l T średnią długość dziennika, który powstaje podczas wykonania rund
od ostatniej migawki. Odpowiednio definiujemy wartości średnie za okres równy
2T - t 2T , l 2T . Nowy wyznaczony okres między zapisami migawki oznaczymy
T ,natomiastT max = Lmax− l T
l T
, maksymalny okres wynikający z rozmiaru dziennika.
Wyznaczenie okresu kolejnej migawki T ′ będzie przebiegało z wykorzystaniem
prostej formuły:
T ′ = δ
(
tT
t 2T
l T
l 2T
) −1
T max
Początkowa wartości T ′ , dla której rozpoczyna się działanie, powinna być
taka, by nie przekroczyć dozwolonej długości dziennika. Parametr δ ∈〈0, 1〉
jest odpowiedzialny za dodatkową regulację wartości T i powinien być wyprowadzony
w zależności od t max ,t min ,l max ,l min oraz t T ,l T . Dodatkowo należy
wprowadzić „bezpiecznik”, który będzie pilnował, żeby rozmiar dziennika nie
został przekroczony:
T ′ =min{T ′ ,T max }
Formuła, która wyznacza T ′ jest bardzo prostym prawem sterowania. Oczywiście
taki sposób zarządzania dziennikiem wyda się trywialny dla kogoś, kto
zna dobrze zagadnienia sterowania, jednak z praktycznego punktu widzenia to
podejście jest wystarczające, jeżeli tylko czasy wykonania rundy oraz długość
dziennika nie zmieniają się zbyt gwałtownie.
Na rysunkach 4.8 oraz 4.9 pokazano przykład sterowania dla zmieniającego
się czasu wykonania rundy. Sterowanie wskazuje co ile kroków należy wykonać
zapis stanu usługi. Rysunek 4.9 zawiera wyznaczone sterowanie dla losowo

4.5 Zatwierdzanie stanu 81
35
13
12
11
30
10
9
25
8
7
20
6
15
100 200 300 400 500 600 700 800 900 1000 1100
5
4
0 100 200 300 400 500 600 700 800 900 1000 1100
Rysunek 4.9: Sterowanie częstością zapisu stanu (prawa strona) dla zmieniającego
się zakłóconego czasu wykonania usługi (lewa strona) (L max = 100, t =
20, δ=0.5).
zmieniającego się czasu wykonania usługi.
Protokół zatwierdzania stanu. Przedstawię teraz protokół synchronizacji i zatwierdzania
stanu, który mógłby używać dowolnej metody wyznaczania kolejnej
chwili migawki.
1. Replika i po wykonaniu rundy wyznacza za ile wykonań nastąpi synchronizacja
T ′ i rozgłasza komunikat < schedule-request, i, T ′ > σi i czeka
na 2f +1takich samych odpowiedzi od innych replik z uwzględnieniem
siebie samej.
2. Po odebraniu propozycji replika rozgłasza wartość zatwierdzoną < scheduleresponse,
i, ˆT >σi która jest wartością średnią ze wszystkich wartości odpowiednio
blisko wartości proponowanej przez nią samą ˆT ≤ T j ± 10%.
3. Replika co każdą rundę zapisuje stan (nie potwierdzony przez resztę replik),
o ile ta operacja nie jest za bardzo pracochłonna .
4. Po wykonaniu ˆT rund replika rozgłasza < checkpoint, ˆT , H(s), i>σi i
czeka na 2f +1odpowiedzi uwzględniając ją samą.
5. Zgromadzenie f +1podpisów dla s powoduje, że replika rozgłasza komunikat
< checkpoint-commit, ˆT , H(s), i>σi oraz zatwierdza stan s
podobnie jak to miało miejsce w przypadku protokołu BFT.
6. Replika ponownie wyznacza kolejny punkt synchronizacji T i rozgłasza
komunikat schedule-request.
Łatwo można zauważyć pewne usprawnienie, które polega na tym, że uzgadnianie
kolejnego momentu zatwierdzenia stanu może odbyć się podczas bieżącej
operacji zatwierdzania stanu, co znacznie zmniejsza nakłady na komunikację.

82 Rozdział 4. Tolerowanie bizantyjskich uszkodzeń
W tym paragrafie przedstawiłem protokół zatwierdzania stanu pokazując
wcześniej, że brak uzgodnienia momentu zapisu mógłby doprowadzić do niepożądanego
działania usługi. W uzupełnieniu do protokołu BFT został pokazany
prosty sposób sterowania częstością zapisu, który mógłby okazać się zawodny
przy większych wymaganiach, jednak stanowi rozwiązanie, które może zostać
użyte po małych modyfikacjach w praktycznej realizacji.
4.6 Protokół optymistyczny
Twierdzenie o nie istnieniu konsensusu w całkowicie asynchronicznym systemie
w obecności choć jednego nieuczciwie działającego procesu Fischera [FLP85]
mówi o tym, że próba uzgadniania bez synchronizacji może nie przynieść rezultatu.
Jednak nadal istnieje szansa, że uzgadnianie się powiedzie. Protokoły,
które dopuszczają możliwość zaistnienia błędnego przebiegu przyjęło się nazywać
protokołami optymistycznymi. W przypadku, gdy protokół optymistyczny
zawiedzie wykonanie zostaje przełączone w tryb użycia protokołu zachłannego.
Opisywane w poprzednim rozdziale protokoły BFT i SC-ABC posiadają swoje
wersje optymistyczne. Protokół BF2 można również zmodyfikować w taki sposób,
że zostanie wyeliminowana duża część synchronizacji między replikami, a
powrót do protokołu właściwego nastąpi podczas wykrycia błędów.
• Wykonanie protokołu BF2 w punkcie trzecim zakłada uzgodnienie przez
repliki zbudowanego wektora R g . W protokole optymistycznym zamiast
uzgadniać R g używając komunikatu request-ready natychmiast przechodzimy
do fazy wykonania zleceń.
• Faza wykonania zlecenia może również zostać skrócona. W tym przypadku
replika zapamiętuje stan obiektu sprzed wykonania zlecenia i wykonuje
je natychmiast, następnie rozgłasza komunikat pre-commit. Gdy
protokół zawiedzie, replika wycofuje wykonanie zlecenia.
• Podążając za tokiem rozumowania z poprzedniego punktu, replika może
wysłać odpowiedź do klienta od razu po wykonaniu zlecenia, jeżeli nie
modyfikuje ono stanu usługi. Klient w przypadku odebrania za małej
liczby takich samych odpowiedzi ponownie wyśle zlecenie ustawiając dodatkową
flagę retrospect. Replika po odebraniu takiego zlecenia wie, że
uprzednio wykonanie nie powiodło się i należy zrealizować całą operację
z uwzględnieniem wszystkich kroków.
Przełączenie w tryb wykonania protokołu zachłannego powinno następować
zaraz po wykryciu niepoprawnego działania. Powrót do optymistycznego proto-

4.7 Podsumowanie 83
kołu może nastąpić wraz z rozpoczęciem wykonania nowej rudny, jednak dopiero
po uzgodnieniu wektora R g .
4.7 Podsumowanie
Protokół BF2, zaproponowany w tym rozdziale, jest przeznaczony dla systemów
rozproszonych, w których istnieje konieczność tolerowania uszkodzeń bizantyjskich,
tzn. takich w których poszczególne elementy mogą zachowywać się w
sposób arbitralny, a dynamika zmiany struktury systemu jest bardzo duża. BF2
jest podobny w wielu aspektach do protokołu BFT opisanego w poprzednim
rozdziale 14 , jednak różni się znacząco w sposobie synchronizacji i uzgadniania
zleceń do wykonania przez repliki.
BFT przeznaczony jest raczej dla systemów, które charakteryzują się statyczną
strukturą. Podstawowym mechanizmem stosowanym do ustalenia kolejności
wykonania w BFT są widoki. W każdym widoku jeden z węzłów
uczestniczących jest koordynatorem i do niego muszą być kierowane wszystkie
zlecenia. Mechanizm widoków w BF2 został zastąpiony przez technikę wykonania
zleceń w rundach, co jest usprawiedliwione przy dużej dynamice grupy
replik. Wyznaczanie koordynatora użyte w BFT zakłada, że repliki są ponumerowane
w ten sposób, że możliwe jest jednoznaczne ustalenie kolejnej repliki
głównej, natomiast w BF2 nie jest to wymagane.
W tym rozdziale przedstawiono techniki konstrukcji grupy replik oraz protokoły
realizujące przyłączanie i odłączanie węzłów, czego nie specyfikuje ani
BFT ani SC-ABC. Projekt protokołu został poszerzony o opis problemu zatwierdzania
stanu, gdzie sformułowano problem sterowania częstością zatwierdzania
migawki i podano sprawne, choć może nie optymalne rozwiązanie.
Podobnie jak w BFT oraz SC-ABC, w BF2 można zastosować wersję optymistyczną
protokołu, co w praktycznej realizacji powinno zwiększyć wydajność
systemu, wtedy gdy środowisko pracy nie jest ekstremalnie nieprzychylne. Kolejny
rozdział opisuje projekt systemu Pastor, który implementuje algorytm BF2
w jego podstawowej postaci.
14 Dlatego przyjęto oznaczenie BF2.

Rozdział 5
Projekt systemu Pastor
Obiekty w systemach peer-to-peer podlegają replikacji z kilku powodów. Najważniejszy
z nich związany jest ze swobodą odłączania i przyłączania się węzłów
z i do systemu. Takie zachowanie elementów nie gwarantuje, że wprowadzone
dane będą zawsze dostępne. Replikacja sprawia, że istnieją większe szanse, iż
wprowadzone obiekty będą stale osiągalne. Drugi powód stosowania replikacji
wiąże się ze zwiększeniem dostępności obiektu. Replikacja w tym przypadku
pozwala, by operacje odczytu obiektów były obsługiwane przez większą liczbę
węzłów równolegle, co gwarantuje większą dostępność żądanych obiektów.
W tym rozdziale został przedstawiony projekt i testowa wersja systemu Pastor,
który implementuje protokół BF2, oparty o sieć Pastry. W pierwszej części
dokumentu zostały opisane dodatkowe techniki i metody, takie jak zarządzanie
dostępem i postarzanie obiektów, konieczne do zastosowania w oprogramowaniu.
Dalsze fragmenty poświęcone są opisowi komponentów i konceptualnej
struktury systemu. Ostatnie sekcje zawierają testy implementacji i ich analizę.
5.1 Projekt systemu
Pastor jest rozszerzeniem Past (DHT), które realizuje replikację usługi (umożliwia
zdalne wywołanie obiektów) opartym na Pastry, . Dla przypomnienia każdy
węzeł w Pastry posiada unikalny identyfikator o długości 160 bit. Ponadto obiekt
umieszczony w sieci Pastry posiada identyfikator, który wyznaczany jest jako
skrót z zawartości przez bezkolizyjną jednokierunkową funkcją skrótu SHA-1
lub w inny sposób zależny od oprogramowania. Pastry rzutuje identyfikatory
obiektów na identyfikatory węzłów tak, że węzeł którego identyfikator jest najbliżej
identyfikatora obiektu używając miary euklidesowej, staje się za ten obiekt
odpowiedzialny (patrz rozdział drugi). W razie konieczności obiekt jest replikowany
w innych węzłach.

86 Rozdział 5. Projekt systemu Pastor
5.1.1 Język implementacji - Java
Sieć Pastry została zaimplementowana w języku Java, dlatego testowa realizacja
Pastora jest realizowana przy użyciu tego języka. Dokumentacja API systemu
Pastor w postaci standardowej dokumentacji Javadoc oraz źródła oprogramowania
zostały umieszczone pod adresami (http://www.ia.pw.edu.pl/
˜tkruk/students/lwalkiew/)oraz (http://www.ia.pw.edu.pl/
˜lwalkiew/p2p/).
Jak każdy język programowania Java ma swoje wady i zalety. Głównymi zaletami
Javy jest niezależność od platformy sprzętowej, dostępność zaawansowanych
techniki programistycznych, takich jak serializacja obiektów, czy refleksja,
w końcu duża liczba gotowych bibliotek zawartych w standardowej dystrybucji
narzędzi programistycznych Java JDK (ang. Java Development Kit.). Podstawową
wadą Javy jest słaba wydajność. Wszystkie wyżej wymienione zalety
stają się niemożliwe do wykorzystania przy projektowaniu skomplikowanego
oprogramowania gdyż okazuje się, że większość bibliotek wymaga macierzystej
implementacji zależnej od sprzętu JNI (ang. Java Native Interface.), by osiągnąć
zadowalającą wydajność. Pomimo niedogodności Java jest świetną platformą do
szybkiej implementacji, gdy głównym celem jest zbadanie właściwości i cech
zaprojektowanej architektury oprogramowania.
Wyraźnym problemem dostrzeżonym w implementacji Pastry, rzutującym na
wydajność jest oparcie systemu na technice serializacji. Serializacja w dużym
skrócie polega na takiej transformacji stanu obiektu, iż możliwym staje się przekazanie
go do innej maszyny wirtualnej lub zapis na dysk, a następnie wykonanie
transformacji odwrotnej i dalsze użycie. Jest to bardzo wygodny mechanizm,
gdyż w ten sposób możemy łatwo przesyłać dane między instancjami maszyny
wirtualnej uruchomionymi na różnych maszynach za pośrednictwem sieci nietroszcząc
się o reprezentacje, czy obsługę błędów, robi to za nas środowisko.
W Pastry zastosowano serializację do przesyłania między węzłami dosłownie
wszystkiego, co niestety niekorzystnie wpływa na wydajność systemu. Każdy
komunikat przed wysłaniem jest serializowany. Odebranie wiadomości w węźle
pośrednim również wymaga deserializacji, dlatego użyta implementacja Pastry
nie jest optymalnie wydajna.
5.1.2 Bezpieczeństwo wykonania
Wykonanie zlecenia przez węzeł po odebraniu komunikatu invoke stanowi wyraźne
zagrożenie zarówno dla samej aplikacji peer-to-peer, jak również sprzętu.
Bezpieczne wykonanie obcego kodu stanowi odrębne zagadnienie i nie będzie
w tej pracy szeroko poruszane.
Nie trudno sobie wyobrazić, jakie mogą być następstwa braku kontroli nad

5.1 Projekt systemu 87
wykonaniem kodu nieznanego pochodzenia. Załóżmy, że obiekt, jaki został
wprowadzony do systemu, posiada metodę która buduje potajemnie kod wykonywalny
będący wirusem, zapisuje go na dysku ofiary, a następnie uruchamia.
Inny scenariusz możliwy do zaistnienia, zakłada, że obiekt rozsyła swoje kopie
do wszystkich węzłów, które zna ofiara działając jak robak używający aplikacji
peer-to-peer, jako medium do rozprzestrzeniania.
Zasygnalizuję problemy, jakie należy rozwiązać, by zagwarantować pewien
poziom bezpieczeństwa i kontroli nad wykonywanym kodem nieznanego pochodzenia:
• Kod zewnętrznego pochodzenia powinien być podpisany, a podpis możliwy
do weryfikacji.
• Kod zewnętrznego pochodzenia powinien zostać zweryfikowany zanim
umożliwi się jego wykonanie.
• Każde wywołanie metody obcego obiektu powinno odbywać się pod kontrolą,
najlepiej w osobnym wątku, z pełnym nadzorem nad zamawianymi
zasobami systemu operacyjnego, jak i dostępu do obiektów wewnątrz aplikacji.
Badania prowadzone nad bezpieczeństwem wykonania doprowadziły do opracowania
dwóch modeli wykonania obcego kodu: piaskownicy (ang. sandbox)
i placu zabaw (ang. playgroud). Piaskownica polega na tym, że środowisko
wykonania określa sztywno jakie operacje mogą być wykonane przez obcy kod
i każde naruszenie tych ograniczeń poskutkuje zatrzymaniem wykonania i zgłoszeniem
wyjątku. Plac zabaw dla odmiany jest trochę mniej restrykcyjnym rozwiązaniem,
które zezwala na wykonanie niektórych uprzywilejowanych operacji,
gdy tylko polityka bezpieczeństwa narzucana przez aplikację akceptuje takie zachowanie,
np. możemy by obcy obiekt nawiązywał połączenia ze źródłem, z
którego został pobrany. Przed rozpoczęciem wykonania obcego kodu aplikacja
powinna znać wszystkie zasoby, z których ten kod będzie korzystał. Różnica
między piaskownicą i placem zabaw jest taka, że w przypadku placu zabaw do
obcego kodu może zostać dołączona lista zasobów niezbędnych do jego wykonania
i aplikacja może zdecydować czy te zasoby mogą być udostępnione na
czas wykonania. Obecnie termin placu zabaw jest wypierany przez określenie
piaskownica, chociaż autorzy pisząc o piaskownicy najczęściej mają na myśli
placu zabaw.
Implementacja Pastry i Pastora została wykonana w języku Java, który pozwala
na rozwiązanie powyższych zagadnień bespieczeństawa, ale tyko częściowo.
Na chwilę pisanie tego dokumentu obowiązującym standardem było
J2SE 5.0, które nie implementuje mechanizmów kontroli kodu na poziomie

88 Rozdział 5. Projekt systemu Pastor
obiektu, dlatego też wszystkie zabezpieczenia musiałyby być zrealizowane na
poziomie wątku wykonania, co dodatkowo rzutuje na wydajność. Wymagania
zapewnienia bezpieczeństwa można rozwiązać używając dwóch podejść:
• Weryfikacja typu off-line, tzn. architektura aplikacji powinna wykorzystywać
mechanizm wtyczek (ang. plug-in), które dostarczane są z wiadomego
źródła, jako zewnętrzne klasy. Uruchamiane klasy powinny być podpisane,
a ich uprawnienia zależne od polityki bezpieczeństwa. Niestety to podejście
ogranicza możliwość przechowania, niektórych obiektów przez węzeł,
gdyż mogą one nie mieć wbudowanej odpowiedniej wtyczki. Wytłumaczenie
powyższej sytuacji wymaga posłużenia się przykładem: Węzeł u chce
umieścić w sieci obiekt klasy A o identyfikatorze A id . Wykonuje operację
insert, która przesyła obiekt poprzez sieć do celu, którego identyfikator
jest najbliższy względem A id . Przyjmijmy, że punktem docelowym będzie
węzeł v. Jeżeli v posiada wtyczkę zawierającą plik A.class, toużywając
deserializacji poprawnie odbierze obiekt A i umieści go w swojej pamięci
trwałej. W przeciwnym razie próba rozpakowania obiektu A nie powiedzie
się i zostanie zgłoszony wyjątek.
• Weryfikacja on-line zakłada, że definicje klas są pobierane w sposób dynamiczny
i uruchomienie obiektów odbywa się w przygotowanym i nadzorowanym
środowisku (np. piaskownicy). To podejście jest znacznie trudniejsze
do zaimplementowania, ale nie nakłada ograniczeń co do możliwości
przechowywania konkretnych obiektów przez określony węzeł. Wrócę do
poprzedniego przykładu. Węzeł u nadal chce przesłać obiekt A do węzła
u. W tym celu u opakowuje A oraz zawartość pliku A.class w jeden
obiekt Content, którego klasa znana jest obu węzłom. Ponadto obiekt Content
implementuje dwie metody put oraz get, które pozwalają „upakować”
przesyłane obiekty w standardowych tablicach bajtów. Gdy Content dotrze
do v ten rozpakuje najpierw plik A.class i wczyta go używając własnego
SecureClassLoader’a, który ustawi ograniczenia dla tego obiektu.
W początkowej implementacji systemu Pastor zostały użyte elementy weryfikacji
off-line oraz on-line. Obiekty w obecnej implementacji Pastora wysyłane
są w specjalnym kontenerze Content, ale bez dołączonej definicji klasy. Definicje
pobierane są z wtyczek, które muszą zostać umieszczone w katalogu plugin/
w pliku jar.
Więcej informacji na temat bezpieczeństwa w Java 2 czytelnik znajdzie w
książce Li Gonga [Gon99].

5.1 Projekt systemu 89
5.1.3 Postarzanie obiektów
Użyteczną techniką stosowaną przez DHT zaimplementowanym w systemie Kademlia
jest postarzanie obiektów [MM02]. Wcześniej ta technika była stosowana
na przykład w systemie plików rozproszonego systemu operacyjnego Amoeba
[Tan95], aczkolwiek użycie tej techniki w systemie Amoeba miało zupełnie inne
przesłanki, niż ma to miejsce w Kademlii. W Amoebie postarzanie wiązało się
z usuwaniem nieużywanych już plików, do których nie odnosi się żadna ścieżka
dojścia 1 , starsze pliki, niż pewna ustalona wartość były kasowane. Kademlia implementuje
podobny mechanizm. Użytkownik chcąc, by jego obiekt pozostał w
DHT Kademlii musi wywołać przynajmniej raz na dobę operację odświeżania,
co odpowiada operacji dotknięcia (ang. touch) stosowanej w systemie Amoeba.
Przesłanki, jakie kierowały projektantami Kademlii wiązały się z rozsądnym gospodarowaniem
przestrzenią dyskową, chociaż przyjęty czas przeterminowania
obiektu, czyli doba, wydaje się być trudny do interpretacji.
W systemie Pastor, postarzanie obiektów można usprawiedliwić nie tylko
optymalizacją zajętości przestrzeni dyskowej, ale też wydatkami komunikacyjnymi
na utrzymywanie stanu replik dla obiektów, które nie są więcej wywoływane.
FreePastry posiada rozszerzenie GCPast (ang. Garbage Collector Past),
które implementuje usuwanie obiektów dlatego Pastor opierał się na tym rozszerzeniu.
Implementacja FreePastry
Do realizacji oprogramowania użyto wersji FreePastry 1.4.1 (maj 2005), w skład
której wchodzą następujące komponenty:
• Pastry - substrat peer-to-peer.
• Past - implementacja DHT.
• Scribe - mechanizm komunikacji grupowej.
• Glacier - współdzielenie zawartości (podobne do protokołu BitTorrent).
• SplitStream - strumieniowe przesyłanie danych.
Jest to duża baza, która pozwala na skonstruowanie nawet bardzo wyszukanych
aplikacji rozproszonych. W tym rozdziale nie będę dokładnie opisywał
interfejsu programistycznego dostarczanego przez FreePastry, gdyż przedstawienie
funkcjonalności tego oprogramowania wykracza daleko poza ramy tej pracy
1 Serwer pików periodycznie odświeżał znaczniki czasu do plików, do których istniały dojścia
w systemie katalogowym.

90 Rozdział 5. Projekt systemu Pastor
i to zagadnienie mogłoby stanowić oddzielne opracowanie. Dokumentację w
postaci plików Javadoc do biblioteki FreePastry czytelnik znajdzie na załączonej
płycie CD. Jedynie w celach ilustracji został podany przykład wraz z komentarzem,
utworzenia węzła sieci Pastry (listing 5.1), oraz zarejestrowania zawartości
w Past (listing 5.2).
Listing 5.1: Tworzenie instancji węzła w Past.
1 // Nazwa instancji aplikacji
2 String instance = new String("PastTesT");
3
4 // Liczba replik dla obiektu Past
5 int replicas = 3;
6
7 // Port przyłączenia
8 int bindport = 6666;
9
10 // Adres przyłączenia
11 InetSocketAddress bootaddress =
12 new InetSocketAddress("127.0.0.1", bindport);
13
14 // Klasa budowy losowych identyfikatorów
15 PastryIdFactory nidFactory =
16 new RandomNodeIdFactory();
17
18 // Klasa budowy węzłów dla połączeń sieciowych
19 PastryNodeFactory factory =
20 new SocketPastryNodeFactory(nidFactory, bindport);
21
22 // Uchwyt do węzła przyłączenia
23 NodeHandle bootHandle =
24 ((SocketPastryNodeFactory)factory).getNodeHandle(bootaddress);
25
26 // Utworzenie nowego węzła
27 PastryNode node = factory.newNode((NodeHandle) bootHandle);
28
29 // Klasa tworzenia identyfikatorów węzłów
30 NodeIdFactory Idf = new PastryIdFactory();
31
32 // Utworzenie zarządcy obiektami przestrzeni ok. 1MB
33 StorageManagerImpl storage =
34 new StorageManagerImpl(Idf,
35 new PersistentStorage(Idf, "root", ".", 1000000),
36 new LRUCache(new MemoryStorage(Idf), 100000));
37
38 // Utworzenie obiektu aplikacji Past
39 Past past = new PastImpl(node, storage, replicas, instance);
Utworzenie węzła inicjuje wywołanie metody getNodeHandle(bootaddress)
klasy SocketNodeFactory, co ma na celu pobranie uchwytu do węzła przyłączającego.
Gdy węzeł przyłączający nie odpowie uchwyt bootHandle będzie
miał wartość null, wtedy zostanie utworzona nowa sieci Pastry poprzez wywoałnie
metody newNode(bootHandle). W innym przypadku węzeł zostanie
przyłączony poprzez węzeł o adresie bootaddress do istniejącej sieci. Kolejnym
krokiem jest utworzenie zarządcy przestrzeni trwałej StorageManagerImpl o
wielkości około 1MB. W końcu do życia powołuje się instancję węzła aplikacji
Past.
Listing 5.2: Wprowadzanie obiektu do Past.
1 // Tworzymy obiekt o, który zostanie wprowadzony do sieci
2 String str = new String("Nowy obiekt");
3

5.1 Projekt systemu 91
4 MyPastContent myObject =
5 new MyPastContent(Idf.buildId(str.toString()), str);
6
7 // Wprowadzamy obiekt do sieci
8 past.insert(myObject, new Continuation() {
9 public void receiveResult(Object o) {
10 System.out.println("Got result " + o);
11 }
12 public void receiveException(Exception e) {
13 System.out.println("Oops! An error occurred: " + e);
14 }
15 });
16
17 Thread.sleep(1000);
18
19 // Wyszukujemy obiekt
20 past.lookup(myObject.getId(), new Continuation() {
21 public void receiveResult(Object o) {
22 System.out.println("Got result " + o);
23
24 }
25 public void receiveException(Exception e) {
26 System.out.println("Oops! An error occurred: " + e);
27 }
28 });
Wprowadzenie zawartości do Past jest trochę trudniejsze, gdyż użycie operacji
insert skutkuje utworzeniem dodatkowego wątku przetważania poprzez użycie
anonimowej klasy wewnętrznej Continuation, który realizuje zlecenie działając
„w tle”, czyli asynchronicznie z punktu widzenia użytkownika. W pierwszej kolejności
utworzony zostaje obiekt klasy MyPastContent, którego identyfikator
jest zbudowany przez obiekt fabryki identyfikatorów Idf typu NodeIdFactory na
podstawie ciągu znaków str. Następnie wywoływana zainicjowanej instancji węzła
past. Wywoływanie podstawowych operacji nie jest wielce skomplikowane,
gdyż oprogramowanie FreePastry ma stosunkowo intuicyjny i prosty interfejs
programistyczny.
Komponenty
Pastor - aplikacja działająca w oparciu o sieć Pastry dostarczająca metody
invoke i dziedzicząca inne operacje po GCPast.
PastorContent - specjalny rodzaj obiektu, który dziedziczy po PastContent,
ale umożliwia dodatkowo wykonywanie metod.
PastorContentHandle - uchwyt do obiektu PastorContent, np. pozwala
określić węzeł, z którego pochodzi.
Messanger - interfejs umożliwiający rozgłaszanie komunikatów z zachowaniem
warunku przyczynowości.
Replicator - aplikacja działająca w oparciu o sieć Pastry, podobnie jak
Pastor. Jej zadaniem jest wykonywanie i obsługa zleceń zgłaszanych przez
aplikację Pastor.

92 Rozdział 5. Projekt systemu Pastor
Wywołanie metody obiektu w Pastorze odbywa się podobnie, jak w Past.
Klient określa id obiektu, który będzie wywołany, buduje obiekt zlecenia, które
przyjmuje jako parametr nazwę metody do wywołania oraz argumenty wyołania.
Klient podczas wywołania operacji invoke tworzy obiekt kontynuacji (Continuation)
i czeka na odpowiedź.
Listing 5.3: Utworzenie węzła Pastora oraz wywołanie obiektu.
1 // Tworzymy nową fabrykę identyfikatorów
2 PastryIdFactory f = new PastryIdFactory();
3
4 // Inicjujemy zarządcę przestrzenią dyskową
5 StorageManagerImpl storage = new StorageManagerImpl(f,
6 new PersistentStorage(f, "root", ".", 1000000),
7 new LRUCache(new MemoryStorage(f), 100000));
8
9 // Tworzymy węzeł aplikacji Pastor używając węzła - node sieci Pastry
10 Pastor pastor = new PastorImpl(node, storage, REPLICATION_FACTOR,
11 INSTANCE, new PastPolicy.DefaultPastPolicy(),
12 GCPast.INFINITY_EXPIRATION);;
13
14 // Tworzymy obiekt Obj i wywołujemy lokalnie metodę setString
15 Obj o = new Obj();
16 o.setString("Alice has a kitty.");
17
18 // Tworzymy obiekt aplikacji Pastor
19 PastorContent myObject = new PastorContent(f.buildId("Nowy obiekt"), o);
20
21 // Obiekt zostaje umieszczony w sieci
22 pastor.insert(myObject, new Continuation() {
23 public void receiveResult(Object o) {
24 System.out.println("Got result " + o.toString());
25 }
26 public void receiveException(Exception e) {
27 System.out.println("Oops! An error occurred: " + e);
28 }
29 });
30
31 Thread.sleep(2000);
32
33 // Tworzymy nowe parametry wywołania
34 Object[] params = new Object[] { new String("Kitty has Alice.") };
35
36 // Tworzymy obiekt zlecenia wywołania metody setString
37 Command cmd = new CommandContent(1, "setString", params);
38
39 // Wywołujemy metodę obiektu uprzednio umieszczonego w sieci.
40 // W wyniku powinniśmy otrzymać napis "Alice has a kitty.", gdyż
41 // metoda setString zwraca uprzednio zapamiętany ciąg znaków.
42 pastor.invoke(f.buildId("Nowy obiekt"), cmd, new Continuation() {
43 public void receiveResult(Object o) {
44 System.out.println("Got result " + o.toString());
45 }
46 public void receiveException(Exception e) {
47 System.out.println("Oops! An error occurred: " + e);
48 }
49 });
Przykład utworzenia węzła Pastor’a oraz wywołanie obiektu umieszczono na
listigu 5.3.
5.1.4 Zarządzanie dostępem
Zarządzanie uprawnieniami klientów można zrealizować używając kryptografii
z kluczem publicznym. Nie jest to może idealne rozwiązanie ze względu na

5.1 Projekt systemu 93
wydajność, jednak przemawia za tym wiele aspektów.
Użytkownik wprowadzając obiekt o do systemu generuje parę kluczy: K p ,K s .
K p jest kluczem publicznym, natomiast K s jest kluczem prywatnym. Klucz publiczny
zostaje dołączony do obiektu i wprowadzony do systemu, tak że każda
replika obiektu będzie również posiadała jego klucz publiczny. Klucz prywatny
posłuży do wygenerowania uprawnień (ang. credentials). Uprawnienia mogą
być przyznawane na rzecz wszystkich (publiczne), grupy oraz indywidualnego
użytkownika, podobnie jak ma to miejsce w systemie Linux.
Uprawnienia publiczne dołączane są do wprowadzanego obiektu. Poniżej
umieszczono opis tworzenia i weryfikacji uprawnień:
1. s u = K s (H(o), u,c,Kp u ) - użytkownik wystawia uprawnienie c na rzecz
obiektu o dla użytkownika u, Kp
u jest kluczem publicznym użytkownika
u. Należy zauważyć, że uprawnienie c może mieć dowolną postać, może
być nadaniem praw do wykonania tylko jednej konkretnej operacji, lub
całego ich zestawu. Warunek jest tylko taki, aby postać c była zrozumiała
dla usługi.
2. insert(H(o), o,K p ) - wprowadzenie obiektu o do systemu musi odbywać
się wraz z wprowadzeniem klucza weryfikacyjnego K p .
3. Protokół używa metody typu challenge-response do zapewnienia jednorazowego
użycia uprawnień. Niech r oznacza losowo wygenerowaną liczbę,
którą replika wysyła do użytkownika, gdy ten chce wykonać operację na
usłudze. Użytkownik generuje bilet (ang. ticket) t = Ks u (r, s c ) iwysyła
operację zawierającą bilet do repliki (H(o), c, u, r, s c , t, Kp u ). Bilet
będzie honorowany przez replikę, tak długo jak będzie to ustalone (np.
przez określoną ilość operacji lub czasu).
4. W celu ustalenia uprawnień użytkownika, replika weryfikuje s c używając
K p , a następnie weryfikuje bilet t używając K u p .
W przypadku weryfikacji uprawnień dla grupy, proces przebiega prawie tak
samo z tym wyjątkiem, że u staje się identyfikatorem grupy g, a klucz użyty do
wyznaczenia w uprawnienia w punkcie 1. staje się Kp
g i przestaje należeć do
jednego uczestnika, tylko do wszystkich uczestników w grupie. Główna różnica
polega na obsłudze jednorazowych biletów. Bilet nadal musi być wystawiony na
rzecz konkretnego użytkownika, dlatego bilet wyznaczany jest przy użyciu Kp u .
Podany schemat weryfikacji dostępu działa tak długo, jak klucz prywatny
K s wstawiającego obiekt nie zostanie złamany lub przechwycony, oraz gdy któryś
z kluczy prywatnych uczestników nie zostanie złamany lub przechwycony.

94 Rozdział 5. Projekt systemu Pastor
Pierwszy przypadek całkowicie blokuje usługę, drugi sprawia, że atakujący będzie
miał taki dostęp do obiektu, jaki miał zagwarantowany użytkownik, którego
klucz prywatny udało mu się złamać lub przywłaszczyć.
W pierwszym przypadku wystawiający uprawnienia musi unieważnić klucz
weryfikacyjny, natomiast w drugiej sytuacji uprawnienie musi zostać wystawione
ponownie, z nowym kluczem publicznym użytkownika. Niestety w tym schemacie
nie ma możliwości łątwego cofnięcia uprzednio wystawionego uprawnienia.
Jedyna możliwość, to bezpośrednia interwencja wystawiającego, który oznajmia,
że konkretne uprawnienie zostało cofnięte (zostaje utworzona lista cofnięć).
5.2 Podsumowanie
Systemy peer-to-peer stają się coraz bardziej popularne ze względu na rosnącą
liczbę implementacji aplikacji opartych na ich architekturze. Liczba możliwych
zastosowań tej klasy systemów jest bardzo długa, chociaż niektóre zastosowania,
takie jak obliczenia rozproszone wymagają jeszcze wielu badań i analiz.
Istnieją pewne specyficzne zastosowania np. maskowanie usługi i trasowanie
cebulkowe, które byłyby bardzo trudne do realizacji przy użyciu klasycznych
aplikacji sieciowych.
Wśród stosowanych aplikacji typu peer-to-peer dominują nieustrukturalizowane
architektury które są łatwe w budowie, chociaż wykorzystują punkty centralne.
Łatwiejsze w analizie i konstrukcji są architektury ustrukturalizowane
oparte na algorytmie przedrostkowego trasowania komunikatów Plaxtona. Niestety
na chwilę pisania tej pracy brakowało aparatu teoretycznego przeznaczonego
do formalnej analizy tych systemów, a szczególnie ich dynamicznego zachowania.
Zagadnienie, które zostało przeanalizowane w kontekście systemów luźno powiązanych
dotyczy tolerancji na uszkodzenia, a dokładnie arbitralne zachowanie
elementów. Przedstawiono dwa algorytmy bezpiecznej replikacji usługi tolerującej
bizantyjskie uszkodzenia, BFT (B. Liskov i M. Castro, MIT) oraz SC-ABC
(K. Kursawe i V. Schoup, IBM). Zasadniczy problem obu podejść wynika bądź
to ze wskazania elementu centralnego, który nadzoruje wykonanie usługi, tak
jak ma to miejsce w BFT, lub trudności w zarządzaniu składem grupy, co z kolei
ma miejsce w SC-ABC. Próbą rozwiązania tych problemów jest zaproponowany
w rozdziale czwartym algorytm BF2.
W ostatnim rozdziale przedstawiono projekt systemu Pastor, rozszerzenia do
ustrukturalizowanego systemu peer-to-peer Pastry, a dokładniej do aplikacji Past
opartej na Pastry, czyli rozproszonej tablicy z kodowaniem mieszającym. Pastor
wprowadza do Past możliwość zdalnego wywoływania obiektów przechowywanych
w systemie i zapewnia odporność na bizantyjskie zachowanie węzłów, które

5.2 Podsumowanie 95
wchodzą w skład grupy replikującej obiekt.
Do opracowania pozostaje wnikliwa analiza algorytmu BF2 oraz teoretyczna
weryfikacja jego poprawności, np. w oparciu o teorię automatów lub sieci Petriego.
Praktyczna implementacja oprogramowania powinna być rozwijana, aż
do momentu wprowadzenia wszystkich zaproponowanych rozwiązań.
Systemy peer-to-peer będą coraz częściej używanym oprogramowaniem sieciowym.
Popularność, którą zdobyły zarówno wśród użytkowników, jak i środowiska
naukowego głównie w USA na chwilę obecną sugeruje, że aplikacje tego
typu będą nadal mocno rozwijane i badane. Niestety głównym zastosowaniem
systemów peer-to-peer najprawdopodobniej pozostanie wymiana plików między
użytkownikami globalnej sieci, jaką jest Internet 2 .
2 Amerykański sąd najwyższy w dniu 28 czerwca 2005 roku uznał, że serwisy wymiany plików
mogą być pozywane za naruszenie praw autorskich, o ile sugerują użytkownikom wymianę
materiału chronionego prawnie. (źródło: CNN.)

Dodatek A
Elementy teorii grafów
Teoria grafów jest jednym z narzędzi projektowania systemów peer-to-peer. Szczególne
znaczenie na początku projektowania ma wybór odpowiedniej architektury,
jaką powinien mieć system, by uzyskać jak najmniejsze odległości między węzłami
w przestrzeni identyfikatorów i jednocześnie utrzymywać, jak najmniejszą
liczbę połączeń przez poszczególne węzły. Ważnym aspektem jest spójność krawędziowa
i wierzchołkowa sieci, która stanowi, o tym jak bardzo system peer-topeer
będzie odporny na niespodziewane odłączanie poszczególnych węzłów lub
ich niepoprawne działanie. Pożądaną właściwością jest istnienie wielu dróg rozłącznych
krawędziowo i wierzchołkowo pomiędzy węzłami, gdyż w przypadku
wystąpienia problemów podczas wysyłania komunikatu, powinna istnieć inna
droga, którą można przesłać wiadomość. Niestety na chwilę obecną brakuje
sformalizowanej metodyki, która pozwalałaby na analizę dynamicznych właściwości
grafów sieci peer-to-peer.
Przedstawię kilka podstawowych faktów z teorii grafów, które znajdują bezpośrednie
zastosowanie przy projektowaniu systemów peer-to-peer. W pierwszej
kolejności zostanie podane kilka definicji, a następnie najczęściej używane architektury
grafowe występujące w systemach peer-to-peer.
Definicja. Grafem G nazywamy zbiór G(V,E), gdzie V nazwany jest zbiorem
wierzchołków, natomiast E zbiorem krawędzi. Mówi się, że krawędź e ∈ E
jest incydentna do wierzchołka v ∈ V , gdy e jest przylega do v. Krawędź e
musi być przyległa do jakiegoś wierzchołka obustronnie. Grafy reprezentuje się
najczęściej w postaci rysunków, takich jak rysunek A.1.
Definicja. Stopniem wierzchołka v nazywamy liczbę krawędzi incydentnych do
tego wierzchołka i oznaczamy d(v).
Definicja. Drogą z wierzchołka v 1 do v n w grafie nazywamy uporządkowany

98 Dodatek A. Elementy teorii grafów
zbiór krawędzi i wierzchołków {v 1 e 1 v 2 e 2 ...e n v n }, w którym pierwszym elementem
jest wierzchołek v 1 , natomiast końcowym v n . Elementy w zbiorze
nie mogą się powtarzać za wyjątkiem ostatniego i pierwszego elementu. Gdy
v 1 = v n , drogę nazywamy cyklem. Każda krawędź w drodze musi być incydentna
do następujących po sobie wierzchołków.
Definicja. Graf nazywamy spójnym, gdy pomiędzy dwoma dowolnymi wierzchołkami
w grafie istnieje droga.
A.1 Spójność krawędziowa i wierzchołkowa
Pod terminem spójności krawędziowej λ(G) ukrywa się minimalna liczba krawędzi
jaką należy usunąć z grafu, by graf przestał być spójny. Odpowiednio przez
spójność wierzchołkową κ(G) rozumiemy minimalną ilość wierzchołków jaką
należy usunąć z grafu, żeby graf przestał być spójny. Operacja usunięcia wierzchołka
pociąga za sobą usunięcie wszystkich krawędzi incydentnych do tego
wierzchołka. Łatwo zauważyć, że istnieje związek między spójnością wierzchołkową,
a krawędziową κ(G) ≤ λ(G). Jednocześnie spójność krawędziowa
nie może przekroczyć λ(G) ≤ ⌊ ⌋
2e
n .
Liczba dróg rozłącznych krawędziowo i wierzchołkowo związana jest ze spójnością
krawędziową grafu. Gdy rozpatrujemy liczbę dróg z wierzchołka u do v
to możemy łatwo znaleźć oszacowania górne na tą wartość. Oznaczając przez
d(u) stopień wierzchołka u oraz d(v) stopień wierzchołka v, oszacowanie górne
liczby dróg z wierzchołka u do v jest równe min{d(v),d(u)}
A.2 Różne typy grafów
Ustrukturalizowane i nieustrukturalizowane systemy peer-to-peer organizują samoczynnie
komunikację między węzłami sieci. Skalowalność obecnie stosowanych
systemów jest wynikiem doświadczeń oraz prób i błędów z rzeczywistymi,
testowymi implementacjami. Dopiero od niedawna zaczęto budować sieci peerto-peer
używając takich strukturach grafowych, które zapewniają lepszą wydajność.
Postanowiłem przedstawić w kilku punktach najczęściej spotykane lub
zalecane struktury grafowe w systemach peer-to-peer. Szczególnie obiecujące
wydają się być grafy de Bruijn’a [LKRG03]. Grafy de Bruijn’a zostały zastosowane
do konstrukcji sieci Koorde [KK03].

A.2 Różne typy grafów 99
Rysunek A.1: Grafy regularne o czterech wierzchołkach i stopniu równym dwa,
oraz sześciu wierzchołkach i stopniu równym cztery.
A.2.1
Grafy regularne i grafy losowe
Grafem regularnym nazywamy taki graf, w którym stopień każdego wierzchołka
w grafie ma taką samą wartość ∀ v∈V d(v) =const. Spójność krawędziowa grafu
r-regularnego jest równa λ(G) =r. Grafy tego typu posiadają ważną właściwość
ze względu na nieustrukturalizowane systemy peer-to-peer, gdyż świetnie działają
w nich protokoły plotkarskie wspomniane w pierwszym rozdziale. Plotkowanie
działa niezwykle dobrze w pewnej szczególnej podklasie grafów regularnych, a
dokładniej w kratownicach (ang. lattices).
Najbardziej znanymi grafami losowymi są grafy Erdős’a. Konstrukcja tych
grafów jest stosunkowo prosta. Dla grafu o n wierzchołkach dane jest prawdopodobieństwo
p istnienia krawędzi między dowolnymi dwoma wierzchołkami.
Dla każdej pary wierzchołków jest losowane, czy są one do siebie incydentne.
Średni stopień wierzchołków zależy oczywiście od prawdopodobieństwa p oraz
wielkości sieci i wynosi d = p(n − 1). Dla dużego n, rzędu kilku milionów,
wartość d będzie duża nawet dla p bliskiego jednej tysięcznej. W rzeczywistych
sieciach prawdopodobieństwo istnienia krawędzi między węzłami nie jest jednolite.
W sieciach up2p super węzły posiadają dużą liczbę połączeń, sięgającą
nawet do kilkudziesięciu tysięcy. Węzły uczestniczące utrzymują prawie o rząd
wielkości mniej połączeń niż super węzły.
Ciekawą hybryda powstaje z połączenia grafów Erdős’a i grafów regularnych.
Ustalamy, że p = 1 ,wtedyd =1oraz wybieramy pewną wartość
n−1
r. Ustalamy, że stopień każdego wierzchołka musi być przynajmniej r, czyli
d ′ = d · r. Oznacza to mniej więcej tyle, że rozpatrując kolejny wierzchołek
grafu, losujemy tak długo krawędzi do niego incydentne, aż stopień wierzchołka
nie wyniesie r. Każdego losowania istnienia krawędzi dokonujemy używając

100 Dodatek A. Elementy teorii grafów
Rysunek A.2: Losowe grafy Erdős’a o dziesięciu wierzchołkach i prawdopodobieństwu
istnienia krawędzi p =0.5, 0.3.
prawdopodobieństwa p równego 1
n−1 .
A.2.2
Grafy Butterfly
Sieć motyla (ang. butterfly)od wymiarach, jest grafem samopodobnym, którego
wierzchołki są oznaczone dwoma wartościami (w, i), w jest ciągiem binarnym
o długości d, ai jest liczbą całkowitą od 0 do d. Wierzchołek (w, i) połączony
jest z wierzchołkiem (w ′ ,i+1)wtedy, gdy w i w ′ jest zgodne przedrostkiem
za wyjątkiem, co najwyżej i +1 bitów. Sieć motyla ma (d +1)2 d wierzchołków
i d2 d+1 krawędzi. Na rysunku A.3 pokazano trzy sieci typu motyla, dla
wymiaru d = {1, 2, 3}. Dla wymiaru równego d = 1 wierzchołki oznakowane
są następująco: (0, 0), (0, 1), (1, 0), (1, 1). Zasadniczą zaletą sieci motyla
jest stosunkowo prosta nawigacja. Gdy komunikat wędruje w sieci to dopóki nie
osiągnie wierzchołka, z którym będzie zgodny prefiksem, to stosuje się przesyłanie
przez węzły o identyfikatorach najbliższych adresatowi. Algorytm trasowania
przedrostkowego Plaxtona stosuje się, gdy komunikat zacznie być zgodny co do
początkowej części adresu z adresem węzła pośredniczącego.
A.2.3
Grafy de Bruijn’a
Grafy de Bruijn’a są digrafami z oznaczonymi wierzchołkami. Grafy tego typu
posiadają dwa parametry: m - liczbę znaków w alfabecie M użytym do utworzenia
tworzenia etykiety oraz wymiar n. Etykieta każdego wierzchołka jest
długości n i składa się ze znaków w M. Na rysunku A.4 pokazano grafy de
Bruijn’a dla m =2, czyli np. dla 0 i 1 i n =3oraz n =4.Dlan =3graf ma
8 wierzchołków, czyli {000, 001, 010, 011, 100, 101, 110, 111}. Dowolny wierz-

A.2 Różne typy grafów 101
Rysunek A.3: Grafy butterfly dla n =1, 2, 3.
Rysunek A.4: Grafy de Bruijn’a dla m =2oraz n =3i n =4.

102 Dodatek A. Elementy teorii grafów
chołek jest incydentny do innego wierzchołka wtedy i tylko wtedy, gdy jakaś
część etykiety obu wierzchołków zachodzi na siebie sufiksem lub prefiksem.
Na przykład wierzchołek 000 jest incydentny do wierzchołków: 010, 001, 011.
Szczególnie ciekawe jest, jak odbywa się wyszukiwanie drogi w takim grafie.
Załóżmy, że interesuje nas droga z wierzchołka 000 do 111. Konstrukcja
przebiega w następujący sposób. Wybieramy taki wierzchołek z wierzchołków
incydentnych do 000, który jest najbardziej zgodny z celem, czyli 011. Następny
wierzchołek, który wybierzemy to cel, czyli 111. Całkowitą drogę możemy zapisać
w postaci 000111, która jest równa dwóm długościom adresu, co wyznacza
ilości kroków, jakie musi pokonać komunikat, by dotrzeć do celu.

Dodatek B
Uzgadnianie w asynchronicznym
systemie
Przedstawię szkic dowodu twierdzenia o niemożliwości uzgodnienia wartości w
całkowicie asynchronicznym systemie nawet wtedy, gdy w grupie jest tylko jeden
niepoprawnie działający proces 1 . Pozwoli to zrozumieć dlaczego przedstawione
algorytmy tolerancji bizantyjskich uszkodzeń używają synchroniczności, by osiągnąć
zamierzony cel, jak również jest dobrym wprowadzeniem do zagadnienia
praktycznego uzgadniania w systemach tolerujących uszkodzenia.
B.1 Brak konsensusu i asynchroniczność
Założenia i lematy. Niech P oznacza protokół uzgadniania w asynchronicznym
systemie z N procesami (N ≥ 2). Każdy z procesów p posiada dwa rejestry
x p ,y p mogące przechowywać jedną z wartości v ∈{b, 0, 1}, gdzie b oznacza
wartość nieustaloną. Rejestr x p jest rejestrem początkowym, natomiast y p jest
rejestrem wyjściowym, który początkowo inicjowany jest wartością b. Gdy p
ustala wartość y p jego stan ustalany jest, jako zatwierdzony. Procesy działają
w sposób deterministyczny zgodnie z pewną funkcją przejścia.
Jako wiadomość, będziemy rozumieli parę (p, m), gdzie m ∈ M, gdzie M
jest skończonym zbiorem elementów, a p oznacza adresata wiadomości. Każdy
z procesów posiada bufor wiadomości, który udostępnia dwie operacje:
wyślij(p,m) umieszcza w buforze procesu p wiadomość m.
odbierz(p) usuwa wiadomość (p, m) z bufora wołającego procesu lub zwraca φ
jeżeli wiadomość nie znajduje się w buforze. Wiadomość (p, m) uznawana
jest jako dostarczona po wykonaniu operacji odbierz(p).
1 Szczegóły zainteresowany czytelnik znajdzie w artykule Fischera [FLP85]

104 Dodatek B. Uzgadnianie w asynchronicznym systemie
Przez konfigurację C będziemy rozumieli stan wszystkich procesów wraz z
zawartością ich buforów. Konfiguracja początkowa jest ustalona w sposób taki,
iż każdy procesów jest w stanie początkowym, a bufory wiadomości są puste.
Konfigurację początkową będziemy nazywali przyległą do innej konfiguracji, jeżeli
różni się ona stanem wewnętrznym tylko jednego procesu p.
Na krok wykonywany przez proces p składają się następujące czynności:
wykonanie operacji odbierz(p), zmiany stanu wewnętrznego, wysłaniu skończonego
zbioru wiadomości do innych procesów. Wykonanie kroku jest całkowicie
uzależnione od e =(p, m), co będziemy nazywać zdarzeniem i jeżeli e przenosi
konfigurację C do nowej konfiguracji, to nowa konfiguracja będzie oznaczana
jako e(C).
Przebiegiem σ będziemy określali skończony bądź nieskończony ciąg zdarzeń.
Jeżeli σ będzie skończone to wynikową konfigurację dla C oznaczymy
jako σ(C). Mówimy, że σ(C) jest osiągalne z C. C posiada wartość decyzyjną
v jeżeli y p = v dla jakiegoś p. P jest częściowo poprawny gdy spełnia
następujące wymagania:
1. Żadna z osiągalnych konfiguracji nie posiada więcej, jak jednej wartości
decyzyjnej.
2. Dla każdej z wartości v ∈{0, 1}, któraś z osiągalnych konfiguracji ustala
wartość v.
P jest całkowicie poprawny niezależnie od jednego niepoprawnie działającego
procesu jeżeli jest częściowo poprawny oraz każdy osiągalny przebieg posiada
wartość decyzyjną v. Możemy powiedzieć, że konfiguracja C jest dwuokreślona,
lubjednookreślona, gdy istnieją dla niej przebiegi zarówno prowadzące,
w pierwszym przypadku do decyzji {0, 1} lub tylko do 0 lub 1 w drugim przypadku.
Konfigurację jednookreśloną rozróżniamy na 0-określoną i 1-określoną.
Lemat 1 Załóżmy, że istnieje pewna konfiguracja C. Przebiegi σ 1 ,σ 2 prowadzą
odpowiednio do wynikowych konfiguracji C 1 oraz C 2 . Jeżeli zbiory procesów
biorących udział w przebiegach σ 1 ,σ 2 są rozłączne, to σ 1 może być zastosowana
do C 2 oraz σ 2 do C 1 i oba przebiegi będą prowadziły do pewnej konfiguracji
C 3 .
Dowód. Możemy podzielić N procesów na dwa rozłączne podzbiory A i B.
Jeżeli σ 1 jest przebiegiem, który wiąże się ze zmianą stanu tylko dla procesów
w A (brak komunikacji z B) orazσ 2 jest przebiegiem, który wiąże się ze zmianą
stanu tylko dla procesów w B (brak komunikacji z A), to σ 1 (C A ) jest nową
konfiguracją w A, aσ 2 (C B ) jest nową konfiguracją w B, po zastosowaniu obu
przebiegów. Ponieważ σ 1 ,σ 2 są rozłączne, to σ 1 (C A ) i σ 2 (C B ) też są rozłączne

B.1 Brak konsensusu i asynchroniczność 105
oraz kolejność wykonania σ 1 i σ 2 jest bez znaczenia, zatem C 3 = σ 2 (σ 1 (C)) =
σ 1 (σ 2 (C)).
Lemat 2 P posiada zawsze dwuokreśloną konfigurację początkową.
Dowód. Dowód przez zaprzeczenie. Załóżmy, że P ma 0-określoną lub 1-
określoną konfigurację początkową. Jeżeli konfiguracja początkowa jest np. 0-
określona, to musi istnieć łańcuch konfiguracji początkowych prowadzących do
C 1 . Niech C 0 oznacza konfigurację początkową z łańcucha, która jest bezpośrednio
przyległa do C 1 oraz p będzie procesem, w którym stan jest różny dla
obu konfiguracji.
Rozważmy decydujący przebieg σ z C 0 , w którym proces p nie wykonuje żadnego
kroku, zatem σ może również zaistnieć dla C 1 . Jeżeli σ prowadzi do
v =0to C 1 jest dwuokreślone, natomiast jeżeli v =1,toC 0 jest dwuokreślone.
Dlatego początkowa konfiguracja jest zawsze dwuokreślona.
Lemat 3 Niech C będzie dwuokreśloną konfiguracją w P oraz e =(p, m) będzie
zdarzeniem istniejącym dla C. Niech C oznacza zbiór konfiguracji osiągalnych
z C bez zaistnienia e oraz D = e(C) ={e(E)|E ∈Ci e może zaistnieć w E},
to D zawiera dwuokreśloną konfigurację.
Dowód. Wiemy e może zajść w C, zatem rozpatrując definicję C oraz, że wiadomość
może być opóźniana dowolnie długo, to e może zaistnieć w dowolnym
E ∈C. Załóżmy, że D nie zawiera dwuokreślonej konfiguracji. Udowodnimy,
że tak nie jest.
Oznaczymy E i , jako jednookreśloną konfigurację osiągalną z C, i ∈{0, 1}.
Jeżeli E i ∈ C oraz F i = e(E i ) ∈ D. W innym przypadku e zaistniało by
osiągnąć E i , więc istnieje F i ∈D, z którego E i jest osiągalne. Zawsze F i
jest i-osiągalne, co wynika z założenia i zarówno F i jest osiągalne z E i ,jak
i na odwrót. Zatem, gdy F i ∈Di D zawiera zarówno 1-osiągalną, jak i 0-
osiągalną konfigurację. Nazwiemy dwie konfiguracje sąsiednimi jeżeli są one
wzajemnie osiągalne tylko w jednym kroku. Istnieją takie sąsiednie konfiguracje
C 1 ,C 2 ∈C,żeD i = e(C i ), i ∈{0, 1} i D i jest i-osiągalne, np. C 1 = e ′ (C 0 ),
gdzie e ′ =(p ′ ,m ′ ). Do rozważenia konieczne są dwa przypadki:
p ′ ≠ p Wtedy D 1 = e ′ (D 0 ), co jest niemożliwe zgodnie z lematem 1, gdyż konfiguracja
następująca po 0-określonej musi być 0-określona.

106 Dodatek B. Uzgadnianie w asynchronicznym systemie
p ′ = p Rozważmy decydujący przebieg σ nie uwzględniający p z C 0 oraz niech
A = σ(C 0 ). Z lematu 1 wynika, że σ może zaistnieć dla D i oraz prowadzi
do i-określonej konfiguracji E i = σ(D i ),i ∈{0, 1}. Także z lematu
1 wynika, e(A) =E 0 oraz e(e ′ (A)) = E 1 . Co za tym idzie, A jest dwuokreślone,
co nie zgadza się z założeniem. Ostatecznie D musi zawierać
dwuokreśloną konfigurację.
Powyższe rozważania prowadzą do wniosku, że każdy decydujący przebieg
rozpoczynający się dwuokreśloną konfiguracją przechodzi do jednookreślonej
konfiguracji w jakimś kroku. Ten krok determinuje przyszłą wartość decyzyjną.
W całkowicie asynchronicznym protokole uzgadniania gdy jakikolwiek z procesów
jest uszkodzony, można unikać takiego kroku, który powoduje przejście
z dwuokreślonej konfiguracji do jednookreślonej. Używając udowodnionych lematów
można pokazać, że następujące twierdzenie jest prawdziwe.
Twierdzenie 5 Nie istnieje taki protokół asynchronicznego uzgadniania P, który
byłby całkowicie poprawny, gdy chociaż jeden proces działa błędnie.
Dowód. Przebieg, który nie prowadzi do uzgodnienia decyzji (wartości) konstruowany
jest w fazach. Utrzymywana jest kolejka procesów początkowo nieuporządkowana.
Bufor wiadomości uporządkowany jest zgodnie z czasem ich
nadania, w porządku od najstarszej wiadomości do najmłodszej. Każda faza
składa się z pewnej liczby kroków. Faza przebiega począwszy od pierwszego
procesu w kolejce procesów, którego bufor wiadomości nie jest pusty na początku
fazy, odbiera on najstarszą wiadomość i jest ustawiany na koniec kolejki.
W ten sposób, żaden z procesów nie jest zagłodzony, wykonuje wszystkie kroki
i odbiera wszelkie wysłane do niego wiadomości.
Niech C 0 jest dwuokreśloną konfiguracją początkową, której istnienie gwarantuje
lemat 2. Załóżmy, że proces p jest na początku kolejki procesów, a m
jest najstarszą wiadomością wysłaną do p, a w innym przypadku φ. Zdarzenie
e =(p, m) jest ostatnim zdarzeniem przeprowadzającym konfigurację C do C ′ ,
gdzie C ′ jest dwuokreślone co gwarantuje lemat 3. Ta sekwencja kroków zakańcza
fazę.
Każda faza zakańcza się dwuokreśloną konfiguracją, co prowadzi do nieskończonego
przebiegu, gdzie decyzja nigdy nie zostaje podjęta, to pociąga za sobą,
że P nie jest całkowicie poprawne.
Zrozumienie tego dowodu daje świadomość, że nie ma protokołu, który pozwalałby
podjąć decyzję przez grupę procesów, jeżeli któryś z nich nie działa

B.2 Uzgadnianie z częściowym zachowaniem poprawności 107
poprawnie, chociaż może odpowiadać na otrzymane wiadomości. Musi istnieć
mechanizm, gdzie pozostałe procesy są w stanie ustalić, który z procesów zawiódł
i wykluczyć go z uzgadniania. Twierdzenie 1 jest istotne z praktycznego
punktu widzenia, gdyż wskazuje, że stosowalne protokoły muszą zakładać synchronizację
między procesami w celu zapewnienia częściowej poprawności.
B.2 Uzgadnianie z częściowym zachowaniem poprawności
Rozpatrujemy system wprowadzony w poprzednim punkcie. Pokażemy protokół
działający dwufazowo, który potwierdza poprawność następującego twierdzenia.
Twierdzenie 6 Istnieje częściowo poprawny protokół uzgadniania, w którym
wszystkie poprawnie działające procesy podejmą decyzję, jeżeli tylko stanowią
większość i podczas uzgadniania wszystkie, te procesy pozostaną sprawne.
Szkic dowodu. Każdy proces konstruuje skierowany graf G, gdzie węzłami są
inne procesy, rozsyła do wszystkich procesów wiadomość ze swoim numerem i
czeka na L − 1 odpowiedzi na wiadomość od innych procesów, L = ⌈ ⌉
(N+1)
2 . G
ma gałąź od i do j jeżeli j odbierze wiadomość. G jest stopnia L − 1.
Druga faza. Procesy konstruują graf G + , tak, że każdy proces k po zakończeniu
fazy zna wszystkie krawędzie (j, k) incydentne do k w G + ,jakrównież
początkowe wartości dla j. Konstrukcja G + przebiega w ten sposób, że każdy
proces rozgłasza numery L − 1 procesów, od których otrzymało komunikat w
fazie pierwszej, następnie czeka na odpowiedzi od każdego poprzednika w G z
fazy pierwszej. W ten sposób k wie o L−1 sąsiadach, jak również o wszystkich
węzłach, dla których on jest sąsiadem. Zatem każdy z procesów zna początkową
klikę w G + o wartości przynajmniej L. Następnie każdy proces podejmuje
decyzję na podstawie odebranych wartości początkowych od innych procesów.
Ten protokół ma bardzo ważną właściwość, a mianowicie wystarczy jedynie,
⌈ to żeby⌉ większość procesów była sprawna, by uzgodnienie doszło do skutku
(N+1)
2 . Gdyby uzgodnienie nie doszło do skutku, bo jakiś z poprawnych procesów
odmówiłby uczestniczenia w protokole, to konieczne byłoby rozpoczęcie
uzgadniania od początku wykluczając ten proces. Opisany protokół do złudzenia
przypomina ten, który stosowano do rozwiązania problemu bizanyjskich generałów,
z tym wyjątkiem, że tu, każdy z uczestników uzgadnia jedną wartość dla
całej grupy.

Bibliografia
[ADS02]
[CC]
J. Aspnes, Z. Diamadi, and G. Shah. Fault-tolerant routing in peerto-peer
systems. In PODC ’02: Proceedings of the twenty-first
annual symposium on Principles of distributed computing, pages
223–232, New York, NY, USA, 2002. ACM Press.
N. Christin and J. Chuang. A cost-based analysis of overlay routing
geometries. In Proceedings of IEEE INFOCOM’05.
[CDG + 02] Miguel Castro, Peter Druschel, Ayalvadi Ganesh, Antony Rowstron,
and Dan S. Wallach. Secure routing for structured peer-to-peer
overlay networks. SIGOPS Oper. Syst. Rev., 36(SI):299–314, 2002.
[CDKR02] Miguel Castro, Peter Druschel, Anne-Marie Kermarrec, and Antony
Rowstron. Scribe: A large-scale and decentralized application-level
multicast infrastructure. IEEE Journal on Selected Areas in Communication
(JSAC), 20(8), oct 2002.
[CKPS01]
[CKS00]
Christian Cachin, Klaus Kursawe, Frank Petzold, and Victor Shoup.
Secure and efficient asynchronous broadcast protocols. In CRYPTO
’01: Proceedings of the 21st Annual International Cryptology Conference
on Advances in Cryptology, pages 524–541. Springer-Verlag,
2001.
Christian Cachin, Klaus Kursawe, and Victor Shoup. Random oracles
in constantipole: practical asynchronous byzantine agreement
using cryptography (extended abstract). In PODC ’00: Proceedings
of the nineteenth annual ACM symposium on Principles of distributed
computing, pages 123–132. ACM Press, 2000.
[CL99a] M. Castro and B. Liskov. A correctness proof for a practical
byzantine-fault-tolerant replication algorithm. Technical report,
1999.

110 BIBLIOGRAFIA
[CL99b]
[CL99c]
Miguel Castro and Barbara Liskov. Authenticated byzantine fault
tolerance without public-key cryptography. Technical Memo MIT-
LCS-TM-589, MIT, June 1999.
Miguel Castro and Barbara Liskov. Practical byzantine fault tolerance.
In OSDI ’99: Proceedings of the third symposium on Operating
systems design and implementation, pages 173–186. USENIX
Association, 1999.
[CL00] Miguel Castro and Barbara Liskov. Proactive recovery in a
byzantine-fault-tolerant system. In Fourth Symposium on Operating
Systems Design and Implementation (OSDI), San Diego, USA,
October 2000.
[CMM02]
[Coh03]
[CRB01]
Russ Cox, Athicha Muthitacharoen, and Robert Morris. Serving dns
using chord. In Proceedings of the 1st International Workshop on
Peer-to-Peer Systems (IPTPS), Cambridge, MA, March 2002.
Bram Cohen. Incentives Build Robustness in BitTorrent. In Workshop
on Economics of Peer-to-Peer Systems, Berkeley,CA,USA,
June 2003.
R. Chandra, V. Ramasubramanian, and K. Birman. Anonymous gossip:
Improving multicast reliability in mobile ad-hoc networks. In
ICDCS ’01: Proceedings of the The 21st International Conference
on Distributed Computing Systems, page 275. IEEE Computer Society,
2001.
[CSWH00] Ian Clarke, Oskar Sandberg, Brandon Wiley, and Theodore W.
Hong. Freenet: A distributed anonymous information storage and
retrieval system. In Proceedings of Designing Privacy Enhancing
Technologies: Workshop on Design Issues in Anonymity and Unobservability,
pages 46–66, July 2000.
[CWC]
N. Christin, A. Weigend, and J. Chuang. Content availability, pollution
and poisoning in peer-to-peer file sharing networks. In Proceedings
of ACM EC’05.
[CY01] R. Chen and W. Yeager. Poblano - a distributed trust model for
peer-to-peer networks, 2001.
[DMS04]
R. Dingledine, N. Mathewson, and P. Syverson. Tor: The secondgeneration
onion router, 2004.
[Dou02] J. Douceur. The sybil attack, 2002.

BIBLIOGRAFIA 111
[DZDS03]
[FLP85]
[FM02]
F. Dabek, B. Zhao, P. Druschel, and I. Stoica. Towards a common
api for structured peer-to-peer overlays, 2003.
Michael J. Fischer, Nancy A. Lynch, and Michael S. Paterson. Impossibility
of distributed consensus with one faulty process. J. ACM,
32(2):374–382, 1985.
Michael J. Freedman and Robert Morris. Tarzan: A peer-to-peer
anonymizing network layer. In Proceedings of the 9th ACM Conference
on Computer and Communications Security (CCS-9), Washington,
D.C., November 2002.
[Gon99] Li Gong. Inside Java 2 platform security architecture, API design,
and implementation. Addison-Wesley Longman Publishing
Co., Inc., Boston, MA, USA, 1999.
[HKM + 87] J. Howard, M. Kazar, S. Menees, D. Nichols, M. Satyanarayanan,
Robert N. Sidebotham, and M. West. Scale and performance in a
distributed file system. In SOSP ’87: Proceedings of the eleventh
ACM Symposium on Operating systems principles, pages 1–2, New
York, NY, USA, 1987. ACM Press.
[KBC + 00]
[KK03]
[KMR02]
[KRT03]
John Kubiatowicz, David Bindel, Yan Chen, Patrick Eaton, Dennis
Geels, Ramakrishna Gummadi, Sean Rhea, Hakim Weatherspoon,
Westly Weimer, Christopher Wells, and Ben Zhao. Oceanstore: An
architecture for global-scale persistent storage. In Proceedings of
ACM ASPLOS. ACM, November 2000.
M. Frans Kaashoek and David R. Karger. Koorde: A simple degreeoptimal
distributed hash table. In Proceedings of the 2nd International
Workshop on Peer-to-Peer Systems (IPTPS ’03), 2003.
A. Keromytis, V. Misra, and D. Rubenstein. Sos: Secure overlay
services, 2002.
J. Kangasharju, K. Ross, and D. Turner. Secure and resilient peerto-peer
e-mail: Design and implementation, 2003.
[LKRG03] D. Loguinov, A. Kumar, V. Rai, and S. Ganesh. Graph-theoretic
analysis of structured peer-to-peer systems; routing distances and
fault resilience. In In Proceedings of the ACM SIGCOMM ’03 Conference,
Karlsruhe, Germany, August 2003., 2003.

112 BIBLIOGRAFIA
[LNBK02] D. Liben-Nowell, H. Balakrishnan, and D. Karger. Analysis of the
evolution of peer-to-peer systems. In In Proceedings of the Twenty-
First Annual Symposium on Principles of Distributed Computing.,
pages 233–242. ACM Press, 2002., 2002.
[MM02]
[MVO96]
[PRR97]
P. Maymounkov and D. Mazieres. Kademlia: A peer-to-peer information
system based on the xor metric, 2002.
Alfred J. Menezes, Scott A. Vanstone, and Paul C. Van Oorschot.
Handbook of Applied Cryptography. CRC Press, Inc., 1996.
C. Greg Plaxton, Rajmohan Rajaraman, and Andrea W. Richa. Accessing
nearby copies of replicated objects in a distributed environment.
In ACM Symposium on Parallel Algorithms and Architectures,
pages 311–320, 1997.
[RD01a] Antony Rowstron and Peter Druschel. Storage management and
caching in PAST, a large-scale, persistent peer-to-peer storage utility.
In 18th ACM Symposium on Operating Systems Principles
(SOSP’01), pages 188–201, oct 2001.
[RD01b]
[REG + 03]
[RFH + 00]
[RSA77]
[SGR97]
Antony I. T. Rowstron and Peter Druschel. Pastry: Scalable, decentralized
object location, and routing for large-scale peer-to-peer
systems. In Middleware 2001: Proceedings of the IFIP/ACM International
Conference on Distributed Systems Platforms Heidelberg,
pages 329–350. Springer-Verlag, 2001.
S. Rhea, P. Eaton, D. Geels, H. Weatherspoon, B. Zhao, and J. Kubiatowicz.
Pond: The oceanstore prototype. In Proceedings of the
Conference on File and Storage Technologies. USENIX, 2003.
Sylvia Ratnasamy, Paul Francis, Mark Handley, Richard Karp, and
Scott Shenker. A scalable content addressable network. Technical
Report TR-00-010, Berkeley, CA, 2000.
R. L. Rivest, A. Shamir, and L. M. Adelman. A method for obtaining
digital signatures and public-key cryptosystems. Technical Report
MIT/LCS/TM-82, 1977.
P F Syverson, D M Goldschlag, and M G Reed. Anonymous connections
and onion routing. In IEEE Symposium on Security and
Privacy, pages 44–54, Oakland, California, 4–7 1997.
[Sha79] Adi Shamir. How to share a secret. Commun. ACM, 22(11):612–613,
1979.

BIBLIOGRAFIA 113
[Sho00]
Victor Shoup. Practical threshold signatures. Lecture Notes in Computer
Science, 1807:207, 2000.
[SM02] Emil Sit and Robert Morris. Security considerations for peer-topeer
distributed hash tables. In IPTPS ’01: Revised Papers from
the First International Workshop on Peer-to-Peer Systems, pages
261–269. Springer-Verlag, 2002.
[SMK + 01] Ion Stoica, Robert Morris, David Karger, Frans Kaashoek, and Hari
Balakrishnan. Chord: A scalable Peer-To-Peer lookup service for
internet applications. In Proceedings of the 2001 ACM SIGCOMM
Conference, pages 149–160, 2001.
[Ste99]
W. Richard Stevens. UNIX network programming, volume 1,2 (2nd
ed.). Prentice Hall PTR, 1999.
[Tan95] Andrew S. Tanenbaum. Distributed operating systems. Prentice-
Hall, Inc., Upper Saddle River, NJ, USA, 1995.
[TS01]
[ZHS + 03]
[ZvRM02]
Andrew S. Tanenbaum and Maarten Van Steen. Distributed Systems:
Principles and Paradigms. Prentice Hall PTR, 2001.
Ben Y. Zhao, Ling Huang, Jeremy Stribling, Sean C. Rhea, Anthony
D Joseph, and John D. Kubiatowicz. Tapestry: A global-scale
overlay for rapid service deployment. IEEE Journal on Selected
Areas in Communications, 2003. Special Issue on Service Overlay
Networks, to appear.
Lidong Zhou, Robbert van Renesse, and Michael Marsh. Implementing
ipv6 as a peer-to-peer overlay network. In SRDS ’02: Proceedings
of the 21st IEEE Symposium on Reliable Distributed Systems
(SRDS’02), page 347, Washington, DC, USA, 2002. IEEE Computer
Society.