Node Runner | Tester | Investor | Trader | Accountant
Node Runner | Tester | Investor | Trader | Accountant
Subscribe to meguce
Subscribe to meguce
Share Dialog
Share Dialog
<100 subscribers
<100 subscribers
Before starting to introduce and explain the project, I thought it would be important to explain some concepts so that new learners can understand the importance, vision and mission of the project. I believe that we will have a more effective project familiarization process with simple explanations.
If you are familiar with Oracle, ZKP, Schelling points and SchellingCoin principle, you can skip these parts.
Oracle.
They are smart contracts that exchange data between the blockchain and the external ecosystem. In other words, they are intermediaries. A blockchain, by definition, cannot connect directly with external ecosystems without intermediaries. It is protected.For this reason, oracles are the intermediaries needed to send data to and receive data from the outside. For example, let’s say we create a token linked to the price of a stock.Oracle is the one that provides us with instant information about the price of this stock. In order to be decentralized, this Oracle needs to be able to pull data from multiple places. This gives us a decentralized data, price.
Zero Knowledge Proof.
This concept arises from a question: How can I prove that I know something without increasing my opponent’s knowledge about it? The simplest way to explain this concept is by example. Imagine that I choose a card from a deck of playing cards. This card is a red card and I want to prove that it is red without giving you any information other than the fact that it is red.
And how can I make you believe that?
If I put all 26 black cards in the deck in front of you, you will be convinced that the card in my hand is red. That’s Zero Knowledge Proof. The only thing you know is that the card is red. No other knowledge is increased.
There are 3 criteria for something to be Zero Knowledge Proof:
Correctness: If the parties are honest, i.e. you are honest and I am honest, then everything is fine. In the deck example, the parties trust each other that there is only one deck of 52 cards.
Soundness: If I don’t have this secret, there must be an argument that I cannot prove. Using the deck example, if I didn’t have a red card in my hand, I wouldn’t be able to set aside 26 black cards. Even if I set aside 10–15 or even 25 black cards, this argument would be suspect.
Characteristic: When I prove this, you cannot learn more than what I want to prove to you. So it’s a proof that is characteristically designed according to the information that I want to show. It doesn’t contain anything more.
Schelling Points.
I thought it would be good to understand this before moving on to the SchellingCoin principle. The Schelling Point, as defined in game theory, is “the solution to a miscommunication situation where people tend to choose the default.”
Schelling means that in the case of cooperation, i.e. when all parties have the same intentions and expectations and each knows that the other is trying to take the same action, to make the same choice, the steps and estimates to reach these decisions can be harmonized.
For a better understanding, let us consider the following: Let’s imagine two people living in Turkey with the same rationality and education, who have the same goal of meeting each other, and who have no communication. The point to note here is that there is no goal other than achieving our goal. In order to realize this meeting, we use certain social and cultural norms, common social frameworks and references.
Since we know that Istanbul is the most populous city in terms of population, we can assume that the other party is already in Istanbul or that he/she will think like you and come to Istanbul even if he/she is not in Istanbul. Statistically, this would be the most logical assumption.
So where in Istanbul? For both those who live in Istanbul and those who don’t, we can choose one of the most well-known meeting points. Taksim Square for example.
So what can we choose as a date? Since we don’t have any information about the other person (birthday, etc.), we can choose a date that is meaningful for both of us. An even lower-risk choice would be to choose a meaningful day that is immediately memorable and meaningful to the crowd. New Year’s Eve for example.
What time? If we have set New Year’s Eve, the most meaningful time for this date would be December 31, 23:59 or January 01, 00:00. So the meeting could take place in Istanbul and in Taksim Square on December 31st at 23:59.
This is the Schelling Point. Past actions and decisions, cultural, social norms, can create Schelling points. There are some things that are known by everybody and we know that everybody knows that. These have created a common consciousness, and it is from this common consciousness that Schelling points arise.
“An endlessly repeating chain of logic!”
SchellingCoin.
The SchellingCoin principle is a protocol based on this theory. It’s best to briefly explain the way Vitalik Buterin talks about it in his article. https://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-trust-universal-data-feed
“This mechanism is how SchellingCoin works. The basic protocol is as follows:
During an even-numbered block, all users can submit a hash of the ETH/USD price together with their Ethereum address
During the block after, users can submit the value whose hash they provided in the previous block.
Define the “correctly submitted values” as all values N where H(N+ADDR) was submitted in the first block and N was submitted in the second block, both messages were signed/sent by the account with address ADDR and ADDR is one of the allowed participants in the system.
Sort the correctly submitted values (if many values are the same, have a secondary sort by H(N+PREVHASH+ADDR) wherePREVHASH is the hash of the last block)
Every user who submitted a correctly submitted value between the 25th and 75th percentile gains a reward of N tokens (which we’ll call “schells”)”
One of the problems with this system is the 51% attack. The majority takes control and manipulates the system.
“Another potential concern is micro-cheating. If the underlying datum is a value that frequently makes slight changes, which the price is, then if most participants in the SchellingCoin are simultaneously participants in a system that uses that SchellingCoin, they may have the incentive to slightly tweak their answers in one direction, trying to keep within the 25/75 boundary but at the same time push the median up (or down) very slightly to benefit themselves. Other users will predict the presence of micro-disruption, and will thus tweak their answers in that direction themselves to try to stay within the median. Thus, if people think that micro-cheating is possible, then micro-cheating may be possible, and if they do not think so then it will not be — a common result in Schelling point schemes.
There are two ways of dealing with the problem. First, we can try to define the value very unambiguously — eg. “the last ask price of ETH/USD on exchange XYZ at a time HH:MM:00″, so that a very large portion of answers end up exactly the same and there is no possibility to move the median at all by micro-cheating. However, this introduces centralization in the definition, so needs to be handled carefully. An alternative is to be coarse-grained, defining “the price of ETH/USD rounded to two significant digits”. Second, we can simply work hard to make the underlying system for picking users avoid biases, both by being decentralization-friendly (ie. proof-of-stake over proof-of-work) and by including users who are likely to have incentives in opposite directions.”
You have understood the working principle and some of the problems involved here.
When we understand these 3 concepts, it will be healthier to think about the project. After all, we cannot evaluate the solution without recognizing the problem.
#Entrance: Blocksense Network
Blocksense is a decentralized and permissionless protocol for the efficient creation and consumption of oracle data feeds, designed as a ZK rollup. With my words, Blocksense network is a trust minimized oracle is established by zero knowledge and Schellingcoin principle.
Every design choice made here has a reason.
This design enables the Blocksense network to have its own efficient consensus mechanism that implements the SchellingCoin principle and is capable of generating very tightly packed blocks that contain data updates to be published on the target chain in a single transaction.
Blocks generated by the Blocksense network will be published on multiple chains. The Zero Knowledge Proof attached to each block guarantees that all protocol rules for data generation have been followed and that the data is supported by the majority of Stakers. The ZK proofs ensuring the authenticity of the data can be verified in any EVM-compliant chain as well as in chains based on WebAssembly or eBPF run-times. Additionally, through the power of Merkle trees, our data universe can scale to an unlimited number of continuously updated data feeds, offering a wide spectrum of cost-to-publish vs cost-to-access options. This greatly facilitates the introduction of new data feeds. All data is secured by the reputation that needs to be protected and by frequently rotated committees, something I will talk about later.
The correctness of the data is ensured by cryptography and game theory incentives. This means that users are rewarded for submitting accurate data. The Blocksense network is operated by many Data Reporters running Oracle node software and Staking on the protocol. Randomly selected Reporters publish their current data as an “Oracle value”. At each time interval, each Oracle data feed is updated by a random subset of Reporters. And reporters are rewarded if their choices match the majority of other reporters (which can also mean either equal or close enough, depending on the data feed) or penalized if their choices differ.
This randomized subset design is important. Because this design prevents bribery and collusion. This is one of the two core features of Blocksense, namely, Secret Committee Election.
Secret Committee Election
Basically, to explain it again, it means that the nodes responsible for publishing updates for a given data feed are randomly selected in a secretive way. Each node is only aware of its own membership on a particular committee and is unaware of which other nodes are on the same committee. This makes both collusion and bribery much more difficult for malicious actors who don’t know who to target in an attack. Normally, there is the problem of the majority taking control and manipulating the data that Vitalik mentioned, but Blocksense’s design reduces this possibility. While this possibility still exists, it becomes less likely.
Another key feature is Vote Secrecy.
Vote secrecy
Updates provided by nodes are hidden and only the final aggregated results are made public. They cannot provide evidence for their votes without revealing the secret that would cause them to lose all their stakes in the network. Even in the event of any collusion, the parties will not know what the other nodes they colluded with voted for. So if you choose to lie, you will have to guess that the other reporters who are interested in lying also took the actions demanded by the bribing actor and voted for what, and since this is a long shot, a majority is unlikely. So the most sensible strategy would be to publish the correct value.
I have already mentioned that Blocksense, like other PoS networks, can be taken over by malicious actors if they control a sufficient percentage of the voting power. Another mechanism to prevent this is to set the voting power as a function of both Stake and reputation. A new concept is introduced here: Reputation.
Reputation.
The reputation of all nodes starts low and gradually increases as their operators demonstrate their ability to run Blocksense software at the appropriate uptime and performance. In other words, the higher performance you can provide accurate value output, the higher your reputation will be. Node operators are incentivized to provide various proofs of their identity that are expected to facilitate approval by protocol users based on social reputation. This allows the largest consumers of data to identify them as more trustworthy. A curation that increases security for everyone.
It also grants user credits to the creators of smart contracts that use Blocksense data feeds, proportional to their transaction volumes. These credits can be delegated to specific Node operators to increase their voting power.
It could also make the critical threshold for the release of a malicious update higher than 51%, as the protocol may require a significantly higher majority before accepting a new data feed value. This means that a potentially malicious update may require more approvals. This represents an important trade-off between ensuring the integrity and vitality of the network.
Timely Updates.
If node operators on the Blocksense network are able to delay or prevent the updating of certain price feeds, this could lead to on-chain price mismatches that could potentially be used in arbitrage trading.
Blocksense makes such an attack virtually impossible by dividing block publishing among three separate roles within the protocol:
Reporters
Reporters in the network are responsible for identifying Oracle reporting tasks and executing the relevant Oracle scripts in a timely manner. Reporters are encouraged to post an update that agrees with the majority. Skipping an update or reporting an incorrect value results in penalties. Therefore, a reporter cannot individually censor any data stream. This is because by definition every update will be signed off by the majority of reporters.
2. Aggregator
Aggregators monitor Gossip channels in the network where Reporters broadcast signed data feed updates. They are incentivized to package as many updates as possible into packets to be rebroadcast to the network. If an Aggregator attempts to censor a particular data feed by pretending not to have received the Reporters’ signed updates, it is likely that another Aggregator will include the feed update in its own packets to claim the relevant rewards.
3. Block Builders.
Block Generators are responsible for mechanically combining the bundles generated by aggregators into the final blocks to be published on the target chain. In this process, the Block Builder is not allowed to manipulate the content of the mixed bundles in any way, and this is ensured through a Zero Knowledge Circuit that verifies that each block has been created correctly.
A block is only considered valid if a sufficient number of aggregators have contributed. It is not uncommon for the same data feed update to be present in the packages of many individual aggregators, making it extremely difficult for the creator to create a valid block in cases where certain feeds are missing. In each slot, multiple generators have the right to publish a block and this ensures that even if a particular Block Builder is offline, others can step in to publish a valid block containing updates to all feeds.
The most critical point is that the different roles in the protocol are not predefined. So operators do not stay in the same role all the time. Or they don’t know which role they will be in. This is because Blocksense node software assigns roles dynamically and randomly and automatically tracks role assignments and performs all tasks accordingly.
Creation of new data streams.
Blocksense Node software includes a virtual machine that can execute various CPU, GPU and I/O tasks.
New data feeds can be created by anyone by writing a short program for the Blocksense VM. Once created, the Oracle is identified by a cryptographic hash of the program content. To initiate feed updates, however, a small fund can be deposited, which will be used to cover the initial data publishing fees. Once the Feed is being used by smart contracts, it will become self-sufficient through on-chain generated data access fees.
For example, a common type of oracle would be one that downloads the content of a given URL. A more specific example would be an oracle that tracks the USD/EUR exchange price by querying multiple independent sources and averaging them.
In the future, the Zero Knowledge Circuits of the Blocksense network could add an additional layer of security by ensuring that all data obtained from SSL-enabled web servers is authenticated following the chain of encryption keys used in the TLS protocol.
Computationally heavy Oracles, such as GPU scripts, could be defined to use a specialized strategy involving heavy penalties that trigger random checks by a larger committee for only a small subset of dataflow updates. This would enable use cases such as on-chain Machine Learning to be implemented in a cost-effective way.
Transparent and Market-Driven Fee Model.
Blocksense has designed a flexible fee model so that access to the most popular data feeds becomes cheaper over time while increasing their security. Chains can choose to subsidize certain streams to initiate and maintain a vibrant Defi ecosystem, all enabled by permissionless protocols and processed entirely on-chain.
Decentralized and Permissionless.
Today, adding new data to the chain is a slow and expensive process. But on the Blocksense network, anyone can create a new data stream by writing a simple script. Anyone can become a data provider by depositing money and running an automated Oracle node. Anyone can access the entire universe of data with an on-chain dapp.
System requirements.
Oracle software will be able to run on a wide range of hardware on all major operating systems, consume minimal disk space and require only persistent internet connectivity.
The reporting workload will scale with the computing power available to generate evidence, and users with access to GPUs will be able to earn more.
When all the design, transparency, feasibility and vision come together, it makes for an exciting project. I hope that the project will progress further with its team, developers, contributors and community and give us the opportunity to develop and grow with it while making us proud to take part in such a project.
I will continue to share as much information about Blocksense as I can.
Thank you for reading.
Project Website: https://blocksense.network/
Project Discord: https://discord.gg/GkS6xmvT
Project Twitter: https://twitter.com/blocksense_
Contributor: https://twitter.com/megucelt
Before starting to introduce and explain the project, I thought it would be important to explain some concepts so that new learners can understand the importance, vision and mission of the project. I believe that we will have a more effective project familiarization process with simple explanations.
If you are familiar with Oracle, ZKP, Schelling points and SchellingCoin principle, you can skip these parts.
Oracle.
They are smart contracts that exchange data between the blockchain and the external ecosystem. In other words, they are intermediaries. A blockchain, by definition, cannot connect directly with external ecosystems without intermediaries. It is protected.For this reason, oracles are the intermediaries needed to send data to and receive data from the outside. For example, let’s say we create a token linked to the price of a stock.Oracle is the one that provides us with instant information about the price of this stock. In order to be decentralized, this Oracle needs to be able to pull data from multiple places. This gives us a decentralized data, price.
Zero Knowledge Proof.
This concept arises from a question: How can I prove that I know something without increasing my opponent’s knowledge about it? The simplest way to explain this concept is by example. Imagine that I choose a card from a deck of playing cards. This card is a red card and I want to prove that it is red without giving you any information other than the fact that it is red.
And how can I make you believe that?
If I put all 26 black cards in the deck in front of you, you will be convinced that the card in my hand is red. That’s Zero Knowledge Proof. The only thing you know is that the card is red. No other knowledge is increased.
There are 3 criteria for something to be Zero Knowledge Proof:
Correctness: If the parties are honest, i.e. you are honest and I am honest, then everything is fine. In the deck example, the parties trust each other that there is only one deck of 52 cards.
Soundness: If I don’t have this secret, there must be an argument that I cannot prove. Using the deck example, if I didn’t have a red card in my hand, I wouldn’t be able to set aside 26 black cards. Even if I set aside 10–15 or even 25 black cards, this argument would be suspect.
Characteristic: When I prove this, you cannot learn more than what I want to prove to you. So it’s a proof that is characteristically designed according to the information that I want to show. It doesn’t contain anything more.
Schelling Points.
I thought it would be good to understand this before moving on to the SchellingCoin principle. The Schelling Point, as defined in game theory, is “the solution to a miscommunication situation where people tend to choose the default.”
Schelling means that in the case of cooperation, i.e. when all parties have the same intentions and expectations and each knows that the other is trying to take the same action, to make the same choice, the steps and estimates to reach these decisions can be harmonized.
For a better understanding, let us consider the following: Let’s imagine two people living in Turkey with the same rationality and education, who have the same goal of meeting each other, and who have no communication. The point to note here is that there is no goal other than achieving our goal. In order to realize this meeting, we use certain social and cultural norms, common social frameworks and references.
Since we know that Istanbul is the most populous city in terms of population, we can assume that the other party is already in Istanbul or that he/she will think like you and come to Istanbul even if he/she is not in Istanbul. Statistically, this would be the most logical assumption.
So where in Istanbul? For both those who live in Istanbul and those who don’t, we can choose one of the most well-known meeting points. Taksim Square for example.
So what can we choose as a date? Since we don’t have any information about the other person (birthday, etc.), we can choose a date that is meaningful for both of us. An even lower-risk choice would be to choose a meaningful day that is immediately memorable and meaningful to the crowd. New Year’s Eve for example.
What time? If we have set New Year’s Eve, the most meaningful time for this date would be December 31, 23:59 or January 01, 00:00. So the meeting could take place in Istanbul and in Taksim Square on December 31st at 23:59.
This is the Schelling Point. Past actions and decisions, cultural, social norms, can create Schelling points. There are some things that are known by everybody and we know that everybody knows that. These have created a common consciousness, and it is from this common consciousness that Schelling points arise.
“An endlessly repeating chain of logic!”
SchellingCoin.
The SchellingCoin principle is a protocol based on this theory. It’s best to briefly explain the way Vitalik Buterin talks about it in his article. https://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-trust-universal-data-feed
“This mechanism is how SchellingCoin works. The basic protocol is as follows:
During an even-numbered block, all users can submit a hash of the ETH/USD price together with their Ethereum address
During the block after, users can submit the value whose hash they provided in the previous block.
Define the “correctly submitted values” as all values N where H(N+ADDR) was submitted in the first block and N was submitted in the second block, both messages were signed/sent by the account with address ADDR and ADDR is one of the allowed participants in the system.
Sort the correctly submitted values (if many values are the same, have a secondary sort by H(N+PREVHASH+ADDR) wherePREVHASH is the hash of the last block)
Every user who submitted a correctly submitted value between the 25th and 75th percentile gains a reward of N tokens (which we’ll call “schells”)”
One of the problems with this system is the 51% attack. The majority takes control and manipulates the system.
“Another potential concern is micro-cheating. If the underlying datum is a value that frequently makes slight changes, which the price is, then if most participants in the SchellingCoin are simultaneously participants in a system that uses that SchellingCoin, they may have the incentive to slightly tweak their answers in one direction, trying to keep within the 25/75 boundary but at the same time push the median up (or down) very slightly to benefit themselves. Other users will predict the presence of micro-disruption, and will thus tweak their answers in that direction themselves to try to stay within the median. Thus, if people think that micro-cheating is possible, then micro-cheating may be possible, and if they do not think so then it will not be — a common result in Schelling point schemes.
There are two ways of dealing with the problem. First, we can try to define the value very unambiguously — eg. “the last ask price of ETH/USD on exchange XYZ at a time HH:MM:00″, so that a very large portion of answers end up exactly the same and there is no possibility to move the median at all by micro-cheating. However, this introduces centralization in the definition, so needs to be handled carefully. An alternative is to be coarse-grained, defining “the price of ETH/USD rounded to two significant digits”. Second, we can simply work hard to make the underlying system for picking users avoid biases, both by being decentralization-friendly (ie. proof-of-stake over proof-of-work) and by including users who are likely to have incentives in opposite directions.”
You have understood the working principle and some of the problems involved here.
When we understand these 3 concepts, it will be healthier to think about the project. After all, we cannot evaluate the solution without recognizing the problem.
#Entrance: Blocksense Network
Blocksense is a decentralized and permissionless protocol for the efficient creation and consumption of oracle data feeds, designed as a ZK rollup. With my words, Blocksense network is a trust minimized oracle is established by zero knowledge and Schellingcoin principle.
Every design choice made here has a reason.
This design enables the Blocksense network to have its own efficient consensus mechanism that implements the SchellingCoin principle and is capable of generating very tightly packed blocks that contain data updates to be published on the target chain in a single transaction.
Blocks generated by the Blocksense network will be published on multiple chains. The Zero Knowledge Proof attached to each block guarantees that all protocol rules for data generation have been followed and that the data is supported by the majority of Stakers. The ZK proofs ensuring the authenticity of the data can be verified in any EVM-compliant chain as well as in chains based on WebAssembly or eBPF run-times. Additionally, through the power of Merkle trees, our data universe can scale to an unlimited number of continuously updated data feeds, offering a wide spectrum of cost-to-publish vs cost-to-access options. This greatly facilitates the introduction of new data feeds. All data is secured by the reputation that needs to be protected and by frequently rotated committees, something I will talk about later.
The correctness of the data is ensured by cryptography and game theory incentives. This means that users are rewarded for submitting accurate data. The Blocksense network is operated by many Data Reporters running Oracle node software and Staking on the protocol. Randomly selected Reporters publish their current data as an “Oracle value”. At each time interval, each Oracle data feed is updated by a random subset of Reporters. And reporters are rewarded if their choices match the majority of other reporters (which can also mean either equal or close enough, depending on the data feed) or penalized if their choices differ.
This randomized subset design is important. Because this design prevents bribery and collusion. This is one of the two core features of Blocksense, namely, Secret Committee Election.
Secret Committee Election
Basically, to explain it again, it means that the nodes responsible for publishing updates for a given data feed are randomly selected in a secretive way. Each node is only aware of its own membership on a particular committee and is unaware of which other nodes are on the same committee. This makes both collusion and bribery much more difficult for malicious actors who don’t know who to target in an attack. Normally, there is the problem of the majority taking control and manipulating the data that Vitalik mentioned, but Blocksense’s design reduces this possibility. While this possibility still exists, it becomes less likely.
Another key feature is Vote Secrecy.
Vote secrecy
Updates provided by nodes are hidden and only the final aggregated results are made public. They cannot provide evidence for their votes without revealing the secret that would cause them to lose all their stakes in the network. Even in the event of any collusion, the parties will not know what the other nodes they colluded with voted for. So if you choose to lie, you will have to guess that the other reporters who are interested in lying also took the actions demanded by the bribing actor and voted for what, and since this is a long shot, a majority is unlikely. So the most sensible strategy would be to publish the correct value.
I have already mentioned that Blocksense, like other PoS networks, can be taken over by malicious actors if they control a sufficient percentage of the voting power. Another mechanism to prevent this is to set the voting power as a function of both Stake and reputation. A new concept is introduced here: Reputation.
Reputation.
The reputation of all nodes starts low and gradually increases as their operators demonstrate their ability to run Blocksense software at the appropriate uptime and performance. In other words, the higher performance you can provide accurate value output, the higher your reputation will be. Node operators are incentivized to provide various proofs of their identity that are expected to facilitate approval by protocol users based on social reputation. This allows the largest consumers of data to identify them as more trustworthy. A curation that increases security for everyone.
It also grants user credits to the creators of smart contracts that use Blocksense data feeds, proportional to their transaction volumes. These credits can be delegated to specific Node operators to increase their voting power.
It could also make the critical threshold for the release of a malicious update higher than 51%, as the protocol may require a significantly higher majority before accepting a new data feed value. This means that a potentially malicious update may require more approvals. This represents an important trade-off between ensuring the integrity and vitality of the network.
Timely Updates.
If node operators on the Blocksense network are able to delay or prevent the updating of certain price feeds, this could lead to on-chain price mismatches that could potentially be used in arbitrage trading.
Blocksense makes such an attack virtually impossible by dividing block publishing among three separate roles within the protocol:
Reporters
Reporters in the network are responsible for identifying Oracle reporting tasks and executing the relevant Oracle scripts in a timely manner. Reporters are encouraged to post an update that agrees with the majority. Skipping an update or reporting an incorrect value results in penalties. Therefore, a reporter cannot individually censor any data stream. This is because by definition every update will be signed off by the majority of reporters.
2. Aggregator
Aggregators monitor Gossip channels in the network where Reporters broadcast signed data feed updates. They are incentivized to package as many updates as possible into packets to be rebroadcast to the network. If an Aggregator attempts to censor a particular data feed by pretending not to have received the Reporters’ signed updates, it is likely that another Aggregator will include the feed update in its own packets to claim the relevant rewards.
3. Block Builders.
Block Generators are responsible for mechanically combining the bundles generated by aggregators into the final blocks to be published on the target chain. In this process, the Block Builder is not allowed to manipulate the content of the mixed bundles in any way, and this is ensured through a Zero Knowledge Circuit that verifies that each block has been created correctly.
A block is only considered valid if a sufficient number of aggregators have contributed. It is not uncommon for the same data feed update to be present in the packages of many individual aggregators, making it extremely difficult for the creator to create a valid block in cases where certain feeds are missing. In each slot, multiple generators have the right to publish a block and this ensures that even if a particular Block Builder is offline, others can step in to publish a valid block containing updates to all feeds.
The most critical point is that the different roles in the protocol are not predefined. So operators do not stay in the same role all the time. Or they don’t know which role they will be in. This is because Blocksense node software assigns roles dynamically and randomly and automatically tracks role assignments and performs all tasks accordingly.
Creation of new data streams.
Blocksense Node software includes a virtual machine that can execute various CPU, GPU and I/O tasks.
New data feeds can be created by anyone by writing a short program for the Blocksense VM. Once created, the Oracle is identified by a cryptographic hash of the program content. To initiate feed updates, however, a small fund can be deposited, which will be used to cover the initial data publishing fees. Once the Feed is being used by smart contracts, it will become self-sufficient through on-chain generated data access fees.
For example, a common type of oracle would be one that downloads the content of a given URL. A more specific example would be an oracle that tracks the USD/EUR exchange price by querying multiple independent sources and averaging them.
In the future, the Zero Knowledge Circuits of the Blocksense network could add an additional layer of security by ensuring that all data obtained from SSL-enabled web servers is authenticated following the chain of encryption keys used in the TLS protocol.
Computationally heavy Oracles, such as GPU scripts, could be defined to use a specialized strategy involving heavy penalties that trigger random checks by a larger committee for only a small subset of dataflow updates. This would enable use cases such as on-chain Machine Learning to be implemented in a cost-effective way.
Transparent and Market-Driven Fee Model.
Blocksense has designed a flexible fee model so that access to the most popular data feeds becomes cheaper over time while increasing their security. Chains can choose to subsidize certain streams to initiate and maintain a vibrant Defi ecosystem, all enabled by permissionless protocols and processed entirely on-chain.
Decentralized and Permissionless.
Today, adding new data to the chain is a slow and expensive process. But on the Blocksense network, anyone can create a new data stream by writing a simple script. Anyone can become a data provider by depositing money and running an automated Oracle node. Anyone can access the entire universe of data with an on-chain dapp.
System requirements.
Oracle software will be able to run on a wide range of hardware on all major operating systems, consume minimal disk space and require only persistent internet connectivity.
The reporting workload will scale with the computing power available to generate evidence, and users with access to GPUs will be able to earn more.
When all the design, transparency, feasibility and vision come together, it makes for an exciting project. I hope that the project will progress further with its team, developers, contributors and community and give us the opportunity to develop and grow with it while making us proud to take part in such a project.
I will continue to share as much information about Blocksense as I can.
Thank you for reading.
Project Website: https://blocksense.network/
Project Discord: https://discord.gg/GkS6xmvT
Project Twitter: https://twitter.com/blocksense_
Contributor: https://twitter.com/megucelt
No activity yet