A Multi-Layered Programmable BlockchainApproach to Digital Currency for High-Volume

Transactions in E-Commerce Systems

Ciprian Pungila1, PhD. and Viorel Negru1, PhD.

Faculty of Mathematics and InformaticsComputer Science DepartmentWest University of Timisoara

V. Parvan 4, Timisoara, Romania{ciprian.pungila,viorel.negru}e-uvt.ro

Abstract. We are proposing a multi-layered, scalable, secure model ofa programmable blockchain approach to digital currency, aimed towardshigh-volume e-commerce systems, and discuss the intricacies of our ap-proach through detailed functional and algorithmic analysis. Addition-ally, we analyze the primary bottlenecks of the most widespread digitalcurrencies today and identify the advantages of our approach as com-pared to the them, outlining the ability to use our model in e-commercesystems with a high number of transactions, where reliability and scala-bility are key factors to driving successful businesses in digital environ-ments.

Keywords: blockchain technology, digital currency, cryptography, e-commerce, high-volume transactions, security, high-performance com-puting

1 Introduction

Ever since the introduction of digital currency [1] and the concept of decen-tralized functionality, the world has seen a continuously growing interest in itsdevelopment. Various blockchain-based technologies [2] have emerged, which al-lowed people to re-consider how we handle digital and real-world businesses, howwe let such technology impact our lives, as well as how we let it become a partof our daily routine. This view of the digital future has found some exciting newopportunities for such technologies, including helping with some of the most in-triguing tasks today, such as authenticating legal contracts or transferring assets,both in digital and tangible forms.

Of course, none of this would have been possible, had computer cryptography[3] not evolved so rapidly in the past decades. Specifically, hash-based approaches[4] for validating authenticity have been a long topic of discussion in researchfor over a century now, with the epiphany of that lying in the widespread useof public key cryptography nowadays [5], from SSL in the Web semantics, todigital e-wallets and crypto-currencies.

2

Bitcoin [6] paved the road to proving that blockchain-based digital currenciescan be a successful part of our digital future, however to some degree it has alsobecome a victim of its own success when it comes to the adoption rates in real-world scenarios, as well as the feasibility of implementing the approach in reale-commerce solutions nowadays. As consequence, various other models for digitalcurrencies have emerged, trying to resolve the problems that Bitcoin’s originalplan had failed at, yet none has been specifically aimed at solving the mostpressing concerns which are inherent to e-commerce systems’ designs nowadays.

2 Related Work

2.1 Blockchain technology

Fig. 1. General layout of records inside a blockchain. Orphan blocks (marked gray) areusually disregared, while the main chain (marked blue) dates (historically) from theroot of the block to today’s latest block (marked dark blue). Rogue blocks (marked grayand dark gray) are common attempts of bypassing authentication, but are disregardedon blockchain validation, usually through cryptographical analysis.

Blockchain technology [2] has been a major topic of discussion lately, espe-cially given the significant media coverage, as well as the various political, geo-economical and global implications that the adoption of the technology havedriven over the past few years.

3

At its core foundation, the blockchain is, intuitively named, a chain of dig-ital records (called ”blocks”) which are linked together in a secure, impenetra-ble manner using cryptography [3]. To ensure the security of the blockchain,each block usually includes a method of validating all or part of the previousblocks, considered to be sufficiently secure to ensure that the authenticity of theserecords cannot be modified through even the most computationally-intensive at-tacks, such as brute-force attempts. Figure 1 outlines the general layout of therecords inside a blockchain.

Digital currencies [1] which are based on decentralized blockchain technologyhave appeared in 2008, when Bitcoin [6] had emerged as the first one of its kind,also commonly referred to nowadays as ”crypto-currency”. The concept behinddecentralization is simple, yet creates a high-degree of confidence between itsadopters: a network of peers is initialized, with each peer having full accessto all of the previous transactions that happen in the network using the digitalcurrency itself. All transactions are passed on from one peer to another, until theypropagate to all peers in the network, and are validated (authenticated) with thehelp of the peers as well. In return for helping with the validation process, whichis generally involving mathematical (cryptographical) computations (sometimes,to an extensive degree), the contributing peer is given a small reward for itseffort, which stimulates further transaction validations and drives the growthof the currency’s adoption rate and, implicitly, that of the network itself (seeFigure 2).

Fig. 2. A network of peers, comprised of individual users (single peers) and collectionsof users (pools of peers). A trust relationship (marked red) governs the network inblockchain-based digital currency implementations. A change issued from user A ispropagated to the entire network of peers through synchronization. Blue lines outlinepossible digital transactions issued between various peers of the network.

4

2.2 Challenges and limitations of blockchain-based digitalcurrencies

When it comes to implementing digital e-commerce solutions, reliability/secu-rity, scalability and high-volume transaction processing are the most importantfactors that drive the best results. We attempt to analyze each of these fac-tors as follows, identifying the strong and weak points of other blockchain-basedtechnologies existing today.

Processing of high-volume transactions When Bitcoin [6], as first digitalcurrency, was designed in 2008, the hardware at the time was capable of produc-ing less computational power than today. As a consequence, validating blocks oftransactions for the blockchain structure every 10 minutes was a solution thatseemed acceptable at the time - yet, the currency itself was not specifically de-signed to support a very high volume of transaction on a regular basis. However,given the large adoption rate of blockchain-based technologies, and the high-volume of transaction being actively processed in enterprise-grade e-commercesystems nowadays, such a technology has to be revamped and adapted to to-day’s growing needs for electronic payments. For example, Salesforce [10], backin 2013 [11] topped more than 1.3 billion transactions per day, or more than900,000 transactions per second in their systems. By comparison, Ethereum [12]is limited to about 20 transactions per second due to the inherent flaws of theblockchain’s design, limitation which was mostly obvious with the release of theCryptoKitties blockchain game [13] that had caused a lot of transactions tooverload the network to a significant degree. At the same time, Bitcoin’s designlimits the number of transactions that can be processed to a mere number ofjust 3.3 to 7 transactions per second [14].

