bakon
9 min readJul 17, 2018

NODES.
Running one, Security and WHY?

Why run a ETC node and what are the benefits of running one? This is probably the #1 question I see around the blockchain community and have been asked tons of times, ever since I entered the blockchain world in 2017.

One thing I have learned and keep seeing that in order for a network like ETC to survive it really depends on ETC nodes and not just the amount of those nodes out there but also their quality and security.

Before I even start digging in about the importance of nodes, why it’s beneficial not just for the rest of the network but for you as a user or developer and the security benefits of running your own node. But before we start lets quickly go over what a node client actually does.

Nodes on blockchain technologies like ETC are the essential part to the whole eco structure, especially since ETC is a 100% decentralized p2p network, we’ll get into that later, a nodes main job is to connect to other nodes download and sync the blockchain data, and using a consensus protocol in this case we’re writing about ETC so our consensus protocol is Proof of Work(PoW), to process new transactions or requests which could be anything from executing smart contracts to transferring funds.

At this point the word MINER or MINING is probably screaming in your head, especially if you’ve already heard or read about PoW type blockchains before or just about the PoW consensus protocol in general.

And you are correct to, miners play a big PART in PoW type blockchains. Long story short, since this is a node article miners get their work from nodes. When a node receives or processes a transaction it creates a job out of it and sends it out to the network to get mined(Verified), this network might be a mining pool or just a miner setup directly to communicate with said node. We’ll talk about setting up nodes for direct mining and pool mining in another article

So quick recap, you run NODE client software of your choice, ETC has several available at this point, which will be covered in an later article. The node client is installed on an operating system of your choice, most ETC node clients support all major OS’s, like Linux, Windows, and Apple MacOS. After running the NODE client of your choice, it connects to other nodes using p2p(Peer to peer) network technology.

If this node client is running for the first time on that machine it will download all the blocks and their transactions from the fully synced nodes on the ETC blockchain and save the data to its local database. (Note this can be fine-tuned in different NODE clients to help preserve hard drive space)

Once that’s done congrats, you are now an owner of your own data and your own bank. The node is ready to accept transactions and distribute work and communicate with other nodes about processing new blocks. Pretty much anything from receiving new transactions or funds being send and then sending work out to miners to confirm and create a new blocks, or your a node is setup as a RPC API end point for dapp developers, IoT devices to submit data into the blockchain with gathered information, or for exchanges and hopefully in the future cross chain communications. But again, greatest part, you are at this point 100% in control of your data and money.

On a distributed network like ETC, the more fully synced nodes you have. The more secure and bullet proof the network will start to become.

Imagine in the above image, which is displaying a distributed network. Each one of those dots is a fully synced ETC node which contains information on all ETC Blocks which contain all transactions processed on the ETC blockchain and all smart contracts or dapps deployed onto the ETC block chain. Now if one of those Nodes(dots) all of a sudden gets wiped out from this universe due to whatever, server melt down, internet outage, etc etc. The whole network does not die and access to any smart contracts or dapps deployed on there is not lost, since every single node(dot) is a fully synced database with the same exact data as its counterpart, you would literally have to make sure that every single ETC node is wiped out off the face of this universe. Because if only one of those nodes comes back online and gets a chance to establish coms with another node of its kind, the syncing and self-healing process begins.

Now sit there and think about this for a minute, imagine that there are millions of NODES all over the world each with the same exact smart contract, dapp, and data as its counterpart. Meaning that short of shutting down communications in let’s say a country, the network of nodes can virtually not be stopped or be disposed of.

Hopefully at this point you have some what of an idea of what a node client is and why nodes are so important to the ETC network in their general functionality and why in numbers they create such a powerful and secure network.

But it doesn’t just end there, there is also a whole other part to the world of nodes. If you have notice this whole time we have been learning on how nodes communicate with each other, store the blockchain data, and process transactions using a consensus protocol.

But how does that information get on there in the first place and how do we access this information stored in the blockchain database? ETC node clients have something called JSON RPC API. If you have ever dabbled in any type of web development you have probably heard of JSON(a lightweight data-interchange format, which can represent numbers, strings, ordered sequences of values, and collections of name/value pairs.) .

JSON-RPC is a stateless, light-weight remote procedure call (RPC) protocol. Primarily this specification defines several data structures and the rules around their processing. It is transport agnostic in that the concepts can be used within the same process, over sockets, over HTTP, or in many various message passing environments. It uses JSON (RFC 4627) as data format.

If right now anything about JSON and RPC or API still sounds like black magic don’t worry it’s not that hard. All the above is, is it’s a standard agreed by ETC node or Ethereum node client developers that lets 3rd party developers talk to node clients. Quick search on google for API and JSON should help you understand a bit more.

