이더리움은 왜 멈추지 않는 체인을 선택했나

장애를 없애는 대신, 장애 속에서도 복구되는 네트워크를 설계하다

블록체인 네트워크의 안정성을 말할 때 흔히 떠올리는 기준은 “문제가 발생하지 않는가”이다. 그러나 이더리움의 합의 설계는 조금 다른 질문에서 출발한다. 문제는 언젠가 반드시 발생한다고 보고, 그때 네트워크가 어떻게 반응해야 하는지를 먼저 묻는다.

노드는 오프라인이 될 수 있다. 클라이언트 소프트웨어에는 버그가 생길 수 있다. 인터넷 연결은 끊길 수 있고, 클라우드 인프라는 장애를 일으킬 수 있다. 검증자들이 동시에 참여하지 못하는 상황도 일어날 수 있다. 이더리움은 이런 사건을 예외가 아니라 현실적인 운영 환경의 일부로 받아들인다.

중요한 것은 완전무결한 상태를 가정하는 것이 아니다. 장애가 발생해도 체인이 계속 움직이고, 시간이 지나면 프로토콜이 스스로 정상 상태로 돌아갈 수 있어야 한다. 이더리움 합의 구조의 핵심은 바로 여기에 있다.

체인이 멈추면 애플리케이션도 멈춘다

일부 합의 시스템은 참여율이 일정 기준 아래로 떨어지면 블록 생산을 중단한다. 겉으로 보기에는 안전한 선택처럼 보인다. 잘못된 상태를 확정하는 것보다 잠시 멈추는 편이 낫다고 판단하기 때문이다.

하지만 퍼블릭 블록체인에서 “잠시 멈춤”은 단순한 기술적 정지가 아니다. 기반 체인이 멈추면 그 위에 올라간 애플리케이션도 함께 멈춘다. 디파이에서는 담보 관리, 청산, 오라클 업데이트, 거래 실행이 지연된다. 롤업은 데이터를 게시하거나 증명을 제출하기 어렵다. 브릿지는 다른 체인의 상태를 확인하지 못한다. 사용자는 포지션을 조정할 수 없고, 애플리케이션은 약속한 기능을 수행하지 못한다.

이더리움이 블록 생산을 쉽게 중단하지 않도록 설계된 이유는 이 때문이다. 최종 확정이 잠시 늦어질 수는 있어도, 네트워크의 기본적인 진행 자체는 유지되어야 한다. 애플리케이션이 체인을 “살아 있다”고 느끼는 가장 직접적인 신호는 새로운 블록이 계속 생성되는지 여부다.

체인이 멈춘 뒤에는 더 큰 문제가 남는다. 누군가 장애 원인을 파악해야 하고, 수정 버전을 배포해야 하며, 운영자와 검증자들이 재시작 시점을 맞춰야 한다. 이 과정은 결국 사람의 조율에 의존한다. 무허가 네트워크가 지향하는 자동성과 독립성은 약해질 수밖에 없다.

이더리움은 네트워크의 생존 능력을 특정 운영자나 개발자 집단의 즉각적인 대응에 맡기지 않으려 한다. 충분한 정직한 검증자가 온라인 상태라면 체인은 계속 앞으로 나아가야 한다. 이것이 이더리움 합의 설계의 출발점이다.

하나의 합의 방식으로 모든 것을 해결할 수는 없다

블록체인 합의에는 오래된 긴장이 있다. 계속 블록을 만들 것인가, 아니면 강한 확정성을 우선할 것인가의 문제다. 비트코인과 같은 최장 체인 방식은 블록을 계속 쌓는 데 강하다. 네트워크 일부가 불안정해도 체인은 성장한다. 대신 특정 블록이 절대 되돌려지지 않는다고 말하기 어렵다. 시간이 지날수록 되돌릴 가능성이 낮아지는 확률적 안정성에 가깝다.

반대로 전통적인 BFT 계열 합의는 강한 확정성을 중시한다. 충분한 참여와 합의가 없으면 확정을 내리지 않는다. 잘못된 결정을 피하는 데 유리하지만, 참여율이 부족하면 시스템이 멈출 수 있다.

이더리움은 이 둘 중 하나만 선택하지 않았다. 블록 생산과 파이널리티를 서로 다른 역할로 나눴다. 하나는 체인이 계속 움직이도록 하는 레이어이고, 다른 하나는 특정 지점의 상태를 되돌리기 어렵게 만드는 레이어다.

현재 이더리움은 블록 생산을 위한 포크 선택 메커니즘과 파이널리티를 위한 Casper FFG 계열 구조를 함께 사용한다. 이를 통해 네트워크는 계속 블록을 만들면서도, 조건이 충족되면 강한 경제적 파이널리티를 제공한다.

핵심은 단순하다. 모든 상황에서 한 가지 합의 규칙이 모든 문제를 해결할 수 없기 때문에, 서로 다른 목적의 장치를 결합한 것이다.

블록 생산 레이어는 네트워크의 심장박동이다

