Caution: tech talk ahead! The wall of text below is a very technical high-level overview of Juxtareum's architecture and design. Details, diagrams, walk-throughs, and lots of other goodies are coming soon. In the meantime, if you're interested in some of the gory details of the Juxtareum internals and dynamics, give this description a once-over.
What Juxtareum does
Overview
Juxtareum is a blockchain-based consensus network that serves as a platform for knowledge applications - kapps for short.
Kapps have a client-server structure. Kapp services are predominantly created by users, and are submitted to and permanently stored in Juxtareum. Kapp clients are created by users, run outside Juxtareum, and interact with kapp services via the Juxtareum messaging API.
Juxtareum essentially acts as an application server, processing messages from kapp clients, invoking kapp services in response to those messages, and running the kapp services in a powerful but tightly controlled environment.
The Juxtareum blockchain ledger is publicly accessible and verifiable, but is encrypted and private - an essential feature made possible by an innovative combination of multiparty computation (MPC), homomorphic encryption, and trusted execution environments (TEEs).
And since it's a decentralized consensus network in the spirit of Bitcoin, Ethereum, and the like, it's unstoppable and uncensorable.
Juxtabase
At the conceptual core of Juxtareum is the Juxtabase knowledge base.
The Juxtabase specification defines a schema for the construction of this knowledge graph from fundamental building blocks called entities. The handful of Juxtabase entity types including statements (similar to statements in RDF or datoms in Datomic), as well as concepts, sets, users, and code.
The global state of Juxtareum at any given time is comprised of a canonical set of entity instances forming a knowledge graph of nodes, edges, and recursive collections. Juxtabase is an immutable, accretion-only knowledge base: entities can be added but not removed, and logical deletion and modification are treated as application-level notions.
Each entity has a modifiable access control state that specifies which users can access it. This access control state is modifiable but is grow-only: once access has been given to a user, it can't be retracted.
Each entity also has a unique address in an address space that is compatible with that of Ethereum. A user creates an externally controlled account by generating a unique cryptographic keypair. Addresses of entities of other types are generated deterministically by the system. External accounts and kapp service code utilize these addresses to reference arbitrary entities, and entities use these addresses to reference each other to form the knowledge graph.
The persistent state of every kapp is a subset of this knowledge graph. Kapp clients invoke kapp services in Juxtareum to query and add to this knowledge graph. Kapp services, in turn, add entities to Juxtabase in sequential transactions represented as atomic changesets of items to be appended.
How Juxtareum works
Juxtareum consists of two subsystems: a blockchain network and a processing network.
Blockchain network
The blockchain network is a cluster of public computing nodes that collaborate to perform the top-level function of Juxtareum: processing incoming messages from kapp clients and creating new blocks in the Juxtareum blockchain ledger.
The blockchain network manages and utilizes a separate cluster - a processing network - in a manner conceptually comparable to that of Kubernetes, but specialized for executing Juxtareum-specific deployments.
The Juxtareum blockchain network employs an encryption scheme involving a network key. This key is split up among numerous parties and, leveraging multiparty computation (MPC) and homomorphic encryption, is utilized to perform encryption operations without any single party ever having access to the entire key.
Incoming messages from kapp clients are encrypted with this network key. When such a message is received, the keyholders collectively re-encrypt it using the public key of a TEE in the processing network - without revealing plaintext contents - and sent to the target TEE for processing.
Processing network
The processing network is a cluster of public computing nodes that collaborate to perform the actual processing of messages from kapp clients.
These nodes must verifiably provide trusted execution environments (TEEs) in order to ensure that the data being processed remains private - even from the node operators themselves.
Juxtaframe
Juxtaframe is a distributed application that provides an environment within which kapp services are executed. It implements the Juxtabase schema and provides an interface through which kapp clients interact with the Juxtabase knowledge graph.
Kapp services are implemented as user-created code written in Juxtalisp, a dialect of Lisp specialized for the Juxtareum execution environment, resembling Clojure.
Request handling:
Each message represents a request to invoke a handler function in a code entity in Juxtabase. If the request is a query, the value returned is the result. If it's a command, the value returned is a changeset passed to the view generation phase.
Materialized view generation:
Juxtaframe maintains a durable data structure containing specialized views of the knowledge graph. These views are implemented as immutable accretion-only B-trees and allow kapps to represent relevant subsets of the graph performantly.
Juxtastore
Juxtastore is a distributed key-value store used to store the Juxtabase knowledge graph, conceptually similar to Apache Ignite or FoundationDB. Its primary use is to provide permanent redundant storage and fast retrieval of the nodes in the trees representing the aggregates in Juxtaframe.