팩소스 (컴퓨터 과학)

3. 전제

팩소스 알고리즘은 다음과 같은 전제를 기반으로 한다.^:3-4

• 프로세서:
• 프로세서는 임의의 속도로 동작하며, 실패할 수 있다.^[1]
• 안정적인 저장소를 가진 프로세서는 실패 후 프로토콜에 다시 참여할 수 있다.^[1]
• 프로세서는 담합, 거짓말, 또는 프로토콜을 파괴하려는 시도를 하지 않는다. (즉, 비잔틴 오류는 발생하지 않는다.)^[1]
• 네트워크:
• 프로세서 간 메시지 전송은 비동기적으로 이루어지며, 전달 시간은 임의적이다.^[1]
• 메시지는 손실, 순서 변경, 중복될 수 있지만, 손상되지는 않는다.^[1]
• 메시지 채널 내의 임의/악의적 행위로 인한 오염된 메시지에 대한 해법은 비잔틴 팩소스를 참조한다.

4. 역할

팩소스는 프로세서의 행동을 프로토콜 상의 그들의 역할(클라이언트, 수락자, 제안자, 학습자, 리더)에 따라 설명한다. 일반적인 구현에서 단일 프로세서는 하나 이상의 역할을 동시에 수행한다. 이것은 프로토콜의 정확성에 영향을 미치지 않는다. (일반적으로 프로토콜 내 메시지 지연이나 횟수를 향상시키기 위해 역할을 결합한다.)

; 클라이언트

:: 클라이언트는 ''요청'' 을 분산 시스템에 게시하고, ''응답''을 기다린다. 분산 파일 서버 안에 있는 파일 쓰기 요청을 예로 들 수 있다.

:; 수락자(유권자)

:: 수락자는 프로토콜의 장애 허용 "메모리"로 동작한다. 그룹 내 모인 수락자는 쿼럼이라고 불린다. 수락자에게 보내진 메시지는 반드시 수락자들의 쿼럼에 보내져야한다. 쿼럼의 수락자로 받은 복사본 외 수락자로부터 받은 메시지는 무시된다.

:; 제안자

:: 제안자는 클라이언트를 대변하며 수락자에게 동의하도록 설득을 시도하고 옹호한 클라이언트 요청을 설득하고 충돌이 발생할 경우 프로토콜을 진전시키기 위해 중재자처럼 행동한다.

:; 학습자

:: 학습자는 프로토콜을 위한 응답 요소로 행동한다. 클라이언트의 요청이 수락자에 의해 동의되면 학습자는 움직인다 (즉, 요청을 실행하고 클라이언트에게 응답을 보낸다). 처리의 가용성을 높이기 위해 추가적인 학습자를 추가할 수 있다.

:; 리더

:: 팩소스는 진행을 위해 식별 가능한 제안자(리더)를 필요로 한다. 많은 프로세스가 자신이 리더라고 믿을 수 있지만, 프로토콜은 그들 중 하나가 선택될 때만 진행을 보장한다. 만약 두 프로세스가 그들이 리더라고 믿는다면, 그들은 지속적으로 충돌하는 업데이트를 제안하여 프로토콜을 지연시킬 수 있다. 하지만 이 경우에도 안전성은 유지된다.

대부분의 팩소스 배포에서, 각 참여 프로세스는 제안자, 수락자 및 학습자의 세 가지 역할을 수행합니다. 이렇게 하면 정확성을 훼손하지 않으면서 메시지 복잡성이 크게 줄어듭니다.

역할을 병합함으로써 프로토콜은 데이터베이스 커뮤니티에서 전형적인 효율적인 클라이언트-마스터-복제 스타일 배포로 "축소"됩니다. 팩소스 프로토콜(병합된 역할을 가진 구현 포함)의 장점은 안전성 속성을 보장한다는 것입니다.

일반적인 구현의 메시지 흐름은 Multi-Paxos 섹션에서 다룹니다.

4. 1. 클라이언트 (Client)

4. 2. 제안자 (Proposer)

4. 3. 수락자 (Acceptor)

4. 4. 학습자 (Learner)

5. 안전성과 생존성 속성

팩소스는 다음과 같은 안전성과 생존성 속성을 보장한다.

