🚀 HIP-1535, Hiero의 크로스체인 연결 방식을 바꾸는 CLPR 제안

HIP-1535는 Linux Foundation 산하의 Hiero 프로젝트에서 제안된 Cross-Ledger Protocol (CLPR)입니다.

이 제안은 Hedera를 포함한 Hiero 네트워크가 다른 블록체인 및 분산원장과 통신하는 방식을 새롭게 설계하는 것을 목표로 합니다.

핵심은 기존 크로스체인 브리지처럼 별도의 검증자 집단을 신뢰하는 대신, 상대 블록체인의 상태(State)를 암호학적으로 검증해 원장 간 메시지를 직접 확인하는 구조입니다.

현재 HIP-1535는 Draft 단계이며, 제안 내용을 누구나 검토하고 의견을 제시할 수 있습니다.

🔗 CLPR이란 무엇인가?

CLPR은 Cross-Ledger Protocol의 약자입니다.

쉽게 말하면 서로 다른 블록체인이나 원장이 상대방의 상태를 확인하고 메시지를 주고받을 수 있도록 만드는 상호운용성 프로토콜입니다.

기존 브리지의 일반적인 구조는 다음과 같습니다.

Hedera → Bridge Validators → Ethereum

Hedera에서 Ethereum으로 정보를 전달할 때 중간의 Bridge Validator Set이 해당 거래를 검증하고 전달하는 방식입니다.

이 경우 사용자는 블록체인 자체뿐만 아니라 브리지 검증자들이 정직하게 작동한다는 것까지 신뢰해야 합니다.

CLPR은 이를 다음과 같이 바꾸는 것을 목표로 합니다.

Hedera → Ethereum State Proof → Ethereum에서 직접 검증

반대 방향에서도:

Ethereum → Hedera State Proof → Hedera에서 직접 검증

즉, 중간의 별도 브리지 검증자 집단을 신뢰하는 대신 수신하는 원장이 상대 원장의 상태 증명을 직접 확인하는 구조입니다.

이를 통해 프로토콜 수준에서 별도의 Bridge Validator Committee나 Wrapped Token에 의존하지 않는 크로스원장 통신을 목표로 합니다.

🛡️ Hedera/Hiero에 중요한 이유

Hedera 생태계에서 이 제안이 주목되는 이유는 Hiero가 사용하는 합의 및 원장 기술의 특성을 크로스원장 통신으로 확장하려는 접근이기 때문입니다.

기존 브리지를 이용하면 Hedera의 자체 합의가 강력하더라도 크로스체인 구간에서는 브리지 검증자라는 새로운 신뢰 계층이 추가될 수 있습니다.

CLPR은 상대 원장이 생성한 State Proof를 직접 검증하는 방식으로 이 문제를 해결하려고 합니다.

특히 HIP-1535는 양쪽 원장이 ABFT Finality를 갖는 경우 해당 Finality 특성을 크로스원장 통신에서도 활용할 수 있는 구조를 제시합니다.

따라서 핵심은 단순히 “Hedera와 다른 체인을 연결한다”가 아니라, Hiero 기반 네트워크의 검증 모델을 다른 원장과의 통신 영역까지 확장하는 것입니다.

📡 CLPR은 토큰 브리지가 아니라 메시징 프로토콜

CLPR에서 중요한 점은 CLPR 자체가 단순한 토큰 브리지라는 것이 아니라는 것입니다.

핵심 기능은 Cross-Ledger Messaging, 즉 서로 다른 원장 사이에서 인증된 메시지를 전달하는 것입니다.

예를 들어 다음과 같은 정보가 전달될 수 있습니다.

• 거래 실행 명령

• 애플리케이션 데이터

• 오라클 정보

• 크로스체인 Swap 명령

•자산 이전 명령

• 스마트컨트랙트 호출

목적지 원장의 실행 결과

따라서 CLPR 위에서 브리지, 크로스체인 Swap, DeFi 및 다양한 상호운용성 애플리케이션을 구축할 수 있는 구조입니다.

쉽게 말하면 CLPR이 자산 자체를 옮기는 서비스라기보다 서로 다른 원장이 서로의 상태를 확인하면서 정보와 실행 명령을 주고받도록 만드는 통신 레이어입니다.

🧩 핵심 기술: Verifier

HIP-1535에서 가장 중요한 구성요소 중 하나가 Verifier입니다.

