Sina Rafati Niya, Burkhard Stiller

BAZO: A Proof-of-Stake (PoS)based Blockchain

March 2019

University of ZurichDepartment of Informatics (IFI)Binzmühlestrasse 14, CH-8050 Zürich, Switzerland ifi

TE

CH

NIC

AL

RE

PO

RT

–N

o.IF

I-201

9.03

S.Rafati, Burkhard Stiller: BAZO: A Proof-of-Stake (PoS) based BlockchainTechnical Report No. IFI-2019.03, March 2019Communication Systems Group (CSG)Department of Informatics (IFI)University of ZurichBinzmühlestrasse 14, CH-8050 Zürich, SwitzerlandURL: http://www.csg.uzh.ch/

BAZO: A Proof-of-Stake (PoS) based Blockchain

Sina Rafati Niya, Burkhard StillerCommunication Systems Group CSG, Department of Informatics IfI,

University of Zurich UZH, Binzmuhlestrasse 14, CH-8050 Zurich, SwitzerlandEmail: [ rafati | stiller@ifi.uzh.ch]

Abstract—Blockchains (BC) are back-linked chain ofrecords termed as blocks. To establish decentralizedtrusted systems, BC employ consensus mechanisms. Dur-ing the past ten years, there have been various proposalsof BC design and implementations. However, most of thedeveloped sate of the art BC suffer from high powerconsumption of miners and low transaction rates in thewhole blockchain network. This paper proposes a Proof-of-Stake (PoS)-based blockchain (especially here the BAZOapproach), which is designed to enhance efficiency prob-lems of Proof-of-Work (PoW)-based BCs. BAZO enhancesthe randomness degree in next validator selection in PoSconsensus mechanisms at each block height.Having devel-oped the transaction aggregation and double linked blocks,BAZO has enabled the featured for further scalability.Evaluations of this BAZO blockchain outline the efficiencyof the design in tackling the 51% attack, double spending,and grinding attacks with avoiding centralization.

I. INTRODUCTION

Blockchain (BC) BCs distribute data storagein terms of records within back-linked lists.Blockchains as decentralized networks of blocksare obliged to offer a sophisticated structure tosupport different applications. To provide trust inthese decentralized systems, various methods ofconsensus mechanisms have been developed forBC systems. The most used and prominent one isthe Proof-of-Work (PoW) of the Bitcoin BC andcryptocurrency [2]. The second most used method isthe Proof-of-Stake (PoS) mainly used in Tendermintand many recent BC developments [3]. The mostimportant characteristics of consensus algorithmsinclude scalability, transaction rate, transmissiondelay, power consumption, security, and privacy,which determine very practical dimensions of BCand their applicability for real applications [9].

consensus mechanisms play a critical role. Con-sensus between validators on the validity of eachtransaction in the BC creates trust. Different con-

sensus algorithms are proposed and used to validatetransactions toward the accuracy and trust of thesesystems, such that the coherent blocks of transac-tions can be reached [3].

Users in BC trust to this system even though theydo not or cannot trust other parties of transactions.Users by trusting to those miners or validators cantrust to the whole system Users in BC trust to thissystem even though they do not or cannot trust otherparties of transactions.

Proof-of-Work (PoW) is the proof of the attempteach miner puts to mine a new block. The attemptto find a new nonce, with which the hash functionproduces the output in the range of a requestedtarget is the outcome of many iterations of thehashing function being applied and to solve a cryp-tographic hash puzzle [12].An important effort isneeded to find such a new nonce in the competitiveenvironment of miners. Each miner’s success isdependent on its computing power in proportion tothe computing power of all miners, thus, leadingto a large energy demand. Typically, two financialincentives for miners exist to participate in PoW-based BCs: (a) the fund they receive as a reward ofmining a new block and (b) the fund they receivefor validating a transaction [14]. A single miner witha limited computational power may not be able tomine a single block in years, that is why usuallyminers gather and create mining pools. These min-ers share their information in mining pools to minea block and eventually, they share the revenues [6].

Proof-of-Stake (PoS) determines a category ofconsensus algorithms, which provide significant im-provements in terms of electricity consumption andscalability over PoW. A PoS consensus algorithmcan be described as follows: A validator is a nodein the network that validates transactions and addsthem to the BC - as done with PoW, too. Any node

in the system can become a validator by depositingtokens of an associated cryptocurrency, which isdifferent compared to PoW. These tokens depositedcannot be spent as long as the validator is part of thevalidator set. Thus, these deposits are used to punishmalicious nodes, since they have not check thevalidity of previous transactions in previous blocks.Validators are elected proportionally to the fundsdeposited for appending the next block to the BC.The right to add the next block is determined in adecentralized selection procedure depending on thenumber of tokens deposited by each validator. Thiscategory of PoS consensus mechanisms consistsof many different algorithms and protocols, whereeach offer the tasks of a random validator’s electionand a reward system, all these challenges addresseddifferently.

Some of the problems experienced with variousaspects of using PoW-based BC regarding cost andtime deficiencies are compared with PoS as follows:

Environmental Harm: Digiconomist [1] reportsthat the Bitcoin BC consumes more than 36 TWhannually. This amount is more than the entire nationof Bulgaria consumes every year. In other terms, theBitcoin BC uses as much electricity as more than 3million households together.

Thus, in order to maintain the Bitcoin BC theglobal mining costs amount to over 5 million USDevery day.In contrast, there is no need for an exten-sive computation task in a distributed system usinga PoS consensus mechanism in order to reach acomparable level of security.

Detailed explanation of all sections in this workis provided in [13] and here, due to the page numberlimitations, only the most important aspects arecovered.

Risk of Centralization in Form of MiningPools: The chances of adding a new, valid blockfor an individual miner with a PoW-based BC isextremely low [10]. Therefore, miners can joinmining pools, where their computational power iscollaboratively deployed. However, if these miningpools joined together, the Bitcoin BC would bevulnerable to a 51%- attack, where these miningpools could always provide a longer competingchain than the currently accepted one [5]. Therefore,the Bitcoin BC would be controlled by a singlecentralized entity.In contrast, the need for a constant

revenue stream is not required in a PoS system,since the validator does not have to be compensatedfor resources burned. Therefore, the formation oflarge validator sets is less likely.

Risk of Centralization in Form of Cloud Min-ing: Cloud-mining allows people to mine cryp-tocurrencies without owning mining hardware [19].Companies providing cloud-mining services profitfrom the economies of scale, such as special dealson hardware orders and lower maintenance costs.Therefore, these companies gain a economic ad-vantage over individual miners and may force themout of the market. Since no specialized hardware isneeded for a PoS system, centralized cloud compa-nies do not provide any significant advantage.

Entry Barrier: A miner in a PoW-based sys-tem, including specialized hardware, gains an ad-vantage over the competition, whereas in a PoS-based system a validator can only generate revenueproportionally to his/her deposits in the system. Theentry barrier of becoming a validator in a PoS-based system is, therefore, significantly lower thanbecoming a miner in a PoW-based system.

Discrepancy between Miners and Non-Miners:Another advantage of PoS protocols is that thediscrepancy between mining and non-mining nodescan be considerably lowered [10]. Practically, anymachine with a sufficient amount of storage andbandwidth can be part of the validator set. There-fore, the community is less split up as it occurs tobe in PoW-based systems.

51% Attack: In the initial phase of a new BC thenumber of validators/miners is limited. This posesa great risk of a 51% attack, indicating that 51%of all miners collude. A malicious user can buymining hardware, such that he/she possesses at least51% of the total hashing power of the network. Thisuser can produce a longer competing chain than theremainder of the network. Since the BC protocolalways follows the longest competing chain, there-fore, the malicious user has control of the entireBC. The developers of a PoS-based system canhold back 51% of all coins until the network isestablished in order to prevent such an attack byan outsider.

Transaction Fees: Transaction fees – determin-ing the incentives to persist a block in a givenBC – prevent a BC from being spammed, but also

2

compensate miners for their computational effortand electricity costs. However, no resources areburned within a PoS consensus mechanism and,therefore, the transaction fees should be loweredsignificantly.

The presented work here covers the design of thePoS-based BAZO BC. Thus, BAZO increases thesecurity of the system against the risks of a 51%-attack. Moreover, the scalability and BC size areconsidered and transaction aggregation methods aredeveloped. Since it is very difficult to implementa fully decentralized PoS, the form of a delegatedPoS (DPoS) or a PoS/PoW combination scheme isconsidered for BAZO, still reaching those targets.

This paper is organized as follows, Section ??explains the PoS and PoW consensus mechanismswith the focus on the problems of PoW whichcould be addressed by PoS BC.Also, the challengesof developing PoS-based BC are explained in thisSection. Section II introduces the PoS based pro-posals of related implementations. In Section IIIdesign of the proposed PoS BC is described andevaluations done in Section V. At the end of thispaper, concluded points are presented in the SectionXI.

