Blockchain and Cryptocurrency: A comparative framework of the main Architectural Drivers
BBlockchain and Cryptocurrency: A comparative framework ofthe main Architectural Drivers
Martin Garriga
CONICET, National Council forScientific and Technical ResearchBuenos Aires 1400Neuquen 8300, Argentinamartin.garriga@fi.uncoma.edu.ar
Maxmiliano Arias
FidtechIndependencia 596Neuquen 8300, Argentinamaximiliano.arias@fidtech.net
Alan De Renzis
FidtechIndependencia 596Neuquen 8300, Argentinaalan.derenzis@fidtech.net
ABSTRACT
Blockchain is a decentralized transaction and data manage-ment solution, the technological weapon-of-choice behind thesuccess of Bitcoin and other cryptocurrencies. As the numberand variety of existing blockchain implementations continuesto increase, adopters should focus on selecting the best one tosupport their decentralized applications (dApps), rather thandeveloping new ones from scratch. In this paper we presenta framework to aid software architects, developers, tool se-lectors and decision makers to adopt the right blockchaintechnology for their problem at hand. The framework ex-poses the correlation between technological decisions andarchitectural features, capturing the knowledge from existingindustrial products, technical forums/blogs, experts’ feed-back and academic literature; plus our own experience usingand developing blockchain-based applications. We validateour framework by applying it to dissect the most outstand-ing blockchain platforms, i.e., the ones behind the top 10cryptocurrencies apart from Bitcoin. Then, we show how weapplied it to a real-world case study in the insurtech domain.
CCS CONCEPTS • Computer systems organization → Embedded systems;
Re-dundancy;
Robotics; •
Networks → Network reliability;
KEYWORDS
Blockchain, Cryptocurrencies, Software Architectures
ACM Reference format:
Martin Garriga, Maxmiliano Arias, and Alan De Renzis. 2018.Blockchain and Cryptocurrency: A comparative framework of themain Architectural Drivers. In
Proceedings of Sample Conference,, November, 2018 (CONF),
Blockchain is a decentralized transaction and data manage-ment solution, well-known for being the technology behind
Permission to make digital or hard copies of part or all of this workfor personal or classroom use is granted without fee provided thatcopies are not made or distributed for profit or commercial advantageand that copies bear this notice and the full citation on the first page.Copyrights for third-party components of this work must be honored.For all other uses, contact the owner/author(s).
CONF, © 2018 Copyright held by the owner/author(s). xxx-x-xxxx-xxxx-x/xx/xx. . . $15.00DOI: xx.xxx/xxx x the success of Bitcoin cryptocurrency [13]. Its main goal is tocreate a decentralized environment where no third party is incontrol of the transactions and data [26]. This technology isnow mainstream because it solves problems in a way peoplecould not before, generating a business value-add that willreach about $176 billion by 2025 and $3.1 trillion by 2030 .The prime reason behind this expansion is the already wide-spread adoption of blockchain in financial transactions andcross-border payments [6].Even though the most popular blockchain implementationis Bitcoin, a myriad others are currently running or stillin development. Different implementations vary in manyways such as their purpose, governance and efficiency, amongothers.However, no single blockchain by itself can meet the require-ments for all usage scenarios, e.g., those that require real-timeprocessing. When building blockchain-based applications, weneed to systematically consider the key technological featuresand configurations, and assess their impact on quality at-tributes for the overall systems [25]. Moreover, to determinewhich blockchain implementation should be leveraged (oreven if a new one is needed) for a given application, it iscrucial to be familiar with the differences among them [7].In this paper we propose a framework to help softwarearchitects, developers, tool selectors and decision makers toadopt the right blockchain technology for their problemat hand. Even though new blockchains increased exponen-tially up to 2017, nowadays it makes no sense to “reinventthe wheel” by building a custom blockchain from scratchevery time; but rather to leverage, and probably combineexisting, battle-hardened solutions to support new applica-tions. For crafting our framework, we surveyed the knowledgefrom existing industrial products, technical forums/blogs, aca-demic literature and our own experience using and developingblockchain-based applications.Afterwards, we applied the framework to analyze and scorethe most outstanding solutions in the real-world market —i.e., the technology behind the top 11 cryptocurrencies ,giving an overview of the current ecosystem of mainstreamblockchain solutions. We then show how such an assessmentframework can be applied through a real-world case study inthe insurtech domain. For the sake of simplicity we will use the word blockchain to refer toany distributed ledger implementation, except when explicitly clarified. According to their market cap. See: https://coinmarketcap.com a r X i v : . [ c s . CR ] N ov ONF, November, 2018, M. Garriga et al.
The rest of the paper is organized as follows. Section 2provides an overview of key concepts in blockchain and cryp-tocurrencies, as well as related work. Section 4 details ourframework for assessment of blockchain technologies. Sec-tion 5 assesses the top blockchain solutions by means of ourframework and then applies it to a real-world case study.Finally, Section 6 concludes the paper. A blockchain is a distributed ledger, in the form of a totallyordered, back-linked list of blocks [13]. Each block containstransactions that are hashed into a binary hash tree (alsocalled a merkle tree ), with the top (root) of the tree storedalongside the transactions. Each block also contains theprevious block’s hash, thus guaranteeing integrity and deter-minism — i.e., any node replaying all blocks starting fromthe first one (genesis block) should end up with the samestate as every other node [3]. This forbids to call externalAPIs whose responses may change over time . Blockchaindistribution is coupled with trust creation and a consensusmechanism for determining agreement on the next block toadd. Cryptocurrencies have emerged as the first generation ofblockchain-based applications, as digital currencies that arebased on cryptography techniques and peer-to-peer networks.The first and most popular example is Bitcoin [1, 13].One of the fundamental disruptions that blockchain tech-nology is causing is the redefinition of digital trust , whichmanifests itself in a fully distributed way without anyonehaving to trust any single member of the network. The onlytrust required is that, on average, the participants of thenetwork are not colluding against the others in a coordinatedmanner [25].
Transactions are data packages that store information— e.g., monetary value for cryptocurrencies, or results offunction calls for other decentralized applications (dApps).The integrity of a transaction is checked by algorithmic rulesand cryptographic techniques. A transaction, signed byits initiator, is sent to a node connected to the blockchainnetwork, which validates the transaction and propagatesit to other nodes in the network. These also validate andpropagate the transaction to their peers, until it reaches allnodes in the network [25]. Transaction processing involves a transaction fee , given the cost imposed to the network, andas an incentives for nodes to stay honest [13].Transactions are grouped in blocks that are appended tothe existing chain, a process known as mining . The net-work aims to reach a consensus about the next block to beincluded into the blockchain by means of a
Consensus Proto-col . Their features include assuring decentralized governance,quorum structure, authentication, integrity, non-repudiation,byzantine fault tolerance and performance [11]. The de-facto consensus protocol is Proof-of-Work [2] (PoW, the onebehind Bitcoin and Ethereum), which imposes miners tocompute a hash function that should be efficiently verifiable, but parameterisably expensive to compute. Given the ludi-crous energy consumption of PoW , other blockchains optedfor greener but rather centralized options such as Proof-of-Stake [8] (PoS), where miner are limited to a percentage oftransactions that is reflective of his or her ownership stakeof the token, and lately Delegated Proof of Stake (DPoS).Finally, several blockchains provided their own hybrid orad-hoc protocols [16].The first generation of blockchains (e.g., Bitcoin) providedvery limited capability to support programmable transac-tions, apart from value transfer from one account to another.The second generation (e.g., Ethereum [3]) aims to providea general-purpose programmable infrastructure, whose pro-grams are known as smart contracts [21, 25]. Originally,smart contracts were defined as the digital equivalent of apaper contract: an agreement between parties with a set ofpromises that are legally enforceable [21]. Nowadays, anygeneral purpose computation that takes place on a blockchainor distributed ledger is considered a smart contract. Yli-huumo et al. [26] identified that a majority of the blockchain-related papers focused on certain technical challenges: through-put, latency, size and bandwidth, security, wasted resources,usability, versioning, hard forks, and multiple chains [20].In addition, they identified privacy, smart contracts, newcryptocurrencies, botnets, consensus protocols and trust-worthiness. As future research directions, authors highlightscalability issues; other uses beyond cryptocurrency systems(i.e., dApps) and effectiveness of the proposed solutions –.the latter being one of the contributions of our paper. In asimilar direction, Alharby and Van Morsel [1] present a sys-tematic mapping study of smart contracts. They identifiedfour groups according to the challenges tackled: codifying,security, privacy and performance.Scriber [18] performed a literature review and evaluated 23blockchain implementation projects. This evaluation revealed10 architectural or blockchain characteristics that can helpdetermine whether blockchain is appropriate for a givenproblem, namely immutability, transparency, trust, identity,distribution, transactions, historical record, ecosystem andinefficiency. However, from the 23 analyzed projects, onlyfour reached an advanced stage while the others failed or wereabandoned. The paper does not provide insights regardingwhich of the most popular blockchains would be suitable fora given problem.Xu et al. [25], present a taxonomy of blockchain systemsand their architectural characteristics, to assist with the de-sign and assessment of their impact on software architectures.First, authors identify fundamental properties of blockchainnetworks, namely: immutable data, non-repudiation, dataintegrity, transparency, equal rights (of participants), andtrust mechanisms. Other properties include data privacy,scalability, cost and performance. Afterwards, they distilledarchitectural design issues, which impact on such properties:decentralization, support for client storage and computation, https://digiconomist.net/bitcoin-energy-consumption lockchain and Cryptocurrency: A Comparative Framework CONF, November, 2018, scope (public/consortium-community/private), data struc-ture, Consensus protocol and new side-chains. Then, theypropose a series of decisions while designing a blockchain-based systems, that may affect those drivers. However, the de-cisions are intended for the development of a new blockchainrather than evaluating the adoption of an existing one. First consideration for a blockchain implementation is its purpose . This seems obvious, but is truly overlooked bymany architects and developers. Most existing blockchainsare specialized for cryptocurrencies, and might not be agood fit for other applications whose intent is different [7].Purposes are categorized as: • Currencies used for transactions or as a store of value,e.g., Bitcoin, Litecoin , Tether [22]. • Exchanges and Interoperability designed to enablecommunication among different blockchains, e.g.,Binance Coin , 0x . • Data and Cloud Services used to interact with datamanagement or cloud service platforms, e.g., Golem . • dApps Platforms : used as part of a smart contractnetwork or dApps platform, e..g, Ethereum, Car-dano [8], EOS [10]. • Gaming, Media, and Social used for gaming, onlinecontent and social media, e.g., Steem , Tron [19]. • Privacy , with built-in features to facilitate anony-mous or untraceable transactions online, e.g., Mon-ero , Zcash . • FinTech for financial services and technologies, e.g.,Ripple [17], Stellar [12]. • Business/Enterprise helps businesses improve effi-ciency, transparency, and security, e.g., Waltonchain . • Others , for example those related to prediction mar-kets, oracles, IoT or AI projects, e.g., IOTA [15].In the following sections, we define the architectural fea-tures to guide this analysis. Alongside, we define technologi-cal decisions and the possible values that they may assume,which finally impact on the features (see Table 1 for a sum-mary).
Altough adopting a blockchain is theoretically free, at leastthree aspects impose a cost for using the network: a variablecost for running transactions, composed by the transaction See https://goo.gl/rDAfkK https://litecoin.org/ https://0xproject.com/ https://golem.network/ https://steem.io/ https://getmonero.org/ https://z.cash/ fee [3] and incentives for processing transactions; and a mini-mal fixed cost to deploy applications (in the form of smartcontracts).The default approach is to have purely voluntary fees withdynamic minimums [13]. However, this approach can becomeprohibitively expensive when the network is congested: forexample, transaction fees in Bitcoin have raised up to 40USD during peaks of workload.On the other end, implementations such as Ripple andTron foster minimal transaction fees to prevent malicioususers to perform DDoS attacks for free. Sitting in the middle,a widely used approach is to define a cost per instructionand then calculate the overall cost of the transaction (as inEthereum), with a maximum limit in order to avoid infiniteloops. Yet another approach is to impose a non-monetaryfee for running transactions. For example, in IOTA, everynode sending a transaction is required to validate two othertransactions, which assures enough processing power.Possible values for the transaction fee are: Minimal (onlyto avoid DDoS attacks), per transaction and per instruction.Possible values for the incentive are: Big (bitcoin-alike) andsmall (equivalent to a fee). Different strategies have been used to confirm that a trans-action is securely appended to the blockchain – that is, toensure strong consistency : wait for a certain number ofblocks (e.g., 6 for Bitcoin, 12 for Ethereum) to have beengenerated after the transaction is strong consistent into theblockchain[25]; add a checkpoint to the blockchain, so thatall the participants will accept the transactions up to thecheckpoint as valid and irreversible. Other implementationsof the distributed ledger (e.g., a DAG) can drastically reducethe time to confirmation as they do not rely on blocks withmultiple transactions, but in transactions that are propagatedindependently in a matter of seconds.Thus, consistency is a function of the time to confirmation (i.e., the number of blocks after which one can consider atransaction securely appended to the blockchain), whichin turn depends on the block production rate (BPR, theamount of time required to mine a block), configured for eachimplementation at design time.Possible values for time to confirmation are: seconds, min-utes and hours. Possible values for block production rate are:10 minutes or more, 1 to 10 minutes and seconds.
Bitcoin’s main intent was to become a decentralized cryp-tocurrency [13]. Rapidly, the idea of applying it to otherconcepts and decentralized application (dApps) emerged, e.g.,for name registration and tokens for corporate use [3], beingmore flexible and extensible through smart contracts. Someimplementations support turing-complete smart contractsusing ad-hoc languages (Solidity in Ethereum, Plutus in Car-dano), while others support traditional languages (such as
ONF, November, 2018, M. Garriga et al.
C++ in EOS) that are then compiled/transpiled to a byte-code. However, the latter are not fully supported yet in anyof the existing blockchain implementation.A latter point is interchain communication , allowing multi-ple parallel blockchains to interoperate retaining their securityproperties [9]. Some blockchain implementations provide na-tive support for interchain communication (e.g., EOS), whilecertain frameworks allow it on top of existing implementa-tions (e.g., Cosmos [9]).Possible values for smart contracts are: Yes (specifyingthe language(s)), No, and Very Limited. Possible values for
Interchain communication are: Yes, No.
Decoupling performance (latency and throughput) and scala-bility (with the number of nodes and clients in the system)is not entirely possible [23], thus we will group them to-gether for analysis. Those became the bottleneck for themost popular blockchain implementations, such as Bitcoin(consensus latency of about an hour) and Ethereum. Addi-tionally, PoW-based networks use a lot of power, equivalentto a small country such as Austria [23]. Thus performanceand scalability of permisionless generic blockchains is limitedby their design decisions [24], namely sequential execution oftransactions and hard-coded consensus protocol.Scalability, in turn, refers to the ability to maintain perfor-mance indicators when serving more users and transactions,limited by: (i) the size of the data on blockchain, (ii) thetransaction processing rate, and (iii) the latency of datatransmission. Roughly speaking, PoW offers good scalabil-ity with poor performance, whereas other protocols offergood performance for small numbers of replicas, with limitedscalability. Given seemingly inherent tradeoffs between thenumber of nodes and performance, it is not clear today whatthe optimal blockchain solution is, for the majority of usecases in which the number of nodes ranges from a few tensto a few thousands.Conclusively, performance and scalability are affected bythe transactions per second (TPS), block production rate,consensus protocol and certain technological choices .Possible values for transactions per second are: less than100, between 100 and 1000; and 1000 or more. Possiblevalues for the
Consensus Protocol are: Proof-of-Work (PoW),Proof-of-Stake (PoS), Distributed Proof-of-Stake (DPoS),and other (specify). Possible values for technological choicesare: Merkle/Patricia trees, Segregated Witness (segwit), datasharding, parallel execution of transactions, GHOST (GreedyHeaviest Observed Sub-Tree), Lightning Network, and other(specify).
One of the main features of blockchain is that its publicledger cannot be modified or deleted after the data hasbeen approved by all nodes, providing data integrity andsecurity characteristics [26]. Security issues mean bugs orvulnerabilities that an adversary might utilize to launch an attack. Currently, the most secure implementations are PoW-based. Even though, they have a possibility of a 51% attack,where a single entity would have full control of the majorityof the network’s mining hash-rate and would be able tomanipulate it.Alternative consensus protocols such as PoS and DPoSmay provide better performance and/or scalability, but theyimply a tradeoff w.r.t. security: most tolerate up to 1/3(33%) of malicious nodes. Other algorithms implementingByzantine Fault Tolerance (BFT, e.g., the Ripple ConsensusProtocol) may improve security up to 2/3 malicious nodes,but they impose additional restrictions such as requiringnodes to know each other.Security is thus affected by the following technologicaldecisions:
Fault tolerance (possible values are 2/3 attack, 1/2attack, 1/3 attack, and other); ledger implementation (possi-ble values are Blockchain, DAG, and other); and consensusprotocol . Theoretically, blockchain does not rely on any centralizednode or authority, allowing data to be recorded, stored andupdated in a distributed fashion. However, some blockchainsintroduce certain degree of centralization. In case of public,permissionless blockchain, no centralized authority or partyhas more power than the rest (Bitcoin), and everyone hasthe right to validate a transaction [23].In the case of consortium, permissioned blockchain, onlyfew nodes are given certain privileges over validation (PoS-and DPoS-based ones such as EOS). A fully private blockchainhas a centralized structure with the power to take decisionsand control the validation process (e.g., Ripple and the RippleConsensus Protocol). Permissioned blockchains are faster,more energy efficient and easily implementable comparedto permissionless blockchains, but introduce certain degreeof centralization. Thus, the decentralization degree is con-strained by the consensus protocol , and the ledger implemen-tation . The initial list of features and decisions extracted from theliterature was a subset of the ones in Table 1. Those weredelivered to a group of three experts, comprising researchersand industry practitioners. They evaluated the list andsuggested to add, remove, group, or decompose concepts,and pointed out correlations, based on their own expertise.Then, we proceeded to extract the technological featureslying under the most popular blockchain implementations, ac-cording to their market cap . Even though we acknowledgeother possible ways to measure popularity — e.g., numberof wallets, number of exchanges, transaction volume, etc. —they usually converge to a similar ranking at a given pointin time [6]. Popularity is not affected by the technical de-cisions behind the implementation, but may impact certain source: http://coinmarketcap.com, July 2018 lockchain and Cryptocurrency: A Comparative Framework CONF, November, 2018, Table 1: Correlation between Architectural Features andTechnological Decisions
TechnologicalDecision Architectural FeatureCost Consis-tency Function-ality Perfor-mance Security Decentra-lizationFees xIncentive xConfirmationTime xBlock Pro-ductionRate x xSmartContracts xInterchain xConsensus x xTechnology xFaultTolerance xLedger x xTPS x features of the blockchain such as cost, time to confirmationand security. Additionally, the popularity of the underlyingblockchain may be the key enabler for the success of a dApp,as demonstrated by the myriad of dApps in Ethereum and the limited offer in others. All in all, the technologicalanalysis of the different blockchains is summarized in Table 2.Based on the identified architectural and technologicalaspects, we conducted a second round of feedback throughstructured interviews with the experts, in order to comeup with a quantitative assessment of the top blockchainsolutions. They completed a questionnaire , assigning scoresfor each architectural feature to the different blockchainimplementations (from very low to very high ) which werethen fuzzified into numerical scale from 1 to 5. For example,if an expert considers that Bitcoin has a very high
Cost , thenin the questionnaire she marks the corresponding cell as “veryhigh”.Experts fulfilled the scorecards as described above, alsodeclaring their confidence (fuzzified from ”low” to ”veryhigh”). Both the confidence values and the scores werethen defuzzified using a triangular membership function [14]and combined on a weighted average scheme. The triangularfunction allows one to map and normalize the linguistic scaleto a given scale, in the range [1 ,
5] for the scores and [0 , , https://github.com/avadhootkulkarni/UltimateICOCalendar https://goo.gl/forms/8mE1mdJ55VJRJw2E3 being able to select the most suitable one for their problemat hand, as illustrated in the following section. From the analysis of literature, top blockchain implementa-tions, and feedback from experts, we were able to identifysome open challenges and concerns regarding the future ofthe field. Although all blockchain implementations promiseto be secure and efficent, most of them fall short in some ofthese aspects. Particularly, Proof-of-Stake and DistributedProof-of-Stake blockchains are risky since critical decisionsfall on a small group of people or company. Even though, intraditional implementations based on Proof-of-Work, group-ing of miners into mining pools are effectively centralizingthese networks [5].In this direction, platforms with the potential to be scalableand energy-efficient will be the weapon-of-choice for dAppsdevelopment. Other “legacy” blockchains such as Bitcoinwill remain for big, sporadic transactions and as long-terminvestment.Blockchain is still an emerging technology, thus not a lotof developers are concerned with the principles of SoftwareEngineering applied to blockchain-based systems. Moreover,the lack of guidelines and standards on how to design softwarearchitectures that include smart contracts as part of thesystem calls for further attention [4, 25].Finally, only a handful of experiences in real-world dAppsexist , and still a lot of controversy on whether an appli-cation requires the use of blockchain. The emergence offrameworks like the one presented in this paper may help toovercome such difficulties.As threats to validity for our approach, we can highlight thefollowing. First, the short number of experts that participatedin the analysis. This might result on a possible bias, butavoids the answers to be meaningless because of the lack ofexperience of surveyed experts. One should also note thatthe number of experts in the blockchain world is not that big.Another concern is the number of analyzed cryptocurrencies,since among the top ones there is Bitcoin itself and twoBitcoin forks (Litecoin, Bitcoin Cash). Some revolutionaryapproaches may have not gained momentum yet, reasonwhy we are planning to extend our analysis, covering moreimplementations. In this section we illustrate the value of our framework toassess blockchain alternatives for a real-world application.Photofied is a mobile application developed by Fidtech, asa solution for worldwide insurance activity. It certifies digitalimages in the blockchain for fraud prevention, granting relia-bility of the status of an insurable risk, both at policy emis-sion and execution stages. All images taken with Photofiedare certified by means of an ad-hoc protocol, namely ThreeWay Certification (3WC). 3WC features blockchain, a P2P https://dappradar.com/ https://photofied.tech ONF, November, 2018, M. Garriga et al. T a b l e : Q u a li t a t i v e a ss e ss m e n t o f t h e m o s t p o pu l a r b l o c k c h a i n a l t e r n a t i v e s a cc o r d i n g t o t h e t e c hn o l og i c a l c h a r a c t e r i s t i c s B i t c o i n ( B T C ) E t h e r e u m ( E T H ) R i pp l e ( X R P ) B i t c o i n C a s h ( B C H ) E O S ( E O S ) L i t e c o i n ( L T C ) S t e ll a r ( X L M ) C a r d a n o ( A D A ) I o t a ( M I O T A ) T e t h e r ( U S D T ) T r o n ( T R X ) P u r p o s e C u rr e n c y P l a t f o r m F i n t ec h C u rr e n c y P l a t f o r m C u rr e n c y F i n t ec h P l a t f o r m O t h e r( I o T ) C u rr e n c y M e d i a/ S o c i a l F ee s P e rtr a n s a c t i o n P e r I n s tr u c t i o n ( c o n fi g - u r a b l e ) M i n i m a l P e r T r a n s a c t i o n P e r i n s tr u c t i o n P e rtr a n s a c t i o n P e r o p e r a t i o n P e rtr a n s a c t i o n s i ze A pp r o v e tr a n s a c t i o n s U S D M i n i m a l I n c e n t i v e . B TC / h a s h C o n fi g u r a b l e N / A . B C H / h a s h C o n fi g u r a b l e ( b y B P s ) . L TC N / AA v a il a b ili t y b a s e d N / AN o C o n fi g u r a b l e ( b y S R s ) B l o c k P r o d - u c t i o n r a t e m i n - s ec N o t s p ec i fi e d m i n . s ec . m i n s ec o nd s s ecc o n fi g u r a b l e N / A m i n s ec C o nfi r m a - t i o n t i m e m i n ( b l o c k s ) m i n s ec o nd s m i n s ec o nd m i n ( b l o c k s ) s ec o nd s m i n m i n ( s c a l a b l e ) m i n ( b l o c k s ) m i n T P S + + + + S m a r t c o n t r a c t s V e r y L i m i t e d Y e s V e r y L i m i t e d V e r y L i m i t e d Y e s V e r y L i m i t e d V e r y L i m i t e d Y e s N o N o Y e s d A pp s N o Y e s N o N o Y e s N o N o Y e s Y e s , I o T l e v e l V e r y L i m i t e d Y e s L a n g u a g e s C ++ , S c r i p t S o li d i t y A n y S c r i p t A n y S c r i p t A n y F un c t i o n a l A n y R ub y J a v a I n t e r c h a i n N o N o N o N o Y e s N o N o Y e s Y e s N o Y e s C o n s e n s u s A l go r i t h m P o W ( s h a - ) P o W ( e t h a s h ) P o C ( R i pp l e C P ) P o W ( s h a - ) D e l e ga t e d P o S P o W ( s c r y p t) F e d e r a t e d B F T S t e ll a r C P P o S ( O u r b o r o s ) M a r k o v C h a i n ( M C M C ) P o R ( O m n i ) P o S ( T e nd e r - m i n t) E nh a n c e d T e c hn o l og y M e r k l e T r ee s , S e g w i t P a tr i c i a T r ee s , Sh a r d i n g – M e r k l e T r ee s M e r k l e P r oo f s , S e g w i t M e r k l e T r ee s , S e g w i t – Sh a r d i n g T a n g l e f o r I o T S c a l e M e r k l e tr ee s , S e g w i t G r a phd a t a b a s e F a u l t T o l e r a n c e % C P U a tt a c k % e t h e r a tt a c k %m a l u s n o d e s % C P U a tt a c k % B l o c k P r o du ce r s % C P UA tt a c k A s y m p t o t i c S ec u r i t y A s y m p t o t i c S ec u r i t y % C P U a tt a c k % C P UA tt a c k % B y z a n t i n e F a il u r e L e d g e r B l o c k c h a i n B l o c k c h a i n I n t e r l e d g e r P r o t o c o l B l o c k c h a i n B l o c k c h a i n B l o c k c h a i n B l o c k c h a i n B l o c k c h a i n D i r ec t e d A c y - c li c G r a ph B l o c k c h a i n B l o c k c h a i n lockchain and Cryptocurrency: A Comparative Framework CONF, November, 2018, Table 3: Quantitative assessment of blockchain solutions according to experts’ feedback regarding architectural decisions.
BTC ETH XRP BCH EOS XLM LTC ADA USDT MIOTA TRX
Popularity 1 2 3 4 5 6 7 8 9 10 11
Cost 1.33 2 4.66 1.66 5 4.66 2.66 4.33 5 5 5Consistency 1.33 2.33 4.33 1.33 5 4 2 3.66 1 4.66 4Functionality 2 5 1.33 2 5 1.33 2 4.33 2 3.66 5Performance 1.33 1.66 4.33 2 4.66 4 2.33 3 1 5 4.66Security 4 4 2.33 4 3.33 4 4 4 3.33 3.66 3.33Decentralization 5 3.33 1 4.33 2.66 2.33 3.66 3.33 1.33 2.33 3.33
Total distributed file system and digital signature to grant theimmutability, perdurability and verifiability of the images.Figure 1 depicts the architecture of the application, whereinsurance agents or car owners use the mobile app (1) tosend packages (containing images and metadata to certify)to the Rest API. The server forwards the package to theEOS smart contract and the p2p FS (2). After that, eachcertification is printed to PDF, allowing offline audit (3). Atany time, insurance companies can access the certificationsusing a Web interface.As a first stage, Photofied is used during the policy emissionprocess, certifying the images taken by the insurance agent.The images are later audited only if needed, thus there is noneed for fast transaction confirmation.End users are neither supposed to know about blockchainor cryptocurrencies and/or own accounts; nor responsible forpaying for the service — thus, Cost should be low to attractinsurance companies as potential customers.Also, as images can be captured either by insurance agentsor car owners, the application needs to identify who took theimages, when, and where, providing functionality and flexi-bility. Each image should be independently certified, whichimplies a high number of transactions, calling for perfor-mance. Additionally, security and consistency are concernsto maximize, granting the trustability of certified images.Each certification, containing images and metadata (user-name, GPS coordinates and mobile device’s information),has to be auditable by third parties without using Photofiedservices/servers (i.e., by querying directly the underlyingblockchain).At application’s design time, the developers were not awareof all the advantages and drawbacks of each blockchain plat-form. A first selection, purely based on popularity, led first toa Bitcoin-based implementation and then an Ethereum-basedone. The former used a na¨ıve (
Data hash → Timestamp )structure, given the lack of proper smart contracts support inthe Bitcoin blockchain. The latest used a smart contract thatstored a mapping from each uploaded piece of informationto the account from which it was uploaded along with somemetadata.
Figure 1: Photofied architecture overview
However, both implementations suffered the drawbacks ofthe underlying blockchains (See Table 2 and Table 3), requir-ing an expensive transaction fee and relying on congestednetworks, with a prohibitively low number of transactions persecond. In parallel, the number of novel blockchain platformsincreased exponentially, paving the way for the adoption of amost suitable one. After crafting the comparison frameworkand fine-tunning the importance for each feature, the mostsuitable options were EOS and TRON, due to the nonexis-tent fee, high transactions per second and high reliability. Tountie, EOS was selected based on its popularity, as it impliesmore active developers, nodes, available dApps and support-ing community. Also, by that time, the TRON mainnet wasnot yet online and had no near release date.All in all, the current version of Photofied is running usingEOS in a collaborate effort with EOS Argentina , one ofthe top block producers on the EOS blockchain. The smartcontract that handles all the needed data is managed by acustom account in charge of time-stamping transactions —combining block timestamp and server timestamp. This way,end users don’t need an EOS account, the application can ONF, November, 2018, M. Garriga et al. run on mobile devices as it uses a central server that man-ages the transactions (ensuring high transactions per secondand reliability). Finally, as EOS is a public, decentralizedblockchain, each piece of certified data can be audited fromany EOS node.
Nowadays, the number and variety of existing blockchainimplementations continues to increase. Adopters should fo-cus on selecting the best one — rather than developing yetanother one from scratch — to support their decentralizedapplications (dApps). In this paper we presented a frame-work to aid software architects, developers, tool selectorsand decision makers to adopt the right blockchain technologyfor their problem at hand. The framework exposes the cor-relation between technological decisions (such as consensusprotocols and support for smart contracts) and architecturaldecisions (such as cost and decentralization). For craftingour framework, we surveyed the knowledge from existing in-dustrial products, technical forums/blogs, experts’ feedbackand academic literature; plus our own experience using anddeveloping blockchain-based applications.We have shown the suitability of our framework in twoways. First, we applied it to analyze the most popularblockchain implementations in the real world, according totheir market cap. This shed light regarding the currentecosystem of mainstream blockchain solutions. Second, weshown how the framework can be applied by dApps developersthrough a real-world case study: a trusted images applicationfor the insurtech domain. Developers were able to successfullyselect a new blockchain and migrate their application basedon the insights obtained from the framework.Our future work comprises fine-tunning the frameworkby engaging yet more experts from the blockchain world.Afterwards we plan to assess the top 50 implementations tohave a complete panorama of the existing solutions, beyondthe Bitcoin and Ethereum hype. Finally, we are currentlydeveloping a series of questions in the form of a wizard, toguide practitioners in the use of our framework for selectingthe most suitable blockchain.
ACKNOWLEDGMENTS
The authors would like to thank to Nicolas Arias, DiegoAnabalon, Nahuel Vazquez and Claudio Arce from Fidtech,for their helpful insights. This work is partially supportedby ANPCyT project PICT-1725-2017 and CONICET.
REFERENCES [1] Maher Alharby and Aad van Moorsel. 2017. Blockchain-basedsmart contracts: A systematic mapping study. arXiv preprintarXiv:1710.06372 white paper (2014). [4] Giuseppe Destefanis, Michele Marchesi, Marco Ortu, RobertoTonelli, Andrea Bracciali, and Robert Hierons. 2018. Smart con-tracts vulnerabilities: a call for blockchain software engineering?.In
Blockchain Oriented Software Engineering (IWBOSE), 2018International Workshop on . IEEE, 19–25.[5] Arthur Gervais, Ghassan Karame, Srdjan Capkun, and VedranCapkun. 2014. Is bitcoin a decentralized currency?
IEEE security& privacy
12, 3 (2014), 54–60.[6] Garrick Hileman and Michel Rauchs. 2017. Global cryptocurrencybenchmarking study.
Cambridge Centre for Alternative Finance (2017).[7] Zane Hintzman. 2017.
Comparing Blockchain Implementation .Technical Report. SCTE/ISBE Society of Cable Telecommunica-tion Engineers and International Society of Broadband Experts,Exton, PA, USA.[8] Aggelos Kiayias, Alexander Russell, Bernardo David, and RomanOliynykov. 2017. Ouroboros: A provably secure proof-of-stakeblockchain protocol. In
Annual International Cryptology Con-ference . Springer, 357–388.[9] Jae Kwon and Ethan Buchman. 2016. Cosmos: A network ofdistributed ledgers.
URL https://cosmos. network/whitepaper (2016).[10] Daniel Larimer et al. 2018.
EOS Whitepaper . Technical Re-port. block.one. https://github.com/EOSIO/Documentation/blob/master/TechnicalWhitePaper.md.[11] Juri Mattila et al. 2016.
The blockchain phenomenon–the disrup-tive potential of distributed consensus architectures . TechnicalReport. The Research Institute of the Finnish Economy.[12] David Mazieres. 2015. The stellar consensus protocol: A feder-ated model for internet-level consensus.
Stellar DevelopmentFoundation (2015).[13] Satoshi Nakamoto. 2008. Bitcoin: A peer-to-peer electronic cashsystem. (2008).[14] Witold Pedrycz. 1994. Why triangular membership functions?
Fuzzy Sets and Systems
64, 1 (1994), 21 – 30. https://doi.org/10.1016/0165-0114(94)90003-5[15] Sergei Popov. 2017.
IOTA Whitepaper . Tech-nical Report. IOTA Foundation, Berlin, Germany.http://iotatoken.com/IOTA Whitepaper.pdf.[16] Lakshmi Siva Sankar, M Sindhu, and M Sethumadhavan. 2017.Survey of consensus protocols on blockchain applications. In
Advanced Computing and Communication Systems (ICACCS),2017 4th International Conference on . IEEE, 1–5.[17] David Schwartz, Noah Youngs, Arthur Britto, et al. 2014. TheRipple protocol consensus algorithm.
Ripple Labs Inc WhitePaper
IEEE Software
35, 4 (2018), 70–77.[19] Justin Sun et al. 2017.
Tron Whitepaper . Technical Report. tronnetwork, Beijing, China. https://tron.network/.[20] Melanie Swan. 2015.
Blockchain: Blueprint for a new economy .” O’Reilly Media, Inc.”.[21] Nick Szabo. 1997. Formalizing and securing relationships onpublic networks.
First Monday
2, 9 (1997).[22] Tether International. 2018.
Tether Whitepaper . Technical Report.Tether International Limited, Hong Kong. https://tether.to/wp-content/uploads/2016/06/TetherWhitePaper.pdf.[23] Marko Vukoli´c. 2015. The quest for scalable blockchain fabric:Proof-of-work vs. BFT replication. In
International Workshopon Open Problems in Network Security . Springer, 112–125.[24] Marko Vukoli´c. 2017. Rethinking permissioned blockchains. In
Proceedings of the ACM Workshop on Blockchain, Cryptocur-rencies and Contracts . ACM, 3–7.[25] Xiwei Xu, Ingo Weber, Mark Staples, Liming Zhu, Jan Bosch,Len Bass, Cesare Pautasso, and Paul Rimba. 2017. A taxonomyof blockchain-based systems for architecture design. In
SoftwareArchitecture (ICSA), 2017 IEEE International Conference on .IEEE, 243–252.[26] Jesse Yli-Huumo, Deokyoon Ko, Sujin Choi, Sooyong Park, andKari Smolander. 2016. Where is current research on blockchaintechnology? A systematic review.