• 유효성 (또는 비자명성): 제안된 값만이 선택 받고 학습될 수 있다.
• 일치 (또는 일관성, 안전성): 단 하나의 값만이 학습될 수 있다. 즉, 다른 두 학습자는 서로 다른 값을 배울 수 없다.
• 종결 (또는 생존성): 충분한 프로세서가 정상 작동 중일 때 어떤 값이 제안되면 학습자는 결국 어떤 값을 학습한다.

5. 1. 안전성 (Safety)

• 유효성 (Validity): 제안된 값만이 선택될 수 있다.^[23]
• 일치 (Agreement): 단 하나의 값만이 학습될 수 있다. 즉, 다른 두 학습자는 서로 다른 값을 배울 수 없다.^[23][24]

5. 2. 생존성 (Liveness)

6. 베이직 팩소스 (Basic Paxos)

베이직 팩소스 프로토콜은 팩소스 계열 중 가장 기본적인 프로토콜이다. 베이직 팩소스 프로토콜의 각 "인스턴스"(또는 "실행")는 단일 출력 값을 결정한다. 이 프로토콜은 여러 라운드에 걸쳐 진행되며, 성공적인 라운드는 2단계로 구성된다.

== 1단계: 준비 (Prepare) ==

제안자는 제안 번호로 쓰기 위한 숫자 ''N''을 선택하며, 이 숫자는 이전의 제안 번호들보다 커야 한다. 제안자는 ''N''을 포함한 ''준비'' 요청을 수락자들의 쿼럼에 보낸다. 제안자는 쿼럼을 구성할 만큼 충분한 수락자와 통신할 수 없다면 Paxos를 시작해서는 안 된다.

수락자들은 제안자로부터 ''준비'' 요청을 기다린다. 만약 수락자가 ''준비'' 요청을 받았을 경우, 수락자는 반드시 받은 ''준비'' 요청의 식별 번호 ''N''을 확인해야 한다.

두 가지 경우가 있을 수 있다:

• ''N''이 이전에 제안자들로부터 수락자가 받은 어떤 제안 번호들보다 높은 경우, 수락자는 제안자에게 n보다 크지 않은 제안 번호(더 오래된 제안 번호)를 허용하지 않겠다는 ''약속''으로 응답한다. 이전에 수락한 제안이 있을 경우, 이전에 수락한 제안 번호 ''M''과 대응하는 승인된 값 ''W''는 제안자에 대한 응답에 반드시 포함되어야 한다.
• ''N''이 이전에 제안자로부터 수락자가 받은 제안 번호보다 작거나 같은 경우, 수락자는 받은 요청을 무시할 수 있다. 응답하지 않아도 팩소스는 동작하나 최적화를 위해 제안 번호 n으로 합의를 만들려는 시도를 멈추도록 거절 (''NAK'') 응답을 보내 제안자에게 알려주는 것이 좋다.

6. 1. 1단계: 준비 (Prepare)

• ''N''이 이전에 제안자들로부터 수락자가 받은 어떤 제안 번호들보다 높은 경우, 수락자는 제안자에게 n보다 크지 않은 제안 번호(더 오래된 제안 번호)를 허용하지 않겠다는 ''약속''으로 응답한다. 이전에 수락한 제안이 있을 경우, 이전에 수락한 제안 번호 ''M''과 대응하는 승인된 값 ''W''는 제안자에 대한 응답에 반드시 포함되어야 한다.
• ''N''이 이전에 제안자로부터 수락자가 받은 제안 번호보다 작거나 같은 경우, 수락자는 받은 요청을 무시할 수 있다. 응답하지 않아도 팩소스는 동작하나 최적화를 위해 제안 번호 n으로 합의를 만들려는 시도를 멈추도록 거절 (''NAK'') 응답을 보내 제안자에게 알려주는 것이 좋다.

6. 2. 2단계: 수락 (Accept)

7. 멀티 팩소스 (Multi-Paxos)

멀티 팩소스는 베이직 팩소스를 확장하여 일련의 값에 대한 합의를 효율적으로 처리하는 프로토콜이다. 팩소스의 일반적인 적용법에서는 연속된 합의 값이 분산 상태 기계에 대한 명령처럼 동작하길 요구한다. 각 명령이 베이직 팩소스 프로토콜의 단일 인스턴스의 결과라면, 상당량의 오버헤드가 발생한다.

하지만 리더가 비교적 안정적이면 1단계(준비, 약속)는 불필요해진다. 따라서 미래의 프로토콜 인스턴스이 동일한 리더로 진행된다면 1단계를 생략할 수 있다. 이를 위해 각 라운드에서 같은 리더에 의해 증가되는 라운드 번호 I를 메시지에 넣는다. 멀티 팩소스는 장애 방지 메시지 횟수를 4번에서 2번으로 줄인다.

