- Incentive structure for the submission and validation of headers (consensus state updates), as opposed to user transactions
- What is intended here?
- Does it make sense to have multiple clients from one chain to another?
- May make sense to have multiple client for different threshold confirmations on Nakamoto Consensus algorithms
- Otherwise you only need to store headers once so ¯_(ツ)_/¯
- Does it make sense to have multiple connections from one chain to another?
- Can connections be rivalrous? Parties A and B keep headers updated for an IBC connection, and are able to charge transaction fees exclusively for use of that connection. Or are connections necessarily open for everyone to update headers.
- How will new validity predicates be put into the Cosmos Hub?
- Chains will different consensus algorithms will presumably need new validity predicates
- Does the addition of a new validity predicate require a governance vote?
- What is the data confidentiality ability in IBC? Taken from the specification:
- Data confidentiality is the ability of the host state machine to refuse to make particular data available to particular parties without impairing the functionality of the IBC protocol.
- What is this exactly?
- Explanation of the concepts of Provable Store and Private Stores. What’s the difference between the store?