Polymer, IBC로 파편화된 이더리움 생태계를 연결하다

과거에 새로운 블록체인 네트워크를 빌딩하는 작업은 시간이 많이 걸리고 많은 인력이 투입되었어야 했다. 이러한 상황은 자체 L1 블록체인뿐만 아니라 롤업에도 적용되었었다. 하지만 기술의 발전으로 2023년에는 성공적으로 운영되던 롤업들의 코드가 복사되어 프레임워크처럼 사용되기 시작하면 자체 블록체인을 런칭하는 사례가 기하급수적으로 많아졌다.

RaaS 공급업체의 성숙이 이러한 발전을 이끌었고, 예시로 Conduit, Caldera, Gelato, Ankr, Luganodes, Zeeve, Tanssi, Dymension, Lumoz, Karnot 등 많은 공급업체가 등장하고 성장하고 있다. 이러한 상황은 각 블록체인 환경과의 연결성의 문제점을 악화시켰기에 서로간을 더 잘 연결하기 위한 인프라를 만드는 상호 운용성 솔루션에 대한 관심을 증가시켰다.

이 글에서는 우선 현재의 상호 운용성의 현황과 표준화가 필요한 이유에 대해 살펴보고, "Polymer"가 어떠한 표준을 기반으로 안전한 연결 허브로서 어떻게 위치하고 있는지 살펴보자.

1. 배경: 이더리움 연결성의 현황

1.1 과거를 돌아보며

2021년 Dmitriy Berenzon의 유명한 이미지를 다시 보자면, 과거에 비해 이더리움은 상당한 진전을 이루었다. 이전에는 상호운영성 기능이 단순했으며, 주로 "토큰 전송"에 초점이 맞추어졌었다. 이는 래핑(wrapping)을 통해, 유동성 브리지를 사용하거나, 중앙집중화된 운영자를 통해 이루어졌었다. 하지만 더 많은 블록체인이 출시되고 다른 기능들에 대한 필요성이 증가함에 따라, 많은 다른 기능들이 증가했다.

Source: Blockchain Bridges: Building Networks of Cryptonetworks | 1kxnetwork

1.2 상호운용성 현황

크로스체인은 플러그인 같은 역할을 하게 되어 모든 체인과 연결이 가능해졌다. 이제 체인들은 이전보다 더 많이 그리고 빠르게 연결되어 있고, 메시지를 전송하여 다른 체인의 스마트 컨트랙트를 실행할 수 있는 등 개발자의 필요에 따라 커스터마이징 할 수 있다. 구체적으로 Dapp들은 상호운용성 솔루션을 사용하여 체인의 인프라 및 유동성에 대한 접근도 이전보다 직관적인 빠르게 활용할 수 있게 되었다. 예를 들어, 레이어제로를 활용하여 여러 블록체인에서 유동성에 접근하는 대출 프로토콜 등이 등장하였다.

1.3 현재 이슈: 표준의 부재, 독립적인 개발

그러나, 상호 운용성 분야는 아직 초기 단계에 있으며, 각 프로젝트는 현재 자체 스택을 개발하고 있다. 접근 방식은 각 코드와 인프라에 대한 자체적인 표준을 만들고 여기에 덧 붙일 수 있는 커스터마이징 가능한 모듈을 만드는 쪽으로 기울어져 있다. 예를 들어, 레이어제로는 사용자 정의 보안 모듈과 중간 릴레이 제공자를 허용하는 v2를 발표하고 있으며, 하이퍼레인 v3는 허가 없는 커스터마이징 가능한 배포를 가능하게 하고 있습니다.

이러한 상호 운용성 솔루션을 활용하려면 개발자들은 그들의 인프라와 함께 개발된 각각의 프로그램 로직을 이해해야 한다. 이러한 추세는 각 솔루션의 독립된 개발 생태계를 조성하기 때문에 추후에는 상호운용성 솔루션간의 파편화 문제 또한 존재할 수 있다. 그러기에 더 공통된 표준에 대한 노력이 필요하다. 현재 이 분야에서 개발되고 있는 표준들에 대해 알아보자.

2. 상호 운용성 표준과 IBC

2.1 표준화에 대한 노력

상호 운용성 인프라가 발전하고 다른 체인에 대한 맞춤화 필요성이 다양해짐에 따라, 두 가지 계층에 ���어 표준화에 대한 노력이 나타났다. 프로그램 로직과 핵심 인프라 로직의 표준화가 중요해졌다

