Skip to content

Instantly share code, notes, and snippets.

@kayabaNerve

kayabaNerve/.md Secret

Last active December 18, 2024 07:25
Show Gist options
  • Save kayabaNerve/5867d08025dcd329a8d44085122686fe to your computer and use it in GitHub Desktop.
Save kayabaNerve/5867d08025dcd329a8d44085122686fe to your computer and use it in GitHub Desktop.
Serai's Status as 2024 Wraps Up

This is an update on where the Serai project is. While I wish I could keep this professional, parts of it will be fundamentally intertwined with my personal life. Apologies to anyone who just wants a short, professional brief.

Serai is currently composed of 19,533 lines of Rust code for its cryptography alone. An audit occurred in March 2023 over our base libraries and FROST implementation. Since then, we've adopted a new DKG so we can perform multisig rotations even if several validators are offline. This DKG is built on top of the same libraries I developed while working on FCMP++ for Monero, and the shared libraries will be audited under Monero's existing audit scope. Serai still has the responsibility of auditing the DKG it culminates in, which is our next step regarding audits.

Our library to produce Bitcoin transactions with FROST was audited in August 2023.

Our Monero libraries are made up of 14,424 lines of Rust code. These don't just enable signing Monero transactions with a multisignature protocol but are a complete re-implementation of the Monero transaction protocol in Rust. These libraries are used by, and have been contributed to by Cuprate (a Monero node in Rust). They're also being actively considered for usage by multiple wallets in the Monero ecosystem, and currently built upon by a hardware wallet. These libraries are undergoing auditing as we speak, after successfully raising funds from the Monero community, and that will likely resolve in March, 2025. Once audited, the plan is to transfer these libraries into the monero-oxide organization. This will ensure their neutrality as more groups adopt and start using them, while making them no longer Serai's maintenance burden.

Our Ethereum libraries are an interesting collection as a couple are general purpose but most aren't. Due to how critical and complex security is within the Ethereum ecosystem (not to mention cryptocurrency as a whole), most of our Ethereum libraries (including the associated contracts) should be audited. The contracts are ready for auditing, pending expansion of their test suite, with our Schnorr contract immediately ready for auditing. This contract of ours involves a decent degree of cryptography, arguably making it the most complex despite its small size, so it's good we can handle it first.

The Serai Processor, our service to index blockchains, abstract their data, and handle transactions is currently 16,748 lines of code. Due to its size, expansive scope, and how it's a locally run service, the plan is to focus on reviews (not audits). A reviewer is already lined up and the codebase is mostly ready for that.

The Serai Coordinator, the service each validator runs to coordinate with other validators, is 13,321 lines of code. As with the processor, the plan is to have it reviewed, not audited, though some components of it may be good candidates for proper auditing as time and budget allows. Unfortunately, it has some significant latency hitches at this time (degrading network stability) and still needs to be gone through with a comb to remove those. On a design/protocol level, this issue was created for my largest concern (the shortest latency bound in the protocol).

Our Substrate codebase, at 14,133 lines of code, is primarily composed of the runtime. The runtime determines how each transaction changes the state on the Serai blockchain (which determines the current validators, tracks sri* coins, updates pool balances, and tracks mints/burns). This is also a prime candidate for auditing yet unfortunately is specialized to groups with familiarity over the Substrate SDK. With that comes limited availability and notable cost for audits.

I prior publicly stated I hoped to be ready by end of year, before adjusting to a release candidate by end of year (as there was no way the necessary audits would resolve in a timely fashion). As I've faced personal issues and split attention, I've been unable to commit the hours to Serai necessary to have reached such a target. That is my fault, and why I was so hesistant to give any time estimates for years. While I had confidence in this estimate when I spoke it, other things came up. I apologize for that.

I have mostly stepped back from my roles within the Monero community, restoring the time I have to focus on Serai. The Serai codebase has largely been brought to where it needs to be, and we are soliciting our next two audits (formalization/proofs for the DKG and an audit of our Ethereum Schnorr contract). While I have prior expressed concern over funding our audits, I am happy and relieved to announce an anonymous donor has enabled Serai's upcoming audits. The donations themselves have been facilitated by MAGIC Grants.

With all that in mind, I look forward to making strong progress as we enter the new year to not only finalize the Serai codebase, yet audit it where proper to ensure its integrity. The next testnet will happen after the codebase finalizes, while audits are ongoing. If anyone has any questions, please reach out on Discord or Matrix. If you're interested a much more detailed overview of where Serai is at, please see this itemized list for the status of each of our ~100 crates.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment