Decentralized applications Part 2

February 23, 2022 The Editorial Board- Teamware Solutions

Gentle introduction to Solidity

We set to start with code instead of English this time around. Solidity is a programming language which is better not boxed into a specific paradigm. It, however; has lot of concepts borrowed from OOP. If you have read the solidity code above like you might read any newspaper like plain English, then you will have noticed we are creating a contract and it has something to do with underwater photography.

Like in our last dispatch we kept refining the understanding as we went along. We will adopt a similar approach here. So, let us write this explicitly and see how this transform to more refined understanding as we interpret things further.

We are creating a contract for something to do with underwater photography.

This is a great start because we are approaching this from the domain. The domain of photography. Now let us dive into the reason or “why” part of this contract. Underwater divers risk a lot to take photos. Photos like any other piece of art is subjected to theft and duplication. One of the simplest use cases of distributed ledger technology is to establish ownership. The underwater divers when put their finished photo and mint a token for that photo, it establishes the ownership of the photo that is acknowledged by the participants of the distributed ledger. If you ask the question what about non-participants to the distributed ledger? That is an intriguing question that is solved by different platforms using different approaches. In this article we will not address that question. We can tackle that question at a future dispatch for its own series of articles.

With that background let us revisit our understanding statement once again –

We are creating a contract to establish ownership of underwater photographs.

This is great refinement as it looks a valid high-level requirement. Let us now dive into the specifics of the language i.e., solidity and interpret the contract.

This is like a processing instruction (PI) you encounter in XML. The PI is known to instruct the XML parser about the encoding of the file so that characters could be interpreted correctly, the version of XML so that any transformation or plugin can evaluate feasibility to parse the file etc. This pragma line in solidity accomplishes the same goal.

In case we did not mention this earlier, solidity is a compiled language so, this file is compiled to a JSON representation encoded in binary before feeding into the Ethereum Virtual Machine (EVM); about which we briefly touched upon in our earlier dispatch. The numbers in the pragma like are the version numbers for the solidity compiler and the greater and lesser than symbol serve the intuitive purpose. i.e., the compiler should be greater than 0.6.0 and lesser than 0.9.0.

The import statements serve the same purpose they serve in any other OOP language. They are bringing in the referenced files into scope of the current compilation. One could have avoided the import statement by copying the content of those files here but that is just too much handle as contract complexity grows. We must take a moment and talk about openzeppelin here.

Open Zeppelin is an open-source project which establishes some standards for solidity contracts running in EVM. Consider them as framework for contracts. We use ERC721 which is a standard for Non-Fungible Token (NFT). Name of the type is ERC721 and NFT are typically collectible tokens which cannot be exchanged for like to like i.e., like a currency or coin. These NFT have URI’s and thus identity of their own unlike a coin. Open Zeppelin in the truffle development framework is installed using npm with the standard installation command. A peek inside the ERC721 yields –

Couple of things we takeaway from this is ERC721 is a contract. It uses the solidity keyword “is” which represents a concept like subtyping in OOP. One can peek in these contracts in the same repository. The reason such standardisation is required is from the fact that many distributed ledger systems become interoperable while following such standards which in part answers the question we stumbled earlier – “What happens to the [establishing of ownership] when non-participant to the distributed ledger?”

Returning to the contract we are naming our contract UnderWaterPhotosCollection with a symbol UWP. Symbols help locate a contract easily for users it is much like stock ticker. The additional details like the symbol and friendly name are provided to constructor of the contract. The constructor like its interpretation from the OOP concepts are executed only once. Notice the plural in the name, so this contract can contain many photos, and each can have different owner. This is not a specific requirement, but one can create different contract for each photos provided such a necessity arises.

This is right time for us to introduce the concept of why this code is called contract. This code enforces certain rules on the item (photo URI) which are observed in all exchanges in the network (distributed ledger). There is no necessity of any other application or individual to validate whether the rules are followed or not. The way distributed ledger is built is with these contracts always honoured. Thus, you must have encountered the adjective smart always associated with the word contract.

In our contract we are gravitating toward establishing ownership and all tokens minted for this contract will have that feature of establishing ownership forever in the ledgers. One of distinguishing feature of NFT is the identity. We use the Counters library of Open Zeppelin for this purpose. The library defines a basic type of struct Counter. This is used to maintain identity of different tokens minted. The syntax of the bringing library into use for the current contract is –

We take a pause here for the next dispatch where we dwell on the concept of ownership in the above contract and touch upon the concept of library. We will also bring the point of rubber meets the road of deploying this to a test distributed ledger and understand the real meaning of the word “mint” which we used in this dispatch quite liberally without really dwelling in on the actual use of it.