1. 프로그램 로직: 이것은 메시지가 어떻게 처리되는지를 다룬다. 메세지가 전달된 이후에 어떠한 사전처리가 이루어지는지를 표준화하는 작업들이 포함된다. 프로그램 로직 측면에서의 트렌드는 layerzero의 OFT-20과 같은 각 스택에 대한 맞춤형 모듈도 등장하고 있으며 xERC20과 같이 브릿지와 상관없이 운영되는 여러 체인에 동시에 활용 가능한 토큰 표준도 개발되었다. 또한 인터페이스 측면에서 Hashi와 Multi-Message-Aggregation(MMA)과 같은 어댑터 형식을 통해 브릿지를 aggregate하는 인터페이스 로직도 이에 대한 노력에 포함된다.

2. 핵심 로직: 이것은 핵심 전송 기능을 다룬다. Axelar 같은 프로젝트들이 그들의 인프라를 표준화하고 있으며 한편으로 Hyperlane과 LayerZero와 같은 프로젝트들이 그들의 인프라를 표준화하고 있고, Polymer와 같은 프로젝트들은 IBC와 같은 표준을 더욱 보편화하려는 노력을 하고 있다.

2.1 표준의 선두, IBC

Inter-Blockchain Communication (IBC) 프로토콜은 블록체인 간 상호 운용성 표준과 솔루션으로, 특히 Cosmos에서 permissionless한 방식으로 블록체인 간에 임의의 데이터 전송을 가능하게 한다. 이는 블록체인간에 데이터, 토큰, 일반 메시지를 보내고 받을 수 있게 한다.

IBC가 2021년 3월에 출시된 이후로, 사용량은 기하급수적으로 증가하였다. 2022년에는 IBC가 290억 달러의 가치를 전송하고 5200만 건의 이체를 일으켰다. IBC 네트워크에는 100개 이상의 체인이 연결되어 있으며 실제로 IBC에 대한 모듈이 포함된 Cosmos SDK를 선택하여 블록체인을 만드는 요인이 되기도 했다. IBC는 Cosmos 생태계 내의 프로토콜뿐만 아니라, 다른 생태계에도 활용되고 있으며 IBC 생태계를 확장하는 많은 프로젝트들이 있다. (다른 생태계로 IBC를 확장하는 더 많은 프로젝트에 대한 정보는 “4.2 IBC를 확장하는 프로젝트들”를 참고하세요.)

이러한 적용을 가속화하기 위해, Interchain Foundation (ICF)은 최근 Interchain Stack Roadmap 2024을 발표하였다. 이것은 IBC를 다른 생태계로 확장하기 위한 GTM 전략과 개발 계획을 개요화하였고 이의 작업으로 여러 프로젝트들이 다른 블록체인으로 IBC를 확장하는 데 적극적으로 작업하고 있다.

Source: Adi on X: "prob nothing. @IBCProtocol https://t.co/k0RZTPg8Dv"

2.2 IBC 스택: 코어 및 프로그램 로직

IBC의 아키텍처는 코어 로직과 응용 프로그램 로직으로 구성되어 있습니다. 코어 로직은 기본적인 전송 기능을 처리하며, 응용 프로그램 로직은 메시지를 처리하는 역할을 한다. 이 모듈식 구조는 각 프로젝트의 특정 요구 사항에 따라 유연성과 맞춤화를 가능하게 한다. (IBC 핵심 모듈의 아키텍처와 트랜잭션 흐름에 대한 참고 자료로 APPENDIX B를 참조하세요)

이를 통해 개발자들은 다양한 응용 프로그램을 만들 수 있는데 아래와 같은 예시들이 있다.

• ICA (Interchain Account): 이는 한 블록체인이 다른 블록체인에서 계정을 운영하는 것을 가능하게한다. 결과적으로, 블록체인은 토큰을 전송하거나, 투표를 하거나, 다른 체인에서 스마트 계약을 실행하는 등의 동작을 다른 체인에서의 지갑을 통해 수행할 수 있다.

• ICQ (Interchain Query): 이는 블록체인이 서로 데이터를 요청하고 안전하게 데이터를 검색할 수 있도록 설계되었다. 이 기능을 통해 블록체인은 스마트 계약 실행, 또는 자체 체인 데이터 가용성을 향상시키기 위해 다른 체인의 데이터를 사용할 수 있다.

