Blockchain Technologies Feature Analysis

Copyright 2016 Digital Bazaar, Inc. (except for Data Structure sections)
Shared under a Creative Commons Attribution 4.0 International license

Abstract

This document analyses the security and performance characteristics of six interesting software systems related to blockchain technology and decentralized identity systems. The systems analyzed in this report are Bitcoin, Ethereum, Stellar, IPFS, Blockstack, and Hashgraph.

Overview

The security and performance findings of this report are summarized in table form at the beginning of the report. Each technology is then analyzed in detail for the rest of the report.

Each analysis of a particular blockchain technology starts by documenting the basic data structures used for the system. The basic data structures are a window into the information that the system needs to operate. They also provide a view into the capabilities and complexity of the given system.

Once the data structures are highlighted, an analysis on the security characteristics of the system is performed. This analysis is based on what the system is capable of doing today. A similar analysis is then performed for the performance characteristics of the system. Finally, the notable characteristics of the system are outlined in an attempt to highlight what makes the particular blockchain different from other blockchains.

Disclaimer

The analysis performed in this document is preliminary, the field of study is
rapidly evolving, and thus this document is a work in progress. There may be
errors or interpretations that do not align with the high-level summaries that
the authors have presented in this analysis. We are actively engaging with the
developer communities that created each technology analyzed in this document
in an attempt to ensure that the information provided and analysis performed
is accurate.

Table of Contents ﹂ Terminology ﹂ Security Principles Summary Chart ﹂ Performance Principles Summary Chart ﹂ Bitcoin    ﹂ Data Structures       ﹂ Block Format       ﹂ Blockheader Format       ﹂ Transaction Format       ﹂ Transaction Input Format       ﹂ Transaction Output Format    ﹂ Security Characteristics    ﹂ Performance Characteristics    ﹂ Notable Features ﹂ Ethereum    ﹂ Data Structures       ﹂ Account Format       ﹂ Message Transaction Format       ﹂ Receipt Format       ﹂ Block Format    ﹂ Security Characteristics    ﹂ Performance Characteristics    ﹂ Notable Features ﹂ Stellar    ﹂ Data Structures       ﹂ LedgerHeader Format       ﹂ Account Format       ﹂ Transaction Format    ﹂ Security Characteristics    ﹂ Performance Characteristics    ﹂ Notable Features ﹂ IPFS    ﹂ Data Structures       ﹂ Object Merkle DAG - IPFSLink       ﹂ Object Merkle DAG - IPFSObject       ﹂ Other    ﹂ Security Characteristics    ﹂ Performance Characteristics    ﹂ Notable Features ﹂ Blockstack    ﹂ Data Structures       ﹂ Base Name Record Format       ﹂ Base Namespace Format       ﹂ Name Import Format       ﹂ Namespace Preorder Format       ﹂ Namespace Reveal Format       ﹂ Namespace Ready Format       ﹂ Name Preorder Format       ﹂ Name Registration Format       ﹂ Name Revoke Format       ﹂ Name Update Format    ﹂ Security Characteristics    ﹂ Performance Characteristics    ﹂ Notable Features ﹂ Hashgraph    ﹂ Data Structures       ﹂ Gossip Event    ﹂ Security Characteristics    ﹂ Performance Characteristics    ﹂ Notable Features

Terminology

In order to perform a meaningful analysis of each system, it is important to define and use the terminology that is applied to each system consistently. The terminology below is used throughout the document and readers are strongly advised to understand the terminology before going further and to refer back to this section in order to fully understand the usage of each term in the analysis sections.

• Confidentiality: Asserts that information is not made available or disclosed to unauthorized individuals, entities, or processes.

• Integrity: Asserts that information accuracy and completeness of data over its entire life-cycle is maintained and assured.

• Non-repudiation: Asserts that one party of a transaction cannot deny having received a transaction nor can the other party deny having sent a transaction.

• Information Availability: Asserts that all information to perform a particular action must be available when it is needed.

• Provenance: Asserts that the the chronology of ownership, custody, or location of a piece of information can be traced throughout time.

• Pseudonymity: Asserts that interactions do not expose an entity’s true name or legal identity

• Selective Disclosure: A situation where an entity may disclose information to one or more selected entities without disclosing that information outside of the selected set.

• Consistency: Asserts that all nodes in a decentralized system see the same data at the same time.

• System Availability: Asserts that every request receives a response about whether it succeeded or failed.

• Failure Tolerance: Asserts that the a decentralized system continues to operate despite arbitrary partitioning due to network failures.

• Scalability: A characteristic of a system that states how performance characteristics change as the system grows or shrinks in size.

• Latency: A characteristic of a system that states how much time it takes to complete certain operations.

• Auditability: A characteristic of a system that ensures that the complete system state can be verified at any given time to be correct.

• Liveliness: A characteristic of a system that states that all data requested may be retrieved from the system at any point.

• Denial of Service Resistance: A measure of a system’s ability to respond to requests when under extreme load. Typically, a mechanism is utilized that is capable of determining a valid request from an invalid one or that makes the price the attacker must pay far greater than the price the receiver must pay to execute the request.

