by SlowMist team
foreword
foreword
With the REX proposal finally voted by the BPs, REX, which has been speculated for half a year, is finally launched. This investment project known as a stable profit has attracted the attention of many people, and it has also occupied the headlines of major blockchain media. Its popularity is no less than that of platform currency, and a large amount of funds poured into it as soon as it went online. But what exactly is REX? Whats the use of REX? This series analyzes the source code of rex1.6.0-rc2 and gives relevant details and answers.
first level titleWhat is REX
Now there are many resource leasing DApps on the market, the purpose is also to alleviate the problem of CPU shortage. Like these platforms, REX acts as a leasing platform. The difference is that the resource lessor is no longer a DApp, but every EOS holder can become a resource lessor and enjoy the benefits. It is important to declare here that REX is not a token, but a resource leasing platform! The REX purchased by the user is just a pass that is circulated in the REX leasing platform to prove that the user has rented resources. This pass itself is not transferable and cannot be traded. Similar to national debt, REX is the bond in hand. In order to distinguish these two concepts, the REX resource leasing platform is collectively referred to as REX below. The token purchased by the user is called rex.
https://medium.com/@bytemaster/proposal-for-eos-resource-renting-rent-distribution-9afe8fb3883a
For more detailed information, please refer to BMs own article:
first level title
REX strategy
For general users, buying and selling rex only needs access to the following interfaces, namely:
Depodit: used for recharging, turning EOS into SEOS, also called reserve fund.
withdraw: use and withdraw, exchange SEOS back to EOS.
buyrex: It is used to deduct the corresponding share from the users reserve fund and use it for the purchase of rex.
unstaketorex: use the resources used in the mortgage for the purchase of rex.
Next, lets take a look at the implementation of these functions to understand the flow of funds.
first level title
deposit function
The deposit function is the first interface for users to participate in REX. As the name suggests, users recharge for later purchase of rex. Just like going to the game hall to recharge the game currency, first exchange the RMB into the game hall points and charge it into the card, and then use this card for subsequent games. All subsequent expenses are based on this card. The same is true for REX, and all subsequent buying and selling operations are based on this reserve account. The specific implementation of the deposit function is as follows:
We dont need to understand the specific implementation of each line, but the general truth needs to be understood. The deposit function does the following:
1. First of all, the user authority is verified on the third line. You cant let others buy rex for you for no reason, bypassing your own will.
2. Verify the purchase amount and token information on the fifth and sixth lines. You cannot buy fake EOS or buy a negative number to ensure the security of REX.
4. Call the transfer_to_fund interface to record the users recharge amount in a small notebook. This is equivalent to our reserve wallet. In terms of data, it is a table, and subsequent purchases of rex will be made based on this table.
5. Call the update_rex_account interface. This interface has different functions when different parameters are input. Here it is used to process the users sell order and organize the users income from selling rex into the reserve account.
first level title
The withdraw function is the reverse interface of the deposit function, which is used to transfer the balance in the reserve account to the users EOS account, just like you have played enough in the game hall, and you still have points in the card, or you can win points by playing games. After entering the card, you can use the points in the card to exchange for RMB. Next time, the principle of the withdraw function is the same. The specific implementation of the withdraw function is as follows:
Roughly the same as the deposit function, the withdraw function also checks the information of EOS tokens. Unlike the deposit function, the order in which the withdraw function calls the update_rex_account interface and transfer_from_fund interface is different from the deposit function. But the purpose is to process the users rex sell order and attribute the proceeds to the reserve account. They are used for cash withdrawal or purchase of rex respectively. The detailed detailed analysis here will be placed in a follow-up article.
first level title
After tossing and tossing for so long, after reading how to recharge and how to withdraw cash, the next question we are most concerned about is how to buy. The interface called by buyrex is the buyrex function, and the specific implementation of the function is as follows:
Like the previous two functions, the buyrex function also verifies the relevant information of the token, and then uses the transfer_from_fund function to deduct the corresponding amount from the users reserve. In addition, we should also pay attention to three other functions, namely check_voting_requirement, add_to_rex_pool and add_to_rex_balance. These three functions are used to check whether the user voted, calculate the number of rex that can be purchased and add the correspondingly increased number of rex to the rexpool, record the rex information purchased by the user, and calculate the unlocking time of the rex purchased by the user. So, how is the number of rex we can get calculated? From the source code, we can see that the add_to_rex_pool function is called to calculate the number of rex. Therefore, the following will focus on the analysis of the add_to_rex_pool function.
first level title
add_to_rex_pool function
1、total_lent：The add_to_rex_pool function is used to put the rex purchased by the user into rex_pool, and calculate the number of rex that the user can purchase according to the relevant information in rex_pool. First, lets look at the definition of the rex_pool table
2、total_unlent：The above is the definition of the rex_pool table, which defines 8 fields, except the version parameter, we explain the meaning of each parameter one by one
3、total_rent：It is used to record how many cpu resources and net resources have been lent in total, and the resource is in EOS.
4、total_lenable：Record the EOS resources not used for lending in rex_pool. Including the rental amount generated by the user for purchasing rex, and the rent of the user who rents the resource. One of them will lock the amount for renting resources (automatically unlocked after 30 days), which is a connector for bancor operations to calculate a certain amount of EOS rentable resources.
5、total_rex：It is used to record the rent paid by users when renting resources. It is a connector, which reflects the number of users who rent resources. It is used for bancor operation to calculate the rentable resources of a certain amount of EOS.
6、namebid_proceeds：It can be said to be all the funds of the entire rex_pool, and the calculation formula is total_unlent + total_lent. The source of funds here also includes the auction fee of name bid and ram fee. This parameter is also closely related to the users income.
7、loan_num：The total amount of rex in rex_pool comes from the user purchasing rex.
Record the fees incurred by the auction account.
Records the total number of times a resource was rented out.
After understanding the definition of the above fields, we now formally look at the add_to_rex_pool function. The following is the specific implementation of the function.
This ratio is fixed at 1:10000 without the interference of third-party funds such as account bidding fees, ram fees, etc. But when third-party funds enter the market, S0 as the denominator will continue to increase, then this ratio will continue to decrease, and the rex that can be bought with the same amount will become less and less. Through the above analysis, we know that with the participation of third-party funds, the earlier rex is bought, the more quantity can be bought. The price of rex has nothing to do with the number of purchasers, but with the number of leased resources, the revenue generated by the system bidding for resources, and ram fee.
sellrex function
first level title
sellrex function
So, now that the process has come to this point, all that remains is to calculate the benefits. The realization of the calculation details for dealing with the income generated by users renting out EOS resources is all in the sellrex function. The following is the specific implementation of the sellrex function.
This sellrex function has a lot of knowledge. It may not be possible to finish this short analysis, but it can analyze the issue we are most concerned about, that is, how the income obtained is calculated. First of all, regardless of other details, lets take a look at what has been done before actually calculating the benefits. It is mainly divided into the following steps:
1. Check whether the user has purchased rex, you can’t sell it without buying it, right?
3. Check whether the amount of rex that needs to be sold is less than the amount of locked REX.
fill_rex_order
first level title
Similarly, similar to add_to_rex_pool, we can also put aside other details and directly hit the core income calculation formula, that is, the calculation formula in line 6. (uint128_t(rex.amount) * S0) / R0, although this function looks equally complicated, we can simplify it in the same way. First, we convert the formula to rex.amount / R0 * S0, add parentheses to rex.amount * (R0 / S0), that is, the rex you can earn is the rex you want to sell multiplied by rex_pool The ratio between the total amount of rex and the total EOS assets in rex_pool remains stable at 10,000:1 without the addition of third-party funds such as name bid and ram fee.
first level title
I said a lot in one breath, and you may be a little bit at a loss when you see this, and you may just remember the conversion of the two formulas, it doesnt matter. Let me summarize the harvest after reading the article this time. Through the above analysis, we know that buying rex and selling rex are calculated according to the ratio between the total amount of rex and the total funds of EOS in rex_pool, that is to say, without the participation of third-party funds, the users EOS is always calculated according to The ratio of 1:10000 becomes rex, and then becomes EOS at the ratio of 10000:1. This shows that in the absence of third-party resources, rex and EOS are always interchangeable according to a certain ratio, which is why REX claims to be profitable without losing money. At the same time, when third-party funds enter the market, the ratio of R0 / S0 will become smaller, which also means that the ratio of S0 / R0 will become larger. Although the rex bought with the same funds will decrease, the sold The larger the ratio, the more benefits you get.
The entire participation process is roughly as follows:
first level title
REX security analysis
As the system contract of EOS itself, REXs security protection must be comprehensive. Once a problem occurs, it will have a catastrophic impact. The REX contract has been voluntarily audited by the EOS Authority team, but as a security officer, the author has also conducted in-depth thinking on the entire structure of REX. The article will successively analyze the interfaces mentioned in each article, and explain Its security or security enhancement recommendations.
This article briefly introduces four interfaces, namely deposit, withdraw, buyrex, and sellrex.
From the point of view of function implementation:
1. Each function checks the information of the asset parameters, including the quantity, and whether the symbol information of the token is consistent with the system token information. Prevent possible false recharge issues and overflow issues.
2. The users key operations have authority checks to prevent unauthorized operations.
At the same time, the four interfaces introduced in the article do not have common attack methods on EOS such as rollback attack, crowding out attack, and false notification attack.
https://eosauthority.com/blog/REX_progress_with_testing_and_implementation_details
The cause of the vulnerability is that the REX system may not have enough money to pay the users income during the sellrex operation. In this case, the users sell order will be suspended. If the order is not verified, the malicious user will be able to use it in the case of insufficient funds in the system. Next, the sellrex operation has been carried out, and the amount of the pending order has been increased until the system has enough resources to pay the users income.
epilogue
REX is a huge system, and it is not possible to analyze all the details in a few words. The article does not analyze too many technical details, but only roughly analyzes the general function of each function, and introduces the core of REX revenue. Friends who want to know the specific details can continue to pay attention to our series of articles ~ the next article will continue to explain more interesting details between these functions! There may be something wrong in the article, and everyone is welcome to point out and communicate.
statement
first level title
