Gossip Layer for Heterogeneous Paxos Transactions

[isheff]

Arguably, we can break down Typhon into layers, which include:

• Transaction dissemination from Clients to Storage (probably on validators, who may also be orderers) (This Issue)
• Mempool Organization, wherein organized portions of the transactions are identified for consensus to decide on.
• Consensus, which chooses an ever-growing sub-dag from the mempool representing "ordered" transactions.
• Execution, wherein state "after" each transaction is calculated and published.

This will have to incorporate / reference sub-transactions in each of the state machines involved, and efficiently disseminate transaction data to relevant parties. This gossipping should happen before consensus.

Ultimately, we want this design formalized in something like TLA+, and integrated with the Mempool Spec. We may even want to prove some safety or liveness (or even fairness) properties along the way.

[ghost]

Just to comment from the crypto side on this, currently the distributed key generator incurs O( # validators * # key shares) communications overhead, primarily because we wanted to use the existing Tendermint gossip layer unchanged (for now), the performance is probably acceptable, and it's simpler to implement.

This can be improved to O(# key shares * log(# validators)) if DKG messages are aggregated in the gossip layer, so if the gossip layer is redesigned, we should build in the DKG. This will be much more concretely efficient at 100 validators and also allow scaling to many more validators.

[isheff]

We will ultimately need some system whereby quorums of validators can verify that they've stored (perhaps erasure-coded) a transaction such that it can eventually be ordered and executed. Perhaps something like Kadcast can help here.

[FatemeShirazi]

Can break this issue down into smaller issues? Like clear todos such as

• learn about Kadcast
• spec a small scheme for tx dissemination
• ...