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

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ę.