• System Complexity: The level of complexity in the system that exists to achieve a set of tasks.

Security Principles Summary Chart

Principle	Bitcoin	Ethereum	Stellar	IPFS	Blockstack	Hashgraph
Confidentiality	NONE	NONE	NONE	Hash-based content addresses	NONE	NONE
Information Availability	Block Mirroring	Block Mirroring	Ledger Mirroring	Graph and file Mirroring	Block Mirroring / DHT Mirroring	Hashgraph Mirroring; optional event history
Integrity	Multiple block verifications	Multiple block verifications	Latest block verification	Hash-based content addressing	Multiple block verifications	Consensus with probability one
Non-repudiation	Digital signatures	Digital signatures	Digital signatures	Digital signatures	Digital signatures	Digital signatures
Provenance	Transaction inputs/outputs	Ethereum state machine and transition functions	Digitally signed ledger transition instructions	Digital signatures and versioning	Transaction inputs & outputs and virtualchain references	Hashgraph Mirroring; optional event history
Pseudonymity	Public keys	Public keys and contract addresses	Public keys	Public keys	Public keys, but public information encouraged	Not supported; could be layered
Selective Disclosure	NONE	NONE	NONE	NONE	Selective access to encrypted storage	Not supported; could be layered

Performance Principles Summary Chart

Principle	Bitcoin	Ethereum	Stellar	IPFS	Blockstack	Hashgraph
Consistency	Block verifications. 30-60 minutes	Block verifications. 20-60 minutes	Single block verification. Less than 1 minute	P2P mirroring. Limited primarily by network I/O. Several seconds for files less than 128KB.	Block verifications. 30-60 minutes	Consensus with probability one; Byzantine agreement, but attackers must control less than one-third
System Availability	Block verifications. 30-60 minutes	Block verifications. 20-60 minutes	Single block verification. Less than 1 minute.	Single storage request response. Several seconds for files less than 128KB	Block verifications. 30-60 minutes	Virtual voting; DoS resistant w/o proof-of-work, fast gossip
Failure Tolerance	Longest chain wins	Longest chain wins	Last balloted block always has consensus.	Content address hash. Highly resilient against network partitioning	Longest chain wins	Strong Byzantine fault tolerance
Scalability	Block size. 7 transactions per second	Block size. 7-20 transactions per second	Thousands to tens of thousands of transactions per second.	Thousands to tens of thousands of transactions per second. Scales linearly as nodes are added.	Block size. 7 transactions per second	Thousands to tens of thousands of transactions per second. Limited by bandwidth only
Latency	Block verifications. 30-60 minutes	Block verifications. 20-60 minutes	Single block verification. Less than 1 minute.	Single storage request response. Several seconds for files less than 128KB.	Block verifications. 30-60 minutes	Virtual voting; limited only by exponentially fast gossip protocol
Auditability	Full	Full	Full	Difficult	Full	Configurable
Liveliness	Full	Full	Full	Fails if nodes storing data fail	Full	Full
Denial of Service Resistance	Spend Bitcoin	Spend Ether	Spend Stellar	Files are only mirrored if requested	Spend Bitcoin	Signed State / Proof-of-stake / < 1/3 attackers
System Complexity	Medium	High	Medium	Medium	Medium	Low, but not full system

Bitcoin

Data Structures

Block Format

Field	Description	Size
Magic no	value always 0xD9B4BEF9	4 bytes
Blocksize	number of bytes following up to end of block	4 bytes
Blockheader	See below	80 bytes
Transaction counter	positive integer	1 - 9 bytes
transactions	the (non empty) list of transactions	Transaction counter - many transactions

Blockheader Format

Field	Description	Size
Version	Block version number	4 bytes
hashPrevBlock	256-bit hash of the previous block header	32 bytes
hashMerkleRoot	256-bit hash based on all of the transactions in the block	32 bytes
Time	Current timestamp as seconds since 1970-01-01T00:00 UTC	4 bytes
Bits	Current target in compact format	4 bytes
Nonce	32-bit number (starts at 0)	4 bytes

Transaction Format

Field	Description	Size
Version no	currently 1	4 bytes
In-counter	positive integer	1 - 9 bytes
list of inputs	the first input of the first transaction is also called "coinbase" (its content was ignored in earlier versions)	In-counter - many inputs
Out-counter	positive integer	1 - 9 bytes
list of outputs	the outputs of the first transaction spend the mined bitcoins for the block	Out-counter - many outputs
lock_time	if non-zero and sequence numbers are < 0xFFFFFFFF: block height or timestamp when transaction is final	bytes

Transaction Input Format

Field	Description	Size
Previous Transaction hash	doubled SHA256-hashed of a (previous) to-be-used transaction	32 bytes
Previous Txout-index	non negative integer indexing an output of the to-be-used transaction	4 bytes
Txin-script length	non negative integer	1 - 9 bytes
Txin-script / scriptSig	Script	in-script length - many bytes
sequence_no	normally 0xFFFFFFFF; irrelevant unless transaction's lock_time is > 0	4 bytes

