Forem: Yury Oparin

Smart Contracts in 10 minutes: Risks, NFTs, storage options

Yury Oparin — Thu, 12 Jan 2023 09:11:42 +0000

This is a series of posts on Blockchain, Ethereum, Smart Contracts and their security. The work was done in collaboration with Dr. Andrew Melnik, Marvin Koppka and Mustafa Erdogan at Bielefeld University under ISY Project: NFTs and Cryptocurrencies With Smart Contracts with the aim to provide a reference material on the blockchain technology.

In this final post we will consider Smart Contracts, give their quick overview, talk about advantages and limitations, as well as risks, including reentrancy attack, and the way to cope with these by following ERC standards. We will provide a popular NFT use case with the objective to examine its storage options and associated risks.

Part 3. Smart Contracts

See also Part 1. Blockchain for an overview of Blockchain, its security fundamentals and issues arising from the choice of its consesus algorithm, such as 51% attack and energy consumption, and Part 2. Ethereum on its architecture and two consensus algorithms, Proof of Work and Proof of Stake, which allow all nodes in the network to agree on a single state of the blockchain.

3.1 What Are Smart Contracts And Their Advantages?

Smart contracts is a type of code that allows for verification and execution of a contract securely and automatically. These smart contracts run on the Blockchain system, with well-defined rules and penalties depending on the contract agreement and automatically enforce those obligations. Also, smart contracts can call other smart contracts or run independently.

When the predetermined conditions are verified and reached, nodes execute the set actions. Actions include the transferring of funds to appropriate parties, emitting events or calling other smart contracts, which update the blockchain state.

As required, contracts could be set with more than one stipulation, focusing on each participant's satisfaction and competent task execution. Participants determine how their transactions and execution data should be represented on the blockchain by agreeing on the rules that control the transactions.

In that case, developers could program and customize smart contracts on the blockchain. For example, Ethereum allows developers to access the Ethereum Virtual Machine (EVM) for execution of smart contract code. Further, organizations implementing blockchains offer web templates and other online tools that can help developers form a basic structure for smart contracts.

Smart contracts have a number of advantages. The primary one is transparency, a result of transaction distribution across all nodes in the network. This provides the parties with security and trust because they always have access to the data and information relating to the contract thereby minimizing the possibility of contract manipulation or misuse.

As smart contracts are deployed on blockchain, they guarantee immutability of their data, allowing contracts and agreements to be made without the need to know each other and prevent potential breaches of conditions or errors in the management and execution of the contract.

Secondly, autonomy is another advantage of smart contracts that provide trusted third parties with no intervention from intermediaries. This feature reduces costs and increases process speed compared to how traditional contracts with intermediaries are executed.

The next section will focus on topics specific to non-fungible tokens (NFTs).

3.2 NFTs

NFTs come in many forms but the most typical one is a metadata file that contains information encoded with a digital tokenized version of the work. The second form involves uploading a complete piece of work to the blockchain, although it is less frequent because of high cost of uploading large files to the blockchain. These files are uploaded to NTF Smart Contracts which are based on the ERC-721 standard, discussed further in Section 3.5. This standard specifies required and optional elements, see Figure 1.

Figure 1: NFT Metadata.^[10]

The TokenID, a number generated when the token is created, is the first required field. The NFT Smart Contract address, a blockchain address that can be examined searched by using a blockchain scanner, for example, is the second fundamental component. Only one token on the blockchain is allowed to have a given combination of TokenID and contract address, making tokens unique across the blockchain.

These two numbers are the only fundamental components of NFTs. Other components may also be included in the NFT Smart Contract. One of them is the creator’s wallet address, which links the NFT back to its originator. In the next section we will see how we can verify the originality of NFTs.

3.2.1 Copyright

Most of NFTs are metadata files that have been encoded with works that may or may not be covered by copyright protection (it is possible to create an NFT of a trademark), or it could even be a work that is in the public domain. An NFT may be created from anything that can be converted into a digital format, the original work is only required at the initial phase of the process when creating a unique combination of the TokenID and the contract address. Therefore, in theory, copyright is not enforced by NFTs.

Nevertheless, there is a rising interest in NFTs from a copyright perspective. This is partly due to the fact that many works are being exchanged as NFTs, such as work of art which is covered by copyright. This is particularly true for NFTs representing digital objects, e.g. in digital rights management, where NFT Smart Contract and blockchain functionality is enough to enforce copyright.

For NTFs that do not fully encapsulate the protected object, such as a physical object or actual files, there is a prevalent misunderstanding of the rights that buyers acquire when they purchase an NFT. Some buyers believe they acquire the underlying work of art together with all its rights,
while they only purchase metadata related to the work and not the work itself.

While most NFTs do not transfer the rights for their protected object, the seller occasionally offers to turn the token into an actual transfer of copyright ownership of the original work. However, it is challenging to determine if this complies with the formal procedure required by law to transfer copyright.

In the next section we will explain the limitations of smart contracts.

3.3 Limitations of Smart Contracts

3.3.1 Irreversibility

Given that smart contracts are immutable on the blockchain, it is impossible to change the way they work after they have been deployed and hence fix code errors. Another issue comes from the fact that successful transactions are irreversible which combined with the first issue makes them vulnerable and defenseless against exploits and hacks.

3.3.2 Crack

