The upcoming launch of EOS Blockchain on June 2nd will be a fundamental historical event many have been waiting for. There is a lot of interest around promises of the first Blockchain running on distributed Proof-of-Stake protocol with a full fledged Governance model.
EOS promises to deliver what many Blockchains currently unable to do including but not limited to speed of transactions. Every success however also breeds enemies. There are stakeholders on countless other platforms and projects who stand to possibly lose should EOS prove successful and deliver on its promises.
Some will be tempted to compromise the launch of EOS Blockchain.
And hence it’s safest to assume there will be various attacks launched on June 2nd with a goal if not derail then significantly complicate the launch of EOS Blockchain.
Let us consider then our latest process for EOS bios boot sequence from security standpoint.
We start with a first eosio node that generates and publishes genesis file for other 121 BP nodes. It starts, establishes bios contract where it adds 21 block producing keys and probably restrict connections to only those 121 BP nodes using peer-key settings.
Once those 121 nodes connect to eosio node, sync up and establish network with each other - we are in relative safe distributed mode.
However that initial period after eosio node makes it IP address known and before other nodes connect to it - may potentially expose us to DDoS attack on boot node.
Consider the following scenario of coordinated DDoS attack:
As soon as IP address of bootstrap node is known to an attacker - it exposes is to potential attack by malicious party. This could significantly affect EOS bootstrap process.
Keeping this information secret may not be possible and filtering all invalid incoming requests can be done to a degree but may complicate joining of valid nodes.
Possible Solution to DDoS Attack
The bootstrap process is only vulnerable because we expose a single point of failure at certain period of bootstrap process. Thus a logical mediation would be to remove single point of failure.
We could change an order of EOS Bootstrap process by establishing a mesh network of BP nodes first. The network will be running idle without producing any blocks.
Then at certain time a eosio node will connect to the mesh network with enabled bios contract and kick block production across all 21 BP nodes instantly.
Step 1: Creating a mesh network of BP nodes in advance of Go Live date:
Again network runs in stale mode and we give BP nodes extended period of time to join in the mesh network. Our experience running Testnets have shown that in geographically distributed environment it takes about 24hrs for 80-90% of nodes to join the network.
Notice that none of the BP nodes on the network knows to whom eosio node will be connecting.
The at a Go Live time eosio node will start and connect to one of the BP nodes directly without ever exposing eosio node to the public Internet.
There are multiple secure scenarios of eosio connection available:
- The eosio runs on subnet of one of the BP producer nodes and connects to it using Intranet.
- The eosio runs separately and connects to one of the BP nodes using VPN connection.
After the network is bootstrapped and all 21 BP nodes start block production, eosio node may safely disconnect. It’s job is done without ever exposing it to outside attacks.
Another upside of current approach is the fact that mesh network can be created days before the Go Live date allowing all 21 BP nodes time to connect, work out any issues that arise and create stable network without the stress of time crunch for everyone.
Authors of this article:
Eugene Luzgin (@eluzgin), EOS Tribe
Eric (@xebb), EOS Sweden
Connect With Us
- Website - https://eostribe.io
- Github - https://github.com/eostribe
- Telegram - http://t.me/EOSTribe
- Facebook - https://www.facebook.com/groups/eostribe
- Twitter - https://twitter.com/eostribe
- Medium - https://medium.com/eostribe
- Dischord - https://discord.gg/Su7pDGt