Transaction Output Format

Field	Description	Size
value	non negative integer giving the number of Satoshis to be transferred	8 bytes
Txout-script length	non negative integer	1 - 9 bytes
Txout-script / scriptPubKey	Script	out-script length - many bytes

Security Characteristics

• Confidentiality: None. All information in the Bitcoin blockchain is public. Confidentiality is achieved by hashing data and placing it in the blockchain.

• Information Availability: Block mirroring. In general, all information is highly mirrored and available at all times. It may be true that some of the more recent information cannot be trusted until more block verifications are performed.

• Integrity: Multiple block verifications. Information is accurate given no blockchain forks. Integrity cannot be strongly trusted until at least 6+ verifications have been performed.

• Non-repudiation: Digital signatures. All transactions are digitally signed and are thus non-repudiable.

• Provenance: Transaction inputs and outputs. All transactions can be traced using block inputs and outputs.

• Pseudonymity: Public keys used as identifiers. All transactions use public keys as identifiers (not legal names or identifiers). Pseudonymity may be compromised via court orders to Bitcoin money transmitters.

• Selective Disclosure: None. All information in the Bitcoin blockchain is public. Selective disclosure could theoretically be achieved via symmetric key encryption, but due to the permanent nature of the Bitcoin blockchain and the impermanent nature of cryptographic protection, storing encrypted information directly on the Blockchain is ill advised.

Performance Characteristics

• Consistency: Multiple block verifications. Eventual consistency is guaranteed through multiple block verifications. Consistency of a freshly committed block cannot be highly trusted until between 30 to 60 minutes after the transaction.

• System Availability: Multiple block verifications. Transactions are not verified to a high degree of certainty until between 30 to 60 minutes after the transaction occurs.

• Failure Tolerance: Longest chain wins. Eventual consistency during arbitrary network partitioning. Mining allocation may cause one network partition to gain blocks at a faster rate than other partitions. In these cases, transactions are not very tolerant to failure depending on which network partition a transaction is written to.

• Scalability: Block size. Transaction speed is currently set at 7 transactions per second with a 1MB block size.

• Latency: Multiple block verifications. Transaction verifications take between 30 to 60 minutes after a transaction occurs to be verified. In May 2016, boot-up time for new nodes takes 1-3 days due to having to download 69GBs of data from peers and audit the blockchain.

Notable Features

• Proof of Work: Processing cycles must be expended in order to be able to write a new block to the blockchain.

• Bitcoin Script: A non-turing complete, Forth-like, stack-based scripting system, without support for loops is used for transaction inputs and outputs enabling some programmability for how transactions can be spent.

• Mining Rewards: To incentivize block verification, bounties are provided to miners that make securing the blockchain a profitable endeavor.

Ethereum

Data Structures

Account Format

Field	Description	Size
nonce	A scalar value equal to the number of transactions sent from this address or, in the case of accounts with associated code, the number of contract-creations made by this account.	32 bytes
balance	A scalar value equal to the number of Wei owned by this address.	32 bytes
storageRoot	A 256-bit hash of the root node of a Merkle Patricia tree that encodes the storage contents of the account (a mapping between 256-bit integer values), encoded into the trie as a mapping from the Keccak 256-bit hash of the 256-bit integer keys to the RLP-encoded 256-bit integer values.	32 bytes
codeHash	The hash of the EVM code of this account—this is the code that gets executed should this address receive a message call; it is immutable and thus, unlike all other fields, cannot be changed after construction. All such code fragments are contained in the state database under their corresponding hashes for later retrieval.	32 bytes

Message Transaction Format

Field	Description	Size
nonce	A 64-bit hash which proves combined with the mix-hash that a sufficient amount of computation has been carried out on this block	8 bytes
gasPrice	A scalar value equal to the number of Wei to be paid per unit of gas for all computation costs incurred as a result of the execution of this transaction.	32 bytes
gasLimit	A scalar value equal to the current limit of gas expenditure per block	32 bytes
to	The 160-bit address of the message call’s recipient or, for a contract creation transaction, ∅, used here to denote the only member of B0.	20 bytes
value	A scalar value equal to the number of Wei to be transferred to the message call’s recipient or, in the case of contract creation, as an endowment to the newly created account	32 bytes
v, r, s	Values corresponding to the signature of the transaction and used to determine the sender of the transaction	?
data	Only in non-contract messages. An unlimited size byte array specifying the input data of the message call.	unlimited
init	Only in contract messages.An unlimited size byte array specifying the EVM-code for the account initialisation procedure	unlimited
body	Only in contract messages. A fragment of code that executes each time the account receives a message call (either through a transaction or due to the internal execution of code)	unlimited

Receipt Format

Field	Description	Size
state	the post-transaction state	?
cumulativeGasUsed	the cumulative gas used in the block containing the transaction receipt as of immediately after the transaction has happened	?
logs	the set of logs created through execution of the transaction	?
logsBloom	the Bloom filter composed from information in those logs	?

