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.

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

AML

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 overlay network on top of the 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 trust

Ethereum privacy

Batching Ethereum

Other

Tendermint and Cosmos

Hyperledger

Hyperledger Fabric

Fabric basics

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.

Fabric versions

Fabric documentation

Fabric and ZKP/Idemix

Idemix is based a blind signature scheme that supports multiple messages and efficient zero-knowledge proofs of signature possession. See local Camenisch info.

This particular Idemix implementation for Fabric uses a pairing-based signature scheme that was proposed by Signature Schemes and Anonymous Credentials from Bilinear Maps - Camenisch and Lysyanskaya, and described in detail by Constant-Size Dynamic k-TAA - Au et al.

The ability to prove knowledge of a signature in a zero-knowledge proof as described in Anonymous Attestation Using the Strong Diffie Hellman Assumption Revisited - Camenisch, Drijvers, Lehmann was used.

Fabric - other info

Hyperledger Sawtooth Lake

Hyperledger Indy

Key features= Info

Hyperledger Ursa

A shared crypto library. Hand in hand with Aries.

Hyperledger Aries

Provides a tool kit designed for initiatives and solutions focused on creating, transmitting and storing verifiable digital credentials. It is infrastructure for blockchain-rooted, peer-to-peer interactions. This project consumes the cryptographic support provided by Hyperledger Ursa, to provide secure secret management and decentralized key management functionality.

Aries grew out of the work in Hyperledger Indy to create technologies for managing decentralized identity. Indy provides a specific blockchain purpose-built for identity. The tools created in Indy for building agents are being migrated to Aries, and extended to be blockchain-agnostic. Functionality related to the Indy ledger will remain in Indy.

Hyperledger Quilt

Hyperledger Caliper

W3C self-sovereign identity and DID

EU eSSIF lab

Sovrin

Different pairwise pseudonymous DIDs for interactions, over a P2P network, with ZKPs.

Sovrin is a public permissioned ledger, running the Plenum consensus protocol, which is an enhancement of the RBFT (Redundant Byzantine Fault Tolerant) protocol first introduced by Pierre-Louis Aublin, Sonia Ben Mokhtar, and Vivien Quéma in 2013. RBFT improved on the earlier PBFT and Aardvark protocols by executing several protocol instances with different primary validator nodes in parallel to detect any performance problems in real-time, without assuming anything about the previous or future performance/condition of the system. The Plenum protocol, developed primarily by Jason Law and Lovesh Harchandani, further improves on RBFT by adding: Sovrin has three networks for SSI, each based on Hyperledger Indy and made up of between 4 and 25 nodes which are operated by Sovrin Stewards. Mainnet, Testnet, and BuilderNet (only for internal use by Sovrin Foundation). Furthermore:

Ethereum-based SSI

MATTR

Alastria SSI

Other SSI

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

Open Wallet Foundation OWF

I-AM and iPDS

Bitcoin

EBSI

Other

Other technology

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

Multichain interfacing

Over-arching chains

Asian initiatives

Other initiatives

Multichains and parallel chains

Superchains, interledger

Social and media

Games

Exchanges and marketplaces

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.

Marketplaces

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.

IETF

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