DeFeed: Secure Decentralized Cross-Contract Data Feed in Web 3.0 for Connected Autonomous Vehicles

TL;DR

This paper tackles the Cross-Contract Data Feed (CCDF) problem in Ethereum-like Web 3.0 environments for Connected Autonomous Vehicles by introducing DeFeed, a secure cross-contract data feed protocol. The approach modularizes data exchange through separate contracts (Data Owner, Data Feed Center, Data Feed Management) and governance via a Committee, complemented by pool, cache, subscribe, and update mechanisms to optimize gas usage and enable real-time data delivery. Implemented in Solidity on the Sepolia test network, DeFeed demonstrates reduced gas costs, scalable batching of requests, and reliable inter-contract communication essential for cooperative CAV operations. The work provides a practical, deployable framework for secure, decentralized inter-contract data sharing in Web 3.0 ecosystems, addressing limitations of traditional oracles and paving the way for more integrated autonomous systems.

Abstract

Smart contracts have been a topic of interest in blockchain research and are a key enabling technology for Connected Autonomous Vehicles (CAVs) in the era of Web 3.0. These contracts enable trustless interactions without the need for intermediaries, as they operate based on predefined rules encoded on the blockchain. However, smart contacts face significant challenges in cross-contract communication and information sharing, making it difficult to establish seamless connectivity and collaboration among CAVs with Web 3.0. In this paper, we propose DeFeed, a novel secure protocol that incorporates various gas-saving functions for CAVs, originated from in-depth research into the interaction among smart contracts for decentralized cross-contract data feed in Web 3.0. DeFeed allows smart contracts to obtain information from other contracts efficiently in a single click, without complicated operations. We judiciously design and complete various functions with DeFeed, including a pool function and a cache function for gas optimization, a subscribe function for facilitating data access, and an update function for the future iteration of our protocol. Tailored for CAVs with Web 3.0 use cases, DeFeed enables efficient data feed between smart contracts underpinning decentralized applications and vehicle coordination. Implemented and tested on the Ethereum official test network, DeFeed demonstrates significant improvements in contract interaction efficiency, reducing computational complexity and gas costs. Our solution represents a critical step towards seamless, decentralized communication in Web 3.0 ecosystems.

Figures (10)

• Figure 1: The Cross-Contract Data Feed (CCDF) problem. The CCDF problem is represented in this structure. It arises because a smart contract cannot directly access variables stored in another contract's Storage Trie. For example, if an integer variable with a specific value is stored in one contract's storage, another contract doesn't have direct visibility to this data.
• Figure 2: The traditional data feed architecture (a), the third-party data feed architecture (b), and the cross-contract data feed architecture (c). In this figure, each gear represents a smart contract, each persona represents a third party. Solid arrows indicate "contract call". while dashed arrows represent "data transfer".
• Figure 3: Regular data feed process. Solid arrows represent contract function calls. The request function in the requester contract calls the response function in the owner contract, which then calls the receive function in the requester contract.
• Figure 4: Overall framework of DeFeed. The smart contract $C_{DF}$ is divided into two separate contracts. Solid blue arrows represent "contract call", while the dashed green arrows indicate "data transfer". Vehicle 1 requests data from Vehicle 2 using the complex contracts outlined in the red dashed box. A red box indicates that its interior is isolated from the exterior.
• Figure 5: Detailed workflow of the regular data feed process. A contract $C_{DFC}$ receives registration data from a vehicle $C_o$ (Step 0). Another vehicle $C_r$ can make requests to a contract $C_{DFM}$ contract for accessing the registered data (Step 1). $C_{DFM}$ will forward the request to $C_{DFC}$ (Step 2). $C_{DFC}$ queries $C_o$ for the data (Step 3&4) and responds it to $C_r$ (Step 5). The committee manages the overall process.