[번역] Istanbul Byzantine Fault Tolerance (EIP-650)

Istanbul Byzantine Fault Tolerance

** EIP에 제안된 초기 IBFT 관련 내용입니다(즉, 1.0 버전) **
원문

용어

Validator: 블록 검증 참여자
Proposer: 합의 라운드에서 블록을 제안하도록 선택된 블록 검증 참여자
Round: 합의 라운드. 라운드는 제안자가 블록 제안을 생성하는 것으로 시작하여 블록 commitment 또는 라운드 변경으로 끝납니다.
Proposal: 합의 처리가 진행 중인 새로운 블록 생성 제안입니다.
Sequence: 제안의 시퀀스 번호. 시퀀스 번호는 이전의 모든 시퀀스 번호보다 커야 합니다. 현재 제안된 각 블록의 높이는 해당 블록과 관련된 시퀀스 번호입니다.
Backlog: 향후 합의 메시지를 보관하는 저장소입니다.
Round state: 사전 준비 메시지, 준비 메시지, 커밋 메시지를 포함한 특정 시퀀스 및 라운드의 합의 메시지입니다.
Consensus proof: 블록이 합의 과정을 거쳤음을 증명할 수 있는 블록의 commitment 서명입니다.
Snapshot: 지난 에포크의 검증자 투표 상태입니다.

합의

이스탄불 BFT는 카스트로-리스코프 99 논문에서 영감을 받았습니다. 그러나 원래의 PBFT는 블록체인에서 작동하도록 하기 위해 상당한 조정이 필요했습니다. 우선, 요청을 보내고 결과를 기다리는 특정 '클라이언트'가 존재하지 않습니다. 대신 모든 검증자를 클라이언트로 볼 수 있습니다. 또한 블록체인을 계속 진행하기 위해 매 라운드마다 제안자가 지속적으로 선정되어 합의를 위한 블록 제안을 생성합니다. 또한 각 합의 결과에 대해 파일 시스템에 대한 읽기/쓰기 작업이 아닌 검증 가능한 새 블록을 생성할 것으로 예상합니다.

이스탄불 BFT는 PRE-PREPARE, PREPARE, COMMIT의 3단계 컨센서스를 사용하여 기존 PBFT를 계승합니다. 시스템은 N 검증자 노드 네트워크에서 최대 F개의 결함 노드를 허용할 수 있으며, 여기서 N = 3F + 1입니다. 각 라운드가 시작되기 전에 검증자는 기본적으로 라운드 로빈 방식으로 검증자 중 한 명을 제안자로 선택합니다. 제안자는 새로운 블록 제안을 제안하고 PRE-PREPARE 메시지와 함께 이를 브로드캐스트합니다. 제안자로부터 PRE-PREPARE 메시지를 받으면 검증자는 PRE-PREPARED 상태로 들어간 다음 PREPARE 메시지를 브로드캐스트합니다. 이 단계는 모든 검증자가 동일한 순서와 동일한 라운드에서 작업하고 있는지 확인하기 위한 것입니다. 검증자는 2F + 1의 PREPARE 메시지를 수신하는 동안 PREPARED 상태로 진입한 후 COMMIT 메시지를 브로드캐스트합니다. 이 단계는 제안된 블록을 수락하고 해당 블록을 체인에 삽입할 것임을 동료들에게 알리기 위한 것입니다. 마지막으로 검증자는 COMMIT 메시지가 2F + 1이 될 때까지 기다렸다가 COMMITED 상태가 되면 블록을 체인에 삽입합니다.

이스탄불 BFT 프로토콜의 블록은 완결성을 가지며, 포크가 없고 유효한 블록이 메인 체인 어딘가에 있어야 함을 의미합니다. 결함이 있는 노드가 메인체인과 완전히 다른 체인을 생성하는 것을 방지하기 위해, 각 검증자는 받은 2F + 1 개의 COMMIT 서명을 헤더의 extraData 필드에 추가한 후 체인에 삽입합니다. 따라서 블록은 자체 검증이 가능하며 라이트 클라이언트도 지원할 수 있습니다. 그러나 extraData는 블록 해시 계산에 문제를 일으킬 수 있습니다. 서로 다른 검증자의 동일한 블록이 서로 다른 COMMIT 서명 집합을 가질 수 있기 때문에 동일한 블록도 서로 다른 블록 해시를 가질 수 있습니다. 이 문제를 해결하기 위해 COMMIT 서명 부분을 제외하여 블록 해시를 계산합니다. 따라서 블록/블록 해시의 일관성을 유지할 수 있을 뿐만 아니라 블록 헤더에 합의 증명을 넣을 수 있습니다.

합의 상태

이스탄불 BFT는 스테이트 머신 복제 알고리즘입니다. 각 검증자는 블록 합의에 도달하기 위해 상태 머신 복제본을 유지합니다.

상태:

NEW ROUND: 제안자가 새로운 블록 제안을 보냅니다. 검증자는 PRE-PREPARE 메시지를 기다립니다.
PRE-PREPARED: 검증자가 PRE-PREPARE 메시지를 수신하고 PRE-PREPARE 메시지를 브로드캐스트합니다. 그런 다음 2F + 1의 PREPARE 또는 COMMIT 메시지를 기다립니다.
PREPARED: 검증자가 2F + 1 개의 PREPARE 메시지를 수신하고 COMMIT 메시지를 브로드캐스트합니다. 그런 다음 2F + 1의 COMMIT 메시지를 기다립니다.
COMMITTED: 검증자가 2F + 1개의 COMMIT 메시지를 받았으며 제안된 블록을 블록체인에 삽입할 수 있습니다.
FINAL COMMITTED: 새 블록이 블록체인에 성공적으로 삽입되었으며 검증자는 다음 라운드를 진행할 준비가 되었습니다.
ROUND CHANGE: 검증자가 제안된 라운드 번호와 동일한 라운드에서 2F + 1의 ROUND CHANGE 메시지를 기다리고 있습니다.
상태 트랜잭션
NEW ROUND → PRE-PREARED:
- 제안자가 txpool에서 트랜잭션을 수집합니다.
- 제안자는 블록 제안을 생성하고 이를 검증자에게 브로드캐스트합니다. 그런 다음 PRE-PREPARED 상태가 됩니다.
- 각 검증자는 다음 조건이 포함된 PRE-PREPARE 메시지를 수신하면 PRE-PREPARED 상태로 들어갑니다:
  - 블록 제안이 유효한 제안자로부터 온 것입니다.
  - 블록 헤더가 유효합니다.
  - 블록 제안의 순서와 라운드가 검증자의 상태와 일치합니다.
- 검증자가 다른 검증자에게 PREPARE 메시지를 브로드캐스트합니다.
PRE-PREPARED → PREPARED:
- 검증자는 2F + 1의 유효한 PREPARE 메시지를 수신하여 PREPARED 상태로 진입합니다. 유효한 메시지는 다음 조건을 준수합니다:
  - 시퀀스 및 라운드가 일치합니다.
  - 블록 해시가 일치합니다.
  - 알려진 검증자가 보낸 메시지입니다.
- 검증자는 PREPARED 상태에 진입하면 COMMIT 메시지를 브로드캐스트합니다.
PREPARED → COMMITTED:
- 검증자는 2F + 1의 유효한 COMMIT 메시지를 수신하여 COMMITTED 상태로 진입합니다. 유효한 메시지는 다음 조건을 만족해야 합니다:
  - 시퀀스 및 라운드가 일치합니다.
  - 블록 해시가 일치합니다.
  - 알려진 검증자가 보낸 메시지입니다.
COMMITTED → FINAL COMMITTED:
- 검증자가 extraData에 2F + 1 커밋 서명을 추가하고 블록을 블록체인에 삽입하려고 시도합니다.
- 삽입에 성공하면 검증자는 FINAL COMMITTED 상태가 됩니다.
FINAL COMMITTED → NEW ROUND:
- 검증자는 새로운 제안자를 선택하고 새로운 라운드 타이머를 시작합니다.

Round change 흐름

