An analysis of the 2018 crypto market collapse and the following crypto winter

Anyone who has been dealing with blockchain and cryptocurrency technologies for a couple of years may still remember the market crash in 2018 and the one and a half year crypto winter that followed. The situation is well reflected in the bitcoin exchange rate shown in the figure below. Of course, the volume of the total kritpo and blockchain market is much larger than the current price of Bitcoin. However, since Bitcoin is used in most places as an interface crypto currency to enter and exit the crypto world, the chart below also shows the general cryptoconditions in 2018 quite well.

The Bitcoin price from 2014 to nowadays

First of all, it is important to note that we believe the blockchain is basically a transformative exponential technology. Exponential technologies have been evolving slowly for quite some time, and then, after a while, reaching their exponential stage, they are being used at an ever-accelerating rate (Figure 2). One of the best examples of this is artificial intelligence, and machine learning. If we consider only the backpropagation algorithm in the narrower sense as the birth of the area, the area has been in existence for more than 45 years. Nevertheless, we are not yet there for self-driving cars to travel on the roads on a daily basis, but it is conceivable that we will reach it within 5-10 years. This means 50-60 years until the technology reaches its true exponential stage, where it will actually result in radical innovations. Blockchain algorithms have been around for about 10 years. We believe that this technology will reach its exponential stage faster than artificial intelligence, but it may still take 10 to 20 years.

Life cycle of an exponential technology

On the other hand, general human thinking tends to underestimate the impact of a technology, especially if it is exponential: we tend to overestimate the effects in the short run, while we underestimate the effects in the long run. This is probably due to the structure of the human neocortex, which specializes in pattern recognition that is basically close to linear, so it also tries to approach an exponential change linearly. From another approach, the high level of media attention in the area caused a problem. With fundamental long-term technological change, the media tends to go to extremes: for example, to advertise something as a world-saving technology for half a year, and then, if it doesn’t change the world in six months, to declare it unusable.

Another feature of blockchain technology is that it is an infrastructure financial technology. In this respect, it is somewhat different from a simple fintech application that tries to save the world with a fancy mobile app and some business logic. It is more like classic infrastructure technologies such as the highway from which a few thousand kilometers have to be built in order for other applications to run on it, such as cars, trucks, motorcycles, and so on.

In 2015-16, a new application related to blockchain technology, called token sales, appeared, the earliest form of which is ICO (Initial Coin Offering, Figure 3). Token sales as a technology has fundamentally liberalized the investment market, both on the demand and supply side:

- On the demand side, it provided a new opportunity for any investor to acquire a stake in a startup starting up anywhere in the world on a basis of up to a few dollars.

- On the supply side, it provided an opportunity for a startup to raise funds from anywhere in the world, even in crowdfunding style in the form of individual investments of a few dollars.

In this sense, the problems arising from the short-term perception of the aforementioned exponential technologies have intensified even more than usual. Simply put, the blockchain is a technology that can implement its own financing as well.

Number of ICO-s around 2018

The biggest problem with ICO technology has been the complete lack of regulation in specific business implementations (and in some places this is not fully clarified today). This did not cause too much of a problem in the initial period of 2015-16, as it was mainly serious professional projects that carried out token sales, and since the technology was not very well known, mainly professional investors could be found in the market. By 2018, however, this has changed as a result of both the press publicity and the incredible exchange rate gains of the first successful projects:

- From the investor's point of view, investors who were not so much interested in technology or in the long-term success of a platform, but only in short-term exchange rate gains, began to dominate.

- As it was seen that there is quite a lot of “free money” in the market, startups have started to raise funds irresponsibly. Of course, there were also teams that did some serious project and teams that didn’t want to do anything just put away the funding they collected. However, most of the attempts were somewhere in between: since the funding was free, many tried to implement a project without worrying too much about whether there was or would be a specific market demand for it.

Overall, we believe that the factors mentioned above are:

- the beginning of the technological curve

- increased media attention and unrealistic expectations

- a liberalized investment market and "free money" without any regulation or control