각 블록체인은 서로 다른 합의와 증명 방식을 사용하기 때문에 CLPR이 모든 블록체인을 하나의 방식으로 처리하는 것이 아닙니다.

대신 각 네트워크에 맞는 Verifier를 사용하는 구조입니다.

예를 들어:

• Ethereum → Ethereum State Proof를 검증하는 Verifier

• QBFT 네트워크 → QBFT Quorum Certificate를 검증하는 Verifier

• CometBFT/Sei → 해당 네트워크의 증명을 검증하는 Verifier

• Hiero → Hiero의 증명을 검증하는 Verifier

따라서 새로운 블록체인을 연결할 경우 해당 블록체인의 증명을 이해하는 새로운 Verifier를 추가하는 방식입니다.

CLPR 전체 프로토콜을 매번 변경하지 않아도 되도록 설계한 것입니다.

🚇 Channel은 원장 사이의 통신 통로

CLPR에서는 Channel이라는 개념을 사용합니다.

쉽게 말하면 두 개의 원장 사이에 만들어지는 전용 통신 경로입니다.

예를 들어:

Hedera ↔ Ethereum

사이에 하나의 Channel을 만들 수 있습니다.

또한 동일한 두 네트워크 사이에서도 서로 다른 검증 기준을 사용하는 Channel을 구성할 수 있습니다.

Ethereum의 경우 Latest, Safe, Finalized와 같은 서로 다른 상태를 기준으로 사용할 수 있습니다.

Channel의 Verifier는 임의로 교체할 수 없도록 설계됩니다.

Verifier를 변경해야 한다면 기존 Channel을 수정하는 것이 아니라:

기존 Channel → 새로운 Channel → Migration → 기존 Channel 종료

방식으로 전환합니다.

이를 통해 기존 Channel이 처음 설정했을 때의 보안 가정을 관리자가 임의로 변경하는 것을 방지합니다.

⚙️ 메시지는 어떻게 이동할까?

CLPR의 기본적인 메시지 흐름은 다음과 같습니다.

먼저 한 원장의 애플리케이션이 다른 원장의 애플리케이션으로 메시지를 전송합니다.

이후 Connector가 목적지에서 필요한 실행 비용을 처리할 수 있도록 승인합니다.

메시지는 순서가 유지되는 형태로 기록되고, Endpoint가 메시지와 함께 해당 원장의 State Proof를 목적지로 전달합니다.

목적지의 CLPR Service는 전달받은 Proof를 검증합니다.

주요 검증에는 다음과 같은 항목이 포함됩니다.

• 암호학적 State Proof

• Replay Protection

• 메시지 순서

• Running Hash

• Trust Anchor

검증이 모두 통과되면 메시지가 대상 애플리케이션에서 실행되고, 결과는 Response Message를 통해 다시 원래 원장으로 전달됩니다.

전체적으로는:

Request → Proof → Verify → Execute → Response → Proof → Return

이라는 구조입니다.

💰 Connector는 경제적 참여자

CLPR에는 Connector라는 경제적 역할도 존재합니다.

Connector는 목적지에서 발생하는 실행 비용을 부담하고 필요한 자금을 유지하면서 크로스원장 메시지 실행을 지원합니다.

또한 일정한 Stake를 제공하고 정상적으로 서비스를 수행하면 수익을 얻는 구조입니다.

반대로 Connector가 메시지를 승인했지만 목적지에서 필요한 비용을 지불하지 못하는 경우에는 Stake가 Slashing될 수 있는 구조가 제안되어 있습니다.

즉, 크로스체인 메시지 전달을 단순한 릴레이 방식이 아니라 경제적 인센티브와 책임이 결합된 구조로 만드는 것입니다.

⚙️ CLPR 전용 토큰은 없습니다

HIP-1535에서 눈에 띄는 부분은 CLPR 자체의 전용 토큰을 만들지 않는다는 것입니다.

대신 각 원장의 Native Token을 사용합니다.

• Hedera → HBAR

• Ethereum → ETH

• 기타 네트워크 → 해당 네트워크의 Native Token

따라서 CLPR 자체가 별도의 토큰 경제나 거버넌스 구조를 만드는 것을 목표로 하지 않습니다.

⚠️ 그렇다고 완전히 Trustless한 것은 아니다

CLPR이 모든 신뢰 요소를 제거하는 것은 아닙니다.

기존 브리지에서 가장 중요한 신뢰 요소 중 하나였던 Bridge Validator Set에 대한 의존성을 제거하는 것이 핵심입니다.