A. PoS Challenges

key challenges to be met while developing PoSconsensus mechanisms include (a) mechanismsneeded to prevent nodes from double spending,(b) manipulation of the random election, (c) DoSattacks, and (d) the difficulty of keeping validatorsonline at all times.

1) Nothing-at-Stake (Double Spending) Problem:In the case of BC forks, which sees multiple side-chains competing with each other at the same time,a validator needs to decide on two or more options,where to add the next block. Unlike in PoW, PoSdoes not ”burn” resources in the process of findinga random node in the network. This allows thevalidator to append a block on any of the compet-ing chains. Therefore, it is a potential validator’sincentive to build on top of every competing chain.This strategy assures that the suggested block willmost likely be included in the chain, which will beaccepted by the network finally.

If all validators act economically and append theirblock on every competing chain, the blockchain

Fig. 1: Competing Chains in PoS [4]

will never reach consensus, even if there exist onlyhonest validators. Figure 1 shows how the expectedvalue EV changes depending on the validators strat-egy. The value of p depends on the percentage ofvalidating nodes that received this chain prior toany other chain of the same length. The fractionalamount of the total stake that votes for a particularchain influences p as well. For simplicity it isassumed that the block-reward and transaction feesadd up to exactly one coin for each block. Unlike inPoW, where a mining node would need to split itshashing power in order to vote on multiple chains,PoS allows for potential misuse. Since for PoWthe hash of the previous block is included in thecalculation, as shown in Figure 2, a miner willalways put all his/her mining power into the longestchain, which is the chain that will most likely beaccepted by the network.

Fig. 2: Competing Chains in PoW [4]

In the context of PoW, the probability p of a chaindepends on the percentage of mining nodes thatreceived this chain prior to the any other chain of thesame length. The fraction of the total hashing powerthat is put into each chain influences the likelihoodp as well. Consequently, miners have to make adecision on what competing chain they want tocontinue, if they have two or more competing chainsof the same length. This results in a separation of

3

miners and, therefore, p has to add up to exactly 100percent over all competing chains of all miners.

As previously described, rational validators in aPoS system append a block on every competingchain. Therefore, the sum of the amount of votingpower from all competing chains can be morethan 100 percent. his property is described in thefollowing scenario and shown in Figure 3. Afterblock a is added, two validators F and G appenda block at the same time, which results in a forkwith two competing chains. Every validator wantsto make sure that his/her block will be included inthe finalized BC. Therefore, every following block isadded on both chains, too. With the assumption thatvalidator F has a staking power of 1% and validatorG of 2%, all the validators between block f and ymake up for the total stake of 96%. At the time ofadding block y, the upper chain has a staking weightof 98% and the lower chain of 97%. The sum of theamount of voting power of both competing chainsin this example is 1.96, well above 1.

Fig. 3: Staking Weights in PoS [4]

A malicious user Z can take advantage of sucha situation and double spend his/her coins. A trans-action that is included in block g, but not in f,can easily be reversed by appending a new blockz on only that subchain, where block g is notincluded. Therefore, after user Z added block z, thechain containing block f and z has a higher stakingweight and will be accepted by the network (cf.Figure 4). In this example the malicious user hasdouble spent his/her coin with only 2% of the totalstake. To ensure a secure implementation of PoS, aPoS consensus protocol has to implement a schemeallowing validators to be punished for appendingnew blocks on multiple chains at the same height.

2) Grinding Attacks: If validators were able tomanipulate the random election process of a consen-sus algorithm, grinding attacks happen. For exam-

Fig. 4: Double Spending in PoS [4]

ple, a poor design is, when the election process de-pends on the previous block hash. The node whichis elected for adding a block can manipulate theblock-hash by in- or excluding certain transactionsor trying many parameters, which results in differentblock hashes. Hence, this node can grind throughmany different combinations and choose the onethat reelects itself with a high likelihood for thenext block. Therefore, the protocol needs to ensurethat parameters for the random election processcannot be modified at commitment time. This canbe achieved by committing to a piece of informationfar in advance and is described in more detail in theSection III-A1.

3) Denial-of-Service (DoS) Attacks: If the ran-dom election process is determined in a publicmanner, the elected validator is known ahead of timeand the protocol is vulnerable to Denial-of-Service(DoS) attacks. Therefore, it is advantageous to runthe election process privately. In a PoW protocol,the election process is done in a way that eachvalidator independently tries to find a solution toa mathematical puzzle. These puzzles are differentfor every miner. A malicious user cannot predict,which node solves this puzzle first. Thus, the electednode cannot become a victim of a DoS attack unlessthe malicious user attacks every single node in thenetwork. The same level of unpredictability in theelection processes as in PoW is desired for a PoSprotocol.

4) Availability: Many different parties compet-ing for the next block decrease the possibility ofappending multiple consecutive blocks by a singlevalidator. Hence, the network becomes more securewith every additional validator. There are PoS proto-cols, where the probability of adding the next blockincreases proportionally to the time that a validatorhas not been elected. Often this is referred to as coinaging and is described by the means of the Peercoinimplementation in Section II-1.

A protocol that includes coin aging incentivizesvalidators for not being online until they reach a

4

high or even the maximum possible coin age. Coinage is accumulated, even if a node is offline. Insuch a scenario a large fraction of the validator setwould be offline most of the time. Therefore, theactual number of competing nodes in the networkis by no means the size of the validator set. Asystem becomes only more secure with additionalvalidators, if these nodes are online and compete forthe next block at any time. A PoS protocol shouldincentivize validators to be online at any given time.

II. RELATED WORK

The two different types of PoS consensus mech-anisms of major importance currently existing are”Chain-Based Protocols” and ”Byzantine Agree-ment Protocols”. Both types consider the amount ofcoins that each validator has deposited in the systemin order to create a payout proportionally to thenumber of coins that are possessed by a validator.

1) Chain-Based Protocols: In this category avalidator is chosen randomly from the validator setin order to append the next block. This randomelection process solely depends on information thatis stored within the BC, such as the ”height” of aparticular block or the amount of coins a validatorpossesses. A selected instance of this approach isPeercoin.

Peercoin: Peercoin or PPCoin assigns the rightof appending a next block to a validator that is incompliance with the condition (1) determined below[7]. A validator must deposit a minimum amount ofcoins to an unspendable address, when joining theset of validators. TxOut represents this transaction,which is different for every validator. Target is aconstant value that determines the speed of theBC. Coins(TxOutA) represents the amount of coinsthat a validator has deposited into the unspendableaddress.

hash(PrevBlockData · TimeInSec · TxOut)

Coins(TxOut) ∗ TimeWeight(TxOut)≤ Target

(1)Peercoin uses ”coin aging” [18] to prevent stake-

holders with a significant fraction of all coins fromadding multiple consecutive blocks. This variable isreset, when a validator has successfully appendeda block. Coin aging makes the protocol vulnerableto attacks. A malicious node can hold back coins

in multiple addresses for a long period of timeto accumulate a large coin age. The likelihood ofbeing elected multiple times in a row is increasedproportionally to the accumulated coin age. Due tothis reason Peercoin limited the maximal amount ofTimeWeight(TxOut) to 90 days in their version v0.3protocol [7].

Peeroin’s random election process is comparableto PoW with one important difference. The onlyvariable parameter is TimeInSec (validators localclock) and, therefore, slows down the hash rate toone attempt per second no matter which hardware isbeing used. In turn, Peercoin is vulnerable to stakegrinding attacks, where a validator can influenceparameters in order to reach a higher probabilityto be re-elected for the next block. This is possible,because the data of the previous block is includedin the PoS condition [4].

2) Byzantine Agreement Protocols: In this cate-gory validators agree upon the next block by meansof a multi-round voting process. Validators are ran-domly selected in order to propose the next block.Each validator has a voting power according tohis/her stake in the system. In each round validatorscan commit to a block. If they agree to the blockproposed and if the block receives a majority ofvotes, it is considered to be valid. All messages thatare used for proposing a new block or committingto a block are handled by a gossip protocol. Thismeans none of these messages are recorded on theblockchain. A selected instance of this approach isAlgorand.

Tendermint: In Tendermint (cf. Figure 5) a val-idator contributes to the consensus by signing votesfor proposed blocks. Each round is split up in threesteps: Propose, Prevote, and Precommit, followedby two special steps called Commit and NewHeight.In every round a validator is nominated as a blockproposer in round-robin fashion. The frequency ofbeing selected depends on the validators stake. Thehigher the stake the higher the chances of beingelected. The elected validator creates a block andbroadcasts it as a proposal. All other validatorslisten for the broadcasted block. Every validatorhas to make a decision during ”Prevote” step. Avalidator can accept the block by broadcasting asigned Prevote message. If a node has not receivedany proposal or an invalid block, it signs and