이더리움에서 블록 생산 레이어는 네트워크의 심장박동에 가깝다. 이 레이어의 가장 중요한 임무는 체인을 멈추지 않는 것이다. 이를 위해 이더리움은 모든 검증자가 항상 온라인 상태라고 가정하지 않는다. 검증자는 잠시 꺼질 수 있고, 네트워크 연결을 잃을 수 있으며, 클라이언트 문제로 참여하지 못할 수도 있다. 중요한 조건은 현재 온라인 상태인 검증자 다수가 정직하게 행동하는가다.

이 관점은 현실적인 운영 환경에 맞춰져 있다. 검증자는 노드를 업데이트해야 할 수 있다. 데이터센터 장애가 발생할 수 있다. 특정 인터넷 서비스 제공자의 라우팅 문제가 일부 지역 검증자에게 영향을 줄 수 있다. 특정 클라이언트의 버그가 해당 소프트웨어를 쓰는 검증자들에게 동시에 영향을 줄 수도 있다.

이더리움은 이런 상황에서도 가능한 한 블록 생산을 유지하려 한다. 일부 검증자가 사라졌다고 해서 전체 네트워크가 멈춰서는 안 된다는 철학이다.

이 구조는 사용자 경험에도 직접적인 영향을 준다. 파이널리티가 지연되더라도 블록이 계속 생성되면 거래는 여전히 포함될 수 있고, 애플리케이션은 대부분의 기능을 이어갈 수 있다. 완전한 정상 상태는 아니지만, 완전한 정지와는 다르다.

파이널리티 레이어는 되돌림의 비용을 만든다

블록 생산이 체인의 진행을 담당한다면, 파이널리티 레이어는 체인의 특정 지점을 경제적으로 확정하는 역할을 한다. 이더리움에서 파이널라이즈된 블록을 되돌리는 것은 이론적으로 불가능하지 않다. 그러나 그렇게 하려면 대규모 검증자 집단이 명확히 모순되는 서명을 남겨야 한다. 즉, 단순한 의견 차이가 아니라 암호학적으로 검증 가능한 위반 증거가 생긴다.

여기서 슬래싱이 등장한다. 검증자가 같은 슬롯에서 충돌하는 블록을 제안하거나, 서로 양립할 수 없는 어테스테이션을 제출하면 처벌 대상이 된다. 중요한 점은 프로토콜이 모호한 의도를 처벌하지 않는다는 것이다. 처벌되는 것은 누구나 확인할 수 있는 서명된 모순이다.

이 원칙은 이더리움의 경제적 보안을 지탱한다. 잘못된 파이널리티를 만들려면 누군가 책임을 질 수밖에 없고, 그 책임은 온체인 증거로 드러난다. 파이널리티는 단순한 투표 결과가 아니라, 검증자가 자신의 자본을 걸고 남기는 공개 약속이다.

따라서 이더리움의 파이널리티는 “절대 되돌릴 수 없음”이라는 물리적 의미보다는 “되돌리려면 막대한 경제적 손실을 감수해야 함”에 가깝다. 이것이 경제적 파이널리티다.

참여율이 무너져도 복구 경로는 프로토콜 안에 있다

문제는 검증자 참여율이 크게 낮아졌을 때다. 파이널리티를 위해 필요한 충분한 투표가 모이지 않으면 체인은 최종 확정을 진행할 수 없다. 다른 시스템이라면 여기서 멈추고 운영자들의 대응을 기다릴 수 있다. 하지만 이더리움은 비활성 누출이라는 자동 조정 장치를 둔다.

일정 기간 파이널리티가 달성되지 않으면, 프로토콜은 온라인에서 투표하지 않는 검증자의 유효 지분을 조금씩 줄이기 시작한다. 시간이 지날수록 이 효과는 커진다. 목적은 오프라인 검증자를 벌주는 데만 있지 않다. 실제로 체인에 참여하고 있는 검증자들이 다시 전체 기준에서 충분한 비중을 차지하도록 만드는 데 있다.

쉽게 말해, 네트워크가 “현재 응답하지 않는 지분”의 영향력을 점차 낮춰서, 남아 있는 온라인 검증자들이 다시 파이널리티를 형성할 수 있게 만드는 방식이다.

이 과정은 사람의 재시작 명령을 필요로 하지 않는다. 하드포크를 기다리지도 않는다. 운영자들이 한곳에 모여 복구 시점을 정하지 않아도 된다. 프로토콜 자체가 시간이 지남에 따라 회복 가능한 상태로 균형을 조정한다.

이더리움이 추구하는 복원력은 여기서 잘 드러난다. 장애가 발생하지 않는 네트워크가 아니라, 장애가 발생해도 내부 규칙으로 회복 경로를 갖는 네트워크다.

클라이언트 다양성은 선택 사항이 아니라 보안 조건이다

이더리움 검증자는 하나의 소프트웨어만 사용하지 않는다. 여러 합의 클라이언트가 존재하고, 운영자들은 각자 다른 클라이언트를 선택할 수 있다.

