Certified communication
Why do you trust data obtained from a blockchain? Typically, it’s because all transactions and subsequent changes to smart contract states are validated through the blockchain consensus protocol, ensuring correctness as long as the underlying trust assumptions hold. However, verifying correctness this way can be tedious. Clients must download and validate the blockchain data, which involves significant effort. Even with more efficient mechanisms like Bitcoin’s SPV or Ethereum’s light clients, clients still need to download and validate block headers. This makes it challenging for applications with limited uptime and resources, such as mobile or web apps, to operate on blockchain data without relying on centralized intermediaries.
The Internet Computer addresses this issue differently. Using chain-key cryptography, the Internet Computer can generate digital signatures that can be validated with a single, permanent public key belonging to the Internet Computer. Unlike traditional digital signatures, the private key material never exists in a single place. It is always securely distributed among many different nodes, and valid signatures can only be generated when a majority of these nodes cooperates in a cryptographic protocol. As a result, a client application only needs to embed the Internet Computer’s public key to validate all certified responses it receives, without needing to trust the specific node that provided the response.
State certification
The Internet Computer certifies data by signing the entire state of a subnet after each execution round. The data in the state is structured in a Merkle tree, which allows the production of certificates for individual parts of the tree. This mechanism is used in several ways, including certifying streams of data between subnetworks and certifying data that comes form canisters.
Certified responses
All responses produced by canisters as answers to some update call from an external party are included a specific part of the state tree called the ingress history. The certificate on the state can therefore be used to certify individual entries in the history, thereby ensuring that a response read from the history had indeed been agreed by the subnet hosting the corresponding canister. This process allows the client to trust the response without needing to rely on the specific node that provided it.
Certified variables
Certified responses work for arbitrary update calls to canisters, but incur increased latency since the call itself needs to go through consensus. For calls that can be predicted in advance (e.g. those fetching some specific data from the canister state), the value to be certified can be computed and certified before the request is made. This allows fetching the certified data from a single node, thereby avoiding the latency incurred from sending the request through the consensus layer. This certification mechanism is available to canisters through certified variables. From an application perspective, certified variables can be set by the canisters during any update call to a canister. The certificate can then be read in a subsequent query call, allowing the canister to respond to a client’s request in a trustworthy manner without incurring the additional delay of consensus. Certified variables also underpin many of the Internet Computer’s advanced features, such as certified assets and Internet Identity.
Technical details
Technically, each canister can specify a single 32-byte value that will be certified by the subnet. Concepts such as Merkle trees or, more generally, authenticated data structures can extend the certification from this single 32-byte value to arbitrary amounts of data. Libraries like certified-map make this feature easily accessible for developers.
