Fantom Technical Update — 1

Fantom Foundation
Fantom Foundation
Published in
5 min readDec 3, 2018

Fantom in the last few months have been busy with creating more partnerships and enterprise alliances. However, that does not mean we have been negligent in building up our industry disruptive technology.

Here are some of the things our brilliant research and development team had been up to:

  1. Researched 2 dynamic inclusion/exclusion concepts

Dynamic participation is crucial in operating DAG based platform. Nodes need to be able to freely enter and exit the network and participate in the verification process without disrupting the current ongoing processes. This capacity is enabled by introduction of internal transaction to the node ecosystem, where its used only by the nodes themselves and not outside wallets.

2. Testnet on ports rather than addresses

The system was running on the same port previously. This required separate network interfaces for every node. This complicated network creation therefore put more burden on the network itself. Enabling different ports to be used allowed lachesis nodes to start on the same network interfaces and streamlined testings.

3. Improvements into tester and lachesis to implement large scale testnets

Rolling out multi-node test network takes some time to allow all nodes to spawn. Synchronization of network joins is now established, before transactions into the test network.

4. Identified and fixed various data race issues for n>25 nodes

Go has special flags to enable its built-in race detector. That functionality added into our build scripts enabled data race identification and therefore allowing more stability with greater number of nodes.

5. CI/CD: Facilitated parallel execution of tests through TCP port management test utility

Previously our tests were unable to run on CI/CD system due to use of ‘sudo’ in creating loopback aliases. This was problematic because CI/CD is the proper process flow for development. We were able to modify our tests to fix this problem and facilitate concurrent test execution.

This improvement was significant in that it was a part of our initiative to build a working test suite for developers to make participate and make contribution without fear of breaking other functionality.

6. CI/CD: Added a hard limit to test duration to ensure future test code quality

We identified a reasonable hard limits on test execution time. This improvement was necessary in order to run our tests in a continuous integration environment shared by multiple developers.

7. CI/CD: Fixed failing tests and removed redundant tests

Redundant tests were identified and failing tests were fixed. This allowed adoption of continuous integration and automated testing. As a result of this work, the cognitive burden on developers were significantly reduced.

8. Onboarding: Reducing technical debt by identifying and removing unused transport implementations

There were several transport implementations which were not being used. Unused code is a distraction and imposes a cognitive burden on developers. We safely removed the unused transport implementation as a part of our initiative to improve developer productivity.

9. Onboarding: Improved understandability of the codebase by documenting key interfaces

One of our goals is to make it easier to onboard new developers. We added in code documentation to key interfaces to make it easier for a new developer to understand how everything fits together better.

10. Rebuilt testing CI infrastructure pipeline

Previously self-hosted solutions — Gitlab; Rancher Kubernetes; and SonarQube — were used. Switched to Travis CI, whose GitHub integration can prevent pull-requests from being accepted if tests don’t pass. Similar to our self-hosted setup, only $0 hosting costs. Tests include: `go test` and spinning up a testnet and flooding it with transactions.

11. Upgraded dependencies (including to go-ethereum)

Sent a pull-request to go-ethereum, which was accepted. Upgraded all our dependencies also, including a bump to the latest Go version.

12. Decoupled VM to support multiple consensus mechanisms

13. Decoupled Client / Server VM model to support bi directional communication and subscriber notification

Previously, there had been a 1 EVM to 1 Consensus node relationship. As a result, each node, at startup, needed awareness of its EVM. Now, after this change, EVM’s can simply join and leave the network.

14. Refactored root select to use new dynamic flag tables

… And more to follow!

We will be committing ourselves to deliver more updates in development as they come. Please follow our other channels to keep up with more news about Fantom.

Follow us!

Official E-mail Address: contact@fantom.foundation

Official Website: https://www.fantom.foundation

Official Telegram English Chat: https://t.me/fantom_english

Official Telegram Chinese Chat: https://t.me/fantom_chinese

Official Fantom Reddit: https://www.reddit.com/r/FantomFoundation/

Official Fantom Twitter: https://twitter.com/FantomFDN

Official Github Page: https://github.com/Fantom-foundation

Official Youtube Channel: https://www.youtube.com/c/fantomfoundation

--

--