iBatch: Saving Ethereum Fees via Secure and Cost-Effective Batching of Smart-Contract Invocations

Yibo Wang Qi Zhang Kai Li Yuzhe Tang Jiaqi Chen

^{SU SU SU SU SU}

Xiapu Luo

HKPU

Ting Chen

UESTC

Outline

1. Introduction

​

• Approach

​

• Evaluation

2

1. Introduction: Ethereum fees are skyrocketing

• Ethereum’s high fees are for �data movement (tx) & �computation (smart contract).

​

​

• The high fees hurt & scared away DApp customers.

​

​

3

Wanna save fees? … Batching to the rescue

The (basic) idea:

​

• Batching multiple contract invocations in one transaction.

​

• So the base tx fee (21000 Gas) can be amortized over multiple invocations.

4

Empirical evidence: Why batching can work?

• IDEX is a popular financial application on Ethereum.

​

• Some Ethereum blocks have up to 20 IDEX’s trade invocations per block.

​

• Thus, batching those 20 invocations in 1 tx reduces tx fees by 1/20 times.
• And it does not incur any block delay!

5

But batching may not be as easy.

Many EIPs on batching have been proposed

(since 2016), yet none adopted 🙁

​

​

6

Need do batching the right way

We identify technical challenges in invocation batching and address them in our proposed work:

​

iBatch: Saving Ethereum Fee via Secure and Cost-effective Batching of Smart Contract Invocations.

7

2. Approach: Threat Model

Introduce two new intermediaries:

• Untrusted batcher off-chain (modeling infura.io)
• Trusted dispatcher smart contract on-chain

Attacks:

• Integrity: Batcher manipulating invocations
• Forging, omitting, & replaying invocations
• Availability: Batcher refuse to batch (Backup slides)

8

2. Approach: Goals and Challenges

Goals:

1. Security against invocation manipulation.
2. Save costs, instead of bloating them.

​

Challenges:

• A baseline design does not work:
• Baseline: invocation-wise nonce
• The (Dispatcher) smart contracts need to maintain N nonces for N invocations in one batch tx, increasing the cost.
• Generally, needs to tackle the fundamental security-cost tradeoff

9

2. Approach: Security Protocol

• Key idea:
• Reusing a tx-wise nonce to defend against the replays of all N invocations in the batch tx.
• Techniques proposed:
• Off-chain collective �signing
• Stateless smart-�contract on-chain

10

2. Approach: Security Protocol

• How to replay invocations?
• R1. replaying invocation twice.
• R2. replaying a batch transaction with same batcher nonce.
• R3. replaying a batch transaction with a different nonce.
• R4. Batcher forking nonce_B1 to client 1 and nonce_B2 to client 2
• How does our design defend against the attack?
• M1. the bmsg is checked and signed by each user.
• M2. prevented by Ethereum’s native replay protection.
• M3. prevented by smart contract Dispatcher’s verification.
• M4. Prevented by the Dispatcher’s verification.

11

2. Approach: Middleware Systems

• We build a middleware system on Ethereum/Geth
• 3 middleware components at 3 sites
1. Batcher by extending Geth’s RPC components
2. Dispatcher smart �contracts
3. Signers at DApp clients
• Instrument
• Geth running with Batcher
• Callee smart contracts

​

​

12

2. Approach: Integration with Legacy SC

• Callee smart contracts (SC) in iBatch need to authenticate the internal calls from Dispatcher.
• On today’s EVM, this entails rewriting the callee SC
• Propose 2 rewriters on source codes (Solidity) and EVM bytecode.
• Future EVM (with EIP-3074) may support iBatch without rewriting SC.

13

2. Approach: Control Policies

• Our middleware system can be configured to optimize cost and delay with varying workloads.
• We propose a series of heuristics/policies controlling the degree of batching and pricing of batch tx:
• Batch all calls in a W-second window (codename: Wsec)
• Batch only the calls from top-1 caller (Top1)
• Batch only when there are more than X calls in the window (MinX)
• Set batch tx’s Gas price higher than P% of batched calls

14

3. Evaluation: Methodology

• Collect Ethereum transactions & build benchmarks
• Running experiments in a local network of Ethereum nodes
• Measure the cost by replaying the transactions into our prototype
• Gas cost
• Ether cost & delays

15

3. Evaluation: Gas Cost

• Replaying IDEX trace
• Gas per call with a 120sec window:
• Baseline: no batching
• Policy Min5: - 23.68%
• Policy Top1: - 14.59%

​

​

16

3. Evaluation: Ether Costs and Block Delay

• Replaying the trace of transferring Tether tokens
• With 15sec batching window:
• Pricing with batch50%:
• Ether cost: - 19.06%
• Delay: 0.26 blocks
• Pricing with block10%:
• Ether cost: - 31.52%
• Delay: 1.66 blocks

17

​

​

​

​

18

Q/A

Dr. Yuzhe Tang

ytang100@syr.edu

Backup Slides

19

Batcher Availability and Attack

• Attack: The Batcher can refuse to batch invocations
• Mitigation: Impose an incentive scheme (e.g., deposit) on Batcher and callers
• A batcher honestly relaying invocations can redeem the fees, endorsed by callers.
• Further attack: Batcher may see the USD-Ether price change and choose to quit (American call option)
• Further mitigation (FC’19 and PODC’21)

20

How to handle Blockchain reorg

• Blockchain reorg is an event that the current branch of recent blocks is deserted and another competing block branch is chosen to the longest chain.
• Reorg occurs non-deterministically
• We defer to the application layer to handle blockchain reorg in Batcher.

21