Two Textbooks from Praxis Press

In two earlier posts, I had introduced the concept of DIGITALICs as a new discipline of study in management schools and had also explained it further in one of the famous Praxis Lockdown Lectures. Now we at Praxis Business School have taken the next step of actually introducing these concepts into the curriculum of the 2 year AICTE approved Post Graduate Diploma in Management (PGDM) Program.

A key challenge is the availability of textbooks that can introduce the correct technology to management students who do not come from computer science and other programming backgrounds. To overcome this Praxis Business School, under the Praxis Press Program has come out with these two textbooks.

Python for Business Managers - is a textbook for the Foundations of Data Science course that is compulsory for all first year management students. This is a small, 64 page book that not only teaches the student how to analyse data with Python but also sets him up for a deep dive into data science. In India, the book is available through Pothi and globally on the Amazon platform.

AI and Deep Learning for Business Managers  - is a textbook for the AI for Managers course that is offered as second year elective to the management students. This 100 page book not only explains the basics of neural network based AI and Deep Learning systems but, building upon the knowledge gained in the Python textbook, shows students how to actually build small AI systems from scratch. In India, this book is available through Pothi Global availability will be arranged through Amazon soon.

---

---

These two textbooks were written in the shadow of the infamous Covid19 lockdown and remain as a testimony to the trying times that the world had to go through.

Purpose of Life

 The big question .... What is my IKIGAI

---

Find purpose .. Stephanie Sieghoertner

Non Fungible Tokens in Journalism

One of the enduring tragedies of journalism today is its inability to monetize the significant intellectual effort that goes into creating great articles. With so much content being available 'free' readers have become increasingly reluctant to pay for articles that they read. Print magazines that have moved their contents to the digital format have tried protecting their IP behind paywalls and subscription mechanisms. Many users find this too cumbersome and opt either to read the few free articles or to simply go somewhere else. Which is a tragedy.

What we would want is a micropayment mechanism that allows individuals to pay for articles that they actually want to read without having to bother about annual subscriptions tied to credit cards and other relatively complicated payment mechanisms. In an earlier post that was also published in Swarajya in 2016, I had explored how browser based crypto-wallets could be used to make micro payments and I am delighted to note and report that MetaMask - the Ethereum wallet that can be added-on to both Chrome or Firefox - is now being widely used by the crypto-community. MetaMask is used both to establish identity and to make small payments. With a little bit of effort, websites can acquire the ability to make pages of the site available against small payments from MetaMask wallet.

But technology is moving even faster and now with non-fungible tokens we have a really new way to manage this process of protecting and monetising intellectual property.

image credit https://www.bankofengland.co.uk/knowledgebank/what-are-cryptocurrencies

What is a non-fungible token? Opensea is currently the best known marketplace for NFTs and their tutorials (1) The Beginners Guide ... and (b) The NFT Bible .... are good introductions to the topic. The fundamental difference between a traditional crypto-token ( like Bitcoin, Litecoin, or Ethereum) and an NFT is the concept of fungibility. A rupee coin ( or any fiat currency) can be exchanged for another without any loss of value. If you lend me a rupee and you take it back from me after a year, you will never ask me for that specific rupee coin that you had given to me. Any other rupee coin will do. That is fungibility. On the other hand, if you had leased a flat to me to live in and after a year you want me to give it back to you, you will demand that same flat. I cannot say that I am giving you back another flat in another part of the city of similar value. It never works that way because a flat - or anything physical - is a non-fungible asset.

What is true in the world of fiat currency (like rupee or dollar) and physical assets is also true in the world of crypto assets. Bitcoins or any other crypto-assets hold significant value ( as do fiat currency) but they are fungible. Cryptocurrency transactions are approved by the network participants ( also called 'miners') on the basis of total historical inflows being more than total historical outflows from a wallet resulting in a current wallet balance being more than the current outbound transaction. There is no need to track the specific coin or token or any part thereof.

