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

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.