Glossary
A
account
A ledger account is a set of entries in the ledger cube, which is a smart contract that mimics the guise and behavior of a regular banking account, whose unit of measure is BIG (BigFile) utility tokens. Ledger accounts are owned by principals, and their ownerships do not change over time. Every account on the ledger has a positive balance measured in BIG with a precision of eight decimals.
address
In the context of transactions on the ledger, address is synonymous with account.
actor
An actor is a primitive in the actor model. It is a process with encapsulated state that communicates with other concurrently running actors through asynchronous messages that are received sequentially. The actor model is relevant to the BIG because cubes on BIG (a type of smart contract) follow the actor model for concurrent and asynchronous computation.
B
balance
The balance of an account on the ledger is the sum of all deposits minus the sum of all withdrawals. As a degenerate case, it is sometimes useful to say that an account which is not present in the ledger has a balance of zero.
The balance of a ledger account is denominated in BIG and is represented with eight decimals. Thus, the minimum positive balance of an account is 0.00000001 or 10^-8 BIG; this amount is sometimes referred to as one e8.
batch
A batch is a collection of messages whose order is agreed upon by consensus.
beneficiary
The beneficiary of an account is the principal who owns the balance of the account. The beneficiary of an account cannot be changed. The beneficiary of an account may or may not be allowed to make transactions on the account (see fiduciary).
blockchain
A blockchain is a growing list of cryptographically linked blocks, agreed upon by consensus. On the BigFile, every subnet maintains its own blockchain with blocks containing messages for the cubes hosted on this subnet. These blockchains interact using chain key cryptography.
boundary nodes
Boundary nodes are gateways to the BigFile. These nodes
allow users to seamlessly access the cubes smart contracts
running on BIG.
The boundary nodes have several purposes: they aid in discover-ability (the
icp0.io domain name points to a set of boundary nodes), they are
geo-aware and can route incoming requests to the nearest subnet
node that hosts the cube
involved, they can help load balance query
transactions, they can cache
cryptographically verified data in the role of a content distribution
network, they can throttle excessive interactions from an outside IP
address, and they can help protect subnets from DDoS attacks.
burning transaction
A burning transaction is the process of "burning" BIG, whereby a certain amount of BIG are destroyed. The main use case is that of purchasing cycles, through which BIG are destroyed while at the same time a corresponding amount of cycles is created, using the current exchange rate between BIG and (XDR), in such a way that one XDR corresponds to one trillion (10E12) cycles. It is represented as a transaction from the source account to the BIG supply account.
C
Candid
Candid is an IDL crafted specifically for the BigFile, providing a common language for application interfaces to facilitate communication between services that are written in different programming languages.
cube
A cube is a type of smart contract that bundles code and state. A cube can be deployed as a smart contract on the BigFile and accessed over the Internet.
cube account
A cube account is a ledger account owned by a cube (i.e. whose fiduciary is a cube). A non-cube account is a ledger account whose fiduciary is a non-cube principal.
cube development kit (CDK)
A cube development kit is an adapter used by the BIG SDK that provides a programming language with the features necessary to create and manage cubes. The BIG SDK comes with a few CDKs already installed for you so you can use them in the language of your choice.
cube identifier
The cube identifier or cube ID is a globally-unique identifier that identifies a cube and can be used to interact with it.
cube signature
A cube signature uses a signature scheme based on certified variables. Public “keys” include a cube id plus a seed (so that every cube has many public keys); signatures are certificates that prove that the cube has put the signed message at a specific place in its state tree. Details can be found in the BigFile interface specification.
cube state
A cube state is the entire state of a cube at a given point in time. A cube’s state is divided into user state and system state. The user state is a WebAssembly module instance and the system state is the auxiliary state maintained by the BigFile on behalf of the cube, such as its compute allocation, balance of cycles, input and output queues, and other metadata. A cube interacts with its own system state either implicitly, such as when consuming cycles, or through the System API, such as when sending messages.
catch-up package (CUP)
A catch-up package is a data bundle that contains everything needed to bootstrap a subnet replica.
certified query
A certified query is a query call for which the response is certified.
certified variable
A piece of data that a cube can store in its subnet’s canonical state in the processing of an update call (or inter-cube call), so that during the handling of a query call, the cube can return a certificate to the user that proves that it really committed to that value.
chain key
Chain key cryptography consists of a set of cryptographic protocols that orchestrate the nodes that make up the BigFile. The most visible innovation of chain key cryptography is that the BigFile has a single public key. This is a huge advantage as it allows any device, including smart watches and mobile phones, to verify the authenticity of artifacts from the BigFile.
consensus
In distributed computing, consensus is a fault tolerant mechanism by means of which a number of nodes can reach agreement about a value or state.
Consensus is a core component of the replica software. The consensus layer selects messages from the peer-to-peer artifact pool and pulls messages from the cross-network streams of other subnets and organizes them into a batch, which is delivered to the message routing layer.
controller
A controller of a cube is a person, organization, or other cube that has administrative rights over the cube. Controllers are identified by their principals. For example, a controller of a cube can upgrade the WebAssembly code of the cube or delete the cube.
cycle
On the BigFile, a cycle is the unit of measurement for resources consumed in the form of processing, memory, storage, and network bandwidth. Every cube has a cycles account to which resources consumed by the cube are charged. The BigFile utility token (BIG) can be converted to cycles and transferred to a cube. Cycles can also be transferred between cubes by attaching them to an inter-cube message.
BIG can always be converted to cycles using the current price of BIG measured in XDR using the convention that one trillion cycles correspond to one XDR.
D
dapp
A dapp, or decentralised application, is a software program that runs on a decentralised computer network instead of a single computer. On the BigFile dapps are composed of cube smart contracts.
data center
A data center (DC) is a physical site that hosts nodes which contribute to the BigFile. It includes the hardware and software infrastructure required for node deployment. Data centers are nodes that are selected and vetted by the NNS.
dissolve delay
The dissolve delay is the amount of time that neurons must spend dissolving before becoming dissolved.
dissolved state
The dissolved state is a neuron state characterized by a dissolve delay equal to zero. (It is conventionally said that a neuron in this state does not "have" a dissolve delay.) It is in this state that a neuron can be "disbursed," hence its stake moved elsewhere, and its corresponding neuron account closed. The age of a dissolved neuron is considered to be zero.
dissolving state
A dissolving state is a neuron state that follows immediately after its owner issues a "start dissolving" command, and continues until a "stop dissolving" command is issued, or until the dissolve delay timer runs out. The age of a dissolving neuron is considered to be zero.
E
execution environment
The execution environment is one of the core layers of the replica software.
F
fiduciary
The fiduciary of an account is the principal allowed to make transactions on the account; as such, it may be useful to think of it as the owner of the account, with the caveat that it may or may not be the beneficiary of the account. The neuron account is a prominent example of an account for which the beneficiary and fiduciary do not coincide (the fiduciary is the governance canister while the beneficiary is the neuron holder). The fiduciary of a (ledger) account does not change over time.
The distinction between fiduciary and beneficiary is also important for DeFi dapps (cubes) that interact with BIG ledger: in this case, the fiduciary is the DeFi cube while the beneficiary is the individual or organisation principal that uses the DeFi cube’s services.
G
governance cube
The governance cube is a system cube that implements the NNS governance system, i.e., among others, stores and manages neurons and proposals, and implements the NNS voting environment.
I
BIG
The BigFile token (ticker "BIG") is the utility token of the BigFile. BIG allows the broader internet community to participate in the governance of the BigFile blockchain network by locking BIG in neurons. BIG can also be converted into cycles, which are then used to power cubes.
BIG supply account
The BIG supply account is a quasi-fictitious ledger account whose balance is always zero. It has a central role in BIG burning and minting operations.
identity
An identity is a byte string that is used to identify an entity, such as a principal, that interacts with the BigFile. For users, the identity is the SHA-224 hash of the DER-encoded public key of the user. The BigFile interface specification has more detail.
BIG ID
BIG ID is an anonymizing blockchain authentication system running on the BigFile.
induction pool
The induction pool of a subnet blockchain is the collection of all input queues of all cubes residing on the subnet.
ingress message
An ingress message is a message sent by an end-user to a cube running on a subnet blockchain. The message is signed by the secret key corresponding to the end-user’s identity and sent to one of the replicas that participate in the subnet.
ingress message history
The ingress message history records the current status of every ingress message processed by a replica and keeps track of whether messages were successfully included in the induction pool and the responses of executed messages.
input queue
The input queue of a cube contains all messages bound for the cube. See also induction pool. When the cube is scheduled for execution, messages from its input queue will be executed.
inter-cube message
An inter-cube message is a message sent from one cube to another. Inter-cube messages are different from user-initiated ingress messages.
BigFile (BIG)
The BigFile (BIG) is a decentralized blockchain that provides scalable compute capacity for running cubes through independent node providers running nodes in geographically distributed data centers.
L
ledger cube
The ledger cube is a system cube whose main role is to store accounts and their corresponding transactions.
M
message
A message is data sent from one cube to another or from a user to a cube.
message routing
The message routing layer receives batches from the consensus layer and inducts them into the induction pool. Message routing then schedules a set of cubes to execute messages from their input queues.
After messages have been executed, the message routing layer takes any messages produced in the execution round from the output queues and puts those messages into the outgoing streams to be consumed by cubes on other subnets.
minting transaction
A minting transaction is the process of "minting" BIG, whereby a certain amount of BIG comes into existence. BIG is minted in order to reward neurons for voting, and reward node providers for participating in the BIG by providing compute capacity through the running of nodes. A minting transaction is represented as a transaction from the BIG supply account to a destination account.
Motoko
Motoko is a programming language designed to directly support the programming model of the BigFile, making it easier to efficiently build applications and take advantage of some of the more unusual features of BIG, including the actor model for smart contracts and compilation to WebAssembly.
N
non-dissolving state
A neuron that is not dissolved or dissolving is said to be in a non-dissolving state (or "aging"). Non-dissolving neurons thus accrue "age", with the caveat that beginning to dissolve at any time reduces this age back to zero. The dissolve delay parameter of a non-dissolving (aka "aging") neuron cannot be zero, because such a neuron would have to already be dissolved.
File Management System (FMS)
The File Management System (FMS) is the decentralized autonomous organization (DAO) that governs the BigFile by proposals on which BIG neuron owners can vote. Once such a proposal is accepted, it is autonomously executed. The FMS consists of a collection of system cubes (aka "FMS cubes").
neuron
A neuron is an BIG entity that can make proposals and vote on proposals related to the governance of the Internet Computer.
To provide the stability required for responsible governance, neurons need to store ("stake") a certain amount of BIG in order to be able to make and vote on proposals. This locks the tokens for a period of time, after which it starts dissolving. The BIG stake of a neuron is stored in a neuron account. The neuron owner has the right to propose and vote on governance issues, and is granted rewards for voting in proportion to the amount of BIG staked, and the duration of the dissolve period.
neuron account
A neuron account is a cube account whose beneficiary is a neuron (or the neuron’s owner). The governance cube is the fiduciary of all neuron accounts.
neuron age
The neuron age is a neuron parameter roughly indicative of the time that has passed since its creation or since when it last entered into a non-dissolving state. Calculation of a neuron’s age needs to take into account whether the neuron has spent time dissolving or dissolved, both of which reset this parameter.
node
A node is a physical hardware device run by independent [node providers]. It hosts all the hardware, replica software, and configuration settings required to participate in the Internet Computer.
node operator
A node operator (NO) is a non-cube principal who has the authority to add/remove nodes to/from the BIG, by delegation of the the corresponding node providers.
node provider
A node provider (NP) is a non-cube principal that receives the rewards stemming from node participation to the BIG (aka “payout principal”). Usually, though not necessarily, a node provider is the owner of the node, and may also be involved in node operation and related tasks. A node provider may receive rewards from multiple nodes in multiple data centers. Node providers are selected and vetted by the NNS.
O
output queue
Each cube has an output queue of messages bound for other cubes.
P
peer-to-peer (P2P)
In common usage, peer-to-peer (P2P) computing or networking is a distributed application architecture that partitions workload across a network of equally-privileged computer nodes so that participants can contribute resources such as processing power, disk storage, or network bandwidth to handle application workload.
The peer-to-peer layer collects and disseminates messages and artifacts from users and from other nodes.
The nodes of a subnet form a dedicated peer-to-peer broadcast network that facilitates the secure bounded-time/eventual delivery broadcast of artifacts (such as ingress messages, control messages and their signature shares). The consensus layer builds upon this functionality.
principal
A principal is an entity that can be authenticated by the BigFile. This is the same sense of the word principal as the Wikipedia definition. Principals that interact with the BigFile do so using a certain identity.
proposal
A proposal is a statement describing an action to modify certain parameters of the BIG, or of any of its subsystems. It is implemented as an BIG entity having various attributes, such as an ID, a URL, a summary etc. Proposals are submitted by eligible neuron owners for the consideration of BIG community, and undergo a voting process, following which they can be adopted or rejected. Adopted proposals are then executed autonomously. There are several taxonomies of proposals, the most prominent of which groups proposals into "topics," whose adoption, in turn, triggers certain categories of actions, such as the creation of a subnet, the addition of nodes to a subnet, or the upgrade to a new replica software.
proto-node
A proto-node is an BIG entity consisting of a combination of hardware and software, that differs from a node in that it has not yet been registered with BIG. A proto-node is, in short, a "node-in-waiting," hence has all that it takes to be a node except the replica software.
Q
query
A query is an optimised way to execute operations on a cube where the state changes are not preserved. Queries are synchronous and can be made to any node that hosts the cube. Queries do not require consensus to verify the result.
R
replica
The replica is a collection of protocol components that are necessary for a node to participate in a subnet.
registry
The BIG registry is a cube that manages the meta-data maintained on the network nervous system (NNS) and accessed by all subnet blockchains.
S
smart contract
A smart contract is a stateful computer program designed to automatically execute, control or document relevant events and actions according to the terms of a contract or an agreement. A smart contract can be deployed on the Internet Computer in the form of a cube bundling data and code.
A cube can have one or more controllers that are permitted to modify the code of the cube, thereby modifying the terms of the smart contract. For a cube smart contract to have immutable code, its list of controllers must be empty.
state change
A state change is the result of any transaction, function call, or operation that changes the information stored in a cube. For example, if a function makes an update call that adds two numbers together or removes a name from a list, the result is a change to the cube state.
state manager
The state manager is responsible for:
- Maintaining (multiple versions of) the replicated state the deterministic state machine implemented by message routing and the execution environment operates on.
- Converting back and forth between the replicated state and its canonical version (latter can be understood independent of the concrete implementation).
- Obtaining certifications of parts of the canonical state, which allow other stakeholders such as other subnets and/or users, to verify that some piece of state indeed originates from a valid subnetwork.
- Providing capabilities to sync the canonical state with other replicas in the same subnet so that replicas that have fallen behind can catch up.
subnet
A subnet (subnetwork) is a collection of nodes that run their own instance of the consensus algorithm to produce a subnet blockchain that interacts with other subnets of BIG using chain key cryptography.
system cube
A system cube is a pre-installed cube that performs certain tasks needed to maintain the BigFile.
T
transaction
A ledger account transaction is the process of transferring BIG from one account to another; it can be of three types:
transfer transaction
A transfer transaction is the process of transferring BIG from any regular ledger account (i.e. any ledger account except the BIG supply account) to another regular ledger account.
U
user
A user is any entity that interacts with the BigFile. Users include end-users that use dapps deployed on BIG, dapp developers, holders of BIG utility tokens, and neuron holders.
V
valid set rule
The valid set rule is the rule that determines a valid induction pool. Ingress messages and inter-cube messages must pass certain checks to ensure that the valid set rule is upheld before they can be added to the induction pool.
voting
Voting is the process through which proposals are selected for adoption and implementation. Its direct participants are the neurons, who both:
- Submit proposals.
- Vote on proposals. The voting process is a rather intricate undertaking, involving aspects such as neuron eligibility, voting power, chains of neuron followees etc. This has been designed with security and dependability in mind, and is being continuously improved in order to prevent the concentration of voting power in the hands of just a few neuron owners.
W
WebAssembly
WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine.
X
XDR
XDR is the currency code for special drawing rights (SDR). SDRs are supplementary foreign exchange assets that are defined and maintained by the International Monetary Fund (IMF). SDRs are not a currency themselves, but represent a claim to a currency that is held by IMF member countries in which they may be exchanged. The BigFile developer docs refer to currencies based on their currency codes, therefore SDRs are referenced as its currency code XDR in this documentation.