• Cross-Chain Validation: Interchain Sequrity로 더 잘 알려져 있는 Cross-Chain Validation은 메인 체인의 검증자가 다른 체인에서 트랜잭션 또는 블록을 검증할 수 있도록 하여, 그들의 보안 모델을 다른 체인으로 확장할 수 있는 기회를 제공한다.

3. Polymer: 이더리움을 위한 가장 안전한 연결 허브

Polymer는 현재 IBC의 기능을 이더리움 생태계로 가져오려는 프로젝트로, OP-Stack과 Eigenlayer의 EigenDA에 의해 구동되기에 “이더리움 보안성” 또한 갖추었다.

3.1 Polymer의 비전

Polymer는 IBC와 자체 OP-Stack Rollup을 사용하여, 이더리움과 궁극적으로는 모든 블록체인을 위한 연결 계층을 구축하고 있다.

웹2의 라우터와 유사하게, 네트워크 간에 데이터를 수신하고 전송하는 Polymer Rollup은 다양한 블록체인에서 IBC 패킷을 받아 대상 체인으로 전달하며, IBC의 코어 표준과 응용 프로그램 표준 을 준수한다.

이 비전을 실현하기 위해 현재 두 단계의 마일스톤이 있다.

1. 단계 1: Polymer의 자체 롤업을 사용하여 모든 이더리움 롤업과 Cosmos를 연결한다.

2. 단계 2: Solana, Avalanche, Sui 등의 다른 생태계와 연결을 확립한다.

Source: Polymer Labs

3.2 폴리머의 여정: 상호 운용성 분야에서 풍부한 경험

폴리머의 팀은 구글, 시타델, 맥킨지, 아마존, 버라이즌, EY, 우버와 같은 회사에서 경험을 쌓은 다양하고 전문적인 배경을 가진 사람들로 구성되어 있다. 그들의 엔지니어링 팀의 대부분은 주로 경력 있는 개발자들로, Web 2.0 분야에서 인프라를 확장하는 데 있어 경험을 가진 Web3.0 산업 외부에서 모집되었다.

처음에 폴리머는 IBC 자체를 고도화하고 활용하여 다른 블록체인 간의 연결을 만들려고 했습니다. 그러나, 그들은 곧 원래의 다른 체인에 있어 IBC 지원은 많은 리소스가 든다는 것을 깨달았다. 이 도전은 폴리머가 독립적인 앱 체인을 구축하여 zkIBC를 만들어 해결하는 방향으로 가게 되었다.

그러나 이더리움 생태계 내에서 롤업들이 점점 늘어나자, IBC 중간 통로로 이용되는 독립적인 앱 체인이 롤업 간의 통신에 이상적인 것이 아니라는 것이 분명해졌다. 그 이유는 롤업이 갖고 있는 보안성을 공유하지 않는다는 점이 문제였다. 그러기에 독립적인 Layer 1을 통해 효과적인 허브와 스포크 모델은 롤업들을 연결하는데 있어 효과적인 방법이 아니게 되었다.

결과적으로, 폴리머를 연결하려는 롤업과 같은 보안 속성을 상속하는 Layer 2 솔루션으로 구축하기로 결정했다.

3.3 폴리머 이해하기: 상호 운용성 허브

*폴리머의 자세한 구조를 이해하려면 APPENDIX A를 참조하세요

폴리머는 OP-Stack 롤업의 구조를 가진 라우터 허브로서, 최소한의 개발 공수로 어떤 체인에서도 IBC 전송을 통합하고 추가하는 것을 가능하게 하였다.

이는 두 가지 주요 인프라로 구성되어 있다:

1. 인터페이스 계층: 이것은 IBC 라이트 클라이언트와 가상 라이트 클라이언트 (vIBC) 를 포함하는 클라이언트 클러스터이다. 가상 IBC 라이트 클라이언트는 이더리움 롤업에서 들어오는 요청을 관리하고, IBC 라이트 클라이언트는 코스모스 체인에서의 요청을 처리한다.

2. 폴리머 롤업 계층: 이 계층은 multi-hop 기능을 가지고 있으며, 이는 다른 체인 간의 상호작용을 하나의 트랜잭션으로 가능하게 한다. IBC 채널은 폴리머를 중간 연결 홉으로 설정할 수 있으며, 폴리머는 라우터처럼 패킷을 넘기는 역할을 한다.

