Whitepaper - Bitshares With Cover
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
BITSHARES WHITEPAPER
BITSHARES 2.0: GENERAL OVERVIEW<br />
Fabian Schuh, Daniel Larimer<br />
Cryptonomex, Cryptonomex.com ∗<br />
Blacksburg (VA), USA<br />
{ fabian, dan }@cryptonomex.com<br />
Abstract—BitShares 2.0 is an industrial-grade decentralized<br />
platform built for high-performance financial smart contracts.<br />
The decentralized exchange that allows for trading<br />
of arbitrary pairs without counterparty risk facilitates only<br />
one out of many available features. Market-pegged assets,<br />
such as the bitUSD, are crypto tokens that come with all<br />
the advantages of traditional cryptocurrencies like bitcoin<br />
but trade for at least the value of their underlying asset, e.g.<br />
$1. Furthermore, BitShares represents the first decentralized<br />
autonomous company that lets its shareholders decide on<br />
its future direction and products. This paper gives a brief<br />
overview over the whole BitShares platform, recapitulates<br />
known blockchain technologies and redefines state-of-the-art.<br />
1 Introduction<br />
BitShares is a technology supported by next generation entrepreneurs,<br />
investors, and developers with a common interest in<br />
finding free market solutions by leveraging the power of globally<br />
decentralized consensus and decision making. Consensus<br />
technology has the power to do for economics what the internet<br />
did for information. It can harness the combined power of all<br />
humanity to coordinate the discovery and aggregation of realtime<br />
knowledge, previously unobtainable. This knowledge can<br />
be used to more effectively coordinate the allocation of resources<br />
toward their most productive and valuable use.<br />
Bitcoin is the first fully autonomous system to utilize distributed<br />
consensus technology to create a more efficient and<br />
reliable global payment network. The core innovation of Bitcoin<br />
is the Blockchain, a cryptographically secured public ledger of<br />
all accounts on the Bitcoin network that facilitates the transfer of<br />
value from one individual directly to another. For the first time in<br />
history, financial transactions over the internet no longer require<br />
a middle man to act as a trustworthy, confidential fiduciary.<br />
BitShares looks to extend the innovation of the blockchain<br />
to more industries that rely upon the internet to provide their<br />
services. Whether its banking, stock exchanges [1], lotteries [2],<br />
voting [3], music [4], auctions or many others, a digital public<br />
ledger allows for the creation of distributed autonomous<br />
companies (or DACs) that provide better quality services at a<br />
fraction of the cost incurred by their more traditional, centralized<br />
counterparts. The advent of DACs ushers in a new paradigm in<br />
organizational structure in which companies can run without any<br />
human management and under the control of an incorruptible set<br />
of business rules. These rules are encoded in publicly auditable<br />
open source software distributed across the computers of the<br />
companies’ shareholders, who effortlessly secure the company<br />
from arbitrary control.<br />
BitShares does for business what bitcoin did for money by<br />
utilizing distributed consensus technology to create companies<br />
that are inherently global, transparent, trustworthy, efficient and<br />
most importantly profitable. Why and how BitShares achieves a<br />
decentralized but profitable business is described in more detail<br />
in a distinct paper [?].<br />
BitShares has went through many changes and has done its<br />
best to stay on top of blockchain technology. Towards the end<br />
of 2014 some of the DACs were merged and the X was dropped<br />
from ”BitShares X” to become simply BitShares (BTS).<br />
The next step in the evolution of BitShares was named <strong>Bitshares</strong><br />
2.0, and incorporates all of the feedback and lessons<br />
learned from the BitShares stakeholders, partners, developers,<br />
marketers, and other community leaders throughout a full year<br />
of research and development.<br />
<strong>With</strong> the former BitShares 1.0, the core development team has<br />
closely controlled the development and direction of BitShares.<br />
<strong>With</strong> BitShares reaching maturity at version 2.0, the team is<br />
ready to remove the training wheels, and let the direction of all<br />
future development be decided completely by stakeholder vote.<br />
By utilizing a new worker voting system that will be included<br />
in BitShares 2.0, the development will continue in whatever<br />
direction is approved by its stakeholders. <strong>With</strong> this new structure,<br />
BitShares will be more robust, and sustainable while being agile,<br />
flexible and adaptive to overcome unforeseen hurdles of the<br />
future.<br />
This paper is intended as an introduction to BitShares 2.0<br />
and presents the basic concepts of the peer-to-peer nature, the<br />
distributed public ledger in form of a blockchain, and give a<br />
brief overview of the decentral consensus mechanism applied to<br />
reach blockchain state consensus. We further discuss the basic<br />
blockchain tokens (BTS), its distribution and usage in BitShares.<br />
We also describe the wallet and operations with the network as<br />
well as outline the functionalities of BitShares accounts.<br />
∗ This work was supported by Cryptonomex and honorable members of the<br />
bitsharestalk.org community.<br />
Release: stress-test/1.0-1-g96f3268 (2017-04-04)
2<br />
2 Base Token<br />
In the BitShares network the base token is called a BitShare and<br />
carries the abbreviation BTS. It is dividable into 10 5 = 100,000<br />
sub-units.<br />
In general, all properties of Bitcoin also apply to BTS,<br />
namely, they have value, can be transfered on the blockchain<br />
and are secured by an Elliptic Curve Digital Signature Algorithm<br />
(ECDSA) on the curve secp256k1.<br />
In contrast to most crypto-currencies, BitShares does not claim<br />
to be a currency but rather an equity in a decentral autonomous<br />
company (DAC). As a result, the market valuation of BitShares<br />
is free floating and may be as volatile as any other equity (e.g. of<br />
traditional companies).<br />
Nonetheless, BTS tokens can be used as collateral in financial<br />
smart contracts [5] such as market pegged assets and thus back<br />
every existing smartcoin such as the bitUSD.<br />
The following subsection recapitulate the initial distribution<br />
and supply of BTS.<br />
2.1 Distribution of BTS<br />
BitShares has set an example of a social agreement by establishing<br />
its own sharedropping standards. The idea behind<br />
sharedropping is that any future chain will always benefit by<br />
choosing to align itself with the ones who worked hard at making<br />
the technology possible.<br />
The base tokens of BitShares 2.0 will be distributed on a<br />
1:1 basis fully honoring the BTS tokens in the BitShares 1.0<br />
network. For the sake of completeness, the following paragraphs<br />
will describe the initial distribution of BTS tokens in the aforementioned<br />
BitShares 1.0 network from PTS and AGS.<br />
2.1.1 <strong>Bitshares</strong> PTS<br />
The original grandfather prototype, formerly called proto-shares<br />
(PTS), BitShares PTS was a simple minable cryptocurrency<br />
(similar to Bitcoin) that was created to allow people to advertise<br />
their interest in receiving free token samples in future DACs.<br />
PTS functions as a high-tech mailing list for distributing free<br />
sample bitshares from many developers of decentral autonomous<br />
companies (DACs). The only people who tended to own PTS<br />
tokens were those who understand DACs, so DAC developers<br />
prefer to target them with free samples rather than air dropping<br />
their samples onto a much less interested general population.<br />
The industry recommendation was that when a DAC is<br />
launched, at least 10% of the DAC’s total tokens are given<br />
proportionally to holders of PTS. This was not a contract or<br />
a guarantee; it was a social consensus of those in the DAC<br />
community about what percentage of a new DAC’s tokens should<br />
be distributed to those who have supported the BitShares industry<br />
by owning its PTS tokens.<br />
The BitShares DAC honored this social consensus and even<br />
sharedropped 47% of its ever existing supply onto BitShares PTS<br />
holders.<br />
2.1.2 <strong>Bitshares</strong> AGS<br />
The original grandmother prototype formerly called angel-shares<br />
(AGS) in reference to the patron angels who once funded the<br />
performing arts. That’s why AGS are not liquid. (No one can<br />
trade the proof that you were the once willing to donate to this<br />
cause.)<br />
The donations have been recorded in the public blockchain<br />
of bitcoin which now acts as a book of honorable donors. The<br />
bitcoin address used as donation address was<br />
1ANGELwQwWxMmbdaSWhWLqBEtPTkWb8uDc<br />
Note, that the donation period for AGS lasting 200 days has<br />
ended already and that donations to this address never resulted<br />
nor will result in any obligations whatsoever.<br />
Since the social consensus includes AGS, the industry recommendation<br />
again is to give at least 10% to holders of AGS.<br />
Similar to BitShares PTS, the 47% of the total BTS supply<br />
have been sharedropped onto members of the AGS mailing-list<br />
proportionally.<br />
2.2 <strong>Bitshares</strong> Genesis Distribution<br />
We see that the seed allocation (initial distribution) of BitShares,<br />
which took place over a 1 year period, from November 2013<br />
to November 2014, was achieved by sharedropping 47% to<br />
BitShares PTS and another 47% to BitShares AGS. This way, the<br />
full, fairness was defined by equal opportunity and in the case of<br />
BTS we have distributed fairly by CPU mining of PTS while,<br />
alternatively, everyone had an additional equal opportunity by<br />
contribute to AGS.<br />
Having attracted two different groups of investors with a<br />
mined crypto token via PTS and a donation based book of donors<br />
via AGS, everyone had a chance to participate and be rewarded<br />
with stake in the genesis block of BitShares 1.0. This genesis<br />
block solely consisted of AGS and PTS holders on a 50%/50%<br />
ratio such that the BTS tokens initially issued by this genesis can<br />
be considered well distributed.<br />
The other 6% are set aside to secure the future of BitShares and<br />
funds its development and operational costs. In practice, they are<br />
put into the so called reserves pool that no one has control over<br />
except the BitShares protocol. In contrast to many other cryptocurrencies,<br />
every shareholder has a say as to how these funds are<br />
spend (see section 4.2).<br />
3 Business Units<br />
Let us discuss the organization structure of the BitShares network<br />
when interpreted as a company. Some of these entities are<br />
associated with a cost for the business and need to be accounted<br />
for in profit calculations.<br />
3.1 BitShares Witnesses<br />
In BitShares, the witnesses’ job is to collect transactions, bundle<br />
them into a block, sign the block and broadcast it to the network.<br />
They essentially are the block producers for the underlying<br />
consensus mechanism (see section 5.4).<br />
Release: stress-test/1.0-1-g96f3268 (2017-04-04)
3.2 BITSHARES COMMITTEE 3<br />
For each successfully constructed block, a witness is payed in<br />
shares that are taken from the limited reserves pool at a rate that<br />
is defined by the shareholders by means of approval voting.<br />
3.2 BitShares Committee<br />
Since Bitcoin struggled to reach a consensus about the size of<br />
their blocks, the people in the cryptocurrency space realized that<br />
the governance of a DAC should not be ignored. Hence, Bit-<br />
Shares offers a tools to reach on-chain consensus about business<br />
management decisions.<br />
The BitShares blockchain has a set of parameters available<br />
that are subject of shareholder approval. Shareholders can define<br />
their preferred set of parameters and thereby create a so called<br />
committee member or alternatively vote for an existing committee<br />
member. The BitShares committee consists of C active<br />
committee members.<br />
For each business parameter the protocol will calculate the<br />
difference between up- and down-votes (v pro − v con ) for each<br />
active committee member and then take the median of the top<br />
C active members:<br />
// Derive active C committee members<br />
for i : active committee members do<br />
member weight: w[i] ← v pro − v con<br />
end for<br />
members ← SORT(w)<br />
active ← members[0 → C]<br />
// For each Parameter: derive median of active members<br />
for parameter : parameters do<br />
p ← GETPARAMETERS(active, parameter)<br />
x = { sort(p[i])<br />
˜p =<br />
x[ C+1<br />
1<br />
2<br />
(<br />
2 ] C odd<br />
x[<br />
C<br />
2 ] + x[ C 2 + 1]) C even.<br />
parameter ← ˜p<br />
end for<br />
Since, C is a parameter as any other, the shareholders decide for<br />
the size of the committee.<br />
The BitShares ecosystem has a set of parameters available that<br />
are subject of shareholder approval. Initially, BitShares has the<br />
following blockchain parameters:<br />
fee structure:<br />
fess that have to be paid by customers for individual<br />
transactions<br />
block interval:<br />
i.e. block interval, max size of block/transaction<br />
expiration parameters:<br />
i.e. maximum expiration interval<br />
witness parameters:<br />
i.e. maximum amount of witnesses (block producers)<br />
committee parameters:<br />
i.e. maximum amount of committee members<br />
witness pay:<br />
payment for each witnesses per signed block<br />
worker budget:<br />
available budget available for budget items (e.g. development)<br />
Please note that the given set of parameters serves as an example<br />
and that the network’s parameters are subject to change over<br />
time.<br />
Additionally to defining the parameters any active witness can<br />
propose a protocol or business upgrade (i.e. hard fork) which can<br />
be voted on (or against) by shareholders. When the total votes for<br />
the hard fork are greater than the median witness weight w then<br />
the hard fork takes effect.<br />
3.3 BitShares Budget Items/Workers<br />
Thanks to the funds stored in the reserve pool, BitShares can<br />
offer to not only pay for its own development and protocol<br />
improvement but also support and encourage growth of an<br />
ecosystem.<br />
In order to be get paid by BitShares, a proposal containing<br />
(a) the date of work begin, (b) the date of work end, (c) a daily<br />
pay (denoted in BTS), (d) the worker’s name, and (e) an internet<br />
address. has to be publish on the blockchain and approved by<br />
shareholders. A worker can also choose on of the following<br />
properties:<br />
• vesting: pay to the worker’s account<br />
• refund: return the pay back to the reserve pool to be used for<br />
future projects<br />
• burn: destroys the pay thus reducing share supply, equivalent<br />
to share buy-back of a company stock.<br />
A blockchain parameter (defined by shareholders through the<br />
committee) defines the daily available budget. No more than that<br />
can be paid at any time to all so called workers combined.<br />
The daily budget is distributed as illustrated in fig. 1: (1) The<br />
available budget is taken out of reserves pool. (2) The budget<br />
items are sorted according to their approval rate (v pro − v con ) in<br />
a descending order. (3) Starting at the worker with the highest<br />
approval rate, the requested daily pay is payed until the daily<br />
budget is depleted. (4) The worker with the least approval rate<br />
that was paid may receive less than the requested pay<br />
Hence, in order to be successfully funded by the BitShares<br />
ecosystem, the shareholder approval for your budget item needs<br />
to be highly ranked.<br />
Since the payments for workers from the non-liquid reserve<br />
pool result in an increased supply of BTS, these payments are<br />
vesting over a period of time defined by shareholders.<br />
3.4 Proxy Voting<br />
Proxy Voting denotes the process of handing out ones voting<br />
power to someone else. This process can be reverted to reclaim<br />
ones voting power.<br />
The motivation behind proxy voting is to reduce voting apathy<br />
and allow active shareholders to react more quickly to business<br />
and security concerns. That way, misbehaving witnesses can be<br />
fired more rapidly.<br />
That is centralizing in some respects, but it’s controlled centralization<br />
in the sense that nothing can happen too quickly and<br />
Release: stress-test/1.0-1-g96f3268 (2017-04-04)
4<br />
Approval Rate<br />
Request and Received Funds<br />
vpro − vcon<br />
Requested Funds<br />
Payed Funds<br />
2 4 6 8 10 12 14 16 18 20 22 24 26 28 30<br />
Budget Item<br />
Figure 1: Illustration of budget item payments.<br />
In practice, a SmartCoin always has 100% or more of its value<br />
backed by means of a contract for difference (CFD) between two<br />
parties with BTS as collateral. What makes these CFDs unique<br />
is that they are free from counterparty risk. This is achievable by<br />
letting the network itself (implemented as a software protocol) be<br />
responsible for securing the collateral and performing (forced)<br />
settlements if required as is described in more detail in [5].<br />
Applications for SmartCoins are obvious: <strong>With</strong> the aforementioned<br />
properties, a bitUSD qualifies for regular and instant<br />
payments, for example with a smartphone or a modern browser<br />
application. In contrast, a bitGOLD (with one ounce of gold as<br />
underlying asset) would fit those people’s needs that see gold as<br />
long-term store of value. As long as an asset has a unique global<br />
price, a SmartCoin could track its value. This allows for even<br />
more sophisticated applications, such as tracking a stock market<br />
index, or the price of a liter of gasoline.<br />
if shareholders don’t like which way it is going, still have the<br />
ability to switch courses. Compared to classical crypto currencies<br />
(e.g. Bitcoin), this process is somewhat similar to pooled mining<br />
with the exception that every shareholder can participate and<br />
only voting power is handed over. Furthermore, this allows for<br />
independent non-profit oriented decisions because there is no<br />
profit variance but purely political influence.<br />
4 BitShares: A profitable DAC<br />
BitShares is a decentralized autonomous company, and as such<br />
offers products to to earn their shareholders a profit. As we have<br />
seen in the previous section, it also offers a way to pay for<br />
expense, such as development and administration but earns a<br />
profit by burnning (i.e. reducing supply). Of course, the company<br />
can only be profitable if the income exceeds the expenses. Thus,<br />
we will now discuss both in detail.<br />
4.1 The Products<br />
The BitShares DAC offers their private customers several products<br />
and in this paper we would like to briefly highlight some of<br />
them. Of course, all of these come with with the properties of<br />
cryptocurrencies, namely (a) global accessibility, (b) customizable<br />
anonymity, (c) industry-grade security, (d) freedom from<br />
counterparty-risk, (e) flexible account Control, (f) low transaction<br />
delays, and (g) world-wide decentralized network.<br />
Keep in mind that, as BitShares has the technical possibilities<br />
to upgrade itself with shareholder approval, new products and<br />
properties can be added in a timely manner.<br />
4.1.1 Price-stable SmartCoins<br />
The core product of BitShares is a class of assets referred<br />
to as Market-Pegged Assets (MPA), BitAssets, or SmartCoins<br />
and represent a crypto-token that has at least the value of the<br />
underlying asset. For instance, a bitUSD can always be sold for<br />
$1, either to a merchant at face-value, or to the network (by<br />
means of settlement of a contract) in return for BitShares’ core<br />
currency (BTS) worth $1.<br />
4.1.2 Customizable Assets<br />
In addition to market-pegged assets, the BitShares network also<br />
offers to register customizable assets on the public ledger. For<br />
instance, a BitShares customer may create the asset FREE and<br />
distribute them to friends for free. Another customer may want<br />
his company shares to be traded in the BitShares network. Yet<br />
another use-case would be event tickets that can be sold at a fixed<br />
price and allow the holder to enter a concert.<br />
Since the use-cases of these User-Issued Assets (UIA) are<br />
manifold and space is limited in this paper, we discuss them in<br />
depth in [5].<br />
4.1.3 Decentralized Exchange<br />
As we have seen in the previous section, the BitShares network<br />
offers to register different types of assets. It also allows for<br />
trading between almost 1 any two pairs in an instant, trust-less<br />
and secure manner by means of the BitShares Decentralized<br />
Exchange (DEX).<br />
In traditional trading, a clearing house is necessary because<br />
trades are made much faster than the cycle time for completing<br />
the underlying transaction. Since in BitShares trades between<br />
two parties are performed on a global scale in a decentralized<br />
network and no middlemen are required, there is no need for<br />
settlement or clearing delays. If a trade in the DEX executes, the<br />
bought asset instantly (T+0 [6]) appears in the customers wallet.<br />
In combinations with SmartCoins, a startup could easily perform<br />
a dollar-denominated crowd-funding without legal or tax<br />
implications due to the velocity of cryptocurrency tokens. Furthermore,<br />
as all order-books are shared on a global scale, the<br />
markets will become more efficient because no different prices<br />
existing on different locations on earth. Of course, the DEX is<br />
open 24/7 and does not apply any limits to customers. A more<br />
detailed discussion about the DEX can be found in a distinct<br />
paper [5].<br />
4.1.4 Flexible Identity Management<br />
In BitShares, each account is separated into<br />
1 The issuer of an asset may white-/or black-list trading partners.<br />
Release: stress-test/1.0-1-g96f3268 (2017-04-04)
4.2 REVENUE AND EXPENSES 5<br />
• Active Permission which has control over its funds and<br />
• Owner Permission which controls the account itself.<br />
Furthermore, BitShares uses authorities consisting of one or<br />
many entities that authorize an action, such as transfers, trades<br />
or account modifications. An authority consists of one or several<br />
pairs of an account name with a weight. In order to obtain a valid<br />
transaction, the sum of the weights from signing the parties has<br />
to exceed the threshold as defined in the permissions.<br />
Let’s discuss some examples to shed some light on the used<br />
terminology and the use-cases. We assume that a new account is<br />
created with it’s active permissions set as described below. Note<br />
that the same scheme also works for the owner permissions!<br />
A flat multi-signature scheme is composed of M entities of<br />
which N entities must sign in order for the transaction to be valid.<br />
Now, in BitShares, we have weights and a threshold instead of M<br />
and N. Still we can achieve the very same thing with even more<br />
flexibility as we will see now.<br />
Let’s assume, Alice, Bob, Charlie and Dennis have common<br />
funds. We want to be able to construct a valid transaction if only<br />
two of those agree. Hence a 2-of-4 (N-of-M) scheme can look<br />
as follows:<br />
Account<br />
Weight<br />
Alice 33%<br />
Bob 33%<br />
Charlie 33%<br />
Dennis 33%<br />
Threshold: 51%<br />
All four participants have a weight of 33% but the threshold<br />
is set to 51%. Hence only two out of the four need to agree<br />
to validate the transaction. Alternatively, to construct a 3-of-4<br />
scheme, we can either decrease the weights to 17 or increase the<br />
threshold to 99%.<br />
<strong>With</strong> the threshold and weights, we now have more flexibility<br />
over our funds, or more precisely, we have more control. For<br />
instance, we can have separate weights for different people. Let’s<br />
assume Alice wants to secure here funds against theft by a multisignature<br />
scheme but she does not want to hand over too much<br />
control to her friends. Hence, we create an authority similar to:<br />
Account<br />
Weight<br />
Alice 49%<br />
Bob 25%<br />
Charlie 25%<br />
Dennis 10%<br />
Threshold: 51%<br />
Now the funds can either be accessed by Alice and a single<br />
friend or by all three friends together.<br />
Let’s take a look at a simple multi-hierarchical corporate<br />
account setup. We are looking at a company that has a Chief<br />
of Financial Officer (CFO) and a some departments working for<br />
him, such as the Treasurer, Controller, Tax Manager, Accounting,<br />
etc. The company also has a CEO that wants to have spending<br />
privileges. Hence we construct an authority for the funds according<br />
to:<br />
Account<br />
Weight<br />
CEO.COMPANY 51%<br />
CFO.COMPANY 51%<br />
Threshold: 51%<br />
whereas CEO.COMPANY and CFO.COMPANY have their<br />
own authorities. For instance, the CFO.COMPANY account<br />
could look like:<br />
This scheme allows:<br />
CFO.COMPANY Weight<br />
Chief.COMPANY 51%<br />
Treasurer.COMPANY 33%<br />
Controller.COMPANY 33%<br />
Tax Manager.COMPANY 10%<br />
Accounting.COMPANY 10%<br />
Threshold: 51%<br />
• the CEO to spend funds<br />
• the Chief of Finance Officer to spend funds<br />
• Treasurer together with Controller to spend funds<br />
• Controller or Treasurer together with wither the Tax Manager<br />
or Accounting to spend funds.<br />
Hence, a try of arbitrary depth can be spanned in order to<br />
construct a flexible authority to reflect mostly any business usecase.<br />
4.1.5 Variable and Flexible Fees<br />
In the BitShares ecosystem every operation is assigned an individual<br />
fee that has to be payed in the core asset (BTS) the the<br />
end user. These fees are subject to change and are defined by the<br />
elected committee members. Thus each and every shareholder<br />
of the BitShares core asset (BTS) has a say as to what the<br />
fees should be. If shareholders can be convinced to reduce a<br />
certain fee and consensus is reached, the fee will be reduced<br />
automatically by the blockchain. This allows the ecosystem, to<br />
stay flexible and adept the price for the usage of its products over<br />
time.<br />
Since the network expects the fees to be payed on the the<br />
core asset (BTS) but many users may not want to hold any, the<br />
protocol allows to trade an arbitrary asset into BTS from the<br />
asset-specific *fee pool* at the *core exchange rate* which is<br />
defined by the issuer (or the witnesses in the case of a market<br />
pegged asset).<br />
4.2 Revenue and Expenses<br />
Revenue streams are essentially caused by fees that have to be<br />
payed when using the DACs products, such as market pegged<br />
assets, user-issued assets, or the decentralized exchange [5].<br />
These fees are variable, can be changed by shareholder approval<br />
and include (a) transfers, (b) order operations, (c) account operations,<br />
(d) asset operations, (e) witness creations (f) proposal<br />
operations (g) withdraw permission operations (h) committee<br />
member operations, (i) worker creation, and more.<br />
In contrast to bitcoin, where newly created coins in each block<br />
are distributed solely among countless miners that immensely<br />
Release: stress-test/1.0-1-g96f3268 (2017-04-04)
4.3 MEMBERSHIPS 6<br />
Figure 2: Cash flow of BitShares 2.0<br />
overpay for the network security [7], the BitShares ecosystem<br />
achieves a better security at lower costs by means of an adjustable<br />
number of approved and trusted witnesses in DPOS. Additionally,<br />
the BitShares ecosystem has the capability to pay for its<br />
own development through budget items. Both, the payment for<br />
witnesses, as well as the budget items are required to be approved<br />
by the shareholders.<br />
As an example, an entrepreneur may approach the shareholders<br />
and offer to launch a business in the BitShares space<br />
that would greatly benefit the ecosystem. If he succeeds and<br />
convinces the shareholders to vote for and not against his plan,<br />
he could get an initial funding by the DAC.<br />
Another use-case would be the improvement of the<br />
blockchain’s protocol. A developer could propose a change or<br />
extension of the existing software implementation and be payed<br />
by the DAC to do so (after shareholder approval). Hence, as<br />
long as the average shareholders acts rational, the BitShares<br />
blockchain can be seen as a self-funded but profitable business<br />
4.3 Memberships<br />
Accounts in BitShares are separated into three groups. We decided<br />
to give users the option to upgrade their accounts into a<br />
VIP-like status if they desire and profit from reduced fees and<br />
additional features.<br />
A regular account is a non-member.<br />
Lifetime Members get a percentage cashback on every transaction<br />
fee they pay and qualify to earn referral income (see below)<br />
from users they register with or refer to the network. A Lifetime<br />
membership is associated with a certain one-time fee that is<br />
defined by the committee and qualifies for reduced transaction<br />
fees.<br />
If a lifetime membership is too much you can still get the same<br />
cashback for the next year by becoming an annual subscriber for<br />
a smaller one-time fee which lasts for only one year and qualifies<br />
for reduced transactions fee during that time.<br />
4.4 Referral Program<br />
Every time an account you referred pays a transaction fee, that<br />
fee is divided among several different accounts. The network<br />
takes a cut, and the Lifetime Member who referred the account<br />
gets a cut.<br />
The registrar is the account that paid the transaction fee to<br />
register the account with the network. The registrar gets to decide<br />
how to divide the remaining fee between themselves and their<br />
own affiliate.<br />
Fees paid are only divided among the network, referrers, and<br />
registrars once every maintenance interval. The paid fees are<br />
divided among tow or three parties, depending on the parameter<br />
d that can be set by the registrar:<br />
total fee = network fee(20%)<br />
+ registrar(80% · (100% − d%)) (1)<br />
+ referrer(80% · (d%))<br />
Most fees are made available immediately, but fees over the<br />
vesting threshold (such as those paid to upgrade your membership<br />
or register a premium account name) must vest for some<br />
days as defined by the committee.<br />
Release: stress-test/1.0-1-g96f3268 (2017-04-04)
7<br />
5 Architecture of BitShares<br />
Before describing how BitShares can be used to secure financial<br />
freedom, we first discuss the technical specifications<br />
briefly. Among these is the public ledger (also referred to as the<br />
blockchain), the peer-to-peer network, the distributed consensus<br />
finding mechanism and the system parameters available to Bit-<br />
Shares.<br />
5.1 Public Ledger<br />
As in other crypto-currencies, the public ledger of BitShares<br />
is built and stored in a linked series of blocks, known as a<br />
blockchain.<br />
The ledger provides a permanent record of transactions that<br />
have taken place, and also establishes an order in which transactions<br />
have occurred. Hence, every content of the blockchain<br />
can be assigned an permanent and unique identifier in form of a<br />
scalar number.<br />
Every full node in the BitShares network stores a full copy of<br />
this blockchain and can verify its validity and the evaluate new<br />
blocks.<br />
Every block contains<br />
• a reference to the previous block,<br />
• a timestamp,<br />
• a hash of a secret,<br />
• the secret of the previous hash,<br />
• a set of transactions, and<br />
• a signature by the block producing authority<br />
As will be discussed in section 5.4, the consensus mechanism<br />
allows for synchronous block production with constant block<br />
confirmation times, e.g., one block every 5 s.<br />
Since the blocks mainly embrace customer transactions but<br />
has to perform time intensive tasks, or execute rare events from<br />
time to time, some actions such as reenumeration of blockchainbased<br />
votes and rare events such as newly registered block<br />
producers (witnesses) are carried out more rarely but still on a<br />
frequent so called maintenance interval.<br />
5.2 Irreversibility of Transactions<br />
Historically we have stated that a blockchain becomes irreversible<br />
after one round of block production with greater than<br />
51% participation. It turns out that this metric is too fuzzy<br />
because of noise in how witnesses are ordered. In an effort<br />
to provide stronger/absolute guarantees a new metric has been<br />
derived that determines the exact point at which a particular<br />
block becomes irreversible. The algorithm to define the metric<br />
goes as follows:<br />
Sort N witnesses by the last block number they signed, then<br />
take the highest block number that is lower than 66% of all other<br />
witnesses. This will indicate that said block has been confirmed<br />
by 66% of all witnesses and is clearly irreversible.<br />
This particular metric is dynamic and can respond to changes<br />
in the order of witnesses and is immune to situations where the<br />
network fragments into more than two pieces. In the event of a<br />
major disruption users are guaranteed that no block older than<br />
that number can ever be undone.<br />
If we had only 17 witnesses and 3 second block confirmation<br />
interval, then this will take an average of 34 seconds. If we had<br />
101 witnesses and 3 second blocks then this will take an average<br />
of 3.3 minutes for block to be irreversible,<br />
Having this metric is important to give everyone in the network<br />
peace of mind in the unlikely event that a software bug or<br />
network issue causes all witnesses to fall out of sync and gives a<br />
clear measure of when they are considered back in sync.<br />
Anyone accepting transactions as final prior to the most recent<br />
irreversible block is choosing to take some extra risk on their<br />
transaction.<br />
5.3 Low Latency Peer-to-Peer Network<br />
The peer-to-peer network distributes the full blockchain database<br />
across the world. It consists of public and private nodes as well as<br />
seed nodes that are used for initial connection to the peer-to-peer<br />
network. Anybody may connect to any known node and download<br />
the current global and unique state (i.e. the blockchain).<br />
Once a node is in sync with the peer-to-peer network it received<br />
and applies newly created blocks, and assists new network<br />
nodes by further distribution of the blockchain. Additionally, new<br />
blocks are broadcast to all connected nodes.<br />
Furthermore, network nodes receive transaction from participants<br />
and forward them to the rest of the network until they<br />
reach the witness that is in charge of constructing the next block.<br />
Hence, new transaction broadcasts do not necessarily need to<br />
reach all nodes.<br />
Building a low-latency network requires P2P nodes that have<br />
low-latency connections and a protocol designed to minimize<br />
latency. For the purpose of this document we will assume that<br />
two nodes are located on opposite sides of the globe with a ping<br />
round-trip time of 250 ms.<br />
In the Bitcoin network architecture, transactions and blocks<br />
were broadcast in a following manner: inventory messages notify<br />
peers of transactions and blocks, then peers fetch the transaction<br />
or block from one peer. After validating the item a node will<br />
broadcast an inventory message to its peers.<br />
Under this model it will take approximately 0.75 s for a peer to<br />
communicate a transaction or block to another peer even if their<br />
size was 0 and there was no processing overhead. This level of<br />
performance is unacceptable for a network attempting to produce<br />
one block every second.<br />
This prior protocol also sent every transaction twice: initial<br />
broadcast, and again as part of a block.<br />
To minimize latency each node needs to immediately broadcast<br />
the data it receives to its peers after validating it. Given<br />
the average transaction size is less than 100 bytes, it is almost<br />
as efficient to send the transaction as it is to send the notice<br />
(assuming a 20 byte transaction id).<br />
5.4 Distributed Consensus Mechanism<br />
Consensus is the mechanism by which a subset of people decide<br />
upon unitary rational action. The process of consensus decisionmaking<br />
allows for all participants to consent upon a resolution of<br />
action even if not the favored course of action for each individual<br />
participant. Bitcoin was the first system to integrate a fully<br />
Release: stress-test/1.0-1-g96f3268 (2017-04-04)
5.5 OPERATIONS 8<br />
decentralized consensus method with the modern technology of<br />
the internet and peer-to-peer networks in order to more efficiently<br />
facilitate the transfer of value through electronic communication.<br />
The proof-of-work structure that secures and maintains the Bitcoin<br />
network is one manner of organizing individuals who do<br />
not necessarily trust one another to act in the best interest of all<br />
participants of the network.<br />
It is of importance to distinguish a democratic voting process<br />
in which every citizen of a community has one and only one vote<br />
from a distributed consensus mechanism in crypto-currencies<br />
hand over voting power either in relation to hashing power (e.g.<br />
proof-of-work) or on a per stake basis (e.g. proof-of-stake). In<br />
both cases, those that invest in the required infrastructure to<br />
increase their voting percentage (i.e. by buying mining hardware<br />
or stake) act as shareholder in a distributed community.<br />
The BitShares community employs Delegated Proof-of-Stake<br />
(DPOS) in order to find efficient solutions to distributed consensus<br />
decision making. DPOS attempts to solve the problems of<br />
both Bitcoin’s traditional proof-of-work system, and the proofof-stake<br />
system of Peercoin and NXT by implementing a layer<br />
of technological democracy to offset the negative effects of centralization.<br />
For historical reasons, the technology is still called<br />
delegated proof-of-stake even though what have been delegates<br />
in BitShares 1.0 are now so called witnesses.<br />
In DPOS set of N witnesses (formerly known as delegates)<br />
sign the blocks and are voted on by those using the network<br />
with every transaction that gets made. By using a decentralized<br />
voting process, DPOS is by design more democratic than comparable<br />
systems. Rather than eliminating the need for trust all<br />
together, DPOS has safeguards in place the ensure that those<br />
trusted with signing blocks on behalf of the network are doing<br />
so correctly and without bias. A more detailed description about<br />
the distributed consensus mechanism as well as a discussion<br />
how blockchain forking is prevented during attacks is given in<br />
a separate paper [8].<br />
Additionally, each block signed must have a verification that<br />
the block before it was signed by a trusted node. DPOS eliminates<br />
the need to wait until a certain number of untrusted nodes<br />
have verified a transaction before it can be confirmed.<br />
This reduced need for confirmation produces an increase in<br />
speed of transaction times. By intentionally placing trust with<br />
the most trustworthy of potential block signers, as decided by<br />
the network, no artificial encumbrance need be imposed to slow<br />
down the block signing process. DPOS allows for many more<br />
transactions to be included in a block than either proof of work<br />
or proof of stake systems.<br />
In a delegated proof-of-stake system, centralization still occurs,<br />
but it is controlled. Unlike other methods of securing<br />
cryptocurrency networks, every client in a DPOS system has<br />
the ability to decide who is trusted rather than trust concentrating<br />
in the hands of those with the most resources. DPOS<br />
allows the network to reap some of the major advantages of<br />
centralization, while still maintaining some calculated measure<br />
of decentralization. Furthermore, once a witness has reached<br />
approval by shareholders, surpasses the threshold of the most<br />
N active witnesses, and, hence, is elected to actively participate<br />
in the block production procedure, its power is equivalent to all<br />
other active witnesses. This system is enforced by a fair election<br />
process where anyone could potentially become a delegated<br />
representative (witness) of the majority of users.<br />
Please note that DPOS has a recommended 1 − 2 block<br />
confirmation versus bitcoin’s 6 block recommendation. DPOS is<br />
much more resistant against forks for the following reasons:<br />
• When a fork is produced it is very likely that all witnesses<br />
have seen and processed your transaction and thus no alternative<br />
transactions can be broadcast and the next witness is<br />
almost certain to include your transaction. All witnesses are<br />
much more trusted than miners.<br />
• The probability of a fork after a block has been produced<br />
is very low (¡ 0.01%) where as Bitcoin has 25 orphans in<br />
the last 22 days (about 1 per day in Dec 3,2014) which<br />
translates into 0.7% of blocks are orphaned.<br />
• On normal operations, DPOS achieves a 100% witness<br />
participation rate and when we are less than that it is more<br />
often because a witness went offline and didn’t produce a<br />
block than because they produced a fork.<br />
• In BitShares 1.0 forks have almost always been resolved<br />
within 30 seconds.<br />
Assuming a 10 second block interval, <strong>Bitshares</strong> is mathematically<br />
over 70x less likely to orphan after 1 block than Bitcoin<br />
after 1 block (10 minutes). After 3 blocks (30 seconds) any<br />
random orphan will have been resolved and the probability of<br />
alternative chains is much lower than the 0.000001% of Bitcoin.<br />
By the time Bitcoin gets to .7% orphan probability, BitShares has<br />
60 blocks which would have a probability of being orphaned of<br />
less than 10 −120 .<br />
5.5 Operations<br />
Similar to most crypto-currencies, there is a set of predefined<br />
operations that can be performed on the blockchain. In contrast<br />
to Bitcoin, which uses a technique called script to describe operations<br />
that shall be performed in a programmatic way using OP<br />
codes, the BitShares network has a predefined (but extensible)<br />
set of operations that a user may perform.<br />
All operations end up on the blockchain eventually. Once they<br />
are validated and confirmed by a witness by being included into<br />
a block, they are executed and update the state of the blockchain<br />
accordingly.<br />
The release version of BitShares 2.0 comes with (a) transfer<br />
ops, (b) trading order ops, (c) account ops, (d) asset ops, (e) witness<br />
ops, (f) committee ops, (g) worker ops, and (h) vesting ops,<br />
However, since BitShares allows for shareholder approved, live<br />
protocol upgrades, the set of operations can be extended and<br />
modified.<br />
On the blockchain level, each operation is assigned an individual<br />
id with a custom set of parameters for performance and<br />
latency reasons.<br />
5.6 Transactions<br />
Having defined operations, we can now put these into a list<br />
of operations and construct a transaction. In addition to its<br />
operations, a transaction also consists of (a) an expiration date,<br />
(b) a reference block number, (c) a reference block prefix, (d) a<br />
Release: stress-test/1.0-1-g96f3268 (2017-04-04)
5.7 PROPOSED TRANSACTIONS 9<br />
set of extensions, and (e) a set of signatures to authorize each<br />
operation.<br />
Each node (including witnesses) verifies that all requires signatures<br />
to perform the given operations are present and valid<br />
prior to propagating the transactions to the rest of the network<br />
and hence to the witness node constructing the next block. If the<br />
transaction is included into a block it is considered finally valid<br />
or executed.<br />
5.7 Proposed Transactions<br />
Additionally, the Graphene technology allows users to propose a<br />
transaction which requires approval of multiple accounts in order<br />
to execute. These transactions are only partially valid and do not<br />
execute until they are completely valid.<br />
The user proposes a transaction, then signatory accounts add<br />
or remove their approvals from this operation. When a sufficient<br />
number of approvals have been granted, the operations in the<br />
proposal are used to create a virtual transaction which is subsequently<br />
evaluated. Even if the transaction fails, the proposal<br />
will be kept until the expiration time, at which point, if sufficient<br />
approval is granted, the transaction will be evaluated a final time.<br />
This allows transactions which will not execute successfully until<br />
a given time to still be executed through the proposal mechanism.<br />
The first time the proposed transaction succeeds, the proposal<br />
will be regarded as resolved, and all future updates will be<br />
invalid.<br />
The common use-case would be similar to so called multisignature<br />
transactions which must be signed by two parties.<br />
Classical crypto currencies had the issue that such proposed<br />
transaction had to be communicated on separated channels until<br />
all required signatures have been collected. <strong>With</strong> BitShares, it is<br />
no possible to propose a transaction on the blockchain and have<br />
the required signatures be added by the respective parties.<br />
The proposal system in combination with corporate accounts<br />
allows for arbitrarily complex or recursively nested authorities. If<br />
a recursive authority (i.e. an authority which requires approval of<br />
nested authorities on other accounts) is required for a proposal,<br />
then a second proposal can be used to grant the nested authority’s<br />
approval. That is, a second proposal can be created which, when<br />
sufficiently approved, adds the approval of a nested authority to<br />
the first proposal. This multiple-proposal scheme can be used to<br />
acquire approval for an arbitrarily deep authority tree.<br />
6 Discussion<br />
In general, BitShares has similarities and differences to most<br />
known crypto-currencies. As many others, BitShares is based<br />
on a blockchain that stores and propagates transactions, i.e. user<br />
operations. Since, with DPOS, computational resources are used<br />
solely for the purpose of transaction propagation and confirmation,<br />
rather than wasteful computational work, the block production<br />
interval has been reduced to a few seconds. Eventually, this<br />
improves the over-all profitability of the DAC.<br />
Additionally, we make use of named accounts that can be<br />
registered on the blockchain. Users no longer need to send money<br />
to an alphanumeric string that can be copied incorrectly. Rather,<br />
funds can be sent as easily as sending an email, and in the same<br />
fashion. Name registration allows for the identification of who<br />
transactions are are originating with with no need to manually<br />
create a contact account for a given address. Transactions may<br />
contain a memo field that allow users to describe the nature<br />
of the transaction or broadcast secure messages about the price<br />
of the current transaction fee. Since BitShares 2.0 implements<br />
confidential transaction, there is no longer a need for mixing or<br />
master nodes. Transactions can be more private iin BitShares<br />
than in Bitcoin, for example, with no additional work needed<br />
from the user.<br />
BitShares is a 100% proof-of-stake system. This means it<br />
is a lot more efficient (cost per security) than proof-of-work<br />
and therefore does not have to dilute stakeholders/coinholders<br />
(there is a 10% yearly dilution of Bitcoin-holders as per 2015<br />
with Bitcoin and lowering this dilution would mean to lower<br />
the security). Hence, the cost of securing the BitShares network<br />
is merely a fraction of all transaction fees accumulated by the<br />
network.<br />
The job of the block producers is simple: include as many valid<br />
transactions in your given block as possible and sign a single<br />
block. These Block producers compete for the most approval in<br />
order to be allowed to produce blocks. Shareholder votes are<br />
proportionate to the relative number of shares they own. The<br />
BitShares DAC is completely shareholder run. Now people can<br />
be hired by the blockchain. Where coins like Bitcoin dilute to pay<br />
for network security, BitShares takes these fees and directs them<br />
towards continual improvement of the network and community.<br />
This helps insure BitShares will stay competitive in its feature<br />
set. More details about the consensus scheme of BitShares will<br />
be made available in a separated whitepaper.<br />
Recalling the initial distribution of BTS, it seem convincing<br />
to assume that most alternative distributions are way more unfair<br />
and some disproportionately favor their respective core developers.<br />
Since BitShares is a self-funded DAC, it can pay for its future<br />
development autonomously by dilution, if shareholders reach an<br />
on-blockchain consensus by approval voting.<br />
Furthermore, it becomes clear from the descriptions that Bit-<br />
Shares is governed by its shareholders and the committee whose<br />
members have shareholder approval. This allows for flexible<br />
adjustment of blockchain parameters, such as transaction fees,<br />
block interval, and more, as well as protocol upgrades to include<br />
new features.<br />
Since the BitShares is a self-funded blockchain, that can pay<br />
its workers by protocol, a healthy competition for new improvements,<br />
upgrades and additional features can be expected.<br />
7 Conclusion<br />
The properties and features mentioned in this paper make it clear<br />
that the BitShares DAC is well-prepared for its own features.<br />
It was shown that, due to on-blockchain voting, a decentralized<br />
development and funding can be achieved. The consensus mechanism<br />
DPOS reaches a trade-off between efficiency and required<br />
trust while maintaining better decentralization than almost every<br />
other blockchain consensus scheme.<br />
Release: stress-test/1.0-1-g96f3268 (2017-04-04)
REFERENCES 10<br />
References<br />
[1] Daniel Larimer, “Creating a Fiat/Bitcoin Exchange without<br />
Fiat Deposits.” https://bitcointalk.org/index.php?topic=<br />
223747.0.<br />
[2] “DACPlay,” http://dacPLAY.org.<br />
[3] Adam Ernest, “Follow My Vote,” http://followmyvote.com.<br />
[4] Cédric Cobban, “Follow My Vote,” http://peertracks.com.<br />
[5] “BitShares 2.0: Financial Smart Contract Platform,” Bit-<br />
Shares <strong>Whitepaper</strong>s, 2015.<br />
[6] “The trade is the settlement,” http://t0.com/.<br />
[7] Daniel Larimer, “Overpaying for Security,” http:<br />
//letstalkbitcoin.com/is-bitcoin-overpaying-for-falsesecurity/#.Ui-p9WTFT7s.<br />
[8] “BitShares 2.0: Distributed Consensus,” BitShares <strong>Whitepaper</strong>s,<br />
2015.<br />
Release: stress-test/1.0-1-g96f3268 (2017-04-04)
BITSHARES 2.0: FINANCIAL SMART CONTRACT PLATFORM<br />
Fabian Schuh, Daniel Larimer<br />
Cryptonomex, Cryptonomex.com ∗<br />
Blacksburg (VA), USA<br />
{ fabian, dan }@cryptonomex.com<br />
Abstract—<br />
Ever since Satoshi Nakamoto released his whitepaper<br />
and corresponding software for bitcoin, the cryptocurrency<br />
ecosystem has continued to grow at a rapid pace. In the<br />
beginning, Bitcoin created a platform that anyone could use<br />
to transfer value across the internet without middlemen,<br />
banks or counterparty risk. However, once bitcoin’s basic<br />
blockchain consensus technology became established and stable,<br />
people began to discuss whether blockchain technology<br />
could also be applied to enable the trade of multiple assets<br />
without the need for a broker or centralized clearinghouse.<br />
BitShares has created such a technology, and has coined<br />
the term ”decentralized exchange” (DEX) to describe our<br />
Bitcoin 2.0 platform. Currently, it supports trade not only in<br />
digital assets, but also traditional financial instruments and<br />
securities on the blockchain. The two main tools we provide<br />
for the creation of these instruments, market pegged assets<br />
(MPA) and user-issued assets (UIA), are discussed in detail<br />
in this paper.<br />
1 Introduction<br />
In today’s world, crypto-currencies are unique because they<br />
are the only type of digital currency that does not represent a<br />
corresponding counterparty liability. Instead, they are fungible<br />
decentralized tokens, whose value is derived from the amount<br />
of practical utility (or potential future utility) perceived by the<br />
network of users that support and trade in them. Not surprisingly,<br />
most cryptocurrencies suffer from high levels of price volatility<br />
due to many complex factors, such as constantly shifting public<br />
perception and highly speculative and unregulated markets. Although<br />
professional traders tend to appreciate this volatility, so<br />
far it has hindered the widespread adoption of cryptocurrency as<br />
a practical payment solution.<br />
One approach to creating a price-stable asset would be for an<br />
issuer to accept deposits in return for a digital token as a claim<br />
receipt (an ”I Owe You”). <strong>With</strong> this approach, the token would<br />
trade in the market as having the same value as the underlying<br />
asset, minus any perceived credit risk associated with the issuer.<br />
While this approach may work well for settlements, it is far<br />
less secure as an instrument for long term savings. History has<br />
∗ This work was supported by Cryptonomex and honorable members of the<br />
bitsharestalk.org community.<br />
repeatedly proven that many issuers will eventually go bankrupt<br />
due to incompetence, government intervention or outright fraud.<br />
BitShares has developed an alternative approach to creating<br />
price stable digital assets by using a cryptocurrency as collateral<br />
in a contract for difference (CFD) [1]. <strong>With</strong> this approach,<br />
two parties take opposite sides of a trade, where one party is<br />
guaranteed price stability, and the other party is granted leverage.<br />
This works as long as sufficient collateral exists, and the contract<br />
can be settled by an honest 3rd party with a price feed<br />
BitShares is a counterparty-trust free platform for financial<br />
smart contracts which operates over the internet, and offers a<br />
set of financial instruments that includes CFDs. These contracts<br />
are derivative instruments, and as such they fall under the wider<br />
definition of financial instruments. Financial instruments can be<br />
defined as tradable assets of any kind, including cash, proof of<br />
ownership receipts, or a contractual right to receive or deliver<br />
an underlying instrument, commodity, option, etc. Additionally,<br />
several other digital financial instrument tools are currently<br />
available on BitShares, such as Market Pegged Assets (MPA)<br />
or “SmartCoins” which represent a derivative with fiat currency,<br />
gold, or even other cryptocurrencies as the underlying asset.<br />
These SmartCoins derive their value from contracts based on the<br />
performance of the BitShares base token (BTS). Smart coins will<br />
be presented in detail in section 2.<br />
The BitShares platform also contains an flexible feature called<br />
“user-issued assets” (UIA) which will help facilitate a wide<br />
range of profitable business models based around certain types<br />
of services. A UIA is a type of custom token registered on the<br />
platform, which users can hold and trade within certain restrictions.<br />
The creator of such an asset can publicly name, describe,<br />
and distribute its tokens, and can specify custom requirements<br />
such as an approved whitelist of accounts permitted to hold<br />
the tokens, or the associated trading and transfer fees. These<br />
tokens allow for diverse use cases such as ownership tracking,<br />
crowd fundraising, IOUs, coupons, and many more that will be<br />
discussed in section 3.<br />
In order to trade financial instruments, BitShares provides a<br />
high-performance decentralized exchange (DEX), with all the<br />
features expected of a professional trading platform (see section<br />
4). Any two assets that are registered on the blockchain<br />
(MPA or UIA) may be traded against each other at any time.<br />
Orders can be settled almost instantly at speeds of up to 100,000<br />
transactions per second. <strong>With</strong> this kind of performance on a<br />
decentralized exchange, there is no longer a need for traders to<br />
expose their funds to the risks of centralized exchanges.<br />
Release: financial-platform/1.0-rc1-4-g23fc8ea (2015-11-12)
2<br />
In this paper we will discuss the financial instruments available<br />
in the BitShares network as well as the DEX. Before continuing,<br />
we recommend that you read through the basic technological<br />
components of BitShares in the other white papers [2] (more<br />
papers to be published shortly).<br />
2 Market Pegged Assets (MPA)<br />
A cryptocurrency that has the properties and advantages of Bitcoin,<br />
but is also capable of maintaining price parity with a globally<br />
adopted currency (e.g. U.S. dollar), would have incredible<br />
high utility for convenient and censorship-resistant commerce.<br />
This has been achieved by BitShares’ market pegged assets<br />
(MPA), a new type of freely traded digital asset whose function<br />
has been designed to track the value of a underlying conventional<br />
asset by means of contracts for difference (CFD).<br />
A SmartCoin (synonym for MPA) is a cryptocurrency that<br />
always has 100% or more of its value backed by the BitShares<br />
core currency (BTS), to which they can be converted at any time,<br />
as collateral in a CFD.<br />
What makes MPAs unique is that they are free from counterparty<br />
risk even though they resemble a CFD backed by collateral.<br />
This is achieved by allowing the network itself (implemented as<br />
a software protocol) to be responsible for securing the collateral<br />
and performing settlements. This will be described in greater<br />
detail below.<br />
We will present SmartCoins as a viable open source alternative<br />
to the slow, restrictive, and expensive “legacy” banking<br />
system. SmartCoins that have price parity with a commonly<br />
used currency will enable merchant adoption with ease and<br />
efficiency. Also, they will reduce the need to calculate capital<br />
gains and losses on volatile assets to determine tax liability.<br />
In short, BitShares is bringing publicly auditable open source<br />
banking to anyone with access to the internet. MPAs allow savers<br />
and spenders to choose their preferred asset type, which brings<br />
flexibility and ease of use to the open source banking experience.<br />
The subsequent paragraphs will explain how market pegged<br />
assets achieve price parity while minimizing risk to their holders.<br />
2.1 Price Stability<br />
Ever since the bitcoin blockchain initiated the age of decentralized<br />
public ledgers, economists and computer scientists have<br />
attempted to achieve a stable or price pegged cryptocurrency.<br />
The following two subsections will discuss our discoveries about<br />
the true nature of stable or pegged currency and explain how<br />
BitShares has solved this complex issue.<br />
2.1.1 Definition of Price Stability<br />
Before we discuss how BitShares achieves price stability, we first<br />
need to define what properties make a currency stable.<br />
In the U.S. for instance, the Federal Reserve (FED) has a<br />
mandate of stable prices and it is almost universally accepted by<br />
the market that this is a good mandate. The same holds true for<br />
the Euro, with its stability being achieved through the European<br />
Central Bank (ECB). Almost every country applies a similar<br />
methods to gain control over prices via monetary policies like<br />
quantitative easing and fixing of the interest rates for commercial<br />
banks that borrow money from the central bank.<br />
As a very basic example, imagine that a central bank has<br />
managed to keep prices stable through their monetary policy with<br />
0% price inflation for 20 years. Now let’s assume that during this<br />
same 20 years the advances in robotics and automation resulted<br />
in a 3x increase in efficiency and thus there are now 3x as much<br />
food, cars, phones, houses, etc. For the sake of this example<br />
we will assume the population is the same and everyone has<br />
the same amount of money in the bank. You would normally<br />
expect that everything would be 1/3 the price and that everyone<br />
would be able to afford 3x their prior lifestyle. However, this<br />
is unfortunately not the case. Because of constant intervention<br />
by the central banks, they have managed to also increase the<br />
money supply by 3x. The newly created money is then lent to<br />
the commercial banks which then lend it again to the people at a<br />
profit.<br />
Since this monetary inflation results in a sustained increase<br />
in the general level of prices, it is equivalent to a decline in<br />
the purchasing power of money. Hence, a dollar buys less and<br />
less over time. As a result, we see the dollar hast lost 99% of<br />
its purchasing power since the FED was founded in 1913 (see<br />
fig. 1).<br />
Billions of Dollars<br />
4,000<br />
3,000<br />
2,000<br />
1,000<br />
0<br />
1920<br />
1930<br />
1940<br />
1950<br />
1960<br />
Figure 1: St. Louis Adjusted Monetary Base [3]<br />
Of course, the goal of this paper is not to propose a replacement<br />
for central banks or their monetary policies, but we do wish<br />
to clarify some terminology, particularly as it relates to other<br />
“stable” cryptocurrencies. Other projects in the cryptocurrency<br />
space have attempted to provide an alternative currency that will<br />
ultimately achieve a similar mandate as the central banks, leaving<br />
the profits in the hands of only few institutional entities. Bit-<br />
Shares market-pegged assets will not result in the centralization<br />
of power and control in this way.<br />
Let us discuss the example above. Since the centralized bank<br />
policies have resulted in a steady decrease in purchasing power<br />
over time, we notice that price stability does not seem very important<br />
to them. Eventually, the ideal goal would be to achieve a<br />
currency with a long term stable purchasing power. However, for<br />
now we must be content to achieve relative stability by pegging<br />
SmartCoins to the dollar or euro or gold, etc. To summarize, what<br />
we want to achieve is:<br />
Year<br />
• a predictable price with reduced volatility<br />
1970<br />
1980<br />
1990<br />
2000<br />
2010<br />
2015<br />
Release: financial-platform/1.0-rc1-4-g23fc8ea (2015-11-12)
2.2 PRICE FEEDS 3<br />
• a somewhat reliable ability to predict the future value of a<br />
token, and<br />
• a unit of account that doesn’t have any meaningful capital<br />
gains or losses for tax purposes.<br />
Hence for us, price “stability” means price predictability<br />
within some tolerance level. In the case of the U.S. dollar, a willingness<br />
to accept a yearly loss in purchasing power via monetary<br />
policies demonstrates that predictability is more important than<br />
stability [4].<br />
Alternatively, BitShares offers a decentralized solution to implement<br />
the Consumer Price Index (CPI) to peg to the changes in<br />
the price of a market basket of goods and services purchased by<br />
regular households. This is another way BitShares users can hold<br />
and trade a stable crypto token that will help them retain their<br />
purchasing power.<br />
2.1.2 BitAssets 1.0: Historical Lessons<br />
The first iteration of the BitShares bitAsset engine evolved for<br />
over 9 months as we observed how market participants reacted<br />
to various rules. We noticed that liquidity is critical to bring<br />
confidence in the value of the token, and that a system with<br />
unbalanced rules will tend to bias the price in one direction or<br />
the other.<br />
Early on, BitUSD (BitShares SmartCoin pegged to the U.S.<br />
dollar) was driven down to $0.85 as demand for shorting outstripped<br />
demand for BitUSD and shorts were not forced to cover.<br />
Then, after implementing a 30 day forced covering rule, the price<br />
stabilized around $0.98 to $1.00. Later, as the cryptocurrency<br />
bear market progressed, BitUSD was trading at $1.05 or more<br />
because everyone was scared to use leverage and those that had<br />
open positions looked to cover their position while those who<br />
held BitUSD were not looking to sell. Over the course of these<br />
past 9 months, we observed the dynamics of 3 different markets<br />
and thus had the opportunity to refine our understanding of the<br />
the behavior of market participants and improve the protocol<br />
accordingly.<br />
While we saw that the idea of a market pegged crypto token<br />
was generally well accepted in the marketplace, we were not<br />
yet satisfied as that the system had been perfected. For that<br />
reason, we improved the BitAssets engine for the BitShares 2.0<br />
protocol.<br />
2.1.3 BitAssets 2.0: Evolving a Stable<br />
Crypto Currency<br />
For BitUSD to be accepted as being equal to $1.00 for the<br />
purposes of setting prices, it only needs to maintain a floor of<br />
$1.00. If it can maintain a floor of $1.00, then merchants can<br />
accept it and know their margins are safe and that they are not<br />
exposed to currency risk. In order to enable a guaranteed floor,<br />
all BitUSD can be force liquidated at a trustworthy price feed 1 .<br />
Since this rule is present, those who create the BitUSD must<br />
sell it at a price that properly accounts for this risk of forced<br />
settlement. This means that at almost all times, new BitUSD<br />
1 Price feeds are published by witnesses that have shareholder approval. See section<br />
2.2.<br />
will only enter circulation when there is a buyer willing to pay a<br />
premium for a guaranteed floor.<br />
As we will see, since USD holders can initiate settlement,<br />
there is no need for artificial forced covering every 30 days. This<br />
relieves shorts of risk, helps increase short demand, and keeps<br />
the price of BitUSD near the floor.<br />
2.2 Price Feeds<br />
The blockchain needs to be aware of the external price of BTS<br />
in order for settlements to convert SmartCoins into the core asset<br />
(BTS) at a fair price.<br />
In BitShares, this is achieved by means of a set of N trusted<br />
witnesses. These witnesses have to be elected by the corresponding<br />
BitShares shareholders (e.g. holders of BTS) and can be<br />
constantly reviewed as all prices are put on the blockchain in a<br />
public manner by means of transactions of a certain type. Hence,<br />
misbehaving witnesses can be identified, “fired” and lose their<br />
reputation of shareholders.<br />
Additionally, to prevent manipulation of the price feed, N<br />
witnesses have to be elected that can all produce their prices<br />
independently. Having a set of N prices p i , 1 < i < N for an<br />
arbitrary MPA on the blockchain, the protocol obtains a single<br />
price ˜p by the use of the median according to:<br />
x = sort(p[i]) (1)<br />
{<br />
x[ N+1<br />
˜p = (<br />
2 ] N odd<br />
1<br />
2 x[<br />
N<br />
2 ] + x[ N 2 + 1]) (2)<br />
N even.<br />
Hence, the price is resistant against misbehaving witnesses in<br />
that only a majority of price publishers can manipulate the<br />
outcome of the median. In practice, any unintentional feed error<br />
is thus balanced around the true price.<br />
Obviously, the shareholders are required to constantly monitor<br />
the published prices of their witnesses and should make a public<br />
note about any discrepancies. This is similar to traditional quality<br />
management for the Smart Coin products (e.g. bitUSD) and Bit-<br />
Shares system can offer a paid position to perform this service.<br />
2.2.1 Price Manipulation<br />
There is always concern of price manipulation. Someone with<br />
a large amount of money on both sides of a trade can use their<br />
funds to manipulate the markets and thus the price feed. If the<br />
amount of money they lose manipulating the markets is less<br />
than the amount of money they can gain by manipulating the<br />
price feed, then it will be profitable to manipulate the market<br />
at the expense of either the BitUSD longs or the shorts. A low<br />
collateralized short that sees a large force or global settlement<br />
order requested can attempt to manipulate the markets and thus<br />
the feed against the BitUSD holder.<br />
The risk of price manipulation should be priced into the<br />
premium on BitUSD charged by the shorts, and thus should<br />
already be priced into the market. If price manipulation became a<br />
serious problem that caused very high premiums, then it could be<br />
addressed by the price feed producers, who can adopt a moving<br />
average over wider time windows to increase the difficulty of<br />
Release: financial-platform/1.0-rc1-4-g23fc8ea (2015-11-12)
2.3 ISSUANCE AND SUPPLY OF COLLATERALIZED SMARTCOINS 4<br />
short-term manipulation. A variety of algorithms could be used<br />
to estimate a fair price 2 that keeps BitUSD valued at least $1.00.<br />
In practice, a feed producer can observe the BitUSD:USD<br />
market as an indicator on which way to adjust the feed. Generally<br />
speaking, the strategy that the feed producers adopt for<br />
controlling the feed should be public knowledge, because the<br />
shorts will ultimately rely on it. For the feed producers to change<br />
strategies in unpredictable ways could cause losses to both longs<br />
and shorts. Fortunately, it is assumed that shareholders primarily<br />
approve complying feed producers and quickly fire misbehaving<br />
feed providers.<br />
2.3 Issuance and Supply of Collateralized<br />
Smartcoins<br />
A BitShares MPA can be viewed as a contract between an asset<br />
buyer seeking price stability and a short seller seeking greater<br />
exposure to BTS price movement. The open source BitShares<br />
software protocol implements a decentralized marketplace for<br />
MPA where all transactions are recorded on the shared block<br />
chain ledger and the software enforces the market rules. This<br />
block chain based marketplace is referred to as the decentralized<br />
exchange or internal market (c.f., section 4) to distinguish from<br />
external markets such as websites that facilitate the exchange of<br />
government issued currencies with cryptocurrency.<br />
SmartCoins are tokens of a particular MPA (e.g. bitUSD).<br />
They use the concept of a contract for difference, and make the<br />
long side fungible. For the purpose of this discussion, we will<br />
assume that the long side of the contract is BitUSD and that the<br />
backing collateral is BTS (the BitShares core asset).<br />
In practice, bitUSD are created on the BitShares blockchain<br />
when a BTS holder asks the network for them by handing over<br />
collateral to the network, essentially locking them in a contract<br />
for difference (c.f., 1) in fig. 2).<br />
external<br />
exchanges<br />
BTS/USD<br />
2. obtain<br />
bitUSD<br />
CFD<br />
short position<br />
1. put<br />
collateral<br />
3. sell<br />
bitUSD<br />
long position<br />
Figure 2: Illustration of external price discovery and a “short<br />
sell” to seek greater exposure for BTS price<br />
movements.<br />
The collateral is only returned to the short seller when the<br />
corresponding amount of the asset agreed in the contract is<br />
handed over to the BitShares network again. The protocol will<br />
then effectively destroy these tokens and fulfill the contract. This<br />
is referred to as covering a short. At the moment of creation,<br />
the position of the shorter has not changed at all because he can<br />
directly cover his own short position using the bitUSD to gain<br />
back his BTS used as collateral.<br />
If the short seller has sold the SmartCoins he has created, then<br />
he would be required to purchase them back from the market<br />
2 “fair” for honest market participants.<br />
before closing his short position. Meanwhile, if the value of<br />
the collateral relative to the current price of the market pegged<br />
asset falls below a certain margin of safety, the assets can be<br />
automatically (i.e. initiated by the protocol itself) repurchased<br />
from the market before the collateral becomes insufficient.<br />
These rules create systemic demand for market pegged assets<br />
while allowing them to remain fungible. To protect your contract<br />
against margin calls (automated, network initiated force<br />
settlement of your contract at the price feed), you should at least<br />
maintain the so called maintenance collateral level at all times.<br />
Hence, the collateral only needs to be high enough to cover any<br />
slippage as a result of a short squeeze.<br />
In summary, the following set of market rules apply to all<br />
market pegged assets (for the sake of simplicity, we here focus<br />
on the MPA bitUSD):<br />
• Anyone with BitUSD can settle their position within an<br />
interval 3 at the settlement price (identical to the feed price).<br />
• In this case, the least collateralized short positions would be<br />
margin called and their collateral would be used to settle the<br />
position.<br />
• The price feed is the median of many sources that are<br />
updated at least once per hour.<br />
• Short positions never expire, except by hitting the maintenance<br />
collateral limit, or being force-settled as the least<br />
collateralized at the time of forced settlement (see point 2).<br />
• In the event that the least-collateralized short position lacks<br />
enough collateral to cover at the price feed, then all BitUSD<br />
positions are automatically force settled at the price of the<br />
least collateralized short (black swan event, see section 2.5).<br />
These simple rules enable a price floor of $1.00 for 1.00<br />
BitUSD. A simple metric for testing the validity of our claim<br />
is to demonstrate that, if you can find someone willing to sell<br />
1.00 BitUSD for $1.00, that it would be the cheapest option for<br />
buying BTS. This means that 100% of the buying demand for<br />
BTS would be available to give liquidity to BitUSD holders as a<br />
priority over BTS holders.<br />
2.4 Perspectives of Participants<br />
While the rules are simple, the consequences are less obvious.<br />
Let’s analyze this from the perspective of the various players.<br />
2.4.1 The Short Position<br />
When deciding a price at which to enter a short order, a trader<br />
must consider the risk of being force settled. In this case, no<br />
trader will attempt to short at or below the price feed, because<br />
they could be forced to settle at the price feed. In fact, a smart<br />
trader would allow enough of a spread to account for the risk<br />
of being forced to settle at a feed price that was off by a small<br />
amount. Since feed errors are equally balanced between being in<br />
the favor of the short and in the favor of the long (c.f. section 2.2)<br />
this leaves only the risk of being forced out of their position at an<br />
inopportune time.<br />
3 defined by the shareholder approval<br />
Release: financial-platform/1.0-rc1-4-g23fc8ea (2015-11-12)
2.5 UNDERCOLLATERALIZATION AND BLACK SWANS EVENTS 5<br />
A short can minimize their exposure to the feed by providing<br />
enough collateral to keep far above the least collateralized positions,<br />
and thus stay very unlikely to be forced to settle at the feed<br />
or at an inopportune time.<br />
In practice, the only way new SmartCoins enter circulation<br />
is if there is someone willing to pay enough of a premium to<br />
convince a short to provide guaranteed liquidity at the price feed<br />
on demand, while also covering the cost of exchange rate risk.<br />
This premium will be higher for the backing cryptocurrency in a<br />
bear market, and will be lower in a bull market.<br />
Someone who is short has only one way to exit their position:<br />
by buying smartcoins off the market. This means that a short<br />
must also factor in the risk that the premium may change. If a<br />
short position is entered in a bull market with a 0.1% premium, it<br />
may be forced to exit during a bear market with a 5% premium.<br />
In this event a short position is exposed to both exchange rate of<br />
the dollar vs. BTS and the premium risk. On the other hand, a<br />
short entered during a bear market with a 5% premium may get<br />
to cover during a bull market with a 0.1% premium.<br />
For all intents and purposes, the premium is expected to move<br />
in the same direction as the price, and thus speculators who only<br />
care about relative price changes can ignore the premium.<br />
2.4.2 The Long Position<br />
The very first buyer of BitUSD will have to pay the lowest<br />
premium set by the shorters. For the sake of discussion, let’s<br />
assume the first BitUSD was created in a bear market and cost<br />
$1.05 to create. The holder of that BitUSD has two options:<br />
sell it on the market for $1.04, or request forced settlement for<br />
$1.00. Clearly, the forced settlement option would only be used<br />
in situations where there was a decrease in total demand for<br />
BitUSD and there were no offers to buy it above $1.00.<br />
As a trader only looking to trade back and forth between<br />
BitUSD and BTS, this premium doesn’t matter. Such a trader<br />
is exposed to volatility in the premium, but that risk is limited to<br />
$0.05 in this example. In practice, the premium is expected to be<br />
relatively stable and predictable.<br />
2.4.3 The Customer’s Perspective<br />
Customers use BitUSD because it provides them the convenience<br />
and freedom of a cryptocurrency, and has lower transfer fees<br />
compared to most other payment platforms besides being significantly<br />
more convenient than fiat.<br />
A customer looking to buy goods and services with BitUSD<br />
finds himself paying a premium to acquire BitUSD from the<br />
market. This means that customers will prefer merchants that<br />
offer a discount equal to the premium paid. On the other hand,<br />
the premium is a wash for a customer that earned BitUSD at a<br />
nominal value of $1.00.<br />
In fact, the only people to whom the premium matters are those<br />
who are looking to enter or exit the ecosystem. Once a customer<br />
or merchant is within the ecosystem, it is easy to simply trade<br />
BitUSD at parity, even if it is theoretically worth slightly more<br />
outside the ecosystem.<br />
Of course, merchants and customers are free to negotiate the<br />
best way to split the premium, and the free market will take care<br />
of the rest. In the meantime, all participants can rest assured that<br />
BitUSD is always worth at least $1, and can consider the premium<br />
for entering the ecosystem as a one-time fee comparable<br />
to fees required for the exchange of foreign currencies.<br />
2.4.4 The Merchant’s Perspective<br />
A merchant wants to be able to price merchandise in BitUSD,<br />
and obtain real USD in their bank account, in a reasonable time,<br />
with minimal risk. In this case, a merchant would place BitUSD<br />
on the market at $1 per BitUSD. As discussed, BTS buyers are<br />
looking for the opportunity to buy BitUSD at that price.<br />
A smart merchant might recognize that 1 BitUSD can actually<br />
fetch $1 plus a variable premium, and start preferring that<br />
customers pay them in BitUSD at face value. An even smarter<br />
merchant might offer a discount to customers that pay in BitUSD.<br />
In any case, merchants have a financial incentive to advertise<br />
BitUSD as the preferred payment mechanism, because they<br />
know that $1.00 is the lower bound on what BitUSD is worth.<br />
2.4.5 BTS Shareholders and Investors<br />
A buyer with dollars, looking to buy BTS, knows that 1 BitUSD<br />
can be used to buy $1 worth of BTS (plus the current premium).<br />
He also knows that this premium can never be negative, because<br />
of the option to force-settle at the price feed. In this situation, he<br />
can know with certainty that if he can convince someone with<br />
BitUSD to sell for $1.00, he can buy more BTS than if he simply<br />
buys BTS with his dollars directly. The higher the premium, the<br />
more incentive exists to buy BitUSD for $1.00.<br />
This means that, in a BTS bear market, the BitUSD price gives<br />
the highest premium of the BTS price, and BitUSD becomes the<br />
easiest to sell. In practice, the BitUSD:USD market will reflect<br />
the premium, and traders will usually be unable to find anyone<br />
willing to sell for exactly $1.00.<br />
If a buyer is looking to purchase a large quantity of BTS<br />
without moving the price, he can start by buying up BitUSD with<br />
dollars. This will slowly raise the BitUSD:USD price, which is a<br />
signal to other market participants. A careful buyer might be able<br />
to avoid signaling the market. Then, after acquiring the position<br />
in BitUSD, the buyer can request a global settlement and get the<br />
price feed on the entire purchase.<br />
Because all positions and trades are visible on the blockchain,<br />
all of this trading activity can be factored into the price, minimizing<br />
any potential profits to be made by attempted manipulation.<br />
2.5 Undercollateralization and Black Swans<br />
Events<br />
All guarantees of SmartCoins are subject to the caveat that a<br />
SmartCoin can never be worth more than the collateral backing<br />
the least-collateralized short position. All collateral above this<br />
maintenance collateral limit is effectively meaningless when it<br />
comes to enforcing the “peg”. In normal market conditions, the<br />
value of the collateral is always more than sufficient, but, from<br />
time to time, markets can rapidly revalue the collateral.<br />
If this revaluation happens faster than the short positions can<br />
be forced to cover, then all SmartCoins are liquidated at the<br />
Release: financial-platform/1.0-rc1-4-g23fc8ea (2015-11-12)
2.6 RISKS 6<br />
exchange rate of the least collateralized short position. This is<br />
called a black swan event since the least collateralized position<br />
is unable to buy enough BitUSD to cover. At this point, all positions<br />
are automatically force settled and any additional collateral<br />
maintained by the shorts is returned to them. This is similar to an<br />
insolvent bank converting its deposits to equity.<br />
2.6 Risks<br />
The current implementation of market pegged assets in the Bit-<br />
Shares system is designed to minimize risk of loss to SmartCoin<br />
holders. The collateral requirements and margin triggers were<br />
chosen conservatively to protect the holders of market pegged<br />
assets from volatility of the underlying collateral. Control over<br />
the price feed is distributed among N separately elected feed<br />
producers who compile information from multiple exchange<br />
sources.<br />
Despite such precautions, it is important to carefully explore<br />
risks of using the system. Risks can be broadly categorized as<br />
value risk, counterparty risk, or systemic risk.<br />
2.6.1 Collateral Risk<br />
Market pegged assets maintain their price parity due to being<br />
backed by collateral that has an established real world value.<br />
When the value of the collateral falls, the system is designed to<br />
react by driving the internal asset exchange to match the new real<br />
world exchange rate and trigger force settlements (also known as<br />
margin calls) if necessary.<br />
However, there exists a possibility that the underlying collateral<br />
(BTS) drops in value so quickly the market pegged assets<br />
become under-collateralized. Often termed a black swan event<br />
(c.f., section 2.5), a sudden crash of BTS value could prevent the<br />
system from adjusting in time. In this event, the full amount of<br />
collateral is no longer sufficient to purchase the market pegged<br />
asset back at the new real exchange rate. In such an event,<br />
assets may settle at the price fees and are converted back into<br />
the underlying collateral (BTS). This may expose customers at<br />
the volatility risk of BTS. Under normal conditions, short term<br />
market movements, spreads, and fees charged by exchanges may<br />
also affect the potential cost of conversion into and out of market<br />
pegged assets.<br />
2.6.2 Counterparty Risk<br />
Unlike many attempts to create a digital asset that tracks the<br />
dollar, market pegged asset are not an “I owe you” issued by any<br />
entity. For this reason, it does not rely on a specific counterparty<br />
to honor its value (unless you choose to view the software<br />
protocol itself as an independent “counterparty” entity).<br />
Although manipulation risk occurs in any market, it is minimized<br />
by the open source and auditable nature of the BitShares<br />
system and carefully considered market rules. MPAs stored on<br />
a centralized exchange become IOUs and are subject to counter<br />
party risk [5]. This risk is not a property of the MPA themselves.<br />
We recommend that users never deposit their tokens on an<br />
exchange and instead only use gateways that issue their IOUs<br />
onto the BitShares network. This way you can trade your BitUSD<br />
against gateway IOUs without exposing your BitUSD to counter<br />
party risk while in the order book (more details in section 4.3.1).<br />
2.6.3 Systemic Risk<br />
Systemic risk is a catch-all for other risks required to utilize the<br />
system. The primary risk lies with individuals being responsible<br />
for protecting the cryptographic private keys that sign transactions<br />
proving ownership of assets. These keys must be protected<br />
from theft or loss. This risk can be greatly reduced and virtually<br />
eliminated by following best practices.<br />
Systemic risk also includes the possibility of an overlooked<br />
fatal flaw in the open source software or the possibility of<br />
large scale failure of global network infrastructure. While some<br />
risk components should drastically reduce over time, such as<br />
implementation bugs and computational bottlenecks, others are<br />
constant and difficult to predict, such as politics (i.e. legislation,<br />
regulations, etc.) or natural catastrophes that may result in partial<br />
or global internet outages.<br />
2.7 Privatized SmartCoins<br />
Alternatively to regular MPA like the bitUSD, BitShares also offers<br />
entrepreneurs an opportunity to create their own SmartCoins<br />
with custom parameters and a distinct set of price feed producers.<br />
Privatized SmartCoin managers can experiment with different<br />
parameters such as collateral requirements, price feeds, force<br />
settlement delays and forced settlement fees (see section 3.2.7).<br />
They also earn the trading fees from transactions the issued<br />
asset is involved in, and therefore have a financial incentive to<br />
market and promote it on the network. The entrepreneur who<br />
can discover and market the best set of parameters can earn a<br />
significant profit. The set of parameters that can be tweaked by<br />
entrepreneurs is broad enough that SmartCoins can be used to<br />
implement a fully functional prediction market with a guaranteed<br />
global settlement at a fair price, and no forced settlement before<br />
the resolution date.<br />
Some entrepreneurs may want to experiment with SmartCoins<br />
that always trade at exactly $1.00 rather than strictly more than<br />
$1.00. They can do this by manipulating the forced settlement fee<br />
continuously such that the average trading price stays at about<br />
$1.00. By default, BitShares prefers fees set by the market, and<br />
thus opts to let the price float above $1.00, rather than fixing the<br />
price by directly manipulating the forced settlement fee.<br />
3 User-Issued Assets (UIA)<br />
In addition to the aforementioned market pegged assets, Bit-<br />
Shares allows individuals and companies to create and issue their<br />
own tokens for anything they can imagine. The potential use<br />
cases for so called user-issued assets (UIA) are innumerable. One<br />
example would be for UIAs to be used as simple event tickets<br />
deposited on the customer’s mobile phone to pass the entrance of<br />
a concert. On the other hand, they can be used for crowd funding,<br />
ownership tracking or even to sell equity of a company in form<br />
of stock.<br />
Obviously, the regulations that apply to each kind of token<br />
vary widely and are often different in every jurisdiction. Hence,<br />
Release: financial-platform/1.0-rc1-4-g23fc8ea (2015-11-12)
3.1 DEPOSIT RECEIPTS 7<br />
BitShares comes with tools that allow issuers to remain compliant<br />
with all applicable regulations when issuing assets, assuming<br />
regulators allow such assets in the first place. We will discuss the<br />
tools and optional administrative rights given to the issuers of a<br />
given UIA and provide a subset of possible use-cases in more<br />
detail.<br />
3.1 Deposit Receipts<br />
In principle, traditional banks are simply companies that maintain<br />
a database of customer account balances and facilitate the<br />
transfer of these assets among their depositors. Companies like<br />
Dwolla and Paypal essentially issue deposit receipts, and then<br />
offer cheaper transfers among their users compared to banks. The<br />
deposit receipt example is probably one of the most important,<br />
and yet most heavily regulated, use cases of UIAs. For that reason<br />
we will describe the tools available in BitShares that allow for<br />
compliant deposit receipts on the blockchain.<br />
<strong>With</strong> BitShares, it is now possible to move a company’s internal<br />
databases onto the blockchain where deposits can make use<br />
of all the features that BitShares offers, such as smart contracts,<br />
internal markets, escrow, or (later) bonds.<br />
In order to make traditional banking more profitable (through<br />
a decentralized account balance database), and enable services<br />
like Paypal and Dwolla while offering more freedom to the<br />
customers, we have identified (with extensive help from many<br />
different banks and exchanges) the relevant laws required to<br />
comply with when issuing deposit receipts. The following shall<br />
briefly discuss how BitShares can assist to comply with those<br />
rules 4 .<br />
3.1.1 Know Your Customer<br />
To comply with Know Your Customer (KYC) laws the issuer<br />
must know every single customer’s real world identity. BitShares<br />
supports this by enabling both whitelists and blacklists on the<br />
block chain.<br />
When an asset enables whitelists, no account may send, receive<br />
or trade that asset without being on an authorized whitelist.<br />
Rather than requiring every issuer to whitelist every customer<br />
separately, an issuer may specify a set of identity verifiers that<br />
they trust to do this job. This allows issuers to benefit from the<br />
network effect of validated users without having to do any direct<br />
identity verification themselves.<br />
<strong>With</strong> this feature, account funds can effectively be frozen by<br />
removing them from the whitelist. Of course this only affects<br />
those tokens of that particular UIA. Additionally, the issuer may<br />
take back his assets from any account, if required.<br />
Note that these kind of administrative powers are available<br />
only for UIAs and not for MPAs. Additionally an issuer may<br />
choose to indefinitely give up partial of full control over each<br />
specific administrative power.<br />
3.1.2 Asset Seizing<br />
From time to time, an issuer may be required to seize funds<br />
as a result of a court order. While this may be unappealing to<br />
4 This paper should not replace consultation of a lawyer<br />
cryptocurrency enthusiasts, it is an unavoidable reality of trustbased<br />
assets. An issuer can determine whether or not they wish<br />
to revoke this privilege, but it may be a requirement in some<br />
jurisdictions. Once again, this privilege only affects tokens of a<br />
particular UIA and does not apply to MPAs like the bitUSD.<br />
3.1.3 Market Restriction<br />
An issuer who offers USD, EUR and other fiat deposits may<br />
need to restrict direct trading between their fiat assets to avoid<br />
being subject to foreign currency exchange regulations. Some<br />
cryptocurrency exchanges allow trading between fiat and cryptocurrencies,<br />
but not between two fiat currencies. <strong>With</strong>out this<br />
feature, many exchanges would be unable to issue their assets on<br />
the BitShares blockchain. Hence, an issuer may choose to also<br />
white or blacklist trading partners for their user issued assets<br />
(i.e. IOUs). This way, the issuer can prevent customers from<br />
trading USD-IOUs for EUR-IOUs without restricting other pairs.<br />
Fortunately, MPAs, such as the bitUSD are not fiat and hence<br />
need not be blacklisted.<br />
3.1.4 Transfer Restrictions<br />
A transfer-restricted asset allows the holders of the asset to trade<br />
it in the markets but not transfer it from person to person. Only<br />
a few cryptocurrency exchanges allow user-to-user transfer of<br />
funds outside the market, because this particular activity is often<br />
subject to a different set of money transmission regulations. For<br />
that reason, known exchanges make use of so called coupon<br />
codes if there is a customer demand for user-to-user transfers.<br />
3.2 Use-Cases<br />
Having discussed the administrative possibilities of UIAs, we<br />
will now list and briefly describe a few use cases. These serve<br />
as examples and only represent a subset of the possibilities.<br />
3.2.1 Rewards Points<br />
A use-case that can be easily implemented and with only minor<br />
regulatory hurdles are reward points, which Merchants already<br />
today offer to their loyal customers. These points are accumulated<br />
to earn discounts on future purchases.<br />
Rewards systems are a prime opportunity to add value by<br />
making them available to BitShares smart contracts. <strong>With</strong> an<br />
UIA, a merchant no longer needs to maintain a database of<br />
customers and their rewards. Instead, he simply transfers a crypto<br />
token to the customer (e.g. via a mobile phone application) and<br />
the public ledger of BitShares takes over the maintenance leaving<br />
all administrative power to the merchant (i.e. the issuer of the<br />
UIA).<br />
Furthermore, because the issuer may set a trading fee for their<br />
UIA, merchants can have an additional revenue stream from<br />
people trading or transferring their rewards points.<br />
3.2.2 Event Tickets<br />
Event tickets are a largely unregulated use case for UIAs. Tickets<br />
to an event could be issued as digital tokens that are auctioned off<br />
Release: financial-platform/1.0-rc1-4-g23fc8ea (2015-11-12)
3.3 FEE POOLS 8<br />
to the highest bidder, who would then resell them. This ensures<br />
that the ticket issuer raises as much money as possible up front,<br />
while transferring the risk of ticket sales on to speculators. On<br />
the day of the event, the issuer can freeze all trading of the asset<br />
and then allow users to cryptographically check in (e.g. with their<br />
smart phones).<br />
Furthermore, the blockchain maintains the database of tickets<br />
which drastically reduces the organizational overhead.<br />
3.2.3 Digital Property<br />
Software and music licenses can be made transferable by issuing<br />
them as a digital asset. Every copy of a program can check to<br />
make sure that the user has control of a token before running.<br />
Software implementing such a licensing scheme can remain<br />
functional even if the company that produced the license goes<br />
out of business.<br />
Trading cards can be simulated by creating many limited issue<br />
assets. Online games can use these assets to represent game<br />
items.<br />
Further related possibilities include, but are not limited to:<br />
ownership tracking, authorization, membership identifications,<br />
etc.<br />
3.2.4 Crowdfunding<br />
<strong>With</strong> BitShares, decentralized crowdfunding becomes an easy<br />
task. Technically the process breaks down to as few as two steps:<br />
(a) Create and issue a new token that should represent your<br />
project, and (b) sell your shares on an exchange. The issuer is<br />
now free to choose to sell them for bitUSD, bitEUR, or any other<br />
token and is free to define the price for each share. Not only can<br />
these shares be traded on traditional (centralized) exchanges but<br />
they can also be traded in the decentralized exchange that will be<br />
discussed in section 4.<br />
Whether the UIAs are used as a transferable coupon for a presale,<br />
or for holding an initial public offering (IPO) for a small<br />
company, issuing an asset is one of the most effective means of<br />
raising money for a cause.<br />
3.2.5 Information/Prediction Markets<br />
<strong>With</strong> BitShares and the decentralized exchange described in<br />
section 4, prediction markets [6] can be quickly implemented.<br />
A binary prediction market has a “price” between 0 and 1<br />
representing the two possible outcomes of an event. All that is<br />
needed is a proper prediction criteria in the description of a newly<br />
created asset that anybody can issue by putting up collateral.<br />
Hence, a prediction market is a specialization of SmartCoins<br />
where there is no need for margin calls or forced settlement<br />
because all positions are fully collateralized at any price.<br />
While the event has not occurred, the price of this asset reflects<br />
the probability of an event to occur. After the event has occurred<br />
the issuer can settle all positions at final “price” depending on<br />
the actual outcome. Participants that have voted correctly will be<br />
able to settle their shares back to the network at a higher price<br />
and make a profit.<br />
These prediction markets can be very secure if the issuer is a<br />
multi-signature account with many independent and trustworthy<br />
parties involved.<br />
This feature, in combination with the bitUSD, allows anyone<br />
to implement most binary prediction and information markets<br />
currently established in a decentralized and trustless manner.<br />
3.2.6 Company Shares<br />
In most countries Corporate shares are heavily regulated by their<br />
corresponding exchange authority, such as the Securities and<br />
Exchange Commission (SEC) in the U.S. However, most of those<br />
regulations do not prevent them from being issued or traded<br />
on an alternative trading system [7]. The regulations in many<br />
jurisdictions require all shares to be registered (a.k.a. held by<br />
known identities).<br />
Since the BitShares network offers whitelisting for customers<br />
of UIA according to section 3.1, corporate shares can certainly<br />
be issued and traded in the BitShares ecosystem (see section 4).<br />
When issuing a corporate share in BitShares, the company<br />
can decide who is able to hold, share, or transfer its shares and<br />
can restrict trading markets freely (e.g. only allow the market<br />
STOCK:bitUSD but not STOCK:bitGOLD).<br />
3.2.7 Privatized SmartCoins<br />
Wit BitShares 2.0, users can create their own derivatives (i.e.<br />
price-stable assets) with custom parameters designed to track<br />
the value of any asset they can imagine by means of CFDs.<br />
The benefit of price-stable crypto-currencies is that they are fully<br />
collateralized, and the issuer only needs to be trusted to appoint<br />
an honest set of independent (non-collusive) feed producers.<br />
Unlike deposit receipts, the value of a privatized SmartCoin is<br />
secured even if the issuer disappears (in this case, however, the<br />
asset may be declared non-complying by regulators since white<br />
and blacklists cannot be updated any longer).<br />
To create a privatized SmartCoin, <strong>Bitshares</strong> provides several<br />
different parameters that an issuer may fine tune. In addition to<br />
account whitelists, market restrictions, and transfer restrictions,<br />
the issuer of a private SmartCoin has control over (a) Collateral<br />
Type, (b) Initial Collateral Rate, (c) Maintenance Collateral Rate,<br />
(d) Forced Settlement Fee, (e) Price Feed Update Rate, (f) Settlement<br />
Delay, (g) Global Forced Settlement, and (h) Trading and<br />
<strong>With</strong>drawal Fees.<br />
<strong>With</strong> these tools it is possible to emulate a pure contract for<br />
difference with periodic global forced settlement (i.e., monthly,<br />
yearly, etc), or to emulate BitAssets 1.0 by having a 30 day delay<br />
on forced settlement (c.f. section 2.1.2).<br />
Hence, any arbitrary financial indexes can be used for the price<br />
feed to mimic all manner of exotic assets. Also, because accounts<br />
are publicly auditable, even mixed asset funds can be modeled<br />
with the advantage of verifiable ownership claims by the fund<br />
manager.<br />
3.3 Fee Pools<br />
Issuers may optionally maintain a so called fee pool. The fee pool<br />
is a pool of BTS and an exchange rate at which the issued asset<br />
may be converted into BTS. This allows users to pay transaction<br />
Release: financial-platform/1.0-rc1-4-g23fc8ea (2015-11-12)
3.4 PROFITING FROM UIAS 9<br />
fees in the form of an asset even though the network requires fees<br />
to be paid in BTS.<br />
When a user wishes to pay a network fee with the asset, the<br />
fee pool will step in to convert the asset into BTS at the rate that<br />
the issuer has specified. This means that issuers may charge a<br />
premium every time users opt to use their asset to pay network<br />
fees rather than paying them directly with BTS.<br />
The purpose of the fee pool is to provide a convenience to users<br />
that would like to use an asset without concerning themselves<br />
with the details of acquiring BTS. Anyone may fund the fee<br />
pool, but only the issuer may specify the exchange rate. This<br />
exchange rate is automatically set to the settlement price if the<br />
asset is collateralized by BTS.<br />
3.4 Profiting from UIAs<br />
There are many ways to profit from issuing an asset. As the<br />
issuer you have complete control over market fees and can tune<br />
parameters such as the percent of each trade that is collected as a<br />
fee. This percentage can be bound by a minimum and maximum<br />
fee. The combination of these parameters give issuers flexibility<br />
in pricing.<br />
For example, you could easily implement a centralized payment<br />
solution on top of the decentralized BitShares network and<br />
mimic the business model of Dwolla and Paypal. In BitShares,<br />
you simply issue your own IOUs for U.S. dollars or Euro<br />
and send them to the wallets of your customers. Whenever a<br />
customers buys a market items from another customer, they may<br />
choose to pay with your IOU and require a percentage or fixed<br />
amount as fee for your service. The major advantage for your<br />
business is that you are not required to maintain your own highly<br />
reliable database servers that contain your customers’ balances<br />
since your customers maintain their wallets on their own and<br />
the public ledger securely stores the balances. This outsourcing<br />
increases security and profits, and improves competitiveness at<br />
no extra cost.<br />
4 Decentralized Exchange<br />
Throughout recent history, centralized exchanges have repeatedly<br />
proven unreliable and untrustworthy. Whether it is<br />
MF Global, Mt. Gox, BitStamp, or Bitfinex [8, 5, 9, 10], many<br />
people have been cheated because they allowed a 3rd party to<br />
hold their funds. It doesn’t matter how big they are, or how<br />
many auditors, regulators or insurers are involved, every kind<br />
of fraud, abuse, and theft can and has occurred. In the modern<br />
financial system, these transgressions happen all too frequently<br />
within centralized banks and exchanges all around the world.<br />
Hence, in the following paragraphs, we will outline the concept<br />
of the decentralized exchange (DEX) that powers the Bit-<br />
Shares network and discuss the many benefits of using it has over<br />
traditional centralized exchanges.<br />
4.1 Core Features of the DEX<br />
A decentralized exchange has a very particular set of advantages<br />
over traditional centralized exchanges, and we would like to<br />
address some of them briefly below. Although the BitShares<br />
DEX comes with all of them, it is up to the reader and customer<br />
to leverage those features for their particular needs.<br />
4.1.1 Separation of Powers<br />
There is no reason why the same entity needs to be responsible<br />
for issuing IOUs and for processing the order book. In fact, this<br />
is is actually a disadvantage from a security standpoint. It is<br />
only because these two roles have been combined that there is<br />
a tendency toward centralization in the Bitcoin exchange space.<br />
Since both sides of any order book consist of amount/price pairs,<br />
it makes more sense to store this data on a public ledger such as<br />
a blockchain. Therefore, to create a decentralized exchange, the<br />
first step is to move the order book onto the blockchain so that<br />
anyone can see and audit it.<br />
After this is done, gateway services can still be used to enter<br />
and leave exchange order book through IOUs, just like a traditional<br />
exchange uses. The blockchain can allow users to trade,<br />
for example, BitstampUSD against BitfinexUSD, and in order<br />
to easily move funds from one gateway to another. Users could<br />
even trade BitstampUSD against BitstampBTC or BitstampUSD<br />
vs BitfinexBTC.<br />
<strong>With</strong> this model, traditional exchanges merely act as gateways<br />
that receive fiat and issue GatewayFiat as an UIA on the<br />
blockchain (In reverse, they would receive their own Gateway-<br />
Fiat token, execute a wire transfer and then burn the token).<br />
These gateways would make their money entirely on transaction<br />
fees and from a percentage of the trading fees similar to their<br />
current model.<br />
But simply moving the order book to the blockchain is not<br />
enough, because the market would naturally centralize around a<br />
few gateway IOUs and the markets for them. Also, BitstampUSD<br />
is not fungible with BitfinexUSD because they have different<br />
trust profiles and regulatory considerations. Plus, any IOU carries<br />
the risk default similar to the the IOUs that currently exist on the<br />
exchanges’ internal databases. If we only had gateway IOUs, it<br />
would prevent the possibility of having a single, unified order<br />
book for USD pairs (or any fiat pair).<br />
Fortunately, BitShares has solved this issue with marketpegged<br />
assets. We have bitUSD which is backed by collateral and<br />
is independent of governments or centralized entities, and trades<br />
for $1 independent of any gateway. It is also universal because<br />
users don’t need to register their identity with anyone to use bitUSD<br />
or any other market pegged asset. So bitUSD pairs can now<br />
act as the universal order book, where users are safe to keep their<br />
funds on the books without risking counterparty exposure. This<br />
core features sets BitShare apart from Ripple, because BitShares<br />
has this unique “software protocol-based counterparty” that can<br />
never cheat a user out of their funds.<br />
4.1.2 Global Unified Order Book<br />
Because BitShares can be accessed through an internet connection<br />
and there exists only one source of truth, namely the<br />
blockchain, there can only exist one global order book for one<br />
particular market. The impact of such a global unified order book<br />
would be to improve market efficiencies (reduce all arbitrage op-<br />
Release: financial-platform/1.0-rc1-4-g23fc8ea (2015-11-12)
4.1 CORE FEATURES OF THE DEX 10<br />
portunities), minimize spreads, maximize liquidity and provide<br />
accountability and auditability.<br />
By having the trades executed on the BitShares network, it<br />
would eliminate all high-frequency trading and front running<br />
because everyone has the same chance of filling an order. High<br />
frequency trading and front running depend upon centralized<br />
exchanges with high volume and deep markets. When the vast<br />
majority of trading activity moves to a decentralized, trustfree<br />
exchange with open order books, the remaining centralized<br />
exchanges will become much less appealing to honest traders.<br />
Furthermore, BitShares does not have restricted open hours,<br />
and is available for trading 24 hours a day and 7 days a week.<br />
4.1.3 Trade Almost Anything<br />
BitShares offers the tools to trade in Gold, Silver, Gas, and Oil<br />
in addition to several national currencies and cryptocurrencies.<br />
There are few limits on what can be traded on the BitShares<br />
exchange, if there are enough people interested to form a market.<br />
The DEX allows any two pairs to be traded directly. There is<br />
no need to ask the exchange to open up an additional market. If<br />
customers prefer to trade Silver:Gold directly, they can simply<br />
do it. The BitShares exchange can support assets that can track<br />
stocks, bonds, indexes, or inflation. Companies can issue their<br />
own stock on the BitShares network and allow easy, low-cost<br />
trading with complete protection against naked shorting.<br />
4.1.4 No Limits<br />
Of course, you can trade any amount, at any time, from anywhere,<br />
without withdrawal limits 5 . All other legally compliant<br />
exchanges have daily withdrawal limits. Those who wish to<br />
exceed standard limits must provide increasingly invasive levels<br />
of documentation. Some exchanges, such as Coinbase [11], even<br />
limit what you can do with your money after you have withdrawn<br />
it [12]. Other exchanges demand documentation of how you<br />
earned your cryptocurrency.<br />
<strong>With</strong> BitShares, no one must approve your account, so you<br />
have complete financial freedom.<br />
4.1.5 Decentralized<br />
Decentralization gives BitShares robustness against failure.<br />
When a centralized exchange is compromised, millions of dollars<br />
and thousands of users are impacted all at once. In a decentralized<br />
system, any attack or failure would impacts only a single<br />
user and their funds. Users are in control of their own security,<br />
which is generally preferable to trusting a centralized entity.<br />
Furthermore, since KYC/AML verification can be outsourced<br />
via whitelists, a gateway that holds customers funds for fiat<br />
backed IOU’s would not necessarily need direct access to the<br />
customers’ identities. This was an issue with Mt.Gox [5], where<br />
thousands of customers’ identities were stolen.<br />
Since there is a fixed cost associated with attempting to hack<br />
an exchange or an individual user, the difference between a<br />
centralized exchange and the DEX is the size of the reward.<br />
5 Restricted access may only apply to user issued assets (e.g. IOUs of gateways),<br />
but not to market pegged assets, such as bitUSD, bitEUR, etc.<br />
If someone places a multi-million dollar bounty on attacking a<br />
specific exchange, then you can expect a lot more effort to be<br />
put into compromising that exchange than would be put into<br />
attacking your individual account.<br />
Furthermore, within any centralized company multiple people<br />
usually have access to customer funds. Likewise, most centralized<br />
exchanges end up depending upon multiple people who<br />
share the responsibility of guarding the secret key that controls<br />
the funds. If any one of them is compromised, everyone’s funds<br />
are put at risk. Because of this, being individually responsible for<br />
maintaining your own secrets is a much safer option.<br />
Access to funds in BitShares can be further secured by means<br />
of corporate accounts that implement threshold signatures [2, 13]<br />
and validate only those transactions which signature weights<br />
(e.g. the CEO has more say than a worker) surpass a pre-defined<br />
threshold.<br />
4.1.6 Secure<br />
The traditional banking system has long practiced what is called<br />
fractional reserve banking, but in many cases the more appropriate<br />
term is “fictional” reserve banking. In the BitShares<br />
ecosystem, however, we demand at least 100% reserves. Every<br />
Dollar, Euro, bitcoin and ounce of gold held as a SmartCoin on<br />
the BitShares DEX is backed by at least, but often greater than<br />
100% reserves. In a centralized exchange, a single hack, mistake,<br />
or theft can quickly turn a 100% reserve system into a fractional<br />
reserve system, or worse, a ”fictional” reserve system. <strong>With</strong>out<br />
any reserves, it is unlikely that an exchange would ever be able<br />
to pay back the funds it owes to its customers.<br />
Because the BitShares DEX always maintains a minimum<br />
of 100% reserves, users can rest assured that BitShares will<br />
be solvent in almost any market. Since all of the reserves are<br />
kept as BTS held in collateral on the blockchain, they cannot<br />
be compromised because there are no private keys that can be<br />
stolen.<br />
4.1.7 Fast, but not too fast<br />
On Wall Street, traders go to great lengths to get as physically<br />
close to the core computers as possible, because their automated<br />
trading robots make decisions so quickly that the speed of light is<br />
a formidable factor. This gives them an unfair advantage against<br />
other traders, and allows them to engage borderline unethical<br />
practices such as order frontrunning. They have even spent<br />
billions of dollars to lay transatlantic fiber optic cables between<br />
London and New York to shave milliseconds off of their trading<br />
times.<br />
On the BitShares DEX, all trades execute in seconds, just like<br />
with any other centralized website interface. Unlike centralized<br />
exchanges however, there is no prioritized trading, front running,<br />
or hidden orders. This puts all traders on a level playing field.<br />
4.1.8 Decentralization of Privacy<br />
Crypto-currencies depend upon a public ledger or blockchain,<br />
which makes privacy challenging, because everyone can see<br />
every transaction. Bitcoin gives every user one or more account<br />
numbers, and that gives many people a false sense of security.<br />
Release: financial-platform/1.0-rc1-4-g23fc8ea (2015-11-12)
4.2 ORDER MATCHING 11<br />
People assume that as long as no one knows their account number<br />
and they use a new account number with every transaction, it is<br />
impossible to tie their bitcoins to their real life identify.<br />
This is where the large centralized exchanges become a problem.<br />
In order to comply with government regulations, exchanges<br />
must know everyone they do business with. Since many bitcoin<br />
transactions flow through an exchange, the exchange learns who<br />
everyone is and can start to track who is doing business with<br />
whom. Coinbase is already closing accounts [14] based upon<br />
who you do business with after withdrawing your bitcoins.<br />
In order to have even the slightest bit of privacy, the exchange<br />
functionality needs to be divided among hundreds of parties<br />
who are unlikely to collude to compromise identity. This is not<br />
economically practical today, because the exchange order book<br />
creates market incentives that naturally tend toward centralization<br />
in just a few exchanges with the vast majority of market<br />
share.<br />
In BitShares, your identity need only be verified by issuers of<br />
IOUs (e.g. GateUSD) in order to comply with fiat regulations.<br />
Once traded for bitUSD your link to the gateway or exchange<br />
Gate can be removed quickly by means of blinded transactions<br />
that enables users to publicly move funds without revealing the<br />
exact amount [2, 15]. If issuers approve, blinded transactions<br />
may even be performed for UIAs directly.<br />
4.2 Order Matching<br />
The old BitShares 1.0 protocol went to great effort to avoid<br />
market manipulation and eliminate the supposed evil of front<br />
running. To stop front running, all orders were matched at the<br />
exact price specified in the order. Any overlap in the market<br />
was captured as fees. This means that to get the best price, a<br />
client would have been forced to submit many orders manually<br />
matching each order. This had the side effect of slowing down<br />
how quickly someone could walk the book. This slow down<br />
effect was pitched as protection against market manipulation<br />
attacks on SmartCoins.<br />
Experience has taught us that the lack of standard limit orders<br />
has harmed market liquidity and adoption. BitShares 2.0 matches<br />
orders on a first-come, first-serve basis and gives the buyer the<br />
best price possible up to the limit. Rather than charging unpredictable<br />
fees from market overlap, the network charges a defined<br />
fee based upon the size of the order matched and the assets<br />
involved. Each asset issuer gets an opportunity to configure their<br />
fees as described in section 3.3.<br />
In contrast to BitShares 1.0, there will also be limit-orders that<br />
allow to buy on the market up to a predefined price. This allows<br />
to instantly fill any order below or above your price at the cost of<br />
a single fee (c.f., section 6).<br />
4.3 Collateralized Smartcoins<br />
The heart of BitShares is the SmartCoin system which enables<br />
the creation of collateralized bitUSD from the BitShares network.<br />
A BitUSD has all of the properties of traditional cryptocurrencies<br />
like Bitcoin, with the additional features from BitShares<br />
combined with the price stability of the US dollar. At any point in<br />
time you can sell a BitUSD for at least 1 dollar worth of BTS. If<br />
at any time the value of the collateral falls below a certain point,<br />
the blockchain will automatically buy back the BitUSD with a<br />
dollars worth of BTS (forced settlement, see section 2).<br />
When you hold BitUSD the value of your holdings will<br />
remain pegged to the dollar so long as BitShares have a value<br />
greater than 0. This means that BitUSD is secure against just<br />
about everything but an unfixable software bug in the BitShares<br />
protocol itself. By the time BitShares matures to the level Bitcoin<br />
is at today, we expect the probability of that kind of bug to be<br />
similar to that of Bitcoin having such an event.<br />
4.3.1 Fiat Gateways<br />
The roles that traditional exchanges perform today are:<br />
1. Receiving cryptocurrency and issuing IOUs.<br />
2. Receiving fiat and issuing IOUs.<br />
3. Redeeming IOUs.<br />
4. Processing an order book.<br />
Each of these stages requires a high degree of trust and<br />
direct counterparty risk, because they involve an IOU from the<br />
exchange. To get the best liquidity and lowest spreads requires<br />
a large and active order book, and this means that most people<br />
gravitate toward a few core exchanges, leaving everyone exposed<br />
to the same counterparty risk.<br />
Moving money into or out of an exchange often incurs a<br />
significant time delay, which means that active traders must keep<br />
their funds on the exchange. This magnifies the amount of risk<br />
to users of the exchange. It also magnifies the risk to all users in<br />
the cryptocurrency ecosystem. Each large security breach results<br />
in significant sell pressure, from both the thief looking to cash in<br />
their loot, and from regular users hoping to sell before the thief<br />
does.<br />
<strong>With</strong> the separation of powers, we only need gateways that<br />
perform the tasks 1, 2 and 3 of the list above while order book<br />
processing and storage of account balances are managed by the<br />
BitShares protocol/network. An entity issuing and redeeming<br />
IOUs for another asset in BitShares is called a gateway. In<br />
contrast to central exchanges, the IOUs are sent to the wallet of<br />
the customer and are under his full control (see section 3.1).<br />
Many gateways prefer the low-risk approach of one-for-one<br />
redemption and will simply allow the GatewayUSD to float<br />
against BitUSD with a small but variable spread in the market.<br />
Users then pay a small variable conversion cost as they exit from<br />
BitUSD to fiat USD through GatewayUSD.<br />
On the other hand, many users will want a direct conversion<br />
from BitUSD to fiat USD. In this mode of operation, the gateway<br />
takes care of providing all of the liquidity within a fixed percentage<br />
transaction fee. The gateways then compete on offering the<br />
lowest possible spread.<br />
Once this happens, BitUSD is effectively as good as USD with<br />
a small fixed conversion fee. This fee will likely be no more than<br />
the withdraw and deposit fees that current exchanges charge. At<br />
that point, BitShares will be a fully operational exchange with<br />
many banking partners and no limits. At no point in time will<br />
user deposits ever be subject to default or confiscation by an<br />
exchange or gateway. A truly decentralized exchange will have<br />
been realized, and the original vision of BitShares completed.<br />
Release: financial-platform/1.0-rc1-4-g23fc8ea (2015-11-12)
12<br />
5 Platform for Further Smart Contracts<br />
In contrast Bitcoin that offers Script — a stack-based scripting<br />
language with a reduced set of instructions (called OP codes) —<br />
to allow for limited smart contracting capabilities, the BitShares<br />
network allows for arbitrary transactions types, in general.<br />
However, in contrast to so called Turing-complete blockchain<br />
projects, such as Ethereum, adding new features or transaction<br />
types to the protocol requires shareholder consensus.<br />
Hence, new features must be proposed to the shareholders who<br />
must reach consensus to approve them. Only after this happens<br />
is the protocol then upgraded to the next version which includes<br />
the new feature set.<br />
6 Fees<br />
In the BitShares ecosystem every operation is assigned an individual<br />
fee. These fees are subject to change. However, they<br />
are defined solely by shareholder approval, thus each and every<br />
shareholder of the BitShares core asset (BTS) has a say as to what<br />
the fees should be. If shareholders can be convinced to reduce<br />
a certain fee and consensus is reached, the fee will be reduced<br />
automatically by the blockchain 6 .<br />
7 Conclusion<br />
In this paper, we have described the foundations of the BitShares<br />
network, which we hope will soon begin to inspire a paradigm<br />
shift from classical banking towards peer-to-peer financing. We<br />
have laid out the many features and benefits of the BitShares<br />
Decentralized Exchange, which offers financial instruments for<br />
anyone to utilize with low barriers to entry.<br />
<strong>With</strong> SmartCoins, the BitShares ecosystem offers a powerful<br />
tool for everyone from speculators and savers, to traders and<br />
entrepreneurs.<br />
The order-matching algorithm is similar to most central exchanges,<br />
and allows a user to directly fill an existing order or<br />
walk-the-books up to a given price by means of a limit order. It<br />
also allows for trade of any arbitrary pair of assets issued on the<br />
BitShares blockchain.<br />
The BitShares platform provides a toolkit with which innovators<br />
can experiment to discover optimal currency solutions using<br />
free market trading.<br />
We also discussed how a price floor of $1.00 USD per bitUSD<br />
is the most reasonable approach to achieving price predictability.<br />
Additionally, we have shown that user issued assets (UIA)<br />
offer countless opportunities to reduce costs. They can be used<br />
to distribute a token on a decentralized database (the blockchain),<br />
and can be programmed to comply with government regulations.<br />
Since the BitShares protocol handles order processing and storage<br />
of user balances, any implementation of business models<br />
around UIAs comes at very low cost to the issuer and will make<br />
expensive central server infrastructure a thing of the past.<br />
References<br />
[1] Investopedia, “Contract for Difference,” http://www.<br />
investopedia.com/terms/c/contractfordifferences.asp.<br />
[2] “BitShares 2.0: General Documentation,” BitShares<br />
<strong>Whitepaper</strong>s, 2015.<br />
[3] Federal Reserve Bank of St. Louis, “Dataset:<br />
St. Louis Adjusted Monetary Base (AMBSL),”<br />
https://research.stlouisfed.org/fred2/series/AMBSL/<br />
downloaddata?cid=124, Aug. 2015.<br />
[4] D. Larimer, “Stable currencies are impractical and<br />
undesirable,” http://bytemaster.github.io/article/2014/12/<br />
31/Stable-Crypto-Currencies-are-Impossible/.<br />
[5] “Mt. Gox,” http://www.wired.com/2014/03/bitcoinexchange/.<br />
[6] Wikipedia, “Prediction Market,” http://en.wikipedia.org/<br />
wiki/Prediction market.<br />
[7] ——, “Alternative Trading System,” http://en.wikipedia.<br />
org/wiki/Alternative trading system.<br />
[8] “MF Global,” http://www.forbes.com/sites/<br />
francinemckenna/2012/07/16/auditors-all-fall-downpfgbest-and-mf-global-frauds-reveal-weak-watchdogs/.<br />
[9] “Bitstamp,” http://www.coindesk.com/bitstamp-claimsroughly-19000-btc-lost-hot-wallet-hack/.<br />
[10] “Bitcoin Exchange BitFinex’ Hot Wallet Hacked,”<br />
https://www.cryptocoinsnews.com/breaking-bitcoinexchange-bitfinex-hot-wallet-hacked/.<br />
[11] “Coinbase,” http://coinbase.com.<br />
[12] “Coinbase case demonstrates the pitfalls of regulatory compliance,”<br />
http://cointelegraph.com/news/112319/coinbasecase-demonstrate-the-pitfalls-of-regulatory-compliance.<br />
[13] Ripple Labs, “Multisig / Transaction Proposal,” https://<br />
wiki.ripple.com/Multisign#Transaction Proposal.<br />
[14] “Is Coinbase Bringing ”Big Brother” to Bitcoin Accounts?”<br />
https://www.cryptocoinsnews.com/coinbase-bringing-bigbrother-bitcoin-accounts/.<br />
[15] Oleg Andreev, “Blind signatures for Bitcoin transactions<br />
(second draft),” http://oleganza.com/blind-ecdsa-draft-v2.<br />
pdf.<br />
6 Changes of blockchain parameters are proposed by members of the committee.<br />
These members are voted by shareholders and improve the flexibility and<br />
reaction rate.<br />
Release: financial-platform/1.0-rc1-4-g23fc8ea (2015-11-12)
BITSHARES TESTNET STRESS-TEST<br />
Fabian Schuh BitShares Europe, bitshares.eu ∗<br />
Erlangen (Bavaria), Germany<br />
fabian@bitshares.eu<br />
Abstract—BitShares 2.0 is an industrial-grade decentralized<br />
platform built for high-performance financial smart contracts.<br />
In order to show its capabilities in the field, we have<br />
conducted a stress test on the public testnet. The testnet<br />
has been deployed with the same code base that is used<br />
for the BitShares network and has nodes around the globe.<br />
Only margin changes have been made to distinguish the<br />
testnet from the productive network, properly. A multi-phase<br />
stress-test has been proposed and accepted that modifies the<br />
maximum transaction size, maximum block size and block<br />
confirmation times in the live network during the stress test.<br />
Validators have been kept up to date by means of stakeweighted<br />
voting [1].<br />
1 Introduction<br />
The Graphene Platform has been developed by Cryptonomex<br />
specifically for BitShares. It has undergone many changes and<br />
has been enhanced to stay on top of blockchain technology. One<br />
of its public forks, BitShares, has been publicly traded for over<br />
2 years and has yet to show its maximum potential with respect<br />
to throughput. For this reasons, we have deployed a testnet, that<br />
uses the very same technology that BitShares is built on, with the<br />
specific purpose of testing algorithms, implementations, and also<br />
scalability.<br />
Here, the term scalability refers to the amount of transactions<br />
that can be applied to the blockchain at scale. Several factors<br />
need to be taken into account to correctly interpret any results<br />
obtained through testing. Among these are the specification<br />
of the deployed servers (CPU/RAM) that produce the blocks<br />
(validators), the interconnectivity of the nodes in the Peer-2-Peer<br />
network, the round-trip times and latency between nodes, as well<br />
as the geographical distance between nodes.<br />
The number of validators, furthermore, does not affect the<br />
throughput as long as all active validators can keep up with the<br />
requirements of the network. All active validators are treated<br />
equally and are given a slot to produce their blocks in each<br />
round [1]. Increasing the number of validators (a.k.a. witnesses)<br />
comes with an increased robustness against server failures yet<br />
also results in a longer duration to reach transaction finality [1]<br />
which describes the absolute irreversibility of transactions after<br />
∗ This work was supported by ChainSquad GmbH, BitShares-Munich IVS and<br />
honorable members of the bitsharestalk.org community.<br />
2/3 of all validators have approved a given block and its transactions.<br />
The goal of the public stress-test performed on the graphenebased<br />
testnet was to identify the limiting factors and bottlenecks<br />
at scale with multiple parties involved. We furthermore wanted<br />
to demonstrate scalability of current state of the art blockchain<br />
technologies.<br />
2 Testnet Setup<br />
We have deployed a separated blockchain for the public testnet<br />
that has been launched in January 2016. That blockchain was<br />
open to the public and every new account has been donated some<br />
of the core assets called TEST. By the time of the stress-test,<br />
the blockchain had over 6,800,000 blocks, and over 25,000,000<br />
operations processed.<br />
2.1 Software<br />
The software for the testnet backend has been maintained by<br />
BitShares Europe and is available for review on github.com.<br />
It is an almost identical fork of the Graphene code base that<br />
BitShares is built on with only marginal changes to accommodate<br />
the separated blockchain.<br />
The tools that have been developed for the stress-test and the<br />
analysis are mostly available in separate repositories as well.<br />
2.2 Validators<br />
The validators’ job is to collect unconfirmed and pending transactions<br />
as received through a Peer-2-Peer network, verify and<br />
validate them and publish your approval over those transactions<br />
in form of a signed block that carries those transactions.<br />
Given that the Graphene testnet also uses Delegated Proof of<br />
Stake (DPOS) as its consensus mechanism, the validators (a.k.a.<br />
block producers) can be voted in and out by means of the stakebased<br />
governance system [1]. This allowed us to 1. modify the<br />
number of validators 2. replace failing validators by standby<br />
validators 3. pick validators that are closer geographically (if<br />
location is known) every maintenance interval. This interval is<br />
used to tally all votes made since the previous maintenance block<br />
and is set to 5 min on the test-network.<br />
At the beginning of the stress-test, we will have these validators<br />
active:<br />
blckchnd-x Intel Xeon E3, 32GB RAM, bare bone, Germany<br />
Release: stress-test/1.0-1-g96f3268 (2017-04-04)
2.3 REFERENCE FULL NODE AND SEED NODE 2<br />
blckchnd-test Intel Xeon E3, 32GB RAM, bare bone, Germany<br />
jim.witness1 Intel Xeon R○ E5, 28-56GB RAM, Azure,<br />
South Korea<br />
smailer-5 Intel Xeon E3, 32GB RAM, Germany<br />
init0 Intel Core i7, 32GB RAM, bare bone, Germany<br />
init2 Intel Core i7, 32GB RAM, bare bone, Germany<br />
lafona2 Intel Avoton, 32GB RAM, France<br />
delegate.ihashfury Intel Atom C2750, 32GB RAM, bare<br />
bone, France<br />
f0x Intel Xeon E5, 56GB RAM, Azure, USA<br />
alpha-jpn Intel Xeon E5, 56GB RAM, Azure, Japan<br />
bravo-bra Intel Xeon E5, 56GB RAM, Azure, Brasil<br />
charlie-usa Intel Xeon E5, 56GB RAM, Azure, USA<br />
delta-gbr Intel Xeon E5, 56GB RAM, Azure, UK<br />
rngl4b Intel Xeon E5, 32GB RAM, bare bone, Luxembourg<br />
taconator-witness Intel Xeon E5, 24GB RAM, Switzerland<br />
arthur-devling Intel Xeon E5, 39GB RAM, France<br />
fr-blockpay Intel Xeon E5, 256GB RAM, Germany<br />
de-blockpay Intel Xeon E5, 128GB RAM, France<br />
2.3 Reference Full Node and Seed Node<br />
A bare bone reference node is provided by BitShares Europe<br />
that allows participants to interface with the Peer-2-Peer network<br />
without running their own full-nodes. The endpoint is available<br />
at wss://node.testnet.bitshares.eu and is powered<br />
by an Intel Core i7 with 64GB of RAM which carries two fully<br />
balanced full nodes to deal with the traffic.<br />
A frontend-wallet is provided under<br />
https://testnet.bitshares.eu.<br />
3 Limiting Factors<br />
In this section we briefly discuss the limiting factors we have<br />
identified prior to the stress-test. For the sake of proper description,<br />
we first need to look into the distinction of blocks,<br />
transactions, and operations.<br />
Transactions and Operations In contrast to other<br />
blockchains, Graphene-based blockchain explicitly allow to<br />
bundle multiple operations into a single transaction. Similar<br />
to Bitcoin allowing to bundle multiple outputs, but with the<br />
option to execute different smart contracts offered by the<br />
blockchain sequentially. The easiest application is similar<br />
to Bitcoin’s multi-send feature where a single user sends<br />
bitcoins to many addresses. In the case of Graphene/BitShares,<br />
the user would also sign a single transaction with a single<br />
signature but the transaction would carry many transfer<br />
operations. Additionally, a user may put a combination of<br />
trade/transfer/borrow operations (or any other) into a<br />
single transaction to ensure that they are executed sequentially.<br />
As can be seen, the main difference between bundling many<br />
transactions into a block and bundling many operations into a<br />
transactions is that in the latter case, the operations are guaranteed<br />
to be executed sequentially and that only a single authorization<br />
(e.g. signature) needs to be validated and verified.<br />
This distinction is important as our test results will clearly distinguish<br />
between the throughput of operations and the throughput<br />
of transactions.<br />
Signature Verification Similar to other blockchain technologies<br />
(i.e. Bitcoin), a single block may contain multiple transactions.<br />
Each transaction is signed by one or multiple entities and<br />
thus requires the validators to perform elliptic curve signature<br />
verification as well as public key recovery for authorization.<br />
From a scalability point of view, the limiting factors are the<br />
time and resources that are required to validate a signature for<br />
a given transaction and the time and resources that are required<br />
to append a transactions to the blockchain and execute its corresponding<br />
smart contract/operation.<br />
Since the Graphene technology is built such that the signature<br />
validation can be done independent of the blockchain’s current<br />
database state, the signature verification and key recovery can be<br />
trivially parallelized by means of a cluster or the use of a graphics<br />
processing unit (GPU). However, as the required software for this<br />
parallel verification was not available at the time of the stresstest,<br />
we expect the throughput to be significantly higher once we<br />
can be validated on a GPU.<br />
For this reason, and because we want to see the limiting factors<br />
when applying validated transactions to the blockchain, parts of<br />
our test scenario are focused around producing transactions that<br />
carry hundreds of transfer operations with just a single signature<br />
to be verified.<br />
Connectivity Obviously, a globally distributed network represents<br />
the worst case scenario when it comes to latency between<br />
nodes limited mostly by the speed of light and the size of the<br />
planet. A network that is hosted locally can result in better<br />
overall performance but does not offer the same robustness and<br />
redundancy as a global network.<br />
Memory Requirements In previous tests, we have identified<br />
a significantly increasing need for memory by the blockchain<br />
providing back-end software. This was mostly caused by so<br />
called plugins that take care of historic events, such as account<br />
transactions history or the trading histories. Those plugins kept<br />
their data in memory for performance reasons. Once we disabled<br />
these plugins, the validating software only required a few hundred<br />
Megabytes of memory.<br />
Transaction Production In order to stress-test a network,<br />
we need to produce actual stress which is not easy to achieve at<br />
the scale that we needed for our tests. Furthermore, we wanted<br />
to simulate a more or less realistic scenario in which multiple independent<br />
parties distributed on the globe produce transactions,<br />
each transaction trying to make it into the next block.<br />
For this reasons, we have asked the BitSharesTalk community<br />
to participate in the stress-testing not only by means of providng<br />
validation nodes across the planet, but also to produce the required<br />
stress.<br />
Peer-2-Peer Networking The original codebase of<br />
Graphene has a hard-coded limit in its Peer-2-Peer networking<br />
Release: stress-test/1.0-1-g96f3268 (2017-04-04)
3<br />
code (not part of the blockchain consensus protocol), that<br />
prevented us from reaching more than 1000 tps due to restriction<br />
in the amount of transactions being obtained through the Peer-2-<br />
Peer network. After increasing this limit way beyond what we<br />
wanted to achieve in our stress-test, we allowed the validating<br />
nodes to obtain up to thousands of transactions per second from<br />
the Peer-2-Peer network.<br />
However, the Peer-2-Peer networking code has been optimized<br />
for a block interval of about 10 s and thus leaves a lot of room<br />
for optimizations when talking about high-throughput at low<br />
latencies.<br />
4 Phases of the Stress-Test<br />
Since we use Graphene as our underlying technology, most<br />
blockchain parameters can be changed in real-time with no need<br />
for protocol upgrades or hard forks.<br />
In contrast to the public BitShares network, the majority of<br />
the stake in the public testnet is owned by BitShares Europe<br />
which allowed us to change the parameters without the need to<br />
coordinate with other stakeholders.<br />
This allowed us to setup a multiple phase stress-test that went<br />
through a set of different blockchain parameters to gradually increase<br />
the amount of processed transactions on the blockchain.<br />
4.1 Modifying Blockchain Parameters<br />
For our stress-test, we decided to focus on three blockchain<br />
parameters only:<br />
Max. block size This limit allowed us to modify the size<br />
of the blocks that are considered valid by the network. For our<br />
test, the size will be between 1 MB and 10 MB. The limiting<br />
factor is the supported data rate and connectivity of the validating<br />
nodes since blocks need to be produced and broadcasted within a<br />
certain time interval. A broadcast block needs to be received by<br />
the subsequent validator in time, otherwise the subsequent block<br />
cannot be linked to the expected previous block properly.<br />
Max. transaction size Each block can carry multiple transaction<br />
and, in contrast to many other blockchain technologies,<br />
transactions on Graphene-based blockchains can carry multiple<br />
operations. In our test, we assume that most of the operations<br />
are simple transfers of size 22 bytes. Together with the transaction<br />
header, a simple single-transfer (unsigned) transaction is<br />
36 bytes large. During the stress-test, we allowed between 50 and<br />
1000 transfer operations to be bundled into a single transaction.<br />
Block confirmation time The block confirmation time is the<br />
expected time between blocks. At the beginning we started with<br />
a 3 s block interval and reduced it down to 1 s at which point we<br />
expected the network to lose its robustness because of its global<br />
distribution, and because round-trip durations together with the<br />
need to transmit non-empty blocks might require more time.<br />
These parameters can be changed by a committee decision that<br />
is manifested through a dynamic multi-signature account. The<br />
members of the committee are voted on by the shareholders and<br />
collectively (with 50%+1), the committee can modify blockchain<br />
parameters by a single transaction. The procedure requires sufficient<br />
committee members to approve/co-sign a transaction that<br />
proposes to change parameters. After approval, the parameters<br />
are changed during the next maintenance block.<br />
4.2 Tested Parameter Sets<br />
The stress-test contained seven phases. As can be seen, the last<br />
two phases changed the block confirmation time and drastically<br />
reduce the maximum block size to ensure that blocks can at least<br />
be transferred in a timely manner. Whether blocks are propagated<br />
to the witnesses in time is is outside of direct control of the testers<br />
since we are running on a public and globally distributed Peer-2-<br />
Peer network.<br />
phase max. tx size max. block size block interval<br />
1 1 kb 1 MB 3 s<br />
2 1 kb 5 MB 3 s<br />
3 10 kb 5 MB 3 s<br />
4 100 kb 5 MB 3 s<br />
5 100 kb 1 MB 2 s<br />
6 100 kb 1 MB 10 s<br />
7 100 kb 1 MB 1 s<br />
5 Results<br />
5.1 Processed Transactions/Operations<br />
During our 4h-stress-test between 2pm and 6pm, the blockchain<br />
processed 4,011,110 transactions and 16,398,274 operations in<br />
4233 blocks. We varied three blockchain parameters including<br />
block confirmation times between 1 and 10 s.<br />
5.2 Transaction/Operation Throughput<br />
After the stress-test, when the transactions and operations had<br />
been added to the blockchain, we reviewed the blockchain offline.<br />
Given that the transactions and operations are recorded on<br />
the blockchain, we started by investigatng the overall results first.<br />
As can be seen from fig. 1 (top), there are multiple periods of<br />
activity. Clearly, most of the transactions started being broadcast<br />
from 15:00 going forward with an average of approximately<br />
1000 transactionsperblock afterwards. We also notice that the<br />
throughput was not constant during the stress-test which can be<br />
explained by the transactions requiring some time to propagate<br />
through the Peer-2-Peer network.<br />
We can further see in fig. 1 (bottom), that the participants<br />
have been constantly trying to modify their spam production<br />
method (increaseing number of transactions vs. bundling more<br />
operations per transaction) until a maximum of processed operations<br />
per block was reached at about 16:40. Afterwards,<br />
the participants were asked to increase the number of created<br />
transactions instead which is why the processed operations per<br />
block decreased later on.<br />
Most interestingly, we observed several short peaks of processed<br />
transactions and operations during the whole stress-test.<br />
As it turned out, the reasons of those peaks can be explained by<br />
a single participant who decided to use his block validating node<br />
Release: stress-test/1.0-1-g96f3268 (2017-04-04)
5.3 BLOCK CONFIRMATION TIMES 4<br />
Figure 4: Max ops/s during the stress-test<br />
Figure 1: Overview of the throughput ops/s and txs/s during the<br />
whole stress-test<br />
to produce transactions. By this, he skipped the propagation of<br />
transactions through the Peer-2-Peer network which confirms to<br />
us that the networking code represents one of the bottlenecks.<br />
5.3 Block Confirmation Times<br />
After investigating the throughput of the blockchain, we also<br />
tested the Peer-2-Peer network and capability to deal with different<br />
block confirmation times. As a reminder, the technology<br />
tested here is capable of changing different blockchain parameters<br />
on the fly. One of these parameters is the block confirmation<br />
time which represents the time between the blocks in<br />
the synchronous consensus mechanism delegated proof-of-stake<br />
(DPOS).<br />
Figure 2: Max ops/s during the stress-test<br />
In fig. 2, we have zoomed into a period of rather high throughput<br />
(i.e. 2500 transactionsperblock). Here, we still see the peaks<br />
produced by skipping the networking.<br />
Figure 5: Max ops/s during the stress-test<br />
Figure 3: Max ops/s during the stress-test<br />
Finally, the results in fig. 3 show that the blockchain was able<br />
to process an average of over 8000 operationsperblock with<br />
quite high peaks and an irregular throughput per block.<br />
The irregularity can be resolved by deploying similar hardware<br />
that can all process the same amount of transactions/operations.<br />
We were able to confirm this behavior later on by replacing all<br />
validators except for one, which greatly reduces the variance of<br />
the throughput as can be seen in fig. 4. Here, the stress has been<br />
produce by a single node connected directly to the validating<br />
node while another single validator was only connected through<br />
the Peer-2-Peer network.<br />
In fig. 5, we can see the actual block confirmation time as<br />
tracked by the blockchain. These values have been obtained<br />
from each block header which also contains the time stamp.<br />
Little variations are to be expected due to slightly inaccurate<br />
synchronization of the local time, while large deviations indicate<br />
one or multiple validators to have missed their blocks. The graphs<br />
shown in the figure are averaged over 100 blocks to reduce the<br />
noise.<br />
We can see that, during the stress-test, multiple different block<br />
confirmation times were tested, starting with 5 s, going down<br />
to 2 s, then up to 10 s until we decided to also test 1 s block<br />
confirmation time. Unfortunately, we observed some witnesses<br />
not producing during large parts of the stress-test which is why<br />
the averages are above the target rates most of the time. For our<br />
next stress-test we plan to be more strict in replacing witnesses<br />
when they miss block production blocks.<br />
In ?? highlights the period when the block confirmation time<br />
was reduced to 1 s. We can see that most of the blocks were produced<br />
in time with only up to 3 validators not having produced<br />
in time (i.e. the black peaks going up to at most 4 s). This came<br />
Release: stress-test/1.0-1-g96f3268 (2017-04-04)
5<br />
each and everyone that has been running a machine for the stresstest<br />
and BitShares-Munich for providing the major API node on<br />
bitshares.eu.<br />
References<br />
[1] “BitShares 2.0: General Documentation,” BitShares<br />
<strong>Whitepaper</strong>s, 2015.<br />
Figure 6: Max ops/s during the stress-test<br />
as a big surprise to us as we had expected a higher block-miss<br />
rate all together.<br />
6 Conclusions<br />
<strong>With</strong> our testing, we have seen that the code base is much<br />
more robust than we had expected. The block creation and block<br />
validation is sufficiently fast so that we can run a blockchain with<br />
synchronous block confirmations times of 1 s without validators<br />
dropping out too much.<br />
The Peer-2-Peer code seems to be working nicely but results<br />
show that it could be one of the bottlenecks currently preventing<br />
us from going further. The computational resources of our validators<br />
have more than enough back-off for higher throughputs<br />
but the networking code was not able to provide sufficient data<br />
(e.g. transactions) to raise it during our stress-test.<br />
We have further identified another bottleneck with respect<br />
to transaction production. Signing transactions takes more resources<br />
and we will prepare properly for our next stress-test. This<br />
result was confirmed in a later private testnet where 36 cores have<br />
been activated during the test sequentially. The result was that<br />
the blockchain easily dealt with all of the produced transactions<br />
and the throughput increasesed accordingly, each time additional<br />
cores have been added to transaction production.<br />
To conclude, the current software stack still has a few limitations<br />
and edges that need to be optimized in order to improve<br />
scalability further, but the foundation has been designed in such<br />
a way that it allows for even higher throughput. Our current<br />
limitations are purely in the implementation and networking<br />
aspects than in the software and protocol architecture.<br />
7 Acknowledgements<br />
We would like to thank every one that has participated in the<br />
stress-test for block validation, transaction generation and setup<br />
of a robust Peer-2-Peer network. We would like to further acknowledge<br />
the assistance during the preparations of the stresstest<br />
and the feedback we have received while writing this paper.<br />
Last but not least we appreciate the financial support given by<br />
Release: stress-test/1.0-1-g96f3268 (2017-04-04)