일반적인 멀티 팩소스의 적용법은 제안자, 수락자 그리고 학습자 역할을 "서버"로 합친다. 따라서 "클라이언트"와 "서버"만이 남는다.

다음 다이어그램은 제안자, 수락자, 학습자 역할이 "서버"로 합쳐진 베이직 팩소스 프로토콜의 첫 인스턴스를 보여준다.

```

Client Servers

| | | | --- First Request ---

X-------->| | | Request

| X->|->| Prepare(N)

| |<-X--X Promise(N, I, {Va, Vb})

| X->|->| Accept!(N, I, Vn)

| X<>X<>X Accepted(N, I)

|<--------X | | Response

| | | |

```

이전 베이직 팩소스 프로토콜 인스턴스들과 같은 리더를 쓰는 베이직 팩소스 프로토콜의 인스턴스들 중 일부는 1단계를 생략할 수 있다.

```

Client Servers

X-------->| | | Request

| X->|->| Accept!(N,I+1,W)

| X<>X<>X Accepted(N,I+1)

|<--------X | | Response

| | | |

8. 패스트 팩소스 (Fast Paxos)

패스트 팩소스(Fast Paxos)는 베이직 팩소스를 일반화하여 종단 간 메시지 지연을 줄인 프로토콜이다. 베이직 팩소스에서는 클라이언트의 요청부터 학습까지 3번의 메시지 지연이 발생하는 반면, 패스트 팩소스는 충돌이 없을 경우 2번의 메시지 지연으로 합의를 이룰 수 있다.

이를 위해 패스트 팩소스는 클라이언트가 리더를 거치지 않고 수락자에게 직접 ''Accept!'' 메시지를 보내도록 허용한다. 수락자는 베이직 팩소스와 마찬가지로 리더와 학습자에게 ''Accepted'' 메시지를 전달하며, 이를 통해 클라이언트에서 학습자까지 2번의 메시지 지연이 발생한다.

하지만 패스트 팩소스는 베이직 팩소스보다 더 많은 수락자(3f+1)를 필요로 한다. 또한, 제안이 충돌하는 경우 복구 과정이 필요하며, 이 과정에서 추가적인 메시지 지연이 발생할 수 있다. 리더가 충돌을 감지하고 중재하는 경우(중재된 복원) 4번의 메시지 지연이, 리더의 중재 없이 수락자들이 자체적으로 복구하는 경우(중재가 없는 복원) 3번의 메시지 지연이 발생한다. (학습자가 수락자 역할을 겸할 경우 2번)

```

클라이언트 리더 수락자 학습자

| | | | | | | |

| X--------->|->|->|->| | | Any(N,I,Recovery)

| | | | | | | |

X------------------->|->|->|->| | | Accept!(N,I,W)

| |<---------X--X--X--X------>|->| Accepted(N,I,W)

|<------------------------------------X--X Response(W)

| | | | | | | |

```

```

클라이언트 리더 수락자 학습자

| | | | | | | | |

| | | | | | | | |

| | | | | | | | | !! 동시 충돌 제안

| | | | | | | | | !! 수락자에 의해 다른 순서로 수신됨

| | | | | | | | | !!

| X--------------?|-?|-?|-?| | | Accept!(N,I,V)

X-----------------?|-?|-?|-?| | | Accept!(N,I,W)

| | | | | | | | |

| | | | | | | | | !! 수락자는 값에 동의하지 않음

| | |<-------X--X->|->|----->|->| Accepted(N,I,V)

| | |<-------|<-|<-X--X----->|->| Accepted(N,I,W)

| | | | | | | | |

| | | | | | | | | !! 충돌 감지 및 복구

| | X------->|->|->|->| | | Accept!(N+1,I,W)

| | |<-------X--X--X--X----->|->| Accepted(N+1,I,W)

|<---------------------------------X--X Response(W)

| | | | | | | | |

```

```

클라이언트 서버

| | | | | |

| | X->|->|->| Any(N,I,Recovery)

| | | | | |

| | | | | | !! 동시적인 상충하는 제안

| | | | | | !! 서버에 서로 다른 순서로 수신됨

| | | | | |

| X--------?|-?|-?|-?| Accept!(N,I,V)

