"Modular process of cross-chain gateway" plug-in mechanism evolution

-- background--

At present, the access methods of the blockchain cross-chain platform are quite different in terms of architecture design. How to quickly and conveniently connect the application chain to the cross-chain system is an urgent problem to be solved. The BitXHub cross-chain service platform of BitXHub adopts the cross-chain solution of relay chain + gateway, in which the cross-chain gateway plays the role of collecting and disseminating transactions between blockchains. The design of the plug-in mechanism decouples the module that interacts between the gateway (Pier) and the application chain from the core function module of the cross-chain gateway, so that different types of application chains can be efficiently connected to the cross-chain system. When Pier is running, the flexible adaptation of different application chains is completed by dynamically loading plug-ins. In order to better enhance the interaction between Pier and the application chain, specific application chain plug-ins need to implement specific interfaces according to the characteristics of different blockchains. The interaction interface needs to meet the following functions:

1) Monitor cross-chain events on the application chain and pass them to the core module for processing;

2) Execute cross-chain requests from gateways (from other application chains);

3) Ability to actively query the status of received and executed cross-chain requests on the application chain.

In the design of the plug-in implementation scheme, we have adopted two different plug-in mechanisms successively. The following will introduce the problems we encountered when using the native plug-in and the advantages of the new plug-in solution.

—— Native Plugins——

The go language supports compiling as a plug-in from version 1.13, and the usage is as follows

• go build --buildmode=plugin -o appchain.so *.go

The go project can be specified as a plug-in mode through --buildmode when compiling, and the output will be a dynamic link file in this way. This file is not a binary file that can be run directly, but a dynamic call provided to other binary runtimes.

Used in the main binary as follows:

advantage:

advantage:

1) The user experience is consistent with native code, similar to the binaryization of code modules;

shortcoming:

shortcoming:

1) The dependent library in the native plug-in must be completely consistent with the main program, otherwise an error will be reported when starting, and this problem will occur regardless of whether the dependency is directly referenced or indirectly referenced.

—— Switch to RPC plug-in ——

The strict version restrictions in the native plug-in make it possible that when upgrading the plug-in and/or gateway main program functions, some dependencies of the main program may be unintentionally upgraded, and the plug-in must also make the same adaptation upgrade. This method is not conducive to the complete decoupling of plugins, so we turned to another GO plugin project that uses RPC. (GitHub address of the project: https://github.com/hashicorp/go-plugin)

Hashicorp's go-plugin already existed before the native plug-in mechanism of GO appeared, but after the native plug-in of GO came out, they did not give up their support for the project, because in general the native plug-in is not very perfect. In some scenarios, go-plugin is more convenient.

The go-plugin plugin is used as follows:

To put it simply, the plug-in method implemented by the go-plugin project adopts the C/S mode. The main program is used as RPC Client, and the specific plug-in is used as RPC Server. The communication between Server and Client is also based on the interface specification.

The specific usage process is as follows:

1) Abstraction requires a plug-in interface. Here, the interface definition used in the native plug-in can be directly reused;

2) Both the client and the server implement the above interface. The server-side implementation is the code for the specific plug-in processing logic; the client-side implementation only needs to encapsulate the gRPC processing results and exception information, and then the main program can be weakly aware of gRPC when using the plug-in.

Server implementation part:

Client implementation part:

▲Additional attention should be paid to:

• The plugin needs to call plugin.Serve to authorize the main program to use its own RPC service. It should be noted here that a handshake is required before the main program and the plug-in communicate, mainly including confirming the version information of the plug-in.

• The main program uses the plugin.Client object to start the plugin, which runs in another process, so the crash of the plugin will not affect the main program.

• The client and the server actually communicate through the inter-process Socket during use. Although this sacrifices a certain amount of performance, it brings in flexible applications such as dependency decoupling and multi-language support that the single-process solution of the native plug-in does not have.

—— Conclusion——

About the Author

About the Author

FunChain Technology Data Grid Lab BitXHub Team

FunChain Technology Data Grid Lab BitXHub Team