We believe that in order to achieve mainstream adoption of decentralized solutions, they should be as user-friendly and down-to-earth as possible. But if we’re honest, the blockchain sector still largely caters to a niche of tech savvy people who are comfortable juggling things like hexadecimal addresses and private keys. It’s a landscape where a seemingly simple typo in an address could cause all sorts of potential problems.

For starters, good luck explaining to your grandma-level end user (or conservative energy-industry corporate executive) that ‘0x17E639952c6F98039E75D11Be884792209F26170’ is now their account… And no, it’s not opened in a bank. It’s a... umm… hash thingy, whatever, and you have to save long, scary strings of characters somewhere safe otherwise ‘bad things’ will happen.

Oh, they want to send funds or interact with a dApp? And that process works with something called Metamask?

You get the idea.

UX is king, regardless of technology. If you want to build successful products you have to understand that. Nowhere does that become more apparent than the difference between alphanumeric addresses and people-friendly names. This is true for blockchain-based solutions, too.

It is really unconventional how we interact with a blockchain compared to what we are used to. This is why we are constantly on the lookout for projects that try to bridge this gap and welcome it with open arms: multisig wallets, mobile wallets, recoverable accounts, safes, gas relays, and now... the Ethereum Name Service (ENS).

What is ENS for?

ENS lets you name things. Things that can be stored in smart contracts — addresses, keys, hashes, texts, and links — so you can refer to them in the ‘friendly’ name of your choice instead of what they really are: inhumanly long character strings. 😃 In other words, ENS allows you to put ‘ugly’ stuff in nicer packaging, thus boosting user experience and on-boarding with blockchain-based solutions.

ENS is to decentralized web3 what the Domain Name System (DNS) is to traditional web2. For example, to navigate to our website you can type the friendly energyweb.org address into your web browser instead of its hard-to-remember, not-people-friendly IP address 104.26.12.227. Similarly, if an Ethereum-based blockchain supports ENS, you can type adam.ewc in your wallet to send me tokens instead of ‘0x74dd76E24B2CFB43C1b1a4498295d553D0843746’. Friendlier, isn’t it? This is just a simple example. Naming addresses is not the only use case.

What does ENS look like?

I would describe ENS as encompassing two things: 1) a system of smart contracts and 2) a protocol that describes how resources are managed, stored, and named. It is an awesome open-source project that has been in development for a few years now and it is one of the most-popular projects on Ethereum.

We ported it to our two chains—our Volta testnet and our production Energy Web Chain. Moreover, we also forked the original ENS manager app to add support for them and make name management a breeze. On our chains you can buy names that end with .ewc, which is our chosen supported top level domain (TLD).

How to use ENS?

Using ENS is the same on all Ethereum-based networks. In essence you have to interact with the ENS registry contracts. The easiest approach is to use our aforementioned Energy Web ENS manager app with a very intuitive, nice UI. You need a Metamask account to do so, which you also use to select the chain to connect to.

1. Buy a name. You pay with the chain’s native tokens. Prices go from around $5 to $650 (except on the testnet, of course). Short three-letter names are more expensive. Under the hood, Chainlink oracles feed in token prices to the ENS system, which determine how many tokens you pay.
2. Manage the name. You get plenty of hints and links on how to do it in the manager app. Once you take ownership of the name, you can map resources to it. The manager app allows you to put multiple coin addresses, text-based resources (metadata, URLs, email, Twitter handle, etc.), and content hashes like IPFS. Note that for each name there is a registrant and controller, which do not have to be the same. The registrant is the true owner (aka the admin superuser), but it can delegate the management responsibilities to another account. This is especially useful in corporate environments where the owner account can be kept somewhere secure and management of the name can be delegated to an expert dev team.
3. Use the name. Once done, you can use your name in dApps. This is the tricky part because registering in the ENS system doesn’t mean that names automatically get resolved to addresses or resources everywhere. dApp developers have to support it and integrate with ENS. This part is their responsibility but there is no reason not to support it. ENS only helps.

Subdomains

If you buy a name, let’s say ‘domain.ewc’, you own all of its subdomains too and can configure each one of them as a separate name. Feel free to create as many as you’d like for free, e.g., ‘subdomain.domain.ewc’ or ‘donate.domain.ewc’. You can get creative.

