BTA Summit – Ruff Founder Roy Li: Application Practice of Blockchain Technology at the Enterprise Level

May 23rd, 2018 at 7:02 pm UTC · 13 min read

Roy Li, the founder of Ruff, was invited to attend the summit and delivered a speech entitled the “Application Practice of Blockchain Technology at the Enterprise Level”. The following is the record of his speech.

Speech Record

At first, I’d like to express my gratitude to the organizers, and CSDN, for giving me such an opportunity to deliver my speech. We are not sponsors. I’m a company invested by Jiang Tao and Wang Feng, who provide angel investment for me. So, I make it clear to you with this opportunity.

We are also the one with the smallest sense of existence among their invested companies. Many people haven’t learnt about it, so it’s also an opportunity for me to display my sense of existence today. It is a technically-oriented forum today, and we are not sponsors, either. I’ll try to talk as little as possible about my company and as much as possible about the entire industry.

My topic today is the application & practice of blockchain technology in enterprises. The market environment has not been so favorable recently, and a great many guys say that, due to the immature infrastructure, blockchain technology is still at its early stage, and it is difficult to implement in a real sense.

For this reason, some on the market hold that, the Tokens before us may turn into an air currency, which, in my view, can not be too absolute.

There are indeed some technologies in the market that are not very mature, with poor adaptability to be realistically implemented. However, there are some technologies that are easy to be applied at the enterprise level.

During such a process, we should analyze from a relatively rational perspective, and should not feel that blockchain is quite extraordinary just through patting the head, or that blockchain is far from realistic implementation.

Today, I’ll talk about the application of blockchain technology at the enterprise level. We ourselves are also engaged in enterprise-level applications, during which a lot of explorations have been made, with tons of analyses of technical practice as well; we’ve also observed how open-source technologies are really like on the external market and whether they can meet relatively high TPS. Of course, TPS is not an indicator good enough. It depends on your mode of selling the currency and how you address the problems related to blockchain.

I wonder how many of you here really understand blockchain, and how many of you know the real meaning of the three words. After learning about the history of the three words, you might make brag of your knowledge with it someday.

Origin of the Three Words: Ropsten/Kovan/Rinkeby

The first word is Ropsten. In fact, these three words are all the names of the Ethereum test network. These three are all optional Ethereum test networks. There are two clients on Ethereum, and Geth is the first client. Since its performance is not so strong, it is very slow to synchronize, and later, an Ethereum full-node software was developed, written in the Last language.

Later, as the two client versions have some compatibility problems with each other, for allowing for compatibility in the Ethereum test network, significant modifications were made to the test network, which finally resulted in the generation of Ropsten.

The next two are also test networks. Since Ethereum’s material mechanism is POW, and this W requires costs, for the miner needs cost, the earliest Ethereum’s test network was of little value due to the very low coin price. In addition, it was impossible to acquire a lot of computing power to support the Ethereum’s test network, so it was vulnerable to malicious attacks.

Since the computing power of entire network was not big enough, tons of attacks were targeted at this Ropsten. For one block, 10 million is the maximum gas, and a gas of 4,750,000 was made into a gas of over 9,000,000,000 for one block by attacks. It became impossible to proceed any more.

In Ropsten, it is, at first, impossible to apply POW when it is so low. So, they used a POA, and this concept was finally turned into Kovan, a POA-based network. For example, if you’re a big name in the community of a well-known organization, I trust you and make you into that.

So, it’s quite like DPOS, but it’s not selected through voting; instead, it is through recognition in the community, and you guys are now big nodes. So, that’s what he did. The foundation also favored that, and decided not to follow the original mode but produced a test network in the POA mode, called Rinkeby; hence the three words here.

We can learn from this story that, as for any public blockchain at its early time of being capable of launching, you should pay attention to one thing: it is highly challenging to conduct very, very high decentralization at the early start.

POW intends to solve decentralization, and its computing power is quite dispersed. However, it is relatively centralized at the early stage. The so-called “decentralization” does not mean no center; there might be several concentrated centers, more appropriate for the launch of network.

Similarly, you might have heard about LTA. It has a centralized coordinator for such coordination. As for miner building, they adopt this mode. In early enterprise-level applications, if you’d like to create a public blockchain, you must consider such issues at the early start.

So, you might resort to POA for fixing. Here, I’ve told you this little story, so that you can brag to your audience and, for those dedicated to public blockchain development, consider how to start when you have a strong computing power for support at the early stage.

Which Consensus Mechanism should be for Public Blockchain?

Our next topic is, for a company, if you want to conduct a public blockchain, the first issue you face now is which consensus mechanism you shall choose. For example, BFT is an option, with high fault tolerance, but it has a problem, i.e. scalability.

Its performance is inversely proportional to the square of the node; that means, if your nodes are ten times more, your performance will drop by 100 times. Based on the data of Hyperledger, including analyses by many people, it would be highly difficult to apply BFT when your nodes reach 100.

By contrast, its advantage also lies here: if 50% of your nodes are crocodile nodes, there would be no big impact. Personally, I prefer DPOS. You can use it at the early stage of public blockchain and rely on DPOS for transition. A double-layer POS works the same, but it has a greater scalability, which, for bitcoin, is not a big issue indeed.

I myself specialize in security, and the bottleneck of security never lies in that layer. It has more problems indeed. It has been proved that, a SPV node can still guarantee high security even if it does not store the data of an entire block, since you can finally discover a POW mechanism with long- and short-chain. But, many such problems exist in DPOS. If you’re a light node in DPOS, not storing all the data, problems many occur.

Besides, the voting mechanism of DPOS is designed to be a vulnerable point, which should also be taken into consideration. POW is certainly the best, but, as I mentioned before, when the computing power of entire network is low, or the value of your coin is not high, some problems may occur in POW.

Another point is about our CAPA. A lot of infrastructure now aims to address some issues in blockchain, including Sharding technology, which is not quite mature up to now but is still an extensively recognized direction. There’s no need to divide the entire network into many blocks to conduct what I desire to do in parallel.

This Cluster includes contract execution. For example, US has done something, and I feel US quite interesting. Due to the reliance of contract during its execution, I might suppose it is highly difficult to execute the contract in parallel. The better you cleanse my data, the higher my parallel execution efficiency will be, and the higher the award I will give you.

This task fulfilled by US is quite interesting, which is what we all desire to solve in Cluster. US hands over the issue to data packers; you pack the data in any way you like, and I just want to solve my problem. I admire companies dealing with this.

At last, in Optimization, more efforts are on the optimization of node ends themselves. The ledge nodes of “gas” itself are limited, and the quantity of “gas” you can reach within the required block generation period is limited. Basically, it’s how to improve the magnitude.

Ethereum is not in the TSO mode; it uses over 400G for storage, and it is a problem to read and write this 400G. Some one improves the ability of data reading and writing, and it is now conducted on the market. It’s quite interesting.

As these technologies slowly grow mature, blockchain expansion technologies have grown much stronger. And your hard disk can have the performance of instantaneous reading and writing, and, theoretically, “gas” can be significantly improved, which is something we should consider during optimization.

Iteration Difficulty of Blockchain Technology is Much Greater than that of Traditional Technology

Why is the iteration of blockchain technology more difficult than traditional technologies? That’s because the problems the distributed system of blockchain faces are different from those faced by centralized systems, possibly quite distinct.

In US, for example, one paragraph of the whitepaper reads: In atomic transactions between mega and mega, atomicity is indivisible, and the atomicity between multiple mega-s can only be executed in parallel, not in series. When you conduct optimization, you’ll see that, 80–90% of these conflicts are avoidable, and only those relationships with unclear sequences, like at exchanges, have 1–2% probability, which you can not handle.

However, the overwhelming majority of them can be handled. Next is storage. A company has said that, he has already added IPFS. There are big problems in IPFS. The performance can not be guaranteed now. As to this point, I’ve asked many P2P old pros and experts, who expressed that, it is currently unsolvable in terms of unstructured data storage. It is highly difficult to be really IPFS.

Personally, I am quite optimistic about the future of IPFS, but, currently, the problems of its practical implementation are still unsolvable. The last point is “contract”, immediate execution of contract.

If it’s easy for you to apply the UTSO mode, just execute it. I chatted with Shuai Chu a couple of days ago about this, and he said: the contract is quite complex; conflicts among contracts are not necessarily conflicts among mega-s, but most likely to be conflicts of others.

At present, the contract is still at an early stage. The future development direction should be, for us, how to more efficiently adjust the sequence of contract execution, and adjust their sequence and more efficiently execute contracts by finding the correlation among contracts.

Blockchain Technology is Currently at the Stage of Transition from Theory to Practice

Finally, I believe that, at present, the blockchain is at the stage of transition from theory to practice. In 2019, when we talk about blockchain again, please do not mention it to me if you have no practical technologies. I think you can do it in 2017. In 2018, in particular, it has been quite difficult to do that.

All of us feel that too many people brag about their own things, including some things that can not be acquired within ten years. There are problems of practical implementations for all of them.

The blockchains that seem quite successful now may not be the best in performance, but one thing is certain: it has dramatically reduced the developer’s cost of developing APP. Why was ICO so hot last year? Why were so many guys engaged in Token last year?

So many people did this every year before, and now, you can directly release your own Token when you make your own Token based on ICO. For someone who has one year of programming experience, he/she can make it within 3 days after learning a little of JAVA. It is so common that all programmers can do it.

In future, maybe some of you do not know how to develop the blockchain, but you can develop an APP and develop your own distributed application, which will be a big trend in future. The Ruff Company has run for four years. We have been successfully engaged in IoT OS for years in the field of IoT, and we can now, in a more abstracted way, develop some applications of peripheral computing.

And, these applications can be combined with blockchain. The updated applications are all standardized and abstracted data, which I’m quite proud of. That’s why many people are optimistic about Ruff when it is launched in a programmers’ community. They hold that, this is where we are close to the physical column.

I’ve been dealing with the public blockchain for a long time, and I feel the same when I’m now dealing with the public blockchain and when I dealt with the OS before. Only when I lowered the threshold of development can more people come in. Only after the threshold is lowered, there are more applications.

People who are more creative than me can produce applications beyond our imagination. So, here comes my slogan: “Code Easier, Change Faster”. A public blockchain is not successful until all the people can develop applications in a relaxed and joyful manner. That’s my attitude towards the public blockchain and how can a public blockchain succeed.

Thank you very much for giving me such an opportunity to share with all of you here today. That’s all of my sharing today. Thanks.

Introduction to the Honorable Guest

Roy Li: the founder of Ruff Chain, Ruff CEO, a noted security expert and IoT expert, the founder of the world’s leading IoT OS —, and an MSE master student supervisor in Fudan University. He used to be a security consultant to Verisign and Trend Micro, former Chief Technology Officer to Nokia OVI in North America, QCon (Software Development Conference) Outstanding Producer for four years, and GITC (Global Internet Technology Conference) lecturer for three years.