they themselves have created an unsustainable market, inevitably creating an investment bubble.

The final push for a concrete market collapse was caused by a total regulatory fire that hit the ICO market in early 2018, but without it, the aforementioned scheme would probably not have been sustainable for a long time. The market crash was followed by a one and a half year crypto winter, causing significant difficulties for downsized and blockchain companies that incorrectly assessed market demand for their products, either because they paid enough attention to it or because the idea they came up with was too “early”. . During this period, it was very difficult to attract new funding from token sales, but classic funding was not always given to such ideas, so most of these startups failed.

The end of the crypto winter began roughly a year ago, when serious and at times conservative institutions began to enter the krito and blockchain market. Perhaps the first was Facebook, which, although it had banned posts and ads in this direction for years, still came up with its own blockchain and crypto platform. Facebook was followed by various institutionalized and controlled implementations by Swiss banks and, from 2020, by some German banks and the ICO, such as IEO (Initial Exchange Offering) or SAFT (Simple Agreement for Future Tokens), with moderate success for the time being. Last but not least, the European Union is testing its own blockchain platform, and J.P. Morgan, calling Bitcoin a scam for years, is launching its own Bitcoin-based investment services.

We might say a little biasedly that the future of technology is not in question, but individual business implementations and specific market developments already do. The emergence of enterprise-level institutions in the market does not preclude the emergence of similar bubbles at all, and in some cases they may even be much larger than in 2018, given that the capitalization of the entire crypto market is still far below the size of the dotcom bubble.

Dotcom bubble and the crypto hype

An Austrian economical interpretation for the last 3 years of Blockchain

The Austrian school of economics provide a pretty good interpretation what was happening in the Blockchain space in the last couple of years. The ICO and token sales hype for three years caused a lot of investment coming into the space totally uncoordinated. The reason for this money pump was not only a speculation in the technology but the fact that the token sales technology liberated and disrupted the whole funding a investment industry. Due to regulation issues the investment source  was basically cut and a lot of company found itself in the situation of having the invested money but not capable to build up a system that can be sold to any customers. The last two years of market and technology free fall was among the others a cause that these companies not able to find real market for their products were slowly liquidated. 

Notes on the future of token standards

Next generation of token standards will define cross-chain tokens, distributing efficiently the functionality between several blockchains or perhaps having even off-chain functionality. This will extend tokenomics and token based business models in the direction of multiply blockchains, or even blockchain and off-chain solutions. From a technological point of view, there is already several initiatives for realizing such a services, like Plazma, Loom network, Polkadot or Cosmos. 

Notes on the skillset of blockchain architect

It is a common misconception that every standard software architect can become a blockchain architect with the help of a couple of weeks intensive education. This is actually far from the reality. Although designing a decentralized system on the blockchain requires some components and ideas from the world of the classical software architectures, blockchain system engineering requires more strongly the skills to design and implement complex cryptoeconmical systems. Among the others, the following fields must be covered:

- Designing for trust model

- Scaling the architecture based on fine-tuning the consensus or implementing off-chain scaling to the required trust model.

- Economically designing a one or more token architecture, like for stable usage tokens. 

- Designing crypto and privacy models, like with increased privacy as zero knowledge proofs or secure multiparty protocols.

As a sum up, a blockchain architect should have its competence only around one third from a software architect. The rest should be cryptography, pure economics, and of course a lot of blockchain specific knowledge.  

Notes on Ethereum WASM

Ethereum WASM is on the horizon, providing a more stable, flexible and faster programming environment. However introducing the technology might bring a couple of unexpected results. The problem is that with the help of WASM there will be many other languages available for Ethereum programming, apart from Solidity. The real difficulty in Blockchain programming is however not the programming language knowledge, but actually the mindset. As Ethereum smart contracts store a huge amount of money on a public blockchain and actually the deployed code is pretty much immutable, developing such a code requires special considerations. Instead of Agile or DevOps methodologies, defensive programming, formal versification and correct by construction tools should be used. For those who has actually never taken part in mission critical system development, these methodologies are new. The result will be that many software developers with WASM compatible languages will start smart contract development, which will cause again a huge amount of buggy software and a lot of hacks on the public chain. That will result that the general perception of the chain security will be again pretty low.   

Notes on AI and system complexitiy

Our IT systems, including software and hardware components are getting so complex that we need AI support for monitoring, maintenance, operation or even for development. 

However that AI support will not make our systems simpler and it does not help people to understand that systems better either. So on a long rung it will result in IT systems that can not be operated based on purely biological intelligence anymore, only with the help of AI, or purely with AI.

Notes on DevOps, agile development and maintenance cost

Surprisingly, techniques like DevOps and Agile did not actually make the software industry easier or user-friendlier. The facts of automated and regular software deliveries made certainly possible to adapt the software more frequently on the user requirements, however they made the maintenance and operation of the software more difficult. Simply put running a software that has daily delivery is not easy, but the biggest problem is that most of the software components do not run individually, but with the help of docent or hundreds further software and software modules together. If you consider that each of these software can be released on a daily basis and usually documentation is the last priority of these systems, it surely results an enormous cost in maintenance, if it is possible at all. 

On solution might be the appearance of the AI based software configuration and maitainance systems. I mean from a pure theoretical point of view, there might be the idea of making our software systems simpler, but to be realistic, that is not going to happen. 

Notes on blockchain technology and market segmentation

Having a lot of competing blockchain platforms it is pretty much difficult to identify which platform to use for a certain use-case. The following directions can be considered:

- B2B market: typically consortium blockchain platforms, like Hyperledger. 

- Inter-banking B2B market: here special platforms need to be considered that can satisfy the requirements of the banking sector, like Corda or Ripple. 

- B2C market: here both consortium and public networks can be used. If the users could have a direct access to the blockchain platform than typically public networks, if the technological details are hidden, than consortium ones. 

- C2C market: on a fully decentralized customer to customer market, only public platforms can be used. 

Hashgraph censorship

The Hashgraph technology is aimed to be a fair censorship resistant, byzantine fault tolerant technology having a public network as well, where theoretically there is no need to ask a permission form the company Swilrds or from consortium members of Hedera and the network will eventually as public as for instance Ethereum. Recent achievements  suggest however that the situation wont't be so clean and simple. The recent direction is to censor social media appearance that do not match into certain corporate policies, certainly the official names are "quality improvement" and "policy compliance", but actually most dictatorial governments have the same names censoring the local social media for filtering out the content that they do not like. Such a censorship raises some serious ethical questions even if it is carried out by a corporation, but it is surely not acceptable at an open distributed ledger platform. Censorship of the social media will very fast result in the censoring of individual transactions and decentralized applications on the platform. 

So, let we see how Hashgraph can censor your transactions:

- The easiest way is blocking incoming transaction at peer level, simply not including into the Hashgraph by dropping the incoming transaction. For that actually it is not necessary to modify the Hedera software itself, incoming transactions can be filtered out on the operation system or on the network level, like filtering out certain transactions from a certain IP address. Certainly, a customer will eventually recognize if a transaction is dropped and will resend, possibly eventual to another node. As a consequence censoring at peer level works theoretically only if all of the peers drop the transaction. However, from a practical point of view a customer will probably give up including the transaction in the Hashgraph after a certain number of attempts. On the other hand, resending too many, like 20, times is probably not acceptable for most of the applications and use cases, so from a practical point of view blocking transactions at several peers, like in a geographical area can make certain applications not-usable, even if from a theoretical point of the transaction is 100% blocked.

-   A similar censorship attack is to introducing a random delay for incoming transaction at the peer level. It is again something that can be carried out without modifying the official source code. If a transaction is 100% blocked, the customer will recognize it and resend it, possibly for another node. However if the transaction only delayed randomly it is more difficult to recognize. As a couple of minutes or hours random delay in the transaction processing is not acceptable for most of the decentralized applications, this can be an efficient denial of service attack for most of the distributed apps even if it is realized by one or two nodes.    

- As the transaction is included in an event, it is propagated with a gossip protocol throughout the network. You can use similar techniques here as well, like blocking event propagation that contains a certain transaction, or delaying and random blocking events containing a transaction. As the peers are connected with TSL, such an attack is difficult to realize by an external attacker, however it can be easily realized by the operators of the nodes as a censorship attack, again without modifying the code itself, implementing everything on the operation system or network side. Blocking a transaction or event will be efficient if more than one third will actively block, however at random delaying a much smaller number of number of censors could effectively make a DApp unusable. 

- There might be some further possible censorship possibilities at the state level and at the point as a transaction is applied to the state. As the implementation details are not known here, such attack vectors need further investigation.

- Last but not least, Hedera is basically a consortium that controls the code. It is pretty much an open question how the software upgrade mechanism will work what is sure that if the consortium votes against your transactions or DApp, a new software version can be delivered that will efficiently block your transactions and DApps. In practice, this process might be accelerated, as upgrading a new software version can be a slow process. I would probably create a configurable element in the software code itself where operators can individually set the blacklisted applications. It probably provides a further censorship attack vector.   

Opening business processes via triple entry accounting and blockchain

Blockchain and triple entry accounting makes it possible to create business processes that are easier to audit or verify. Let we imagine for example the following use-case. A company creates a balance about the activities of the company at the end of the year, and based on that result pays dividend to the stock holders. However accounting only at the end of the year might be not so reliable and offers a lot of place for misuse. However, the process can be more transparent if we register the result of the company on the blockchain on a daily basis, like the costs and revenue, or some relevant business related information. Although there is the possibility for misuse and gaming in such a situation as well, however it is much more difficult. 

Certainly, no company would like that such business related information is visible on the blockchain on a daily basis for the competitors. However what might be done is to use a kind of a proof of existence system and for example registering the hash of the relevant information on the blockchain on a daily basis. At the end of the years, daily information related to the hashes can be published which makes the yearly performance of the company more reliable. Another solution might be to use some kind of a more advance cryptographic scheme, like zero knowledge proofs or functional encryption.   

The new divide of the information society

There will be a new divine in the information society between people producing information and people consuming information. As information can be simpler and more automatically produced every day, like with the help of massive online courses, chat bots, and different online platforms, it will be more and more information produced by less and less people.

Services will become more and more automated, meaning that more customer service will be carried out by bots or robots, resulting a cost factor saving in the employees and enabling fully automated decentralized companies. As an average customer it will be more and more complicated to fight through the bureaucracy of  bots and robots and get to a "living" person.

Memory of a blockchain and multi-hash Blockchain

Memory of a blockchain is simple the number of blocks, pieces of information, transactions or state variables that are hashed together and are represented in the final hash pointers. Regarding the final hash pointer of a standard blockchain solution, it has infinite memory, regarding that the information is hashed back to the genesis block. However this should not always be the case, certainly an infinite memory provides a better security, however after a certain point, it seems to be irrelevant if we keep the history only for a couple of years or to forever. In this sense, it makes sense imagine blockchain platforms that have less than infinite memory. 

IOU debt graphs and trust lines on the blockchain

We were briefly brainstormed how IOU debt network can be represented on the blockchain and how it can be embedded into a mining process in the previous two blogs:  debt graph and mining. We can extend the model with trust lines as well, meaning that the IOU network can be optimized and a new IOU can be issued only if there is an existing trust line between two participants. Trust line can be represented again with a matrix T, where

T[i,j] = 0 if participant i does not trust participant j and
T[i,j] = 1 if participant i trusts participant j

It is an open question what further properties shall a trust matrix have. As an example, it might be reflexive and or transitive:

reflexive: if T[i,j] = 1 then T[j,i] =1 as well
transitive: if T[i,j] = 1 and T[j,k] = 1 then T[i,k] = 1

Having a trust matrix means that there is the possibility to issue a credit or to optimize a relationship between i an j if and only if T[i,j] = 1. Certainly, it is pretty much an open question what should happen if a trust line can be deleted as well.   

Optimizing IOU debts and mining