폴리머는 중개인 역할을 하며 개발 구조가 모듈화가 많이 되어있다. 이를 통해 이더리움과 같은 비-IBC 체인들이 최소한의 구현을 통해 IBC를 활용하면서 폴리머에게 전송 작업을 처리하도록 의존할 수 있다.

3.4 폴리머 테크 스택

폴리머 테크 스택은 두 가지 기본 철학에 기반을 두고 있습니다:

1. 가장 많이 사용되는 롤업 프레임워크와 가장 이더리움의 보안성을 갖는 DA를 통해 이더리움의 보안을 최대한 활용한다.

2. 인터 블록체인 통신 (IBC)을 가능하게 하는 기술을 통합하고, IBC 코드베이스와 관련 응용 로직을 활용한다.

다음은 "폴리머 테크 스택"의 주요 구성 요소와 그 기능에 대한 분석이다

1. Execution: 코스모스 SDK가 사용되며 롤업의 연결하기 위한 인터 블록체인 통신 (IBC) 모듈들을 그대로 사용한다. 이를 통해 블록체인 간에 임의의 데이터를 전송하고, 원활한 상호 작용과 데이터 전송을 가능하게 한다.

2. Settlement: 폴리머는 Cosmos-SDK을 OP-Stack 위에 만들었기에 다른 OP-Stack 롤업들과 마찬가지로 증명 시스템을 갖춘다.

3. Data Availability: EigenDA는 폴리머 네트워크 내에서 낮은 비용으로 확장 가능한 데이터 가용성을 보장하는 데 작용된다. 이더리움 네트워크의 데이터 대역폭을 향상시킴으로써, EigenDA는 폴리머의 크로스 체인 상호 운용성과 같은 고 처리량 애플리케이션에 대한 네트워크의 효율을 향상시킨다.

결과적으로 Cosmos-SDK, OP-Stack 그리고 EigenDA의 사용을 통해 폴리머는 안전한 상호 운용성 인프라의 구축을 이더리움에서 구축하고 있다.

Source: The Polymer stack | Polymer Developer Docs

3.5 Leading the Coordination of IBC

To ensure efficient development and coordination, it is necessary to have a single entity driving the development of each component and coordinated by a single entity.

Currently, Polymer is leading the development and coordination efforts. IBC Explorer, OpenIBC and IBC Summit, which is operated by Polymer are three initiatives focused on coordinating these efforts.

3.5 IBC 생태계 협업을 주도하다

효율적인 개발을 보장하기 위해서는 각 구성 요소의 개발을 주도하고 있는 여러 개발 주체들간의 교류를 조성하는 것이 중요하다. 현재 Polymer가 개발과 조정 노력을 주도하고 있다. Polymer가 운영하는 IBC Explorer, OpenIBC 및 IBC Summit은 이러한 노력을 조정하는데 중점을 둔 세 가지 이니셔티브이다.

3.5.1 IBC Explorer

Source: polymerdao/ibc-explorer: IBC dashboard

IBC Explorer는 IBC와 관련된 작업을 하는 개발자들을 위한 사용자 경험을 향상시키도록 설계되었다. IBC Explorer는 다음과 같은 기능을 제공함으로써 이러한 영역을 해결하고자 한다:

• 패킷 라이프사이클의 간단한 추적, 더 나은 모니터링 과정을 가능하게 한다.

• 애플리케이션별 채널의 활성화 상태 추적, 그들의 성능에 대한 명확한 개요를 제공한다.

• 네트워크 구성에 대한 제어를 제공, 개발자가 특정 클라이언트를 통해 소통하고자 하는 체인을 지정할 수 있게 한다.

이러한 기능들은 IBC의 실용적인 응용을 향상시키기 위한 것으로, 이는 사용자 친화적이고 개발자의 필요에 맞게 조정할 수 있게 만듭니다. 현재 이 대시보드는 테스트 환경에서만 제공하며 곧 출시될 예정이다.

3.5.2 OpenIBC (Website, Twitter)

OpenIBC는 Polymer가 설립한 조직으로, 인터 블록체인 통신(IBC) 프로토콜 개발 및 홍보에 중점을 두고 있다. 주요 목표는 개발자, 프로젝트, 조직의 통합 네트워크를 구축하여 IBC 표준 및 구현을 발전시키는 것이다.

