| Address | An address represents a Miyabi account. It can be a normal address representing a cryptographic keypair, or a multi-signature address. The address can represent a single or multiple credentials. An address defines the validation for the member credentials. |
| Application Node | A node that does not participate in the consensus process. It exposes APIs to accept transactions to perform multiple operations like consensus nodes. The application node can receive blocks from the consensus nodes to build it's world state and append blocks. However, it does not participate in the block creation process. |
| Block | A block can be thought of as a bundle of transactions and corresponding results wrapped by meta-data. Each transaction in a block needs to be validated before the network can accept it. A block consists of a BlockHeader (meta-data), BlockBody (transactions, transaction results, and events), and Evidences (signatures for the block). Each block is linked to the previous block. |
| Blockchain Configuration | The blockchain configuration is blockchain wide configuration settings and it affects all nodes. The blockchain configuration is set using a JSON file at the node startup and this initial blockchain configuration's hash is stored as a part of genesis block. Some of the parameters in the blockchain config can be updated using transactions. This configuration includes blockchain-wide settings e.g., world admin addresses, transaction lifetime, maximum transactions per block etc. |
| Consensus Credentials Admin | The Consensus Credentials Admins manage the members who can participate in the consensus process. These admins can change the consensus members using a transaction. The consensus credential admins are defined in the blockchain config. |
| Consensus Node | A node that participates in the Miyabi consensus process. It is responsible for creating block proposals and making consensus on the proposed blocks. |
| Contract Admin | The Contract Admins are the admins defined within the Contract module of Miyabi. This module also defines a set of ModulePermissions for controlling the operations related to smart contracts. The contract admins are set using the ContractInitialize transaction, which effectively bootstraps the smart contract feature in Miyabi. The contract admins have Deploy (permission to deploy a new contract) and GrantDeploy (permission to grant the Deploy permission) module permissions. The module permissions for the contract module can be updated using the UpdateContractPermission transaction. |
| Credential | A credential is a public claim of ownership of the private key. It is publicly declarable information. A transaction can present certain credentials for the validity of the operation to be done on the world state. These credentials need to be verified by the Miyabi execution. The credential owner also needs to provide "Evidence" along with the credential if they want to prove the claim of ownership. |
| Custom Table Permission | A set of permissions to control the insert, update, and read operations for a table. There are five custom table permissions defined: None, Insert, Update, Read, All. |
| Event | Event is a field for storing data in the blockchain. The events are stored directly as part of the blocks, instead of being stored in the world state. The events are emitted during transaction execution. Miyabi core transactions which affect the system tables of Miyabi emit system changes related events. Smart contracts can define events of their own and trigger them when the invocation of smart contract method happens in a transaction. All events will generate a bloom filter for searching in blocks. |
| Index Node | An index node is a short term referring to an application node with an attached Observer. The system works together to "index" the world state and block(s)/transaction(s) data into an external RDMS database managed by Observer. |
| Module | A Miyabi module is an extension of the Miyabi core features. Based on the needs and use cases for the Miyabi deployment, it is possible to include or exclude these modules at blockchain startup. Example of modules are Asset module (Digital fungible token feature), Entity module (Relational data feature), NFT module (Non-fungible token feature) etc. |
| Node | An active instance of the Miyabi daemon program. It is a program responsible for validating transactions and blocks, adding new blocks, and sharing the information between other peer nodes. |
| Node Admin | A Node admin is defined in the node config file. It represents an admin for a single node. Node admin's signature are required for doing operations on the node. These operations are only local to the node and not blockchain wide. |
| Node Configuration | The node configuration is a local configuration for the node. It includes various settings for the node, e.g., keystore paths, IP endpoint bindings, database configurations etc. It is set using a JSON format file and is required by the Miyabi daemon program to startup. This configuration does not affect other nodes. |
| Observer | An observer is a user-defined program that satisfies various well-defined interfaces in the Miyabi ObserverSdk. The Observer program can communicate synchronously with Miyabi node. The Miyabi node relays the state changes to the Observer along with transaction and block information. This program can be used to build an index for the world state of the blockchain. |
| Permission Model | All permissioned tables need to define a permission model. It represents the combination in which the permission checks will be done for operations like create, update, and read on the table data. The table level permissions and row level permissions which are orthogonal to each other, are combined according to the Permission model. There are five permission models defined right now: PermissionLess, CheckRowOnly, CheckTableOnly, TableOrRow, TableAndRow. |
| Permissioned Table | A permissioned table is another layer of abstraction over the base Miyabi table layer. It introduces the abstraction of permissions at table level and at table row level. All custom tables in Miyabi are permissioned tables. |
| Row Owner | It represents the owner of the data in a permissioned Miyabi table. The row owner's signature may be required (depends on the PermissionModel of the table) when reading/writing the data from/to the row. |
| SDK Configuration | Miyabi Client Sdk provides the users various configurable settings to automate transaction creation and to interact with the Miyabi server host(s). The sdk configuration contains settings required by the Miyabi sdk clients related to http client, local caching etc. |
| State proof | It represents the proof of existence of data in a table or the proof of existence of table itself. The user can set this flag for the table at the create table step. The user can request and get a verifiable proof of existence of table and its data. |
| System Permissions | These are the permissions required for performing operations at the system level. It consists of world permissions and module permissions. World permissions relate to the permissions for managing operations on the world state. Module permissions are defined by the Miyabi modules for module specific workflow operations. |
| Table | Miyabi abstracts the data storage in the form of a table. Underneath, it is a key value storage. The table is a powerful abstraction that can store similar types of data and provides access control at the table level as well as at the row level. Miyabi supports different data types (like fungible and non-fungible assets etc.) and has ready to use table types that encapsulate the logical operations on these data types. |
| TableAccessControlList | It defines the addresses of table owners and addresses that hold specific CustomTablePermissions. |
| Table Admin | For creating any new table in Miyabi, signer(s) with CreateTable permission is required. The table admin addresses (defined in the blockchain config) have the CreateTable Permission by default. The CreateTable permission can also be granted to other addresses using a transaction, in which case, these addresses effectively become the table admins. |
| Table Descriptor | The table descriptor defines various attributes of a Miyabi table. It contains metadata about the table, for example, name of the table, tracking changes to the table etc. |
| Table Owner | An address(es) which have all the insert, update and read permissions for the table. Additionally, the table owners can delete the table also. In case of Entity table, some additional permissions may be required depending on the PermissionModel of the table. |
| Token Admin | The Token admins are defined within the modules which manage the digital assets abstraction, namely, Asset module and NFT module. The Token admins can mint the tokens. Additionally, the Token admin's signature may be required when moving the tokens (however, Asset module and NFT module handle this situation in different ways). The token admins can be modified using the TokenAdminAdd and TokenAdminRemove commands. |
| Track table | The user can set this flag for the table at the create table step. It allows Miyabi to store the transactions that have changed the table. |
| Transaction | A transaction performs an atomic change on the state of the blockchain. A single transaction can contain one or multiple transaction entries. Along with the transaction entries, it contains the signature information and other meta-data (like lifetime) attached. If a single transaction entry fails, then the complete transaction is marked as unsuccessful. |
| Transaction Entry | Transaction entry represents the basic executable unit in Miyabi. However, the transaction entries must be encapsulated within a transaction. A single transaction can have multiple transaction entries. The admins of the world state can define certain limits on the number of transaction entries that can be included in a single transaction. |
| Transaction Id | Transaction Id is a unique hexadecimal Id associated with one transaction. This Id can be used to track the status of the transaction. |
| World Admin | The world admin addresses are defined in the blockchain config and have the Root world permission by default. Since, world admins have the Root permission, it effectively means these addresses have all the world permissions, namely, CreateTable, ChangeConfig, GrantCreateTable. The Root permission can be granted to other addresses also using a transaction, in which case, these addresses effectively become the world admins. |
| World State | The logical view of all the tables stored in the blockchain. |
