Popularne tematy
#
Bonk Eco continues to show strength amid $USELESS rally
#
Pump.fun to raise $1B token sale, traders speculating on airdrop
#
Boop.Fun leading the way with a new launchpad on Solana.
Wątek podsumowujący badania dotyczące latencji w najlepszym przypadku i odporności protokołów częściowej synchronizacji.
Dolna granica 1 (DLS): Niemożliwe jest rozwiązanie problemu zgody w warunkach częściowej synchronizacji w obliczu przeciwnika bizantyjskiego, jeśli f >= n/3. (
Dolna granica 2 (Latencja w najlepszym przypadku): Dla częściowo synchronizowanej transmisji bizantyjskiej z f stronami bizantyjskimi, 3 rundy są konieczne i wystarczające, jeśli 3f +1 <= n <= 5f-1 (
Górna granica: np. PBFT, Tendermint, Simplex tolerują f < n/3 błędów i osiągają 3-rundową latencję w najlepszym przypadku (link:
Dwie drogi do poprawy: (A) tolerować więcej awarii, (B) osiągnąć lepszą latencję w dobrych przypadkach, gdy występuje mniej błędów bizantyjskich
Droga (A): tolerować więcej awarii
Dolna granica 3: Potrzebujemy n >= 3f + 2c + 1, aby tolerować f błędów bizantyjskich i c błędów awarii w warunkach częściowej synchronizacji (folklor?)
Górna granica: Uogólnić dowolny z wcześniej wspomnianych protokołów, np. PBFT, z rozmiarem kworum 2f+c+1 zamiast 2f+1 (folklor?)
Avenue (B): osiągnąć lepszą latencję w dobrym przypadku, gdy występuje mniej błędów bizantyjskich
Dolna granica 4: Potrzebujemy n >= 3f + 2p - 1, aby tolerować f błędów bizantyjskich i osiągnąć 2-rundową latencję w dobrym przypadku, gdy p <= f (
Górna granica: FaB, SBFT, Kudzu, Alpenglow, Minimmit (niektóre z nich ustawiają f = p ~= n/5) (
Łączenie dróg (A) i (B): Hydrangea, nasz nowy dokument () z @nibeshrestha2 i @aniketpkate
Dolna granica 5: Nie istnieje częściowo synchronny protokół rozgłaszania bizantyjskiego, który toleruje f błędów bizantyjskich i c błędów awarii dla n = 3f + 2c + k + 1, i osiąga optymistyczną latencję w dobrym przypadku wynoszącą dwie rundy, tolerując więcej niż p = (c+k+2) / 2 błędnych stron (bizantyjskich lub awaryjnych); k to parametr regulowany z pewnymi ograniczeniami.
Górna granica: Hydrangea przedstawia protokół dla n = 3f+2c+k+1, aby tolerować f błędów bizantyjskich, c błędów awarii, i możemy uzyskać
(i) optymistyczną latencję w dobrym przypadku wynoszącą 2 rundy, tolerując p = (c+k)/2 błędów, oraz
(ii) latencję w dobrym przypadku wynoszącą 3 rundy w przeciwnym razie.
4,15K
Najlepsze
Ranking
Ulubione