I am trying to understand the concept and use cases of blockchain. I plan to put up a series of blogs on this subject as I navigate through the complexity of the subject. I will be more than happy to receive any response pointing out flaws in my understanding. Please write to me at ashok.nag@gmail.com.
Definition of Blockchain:
Bitcoin.org: The blockchain is a shared public ledger on which the entire Bitcoin network relies. All confirmed transactions are included in the blockchain. It allows Bitcoin wallets to calculate their spendable balance so that new transactions can be verified thereby ensuring they’re actually owned by the spender. The integrity and the chronological order of the blockchain are enforced with cryptography.
Ethereum: A blockchain is a public database that is updated and shared across many computers in a network.
Wikipedia: A growing list of records, called blocks, that are securely linked together using cryptography. The blocks are timestamped and chained with the previous block by incorporating a cryptographic hash of the previous block.
IBM: Blockchain is a shared, immutable ledger that facilitates the process of recording transactions and tracking assets in a business network.
Oracle: Blockchain is defined as a ledger of decentralized data that is securely shared. Blockchain technology enables a collective group of select participants to share data. With blockchain cloud services, transactional data from multiple sources can be easily collected, integrated, and shared. Data is broken up into shared blocks that are chained together with unique identifiers in the form of cryptographic hashes.
Our definition: Blockchain is a digital record management system with the following properties:
Records are grouped into blocks with a pre-defined limit for the size of a block. The size of a block determines the number of records of a given size that a block can include. Data in blocks can only be appended and not deleted or modified.
The process of creating a new block and adding it to a given chain determines the type of blockchain. There are mainly two types of blockchain, namely permissionless and permissioned. The former one is called public blockchain as access to it is open to all. The latter type restricts access to authenticated users only and is also known as a private blockchain.
Blocks are mostly stored in a key-value database. Bitcoin, Ethereum, and many other cryptocurrencies use LevelDB database of Google. Cryptographic hashes are used as identifiers for a block as well as its records. In other words, hashes are the keys and the data as the value.
The “chain” part in “Blockchain” refers to the fact that two consecutive blocks are linearly linked as a parent and a child. The block which has no parent is called the Genesis block of a particular chain. The “chaining process” entails the incorporation of the hash value of a parent block in the header of the child block. A block’s header contains all the metadata of the block. This linking of parent and child through a hashing process ensures
immutability of data of a child’s parent block and then all its ancestors up to the genesis block
Before explaining the components of a blockchain in more detail, we need to clarify the term “distributed ledger” and its connection, if any, to the concept of “distributed database”.
A ledger, primarily an accounting term, is a date-wise summary of all transactions of values, details of which are kept in a supporting book called “journals”. The word” ledger” was used in the blockchain context because its first use case was in the creation of a decentralized currency system. Since a ledger is also a record-keeping system, the term has persisted. But the question remains whether a ‘distributed ledger” is conceptually and practically equivalent to a “distributed database”. The answer is a big No.
Let us first demystify the term “distributed”. Oracle has defined a distributed database as “a set of databases stored on multiple computers that typically appears to applications as a single database. Consequently, an application can simultaneously access and modify the data in several databases in a network”.
Ozsu and valduriez have defined a distributed database and database management system as a “ Collection of multiple, logically interrelated databases distributed over a computer network. A distributed database management system (distributed DBMS) is then defined as the software system that permits the management of the distributed database and makes the distribution transparent to the users” (page 3). It is important to note that a distributed database system must also have an associated database management system to enable end users to access, query ,and generate user defined reports. Although a key-value database is also called a database, it provides limited support for data manipulation to discover patterns within the database and, therefore, the DBMS associated with it is very rudimentary.
Let us now look into the ledger aspect of blockchain-based databases. What does a business ledger look like? IBM, while highlighting the deficiencies of current business ledgers, has given the following example.
IBM states that the current business ledgers are “inefficient, costly, and subject to misuse and tampering.” If this is the “reality”, then all the balance sheets and P&L accounts of IBM itself are faulty, and cannot be trusted by investing public as well as any tax authority”. Be that as it may, it is undoubtedly true that no enterprise will maintain its transactions only in a blockchain database although the immutability property of blockchain may have its own use.
For pedagogical purpose, let us consider the following example of an accounting database model
Obviously, a proper industry standard accounting information system (AIS) software will require a much more complex database. For our limited purpose, it suffices to note that a ledger book database cannot be a list of transactions only. A number of complex rules must be enforced on the database to create a proper double-entry accounting system. For example, a bank reconciliation process that matches a company’s bank statement with its cashbook balances is automated in many accounting information systems(AIS). The participants in this process must be authorized and cannot be anonymous validators. A blockchain-based database cannot be a solution for such essential requirements of an AIS, although underlying transactions can be stored in a private blockchain for future auditing requirements (see the article: Blockchain as the Database Engine in the Accounting System).
Let us consider the information management issues in regard to the Letter of Credit (LC), the most important banking document for facilitating international trade. In general, there are 5 five parties involved in an LC-based international payment settlement process. They are- importer, exporter, issuing bank, advising bank, and confirming bank. Today, banks use the SWIFT platform’s category 7 message type for sending and receiving messages between these parties. It is eminently possible to use a permissioned blockchain platform for sending and receiving LC-related messages. But it is impossible to use a public blockchain platform for this purpose. Furthermore, such a blockchain must rest at the top of a standard relational database to enable payment settlement and recording of underlying credit flow.
The moot point is that a blockchain-mediated database is extremely useful for record-keeping purposes and not for enabling contestable transactions involving values between a network of legally connected parties. For enforcement of any contract between two parties, the foremost requirement is the identification of the parties involved. It is immaterial whether the parties are connected in a network managed by a centralized authority or not. The anonymity of transacting parties should be considered the weakest part of a blockchain-based transaction system and not its strongest one. As we know a chain is as strong as its weakest part.
References:
References:
Musa Aujara Shamsuddeen (April 2019) ,Documentary Letter of Credit Discrepancy and Risk Management in the Nigerian: Crude Oil Export; Ph.D Thesis submitted to University of Central Lancashire
Özsu M. Tamer & Valduriez Patrick (2011) Principles of Distributed Database Systems; 3rd Edition 2011
Tan Boon Seng , Kin Yew Low (2019) Blockchain as the Database Engine in the Accounting System in Australian Accounting Review No. 89 Vol. 29 Issue 2
To understand the driver of the Indo-Pacific Economic Framework(IPEF) that has been launched on 24 May by 13 countries of South-East Asia including 4 members of the QUAD group and most of the ASEAN countries, we need to understand the interplay of regional and global aspirations of and challenges faced by these countries.
The first quarter of the present century has seen a quantum leap in humanity’s progress in science and technology creating the possibility of bringing an end to the childhood of humanity. A possibility but not a certainty. On the contrary, a more than even chance is emerging about a nuclear armageddon bringing an end to human civilization as we know it now. The 9/11 terror attack, the financial crisis of 2007-08, America’s war on terror and its exit from Afghanistan, the disproportionate impact of the COVID-19 pandemic on developed countries and now the Ukraine war -all are pointers to an irreconcilable conflict of interests among nations states of today which can be resolved only in a theater of war and destruction. Globally, there are two conflicting intertwined players- a declining but still globally dominant power, both economically and technologically, and a rising power with the ability to challenge the dominant one on both these fronts.
The genesis of IPEF can be traced back to a 2018 document – declassified in January 2021- on Indo-Pacific Strategic Framework prepared by the United States National Security Council(USNSC). The foremost security challenge faced by the USA, as identified by the USNSS is: “How to maintain US strategic primacy in the Indo-Pacific region and promote a liberal economic order while preventing China from establishing new, illiberal spheres of influence, and cultivating areas of cooperation to promote regional peace and prosperity?”.
The document emphasizes the threat posed by China’s rise as a technology superpower. “China seeks to dominate cutting-edge technologies, including Artificial Intelligence and Bio-genetics, and harness them in the service of authoritarianism. Chinese dominance in these technologies would pose profound challenges to free societies.”
This 2018 strategy document also underpins India’s pivotal role in containing as well as counterbalancing China’s aggressive posture in the Indo-Pacific region. The document is quite candid about USA’s objective in regard to India-
“Accelerate India’s rise and capacity to serve as a net provider of security and Major Defense Partner; solidify an enduring strategic partnership with India, underpinned by a strong Indian military able to effectively collaborate with the United States”.
The Indo-Pacific Strategy document issued in February 2022 by the US government espouses the same line of thought articulated by the 2018 document. The word “economic” is added to provide a veneer of creating a trading block like it was envisaged in the Trans-Pacific Partnership Agreement(TPP). TPP did not take off as US Senate failed to ratify it. Being a trade agreement, ratification by congress was a necessity. By making IPEF a framework document, a kind of declaration of intent, it should be possible to avoid the requirement of any legislative approval by all signatories. The word Economic is also slightly problematic since there are already two agreements for facilitating trade among countries of this region. The Comprehensive and Progressive Agreement for Trans-Pacific Partnership (CPTPP) is a free trade agreement (FTA) among 11 countries including Canada, Chile, Mexico, and Peru. The CPTPP was concluded on 23 January 2018 in Tokyo, Japan, and signed on 8 March 2018 in Santiago, Chile. Regional Comprehensive Economic Partnership Agreement (RCEP) is another free trade agreement between ASEAN countries and Australia, China, Japan, Korea, and New Zealand. India was a member of the drafting committee of RCEP but eventually did not join it because it would put India in a disadvantageous situation vis-à-vis China in a free trade regime. It is interesting to note that 3 ASEAN countries having close relationships with China, namely Cambodia, Laos and Myanmar kept them away from IPEF.
Four areas of cooperation have been identified in the joint statement issued by the 11 signatory countries to IPEF. In each of them, it is difficult to see a convergence of interest of all signatory countries. For example, let us consider the Clean Energy, Decarbonization, and Infrastructure component of IPEF. Although India is a signatory to the Paris agreement that requires all countries to achieve net-zero carbon emission by 2050, the Indian prime minister promised to cut its emissions to net-zero by 2070 only. China has committed to reaching net-zero status by 2060 while US and EU have committed to reaching the target by 2050. India’s overriding national interest of poverty eradication by maintaining its growth momentum over a longer time will not allow it to toe its de-carbonization policies to that of developed countries who are already enjoying a lifestyle that has led to a much higher per capita carbon emission than is the case with India.
As regards the Trade component of the framework, the declarative statements are as general as possible. Out of 13 participating countries in the IPEF framework, only USA and India are not part of another regional free trade agreement, Regional Comprehensive Economic Partnership or RCEP. China is a member of the RCEP trade block. India was a member of the RCEP drafting committee since the committee began its work in 2011 and just before the signing date of the agreement, in November 2019, it opted out. As a result, India would be out of two existing trade blocks that cover almost all important counties of the region- RCEP and CPPTP. So it is difficult to envisage what new terms and conditions can IPEF will bring in to assuage India’s concerns.
As regards the Supply Chain component of IPEF, the statement says:” ensure access to key raw and processed materials, semiconductors, critical minerals, and clean energy technology”. Among the manufactured products only “semiconductors” is mentioned. The most important omission is Artificial Intelligence related products which represent the cutting-edge technologies of today.
To conclude, on the high table of the 13 signatory countries of IPEF, the USA is bringing nothing substantial to offer. It is more of a taker than a giver. IPEF may turn out to be more of a hubris of a declining power.
I am providing a link below to the latest version of my paper. The Reserve Bank of India has declared that it will start a pilot project on the issuance of CBDC. The former Governor Subbarao has strongly cautioned RBI against any interest payment on account-based CBDC. Please see my detailed discussion on various issues related to this subject.
The key takeaways from my paper:
CBDC should not be a mutated version of Bitcoin type digital coin.
CBDC must possess three properies of paper currency fully and comprehesnively: No third party verification is required to transfer digital currency from a holder to a recipent.
No account balance concept is introduced and therefore no double spending is possible.
A holder is a legal owner unless proved otherwise.
All digital currency are of a certain denomination and every transfer is legitimate as long as wallets are genuine. A proper application of public key cryptography and hash function allows a digital currency to mimic it’s paper based counterpart.
The only difference with paper curreency is that transactions based on digital currency are not competely anonymous. But investigation of audit trail of a particular digital note would be very complex and costly. So it would not be easy.
Double spending is prevented because notes are automatically modified in the wallet of the sender which will not be accepted by another receiver’s wallet. No internet is required for a transaction to take place and notes cannot be sent through internet.
No requirement of a blockchain database.
It is neither an account-based nor a token based payment system.
Notes can travel back to issuer- the central bank- and get destroyed by the central bank.
The death toll of COVID-19 has reached 2.9 million by April 2021, a little less than 0.04% of the world population. In Wikipedia’s list of the largest known epidemics and pandemics caused by an infectious disease, COVID19 is ranked 8th in terms of its death tolls1. The deadliest known pandemic in history, the Black Death of 1346-1353 in comparison killed between 70-200 million people. Thus, humanity has been able to contain, if not eradicate, nature’s fury by constant progress in scientific knowledge and technology. And, to paraphrase Shakespeare, “therein lies the rub”2. The incidence of death due to COVID19 has been the largest in the most advanced country of the world- that is the USA. Till January 2021, the USA accounted for around 20% of total recorded death worldwide due to COVID-19. The top 5 countries, namely the USA, Brazil, India, Mexico, and UK accounted for a little less than 49% of total deaths. The share of these 5 countries in the world population was around 27% and excluding India the other 4 countries had only 9.5% of the world’s population3. This huge disparity among various countries in terms of the mortality impact of COVID -19 calls for a cross-country analysis of the same.
The objective of the present paper is to identify the distinctive characteristics of the countries recoding 1st wave of COVID-19 deaths of varying intensities. Since country is our unit of analysis, data on various proximate causes of death of a COVID-19 infected person may not be available at that level. However, available micro-level- studies of patients of a single hospital or a local administrative unit -like a county- can be relied upon to identify the possible factors like the presence of certain specific co-morbidities that could determine the fatality rate of the COVID-19 patients.
The paper is organized into 3 main sections. Section I reviews the literature on the characteristics of COVID-19 patients and its impact on their subsequent survival. The parameters that have been used in creating a scoring system to determine the survival probability of COVID-19 patients are also reviewed. It is an accepted fact that higher mortality is expected for COVID-19 patients with chronic lung diseases like asthma. In this respect, the relevance of the so-called ‘hygiene hypothesis” is briefly discussed. Section II discusses the data and methodology used. Section III presents the results. A concluding section follows.
In December 16 2019, I wrote this letter to RBI Governor
To
The Governor
Reserve Bank of India
Mumbai
Sub: Possibility of introducing Central Bank Digital Currency in India- a Technical Blueprint
Respected Sir,
Many countries in the world including China are experimenting to introduce Central Bank Digital Currency (CBDC). I have worked out a blueprint for developing such a CBDC for India. I would like to point out that such a CBDC, although based on the principle of cryptography, is not designed on the Distributed Ledger concept. It also does not require Third Party Verification based Consensus schema that drives current Bitcoin and similar cryptocurrencies. According to me a CBDC must mimic the basic characteristics of paper currency which are anonymity (to a reasonable extent, as any digital asset is finally traceable) of transactors, bearer as legal owner and a legal tender if the both transactors agree on this mode of transaction. Furthermore, at the unit level each CBDC would have distinct denominational identity and cannot be sub-divided.
If this proposal appears to be- prima facie- feasible and fits into the RBI’s overall scheme for currency management, I would be ready to provide the underlying distributed database structure etc. Finally, I would humbly state that my proposal is only a proposal and needs extensive discussion amongst all stakeholders to make it a proper working solution.
Best regards
Ashok Kumar Nag
Former Adviser`
Department of Statistics and Information Management
Reserve Bank of India
Now that RBI is preparing to introduce digital currency, I feel that I need to put in public domain the blueprint for a digital currency that I had proposed.
eRupiah: RBI’s Virtual Cash
Introduction:
No currency has ever been used in the human history which did not have the stamp of an authority. Bitcoin is a medium of payment but it is not money for the same reason. As long as, a citizen of a country cannot pay taxes with Bitcoin, it cannot be called a legal tender. Nonetheless, the technology underlying Bitcoin is a significant one with great potential. A central bank, issuer of paper currency, can use some selected components of Bitcoin technology to replace paper currency with virtual currency, retaining all the important features of paper currency. The most important of them is that a central bank note is a freely negotiable bearer bond and a legal tender in the hand of its holder. It does not require any third party verification. Counterfeiting a central bank note is not impossible but difficult and costly. The central bank neither authenticates any transaction made with that particular note nor does it keep any record of that transaction. The note remains as a liability on the book of the central bank till it comes back to it, either for reissue or its destruction. The physical nature of the note ensures that no double spending is possible with the same note by its current holder. In case of digital cash, the main issue that a central bank has to resolve is the issue of double spending without depending on third party verification of the same. What follows hereunder is an outline of a system that any central bank can implement to issue its own currency retaining most, if not all, of the desired properties of a paper currency.
The main features of a paper currency are:
It is a legal tender; transfer between two transactors can happen only through face-to-face encounter; double spending is not physically possible; no third party verification required; counterfeiting is possible but costly and detected by physical examination; each note has a unique identity; gets destroyed when unusable, liability of a central bank, in general.
I am presenting below a system based on digital currency on a mobile phone. There is no compelling reason to believe that the same system cannot be implemented on a specially designed smart card with embedded chip. The system outlined below is described within the currency management framework of the Reserve bank of India (RBI). With little tweaking the same can be customized by any central bank.
RBI Currency Management Framework:
RBI carries out its currency management function through its 19 Issue Offices located across the country. There is a network of 4281 currency chests and 4044 small coin depots in selected commercial bank branches. These chests store currency notes and rupee coins on behalf of RBI. The note distribution mechanism is summarized in the following diagram.
For issuance of digital currency, each currency chest would function as a data center for hosting the ledger book of notes issued from it. Similarly each issue office of RBI would have a copy of the entire ledger book of notes. A folio would be opened in the note ledger book when the first time a specific note is issued. Each data center will have complete inventory of wallets issued by RBI. An wallet could be a mobile app downloaded on a person’s mobile phone or it could be a smart card to be issued by RBI. The details are given below.
Every bank branch would have a digital cash dispenser. Any wallet holder would be able to replenish her wallet with digital currency by pairing it with the dispenser via Bluetooth or NFC communication channel. Similarly every ATM would have similar facility. At the time of cash dispensation from bank branch or ATM would require Aadhaar based biometric verification of wallet. For cash transfer between wallets of two individuals this verification is not a necessary requirement.
The protocol for issue of eRupiah
RBI would maintain ledgers of each currency note in a distributed database.
Currently RBI issues notes through its Issue offices. The distributed database will be created according to issue departments of RBI. Each Issue office of RBI will be able to issue new digital currency and destroy old digital currency. Destruction of old digital currency would help RBI to keep the number of entries in the ledger folio of a particular note within a limit. Every Issue offices would maintain record of all notes issued by it as well as copies of corresponding records of 3 neighboring Issue offices.
Each currency chest will have a database of notes received by it from RBI’s Issue department.
Each currency chest will also have replicated database of its three nearest neighbor
The system will issue new digital currency when an account holder wants to withdraw cash from its account with RBI. It would be optional, to start with. An account holder can withdraw cash or digital currency according to her discretion.
The account holder would specify how much of its cash withdrawal would be in digital form. This facility would be provided for an interim period when both forms of currency would be in circulation.
To incentivize issue of digital cash, RBI may reward with a fixed amount that could be related to the cost of producing physical cash.
RBI is banker to the Central and State Governments. It also functions as banker to the banks and thus enables settling of inter-bank obligations. These large account holders of RBI would get digital cash in their Jumbo Wallet which would be a server in the account holder’s custody. It would be like a till holding cash. An authorized person can withdraw e-Rupiah from the till as and when required.
The RBI’s Note ledger would comprise ledger folios of each currency notes issued.
Each record in the Note ledger would comprise the following attributes: (1) a sequential no, (2) unique identity / sr no of a note, (3) hashed value of the note serial no, (4) identity of the issue department, (5) denomination, , (6) time stamp of transaction, (7) hashed value of identity of paying wallet (first time payer would be RBI), (8) hashed value of identity of receiver wallet, (9) active flag, (10) hashed value of first 9 attributes , (11) hash value of the first 9 attributes of earlier transaction record of the same note. The identity of a wallet is described below.
RBI will also maintain database of each wallet downloaded from its website.
The wallet database will have a header record with the following attributes (1) IMEI no of each phone, (2) Aadhaar No of the phone owner, (3) timestamp of successful downloading of the wallet, (4) the GPS location of the phone at the time of downloading of the wallet, (5) a unique private key generated for each wallet and (6) the corresponding unique public key generated for each wallet. This data would also be hashed and encrypted with RBI’s private key and will be part of the header record. RBI’s public key would also form a part of the header record. The private and public key of each wallet would be generated by RBI at the runtime. The hashed value of attributes 1 to 6 would be the identity of each wallet.
Each wallet will have its own database of transactions. Each record in the transaction database will represent a note that has been loaded into the wallet. Each record will have the following attributes: (1) unique identity of the note, (2) note denomination, (3) digitally signed (with the private key of the paying wallet) hashed value of the concatenated string of serial no and denomination, (4) digitally signed ( with the private key of the paying wallet) hash value of concatenated string of attributes 1 and 2 of the header record with private key of payer wallet, (7) public key of the paying wallet, (8) timestamp of last transaction( i.e. timestamp of receipt of the note , (9) timestamp of the payment transaction, (10) payment status (paid or unpaid), (10) hashed value of the earlier transaction of the note(attributes 1,2,3,4,5).
A transaction between two wallets would involve “note data” transfer from the paying wallet to receiving wallet. [A separate note is given to explain how such transfer can happen with QR codes}. Every note that gets transferred from the payer’s wallet to the recipient’s wallet would essentially mean transfer of the entire record from the former to the latter. In the process of data transfer two insert / update activities take place in the receiver’s and payer’s wallet respectively. The receiver’s wallet inserts a new note record while the payer’s wallet updates the concerned note’s existing record.
Once the receiving wallet gets a new e_Rupiah note, it checks the authenticity of the note by calculating hash value of the concatenated string of attribute 1 and 2 of step at 13. In the payer’s wallet the status flag would get changed to “paid” while in the receiver’s wallet it would continue to have the status flag as “unpaid”.
Any wallet would have a limit in terms of number of records / notes. When the database has reached its limit then the wallet would have to be uploaded to RBI and a new wallet has to be downloaded.
At any point of time a single wallet would be subject to 2 limits- holding limit of no of transactional records and total value of a single transaction. For a high value transaction two factor authentications would be required. (say above one lac). Both paying wallet as well as receiving wallet has to simultaneously establish connection with RBI and get their credential verified.
As and when no of records in a wallet’s transactional database reaches its limit, the database has to be downloaded in an ATM or at a bank branch. The wallet would be purged of the all transaction records with status as “paid”. The wallet holder then can download more E_Rupiah from an ATM or from a bank brunch. RBI will update its ledger book of individual notes thus uploaded from each wallet.
Any fraudulent transactions identified in the process of uploading would get notified and thorough automated forensic audit perpetrator of fraud would get identified. Downloading of Wallet:
The user sends a sms to a designated no with the Aadhaar no of the sender. Each sms would cost the user 1 INR. RBI would send a link to the phone and clicking on the same the app would be automatically downloaded. To activate the app, the user has to sign-in with his/her Aadhaar no. For additional security one may think of incorporating biometric signature of the wallet holder as another feature of the wallet; every use of the downloaded wallet would require signing in biometrically by the wallet holder.
2. The wallet will have the following features:It will recognize another wallet in its vicinity using NFC technology. Alternatively Bluetooth technology for pairing two cell phones can be also used. Both the wallets would then exchange their digital identity and verify them with public keys of both and RBI’s public key. After two wallets have been paired, the payer’s / payee’s wallets would prompt the respective wallet owners to initiate the intended actions on their part. The payer will have to initiate payment action and would type in amount of money to be paid. The wallet would automatically prompt for denominations – a built in program would provide the best possible composition nearest to the amount indicated by the payer. The payer would have the right to change the composition and the resulting total value.
3. Once the payer approves payment the required data transfer takes place without seeking any third party verification at that time. For a transaction above a certain threshold value, at the discretion of the transactors, the receiver’s wallet may be connected with Aadhaar database and a biometric confirmation of the payer’s bonafide may be authenticated.
4. If any wallet holder commits a fraud by hacking the wallet’s database and changing the header record, it would be considered as an act of counterfeiting of notes. As and when any receiver uploads data to RBI website, the same would get immediately detected when RBI updates its ledger folio of notes involved. The concerned wallet holder would be notified with the fraudulent transactions and details thereof. It would be a matter of time to nab the fraudster.
5. For merchants, wallets can function like mPOS (mobile point of sales) machine. A merchant’s wallet would authenticate the payer’s wallet and notes therein by directly connecting to RBI’s ledger of notes.
How the system will function:
Alice downloads the mobile app/wallet from RBI website. Alice visits it nearest ATM or bank branch and loads its wallet with required e-Rupiah. On a single day Alice would not be allowed to load her wallet with more than, say, fifty thousand value of e-Rupiah. The cash dispenser, say ATM, would be configured accordingly.
Alice wants to pay, say one thousand rupees, to Bob; the Alice keeps her wallet bearing mobile to Bob’s wallet and taps the application on her mobile. The respective apps recognize each other and Alice keys in the amount to be disbursed to Bob. If Alice has necessary denominations then the application would give nearest amount higher than that amount and which can be transacted. The balance can be paid back by Bob.
Loss of Wallet
In case of loss of a wallet, the holder of the wallet would be required to register the loss with RBI and provide its mobile number and Aadhaar number. RBI would broadcast the IMEI no of the wallet to all mobile service providers, thus blocking any further use of the mobile. In due course, the stolen wallet can be traced and, in case of theft, required action by law enforcing agencies can be initiated. If a fraudster wants to use a stolen wallet by replacing the original header record, it would need to replace all unpaid notes’ records with values consistent with corresponding values of the new fraudulent header record. This would be very costly and may not be worthwhile. Furthermore, it would not be possible to download any further notes from an ATM or a bank branch.
Cost of Issuing E-Rupiah
As on end March 2017, around 201 billion pieces of notes including coins (one rupee and above) were in circulation. In that year, India’s adult population (15 years and above) was estimated to be around 916 million. If all adults hold one wallet each, the estimated size of all header records would be around 320 GB, not a very big number by any yardstick. The size of transaction database, assuming 1000 transaction for each note during its lifetime, would be around 71 petabyte or .07 Exabyte. Amazon Redshift Spectrum Query service charges $5 per Terabyte of Query. If in the extreme case we assume that all notes are transacted once every day of one year, then the cost would be around 132 million US dollar or 862 crore of Indian rupees. Taking storage cost, it would be well below the cost of printing notes that RBI incurs today.
Digital Currency and Corruption With digital currency it would be very difficult for anybody to make huge cash transaction for drug trafficking, bribing and other illegal purposes. In the Netflix original TV serial Narcos, the Columbian drug cartels are seen to carry out most of their transactions in cash. So much so, they had to store cash buried in fields. Central Bank Digital Currency would be the most effective antidote to cash mediated corruption and illegal transactions.
More on the e-Rupiah process
The following paragraphs describes the process of connecting and validating users in proposed p2p e-cash transfer.
The scenario has two users with devices – device A which will send the money (will be called as consumer hereafter) and device B which is a merchant and will receive the money.
The app will require any user to sign up first using the government issued ID card such as aadhaar card. Once the sign up is done, app will connect to RBI server and download a key pair on the phone.
Merchant will start the app and enter the amount it wants to receive.
Once the amount and details are entered the app will create a barcode of the same. At the same time, app will start a hotspot.
The consumer will start the app and scan the barcode using the send button.
The barcode shall contain basic information such as some validation message, network name (hotspot) and network key.
Using the scanned information, the consumer’s app will connect directly to the hotspot started by merchants app. All the basic network validation will be done internally.
Once the two devices are connected, the main process of validation will start.
Both devices will exchange public key of each other.
Once done, both the devices will exchange basic data in form of encrypted packet. The packet shall contain data such as user info and some other validations related data if and as necessary. The packet will be encrypted with the respective users’ public key. For example, consumer will encrypt packet using merchants’ public key.
The merchant’s device will decrypt package received from consumer’s device using its private key and verify the data.
Once verification is done, the consumer shall send the money requested by merchant and will deduct it from app’s database pending upload to RBI server.
Once the transfer is done successfully, the hotspot will be shut down by app.
