Storichain Tokeneconomy simulation first result based on ABMS, 2019.1.2.
Agent Based Modeling and Simulation
Table of Contents
1. Overview2. The desired result
3. Scenario
4. Internal operation method
5. Results of analysis
6. Limits and future plans
1. Overview
Task name: Verifies the stability of the ecosystem of Storichain (Dapp project) through ABMS simulation
Task period: 1st November 2018 to 31st December 2018
Sub-task: 2 years compensation pool variability is identified and utilized in token flow policy
Simulation environment:
- Tool: Repast Symphony 2.6
- OS: MacOS 10.13.6, Window 10
2. The desired result
Through the simulation, the following results were checked:
First, find a point where the token fluctuates rapidly
Second, finding a distribution policy that focuses on a specific participant
Third, over time, the company will reduce compensation from EcoPool and increase the proportion of investments made by PD Agent.
3. Scenario
Participating object: ST (writer), PD (producer), RD (reader), Story
Major scenario (relational formation)
1) The relationship between the four objects above is formed through Story.
2) ST and ST are connected only when working together (current code can only be co-worked with two people)
3) ST is related when Story is created (up to 10 stories can be created)
4) If ST has more than a certain number of Story typing, the corresponding indicator will rise.
5) When ST creates a new scene in the Story, the figure of the indicator rises.
6) Relevance is formed when the PD invests in the Story and investment is made only when the product characteristics of the Story are included within the PD’s desire range.
7) The PD will have a valid value in the Story if the Story participates in the validation.
8) When PD participates in the branching of Story, the branch level rises in Story.
9) Relationship is formed when RD reacts to Story. Reaction takes place only when the product characteristics of Story are within the range of RD’s needs.
10) If RD reads Story, the corresponding figure goes up.
11) When RD shares the Story, the corresponding figure is raised.
4. Internal operation method
The class diagram explains how objects are designed first, and only the parts that need to be explained during the internal logic are briefly described.
4.1 클래스 다이어그램
Parameters
Classes that manage initial settings
SimulationBuilder
ABMS simulation main class initializes all other classes here.
EntreNetworkGenerator
As a class that oversees agent-to-agent relationship settings, call corresponding classes according to the conditions set by Parameter.
AdjacentNetworkGenerator
This class finds and connects agent-to-agent relationships on adjacent nodes
RandomNetworkGenerator
When establishing relationships between agents, select randomly selected agent to connect.
BarabasiAlbertNetworkGenerator
When establishing relationships between agents, select the larger cluster of agent to connect.(Choose good background)
Agent
have a common function as the parent object of a major object
PD
As a producer object, it serves as an investment and validation of the story.
RD
As a reader (RD) object, it plays a role in responding to stories
ST
Create a story and collaborate as a writer (ST) object.
Story
An object that acts as a center between agents, and other objects are connected through Story object.
GrowthSchedule
The class that evaluates Story Growth Index (GI) operates on an independent schedule.
4.2 Key Operating Methods
Repast Symphony is an agent-based simulation tool. Simulate the desired objects (agents) and assign an independent schedule. The portion of the code that assigns a schedule to each object (agent) is implemented as follows in SimulBuilder class.
public void scheduleActions() {
ISchedule schedule =
repast.simphony.engine.environment.RunEnvironment.getInstance().getCurrentSchedule();
ScheduleParameters parameters = ScheduleParameters.createRepeating(10,Parameters.adaptationSpeed+3, 9);
schedule.scheduleIterable(parameters, pdList, “doPDaction”, true);
// call PD schedule
parameters = ScheduleParameters.createRepeating(2,Parameters.adaptationSpeed+17, 8);
schedule.scheduleIterable(parameters, stList, “doSTaction”, true);
// call ST schedule
parameters =
ScheduleParameters.createRepeating(2, Parameters.adaptationSpeed+9, 8);
schedule.scheduleIterable(parameters, rdList, “doRDaction”, true);
// call RD schedule
}
SimulBuidler.java
Schedule is a function that is continuously invoked under independently defined conditions. Set Interval, Priority, and Start for the call condition. In the above code, the parameters set the initial conditions and pass them to the schedule. The schedule of each agent continues to rotate and the object generates data. Our interest is tokens data, which assumes about two years of operation and collects data.
5. Results of analysis
Illustrates how agents (PD, ST, RD, and Story) behave. The blue circle represents PD. An orange square represents an RD. The light green star type represents the author of ST. At the end, the sky blue cross represents Story. The current capture screen above is a picture since 1400 Ticks was created by ST (60), RD (166), PD (45), and Story (106).
Two years have passed since we reached 1400 Tick Count.
Early EcoPool was set to 1,000 token.
Two years later, token inflation was roughly half the rate.
Let’s contrast it with the results we wanted.
First, find a point where the token fluctuates rapidly
After the 550 Tick count, the rate of token benefit increases significantly that of PD than that of the author (ST). It seems that it is because of inflation as many co-authors as it is now.
Second, finding a distribution policy that focuses on a specific participant
This is the same as above. After 1,300 Ticks, the PD’s tokens show a gradual decrease. This means that there is less compensation than investment, but you will know what it means by watching it for a longer.
Third, over time, the company will reduce compensation from EcoPool and increase the proportion of investments made by PD.
The task of adjusting token inflation to a low level is needed, depending on the number of times or agents increasing.
Width is the tick count, and Legnth represents the total token amount. The formula represents a tertiary trend line. The red trend line reflects 99 percent of it.
Width is a tick count, and length represents the total token amount of the PD. The formula represents a tertiary trend line. It shows that the red trend line reflects 97%.
Width is the tick count, and length represents the total token amount of ST. The formula represents a tertiary trend line. It shows that the red trend line reflects 98% of it
6. Limits and future plans
The main threshold was the inability to apply network theory, which is often used to determine the cause of the relationship center, between objects. Through the graph, the network theory, a relationship model used primarily in social science and computer science, assumes a one-to-one relationship with no differences between objects. However, in this study, network theories such as connection centrality, eigenvector centrality, mediated centrality, harmonic centrality, and proximity centrality could not be applied as they were because of the different characteristics between objects.
Token simulations can identify future trends. Token trend analysis can also create the desired trend direction. However, it is necessary to consider how to reduce the difference between the actual DApp by simply setting the major compensation rate (GrowthIndex) without considering the weight. In the future, we intend to reduce the actual Dapp and simulation errors by developing the Dapp by incorporating the major token policies into ABMS simulation model in detail. By reducing errors, it will be possible to implement a token flow policy with predictions. In the future, the portion of the variation in the simulation will be updated continuously through this page.
