How to do architectural design in a distributed system? | "Super Talk Blockchain" Issue 84 Review

This article is based on the experience sharing and summary of Bochain Education Company, the research center team of Shanghai International Trade University, members of Bochain Education Department, and my exploration of alliance chain direction on FISCO BCOS, hoping to bring inspiration and reference to everyone.

The theme of this sharing is divided into 4 parts: the first is to talk about the characteristics and differences of the distributed architecture, the second is to talk about how to design on-chain and off-chain, and the third is to talk about how to deal with the server and customers The fourth is to summarize the distributed systems we have encountered in practice.

In the development of traditional application software systems, best practices are often mentioned. For traditional software systems, after years of development, it can be said to be the best practice, but for blockchain technology, everyone, including us, is still in the stage of exploration.

The blockchain industry today is the computer industry of the 90s and is in what I would call relative best practice. All are welcome to join in and discuss the system design together.

Differences between distributed architecture and traditional architecture

Certificate system design under traditional thinking

The traditional idea is to design a centralized certificate system, which consists of three necessary parts, namely front-end, back-end and database.

The front and back ends may include many services, all of which are controlled by the main body, that is, a centralized system. This centralized system refers to the centralization of the service management body. Technically, a traditional centralized system can also be a distributed architecture.

In the centralized system, we define three types of roles, namely authoritative issuers, users and validators.

Authoritative issuers, such as a university, can issue certificates to students; users can not only receive certificates issued by authoritative issuers, but also submit their own certificates to the verifier; after the verifier receives the certificate submitted by the user, The validity of the certificate can be verified.

The certificate system under the traditional thinking has the following characteristics:

First of all, the ID in the database is unique, and the uniqueness has a limited scope, and its use scope will not exceed the database where it is located.

Second, the interactions between authoritative issuers, users, and validators all go through a centralized system. For example, authoritative issuers cannot bypass the centralized system to issue certificates to users, and verifiers cannot bypass the centralized system to verify certificates issued by users. Once there is a problem with the centralized system, all roles will be unusable.

Certificate system design under the idea of blockchain

Under the blockchain idea, the design of the certificate system may use an existing blockchain network, or it may be a specially created blockchain network. In order to facilitate the understanding of traditional developers, we often think of blockchain as a public database with open characteristics maintained by many nodes.

Due to the existence of the public database, the service can no longer be deployed by a certain company. For example, the certificate issuance service A is provided by Bailian Education. At the same time, another company also wants to provide the service, so the system is optimized and transformed on the basis of open source. It also has access to nodes, and data from both publishing services flows to a public database. Third parties with permissions can then also access the public database.

All services are not issued by a subject. On the one hand, this design increases the complexity of services, but also brings a lot of imagination.

Unique digital identity in the whole chain

When we design a normal application, the scope of the ID is the entire application, so just make sure that the entire application is unique.

In blockchain applications, the user's ID can be directly connected to the blockchain network, and it can have a unique ID in the entire chain, namely Weldentity Digital Identity (DID). This change means that the ID now has an expanded range and is unique in the entire chain.

Differences Between Distributed Architecture and Traditional Architecture

Knowing the above information, we will compare the certificate system under the distributed system with the traditional certificate system. The main differences are as follows:

First, the software life cycle. Under the traditional system, the life cycle of a service is usually smaller than that of a company; however, under the blockchain idea, the life cycle shows complex characteristics. The life cycle of the blockchain depends on all participants.

In addition, there are differences in the life cycle between these services, for example, the certificate verification service is developed by an individual, if I write the certificate verification service separately to connect to the database, even if the company providing the service goes out of business, my certificate verification service Still usable. Therefore, the life cycles of services deployed by different entities are independent of each other.

Second, provide more choices. Under the traditional system, our choice is the centralized system. Whether it is upgraded or not depends entirely on the will of the main body of the centralized system. In a distributed system, there is a competitive relationship between services. Assuming that there are three companies A, B, and C in the alliance chain to jointly provide services, everyone will naturally tend to choose the company that provides better services.

Therefore, when there are enough participants, there is actually a competition mechanism in the new system. People choose among multiple service providers, which motivates everyone to provide better services and promotes the market-oriented development of the entire certificate system.

Third, different data processing methods. In traditional systems, even if the database uses sharding in a distributed system, it is still essentially a single database, and we don't need to think about where the data is. Under the blockchain system, we need to think about which database different data needs to be stored in, and which data needs to be processed on the chain.

Fourth, the way of interaction is different. Under the traditional thinking, all participants must go through a centralized system if they want to interact with other people. However, under the new certificate system, as long as the user obtains the public key of the authoritative issuer before submitting it to the verifier, he can verify the certificate and realize point-to-point interaction between the two parties.

