Cryptographic Truth: The Future of Trust-Minimized Computing and Record-Keeping

This is Part 2 of a two-part series on the future of trust. Read Part 1, What Crypto Is Really About, for a deep dive into the societal problems that blockchains, smart contracts, and oracles are built to solve.

While blockchain-based technologies have many qualities that set them apart from other computing paradigms, their primary value proposition is the generation of cryptographic truth. In the simplest sense, cryptographic truth is a form of backend computing and record-keeping that’s more accurate, accessible, auditable, and tamper-proof than current alternatives.

Cryptographic truth is derived from trust-minimized infrastructure—code that works exactly as intended because its execution and verification don’t rely on trust in strangers or uncontrollable variables. Blockchains generate trust-minimization using cryptography to authenticate data and secure the chronological order of records and decentralized consensus to validate new entries and keep them immutable. Through this mechanism, multi-party processes can be tracked and executed on a shared, credibly neutral backend that is incentivized to be managed honestly.

Cryptographic truth combines cryptography and decentralized consensus to generate a golden record amongst a distributed set of entities and deterministically compute applications.

The following article will examine how cryptography and decentralized consensus combine in blockchains to generate cryptographic truth before discussing how oracles extend cryptographic truth to the verification of any type of event or computation not available on a blockchain.

Understanding Cryptography and Its Use in Blockchains

To fully comprehend cryptographic truth and its role in blockchains, it’s important to first become familiar with the terminology and general workings of modern cryptography. Note: If you already understand cryptography, feel free to skip down to the subsection Cryptography in Blockchains.

Introduction to Cryptography

Cryptography is the science of securely communicating in the presence of adversarial behavior. While most people understand cryptography’s role in keeping communication confidential (e.g. encrypted messaging apps), it’s also used to authenticate the origin, validate the integrity, and establish non-repudiation of communication; i.e. for determining that a message came from a specific person and wasn’t tampered with and that these properties cannot be denied by the sender.

Cryptography is used to convert an original message into an unintelligible message that only someone in the know can interpret. Encryption is a two-way function that encrypts the original message (i.e. plaintext) into an unintelligible message (i.e. ciphertext) that only the recipient can decrypt to extract the plaintext. Other cryptographic functions are one-way, seeking only to prove some knowledge or property about data as opposed to making the original data knowable.

An encryption algorithm is referred to as a cipher while the key is a secret—usually a string of characters—that allows someone to understand the cipher. There are two basic types of techniques used in ciphers: substitution and permutation (also called transportation). Substitution ciphers replace plaintext letters, numbers, and symbols with other letters, numbers, or symbols. Permutation ciphers use the plaintext message letters but rearrange their order. These techniques are often combined, layered, influenced by external data, and changed over time to create complexity.

The two basic encryption techniques utilized by ciphers are substitution and permutation (also called transportation).

The first encryption ciphers were hardware-based, meaning they were memorized, hand-written, or facilitated through non-digital machines. However, with the advent of computers, software-based encryption algorithms became the dominant form of encryption.

Modern Cryptography

Modern cryptography is based heavily around computational hardness assumptions—the notion that a particular problem cannot be solved efficiently. So while most cryptographic functions are theoretically possible to break, they are impractical to break in practice given current computing limits. Thus, modern cryptographic algorithms seek to strike the right balance between computational efficiency and being computationally secure, relying on mathematics and computer science to make decisions regarding factors such as key length. This is why many cryptographic functions are based on the time and budget it takes for modern computing systems to find solutions to hard-to-solve math problems such as the discrete logarithm problem, the integer factorization problem, and theoretical problems in elliptic curves.

There are three general classes of modern, software-based cryptography: hash functions, symmetric encryption, and asymmetric encryption.

Hash Functions