The idea of good faith stipulates that parties will deal fairly and refrain from obtaining unethical gains from a smart contract. However, it is challenging to guarantee that these terms are followed in accordance with what was agreed upon when utilizing smart contracts. This is mostly related to hacks of smart contracts that exploit system design vulnerabilities, e.g. Reentrancy attacks, described in Section 3.6.2.

3.3.3 Third Party Assessment

Even while smart contracts aim to do away with third parties, it is impossible to do so fully. In contrast to the functions they play in conventional contracts, third parties take on new responsibilities. For instance, attorneys won't be required to draft individual contracts, but developers will still need them to comprehend the conditions when writing the code for smart contracts.

3.3.4 Uncertainty Terms

Smart contracts cannot always manage unclear terms and conditions since contracts often include phrases that aren’t always clear, with most typical of them being "within a reasonable period of time", "without undue delay" or "obligations to cooperate."

After explaining limitations, we will move on to the functionality of smart contracts.

3.4 Functionality of Smart Contract

"Smart contracts work by following simple if/when...then... statements that are written into code on a blockchain. A network of computers executes the actions when predetermined conditions have been met and verified. These actions could include releasing funds to the appropriate parties (DeFi Protocols allow individuals to borrow funds against a collateral cryptocurrency or Token Protocols, such as USDC and other stablecoins), registering a vehicle (DIMO makes possible applications like parametric insurance, peer-to-peer car sharing and vehicle marketplaces), sending notifications (Push Protocol enables cross-chain notifications and messaging for dapps, wallets, and services), or issuing a ticket (Ticketmaster recently announced they would let event organizers issue NFTs tied to tickets). The blockchain is then updated when the transaction is completed. That means the transaction cannot be changed, and only parties who have been granted permission can see the results."^[5]

Currently, Ethereum is the most popular among other smart contract platforms, while several other cryptocurrency blockhains, including as Tron, Polkadot, Avalanche and Solana, are also capable of supporting smart contacts. These blockchains made it easy for developers to create and deploy smart contracts. There is a selection of programming languages to write code in, e.g. Solidity, WebAssembly or Rust. Smart contracts are usually stored on the blockchain with their code and current state visible and queryable even via online scanner websites.

Moreover, along with the blockchain and transaction data, every node on the network keeps a copy of all active smart contracts and their current state. All nodes in the network execute smart contract code when users interact with.

Because of this smart contracts may run safely without the need for a centralized authority, even when users conduct complex financial transactions with unidentified entities. On Ethereum, users often have to pay a charge called “gas” to execute a smart contract (so-called because these fees keep the blockchain running).

Another important behavior of smart contracts is that once deployed onto a blockchain, they cannot be changed, even by their creators. Partly to cope with issues arising from that last point (see the previous Section 3.3), the Ethereum community came up with the process of standardization, which we will discuss in the next section.

3.5 ERC

"ERC is essentially an acronym for Ethereum Request for Comments. In general, ERCs are specifications for Ethereum applications, such as token standards, name registries, library formats, and package formats. An author may create an Ethereum Blockchain app with an ERC token, but they will need to clarify their standard and gain community approval."^[12]

3.5.1 What Are ERC Standards?

Ethereum Request for Comments (ERC) is a document with specifications that smart contract developers use to write smart contracts on the Ethereum blockchain platform. The Ethereum developers and community utilize this procedure, also known as the Ethereum Improvement Proposal (EIP), to examine these documents and suggest changes which can be taken into account by the document authors and result in revisions published.

The most common ERC standard is ERC-20 Token Standard. It makes it easy to develop, use and trade Ethereum-based fungible tokens by providing a standard set of fields and functions for a token smart contract. For non-fungible tokens or NFTs there is another widely used standard ERC-721. Unlike traditional fungible tokens, NFTs cannot be split up and are unique. They may be owned and transacted by one person or they may be assigned to another party. NFTs can signify ownership over digital or physical assets.

Figure 2 depicts popular ERC standards and gives their brief descriptions.

Figure 2: ERC Standards List for Tokens.^[13]

In the next section we will look at some of the risks and issues with Smart Contracts.

3.6 Risks and Issues

3.6.1 Immutability Issue

Smart Contracts, unlike traditional contracts, miss an important feature, namely a severability clause. This clause refers to a clause added to complex contracts which prevents mistakes in the contract to fully invalidate it. This however happens to Smart Contracts. If a deployed Smart Contract is found invalid, it cannot be changed, even though it might entail crucial bugs. As such, the Blockchain gets flooded with immutable, not optimized and partially faulty code. The ERC Standards mentioned in Section 3.5 prevent crucial bugs from happening, such as Reentrancy attacks, which led to a famous The DAO Hack on Ethereum in 2016 discussed in the next section.

3.6.2 Reentrancy Attack

This destructive attack involves two Smart Contracts calling each other when sending funds, see Figure 3. An untrusted Contract B requests its funds from Contract A, which after checking Contract B's balance, sends the requested funds to Contract B. Contract B uses a special fallback function that is triggered when a contract receives Ether without any data sent with the transaction. This function requests more funds from Contract A, which hasn't yet updated Contract B's balance because the external call to Contract B happens in the same transaction and hence is executed sequentially for both contracts on the Blockchain. This allows Contract B to drain all of Contract A's funds.

Figure 3: Reentrancy Attack.^[11]

