Development

Github metrics:

NOTE: This is beta software and is not considered production-ready. The module is subject to updates as there are still minor performance improvement work needed before this module is ready for primetime. Open-source contributions are welcome.

Application Specific Blockchains

There are a lot of reasons why an application might need its own blockchain but most of them boil down to the question of sovereignty. Every application has its own features and requirements — speed, security, cost, privacy — while blockchains like Ethereum, EOS or Polkadot require all their apps to share resources even if they have conflicting needs. When a conflict becomes contentious, a fork can occur. This happened to Ethereum when a single application (The DAO) was compromised and the wider community couldn’t agree on a unified plan to respond. If The DAO had been its own chain, it would’ve had the sovereign right to decide its own outcome. Instead all those interested in Ethereum maintaining the “code-is-law” concept forked into Ethereum Classic — I seems that technically ETH forked from ETC… but that’s ancient history.

Application Specific Blockchains come with their own problems and overhead or course. For example a certain degree of composability is lost by not having direct access to the state of other applications. Instead, Application Specific Blockchains might use Inter-Blockchain Communication (IBC) to send messages and queries between chains that rely on light client proofs to verify the information (Cosmos is a blochchain that will act as a hub to route IBC traffic). This article isn’t meant to debate whether an Application Specific Blockchain is right for you. Rather, assuming an app warrants its own chain, what might Non-Fungible Tokens look like in that setting?

Non-Fungible Things

Non-Fungible Tokens (or Non-Fungible Things as Sunny Aggarwal has conceded to call them) are essentially inventory lists. The concept might have originated with CryptoPunks or with an early version of Clovers Network, but it was CryptoKitties which established the first standard called ERC-721. This allowed for an extreme variety of use cases because the standard was as un-opinionated as possible as to exactly how the standard was used. That’s why we’ve been able to see such a wide range of uses from games and art to invoices and domain names. That’s why at it’s core a Non-Fungible Token only cares about the unique identification number and the token’s place of origin (which makes them essentially inventory lists).

This concept was core to the creation of an NFT Module within the Cosmos-SDK. For those not familiar with the SDK, it’s like ruby-on-rails for building scalable and interconnected blockchains. While there are many ways to build Application Specific Blockchains, Tendermint Inc. hopes to make the Cosmos-SDK the best option out there. Part of that goal is making reusable modules that take care of common use-cases on blockchains. For example the notion of a token is taken care of by the Bank Module, Liquid Democracy is handled by the Gov Module and securing the network with Proof-Of-Stake is handled by the Staking Module. These modules can be modified and integrated into what ever use case is needed on a chain-by-chain basis. The goal of the NFT Module is to allow any chain to re-use code related to Non-Fungible Tokens so that apps and wallets can use the same process for generating messages and querying state no matter which NFT blockchain they’re dealing with.

What’s Included?

Types

The NFT Module is built around the BaseNFT type. This contains the essential information relative to an NFT.

There is also an NFT interface which allows the struct to be extended to include other information that might be deemed desirable to be stored inside the NFT Module. At the moment this is restricted to the tokenURI to make it backwards compatible with ERC-721. However you could put as little or as much as you wanted. There is also discussion about a Metadata Module which would have the dedicated purpose storing and managing any necessary on-chain metadata.

Since there is no contract address to designate the origin of the NFT a denomination name is used (referred to as denom). This allows for many different collections of NFTs to live on the same chain and takes care of the aspect of origin I mentioned earlier. You may notice denom is missing in the NFT interface and BaseNFT struct. That’s because it is stored in the Collection type which contains all the underlying NFTs.

Messages

The NFT Module comes with four message types that are common among NFTs. The exact use or inclusion of these messages will differ from application to application so they come with a process for tailor fitting. There are also a number of Queriers, which are basically read only messages, that can be expected to be useful across use-cases.

MsgTransferNFT

This is the most commonly expected Msg type to be supported across chains. While each application specific blockchain will have very different adoption of the MsgMintNFT, MsgBurnNFT and MsgEditNFTMetadata it should be expected that most chains support the ability to transfer ownership of the NFT asset. The exception to this would be non-transferable NFTs that might be attached to reputation or some asset which should not be transferable. It still makes sense for this to be represented as an NFT because there are common queriers which will remain relevant to the NFT type even if non-transferable. This Message will fail if the NFT does not exist. By default it will not fail if the transfer is executed by someone beside the owner. It is highly recommended that a custom handler is made to restrict use of this Message type to prevent unintended use.

MsgEditNFTMetadata

This message type allows the TokenURI to be updated. By default anyone can execute this Message type. It is highly recommended that a custom handler is made to restrict use of this Message type to prevent unintended use.

MsgMintNFT

This message type is used for minting new tokens. If a new NFT is minted under a new Denom, a new Collection will also be created, otherwise the NFT is added to the existing Collection. If a new NFT is minted by a new account, a new Owner is created, otherwise the NFT ID is added to the existing Owner’s IDCollection. By default anyone can execute this Message type. It is highly recommended that a custom handler is made to restrict use of this Message type to prevent unintended use.

MsgBurnNFT

This message type is used for burning tokens which destroys and deletes them. By default anyone can execute this Message type. It is highly recommended that a custom handler is made to restrict use of this Message type to prevent unintended use.

Unintended Use

Each of these Message Types come with very little restriction on who can execute them. That’s why it is “highly recommended that a custom handler” dot dot dot. What that means is that each Application Specific Blockchain should write a custom handler that will handle the messages upon receipt and decide what to do with them. This is where custom logic can be applied like, “only the owner of an NFT can transfer it” or “only players with a score over 100 can mint new NFTs”. Once those requirements are met, the original handler can be used to carry out the rest of the operation. This saves time for engineers who don’t have to re-build the whole module to cater to their specific use. An example of this can be seen in the sample app here with the custom handler seen here that makes sure the UTC time is during twilight before allowing an NFT to be minted.