5

broadcast a Nil Prevote [11]. In the ”Precommit”step, each node validates if it received more than 2

3of the total Prevotes. In this case the validator signsand broadcasts a Precommit message. At the end ofthis step a note decides again if it received morethan 2

3of Precommits. Depending on this decision

the validator either enters the Commit step or startsa new round in the Propose step with a slightlyincreased time period for each step.

Fig. 5: Tendermint State Machine

Algorand: Algorand’s PoS protocol is similar toTendermint with significant improvements. Whilein Tendermint the right of proposing a next blockis being passed in a round-robin fashion [11], Al-gorand uses a mechanism based on verifiable ran-dom functions that allow nodes to privately checkwhether they are part of the current round. Aftergossiping a message to the network, these nodes areimmediately replaced. The mechanism developed inAlgorand, prevents Denial-of-Service (DoS) attackson validators chosen after their identity is revealed.Algorand addresses the scalability problem by ran-domly selecting a committee, which determines asmall subgroup of representatives of all validators.Only the committee is eligible to run a certainstep in the protocol, which reduces the number

of messages passed through the network. Algorandclaims that the protocol is able to handle 125 timesmore transactions than Bitcoin does [20].

III. BAZO DESIGN

The previously existing PoW-based BAZO BC[17] was revised and extended to a PoS-based BC,which is referred as BAZO in this paper below[16]. The proposed BC is explained here withelaborations on Transactions, Accounts, Block, PoSCondition, and validations.

In BAZO, the chain-based protocol is developedfor simplicity reasons in which the PoS protocolworks comparably to the PoW consensus mecha-nism with key differences. It designs a throttledPoW algorithm. Since a validator is limited toexactly 1 h/s (hash per second). BAZO defines asemi-synchronous system, such that every node hasits own local time. If a node attempts to speed uphis hashing power, the system detects the maliciousnode and the suggested blocks are rejected. BAZOchooses validators proportionally to the number ofcoins that each validator owns.

Furthermore, seeds are replaced by RSA scheme[15] to enhance the randomization of selecting thenext validator at every Block Height (BH) (cf.Section III-D). One key advantage of this PoSprotocol is that a validator is always elected unlessall validators are offline at the same time. OtherPoS protocols would need to implement a fall-backmechanism that deals with a deadlock, which oc-curs, if all members of a chosen subset of validatorsare offline.

A. Transactions

Transactions are used to change the state of ac-counts in BAZO. Three transaction types are alreadyexisting in the original PoW-based BAZO, whichinclude the ”account creation”, ”transferring funds”,and ”adjusting system parameters” [17].

1) Stake Transaction (StakeTx): A node in theactive validator set confirms transactions propor-tionally to their stake in the form of blocks oftransactions. This new type of transaction allowsa node to join or leave the validator set. Thistransaction consists of the following parameters:

Fee: The fee is a payment as an incentive forthe validator to include the transaction in the next

6

block. The higher the amount of the fee, the morelikely the transaction will be included in the nextblock. As in the PoW-based protocols, the validatorthat appends the next block will be rewarded withtransaction fees of all transactions within the blockappended. Fee amounts are smaller compared to aPoW-based system, since a validator does not haveto be compensated for electricity costs. However, asmall amount – which needes to be calculated viaconfiguration transactions – still has to be paid forevery transaction in order to prevent to BC frombeing spammed.

Is Staking: This defines a Boolean state, whetherthe node wants to join or leave the set of validators.

Account: The account is defined by the hash ofthe public key of the issuer.

Signature: The signature serves the purpose ofauthentication. The node digitally signs the transac-tion with its private key. A transaction of this typeis accepted by the network, if the issuer fulfills theminimum staking amount that is needed to becomea validator. This minimum amount is a systemparameter (cf. Section III-A2). Staking transactionsare referred to as StakeTx.

key Commitment: Each node has to generate aPublic key Pk, Private Key Sk, (Pk,Sk) pair. For thispurpose the RSA algorithms is chosen with a keysize of 4096 bits [15].

2) System Parameters (ConfigTx): With Con-figTx system parameters can be adjusted without theneed of a hard fork. The configuration transactionof the PoW-based BAZO BC is extended by thefollowing parameters to reach a PoS-based BAZO:

Minimum Staking Amount: This is the mini-mum amount of coins that a potential validator mustpossess. A node cannot join the set of validatorsunless it fulfills this requirement. As long as a nodeis part of the validator set, its balance must neverfall below the minimum.

Minimum Waiting Time: This is the minimumnumber of blocks that a validator must initially waitfor, when joining the validator set. After appendinga block to the BC, a validator must also wait thesame number of blocks before another one can beadded. The reason for waiting a certain number ofblocks is the prevention of a stake grinding attack(cf. Section V-A2).

Accepted Time Difference: An important char-acteristic of a semi-synchronous system is the dif-ferent clock speed in every node participating withinthe network. This parameter defines the acceptabletime difference. A malicious validator that speeds uphis/her clock interval should not be able to appenda block to this BC.

Slashing Window Size: As described in SectionI-A1 validators must be punished, when addingblocks on two competing chains. Otherwise thenetwork will never reach consensus and it offers thepossibility for double spending attacks. The slashingwindow size forces validators to commit to one ofthe competing chains after a fork. If a validator voteson two different chains within a span of a certainBlock Height he/she will be punished.

Slashing Reward: refers to the amount of coinsthat a validator receives for providing a correctslashing proof. This incentivizes validators to check,if other validators have built on top of multiplecompeting chains within the slashing window.

3) Funds Transaction (FundsTx): transfers fundsfrom one account to another. Any transaction froman active validator will be rejected, if the balanceof the node is below the minimum staking amountafter the transaction.

B. Account

The BAZO BC is an account-based model, whichmeans that the union of all accounts make up thestate of the network. Besides the three existingparameters – address, balance, and transaction count– three additional parameters are introduced:

Is Staking: This Boolean parameter describes,whether the account is currently part of the activevalidator set or not.

Staking Block Height (SBH): The system reg-isters the block height at which an account joinedthe set of validators. This parameter is needed forthe slashing condition.

C. Block Structure in Bazo

The following parameters are updated from theexisting protocol or added to the block parameters:

Number of StakeTx: Due to the newly intro-duced StakeTx this parameter corresponds to thenumber of StakeTxs that are included in the block.

7

StakeTx Data: The hashes of all StakeTxs thatare included in this block in sequential order.

Time in Seconds (updated Nonce): The mean-ing of the nonce in the updated protocol bears thenumber of seconds that a validator needs in orderto fulfill the PoS condition (cf. Section III-D).

Height: The height of a block refers to thenumber of previously appended blocks to the BC.This parameter is needed for the PoS condition (cf.Section III-D) as well as the slashing condition (cf.Section III-E).

Commitment Proof: This parameter representsthe output of RSA(SK, SHA3 − 512(H)). SKrepresents the private key that corresponds to thepublic key PK that was set in the initial StakeTxpf the node. PK can be used by other validators toverify the proof. H is the Height at which blockcreated.

SlashedAddress: A validator can submit a slash-ing proof when appending a block. Therefore, avalidator checks if another validator has built ontwo competing chains within the block span of theslashing window size. This parameter is set to 0 bydefault if no proof is included. Otherwise, it holdsthe address of the misbehaving node that must bepunished.

Two Conflicting Block Hashes: These two pa-rameters exhibit the block hashes where the samenode has appended a block on two competing chainswithin the slashing window size.

D. PoS Condition

The PoS condition works similar to the PoW con-dition but with different parameters and a regulatedhash rate for each validator. Each parameter has itsown unique function in order to secure the system.

After a node has joined the set of validatorsand the minimum waiting time has passed, it iseligible to append blocks to the BC. For that aim,it must provide a valid TimeInSeconds (T) for thePoS condition 3. Each of the parameters provide animportant property:

SHA-256([SeedPrevBlocks] · SeedLocal ·BH · T )Coins

≤ Target

(2)An important characteristic of the seed which

is included in every block is the immutability of

the seed. A validator has previously committed tothis seed and cannot change it during commitmenttime. It is called the commitment time when a nodeadds transactions in form of a block to the BC bybroadcasting the proposed block. The seed is usedfor the random election process for the upcomingblock. As highlighted in Section II-1 a node mustnot be able to modify the random election processduring commitment time. By including a list ofthe previous seeds a stake grinding attack becomesunfeasible. In Section ?? stake grinding attacks arerevisited and evaluated.

SHA-256([PPrevBlocks] · PLocal ·BH · T )Coins

