Any new implemented Custom Transaction will be packed inside a core module and deployed on the blockchain as a core dApp.
A general overview of important classes supporting custom transaction development can be seen in the Class Diagram picture below. Abstract classes and methods in the class diagram are presented with italic text.
To develop a custom transaction type we need to implement code-contracts defined by GTI interfaces and abstract classes (the blue colored items in the class diagram above). Implementation is pretty straight forward. We override default transaction behaviour and add custom business logic, by implementing the Transaction, Builder and Handler type classes (the green-colored items in the diagram above) by following the guides below:
Most of the real-world interactions are transaction-based/event-based. Having the ability to add your custom functionality on top of existing distributed ledger technology with ease and reuse its benefits — the possibilities are endless.
For example, we can build:
audit log, tracking functionalities (GDPR, ISO-27001 support by default),
supply chain management transactions, e.g. following specific parts through receiving, manufacturing, quality assurance, packaging, distribution, maintenance, and disposal over the entire product life cycle,
healthcare, e.g. tracking of events, combined with storage of large medical data sets via IPFS network,
IoT network support, e.g. custom transaction for device registrations and storage of additional sensor data,
NFT token support,
administrative role-based system governed by blockchain,
… and much more — the list is endless.
All of the above-listed examples are transactions in the real world and can be implemented with our core GTI engine. Meaning, as a developer, you can add the new business logic to a blockchain by introducing additional custom transaction types tailored to the application. So, the next thing you need to implement is an awesome front end to support your business. Your new application becomes a light-client by default, leveraging the power of the blockchain platform in the background.
Each newly implemented transaction type becomes a full member of a core node after the registration call — meaning we can query it via existing Public API interfaces, after the plugin is deployed on the blockchain.
We provide different programming language implementations of our API, all accompanied by full cryptography protocol implementation. Simply install the SDK of your choice and start interacting with the blockchain. For more information about our SDKs (REST API and crypto) refer to https://sdk.ark.dev.
Use the Builder class to create transaction payloads and send it to the core nodes.
In the next subsections we will learn how to:
Implement a new transaction type structure
Implement a new custom transaction builder class
Implement a general transaction handler that hooks our newly created transaction type with the blockchain protocol
Use existing API interfaces to interact with core blockchain and new transaction types.
Your newly implemented transaction type can now be packed into a core dApp and distributed to any ARK technology-based bridgechain (API and protocol compliant).