Skip to main content

Cosmos SDK vs Rell

When I first looked at Tenderming ~4 years ago (I seriously considered using Terndermint to implement consensus in Postchain), I was not particularly impressed by its programming model -- the example code in Go looked overly verbose.

I looked through Cosmos SDK docs today. Docs look really nice. And it's nice that the application can be built in a modular fashion, using pre-made Cosmos SDK modules. However, verbosity is still there...

Let's look at code needed to implement a single SetName operation in Cosmos. This operation simply checks that transaction's signer is the owner of the name, and then changes value associated with the name. This should be simple, right? It's probably the simplest thing you can do with blockchain. Let's first look at how one would implement it in Rell, e.g.:

operation set_name_value (name, value: text) {
   val entry = name_entry @ { name };
   entry.value = value;

Even if you don't know anything about Rell, it should be easy to follow -- we first find an entry by a key (name), then check if owner of the entry is the signer of a transaction which includes this operation call, and then we update the value part of the entry. This kind of stuff is also very easy to code in Solidity -- code would be roughly the same.
Now look at the Cosmos tutorial code, taken from here:
const RouterKey = ModuleName // this was defined in your key.go file

// MsgSetName defines a SetName message
type MsgSetName struct {
 Name  string         `json:"name"`
 Value string         `json:"value"`
 Owner sdk.AccAddress `json:"owner"`

// NewMsgSetName is a constructor function for MsgSetName
func NewMsgSetName(name string, value string, owner sdk.AccAddress) MsgSetName {
 return MsgSetName{
  Name:  name,
  Value: value,
  Owner: owner,

// Route should return the name of the module
func (msg MsgSetName) Route() string { return RouterKey }

// Type should return the action
func (msg MsgSetName) Type() string { return "set_name" }

// ValidateBasic runs stateless checks on the message
func (msg MsgSetName) ValidateBasic() sdk.Error {
 if msg.Owner.Empty() {
  return sdk.ErrInvalidAddress(msg.Owner.String())
 if len(msg.Name) == 0 || len(msg.Value) == 0 {
  return sdk.ErrUnknownRequest("Name and/or Value cannot be empty")
 return nil

// GetSignBytes encodes the message for signing
func (msg MsgSetName) GetSignBytes() []byte {
 return sdk.MustSortJSON(ModuleCdc.MustMarshalJSON(msg))

// GetSigners defines whose signature is required
func (msg MsgSetName) GetSigners() []sdk.AccAddress {
 return []sdk.AccAddress{msg.Owner}

// x/nameservice/handler.go

// NewHandler returns a handler for "nameservice" type messages.
func NewHandler(keeper Keeper) sdk.Handler {
 return func(ctx sdk.Context, msg sdk.Msg) sdk.Result {
  switch msg := msg.(type) {
  case MsgSetName:
   return handleMsgSetName(ctx, keeper, msg)
   errMsg := fmt.Sprintf("Unrecognized nameservice Msg type: %v", msg.Type())
   return sdk.ErrUnknownRequest(errMsg).Result()

// Handle a message to set name
func handleMsgSetName(ctx sdk.Context, keeper Keeper, msg MsgSetName) sdk.Result {
 if !msg.Owner.Equals(keeper.GetOwner(ctx, msg.Name)) { // Checks if the the msg sender is the same as the current owner
  return sdk.ErrUnauthorized("Incorrect Owner").Result() // If not, throw an error
 keeper.SetName(ctx, msg.Name, msg.Value) // If so, set the name to the value specified in the msg.
 return sdk.Result{}                      // return
Jesus... So what is going on here: Everything which Rell does implicitly -- defining data format for an operation, serialization, dispatch, etc. -- needs to be written manually in Cosmos-based Go code.
People often ask why we made Rell. This is a simply illustration -- to allow programmer to write stuff in a simple way, writing only 4 lines of code instead of 37. That's almost 10x difference. And this is trivial operation which fits well into KV store provided by Cosmos, for an application which requires a more complex data model the difference would be even bigger.


galynkaber said…
A major incentive for New Zealand gamblers is the opportunity to commerce factors for cashback. The system encourages a sport of persistence — that is, the longer a participant resists the urge to exchange factors the more cashback he/she will bag. Don’t wait too long end result 정카지노 of|as a result of} factors have a use-by date of 90 days, from the final time one plays at Spin Casino. Spin Casino’s loyalty programme isn't any totally different to overwhelming majority of} its type. Kiwis will earn factors on every real cash wager they place. A excessive engagement degree equates to bumper factors that may catapult gamers up the rungs of the VIP ladder.

Popular posts from this blog

Lisp web tutorial?

"PHP vs. Lisp: Unfortunately, it's true..." article initiated quite active discussion on reddit , one fellow asking : Can someone post a tutorial for taking a clean install of Ubuntu (or windows or anything) to finish with serving a basic CRUD application using lisp? Maybe a TODO list with entires consisting of: incomplete/complete boolean, due date, subject, body? actually i had an impression that there are more than enough such tutorials, but as nobody replied i've tried finding one myself, starting with Hunchentoot tutorials. surprisingly, none of them covered a short path from clean OS install to working examples. neither i've found my ABCL-web  tutorial suitable for this, so i decided to try myself.  my idea was that Linux distros like Debian and Ubuntu contain a lot of Lisp packages, and it should be fairly easy to install them, as it automatically manages dependencies etc. i've decided to try Hunchentoot -- i'm not using it myself, but it's k

A note to my former self: You're not supposed to take care of everything

In 2012-2013, I led the development of an open-source project called "Colored Coins", which defined a protocol for user-issued fungible tokens on the Bitcoin blockchain. In fact, this was the first protocol of its kind; before colored coins, the only fungible tokens on a blockchain were the native tokens (e.g., BTC on the Bitcoin blockchain). How did I become the lead dev? It was simple: I thought it was a cool project and relatively easy to implement. In August 2012, I stumbled upon an article about colored coins while browsing a Bitcoin forum. At that point, it was merely a theoretical concept. Intrigued by the idea, I believed that it could be implemented in a few weeks and might be a nice addition to my CV. Back then, the world of "crypto" was less about money and more about exploring the possibilities of decentralized, peer-to-peer networks. The project started with just a few people discussing it on a mailing list. The first implementation I created the first

Fujitsu UH572 review

This ultabook is barely relevant now; but, on the other hand, I've been using this ultrabook for about 6 months, which allows me to cover things not covered by other reviews. Perhaps, it would be of interest to people who consider buying used laptops. Overview  Fujitsu UH572 is a cheap and light ultrabook. For me, the weight is a very important factor, as I often move around with an open laptop in my hands (sometimes even typing while I hold it one hand). Anything heavier than 1.6 kg is unacceptable. On the other hand, I need fast CPU and lots of RAM for the work I do, so netbook-like devices are not an option. And I can't afford high-end ultrabooks, so I'm glad that devices like UH572 are available. Here are specs of the one I got: Intel Core i5-3317U (1.7-2.6 GHz, 3 MB cache, 2 cores/4 threads, Ivy Bridge) 4 GB RAM 500 GB HDD 32 GB iSSD (SanDisk i100) Intel Centrino Wireless-N2230 b/g/n (see the rest of specs in datasheet) The alternatives were: De