Crown Platform NFT Framework

Artem
Artem
Jun 20, 2019 · 9 min read
Image for post
Image for post

Non-fungible Token creation on Crown Core

Since the beginning of the Crown Platform evolution, we wanted to build a public blockchain solution that will enable simple and fast integration with a modern distributed ledger technology. Back in August 2017, the foundational ideas of how the platform should look like were laid down. Since then, we’ve been working hard to realize these ideas and transform them into a tangible form. The general platform overview that is available here explains the main concepts of the Crown Platform. Today we are going to concentrate on the part that evolved to become the Non-Fungible Token Framework or NFT Framework. In the platform overview that part has a name — Registry Subsystem. If you’re not familiar with the term NFT, feel free to read a quick overview here. In simple words, when a token is non-fungible it means it’s not interchangeable, it has unique properties and one asset is not equal to another asset in the same set, as it is with the fungible tokens. They are mostly monetary and interchangeable.

After some experiments with development, we changed terminology and the API interface a bit. So it now aligns with the notion of NFTs that became popular with the rise of Ethereum, ERC-721 smart contract standard and success of the Cryptokitties game. We believe it will be easier for developers to understand the workflow and start using Crown Platform in their applications if we adopt the same abstract concepts that exist on the market. In general, we all need the same technical language which is platform-agnostic to effectively communicate about blockchain software development.

Crown NFT vs Ethereum ERC-721 NFT

The conceptual difference between Ethereum NFTs and Crown NFTs is that in the first case the development process is more code-oriented or smart contracts based. It means that the most part of the business logic is deployed and executed on the EVM. However, in Crown we use the data-oriented approach and the Crown Platform API as a gateway for the integration of your web or any other application with a blockchain solution. There are pros and cons to both approaches. The smart contract approach gives you the flexibility to run arbitrary code on-chain and customize your business-logic in a smart contract, and in many cases, it’s exactly what you need. But sometimes you need a blockchain solution that you can quickly integrate with your existing or developing application using the API. You don’t need to deal with the smart contracts languages and time-consuming development. You need to get clear on the data model for your non-fungible tokens set and how it fits into your architecture. So eventually, you have business-logic running off-chain on your back-end which interacts with the on-chain solution that you integrate using the Crown Platform API. Plus, you don’t have to deal with potential bugs that might be introduced with a smart contract code and are irreversible.

Image for post
Image for post
NFT Data Structure

Design Your Blockchain Solution

When you work on an NFT solution based on Ethereum, you need to write Solidity code that implements standard smart contract interface:

The implementation will encapsulate the logic of your NFT blockchain solution. The analog of the smart contract implementation on Crown is an NFT protocol registration. You need to define the set of rules for your non-fungible token solution. First, you need to set a protocol symbol or protocol ID, it should be a string that contains only symbols from the set: .abcdefghijklmnopqrstuvwxyz12345 with the length between 3 and 12 characters. It might be something like: “doc”, “docproof”, “prf”, “ckt” or “cryptoknight”, “lux” etc. This string is used as a unique identifier of the protocol in the system. Also, you can set up a long protocol name that will be more meaningful and can contain up to 24 arbitrary symbols, for example: “Documents”, “Documents Proof”, “Proofs”, “Cryptoknights Game”, “Luxury Goods” etc. As an engineer, you also need to define the metadata mimetype, its schema and whether it will be embedded in the NFT or just contain a link to an IPFS or another resource with the metadata. Usually, it should be an “application/json” format, and the metadata field should contain a link to the JSON file. Embedding metadata directly into the blockchain record only makes sense if it’s shorter than a URL. If the metadata field contains many symbols, the NFT transaction fee will grow exponentially (not implemented yet). You will also need to define some other rules for your protocol that will customize the behavior of your application. Some of the fields of the protocol are:

Note: the protocol registration is not necessary for the upcoming testnet release 0.13.9 (pre-release before 0.14.0), you can start NFTs registration with arbitrary protocol symbol to test your solution.

NF Token Registration and API interface

