분산 검증자 기술을 통한 다수결 포크(Fork) 보호: 네트워크 복원력을 위한 새로운 접근 방식

검토해 주셔서 감사합니다, 마테우스 프랑코 님.

추상적인

Holesky 테스트넷 사건은 이더리움 합의 메커니즘의 치명적인 취약점을 드러냈습니다. 클라이언트 버그로 인해 검증자 대다수가 잘못된 체인 상태를 증명할 경우, 네트워크는 복구 불가능한 상태에 빠지게 되며, 최종성을 복원하려면 파괴적인 비활성 누출이 필요합니다. 본 논문은 이기종 운영자를 사용하는 분산 검증자 기술(DVT)이 이러한 다수 포크 시나리오에 대한 보호 메커니즘을 제공할 수 있다고 제안합니다. DVT 클러스터 수준에서 체크포인트 검증을 도입함으로써, 다양한 검증자 운영자가 악의적인 포크에 대한 증명을 선택적으로 거부하여 대규모 슬래싱 이벤트 없이도 최종화를 방지할 수 있음을 보여줍니다. 이 메커니즘은 잘못된 포크에 대한 단기적인 정당화를 장기적인 네트워크 안전성과 맞바꾸어, 정직한 소수가 사회적 합의와 비활성 누출을 통해 궁극적으로 승리할 수 있도록 합니다.

1. 이더리움의 근본적인 설계 선택: 안전성보다 활성성을 우선시함

이 글은 이더리움의 안정성보다 활성성을 우선시하는 설계 방식과 비활성 상태 유출과의 관계에 대한 요약입니다. 이미 관련 내용을 잘 알고 계신 분은 다음 섹션으로 넘어가셔도 됩니다.

1.1 CAP 정리와 블록체인 합의

이더리움의 합의 메커니즘은 근본적인 차원에서 의도적인 선택을 반영합니다. 네트워크가 안전성(충돌하는 최종 상태 방지)과 활성성(지속적인 블록 생성 및 확정) 사이에서 선택해야 할 때, 이더리움은 활성성을 우선시합니다 . 즉, 서로 다른 포크들이 네트워크 승인을 얻기 위해 경쟁할 수 있도록 허용합니다.

이러한 선택은 CAP 정리(CAP Theorem) 에 근거합니다. CAP 정리는 분산 시스템이 일관성(안전성), 가용성(활성), 그리고 분할 내성을 동시에 보장할 수 없다고 명시합니다. 이더리움은 네트워크 분할을 허용해야 하는 무허가 시스템이므로 이 세 가지를 모두 달성할 수 없습니다. 이더리움은 네트워크가 계속 작동하도록 보장하기 위해 심각한 장애 발생 시 일관성을 희생하는 방식을 택했습니다.

1.2 정당성: 비활동으로 인한 손실

이더리움은 비활성 누출 메커니즘을 통해 이러한 선택을 공식화했습니다. 이더리움의 Gasper 사양에 명시된 바와 같이, 비활성 누출은 체인이 4 에포크 이상 최종화되지 못할 때 활성화됩니다. 활성화되면, 다수 포크의 유효성 여부와 관계없이 다수 포크를 검증하지 않는 검증자에게 점진적으로 불이익을 줍니다. 32 ETH를 보유한 검증자가 시스템에서 퇴출되는 데는 4986 에포크, 즉 3주가 걸립니다.

이 프로토콜의 논리는 일시적인 네트워크 가용성이 영구적인 안전성보다 낫다는 것 입니다. 만약 네트워크 분할이 발생하고 검증자 대다수가 한쪽에 몰리면, 비활성 상태 유지로 인해 해당 측은 결국 최종 확정을 하고 네트워크를 복구할 수 있습니다. 반대편의 소수 검증자는 불이익을 받겠지만, 사회적 합의(하드 포크)를 통해 결국 복구하여 네트워크에 다시 참여할 수 있습니다.

2. 홀레스키 사건: 전제가 무너진 상황에서 합의가 실패한 사례 연구

2.1 무슨 일이 일어났는가

2025년 2월 25일, 이더리움 홀스카이 테스트넷에서 펙트라 업그레이드가 활성화되었습니다. 몇 시간 만에 네트워크는 심각한 오류를 겪었습니다. 실행 계층의 주요 클라이언트 세 개(Geth, Nethermind, Besu)가 잘못된 예치 계약 주소로 설정되어 있었던 것입니다. 이로 인해 해당 클라이언트들은 검증자 예치금을 제대로 추적할 수 없었고, 합의 과정에 불일치가 발생했습니다. 결과적으로 실행 계층과 합의 계층이 동기화되지 않게 되었습니다. 대다수의 검증자들은 실행 상태의 오류를 감지하지 못한 채 잘못된 체인의 블록에 대한 인증을 시작했습니다.