Non-fungible assets or tokens are different because one has to keep track of the ownership of the entire token. Non-fungible tokens exploded into the crypto landscape through a trivial game called Cryptokitties that allowed people own and trade images of kittens all of which were different from each other. Almost all non-fungible tokens are based on smart-contracts built with the Solidity language and deployed on the Ethereum network. For more information on how these things are done, please see my recent post on how to build smartcontracts. Stripped of all jargon, what this means is that the contract defines a digital artifact -- an image, an audio or video file -- and an owner, whose identity changes when there is a transfer of ownership. All transfer of ownership is recorded in an immutable Ethereum blockchain and so there is never any doubt about the ownership of an asset.

But there are two problems :

• What if I make a copy of the digital artifact? Frankly there is nothing that can stop you. You can go to the Louvre and take a picture of the Mona Lisa but that does not mean that own the Mona Lisa. Ownership does not change. You have a copy that is obviously a copy. In the case of digital assets, it is impossible to distinguish the original from the copy so does it really make much sense to go to such extent to protect a digital asset? 
• What if the asset is something physical like a car or a house? Does it make a little more sense? It surely does! If the asset is physical, the ownership is clearly established but whether you can enjoy the asset would depend on other factors like being able to evict squatters or illegal occupants with the help of the judiciary or the police.

These are important issues but resolving them needs a little more understanding of the process of creating a non-fungible token.

During the process of creating an NFT, we usually provide only two things : 

• The asset, which is a digital file that is stored either on the blockchain ( which is very very expensive) or otherwise on some server and only the location is stored in the blockchain. 
• The wallet that owns the asset as defined by its address or the public key. Anyone who has access to the private key of the wallet is technically -- de facto or de jure --  the owner of the asset.

Obviously there is no fun if the asset can only be seen by the wallet owner? What is the point if I own a million dollar painting that no one can see. So all owners will make their assets visible. But then people can copy it? Which makes ownership pointless! 

So where is the catch? Why are non-fungible assets suddenly so valuable? Not because of stupid Cryptokitties!

The salvation lies in one specific feature of non-fungible tokens called Unlockable Content. This is a piece of information that can be viewed only with the private key of the wallet that owns the asset and can be used to store truly private information. This is where one can keep stuff like access keys or passwords with which one can actually use the asset, rather than just see it.

• If the asset is password protected PDF file, then the PDF can be publicly visible and downloadable but the password will be an Unlockable Content that is only available within the wallet.
• If the asset is house or a flat, that is visible from the road, then access key of an electronic lock to the house can be kept as an Unlockable Content within the wallet. Without this one cannot enter the house.

Armed with the concept of Unlockable Content, one can design a simple mechanism to protect and distribute journalistic content using a general purpose eBook reader that has an embedded crypto wallet to handle non-fungible assets. This is very similar to the MetaMask add-on that can handle fungible assets like Ether. We will refer to this wallet enabled eBook reader as an eReader/Wallet.

On the Ethereum blockchain there are two standards : ERC-20 for fungible tokens and ERC-721 for non-fungible tokens and both are in the public domain. So any website that publishes content can set up the mechanism to interact with any eReader/Wallet. What we need is a way for the website to request fungible tokens from the eReader/wallet and when this is approved by the human user, the website will receive the ERC-20 fungible token and send the ERC-721 non-fungible asset to the  eReader/Wallet. Obviously, the owner of the eReader/Wallet must have loaded up the wallet with ERC-20 fungible tokens like Ether or equivalent prior to any transaction. What is interesting is that the same eReader/Wallet can interact with any website that is built as per ERC20/721 standards. So there is no need to subscribe to any specific website separately.

The non-fungible asset (say a PDF file) may or may not move to the users machine. It may still reside on a distant server but the unlockable content (say, the password) will be on the eReader/wallet and using this the user can open the asset and view it within the eReader/Wallet.

There are two very interesting aspects to this mechanism

• The user who has received the PDF file cannot send it to someone else. They will not be able to read the file without the access key stored as the Unlockable Content in the owners wallet.
• The user, if they so want, can transfer the asset to someone else through a standard ERC-721 wallet transaction but then they lose access! This is no different from buying a paper magazine at news stand, reading it and then passing it on a friend.