That type of attack is the most well-known attack on the Blockchain because of the The DAO Hack on Ethereum in 2016, leading to a loss of 3.6 million Ether. The hack worked by having the attacking smart contract continuously calling the withdraw function of The DAO before it updated the balance of the vulnerable smart contract. This attack scenario was successfully repeated in 2021 with the SIREN protocol hack, draining approximately $3.5 million from its AMM pools by using a similar fallback mechanism in ERC-1155.

The next section will discuss issues with storing NFTs.

3.6.3 NFT On-Chain and Off-Chain Storage

Non-fungible Tokens or NFTs is a trending technology supported by the ERC-721 standard.^[14] The most common use case of NFTs is creating and distributing art pieces that carry crucial information such as the history of its owners on the blockchain and is known to be duplicate-proof. However an important factor to consider is the way NFTs are stored by applications.

On-Chain NFTs

On-Chain NFTs are tokens that are written on the Blockchain (e.g. Ethereum), including their image and metadata, see Section 3.2. This information also includes the transaction hash of the generated NFT, which makes NFTs more unique.

Off-Chain NFTs

However some NFT projects store their Smart Contracts on the Blockchain while keeping the NFT image and metadata off-chain in order to save on gas costs. This off-chain storage can be placed with the cloud service providers, such as AWS, GCP, Azure but also Google Drive and Dropbox. Even more trendy is to keep metadata on the "interplanetary file system" (IPFS) nodes designed to address issues with distributed web. In all those cases, problems still exist. For example, an NFT file or metadata can be deleted by the NFT creator at any time, severing the connection between the file and the blockchain on which the NFT ownership for the file is recorded.

Another issue concerned with NFTs are impersonation attacks, also called sleepminting, in which an NFT is minted to a different address than that of the transaction sender.^[20] The creator of the NFT is therefore displayed at this different address, confusing buyers, as certain creators have a higher innate value to their creations, such as CryptoPunks. If bought, the original transaction sender initiates another transaction for the NFT to be transferred to the buyer and receives the funds.

Evidently, some issues and risks for this "decentralized payment platform that would revolutionize the way we pay everything" still persist for the Blockchain and its resulting technologies.^[13] Former issues of banks were partially solved, but new issues are created. As such, existing issues shifted.

Conclusion

This series of posts (Part 1. Blockchain, Part 2. Ethereum and Part 3. Smart Contracts) summarizes the design of blockchain and its main components. One of them is smart contracts, which are now widely used in digital finance and applications where ownership of digital assets is transferred, for example, NFTs. Being exposed to the public, these applications require bulletproof protection from potential attacks. This protection was originally believed to come from the blockchain itself, which includes various security features such as sophisticated encryption mechanism, Merkle trees, consensus algorithms and data distribution across the whole peer-to-peer network.

However faced with numerous attacks, the blockchain community came up with additional measures realized in the form of standards, with the most famous one on Ethereum, the ERC. Surprisingly, that wasn't enough. Because of high cost and small throughput of running transactions on blockchains, specifically Ethereum, developers do not store all application state in smart contracts, offloading its biggest part to off-chain storage that neither has security guaranties of the blockchain nor follows the smart contract community standards. This particularly concerns NFTs, as their buyers need to be aware of the risks involved when purchasing widespread Off-Chain NFTs versus more expensive On-Chain NFTs.

References

The Merge on Ethereum, https://ethereum.org/en/upgrades/merge/.
Ethereum nodes and clients, https://ethereum.org/en/developers/docs/ nodes-and-clients.
Chapter 4. Cryptography — Elliptic Curve Cryptography Explained, https://www.oreilly.com/library/view/mastering-ethereum/9781491971932/ch04.html.
Ethereum Yellow Paper, https://ethereum.github.io/yellowpaper/paper.pdf.
Functionality of smart contracts, https://www.ibm.com/topics/smart-contracts.
The Keccak reference, https://keccak.team/files/Keccak-reference-3.0.pdf.
The Keccak SHA-3 submission, https://keccak.team/files/Keccak-submission-3.pdf.
Merkle Tree, https://soliditydeveloper.com/merkle-tree/.
Blogpost of Vitalik Buterin — Merkling in Ethereum, https://blog.ethereum.org/2015/11/15/merkling-in-ethereum.
NFT Metadata, https://www.weforum.org/agenda/2022/02/non-fungible-tokens-nfts-and-copyright/.
Reentrancy attack in a Solidity smart contract, https://cryptomarketpool.com/reentrancy-attack-in-a-solidity-smart-contract/.
ERC Token Standards - The Ultimate List, https://www.blockchain-council.org/ethereum/erc-token-standards/.
Why Does Bitcoin Use So Much Energy? https://www.forbes.com/advisor/ca/investing/cryptocurrency/bitcoins-energy-usage-explained/.
ERC-721 Non-Fungible Token Standard, https://ethereum.org/en/developers/docs/standards/tokens/erc-721/.
Ethereum block architecture, https://ethereum.stackexchange.com/questions/268/ethereum-block-architecture.
Ethereum Virtual Machine, https://ethereum.org/en/developers/docs/evm/.
Ethereum Wallets, https://ethereum.org/en/wallets/.
Cryptographic Hashes and Bitcoin, https://freecontent.manning.com/cryptographic-hashes-and-bitcoin/.
Private and public keys on Ethereum, https://www.massmux.com/private-and-public-keys-on-ethereum/.
What Is Sleepminting And Will It Ruin NFT Provenance? https://timdaub.github.io/2021/04/22/nft-sleepminting-beeple-provenance/.
Pentagon finds concerning vulnerabilities on blockchain, https://www.techrepublic.com/article/pentagon-finds-concerning-vulnerabilities-on-blockchain/.
A. M. Antonopoulos and G. Wood. Mastering Ethereum: Building Smart Contracts and DApps. O’Reilly Media, 2018.
Bitcoin Energy Consumption Index, https://digiconomist.net/bitcoin-energy-consumption.

