[Epic]: Server/v2

[tac0turtle]

Summary

As part of the server/runtime working group the design is leaning towards one that allows teams to compose servers with preexisting server modules or create new server modules.

In order to allow more consensus engines to be plugged into the Cosmos SDK the server needs to clean up existing interfaces like:

• cosmos-sdk/server/types/app.go

  Line 37 in 21e69ba

  Application interface {

These interfaces should be minimal and allow new items to be plugged in without needing to fork the cosmos sdk

ref #8208

Problem Definition

In order to allow users to create custom servers without forcing them to fork the server package, we must modularise the server to allow a user to compose it from existing components and new ones.

Work Breakdown

Phase 1 (Create server modules for all the components of the server)

Tasks

Preview Give feedback

1. grpc
2. grpcweb
3. grpc gateway
4. purning (could be moved to store)
5. comet (could be moved together with consensus comet) (facu)
6. Appmanager
7. Telemetry
8. swagger/Openapi

All server modules that need to be started should be treated as a service

type Service interface {
 Start() error
 Stop() error
}

Phase 2

Tasks

Preview Give feedback

1. AppManager
2. STF (state transition function) (frojdi)
3. preparehandler (marko)
4. processhandler (marko)
5. valset updates (marko)
6. precommit handler (marko)
7. preblock handler (marko)
8. recovery middleware (marko)
9. vote extensions
10. handling gas (wrapper in stf)
11. posthandler (frojdi)
12. Plug modules into server/v2 (julien)
13. Genesis (initchain)

phase 3

Tasks

Preview Give feedback

1. storage integration
2. cleanup client services (grpc, reflection, grpc service reflection.  #13601)
3. add cli for existing features (client/v2?)
4. Gas refunds (Refunding unused but allocated gas #2150)
5. Testing
6. benchmarking
7. add cli commands
8. integrate endpoints (broadcast tx, queries, etc..)

[tac0turtle]

closing in favour of #20439