What if the owner of a journalistic asset makes the Unlockable Content public? Theoretically that is possible. After all, if the owner of a house decides to hang the key on the gate or the password of a PDF file is used as an extension of the name of the PDF file there is little that technology can do. However, it is entirely possible to make this quite difficult if the eReader/wallet is so designed that it can ONLY use the unlockable content to open the asset within itself but will NOT allow it to be exported or published. While reverse engineering cannot be stopped and 'jail-broken' eReader/wallets cannot be ruled out, a process like this will ensure that a vast majority of assets will be protected successfully.

Publishing journalistic content as a non-fungible asset on the Ethereum blockchain and creating an eReader/Wallet could be a very good way to solve the problem that is currently facing journalists. The Brave browser, with its built in support for cryptowallets could be a step in this direction.

Deep Learning for Business Managers

Why this book?

 After years of being talked about and featured in science fiction, artificial intelligence is finally showing up in the world around us. But before we delve into artificial intelligence, do we understand what normal, natural human intelligence is?

For sure, there is no simple, single definition of intelligence, but it can be broken into a number of tasks, or categories of tasks. At one end of the spectrum we have raw, computational power that allows us to solve complex but logical problems, while at the other end we have abstract, philosophical concepts like being conscious and  self-awareness and have motivation and morality. In between are four kinds of tasks that are seen as intelligent - the ability to predict future outcomes, to react successfully to unexpected circumstances, to resolve between ambiguous situations and to create something new and original.

Complex logical problems can be resolved with traditional computer programming while the philosophical issues are best kept aside for academicians and spiritualists. The other four namely predictions, uncertainty, ambiguity and creativity - is what practical artificial intelligence is all about.  From this perspective certain tools and techniques have been found to be very useful. Deep learning -- the combination of a tool called artificial neural networks and a technique called machine learning -- is one approach that drives many of the most exciting innovations in the business world.

Managers in mainstream companies are cut-off from this surge of technology that is flowing past them but it will have a significant impact on their careers. Many tasks that were being carried out by humans are now done by machines. This was already evident in factories run by robots and now back-offices are adopting robotic process automation tools to eliminate white-collars. There is no escape from the relentless march of this technology.

Sun Tzu’s Art of War tells us to know the enemy. Even though AI is not an enemy in that sense, it is important that managers today understand the nuts and bolts of this critical technology. This book will help business managers enter this field, find their way around and prepare them to leverage the potential opportunities that lie within this magical world.

It is naive to believe that AI can be understood through text and slides and managers can leave the coding part to professional programmers. Zukerberg and Musk built global businesses but they did not outsource the coding to India. Computer coding is as much a part of the corporate landscape today as Mathematics and English is and every manager should have the ability to at least read, follow and understand computer code.

This book uses Python to demonstrate how intelligence arises, or manifests itself, from pure data through the medium of neural networks that are loosely modelled on human, biological, brains. If the reader invests a little effort in simply following along and understanding what the Python codes are doing they will be rewarded with five interesting applications of artificial intelligence :

• Predict the incidence of diabetes and cancer on the basis of pathological data
• Classify images based on what they contain.
• Predict what a person is likely to type next on a keyboard
• Get a Taxi to learn how to navigate around a city and Moon Lander to learn how to land safely on the moon
• Create original art-work

There are many books that talk about and describe deep learning but to really appreciate the magic that they bring to the table,  it is important to actually build simple systems that demonstrate intelligent behaviour. No coding is required but readers with even a faint memory of computer coding should have little difficulty in navigating through this book.  

This book was written for second year MBA students in Praxis Business School where Python is taught as a compulsory subject in the first year. The syllabus and pedagogy at Praxis has a strong bias towards high technology and the author is grateful to Dr Subhasis Dasgupta, a member of the faculty who teaches these subjects in the Data Science program, for his help with some of the examples used in this book.

Building CRUD Applications on the Blockchain - Part II

Once the basic architecture or the big picture of the blockchain ecosystem -- as explained in Part I of this article -- is understood, we can now move into the nuts-and-bolts of actually building a software application. To do so, we need the following four pieces :

1. An Ether wallet - to store Ether and pay it out when necessary
2. A Solidity development environment or IDE to build contracts
3. A connection service provider that allows client software to connect to the Ethereum network
4. A platform or IDE to build a client software that can execute transactions against Solidity contracts residing on the blockchain