A proper rewarding system for proof-of-work One of the main issueswith Bitcoin’s computational model [6] is that the validation of blocks is notalways properly balanced in terms of rewards distributed to workers. In otherwords, peers in the decentralized network which contribute to the authentica-tion of transactions as part of the block, are only rewarded when a block isfinalized. Since finalizing block validation is a computationally-intensive process(called ”mining” in common terminology nowadays), peers with faster hardwareresources will always be able to finish sooner than others with less powerfulhardware, causing an imbalance amongst peers and determining the reward tobe lost by those that have attempted mining on their own, but did not get achance finish it. With increasing mining difficulty, mining pools have emerged,grouping multiple workers together with the hope of being able to produce blockson a much faster rate than before, yet distributing the rewards to each workerbased on the workload that they undertaken. This ensures faster and much moreconsistent smaller rewards, rather than much slower, but much larger ones. Itis important to understand that in this scenario, workers are no longer consid-ered to be peers in the network - they are a part of a mining pool, which runs

5

through its own, self-imposed distribution algorithm - so one could argue thatthe decentralization concept that made Bitcoin so popular in its early years, hasbeen plagued by a centralization of the workers (e.g. as in a syndicate, or union).

Ethereum’s model for rewarding workers is better from that perspective, as itprovides more incentive for peers to contribute to block consolidation operations,and rewards are more consistent. Nonetheless, its model is significantly morecomplex than that of Bitcoin’s, and there is still significant debate between thetechnology adopters [7] on whether the proof-of-work should be replaced by aproof-of-stake implementation, which is more energy efficient.

Computational requirements and energy efficiency Additionally, anothermajor issue of Bitcoin is that the computational power required to process trans-actions has grown exponentially lately, being projected to reach 0.5% of theworld’s total energy consumption [8] by the end of 2018 and, even worse, hadthe growth of Bitcoin been sustainable from back in 2017, by 2020 the energyconsumption was estimated to have exceeded that of the entire world [9].

Additionally, the blockchain size in the Bitcoin database has reached morethan 150 GB in the early days of 2018, according to [15], while Ethereum’sarchive has topped close to 400 GB in the same time period (nowadays, beingcloser to 410 GB, according to [16]).

With such high demand on the computational power required to authenticatetransactions happening in common widespread digital currencies, the financiallimitations of existing approaches becomes more clear: the mining of digital cur-rencies remains efficient only assuming that the financial rewards obtained as aresult thereof are sufficiently large to cover the ever-growing costs required toperform such an operation. Improperly designed digital currencies, specificallythose aimed at high-volume processing, have the inherent flaw of requiring anextremely high amount of storage, while improperly balanced blockchains suf-fer from the inherent flaw of offering low-throughput, infeasible for e-commerceplatforms nowadays capable of accepting thousands of transactions (or more)per second, on a regular basis.

At the same time, it is a general consensus still that the best security to-day comes from the mining process itself. It is the mining process that holdsthe integrity of the bitcoin transaction. To be able to break such a system (a51% attack, as it is often referenced), the total amount of power required tomanipulate the market would be enormous, and infeasible of being achieved inreal-world scenarios. This makes the mining process, at least in theory, moresecure than a proof-of-stake model, where the principles are different but stillunder great debate nowadays.

Refundable and non-refundable transactions As often in the case of e-commerce, and as an incentive to try out a new product or service, many re-tailers choose to offer a full refund within a specific number of days after thepurchase has been made by the final customer. A similar concept exists todaywith major credit and debit cards, which all support that approach. With the

6

existing blockchain design in Bitcoin, for example, this isn’t possible througha solid contract, meaning there is no enforcement from the network itself tooffer the refund, should it be requested for any reason. In fact, to the best ofour knowledge, there is no digital currency in existence today that is capable ofoffering both refundable and non-refundable transactions.

The only way to ensure a refund, is to have the seller willingly return thefunds to the buyer, which of course assumes the seller is well-intended (assumingthe buyer is not happy with the purchase for good reason), but also ensuringthat the buyer is not malicious in his or her intent to obtain a refund (e.g.assuming the buyer had already properly returned the item in the conditionrequested by the seller as part of the refund policy, etc.). Both approaches arenot implemented, by design, in the blockchain-based approach, and also requirean additional mining fee so that the miners can validate the transaction - whichcauses losses on both sides. See Figure 10 for an illustration on how this wouldwork.

To avoid those losses, and accomplish the two types of transactions above,we propose an approach that is strongly anchored into the blockchain designitself, and we present a potential approach to implementing it. Nonetheless,it’s important to remember that as various use-cases emerge for these typesof transactions, the need for a supervising authority (a ”Mediator”, as we callit) becomes obvious - nonetheless, we attempt to implement Mediators in adistributed manner, so that the Byzantine consensus [17] may be reached in thisscenario as well.

Affiliates and commissions A significant part of the marketing models inexistence today rely on sales made through affiliates and commissions being paidout adequately to them, based on those sales (see Figure 3). To the best of ourknowledge, no digital currency system in existence today is capable of offeringa model where, by design, the blockchain is capable of distributing commissionsfrom a specific sale to one or more affiliates, with a specific margin of profit foreach of these affiliates. In our design concept, we aim to overcome this issue, sowe are designing the blockchain in a multi-layered architectural format which iscapable of supporting affiliate marketing.

With this approach in mind, digital transactions will ensure that all mer-chants can automatically distribute commissions to their affiliates without theneed for 3rd party programming, additional infrastructure and human resources,as well as without the need of additional maintenance, all of which add signifi-cant amounts of money (fiat currency) being spent to have them implemented,tested and deployed. Additionally, the security of this proposed distributed ap-proach exceeds that of an individual, centralized implementation, which addseven more value to the approach itself, while at the same time it creates a trueblockchain-based marketplace that is open for custom business implementations,in various niches of interest.

7

Fig. 3. Short depiction of how affiliate marketing works.