Block Format

Field	Description	Size
parentHash	The Keccak 256-bit hash of the parent block’s header, in its entirety	32 bytes
ommersHash	The Keccak 256-bit hash of the ommers list portion of this block	32 bytes
beneficiary	The 160-bit address to which all fees collected from the successful mining of this block be transferred	20 bytes
stateRoot	The Keccak 256-bit hash of the root node of the state trie, after all transactions are executed and finalisations applied	32 bytes
transactionsRoot	The Keccak 256-bit hash of the root node of the trie structure populated with each transaction in the transactions list portion of the block	32 bytes
receiptsRoot	The Keccak 256-bit hash of the root node of the trie structure populated with the receipts of each transaction in the transactions list portion of the block	32 bytes
logsBloom	The Bloom filter composed from indexable information (logger address and log topics) contained in each log entry from the receipt of each transaction in the transactions list	?
difficulty	A scalar value corresponding to the difficulty level of this block. This can be calculated from the previous block’s difficulty level and the timestamp.	32 bytes
number	A scalar value equal to the number of ancestor blocks. The genesis block has a number of zero	32 bytes
timestamp	A scalar value equal to the reasonable output of Unix’s time() at this block’s inception	4 bytes?
extraData	An arbitrary byte array containing data relevant to this block. This must be 32 bytes or fewer	0-32 bytes
mixHash	A 256-bit hash which proves combined with the nonce that a sufficient amount of computation has been carried out on this block	32 bytes
ommerBlockHeaders	A list of ommer block headers (of the same format as everything above in this table)	?
transactions	a series of the transactions	?

Security Characteristics

• Confidentiality: None. All information in the Ethereum state machine is public. Confidentiality is achieved by hashing data and placing it in the blockchain or storing a pointer to off-chain data.

• Information Availability: Mirroring. In general, all non-generatable information is highly mirrored and available at all times. It may be true that some of the more recent information cannot be trusted until more block verifications are performed. There is also the possibility of not having to store all of the state machine transitions via a Simplified Payment Verification by only downloading the Patricia Merkle Tree block headers and verifying those, leading to light client implementations.

• Integrity: Multiple block verifications. Information is accurate given no long forks in the Merkle Patricia tree. Integrity cannot be strongly trusted until at least 7+ verifications have been performed.

• Non-repudiation: Digital signatures. All transactions are digitally signed and are thus non-repudiable.

• Provenance: Ethereum state machine and transition functions. All state machine transitions can be traced by replaying each state and set of inputs (both external and internal) to the Ethereum state machine.

• Pseudonymity: Random identifiers, transaction identifiers, or contract addresses may be used as identifiers each of them having a certain level of pseudonymity. Pseudonymity may be compromised via other data associated with the random identifier in the Ethereum state machine or court orders to Bitcoin money transmitters and/or BTC to ETH gateways.

• Selective Disclosure: None. All information in the Ethereum state machine is public. Selective disclosure could theoretically be achieved via symmetric key encryption, but due to the permanent nature of the Ethereum state machine transitions and the impermanent nature of cryptographic protection, storing encrypted information directly in the Ethereum state machine is ill advised.

Performance Characteristics

• Consistency: Multiple block verifications. Eventual consistency is guaranteed through multiple block verifications. Consistency of a freshly committed block cannot be highly trusted until between 6-10 confirmations (20-60 minutes after the first verification).

• System Availability: Multiple block verifications. Transactions are not verified to a high degree of certainty until between 20 to 60 minutes after the transaction occurs.

• Failure Tolerance: Longest chain wins. Eventual consistency during arbitrary network partitioning. Mining allocation may cause one network partition to gain blocks at a faster rate than other partitions. In these cases, transactions are not very tolerant to failure depending on which network partition a transaction is written to.

• Scalability: Block size, proof algorithm, and protocol GHOST and CASPER. Maximum transaction speed is currently around 7-10 transactions per second with a 1.7KB block size. Testnet has achieved 10-20 transactions per second. Predicted future rates range between 10,000 to 100,000 transactions per second.

• Latency: Multiple block verifications. Roughly 12-40 seconds to propagate a transaction to 95% of all nodes. Transaction verifications take between 20 to 60 minutes after a transaction occurs to be strongly trusted.

Notable Features

• Contracts with a Turing-complete Programming Language: Executable code that runs in the Ethereum state machine moving Ether and data around the state machine. Ethereum Virtual Machine is turing-complete, allowing any program to be written and executed.

• Asynchronous Multisignatures: Enables multi-signatures to be performed asynchronously vs. Bitcoins requirement for a synchronous multi-signature (all signatures must be submitted at the same time requiring out of band coordination).

• Gas Fees: Turing-complete languages create systems with halting problems (systems that could possibly execute a program forever - in an endless loop, for example). Gas fees enforce an upper-bound on Contract execution cost. Once a Contract’s gas runs out, it stops running, thus solving the halting problem in Ethereum.

Stellar

Data Structures

LedgerHeader Format

