Report
Reference
Towards a Standard to Assess Blockchain & Other DLT Platforms
MARANHÃO, Suzana, SEIGNEUR, Jean-Marc, HU, Ruifeng & ITU
Abstract
There are more and more Distributed Ledger Technologies (DLT) and it becomes difficult to assess them due to unfounded marketing claims and their open networks, which can easily be under attack. This paper presents an initial DLT assessment framework as discussed as part of the ITU focus group on application of distributed ledger technology and how it has been applied to assess one of the major existing DLT platforms at time of writing, i.e., Ethereum.
MARANHÃO, Suzana, SEIGNEUR, Jean-Marc, HU, Ruifeng & ITU. Towards a Standard to Assess Blockchain & Other DLT Platforms . ITU, 2019
Available at:
http://archive-ouverte.unige.ch/unige:112558
Disclaimer: layout of this document may differ from the published version.
1 / 1
Assess Blockchain & Other DLT Platforms
Suzana Maranhão
Brazilian Development Bank Rio de Janeiro
Brazil [email protected]
Jean-Marc Seigneur
University of Geneva & Reputaction 7 route de Drize, Carouge
Switzerland
Ruifeng Hu
Nanjing Jiangsu Huawei
China
ABSTRACT
There are more and more Distributed Ledger Technologies (DLT) and it becomes difficult to assess them due to unfounded marketing claims and their open networks, which can easily be under attack.
This paper presents an initial DLT assessment framework as discussed as part of the ITU focus group on application of distributed ledger technology and how it has been applied to assess one of the major existing DLT platforms at time of writing, i.e., Ethereum.
CCS CONCEPTS
• General and reference → Document types; Computing standards, RFCs and guidelines • Computer systems organization → Architectures; Distributed architectures
KEYWORDS
Blockchain, Distributed Ledger Technology, DLT, Standard, Evaluation
1 INTRODUCTION
Bitcoin [1] has introduced and popularized blockchain technology, which is one among other Distributed Ledger Technologies (DLT).
Since 2013, the number of different DLT has increased a lot and it is difficult to know which ones are of good quality due to unvalidated marketing claims and the different types of attacks that can happen in such open environments where any entities may join the network. Although few DLT have been deployed with enough real use-cases and users to be able to practically check their technical claims, in this paper, we propose a DLT assessment framework that has been applied to several major DLT and may be applied to other ones.
The next section discusses related work. In Section 3, we present how we have designed our DLT assessment framework. In Section 4, we present the assessment results of Ethereum as an example.
Section 5 concludes our paper.
2 RELATED WORK
As mentioned in the introduction, Bitcoin has been the first project to use blockchain technology [1] although it has been focused on the payment application domain. In 2013, Buterin et al. [2] have proposed Ethereum, the first project to build a decentralized application (dApp) framework using blockchain for other types of applications than payment. Several other projects followed the path of Ethereum but with slightly different blockchain approaches, for example, with different consensus algorithms, e.g., NEO [3]. Then, other types of DLT appeared, for example, based on directed acyclic graph (DAG) like IOTA tangle [4] or Hashgraph [5], which argue to reach very high Transactions Per Seconds (TPS) but are still not attack-resistant in permissionless settings, open to any new nodes, because IOTA still uses a coordinator and Hashgraph is trying to move to permissionless settings with its Hedera platform.
Permissioned settings are less challenging regarding attack- resistance but they have their own dedicated DLT platforms such as Hyperledger Fabric [6].
Regarding blockchain assessment, Wang et al. [7] have used the Capability Maturity Model (CMM) [8] to assess blockchain technology, however only roughly according to technology, market and regulation. The ISO [9] has a dedicated technical committee for “blockchain and distributed ledger technologies” focusing on use cases, smart contracts, governance, interoperability, security, privacy and identity. The ITU has a focus group on application of distributed ledger technology [10] to develop a standardization roadmap for interoperable DLT-based services and this work has been discussed as part of this ITU focus group as an initial attempt that will be further improved. Weiss Cryptocurrency Ratings [11]
argues to be the first cryptocurrency ranking by a financial rating agency based on a model that analyzes thousands of data points on each coin’s trading patterns, technology, and usage. China’s Ministry of Industry and Information Technology (CCID) periodically releases a global public blockchain evaluation index [12] ranking projects according to a total score over 3 aspects:
technology, application and innovation. There are also sites rating new coins associated to DLT such as CryptoBriefing [13] or Smith+Crown [14], although a lot of them do not publish unpaid
2
independent reviews. A few of these sites have also dynamic ratings based on the DLT popularity on social networks, which may be biased with paid fake engagement, and code activity [15], [16].
3 DLT ASSESSMENT FRAMEWORK
After analyzing previous work and major DLT platforms, 3 main layers of assessments criteria emerged as depicted in Figure 1. The first layer concerns the core technology part of DLT. The second layer concerns their application aspects. Then, beyond independent applications running on the DLT, there is the operation layer for the DLT and its applications.
Figure 1: The 3 layers of our DLT assessment framework
In order to assess the different DLT in finer grained detail, we have then listed different assessments criteria in each of these 3 layers.
We have followed the IETF RFC wording way [17]: must means the feature is mandatory and should means that the feature is recommended but optional.
3.1 Core Technology Layer
3.1.1 Security
.
The DLT system provider must provide detail of the security aspects of the DLT:• Attack-resistant Consensus Mechanism. Consensus mechanism is a major component of a DLT. An insecure consensus mechanism may lead to a disastrous outcome, e.g., if the DLT deals with payments transactions, all funds may be stolen. DLT system providers must reveal the consensus mechanism in product specification, which must be peer-reviewed and open-source. Verification should be done by functional testing and formal verification. The theoretical limit of malicious nodes in the system before it is successfully attacked must be known. The DLT should have mechanisms to detect when it is attacked and which data has been tampered.
Consensus in permissioned settings may be less challenging than in permissionless settings where the
number of nodes is unbounded and most nodes are unknown. The DLT should have a pluggable consensus algorithm module.
• Open-source Cryptography. DLT system providers must reveal the cryptography techniques used in the DLT.
They should disclose the DLT code as open-source. They should use peer-reviewed open-source cryptography. If they don’t use standard state-of-the-art peer-reviewed or regulatory-compliant cryptographic algorithms, their proprietary algorithms must have been peer-reviewed. If passwords are used, the passwords strength and encryption methods should be verified by functional testing. The DLT providers should publicly state if their DLT encryption is quantum-computing resistant and, if not, they should mention what is planned regarding quantum-computing resistance. The DLT system should have a pluggable encryption algorithm module. The DLT providers should test that high load of encryptions does not degrade the DLT performance and publish publicly the results.
• KYC, AML, CTF and Privacy. On one hand, the DLT must enforce Know Your Customers (KYC), Anti- Money Laundering (AML) and Counter Terrorism Financing (CTF) in order to forbid criminal activities. On the other hand, the DLT must comply with privacy laws and should protect privacy, for example, via privacy protection mechanisms such as zero knowledge proof, ring signature and homomorphic encryption.
• Private Key Management. The DLT provider must provide software-based private key management functionalities, which should be extended with hardware- based storage. The users must also have the choice to store their private keys with their own customized solutions. Those functionalities should be verified by functional testing and should be user-friendly.
• Resistance to Distributed Denial of Service (DDoS) Attack. The DLT should provide security mechanisms to detect and fight DDoS attacks.
• Permissionless:The DLT should work in permissionless settings without compromising security.
3.1.2 Performance. The DLT system provider or open- source community must provide detail of performance testing environment and results, even for a high number of nodes and transactions. Performance results should be peer-reviewed.
Performance shouldn’t be too much degraded as the number of nodes and transactions increases. Performance may be optimized with off-chain mechanisms such as sidechains [18] and/or offline transactions protected by hardware security modules. Performance should include:
• Traditional throughput. With a specific number of nodes, hardware devices, network bandwidth, network latency and specific constraints such as failure tolerance (e.g., 99.95%), the system throughput must be evaluated when
different numbers of requests (transaction request and query request) are generated. When the DLT allows smart contracts, an estimation of basic smart contract operations throughput should also be provided.
• Transaction confirm timestamp. The time required to achieve consensus and generate a block, if blocks are used, must be evaluated with regard to:
o Maximum transaction time. The longest waiting time from a transaction submission to confirmation.
o Average transaction time. The average waiting time from a transaction submission to confirmation. It must be mentioned whether the confirmation is probabilistic or not and if it is probabilistic, the given probability strength should be detailed.
3.1.3 Sustainability. A DLT relies on nodes owned by different parties and an incentive should be in place to motivate nodes to continue serving and using the system, especially if the transactions aren’t free and require some tokens to be paid as transaction fees. For example, Bitcoin Proof-of-Work (PoW) uses a lot of electricity and miners are rewarded through Bitcoins. If an incentive mechanism is in place, it should be detailed, e.g., if tokens are used, a tokenomics report explaining the tokens economics should be publicly released. Any potential environmental issues should be highlighted in the report, e.g., the high electricity consumption of Bitcoin PoW. The users community, from developers to end-users, must be active and appropriate communication channels must be regularly updated (news, deeper reports...).
3.1.4 Governance.The DLT system must document publicly its governance: how its accounts, smart contracts, data and functionalities are governed, controlled, owned, changed, how it is technically enforced and managed including their lifecycle, upgradability, isolation and freezing conditions, monitorability, auditability…
3.1.5 Interoperability. The DLT system should use standards where possible for increased interoperability, e.g., regarding its potential tokens, they should be based on de facto standards such as ERC-20 or NEP-5. The DLT system should have functionalities to facilitate cross-chain or cross-DLT operations.
3.2 Application Layer
If developers can write their own smart contract on top of the DLT, the following criteria apply:
3.2.1 Smart Contract Programmability
.
• An Integrated Development Environment (IDE) to help the developers to implement, test and maintain their
smart contracts must be provided, including at least a testnet in addition to the mainnet, with up to date documentation and an active developers community. It should be possible to formally validate the smart contract functionalities. The IDE should use proven development tools, e.g, well-known programming languages.
• A DLT that provides Turing complete programming capabilities, such as Ethereum, may be more prone to security holes and more difficult to audit. For basic smart contracts, such as payments applications, DLT with non- Turing complete programming capabilities should be sufficient, e.g., Stellar.
3.2.2 Smart Contract Data Access Control.If the DLT governance allows the developers to specify and enforce the authorization and confidentiality of their smart contract, the DLT system must document publicly how developers can specify the authorization and confidentiality of their smart contract and technically enforce them. Potential users of the smart contracts should have an easy way to understand the smart contract governance model, especially who owns what (user data, cryptocurrency fund…) and who has access to what, for example, via visual interfaces to represent smart contracts and query them.
3.3 Operation Layer
3.3.1 Scalability.• Adding, deleting or upgrading DLT nodes must not disrupt the system as long as it is within the minimum and maximum number of nodes publicly documented by the DLT.
• Storage of DLT data must be expandable as the system scales and it should be validated by functional testing.
• Load-balancing between nodes should be provided because each node may have limited bandwidth, computing and storage resources, especially Internet of Things (IoT) nodes.
3.3.2 Stability. The DLT should keep running 7 x 24 hours with no exception of network delay, memory and CPU utilization…
3.3.3 Auditability. A DLT explorer tool must be provided to investigate its current and previous status (number of nodes and their status, blocks, transactions, tokens, smart contracts, bugs found, treated and being fixed, number of contributors currently working for the DLT system…), the DLT accounts and the history of its transactions. It should be verifiable by functional testing. The DLT system should have enough full archiving nodes and/or make appropriate backups for recovery and audits as well as to archive outdated data that can still be retrieved even if the access is slower than on the live version.
4
4 ETHEREUM ASSESSMENTS RESULTS
In this section we have applied our DLT assessment framework to Ethereum. Besides the referenced material, this section took a lot of information of the Ethereum White Paper [2] and Yellow Paper [19].
4.1 Core Technology Layer
4.1.1 Security
.
Attack-resistant Consensus Mechanism. The consensus mechanism is a kind of Proof-of-Work (PoW) algorithm. The PoW adaptation to Ethereum platform is called Ethash. Besides the explanation of how this algorithm works in the Yellow Paper [19], it is also possible to see its implementation because Ethereum is open source1.
There are more than 15 thousands full nodes2 in Ethereum network at the moment of this writing. In order to minimize the incentive of node centralization into pools, Ethash is ASIC- resistant and do not generate super-linear profits in mining rewards.
If there were few full nodes, the majority of these nodes could band together and all agree to cheat in some profitable fashion (e.g. to change the block reward). However, at least one honest full node would likely exist, and after a few hours the fraud would be clearly identifiable.
All valid Ethereum transactions must be signed with their owner’s private key. An attacker cannot spend the account’s funds unless it has access to its private key. If an attacker tried to submit an invalid transaction and this transaction is included in a block, then this block would also become invalid. Honest nodes would not include this block on the blockchain.
An attacker cannot submit the same transaction again, doing a so-called replay attack, since every Ethereum account has a field known as nonce: a counter used to make sure each transaction can only be processed once. Transaction with wrong nonce, in this case, repeated ones, are also invalids.
An attacker can try to double spend its funds. In order to do that, the attacker would need to create a blockchain fork beginning before its first spending. Finally, because of the Poof- of-Work consensus protocol, the attacker would need to make his branch of the blockchain the longest one. Then, he would need to have more computational power than the rest of the network combined in order to catch up. That is known as 51% attack and it is capable of rewriting the history of the blockchain. The transaction history of Ethereum can be traced using Etherscan3. A 51% attack would greatly undermine Ethereum trustworthiness.
1 https://github.com/ethereum/
2 https://www.ethernodes.org/
3 https://etherscan.io/
4 https://blog.ethereum.org/2015/12/24/understanding-serenity-part-i-abstraction/
5 https://github.com/ethereum/EIPs/pull/208/files
6 https://www.uport.me/
Open-source Cryptography. Ethereum uses ECDSA (Elliptic Curve Digital Signature Algorithm) for it’s public-key cryptography and KECCAK-256 for hashing.
Ethereum has announced in 2015 that the Serenity version will be optionally quantum-safe4. The user will have the option to protect his/her account using Lamport signatures. Before Serenity, there are some features been implemented on Metropolis version, as commented in the Ethereum’s source code: “The goal of these changes is to set the stage for abstraction of account security.
Instead of having an in-protocol mechanism where ECDSA and the default nonce scheme are enshrined as the only standard way to secure an account, we take initial steps toward a model where in the long term all accounts are contracts, contracts can pay for gas, and users are free to define their own security model.”5.
KYC, AML, CTF and Privacy. Ethereum accounts are pseudo- anonymous. There is no native concept of user in the platform.
There are some initiatives to manage personal identity linked to Ethereum accounts in a sovereign way. One example is uPort6.
There are some works focusing to bring privacy to Ethereum, especially using zero knowledge proof but, as far as we know, they are still not available to end-users. At time of writing, all transactions data is public.
Private Key Management. An example of a software-based private key management tool is MyEtherWallet7. Using this software, the user has the choice to access her/his private key in many ways, e.g., JSON File, Mnemonic Phrase and Trezor8. Trezor is an example of hardware-based storage.
Resistance to Distributed Denial of Service (DDoS) Attack. The main defense against DDoS attack in Ethereum is (a) its decentralized architecture without central services like masternodes or node producers and (b) the transaction fee charged when a transaction is submitted. It is expensive to an attacker create a lot of fake transactions.
One important point to highlight is that an attacker can compromise some network gateways and affect the experience of many users. For example, many users are accessing the network by a browser plug-in called Metamask9. Although is it possible to configure what gateway should be used, Metamask comes configured with a pre-defined server to access Ethereum network and probably many users do not know how to change that.
Permissionless:Ethereum is a permissionless network.
4.1.2 Performance
.
Since Ethereum is a permissionless DLT, it is not possible to control the number of nodes, hardware devices, network bandwidth, network latency and specific constraints such as failure tolerance in the mainnet.7 https://www.myetherwallet.com/
8 https://trezor.io/
9 https://metamask.io/
Block’tivity10 is a Website dedicated to observe the activity in different permissionless DLTs. The information in August, 31 of 2018 shows that Ethereum is working at 100% of its capacity. It also shows that, on average, Ethereum process 580 661 transactions/day (or something between six and seven transactions/second) and the maximum throughput was 1 372 918 transactions/day (fifteen transactions/second). There are projects to increase the transaction throughput, like sharding and plasma11.
An Ethereum transaction can be a simple value transfer between two accounts or a smart contract execution. A transaction contains a STARTGAS value, representing the maximum number of computational steps the transaction execution is allowed to take and a GASPRICE value, representing the fee the sender pays per computational step.
The STARTGAS and GASPRICE fields are crucial for Ethereum's anti-denial of service model. In order to prevent accidental or hostile infinite loops or other computational wastage in code, each transaction is required to set a limit to how many computational steps of code execution it can use. The fundamental unit of computation is called “gas”; usually, a computational step costs 1 gas, but some operations cost higher amounts of gas because they are more computationally expensive, or increase the amount of data that must be stored as part of the state. There is also a fee of 5 gas for every byte in the transaction data. The intent of the fee system is to require an attacker to pay proportionately for every resource that they consume, including computation, bandwidth and storage; hence, any transaction that leads to the network consuming a greater amount of any of these resources must have a gas fee roughly proportional to the increment.
A transaction fee is calculated as STARTGAS * GASPRICE.
In general, if the transaction does not exceed the block limit, the transaction is executed faster if there is GASPRICE higher than the average of what other transactions are using.
Figure 2: Average confirmation time by gas price, recommended gas price is 2.4Gwei
10 https://blocktivity.info/
11 https://bitcoinist.com/vitalik-buterin-sharding-plasma-scale-ethereum-10000- times/
As far as we know there is no maximum transaction time. If the GASPRICE is too low, the transaction can never be confirmed. The average waiting time from a transaction submission to confirmation can be estimated considering gas requirements. The information in August, 31 of 2018 on ETH Gas Station12 shows the average waiting time for each gas price (see Figure 2).
Nevertheless, ETH Gas Station also shows that the median wait for all transactions are two blocks, or less than 30 seconds.
4.1.3 Sustainability
.
A miner receives money from transaction fees and from new ethers, created together with new blocks.The transaction fee is calculated considering how difficult it is to execute that transaction or store its results. A transaction fee is calculated as STARTGAS * GASPRICE. The price of gas goes up if there are too much demand on the network.
New ethers are constantly been created together with new blocks. During each block creation, Ethereum implementation of Proof-of-Work give rewards to the winner miner and to miners of stale descendants of ancestors blocks which attend some protocol rules (GHOST protocol).
With a permanent linear growing currency issuance, the ether long-term inflation rate tends to zero. There is a theory that because coins are always lost over time due to carelessness, death… and coin loss can be modeled as a percentage of the total supply per year, the total currency supply in circulation will in fact eventually stabilize at a value equal to the annual issuance divided by the loss rate. For example, considering that X is the total amount sold during the initial currency sale (X=60102216 ETH) and that 0.26X is allocated to miners per year forever after that point - at a loss rate of 1%, once the supply reaches 26X then 0.26X will be mined and 0.26X lost every year, creating an equilibrium.
Ethereum’s consensus algorithm is going to change from Proof- of-Work to Proof-of-Stake, which will demand less resources from miners. It could reduce the issuance requirement to somewhere between zero and 0.05X per year.
The value received during the currency sale was allocated to pay salaries and bounties to developers and invest into various for- profit and non-profit projects in the Ethereum and cryptocurrency ecosystem. In addition to the value received, two endowment pools were also created to cover initial costs and to be used as log- term reserve.
There are some active forums like:
https://www.reddit.com/r/ethereum/, with 381 000 subscribers and 7 000 people online at the time of writing. There are other forums to specific topics like /r/ethtrader (price of ether, buying, trading, market speculation), /r/EtherMining (mining discussion) and r/ethinvestor or similar (ICO advertisements). These topics should not be covered in the main forum. ETH Gas Station is a site very useful to Ethereum users. It provides a consumer oriented metrics for the Ethereum Gas Market.
12 https://ethgasstation.info/
6
4.1.4 Governance
.
There are two types of accounts which share the same address space: externally owned accounts and contract accounts. Externally owned accounts are controlled by public-private key pairs and have no code. Contract accounts are controlled by the code stored together with the account – the smart contract code. Each account has a storage, a persistent memory area. A contract can neither read nor write to any storage apart from its own.A transaction is a message that is sent from one account to another account. It can include binary data (its payload) and Ether.
A transaction must be originated by an externally owned account.
If the target account contains code, that code is executed and the payload is provided as input data. The code can read or write in the account internal storage. If the target account is the zero-account (the account with the address 0), the transaction creates a new contract. The payload of such a contract creation transaction is taken to be EVM bytecode and executed. The output of this execution is permanently stored as the code of the contract.
As far as we know, there is no native support to manage accounts lifecycle (apart from creation), upgradability and freezing.
Contract account can freeze and destroy itself if and only if it is programmed to do so. It should also be coded to store its owner and to make upgradability easier. There are design patters to deal with ownership, freezing, upgradability and contract destruction [20].
The EIP (Ethereum Improvement Proposals)13 is an open governance model where everyone is free to propose and discuss changes to the system. There are several different stages that an EIP can be in. Draft EIPs are works in progress, are open for consideration and discussed on Github. Accepted EIPs can be expected to be included in the next hard fork. Final EIPs are proposals that have already been adopted and deferred EIPs are not being considered for immediate adoption, but may be considered again in the future.
4.1.4 Interoperability
.
The Ethereum community has developed standards thanks to its governance model. ERC-20 (fungible tokens) and ERC-721 (non-fungible tokens) are examples of these standards. There are others, like ERC-165 Standard Interface Detection and ERC137 Ethereum Domain Name Service.As far as we know, Ethereum does not have functionalities to facilitate cross-chain or cross-DLT operations.
4.2 Application Layer
4.2.1 Smart contract programmability
.
Ethereum provides Turing-complete programming languages, such as Solidity14. There are some tools to be used during development of new smart contracts. Remix15 is an open source tool that helps developers write Solidity contracts. Written in Javascript, Remix supports both usage in the browser or locally. Remix also supports13 https://eips.ethereum.org/
14 https://solidity.readthedocs.io/
testing, debugging and deploying of smart contracts. Truffle16 provides development environment, testing framework and deployment. Truffle does not offer a text editor. Developers can use Visual Studio Code with Solidity plug-in.
Remix is also an example of security tool capable of reducing coding mistakes on Solidity codes and identifying potential vulnerable coding patterns. Its security analysis rely on formal verification (deductive program verification and theorem provers).
Ardit and Mariusz discuss other examples of security tools for Ethereum contracts [21].
There are some testnets executing Ethereum nodes, like Rinkeby and Ropsten. It is also possible to simulate a local environment DLT using Remix or Truffle. There are a reasonable amount of documentation (covering language, development procedures, best practices, known attacks) and active developer’s communities, like ethereum.stackexchange.com.
4.2.2 Smart contract Data Access Control
.
Using Solidity, developers can specify who has access to each function in the smart contract. The functions provide access to smart contract data. Indeed, Maximilian and Uwe [20] explain how to use design patterns to handle Ownership and Access Restriction in Solidity.As far as we know, there is no way to specify confidentiality and no standardize way to allow users to understand the smart contract governance model, especially who owns what and who has access to what. This information can be presented to the user if there is a comprehensive front-end with this goal.
4.3 Operation Layer
4.3.1 Scalability
.
There is no restriction about maximum number of nodes. In fact, the Proof-of-Work algorithm provides a mechanism for allowing free entry into the consensus process, solving the political problem of deciding who gets to influence the consensus, while simultaneously preventing Sybil attacks. It does this by substituting a formal barrier to participation, such as the requirement to be registered as a unique entity on a particular list, with an economic barrier - the weight of a single node in the consensus voting process is directly proportional to the computing power that the node brings.As a peer-to-peer network, at any time an Ethereum node can be added, deleted or upgraded without network disruption. If a software upgrade of a node introduces a hard fork, the upgraded node will no longer accept the blocks produced by non-upgraded nodes. This essentially creates a fork in the blockchain: one path follows the new, upgraded blockchain, and the other path continues along the old path.
Regarding to load-balancing, it is possible to divide Ethereum nodes into two types: full nodes and light nodes. Full nodes maintain the current state of the network as defined according to the Ethereum specifications. Their goal is ensure that the transactions contained in the blocks and the blocks themselves
15 https://remix.ethereum.org
16 https://truffleframework.com/
follow the rules defined in the Ethereum specifications. Full nodes also have to run all the instructions during execution of smart contracts to ensure that they arrive at the correct, agreed-upon next state of the blockchain. Full nodes that preserve the entire history of transactions are known as full archiving nodes.
Light nodes, in contrast, do not verify every block or transaction and may not have a copy of the current blockchain state.
They rely on full nodes to provide them with missing details (or simply lack particular functionality). The advantage of light nodes is that they can get up and running much more quickly, can run on more computationally/memory constrained devices, and need much storage. On the downside, they should have different levels of trust in other full nodes. Light nodes are still under development in Ethereum17.
Miners nodes need to receive updated information of a full node or be a full node itself.
Every transaction needs to be processed by every full node in the network. DLT storage is independently expandable in each node. The larger the blockchain size, the smaller is the incentive to store large amount of data as a full node. The fewer the number of full nodes, the higher the risk of network attacks (see subsection 4.1.1).
4.3.2 Stability
.
Due to network congestion, Ethereum has faced some problems regarding to network delay18. As far as we know, there is no downtime in the network due to its peer-to-peer architecture.4.3.3 Auditability
.
Etherscan.io is a search engine and an explorer tool that allows anyone to investigate Ethereum current and previous status. It shows information about blocks, transactions, tokens, smart contracts, addresses and the history of its transactions. Etherscan.io is independently operated and developed independent of the Ethereum Foundation.Ethernodes allows anyone to see the number of nodes and where they are located. There are more than 15 000 full nodes in Ethereum network at the time of writing.
The Ethereum code and development artifacts are open source, thus, it is possible to see the bugs that have been found, treated and being fixed as well as discussions and who is involved by looking at its Github repository.
5 CONCLUSION
To conclude, we have proposed one of the first DLT assessment framework to be standardized by an international standardization body. We have shown how it can be applied to a DLT by applying to Ethereum.
Future work not only concerns applying it to other DLT but also using it to compare different DLT between each other.
17 https://github.com/ethereum/wiki/wiki/Light-client-protocol
17 https://www.bbc.com/news/technology-42237162
ACKNOWLEDGMENTS
We are grateful to all the contributors of the ITU-T Focus Group on Application of Distributed Ledger Technology, which is working on further versions of this DLT assessment framework.
REFERENCES
[1] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” 2008.
[2] V. Buterin and others, Ethereum white paper. Ethereum Foundation, 2013.
[3] “NEO Smart Economy.” [Online]. Available: https://neo.org/.
[Accessed: 28-Sep-2017].
[4] S. Popov, “The tangle,” 2016.
[5] L. Baird, “Hashgraph consensus: fair, fast, byzantine fault tolerance,” Swirlds Tech Report, 2016.
[6] “Hyperledger Fabric,” Hyperledger. .
[7] H. Wang, K. Chen, and D. Xu, “A maturity model for blockchain adoption,” Financ. Innov., vol. 2, no. 1, p. 12, Dec.
2016.
[8] J. Herbsleb, D. Zubrow, D. Goldenson, W. Hayes, and M.
Paulk, “Software Quality and the Capability Maturity Model,”
Commun ACM, vol. 40, no. 6, pp. 30–40, Jun. 1997.
[9] “ISO/TC 307 - Blockchain and distributed ledger
technologies.” [Online]. Available:
https://www.iso.org/committee/6266604.html. [Accessed:
15-Aug-2018].
[10] “Focus Group on Application of Distributed Ledger
Technology.” [Online]. Available:
https://www.itu.int/en/ITU-
T/focusgroups/dlt/Pages/default.aspx. [Accessed: 15-Aug- 2018].
[11] T. W. R. Team, “The Weiss Cryptocurrency Ratings Explained,” Weiss Cryptocurrency Ratings, 24-Jan-2018. . [12] “Global public chain technology assessment.” [Online].
Available: http://special.ccidnet.com/pub-bc- eval/index.shtml. [Accessed: 15-Aug-2018].
[13] “ICO Reviews Updates,” Crypto Briefing. . [14] “Sales Archive,” Smith + Crown. .
[15] “CoinGecko: 360 Degree Overview of Cryptocurrencies Chart.” [Online]. Available: https://www.coingecko.com/en.
[Accessed: 30-Aug-2018].
[16] “Analysis Overview,” CoinCheckup - Cryptocurrency Analysis Platform. [Online]. Available:
https://coincheckup.com. [Accessed: 30-Aug-2018].
[17] S. Bradner, “Key words for use in RFCs to Indicate Requirement Levels.” IETF, 1997.
[18] J. Poon and T. Dryja, “The bitcoin lightning network:
Scalable off-chain instant payments,” Tech. Rep. Draft, 2015.
[19] Gavin Wood, “Ethereum: a Secure Decentralised Generalised Transaction Ledger Byzantium”, Ethereum yellow paper, 2015.
[20] M. Wohrer and U. Zdun, “Design Patterns for Smart Contracts in the Ethereum Ecosystem”, IEEE Internation Conference on Blockchain, Halifax, 2018.
[21] A. Dika and M. Nowostawski, “Security Vulnerabilities in Ethereum Smart Contracts”, IEEE Internation Conference on Blockchain, Halifax, 2018.
