Updated: January 13, 2018
[email protected]
[email protected]
Why this thread matters
We’d like to take this opportunity to share with the wider community what we have accomplished in the last week. We firmly believe that the BP community should stand proud on the pillar of inclusion -- as such, we would like to both provide the community an update, as well as give other prospective BPs an opportunity to learn from the trial and error we’ve experienced, which has brought us this far.
This is an effort being made for EOS as a whole. We must remember our efforts must move towards building a global BP community, and a sense of global cooperation. Only in this way can we take aim and build the best network for EOS, which is the ultimate point of running a testnet maintained by BPs all over the world.
Process and Execution
It has been an exciting week for those who have joined us in our efforts. We wanted to share some highlights throughout this experience and hope others can share in the fun of getting this off the ground.
After much community discussion leading up to period 200, it was decided a testnet community be built around the experimentation and testing of the EOS Blockchain. As such, on the 6th of January, a telegram group was created.
We decided to have all BPs pull and compile ‘DAWN-2018-01-05’ from the EOS github repository. Immediately, there were several questions regarding capabilities under various operating systems. Recommendations were made for Ubuntu 16.10, however the community was eager to experiment with and test other solutions. Things started turning into what we later found to be, a dangerous (and fun) direction:
With the limited knowledge we had at the time, which admittedly was even less than we know and understand today, the plan was to activate voting as soon as possible. The motivation for this was due to a general desire to look into the voting mechanics and interaction with certain smart contracts we’d like to build.
After a few hours the genesis block was successfully created. At this time we still thought we could get voting going -- and hopefully even lose control of the blockchain:
And then this happened:
A lot of trial and error getting the initial chain up and running, and getting peers to connect correctly:
We had problems getting the blockchain up and running due to the fact that the genesis-block didn’t contain 21 initial producers. We received some excellent input from block.one and the issue was solved:
And of course a significant amount of celebration:
In an effort to keep all BPs on the same page, we decided to create and use github as a repository for the config.ini and genesis.json
On the naming of the repository:
At this point, we had a blockchain up and running, but we started to experience an assortment of issues and crashes.
Many of us were receiving forking blocks
As such, systematic attempts to replicate the issues began -- and with this, we began to uncover some learnings regarding the general configuration and setup to a successful network.
Given there was a continual effort to find and include other BPs from around the world, we had an inflow of new participants:
Despite all the fun we were having while testing various configurations and intentionally bringing down the network, the time had come to pull out experimental configurations and standardize across all machines. For this attempt, a new genesis.json file was generated up to period 203, and a blockchain was initiated which would act to showcase a working proof of concept. This time, we chose superheroes for our initial producers:
Systems and configurations were systematically vetted before being added to the new network, and we now have a functional network up and running with participants from all over the world:
Learnings
Organization:
It doesn’t take much to misconfigure a node, and it is a lot easier to bring down the entire blockchain than we initially thought. When looking to initialize a functional network, it makes sense to systematically vet node configurations before they are brought online - maybe even create them centrally and distribute them.
In a closed environment where a few VMs are maintaining the entire blockchain, this may seem obvious -- but when collaborating with BPs around the world, making an appointment for such vetting saves a lot of time.
General setup and configuration files
A lot of our learnings regarding the config.ini file have been documented in the resource itself. We encourage you to look at Michael’s repository for additional information.
Initialization of the blockchain:
So far, we have clients running Ubuntu 16.04, 16.10, 17.04 and 17.10. In our testing, zaratustra was able to get FreeBSD up and running -- however it was unclear if some of the initial instability in our network was caused by the modifications necessary to get this node online. As such, we have pulled this node off the network for further testing.
The first node initializes the blockchain and should pass --enable-stale-production on the command line when launching the first eosd instance. The other BPs should connect using the --replay flag.
Peers:
Having one bootstrap peer is enough to get the network up and running. Further understanding and testing is necessary when considering how this works with voting in new BPs and other implications. It is unclear if p2p-peer-address should be set for all 21 nodes on the network.
Secondary Blockchain:
With our main network up and running, we will be looking to create a secondary network which will be used to test various cases to further our insight. There are still many unanswered questions from our initial foray into ‘breaking’ the blockchain. Many of our test cases will also be made possible with the upcoming release.
Additional Participation:
We are hoping to uncover other prospective BPs which would like to join in the EOS Community Testnet. If this is of interest to you, please join us in T.me/eospros.
...
Everything behind this post has been a community effort and we want to thank all participants.
