Scaling Chainlink in 2020

Everything within this article is a collection of my own thoughts, research, and findings. It does not reflect any official stance taken by the Chainlink team. If you find any factual errors in this article, please let me know.

A Little Background

The Chainlink mainnet officially went live on May 30th (after three independent security audits) with just three security reviewed node operators (Chainlink, LinkPool, and Fiews). For most of 2019 there was just a single price feed reference contract that aggregated the ETH/USD market price every five minutes (update frequency later adjusted). While the chainlink network was technically live on the Ethereum mainnet, you could think of it more as an extended testing period as the Chainlink team carefully analyzed the reliability and security of their sole Aggregator smart contract (also audited) before they began expanding to include a wider array of different oracle networks.

Before you can run, you must first learn how to walk, especially when your value proposition is building new infrastructure that facilitates trust. Similar to raising a child, nurturing the early outgrowths of trust in the network is crucial to forming a foundation that can support long term success.

Over the course of the second half of 2019, the team successfully scaled the ETH/USD price feed from just three initial nodes (and three data sources) to their stated goal of 21 independent, security reviewed, and Sybil resistant nodes (and ten data sources) with zero issues or downtime. This proved that not only does Chainlink have scalable security but it can do so in an elegant manner wherein developers don’t have to redeploy the entire Aggregator contract each time they want to add more nodes (or remove nodes). This flexibility is important as developers can choose and pay for the exact level of decentralization/security required for their smart contract today, while simultaneously having the capability of easily scaling that security up as needed as the value of that contract rises.

Since launch, the Chainlink ecosystem has grown substantially from just three nodes to over 27 security reviewed nodes that are live today feeding off-chain data to the 29 various Chainlink Price Reference Data contracts currently being consumed by several Ethereum mainnet DeFi protocols such as Synthetix, Loopring, Ampleforth, and Aave. This means that Chainlink Oracle Networks are already securing over $150M worth of collateral locked in the above DeFi projects (now over $740M with the addition of Celsius). Oracle security is absolutely paramount for contracts that lock up and direct user funds. Without a secure oracle solution, DeFi protocols would be putting users’ collateral at risk of loss by malicious actors manipulating the oracle system that delivers the data that triggers and ultimately determines the action a smart contract takes. As the saying goes, “garbage in, garbage out.”

The oracle networks powering these DeFi protocols can be discovered at feeds.chain.link

There are also 100+ independent community nodes listed on the open marketplace market.link. There are also 21+ Chainlink-connected data sources and 23 Chainlink-powered dApps on the API marketplace honeycomb.market. The pace of growth has been nothing short of mind-blowing and showcases a real demand by smart contracts to be connected to external sources of data (usually market prices) from outside the blockchain (off-chain) which is securely and reliably delivered to the smart contract by time-tested and security-hardened oracle networks.

Chainlink Market was created by LinkPool and can be found at market.link

LINK Token Usage

As to why Chainlink needs its own token, I wrote about it in a thread here and The Crypto Oracle wrote about it here. In short,

  • It enables TransferAndCall functionality (allows requesters to send LINK payments and request data from nodes in a single transaction)
  • Isolates the security and economics of the overall network from unrelated external factors (incentives are aligned by having active nodes hold a share of the network and prevent security from being fragmented into many disparate networks)
  • Forces nodes to have “skin-in-the-game” (LINK will be staked by nodes as collateral which can be slashed for malicious behavior or non-performance)
  • Allows the Chainlink team to subsidize early oracle networks to make sure operating a node in the early days of the network is economically feasible (solving the chicken or egg problem of building a new network)

The amount of LINK paid to nodes for their off-chain data depends on the value of the contract being triggered, the use of free/paid APIs, what rates the nodes are willing to accept, and what the requester is willing to pay. Thus, before a network can be established, a price equilibrium needs to be found. The LINK payments need to be high enough to prevent bribery attacks, but low enough to be economically sustainable in the long term. This cost is unique for every integrating contract and oracle network and should be evaluated on a case by case basis.

For example, each node feeding data to the decentralized ETH/USD (21 nodes) and BTC/USD (20 nodes) price reference networks are paid quite handsomely at 0.333333333333333333 LINK per data feed, which has an update frequency of every twenty minutes (or a 0.5% deviation from last update). This amounts to ~7 LINK in total to update just one price feed network. This means a node that delivers data to just one of these price networks is currently paid ~8,760 LINK per year ($40k at current prices) and double that if the node is delivering data to both (ETH and BTC) price feed networks. This puts the total LINK cost of securing just one of these price networks at ~180,000 LINK per year (Over $800,000 at current prices) and double that for securing both networks. These numbers are calculated using worst case scenarios where feeds only update every twenty minutes and volatility is never above 0.5% within that time period (which is unlikely so nodes are actually paid more than this).

The parameters above have since been updated from when I initially wrote this article. As of April, the ETH/USD and BTC/USD feeds (now both 21 nodes each) update at every 1% deviation threshold since the last update and a heartbeat of every two hours. Node payments have also been bumped up to 2 LINK per node per update per data feed. This means node income is now more variable as these networks will trigger updates (and node payments) still incredibly often during times of high volatility, but much less often during times of low volatility.

ETH/USD price reference feed
Example of a transaction requesting an update for the above ETH/USD price network

It should also be noted that, down the line, the amount of tokens paid to each node operator can vary depending on a predetermined function (e.g. first nodes to respond get paid the most), and/or be pegged to a certain dollar amount of LINK tokens (e.g. $0.30 of LINK paid per node for each update) by leveraging a LINK/USD price feed network.

These LINK payment expenses to nodes are required to prevent bribery attacks (ETH and BTC price feeds are high value targets) as nodes who try to cheat would immediately get removed from that price feed (and likely all price feeds they currently feed data to, not just the one attacked). This would amount to losing out on all future revenue, which as demonstrated above, is quite a substantial amount. Such an attempted attack would also destroy a node’s reputation making any chance of them earning more money in the Chainlink ecosystem essentially impossible. Proof of the node’s malicious activity is immutable and forever viewable on-chain or on the Chainlink explorer by anyone. If they wanted to rejoin the network and make any revenue, they would have to create a brand new node and build their reputation all over again from scratch.

Potential attackers would have to convince not just one node to take on this monumental risk but at least 50% of the nodes in an oracle network (since the current Aggregator takes the median). This becomes more and more improbable (and expensive) too the more nodes that are added to a particular network (and the more each node is paid). These nodes would not want to lose out on such a lucrative revenue stream (i.e. payments in LINK and price appreciation of that LINK) for an insignificant bribe especially in the early days of the network. Many of these node operators are also public-facing businesses that offer other services to their customers (PoS validator pools, NaaS infrastructure, etc). Thus, their reputation determines not only their revenue in the Chainlink network, but for all other networks they currently serve. Additionally, node operators could be held legally responsible for their malicious actions as oracle manipulation is already illegal in traditional financial markets.

As the value of the contract increases, the security of the oracle network also needs to rise

The LINK spent on these networks is a big reason why these Chainlink Price Reference Contracts are currently the most secure oracle networks on the market. The cryptoeconomic incentives heavily favor honest nodes as dishonest nodes will lose most, if not all, future revenue in the Chainlink economy. In order to raise the security of an oracle network, the creator/requester could take a combination of multiple paths: they could require each node to stake some amount of LINK as collateral which gets slashed if the node responds with outlier/faulty data or not at all (currently still in development), they could pay the nodes more LINK per request, and/or they could add more nodes to their oracle network to increase both the liveness and security guarantees. All of these methods increase the cost of bribery/collusion attacks, making the oracle network more dependable for the consuming smart contracts.

