🚀 Road to V1

[Farhad-Shabani]

ibc-rs V1 Roadmap

Motivation

We are thrilled to share the status and plans for the upcoming release of ibc-rs v1.0.0. Our goal is to enable new use cases and business models across the blockchain industry and bring the power of IBC protocol to a wider range of blockchains, developers, operators, and relayers, ultimately paving the way for a truly interconnected blockchain ecosystem.
This tracking issue serves as a beacon of our progress and gives a road toward the future of ibc-rs. View this roadmap as a broad overview rather than a promise of specific outcomes and timelines. As we continue to work towards the release of V1, we try our best to keep this roadmap updated and reflect our status.

Acceptance Criteria

The following are three main objectives we aim to achieve with the implementation. The current issues associated with achieving these goals are outlined in the "Objectives Breakdown" section.

1. Improve Compatibility: with reference to specs and IBC-go enabled chains

We aim to optimize our compatibility with the IBC protocol outlined in the official IBC documentation. To achieve this, we strive to align our data structures, abstractions, and semantics with the protocol set forth by the IBC core, client, and relayer standards and prioritize to support the fungible token transfer (ICS20). We do our best to clearly communicate any deviations from specifications and provide developers with guidance on how to handle them.
In addition to the above, we are committed to achieving compatibility with ibc-go enabled chains, which will expand our system's interoperability and enhance its potential for adoption.

2. Scalable Design: empowering non-cosmos chains

Our goal is to make architectural and design decisions that incorporate implementation with a clear separation of concerns and generic enough modular building blocks. Each with exclusive responsibility and well-defined required and provided APIs that ensure independent maintainability and support the IBC adoption of non-cosmos chains. Thus, this objective is tracked under the following criteria:

• 2.1. Ensure APIs are delightful and flexible enough for end-users
• 2.2. Assist non-cosmos chains in adopting IBC and applying feedback

3. Solidify Implementation: by quality assurance measures

This objective will take a number of steps to ensure our designs and implementation function within consistent and reliable behaviors while minimizing backward-incompatible and breaking changes. By taking the following measures, we aim to provide a more robust and user-centric product:

• 3.1. Clean-ups, public exposure refinement and encapsulation
• 3.2. Add necessary unit, integration, and e2e compatibility tests and maintain basecoin-rs up-to-date with ibc-rs changes as our primary testing venue
• 3.3. Fix existing and community-reporting security and functionality findings
• 3.4. Ensure adequate contents/docs around how to use, integrate and upgrade ibc-rs

Objectives Breakdown

Here, you can check out the list of current and usually more significant issues for each objective!
Note that this list may be subject to periodic updates, meaning it may grow or shrink over time.

1.1. Improve Compatibility [app support]

Beta Give feedback

1. Add "extra data" field to TokenTransfer*Context::escrow_coins_*() methods #839
   A: breaking +1
2. Transfer contexts: split send_coins_*() methods #837
   A: breaking +1
   

1.2. Improve Compatibility [compliance with ibc-go]

Beta Give feedback

1. [ICS02] Implement IBC client recovery mechanisms #738
   4 of 4
   A: critical O: reliability +2
   
2. [ICS02] Modify MsgUpdateClient handler to also handle misbehaviour due to ibc-proto-rs v0.34.0 updates #835
   A: critical +1
   
3. Tendermint light client: add consensus state pruning on client update #600
   A: critical O: new-feature +2
   
4. Implement (parts of) ibc-go/ADR006 #173
   A: tracking +1
5. [ICS02] Split check_misbehaviour_and_update_state and check_header_and_update_state into two sets of validation/execution functions #535
   5 of 5
   A: breaking O: decoupling O: logic O: maintainability +4
   
6. Provide a "upgrade client proposal" handler for Tendermint chains #420
   O: exploratory +1
   
7. Handler for upgrade client #141
   +0
   
8. Make token transfer events fully compatible with latest ibc-go #495
   +0
   

1.3. Improve Compatibility [compliance with specs]

Beta Give feedback

1. [Router] Missing parts of ICS05 & ICS26 that deal with the Module management #519
   A: breaking O: usability S: specs +3
   
2. ICS-20: add memo field #559
   S: specs +1
   

2.1 Scalable Design [delightful APIs]

Beta Give feedback

1. Make core Error enums less specific #270
   3 of 3
   O: maintainability S: errors +2
   
2. Refactor ValidationContext and ExecutionContext #325
   A: breaking +1
   
