블록체인의 인터넷은 누가 움직이는가

우리는 종종 기술을 마법과 혼동한다. 버튼을 누르면 즉시 다른 대륙으로 돈이 전송되고, 데이터가 마치 공기처럼 자유롭게 흐른다고 믿는다. 블록체인, 특히 수백 개의 체인이 서로 대화하는 인터체인(Interchain)의 비전은 이러한 믿음을 더욱 강화한다. 하지만 이 유려한 시스템의 표면 아래에는, 우리가 애써 외면하는 거대하고 고된 노동의 세계가 존재한다. 데이터는 저절로 흐르지 않는다. 그것은 누군가에 의해 물리적으로, 그리고 막대한 비용을 치르며 배달되어야 한다.

이 화려한 분산 시스템의 무대 뒤편에는, 24시간 잠들지 않고 체인과 체인 사이의 어두운 바다를 항해하는 존재들이 있다. 우리는 그들을 '메신저(Relayer)'라고 부른다. 그들은 이 시스템의 숨은 노동자이며, 이들의 경제학적 인센티브가 무너지는 순간, 우리가 믿었던 인터체인이라는 거대한 신기루도 함께 멈춰 선다. 이들의 역할과 그들이 짊어진 경제적 모순을 이해하는 것은, 이 시스템의 진정한 지속 가능성을 가늠하는 유일한 척도다.

체인 간 통신은 자동이 아니다.

IBC라는 프로토콜을 사용하여 A체인에서 B체인으로 토큰을 전송한다고 상상해 보자. 사용자가 트랜잭션을 승인하는 순간, A체인은 "B체인으로 100 토큰을 보낸다"는 내용의 데이터 패킷을 생성한다. 그리고 이 패킷을 자신의 상태(State), 즉 A체인의 '보낸 편지함'에 저장한다.

여기서 대부분의 사용자는 자신의 일이 끝났다고 생각한다. A체인이 B체인에게 이 사실을 '알려줄' 것이라고 기대한다. 하지만 현실은 다르다. A체인과 B체인은 근본적으로 서로의 존재를 알지 못하는, 고립된 두 개의 우주다. A체인은 B체인에게 직접 말을 걸 수 있는 전화선도, 인터넷 연결도 가지고 있지 않다. A체인이 할 수 있는 유일한 일은 "나는 이런 편지를 보낼 준비가 되었다"라고 자신의 장부에 기록하는 것뿐이다.

B체인은 A체인의 '보낸 편지함'에 무슨 일이 일어났는지 전혀 알지 못한다. 이 편지는 저절로 B체인으로 날아가지 않는다. 누군가 A체인의 '보낸 편지함'을 확인하고, 그 편지를 복사해서, B체인으로 직접 달려가 '받는 편지함'에 꽂아 넣어야만 한다. 이 물리적인 배달 행위가 없다면, A체인의 패킷은 영원히 '보낸 편지함'에서 썩어갈 것이다.

이것이 인터체인 통신의 가장 큰 오해다. IBC는 마법적인 순간이동 기술이 아니라, 두 개의 고립된 데이터베이스 간에 데이터를 '안전하게 복사'할 수 있도록 약속된 표준화된 '규칙'일 뿐이다. 이 규칙을 실제로 실행하고, 두 데이터베이스 사이를 오가며 데이터를 운반하는 존재가 바로 '메신저'다. 그들이 없다면 이 모든 시스템은 개념으로만 존재할 뿐, 실제로 작동하지 않는다.

'메신저'의 역할 정의

메신저는 시스템의 규칙에 묶여 합의에 참여하는 '검증인(Validator)'과는 다르다. 메신저는 블록체인 외부에 존재하는 독립적인 프로그램, 즉 '오프체인(Off-chain) 봇'이다. 누구나 이 봇 소프트웨어를 다운로드하여 자신의 서버에서 24시간 실행할 수 있다.

이 봇의 임무는 지독히도 단순하고 반복적이다.

1. A체인 감시: 메신저는 A체인의 '보낸 편지함'(특정 이벤트 로그)을 강박적으로 끊임없이 확인한다.
2. 패킷 감지 및 복사: A체인이 B체인으로 가는 새로운 데이터 패킷을 생성한 것을 감지하면(예: SendPacket 이벤트), 봇은 이 패킷 데이터를 즉시 복사한다.
3. B체인으로 이동 및 제출: 봇은 즉시 B체인으로 연결을 전환하고, B체인의 가스비를 지불하며 트랜잭션을 제출한다. 이 트랜잭션에는 "A체인이 이 패킷을 보냈다는 것을 증명하는 암호학적 영수증"과 "패킷의 원본 내용"이 포함된다.
4. B체인 감시: B체인은 이 패킷을 받고 처리한 뒤, "패킷 잘 받았다" 또는 "패킷 처리에 실패했다"는 내용의 '영수증(Acknowledgement)'을 자신의 '보낸 편지함'에 저장한다. 봇은 이때 B체인의 '보낸 편지함'을 감시하기 시작한다.
5. A체인으로 복귀 및 제출: 봇이 B체인의 '영수증'을 감지하면, 그것을 복사하여 다시 A체인으로 돌아온다. 그리고 결과를 알리기 위해 A체인의 가스비를 지불하며 트랜잭션을 제출한다.

A체인은 비로소 이 '영수증'을 받고 나서야, 자신이 보낸 패킷이 성공적으로 도착했는지, 아니면 실패했는지(예: 타임아웃)를 인지하게 된다. 이 모든 과정, 즉 A에서 B로의 편도 여행과 B에서 A로의 왕복 여행은 전적으로 이 '오프체인 봇'의 자발적인 노동에 의존한다. 그들은 시스템의 혈관을 순환하며 데이터를 운반하는 적혈구와 같다.

'무신뢰(Trustless)' 설계

여기서 우리는 이 시스템의 가장 아름다운 설계와 마주한다. 만약 이 메신저가 악의를 품는다면 어떻게 될까? A체인이 "100 토큰을 보낸다"는 패킷을 중간에서 가로채 "1,000,000 토큰을 보낸다"고 위조하거나, B체인의 "성공" 영수증을 "실패"로 위조하여 A체인의 시스템을 교란할 수도 있지 않을까?

이것이 IBC가 '신뢰 기반 브릿지(Trusted Bridge)'와 근본적으로 다른 지점이다. 신뢰 기반 브릿지는 중앙화된 운영자(관리자)의 정직함을 '신뢰'해야만 한다. 그들이 해킹당하거나 배신하면 모든 자산이 도난당한다.

하지만 IBC는 '무신뢰(Trustless)'를 기반으로 한다. 메신저가 100% 정직할 것이라고 가정하지 않는다. 그들은 언제든 배신할 수 있는 존재라고 가정한다. 그리고 그 배신이 수학적으로 불가능하도록 시스템을 설계했다.

메신저는 데이터 패킷을 '전달'할 수는 있지만, '위조'할 수는 없다. 그들이 A체인에서 B체인으로 패킷을 전달할 때, 그들은 패킷의 내용만 전달하는 것이 아니라 'A체인이 이 패킷을 보냈음을 증명하는 암호학적 증명(Merkle Proof)'을 함께 전달해야 한다.

B체인은 이 증명서를 받으면, 자신이 이미 알고 있는 A체인의 '공개키(라이트 클라이언트)'와 대조한다. 만약 메신저가 패킷의 내용을 1비트라도 수정했다면(예: 100을 101로), 암호학적 증명은 즉시 깨져버린다. B체인은 이 패킷이 위조되었음을 즉각 감지하고, "이것은 가짜다"라고 선언하며 트랜잭션 전체를 거부한다.

악의적인 메신저는 자신의 배달 시도가 실패하고, B체인에 지불한 가스비만 날리게 된다. 메신저의 역할은 신뢰가 필요한 '공증인'이 아니라, 누구든 대체할 수 있는 '우편 배달부'에 불과하다. 이 설계 덕분에 우리는 메신저의 정직함이 아닌, 오직 암호학과 수학의 정직함만을 신뢰하면 된다.

라이트 클라이언트(Light Client) 검증

