Choosing the genesis software target (and future milestones)

[moul]

Let's start our chat about what software we should use first for our project.

We've got two main ideas:

1. Starting with Tendermint 2 (tm2): This means we'll need to build some missing parts. We've got two ways to do this:

   1. We could start tm2 with what it's got now.
   2. Or, we could make some early changes, like adding a new governance module.

2. Starting with a Cosmos Hub 4 fork: We're thinking about this release: Cosmos Gaia v13.0.1. This could be done fast. Then we would add the changes we want, bit by bit. In the end, we can think about moving to tm2 when it makes sense.

Once we've decided how to start, we can plan out the details for this launch, and also the rest of our roadmap and big milestones. Then, we can start the first milestone, making a list of things we need to do in a big issue or a GitHub milestone. This way, we can keep all the tasks together as issues, but also use issues for long chats or things we need after milestone 1.

Remember: I'll keep this top issue updated with big decisions, as well as replying with comments.

[moul]

I prefer option 2 because it allows for an early start and addresses the weakening of the current hub (which is not yet deprecated) over time, like with props such as 848.

However, option 2 does have the drawback of a more difficult migration process. I planned to handle this myself in the context of Gno/TM2, so that we can assist people in migrating to Tendermint2 later, not just for new blockchains starting from day one on tm2.

Please note that even though option 2 offers many shortcuts, I still believe that we should not launch (genesis) until we finish the constitution and the plan, as they are bundled with the software in my opinion.

If we choose option 1, there will be less migration but more work to be done. It optimizes for avoiding redundant coding but will require more time to be ready.

[giunatale]

However, option 2 does have the drawback of a more difficult migration process. I planned to handle this myself in the context of Gno/TM2, so that we can assist people in migrating to Tendermint2 later, not just for new blockchains starting from day one on tm2.

Why? I think the opposite. You are already envisioning a "migration" to tm2 but this is not necessarily going to happen. The frictionless approach here is option 2. And I am advocating for option 2 too. Software-wise it should initially be just a fork the current Hub software, and we move from there. Any major change like adopting tm2 should be a governance decision.

let's not jump the gun here.

[jaekwon]

I agree we should start with option 2.

We (AtomOne, AIB, NT, everyone) can collectively maintain both Tendermint1+AtomOne and Tendermint2 whether or not AtomOne migrates to Tendermint2. This is also what is in the README.

[moul]

Should we consider forking Gaia within the organization? This would enable us/anyone to open PRs.

Alternatively, we can choose not to fork Gaia now and instead focus on finalizing all the definitions here.

[Ticojohnny]

I prefer Option 2 and one benefit to note that is that migrating Atom One to Tendermint2 will be a great demonstration of how it will work for curious and interested onlookers.

[albttx]

Do we want to rollback to tendermint/tendermint v34 or do we keep as current gaia version by using cometbft ?

[moul]

Can you provide GitHub URLs or any other means to view the specific set of differences we are discussing?

[albttx]

• https://github.com/cometbft/cometbft
• https://github.com/tendermint/tendermint

cosmos-sdk now use cometbft, i don't know if it's "possible" to rollback current cosmos-sdk with tendermint due to new ABCI interface.