For the past few weeks we have been testing the new ARK Core v2 software along with the intended v1 backwards compatibility on our internal TestNet and public DevNet. And … the two versions do not play well together. The spaghetti left over from the legacy code of Lisk, and prior to that Crypti, is causing too much heartache and even more headaches. The initial idea was to ensure backward compatibility so any development that was in progress on v1 would be able to continue. The reality is that everyone, including the ARK team is waiting eagerly for v2.
The effort and time that is required to make Core v2 reliably backwards compatible is becoming excessive, and for little to no benefit. As of now, we are abandoning further efforts to make Core backwards compatible with v1. Like your flawed and immature high school sweetheart who just keeps repeatedly torturing you — its time to let her go and move on. Sometimes when you are in a relationship it takes a kick from the outside to achieve clarity. This image from the community sums it up perfectly and provided huge laughs all around.
From this point forward, all focus will be on hard forking to v2 and bringing it to mainnet as soon as possible. This will still require testing of the hard fork process for v2 and a series of critical tests on the v2 network once running smoothly (minus the v1 incompatibility errors). This testing is a large part of what we have been doing internally for the past few weeks.
When the time comes, exchanges will be required to update and there will be a brief transition time as this process takes place. With advanced warning and some hand-holding, we believe we can get the exchanges updated in short order. The v2 code will make the process much easier and more reliable for exchanges.
A future hard fork was already planned to implement AIP 11 following the transition to Core v2. Our current plan is to hard fork to the new Core allowing development using v2 to progress. A future hard fork to implement AIP 11 will still occur, however that will serve to introduce new transaction types and will not affect any new Core development.
Since introducing the new code to the public a month ago, we have been rigorously testing it and working on further development of the Core. The following are several of the items completed during this time:
- Additional tests have been written for core. We’re focused on having 100% Core tests covered, so development will be easier for upcoming changes and much easier to spot any bugs when new code is written.
- Implemented improvements to the broadcasting of blocks.
- Fixed performance issue on saving wallets that tremendously reduces time (as much as from 45 min to few seconds on MainNet).
- Multiple forger hosts/relay make it now possible to run the forger behind a firewall on one server and the relay on another.
- Improved time tracking during sync.
- Added verification of the database after starting of the node process to see the integrity of the database (if database is corrupt it will let you know).
- We’ve started to improve the entire database access to make it safer against SQL injections.
- Forger process has been refactored and rewritten with PBFT calculation and network state detection. We have already tested forging on v2 on internal DevNet as well, with success. It will be further optimized during the upcoming testing period.
- Block transaction sequence improved (now we are storing order of transaction included in blocks) — was needed for rebuild process and support of different databases (different ordering logic of bulk write operations).
- Revamped P2P communication with additional checkpoints and trust logic.
- Implemented the ability to search transactions by senderId via API.
- Several state machine fixes and updates.
Our development process is organized according to best practices and recommendations from top engineering companies such as AirBnB, Facebook and other top companies in the tech industry. In keeping with that same tradition, we have implemented the following new items:
- templates for Issues and Pull Requests (easier to develop and check PR).
- new functionality requires full test coverage (tests should be green before merging code).
We’d like to thank the community developers who have already helped with improving our Core by providing PRs or opening issues they found while testing.
More information can be found at: https://docs.ark.io/docs/contributing
We would also like to thank the community and the ARK delegates for their constant support and eagerness to test v2.
NEW DEVNET
We will release official details on the next public DevNet release once we have completed a few more internal tests. Stay tuned to #devnet channel in our slack to follow along with the official process and updates.
ARK.io | Github | Facebook | Twitter | Forum | Blog | Explorer | Shop