ROUND CHANGE를 트리거하는 세 가지 조건이 있습니다:
- 라운드 변경 타이머가 만료되었습니다.
- 잘못된 PRE-PREPARED 메시지.
- 블록 삽입 실패.
위 조건 중 하나가 적용되면 검증자는 제안된 라운드 번호와 함께 ROUND CHANGE 메시지를 브로드캐스트하고 다른 검증자의 ROUND CHANGE 메시지를 기다립니다. 제안된 라운드 번호는 다음 조건에 따라 선택됩니다:
- 검증자가 동료로부터 ROUND CHANGE 메시지를 수신한 경우, ROUND CHANGE 메시지의 F + 1이 있는 가장 큰 라운드 번호를 선택합니다.
- 그렇지 않으면 1 + 현재 라운드 번호를 제안된 라운드 번호로 선택합니다.
검증자는 된 라운드 번호와 동일한 라운드 번호에 대해 F + 1 개의 ROUND CHANGE 메시지를 수신할 때마다 수신된 메시지를 자신의 라운드 번호와 비교합니다. 수신된 숫자가 더 크면 검증자는 수신된 숫자로 다시 ROUND CHANGE메시지를 브로드캐스트합니다.
동일한 제안 라운드 번호에 대해 2F + 1의 ROUND CHANGE 메시지를 수신하면 검증자는 라운드 변경 루프를 종료하고 새 제안자를 계산한 다음 NEW ROUND 상태로 들어갑니다.
검증자가 라운드 변경 루프에서 벗어나는 또 다른 조건은 피어 동기화를 통해 검증된 블록을 수신할 때입니다.

Proposer 선정

현재 저희는 라운드 로빈과 고정 제안자의 두 가지 정책을 지원합니다.

라운드 로빈: 라운드 로빈 설정에서는 블록과 라운드가 변경될 때마다 제안자가 변경됩니다.
고정 제안자(Sticky proposer): 고정 제안자 설정에서는 라운드 변경이 발생할 때만 제안자가 변경됩니다.

검증자 목록 투표

저희는 Clique와 유사한 검증인 투표 메커니즘을 사용하며, 대부분의 콘텐츠를 Clique EIP에서 복사합니다. 모든 에포크 트랜잭션은 검증인 투표를 재설정하므로, 승인 또는 승인 취소 투표가 진행 중일 경우 해당 투표 프로세스가 종료됩니다.

모든 트랜잭션 블록에 적용됩니다:

제안자는 검증자 목록에 변경을 제안하기 위해 한 번의 투표를 할 수 있습니다.
단일 검증인으로부터 대상 수혜자당 최신 제안만 보관됩니다.
투표는 체인이 진행됨에 따라 실시간으로 집계됩니다(동시 제안 허용).
과반수 합의에 도달한 제안 VALIDATOR_LIMIT는 즉시 적용됩니다.
유효하지 않은 제안은 클라이언트 구현의 단순성을 위해 불이익을 받지 않습니다.
제안이 발효되면 해당 제안에 대해 보류 중인 모든 투표(찬성 및 반대 모두)가 폐기되며, 새로운 제안은 백지 상태에서 시작됩니다.

future message 및 backlog

비동기 네트워크 환경에서는 현재 상태에서 처리할 수 없는 미래의 메시지를 수신할 수 있습니다. 예를 들어, 검증자는 NEW ROUND에서 COMMIT 메시지를 수신할 수 있습니다. 우리는 이런 종류의 메시지를 "future message"라고 부릅니다. 검증자는 future message를 수신하면 해당 메시지를 backlog에 넣고 가능한 한 나중에 처리하려고 시도합니다.

최적화

합의 프로세스의 속도를 높이기 위해, 2F + 1의 COMMIT 메시지를 수신하기 전에 2F + 1의 PREPARE 메시지를 수신한 검증자는 추가 PREPARE 메시지를 기다릴 필요가 없도록 COMMITTED 상태로 이동합니다.

상수

다음 상수를 정의합니다:

EPOCH_LENGTH: 보류 중인 투표를 체크포인트하고 리셋할 블록 수입니다.
- 테스트넷이 메인넷 이더리움 에포크와 유사하게 유지되도록 30000을 제안했습니다.
REQUEST_TIMEOUT: 라운드 변경을 실행하기 전 각 합의 라운드의 시간 제한(밀리초).
BLOCK_PERIOD: 연속된 두 블록 사이의 최소 타임스탬프 차이(초).
PROPOSER_POLICY: 제안자 선택 정책, 기본값은 라운드 로빈입니다.
ISTANBUL_DIGEST: 이스탄불 블록 식별을 위해 블록 헤더의 mixDigest에 매직넘버 0x63746963616c2062797a616e74696e65206661756c7420746f6c6572616e6365를 수정했습니다.
DEFAULT_DIFFICULTY: 0x0000000000000001로 설정된 기본 블록 난이도입니다.
EXTRA_VANITY: 제안자 베니티를 위해 예약된 추가 데이터 접두사 바이트 수를 수정했습니다.
- 현재 추가 데이터 허용량 및/또는 사용을 유지하기 위해 32 bytes를 제안했습니다.
NONCE_AUTH: 검증자 추가에 투표하기 위한 매직 논스 번호 0xffffffffffffffff.
NONCE_DROP: 검증자 제거에 투표하기 위한 매직 논스 번호 0x0000000000000000입니다.
UNCLE_HASH: uncle은 PoW 외에는 의미가 없으므로 항상 Keccak256(RLP([]))을 사용합니다.
PREPREPARE_MSG_CODE: Fixed number 0. PREPARE 메시지의 메시지 코드입니다.
COMMIT_MSG_CODE: Fixed number 1. COMMIT 메시지의 메시지 코드입니다.
ROUND_CHANGE_MSG_CODE: Fixed number 2. ROUND CHANGE 메세지의 메시지 코드 입니다.

