Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
REX Implementation #117
This issue describes the EOSIO resource exchange (REX) implementation details. For the mathematical details of the Bancor algorithm used in REX, please see this article. In the following, we use
User REX funds
For REX related actions, a user needs to create a REX fund and deposit SYS tokens into the fund.
REX pool balances
REX pool represents the global state of the REX system. It comprises multiple balances:
Buying REX with liquid tokens
As the name suggests, the action
Buying REX with staked tokens
A user can buy REX using staked tokens, without the need for unstaking to liquid tokens first, via
A delay is imposed on selling REX tokens after they're purchased. Tokens bought cannot be sold until
REX savings bucket
In addition to maturity buckets described above, a REX owner can utilize a special bucket which we call the "savings bucket". REX held in this bucket does not mature and cannot be sold directly. Users can move already purchased REX from other buckets to their savings bucket at will using the action
Processing REX sell orders
A user can rent CPU and Network resources on behalf of a
Loan automatic renewal
In most REX actions, the function
In order to buy REX, an account must have voted for at least 21 producers or delegated their vote to a proxy. As long as an account holds any REX tokens, the condition must be satisfied.
Is anyone at Block One or anyone else at all who has worked on REX willing to go on the record either here in this issue or on the REX pull request and say in unambiguous terms whether this issue is in scope or out of scope to be addressed in REX:
Thank you for clearing up the current stance on gaming access to REX via a proxy @zorba80
For my own understanding I'm trying to succinctly summarize from the REX pool balances and Processing REX sell orders stories above how rewards are calculated when the
REX pool balances advises that the REX current exchange price is calculated as
It would appear that the actual rewards / proceeds calculation is performed here: https://github.com/EOSIO/eosio.contracts/blob/rex-2/eosio.system/src/rex.cpp#L499-L503
To recap, I would say that the rewards calculated at
Would you agree that this is a fair and accurate summary of how rewards will be calculated for a user selling REX tokens with the REX feature as it stands today ?
@gleehokie your link to #91 (comment) identifies the one and only change that can work to fix the REX proxy loophole; proxy accounts having the ability to vote for low BP counts is a general EOSIO platform weakness and it just so happens that REX further highlights this weakness because it undermines one of the original measures of success for REX in no uncertain terms: the goal of improving voting engagement.
Ignoring this issue with the hope that the bar to create a proxy account to game access to REX is a bar too high for most to follow and that the system as it stands is "good enough" is naive and an irresponsible stance in my opinion.
I honestly don't want to turn this issue into a governance discussion but there's no escaping the fact that EOSIO is a blockchain with governance. Platform base layer governance exists to support the business rules built into EOSIO code and in symbiotic fashion the business rules built into the EOSIO code support platform base layer governance.
It's at times like these when a gap is identified that undermines the ability for that symbiotic governance <-> platform relationship to successfully work, the responsible and reasonable thing to do is to close that gap to strengthen the platform overall.
If we were to talk about the nuts and bolts of what's really needed to close this gap,
This change would reasonably work if it was undertaken and it is also a responsible change when considering the overall health and well being of the platform.
The questions that remain unanswered are whether block one is wiling to concede that proxy accounts having the ability to vote for low BP counts is a general EOSIO platform weakness and whether block one is willing to address this gap with a code fix or not.
I think the requirement to vote for a minimum of 21 producers in order to use REX should be removed. There should be a requirement to vote, but not for how many. Trying to control voter behavior is not good practice. Let me explain myself.
Currently, the requirement allegedly accomplishes 2 things:
(1) is accomplished without the requirement to vote for at least 21. All we need is just a requirement to vote.
The problem I see with (2) is that it is too easy to circumvent even without the proxy problem. Users can vote for irrelevant candidates (ones that have too few votes). It's very easy to create new candidates. Furthermore, this requirement creates an incentive for strategic voting.
All of this is not good IMO because when a system rule can be circumvented too easily, what happens is that honest users follow the rule and dishonest users circumvent it. So it can be said that the system gives an edge to dishonest users, which also means that it will attract dishonest users. Ideally, I think we want to build an environment that attracts more honest users.
This is just my opinion on the matter, and I understand it is debatable. However, if in the end we decide that voting for a minimum of 21 is a good system rule, why not implement it as a general requirement to voting, not just REX? To me, this seems like a patch that doesn't address the problem at its core.
What is the problem at its core then?
@jjssoftware should users not be allowed to vote as they see fit? Please expand on why you think proxy accounts (in particular) voting for low BP counts is a problem.
I find your question perplexing @gleehokie:
Perhaps you need to have a word with @bytemaster Daniel Larimer to ask him why the original REX proposal stated:
If voting for at least 21 block producers in the context of REX makes no sense to you, have a think about crusading for that requirement to be completely removed. One thing is certain: in the context of REX, allowing a user to vote for i.e. 1 BP via a proxy and also be rewarded for doing so goes directly against whatever original goal this requirement has.
I can offer an opinion why I believe that voting for a low number of BPs poses potential problems; it is healthy account voting behaviour to vote for a wide spread of block producers rather than voting for a small number of block producers because voting for many BPs promotes diversity in BP specialty skills and geographical decentralization.
Putting REX to one side, allowing proxies to vote for i.e. 1 BP is a general platform voter engagement weakening problem because in the worst case scenario, it promotes BP centralization by concentrating / funneling the voting power of many accounts to 1 BP. REX simply highlights this weakness further by not only continuing to allow it, but REX will also reward accounts for doing it.
Update on REX Development
Release Blocking Concerns
Initial Market State and Bootstrapping
Prior to the proper functioning of a Bancor market, initial values for the pools at either side of a connector must be initialized. Generally, this can be accomplished in a few ways but after review the most promising are:
While the bidding process is potentially more accurate, it is also requires a far more complex launch ceremony. As such, initial development will not support this option. This leaves initial “virtual” balances as the preferred method of bootstrapping a new instantiation of the REX.
In order to provide better documentation to future REX operators, some analysis will occur such that general guidelines for determining initial “virtual” balances is available.
Resilience To Market Resets
In concert with bootstrapping concerns, there are still outstanding features which will attempt to prevent a complete reset of the market except in the rare event of all owners deciding to sell their REX shares. This will likely take the form of a “minimum”ratio of balances in the Bancor pools under which various measures, like delaying withdrawals, will exist to maintain a stable market maker and prevent the market from returning abruptly to its initial state.
Buying REX with staked tokens
The current implementation in GitHub requires liquid tokens in an internal REX balance prior to processing a
As a result, prior to release, a path for participation in the REX will be added which maintains voter influence during the transition. The exact form of this interaction is in development and will be announced as soon as it satisfies the requirements stated above as well as the requirements of staked token management necessary to prevent resource exploits.
REX Maturity and Testing
In order to prevent possible price manipulation, the concept of maturity is being added to REX purchases. This does not affect the rewards for buying REX but will act as a vesting period over which newly purchased REX cannot be sold. Once outside this time period the given REX tokens can be sold at will. The REX maturity period is now implemented and currently set to 4 days. This value was chosen such that it is longer than the normal resource unstaking period and provides the market adequate time to react. Feedback on the time period is welcome.
Updates on Existing Features
“Toggle” for Additional Fees
In earlier discussions, the deposit of fees generated from other system level functions was contentious and it was stated that there would be a toggle for those fees prior to release. After analysis, it was determined that the best practice was not to provide a soft-switch which would impose RAM and CPU overhead during chain operations. Instead, operators who wish to deploy the REX without those inputs will have clear instructions on how to remove the code, prior to compilation of the contract, so that the deployed contracts are as lean as possible. The code currently in GitHub has been modified to support this removal, if desired, as cleanly as possible.
One of the goals of the REX is to increase voter participation on a public EOSIO-based blockchain. To achieve this goal, an invariant was established such that participants in the REX needed to EITHER vote for at least 21 block producer candidates OR delegate their voting influence to a registered proxy.
Discussions in the interim have questioned whether this invariant was sufficient to affect a number of different nuanced states in the general voting game-theory. After analysis, the development team has concluded that the current rules are sufficient to at least affect voter apathy. By requiring participants to overcome the initial barriers of entry, the expectation is that the REX will increase voter participation.
Qualitative expectations, such as increasing informed-voter participation OR decreasing active voters with malicious intent, is beyond the scope of a software process such as the REX as the ability to judge these qualities in a voter’s participation is outside of the scope and mandate of the reference system contracts for public EOSIO-based blockchains.
The development team respectfully requests that further discussion on this very contentious topic focus on a more measurable goal of decreasing voter apathy.
how does users can inquire that how many CPU/NET do they rent from REX? there is no api or something else,right?
but on testnet or main-net in the fututre,there will be many accounts info,how can you filter your appointed account info?