Tip: Let’s say you have a dApp project and acquire ‘myproject.ewc’ for it. When a user registers, you can automatically create ‘<username>.myproject.ewc’ for her, which can already be used as an account for your dApp.

How to support ENS in dApps?

ENS is an enabler to create user-friendly dApps. The goal is simple: wherever there is a user input field for a data type that is supported by ENS (Ethereum address, email, etc.):

1. Detect if the input is an ENS name or not, then…
2. If an ENS name was entered ,you perform an ENS lookup to resolve it to the appropriate resource.

Technically, resolution of ENS names is a three-step process (described in the original ENS documentation here). As an example, you can look at how our online wallet https://wallet.energyweb.org supports ENS. Typed in an address? Cool! Typed in an ENS name instead? It tries to resolve it to an address. Also cool! Both work.

Why not do the same with email, or user name fields on login pages? This way a user’s ENS name can be like a “universal passport” for many things at once and all they have to do is to remember the name they chose.

If you want to integrate with Energy Web’s ENS system, or you want to get involved with some more-advanced use cases, you will find all the info and tools you need on our wiki page about ENS.

What are we doing with the funds generated from ENS?

1. Maintaining ENS infrastructure. Hosting the ENS manager app has costs and Chainlink nodes need to eat.
2. Reinvesting in projects like ENS (potentially via the EW community fund) to make our chains more useful and user friendly.

What’s next?

Having ENS on our chains unlocks some interesting possibilities. Since you can use it to manage public keys and arbitrary texts, we are looking for ways to connect it with our Decentralized Digital Identities (DID) system. Other than that, we will add support for it in all our dApps. We will also open PRs to various ENS client libraries so they find our ENS contract addresses out of the box.

ENS Resouces

• Official ENS docs: https://docs.ens.domains/
• ENS GitHub: https://github.com/ensdomains
• Official ENS medium: https://medium.com/the-ethereum-name-service
• EnergyWeb ENS manager: https://ens.energyweb.org
• EnergyWeb ENS wiki: https://energyweb.atlassian.net/wiki/spaces/EWF/pages/555745281/Using+ENS

Ethereum Name Service (ENS) is now available for the Energy Web was originally published in Energy Web on Medium, where people are continuing the conversation by highlighting and responding to this story.

Let’s see a more complicated setup. For this part, everything is already in place so you don’t really have to deploy anything yourself. The extended system for aggregating results of multiple Chainlink nodes is the following:

The parts

Nodes and Oracle contracts

There are N Chainlink nodes instead of one. It is important to note that Chainlink nodes do not communicate/coordinate with each other off-chain, they are totally independent.

There are N Oracle contracts that each belong to their corresponding off-chain nodes. These are also independent from each other.

I talk about choosing an optimal N later.

The EWT/EUR Job

Each Node runs the following job:

{
    "initiators":[
        {
            "type":"runlog",
            "params":{
               "address":"0x3b903c60ef60c4b29655608576cc16c0ddcd6da0"
            }
        }
    ],
    "tasks":[
        {
            "type":"httpget",
            "confirmations":0,
            "params":{
                "get":"https://api.liquid.com/products/560"
            }
        },
        {
            "type":"jsonparse",
            "confirmations":null,
            "params":{
                "path":[
                    "last_traded_price"
                ]
            }
        },
        {
            "type":"multiply",
            "confirmations":null,
            "params":{
                "times":10000
            }
        },
        {
            "type":"ethuint256",
            "confirmations":null,
            "params":{}
        },
        {
            "type":"ethtx",
            "confirmations":null,
            "params":{}
        }
    ],
    "startAt":null,
    "endAt":null
}

For this Job, no parametrization is done from the client contract to reduce on-chain message size. It is hardcoded to fetch the price from https://api.liquid.com/products/560, multiply it with 10000 and return the value in a transaction.

Contracts

All of them are included in this shared GitHub gist, just import it to Remix as before at Part 1.: 21db5a581949c4ab7882add2bb0d5867.

Aggregators

The Aggregator contract is the heart of this whole operation. Chainlink provides a reference implementaion (Aggregator.sol) that can be modified and extended. The Aggregator contract also derives from ChainlinkClient.sol. How they work in general:

