ARK Core v2 Technical Update Series — Plugin System

In previous blog posts, we briefly mentioned a new system we are developing that would transform the ARK Core v2 into a basic plugin / modular concept. Since then, the first implementation has outgrown it’s initial concept so much so that we decided it needs a dedicated post to explain the upcoming changes. We are very excited at how it has turned out so far and believe that it will make our system much more powerful in the future.

ARK Core v2 will be split into multiple packages using Lerna to manage development and publishing of those packages.

The benefit of this approach is that it is easier to focus on smaller parts of the whole system in isolation. Each part of the core can be easily replaced by custom implementations, imagine a core-logger-logstash package that replaces the default logger.

Everything should be easy to replace, remove or disable in modules, which also makes it possible to just tag a new version of the core-database if, for example, a database fix needed to be done instead of having to tag a new core release. We can split the whole core into modules and provide a lego-like experience for building your own node (provide chain manager, forger, transaction pool, etc. as default and APIs, webhooks, etc. as optional modules).

For instance, using this method, relay nodes wouldn’t need to include the core-forger module. This change also makes it easier for bridgechains and forks to modify the core as they can swap their custom implementations in without too much effort.

To put these updates in perspective, have a look at the current structure of the modules for ARK v2 (note that this is not final and we might add more or modify current ones with different implementations):

The Plugin Manager

All of those plugins are interconnected via the core-plugin-manager package, which functions as a container to hold all the instances that are shared across plugins.

The plugin manager allows us to provide different Bootstrap processes for things like starting a relay node or a forging node.

The plugin manager accepts 2 parameters, the path to a folder that contains a plugins.json file and an optional parameter that can contain options like including and excluding plugins from the Bootstrap process or plugin specific options that are not available from the configuration file.

Configuration

The basic plugin.json at the moment looks roughly like this and is subject to changes.

Lifecycle & Hooks

The lifecycle of the ARK Core process is split into 4 steps that have to be registered in that exact order.

init

The init hook in the lifecycle is the start, which usually just consists of registering the configuration so that everything after this point has access to all required data.

beforeCreate

The beforeCreate hook in the lifecycle registers any plugins that require configuration (init) but also need to be registered before the blockchain manager is initialised. This means that your beforeCreate hook in the plugins.json always has to have @arkecosystem/core-blockchain as the last plugin.

beforeMount

The beforeMount hook in the lifecycle registers any plugins that need access to configuration (init) and rely on the blockchain manager (beforeCreate). Those plugins are usually things like database connections or P2P management as they need the blockchain manager to be available as they are bound to it.

mounted

The mounted hook in the lifecycle is the last one that will be processed and currently is only used to mount the public and webhook APIs as they rely on the blockchain manager (beforeCreate) and database connections (beforeMount). These hooks provide access to all core plugins of the system that you would need.

Bootstrap

The basic bootstrap for a relay node using the plugin manager looks like this at the moment.

As you can see in the above image we passed the exclude option to the plugin manager which will let it know to not register that specific plugin, in this case the forger which is not needed for a relay node.

Here is another example of the Bootstrap process, but this time to just start the forger without a full node.

If you remember the exclude option from the previous image the include option will be self explanatory. All it does is tell the plugin manager to only register plugins that are included in this list.

Having the plugin manager handle all instances allows us easier testing as we are able to create, register and bootstrap exact copies of the original plugins that return fake data as we need more control about what data is used when in a normal development environment.

Plugin Structure

Plugins are very simple to write. At their core they are an object with a register property, that is a function with the signature async function. Additionally the plugin object has a required name property and several optional properties including version.

— The register method accepts two parameters, manager and options.
— The manager parameter is an instance of the plugin manager to provide you easy access to other plugins like configuration or database connections.
— The options parameter is whatever options the user passes to your plugin when registering.

register should be an async function that returns once your plugin has completed whatever steps are necessary for it to be registered. Alternatively your register plugin should throw an error if an error occurred while registering your plugin.

When the core goes live on Devnet for testing there will be a full guide on plugin development, what it offers and what requirements have to be met.

Configuration Manager

The first plugin that is mounted after the plugin manager is ready is the configuration manager and a configuration driver which offers a concrete implementation of an interface.

Let’s take a look at how a configuration driver can be registered through the plugin manager to make it available to the application.

The first thing we need to do is to get an instance of the configuration manager which allows us to pass in a driver which implements the configInterface provided by @arkecosystem/core-config.

Each configuration driver has to contain a make method, this method will be called by the configuration manager to setup the configuration and make it accessible to the application.

Allowing developers to easily implement new configuration drivers opens up new abilities. For example, in a private network where you could have 500 nodes that share the same configuration and 1 server would provide the configuration for all those nodes through an API.

This would allow you to update the configuration for all those 500 nodes without having to make any changes to the nodes itself other then restarting them so they pull in the configuration from the master server.

Database Manager

The database manager serves the same purpose as the configuration manager but this time for database connections instead of configuration loading.

As you can see it follows the same pattern as the configuration driver. Each driver has to contain a make method which will be called by the database manager to setup the database connection and then expose it to the application.

Allowing developers to create custom database drivers will make it easier for big private chains to scale as they could implement and use things like Cassandra.

Log Manager

The last manager we will talk about is the log manager which provides the same functionality as the configuration and database managers.

A log driver has to implement a LoggerInterface which provides common base functionality that is required for the core to log messages.

Each driver has to contain a make method which will be called by the log manager to setup the logger and expose it to the application.

Allowing developers to create custom database drivers will make it easier for big private chains to manage their logging as they could implement things like logstash for log collection.

Closing Words

The introduction of modular code plugins in ARK Core v2 will allow for a robust and feature rich toolbox as we move forward in the development of our Point. Click. Blockchain system and the first visual, GUI based version of the ARK Deployer. Much like the other changes being made in v2, this is one step closer to being able to realize the full vision for the ARK Ecosystem.

Note that things are subject to change as this is still under development.

ARK.io | Github | Facebook | Twitter | Forum | Blog | Explorer | Shop