CBSP Official Exam Study Guide v1.5

Certified Blockchain Security Professional (CBSP) Official Exam Study Guide
By: Howard Poston and Kris Bennett
Book is published by Blockchain Training Alliance, Inc.

Copyright © 2020
All rights reserved. No part of this book may be reproduced or utilized in any form by any means,
electronic or mechanical, including photocopying, scanning, recording, or by information storage or
retrieval systems, without express permission in writing from the author, with the exception of small
excerpts used in published reviews.
Limit of Liability / Disclaimer of Warranty / Terms of Use

While the publisher and author have used their best efforts in preparing this book, they make no
representations or warranties with respect to the accuracy or completeness of the contents of this book
and specifically disclaim any implied warranties of merchantability or fitness for a particular purpose.
There are no warranties which extend beyond the descriptions contained in this paragraph. No warranty
may be created or extended by sales representatives or written sales materials. The advice and strategies
contained herein may not apply or be suitable for your situation. You should consult with a professional
where appropriate. The accuracy and completeness of the information provided herein, and the opinions
stated herein are not guaranteed or warranted to produce any particular results, and the advice and
strategies contained herein are not suitable for every individual. By providing information or links to
other companies or websites, the publisher and the author do not guarantee, approve or endorse the
information or products available at any linked websites or mentioned companies, or persons, nor does a
link indicate any association with or endorsement by the publisher or author. This publication is designed
to provide information regarding the subject matter covered. It is offered or sold with the understanding
that neither the publisher nor the author is engaged in rendering legal, accounting, investment, or other
professional service. If legal advice or other expert assistance is required, the services of a competent
professional should be sought. This publication is no guarantee of passing this exam or other exam in the
future. Neither the publisher or the author shall be liable for any loss or loss of profit or any other
commercial damages, including but not limited to special, incidental, consequential, or other damages.
© Copyright 2020 | All Rights Reserved Blockchain Training Alliance, Inc. Page 1
Table of Contents
Chapter 1: Fundamental Blockchain Security ....................................................... 7
Cryptography for the Blockchain ........................................................................................................................... 7
Hash Functions ................................................................................................................................................... 7
Public Key Cryptography .................................................................................................................................... 7
Elliptic Curve Cryptography ................................................................................................................................ 8
A Brief Introduction to the Blockchain ................................................................................................................... 8
The Blocks .......................................................................................................................................................... 8
The Chains .......................................................................................................................................................... 8
The Network ....................................................................................................................................................... 8
Promises of the Blockchain ................................................................................................................................ 9
Blockchain Security Assumptions ........................................................................................................................... 9
Attacking Basic Blockchain Security ....................................................................................................................... 9
Chapter 1 Quiz...................................................................................................................................................... 10
Chapter 1 Quiz Answer Key .................................................................................................................................. 11
Chapter 2: Consensus in the Blockchain ............................................................. 12

Blockchain Consensus and the Byzantine Generals ............................................................................................. 12
Introduction to Blockchain Consensus Security ................................................................................................... 12
Proof of Work ................................................................................................................................................... 13
Solving BGP with PoW ...................................................................................................................................... 13
Security of PoW ................................................................................................................................................ 13
Attacking PoW .................................................................................................................................................. 13
Proof of Stake ................................................................................................................................................... 14
Solving BGP with PoS........................................................................................................................................ 14
Security of PoS.................................................................................................................................................. 14
Attacking PoS ................................................................................................................................................... 14
Other Blockchain Consensus Algorithms ............................................................................................................. 15
Chapter 2 Quiz...................................................................................................................................................... 16
Chapter 3: Advanced Blockchain Security Mchanisms ........................................ 18

Architectural Security Measures .......................................................................................................................... 18
Permissioned Blockchains ................................................................................................................................ 18
Checkpoints ...................................................................................................................................................... 18
Advanced Cryptographic Solutions ...................................................................................................................... 19
Multisignatures ................................................................................................................................................ 19
Zero-Knowledge Proofs .................................................................................................................................... 19
Stealth Addresses ................................................................................................................................................. 19
Ring Signatures ..................................................................................................................................................... 20
Confidential Transactions..................................................................................................................................... 20
Chapter 3 Quiz...................................................................................................................................................... 21
Chapter 4: Smart Contract Security .................................................................... 23

Introduction to Smart Contracts .......................................................................................................................... 23
Smart Contract Security Considerations .............................................................................................................. 23
Turing-Completeness ....................................................................................................................................... 23
Untrusted Code ................................................................................................................................................ 23
Smart Contract Lifetimes.................................................................................................................................. 24
External Interfaces ........................................................................................................................................... 24
Smart Contract Code Auditing ............................................................................................................................. 24
Auditing Smart Contracts ................................................................................................................................. 24
Chapter 4 Quiz...................................................................................................................................................... 26
Chapter 5: Blockchain Risk Assessment.............................................................. 28

Blockchain Risk Considerations ............................................................................................................................ 28
Decentralization ............................................................................................................................................... 28
Distributed Ledger............................................................................................................................................ 28
Distributed Infrastructure ................................................................................................................................ 29
Smart Contracts................................................................................................................................................ 29
Visibility ............................................................................................................................................................ 30
Regulatory Requirements .................................................................................................................................... 30
Blockchain Architectural Design........................................................................................................................... 30
Private vs. Public Blockchains........................................................................................................................... 31
Permissioned vs. Open Blockchains ................................................................................................................. 31
Chapter 5 Quiz...................................................................................................................................................... 32
Chapter 6: Basic Blockchain Security .................................................................. 34

User Security ........................................................................................................................................................ 34
Failure to Protect Private Keys ......................................................................................................................... 34
Vulnerability to Malware ................................................................................................................................. 34
Failure to Update ............................................................................................................................................. 34
Node Security ....................................................................................................................................................... 35
Shared Vulnerabilities ...................................................................................................................................... 35
Misconfigured Membership Service Providers ................................................................................................ 35
Insecure API Connections................................................................................................................................. 35
Network Security .................................................................................................................................................. 35
Flawed Network Design ................................................................................................................................... 35
Poor Network Security ..................................................................................................................................... 36
Chapter 6 Quiz...................................................................................................................................................... 37
Chapter 7: Blockchain for Business .................................................................... 39

Introduction to Ethereum Security ...................................................................................................................... 39
The Ethereum Distributed Ledger .................................................................................................................... 39
Ethereum Smart Contracts............................................................................................................................... 39
Ethereum Security Measures ........................................................................................................................... 40
Introduction to Hyperledger Security .................................................................................................................. 40
The Hyperledger Distributed Ledger ................................................................................................................ 40
Hyperledger Smart Contracts ........................................................................................................................... 40
Hyperledger Security Measures ....................................................................................................................... 41
Introduction to Corda Security............................................................................................................................. 41
The Corda Distributed Ledger .......................................................................................................................... 41
Smart Contracts in Corda ................................................................................................................................. 41
Corda Security Measures ................................................................................................................................. 42
Chapter 7 Quiz...................................................................................................................................................... 43
Chapter 8: Securely Implementing Business Blockchains ................................... 45

Business Operations ............................................................................................................................................. 45
Business Continuity/Disaster Recovery............................................................................................................ 45
Contract Management ..................................................................................................................................... 45
Product Distribution ......................................................................................................................................... 46
Product Monetization ...................................................................................................................................... 46
Data Management ............................................................................................................................................... 46
Access Control .................................................................................................................................................. 46
Data Retention and Deletion............................................................................................................................ 47
Infrastructure ....................................................................................................................................................... 47
Asset Management .......................................................................................................................................... 47
Infrastructure Scalability .................................................................................................................................. 47
Secure Communications................................................................................................................................... 48
Legal and Regulatory Compliance ........................................................................................................................ 48
Data Control ..................................................................................................................................................... 48
Data Security .................................................................................................................................................... 48
Transparency .................................................................................................................................................... 49
Chapter 8 Quiz...................................................................................................................................................... 50
Chapter 9: Network-Level Vulnerabilities and Attacks ....................................... 52

51% Attacks .......................................................................................................................................................... 52
Denial of Service Attacks ...................................................................................................................................... 52
Eclipse Attacks ...................................................................................................................................................... 53
Replay Attacks ...................................................................................................................................................... 53
Routing Attacks .................................................................................................................................................... 54
Sybil Attacks ......................................................................................................................................................... 54
Chapter 9 Quiz...................................................................................................................................................... 55
Chapter 10: System-Level Vulnerabilities and Attacks ........................................ 57

The Bitcoin Hack ................................................................................................................................................... 57
The Verge Hack .................................................................................................................................................... 57
The EOS Vulnerability ........................................................................................................................................... 58
The Lisk Vulnerability ........................................................................................................................................... 58
Chapter 10 Quiz.................................................................................................................................................... 59
Chapter 10 Quiz Answer Key ................................................................................................................................ 60
Chapter 11: Smart Contract Vulnerabilities and Attacks..................................... 61

Reentrancy ........................................................................................................................................................... 61
Access Control ...................................................................................................................................................... 61
Arithmetic............................................................................................................................................................. 62
Unchecked Return Value ...................................................................................................................................... 62
Denial of Service ................................................................................................................................................... 63
Bad Randomness .................................................................................................................................................. 63
Race Conditions.................................................................................................................................................... 64
Timestamp Dependence ...................................................................................................................................... 65
Short Addresses ................................................................................................................................................... 65
Chapter 11 Quiz.................................................................................................................................................... 67
Chapter 12: Security of Alternative DLT Architectures ....................................... 70

Introduction to Directed Acyclic Graphs (DAGs) ................................................................................................. 70
Transactions in a DAG ...................................................................................................................................... 70
Advantages and Disadvantages of DAGs.............................................................................................................. 70
Chapter 12 Quiz.................................................................................................................................................... 72
Chapter 1: Fundamental
Blockchain Security
Objective: Understand the basic principles and fundamental security assumptions of blockchain
technology.
Cryptography for the Blockchain

The blockchain relies on cryptographic algorithms to function. Some of the most important types of
cryptography used for blockchain security are hash functions, public key cryptography, and elliptic curve
cryptography (ECC).
In this section, we use the term computationally infeasible. This means that the best way to accomplish
something (like breaking a cryptographic algorithm) is by randomly guessing until a solution is found. If a
function has too many potential inputs to try them all on modern technology, it’s computationally
infeasible to break the algorithm by guessing.
Hash Functions
Hash functions are mathematical functions that can take any input and produce an output of a fixed size.
In cryptography, hash functions are typically used as a one-way function where it’s easy to go forward
(input to output) but computationally infeasible to go backward (output to input).
In order for this to work, a cryptographic hash function has a few essential properties:
1. Large State Space: For a hash function to be one-way, it needs to be computationally infeasible
to guess inputs to find one that creates the desired output. This means that the algorithm needs
to have a large number of possible outputs.
2. Collision Resistance: The fact that a hash function has an infinite number of potential inputs but a
finite number of possible outputs means that multiple inputs match to the same output. In a
good hash function, it should be computationally infeasible for someone to find two inputs that
hash to the same output.
3. Non-Locality: Similar inputs to a hash function should create dissimilar outputs. Otherwise, an
attacker could find a collision using a hill climbing approach (making small changes to an input
and see if the changes make the output closer to the desired output).
Public Key Cryptography

Public key cryptography (also called asymmetric cryptography) is a type of encryption algorithm which
uses a different public and private key. A user generates a pair of these keys (which are mathematically
related), keeps the private one secret, and publicizes the public one.
Public key cryptography algorithms are designed to make it computationally infeasible to derive a private
key from the corresponding public key. This is accomplished by making it necessary to solve
mathematically “hard” problems to do so. For example, the best way to factor the product of two prime
numbers is by guessing until you find one of the primes. Another “hard” problem is the discrete
logarithm problem, in which the attacker needs to find the value of the exponent given the base and the
result of the exponentiation. The factoring and discrete logarithm problems are commonly used in
cryptography since they can only be solved by guessing and using large enough numbers ensures that it
will take a very long time to break them by guessing.
Public key cryptography has two main applications:

1. Encryption/Decryption: Anyone with a person’s public key can use it to encrypt a message that
they can decrypt with their private key. They don’t ever need to meet or exchange a shared
secret key. This protects the confidentiality of the data.
2. Digital Signatures: Public key cryptography allows someone to use their private key to sign a copy
of a message. Anyone with a copy of their private key can use this signature to verify that the
private key was used to sign the message and that it wasn’t changed in transit. This protects the
message’s integrity and provides non-repudiation (the person can’t deny that they sent the
signed message).
The security of public key cryptography is completely dependent on the security of the private key.
Anyone with a private key can decrypt messages or generate legitimate digital signatures.
Elliptic Curve Cryptography

Elliptic curve cryptography is a type of public key cryptography. It uses a hard problem that is
mathematically equivalent to the discrete logarithm problem for security. Its main advantage is that it
has a similar level of security to traditional public key cryptography algorithms while using smaller keys.
A Brief Introduction to the Blockchain