결과적으로 복구 불가능한 최종화 실패가 발생했습니다. 네트워크를 복구하기 위해 잘못된 체인에 대해 검증을 수행한 검증자들은 슬래싱 페널티를 받게 되었습니다. 비활성 누출 메커니즘은 올바른 체인이 3분의 2 이상의 압도적인 다수를 되찾을 때까지 오프라인 검증자들의 지분을 서서히 줄여나가야 했는데, 이 과정은 약 3주가 걸렸습니다. 소수 클라이언트(실행 클라이언트 1개)가 계속해서 유효한 블록을 생성했음에도 불구하고, 압도적인 다수 검증자들의 검증으로 인해 올바른 체인에서의 최종화가 이루어지지 못했습니다.

2.2 정직한 다수결 가정 위반

이더리움의 합의 프로토콜은 근본적인 보안 가정인 정직한 다수결 가정을 기반으로 합니다. 캐스퍼 FFG의 최종성 요건은 검증자의 3분의 2가 동일한 체크포인트에 동의하는 것입니다. 활성성(블록 생성)은 포크 선택 규칙을 따르는 단순 다수결에 의존합니다. 이 프로토콜은 검증자의 3분의 1 미만이 비잔틴 검증자(악의적이거나 결함이 있는 검증자)인 한 상태를 정확하게 최종화하도록 설계되었습니다.

홀레스키 사건은 이러한 가정을 뒤집었습니다. 해당 버그로 인해 정직한 검증자들이 네트워크에 대해 적대적인 행동을 하게 되었습니다. 클라이언트 다수는 사실상 비잔틴 제국처럼 행동하며 유효하지 않은 상태에 투표했습니다.

핵심은 이더리움의 안전성이 비잔틴 검증자의 비율이 3분의 1 미만일 때 유지된다는 점 입니다. 세 명의 주요 클라이언트가 모두 동일한 방식으로 장애를 일으키면, 이들은 네트워크의 3분의 1을 훨씬 넘게 되어 안전성이 보장되지 않게 됩니다.

2.3 비활동으로 인한 손실이 파괴적인 이유

네트워크가 포크 상태에 진입하면 복구를 위해 이더리움은 안정성을 희생하고 활성 상태를 유지해야 했습니다. 비활성 누출 메커니즘은 다수결 포크에 동의하지 않는 검증자들의 유효 잔액을 점진적으로 감소시킵니다. 이 과정은 동의하지 않는 검증자들의 잔액이 너무 낮아져 검증자 집합에서 제외될 때까지 계속되며, 그 결과 나머지 (정당한) 검증자들이 전체 잔액의 3분의 2를 확보하게 됩니다.

하지만 이 메커니즘은 여러 면에서 파괴적 입니다.

1. 경제적 손실 : 다수(잘못된) 포크의 검증자는 페널티를 받아 ETH를 영구적으로 잃게 됩니다. 소수(올바른) 포크의 검증자는 활동이 없는 것으로 판단되어 페널티를 받습니다.
2. 포크 위험 : 비활성 상태가 장기간 지속될 경우, 두 파티션 모두 각각 2/3의 지분을 확보하고 독립적인 버전의 기록을 확정할 수 있습니다.
3. 복구 시간 : 전체 과정은 몇 주가 걸렸으며, 그 기간 동안 네트워크는 거래를 완료하거나 사용자 및 애플리케이션에 안정적인 서비스를 제공할 수 없었습니다.

3. DVT PBFT 문제: 단순 정족수 기반 인증이 실패하는 이유

3.1 단순한 DVT 접근법

분산 검증자 기술은 임계값 암호화와 비밀 공유를 사용하여 단일 검증자의 서명 키를 여러 독립적인 운영자에게 분산합니다. 각 운영자는 키 지분을 보유하고 비잔틴 장애 허용(BFT) 합의 메커니즘에 참여하여 어떤 역할을 수행할지 합의합니다.

단순한 DVT 설계에서는 BFT 합의가 특정 조치에 대해 동의에 도달하면 모든 운영자가 서명하고 증명서를 제출합니다. 논리는 간단합니다. BFT 합의가 정족수를 충족하면 해당 결정은 올바른 것입니다 .

하지만 이러한 논리는 우리를 다수결의 함정 에 빠뜨릴 수 있습니다.

3.2 트래핑 속성

비형식적 직관

검증자가 특정 포크의 체크포인트 최종화를 진행하기 위해 투표하면, 해당 시점의 포크에 로컬로 고정 됩니다.

보다 구체적으로, 서로 충돌하는 두 개의 포크 (A)와 (B)가 있고, 포크 (A)가 포크 (B)보다 더 진행되었다고 가정해 보겠습니다. 검증자 (V)가 포크 (A)의 체크포인트 (a)의 최종화에 기여하는 투표 ((s_a, t_a))를 행사하면, 그 순간부터 (V)는 Casper FFG 슬래싱 규칙을 위반하지 않고는 목표 에포크가 (t_a) 이상인 포크 (B)에 대해 어떠한 투표도 할 수 없습니다.

직관적으로, 검증자는 (a)를 최종 확정하기 위한 투표를 통해 (A) 포크에 대한 특정 에포크 간격을 확정합니다. 동일하거나 더 나중 에포크에 체크포인트를 설정하기 위한 투표를 통해 (B) 포크를 "따라잡으려"는 시도는 다음과 같은 결과를 초래할 수 있습니다.

• 동일한 목표 에포크에 대해 이중 투표를 하거나,
• 이전 투표를 둘러싸고,

둘 다 칼로 찌를 수 있는 범죄입니다.

결과적으로, (a)를 최종화하기 위한 투표 후, 검증자는 (B) 포크와 관련하여 갇히게 됩니다. 즉, (B) 포크가 검증자의 잠금 범위를 넘어선 에포크로 정당한 체크포인트를 진행시키지 않는 한, 검증자는 (B) 포크의 최종화에 도움을 줄 수 없습니다. 그때까지 검증자는 갇힘 속성에 위배되지 않고는 (B) 포크의 최종화에 기여할 수 없습니다.

이를 명확히 하기 위해 공식화해 보겠습니다.

캐스퍼 FFG 요약

먼저, 캐스퍼 FFG의 투표 방식에 대해 간략하게 다시 설명드리겠습니다.

각 인증에는 에포크의 정당성을 검증하려는 대상 체크포인트 투표 와 에포크를 확정하려는 소스 체크포인트 투표 가 포함됩니다. 에포크는 대상 투표의 2/3 이상을 획득해야만 정당성을 확보할 수 있습니다. 또한, 이전에 정당성을 확보하고 소스 투표의 2/3 이상을 획득했으며, 바로 위의 에포크에 동일한 인증 세트를 가진 새로운 정당성 체크포인트가 생성된 경우에만 확정될 수 있습니다.

자, 이제 베기 규칙을 다시 정리해 보겠습니다.

(s_a, s_b)는 서로 다른 두 소스 투표를 나타냅니다.
(t_a, t_b)를 서로 다른 두 개의 목표 투표라고 하자.
(h(x))를 임의의 투표 또는 체크포인트의 높이(에포크)라고 합시다.

동일한 검증자가 발행한 경우, 해당 투표는 다음 중 하나에 해당하면 슬래싱 위반으로 간주됩니다.

1. 중복 투표 규칙: (h(t_a) = h(t_b))
2. 주변 투표 규칙: (h(s_b) < h(s_a)) AND (h(t_a) < h(t_b))

캐스퍼 FFG 논문은 이러한 규칙으로부터 다음과 같은 속성을 도출합니다.

(iv) 높이가 (n)인 정당한 검문소는 최대 1개 존재합니다.

트래핑 속성의 형식적 정의

예비 단계

(a, b)를 서로 다른 포크((A) 및 (B))에서 각각 투표((s_a, t_a)) 또는 ((s_b, t_b))를 통해 최종화로 진행할 수 있는 가장 최근의 정당화된 체크포인트라고 하자. 여기서 (h(s_a) = h(a)) 및 (h(b) = h(s_b))이다.

우리는 (h(a) = h(b))인 경우 검증자의 최소 (1/3)이 슬래싱 위반(1)을 저질렀다는 것을 알고 있습니다.

덫 설치

일반성을 잃지 않고, 만약 (h(a) > h(b))이고 (V)가 ((s_a, t_a)) 투표로 (a)를 최종화하기 위해 투표하는 검증자라면, (V)는 슬래싱 위반(포크 진행)을 일으키지 않고는 (h(t_b) \ge h(t_a))를 만족하는 ((s_b, t_b)) 투표를 생성할 수 없습니다.

여기서 이제 (V)는 슬래싱 없이 (B)의 어떤 체크포인트에서도 최종화에 기여할 수 없다는 것을 쉽게 알 수 있습니다.

