mirror of
https://github.com/serai-dex/serai.git
synced 2024-12-23 12:09:37 +00:00
e010d66c5d
Due to the ordered message-queue, there's no benefit to multiple emissions as there's no risk a completion will be missed. If it has yet to be read, sending another which only be read after isn't helpful. Simplifies code a decent bit.
97 lines
3.7 KiB
Markdown
97 lines
3.7 KiB
Markdown
# Tributary
|
|
|
|
A tributary is a side-chain, created for a specific multisig instance, used
|
|
as a verifiable broadcast layer.
|
|
|
|
## Transactions
|
|
|
|
### Key Gen Commitments
|
|
|
|
`DkgCommitments` is created when a processor sends the coordinator
|
|
`key_gen::ProcessorMessage::Commitments`. When all validators participating in
|
|
a multisig publish `DkgCommitments`, the coordinator sends the processor
|
|
`key_gen::CoordinatorMessage::Commitments`.
|
|
|
|
### Key Gen Shares
|
|
|
|
`DkgShares` is created when a processor sends the coordinator
|
|
`key_gen::ProcessorMessage::Shares`. When all validators participating in
|
|
a multisig publish `DkgShares`, the coordinator sends the processor
|
|
`key_gen::CoordinatorMessage::Shares`.
|
|
|
|
### External Block
|
|
|
|
When *TODO*, a `ExternalBlock` transaction is provided. This is used to have
|
|
the group acknowledge and synchronize around the block, without the overhead of
|
|
voting in its acknowledgment.
|
|
|
|
When a `ExternalBlock` transaction is included, participants are allowed to
|
|
publish transactions to produce a threshold signature for the block's `Batch`.
|
|
|
|
### Substrate Block
|
|
|
|
`SubstrateBlock` is provided when the processor sends the coordinator
|
|
`substrate::ProcessorMessage::SubstrateBlockAck`.
|
|
|
|
When a `SubstrateBlock` transaction is included, participants are allowed to
|
|
publish transactions for the signing protocols it causes.
|
|
|
|
### Batch Preprocess
|
|
|
|
`BatchPreprocess` is created when a processor sends the coordinator
|
|
`coordinator::ProcessorMessage::BatchPreprocess` and an `ExternalBlock`
|
|
transaction allowing the batch to be signed has already been included on chain.
|
|
|
|
When `t` validators have published `BatchPreprocess` transactions, a
|
|
`coordinator::ProcessorMessage::BatchPreprocesses` is sent to the processor.
|
|
|
|
### Batch Share
|
|
|
|
`BatchShare` is created when a processor sends the coordinator
|
|
`coordinator::ProcessorMessage::BatchShare`. The relevant `ExternalBlock`
|
|
transaction having already been included on chain follows from
|
|
`coordinator::ProcessorMessage::BatchShare` being a response to a message which
|
|
also has that precondition.
|
|
|
|
When the `t` validators who first published `BatchPreprocess` transactions have
|
|
published `BatchShare` transactions, a
|
|
`coordinator::ProcessorMessage::BatchShares` with the relevant shares is sent
|
|
to the processor.
|
|
|
|
### Sign Preprocess
|
|
|
|
`SignPreprocess` is created when a processor sends the coordinator
|
|
`sign::ProcessorMessage::Preprocess` and a `SubstrateBlock` transaction
|
|
allowing the transaction to be signed has already been included on chain.
|
|
|
|
When `t` validators have published `SignPreprocess` transactions, a
|
|
`sign::ProcessorMessage::Preprocesses` is sent to the processor.
|
|
|
|
### Sign Share
|
|
|
|
`SignShare` is created when a processor sends the coordinator
|
|
`sign::ProcessorMessage::Share`. The relevant `SubstrateBlock` transaction
|
|
having already been included on chain follows from
|
|
`sign::ProcessorMessage::Share` being a response to a message which
|
|
also has that precondition.
|
|
|
|
When the `t` validators who first published `SignPreprocess` transactions have
|
|
published `SignShare` transactions, a `sign::ProcessorMessage::Shares` with the
|
|
relevant shares is sent to the processor.
|
|
|
|
### Sign Completed
|
|
|
|
`SignCompleted` is created when a processor sends the coordinator
|
|
`sign::ProcessorMessage::Completed`. As soon as 34% of validators send
|
|
`Completed`, the signing protocol is no longer further attempted.
|
|
|
|
## Re-attempts
|
|
|
|
Key generation protocols may fail if a validator is malicious. Signing
|
|
protocols, whether batch or transaction, may fail if a validator goes offline or
|
|
takes too long to respond. Accordingly, the tributary will schedule re-attempts.
|
|
These are communicated with `key_gen::CoordinatorMessage::GenerateKey`,
|
|
`coordinator::CoordinatorMessage::BatchReattempt`, and
|
|
`sign::CoordinatorMessage::Reattempt`.
|
|
|
|
TODO: Document the re-attempt scheduling logic.
|