Blockchain technology consists of several different components that work together. These components
include the blocks, chains, and the blockchain network. By combining these components, blockchain
technology is able to offer certain promises to its users.
The Blocks
The blocks are the place where data is stored in the blockchain. Users create transactions and send them
out to the rest of the blockchain network. Each transaction is digitally signed by its creator using their
secret key to prove that it is legitimate. At regular intervals, the current block creator organizes these
transactions into blocks and digitally signs the entire block with their own secret key and sends it out to
the rest of the blockchain network for addition to the distributed ledger.
The Chains
The links between blocks are where hash functions come into play in blockchain technology. Each block
in the blockchain includes the hash of the previous block. This ties the blocks together since the collision
resistance of the hash function will make it computationally infeasible for an attacker to generate a fake
version of a block that hashes to the value stored in the block after it.
The Network
The blockchain’s distributed ledger is designed to be stored in a decentralized fashion. Each node in the
network can store its own copy of the ledger and these copies are kept in sync via the blockchain’s
consensus algorithm. The nodes in the blockchain communicate via a peer-to-peer networking, meaning
that each node talks to a few other nodes and messages percolate across the network rather than going
through a central authority.
Promises of the Blockchain
Blockchain technology can bring numerous benefits to its users. Some of the most common promises of
blockchain technology include:
● Anonymity: Many blockchains do not require users to register their identity to use the blockchain
● Decentralization: Blockchain technology was designed to function without oversight by a central
authority
● Fault Tolerance: Blockchains are designed to keep functioning even if nodes fail. No nodes are
“mission-critical” and there are no single points of failure
● Immutability: The distributed ledger maintained by the blockchain is designed to make
modification or deletion of transactions difficult or impossible
● Transparency: The distributed ledger is publicly visible
● Trustless: The blockchain is designed so that users can trust the ledger without trusting anyone
else in the network
Blockchain Security Assumptions

Blockchains assume the security of the cryptographic algorithms used to build them. At a basic level, this
boils down to assuming the security of digital signatures and hash functions.
Digital signatures verify transactions’ and blocks’ integrity, authenticity, and non-repudiation. It should
be impossible to forge a digital signature.
Hash functions are used to chain blocks together in the blockchain. Hash functions should remain one-
way, non-local, and collision-resistant and have a state space large enough to defeat brute-force guessing
attacks.
Attacking Basic Blockchain Security

Theoretically, the cryptographic algorithms used in the blockchain are currently secure against attack. In
practice, the security of these algorithms is vulnerable to current and upcoming threats.
The security of public key cryptography is based on the security of the private key. If an attacker steals a
user’s private key, they can masquerade as that user on the blockchain decrypting messages and
generating valid digital signatures. Historically, blockchain users are bad at protecting their private keys.
Some solutions have been developed including:
● Hardware Wallets: A device that does all cryptographic operations on-device so that the key
never leaves the device
● Hardware Security Modules: Essentially a hardware wallet built into a computer
● Paper Wallets: writing the key down and storing it somewhere safe
Chapter 1 Quiz
1. Which of the following is not an essential feature of a cryptographic hash function?
a. Non-Locality
b. Large State Space
c. Randomness
d. One-Way
2. Which of the following are digitally signed on the blockchain? Choose all that apply.
a. Blocks
b. Proof of Work
c. Transactions
d. Public Keys
3. Including the hash of the previous block helps the blockchain achieve what?
a. Decentralization
b. Immutability
c. Distribution
d. Fault Tolerance
4. Digital signatures can provide which of the following? Select all that apply.
a. Integrity
b. Confidentiality
c. Anonymity
d. Authentication
5. What is the communications model for the blockchain network?
a. Spoke and Wheel
b. Client-Server
c. Fully Connected
d. Peer-to-Peer
6. What is the best way to find a hash input from the corresponding output?
a. Brute Force
b. Reverse Engineering
c. Inverse Hash Function
d. Decryption
7. Which of the following is used to prevent an attacker from modifying a transaction after it is
generated?
a. Hash Functions
b. Public Key Cryptography
c. Proof of Work
d. Proof of Stake
8. Which of the following is a mathematically “hard” problem?
a. Multiplication
b. Exponentiation
c. Factoring
d. Modulus
9. It is ______ to break public key cryptography by brute force guessing.
a. Easy
b. Hard
c. Infeasible
d. Impossible
10. What is the easiest way to compromise a blockchain account?
a. Quantum Computing
b. Private Key Theft
c. Brute Force Guessing
d. Algorithm Reverse Engineering
Chapter 1 Quiz Answer Key

1. C
2. A,C
3. B
4. A,D
5. D
6. A
7. B
8. C
9. C
10. B
Chapter 2: Consensus in the
Blockchain
Objective: Understand the common blockchain consensus algorithms, their security assumptions, and
consensus-based attacks.
Blockchain Consensus and the Byzantine Generals

The Byzantine Generals problem is a puzzle in computer science dealing with the issues of reaching
agreement between multiple parties when neither the parties nor the communications links can be
trusted.
In the Byzantine Generals problem, a set of generals laying siege to a city is trying to decide whether or
not to attack the city or retreat. If only some of the armies attack, they are guaranteed to be defeated.
The generals can only communicate by messengers (who could be intercepted) and some of the generals
could be traitors.
The Byzantine Generals problem is applicable to the blockchain because the nodes in the blockchain
need to agree on the information that should be included in the official version of the distributed ledger.
The nodes have to organically come to a consensus via messaging in an efficient manner and must deal
with the possibility that some nodes may be willing to sabotage the consensus if it is in their own best
interests.
A system is called Byzantine Fault Tolerant if it solves the Byzantine Generals problem. The problem has
been demonstrated to be solvable if at least two-thirds of the nodes in the network are honest.
Blockchain consensus algorithms are designed to let the network agree on the state of the shared ledger
while remaining Byzantine Fault Tolerant.
Introduction to Blockchain Consensus Security

Prior to the invention of the blockchain, algorithms that solved the Byzantine Generals problem existed
but they were very inefficient. One of the major breakthroughs of blockchain technology was the
creation of a probabilistic solution to the Byzantine Generals problem. This algorithm, called Proof of
Work, and another one called Proof of Stake are the two main consensus algorithms used in the
blockchain (though several others exist as well).
In blockchain technology, there is often a reward for being chosen to create the next block on the
blockchain. Proof of Stake (and the other consensus algorithms derived from it) use ownership of a
scarce asset to manage users’ control over the blockchain: the more of the asset that you controlled, the
more power over the blockchain that you have. This uses economic incentives to make it very difficult to
control the blockchain. In this section, we’ll talk about Proof of Work and Proof of Stake, how they
implement this scarcity-based solution to the Byzantine Generals Problem, and their security
assumptions and related attacks.
Proof of Work
Proof of Work is the original blockchain consensus algorithm. In Proof of Work, nodes race to find the
solution to a computational puzzle that can only be solved by random guessing. This process (called
mining) typically requires the miners finding a version of the block that, when hashed, produces a set
number of leading zeros. The number of leading zeros is referred to as the difficulty and allows the
consensus algorithm to maintain a set block rate and level of difficulty despite changes in the
computational power of the blockchain network. Blockchain miners have the ability to change one value
in the block’s header but, due to the properties of hash functions, cannot determine which value will
produce the desired output except by random guessing.
Solving BGP with PoW

Proof of Work provides a probabilistic solution to the Byzantine Generals Problem. The difficulty target
of the consensus algorithm is set so that the entire network needs to work on the problem in order to
find a solution in time with reasonable probability. While it is possible that the blockchain could maintain
two divergent versions of the ledger for some times by getting lucky and finding solutions without
making the expected number of guesses, this probability decreases with each new block. Eventually, this
probability becomes so low that it is impossible to believe that a certain version of the ledger is not
supported by the majority of the blockchain network.
Security of PoW
The security of Proof of Work centers around the security of its cryptographic “puzzle”. If the mining
puzzle can be solved by any means other than random guessing, the security of the algorithm is broken.
Since the puzzle is typically implemented as a hash function, this means that the hash function remains
one-way and non-local.
Attacking PoW
The Proof of Work algorithm is not immune to attack. Several different attacks exist that could degrade
or break the security of the blockchain.
The 51% Attack addresses the case where an attacker controls the majority of the computational power
in the blockchain. If this is the case, the attacker has the ability to create a divergent blockchain that will
accumulate more Proof of Work than the chain supported by the rest of the network. Since nodes are
configured to switch over to whatever version of the blockchain has the most Proof of Work, this gives
the attacker complete control of the distributed ledger. This enables double-spend attacks where the
attacker posts one version of a transaction on the blockchain, waits for it to be trusted by its recipient,
and then makes a different version of the blockchain (containing a conflicting version of this transaction)
the version accepted by the network as a whole.
A Selfish Mining attack helps an attacker accomplish a 51% attack with less than 51% of the blockchain’s
resources. In an ideal world, users would immediately publish the next block once they found a solution
to the Proof of Work puzzle. However, a selfish miner will hide their solution for a while and immediately
begin mining the next block on top of the one that they found. Since other miners can’t begin mining
until a solution is revealed, this gives them a head start on the race to find a Proof of Work solution for
the next block. The main risk of this type of attack is that a competing solution will be found and
accepted while the miner is still hiding theirs, so it’s a tradeoff between the advantage gained on the
next block and the risk of losing the reward of the current block.
Finally, a Proof of Work blockchain can be attacked using physical attacks. The Proof of Work algorithm
uses a huge amount of power to perform its calculations. If an attacker can cut the power or remove a
miner’s access to the Internet, they increase their chances of performing a 51% attack, especially if the
miner(s) represent a large percentage of the network’s computational power.
Proof of Stake
Proof of Stake takes a different approach to solving the Byzantine Generals Problem, using the
blockchain’s cryptocurrency as the scarce resource instead of computational resources. In Proof of
Stake, a user can promise not to spend or stake some of their cryptocurrency. In exchange, they get a
chance to participate in the blockchain’s consensus process.
In Proof of Stake, nodes are pseudo-randomly selected to be the creator of the next block based on the
size of their stake. The probability may be based solely on size of stake (sometimes capped at a
maximum probability) or take the time since the user was last selected into account. A pseudo-random
selection process is necessary since every node in the network must be able to independently calculate
the correct node to create the next block (since no centralized authority declares this) but can’t predict
block creators in advance (or else they could manipulate the process to their advantage). In general, the
hash of the previous block is used as an input to the algorithm to ensure pseudo-randomness.
Solving BGP with PoS

In Proof of Stake, the creators of each block are randomly selected and they sign a block that they’ve
added to the end of an existing blockchain. By doing so, they state that they agree with the state of the
distributed ledger as described by that blockchain.
Over time, every node with a stake in the network should have been randomly selected to create a new
block and endorse the state of the distributed ledger. They can only endorse the blocks created to that
point but they also endorse the current system and selection process, meaning that they agree with how
future block creators are selected. As long as the appropriate node creates each block, they agree that it
is a valid part of the distributed ledger.
Security of PoS
The security of Proof of Stake is based on two assumptions: the security of the process to select block
creators and the security of digital signatures. The block creator process must be pseudo-random and
based off of a one-way function, otherwise attackers could create accounts and stake coins to win the
right to create each block in the chain. The security of digital signatures is also important since a digital
signature certifies that a block is created by the correct node.
Attacking PoS
Like the Proof of Work consensus algorithm, Proof of Stake is vulnerable to a few different attacks.
In Proof of Work, an attacker can control the blockchain if they control 51% of the network’s
computational resources. In Proof of Stake, the percentage isn’t as set but the principle is the same. If
an attacker controls enough of the network’s staked currency, they are more likely to be selected as the
legitimate creator of each block. If this percentage is high enough, the attacker could theoretically
control the blockchain.
A long-range attack is one in which the attacker creates a new version of the blockchain right back to the
genesis block. The goal of the attacker is to make it appear that their version of the blockchain has been
approved by more accounts than the main chain. This is accomplished by slowing the growth of the main
chain (by passing on their opportunities to create a block) and growing their chain as quickly as possible
(by only having blocks created on their turns and staking all of their block rewards to increase the rate at
which they are selected to create blocks). If the attacker’s chain grows longer than the main chain, they
can publicize it and, if they are following the blockchain protocol, the rest of the network will accept it as
truth.
If an attacker has the majority of the stake in a blockchain and is patient, they can take advantage of the
Proof of Stake “timebomb”. Block rewards in Proof of Stake are awarded based on the percentage of
staked rewards. If the person with the most cryptocurrency invests all of their rewards in stakes, their
percentage of the stake will grow steadily, eventually giving them control of the distributed ledger.
Other Blockchain Consensus Algorithms

While Proof of Work and Proof of Stake are the dominant blockchain consensus ones, they are not the
only ones in existence. Several different algorithms have been proposed, including the following:
● Delegated Proof of Stake: Nodes use their stake to vote for witnesses and delegates who create
blocks and maintain the blockchain.
● Proof of Activity: Hybrid Proof of Work and Proof of Stake. The result of Proof of Work is used to
select a group of delegates who sign the block. If the entire group doesn’t sign, the process
repeats.
● Proof of Burn: Users destroy cryptocurrency for the future right to say that they’ve destroyed at
least the minimum amount required to create a block and earn its reward.
● Proof of Space: Users allocate a certain amount of storage to a lookup table of challenges and
responses. If a user has the response for a challenge, they get to create the next block.
Chapter 2 Quiz
1. What is the original blockchain consensus algorithm?
a. Proof of Work
b. Proof of Stake
c. Proof of Activity
d. Proof of Space
2. What scarce resource does Proof of Work use to protect the blockchain's security?
a. Cryptocurrency
b. Computational Resources
c. User Transactions
d. Storage Space
3. What scarce resource does Proof of Stake use to protect the blockchain's security?
a. Cryptocurrency
b. Computational Resources
c. User Transactions
d. Storage Space
4. A 51% Attack is designed to target which consensus algorithm?
a. Proof of Activity
b. Proof of Space
c. Proof of Stake
d. Proof of Work
5. In what attack does a miner deliberately conceal a Proof of Work solution for a while to gain an
advantage?
a. 51% Attack
b. Double-Spend Attack
c. Long-Range Attack
d. Selfish Mining
6. In what attack does an attacker create a new copy of the blockchain all the way back to the
genesis block?
a. 51% Attack
b. Double-Spend Attack
c. Long-Range Attack
d. Selfish Mining
7. Which of the following contributes to the Proof of Stake timebomb?
a. “Rich get richer” reward scheme
b. Use of outdated cryptography
c. Inability to scale to meet needs
d. Limited number of potential users
8. Which consensus scheme is a hybrid of Proof of Work and Proof of Stake?
a. Delegated Proof of Stake
b. Proof of Activity
c. Proof of Burn
d. Proof of Space
9. If a Proof of Work blockchain diverges, how is the tie broken?
a. Chain with oldest timestamp wins
b. Chain with most blocks wins
c. Chain with most “work” wins
d. Chain with largest adoption wins
10. In a Proof of Stake blockchain, how is the next block creator selected?
a. By majority vote of the blockchain network
b. Using a random process
c. Based on the previous block
d. By a centralized server

