Web3 Builder Frank's Archive

🇰🇷 Korean

💡

한국 블록체인 학회 디사이퍼에서 진행한 Rise Core 개발자 Narumi의 세션을 요약하고, 해당 세션에서 이해한 내용을 정리해보았어요!

사전 지식

Rise Testnet Explorer - Explore tokens, applications, and more on the Rise Testnet

https://portal.risechain.com/

Rise Chain은, 빠른 속도가 강점인 체인입니다. 따라서 빠른 속도를 활용할 수 있는 Dapp들이 런칭되고 있고, 저 또한 Relic Marketplace에서 NFT Marketplace 빌더로 참여하고 있는 네트워크 입니다. 테스트넷 런칭이 완료되었고, 현재는 다양한 빌더들이 GameFi 나, 온체인 CLOB 들이 런칭 중입니다. 이번 Narumi와 함께한 세션에서, 어떻게 Core 단에서, 이러한 생태계를 빠른 속도로 뒷받침 할 수 있는지 알게되었습니다.

해당 문서는 Narumi에게 발표 자료를 공유받아 제작했습니다. 고맙습니다.

메인 키워드

세션을 요약해보면 다음과 같은 키워드로 “빠른” Rise Chain의 원리를 이해할 수 있었습니다.

RETH

PEVM

Shred

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!

💡

I have summarized and organized what I learned from the Rise Core developer Narumi's session at the Korean Blockchain Society Decipher.

Background

Rise Testnet

Rise Testnet Explorer - Explore tokens, applications, and more on the Rise Testnet

https://portal.risechain.com/

Rise Chain is a blockchain network known for its high-speed performance. As a result, many Dapps that leverage this speed are being launched, and I myself am participating as an NFT marketplace builder for Relic Marketplace on this network. The testnet has already been launched, and various builders are currently releasing GameFi projects and on-chain CLOBs. Through this session with Narumi, I gained insight into how the core infrastructure is able to support this ecosystem at such high speed.

This document was created based on the presentation materials shared by Narumi. Thank you.

Main Keywords

To summarize the session, the following keywords helped us understand the principles behind the fast Rise Chain:

RETH

PEVM

Shred

RETH

Fundamentally, Rise is a Reth-based chain.

As shown in the following data, we can see how a Reth-based chain demonstrates speed advantages depending on transactions per gas limit.

When comparing its performance to Geth on average, the differences can be summarized as follows:

💡

30M : 272 Mgas/s vs 508.26 Mgas/s

200M : 287.65 Mgas/s vs 830.90 Mgas/s

Therefore, by adopting Reth—which is built in Rust—Rise benefits from the speed and various advantages of a high-performance, low-level language runtime.

PEVM

The image above is a slide from the session. According to Ethereum research, it was found that “most transactions are independent”, accounting for about 60–80% of all transactions.

This insight aligns perfectly with one of the core ideas Rise aims to adopt: “processing transactions in parallel.”

The main challenge to parallel execution lies in dependent transactions. But then, how is parallel processing possible even when dependencies exist?

The answer lies in the concept of “Optimistic Execution.”

Unlike the traditional EVM, which resolves dependencies through single-threaded execution, Optimistic Execution simply executes all transactions, regardless of potential dependencies. If a dependency is later detected, only those conflicting transactions are re-executed. Furthermore, even when transactions are executed in parallel and out of order, a deterministic outcome is guaranteed—meaning the final state remains consistent.

However, this raises a few important questions:

How are dependencies detected during parallel execution?

How are other potential issues—such as those involving beneficiary accounts—handled?

Rise solves these problems by introducing two key concepts:

Multi Vision Memory

Lazy Account Balance Update

Multi Vision Memory records all read and write operations on state slots, enabling precise tracking of access patterns to detect conflicts.

The image above illustrates an example of Multi Vision Memory (MVM). In this case, three different transactions (TXs) are reading from and writing to the same state slot. MVM versions each of these accesses to track changes across multiple parallel executions.

If a state conflict is detected—meaning that multiple transactions write to or depend on the same slot—those conflicting transactions are then executed sequentially, preserving their dependencies.

