CSE 645 - Spring 2025

Seminar in Languages

​

Smart Redbelly Blockchain: Reducing Congestion for Web3

​

Deepal Tennakoon Yiding Hua Vincent Gramoli

University of Sydney ETH Zurich University of Sydney

​

Presented by

Divesh Thakker

CSE 645 - Spring 2025

Seminar in Languages

​

Smart Redbelly Blockchain: Reducing Congestion for Web3

​

Deepal Tennakoon Yiding Hua Vincent Gramoli

University of Sydney ETH Zurich University of Sydney

​

Presented by

Divesh Thakker

Web3?

CYMBAL

PRODUCT OVERVIEW

CSE 645 - Spring 2025

Seminar in Languages

​

Smart Redbelly Blockchain: Reducing Congestion for Web3

​

Deepal Tennakoon Yiding Hua Vincent Gramoli

University of Sydney ETH Zurich University of Sydney

​

Presented by

Divesh Thakker

CSE 645 - Spring 2025

Seminar in Languages

​

Smart Redbelly Blockchain: Reducing Congestion for Web3

​

Deepal Tennakoon Yiding Hua Vincent Gramoli

University of Sydney ETH Zurich University of Sydney

​

Presented by

Divesh Thakker

Blockchain?

CYMBAL

PRODUCT OVERVIEW

Define Blockchain.

​

🧱 A blockchain is a decentralized network that records transactions.

​

So how does it work?

​

📦 Block: Data (e.g., transactions) is grouped into a block.

​

🧬 DNA: Each block gets a unique fingerprint (its DNA) using hash.

​

🔗 Chained: The block is linked to the previous one forming a chain.

​

🌐 Distributed: The chain is stored across many computers.

​

🛡️ Tamper-Proof: Any change would require changing all copies.

“Any change would require changing all copies”

​

• Each block’s hash is computed using its own data and previous hash.

​

• If anyone tries to change data in a past block, its hash changes.

​

• But the next block still hashes using the old hash, creating a mismatch.

​

• That breaks the entire chain — instantly exposing tampering.

​

Decentralized Network is the Hardware, but what about Software?

​

That’s Decentralized Applications (Dapps) - just the regular apps, built on blockchain instead of traditional servers.

​

The backend runs on a blockchain network like Ethereum or Solana and uses Cryptocurrency for payments, access or governance.

CSE 645 - Spring 2025

Seminar in Languages

​

Smart Redbelly Blockchain: Reducing Congestion for Web3

​

Deepal Tennakoon Yiding Hua Vincent Gramoli

University of Sydney ETH Zurich University of Sydney

​

Presented by

Divesh Thakker

CSE 645 - Spring 2025

Seminar in Languages

​

Smart Redbelly Blockchain: Reducing Congestion for Web3

​

Deepal Tennakoon Yiding Hua Vincent Gramoli

University of Sydney ETH Zurich University of Sydney

​

Presented by

Divesh Thakker

What is Congestion in Web3?

Congestion happens when too many users try to use the blockchain at once.

​

So what? Are there any downsides?

• ⌛ Processing Delays
• 📭 Lost Transactions

​

Naturally, this will impede scalability and we won’t be able to replace the huge 🌐 Web2.0 with our decentralized 🔗 Web3.0.

​

But how do we know we’re facing congestion?

Congestion ~ Scalability. We already know how to measure scalability:

• ⏱️ Latency
• ⚡ Throughput

CSE 645 - Spring 2025

Seminar in Languages

​

Smart Redbelly Blockchain: Reducing Congestion for Web3

​

Deepal Tennakoon Yiding Hua Vincent Gramoli

University of Sydney ETH Zurich University of Sydney

​

Presented by

Divesh Thakker

CSE 645 - Spring 2025

Seminar in Languages

​

Smart Redbelly Blockchain: Reducing Congestion for Web3

​

Deepal Tennakoon Yiding Hua Vincent Gramoli

