컨센서스 프로토콜

1.개요

EOS 블록체인은 분산된 방식으로 작동할 수 있는 매우 효율적이고 결정론적인 분산 상태 시스템입니다.블록체인은 서로 교환된 일련의 블록 내에서 트랜잭션을 추적합니다.각 블록은 동일한 체인의 이전 블록에 암호학적으로 커밋됩니다.따라서 연속되는 블록의 암호화 검사를 중단하지 않고 주어진 블록에 기록된 트랜잭션을 수정하는 것은 어렵습니다.이 단순한 사실은 블록체인 거래를 불변하고 안전하게 만듭니다.

1.1.블록 프로듀서

EOS 생태계에서 블록 생산과 블록 검증은 “블록 생산자”라는 특수 노드에 의해 수행됩니다.생산자는 EOS 이해 관계자에 의해 선출됩니다 (참조). 4.프로듀서 투표/일정).각 생산자는 다음을 통해 EOS 노드의 인스턴스를 실행합니다. nodeos 서비스.이러한 이유로 블록 생산 일정에 따라 활동하는 생산자를 “활성” 또는 “생산” 노드라고도 합니다.

1.2.합의의 필요성

블록 검증은 모든 분산 노드 그룹에서 문제를 야기합니다.분산형 시스템 내에서 내결함성 방식으로 이러한 블록을 검증할 수 있는 합의 모델이 마련되어야 합니다.합의는 이러한 분산 노드와 사용자가 블록체인의 현재 상태에 동의하는 방법입니다 (참조). 3.EOS 컨센서스 (DPoS + Baft)).

2.컨센서스 모델

분산된 시스템에서 분산된 당사자 그룹 간에 합의에 도달하는 방법에는 여러 가지가 있습니다.대부분의 합의 모델은 몇 가지 증명을 통해 합의에 도달합니다.가장 인기 있는 두 가지는 작업 증명 (PoW) 과 지분 증명 (PoS) 이지만, 활동 증명 (PoW와 PoS 간의 하이브리드), 소각 증명, 용량 증명, 경과 시간 증명 등과 같은 다른 유형의 증명 기반 체계도 존재하지만 Paxos와 Raft와 같은 다른 합의 체계도 있습니다.이 문서는 주로 EOS 합의 모델에 초점을 맞춥니다.

2.1.작업 증명 (PoW)

블록체인에서 가장 일반적으로 사용되는 두 가지 합의 모델은 작업 증명과 지분 증명입니다.작업 증명 (Proof of Work) 에서 마이너 노드는 블록 헤더에 추가된 논스를 찾기 위해 경쟁합니다. 이렇게 하면 블록이 원하는 속성 (일반적으로 블록 헤더의 암호화 해시에서 가장 중요한 비트에 특정 개수의 0이 표시됨) 이 생깁니다.블록의 유효성을 높여주는 엉터리를 찾는 데 컴퓨팅 비용이 많이 들기 때문에 공격자들은 네트워크의 나머지 사람들이 최상의 체인으로 받아들일 수 있는 블록체인의 대체 포크를 만들기가 어려워진다.Proof of Work의 가장 큰 단점은 네트워크 보안이 컴퓨팅 성능에 많은 리소스를 소비하는 데 달려 있다는 것입니다.

2.2.지분증명 (PoS)

지분 증명에서 가장 큰 지분 또는 일부 자산의 비율을 소유한 노드는 동등한 결정 권한을 갖습니다.즉, 투표권은 보유한 지분에 비례합니다.한 가지 흥미로운 변형은 DPO (위임된 지분증명) 입니다. 이 방식에서는 많은 참여자 또는 이해관계자가 소수의 대표자를 선출하고, 이들이 대신 결정을 내립니다.

3.EOS 컨센서스 (DPoS + Baft)

EOS 블록체인은 위임된 지분증명 (DPO) 을 사용하여 네트워크에서 유효한 블록에 서명할 권한이 있는 활성 생산자를 선출합니다.그러나 이는 EOS 합의 프로세스의 절반에 불과합니다.나머지 절반은 비동기식 비잔틴 장애 허용 (aBFT) 방식으로 수행되는 최종 (되돌릴 수 없음) 이 될 때까지 각 블록을 확인하는 실제 프로세스에 참여합니다.따라서 EOS 합의 모델에는 두 가지 계층이 포함됩니다.