1. The Ether Wallet - MetaMask

An ether wallet is a Solidity contract with an address ( think Bank Account Number)  and a private-key (think Specimen Signature in a Bank Account) that resides on the blockchain. What is commonly understood as an ether wallet is actually a client application that can execute payment transactions from the Solidity wallet-contract. So we will refer to this client as a wallet-client. 

A wallet-client can be installed on your local laptop or be hosted with a crypto-exchange like Coinbase and is protected with a password that is different from the private-key of the actual wallet-contract. For our purpose we will use MetaMask wallet-client that sits as a Chrome extension in the Chrome browser. A Mozilla extension is also available but I have not tried it. Android / iPhone versions are irrelevant for our exercise.

After installing the extension,  select the network that you want to connect to, which could be the MainNet or in our case a TestNet called Rinkeby. MetaMask allows connections to other public TestNets or also a local blockchain that you might install on your local machine. This last option may be used by experienced users but my advise is to stay away from such adventurism until you get your basics right.

Once connected to the network, MetaMask will allow you to create a number of wallet-contracts. You need to create at least one wallet-contract and and note down its address and private-key. The next step is to fund the wallet-contract with Ether. If you were using the MainNet, then you would have purchase Ethers at a crypto-currency exchange like Coinbase and have them sent to the address of your wallet-contract. In the case of the Rinkeby network,  you can get free Ethers -- that of course have no value in the real MainNet -- by visting  Rinkeby faucet and following instructions. The simplest way is to send out a tweet with your wallet-conract address,   the URL of the tweet in their form and request for Ether. After a minute or two -- remember, nothing happens instantaneously on the blockchain because of synchronization requirements -- you will suddenly find that your wallet-contract has Ethers that you can use.

2. The Remix Ethereum IDE

There are many Ethereum IDEs available but you can start with Remix , a hosted IDE that runs in a browser. Contracts developed in the Remix IDE can be deployed on the MainNet or on any of the TestNets that are supported in the MetaMask wallet-client that you have installed in the previous step after paying the required fees - in Ethers - from the wallet-contracts defined in the MetaMask wallet-client. But since deploying and testing of contracts on the network is a little slow, Remix gives you a local Ethereum node -- complete with wallets etc -- where you can rapidly test the Solidity contracts that you are testing. Remix also gives you a small and generic client with which you can call ( or invoke) functions (or methods), pass parameters and see the results returned.

The code that you write in Remix can be saved either on your local disk or directly as a Gist in Github! 

A CRUD application

The application that we will build is inspired by this post from Rob Hitchens who has not only shared the architecture of his application but also his entire code. The basic idea in our application, that is different from Rob's application, is as follows :

• We have an employee database consisting of EmpID, EmpName, EmpSalary that is stored in a simple array called database9 that is indexed by the EmpID. The EmpID is the primary key or index and is stored separately in another index array called db9index.
• There are six functions that are defined, namely, 
• insertEmp - create new record in the database
• updateEmpSalary - update the salary field
• deleteEmp - delete a record
• getEmpCount - get total number of records
• getEmpData - get record of employee specified by EmpID
• isEmp - to check whether an employee ID exists or not

Open the  Remix  IDE, delete any sample applications and start coding. To get started, create a new .sol file called pmCrudCon.sol and copy the contents of the code available here.   Simply copy and paste this code into your file. You are free to modify this application and save it in your own Gist but for the time being let us deploy and execute the sample code.

The IDE has three important tabs on the left

• The coding tab where you write or edit your Solidity program
•  The compile tab where you choose your compiler and compile your code. On successful compilation, go to the bottom and look for a field called ABI. Copy the contents of the field and store it separately. We will need it later for the client application. You can of course come back and copy it later as well.
• The deployment tab that we will study in some detail

In the deployment tab