University of Sydney ETH Zurich University of Sydney

​

Presented by

Divesh Thakker

Smart Redbelly Blockchain (SRBB)?

The subject of the paper, Smart Redbelly Blockchain (SRBB) is a permissionless blockchain solving the problem of congestion.

​

What is Permissionless?

🌍 Open to all. Anyone can participate in the system without needing any approval.

​

How does SRBB solve Congestion?

1. Transaction Validation and Propagation Reduction (TVPR)
2. Reward Penalty Mechanism (RPM)

​

We will discuss later how TVPR and RPM are indeed responsible to reduce congestion in the blockchain.

Blockchain Demystified…

CYMBAL

PRODUCT OVERVIEW

What is a node in a blockchain?

A blockchain node can either be a client node or validator (miner) node.

​

What is a client node?

Client nodes send read and write requests to the blockchain

​

What is a validator (miner) node?

Validators solve consensus to agree upon the order of client write requests, execute client requests, and services client read requests

Malicious Validators are called Byzantine.

​

​

Transaction

Transactions are write requests sent by clients to the blockchain and are of three main types:

1. Native payments that transfer funds between accounts,
2. Smart contract deployments, and
3. Smart contract invocations that invoke functions

​

Block

A block is a batch of transactions.

​

Account

Clients have accounts in the blockchain that hold their digital assets. An account contains an address (the identifier of the account derived from the account holder’s public key), and a balance (the amount of funds in the account)

What is a smart contract?

Self-executing programs stored on the blockchain that run automatically when predefined conditions are met.

Deployed on chain by users or developers (just like a transaction).

Can be upgraded, paused, or destroyed from the chain.

Eg: Slashing-Reward Logic

​

What is the blockchain protocol?

Protocols permanently written on the node software by the creator of the blockchain.

Hence cannot be created/updated/destroyed by anyone.

Eg: PBFT (Byzantine Fault Tolerant consensus protocol)

Transaction Validation

​

Eager validation: Eager validation occurs when a validator receives a transaction either from another validator or a client.

How does a node Eager Validate?

1. Sender account has sufficient balance
2. Client signature
3. Size of transaction within limits

​

What if the node successfully eager validates?

1. Add the tx to its local logs (transaction pool)
2. Sends this transaction to other validators connected to it

What if the node fails to eager validate?

1. Drop the transaction, i.e. will NOT add to its local logs, neither propagate it further in the network

What is nonce?

Sequence number, enforcing

🧩 Uniqueness, and

🔄 Order of execution of the transaction

​

Lazy validation:

Lazy validation occurs before the transactions in a block are executed.

It checks two things:

🔑 Nonce

⛽ Availability of Gas (cost required to execute a transaction)

​

Lazy validation is less time-consuming than eager validation.

​

When is a transaction considered “valid”?

1. Signed by the correct sender
2. Size does not exceed limit
3. Nonce is the next sequence number
4. Gas cost is covered by the sender balance
5. Transferred amount is covered by the sender balance

​

What does eager validation check?

1,2,5

​

What does lazy validation check?

3,4,5

​

This is important - we’ll revisit this slide later

Problems in Modern Blockchain

There are two major problems causing congestion:

​

1. Redundant eager validation and transaction propagation

​

1. Invalid transaction propagation

​

​

​

Transaction Validation and Propagation Reduction (TVPR)

​

Every validator node ends up validating the same transaction twice:

• First, when the transaction arrives on its own.
• Second, when that transaction appears again in a block.

​

Except at the first node, transaction level eager validation is redundant - we (other nodes) can just eager validate the transaction once when its a part of a block.

​

​

Transaction Validation and Propagation Reduction (TVPR)

We only perform transaction level eager validation once, when a node receives the transaction from the client.

​

Client → Node (transaction): eager validate

Node → Node (transaction): do NOT propagate or eager validate

Node → Node (block): propagate and eager validate

​