X-----------?|-?|-?|-?| Accept!(N,I,W)

| | | | | |

| | | | | | !! 서버가 값에 대해 동의하지 않음

| | X<>X->|->| Accepted(N,I,V)

| | |<-|<-X<>X Accepted(N,I,W)

| | | | | |

| | | | | | !! 충돌 감지 및 복구

| | X<>X<>X<>X Accepted(N+1,I,W)

|<-----------X--X--X--X Response(W)

| | | | | |

9. 일반화된 팩소스 (Generalized Paxos)

일반화된 팩소스는 복제 상태 머신의 연산과 이를 구현하는 합의 프로토콜 간의 관계를 탐구한다. 주요 발견은 상충하는 제안이 어떤 순서로든 적용될 수 있을 때, 즉 제안된 연산이 상태 머신에 대한 교환 연산일 때 팍소스의 최적화와 관련이 있다. 이러한 경우, 상충하는 연산이 모두 수락될 수 있으며, 충돌 해결 및 거부된 연산의 재제안에 필요한 지연을 피할 수 있다.

일반화된 합의는 분산 상태 기계의 명령과 상태 머신들의 일관성을 유지하기 위해 쓰이는 합의 프로토콜 사이의 관계를 다룬다. 주된 연구는 충돌된 제안이 어떠한 순서로든지 상태 머신에 반영될 수 있을 때의 합의 프로토콜의 최적화를 포함한다. 충돌된 제안의 명령들이 자리 바꿈이 가능한 상태 기계의 명령인 경우이다. 이러한 사례에서 충돌된 명령들은 충돌을 해결하거나 반복 제안, 거절 등에 필요한 지연을 피하기 위해 동시에 수용될 수 있다.

이 개념은 더욱 일반화되어 끊임없이 증가하는 교환 연산 시퀀스로 발전하며, 이 중 일부는 안정된 것으로 알려져 있으며 (따라서 실행될 수 있다). 프로토콜은 이러한 시퀀스를 추적하여 하나의 시퀀스에 속한 모든 제안된 연산이 안정화되기 전에 이와 교환되지 않는 연산이 안정화되는 것을 허용하지 않도록 한다.

일반화된 팩소스는 연산 의미론을 활용하여 충돌을 피할 수 있다. 이를 통해 프로토콜은 실제로 패스트 팩소스보다 더 빠르게 작동할 수 있다. 그러나 충돌이 발생하면 복구를 위해 두 번의 왕복 통신이 추가로 필요하다.

일반적인 경우, 이러한 왕복 통신은 불가피하며 여러 명령이 한 라운드 동안 허용될 수 있다는 사실에서 비롯된다. 이로 인해 충돌이 자주 발생할 경우 이 프로토콜은 팩소스보다 더 많은 비용이 든다. 일반화된 팩소스의 복구 시간을 개선하기 위해 다음과 같은 두 가지 가능한 개선 사항이 있다.

• 코디네이터가 모든 승인자의 쿼럼에 속하는 경우 (라운드 N을 '중앙 집중식'이라고 함), 라운드 N에서 충돌이 발생하여 라운드 N+1에서 복구하기 위해 코디네이터는 1단계를 건너뛰고 라운드 N 동안 마지막으로 승인한 시퀀스를 2단계에서 제안한다. 이렇게 하면 복구 비용이 한 번의 왕복 통신으로 줄어든다.
• 라운드 N과 N+1 모두 고유하고 동일한 중앙 집중식 쿼럼을 사용하는 경우, 승인자가 라운드 N에서 충돌을 감지하면 (i) 라운드 N에서 코디네이터가 승인한 시퀀스와 (ii) 라운드 N에서 승인한 가장 큰 비충돌 접두사를 모두 접미사로 하는 시퀀스를 라운드 N+1에서 자발적으로 제안한다. 이 변형을 사용하면 복구 비용이 단일 메시지 지연으로 줄어들어 최적이다. 여기서 라운드에서 고유한 쿼럼을 사용하는 것은 라이브니스에 해를 끼치지 않는다. 이는 이 쿼럼의 모든 프로세스가 다음 라운드의 준비 단계에 대한 읽기 쿼럼이기 때문이다.^[4]

10. 비잔틴 팩소스 (Byzantine Paxos)

