mirror of
https://github.com/serai-dex/serai.git
synced 2025-12-08 12:19:24 +00:00
Update processor README
This commit is contained in:
@@ -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
|
|
||||||
|
|||||||
Reference in New Issue
Block a user