How to be fun at parties: understanding blockchain — Professor
Overview
If you have come from How to be fun at parties: understanding blockchain — Apprentice or if you are in coming along with some hobby knowledge of the inner technical workings of blockchain and Ethereum, this article is intended for you as the third of a series of three articles. If you don’t feel as comfortable with your knowledge feel free to jump back to the beginning of this series How to be fun at parties: understanding blockchain — Student and read along. This article will take you through understanding some of the current challenges facing Ethereum, and what the future looks like for it considering these problems.
Chainlink
Oracle problem
An oracle is a source of information that allows for the transfer of information between the inside and outside of a blockchain network, and is therefore vital to the functionality of some smart contracts. Oracles can take on different tasks and thus there are different types, such as; a software oracle, a hardware oracle, an inbound oracle, an outbound oracle, or a consensus oracle. Oracles can also be a combination of types for certain services (e.g. inbound and software oracle).
If the information being collected to inform the operation of smart contracts is not correct or is not sufficient to allow for any meaningful operations to occur, than unintended consequences can occur. Without an appropriate degree of information available to refer to networks can also struggle with detecting fraudulent blocks or determining which of two blocks is the valid one in the event of a challenge.
The inherent problem with oracles is that they require trust, which goes against the key principles of a decentralised block chain network. If an oracle becomes compromised, so too does any smart contract that relies on that oracle’s input for the execution of its contract code. The oracle problem has been discussed at great length and many different contributors, including Chainlink, have offered different solutions. It would appear that there is no singular solution to the oracle problem, even using consensus oracles fail to protect the contract against a deliberate attack where an attacker could submit so many false values that the correct values appear to be outliers.
Chainlink allows real world data to be made available to a blockchain, for the execution of smart contracts. It is best to think of Chainlink as a decentralised network of oracles. The Chainlink network not only provides data to the on-chain smart contracts, but it also aggregates results to benefit the accuracy of the data supplied to the contracts and keeps a record of the reputation of oracles and the validity of their data. Chainlink can be used with a variety of blockchains, and can accept a variety of information sources (multiple types of oracles).
Architecture
There are three components to the Chainlink process: the requesting smart contract, the Chainlink smart contract, and the Chainlink nodes linked to an external API. The process is initiated when a requesting smart contract makes a request on the blockchain to a Chainlink smart contract for information required for the execution of the smart contract. The Chainlink smart contract then connects the blockchain to the Chainlink nodes by logging an event for the network of oracles. The Chainlink smart contract is able to collect all the data that the Chainlink nodes go forth and collect in completion of the job, and collates it into a form easily readable by the original requesting smart contract.
Software oracles typically include online sources such as public websites and databases, and are characterised by their connection to the internet. Meanwhile, hardware oracles differ are connected to the physical world and can draw information from events such as a barcode being scanned in a supermarket checkout. An inbound oracle is a smart contract’s source of information, it is a purely one-way relationship and the only method of a smart contract receiving information from inside or outside its blockchain. An outbound oracle serves the opposite purpose. It receives information from the smart contract and essentially acts as its mouth piece. Again, this is a purely one-way relationship.
A consensus oracle will have access to an array of sources and takes the consensus of these sources to be the true and accurate information. An example of this would be an oracle that takes the recorded temperature from multiple weather stations. This way if one station has an incorrect measurement, the integrity of the oracle is not compromised because if the other stations agree witch each other then the oracle will consider what this majority considers to be true.
Oracle selection
When oracles are being selected to be used for the requested job of a smart contract, a Service Level Agreement (SLA) proposal is made, which includes some requirements that the requesting smart contract wishes to be met. These requirements mostly consist of the number of oracles wanted and the desired reputation of the oracles. The user who created the smart contract has the ability to manually sort and select oracles via various off-chain listing services. Once the user has completed the SLA, they will submit the proposal to an order-matching contract which will in turn contact a log which oracle service providers monitor for jobs. An oracle service provider will decide if it would like to bid for the proposal. If it does want the proposal, it will bid on it by committing a penalty value. There is a period of time referred to as the bidding window during which all bids are accepted and considered. At the completion of the bidding window, the order-matching contract will reject bids that do not meet the SLA requirements, and select the requested number of oracle service providers that best suit said requirements. All unsuccessful bids will have their penalty value returned to them. Successful oracles service providers are notified and begin to complete their task as outlined in the SLA.
Collating results
Oracles will report their data to the oracle contract, which will in turn report the data into an aggregating contract. It is the role of the aggregating contract to tally the different responses and calculate a consensus. The consensus is generally formed through weighting placed on reputable oracles, and this consensus is then sent to the smart contract that originally requested the job. Each oracle is held accountable to the data they reported, and the accuracy of their data in comparison to the consensus is reported to the reputation contract. There is no singular aggregating contract for oracles to report to as different data types will have different criteria for what constitutes an outlier, thus the aggregating contract used is chosen by the user. Chainlink provides a set of standard aggregating contracts to choose from, whilst also allowing for the implementation of custom contracts.
Ethereum 2.0
The Istanbul and Berlin hard forks are indicative of many of the intentions of Ethereum 2.0, but these forks are not the only one’s which are intended to influence the upcoming update to Ethereum 2.0 in the near future. Such changes to Ethereum have and will transform the blockchain network — perhaps the most consequential transformation of which is the shift to using a Proof-of-Stake consensus mechanism instead of a Proof-of-Work consensus mechanism.
London hard fork
The second most recent hard fork to be pushed forth onto Ethereum; these cumulative changes are enacted with the intention of assisting in the progression of Ethereum from Ethereum 1.0 to Ethereum 2.0 — occurring sometime in 2022 most likely. The most recent hard fork itself, Muir Glacier, was used for the primary purpose of pushing back the Merge event that would bring about Ethereum 2.0 to later next year.
Some of the changes in the London hard fork include EIP-1559 (an EIP, or Ethereum Improvement Proposal, is a change proposed by the community which is voted on by the community to decide if it will be implemented sort of like legislation in a government). This EIP provides greater stability for the gas fees that a user needs to pay to have their transaction included in a block, as well as providing greater flexibility in terms of the size of a block. Another notable change was the inclusion of EIP-3554 which had moved back the predicted date of the Merge (the occasion in which Proof-of-Work is phased out for Proof-of-Stake on Ethereum) even before the Muir Glacier hard fork pushed it back even further.
Sharding
Sharding will allow for multiple “shards” or chains of L1 Ethereum to be running consecutively, with each shard running a small version of the main blockchain. This will mean that validators will not require a complete copy of the main blockchain (alongside the hardware requirements needed to hold this copy) to be able to validate blocks on their particular shard. This will allow many more validators to join the network regardless of their computational power, greatly increasing the security of the network.
There will be one main “beacon chain” that will keep track of all the shards and ensure that integrity and availability is maintained across all shards for all entities who are on the network.
Proof-of-Stake
Ethereum 2.0 intends to completely move away from any Proof-of-Work to Proof-of-Stake over the coming years. Over the previous few years Ethereum has been employing incentives to encourage entities to transfer their stakes over to a fork that has been running on Proof of Stake so that when the complete transfer occurs there is no sudden collapse in Ethereum.
The motivating reasons for this move include a desire to reduce energy usage involved with mining blocks (and as such the increased gas costs that are involved with mining) and to secure Ethereum against centralisation that has become increasingly apparent as certain entities get control of more and more computational power. These changes are contentious as many entities will suddenly lose all investment they have placed into acquiring large degrees of computational power.
Unlike Proof-of-Work, Proof-of-Stake has not been “battle-tested” to a sufficient degree to determine what effects it will have on Ethereum upon the switchover. While it is widely believed it will immediately decrease centralisation upon launch, there is some worry that centralisation will still eventually occur as only a limited number of entities control the stake required to become a validator in Proof of Stake. As it stands currently the minimum stake to be placed down is 32 ETH (as of December 2021 approximately equivalent to $180,000AUD) — though it is planned that this will decrease over time as Ethereum 2.0 reaches greater stability.
L2 solutions
As it stands currently there are primarily two viable contenders to form the future of L2 Ethereum. The following goes into greater detail as to the specifications of the two L2 solutions, and their limitations.
Both L2 solutions take upon the form where blocks are processed off the main L1 blockchain to reduce the computational work being done there. After they have been processed off chain they are added back to the main chain to be verified and possibly challenged. This pattern provides the advantage of reducing the gas costs involved with processing blocks as less computational work is done overall.
Optimistic Rollup
In the case of Optimistic Rollups it is assumed the block that has been added is honest until proven otherwise. This is advantageous as the total computational work needed to verify a block added through Optimistic Rollup is minimal at worst. If the block is eventually challenged by some entity then the main blockchain will have to run a large amount of computational work to verify that the block is honest which will increase gas costs. These gas costs however are passed onto the “loser” of the challenge, deterring fraudulent blocks from being added and deterring fraudulent challenges.
This L2 solution is far less complex to implement and demonstrates immediate benefits in reducing gas costs across the Ethereum network. As such most companies are aiming towards this solution to form part of their short to medium term strategy in Ethereum.
ZK Rollup
ZK Rollups promise to be the most effective L2 solution in terms of reducing gas prices without reducing security on the blockchain. What allows them to work is a set of proofs that are difficult to compute, but simple to verify without needing to share any of the data involved in the blocks themselves. In Optimistic Rollups little verification needs to be done, but all the data must be received which does increase gas costs slightly. In ZK Rollups however a small bit of verification needs to be done, but no data needs to be received which does decrease gas costs even further.
The mathematics which allows this all to work has not been perfected though, and it is believed it will be at least a year if not more before an application of ZK Rollups is produced to a quality optimal for Ethereum. As such most companies are not looking to this solution within the short term, but are aware that they need to be ready for its potential arrival in the long term — arguably being the most advantageous of the two L2 solutions when perfected.
Concluding remarks
Reading through this entire series, including How to be fun at parties: understanding blockchain — Student and How to be fun at parties: understanding blockchain — Apprentice (or at least the parts you needed to for rounding out your blockchain and Ethereum knowledge) it is hoped that you are more prepared for any future in which blockchain may have an impact on. Every day more and more governments and businesses are adopting and including blockchain into their decision-making. It is important the public is informed about what all these changes will mean for them, as it is an important pillar of the blockchain community that everything is decentralised and all users have a voice. Thank you, and I wish you all the best for whatever form the future takes upon.
Join Coinmonks Telegram Channel and Youtube Channel learn about crypto trading and investing
