Author: Haiyan

Media: Token Explorer(bitansuo.com)

Recently Robert Mao, founder and CEO of ArcBlock, sat down with Token Explorer . Token Explorer is a media company founded in China and committed to blockchain technology research, project rating, and other industry activities.

Token Explorer: Could you tell us how the idea for ArcBlock originated?

Robert: I learned about Bitcoin and blockchain back in 2013, and was immediately inspired by its broad applications. I wanted to become more involved with this technology, as this was a natural application of my background, so I participated in Bitcoin mining. At the time, when the blockchain concept was in its infancy, it wasn’t well understood, which significantly and adversely impacted Bitcoin prices, casting doubt on Bitcoin’s potential as a currency. Eventually, people began inquiring into Bitcoin’s underlying technology, and discovering its potential.

This was the turning point for blockchain technology development in the United States. Prior to 2013, blockchain was largely only applicable to facilitating cryptocurrency markets. Realizing blockchain’s versatile applicability, more and more companies, especially financial institutions, invested major resources in the blockchain industry. However, by late 2016, we discovered that the existing blockchain applications market still left a large and unfilled gap.

I say quite often that today’s blockchain technology is like Internet technology in 1993. Why specifically 1993? Because 1993 was a watershed year in Internet development history. TCP/IP protocol clusters and other basic protocols had already reached a very mature stage but web professionals were still unsure which protocol would eventually become universal. This environment fostered an urgent market need for companies like Cisco to develop the Internet infrastructure, which allowed companies like AOL and Netscape to finally allow everyday users to access the Internet.

It is in this spirit that we founded ArcBlock; we hope that ArcBlock can play a similarly important role during this critical period, the blockchain development era, taking blockchain from 2.0 to 3.0.

Token Explorer: You’ve only listed four key team members on your official website, but as we know from other sources, you’ve added dozens of technical staff. What is your team development plan for 2018?

Robert: Our team grows relatively fast. The project, which started with a team of four, began attracting additional team members shortly thereafter. Additionally, our token sale has gone smooth, providing us with additional team building resources and enabling a much faster expansion.

Since we are a computing ecosystem, we need to address both technical issues and specific business components, which also have developer and UX implications. Our team design is also relatively decentralized. Therefore, in 2018, we plan to divide our team into multiple small centers, each having a separate focus and key responsibilities:

We plan to establish the Seattle office as the core research and development base, focusing on the development of the computing platform itself. We chose Seattle because it is the "Capital of Calculation.” There is a lot of technical talent here. Our Seattle office will expand its core technology team to about 25 people.

In Dublin, we plan to set up a technical team of no more than 10 people, led by Flavien (Chief Scientist). This team will be responsible for the research and development of high-performance blockchain technology.

We are also going to build a larger team in Shanghai, mainly focusing on developer and user experience.

Token Explorer: According to ArcBlock’s roadmap description, the first decentralized consumer application will launch in Q2 of 2018. What kinds of applications do you foresee running on ArcBlock? Is it particularly well suited to a certain kind of application?

Robert: For the first Dapp launch, we want to give our community a bit of a surprise. I will say the first few applications we put online will possibly fall under the category of education. As a computing platform, we hope ArcBlock can be used across different industries. I believe there will be all different types of ArcBlock applications in the future. In general, ArcBlock is designed to foster non-financial application development.

Token Explorer: Does ArcBlock have an incentive policy for developers?

Robert: Sure. ArcBlock is essentially a development platform, so we keep the focus on developers.

For example, we give priority to developers if they want to participate in the highly limited token sale. Even if a candidate is a VIP investor, I’ll say, ‘Sorry, our quota is extremely limited.’ But if a candidate is a developer, even if they are an ordinary developer, we are willing to give them a chance to participate. We’ve allocated 32% of our tokens, a substantial share, for the future developer community.

Our system may not be sufficiently mature by the end of 2018, and may not yet be open to community developers. However, we will be able to invite some of our close partners to experience the system in advance.

Additionally, we are planning to host the first Developer Conference in 2019. This will be a milestone event that will broaden our developer pool and facilitate further participation in ArcBlock’s development.

Token Explorer: ArcBlock's white paper mentions that there are some core issues in the existing underlying blockchain, such as poor performance, non-user-friendly interface, high costs, and platform lock-in risks. Can these issues be resolved through upgrades and improvements to the existing platform?