Various business use-cases Another issue with most cryptocurrencies ex-isting today is that they were not well planned for particular business uses,such as lending money or manipulating the raw blockchain data using a customprogramming model, to create flexibility and even implement custom function-ality on top of the blockchain itself. Ethereum enhances the approach greatlyby proposing an entire platform on top of which a particular cryptocurrencymay be built, but that comes at the price of significant overhead and increasedcomplexity, with no particular focus on a single use-case (e.g. platform is toogeneral). In our opinion, it is better to design a blockchain structure that isflexible enough, compact enough and secure enough to ensure fast transactionprocessing, while still allowing particular business use-cases to be built on topof a light-weight micro-blockchain design, that evolves into various, more com-plex layers of functionality on top of the blockchain data core itself. This makessure that fundamental business use-cases in financial niches can be implementedeasier and without requiring regular maintenance from a dedicated developmentteam, while at the same time allowing more doors to be open for future protocolupdates, in case newer such use-cases are found.

3 Implementation

We are proposing a multi-layered, programmable blockchain approach to imple-menting digital currency (which we shall call ”DC” moving forward, for sim-

8

plicity), which paves the way to implementing custom smart contracts aimed atvarious e-commerce uses, such as: loan financing, refundable and non-refundabletransactions, etc. On the very first layer of the blockchain, the inherent digi-tal currency design is implemented - this is what we call the Foundation Layer(FL). Various upper layers are to be built on top of FL, describing variousadditional functionality tied to various business-driven usecases, which we willdiscuss shortly. All of these layers are fully programmable and can be very easilyadapted to the usecases of interest..

While most digital currencies today store the balance of transactions in theblockchain, our approach is comparable to that of PascalCoin’s cryptocurrency[18], and it uses a cryptographic structure which we call the Vault. The Vaultmaintains only the balance of all accounts in the network, rather than the en-tire list of transactions that have happened, and which can be reconstructedthroughout the history of the blockchain evolution. This reduces overhead forstoring the blockchain significantly, as the Vault can be easily pruned to anymoment in time. By comparison, the Bitcoin database takes about 170 GB atthe time of this writing (and continues to grow at an alarming rate, estimationsreaching 300 GB in 2019) to download, already making it infeasible for miningoperations on ultrabooks or laptops with small storage (e.g. 128 GB or 256 GB).Our blockchain size, on the other hand, will always be of a constant size, the sizeof just 50 blocks (while Bitcoin has more than 525,000 blocks in its blockchainat the time of this writing).

The Vault fully supports digital currency transfers between accounts andadditionally, it assigns to each account an owner-defined name, instead of a hashlike most cryptocurrencies do today - this makes the account easier to remember,and exposes the name publicly. See Figure 4 for an illustration of how the Vaultworks.

One important feature that helps prevent blockchain overhead, especiallywhen it comes to the history of the transactions, is the ability to create safecopies of the state of the blockchain, with the purpose of saving these states andreducing the size of the blockchain itself. Since the history of the transactionsis not required, and all accounts are stored through their direct balances, theblockchain becomes partially eraseable. All states of the blockchain which arebeing saved, are considered to be a landmark.

To a limited degree, our proposed implementation could be considered a”hard fork” of PascalCoin, which is less than 2 years old at the time of thiswriting. Nonetheless, one of the main limitations of PascalCoin is its inherentaccount creation method. By default, given PascalCoin’s block time of 5 minutes,only about half a million user accounts can exist in the PascalCoin network over aperiod of one year. This makes it not just slow, but also inadequate for real-timeprocessing of transactions in large-scale systems, where over the span of a year,an e-commerce platform may gain tens of millions of users, requiring thereforefast adaption of the network itself to the actual market growth. Therefore, webelieve that the additional features we propose expand the initial PascalCoinconcept to a significant degree, and bring the digital currency much closer to

9

Fig. 4. Functionality in the Vault. Miners produce blocks and forge them into theblockchain. Each block can update all Miner Reward Blocks before its inception. Eachblock creates a new corresponding Miner Reward Block with more accounts. The Vault’shash is computed using a SHA-256 cumulated hash of all previous hashes correspondingto all Miner Reward Blocks.

10

the concept of traditional banking, by introducing additional functionality suchas: fast creation of new accounts, support for refundable and non-refundabletransactions, a new type of mining called Mediators, support for affiliates andautomatic distribution of commissions, as well as for pre-mining, a more dynamicaccount creation methodology and a programmable multi-layered blockchain.

3.1 Secure data sharing

By blockchain structure design, with each transaction that is sent out into thenetwork, the blockchain may contain encrypted metadata (which may be usefulto send out private messages to the recipient of the data, or to execute pro-grammable instructions, as in our Layer 5 model presented in the whitepaper)that may only be decrypted by the recipient of the transaction. This is achiev-able by including the public key of the sender in the transaction being sent outto the network, and encrypting the metadata with the public key of the recipient- which would make the data decryptable by the recipient alone, as he carriesthe private key used for decryption purposes. As encryption methodology, whileBitcoin is restricted to elliptic-curve cryptography [19], the blockchain metadatamay be encrypted using any other mechanism, offering complete flexibility interms of choice of security and without compromising the blockchain’s structureor functionality.

3.2 Scalability

As our proposed blockchain supports historical landmarks by design, it is veryeasy to achieve high-scalability in the network itself, since the blockchain willalways require constant storage (relevant up to the last SL in existence). Thiscompletely eliminates the need to store a history of transactions just to computethe balance of all accounts, and instead just directly stores the balance of allaccounts, ensuring Byzantine consensus is given from all nodes in the networkabout those specific balances.

One of the biggest misunderstandings regarding blockchain technology lies inthe block time. When analyzing information propagation in the Bitcoin network[20], it was noticed that producing a block takes on average 6.5 seconds for thatblock to be properly propagated to just 50% of the nodes of the network. Toreach 95% of the nodes, 40 seconds were required, and the average delay is 12.6seconds. It is well worth noting that reducing the block time to anywhere as closeto 1 second as possible, highly increases the centralization risk, while having ablock time too high can induce stalls. It might seem that the average block timeof 12 seconds would be a good time for the block size, but nonetheless, thenetwork gets substantially more prone to attacks as the block time is lower, asdetailed in the Ethereum website [21] as well.

From a throughput perspective, the desired approach should involve littleto no waiting times for transactions, as well as low fees. As network usage in-creases, so will orphan blocks and chain re-organization. From previous empirical

11

