Ecosystem/serai
Ecosystem/serai
1
0
Fork 0
mirror of https://github.com/serai-dex/serai.git synced 2025-01-23 19:15:59 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 1

Update the consensus documentation

Browse source 
It was incredibly out of date.
This commit is contained in:
Luke Parker 2022-11-02 04:07:15 -04:00
parent 40b6cb7106
commit 5cfe2d5c59
No known key found for this signature in database
GPG key ID: F9F1386DB1E119B6
2 changed files with 28 additions and 21 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
docs/Serai.md
View file

@ -1,8 +1,8 @@
# Serai
Serai is a decentralization execution layer whose validators form multisig
wallets for various connected networks, offering secure decentralized custody of
foreign assets to applications built on it.
Serai is a decentralized execution layer whose validators form multisig wallets
for various connected networks, offering secure decentralized custody of foreign
assets to applications built on it.
Serai is exemplified by Serai DEX, an automated-market-maker (AMM) decentralized
exchange, allowing swapping BTC, ETH, USDC, DAI, and XMR. It is the premier

43
docs/protocol/Consensus.md
View file

@ -1,25 +1,32 @@
# Oraclization (message)
`Oraclization` messages are published by the current block producer and communicate an external event being communicated to the native chain. This is presumably some other cryptocurrency, such as BTC, being sent to the multisig wallet, triggering a privileged call enabling relevant actions.
# Report (message)
`Report` reports a validator for malicious or invalid behavior. This may be publishing a false `Oraclization` or failing to participate as expected. These apply a penalty to the validator's assigned rewards, which is distinct from the bond which must be kept as a multiple of 1m. If the amount deducted exceeds their assigned rewards, they are scheduled for removal with an appropriately reduced bond.
# Consensus
Consensus is a modified Aura implementation with the following notes:
### Inherent Transactions
- Stateful nodes exist in two forms. Contextless and contextual.
- Context is inserted by external programs which are run under the same umbrella as the node and trusted.
- Contextless nodes do not perform verification beyond technical validity on `Oraclization` and `Report`.
- Contextual nodes do perform verification on `Oraclization` and `Report` and will reject transactions which do not represent the actual context.
- If a block is finalized under Aura, contextual checks are always stated to be passing, even if the local context conflicts with it.
Inherent transactions are a feature of Substrate enabling block producers to
include transactions without overhead. This enables forming a leader protocol
for including various forms of information on chain, such as In Instruction. By
having a single node include the data, we prevent having pointless replicas on
chain.
Since validators will not accept a block which breaks context, it will never be finalized, bypassing the contextual checks. If validators do finalize a block which seemingly breaks context, the majority of validators are saying it doesn't, signifying a locally invalid context state (perhaps simply one which is behind). By disabling contextual checks accordingly, nodes can still keep up to date with the chain and validate/participate in other contextual areas (assuming only one local contextual area is invalid).
In order to ensure the validity of the inherent transactions, the consensus
process validates them. Under Substrate, a block with inherents is checked by
all nodes, and independently accepted or rejected. Under Serai, a block with
inherents is checked by the validators, and if a BFT majority of validators
agree it's legitimate, it is, regardless of the node's perception.
By moving context based checks into consensus itself, we allow transforming the `Oraclization` and `Report` messages into a leader protocol. Instead of every validator publishing their own message and waiting for the chain's implementation to note 66% of the weight agrees on the duplicated messages, the validators agreeing on the block, which already happens under BFT consensus, ensures message accuracy.
### Consensus
Aura may be further optimizable by moving to either BLS or FROST signatures. BLS is easy to work with yet has a significance performance overhead. Considering we already have FROST, it may be ideal to use, yet it is a 2-round protocol which exponentially scales for key generation. While GRANDPA, an alternative consensus protocol, is 2-round and therefore could be seamlessly extended with FROST, it's not used here as it finalizes multiple blocks at a time. Given the contextual validity checks, it's simplest to finalize each block on their own to prevent malicious/improper chains from growing too large.
Serai uses Tendermint to obtain consensus on its blockchain. Tendermint details
both block production and finalization, finalizing each block as it's produced.
If the complexity challenge can be overcame, BABE's VRF selecting a block producer should be used to limit DoS attacks. The main issue is that BABE is traditionally partnered with GRANDPA and represents a more complex system than Aura. Further research is needed here.
Validators operate contextually. They are expected to know how to create
inherent transactions and actually do so, additionally verifying inherent
transactions proposed by other nodes. Verification comes from ensuring perfect
consistency with what the validator would've proposed themselves.
While Substrate prefers block production and finalization to be distinct, such
a model would allow unchecked inherent transactions to proliferate on Serai.
Since inherent transactions detail the flow of external funds in relation to
Serai, any operations on such blocks would be unsafe to a potentially fatal
degree. Accordingly, re-bundling the two to ensure the only data in the system
is that which has been fully checked was decided as the best move forward.