So now comes the fun part. As an engineer, you will be interacting with the Crown Platform API interface to issue new NFTs, query different information about them for your users, etc. I am going to provide you a couple of examples of how you can use the API through the wallet command line interface and a small code example.

All the NFT framework APIs start with the nftoken command. The subcommands list is: register(issue)|list|get|getbytxid|totalsupply|balanceof|ownerof.

In order to register/issue a new NFT instance you need to call the corresponding remote procedure:

Let’s imagine we are building a crypto collectibles game — CryptoKnights. It’s a game where you can own digital assets that represent unique knights. Every other instance has different properties based on the DNA generation algorithm. Just like with Ethereum Cryptokitties game. Let’s say the protocol symbol will be “ckt”. In order to register an instance of a CryptoKnight, you have to run a command like this one:

nftoken issue ckt 2772eeb3a5486f773ad7e47413424356da55db94c7f8e0528fcba5079ddeb8ed CRWJKC453SVnczLQD6opqJVMuHDqNWwaJAgV CRWD4W7PauajWooq8vmtzaxNzEEED5yL3FdZ “https://ipfs.io/ipfs/QmPiYzMQbSPxsKC2b6CHEUHWfqFHjX9bHSu6YVpiopzvTx"

As a result you will get a transaction ID: ce1444b48cdd83761afa79f3089d2d433a417ea3a6eb2cfc403dc0bf4e7f48c6. To uniquely identify an NFT you can use the combination of the protocol ID and the token ID. Or transaction hash.

As an architect of your application, you have to choose a strategy of generating NF token IDs. The restriction is pretty simple — it must be unique in the space of your protocol. It can be a hash of a document that uniquely identifies your tokens, it also can be a simple counter, unique seed, etc. In the example above I calculate SHA-256 hash of the DNA uniquely identifying a new CryptoKnight instance.

After the transaction is mature enough, the NFT is considered registered and can be used as an existing digital asset. The link to the metadata can look something like this:

Now you can query data from the blockchain to process and display it in your application. In order to get a single instance of an NFT you can simply use the get API:

As a result, you will have a JSON document that looks something like this:

You can also request the information about the NFT instance using the transaction ID:

Keep in mind that it means using different abstraction level, so it’s recommended to use the token ID to address NFTs. In this case, you interact on a level of your application business-logic.

To query multiple instances you will use the nftoken list API. This command is pretty flexible so you can request and process all existing NFTs, or only those belonging to a specific protocol or belonging to a specific owner or both. You also can set up the requesting blockchain height and amount of records. All of this will give you the flexibility to adapt requests to your needs. For example, to request all CryptoKnights tokens you will write:

or to get all the instances belonging to the owner of the address CRWJKC453SVnczLQD6opqJVMuHDqNWwaJAgV your command will look like this:

Other API documentation details are available using the help command of your node instance and will be available in the project wiki soon. You can also request additional information using the APIs:

Code Example

This code example is a fragment of a simple application that receives a file as an input and registers an NFT with a unique hash of that file as a token ID, proving the existence and ownership of the underlying data.

In the example above we generate two new Crown addresses and then make a call to register a new NFT within the “doc” protocol space. And that’s it. You now have a non-fungible token instance registered on the Crown blockchain. We use a local node here for registration on a sandbox blockchain. (Note: the information of how to set up and use Crown sandboxes will be available soon). It’s really up to you what language or library to use for the development. In the near future, I will update the Crown Bitcore library to support NFTs out of the box, so it’s easier for web developers to integrate Crown blockchain solution in their applications.

Thank you for your attention. Stay tuned for the upcoming 0.14 Emerald testnet release this week and more technical documentation on the wiki.

Crown Platform

Crown is a digital token and blockchain platform enabling…

Thanks to J. Herranz

Artem

Written by

Artem

Crown Platform

Crown is a digital token and blockchain platform enabling independence serving individuals & businesses. We are focused on legal compliance and transparency utilizing our decentralized governance model.

Artem

Written by

Artem

Crown Platform

Crown is a digital token and blockchain platform enabling independence serving individuals & businesses. We are focused on legal compliance and transparency utilizing our decentralized governance model.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store