evidence, Bitcoin forks with much shorter average block times end up produc-ing many more orphan blocks. On the other hand, longer confirmation timesmake chain reorganization less common. There were Bitcoin forks with a 30seconds block time, that had caused the network to converge after long peri-ods of time, potentially even permanently. Similar situations have occurred withBitcoin blocks with 60 seconds forks, so anything closer to a block time of 1minute (or even less) is very dangerous from a scalability perspective. Whilethere are other currencies, such as Ripple [22], that claim to offer transactionconfirmations in just a couple of seconds if not less, they do have one majorflaw: they are partially centralized, which helps them achieve the speed of theoperations. Through centralization, a network’s node of peers loses confidencein its implementation from a trust-factor perspective.

Based on all the considerations above, we can safely conclude that the bestaverage block time for a high-throughput, scalable and secure blockchain networkshould be settled at 2-2.5 minutes. The same conclusion was reached by LiteCoin[23], Monero [24] and other cryptocurrencies as well. In our approach, aiming forcomplete decentralization and the highest trust factor therefore, we propose touse a block time for confirmation of transactions of 2 minutes, which seems tobe a commonly accepted trade-off time nowadays for network stability, integrityand security.

3.3 User accounts

In our proposed model, just like in PascalCoin’s approach, user accounts are notgiven away as easily as it happens with most other cryptocurrencies (such asBitcoin, LiteCoin, etc.). Instead, genesis user accounts are pre-mined, up to acertain number in the genesis block (in our proposed approach, we start witha pre-mined 1 million accounts, all belonging to the founder of the blockchain;by comparison, there are about 30 million Bitcoin accounts at the time of thiswriting). The pre-mined accounts may be distributed to users belonging to anentity or an organization on a per-need basis, with the idea in mind that everynew block that is mined, gets 50 new accounts to the account who receives theblock reward also. This means that once the network picks up momentum, anuser with a single public key may own multiple accounts of digital currency in theblockchain. This creates a particular reward-driven ecosystem, where the systemensures that early adopters of the technology are rewarded for their contributionto the growth of the network, while late adopters will have to earn their right tojoin the network, either by paying for it or by contributing to it (e.g. by mining).

The PascalCoin implementation uses 5 new accounts per block. This severelylimits the adoption rate for new users, since only about 2.1 million accounts canbe created over a lifespan of 4 years. Therefore, we propose an approach whichallows 25 times more that amount, totalling 13.14 million new accounts per year.However, to avoid an overload of the network through account proliferation, wepropose the implementation of a ”purge” operation to be handled automatically,in every node, every 21,600 blocks (every 30 days on average).

12

The purge operation’s purpose is to reduce proliferation of useless accounts,reason as to which every node would react by removing all inactive accountsfrom the Vault during the purge. By inactive account, we mean an accountwhose balance is zero and has had no transactional activity of any kind in thepast 12 months (e.g. listing and delisting the account for sale does not count hereas transactional activity). This ensures that even if mining pools are sufficientlypowerful to obtain the rewards themselves, having that many accounts undertheir control does not monopolize the network. Even if the surplus of accountsis listed for sale by the owner, the closer to the purge time, the cheaper theseaccounts would become.

Fig. 5. The Account Distributor is assigning an account to the initiator of the JSONrequest, and propagates the changes to the network. Once complete, the user is now apart of the network as an individual node.

Our blockchain design also supports trading of accounts, meaning that ifsomeone wishes to sell one or more of their accounts in the network, they canbroadcast their intent to the network and specify a time-limit for the transaction.Nonetheless, this does not compromise the integrity or the anonymity of the

13

accounts in any way, since the names are fully configurable and they can bechanged at any time.

The founder of the blockchain could decide how to distribute the accountsbased on multiple relevant criteria: history with the company, contributions orstake in the company, etc. In fact, our architecture even takes into account anAccount Distributor API, which is capable of distributing accounts through aweb-based JSON-encoded communication protocol (see Figure 5).

With this approach, adopters who wish to join the network at a later time, caneither choose to receive an account from the miners that own multiple accounts,or can choose to pay for an account from those which are currently listed forsale. In fact, our Layer 1 of the blockchain allows what we believe to be thefirst actual implementation of a marketplace concept in the blockchain, creatingseveral different standalone micro-economies: one handling purchasing/selling ofaccounts in the network, one related to refundable transactions and mediatingdisputes, one related to lending currency, etc.

3.4 Security and proof-of-work

By design, a double-spend operation [25] (which is hypothetically possible inmost major cryptocurrencies in existence today, given certain favorable scenar-ios) is not possible in our proposed approach. Each transaction means a rathersimple update of the account balance to which the transaction applies to, withno particular way to revert the transaction from the network’s pending queue oftransactions.

The Vault is our blockchain’s fundamental structure, as all the technolog-ical/functionality layers are built on top of it, therefore it is essential to themining operation.

The blockchain in our proposed model is comprised of a series of blocks,where each block is being mined by voluntary nodes in the network using aproof-of-work model. All nodes in the network will update their account balancesindividually and independent from each other, based on the transactions thatare part of the blocks. The mining operation affects Layer 1 of functionality.Alongside the updating of balances, each node may also update various otheritems that are part of the blockchain structure, which may belong to upper layersof functionality as well. Once the update happened, a Mining Reward Block iscreated, containing a number of new, reward accounts allocated to the minerthat had been accepted as the winner of the reward for proof-of-work (currently,that number is 50 accounts), by assigning the winning miner’s public key to allthese accounts.

Mining ensures that the blockchain is kept secure. Each block includes a listof transactions that alter the financial state of one or more accounts, and justlike in PascalCoin, a block does not reference the previous block directly, yet itdoes reference the previous Vault hash, which links to the previous block via theMining Reward Block for that Vault hash.

The historical landmark concept represents a saved copy of the state of theVault throughout time. A landmark is created automatically after a number of

14

Fig. 6. The historical landmark and the checkpointing mechanism used to achieve con-stant storage.

15

Fig. 7. The blockchain layout in our proposed implementation. Various layers are de-picted, as well as the general (common) block structure contents.

16