To sum it up, the LINK paid to nodes operators in each oracle network directly affects the level of security for such a network. While some of the payment is used by nodes to subsidize the ETH gas costs associated with creating on-chain transactions in response to data requests, most of it is pocketed by the nodes as profit. This profit incentive mechanism ensures nodes act honestly in delivering data and do not succumb to bribes. If you are looking to reduce costs of your oracle network, but keep security at the same level (or higher), reducing the amount of LINK paid to nodes is generally not the way to go.

Sharing the Costs

Recent Decrypt article where Sergey spoke about how oracle networks can become a public good

If a project wanted to create a proprietary and isolated price feed, specifically to prevent freeloading of the oracle network they support, they could setup and fund their own oracle network using a whitelist-supported Aggregator contract (in development). In such a model, only pre-approved on-chain contracts can query the Aggregator for its latest/historical data. This is possible as Chainlink is a framework for building/connecting to any kind of oracle network. What works for one project, may not for another; this flexibility is key and is one of the killer features of Chainlink.

By designing oracle networks as public goods that are shared by many projects, the per-node LINK payment costs are reduced, as the costs are spread amongst each individual project without lowering the oracle network’s overall security. But this isn’t the only area where efficiencies can be made in regards to reducing the upkeep costs of an oracle network. We also need to examine the ETH used to pay for Ethereum transactions.

ETH Gas Payments

The user initiating the transaction also chooses the gas price they are willing to pay, denominated in Gwei, for each unit of gas consumed (1 Gwei = 0.000000001 ETH). So while the gas used in a transaction is always fairly static, the gas price you need to pay for each unit of gas can change as the Ethereum network as a whole gets more or less congested (Remember the CryptoKitties craze in late 2017?). If you want your transaction to be processed and confirmed within a timely manner, you will have to pay a higher gas price as miners prioritize transactions with the highest gas price first. Miners can only fit so many transactions in a single block and ultimately want to maximize their profits. Essentially, Ethereum is a decentralized computer with limited bandwidth where users can pay more for better access to quicker bandwidth.

Current gas price estimation of a simple ETH transfer from EthGasStation.info
21,000 gas * 8 Gwei (0.000000008 ETH) = 0.000168 ETH paid in fees for a simple transfer of ETH

Currently, the Chainlink protocol is the third highest consumer of gas in the Ethereum network (can also be thought of as the third highest consumer of Ethereum blockspace). This is just behind dYdX (a margin trading DEX) and the stablecoin Tether USDT (used for value transfer/arbitrage across cryptocurrency exchanges). While Chainlink having this high level of gas consumption is considered bullish to many (as it shows real network usage), it is also one the major factors that contribute to the current costs of running and maintaining Chainlink oracle networks (these costs are borne by both requesters and responding node operators). The ultimate goal is to increase usage, while decreasing the amount of gas consumed.

Chainlink is the third highest gas consumer according to EthGasStation

Understanding the basics of Ethereum gas is needed to understand where most of the current costs of maintaining a Chainlink oracle network originates from. The gas required for requesting an update of an on-chain Aggregator contract (for say a price feed) from an oracle network increases linearly the more nodes that need to be pinged for their data. For example, back when the ETH/USD price feed featured only three nodes, an update request transaction cost 378,440 gas (~$2.04 at 20 Gwei gas price), while today with 21 nodes in the network it costs 2,374,048 gas (~$12.82 at 20 Gwei) to initiate an update. This is already 23% of the available bandwidth in a single Ethereum block!

Gas consumed in each update request transaction for the current ETH/USD price feed

Besides the gas costs associated with requesting an update from an oracle network, there are also the costs each responding node incurs when responding back on-chain with their data. Some nodes may also have to perform and pay for on-chain data aggregation (and update the trusted answer) if the minimum number of responses (a predetermined threshold) has been reached for that particular update round. For the ETH and BTC price feeds, the minimum threshold to start aggregating is after 14 responses (later lowered to 9). This currently costs anywhere from 42,204 gas per response (~$0.23 at 20 Gwei) if aggregation doesn’t need to be performed, all the way up to 144,776 gas per response (~$0.78 at 20 Gwei) if on-chain aggregation needs to be performed. These gas costs scale linearly with how many nodes were pinged for their data (more nodes = more response transactions).

