Details on the Smart Contract Ranking Algorithm Part 2
Analysis of Actual Situation
1. A normal buyer or seller
For a normal buyer or seller, there will only be records of transfers-out or transfers-in the transaction network. For example, the seller delivers the goods to the buyer offline, and the buyer pays a certain amount of NAS to the seller on the Nebulas chain. We believe that these users connect the online and offline parts of the Nebulas chain. Because they contribute to the network, so we give them “devotion” scores. Derived from the calculation formula, when transfer-in or transfer-out equals 0, the value of R_v increases slowly with the increase of “in” or “out”, and there is a certain upper limit to R_v.
2. Accounts with lots of wealth without transactions
For accounts with lots of wealth but no transactions, we view that they do not actually use the transaction network. In other words, both in and out are 0, so their contribution is 0. As a result, the score given by the ranking algorithm is 0.
3. Exchanges with a large number of transfer records
For an exchange, it will hold a certain amount of balance and a large number of transfer records at the same time. Generally speaking, it achieve a balance between in and out within a certain period of time. As a result, Nebulas will give it the largest ranking score.
Cheating？
The importance of accounts will directly affect the ranking of smart contracts, thus affecting the profits of users in this activity. As a result, cheating is inevitable.
In this activity, we have increased the cost of cheating to some extent, but we can’t completely prevent cheating. We prefer to think about cheating from another angle. First of all, we assume that the users owning the accounts are rational. In other words, they always want to make profits, rather than be cheaters without caring about the returns. If a user tries to cheat, he needs to spend a lot of time and money. However if he can’t get any return, we think that these users will not exist for a long time. The short-term opportunism of these adverse users will not affect the overall fairness. Secondly, from the perspective of game theory, we believe that in a certain degree, the cheater’s behavior may contribute to continual improvement of the Nebulas, just like the relationship between search engines and optimization techniques for search engines (Google vs SEO).
What happens if a user tries to cheat? At first, it is necessary for him to create a large number of account addresses and conduct transfer transactions between the addresses. Then he needs to use these account addresses to call the smart contract created by him. To simplify the discussion, let’s assume that a user has 1000 NAS, and that the user can try to create 2 accounts, with 500 nas for each account. After creating the accounts, he will transfer money between two accounts, and use both the accounts to invoke the corresponding smart contract. Similarly, the user can create 4 accounts, 10 accounts and even 1000 accounts. For the convenience of calculation, we can assume that the values of a, b, c, d, \ mu, \ lambda above are all 1, therefore, we can calculate the final scores of this smart contract as follows:
As we expected, when users create more accounts, they can effectively improve the scores of smart contracts. However, what if we adjust the values of various parameters? For example, a = 10, b = 1000, c = 1, d = 1, \ mu = 1, \ lambda = 1. This time, the scores of the smart contract is as follows:
As we can see, with the increase of the number of accounts created by users, the score of smart contracts has a decreasing trend. That is to say, with some appropriate parameters and under the premise that the number of NAS held by users is limited, the profits obtained by creating trumpets and sharing NAS among these trumpets are shown in the following figure:
That is to say, creating trumpets recklessly cannot largely increase profits. As a result, under the condition that each of the parameter is known, users will choose to cheat moderately, thus ensuring the fairness of the whole system
Furthermore, the adjustment of each parameter is determined according to the actual situation. Suppose that the user is unaware of the parameter, it is risky for users to practice frauds. For example, with another set of parameters ( b is adjusted to 100000 ), a = 10, b = 100000, c = 1, d = 1, \ mu = 1, \ lambda = 1, the score of this smart contract is as follows:
By comparison, it is easy to find that when b = 1, the best policy for users is to create 1000 accounts, while the best policy is to create 20 ~ 100 accounts for b = 1000, and 4 accounts for b = 100000. Without knowing the specific parameters, it is risky to create more accounts rashly to improve the final score of smart contracts. As an example, consider that the user has created four accounts. At the moment, as he doesn’t know the specific parameters, he can’t judge whether it is wise to create more accounts to improve the final score. If he creates more accounts blindly, it may lead to the decline of his final score.
To sum up, we believe that users are likely to cheat, but cheating will be very moderate, which will not affect the fairness of the whole activity. Another question is that why do we allow users to create trumpets moderately instead of guaranteeing absolute fairness? On the one hand, moderate cheating can increase the enjoyment and challenge of the activity. On the other hand, it provides a test — and thus signals for means to improve — for the Nebulas mainnet.
Finally, in order to enhance the interest of this activity, we will announce the parameters used in the first week before the first week activity begins. Please stay tuned. As for the parameters in the following activities, whether or not they will be published will be determined later.
parameters
a = 2000.0
b = 200000.0
c = 100.0
d = 1000.0
μ = 0.75
λ = 3.14
Learn more about Nebulas:
Official website: Nebulas.io
Github: github.com/nebulasio/go-nebulas
Slack: nebulasio.herokuapp.com
Telegram(EN): t.me/nebulasio
Twitter: @nebulasio