이 '무신뢰' 설계를 가능하게 하는 기술적 핵심이 바로 '라이트 클라이언트(Light Client)'다. A체인과 B체인이 서로 통신을 시작할 때, 그들은 먼저 서로의 '라이트 클라이언트'를 교환하여 자신의 장부(State) 내부에 저장한다.

라이트 클라이언트는 상대방 체인의 모든 거래 내역(수백 기가바이트)을 저장하는 '풀 노드(Full Node)'가 아니다. 그것은 상대방 체인의 '블록 헤더(Block Header)' 정보만을 추적하는 가벼운 사본이다. 블록 헤더는 신문의 1면 헤드라인과 같다. 그 안에는 해당 블록에 포함된 모든 거래 내역을 암호학적으로 요약한 '지문(Merkle Root)'과, 이 지문이 유효하다고 서명한 검증인들의 '서명 목록'이 들어있다.

메신저가 A체인의 패킷을 B체인으로 가져올 때의 검증 과정은 다음과 같다.

1. 메신저 제출: "여기 A체인의 300번 블록에 포함된 '100 토큰 전송' 패킷과, 이 패킷이 300번 블록의 '지문'에 포함된다는 '암호학적 증명(Merkle Proof)'입니다."
2. B체인 검증: B체인은 자신이 이미 가지고 있던 A체인의 '라이트 클라이언트(헤드라인 모음집)'를 확인한다. "A체인의 300번 블록 헤더가 내 장부에 있는가? 그 헤더의 '지문'이 메신저가 제시한 증명과 일치하는가? 그 헤더가 A체인 검증인의 3분의 2 이상에게 유효한 서명을 받았는가?"
3. 판단: 이 모든 것이 수학적으로 일치하면, B체인은 이 패킷이 위조되지 않은 '진짜' 패킷이라고 100% 확신하고 수락한다. 만약 하나라도 틀리면, 그 자리에서 패킷을 거부한다.

이 과정에서 메신저의 '신뢰'는 단 1%도 개입되지 않는다. 오직 A체인의 검증인들이 서명한 '헤드라인(블록 헤더)'과, 메신저가 가져온 '증명(Merkle Proof)' 사이의 수학적 검증만이 존재할 뿐이다.

인센티브의 문제. "누가 비용을 내는가?"

이제 우리는 이 아름다운 기술적 설계 이면에 숨겨진, 가장 민감하고 현실적인 문제, 즉 '돈'의 문제에 도달했다. 메신저는 자원봉사자가 아니다. 그들은 이 모든 과정을 수행하기 위해 자신의 서버 비용과 막대한 '가스비'를 지불한다.

메신저는 A체인에서 B체인으로 패킷을 전달할 때 B체인의 가스비를 내야 하고, B체인의 영수증을 다시 A체인으로 전달할 때 A체인의 가스비를 내야 한다. 이들은 양방향으로 돈을 쓰고 있다. 그렇다면 이들은 이 비용을 어떻게 회수하는가?

놀랍게도, 표준 IBC 프로토콜에는 이들의 노동에 대해 보상하는 기능이 기본적으로 탑재되어 있지 않다. 이것은 의도된 설계였다. IBC는 '규칙'일 뿐, '비즈니스 모델'이 아니기 때문이다. 릴레이어들은 차익 거래(Arbitrage) 기회를 포착하거나, 혹은 자신이 속한 생태계(예: 특정 디파이)의 유지를 위해 이 비용을 자발적으로 지불할 것이라 가정된 부분도 있다.

그러나 이 가정은 시스템이 복잡해지면서 치명적인 결함을 드러냈다. 예를 들어 '가스 그리핑(Gas Griefing)' 공격이 바로 이 지점을 파고든다.

과거 어떤 체인에는 특정 콜백(Callback) 기능에, 사용자가 패킷을 보낼 때 패킷의 특정 필드에 "영수증이 돌아오면 이 스마트 컨트랙트를 실행해줘"라는 '콜백(Callback)'을 예약할 수 있는 기능을 넣어둔 경우도 있었다. 문제는 이 콜백을 실행하는 데 드는 가스비를, 콜백을 예약한 '사용자'가 아니라, 그 영수증을 배달한 '메신저'가 지불하도록 설계했다는 점이다. 해커가 만약 무의미한 연산으로 가스를 소모하게 하는 악성 컨트랙트를 콜백으로 지정하면 어떻게 될까?