Hash Functions convert data of any length into a fixed bit-length called a hash. A hash is a unique identifier of data akin to a fingerprint, essentially verifying an original set of data. Hashing data is popularly used to index data and retrieve it from a database in an efficient manner. It’s also used to store data securely, such as in the case of websites that only store a salted hash of users’ passwords to prevent password leaks in the event of a database breach.

Hash functions don’t make use of keys and are based on one-way functions to ensure they are pre-image resistant—it’s nearly impossible for someone who doesn’t know the original message to figure it out from the hash alone. The only realistic method to obtain the original message is by brute force; i.e. guess every possible input, which in the case of hashes is an unlimited set of possible character combinations. Hashing algorithms are also commonly designed to be collusion resistant—it’s nearly impossible for two different inputs to generate the same hash. These properties make it so that changing anything in the input, such as the capitalization of a letter or the addition of a punctuation mark, will result in a completely different and seemingly random hash output.

The most popular secure hashing algorithm today is SHA-256, which makes strings that are 256 bits in length (i.e. 256 consecutive 1s and 0s). 256-bit hashes are often represented in hexadecimal string format, hence why they may appear 32 or 64 characters in length. SHA-256 exists within the SHA-2 set of hash functions, superseding the now cryptographically broken SHA-1. SHA-3 was also introduced in 2015 based on the cryptographic primitive Keccak.

Changing one character in the hash, such as adding the comma in the second input, will completely change the output and appear totally random to observers.

Symmetric Encryption

Symmetric Encryption (aka Secret-Key Encryption) involves a common secret key that both the sender and receiver use to encrypt and decrypt messages. Symmetric encryption is fast and efficient but comes with the challenge of sharing the secret key over the Internet in a secure manner. While sharing can be done in person, it’s not a method that’s globally scalable since it requires formal relationships with each counterparty. The other problem is that once the secret key is compromised, anyone using it is at risk of all previous and future messages being decrypted. This is why many Internet protocols that use symmetric encryption, such as TLS, also make use of key exchange protocols to securely establish a shared secret key without ever sending it over the Internet.

The most popular symmetric encryption cipher is Advanced Encryption System (AES). AES offers key sizes of 128, 192, and 256-bits in length—a substantial upgrade over the 56-bit keys used in the previous and now insecure Data Encryption Standard (DES) standard. For context, a 56-bit key has 256, or 72 quadrillion, possible keys, which can be cracked in under 24 hours by brute force. Alternatively, the shortest key size in AES would take trillions upon trillions of years to try all 2128 possible keys, even when combining all the computers in the world.

Symmetric encryption uses the same secret key to encrypt and decrypt messages.

Asymmetric Encryption

Asymmetric Encryption (aka Public-Key Cryptography) gives each user a public and private key pair. The public key is visible to everyone while the private key is only known to the owner. Users can encrypt messages with their private key that anyone with the public key can decrypt. This is known as a digital signature, as it proves knowledge of a secret without revealing the secret (i.e. the user has the private key to the public key address). Users can also encrypt messages with someone else’s public key that only the person with the private key can decrypt (i.e. sending confidential information).

The most popular asymmetric encryption algorithms are RSA (named after its inventors Ramis, Shamir, and Adleman), ECC (Elliptic Curve Cryptography), Diffie Hellman (popular key exchange protocol), and DSS (Digital Signature Standard). Some asymmetric encryption algorithms are quantum-resistant while others are not and may have to be upgraded or abandoned in the future.

Asymmetric encryption requires each user to have a public/private key pair.

Cryptography in Blockchains

Blockchains leverage two primary forms of cryptography: public-key cryptography and hash functions. However, other cryptographic techniques are increasingly being used to bring scaling, privacy, and external connectivity solutions to blockchains. Below are some of the ways blockchains use cryptographic functions.

Transaction Authentication and Verification

Every user on a blockchain must have a public/private key pair and blockchain address in order to submit transactions on the network. The private key is used to generate the public key, and the public key is used to generate the blockchain address—generally a hash of the public key with the last 20 bytes added to a prefix such as 0x. Note that many blockchain wallets and traditional exchanges abstract away the generation of the public/private key pair and user interactions with it.

