Oracles are going to be the most important piece of web3 infrastructure after we increase on chain TPS via rollups and L2s. If there is a million transactions possible in a block, most of the block space will be used by oracles bringing off chain data on chain.

Super important for us to figure out a decentralized oracle network. Chainlink is doing a great job - the question is how can we bring in data feeds that have higher participation from the community members/data providers?

Data guilds

There are data guilds that form to become a consensus layer on data aggregation.

A guild may come together and say “We will reliably provide the right temperature of cities in Europe at a daily cadence”. We’ll call this the European City Weather Data Guild.

The Guild agrees upon

• Data sources, ideally multiple
• Code that they’ll run to aggregate the data
• Epoch to refresh data
• Allowed margin of error

Nodes commit to code

To join a guild, a guild leader will publish code to say Github and publish the source code’s hash to the mainchain.

Other nodes can join this guild by agreeing to run this exact code in every block.

Prove executing the correct code w/ ZK-STARKs

At every block, the node must publish the proof that they executed the code they committed to. Anybody can verify this code execution trace without access to the data itself.

They broadcast the zk proofs at every epoch.

Open question : Is it possible to do network calls (i.e. non deterministic inputs) and still generate a stark that provides proof of execution?

Staking

Any node that wants to participate in this guild must stake coins. If a node is found to be cheating, and not running the code as committed (by verifying their zk proofs they publish), their entire stake is slashed.

If the data doesn’t agree with the consensus within the agreed upon margin of error, a portion of the stake is slashed.

Voting

Once every node has broadcasted its proof of running code via a zk-proof, all the nodes broadcast their data’s true value.

This value must coincide with the previously broadcasted proof of execution.

If there is a 51% consensus on a certain data point, that data is published on chain.

Guild coins

Every guild has its own coin.

This coin is used for

• Staking to become a guild node
• Payment to subscribe to data

Coin price bonding curve

A bonding curve sets the price of the inflationary guild coin.

A user can deposit ETH to the bonding curve and take out the guild coins.

The guild coins’ price is proportional to the number of coins in circulation. Meaning, the price decreases when someone sells coins to the bonding curve and/or the stakes are burnt.

Pooling subscription

Once data is on chain, the data is public. So, it doesn’t make sense to have an individual user pay for subscribing to data. That is too web2.

Users can pool together guild coins in a subscriber contract. The Guild, upon data consensus, publishes data to the subscriber contract.

The subscriber account codifies the number of guild coins it is willing to pay per data point provided.

The subscribers can also fill up the subscriber contract with more guild coins to incentivize more nodes to participate in the data consensus, thereby, increasing the security of the data accuracy.

Every other contract can use the data from the subscriber account for free.

Paying for data

The subscriber contract agrees to pay the nodes that were part of the consensus certain guild coins per data point.

The payment is distributed to the nodes that are participating in the consensus, in proportion to the node’s stake.

Some observations

• The earlier you become a guild member, cheaper it is to become one
• The earlier the subscribers buy coins for future data points, the cheaper it is
• More coins in the subscriber contract, more incentive for nodes to participate
• More coins bought by subscriber or other data nodes, more expensive it becomes to participate in the guild

Requesting help

• Is it possible to achieve zk-proof of correct code execution for things that include external api calls?
• What are the specifics of this staking?
• What should the bonding curve look like?
• Willing to build a prototype?

Please hit me up on @madhavanmalolan