≤ Target

(3)List of the Previous Proofs (ProofPrevBlocks):

By having the list of previous proofs at hand, a stakegrinding attack becomes unfeasible [15].

Local Proof (PLocal): With Local Proof, even avalidator with a low amount of coins can append ablock to the BC [15].

Block Height (BH): The height of a block ischaracterized by the number of previously addedblocks in the BC plus one.

Amount of Coins (Coins): By dividing up thenumber of coins that a validator possesses, theelection process becomes proportional to the stake.Without this division every economically actingnode would create new accounts that possess exactlythe minimum staking in order to maximize itsstaking reward.

Difficulty of the PoS Condition (Target:) Sim-ilar to the PoW condition the difficulty in the PoSprotocol can be adjusted with this global variablein order to determine the speed of the BC. Asthe number of validators in-/decreases the difficultyis adjusted accordingly. The Target is recalculatedand adjusted based on the measured average blockinterval [17].

E. Validation

When a new block is received each validatorchecks the following conditions whether the blockis valid or not:

Commitment Proof: Each validator checks theorigin of message by checking the public key of the

8

validator in the Commitment Proof of the new block[15].

Minimum Waiting Time: The minimum waitingtime requirement is needed in order to prevent stakegrinding attacks (cf. Section V-A2). The larger thenumber of blocks the more difficult it becomes foran attacker to perform such an attack. Furthermore,it also sets a validator offline for the number ofblocks that is set as the minimum waiting time afterappending a block. This is because when adding ablock, a new seed is submitted and this also opensthe possibility of a stake grinding attack. Therefore,it is desired to adjust the size of the minimumwaiting time according to the size of the validatorset. PoS Condition: The current state of the systemand the suggested block contain all the neededinformation to check whether the PoS condition isvalid or not.

Slashing Condition: When the suggested blockincludes a proof for a slashing condition, each val-idator checks for the proof’s validity by comparingthe height of the two blocks and whether they arisein competing chains or not. If the proof is valid,the beneficiary address receives an addition rewardwhich is determined by a system parameter. Further,the slashed address loses its position in the validatorset as well as the minimum amount of coins that isrequired to be part of the validator set.

Clock Speed: When a node tries to manipulateits clock speed, the suggested block will be ignoredif the submitted time is too far in the future. Thisthreshold is set with a system parameter.

F. Competing Chains

Due to latency and the nature of the PoS conditionit is possible that BC forks happen and validatorscompete on two or more chains. In such a case theproposed BAZO protocol follows the same principleas in a PoW system which covers the followingpossibilities:

Same Height: A validator takes the first receivedvalid block and rejects all blocks belonging to achain that are of the same height or shorter Com-peting Chains.

Longer Chain: If a block is received that belongsto a longer valid chain, this chain is used as the validchain and a rollback is necessary [17].

IV. SCALABILITY ENHANCEMENTS WITHTRANSACTION AGGREGATION

The idea behind transaction aggregation is toaggregate valid transactions such that multiple trans-actions from one sender or to one receiver arevisible as one transaction in the BC. This shouldenhance the TPS because more transactions can bevalidated in one block. Thus, the block size becomesless of a limiting factor when many transactionswith the same sender or receiver are issued tothe network. Furthermore, transaction aggregationreduces the BC’s overall size because fewer trans-actions are visible in the BC. Especially whenaggregating transactions, which are validated in analready closed block, the overall BC size can shrinksince at a certain point these blocks can be emptiedcompletely. This results in a reduced block size.Forthe aggregation, a new type of transactions, calledAggTx, is introduced in Bazo. Furthermore, all fundstransactions are updated accordingly.

An Example: User A sends 2 BAZO-Coins toB and 5 Bazo-Coins to C. Without transactionaggregation both transactions are listed in a blockas (schematic) (A →B : 2) & (A →C : 5). Withtransaction aggregation only one transaction (A→[B,C] : 7) will be written into the block. Thisillustrates that the overall BC size could be smallerand more transaction can be handled because theyare aggregated. The aggregation is planned to befully hidden from the users.

Aggregated: The variable ’Aggregated’ is aboolean and does indicate if this transaction isaggregated already.Block: In this filed the hash of the block, in whichthis transaction is validated the first time, getsstored. This is used for rollback scenarios. It is oftype [32]byte.

1) AggTx: This type of transaction does ag-gregate and sum up matching funds transactionsand older aggregation transaction. Instead of thesetransactions, an AggTx will be listed inside a block.Amount: The amount is the summed up amount ofall transactions aggregated inside this AggTx. It is oftype uint64. Fee: The fee of this transaction. It is setto 0 because, at the time of writing, the users shouldnot be charged for this type of transaction. It is alsoa uint64. From: It is a slice where the addresses of

9

all senders sending a transaction aggregated in thisblock are stored. It is a slice of type [][32]byte To:This is the counterpart of the From field and filledwith the addresses of the transactions’ receivers. Itis also a slice of type [][32]byte.

AggregatedTxSlice: This slice is of type[][32]byte and does store all hashes of the trans-actions aggregated inside this AggTx.

Aggregated: The variable ’Aggregated’ is aboolean and does indicate if this transaction is ag-gregated. Block: In this filed the hash of the block,in which this transaction is aggregated the first time,gets stored. It is of type [32]byte. MerkleRoot:Root of the Merkle tree to ensure integrity and thecorrect order for the transactions aggregated in thisAggTx. It is a slice of type [32]byte.

These AggTx are added to the blocks simi-lar to other transactions. They are listed in theAggTxData slice.

2) Theoretical Aggregation Process: Fundstransactions and aggregation transactions canbe aggregated in two different ways. All othertypes of transactions are not taken into account.Furthermore, it is not possible to combine analready aggregated transaction aggregated by thesender and one by the receiver. This results ineither the From or To slice to have a length of one.

Transactions can be aggregated by the sender.Then all transactions which are sent by a spe-cific wallet are aggregated into one AggTx. Whenaggregating transactions this way, the From slicehas a length of one, as there is only one senderincluded. On the other hand transactions can alsobe aggregated by the receiver. Then all transactionssent to one specific wallet are aggregated into oneAggTx. Here the To slice is only length one becauseall transactions are sent to one specific receiver.

When a miner combs through all open trans-actions he tries to aggregate as many open fundstransactions as possible according to these two rules.If two or more transactions can be aggregated,their transaction hashes are written to the AggTx’sAggregatedTxSlice and the transactions’ booleanAggregated will be set to true.

In the next step, the miner checks already closedblocks, whether there are transactions (either Fund-sTx or AggTx) which do match the chosen pattern(either aggregated by sender or receiver) and are

not aggregated by now. If such historic transactionsexist, they are also added to the AggTx. But they donot have an influence on the state during the postvalidation of a block anymore.

Fig. 6: Transaction Aggregation Concept

In figure 6 the aggregation process is visualizedschematically. The letters are wallets and the num-bers are the amount of BAZO-coins sent. All opentransactions are listed on the right side. In thisexample, the historic aggregation is omitted due tosimplicity and only one of various possibilities isshown.

An algorithm group these transactions in an opti-mal way, such that the fewest transactions are listedin the block, but the most transactions are validated.Without Transaction Aggregation, all these opentransactions try to be in current block 103. Whenthe block size is assumed to be limited to fivetransactions, with aggregation, there is still place forone more transaction whereas without transactionaggregation not even all nine transactions can bevalidated in the current block. Because BAZO onlywrites the hashes of transactions inside its blocks,this is possible. Consequently, with aggregation onlythe hashes of the two aggregated transactions andthe two normal funds transactions, which cannot beaggregated in this block, are stored in the block’sbody.

Furthermore, it is also visible that it actually doesnot matter, how many transactions are aggregated inone AggTx. If A would have sent more transactions,still only one transaction is written into the block,but this transaction would aggregate more transac-

10

tions. This is especially nice for a BC which is usedin a case, where often multiple transactions are sentfrom one or to one peer. With small modifications,an imaginable example use case would be a BCwhich stores values sent from Internet-Of-Thingsdevices always to the same receiver.

The miners do not earn a specific fee for aggregat-ing. But they still receive all the fees which belongto the FundsTx. This results in miners that wantto validate as many FundsTx as possible and thusearning as much as feasible. The more transactionsthey can aggregate the more transactions are in ablock and they will get a higher reward. Since theblock’s size does not grow with every transaction,they can add more transaction into one block.

A. Double Linked Blockchain

The concept of a double linked BC is a result ofthe idea to remove all transactions from a block onceall of them are aggregated in a later validated block.This is kind of a contradiction against the theory of aBC where all validated blocks are immutable. Theyare unchangeable because it would take too mucheffort to recalculate the complete chain since thisadapted block, and additionally persuade over 50%of all miners to accept the newly created blocks.

In BAZO the block hash is calculated from vari-ous block related input fields. One of these variablesis the Merkle root, which ensures transaction verifi-cation. It ascertains that transactions neither can beadded to or removed from a block nor the orderingcan be changed once a block hash is created [?].Thus, the removing of transactions is only possiblewhen a new additional block hash is calculatedfor every block because the old hash is becominginvalid, as soon as some transactions are removed.This new hash, called HashWithoutTransactions, isused always when the normal hash is becominginvalid. The normal hash becomes invalid becausethe Merkle root changes.

The goal and also the specification of the doublelinking is, that at least one link to the previousblock is valid. Additionally to the common variablesincluded in a block, the following fields are addedin respect of the double linking of the BC:

Aggregated: It indicates if a block is aggregatedand therefore does not contain any transactionsanymore. It is of type boolean.

HashWithoutTransactions: This hash is usedonce all transactions from a specific block areaggregated. It can be calculated when not taking thetransactions into account and as a consequence as-suming an empty block. Thus, it is only possible toempty a block, once all transactions are aggregatedand removed. It is of type [32]byte.

PrevHashWithoutTransactions: This field linksthe current block to the previous one once alltransactions in the previous block are aggregated.

ConflictingBlockHashWithoutTx1: HashWith-outTransactions of the first conflicting block.

ConflictingBlockHashWithoutTx2: HashWith-outTransactions of the second conflicting block.

1) Theoretical Double Linking Process: In figure7 the concept of a double linked BC is illustrated.Every block, expect the genesis block, can eitherbe in the storage Blocks With Tx or Blocks WithoutTx. This two versions of a block are indicated withblock-namew/ (including transactions) and block-namew/o (without transactions, meaning this blocknever contained transactions or all of them areaggregated by now). The increasing block numberindicates which block is the ancestor, and the arrowspoint to them.

Fig. 7: Double Linked Blockchain Concept inBAZO

Every block, expect the genesis block, can con-tain transactions. These transactions are sent fromclients to the network, what is indicated on theleft side, as incoming Tx. Transactions are read as

11

FundsTxsenderAddress=¿receiverAddress or when aggregatedas AggTxsenderAddress=¿{receiverAddress}. This happens as ahistorical aggregation in block 103 or while mininga new block denoted as the incoming AggTx alsoincluded in block 104.

As FundsTxB=¿D reaches the network, the minerssearch in already validated blocks for other FundsTxor AggTx with either the same sender or receiver.In this example FundsTxB=¿C in block 102 can beaggregated, which leads to the case where in block102 all transactions are aggregated.

Once all transactions are aggregated and the blockis out of the exclusion zone, it can be transferredto the storage without transactions. The exclusionzone is defined as the current blockheight minusNO EMPTYING LENGTH what ensures that theuser-defined NO EMPTYING LENGTH last blocksare not moved even though all their transac-tions are aggregated. Meaning only blocks witha blockheight smaller than currentBlockheight -NO EMPTYING LENGTH are moved. Block 105is not emptied yet despite the fact it does not containany transactions. Once block 105 will be out of theexclusion zone, it will be transferred to the BlocksWithout Tx. When a NO EMPTYING LENGTH of2 is assumed, block 105 can be moved once a blockwith height 108 is appended to the chain.

When emptying block 102, it will be moved to theBlocks Without Tx, and the hash HashWithoutTrans-actions gets valid. Therefore block 103 is not linkedto block 102 via the Previous Hash anymore butover the PrevHashWithoutTransactions now. It hasto be ensured that one link between two consecutiveblocks is always valid. In figure 7 this is indicatedwith the black arrows between blocks. This resultsin a valid chain indicated with grayish backgroundcolor whereas all other blocks are only there forvisual purposes and therefore slightly faded.

V. EVALUATION AND SIMULATION RESULTS

Evaluations of BAZO is performed by setting upa test-bed including 9 miners hosted on AmazonWeb Services (AWS) located in Oregon, Sao Paulo,Ohio, London, Paris, Mumbai, Singapore, Tokyoand Sydney. In this network more than 2200 trans-actions monitored between the clients and miners.The maximal block size is set to 500’000 Bytes. Theblock interval, which defines the time span between

two blocks added to the chain is set to 180 s andthe difficulty interval is set to 20 blocks. This meansthat the difficulty is checked all 20 blocks and ifblocks are mined too fast or too slow the targetgets adapted accordingly to match the defined 180seconds in future. Related information can be seenin the Table I.

In the following part evaluations regarding thethree major metrics of (a) security challenges, (b)environmental side effects, and (c) risks of central-ization are elaborated.

A. Attack Countermeasures

The attack scenarios and their countermeasuresin order to mitigate them elaborates explicitly onDenial-of-Service (DoS) and stake grinding attacks.

1) Countermeasure on DoS and Stake GrindingAttacks: The election process of the BAZO BC isdone in the same private manner as done withinPoW consensus algorithms. By increasing the ran-domness in the selection of next validator, attackerswont be able to predict the next validator. This willcause in protection of the system against DoS andGrinding attacks.

2) Without a Minimum Waiting Time: The mini-mum waiting time here explained in two settings.

Setting 1: The vicious node controls two ad-dresses A and B. A is part of the validating set and Bpossesses the required minimum amount of coins tojoin the validator set, but it is not part of it yet. Assoon as A is elected to add a block, B broadcasts aStakeTx with a manipulated seed such that the PoScondition for the next block is immediately fulfilled(T = 0). This can only be possible, if an attackerknows all parameters for the PoS condition for thenext block. A includes this transaction in its blockand B is immediately elected for the next block. Thesame setting could be repeated and a single partycould take control over the entire BC.

Setting 2: Without a minimum waiting time, amalicious node can easily reelect itself. This attackreads as follows. When the attacker is elected foradding a block, it finds a manipulated seed bybrute forcing such that it fulfills the PoS conditionimmediately for the next block (T = 0). Therefore,the system parameter for the minimum waiting timemust be selected accordingly, that such an attackbecomes unfeasible in the current distribution of

12

TABLE I: BAZO Simulation Results

MinerLocation

#BlocksMined

FirstBlock

LastBlock

Timespan ElapsedTime (s)

BlocksPer Min

#BlocksAddedToChain

Total#TXsent

Total #TXValidated

AverageNumberof TPB

MaxTPB

London 51 11:44:05 18:58:04 07:13:59 26039.88 0.12 43 21536 21536 500.83 4403

Ohio 41 11:38:45 18:56:00 07:17:15 26235.14 0.1 43 9952 9952 231.44 2272

Tokyo 32 11:23:02 19:09:54 07:46:52 28012.53 0.07 43 17589 17589 409.04 5204

Sydney 77 11:14:54 18:53:50 07:38:56 27536.54 0.17 32 13159 13159 411.21 2272

Mumbai 69 11:17:11 19:06:23 07:49:12 28152.95 0.15 43 16908 16908 393.20 2272

SaoPaulo

51 11:33:17 19:16:45 07:43:28 27808.23 0.12 43 16942 16942 394 2174

Singapore 58 11:23:13 19:21:46 07:58:33 28713.40 0.13 43 10104 10104 234.97 3090

Oregon 42 11:18:50 19:18:46 07:59:55 28795.47 0.09 32 13727 13727 428.96 3836

Paris 54 11:29:18 19:28:02 07:58:44 28724.73 0.12 40 15927 15927 398.17 3302

Overall 475 11:14:54 19:28:02 08:13:08 29588.98 0.97 362 135844 171230.03 ——– 5204

AverageperMiner

52.78 11:26:57 19:09:57 07:42:59 27779.87 0.12 40.02 15093.78 19025.55 473.02 578.77

stake. One also has to consider that a validator isblocked for the number of blocks that defines theminimum waiting time after appending successfullya block.

In case where the minimum waiting time is setto 10 blocks, a malicious user would have to besuccessfully elected ten times in a row before he/shecan execute such an attack. In an established system,where the staking amount is distributed amongmany validators, such an attack becomes infeasible.

B. Environmental Side Effects

The consensus algorithm implemented for BAZOthrottles the hashing power of each validator to ex-actly 1H/s. Compared to Bitcoin mining hardware,such as the Antminer S9, which delivers up to14TH/s [8], the expended resources are negligibleand can be carried out by low performance desktopcomputers.

C. Risk of Centralization

Mining and Validating Pools: Since the amountof resources used in the BAZO is low (cf. SectionIII), formation of validating and mining pools is lessapplicable as there is no need for a constant revenuestream for a validator.

Cloud Mining/Validating: In BAZO a validatordoes not gain a competitive advantage over other

