Status of Serai's crates w.r.t. review, audits, and finalization

[kayabaNerve]

Serai is composed of the following crates with the following statuses.

• patches/*: All of these provide updated versions of/alternatives to crates
  which should not be used directly. None of these require auditing.

• std-shims: std-shims provides no-std (alloc) alternatives to the std
  library. They're used to provide no-std support. They're sufficiently minimal
  they do not require auditing.

• zalloc: A zeroizing allocator. This is minimal and does not require
  auditing.

• patchable-async-sleep: This is a wrapper around tokio::time::sleep which
  allows patching it on the application level. This does not require auditing.

• serai-db: This is a wrapper around either RocksDB or ParityDB. The RocksDB
  configuration needs a test added to ensure we don't permanently propagate WALs
  and do in fact flush to the underlying store. It does not require auditing.

• serai-env: This is an alternative to std::env::var which is meant to
  enable fetching secrets from a solution such as Kubernetes. We need to decide
  how we plan to handle such variables (as the current env solution allows
  anyone to inspect the process log to find them). See serai-orchestration's
  entry for more context.

• simple-request: This is a simple solution for an HTTP transport which is a
  fraction of the size of more popular libraries such as request. It does not
  require auditing.

• flexible-transcript: This was audited.

• ff-group-tests: This was audited.

• dalek-ff-group: This was audited.

• minimal-ed448: This was audited.

• ciphersuite: This was audited.

• multiexp: This was audited.

• schnorr-signatures: This was audited.

• dleq: This was audited and will be removed per Move the dleq library into a distinct repository #597.

• secq256k1: This has a little-endian encoding which should be made big-endian
  (to match secp256k1), then needs to be audited. As an implementation of a
  notable curve (secp256k1's natural cycle, of value to anyone doing ZK proofs
  which works with secp256k1 points, such as anyone in the Bitcoin ecosystem),
  it can be argued a public good.

• embedwards25519: This needs to be audited. As an implementation of an
  elliptic curve whose field is Ed25519's scalar field, it allows doing proofs
  over Ed25519 (fast, efficient, a very standard/popular choice of elliptic
  curve), which themselves work with points of an elliptic curve. This also
  enables schemes which require doing elliptic curve operations on an embedded
  curve (such as MuSig-DN, DDH-premised eVRFs). It can accordingly be argued a
  public good.

• generalized-bulletproofs: This will be audited as part of Monero's FCMP++
  audits.

• generalized-bulletproofs-circuit-abstraction: This will be audited as part
  of Monero's FCMP++ audits.

• ec-divisors: This will be audited as part of Monero's FCMP++ audits.

• generalized-bulletproofs-ec-gadgets: This will be audited as part of
  Monero's FCMP++ audits.

• dkg: This was historically audited. We need to support multiplicative
  scalings, not just additive offsets, at some point (not necessarily before
  launch). We also want to smash it per dkg 2.0 #624. The eVRF DKG contained (1-round DKG without re-attempts #576)
  needs to be formalized, have security proofs written, and its
  implementation audited. The outline to be formalized can be found
  here.
  The formalization and security proofs can immediately occur. The audit of the
  implementation will also require the academia on elliptic curve divisors resolve
  (due to the implementation using those for the necessary scalar multiplication
  gadget). The divisor academia is wrapping up per efforts of the Monero project.

• modular-frost: This was audited.

• frost-schnorrkel: This wasn't audited. It's of such triviality, it probably
  doesn't need to be, but we might as well.

• bitcoin-serai: This was audited. If we add multiplicative scaling to dkg,
  we should update bitcoin-serai to use negations instead of additive offsets
  to achieve even y-coordinates (as required by Taproot).

• build-solidity-contracts: This does not have to be audited.

• ethereum-schnorr-contract: This is ready for audit and needs to be audited.

• alloy-simple-request-transport: This does not have to be audited.

• serai-ethereum-relayer: This presumably isn't in its final form and needs
  review, API documentation, and an example client which simply passes the buck
  to an existing Ethereum ERC-4337 relayer service. This does not need auditing.
  We simply need to consider it an internal service, and say to only publicly
  expose it via a reverse proxy (such as nginx).

• monero-io: This is being audited thanks to the Monero community.

• monero-generators: This is being audited thanks to the Monero community.

• monero-primitives: This is being audited thanks to the Monero community.

• monero-mlsag: This is being audited thanks to the Monero community.

• monero-clsag: This is being audited thanks to the Monero community.

• monero-borromean: This is being audited thanks to the Monero community.

• monero-bulletproofs: This is being audited thanks to the Monero community.

• monero-serai: This is being audited thanks to the Monero community. A new
  update incorporating the FCMPs++ protocol upgrade will need to be done.

• monero-io: This is being audited thanks to the Monero community.

• monero-rpc: This is being audited thanks to the Monero community.

• monero-simple-request-rpc: This is being audited thanks to the Monero
  community.

• monero-address: This is being audited thanks to the Monero community.

• monero-wallet: This is being audited thanks to the Monero community.

• monero-serai-verify-chain: This is code for testing purposes which does not
  need to be audited.

• serai-message-queue: This is an internal service of small size which does
  not need to be audited.

• serai-processor-messages: This needs to be reviewed and has a reviewer
  queued.

• serai-processor-key-gen: This needs to be reviewed and has a reviewer
  queued.

• serai-processor-view-keys: This needs to be reviewed and has a reviewer
  queued.

• serai-processor-frost-attempt-manager: This needs to be reviewed and has a
  reviewer queued. Potentially, it should be audited. It's an agnostic wrapper
  around modular-frost to enable signing a variety of messages in parallel,
  without risk of participating multiple times. As modular-frost can be argued
  a public good (implementation of an IRTF standard and the premise of
  multisignature implementations for Bitcoin, Ethereum, Monero), so can this
  library if we remove the current binding to the Serai API (trivial and worth
  doing).

• serai-processor-primitives: This needs to be reviewed and has a reviewer
  queued.

• serai-processor-scanner: This needs to be reviewed and has a reviewer
  queued.

• serai-processor-scheduler-primitives: This needs to be reviewed and has a
  reviewer queued.

• serai-processor-utxo-scheduler-primitives: This needs to be reviewed and has
  a reviewer queued.

• serai-processor-utxo-scheduler: Some code needs to be moved into
  serai-processor-utxo-scheduler-primitives to enable de-duplicating with
  serai-processor-transaction-chaining-scheduler. Then this needs to be
  reviewed, and a reviewer is queued.

• serai-processor-transaction-chaining-scheduler: Some code needs to be
  de-duplicated with serai-processor-utxo-scheduler. Then this needs to be
  reviewed, and a reviewer is queued.

• serai-processor-smart-contract-scheduler: This needs to be reviewed and has
  a reviewer queued.

• serai-processor-signers: This needs to be reviewed and has a reviewer
  queued.

• serai-processor-bin: This needs to be reviewed and has a reviewer queued.

• serai-bitcoin-processor: This needs to be reviewed.

• serai-processor-ethereum-primitives: This needs to be audited.

• serai-ethereum-test-primitives: These are test utilities which don't have to
  be audited.

• serai-processor-ethereum-deployer: This needs tests written and to be
  audited. This does lack any Serai-specific code and is reusable by any project
  which needs a way to deploy variable contracts to sufficiently static
  addresses.

• serai-processor-ethereum-router: This needs its tests completed regarding
  the edge cases and to be audited.

• serai-processor-ethereum-erc20: This needs finalization, tests written, and
  to be audited.

• serai-processor-ethereum: This needs tests written and to be audited.

• serai-monero-processor: This needs to be reviewed.

• tendermint-machine: This is a flexible implementation of the Tendermint
  consensus algorithm with no Serai-specific code. It can be argued a public
  good. It has been reviewed prior by another developer on the Serai project
  and does not necessitate auditing (though that wouldn't be a bad idea).

• tributary-chain: This is a blockchain-as-a-library with no Serai-specific
  code. It allows anyone to build an app which contains a blockchain (or even
  several). It has been tested and reviewed prior by another developer on the
  Serai project, and accordingly doesn't require auditing. We do have to delay
  when we propose provided transactions in block templates however to reduce
  missed blocks.

• serai-coordinator: The coordinator has to be updated to a task-based
  architecture, as the processor was. We also have to update how the cosigning
  protocol works (New cosign procedure #633) to ensure progress even under high-latency situations.

• serai-primitives: This ideally is audited but needs to at least be reviewed.

• serai-coins-primitives: This ideally is audited but needs to at least be
  reviewed.

• serai-coins-pallet: This ideally is audited but needs to at least be
  reviewed.

• serai-dex-primitives: This ideally is audited but needs to at least be
  reviewed.

• serai-validator-sets-primitives: This ideally is audited but needs to at
  least be reviewed.

• serai-validator-sets-pallet: This needs to be updated to the final flow seen
  in practice, notably with distribution of rewards and Proofs of Knowledge for
  the keys on the embedded curves used by validators. ideally is audited but
  needs to at least be reviewed.

• serai-genesis-liquidity-primitives: This ideally is audited but needs to at
  least be reviewed.

• serai-genesis-liquidity-pallet: This needs to be finalized and ideally is
  audited, but at least needs to be be reviewed.

• serai-emissions-primitives: This ideally is audited but needs to at least be
  reviewed.

• serai-emissions-pallet: This needs to be finalized and ideally is audited,
  but at least needs to be be reviewed.

• serai-economic-security-pallet: This needs to be finalized and ideally is
  audited, but at least needs to be be reviewed.

• serai-in-instructions-primitives: This ideally is audited but needs to at
  least be reviewed.

• serai-in-instructions-pallet: This needs to be finalized and ideally is
  audited, but at least needs to be be reviewed.

• serai-signals-primitives: This ideally is audited but needs to at least be
  reviewed.

• serai-signals-pallet: This needs to be finalized and ideally is audited, but
  at least needs to be be reviewed.

• serai-abi: We need to define our own ABI for events and the header (to avoid
  committing to the entire storage layout currently present). This ideally is
  audited but needs to at least be reviewed.

• serai-runtime: This ideally is audited but needs to at least be reviewed.

• serai-node: This needs to be updated to the latest version of polkadot-sdk.
  While doing so, we have to ensure BABE/GRANDPA slashes don't require any
  storage proofs and GRANDPA can successfully work with Ristretto
  keys/signatures. We also want to extend the API per Add Serai RPC to the Serai node #625. This ideally is
  audited but needs to at least be reviewed.

• serai-client: This needs to be reviewed. It also should have examples
  written, and JS bindings, in order to be friendly and accessible.

• serai-orchestration: The current orchestration works to some definition of
  working. It isn't optimal and I'm sure experienced sys-admins wouldn't be a
  fan. Ideally, a more competent system is built yet that isn't necessary. Some
  degree of review is necessary to ensure we don't handle secrets incorrectly.

• mini/, tests/* are proofs of synchrony and test which don't need to be
  audited.

---

All of the processor crates need further tests written. The ones requiring
audits had this explicitly written as it is a precondition for their audit, but
all so qualify. The Substrate pallets (part of the runtime) also need further
testing.

The robust eVRF PVSS and the Ethereum code are the most notable targets for
auditing, followed by the Serai runtime. I'd next posit
serai-processor-frost-attempt-manager, then tendermint-machine. Public good
arguments exist for all except some Ethereum libraries and the runtime. This is
noted as it relates to the accessibility of some funding mechanisms for audits.

We, of course, also still need documentation. This can be written during the
operation of a testnet, which can start once we have a release candidate. The
processor is effectively at its release candidate, enabling its review, but we
cannot perform a testnet without the rest being at their release candidates. The
time during which a testnet is run can also be used to extend the tests into an
exhaustive suite (from their initial point used to confirm in-general validity).