Field	Description	Size
ledgerVersion	The protocol version of the ledger	4 bytes
previousLedgerHash	Hash of the previous ledger header	32 bytes
scpValue	What consensus agreed to	808 bytes
txSetResultHash	The TransactionResultSet that led to this ledger	32 bytes
bucketListHash	Hash of the ledger state	32 bytes
ledgerSeq	Sequence number of this ledger	4 bytes
totalCoins	Total number of stroops in existence. There are 10,000,000 stroops in 1 Stellar (XLM) - 1 Stellar is the unit of currency (e.g. U.S. Dollars).	8 bytes
feePool	Fees burned since last inflation run	8 bytes
inflationSeq	Inflation sequence number	4 bytes
idPool	Last used global ID, used for generating objects	8 bytes
baseFee	Base fee per operation in stroops	4 bytes
baseReserve	Account base reserve in stroops	4 bytes
maxTxSetSize	Maximum size a transaction set can be	4 bytes
skipList	Hashes of ledgers in the past. allows you to jump back in time without walking the chain back ledger by ledger each slot contains the oldest ledger that is mod of either 50 5000 50000 or 500000 depending on index skipList[0] mod(50), skipList[1] mod(5000), etc.	128 bytes

Account Format

Field	Description	Size
accountID	Master public key for this account	32 bytes
balance	Account balance in stroops	8 bytes
seqNum	Last sequence number used for this account	8 bytes
numSubEntries	Number of sub-entries this account has drives the reserve	4 bytes
inflationDest	Account to vote for during inflation	8 bytes
flags	Flags set on issuer accounts. TrustLines are created with authorized set to "false" requiring the issuer to set it for each TrustLine. Values may be AUTH_REQUIRED_FLAG (if set, the authorized flag in TrustLines can be cleared), otherwise, authorization cannot be revoked and the flag is AUTH_REVOCABLE_FLAG. If AUTH_IMMUTABLE_FLAG is set, causes all AUTH_* flags to be read-only.	4-bytes
homeDomain	Can be used for reverse federation and memo lookup	32 bytes
thresholds	Stores unsigned bytes: [weight of master:low:medium:high]	4 bytes
signers	Possible signers for this account	36 bytes per signer (720 bytes total)

Transaction Format

Field	Description	Size
sourceAccount	Account used to run the transaction	32 bytes
fee	The fee the sourceAccount will pay	4 bytes
seqNum	Sequence number to consume in the account	8 bytes
timeBounds	Validity range (inclusive) for the last ledger close time	4 bytes (pointer to 16 byte data structure)
memo	Extra data carried along with the transaction.	0-32 bytes
operations	Up to 100 operations associated with this transaction.	8-N bytes (dependent on op code)

Security Characteristics

• Confidentiality: None. All information in the Stellar ledger is public. Confidentiality is achieved by hashing data and placing it in the blockchain or storing a pointer to off-chain data.

• Information Availability: Mirroring. In general, all non-generatable information is highly mirrored and available at all times. It may be true that some of the more recent information cannot be trusted until at least one block confirmation can be done, which is a great improvement over permissionless ledgers at the cost of having to trust a set of nodes in the network.

• Integrity: A single block verification. Information is accurate when a ballot produces a new block.

• Non-repudiation: Digital signatures. All transactions are digitally signed and are thus non-repudiable.

• Provenance: All transactions (instructions to the ledger) are digitally signed. A replay of all transactions results in a full understanding of a particular state’s provenance.

• Pseudonymity: Public keys are the primary identification mechanism in the system and provide a certain level of pseudonymity. Court orders to Stellar to fiat currency gateways can uncover the true identity of a person using the system.

• Selective Disclosure: None. All information in the Stellar ledger is public. Selective disclosure could theoretically be achieved via symmetric key encryption, but due to the permanent nature of the Stellar ledger and the impermanent nature of cryptographic protection, storing encrypted information directly in the Stellar ledger is ill advised.

Performance Characteristics

• Consistency: A single block verification. A single block verification can be propagated in a number of seconds (12 seconds on average to reach 95% of all nodes, up to 40 seconds to reach the other 5%).

• System Availability: A single block verification. Requests are typically answered in under a minute.

• Failure Tolerance: Stellar Consensus Protocol. As long as trust lines are allocated to maximize network connectivity, consensus will be achieved even in the event of multiple node failures and network partitions. If, for example, half of the network is separated from the other, the consensus protocol no longer works but the likelihood of an event of that nature is highly improbable.

• Scalability: Stellar Consensus Protocol. A single block can store 4 billion transactions, each with 100 transaction operations. The system is theoretically capable of performing thousands of transactions per second with the primary limiting factor being network speed and latency.

• Latency: A single block verification. A single block verification can be propagated in a number of seconds (12 seconds on average to reach 95% of all nodes, up to 40 seconds to reach the other 5%).

Notable Features

• Stellar Consensus Protocol: An algorithm with a mathematical proof of correctness for reaching consensus using quorum slices and assuming a certain level of network connectivity.

