Overview

ADAPT (A Decentralized Application Programming Toolkit) is:

  • A framework for building distributed data fabrics that serve as intelligent and secure data backends for internet applications.
  • A toolkit you use to build end-to-end decentralized systems in both public and enterprise web3 contexts. ADAPT is used to develop software that manages highly-critical data, provides secure storage, and creates isolated data manipulation facilities.
  • A flexible platform for decentralized data management, supporting a wide range of existing secure environments, from secure enclaves to zero-knowledge-proof virtual machines.

ADAPT provides platform level features for software attestation, peer-to-peer data sharing, and secure inter-organizational workflows. Use ADAPT:

  • To implement any distributed secure application, from multi-device authentication, to decentralized identity and zero-trust data services.
  • As part of a SaaS software stack to provide additional security to critical data, such as cryptographic keys and sensitive information about your customers.

ADAPT is designed for holistic security of both the data and the business logic that governs the data. It is not a high-performance query and data analysis tool, but rather a system designed for secure multi-node operating environments where performance requirements are light, but security requirements are high.

The best place to start with the ADAPT framework is by looking at the page for the E2E-encrypted messenger demo built using ADAPT that contains links to both the live demonstration and the code sandbox that enables you to play with the code in a live environment.

There is a detailed tutorial the describes the process of building the messenger demo application. Part1. Part2

Anatomy of the ADAPT Framework

The ADAPT toolkit consists of:

  • A compiler for the MUFL language, a special-purpose programming language for data manipulation with strong external isolation.
  • The ADAPT execution environment, responsible for data storage and encryption, communication with the outside world, and for interpreting compiled MUFL code.

The key concepts of the execution environment are:

ADAPT Packets

An ADAPT packet is a data structure representing an intelligent data store (smart database). A packet contains application data and the business logic code that carries out all requests for data access or modification. Data is defined by the application developer for a specific use case, for example, cryptographic keys, personal data, permissions, event history, or anything else.

A packet is a tight association between data and its business logic code, designed for a high degree of integrity and verifiability. The code associated with the packet is responsible for overseeing data organization and state transitions, which the packet undergoes in response to requests coming from outside the packet. Each packet specifies its own API, that is, a valid set of requests that the packet is able to process.

For more information, refer to Packets in ADAPT Data Model.

ADAPT Nodes

An ADAPT node is a small-scale request-response server that tightly controls both the business logic code and the data being stored. Nodes can run identically anywhere: in your browser, in mobile environments, on servers, and inside secure enclaves. Nodes can run as standalone servers and as components embedded in application front ends. Front-end nodes are additionally responsible for communicating with the user, as required by the application’s business logic.

Each node consists of:

  • One or more ADAPT packets.
  • A security environment that protects the packet(s) from unauthorized access.
  • A network interface that accepts messages, passes them into the node, and invokes a packet’s state transition as requested.
  • Optionally, when the node is deployed on the front-end of an application, an interface between the node and the application into which it is embedded.

Each node:

  • Stores packets containing application data.
  • Protects packets from intrusion.
  • Processes requests.
  • Maintains packet backups and transaction logs.
  • Ensures appropriate backup/restore functionality.
  • Connects to the ADAPT message broker and is responsible for sending and receiving requests on behalf of its packets to/from other nodes through ADAPT’s messaging protocol.
  • and for front-end nodes, interacts with the user as appropriate.

ADAPT nodes talk to each other through a simple message-passing protocol. This approach allows developers to implement multi-node workflows that establish shared functionality between the nodes. ADAPT significantly simplifies the use of secure enclaves in your software applications by carrying out enclave attestation as part of the framework, leaving only the business logic of the application to the developers, not the low-level complexity.

ADAPT nodes come in different forms:

  • AWS Nitro Enclaves node
  • Linux server node
  • Embedded backend node (node.js application)
  • Embedded front-end node (browser application)

Nodes can be deployed in either of these ways:

  • As part of a DevOps process by the organization that developed the application.
  • Automatically inside application front-end components residing on user devices.

ADAPT Transactions

An ADAPT transaction is a distinct request sent to a node through ADAPT’s messaging protocol. Each transaction carries some data as input. If the transaction execution is successful, it might change the state of the packet and/or return some output. Output of a transaction might consist of requests to invoke transactions on other packets in the network, and if so, the ADAPT node is responsible for forwarding those requests appropriately.

The ADAPT node software may receive transaction requests from the outside world as well as from the application into which it is embedded. Transactions are forwarded to the packet’s business logic software which evaluates the code associated with each request.

The transaction API, as well as the rest of the business logic, is written in MUFL, the ADAPT’s special purpose language.

All access to data inside a node is governed by the business logic, and so must be accessed by using one of the transactions provided.

Lifecycle of an ADAPT Node

(old_state,transaction_name,input) -> (new_state,output)

The typical lifecycle of an ADAPT node is:

  1. The node software is developed by combining the MUFL standard libraries with custom-built, use-case-specific components.
  2. The software, once compiled and tested, is used to initialize a packet. Once initialized, packets can respond to transaction requests. The ADAPT node software takes care of storing the transaction log and packet backups as required by the environment in which it runs.
  3. The packet is deployed, along with the ADAPT execution environment into its secure operating environment, thus creating an ADAPT node. ADAPT supports multiple secure environments, from server-side secure enclaves, to browser add-ons, to IoT devices, to mobile application containers. Nodes can be deployed either as part of a DevOps process by the organization that developed the application in question or automatically inside application front-end components residing on user devices.
  4. Once deployed, the ADAPT execution environment may receive transaction requests from the outside world. Transactions are forwarded to the packet’s business logic software which evaluates the code associated with each request. While some requests may come from remote agents on the network, others may originate from a user interface, provided the node is deployed inside an application that has user interface.
  5. Upon successful completion of the request, the execution environment may generate and record a new state of the packet, return some information to the originator of the request, or both.