Generational Dynamics: Modern Generational Theory Generational
Dynamics
 Modern Generational Theory

 |  HOME  |  WEB LOG  |  COUNTRY STUDIES  |  COMMENT  |  FORUM  | 
 |  DOWNLOADS  |  FOURTH TURNING ARCHIVE  |  ABOUT  | 

Generational Dynamics Web Log for 13-Apr-2021
13-Apr-21 World View -- Investing in Decentralized Finance (DeFi) and Smart Contracts

Web Log - April, 2021

13-Apr-21 World View -- Investing in Decentralized Finance (DeFi) and Smart Contracts

Sabotage and fraud in DeFi and Smart Contracts

by John J. Xenakis

This morning's key headlines from GenerationalDynamics.com

Investing in Decentralized Finance (DeFi) and Smart Contracts


How Smart Contracts Work (Deccan Herald)
How Smart Contracts Work (Deccan Herald)

I've been asked about investing in the crypto-currency (Bitcoin) related technologies, Decentralized Finance (DeFi) and Smart Contracts, which use the same internet-based blockchain technology as Bitcoin.

For over a decade, crypto currencies have been the highly stylish, fashionable rock star finance technology, but lately they've been losing their glamor and lustre as compared to a newer technology, "decentralized finance" (DeFi) and "smart contracts."

It was just a few years ago that people were saying that the world was just a stone's throw away from having a universal currency (Bitcoin) that was independent of any nation. Last week, I read one analyst saying, "We are a stone’s throw away from the global financial industry running on a common software infrastructure." Well, that stone would have to land something like 20-30 or more years in the future, and if humans haven't figured out how to do it by then, then perhaps our computer overlords will do it for us.

What's happening now is that there's an explosion of financial applications and services, normally provided by banks, brokers, and other financial institution, that are now being provided on blockchain platforms as "smart contracts." There are really an unlimited number of possible apps and services -- insurance, lending, borrowing, asset management, gaming, day trading, savings, payments, billing, and so forth. Smart contracts are "self-executing," meaning that once a particular smart contract is set up, any action that would normally be taken by a human intermediary in a bank or financial institution would now be executed automatically by the smart contract.

Another way of looking at it is to compare a smart contract to workflow software that has been around since the 90s. The software is set up with a set of workflow rules, and the appropriate conditions specified by the rules are satisfied, then the workflow software sends out e-mail messages to the appropriate people, telling them to take the appropriate action.

DeFi applications are more powerful because typically they have control of crypto assets, so when the right conditions are met, the app does not send out an e-mail saying "buy a new car." Instead, it automatically issues the paperwork to buy a new car.

There are several ways to invest in DeFi technology. You can set up a financial relationship with someone else using a smart contract. Or you could invest in companies that develop these apps or offer services using this technology.

The following web site provides a pretty extensive list of companies offering such apps and services at the current time: https://defipulse.com/defi-list/

Automated processing on IBM mainframes in the 1960s

Although Decentralized Finance and Smart Contracts are a brand-new, shiny technology, there are problems and dangers that can be learned from history. Let's look at some historical examples.

Back in the 1960s, accounting systems were developed for IBM mainframe systems, and they were only a stone's throw from never needing human accountants again, according to experts.

The transaction processing systems used magnetic tapes. A typical processing run required three tapes -- an input tape of existing account records, an input tape of new transaction records, and an output tape of updated account records. The two input tapes are pre-sorted by account number so that they can be processed simultaneously in order of account. It's therefore possibe to update the accounts with only one pass through the transaction tape, writing the updated accounts to the output tape, which would be the existing accounts input tape for the next day's run.

So let's take a look at some of the issues. The most obvious one is that the mainframe might be down, so that the transaction processing run could not take place. Another issue is that mag tapes are somewhat fragile, and data could be lost.

Another possible problem is that the transaction processing software could have a bug, since all software has bugs. So if the bug affects several thousand accounts, then it's possible that a single run could result in several thousand errors caused by the bug, and they wouldn't be caught until much later.

That's when people started saying things like, "To err is human. To really screw things up takes a computer."