• 레이어 1 - 네이티브 컨센서스 모델 (AbFT).
• 레이어 2 - 위임 지분 증명 (DPO).

EOS에서 사용되는 실제 네이티브 컨센서스 모델에는 위임/투표, 지분 또는 토큰이라는 개념이 없습니다.이는 DPoS 계층에서 블록 생산자의 첫 번째 일정을 생성하는 데 사용되며, 해당하는 경우 각 생산자가 순환한 후 기껏해야 매 일정 라운드마다 세트를 업데이트합니다.이 두 계층은 EOS 소프트웨어에서 기능적으로 분리되어 있습니다.

3.1.레이어 1: 네이티브 컨센서스 (BaFT)

이 계층은 궁극적으로 선출된 생산자들 사이에서 수신되고 동기화된 블록이 최종적으로 최종 결정되어 블록체인에 영구적으로 기록되는지를 결정합니다.두 번째 레이어에서 제안한 생산자 일정을 가져옵니다 (참조). 3.2.레이어 2: 위임된 PO) 그리고 이 스케줄을 사용하여 적절한 제작자가 어떤 블록에 올바르게 서명했는지 결정합니다.비잔틴 내결함성을 위해 이 계층은 현재 예정된 세트의 생산자 중 3분의 2 과반수가 각 블록을 두 번 확인하는 2단계 블록 확인 프로세스를 사용합니다.첫 번째 확인 단계에서는 마지막 돌이킬 수 없는 블록 (LIB) 을 제안합니다.두 번째 단계에서는 제안된 LIB를 최종으로 확인합니다.이 시점에서 블록은 되돌릴 수 없게 됩니다.또한 이 레이어는 모든 스케줄 라운드가 시작될 때 프로듀서 스케줄 변경 (있는 경우) 을 알리는 데 사용됩니다.

3.1.1.EOS 알고리즘 완결성

EOS 합의 모델은 특정 시간대에 블록에 서명할 권한이 있는 당사자를 결정하는 일정에 따라 선택된 특별 참여자 (활성 생산자) 집단의 서명을 통해 알고리즘적 최종성 (작업 증명 모델에서는 기껏해야 달성할 수 있는 단순한 확률론적 최종성과는 다름) 을 달성합니다.이 일정에 대한 변경은 EOS 블록체인에서 실행되는 특권 스마트 계약에 의해 시작될 수 있지만, 일정에 대한 모든 초기 변경 사항은 일정 변경을 시작한 블록이 두 단계의 확인을 거쳐 확정되기 전까지는 적용되지 않습니다.각 확인 단계는 현재 예정된 활성 프로듀서 세트의 대다수의 프로듀서가 수행합니다.

3.2.계층 2: 위임된 주문서 (DPO)

위임된 PoS 계층은 토큰, 스테이킹, 투표/프록시, 투표 소멸, 투표 집계, 생산자 순위, 인플레이션 지급 등의 개념을 소개합니다.또한 이 계층은 프로듀서 투표를 통해 생성된 랭킹을 바탕으로 새로운 프로듀서 일정을 생성하는 역할도 담당합니다.이는 약 2분 (126초) 의 스케줄 라운드로 진행되며, 이는 블록 생산자가 블록을 생성하고 서명할 수 있는 타임슬롯을 배정받는 데 걸리는 기간입니다.타임슬롯은 프로듀서당 총 6초 동안 진행되며, 이는 프로듀서 라운드이며, 최대 12개의 블록을 생성하고 서명할 수 있습니다.DPoS 계층은 WASM 스마트 계약에 의해 활성화됩니다.

3.2.1.이해관계자 및 대리인