validators by buying specialized hardware (cf. Sec-tion III). Thus, there is no need for centralized cloudservice providers to offer hardware rentals, whichreduce the risk of centralization.

The Rich Gets Richer The rich get richer prob-lem corresponds to a node owning a large fractionof tokens and which will generate more revenuethan others, eventually possessing more than 51%.Thus, such a form of centralization is possible inPoW and PoS consensus mechanism. Since theblock reward and transaction costs in PoS can belowered drastically compared to PoW due to thelack of burned resources, it would take a node muchlonger to possess 51% of all tokens. It requiresmore effort in PoW, since constantly new mininghardware and infrastructure had to be added. InPoS if the reward of validators paid proportionally,since only a very small portion of the total amountof coins is generated with each new block it takessignificantly longer than PoW.

While this may happen, the exact same argumentcan also be raised in a PoW system. Every time aminer is able to produce a new block, he/she caninvest the earned block reward in new mining hard-ware. The node that can initially afford the greatestmining infrastructure would also be able to buy newhardware more frequently and eventually becomesthe richest node in the network. Such a node profits

13

from the economies of scale and can benefit fromhigher margins on each block compared to smallerminers. This offers the possibility of buying newhardware even more regularly.

As soon as people start realizing that there isa potential risk of centralization in a distributedsystem the interest in such a system decreases. Asa result the value of the tokens declines with it. InPoS entire stake is at risk since your investment isin the token itself, whereas in PoW your investmentis in form of mining hardware.

If an attacker successfully performs a 51% at-tack, a miner can move its mining gear on toanother BC. In PoS it is more difficult to withdrawthe investment since the attacker needs to sell allhis/her tokens. The market price for the associatedcryptocurrency would drop immediately due to theexcessive supply and the attacker is probably notable to sell above the price that he/she acquired thetokens. As a result, in PoS systems there is a higherrisk of losing a large portion of the investmentwhen attempting a 51% attack and might be moreexpensive than in PoW.

In this section, the results from the performanceanalysis are discussed. Therefore, the test cases de-fined in chapter ?? are used. There is a section aboutthe block size, about the interval between blocksand about the blockchain’s overall size. The chaptercloses with the benefits and obstacles of transactionaggregation and a prospect about possible futurework.

VI. DIFFERENT BLOCK SIZES

Here, the evaluation and comparison betweendifferent block sizes and its influence on the TPS,with an initially defined amount of transactions sentto the network, is measured and listed. However, itis possible that not the same amount of transactionsare sent to the network in each test run becauseof either the miner or the client crashes. This ismainly caused by an unrecoverable SIGBUS error.For certain test runs, the number of transactions sentis lowered on purpose, as described in chapter ??.

Table II does show the transactions per secondrates for test cases with transaction aggregation en-abled whereas tableIII shows the test cases withouttransaction aggregation. In both tables, the blocksize has unit byte, and the values belonging to

transactions have unit transaction or transactionsper second.

The actual block size (ABS and unit byte) isthe available space in a block where transactionscan be filled in. At the time of writing, it isDefinedBlockSize − 658byte. The 658 bytes areused for block related values and therefore thisspace cannot be filled with transactions.

At a first look, it occurs strange that there arealso TPSmin and TPSmax beside the normal TPS. Thisis due to the fact, that some miners need longerto fetch all transactions when they do not receiveall transactions during broadcasts, as described insection ??. Also nearly always the virtual machineshosted on GCP had a lower TPS than the oneson AWS, what may be an indicator that they areslightly underpowered in regards of the randomaccess memory. The TPSmax is an evidence of whatspeeds can be possible with transaction aggregationas it is implemented in this thesis. However, inchapter VII, it is visible that also with transactionaggregation, the TPSmin and TPSmax can be closeto each other. Therefore it is strongly assumed, thatthis difference is caused by connection issues, whichresults in requesting more transactions.

As visible in table II, the block size does not takea big influence on the reached TPS value. This doeshave multiple reasons:

Transaction Aggregation: Since transactions areaggregated, not every transaction needs space ina block, and thus, more transactions fit into oneblock. Actually it does not matter, if there aretwo transactions from A to B or if there are onehundred transactions from A to B. With transactionaggregation, only one transacting will be writteninto the block. Consequently, it is good to group asmany transactions as possible and bad, not to groupany transaction, because it needs too much space incomparison.

Unlimited AggTx Size: If a transaction does notfit in one block, it is likely that it is validated inthe next block because there is no limit in howmany transactions can be written into one AggTxand because of the splitAndSort-algorithm’s design(explained in section ??, algorithm ??). This algo-rithm takes the senders or receivers which have mostawaiting transactions to be validated. Thus, the moretransactions from one sender or to one receiver are

14

TABLE II: Table of different block sizes influencing the TPS with transaction aggregation enabled.

Block size TransactionsDefined ABS #sent #validated TPSsent TPS TPSmin TPSmax

TPSTPScalc.

1’000 342 179’328 178’196 33.1 28.0 14.6 32.7 39.25’000 4’342 181’933 181’933 33.3 28.5 20.9 33.2 3.120’000 19’324 181’613 181’613 33.0 28.0 16.7 32.9 0.7

TABLE III: Table of different block sizes influencing the TPS with transaction aggregation disabled.

Block size TransactionsDefined ABS #sent #validated TPSsent TPS TPSmin TPSmax

TPSTPScalc.

1’000 342 19’000 19’000 36.3 0.6 0.6 0.6 0.75’000 4’342 74’960 74’834 34.7 7.0 7.0 7.0 0.820’000 19’342 181’078 181’078 33.5 27.3 27.2 27.4 0.7

in the mempool, the more likely it is that they getvalidated. Because the transactions from / to onewallet, which cannot be validated in a block, arestill in the mempool, it is likely that there are moretransactions matching the selection criteria for thenext block. Since the size of an AggTx is unlimited,they are able to aggregate as many transactions aspossible.

Test Case: In the test cases, there are maximal20 users in the network. Thus it is likely, that thesame sender or receiver is found quickly. This doeshelp to keep the TPS at a high level. It is obviousthat transaction aggregation works better the moresimilar sender or receivers are in the transactions.But since BAZO is planned to become an IoTblockchain, where multiple IoT devices send theirdata to one receiver, this limited number of walletsis not a problem.

Transaction Sending: Transactions are sent ap-proximately every 12 second. If transactions wouldonly be sent after the previous transaction is vali-dated in the network, aggregating by sender wouldnot work. The current acknowledgment a minersends to a client is only confirming that a certaintransaction is sent to the network. A client does notknow if and when the sent transaction is validated.Thus, aggregating by sender is possible.

The TPSTPScalc.

does indicate by which factor the ag-gregation increases the maximum possible TPScalc.

value. Thus with a block size of 1’000 byte, theversion with transaction aggregation can theoret-ically handle roughly 39 times more transactionsthan without aggregation. It is clear, that with asmaller TPScalc. and a constant TPS, this factor

increases. The TPSTPScalc.

for a block size of 20’000byte is below one, because theoretically over 600transactions fit into a 20’000 byte block what resultsin a TPScalc. of about 40 transactions. This TPScalc.

is higher then the TPSsent and therefore, the ratiocannot be bigger than one. Summarizing this, it isnot possible to generally say, that with transactionaggregation it is exactly 39.2 respectively, 3.1 timesfaster, because this numbers are highly influencedby the actual TPS which can not be higher than theTPSsent. Thus, sending more transactions probablyincreases the TPS, and therefore also the TPS

TPScalc.ratio, even more. In table III, the fraction TPS

TPScalc.can be understood as degree of utilization in termsof defined and actual block size.

Fig. 8: Different block sizes and its influence on theTPS with and without aggregation

15

Figure 8 does visualize the output of tables II andIII. The scalability improvement is clearly visible.One can say, that with transaction aggregation, theblock size is not a limiting factor anymore if thereare either same senders or same receivers in thetransactions. This is visible in figure 8, because theblue bars are nearly constant, whereas the orangeones, standing for test runs without aggregation, areincreasing with bigger block sizes. The grey bars dovisualize the TPScalc.. Furthermore it is surprising,that the orange bar is not higher in the test run witha block size of 20’000 byte. The block’s size isnot limiting the TPS anymore, since the TPScalc. ishigher as the TPSsent. This may indicate, that theconnection issues described in section ?? and ?? arelimiting the network throughput. Unfortunately, thisassumption can neither be confirmed nor rejectedbecause there is no fix for this problem yet. TheTPSsent is indicated by the green line.

The shrinking of the TPSsent in figure 8 is notrelated to the block size, as it may could beassumed. Sending the transactions, even with afixed interval, is still not always equally fast. It isrelated to the timespan in which a client receivesan acknowledgment from a miner after sending thetransaction. This timespan can slightly differ, andthus, it can have a bigger influence when sending alot of transactions.