In all other cases, transactions will only be eager validated when they are propagated inside a block to other nodes.

Lifecycle of a transaction in SRBB

A Smart Redbelly Blockchain (SRBB) node consists of the SRBB VM and SRBB consensus (Delegated BFT)

​

Stage 1: Reception

The client creates a signed transaction and sends it to one SRBB validator (node) where the transaction is eagerly validated.

If the eager validation:

✅ Succeeds - the transaction is added to the transaction pool

❌ Fails - the transaction is discarded

​

Once the transaction pool (block) is filled, it is propagated to other validator nodes on the network.

​

​

Stage 2: Consensus (upto commit)

In DBFT, everything is parallel. This means multiple validators send blocks to one node and consensus is run for a group of blocks together.

​

After receiving a set of n blocks B = b₁ … b_n, the node executes DBFT consensus for B.

​

After verifying that the majority of nodes are “prepared” with superblock B* (where B* ⊆ B), the node commits superblock B* to the VM for execution.

Stage 3: Execution of Transaction

The VM iterates over each block b in the superblock B* and executes each transaction t inside b, based on the sequence number (determining the global execution order).

​

​

​

​

​

​

​

​

Note: Blocks inside B* may not be in sequence. Transactions inside each block may not be in sequence. It is the responsibility of the VM to execute transaction based on initially assigned sequence numbers.

​

DBFT Protocol

​

​

(Revisiting) When is a transaction considered “valid”?

1. Signed by the correct sender
2. Size does not exceed limit
3. Nonce is the next sequence number
4. Gas cost is covered by the sender balance
5. Transferred amount is covered by the sender balance

​

What does eager validation check?

1,2,5

​

What does lazy validation check?

3,4,5

​

What does execution of transaction check?

1,2 (ErrInvalidSig exception for 1, VM Overflow exception for 2)

​

Stage 3: Execution of Transaction in SRBB (continued)

If the lazy validation succeeds, verifying the

1. Nonce (sequence number)
2. Gas Cost covered by the sender balance
3. Transfer Amount covered by the sender balance

​

the VM applies (executes) the transaction on the current state. This checks:

1. Sender signature
2. Size of transaction

and throws an error if either of the two fail. On success however, the transaction is successfully committed in the block.

​

If all transactions of the block are processed (and the block is not empty), the block is appended to the global blockchain network (Finally, hoorah 🎉)

​

Reward Penalty Mechanism (RPM)

₿ What is a token?

1 token = 1 cryptocurrency coin (eg: 1 bitcoin)

​

💵 What is stake?

The security deposit (to a smart contract) a node locks in to be able to validate on the network.

Eg: Minimum 32 ETH to validate on Ethereum

​

⚔️ What is slashing?

If you misbehave, your stake is slashed (equivalent to losing money!).

​

⛽ Why do validators charge gas (transaction fees)?

They paid money as stake to be appointed as validators. They’re here to earn money and you’re the customer they are serving in return for a fee.

💀 Level of dangers for an adversary.

There can be three levels of adversary.

1. Static: the adversary can never subvert an honest node
2. Slowly Adaptive: the adversary can gradually bribe an honest node (by gradually earning money)
3. Fully Adaptive: can instantly corrupt any node anytime

​

🌍 What is the level of adversary in the real world?

Slowly Adaptive. This is what we will assume for our blockchain too.

​

⛓️ Maximum number of malicious nodes we can handle?

Assuming f nodes are malicious, we require at least 3f+1 total nodes.

​

Membership and Committee reconfiguration

To be a candidate validator, a node must deposit stake to the Committee reconfiguration smart contract.

​

Afterward, the committee reconfiguration protocol randomly selects a set of candidate validators as validators and they form the committee.

​

These validators are rotated periodically, mitigating the committee from being bribed by a slowly adaptive adversary.

​

Invalid transaction propagation