The blockchain address is similar to the real name associated with a user’s bank account (e.g. Pay to the Order…), except on blockchains it’s a pseudo-anonymous string of numbers and letters. The blockchain address is where a user stores funds and deploys smart contracts. The private key is akin to a pin code that the user must input to take actions on their account, such as to transfer funds and make changes to smart contracts. The public key is akin to the user’s bank account number and is used to verify their private key signatures.

When submitting transactions, the user sends a message from their blockchain address to the network containing both transaction data and a digital signature. The transaction data describes the action the user wants to take on the network while the digital signature authenticates the action. The digital signature is generated from two inputs: a hash of the user’s transaction data and their private key. The digital signature is then attached to the transaction data to form a digitally signed transaction.

Miners/validators and full nodes—who manage the blockchain—run a digital signature verification protocol to verify the validity of the transaction. The verification protocol will take the original transaction data and hash it. It will also decrypt the digital signature with the user’s public key to obtain a hash. If the two hashes are the same, then the transaction is considered valid. By combining hashing and public-key cryptography to support digital signatures, blockchains make sure that only the private key holder can access funds stored at the corresponding blockchain address.

Blockchains use digital signatures to authenticate and verify user transactions.

Block Production, Sybil Resistance, and Finality

Block production is the process by which miners/validators bundle pending transactions into data structures called blocks and propose them on the network. A block generally consists of a list of all transactions included in the block and a block header containing metadata from the block. To produce a block, a miner/validator needs to generate a valid block hash, or else the block will be rejected.

Proof-of-Work (PoW) blockchains (e.g. Bitcoin) host an open competition between miners, where the first to generate a valid hash (i.e. a hash starting with at least a certain number of zeros) through brute force is selected to propose their block to the ledger. PoW blockchains use hash functions in block production to ensure Sybil resistance—protection against a single entity controlling the block production process by spoofing alternative identities. Since hashing power is the only way for a PoW miner to increase their chances of being the block author, getting control over more network hashing power comes with proportional financial costs in the form of performing more computation. This not only prevents denial of service attacks but requires miners to put in “work” to even get the chance of obtaining rewards.

Proof-of-Stake (PoS) blockchains like Ethereum (post-merge) also generate hashes in block production, but the process is purposely designed to be easy since there is no competition between validators. Instead, PoS validators are generally chosen as block authors via randomization, often based on their stake-weight. PoS blockchains create Sybil resistance by requiring validators to deposit cryptocurrency (i.e. stake) in order to participate in block production. Thus, PoS validators have to commit financial resources to increase their chances of being selected as a block author. Oftentimes, their stake is subject to slashing (i.e. confiscation) if they break certain protocol rules such as including invalid transactions in their block or signing two blocks at the same height.

Generally, a valid block hash must have the following inputs:

Merkle root—a hash of all included transactions in the block that’s contained within a Merkle tree data structure.
Nonce—an arbitrary number/letter combo that produces a valid hash that meets the current difficulty target. PoW blockchains periodically adjust the difficulty of guessing a nonce to target a certain frequency of blocks (e.g. every ten minutes) while PoS networks make nonces relatively easy to generate.
Additional block metadata—this varies across blockchains but may include some of the following: the blockchain’s current software version, a timestamp, the mining difficulty target, a state root of the entire chain, or the current block number.
Previous block hash—the valid block hash from the previously validated block.

Blocks consist of transaction data, the Merkle root, other block metadata, a valid nonce, and a hash of the previous block.