• Trust Lines: The consensus mechanism in Stellar requires that an entity running a node specify the other nodes in the system that it trusts. This design choice results in a much faster consensus algorithm (instead of using proof-of-work and proof-of-stake) with the drawback of making the system permissioned instead of permission-less.

IPFS

Data Structures

Object Merkle DAG - IPFSLink

Field	Description	Type
Name	Name or alias of link.	string
Hash	Cryptographic hash of target.	Multihash
Size	Total size of target.	int

Object Merkle DAG - IPFSObject

Field	Description	Type
links	Array of links.	Array of IPFSLinks
data	Opaque content data.	Array of bytes

Other

Merkle DAG (directed acyclic graph) structures can be used to build many types of other systems. Specialized structures exist for encrypted data, signed data, and a number of versioned file system primitives.

Security Characteristics

• Confidentiality: Hash-based obfuscation and encryption (limited confidentiality). All information in the DHT is available to the peer-to-peer network. Confidentiality may be achieved by using EncryptedObjects or storing a pointer to data outside of IPFS.

• Information Availability: Peer-to-peer mirroring. The DHT and Merkle DAG store data addressed by content hash. Various peer-to-peer strategies can be used to find, send, receive, and store data.

• Integrity: Hash-based content-addressing. Content is stored in a Merkle DAG and addressed by content hash. Individual data blocks can be verified for hash correctness. Completeness of all data depends on having a correct root with links to all data.

• Non-repudiation: Digital signatures. Data can be digitally signed and thus non-repudiable.

• Provenance: Digital signatures and data versioning. While not a core part of IPFS, these concepts could be layered on top to provide needed provenance features.

• Pseudonymity: Public keys. Nodes use identities built from public keys which could expose information about the person if cross-correlated. Data itself is opaque and addressed by content hash. Without a known hash it may be difficult to find and expose arbitrary data from the network.

• Selective Disclosure: None. All information in the DHT is public. Selective disclosure could theoretically be achieved via symmetric key encryption, but due to the permanent nature of the hashed data and the impermanent nature of cryptographic protection, storing encrypted information directly in the DHT is ill advised. Some protection is provided as it is unlikely unknown peers would request arbitrary data by its specific hash value.

Performance Characteristics

• Consistency: Peer-to-peer mirroring. Peer-to-peer network can be used to ensure consistency between all network peers of required immutable data.

• Failure Tolerance: The peer-to-peer network is resistant to failure when data is available from many peers and some network connectivity is available.

• Scalability: BitSwap peer-to-peer protocol is similar to protocols such as BitTorrent. Network topology, data locality, and BitSwap strategies that peers use will will have an effect on scalability.

Notable Features

• IPNS: Mutable naming system to compliment immutable IPFS objects. Allows for easier human naming and references.

• Flexible Components: Components of the system can be changed depending on performance, security, and other considerations. Standard interfaces allow for changing of naming, data exchange, routing, and network transport components.

Blockstack

Data Structures

Base Name Record Format

• name: the name itself

• value_hash: the hash of the name's associated profile

• sender: the scriptPubKey hex that owns this name (identifies ownership)

• sender_pubkey: (OPTIONAL) the public key

• address: the address of the sender

• block_number: the block number when this name record was created (preordered for the first time)

• preorder_block_number: the block number when this name was last preordered

• first_registered: the block number when this name was registered by the current owner

• last_renewed: the block number when this name was renewed by the current owner

• revoked: whether or not the name is revoked

• op: byte sequence describing the last operation to affect this name

• txid: the ID of the last transaction to affect this name

• vtxindex: the index in the block of the transaction.

• op_fee: the value of the last Blockstack-specific burn fee paid for this name (i.e. from preorder or renew)

• importer: (OPTIONAL) if this name was imported, this is the importer's scriptPubKey hex

• importer_address: (OPTIONAL) if this name was imported, this is the importer's address

Base Namespace Format

• namespace_id: human-readable namespace ID

• namespace_id_hash: hash(namespace_id,sender,reveal_addr) from the preorder (binds this namespace to its preorder)

• version: namespace rules version

• sender: the scriptPubKey hex script that identifies the preorderer

• sender_pubkey: if sender is a p2pkh script, this is the public key

• address: address of the sender, from the scriptPubKey

• recipient: the scriptPubKey hex script that identifies the revealer.

• recipient_address: the address of the revealer

• block_number: block number at which this namespace was preordered

• reveal_block: block number at which this namespace was revealed

• op: byte code identifying this operation to Blockstack

• txid: transaction ID at which this namespace was revealed

• vtxindex: the index in the block where the tx occurs

• lifetime: how long names last in this namespace (in number of blocks)

• coeff: constant multiplicative coefficient on a name's price

• base: exponential base of a name's price

• buckets: array that maps name length to the exponent to which to raise 'base' to

• nonalpha_discount: multiplicative coefficient that drops a name's price if it has non-alpha characters

• no_vowel_discount: multiplicative coefficient that drops a name's price if it has no vowels

Name Import Format

• NameRecordFields: All of the base Name Record Format fields

• recipient: scriptPubKey hex that identifies the name recipient

• recipient_address: address of the recipient

Namespace Preorder Format

• namespace_id_hash: hash(namespace_id,sender,reveal_addr)

• consensus_hash: consensus hash at the time issued

• op: bytecode describing the operation (not necessarily 1 byte)

• op_fee: fee paid for the namespace to the burn address

• txid: transaction ID

• vtxindex: the index in the block where the tx occurs

• block_number: block number at which this transaction occurred

• sender: scriptPubKey hex from the principal that issued this preorder (identifies the preorderer)

• sender_pubkey: if sender is a p2pkh script, this is the public key

• address: address from the scriptPubKey

Namespace Reveal Format

• NamespaceFields: All of the base Name Record Format fields

Namespace Ready Format

• NamespaceFields: All of the base Name Record Format fields

• ready_block: block number at which the namespace was readied

Name Preorder Format

• preorder_name_hash: hash(name,sender,register_addr)

• consensus_hash: consensus hash at time of send

• sender: scriptPubKey hex that identifies the principal that issued the preorder

• sender_pubkey: if sender is a pubkeyhash script, then this is the public key

• address: address from the sender's scriptPubKey

• block_number: block number at which this name was preordered for the first time

• op: blockstack bytestring describing the operation

• txid: transaction ID

• vtxindex: the index in the block where the tx occurs

• op_fee: blockstack fee (sent to burn address)

Name Registration Format

• NameRecordFields: All of the base Name Record Format fields

• recipient: scriptPubKey hex script that identifies the principal to own this name

• recipient_address: principal's address from the scriptPubKey in the transaction

Name Revoke Format

• NameRecordFields: All of the base Name Record Format fields

Name Transfer Format

• NameRecordFields: All of the base Name Record Format fields

• name_hash: hash(name)

• consensus_hash: consensus hash when this operation was sent

• keep_data: whether or not to keep the profile data associated with the name when transferred

Name Update Format

• NameRecordFields: All of the base Name Record Format fields

• name_hash: hash(name,consensus_hash)

• consensus_hash: consensus hash when this update was sent

Security Characteristics

• Confidentiality: None. All information in the Bitcoin blockchain and Blockstack virtualchain is public. Confidentiality could achieved by hashing data and placing it in either blockchain, but the system is not designed or intended to preserve confidentiality.

• Information Availability: Block mirroring. In general, all information is highly mirrored and available at all times. It may be true that some of the more recent information cannot be trusted until more block verifications are performed.

• Integrity: Multiple block verifications. Information is accurate given no blockchain forks. Integrity cannot be strongly trusted until at least 6+ verifications have been performed.

• Non-repudiation: Digital signatures. All transactions are digitally signed and are thus non-repudiable.

• Provenance: At the Bitcoin layer via transaction inputs and outputs; all transactions can be traced using block inputs and outputs. At the Blockstack layer each virtualchain entry can be traced back to the Bitcoin block it came from.

• Pseudonymity: Bitcoin: public keys are used as identifiers; Blockstack: pseudonyms in .id namespace. All Bitcoin transactions use public keys as identifiers (not legal names or identifiers). Pseudonymity may be compromised via court orders to Bitcoin money transmitters to determine who paid for particular inputs on Blockstack transactions. Blockstack entries in the .id namespace are pseudonyms, but publication of personally identifiable information is common practice typically leading to invalidation of pseudonymity.

• Selective Disclosure: Bitcoin: None; Blockstack: encrypted data at secret locations. All information in the Bitcoin blockchain and Blockstack virtual chain and storage layer is public. Selective disclosure could theoretically be achieved via symmetric key encryption, but due to the permanent nature of the Bitcoin blockchain and Blockstack virtualchain and the impermanent nature of cryptographic protection, storing encrypted information directly on the Bitcoin blockchain or on the Blockstack virtualchain/storage layer is ill advised. Blockstack profiles do have a mechanism where hashed information may be stored at known locations and where access may be provided to select entities with specific access keys.

Performance Characteristics

• Consistency: Multiple block verifications. Eventual consistency is guaranteed through multiple block verifications. Consistency of a freshly committed block cannot be highly trusted until between 30 to 60 minutes after the transaction.

• System Availability: Multiple block verifications. Transactions are not verified to a high degree of certainty until between 30 to 60 minutes after the transaction occurs.

• Failure Tolerance: Longest chain wins. Eventual consistency during arbitrary network partitioning. Mining allocation may cause one network partition to gain blocks at a faster rate than other partitions. In these cases, transactions are not very tolerant to failure depending on which network partition a transaction is written to.

• Scalability: Block size. Transaction speed is currently set at 7 transactions per second with a 1MB block size.

• Latency: Multiple block verifications. Transaction verifications take between 30 to 60 minutes after a transaction occurs to be verified.

Notable Features

• Fast Bootstrapping: Utilizes log checkpoints and skip lists to provide fast bootstrapping/auditing for new nodes in the network (called Simple Name Verification). Use of SNV provides new node bootup times of 1-2 hours vs. 2-4 days without SNV.

