CRYPTO-applications: timestamping, archiving, blockchains, cryptocurrencies
DLT and blockchain
A distributed ledger is a ledger that is shared and synchronized, and distributed across a set of nodes.
It is designed to be tamper evident, append only and immutable containing confirmed transaction records
It can be implemented as a distributed datastore, or as a blockchain.
The two main schools are consortium-based (typically permissioned, used by e.g. Hyperledger Fabric) and
decentralised (typically permissionless, introduced in Bitcoin's Nakamoto consensus protocol).
Variations continue to emerge. The types of fault tolerated by the protocol are an important factor. Faults include crashes and subvertion of nodes, and Byzantine faults
(a fault presenting different symptoms to different observers). For the first school, the distinction can be made between crashes and subvertion of the special nodes (such as validators and ordeners)
and of the regular nodes. For the second school, there are only regular nodes to be considered.
Typical questions that must be answered by any consensus process:
- When deployed within a single enterprise, or operated by a trusted authority, a crash fault-tolerant (CFT) consensus protocol might be more than adequate.
- Alternatively, in a multi-party, decentralized use case, a byzantine fault tolerant (BFT) consensus protocol might be required. However, Byzantine fault tolerant consensus decreases performance and throughput.
The term trustlessness is sometimes used to refer to the property of not relying on trusting external parties for correct operation,
typically by enabling all parties to verify on their own that information is correct.
- Who will produce the next block of updates to apply to the database?
- When will the next block be produced?
- What transactions should be included in the next block?
- How are changes to the blockchain protocol applied?
- How should competing transaction histories be resolved?
Crash Fault Tolerant (CFT)
- Paxos is Lamport's family of non-BFT protocols for solving consensus in a network of unreliable processors
Roles are proposers, acceptors and learners. A participant may be a distinguished proposer (the only one to issue proposals) or a distinguished learner (where other learners will learn from).
A participant that is both a distinguished proposer and learner is called a leader.
Features are specified as safety (composed of non-triviality (any value learned must be proposed), stability (a learner can learn at most one value) and
consistency (two learners cannot learn different values)), as well as liveness (values will eventually be learned).
- Raft is an algorithm for managing a replicated log, using a stronger form of leadership than Paxos
- Implements consensus by first electing a distinguished leader, then giving the leader complete responsibility for managing the replicated log
- The leader accepts log entries from clients, replicates them on other servers, and tells servers when it is safe to apply log entries to their state
- Having a leader simplifies the management of the replicated log. For example, the leader can decide where to place new entries in the log
without consulting other servers, and data flows in a simple fashion from the leader to other servers.
- A leader can fail or be-come disconnected from the other servers, in which casea new leader is elected.
Byzantine Fault Tolerance (BFT)
BFT is an important quality of a consensus protocol. Consortium and quorum-based consensus protocols grew out of BFT research. For an overview refer to 'Implementing Trustworthy
Services Using Replicated State Machines' by Schneider and Zhou.
A Byzantine fault is any fault presenting different symptoms to different observers. Acquiring consensus under this condition requires significant overhead.
Requires O(n²) communications (OK for 10-100 nodes, not > 1000s. Studied since 1980s. Hyperledger Fabric v0.6 used PBFT, v1.0 used Kafka.
- BFT is addressed by the Lamport Shostak Pease protocol specified in the 1982 Byzantine Generals article
- PBFT - Castro-Liskov's Practical Byzantine Fault Tolerant consensus (1999), builds on Lamport's BFT and resembles Paxos
- Zyzzyva - Speculative Byzantine Fault Tolerance
- RBFT - Redundant BFT by Aublin
- Apache Kafka - ordening, used as ordener in Hyperledger Fabric
- Kafka is essentially a streaming platform with three key capabilities:
- Publish and subscribe to streams of records, similar to a message queue or enterprise messaging system
- Store streams of records in a fault-tolerant durable way
- Process streams of records as they occur
- Kafka is generally used for two broad classes of applications:
- Building real-time streaming data pipelines that reliably get data between systems or applications
- Building real-time streaming applications that transform or react to the streams of data
- BFT-SMaRT - OpenSource BFT
- Hyperledger Burrow is a permissioned Ethereum smart-contract blockchain node, executing EVM smart contract code
(usually written in Solidity) on a permissioned virtual machine, its based on a PoS and BFT Tendermint consensus engine
- Casper (by Buterin) is a partial consensus mechanism combining PoS research and BFT theory
- Juno was a BFT version of Raft (now discontinued)
- HotStuff BFT
- Leader based
- Casper and HotStuff exhibit similarity in protocol structure, embedding the protocol rounds into a (possibly branching) chain and deduce commit decisions by simple
offline analysis of the chains
- LibraBFT - based on HotStuff
- Istanbul BFT - EIP
- inspired by Castro-Liskov 99 paper, using proposers (PBFT)
- Istanbul BFT inherits from the original PBFT by using 3-phase consensus, PRE-PREPARE, PREPARE, and COMMIT. The system can tolerate at most of F faulty nodes in a N validator nodes network, where N = 3F + 1
- South African Reserve Bank (SARB), in partnership with ConsenSys Solutions and 7 commercial banks, utilized JP Morgan's Quorum, an Enterprise Ethereum solution in combination with Istanbul BFT, Pedersen commitments, and range proofs to process the typical daily volume of payments (70,000 transactions) for the South African Reserve Bank, with full confidentiality and finality, in less than two hours
- Dumbo BFT - Guo, Lu, Tang
Proof of Work (PoW)
Nakamoto Consensus (NC) is a protocol that implements a replication of a Blockchain using two ideas: proof of work (PoW) and a longest fork win (LFW) strategy:
It is BFT in the sense that it mitigates the double-spending attack where a participant would use the same coin twice to make a payment.
The double-spent can be seen as a deliberate byzantine fault.
- PoW implements a leader election oracle, based on lottery (but probability is influenced by mining power)
- LFW means non-faulty leaders will connect their pre-committed block to the leaf block which forms the longest path from the genesis block
Alternatives have emerged, including:
- NC POW for cryptocurrencies focuses on double spending attack (which is achieved through consensus)
- Bitcoin timestamping as nodes run on their local clock, only coarse timestamping is available
- Bitcoin NG uses PoW to elect a leader, which is then responsible for ordering the next K transactions
- GHOST the Greedy Heaviest-Observed Sub-Tree protocol, by Sompolinsky and Zohar, differs from Bitcoin in how it resolves the correct chain.
Instead of LFW, it follows the path of the subtree with the combined hardest proof of work/difficulty
Proof of Stake (PoS)
- POS - a set of validators take turns proposing and voting on the next block, and the weight of each validator's vote depends on the size of its deposit
- Chain-based PoS: the algorithm pseudo-randomly selects a validator during each time slot (e.g. 10 seconds), and assigns that validator the right to create a single block,
and this block must point to some previous block (normally the block at the end of the previously longest chain), and so over time most blocks converge into a single constantly growing chain
- BFT-style PoS: validators are randomly assigned the right to propose blocks, but agreeing on which block is canonical is done through a multi-round process where every validator sends a "vote" for some specific block
during each round, and at the end of the process all (honest and online) validators permanently agree on whether or not any given block is part of the chain. Note that blocks may still be chained together;
the key difference is that consensus on a block can come within one block, and does not depend on the length or size of the chain after it
- Ouroboros is a BFT PoS protocol used in Cardano
- Tendermint is a BFT PoS protocol, tolerating up to 1/3 of the machines failing arbitrarily (this includes explicitly malicious behaviour)
- Slasher (by Buterin) was a candidate PoS algorithm for Ethereum
- Casper (by Buterin) is a partial consensus mechanism combining PoS research and BFT consensus theory
- Casper is a family of PoS protocols, including Casper The Friendly Finality Gadget and the Friendly GHOST
Delegated Proof of Stake (dpos)
Under Delegated Proof-of-Stake (DPoS), the stakeholders can elect any number of witnesses to generate blocks.
A block is a group of transactions which update the state of the database.
Each account is allowed one vote per share per witness, a process known as approval voting.
The top N witnesses by total approval are selected. (N) is defined such that at least 50% of voting stakeholders believe there is enough decentralization. When stakeholders express a desired number of witnesses, they should also vote for at least that many.
A stakeholder cannot vote for more decentralization for which they actually cast votes.
Proof of Authority (PoA)
Authorized signers can at any time at their own discretion create new blocks. The challenges revolve around:
JPMorgan's Quorum was the first Ethereum Enterprise client that introduced three PoAs:
- how to control minting frequency
- how to distribute minting load (and opportunity) between the various signers
- how to dynamically adapt the list of signers
In Ethereum PoA was introduced in the Parity client, and in the Kovan testnet. A select group of trusted parties
(signers or validators) is responsible for maintaining a cluster of Ethereum nodes running PoA to verify blocks.
The validators will ensure that valid transactions are added to blocks, processed and executed by the EVM faithfully.
To ensure a sufficient degree of trust and redundancy, a minimum number of Consortium members should be recognised as being trusted members of the Ethereum/Blockchain community.
Servers should not be controlled by a single entity, but run individually by the consortium companies, preferably with servers located in multiple regions.
There is no difference in the way that contracts are executed compared to PoW.
- Raft is a CFT protocol with leader election
- Clique is an Ethereum PoA protocol
- IBFT 1.0 - by Yu-Te Lin, early 2017, implemented in Quorum by November 2017
- Raft is a CFT protocol with leader election
- etcd is a distributed key-value store using Raft
- Juno is a BFT version of Raft (discontinued)
- Parity PoA Aura
- each validator gets an assigned time slot in which they can release a block
- time slots are determined by the system clock of each validator
- Parity PoA
- Ethereum Kovan- testnet specification including PoA
- IBFT 1.0 - by Yu-Te Lin, early 2017, implemented in Quorum by November 2017
- Key driver of IBFT was to guarantee immediate finality, i.e. once a transaction is included in a block, it's guaranteed to always be part of the blockchain
- This means there are no forks (not inherently, not by malicious intent)
- IBFT 2.0- by Saltini, September 2019, implemented in Pantheon client
- Clique - specified as EIP 225
Proof of Elapsed Time (PoET)
- PoET used by Hyperledger Sawtooth, based on Intel's SGX TEE. So quite proprietary.
To create a block, a node needs to win a "lottery". Each node waits for a random amount of time. The first node who finishes waiting this amount of time is "elected" to create a block.
To be fair, this lottery requires that: the lottery winner choose a random waiting time, and the lottery winner finishes waiting this amount of time.
These requirements are satisfied thanks to a code run in a trusted execution environment.
Proof of Importance (PoI)
- NEM - Japanese smart asset blockchain, uses PoI (based on Eigentrust) as consensus
- EigenTrust - P2P reputation management system
Zero Knowledge in blockchains
- StarkWare - Eli Ben-Sasson et al
- proofs of computational integrity which are zero-knowledge, succinct (ref zkSNARK), transparent and post-quantum secure
- nuid.io - ZK proof generated on device for login
Privacy in blockchains
- MimbleWimble and Grin -
- Mimblewimble is a blockchain format and protocol that provides good scalability, privacy and fungibility by relying on strong cryptographic primitives.
- Grin implements a Mimblewimble blockchain and fills the gaps required for a full blockchain and cryptocurrency deployment.
eMoney and tokens
The terminology here is not yet cast in stone. De-facto, token types can be classified as:
- Payment Tokens are tokens that are accepted as payment. They may be recognized as legal tender or not. This includes cryptocurrencies such as bitcoins and its forks, as well as Central Bank Digital Currencies (CBDC), which are a digital form of central bank money that is different from balances in traditional reserve or settlement accounts
- Security tokens represent things deposited or pledged as a guarantee of the fulfilment of an undertaking or the repayment of a loan, which are to be forfeited in case of default
- Utility Tokens provide access, digitally, to an application or service by means of Blockchain based infrastructure
Overviews and research
- ITU DCGI - Digital Currency Global Initiative (with Stanford)
- ITU DCGI - Focus group on
- BIS - the moneyflower (a taxonomy of money) - analysis of cryptocurrencies in Annual Reports etc
- ECB - electronic money
- ITSA.global - International Token Standardization Association - International Token Identification Number (ITIN)
- eCurrency.net - solutions for Central Bank Digital Currency
- Ian Grigg - financial crypto, triple entry ledger, EOS, blockchain governance et al
- cryptoeconomics - Ethereum inspired
- Hugo Benedetti - research on crypto-marketplaces, digital tulips etc (suggestion from Harald S)
- Blocktivity - overview of blockchain activity rather than of investment
- One way to consider a blockchain project is through its market cap. Another way, closer to the real value, is observing the activity on the blockchain.
- Coinmarketcap - overview of digital currencies marketcap
- MapOfCoins - overview of digital currencies
Bitcoind was the first client, a full client that implements the Bitcoin protocol, operated from the command line, can send RPC-based commands
Bitcoin Core (aka Bitcoin-Qt) was written in C++, based on the reference code by Satoshi Nakamoto. Has been bundled with bitcoind since version 0.5 and can be considered to be a GUI front-end to bitcoind
Bitcoin and ecash mining and hashes
- Hashcash - POW algorithm, Adam Back, 1997, to fight spam
- Equihash - ASIC resistance, by Alex Biryukov and Dmitry Khovratovich
- ASICspace.com - hosting your miner
- Bitcoin ECC crypto - as per Certicom's secp256k1
- Bitcoin Core's secp256k1 implementation - Optimized C library for ECDSA signatures and secret/public key operations on curve secp256k1
- BIP 32 - HD hierarchical deterministic keys derived from seed
- HD wallets can be shared partially or entirely with different systems, each with or without the ability to spend coins.
- The specification is intended to set a standard for deterministic wallets that can be interchanged between different clients.
- Hierarchical deterministic wallets allow such selective sharing by supporting multiple keypair chains, derived from a single root.
- The specification consists of two parts:
- A system for deriving a tree of keypairs from a single seed, and
- how to build a wallet structure on top of such a tree.
- Bitcoin multisig
- Multisignature (multisig) refers to requiring multiple keys to authorize a Bitcoin transaction, rather than a single signature from one key.
- See Shamir's secret sharing m out of n
- NPMjs secp256k1 package - provides native bindings to bitcoin-core/secp256k1
- NPMjs jose package - covers:
Bitcoin forks, extensions and research
Software client forks, attempting to increase transaction capacity of the network. The majority hash power did not begin to use these clients. Therefore there was no consensus to change the rules.
- Bitcoin Core- the original reference implementation
- Bitcoin XT- increased blocksize, not well adopted
- Bitcoin Classic - fork of Bitcoin launched in 2016 with the aim to increase the block size limit, ceased operation in November 2017
- Bitcoin Unlimited - allows users to signal which block size limit they prefer, find the limit having a majority consensus and automatically track the largest POW, regardless of block size
- Bitcoin Cash- the first fork, August 2017
- Bitcoin Gold- purpose was to restore the mining functionality for common GPUs, instead of having to use ASICs, October 2017
- Bitcoin Private- optional ability to keep the sender, receiver, and amount private in a given transaction, merge of Bitcoin and Zclassic (a fork of ZcashZcash/zerocoin using Equihash), February 2018
- Litecoin Bitcoin fork with block generation time of 2.5 minute (instead of 10)
- Dogecoin Bitcoin fork with block generation time of 1 minute (instead of 10)
- Segregated Witness aka segwit
- Proposed in December 2015, segwit is an optimization proposal implemented in August 23, 2017, with the aim to improve performance
- Bitcoin trx have 2 main types of information contained within them: what sum is transferred from where to where, in the form of inputs and outputs,
and a proof that those transferences are authorized by the respective private key holders and they can be validly performed
- This last part is the Witness part, segwit removes this from the transaction, enables more transactions to be recorded to the blockchain and thus a higher transaction throughput i.e. separate signature data from txidentifier data
- Bitcoin Lightning - overlay network over existing blockchain to speed-up payments
- The idea is that not all transactions need to be recorded on the Blockchain
- If 2 people make multiple transactions between them there is no need to record all the transactions on the Blockchain
- A payment channel between these people can be created. The opening of this channel is recorded on-chain. Participants will transact through the payment channel (off-chain no blockchain transactions at this point) as much as they wish
- When participants decide to close the channel, only the final balance of the transactions will be recorded on-chain
- Cornell - HackingDistributed - Emin Gn Sirer
- Cornell - HackingDistributed - Miniature World criteria
- Princeton - Bitcoin IDE for Script
Spawned from Bitcoin
- Elements an open source, sidechain-capable blockchain platform with features such as Confidential Transactions and Issued Assets
- Elements - by Blockstream
- Elements - Github
Bitcoin and biometrics
Other coins and payments
Some are altcoins (bitcoin forks), some are colored coins (extending or coloring bitcoins with further properties, turning
them into tokens which can represent anything(e.g. shares of a company, deposits of physical material, etc)
Colored coins work as an \93overlay\94 network on top of the traditional Bitcoin network.
State issued - Central Bank Digital Currencies (CBDC)
- Monerium - licensed in Iceland
- J-coin- Mizuho bank et al
- Zerocoin - code fork of bitcoin aimed to enhance the privacy of Bitcoin payments by disabling the deduction of user identities from their payment patterns/habits
through ZK-proofs, this comes at the price of additional delay as it requires storing its proofs in the blockchain -significant time taken by nodes to verify the proofs
- Zcash - extends the zerocoin ideas further as another code fork of bitcoin which maintains its own blockchain and currency token, uses zero-knowledge proofs and also includes some non-privacy changes to bitcoin, including its proof of work algorithm
- strong scientific board
- application of zk-SNARKs, shielded transactions in Zcash can be fully encrypted on the blockchain, yet still be verified as valid under the network\92s consensus rules by using zk-SNARK proofs
- zk-SNARK stands for \93Zero-Knowledge Succinct Non-Interactive Argument of Knowledge\94
- Electric Coin Company - inventors of Zcash
- Zcash docs
- Facebook Libra
- Stellar open-source distributed payments client, currency of choice, no mining, Lumen as internal token
- Stellar consensus federated BFT
- KodakCoin for digital asset management of e.g. pictures
- Lykke coin (CH)
- Monero - private money (at least that's their claim)
- Raiden- near-instant, low-fee and scalable payments
Are blockchains completely independent from the main bitcoin blockchain, allowing bitcoin or other assets to be transferred between blockchains.
Coins are sent to a special address so they are frozen (but not leaving the network),
and when a tx is confirmed the bitcoin owner sends a message to the sidechain containing verification of ownership,
upon which the sidechain creates an equal amount of pegged bitcoins (or other specified tokens) and sends them to the owner
(who can spend them in the sidechain under the sidechain rules)
- Ricardian contracts - original application was a bond trading system
- Ricardian contracts - seminal Systemics description
- As bonds are, at their essence, contracts between issuers and users, our problem reduces to one of issuing contracts. Whereas other issues have contracts, our issues are contracts.
Our innovation is to express an issued instrument as a contract, and to link that contract into every aspect of the payment system. By this process, a document of some broad utility (readable by user and program) is drafted and digitally signed by the issuer of the instrument. This document, the Ricardian Contract, forms the basis for understanding an issue and every transaction within that issue.
By extension, all issues of value, such as currencies, shares, derivatives, loyalty systems and vouchers, can benefit from this approach.
- Szabo - smart contracts
In a nutshell
Ethereum runs on the Ethereum main P2P network, which is addressable on TCP port 30303.
The consensus rules are defined in the reference specification, the Yellow Paper.
Ethereum supports two types of account: Externally Owned Accounts (EOA) and Contract Accounts (CA). EOAs are under
user control through a private key, and can send Ether and messages. CAs consist of code.
Action is triggered by an EOA sending a message to another user. This can transfer Ether to another EOA, or it can have a contract as recipient,
which will then execute. A contract can read the storage of the received message, can read/write to its own internal storage and can send messages
to other contracts. Typical usage of contract is:
Ethereum transactions are network messages that include (among other things) a sender, recipient, value, and data payload.
There are two types of transactions: contract creating transactions and sending transactions.
Ethereum state transitions are processed by the Ethereum Virtual Machine (EVM), a stack-based virtual machine that executes bytecode (machine-language instructions). EVM programs, called "smart contracts," are written in high-level languages (e.g., Solidity) and compiled to bytecode for execution on the EVM.
Ethereum\92s state is stored locally on each node as a database (usually Google\92s LevelDB), which contains the transactions and system state in a serialized hashed data structure called a Merkle Patricia Tree.
- maintain data value
- serve as an EOA with a more complicated access control policy, referred to as a 'forwarding contract'
- serve as a contract between multiple parties
- serve as a software library to other contracts
Ethereum originally used Bitcoin\92s consensus model, Nakamoto Consensus, which uses sequential single-signature blocks, weighted in importance by PoW to determine the longest chain and therefore the current state. However, there are plans to move to a PoS weighted voting system, codenamed Casper, in the near future.
Ethereum's first mining algorithm was Dagger Hashimoto, combining ideas from:
The difference between Dagger Hashimoto and Hashimoto is that, instead of using the blockchain as a data source, Dagger Hashimoto uses a custom-generated 1 GB data set,
which updates based on block data every N blocks. The data set is generated using the Dagger algorithm, allowing for the efficient calculation of a subset
specific to every nonce for the light client verification algorithm.
The difference between Dagger Hashimoto and Dagger is that, unlike in the original Dagger, the dataset used to query the block is semi-permanent,
only being updated at occasional intervals (eg. once per week).
Currently a PoW algorithm called Ethash is used, but this will eventually be dropped with the move to PoS at some point in the future.
Ethereum deliberately makes mining more memory intensive as time goes on. Every 30 000 blocks, a new piece of data (a DAG) is used for mining new blocks.
Each new group of 30 000 blocks is known as an epoch. And epoch switch is when the next DAG is loaded.
- Hashimoto, an algorithm by Thaddeus Dryja which intends to achieve ASIC resistance by being IO-bound, ie. making memory reads the limiting factor in the
- Dagger, an algorithm by Vitalik Buterin which uses directed acyclic graphs to simultaneously achieve memory-hard computation but memory-easy validation.
The core principle is that each individual nonce only requires a small portion of a large total data tree,
and recomputing the subtree for each nonce is prohibitive for mining (hence the need to store the tree) but okay for a single nonce's worth of verification.
- Ethereum 1.0 or ETH 1.x is the name for a collection of upgrades to the existing Ethereum protocol.
The goal is to continue to improve and maintain Ethereum while ETH 2.0 is developed and implemented.
- Ethereum\92s development was planned over four distinct stages, with major changes occurring at each stage.
A stage may include subreleases, known as "hard forks," that change functionality in a way that is not backward compatible.
The four main development stages are codenamed Frontier, Homestead, Metropolis, and Serenity.
The intermediate hard forks that have occurred (or are planned) to date are codenamed
Ice Age, DAO, Tangerine Whistle, Spurious Dragon, Byzantium, and Constantinople.
Both the development stages and the intermediate hard forks are shown on the following timeline, which is "dated" by block number:
- Block #0 Frontier\97The initial stage of Ethereum, lasting from July 30, 2015, to March 2016.
- Block #200,000 Ice Age\97A hard fork to introduce an exponential difficulty increase, to motivate a transition to PoS when ready.
- Block #1,150,000 Homestead\97The second stage of Ethereum, launched in March 2016.
- Block #1,192,000 DAO\97A hard fork that reimbursed victims of the hacked DAO contract and caused Ethereum and Ethereum Classic to split into two competing systems.
- Block #2,463,000 Tangerine Whistle\97A hard fork to change the gas calculation for certain I/O-heavy operations and to clear the accumulated state from a
denial-of-service (DoS) attack that exploited the low gas cost of those operations.
- Block #2,675,000 Spurious Dragon\97A hard fork to address more DoS attack vectors, and another state clearing. Also, a replay attack protection mechanism.
- Block #4,370,000 Metropolis Byzantium\97Metropolis is the third stage of Ethereum, launched in October 2017.
Byzantium is the first of two hard forks planned for Metropolis.
- After Byzantium, there is one more hard fork planned for Metropolis: Constantinople.
- Metropolis will be followed by the final stage of Ethereum\92s deployment, codenamed Serenity (ETH 2.0).
- Ethereum 2.0, ETH 2.0 (also known as \93Serenity\94) refers to the next major upgrade of the core Ethereum protocol.
It combines several improvements to Ethereum\92s core protocol, or \93Layer 1\94. In ETH 2.0, Ethereum will be moving to \93Proof of Stake\94.
- Ethereum wiki
- Ethereumbook in asciidoc, online
- Ethereum documentation
- Ethereum definition public private consortium
- Public blockchains: a public blockchain is a blockchain that anyone in the world can read, anyone in the world can send transactions to and expect to see them included if they are valid, and anyone in the world can participate in the consensus process \96 the process for determining what blocks get added to the chain and what the current state is. As a substitute for centralized or quasi-centralized trust, public blockchains are secured by cryptoeconomics \96 the combination of economic incentives and cryptographic verification using mechanisms such as proof of work or proof of stake, following a general principle that the degree to which someone can have an influence in the consensus process is proportional to the quantity of economic resources that they can bring to bear. These blockchains are generally considered to be \93fully decentralized\94.
- Consortium blockchains: a consortium blockchain is a blockchain where the consensus process is controlled by a pre-selected set of nodes; for example, one might imagine a consortium of 15 financial institutions, each of which operates a node and of which 10 must sign every block in order for the block to be valid. The right to read the blockchain may be public, or restricted to the participants, and there are also hybrid routes such as the root hashes of the blocks being public together with an API that allows members of the public to make a limited number of queries and get back cryptographic proofs of some parts of the blockchain state. These blockchains may be considered \93partially decentralized\94.
- Private blockchains: a fully private blockchain is a blockchain where write permissions are kept centralized to one organization. Read permissions may be public or restricted to an arbitrary extent. Likely applications include database management, auditing, etc internal to a single company, and so public readability may not be necessary in many cases at all, though in other cases public auditability is desired.
- Ethereum blog
- Ethereum blog 2018 EF Grants (state channels, plasma, ...)
- Github Ethereum main entry point
- Github Ethereum main wiki
- Ethereum audit report by Least Authority March 2020
- ERC20 - Ethereum Token Standard, fungible (every token is the same as every other token)
- ERC721 - non-fungible (unique) token standard
- ERC-721 started as a EIP draft written by @dete and first came to life in the CryptoKitties project by Axiom Zen
- Ethereum EIPs- Ethereum Improvement Proposals
- Ethereum EIPs on github
- EIP20- Ethereum Request for Comment 20 Token format,
functionality for token transfer and spending by an on-chain third party
- EIP1056- Ethereum Request for Comment 1056
A registry for key and attribute management of lightweight blockchain identities.
- Describes creating and updating identities with a limited use of blockchain resources.
An identity can have an unlimited number of delegates and attributes associated with it.
Identity creation is as simple as creating a regular key pair ethereum account, which means that it's free (no gas costs)
and all ethereum accounts are valid identities. Furthermore this ERC is fully DID compliant.
- Ethash - Ethereum's POW consensus algorithm
- an evolution of the Dagger\96Hashimoto algorithm, which is a combination of Vitalik Buterin\92s Dagger algorithm and Thaddeus Dryja\92s Hashimoto algorithm
- Ethash - explained in Ethereumbook
- Casper is the proposed name for Ethereum\92s PoS consensus algorithm. It is still under active research and development
and is not implemented on the Ethereum blockchain at the time of publication of the Ethereumbook. Casper is being developed in two competing "flavors":
- Casper FFG: "The Friendly Finality Gadget"
- Casper CBC: "The Friendly GHOST/Correct-by-Construction"
- Olympic testnet - launched May 2015
- Morden - first Ethereum testnet, expected to continue throughout the Frontier and Homestead era \96Morden fork occurred on Nov-20-2016
- Ropsten \96 second Ethereum testnet, until Feb 2019
- G\F6rli - a cross-client PoA Ethereum testnet
- Mainnet readiness
- Release Step One: Frontier - launched 30 July 2015
- Release Step Two: Homestead - launched 14 March 2016 (Pi Day)
- Release Step Three: Metropolis - TBA
- Release Step Four: Serenity \96 TBA \96 Spurious Dragon hardfork?
Ethereum block explorers
Ethereum application building blocks
There are Dapps, full clients, remote clients and wallets.
Distributed applications (Dapps)
- The frontend is usually linked to the Ethereum backend via web3.js, which is bundled with the frontend resources and served to a browser by a web server.
- Data storage
- Most DApps utilize off-chain data storage services, meaning they store the bulky data off the Ethereum chain, on a data storage platform.
That data storage platform can be centralized (for example, a typical cloud database), or the data can be decentralized, stored on a P2P platform such as the IPFS, or Ethereum\92s own Swarm platform.
- Smart contracts store the business logic and the state of the application. A smart contract replaces the 'server-side' (aka "backend") component in a regular application.
- Exposes RPC such as JSON-RPC API.
- Inter-process communication
- IPC allows to exchange messages between applications, between different instances of the application, or between users of the application. The most notable P2P messaging protocol for DApps is Whisper, which is part of the Ethereum Foundation\92s Go-Ethereum suite of tools.
- Name resolution - ENS
- ENS is a distributed DNS. The Ethereum Foundation donation address is 0xfB6916095ca1df60 bB79Ce92cE3Ea74c37c5d359; in a wallet that supports ENS, it\92s simply ethereum.eth.
- ENS is supported by a number of DApps for registration, management, and auctions of registered names
- ENS is specified mainly in three Ethereum Improvement Proposals: EIP-137, which specifies the basic functions of ENS; EIP-162, which describes the auction system for the .eth root; and EIP-181, which specifies reverse registration of addresses.
- Bottom layer: ENS operates on "nodes" instead of human-readable names: a human-readable name is converted to a node using the "Namehash" algorithm (Keccak based). The basic ENS contract can\92t add metadata to names; that is the job of so-called "resolver contracts." These are user-created contracts that can answer questions about the name,
such as what Swarm address is associated with the app, what address receives payments to the app (in ether or tokens), or what the hash of the app is (to verify its integrity).
- Middle Layer: .eth nodes. The .eth domains are distributed via an auction system.
- Top Layer: the Deeds. Is a simple contract with a single purpose: to hold the funds.When you win a name, the funds are not actually sent anywhere, but are just locked up for the period you want to hold the name (at least a year).
This works like a guaranteed buyback: if the owner does not want the name any more they can sell it back to the system and recover their ether (so the cost of holding the name is the opportunity cost of doing something with a return greater than zero).
Having a single contract hold millions of dollars in ether has proven to be risky, so ENS creates a deed contract for each new name. The deed contract is simple (about 50 lines of code), and it only allows the funds to be transferred back to a single account (the deed owner)
and to be called by a single entity (the registrar contract).
These run a full node and contain a local copy of the blockchain and perform validation. The most common full clients are Parity and Geth. A full node must download 80\96100 GB of data (as of September 2018, depending on the client configuration) and store it on a local hard drive.
A full node running on a live mainnet network is not necessary for Ethereum development.
You can do almost everything you need to do with a testnet node (which connects you to one of the smaller public test blockchains), with a local private blockchain like Ganache, or with a cloud-based Ethereum client offered by a service provider like Infura.
- Pantheon client - PegaSys
- Pantheon 1.0
- compliant with most of the permissions requirements of the EEA v2.0 spec
- Node permissions via a whitelist allow a node to restrict which other nodes it is willing to peer with and is provided off-chain,
which means each node has its own whitelist of nodes. It can be observed a node does not control who other nodes peer with.
- account permissions limit which accounts a node accepts transactions from, implemented via a whitelist of allowed accounts, maintained at each node
- Pantheon 1.1 (April 2109) has smart contract permissions
- meaning a whitelist enforces which accounts can transact, implementing a 'public permissioned' model (as also chosen by the EBP)
- Pantheon 1.2, compliant to the EEA v3 specifications
- After Pantheon 1.2.3 it was renamed Besu in September 2019
- Pantheon 1.3 was originally announced for Q4 of 2019, should include RBAC
- Besu open-source Ethereum client, part of Hyperledger, previously known as Pantheon
- Besu Architecture
- Besu docs
- Besu 1.2, July 31, 2019
- Besu 1.3, October 07, 2019
- runs on the Ethereum public network, private networks, and test networks such as Rinkeby, Ropsten, and G\F6rli (/li>
- includes a CLI and JSON-RPC API for eth, net, web3, debug, etc
- API can be used via RPC over HTTP or via WebSockets, and Pub/Sub is supported
- supports smart contract and Dapp development/deployment and operational use cases, using Truffle, Remix, and web3j
- doesn\92t support key management, but EthSigner can be used with Besu to provide access to your key store and sign transactions
- EthSigner can sign transactions with a key stored in a V3 keystore file stored on a file system accessible by the host, a Hashicorp Vault and an Azure Key Vault
- Besu source - github
- Besu doc - besu.hyperledger.org
Remote clients and wallets
The terms "remote client" and "wallet" are used interchangeably, though there are some differences. Usually, a remote client
Do not confuse the concept of a remote wallet in Ethereum with that of a light client (which is analogous to a Simplified Payment Verification client in Bitcoin).
Light clients validate block headers and use Merkle proofs to validate the inclusion of transactions in the blockchain and determine their effects, giving them a similar level of security to a full node. Conversely, Ethereum remote clients do not validate block headers or transactions.
They entirely trust a full client to give them access to the blockchain, and hence lose significant security and anonymity guarantees.
- offers an API (such as the web3.js API) in addition to the transaction functionality of a wallet
- does not store a local copy of the blockchain or validate blocks and transactions
- can connect to existing networks such as your own full node, a public blockchain, a public or permissioned testnet, or a private local blockchain
Three types of nodes:
- Metamask.io - part of Consensys ('a Consensys Formation')
- Metamask browser extension for Firefox and Chrome
- lets the user create and manage identities (via private keys, local client wallet and hardware wallets like Trezor), so when a Dapp wants to perform a transaction and write to the blockchain, the user gets a secure interface to review the transaction, before approving or rejecting it
- Metamask doc
- Using Metamask and Solidity - tutorial Karl Floersch
- Metamask Github
- Metamask Github
- Metamask audit report by Least Authority
For general information see wallets. Ethereum wallets include:
- ethers - an collection of Libraries, Web Tools, Command-Line Utilities and
Server Components to assist in the development, deployment, hosting and sharing of Ethereum applications.
- includes scrypt for key derivation
- ethers.js documentation - further
- Gnosis - founded 2015 as part of Consensys, spun out in 2017
- MEW - MyEtherWallet
- full Web App wallet, running without any add-on on Mobile/Desktop/Laptop Browser
- supports KeyStoreFile, Private Key Import and Mnemonic Phrase
- on desktop also supports hardware ledger wallet to store private key
- MEW GitHub
- Emerald Wallet
- ConsenSys Ethereum development, founded by Joseph Lubin, started in Brooklyn, US
- Products include:
- Codefi - blockchain application suite for commerce and finance
- MetaMask - crypto wallet and gateway to blockchain dApps - also MetaMask Instiutional for institutions
- Diligence - security audits for Ethereum blockchain smart contract
- Quorum - complete open source blockchain protocol for business
- Infura - instant, scalable API access to the Ethereum and IPFS networks
- Truffle - development environment and testing framework for Ethereum smart contracts
- Ethereum development - Consensys
- Ethereum development tools overview - on Github by Consensys
- Ethereum book:
- Pegasys Ethereum development
- Solidity - language documentation
- Remix - Ethereum development using your browser
- Remix Ide - documentation
- Truffle framework - Ethereum development (Truffle, Ganache, Drizzle)
- Infura.io - instant, scalable API access to the Ethereum and IPFS networks
Ethereum Enterprise Alliance
DAO - Slock.it - DAO led to Ethereum hard fork
Ethereum management and stats
- Aleth.io - Ethereum analytics
- ethPM - Ethereum Package Manager - an 'immutable' package manager
- At its core, an ethPM package is a JSON object containing the ABI, source code, bytecode, deployment data and
any other information that combines together to compose the smart contract idea.
The ethPM specification defines a schema to store all of this data in JSON format, enabling transportation of smart contract
ideas between tools and frameworks which support the specification.
- A registry is an on-chain datastore containing the data for released ethPM packages.
Unlike traditional package managers which maintain a single, centralized package registry (eg. NPM, pypi)
ethPM uses a federated model where everybody is required to deploy and maintain their own, permissioned package registry
- An ethPM package is a combination of 3 elements that represent an immutable smart contract idea
and are stored on-chain in an ethPM registry:
- Package name
- Package version
- Content-Addressed URI (any URI that contains a cryptographic hash ensuring the identity of its contents and
that the contents have not been modified. For example on ipfs://Qme4otpS88NV8yQi8TfTP89EsQC5bko3F5N1yhRoi6cwGV )
- The package manifest is the JSON file stored at the content-addressed URI, containing the actual JSON file
which defines an ethPM package
- These three elements are stored on-chain in an ethPM registry
- The registry API (ERC1319) enforces that once a package is released, it can never be re-released
- Ethereum privacy - Orion
- Orion is an open-source private transaction manager, primarily intended for Besu
- developed under the Apache 2.0 license and written in Java
Tendermint and Cosmos
- Tendermint: a BFT and POS general purpose blockchain consensus engine that can host arbitrary application states,
can be used as a plug-and-play replacement for the consensus engines of other blockchain software
- created by "All in Bits, Inc", which also does business as "Tendermint, Inc.", a Delaware for-profit corporation
- can replicate deterministic state machines written in any programming language
- Byzantine fault-tolerant consensus protocol that is inspired by the consensus model used for mainstream distributed databases
- according to the doc: "Tendermint is broadly similar to two classes of software. The first class consists of distributed key-value stores,
like Zookeeper, etcd, and consul, which use non-BFT consensus. The second class is known as "blockchain technology", and consists of both
cryptocurrencies like Bitcoin and Ethereum, and alternative distributed ledger designs like Hyperledger's Burrow"
- the Cosmos network is an example of a cryptocurrency application built on Tendermint
- Cosmos Network:
- Cosmos development is supported by the Interchain Foundation (ICF), a Swiss foundation
- Cosmos introduces the concept of \91zones\92 (= sidechains), where you can spin up as many sidechains as you need when any one of your chains hit capacity.
Currently, a Cosmos zone can accommodate a throughput of 1000 transactions per second thanks to being powered by the Tendermint consensus engine. When your zone hits its limit, you could simply spawn a second zone, and so on. Zones are aware of one another and can communicate through IBC.
- Hyperledger.org - a Linux Foundation Collaborative Project - blockchain explorer/fabric/sawtooth lake/...
Permissioned, based on deterministic ordering rather than probabilistic consensus, with channels between participants, multi-sig, originally max 100 nodes.
Uses CouchDB (to store ledger plus World State and Private Data Collection).
Hyperledger Fabric users often use the terms smart contract and chaincode interchangeably.
In general, a smart contract defines the transaction logic that controls the lifecycle of a business object contained in the world state.
It is packaged into a chaincode which is deployed to a blockchain network.
Smart contracts govern transactions, whereas chaincode governs how smart contracts are packaged for deployment.
A smart contract programmatically accesses two distinct pieces of the ledger:
- Client is written in Node.js or Java, uses Fabric SDK to send an transaction-invocation to the endorsers, and broadcasts transaction-proposals to the ordering service.
- regular peer commits transactions and maintains the state and a copy of the ledger
- endorsing peer with respect to a particular chaincode means the peer can endorse a transaction before it is committed
- Orderer: a node running the communication service that implements a delivery guarantee, such as atomic or total order broadcast.
Smart contracts primarily put, get and delete states in the world state, and can query the immutable blockchain record of transactions.
- a blockchain, which immutably records the history of all transactions, and
- a world state that holds a cache of the current value of these states (in CouchDB), as it's the current value of an object that is usually required.
Smart contracts have many APIs available to them. In all cases, whether transactions create, read, update or delete
business objects in the world state, the blockchain contains an immutable record of these changes.
Associated with every chaincode is an endorsement policy that applies to all of the smart contracts defined within it. An endorsement policy indicates which organizations in a blockchain network must sign
a transaction generated by a given smart contract in order for that transaction to be declared valid.
- A get typically represents a query to retrieve information about the current state of a business object.
- A put typically creates a new business object or modifies an existing one in the ledger world state.
- A delete typically represents the removal of a business object from the current state of the ledger, but not its history.
- Hyperledger - Fabric project
- v0.6.0-preview, 2016
- v1.0.0 Kafka ordering as consensus, 2017
- v1.1.0 Kafka 2018
- v1.2.0 Kafka 2018
- v1.3.0 Kafka 2018
- v1.4.1 introduced Raft as CFT ordering service based on an implementation of Raft protocol in etcd.io. Raft follows a \93leader and follower\94 model,
where a leader node is elected (per channel) and its decisions are replicated to the followers
- v2.2 as used by EBSI V2.0
- Hyperledger - Fabric- documentation, all versions
- Hyperledger - Fabric v1.1- client-side SDK's for Node.js and Java - APIs to:
- create channels
- ask peer nodes to join the channel
- install chaincodes in peers
- instantiate chaincodes in a channel
- invoke transactions by calling the chaincode
- the Fabric API putState() writes an object such as a commercial paper as state data in the ledger
- query the ledger for transactions or blocks
- Hyperledger - built-in CA- for Membership Service
- Fabric Jira
- Chaincoder - new kid on the block - not yet full-featured, uses Go for chaincode
Hyperledger Sawtooth Lake
- Hyperledger - Indy - purpose-built for decentralized identity, used e.g. in Self-Sovereign Identity applications
W3C self-sovereign identity and DID
EU eSSIF lab
- Sovrin.org (rooted in Evernym) - the Sovrin Foundation is a private-sector, international non-profit established to govern the world's first self-sovereign identity (SSI) network
- in SSI, an "Identity Owner shall have the right to completely and permanently own and control one or
more Sovrin Identities without the need to rely on any external administrative authority and without the fear that a Sovrin Identity will ever be taken away"
- Sees a blockchain as a decentralised self-service registry of public keys, where every key can have its own address, called a DID or Decentralised Identifier
- DID is stored on a blockchain along with a DID document containing the public key for the DID, any other public credentials the identity owner wishes to disclose,
and the network addresses for interaction. The identity owner controls the DID document by controlling the associated private key.
- Sovrin relies on Hyperledger Indy (based on Evernym), which has its own distributed ledger called Plenum, based on Redundant BFT
- Has two rings of nodes:
- ring of validator nodes to accept write transactions, and
- much larger ring of observer nodes running read-only copies of the blockchain to process read requests
- The ledger is intended to store Identity Records that describe a Ledger Entity. Identity Records are public data and may include Public Keys, Service Endpoints, Credential Schemas, and Credential Definitions.
Every Identity Record is associated with exactly one DID that is globally unique and resolvable (via a ledger) without requiring any centralized resolution authority. To maintain privacy each Identity Owner can own multiple DIDs.
- DID types:
- Verinyms, associated with the Legal Identity of the Identity Owner, and
- Pseudonyms - a Blinded Identifier used to maintain privacy in the context of an ongoing digital relationship.
If the Pseudonym is used to maintain only one digital relationship it is called a Pairwise-Unique Identifier.
- Sovrin library
- Sovrin Github
- Hyperledge Indy - Sovrin's basis
- Hyperledge Indy Plenum - Sovrin's basis
- BLS signatures - Boney, Lynn, Shacham
- Verifiable Organisations Network - vonx.io - based on Sovrin, by Canadian governments
- BCgov vonx github
- BCgov vonx issuer/verifier function
- Evernym - roots of Sovrin
- contributed to W3C credentials and did specs
- contributed to HyperLedger Indy- decentralised identity
- contributed to HyperLedger Ursa - common cryptolibrary (and interface to OpenSSL)
- contributed to HyperLedger Aries- interoperable cross-ledger SSI digital wallets and agents.
- Peer DID - Evernym
- Ethereum Light-weight IDentity - EIP 1056, A registry for key and attribute management of lightweight blockchain identities.
Identity creation is as simple as creating a regular key pair ethereum account,
which means that it's fee (no gas costs) and all ethereum accounts are valid identities. Furthermore this ERC is fully DID compliant.
- uport.me - Open Identity Infrastructure based on Ethereum, backed by Consensys, based in NY, US
- Libraries: uPort Connect (single sign-on and transaction signing for your client-side app), and uPort JS (request, sign, and issue credentials from your app server)
- Tools: EthrDID, EthrDID Registry (smart contract that enables the resolution and management of decentralized identifiers (DIDs)
- uport ethr-did
This library conforms to ERC-1056 and is intended to use Ethereum addresses as fully self-managed Decentralized Identifiers (DIDs), it allows you to easily create and manage keys for these identities. It also lets you sign standards compliant JSON Web Tokens (JWT) that can be consumed using the DID-JWT library.
This library can be used to create a new ethr-did identity. It allows ethr-did identities to be represented as an object that can perform actions such as updating its did-document, signing messages, and verifying messages from other dids.
A way to start using ethr-did identities, and want high-level abstractions to access its entire range of capabilities.
It encapsulates all the functionality of ethr-did-resolver and ethr-did-registry.
- uport ethr-did registry
- Can be used to interact directly with a deployed registry contract directly, or deploy a copy of the contract to another Ethereum network.
- uport secp256k1-did resolver
- Library is intended to use secp256k1 public keys as Decentralized Identifiers and wrap them in a DID Document
- Requires the did-resolver library, which is the primary interface for resolving DIDs.
- Jolocom - project AGILE, W3C DID work (Berlin, DE)
- decentralised identity based on hierarchically deterministic keys
- MATTR - general entry point
- MATTR - learning
- MATTR - issue a zkp credential
IDunion - German cooperative on eIDAS/SSI with many strong partners
H2020 ESSIF-lab.eu -
TNO Blockchain lab-
Decentralised Identity- overall site
H2020 Kraken project - coordinated by Atos Spain
- DIF Identity Foundation
- DIF github - a long list of libraries
- DIF DIDComm use DIDs to communicate securely and privately over different channels
- Hyperledger Aries-
- creation, transmission and storage of verifiable digital credentials
- infrastructure for blockchain-rooted, peer-to-peer interactions
- includes a shared cryptographic wallet for blockchain clients as well as a communications protocol for allowing off-ledger interaction
between those clients
- consumes the cryptographic support provided by Hyperledger Ursa, to provide secure secret management and decentralized key management functionality
- Hyperledger Aries was initially contributed by developers from Sovrin Foundation, the Government of British Columbia, and other Indy community developers
- KRAKEN (BroKeRage and MArKet platform for pErsoNal data) is developing a trusted and secure personal data platform with state-of-the-art privacy aware analytics methods (with guarantees on metadata privacy, including query privacy).
- SSI - ZKProofs
- includes a shared cryptographic wallet for blockchain clients as well as a communications protocol for allowing off-ledger interaction
between those clients
- consumes the cryptographic support provided by Hyperledger Ursa, to provide secure secret management and decentralized key management functionality
- Hyperledger Aries was initially contributed by developers from Sovrin Foundation, the Government of British Columbia, and other Indy community developers
- US Gataca - SSI Samuel Gomez
- ID credentials issuance tool, wallet, User authentication tools
- GatacaQR JS authentication
- Tradle blockchain for KYC
- Octopus.sh - SSI - distributed graph identity solution for compliant self-sovereignty
- Rather than a single large encrypted database on a server, Octopus distributes data across millions of anonymous,
private, "data islands", cryptographic digital repositories - called 'Vaults\92.
Vaults linked together form the VaultChain. This technology ensures only data owners can manage their data
- unless access is granted to another Vault in the chain.
- A Vault can store any form of data, and the owner is free to publish cryptographically signed sets of data called Artefacts\AE from their Vault,
either to the public at large or other specific Vaults. These shared relationships between Vaults form the VaultChain
- Microsoft - DID on Azure for Bitcoin, Ethereum (via uPort) and Sovrin
- namecoin - DNS replacement
Tezos - POS-based, written in OCaml, contracts in Michelson language, tokenisation use cases
- Concordium codebase on Github
- core on-chain language is WebAssembly (Wasm)
- uses Rust as first high-level smart contract language
- Global Transaction Unit (GTU) is the native token
- a major innovation of the design is the two-layer consensus approach: BFT finality layer over a Nakamoto-style POS
Google, Amazon, Microsoft, Oracle, etc
- Digital Asset - the company behind DAML
- Google - DAML- Digital Asset Management Language
- DAML is a programming language for writing smart contracts, that you can use to build an application based on a ledger. DAML contracts run on different ledgers.
- DAML documentation
- DAML github - examples of trading, KYC, collateral management, supply chain, ...
- DAML github - ISDA CDM (International Swaps and Derivatives Association - Common Domain Model)
- CDM documentation - Rosetta technology
- Amazon QLDB - Quantum Ledger Database
- Microsoft - Azure-based blockchain
- Oracle - cloud-based HyperLedger Fabric
- Digital Bazaar - W3C, DID, XHTML+RDFa, HTML5+RDFa, Semantic Web, OpenID Connect, WebID
- Digital Bazaar on Github
- Bedrock - foundation for rich Web applications, based on nodejs
- PYLD - JSON-LD processor written in Python
- PYCA - crypto package written in Python
- PYLD - JSON-LD processor written in Python
- Bitcoin BIP 32 - Hierarchical Deterministic Wallets, two parts: a system for deriving a tree of keypairs from a single seed, building a wallet structure on top of such a tree
- Part 1, deriving a tree of keypairs from a single seed
- both private and public keys are extended with an extra 256 bits of entropy (at the end)
- CKDpriv derives private parent key -> private child key
- CKDpub derives public parent key -> public child key
- N((k, c)) calculates a private parent key -> public child key
- Finally, the calculation public parent key -> private child key is not possible
- Part 2, building a wallet structure on top of such a tree, using child key derivation (CKD) functions
- several CKD constructions are cascaded to build a tree
- the starting point is the master extended key m as root
- evaluation of CKDpriv(m,i) for several values of i, yields a number of level-1 derived nodes
- as each of these is again an extended key, CKDpriv can be applied to those as well
- Bitcoin BIP 39 - Mnemonic code for generating deterministic keys, used in two steps: generating the mnemonic,
and converting it into a binary seed (which can be later used to generate deterministic wallets using BIP-0032 or similar methods)
- Step 1, generate mnemonic
- generate entropy of 128-256 bits
- calculate and append checksum
- generate entropy of 128-256 bits
- split into groups of 11 bits, each encoding a number from 0-2047, serving as an index into a wordlist
- convert these numbers into words and use the joined words as a mnemonic sentence
- Step 2, create a binary seed from the mnemonic
- use of PBKDF2 (RSA PKCS #5 v2.0) function with a mnemonic sentence used as the password and the string "mnemonic" + passphrase used as the salt
- iteration count is set to 2048 and HMAC-SHA512 is used as the pseudo-random function
- length of the derived key is 512 bits
- seed can be later used to generate deterministic wallets using BIP-0032
- Bitcoin BIP 44 - Multi-Account Hierarchy for Deterministic Wallets, to allow the handling of multiple coins, multiple accounts, external and internal chains per account and millions of addresses per chain
- Quantum Blockchains - Mirek Sopek et al
- NEM - Japanese smart asset blockchain, built from scratch for application developers of all kinds, not just as a digital currency, relies on Proof of Importance
- Plasma- Scalable Autonomous Smart Contracts - Poon/Buterin
- Hedera Hashgraph- gossip protocol, Swirlds platform
- Bitfury- behind Georgia NAPR
- LU - Hexalina- blockchain for reputation management XFAIR
- RepuChain - reputation
- Cryptowerk- blockchain as a service, integration in SAP, e.g. for storing invoices
- IOHK.io- cryptocurrencies, works on Cardano blockchain and Ethereum Classic, Proof-of-stake Ouroboros
- Cardano- used e.g. by the Greek diploma solution
- Cardano roadmap
- Steem with dpos
- permissionless open source dlt
- ledger does not consist of transactions grouped into blocks and stored in chains, but as a stream of individual transactions entangled together using a 'tangle' (directed acyclic graph - DAG)
- no miners (but small pow involved nevertheless)
- relies on Lamport one-time signatures (optimised as Winternitz or PQ signatures)
- Swarm gateways- a distributed storage platform and content distribution service, a native base layer service of the ethereum web 3 stack
- RChain- with the Rho VM - aiming for scalability
- Aeternity - mainnet launch in 2018, contract creation off-chain, blockchain as arbiter
- EOS.IO - Block.one, working on transaction throughput, delegated proof of stake
- EOSIO supports the R1 elliptic curve, which means every iMac Pro, MacBook Pro, iPhone and iPad can use the secure enclave as a biometrically-secured hardware wallet
- the same R1 curve is used on many smart-cards and Android devices
- Tracr - diamond tracking from mine onwards by DeBeers
- Everledger - protecting diamonds
- Hydrachain - a variant of Ethereum employing traditional Byzantine Fault-tolerant consensus, similar to Tendermint
- Blondie - semantic blockchain
- BOScoin (Korea/CH) - trust contracts - owlchain (owl+timed automata language)
Over-arching, cross-chain, multi-chain, superchain
- BE- Settlemint - licensed software solution that interfaces with several blockchain and distributed ledger technologies (e.g. Ethereum) and relevant adjacent technologies (like IPFS) providing an abstraction layer
- ES - Alastria - not-for-profit consortium, 300+ members, testnet of 60 nodes, relies on Quorum's geth and truffle
- based on two different type of nodes:
- Validator: responsible for generating neutrality and reliability when generating blocks with transactions
- Regular: responsible for accepting transactions, verifying them and delivering them to the validator
- LU - Infrachain - not-for-profit, supported by LU government
- IT - SIAchain - created by SIA payment solutions
Multichains and parallel chains
- Multichain - Open source private blockchain platform, backwards compatible with bitcoin and Bitcoin Core
- Multichain on Github
- Pantos- multi-blockchain token
- Polkadot- Gav Wood and Parity-backed
- Polkadot consensus GRANDPA (GHOST-based Recursive Ancestor Deriving Prefix Agreement)
- Polkadot- wiki
- Consensus roles:
- Nominators, secure the Relay Chain by selecting trustworty validators and staking dots.
- Validators, secure the relay chain by staking dots, validating proofs from collators and participating in
consensus with other validators.
- Collators, maintain shards by collecting shard transactions from users and producing proofs for validator.
- Fishermen, monitor the network and report bad behavior to validators.
Collators and any parachain full node can perform the fisherman role.
- Parachains are the name given to the parallelized chains that participate in the Polkadot network.
Polkadot\92s natively supported blockchains achieve consensus using the greater network\92s consensus mechanism,
both adding to and benefiting from pooled security.
- Bridges are connecting layers that will enable existing blockchains with their own state histories and methods of
consensus to link with Polkadot without having to be a native parachain. These include Bitcoin and Ethereum.
- Polkadot- wiki - legacy
- Polkadot project- projects to deploy on Polkadot
- Kusama - Polkadot's canary network
- Polkadot governance
- Polkadot governance - 200 validators in 2021Q1
- Substrate - the technology under Polkadot, also Polkadot-JS
Social and media
- Bitshares - created by Dan Larimer, BitShares were originally named ProtoShares and intended to function as shares of virtual companies.[
- Bitshares Foundation (NL) - started by Ned Scott and Dan Larimer
- Graphene is used as the underlying technology for Bitshares and Steem. Graphene is an open source blockchain, mostly written in C++, originally created for Bitshares. The Bitshares developers
later founded Cryptonomex which now holds the main Graphene source.
- Steem- started by Ned Scott and Dan Larimer
- The challenge faced by Steem is to derive an algorithm for scoring individual contributions that most
community members consider to be a fair assessment of the subjective value of each contribution. In a
perfect world, community members would cooperate to rate each other\92s contribution and derive a fair
compensation. In the real world, algorithms must be designed to be resistant to intentional manipulation.
- The fundamental unit of account on the Steem platform is STEEM, a cryptocurrency token. Steem operates
on the basis of one-STEEM, one-vote. Under this model, individuals who have contributed the most to the
platform, as measured by their account balance, have the most influence over how contributions are scored.
Furthermore, Steem only allows members to vote with STEEM when it is committed to a vesting schedule.
- Users can vote content up or down and Steem will use their votes to determine the creator's reward.
- STEEM is the fundamental unit of account on the Steem blockchain. All other tokens derive their value
thereof. It is a liquid currency, which can be bought or sold on exchanges, as well as transferred to other users as a form of payment.
- Steem Power (SP) is STEEM that has been committed to a thirteen-week vesting schedule. SP balances are non-transferable and non-divisible except via the automatically
recurring conversion requests. SP cannot be easily traded on cryptocurrency exchanges.
When users vote on content, their influence over the distribution of the rewards pool is directly proportional
to the amount of SP that they have.
- Steem Blockchain Dollars (SBD) are created by a mechanism similar to convertible notes.
The terms of the convertible note allow the holder to convert to the backing token with minimum notice at the fair market price of the token.
- Consensus comes from witnesses. With Steem, a block is a group of signed transactions, and block production is done in rounds.
For each round, 21 witnesses are selected to create and sign blocks of transactions. Twenty (20) of these witnesses are selected by approval voting and one is
timeshared by every witness that didnt make it into the top 20 proportional to their total votes. The
21 active witnesses are shuffled every round to prevent any one witness from constantly ignoring blocks
produced by the same witness placed before. Any witness who misses a block and hasnt produced in the
last 24 hours will be disabled until they update their block signing key.
- Graphene wiki
- SmartMediaToken (SMT)
- native digital assets on the Steem blockchain that can be launched by anyone to help monetize online content
and create incentives to encourage desired user behavior
- Like Ethereum's ERC-20 tokens, but with built-in \91Proof-of-Brain\92 properties
and a token distribution reward system designed specifically for digital content businesses
- evaluated for EFTG
- Steemit - a blockchain-based blogging and social media website, which rewards its users with the cryptocurrency STEEM for publishing and curating content, owned by Steemit Inc., a privately held company based in New York City
All of these websites read and write content to the Steem blockchain, which stores the content in an immutable blockchain ledger,
and rewards users for their contributions with digital tokens called STEEM.
Every day, the Steem blockchain mints new STEEM tokens and adds them to a community's "rewards pool".
These tokens are then awarded to users for their contributions, based on the votes that their content receives.
Users who hold more tokens in their account as "Steem Power" will get to decide where a larger portion of the
rewards pool is distributed.
- Blockchain for social impact- leveraging Ethereum
Remember Mt. Gox which went bankrupt in JP and US. Remember the Coincheck 2018 hacking incident where approximately 500 million NEM tokens
($530 million) were stolen.
Blockchain use cases
Energy and utilities
- EWF - Energy Web Foundation - with Tobalaba blockchain, based on Ethereum Parity client
- EWF - Energy Web Foundation - Tobalaba netstats
- EWF - Tobalaba
- IDB Lab - innovation for inclusion in Latin America and the Caribbean
- LACChain- una alianza global por actores del entorno blockchain, liderada por BID Lab
Issuing, clearing and settlement
- CH atpar.io - Nils Bundi et al, issuing financial products, based on Ethereum, Consensus as shareholder
- CH ACTUS Protocol - see also atpar.io,
- SETL - started in FR, filed for insolvency, restarted in UK
- purpose-developed Big Object Storage System
- operates its ID2S CSD
Ripple's RippleNet and XRP
- Ripple - payment and clearing based on blockchain settlement in 4 seconds
- xCurrent enables banks to instantly settle cross-border payments
- xRapid can source on-demand liquidity
- xVia allows to plug into RippleNet to send payments
- Ripple Github
SWIFT's Global Payment Innovation - GPI
Customer Credit Transfer is the first SWIFT gpi service. Via Hyperledger channels it's ensured that data is stored only on the peers having
a stake in the transaction.
- GPI - POC based Hyperledger Fabric 1.0,
JP Morgan's Quorum
Private sector Ethereum with configurable consensus with QuorumChain (POS), Raft (leader election), Clique (POA) and Istanbul (BFT).
Built off Go Ethereum, functions similarly to Ethereum, but with some distinctions: network and peer permissions management, increased transaction and contract privacy, voting-based consensus mechanisms, and higher performance.
- JP Morgan's Quorum- an enterprise-focused version of Ethereum, Cakeshop SDK
- Quorum- documentation
- GoQuorum- Quorum development
- JP Morgan's Quorum Github - wiki, explaining
- Quorum is a permissioned implementation of Ethereum that supports transaction and contract privacy
- includes a minimalistic fork of the Go Ethereum client (geth)
- the primary features of Quorum, and therefore extensions over public Ethereum, are:
- Transaction and contract privacy
- Multiple voting-based consensus mechanisms
- Network/Peer permissions management
- Higher performance
R3 is an enterprise blockchain software firm and developped Corda,
an open-source blockchain platform, and Corda Enterprise, a commercial version for enterprise usage.
- US - R3 (since 2015) - Corda
- US - R3 - alternative url
- uses a doorman for access control
- uses Raft and a notary for consensus
- each node maintains a separate database of known facts, each peer only sees a subset of facts on the ledger, and no peer is aware of the ledger in its entirety
- whenever one of these facts is shared by multiple nodes on the network, it evolves in lockstep in the database of every node that is aware of it
- Java and Kotlin for dapps
- throughput up to 20K TPS, notary is main bottleneck
In June 2019, FB launched the Libra association and its currency. Currently available for macOS and Linux (sic).
Blockchain in supply chain
Blockchain as registry
Blockchain for education
- EduScrypt- Deloitte's talent education and qualification management
Blockchain for other purposes
- HullCoin - the world’s first Community Loyalty Point
Blockchain in production
Blockchain security, audit, law, education
Smart contract security
Blockchain security and audit
- AnChain (US) - Victor Fang (FireEye Mandiant)
- BEI connects wallet addresses and cryptocurrency transactions to real-world entities,
allowing you to secure endpoints, quantify risk, remain KYC/AML compliant
- TAP produces insight into your operations, providing automated alerts, anomaly detection, user profiling, and QA/QC
- CAS audits the security score of any Solidity-based smart contract, having analyzed the source code of every mainnet EVM
smart contract plus the 1M + unique, user-uploaded smart contracts
- CRR pursues your adversaries throughout their digital monetization life cycle, deterring repeat and future attempts,
identifying attack vectors, and minimizing financial and reputational losses to ransomware
- MerkleScience (JP) - monitoring and protection of crypto exchanges
- DASP - Decentralized Application Security Project - Ethereum security by NCC Group
- Trails Of Bits - includes blockchain security
- Trails Of Bits Echidna - EVM fuzzer, a Haskell library designed for fuzzing/property based testing of EVM code
- ChainSecurity (CH) - ETH/PwC
- Auditchain - ref Eric Cohen
- ACCA - the global body for professional accounts - divided we fall, distributed we stand - ref Eric Cohen
Blockchain and the law
Blockchain education, research, solutions and consulting