blocksense
What is Blocksense?
Blocksense is a decentralized and permissionless protocol for the efficient creation and consumption of oracle data feeds, designed as a ZK rollup.
How does Blocksense produce accurate data?
The correctness of the data is ensured through cryptography and game-theoretic incentives.
The Blocksense network is operated by a large number of data reporters who have stake in the protocol and run the Blocksense oracle node software. At each time interval, each oracle data feed is updated by a random subset of the reporters. The reporters publish what they have obtained as the value of the oracle at the given time. The reporters are rewarded if their choice agrees with the majority of other reporters (depending on the data feed, this means having either equal or close enough value) or penalized if their choice differs. Since the selected subset of reporters is both random and secret, collusion is unlikely and the most rationale strategy for everyone is to publish the correct value (if you choose to lie, it would be difficult to guess what other reporters interested in lying are voting for, so a majority is very unlikely to form).
This mechanism is known as the Schelling Coin principle and it's explored in-depth in the following article from Vitalik:
https://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-trust-universal-data-feed
Why is Blocksense designed as a ZK rollup?
This allows the network to have its own efficient consensus mechanism that implements the Schelling Coin principle and produces very tightly packed blocks of data updates that can be published on the target chain with a single transaction.
The zero-knowledge proof attached to each block ensures that all protocol rules for data production have been followed and that the data is backed by the majority of the stake.
This design allows for a dramatic cost reduction for publishing data and greatly simplifies the introduction of new data feeds.
How does Blocksense prevent bribery and collusion?
The Blocksense network leverages the advanced capabilities of the zero-knowledge proving systems to implement two key properties of the protocol:
Secret committee election - in plain words this means that the nodes responsible for publishing updates for a particular data feed are selected randomly in a concealed fashion. Each node is aware only of its own membership in a particular committee and it remains oblivious to which other nodes participate in the same committee.
This makes both collusion and bribery much more difficult for malicious actors as they don't know who to target in their attacks.
Vote secrecy - the updates provided by the nodes are concealed and only the final aggregated results are revealed publically. The nodes cannot provide a proof for their votes without also revealing a secret that can be used to drain their entire stake. This makes bribery much more difficult as the actor providing the bribe cannot be certain that the actions they request are being carried out. When the overall goal of the bribe fails, it's difficult to determine who complied and who defected in the bribing attempt.
Is the network subject to 51% attacks?
Yes, like most other proof-of-stake decentralized networks, Blocksense can be overtaken by malicious actors if they control sufficient percentage of the voting power.
To make such an attack less likely, the Blocksense network determines the voting power as a function of both stake and reputation. The reputation of all nodes starts low and it's gradually increased as their operators demonstrate their abilities to run the Blocksense software with proper uptime and performance.
Furthermore, the creators of the smart contracts that consume the Blocksense data feeds are awarded user credits in proportion to their transaction volume.
These credits can be delegated to certain node operators to increase their voting power. The node operators are incentivised to provide various proofs of their identity which is expected to facilitate this endorsement by the users of the protocol based on social reputation.
Finally, the critical threshold for publishing a malicious update may be above 51% as the protocol may require a significantly higher super-majority before accepting a new data feed value. This represents an important trade off between ensuring correctness and liveness of the network and it may be subject to an ongoing protocol governance, applied on a feed-by-feed basis (in certain feeds correctness is much more important than liveness).
How does Blocksense ensure timely updates for all feeds?
If the node operators in the Blocksense network were able to delay or prevent the updates of certain price feeds, this would create an avenue for inducing an on-chain price disrepancies that can be potentially exploited in arbitrage trading.
The Blocksense network makes such an attack nearly impossible by dividing the work of publishing blocks between three separate roles within the protocol:
* The reporters in the network are responsible for determining their oracle reporting duties and executing the respective oracle scripts in a timely manner. The reporters are incentivised to publish an update that agrees with the majority. Skipping an update or reporting an incorrect value results in penalties. Thus, a reporter cannot individually censor any data feed because by definition each update will be signed by a large majority of reporters.
* The aggregators monitor the gossip channels in the network where the reporters broadcast their signed data feed updates. They are incentivised to package as many updates as possible in bundles that are re-broadcasted to the network. If an aggregator attempt to censor a certain data feed by pretending that she hasn't received the signed updates of the reporters, it's likely that another aggregator will include the feed update in their bundle in order to claim the associated rewards.
* The block builders are responsible for mechanically combining the bundles produced by the aggregators in the final blocks that will be published on the target chain. In this process, the block builder is not allowed to manipulate the contents of the mixed bundles in any way and this is ensured through a zero-knowledge circuit that verifies that each block is constructed correctly.
A block is considered valid only if a sufficient number of aggregators have contributed to it. Please note that the same data feed update is likely to be present in the bundles of many individual aggregators and this makes it exceedingly difficult for the builder to construct a valid block where specific feeds are missing. In each slot, multiple builders are eligible to publish a block and this ensures that even if a particular builder is offline, others will step in to publish a valid block including updates to all feeds.
The different roles in the protocol are not pre-determined, but rather dynamically and randomly assigned to the node operators as time shifts. The Blocksense node software automatically keeps track of the role assignments and performs all duties accordingly.
How are new data feeds (a.k.a oracles) created?
The Blocksense node software includes a sandboxed virtual machine capable of executing a variety of CPU, GPU and I/O tasks. New data feeds can be created by anyone by simply writing a short program for the Blocksense VM.
Once created, the oracle is identified by a cryptographic hash of its program contents. To bootstrap the feed updates, any entity can deposit a small amount of funds that will be used to cover the initial data publishing fees, but once the feed gets actively used by smart contracts, it may become self-sufficient through the data access fees generated on-chain.
For example, a common type of oracle will be one that downloads the contents of a particular URL. Another, more specific example is an oracle tracking the USD/EUR exchange price by querying multiple independent sources and taking the average of them.
In the future, the zero knowledge circuits of the Blocksense network may add an additional layer of security by ensuring that all data obtained from SSL-enabled web servers is authenticated by following the chain of encryption keys used in the TLS protocol.
Computationally heavy oracles such as GPU scripts can be defined to use a specialized strategy involving heavy penalty inducing randomized checks by a larger committee for only a small subset of the data feed updates. This would enable the cost-effective implementation of use cases such as ML inference on chain.
What would be the system requirements for running an oracle node?
The BlockSense oracle node software will run on a wide range of commodity hardware on all major operating systems, consuming minimal disk space and requiring only persistent internet connection.
The reporting workload will scale with the available computing power for generating proofs and users with access to GPUs will be able to earn more.
Is the system live?
Yes. Blocksense is available in many leading blockchain testnets. Please refer to our latest docs for more details. The first production use cases are expected to go live in late 2024.
More details on the Blocksense staking token and its associated fee model willl be published prior to the mainnet launch in the second half of 2025.
Which chains are targeted?
The blocks produced by the Blocksense network will be published on multiple chains. The zero-knowledge proofs ensuring the authenticity of the data can be verified on any EVM compatible chain, as well as on chains based on WebAssembly or eBPF run-times.
Have another question?
Drop us an email at hi@blocksense.network
The BlockSense blocks can be published and accessed on any blockchain capable of verifying our zero-knowledge circuits.