Polkadot 합의 GRANDPA 계약을 이해하기 위한 기사
PolkaBase
2020-08-07 13:25
本文约2937字,阅读全文需要约12分钟
이것은 Polkadot Consensus 시리즈의 2부입니다. 소개는 파트 1을 참조하십시오. 이 시리즈 소개에서는 컴퓨터 네트워크가 세 가지 질문에 답하는 데 도움이 되는 합의 알고리즘에 대해 설명합니다.

이것은 Polkadot Consensus 시리즈의 2부입니다.

이 시리즈 소개에서는 컴퓨터 네트워크가 세 가지 질문에 답하는 데 도움이 되는 합의 알고리즘에 대해 설명합니다. GRANDPA는 두 번째 문제를 해결할 것입니다.

1. 누가 다음 변화를 제안할 수 있습니까?

2. 최종 변경점은 어떤 세트인가요?

3. 누군가가 규칙을 어기면 어떻게 합니까?

GRANDPA는 Polkadot의 최종 도구이며, 그 역할은 모델 체인을 올바르게 선택하여 GRANDPA에 대한 일련의 변경이 최종 단계임을 나타냅니다. GRANDPA는 자체적으로 블록을 생성하지 않고 대신 GRANDPA 유효성 검사기는 다른 블록 생성 구성 요소에서 블록을 가져옵니다(3부에서 논의함).

보조 제목

할아버지 계약

GRANDPA는 검증자가 블록이 아닌 체인에 투표한다는 점에서 다른 BFT(Byzantine Fault Tolerant) 블록체인 알고리즘과 다릅니다. 프로토콜은 전환 투표 메커니즘을 채택하고 GRANDPA 알고리즘은 최종 투표로 간주될 가장 높은 투표 수를 가진 블록 번호를 찾습니다. 이 프로세스를 통해 여러 블록이 동시에 발생할 수 있습니다.

마지막 부분은 GRANDPA가 다른 블록체인 종료 도구를 방해하는 병목 현상을 제거하기 때문에 중요합니다. Practical Byzantine Fault Tolerance의 다른 PBFT 파생물과 마찬가지로 GRANDPA에는 O(n²) 복잡성이 있습니다. 즉, 노드 수를 두 배로 늘리면 메시지 수의 네 배를 보내야 합니다. 블록 생성을 결정론적 프로세스의 일부로 만드는 합의 시스템을 통해 이러한 메시지를 각 블록에 보낼 수 있습니다. 다른 모듈에서 블록 생성을 분리함으로써 보다 효율적인 방식으로 블록을 생성하고(BABE의 경우 O(n)) 한 번의 투표로 여러 블록을 마무리할 수 있습니다.

이 예를 이해하려면 Kusama 노드의 다음 로그 메시지를 살펴보십시오.

Idle (24 peers), best: #664257 (0x706c…76b7), finalized #664253 (0xe4ab…4d2a)

Imported #664258 (0xee71…6321)

Idle (24 peers), best: #664258 (0xee71…6321), finalized #664256 (0x809a…a5d8)

한 라운드에서 GRANDPA는 3개의 블록(664,254에서 664,246)을 확정했습니다.

보조 제목

할아버지 라운드

유권자는 새 블록을 생성하기 위해 다음을 수행합니다.

1. "기본"으로 지정된 노드는 이전에 획득했다고 생각되는 가장 높은 투표를 받은 블록을 최종 블록으로 방송합니다.

2. 네트워크 지연을 기다린 후 각 유효성 검사기는 완료되고 최종으로 간주되어야 한다고 생각하는 가장 높은 투표를 받은 블록에 대한 "사전 투표"를 브로드캐스트합니다. 대부분의 유효성 검사기가 정직한 경우 이 블록은 원래 브로드캐스트 체인을 확장해야 합니다. 따라서 새 체인은 최종 체인보다 몇 블록 더 길 수 있습니다.

3. 각 검증자는 사전 투표 계산에 따라 가장 높은 표를 얻은 최종 블록을 결정할 수 있습니다. 사전 투표 세트가 마지막 최종 체인으로 확장되면 각 유효성 검사기는 해당 체인을 "사전 실행"합니다.

4. 각 유효성 검사기는 새로 결정된 체인에 대한 정보를 제공하기 위해 충분한 사전 실행을 받을 때까지 기다립니다.

PBFT 및 Hotstuff와 같은 다른 Byzantine Fault Tolerant 알고리즘과 미묘하지만 중요한 차이점은 이 투표 라운드의 주요 경로에 대한 의견 변경이 없다는 것입니다. 각 라운드의 주요 내용이 변경되더라도 이 변경은 비동기 네트워크에서 새로운 라운드를 시작할 뿐이므로 부분 동기 네트워크에서는 메인 랜드가 할당되지 않더라도 프로토콜은 항상 앞으로 나아갈 것입니다.