500,000 is the default gas limit set per response transaction by Chainlink nodes. This prevents malicious data requesters from having nodes respond to a malicious contract that tries to drain as much of a node’s ETH funds as possible by performing needlessly complex operations, yet still leave enough gas to allow for the aggregation of many data points. This can also save on gas costs as miners are more picky on transactions that have a high gas limit since those take up a larger percentage of any given block. 500,000 is the optimal amount sitting right in that comfortable goldilocks zone.

Gas consumed by one of the last responding nodes in the ETH/USD price feed that aggregates the data (median using quickselect algorithm) from the previous responses in a round into a single trusted answer

Due to these gas costs (both request and response transactions), the current Aggregator contracts that lie at the heart of every currently live chainlink network can only support a maximum of 45 nodes before encountering gas consumption issues. While 45 nodes are still vastly more secure than a centralized oracle network with only a single node, if they want to eventually secure contracts that are valued in the billions, if not more, then they are going to need to bring these costs down multiple orders of magnitude to enable support for more nodes in a single network. Ethereum’s blockspace is not infinite and if we expect a plethora of heterogeneous oracle networks live at any single given point of time, then ultimately efficiencies need to be made. This is exactly what the Chainlink team has been working on mitigating for quite some time now.

Sigma Prime security audit of the original Aggregator contract, the block gas limit values are outdated now, but the methodology/reasoning is the same

Temporary Cost Saving Measures

In April of this year, these same reference feeds were adjusted to update every two hours and at every 1% deviation from the last update. Payments were also bumped up from 0.33333333333333333 to 2 LINK per node per update. As stated before, these oracle networks will update more often during times of high volatility and less often during low volatility.

Github commit changing the update frequency

While not the most optimal long-term way to scale, this was a quick and easy way to temporarily cut down on-chain costs and create more economically sustainable oracle networks that are being supported by the Chainlink team. This is just the first of many optimizations rolling out to reduce the overall expenses of oracle networks.

Chainlink Nodes and Gas Prices

While transactions usually confirm quickly with no issue, this method causes nodes to often way overpay as the Ethereum network is *usually* not congested enough to justify paying such a high default gas price. This wastes the node operator’s ETH funds and ultimately digs into their profits. For example the gas price to confirm a transaction within one block may only be four Gwei, but the Chainlink node (by default) still sets the gas price to the value held in its database (initially set at 20 Gwei), this causes the node to overpay five times over what it actually needed to.

In order to mitigate this issue, Chainlink integration engineer Thomas Hodges created the Chainlink Gas Price Update Service that node operators can run locally on the same machine as their node. This module automatically fetches the latest gas price from multiple gas reporting APIs (default is EthGasStation, Anyblocks Analytics, and POA network but node operators can choose which APIs they want), and updates the Chainlink node with the max “fast” value of the endpoints every minute.

Chainlink nodes are now much more efficient at setting their gas prices to match current network congestion

By leveraging this gas updater module, Chainlink nodes can always know what gas price they need to set to ensure their transaction goes through in a timely manner while not overspending their funds needlessly. The Chainlink team is working on building this feature natively into the Chainlink node itself, designed in such a way that there aren’t any dependencies on external gas estimator APIs. This makes the overall gas price estimation process of each node much more accurate and censorship-resistant. While it’s unlikely that all three default independent gas estimator APIs are DDoSed, hacked, or compromised at the same time, it’s not an impossibility, so having the Chainlink node calculate gas prices internally, using data from its connected Ethereum node, is much safer (multiple Ethereum nodes are connected behind a load-balancer for redundancy).

Story on the public Chainlink Pivotal Tracker

While this solution lowers some of the costs associated with paying gas for Ethereum transactions, this isn’t enough to scale Chainlink to the security level required by high value smart contracts (ones that would power entire industries: Insurance, Trade Finance, Derivatives, etc). But don’t worry, the Chainlink team isn’t asleep at the wheel, far from it, and in-fact right now there are a few major developments in the works that will largely solve these gas consumption problems.

Data Request Optimizations

How it works is largely in the name, instead of a requester having to make a specific on-chain transaction each and every time they want a data update, they can instead prepay ahead of time by loading the contract with enough LINK tokens (how much is up to the requester and depends on a multitude of factors). More LINK tokens can be added to the contract at anytime by anyone. The Chainlink nodes in the network then autonomously trigger new update rounds, push their data to the contract, and aggregate the data all on a predetermined basis with no further input needed from the requester.

Initially called the “PushAggregator” it was renamed to the “PrepaidAggregator” and then after writing this article renamed as the “FluxAggregator”

These predetermined update parameters can be based on a time schedule (e.g. every 10 minutes), on a deviation threshold (e.g. every 0.5% price deviation since previous update), or a mixture of the two (e.g. every 1% price deviation or 2 hours since last update). This feature is enabled by what the team calls the “Flux Monitor.” Each node would run its own Flux Monitor module (integrated into the Chainlink node natively), this way a new round of updates can be initiated by any node in the network.

All nodes would run their Flux Monitor in the background which would, on a predetermined interval (e.g. every minute), check if a specific threshold/trigger has been met, and if it has, initiate a new round of updates and deliver their data on-chain. Nodes would also continuously monitor the on-chain contract to see if any other node in the network has already initiated a new round of updates, in which case it would fetch the desired off-chain data, feed it into the contract as usual, and perform aggregation if needed.

Product Manager Johann Eid explaining the Flux Monitor in the Synthetix-Chainlink integration thread

The Prepaid Aggregator contract and the Flux Monitor go very much hand in hand, each not being possible without the other. Additionally, this combination also greatly increases the censorship-resistant nature of Chainlink oracle networks as any node in the network can initiate a new round of updates, instead of just the single requester having that capability. DDoSing/censoring the requester would achieve nothing after they've already setup and loaded the contract with LINK. This makes Chainlink oracle networks much more autonomous and fault-tolerant overall.

Trying to perform the same DDoS attack on a distributed/decentralized network of Chainlink nodes becomes increasingly more difficult/impractical the higher the number of nodes in the network (if not being completely impossible due to how nodes are security hardened: e.g. inbound ports closed or IP-locked, denying unauthorized connections, only making external connections as needed). This creates an oracle network that is incredibly resilient to failure and capable of withstanding a much wider array of attacks.

The Prepaid Aggregator also contains many additional quality-of-life upgrades and new security features which greatly benefit both smart contract developers and node operators alike. This includes gas-optimised variable sizes and contract logic, improved readability (and thus auditability), isolated aggregation logic, increased transparency with additional getter methods, optional contract whitelisting for data access control, increased security for LINK withdraws through key hierarchy, and more.

Some of the relevant stories in different stages of development

The Prepaid Aggregator contract will likely end up becoming the de facto standard aggregator contract that will sit at the core of many Chainlink oracle networks, autonomously coordinating node activity and consensus. The contract will eventually become time-tested (and audited of-course) just like the current v1 Aggregator contract is today, and due to the flexible, compossible, and upgradable nature of the Chainlink framework, many more aggregation contracts/strategies can be created (by anyone) as a template or as a specialized contract that can meet any project/dApp’s exact aggregation, security, and off-chain data needs.

The Prepaid Aggregator contract will substantially lower gas costs for the requester (from consuming millions of gas per request to literally zero), but the added complexity in the aggregator contract logic will slightly increase the gas costs experienced by Chainlink nodes when they respond with their data on-chain. Due to this, the Prepaid Aggregator can only handle a maximum of 42 nodes (just slightly lower than the 45 nodes maximum of the Aggregator v1 contract in use today).

