The Road to Cosmos SDK v1.0

--- title: The Road to Cosmos SDK v1.0 slideOptions: theme: solarized transition: 'fade' # parallaxBackgroundImage: 'https://s3.amazonaws.com/hakim-static/reveal-js/reveal-parallax-1.jpg' --- ## The Road to Cosmos SDK v1.0 ### Aaron Craelius ### CTO, Regen Network <img src="https://cosmos.network/images/logos/cosmos-logo-black.svg" style="border:0; box-shadow:none" height="80"/><img src="https://i.imgur.com/XnmHAZ4.png" style="border:0; box-shadow:none" height="160"/> --- ## <img src="https://i.imgur.com/XnmHAZ4.png" style="border:0; box-shadow:none" height="250"/> - 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 ```proto 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 ```go= 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 ```go= 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 ```go= 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 ```typescript /** * 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 ![](https://i.imgur.com/uPCvGrY.png) --- ### Stargate for App Developers **`app.go` is pretty massive 🤔** ![](https://i.imgur.com/2p1QHT3.png) --- ## 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 `Any`s 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: ```go= 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** <div class="fragment"> <strong>Maybe something like this?</strong> ```go app := NewApp([]Module{ bank.Module{/* some settings */}, gov.Module{/* some settings */}, staking.Module{/* some settings */}, ... }) app.Start() ``` </div> --- ### 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!

Syntax	Example	Reference
# Header	Header	基本排版
- Unordered List	Unordered List
1. Ordered List	Ordered List
- [ ] Todo List	Todo List
> Blockquote	Blockquote
Bold font	Bold font
Italics font	Italics font
~~Strikethrough~~	~~Strikethrough~~
19^th^	19^th
H~2~O	H₂O
++Inserted text++	Inserted text
==Marked text==	Marked text
[link text](https:// "title")	Link
![image alt](https:// "title")	Image
`Code`	`Code`	在筆記中貼入程式碼
```javascript var i = 0; ```	`var i = 0;`
:smile:		Emoji list
{%youtube youtube_id %}	Externals
$L^aT_eX$	L^aT_eX
:::info This is a alert area. :::	This is a alert area.