검열 저항을 프로토콜에 포함: 이더리움 트랜잭션의 온체인 여부를 누가 결정하는가?

글쓴이: imToken

블록체인 세계에서 우리는 '검열 저항'이라는 말을 자주 듣습니다.

많은 사람들이 처음 들었을 때 다소 정치적인, 심지어 무정부주의적인 색채가 느껴지는 구호처럼 들릴 수 있습니다. 하지만 이더리움처럼 전 세계 사용자에게 개방된 결제 네트워크의 경우, 검열 저항은 무엇보다 정치적 입장이 아니라 아주 구체적인 기술적 역량입니다.

상상해 보세요. 여러분이 imToken 지갑에서 트랜잭션을 전송했습니다.

서명이 올바르고, 계좌 잔액도 충분하며, 가스비도 적지 않은데도 트랜잭션이 좀처럼 블록에 포함되지 않고 지갑 상태가 계속 'Pending'으로 표시됩니다. 그와 동시에 비슷하거나 더 낮은 수수료의 다른 트랜잭션들은 계속해서 체인에 올라가고 있습니다.

이때의 문제는 결국 누가 트랜잭션이 블록에 들어갈 수 있는지 결정할 권한을 가지느냐는 것입니다. 왜냐하면 만약 이더리움이 결국 소수의 중앙화된 참여자들이 어떤 트랜잭션을 체인에 올릴지 결정해야 하는 구조라면, 전통 금융 시스템과 본질적으로 다를 바가 없기 때문입니다.

따라서 이더리움은 최근 몇 년간 FOCIL, FairFIL 등 일련의 검열 저항 메커니즘을 모색해 왔는데, 이는 겉보기에는 단순하지만 실제로는 매우 중요한 질문, 즉 '프로토콜 규칙을 준수하는 모든 트랜잭션이 블록에 공정하게 포함될 기회를 어떻게 보장할 수 있는가?'에 답하기 위한 것입니다.

1. '검열'은 도대체 어디서 오는가?

이더리움이 왜 이런 메커니즘을 필요로 하는지 이해하려면, 먼저 트랜잭션이 지갑에서 전송된 후 어떤 과정을 거치는지 명확히 알아야 합니다.

사용자가 지갑에서 트랜잭션에 서명하고 전송하면, 이 트랜잭션은 일반적으로 먼저 이더리움의 공개 트랜잭션 풀, 즉 멤풀(Mempool)로 들어갑니다. 이곳은 아직 블록에 포함되지 않은 많은 트랜잭션들이 머무는 대기 공간과 같습니다.

하지만 대기 공간에 들어갔다고 해서 체인에 올라간 것은 아닙니다. 누군가가 트랜잭션들을 골라 순서를 정하고 하나의 완전한 블록을 구성한 다음, 네트워크에 제출해 승인을 받아야 합니다.

바로 이 단계에서 문제가 발생합니다.

이더리움이 PoS(지분 증명) 메커니즘으로 업그레이드한 후, 대형 스테이킹 풀이 MEV(최대 추출 가능 가치)를 이용해 경제적 독점을 형성하는 것을 막기 위해 PBS(Proposer-Builder Separation, 제안자-빌더 분리) 체계를 도입했습니다. 이 구조에서는 각 이더리움 트랜잭션의 처리 흐름이 실제로 두 역할로 분리됩니다:

빌더(Builder): 트랜잭션을 수집하고 순서를 배열하며, 차익 거래 및 청산 기회를 찾아 가능한 한 높은 수익의 블록을 구성합니다.
제안자(Proposer): 빌더가 제출한 후보 블록 중 하나를 선택하여 네트워크에 제출합니다.

이러한 역할 분담에는 분명한 실질적 이점이 있습니다.

잘 알려져 있듯이 최근 몇 년간 MEV 전략은 점점 더 복잡해졌습니다. 만약 모든 일반 검증자가 트랜잭션 순서 정리와 블록 최적화를 독립적으로 수행해야 한다면, 더 많은 자금과 데이터, 기술 역량을 갖춘 대형 노드가 당연히 우위를 점하게 될 것입니다.

따라서 복잡한 블록 구축 작업을 전문 빌더에게 맡기면, 고급 차익 거래 능력이 없는 일반 검증 노드도 블록 제안에 참여하고 그에 상응하는 보상을 얻을 수 있어, MEV가 스테이킹 탈중앙화에 미치는 충격을 완화할 수 있습니다.

그러나 이는 의도치 않게 또 다른 부작용, 즉 블록 구축 권한의 과도한 집중을 초래했습니다. 예를 들어 현재 네트워크 전체 이더리움 블록의 90% 이상이 소수의 전문 빌더에 의해 생성되며, 이 빌더들은 보통 명확한 사업적 배경을 가지고 있어 특정 국가나 지역의 법규 준수(예: OFAC 제재 목록) 등 외부 압력에 노출되기 쉬워 사실상 중앙화 위험을 형성하고 있습니다.