1. The Aggregator usually maintains a list of Oracles and JobIDs. New ones can be added or removed similarly to any other permissioning contract.
2. Whenever a request is made to the Aggregator, it forwards that request to all the Oracles, separately.
3. The Aggregator pays for the Oracles. The Aggregator contract must own enough Chainlink tokens to work.
4. The Oracles run the invoked jobs independently and return the answer in the Aggregator’s fallback function
5. The Aggregator waits until a certain number of results are collected for a query, and then calculates a statistical value, e.g. mean or median, which is the final answer.

The Aggregator provided by Chainlink is just an example. It is expected that you modify it to your needs (result data types and co).

For this poc I use ExecutorPublicPriceAggregator.sol, which I developed only for this price oracle use case:

• It handles uint256 numbers instead of int256s.
• It can execute an arbitrary transaction as soon as enough results are collected. Enough results mean 3-out-of-5 Oracles replies here.
• Instead of the Aggregator paying, the requester has to approve the Aggregator to spend a certain amount of tokens in its name. If the requester doesn’t do it, the requests fail.
• It is meant to be a public price oracle infrastructure poc.

Let’s try it out!

Using the price Oracle

Fetch the necessary contracts

In Remix just compile and add contracts on the following addresses. Copyable version here: https://gist.github.com/ngyam/6d1ffdc727eea2cfdc8636c53a12a677:

Approve some tokens for the PriceAggregator

This was a little bit tricky. I wanted my PriceAggregator contract to be a public infrastructure, so how payments are made to the Oracle contracts? Who pays? The Aggregator is the ChainLink client contract, submitting requests with the “transferAndCall” function of the LinkToken. How can I make sure, that the user pays and e.g. I don’t have to continuously fill up the balance of the Aggregator in some tricky way? Or use some registry of users and their tabs? In the end I decided to simply use the “approve” feature of ERC-20 token contracts.

First, you have to check your Volta-Link token balance which you can do with the LinkToken contract’s “balanceOf” function. If you still need some more you can go back to Part 1 section 3 to see how to get some.

There is a convenience function “calculateRequestFee” in the Price Aggregator that returns how much you have to pay for 1 request, which is now basically the price of 5 individual Oracle requests.

Then go back to the LinkToken contract. With the “approve” function, approve some tokens for the Aggregator contract address, at least 1 request worth. Each time you make a request, the Aggregator tries to pay for the Oracle nodes in your name. If you didn’t approve enough to pay for a request, the call will fail.

Now you should be ready to interact with the Aggregator.

Request a rate update from the Oracle

This is the part when we try things out. You can call 2 PriceAggregator functions:

• requestRateUpdate: simply updates the “currentAnswer” storage variables and “updatedHeight” once enough results are in. Updated height is the blocknumber when the last change happened. The user can actually decide whether he wants to make a new request or the current answer is fresh enough.
• requestRateUpdateWithTransaction: with this you can fire a transaction in the end. I added this because as an external user (meaning an external smart contract) usually wants to some immediate action once the oracle results are in. Loading in a transaction works the exact same way as in the Gnosis Multisig wallets. If you are not familiar with Gnosis Multisg wallets, check out my interactive notebook tutorial here (js) or here (py).

By calling e.g. “requestRateUpdate” you have to see same things happening as for the first part of the tutorial. With the difference that results are coming aggregated.

How results are aggregated

Everything happens in the smart contract on-chain:

1. We wait till the required amount of answers are in, e.g. 3
2. Sort answers, and choose the middle one from the list
3. If the answer-list size is even, we use the mean value of the 2 middle elements.

You can implement of course your own strategy too depending on the use case. If you use Oracles for e.g. random numbers, this strategy would not make sense.

How to choose the number of nodes N and required number of answers k

In theory

Usually you want to have an odd number of nodes and at least 3, e.g. a TMR config.Why? Because of majority voting and error detection. If 1 node says A and the other 2 says B, you can detect who lies. If there were e.g. 4 nodes and 2 would say A and 2 would say B, then who is right?

• 3 nodes can tolerate 1 failure (2-out-of-3), 5 nodes can tolerate 2 (3oo5), 4oo7, 5oo9 and so on.
• 4 nodes tolerate 1 failure too (3oo4) but it is just more expensive then 2oo3.

