블록체인 업계에서 떠오르는 핫스팟 '애플리케이션별 롤업'을 이해하기 위한 글입니다.
Smrti Lab 작성
모듈러 101에 의해 편집됨
2023년 3월 28일에 영어로 처음 게시된 이 글은 이 기사의 전반부입니다.
이 글은 롤앱 생태계에 대한 종합적인 분석을 제공하며, 기존 솔루션 4가지의 장단점을 비교합니다.
읽기에 너무 길어요:
- 현재 애플리케이션별 롤업 (RollApp) 에코시스템은 RollApp SDK, 서비스형 롤업(RaaS), 서비스형 롤업 SDK, 통합 시퀀싱 네트워크의 네 가지 유형으로 구성되어 있습니다.
- 롤앱 SDK는 개발자가 맞춤형 롤앱을 만들 수 있도록 도와주며, 일반적으로 RaaS 제공자는 롤앱 배포를 작성할 필요가 없고 스마트 계약과 유사한 개발 환경을 제공하는 롤업-SDK를 사용해 서비스를 개발합니다.
- RaaS는 주로 스마트 컨트랙트 개발자(2C)를 대상으로 하지만, 개발자를 위해 이러한 다양한 SDK를 모두 통합해야 할 필요성이 생겨났고, 이로 인해 2B 서비스 제공자인 서비스형 롤업 SDK가 등장하게 되었습니다.
- 통합 시퀀싱 제공업체는 탈중앙화, 확장성, 보안 등 시퀀서의 특정 기능에 특화되어 있습니다.
- 롤업에는 결제 롤업, 소버린 롤업, 기본 롤업, 임베디드 롤업의 네 가지 주요 유형이 있으며, 각기 다른 롤앱 SDK와 RaaS는 각자의 장단점을 가지고 다양한 유형의 롤업에 특화되어 있습니다.
- 현재의 RaaS 프로젝트는 비슷한 수준의 커스터마이징을 제공합니다. 주요 관심사는 이러한 기능의 구현 수준과 배포의 속도 및 안정성입니다.
- 통합 인터페이스는 모듈화로 이어집니다. 그리고 모듈화는 결합 가능성을 가져와 여러 개의 롤앱을 만들 수 있는 잠재력을 열어줍니다. 통합 인터페이스가 없다면 서로 호환되지 않는 레고 블록 더미에 직면할 수 있습니다.
- 시장에서 시리얼라이저의 탈중앙화를 위해서는 타협이 필요할 수 있습니다. 대신, 노드가 처음에 탈중앙화되지 않았더라도 비즈니스 모델을 효과적으로 구현하고 애플리케이션 롤앱을 쉽게 시작하고 커스터마이징할 수 있는 것이 더 중요할 수 있습니다.
애플리케이션별 롤업(즉, 롤앱 )은 블록체인 공간에서 중요한 주제가 되고 있습니다. "롤앱" 아이디어는 아직 초기 단계이지만, 지난 한 해 동안 이 분야에서 여러 프로젝트를 목격했습니다.
이 개요에서는 가까운 미래에 블록체인 분야에서 중요한 요소가 될 수 있는 이 특정 분야의 다양한 솔루션 중 몇 가지를 강조하고 비교하고자 합니다. 이러한 개별 솔루션에 대해 심도 있게 논의하기 전에, 어떻게 현재에 이르렀는지에 대해 논의할 필요가 있습니다.
처음에는 개발자가 기존 레이어 1 (L1) 체인(예: 이더 등)에 배포할 수 있는 옵션만 있었습니다. 기존 레이어에 배포하면 개발자에게 적절한 보안을 보장할 수 있었지만, 대규모 사용자로 확장하는 데 필요한 확장성 기능이 부족했습니다.
이러한 확장성 문제를 해결하기 위해 L1 체인이 아닌 롤업이 점점 더 많이 등장하고 있습니다. 롤업은 기본 체인의 보안을 유지하면서 충분한 확장성을 제공합니다. 이를 통해 확장성 문제는 일부 해결되었지만, 현재 개발자들이 직면하고 있는 문제는 커스터마이징입니다.
이더리움의 레이어 2(L2)에 배포된 각 디앱은 해당 롤업의 다른 모든 디앱과 컴퓨팅 리소스를 공유하므로, 제한된 블록 공간을 두고 치열한 가스 경쟁을 벌이게 됩니다. 또한, 디앱은 배포된 기본 체인과 동일한 규칙을 따라야 하므로 사용자 정의 기능이 부족합니다.
제한된 블록 공간과 사용자 정의 기능의 부족으로 인해 애플리케이션별 블록체인(앱 체인) 이 등장하게 되었습니다. 이러한 유형의 프레임워크는 코스모스 생태계에 의해 대중화되었고, 이후 폴리곤 슈퍼체인, 애벌랜치 서브넷 등이 채택했습니다. 그러나 애플리케이션 체인도 자체적인 검증자 네트워크를 시작해야 하고, 자체적인 보안을 책임져야 하는 등의 단점이 있습니다.
하지만 개발자가 롤업 배포의 보안 이점과자체 전용 환경의 유연성을 결합할 수 있다면 좋지 않을까요?
이것이 바로 애플리케이션별 롤업 또는 "롤앱"이 달성하고자 하는 목표입니다. 롤업에서 차용한 보안과 유연성에 자체 전용 환경의 특성을 결합하는 것이 이 아이디어의 핵심입니다.
1. 롤앱 생태계
현재 롤앱 생태계에는 네 가지 주요 플레이어가 있습니다.
롤앱 SDK
개발자가 맞춤형 롤앱을 쉽게 구축할 수 있는 프레임워크이자 툴킷입니다. 그러나 개발자는 자신만의 애플리케이션별 롤업을 구축하기 위해 기본적인 블록체인 로직을 이해해야 하며, 각기 다른 SDK는 서로 다른 유효성 및 사기 방지 옵션을 갖춘 다양한 유형의 롤업에 특화되어 있습니다. 따라서 개발자는 자신의 특정 요구에 맞는 SDK를 선택하는 것이 중요합니다.
서비스형 롤업(RaaS)
RaaS는 롤업 서비스 제공업체를 말하며, 일반적으로 롤업-SDK 위에 서비스를 구축합니다(예: Caldera는 운영 스택을 사용). 롤업 배포에는 코드가 필요하지 않습니다. 모든 노드/콜은 RaaS 운영자가 처리합니다. 스마트 컨트랙트 개발자의 경우 블록 로직을 이해할 필요가 없으며, 개발 환경은 스마트 컨트랙트 개발과 매우 유사합니다.
서비스형 롤업 SDK
RaaS는 주로 스마트 컨트랙트 개발자(2C)를 대상으로 하지만, 다양한 SDK를 함께 통합할 필요도 있어 개발자를 위한 2B 서비스 제공자인 서비스형 롤업 SDK가 탄생했습니다. 현재 이 분야에 초점을 맞춘 프로젝트는 한정되어 있습니다. 모듈형 클라우드 팀은 2022년에 이 기능을 시연했지만, 현재는 여러 모듈형 블록체인을 위한 브라우저를 구축하는 데 집중하고 있습니다.
통합 정렬 네트워크
각 RaaS 또는 앱 롤업 SDK에는 자체 시퀀서가 있을 수 있지만, 탈중앙화된 시퀀서 네트워크를 위한 합의와 보안에 중점을 둔 전용 시퀀서 제공자가 여전히 필요합니다. 공유되고 통합된 시퀀서 네트워크는 서로 다른 롤앱 간에 원자성과 상호운용성 구현을 간소화할 수 있습니다.
그림 1: 롤앱 생태계 파노라마
2. 롤업에는 어떤 유형이 있나요?
롤업은 L1에 확장성 이점을 제공하도록 설계되었습니다. 롤업은 사용자 클라이언트, 가상머신, 시퀀서, 증명 시스템(특히 zk 롤업의 경우), 하나 이상의 메모리 풀, L1의 브리지 컨트랙트 등 다양한 구성 요소로 이루어져 있습니다.
롤업이 브리징 콘트랙트에 의해 정의되어야 하는지 여부는 논란의 여지가 있지만, 브리징 프로토콜을 구분하는 것과 마찬가지로 어떤 체인/레이어가 진실의 원천인지에 따라 "소버린" 롤업과 "합의" 롤업을 구분할 수 있습니다.
그림 2: 결제 롤업과 소버린 롤업 비교
결제 롤업은 결제 레이어의 스마트 콘트랙트에 의존해 증명을 검증하고 자산을 연결하는 자산 유형입니다. 이 스마트 콘트랙트는 롤업 체인의 진실 소스 역할을 합니다. 이러한 브리징 스마트 콘트랙트를 보호하기 위해 많은 롤업 팀(예: Arbitrum과 옵티미즘)은 롤업의 명백한 취약점을 수시로 수정하기 위해 업그레이드 키를 보유하고 있습니다. 그러나 이러한 권한은 다른 한편으로 무작위 코드 변경이 눈에 띄지 않게 될 위험도 있습니다.
소버린 롤업은 셀레스티아에서 도입했으며, 롤업 자체는 레이어 1 블록체인처럼 작동합니다. 소버린 롤업 자체는 L1이 아닌 진실의 원천이며, 롤업 노드는 자체 P2P 네트워크를 통해 위조(유효) 인증서를 전송하고 로컬에서 유효성을 검사하는 동시에 기본 체인만 사용하여 주문된 트랜잭션을 저장합니다.
또한, 주권적인 롤업 커뮤니티는 베이스 레이어의 허가 없이 하드포크를 통해 체인을 업그레이드할 수 있습니다. 이는 악의적인 행동이 발생하여 소버린 롤업이 이를 되돌리고자 할 때 유용합니다.
그림 3: 베이스 롤업과 임베디드 롤업 비교
기본 롤 업은 L1 노드를 시퀀서로 사용하는 롤업 유형으로, L1 시퀀싱 설계는 L1의 활동과 탈중앙화를 계승하여 중앙 집중식 또는 단기 시퀀서의 유해한 MEV를 완화하는 데 도움이 되며, 현재 기본 롤업 설계를 사용하는 SDK나 RaaS 프로토콜은 없습니다.
임베디드 롤업은 L1 자체 내에 롤업 블록을 구축하는 것을 의미합니다. 이더리움에서 실행 클라이언트는 블록 헤더와 블록 본문을 포함하는 블록을 빌드합니다. 이 블록을 (유효성/부정) 증명이 있는 롤업 블록으로 감싸면, 다른 검증자는 모든 트랜잭션을 다시 계산하는 대신 상태 차이만 계산하고 증명을 검증하면 됩니다.
이 아이디어는 한 명의 빌더만이 전체 상태를 포함하여 증명을 생성하고, 다른 검증자는 모든 상태를 다운로드하지 않고도 직접 검증할 수 있는 스테이트리스 아이디어와 매우 유사합니다. 현재 다이멘션은 인라인 롤업 구조이며, 이 구조에 대한 자세한 설명은 이 백서의 뒷부분에서 제공될 것입니다.
3. 롤앱 SDK 솔루션 자세히 살펴보기
3.1 롤킷과 OP 스택
올해 2월 21일, 셀레스티아 팀은 개발자가 다양한 기능을 자유롭게 선택하여 자신만의 맞춤형 롤업을 구축할 수 있는 모듈형 롤업 프레임워크인 롤킷을 소개했습니다. 롤킷과 OP 스택의 주요 차이점은 롤킷이 소버린 롤업을 지원한다는 점입니다.
(1) 롤킷은 OP 스택보다 더 유연할 수 있는 가상 머신을 제공합니다.
소버린 롤업의 가장 큰 장점은 포크 기능이 아니라 개발자가 롤업을 위해 솔리디티 라이트 클라이언트를 작성하지 않아도 된다는 점입니다.
이는 zk와 부정 증명을 처리하고 정산하는 L1의 제약을 받지 않으므로 보다 유연한 가상 머신의 혁신을 촉진할 수 있습니다. 많은 경우, 기본 결제 레이어(예: 이더리움)가 이를 효율적으로 처리하지 못할 수 있습니다.
OP 스택은 모든 슈퍼체인을 위한 자체 정산 레이어를 구축하여 이 문제를 완화하는 것을 목표로 합니다. 그러나 결제 레이어는 여전히 이더의 결제 기능에 의해 제한될 수 있으며, 이는 다른 가상머신에서 결제하고자 하는 슈퍼체인에게는 완벽한 장소가 아닐 수 있습니다.
OP 스택에 통합하고자 하는 개별 VM 모듈은 모든 이더채널 실행 클라이언트가 구현하는 메서드 집합인 엔진 API를 지원해야 하며, 엔진 API는 현재 개발 중이며 모든 VM이 당연히 이 인터페이스를 지원하는 것은 아닙니다. 따라서 더 다양한 VM과의 호환성을 보장하기 위해 아직 해야 할 작업이 많이 남아 있습니다.
(2) 롤킷에 다른 가상 머신을 도입할 때 가상 머신 패키징과 언어의 비호환성이 큰 문제가 될 수 있습니다.
하지만 롤킷을 통해 보다 유연한 VM 설계가 가능하다면, 왜 많은 VM(예: SolVM, MoveVM)이 롤킷에 포함되지 않나요?
롤킷은 롤업을 위한 ABCI와 유사한 클라이언트 구현을 제공합니다. 즉, 코스모스 SDK에서 처음 도입한 애플리케이션 블록체인 인터페이스(ABCI)를 통해 요청을 처리하고 이를 로컬 애플리케이션 인스턴스로 전달합니다. 즉, ABCI는 블록체인 클라이언트와 애플리케이션이 완전히 다른 언어로 작성된 경우에도 서로 통신할 수 있게 해줍니다.
반면, 블록체인의 클라이언트가 애플리케이션(예: 가상머신)과 통신하려면 ABCI 메서드를 호출하는 요청을 보내는 것만이 유일한 방법입니다.
따라서 모든 애플리케이션이나 VM이 롤킷에 통합되려면 ABCI 인터페이스로 래핑되어야 합니다. 이는 복잡한 과정이기 때문에 지금까지 ABCI로 래핑된 VM은 EVM(이더리움)이 유일합니다.
또한 개발과 관련하여 몇 가지 다른 문제가 있는데, ABCI는 Cosmos-SDK에 의해 설계되었습니다. 그 결과, 현재 ABCI를 기반으로 애플리케이션을 구축하는 데 사용되는 대부분의 도구는 골랑을 위한 것이기 때문에 연료나 앱토스 스택(러스트 및 기타 언어로 작성된)을 롤킷으로 가져오고자 하는 사람들이 사용하기가 어렵습니다.
롤킷이 다른 프로그래밍 언어를 사용하는 애플리케이션과 통신하는 가장 쉬운 방법은 소켓 연결을 사용하는 것입니다. 그러나 현재 롤킷에는 소켓을 사용하여 애플리케이션과 통신할 수 있는 기본 기능이 없기 때문에 다른 가상머신이나 애플리케이션으로의 마이그레이션 속도가 제한될 수 있습니다.
반면, OP 스택에는 개발 중인 엔진 API라는 자체 ABCI와 유사한 인터페이스 요구사항이 있으며, OP 스택에 통합된 모든 VM은 엔진 API와 호환되어야 합니다.
그림 4: 롤킷 아키텍처
(3) 롤킷은 비 EVM 체인(예: 비트코인)에 통합되어 보안을 계승할 수 있지만, OP Stack은 그렇지 않습니다.
OP 스택의 경우 다른 OP 스택 체인의 정산 레이어로 타사 체인에 의존해야 하며, 이를 위해서는 정산 레이어에 소스 체인의 라이트 클라이언트 또는 스마트 컨트랙트를 배포해야 합니다.
EVM과 호환되지 않는 체인을 결제 레이어로 사용하려면 각 체인이 다른 VM 시스템의 증명과 상태를 이해하고 검증해야 합니다. 이를 위해서는 서로의 라이트 또는 풀 클라이언트를 구축하는 복잡한 과정이 필요합니다. 그러나 비트코인과 같은 체인에서 OP 스택을 위한 라이트/풀 클라이언트를 구축하는 것은 거의 불가능에 가깝기 때문에 비트코인에 통합하는 것은 거의 불가능합니다.
그러나 소버린 롤업은 자체 라이트 클라이언트를 통해 증명을 검증하기 때문에, 데이터를 비트코인으로 가져와 DA 레이어로 사용하는 것이 상대적으로 쉬울 수 있습니다.
(4) 비트코인 소버린 롤업은 비트코인으로부터 유효성을 상속하지 않습니다.
비트코인 소버린 롤업은 비트코인을 DA 레이어로 사용하고 오프체인에서 증명을 검증하지만, 비트코인으로부터 얼마나 많은 보안을 상속받을 수 있을까요?
비트코인에서 소버린 롤업을 위한 풀 클라이언트나 라이트 클라이언트를 작성하는 것은 거의 불가능합니다. 즉, 비트코인과 소버린 롤업 간에 자산을 이동할 수 있는 탈신뢰 브리지 없이는 소버린 롤업의 증명과 상태를 해석하는 것이 불가능하다는 뜻입니다.
스리람 칸난은 블록체인 보안을 평가하기 위한 훌륭한 프레임워크를 제공합니다. 이 프레임워크를 비트코인 소버린 롤업의 보안 평가에 적용해보면 재구성, 검열, 데이터 가용성에 대한 저항성은 비트코인에서 상속될 수 있으며, 유효성 속성만 특별한 과제로 남는다는 것을 알 수 있습니다.
그림 5: 비트코인 소버린 롤업의 보안성
결과적으로 비트코인 소버린 롤업은 비트코인을 기본적으로 사용하거나 비트코인에 다른 애플리케이션 로직을 결합할 수 있는 기능이 필요한 애플리케이션에는 적합하지 않습니다. 그러나 대체 불가능한 토큰 프로젝트와 같이 검열과 재구성 저항을 우선시하는 프로젝트에는 좋은 선택이 될 수 있습니다.
하지만 비트코인이 소버린 롤업에 적합한 데이터 가용성 계층이 될 수 있을까요? 탭루트 위트니스는 비트코인이 각 블록에 최대 4MB의 임의 데이터를 포함할 수 있는 기능을 제공합니다. 소버린 롤업 데이터 저장 비용은 아직 논란의 여지가 있지만, 탭루트의 창립자 에릭 월에 따르면 바이트 단위로 이더리움보다 최대 7배 저렴할 수 있다고 합니다.
3.2 ZK 소버린 SDK와 ZK 결제 롤업
ZK 롤업은 낙관적 롤업보다 빠르게 마무리되어야 하지만, 증명 검증에 드는 높은 비용으로 인해 여전히 마무리 시간이 더 오래 걸립니다.
이더넷 롤업에서 단일 증명을 검증하는 데 드는 비용은 기본 증명 시스템에 따라 30만 가스에서 500만 가스까지 다양합니다. 그러나 트랜잭션 수에 따라 증명 규모는 천천히 증가합니다. 따라서 롤업은 각 트랜잭션의 증명 비용을 분산하기 위해 트랜잭션 배치를 기다렸다가 누적하는 방법을 택하는 경우가 많습니다.
현재 zk 결제 롤업에서 zk의 확정 시간이 긴 주된 이유는 비용 절감에 필요한 시간이 지연되기 때문입니다. 그러나 중앙화된 시퀀서를 사용하고 신뢰함으로써, zk 결제 롤업은 더 빠른 "소프트 파이낸싱"을 달성할 수 있습니다.
이러한 관점에서 소버린 SDK는 검증 비용을 줄임으로써 빠르고 "진정한" 결제를 달성할 수 있는 고유한 이점을 제공합니다. 소버린 롤업의 노드는 실시간으로 증명을 생성하고 나중에 재귀를 사용하여 증명을 한 묶음의 증명으로 집계할 수 있습니다. 또한, 소버린 롤업은 추가적인 온체인 검증 비용이 필요하지 않으므로 트랜잭션 비용을 분산하는 데 필요한 추가 대기 시간이 필요하지 않습니다.
다시 말하지만, DA와 합의 레이어에 의해 완결성은 여전히 제한되지만, 높은 증명 검증 비용으로 인한 지연을 크게 줄일 수 있습니다.
3.3 임베디드 롤업(다이멘션)
위에서 언급했듯이 임베디드 롤업은 L1 자체에 롤업 블록을 구축하는 것을 의미합니다. 이더리움에서는 실행 클라이언트가 블록 헤더와 본문이 포함된 블록을 빌드합니다. 이 블록을 증명(zk/부정)이 있는 롤업 블록으로 감싸면 다른 검증자는 모든 트랜잭션을 다시 계산할 필요가 없습니다. 대신 상태 차이만 계산하고 증명을 검증하면 됩니다.
이는 여러 가지 이점을 가져올 수 있습니다:
- 재실행이 필요하지 않으므로 상태 저장 증인 솔루션에 특히 적합합니다. 또한 기록 부하가 적기 때문에 노드 동기화 프로세스의 속도를 높일 수 있습니다.
- 거의 모든 값이 L1 - 다이멘션 허브에 직접 제공됩니다.
- 결제 레이어에서 브리징 컨트랙트를 구축할 필요가 없으므로 지연 시간을 줄이고 더 빠르게 마무리할 수 있습니다.
이더에 인라인 롤업을 통합하는 것은 어렵기 때문에 다이멘션과 같은 프로젝트는 코스모스 생태계에 구축하는 것을 선택합니다.
그러나 인라인 롤업 SDK의 가장 큰 잠재적 문제점은 유연성과 주권이 부족하다는 것입니다. 블록 생성, 증명 검증, 롤업 유형의 기본 로직은 결제 레이어에 '임베디드'되어 있어 개발자가 자유롭게 수정하거나 '레고화'할 수 없습니다.
따라서 임베디드 롤업 SDK(예: 다이멘션)는 결제 레이어와 긴밀하게 연결되어 있으며, 롤킷이나 소버린 SDK와 같은 방식으로 롤업의 각 모듈을 자유롭게 수정하는 것은 매우 어렵습니다.
3.4 롤업 SDK의 주요 기능은 무엇인가요?
모듈성은 컴포저빌리티를 촉진합니다. 예를 들어, 모듈형 SDK는 실행 환경부터 증명 체계까지 다양한 모듈을 결합하여 DEX부터 높은 TPS가 필요한 게임 프로젝트까지 다양한 목적에 맞게 커스터마이징하고 구현할 수 있습니다. 동일한 SDK에 원활하게 통합할 수 있는 개발별 모듈이 많을수록 컴포저블성이 높아져 사용 장벽이 크게 낮아집니다.
그러나 모듈화에는 균일한 인터페이스도 필요합니다. 표준 인터페이스가 있으면 구성 요소를 쉽게 교체할 수 있습니다. 반대로 인터페이스가 다양하면 애플리케이션 롤업 에코시스템이 파편화될 수 있습니다. 통합 인터페이스가 없으면 호환되지 않는 레고 컬렉션으로 끝날 위험이 있습니다. 통합 인터페이스는 모듈화로 이어집니다. 모듈성은 다시 컴포저빌리티로 이어져 다양한 애플리케이션 롤업의 잠재력을 열어줍니다.
그림 6: 모듈성과 컴포저빌리티