As we have seen in the previous blog, debt optimization is practically proposing a new directed graph structure in a way that balances of the individual accounts do not change. The easiest way to represent the debt graph is the adjacency matrix, where each A[i,j] element represents the the IOU contract from i to j. Based on that representation, we can formally define the balances of an account as well: 

Balance i = Sum j (A[i,j]) - Sum k (A[k,i])

Considering a general mining process, there can be several {IT1, IT2, ... ITN} transactions issuing new IOU-s each transaction is signed by its creator. On top, there is a set of {OT1, OT2, ... OTN} optimization transactions either signed by trusted optimizer nodes, or by nobody. Both sets of transactions are in one two separate transactions pools. The idea of mining is to find a subsets of {IT1, IT2, ... ITK} and {OT1, OT2, ... OTK} transactions in a way that for all account balances, the change is initiated by only by the issuing transactions, meaning that:

Balance i (new) = Balance i (old) + Sum j (OT[i,j]) - Sum k (OT[k,i]), where OT is a matrix built up by the {OT1, OT2, ... OTK} transactions. Certainly, the complexity of the network has to be reduced due to the optimization transactions, it is an open question how it can be measured. 

Based on these definitions, there can be a one shot or a two round transaction process: 

- if we imagine two rounds, the first round is a purely optimization round as the second one is a classical transaction round. 

- In a one shot process, both optimization and the new transactions take place. 

  

Optimizing IOU debt graphs on the blockchain

At optimizing an IOU debt graph on the blockchain we should consider the following properties:

- Issuing a new IOU debt must be associated with a digital identity. I should be able to issue a new IOU if I can sign with my private key that I am the issuer of the given identity. 

- There should be a balance for each identity on the blockchain accumulating the numbers how much do I own for someone and how much am I owned by someone. The balance can be changed only if someone creates a new IOU requires digital signatures. 

- The IOU network can be optimized either by everyone or by special optimizer roles. Network optimization can be executed only in a way that non of the account balances changes.

- The effect of the network optimization should be a decreased complexity of the graph, which can be manifested for example as the amount of edges of the depth graph, or the edges weighted by the debt amount. 

- The decreased complexity should be incentivezed, the increased complexity should not be allowed.  - The optimization should not be a totally independent round, optimization should run parallel and consistent with the issuance of new debt.

- It is an open question of a debt can be transferred or traded explicitly without the optimization mechanism.   

Blockchain solutions and operational cost structure

At designing a solution on the top of the blockchain requires always special considerations regarding costs, because of the transaction cost of most of the DLT platforms. The classical use-case is always the fully decentralized model, where the end-users communicating with the platform pay the transaction cost explicitly on their own. However there are sometimes requirements that would differ from this classical situation: 

- One way can be that a company or provider would like to offer services on the blockchain and want to take over the transaction fee of the end-user. In this use-case, the easiest way is to add the customer accounts to a pool of customers and monitor have a certain budget which can be stored in a smart contract for certain operation to be paid automatically. If this budget will reach a certain level because of too much expenditure, it has to be renewed. 

-   Another model is to innate some kind of a transaction autocratically, certainly, it is not possible directly from a third party, however there is a chance to initiate such a behavior from a trusted or semi-trusted third party. However, in this scenario as well, the accumulated transaction fee must be paid by the semi trusted-third party, so appears as a kind of operational cost. 

The aggregated transaction fee can be estimated in these situations as the average number of transactions to be executed times the average transition fee and appears as an operational cost of the system. The use-cases must be carefully analyzed as the operational cost in certain situations can enormous.

Estimating the cost of a Blockchain project

Estimating the cost of a blockchain project is pretty tricky, as there is generally not much experience in the field. Usually it is not estimated apriori because on the one hand there are a lot of unexpected technological challenges and on the other hand the requirements are unclear as well. For this reason usually there is no cost estimation at the beginning of a project but the project is delivered in an agile way starting with a proof of concept, continuing with a working prototype, which is followed by the fine tuning of both the requirements and the technological architecture. 

