한국 블록체인 학회 디사이퍼에서 진행한 Rise Core 개발자 Narumi의 세션을 요약하고, 해당 세션에서 이해한 내용을 정리해보았어요!
사전 지식
Rise Chain은, 빠른 속도가 강점인 체인입니다. 따라서 빠른 속도를 활용할 수 있는 Dapp들이 런칭되고 있고, 저 또한 Relic Marketplace에서 NFT Marketplace 빌더로 참여하고 있는 네트워크 입니다. 테스트넷 런칭이 완료되었고, 현재는 다양한 빌더들이 GameFi 나, 온체인 CLOB 들이 런칭 중입니다. 이번 Narumi와 함께한 세션에서, 어떻게 Core 단에서, 이러한 생태계를 빠른 속도로 뒷받침 할 수 있는지 알게되었습니다.
해당 문서는 Narumi에게 발표 자료를 공유받아 제작했습니다. 고맙습니다.
메인 키워드
세션을 요약해보면 다음과 같은 키워드로 “빠른” Rise Chain의 원리를 이해할 수 있었습니다.
- RETH
- PEVM
- Shred
- CBP
RETH
기본적으로, Rise는 Reth 기반의 체인입니다.
다음의 자료를 보면, reth 기반이 체인의 Gas Limit 별 트랜잭션에 따라 어떠한 속도의 강점을 가지고 있는지 알 수 있습니다.
Geth와의 속도를 평균적으로 비교한다면 다음과 같은 비교가 가능합니다.
30M : 272 Mgas/s vs 508.26 Mgas/s
200M : 287.65 Mgas/s vs 830.90 Mgas/s
따라서, Rise는 Rust 기반의 Reth를 채용함으로써, 빠른 런타임을 가진 언어 기반의 속도 및 다양한 이점을 가지고 있습니다.
PEVM
위 사진은 세션에서 나온 자료입니다. 이더리움 리서치에 따르면, “대부분의 트랜잭션은 독립적이다” 라는 결과를 확인할 수 있다고 합니다. (60 ~ 80% 비율의 트랜잭션들)
이 말은, Rise에서 중요하게 채용하려는 개념인 “병렬로 트랜잭션을 처리하자!” 라는 개념에 매우 부합합니다. 병렬에 가장 걸림돌이 되는 이유는, 의존적인 트랜잭션들이 있기 때문입니다. 그럼에도 불구하고, 의존적인 트랜잭션이 있을 경우 왜 병렬 처리가 가능할까요?
그 이유는 바로 “Optimistic Execution” 이라는 개념을 적용함으로써, 가능해집니다.
하나의 스레드를 활용하여 의존성을 해결하던, 기존의 EVM 과 달리 Optimistic Execution은 “어떤 트랜잭션이든 실행” 합니다. 만일 의존성이 있을 경우, 해당 트랜잭션들만 재실행 하게 됩니다. 또한, 모든 병렬된 트랜잭션은, 실행 순서가 바뀌어도 최종 상태는 동일하게 보장되는 “deterministic outcome” 을 보장합니다.
여기서 의문점이 있습니다.
- 병렬로 처리할 때 어떻게 의존성을 검사하지?
- 의존성을 가질만한 다른 문제(Beneficiary Account)는 어떻게 처리하지?
Rise는 두 가지 개념을 도입하여 해당 의문점에 대한 문제를 해결했습니다.
- Multi Vision Memory
- Lazy Account Balance Update
Multi Vision Memory 는 state slot에 대한 모든 Read & Write 기록을 저장합니다.
위 사진은, Multi Vision Memory의 예시입니다. 총 세 가지의 TX별 하나의 State Slot을 읽고 쓰고 있고, MVM은 이에 대한 버저닝을 진행합니다.
여기서, 만일 State Conflict 가 존재한다면, 해당 트랜잭션은 순차적으로, 의존성을 지키며 실행되게 됩니다.
TX 간의 의존성과 별개로, Beneficiary Account 문제는, 병렬 실행의 큰 걸림돌 입니다.
단순히 한 블록에 포함 될
Frank가 Narumi에게 1이더를 보내고, Frank가 Andy에게 2이더를 보낸다 라는 트랜잭션도, 기존 EVM 환경에서는 의존성을 가지고 있습니다.이는, Gas Payment를 하기 위해 모두 Frank의 balance slot을 접근하게 되므로, 의존성을 띄게 됩니다. 따라서,
Lazy Account Balance Update 라는 개념을 Rise는 도입했습니다. Gas Payment를 위한 Balance Slot 조회를 임시적으로 실행하고, 블록 생성 마지막 시점에서 한번에 계산하는 방법입니다.Shred
PEVM 세션에서는, “트랜잭션을 최대한 병렬로 돌려 쓰루풋을 늘리자!” 라는 요약으로 Rise의 빠른 속도에 대해 이해할 수 있었습니다. 하지만, 실제 Dapp 생태계에서 유저들이 빠름을 체감하기 위해선, 단순히 체인 엔진이 병렬일 뿐만 아니라,
Block Propagation 이 빠르게 진행되어야 합니다.기존의
Block Propagation 스텝은 어떻게 될까요?- 유저는 트랜잭션 요청을 RPC(full node)에 요청
- full node는 트랜잭션을 Sequencer에 넘김
- Sequencer는 트랜잭션을 실행 후 머클라이제이션, 풀노드에 블록 전파
- full node는 블록 검증 위해 다시 실행후 Confirm
- 유저가 상태 변화 감지
Rise 체인은 보편적인
Block Propagation의 스텝을 다음과 같이 변형하였습니다.- 유저는 트랜잭션 요청을 RPC에 요청
- full node는 트랜잭션을 Sequencer에 넘김
- Sequencer는 블록 생성 전, 트랜잭션을 실행 후 Pre-confirmation, Shred에 담아서 풀노드에 전파
- 유저가 상태 변화 감지
한 마디로, Shred는 미니 블록입니다. 다만 블록의 영수증이 생기기 전, 유저들이 미리 결과를 받아 볼 수 있는 캐시 메모리의 역할을 합니다.
CBP + Trie-prefetching
해당 파트는, 기존의 Block Pipeline에서의 문제점을 고치며, 트랜잭션 처리량을 늘려 빠른 속도를 보장할 수 있음을 알 수 있었습니다.
기존의 블록 파이프 라인은 다음과 같습니다.
한 마디로, Consensus time이 너무 길기 때문에, Execution, Merkleization Time을 확보할 수 없습니다. 이는 한 블록에 담길 수 있는 트랜잭션의 수가 적어지고, Merkleization Time도 대기해야 합니다. 또한 블록이 많아질수록, Merkleization Time은 증가합니다.
Rise는 해당 블록 파이프라인을 두 가지 방식으로 개선중입니다.
- Continous Block Pipeline → Execution Time을 확보
실제 Execution Layer의 경우에서 이는 병렬 쓰레드 실행과 Mempool을 적절히 활용하여 구현되어 있습니다.
Main Thread는 Consensus가 끝나는 대로 끊임없이 실행되는 Execution Thread의 트랜잭션의 실행 결과를 블록으로 생성하고, Merkleization을 수행합니다.
- Trie Prefetching → Merkleization Time을 확보
1번의 개념을 통하여, Execution Time은 엄청나게 확보되어, Transaction들의 처리가 밀리지 않게되고, idle한 시간을 갖게 됩니다. 따라서, “이 idle time에 merkleization을 도울 수 있는 정보를 캐시로 만들자” 라는 개념입니다. 다음과 같은 세 가지 쓰레드로 설명하겠습니다.
- PreExecution : Continous하게 트랜잭션을 실행하며, Change Set을 Prefetcher 쓰레드에 전달
- Prefetcher : Change Set을 캐시, Trie node를 캐싱
- Merkleization : 실제 Merkleization 실행 중에 캐싱된 정보를 토대로 계산하며, 누락된 trie node가 있다면 DB 조회
결론
Rise 체인의 테스트넷에 있는 Dapp들은, 다른 Layer2 와 다른 UX를 제공합니다. 이를 위해서 코어 팀에서 제공하고 있는 기술적인 뒷받침들은 단순히 Sequencer를 Scale Up 하는 물리적인 전략이 아닌, 기술적인 완성도로 제공하고 있다는 사실을 알 수 있었습니다.
Dapp을 개발하는 Builder의 입장에서, 네트워크의 코어에 대해서 알고, 이러한 생태계를 활용하고, 이해하고 개발하는 것은 유저들에게 좋은 경험을 줄 수 있는 노력 중의 하나라고 생각이 듭니다.
좋은 설명과 자료를 제공해 준 Rise Chain Narumi 에게 고마움을 표하며, Rise Chain에서 좋은 Builder로 기여하고 싶다는 생각입니다! LFG!