Adaptive IBC 이종 체인 크로스 체인 기술 노선 상세 해설
Adaptive IBC 이종 체인 크로스 체인 기술 경로에 대한 상세 설명저자：MiX
Cosmos에서 제안한 IBC 프로토콜은 체인 간 메시지를 검증하기 위해 체인 상의 네이티브 라이트 클라이언트/라이트 클라이언트를 사용합니다. 즉, 크로스 체인 양측 모두 자신의 체인에서 상대 체인에 대한 네이티브 라이트 클라이언트를 유지하여 크로스 체인 데이터의 안전성을 극대화합니다.
Cosmos SDK는 모든 Tendermint 합의 기반 블록체인에 대해 Tendermint 라이트 클라이언트 구현을 제공하므로 Cosmos 체인 간의 크로스 체인 경험은 매끄럽습니다. 하지만 비-Tendermint 합의 블록체인, 즉 이종 체인이라고 불리는 블록체인은 해당 라이트 클라이언트의 구현이 없기 때문에 IBC가 이종 체인으로 확장되는 여정은 매우 어렵습니다.
2023년 12월 17일, 문어 네트워크가 개발한 두 번째 이종 체인 IBC ------ NEAR-IBC가 공식적으로 사용되기 시작했습니다. 프로젝트 개발부터 제3자 감사 및 공식 출시까지의 전체 과정은 1년이 채 되지 않았습니다.이 배후의 공신은 문어 네트워크 팀이 제안한 Adaptive IBC 이종 체인 크로스 체인 기술 노선입니다: IBC 기술 아키텍처의 혁신을 통해 IBC 프로토콜의 이종 체인 크로스 체인 결함을 보완하고 IBC 프로토콜의 적응성을 크게 확장했습니다.
- 다양한 합의 메커니즘을 가진 블록체인이 Adaptive IBC 기술 노선을 채택할 수 있습니다. 예를 들어 Ethereum, NEAR Protocol 및 Polkadot 등이 있습니다.
- 크로스 체인 비용을 크게 줄이고 IBC 프로토콜이 이종 체인으로 확장되는 데 가장 큰 문제를 해결했습니다.
- ZK 기술과 같은 다양한 검증 기술의 발전에 적응할 수 있습니다. 예를 들어 ZK 기술이 성숙해지면 프록시 클라이언트를 ZK 검증기로 쉽게 업그레이드할 수 있습니다.
Adaptive IBC 기술 진화 이정표는 문서 끝의 부록을 참조하십시오.
|IBC 프로토콜의 기본 원리 및 장점
Cosmos 팀이 제안한 IBC(Inter-Blockchain Communication) 프로토콜은 완전 오픈 소스이며 범용적인 블록체인 크로스 체인 상호 운용 프로토콜입니다.
크로스 체인 기술 솔루션의 핵심은 그 "상호 운용 능력"과 "안전성"입니다. IBC 프로토콜의 "계층 구조"와 "오픈 소스 전략"은 IBC가 기능이 풍부하고 신뢰가 필요 없는 크로스 체인 상호 운용을 지원할 수 있게 하여, 당연히 크로스 체인 프로토콜의 황금 기준이 되었습니다.
1. 계층 구조:
IBC는 크로스 체인을 "응용 계층/Application"과 "통신 계층/Channel"로 분리합니다. 그 간결성과 유연성은 블록체인의 TCP/IP 프로토콜에 비유될 수 있으며, IBC 공식 웹사이트에서도 언급하듯이: IBC는 인터넷의 기본 프로토콜인 TCP/IP에서 영감을 받았습니다.
그림 1: IBC는 블록체인의 TCP/IP 프로토콜입니다.
- 응용 계층은 최종 사용자에게 크로스 체인 상호 운용 인터페이스를 제공합니다: 토큰 전송, 체인 간 계좌 및 체인 간 조회 등 여러 독립적인 응용 프로토콜을 포함하며, 이러한 응용 프로토콜은 조합 가능성이 있어 응용 프로토콜이 증가함에 따라 크로스 체인 능력이 기하급수적으로 향상될 수 있습니다.
- 통신 계층은 데이터의 크로스 체인 전송 및 수신을 정의하며, 전송, 검증 및 정렬을 포함하고, 전송 데이터 내용은 보이지 않습니다. 이 중에서, 원체인의 상태 머신 내의 라이트 클라이언트는 통신 계층의 핵심이며, IBC의 정수이기도 합니다.
그림 2: IBC 기술 아키텍처
체인 A는 자신의 상태 머신 내에 체인 B를 나타내는 라이트 클라이언트를 두고, 체인 B도 체인 A의 라이트 클라이언트를 가지고 있습니다. 라이트 클라이언트는 블록 헤더와 머클 증명을 검증하여 상대 블록체인의 합의 데이터를 추적하여 크로스 체인 상호 작용의 합법성을 검증합니다.
크로스 체인 양측 간에는 Relayer가 있어 두 측 블록체인에서 발생하는 이벤트를 모니터링하며, IBC 이벤트를 수신하면 이를 실제 IBC 메시지로 변환하여 상대 체인으로 전달합니다.
간단히 말해, IBC 프로토콜은 먼저 두 블록체인 간의 안전한 통로를 구축한 다음 데이터 패킷을 전달하며, 라이트 클라이언트는 상대 블록체인의 합의 정보를 검증하여 이전의 일관성과 안전성을 보장합니다. 따라서 통신 계층이 구축되기만 하면 전체 IBC의 크로스 체인은 안전합니다.
2. 기술 오픈 소스
누구나 IBC 프로토콜을 사용할 수 있으며, 기여할 수 있습니다. IBC 프로토콜 내에는 수수료나 숨겨진 비용이 없습니다.
크로스 체인 브릿지가 안전 문제를 자주 겪는 이유는 결국 단일 팀의 안전 능력으로는 전체 해커 집단에 맞설 수 없기 때문입니다. 오직 공동의 크로스 체인 오픈 프로토콜을 사용하고, 오픈 커뮤니티의 공동 힘을 통해 지속적으로 반복적으로 업그레이드해야만 전체 산업의 크로스 체인 안전 능력을 지속적으로 진화시킬 수 있습니다. Louis, Octopus Network의 창립자
그림 3: IBC 크로스 체인 데이터
데이터 출처: mapofzones.com
동시에 많은 팀들이 IBC 프로토콜을 다른 생태계로 확장하기 위해 노력하고 있으며, Ethereum, Polkadot, NEAR Protocol, Avalanche, Solana 및 Celestia 롤업을 포함한 이종 체인 간의 크로스 체인 상호 작용을 IBC를 통해 실현하고자 하고 있습니다.
|IBC가 이종 체인으로 확장되는 난점
IBC 프로토콜의 아키텍처는 라이트 클라이언트를 기반으로 하므로 제3자의 검증 서비스를 도입할 필요가 없어 신뢰가 필요 없는 크로스 체인을 구현했습니다. 특히 Cosmos 체인 간에는 안전성, 비용 및 속도의 훌륭한 균형을 이루었지만, 이종 체인으로 확장할 때 많은 팀들이 눈에 띄게 느린 진전을 보이고 있습니다.
IBC 와 Tendermint 합의 메커니즘은 모두 Cosmos 팀이 제안한 것이므로, Cosmos SDK는 설계 초기부터 라이트 클라이언트에 대해 매우 좋은 지원을 제공했습니다.
Cosmos 체인과 비-Cosmos 체인 간에 IBC 프로토콜을 구현하려면, Cosmos 체인에서 상대 비-Cosmos 체인의 라이트 클라이언트를 구현하고, 비-Cosmos 체인에서 Tendermint 라이트 클라이언트를 구현해야 합니다. 이종 체인의 합의 메커니즘이 다르기 때문에 구현 과정에서 많은 호환성 작업이 필요하며, 관련 기술 위험이 도입됩니다.
이로 인해 이종 체인 IBC는 구현 과정에서 많은 기술적 도전에 직면하게 됩니다:
첫째, 이종 체인은 크로스 체인 메시지의 검증이 비용이 높고 계산 자원 제한/gas 제한이 있습니다:
IBC는 크로스 체인 메시지를 검증하기 위해 먼저 블록 헤더를 검증해야 하며, 블록 헤더를 검증하려면 보통 수십 개에서 수백 개의 서명을 검증해야 합니다. 체인에서 스마트 계약을 사용하여 이러한 계산을 수행하는 비용은 매우 높습니다. 한편, Ethereum, NEAR 및 기타 블록체인 모두 스마트 계약의 사용 가능한 계산량에 대해 제한 및 규제를 두고 있습니다. 이로 인해 IBC가 검증할 때 서명 검증 gas가 부족한 문제에 쉽게 직면하게 됩니다.
최근 등장한 제로 지식 증명 크로스 체인은 많은 서명을 하나의 ZK 증명으로 변환하여 ZK 증명을 검증하는 것이 블록 헤더의 모든 서명을 검증하는 것과 동등하게 되어 검증 비용을 절감합니다.
둘째, 체인 상 자산 관리/On-chain Asset Management 메커니즘이 다릅니다.
Cosmos SDK는 프로토콜을 통해 체인 상 자산을 등록하고 조작할 수 있지만, 스마트 계약 블록체인에서는 불가능하며, Fungible Token 데이터는 개별 스마트 계약에 의해 관리됩니다.
셋째, 가상 머신의 샌드박스 제한/Sandbox Limitation
현재의 스마트 계약 블록체인은 모두 가상 머신을 기반으로 하며, 이러한 폐쇄적이고 제어 가능한 환경에서 호스트 체인에 접근할 수 있는 능력이 제한적입니다. 예를 들어, 스마트 계약은 체인 상의 합의 상태를 가져올 수 없으며, NEAR는 비동기 체인이기 때문에 합의 상태 변화가 스마트 계약 호출의 여러 블록에서 발생할 수 있어 더욱 복잡합니다.
넷째, 체인 상 저장/On Chain Storage 데이터의 규칙이 다릅니다.
IBC 프로토콜은 비교적 엄격한 저장 키 값 규칙/Path Rule이 필요하며, 규칙에 따라 생성된 저장 키 값에 대한 암호학적 증명/Proof을 체인에서 가져와야 합니다.
위의 난점 및 그 이상의 차이점으로 인해 개발 팀은 추가적인 엔지니어링 처리를 해야 하며, 이는 복잡성과 버그 위험을 크게 증가시킬 것입니다.
|Adaptive IBC의 원리와 장점
Adaptive IBC 이종 체인 크로스 체인 기술 노선의 핵심은 IBC 프로토콜의 계층 구조를 혁신하여 "검증 계층"을 추가하는 것입니다. 즉, "검증 프록시/Verification Proxy"를 프록시 체인( ICP )에 배치하여 크로스 체인 양측은 "검증 프록시"가 생성한 증명만 검증하면 되고, 상대 체인의 블록 헤더와 모든 서명을 직접 검증할 필요가 없습니다.
그림 4: Adaptive IBC 기반 NEAR-IBC 아키텍처
NEAR-IBC를 예로 들면, 프록시 체인/Proxy Chain에 Cosmos와 NEAR의 검증 프록시가 배치되어 해당 체인의 합의를 유지하고, 크로스 체인 양측에 상대 합의 메커니즘의 프록시 클라이언트를 배치하여 IBC의 원래 라이트 클라이언트를 대체합니다.
Cosmos에서 NEAR로 크로스 체인하는 예를 들면, Cosmos가 NEAR에 메시지를 전달할 때, 프록시 체인上的 Cosmos 검증 프록시/Tendermint Verification Proxy가 크로스 체인 메시지를 검증하고 서명을 생성하여 증명을 만든 다음, NEAR 측의 Cosmos 프록시 클라이언트/Tendermint Proxy Client는 이 증명만 검증하면 크로스 체인 검증을 완료할 수 있습니다.
그림 5: 크로스 체인 기술의 안전성과 확장성
안전성 측면에서, 도입된 검증 프록시는 외부 검증/External Verification 솔루션에 해당하므로 이론적으로 원래 라이트 클라이언트 검증보다 안전성이 약간 낮지만, 원래 라이트 클라이언트 검증에 비해 전체적인 안전성은 크게 감소하지 않았습니다.
Adaptive IBC는 검증 프록시를 공공 체인에 배치할 것을 권장합니다. 예를 들어 NEAR-IBC는 공공 체인 ICP에 배치되어 있으므로, 이러한 방식은 탈중앙화와 공개 검증을 보장할 뿐만 아니라 검증 프록시와 전체 크로스 체인 시스템의 안전성을 보장합니다.
그림 5: 크로스 체인의 안전성에 대한 두 가지 관점
크로스 체인 양측 중 한 체인의 공격 비용/Attacking Cost가 공공 체인 ICP 보다 낮으면, 검증 프록시의 도입은 신뢰 집합/Trust Set이 확대되어도 안전성을 해치지 않습니다. 다중 서명이나 기타 외부 검증 크로스 체인 브릿지에 비해 안전 수준이 훨씬 높습니다.
이로 인해 Adaptive IBC의 검증 프록시 아키텍처는 IBC 프로토콜의 이종 체인 크로스 체인 시나리오에서의 결함을 보완하고, 세 가지 측면에서 IBC 프로토콜의 적응성을 크게 확장했습니다:
크로스 체인 비용을 크게 줄였습니다: 상대 체인의 블록 헤더에 대한 수십 개에서 수백 개의 모든 서명을 검증하는 대신, 검증 프록시의 1개 서명만 검증하면 되므로 IBC 이종 체인 크로스 체인의 최대 고통점인 "검증 비용이 높고 계산 자원 제한이 있다"는 문제를 해결했습니다.
다양한 합의 메커니즘과 호환 가능합니다: 검증 프록시 아키텍처는 크로스 체인 양측 간의 의존성이 없으므로 Ethereum, NEAR Protocol, Polkadot 등 다양한 합의 메커니즘을 가진 블록체인에서 채택할 수 있는 진정한 이종 체인 크로스 체인 기술 솔루션입니다.
검증 기술 발전에 적응할 수 있습니다: Adaptive IBC는 통신 계층에서 "검증 계층"을 추가로 분리하고 검증 프록시 솔루션으로 발전시켰습니다. 계층 구조의 장점 중 하나는 전체 시스템 간의 의존성을 줄이는 것이므로 Adaptive IBC는 다양한 검증 기술의 발전에 적응할 수 있습니다.
Cosmos가 집합 서명을 지원하거나 NEAR가 ED25519 서명의 Precompile을 지원하면 NEAR Protocol에서 직접 검증하는 비용이 크게 줄어들어 프록시 클라이언트를 다시 진정한 라이트 클라이언트로 업그레이드할 수 있습니다.
ZK 크로스 체인 기술이 성숙해지면 검증 프록시를 ZK 증명기로 교체하고 프록시 클라이언트를 ZK 검증기로 업그레이드할 수 있습니다. 커뮤니티 거버넌스를 통해 투표만 하면 원활하게 전환하여 업그레이드할 수 있으며, 응용 계층의 사용 및 기술 진화에 영향을 미치지 않습니다.
Adaptive IBC는 거인의 어깨 위에 서서 "계층 구조"의 장점을 더욱 발전시켜 응용 계층, 통신 계층 및 검증 계층의 3계층 구조를 설계하여 검증 계층이 독립적으로 발전할 수 있도록 하여, 더 많은 블록체인의 합의 메커니즘에 적응할 수 있을 뿐만 아니라 검증 기술의 발전에 따라 최고의 기술을 수용하고, 미래에 점진적으로 진화할 수 있도록 합니다.
|부록
- 2020년, 문어 네트워크의 전신 Cdot 팀이 Interchain 재단의 보조금을 받아 Substrate-IBC, 즉 ICS10을 개발했습니다. 2. 2022년, Substrate-IBC 개발이 완료되어 전 세계 최초로 비-Cosmos 블록체인에서 IBC를 구현한 팀이 되었습니다. 3. 2022년 10월, Adaptive IBC 이종 체인 크로스 체인 기술 노선을 제안하고 NEAR-IBC 개발을 시작했습니다. 4. 2023년 10월, NEAR-IBC 개발이 완료되었으며, 제3자 보안 팀 Blocksec가 감사를 완료했습니다. 5. 2023년 12월, Cosmos SDK 블록체인 Ottochain이 $NEAR Rstaking 공유 안전 서비스를 채택하여 공식적으로 운영을 시작했습니다. NEAR-IBC는 그 중 핵심 기술로 Adaptive IBC 이종 체인 크로스 체인 기술 노선의 실행 가능성과 과학성을 검증했습니다. 6. 2024년 1분기, 프라이버시 프로토콜 Secret Network가 Adaptive IBC 기반 NEAR-IBC를 사용하여 NEAR Protocol 간의 자산 크로스 체인을 실현할 예정입니다. 이후 Octopus Network는 Secret Network와 함께 메시지 크로스 체인 기술을 계속 탐색하여 NEAR의 스마트 계약이 Secret Network의 프라이버시 계산 능력을 직접 호출할 수 있도록 할 것입니다. 7. 2024년, Adaptive IBC 기반 ETH-IBC 개발을 시작할 계획이며, 목표는 Ethereum과 기타 IBC를 지원하는 블록체인 간에 사용자에게 저렴한 IBC 크로스 체인 경험을 제공하는 첫 번째 팀이 되는 것입니다.
|참고 자료
《The IBC Protocol 2023 Year in Review》Mary McGilvray
《Adaptive IBC ：이종 체인 상호 운용성의 파괴자》Louis
《NEAR-IBC 소개｜스마트 계약을 통해 IBC 프로토콜을 구현하는 방법》
《NEAR는 곧 Cosmos 존이 될 것입니다》Louis