Ethereum: Workflow and Consensus Algorithms in 10 minutes

Yury Oparin — Wed, 11 Jan 2023 12:53:34 +0000

In this second post we will examine Ethereum architecture and two of its consensus algorithms, Proof of Work and Proof of Stake, which allow all nodes in the network to agree on a single state of the blockchain.

Part 2. Ethereum

See also Part 1. Blockchain for an overview of Blockchain, its security fundamentals and issues arising from the choice of its consesus algorithm, such as 51% attack and energy consumption, and Part 3. Smart Contracts for a quick overview, risks, including reentrancy attack, and NFT use case with the objective to examine its storage options and associated risks.

2.1 Introduction

Ethereum is a decentralized community-driven open-source Blockchain created for various purposes such as Decentralized Finance (DeFi), more transparent supply chains, healthcare and smart contracts. With its special structure Ethereum saves additional information such as Transactions Receipts and the resulting state calculated by the Ethereum Virtual Machine (EVM) in multiple data structures called Patricia Merkle Tries.

Due to additional information given by the Tries, such as the state, light clients — nodes that do not have a full copy of the blockchain — are not just able to prove inclusion of transactions but also verify given information about the state. While this information would normally result in the verification of every single transaction in the entire chain, this can be apprehended by saving these states. As such, transactions in the Blockchain are more easily verifiable for certain kinds of queries.^[9] Additionally, Smart Contracts, which we will cover in the next post, enable automation of contracts effectively replacing the need for third parties, and creation of Tokens, such as non-fungible tokens (NFTs).

2.2 Workflow

Figure 1: Workflow of the Ethereum Blockchain based on its Yellow Paper by Lee Thomas.^[4]^[15]

Figure 1 outlines the workflow of Ethereum Blockchain detailing specific components of each data structure and Keccak-256 hashes indicated by red lines. In the following sections which we will explain different stages of that workflow.

2.2.1 Mining Network

Starting with the topside of the figure, the Mining Network, it consists of several computers called nodes forming a peer-to-peer network. Each of these nodes runs a blockchain client to access the Blockchain, albeit there are differences in nodes. A node can either be an archive, full or light node.^[2] Transactions added to the blockchain originate from nodes or wallets that interact with nodes.

These transactions get added to a node temporary memory pool, which is simply a pool of transactions waiting to be added into a candidate block, discussed in the previous post about Blockchain, see Section 1.3. Each node has its own memory pool where new transactions are added after being propagated along the network. Next, we will see what happens to these transactions.

2.2.2 Block Finalization

For transactions to be included in the blockchain they need to be included in a block (left side of the Figure 1 - Determine Transactions). The finalization of the block involves four stages which as can be seen in the Ethereum Yellow Paper (11. Block Finalisation) vary depending on whether the block is finalized for mining or has already been mined and needs to be validated.^[4] In our case, ommers and transactions need to be determined and added to the block. The first transaction in the list of transactions is the application of rewards, the beneficiary address for miners to receive rewards. After that, at the fourth stage the process of mining starts which computes a valid state and block nonce. Before explaining the process of the consensus algorithms let us first examine the block structure, including the data structures used and the way transactions are added to the network.

2.2.3 Accounts and Blocks

As shown in Figure 1 and Figure 1, 2 from the previous post, blocks consist of a Block header, transactions and an ommers list. Transactions can be added by Ethereum accounts, namely Externally owned accounts (EOA) and contract accounts. Accounts, as discussed in the previous post Section 1.1.3, are generated from 256-bit private keys using elliptic curve algorithms. Externally owned Accounts are essentially accounts created and controlled by anyone holding the corresponding private key. While EOAs can receive, hold, send Ether or tokens and interact with deployed smart contracts on their own, contract accounts can only send transactions after receiving incoming transactions from either EOAs or other contracts if the first transaction was initiated by an EOA. Contract accounts are smart contracts deployed in the network and are controlled by code. They will be discussed in the next post.

Figure 2: Ethereum - Accounts.

As depicted in Figure 2, each account has four fields, the nonce, balance, storage hash and code hash equal to the one from Figure 1 (the bottom right side of the figure). The code hash represents a hash of the EVM code of the account, which is executed if the address receives a message call. For EOAs this code is the hash of an empty string.^[4] The code of accounts is stored in the state database. The storage root is "a 256-bit hash of the root node of a Patricia Merkle Trie that encodes the storage contents of the account". Without going into too much detail, a Merkle Tree is an efficient data structure for key-value mappings that enables fast and secure validation of given data, see Section 1.1.5 of the previous post. Its main feature is that any change in a node yields different hash values in the nodes above the changed one, including the root node. Because of this property Ethereum light clients can operate making the functioning of the network much cheaper. In addition, Ethereum stores the root hashes of three other trees, namely the World State Trie, Transaction Trie and Transaction Receipts Trie. The World State Trie is a "mapping between addresses and account states" where each leaf node represents an account state. Therefore account states, i.e. their balances, nonce values and the hashes for the storage root and code, become traceable and verifiable at any point in time. That also refers to state changes enacted by transactions as these are stored in the Transaction Receipts Trie, while the Transaction Trie is derived from the transaction list.