Intentional sabotage in automated processing

Another problem was intentional sabotage. The mag tape transaction processing that I described was subject to a very interesting form of sabotage.

Some transactions involve division of two numbers, and result in an amount with a fraction of a penny. The correct algorithm would round to the nearest penny, and the resulting amount would be used in the transaction. But one developer did something different. His software contained secret code that deducted the fractional penny from the amount, and credited it to his own account. Tens of thousands of fractions of a penny adds up to real money. He made a lot of money that way, but the consequences of what he had done were not discovered until much later.

The thing that makes this kind of sabotage possible is that managers don't understand what the programmers are doing. There was a similar problem with the financial crisis of the 2000s. The Gen-X financial engineers got their Masters Degrees in the 1990s, and applied those skills to create fraudulent synthetic securities based on subprime mortgages. Their managers in the financial institutions had no idea how they worked, except that they made lots of money, and the result was the financial crisis. In the late 2000s I was working on a government system where the lead programmer was sabotaging the code (my code, in particular). I complained repeatedly to my boss, but he refused to believe me. Eventually, the lead programmer screwed around with someone else's code, someone really important, and my manager apologized to me. This shows that the consequences of sabotage are not usually discovered until much later.

Another example was the Obamacare website Healthcare.gov. President Obama launched Obamacare on the afternoon of Oct 1, 2013, and he had no idea that the web site wasn't even working. When he announced the launch, he had no idea a disaster had unfolded several hours earlier. As I wrote in my 2015 article, massive fraud had occurred among all the consuting firms, and they propagated lies all the way up the chain. The entire White House had no idea of the disaster until it was too late. (See: "Healthcare.gov -- The greatest software development disaster in history")

So there was massive fraud in the development of Obamacare, which no one cares about since caring about Obamacare fraud is politically censored. Similarly, with tens of millions of mail-in ballots sent out last year there was massive fraud in the 2020 election that no one cares about, since caring about fraud in the 2020 election is politically censored.

The reason for mentioning all this is that the DeFi technology will be a huge target for sabotage and fraud, and the people benefiting from the fraud may want it censored. This concern is being politically censored because the major beneficiaries -- Silicon Valley, the Chinese, the Democrats, hedge funds -- don't want it discussed.

Sabotage and fraud in DeFi and Smart Contracts

Blockchain technology has this magical, mystical reputation as being incorruptible -- open source, "tamper-proof data," transparency, permissionless access, etc. Obamacare had the same magical, mystical reputation, and the amount of fraud was massive. The mainstream media didn't want to see it, because it was censored. The housing bubble of the early-mid 2000s was obvious (I was writing about it, Alan Greenspan was talking about it), but mainstream media didn't want to see it until 2009, when millions of people had lost their homes or went bankrupt. The mainstream media don't want to see the massive voter fraud in the 2020 election.

So there's no doubt that as DeFi grows, there will be lots of bugs and plenty of fraud, sabotage and corruption. This will be done at technical levels, and managers won't even know that it's going on until there are severe consequences and it's too late. In particular, it's absolutely certain that China's military is already developing tools to hack into DeFi applications, to control them.

There's another issue that's analogous to the 1960s IBM mainframe being unavailable, and this applies to all blockchain technologies: There may be a crisis (flood, hurricane, Chinese sabotage, malware, war), and the internet could become unavailable, or large numbers of servers along the blockchain could be destroyed.

Due diligence in DeFi and Smart Contract investments

So you can invest in DeFi at any of several levels. You can invest in companies developing core low-level technologies, or in companies developing mid-level API platforms, or in companies developing the top level apps that people and corporations actually use in their business. Or, you could invest by using one of the apps for its business relationships. The investment at any of these levels would be subject to the same concerns that I've raised.

So how do you do due diligence on such an investment? I believe that the biggest advantage of DeFi is also its biggest disadvantage and biggest risk -- the "self-executing" feature of "smart contracts."

Here's the investopedia definition of Smart Contracts:

A smart contract is a self-executing contract with the terms of the agreement between buyer and seller being directly written into lines of code. The code and the agreements contained therein exist across a distributed, decentralized blockchain network. The code controls the execution, and transactions are trackable and irreversible.

