Flip Taking #99
Replies: 4 comments 7 replies
-
|
My main feedback on this proposal is on the motivation/rational sections. The proposal mentions: "Anyone with a remote interest in Idena can now participate without significant investment of time and energy, thus lowering the barrier to entry and maintenance. With this change Idena will be inclusive of all people, not just to those with a hardcore commitment to the project. [...] The amount of individual time and effort required for Idena participation is extraordinarily high, which is mostly attributable to mandatory flip creation. Most people willing are either those that are super passionate in the technology and potential, and/or stakers that wish to profit from the system rewards. In either case, the high effort involved with mandatory flip creation significantly denudes the immense growth potential from people that are potentially interested in the technology and/or rewards, but are unwilling to invest the time and effort. Furthermore, the burden of flip creation is currently placed on people who are simply uninterested." If I understand correctly, the proposal aims to:
I would challenge assumption number 3 as I don't think that flip creation is what people see as the most demanding and time consuming activity. In my opinion, flip creation is magnitude less demanding and time consuming than attending the ceremony at a specific date and time. Hence, I don't think that making flips creation optional would remove a significant burden for potential participants who decide to not be involved because they see their participation as demanding too much of their time and efforts. In order to validate the assumption that flips creation would remove a significant burden to network participation, I would suggest to create an oracle polling current network participants on what they see as the most demanding and time consuming activities for their participation. |
Beta Was this translation helpful? Give feedback.
-
|
With regards to flip quality, this proposal focusses on experience of the flip creator, but does not prevent abuse - that would require a different iip which is out of the scope here. However, I think we could direct more of the generous flip rewards in this iip towards reporting rewards, this could definitely help. E.g. 51% flip rewards, 45% reporting rewards. If I were to create an oracle, I'd prefer to ask whether the community supports this proposal. Or asking a question that helps to amend this proposal in a way that improves it. Asking whether flip creating is painful or not is nonsensicle to me, because it's obviously a burden. And it is not just current users that should be considered, it is also new users or even lost users. I cannot imagine a future where Idena is mainstream and everyone is creating flips. Specialisation and optionality needs to happen for mainstream adoption. |
Beta Was this translation helpful? Give feedback.
-
|
I certainly can see your point when it comes to mainstream adoption and I agree that not everybody would find it "fun" to create flips. |
Beta Was this translation helpful? Give feedback.
-
|
I'm going to update the rewards distribution, 51% flip rewards, 45% reporting rewards. Thanks for your feedback Justin! |
Beta Was this translation helpful? Give feedback.
-
|
Of course! |
Beta Was this translation helpful? Give feedback.
-
|
If I had it my way, flip quality would have been solved long ago. But yeah, I think I may agree with you to an extent that flip quality may need to be prioritised. |
Beta Was this translation helpful? Give feedback.
-
|
Please note that the Specification was updated to include the "Taking time limit". |
Beta Was this translation helpful? Give feedback.
-
|
Please note a couple more updates to the Specification: 1) once a flip is taken, it may not be re-taken by another validator - it must be submitted. 2) during the flip lottery, a validator cannot be paired with another validator for whom they have taken flips from. |
Beta Was this translation helpful? Give feedback.
-
|
Please note another update, a validator will be penalised if having more than 2 reported flips for the last 10 epochs. |
Beta Was this translation helpful? Give feedback.
-
IIP: Flip Taking
Abstract
This proposal introduces the functionality of taking (un-submitted) flips from other users. This in effect makes flip submission optional for users who do not wish to participate, yet still wish to benefit from all other aspects of Idena. It also enables those that enjoy making quality flips to benefit from their efforts.
Motivation
A growing base of genuine users is needed for any project in its infancy. In fact, many businesses fail not because the idea was not world changing, but because the idea failed to gain traction. Idena is vulnerable with its current low market capitalisation for several reasons, but most notably the challenge to pay for development and operational costs, and furthermore potential investor may opt to fork the protocol any create their own coin, rather than buy into Idena. As such, significant traction is expected to provide the momentum to allay these threats, and moreover reach its potential for mass user adoption.
Flip quality is an essential component of Idena's security layer, which has been declining over time to the point that the network may be vulnerable to AI attack.
Here I introduce a significant protocol change to make flip creation optional (with conditions), thereby increasing the scalability and popularity of the network. Anyone with a remote interest in Idena can now participate without significant investment of time and energy, thus lowering the barrier to entry and maintenance. With this change Idena will be inclusive of all people, not just to those with a hardcore commitment to the project. This change also enables specialisation to occur with regards to flip making, for better overall flip quality and thus enahnced security.
Specification
Overview
In the beginning of each epoch, a validator has a quota of 3 required flips in order to be validated for the next epoch. This requirement is maintained with this proposal, however the quota of un-submitted flips can be reduced by other validated identities “taking” them. More specifically, when a validator has submitted all of their own required flips, they are then provided with the option to take an additional flip from someone else’s required flip quota. When selecting this option, the protocol will find a random validator with remaining quota and essentially take it. Over epoch time, this process results in all flip creation being completely taken from those validators that either opted to not submit any flips, or placed no effort into submitting their flips in a timely manner.
There are certain rules surrounding this process, such as a maximum number of flips that can be taken by any particular validator, the rate at which they can be taken, and the priority of which validators have their flips taken from them. Furthermore, changes to the protocol incentives and rules are updated to accommodate this new functionality.
Change in Validation Rewards
Current random sampling indicates that a very low number of validators utilise their “optional” flips (~10% of validators), meaning current flip rewards are insufficient to motivate validators to do any more than what is required. As such, greater flip rewards are needed.
The flip rewards will be raised to 51% of validation rewards. Moreover, flip reporting rewards will be raised from 15% to 45% to incentivize good flip reporting. These reward changes will be accomodated by removal of the following validation rewards:
Staking rewards (18%). These rewards are redundant now that staked mining rewards have been implemented.
Invitation rewards (18%). These rewards are an absurdity, people are motivated to invite family/friends for reasons other than receiving a transactional reward.
Idena foundation payouts (10%). These rewards are redundant because the Foundation Wallet has already accumulated ~1,366,000 iDNA, and the Zero Wallet continues to accumulate iDNA.
Removal of Optional Flips
Optional flips (as currently implemented) for both verified and human status, are now inconsistent with this proposal – flips are either required or taken.
Taking Priority Schedule
Available flips are taken from other validators via the Taking Priority Schedule (See Table 1). More specifically, available flips are taken from the first priority level until no more are available, then taken from the second priority level, and so forth. Within each priority level, available flips are taken randomly. Validators may elect for their flips to be prioritised for taking, resulting in that validator rising in priority level. By default, election is turned on and validators must turn off to de-prioritise their flips.
Table 1: Taking Priority Schedule.
Priority Level
Status
Age
Elected
1
Newbie
1
Yes
2
Verified
2
Yes
3
Verified
3
Yes
4
Human
4
Yes
5
Human
5
Yes
6
Human
6
Yes
7
Human
7
Yes
8
Human
8
Yes
9
Human
9
Yes
10
Human
10+
Yes
11
Newbie
1
No
12
Verified
2
No
13
Verified
3
No
14
Human
4
No
15
Human
5
No
16
Human
6
No
17
Human
7
No
18
Human
8
No
19
Human
9
No
20
Human
10+
No
Flip taking
When a non-newbie validator has submitted all of their required flips, they are then eligible to take a flip. When a flip is taken, a flip taking transaction is created with reference of the event for storage on the blockchain. The validator from which the flip was taken (the giver), no longer has this required flip available to them. And the receiving validator (the taker) now has an added required flip, which must be submitted either prior the next validation, or prior to taking another flip. Note that once a flip is taken, it may not be re-taken by another validator - it must be submitted.
The keywords used for the taken flip are generated by the taker. By default, the 9 default keywords first generated by a validator occupy the first 9 determinant keywords (1..9), which are used with the first 3 submitted flips. For the next 3 flips submitted, i.e. for taken flips, the validator will generate the next 9 determinant keywords (10..18), and so on.
Come the validation ceremony, the flip lottery proceeds as per normal as if no flips been taken from anyone, with one caveat which is a validator cannot be paired with another validator for whom they have taken flips from. Blockchain pointers (flip taking transactions) are utilised to locate the true flip creator and flip, for gathering the images, keywords, and correctly distributing rewards/penalties for that flip.
The maximum number of flip takes
It takes time and practice for a validator to become a skilled flip creator. As such, limits will be placed for the maximum number of flips that a user can create in order to ensure overall network flip quality, and also to prevent abuse. More specifically, for each successful validation, a validator will have their maximum flip submissions raised by 3 (See Table 2). Moreover, a hard upper limit of 30 flips per validator is designed to maintain decentralisation. Note that with this proposal, validators can be penalised for unqualified/reported flips, which will reduce their maximum flip submissions (more details below).
Table 2: Typical validator maximum flip submissions.
Status
Age
Maximum flip submissions
Candidate
0
0
Newbie
1
3
Verified
2
6
Verified
3
9
Human
4
12
Human
5
15
Human
6
18
Human
7
21
Human
8
24
Human
9
27
Human
10+
30
Unqualified/Reported flip penalties
Because a validator can create many more flips, they can do more harm to the network via intentional (or unintentional) shitflips – as such, penalisations are required. Specifically, a validators’ qualified flip creation score for any given epoch should be 60% or more. A validators’ total qualified flip creation score for the last 10 epochs should be 75% or more. Further, a validator cannot have more than 2 reported flips for the last 10 epochs. If any of these thresholds are unmet, the validator loses their validated status and has their maximum flip submissions reduced back to 0 (Candidate level).
Reduced flip submission rate
The flip submission rate per validator will be set to a maximum of 3 flips per hour. This is designed to provide all other validators with sufficient time to create their own flips, and not having them taken prior to them having the chance to submit them. It is also designed to prevent too many transactions happening in one go at the beginning of the next epoch.
Note that an intentional design of this proposal is to disallow users from preventing their flips from being taken. If users could prevent their flips from being taken and they subsequently fail to submit their flips, this would decrease the number of flips in the network and jeopardise the optionality of flip creation for everyone else. If validator wish to guarantee that their flip is not taken, then they should put effort into submitting early in the epoch.
Taking time limit
In order to provide validators with certainty about whether or not they have required flips to create and submit, flip taking is time limited to the first half of the epoch. With this limitation, a validator that can now check half way through the epoch and know for certain if they will be required to make any flips. It also provides ample time for these required flips to be created and submitted.
Rationale
The amount of individual time and effort required for Idena participation is extraordinarily high, which is mostly attributable to mandatory flip creation. Most people willing are either those that are super passionate in the technology and potential, and/or stakers that wish to profit from the system rewards. In either case, the high effort involved with mandatory flip creation significantly denudes the immense growth potential from people that are potentially interested in the technology and/or rewards, but are unwilling to invest the time and effort. Furthermore, the burden of flip creation is currently placed on people who are simply uninterested.
The proposal herein provides aligned incentives for two new critical target groups of users, making Idena an attractive value proposition expected to result in immense growth of the network. The first group are users who can earn significant rewards by creating flips, and are rewarded directly proportional to the time and effort provided. The second group and by far the largest, are ordinary users that have an interest in Idena, and can now participate without the associated burden.
The key benefits of this change is to improve the quality of flips produced by specialised workers, and to expand Idena participation, which is expected to increase:
conversion of participants into investors, miners, word of mouth promoters.
eyeballs for Idena advertisements.
interest from third-party applications for using Idena Sign-In, and Idena Advertising (if third-party platform revenues are enabled).
interest from Web3 and DAO developers (for when iwasm is enabled).
It also provides a pathway for flip creators to earn iDNA for participation in staked mining rewards.
Backward Compatibility
This change requires a hard fork.
Security Considerations
Flip production will have increased concentration and can lead to power concentration. This is mitigated by introducing maximum flip submissions.
Competitiveness to take flips is introduced which can disrupt a good user experience. This is mitigated by introducing a reduced flip submission rate.
Inconsistent user requirements may arise if in some epochs flip submission was not required, yet in other epochs submission was required. To mitigate this, flip rewards have been significantly maximised so that users shouldn’t ever have to submit flips, and furthermore flips cannot be protected from taking, thus ensuring maximal flip production from those that want to submit.
Beta Was this translation helpful? Give feedback.
All reactions