출처: https://chronicle.castlecapital.vc/p/arbitrum-chains-scaling-on-your-own-terms-53cc2f910c5bce75
Arbitrum Chains: Scaling on Your Own Terms
오늘은, 아비트럼 오르빗(Orbit) 체인이 무엇인지, 왜 태어나게 되었는지, 그리고 현재 Orbit 체인을 실제로 사용하고 있는 프로젝트는 무엇인지 설명하는 캐슬 랩스의 리서치를 소개드리고자 합니다.
우선, Orbit 체인의 가장 큰 의의는 블록체인 인프라에서 점점 희소해지고 있는 ‘자유’를 빌더에게 제공하는 것입니다. 여기서 자유란 자신만의 이코노미 모델·거버넌스·신뢰 가정을 정의하고, 자신이 정의하는 애플리케이션에 맞춰 체인을 설계할 수 있는 능력을 의미합니다.
https://x.com/OffchainLabs/status/1742667160277729528
이미 35개가 넘는 Orbit 체인이 메인넷에서 서비스 중이며, 초고속 게임·옴니체인 로열티·유동성 라우터·교육 인프라까지 다양한 영역에서 서비스를 제공하고 있습니다. 그리고 이들은 아비트럼 메인넷 네트워크를 사용하는 것이 아니라, 당연하게도 그들만의 독자적인 네트워크를 활용하고 있습니다. Orbit은 모듈형 툴킷에서 새로운 유형의 생태계를 잇는 결합 조직으로 진화하고 있습니다. Orbit은 단순히 여러 체인을 하나의 비전 아래 통합하는 것을 넘어, 각 체인이 스스로를 정의하도록 힘을 실어 주고 있는데요. 이러한 Orbit이 왜 태어나게 되었는지, 그리고 어떤 프로젝트들이 Orbit을 사용하고 있는지 안내드릴 수 있도록 하겠습니다.
https://x.com/arbitrum/status/1749871150480363789
레이어 2가 처음 등장했을 때 가장 시급했던 목표는 비싼 가스비와 한정된 처리량을 해결하는 것이었습니다. 롤업이라는 기술 덕분에 이들은 빠르게 제품-시장 적합성을 확인하고 초기에 활발한 사용자 유입을 이끌어냈지만, 규모가 커질수록 단일 체인 구조로는 해결하기 어려운 문제들이 순차적으로 드러났습니다. 단일 레이어 2가 가지는 문제점은 대략적으로 아래와 같았어요.
첫째, 여러 대형 애플리케이션이 같은 블록스페이스(네트워크)를 공유하면서 다시 혼잡과 수수료 상승이 발생했습니다. 둘째, 게임·소셜·기관용 디파이처럼 요구 사항이 극단적으로 다른 워크로드가 한 체인 안에서 충돌해 최적화가 불가능해졌습니다. 셋째, 각 디앱이 자체 수익 모델과 거버넌스를 설계하려 할 때, 호스팅 체인의 정책에 종속된다는 구조적 제약이 드러났습니다. 마지막으로, 체인 밖으로 전용 인프라를 확장하려는 프로젝트가 늘어나면서 네트워크 파편화가 심화됐고, 체인 간 메시지·자산 이동 표준이 미비해 사용자 경험이 단절되었습니다. 이러한 문제들에 대해 아비트럼의 개발사인 오프체인랩스는 다른 해결책을 모색했습니다.
이런 숙제를 풀기 위해 등장한 해법이 바로 ‘체인-빌더용 프레임워크’에 해당하는 아비트럼 Orbit 이었습니다. 프레임워크를 제공하면 개발팀은 이미 검증된 시퀀서, 데이터 가용성 계층, 브리지, 탐색기 등을 그대로 활용하면서도 블록타임·가스 토큰·DA 옵션·거버넌스 규칙 같은 핵심 파라미터를 애플리케이션 맞춤형으로 바꿀 수 있습니다. 그러니까 아비트럼 네트워크가 가진 장점들은 고스란히 흡수하면서 본인들의 체인들에 맞는 네트워크 환경을 구축할 수 있는 것이지요. 결국 각 애플리케이션이 필요로 하는 만큼 블록체인을 세분화하고, 동시에 동일한 보안 기준과 호환 표준을 유지해 네트워크 효과를 잃지 않는다는 점이 프레임워크 방식의 본질적인 장점입니다.
Orbit을 좀 더 깊이 들여다보면, Nitro 실행 스택을 층층이 분해해 개발자가 원하는 대로 조합하도록 설계됐다는 사실을 알 수 있습니다. 데이터 가용성 계층은 이더리움 L1, Celestia, 혹은 소수의 위원회 기반 AnyTrust 중에서 선택할 수 있고, 시퀀서는 Conduit G2 기본값을 유지할 수도, 자체 시퀀서로 교체하거나 EigenLayer 보안 모듈을 덧붙일 수도 있습니다.