In July, the Telecom Regulatory Authority of India (TRAI) put into place a new regulation to deal with spam phone calls — the Telecom Commercial Communication Customer Preference Regulations, 2018.
The regulation turns out to mandate storing your customer complaints in a “distributed ledger” that runs “smart contracts.”
A distributed ledger — whatever that specifically means — will store customers’ phone call preferences. This will ensure the data is centrally accessible — but only to registered telemarketers. (Who, I’m sure, will never abuse it or anything.) Users can revoke consent at any time.
As far as I can tell, this is the first case of a government requiring the use of a blockchain for a particular task.
Microsoft and Tech Mahindra have already started on a solution — running on Azure, of course. It’s not clear what blockchain software they’ll use.
The state of Enterprise Blockchain
The problem with blockchain for business use is a glaring lack of production use cases.
Blockchain has been hyped as the next big thing since 2014. The world is drowning in blockchain white papers, all describing the astounding future, and not the rather less astounding present.
Every consultancy is looking to blockchain as a source of billable hours — IBM in particular has been flat-out with press releases and pilot programmes, and are directly responsible for the majority of the press coverage of exciting new blockchain initiatives.
But there’s very little to show for it all. Nothing has advanced since chapter 11 of Attack of the 50 Foot Blockchain came out — we see the same promises, from the same people, with the same lack of magical results.
The problem is that “blockchain” is a particular package of hype — rather than any specific technology. Perhaps the actual technology contains a 1979-model Merkle tree. The problem, as Angus Champion de Crespigny puts it, is that:
almost every proposed blockchain solution could be achieved using upgraded, legacy technology. Consequently, it assumes that such a solution could be implemented at a cheaper cost in a faster timeline because they are using a different type of data structure.
Maybe your use case really does need a slow but very robust distributed database — but it probably doesn’t.
But there’s a saying in computer networking — “With sufficient thrust, pigs fly just fine.” So my prediction for the future is that we’ll see systems that sort of work — but which use some blockchain-descended thing as the database, for bad reasons.
And there’s a time-honoured way for a company to get its technology adopted — get it written into legislation! Or, better yet, a regulation — then it’s less susceptible to democratic oversight.
TRAI’s blockchain specification in detail
TRAI’s press release lists amongst the “salient features of the regulation”:
a) Adoption of Distributed Ledger Technology (or blockchain) as the RegTech to ensure regulatory compliance while allowing innovation in the market.
2. (j) “Consensus” means the concurrence among the participants on a distributed ledger to record an irrevocable data value, which is cryptographically secured;
2. (w) “Distributed Ledger Technologies (DLT)” means a set of technological solutions that enables a single, sequenced, standardized and cryptographically-secured record of activities to be safely distributed to, and acted upon, by a network of varied participants and their
(i) database can be spread across multiple sites or institutions;
(ii) records are stored one after the other in a continuous ledger and can only be added when the participants reach a consensus;
2. (ag) “Immutable” means data added to the distributed ledger after achieving consensus, which thereafter is unchangeable, secure and preserved for the life of the ledger;
2. (ao) “Permissioned DLT networks” means those DLT networks where participants in the process are preselected and addition of new record on the ledger is checked by a limited consensus process using a digital signature;
2. (at) “Private DLT networks” means those DLT networks where visibility is restricted to a subset of users;
2. (bk) “Smart contract” means a functionality of intelligent and programmable code which can execute pre-determined commands or business rules set to pre-check regulatory compliance without further human intervention and suitable for DLT system to create a digital agreement, with cryptographic certainty that the agreement has been honored in the ledgers, databases or accounts of all parties to the agreement;
These are invoked in sections 12 to 14:
12. Access Providers shall deploy, maintain and operate a system, by themselves or through delegation, to ensure that requisite functions are performed in a non-repudiable and immutable manner: – […]
13. Access Providers shall adopt Distributed Ledger Technology (DLT) with permissioned and private DLT networks for implementation of the system, functions and processes as prescribed in Code(s) of Practice:
(1) to ensure that all necessary regulatory pre-checks are carried out for sending Commercial Communication;
(2) to operate smart contracts among entities for effectively controlling the flow of Commercial Communication;
14. Access Providers may authorise one or more DLT network operators, as deemed fit, to provide technology solution(s) to all entities to carry out the functions as provided for in these regulations.
Various “Distributed Ledgers” are defined, which in any ordinary regulation would be “databases.”
So what TRAI require is a series of closed, permissioned blockchain-ish distributed ledgers, that will process data using smart contracts right there on the blockchain.
Initial customer complaint structures were to be in place by 18 August 2018 —30 days after 19 July, when the regulation was gazetted. Sections 13 and 14 must be implemented by 17 October 2018 (90 days); Section 12 by 16 November 2018 (120 days); and the entire regulation by 16 December 2018 (150 days).
How did “distributed ledgers” get into the regulation?
TRAI’s Consultation Paper on Unsolicited Commercial Communication (14 September 2017) doesn’t mention “blockchain,” “distributed ledger” or even “DLT” — though it uses the word “distributed” a lot.
This paper got 27 comments, including responses from both industry and the general public. Two of the comments include the word “blockchain”:
- Prashant Shukla, National Technology Officer at Microsoft India — “Regarding operating agency, a single agency should provide the platform infrastructure, e.g., cloud and/or blockchain, database, etc.”
- IBM Global Services — no mention of blockchains, but one author of the response is “Blockchain Offerings and Engagement Leader India/South Asia” and another is “Architect – Blockchain and Cloud Solutions.”
No-one else mentions blockchains or distributed ledgers — but they somehow made their way into the regulation during ensuing discussions. The Explanatory Notes credit the Open House Discussion (OHD) on 15 December 2017:
5.2.1. iv. Many stakeholders supported the idea of using centralized cloud-based complaint redressal system. During OHD, some stakeholders suggested that it is technically possible to maintain all complaint related information through either a centralized database or through blockchain technology. Using this system, as soon as, a complaint is registered it should be also possible to track the history of a UCC call or SMS, its content and whether it should have been sent in the first place.
The word “intelligent” in the definition of “smart contract” in part 2(bk) of the regulation is part of plans to use machine learning for spam detection — one of the consultation questions was, literally:
Q24. How Artificial Intelligence (AI) can be used to improve performance of signature solution and detect newer UCC messages created by tweaking the content? Please give your suggestions with reasons.
Artificial Intelligence, on the Blockchain! This suggests someone inside TRAI is suffering a serious case of buzzwords. AI didn’t make it into the eventual regulation, though the explanatory notes talk about it at length.
No really, why would you do this?
The explanatory memorandum reads like a blockchain-vendor-written paean to DLT.
The justification for requiring DLT is on pages 107 to 109. Here’s how TRAI reassures the world that the technology is up to scratch:
The cryptographic tools used in DLT systems have a solid mathematical background and are military grade technologies.
The same Linux Foundation which develops the operating system for enterprise computing system is behind the Hyperledger DLT. A 100 year old company, like IBM has bet billions of USD in developing its product offering in this segment. Enterprise solution providers like Oracle, SAP and Microsoft all have their own DLT offerings.
There are thousands of academic papers published in the last few years that related to distributed ledgers.
The total value of bitcoins has remained over 100 billion USD in the recent past. Ethereum’s market cap is half as much, with several other currencies in the billions of dollars range. There’s every reason for hackers to attack these systems, which have withstood their assault.
Therefore, it is safe to say that the technologies are well-proven, even though their new uses are just beginning to emerge.
I won’t take the time to take apart every problem in the above — but literally every factual claim made here is misunderstood, or irrelevant to the question “what would be good technology for a spam complaints database?” This is the quality of blockchain argumentation that led me to write a book dismantling it.
Is this a good idea?
No, not really. Rather than specifying what must be achieved and the bureaucratic workflows they require, TRAI have specified deep implementation details — on the basis of unrealisable hype.
They’ve specified the precise kind of database to use. They’ve even specified that the programming to run the database be implemented as database triggers — which is what smart contracts really are — rather than as separate programs.
(Read this article on why database triggers should be avoided — they’re bad for obscurity, complexity and maintainability. If you’ve ever been bitten by smart contract programming, lots of this will seem eerily familiar.)
This will not result in good software engineering. But the resulting system will definitely generate lots of consultant hours just for maintenance.
There’s probably no hope of fighting this terrible idea
Telephone company lobbyists are the only people providing pushback. From LiveMint:
The telecom industry, however, is worried that there has been no cost-benefit analysis of this regulation at a time when the industry is facing financial stress.
“We remain concerned about whether the regulation addresses the issues of unsolicited calls origination from unregistered tele-marketers. We are reviewing the regulation to see if this is adequately addressed,” said Rajan Mathews, director general of Cellular Operators Association of India (COAI).
“The time frame for implementing, especially given the requirement to implement distributed ledger technology, which has not been implemented by any other regulator, appears too stringent and difficult to achieve,” said Mathews.
Apart from all else — there’s literally nothing this regulation achieves that a conventional centralised database wouldn’t achieve. With the programs written and maintained separately from the data store.
But I fully expect this to proceed — and the Unsolicited Commercial Calls Complaint System will be a slow and clunky distributed database cluster, with all the programming implemented as database triggers.
It won’t quite do the expected job very well. It will accumulate assorted bodges, patches and gaffer tape with time. It’ll rack up a ton of consultant hours for maintenance. Everyone who has to use it will hate it with every fibre of their being.
I predict a later amendment wherein “distributed ledger” is quietly replaced with “database,” and “smart contract” with “program” — so that the regulation specifies what to do, not what to do it with.
But the Unsolicited Commercial Calls Complaint System will still be listed in blockchain studies, books, and the all-important white papers, until the end of time — as an example everyone should emulate. Call Microsoft today!
Thanks to MetaDev for the tip — the first person to notice why this was important — and Amy Castor for editing.
Your subscriptions keep this site going. Sign up today!