바로 그 때문에 이 몇몇 주류 빌더가 Tornado Cash 같은 특정 민감 계약이나 특정 주소의 트랜잭션을 선택적으로 걸러내기 시작하면, 해당 트랜잭션들은 오랜 시간 블록에 포함되지 못하고 사실상 '암묵적 차단'의 위험에 직면하게 됩니다.

요컨대 일반 사용자 관점에서 이더리움은 누구나 연결하고 송금하며 스마트 계약을 호출할 수 있는 개방형 네트워크이지만, 프로토콜 작동 측면에서 보면 트랜잭션을 보내는 것은 첫 단계일 뿐, 실제로 유효화되기 위해서는 어떤 블록 빌더가 해당 트랜잭션을 선택하고, 순서를 지정하여 블록에 포함시켜야 합니다.

따라서 이더리움이 논의하는 '검열 저항'은 정치나 규제, 제재와 관련된 거대한 개념만이 아니며, 무엇보다 아주 구체적인 기술적 문제입니다:

프로토콜 규칙을 충족하는 트랜잭션이 있을 때, 네트워크는 그것이 합리적인 시간 내에 블록에 포함될 기회를 얻을 수 있도록 보장할 수 있는가?

2. FOCIL에서 FairFIL까지: 이더리움이 블록 빌더를 제한하는 방법

사실 여기까지 오면 문제는 이미 분명합니다. 빌더는 블록 구축 효율을 높일 수 있지만, 트랜잭션 포함 권한이 소수 빌더에게 장기간 집중된다면 이더리움은 다시 새로운 중앙화 독점 위험에 직면하게 됩니다.

이에 이더리움 연구자들은 '포함 목록(Inclusion Lists)'을 제안했습니다.

이름이 다소 추상적으로 들릴 수 있지만, 핵심 논리는 복잡하지 않습니다. 빌더는 여전히 블록을 만드는 역할을 하지만, 모든 트랜잭션의 포함 여부를 독단적으로 결정할 수 없으며, 이더리움 스테이킹에 정상적으로 참여하는 검증 노드들도 반드시 처리되어야 할 일부 트랜잭션을 나열할 수 있는 권한을 일부 보유해야 합니다.

버스 정류장에 비유하자면, 블록은 좌석 수가 제한된 버스 한 대로 생각할 수 있습니다.

빌더는 대부분의 승객이 어떻게 줄을 서고 어디에 앉을지를 결정하여 더 효율적인 배치로 전체 버스의 수익을 높입니다. 그러나 검증 노드는 '반드시 탑승해야 할 명단'을 제출할 수 있으며, 해당 명단의 트랜잭션이 여전히 유효하고 합리적인 수수료를 지불하며 블록에 충분한 공간이 있다면, 빌더는 자신의 선호만으로 계속해서 이들을 탑승 거부할 수 없습니다.

하지만 포함 목록을 누가 작성할 것인지, 그리고 누군가 고의로 트랜잭션을 누락시킨다면 어떻게 대처할 것인지는 여전히 해결해야 할 두 가지 문제로 남아 있습니다.

FOCIL과 FairFIL은 바로 이 두 방향을 따라 전개됩니다.

1. FOCIL: 더 이상 한 명의 제안자가 혼자 포함 목록을 만들지 않도록

FOCIL(Fork-Choice Enforced Inclusion Lists)은 트랜잭션이 반드시 포함되어야 하는지 결정하는 권한을 단일 제안자에서 다수의 검증 노드로 구성된 '검증 노드 위원회'로 이전합니다.

각 블록 생성 주기마다 네트워크는 무작위로 검증 노드 그룹을 선출하여 임시 위원회를 구성합니다. 위원회의 각 구성원은 네트워크 멤풀을 독립적으로 관찰하고, 각자의 로컬 포함 목록을 제출합니다.

이는 설령 네트워크 전체 빌더와 제안자 중 99%가 특정 트랜잭션을 검열하려고 시도해도, 위원회 내에 단 한 명의 정직한 노드가 해당 트랜잭션을 목록에 포함시키면, 이 트랜잭션은 프로토콜의 강제력을 받을 기회를 얻게 된다는 뜻입니다. 검열하려는 측이 계속해서 이를 배제하려면 이제는 한 명이 아니라 여러 독립적인 참여자를 동시에 우회해야 합니다.

따라서 이 방식의 장점은 위원회의 모든 구성원이 중립적일 것이라고 믿을 필요가 없다는 점입니다.

하지만 명단만으로는 충분하지 않습니다. 빌더가 명단을 받고도 계속 실행하지 않는다면, 포함 목록은 구속력 없는 권고에 그치고 말 것입니다.