In the test runs with a block size of 1’000 byte,the version with transaction aggregation can han-dle that much more transactions because about 10transactions fit into one block. These 10 transactionscan be aggregation transactions aggregating waymore transactions and therefore increasing the TPS.Here point two from the listing above does havean influence because 19 different wallets are in thenetwork. When aggregating these transactions per-fectly, it would result in 19 AggTx transactions. Thiswould overflow the block size by nine transactions.If transactions from one sender cannot be validatedin block n, there will be all these transactions plusthe newly received ones for block n + 1. Thus,during the preparation of block n + 1, this specificsender will have more transactions than a senderwhose transactions get validated in block n andtherefore all its transactions get validated then.

The global distance of the network is not influ-encing the performance a lot since the ping-latency

between the used virtual machines was usuallybelow half a second during the test runs.

The block size is not limiting the BAZO versionwith transaction aggregation up to the point, whereonly distinct senders and receivers are sending andreceiving the transactions. Therefore, in regards tothe block size, transaction aggregation does increasethe TPS especially for small blocks and thus it looksvery promising.

VII. DIFFERENT BLOCK INTERVALS

Here the comparison and evaluation betweendifferent block intervals, with a given number oftransactions sent to the network, is measured andlisted.

Table IV does show the TPS rates for test caseswith transaction aggregation enabled whereas tableV shows the test cases without transaction aggre-gation. In both tables, the block interval has unitseconds, and the values belonging to transactionshave unit transactions or transactions per second.In table IV the fraction TPS

TPScalc.can be seen as

improvement factor in contrast to the theoreticalmaximum and in table V as degree of utilization.

The ABI (actual block interval) is an indicatorif the blockchain does validate blocks in the userdefined interval. It has unit seconds and is theaverage timespan between two blocks. Since thevalidation speed is set with the help of the target,it is not exactly the set interval [?]. This target isadapted every n blocks, whereas n is user defined.

The test runs with different block intervals looksimilar to the test runs with various block sizes. TheTPS can be increased when transaction aggregationis used. Especially because the block interval andthe TPS without aggregation are behaving inverselyproportional, these test runs show the advantagesnicely. The relationship between the TPS and theblock interval is inversely proportional because,with a higher block interval, fewer blocks can bevalidated, and thus, less transaction as well.The block size, on the other side, is related pro-portional to the TPS, because bigger blocks canhandle more transactions. This results in a higherTPS value.Consequently, the version without aggregation cantheoretically handle the most transactions with a tinyblock interval and huge blocks.

16

TABLE IV: Table of different block intervals influencing the TPS with transaction aggregation enabled.

Block interval TransactionsDefined ABI #sent #validated TPSsent TPS TPSmin TPSmax

TPSTPScalc.

15 18.8 181’933 181’933 33.3 28.5 20.9 33.2 3.160 66.8 190’000 190’000 34.8 34.4 33.9 34.7 15.3120 118.4 181’278 181’278 33.8 32.9 30.2 33.4 28.5

TABLE V: Table of different block intervals influencing the TPS with transaction aggregation disabled.

Block interval TransactionsDefined ABI #sent #validated TPSsent TPS TPSmin TPSmax

TPSTPScalc.

15 14.3 74’960 74’834 34.7 7.0 7.0 7.0 0.860 63.5 78’375 78’375 36.3 2.0 2.0 2.0 0.9120 111.4 18’000 18’000 34.4 1.1 1.1 1.1 1

Similar to the different block sizes, the blockinterval is not a TPS limiting factor anymore. Fur-thermore, transaction aggregation also allows val-idating more transactions per second, as alreadystated before.

During one test run, with a block interval of 60seconds, the TPS is close to the TPSsent. In thistest run, due to certain unknown circumstances, theTypeID issue (section ??) was not influencing somuch as during other test runs.

Fig. 9: Different block intervals and its influence onthe TPS with and without aggregation

In figure 9 the differences of the TPSsent, whichis indicated with the green line, were relatively bigand thus it has different heights. The differences areagain caused by small differences between sending atransaction and receiving the acknowledgment froma miner.

The difference between the TPS with aggregation(blue bars in cart 9) and without (orange bars) iseven bigger here, since the block interval and theTPS are inversely proportional.

It is not appropriate, to say, that with a higherblock interval, the TPS can be increased for BAZOwith aggregation enabled. Theoretically, the dif-ferent block intervals should not have an effecton the TPS up to a certain number of differentsenders and or receivers. However, the differencescan be founded on the TypeID issue again. This,because with the two higher block intervals, four toeight times fewer blocks have to be sent throughthe network compared to the 15 seconds interval.Therefore, the miners probably disconnect less oftenand they have more time to fetch transactions orblocks, which they never received.

Similar to the test with different sizes of blocks,the global distribution of miners and clients did nothave a huge influence. The latency for a ping-testwas usually around half a second.

Summarizing these outcomes results in the sameperception as in section VI. Transaction aggrega-tion does definitely increase the transactions pos-sible to handle per second. Especially for a largeblock interval, similar to small defined block sizes,summarizing transactions increases the throughputenormously. Since the relation between the blockinterval and the TPS is inversely proportional, thedifference in regards to the TPS with and withoutaggregation is even bigger, as with different blocksizes.

17

VIII. BLOCKCHAIN’S OVERALL SIZE

In this section, the blockchain’s overall size isanalyzed and the findings, based on the test scenariodefined in section ??, are discussed.

As it is visible in graph 10, the blockchain sizecan be reduced with aggregation and even morewith aggregation and emptying of blocks, once alltransactions are aggregated. The difference betweenonly aggregating and aggregating with emptyingis not extraordinary big, because, in this test caseonly three different transactions are written into ablock with aggregation. When emptying a block, theblock’s size gets reduced only around three timesthe size of a transaction hash. The more differenttransactions are listed in a block, the bigger thisdifference will be.

Fig. 10: Differences Regarding The size of TheBlockchain With Aggregation, With Aggregationand Emptying of Blocks and Without Aggregation.

When a BAZO version with transaction aggre-gation (red or black line in figure 10) is comparedto the version without (green line), a huge differ-ence is visible. The difference is this big, becausewith transactions aggregation enabled, around threetransactions are validated in each block, whereaswithout aggregation, roughly 135 transactions getaggregated in each block. These 135 transactionsare also the maximum capacity of a block with thedefined size of 5’000 byte. The two major kinks arecaused by the start and end of sending transactions,whereas the smaller ones are caused by rollbacks.

This graph shows the possibility of having a smalleroverall blockchain size with transaction aggregationand emptying of blocks.

However, since self-contained proofs are not im-plemented in this aggregation technique, a newjoining miner still has to fetch all transactions,no matter if BAZO is aggregating or not. Andbecause aggregating transactions brings an extratransaction each time some transactions get aggre-gated, a new joining miner has to fetch even moretransactions actually. This will change, once self-contained proofs are implemented. Then only thetransactions since, e.g., the last epoch block needsto be fetched from the network. This reduces theamount of data which needs to be fetched.

IX. BENEFITS OF TRANSACTION AGGREGATION

Transaction aggregation does definitely allowmore transactions in one block. Thus the overallthroughput increases and at the same time the blocksize and the overall chain size can be kept small.Furthermore, the block interval can be enlarged,which reduces network traffic. However, transactionaggregation does help the most, if there are similarsenders or receivers of transactions. It performsbetter, the more transactions with the same senderor receiver are sent. As BAZO is becoming an IoTblockchain, where many IoT nodes send their trans-actions to one receiver, this aggregation approachhelps in scaling the blockchain.

As stated above, the implementation presented inthis thesis does not help if there is no overlappingin terms of sender or receiver. Therefore, anotheraggregation technique should be used. A differentpossibility would be: Aggregate transactions (A →B: 5) and (B →A : 20) as one transaction (B →A : 15).Here the only the final amount and the direction ofthe transaction gets written into the blockchain. Thisidea is kind of similar to state-channels proposed insection ??.

Although transaction aggregation already workswell here, its full power may only be visible oncesharding and self-contained profs are implementedand combined with this technique.

18

X. OBSTACLES OF TRANSACTIONAGGREGATION

The intention behind double linking theblockchain is emptying all blocks once they aresecure enough. A block is secure enough whenit is accepted by the majority of miners, andthus, will not be included in rollbacks anymore.The emptying helps to save storage, as visible insection VIII. However, the emptying of validatedblocks is kind of a contradiction against the coreconcept of a blockchain, where secure blocks areimmutable and cannot be changed again. Thus,some impediments occur, especially when a newminer joins the network and wants to start mining.

A. Join As A New Miner & Order Of TransactionsWhen aggregating transactions in a historic man-

