EIP-225 클리크 권한증명 합의 프로토콜 (Clique proof-of-authority consensus protocol)

최종 확정 · 합의·스테이킹 · 원문 상태 Final · 2017-03-06 작성

미리 승인된 서명자만 블록을 만들 수 있는 권한증명(proof-of-authority) 합의 방식 클리크(Clique)를 정의합니다. 기존 블록 헤더 구조를 그대로 재활용해 어떤 클라이언트에도 쉽게 넣을 수 있습니다.

왜 필요한가

테스트넷은 실제 가치가 없는 네트워크라서 작업증명(proof-of-work)으로는 지킬 수 없습니다. 작업증명 네트워크의 안전성은 투입된 계산력만큼만 보장되기 때문입니다. 실제로 2017년 2월 말 Ropsten 테스트넷에서 공격자가 낮은 채굴 난이도를 악용해 블록 가스 한도를 평소 470만에서 90억까지 부풀린 뒤 거대한 트랜잭션을 보내 네트워크를 마비시켰습니다. 그 전에도 아주 긴 체인 재구성(reorg)을 여러 번 시도해 클라이언트와 버전 사이에 네트워크가 갈라졌습니다. Parity 팀은 블록을 되돌리고 가스 한도를 제한하는 긴급 소프트포크로 대응했지만 이 방식은 다른 클라이언트가 포크 규칙을 따로 구현해야 하고 fast·light 싱크와 맞지 않으며 쓰레기 데이터 유입을 막지 못하는 임시방편이었습니다. 지분증명(Casper)은 아직 연구 단계라 당장 쓸 수 없었기 때문에, 바로 구현할 수 있으면서 테스트넷을 제대로 고칠 수 있는 권한증명 방식이 제안됐습니다.

무엇이 바뀌나

지금

EIP-225 이후

누구에게 영향이 있나

심층 설명

설계 제약: 서명자 목록은 헤더 안에서만 관리

권한증명에서는 모든 블록을 신뢰받는 서명자 목록과 대조해야 하는데, 이 목록은 시간에 따라 바뀝니다. 목록을 이더리움 컨트랙트에 저장하면 될 것 같지만 fast·light·warp 싱크는 동기화 중에 상태(state)에 접근할 수 없어서 쓸 수 없습니다. 헤더에 투표용 필드를 새로 추가하는 방법도 여러 구현체의 핵심 자료구조를 바꿔야 해서 개발·유지보수·보안 모두에 부담이 됩니다. 그래서 원문은 두 가지 제약을 둡니다. 서명자 목록을 관리하는 프로토콜은 블록 헤더 안에 완전히 담겨야 하고 현재의 데이터 모델에 그대로 들어맞아야 합니다. 그 결과 EVM 대신 헤더를, 새 필드 대신 기존 필드를 재활용하는 설계가 나왔습니다.

헤더 필드 재정의와 상수

extraData는 앞쪽 EXTRA_VANITY(32바이트)를 서명자 자유 공간으로, 뒤쪽 EXTRA_SEAL(65바이트)을 서명 자리로 고정합니다. 체크포인트(에폭 전환) 블록은 그 사이에 현재 서명자 목록(N*20바이트)을 오름차순 바이트 순서로 넣고 평소에는 생략합니다. beneficiary(miner)는 목록 변경을 제안할 주소를 담는 칸이 되고 평소에는 0으로 둡니다. nonce는 그 주소에 대한 제안으로, 추가는 NONCE_AUTH(0xffffffffffffffff), 제거는 NONCE_DROP(0x0000000000000000)만 허용하며 체크포인트 블록에서는 두 필드 모두 0이어야 합니다. ommersHash는 PoW 밖에서 엉클이 의미가 없으므로 항상 UNCLE_HASH(Keccak256(RLP([])))이고 mixHash는 포크 보호용으로 남겨 두되 평소에는 0입니다. timestamp는 부모 타임스탬프에 BLOCK_PERIOD(제안값 15초)를 더한 값 이상이어야 합니다. difficulty는 블록 점수로, BLOCK_NUMBER % SIGNER_COUNT == SIGNER_INDEX인 차례(in-turn) 블록은 DIFF_INTURN(2), 아니면 DIFF_NOTURN(1)입니다. 에폭 길이 EPOCH_LENGTH는 메인넷 ethash와 비슷하게 30000블록이 제안값입니다. 트랜잭션 실행 시 COINBASE 명령어와 수수료 귀속은 beneficiary가 아니라 extraData에서 복원한 실제 서명자 계정을 써야 합니다.

블록 서명과 서명 빈도 제한

서명자는 블록의 sighash에 서명합니다. sighash는 서명 자체를 뺀 모든 것, 즉 nonce와 mixDigest를 포함한 헤더의 모든 필드와 65바이트 서명 접미사를 제외한 extraData를 옐로페이퍼 정의 순서대로 해시한 값입니다. 서명은 표준 secp256k1 곡선으로 만들며 결과 65바이트(R, S, V, 단 V는 0 또는 1)가 extraData 끝에 들어갑니다. 서명에서 주소를 복원할 수 있으므로 별도의 miner 필드가 필요 없어집니다. 키 유출 피해를 막기 위해 각 서명자는 SIGNER_LIMIT(floor(SIGNER_COUNT / 2) + 1)개 연속 블록 중 최대 1개만 서명할 수 있습니다. 권장 전략으로, 차례인 서명자는 부모 시각 + BLOCK_PERIOD에 맞춰 바로 서명하고 전파하며 차례가 아닌 서명자는 rand(SIGNER_COUNT * 500ms)만큼 늦춰 작은 포크와 네트워크 트래픽을 줄입니다.

투표 규칙과 에폭 체크포인트

에폭 전환 블록(제네시스 포함)은 상태 없는 체크포인트입니다. 투표를 담아서는 안 되고 미결 투표는 모두 폐기되며 집계는 처음부터 다시 시작합니다. 덕분에 클라이언트는 체크포인트 해시 하나만으로 그 전의 투표 내역을 재생하지 않고 동기화할 수 있습니다. 에폭이 아닌 블록에서는 서명자가 자기 블록마다 1표를 던질 수 있고 같은 서명자가 같은 대상에 던진 표는 최신 것만 남습니다. 여러 제안을 동시에 진행할 수 있으며 찬성이 SIGNER_LIMIT에 도달한 제안은 즉시 효력이 생깁니다. 제안이 통과되면 그 대상에 대한 미결 투표는 찬반 모두 폐기됩니다. 서명자가 아닌 주소를 제거하자는 식의 무의미한 제안도 구현 단순화를 위해 처벌하지 않습니다. 작은 재구성으로 투표 블록이 사라질 수도 있으므로, 서명자 노드에 제안을 설정해 두고 블록마다 무작위로 하나씩 실어 보내는 전략이 제시됩니다. 제안이 통과한 것처럼 보여도 재구성될지 모르니 바로 버리면 안 됩니다.

연쇄 투표 금지

서명자가 제거되면 과반 기준이 1 낮아져서 대기 중이던 다른 제안이 갑자기 과반에 도달할 수 있습니다. 그 실행이 또 다른 제안의 통과로 이어질 수도 있습니다. 서로 충돌하는 제안(예: 새 서명자 추가와 기존 서명자 제거)이 동시에 통과하면 평가 순서에 따라 최종 목록이 크게 달라지는데, 서명자는 블록마다 자기 표를 뒤집을 수 있어 어느 제안이 먼저인지도 분명하지 않습니다. 클리크는 이 함정을 피하려고 연쇄 효과를 명시적으로 금지합니다. 현재 헤더의 beneficiary로 지목된 계정만 목록에 추가되거나 제거될 수 있고 그 여파로 과반에 도달한 다른 제안은 해당 대상이 투표로 다시 지목될 때, 그 시점에도 과반이 유지되는 경우에만 실행됩니다.

네 가지 공격 벡터와 방어

악성 서명자: 악의적 사용자가 목록에 들어오거나 서명 키가 탈취돼도, 서명자당 K개 블록 중 1개만 서명할 수 있어 피해가 제한되고 나머지 서명자가 투표로 쫓아낼 수 있습니다. 검열 서명자: 자신을 제거하는 투표가 담긴 블록을 검열하려는 서명자에 대비해 서명 빈도를 N/2 중 1로 제한합니다. 검열에 성공하려면 서명 계정의 51% 이상을 장악해야 하는데, 그 경우는 어차피 게임이 끝난 상황입니다. 스팸 서명자: 블록마다 새 제안을 끼워 넣으면 노드가 추적해야 할 투표가 한없이 늘어나므로, W개 블록이 지난 표는 무효로 처리합니다. 이 구간을 에폭이라 부릅니다. 동시 블록: 서명자가 N명이면 매 시점 N-K+1명이 블록을 만들 수 있어 경쟁이 생기므로, 각 서명자가 블록 공개 시각에 작은 무작위 지연을 더해 작은 포크가 드물게만 일어나도록 합니다.

상태, 구현, 테스트 케이스

이 EIP는 상태가 Final로 확정된 명세입니다. 참조 구현은 go-ethereum의 consensus/clique 패키지에 들어 있고 2017년 4월부터 Rinkeby 테스트넷의 합의 엔진으로 작동해 왔습니다. 원문에는 투표 시나리오별 테스트 케이스가 함께 실려 있어 경계 조건을 명시합니다. 권한 없는 서명자의 블록은 errUnauthorizedSigner로, 최근에 서명한 서명자의 재서명은 errRecentlySigned로 실패해야 하고 체크포인트 블록을 일괄 임포트해도 최근 서명 기록이 초기화되면 안 됩니다. 또 통과된 제안의 미결 투표가 시스템에 남아 이후 결과를 오염시키면 안 된다는 점도 서명자가 빠르게 추가·제거·재추가되는 사례로 검증합니다.

EIP 원문 · ← EIPs