At the beginning of the project, we researched the available blockchain technology to understand how it works and discover how we can use it for our application. We concentrated on Bitcoin and Ethereum, comparing their capabilities and judging how suitable they are for implementing smart records. In addition, we looked for previous work similar to what we intend to build, and wrote a business plan for our project, as it was required for the Atos IT Challenge.

The current system of electronic payments relies on trusted financial institutions to process transactions. This trust-based model has inherent weaknesses:

• Non-reversible transactions are not possible; disputes need to be mediated.
• Small payments are infeasible; cost of mediation increases transaction costs.
• Transactions are not anonymous; third party must collect personal information.

Bitcoin, on the other hand, is an electronic payment system based on cryptographic proof of work instead of trust, allowing two parties to transact directly with each other without the need for a trusted third party.

Bitcoin keeps a public ledger of all transactions, called the block chain. This is, in essence, a peer-to-peer distributed timestamp server. Its role is to prevent double spending and modification of previous transaction records.

Each full node in the Bitcoin network keeps a complete copy of the block chain, containing all blocks validated by that particular node. Consistency across the network is guaranteed by following a series of consensus rules. When several nodes in the Bitcoin network independently arrive at identical block chains, they are considered to be in consensus.

A block chain, as the name suggests, is a digital chain of blocks. Each block contains a timestamp, a nonce (a number whose purpose will be described later) and a Merkle Tree that stores transactions.

The blocks are cryptographically chained together using hashes. Each block contains the hash of the previous block, which in turn contains the hash of the previous, and so on back to the first block. Modifying any part of a past block would invalidate all the subsequent hashes. This is critical for preserving the integrity of the ledger.

Computing a hash, however, is not very difficult. A usual CPU can compute roughly a million SHA-256 hashes per second. GPUs can compute hundreds of millions of hashes per second. ASICs (application-specific integrated circuits) are even faster. Under normal circumstances, it would be possible to modify previous blocks, as you could simply recompute all subsequent hashes.

The block chain is maintained collaboratively by peers on the Bitcoin network. To prevent malicious peers from modifying past blocks, the network requires a significant amount of work to be invested in the generation of each block. Chaining blocks together makes it impossible to modify transactions included in any block without modifying all following blocks.

When there are multiple chains competing for acceptance in the network (for example, when someone tries to rewrite a past block), consensus rules dictate that nodes will pick as valid the chain that is longest, i.e. the chain that has most proof of work behind it .

To successfully rewrite a past block, a malicious actor needs to re-generate all following blocks and overtake the honest nodes in the network. This is computationally infeasible, as long as honest peers control a large share of the total hashing power.

Distributed contracts are a way of using Bitcoin transactions to enforce financial agreements. They can be used to formalise and guarantee agreements in a way that does not rely on the traditional court system. Example contracts include Escrow, Micropayment channels and CoinJoin^[8].

Several different types of contracts can be implemented in Script, but the language is not Turing-complete, so not all possible contracts can be implemented. For a block chain system specifically designed for smart contracts, check out Ethereum and its Turingcomplete contract language, Solidity.

Various proposals to improve certain aspects of Bitcoin have been published. Some of them have been collected as BIPs (Bitcoin Improvement Proposals). Others proposals are stand-alone papers or forum posts. Some propose improvements of the existing Bitcoin system, while others create entirely new crypto-currencies.

To get an accurate understanding of Bitcoin internals, check the source code^[7], the developer guide^[8] and Mastering Bitcoin by Andreas Antonopoulos^[9].

The Bitcoin protocol does facilitate a weak version of smart contracts, however the scripting language implemented in Bitcoin has several important limitations:

• Lack of Turing-completeness – the scripting language doesn’t have loops
• Value blindness – cannot control what amount is withdrawn; either the entire UTXO is withdrawn, or none of it is
• Lack of state – UTXOs scripts can only be used for one-off contracts; “stateful” multi-stage contracts such as decentralised organisations are impossible to implement
• Blockchain blindness –cannot access blockchain data such as block headers or transaction history

Ethereum aims to build “the ultimate abstract foundational layer”: a blockchain with a built-in Turing-complete programming language, value awareness, blockchain awareness and state.

