Skip to content
Vendia

Vendia Terminology

Common Terms

This page defines terms as they are used by Vendia.

Uni

Uni is short for Universal Application

Unis offer a general-purpose platform for sharing code and data easily across companies, clouds, regions, accounts, and technology stacks. They can be used for many purposes, which means they also have a number of moving parts!

Each Uni is composed of one or more nodes. Nodes can live in different clouds, regions, and accounts and can be owned by different organizations or companies. However, each node in a Uni has a common view of the Uni’s application data. This is made possible by a fully replicated, totally ordered, ACID-semantics database. Vendia Share generates all the code and cloud resources required to create and maintain this database and the other elements of the Uni - there is no “centralized database”, and Vendia never gains access to any of the data customers store in Unis.

Inside each node is a group of serverless resources appropriate to the cloud, region, and account associated with that node. For example, a Uni node would have (among other things) the following resources:

  • A ledger and world state
  • A serverless GraphQL API to model transaction input and queries for both world state and ledger information
  • Serverless functions to implement consensus and ACID data replication

As a user of the Uni, you don’t need to understand all the details and you don’t need to worry about operating these resources. That’s the beauty of Vendia Share’s SaaS-based deployment model. Vendia Share can provide all the ease of use of a conventional SaaS offering while still providing you with all the benefits of a unique cloud vendor account. This includes the security, operational isolation, and governance capabilities you’ve come to expect from AWS, Azure, Google, and other cloud vendor account boundaries.

Vendia offers the “best of both worlds” — full replication and decentralization (aka “you own your data at all times”) coupled with a fully managed, SaaS experience that frees you from operational toil and lets Vendia and your cloud service provider handle the task of keeping the infrastructure performing well.

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

An 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 tamper-proof 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.

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.