Useful Information | Blockchain is so popular, how can enterprises play with it?

Liu Shangqi said that the concept of blockchain has gradually gained popularity in the past two years, but when it comes to enterprise-level applications, it still faces many problems. Practitioners should be aware that when making decisions on blockchain selection, practitioners must start from the actual business problems that need to be solved at present and base their decisions on real business needs rather than pure technology. Technology should be part of the application solution.

However, as part of the application solution, when enterprises began to deploy blockchain, they found that blockchain needed to be decentralized, which was completely different from the deployment ideas of traditional applications, and thus fell into trouble. In this regard, Liu Shangqi said that in blockchain technology, except for the underlying components such as smart contracts and distributed ledgers that need to be decentralized, the upper-level architecture is actually no different from traditional technology. At the same time, he suggested:

Regardless of whether the blockchain application is a decentralized application, enterprises should build it on a series of independent services and modularize the system so that different parts can evolve and deploy independently.

For more information about blockchain theory and practice, Leiphone AI MOOC Academy will give a comprehensive explanation in the " Building a Blockchain Application from Scratch " series of courses. Liu Shangqi is also one of the instructors. Interested friends should not miss it!

The following is the full text of the speech (Leifeng.com has edited it without changing the original meaning):

If you want to introduce blockchain technology in your organization, what should you pay attention to? We think that in an enterprise, when you do blockchain, you must consider the following factors:

First, there are so many blockchain bases to choose from in the market, but I may only want to build a blockchain application. What kind of technology is suitable for me? Should I fork the Bitcoin code and create my own implementation, or adopt the solution provided by some vendor?

Second, what is being developed around blockchain is the so-called decentralized application (dapp). Many people find that this is different from the way we think about traditional enterprise applications or Internet applications. Because the decentralized thinking it brings will affect the entire architecture design thinking, how should the software be designed in this case?

Third, the deployment of blockchain is also different from traditional applications based on private computer rooms or public clouds and private clouds. Because blockchain nodes need to be deployed in a decentralized manner, what challenges will we encounter and how should we optimize the deployment method?

Today I will share with you my own understanding based on the above three points.

Technology choices for blockchain

This picture shows the landscape of blockchain in the Fintech field in 2016 summarized by Willam Mougagyar, with a lot of technologies. Of course, blockchain is not only used in the financial field, but also in many other fields such as supply chain and medical care. The blockchain technology in this panoramic picture includes infrastructure based on cryptocurrencies such as Bitcoin, platforms for developing smart contracts, middleware, and more targeted industry solutions at the upper level. When you want to make a blockchain application, you will find that there are many choices.

Not all companies are startups that directly engage in blockchain business. Companies are more likely to hope that this technology can bring some changes and value to the company. Because of the huge potential of blockchain - it is very likely to subvert the current payment, intermediary and other business forms, everyone may want to prepare in advance to prevent being subverted by the rising blockchain innovators.

I assume that we will not develop a blockchain technology stack from scratch. I do see many startups forking open-source cryptocurrencies such as Bitcoin and Ripple to develop on them. We recommend building applications based on relatively mature, open-source or commercial solutions.

When choosing blockchain technology, first of all, it is no different from making technical decisions in the past: in the past, when we made technical decisions, we would look at what type of programming language interface the solution provides, whether programmers are familiar with it, what its documentation supports, whether there are some big companies behind it, whether it is endorsed by open source organizations, whether it is stable enough, and whether there are any application cases in the industry.

In addition, when we choose blockchain technology, we must base it on the business problems we need to solve. Gartner published an article called "Top 10 Mistakes in Enterprise Blockchain Projects" at the beginning of this year, which mentioned that a common misunderstanding about blockchain applications is "Confusing a limited, foundation-level protocol with a complete business solution".

Blockchain technology itself is different from our business solutions. It is part of the business solutions we want to build. Many times we need to pay more attention to our blockchain solutions.

