Non-obvious centralization manifests itself in various forms and places. Web server wars lessons from the past?
Let’s start with the history of the IT industry
Fast forward to the past, to the end of the nineties… The Internet was actively gaining momentum, and companies such as WebLogic (quickly acquired by BEA) noticed the need for a web application server.
Companies were solving an obvious problem: writing the correct high-quality web applications was a real headache. It was possible to write HTML code and run it on the Apache server, then, having screwed CGI, use the interface to run scripts for generating basic dynamic content, but it was problematic to develop something more sophisticated.
Banks that wanted to create an online payment application that would interact with their main banking system required a huge amount of effort and resources. They bore full responsibility related to technical aspects: session state management, fault tolerance, transactionality, and other parameters. It quickly became clear that other organizations needed a similar set of “middleware “ services — and each organization is forced to develop its own software package.
One of the solutions to this problem was the web application server. These servers, usually written in Java, provided a specific set of APIs and a runtime environment for web applications. The clients were provided with a webspace where they could use the organization’s functions, and the organizations themselves were provided with the API, SLA, and general rules of behavior that application developers were equal to. As a result, the following software products were developed: BEA WebLogic, Netscape Enterprise Server, IBM WebSphere Application Server, and the Microsoft Internet Information Services platform. They were developed to solve such problems and it has become an industry worth billions of dollars.
Of course, someone still had to buy, configure, install and manage these platforms (usually incorporate data centers running on expensive hardware), but at least now there is a clear separation. Along with it, a division of labor appeared: J2EE developers, application server administrators, infrastructure engineers, and so on.
Today everything is different, but not radically!
Back to today, the world has changed: we take a rich runtime environment for granted. The modern Internet includes many cloud offerings that protect the developer from worrying about anything other than their code: infrastructure, connectivity, bandwidth, middleware configuration-all this is delegated to the cloud platform. (Examples of cloud platforms)
But the conclusion is the same: in any area, we see that the lower levels of the stack are being standardized and turned into a commodity. A small number of specialized players who save on scale and benefit from the effect of the experience curve are beginning to dominate.
Therefore, the question is natural, will we see something similar in the Bitcoin space? Are there any parallels that we can draw, and if so, what can we learn from them?
Can we see any similarities with the Bitcoin infrastructure?
Look back a few years ago, and anyone who wanted to create a product or service on Bitcoin had to do it all for themselves.
For example, it seems that Mt.Gox has written its own custom implementation of the Bitcoin protocol, which is no surprise, given the nature of its business and the maturity of the ecosystem when it was founded. You might think that this is similar to people who wrote their own HTTP servers or implemented custom schemes for creating dynamic content back in the nineties.
APIs such as BitcoinJ, and platforms such as BitsOfProof, where you can create exciting products and services. In both cases, developers usually run and maintain their own instances of BitcoinJ or BitsOfProof, etc. Thus, it can be argued that this is a parallel with the times of developing own web application servers in the Global Net.
So it is reasonable to ask whether parallels with the Internet are appropriate? If so, what will happen if there are cloud services for Bitcoin developers?
And, of course, we don’t need to imagine. These services already exist. Chain.com is one such example.
Chain.com is a cloud-based bitcoin API for developers. Their website shows the supported Bitcoin nodes. The Chain ensures that they work well and are well connected. Perhaps in the same way as Amazon or IBM, they could support application servers, infrastructure, routers, and connections to the main peer-to-peer points on the Internet.
Developers write their Bitcoin product or service in a language of their choice, calling the blockchain APIs as needed to interact with the Bitcoin network. One can imagine that coding is against Chain.com makes it much easier to create and launch a new Bitcoin company. Developers don’t need to worry about any infrastructure details: Bitcoin abstracts from a set of easy-to-use, well-documented high-level APIs.
Perhaps the users don’t even know that they used Bitcoin!
This is a really important subtlety: if the developers of their own solutions do not use their blockchain nodes in their work, how do you know that the information provided by their service is reliable? How do I find out that his service is connected to a “real” registry that outputs valid data and that user transactions pass through the network?
It is worth being open to compromises that are necessary for development engineers. One approach that application developers can use is to create and maintain their own independent copy of the blockchain, for example, as a node, using it as a monitor/guardian.
Such services are very popular because it takes a lot of effort to install and maintain the Bitcoin network infrastructure and fix it. Then you also need to take care that all the nodes are “close” to each other and the main nodes.
All successful solutions that carry improvements will constantly scale, generating large learning/experience curves. Just like cloud providers can run web infrastructure better and cheaper than most companies could do themselves. It is probably worth expecting that small startups will outsource their integration into the bitcoin network to firms such as chain.com. Perhaps even to hosting providers that include the bitcoin API and network abstraction as a core part of their service offering.
So, leaving aside the problems that such an approach can bring in connection with decentralization, we will ask ourselves:
What if the Bitcoin API/application cloud platform becomes really popular, what is the best way to deliver it?
Until recently, anyone could expect a large number of such companies as chain.com which will be founded soon, and that some of them will gain critical mass and become the dominant players on the application platforms of the future.
However, the news background from China and the analysis of the consequences for the miners of the Middle Kingdom, again updated the issue under consideration, about vertical integration in the blockchain. Mining farms are one of the solutions. Think about the opportunities and advantages that large mining farms have. They could use them to create a powerful hosting offer for developers:
- Hosting in inexpensive locations
Mining farms already support a huge number of servers, usually in locations with cheap power. They could easily offer their clients hosting.
- Huge hashing power
Large farms have the ability to transfer SLA to application clients that no one else could do.
- Optimized network connection
Mining farm engineers, of course, must have a deep knowledge of the Bitcoin network topology, so we can assume that they could make promises about the transaction propagation time and other delay-critical requirements that will meet customer requests.
- 100% pure coins for work
Mining farms have the opportunity to offer companies that use their APIs access to new coins that were not previously involved in transactions. There are no risks associated with reputation, you do not need to ask where the coins came from or rummage through the registry to make sure that it is not stolen money.
Many people tend to ignore mining, considering it only as a function of the infrastructure, but a well-managed mining platform is also a phenomenally powerful platform that can be used to build up the stack to the middleware/API and beyond.
