CRYPTO-applications: timestamping, archiving, blockchains, cryptocurrencies

Timestamping

Electronic archiving

Electronic consensus

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.

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 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). Permissioned means that only particular users can publish blocks. ETSI has an Industry Specification Group (ISG) on Permissioned Distributed Ledger (PDL) Permissionless means that anyone can publish a new block. 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: 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.

Crash Fault Tolerant (CFT)

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.

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. Alternatives have emerged, including:

Proof of Stake (PoS)

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: 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.

Proof of Elapsed Time (PoET)

Proof of Importance (PoI)

Other

Zero Knowledge in blockchains

Privacy in blockchains

eMoney and tokens

The terminology here is not yet cast in stone. De-facto, token types can be classified as:

Overviews and research

Bitcoin

Bitcoin basics

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

Bitcoin cryptography

ECC secp256k1

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. Hard forks: Other

Bitcoin status

Spawned from Bitcoin

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)

Non-state issued

Sidechains

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)

eInvoicing

Blockchain

General

Standards

Economy

Contracts

Ethereum

Ethereum basics

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.

Consensus

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.

Details

The papers: More info:

Ethereum consensus

Ethereum Networks

Test/main

Ethstats

Ethereum block explorers

Ethereum application building blocks

There are Dapps, full clients, remote clients and wallets.

Distributed applications (Dapps)

Dapps are JavaScript coded web pages that connect to a Ethereum node softwares over JSON-RPC API protocol that itself runs on the top of HTTP protocol. Dapps are pure client side HTML and JavaScript, don't need any servers and they can run in any web browser, including mobile and embedded ones, like one inside Mist wallet.

Full clients

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.

geth
Parity
EEA clients
Pantheon client
Besu

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.

Web3
Remote clients
These include:
Wallets
For general information see wallets. Ethereum wallets include:

Development

Ethereum Enterprise Alliance

DAO - Slock.it - DAO led to Ethereum hard fork

Alastria

Ethereum management and stats

Ethereum security

Ethereum privacy

Other

Tendermint and Cosmos

Hyperledger

Hyperledger Fabric

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).

Three types of nodes:
  1. 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.
  2. Peer:
    • 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
  3. Orderer: a node running the communication service that implements a delivery guarantee, such as atomic or total order broadcast.
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:

Smart contracts primarily put, get and delete states in the world state, and can query the immutable blockchain record of transactions. 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.

Hyperledger Sawtooth Lake

Hyperledger Indy

Hyperledger Quilt

Hyperledger Caliper

W3C self-sovereign identity and DID

Sovrin

Ethereum-based SSI

MATTR

Alastria SSI

Other SSI

  • H2020 Kraken project - coordinated by Atos Spain
  • Other chains

    Tezos

    Tezos - POS-based, written in OCaml, contracts in Michelson language, tokenisation use cases <

    Concordium

    Governance

    Ideas

    Vendors

    IBM

    Google, Amazon, Microsoft, Oracle, etc

    Other

    Building blocks

    Digital Bazaar

    Oracles

    Legal contracts

    Wallets

    Other technology

    Over-arching, cross-chain, multi-chain, superchain

    Multichain interfacing

    Over-arching chains

    Multichains and parallel chains

    Superchains, interledger

    Social and media

    Games

    Exchanges

    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

    Overviews

    Conformity assessment

    Energy and utilities

    Finance

    Issuing, clearing and settlement

    Ripple's RippleNet and XRP

    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.

    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.

    R3's Corda

    R3 is an enterprise blockchain software firm and developped Corda, an open-source blockchain platform, and Corda Enterprise, a commercial version for enterprise usage.

    Facebook's Libra

    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

    Blockchain for other purposes

    Blockchain in production

    Blockchain security, audit, law, education

    Smart contract security

    Blockchain security and audit

    Blockchain and the law

    Blockchain education, research, solutions and consulting