Many participants had difficulty invoking the IAM smart contract on NEO at the beginning of our token sale. There were a few matters that challenged us preparing for and managing the mainnet token sale, most notably our whitelist upload. Our team created a script in-house, which through neo-python, would upload a set amount of public wallet addresses with each transaction that registered on the blockchain. For reduction of GAS expenditures, we were only able to upload 6 addresses per transaction. Adding additional public addresses to the transaction would increase the GAS cost to a point where it became economically infeasible with the number of addresses we had to process. The problems began for us when transaction response timeouts led to our script failing. Responses from the mainnet nodes took up to 3–4 minutes to report back to us; the default timeout value in neo-python was 120 seconds. The Bridge team had not observed these issues with nodes during our testing of the smart contract on our privatenet and the public testnet, for obvious reasons. The seed synchronization issues and node failures required immediate action to resolve so that our token sale could complete in the manner we sought, and the window was closing hour by hour. After consulting with some City of Zion members on the situation at the time and then seeing the call for community support on February 24th, we determined that deploying our own seed nodes would not only support our efforts, but those of the ecosystem as a whole. And for those who participated, you’ll have noted that we had to adapt to this circumstance on the fly in order to serve everyone who experienced these widely noted issues. Many people also selected the option in their NEON wallets to participate without verification, which triggered the need for a significant amount of refunds to be processed. The token sale quickly required our small team to re-posture and with all hands available, provide customer support for the remainder of the sale.

I was asked for some technical details on Discord about how Bridge deployed 10 full nodes so rapidly. NEO-CLI provided the full RPC node and was readily available as a pre-compiled binary. For our deployment, we used DigitalOcean ‘droplets’ (their term for virtual machines or VMs) running Fedora 27 x64, with 8GB of RAM, 4 vCPUs and 5TB of transfer bandwidth for each instance.

I started with a single VM instance and built out. There were dependencies to resolve in order to get the VM prepared to run neo-cli. This may require some translation from the supplied documentation to equivalent packages depending on the flavor of Linux you decide to use. Once the node is operational, it simply requires a bootstrapping and synchronization of the block height difference. Once this step was completed, I simply took a ‘snapshot’ of the VM and made it available to a variety of regions where DigitalOcean has their datacenters. It was a simple operation to create new VMs from that image, log in and start the node application. I chose regions that our participants were based in, and added two nodes in places where I would expect heavier peer loads. Since Bridge is based in the United States, I ensured that there were nodes geographically close to where we were operating the token sale to ensure our interaction with the smart contract was expedient and stable.

The additional infrastructure served Bridge well during the token sale, and should have been a great resource for other activities occurring on NEO during that time. For the foreseeable future, Bridge will maintain the nodes to support the Smart Economy, and we applaud the other projects and individuals for answering the call and providing additional throughput to enhance operational capacity of the NEO blockchain.

To view the current status of the seed nodes running on the mainnet and testnet, go to: http://monitor.cityofzion.io/