• Virtualchain: Layering a virtualized blockchain on top of an existing blockchain (e.g. Blockstack on top of Bitcoin)

• Separation of Control/Routing/Data planes: Separation of control plane (Bitcoin blockchain / Blockstack Virtualchain) from routing (DHT) from storage (S3, IPFS, etc.)

Hashgraph

Data Structures

No implementation of hashgraph was available, so the hashgraph datastructure, per the whitepaper is summarized below.

Gossip Event

The hashgraph consensus mechanism uses a gossip protocol. Whenever a member of the hashgraph receives new information, it chooses another member at random and communicates that information to it. This is called a “gossip event” and it is stored a sequence of bytes that is digitally signed by its creator.

• peer_id: The network identifier for the peer that was gossipped with.

• self_parent_hash: The hash of the last local event prior to this one.

• other_parent_hash: The hash of the peer’s last event prior to this one.

• payload: An optional list of transactions created in this event.

• timestamp: Date and time of event creation.

• key_identifer: Identifier for the key that can verify the digital signature.

• signature_algorithm: Algorithm for the digital signature.

• signature: The digital signature value.

Security Characteristics

• Confidentiality: None. All information in the hashgraph is public. Confidentiality could achieved by hashing data and placing only the hash in the hashgraph (within a transaction), but the system is not designed or intended to preserve confidentiality.

• Information Availability: Configurable. In general, all information is highly mirrored and available at all times. However, hashgraph can also be implemented such that only the effects of the transactions in a block need to be remembered, the transactions themselves can be destroyed. Another option uses signed states to allow events to be destroyed as well.

• Integrity: Consensus guaranteed with probability one and cannot be changed once reached. Once a transaction enters the system, it cannot be delayed and will be recorded in an order that cannot manipulated by individuals. Shortly after recording, due to the gossip protocol, every member will know the transaction’s place in history and that every other member also knows the same place.

• Non-repudiation: Digital signatures. All events/transactions are digitally signed and are thus non-repudiable.

• Provenance: The hashgraph is a history of all of the gossip events that occurred in the network, in the order they occurred. Every event can be traced back via ancestor hashes. However, the system also allows for event payloads to be discarded, which would disallow tracking of individual transactions. Another option also allows for events themselves to be destroyed via signed states.

• Pseudonymity: Identifiers for parties to the transactions are unspecified in the consensus algorithm. Pseudonymity could be implemented as a separate layer.

• Selective Disclosure: All information in the hashgraph is public and highly mirrored. Selective disclosure could theoretically be achieved via encryption, but due to the permanent nature of the hashgraph and the impermanent nature of cryptographic protection, storing encrypted information directly in the hashgraph event payloads is ill advised. The hashgraph consensus algorithm does allow the payloads to be destroyed with no influence upon the consensus algorithm, but the information would still have been made public and gossipped across the entire network.

Performance Characteristics

• Consistency: Eventual consensus guaranteed with probability one and cannot be changed once reached. Once a transaction enters the system, it cannot be delayed and will be recorded in an order that cannot manipulated by individuals. When members have different versions of the hashgraph, consensus is reached via virtual voting (zero bandwidth required) in a few minutes with no proof-of-work. Attackers must control less than one third of network.

• System Availability: Gossip protocol and virtual voting ensures quick success/failure indication. Eventual consensus guaranteed with probability one; forks are not possible under normal operation. Attackers cannot stop message recording other than by eliminating internet access. DoS Resistant without proof-of-work.

• Failure Tolerance: Strong Byzantine fault tolerance. Network will continue to function properly when up to just under one third of the members are attackers that collude, delete, or delay messages between honest members with no bounds on delays. Consensus algorithm is asynchronous, nondeterministic, and achieves Byzantine agreement with probability one.

• Scalability: Bandwidth. System is only limited by the amount of bandwidth available to its members. Using a few megabits per second (typical home connection) the network can support 4,000 transactions per second. Only 2-4% overhead added to messages for hashgraph protocol.

• Latency: Low. Virtual voting allows consensus to occur without network communication. Communication of the hashgraph via the gossip protocol has low overhead and gossip spreads exponentially amongst members. Events and transactions can be discarded if desired whilst preserving consensus state.

Notable Features

• Proof-of-stake: The voting power for each member does not have to be equal; members could be given more power based on trust, based on number of coins, or a system could allow power to be split when inviting new members.

• Signed State: Every time consensus is reached following a voting round, the state of the hashgraph can be considered immutable up to that round. This state can digitally signed and gossipped amongst members. Once more than two-thirds of the population have collected signatures, the information used to generate the state can be destroyed and the state can be used as a new starting point.

---

This document, a part of the "Credentials on Public/Private Linked Ledgers"
project, has been funded in part by the United States Department of Homeland
Security's Science and Technology Directorate under contract HSHQDC-16-C-00058.
The content of this document does not necessarily reflect the position or the
policy of the U.S. Government and no official endorsement should be inferred.