Terminology

Common Terms

This section defines terms as they are used by Vendia.

Uni

Short for “Universal Application”, a uni is a cross-cloud, cross-party, cross-account, cross-region data and code sharing application powered by Vendia’s serverless distributed ledger technology. A uni is composed of nodes modeling participants, each of which possesses an ordered, replicated data model in the form of a distributed ledger.

Entity

A Universal Application’s data model is comprised of “entities”: user-defined entities (e.g., “Product”, “Customer”, “Invoice”) defined via top-level “properties” in Uni’s JSON schema, or Vendia-defined entities (e.g., “Block”, “File”, “ApiKey”). User-defined entities are generated from the immediate children of your JSON schema’s top-level “properties”. Each entity will have a set of GraphQL APIs for CRUD operations (e.g. addProduct, getCustomer, listInvoices) and can be indexed to enable efficient data retrieval. Entities can contain complex data types (e.g. “object”, “array”) in addition to scalar data types (e.g. “string”, “number”, “integer”), but arrays of data nested within entities will not have their own APIs and cannot be indexed.

Field

Any property defined within an Entity. Generally, the term field is used to describe object’s keys in a GraphQL query - we often use the term to differentiate between top-level JSON schema “properties” that become entities and JSON schema “properties” nested within an entity. A “Product” entity, for example, might include fields for “name” and “sku”.

Transaction

An individual update to a data value. For example, if you have a uni modeling shapes, a transaction to add a shape might look like addShape(name, number_of_sides). A transaction can add new data or delete or modify existing data. Transactions are atomic: A transaction is either applied in its entirety or not at all, but never “partially” performed.

Ledger Entry

A unordered set of one or more transactions that are mutually unambiguous (i.e., are commutative and associative).

Ledger

An ordered list of ledger entries. By convention, the “head” is the most recent entry. Distributed ledgers composed of tamperproof blocks are sometimes referred to as “blockchains”.

Block

A ledger entry which contains, in addition to its transactions, three additional pieces of metadata:

1. A link to the previous entry.
2. A copy of the previous entry’s content hash.
3. A content hash that includes (1) and (2).

These additional items are what make a block more than just a log entry - they ensure that the block and its history are also tamperproof, because any change to any portion of the history will cause one or more of the hashes to be invalid.

Genesis Block

The first (earliest, “zeroth”) block in a ledger.

The genesis block may be explicit or implicit. It is the only block that is not required to have a link to the previous block or a copy of the previous block’s hash. The genesis block typically establishes any initial state and records important metadata such as the initial set of participants in the uni.

Head

The newest (most recent) block in a ledger.

Height

The number of blocks in a ledger.

World State

The current state of the data; i.e., a copy of all values that would exist if you took the initial state in the genesis block and applied all the blocks in the ledger to it, in order.

For operational performance reasons, the world state is usually explicitly maintained as a materialized view, rather than being reconstructed by replaying the entire ledger repeatedly to the initial state.

Participants

The business or legal entities who share replicated code and data through a uni. Typically, each participant owns one node in the uni.

Node

The “on-chain” representation of a participant. In Vendia’s implementation, a node is composed of public cloud resources. A company or organization may own multiple nodes, even in the same uni, in order to access data or services from different cloud vendors (CSPs). (Note that unis are fault tolerant by design, and do not require multiple nodes per participant to achieve high availability, as is typical of older blockchain technologies, such as Hyperledger Fabric.)

Consensus

The process by which the participants in a uni decide whether to approve and commit new blocks. Note that consensus is an implementation detail and is separate from application-level voting, whereby participants agree on business decisions and outcomes.

Round

The workflow associated with creating a new block through the consensus process.

Voting

An application-level activity whereby participants collectively make a decision on a business decision. Note that voting is an application-centric activity, governed by the participants, and is separate from operational activities (such as consensus) that implement data replication.

Upsert

An upsert operation (a combination of the words “update” and “insert”) will update an existing item, if that item (specified by a unique identifier) already exists in the uni, or add a new item if the specified unique identifier doesn’t exist.