How to design on-chain and off-chain

When designing on-chain, it is first necessary to make good use of CNS for version management of contracts. Between different versions, we will use different version names to distinguish, such as 1.0, 2.0. This both makes the contract more intuitive and reduces the chance of bugs in the process.

Secondly, the contract should be layered, and the data layer and the data operation layer should be separated. When the contract needs to be optimized, if all the code is written in one file, the past data may have to be migrated during the upgrade. But now after the contract is layered, the stored data does not need to be changed or migrated, and we can directly upgrade the contract.

In addition to CNS and contract layering, the principles of "off the fat chain, on the thin chain" and "on the abstract chain and off the concrete chain" must be adhered to. Because the chain is actually very heavy, we store the data on the chain, and also perform calculation operations on the chain. For example, when we calculate "1+6" on the chain, each node on the chain has to execute it once, which is a lot more burdensome than running it off-chain.

When data storage is performed on the blockchain, it is stored as many times as there are nodes, and the storage load is the number of nodes; for computing operations on the blockchain, all nodes need to be calculated once.

Therefore, we need to simplify the logic of the contract on the chain, and comprehensively think about the key issues when designing the contract - whether the operation must be executed on the chain, whether the data must be stored on the chain, the developer must calculate the storage and the contract with the least computational cost.

For daily calculations like "1+6", such operations do not need to be performed on-chain. In addition, too many specific business fields are sometimes written when depositing certificates, which actually violates the principle of "abstract on-chain, concrete off-chain". Therefore, when we design the contract, we will put forward the requirement that the contract should have higher generality.

So, should the certificate be hashed on the chain? In fact, this statement is somewhat arbitrary. In actual business operations, it depends on the specific purpose.

If we are doing the business scenario of judicial evidence storage, the hash on-chain is very reasonable, because the purpose of judicial evidence storage is to check whether the original data is consistent with the hash value on the chain.

But if it is for other purposes, for example, we want to actually store operational data on the chain, json will be converted into string and then stored on the chain in business operations, but using hash will not achieve the purpose.

How to design server and client

The first is pure server. This is the easier option because it is very similar to traditional thinking. For example, if we want to make a blockchain version of Zhihu, the simple and tricky way is to make a payment website, and then only the client can access it. This method is more conservative and less error-prone, and is suitable for the initial attempt.

The second is the form of light client plus server. If you want to obtain and store the user's private key locally, when an unsigned transaction is sent from the server, please sign it from the client and send it back to the server. This kind of design is actually a new attempt to be distributed cautiously on the basis of the first step.

The third is the form of heavy client and light server. If you want to design a digital identity wallet, the Weldentity-based system can actually take the form of a client, and the new server only plays a forwarding role.

This form is bolder because it transfers more functionality to the client side, and the adoption of this approach depends on actual business needs. As far as experience is concerned, it is better not to do too innovative design at the beginning, because it is easy to have problems, it is better to be cautious.

Architecture summary in distributed system

The first example is a Weldentity-based certificate system. There are two options, one is that the user invokes the server-side certificate management service; the other is that the client is downloaded locally, and the client has exclusive management services.

This is actually a very interesting way of playing. The user's certificate management service can be either on their own computer or using a certificate management service deployed by an organization in a cloud provider.

The second is the design based on WeBASE. We can use WeBASE as a set of components in front of the node for block chaining, and host the private key on it. In this way we can save a lot of things and can utilize WeBASE to efficiently implement blockchain applications.

The third is the blockchain certificate system. We added off-chain middleware in front of WeBASE to verify the format of the content of the certificate. The contents of the certificates provided by these applications need to be verified before they can be uploaded to the chain.

There is also a public query service. In fact, many blockchain systems have such requirements and need to provide public query services for some data.

For the specific operation demonstration, please click to watch the demonstration operation:
https://www.qq.com/video/f3261okh841

"Super Blockchain"
"Super Talk Blockchain" is a live broadcast event launched by the FISCO BCOS open source community. Every Thursday at 8 pm, the community invites a technology geek or application pioneer to share development practices or application experience as a guest in the live broadcast room. As a regular community column, "Super Talk Blockchain" has held nearly 100 sessions, ranging from technical seminars to industrial applications. You are welcome to recommend yourself or recommend friends to share in the live broadcast room. Add [Little Assistant] to join the group to watch the live broadcast.

For more dry goods, please pay attention to the FISCO BCOS open source community public account, visit the FISCO BCOS code repository to download all the source code of the project: https://github.com/FISCO-BCOS/FISCO-BCOS , please click the star collection in the upper right corner of the page , to get the latest version.