# Vendia Terminology ## Common Terms This page defines terms as they are used by Vendia. ### Project > Note: Vendia **projects** may be referred to as “Universal Applications” or “Unis” in older Vendia blog posts, articles, and videos. Additionally there are some legacy APIs and data models that use the term `uni`. **Projects** 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 have several components that work together. Each **project** is composed of one or more **workspaces**. ### Workspace > Note: Vendia **workspaces** may be referred to as “nodes” in older Vendia blog posts, articles, and videos. Additionally there are some legacy APIs and data models that use the term `node`. The “on-chain” representation of a [participant](https://docs.vendia.com/platform/vendia-terminology/#participants). In Vendia’s implementation, a **workspace** is composed of public cloud resources. - A company or organization may own multiple **workspaces**, even in the same **project**, in order to access data or services from different cloud service providers (CSPs). - **projects** are fault tolerant by design and do not require multiple **workspaces** per participant to achieve high availability, as is typical of older blockchain technologies, such as Hyperledger Fabric. **Workspaces** can live in different clouds, regions, and accounts and can be owned by different organizations or companies. However, each **workspace** in a **project** has a common view of the **project**’s application data. This is made possible by a fully replicated, totally ordered, ACID-semantics database. Vendia generates all the code and cloud resources required to create and maintain this database and the other elements of the **project** - there is no “centralized database”, and Vendia never gains access to any of the data customers store in **projects**. Inside each **workspace** is a group of serverless resources appropriate to the cloud, region, and account associated with that **workspace**. For example, a **project**’s **workspace** 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 **project**, 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’s SaaS-based deployment model. Vendia 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 (CSP) handle the task of keeping the infrastructure performing well. ### Entity A **project**’s data model is comprised of “entities”. These entities can be: - User-defined entities (e.g., “Product”, “Customer”, “Invoice”) defined via top-level “properties” in **project**’s JSON schema. - 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”. Any property defined within an Entity. Generally, the term **field** is used to describe an object’s keys in a [GraphQL query](https://graphql.org/learn/queries/#fields). We often use the term to differentiate between top-level JSON schema “properties” that become **entities** and JSON schema “properties” nested _within_ an entity. For example, a “Product” entity might include **fields** for “name” and “sku”. 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](https://graphql.org/learn/queries/#fields) - 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 **project** 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 ledger entry is an unordered set of one or more [transactions](https://docs.vendia.com/platform/vendia-terminology/#transaction) that are mutually unambiguous (i.e., are commutative and associative). Each ledger entry represents a group of changes or updates that are applied together to ensure consistency and integrity. Ledger entries are used to record the history of changes in a [ledger](https://docs.vendia.com/platform/vendia-terminology/#ledger), providing a tamper-proof record of all transactions. This ensures that the data can be audited and verified, maintaining trust and transparency among the [participants](https://docs.vendia.com/platform/vendia-terminology/#participants) in a **[project](https://docs.vendia.com/platform/vendia-terminology/#project)**. ### Ledger An ordered list of [ledger entries](https://docs.vendia.com/platform/vendia-terminology/#ledger-entry). By convention, the [head](https://docs.vendia.com/platform/vendia-terminology/#head) is the most recent entry. Distributed ledgers composed of tamper-proof [blocks](https://docs.vendia.com/platform/vendia-terminology/#block) are sometimes referred to as “blockchains”. ### Block A [ledger entry](https://docs.vendia.com/platform/vendia-terminology/#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 _tamper-proof_, 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](https://docs.vendia.com/platform/vendia-terminology/#block) in a [ledger](https://docs.vendia.com/platform/vendia-terminology/#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 project. ### Head The newest (most recent) [block](https://docs.vendia.com/platform/vendia-terminology/#block) in a [ledger](https://docs.vendia.com/platform/vendia-terminology/#ledger). ### Height The number of [blocks](https://docs.vendia.com/platform/vendia-terminology/#block) in a [ledger](https://docs.vendia.com/platform/vendia-terminology/#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](https://docs.vendia.com/platform/vendia-terminology/#genesis-block) and applied all the [blocks](https://docs.vendia.com/platform/vendia-terminology/#block) in the [ledger](https://docs.vendia.com/platform/vendia-terminology/#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 [**project**](https://docs.vendia.com/platform/vendia-terminology/#project). Typically, each participant owns one [**workspace**](https://docs.vendia.com/platform/vendia-terminology/#workspace) in the **project**. ### Consensus The process by which the [participants](https://docs.vendia.com/platform/vendia-terminology/#participants) in a [project](https://docs.vendia.com/platform/vendia-terminology/#project) decide whether to approve and commit new [blocks](https://docs.vendia.com/platform/vendia-terminology/#block). Note that consensus is an implementation detail and is separate from application-level [voting](https://docs.vendia.com/platform/vendia-terminology/#voting), whereby participants agree on business decisions and outcomes. ### Round The workflow associated with creating a new block through the [consensus](https://docs.vendia.com/platform/vendia-terminology/#consensus) process. ### Voting An application-level activity whereby [participants](https://docs.vendia.com/platform/vendia-terminology/#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](https://docs.vendia.com/platform/vendia-terminology/#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 **project** or - Add a new item if the specified unique identifier does not exist.