Beyond dependencies between transactions, another major bottleneck to parallel execution is the Beneficiary Account problem.

Even a seemingly simple pair of transactions in a single block—such as:

“Frank sends 1 ETH to Narumi” and “Frank sends 2 ETH to Andy”

—would be treated as dependent under a traditional EVM environment.

Why? Because both transactions need to access Frank’s balance slot to pay gas, creating a shared dependency.

To overcome this, Rise introduces the concept of Lazy Account Balance Update.

Rather than updating the balance slot immediately during each transaction’s gas payment, Rise defers this process. All balance checks are temporarily handled during execution, and the actual balance updates are applied once at the end of block execution—in one consolidated step.

This greatly reduces unnecessary execution conflicts and unlocks more opportunities for true parallelism.

Shred

In the PEVM session, the key takeaway was:

“Let’s run as many transactions in parallel as possible to maximize throughput!”

This provided a solid understanding of how Rise achieves its fast execution speed.

However, in order for users to actually perceive this speed in real Dapp ecosystems, it’s not enough for just the chain engine to be parallelized.

Fast block propagation is equally critical—ensuring that new blocks are distributed and recognized across the network quickly.

What does the traditional Block Propagation process look like?

User submits a transaction to an RPC endpoint (full node).

The full node forwards the transaction to the sequencer.

The sequencer executes the transaction, constructs a Merkleized block, and broadcasts the block to full nodes.

Each full node re-executes the block to verify correctness and then confirms it.

The user finally observes the state change.

Rise Chain modifies the conventional Block Propagation steps as follows:

User submits a transaction to the RPC (full node).

The full node forwards the transaction to the sequencer.

Before the block is finalized, the sequencer executes the transaction, provides a pre-confirmation, and sends the result via Shreds to full nodes.

The user perceives the state change almost immediately.

In short, a Shred is like a mini block.

However, unlike a finalized block, it serves as a cache memory that allows users to preview transaction results before official block receipts are generated.

CBP + Trie-prefetching

This section shows how Rise addresses the limitations of the traditional block pipeline, ultimately increasing transaction throughput and ensuring faster performance.

The conventional block pipeline typically follows this sequence:

In short, the consensus time in traditional pipelines is too long, leaving insufficient time for execution and Merkleization.

Rise is improving the traditional block pipeline in two key ways:

Continuous Block Pipeline → Rise secures more dedicated execution time.

In the actual Execution Layer, this is implemented by:

The main thread continuously creates blocks and performs Merkleization using the execution results from the execution threads, as soon as consensus is completed.

Trie Prefetching → Securing Merkleization Time

Through the concept described in step 1, execution time is significantly secured, preventing transaction processing from becoming a bottleneck and resulting in idle time.

This leads to the idea:

“Let’s use this idle time to cache information that can assist with Merkleization.”

The process can be described using the following three threads:

PreExecution: Continuously executes transactions and sends the resulting change sets to the Prefetcher thread.

Prefetcher: Caches the change sets and preloads the necessary Trie nodes into memory.

Merkleization: When Merkleization begins, it uses the cached information for computation. If any Trie nodes are missing, it retrieves them from the database.

Conclusion

The Dapps on Rise Chain’s testnet deliver a user experience that sets them apart from other Layer 2 networks.

What’s remarkable is that the technical foundation provided by the core team goes beyond simply scaling up the sequencer through physical means—it reflects a high level of technical craftsmanship.

As a builder developing Dapps, I believe that understanding the network’s core, leveraging this ecosystem, and building with that understanding in mind is one of the most meaningful ways to create better experiences for users.

I’d like to express my gratitude to Narumi from Rise Chain for the clear explanations and insightful materials, and I’m more motivated than ever to contribute as a strong builder within the Rise Chain ecosystem. LFG!

Insight from Rise Chain Core Session

사전 지식

메인 키워드

RETH

PEVM

Shred

CBP + Trie-prefetching

결론

Background

Main Keywords

RETH

PEVM

Shred

CBP + Trie-prefetching

Conclusion