Smart contracts, decentralised applications and even entirely new protocols (currencies, reputation systems etc.) can be developed on top of the Ethereum block chain.

This new wave of blockchain-based technology is called “Blockchain 2.0”.

The state in Ethereum consists of objects called accounts. Each account has a 20-byte address. Ethereum has two types of accounts: externally owned accounts, controlled by private keys, and contract accounts, controlled by their contract’s code.

An Ethereum account contains 4 fields :

• nonce – for externally owned accounts, the number of transactions sent; for contract accounts, the number of contract-creations made; used to make sure each transaction can only be processed once
• balance – number of Wei in this account
• codeHash (immutable) – for contract accounts, stores the hash of the EVM code of this account; the actual code is stored in the global state database
• storageRoot – a hash of the root node of a Merkle Patricia tree that encodes the storage contents of the account

A transaction is a cryptographically-signed instruction created by an external actor. There are two types of transactions: message-call transactions and contract-creation transactions.

A transaction contains a number of standard fields:

• nonce – (sender account’s nonce at the time the transaction was sent) + 1
• gasPrice – the number of Wei to be paid per unit of gas for all computation costs incurred as a result of the execution of this transaction
• gasLimit – maximum amount of gas that should be used in executing this transaction; this is paid up-front, before any computation is done and may not be increased later
• to – 20-byte address of the message-call recipient or, in the case of a contractcreation transaction, empty
• value – number of Wei to be transferred to the message-call recipient or to the newly-created account
• v, r, s – values corresponding to the signature of the transaction and used to determine the sender of the transaction

Contract transactions additionally contain:

• init– EVM-code fragment for the account initialisation procedure

init is EVM-code that returns the body, a second EVM-code fragment that executes each time the contract account receives a message. init is executed only once, at account creation, and is discarded immediately afterwards.

Message transaction contain:

• data– a byte array specifying the input data of the message call

Messages are used to pass data and value (Ether) between two accounts. A message can be created either by external entities through a transaction, or by contracts through their EVM-code.

Digital Certificates Project

In June 2016, the MIT Media Lab released an experimental system for issuing academic certificates (Digital Certificates Project) and published BlockCerts, an open standard format for blockchain-based certificates, based on Mozilla Open Badges. The system is built on top of the Bitcoin blockchain, using OP_RETURN to store certificate hashes.

We would split our operations into two distinct units:

• Non-profit foundation – runs the core infrastructure, i.e. protocol and CA cert lists
• For-profit company – provides value-added services

As there are no hosting or maintenance costs associated with the system, it is financially feasible to have it managed by a non-profit. This provides an advantage against potential for-profit competing systems (as long as our technology is not surpassed) – our open system would be more attractive for third parties to integrate with and potentially contribute to than a for-profit competitor’s closed scheme. For the CA, we would use a process similar to the Mozilla CA Certificate Policy to add certification authorities in a fair and consistent manner.

The for-profit company would build value-added services on top of the infrastructure. There are several possibilities, and we would likely offer all of them:

• Hosted BitKariero profiles: users can host their CV on our platform, with freemium pricing (basic profile is free, but need to pay for additional features); when applying for a job, simply send the recruiter a link to your profile – we handle all the complexities of verifying it
• Candidate database: when uploading a CV to our platform, users can choose to make it available to potential recruiters; HR departments have to pay a fee to get access
• Third-party integrations: provide paid APIs for integrating with applicant tracking systems, certification pipelines, etc.

To attract users to our platform, we would partner with organisations that provide professional or academic certifications (Microsoft, Cisco, RedHat, British Council, PMI) and offer blockchain-based verifiable certificates.

The foundation will in effect create a competitive market for building upon the open infrastructure, and the for-profit company will move into a privileged position in that market.

We decided to use Ethereum, as it is much better aligned with our needs. While Bitcoin does have smart contract capability, this is very rudimentary and difficult to use in practice. Implementing records as Ethereum smart contracts gives us great flexibility in terms of functionality – it allows us to potentially implement dynamic records, multi-issuer records and many other record types.

We will extend the work done by the MIT Media Lab and advance the state of the art.

• Bibliography
• Full PDF (including standard format bibliography)