ner, as it is described in section IV-2, various prob-lems and difficulties can occur. They are describedwith the help of figure 11.

In figure 11 three FundsTx are incoming to theblockchain and get validated in in blocks 1011,1012 and 1013. As it is visible, the third transaction(FundsTxA=¿C : 5) can be aggregated with the firsttransaction (FundsTxA=¿B : 10), because of the similarsender. This results in the AggTxA=¿{B, C} : 15 in block1013, and the removing of FundsTxA=¿B : 10 in block1011.The table on the right side shows the balances forthe three wallets A, B and C with and withoutaggregation, before, between and after the threeblocks are validated.

As it is now visible in the table, the balancesfor A and B are not the same when aggregatingthe transaction as when not aggregating them. Thiscan lead to problems, especially when restarting orjoining the network after transactions are alreadysent. Since BAZO fetches all blocks from the lastvalidated one to the genesis block first and afterwardvalidates them in the correct order, moving andaggregating transactions is problematic.

As example, when the transactionsFundsTxA=¿B : 10 and FundsTxA=¿C : 5 get aggregatedto AggTxA=¿{B, C} : 15 and thus transactionFundsTxA=¿B : 10 moves from block 1011 to1013, B does not have enough funds for transactionFundsTxB=¿C : 4 at the point of validating block1012. This is visible in the middle two sub-tables

Fig. 11: Transaction aggregation and the balance.

where the balance of B is not the same with andwithout aggregation. When a new miner is joiningthe network, which uses transaction aggregation,and the FundsTxA=¿B : 10 is not in Block 1011 but in1013, this new joining miner is not able to validateblock 1012, because B does not have enough funds.

One Way of eluding this is a credit-like behavioron startup. This concept allows a wallet to have anegative balance during the startup process. At theend, similar to the fourth small table in figure 11,the balances with aggregation enabled are the sameas when validating each transaction without aggre-gation. As long as all transactions are validated, theorder of validation does not play a substantial role.At a participation of a miner, this new miner onlyvalidates transactions which are already validatedfrom other miners in the network. If the bootstrapminer tries to send invalid transactions to the newminer, the currently joining miner will find them,either by invalid block hashes, or when other minersare refusing its mined blocks later. Consequently,with this credit like behavior during the participa-tion, it is possible to validate block 1012 even withaggregation and join the network.

Joining as a new miner, when blocks are alreadyemptied, is problematic since the nonce of a blockis calculated with the help of the wallets’ balances.Here, similar problems as in the previous subsectioncan occur, and blocks are not validated because thenonce is incorrect at this point. This should also be

19

possible to prevent, when not checking the nonce onstartup. It is also possible to argue, that these blocksare validated in the network already and thereforesecure.

XI. CONCLUSIONS

Blockchains have been used to create a decen-tralized ecosystem for peer to peer transactionsbetween non-trusting peers. Trust in BC is providedwith consensus mechanisms that mainly give anequal sense and view of the whole system to allof it’s users. To tackle the problems experiencedwith PoW-based consensus mechanisms, this workproposed the design and implementation of a PoSblockchain called BAZO. BAZO defines a semi-synchronous system, such that every node has itsown local time. If a node attempts to speed uphis hashing power, the system detects the maliciousnode and the suggested blocks are being rejected.BAZO determines the waiting time for validatorsto control the fair distribution of validator selectionin the system. Without a minimum waiting time, amalicious node can easily reelect itself. In BAZOeach validator owns a local timer and the wholesystem protects validators from diverging. Forks arecontrolled in this PoS based BC and scalabilityissues of PoW based BCs are addressed usingtransaction aggregation. To increase the random-ness, local seeds are replaced by RSA signaturesat every Block Height in order to determine thenext eligible validator. Another key advantage ofthis PoS protocol is that a validator is always electedunless all validators are offline at the same time. Ithas been proved that along with high transactionrate, using BAZO is an environmentally friendlyPoS-based BC, and proposes a higher degree ofsecurity than other implementations of PoW or PoSbased BC such as in PPCoin and Tendermint. BAZOimplements a chain-based PoS protocol to leveragethe simplicity of this type of protocols. For futurework, it is planned to evaluate and enhance thescalability of BAZO by employing proper methodsto handle high rates of data streams, while assuringthe fairness and randomness of the PoS consensusmechanism along with security aspects.

REFERENCES

[1] Bitcoin Energy Consumption Index. https://digiconomist.net/bitcoin-energy-consumption, [Last visit Dec 15, 2018].

[2] Bitcoin, Proof of Work. https://en.bitcoin.it/wiki/Proof ofwork, [Last visit June 6, 2018].

[3] Thomas Bocek Burkhard Stiller:. Smart Contracts -Blockchains in the Wings, pp 169–184. Springer, Tiergartenstr.17, 69121 Heidelberg, Germany, Jan 2017.

[4] Vitalik Buterin. Proof of Stake FAQs. https://github.com/ethereum/wiki/wiki/Proof-of-Stake-FAQs, [Last visit Dec 15,2018].

[5] Daniel Cawrey. Are 51% Attacks a Real Threat to Bitcoin?https://www.coindesk.com/51-attacks-real-threat-bitcoin, [Lastvisit Dec 15, 2018].

[6] Arthur Gervais, Ghassan O Karame, Karl Wust, VasileiosGlykantzis, Hubert Ritzdorf, and Srdjan Capkun. On TheSecurity and Performance of Proof of Work Blockchains. Pro-ceedings of the 2016 ACM SIGSAC Conference on Computerand Communications Security, pp 3–16. ACM, 2016.

[7] A.Mizrahi I.Bentov, A.Gabizon. Cryp-tocurrencies Without Proof of Work.https://assets.ctfassets.net/sdlntm3tthp6/resource-asset-r351/5843a7c05e64302636f9139dd6438943/df8fc572-b128-44fc-8b16-0d06b87d5109.pdf, [Last visit Dec 15, 2018].

[8] J.Tuwiner. Peer-to-Peer Crypto-Currency with Proof-of-Stake. https://www.buybitcoinworldwide.com/mining/hardware/antminer-s9/, [Last visit Dec 15, 2018].

[9] I.Eyal A.Gencer A.Juels A.Kosba A.Miller P.Saxena E.ShiS.Gun E.Sirer D.Song and R.Wattenhofer k.Croman, C.Decker.On Scaling Decentralized Blockchains. In: Jeremy Clark,Sarah Meiklejohn, Peter Y.A. Ryan, Dan Wallach, MichaelBrenner, and Kurt Rohloff (Editors), Financial Cryptographyand Data Security, pp 106–125. Springer Berlin Heidelberg,2016.

[10] Daniel Kraft:. Difficulty Control for Blockchain-based Con-sensus Systems, Mar 2016.

[11] Jae Kwon. Vitalik Buterin: Proof of Stake FAQ. https://tendermint.com/static/docs/tendermint.pdf, [Last visit Dec 15,2018].

[12] A. Narayanan, J. Bonneau, E. Felten, A. Miller, andS. Goldfeder. Bitcoin and Cryptocurrency Technologies: AComprehensive Introduction. Princeton University Press, 2016.

[13] Sina Rafati Niya and Burkhard Stiller. Bazo: Design andevaluation of a proof-of-stake (pos) based blockchain. Technicalreport, Zurich, Switzerland, May 2019.

[14] Nxt:. What is Nxt? https://nxtplatform.org/what-is-nxt/, Feb2017.

[15] R.Blum:. Cryptographic Sortition for Proof of Stake inBazo. http://ifsoftware.ch/SemProgAnTr/files/CryptographicSortition for PoS in Bazo Draft.pdf, April 2018.

[16] S.Bachmann. Proof of Stake for Bazo. https://files.ifi.uzh.ch/CSG/staff/bocek/extern/theses/BA-Simon-Bachmann.pdf, Jan2018.

[17] Livio Sgier. Bazo - A Cryptocurrency from Scratch.https://files.ifi.uzh.ch/CSG/staff/bocek/extern/theses/BA-Livio-Sgier.pdf, Aug 2017.

[18] S.Nadal S.King. Review Of Cryptonote White Paper. https://peercoin.net/assets/paper/peercoin-paper.pdf, [Last visit Dec15, 2018].

[19] Jordan Tuwiner. Bitcoin Cloud Mining. https://www.buybitcoinworldwide.com/mining/cloud-mining/,[Last visit Dec 15, 2018].

[20] S.Micali G.Vlachos N.Zeldovich Y.Gilad, R.Hemo. Algorand:Scaling Byzantine Agreements for Cryptocurrencies. https://people.csail.mit.edu/nickolai/papers/gilad-algorand-eprint.pdf,[Last visit Dec 15, 2018].

20