OpenIBC에는 IBC 개발에 관한 토론, 협업, 지식 공유를 위한 플랫폼으로서의 역할을 하는 포럼이 있다. 다양한 블록체인 커뮤니티의 이해관계자들을 모아 OpenIBC는 다른 네트워크 간의 안전한 통신 및 상호 작용을 가능하게 하는 IBC의 개방적이고 협력적인 개발을 장려한다.

3.5.3 IBC Summit (Website, Twitter)

IBC 서밋은 IBC에 대한 이해를 높이고 업계의 미래 방향에 대해 논의하기 위해 생태계에 속한 사람들이 한자리에 모이는 모임이다. 수많은 업계 전문가들이 IBC의 활용과 잠재력에 대한 인사이트를 공유하며 이전 참여 프로젝트로 Celestia, dydx, Cosmostation, Osmosis 등이 있다.

4. IBC 생태계를 확장하는 프로젝트들

본 섹션에서는 이더리움을 제외하고 다른 생태계에서 IBC가 어떻게 활용되고 있는지에 대해 알아보자

4.1 코스모스의 IBC 생태계

코스모스 생태계는 IBC 스택에서 가장 활발한 커스터마이징과 개발이 이루어지고 있으므로, 현재 개발 현황을 살펴보겠습니다.

과거에는 인터체인 재단(ICF)과 인포멀 시스템즈가 IBC와 관련된 핵심 구성 요소를 유지 관리하고 개발하는 팀이었다. ICF는 IBC 사양, ibc-go, ics23-go를 유지 관리하는 데 중점을 두고 있고 반면에 Informal Systems는 hermes, ibc-rs, ics23-rs, 텐더민트-rs(CometBFT 팀과 협력)를 유지 관리한다.

또한 다양한 코스모스 기반 블록체인에서 IBC 기능에 상당한 발전이 있었다. 다음은 몇 가지 예시이다:

• 오스모시스와 마스 프로토콜: outpost 및 크로스체인 스왑을 제공한다.

• 스트라이드와 뉴트론: 이 블록체인은 많은 미들웨어, ICA 및 쿼리로 구축되었다.

• 다오다오: 모든 스마트 컨트랙트에 IBC에 연결된 모든 블록체인의 계정을 제공하는 프로토콜인 폴리톤을 만들었다.

• Evmos: EVM을 통한 전송을 위해 IBC 프리컴파일을 구축했다.

• 인젝티브: 오라클 데이터 스트리밍 모듈을 개발했다.

4.2 코스모스를 넘어 …

다양한 블록체인 네트워크에서 IBC를 활용하도록 하는 여러 프로젝트들이 있다. 이로 인해 IBC의 기술 모듈과 생태계가 다양해지고 있으며, 다양한 환경에서 테스트되고 있어 앞으로 많은 발전이 있을 것이다.

IBC를 다른 블록체인으로 확장할 때, IBC 기반 상호운용성을 활성화하기 위해서는 다음 네 가지를 개발해야 한다.

1. 코어 로직: ibc-go는 Go 체인에서만 작동하므로 다른 블록체인을 통합하려면 맞춤형 IBC 전송 계층을 구현하는 것이 핵심이다. Rust용 ibc-rs와 같은 대안이 개발되고 있지만 아직 테스트 단계이다.

2. 라이트 클라이언트: 새로운 비코스모스 체인은 트랜잭션을 신뢰 없이 검증하기 위해 검증을 위한 라이트 클라이언트가 필요하다.

3. 릴레이어: 연결된 체인 간에 IBC 패킷을 라우팅하고 생태계 내에서 새로운 체인의 데이터를 전파하려면 릴레이어 소프트웨어와 운영자가 필요하다.

4. 검증 로직: 코스모스의 IBC는 머클 증명을 사용하여 크로스 체인 트랜잭션을 검증한다. 그러나 블록체인마다 완결성과 검증 로직이 다르다. 예를 들어, 이더리움은 텐더민트와 달리 가역성을 허용합니다. 파이널리티를 위해 사기 증명을 활용하는 OP-Mainnet 역시 고유한 로직을 가지고 있다. 따라서 검증 클라이언트는 블록체인 전반에서 올바른 최종성을 보장하기 위해 다양한 사양으로 개발되어야한다.

그러기에 완결성과 기술 사양이 서로 다른 두 블록체인을 연결하는 것은 어려울 수 있습니다. 이를 해결하기 위해 다양한 수정과 보완 로직이 필요합니다. 한 가지 예로 Polymer Labs에서 개발한 조건부 클라이언트와 가상 라이트 클라이언트가 이에 대한 개발 공수를 줄이는 역할을 했다.

5. Looking Ahead - 상호운용성의 미래

2023년에는 상호운용성 문제를 해결하기 위한 수많은 프로젝트가 발전을 이루어왔다. 일부는 성공했지만, 일부는 실패했다. 그러나 현재 플레이어들은 각자의 입지를 굳히고 체인 간에 메시지와 토큰을 전송하는 방식을 표준화하고 있다.

저자는 이중 코어 전송에서 두 가지 흥미로운 측면이 개발 중이라고 생각한다:

• 애플리케이션 로직: 체인 간에 패킷을 전송한다는 것은 자산을 전송할 수 있을 뿐만 아니라 데이터도 전송할 수 있고, 다른 체인에서 스마트 콘트랙트를 실행할 수 있다는 것을 의미한다. 이는 체인용 인터페이스 어댑터를 구축하는 해시나 세이프와 함께 안전한 멀티체인 지갑을 만드는 것과 같은 흥미로운 구현의 가능성을 열어준다. 또 다른 예로는 모든 블록체인을 위한 유동성 레이어를 구축하는 카탈리스트가 있다.

• 프로젝트 간의 협업 증가: 상호운용성 솔루션이 점점 permissionless하게 바뀜에 따라 서로를 지원하는 가능성이 열리고 있다. xERC20과 같은 표준 제안은 다른 여러 솔루션을 활용하여 사용될 수 있다는 점에서 흥미롭다.

이러한 맥락에서 폴리머가 코스모스 IBC 애플리케이션 로직 개발을 이더리움으로 가져오고, 협업을 촉진시키는 노력들을 통해 IBC 생태계를 어떻게 활성화를 시킬지 기대된다.

*APPENDIX는 docs의 표현을 최대한 정확하게 전달하고자 영문으로 작성되었습니다.

APPENDIX A: Polymer Architecture Deep Dive

This section delves into the intricacies of Polymer's architecture, looking into the roles and interconnections of its various components.

The core components are like below

1. IBC Interface:

   1.1 Entry contracts: These are the contracts that are deployed on each rollups/blockchains.

   1.2 Relayers: These are the entities that listen to events in other rollups/blockchains and relay them to Polymer, and vice versa.

2. Polymer Rollup

   2.1 Cosmos-SDK: This is the execution layer where the logic is constructed.

   2.2 OP-Stack: This is the rollup infrastructure where the transaction and settlement processes are managed.

   2.3 EigenDA: This is where data availability is handled, offering lower costs but maintaining Ethereum level security.

Source: The Polymer stack | Polymer Developer Docs

A.1 IBC Interface - Access Polymer

A.1.1 Entry Contracts

At the user interface level, we have IBC proxy contracts which serve as the primary point of contact for users. These entry points are built on a foundation of core smart contracts that define the operational logic for application. Below are core components of Polymer making connections available.

• IBC: The standard protocol facilitating interoperability between different blockchain networks.

• vIBC: Representing Virtual Inter-Blockchain Communication, this adaptation of the Inter-Blockchain Communication (IBC) protocol is designed to make IBC available to any chains. 

  Virtual IBC allows for permissionless IBC connectivity. The idea is that instead of needing to do a native integration of IBC, devs can deploy a set of smart contracts, and instead have Polymer act as an IBC sidecar performing IBC execution on behalf of the connected rollup, making the rollup appear as any normal IBC chain in the network itself.

• Middle Hop: enables a one-click transaction between different chains; IBC channels can be defined over Polymer as a middle connection hop, as Polymer acts like a router.

A.1.2 The Relayer Component

The Relayer is a bridge-like entity within the Polymer architecture, responsible for monitoring and conveying events across different blockchain networks. It's a vital cog in the machinery, ensuring that operations on one chain can trigger corresponding actions on another.

A.2. Polymer Rollup: Cosmos-SDK, OP-Stack and EigenDA