증거

(V)가 (h(t_b) = h(t_a))를 만족하는 ((s_b, t_b))를 발행하면 이는 이중 투표 규칙을 명백히 위반하는 것입니다. 따라서 분기 (A)를 지나 진행하려면 (V)는 (h(t_b) > h(t_a))를 만족하는 (t_b)를 발행해야 합니다. (b)가 가장 최근에 검증된 체크포인트이므로 (V)는 (s_b)로 투표해야 합니다. (h(s_b) = h(b) < h(a) = h(s_a))가 주어졌으므로 이 투표는 슬래싱 위반에 해당합니다.

3.2 다수결의 함정: 예시 시나리오

시나리오 설정:

• DVT 클러스터에는 (O_1), (O_2), (O_3), (O_4)의 4개 운영자가 있습니다.
• 정족수 요건은 운영자 3명입니다.
• 네트워크에서 (X+1) 에포크에 체인 (A)(네트워크의 다수)와 체인 (B)(소수, 올바른 체인)가 분기되었습니다.
• (A)도 (B)도 체크포인트를 정당화하거나 확정하기 위한 충분한 검증자가 없습니다.
• (라운드 로빈 방식으로 선정된) BFT 리더는 이제 (O_1)입니다.

시나리오:

1. (O_1)은 (A) 체인(다수 포크)에 있습니다.
2. (O_1)은 BFT 리더로서 DVT 클러스터에 다음과 같이 제안합니다. "체인(A)에 대한 증명: 에포크(X)에 소스 투표, 에포크(X+1)에 타겟 투표".
3. (O_2)와 (O_3)는 우연히 체인(B)에 있지만, 제안이 슬래싱 위반을 초래할지 여부만 확인합니다.
4. BFT 합의가 정족수를 달성했습니다: (O_1), (O_2), (O_3)이 체인(A), 블록(X)에 대한 증명을 승인했습니다.
5. 해당 증명서는 DVT 클러스터에서 서명하여 제출합니다.
6. 해당 에포크의 종료 시점에 체인(B)에 대한 체크포인트가 생성되거나 최종화되지 않았습니다.
7. 다음 에포크(O_2)는 BFT 리더이며 DVT 클러스터에 다음을 제안합니다. 체인(B)에서 증명: 에포크(X)에서의 소스 투표 및 에포크(X+2)에서의 타겟 투표.
8. 이는 이중 투표가 아니고 이전 투표를 둘러싸지도 않으므로 슬래싱할 수 없으며, 따라서 승인됩니다.
9. DVT 클러스터는 체인(A)과 체인(B) 사이에서 인증을 순환적으로 수행하여 두 포크 모두에서 보상을 수집합니다. 참고 : 체인의 검증자 수가 적으면 인증 슬롯이 누락될 수 있습니다. 이로 인해 인증을 포함시키기 어려워지므로 이러한 긍정적인 효과가 상쇄될 수 있습니다.
10. 4 에포크 후에 비활성 누출이 두 포크 모두에서 활성화됩니다. 각 체인에 대해 DVT 검증자 비활성 점수는 비활성 에포크마다 (4)만큼 증가하고 활성 에포크마다 (1)만큼 감소합니다.
11. 체인 (A)는 (B)보다 먼저 체크포인트 정당화를 시작합니다. DVT 검증자가 소스 투표를 진행시키면 사실상 (A)에 갇히게 됩니다.
12. DVT 클러스터 비활동 점수는 (B)에서 에포크당 (4)씩 증가하기 시작합니다.
13. 이 시점에서 DVT 클러스터는 다음 경우에만 (A)를 벗어날 수 있습니다.
    a. (A)에 대한 증명을 중단합니다.
    b. (B)의 비활성 누출을 견뎌냈습니다.
    c. 체인(B)은 DVT 목표가 투표한 높이(A)보다 더 높은 높이에 체크포인트를 설치하는 것을 정당화합니다.

결과:

DVT 클러스터는 소수 사업자들이 다수 사업자와 협력하도록 강요합니다.

대다수가 정직하다면 이는 유익한 행동이다.
DVT 검증자는 어떤 체인이 정식 체인이 될지 미리 알 수 없었기 때문에 두 체인 모두에 참여합니다. 2/3 이상의 다수표를 먼저 확보하는 체인을 기반으로 빌드를 진행합니다.

