V God이 개인적으로 Serenity의 설계 원리를 알려주고 이 웅장한 프로젝트의 독창성을 이해하도록 안내합니다!
편집자 주: 이 기사의 출처는Unitimes(ID:Uni-times)편집자 주: 이 기사의 출처는

Eth1.0 체인의 설계 원칙 문서는 다음을 참조하십시오.
https://github.com/ethereum/wiki/wiki/Design-Rationale
보조 제목
세레니티 디자인 원칙
▲ 단순성: 특히 암호화 경제 PoS와 2차 샤딩은 본질적으로 복잡하기 때문에 프로토콜은 결정에서 최대한 단순성을 위해 노력해야 합니다. 이는 다음과 같은 점에서 매우 중요합니다.
(i) 개발 비용 최소화,
(ii) 의도하지 않은 안전 문제의 위험을 줄이고,
(iii) 프로토콜 설계자가 매개변수 선택의 정당성을 사용자에게 쉽게 납득시킬 수 있도록 합니다.
배경 정보를 보려면 이 링크[1]를 따르십시오. 특정 수준의 기능을 달성하려는 경우 특정 복잡성을 피할 수 없습니다. 복잡성의 우선 순위 수준은 레이어 2 프로토콜 복잡성 > 클라이언트 구현 복잡성 > 프로토콜 사양 복잡성입니다.
▲장기적 안정성: 이상적으로는 하위 수준의 프로토콜을 구축하여 10년 이상 프로토콜 변경이 필요하지 않고 필요한 혁신이 상위 수준(클라이언트 구현 또는 Layer2 계약)에서 구현될 수 있도록 해야 합니다. .
▲ 충분성: 가능한 한 많은 애플리케이션 범주가 프로토콜 위에 구축될 수 있어야 합니다.
▲라이트 클라이언트의 검증 가능성: 몇 가지 보안 가정(예: 네트워크 대기 시간, 공격자 예산 범위, 1/n 또는 소수의 정직한 검증자만)이 주어지면 O© 데이터를 검증(이상적으로는 비콘 체인만 검증) 클라이언트는 간접적인 보증을 얻을 수 있어야 합니다. 51% 공격의 경우에도 시스템 전체의 모든 데이터를 사용할 수 있고 유효합니다(참고: 이는 "심층 방어" 측면의 목표 중 하나입니다).
보조 제목
Layer1과 Layer2 사이의 타협
독자는 이전 두 기사를 읽을 수 있습니다. Layer 1 Should Be Innovative in the Short Term but Less in the Long Term [2] 및 Sidechains vs Plasma vs Sharding [3].
모든 블록체인 프로토콜 설계에서 레이어 1(즉, 합의 레이어)에 더 많은 기능을 도입하는 것과 보다 간결한 레이어 1 프로토콜을 구축하고 이러한 기능을 레이어 2(즉, 애플리케이션 계층).각각 장단점이 있습니다.
Layer2를 지원하는 인수:
합의 계층의 복잡성을 줄입니다(위에서 언급한 "단순성" 참조).
프로토콜 레이어 수정 필요성 감소(위에서 언급한 "장기적 안정성" 참조):
-- 합의에 도달하지 못할 위험을 줄입니다.-- 프로토콜 거버넌스 및 정치적 위험에 대한 작업량 감소
시간이 지남에 따라 새로운 아이디어를 구현하는 유연성 및 능력 향상
Layer1을 지원하는 인수:
모든 사람이 새 프로토콜(예: 하드 포크)로 업그레이드하도록 강제하는 메커니즘이 없기 때문에 진행이 지연되는 위험을 줄입니다.
잠재적으로 전체 시스템의 복잡성을 줄입니다.
Layer1이 충분히 강력하지 않으면 Layer1에서 필요한 성능을 갖춘 Layer2 시스템을 구축하는 것이 불가능합니다(위에서 언급한 "풍부함" 참조).
이더리움 2.0의 디자인은 주로 레이어 1과 레이어 2 사이의 균형을 신중하게 유지하는 데 전념합니다. 여기에는 (i) Turing-complete, state-rich 코드 실행, (ii) 데이터 유효성 및 계산 측면에서의 확장성, (iii) 프로토콜 구현에 중요한 더 빠른 블록 확인 시간이 포함됩니다. Sex]는 다음과 같은 이유로 매우 필요합니다.
(i)를 구현하지 않으면 강력한 신뢰 모델로 레이어 2 애플리케이션을 구축하는 것이 불가능합니다.
(ii)가 없으면 확장성은 상태 채널 또는 플라즈마와 같은 기술로 제한되며 자금을 확장하고 잠그거나 규모에서 벗어나는 데 어려움이 있습니다.
(iii)이 달성되지 않으면 채널 기술을 사용하지 않고는 빠른 거래를 수행할 수 있는 방법이 없으며 자금의 촉진 및 잠금 및/또는 대규모 출구 측면에서 어려움이 있습니다.
그러나 이더리움 2.0은 또한 (i) 프라이버시, (ii) 높은 수준의 프로그래밍 언어, (iii) 확장 가능한 상태 저장소 및 (iv) 서명 체계와 같은 일부 다른 기능을 의도적으로 레이어 2에 남겼습니다. 이러한 기능은 이러한 측면이 급속한 혁신의 영역이고 많은 기존 솔루션이 서로 다른 특성을 가지고 있으며 더 좋고 새로운 솔루션을 얻기 위해 절충이 필연적으로 이루어지기 때문에 레이어 2에 남아 있습니다. 예를 들어:
프라이버시: 링 서명 + 기밀 값 대 ZK-SNARK 및 ZK-STARK, 롤업 대 ZEXE 등
고급 프로그래밍 언어: 선언적 프로그래밍 대 명령적 프로그래밍, 구문, 형식 검증 기능, 유형 시스템, 보호 기능(예: 산술 표현식에서 비순수 함수 사용 금지), 기본적으로 지원되는 개인 정보 보호 기능 등
서명 체계: Schnorr 서명, BLS 서명, Lamport 서명 등
보조 제목
보다:
https://github.com/ethereum/wiki/wiki/Proof-of-Stake-FAQ
https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51
보조 제목
캐스퍼를 사용하는 이유
현재 지분 증명(PoS) 합의 알고리즘은 주로 세 가지 진영으로 나뉩니다.
Satoshi Nakamoto에서 영감을 받은 지분 증명 알고리즘(예: Peercoin(Peercoin), NXT(Future Coin), Ouroboros(Cardano의 합의 알고리즘) 및 기타 실용적인 알고리즘)
PBFT(Practical Byzantine Fault Tolerance)에서 영감을 받은 지분 증명 알고리즘(예: Tendermint, Casper FFG, Hotstuff 등)
CBC Casper(설명은 [4] 및 [5] 참조)
후자의 두 진영에서는 마진 보증금(스테이킹)과 슬래싱(스테이킹)을 사용해야 하는지 여부와 방법에 대한 질문이 있습니다. 세 가지 지분 증명 메커니즘 모두 작업 증명(PoW)보다 우수하지만 이 기사에서는 이더리움 2.0에서 사용하는 접근 방식을 방어하고자 합니다.
날카로운
이더리움 2.0은 슬래싱(예금 페널티) 메커니즘을 사용합니다. 매장.
우리는 다음과 같은 이유로 슬래싱 메커니즘의 사용을 옹호합니다.
공격 비용 증가: 우리가 보장하고자 하는 것은 PoS 체인에 대한 51% 공격으로 인해 공격자가 매우 큰 비용(예: 수억 달러 상당의 공격으로부터 복구)을 지출하게 된다는 것입니다. 이것은 공격/방어 미적분을 공격자에게 매우 불리하게 만들고 실제로 공격을 비생산적으로 만들 수 있습니다.
검증자가 가져온 딜레마 극복: 노드가 "정직한" 행동에서 벗어나기 시작하는 가장 현실적이고 직접적인 방법은 태만입니다(예: 검증자는 검증에 참여해야 하지만 검증에 참여하지 않아야 합니다. 서명해서는 안 됩니다. 등) . 유효성 검사기가 제기하는 딜레마는 [6]에 자세히 설명되어 있으며 Bitcoin SPV 마이닝 [7]은 이러한 일이 발생하는 예이며 매우 심각한 결과를 초래할 것입니다. 부정직한 검증자에 대한 검증 페널티는 이러한 딜레마를 완화하는 데 도움이 됩니다.
마스터 노드와 백업 노드가 모두 있는 것이 일반화되면 공격자는 블록체인 네트워크를 분할하고 모든 유효성 검사기의 마스터 및 백업 노드가 서로 다른 블록을 제출하도록 하여 두 개의 충돌 영역이 생성되도록 할 수 있습니다. 삭감 페널티는 이 작업을 크게 억제하여 이러한 일이 발생할 위험을 줄이는 데 도움이 됩니다.
텍스트
합의 알고리즘의 선택
위에서 언급한 PoS 합의 알고리즘의 세 진영 중 후자의 두 진영(즉, PBFT와 CBC Casper에서 영감을 받은 합의 알고리즘)만이 이 두 알고리즘에서 Finality 개념을 가지고 있습니다. 이 방법: 많은 비율의 유효성 검사기(PBFT에서 영감을 받은 알고리즘은 최소 1/3의 유효성 검사기가 필요하고 CBC 캐스퍼 알고리즘은 최소 1/4의 유효성 검사기가 필요함)가 오작동할 때만 블록이 슬래시될 때만 반전됩니다.
그리고 첫 번째 캠프인 Nakamoto에서 영감을 받은(가장 긴 체인 규칙) 합의 알고리즘은 이러한 의미에서 최종성을 달성할 수 없습니다.
결정성을 달성할 때 프로토콜에서 사용할 수 있는 가장 단순한 알고리즘이기 때문에 Casper FFG를 선택했습니다. 우리는 현재 Ethereum 2.0의 3단계에서 CBC Casper로의 전환을 적극적으로 모색하고 있습니다.
보조 제목
샤딩, 또는 왜 우리는 슈퍼 노드를 싫어합니까?
Layer1 확장의 경우 샤딩의 주요 대안 중 하나는 슈퍼노드를 사용하는 것입니다.슈퍼노드는 노드가 각 트랜잭션을 개별적으로 처리할 수 있도록 각 합의 노드에 강력한 서버가 있어야 합니다.
슈퍼노드 기반 스케일링은 구현하기 쉽기 때문에 편리합니다. 이는 보다 병렬화된 방식으로 구축하기 위해 더 많은 소프트웨어 설계 작업이 필요하다는 점을 제외하면 현재 많은 블록체인에서 사용하는 것과 동일한 접근 방식입니다.
우리는 다음과 같은 주요 이유로 슈퍼 노드를 사용하는 이 방법을 선택하지 않습니다.
검증 풀 중앙화 위험: 슈퍼노드 기반 시스템에서 노드를 실행하려면 높은 고정 비용이 필요하므로 참여할 수 있는 사용자 수가 제한됩니다. 일부에서는 "대부분의 PoW 및 PoS 암호화폐에서 합의는 노드를 잘 실행할 수 있는 5-20개의 풀(채굴 풀 또는 유효성 검사 풀)에 의해 제어됩니다."라고 반박할 것입니다. 주머니가 깊은 수영장. 검증인을 운영하는 고정 비용이 보상에 비해 매우 높은 경우, 더 큰 검증인 풀은 더 작은 검증인 풀보다 더 낮은 수수료를 제공할 수 있으며, 이로 인해 이러한 소규모 검증인 풀이 붐비고 병합에 대한 압력을 느낄 수 있습니다. 샤딩 시스템에서 더 많은 ETH를 약속한 유효성 검사기는 더 많은 트랜잭션을 확인해야 하므로 비용이 고정되어 있지 않습니다.
클라우드 중앙 집중화 위험: 슈퍼노드 기반 시스템에서는 사용자가 집에서 스테이킹하는 것이 불가능하므로 대부분의 스테이킹은 클라우드 컴퓨팅 환경에서 발생할 가능성이 높습니다. 이로 인해 단일 실패 지점이 생성됩니다.
감소된 검열 저항: 높은 계산 + 대역폭 요구 사항 없이 사용자가 합의에 참여하는 것은 불가능하므로 검증자를 더 쉽게 감지하고 검열할 수 있습니다.
위에서 언급한 이러한 중앙 집중화 위험은 우리가 이더리움의 초저 지연 시간(1초 미만)을 달성하려고 하지 않고 (상대적으로) 보수적인 지연 시간을 선택하는 이유이기도 합니다. 이더리움 2.0 시스템에서는 ETH를 최대한 적게 또는 많이 사용하고 컴퓨팅 파워를 최대한 적게 또는 많이 사용하여 참여가 가능합니다. 작은 컴퓨팅 파워로 많은 양의 ETH를 스테이킹할 수 없으며 그 반대의 경우도 마찬가지임) 고정 비용은 최소화되지만 이 비용은 스테이킹하는 ETH의 양에 따라 증가합니다(일단 스테이킹하면 ETH의 수가 32,768 ETH를 초과하면 대부분의 시간 동안 모든 샤드 체인을 확인합니다(참고: 총 1024개의 샤드 체인이 있으며 각 유효성 검사기 ID는 32 ETH를 약속해야 하므로 1024*32=32,768).
보조 제목
보안 모델
일반적으로 블록체인의 보안은 "대부분의 참가자가 정직하다"는 가정, 즉 참가자의 ≥50%가 확립된 계약을 정직하게 따르고 개인적 이익을 위해 반역의 기회를 포기할 것이라는 가정에 의존한다고 믿어집니다.
사실, (i) 참가자가 "게으르고" 검증하지 않고 블록에 서명할 수 있기 때문에 "대부분의 참가자가 정직하다"는 가정은 비현실적입니다(Validator [9] 및 비트코인 SPV 마이닝[10]으로 인한 포크 참조) , 이는 매우 일반적인 결함 사례이지만 다행스럽게도 (ii) 블록체인은 일반적으로 자체 보안 속성을 유지하기 위해 일부 보안 모델을 통과합니다(대부분의 참가자가 정직하게 유지될 것이라고 가정하지 않음).
일반적이고 엄격한 보안 모델은 조정되지 않은 합리적 다수 모델(Uncoordinated Rational Majority)입니다. 즉, 참가자는 자신의 이익에 따라 행동하지만 서로 협력하는 참가자의 수는 일정 비율을 초과하지 않습니다. PoW 체인에서 이 비율은 23.2%입니다[11]).
또 다른 더 엄격한 보안 모델은 최악의 경우 모델입니다. 즉, 단일 참가자가 컴퓨팅 파워 또는 서약의 50% 이상을 제어할 때 이 때 문제는 다음과 같습니다.
(1) 이 경우 검증자가 전체 체인을 파괴하려고 할 때 매우 높은 비용을 지불할 것이라고 보장할 수 있습니까?
(2) 무조건 지킬 수 있는 보장은?
PoS 체인에서 삭감(예치금 삭감)은 위의 첫 번째 문제, 즉 공격자가 전체 체인을 파괴하려고 할 때 매우 많은 비용이 소요된다는 보장을 제공할 수 있습니다. 단편화가 없는 블록체인(예: 현재 이더리움 1.0 체인)에서 모든 블록을 확인하는 각 노드는 다음 두 가지 보증을 제공하여 위의 두 번째 질문의 요구 사항을 충족합니다. (i) 가장 긴 체인이 유효하고 (ii) 가장 긴 체인도 사용할 수 있습니다("데이터 가용성"의 중요성에 대한 이론적 근거는 이 링크 [12] 참조).
이더리움 2.0에서는 샤딩(sharding) 즉, 무작위로 선택된 검증인 위원회를 결합하여 대부분의 검증인이 정직할 보안 모델을 기반으로 심층 방어를 구현하여 효율성과 가용성 보장을 달성하고 게으른 검증인을 방지합니다. 사기 증명 및 데이터 가용성 증명을 통해 보관 증명(즉, 검증자가 "게으른" 상태이고 검증에 참여하지 않을 경우 처벌을 받게 됨) [9] 모든 데이터를 다운로드하고 검증하지 않고 유효하지 않고 사용할 수 없는 체인을 감지합니다. 이를 통해 클라이언트는 대부분의 PoS 검증자가 체인을 지원하는 경우에도 유효하지 않고 사용할 수 없는 체인을 거부할 수 있습니다.
예상되는 보안 특성은 아래 표에 나와 있습니다.

보조 제목
캐스퍼가 설정한 인센티브 메커니즘
기본 보상
각 에포크(이더리움 2.0에서는 생성된 64개 블록(약 6.4분)마다 에포크라고 함) 동안 각 유효성 검사기는 "증명"을 수행해야 합니다. 상단 블록). 검증자의 "증명"이 체인 헤더에 포함된 경우 검증자는 보상을 받게 됩니다. 이 보상은 다섯 부분으로 구성됩니다.
상위 블록에 포함된 "교정"에 대한 보상
올바른 에포크 체크포인트를 "증명"한 것에 대한 보상(참고: 각 에포크 동안의 마지막 슬롯을 체크포인트(checkpoint)라고 하며 슬롯은 프로토콜에 의해 설정된 블록을 생성하는 데 필요한 시간(6초))
올바른 체인 헤드(상단 블록)가 식별되었음을 "증명"한 것에 대한 보상;
"증명"이 온체인에 빠르게 포함되는 것에 대한 보상("증명"이 1 슬롯 이후에 포함된 경우 검증자는 전체 보상을 받습니다. 체인의 n 슬롯 이후에 포함된 경우 획득한 보상은 1/n입니다. 모든 보상 중);
올바른 샤드 블록이 식별되었음을 "증명"한 것에 대한 보상.
각각의 경우 실제 보상은 다음과 같이 계산됩니다. B가 기본 보상이고 P가 원하는 "증명" 작업을 수행하는 유효성 검사기의 일부인 경우 필요한 작업을 수행하는 모든 유효성 검사기는 B*P로 보상을 받는 반면 관련 작업을 수행해야 하지만 not 이를 수행하지 않는 유효성 검사기는 -B로 페널티를 받습니다. 이 "집단적 보상" 메커니즘의 목표는 "누군가가 더 잘하면 모두가 더 잘하는 것"이므로 기물 파손 요인을 제한합니다. (기물 파손 요소에 대한 설명과 이를 제한하는 것이 중요한 이유는 이 문서 [13]를 참조하십시오.)
위의 4번 항목은 예외이며, 이 보상은 검증자의 행동이 아니라 채택되는 "증거"의 지연에 따라 달라지며 처벌의 위험이 없습니다.
기본 보상 B 자체는 다음과 같이 계산됩니다. 여기서 D1...Dn은 유효성 검사기 예치금의 크기이고 k는 상수입니다. 이것은 (i) 고정된 보상률, 즉 k*Di 설정 및 (ii) 고정된 총 보상 설정, 즉 두 가지 일반적인 패턴 사이의 절충안입니다.
(i)에 대한 주된 주장은 이 모델이 네트워크에 두 가지 불확실성을 가져온다는 것입니다. 발행된 코인의 총량은 불확실하고 참여 서약의 총 수는 불확실합니다(고정 보상 비율이 너무 낮으면 기본적으로 한 사람이 참여하게 되어 전체 네트워크를 위협하고, 고정 보상률이 너무 높으면 너무 많은 사람들이 참여하게 되어 코인의 유통량이 예상외로 많아집니다.
(ii)에 대한 주요 주장은 이 모델이 네트워크를 "낙담 공격"에 더 취약하게 만든다는 것입니다. 자세한 내용은 [13]을 참조하십시오.
블록 제안자는 블록 제안자가 가능한 한 많은 정보를 듣고 가능한 한 많은 정보를 수용하도록 장려하기 위해 블록에 "증명"을 포함하는 것에 대해 기본 보상의 1/8로 보상을 받습니다.
손익분기점에 이르는 온라인 시간
텍스트
(i) 역할을 수행하는 온라인 검증자와 (ii) 오프라인 검증자 두 종류의 검증자가 있다고 가정하고 전자의 검증자가 부분적으로 P이고 기본 보상이 B인 경우 온라인 검증자는 다음을 받을 것으로 예상됩니다. 보상은 위의 1, 2, 3, 5번째 경우 보상 B*4P + 7/8*B*(P+(P*(1-P))/2+(P *(1-P)^2) /3+...) (유효성 검사자가 없기 때문에 "증명"이 체인 헤더에 포함되는 것이 지연될 수 있기 때문에) + 블록 제안자 보상 1/8*B*P . 불참한(즉, 검증에 참여했어야 하지만 실제로 검증을 하지 않은) 검증자는 B*4로 처벌받게 됩니다. 따라서 다른 모든 검증자가 온라인 상태이면 온라인일 때 검증자는 B*5로 보상되고 오프라인일 때 B*4로 불이익을 받게 되므로 검증자가 ≥4/(4+ 5) ≈ 44.44% 동안 온라인 상태이면 검증자는 손익분기점(손익분기점)을 이룰 수 있을 것입니다. P=2/3(즉, 온라인 검증자가 모든 검증자의 2/3를 차지)이면 검증자는 온라인 상태에 대한 보상이 ≈B*(2/3*4.125+7/8*0.81 )≈B입니다. *3.46 또는 온라인 시간 ≥ 53.6%로 인해 국제 수지에 도달합니다.
Inacivity leak
그러나 P가 2/3 미만인 경우(즉, 온라인 검증자의 수가 전체의 2/3 미만인 경우) 오프라인 검증자는 "비활성 유출"이라는 페널티를 받게 됩니다.
이더리움 2.0 체인이 4 epoch 이상 최종성 달성에 실패하면 가능한 최대 보상이 0이 되도록 추가 페널티가 추가됩니다(작업을 올바르게 수행하지 못한 검증자는 페널티가 부과됨). 얼마나 많은 에포크가 최종성을 달성하지 못했는지에 따라 비례적으로 증가합니다. 이는 검증인의 1/3 이상이 오프라인 상태가 되면 이러한 오프라인 검증인이 더 가혹하게 처벌되고 이 처벌이 시간이 지남에 따라 기하급수적으로 증가하도록 하기 위한 것입니다.
이렇게 하면 세 가지 효과가 있습니다.
오프라인 유효성 검사기는 이 시점에서 유효성 검사기의 오프라인이 실제로 블록이 완료되는 것을 방지하기 때문에 더 심각한 불이익을 받게 됩니다.
"반상관 페널티"의 목표 달성(아래에서 자세히 설명)
검증인의 1/3 이상이 동시에 오프라인 상태가 되면 결국 온라인이 되는 검증인의 수는 전체의 2/3로 회복됩니다. 유효성 검사기 순위.
이는 검증인의 50%가 오프라인 상태이면 21일 후에 모든 오프라인 검증인이 예치금의 50%(16 ETH)를 잃었기 때문에 21일 후에 블록이 다시 확정된다는 것을 의미합니다. 16 ETH, 그는 유효성 검사기 순위에서 추방됩니다.
텍스트
슬래싱 및 상관관계가 없는 페널티
검증인이 Casper FFG의 삭감 조건을 위반한 것으로 확인되면 해당 검증인은 패널티를 받게 됩니다(지분의 일부 손실). 검증자가 검증자를 종료할 때) 이전 벌금의 3배가 부과됩니다. 이는 다음과 같은 여러 가지 목적으로 사용됩니다.
검증인이 다른 많은 검증인과 동시에 잘못된 행동을 하는 경우에만 검증인의 행동이 네트워크에 실질적인 피해를 입힐 수 있으므로 이 경우 처벌은 더 가혹할 것입니다.
이것은 실제 공격에 큰 벌점을 주지만 악의적이지 않을 수 있는 개별 개인의 실수에 대해서는 매우 가볍게 벌점을 줍니다.
이것은 모든 사람이 가장 큰 유효성 검사기 풀에 참여하는 것을 금지합니다.
BLS 서명
텍스트
BLS 서명은 집계 친화적이기 때문에 BLS 서명을 사용합니다. 메시지 M은 키 k1 및 k2에 의해 처리됩니다(해당 공개 키 K1=G*k1, K2=G*k2, 여기서 G는 타원 곡선의 기준점임). 의 임의의 두 서명 S1 및 S2는 타원 곡선 점 추가(S1+S2)에 의해 간단하게 집계될 수 있습니다. 이를 통해 수천 개의 서명을 생성할 수 있으며, 각각은 하나의 데이터 비트(집계 서명에 특정 공개 키의 존재를 나타냄)의 한계 비용과 하나의 타원 곡선 추가로 계산할 수 있습니다.
우리는 검증인의 모기지 메시지 서명을 소유권 증명으로 사용하며 서명 키 및 인출 키와 같은 기타 중요한 정보를 지정합니다.
보조 제목
검증자의 무작위 선택<- hash(seed,임의성을 달성하는 데 사용되는 시드는 블록 제안자가 공개해야 하는 값(즉, 시드는
new_data)) 각 블록에서 업데이트됩니다. 에스크로 증명의 하위 키와 마찬가지로 검증자의 값은 검증자가 서약을 한 직후에 결정되며, 제3자는 하위 키를 계산할 수 없지만 리소스에 의해 하위 키가 공개되면 이를 검증합니다(이 메커니즘은 RANDAO라고도 함).
앞으로 우리는 조작에 대한 무작위 시드의 견고성을 더욱 높이기 위해 VDF(Verifiable Delay Functions)를 사용할 계획입니다.
텍스트
셔플 유효성 검사기
각 에포크 동안 우리는 스왑 여부 셔플[13]을 사용하여 유효성 검사기를 셔플하고 책임을 할당합니다. 이 알고리즘은 다음을 보장합니다.
셔플은 순열이기 때문에 각 유효성 검사기는 각 시대 동안 장기 위원회의 구성원으로 임명됩니다.
텍스트
가교 위원회
각 에포크 동안 각 샤드는 교차 링크(crosslink)를 수행합니다. 즉, 샤드 위원회에서 검증자 중 2/3를 무작위로 선택합니다(각 샤드 위원회의 인증자 수는 약 128명입니다).포함된 모든 데이터의 해시는 마지막 크로스링크가 서명된 이후 샤드에서(샤드의 크로스링크가 실패할 수 있기 때문에 해시는 최대 처음 64 에포크의 데이터를 나타낼 수 있습니다. 따라잡기 위해 여러 개의 성공적인 교차 연결을 사용하십시오).
샤드 위원회 당 검증인의 수는 전체 검증인의 1/3 미만을 통제하면서 위원회 구성원의 2/3를 통제하는 공격자를 방어하기 위한 최소 숫자이기 때문에 128로 설정됩니다. 이항 정리에 의해 위원회 구성원의 2/3를 제어하는 공격자는 5.55*10^(-15)
각 에포크(64블록, 약 6.4분) 후에 비콘 체인은 각 샤드 체인에 대한 샤드 위원회를 재구성합니다(즉, 유효성 검사기를 방해합니다). 빠른 스크램블링 유효성 검사기의 목적은 공격자가 샤드 체인을 공격하려는 경우 공격자가 샤드 위원회를 신속하게 파괴(통제)해야 한다는 것을 확인하는 것입니다.
텍스트
장기 위원회
약 27시간마다 시스템은 각 샤드 체인에 대한 영구 위원회를 선택합니다. 어느 시점에서든 이더리움 2.0 시스템의 모든 유효성 검사기는 이러한 장기 위원회 중 하나의 구성원입니다. 장기 위원회는 샤드 블록을 제안하고 사용자에게 샤드 블록에 대한 일정 수준의 보증을 제공하며(샤드 블록이 교차 링크에 포함될 때까지) 라이트 클라이언트는 장기 위원회에 의존할 수 있습니다. P2P 네트워크의 안정성과 라이트 클라이언트의 효율성을 유지하기 위해 장기적인 위원회 변경은 상대적으로 드뭅니다(샤드 위원회는 ~6분마다 변경됨).
네트워크의 안정성을 더욱 유지하기 위해 모든 검증인이 n 기간의 장기 위원회에서 n+1 기간의 장기 위원회로 동시에 순환되지는 않습니다. 유효성 검사기는 일정 기간 동안 임의의 시점에서 다음 회전까지 지연됩니다.
보조 제목
LMD GHOST 포크 선택 규칙
LMD GHOST 포크 선택 규칙은 모든 유효성 검사기의 정보를 결합하여 정상적인 상황에서 어떤 블록도 되돌릴 수 없도록 합니다. 이 분기 선택 규칙은 모든 유효성 검사기에 의존하기 때문에 공격자가 유효성 검사기의 50% 이상을 제어하지 않는 한 블록을 되돌릴 수 없도록 합니다.
보조 제목
비콘 체인/샤드 체인 구조
Ethereum 2.0 샤딩 시스템의 구조는 모든 활동을 조정하는 중앙 "비콘 체인"과 1024개의 샤드 체인으로 구성됩니다. 각 샤드 체인은 교차 링크를 통해 비콘 체인에 정기적으로 연결됩니다.
이 샤딩 구조에 대한 대안:
(1) 위원회를 통해 샤드 블록에 서명하고 모든 샤드 블록을 비콘 체인에 직접 넣습니다.
(2) 비콘 체인은 없지만 모든 샤드 체인이 일정한 구조로 연결되어 있습니다.
위의 구조 (1)을 포기한 이유는 샤드 체인 블록에 6초 시간(슬롯)을 설정하는 것이 바람직하지만 6초마다 비컨 체인에서 1024개의 교차 링크를 수행하면 체인으로 이어지기 때문입니다. 매우 높은 부하를 받습니다.
항소심 (2)의 구조를 포기한 이유는 허브 앤 스포크 비콘 체인 구조가 어떤 복잡한 구조보다 구현과 이해가 더 쉽기 때문입니다.
샤드 체인 디자인
각 샤드는 교차 연결된 집계 블록보다 빠르게 블록을 처리할 수 있는 반독립적인 체인입니다(목표 3-6초). 이를 통해 거래는 비콘 체인(교차 연결을 통해)에 의해 확인되기 전에 샤드의 장기 위원회를 통해 일정 수준의 확인을 신속하게 얻을 수 있습니다.
샤드 체인의 구조는 각 블록이 샤드 위원회의 각 검증자에 의해 증명되어 검증의 단순성을 보장하고 샤드 블록이 상당히 높은 수준의 확인을 갖도록 보장합니다. 단일 확인에 의존할 수 있어야 합니다.
각 에포크가 시작될 때 각 샤드 블록에는 상위 블록에 대한 포인터와 비콘 블록에 대한 포인터가 포함됩니다. 비콘 체인과 샤드 체인 사이의 이 반긴밀한 결합은 (i) 샤드 체인이 장기 위원회에 대한 정보를 알고 있는지 확인하기 위한 것입니다(이 정보는 샤드 체인 블록에 의해 생성되기 때문에 어떤 체인을 결정하는 실행 가능한 방법입니다) 표준 비콘 체인입니다.
샤드 체인 상태(보상, 페널티, 히스토리 누적기)는 사기 증명이 필요한 경우 샤드 체인 상태가 비콘 체인에 완전히 배치될 수 있도록 의도적으로 블록 크기보다 작게 설계되었습니다. 각 개별 실행 환경의 상태가 이 크기로 제한되는 2단계에서 제한이 완화되지만 결합된 모든 상태는 매우 커서 사기 증명에는 Merkle 증명이 필요합니다.
교차 연결된 데이터
교차 링크에는 마지막 교차 링크 이후 샤드의 모든 샤드 블록을 포함하는 데이터 구조의 Merkle 루트인 data_root가 포함됩니다. 이 교차 연결 데이터 구조 + 루트에는 여러 대상이 있습니다.
표준 샤드 체인 블록이 무엇인지 비콘 체인에 알리십시오.
사기 방지를 위해 평가할 수 있는 간단한 바이트 배열을 만듭니다.
보조 제목
유효성 검사기 수명 주기
약속
검증자는 트랜잭션(이 트랜잭션은 Eth1.0 체인에 배포된 예금 계약의 기능을 호출함)을 전송하여 ETH 서약을 수행하고 마지막으로 Eth2.0 체인에 서약 방법을 추가합니다. 검증자에 의한 이 조치는 다음을 명확히 합니다.
메시지 서명에 사용된 개인 키에 해당하는 공개 키
출금 자격 증명(즉, 검증자가 검증을 완료할 때 자금을 출금하는 데 사용되는 공개 키 해시)
약속 금액
이 값은 모두 서명 키로 서명됩니다. 서명 키와 출금 키를 분리하는 목적은 더 위험한 출금 키를 더 안전하게 만들기 위한 것이며(출금 키는 오프라인이며 어떤 서약 풀 등과도 공유되지 않음), 서명 키는 메시지에 서명하는 데 사용됩니다. 각 시대 동안.
예금 계약은 모든 서약의 Merkle 루트를 보유합니다. 유효성 검사기가 약속한 Merkle 루트가 Eth2.0 체인에 포함되면(Eth1.0 데이터 투표 메커니즘을 통해) Eth2.0 블록 제안자는 서약의 Merkle 증명을 제출하고 서약 프로세스를 시작할 수 있습니다.
활성화
검증자가 모기지 컨트랙트에 트랜잭션을 보내면 즉시 검증자 등록 테이블에 추가되지만 초기에는 검증자가 비활성화됩니다. 검증인은 최소 4 epoch 이후에만 활성화되며, 검증인이 최소 4 epoch(epoch당 약 6.4분)를 기다려야 하는 이유는 RANDAO가 조작되지 않도록 하기 위함이며 동시에 많은 검증인이 참여하는 경우 N은 4를 초과할 수 있습니다.
Eth2.0에 존재하는 전체 검증자 수가 |V|인 경우 각 epoch 동안 추가할 수 있는 최대 검증자 수는 max(4, |V|/65536)이며, 더 많은 검증자가 Join in을 원하면 대기해야 하며 시스템에서 최대한 빨리 처리합니다.
그만두다
검증인이 Eth2.0 시스템에서 탈퇴할 때(자발적 종료 메시지를 게시하거나 슬래싱으로 인해 종료하든 상관없이) 검증인도 시스템에서 탈퇴하기 위해 대기해야 합니다. 위에서 설명한 대로 추가할 수 있는 새 유효성 검사기의 최대 개수와 동일합니다.
이 새로운 참여/퇴장 대기열 제한의 이유는 시스템의 총 유효성 검사기 수가 두 시점 사이에서 너무 빨리 변경되지 않도록 하기 위함입니다. number ≥ 262144이면 검증자는 1~2개월에 한 번씩 로그인할 수 있음을 보장합니다.) 이더리움의 기존 체인과 새 체인 간에 여전히 확실성이 있음을 보장할 수 있습니다. 관련 원리는 [17] 및 [18]을 참조하십시오.
돈을 인출
유효성 검사기가 성공적으로 대기열을 빠져나오면 출금이 이루어지기까지 약 27시간의 대기 기간이 있습니다. 이 대기 시간에는 여러 가지 효과가 있습니다.
이렇게 하면 유효성 검사기가 오작동하는 경우 오작동을 포착하고 유효성 검사기를 삭감할 시간이 있습니다.
이렇게 하면 시스템이 마지막 샤드 보상 기간을 해당 검증자에게 분배할 시간을 줍니다.
이는 에스크로 증명에 대한 도전이 시작될 시간을 제공합니다.
0단계에서 "인출"을 원하는 유효성 검사기는 실제로 그렇게 할 수 없으며 이후 단계에서는 유효성 검사기가 인출한 자금을 실행 환경으로 전송할 수 있습니다.
효과적인 균형
검증인의 잔고를 기반으로 하는 대부분의 계산은 검증인의 "유효 잔고(EB)"를 사용하며 유일한 예외는 검증인의 잔고를 늘리거나 줄이는 계산입니다. 검증자의 잔고 B가 EB보다 낮거나 EB+1.5보다 높을 때만 EB는 floor(B)와 같게 조정됩니다. 이는 유효 잔액이 자주 변경되지 않도록 하여 각 에포크 동안 상태를 다시 계산하는 데 필요한 해싱의 양을 줄이기 위한 것입니다.
보조 제목
포크 메커니즘
포크 데이터 구조에는 (i) 현재 "포크 ID", (ii) 이전 "포크 ID" 및 (iii) 두 포크를 전환한 슬롯이 포함됩니다. 현재 블록 높이의 포크 ID는 모든 메시지의 유효한 서명에 영향을 미치므로 하나의 포크 ID로 서명된 메시지는 다른 포크 ID를 사용하는 검증 기능에 유효하지 않습니다.
포크는 "포크 슬롯"에 상태 전환을 추가하여 수행할 수 있습니다. 서명 검증 기능은 메시지가 위치한 슬롯의 포크 ID를 사용하여 메시지를 검증하며, 이 포크 ID는 이전 포크 ID일 수도 있고 현재 포크 ID일 수도 있습니다.
어떤 사용자라도 포크에 참여하고 싶지 않다면 포크 슬롯에서 포크 ID를 변경하지 않은 체인에 그대로 있으면 됩니다. 두 체인 모두 계속 존재할 수 있으며 유효성 검사기는 페널티 없이 두 체인을 자유롭게 검증할 수 있습니다.
비고: 번역이 삭제되었습니다.
[1]:https://radicalxchange.org/blog/posts/2018-11-26-4m9b8b/
[2]:https://vitalik.ca/general/2018/08/26/layer_1.html
[3]:https://vitalik.ca/general/2019/06/12/plasma_vs_sharding.html
[4]:https://vitalik.ca/general/2018/12/05/cbc_casper.html
[5]:https://medium.com/@aditya.asgaonkar/casper-cbc-simplified-2370922f9aa6
[6]:https://eprint.iacr.org/2015/702.pdf
[7]:https://bitcoin.stackexchange.com/questions/38437/what-is-spv-mining-and-how-did-it-inadvertently-cause-the-fork-after-bip66-wa
[8]:https://twitter.com/VitalikButerin/status/1145576103089602560
[9]:https://eprint.iacr.org/2015/702.pdf
[10]:https://bitcoin.stackexchange.com/questions/38437/what-is-spv-mining-and-how-did-it-inadvertently-cause-the-fork-after-bip66-wa
[11]:https://arxiv.org/abs/1507.06183
[12]:https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding
[13]:https://ethresear.ch/t/censorship-detectors-via-99-fault-tolerant-consensus/2878
[14]:https://github.com/ethereum/research/raw/master/papers/discouragement/discouragement.pdf
[15]:https://link.springer.com/content/pdf/10.1007%2F978-3-642-32009-5_1.pdf
[16]:https://github.com/ethereum/eth2.0-specs/blob/master/specs/core/0_fork-choice.md
[17]:https://ethresear.ch/t/rate-limiting-entry-exits-not-withdrawals/4942
[18]:https://ethresear.ch/t/weak-subjectivity-under-the-exit-queue-model/5187