그래서 FOCIL은 두 번째 계층의 설계를 추가하여, 포크 선택 규칙(Fork-Choice Rule)을 도입해 강제력을 부여합니다. 이를 통해 네트워크 전체에서 투표 검증을 담당하는 노드들이 빌더가 제출한 블록을 엄격하게 확인하게 하며, 빌더가 위원회의 통합 포함 목록을 위반한 것이 발견되면 네트워크는 곧바로 해당 블록에 대한 투표를 거부합니다.

이는 규칙을 위반한 블록이 프로토콜에 의해 즉시 무효 블록으로 판정되며, 빌더는 블록 생성 실패에 따른 막대한 대가를 치르게 된다는 의미입니다.

2. FairFIL: 누락을 막을 뿐만 아니라, 누락을 검증 가능하게 만들기

FOCIL이 합의 규칙 차원에서 검열을 강제적으로 금지하는 것이라면, FairFIL(Fair Forward Inclusion Lists)과 책임 추궁 가능 메커니즘은 경제학적 관점에서 검열 행위를 극도로 비싸고 지속 불가능하게 만듭니다.

간단히 말해, 이 방식은 한 걸음 더 나아가 트랜잭션이 왜 블록에 포함되지 않았는지에 대해 가능한 한 공개적으로 확인할 수 있는 기록을 남겨야 한다는 요구를 제시합니다.

실제 네트워크 운영에서 빌더는 트랜잭션 순서 최적화와 MEV 차익 거래를 위해 아주 짧은 완충 기간이 필요할 수 있습니다. FairFIL은 빌더가 특정 제약 조건 내에서 유연하게 조정할 수 있도록 허용하지만, 빌더가 특정 검열 행위를 다음 블록까지 이어가려고 하면 프로토콜이 즉시 책임 추궁 절차를 개시합니다.

그 대략적인 논리는 세 단계로 이해할 수 있습니다.

먼저, 프로토콜은 공개되고 검증 가능한 참조 규칙을 설정하여, 정상적인 상황에서 현재 블록에 포함될 자격이 있는 공공 거래 풀의 거래들을 판별합니다. 만약 참조 규칙에 따라 원래 블록에 포함될 자격이 있었음에도 최종적으로 처리되지 않은 거래가 있다면, Builder는 이를 공개적으로 FairFIL에 포함시켜야 합니다;
이후 검증자는 이 목록이 완전한지 확인하며, Builder가 자격이 있는 거래를 분명히 누락하고 목록에 기재하지 않았다면, 이 행위가 발각될 수 있고 해당 검증 노드가 이 블록을 지지할지 여부에 영향을 미칩니다;
마지막으로, FairFIL에 포함된 유효한 거래는 이후 블록에서 우선적으로 처리해야 할 작업이 되며, 다음 Builder는 이 거래들을 블록 내 특정 위치에 배치할 수는 있지만, 계속해서 보지 못한 척할 수는 없습니다;

만약 거래가 지속적으로 누락되면 해당 블록은 검증자의 지지를 잃을 수 있으며, 빌더는 이로 인해 블록 전체의 수익을 잃을 수도 있습니다.

즉, FairFIL이 강조하는 '책임 추궁 가능성'은 사실 단계적 경제적 페널티를 도입하여, 지속적으로 거래를 검열하는 빌더가 블록 보상 전체를 박탈당하거나 나아가 스테이킹 예치금이 몰수될 위험에 직면하게 하는 것입니다.

이는 이더리움의 검열 저항 메커니즘이 점차 심화되는 방향이기도 하며, 더 현실적인 제약을 구축하는 것을 목표로 합니다. 소수의 참여자가 검열 의도를 가지고 있더라도 장기간 거래 진입로를 통제하기 어렵고, 누군가 고의로 거래를 누락시키더라도 흔적을 남겨야 하며 지속적인 검열에 대해 점점 더 높은 대가를 치르게 됩니다.

3. 이것이 일반 사용자에게 의미하는 바는?

매일 지갑을 통해 송금, 스왑 또는 DeFi를 이용하는 일반 사용자에게 이러한 기반 메커니즘은 향후 도입되더라도 기존의 작업 습관을 바꿀 필요가 없습니다.

사용자는 여전히 지갑에서 금액을 입력하고, 가스를 확인하고, 서명을 완료한 다음 트랜잭션이 체인에 올라가기를 기다리지만, 눈에 보이지 않는 프로토콜 하부에서는 거래가 블록에 포함될 수 있는지 여부의 로직이 크게 달라질 수 있습니다.

이것이 실제로 개선하는 것은 거래 포함 과정의 확실성입니다.

첫째, 규칙을 준수하는 거래는 더 이상 특정 빌더의 선택에 전적으로 의존하지 않습니다. 현재 빌더가 처리하기를 꺼리더라도 다른 검증자가 포함 목록을 통해 프로토콜 차원의 포함 요구 사항을 설정할 수 있습니다.
둘째, 거래 포함 권한과 거래 정렬 권한이 점차 분리될 수 있습니다. 빌더는 여전히 전문 알고리즘을 활용하여 거래 순서를 정하고 블록 수익을 높일 수 있으며, 차익 거래와 청산을 둘러싼 경쟁도 계속할 수 있지만, '누가 시장에 진입할 자격이 있는지'를 결정하는 권한은 제한될 것입니다.

더 나아가 이더리움의 신뢰할 수 있는 중립성은 참여자의 약속에 의존하는 가치 제안에서 점차 클라이언트에 의해 자동으로 실행되는 프로토콜 규칙으로 변모할 수 있습니다.

사용자는 현재 블록이 어느 빌더에 의해 구축되었는지 알 필요도 없고, 이 빌더들이 자발적으로 중립을 유지할 것이라고 일일이 신뢰할 필요도 없습니다. 검증 노드는 동일한 규칙에 따라 블록을 확인하여 포함 의무를 위반한 블록이 네트워크의 승인을 받기 어렵게 만듭니다.

앞으로 지갑과 블록 탐색기는 이를 바탕으로 더욱 상세한 거래 상태를 제공할 수도 있습니다.

거래는 더 이상 단순히 '처리 중'으로만 표시되지 않고, 그것이 포함 목록에 들어갔는지, 후속 블록에 대한 포함 의무를 획득했는지, 그리고 계속 기다리는 이유가 가스 부족인지, 거래가 이미 무효화되었는지, 아니면 블록 구축 단계에서 이상이 발생했는지까지 사용자에게 알려줄 수 있습니다.

하지만 검열 저항 메커니즘이 모든 거래가 즉시 성공한다는 것을 의미하지는 않습니다.

잔액 부족, 논스 충돌, 가스가 너무 낮거나 컨트랙트 실행 조건이 이미 무효화된 거래는 여전히 블록에 포함되지 못할 수 있습니다. 네트워크가 혼잡하고 블록 공간이 부족할 경우 사용자는 여전히 수수료 경쟁을 통해 확인을 기다려야 합니다.

하지만 이 메커니즘이 주로 개선하는 것은, 원래 유효하고 수수료가 적절하며 공개 트랜잭션 풀에 이미 전파된 거래가 소수 블록 빌더의 주관적인 선택으로 인해 무기한 지연되어서는 안 된다는 점입니다.

진행 상황을 보면, 2026년 8월 현재 FOCIL에 해당하는 EIP-7805는 여전히 Draft 상태이지만, 이더리움 핵심 개발자들에 의해 Hegotá 업그레이드의 합의 레이어 Headliner로 선정되었고 Scheduled for Inclusion 단계에 진입했습니다. 이는 클라이언트 팀들이 이를 중심으로 구현을 추진하고 개발 네트워크 테스트를 진행하기로 합의했음을 의미하지만, 구체적인 메인넷 출시 시기는 아직 최종 확정되지 않았습니다.

FairFIL은 더 초기 단계로, 현재는 2026년 7월에 발표된 연구 제안에 주로 해당하며, 향후 이더리움 로드맵에 포함될지 여부는 더 폭넒은 논의, 구현 및 보안 검증을 거쳐야 합니다.

마치며

객관적으로 말해, 이더리움이 모든 빌더, 검증자 및 인프라 운영자가 항상 중립을 유지할 것이라고 보장할 수는 없습니다.

참여자는 규제 압력을 받을 수도 있고, 자신의 이익을 추구할 수도 있으며, 외부 인센티브를 받을 수도 있습니다. 진정한 회복탄력성을 갖춘 탈중앙화 네트워크는 '모두가 옳은 일을 할 것이다'라는 이상적인 가정 위에 구축될 수 없습니다.

진정한 검열 저항은 일부 참여자가 거래를 방해하려 해도 다른 참여자가 여전히 이 통제를 깨뜨릴 수 있는 능력을 갖추고, 누군가 중립 원칙에서 벗어나기로 선택하더라도 프로토콜이 그 행위를 가시적이고 비용이 많이 들며 지속하기 어렵게 만들 수 있는 것입니다.

초기의 포함 목록에서, 분산 위원회가 공동으로 빌더를 제약하는 FOCIL을 거쳐, 누락 행위를 공개적으로 검증할 수 있도록 요구하는 FairFIL에 이르기까지, 누구든지 거래를 보낼 수 있도록 허용한 데서 나아가 누구의 거래든 볼 수 있는 기회를 보장하는 방향으로 나아가고 있습니다.

이런 관점에서 보면, 이더리움은 확실히 이러한 약속을 가치 선언의 구호에서 한 걸음씩 프로토콜 자체에 새겨 넣으려고 시도하고 있습니다.

기대할 만합니다.