1. A
2. B
3. A
4. D
5. D
6. B
7. A
8. B
9. C
10. C
Chapter 3: Advanced
Blockchain Security
Mechanisms
Objective: Understand architectural and cryptographic solutions for increasing the privacy and security
of the blockchain.
Architectural Security Measures

Blockchains are not all designed and implemented identically. Certain design decisions can improve the
resiliency of the blockchain against certain attacks.
Permissioned Blockchains
The original blockchains were designed to have no access control. The blockchain was completely
decentralized and open: anyone could become a user of the blockchain and all of the users had the same
level of power on the blockchain.
Permissioned blockchains have built-in access control mechanisms. A permissioned blockchain will have
one or more Membership Services Provider (MSP) nodes that handle authentication, authorization, and
identity on the blockchain. This allows blockchain developers and users to provide access to data and
functionality on the blockchain on a case-by-case basis.
The security of a permissioned blockchain is based on the security of the blockchain’s MSP. Since these
nodes have full control over who can access the blockchains and the actions they can take, a compromise
of the MSPs nodes can jeopardize the blockchain’s security. MSPs can also be the target of a Denial of
Service (DoS) attack on the blockchain since users cannot access or take action on the blockchain without
them.
Checkpoints
In an ideal world, a blockchain network will reach consensus on the contents of every block. In practice,
divergent blockchains can occur for both benign and malicious reasons. The blockchain protocol is
designed to accept the blockchain with the most “work” supporting it.
This protocol can be taken advantage by an attacker who deliberately creates a divergent blockchain and
builds it up to have more work than the true blockchain (like in a 51% attack). Checkpointing is designed
to defeat this type of attack by having nodes periodically store a block on the accepted chain and refuse
to accept any divergent chain that does not include this block.
The main issue with checkpointing is that it either requires centralization or risks splitting the network. If
nodes create their own checkpoints, it’s possible that they will choose blocks on divergent blockchains
and refuse to switch over, splitting the network. If a single node or a group working together is
responsible for creating and sending out checkpoints, the network has become centralized.
Advanced Cryptographic Solutions
The blockchain is built using cryptographic algorithms for security and privacy. Over time, additional
cryptography-based solutions have been proposed to increase the privacy and/or security of the
blockchain.
Multisignatures
Blockchains use digital signatures to ensure the authenticity and integrity of transactions; however, a
digital signature can only authenticate one person. If a transaction needs multiple verifiers, each would
have to add their own signature, which could become very bulky. A multisignature is a digital signature
that requires multiple private keys to generate a valid digital signature, allowing multiple parties to
approve a transaction.
Multisignatures are implemented using Shamir Secret Sharing (SSS), which is based off of the principle
that you need a certain number of points to define a line of a given degree (i.e. two for a straight line,
three for a parabola, etc.). SSS encodes the shared secret key as the y-intercept of a curve of degree K
and provides (secret) points on the curve to each potential signer. If K different signers generate their
own partial signature using their secret point and combine them, it produces a valid digital signature for
the group. The number of signers, K, can be any number and can be a subset of the group (K of N).
Zero-Knowledge Proofs
A zero-knowledge proof (ZKP) is designed for the situation where you know a secret and want to prove
that you know it to someone without giving it away. This can be very useful on the blockchain where the
distributed ledger is publicly visible since a user can prove membership in a group by posting a ZKP of the
group’s secret on the blockchain which confirms that they know it without giving it away.
An example zero-knowledge proof to prove that red and green are different colors to a red-green
colorblind person goes as follows:
1. Find two objects that are completely identical other than color (red and green)
2. The colorblind person takes the objects and hides them from the view of the prover
3. The colorblind person shows one of the objects to the prover and then conceals it again
4. The colorblind person shows one of the objects to the prover
5. The prover tells the colorblind person whether or not they are the same object
The goal of this proof is to demonstrate that red and green are different colors without revealing which
object is red and which is green. If the objects are identical other than color, the only way that the
prover can consistently answer correctly is if red and green are different. While they have a 50/50
chance of guessing correctly running the test once, the probability of always guessing correctly decreases
quickly if the test is repeated multiple times.
Stealth Addresses
Stealth addresses are a special type of address on the blockchain designed to conceal the recipient of a
transaction. The transaction recipient publicly posts a special type of public address for users to use
when generating transactions to them. A transaction sender uses this address to compute a unique, one-
time address and a bit of information called a tag. The sender can then post a transaction to this one-
time or stealth address that includes the tag. Using the information from the address and the tag, the
recipient can identify if a transaction posted to the blockchain was intended for them and update their
account accordingly.
Ring Signatures
Ring signatures are designed to conceal the sender of a transaction by generating a valid digital signature
that can be verified as coming from one of a set of public keys included with the transaction. To do this,
the sender selects a set of decoy public keys and crafts a digital signature that could only be created if
the signer knew at least one of the private keys belonging to the group but that doesn’t reveal which
public key it is.
The security of the decoy signature is based on the security of public key cryptography. The ring
signature equations are designed so that solving them either involves solving the public key cryptography
algorithm’s “hard” problem (which should be impossible) or substituting the equation to calculate a
public key from a private key in for the public key itself.
Confidential Transactions
Confidential Transactions are designed to allow a transaction to be verified as legitimate without
revealing the value of the transaction. This is accomplished by proving that the transaction value is
within some set of values, all of which could have been a valid transaction (i.e. less than the amount in
the user’s account).
Confidential Transactions take advantage of several different cryptographic operations:

● Homomorphic Encryption: Allows arithmetic operations to be performed on encrypted data
○ Additive Homomorphism: The sum of ciphertexts is the encryption of the sum of the
plaintexts
○ Multiplicative Homomorphism: The product of ciphertexts is the encryption of the
product of the plaintexts (RSA is multiplicative homomorphic)
● Elliptic Curve Cryptography (ECC): A form of public key cryptography that uses points on elliptic
curve as public keys
○ Is additively homomorphic
● Pederson Commitments: Commits to the value of something without revealing the value
○ A hash function is a simple type of commitment
○ Are additively homomorphic and can be implemented using ECC
■ C = xG+aH (x is private key, a is committed value, G and H are ECC generators)
● Ring signatures: Generate a signature that proves knowledge of the private key that corresponds
to one of a group of public keys
Confidential Transactions combine these principles to prove that a transaction is value without revealing
the value of the transaction itself. This is accomplished by creating a set of transactions and proving that
the input and output amounts are equal without revealing the distribution over the different
transactions.
Chapter 3 Quiz
1. A Membership Services Provider contributes to what in the blockchain?
a. Access Control
b. Consensus
c. Block Creation
d. Ledger Storage
2. Checkpointing is designed to protect against what type of attack?
a. Double-Spend Attack
b. Selfish Mining Attack
c. 51% Attack
d. Denial of Service Attack
3. Shamir Secret Sharing is a critical component of which of the following?
a. Zero-Knowledge Proofs
b. Multisignatures
c. Ring Signatures
d. Confidential Transactions
4. Which of the following allows a user to prove membership in a group without revealing the
group’s secret?
a. Ring Signatures
b. Multisignatures
c. Zero-Knowledge Proofs
d. Pederson Commitments
5. Which of the following conceals the identity of a transaction creator among a set of possibilities?
a. Ring Signature
b. Zero-Knowledge Proof
c. Multisignature
d. Confidential Transaction
6. Which of the following is designed to protect the privacy of the recipient of a transaction?
a. Ring Signature
b. Pederson Commitment
c. Confidential Transaction
d. Stealth Address
7. Which property of Elliptic Curve Cryptography is useful for Pederson Commitments?
a. Subtractive Homomorphism
b. Divisive Homomorphism
c. Additive Homomorphism
d. Multiplicative Homomorphism
8. A hash function can be used in a simpler version of what?
a. Ring Signature
b. Pederson Commitment
d. Stealth Address
9. In which of the following does someone collect a set of public keys to use as decoys?
a. Multisignatures
b. Ring Signature
d. Stealth Address
10. In which of the following does a transaction recipient use tag information to determine if a
transaction on the blockchain is intended for them?
a. Ring Signatures
b. Confidential Transactions
c. Stealth Addresses
d. Pederson Commitments

1. A
2. C
3. B
4. C
5. A
6. D
7. C
8. B
9. B
10. C
Chapter 4: Smart Contract
Security
Objective: Understand the basics of smart contract operation, major security considerations, and smart
contract auditing strategies.
Introduction to Smart Contracts

Smart contracts are programs that run “on the blockchain”. They allow the creation of completely
distributed and decentralized applications and are designed to be self-enforcing. The code of a smart
contract is designed to be the final authority on the agreement that it encodes, meaning that any
contractually valid interaction is considered “fair use” including exploiting a logical or programming flaw
in the contract. Since smart contracts can store and manipulate value and sensitive data on the
blockchain, they are attractive targets to attackers and security is of paramount importance.
Smart contract platforms (sometimes called “world computers”) are designed to have blocks whose
transactions consist of instructions to execute. Each node in the blockchain network runs a copy of the
blockchain’s virtual machine and executes the code contained in transactions. This creates a parallelized
but hugely inefficient distributed computer since the parallelization is used to maintain synchronization
(each node runs the same code in the same order) rather than speed processing.
Smart contracts are designed to be just like a standard computer programming. They can run commands
(encoded in transactions), access memory (the distributed ledger), interact with users (by calling or being
called by accounts), and interact with other programs (running other smart contracts). Smart contract
platforms are designed to be Turing-complete, meaning that anything that is possible for a program on a
computer should be possible in a smart contract.
Smart Contract Security Considerations

Smart contracts are designed to be fully-functional programs that run on the blockchain. This creates a
few security considerations that should be taken into account when designing a blockchain solution.
Turing-Completeness
Smart contracts are designed to be Turing-complete, meaning they have the same capabilities as a
standard computer program. This power makes them very useful but also potentially dangerous. Smart
contracts are designed to manipulate sensitive or valuable data in a public, immutable ledger. This
makes them attractive targets and the “code as law” arbitration means that attacks arising from
programming errors are unlikely to be reversed. Developers should be extremely cautious when creating
smart contracts to store sensitive or valuable data.
Untrusted Code
The purpose of smart contracts is to allow developers to create and run code on the blockchain. These
developers are not necessarily trusted and may be malicious. The design of the blockchain means that
every node in the blockchain network will be regularly running untrusted code on their computers.
Smart contracts are permitted to interact with other smart contracts, meaning that smart contract
developers are essentially developing for a “computer” where the “user” runs any program that they
come across, including malware. Any smart contract vulnerabilities can and likely will be exploited if
doing so would benefit a malicious user.
Smart contracts run within a sandboxed virtual machine in the blockchain software. While this should
protect a user’s computer, virtual machine escapes can and do occur. It is best to treat blockchain
software as untrusted since it regularly will run untrusted (and potentially malicious) code.
Smart Contract Lifetimes

Most programs have an “end of life” when they become obsolete and are retired or are updated. Smart
contracts are part of the immutable blockchain and, as such, are permanent. While a developer can
build in a “kill switch” or update mechanism to a smart contract, the code is there forever. If an attacker
finds a way to bypass these mechanisms, they may be able to exploit and do damage even with a
dormant smart contract.
External Interfaces
One of the major uses of smart contracts is to allow external components to interact with the blockchain.
While this greatly increases the capabilities of the blockchain, it also means that these external
components are within the blockchain’s security perimeter and part of its threat surface. Vulnerable
external components can potentially compromise the smart contracts that they connect to and vice
versa.
Smart Contract Code Auditing

The value and potential of smart contracts means that securing them is important; however, it is a
difficult problem. The relative youth of the technology means that it has been unable to build up the
same level of expertise and security research as traditional cybersecurity. The novelty and potential of
the technology have inspired a large following and security research has identified and corrected several
issues but there are certainly more to come.
One of the major issues with securing smart contracts is the fact that the technology is so new. Some
smart contract platforms, like Ethereum, have created their own programming languages (Solidity) for
smart contract development. This means that smart contract developers are often programming in a
language with which they have limited familiarity and understanding of how it works “under the hood”.
While the number of Solidity developers and experts are increasing, it is still far behind traditional
programming languages.
Auditing Smart Contracts