In the next section we will look at how such blocks are added to the blockchain.

2.2.4 Consensus Algorithms

As previously mentioned in the overview of Blockchain (see Section 1.3) the process of adding blocks to the blockchain depends on the consensus algorithm in use. These algorithms allow all nodes in the network to agree on its single state. Before September 15, 2022 Ethereum used the Proof of Work (PoW) consensus protocol Ethash, while after that date a much more efficient algorithm Proof of Stake (PoS) was merged into the network. Both algorithms will be covered in the next two sections.

Proof of Work

For PoW, nodes in a peer-to-peer network are referred to as miners. To recap, each miner builds a candidate block from pending transactions in its temporary memory pool. The miners can choose transactions they want to add into the candidate block and then start with the mining process. Mining describes the process of hashing the candidate block until a valid hash could be found. For a candidate block to be valid, the hash of the block needs to be below a certain target value. This target value adapts to the computational power existing in the network and is updated in intervals. As shown in Figure 3 a value called number used once (nonce) in the block header is changed in an iterative manner until a valid hash value is found. Due to several resistances of Keccak-256 (see Figure 5 in the post about Blockchain) mining is done by brute force, which involves changing the nonce value until the resulting hash becomes valid. The newly found valid block is propagated along the network.

Figure 3: Finding a valid hash below the target value by adapting the nonce value.

This brute force technique and competition to win the reward by first announcing a new valid block requires high computational effort from all network nodes. On the one hand, it leads to immensely increased safety as well as a reduction in the likelihood of attacks such as the double spending attack in which the same currency is spent multiple times by tempering with the Blockchain. But on the other hand, massive energy consumption and slow addition of new blocks makes PoW highly inefficient and unsustainable. For this reason, Ethereum changed its consensus algorithm to Proof of Stake on September 15, 2022, known as "The Merge".^[1]

Proof of Stake

With PoS, nodes are referred to as validators minting or forging blocks. Each validator stakes coins acting as a security deposit in case of the approbation of fraudulent blocks by the validator. As a result, trust is built in validators because the stakes are higher than benefits gained from approving wrong transactions. The chance of being chosen as validator increases with the amount of the staked coins. A chosen node validates transactions in the block and adds them to the blockchain for which it is rewarded with the fees of the included transactions. The fees as well as staked coins are released when a node discontinues being a validator, albeit the release is delayed in order to deduct coins if necessary.

The energy consumption of Ethereum using PoS was reduced by 99.95% and the time necessary for adding new blocks could be significantly reduced.^[1] Furthermore, PoS decreases the need for high hash rates and thus the need for expensive and massive amounts of hardware. Additionally, it might yield increased decentralization as mining in pools is suspended together with the reduced necessity of expensive hardware, producing more distributed nodes that contribute to the network. While the majority of attacks are still possible, the benefit outweighs the loss of the 51% staked coins necessary, together with the possible fluctuations of the coin as a result of such an attack.

After a new block has now been added to the blockchain via PoW or PoS, it is propagated along the network to other nodes which validate it and include it into their copy of the blockchain. As stated in the Ethereum Yellow Paper and illustrated on the left side of Figure 1, the block is finalized in four stages which slightly vary depending on whether the block is mined or propagated and validated.^[4] Compared to mining, where the ommers and transactions for the candidate block are determined, the reward is applied and a valid state and nonce are computed with the consensus algorithm, validation of valid blocks is done for all other nodes in the network and involves validating the ommers, transactions, applying the rewards and verifying the state and nonce of the valid block.

Next we will look at how how these states are verified.

2.2.5 Ethereum Network

The verification of the state includes running the code on the Ethereum Virtual Machine (EVM), the backbone for computing states. It is important to note, that every node goes through that step of validating and verifying new blocks. As a state machine, the EVM computes the state of the blockchain after each transaction by applying changes in the fields of accounts involved in the transaction, which allows nodes to validate and verify all state transitions including the final one. This work then repeats with choosing new transactions from the transaction pool for the next candidate block. Since we only covered the EVM briefly, please check Ethereum Virtual Machine for more information, albeit this in-depth knowledge is not required to grasp the concepts of Ethereum.^[16]

Summary

This concludes our overview of Ethereum and its consensus algorithms. We explored the way state is stored in the network and how transactions are added and validated. The new Proof of Stake consensus algorithm makes Ethereum sustainable by reducing its energy consumption by 99.95% and relying on more affordable hardware.

For an overview of Blockchain, its security fundamentals and issues arising from the choice of its consesus algorithm, such as 51% attack and energy consumption, see the previous post Part 1. Blockchain.

The next post on Part 3. Smart Contracts will bring the notion of Ethereum's primary use case of the blockchain, which include contracts such as NFTs, Tokens, DeFi protocols and others.

References