Anyway, blockchain projects usually have the following factors to be considered, most of them based on the architectural requirements of the project:

- Smart contract development: key element of the architecture is the smart contract, developing such contracts is more or less resource intensive. Like in case of a solidity, Ethereum development of the code itself is not too much energy, however a lot of efforts have to be put into testing, quality assurance and formal verification as the contract will be deployed into a public immutable ledger. 

- Blockchain infrastructure: at public blockchain platforms, the blockchain infrastructure both the live and the different test networks are usually configured. For consortium blockchains, the whole infrastructure has to be planned, configured and delivered, which might be a huge task. There are some initiatives however to speed up the infrastructure deployment of a consortium blockchain networks, like Azure blockchain from Microsoft or Chello project from Hyperledger

- Fronted or UI: Fronted and user interface is usually required for every blockchain application. It usually requires classical fronted development with javascript, HTML and CSS. There are experimental platforms however where you can speed up the fronted development. Like in Azure Blockchain Workbench, you can click together some of the UI elements, or in Hyperledger Fabric composer, where based on the business blockchain definition file, there is the possibility to automatically generate a basic user interface. 

- Storage: If storage is required, the major question is if it is centralized or decentralized. If it is decentralized, like in IPFS or Swarm, usually the smart contract developers manage this part of the development as well. If it is a centralized storage, like a classical file system or an SQL DB, the integration must be implemented. There are already frameworks which can speed up some blockchain integration with existing storage systems, like Azure Blockhain from Microsoft.  

- System integration: In enterprise blockchain application, exiting legacy systems, like databases, existing ledgers, authentication providers... should usually be integrated with the Blockchain. This can mean atomic swaps, or simply import - exports. Some enterprise blockchain systems already provide experimental services in this direction. 

- Non-technical roles: usually some management roles should be considered as well in a Blockchain project, like a project manager if the project is getting more complex, a Blockchain consultant and requirement engineer to fine tune the business requirements.  

Blockchain as the next level of gamification

From an economical perspective blockchain and cryptocurrency based platforms can be regarded as the next level of gamification. With cryptoecomomical incentive structures it is possible to turn every kind of gamification, score or badge based systems into real measurable economical value. A well designed cryptoecomomical system is exactly what most of the gamification systems do: encourages and discourages certain patterns of behavior. 

Blockchain and network science

Blockchain and distributed ledger systems are pretty much natural targets of network science. They are based on networks regarding both the infrastructure and the transaction graph networks. On top most current network are public, meaning there is a really huge number of data available for analysis. Network science investigations could be carried out on two or three level. 

1. On the infrastructure side, analysis of the P2P topology combining with the changing of the topology and consensus mechanism that can be analyzed. Some consensus mechanisms like Ripple or from Stellar are very much dependent on the network structure. Other classical algorithms like proof of work are perhaps less sensible, however certain network structures make different attacks vectors easier, whilst others guarantee almost the theoretical limits of Byzanzine fault tolerance. 

2. On the transaction side, the dynamics of the different transactions which is important. This is theoretically similar to the cash-flow of the classical systems, the difference is here however that the dynamics of the transaction flow is much faster and all the information is public, implying a much broader investigation possibility. 

3. Last but not least, the blockchain can be analyzed with the help of different other systems. Examples might be the correlation of the blockchain or the transaction flow of two blockchains and perhaps the exchange rates of the two cryptocurrencies. Another option might be to analyze the connections between a blockchain solution and a traditionally centralized www system.  

Network effect and blockchain forks

Decentralized applications based on the blockchain are heavily dependent on the network effects. The value of each platform will be strongly depend on how many actors use the network. In this sense, public networks have much more chance to reach mainstream adaptation than the consortium ones. It is actually an interesting question which of the consortium blockhain solutions have the chance to reach mainstream adaptation: probably the ones that have public solutions as well. One thing that is however dangerous for public blockchains is the forking. Forking practically splits the community into two competing parts. However because of the network effect, such a split will not half the value of the individual networks but quarters them, with other words halfing the value of the whole network.