Robert: Yes, we believe the existing mainstream blockchains have already realized these problems and are beginning to solve them. ArcBlock’s purpose is not to create a new blockchain just because the existing ones have issues. Instead, we will cooperate with the existing mainstream blockchains and grow together with them.

As an application platform, we are mainly focused on achieving the open chain access protocol. At present, most of the underlying blockchain platforms usually choose themselves as the center. Developers have to be locked into a chain’s protocol when they are on that chain. Developers find this frustrating, and we want to change it.

Many people describe the power of the blockchain as omnipotent: it can do everything. However, we think blockchain has boundaries. We need not only to acknowledge blockchain’s abilities but its shortcomings as well. A truly consumer-friendly blockchain application should combine both on-chain and off-chain capabilities. The underlying technology support platforms such as Ethereum or SuperBank are mostly concerned with how their blockchains themselves can improve performance and solve platform issues, but as a complete application experience, there are many off-chain aspects that we should focus on. This UX framework is the guiding principle of ArcBlock.

Token Explorer: In order to solve the platform lock-in problem, we may need to solve other problems first, such as the application of each platform (back-end services, mobile phones) and interface interaction, chain data migration problems, and transplant compatibility problems. Has ArcBlock explored solutions in these areas?

Robert: We have received some criticisms from the community about the platform lock-in issue. I think the comments are fair. Their main point of view is that if users choose ArcBlock, in fact, the users will still be locked in the open chain of ArcBlock.

Open Chain Access Protocols is essentially the access layer of an abstract blockchain protocol. Once you have defined an abstraction layer, it also means that the user is bound to this abstraction layer. To solve this problem, our approach is to contribute the open-chain access protocol code to the open source community. That is to say, although we created it, we don't control it. Everyone can contribute code. Users are bound to a public open source agreement, but not a platform that is completely controlled by a company.

In addition, from the perspective of computer technology development, there are quite a few things that we need a unified abstraction layer in order to solve. Our open-chain access protocol is very similar to the database system's open database interconnection. In the early days of database development, each database had different APIs, different data query languages, and different data manipulation languages. Out of this problem, a unified intermediate language called SQL was born. If you want to get the best performance from a database, you first need to find the database's native interface. SQL acts as the “linguistic” intermediary.

Today, when you launch an application that requires a database, you’ll find that most databases support SQL, which has become standard. However, as we reach a consensus, we find that a more abstract middleground still works best for some things. Therefore, we believe that in the future, even if our open chain access agreement does not become the gold standard, something similar will become mainstream. I'm not quite sure that a particular blockchain (such as Ethereum or Hyperledger) will be it. ArcBlock is more neutral, and, I believe, more likely to be embraced as mainstream.

Token Explorer: The Open Chain Access Protocol defines three levels of APIs. To solve the cross-chain problem is mainly to work with level 1 and level 2, which will only produce a simple query adaptation. The feasibility will be high but the function will be relatively simple. In order to enhance the functionality of these two levels of APIs, the implementation is similar to the current cross-chain protocol projects. Is ArcBlock Open Chain Access Protocol a good solution to the problem of consistency across non-read-only interfaces?

Robert: Very good question. As you said, ArcBlock divides the API into three levels, designed after in-depth consideration:

• Level 1: Common Chain APIs. Almost all of the blockchain has the most basic common attributes.
• Level 2: Common chain data APIs. At level 2, instead of thinking about the blockchain itself, we consider which series of abstractions most blockchain applications need. So in level 2 API, there will be some blockchain which can not be fully realized.
• Level 3: Native Chain APIs. Because of the need to define an abstract interface, some of the native features of a particular blockchain model are bound to be sacrificed. In this case, providing only level 1 and level 2 APIs will render many of the blockchain's native attributes totally useless and will therefore lose some of the open interface users, so we support level 3 interfaces.

We did a lot of research when designing these three levels of API, and we also learned from the ODBC standard design practice. In fact, the ODBC design is also divided into three levels.

We have a fundamental difference from current cross-chain protocols. Currently, according to my understanding, most of the cross-chains are a relatively low-level protocol. They try to achieve a certain degree of interconnection and interoperability. Our open chain access protocol is not to solve the intercommunication problem between blockchains. We run cross-chain applications in ArcBlock, but here, cross-chain applications mean that they all access different networks through open chain protocols. The blockchains are not actually interacting directly through our protocol interface, so those cross-chain protocols can meet some different requirements, and incorporate additional design development complexities.