Smart contracts permit trusted transactions and agreements to be carried out among disparate, anonymous parties without the need for a central authority, legal system, or external enforcement mechanism.

In other words, a "smart contract" is just a software program. It will also certainly contain bugs -- because all software programs contain bugs -- and it will be subjected to sabotage, malware and hacking. And since the whole point of smart contracts is that they're "self-executing," without human involvement, and since management won't understand what's going on anyway, the bugs and sabotage won't be detected until a disaster has occurred.

Perhaps a good solution is to require "human oversight" of any smart contract. That is, if a self-executing smart contrast tells you "kill your mother or pay a large fine" (and this isn't as far-fetched as it might seem, given my experience with software developers in the last 20 years), then there has to be a way for a human being on each side of the smart contract to review the self-executing action, and override it under the right circumstances.

This means that every party to a "smart contract" should have, as a backup, a printout or a pdf of a written contract that can be referenced if the internet goes down, or if there's a failure in or sabotage of the smart contract.

Unfortunately, this will only work at a small scale. DeFi applications are going to become larger and more complex, with a single app consisting of hundreds or thousands of interlocking smart contracts, and these will really be a disaster waiting to happen. But they're coming anyway. Watch for the buzzword: DAO (distributed autonomous organization), an entire business which is just a collection of smart contracts.

Sources:

Related Articles:

(Comments: For reader comments, questions and discussion, see the Generational Dynamics World View News thread of the Generational Dynamics forum. Comments may be posted anonymously.) (13-Apr-2021) Permanent Link
Receive daily World View columns by e-mail
Donate to Generational Dynamics via PayPal

Web Log Pages

Current Web Log

Web Log Summary - 2021
Web Log Summary - 2020
Web Log Summary - 2019
Web Log Summary - 2018
Web Log Summary - 2017
Web Log Summary - 2016
Web Log Summary - 2015
Web Log Summary - 2014
Web Log Summary - 2013
Web Log Summary - 2012
Web Log Summary - 2011
Web Log Summary - 2010
Web Log Summary - 2009
Web Log Summary - 2008
Web Log Summary - 2007
Web Log Summary - 2006
Web Log Summary - 2005
Web Log Summary - 2004

Web Log - December, 2021
Web Log - November, 2021
Web Log - October, 2021
Web Log - September, 2021
Web Log - August, 2021
Web Log - July, 2021
Web Log - June, 2021
Web Log - May, 2021
Web Log - April, 2021
Web Log - March, 2021
Web Log - February, 2021
Web Log - January, 2021
Web Log - December, 2020
Web Log - November, 2020
Web Log - October, 2020
Web Log - September, 2020
Web Log - August, 2020
Web Log - July, 2020
Web Log - June, 2020
Web Log - May, 2020
Web Log - April, 2020
Web Log - March, 2020
Web Log - February, 2020
Web Log - January, 2020
Web Log - December, 2019
Web Log - November, 2019
Web Log - October, 2019
Web Log - September, 2019
Web Log - August, 2019
Web Log - July, 2019
Web Log - June, 2019
Web Log - May, 2019
Web Log - April, 2019
Web Log - March, 2019
Web Log - February, 2019
Web Log - January, 2019
Web Log - December, 2018
Web Log - November, 2018
Web Log - October, 2018
Web Log - September, 2018
Web Log - August, 2018
Web Log - July, 2018
Web Log - June, 2018
Web Log - May, 2018
Web Log - April, 2018
Web Log - March, 2018
Web Log - February, 2018
Web Log - January, 2018
Web Log - December, 2017
Web Log - November, 2017
Web Log - October, 2017
Web Log - September, 2017
Web Log - August, 2017
Web Log - July, 2017
Web Log - June, 2017
Web Log - May, 2017
Web Log - April, 2017
Web Log - March, 2017
Web Log - February, 2017
Web Log - January, 2017
Web Log - December, 2016
Web Log - November, 2016
Web Log - October, 2016
Web Log - September, 2016
Web Log - August, 2016
Web Log - July, 2016
Web Log - June, 2016
Web Log - May, 2016
Web Log - April, 2016
Web Log - March, 2016
Web Log - February, 2016
Web Log - January, 2016
Web Log - December, 2015
Web Log - November, 2015
Web Log - October, 2015
Web Log - September, 2015
Web Log - August, 2015
Web Log - July, 2015
Web Log - June, 2015
Web Log - May, 2015
Web Log - April, 2015
Web Log - March, 2015
Web Log - February, 2015
Web Log - January, 2015
Web Log - December, 2014
Web Log - November, 2014
Web Log - October, 2014
Web Log - September, 2014
Web Log - August, 2014
Web Log - July, 2014
Web Log - June, 2014
Web Log - May, 2014
Web Log - April, 2014
Web Log - March, 2014
Web Log - February, 2014
Web Log - January, 2014
Web Log - December, 2013
Web Log - November, 2013
Web Log - October, 2013
Web Log - September, 2013
Web Log - August, 2013
Web Log - July, 2013
Web Log - June, 2013
Web Log - May, 2013
Web Log - April, 2013
Web Log - March, 2013
Web Log - February, 2013
Web Log - January, 2013
Web Log - December, 2012
Web Log - November, 2012
Web Log - October, 2012
Web Log - September, 2012
Web Log - August, 2012
Web Log - July, 2012
Web Log - June, 2012
Web Log - May, 2012
Web Log - April, 2012
Web Log - March, 2012
Web Log - February, 2012
Web Log - January, 2012
Web Log - December, 2011
Web Log - November, 2011
Web Log - October, 2011
Web Log - September, 2011
Web Log - August, 2011
Web Log - July, 2011
Web Log - June, 2011
Web Log - May, 2011
Web Log - April, 2011
Web Log - March, 2011
Web Log - February, 2011
Web Log - January, 2011
Web Log - December, 2010
Web Log - November, 2010
Web Log - October, 2010
Web Log - September, 2010
Web Log - August, 2010
Web Log - July, 2010
Web Log - June, 2010
Web Log - May, 2010
Web Log - April, 2010
Web Log - March, 2010
Web Log - February, 2010
Web Log - January, 2010
Web Log - December, 2009
Web Log - November, 2009
Web Log - October, 2009
Web Log - September, 2009
Web Log - August, 2009
Web Log - July, 2009
Web Log - June, 2009
Web Log - May, 2009
Web Log - April, 2009
Web Log - March, 2009
Web Log - February, 2009
Web Log - January, 2009
Web Log - December, 2008
Web Log - November, 2008
Web Log - October, 2008
Web Log - September, 2008
Web Log - August, 2008
Web Log - July, 2008
Web Log - June, 2008
Web Log - May, 2008
Web Log - April, 2008
Web Log - March, 2008
Web Log - February, 2008
Web Log - January, 2008
Web Log - December, 2007
Web Log - November, 2007
Web Log - October, 2007
Web Log - September, 2007
Web Log - August, 2007
Web Log - July, 2007
Web Log - June, 2007
Web Log - May, 2007
Web Log - April, 2007
Web Log - March, 2007
Web Log - February, 2007
Web Log - January, 2007
Web Log - December, 2006
Web Log - November, 2006
Web Log - October, 2006
Web Log - September, 2006
Web Log - August, 2006
Web Log - July, 2006
Web Log - June, 2006
Web Log - May, 2006
Web Log - April, 2006
Web Log - March, 2006
Web Log - February, 2006
Web Log - January, 2006
Web Log - December, 2005
Web Log - November, 2005
Web Log - October, 2005
Web Log - September, 2005
Web Log - August, 2005
Web Log - July, 2005
Web Log - June, 2005
Web Log - May, 2005
Web Log - April, 2005
Web Log - March, 2005
Web Log - February, 2005
Web Log - January, 2005
Web Log - December, 2004
Web Log - November, 2004
Web Log - October, 2004
Web Log - September, 2004
Web Log - August, 2004
Web Log - July, 2004
Web Log - June, 2004


Copyright © 2002-2021 by John J. Xenakis.