하지만 CLPR에서는 여전히 Verifier의 정확성과 보안성이 중요합니다.

Verifier가 잘못 구현됐거나 손상될 경우 잘못된 State Proof가 승인될 가능성이 있기 때문입니다.

따라서 CLPR의 보안 구조는:

Blockchain Consensus + CLPR + Verifier + 상대 Blockchain + Application

으로 이해하는 것이 적절합니다.

즉, 기존 브리지 검증자에 대한 신뢰를 암호학적 검증으로 대체하려는 것이지, 모든 신뢰 가정을 완전히 없애는 것은 아닙니다.

🔐 Ethereum 연결에서는 Finality 선택이 중요

Ethereum은 Hedera와 동일한 방식의 ABFT Finality를 사용하지 않기 때문에 CLPR에서도 Ethereum의 상태를 어느 수준까지 확정된 것으로 인정할 것인지가 중요합니다.

Latest는 빠르지만 Reorg 위험이 상대적으로 높고, Finalized는 상대적으로 느리지만 더 강한 최종성을 제공합니다.

따라서 고액 거래나 되돌릴 수 없는 작업에서는 Finalized 상태를 검증하는 방식이 더 적합할 수 있습니다.

CLPR이 Ethereum의 합의 구조 자체를 바꾸는 것은 아닙니다.

연결 대상 블록체인이 가진 Finality와 보안 특성을 그대로 고려하는 구조입니다.

👁️ Privacy는 별도로 처리

CLPR 자체는 메시지의 기밀성을 제공하지 않습니다.

CLPR을 통해 전달되는 메시지는 원장에 기록되기 때문에 필요한 경우 애플리케이션이 전송 전에 데이터를 직접 암호화해야 합니다.

HIP-1535는 모든 애플리케이션에 동일한 암호화 및 키 관리 방식을 강제하기보다는, 이러한 부분을 애플리케이션 레이어에서 처리하도록 설계하고 있습니다.

🛡️ Channel 등록과 Commit-Reveal

HIP-1535는 Channel 등록 과정에서 Commit-Reveal 방식도 사용합니다.

Channel ID가 먼저 공개될 경우 다른 사람이 이를 보고 선점할 가능성이 있기 때문입니다.

따라서 먼저 Channel ID와 Public Key 등을 이용한 Hash를 Commit하고, 이후 실제 정보와 서명을 공개하는 Reveal 단계를 거칩니다.

Private Key를 보유하지 않은 공격자가 정상적인 Channel 등록을 완료하기 어렵게 만들어 Channel 등록 과정의 Front-Running 문제를 방지하는 구조입니다.

🌐 HashSphere와 Private Network

HIP-1535의 범위는 퍼블릭 블록체인에만 한정되지 않습니다.

제안에서는 Private/Permissioned Hiero 네트워크인 HashSphere와의 연결도 고려하고 있습니다.

따라서 향후에는:

HashSphere ↔ Hedera

또는

HashSphere ↔ Ethereum

과 같은 형태의 상호운용성도 가능하도록 설계할 수 있습니다.

이는 기업이 자체적인 Permissioned Ledger를 유지하면서도 Hedera나 다른 공개 블록체인과 연결할 수 있는 구조로 활용될 가능성을 보여줍니다.

🚀 HIP-1535가 의미하는 것

HIP-1535를 단순히 “Hedera의 새로운 브리지”라고 보는 것은 정확하지 않습니다.

이 제안은 Hiero 네트워크가 다른 블록체인과 통신할 때 브리지 검증자에 의존하는 방식을 줄이고, 각 원장이 상대방의 상태를 암호학적으로 검증할 수 있는 공통 프로토콜을 만드는 것에 더 가깝습니다.

구조적으로 보면:

Hiero Network → CLPR → Ethereum · EVM Networks · QBFT · CometBFT/Sei · HashSphere 등

으로 확장할 수 있는 구조입니다.

핵심 구성요소는:

• Cryptographic State Proof

• Pluggable Verifier

• Channel

• Economic Connector

• Ordered Messaging

입니다.

결국 HIP-1535가 제안하는 것은 특정 브리지 하나를 추가하는 것이 아니라, Hiero 생태계가 서로 다른 원장과 직접 검증 가능한 방식으로 메시지를 주고받을 수 있도록 하는 공통 상호운용성 레이어입니다.