Move in instructions from inherent transactions to unsigned transactions

The original intent was to use inherent transactions to prevent needing to vote
on-chain, which would spam the chain with worthless votes. Inherent
transactions, and our Tendermint library, would use the BFT's processs voting
to also vote on all included transactions. This perfectly collapses integrity
voting creating *no additional on-chain costs*.

Unfortunately, this led to issues such as #6, along with questions of validator
scalability when all validators are expencted to participate in consensus (in
order to vote on if the included instructions are valid). This has been
summarized in #241.

With this change, we can remove Tendermint from Substrate. This greatly
decreases our complexity. While I'm unhappy with the amount of time spent on
it, just to reach this conclusion, thankfully tendermint-machine itself is
still usable for #163. This also has reached a tipping point recently as the
polkadot-v0.9.40 branch of substrate changed how syncing works, requiring
further changes to sc-tendermint. These have no value if we're just going to
get rid of it later, due to fundamental design issues, yet I would like to
keep Substrate updated.

This should be followed by moving back to GRANDPA, enabling closing most open
Tendermint issues.

Please note the current in-instructions-pallet does not actually verify the
included signature yet. It's marked TODO, despite this bing critical.
This commit is contained in:
Luke Parker
2023-03-26 02:58:04 -04:00
parent 9157f8d0a0
commit c182b804bc
26 changed files with 305 additions and 481 deletions

View File

@@ -1,32 +0,0 @@
# Consensus
### Inherent Transactions
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.
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.
### Consensus
Serai uses Tendermint to obtain consensus on its blockchain. Tendermint details
both block production and finalization, finalizing each block as it's produced.
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.

View File

@@ -0,0 +1,8 @@
# In Instructions
In Instructions are included onto the Serai blockchain via unsigned
transactions. In order to ensure the integrity of the included instructions, the
validator set responsible for the network in question produces a threshold
signature of their authenticity.
This lets all other validators verify the instructions with an O(1) operation.