opBNB와 이더리움 L2의 성능 차이를 통해 롤업(Rollup)의 병목 현상과 최적화 방식을 이해하기
작성자: Faust, Geeker Web3
서론: 2023년 Web3를 한 키워드로 요약하자면, 대부분 사람들은 아마도 ‘Layer2의 여름’을 떠올릴 것이다. 애플리케이션 계층에서의 혁신이 계속되고 있지만, Layer2처럼 오랫동안 지속되는 장기적 핫이슈는 드물다. Celestia가 모듈형 블록체인 개념을 성공적으로 확산시키면서, Layer2와 모듈화는 거의 인프라의 대명사가 되었고, 단일 체인(Single-chain)의 과거 영광은 다시 보기 어려운 상황이다. Coinbase, Bybit, Metamask 등 주요 거래소들이 각각 전용 2단계(Layer2) 네트워크를 출시한 이후, Layer2 간 경쟁은 마치 초기 신규 공개 블록체인들 사이의 치열한 경쟁과 흡사하다.
이러한 거래소 주도의 Layer2 경쟁 속에서 BNB Chain 역시 뒤처지기를 원하지 않는다. 이미 작년에 그들은 zkBNB 테스트넷을 출시했지만, zkEVM이 아직 규모 있는 애플리케이션 수요를 감당할 만큼의 성능을 제공하지 못하고 있어, Optimistic Rollup 방식의 opBNB가 범용적인 Layer2 구현을 위한 더 나은 선택지로 부상했다.본문에서는 opBNB의 작동 원리와 비즈니스적 의미를 간략히 정리하여, 모듈형 블록체인 시대 속 BSC 공개 블록체인이 내딛은 중요한 한 걸음을 독자들에게 소개하고자 한다.
BNB Chain의 대용량 블록 도전
Solana, Heco 등 거래소가 후원하는 다른 공개 블록체인들과 유사하게, BNB Chain의 BNB Smart Chain(BSC)은 고성능을 오랫동안 추구해 왔다.2020년 출시 당시 BSC는 블록당 가스 용량 상한을 3천만으로 설정하고, 블록 생성 간격을 안정적으로 3초로 유지했다. 이러한 설정 하에서 BSC는 다양한 트랜잭션이 복합된 상태에서 100+ TPS의 처리 한계를 달성했다. 2021년 6월, BSC의 블록 가스 상한은 6천만으로 증가했으나, 같은 해 7월 블록체인 게임 CryptoBlades가 BSC에서 폭발적인 인기를 끌며 일일 트랜잭션 수가 800만 건을 초과하면서 수수료가 급등했다. 이로써 당시 BSC의 효율성 병목 현상이 명확히 드러났다.
（자료 출처: BscScan）
네트워크 성능 문제를 해결하기 위해 BSC는 다시 한번 블록당 가스 상한을 늘렸으며, 이후 장기간 8천만~8천5백만 수준에서 안정화되었다. 2022년 9월, BSC 체인의 단일 블록 가스 상한은 1억2천만으로 상향되었고, 연말에는 1억4천만으로 증가하며 2020년 수준의 약 5배에 달했다.이전에 BSC는 블록 가스 용량 상한을 3억까지 끌어올리는 것을 계획했으나, Validator 노드들의 부담이 너무 크다는 이유로, 이러한 초대용량 블록 제안은 시행되지 않았다.
（자료 출처: YCHARTS）
이후 BNB Chain은 Layer1 확장보다는 모듈화/Layer2 분야에 집중하는 모습을 보이고 있다. 작년 하반기 출시된 zkBNB에서 올해 초 GreenField에 이르기까지 이러한 의도는 더욱 명확해졌다. 모듈형 블록체인/Layer2에 대한 깊은 관심을 바탕으로 본 글은 opBNB를 중심으로 조사하여, opBNB가 이더리움 Layer2와 어떻게 다른지를 통해 Rollup의 성능 병목을 간단히 설명하고자 한다.
BSC의 고처리량이 opBNB의 DA 계층에 주는 강점
众所周시하듯, Celestia는 모듈형 블록체인의 작업 흐름에 따라 다음의 4가지 핵심 구성 요소를 정의했다:
-
실행 계층(Execution): 스마트 계약 코드를 실행하고 상태 전환을 수행하는 환경;
-
결제 계층(Settlement): 위변조 증명 또는 유효성 증명을 처리하며, L2와 L1 간의 브릿지 문제를 해결함;
-
합의 계층(Consensus): 트랜잭션 순서에 대해 합의를 형성함;
-
데이터 가용성 계층(Data Availability, DA): 블록체인 원장 데이터를 게시하여 검증자가 해당 데이터를 다운로드할 수 있도록 함.
여기서 DA 계층과 합의 계층은 종종 결합되어 있다. 예를 들어, 낙관형 롤업(Optimistic Rollup)의 DA 데이터는 일련의 L2 블록 내 트랜잭션 순서를 포함한다. L2 전체 노드가 DA 데이터를 획득하면, 각 트랜잭션의 순서를 즉시 알 수 있다. (이 때문에 이더리움 커뮤니티는 롤업을 분류할 때 DA 계층과 합의 계층이 밀접하게 연결되어 있다고 본다.)
그러나 이더리움 기반의 Layer2의 경우, DA 계층(즉 이더리움)의 데이터 처리량이 롤업 성능의 가장 큰 병목이 된다. 현재 이더리움의 데이터 처리량이 매우 낮아 롤업은 자신의 TPS를 억제해야 하며, 그렇지 않으면 이더리움 메인넷이 L2에서 발생하는 데이터를 감당하지 못하게 된다.
또한 낮은 데이터 처리량으로 인해 이더리움 네트워크 내 다수의 트랜잭션이 대기 상태에 머무르며, 이는 가스비를 극도로 높이는 결과를 초래하고, L2의 데이터 게시 비용 또한 상승시킨다. 결국 많은 레이어2 네트워크들이 이더리움 외부의 DA 계층(예: Celestia)을 사용할 수밖에 없게 되는데, 반면 opBNB는 '근접한 자'로서 고처리량의 BSC를 직접 DA 계층으로 활용해 데이터 게시 병목을 해결한다.
이해를 돕기 위해 롤업의 DA 데이터 게시 방식을 간단히 설명하겠다.Arbitrum을 예로 들면, Layer2 정렬기(Orderer)가 관리하는 이더리움 EOA 주소는 정기적으로 특정 스마트계약으로 트랜잭션을 보내며, 이 트랜잭션의 입력 파라미터 calldata 필드에 패킹된 트랜잭션 데이터를 기록하고, 스마트컨트랙트 로그에 영구 기록을 남긴다.
이렇게 하여 L2의 트랜잭션 데이터는 이더리움 블록에 장기 저장되며, L2 노드를 운영할 수 있는 사용자는 해당 기록을 다운로드하고 데이터를 파싱할 수 있다. 그러나 이더리움 자체 노드는 이 L2 트랜잭션을 실행하지 않는다. 쉽게 말해, L2는 트랜잭션 데이터를 이더리움 블록에 저장하여 스토리지 비용을 부담하고 있으며, 실제 실행 계산 비용은 L2 자체 노드가 부담한다.
위에서 설명한 것이 Arbitrum의 DA 구현 방식이며, Optimism은 정렬기가 관리하는 EOA 주소가 다른 특정 EOA 주소로 전송하면서, 부가 데이터에 새로운 L2 트랜잭션 묶음을 포함시킨다. 그리고OP Stack 기반의 opBNB는 Optimism의 DA 데이터 게시 방식과 기본적으로 동일하다.
분명히, DA 계층의 처리량은 단위 시간 당 롤업이 게시할 수 있는 데이터 크기에 제한을 두며, 이는 곧 TPS에도 영향을 준다. EIP1559 이후 이더리움 블록의 가스 용량은 3천만으로 안정화되었으며, Merge 이후 블록 생성 시간은 약 12초로, 초당 처리 가능한 최대 가스량은 250만에 불과하다.
대부분의 경우, L2 트랜잭션 데이터를 담는 calldata는 1바이트당 16가스를 소모하므로, 이더리움은 초당 최대 약 150KB의 calldata만 처리할 수 있다.반면 BSC는 초당 최대 약 2,910KB의 calldata를 처리 가능하며, 이는 이더리움의 18.6배에 달한다. 두 플랫폼의 DA 계층으로서의 격차는 명확하다.
요약하면, 이더리움은 초당 약 150KB의 L2 트랜잭션 데이터만 처리할 수 있다. EIP-4844가 도입된 후에도 이 숫자는 크게 변하지 않으며, 다만 DA 수수료가 낮아질 뿐이다.그렇다면 초당 150KB는 대략 얼마나 많은 트랜잭션 데이터를 포함할 수 있을까?
롤업의 데이터 압축률에 대해 설명할 필요가 있다. 비탈릭(Vitalik)은 2021년 낙관적으로 추정하기를, 낙관형 롤업은 트랜잭션 데이터 크기를 기존의 11% 수준까지 압축할 수 있다고 했다. 예를 들어, 가장 기초적인 ETH 전송은 원래 112바이트의 calldata를 차지하지만, 낙관형 롤업으로 12바이트로 압축 가능하며, ERC-20 전송은 16바이트, Uniswap의 Swap 거래는 14바이트로 압축 가능하다고 했다. 이에 따르면, 이더리움은 초당 약 1만 건의 L2 트랜잭션(다양한 유형이 혼합된)을 기록할 수 있다는 계산이 나온다. 그러나 Optimism 공식이 2022년 공개한 데이터에 따르면,실제 적용된 데이터 압축률은 최대 약 37%에 그쳐 비탈릭의 추정치보다 3.5배 낮았다.
（비탈릭의 롤업 확장 효과 추정은 실제와 상당히 벗어남）
（Optimism이 공개한 다양한 압축 알고리즘의 실제 압축률）
따라서 합리적인 수치를 제시할 수 있다.현재 이더리움이 처리량 한계에 도달하더라도, 모든 낙관형 롤업의 총합 TPS는 겨우 2,000건을 넘지 못한다. 즉, 이더리움 블록의 모든 공간을 Arbitrum, Optimism, Base, Boba 등의 낙관형 롤업이 점유한다고 해도, 이들의 TPS 총합은 3,000에 미치지 못하며, 이는 압축 알고리즘이 최고 효율을 발휘할 때의 상황이다. 게다가 EIP1559 이후 각 블록이 평균적으로 최대값의 50% 가스만을 처리한다는 점을 고려하면, 위의 수치는 절반으로 줄어야 한다.EIP4844 도입 후에는 데이터 게시 수수료가 크게 낮아지겠지만, 이더리움 블록의 최대 크기는 크게 변하지 않을 것이며(너무 많이 변경하면 ETH 메인체인의 보안에 영향), 따라서 위에서 산출한 수치는 크게 개선되지 않는다.
Arbiscan 및 Etherscan 데이터에 따르면, Arbitrum의 하나의 트랜잭션 배치는 1,115건의 트랜잭션을 포함하며 이더리움에서 181만 가스를 소모했다. 이를 추산하면,DA 계층의 모든 블록이 꽉 찼다고 가정할 때 Arbitrum의 이론적 TPS 한계는 약 1,500이다. 그러나 L1 블록 리오더링(reorg) 문제를 고려하면 Arbitrum은 매번 이더리움 블록마다 트랜잭션 배치를 게시할 수 없으므로, 위의 수치는 현재 이론상의 값에 불과하다.
또한 EIP-4337 관련 스마트 월렛이 대규모로 채택된 이후에는 DA 문제가 더욱 심각해진다. EIP-4337 지원 후 사용자의 인증 방식이 커스터마이징 가능해지며, 예를 들어 지문이나 홍채 정보의 바이너리 데이터를 업로드할 수 있는데, 이는 일반 트랜잭션이 차지하는 데이터 크기를 추가로 증가시킨다. 따라서 이더리움의 낮은 데이터 처리량은 롤업 효율성을 제한하는 가장 큰 병목이며, 이 문제는 향후 오랜 기간 동안 적절히 해결되기 어려울 가능성이 크다.
반면 BNB 체인의 BSC는 초당 평균적으로 최대 약 2,910KB의 calldata를 처리할 수 있어, 이더리움의 18.6배에 달한다. 즉, 실행 계층의 속도만 따라잡는다면 BNB 체인 생태계의 Layer2는 이론적 TPS 한계가 ARB나 OP의 약 18배 수준에 이를 수 있다. 이 수치는 현재 BNB 체인의 블록당 최대 가스 용량 1.4억, 블록 생성 시간 3초를 기반으로 계산된 것이다.
즉,현재 BNB 체인 기반의 모든 롤업의 총합 TPS 한계는 이더리움의 18.6배에 달한다(ZK롤업을 포함하더라도 마찬가지이다). 이를 통해 많은 Layer2 프로젝트들이 왜 굳이 이더리움 외부의 DA 계층을 이용하는지를 이해할 수 있다. 그 차이는 명확하기 때문이다.
그러나 문제는 이렇게 단순하지 않다. 데이터 처리량 외에도,L1 자체의 안정성 또한 L2에 영향을 미친다. 대부분의 롤업은 몇 분 간격으로 이더리움에 트랜잭션 배치를 게시하는데, 이는 L1 블록 재구성 가능성 때문입니다. 만약 L1 블록이 재구성되면, L2의 블록체인 원장에도 영향을 미친다. 따라서 정렬기는 L2 트랜잭션 배치를 게시한 후, 여러 개의 새로운 L1 블록이 생성되어 블록 롤백 확률이 크게 낮아진 후에야 다음 배치를 게시한다. 이는 실제로 L2 블록의 최종 확정 시간을 지연시키며, 대규모 거래의 확인 속도를 저하시킨다(대액 거래는 결과가 불가역적이어야 안전성이 보장됨).
간단히 정리하면,L2에서 발생한 트랜잭션은 DA 계층 블록 내에 게시되고, DA 계층에서 일정 수의 새 블록이 추가로 생성된 후에야 불가역성을 갖게 되며, 이는 롤업 성능을 제한하는 중요한 요인 중 하나이다. 그러나 이더리움은 블록 생성 속도가 느려 12초마다 하나의 블록을 생성하며, 롤업이 15개 블록마다 하나의 L2 배치를 게시한다고 가정하면, 배치 간격은 3분이 된다. 각 배치 게시 후에도 여러 개의 L1 블록이 생성되어야 불가역성이 확보된다(도전받지 않는다는 전제 하에). 명백히 이더리움 L2의 거래는 시작부터 불가역 상태까지 대기 시간이 매우 길며, 결제 속도가 느리다. 반면 BNB 체인은 3초마다 블록을 생성하며, 블록 불가역성 확보는 45초(15개의 새로운 블록 생성 시간)만 필요하다.
현재의 파라미터를 기반으로,L2 트랜잭션 수가 동일하고 L1 블록의 불가역성을 고려할 경우,단위 시간 내opBNB가 트랜잭션 데이터를 게시하는 횟수는 Arbitrum의 최대 8.53배에 이를 수 있다(전자는 45초마다, 후자는 6.4분마다). 따라서 opBNB에서 대규모 거래의 결제 속도는 이더리움 L2보다 훨씬 빠르다.또한 opBNB가 매번 게시할 수 있는 최대 데이터량은 이더리움 L2의 4.66배에 달한다(전자의 L1 블록 가스 상한은 1.4억, 후자는 3천만).
8.53 × 4.66 = 39.74. 이것이 현재 opBNB와 Arbitrum이 TPS 한계에서 실질적으로 존재하는 차이이다. (현재 ARB는 보안상의 이유로 의도적으로 TPS를 낮추고 있으나, 이론적으로 TPS를 높이려 한다면 여전히 opBNB보다 훨씬 낮다.)
（Arbitrum 정렬기는 약 6~7분마다 한 번씩 트랜잭션 배치를 게시함）
（opBNB 정렬기는 1~2분마다 트랜잭션 배치를 게시하며, 최단 45초만에 가능함）
물론 고려해야 할 더 중요한 문제가 있다. 바로 DA 계층의 가스 수수료 문제이다. L2가 트랜잭션 배치를 게시할 때마다 calldata 크기와 무관한 고정 비용—21,000 가스가 발생하며, 이 또한 비용이다. 만약 DA 계층/L1의 수수료가 매우 높아 L2의 배치 게시 고정 비용이 계속 높아진다면, 정렬기는 배치 게시 빈도를 낮출 것이다. 또한 L2 수수료를 고려할 때 실행 계층 비용은 매우 낮아 대부분 무시할 수 있으며, 수수료에 영향을 주는 것은 주로 DA 비용이다.
결론적으로, 이더리움과 BNB 체인에 동일한 크기의 calldata를 게시할 경우 소모되는 가스는 같지만, 이더리움의 가스 가격은 BNB 체인의 10배에서 수십 배에 달한다. 이는 L2 수수료로 전가되어,현재 이더리움 Layer2의 사용자 수수료는 opBNB의 약 10~수십 배 수준이다. 종합적으로 보면, opBNB와 이더리움 기반 낙관형 롤업 사이의 차이는 매우 뚜렷하다.
（Optimism에서 15만 가스를 소모한 거래의 수수료는 0.21달러）
（opBNB에서 13만 가스를 소모한 거래의 수수료는 0.004달러）
그러나 DA 계층의 데이터 처리량을 확대하더라도 전체 Layer2 시스템의 처리량은 증가하지만, 개별 롤업의 성능 향상에는 한계가 있다. 왜냐하면 실행 계층의 트랜잭션 처리 속도가 종종 충분히 빠르지 않기 때문이다. DA 계층의 제약이 사라져도 실행 계층이 다음 병목이 될 수 있다. 만약 Layer2 실행 계층이 느리다면, 넘치는 거래 수요는 다른 Layer2로 분산되어 궁극적으로 유동성 분열을 초래할 수 있다. 따라서 실행 계층의 성능 향상도 중요하며, DA 계층 이후의 또 다른 장벽이다.
opBNB의 실행 계층 강화: 캐시 최적화
많은 사람들이 블록체인 실행 계층의 성능 병목을 언급할 때, 반드시 언급하는 두 가지는 EVM의 싱글 스레드 직렬 실행 방식이 CPU를 충분히 활용하지 못하고, 이더리움이 사용하는 Merkle Patricia Trie의 데이터 탐색 효율이 낮다는 것이다. 이 두 가지는 중요한 실행 계층 병목이다. 요약하면, 실행 계층의 확장 아이디어는 CPU 자원을 더 충분히 활용하고, CPU가 데이터를 가능한 빨리 가져오는 것이다. EVM의 직렬 실행 및 Merkle Patricia Tree를 최적화하는 방안은 종종 복잡하고 구현이 어렵기 때문에, 투자 대비 효과가 높은 작업은 주로 캐시 최적화에 집중된다.
사실 캐시 최적화 문제는 전통적인 Web2 혹은 교과서에서도 자주 논의되는 주제로 돌아간다.
일반적으로 CPU가 메모리에서 데이터를 읽는 속도는 디스크에서 읽는 속도의 수백 배에 달한다. 예를 들어, 특정 데이터를 CPU가 메모리에서 읽는 데 0.1초가 걸린다면, 디스크에서 읽는 데는 10초가 걸릴 수 있다. 따라서 디스크 입출력에서 발생하는 오버헤드를 줄이는 것, 즉 캐시 최적화는 블록체인 실행 계층 최적화에서 필수적인 부분이다.
이더리움을 비롯한 대부분의 공개 블록체인에서, 체인상 주소 상태를 기록하는 데이터베이스는 디스크에 완전히 저장되며,所谓 세계 상태(World State) 트리는 이 데이터베이스의 인덱스 혹은 데이터 탐색을 위한 목록 역할을 한다. EVM이 매번 스마트 계약을 실행할 때 관련 주소 상태를 가져와야 하는데, 모든 데이터를 디스크에 저장된 데이터베이스에서 일일이 가져온다면, 거래 실행 속도가 심각하게 저하될 것이다.따라서 데이터베이스/디스크 외부에 캐시를 설정하는 것은 필수적인 가속화 수단이다.
opBNB는 BNB 체인이 사용하는 캐시 최적화 방안을 직접 채택했다. opBNB의 협력사 NodeReal이 공개한 정보에 따르면, 초기 BSC 체인은 EVM과 상태를 저장하는 LevelDB 데이터베이스 사이에 3단계 캐시를 설정했으며, 설계 개념은 전통적인 3단계 캐시와 유사하다. 즉, 접근 빈도가 높은 데이터를 캐시에 저장하여 CPU가 먼저 캐시에서 필요한 데이터를 찾도록 한다. 캐시 적중률이 충분히 높다면 CPU는 디스크에 과도하게 의존하지 않고도 데이터를 획득할 수 있으며, 전체 실행 속도가 크게 향상된다.
이후 NodeReal은 이를 기반으로 기능을 추가하여, EVM이 사용하지 않는 유휴 CPU 코어를 동원해 EVM이 미래에 처리할 데이터를 미리 데이터베이스에서 읽어 캐시에 저장함으로써, EVM이 미래에 캐시에서 직접 필요한 데이터를 가져올 수 있도록 했다.이 기능을 ‘상태 사전 읽기(State Prefetching)’라고 한다.
상태 사전 읽기의 원리는 간단하다: 블록체인 노드의 CPU는 멀티코어이며, EVM은 싱글 스레드 직렬 실행 모드로 단 하나의 CPU 코어만 사용하므로 나머지 코어는 충분히 활용되지 않는다. 이를 해결하기 위해, EVM이 사용하지 않는 CPU 코어들이 일을 맡게 한다. 이 코어들은 EVM이 아직 처리하지 않은 트랜잭션 시퀀스를 통해 미래에 EVM이 사용할 데이터를 미리 파악한 후, 데이터베이스에서 해당 데이터를 읽어 EVM이 사용할 준비를 해둔다. 이를 통해 EVM의 데이터 획득 오버헤드를 줄이고 실행 속도를 높인다.
캐시 최적화를 충분히 수행한 후, 성능이 충분한 하드웨어 구성과 함께,opBNB는 노드 실행 계층의 성능을 사실상 EVM의 한계 근처까지 끌어올렸다: 초당 최대 1억 가스를 처리할 수 있다. 1억 가스는 수정 없이 사용하는 EVM의 성능 천장에 해당한다(한 유명 공개 블록체인의 실험 테스트 데이터 기반).
구체적으로 요약하면, opBNB는 초당 최대 4,761건의 가장 간단한 전송 거래, 1,500~3,000건의 ERC20 전송, 약 500~1,000건의 SWAP 작업을 처리할 수 있다(블록 탐색기의 거래 데이터 기반). 현재 파라미터를 비교하면,opBNB의 TPS 한계는 이더리움의 40배, BNB 체인의 2배 이상, Optimism의 6배 이상이다.
물론,이더리움 Layer2는 DA 계층 자체의 심각한 제약으로 인해 실행 계층이 제대로 발휘되지 못하며, 앞서 언급한 DA 계층의 블록 생성 시간, 안정성 등을 모두 고려하면, 이더리움 Layer2의 실제 성능은 실행 계층 성능보다 크게 떨어진다. 반면 BNB 체인처럼 고처리량 DA 계층의 경우, 2배 이상의 확장 효과를 보는 opBNB는 매우 가치 있으며, 더군다나 BNB 체인은 이러한 확장 프로젝트를 여러 개 수용할 수 있다.
예상할 수 있듯,BNB 체인은 이미 opBNB를 중심으로 한 Layer2 전략을 포트폴리오에 포함시켰으며, 앞으로도 더 많은 모듈형 블록체인 프로젝트들을 수용할 예정이다. opBNB에 ZK proof를 도입하고, GreenField 등의 인프라를 결합하여 고가용성 DA 계층을 제공하며, 이더리움 Layer2 체계와 경쟁하거나 협력하려는 시도를 할 것이다. 계층화 확장이 대세가 된 지금, 다른 공개 블록체인들도 BNB 체인을 따라 자신의 Layer2 프로젝트를 육성할지 여부는 시간이 지나봐야 알 수 있다. 하지만 분명한 것은 모듈형 블록체인을 방향으로 한 인프라 패러다임의 혁명이 이미 진행 중이며, 이미 시작되었다는 점이다.
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
@godrealmx