Lets say I am a malicious validator node. I will deliberately add an invalid (failed eager validation) transaction in my block and propagate this block to other (honest) validators. It did not cost me anything, but honest validators will:

1. Waste CPU cycles eager validating invalid transactions before disposing them
2. I hoard network bandwidth sending huge blocks with only one invalid transaction, subsequently invalidating the entire block

What does the malicious node achieve?

The invalid block certainly won’t be committed, but it floods the system with invalid blocks, eventually leading to

1. valid transaction losses
2. performance degradation.

Remember the earlier slides where we discussed exactly this, being the reason for congestion!

​

​

Aren’t there already existing mechanisms that discourage this?

Yes there are, for example - ban those malicious validator nodes. But this does not solve the problem.

​

Why does a ban not stop the malicious nodes from repeating?

By banning a validator, you’re banning its private key. The malicious validator can easily create a new public-private key pair and participate in the blockchain again.

Hence, modern blockchains do not use this ban mechanism.

​

What is a wallet?

Your wallet stores your private key. It doesn’t “store” coins, but has the key you require to access your coins on the blockchain.

​

Reward Penalty Mechanism prevents invalid transaction propagation.

3. The blockchain problem

1. Liveness: if a correct validator receives a valid transaction, then this transaction is eventually reliably stored in the block sequence of all correct validators.

​

1. Safety: the two chains of blocks maintained locally by two correct validators are either identical or one is a prefix of the other.

​

1. Validity: each block appended to the blockchain of each correct validator is a set of valid and non-conflicting transactions

​

​

We can prove that SRBB satisfies all three conditions.

Empirical Evaluation

SRBB was evaluated on the DIstributed Analytical BLOckchain (DIABLO) benchmark suite.

They used the realistic DApp workloads of:

​

📈 NASDAQ (peak request rate - 19800 TPS, avg. request rate - 168 TPS)

🚗 Uber (peak request rate - 900 TPS, avg. request rate - 852 TPS)

⚽ FIFA (peak request rate - 5305 TPS, avg. request rate - 3483 TPS)

​

To measure:

⚡ Throughput

⏱️ Latency

❌ Transaction Loss

​

They used 200 validators spanning 10 AWS regions for this benchmark.

Transaction Loss - what does it mean?

If a transaction isn't included due to

​

• 🚧 Congestion,

​

• 🎭 Malicious Validator, or

​

• 🚫 Being Invalid

​

it will be permanently dropped from the system.

​

In that case, it is the Client’s responsibility to resent after maybe a timeout or some other policy.

Results for transaction loss?

SRBB:

• NASDAQ - ✅ (100% Committed)
• Uber - ✅ (100% Committed)
• FIFA - (98% Committed)

​

Others:

• NASDAQ - (~47% Committed)
• Uber - (~47% Committed)
• FIFA - (2% Committed)

​

Impact of removing redundant eager validations (TVPR)

55x Throughput

-3.5x latency

Transaction losses considerably reduced

Empirical Evaluation

SRBB reached a maximum average throughput of ~ 2000 TPS, outperforming 6 modern blockchains.

Empirical Evaluation

SRBB

Drawbacks of removing redundant eager validations (TVPR)

​

Censorship of transactions (by malicious nodes)

Solution: random load balancer between client and the network, randomly forwarding client requests to different validators to reduce censorship.

​

But this “reduces” censorship, how do we eliminate it completely?

Lets say client is unlucky and the transaction gets forwarded to a malicious validator (who drops it). Client should timeout and send again, and due to randomness there is high probability this time the transaction will be sent to an honest node, eliminating censorship eventually.

​

What if the load balancer itself is malicious?

Well then we have have multiple load balancers and client sending transaction each time to a random load balancer.

Conclusion:

TVPR and RPM are just the first steps towards solving congestion. SRBB may not scale fully on other real world Dapp workloads. That is the future scope on this work.

Thank You.

Questions?

CYMBAL

PRODUCT OVERVIEW