Security auditing is an essential part of smart contract development. Their value and threat exposure
make them an attractive target for attackers. However, the lack of expertise in this field makes finding
an expert difficult or expensive.
There are several different strategies for smart contract audits. It’s best to perform as many as possible
to minimize vulnerabilities. Several potential tests and useful tools (for Ethereum) include:
● Expert Code Analysis: Have a smart contract expert perform a review
● Control Flow Analysis: Generate a graph of the program’s control flow and look for anomalies
○ Check out Mythril and Solgraph if doing this for Ethereum
● Dynamic Code Analysis: Run the program to see how code works and look for anomalies
○ Manticore has this functionality
● Manual Code Analysis: Line-by-line review of the smart contract code for logical or programming
languages
○ Probably a good idea to have this performed by a “fresh set of eyes”
● Vulnerability-Based Scanning: Scan the code for known smart contract vulnerabilities
○ Oyente implements vulnerability scanning
● Symbolic Execution: Determine the inputs that cause certain parts of the code to execute
○ Mythril does this as well
● Taint Analysis: Check what variables within the smart contract are controllable by the person or
smart contracting executing it
○ Mythril does this as well
● Test Coverage: Ensure that unit tests cover all of the smart contract’s code
○ solidity -coverage
● Linting: Ensure that the contract meets style requirements and has no grammatical errors
○ Solium, Solcheck, Solint\
Chapter 4 Quiz
1. Why is the Turing-completeness of smart contracts a potential security concern?
a. It means that they cannot be run within a sandbox
b. It means that they cannot be deleted from the ledger
c. It means that they are fully functional programs
d. It means that they may consume computational resources
2. Smart contract code is only visible on the blockchain after it has been executed.
a. True
b. False
3. Which of the following does not contribute to the difficulty of performing smart contract security
audits?
a. Limited number of blockchain security experts
b. Limited access to smart contract code examples
c. Limited security research into blockchain technology
d. Limited time since invention of blockchain for bugs to be worked out
4. Which of the following analysis methodologies is a quick way to catch common smart contracting
coding flaws?
a. Taint Analysis
b. Manual Code Analysis
c. Vulnerability Scanning
d. Dynamic Code Analysis
5. Which of the following methodologies helps the Quality Assurance tester ensure that they have
performed basic due diligence?
a. Test Coverage Analysis
b. Symbolic Execution
c. Taint Analysis
d. Control Flow Analysis
6. Which of the following can help detect logical errors in a smart contract? Select all that apply.
a. Control Flow Analysis
d. Taint Analysis
7. Which of the following is not primarily designed to detect errors in a smart contract?
a. Control Flow Analysis
b. Linting
c. Taint Analysis
d. Symbolic Execution
8. What may make development for the Ethereum blockchain more difficult than traditional
programming? Select all that apply
a. New programming language
b. Lack of sample code
c. Lack of understanding of internals
d. Limited available functionality
9. Which of the following is not essential to performing a complete security assessment of a smart
contract?
a. Linting
d. Taint Analysis
10. Smart contract platforms are designed so that smart contracts cannot reach out to external
components and vice versa.
a. True
b. False

1. C
2. B
3. B
4. C
5. A
6. A,B,D
7. B
8. A,C
9. A
10. B
Chapter 5: Blockchain Risk
Assessment
Objectives: Consider the possible effects that a blockchain solution can have on organizational risk and
regulatory compliance. Learn about the comparative advantages of different blockchain architectures.
Blockchain Risk Considerations

Blockchain technology has several built-in advantages for both individuals and businesses. However, the
unique architecture of the blockchain requires a different mindset than that required for traditional
cybersecurity. In this section, we’ll discuss some of the major features of the blockchain and some of the
security considerations they create.
Decentralization
Decentralization is one of the major advantages of the blockchain. By removing single points of failure,
the blockchain can dramatically increase the resiliency of a company’s infrastructure. However, the
differences between the decentralized blockchain and traditional, centralized systems requires a
different approach to design and security.
The main security consideration of a decentralized blockchain is the decreased control that an
organization has over the blockchain. In a centralized system, the organization has the ability to monitor
information being added to the ledger, to physically protect systems, and to take down the system if
needed. In a decentralized environment, this ability is reduced or eliminated, requiring an organization
to take more care with what they add to the blockchain.
The other major risk consideration of decentralization is an increased reliance of the organization on its
infrastructure. Blockchain networks require good communications for consensus and to add data to the
blockchain. If a network’s infrastructure is damaged, the blockchain may become non-function, less
secure, or divergent.
Distributed Ledger
Traditionally, organizations kept their own, internal ledgers and the trust in the ledger was based on the
trust in the organization itself. People trust major online retailers to send them products if they send
money but aren’t willing to shop on “sketchy” sites even if it’s a better deal. Blockchain’s distributed
ledger transfers the burden of trust from an organization to cryptographic algorithms.
The distributed ledger creates several risks that should be considered and managed when implementing
blockchain technology. The first is the decreased control of potentially sensitive data on the blockchain.
Data posted to the blockchain is stored on many different nodes. This also increases the potential attack
surface of the blockchain since an attacker could gain a access and a level of control of a private
blockchain by compromising any of the nodes on the system rather than the centralized “master” node
(like in a traditional database).
Implementing blockchain technology also increases overhead for an organization. The duplication of the
same ledger over multiple nodes means that data is being stored very inefficiently.
Finally, an organization can never be completely certain of the finalization of a transaction on a public
blockchain. The rules of the blockchain state that the longer chain is the official one if two divergent
blockchains exist. Therefore, an attacker can theoretically replace the current copy of blockchain at any
time if they manage to break consensus and generate a “longer” chain.
Distributed Infrastructure
Blockchains are based off of distributed networks of nodes communicating peer-to-peer. This creates a
distributed infrastructure that is extremely resilient. However, operating in a distributed environment
has associated risks and security considerations.
The main risk of a distributed infrastructure is a decreased level of oversight. An organization may not be
able to manage node security or even own all of the nodes that are involved in their blockchain network.
This requires a level of trust that all members of the network properly protect their own systems.
The distributed nature of the blockchain network also creates reliance on the underlying infrastructure.
The blockchain’s nodes need to be able to communicate in order to complete consensus and maintain
the blockchain.
Smart Contracts
Smart contract technology allows organizations to run programs on the blockchain, creating most of its
appeal for business use cases. However, smart contract technology also has associated risks and security
considerations.
Smart contracts are considered the final authority on their “acceptable use”. Any contractually valid
interaction (including exploiting a logical or programming vulnerability) is considered “fair use”. Since
smart contracts are stored on the blockchain, an attacker may be able to execute and exploit it. The
ability of smart contracts to manipulate sensitive and valuable data (potentially including cryptocurrency)
can make them very tempting targets for an attacker.
The blockchain is designed to be publicly visible and immutable. Smart contract code is stored on the
blockchain, making it visible to malicious users. This means that intellectual property may be reverse-
engineered from a smart contract’s code and that attackers can analyze the code for exploitable
vulnerabilities. The immutability of the blockchain means that a poorly-designed smart contract cannot
be easily disabled or removed from the distributed ledger.
A final major security consideration of smart contracts is the relative newness of the technology. Few
expert developers and security researchers exist, meaning that a lot of smart contracts are being
designed and posted by relative amateurs. This increases the threat surface of the blockchain network as
smart contracts are essentially untrusted code that nodes run on their own computers. While
blockchains are sandboxed, design or coding errors may allow malicious smart contract to escape a
sandboxed environment.
Visibility
Most blockchain are designed to have a distributed ledger that is visible to all of its users. This allows the
network to be decentralized and trustless as all nodes have the ability to independently validate the
transactions stored in the distributed ledger.
The visibility and immutability of the distributed ledger mean that organizations must be careful with the
data posted to the ledger since it cannot be removed if a mistake is made. Most blockchains make the
source and destination of transactions publicly visible to aid in validation, meaning that data mining of
the blockchain can provide useful intelligence to an attacker. Additionally, data visibility and
immutability makes cryptographic security an issue since encrypted data cannot be removed from the
ledger even if the encryption algorithm has been broken.
Regulatory Requirements
Most businesses are governed by some type of laws or regulations that specify how they must protect
sensitive and personal data. When developing a blockchain solution, the organization needs to consider
how use of blockchain technology can affect regulatory compliance. The most common regulatory
requirements focus on data encryption and control and the protection of personally identifiable
information (PII).
Data encryption is a common requirement for sensitive data with specifications on acceptable encryption
algorithms and security levels. When developing a blockchain solution, it’s necessary to consider
whether the blockchain supports the necessary levels of encryption and whether data can be encrypted
without impacting the functionality of the blockchain (since blockchains rely on public verification of
transactions). Longer term, an organization needs to consider the required length of time the data must
be encrypted. In an immutable distributed ledger, data that was protected with an encryption algorithm
that has been broken cannot be removed from the ledger. Any data added to a distributed ledger should
be encrypted at a level that ensures it will not be exposed for the length of time that the data remains
sensitive.
Businesses commonly also have to demonstrate control over sensitive data in their possession.
Blockchain technology stores copies of the ledger on multiple nodes, all of which may not be owned by
the organization. When developing a blockchain solution for sensitive data, it may be wise to choose a
system with built-in access control capabilities.
Finally, organizations are required to protect personally identifiable information (PII). If such data is
stored on the blockchain, it must be appropriately encrypted and controlled. An organization should also
carefully analyze their blockchain solution for potential side-channel leakages. Data mining of
transactions on the blockchain may reveal business relationships, giving an adversary clues to trade
secrets or an organization’s business plans.
Blockchain Architectural Design

Different blockchains have different underlying architectures. However, they can be roughly classified
into a few different types based on how they handle privacy and access control. Blockchains can be
Private or Public and Permissioned or Open.
Private vs. Public Blockchains
The first distinction between different blockchains is that they are public or private. In a public
blockchain, anyone is allowed access to the blockchain, allowing it to be fully decentralized. In a private
blockchain, access is by invitation only.
Public blockchains have several advantages over private ones including:

● Decentralization: In a private blockchain, someone needs to issue invitations, which centralizes
the blockchain
● Scale: It is easier to build a larger blockchain network if anyone can join
Private blockchains also have their advantages, including:

● Control: An organization can restrict access to the distributed ledger
● Efficiency: A smaller network means less duplication of stored data and lower energy
consumption
Permissioned vs. Open Blockchains

The other major differentiation between blockchains is if they are permissioned or open. In a
permissioned blockchain, Membership Service Providers (MSPs) are nodes that enforce access and
permissions on the blockchain on a case-by-case basis. In an open blockchain, everyone with access to
the blockchain has access to all data and basic operations on the blockchain (creating transactions,
consensus, etc.).
Permissioned blockchains provide several advantages, including:

● Access Control: Organizations can specify access on a case-by-case basis
● Efficiency: Fewer nodes being involved in consensus decreases storage and energy requirements
Open blockchains also have their pros:

● Decentralization: MSPs centralize blockchain control and can be targets of attack
● User Privacy: Role-based access controls means users cannot be completely anonymous on the
blockchain
Chapter 5 Quiz
1. Implementing a blockchain solution means that an organization is willing to accept which of the
following?
a. Reduced functionality of developed programs
b. Decreased control of infrastructure
c. Decreased infrastructure resiliency
d. Decreased data storage capacity
2. Once a block has at least three blocks built on top of it, it cannot be removed from the
distributed ledger.
a. True
b. False
3. Blockchain’s distributed ledger reduces organizational storage requirements by breaking up the
ledger to be stored across multiple nodes.
a. True
b. False
4. Implementing programs as smart contracts risks a loss of an organization’s intellectual property.
a. True
b. False
5. The immutability of the blockchain is a security concern when dealing with regulatory
requirements for data encryption.
a. True
b. False
6. Data mining of the public distributed ledger can reveal sensitive information about the
blockchain’s users.
a. True
b. False
7. Which of the following is an advantage of a public blockchain?
a. Efficiency
b. Scale
c. Access Control
d. User Privacy
8. Which of the following is an advantage of a private blockchain?
a. User Privacy
b. Efficiency
c. Scale
d. Decentralization
9. Which of the following is an advantage of a permissioned blockchain architecture?
a. Scale
b. Decentralization
c. Access Control
d. User Privacy
10. Which of the following is an advantage of an open blockchain architecture?
a. User Privacy
b. Access Control
c. Scale
d. Efficiency

1. B
2. B
3. B
4. A
5. A
6. A
7. B
8. B
9. C
10. A
Chapter 6: Basic Blockchain
Security
Objective: Understand some of the most common ways in which blockchain security is compromised.
User Security
The people who have accounts on a blockchain system can be classified into users and nodes. Users are
anyone who makes use of the blockchain’s functionality while nodes also contribute to the blockchain via
ledger storage, participation in consensus, etc. All nodes are users but not all users are nodes. In this
section, we’ll discuss some of the most common ways in which users damage the security of the
blockchain.
Failure to Protect Private Keys

