Update processor README

This commit is contained in:
Luke Parker
2023-04-11 05:53:19 -04:00
parent 90f2b03595
commit 7538c10159

View File

@@ -14,23 +14,23 @@ Once the key is voted in, it'll become active.
### Scanning ### Scanning
The processor is expected to scan all sufficiently confirmed blocks from a given Sufficiently confirmed block become finalized in the eyes of the procesor.
coin. This will create a list of outputs, considered pending. Finalized blocks are scanned and have their outputs emitted, though not acted
on.
### Reporting ### Reporting
These outputs are to be placed in a `Batch`, identified by the block containing The processor reports finalized blocks to the coordinator. Once the group
them. Batches are provided in an `Update` to Serai, paired by an agreed upon acknowledges the block as finalized, they begin a threshold signing protocol
block number. to sign the block's outputs as a `Batch`.
The processor will also produce an `Update` if there have been no batches within Once the `Batch` is signed, the processor emits an `Update` with the signed
the confirmation window. batch. Serai includes it, definitively ordering its outputs within the context
of Serai.
### Confirmed Outputs ### Confirmed Outputs
Once outputs have been acknowledged by Serai, they are considered confirmed. With the outputs' ordering, validators are able to act on them.
With their confirmation, the validators are ready to create actions based on
them.
Actions are triggered by passing the outputs to the scheduler. The scheduler Actions are triggered by passing the outputs to the scheduler. The scheduler
will do one of two things: will do one of two things:
@@ -45,21 +45,12 @@ accordingly. This is done by scheduling the payments out.
# TODO # TODO
- Acknowledging a sign ID as signed so we don't continue trying - Items marked TODO
- Items marked TODO2, yet those only need to be done after protonet
monero-serai now supports `Eventuality`s. When we have a plan to attempt, - Test the implementors of Coin against the trait API
we can create an `Eventuality` and see if it matches a given TX. A signing node - Test the databases
just has to submit the TX hash. - Test eventuality handling
Bitcoin will have the same TX hash flow, just explicitly matching against the
inputs.
- Coordinator communication - Coordinator communication
Kafka? RPC ping to them, which we don't count as 'sent' until we get a pong? Kafka? RPC ping to them, which we don't count as 'sent' until we get a pong?
- Handle reboots
- Items marked TODO
- Items marked TODO2, yet those only need to be done after protonet