Skip to main content

Application Chain Interface

Planned for a future release

The ACI and ACI registry are fundamental components in the Hypergraph's ability to process complex data types and interact with diverse data sources. Development effort on this feature is ongoing and it will be included in a future release.


Core to most distributed consensus protocols is the ability to apply consensus to the problem of secure remote code execution. Secure remote code execution requires the validation of executable binary sent to a remote server to operate in such a way that the server does not become exposed to injection attacks, essentially taking over the runtime of an application to expose data or permissions of the server. To do so in such a way that allows for a globally converged state, each consensus participant needs to know the definitions of all contracts interfacing with the global ledger.

These contracts rely on what's typically known as an ABI (Application Binary Interface) to register their API and state update methods. The binary is typically contained as a field of a JSON string or compatible data type which can be rendered into a human-readable interface to the API/contract of the stateful ledger. Typically, these have been described as a program defined within a limited execution environment (virtual machine) and API that defines a stateful "contract" for iterative state updates. However, this model is not limited only by execution environment and primitive data types, it limits state updates to serial convergence of the network: i.e. it forces a distributed system to operate in serial or sequentially, potentially allowing one contract to bottleneck others. How then could the problem of remote code execution be mitigated in a truly parallel sense?

A natural solution is to federate responsibility to parallel sub-networks and allow them to converge concurrently on partitions of the total state. To do so, the runtime environment and executable logic of smart contracts needs to be expanded. HGTP solves this with the ACI or Application Chain Interface and corresponding database. As opposed to the traditional smart contract ABI, the ACI is configurable; each node operator registers the data and execution logic they wish to validate or "mine". Because these contracts are for their own independent networks, whose ledgers are off-chain with respect to the Global L0 ledger, in HGTP they are referred to as State Channels.

General architecture

Each node stores the ACI of the channels it wishes to validate in a service called the ACI Registry. The flow of registration is described in the following diagram and reference implementation.


The entry point is the ACI Server which access it the main resources via ACI Context.

One resource contained within the ACI Context, the Runtime Loader instantiates the serializers necessary to deserialize state channel data (kryo registrar).

Local Multi-Channel Validation (alpha)

An example is provided in the ACI App which loads the definition from the Example Manifest and can be run as a local jar file. This is extendable to implement multi-layer validation as described by the following diagram.


We see that incoming data is then deserialized by the ACI and processed by the state channel's Cells (algebra/coalgebra). Note that sandboxing and use of JVM secure classloader should be used in tandem for proper security.

DAG L0 validation

Each state channel is meant to serve a specific use case and the DAG L0 is no different. The purpose of the DAG L0 is to provide a meta consensus process that allows L1 ledgers to swap values. To maximize security, scalability, and decentralization for this use case, the DAG L0 ACI contains definitions for performing hash-based validation on ledger state as each state channel's executable and contains fields necessary to define a state channel's liquidity pool which is a configuration for handling transactions and normalization across L1 ledgers.