176 lines
7.5 KiB
Markdown
176 lines
7.5 KiB
Markdown
BSIP: 00025
|
|
Title: Transaction Flat-Rates with Weighted Rate-Limitation
|
|
Authors: Fabian Schuh <Fabian.Schuh@blockchainprojectsbv.com>
|
|
Status: Draft
|
|
Type: Protocol
|
|
Created: 2017-10-16
|
|
Worker: T.B.D.
|
|
|
|
# Abstract
|
|
|
|
Blockchain technology currently depends upon transaction fees to prevent
|
|
spam. These fees suffer all of the known problems with
|
|
micro-transactions and prevent blockchains from being used for low-value
|
|
transactions, massive trading and high-rate market making. Truly
|
|
decentralized applications must offer users the *appearance* of free
|
|
transactions if they wish to compete with their centralized
|
|
alternatives.
|
|
|
|
This document proposes a protocol upgrade to BitShares to introduce
|
|
rate-limitations for *fee-free* transactions. Since the BitShares
|
|
blockchain is entitled to be a profitable decentralized autonomous
|
|
company (DAC), making use of *fee-free* transactions comes at a
|
|
*monthly* fixed cost as well as the option to lock shares away in a
|
|
vesting balance in order to increase the standard rate at which users
|
|
may interact with the blockchain.
|
|
|
|
# Motivation
|
|
|
|
Blockchains are decentralized networks where all transactions are
|
|
broadcast to all peers. Every so often a block is produced that includes
|
|
some or all of the pending transactions. All blockchains must find a
|
|
solution to prevent malicious users from consuming all of the available
|
|
network capacity with worthless transactions. These worthless
|
|
transactions can prevent other valuable transactions from being
|
|
processed and ultimately destroy the network.
|
|
|
|
The solution adopted by most blockchains thus far is to charge a minimum
|
|
transaction fee. A fee worth just a few cents is enough to make
|
|
attacking the network expensive and unprofitable. While this approach
|
|
solves the spam problem, it introduces new problems.
|
|
|
|
Market making as well as micro-transactions are a highly competitive
|
|
market. Being *decentralized* and *trust-less* alone, does not make the
|
|
BitShares blockchain a good competitor when compared to centralized
|
|
services.
|
|
|
|
Despite blockchain transactions being cheaper *technically*, the fee
|
|
that is attached to each and every transaction on BitShares results in
|
|
some crucial businesses to be unviable, such as **market making** at
|
|
scale, where dozens of orders are created (and canceled) continuously,
|
|
in order to provide liquidity to the markets.
|
|
|
|
# Rational
|
|
|
|
In this proposal, we extend the BitShares fee model to allow
|
|
transactions made by accounts to go through without paying a fee. We
|
|
require accounts to be lifetime members to harness a **transaction
|
|
flat-rate** with certain limits that can be raised by additionally
|
|
providing BTS (units of the core asset) in a vesting balance that is
|
|
locked away for a certain amount of time, only do be made liquid in
|
|
weekly chunks over the whole period.
|
|
|
|
## Full Reserve vs Fractional Reserve
|
|
|
|
Let's view a blockchain like an Internet Service Provider (ISP) co-op
|
|
which owns all of the cables in the town and can process a maximum
|
|
amount of data transmission on those cables at any time. This is called
|
|
*the capacity* of the transmission lines. People living in the town can
|
|
buy shares in the ISP and obtain the right to utilize a portion of the
|
|
available capacity.
|
|
|
|
The ISP has two choices and can either run a **full reserve** or
|
|
**fractional reserve** system.
|
|
|
|
* Under a full reserve system each user is only allowed a fraction of
|
|
the capacity proportional to her shares. Because not everyone uses
|
|
the Internet at the same time, the town's network would be significantly
|
|
underutilized.
|
|
* Under a fractional reserve system the individual users could utilize
|
|
more date rate than they are entitled to at any given point in time so
|
|
long as not everyone uses the Internet at the same time.
|
|
|
|
The problem with operating a fractional reserve is that congestion
|
|
occurs anytime too many people wish to use the network at the same time.
|
|
The ISP needs a way to prioritize transmissions during congested
|
|
periods. In the most extreme case, a fully congested network must revert
|
|
to a full reserve system.
|
|
|
|
The challenge is setting the proper fractional reserve ratio or
|
|
implement a **dynamic fractional reserve ratio**. Under this model the
|
|
blockchain will
|
|
automatically adjust the reserve ratio for the network during times of
|
|
congestion. The blockchain will set a target utilization that leaves
|
|
enough headroom for short term surges in demand. Any time the surges
|
|
are sustained the blockchain reduces the maximum rate-per-share.
|
|
When a surge is over and there is surplus capacity the blockchain can
|
|
slowly increase the rate-per-share.
|
|
|
|
If the time window for this control cycle is stretched too far then the
|
|
reserve ratio will not adjust fast enough to respond to short-term
|
|
surges, if the window is too short then clustering usage will have too
|
|
big of an impact on normal users.
|
|
|
|
In our estimate it should be sufficient to measure the average weekly
|
|
transaction rate usage of users. This parameter will be changeable by
|
|
the BitShares committee. The advantage with this approach is, that the
|
|
BitShares committee can define whether they prefer a dynamic fractional
|
|
reserve, where occasional uses may transact more often within a very
|
|
short period of time, or a simple and static method, where professional
|
|
users get an easy picture of how many transactions they may produce in a
|
|
certain amount of time.
|
|
|
|
## Flat-Rate Model
|
|
|
|
In recent years, ISP providers have seen a shift in their own economics
|
|
leaving the *pay-per-use* (e.g. per minute) service domain where users
|
|
paid for a duration they occupied a land-line to go for a
|
|
*pay-per-serice* flat-rate model where users paid a fixed fee to enable
|
|
a specific service to be used for free within certain conditions (e.g.
|
|
data volume). With the improvements in communications technology, land
|
|
lines got replaced by fiber which can carry significantly more load.
|
|
Thus the flat-rate model makes sense from business perspective.
|
|
|
|
The same holds true for blockchain technologies. The Graphene framework
|
|
is capable of incomparable transaction loads and thus, the individual
|
|
transaction may not be tagged with a fee for the profit alone, but
|
|
merely to prevent spam. A full reserve system gives value to a
|
|
transaction processing capabilities of the blockchain which everyone can
|
|
own a share of to prevent spam.
|
|
|
|
## Flat-Rate with Weighted Rate-Limitation
|
|
|
|
That said, we here propose a combination of the flat-rate model with a
|
|
stake-weighted limitation of transaction rates.
|
|
|
|
* **Flat-Rate**: A new feature is added to the blockchain that enables
|
|
the flat-rate model with a basic transaction rate that can be defined
|
|
by the BitShares committee (e.g. 10 transactions per day). This
|
|
operation costs a fee and lasts for a committee-parameterized amount
|
|
of time (e.g. 30 days). These rates are the same for every single user
|
|
that has bought the flat-rate subscription.
|
|
|
|
* **Stake-Weighting**: Since some users may need more than the basic
|
|
amount of transactions per day, power users can increase the
|
|
implicitly assumed weight of 1x to a higher value by providing BTS
|
|
core tokens in a vesting balance locks them away for as long as the
|
|
subscription lasts.
|
|
|
|
This ultimately gives the option to
|
|
|
|
* pay a fee for every transaction (current system)
|
|
* pay for a flat-rate to transaction for fee within certain conditions
|
|
* powerup your account with core tokens to increase fee transaction
|
|
rate
|
|
|
|
# Specifications
|
|
|
|
* Do not refund order creation fee!
|
|
* Replace Annual Fee operation?
|
|
|
|
# Discussion
|
|
|
|
Todo
|
|
|
|
# Summary for Shareholders
|
|
|
|
Todo
|
|
|
|
# Copyright
|
|
|
|
This document is placed in the public domain.
|
|
|
|
# See Also
|
|
|
|
1. [Steem Whitepaper](https://steem.io/SteemWhitePaper.pdf)
|