Meros Update #27
Welcome to Meros’s Update #27, covering 1/16/20 to 2/19/20! It’s been five weeks since our last update, as we’ve been publishing Developer Testnet updates in the meantime. These five weeks saw the addition of Merit Removals, two testnets, brand new networking code, multiple quality-of-life additions, and more bugs fixed in a single update than ever before.
Merit Removals are a critical part of the Meros protocol, and a way to automatically penalize those who would try to harm the network. There are multiple reasons for one to exist, and we previously have implemented proper handling for some of these reasons. That said, when we did our “No-Consensus-DAG” branch, the causes of a Merit Removal changed, meaning we had to remove our progress. Before we started our testnets, we managed to add in functional Merit Removals for every case.
Speaking of testnets, we launched Developer Testnet 2 as the successor to Developer Testnet 1D, which occurred all the way back in January 2019. We successfully had spun up a few nodes running Meros and verified a network could exist, beyond our highly structured test environment. DT2 originally wasn’t going to include seed nodes and peer finding, a feature necessary for mainnet yet not necessary for protocol testing, yet we managed to finish the feature in time. This was our mistake.
Despite testing peer finding via our test suite, it was unstable at a large scale due to the way it modified network behavior. This, combined with other bugs, made the network too unstable to maintain for more than a few minutes. We attempted to fix the network, and did create several patches on a dedicated branch, yet the task ended up being too large to fix quickly enough to continue the network. We made the decision to declare the testnet over, and rebuild our networking code from the ground up to have the architecture needed to scale.
The problem with our networking code was a blemish on the protocol called “sync mode”. Sync mode was a special set of network messages any node could trigger. When one node started sync mode, the other node was required to respond with specific data in a specific order, as requested by the node which initiated sync mode. It had two problems in its design. The first is that it suspended regular network traffic, instead only allowing sync data, in order for the two sets of data to not intermingle. The second is that it was one-way; only the node which started sync mode could send sync requests.
We removed sync mode by having nodes create two connections with each other; one is for live network data while one is for data being synced. The new sync connection is also bidirectional, letting either party make requests at any time. This change required rebuilding almost all of our networking code, yet once it was done, we were able to start Developer Testnet 3.
DT3, beyond testing what DT2 was meant to test (as in, everything, since it’d had been a year since our last testnet), was also meant to test our newly rewritten networking code. We launched the network and discovered a new bounty of bugs, as the network was meant to do. Overall, the network succeeded, working as expected. We’re very happy with how it went. That said, it was missing two features that are required to properly maintain a network over time.
The first is chain reorganizations. As a tricky feature, it has been continuously put off. That said, as of the current codebase, when two miners find a block at the time, the network splits, which is the antithesis of stability. The second is “locked Merit”, which we’ve touched on before. When miners go offline, their Merit still exists. As it’s unusable, it solely hampers the network which expects voting power to vote when it never will. To solve this problem, Meros locks voting power which goes offline for a certain amount of time. This voting power isn’t gone forever, as it can be unlocked when the Merit Holder comes back online. When too much Merit is offline however, Meros stops being minted, which reduces the amount of features we can test.
We assigned these features, along with a plethora of bugs, as requirements for us to complete before we can launch Developer Testnet 4. Their status can be tracked via this milestone. Most of the bugs found thanks to DT3 have been fixed already. Chain reorganizations aren’t yet completed, yet are mostly finished, and should be ready within a few days.
Beyond all of the development, there is one other thing to note. A dear community member created an issue concerning Meros’s funding. The plan was for Meros to have a premine of roughly 350,000 Meros, or seven weeks of coin issuance, timelocked over two and a half years. The problems noted in the issue are twofold; the first is the funding’s finite nature, the second is the fact it pays out in lump sums which can be disruptive to the coin’s economics.
In response to this issue, MIP-0001 was written. MIP-0001 is the first Meros Improvement Proposal; a document meant to change or extend the Meros protocol for its benefit. MIP-0001, also known as the “Meros Development Fund”, outlines a decentralized solution where users vote, with one coin equaling one vote, for various parties to receive newly minted funds in order to ensure Meros’s continued growth and success. MIP-0001 represents a rather large change, as well as further decentralization.
MIP-0001 is currently still a draft which must be finalized before acceptance into the protocol is discussed. Its discussion is occurring here. We encourage all of our community to participate and give their thoughts.
Finally, we’d like to invite our community to another round table. Our last round table was on November 16th, 2019, and provoked a lot of engaging discussion about Meros. In order to discuss Meros’s future, and the first ever MIP, we’re having another on February 29th, at 2pm Central.
We’re happy to provide this update and insight into Meros. The future is coming quickly, and we can’t wait to be there. We’ll make sure to update you with our progress soon.