실제 활동 프로듀서 선정 (프로듀서 일정) 은 매 일정 라운드마다 투표에 참여할 수 있으며, 참여권을 행사하는 모든 EOS 이해 관계자가 참여합니다.하지만 실제로 활동하는 프로듀서의 순위는 자주 바뀌지 않습니다.이해 당사자는 자신이 선호하는 블록 생산자가 자신을 대신하여 DPoS 대의원으로 활동하도록 투표하는 정규 EOS 계정 소유자입니다.그러나 일반 DPO와 크게 다른 점은 일단 선출되면 모든 블록 생산자가 투표 순위에 관계없이 동일한 권한을 갖는다는 것입니다.다른 DPoS 모델에서는 투표권이 각 대의원의 득표수에 비례합니다.

3.3.컨센서스 프로세스

EOS 합의 프로세스는 두 부분으로 구성됩니다.

• 프로듀서 투표/일정 수립 - DPoS 계층 2에서 수행
• 블록 생성/검증 - 네이티브 컨센서스 레이어 1에서 수행

이 두 프로세스는 독립적이며 병렬로 실행될 수 있습니다. 단, 블록체인의 첫 번째 제네시스 블록이 생성되는 부팅 시퀀스 이후 첫 번째 스케줄 라운드는 예외입니다.

4.프로듀서 투표/일정

다음 일정에 포함될 활성 생산자의 투표는 DPoS 계층에 의해 구현됩니다.엄밀히 말하면, 토큰 보유자는 먼저 일부 토큰을 스테이킹해야 이해 관계자가 되어 주어진 스테이킹 권한으로 투표할 수 있습니다.

4.1.투표 절차

각 EOS 이해관계자는 한 번의 투표로 최대 30명의 블록 생산자에게 투표할 수 있습니다.그러면 상위 21명의 선출된 프로듀서가 DPoS 대의원으로 활동하여 이해관계자를 대신하여 블록을 제작하고 서명하게 됩니다.나머지 생산자들은 득표한 순서대로 대기자 명단에 올립니다.투표 과정은 각 프로듀서가 획득한 투표 수를 합산하여 매 일정 라운드마다 반복됩니다.투표하지 않은 생산자들은 투표 무효로 인해 가치가 하락했지만 이전 투표를 유지하기로 투표하지 않았습니다.투표한 프로듀서들도 이전 투표를 유지할 수 있습니다. 단, 각 유권자에 대한 마지막 투표 가중치의 기여도는 새 투표 가중치로 대체됩니다.

4.1.1.투표 가중치

각 이해관계자의 투표 가중치는 스테이킹된 토큰 수와 2000년 1월 1일로 정의된 EOS 블록 타임스탬프 시대 이후 경과된 시간의 함수로 계산됩니다.현재 구현에서 투표 가중치는 스테이킹된 토큰 수에 정비례하고 2진수는 2000년 이후 몇 년 동안 경과한 시간에 기하급수적으로 비례합니다.실제 체중은 주당 2달러^ {1/52} = 1.013419$의 비율로 증가합니다.즉, 동일한 양의 토큰을 스테이킹하면 투표 가중치가 매주 바뀌며 매년 두 배로 늘어납니다.

4.1.2.투표 부정

투표 가중치를 높이면 각 생산자가 보유한 현재 투표 가치가 하락합니다.이러한 투표 거부는 의도적이며 그 이유는 두 가지입니다.

• 새로운 투표가 이전 투표보다 더 큰 비중을 차지하도록 하여 참여를 유도하세요.
• 중요한 거버넌스 문제에 적극적으로 관여하는 사용자들에게 더 많은 의견을 제시하세요.

4.2.프로듀서 일정

프로듀서에 대한 투표를 거쳐 다음 일정에 선정되면 프로듀서 이름을 알파벳순으로 정렬하기만 하면 됩니다.이에 따라 생산 순서가 결정됩니다.각 프로듀서는 곧 시작될 현재 스케줄 라운드의 검증을 받기 위해 첫 번째 블록 내에서 다음 스케줄 라운드를 위해 제안된 프로듀서 세트를 받습니다.제안된 일정이 포함된 첫 번째 블록이 생산자 과반수에 1을 더한 것에 의해 되돌릴 수 없는 것으로 간주되면 제안된 일정이 다음 일정 라운드에서 활성화됩니다.

4.2.1.생산 매개변수