Blocks include the block hash value of the previous block to cryptographically link them together in a chain, maintaining the chronological order of the ledger. This is why blockchains are said to be immutable, as it would require a lot of computing power and/or financial risk to undo previously validated blocks, referred to as block reorganizations or simply re-orgs. Even if just one transaction in a block is altered, the entire hash of that block changes and can thereby be easily spotted by other nodes. Note that not all re-orgs are malicious; i.e., 1-block reorgs at the tip of the chain are more common due to asynchronous network conditions. However, deep reorgs can be more contentious and are significantly more difficult to pull off the further back they occur.

In PoW blockchains, miners have to regenerate valid hashes for all of the blocks being replaced to perform re-org attacks, during which time other miners are expending computational resources to append new blocks to the most recent block. This is where the Nakamoto consensus logic that “the longest chain with the most work is the valid chain” comes into play, as it provides miners with a straightforward way to determine the valid version of the ledger.

This logic is why PoW blockchains are said to have probabilistic finality, as the further back an alteration is attempted, the less likely an attack will be successful. From probabilistic finality comes the notion of 51% attacks—miners need 51% or more of the hashing power to pull off a deeper reorg attack or censor other miners’ blocks. Probabilistic finality is also why centralized cryptocurrency exchanges typically only approve users to spend their deposited funds once a certain number of subsequent blocks have been mined on top of the block that includes their transaction (e.g. generally 6 blocks in Bitcoin, 32 blocks in Ethereum). This helps prevent double-spend attacks—when the same unit of a currency is fraudulently spent more than once.

In PoS networks, all or a portion of the validators not currently producing blocks are often tasked with attesting to the validity of new blocks via a voting mechanism. A validator attempting to perform a re-org will then have to put at risk their financial stake, with the penalty for going against the decentralized consensus (generally >2/3s of validators) increasing the deeper the attack. This generalized model of PoS brings cryptoeconomic properties to consensus algorithms such as Practical Byzantine Fault Tolerance, Tendermint, Casper, and HotStuff.

Some PoS blockchains also have a limit on how far back the blockchain ledger can be changed, essentially establishing a checkpoint at which every transaction before it has explicit finality. For instance, the merge of the PoS beacon chain into the current Ethereum network will split block production and verification into epochs, with each epoch having 32 slots that are 12 seconds each in length. During each epoch, all validators are randomly split into committee sizes of at least 128, with validators being mixed around every epoch. During each slot, a validator proposes a block, and validators from one or more committees attest to the block. This is designed so validators attest to one proposed block per epoch.

Ethereum block production and verification post Merge will be split into epochs with 32 slots, where a block can be proposed and attested to every slot. Source.

At the end of each epoch, blocks within the previous epoch are considered justified if at least two-thirds of all validators by stake attest to their validity (i.e. a supermajority). If two previous epochs are justified in a row, then the former epoch becomes finalized. Given ideal network conditions and validator participation, transaction finality would take place on average around 14 minutes. Once an epoch is finalized, the rules of the protocol prevent it from being reverted without external social consensus.

Data Storage

A blockchain is a ledger containing every transaction that has ever happened on a blockchain network in chronological order (although some blockchains are exploring pruning historical data past a certain checkpoint). The longer the blockchain runs, the larger the ledger becomes and the more costly it is for nodes to store and sync. Excessive storage and bandwidth requirements put at risk the blockchain network’s decentralization by increasing the hardware requirements of running a full node, potentially allowing a small group of entities to corrupt the network.

To encode ledger data in an efficient and secure manner, blockchains make use of data structures called Merkle trees. In a Merkle tree, each user transaction is hashed, then paired with another hashed transaction and hashed again. The hashes are continually paired and hashed up the tree until there is a single hash of all the hashes, referred to as the Merkle Root.

Bitcoin uses a Merkle tree for transactions based on the Unspent Transaction Output (UTXO) model, while Ethereum uses Merkle trees for transactions, state, and receipts (e.g. logs and events) in what’s referred to as an Account model with generalized smart contract support.

Merkle trees are an efficient way to store transaction data in blockchains.