But to give a simple example. If for instance you want to build a simple user interface that looks up the funds at a certain provided address on the ETC blockchain, you will need a node client running that gives you access to the above said JSON RPC API. Just setting up this access to this JSON RPC API could be risky business in itself if you somehow stored a ETC account on your node, this will be explained later.

Another great example is, You have a IoT device that is deployed in the field collecting information about air quality. The device needs to of course sync that information it’s been gathering to the ETC blockchain so its user can later connect to the ETC blockchain and view the data.

Each one of these transactions, from the moment where device submits info to the ETC blockchain to the moment where a user access the ETC blockchain to view the data, needs a node to access the data through.

Now, when you just simply run a node client like we have been writing about this whole time, to just support the whole network and process transactions, you’re just exposing yourself to other nodes on the network, nothing really insecure about this.

Most node client software doesn’t really provide secure networking. It is not safe to expose Ethereum JSON-RPC API to public Internet as even with private APIs disabled this opens a door for slew of DDOS attacks. But at the end of the day node software doesn’t really need to provide secure networking primitives, as this kind of built-in functionality would increase complexity and add attack surface to critical parts of node software. And also most node clients allow you to setup up if you want the JSON RPC API enabled, what IP address and port you want your node to listen for the JSON-RPC calls, for the most part if you don’t store any accounts on your node or if you do and they are locked, there isn’t much anyone can do except maybe flood your node with RPC calls for whatever their intentions and of course the above mentioned various DDOS attack etc etc.

With that said above, hopefully you now have a little bit more of an understand of how your interaction with the ETC blockchain works through node software works and more of an insight on why using wallet software with your own local node is the mist secure.

If not I’ll do a quick over view of it and also touch up briefly on how some man in the middle DNS attacks have happened with wallets, how to install a NODE client and which securities to look and watch out for. Remember if you are adapp developer, UI/UX developer that relies on data from the blockchain, or just even using a wallet this section is for you.

Lets start with wallets and nodes, at the end of the day all a ETC wallet is, is a user interface usually written in Javascrip that uses JSON RPC API calls usually through libraries like web3.js for Javascript developers like myself. In short, “Under the hood it communicates to a local node through RPC calls. web3.js works with any Ethereum node, which exposes an RPC layer. “.

And here is where many web wallets have a vulnerability, the smart thing to do is run a node with an exposed RPC layer only to the internal network and your wallet application running locally alongside the node client to submit and receive RPC calls. Of course this would be in the perfect world, where everyone has access to hardware, and the want to and know to install node clients. Go through all the networking setups while making sure the server is secure to expose the RPC Layer, oh and wait let’s not forget our mobile devices.

Cause what would be the whole point to this, if you couldn’t run your ETC wallet on your phone and show off all your ETC to your friends, and I don’t foresee running a fully synced node with the RPC layer exposed on your phone just to run a wallet app is happening any time soon.

So devs resolve to connecting to remote nodes, meaning the wallet app, connects to a node running somewhere else for ease of use and efficiency. Usually if https is used this is not an issue at all and if you know that you are actually sending your transaction to what you really think is a node on the other side.

Most good open source wallet apps even the online hosted ones now days give the option to connect to your own node if you have one running, which is your best bet a this point if using a online hosted wallet solution like https://ethereumproject.github.io/etherwallet/ Classic Ether Wallet.

For the most secure wallet solution to date for ETC blockchain I have found to be the Emerald wallet, for the simple reason, because the wallet upon first run gives you the option to automatically run and sync your own node for the wallet to use locally, or if you already have a GETH-ETC Node client running on that machine with he RPC layer exposed, it will automatically detect it and try to connect. The first option is the best, easiest and most secure in my opinion, having it automatically setup a full node client for you on first run.

Another example why it’s beneficial of running your own NODE client as a dapp developer. In order to deploy your dapp, smart contract or just interact with it on the ETC blockchain, like mentioned earlier. All of these transactions have to be submitted to a ETC NODE to be processed onto the blockchain or to execute a smart contract on the ETC blockchain.

And just like with running your wallet apps, the best bet is running a fully synced local ETC node with the RPC Layer only exposed to the local network, but of course that is not always the option.

And of course let’s not forget our IoT devices. If you have a fleet of IoT devices deployed in the field, they more then likely require a remote node to send all their transactions to. And in general like now days, you don’t have you IoT device send information a untrusted server address end points even though hopefully they end up in their right database. You go setup your own node expose the JSON RPC API as needed and point your IoT devices to your node to process the info, then your node will do the rest and distribute the information for further processing.

Hopefully at this point you have a little bit more of an understanding on why running your own ETC node client, is not only beneficial for the network as a whole, but the security benefits and piece of mind you get being able to process transactions through your own node knowing where they go every time.