Meros Development Update, August 2021
Welcome to the August 2021 Meros Development Update. This update covers news from both the July and August State of the Project videos, and the full stories can be found here for July, and here for August.
Issues with the July State of the Project
In July, we experienced some issues with the quality of the State of the Project video published to YouTube and shared with the Meros community. We weren’t satisfied with the end result and so we released a revised video later that month. We’d like to apologise for any inconveniences the initial release and the following wait for the revision caused. Following July’s video, we’re handling the State of the Project videos more carefully with a different editor.
July
A new Github branch dedicated to the new epochs implementation was created to improve the way in which Meros finalizes transactions. While the epochs system is designed to do that, the previous version had two inefficiencies. The first was a risk of using hash power to ‘ram through’ a competing transaction which double spent funds. When the new system tracks a competitor, it extends the lifetime of both transactions, whereas previously the new one assumed the old’s, about to expire, lifetime. The second improvement is an internal change to how transactions were tracked and catalogued inside the system, allowing for more powerful manipulations.
The power of hindsight and revision
Kayaba discussed instances in which revisions are worth the time investment to implement, instead of the cost of continuing with what exists. Using epochs as an example, Kayaba cited security issues not revising would create as a reason to address the problem before launch. He also mentioned the difficulty revisions can create when you have a live chain. That plays a major factor in his decision making regarding revisions, as anything which would be incredibly difficult to change later yet easy now is corrected.
Meros currently uses EdDSA signatures for transactions, yet will move to Schnorr signatures. This serves as an example of something easy to do now, yet frustrating to do later, making it worth the time investment. There are two reasons why it’s worth moving, the first being Schnorr is a more efficient signature algorithm, and the second being the ability to recover the signer of a message from just the message and signature. While there are no plans to utilize this latter feature in Meros at this time, it does open up interesting possibilities in the future.
Also discussed was Meros’s use of BLS signatures for voting. While Schnorr signatures would be much faster, they don’t offer the same aggregation properties as BLS signatures. With BLS signatures, all votes’ signatures can be combined into a single signature by miners, reducing the amount of disk space required to store them. Schnorr signatures could be used for this purpose, yet at the cost of network bandwidth and complexity. While it may be worth it for Meros to move to in the future, it’s not worth the time cost for its limited trade-offs at this time.
Magic inputs are special cases where an input specifies a hash which doesn’t exist. Furthermore, anything spending it isn’t seen as competing with something else which spends it. These exist for Data transactions to mark the first Data transaction by a specific person, or to mark a Data transaction created by Meros itself.
August
Kayaba covered the potential of what he calls an ‘impossible transaction’, a double-spend case where a transaction competes with its own parent, causing an infinite dependency loop. This kind of transaction can never be verified as it must have its parents finalize first, which will spend the funds which cause them to compete, making it a losing competitor. These have been handled for a long time yet came up again thanks to the epochs redo.
Simplify getPending transactions
An optimization was made to a function that is called at boot-up and upon reorganization. Where previously it accessed all inputs in epochs, which was cached, in order to create a list of pending transactions, now the pending transactions are cached and that’s simply accessed. This function is rarely called, yet does greatly improve performance when it is called, not to mention it simplifies the codebase by not having extraneous code.
Kayaba talked briefly about some long-standing Github issues that are not, as of yet, resolved. These issues, as he explained, are not immediately problematic, hence why they’ve stood for so long, but will need to be addressed before Meros goes live. He went into some detail about two of these older issues he’s also discussed on previous episodes.
Kayaba announced that the tests passed once again after performing the epochs redo. While he has yet to write comprehensive tests specifically for the redo, this is a massive step forward to ensuring proper and functioning code and shows the redo should be done shortly.
Kayaba estimates another 2 months of work remain before the final testnet can take place. The only major protocol-level work remaining is merging the epochs redo and checkpoints. Beyond that, only small fixes (such as those mentioned in the Persisting issues section) and minor bug fixes remain. Kayaba did also clarify that he has a move coming up, which will take away from his time coding, but to what degree he can’t be certain.
That completes our summary of the latest State of the Projects. 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!