The Merge on Ethereum, https://ethereum.org/en/upgrades/merge/.
Ethereum nodes and clients, https://ethereum.org/en/developers/docs/ nodes-and-clients.
Chapter 4. Cryptography — Elliptic Curve Cryptography Explained, https://www.oreilly.com/library/view/mastering-ethereum/9781491971932/ch04.html.
Ethereum Yellow Paper, https://ethereum.github.io/yellowpaper/paper.pdf.
Functionality of smart contracts, https://www.ibm.com/topics/smart-contracts.
The Keccak reference, https://keccak.team/files/Keccak-reference-3.0.pdf.
The Keccak SHA-3 submission, https://keccak.team/files/Keccak-submission-3.pdf.
Merkle Tree, https://soliditydeveloper.com/merkle-tree/.
Blogpost of Vitalik Buterin — Merkling in Ethereum, https://blog.ethereum.org/2015/11/15/merkling-in-ethereum.
NFT Metadata, https://www.weforum.org/agenda/2022/02/non-fungible-tokens-nfts-and-copyright/.
Reentrancy attack in a Solidity smart contract, https://cryptomarketpool.com/reentrancy-attack-in-a-solidity-smart-contract/.
ERC Token Standards - The Ultimate List, https://www.blockchain-council.org/ethereum/erc-token-standards/.
Why Does Bitcoin Use So Much Energy? https://www.forbes.com/advisor/ca/investing/cryptocurrency/bitcoins-energy-usage-explained/.
ERC-721 Non-Fungible Token Standard, https://ethereum.org/en/developers/docs/standards/tokens/erc-721/.
Ethereum block architecture, https://ethereum.stackexchange.com/questions/268/ethereum-block-architecture.
Ethereum Virtual Machine, https://ethereum.org/en/developers/docs/evm/.
Ethereum Wallets, https://ethereum.org/en/wallets/.
Cryptographic Hashes and Bitcoin, https://freecontent.manning.com/cryptographic-hashes-and-bitcoin/.
Private and public keys on Ethereum, https://www.massmux.com/private-and-public-keys-on-ethereum/.
What Is Sleepminting And Will It Ruin NFT Provenance? https://timdaub.github.io/2021/04/22/nft-sleepminting-beeple-provenance/.
Pentagon finds concerning vulnerabilities on blockchain, https://www.techrepublic.com/article/pentagon-finds-concerning-vulnerabilities-on-blockchain/.
A. M. Antonopoulos and G. Wood. Mastering Ethereum: Building Smart Contracts and DApps. O’Reilly Media, 2018.

Blockchain: from A to Z in 10 minutes for future Smart Contract Engineers

Yury Oparin — Sat, 31 Dec 2022 00:14:54 +0000

Smart contracts are automatized applications running on blockchain that unlike their traditional Web 2.0 counterparts guarantee immutability of state and hence enable secure execution of distributed transactions. This attracts their use in digital finance and specifically in applications where ownership of digital assets is transferred, for example, NFTs.

However numerous successful exploits and hacks of smart contracts show that just relying on blockchain security is not enough and additional measures are necessary. In this post we give a brief overview of the blockchain technology, explain the smart contracts workflow and discuss some of those hacks that happened to smart contracts and security issues with NFTs.

Part 1. Blockchain

See also Part 2. Ethereum on its architecture and two consensus algorithms, Proof of Work and Proof of Stake, which allow all nodes in the network to agree on a single state of the blockchain, and Part 3. Smart Contracts for a quick overview, risks, including reentrancy attack, and NFT use case with the objective to examine its storage options and associated risks.

Blockchain is a chain of blocks where each block references a prior block. Under the hood it uses various technologies including Peer-to-Peer Networks, consensus and hashing algorithms, as well as data structures such as Merkle trees and the chain of Blocks, which are discussed in the following sections.

1.1 Chain of Blocks

1.1.1 Blockchain — Structure

Blockchains run on computers, also called nodes, that are interconnected into a Peer-to-Peer Network (see Figure 1 and Section 1.2).

Figure 1: Peer to Peer Network of Nodes.

Each node tries to add a new block to the existing blockchain and announce that in the network, which yields rewards and sustains the blockchain. For Ethereum (discussed in Part 2. Ethereum), for example, these blocks consist of a Block Header, a list of Transactions and an Ommers List (see Figure 2).

Figure 2: Block structure.

The Transaction list contains transactions from a temporary memory pool, a waiting area for transactions, which a node includes into a candidate block to add to the blockchain if the node is deemed successful (see Figure 3).

Figure 3: Transactions added to a block.

Sometimes multiple new blocks are ready to be added to the chain at the same time of which only one will be primarily used for the Blockchain. These other blocks are known as the Ommers or Uncles and yield a partial reward for adding blocks to the blockchain. The next section discusses how a chain of blocks is formed.

1.1.2 Metadata of Blocks — Block Header

The Block Header is the most essential part of chaining blocks. It consists of a digital fingerprint computed by using a hash function that takes its contents and a hash of a previous block as input. This allows participants to validate the full chain and detect any tempered blocks.

Besides the hash value of a previous block the block header has multiple other data structures such as Merkle trees, namely the World State Trie, Account storage content trie, Transaction Trie and Transaction Receipts Trie, which will be discussed in the next posts on Part 2. Ethereum and Smart Contracts.

1.1.3 Encryption Mechanisms

At the core of blockchain security lies a crucial feature of cryptography and its encryption mechanisms. "Cryptography can, for example, also be used to prove knowledge of a secret without revealing that secret (e.g., with a digital signature), or to prove the authenticity of data (e.g., with digital fingerprints, also known as "hashes"). These types of cryptographic proofs are mathematical tools critical to the operation of the Ethereum platform (and, indeed, all Blockchain systems), and are also extensively used in Ethereum applications."^[22]

