기반 부스터 롤업에 대한 심층 분석: 배경, 사례 및 전망
원저자: jolestar (X: @jolestar )
몇몇 친구들이 보안 측면에서 기반 롤업에 관해 이야기하는 것을 보았습니다. 저는 L1과 L2의 관계와 애플리케이션 구축 측면에서 기반 부스터 롤업에 대한 저의 견해를 이야기하고 싶습니다.
Based Rollup의 아이디어는 실제로 매우 간단합니다. 즉, 사용자가 L2 트랜잭션을 L1에 직접 제출하고 L1이 이를 정렬하고 패키징합니다. 그러나 L1은 트랜잭션의 유효성을 확인하지 않고 순서와 가용성만 보장합니다. L2는 순수 실행자이지만 L1에 패키징된 L2 트랜잭션을 실행합니다. 이것이 당신에게 친숙해 보입니까? 이거 인스크립션 모드 아닌가요? 네, 여기서 비문의 인덱서는 L2로 이해하면 됩니다. 나는 "비문이 버그인가, 기능인가"라는 기사에서 이러한 관점을 언급했습니다.
Booster Rollup은 또 다른 관점에서 시작됩니다. L2의 컨트랙트를 통해 L1의 상태를 직접 읽는 방법은 무엇일까요? 실제로 아이디어는 복잡하지 않습니다. Based Rollup은 이미 L1에서 L2 트랜잭션을 실행하고 있으므로 L1 트랜잭션도 실행하는 것은 어떻습니까? 이런 식으로 L1과 L2의 상태는 큰 상태 트리에 있고 L2의 계약은 L1의 상태를 직접 읽을 수 있습니다.
그래서 taiko와 같이 Based Booster Rollup(BBR)이라고 불리는 Based Rollup과 Booster Rollup을 결합한 프로젝트도 있습니다.
BBR 배경
BBR이 제안된 이후 시장의 주목을 받은 주요 배경은 현재 이더리움의 주류 L2 솔루션으로 인한 조각화 문제, L1과 L2 간의 조각화, L2 간의 조각화 문제이다. 현재 L2 솔루션이 제공하는 기능은 개발자와 사용자 관점 모두에서 Alt-L1과 크게 다르지 않습니다. L1 데이터 읽기는 여전히 Oracle에 의존하고 자산은 여전히 연결되어야 하며 지갑은 네트워크를 전환해야 합니다. 이러한 분리는 또한 또 다른 문제를 가져왔습니다. L1과 L2 사이의 바인딩은 그다지 단단하지 않습니다. L2는 언제든지 합의 메커니즘을 추가하여 "왕으로서 자립"할 수 있으며 개발자와 사용자를 허용합니다. 기본적으로 무관심해요. 현재 주요 바인딩 관계는 정통성에 대한 EF의 제한에서 비롯됩니다. L2는 L1을 DA로 사용해야 하지만 분명히 이 제한은 강력하지 않습니다.
그렇다면 현재의 모든 L2 솔루션을 기반 롤업 솔루션으로 교체하면 문제가 해결됩니까? Optimism과 Arbitrum이 튀어나와서 Based Rollup으로 바꾸는 게 쉽지 않을까요?라고 말할 것 같아요. 요즘 주요 L2 솔루션에는 Force Inclusion 메커니즘이 있습니다. L2는 Sequencer를 직접 제거하고 Force Inclusion을 통해 사용자가 L1에 트랜잭션을 보낼 수 있도록 합니다.
하지만 이것이 단편화 문제를 해결할 수 있을까요? 할 수 없습니다. Arb와 Op는 모두 실시간으로 L1에 트랜잭션을 제출하고 L1별로 패키징 및 정렬되지만 각각 자체 트랜잭션만 인식하기 때문에 여전히 분리되어 있습니다. 이 시점에서 모두는 기반 롤업의 조각화 문제를 해결하는 열쇠는 L2 간에 공유할 수 있는 트랜잭션이나 데이터를 갖는 것이며 이 데이터 형식에는 다음이 필요하다는 것을 이해해야 합니다.
L1에 정의된 플랫폼 및 구현 독립적인 형식이어야 합니다. 서로 다른 L2 계정과 가상 머신은 다르며 해당 트랜잭션을 직접 공유할 수 없습니다.
이는 L2 간의 합의가 필요하며 여러 L2에서 지원됩니다.
따라서 프로토콜이 먼저이고, 퍼블릭 프로토콜과 데이터 형식이 먼저 설계되어야 합니다. 프로토콜에 필요한 데이터만 체인에 저장됩니다. 실행 및 검증은 오프체인에서 구현됩니다. 하지만 이 두 가지 점을 달성하는 것은 실제로 매우 어렵습니다. 우선, 이더리움 생태계의 개발자들은 일반적으로 스마트 계약을 통해 프로토콜을 설계하며, 데이터 형식을 기반으로 직접 프로토콜을 설계하는 습관이 없습니다. 이 방향의 주요 시도는 지난번 비문이 뜨거웠을 때 Ethscriptions였습니다. 두 번째 요점은 더 어렵고 확인하는 데 연습과 시간이 필요합니다.
BBR에서 BBSR까지, 스택형 L2
데이터 공유 문제에 이어 사용자 경험 문제를 이야기해보겠습니다. 분명히 모든 거래가 사용자에 의해 L1으로 직접 전송된다면 Gas이든 확인 시간이든 L1을 사용하는 것과 유사한 경험을 하게 될 것입니다. 그래서 어떤 사람들은 기반 롤업(Based Rollup)이라는 사전 확인 프로토콜을 설계하기 시작했습니다. 하지만 사전 확인 프로토콜이 실제로 작동할 수 있다면 모든 거래는 먼저 사전 확인 프로토콜을 거쳐야 합니다. 시퀀서가 아닐까요? 얘기하기엔 시간낭비인가요?
이러한 모순이 발생하는 이유는 모든 사람이 여러 거래 유형을 혼동하기 때문입니다.
사용자가 L1에 직접 제출하고 L1에 의해 실행되고 확인되는 트랜잭션은 L1 트랜잭션입니다.
사용자는 L1에 직접 제출하지만 L1은 이를 직접 검증하고 실행하지 않습니다. L2 간 공유 프로토콜의 데이터 트랜잭션을 L1.5 트랜잭션이라고 할 수 있습니다.
사용자가 L2 Sequencer에 직접 제출한 트랜잭션으로 Sequencer에 의해 사전 확인 및 실행되는 특정 L2 관련 트랜잭션입니다.
Based Rollup은 1과 2에만 관련되어 있습니다. 3은 현재 Sequencer Rollup의 작동 방식으로 두 가지를 완전히 결합할 수 있습니다.
그러한 롤업 계획이 있는 경우:
Sequencer는 모든 L1(L1.5 포함) 트랜잭션을 자동으로 동기화하고 L1에서 지정한 순서대로 실행합니다.
Sequencer는 L2 트랜잭션을 동시에 수신하여 L1 트랜잭션과 함께 정렬하여 실행합니다.
1을 통해 Based와 Booster를 구현하고, 2를 통해 사용자 경험을 잃지 않으면서 L2 트랜잭션의 빠른 확인을 달성합니다. 이전 네이밍 방식을 따른다면 이것을 BBSR(Based Booster Sequencer Rollup)이라고 불러야 하는데 좀 길어서 이해하기 쉽지 않아서 Stackable L2, 이름 그대로 L2는 Stacked라고 부릅니다. L1에는 L2에는 L1의 모든 트랜잭션과 상태가 포함됩니다. @RoochNetwork 의 솔루션입니다.
L2 거래의 DA를 어떻게 보장하나요? 롤업 또는 롤아웃?
위의 솔루션이 채택되면 L2가 자신의 트랜잭션을 패키징하여 L1에 다시 제출하는 것이 약간 이상할 것입니다. 왜냐하면 L2가 자신의 트랜잭션을 패키징한 L1 트랜잭션을 읽고 이를 다시 실행하기 때문입니다. 자체 출력도 자체 입력이 됩니다. 따라서 Rooch의 솔루션은 Rollup이 아닌 Rollout입니다. L1 블록 공간은 장기적으로 매우 소중하기 때문에 L1 공간을 점유하는 다중 L2 트랜잭션은 L1 및 L1.5 트랜잭션을 위해 예약되어야 하며 L2 애플리케이션 수준 트랜잭션을 추구해야 합니다. 그리고 "아웃소싱"을 통한 새로운 블록 공간의 확장은 전체 산업 생태계의 발전에도 도움이 될 것입니다.
비트코인 생태계의 BBSR/Stackable L2 실습
이전 설명은 모두 이더리움의 관점에서 나온 것이며 Rooch는 비트코인의 첫 번째 BBSR 또는 Stackable L2 방식입니다. 비트코인의 생태학적 차이점에 대해 이야기해 보겠습니다.
비트코인 L2에는 Turing-complete 스마트 계약이 없으며 기반 롤업 모드가 실제로 이점이 됩니다. Based Rollup은 트랜잭션을 실행하고 검증하는 데 L1이 필요하지 않으므로 Permission Less와 DA만 보장하면 됩니다. 이로 인해 비트코인 생태계의 프로젝트는 오래전부터 컬러 코인이든 이후의 RGB, Taproot Assets, Ordinals Inscription, Atomics, Runs 등이든 모두 데이터 구조를 기반으로 하는 프로토콜 설계를 시작하게 되었습니다. CSV(Client-side Validation) 프로토콜의 일반적인 개념에 포함될 수 있으며, 해당 트랜잭션은 모두 일반적인 L1.5 트랜잭션입니다. Ethereum 생태계의 프로젝트가 기반 L2를 구현하고 여러 L2 간에 공유되는 프로토콜을 설계하려는 경우 일반적으로 위 프로토콜과 유사합니다.
비트코인에서 BBSR의 작동 모드를 설명하기 위해 Rooch를 예로 들어보겠습니다.
사용자는 L1 및 L1.5 거래를 비트코인에 직접 제출하게 됩니다. 프로토콜이 공개되어 있기 때문에 모든 애플리케이션이 입구가 될 수 있습니다.
Rooch는 모든 L1 트랜잭션을 동기화하고 UTXO를 처리하며 추가 프로토콜 정보를 전달하는지 확인한 다음 해당 Move 모듈을 사용하여 이를 처리합니다. 예를 들어 Inscription으로 식별된 거래는 ord 모듈에 의해 처리되고 Babylon Stake 거래는 bbn 모듈에 의해 처리됩니다.
사용자는 처리를 위해 L2 트랜잭션을 Rooch의 Sequencer 노드에 직접 제출합니다. 위 세 가지 트랜잭션의 실행 결과는 완전한 상태 트리를 생성하며 애플리케이션 계약은 L1 및 L1.5 트랜잭션에서 생성된 상태를 최대한 활용할 수 있습니다.
이 모드의 애플리케이션은 두 개의 트랜잭션을 설계할 수 있습니다. 하나는 공용 프로토콜 트랜잭션(L1의 기반 부분)이고 다른 하나는 애플리케이션 트랜잭션(Sequencer로 정렬됨)입니다. 두 트랜잭션은 Booster 모드를 통해 서로 협력하여 Permission Less를 보장할 수 있습니다. 동시에 사용자 경험도 보장합니다.
앞서 언급했듯이 공개 프로토콜을 설계하려면 검증하고 합의에 도달하기 위해 시간과 연습이 필요합니다. Rooch가 제공할 수 있는 것은 매우 편리한 실험 환경입니다. 비트코인에서 새로운 애플리케이션이나 자산 프로토콜을 설계하려면 After를 정의하기만 하면 됩니다. 프로토콜 형식을 결정하고 해당 이동 계약 모듈을 배포하여 이를 처리한 후 애플리케이션 시나리오를 구성하여 실험할 수 있습니다.
물론 비트코인 생태계에도 이 경로에 대한 몇 가지 과제가 있습니다.
비트코인의 원래 디자인은 이 DA 시나리오에 확장할 여지가 충분하지 않았기 때문에 비트코인에 데이터가 기록되는 형식은 Witness를 통해 데이터를 삽입하는 OP_RETURN과 같이 이전의 다양한 프로토콜이 탐색하려고 시도한 방향 중 하나입니다. 서명을 사용하더라도 현재 표준화된 솔루션이 부족합니다.
비트코인 생태계는 체인에 내장된 데이터의 가치에 대해 폭넓은 합의에 이르지 못했습니다. 이는 제가 지난번 비문 이후 주장해 왔던 방향이기도 합니다. 비트코인 생태계는 글로벌 공공 데이터 버스로서 비트코인에 주목해야 합니다. 데이터 버스).
글로벌 공공 데이터 버스로서 L1의 가치
DeFi 여름 이후 전체 암호화폐 분야는 DeFi 외부의 새로운 애플리케이션을 탐색해 왔습니다. 비트코인 비문 열풍이든, 최근의 Based Rollup 논의든, 이는 데이터 버스로서의 L1의 가치를 재발견한 것으로 이해될 수 있습니다. 분산 시스템의 관점에서 시스템 간 디커플링은 데이터 버스를 통해 이루어질 수 있으며, 시스템 간 디커플링은 Permission less를 달성하기 위한 핵심 전제 조건 중 하나입니다. 예를 들어, 암호화폐 생태계의 분산형 거래소는 블록체인의 데이터 버스를 최대한 활용하여 전통적인 금융 시스템에서 직접적으로 달성하기 어려운 "분산형" 도킹을 달성합니다. 더 복잡한 애플리케이션을 지원하려면 단순 전송 트랜잭션을 애플리케이션 프로토콜 트랜잭션으로 업그레이드하기만 하면 애플리케이션 수준 권한을 덜 얻을 수 있으며 이 방법은 기존 애플리케이션에 가장 덜 방해가 됩니다.
이 기사에서는 주로 생태학 및 응용 관점에서 BBR을 논의합니다. BBR 모드의 보안과 BBR 모드의 L1, L1.5 및 L2 상태의 상호 운용성은 이후 기사에서 자세히 설명합니다. 마지막에는 내 역사적 기사와 기반 롤업에 대한 팬들의 다양한 각도 설명을 포함하여 관련 링크가 첨부되어 있습니다.
관련 링크:
1. Stackable L2 — 새로운 블록체인 확장 솔루션 https://rooch.network/zh-CN/blog/stackable-l2
2. 비트코인의 레이어 2에서는 무엇을 해야 합니까? https://x.com/jolestar/status/1717358817992995120 비트코인 L1의 상태와 데이터를 어떻게 활용할 것인가에 대한 초기 계획을 L2에서 설계했는데, 댓글에서 친구가 부스터의 계획을 언급했는데 결국 부스터의 계획은 이렇습니다. 실제로 채택되었습니다.
3. 비문은 버그인가요, 아니면 기능인가요? https://x.com/jolestar/status/1732711942563959185에서는 L1과 L2의 인센티브 호환성 문제를 포함하여 L2가 어떻게 구성되는지 관점에서 Inscription의 가치를 설명합니다.
4. 뺄셈 이론을 기반으로 한 롤업 기반 토론 @kerne l1 983 https://web3 caff.com/zh/archives/108241
5. 기반 롤업에 관한 @jason_chen 998의 기사 https://x.com/jason_chen998/status/1799692331635048697
6. 기반 롤업 트랙 연구 보고서 https://research.web3 caff.com/zh/archives/22719
IOS
Android