다수가 악의적일 경우 DVT 클러스터는 다수 포크에 갇히게 됩니다. 이후 비활성 누출로 인해 네트워크가 복구되고 체인(B)가 정규 체인이 되면 DVT 클러스터의 검증자들은 모호성으로 인한 슬래싱에 직면하거나 체인(B)를 포기(손실 수용)하게 됩니다.

핵심 쟁점은 DVT 클러스터가 모든 사업자가 동의하지 않는 다수결 포크에 투표하도록 강요받는다는 점입니다 . BFT 합의는 소수 사업자가 다수결 선택을 수용하도록 강제하는 메커니즘이 됩니다.

4. 해결책: 체크포인트 검증 및 클러스터 수준 기권

4.1 체크포인트 검증 소개

다수결 분기 함정을 해결하기 위해 DVT 클러스터는 체크포인트에 대한 증명을 하기 전에 체크포인트 유효성 검사를 구현할 수 있습니다 .

체크포인트 유효성 검사 규칙:

DVT 클러스터가 시점(E)의 체크포인트(C)를 증명하려면 다음과 같습니다.

1. 각 운영자는 에포크 수준의 체크포인트 구조가 유효한지 확인해야 합니다.
2. 각 운영자는 소스의 에포크가 올바른지 독립적으로 검증해야 합니다.
   대상 체크포인트는 로컬 뷰와 일치합니다.
3. 운영자 정족수(예: 2/3)가 동의하면 DVT가 인증합니다.
4. 정족수가 충족되지 않으면 DVT는 인증을 하지 않습니다.

 func shouldSignAttestation (own, proposed Attestation) bool { return own.SourceCheckpoint.Epoch == proposed.SourceCheckpoint.Epoch && own.TargetCheckpoint.Epoch == proposed.TargetCheckpoint.Epoch} 

4.2 증명이 실패할 경우: 기권 메커니즘

핵심 메커니즘은 다음과 같습니다. 운영자 정족수가 에포크 수준 체크포인트 구조에 동의하지 못하면 클러스터는 인증을 수행하지 않습니다 .

개별 검증자는 반드시 검증에 참여해야 하는 반면(그렇지 않을 경우 비활성 페널티를 받음), DVT 클러스터는 선택적으로 참여를 거부 할 수 있습니다. 이는 중요한 장점입니다. DVT 클러스터는 참여를 보장하는 것이 아니라 장애 허용 및 중복성을 위해 설계되었습니다.

DVT 클러스터가 인증을 중단하면 어떻게 되나요?

1. DVT는 비활성으로 표시됩니다.
2. 활동 부족에 대한 벌점이 누적되기 시작하지만, 대폭 삭감되지는 않습니다.
3. DVT는 나중에 올바른 분기점을 증명하는 것으로 다시 전환할 수 있습니다.

5. 네트워크 수준 안전성: 다양화된 DVT가 다수결 포크 확정을 방지하는 방법

5.1 이질성 가정

전체 메커니즘은 중요한 가정에 달려 있습니다. 즉, DVT 클러스터는 이질적이어야 한다는 것입니다 .

모든 DVT 클러스터가 동일한 실행 클라이언트(예: 모두 Geth 사용)를 사용하는 경우, Holesky와 같은 사고 발생 시 모두 동일한 버그에 직면하게 됩니다. 이 경우 모든 클러스터는 동일한 다수 포크에 속하게 되며, BFT 합의를 통해 모두 인증을 강제로 수행해야 합니다. 따라서 DVT는 아무런 보호 기능을 제공하지 못합니다.

하지만 DVT 클러스터가 서로 다른 클라이언트 (일부는 Geth, 일부는 Nethermind, 일부는 Besu)를 사용하는 독립적인 주체에 의해 운영되는 경우 상황은 달라집니다.
포크가 정당화되면 체크포인트 유효성 검사가 작동하여 기권 메커니즘이 활성화됩니다.

5.2 임계점: 다수결 포크 최종 확정 방지

이더리움의 최종성 규칙은 전체 검증자의 3분의 2 이상(66.7%)이 체크포인트에 동의해야 최종 확정됩니다.

이더리움 검증자 중 충분한 비율이 서로 다른 운영자를 가진 검증자(DV)라면 다음과 같은 결과가 나타납니다.

• 다수결에 따른 종속변수(DV)는 (불일치를 감지하면) 기권할 것입니다.
• 다수결 원칙에 따른 분할안은 3분의 2의 동의를 얻지 못하여 최종 확정될 수 없습니다.

예시 계산:
현재 SSV 네트워크 보급률을 기준으로 삼아 보겠습니다.