팩소스는 거짓말, 메시지 조작, 다른 참가자와의 공모, 선택적 불참 등 참가자의 임의적인 오류를 지원하도록 확장될 수 있다. 이러한 유형의 오류는 비잔틴 장애라고 불린다.

리스코프와 카스트로가 도입한 비잔틴 팩소스^[5]는 다른 프로세서의 작업을 분배하고 검증하는 역할을 하는 추가 메시지(''증명'')를 추가하여 정보를 분배하고 다른 프로세서의 행동을 증명한다.^[27]

```

Client Proposer Acceptor Learner

| | | | | | |

X-------->| | | | | | Request

| X--------->|->|->| | | Accept!(N,I,V)

| | X<>X<>X | | Verify(N,I,V) - BROADCAST

| |<---------X--X--X------>|->| Accepted(N,V)

|<---------------------------------X--X Response(V)

| | | | | | |

```

마틴과 알비시가 소개한 빠른 비잔틴 팍소스^[6]는 클라이언트가 명령을 승인자에게 직접 보내기 때문에 지연을 제거한다. 빠른 비잔틴 팍소스에서 ''승인됨'' 메시지는 모든 승인자와 모든 학습자에게 전송되는 반면, 빠른 팍소스는 ''승인됨'' 메시지를 학습자에게만 전송한다.

```

Client Acceptor Learner

| | | | | |

X----->|->|->| | | Accept!(N,I,V)

| X<>X<>X------>|->| Accepted(N,I,V) - BROADCAST

|<-------------------X--X Response(V)

| | | | | |

```

두 프로토콜에서 실패 시나리오는 같다. 각 학습자는 서로 다른 승인자로부터 F+1개의 동일한 메시지를 받기를 기다린다. 수락자는 정보를 공유하기 때문에 학습자의 상태를 예측할 수 있다. 학습자가 F+1개의 동일한 메시지를 받을 수 없는 경우 정상인 수락자는 합의된 값을 다시 브로드캐스팅한다.