이 다양성은 단순한 취향의 문제가 아니다. 네트워크 보안과 직접 연결된다. 만약 하나의 클라이언트가 전체 스테이크의 3분의 1 이상을 차지한다면, 그 클라이언트의 버그는 파이널리티를 흔들 수 있다. 2분의 1을 넘으면 포크 선택 과정에 큰 영향을 줄 수 있다. 3분의 2를 넘으면 더 위험하다. 해당 클라이언트가 잘못된 상태를 정상으로 판단할 경우, 그 오류가 파이널라이즈될 가능성까지 생긴다.

이 경우 복구는 단순한 기술 문제가 아니다. 어떤 체인이 정당한지, 어떤 서명을 어떻게 처리할지에 대한 사회적 판단이 필요할 수 있다. 이는 이더리움이 피하고자 하는 상황이다.

그래서 클라이언트 다양성은 커뮤니티 캠페인 이상의 의미를 가진다. 특정 소프트웨어 하나가 네트워크 전체의 단일실패 지점이 되지 않도록 만드는 분산 방어 체계다.

검증자 입장에서도 소수 클라이언트를 사용하는 것은 단순한 희생이 아니다. 대형 클라이언트 집단에 치명적 버그가 생기면 같은 소프트웨어를 쓰는 검증자들이 동시에 위험에 노출될 수 있다. 반대로 클라이언트 사용 비중이 고르게 나뉘어 있으면 하나의 버그가 전체 합의를 장악하기 어렵다.

이더리움의 보안 모델은 코드만으로 완성되지 않는다. 다양한 구현체, 다양한 운영자, 다양한 인프라 환경이 함께 만들어내는 구조적 분산성이 중요하다.

검증자가 계속 참여하도록 만드는 경제적 설계

네트워크가 멈추지 않으려면 충분한 검증자가 계속 온라인 상태를 유지해야 한다. 이더리움은 이를 위해 보상과 페널티를 함께 사용한다. 정상적으로 참여하는 검증자는 어테스테이션을 제출하고 보상을 받는다. 블록 제안자로 선정되거나 특정 역할을 맡으면 추가 보상도 받을 수 있다. 반대로 오프라인 상태가 되면 받을 수 있었던 보상을 놓치고, 경우에 따라 작은 페널티도 부담한다.

평상시 오프라인 페널티는 과도하게 가혹하지 않다. 일시적인 장애나 점검을 이유로 검증자가 심각한 손실을 입지 않도록 설계되어 있다. 그러나 파이널리티가 장기간 깨지는 특수 상황에서는 비활성 누출이 작동하면서 페널티가 커진다.

또한 검증자는 원할 경우 정상적인 퇴출 절차를 통해 네트워크를 떠날 수 있다. 프로토콜은 정상적으로 퇴장하는 검증자와, 아무 신호 없이 사라져 네트워크 참여율을 떨어뜨리는 검증자를 구분한다.

이 구조는 검증자에게 명확한 메시지를 준다. 계속 참여하면 보상을 받고, 책임 있는 방식으로 떠나면 불필요한 손실을 피할 수 있다. 그러나 네트워크가 어려운 상황에 놓였을 때 장기간 응답하지 않는 지분은 점차 영향력을 잃는다.

이더리움의 탈중앙화는 운영 방식에 내장돼 있다

이더리움이 말하는 탈중앙화는 단지 많은 사람이 노드를 운영한다는 의미에 그치지 않는다. 더 중요한 것은 네트워크 운영이 특정 주체의 판단과 조율에 의존하지 않도록 설계되어 있다는 점이다.

블록 생산 레이어는 체인을 계속 움직인다. 파이널리티 레이어는 경제적 확정성을 제공한다. 슬래싱은 명확한 위반에 책임을 부여한다. 비활성 누출은 참여율 붕괴 이후에도 자동 복구 경로를 만든다. 클라이언트 다양성은 소프트웨어 버그가 전체 네트워크를 장악하지 못하도록 방어한다. 검증자 인센티브는 장기적인 참여를 유도한다.

이 요소들은 따로 떨어진 기능처럼 보이지만, 실제로는 하나의 방향을 향한다. 네트워크가 특정 회사, 특정 개발팀, 특정 검증자 집단, 특정 클라이언트에 종속되지 않도록 만드는 것이다.

장애는 피할 수 없다. 그러나 장애가 곧 정지를 의미할 필요는 없다. 이더리움 합의 설계의 특징은 문제를 완전히 제거하려는 데 있지 않고, 문제가 생겼을 때도 체인이 계속 움직이며 스스로 정상 상태를 회복하도록 만드는 데 있다.

결국 이더리움이 선택한 길은 “멈추지 않는 완벽한 시스템”이 아니다. 더 정확히 말하면, 불완전한 현실 속에서도 계속 작동하도록 설계된 시스템이다.

그리고 이것이 이더리움 합의 구조가 지향하는 핵심이다. 네트워크는 누군가가 구해주기를 기다리지 않는다. 프로토콜 안에 복구의 논리를 품고, 가능한 한 스스로 문제를 흡수하고 다시 앞으로 나아간다.