• 투표 참여율: 14% (최종 결정에 대해 모두 기권).
• 다수결 분기 중에 네트워크의 80%가 (잘못된 방식으로) 다수결 분기로 향한다고 가정해 보겠습니다.
• 기존 검증자: 69%가 다수 포크를, 17%가 소수 포크를 지지합니다.
• 다수결 분기는 DVT의 참여 없이 최종 확정되었습니다 .

하지만 이더리움 검증자의 30%가 서로 다른 운영자를 가진 검증자(DV)라고 가정해 봅시다.

• 70%는 기존 검증자입니다.
• 다수결 분기 중에 네트워크의 90%가 (잘못된 방식으로) 다수결 분기로 향한다고 가정해 봅시다.
• 다양한 운영자가 참여하는 DV의 경우 30%가 기권했습니다.
• 기존 검증자: 63%는 다수 포크를, 7%는 소수 포크를 지지합니다.
• 최종 확정되지 않았습니다 .

5.3 네트워크 안정성 논거

핵심적인 통찰은 다음과 같습니다. 충분히 다양한 DVT 집단이 존재한다면, 그들의 협조 없이는 잘못된 분기를 확정짓기가 어려워집니다 . 이는 자연스러운 종착점을 만들어냅니다.

1. 다수결 포크가 최종화를 시도합니다.
2. 다양한 종속변수들은 불일치를 감지하고 기권한다.
3. 최종화가 차단되어 정규 체인의 분기가 방지됩니다.
4. 네트워크가 최종적인 해결책 없이 "정체"된 상태입니다.
5. 비활성 상태 누출 방지 메커니즘이 작동합니다.
6. 정직한 공동체에게는 협력할 수 있는 시간적 여유가 있습니다.

결정적으로 , 이 결과는 홀레스키 시나리오보다 우월합니다.

• 올바른 체인의 검증자 중 누구도 슬래싱되지 않았습니다.
• 정직한 소수자는 다수의 의견을 정설로 받아들일 필요가 없습니다.
• 사회적 합의는 올바른 회복 경로를 결정할 수 있다.
• 이 일이 발생하기 전까지는 두 포크 모두 계속 활성화된 상태로 유지됩니다.

6. 절충안: 확정 없는 정당화

6.1 DV가 잘못된 분기를 정당화할 수는 있지만 (확정짓지는 못할 수도 있는) 이유

우리가 제안하는 체크포인트 검증 메커니즘은 의도적으로 상태 루트를 검사하지 않습니다 . 이는 근본적인 한계를 초래하는 중요한 설계상의 선택입니다. DVT 클러스터는 최종 분기를 확정할 수는 없지만, 잘못된 분기를 증명하고 정당화할 수 있습니다.

상태 루트 검사가 제외되는 이유:

DVT 운영자 간의 전체 상태 루트를 비교하려면 다음이 필요합니다.

1. 모든 운영자가 정확히 동일한 블록 상태를 처리하고 검증해야 합니다.
2. 주어진 슬롯에서의 전체 실행 계층 상태에 대한 합의
3. 상태 차이가 조금이라도 있는 블록은 모두 거부됩니다.

이는 치명적인 문제를 야기합니다. 네트워크 지연과 블록 전파 지연으로 인해 운영자들이 동일한 시점에 동일한 상태 루트를 갖지 못할 수 있습니다 . 일부 운영자는 다른 운영자보다 약간 먼저 블록 X를 수신할 수 있습니다. 완벽한 상태 루트 일치를 요구한다면 DVT 클러스터는 거의 인증을 수행하지 못하게 되어 지속적인 비활성 페널티가 발생하고 DVT의 경제적 타당성이 떨어지게 됩니다. 이러한 문제는 악의적인 시나리오에서 더욱 악화됩니다.

이 문제를 해결하기 위해 해당 메커니즘은 의도적으로 검증 규칙을 완화합니다. 즉, 전체 실행 상태가 아닌 체크포인트의 에포크 구조만 검증합니다 . 이를 통해 운영자는 에포크 수준의 합의 구조(소스 체크포인트, 대상 체크포인트, 검증된 체크포인트)가 일관적인 한, 현재 HEAD 슬롯에 대한 관점이 약간 다르더라도 검증을 완료할 수 있습니다.

절충점:

이러한 설계 선택은 직접적인 결과를 초래합니다. DVT 클러스터는 상태 루트를 검증하지 않기 때문에 포크의 정당성을 뒷받침하는 데 도움이 될 것입니다 .

분기의 첫 번째 시대 동안:

1. DVT 운영자는 두 가지 다른 갈림길을 봅니다.
2. 에포크 수준의 체크포인트 구조는 각 분기점에서 유효한 것으로 보입니다.
3. BFT 합의는 지도자가 결정한 사항(대부분 다수결)에 대해 쉽게 정족수를 충족하여 승인합니다.

결과:
DV는 에포크 수준의 구조가 표면적으로 올바르다는 이유만으로 잘못된 포크를 정당화 (증명의 3분의 1 이상을 누적)할 수 있습니다. 지속적인 검증 실패를 통해 가용성을 저해하지 않고는 이러한 행위를 막을 수 없습니다.

6.2 이것이 허용되는 이유

DVT 검증자 관점에서 볼 때, 이는 바람직하며 검증자의 인센티브와도 잘 부합합니다.

1. 네트워크 가용성 : 상태 루트 검사를 제외함으로써 DVT 가용성을 유지합니다. DVT 클러스터는 네트워크 분할이나 일시적인 상태 불일치 상황에서도 합의 과정에 계속 참여할 수 있으며, 이는 네트워크 활성에 필수적입니다.
2. 최종 확정은 보호됩니다 . 분산 변수(DV)는 잘못된 포크를 정당화할 수 있지만, 분산 변수가 다양한 설정을 유지하는 한 최종 확정을 하지 않습니다.
3. 가역성 : 정당성 검증 후, DV는 언제든지 불이익 없이 다른 포크로 전환할 수 있으므로, 두 체인 중 어느 쪽에서든 얻을 수 있는 보상을 극대화할 수 있습니다.
4. 비활성 누출 노출 감소 : DV는 정당화 시점까지 각 체인의 클러스터 구성에 비례하여 검증합니다. 더 일찍 중단하면 비활성 누출의 영향을 감수해야 합니다.

7. 다른 검증자들의 딜레마: 슬래싱 vs. 파이널라이제이션 절충

7.1 비 DVT 검증자의 문제점

DVT 클러스터가 다수결 포크를 증명하면 네트워크의 다른 검증자들은 딜레마에 직면하게 됩니다 .

상황:

• DV(다수 포크를 정당화하는) + 기존 검증자 다수 > 66.7%.
• 잘못된 분기가 정당화되면 DV는 다음 에포크에서 참여를 보류합니다.
• 기존 검증자들이 포크를 최종 확정할 수 없더라도, 특정 소스를 지지하는 투표를 함으로써 포크에 휘말릴 수 있습니다 .

결과:
갇힌 검증자들은 올바른 포크를 확정하는 데 도움을 줄 수 없습니다.

7.2 DVT의 기회: 네트워크 복원력 강화를 위한 길

네트워크 보안 관점에서 볼 때 이러한 결과는 최적은 아닙니다 . 하지만 DVT 클러스터는 양쪽 체인 모두에서 검증을 수행하여 자체 비활성 상태 유출 속도를 높이지 않도록 유도됩니다. 대규모 포크로 인한 심각한 피해를 우려하는 검증자들은 선제적인 조치를 통해 위험을 완화할 수 있습니다.

핵심적인 해결책 중 하나는 DVT 클러스터로의 전환입니다. DV의 광범위한 도입은 클라이언트 다양성 문제를 해결할 수도 있습니다. 다양한 운영자 환경에서 DVT 검증기는 여러 클라이언트 구현 전반에 걸쳐 검사를 효과적으로 통합하여 생태계 전체를 강화할 수 있습니다.

8. 심부정맥혈전증(DVT) 다수 확보의 중요성

8.1 핵심 보안 속성

이더리움의 최종성 보장 장치(Casper FFG)는 체크포인트를 승인하고 확정하기 위해 전체 검증자의 3분의 2 이상의 동의를 필요로 합니다. 네트워크의 3분의 1 이상이 다양한 검증자로 구성되어 있다면, 사회적 합의 없이는 어떤 포크도 확정되지 않는다는 보장이 있습니다.

8.2 검증자 함정 해제

정당화 후 기권은 함정을 피하기 때문에, 종속변수는 사회적 합의가 이루어지자마자 올바른 분기점에 대한 증언으로 전환할 수 있다.

선택한 분기점이 잘못된 분기점보다 더 높은 수준에서 타당성을 입증하면, 기존 검증자들은 이제 안전하게 분기점을 전환할 수 있습니다.

DVT 참여자 수가 많을수록 선택된 포크가 더 빨리 확정되고 비활성 상태 누출이 종료됩니다. 이 과정이 충분히 빠르게 진행되면, 갇힌 검증자들은 사회적 합의가 이루어진 직후에 탈출할 수 있게 됩니다.