```

Client Acceptor Learner

| | | ! | | !! One Acceptor is faulty

X----->|->|->! | | Accept!(N,I,V)

| X<>X<>X------>|->| Accepted(N,I,{V,W}) - BROADCAST

| | | ! | | !! Learners receive 2 different commands

| | | ! | | !! Correct Acceptors notice error and choose

| X<>X<>X------>|->| Accepted(N,I,V) - BROADCAST

|<-------------------X--X Response(V)

| | | ! | |

11. 실제 구현 사례

• 구글은 장애 발생 시 복제본의 일관성을 유지하기 위해 자사의 분산 록 서비스인 Chubby에서 팩소스 알고리즘을 사용한다.<sup>[7]</sup> Chubby는 현재 구글 애널리틱스 및 기타 제품에서 사용 중인 빅테이블에서 사용된다. 구글 스패너와 메가스토어는 내부적으로 팩소스 알고리즘을 사용한다.
• IBM은 자사의 IBM SAN 볼륨 컨트롤러 제품에서 팩소스 알고리즘을 사용하여 클러스터에서 제공하는 스토리지 가상화 서비스의 구성 및 제어 구성 요소를 실행하는 범용 내결함성 가상 머신을 구현하는 것으로 알려져 있다.<sup>[8]</sup>
• 마이크로소프트는 빙의 오토파일럿 클러스터 관리 서비스와 Windows Server 장애 조치(Failover) 클러스터링에서 팩소스를 사용한다.<sup>[9]</sup>
• WANdisco는 DConE 액티브-액티브 복제 기술 내에 팩소스를 구현했다.<sup>[10]</sup>
• XtreemFS는 파일 데이터와 메타데이터의 내결함성 및 일관된 복제를 위해 팩소스 기반의 리스 협상 알고리즘을 사용한다.<sup>[11]</sup>
• Heroku는 일관된 분산 데이터 저장소를 위해 팩소스를 구현하는 Doozerd를 사용한다.
• Ceph는 팩소스를 모니터 프로세스의 일부로 사용하여 어떤 OSD가 클러스터에서 가동 중인지 합의한다.
• MariaDB Xpand 분산 SQL 데이터베이스는 분산 트랜잭션 해결을 위해 팩소스를 사용한다.<sup>[12]</sup>
• Neo4j HA 그래프 데이터베이스는 v1.9부터 Apache ZooKeeper를 대체하여 팩소스를 구현한다.
• Apache Cassandra NoSQL 데이터베이스는 경량 트랜잭션 기능에만 팩소스를 사용한다.<sup>[13]</sup>
• ScyllaDB NoSQL 데이터베이스는 경량 트랜잭션에 팩소스를 사용한다.<sup>[14]</sup>
• 아마존은 엘라스틱 컨테이너 서비스에서 팩소스를 사용하여 클러스터 상태에 대한 일관된 보기를 유지한다.<sup>[15]</sup>
• 아마존 다이나모DB는 리더 선출 및 컨센서스에 팩소스 알고리즘을 사용한다.<sup>[16]</sup>
• OpenReplica 복제 서비스는 팩소스를 사용하여 사용자가 내결함성 객체를 생성할 수 있도록 하는 개방형 액세스 시스템의 복제본을 유지한다. 이는 동시 라운드를 통해 고성능을 제공하고 동적 멤버십 변경을 통해 유연성을 제공한다.

11. 1. 구글 (Google)

11. 2. 아마존 (Amazon)

11. 3. 기타

12. 결론 및 중도진보적 관점

참조

<sub>[1]</sub> 논문 Paxos Made Moderately Complex https://doi.org/10.1[...] 2015-02-17
<sub>[2]</sub> 웹사이트 Leader Election, Why Should I Care? https://www.elastic.[...] 2021-02-27
<sub>[3]</sub> 간행물 A Probabilistically Correct Leader Election Protocol for Large Groups Cornell University 2000
<sub>[4]</sub> 서적 Proceedings of the 28th ACM symposium on Principles of distributed computing ACM 2009
<sub>[5]</sub> 논문 Practical Byzantine Fault Tolerance http://pmg.csail.mit[...] 2018-03-05
<sub>[6]</sub> 논문 Fast Byzantine Consensus https://www.cs.utexa[...] 2018-03-05
<sub>[7]</sub> 웹사이트 The Chubby lock service for loosely-coupled distributed systems https://static.googl[...] OSDI
<sub>[8]</sub> URL https://groups.csail[...]
<sub>[9]</sub> 웹사이트 Microsoft Research – Emerging Technology, Computer, and Software Research https://www.microsof[...] 2024-09-19
<sub>[10]</sub> Webarchive The Distributed Coordination Engine (DConE) https://www.wandisco[...] 2016-04-15
<sub>[11]</sub> 간행물 Flease - Lease Coordination without a Lock Server http://www.xtreemfs.[...] 25th IEEE International Parallel & Distributed Processing Symposium (IPDPS 2011)
<sub>[12]</sub> 웹사이트 Consistency, Fault Tolerance, and Availability with MariaDB Xpand — MariaDB Documentation https://mariadb.com/[...] 2024-09-19
<sub>[13]</sub> 웹사이트 Lightweight transactions in Cassandra 2.0 https://www.datastax[...] 2024-09-19
<sub>[14]</sub> 웹사이트 Lightweight Transactions {{!}} ScyllaDB Docs https://opensource.d[...] 2024-09-19
<sub>[15]</sub> 웹사이트 Under the Hood of Amazon EC2 Container Service https://www.allthing[...] 2024-09-19
<sub>[16]</sub> URL https://www.usenix.o[...]
<sub>[17]</sub> 논문 Reaching Agreement in the Presence of Faults http://research.micr[...] 2007-02-02
<sub>[18]</sub> 논문 Time, Clocks and the Ordering of Events in a Distributed System http://research.micr[...] 2007-02-02
<sub>[19]</sub> 논문 Implementing Fault-Tolerant Services Using the State Machine Approach: A Tutorial https://web.archive.[...]
<sub>[20]</sub> 논문 The Part-Time Parliament http://research.micr[...] 2007-02-02
<sub>[21]</sub> 학회 Viewstamped Replication: A New Primary Copy Method to Support Highly-Available Distributed Systems http://portal.acm.or[...]
<sub>[22]</sub> 학회 Cheap Paxos http://research.micr[...]
<sub>[23]</sub> 웹사이트 Fast Paxos http://research.micr[...] 2007-02-02
<sub>[24]</sub> 논문 Generalized Consensus and Paxos http://research.micr[...] 2007-02-02
<sub>[25]</sub> 웹사이트 Practical Byzantine Fault Tolerance http://citeseer.ist.[...] 2007-02-02
<sub>[26]</sub> 저널 1988-04-01
<sub>[27]</sub> 저널 Fast Byzantine Consensus https://www.cs.utexa[...] 2018-03-05