EOS 블록 생산 일정은 선출된 생산자 간에 균등하게 분배됩니다.생산자는 다음 매개 변수 (스케줄 라운드당) 를 기반으로 각 일정 라운드마다 예상 블록 수를 생성할 예정입니다.

파라미터	설명	디폴트 값	레이어
P (프로듀서)	활동 중인 프로듀서 수	21	2
Bp (블록/생산자)	생산자당 연속 블록 수	12	1
Tb (s/블록)	블록당 생산 시간 (초: 초)	0.5	1

Bp (생산자당 연속 블록 수) 및 Tb (블록당 생산 시간) 는 Layer 1 컨센서스 상수라는 점을 언급하는 것이 중요합니다.반대로 P (활성 생산자 수) 는 DPoS 계층에 의해 구성된 계층 2 상수이며 WASM 계약을 통해 활성화됩니다.

위의 매개변수에서 다음 변수를 정의할 수 있습니다 (스케줄 라운드별).

변수	설명	방정식
B (블록)	총 블록 수	Bp (블록/프로듀서) x P (프로듀서)
Tp (S/프로듀서)	프로듀서당 제작 시간	Tb (s/블록) x Bp (블록/프로듀서)
T (s)	총 제작 시간	Tp (S/프로듀서) x P (프로듀서)

따라서 계층 2에서 정의되는 P의 값은 EOS 블록체인에서 동적으로 변할 수 있습니다.그러나 실제로 N은 21명의 생산자로 전략적으로 설정됩니다. 즉, 생산자의 3분의 2에 1명을 더하여 합의에 도달하려면 15명의 생산자가 필요합니다.

4.2.2.프로덕션 기본값

현재 기본값인 P=선출된 생산자 21명, Bp=생산자당 생성되는 블록 12개, T=0.5초마다 생성되는 블록의 경우 현재 제작 시간은 다음과 같습니다 (스케줄 라운드별).

변수	값
Tp: 프로듀서당 제작 시간	Tp = 0.5 (s/블록) x 12 (블록/프로듀서) ⇒ Tp = 6 (프로듀서당)
T: 총 제작 시간	T = 6 (생산자/생산자) x 21 (생산자) ⇒ T = 126 (초)

지정된 시간 동안 특정 생산자가 블록을 생성하지 않으면 블록체인에 공백이 발생합니다.

#5.블록 라이프사이클

활성 생산자가 지정된 시간대에 일정에 따라 블록을 생성한 다음 동기화 및 검증을 위해 다른 생산자 노드로 전달합니다.이 프로세스는 이후 일정에 따라 새로운 생산자 일정이 승인될 때까지 생산자 간에 계속됩니다.유효한 블록이 합의 요구 사항을 충족하는 경우 (참조) 3.이오스 컨센서스), 블록은 최종 결정되며 되돌릴 수 없는 것으로 간주됩니다.따라서 블록은 수명 기간 동안 생산, 검증 및 최종성이라는 세 가지 주요 단계를 거칩니다.각 단계도 다양한 단계를 거칩니다.

5.1.블록 구조

블록이 서로 연결된 시퀀스로서 블록체인 내의 기본 단위는 블록입니다.블록에는 사전 검증된 트랜잭션의 기록과 블록 확인, 검증 중 트랜잭션의 재실행, 블록체인 리플레이, 리플레이 공격으로부터의 보호 등에 필요한 해시 및 서명과 같은 추가 암호화 오버헤드가 포함됩니다 (참조). block 아래 스키마).

블록 스키마