Open source, no installation.

It has been approximately 6 months since the Cosmos Hub mainnet launch. The Cosmos network has been running smoothly without any major chain-breaking incidents, and the ecosystem is growing day by day with more projects and builders entering the community with valuable contributions.

As one of the top-tier validators for Cosmos (ATOM), Cosmostation has also been doing its part to provide stable node operation and powerful tools for the Cosmos community as an effort to bring Tendermint and the Cosmos SDK closer to the public by lowering its entry barrier.

Below are some of the ecosystem tools and open source contributions developed and maintained by the Cosmostation team.

Cosmostation Wallet for Cosmos (ATOM)

Cosmostation iOS — Mobile wallet for iOS

Cosmostation Android — Mobile wallet for Android

Cosmostation Web — Web wallet with Ledger integration

Cosmos (ATOM) Block Explorer

Mintscan Explorer — Official Cosmos explorer trusted by most exchanges

Open Source

CosmosJS — JavaScript library for Cosmos transactions

Cosmostation iOS, Android — Swift, Java libraries for mobile wallets

Over the past few months, the team have accomplished a lot of the milestones they have set in their roadmap. Today, they are proud to announce a new addition to their list of contributions to the Cosmos ecosystem.

Introducing Keystation

An end-to-end encrypted key manager for decentralized applications and networks built with the Cosmos SDK.

Cosmos web wallets like Cosmostation Web Wallet and Lunie allow users to connect their Ledger hardware wallet for secure transactions, but ATOM holders without Ledger often experience inconvenience because there are no other means of access.

Comparatively, Ethereum has several convenient private key authentication methods like Metamask, which Cosmos does not yet have.

Cosmostation developed Keystation to give users a more convenient method to not only log into web wallets but also access decentralized exchanges and applications. They strongly feel that Keystation could also provide better usability and accessibility for users in preparation for the expansion of the Cosmos universe post-IBC.

Keystation User Experience

Keystation securely manages your mnemonic phrase. Conveniently access any decentralized applications or networks and sign transactions with no installation required.

Below are the steps for using Keystation from a user’s perspective.

Set account name and enter mnemonic phrase. Set your PIN (4 numbers + 1 alphabet). Your mnemonic phrase is encrypted using the PIN. Copy and paste your encrypted mnemonic phrase into the empty box. Press [Save] when Chrome/Safari asks permission to save your account name and encrypted mnemonic phrase.

Through the process above, the user’s mnemonic phrase is encrypted and stored in Keychain using Chrome/Safari browser’s key management system.

Allowing your stored mnemonic phrase to be immediately accessed and used for transactions could be considered dangerous. For this reason, they added an extra layer of security by requiring users to set a PIN.

This PIN is used to encrypt the user’s mnemonic phrase using JavaScript AES encryption before the user’s mnemonic phrase is stored in the browser’s Keychain.

AES Encryption (Advanced Encryption Standard)

Simple and powerful encryption and decryption method for JavaScript.

As you can see in the example below, a message entered by the user is encrypted with the combination of the message and a password.

For Keystation, the message would be the user mnemonic phrase, and the password would be the PIN set by the user.

code.encryptMessage(‘Mnemonic Phrase’,’User PIN’);

code.decryptMessage(‘Encrypted Mnemonic Phrase’,’User PIN’)

With this extra layer of security, Keystation prevents the browser Keychain from saving the actual mnemonic phrase and instead stores the encrypted mnemonic phrase.

The PIN set by the user is not only used for encryption but also as a password for user authentication.

*It is important to remember also not to share this encrypted mnemonic phrase to prevent any type of brute force attack. Make sure you are the only person with access to the device you are using (laptop, mobile phone, etc.). If you are using a device shared by multiple people, always remember to log out of your Chrome/Safari account.

Keystation Under The Hood

Secure, open source. All processes are operated in the client side. Here’s an explanation of how Keystation works under the hood.

In the client side, bundle.js is included to allow using CosmosJS on browserify in the browser. With the user mnemonic phrase, CosmosJS signs and broadcasts transactions.

Keystation stores user mnemonic phrase in the user’s computer browser. More specifically, this mnemonic phrase is stored in Chrome/Safari’s Keychain. For a simpler explanation, Keychain is Google and Apple’s password storage space (just like saving your ID and PW to your favorite website on Google Chrome for easier access).

When a user requests to send ATOM, Keystation generates a send transaction and requests the user to sign the transaction. The user is then required to enter the PIN to complete signing the transaction, and Keystation broadcasts the transaction to the network. The client then displays the results of the transaction.

Must-Know & Precautions

What you need to know before implementing Keystation to your decentralized application.

No user input (mnemonic phrase, PIN) is controlled by Keystation. User input in stored in Chrome/Safari’s key management system, only accessible by the owner of the account logged into the browser.

When using Keystation, make sure that you are the only person with access to the device you are using. If you use a device shared by multiple people, always remember to log out of your account on the browser.

Keystation is open source. Feel free to implement Keystation as a key management, log-in, authentication system for your decentralized application built with the Cosmos SDK.

Any network supported by CosmosJS developed/maintained by Cosmostation can be supported on Keychain.

Implementation

Keystation on Cosmostation Web Wallet

The first implementation of Keychain on an application will most likely be Cosmostation Web Wallet (Unless you are interested in integrating Keychain for your decentralized application before us!).

Conclusion

What Keystation does is allow you to store your mnemonic phrase in a secure location for a more convenient way to sign and broadcast your transactions.

See also: