Junha Yang(양준하)

It is not used

It is desirable to propagate tx based on the order sorted by TxSorter

We have no proper rule for transactions that are tested to be valid by TxSorter, but not accepted by the actual owner module. They will just reside in the mempool...

Foundry host eventually has to use the 0th validator given by `UpdateConsensus`, as the proposer. This will remove old CodeChain proposer selection logic https://github.com/CodeChain-io/foundry/pull/602#pullrequestreview-556853470. And also, to express complicated staking...

It sometimes fails with ``` thread 'track_blocks' panicked at 'called `Result::unwrap()` on an `Err` value: Connect(Io(Os { code: 111, kind: ConnectionRefused, message: "Connection refused" }))', /home/junha/Projects/foundry/integration-test/src/lib.rs:147:47 ```

## Types Eventually, we will have only 3 types for validators. 1. `ctypes::Validator` - It has two fields: `public_key` and `weight`. 2. `ctypes::ValidatorSet` - It is a newtype of `Vec`,...

It is too fragile with RTO/process-sandbox related tests.

- [x] Setup engine-level handler - [x] Implement two essential fields (`GetBlock` and `SendTransaction`) - [ ] Move others

Obviously it is not related to the consensus or business logic anymore, but worth it being same for the network. We have to decide detail policy for snapshot.