In addition, you want some protection against 2 types of Oracle failures:

• A node is down, inactive, so the Oracle never sends an answer.
• A node lies, malicious, so it sends a bullshit answer or wants to mess with you on purpose.

In practice

Let’s map theory to my price Oracle use case.

If a node is malicious, there are 2 scenarios:

1. The Oracle reports some too low or high price value. I protect against it by choosing the minimum number of required answers to an odd number that’s larger than 1. Let’s settle with 3. This way the outrageously low or high number gets to the very beginning- or end of the sorted list and it doesn’t get chosen as the answer.
2. If the malicious answer is kinda on the same range as the other answers and gets chosen as median, it is not malicious at all. 😀

So if I’d choose e.g a 3oo5 config, I would protect against:

• 1 malicious and 1 inactive node, or
• 2 inactive nodes, or
• 1 malicious node only

If there were 2 malicious nodes, potentially one of them could be chosen as median.

I could also go with a 3oo4 config which would protect against 1 inactive or malicious node.

Reflection, limitations and further improvements

This is just a simple poc to test Chainlink’s capabilities. Get inspired, take it one step further, but don’t take it too seriously as it is.

• I feel like the ERC-20 token system is a limitation and annoyance that forced me to use this “approve” based scheme to pay for the Aggregator. Could Chainlink oracles work without the LinkToken? Absolutely. With native tokens life would be simpler, but the whole ecosystem is built around this token so you have to buy it. For now let’s just accept that open source projects have to make a living somehow and that’s how the team solved it. If I ever get too bored I might fork Chainlink and make it work with native tokens only.
• An issue of this poc design is that the last Oracle pays for everything: calculates the aggregation of results and fires the loaded user transaction. An improvement could be made where the executor node gets paid extra.
• Scalability issue: increasing the number of nodes linearly increases the number of transactions. N requests, N answers.. Moreover, aggregating a bunch of results and firing the final user transaction in one go can easily bump into the gas limit.
• Chainlink network doesn’t feel like a “network”. Nodes are standalone, do not coordinate and do not see each other at all. They are just offering simple modular redundancy, nothing else. It is completely up to the users how they want to rely on this.
• All public facing nodes would have to somehow publish the Jobs they are offering and how they accept the requests. There is no service discovery. You have to tell a friend, or enlist on a service market e.g.: https://market.link/.
• The other thing that I’m missing is a wholesome incentive scheme. Oracles are getting paid for work, but they are not punished if they do not fulfil their duties or are proven malicious. A staking/slashing system would be interesting to consider here. Modular redundancy helps, but you’d get stronger guarantees with something like this. There are already some ongoing efforts that you can read about here.

When would you use Chainlink?

Smart contracts need to be poked from outside, so most DApps have off-chain components and workers. Why would you use Chainlink then? Why would you aggregate on-chain?

First of all you want to put things on-chain that are mean to be public and disputable. This means that Chainlink comes handy when:

• You want to fetch data from a public, third party API, so publicly verifiable information. Think of price pairs, weather, scores, etc.
• You want to show an undeniable proof of honesty to your users: what data you fetched, when did you fetch it, and how you calculated the outcome. All this with an immutable, historical trace. You need to prove you honesty for the preservation of trust.
• You want to spread risk. Airplanes have 3 of everything from different manufacturers. You can achieve the same with Chainlink’s modular redundancy and aggregate results of different providers.

Second, the UX of Chainlink is amazing (or should I say DX for developer experience?). You can setup one node/Oracle in minutes. If your DApp consists mostly of smart contracts why would you bother developing off-chain components for simple things? You get one out of the box.

The end

I hope you enjoyed this journey with Chainlink on our chain. I keep my nodes running on AWS so the PriceAggregator is quasi public infrastructure on Volta, you can rely on it for your pocs. Not production grade though. If you have some cool addition or different Aggregators, feel free to create a PR to my GitHub repo. I plan to share some other cool things I’m involved with in the future, so stay tuned!

Navigation

← Part 2.: Running your Jobs
← Back to Introduction