• The first key field is Environment where you have three options. Either you can deploy the contract in the Javascript EVM in your local browser or you can choose the Injected Web3 option that will connect to the TestNet that your MetaMask wallet-client is already connected to! Since both the Remix IDE and the MetaMask wallet-client are loaded in the same browser, the connection is delightfully easy. The third option of Web 3 provider is more complicated and can be safely ignored for the time being.
• The Gas limit and the wei value can be ignored or left on default.
• Assuming that the compile is successful, you can now press the Deploy button. Now a couple of things will happen
• Since Deployment costs you Ether, MetaMask will seek your confirmation to debit the required number of Ether ( do not panic, it is a miniscule fraction of an Ether) and send it to the network.
• Once you confirm, the deployment transaction will be be submitted and may take a few seconds to complete. You will get a confirmation from MetaMask that  you transaction (for deployment, or whatever) has been confirmed.
• 
  
  
  
  
• If you scroll down you will see details of the contract ( in this case PMCRUDCON)  that has been deployed. Copy the contract address - that is more important than the name.
• There is a button to execute each of the functions along with a way to send arguments to the same. Go ahead and insert an employee with name, salary, emp id as 'Narendra Modi', 10000, 100 or something like that.
• Note that the Blue boxes represent Read Only functions that do not require Ether payment. The Brown boxes represent state-changing transactions and for each MetaMask will request you to confirm a payment and only then will the transaction be submitted to the network.

3. Connection Service - infura.io

When MetaMask or Remix connects to the network -- mainnet or testnets -- they know the URL to use but how will the client that you and I write, connect. To do so, head over to infura.io and create first a login for yourself and then a Ethereum project. Navigate to the dashboard settings, choose the network that you wish to connect to and get the URL of the corresponding endpoint that will look like this : https://rinkeby.infura.io/v3/68ae8e6787934812814cffe52999999"

4. The Python Client

The contract-client that will allow us to execute transactions built into a deployed Solidity contract can be built with any language that has a web3 library with a set of functions that allow us to interact with the Ethereum network. Both Javascript and Python libraries are available but because I am more comfortable with Python we use Python in this example. Any Python IDE -- like Anaconda with Spyder or Jupyter -- is fine but we prefer to use Google Colab! and the corresponding notebook is available here. Like Remix, Colab is a another browser based IDE so again there is nothing to install. If you are not familiar with Google Colab, suggest that you learn it by reading tutorials.

The notebook is pretty straightforward and goes through the following steps

• Install the web3 client with pip. Note that you need to restart the VM after the installation
• Define the contract address, the wallet address and the wallet private key 
• Unhide the cell containing ABI variable and place your own ABI variable from Remix there
• Define the contract in terms of its address, and ABI value
• Execute the read_only functions and see the results. Data that you have entered in the Remix client should be visible here.The only way you can get an error is if  you have not transferred the following variables correctly
• Endpoint URL from infura.io
• Contract Address & ABI value from Remix
• Wallet Address and Wallet Private Key from MetaMask

For the state-altering ( or insert, update, delete) transactions, the process is little complex because we have to send the function along with a way to make an Ether payment. Look at the pyinsertEmp function that acts a wrapper to the Solidity insertEmp function. Before calling the Solidity we need to specify the maximum quantity of gas that we will expend on executing the function. Gas comes at a price and quantity x price gives us the total that we will spend. To spend we need to specify the address of the wallet-contract as well as its private-key. We also need to specify the chainID ( for Rinkeby this is 4).

Now we call the function or submit the transaction. If all variables have been set correctly and the gas quantity is sufficient, the transaction will be enqueued for the network but it will take time to execute. Hence the python code must keep waiting until a non-null transaction receipt comes back or there is a timeout. Typically, this takes about 20 - 30 secs in the testnet. Both the transaction receipt and a broadcast log ( if set) can be read to understand whether the transaction has succeeded or failed.

---

This application has demonstrated how to write a basic application that allows us to create, read, update and delete data records into the blockchain. This is primarily what any commercial application does and we have shown how to this with a 

• Solidity Contract - pmCrudCon
• Python client demonstrated here notebook is available here

The next step would be to write contracts that will accept payment in Ether and deliver a digital artifact  or service to the initiator of a transaction. To see how that is done look at 

• This Solidity Code : that allows you to deposit and withdraw Ether into a contract and also send it to a third party
• This Colab Notebook that shows the Python Client

Building CRUD Applications on the Blockchain - Part I