8.3 실질적인 효과

실제로 이는 다음과 같은 의미입니다.

1. 홀레스키 시나리오 방지 : 홀레스키 기간 동안 검증자의 40%가 다양한 운영자를 가진 검증자였다면, 다수결 포크가 확정되지 않았을 것입니다. 3주간의 비활성 기간으로 인한 손실도 발생하지 않았을 것입니다.
2. 사회적 합의 도출 기간 : 네트워크는 사회적 합의를 통해 해결책을 마련할 시간(며칠에서 몇 주)을 확보합니다. 돌이킬 수 없는 분열은 발생하지 않습니다.

9. 한계 및 가정: 심부정맥혈전증 예방이 실패할 경우

9.1 동질적인 심부정맥혈전증 시나리오

전체 메커니즘은 이기종 DVT 운영자 에 따라 달라집니다. DVT 클러스터가 관련 당사자에 의해 운영되거나 단일 클라이언트 구현만 사용하는 경우 보호 기능이 제한적이거나 전혀 제공되지 않습니다.

9.2 조직적인 운영자 공격

DVT 클러스터의 운영자들이 특정 포크를 중심으로 협력하도록 유도되는 경우(예: 정확성과는 무관한 경제적 이유로 포크 A를 집단적으로 선호하는 경우), 체크포인트 유효성 검사 메커니즘은 이를 방지할 수 없습니다.

DVT의 암호화 보안은 단일 운영자가 검증자 키를 탈취할 수 없도록 보장합니다. 그러나 이는 운영자가 네트워크의 이익을 위해 행동할 것이라는 것을 보장하지는 않습니다. 만약 운영자 쿼럼이 악의적이거나 조직적으로 행동한다면, 클러스터가 모든 포크에 대해 인증을 강요할 수 있습니다.

9.3 고객 초다수 문제

Holesky 업데이트 기간 동안 Geth, Nethermind, Besu 세 가지 실행 클라이언트가 영향을 받았습니다. 이 세 클라이언트가 전체 검증자(솔로 및 DVT 모두 포함)의 66.7% 이상을 차지하는 경우, 이 클라이언트를 사용하는 모든 검증자는 다수 포크를 따르게 됩니다.

9.4 비활동 누수 문제 해결 실패

검증자(DV)는 해당 검증자를 정규 검증자로 간주하는 위원회 운영자 수에 비례하는 빈도로 소수 체인에서 검증을 수행한 후 트랩에 고정됩니다. 그러나 대다수 검증자가 블록을 제안하지 않기 때문에 검증 등록에 지연이 발생할 수 있습니다. 결과적으로 검증자는 성능과 관계없이 비활성 누출 페널티를 받을 수 있습니다.

10. 결론: 탄력적인 합의를 향한 길

이기종 운영자를 사용하는 분산 검증자 기술(DVT)은 혁신적인 솔루션을 제공합니다. 클러스터 수준에서 체크포인트 검증을 구현함으로써 DVT는 다수 포크에서 선택적으로 기권 할 수 있도록 합니다. 일정 수의 검증자가 다양한 DVT를 채택하면 네트워크는 다음과 같은 이점을 얻게 됩니다.

1. 대규모 삭제 작업 없이 잘못된 포크의 최종화를 방지합니다 .
2. 돌이킬 수 없는 분열을 차단하여 사회적 합의 회복 경로를 보존하십시오 .
3. 정직한 커뮤니티가 하드 포크 복구를 조율할 수 있도록 시간과 공간을 제공하십시오 .
4. 프로토콜 수준에서 고객 및 운영자 다양성이 지속될 수 있도록 인센티브를 제공하십시오 .

이 메커니즘은 만능 해결책이 아닙니다. 다음이 필요합니다.

• 충분한 DVT 채택률(검증자의 33.3% 이상).
• 고객 및 운영자 분포가 이질적입니다.
• DVT 운영자들 간에 조직적인 비잔틴식 행동은 없었습니다.

하지만 이러한 가정을 하더라도, 이는 클라이언트 과반수 장애로 인해 네트워크가 제어할 수 없이 분기되는 현 상황에 비해 상당한 개선을 의미합니다.

앞으로 나아가야 할 길은 DVT 도입을 적극적으로 장려하고, 다양한 운영자와 클라이언트의 참여를 보장하며, 체크포인트 검증을 DVT 합의 메커니즘의 표준 요소로 만드는 것입니다. 이더리움이 성숙해짐에 따라 이러한 보호 계층은 장기적인 네트워크 안정성을 위해 점점 더 중요해질 것입니다.