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

Paper / Discussion Title

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

  • Link to source

  • PDF: https://tristartom.github.io/docs/fse21-ibatch.pdf

  • Content type tag (summary, discussion)

  • post-idea

  • Category

  • post-idea

  • Proposed tags

  • Blockchains, smart contracts, DeFi, cost effectiveness, replay attacks

  • Description of why this would be an interesting post

  • Ethereum charges a high unit cost for data movement (via transactions) and for data processing (via smart-contract execution). To optimize the transaction fee, a natural idea is to batch multiple smart-contract invocations in a single transaction so that the fee can be amortized. However, the third-party server that assumes the job of batching can mount attacks to forge, replay, modify and even omit the invocations. A naive design to defend against the invocation manipulations by validating invocations on blockchains incur high cost that offsets the saving intended by the batching.

  • We present iBatch, a middleware system retrofittable on an unmodified Ethereum network to batch smart-contract invocations securely against an off-chain relay server. iBatch achieves low-cost invocation validation by offloading the majority of validation work to the caller EOAs (assumed to be available here) and leaving on-chain validation stateless.

  • We conduct extensive cost evaluations, which shows iBatch saves 14.6% ∼ 59.1% Gas cost per invocation with a moderate 2 minute delay and 19.06% ∼ 31.52% Ether cost per invocation with a delay of 0.26 ∼ 1.66 blocks

  • Links to background reading (0 to 3 items)

  • Extended version: [2106.08554] iBatch: Saving Ethereum Fees via Secure and Cost-Effective Batching of Smart-Contract Invocations

  • Corresponding author: http://ecs.syr.edu/faculty/yuzhe

  • Conference website: Towards Practical and Cost-Effective Batching of Smart-Contract Invocations on Ethereum (ESEC/FSE 2021 - Research Papers) - ESEC/FSE 2021

  • Ethereum, the second-largest blockchain after Bitcoin and the most popular DApp platform, charges a high unit cost for data movement (via transactions) and for data processing (via smart-contract execution). For instance, sending one-megabyte application data to Ethereum costs 17.5 Ether or more than 25, 000 USD (at the exchange rate as of Jan. 2021), which is much more expensive than alternative centralized solutions (e.g., cloud services) and has scared away customers (e.g., Binance).

  • To optimize the transaction fee, a natural idea is to batch multiple smart-contract invocations in a single transaction so that the fee can be amortized.

  • Invocation batching has long been craved for among Ethereum developers, evidenced by a number of Ethereum Improvement Proposals (EIPs). It still lacks real-world support of invocation batching in Ethereum, as these EIPs are not made into production after years of discussion.

  • In a naïve batching design, the third-party Batcher can mount attacks to forge, replay, modify and even omit the invocations from the callers.

Summary

  • We design a security batching framework. it prevents the Batcher from forging or replaying a caller’s invocation in a batch transaction. It also ensures the Batcher’s attempt to omit a caller’s invocations can be detected by the victim caller. In addition, iBatch can be extended to prevent a denial-of-service caller from delaying a batch.
  • We propose mechanisms and policies for the Batcher to properly batch invocations for design goals in cost and delay.

Method:

  • The iBatch protocol works in the following four steps:

    • In the batch time window, a caller submits the 𝑖-th invocation request, denoted by call_i, to the Batcher service.
    • By the end of the batch time window, the Batcher prepares a batch message bmsg and sends it to the callers for validation and signing. Message bmsg is a concatenation of the 𝑁 requests, call_i’s, their caller nonces nonce_i ’s, and Batcher account’s nonce, nonce_B. Each of the callers checks if there is one and only one copy of its invocation in the batch message. After a successful check of equality, the caller signs the message bmsg_sign, that is, bmsg without callers’ nonces. She then sends her signature to the Batcher.
    • Batcher includes the signed batch message in a transaction’s data field and sends the transaction, called batch transaction, to be received by the Dispatcher smart contract.
    • In function dispatch_func, smart contract Dispatcher parses the transaction and extracts the original invocations call_i before forwarding them to callees. smart-contract Dispatcher internally verifies the signature of each extracted invocation against its caller’s public key; this can be done by using Solidity function ecrecover(call𝑖,sig𝑖,account𝑖).
  • When running legacy smart contracts on iBatch, the smart contracts need to be rewritten to authenticate the internal calls from Dispatcher smart contract. We propose source code and bytecode rewriting techniques.

Results

  • We conduct extensive cost evaluations, which shows iBatch saves 14.6% ∼ 59.1% Gas cost per invocation with a moderate 2-minute delay and 19.06% ∼ 31.52% Ether cost per invocation with a delay of 0.26 ∼ 1.66 blocks.

Discussion & Key Takeaways

  • We design a lightweight security protocol for batching of smart contract invocations in Ethereum without trusting third-party servers
  • We design a middleware system implementing the above protocol and propose batching policies from conservative to aggressive batching.
  • We built an evaluation platform for fast and cost-accurate transaction replaying and constructed transaction benchmarks on popular Ethereum applications.

Implications and Follow-ups

  • We note that a recent Ethereum Improvement Proposal (i.e., EIP- 3074) may facilitate the integration of iBatch with legacy smart contracts. In the future, if EIP-3074 is adopted by the Ethereum protocol, it would allow integrating iBatch with legacy smart contracts without rewriting.

Applicability

  • Our iBatch is a general protocol for all kinds of Dapp transactions with a tradeoff between cost-saving and delay. It is a very useful middleware for Ethereum users. For the Dapp team or institutional caller, which may send a lot of transactions during a short time, iBatch can help them save cost.
8 Likes

Welcome to the forum, @ywang349! That’s a great suggestion for a summary. Transaction batching has been predominantly done on UTXO-based chains, so it would be interesting to see how this would be applied to Ethereum – the benchmarks seem promising.

6 Likes

Because Ethereum transaction fee are too expensive, many Dapp companies are leaving Ethereum. Like Binance, they develop their own blockchain.

UTXO-based chain can natively support batching because it can accept many inputs and many outputs. Because Ethereum transaction only have one from address and one to address, we need to rewrite the legacy smart-contract. The incoming EIP-3074 would allow batching with legacy smart contracts without rewriting. We are looking forward to seeing EIP-3074 adopted in batching.

3 Likes

Great points @ywang349.

EIP-3074 is not something widely discussed, but it can be incredibly impactful in the context of batching. If this is an area that you are interested in, you could write a discussion post on iBatch and 3074 to increase awareness of smart contract batching.

If you have any questions on how to get started, please feel free to join on Discord: Smart Contract Research Forum

3 Likes