Need help with your blockchain based project? Shoot me a mail: adam.zsolt.nagy@gmail.com
Did you learn something useful? Made your job easier? Tips are welcome too: Ethereum: 0x74dd76E24B2CFB43C1b1a4498295d553D0843746

4. Creating Jobs on your Chainlink node

The only step left is to populate your node with Jobs so they can actually serve requests coming from your smart contracts. Read about what Jobs, Adapters and Initiators are here. These are your building blocks.

TL;DR version:

• Job: A sequence of actions processing a request.
• Adapter: A step in processing a request.
• Initiator: Defines how a Job run is triggered. The “first step”.

You have to specify Jobs in a JSON format, and you can add them in the Jobs section of your node’s GUI.

I want to make an oracle for the EWT/EUR price pair listed on Liquid, so I am using the following Job specification:

{
    "initiators":[
        {
            "type":"runlog",
            "params":{
               "address":"0x1a63f77dD7Dc0c28220e10D6DBbd7d1e5104fb05"
            }
        }
    ],
    "tasks":[
        {
            "type":"httpget",
            "confirmations":null,
            "params":{
            }
        },
        {
            "type":"jsonparse",
            "confirmations":null,
            "params":{
            }
        },
        {
            "type":"multiply",
            "confirmations":null,
            "params":{
            }
        },
        {
            "type":"ethuint256",
            "confirmations":null,
            "params":{
            }
        },
        {
            "type":"ethtx",
            "confirmations":null,
            "params":{
            }
        }
    ],
    "startAt":null,
    "endAt":null
}

Let’s go through what these mean:

Initiator is a RunLog, which means the node will trigger a job run to an OracleRequest event emitted by the Oracle contract at 0x1a63f77dD7Dc0c28220e10D6DBbd7d1e5104fb05, which I deployed earlier.

Then our request will get processed by the Adapters, in the order they are defined sequentially, as a pipeline:

1. We create HTTP GET request to a URL that will be given from the client Smart Contract
2. We parse the result to JSON and get the value defined in a path given from the client Contract as a request parameter
3. We multiply it by a certain amount which is also given from the client Contract as a request parameter
4. Transform it to uint256 type
5. Aaand fire the result as a transaction

As you see this job description is quite generic, which means the adapters can get parametrized with the request initiated from the smart contract, e.g.: which URL should be fetched, what value to multiply the result with, what are the callback transaction params, etc.

There are so many other cool options that you can try. e.g.: CronJobs as Initiators that regularly feed data to your smart contracts or Compare Adaptors for true/false results.

Once you create the job, your job gets an ID. You can create many jobs running on one node, and list it in the Jobs section of the GUI.

5. Use your Chainlinked contract

Now with all contracts in place it is time to try things out. Let’s call the “requestEwtPrice” function. It takes the Oracle address and the Job ID as params.

function requestEwtPrice(address _oracle, string _jobId)
    public
    onlyOwner
{
    Chainlink.Request memory req = buildChainlinkRequest(
        stringToBytes32(_jobId),
        this,
        this.fulfillEwtPrice.selector
    );
    req.add("get", "https://api.liquid.com/products/560");
    req.add("path", "last_traded_price");
    req.addInt("times", 10000);
    sendChainlinkRequestTo(_oracle, req, ORACLE_PAYMENT);
}

You can see in the source code what is the URL being called, what JSON field we are accessing, and what value are we multiplying the price with. You can just check the URL in the browser to see how it looks like: https://api.liquid.com/products/560. We access the last traded EWT/EUR price pair through Liquid’s public API.

You can also see that “fulfillEwtPrice” is the function that gets fired once the results are in, which just sets the “currentEwtPrice” state variable in the client contract.

If all went well, you have to see the “currentEwtPrice” to be set to a non-zero value in Remix. If you check you node, you can see that a successful Job Run was triggered. You can access its details to see the transformations that were applied at each step.

That’s it with the basics! Now we can move to the cool stuff everyone is waiting for: how aggregation of results look like in smart contracts in Part 3.

Materials

You can find all the materials on my GitHub for the scripts and Chainlink contracts.

Navigation

← Part 1.: Setting up a single node
Part 3.: Aggregation of results and synthesis →