Blockchain technology uses public key cryptography to protect the authenticity and integrity of
transactions and blocks. The security of public key cryptography is dependent on the security of a user’s
private keys: anyone with a private key can decrypt messages and generate valid digital signatures on the
user’s behalf.
Failing to properly protect private keys is one of the most common security errors that users make.
Some solutions have been developed to help with this including:
● Hardware wallets: Physical devices that store private keys and perform cryptographic operations
on-device to prevent the keys from being leaked
● Hardware Security Modules (HSMs): Essentially hardware wallets built into computer chips with
physical protections
● Paper wallets: Writing a private key on a piece of paper and physically securing it (safe, etc.)
Vulnerability to Malware
Blockchain users interact with the network via their computers and computers are vulnerable to
malware. A malware infection on a user’s computer can affect the blockchain’s security in a few
different ways. If the user’s private key is stored on the computer, the malware can take control of their
account. Malware controlling a user’s computer has knowledge of some of the IP addresses of
blockchain users and can use this knowledge to attack them. Infected machines could also be used for
cryptojacking, where malware uses the infected computer’s computational resources to perform Proof of
Work calculations to the attacker’s benefit (either helping with a 51% attack or increasing the attacker’s
ability to earn block rewards).
Failure to Update
The blockchain is implemented as software that runs on user’s machines. Periodically, this software
needs to be updated and the developers send out a patch that users should download and install. The
impact of not performing the update depends on the type of update. If the update is only to improve
functionality, failure to update should limit or destroy the user’s ability to view and interact with the
blockchain. If the update is to fix a security hole, not installing it could put the user’s blockchain account,
computer, or the blockchain as a whole at risk.
Node Security
Nodes are users that also contribute to maintenance of the blockchain. They are prone to some of the
same security issues as users but also can be attacked in other ways.
Shared Vulnerabilities
All nodes are users, and the security issues of users also apply to nodes. However, the increased
participation of nodes in the blockchain means that a security compromise can have a greater impact for
a node than for a user. If a node’s private key is compromised, the node’s account can be used to attack
the consensus algorithm by working in the attacker’s interest. Compromise of a sufficient number of
nodes could give an attacker the ability to control the blockchain.
Failure by nodes to update their copy of the blockchain software can also have a dramatic impact. If
nodes do not install a feature update affecting how consensus is performed, it’s possible that the
blockchain network would split, creating two networks with weaker security. An attacker may be able to
control 51% of the resources on the split network when he could not on the complete one.
Misconfigured Membership Service Providers

In a permissioned blockchain, Membership Service Providers (MSPs) determine who can access the
blockchain and their rights on it. If a network’s MSPs are disabled by a Denial of Service attack, the
network may become non-functional. A compromised Membership Service Provider could give an
attacker control over the network’s access controls. MSPs should have protections against DDoS attacks
and be protected against malware and other types of attack.
Insecure API Connections

Blockchains’ Application Programming Interfaces (APIs) allow external applications to interact with the
blockchain. This means that these external components may be within the blockchain’s security
perimeter and should be handled accordingly. The blockchain API should be designed so that a
misconfigured or compromised application cannot damage the security of the blockchain and vice versa.
At a minimum, the API should be access-controlled and have sanitization of inputs coming from external
components.
Network Security
The blockchain network is built on top of traditional networking infrastructure. Security issues with the
underlying network can hurt the security of the blockchain as well.
Flawed Network Design

The blockchain network runs as a peer-to-peer network on top of the Internet or a company’s internal
network. The underlying network infrastructure used by the blockchain should be designed to meet the
needs of the blockchain. For example, blockchains are designed to allow nodes to talk in a peer-to-peer
fashion. If nodes are located in network segments with different security levels, this may violate the
organization’s network security protocols.
Also, the blockchain network requires a large amount of bandwidth for peer-to-peer communications.
Each node sends transactions and blocks to all of its peers, resulting in a large amount of duplication of
communications. The network infrastructure must be set up to handle this or the blockchain may be
vulnerable to attack.
Poor Network Security

The blockchain network communicates over traditional network infrastructure, and the security of the
blockchain is dependent on the security of the underlying network.
Physical attacks on the network infrastructure can affect the security of the blockchain. An attacker with
access to communication links or network components has the ability to affect the blockchain’s
communications, which can degrade its security. As much as possible, an organization should protect the
physical security of its communications infrastructure.
Poor logical security of the network can also affect the blockchain. Private blockchains may rely on the
security controls of the underlying network (firewalls, segmentation, etc.) and may be vulnerable to an
attacker who circumvents these controls. Control of firewalls and other components could also allow an
attacker to segment the blockchain network, leaving it vulnerable to attack.
Chapter 6 Quiz
1. Which of the following is a low-tech means of protecting a private key?
a. Hardware wallets
b. Hardware Security Modules (HSMs)
c. Paper wallets
d. Multisignature wallets
2. Using malware to mine for Proof of Work on an infected computer is called what?
a. Cryptojacking
b. Selfish Mining
c. Account Hijacking
d. Malicious Mining
3. The software that runs the blockchain is immutable and not designed to be updated.
a. True
b. False
4. An attacker pursuing a 51% attack may benefit from launching a malware attack on both users
and nodes.
a. True
b. False
5. Failure to update blockchain software may degrade or destroy a user’s ability to interact with the
distributed ledger.
a. True
b. False
6. It is critical that a blockchain network’s Membership Service Providers be equipped with
traditional anti-Denial of Service solutions.
a. True
b. False
7. During a hard fork software update, a blockchain network is more vulnerable to attack.
a. True
b. False
8. The use of blockchain technology has no effect on the security of the underlying network.
a. True
b. False
9. Blockchain technology can be securely used on any network, regardless of network architecture.
a. True
b. False
10. Poor physical control of network components can damage blockchain security.
a. True
b. False
1. C
2. A
3. B
4. A
5. A
6. A
7. A
8. B
9. B
10. A
Chapter 7: Blockchain for
Business
Objective: Understand the basic functionality of the Ethereum, Hyperledger, and Corda blockchain
technologies.
Introduction to Ethereum Security

Ethereum is the first smart contract platform, designed to allow developers to access a Turing-complete
platform on the blockchain and develop applications as smart contracts. The Ethereum network has the
following properties:
● Network Privacy: Public
● Permissioned: No
● Identity Mechanism: Public Key
● Consensus Algorithm: Proof of Work with planned transition to Proof of Stake
The Ethereum Distributed Ledger

The Ethereum distributed ledger consists of a set of trees:
● State Tree: Key, value pairs for each account in the Ethereum network
○ Values are the account’s nonce, balance, storage root, and hash of its code (if a smart
contract account)
● Storage Trees: The data storage for each account’s smart contracts
● Transaction Trees: A Merkle Tree containing the transactions of a given block
● Receipts Trees: Contains the gas usage, logs, Bloom filter, and status code of each transaction in
a given block
Each block on the blockchain contains hashes of the roots of the current version of the state tree and the
block’s transaction and receipts trees. This allows the blockchain to verify the state of the distributed
ledger at the time of the block’s creation.
Ethereum Smart Contracts

Ethereum smart contracts run in the Ethereum Virtual Machine. Contracts are written in the Solidity
programming language (developed for Ethereum), and each instruction in the Ethereum Virtual Machine
has an associated gas value. To execute a smart contract, a transaction includes an amount of gas
(fractions of an Ether) which is used to pay for the computational effort expended in running the code. If
a transaction includes insufficient gas to complete, the entire transaction is reversed and fails to
complete.
The Ethereum Virtual Machine currently has no support for parallelization, meaning that all transactions
in a block are run sequentially. However, this may change in the future if Ethereum implements
sharding, allowing transactions that interact with different parts of the state of the distributed ledger to
execute concurrently.
Ethereum Security Measures
Currently, Ethereum has very limited built-in support for privacy or security. Its use of public keys for
identity management are the main built-in feature as they give users a level of pseudo-anonymity.
However, advanced security features (like Confidential Transactions) can be implemented in Ethereum as
smart contracts. Additionally, future development in Ethereum is planned to include support for the
mathematical operations used in zero-knowledge proofs like zkSNARKS.
Introduction to Hyperledger Security

Hyperledger is a smart contract platform originally built by IBM and currently maintained by the Linux
Foundation. It is designed to be a blockchain platform for businesses and includes features to help it
accomplish this goal.
The Hyperledger blockchain has the following properties:

Network Privacy: Private
Permissioned: Yes
Identity Management: X.509 Certificates
Consensus Algorithm: Pluggable (currently offers transaction ordering with planned full BFT solution)
The Hyperledger Distributed Ledger

Hyperledger is built based on the principle of channels. Each channel in Hyperledger is a completely
distinct blockchain with its own distributed ledger visible only to members of the channel. This
architecture allows multiple blockchain networks to run on the same network of nodes.
Hyperledger’s Distributed Ledger consists of two components:

● Transaction Log: Blockchain of all transactions performed within a given channel
● World State: Snapshot of the current state of the ledger (modified by transactions)
Smart contracts in Hyperledger typically only interact with the World State component. Its purpose is to
save the contracts the trouble of searching through the entire blockchain for necessary information by
storing current states in a database as key, value pairs.
Hyperledger Smart Contracts

Hyperledger smart contracts or chaincode can be programmed in Node.js or Go and run in Docker
containers. They’re run by an external application interacting with the distributed ledger.
Hyperledger takes a slightly different approach to transaction validation and execution than smart
contract platforms like Ethereum. It follows an Execute, Order, Validate control flow:
● Execute: Nodes run the code, check its correctness, and endorse it if valid
● Order: Transactions are organized into blocks using the consensus protocol
● Validate: Ensure that transactions meet endorsement policy
○ Each transaction can have a necessary set of endorsers (threshold, certain users, etc.)
and will only be accepted if the requirements are met
The control flow used in Hyperledger has a couple of major benefits:

1. Parallelization: In the Execute phase, transactions can be validated in parallel instead of
sequentially
2. Specialization: Validation and Ordering are distinct phases, allowing nodes to specialize in one or
the other if desired
Hyperledger smart contracts are designed to appeal to business users since code can be efficiently tested
and ordered by specialized nodes and endorsement policies can be written to meet the needs of the
business.
Hyperledger Security Measures

Hyperledger has a few features designed to improve its security for business use cases:
● Pluggable Identity Management: Support for traditional schemes like LDAP and OpenID Connect
● Channel Architecture: Logically distinct blockchains with the ability for nodes to belong to
multiple channels as job roles require
● Private Data: Ability to exchange data via the gossip protocol, which only goes to nodes with
need-to-know and is stored in distinct, client-side databases off-chain
Introduction to Corda Security

Corda is a blockchain designed for business use cases. The developers have used the Java environment
as the virtual machine in order to ease adoption by businesses.
The Corda blockchain has the following properties:
● Privacy: Private
● Permissioned: Yes
● Identity Management: X.509 Certificates
● Consensus Algorithm: Pluggable
The Corda Distributed Ledger

Corda’s distributed ledger differs from most blockchains in that no-one in the blockchain network has full
visibility of the ledger. Access to data is on a need-to-know basis where only parties that are involved in
a transaction have the ability to view it.
Each node in the blockchain network keeps its own copy of the current state of the distributed ledger
from its point of view. The node’s ledger consists of multiple chains of immutable states (inputs and
outputs to transactions). States are consumed and produced by transactions and each node keeps a
complete history of both the current and historic versions of all of its states.
Smart Contracts in Corda

Corda is a smart contract platform built around the Java environment. It uses the Java Virtual Machine
and contracts can be written in Java or Kotlin.
Each state in Corda is governed by a smart contract. A smart contract takes a transaction involving its
state as an input and determines whether the transaction is valid based upon the rules encoded in the
smart contract.
Transactions in Corda must be determined to be both valid and unique in order to be accepted. The
validity of a transaction is determined by the parties involved in it. For a transaction to be valid it must:
● Be signed by all of the necessary parties
● Be contractually valid
● Have input states that are valid all the way back to the genesis block
The uniqueness requirement for transactions is designed to verify that states are not double-spent.
Nodes in Corda only have visibility of transactions and states where they were a party, so a node cannot
verify a transaction’s uniqueness (since they will not be a party to both of the double-spending
transactions).
To deal with this issue, Corda blockchains have a network of notaries that must sign a transaction to be
valid. Every state in every node’s copy of the distributed ledger has an assigned notary and a notary will
only approve a transaction where it is the assigned notary for all of the input states. If this is not the case
initially, a transaction can be performed with the sole purpose of changing the assigned notary of a state.
Once a notary has ownership of all states, they verify transaction uniqueness and sign it.
Corda Security Measures

Corda’s security is based primarily on its need-to-know philosophy and network of notaries. Since users
can only see and interact with transactions in which they have a stake, the potential impact of a data
leakage is reduced. Corda also uses point-to-point TLS-encrypted communications rather than peer-to-
peer broadcasts like other blockchains.
Security is Corda is heavily dependent on the notaries. Assets and transactions in Corda can be held
hostage if the assigned notary refuses to transfer them or sign. A malicious notary can permit a double-
spend attack and make it impossible to reconcile the blockchain. If implementing a Corda blockchain,
notary trust and security is paramount.
Chapter 7 Quiz
1. Which blockchain provides users with a level of pseudo-anonymity?
a. Corda
b. Ethereum
c. Hyperledger
2. Which blockchain does not organize transactions into blocks?
a. Corda
b. Ethereum
c. Hyperledger
3. In which blockchain are smart contracts called chaincode?
a. Corda
b. Ethereum
c. Hyperledger
4. Which blockchain uses Proof of Work for consensus?
a. Corda
b. Ethereum
c. Hyperledger
5. Which blockchain uses the gossip protocol to transmit private data?
a. Corda
b. Ethereum
c. Hyperledger
6. Which blockchain prevents anyone from having a complete view of the distributed ledger?
a. Corda
b. Ethereum
c. Hyperledger
7. Which blockchain does not allow specific endorsement rules to be set for transactions?
a. Corda
b. Ethereum
c. Hyperledger
8. Which blockchain uses security based on need-to-know?
a. Corda
b. Ethereum
c. Hyperledger
9. Which blockchain is most vulnerable to a malicious node?
a. Corda
b. Ethereum
c. Hyperledger
10. Which blockchain supports pluggable identity management?
a. Corda
b. Ethereum
c. Hyperledger
1. B
2. A
3. C
4. B
5. C
6. A
7. B
8. A
9. A
10. C
Chapter 8: Securely
Implementing Business
Blockchains
Objective: Understand the benefits of blockchain for business use cases and the associated security
considerations.
Business Operations
Business operations is the first of four categories of areas in which blockchain technology can help to
meet business needs. This category addresses situations dealing with the basics of running an
organization.
Business Continuity/Disaster Recovery