Merkle trees are useful because they take up less disk space compared to other data structures and facilitate the efficient verification of data integrity and data inclusion in the ledger. Furthermore, because Merkle roots are included in block headers, they allow light clients connected to a trusted full node to quickly and securely verify that a specific transaction was included in a block without downloading the whole blockchain.

Other Cryptographic Techniques Used in Blockchains

Some of the other cryptographic primitives utilized within blockchains include:

Zero-knowledge proofs (ZKPs)—a method for a user (prover) to prove to another party (verifier) that they possess knowledge about a specific piece of information without revealing the actual underlying information. For example, on the Zcash blockchain, full nodes can prove that transactions are valid without knowing the sender, receiver, or transaction amount.
Trusted execution environments (TEEs)—the use of trusted hardware, such as Intel SGX, to perform confidential computation, where the integrity of the computation can be proven via cryptographic attestations. One instance of this is Oasis, a blockchain where all validator nodes utilize trusted execution environments to provide confidential and verifiable execution of smart contracts.
Threshold signature schemes (TSS)—a form of distributed key generation and signing used to authenticate computation performed by a decentralized network via a single cryptographic signature that only requires a threshold set of participants to sign. For instance, a transaction that only 10 out of 15 nodes need to sign for it to be considered valid.

Truth Generated From Decentralized Consensus

Game theory is a mathematics-based approach to strategy, concerned with predicting the actions of rational actors in a specified competition. Within game theory, mechanism design is the art of using incentives to achieve desired outcomes within strategic interactions.

Blockchains leverage mechanism design to incentivize a decentralized network of rational, self-interested nodes to maintain an accurate, immutable, always available, censorship-resistant ledger. This desired outcome is sometimes summed up as achieving an honest majority—a majority of nodes in a blockchain network participating honestly, enabling users to consistently trust network consensus.

Let’s look at how blockchains are structured and incentivized to achieve truth via an honest majority outcome.

Game Structure

Blockchains are transparent ledgers powered by open-source software, meaning all participants can view the entire history of the ledger and verify how the code functions. Blockchain network participants are split into five general groups:

Users make transactions on the network, either for personal reasons or to host applications. On permissionless blockchains, anyone is allowed to submit transactions to the network at any time.

Miners/validators extend the ledger by producing new blocks from user transactions. Some blockchains allow anyone to be a miner/validator while other blockchains are capped at a limited number or permissioned set of participants. Some offset this limitation by allowing users to vote on or delegate stake to validators.

Full nodes have several functions on blockchain networks. First, full nodes provide RPC endpoints that enable users to read from and write to the blockchain. RPC endpoints are possible through self-hosted nodes or available through third-party providers (e.g. Infura). When writing data to the blockchain (i.e. submitting transactions), full nodes either relay them to a public mempool or hold them within private transaction pools. This is because there is no single transaction pool in a peer-to-peer decentralized network, but rather each full node has its own pool of transactions.

Full nodes also check the validity of users’ transactions before relaying them to the network or prior to propagating other nodes’ transactions on the network. Furthermore, full nodes validate new blocks proposed by miners/validators, serving as a way to self-verify the blockchain ledger. If they deem the block as valid, they will append it to their copy of the ledger. If they don’t think it’s valid, they will reject the block and not update their ledger. The consensus amongst the decentralized network of full nodes represents the current state of the ledger—the culmination of all blockchain addresses, their balances, deployed smart contracts, and associated storage. Anyone can run a full node, although the hardware requirements vary across networks. Miners/validators often participate as full nodes.

Blockchains separate the roles of miners/validators and full nodes for increased security on the network.

Service providers are external entities that provide services to blockchains or create services based on the content of blockchains. This includes oracles, indexing protocols, centralized exchanges, light clients, archive nodes, block explorers, and many more. These entities generally have business models that require interaction with a blockchain. For instance, centralized exchanges provide on/off ramps between cryptocurrencies and the traditional financial system, light clients allow users to verify information sent from full nodes without needing a full copy of the ledger, and oracles provide key external resources to smart contract applications.

MEV bots are entities that seek to influence how transactions are ordered during block production, particularly miners and MEV developers. Miner extractable value (MEV), also called maximum extractable value, is based on the ability of miners/validators to choose which transactions are included in a block and how those transactions are ordered. They can then use this privilege to their advantage to extract value, such as by frontrunning or sandwich attacking users and capitalizing on liquidation and arbitrage opportunities. MEV bots generally operate via private transaction pools and off-chain block space auctions, although they may operate independently.

Game Incentives

Incentives are split into two broad categories: implicit and explicit. Explicit incentives are direct rewards or penalties for actions taken in the game, such as a mandatory payment to access a service or a hardcoded fine for breaking a protocol rule. Implicit incentives are indirect rewards and penalties derived from the game, such as participants losing out on future revenue opportunities or expending labor without guaranteed compensation.

The most obvious incentives in blockchains are the block reward and transaction fees paid to miners/validators for producing approved blocks. Block rewards are generally standardized in quantity while transaction fees can fluctuate higher or lower depending on the current demand for limited block space. Within the block production process are also incentives to order transactions in a particular way, which MEV bots seek to take advantage of for financial gains.

Blockchains also make use of financial penalties through Sybil resistant mechanisms such as PoW and PoS; i.e. miners/validators need to commit a computational or financial stake in order to get a chance at earning rewards, which can be wasted or slashed should they go against network consensus. Another benefit of requiring block producers to commit a computational or financial stake is that it incentivizes decentralization. Particularly because it becomes increasingly more expensive for a miner/validator to obtain more control over the network’s hashing power or stake.

Blockchains also pay miners/validators in their own native cryptocurrency. This creates an implicit incentive for miners/validators to participate honestly in the network, as a secure and reliable network is likely to attract more users. More users lead to more transaction fees, as well as a potentially higher price for the cryptocurrency they earn. A higher crypto price can mean greater per-block revenue and an increase in any personal holdings.

Bitcoin has a form of implicit staking where miners are rewarded in an asset (BTC) that only remains valuable and covers their expenses if they uphold the security of the network.

While there is usually not an explicit incentive built directly into the protocol to run a full node, there are many implicit incentives to do so. To start, full nodes are required for the network to operate, so at a minimum miners need to run them. Users, applications, and service providers also need to run or have access to full nodes in order to submit and verify the status of pending transactions. Thus, several free and node-as-a-service models exist to support the ecosystem.

Beyond financial incentives, full nodes are critical to the integrity of the ledger, as a lack of decentralization will give a smaller group of participants control over the network. A compromised ledger will then affect service providers and decentralized applications that have business models solely reliant on the honest majority assumption of blockchains being upheld.

A decentralized full node network also helps separate block generation from block verification, keeping miners/validators accountable by reducing their ability to arbitrarily change the protocol’s rules. Furthermore, entities running their own full node experience the greatest level of censorship resistance and security guarantees, given that they don’t need to trust any third party to read or write to a blockchain. These implicit incentives combine to encourage users and key economic actors to run full nodes.

Game Outcome

The introduction of these incentives within the stated game structure lead to the desired outcomes of blockchains:

Accuracy—the decentralization of blockchains, the implicit/explicit costs at stake, and the ease of detecting invalid transactions incentivize miners/validators and full nodes to reach honest consensus on the validity transactions.
Immutability—the financial cost and risk of attempting to alter a previously approved block render doing so largely undesirable, especially as more blocks are produced on top of the target block.
Availability—sufficient rewards help ensure miners/validators constantly generate blocks, while having a substantial amount of value at stake incentivizes full node networks that scale beyond miners/validators.
Censorship Resistance—Sybil resistance mechanisms, financial rewards, and the ability to permissionlessly participate make it incredibly expensive for any centralized entity to attempt to censor transactions, especially for a prolonged period of time.

With these desired properties come stronger incentives for users to interact with the blockchain network. Not only could usage go up, but users become comfortable storing higher amounts of value on blockchains and using their on-chain assets in smart contract applications.

However, it should be noted that while blockchains are generally censorship-resistant and accurate, the ordering of transactions in terms of send time or fee paid is not guaranteed due to MEV. This is why Chainlink is developing Fair Sequencing Services (FSS)—an oracle service for decentralized ordering of transactions for blockchains, layer-2 networks, and applications based on the time they are received.

It should also be said that blockchains are ultimately systems run by humans to serve humans, so if everyone comes to a social consensus (i.e. off-chain agreement between participants) that something with the blockchain needs to change, then it can be done. The clearest example of social consensus driving change was an Ethereum hard fork—a backward-incompatible software update—that restored stolen funds from The DAO hack in 2016. Social consensus can also happen in reverse, where community participants prevent proposed changes from being deployed, such as the rejection of Segwit2x for the Bitcoin network and ProgPoW for the Ethereum network.

With that being said, blockchains are arguably the most effective networks at protecting against unwanted attacks and changes that go against a supermajority of social consensus, particularly through cryptographic and economic mechanisms.

How Chainlink Leverages Cryptographic Truth to Build a Global Truth Machine

The focus of this article so far has been on how blockchains combine cryptography and game theory to consistently form honest consensus—the truth—regarding the validity of internal transactions. However, how can events happening outside a blockchain be reliably verified? Enter Chainlink.

Chainlink is a decentralized oracle network designed to generate truth about external data and off-chain computation. In this sense, Chainlink generates truth from largely non-deterministic environments. Determinism is a feature of computation where a specific input will always lead to a specific output, i.e., code will execute exactly as written. Decentralized blockchains are said to be deterministic because they employ trust-minimization techniques that remove or lower to a near statistical impossibility any variables that could inhibit internal transaction submission, execution, and verification.

The challenge with non-deterministic environments is that the truth can be subjective, difficult to obtain, or expensive to verify. For example, what is the price of Bitcoin? The answer is that there is no universal price of Bitcoin since it varies across exchanges, which are each in a constant state of change. Furthermore, will all users agree on the price they are willing to pay for the truth and the amount of certainty a specific methodology provides in obtaining it? For instance, a network of numerous high-performance IoT devices will obtain a more accurate weather reading than a single low-quality sensor, but will also be more expensive to install and run. These situations highlight the reality that the methodology for generating external truth and the cost people are willing to pay for it will vary from person to person and company to company.

Since blockchains only keep a single source of truth between all users and applications, Chainlink is critical infrastructure because it gives users the ability to create their own definitive truth—a predefined method for generating truth that all parties involved agree is authoritative for the purpose of settling their agreements. Furthermore, the oracle mechanism used to generate the definitive truth can be verified, with its terms enforced, using the cryptographic guarantees and deterministic computing of blockchains.

By combining definitive truth with cryptographic guarantees, decentralized oracle networks can securely, reliably, and accurately perform off-chain services and prove they are in alignment with user-defined parameters.

In this sense, definitive truth is a user-defined consensus mechanism for decentralized oracle networks that anchor themselves to blockchains to operate in a more trust-minimized manner. Some of the consensus parameters users are able to define include the infrastructure of the oracle network, the specific data sources used, the exact computation performed, the rewards/penalties earned, and how the oracle network will prove the integrity of its work to the blockchain. And while these parameters can be customized to meet a variety of budgets, performance requirements, and trust assumptions, industry standards will also take root, with whole markets or large segments of markets agreeing upon as a shared source of truth.

In terms of trust-minimization, Chainlink uses many of the same methods employed by blockchains, such as:

Cryptography—Each Chainlink oracle node has a public/private key address on each supported blockchain. Nodes use these keys to generate digital signatures on all computations they perform, with the signatures verified and stored on blockchains. The cryptographic signature not only proves who delivered the data and what their computation was, but it helps support reputation systems that track the on-chain performance of nodes, such as their historical uptime and accuracy. The signed data of oracle nodes and oracle networks can also be used to trigger the issuance of rewards and penalties.
Decentralized Consensus—Chainlink utilizes decentralization at the data source, oracle node, and oracle network levels to mitigate any point of failure and control in the sourcing, delivery, and computation of data. This empowers users to aggregate data from as many specific sources and nodes as they need and are willing to pay for in order to prove with a high degree of certainty the validity of an external event or off-chain computation.
Financial Incentives—Chainlink nodes get paid for providing oracle services in the form of user fees. Additionally, as part of a future cryptoeconomic staking model, LINK tokens can be staked as collateral to further incentivize honest oracle services. The staked LINK collateral can be subject to slashing in the event of poor performance or malicious behavior by the node, such as withholding data/computation, not delivering data on time, or supplying data that deviates a certain percentage from the DON’s overall median value.

The end result is a trust-minimized framework for performing off-chain computation according to any user-defined parameters, with the results along with signatures delivered to the blockchain where they can be verified. These new hybrid “on-chain/off-chain” applications vastly extend the value proposition of blockchains because they allow on-chain smart contract code to react to and directly influence data and computation from external environments, such as data providers, web APIs, IoT networks, other blockchains, legacy backends, payment systems, or any type of external resource.

Chainlink can provide an end-to-end framework for hybrid smart contracts powered by cryptographic truth.

As an example, Chainlink Price Feeds are decentralized oracle networks that use a multi-layer aggregation architecture to generate an industry standard for cryptographic truth regarding real-time asset prices and financial market information.

With Chainlink Price Feeds, data is aggregated by professional data aggregator companies, which generate volume-weighted average prices (VWAPs) from raw data across hundreds of exchanges. Each Chainlink node then fetches a VWAP from multiple data aggregators and takes a median. Finally, the median values of each Chainlink node are further aggregated into a median to create a single trusted value that’s stored on blockchains. The values submitted by each node and the oracle network as a whole can be verified by anyone via on-chain data.

Traditional and decentralized finance applications use these prices to perform critical operations, such as issuing and liquidating loans, settling derivatives contracts, and setting exchange rates.

Chainlink Price Feeds generate cryptographic truth for the real-time prices of financial assets.

A World Powered By Cryptographic Truth

Ultimately, cryptographic truth brings determinism, accuracy, and transparency to computing and record keeping. By knowing that application code will execute as intended and that historical records have been redundantly validated and will remain tamper-proof, social and economic relationships can be grounded in deeper levels of truth than ever before. Having a sound foundation of truth leads to increased economic activity and strengthens social harmony—a world everyone wants to see manifest. This is why it’s on all of us to build and adopt blockchain and oracle technologies that establish cryptographic truth across core pillars of our collective society.

If you enjoyed this article, we encourage you to read What Crypto Is Really About, a blog post examining the current need for cryptographic truth within our existing economic and social systems.

If you want to familiarize yourself more with blockchain and oracle technologies, we encourage you to check out the growing list of educational materials on the Chainlink blog.

To learn more about Chainlink, visit chain.link, subscribe to the Chainlink newsletter, and follow Chainlink on Twitter, YouTube, and Reddit.

The post Cryptographic Truth: The Future of Trust-Minimized Computing and Record-Keeping appeared first on Chainlink Blog.

Publication date

03/16/2022 - 16:04

Author

Chainlink

Article source

Disclaimer

The views and opinions expressed in this article are solely those of the authors and do not reflect the views of Bitcoin Insider. Every investment and trading move involves risk - this is especially true for cryptocurrencies given their volatility. We strongly advise our readers to conduct their own research when making a decision.