Christopher Goes

Transaction load generation client

6

An underappreciated requirement of peer-to-peer blockchain client implementations is high resistance to DoS attacks. These are not exploits targeting the consensus ruleset, just malicious nodes spamming expensive-to-reject transactions to slow...

ICS2: Update for changes to client state verification

7

Thanks @AdityaSripal - https://github.com/cosmos/cosmos-sdk/issues/6524#issuecomment-651927537.

Metadata format for application-layer specifications

2

Includes - Packet data `.proto` - Versioning semantics - Link to spec - etc. etc. Suggestions welcome.

ICS2: Think through delay period options

2

And how to push to application, secondary queues, etc. etc.

Per discussion. - [x] Reorganise this repository, with subdirectories corresponding to the five semantic categories: 1. Core IBC: ICS 2, 3, 4 2. Light client (validity predicate) specifications: ICS 7,...

Per our discussion and Informal's [verification-driven development process](https://github.com/informalsystems/vdd/blob/master/guide/guide.md), new specifications would each contain: 1. A high-level English description covering process definitions, communication definitions, synchrony assumptions, safety and liveness properties, etc....

Ref https://github.com/cosmos/cosmos-sdk/pull/7808

ICS6: Remove timestamp check for misbehaviour

1

This is not safe because there is only one consensus state and it can be immediately updated.

ICS6: Revise data types to match SDK

1

- Remove sequence from ConsensusState - Add boolean flag for proposal updates (need to rectify because of proofs)

ICS7: Include chain ID parsing requirements

4

Per https://github.com/informalsystems/ibc-rs/pull/304#discussion_r506982998