A common part of business risk management is development of the organizational Business
Continuity/Disaster Relief (BC/DR) strategy. This strategy describes how the business will react to events
that could degrade or destroy the organization’s ability to do business.
Blockchain technology has several features that are useful for a business developing a BC/DR strategy:
● Blockchain systems are designed to be fault-resistant
● Distribution decreases the probability that all nodes will be affected by an event
● Decentralization removes single points of failure and allows the system to function even if all but
one node are disabled
When developing a blockchain-based BC/DR solution, there are a couple of security considerations to
take into account:
● Storing sensitive data on the blockchain may have regulatory or legal impacts
● Functionality encoded as smart contracts may be subject to “code as law” arbitration
Contract Management
Most businesses have contracts with vendors, resellers, etc. Blockchain technology can help with
contract management in a variety of different ways:
● Terms of contracts can be encoded and enforced as smart contracts
● Smart contracts can hold currency or assets in escrow
● Contract bidding can be hosted on the blockchain and reach a wider audience
● Distributed Ledger Technology ensures contracts are accessible to all parties and resistant to
modification
When considering using the blockchain for contract management, the following considerations are
important to note:
● Smart contract code may be public on the blockchain
● Smart contract code can be considered legally binding (code as law arbitration)
Product Distribution
A major challenge in business is developing a means for getting product to market in a cost-effective
fashion. Blockchain technology has a couple of major benefits that can help improve the effectiveness of
a product distribution strategy:
● A blockchain network can reach a large pool of potential customers
● Smart contracts can encode purchasing options, terms of service, etc.
As with all technology, blockchain-based solutions have to be carefully designed to protect against
security vulnerabilities. A couple of considerations when using a smart contract platform for product
distribution include:
● Smart contract code can be subject to “code as law” in arbitration
● Smart contracts can be difficult to disable, replace
● Smart contract code is public and may reveal trade secrets or intellectual property
Product Monetization
The goal of most businesses is to develop a strategy for maximizing product adoption and value while
minimizing costs. Blockchain technology has a few features that can provide valuable contributions to an
organization’s product marketing and monetization strategy:
● Built-in support for financial transactions
● Ability to encode transactions as smart contracts
● Code hosting is outsourced and only paid for when used
When using the blockchain to perform financial transactions, secure design and implementation is of
paramount importance. A few important security considerations include:
● Improper protection of blockchain accounts can lead to financial loss
● Poorly coded smart contracts can have financial implications
● Smart contracts are non-removable and code is treated as final authority
Data Management
The second category explored here are the ways in which the blockchain can help an organization
manage its sensitive data. The blockchain can be beneficially applied to access management and data
retention and deletion strategies.
Access Control
Organizations commonly need to implement access control as a means of restricting employee
permissions based on need-to-know. A couple of benefits of the blockchain for implementing access
control include:
● Blockchain has built-in identity management
● Permissioned blockchains are designed to handle access control requirements
● Distributed and decentralized processing decreases attacker’s ability to target processing nodes
When using blockchain solutions for access control, the following considerations are important:
● Membership Service Provider (MSP) nodes have control over all blockchain permissions
● Improperly protected data cannot be removed from the distributed ledger
● Poorly coded smart contracts can be exploited repeatedly
Data Retention and Deletion

Organizations commonly have policies for how long data should be retained and how it should be
destroyed. Blockchain technology has certain benefits for tracking data throughout this process:
● Data can be tracked on the blockchain, decreasing the potential for tracking information to be
misplaced
● Smart contracts can automatically implement data lookup and deletion procedures
When designing a blockchain-based data retention and deletion solution, it is important to consider the
following:
● Data stored on the blockchain cannot be deleted from the distributed ledger
● Smart contract code is public, allowing attackers to identify and exploit vulnerabilities
● Improperly coded smart contracts may be difficult to update or delete
Infrastructure
An organization’s infrastructure is the third area in which blockchain can benefit businesses. Blockchain
technology provides solutions for management of organizational assets, infrastructure scalability, and
secure communications.
Asset Management
Management of an organization’s physical assets can be difficult as asset ownership, status, location, etc.
must be tracked at a department and possibly organization level. Blockchain technology can help with
creating an automated asset management system:
● Proof of ownership of assets can be tracked and transferred on the blockchain
● Distributed ledger makes ownership information accessible and decreases chance of loss
● Smart contracts can provide alerts if assets require updates or reach end-of-life
● Smart contracts can query assets for current state, verify location, etc.
When implementing a blockchain-based asset management system, the following risks and security
issues should be appropriately mitigated:
● Ownership information may be public on blockchain, revealing details about a company’s assets
● Vulnerable smart contracts may allow ownership of assets to be inappropriately transferred
Infrastructure Scalability
Organization’s public facing services need the ability to scale to meet demand. Blockchain technologies
provide several benefits for organizations seeking a solution for infrastructure scalability:
● Software can be written as smart contracts with hosting being outsourced
● Smart contracts only require payment when they are run
● Blockchain networks have built-in incentives that improve the probability that networks will grow
if need increases
● Computational and storage resources can be leased at-need via smart contracts
When developing a blockchain-based solution, the following design considerations are important:
● Blockchains are designed for a steady amount of traffic, not sudden surges
● Software written as smart contracts cannot be taken offline if a vulnerability is discovered
Secure Communications
Organizations need the ability to communicate securely and privately both internally and externally.
Blockchain is a good solution for secure communications with the following benefits:
● Most blockchains have the ability to send data (messages) with transactions
● Some blockchain have pseudo-anonymity, concealing message senders and recipients
● Peer-to-peer networks make it difficult to intercept or block communications
When developing a blockchain-based communications solution, it is important to consider the following:

● Transactions cannot be removed from the distributed ledger
Legal and Regulatory Compliance

Most organizations store sensitive data that is subject to legal or regulatory protections. Common
requirements include solutions for data control, data security, and corporate transparency.
Data Control
If an organization stores, processes, or transmits sensitive data, it is a common requirement that they be
able to demonstrate that they have control over the sensitive data. Blockchain technology can help
implement a solution for tracking data under the control of an organization:
● Data can be stored, tracked, and transferred while encrypted on the blockchain
● Blockchain uses publicly-available software, decreasing the probability of a hidden vulnerability
● Data on the blockchain cannot be modified after inclusion in a block
When using the blockchain to comply with regulatory requirements for data control, the following
considerations are important:
● The blockchain cannot be disabled if a security issue is detected
● Current regulations may not recognize blockchain technology as a storage medium
Data Security
Data protected by laws or regulations must be handled in a way that ensures that the data will not be
breached. Blockchain-based solutions have several benefits for an organization seeking to demonstrate
that data under their control is properly protected:
● Data can be stored, tracked, and transferred while encrypted on the blockchain
● Blockchain uses publicly-available software, decreasing the probability of a hidden vulnerability
● Blockchain immutability detects unauthorized modifications to data
● Attempts to access data via transactions are visible in the distributed ledger
When using the blockchain to protect sensitive data, the following considerations should be included
when designing the solution:
● Data and code stored in the distributed ledger may be publicly visible
● Vulnerable smart contracts may not be removable from the blockchain
Transparency
Organizational transparency is a common requirement to avoid fraud and business malpractice.
Blockchain technology can help an organization operate in a transparent manner:
● All transactions on the blockchain are publicly visible
● Data stored in the distributed ledger cannot be modified or deleted
When placing information on the blockchain to comply with regulatory transparency requirements, it is
important to consider the following:
● Improperly protected data may leak information about a business’s operations
Chapter 8 Quiz
1. The combination of smart contract technology and the immutable ledger provide a good means
for organizations to generate audit logs for certain activities.
a. True
b. False
2. Smart contract technology can be used to meet which of the following business needs? Select all
that apply.
a. Contract Management
b. Asset Management
c. Data Retention
d. Product Distribution
3. The built-in fault resistance of blockchain technology is most helpful for which of the following?
a. Business Continuity/Disaster Recovery
b. Infrastructure Scalability
c. Asset Management
d. Secure Communications
4. Blockchain technology is ideal for solving which of the following problems?
a. Data Control
b. Data Retention
c. Data Transparency
d. Data Deletion
5. Smart contract technology has useful applications for management of an organization’s physical
assets.
a. True
b. False
6. Sensitive data should be stored on the blockchain in an encrypted format to provide long-term
protection and access control.
a. True
b. False
7. Smart contract technology is useful for hosting a company’s software products since costs are on
a per-use basis.
a. True
b. False
8. When dealing with sensitive data, it should be stored on-chain to take advantage of blockchain
immutability.
a. True
b. False
9. Blockchain technology is designed to scale rapidly to handle sudden surges in usage.
a. True
b. False
10. The immutability of the distributed ledger can be a security concern when using transactions to
send sensitive data between users.
a. True
b. False

1. A
2. A,B,C,D
3. A
4. C
5. A
6. B
7. A
8. B
9. B
10. A
Chapter 9: Network-Level
Vulnerabilities and Attacks
Objective: Understand standard network-level attacks on blockchain technology including
implementation and mitigations.
51% Attacks
A 51% attacks is one of the simplest possible attacks against the blockchain since it takes advantage of
the legitimate function of the consensus algorithm. In a Proof of Work blockchain, the state of the
blockchain is determined by majority vote since, in the event of a divergent blockchain, the branch with
the greater amount of work behind it wins. If an attacker controls 51% of a PoW blockchain’s
computational resources, they control the blockchain.
Performing a 51% attack requires an attacker to purchase, rent, or steal enough computational resources
to have more than the rest of a blockchain network put together. Once they control the blockchain, they
can perform double-spend attacks.
Checkpointing is designed to protect against 51% attacks. By storing a block in the history of the
blockchain at intervals and refusing to accept divergent blockchains without these blocks, they prevent
an attacker from rewriting too much of the ledger’s history. However, divergent blockchains can exist
legitimately, so there is a fine line between protecting against attack and legitimate operation of the
blockchain. Checkpointing also runs the risk of centralizing (if a single node generates and distributes
checkpoints) or splitting (if multiple nodes generate checkpoints potentially on divergent chains) the
network.
Denial of Service Attacks

