Ecosystem/serai
Ecosystem/serai
1
0
Fork 0
mirror of https://github.com/serai-dex/serai.git synced 2024-10-30 00:47:43 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 1
serai/processor
History
Luke Parker bc19975a8a
Update Bitcoin confirmations from 3 to 6 
While Bitcoin practically doesn't have long re-orgs, it is possible for a
single miner to build a long chain. Recently, a miner found 5 blocks in a row,
which would be enough to re-org a transaction Serai considered finalized.
2023-04-10 02:51:44 -04:00
..
messages Update processor message flow around the new SignedBatch flow 2023-04-10 02:51:36 -04:00
src Update Bitcoin confirmations from 3 to 6 2023-04-10 02:51:44 -04:00
Cargo.toml Update processor message flow around the new SignedBatch flow 2023-04-10 02:51:36 -04:00
LICENSE Update licenses 2023-01-11 23:05:31 -05:00
README.md Processor (#259) 2023-03-16 22:59:40 -04:00

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

The processor is expected to scan all sufficiently confirmed blocks from a given coin. This will create a list of outputs, considered pending.

Reporting

These outputs are to be placed in a Batch, identified by the block containing them. Batches are provided in an Update to Serai, paired by an agreed upon block number.

The processor will also produce an Update if there have been no batches within the confirmation window.

Confirmed Outputs

Once outputs have been acknowledged by Serai, they are considered confirmed. 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 will do one of two things:

  1. Use the output
  2. 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

  • Acknowledging a sign ID as signed so we don't continue trying

monero-serai now supports Eventualitys. When we have a plan to attempt, we can create an Eventuality and see if it matches a given TX. A signing node just has to submit the TX hash.

Bitcoin will have the same TX hash flow, just explicitly matching against the inputs.

  • Coordinator communication

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