blocks. In our proposed implementation, the number of blocks is 50, two timesless than that of PascalCoin, with a simple reason in mind: increase security ofthe network by reducing the chances of a 51% attack even further, and reducethe download size of the last landmark for the new nodes that join the network.In addition, when a new node joins the network and downloads its copy of theVault, it can independently verify its integrity by verifying the proof-of-workmetadata in the Vault itself. On every 50th block, the Vault’s state is beingsaved into a historical landmark which may be used for checkpointing purposesat any later time (see Figure 6). While it is not required in the network itself,there are nodes in the network which will hold the entire list of all historicallandmarks since the network’s inception.

To allow easy verification of the proof-of-work metadata, the Vault includesblock header information in every Mining Reward Block component. With thisin place, any node could verify the validity of proof-of-work by a) verifying thetransitive relationship between block headers via the Vault, b) recalculating alloperations used to update the Vault using the proof-of-work metadata and c)validating that the total amount of work (sum of every compact amount forevery block header) is the highest known in the network (if it isn’t, the Vault isdiscarded and the nodes from where it was obtained are blacklisted).

When a new node joins the network, in order to speed-up the process and re-duce download bandwidth, it downloads a multi-part archive concurrently fromthe network. The blockchain data is stored in a fixed-size multi-part archive for-mat, that, when put together in decompressed form, forms the historical land-mark. This is what we call the ”landmark discovery protocol”. The data that thenew node retrieves from the peers lies in: the block number of the landmark, theVault hash of it, total work and the Merkle tree [26] of the individual archivesdownloaded. With each part of the archive being downloaded concurrently frommultiple nodes, the need to validate the data becomes important, and here theMerkle tree helps achieve just that - by computing the hashes of individualarchives and grouping them together. To detect the correct landmark, the newnode selects the one with the highest amount of total work. The landmark’sintegrity can be verified by the new node by recomputing the total work andmatching it to the one retrieved during the initial discovery protocol. If the land-mark cannot be validated, it is dropped and the peers used for communicationare blacklisted, then the discovery protocol begins again. Once a valid landmarkis found, it is used as a Vault and it is followed by the synchronization protocol,where blocks are starting to be received from peers. In our model, a node will nothave to download more than 50 blocks to complete the synchronization protocol.

The core architecture of a block in the blockchain is presented in Figure 8,while the Miner Reward Block structure proposed is shown in Figure 9. As forpotential rewards for mining a block, we propose the model below:

– For the first year (blocks 0 to 262,799 blocks), the reward is 1,000 DC (total262.8 million DC)

– For the second year (blocks 262,800 to 525,599), the reward is 500 DC (total131.4 million DC)

17

Fig. 8. The core architecture of a block in the blockchain.

Fig. 9. The core architecture of a Miner Reward Block in the blockchain.

18

– For the third year (blocks 525,600 to 788,399), the reward is 250 DC (total65.7 million DC)

– For the fourth year (blocks 788,400 to 1,051,099), the reward is 125 DC (total32.85 million DC)

– For the fifth year (blocks 1,051,100 to 1,313,999), the reward is 50 DC (total13.14 million DC)

– For all years to follow, the reward is 10 DC (total 2.628 million DC per year)

3.5 Blockchain technological layers

Our DC model is comprised of a multi-layered architecture, with the first layerbeing represented by the currency implementation itself (see Figure 7 for a graph-ical explanation). The layers are:

Blockchain layers in proposed modelLayerno.

Layer description Use-case

1 Digital currency(crypto)

Currency transfers, mining

2 Refundable andnon-refundabletransactions

Allows refundable transactions, with adigital judicial system in place

3 Affiliates and com-missions

Allows automatic distribution of com-missions to affiliates

4 Lending currency Lending currency as means to gainmore revenue from interest rates

5 Programmable Reserved for future implementation ofa Turing-complete programming modelto manipulate blockchain data in cus-tom ways (e.g. smart-contracts).

6, etc. Custom protocols Reserved for future use-cases.

We outline the various transaction types in their corresponding blockchainlayers.

3.6 Transaction types

With our model, we allow multiple transaction types, on the various layers avail-able in the blockchain by design. Layer 1 transaction types are show below.

19

Layer 1No. Transaction name Use-case

1 Transfer Transferring funds between accounts (1-on-1transfers)

2 Refundable-Transfer

A refundable transaction between accounts.Amount is deposited in the escrow balance in-stead of the regular account balance.

3 Key-Change Changing the key for handling an account4 Recuperate-

AccountRecuperate funds from a lost, inoperative ac-count (lost key)

5 Set-Account-Name Defining the name of an account owned by ini-tiator

6 Ready-For-Sale For marking an account as being available forsale

7 Remove-From-Sale For unmarking an account, and making it un-available for sale

Every transaction may also have a reward fee associated to it, to drive theincentive to include it in the next blockchain on a faster basis. However, transac-tions may also have no fee associated to them, in which case the miner is aimingto obtain the blockchain reward fee and also the corresponding Mining RewardBlock, with the new accounts being assigned to him.

3.7 Refundable transactions and Mediators

For most cases, non-refundable transactions are the equivalent of 1-on-1 pay-ments inside all blockchain-based digital currency models. However, we intro-duce the concept of refundable transactions in our DC model. A transaction hasa small flag that specifies whether it is refundable or not. Additionally, each ac-count in our network has two types of balances: the regular, immutable balance,which marks the funds that are immediately and irremediably received by thisaccount, and an escrow balance, which holds a list of transactions which aremarked as refundable, along with the number of minutes for each transaction.

Layer 2No. Transaction name Use-case

8 Payment-Dispute Initiates a payment dispute for a transactionthat was marked as refundable. Can only beinitiated by the sender of the funds.

9 Refund-Request Initiates a refund request for a previous trans-action marked as refundable. Can only be ini-tiated by the sender of the funds.

10 Cancel-Escrow Cancels the funds in escrow and immediatelyreturns them to the sender. Can only be initi-ated by the recipient of the funds.

11 Release-Escrow Releases funds in escrow and immediatelyadds them to the balance of the recipient. Canonly be initiated by the sender of the funds.

20

With our proposed approach, we introduce a new type of mining and in-herently, a new type of miner, called ”Mediator”. A Mediator is a miner whois trusted by the network, by a specific trust factor. In fact, it is the earliestform of distributed judicial system implementation in any digital currency, thatwe are aware of. Any node in the network can be a Mediator, and, of course, aregular miner at the same time. By analogy, a Mediator is the equivalent of adigital jury member.

If a transaction is marked as refundable, another field in the blockchain spec-ifies the number of minutes during which the refund may be granted - implicitly,this is also the number of minutes in which the amount will remain in the re-cipient’s escrow account. Additionally, a ”dispute fee” will be specified by themerchant, to ensure that Mediators are rewarded in case of a payment dispute.Only the recipient of the refundable payment can cancel the payment, immedi-ately returning the amount to the sender of the payment, and only the senderof the payment can confirm the payment, immediately moving the amount tothe recipient’s wallet. There is also a timeout period, given by the number ofblocks (with a minimum of 10 minutes, or 5 blocks, being accepted; all transac-tions under this minimum threshold will be discarded automatically) in whichthe payment can be refunded to the sender, in case the product is returned. Itis important to understand that escrow balances are not tradeable and cannotbe used for making other payments in the network, of any kind.

A legal form of organization is required when a merchant has a payment dis-pute for a specific refundable transaction. For example, let’s assume a customer(initiator of refundable payment, to the escrow account of merchant) wishes arefund claiming that the product was shipped back and not what it had hopedfor. Specifically, there are some scenarios when the merchant claims that the re-fund cannot be granted (e.g. merchant claims they have not received the productback, therefore cannot approve the refund). At this point, it is up to the Media-tors to decide whether to approve or deny the refund request. To support theirclaims, both the merchant and the customer have to provide proper paperworkand documents supporting their claim, with links included in the transactionmessage are of our blockchain. Additionally, a customizable reward for perform-ing mediation will be split between the first MinMediators Mediators that agree,in consensus, whether to approve or deny the refund request. MinMediators is aconfigurable number, and in our scenario MinMediators is chosen to be 6, justlike in a real court of trial. If some Mediators agree while others disagree, thevoting difference between the winning party has to be at least MinMediators toconsider the payment dispute resolved (e.g. to refund a payment, at least 6 moreMediators have to agree on the refund compared to the actual number of Medi-ators who disagree; for example, if 14 Mediators agree and 8 disagree, refund isgranted, but if 14 Mediators agree and 12 disagree, payment is still consideredunresolved).

A Mediator’s job, as a miner, comes down to two things:

1. First, to analyze the documents provided for mediation by both the mer-chant and the customer. These documents can (and should) include: proof

21

of delivery from merchant’s side, proof of receiving (merchant side), proof ofreturn (customer side), proof of condition (from both merchant and customersides), etc.

2. Second, to decide whether to approve or deny the refund request.

To increase the trust factor, a miner should be allowed to become a Mediatoras well, if he has a minimum of 6 months of experience in the network and anon-zero balance in his or her account. It is important to note that this process isentirely manual. A miner who is allowed to mediate, and who wishes to mediatea request, can choose one or more requests from the list of payment disputes andcan choose to validate or invalidate the request, once the review is over.

Let’s assume a customer wishes to purchase a refundable, tangible product.The workflow of refundable transactions we propose through our blockchain isthe following:

1. First, the customer makes the payment and marks it as refundable throughRefundable-Transfer, for the number of minutes specified by the merchant.

2. If the merchant finds that escrow time is higher than the maximum allowed(e.g. 60 minutes instead of 30 minutes the maximum), they cancel the es-crow payment through a Cancel-Escrow transaction and funds are returnedto the customer immediately. Otherwise, merchant delivers product to thecustomer, keeping proof of delivery and proof of condition (for potentialfuture disputes).

3. Once the customer receives the product, if they are happy with it, theycan immediately release the payment from the escrow account into the mer-chant’s account through a Release-Escrow transaction.

4. If the customer does not receive the product or is scammed, they can initiatea Payment-Dispute transaction (including all relevant documentation for it).

5. If the customer is not happy with the product, they can return it (keepingproof of return, proof of condition on shipping, etc. for potential disputes)and initiate a Refund- Request transaction.

6. If the merchant received a Refund-Request but does not agree, they initiatea Refund-Dispute transaction (including all relevant documentation for it)and at this point, the Mediators see the transaction listed for analysis.

7. Once the minimum number of Mediators agree on the dispute result, theadequate transaction is initiated: either a Release-Escrow when the mer-chant wins, or a Cancel-Escrow then the merchant loses. In addition, throughour Turing-complete language implementation compiler, custom implemen-tations may be added in the future through programming for a) maintaininga number of wins and losses for disputes for a merchant, b) implementing arating system based on the number of wins or losses, etc.

Mediators are accepted on a first-come, first-serve basis, and they can makecomments for their decision when sending their approval or disapproval in theblockchain. In other words, the fastest Mediators are the ones to be rewarded.The reward is split between the number of all Mediators that have agreed last,minus the number of Mediators that have disagreed (e.g. if 20 agreed, and 12disagreed, the reward will be split by the last 20-12=8 Mediators that agreed).

22

Fig. 10. Refundable transactions ensure that funds can be returned to the customerafter they return the product. In case of disputes, Mediators decide the faith of the sale.

3.8 Affiliates and commissions

One important missing piece of the puzzle in today’s blockchain-driven finance-related technologies, is the lack of the ability to reward affiliates for sales madefor a specific product or service. Layer 3 of our blockchain proposes to resolvethis problem. To that extent, the merchant has to have a separate account, calledan Affiliate Merchant Account (AMA). An AMA is a regular account, which ismarked however accordingly in the blockchain for that specific owner.

As there are multiple marketing models that support affiliates such as directaffiliates (where the commission is generally distributed to one affiliate only) ormulti-level marketing (where the commission may be spread out on a pyramid-alike principle), we introduce an additional type of node, called Trusted PaymentGateway (TPG). The TPG has an associated trust factor to it: by design, itsrole is to ensure that it acts as a fair buffer between affiliates and merchants.By all means, the TPG account is still acting like a normal account type, exceptthat it implements local logic to make sure that affiliate commissions are paidout, corresponding to the business model defined.

