|
|
| (19 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.
| |
| − | | |
| − | ==D==
| |
| − | ===== dapp =====
| |
| − | A '''dapp''', or decentralised application is a canister smart contract running on the Internet Computer.
| |
| − | | |
| − | ==R==
| |
| − | ===== replica =====
| |
| − | The '''replica''' is a collection of protocol components that are necessary for a node to participate in a subnet.
| |