AstraKode Blockchain, the new intuitive and customisable blockchain platform
Despite its breakthrough more than 10 years ago, blockchain has not yet become mainstream. There are many reasons behind the slow and limited use of this technology and we already discussed them in the article “Barriers to blockchain adoption: low-code as a solution”.
More recently, we conducted a survey on a sample of 133 blockchain experts, investigating such barriers. The results confirmed that the following are major limitations in the use of blockchain technology:
- wide technology stack;
- scarcity of documentation resources;
- difficulties in network design and configuration;
- conceptually complex technology.
Stemming from these needs, we ideated AstraKode Blockchain (AKB).
Drawing from the “Hype Cycle for Blockchain Business” by Gartner (2019), we can place blockchain technology in the Innovation Adoption Lifecycle (‘Rogers bell curve’, on the right), at a stage between “Early Adopters” and “Early Majority”. From this, we are able to infer that in the next 10 years the technology is likely to reach widespread adoption. Thus, it is not a matter of whether mass adoption will be achieved, it is just a matter of time. How can this process be facilitated?
AstraKode Blockchain, or simply “AKB”.
AKB is a PaaS (Platform as a Service) solution that uses a low code approach to easily design and develop blockchain networks and smart contracts.
Being an assisted solution for the development of Hyperledger Fabric networks (and applications), the platform can be considered as a spiritual heir to the now deprecated Composer from the Hyperledger family (we have talked about it in this article).
The main objective of the platform is to facilitate the implementation of any level of blockchain solutions, especially for enterprises. AKB provides tools that simplify the three main mechanisms of the process: network design, smart contract development, and subsequent deployment. These tools are:
- Network Composer: a visual development environment for blockchain network design and customization
- Smart Contract IDE: a visual development environment completely dedicated to smart contracts (not available in 1.0.0 version )
- Cloud deployment: a dedicated environment for integration with main cloud service providers to ease the implementation of blockchain projects created with AKB.
- Integrated community: here users can actively participate in discussions about projects, ask for support, and get access to valuable learning content about both the platform and the technology itself. This includes tutorials, technical articles, and much more. In this way, we enable also less experienced users to create their own blockchain network.
The low-code approach allows both environments to be equipped with configurable visual elements and guided processes, able to abstract and automate many complexities of traditional development, such as the self-documentation, monitoring, and project testing/validation.
Now, let’s have a closer look at the platform.
Buckle up, it’s time for the virtual tour!
As a first step, you need to register to the platform (Moon). Your account will be validated by entering a numerical code received by email. We will now delve deeper into the key functions offered by AKB.
After logging in, users are redirected to the platform’s homepage. The left sidebar, also present in the Composer, can be used to navigate the platform, with the addition of several other useful external links, such as AstraKode.tech and What’s new?.
The top right corner provides the means to access and modify one’s user profile (through the avatar widget), log out of the platform, and access the virtual tour process (question mark widget).
The central area of the homepage, its heart, is dedicated to blockchain projects. Here one can either create a new project or open an existing one. Existing projects are shown via expandable “cards” that summarize them to varying degrees of granularity to make them more easily identifiable. By clicking on a project’s card, the preview will be expanded to show additional information, such as the project’s visual layout, and a feed of the most recent project activities (still partly under implementation). Finally, to the top right of the expanded preview one can find buttons to open the project, share it, or minimize the preview.
Going back to new project creation, an AKB project can either be of the “Network” or “Logic” type. Since the Smart Contracts IDE is still under development, for now only projects of the “Network” type can be created. After deciding which project type one wants to create and entering some descriptive information, one will be able to select the blockchain technology for the project (currently only Hyperledger Fabric, with future plans to include other popular implementations), and its version. Once this initial configuration is complete, one is redirected to the Network Composer, the development environment dedicated to AKB Network projects.
The visual approach provided by the Composer allows users to quickly and intuitively design all aspects of the network by simply adding and configuring network settings and components. More in detail, a typical Composer project for Hyperledger Fabric will begin by defining the organizations that are going to participate in the network. This is done via the “+” button on the left sidebar of the Composer, under the Organizations tab.
Once an organization is added and named, its type and up to two Certificate Authorities (CAs) can be configured within the same modal window. The type property points to whether the organization is going to participate in the network as a client or as an orderer, whereas CAs are used to provide means of authentication to any party that needs to perform operations on the network on behalf of that organization. As Hyperledger Fabric CAs are designed to provide two types of certificates (MSP or TLS), one is free to decide whether to set up a separate CA for each certificate type, or just utilize a single CA for both.
Once the various organizations have been configured, it is necessary to define one or more consortia, i.e. a group of client organizations that need to conduct transactions with one another. These are the organizations that form and join channels and that own peers. Again, this is done via the “+” button on the left sidebar of the Composer, this time under the Consortia tab. Once consortia are named and their participant organizations defined, it is finally time to begin modeling the network.
The first step in the modeling process is the creation of channels. As defined by the Hyperledger Fabric documentation, channels are private “subnets” of communication between two or more specific network members, for the purpose of conducting private and confidential transactions. As channels are intrinsically tied to a particular consortium, the addition of new channels to the development canvas is governed by the “Add Channel” button under a specific consortium definition in the left sidebar.
Channels are visually represented on the canvas by a horizontal rectangle. In their configuration, one can define its name and members, i.e. its participant organizations (note that such organizations should also be part of the consortium tied to the channel).
Once a channel is defined, by selecting its component on the canvas one is able to add peers and an ordering service via the “+” button on the top right corner of the component (note that peers and ordering services can also be shared by multiple channels. This can be done by selecting an existing component instead of creating a new one). All mandatory actions that have yet to be performed, together with any other design validation issues, are flagged by the automatic validation tool accessible via the right sidebar under the Community Feed (under the “Project Issues” label).
In the above case, the platform is reminding us that it is necessary, once channels have been configured, to define at least one participant peer. Peers function as points of access for an organization to a channel and are thus needed to enable an organization to read or write on that channel’s ledger (granted that it has permission to do so).
Each peer is represented on the canvas by a rhombus, and by configuring it one is able to name it and define the organization it belongs to (owner), as well as several network parameters such as its IP and ports.
Finally, as also pointed out by the validation tool, an ordering service must be configured for a channel to operate properly. The ordering service is a collection of orderer nodes managed by the same orderer organization, responsible for the ordering of (endorsed) transactions into blocks, and for the delivery of the block to the relevant peers. Furthermore, orderer nodes also maintain some system information so that they can validate and manage system requests such as new channel creation or new peer additions.
Next to naming, the component’s configuration allows one to define the orderer organization responsible for the ordering service, as well as up to five orderer nodes (together with their network parameters).
Once the configuration of each component is complete, it will be possible to “generate” the network’s source code (plus some scripts for its automated deployment) and download it locally. However, as this functionality is still under development (ETA: Q1 2022) for the moment it will only be possible to design the network. In future updates, we also plan to integrate cloud testing and deployment functionalities so that the network can be easily tested or deployed to the cloud directly via the platform. For more information on current and planned features, please consult the 2022 roadmap available on the AstraKode Blockchain website.
Even if Moon represents the first prototype version of the AstraKode Blockchain platform and as such is not yet able to offer all the planned functionalities, we believe that it is already able to provide substantial value. Thus, we encourage you to come and try it first-hand (free of charge) by visiting AstraKode.tech. See you soon, AstraKoder!