With Bitcoin and cryptofinance in the news, blockchain programming has suddenly become very important but most people - including many programmers - do not have a clear idea on how to write a program on the blockchain. This article is not about theoretical concepts like Merkle Trees and SHA256 Hash. It is about how to write an application that creates, reads, updates and deletes a data record from a 'database' on the blockchain. A CRUD application. If you are impressed by Powerpoint slides in Zoom Webinars, you may skip this article, but if you are a programmer -- professionals or hobbyist -- do read on. You will end up writing your first blockchain application without too much sweat.

I first came across Bitcoins as currency in the virtual world of Second Life and wrote about "Bitcoins - my first look at a new currency" in 2013 and then I struggled to wrap my head around this fantastic concept for almost a year until I reached a point where I could write "Bitcoins - as I understood it." While Bitcoin itself was a fascinating concept - an esoteric cocktail of mathematics, programming and economic concepts worthy of a Nobel Prize in Economics - the underlying technology of blockchain was even more fascinating. The incredible potential of this technology became evident with the advent of the Ethereum Virtual Machine and intrigued me enough to explore the concept of the CryptoCorporation, a strange, but successful automatic, manager-less organisation that could create value out of thin air and finally in 2016, I was finally able build my own cryptocoin using Smartcontracts running on the Ethereum blockchain.

Back in 2016, writing blockchain programs were not for the faint-hearted, because there were two big stumbling blocks.

• First, one had to install a whole suite of very complex software -- including wallets -- on the laptop and 
• Second, one had to buy Ether, with credit cards, and use it each time you wanted to run, or even test a program that you had written.

This was frustrating, to say the least. First, if you had to replace or change your computer, there was this great likelihood of not just losing your software stack but also your Ether wallet unless  you had the foresight and the ability  ( which very few had) to keep proper backups. The other huge challenge was the sudden decision of the RBI / Government of India, not too ban cryptocurrency, but to bar banks from allowing people to purchase cryptocurrency using normal, legitimate banking channels like credit cards. Hence while the whole world, including China, raced ahead with blockchain technology, programmers in India were left with no option but to only watch from the sidelines. Fortunately, the Supreme Court has lifted this ban  in March 2020 and blockchain programmers can start work again after losing nearly two years of sitting it out in the wilderness.

image from Forbes.com

But blockchain programming is so very different from 'normal' programming that most programmers have difficulty in wrapping their heads around the  concept. Forget about the concept of smart contracts, even basic stuff like writing, reading and updating a piece of data becomes esoteric because apparently there is no one machine where program resides or executes. It took me quite a while to understand this and once I did, the elegance and beauty of it all took my breath away. Which is why I thought of writing it down, not just for my own clarity but for other programmers who could possibly be in the same boat as well. While I have tried to keep my post as simple as possible, please note that reading beyond this point means that you have some programming experience that goes beyond Excel. An exhaustive manual would be far too long but if you are like me, a hobbyist with a penchant for coding, sit back and enjoy this ride. 

This tutorial is based on two important premises :

1. Only the bare minimum software will be installed on the local laptop, we will use hosted software as much as possible.
2. We will not spend any real money -- as in using credit cards.

Without any further ado, let us start with 

The Big Picture / Architecture

A theoretical and mathematical description of the blockchain is given in this article but for all practical purposes it consists of a network of computers (the MainNet) that run the the full Ethereum node software. All full nodes contain identical copies of two artifacts : (a) a node software application and (b) a huge database file that is called the blockchain. Both the node application and the block chain are kept in continuous sync by constant exchange of messages between nodes, all of which have a peer-to-peer relationship with each other. In addition to the MainNet, there are other private and public chains called Test Nets  with names like Ropsten, Rinkeby, Roerli etc. 

In traditional three-tier client server architecture we have three components. 

• Client software written in, say Python, Javascript, VisualBasic, or in many cases running inside an Internet Browser like Chrome, Mozilla or Edge. This provides the user interface.
•  Application software, written in say, PHP, Ruby, Python that resides within an application server or web server like Apache. This provides the business logic. 
• A persistent data store like MySQL. Obviously the application server (Apache) and the database server (MySQL) may or may not reside in the same physical machine.