릴레이어는 이 트랜잭션을 네트워크에 전송한다. 그리고 이 트랜잭션을 처리하는 대가로 수익 0원(또는 소액의 기본 수수료)을 받고, 비용으로 모든 보유 가스를 소모한다. 즉각적인 파산이다.

이것은 메신저라는 '우편 배달부'에게 편지(패킷)를 배달시켰더니, 답장(영수증)이 열자마자 폭발(콜백 실행)하여 배달부의 오토바이(가스 잔액)를 통째로 태워버리는 것과 같다. 이런 일이 반복되고 소문이 퍼지면 배달부가 감소하고 시스템은 마비될 것이다.

'선불 수수료(Fee Middleware)' 모델의 필요성

이 근본적인 경제적 결함을 해결하기 위해 뒤늦게 제안된 표준이 바로 '선불 수수료 미들웨어(Fee Middleware)'다. 이것은 선택적 모듈이지만, 사실상 현대의 모든 인터체인 시스템에 필수적이어야 한다.

이 모델의 철학은 간단하다. "노동을 요청한 자가 비용을 지불하라." 즉, '발신자 부담 원칙'이다.

선불 수수료 미들웨어가 적용된 채널에서, 사용자가 A체인에서 패킷을 보낼 때, 패킷의 내용뿐만 아니라 이 패킷을 처리하는 데 필요한 두 가지 비용을 '선불'로 예치해야 한다.

1. A체인에서 작업할 때 필요한 가스비.
2. B체인에서 작업할 때 필요한 가스비.

이 두 비용은 A체인의 특정 에스크로 계정에 잠기게 된다. 이제 메신저는 위험 부담 없이 일할 수 있다.

• 메신저가 B체인에 트랜젝션을 제출하면, B체인은 A체인의 에스크로 계정에 잠긴 가스비를 메신저에게 보상으로 지급한다.
• 메신저가 A체인에 트랜젝션를 제출하면, A체인은 에스크로에 남은 가스비를 메신저에게 지급한다.

이 모델은 일반적으로 우려되는 가스 그리핑 공격을 적절하게 방어한다. 만약 해커가 990만 가스를 소모하는 악성 콜백을 예약하려면, 패킷을 보낼 최소 990만 가스 이상을 '선불'로 예치해야 한다. 메신저는 나중에 이 악성 콜백을 실행하며 990만 가스를 소모하지만, 동시에 해커가 예치한 990만 가스를 보상으로 받는다. 손해가 0이다. 해커는 자신의 돈으로 쓸모없는 연산을 수행하고, 릴레이어에게는 수수료를 지불하는 셈이 된다. 공격의 인센티브가 완전히 사라진다.

결국, 인터체인이라는 거대한 비전을 지탱하는 것은 화려한 암호학이나 기술이 아니다. 그것은 데이터를 배달하는 '메신저'라는 숨은 노동자들의 지극히 평범한 경제 활동이다. 그들의 노동에 정당한 대가를 지불하고, 그들의 비용을 시스템이 보호하지 않는 한, 이 모든 기술은 언제든 멈춰 설 수 있는 모래 위의 성에 불과하다.

3줄 요약

1. IBC 통신은 자동이 아니며, '메신저(Relayer)'라는 오프체인 봇이 가스비를 지불하며 체인 간 데이터 패킷과 영수증을 물리적으로 전달해야만 작동한다.
2. 이 시스템은 '무신뢰' 기반으로, 메신저가 패킷을 위조할 수 없도록 '라이트 클라이언트'가 암호학적 증명을 수학적으로 검증한다.
3. 표준 IBC는 릴레이어 보상이 없어 '가스 그리핑' 공격에 취약하며, '선불 수수료 미들웨어'(Fee Middleware)를 통해 발신자가 비용을 지불해야만 경제적 지속 가능성이 보장된다.