How to find business problems that can be solved with blockchain? These methodologies include: analyzing the target customer groups and establishing user portraits; establishing customer experience maps by analyzing demand-oriented scenarios; and in order to support this experience, sorting out how each business link should flow and analyzing the business process map; in addition, analyzing the interaction between business touchpoints and your business model, and improving your product design and user experience through experience mood maps and design challenges.

In addition, what should we pay extra attention to in blockchain applications? First of all, we need to clarify the two core problems that blockchain solves: the first is distributed trust, and the second is indelible ledgers.

• Distributed Trust

The first is distributed trust, which enables multiple participants with no trust relationship at all to establish consensus and trust in a so-called decentralized scenario without the endorsement of an intermediary authority.

When sorting out business processes and business touchpoints, we need to: analyze which touchpoints in the entire business process of the enterprise require me to interact with third-party organizations and institutions, and establish some kind of trust mechanism. Our blockchain technology can be applied to these touchpoints.

• Irrefutable ledger

Another use case of blockchain is irrefutable ledgers. Blockchain hashes each transaction, constructs multiple transaction hashes into blocks through Merkle Tree, and then connects them into a chain through Hash Point. This structure can easily and efficiently verify tampering with the underlying ledger. For businesses that require auditing and compliance, once blockchain technology is used, the cost reduction that can be brought to you is very obvious.

Therefore, when we talk about the application of blockchain, we must not simply use this technology to explore new ideas, but must base it on real business problems.

We analyze real business problems, find the points where multi-party trust needs to be established, find the points where non-repudiable data is needed, and then build blockchain solutions at these points.

After finding the business problem, we may also need to pay attention to two core business indicators: the first is the business throughput, and the second is the business transaction confirmation time.

• First, we need to understand the transaction throughput of this business. For example, if the business is a cross-border settlement business with hundreds of thousands of transactions per day, the daily throughput supported by the blockchain system must support this number, which is the transaction throughput.

