| Node | An active instance of the Miyabi daemon. It is a program responsible validating transactions and blocks, adding new blocks, and sharing the information between other peer nodes |
| Consensus Node | A node which is participating in the consensus algorithm. It holds a voting power and can also make proposals. Like application nodes, it also exposes an API to users. also denoted as core node. |
| Application Node | A node that does not participate in the consensus, but provides an API service and supports the gossiping protocol. |
| Observer Node | A special node that can be attached to a core or application node to listen to the transactions. |
| Table | A collection of related data held in a table format within the blockchain |
| World State | The logical view of the all the tables stored in the blockchain |
| Block | A block can be thought of as a bundle of transactions wrapped by meta-data. Each transaction in a block needs to be validated before it can be accepted by the network. A block consists of a BlockHeader (meta-data), BlockBody (transactions/events), and Evidences (signatures) |
| Transaction | A bundle of entries with the necessary signatures and meta-data attached. A transaction performs an atomic change on the state of the blockchain |
| Entry | Entry is the basic level of operations in Miyabi. Miyabi provides many entries in models so users can create them with clientsdk and add them to transactions |
| Event | Event is a field for storing data in a blockchain. Users can define their events and write them into blocks when they are triggered in smart contracts. All events will generate a bloom filter for searching in blocks |
| 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 |
| Track | An option for tables which allows Miyabi to store the transactions that have changed the table |
| State proof | The proof of the existence of each transaction related to that table |
| Address / Credential | An address is an identifier of alphanumeric characters, that represents a user |
| Permissioned Table | Table in which every write action requires an admin's signature. For example, consider a Permissioned Asset Table T with table owner O and Update Admin A. If asset owner B wants to move some assets from B to C within T1, then the transaction requires the signature of O or A. Currently Miyabi has Permissioned Binary Table and Permissioned Asset Table as permissioned Tables. Permissioned tables can also be set to read restricted which means only the update admin and table owner can read the table. |
| Permissioned Row Table | Permissioned Row Table is a table in which each row can be handled by the row owner. Currently, Permissioned Row Table inherits from Permissioned Table. Hence, permission admins can also modify the table according to their permissions. In Miyabi: Entity Table and Permissioned Row Binary Table are Permissioned Row Tables |
| Table Admin | A specific user who has the right to create or delete tables in the blockchain. For example, Asset Table; Permissioned Asset Table; Entity Table; Instance Table (for Smart Contract Instances) |
| Table Owner | Table Owner is the owner of a table such as the Asset Table Owner or Entity table Owner which is defined at the time of table creation. For example, if Table T is created with A’s public key, then the owner of Table T will be A. All operations performed on T can be done with A’s signature |
| Permissioned Admin | Currently, three permissions can be grant to different address by table owner: 1. Insert admin, who can insert a row to the table. 2. Update admin, who can update a row's value. 3. ACL admin, who can grant above permission to any addresses. |