In blockchains, each Block is hashed with specific hashing algorithms. For Ethereum these encryption algorithms are Keccak-256 and the elliptic curve algorithm Secp256k1.^[7]^[3] Elliptic curves are used to derive digital signatures and ensure that a transaction is valid and the user initiating it owns the corresponding assets. Keccak-256 is a one-way hash function used as a digital fingerprint ensuring data authenticity and is also used in the consensus algorithm to guarantee high computational effort for brute force attacks.

A good example of using these hashing algorithms is depicted in Figure 4. It shows a public key and address generation from a private key using elliptic curves and Keccak-256 function.

Figure 4: Private Key, Public Key and Address Generation.^[19]

1.1.4 Keccak Algorithm

According to the Keccak Reference and Keccak-256 Submission,^[6]^[7] Keccak-256 is a hash function based on a sponge construction which takes any size of input and generates a chosen size of output. The key security property of hash functions is the collision and preimage resistance (see Figure 5) where two values mapping to the same hash cannot be found easily and neither can hash to a predefined output of the hash. This resistance in the case of Keccak-256 is achieved "By translating these computation complexities into physical quantities such as time or energy, both are simply out of reach and will remain so in the foreseeable future."^[7]

To bring the unlikeliness of a hash collision of either an address or even a private key into perspective, let us illustrate that likelihood by using a simple example. Currently 8 billion people live on Earth, which is approximately equivalent to 2³³ ≈ 8.59 * 10⁹. If all people generated one million addresses (160 bits each, see Figure 4) per day for 10,000 years, it would amount to approximately 2⁷⁵ ≈ 3.78 * 10²² addresses generated out of all possible addresses 2¹⁶⁰ ≈ 1.46 * 10⁴⁸ with different bit combinations. In fact it would take about 2**(160–33–28) = 2⁹⁹ ≈ 6.34 * 10²⁹ years to generate a collision of an address. As private keys have even more bits, the years necessary to find a collision are astronomically high.

Figure 5: Resistances when hashing.^[18]

1.1.5 Merkle Tree

A Merkle tree is another data structure that is used to further enforce secure encryption of data. It is made up of hashes of various data sections that summarize all the transactions in a given block. Each leaf node in the tree is labeled with the cryptographic hash of a data block, and each non-leaf node is labeled with the cryptographic hash of its child nodes' labels. Implementations of a Merkle tree are mostly binary, with each node having two child nodes. This enables a quick verification of data consistency and quality across large datasets.

Figure 6 illustrates how data verification happens that uses a Merkle tree. The verifyCalldata function checks whether a leaf belongs to the Merkle tree defined by a root hash stored in a smart contract. Another parameter is a proof which is a bytes32 array created off-chain.

Figure 6: Merkle Tree verification procedure.^[8]

Internally, this functions calls processProofCalldata function that iterates through each element in the proof array and computes recursively a resulting hash based on the proof elements and a hash computed on the previous iteration, starting from the leaf value. This hash is then compared to the root hash to see if they are equal.

In the next section, we will discuss the third technology that is necessary for blockchains to operate, peer-to-peer Networks.

1.2 Peer-to-Peer Networks

Blockchains are upheld, shared and expanded in a decentralized fashion through the use of a peer-to-peer network (see Figure 1). Nodes in the network refer to computers running instances of a given Blockchain client software and forming connections to other computers.^[2] They expand the blockchain by adding blocks to their local copy of the existing blockchain and sharing newly found blocks with others.

In addition to propagating transactions and blocks among the network, nodes validate data to achieve consensus and thus strive to maintain a single state of the blockchain. Interaction with this decentralized data structure from a user’s perspective happens via a node or a wallet.^[17] A wallet can send transactions to a node which then adds the transaction if verified to a temporary pool of transactions called the memory pool. This transaction gets propagated over the network enabling every node to include this transaction in the next block.

A fee for the transaction hereby indirectly orders the transactions, as nodes are more likely to include transaction into the, to be added, candidate block if the fees they receive are higher. Nodes add their own address to a block, as the first transaction in the block in the case of Bitcoin and as a beneficiary field in the Block Header for Ethereum, in order to collect rewards for adding a valid block to the blockchain.

Next we will look at how the consensus mechanism is realized in blockchain that enables all nodes to agree on its single state.

1.3 Mining: Consesus among the Network

Consensus algorithms exist in order to realize consensus among the network on a single state of the Blockchain. Each transaction gets approved before being added to the node memory pool, which involves adhering to the Blockchains rules and confirming the ownership of the currency for the transaction as well as getting validated by other nodes in the network after a given block has been broadcasted. This helps avoid erroneous blocks and adhere to a single state of truth. Additions of blocks to the Blockchain are thereby controlled by the consensus algorithm. Different algorithms exist, such as Proof of Work which entails adaptable complex calculations and Proof of Stake requires staking of currency.

Proof of Work (PoW) describes the consensus mechanism of providing work in the form of solving complex calculations. The block header of the candidate block gets hashed together with an iterative value called nonce (the number used once). The result of the hash needs to be below a specific target value chosen by the network and adapted relative to the computing power in the network (see Figure 7).

Figure 7: Finding a valid hash below the target value by adapting the nonce value.

If a fitting nonce value leading to a hash being below the given target was found, the block is deemed valid and can be added and shared among the network. It will then be executed, verified and added by each node. Afterwards, a new candidate block is brought about with new transactions and the process continues.

Nodes participating in the PoW mechanism are referred to as miners. As finding a nonce requires substantial computation resources, miners usually group together in mining pools to solve the mathematical problem. This increases their chances of success and distributes the reward among them.