A.2.1 Polymer Rollup, built with Cosmos-SDK and OP-Stack

Diving deeper into the architecture, the Polymer Chain App integrates a variety of technologies:

Cosmos-sdk: This framework is used to build blockchain execution logic within the Cosmos ecosystem, illustrating Polymer's compatibility with this environment. Polymer has successfully integrated with OP-Stack, using Cosmos-SDK as an execution engine for Ethereum rollups.

OP-Stack: The OP Engine API and the OP rollup node, key components of the Optimistic Rollup infrastructure, are central. The OP Engine API interacts with cosmos-sdk, while the OP rollup node serves as the settlement layer for a sequencer.

• L2Client (ABCI): This Layer 2 client uses the Application Blockchain Interface (ABCI) to facilitate communication between Cosmos-SDK and the OP Engine API.

• Sequencer: This node sequences transactions, determining their order before they're finalized on the blockchain.

• Proposer: This entity proposes new blocks for the blockchain.

A.2.2 Data Availability (DA) Layer with EigenDA

The Data Availability (DA) layer is responsible for ensuring that data across the chains remains accessible and verifiable. This is crucial for maintaining transparency and security within the ecosystem. Polymer use EigenDA to achieve this, which allows Polymer Rollup to operate at a much lower cost while maintaining Ethereum level security.

APPENDIX B: IBC Protocol and Its Detailed Process

The Inter-Blockchain Communication (IBC) protocol is a blockchain interoperability solution that allows for arbitrary data transfer across blockchains in a secure and permissionless manner. It lets blockchains, applications, and smart contracts seamlessly send and receive data cross-chain.

When discussing cross-chain solutions, the Inter-Blockchain Communication (IBC) protocol is often mentioned as a secure and reliable cross-chain protocol, but mainly only actively used within the Cosmos ecosystem.

Lets look into how IBC actually works:

B.1 IBC Stack

IBC has different standards and consists of various components. The two main operators are the Light Client and Relayer. The application logic and the connection are implemented in its core logic.

1. IBC Light Clients: IBC clients, also known as light clients, track the consensus state of other blockchains and the proof specs required to verify proofs against the client's consensus state. Each client is identified by a unique client ID and can be associated with any number of connections to the counterparty chain.

2. Relayers: Relayers play a key role in IBC communication. They are off-chain processes responsible for relaying data between two chains running the IBC Protocol. Relayers scan the state of each chain, construct appropriate datagrams and execute them on the opposite chain as allowed by the protocol.

B.2 Lifecycle of IBC

IBC enables communication through a process of establishing connections. Channels are then opened between modules to allow packet sending, receiving, and acknowledgment using a channelID and portID. Once connections, channels and ports are set, applications can transmit packets across chains. A user initiates a cross-chain transaction delivered via relayers to the light client of the receiving chain for verification.

B.2.1 Initialization

1. Establish Connections: Connections, as facilitated by ICS-3, are responsible for all cross-chain verifications of an IBC state. Each connection encapsulates two ConnectionEnd objects on two separate blockchains. Each ConnectionEnd is associated with a light client of the counterparty blockchain.

2. Open Channels: Modules on one blockchain can communicate with other modules on different blockchains by sending, receiving, and acknowledging packets through channels. Channels are established with a handshake and are uniquely identified by the (channelID, portID) tuple. They encapsulate two ChannelEnds that are associated with a connection.

3. Bind Ports: An IBC module can bind to any number of ports with each identified by a unique portID. The portID denotes the type of application, for instance, in fungible token transfers the portID is 'transfer'.

B.2.2 Packet Transfer

Applications can now send data packets across the established channels. Once a data packet is sent from the source chain, it's received and acknowledged by the destination chain, utilising the light client on the destination chain for verification.

1. A user, which can be an end user, smart contract, or module, initiates a cross-chain transaction on Chain A.

2. The transaction request is transmitted to the IBC Transport Layer to be delivered to the receiving chain, Chain B.

3. An off-chain process, known as a relayer, takes responsibility for transporting the message from Chain A to Chain B.

4. Chain B utilizes its light client of Chain A to verify the consensus state and confirm that the transaction has indeed occurred on Chain A.

5. If the verification is successful, indicating that the transaction is legitimate and has been executed on Chain A, Chain B proceeds to execute the requested action on its own chain.

Thanks to Kate for designing the graphics for this article.