또한 다음과 같은 블록별 상수도 정의합니다:

BLOCK_NUMBER: 체인 내 블록 높이, 여기서 제네시스 블록의 높이는 0입니다.
N: 승인된 검증자 수입니다.
F: 허용된 결함 검증자 수입니다.
VALIDATOR_INDEX: 현재 승인된 검증자의 정렬된 목록에서 블록 검증자의 인덱스입니다.
VALIDATOR_LIMIT: 승인 또는 승인 취소 제안을 통과할 검증자 수입니다.
- 체인에서 과반수 합의를 적용하려면 floor(N/2) + 1이어야 합니다.

블록 헤더

저희는 이스탄불 BFT를 위한 새로운 블록 헤더를 개발하지 않았습니다. 대신, 저희는 Clique를 따라 ethash 헤더 필드의 용도를 다음과 같이 변경했습니다:

beneficiary: 검증자 목록 수정을 제안할 주소입니다.
- 평소에는 0으로 채워야 하며, 투표하는 동안에만 수정할 수 있습니다.
- 그럼에도 불구하고 투표 메커니즘 구현의 복잡성을 피하기 위해 임의의 값(비 검증자를 투표하는 것과 같은 무의미한 값도 허용됩니다)을 사용할 수 있습니다.
nonce: 수혜자 필드에 정의된 계정에 대한 제안자 제안.
- 기존 검증자로서의 수취인 승인 취소를 제안하려면 NONCE_DROP이어야 합니다.
- 수취인을 새 검증자로 승인할 것을 제안하려면 NONCE_AUTH이어야 합니다.
- 0, NONCE_DROP 또는 NONCE_AUTH로 채워야 합니다.
mixHash: 이스탄불 블록 식별을 위한 Fixed magic number 0x63746963616c2062797a616e74696e65206661756c7420746f6c6572616e6365.
ommerHash: uncle은 PoW 외부에서는 의미가 없으므로 UNCLE_HASH여야 합니다.
timestamp: 최소한 부모 타임스탬프 + BLOCK_PERIOD이어야 합니다.
difficulty: 0x0000000000000001로 채워야 합니다.
extraData: 서명자 베니티와 RLP 인코딩된 이스탄불 추가 데이터를 위한 결합 필드이며, 이스탄불 추가 데이터에는 검증자 목록, 제안자 씰, 커밋 씰이 포함됩니다. 이스탄불 추가 데이터는 다음과 같이 정의됩니다:따라서 extraData는 EXTRA_VANITY | ISTANBUL_EXTRA의 형식이 되며, 여기서 |는 베니티와 이스탄불 extraData를 구분하는 고정 인덱스(실제 구분 문자가 아님)를 나타냅니다.
- 첫 번째 EXTRA_VANITY 바이트(fixed)에는 임의의 제안자 베니티 데이터가 포함될 수 있습니다.
- ISTANBUL_EXTRA 바이트는 RLP(IstanbulExtra)로부터 계산된 이스탄불 추가 데이터로, 여기서 RLP()는 RLP 인코딩 함수이고 IstanbulExtra는 이스탄불 엑스트라 데이터입니다.
  - Validators: 검증자 목록으로, 오름차순으로 정렬해야 합니다.
  - Seal: 헤더에 대한 제안자의 서명 씰링입니다.
  - CommittedSeal: 합의 증명을 위한 commitment 서명 씰 목록입니다.