검증인의 사전 투표 또는 사전 실행이 프로토콜 프로세스에서 3분의 2 이상 획득되면 프로세스가 완료될 수 있음을 나타냅니다. 최종성을 달성하려면 검증자가 최종성을 설정하는 무한한 체인과 달리 검증자의 손에 있는 투표 수를 제한해야 합니다. 투표자 집합을 선택하는 방법은 GRANDPA 프로토콜 외부에서 정의된 논리입니다(섹션 4 참조).

보조 제목

안전 책임: 사고 발생 시

GRANDPA에는 검증자가 보안 위반에 대해 책임을 지게 하는 보안 책임이라는 기능이 있습니다. 서로 다른 체인의 두 블록이 결정될 때 보안 충돌이 발생하면 보안 책임 기능은 사고 후 조사와 유사합니다.

그러나 먼저 충돌하는 두 사슬이 어떻게 형성되는지가 명확합니까? BFT 시스템은 항상 해당 유효성 검사기의 최대 수가 전체 유효성 검사기의 작은 부분(이 경우 1/3)이라는 조건을 기반으로 구축됩니다. 검증자 세트가 위의 요구 사항을 충족하지 못하는 경우 검증자 중 최소 1/3이 충돌하는 두 체인을 최종적으로 청산하기 위해 두 체인에 투표합니다.

이 예에는 10개의 유효성 검사기가 있습니다. 즉, 3개는 시스템이 허용할 수 있는 최대 거짓 유효성 검사기 수입니다(f = (10-1)/3). 4개의 불량 유효성 검사기(빨간색)와 네트워크 파티션이 있는 정직한 유효성 검사기(파란색)의 각 세트는 각각의 최종 블록을 가질 수 있습니다.

두 개의 상충하는 체인에 투표하는 것은 모호한 행위입니다. 사실 모든 사람들은 모호성이 BFT 시스템에 대한 공격이라고 생각하지만 GRANDPA에서는 이러한 동작을 감지할 수 있습니다.

먼저 노드가 이전 블록을 고려하지 않고 새 블록에 투표한 이유를 묻습니다. 정직한 검증자는 이 질문에 답하기 위해 두 번째 사전 투표 또는 사전 실행을 활성화해야 합니다. 두 번째 블록이 항상 다수의 표를 가지기 때문입니다.

첫 번째 질문이 사실이면 두 번째 질문을 합니다. 첫 번째 라운드에서 어떤 투표지를 보았습니까? 우리는 본질적으로 그들에게 다른 검증자를 승인하고 동료로부터 받은 모든 표를 공개하도록 요청하고 있습니다. 이 두 세트의 합집합 어딘가에서 충돌하는 두 체인에 투표한 유효성 검사기를 찾을 수 있습니다. 위의 결과가 확인되면 혹독한 페널티를 받게 되는데 이는 합의가 아닌 온체인 로직 작업의 결과일 뿐입니다.

보조 제목

GRANDPA가 유용성과 효율성을 달성하는 방법

위의 로그 메시지를 기억하십니까? 최종 블록은 최상의 블록 다음의 두 번째 블록입니다. 이 지연은 실제로 블록 생산과 완료를 다르게 유지하는 데 이점이 있습니다.

Idle (24 peers), best: #664258 (0xee71…6321), finalized #664256 (0x809a…a5d8)

Polkadot을 포함한 블록체인 상호 운용성 시스템은 데이터 가용성에 문제가 있습니다. 협력자가 검증자에게 블록을 커밋하지만 다른 파라체인 협력자는 이를 볼 수 없다고 상상해 보십시오. 블록 정보를 제출한 수집가가 오프라인 상태가 되면 어떻게 되나요? 검증자는 모든 파라체인 수집가가 블록 정보를 얻을 수 있도록 일정 기간 동안 완전한 블록 정보를 저장하는 데 도움을 줄 책임이 있습니다.

유효성 검사기는 투표하기 전에 블록 후보를 검증해야 하지만 우리는 그들이 그렇게 하도록 하고 싶습니다. Polkadot에는 릴레이 체인에서 유효하지 않은 파라체인을 지적하는 것과 같이 블록을 검증하고 검증자의 오작동을 보고할 수 있는 피셔로 알려진 많은 노드가 있습니다.

우리는 최종적으로 선택된 블록이 유효하지 않은 블록이나 결합자가 재구성할 수 없는 블록이 되는 것을 결코 원하지 않습니다. 체인 끝 뒤에 있는 여러 블록의 검증 가능성을 유지함으로써 피셔가 블록이 올바른지 확인하고 검증자가 성실한지 확인할 수 있습니다.

원본 링크:

원본 링크:https://polkadot.network/polkadot-consensus-part-2-grandpa/

번역 / 마이크

편집 / 돌리

PolkaBase
作者文库