In a Denial of Service attack, an attacker attempts to degrade a service’s operations or make it
completely non-functional. In traditional, centralized networks, Denial of Service attacks target the
network’s bottlenecks or single points of failure. Blockchains are designed to be decentralized and have
no single points of failure, but Denial of Service attacks can still be effective against them.
The details of a Denial of Service attack depend on the blockchain technology and where bottlenecks and
single points of failure arise in its operations. Examples of Denial of Service attack types include:
● Transaction Flooding: Flood the network with transactions to increase the size of the queue for
transactions waiting to be added to blocks
● Artificial Difficulty Increases: Temporarily increase the computational power of a Proof of Work
blockchain to push up the difficulty then remove the increased resources
● Block Forger DoS: Perform a traditional DoS attack against the next block creator on a Proof of
Stake blockchain to prevent the block from being added to the chain
● Permissioned Blockchain MSP DoS: Perform a Denial of Service attack against a permissioned
blockchains MSPs to deny users access to the blockchain
The various types of Denial of Service attacks can be mitigated in different ways based upon how they
are implemented:
● Transaction Flooding: Wait out the attack or intentionally create blocks to clear flooded
transactions from the queue
● Artificial Difficulty Increases: Set difficulty increase interval to minimize attack impact
● PoS and MSP DoS: Implement traditional DoS protection for nodes
Eclipse Attacks
Blockchains run on a peer-to-peer network where each node connects to a set number of other nodes.
The network is deliberately not fully connected since this would dramatically increase overhead. In an
Eclipse attack an attacker controls all of a node’s connections to the network, allowing the attacker to
completely control the node’s view of the distributed ledger and network operations. A successful
eclipse attack allows the attacker to perform a double-spending attack against the isolated node, helps
the attacker perform a Denial of Service attack, or lets the attacker use the node’s computational
resources for the attacker’s benefit in the blockchain consensus algorithm.
Performing a successful eclipse attack requires the attacker to have location, power, scale, or malware at
their disposal. Location is helpful in this type of attack because an attacker may have the ability to
intercept the user’s messages before they reach the rest of the blockchain network (by WiFi attacks,
physical access to network cables, etc.). If an attacker has the power of an ISP or similar, they have
complete control over the user’s communications. An attacker with significant resources could
implement a large-scale attack where they create a large number of accounts on the blockchain in the
hopes that all of the user’s randomly selected connections will be to attacker-controlled nodes. Finally,
the attacker could infect the user’s computer with malware and use this to control their communications.
The probability that an eclipse attack will be effective can be decreased in a variety of different ways:
● Increased Connections: Reduce the probability that an attacker can control all nodes that the
user connects to
● Whitelist: Have a list of known, trusted nodes and always connect to at least one
● Random Reconnections: Improve the probability that, if eclipsed, the attack will be short and
detectable
● Permissioned, Private Blockchain: Decrease the probability of malicious nodes on the network
and make scale-based attacks more difficult (since membership is invite-only)
Replay Attacks
Transactions on the blockchain include the sender’s digital signature. The purpose of this is to ensure
that the transaction was actually generated by the sender and has not been modified in transit. An
attacker is unable to forge a digital signature, which makes generating fake transactions impossible.
In a replay attack, an attacker takes an existing transaction and resubmits it to the blockchain like it is a
new transaction. Since the original transaction was legitimate, the digital signature will be valid and
acceptable to the blockchain. This type of attack could benefit the attacker if the original transaction
benefitted the attacker. By replaying a transaction sending money to the attacker, the attacker gets paid
twice.
To protect against this attack, a blockchain can include nonces or a unique value in each transaction. If a
replayed transaction should have a new nonce and doesn’t, it will be rejected. If an attacker tried to
change the nonce value and replay it, the digital signature would be invalid and rejected by the network.
Routing Attacks
Unlike most blockchain attacks, routing attacks target the underlying communications network used by
the blockchain for peer-to-peer communications. If an attacker can control all of the communications
between two sets of nodes, they can partition the network. This is useful in performing 51% attacks,
Denial of Service attacks, and double-spend attacks.
The Internet relies on the Border Gateway Protocol (BGP) to find routes between different computers. In
this protocol, a computer wishing to send a message to another computer sends out a query if anyone
knows a way for the message to get there. The requestor chooses the shortest route advertised in
response and does not check routes for validity. If an attacker advertises short routes between two
network segments containing nodes of a blockchain network, it is probable that all traffic flowing
between those nodes will flow through the attacker, allowing him to isolate the two parts of the
network.
Routing attacks are only successful if an attacker can control all connections between the two parts of
the partitioned network. Several methods can decrease the probability of a successful attack:
● Multi-homed Nodes: If a node has Internet connections to two different segments, it makes it
more difficult for an attacker to find a way to split the network
● Intelligent Neighbor Selection: The more nodes that connect to nodes in different segments, the
more communications that the attacker needs to control
● Known Route Selection: An attacker can’t use BGP to subvert communications if a node uses
known, trusted routes to communicate with nodes in other network segments
● Network Statistics Monitoring: An attacker’s rerouting and monitoring is likely to significantly
increase network latency, monitoring for this could detect attacks
● Encrypted Authenticated Communications: Encryption and authentication ensure that an
attacker cannot monitor and change the communications occurring between nodes
Sybil Attacks
A Sybil attack is when an attacker creates a large number of accounts on the blockchain network. This
can be useful in eclipse attacks (making all of a node’s connections attacker-controlled), routing attacks
(controlling nodes that are sole connections between network segments) and attacking Proof of Stake
(manipulating coin age-based consensus selection).
To perform a Sybil attack, an attacker only needs the ability to create and operate a large number of
blockchain accounts. Botnets, virtualization technology, or malware can be used to accomplished this.
The best way to protect against a Sybil attack is to use a permissioned or private blockchain where access
controls limit the attacker’s ability to create accounts on the blockchain.
Chapter 9 Quiz
1. Which type of attack is checkpointing designed to mitigate?
a. Eclipse Attack
b. 51% Attack
c. Routing Attack
d. Sybil Attack
2. Which of the following attacks require the attacker significant resources? Select all that apply.
a. 51% Attack
b. Routing Attack
c. Denial of Service Attack
d. Sybil Attack
3. Which type of attack is designed to perform a double-spend attack against a specific target
node?
a. Eclipse
b. Routing
c. Sybil
d. 51%
4. Which of the following types of attacks can be mitigated by including a unique nonce in every
transaction?
a. Sybil Attack
b. 51% Attack
c. Replay Attack
d. Denial of Service Attack
5. Virtualization technology is a cheap way to make which type of attack possible?
a. Replay Attack
b. Sybil Attack
c. Eclipse Attack
d. Routing Attack
6. Which of the following is an effective mitigation for Eclipse attacks?
a. Encrypted communications
b. Node whitelisting
c. Checkpointing
d. Private blockchains
7. Always connecting to at least one trusted node is a good defense against which type of attack?
a. Routing
b. Sybil
c. Eclipse
d. Denial of Service
8. Multi-homed nodes are a good solution for what type of network attack?
a. 51% Attack
b. Eclipse Attack
c. Sybil Attack
d. Routing Attack
9. Controlling a large number of accounts on the blockchain is useful for which of the following
attacks? Select all that apply.
a. Eclipse
b. Routing
c. Replay
d. Sybil
10. The use of private or permissioned blockchains is most helpful in preventing which type of
attack?
a. Eclipse
b. Routing
c. Sybil

1. B
2. A,D
3. A
4. C
5. B
6. B
7. C
8. D
9. A,C,D
10. C
Chapter 10: System-Level
Objective: Understand attacks targeting blockchain design or implementations through real-world
examples
The Bitcoin Hack

Bitcoin is designed as a cryptocurrency, meaning that it needs to validate if transaction amounts are less
than the amount of value in the sender’s wallet. This transaction validation code included an integer
overflow vulnerability that allowed extremely large transaction amounts to pass the check.
An attacker exploited this vulnerability by creating a transaction that sent 184 billion Bitcoin to an
account controlled by an attacker. This would allow the attacker to control over 98% of all Bitcoin that
would ever exist and would destroy the value of Bitcoin.
The Bitcoin network made the decision to roll back the blockchain to erase the attack. This was an
important decision since the distributed ledger is designed to be immutable but was necessary to
preserve the cryptocurrency’s value.
The attack showed the importance of performing comprehensive security testing of blockchain code
before deployment. An integer overflow vulnerability is a well-known programming flaw and likely
would have been identified as part of a security assessment.
The Verge Hack

The Verge cryptocurrency is a cryptocurrency focused on preserving the privacy of its users. It was
hacked through the clever combination of some of its built-in features:
● Flexible Timestamps: Due to a lack of a synchronized time server on the blockchain, nodes accept
any block or a transaction timestamped within 2 hours of the current time
● Difficulty Updates: Verge uses the Dark Gravity Wave algorithm that updates Proof of Work
mining difficulty on a per-block basis based on a sliding window of past block times
● Consensus Algorithm: Verge uses Proof of Work but supports five algorithms instead of the usual
one
The attacker took advantage of these three features to control the Verge blockchain. By falsifying the
timestamp of every other block to an hour in the past, the attacker made it appear that blocks were
being created at a much slower rate than expected (hourly instead of every thirty seconds). As a result,
the Dark Gravity Wave algorithm dropped the difficulty of the mining algorithm used by the attacker
(scrypt). Mining with scrypt became ridiculously easy, allowing the attacker to perform a 51% attack with
less than 10% of the network’s computational resources.
To correct the issue, the Verge developed decreased the timestamp window from two hours to fifteen
minutes. This minimized the impact the attacker could have on the mining difficulty.
The biggest takeaway from this attack is that complexity can hurt security. The attack was only made
possible by the combination of the three features built into the Verge cryptocurrency. The attack also
demonstrated the effectiveness of time warp attacks (exploiting timestamp flexibility) and the danger of
frequent mining difficulty updates.
The EOS Vulnerability

EOS is an open-source smart contract platform. As a smart contract platform, the EOS software needs to
be able to parse and execute smart contract files. A buffer out of bounds writing vulnerability in the
parsing function allowed malicious smart contracts to exploit the EOS blockchain software.
Researchers at Qihoo 360 identified and reported the bug to the EOS developers. Their proof of concept
demonstrated that they could bypass Address Space Layout Randomization (ASLR) and get a remote shell
from the attacked node. As a result, they could completely compromise the blockchain network and all
nodes running it.
Since EOS was not yet launched, the EOS developers were able to issue a fix on their Github page with no
risk of the vulnerability being exploited. The process demonstrated the value of external code reviews
(especially for well-known vulnerabilities) and that vulnerable smart contract platforms can allow a
malicious smart contract to exploit the node running the blockchain software.
The Lisk Vulnerability

Lisk is a cryptocurrency that is vulnerable to an exploit taking advantage of two built-in features. Lisk
uses the last 64 bits of the SHA-256 hash of a user’s public key as their address on the blockchain. This
address isn’t tied to a specific public key on the blockchain until the user performs a transaction (either
sending cryptocurrency or voting for a delegate).
This system can be attacked because transactions sending value to an account do not tie an address to a
public key. Any accounts that have only received value remain unclaimed. The complexity of finding a
public key that can be tied to a given address is at most 264 operations (which is doable) and “failures”
may allow an attacker to claim a different address. The value of some of the vulnerable accounts on the
Lisk blockchain (one was worth $184 million) make the attack worthwhile.
Once the vulnerability was reported, the Lisk developers issued an announcement describing the issue
and advising users to take an action that ties their account’s address to the public key. However, Lisk
remains vulnerable to the attacks and may be vulnerable to race conditions where an attacker tries to
claim an address between the initial transaction funding it and the transaction sending value to claim it.
Chapter 10 Quiz
1. Which of the following blockchain hacks demonstrated the fact that increased complexity can be
a threat to security?
a. Bitcoin
b. EOS
c. Lisk
d. Verge
2. Which of the following blockchains is most vulnerable to being attacked via the same attack
vector?
a. Bitcoin
b. EOS
c. Lisk
d. Verge
3. The fix implemented by the Verge developers after the hack eliminated the possibility that the
blockchain could be attacked again by the same means.
a. True
b. False
4. The flaws of which of the following blockchains had the greatest potential to impact the security
of the blockchain?
a. Bitcoin
b. EOS
c. Lisk
d. Verge
5. The flaws of which of the following blockchains enabled an attacker to perform a double-spend
attack?
a. Bitcoin
b. EOS
c. Lisk
d. Verge
6. The primary effect of which of the following hacks was the complete destruction of the value of
the blockchain’s cryptocurrency?
a. Bitcoin
b. EOS
c. Lisk
d. Verge
7. The rate at which a Proof of Work blockchain updates its mining difficulty can be a tradeoff
between efficiency and security.
a. True
b. False
8. In which of the following blockchains did the security flaw have the potential to take over the
computers of nodes running the blockchain?
a. Bitcoin
b. EOS
c. Lisk
d. Verge
9. For which of the following blockchains did the solution to the problem involve violating the
fundamental principles of blockchain?
a. Bitcoin
b. EOS
c. Lisk
d. Verge
10. Which of the following hacks could likely have been prevented by a code review searching for
common programming flaws? Select all that apply.
a. Bitcoin
b. EOS
c. Lisk
d. Verge

1. D
2. C
3. B
4. B
5. D
6. A
7. A
8. B
9. A
10. A,B
Chapter 11: Smart Contract
Objective: Understand the most common smart contract vulnerabilities and how they can be exploited.
Reentrancy
A smart contract may be vulnerable to a reentrancy attack if it updates state after performing a state-
changing operation. If a smart contract’s withdraw function sends value to another smart contract, the
recipient smart contract’s payable fallback function is called, which can re-call the original smart
contract’s withdraw function and perform a second withdraw before the user’s account balance is
updated in the original smart contract.
The sample code above is vulnerable to a reentrancy attack. In line 3, a smart contract’s fallback function
may be called, which can call this function again. Since the smart contract has not yet updated its
account balances (performed in line 4), the user can end up withdrawing twice the original amount.
The famous breach of the Ethereum DAO smart contract involved exploiting a reentrancy vulnerability.
The smart contract included code similar to the example above, allowing a malicious smart contract to
drain value from the DAO smart contract.
Access Control
Smart contracts commonly give different levels of permissions to their owners versus other users. If the
access control code of a smart contract is improperly implemented, a malicious user can gain control of
the smart contract.
The code sample above is designed to give ownership permissions to the creator of the smart contract as
part of the initialization process. However, the code does not check if the initContract function has
already been called, allowing any user to call it again and claim ownership of the contract.
The Parity wallet was a commonly-used smart contract-based cryptocurrency wallet. It included an
initWallet function that stored the list of users authorized to make transactions using the wallet.
However, it did not include a check if initWallet had been called in the past, allowing an attacker to call
the function for several valuable wallets and claim the cryptocurrency stored within.
Arithmetic
Common arithmetic vulnerabilities include integer overflows and integer underflows. An integer
overflow vulnerability occurs when a variable is stored in a fixed-size variable without verifying that the
value is less than the maximum value that the variable can contain. If this is not the case, the value
“wraps around”, allowing a very large number to appear to be a small one.
Integer underflows are a vulnerability commonly caused by subtracting a large number from a small
number and storing the result in an unsigned variable, making it appear to be a very large number
The code example above includes an integer underflow vulnerability in line 2. If _amount is greater than
the sender’s balance, it will produce a negative result that will appear to be a large positive number and
pass the check.
BatchOverflow is the name PeckSecurity gave to a smart contract vulnerability that they discovered in
the wild. Vulnerable contracts would be designed to send the same amount of cryptocurrency to
multiple recipients. The issue is that they would check that the total value to be sent was valid all at once
(creating an integer overflow) but send value to each recipient separately (no overflow).
Unchecked Return Value