While 42 independent oracle nodes is still much more decentralized and secure than what a centralized oracle with only a single node can offer, gas costs still prevent Chainlink networks from scaling to the level required by high-value smart contracts which will want hundreds if not thousands of independent nodes in their oracle network feeding data to and triggering their contract logic. The Chainlink team have long recognized this issue (in the whitepaper), and have been working on a very key development that will largely alleviate this issue entirely.

Data Response Optimizations

To overcome this, Chainlink nodes can instead connect and coordinate off-chain (current plan is to use the libp2p networking stack) and achieve consensus among a majority of the nodes without needing to perform any expensive on-chain transactions to create the final aggregated data point. In order to prove that consensus was achieved off-chain, nodes sign the data and combine their signatures into a single Threshold Signature.

Abstract from the “Threshold Signatures in Chainlink” blogpost

The result is that oracle networks now only have to create a single response transaction to update an on-chain contract with off-chain data. This transaction contains the final aggregated data point and a single threshold signature that proves the data was aggregated and signed by a majority threshold of nodes in the network. The threshold of nodes needed to create a complete threshold signature is determined beforehand and can any fraction of the network (e.g. 2/3, 4/5 of nodes). By having only a majority (not all) of the nodes in the network come to consensus, this avoids any issues related to stubborn/unresponsive nodes holding up progress.

Only a single node in the network needs to create the response transaction (usually the node that completed the threshold signature) leading to huge reduction in the amount of gas consumed in an oracle network overall. Nodes don’t need to stock up on nearly as much ETH as the probability of needing to make an on-chain transaction goes down the higher the number of nodes in a network. Additionally, the cost for verifying a threshold signature on-chain is extremely cheap at only 15,000 gas! This puts the total transaction cost at 36,000 gas (21,000 base gas cost + 15,000 gas for threshold signature logic). This low cost signature verification is achieved by taking advantage of the ECRECOVER trick discovered by Vitalik Buterin.

The most fundamental advantage gained through a threshold signature model is turning a linear cost into a static cost. This breaks the upper bound that was previously limiting how many nodes could operate in a single oracle network. With threshold signatures, any arbitrary amount of nodes can achieve off-chain consensus while only one node needs to push a single on-chain transaction (containing the data point) on the behalf of all nodes. The data point pushed on-chain will only be accepted if the threshold signature is verified to be valid (proves a certain threshold of nodes signed off on the data point) preventing any single point of failure. This means Chainlink networks will scale completely independently of Ethereum’s throughput (or the throughput of any blockchain as Chainlink is blockchain agnostic).

Decentralized oracle networks comprised of hundreds to thousands to virtually any arbitrary number are now not only possible from a technical perspective, but also from an economic perspective as well. As a requester, you can now pay nodes less LINK while those nodes still make the same exact profits (or more) as they no longer have to constantly make expensive on-chain transactions. This drastically decreases the marginal cost of adding new nodes to an oracle network, enabling a diverse and rich ecosystem of heterogeneous oracle networks, all at varying levels of decentralization.

Some of the Threshold Signature Networking stories on Chainlink’s public pivotal tracker

An easy way of thinking about it is that the oracle network is essentially batching all the node’s response transactions together into just a single transaction, which is verified by a single threshold signature. This means the efficiency of Chainlink oracle networks goes from O(n), with n being the number of nodes, to O(1). An update of an oracle network with 21 nodes (ETH/USD price feed), would go from 21 on-chain response transactions (from each node), to only one single response transaction.

If it seems like I am repeating myself, I’m just trying to drive the point home, the advantage of threshold signatures cannot be understated. While 42 nodes are the maximum supported in the prepaid aggregator contract, off-chain aggregation using threshold signatures enables an unbounded number of nodes in a network! Not only can Chainlink oracle networks become massively more decentralized, but they become much cheaper at the same time. Leveraging Chainlink oracle networks will become economically feasible for projects at any stage of development/funding. If you want to understand the more nuanced points of threshold signatures or want to verify the math for yourself, Chainlink researcher Alex Coventry wrote a very informative article that crypto geeks will enjoy.

As of late March, Coventry posted an update regarding Threshold Signature’s development that the team was moving from Schnorr Signatures to BLS Signatures which will greatly reduce complexity and enable much larger signing groups. Off-chain communication efficiency has been lowered from the cube of the number of participants O(n³) to being linear O(n) (assuming the threshold number is roughly a constant proportion of the total participation group). On-chain gas costs for BLS signature verification will be slightly higher than Schnorr, but will still have a transaction efficiency of O(1) and actually lower costs for all participating nodes even further due to enabling much larger signing groups.

Total Costs Saved

Currently, it costs about 2,374,048 gas ($6.41) to request a price update from a network of 21 oracle nodes. With the Prepaid Aggregator contract, this would cost 0 gas ($0.00)! As stated before, this is because the new aggregator contract requires no request transactions to ever be made, effectively enabling infinite gas cost savings in this regard.

Currently, the cost from all 21 nodes responding with data back on-chain is 1,358,377 gas ($3.67), with an average cost of 64,684 gas per node ($0.17). With Threshold Signatures, the response from all nodes when batched together off-chain, leads to a static cost of only 36,000 gas ($0.09). With 21 nodes, this leads to an average per node cost of just 1,714 gas ($0.004)! This is a cost reduction of 37x.

Putting it all together, the total gas costs spent on a single update of the ETH/USD price reference feed from 21 nodes went from 3,732,425‬ gas ($10.07) to just 36,000 gas ($0.09)! This is a cost reduction of 103x.

If we scale things up to the maximum number of nodes allowed in the Aggregator v1 contract (45 due to gas consumption limitations), the total gas costs of a single update would go from ~10,000,000 gas ($27.00) to again just 36,000 gas ($0.09), leading to an average per node cost of just 800 gas ($0.002)! This is a cost reduction of ~277x.

Thanks to the Prepaid Aggregator and Threshold Signatures, an oracle network made up of 10,000+ nodes would still only cost 36,000 gas ($0.09) per update, which is an average per node cost of just <3.6 gas (<$0.000009)! The gas cost savings per node increases as the number of nodes in the oracle network increases.

After taking it all in

It’s important to note however now that with Threshold Signatures being implemented with BLS signatures instead of Schnorr signatures, the gas consumption savings will be slightly lower, but will still offer a substantial cost savings now that signing groups can be made much larger with lower off-chain communication latency and bandwidth requirements. BLS based Threshold Signatures similarly offer a static transaction efficiency of O(1) no matter how many nodes are in the signing group.

Remember that these numbers are just what is spent on gas, but since the gas costs experienced by each node are now much much lower, nodes can be more competitive and accept a lower LINK payment per data request while at the same time the overall volume of the chainlink ecosystem will be increasing, so nodes will also be making up those costs on volumes if not profiting more than before. These cost savings trickle down the end-users of the consuming contracts/dApps.

Wrapping Up

It should be noted that in this article, I limited the scope to only talking about Chainlink’s own network scalability and not about how Chainlink can scale other Smart Contracts through attested off-chain computation using Arbitrum, Trusted Execution Environments, Zero Knowledge Proofs, Mixicles, and more. I also didn’t mention many of the little improvements that have been made here and there to the Chainlink codebase over time, but instead focused this article on the major network-wide upgrades that will dramatically increase scalability, lower costs, and enable a much more sustainable cryptoeconomic model for both nodes and the data-requesting contracts. This would be a never ending article if I tried to cover everything!

Hope your brain didn’t melt too much from trying to soak it all in, but now you see why I believe 2020 will be the year Chainlink scales.

Follow me on Twitter @ChainLinkGod where I fight the information asymmetry surrounding DeFi, Oracles, and Chainlink.

Chainlink Community Ambassador 🦆🦆🦆 Decentralized Middleware Realist 🌐

Chainlink Community Ambassador 🦆🦆🦆 Decentralized Middleware Realist 🌐