89eef95fb3
* add mlsag * fix last commit * fix miner v1 txs * fix non-miner v1 txs * add borromean + fix mlsag * add block hash calculations * fix for the jokester that added unreduced scalars to the borromean signature of 2368d846e671bf79a1f84c6d3af9f0bfe296f043f50cf17ae5e485384a53707b * Add Borromean range proof verifying functionality * Add MLSAG verifying functionality * fmt & clippy :) * update MLSAG, ss2_elements will always be 2 * Add MgSig proving * Tidy block.rs * Tidy Borromean, fix bugs in last commit, replace todo! with unreachable! * Mark legacy EcdhInfo amount decryption as experimental * Correct comments * Write a new impl of the merkle algorithm This one tries to be understandable. * Only pull in things only needed for experimental when experimental * Stop caching the Monero block hash now in processor that we have Block::hash * Corrections for recent processor commit * Use a clearer algorithm for the merkle Should also be more efficient due to not shifting as often. * Tidy Mlsag * Remove verify_rct_* from Mlsag Both methods were ports from Monero, overtly specific without clear documentation. They need to be added back in, with documentation, or included in a node which provides the necessary further context for them to be naturally understandable. * Move mlsag/mod.rs to mlsag.rs This should only be a folder if it has multiple files. * Replace EcdhInfo terminology The ECDH encrypted the amount, yet this struct contained the encrypted amount, not some ECDH. Also corrects the types on the original EcdhInfo struct. * Correct handling of commitment masks when scanning * Route read_array through read_raw_vec * Misc lint * Make a proper RctType enum No longer caches RctType in the RctSignatures as well. * Replace Vec<Bulletproofs> with Bulletproofs Monero uses aggregated range proofs, so there's only ever one Bulletproof. This is enforced with a consensus rule as well, making this safe. As for why Monero uses a vec, it's probably due to the lack of variadic typing used. Its effectively an Option for them, yet we don't need an Option since we do have variadic typing (enums). * Add necessary checks to Eventuality re: supported protocols * Fix for block 202612 and fix merkel root calculations * MLSAG (de)serialisation fix ss_2_elements will not always be 2 as rct type 1 transactions are not enforced to have one input * Revert "MLSAG (de)serialisation fix" This reverts commit |
||
|---|---|---|
| .. | ||
| messages | ||
| src | ||
| Cargo.toml | ||
| LICENSE | ||
| README.md | ||
Processor
The Serai processor scans a specified chain, communicating with the coordinator.
Key Generation
The coordinator will tell the processor if it's been included in managing a coin. If so, the processor is to begin the key generation protocol, relying on the coordinator to provided authenticated communication with the remote parties.
When the key generation protocol successfully completes, the processor is expected to inform the coordinator so it may vote on it on the Substrate chain. Once the key is voted in, it'll become active.
Scanning
Sufficiently confirmed block become finalized in the eyes of the procesor. Finalized blocks are scanned and have their outputs emitted, though not acted on.
Reporting
The processor reports finalized blocks to the coordinator. Once the group
acknowledges the block as finalized, they begin a threshold signing protocol
to sign the block's outputs as a Batch.
Once the Batch is signed, the processor emits an Update with the signed
batch. Serai includes it, definitively ordering its outputs within the context
of Serai.
Confirmed Outputs
With the outputs' ordering, validators are able to act on them.
Actions are triggered by passing the outputs to the scheduler. The scheduler will do one of two things:
- Use the output
- Accumulate it for later usage
Burn Events
When the Serai chain issues a Burn event, the processor should send coins
accordingly. This is done by scheduling the payments out.
TODO
-
Items marked TODO
-
Items marked TODO2, yet those only need to be done after protonet
-
Test the implementors of Coin against the trait API
-
Test the databases
-
Test eventuality handling
-
Coordinator communication
Kafka? RPC ping to them, which we don't count as 'sent' until we get a pong?