This article will cover the methodology we will be using to explore the possibilities and limits of the Gravity emission model. The main idea of this research is to explore the flexibility of the model, as well as its strengths and weaknesses. The tools that we’ve created for modelling user behavior and further statistics analysis are available in our GitHub repo. This will be the first in the series of articles on the subject.

Aims of the modelling process:

• to model such scenarios that carry no threat to the system, and to see how the model behaves in those cases;
• to create a standard of the model’s results that will be used to compare with other scenarios and later, as a benchmark to monitor the system’s safety;
• to tune the model’s parameters in such a way that honest active users and businesses within the system are rewarded accordingly.

Assumptions:

• the emission model rewards users that own a lot of tokens as well as active users;
• the model detects bot activity and clusters and minimizes reward towards artificial activity.

Methodology:

• choose and describe the account roles in the system based on their wealth and activity;
• select the number of accounts assigned to each role;
• model the frequency and intensity of transactions;
• run transactions through the model with different parameter settings.

Further development:

• compare the modelling results with the testnet;
• create more realistic scenarios;
• stress-test the system to outline its limits.

Description of the neutral scenario:

For the initial stage of the modelling process we’ve created a hypothetical scenario of transactions between a number of user groups. This is necessary for comparing a neutral environment with an aggressive environment where malicious accounts and nodes act with personal incentives. The accounts are viewed as vertices in a graph and the transaction history - as an edge between two vertices.

Code that generates the neutral scenario. Neutral scenario description and stats (transaction history is available on GitHub):

This scenario is a set of 100 000 transactions between 1500 accounts. There are no malicious or any other extraordinary transactions within this particular scenario. The transaction frequency grows as a function of time (square root of 0.75t). The initial token supply is equal to 1 000 000 000 tokens. The fee is currently fixed and equals 20 tokens per transaction. The transactions start on 2018-04-01 11:00:00 and stop on 2018-07-01 11:00:00. The emission takes place weekly.

Initially, all the tokens are on the genesis account (address 'g6058z5762i1084'). This account does not receive tokens and distributes (almost) all of the tokens to the first 200 accounts in roughly equal amounts.

The types of accounts in the system are: HODLers, businesses, sellers, buyers, and an exchange ('g1791u5098w9228'). Any account can deposit tokens to the exchange for trading or withdraw tokens onto their wallet. In addition, any two accounts are allowed to transact with each other. There are 50% of HODLers, or relatively inactive accounts, 25% of sellers who behave in a mildly speculative manner, and 25% of buyers who try to gradually accumulate wealth.

The types of accounts in the system are defined in a probabilistic manner. A transaction is formed by a random selection of a sender and a receiver, and the types of accounts each have probabilities of sending or receiving an amount of tokens. Probabilities of sending a transaction by account type: {'exchange' : 0.005, 'genesis' : 0.005, 'buyer' : 0.33, 'seller' : 0.6, 'hodler' : 0.06}. The genesis address does not send tokens after the initial distribution. These are the probabilities of receiving a transaction by account type: {'exchange' : 0.05, 'genesis' : 0, 'buyer' : 0.55, 'seller' : 0.25, 'hodler' : 0.15}. Here we see, for example, that a HODLer has a much higher probability of purchasing tokens rather then selling them, but is also altogether less active than other users. This probability proportion is what defines a role in the system.

The minimum transaction amount threshold is 1000 tokens. The amount sent by an account is a random amount between the minimum threshold, and 30% of the sender's current balance. If an account tries to send a smaller amount, it does not go through.

Another account subtype in the system is a business.Defined as an address that accepts tokens as a payment for their services. In the system, businesses do not accumulate wealth and go on to send their tokens further, but are a frequent receiver of transactions. Each business account has a set number of clients in the system.

The number of businesses in the scenario is equal to 8. The number of clients of each business is equal to [20, 30, 80, 20, 15, 25, 18, 10]. A business-to-customer transaction takes place with a 40% probability and a customer-to-business transaction takes place with a 60% probability. The number of business-related transactions in the system is equal to 10% of all transactions, or roughly 10,000. The number of a business transactions is a random amount between the minimum threshold and 40% of the sender's current account.

The aim of this scenario is to create a standard setting that develops slowly and organically, as well as providing a way to see the dynamics of the system, the balances, volumes, emission, account activity, and gravity index, all grouped by account types. The observed dynamics are then compared with a set transaction with malicious accounts intending to compromise or manipulate the system by transacting very intensely or by creating clusters within the system. The system parameters are tuned to neutralize malicious activity. The goal is to communicate that that an attack is too expensive to carry out and does not give a financial incentive.

The metrics that we build to evaluate the performance of the model are:

• The number of accounts that register weekly (cumulative);
• Weekly balance distribution between the groups;
• Weekly activity and gravity indices (by group);
• Sum of sent and received transactions (by group);
• Weekly volumes (by group);
• Weekly account activity (by group);
• Weekly emission received (by group).

We can also see the general characteristics of a representative from each group in the python notebook.

Next, we compare the neutral scenario with an aggressive one. A purely hypothetical scenario in which where we initially distribute about 50% of the tokens to 150 attackers. These attackers not only own half of the system’s wealth, but they also operate in a very frequent and aggressive manner by transacting between the richest of their accounts by a random percentage of their balance (between 80% and 90%).

In the following charts of weekly trading volumes(transactions and balances), we see that the absolute majority of traded tokens happens between the attackers. Even though they attack, execute the majority of the transactions, and own such a large part of the tokens, they receive less than half of the emission within the system (see chart: ‘weekly emission by group’). The amount invested into purchasing the tokens as well as the cumulative fees (and accordingly, number of sent transactions) paid by the attackers, are much higher than the emission received by the attacking group.

The two basic scenarios (with and without attackers), show us that the system withstands to a very aggressive scenario and thus will be highly resistant to real attacks which are similar in concept but will be carried out with less actual resources from the attackers.

Please stay tuned for more models, real net data, stats and analytics.

by Lana Ivina (GitHub)

📢 Gravity Launches Public Testnet

Come to our testnet and break our toys!
Gravity Testnet Instructions Set
Gravity Testnet Report 25.05.2018 - 08.06.2018

Want to join our team?

Gravity Protocol is hiring!

See the previous articles

Gravity Protocol Intro
A Deeper Look Into Dan Larimer’s radio
Gravity Protocol initial distribution
Adaptive Emission: Making Blockchain Economy Real
Gravity IPFS: Off-chain Data Storage
Gravity: Ecosystem Participants
Gravity: Stablecoin Solutions
How the Gravity Protocol Team Implements a Security Development Lifecycle

Follow Us

Website: http://gravity.io
BitsharesTalk: https://bitsharestalk.org/index.php?board=122.0
BitcoinTalk: https://bitcointalk.org/index.php?topic=4189531.0
Telegram channel: https://t.me/gravityprotocol
Telegram dev chat: https://t.me/gravity_protocol
Blog: https://steemit.com/@gravity-protocol
Blog: https://medium.com/@gravityprotocol
Twitter: https://twitter.com/protocolgravity
Discord: https://discord.gg/bcavmUg
Linkedin: https://www.linkedin.com/company/gravity-foundation/