Communication between TPG and AMA nodes may happen through cus-tom protocols, but we propose a simple, web-based, JSON-encoded protocolthat allows a) merchants (AMAs) to subscribe to the TPG and announce theirpresence and b) AMAs to define products for sale (through a product ID) withthe corresponding affiliate-rewarding scheme associated to them (e.g. direct-sale,multi-level commissions, etc.). Additionally, affiliates can subscribe to TPGs asaffiliates for specific AMAs and their specific product IDs.

23

The TPG employs therefore a local database that holds, for each merchantsubscribed to its services, a list of products on sale. For each product, the TPGalso defines the commission payout rates. Every TPG may impose different feesto merchants and/or affiliates for the service(s) that it offers, and it is up tothem to decide which TPGs are the best to use. It is worth noting here thateven an AMA can act as a TPG on its own, presuming it implements the logic ofdistributing commissions automatically after a sale to its affiliates (however, thisdoes require time, resources - both human and financial - as well as permanentmaintenance, which is why 3rd party TPG services may be better suited for themajority of business models).

When a sale is made, the final customer pays to the TPG directly, with thetransaction cargo (provided to him by the affiliate) including the following in-formation: the AMA ID and the product/service ID. Without these two piecesof information present in the cargo, the transaction is unanimously discarded bythe network. The TPG’s role is therefore to process all payments for products,goods and services, on behalf of the merchant itself. Once a sale is final (e.g.passed refundable due date, or the payment was released from escrow by cus-tomer), the TPG automatically pays the funds to the original seller by initiatinga transaction in the blockchain, and also sends out one or more transactions tothe respective affiliate account (or accounts) that intermediated the sale. Thisensures that both the seller and the affiliate(s) are paid adequately and fairly.By inherent design, the blockchain could support not just 1-on-1 transactions,but also 1-to-many transactions, where one single transaction initiated by theTPG can help update the balance of multiple affiliate accounts in the network,concurrently.

3.9 Lending digital currency

Lending digital currency is one easy and fast approach to allowing people to bor-row fiat currency, while still keeping their cryptoassets safe. Since valuable digitalcurrencies are commonly traded nowadays, lending money becomes a possibilitynot only because it allows borrowers to deposit practically any type of cryp-tocurrency as collateral, but also because it is an attractive way to keep a holdof your digital assets in a completely secure manner and with little risk. Addi-tionally, our model proposes built-in protection through a custom Vault LendingGateway (VLG), that acts as a buffer between the lender and the borrower itself(see Figure 12).

In our proposed DC model, our Layer 4 of the blockchain ensures that lend-ing currency is becoming possible through blockchain design directly, ratherthan through a smart-contract implementation such as in Ethereum and otherplatforms. The immediate advantages of this approach is a light-weight (fast)implementation and significantly increased bandwidth throughput (due to lessoverhead).

The lending process is simple: with the help of a Vault Lending Gateway,lending money becomes similar to the software-as-a-service approach. Any ac-count may be marked as a VLG, however only trusted VLGs should be used

24

Fig. 11. Implementation of a Trusted Payment Gateway (TPG) for blockchain-basedaffiliate marketing.

Fig. 12. The workflow of the lending process in our proposed implementation.

25

throughout the platform. An account marked as a VLG should implement anadequate lending policy, and should also accept external fiat currency througha dedicated software infrastructure, to accommodate the loans. Generally, earlyadopters of the blockchain should be the ones to be the most trust-worthy forlarger loans, while newcomers should be treated with reluctance and pre-testedwith smaller loans. Each VLG should also advertise a loan-interest rate. Themore VLGs exist in the system, the more competitive this niche becomes in theblockchain network.

The idea behind the lending process lies in the high volatility of cryptocur-rencies nowadays. The lending process aims not only to alleviate the effects ofthe volatility of cryptocurrency, but also to allow people to receive loans in fiatcurrency without having to entirely give up their digital assets (e.g. by sell-ing them). Each VLG should have implemented a risk-handling policy, where itwould specify up to what amount the borrower may be receiving the amountof fiat currency desired, based on the digital currency that they are selling.For example, one VLG could consider accepting digital currency from the bor-rower in exchange for only 80% of the market value of that currency. Each VLGshould offer built-in market analysis and prognosis capabilities, to ensure thatthe volatility does not cause extreme losses to both parties involved. In exchangefor its service, the VLG may charge a specific fee, either in digital or fiat cur-rency. Additionally, a VLG may also accept regular loan payments either in fiatcurrency or in digital currency also.

As an example, assuming that a borrower wishes to get fiat currency for ourdigital currency (DC) at a rate of 1 DC = 100 USD. The price of DC is currentlyfollowing an increasing trend on the market, so the borrower wishes to keep thedigital assets, but at the same time they do need the fiat currency - which iswhat determines the loan request to the VLG. Let’s say the VLG the borrowerchooses to work with, is offering 80% of the market value of DC. Borrower needs1,000 USD, so he pays 12.5 DC and receives the equivalent of 80% of that infiat currency, which is 1,000 USD. The risk-handling policy is in place to ensurevolatility protection, since although the price trend might be increasing now, itmay also drop significantly in the near future, throughout the period of the loan.There are multiple scenarios here that could happen: 1) price of DC grows, 2)price of DC stalls, 3) price of DC drops. In scenario 1), when price of DC growsto 1 DC = 200 USD, borrower can pay the entire amount of 1,000 USD and getsback the collateral deposit of 2.5 DC. If the loaner is not repaid in full by thedeadline, the borrower could be allowed to pay just the interest rate and thenrefinance the loan.

One additional element of trust here could come from the implementation ofthe escrow account for the VLG itself. In other words, when borrowers deposittheir digital currency, and it goes directly into the escrow balance of the accountmarked as a VLG. Upon return of the loan, the VLG will return the digitalassets to the borrower. If the loan is not returned on time, the borrower mayvoluntarily release the funds from the escrow balance into the VLG’s regularbalance. In case of a dispute however (whether coming from the borrower, not

26

wanting to release the funds to the VLG instead demanding a return of thedigital assets, or from the VLG requesting a release of funds from escrow), thecase may be sent to Mediators for proper arbitration, pertaining to a similarscenario as the one described for refundable and non-refundable transactionspreviously. However, when using an escrow account, a VLG may have to dealwith the ”liquidity” issue on its own, since in general VLGs are aiming to tradethe digital assets received in order to obtain funding and pay the interest rateto the lender - to that extent, the escrow account may only be used to hold thecollateral deposit of 20%, as in the scenario presented above.

