• Regen Network is launching a Cosmos Zone dedicated to ecological applications (Carbon Credits and beyond)
• Since April 2020, Regen has been acting as the lead maintainer of the Cosmos SDK

What does 1.0 mean?

1.0 is a commitment to stability

Maybe it's obvious, but why is stability important?

We can't build durable, long-lived systems without stability. We need a solid foundation to start building other layers.

1.0 is a commitment to a great developer experience (DevX)

Why is DevX important?

Blockchain is hard! A successful blockchain development platform must have a strong focus on DevX to balance against the inherent complexity of developing distributed ledger technologies.

Stability & DevX for whom?

• Client Developers
  • developers building user-facing apps that integrate with Cosmos SDK blockchains
• Module Developers
  • developers building custom modules for Cosmos SDK blockchains
• App Developers
  • developers building Cosmos SDK blockchains

How Stargate moved us closer to 1.0:

• Protobuf: a standard multi-platform protocol for clients
• Live upgrades: blockchains can gracefully upgrade without needing to start over from genesis

Stargate for Module Developers

Simplified workflow for implementing a module:

1. Write proto definitions
2. Generate code
3. Implement interfaces in generated code
4. Wire up services in single RegisterServices entry point

1. Write proto definitions

package cosmos.bank;

// Msg defines the bank Msg service.
service Msg {
  // Send defines a method for sending coins from one account to another account.
  rpc Send(MsgSend) returns (MsgSendResponse);

  // MultiSend defines a method for sending coins from some accounts to other accounts.
  rpc MultiSend(MsgMultiSend) returns (MsgMultiSendResponse);
}

message MsgSend {
  string   from_address                    = 1;
  string   to_address                      = 2;
  repeated cosmos.base.v1beta1.Coin amount = 3;
}

message MsgSendResponse {}

message MsgMultiSend {
  repeated Input  inputs  = 1;
  repeated Output outputs = 2;
}

message MsgMultiSendResponse {}

2. Generate code

package bank;
 
// MsgServer is the server API for Msg service.
type MsgServer interface {
	// Send defines a method for sending coins from one account to another account.
	Send(context.Context, *MsgSend) (*MsgSendResponse, error)
	// MultiSend defines a method for sending coins from some accounts to other accounts.
	MultiSend(context.Context, *MsgMultiSend) (*MsgMultiSendResponse, error)
}

3. Implement interfaces in generated code

func (k msgServer) Send(ctx context.Context, msg *types.MsgSend) (*types.MsgSendResponse, error) {
	...
}
 
func (k msgServer) MultiSend(goCtx context.Context, msg *types.MsgMultiSend) (*types.MsgMultiSendResponse, error) {
	...
}
 

4. Wire up services in single RegisterServices entry point

func (am AppModule) RegisterServices(cfg module.Configurator) {
	types.RegisterMsgServer(cfg.MsgServer(), keeper.NewMsgServerImpl(am.keeper))
	types.RegisterQueryServer(cfg.QueryServer(), am.keeper)
}

Stargate for Client Developers

• client libraries in all languages
• backwards compatible APIs: breaking change detection is run against every commit to prevent breaking changes to v1 proto files
• gRPC + auto-generated REST/OpenAPI support
• easy to implement transaction signing given any off-the-shelf protobuf library

Typescript generated code

/**
 *  Msg defines the bank Msg service.
 */
export interface Msg {

  /**
   *  Send defines a method for sending coins from one account to another account.
   */
  Send(request: MsgSend): Promise<MsgSendResponse>;

  /**
   *  MultiSend defines a method for sending coins from some accounts to other accounts.
   */
  MultiSend(request: MsgMultiSend): Promise<MsgMultiSendResponse>;

}

Automatic REST/OpenAPI Endpoints

Stargate for App Developers

app.go is pretty massive 🤔

Stargate was about setting a foundation

But there's a lot work to do…

1.0 Goals for Client Devs: Protobuf

• stabilizing proto files as v1 (they're currently mostly v1beta1)
• proto files for individual modules will likely reach v1 before the SDK reaches v1 and when they do clients can expect stability

1.0 Goals for Client Devs: Transactions

• need to design SIGN_MODE_TEXTUAL to fully replace Amino JSON
• improve multisig signing UX
• standardized public key address format for new signature algorithms

v1.0 Goals for Module Developers

• protobuf code-generation improvements - better handling of Anys and custom types
• simplify and stabilize core types/ package
  • remove things that don't belong there
  • better decimal support
• simplify and improve the AppModule interface and inter-module wiring
• remove legacy code

Inter-module communication

Protobuf generates client golang interfaces:

type MsgClient interface {
	Send(ctx context.Context, in *MsgSend, opts ...grpc.CallOption) (*MsgSendResponse, error)
	MultiSend(ctx context.Context, in *MsgMultiSend, opts ...grpc.CallOption) (*MsgMultiSendResponse, error)
}

• Modules could talk to other modules using these interfaces
• This could greatly simplify app.go module wiring and standardize inter-module interfaces
• Authorization is handled automatically with this model

v1.0 Goals for App Developers

• greatly simplify module wiring so that app.go is much more concise
• inter-module communication as described in the previous slide could be key to that

Building a blockchain from existing modules should be really simple

app := NewApp([]Module{
  bank.Module{/* some settings */},
  gov.Module{/* some settings */},
  staking.Module{/* some settings */},
  ...
})
app.Start()

Independently versioned modules

• We might be able to split base/core packages (like types/ and baseapp/) and modules (x/bank, etc.) into separate go modules
• Then each module could have its own version and release cycles

If you have comments, questions, etc. please post in https://github.com/cosmos/cosmos-sdk/issues/7421

We hope this roadmap brings us one step close to realizing the Cosmos vision

Thank you!