Welcome to Meros’s Update #22, covering 8/22/19 to 9/25/19! That is a five week period, due to reasons we will discuss further below. Because of our infrequent timing, these updates no longer have a time span associated. They will come out on Wednesdays, likely every 3 to 4 weeks. During the last five weeks, we’ve fixed bugs, gotten closer to the protocol, and improved the protocol; the third being the most important of the three.
The first issue we’d like to discuss regards quality assurance. One of our community members created an issue about our lack of a Python style guide. In response, within just a couple days, we added a style guide, a PyLint configuration file, and custom checker to ensure consistency in our test suite.
The second issue relates to our Transactions DAG. If a transaction was unverified, Meros didn’t properly handle adding descendant transactions. This was due to how we defined UTXOs, which were the reason we merged Merit Removals when they were still a work in progress (albeit stable). We spent most of our time working on solving this issue.
The goal was to separate the Transactions DAG from the Consensus completely. There can’t be a problem adding transactions to unverified transactions if transactions are neither verified nor unverified. Once we properly separated the two, fixing this bug and bringing a much cleaner setup, we worked on what the Merit Removals branch left unfinished. We also added a higher threshold, adding extra safety and certainty to transactions verified instantly, and corrected a protocol error leading to ambiguity about the state of a transaction.
Beyond revamping our Transactions DAG, we revamped addresses. Previously, we were Bech32 ‘inspired’. We used the Bech32 character set but not the same data to address conversion algorithm. In order to be compatible with the wide library of existing code, we corrected this to comply with BTC’s Bech32 standard.
We also cleaned our tests. Most tests shared the same basic code and some had less than 10 lines different when compared. That said, it was difficult to unify them due to the timing, specific events we sent, and specific responses we expected in return. We designed and developed a callback based solution, where after sending each Block, we hand control to the test for it do its custom actions and checks. It’s been highly efficient and been applicable to most of our tests.
Finally, I, Luke Parker (Kayaba), made a decision.
Currently, Meros has every Merit Holder create a verification and those get sent around. Once an individual notices a transaction has achieved majority weight, the transaction becomes verified. One of the greatest improvements Meros can have in the future is having Merit Holders create the verifications together, on their own network (a “subnet”), and then sending the joint verification. One transaction, one verification signature.
This cannot be done with the existing Meros protocol. It indexed every verification by Merit Holder/Nonce. Moving to a system indexed by transactions… It would require a hard fork.
I’m not against hard forks. I plan for Meros to have one every 6 to 12 months. It’s how software gets better and cryptocurrencies grow. That said, this hard fork would make the Consensus DAG do nothing from then on. The Meros community would be using it for 6 months, moving on to something better, but supporting it for life.
Not wanting to commit to that technical debt for life, I rewrote the protocol to support subnet voting. The protocol docs have been updated, the Blockchain/State have been updated, and the Transactions DAG is largely unaffected. There’s still work to do, but it should only add a few weeks to the development process. That said, the development process has been long already.
I understand why people are curious about mainnet and why people want to see this live. I want to see this live myself. With all the time I’ve put in, work done designing it, building out docs and a place for the community, working with others on its design and theory… I’d love to see mainnet. That said, I can’t launch something that isn’t ready, and Meros isn’t ready. My answer when asked will always be, “When it’s ready”. When I know it’s ready, I’ll change my answer.
It should be noted that this new protocol has a separate change I didn’t note above. Mining is now not done via Proof of Work alone, but involves the miner signing the Block as they mine it. This makes Meros pool resistant, a change desired for the decentralization and therefore security it offers.
That concludes our updates for these weeks. We’ve fixed bugs, done a lot of work on our Transactions DAG, and changed the protocol to be better than before. As we have said every time, we’re excited for Meros’s future, and we’ll make sure to update you with our progress.