In Ethereum, some low-level functions will return false if they failed rather than throwing an error. If
smart contracts fail to check return values of low-level functions, they may not realize that the functions
failed. Send fails silently (returns false) in Ethereum; transfer does not.
In the smart contract sample shown above, the function makes a call to send in line 5 and does not check
the return value. Send is a low-level function that will return false if failed. If send fails in this code, the
smart contract’s account balances will be incorrect.
King of the Ether was a smart contract where users could pay increasing amounts of cryptocurrency to be
named “King of the Ether” with the proceeds going to the previous monarch. It included an unchecked
call to send with only a small amount of gas allocated to it. If the previous monarch used a smart
contract-based wallet, send would fail and deprive them of their payment.
Denial of Service
Denial of Service vulnerabilities make it possible for a smart contract to be rendered non-functional. Two
common Denial of Service vulnerabilities are created by poor access control and the potential for infinite
loops or recursion.
The code sample above shows smart contract code that is vulnerable to a Denial of Service attack. If
largestWinner is set high enough, the smart contract will require a large amount of gas to execute the
selectNextWinners function. Ethereum has a built-in maximum gas limit, meaning that the function
could be impossible to run if largestWinner becomes too large.
Bad Randomness
Some smart contracts need access to a random number. Some ways of getting a “random” number are
using a secret value, using embedded secret code, basing the number off of statistics from mining, and
using an external oracle. Since smart contract code is public on the blockchain, the first two options do
not work. A malicious miner can manipulate the third option to their benefit. The only workable
solution is to use a random oracle external to the blockchain.
The sample code above uses random numbers as part of a smart contract-based gambling game. As a
source of randomness, it uses the hash of a previous block on the blockchain. This solution will not work
regardless of the block used for the following reasons:
● Ethereum only stores the last 256 block hashes and returns 0 for anything before (which is a
winner)
● For the previous 256 blocks, an attacker could create a smart contract that checks if the current
block is a winner and, if so, call this function to claim the prize
The SmartBillions lottery was an Ethereum-based gambling game where a user can predict 6 “lucky
numbers”, and, if the hash of the block when they decided to call the play function equaled the number,
they could get a certain return on their bet (repeated 6 times for increasing rewards). A player learned
about the fact that Ethereum only stores the last 256 block hashes and, by guessing all zeros, managed to
win on several blocks before the SmartBillions creators drained the pot (demonstrating it was a scam
anyway).
Race Conditions
A race condition is when two different programs compete to be the first to complete some task. Some
blockchains are vulnerable to race conditions because transactions are visible in a public pool and the
order in which they are placed in blocks depends on the included transaction fees. If a smart contract
rewards users for completing a puzzle, an attacker can watch the transaction pool for a solution and then
submit the same solution with a higher transaction fee to win the prize. Alternatively, a malicious miner
could cause themselves to win the race regardless of transaction fee amounts.
The sample code above is part of the King of the Ether code designed to transfer the throne to a new
monarch if they pay the minimum amount to claim the prize. It is vulnerable to race conditions because
a user could observe another user’s transaction to claim the prize and beat them to it by submitting a
transaction with a higher transaction fee.
The Bancor smart contract-based cryptocurrency exchange is designed to allow users to buy and sell
tokens using Ether. Its exchange rates are based on its current supply of each coin. An attacker can
make a guaranteed profit on Bancor by exploiting race conditions to ensure that they perform a
transaction before another user would make a similar transaction. Winning a race to buy allows the
attacker to buy low and then sell higher (since the value of their tokens increased in Bancor due to the
reduced supply). Winning a race to sell allows them to sell high and buy low (increased supply makes the
price of the token lower).
Timestamp Dependence
Some smart contracts are designed to perform an action after a specific time. Since the only access the
contract has to timing information is block timestamps (which are flexible), a malicious miner can create
a block that allows them to win the prize at exactly the right time (as long as the time is within the
acceptable block timestamp window).
The sample code above is vulnerable to attacks exploiting timestamp dependence. If an attacker
manages to win the right to create a block within the window where the desired timestamp would be
acceptable, they can include a transaction with themselves claiming the prize.
The GovernMental smart contract was designed to allow users to bet on whether no-one would place a
new bet within 12 hours. If so, they would win the value in the smart contract. Since most blockchains
have a two-hour window for timestamp acceptance, a miner who creates a block at the 10-hour mark
could win the prize.
Short Addresses
Short address attacks exploit the fact that arguments to a function are stored contiguously in memory
and that Ethereum automatically pads arguments to the correct length. If the arguments to a function
are too short, Ethereum will automatically right-pad the last argument to fix it. If an attacker calls a
function with arguments (address,amount) with an address that is one byte too short, the function will
interpret the first byte of amount as the last byte of address and right-pad amount by one byte
(multiplying it by 256).
The sendCoin function shown above is vulnerable to a short address attack. sendCoin does not impose
sizes on its variables, so the short address and amount are read appropriately and amount passes the
check in line 3. However, the Transfer function called in line 1 imposes a length of 256 on amount. If to
is one byte short and the first byte of amount is the correct last byte for the attacker’s to address, the
attacker will receive 256 times the amount of Ether that the sendCoin function approved.
Multiple cryptocurrency exchanges are probably vulnerable to this type of attack. However, no instances
of the attack have been publicly reported.
Chapter 11 Quiz
1. Which smart contract vulnerability takes advantage of the fact that blockchains add transactions
to the ledger in blocks? Select all that apply.
a. Short Addresses
b. Timestamp Dependence
c. Race Conditions
2. Which smart contract vulnerabilities allow an attacker to make a single transaction of more than
the amount approved by the contract? Select all that apply.
a. Reentrancy
b. Arithmetic
c. Access Control
d. Short Address
3. Loops are dangerous in smart contracts because they can create which of the following
vulnerabilities?
a. Reentrancy
b. Arithmetic
c. Denial of Service
d. Race Conditions
4. The King of the Ether smart contract included which of the following vulnerabilities? Select all
that apply.
a. Unchecked Return Value
b. Reentrancy
c. Race Conditions
d. Access Control
5. In which of the following vulnerabilities is the details of what information Ethereum makes
available to smart contracts important?
a. Access Control
b. Timestamp Dependence
c. Race Conditions
d. Bad Randomness
6. The sample code shown above is vulnerable to which of the following?

a. Race Conditions
b. Access Control
c. Timestamp Dependence
d. Reentrancy
a. Reentrancy
b. Unchecked Return Values
c. Arithmetic
d. Access Control

a. Timestamp Dependence
b. Bad Randomness
c. Access Control
d. Reentrancy

a. Reentrancy
b. Access Control
c. Short Address
d. Race Condition
a. Access Control
b. Denial of Service
c. Arithmetic
d. Race Condition

1. B,C
2. B,D
3. C
4. A,C
5. D
6. B
7. C
8. A
9. D
10. B
Chapter 12: Security of
Alternative DLT Architectures
Most current Distributed Ledger Technology (DLTs) use blockchain as their data storage architecture.
However, this is not the only option. Directed Acyclic Graphs (DAGs) are another option for creation a
DLT solution.
Introduction to Directed Acyclic Graphs (DAGs)

Blockchain technology is based on directed graphs. Each block in the blockchain is a node and each block
is connected to the previous block using a hash. The type of directed graph used in blockchain (a linked
list) is the simplest possible type of directed graph but is not the only option for DLT.
DAG-based distributed ledger solutions (like IOTA and Byteball) are designed as trees rather than linked
lists. Blockchains grow by collecting transactions into blocks and appending them to the previous block;
DAGs grow by allow transactions to connect to any leaf node in the tree.
Transactions in a DAG
In blockchain, a network of nodes take responsibility for validating transactions and updating the
distributed ledger. This requires transactions to be collected into blocks.
In IOTA’s Tangle, each transaction validates two other transactions. The choice of transactions to verify
is made using a weighted random walk.
The algorithm starts at the genesis transaction and moves to a transaction that validates it. The choice of
which transaction to move to is selected randomly where each option is weighted by the number of
transactions that validate it. This process is repeated until a leaf node is reached and the entire
algorithm is run twice to select two transactions to verify.
The node then validates the entire history of these transactions. Once a transaction has completed
verification and a small Proof of Work (as anti-spam), it can be sent off to the rest of the network and is
immediately considered a (unverified) part of the distributed ledger.
Since the distributed ledger is constantly changing, it’s impossible for anyone to know the entirety of its
exact state. The determination whether a transaction is officially part of the distributed ledger is
probabilistic. This probability is calculated by performing the same random walk described previously
many times and determining if the resulting leaf node validates (directly or indirectly) the transaction of
interest. If a transaction is validated by a high percentage of the leaf nodes, it is probably trustworthy.
Advantages and Disadvantages of DAGs

Directed Acyclic Graphs (DAGs) are designed to be an alternative to the blockchain and to help solve
some of the issues facing blockchain technology. Some of the major advantages of DAG-based DLTs are:
● Decentralization
○ Blockchains rely on a network of nodes for transaction validation.
○ DAGs have users perform validation as part of creating transactions.
● Overhead
○ Proof of Work calculations in blockchain are competitive (everyone racing for a solution).
○ Proof of Work calculations in DAGs are cumulative (each transaction has one and forging
a DAG means forging all validating transactions).
● Scalability
○ Blockchains use linked lists, which can only grow linearly.
○ DAGs use trees, which can grow exponentially.
● Speed
○ Blockchains add transactions to the ledger as a group (blocks), which creates delays.
○ DAGs add transactions to the ledger instantly and perform validation later. Delays
decrease as the network is used more.
DAGs also have some disadvantages when compared to blockchain-based solutions:
● Double-Spends
○ DAGs do not solve blockchain’s double-spend problem
● Network Synchronization
○ Blockchains come to consensus on every block. Transactions can be trusted within a few
block cycles.
○ DAG transactions are validated on a per-transaction basis (and may be left behind).
Consensus is probabilistic based on how the DAG grows.
Chapter 12 Quiz
1. Blockchains use Directed Acyclic Graphs (DAGs) as their underlying data storage architecture.
a. True
b. False
2. A binary tree is a directed graph but not an acyclic one.
a. True
b. False
3. DAG-based distributed ledgers have no need to group transactions into blocks.
a. True
b. False
4. Which of the following is not an area where DAGs are superior to blockchains?
a. Overhead
b. Speed
c. Synchronization
d. Decentralization
5. An advantage of DAG-based distributed ledgers is increased decentralization since they eliminate
the need for a network of block creators.
a. True
b. False
6. The primary purpose of Proof of Work calculations in IOTA’s Tangle is to help with network
consensus.
a. True
b. False
7. DAG-based distributed ledgers can grow exponentially, while blockchains can only grow linearly.
a. True
b. False
8. DAG-based distributed ledgers increase in speed as they are used more.
a. True
b. False
9. Transactions will be added to the distributed ledger more quickly in DAGs than in blockchains.
a. True
b. False
10. A DAG-based distributed ledger is likely to have less computational overhead when compared to
a blockchain with a similar network size and transaction rate.
a. True
b. False
1. A
2. B
3. A
4. D
5. A
6. B
7. A
8. A
9. A
10. A

CBSP Official Exam Study Guide v1.5

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CBSP Official Exam Study Guide v1.5

Uploaded by

Copyright:

Available Formats

Certified Blockchain Security Professional (CBSP) Official Exam Study Guide

By: Howard Poston and Kris Bennett

Book is published by Blockchain Training Alliance, Inc.

Limit of Liability / Disclaimer of Warranty / Terms of Use

Chapter 2: Consensus in the Blockchain ............................................................. 12

Chapter 3: Advanced Blockchain Security Mchanisms ........................................ 18

Chapter 4: Smart Contract Security .................................................................... 23

Chapter 5: Blockchain Risk Assessment.............................................................. 28

Chapter 6: Basic Blockchain Security .................................................................. 34

Chapter 7: Blockchain for Business .................................................................... 39

Chapter 8: Securely Implementing Business Blockchains ................................... 45

Chapter 9: Network-Level Vulnerabilities and Attacks ....................................... 52

Chapter 10: System-Level Vulnerabilities and Attacks ........................................ 57

Chapter 11: Smart Contract Vulnerabilities and Attacks..................................... 61

Chapter 12: Security of Alternative DLT Architectures ....................................... 70

Cryptography for the Blockchain

Public Key Cryptography

Public key cryptography has two main applications:

Elliptic Curve Cryptography

A Brief Introduction to the Blockchain

Blockchain Security Assumptions

Attacking Basic Blockchain Security

Chapter 1 Quiz Answer Key

Blockchain Consensus and the Byzantine Generals

Introduction to Blockchain Consensus Security

Solving BGP with PoW

Solving BGP with PoS

Other Blockchain Consensus Algorithms

Chapter 2 Quiz Answer Key

Architectural Security Measures

Confidential Transactions take advantage of several different cryptographic operations:

Chapter 3 Quiz Answer Key

Introduction to Smart Contracts

Smart Contract Security Considerations

Smart Contract Lifetimes

Smart Contract Code Auditing

Auditing Smart Contracts

Chapter 4 Quiz Answer Key

Blockchain Risk Considerations

Blockchain Architectural Design

Public blockchains have several advantages over private ones including:

Private blockchains also have their advantages, including:

Permissioned vs. Open Blockchains

Permissioned blockchains provide several advantages, including:

Open blockchains also have their pros:

Chapter 5 Quiz Answer Key

Failure to Protect Private Keys

Misconfigured Membership Service Providers

Insecure API Connections

Flawed Network Design

Poor Network Security

Introduction to Ethereum Security

The Ethereum Distributed Ledger

Ethereum Smart Contracts

Introduction to Hyperledger Security

The Hyperledger blockchain has the following properties:

The Hyperledger Distributed Ledger

Hyperledger’s Distributed Ledger consists of two components:

Hyperledger Smart Contracts

The control flow used in Hyperledger has a couple of major benefits:

Hyperledger Security Measures

Introduction to Corda Security

The Corda Distributed Ledger

Smart Contracts in Corda