Understanding Ethereum Architecture and Meitu's Open‑Source DPoS Implementation

Recently Ethereum experienced severe congestion again; Meitu implemented a DPoS algorithm on the Ethereum framework and open‑sourced the code, hoping to provide more options for Ethereum's evolution.

Figure: Recent week of widespread Ethereum transaction congestion

For readers unfamiliar with Ethereum, a brief overview of its basic components is provided.

Ethereum consists of several modules:

Protocol management: JSON‑RPC (HTTP) for external access and TCP/UDP for node discovery and block/transaction synchronization.

Transaction pool: stores pending transactions.

Consensus algorithms: currently PoW and PoA (Clique) that decide block creation, validation, and conflict resolution.

EVM: the virtual machine that executes smart‑contract code.

StateDB: composed of a Merkle‑Patricia Trie (MPT) and a KV store; all Ethereum data ultimately resides in the KV store.

Wallets sign transactions and send them via JSON‑RPC to the transaction pool; the consensus algorithm then determines block production timing, and the block is written to the database.

Ethereum prioritizes transactions based on Gas Price, maintaining a max‑heap of high‑price transaction IDs. To prevent replay attacks, each account uses a nonce that increments with each transaction; dependent transactions must be received in nonce order.

Transactions first enter the Queued Pool; if the nonce is valid, they move to the Pending Pool, where they are eligible for inclusion in a block. Pending transactions may return to the Queued Pool after a block rollback.

The consensus algorithm decides block production; the resulting block is stored in the DB. Different account models store balances differently: Bitcoin uses UTXOs, while Ethereum uses an account model.

Ethereum's account balance data is stored in a Merkle‑Patricia Trie (MPT), which combines a Patricia Trie for fast lookups and a Merkle Trie for tamper proof. This tree is shared across all blocks, and each block header stores the trie root.

When a transaction modifies an account, only the affected account node and its parent nodes are copied, producing a new trie root; thus each block reflects the correct balances at that point.

Each block also contains separate transaction and receipt trees, which are independent of other blocks; understanding the Merkle‑Patricia Trie is essential for grasping Ethereum.

The trie nodes are stored in a KV store (currently LevelDB); replacing the KV store only requires implementing basic GET/PUT/DELETE interfaces.

After this overview, the article delves into Meitu's DPoS specifics.

Ethereum offers three sync modes that affect development:

Full sync: downloads all blocks and replays every transaction to reconstruct the global state.

Fast sync (default): downloads all blocks and the state at a chosen pivot block, then replays only subsequent transactions, similar to Redis's RDB+AOF.

Light sync: downloads only block headers, enabling SPV wallets.

Fast sync can cause issues because the pre‑pivot blocks are not replayed, making balance queries unavailable for those blocks.

Meitu's DPoS adds several global state trees to avoid replaying data from genesis:

EpochTrie – records validator lists per epoch.

VoteTrie – maps voters to validators.

CandidateTrie – stores candidate lists.

DelegateTrie – records validators and their voters.

MintCntTrie – tracks the number of blocks produced by each validator per epoch.

These trees, like the account balance tree, are shared across all blocks and their roots are stored in the block header, preventing the need to replay the entire chain for election data.

The implementation details are available on GitHub; the team encourages readers to explore the code directly.

Q&A

Q1: Does DPoS compromise decentralization?

Yes, DPoS concentrates block production to a small set of nodes, trading decentralization for performance; however, similar centralization exists in PoW mining pools.

Q2: Why implement a DPoS on Ethereum if it reduces decentralization?

The team is exploring the trade‑offs; DPoS offers performance benefits despite reduced decentralization.

Q3: How long did the project take and how many person‑months?

Approximately two months of development with a team of three to four people.

Q4: Will there be live source‑code analysis sessions?

No, the team prefers direct code inspection and discussion.

Q5: Have you tested in a real network, and what are the bottlenecks?

Testing is currently limited to an internal network; with a default block time of 5 seconds, performance is 2–3× Ethereum's. Faster block times (≈1 s) are possible with direct node connections.

Q6: Can voting and candidate registration happen at any time, and can any node become a candidate?

Both actions are treated as regular transactions and can occur anytime; however, candidate numbers must be limited to avoid election overhead.

Q7: How are voting and candidate operations reflected in Meitu's Ethereum fork?

They are encoded as transactions with an additional type field distinguishing normal, vote, or candidate operations.

In summary, Meitu's team plans to further extend the technology and invites collaboration.

Code repository: https://github.com/meitu/go-ethereum