Developers build applications by writing both client-side programs (in Javascript, Python) that are hosted in the client machine and server-side program (in PHP, Python etc) that are hosted in the web-server. There is also the case of client side software being stored in the server and downloaded and used inside a browser, but we shall park that aside for the time being. The database engine, MySQL ( or equivalent) is not written but purchased or downloaded and installed on an appropriate machine. If you are a programmer, all this will be very easy for you to understand.

In the blockchain architecture we have a two tier setup

• Client application written in Javascript, Python (there could be others, but I have not used other languages) or running in an Internet Browser. As in traditional client-server architecture, the client software provides the user interface which may or may not be GUI.
• 'Contracts' - a new term used only in the blockchain -- written in a language called Solidity - again a new language used on blockchains -  that holds BOTH business logic AND persistent data.

Since contracts are the new kids in the block, let us look at them a little carefully

• Think of a contract as an instance of a object from the world of Object Oriented programming. This means that the contract has both logic ( as in methods, or functions) and data. But unlike OO objects which can have multiple instances, there is only one instance of a contract. Like OO objects, contracts can inherit properties from other contracts.
• The state of a contract -- as defined by the data that it holds -- can be changed  through a transaction. A transaction can be initiated from a client application either by a human being or some automated process
• A contract is deployed into and resides in the blockchain. Hence it is available on all computers on all networks and all copies are in the same state. Each contract is identified with its own unique address that is generated when a contract is deployed in the blockchain through any node.
• A wallet is special kind of contract that holds a defined quantity of Ether. A transaction can deposit any amount of Ether into a wallet contract but to withdraw the Ether from a wallet contract, one must provide a password ( aka 'the private key') of this specific wallet. So a wallet is a contract defined by its address (similar to a bank account) and its private key (similar to specimen signature in a bank account)
• When a client application connects to any node (through a standard URL) it requests or calls a contract that is now loaded from the blockchain on the node where it resides to the Ethereum Virtual Machine running on the same node. On the EVM, the contract performs the task -- in the process, it may or may not change its state -- and then is put back in its new state back into the blockchain. 
• It is actually a misnomer to say that the state of the contract is changed. The blockchain is immutable, it can be added to but earlier data cannot be changed. When we say that the state of the contract is changed, what we really mean is that the original contract along with all transactions that were supposed to change it are ALL stored in the blockchain. Hence the current state of the contract can -- and is -- recreated. This may sound incredibly inefficient when compared to, say a relational database, but it is the only option when there is no central authority ( like the MySQL database adminstrator) who is trusted by everyone in the network. Which is why it does not make any sense to port an application from a traditional three-tier platform to the blockchain platform where there exists a clear central authority, like a statutory body and its database administrator, to own manage a central database.. Blockchain applications are meant to handle situations where there are multiple operators -- all of whom are peers, without a central hierarchy -- and there is no reason to trust any or all of them.

Finally, in addition to the client application and the Solidity contract, that a developer needs to build there is a third 'joker' that the developer needs to deal with - a payment. Since the transaction is getting executed on network node, the owner of the node needs to be incentivised or compensated for their investment in hardware and electricity. In the Bitcoin network this incentive is in the form of new coin that is mined ( that is another long story -- see here, and here ) but in the Ethereum ecosystem it is a combination of mining and an actual fee that must be paid by the client application to the node owner in the form of Ether. On the Main Net, this is real Ether that has be mined or purchased but in the other Test Nets, there is a lot 'fake' or 'toy' Ether that is freely available. Think of this as monopoly money with which we buy properties in the Monopoly game. This Ether - real or fake, depending on the network being used - must be sent along with the transaction request.

The second part of this tutorial will show you how to to build 

• a Solidity contract pmCrudCon.sol  to manage employee data ( empID, empName, empSalary)
• a Python Application to Insert, Update, Display and Delete this Data

Badshah Alam Shah 1204

 

Located this coin among others in a locker being cleaned out. Charanpreet Singh helped me decode the text that reads 19 Zarb Murshidabad and Badshah Alam Shah 1204. Used this information to get some more information from an auction site.

Deepawali acquisition!