Welcome everyone to the second part in our series of tutorials based on the ARK Messenger Proof-of-Concept (PoC). During Part One, we set up a development environment and deployed our own custom bridgechain. This series was created in-part with documentation provided by Delegate Lemii as part of his ARK Messenger Proof-of-Concept, funded by the ARK Grants Program.

One of the main goals for this series is to successfully demonstrate the different ways developers can work with ARK Core. In this part of the series, we will learn to develop and test a custom transaction for our bridgechain. In addition, we will also be developing the client, which is the front-end application users will use to interact with the messaging service.

Getting Started

Before we get started with developing and testing our custom transactions, we need to outline the technical specifications for the application. This is important because it is very difficult to make changes once these parameters have been established. Let’s take a look at ARK Messenger’s technical specifications as an example.

ARK Messenger implements a custom Message Transaction. This is a transaction that will hold the encrypted message that is being sent by the user. The transaction should follow these rules:

Set transfer amount to 0, and apply a low static fee (currently 0.01).

Be able to store a relatively large amount of message data (1024 bytes).

Must have a unique type and type group (101, 1001).

These were considerations made prior to developing the custom transaction. In addition to outlining your technical specifications, you may want to familiarize yourself with how custom transactions work on ARK. The article listed below will give you a solid base in understanding how smart/custom transactions work on the ARK Core Blockchain Framework.

Creating a Custom Transaction

Creating a custom transaction is a straightforward process. We will be using ARK Messenger’s custom transaction — Message Transaction as our template.

The custom Message Transaction is based on the Business Registration Transaction from the guide above. For reference, you can find the code here.

In order to create our custom transaction, we will be going over the transaction class, the transaction handler, and the transaction builder below. Please use the files below while working on each one:

Message Transaction (Creating our Custom Transaction)

At the very top, we define our custom type and type group:

const MESSAGE_TYPE = 101; const MESSAGE_TYPE_GROUP = 1001;

Just below that, we define our transaction schema:

public static getSchema(): Transactions.schemas.TransactionSchema { return schemas.extend(schemas.transactionBaseSchema, { … } }

One difference you will notice, unlike the Business Registration Transaction, we included the recipientId field in our schema. This is because this field is used as the ‘channel id’ for our purposes. Apart from that, we define the rest of the transaction and our message object that will be used for message data.

Below the schema, we define our static fee of 0.01. The value we use is 1000000 because the ARK SDK does not work with floating-point numbers and the number of decimal places is 8.

As for the serde (serializer/Deserializer) functionality; it mostly works the same as the Business Registration Transaction, with the exception of two important things:

The writeUint8 buffer function is limited to a size, 256 bytes. Since we want to process message data of 1024 bytes maximum, we must use the writeUint16 variant instead.

buffer function is limited to a size, 256 bytes. Since we want to process message data of 1024 bytes maximum, we must use the variant instead. Because we want to use the recipientId in the transaction, we must include it in serde process as well:

Serializer:

const { addressBuffer, addressError } = Identities.Address.toBuffer(data.recipientId);

options.addressError = addressError;

buffer.append(addressBuffer);

Deserializer:

data.recipientId = Identities.Address.fromBuffer(buf.readBytes(21).toBuffer());

Message Transaction Handler

Next, we will work on the Message Transaction handler. Since the Message Transaction is relatively simple, we can omit most of the logic from the Business Registration Transaction handler.

Using throwIfCannotBeApplied we explicitly check if the message data is valid:

const { data }: Interfaces.ITransaction = transaction; const { message }: { message: string } = data.asset.messageData; if (!message) { throw new MessageTransactionAssetError(); } await super.throwIfCannotBeApplied(transaction, wallet, databaseWalletManager);

At applyToSender and revertForSender we perform the default apply and revert actions. The methods applyToRecipient and revertForRecipient are not utilized because none of the recipient’s attributes are mutated by processing the Message Transaction.

Apart from that, we let the base TransactionHandler… “handle” the rest

Message Transaction Builder

The builder that is present in this file will be used in the ARK Messenger Client to create Message Transactions whenever a user submits a message.

First, we initialize the data object with the class constructor() method:

constructor() { super(); this.data.type = MessageTransaction.type; this.data.typeGroup = MessageTransaction.typeGroup; this.data.version = 2; this.data.fee = Utils.BigNumber.make("1000000"); this.data.amount = Utils.BigNumber.ZERO; this.data.asset = { messageData: {} }; this.data.recipientId = undefined; };

Next up, we create a method that we can use to add message data to the transaction:

public messageData(message: string): MessageTransactionBuilder { this.data.asset.messageData = { message, }; };

Finally, we need to add the non-standard fields to the transaction data object for when it is called with getStruct():

const struct: Interfaces.ITransactionData = super.getStruct(); struct.amount = this.data.amount; struct.asset = this.data.asset; struct.recipientId = this.data.recipientId; return struct; };

Testing the Custom Transaction Builder

There are a number of ways to test your custom transaction. One of the best options is to create a test file with Jest. This tester is also used for other ARK packages, so this is a nice synergy.

At the top, we import all the required packages:

import “jest-extended”;

import { Managers, Transactions } from “@arkecosystem/crypto”;

import { MessageTransactionBuilder } from “../src/builders”;

import { MessageTransaction } from “../src/transactions”;

Next, we need to make some adjustments with the config manager to be able to actually create the transaction. First, we select the testnet network preset and set the height to 2. This will enable the AIP11 milestone.

Managers.configManager.setFromPreset(“testnet”);

Managers.configManager.setHeight(2);

Now we include our new custom transaction to the transaction registry:

Transactions.TransactionRegistry.registerTransactionType(MessageTransaction);

The configuration is now complete. What’s left is to create a test that verifies that the transaction can be built and verified:

describe(“Test builder”, () => {

it(“should verify correctly”, () => {

const builder = new MessageTransactionBuilder();

const tx = builder

.messageData(“SomeMessage”)

.nonce(“3”)

.recipientId(“AYeceuGa7tTsyG6jgq7X6qKdoXt9iJJKN6”) .sign(“clay harbor enemy utility margin pretty hub comic piece aerobic umbrella acquire”);

expect(tx.build().verified).toBeTrue();

expect(tx.verify()).toBeTrue();

});

});

Lastly, we will verify these transactions on the network.

Testing the Custom Transaction on the Network

When the builder test has been passed, we can continue with the custom transaction integration for the bridgechain. First, we need to include the custom transaction as a plugin in the bridgechain.

Information on how to create a plugin can be found here: How to Write a Core Plugin

You can view our Message Transaction plugin file here: plugin.js.

To integrate the Message Transaction plugin in the bridgechain, we simply have to include it at the bottom of the plugins.js file found in ./packages/core/bin/config/{network}/plugins.js

module.exports = { …. “message-transaction”: {}, };

Now, when we run yarn setup to install the bridgechain, it will automatically install the custom transaction as well and include it as a plugin on startup.

When the bridgechain is running (locally), we can verify that the custom transaction is integrated correctly by checking the following API endpoint: http://127.0.0.1:11003/api/transactions/types

If our custom transaction is present in the list of available transaction types, we can try and post an actual transaction to the blockchain to see if it processes correctly. This can be done in many ways, but the preferred way is utilizing simple scripts.

The test is complete when the transaction is broadcasted and processed by the network. We have now successfully implemented our custom Message Transaction! The next step is to develop the chat client that the user will interact with.

Using the custom transaction in the client

As mentioned earlier, the client has been created with ReactJS and is written in TypeScript. The full codebase can be viewed here.

To make use of the custom transaction in our chat client, we first have to include some of the files in our project. The parts that we need are the Message Transaction and Message Transaction Builder. We can simply copy-paste these from before, and place them in the /src/ folder. Since the Message Transaction Handler is only used for the Core, this can be omitted.

Now, we can simply import the Message Transaction Builder anywhere in our app to make use of it. In the ARK Messenger client, it is being imported in a separate utils file, as you can see here.

import { encryptMessage, fetchRemoteNonce, broadcastTransaction } from ‘./index’; import { Transactions } from ‘@arkecosystem/crypto’; import { ITransactionData, IPostTransactionResponse } from ‘../interfaces’; import { MessageTransaction } from ‘../custom-transactions/message-transaction/transactions’; import { MessageTransactionBuilder } from ‘../custom-transactions/message-transaction/builders’;

It’s required to register the new transaction type in the Transaction Registry:

Transactions.TransactionRegistry.registerTransactionType(MessageTransaction);

We’re using a custom network version defined in an environment variable. We store this in a const variable that will be passed on to the transaction builder:

const NETWORK = Number(process.env.REACT_APP_NETWORK);

Finally, we can call the builder in our custom transaction functions that will be used for the chat functionality:

const createMessageTransaction = async ( recipientId: string, encryptedMessage: string, passphrase: string, senderId: string ): Promise<ITransactionData> => { const nonce = await fetchRemoteNonce(senderId); const tx = new MessageTransactionBuilder() .network(NETWORK) .recipientId(recipientId) .messageData(encryptedMessage) .nonce(nonce) .sign(passphrase); return tx.getStruct(); }; export const sendMessage = async ( recipientId: string, text: string, channelPassphrase: string, userPassphrase: string, userAddress: string ): Promise<IPostTransactionResponse | void> => { const encryptedMessage = encryptMessage(text, channelPassphrase); try { const tx = await createMessageTransaction( recipientId, encryptedMessage, userPassphrase, userAddress ); return broadcastTransaction(tx); } catch (err) { console.error(err); } };

Alternatives to this approach are:

Upload the custom transaction as a module to NPM.

Make use of Git Submodules.

Next Steps

In our next and final tutorial, we will be deploying a bridgechain and launching the client application. In addition, we will be highlighting all of the examples pertaining to how developers can work with the ARK Core. With future updates and improvements, ARK Core will continue to be one of the simplest and most flexible ways to build blockchain solutions.

If you become stuck at any point, make sure to consult our documents on the Learn ARK hub. In addition, our team and community developers are active on Slack so do not hesitate to reach out!