1.4 Energy Consumption

When Satoshi Nakamoto created the first cryptocurrency in 2009, his goal was to establish a decentralized payment system that would facilitate quick and borderless transactions. Although not in the manner Nakamoto desired, Bitcoin has become mainstream more than ten years later. Cryptocurrencies now serve as speculative assets rather than transaction tools, attracting investors who think they may sell their holdings in the future with profit.

A consequence of that demand for Bitcoin is its high price that attracts mining companies to install more nodes in the network to get highly-valued rewards for mining new blocks. This results in a growing competition between the nodes and since Bitcoin uses Proof of Work consensus algorithm, which requires nodes to solve a difficult mathematical problem, ultimately that competition leads to a high electricity usage by the network. Figure 8 outlines how Bitcoin energy consumption changed from January 2017 to September 2022.

Figure 8: Bitcoin Energy Consumption.^[23]

The estimated yearly electricity usage of Bitcoin is 127 terawatt-hours (TWh). This is greater than Norway’s whole annual electricity use. In fact, Bitcoin needs more electricity than Ethereum (see Part 2. Ethereum), roughly 11 times as much (707 kilowatt-hours (kWh)) for every transaction, even though Ethereum runs 1.7 times as many transactions per second (TPS) as Bitcoin. Furthermore, as will be mentioned in the next post, Ethereum recently changed its consensus algorithm from Proof of Work to Proof of Stake, which reduced its energy consumption by 99.95%.^[1] If more blockchains adapted Proof of Stake, their energy consumption and the need for special hardware could be reduced significantly.

1.5 Decentralization Issues

Another issue is the size of specific Blockchains. Due to the structure of the Blockchain and the usage of peer-to-peer networks in order to uphold it and achieve consensus, computing power and users are essential. Without users the Blockchain could neither be sustained nor reasonably agreed upon a single state. As a result, majority attacks (51% attacks) could be performed much easier than on large Blockchains, such as Bitcoin or Ethereum, in which 51% computational power would be hard to achieve by any party. Currently, rewards and fees serve as an incentive for miners to produce new blocks. This however will not be always the case because some Blockchains will leave only fees as the sole incentive for miners, most likely reducing their number.

Furthermore, because miners form mining pools to have a higher chance of solving the mathematical problem to generate new blocks, the success of a majority attack can become possible. In some cases only two or four mining pools would have to combine in order to achieve >51% mining power, which could then alter the Blockchain, albeit limited, to their needs.^[21]

Summary

This concludes the first post about Blockchain, its security fundamentals and issues arising from the choice of its consesus algorithm to create a single chain of blocks that all the nodes in the Peer-to-Peer network agree on.

In the next post about Ethereum Blockchain we will consider the building blocks of Ethereum in detail and then return to discussing risks and issues.

References

The Merge on Ethereum, https://ethereum.org/en/upgrades/merge/.
Ethereum nodes and clients, https://ethereum.org/en/developers/docs/ nodes-and-clients.
Chapter 4. Cryptography — Elliptic Curve Cryptography Explained, https://www.oreilly.com/library/view/mastering-ethereum/9781491971932/ch04.html.
Ethereum Yellow Paper, https://ethereum.github.io/yellowpaper/paper.pdf.
Functionality of smart contracts, https://www.ibm.com/topics/smart-contracts.
The Keccak reference, https://keccak.team/files/Keccak-reference-3.0.pdf.
The Keccak SHA-3 submission, https://keccak.team/files/Keccak-submission-3.pdf.
Merkle Tree, https://soliditydeveloper.com/merkle-tree/.
Blogpost of Vitalik Buterin — Merkling in Ethereum, https://blog.ethereum.org/2015/11/15/merkling-in-ethereum.
NFT Metadata, https://www.weforum.org/agenda/2022/02/non-fungible-tokens-nfts-and-copyright/.
Reentrancy attack in a Solidity smart contract, https://cryptomarketpool.com/reentrancy-attack-in-a-solidity-smart-contract/.
ERC Token Standards - The Ultimate List, https://www.blockchain-council.org/ethereum/erc-token-standards/.
Why Does Bitcoin Use So Much Energy? https://www.forbes.com/advisor/ca/investing/cryptocurrency/bitcoins-energy-usage-explained/.
ERC-721 Non-Fungible Token Standard, https://ethereum.org/en/developers/docs/standards/tokens/erc-721/.
Ethereum block architecture, https://ethereum.stackexchange.com/questions/268/ethereum-block-architecture.
Ethereum Virtual Machine, https://ethereum.org/en/developers/docs/evm/.
Ethereum Wallets, https://ethereum.org/en/wallets/.
Cryptographic Hashes and Bitcoin, https://freecontent.manning.com/cryptographic-hashes-and-bitcoin/.
Private and public keys on Ethereum, https://www.massmux.com/private-and-public-keys-on-ethereum/.
What Is Sleepminting And Will It Ruin NFT Provenance? https://timdaub.github.io/2021/04/22/nft-sleepminting-beeple-provenance/.
Pentagon finds concerning vulnerabilities on blockchain, https://www.techrepublic.com/article/pentagon-finds-concerning-vulnerabilities-on-blockchain/.
A. M. Antonopoulos and G. Wood. Mastering Ethereum: Building Smart Contracts and DApps. O’Reilly Media, 2018.
Bitcoin Energy Consumption Index, https://digiconomist.net/bitcoin-energy-consumption.