The implementation, on a transaction/protocol-level, the functionality above,is presented in the table below. By design, the blockchain structure allows morethan the basic operations described below and the future implementations maytake that into account, as well as potentially change or adapt the existing oper-ations below for improved protocols for lending currency.

Layer 4No. Transaction name Use-case

12 Borrow-Money Issued by borrower inside the network. An-nounces the intention to borrow money. Alsospecifies the VLG account for which to bor-row money. This transaction is very much likea deposit in the regular/escrow balance of thechosen VLG’s account.

13 Return-Collateral Issued by the VLG itself. Will occur once thecollateral is to be returned to the borrower, asper the risk-handling policy of the VLG.

14 Pay-Loan Issued by the borrower. Borrower may alsochoose to pay for the loan in digital currency,should the VLG accept such a form of pay-ment. Funds will go to the regular balance ofthe VLG.

3.10 Programmable blockchain

Layer 5 of the blockchain, through its associated metadata payload, is reservedfor the implementation of a grammar-based, Turing-complete basic program-ming language that would allow raw blockchain data manipulation for furthercreation of smart contracts between the peers of the network. Each payloadcan be encrypted or publicly visible, and will be executed through a dedicatedvirtualized environment, very much like a virtual machine, capable of securingthe data and avoiding data and security breaches. The main advantage of theapproach is that this layer allows creation and enforcement of digital contractswithout requiring any specialized programming of the blockchain itself.

This layer, along with the proper grammar definition and semantic contextfor its implementation, is considered in a future update of our approach. At

27

the same time, the upcoming layers (6, 7 and so on) can additionally be usedfor extending the protocol with more use-cases, on a per-need basis, with thedisadvantage that such an implementation would require a soft or a hard forkin the blockchain itself.

4 Experimental Results

An experimental implementation is currently being worked on and will be avail-able shortly on GitHub, the world’s biggest open-source platform.

5 Conclusion

We have analyzed the major challenges and limitations of existing blockchain-based digital currencies, and have identified the most important aspects fortransactional processing in modern e-commerce systems nowadays. As a resultof the analysis, we have proposed a multi-layered, scalable and high-throughputfocused programmable blockchain model for digital currency, whose aim is toprovide a feasible solution to the growing needs of common e-commerce solu-tions today, while also benefitting from a secure, blockchain-focused implemen-tation. We propose multiple innovative features in our blockchain design and aswe analyze the theoretical background behind it, we show how it may be usedto reliably become a solid foundation for the future of e-commerce, while alsoimplementing additional functionality commonly found in modern financial in-stitutions and opening multiple doorways to custom programming on top of theblockchain’s raw data itself.

References

1. Wikipedia: Digital currency, https://en.wikipedia.org/wiki/Digital currency

2. Wikipedia: Blockchain, https://en.wikipedia.org/wiki/Blockchain

3. Wikipedia: Cryptography, https://en.wikipedia.org/wiki/Cryptography

4. Wikipedia: Cryptographic hash function, https://simple.wikipedia.org/wiki/ Cryp-tographic hash function

5. Wikipedia: Public key cryptography, https://en.wikipedia.org/wiki/Public-key cryptography

6. Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System,https://bitcoin.org/bitcoin.pdf, 2008.

7. CryptoSlate: Ethereums Proof of Stake Protocol Under Review,https://cryptoslate.com/ethereums-proof-of-stake-protocol-in-review/

8. Alex de Vries, Bitcoin’s Growing Energy Problem, Joule, 2 (5): 801 DOI: 10.1016/ j.joule.2018.04.016, 2018.

9. Bitcoin Energy Consumption Index, https://digiconomist.net/bitcoin-energy-consumption

10. SalesForce, https://www.salesforce.com/

28

11. HighScalability.com: Salesforce Architecture - How They Handle 1.3 Billion Trans-actions A Day, http://highscalability.com/blog/2013/9/23/salesforce-architecture-how-they-handle-13-billion-transacti.html

12. Ethereum Project, https://www.ethereum.org/13. Bloomberg: CryptoKitties Mania Overwhelms Ethereum Network’s Process-

ing, https://www.bloomberg.com/news/articles/2017-12-04/cryptokitties-quickly-becomes-most-widely-used-ethereum-app

14. Wikipedia: Bitcoin scalability problem, https://en.wikipedia.org/wiki/ Bit-coin scalability problem

15. Statista: Size of the Bitcoin blockchain from 2010 to 2017,https://www.statista.com/statistics/647523/worldwide-bitcoin-blockchain-size/

16. Current ethereum blockchain size, http://ethereumchainsize.com/17. Wikipedia: Byzantine fault tolerance, https://en.wikipedia.org/wiki/Byzantine

fault tolerance18. PascalCoin, https://www.pascalcoin.org/19. Certicom Research, SEC 2: Recommended Elliptic Curve Domain Parameters,

http://www.secg.org/sec2-v2.pdf, 201020. Christian Decker, Roger Wattenhofer, Information propagation in the Bitcoin net-

work, IEEE Thirteenth International Conference on Peer-to-Peer Computing(P2P), DOI 10.1109/P2P.2013.6688704, 2013

21. Vitalik Buterin: Toward a 12-second Block Time,https://blog.ethereum.org/2014/07/11/toward-a-12-second-block-time/

22. Ripple, https://ripple.com/23. LiteCoin, https://litecoin.org/24. Monero/CryptoNote v2.0, https://github.com/monero-project/research-

lab/blob/master/whitepaper/whitepaper.pdf25. Wikipedia: Double-spending, https://en.wikipedia.org/wiki/Double-spending26. Wikipedia: Merkle tree, https://en.wikipedia.org/wiki/Merkle tree