v2 Documentation

[julienrbrt]

Once #21429 is completed, we should focus on the documentation and upgrading documentation for docs.cosmos.network/v2 for Cosmos SDK (server) v2.

The removal of baseapp and change of all core concepts will require quite an overhaul.

Documentation

Core Concepts

• STF
  • Branching
• Server Components
• Runtime/v2
• Store/v2
• IAVL v2

App

• Use runtime/v2 and simapp/v2

CometBFT server

• CometBFT server
• ABCI
• Optimistic Execution

Modules

Module documentation changes are limited compared to #21429 thanks to core v1:

• Core Appmodule/v2
• TxValidators
• Handlers (Optional, gRPC services are still supported)
  • If you use handler, no gRPC service will be available for that module
• No need to generate grpc gateway code, thanks to grpc Server (Remove RegisterGRPCGatewayRoutes)

Testing

• core/testing (unit tests)
• integration tests framework v2
• sims v2
• systemtests

Upgrading Guide

• Create a UPGRADING_V2.md

Modules

• sdk.Context to core service migration: https://hackmd.io/@julienrbrt/S16-_Vq50
• AnteHandler to TxValidator
• Optional migration from grpc services to handlers
• [Documentation]: Module configuration #22371

Server

• Telemetry server is another port (1328)
• New REST server for querying modules (8080) -> Use post and type_url (docs at server/v2/api/rest/README.md)
• gRPC: new service to query the modules gRPC messages, without going via module services
• gRPC: external gRPC services no more registered in the application router (e.g. nodeservice, cmtservice, authtx service)

App

• Use runtime/v2 and simapp/v2 (no brainer)

[SpicyLemon]

The x/accounts blurb takes me way too long to figure out what it's trying to say. I've read it probably 20 times now and am still a bit fuzzy.

Accounts's AccountNumber will be used as a global account number tracking replacing Auth legacy AccountNumber. Must set accounts's AccountNumber with auth's AccountNumber value in upgrade handler. This is done through auth keeper MigrateAccountNumber function.

---

I'd also like to see something under x/crisis about what we should do with our current invariants.

---

It'd be nice to have something at the top of the x/protocolpool section that states that it's required to add it if using the x/distribution module. I know that it says that in the x/distribution section, but it'd be good to have it in both places.

[julienrbrt]

Great feedback, thanks, we'll amend!

[robert-zaremba]

@SpicyLemon I think invariants are deprecated and dropped in v0.52

[SpicyLemon]

@SpicyLemon I think invariants are deprecated and dropped in v0.52

Right. But what are we expected to do with current invariants that we have? Is something replacing them or are we just supposed to do without these safety checks? A good deprecation message indicates what to change to even if that message is something along the lines of "There is no replacement for this functionality."

[robert-zaremba]

Ideally, invariant should be assured on a tx level. But if you need more - then how about adding it to EndBlock?