이름	유형	설명
timestamp	block_timestamp_type	이 블록이 생성되는 예상 시간 슬롯 (.000초 또는 .500초 후에 종료)
producer	name	이 블록의 제작자 계정 이름
confirmed	uint16_t	현재 생산자 일정에서 이 블록의 생산자가 확인한 이전 블록 수
previous	block_id_type	이전 블록의 블록 ID
transaction_mroot	checksum256_type	블록에 포함된 거래 영수증의 머클 트리 루트 해시
action_mroot	checksum256_type	블록에 포함된 액션 영수증의 머클 트리 루트 해시
schedule_version	uint32_t	창립 이후 생산자 일정이 변경된 횟수
new_producers	producer_schedule_type	새로 제안된 프로듀서 일정에 대한 프로듀서 이름 및 키를 보유합니다. 변경이 없으면 null
header_extensions	extensions_type	추가 기능을 지원하기 위해 블록 필드를 확장합니다 (블록 ID 계산에 포함).
producer_signature	signature_type	블록을 만들고 서명한 제작자의 디지털 서명
transactions	배열 transaction_receipt	블록에 포함된 유효한 거래 영수증 목록
block_extensions	extension_type	추가 기능을 지원하기 위해 블록 필드를 확장합니다 (블록 ID 계산에 포함되지 않음).
id	block_id_type	이 블록 ID의 UUID (블록 헤더 및 블록 번호의 함수). 검증/검색 목적으로 블록을 쿼리하는 데 사용할 수 있습니다.
block_num	uint32_t	블록 번호 (제네시스 블록 0 이후의 순차 카운터 값). 검증/검색 목적으로 블록을 쿼리하는 데 사용할 수 있습니다.
ref_block_prefix	uint32_t	하위 32비트 블록 ID, 리플레이 공격을 방지하는 데 사용

일부 블록 필드는 블록이 생성될 때 미리 알려져 있으므로 블록 초기화 중에 추가됩니다.트랜잭션 및 액션에 대한 머클 루트 해시, 블록 번호 및 블록 ID, 블록을 생성하고 서명한 생산자의 서명 등과 같은 다른 것들은 블록 마무리 과정에서 계산되고 추가됩니다 (참조). 네트워크 피어 프로토콜: 3.1.블록 ID)

5.2.블록 프로덕션

블록 생산의 각 일정 라운드 동안 생산자는 일정에 따라 가능한 한 많은 검증된 트랜잭션을 포함하는 Bp=12개의 연속 블록을 생성해야 합니다.각 블록은 현재 Tb=500ms (0.5초) 범위 내에서 생산됩니다.각 블록을 생성하고 검증을 위해 다른 노드로 전송하는 데 충분한 시간을 보장하기 위해 블록 생성 시간을 구성 가능한 두 가지 매개변수로 더 나눕니다.

*최대 처리 간격: 트랜잭션을 블록으로 푸시하는 데 걸리는 시간 (현재 200ms로 설정). *최소 전파 시간: 블록을 다른 노드로 전파하는 데 걸리는 시간 창 (현재 300ms로 설정).

아직 만료되지 않았거나 이전의 검증 실패로 인해 삭제된 모든 소실 트랜잭션은 블록 포함 및 다른 노드와의 동기화를 위해 로컬 대기열에 보관됩니다.블록 프로덕션 중에 생산자는 예정된 트랜잭션을 일정에 따라 적용 및 검증하고, 유효하면 처리 간격 내에 보류 중인 블록으로 푸시됩니다.거래가 이 기간을 벗어나는 경우, 해당 거래는 적용이 취소되고 다음 블록에 포함되도록 일정이 조정됩니다.현재 생산자가 사용할 수 있는 블록 슬롯이 더 이상 없는 경우, 트랜잭션은 결국 다른 생산 노드에 의해 (P2P 프로토콜을 통해) 픽업되어 다른 블록으로 푸시됩니다.마지막 블록 (Bp 블록의 생산자 라운드부터) 의 최대 처리 간격은 다음 생산자에게 핸드오프하는 동안 발생하는 네트워크 지연을 보완하기 위해 약간 짧습니다.처리 간격이 끝날 무렵에는 보류 중인 블록에서 더 이상 트랜잭션이 허용되지 않으며, 블록은 검증을 위해 다른 블록 생산자에게 브로드캐스트되기 전에 최종 단계를 거칩니다.

블록은 제작 과정에서 적용, 마무리, 서명, 커밋 등 다양한 단계를 거칩니다.

5.2.1.블록 적용

적용 블록은 기본적으로 생산 노드가 수신하고 검증한 트랜잭션을 블록으로 푸시합니다.내부적으로 이 단계에는 블록 헤더와 서명된 블록 인스턴스의 생성 및 초기화가 포함됩니다.서명된 블록 인스턴스는 단순히 서명 필드로 블록 헤더를 확장합니다.이 필드에는 결국 블록에 서명하는 제작자의 서명이 포함됩니다.또한 EOS의 최근 변경 사항으로 인해 헤더 확장 필드에 저장된 여러 서명을 포함할 수 있습니다.

5.2.2.블록 파이널라이즈

생성된 블록은 서명, 커밋, 전달 및 검증되기 전에 마무리되어야 합니다.마무리하는 동안 암호화 검증에 필요한 블록 헤더의 모든 필드가 계산되어 블록에 저장됩니다.여기에는 액션 수신 목록과 블록에 푸시된 트랜잭션 수신 목록에 대한 머클 트리 루트 해시 생성이 모두 포함됩니다.

5.2.3.사인 블록

트랜잭션이 블록으로 푸시되고 블록이 확정되면 생산자가 블록에 서명할 준비가 됩니다.여기에는 블록에 포함된 거래 영수증을 포함하는 블록 헤더의 직렬화된 내용에서 서명 다이제스트를 계산하는 작업이 포함됩니다.생산자의 개인 키로 블록에 서명한 후 서명 다이제스트가 서명된 블록 인스턴스에 추가됩니다.이것으로 블록 서명이 완료됩니다.

5.2.4.커밋 블록

블록이 서명되면 로컬 체인에 커밋됩니다.이렇게 하면 블록이 가역적 블록 데이터베이스로 푸시됩니다 (참조). 네트워크 피어 프로토콜: 2.2.3.포크 데이터베이스).이렇게 하면 블록을 다른 노드와 동기화하여 검증할 수 있습니다 (참조). 네트워크 피어 프로토콜 블록 동기화에 대한 자세한 내용은 여기를 참조하십시오.

5.3.블록 검증

블록 검증은 EOS 블록체인 내에서 합의에 도달하는 데 필요한 기본 작업입니다.블록 검증 중에 생산자는 다른 피어로부터 들어오는 블록을 수신하고 각 블록에 포함된 트랜잭션을 확인합니다.블록 검증은 활동 중인 생산자 간에 다음과 같은 합의에 도달할 수 있는 충분한 정족수에 도달하는 것입니다.

• 블록과 블록에 포함된 트랜잭션의 무결성.
• 각 블록 내 트랜잭션의 결정적이고 시간순으로 정렬된 순서

블록 검증을 위한 첫 번째 단계는 노드가 블록을 수신할 때 시작됩니다.이 시점에서 블록에 대한 몇 가지 안전 점검이 수행됩니다.블록이 이미 알려진 블록에 연결되지 않거나 노드가 이미 수신하고 처리한 블록의 블록 ID와 일치하면 블록은 삭제됩니다.새 블록이면 체인 컨트롤러로 푸시되어 처리됩니다.

5.3.1.푸시 블록

체인 컨트롤러가 블록을 수신하면 소프트웨어는 로컬 체인 내에서 블록을 추가할 위치를 결정해야 합니다.포크 데이터베이스, 줄여서 Fork DB가 이러한 목적으로 사용됩니다.포크 데이터베이스에는 수신되었지만 아직 확정되지 않은 되돌릴 수 있는 블록이 있는 모든 브랜치가 보관됩니다.이를 위해 다음 단계가 수행됩니다.

1.fork 데이터베이스에 블록을 추가합니다. 2.현재 헤드 블록이 포함된 메인 브랜치에 블록이 추가된 경우 블록을 적용합니다 (참조). 5.2.1.블록 적용); 또는 3.블록을 다른 브랜치에 추가해야 하는 경우:

1. 이제 해당 분기가 현재 기본 분기와 비교하여 선호 분기가 되는 경우: 모든 블록을 가장 가까운 공통 조상으로 되돌리고 (그리고 프로세스에서 데이터베이스 상태를 롤백하고) 다른 분기의 모든 블록을 다시 적용하고 새 블록을 추가하고 적용합니다.이제 해당 브랜치가 새로운 메인 브랜치가 됩니다.
2. 그렇지 않으면 포크 데이터베이스의 해당 브랜치에 새 블록을 추가하고 다른 작업은 수행하지 않습니다.

블록을 포크 데이터베이스에 추가하려면 일부 블록 검증이 이루어져야 합니다.블록 헤더 검증은 포크 데이터베이스에 블록을 추가하기 전에 항상 수행해야 합니다.그리고 블록을 적용해야 하는 경우 블록 내 트랜잭션에 대한 일부 검증이 이루어져야 합니다.트랜잭션이 검증되는 정도는 노드가 구성된 검증 모드에 따라 달라집니다.전체 검증 (기본 모드) 과 라이트 밸리데이션의 두 가지 블록 검증 모드가 지원됩니다.

5.3.2.전체 검증

전체 검증 모드에서는 적용된 모든 트랜잭션이 완전히 검증됩니다.여기에는 거래의 서명 확인 및 승인 확인이 포함됩니다.

5.3.3.라이트 검증

라이트 검증 모드에서는 신뢰할 수 있는 생산자가 서명한 블록 (노드별로 로컬로 구성 가능) 은 전체 검증 중에 수행된 트랜잭션 검증을 일부 건너뛸 수 있습니다.예를 들어, 서명 확인을 건너뛰고 작업에 대해 청구된 모든 승인이 유효한 것으로 간주됩니다.

5.4.블록 파이널리티

블록 최종성은 EOS 합의의 최종 결과입니다.이는 적극적인 생산자 대다수가 합의 규칙에 따라 블록을 검증한 후에 달성됩니다 (참조). 3.1.레이어 1: 네이티브 컨센서스 (BaFT)).최종성에 도달한 블록은 블록체인에 영구적으로 기록되며 취소할 수 없습니다.이와 관련하여 체인의 마지막 비가역 블록 (LIB) 은 최종 블록이 된 가장 최근의 블록을 의미합니다.따라서 그 이후로는 블록체인에 기록된 트랜잭션을 되돌리거나, 변조하거나, 지울 수 없습니다.

5.4.1.파이널리티의 목표

최종 결정의 핵심은 LIB 블록 이전 및 이전에 적용된 트랜잭션을 수정, 롤백 또는 삭제할 수 없다는 확신을 사용자에게 제공하는 것입니다.LIB 블록은 또한 활성 노드가 가장 긴 브랜치에 관계없이 어떤 브랜치를 기반으로 빌드할지 빠르고 효율적으로 결정하는 데 유용할 수 있습니다.이는 가장 최신 LIB를 포함하지 않으면 지정된 분기가 더 길어질 수 있기 때문입니다. 이 경우 가장 최신 LIB를 가진 더 짧은 분기를 선택해야 합니다.

5.4.2.EOS 파이널리티

현재 위의 EOS 합의 규칙에 따르면 (참조 3.1.레이어 1: 네이티브 컨센서스 (BaFT)), 제안된 각 LIB 블록이 최종 확정되려면 두 차례에 걸쳐 예정된 BP 검증이 필요합니다.EOS 메인넷 (총 21BP 중 15BP를 차지함) 내에서 합의에 도달하기 위해서는 2/3+1 BP의 절대 다수가 필요하기 때문에 제안된 각 LIB 블록이 최소 이내로 최종 확정됩니다. 3 분 (180 초), 아래 계산에 따르면:

변수	값
Tp: 프로듀서당 제작 시간	Tp = 0.5 (s/블록) x 12 (블록/프로듀서) ⇒ Tp = 6 (S/프로듀서) (\ *)
SP: 생산자 대다수	SP = int [2/3* P (생산자)] + 1 ⇒ [P=21] SP = int [2/3* 21 (생산자)] + 1 = 14 + 1 (생산자) ⇒ SP = 15명 (생산자)
CR: 확인 라운드	CR = 2 (라운드) (\ \ )
FT: 파이널리티 타임	FT = SP x Tp (라운드당) x CR (라운드) ⇒ [SP=15, Tp=6, CR=2] FT = 15 (프로듀서) x 6 (s/프로듀서) (라운드당) x 2 (라운드) ⇒FT = 180 (s) = 3 (분)

(\ *): 섹션에서 4.2.2.프로덕션 기본값. (\ \ ): 제안된 LIB 블록을 검증하는 데 필요한 스케줄 라운드 수입니다.