You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be helpful to be able to instantiate a sort of flexible sharding utilising heterogenous Paxos, where a validator set controlled by a single logical proof-of-stake system and staking token can be split across "shards" - independent consensus instances which execute in parallel, but where the validator subsets can be guaranteed to have certain amounts of overlap by the assignment logic of the logically centralised proof-of-stake module.
Ideally we would be able to craft an automatic scheduling algorithm so that transactions can use a unified programming model ("as-if-atomic") and the scheduling mechanism can produce an actual execution which is serialisable per a particular ordering but splits actual execution amongst shards efficiently (as efficiently as possible). This intersects nontrivially with Ferveo, as we want to commit to an ordering before knowing transaction contents (making scheduling considerably more difficult), but it should still be possible to run the scheduling algorithm after we know the order and transactions are decrypted - this just fixes a particular order (of serialisability) which actual execution must be semantically equivalent to.
It would be helpful to be able to instantiate a sort of flexible sharding utilising heterogenous Paxos, where a validator set controlled by a single logical proof-of-stake system and staking token can be split across "shards" - independent consensus instances which execute in parallel, but where the validator subsets can be guaranteed to have certain amounts of overlap by the assignment logic of the logically centralised proof-of-stake module.
Ideally we would be able to craft an automatic scheduling algorithm so that transactions can use a unified programming model ("as-if-atomic") and the scheduling mechanism can produce an actual execution which is serialisable per a particular ordering but splits actual execution amongst shards efficiently (as efficiently as possible). This intersects nontrivially with Ferveo, as we want to commit to an ordering before knowing transaction contents (making scheduling considerably more difficult), but it should still be possible to run the scheduling algorithm after we know the order and transactions are decrypted - this just fixes a particular order (of serialisability) which actual execution must be semantically equivalent to.
Prior research:
The text was updated successfully, but these errors were encountered: