|
|
| (18 intermediate revisions by 4 users not shown) |
| Line 1: |
Line 1: |
| − | ==A==
| + | See updated Glossary: [https://internetcomputer.org/docs/current/references/glossary/ ICP Glossary] |
| − | | |
| − | ===== account =====
| |
| − | A ledger '''account''' is a set of entries in the [[#ledger canister| ledger canister]], which is a smart contract that mimics the guise and behavior of a regular banking account, whose unit of measure is [[#ICP| ICP]] (Internet Computer Protocol) utility tokens. Ledger accounts are owned by [[#principals| principals]], and their ownerships do not change over time. Every account on the ledger has a positive [[#balance| balance]] measured in ICP with a precision of eight decimals.
| |
| − | | |
| − | ===== address =====
| |
| − | In the context of transactions on the ledger, '''address''' is synonymous with [[#account| account]].
| |
| − | | |
| − | ==B==
| |
| − | | |
| − | ===== balance =====
| |
| − | The '''balance''' of an [[#account| 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 ICP and is represented with eight decimals. Thus, the minimum positive balance of an account is 0.00000001 or 10^-8 [[#ICP| ICP]]; this amount is sometimes referred to as one '''e8'''.
| |
| − | | |
| − | ===== batch =====
| |
| − | A '''batch''' is a collection of [[#messages| messages]] whose order is agreed upon by [[#consensus| consensus]].
| |
| − | | |
| − | ===== beneficiary =====
| |
| − | The '''beneficiary''' of an [[#account| account]] is the [[#principal| principal]] who owns the [[#balance| 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| fiduciary]]).
| |
| − | | |
| − | ===== blockchain =====
| |
| − | A '''blockchain''' is a growing list of cryptographically linked blocks, agreed upon by [[#consensus| consensus]]. On the [[#Internet computer| Internet Computer]] every [[#subnet| subnet]] is a blockchain and these blockchains interact using [[#chain key cryptography| chain key cryptography]].
| |
| − | | |
| − | ===== burning transaction =====
| |
| − | A '''burning transaction''' is the process of "burning" [[#ICP| ICP]], whereby a certain amount of ICP are destroyed. The main use case is that of purchasing [[#cycles| cycles]], through which ICP are destroyed while at the same time a corresponding amount of cycles is created, using the current exchange rate between ICP and ([[#SDR| SDR]]), in such a way that one SDR corresponds to one trillion (10E12) cycles. It is represented as a [[#transaction| transaction]] from the source [[#account| account]] to the [[#ICP supply account| ICP supply account]].
| |
| − | | |
| − | ==C==
| |
| − | ===== canister =====
| |
| − | A '''canister''' is a computational unit that bundles ''code'' and ''state''. A canister can be deployed as a [[#smart contract| smart contract]] on the [[#Internet Computer| Internet Computer]] and accessed over the Internet.
| |
| − | | |
| − | ===== canister account =====
| |
| − | A '''canister account''' is a ledger account owned by a [[#canister | canister]] (i.e. whose [[#fiduciary|fiduciary]] is a canister). A non-canister account is a ledger account whose fiduciary is a non-canister [[#principal |principal]].
| |
| − | | |
| − | ===== canister identifier =====
| |
| − | The '''canister identifier''' or '''canister ID''' is a globally-unique identifier that identifies a [[#canister| canister]] and can be used to interact with it.
| |
| − | | |
| − | ===== canister signature =====
| |
| − | A '''canister signature''' uses a signature scheme based on [[#certified variables| certified variables]]. Public “keys” include a canister id plus a seed (so that every canister has many public keys); signatures are certificates that prove that the canister has put the signed message at a specific place in its state tree. Details in the [https://smartcontracts.org/docs/interface-spec/#canister-signatures The Internet Computer Interface Specification].
| |
| − | | |
| − | ===== canister state =====
| |
| − | A '''canister state''' is the entire state of a [[#canister|canister]] at a given point in time. A canister’s state is divided into ''user state'' and ''system state''. The user state is a [[#WebAssembly|WebAssembly]] module instance and the system state is the auxiliary state maintained by the [[#Internet Computer|Internet Computer]] on behalf of the canister, such as its compute allocation, balance of cycles, input and output queues, and other metadata. A canister 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|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 [[#canister|canister]] can store in its subnet’s canonical state in the processing of an update call (or inter-canister call), so that during the handling of a [[#query|query]] call, the canister 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 Internet Computer. The most visible innovation of chain key cryptography is that the Internet Computer 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 Internet Computer.
| |
| − | | |
| − | ===== consensus =====
| |
| − | In distributed computing, '''consensus''' is a fault tolerant mechanism by means of which a number of [[#nodes|nodes]] can reach agreement about a value or state.
| |
| − | | |
| − | Consensus is a core component of the [[#replica|replica]] software. The consensus layer selects [[#messages|messages]] from the peer-to-peer artifact pool and pulls messages from the cross-network streams of other [[#subnets|subnets]] and organizes them into a [[#batch|batch]], which is delivered to the [[#message routing|message routing]] layer.
| |
| − | | |
| − | ===== controller =====
| |
| − | A '''controller''' of a [[#canister|canister]] is a person, organization, or other canister that has administrative rights over the canister. Controllers are identified by their [[#principals|principals]]. For example, a controller of a canister can upgrade the [[#WebAssembly|WebAssembly]] code of the canister or delete the canister.
| |
| − | | |
| − | ===== cycle =====
| |
| − | On the Internet Computer, a '''cycle''' is the unit of measurement for resources consumed in the form of processing, memory, storage, and network bandwidth. Every canister has a cycles account to which resources consumed by the canister are charged. The Internet Computer’s utility token ([[#ICP|ICP]]) can be converted to cycles and transferred to a canister. Cycles can also be transferred between canisters by attaching them to an [inter-canister] message.
| |
| − | | |
| − | ICP can always be converted to cycles using the current price of ICP measured in [SDR] using the convention that one trillion cycles correspond to one SDR.
| |
| − | | |
| − | ==D==
| |
| − | ===== dapp =====
| |
| − | A '''dapp''', or decentralised application is a canister smart contract running on the [[#Internet Computer|Internet Computer]].
| |
| − | | |
| − | ===== data center =====
| |
| − | A '''data center''' (DC) is a physical site that hosts [[#nodes|nodes]] which contribute to the [[#Internet Computer|Internet Computer]]. It includes the hardware and software infrastructure required for node deployment. A DC is identified on the Internet Computer by a unique identifier.
| |
| − | | |
| − | ===== dissolve delay =====
| |
| − | The '''dissolve delay''' is the amount of time that [[#neuron|neurons]] must spend [[#dissolving state| dissolving]] before becoming [[#dissolved state| disolved]].
| |
| − | | |
| − | ===== dissolved state =====
| |
| − | The '''dissolved state''' is a [[#neuron|neuron]] state characterized by a [[#dissolve delay|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|neuron account]] closed. The [[#neuron age|age]] of a dissolved neuron is considered to be zero.
| |
| − | | |
| − | ===== dissolving state =====
| |
| − | A '''dissolving state''' is a [[#neuron|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 [[#neuron age|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|replica]] software.
| |
| − | | |
| − | ==F==
| |
| − | ===== fiduciary =====
| |
| − | The '''fiduciary''' of an [[#account|account]] is the [[#principal|principal]] allowed to make [[#transactions|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|beneficiary]] of the account. The [[#neuron account|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 (canisters) that interact with the IC ledger: in this case, the fiduciary is the DeFi canister while the beneficiary is the individual or organisation ([[#principal|principal) that uses the DeFi canister’s services.
| |
| − | | |
| − | ==G==
| |
| − | | |
| − | | |
| − | ==R==
| |
| − | ===== replica =====
| |
| − | The '''replica''' is a collection of protocol components that are necessary for a node to participate in a subnet.
| |