3. feat: replace store_update_{time,height} by metadata update #973
   A: breaking O: optimization +2
4. Follow-up: ICS 26 routing module #21
   +0
5. Separate Module in ModuleValidation and ModuleExecution #465
   A: breaking O: exploratory +2
   
6. [Module] Differentiate module-specific contexts #520
   A: breaking A: critical O: decoupling O: logic +4
   
7. Improve logging facility for contexts #718
   A: breaking O: usability +2
   
8. Enable light clients to specify the methods they need the host to implement #296
   A: breaking O: exploratory O: logic +3
   
9. [Context] Separate validate() and execute() handlers for better modularity and API coherence #539
   A: breaking O: decoupling +2
   
10. ClientState: consider replacing confirm_frozen and expired methods with a "status" instead #536
    O: exploratory O: logic O: usability +3
    
11. Investigate exposing an API which implements IBC gRPC queries #686
    O: exploratory +1
    

2.2. Scalable Design [non-Cosmos support]

Beta Give feedback

1. Continue assisting users in adopting ibc-rs (Q4 2023) #882
   18 of 18
   A: tracking +1
2. Assist users in adopting IBC-rs (Q3 2023) #807
   8 of 8
   A: tracking +1
3. Assist non-cosmos chains in adopting IBC (Q2 2023) #608
   5 of 5
   A: tracking +1
4. Enable Nomic and Namada to get to mainnet #431
   16 of 16
   A: tracking +1
5. Restructure the ibc crate #965
   7 of 7
   O: code-hygiene O: decoupling O: maintainability O: usability +4
6. Move transfer application and tendermint client to separate crates #716
   O: decoupling O: maintainability O: usability +3
   

3.1. Solidify Impl [clean-ups]

Beta Give feedback

1. [Crate] Take consistent approach for handling public structs/fields #532
   O: maintainability +1
2. [Core] Check out and remove default impls that depend on a certain client or application #373
   A: low-priority O: maintainability +2
3. [ICS02] Examine removing dyn ValidationContext type from check_header_and_update_state() and check_misbehaviour_and_update_state() #534
   A: breaking O: decoupling O: logic +3

3.2. Solidify Impl [unit and integration tests]

Beta Give feedback

1. Revamp mock testing artifacts in the ibc-testkit #677
   O: testing +1
   
2. Define testing strategy #433
   O: exploratory O: testing +2
   
3. Separate mock module into a standalone crate #953
   O: decoupling O: maintainability O: usability +3
   
4. Determine the best way to run e2e tests against various chain binaries #744
   O: testing +1
   
5. Refactor unit tests #429
   O: maintainability O: testing +2
6. Missing unit tests for ibc-rs module verification #24
   O: testing +1
7. Audit and test implementation of ICS-23 #533
   O: security O: testing +2
8. [ICS03] Cover successful / failure scenarios of verify_conn_delay_passed with tests #505
   O: testing +1
   
9. Test NO-OP paths for packet acks, RecvPacket and timeouts #427
   O: testing +1
   
10. Add needed unit or integration tests for Tendermint proof verifications #398
    O: testing +1
    
11. implement missing timeout packet test #443
    A: good-first-issue O: testing +2
12. [ICS02] Cover client frozen/expired conditions with unit tests #538
    O: testing +1
    
13. Validate "upgrade_client" implementation by adding unit and integration tests #385
    O: testing +1
    

3.3. Solidify Impl [potential findings]

Beta Give feedback

1. chan_open_{init, try} should not return a ChannelEnd #190
   O: maintainability +1
2. Disallow creation of frozen clients #178
   A: bug +1
   
3. Missing message validation checks #233
   3 of 3
   A: breaking A: bug +2
   
4. Add check for redundant relays and treat them as noops (although an event must be emitted) in AcknowledgePacket and timeoutOnClose #213
   A: bug +1

3.4. Solidify Impl [docs]

Beta Give feedback

1. Develop the first iteration of IBC-rs website #743
   2 of 8
   A: tracking O: usability S: docs +3
   
2. Revisit documentation and README to include missing materials
3. Enhance project Wiki with more info and testing details
4. Support the community by adding the FAQ section
5. Clarify ibc-rs's semantic versioning policy #1240
   +0
   

Features to support after the V1 release

• ICS721 - Support NFT transfer
• ICS027 - Interchain Accounts
• ICS029 - Fee payment
• ICS031 - Cross-chain queries
• Connection Upgradability
• Channel Upgradilbilty

TBD with further Investigation

• Exposing an async API

Milestone

v1.0.0