V God은 ETH2.0 비콘 체인의 첫 번째 하드 포크 제안 HF1을 발표하여 더 공정한 노드 페널티 메커니즘을 도입했습니다.
편집자 주: 이 기사의 출처는배빗 정보 (ID: bitcoin8btc), Kyle이 허가를 받아 게시했습니다.
편집자 주: 이 기사의 출처는
배빗 정보 (ID: bitcoin8btc)
배빗 정보 (ID: bitcoin8btc)
, Kyle이 허가를 받아 게시했습니다.
"이더리움 창시자인 V God은 이더리움 비콘 체인(가칭 "HF1")의 첫 번째 하드포크 업그레이드 제안을 트위터에 소개했습니다. 덜 처벌적인 비활성 페널티 메커니즘을 도입했습니다 문서에 따르면 하드 포크는 개발자가 최근 출시된 비콘 체인에 대한 몇 가지 주요 업그레이드를 수행할 수 있도록 하며 변경 사항에 대한 더 유용한 테스트를 만드는 방법이 될 것입니다 라이트 클라이언트가 노드를 지원하는 곳 최소한의 리소스 요구 사항이 있고 모바일 장치에서 실행할 수 있습니다. 이를 통해 "최소 신뢰 지갑"은 By를 제공하기 위해 외부 서비스에 의존하지 않고 블록체인 자체를 확인할 수 있습니다.
HF1은 Ethereum 비콘 체인의 첫 번째 하드 포크 업그레이드에 대한 임시 코드 이름입니다(이 하드 포크에 대한 장기 명명 아이디어는 여기 참조). HF1의 주요 목표는 다음과 같습니다.
라이트 클라이언트 지원 추가
비콘 체인의 일부 취약점을 수정합니다. 이러한 취약점은 비컨 체인이 시작되었을 때 수정하기에는 너무 늦게 발견되었습니다.
비콘 체인의 하드 포크 업그레이드 메커니즘은 마이너 체인지 업그레이드 환경에서 테스트되므로 나중에 더 큰 변경이 이루어질 수 있습니다.
HF1에서 제안된 컨센서스 변경 사항은 다음과 같습니다.https://github.com/ethereum/eth2.0-specs/pull/2130
동기화 위원회
비콘 체인에 무작위로 뽑힌 "동기화 위원회"를 추가합니다. 이것의 목적은 라이트 클라이언트가 매우 적은 오버헤드(최소 하루에 약 20킬로바이트, 단일 블록을 확인하는 데 약 500바이트)로 체인 헤드를 결정할 수 있도록 하는 것입니다. 이를 통해 라이트 클라이언트는 모바일 장치, 내장 브라우저와 같은 사용 사례에 대해 실제로 비콘 체인을 사용할 수 있으므로 보다 신뢰가 최소화된 지갑 생태계를 위한 길을 닦을 수 있습니다.
각 기간(약 27시간)마다 1024명의 검증인이 무작위로 동기화 위원회 구성원으로 선정됩니다. 동기화 위원회의 유효성 검사기 노드는 현재 헤드를 증명하기 위해 서명을 발행합니다. 이러한 서명은 라이트 클라이언트가 이 헤드를 찾는 데 도움이 되는 LightClientUpdate 개체의 일부로 브로드캐스트되며 보상을 위해 비콘 체인에 포함됩니다.https://github.com/ethereum/eth2.0-specs/pull/2176
더 많은 콘텐츠:
부기 개혁(1단계)
증명자 보상 계산을 대체했습니다. PendingAttestation 개체를 저장하고 마지막에 처리하는 대신 각 유효성 검사기의 상태를 저장하는 비트 필드를 추가하여 참여한 사람에 대한 데이터를 실시간으로 축적할 수 있습니다. 비트 필드는 동일한 위원회의 유효성 검사기 레코드가 함께 표시되도록 "순서 섞기"로 정렬됩니다. 이 변경의 목적은 클라이언트 구현을 단순화하고 Merkle 트리 업데이트 비용을 낮추는 것입니다.
특정 참조:
부기 개혁(2단계)https://github.com/ethereum/eth2.0-specs/issues/2098
우리는 유효성 검사기 세트를 변경하고 페널티 기록은 모든 단일 에포크가 아니라 64 에포크마다 발생합니다. 이것의 목적은 "갭 기간 전환"을 처리하는 복잡성을 크게 줄이는 것입니다. 예를 들어 두 개의 연속 블록이 간격 기간만 있는 천 개의 슬롯으로 분리되는 참여가 매우 낮은 체인이 있습니다. 이러한 체인을 처리하기 위해 현재 클라이언트는 매 에포크마다 각 유효성 검사기의 잔액을 다시 계산하여 비활성 상태에 대해 유효성 검사기에 페널티를 부과해야 합니다.
또한 비활성 페널티 작동 방식에 두 가지 변경 사항이 적용되었습니다.https://github.com/ethereum/eth2.0-specs/pull/2192
https://github.com/ethereum/eth2.0-specs/pull/2194
비활성 페널티는 각 검증자에 대해 2차가 됩니다. 즉, 완전히 오프라인 상태였던 유효성 검사기가 잔액의 약 10%를 잃는 비활성 페널티가 있는 경우, 이 기간 동안 90% 동안 온라인 상태였던 유효성 검사기는 이제 잔액의 약 0.1%만 잃게 됩니다(비교 ~ 1%). 이는 네트워크 연결 문제로 인해 오프라인 상태인 정직한 노드가 아니라 진정으로 오작동하는 노드에 벌점을 집중시키려는 시도입니다.
INACTIVITY_PENALTY_QUOTIENT: reduced from 2**26 (= 67,108,864) to 3 * 2**24 (= 50,331,648)
PROPORTIONAL_SLASHING_MULTIPLIER: increased from 1 to 2
MIN_SLASHING_PENALTY_QUOTIENT: reduced from 2**7 (= 128) to 2**6 (= 64)
더 많은 논의는 여기에서 찾을 수 있습니다:
유효성 검사기 비활성 페널티는 결정된 후 중지되지 않고 점진적으로 느려집니다. 이렇게 하면 최종 상태에 도달하면 오프라인 노드가 일정 기간 동안 계속해서 균형을 잃게 되어 유효성 검사기의 온라인 시간 비율이 임계값보다 약간 높은 것이 아니라 2/3보다 훨씬 더 높아집니다.
특정 참조:
축하해야 할 한 가지는 유효성 검사기 페널티를 약화함으로써 숲에서 약간(완전하지는 않지만) 벗어날 수 있다는 것입니다. 상수를 변경합니다.
포크 선택 변경 사항은 HF1과 (거의) 동시에 배포됨https://econcs.pku.edu.cn/wine2020/wine2020/Workshop/GTiB20_paper_8.pdf
(블록, 슬롯) 쌍 (쌍) 포크 선택
현재 가장 최근 슬롯에 블록이 게시되지 않은 경우 해당 슬롯 동안 LMD GHOST 증명을 위해 증명자가 지원하는 체인의 최신 블록으로 간주됩니다. 예를 들어, 아래 다이어그램에서 BLANK에 대한 증명은 A에 대한 증명으로 간주됩니다.https://github.com/ethereum/eth2.0-specs/pull/2197
그러나 이것은 34% 공격의 문을 열어줍니다. 악의적인 공격자가 0.34*m을 제어하는 각 슬롯에 m개의 유효성 검사기가 할당된다고 가정합니다. 공격자는 또한 슬롯 n+1에 대해 블록 B를 게시할 권한이 있습니다. 공격은 다음과 같이 진행됩니다. 공격자는 B를 게시하지 않으며 이에 대한 어떠한 증거도 게시하지 않습니다. 모든 정직한 증명자는 슬롯 n에서 블록 A를 보았고 슬롯 n+1에서는 아무것도 보지 못했다는 주장에 투표할 것이며, 이 카운트는 현재 A에 대한 투표로 간주됩니다. 슬롯 n+2에서 정직한 제안자는 A 위에 블록 C를 구성할 것입니다. 이때 악의적인 제안자는 슬롯 n+1과 n+2에 B와 B의 증명을 알릴 것입니다. 상단 포크에는 0.68*m 검증자가 지원하지만 상단 포크에는 0.66*m 지원만 있으므로 하단 포크가 승리합니다.
이 공격은 문서의 섹션 3.1에 자세히 설명되어 있습니다.
제안된 솔루션은 블록 트리가 아닌 (블록, 슬롯) 쌍의 트리에서 작동하도록 포크 선택 작동 방식을 변경하는 것입니다. 따라서 위의 그래프에서 슬롯 n+1의 정직한 투표는 (BLANK,n+1)에 대한 투표로 계산되므로 위의 포크를 지원하는 것으로 올바르게 계산되므로 위의 포크가 받는 지원은 1.32*m입니다. 따라서 공격을 물리칩니다.