Our open chain access protocol is more realistic by design. We think most applications, even if they have cross-chain requirements, work from that application’s layer. So we do not need to complicate the issue. We only need to provide a unified method for applications to access different protocols or different blockchains. Any design is a trade-off, and ArcBlock is designed more from the perspective of applications themselves than cross-chain requirements.

Token Explorer: ArcBlock wants to provide a free blockchain. However, in the current world of blockchain, the lower the fee, the more vulnerable it is to attack. Does ArcBlock have any defense measures?

Robert: We have considered this aspect. Every user can be a node in the architecture design of the blockchain. Each node can broadcast transactions in accordance with the protocol rules. Miner nodes will package these transactions into the block, which poses the risk of some malicious nodes consuming system power through dust attacks.

The end user, in the current blockchain, cannot publish a large amount of malicious transaction information. It is very difficult to produce an attack effect. ArcBlock is an application framework. If a dust attack occurs, it can basically only be initiated by a server application running on ArcBlock.

In our design, the end user doesn’t need to pay, but that doesn’t mean that the application itself in the system doesn’t generate any costs. The cost will be paid by the application providers. Just like when a video game developer develops a free game, the game is free for end users to gain more attraction, but its server needs to be paid for. Unless the purpose of developing of an application is to generate a large number of invalid transactions, it is impossible to produce a dust attack.

There is one detail that our white paper does not mention, but which is relevant here, and it’s that the application provider in the ArcBlock system needs to pay a certain amount of ABT as a deposit. If it causes destructive behavior in the system, not only will the application possibly be removed, but the provider may also forfeit the deposit. This mechanism is to prevent the application provider from launching malicious applications to destroy the system.

Token Explorer: System updates, such as blockchain decentralized services, have always been tricky issues. Blocklet is the core component of ArcBlock, responsible for a lot of its functions, especially the adaptation of out-of-chain services. Is Blocklet likely to require frequent updates? Is there any program with better update distribution?

Robert: Blocklet itself is a microservice that needs to be frequently updated, but this problem can be solved by supporting multi-version running, where the server supports multiple different versions of the blocklet to work at the same time. In our design, developers can easily and constantly update it. Multi-version support is an important part of our entire framework and is one of our core basic functions.

Token Explorer: Microservice architecture is more frequently used for centralized servers, but ArcBlock is using this architecture to build decentralized services. Will there be consensus and consistency among the various microservices?

Robert: There is definitely a challenge there. However, it’s hard to define the line between centralization and decentralization. For example: a bank has made an application. This application is distributed in many different data centers. Some data centers are on AWS and some are on Azure. From one perspective, this is a very decentralized design, because its system is not concentrated on the same physical device, and may even be heterogeneous. But from another point of view, it is a centralized service because it is controlled by one bank organization.

Token Explorer: Is ArcBlock's smart contract implemented in a blocklet?

Robert: The concept of our smart contract is somewhat different from the current Ethereum smart contract. Ethereum's EVM can guarantee the consistency of code execution, which is very important in some instances, but not necessarily in others.

A contract often requires a lot of external trigger conditions. In Oracle, for example, once the contract has been triggered by external data, the contract loses consistency of execution. Although the code is consistent, external conditions may change or be abnormal at each execution.

Our blocklet itself is actually a framework. If an application uses Ethereum as its underlying core chain, and its contract emphasizes the consistency of its own calculations, then the contract itself should be native on-chain. But if the application has a lot of external trigger conditions, then we prefer to put the contract in the blocklet instead of putting it on the chain, because if it’s put on the chain, it may not execute its original purpose, and it may suffer performance issues.

The ultimate smart contract can be implemented in either the blocklet or on the underlying chain; it mainly depends on the positioning, function and design of the business itself.

Token Explorer: Thanks again for all of your answers. Is there anything you need to add?

Robert: This interview really helps the community understand what exactly we do and how we do it. We are very enthusiastic about collectively bringing our ideas to life with a community of people who believe in what we’re doing.

Link： https://mp.weixin.qq.com/s/9kEjYzIFFuZ1nvwu8p8OiA