• Another point is the transaction confirmation time. When I make a transfer or a payment, how long does it take for the transaction to be confirmed? The transaction throughput of Bitcoin on the real chain is relatively low, 7 transactions per second. If commercial applications are developed directly based on Bitcoin, many business scenarios with daily transaction volumes exceeding one million may not be supported. In addition, Bitcoin generates a block every ten minutes, which means that it takes ten minutes to confirm a transfer. Generally, after generating six blocks in a row, which is about one hour, we believe that your transfer is relatively stable on the chain and is not easy to be tampered with. Ten minutes, if you want to make cross-border payments, this is much shorter than the traditional T+2 and T+3 arrival time. But if you do some consumer-oriented applications, consumers cannot stand there and wait for you for ten minutes before knowing that my payment is successful. (Of course, this is just an example of Bitcoin. In fact, there are many technologies such as micropayment channels, lightning networks, and segregated witnesses on Bitcoin to improve Bitcoin's throughput and transaction confirmation time.)

But here I want to remind everyone that the transaction throughput and transaction confirmation time of the business you are facing will greatly affect what kind of blockchain technology you choose.

Some factors don't need to be considered

Related to the specific blockchain technology, I think there are some factors that do not need to be considered:

• Encryption Algorithm

For example, what encryption algorithm do you use? Is SHA128 or SHA256 used for one-way encryption? Is RSA or elliptic curve used for asymmetric encryption? We believe that as an enterprise, you don’t need to pay too much attention to the specific encryption algorithm. This should be part of the blockchain technology stack you choose, and the encryption algorithm implementation is encapsulated inside. It is very difficult to implement the encryption algorithm and do the tuning yourself, so try not to write it yourself.

• Underlying network communication protocol

In addition, some companies that expand their applications based on open source blockchain technology may try to optimize the communication performance of the P2P network. We share the same view that as an enterprise, there is no need to adjust these underlying network communication protocols by yourself. You should have considered it when choosing a certain blockchain technology.

• Interoperability

Many people are also talking about the interoperability of blockchain. We know that there are so many blockchain technology implementations listed above, and their underlying protocols, including the data structure of the ledger, the verification and communication methods of the nodes, and the smart contracts running on them are all incompatible with each other. It is a bit like before we built the global Internet in the last century, each organization had many local area networks of its own. Of course, these local area networks have played their own roles, but they are isolated information islands that are not connected to each other.

So many people say that when choosing a blockchain, you should consider interoperability and whether it is compatible with other blockchains, so that you don’t have to do too much migration work when the blockchain is unified in the future. I admit that interoperability is very important, but frankly speaking, at this point in time, I don’t recommend that you spend too much time on it. Because there is no so-called defacto standard at present. Whether Bitcoin or Ethereum will achieve unification in the future is uncertain. There is no need to invest too much time trying to predict the uncertain future at this time.

Important points to consider

Regarding factors related to specific blockchain technology, I suggest considering these three points: first, consensus algorithm, second, account model, and third, smart contract.

Consensus Algorithm

Someone joked that it solves the problem of "what to eat for lunch today"? This is a very apt description. The so-called distributed consensus algorithm - I have so many distributed nodes, and they need network communication to reach a consensus on a certain state, but they don't trust each other. This is very different from the distributed systems we use in Internet applications. Traditional distributed system nodes are deployed in their own computer rooms, and there is no need to consider Byzantine errors. You only need to consider problems such as packet loss, timeout, and machine crashes, and you can use algorithms such as Paxos and Raft.

But if you are doing blockchain applications, you must deal with Byzantine errors and face potential fraud and tampering. Choosing different consensus algorithms here will have a relatively large impact on your blockchain application. Some blockchain applications may be public chains facing the public network; some blockchain applications are alliance chains with limited nodes, pursuing high performance and high throughput. The consensus algorithms they choose must be different. Here is a comparison of the main algorithms.

• One type is PoW, proof of work, which has been verified in Bitcoin for many years. PoW has been proven to be very suitable for this kind of fully open network public chain, and has a high tolerance rate for Byzantine errors. Generally speaking, we believe that 51% of the nodes must unite to commit fraud in order to generate effective supply for the entire blockchain. But correspondingly, PoW consumes a lot of computing power, and the throughput and confirmation time are not ideal.

• Another major category is PoS, proof of stake, and DPoS, etc., which are adopted by Ethereum . Proof of stake is based on the number of shares of different nodes, which is a bit like voting at a real shareholders' meeting, where nodes are randomly elected among shareholders to keep accounts. This type of algorithm is also more suitable for public chains, and is optimized in terms of capacity and computing resources compared to PoW.

• Another type is the Byzantine Fault Tolerance (BFT) protocol, and the more famous ones are like PBFT. This type of algorithm is based on state machine replication and does not require tokens. When a client sends a request to a node, each node broadcasts messages sent by all other nodes to each other and confirms the transaction with each other. Generally speaking, it has lower latency and higher throughput, but it also puts relatively more pressure on the network and is more suitable for limited network nodes. In addition, BFT algorithms have a relatively low tolerance for Byzantine errors. For example, when f nodes in PBFT have Byzantine errors, the entire network must have more than 3f+1 nodes to ensure correctness.

In 2016, the industry also did a lot of exploration on consensus algorithms. Now everyone has basically reached a consensus: if your blockchain application scenario is a public chain, you can use algorithms such as PoW and PoS. If your blockchain application scenario is a permissioned chain or consortium chain, you can use a BFT algorithm.

Account Model

Another one is the account model of the blockchain technology you use. There are two schools of thought. The first school is the UTSO model represented by Bitcoin, and the second is the simple account model represented by Ethereum.

Let's talk about the simple account model first. It's very simple. My transfer payment is money addition and subtraction, and payment. UTSO, when constructing each transaction, there are inputs and outputs. I have 1,000 yuan in Bitcoin. When I transfer 100 yuan to Alice, I don't deduct 100 yuan. I construct such a transaction, input 100 yuan, and output 100 yuan. Your every transaction data will be recorded in this ledger, so it is easier to do some data analysis in the future. Because it was first proposed by Bitcoin, it is more effective for the double-transaction problem. The simple account model is more effective, that is, simple transfers, and can support some more advanced ones. If you do it based on UTSO, it may be more troublesome.

Smart Contracts

The third is the support for smart contracts. Many people have been working on it for a year or two and found that we only need a distributed ledger and a bookkeeping function. If you only make a bookkeeping function that cannot be tampered with, many companies and organizations are interested in its smart contract capabilities. When choosing technologies, two appeared in the technology radar. These are the solutions we have conducted some joint experiments on.

Decentralization

Another point is how you should build a blockchain application. Many people say that blockchain is completely decentralized, which is completely different from traditional thinking. How to build my application is completely confusing.

In your traditional application, the top layer is the UI layer, and the bottom layer is the database. In blockchain deployment, the top layer is your Cllent, which does not run a real node, but is just a light client responsible for calling the blockchain contract at the back layer. Whether you are building a website or not, you can use any familiar technology. The real core part is the SMART contract, and the bottom layer is the distributed ledger. Only the following layers need to be deployed and built in a decentralized manner. The top layer is no different from our traditional technology.

When building blockchain applications, we saw some consulting companies that put a lot of things together. Because it is a new thing, it is very convenient to do it together. However, blockchain has some consensus algorithms, which makes it very difficult to evolve in the future, because each part can evolve and develop independently.

This is Hyperledger, my identity management, my registration, part of which is responsible for the so-called consensus algorithm and distributed ledger, which are especially like consensus algorithms, and part of which is the smart contract in Hyperledger. Even if we don't use Hyperledger, it's similar to our own public cloud. This part must not be compiled and packaged with the business application in the same code.

Another part may not be a smart contract. We hope to separate this part and make it a separate service module. Generally speaking, identity management will be involved in your blockchain. No matter what technology you use, there will be this part. We also built it independently. It recommends an architecture. We see that it also makes our distributed ledger, identity and key management services into common services, including encryption algorithms that can be refined, and some ML and BI servlces are carried on it. At the top are applications and monitoring terminals, running some real solutions. This is blockchain-related technology. This is the underlying ledger. It can be combined with other blockchain customized tools and the market to build some architecture.

This is the approach we recommend, because blockchain is a mixture of many technologies, which must not be mixed together, but should be formed into independent services. In this way, for identity management, blockchain technology, consensus algorithm, encryption technology, you can choose independent technology providers, or independent open source implementations, to build your own independent business, so that you will not be tied to a certain platform and can have more room for development.

Deployment and recommendations

Speaking of deployment, I will only mention a few of the original planned applications. Some classmates asked me that they are entrepreneurs who do technology. When it comes to blockchain technology, once I write data into it, it cannot be tampered with. What should I do if I want to change the data?

I said there are two situations. In the first case, the data is tampered with due to the requirements of regulatory audits. There are also two schools of thought. One school believes that blockchain technology should provide such capabilities. I stand on the other side and I think it should not provide such capabilities. In addition, you clearly wrote it wrong. I saw the problem faced by individual developers because my own application was written wrong, resulting in data corruption and data errors. When you develop in a normal enterprise, you must go through strict development and testing, and you must test in advance before you can go to the production environment. We usually develop several nodes on the local machine and then a network. It is impossible to go directly after development. You must have different test network nodes of the blockchain. You must fully test before you go to the production environment to ensure that the logic of this part is correct and that there will be no data errors due to logical problems. Then you can rise to the production stage. How to maintain a unified environment between the local production environment and development, including infrastructure and blockchain network configuration, we think it is very easy to solve with this technology.

Another point is that you are really facing a problem. The applications you deploy now are not just in your own computer room, where you have full authority to deploy. In order to establish distributed trust, you need to distribute your applications on different nodes and different participants, possibly outside your organization. You don’t have an Apple store, so it is difficult for you to constrain their environment, their technical environment, and their conditions . At this time, we think that if you just give them the latest software package for them to upgrade, there may be many uncontrollable factors. There may be some conflicts in the technology, software version, and middleware they use, and there may be some unpredictable problems. In this scenario, I think it is a good strategy to standardize your software and environment and distribute it. So we recommend that when you make an application, you should still use the original plan to manage the environment, deployment, and release.

Finally, when companies want to try blockchain technology, they will face many uncertainties. Here are three suggestions for you:

● When you choose blockchain technology, it must be based on your business. It is not a pure technology, but must be part of an application solution.

● Whether it is a blockchain application or a decentralized application, we recommend building it on a series of independent services so that different parts can evolve and be deployed independently.

● Want to manage the original plan and improve the efficiency of your deployment, including software distribution.

That’s all for today’s sharing, thank you everyone.

On-site Q&A

Question 1: I just mentioned a question. If there is a problem with my business that affects the data, is it reasonable to change the data of my blockchain in the production environment?

Liu Shangqi: Because we know that the characteristic of blockchain technology is the so-called data immutability. In fact, many people ask this question, is it really reasonable for me to change the data in the production environment? I just mentioned two schools of thought. The first school of thought believes that mistakes will definitely happen in reality, and there must be a need for supervision, especially in China. If the technology does not provide the ability to supervise and change data, the government may not allow it.

This is achieved by the blockchain technology platform, and a separate arbitration node and implementation may be established, such as Oracle, which will do the final audit of our data. It is more authoritative and can make some modifications. But I personally, including many colleagues in the blockchain technology community, think that this is unreasonable, because it will obliterate the value brought by blockchain technology and your trust in blockchain. What if such a situation really occurs? In real life, humans will definitely make mistakes, and businesses will definitely make mistakes. How to deal with it in real life? Through offline methods, you make a phone call, you make the wrong money, we will send the money back, and compensate the technology itself through offline contracts. Technology maintains its value, and I rely on other business operations to compensate. Thank you.

Question 2: I have a question. You may be talking about the financial industry. I wonder what impact it will have on other industries, such as traditional industries.

Liu Shangqi: Here we can open a brain hole, if you are familiar with the concept of DEO. In addition to the financial industry, because your blockchain can establish a distributed consensus among different participants, many so-called O2O and some intermediary applications are no longer needed, including P2P. I don't know if there are Didi Taxi or Dianping here.

If you develop a taxi-hailing app or a rental app or Dianping based on a blockchain platform, why do I need a dedicated company to operate it? I rent a house, and I have a tenant and a landlord. I only need these two parties to participate, and I don’t need a real company or entity to establish this trust. So if you look at it from this perspective, you will find that many of our current Internet O2O, or online-to-offline, Internet-based applications, and some emerging giant companies, their business scenarios can be replaced by blockchain smart contracts. I wonder if anyone has tried to answer this question.

Question 3: I would like to ask, there are public chains, private chains, and now there is a consortium chain. My simple understanding is that the consortium chain is a few private chains added together?

Liu Shangqi: For private chains, I am an organization. Even if we don’t use blockchain within the organization, you still have enough trust. Consortium chains are between multiple organizations, such as credit card settlement between banks. I may need an institution like Visa in the past, because my bank A is CCB, and I transfer money to China Merchants Bank. I deduct 100 yuan from the database and add 100 yuan to your database, but our databases are separate, and there is no way to confirm that you added 100 yuan, not 200 yuan. We need an intermediary like Vasa.

If a consortium chain is developed, we can establish nodes between different participants, reach a consensus, and share a shared ledger. I know that if I deduct 100 yuan, I will give you 100 yuan more. The consortium chain is more suitable for settlement between banks. We are entities that have certain business dealings and connections. We may have needed an intermediary, an endorser, or an authoritative certifier to authorize in the past, but now we can put it aside and play by ourselves.

Editor's note: According to the official introduction, "ThoughtWorks Technology Radar" is not an objective industry analysis or report, nor is it intended to be an authoritative official document. It shows a "snapshot" of the current technology field, and conducts coarse-grained classification and trend analysis. The ThoughtWorks Global Technology Board (TAB) regularly discusses the current status of technology development, and evaluates the maturity of various technologies in the form of radars and gives suggestions, providing reference for stakeholders from programmers to CIO/CTO. This is also the meaning of the word "radar" in the name of the conference.