Building an application specific blockchain using Cosmos SDK Part-3

Harish Bhawnani
Coinmonks
7 min readApr 7, 2022

--

Photo by Luca Bravo on Unsplash

So far in part-2, we discussed the technical details around Tendermint, Cosmos sdk and installed starport to scaffold and run the chain.We also went through the business flow for our custom module deal. Now we will start with defining our data types first. We will be using starport to generate the types. Note that starport will auto generate query and message handlers along with types. Use the flag--no-message so that starport doesn’t create sdk.Msg and msg service for our data type. Feel free to remove the query handlers if not required for a given type.

Let’s start with a dealCounter type which will take care of generating deal ids while creating new deals.

The --no-message flag helps us to generate type without sdk.Msg type and msg handler. We will be using idValue field under dealCounter type as an increment counter to generate deal ids while creating deals. The above scaffold command does the following -

  • Generates the proto type definition for dealCounter(deal_counter.proto).
  • Updates the genesis.proto file to include dealCounter under genesis state.
  • Generates the query messages definition(query.proto).
  • The query message handlers (under keepers directory).
  • The query proto and query proto grpc gateway files(query.pb.go, query.pb.gw.go).
  • Generates the cli command to invoke the query handler (query_new_deal.go).
  • Test files and test simulation parameters (for simulation testing).

Note that we don’t require user to query counter details. Therefore we should remove the query messages related to dealCounter from query.proto file. Also delete the scaffolded dealCounter query handler file from keepers folder and dealCounter specific cli commands from cli folder. And run the following command to regenerate the proto definitions (*.pb.go and *.pb.gw.go).

Note that we should not touch the *.pb.go and *.pb.gw.go generated files as those will be auto-generated every-time based on proto definitions. Also you will find the commands (in various files) similar to one as given below -

// this line is used by starport scaffolding # genesis/proto/state

Don’t remove such commands as those will be used by starport every-time to identify correct locations for the code generation.

Lets generate the newDeal map type -

This command does the following -

  • Generate the proto type definition for newDeal(new_deal.proto).
  • Updates the genesis.proto file.
  • Generate the query messages(query.proto).
  • The query message handlers. (grpc_query_new_deal.go).
  • The query proto and query proto grpc gateway files. (query.pb.go, query.pb.gw.go).
  • Generates the cli commands to invoke the query handlers (query_new_deal.go).
  • Keeper methods to serialize/deserialize data and crud operations on the store.(new_deal.go).
  • Test files and test simulation parameters.

Get, Set and remove operations for deals have been defined on keeper object (as shown above). Note that we are using prefix store for storing deals with prefix key NewDeal/value/ (key_new_deal.go).

Let’s modify the grpc_query_new_deal.go file to handle deal queries.

NewDeal will fetch us the deal details based on a given dealId(req.Index).We will be saving the deal object against dealId. Therefore, fetch the deal against the given req.index which is dealId in our case.

NewDealAll will iterate over keyStore to fetch all the saved deals from store. It also includes pagination feature to paginate the response.

Now similar to dealCounter and newDeal type, lets generate the contractCounter and newContract type with the help of starport scaffold command. Our contractCounter and newContract proto definitions should look be as given below -

We will be using prefix store here with prefix key NewContract/value/{dealId}/ to store the contracts. Note that dealId here is the id of the deal under which contract has been initiated.

Lets modify the new_contract.go (to handle the getter, setter for contracts)and grpc_query_new_contract.go (query handler) as shown below-

Let us register the query server on module- (module.go)

This will ensure that the module manager registers the query server of our custom deal module.

Finally we are done handling the query part for deal and contracts! In next part will take care of handling msg service for transactions & state changes.

--

--