Need help with your blockchain based project? Shoot me a mail: adam.zsolt.nagy@gmail.com
Did you learn something useful? Made your job easier? Tips are welcome too: Ethereum: 0x74dd76E24B2CFB43C1b1a4498295d553D0843746

1. Let’s get started with setting up the node!

The Chainlink documentation provides ample tutorials to get started. We are going to go the Docker way, so if you have it installed you are ready to go. I don’t want to completely duplicate the original guide because it is well written so I just focus on the settings I applied.

1. Create a separate folder for the node where it is convenient, e.g. YOUR_PATH/chainlink-volta-1/. In our example, this is where the node will keep all its data.

2. The main difference you have to make is the LINK_CONTRACT_ADDRESS and the ETH_URL in the .env generation bash script. The link token contract is deployed at “0xe76d478383327b83eE0FE6b3F0ec675315340E18” on Volta. Feel free to change the RPC URL to your local-, or another remote Volta node if needed. You can find all configuration variables here.

#!/bin/bash

echo "ROOT=/chainlink
LOG_LEVEL=debug
ETH_CHAIN_ID=73799
ETH_GAS_PRICE_DEFAULT=1000
ETH_GAS_BUMP_WEI=1000000000
ETH_GAS_BUMP_THRESHOLD=3
MIN_INCOMING_CONFIRMATIONS=3
MIN_OUTGOING_CONFIRMATIONS=3
LINK_CONTRACT_ADDRESS=0xe76d478383327b83eE0FE6b3F0ec675315340E18
CHAINLINK_TLS_PORT=0
SECURE_COOKIES=false
ALLOW_ORIGINS=*

ETH_URL=wss://volta-rpc.energyweb.org/ws" > .env

3. To start up the node, you can run the bash script below. cdir is just the directory where your bash script is located, and host_port is where you can reach the graphical interface of the chainlink node on localhost. A Chainlink node exposes a nice GUI for managing it.

#!/bin/bash

host_port=6688
cdir="$( cd "$(dirname "$0")" ; pwd -P )"
docker run -p $host_port:6688 -v $cdir:/chainlink -it --env-file=$cdir/.env smartcontract/chainlink:latest local n

4. The first time you launch the node, the terminal leads you trough creating a password for a keyfile of a new Ethereum account. This account belongs to your node for creating transactions on the chain. You also need to give user/pass login credentials for the GUI.

4.1. If you don’t want these credentials to be regenerated for your Chainlink node, you have to save them. E.g.:

• Create a .secret file and put the keyfile password into it
• Create a .api file and put the user on the first line, and its password below on the second line
• Now when you start the node again, you have to pass your credentials with the -p and -a flags

#!/bin/bash

host_port=6688
cdir="$( cd "$(dirname "$0")" ; pwd -P )"
docker run -p $host_port:6688 -v $cdir:/chainlink -it --env-file=$cdir/.env smartcontract/chainlink:latest local n -p /chainlink/.secret -a /chainlink/.api

5. Login to the GUI. If everything went well, you can navigate to http://localhost:6688 (or the port you set) for the login screen. Clicking the Configuration page, you can find your node’s address (ACCOUNT_ADDRESS) and all the settings that you applied.

6. Put some native tokens on your node address, otherwise your node can’t interact with the chain. On Volta this is very easy using the faucet.

Congrats! Your Chainlink node is up and running. It is pretty much useless without Jobs and the on-chain components though.

2. Deploying the necessary Smart Contracts

For this part you better use some interactive tool. I chose Remix with Metamask to connect to our Volta remote RPC. To add Volta to Metamask, follow our wiki page.

You can load the smart contracts to Remix from GitHub Gist with ID: d899cf4ecbc352bba1d9ba6c9c9db4d8.

Oracle.sol

This is the first contract to deploy. Oracle contracts can be monitored by the nodes running off-chain to listen for requests.

1. These contracts can only be compiled with a 0.4.x compiler. I used version 0.4.26.
2. When deploying, you have to pass the constructor the Link Token address on Volta, which is 0xe76d478383327b83eE0FE6b3F0ec675315340E18.
3. Once deployed, you have to permission your Chainlink node’s address in this contract. This is done by calling the “setFulfillmentPermission” function. If you don’t do this, your node will not be able to pick up requests coming to this Oracle contract.

ATestnetConsumer.sol

This is the client contract that makes the requests and receives the results. To integrate with Chainlink, your contracts have to simply derive from ChainlinkClient.sol.

After compilation just simply deploy. This contract does not need constructor parameters for deployment.

3. Get Volta-Chainlink tokens to fuel your Oracle requests

The Chainlink ecosystem runs on ERC-20 Chainlink tokens, so your client ATestnetConsumer.sol must have some in order to make requests to the Oracle. There is no free lunch.

I developed a simple crowdsale contract for this purpose that can be found on address 0x3f312acB7c48Eb4e2A2E2B6C89FD7a2011F45915.

To reach it, compile LinkTokenSale.sol but choose a compiler that is 0.5+ version. Instead of deploying just use the “At Address” button with the address given above.

Next, you have to buy the Volta-Chainlink ERC-20 tokens with Volta native tokens by calling the “buyTokens” function. Buy the tokens for the address of ATestnetConsumer.sol. For this to work, you have to fill out the Value field as well which is right below the Gas limit settings. The Crowdsale contract exchanges tokens in a 1:50 ratio, so e.g. for 1 Volta Token you get 50 Volta-Chainlink tokens.

That’s it for Part 1.

In Part 2 we are going to set up a Job and try out our Oracle client.

Navigation

← Introduction
Part 2.: Running your Jobs→

Need help with your blockchain based project? Shoot me a mail: adam.zsolt.nagy@gmail.com
Did you learn something useful? Made your job easier? Tips are welcome too: Ethereum: 0x74dd76E24B2CFB43C1b1a4498295d553D0843746

• Introduction
• Part 1.: Setting up a single node
• Part 2.: Running your Jobs
• Part 3.: Aggregation of results and synthesis

Oracles

It is often the case that your smart contracts need external data feed in order to do their proper job. Smart contracts cannot reach out to the external world to fetch data, cannot schedule transactions, so they rely on external entities/third parties to do this which we call Oracles. When you need to “blockchainize” real world information, Oracles are always there in one form or another. The flipside though: they introduce heavy trust assumptions in your otherwise trustless system. How can you trust an external data source? What if there is malicious intent, the source gets compromised or data never arrives? These are not trivial issues.

Chainlink’s value proposition

Chainlink aims to bridge the on-chain & off-chain world with decentralized Oracles, eliminating single-point-of-failures and unconditional trust in centralized Oracle services. They provide this in a hassle-free manner for contract creators and developers so they can focus on what actually matters: their use case. As you will see, setting up Chainlink nodes and getting integrated at smart contract level is surprisingly easy.

The aim of this series

I like to be hands-on so expect hands-on stuff and some bonus memes. We will:

• Learn how to set up a Chainlink node and use it from a smart contract on our public Ethereum testnet, Volta.
• Learn how to aggregate the answers of multiple Oracles, and how to use the public EWT/EUR Price Pair Oracle infrastructure on Volta.
• Learn some design principles around Chainlink oracles.
• Philosophize about when does it makes sense to use Chainlink.

Why Volta? B̶e̶c̶a̶u̶s̶e̶ ̶I̶ ̶m̶a̶d̶e̶ ̶i̶t̶.̶ We at EnergyWeb created the world’s largest energy blockchain ecosystem with more than 100 companies and 2 enterprise-grade blockchain platforms: the Energy Web Chain and a related testnet called Volta. They are Ethereum chains with Parity’s AuRa Proof-of-Authority consensus engine, 25+ reputable energy corporates as validators, rock stability and 5s block times. Thus, even if you are not doing anything energy specific it is worth to use Volta as a live Ethereum testnet because from a dev perspective it is the same. You can get started here.

Since more and more of our projects need some kind of Oracle service, the time has come to look into it and set the Chainlink infrastructure up on our chain as well. I decided to document my journey and share the outcome of my experimentation in form of a tutorial series as a pledge to the open source community. Naturally, everything is applicable to any other Ethereum network too.

Need help with your blockchain based project? Shoot me a mail: adam.zsolt.nagy@gmail.com
Did you learn something useful? Made your job easier? Tips are welcome too: Ethereum: 0x74dd76E24B2CFB43C1b1a4498295d553D0843746