type IstanbulExtra struct { Validators []common.Address //Validator addresses Seal []byte //Proposer seal 65 bytes CommittedSeal [][]byte //Committed seal, 65 * len(Validators) bytes }

Block hash, proposer seal, and committed seals

이스탄불 블록 해시 계산은 다음과 같은 이유로 인해 ethash 블록 해시 계산과 다릅니다:

제안자는 블록이 선택된 제안자에 의해 서명되었음을 증명하기 위해 제안자 씰을 extraData에 넣어야 합니다.
검증자는 블록이 합의를 거쳤음을 증명하기 위해 합의 증명으로 2F + 1의 committed seal을 extraData 에 넣어야 합니다.

계산은 여전히 ethash 블록 해시 계산과 유사하지만, extraData를 처리해야 한다는 점이 다릅니다. 다음과 같이 필드를 계산합니다:

Proposal seal calculation

Proposal seal 계산 시점에 committed seal은 아직 알 수 없으므로, 알 수 없는 seal을 비운 상태로 seal을 계산합니다. 계산은 다음과 같습니다:

Proposer seal: SignECDSA(Keccak256(RLP(헤더)), PrivateKey)
PrivateKey: 제안자의 개인 키.
Header: ethash 헤더와 동일하지만 extraData가 다릅니다.
extraData: vanity | RLP(IstanbulExtra), 여기 IstanbulExtra에서 CommittedSeal과 Seal은 빈 배열입니다.

Block hash calculation

블록 해시를 계산할 때, committed seal은 서로 다른 검증자 간에 동적이기 때문에 제외해야 합니다. 따라서 해시를 계산하는 동안 CommittedSeal을 빈 배열로 만듭니다. 계산은 다음과 같습니다:

Header: ethash 헤더와 동일하지만 extraData가 다릅니다.
extraData: vanity | RLP(IstanbulExtra), 여기 IstanbulExtra에서 CommittedSeal과 Seal은 빈 배열입니다.

Consensus proof

블록체인에 블록을 삽입하기 전에 각 검증자는 합의 증명을 구성하기 위해 다른 검증자로부터 2F + 1의 committed seal을 수집해야 합니다. 충분한 committed seal을 받으면 IstanbulExtra에 CommittedSeal을 채우고 extraData를 다시 계산한 다음 블록을 블록체인에 삽입합니다. committed seal은 소스마다 다를 수 있으므로 이전 섹션에서와 같이 블록 해시를 계산할 때 해당 부분을 제외합니다.

Committed seal calculation

커밋된 씰은 각 검증자가 개인 키의 COMMIT_MSG_CODE 메시지 코드와 함께 해시에 서명함으로써 계산됩니다. 계산은 다음과 같습니다:

Committed seal: SignECDSA(Keccak256(CONCAT(Hash, COMMIT_MSG_CODE)), PrivateKey).
CONCAT(Hash, COMMIT_MSG_CODE): 블록 해시 및 COMMIT_MSG_CODE 바이트를 연결합니다.
PrivateKey: 검증자의 개인 키입니다.

Block locking mechanism

Safety 문제를 해결하기 위해 잠금 메커니즘이 도입되었습니다. 일반적으로 제안자가 블록 B로 특정 높이 H에서 잠기면 높이 H에 대해 B만 제안할 수 있고, 반대로 검증자가 잠기면 높이 H에 대해 B에만 투표할 수 있습니다.

Lock

Lock(B, H)은 블록과 블록의 높이를 포함하며, 이는 해당 블록에 속한 검증자가 현재 특정 블록 B와 높이 H에 잠겨 있음을 의미합니다. 아래에서는 +를 사용하여 보다 많음을 나타내고 -를 사용하여 보다 적음을 나타내기도 합니다. 예를 들어 +2/3 검증인은 검증인의 3분의 2 이상을 나타내고, -1/3 검증인은 검증인의 3분의 1 미만을 나타냅니다.

Lock and unlock

Lock: 검증자는 높이 H의 블록 B에서 2F + 1 PREPARE 메시지를 수신하면 잠깁니다.
Unlock: 블록 B를 블록체인에 삽입하지 못하면 검증자는 높이 H와 블록 B에서 잠금이 해제됩니다.

Protocol (+2/3 validators are locked with Lock(B,H))

PRE-PREPARE:
- Proposer:
  - 케이스 1, 제안자가 잠겨 있습니다: B에서 PRE-PREPARE를 브로드캐스트하고 PREPARED 상태로 들어갑니다.
  - 케이스 2, 제안자가 잠기지 않은 경우: 블록 B'에서 PRE-PREPARE를 브로드캐스트합니다.
- Validator:
  - 케이스 1, 기존 블록에서 PRE-PREPARE 수신: 무시.
    - 참고: 결국 라운드 변경으로 이어지며 제안자는 동기화를 통해 이전 블록을 받게 됩니다.
  - 케이스 2, 검증자가 잠긴 경우:
    - 케이스 2.1, B에서 PRE-PREPARE 수신: B에 PREPARE를 브로드캐스트합니다.
    - 케이스 2.2, B'에서 PRE-PREPARE수신: ROUND CHANGE 를 브로드캐스트합니다.
  - 케이스 3, 검증자가 잠기지 않음:
    - 케이스 3.1, B에서 PRE-PREPARE를 수신한 경우: B에서 PREPARE를 브로드캐스트합니다.
    - 케이스 3.2, B'에서 PRE-PREPARE를 수신: B'에서 PREPARE를 브로드캐스트합니다.
      - 참고: 이 합의 라운드는 +2/3이 B에 고정되어 라운드 변경으로 이어지기 때문에 결국 라운드 변경에 들어가게 됩니다.
PREPARE:
- 케이스 1, 검증자가 잠겨 있음:
  - 케이스 1.1, B에서 PREPARE 수신: B에서 COMMIT을 브로드캐스트하고 PREPARED 상태로 들어갑니다.
    - 참고: 이런 일이 발생하지 않아야 하며, 이 단계를 건너뛰고 PRE-PREPARE 단계에서 PREPARED로 진입해야 합니다.
  - 케이스 1.2, B'에서 PREPARE를 수신했습니다: 무시합니다.
    - 참고: +2/3이 B에 잠겨 있기 때문에 B'에 +1/3의 PREPARE가 있어서는 안됩니다. 따라서 B'의 합의 라운드가 라운드 변경을 유발합니다. 이 PREPARE 메시지는 결함이 있는 노드에서 발생할 수 있으므로 검증자는 여기서 직접 ROUND CHANGE 를 브로드캐스트할 수 없습니다.
- 케이스 2, 검증자가 잠기지 않음:
  - 케이스 2.1, B에서 PREPARE 수신: B에서 2F + 1 PREPARE 메시지를 기다립니다.
    - 참고: B에 +2/3의 검증자가 잠겨 있기 때문에 2F + 1 COMMIT 메시지를 수신하기 전에 2F + 1 PREPARE 메시지를 수신할 가능성이 높으며, 이 경우 바로 COMMITTED 상태로 이동합니다.
  - 케이스 2.2, B'에서 PREPARE를 수신한 경우: B'에서 2F + 1 PREPARE 메시지를 기다립니다.
    - 참고: +2/3 검증자가 B에 잠겨 있기 때문에 이 합의는 결국 라운드 변경으로 이어질 것입니다.
COMMIT:
- 검증자는 잠겨 있어야 합니다:
  - 케이스 1, B에서 COMMIT 수신: 2F + 1 COMMIT 메시지를 기다립니다.
  - 케이스 2, B'에서 COMMIT 수신: 일어나지 않아야 합니다.

Locking cases

라운드 변경:
- 케이스 1, +2/3은 잠겨 있습니다:
  - 제안자가 잠겨 있으면 B를 제안합니다.
  - 그렇지 않으면 B'를 제안하지만 또 다른 라운드 변경으로 이어집니다.
  - 결론: 결국 정직한 검증자가 B를 커밋할 것입니다.
- 케이스 2, +1/3 ~ 2/3은 잠겨 있습니다:
  - 제안자가 잠겨 있으면 B를 제안합니다.
  - 그렇지 않으면 B'를 제안합니다. 그러나 +1/3이 B에 잠겨 있기 때문에 어떤 검증인도 B'에서 2F + 1 PREPARE를 받을 수 없으며, 이는 어떤 검증인도 B'에 잠길 수 없음을 의미합니다. 또한 +1/3으로 잠긴 검증자는 B'에 응답하지 않고 결국 라운드 변경으로 이어집니다.
  - 결론: 결국 B는 정직한 검증자에 의해 커밋될 것입니다.
- 케이스 3, -1/3이 잠겼습니다:
  - 제안이 잠겨 있으면 B를 제안합니다.
  - 그렇지 않으면 B'를 제안합니다. 2/3가 B'에 대한 합의에 도달하면, 잠긴 -1/3는 동기화를 통해 B'를 얻고 다음 높이로 이동합니다. 그렇지 않으면 또 다른 라운드 변경이 있을 것입니다.
  - 결론: B가 될 수도 있고 다른 블록 B' 가 최종적으로 커밋될 수도 있습니다.
삽입 실패로 인한 라운드 변경:
- 위의 라운드 변경 사례 중 하나에 해당합니다.
  - 블록이 실제로 불량(블록체인에 삽입할 수 없음)인 경우, 결국 +2/3 검증자는 H에서 블록 B의 잠금을 해제하고 새로운 블록 B'를 제안하려고 시도할 것입니다.
  - 블록이 양호한 경우(블록체인에 삽입될 수 있는 경우)에도 위의 라운드 변경 사례 중 하나에 해당합니다.
-1/3 검증자는 블록을 성공적으로 삽입하지만 다른 검증자는 라운드 변경을 성공적으로 트리거하여 +1/3이 여전히 Lock(B,H)에 잠겨 있습니다.
- 케이스 1, 제안자가 B를 삽입한 경우: 제안자는 H'에서 B'를 제안하지만 +1/3이 B에 잠겨 있으므로 B'는 합의를 통과하지 못하고 결국 라운드 변경으로 이어집니다. 다른 검증자는 B에 대한 합의를 수행하거나 동기화를 통해 B를 얻습니다.
- 케이스 2, 제안자가 B를 삽입하지 않은 경우:
  - 케이스 2.1, 제안자가 잠긴 경우: 제안자가 B를 제안합니다.
  - 케이스 2.2, 제안자가 잠기지 않은 경우: 제안자가 H에서 B'를 제안합니다. 나머지는 위의 케이스 1과 동일합니다.
검증자 +1/3이 블록을 성공적으로 삽입하고, 검증자 -2/3이 H에서 라운드 변경을 트리거하려고 합니다.
- 케이스 1, 제안자가 B를 삽입한 경우: 제안자는 H'에서 B'를 제안하지만, 동기화를 통해 +1/3이 B를 얻을 때까지 합의를 통과하지 못합니다.
- 케이스 2, 제안자가 B를 삽입하지 않은 경우:
  - 케이스 2.1, 제안자가 잠긴 경우: 제안자가 B를 제안합니다.
  - 케이스 2.2, 제안자가 잠기지 않은 경우: 제안자가 H에 B'를 제안하고 나머지는 위의 케이스 1과 동일합니다.
+2/3의 검증자가 블록을 성공적으로 삽입하고, -1/3은 H에서 라운드 변경을 트리거하려고 합니다.
- 케이스 1, 제안자가 B를 삽입한 경우: 제안자는 H'에서 B'를 제안할 것이며, 이는 성공적인 합의로 이어질 수 있습니다. 그런 다음 -1/3은 동기화를 통해 B를 가져와야 합니다.
- 케이스 2, 제안자가 B를 삽입하지 않은 경우:
  - 케이스 2.1, 제안자가 잠긴 경우: 제안자가 B를 제안합니다.
  - 케이스 2.2, 제안자가 잠기지 않은 경우: 제안자가 H에서 B'를 제안합니다. +2/3가 이미 H에 B를 가지고 있으므로 이번 라운드에서는 라운드 변경이 발생합니다.

Gossip network

기존에는 안정적인 합의 결과에 도달하기 위해 검증자들이 강력하게 연결되어야 하는데, 이는 모든 검증자들이 서로 직접 연결되어야 한다는 것을 의미하지만 실제 네트워크 환경에서는 안정적이고 지속적인 P2P 연결을 달성하기 어렵습니다. 이스탄불 BFT는 이러한 제약을 극복하기 위해 가십 네트워크를 구현하여 이러한 문제를 해결합니다. 가십 네트워크 환경에서는 모든 검증인이 약하게만 연결되면 되는데, 이는 두 검증인이 직접 연결되거나 중간에 하나 이상의 검증인과 연결될 때 두 검증인이 연결된 것으로 간주된다는 의미입니다. 합의 메시지는 검증자 간에 전달됩니다.

'분산 컴퓨팅 이론' 카테고리의 다른 글

[번역] There is No Now (0)	2023.04.27
NAT-PMP 에러 처리 (0)	2023.04.22

유승배

[번역] Istanbul Byzantine Fault Tolerance (EIP-650)

Istanbul Byzantine Fault Tolerance

용어