Former JPMorgan Chase R & D: Why isn't the IBM blockchain real blockchain?

Author: Stuart Popejoy

Translation: Yue Wei

Source: Blockchain Outpost

Introduction: In 2016, the blockchain projects on the market were technically insufficient to support enterprise applications. It is a pity that the problems at the time are still present on today's Hyperledger Fabric and are core issues.

• U.S. CFTC chairman hints that Ethereum futures will be launched soon, and the United States should play a leading role in the blockchain field
• Bitcoin blockchain will part ways, Libra's misery continues, 2020 blockchain enters critical period
• Google develops secure key project OpenSK, which could benefit cryptocurrencies

IBM is an important player in the field of enterprise blockchain. Its blockchain platform is based on the Hyperledger Fabric hyperledger and has developed blockchain pilot products for many large companies such as Wal-Mart and Antai Insurance.

The Hyperledger Foundation is an open source public chain project and belongs to non-profit organizations. As one of the agency's sponsors (most recently Microsoft and software services company Salesforce also announced their presence in Hyperledger), IBM has invested a lot of money to plan to move the organization towards a private or "licensed chain". IBM seems to have his own investment intention: Hyperledger must not only maintain commonality with the industry's well-known public blockchains such as Bitcoin and Ethereum, but also remove the "unsuitable for corporate development" feature.

But regardless of public ownership or private ownership, IBM's behavior that both protects the public chain and engages in revenue generation just ignores the most important characteristics of the Hyperledger Fabric blockchain. Fabric's architecture is more complex than any blockchain platform.At the same time, it is not reliable enough in the face of possible future tampering and attack risks. You might think, after all, it is a "private chain", which has some advantages in scalability and efficiency, but I am sorry that Fabric is not much better in this regard. In short, the pilot projects based on Fabric will face many complex factors and insecurity during the deployment process, and it is unlikely that they will be extended to other enterprises in the future.

What are the blockchains we can choose?

In 2016, while I was at JP Morgan Chase, I led an emerging technology group responsible for researching and reviewing blockchain projects on the market, laying the groundwork for the company's future strategic development and investment. We have conducted in-depth analysis of earlier versions such as Hyperledger, Axoni, Symbiont, Ripple, and Ethereum. At that time, we found that the blockchain projects on the market were technically insufficient to support enterprise applications. It is a pity that the problems at the time are still present on today's Hyperledger Fabric and are core issues.

There are many questions: How can the smart contract language of the blockchain express complex business rules in a secure and simple way? How does a public key signature work? How can a blockchain system expand more nodes without slowing down efficiency? Also, as a future-oriented company, how to easily interact with other public and private chains?

From these issues, I think that IBM's blockchain system lacks the necessary elements of the blockchain. Not only its efficiency index may be misleading to the enterprise, but also a question mark is needed to ensure the long-term viability of the enterprise. Although my colleagues and I should not only take the efficiency (such as the number of transactions per second and the number of nodes, etc.) as the sole measure of blockchain technology, we believe that it is necessary for everyone to know what blockchain should be and what it should not be. Clarifying this concept helps us better understand the changes in this new technology of blockchain.

What should a blockchain be? What is not

To really understand IBM's blockchain position, we need to look at the definition of blockchain. The core of the so-called blockchain is an unchangeable decentralized ledger that records project and transaction data. The actual transaction record is performed through a consensus mechanism. In public chains such as Bitcoin and Ethereum, the implementation of the consensus mechanism is a proof-of-work mechanism, commonly known as "mining." In the permission chain, the consensus mechanism is implemented by participating nodes providing cryptographic signatures and voting on written terms. No matter what kind of chain, there is no central agency involved.

IBM's definition captures the distributed and immutable nature of the blockchain, but ignores decentralized consensus, which is why Hyperledger Fabric does not require a true consensus mechanism. Instead, it uses a "subscription system" called Kafka. The problem is that only if the participants have enforced a democratic voting mechanism can we prove that the ledger information has not been tampered with. The fault tolerance mechanism is a hallmark feature of the blockchain. Without a fault tolerance mechanism, IBM's "blockchain" is almost no different from timestamps.

Fabric's architecture also exposes many weaknesses at the same time, which are easily exploited by criminals . For example, Fabric uses public key encryption technology "in the network" signed by the verifier, which does provide security guarantees, but only if the external signature transaction is submitted before it can be started.

Fundamentally, the proven security model of Bitcoin and other true blockchain systems may fail. In a real blockchain system such as Bitcoin, the transaction record can only be determined by the public key signature of an external user, and any form of intermediate power cannot participate in the system. However, the really important signature in the Fabric consensus mechanism belongs to the verifier, and the user signature is often ignored in the network replication process of any data set.

The reason why Fabric researchers continue to emphasize efficiency indexes (such as transaction speed) is because Fabric's architecture cannot expand while maintaining high efficiency. Fabric uses a multi-chain environment (channel) to keep users secret. Protecting user privacy is an important feature of the private "enterprise" chain, which will inevitably involve many trade-offs and complex factors, but multi-chain solutions are not suitable for expansion. Moreover, the deployment of nodes is also very complicated, each node is uneven, the reliability of smart contracts is low, and single points of failure are prone to spread.

Therefore, for a standard Fabric deployment, a high efficiency index cannot explain the problem. With the increase of the number of nodes, the channel is restored to a single channel, and the efficiency index will decrease rapidly: If you want to trade with the entire network through multiple channels, the efficiency index does not have much reference value. Even if you see that the transaction volume per second of the individual channel has desperately reached more than 800, the channel parameters of the 16 nodes will not exceed 1500 per second. Once the node participation volume becomes high, the delay may reach the length of 10-20 seconds.

Recently, Fabric has made great efforts. It is said that the transaction volume per second has been increased to 20,000, but the changes made by researchers at the architectural level have greatly deviated from the nature of the blockchain, so that the properties of the changed architecture are beyond recognition: patrons Cannot assume the role of validator, and the Kafka system as the only subscription system has also become a display (theoretically, Fabric can use the real blockchain consensus mechanism, but the speed will be very slow and the possibility of practical application will not be very high ).

Finally, the speed index only stays at the single-channel level, which means that the blockchain cannot become an overall source of shared information.

Smart contracts are a business logic

In the face of blockchain, the last point to consider is: how does it expand beyond private databases? How blockchain tools (such as smart contract languages) can help companies achieve widespread success.

Remember, smart contracts are not so-called "code", they are a manifestation of business logic. You can buy a house on the blockchain through smart contracts, confirm your digital identity, or buy and sell used cars. So the reliability of smart contracts is very important. Whatever the terms are, they will be implemented according to what they are.

If you want to create something on the blockchain, you need to describe what you want to do (such as physical transactions, packaged data, etc.) through smart contracts. The simpler the language you describe, the faster it can be created, and the faster the project can be seen by the project. More importantly, you need smart contracts to earn revenue or bring good performance to your business.

Hyperledger Fabric's smart contracts ("chain code") are generally written in several programming languages, including the general JavaScript language and the Go language, but they need to weigh the convenience and security of the programming language. If the blockchain involves a lot of benefits, such as if a program is bugged or written incorrectly, causing millions of dollars to be lost, then the programming language should indeed have a clear purpose, and safety should be given top priority when designing. In an ideal blockchain environment, the smart contract language should be easy to learn and easy to use, but the actual situation cannot be achieved. We know that to successfully complete the classic program demonstration "Hello world", you need to write about 150 lines of code. This amount of code is naturally prone to bugs that can cause millions of dollars in damage.

Private and public chains will not be unrelated

Senior observers in the field of blockchain are realizing that private and public chains will not be unrelated, and the two will be linked in the future. Private networks want to issue tokens to users of public chains, and decentralized applications of public chains also want to store confidential information in private chains. But unfortunately, IBM Fabric users are “isolated” from the public chain simply because the architecture is incompatible. Not only that, they also missed the opportunity to learn the smart contract language, and were unable to achieve seamless operation between the public and private chains.

With the announcement of IBM's announcement of the establishment of an enterprise blockchain that continues to be the focus of media attention, we need to see clearly what the technology is doing under the spotlight. Hyperledger Fabric has insufficient standards in many aspects (including security, efficiency, reliability, etc.). Therefore, companies or institutions that want to seek development with the help of blockchain technology cannot get valuable solutions. To truly understand the value of the blockchain, senior users will look for more advantageous service companies, because they can provide better blockchain technology, and have better plans for future development and application of the technology.

About the author: Stuart Popejoy, has 15 years of experience in the financial sector and has extensive experience in creating trading system and trading platform frameworks. He once worked in the new product research and development department of JPMorgan Chase in the United States, during which he led the development of JPMorgan's flagship blockchain product, Juno. Stuart also participated in writing Morgan's algorithmic trading script, laying the foundation for Kadena's concise and specific smart contract language in the future. After leaving Morgan, he co-founded smart contract startup Kadena in 2016 with Will Martino as president of the company.

Original link: https://medium.com/@mikeycrypto752/why-ibms-blockchain-isn-ta-real-blockchain-7dbe820751ee

We will continue to update Blocking; if you have any questions or suggestions, please contact us!