Welcome to the June 2021 Meros Development Update. We aim to have these updates released in the middle of the month, yet sometimes run a bit late. As always, this is a written summary of the State of the Project podcast, and the full story can be found here.
As of May 20th 2021, Kayaba has been working on Meros for 3 years! The day actually marks the initial code commit for Meros on GitHub. Through all he’s achieved so far, when asked, it was ASMR that Kayaba feels most proud of coding to date, noting its strong cryptography, being the first of its kind, and implementing a new protocol as standout strengths. Kayaba also takes pride in the Rust code itself, as it’s an incredibly powerful and safe language.
Pull request #314 on Github introduced a significant amount of code specifically to ensure macOS is supported by Meros for launch. Windows will also be supported by then, yet Kayaba goes a step further and strongly disagrees with the idea of “Linux only” development. Any supported operating system should be able to compile its own release, and properly test it. Having devices on hand is a key part of ensuring this.
Kayaba ran into hurdles using an M1 Mac, such as choosenim not supporting M1 Macs. He also had to chase up an M1 fix for RandomX, used as Meros’s Proof of Work algorithm, which had existed for months despite having a solution provided. After solving some other lesser issues, Kayaba was able to contribute the macOS support he aimed to give Meros.
Meros previously used Ed25519, something also utilized by both Monero and Nano, for its digital signature scheme. Ed25519 has a side effect where every single point (such as a public key, which is the basis of addresses) has 8 distinct representations, which in the past has proven problematic for Monero, enabling a double spend. While this wouldn’t be possible with Meros due to the vastly different ways Ed25519 is used, the lack of guarantees around encoding and validity is still a concern. Ristretto resolves this by building upon Ed25519, keeping its performance and benefits, yet producing singular and definite forms for every point.
Kayaba wrote a Ristretto implementation in Python, which deepened his knowledge and understanding of it. It also enables independent testing of the Meros node’s usage of Ristretto, which is performed via a library known as dalek. By having two different versions available, it is possible to ensure there are no deviations from expectations.
As Meros now uses dalek for Ristretto, a library written in Rust, Rust is needed to compile the Meros node. This increases the amount of effort to set up Meros, as C, Nim, Python, and NodeJS were already used, each with their own role in the ecosystem. While it is unfortunate to grow this list of languages yet again, dalek is the top Ristretto library, and using Rust also enables upgrading the GUI to also use Rust for its backend. It also has no negative effects on the released binaries, which is what most people will actually use, solely increasing the quality and functionality of Meros.
Issues have been opened for functionality such as “Platform Support”, which covers supporting a variety of systems when Meros releases, including macOS, as covered above. Windows support is also pending, yet will be available before launch, as well as before the final testnet. The GUI also currently handles the same action multiple times, creating multiple copies of transactions which isn’t secure nor proper. This is due to its current minimal status as a proof of concept of creating a GUI, rather than being the fleshed out GUI planned to be integrated. A fix is available and should be merged soon.
Partial Merit Removals are a type of Merit Removals, the penalty actions of the Meros consensus system. They contain two conflicting Verifications, showing a Merit Holder trying to double spend funds, and trigger the removal of all of their Merit. A Partial Merit Removal does not only remove some Merit, yet rather only includes a single reason, as the other reason has already been included on the Meros blockchain. Because of this, it is effectively just the single reason, which could be broadcasted on its own, without a wrapper of being a Merit Removal. This is a protocol optimization best done now before the protocol is set in stone by the live network running it.
As of the current protocol, malicious Merit Holders have the ability to become Merit Holders once again. Their public keys are assigned nicknames, starting at 0. When a nickname is flagged, it loses all of its Merit. If it mines another block, it can still gain 1 Merit. This creates a very complex internal accounting state, and the code complexity makes it not worth it. Once a Merit Holder is marked as malicious, they should forever be banned from the system. It’s simple and effective. If a Merit Holder wants to pick up the responsibility again, they just have to generate a new public key anyways.
That completes our summary of the latest State of the Project. If you wish to hear this news as soon as possible, please subscribe to Smart Reach, the host of these podcasts, or join the Meros Discord. We look forward to seeing you there! Finally, if you are interested in contributing, we are actively looking for a Python developer. Please join the aforementioned Discord and message Kayaba for more information.