Teams - Phase 1 #861
Teams - Phase 1 #861
Conversation
| // Used for coordinating "Teams", equivalent to delegation | ||
| // Teams are groups which engage in work. | ||
| // some of that work is automated such as validation. | ||
| // A Team has a collective "consensus weight", which is used for voting in consensus |
There was a problem hiding this comment.
know it might be late but just a thought: should we use consensus weight only for being in top 100 and consider all teams to be equal consensus weight. theoretically there is a probability of malicious node having higher consensus weight
There was a problem hiding this comment.
This is interesting. Something for @zmanian
There was a problem hiding this comment.
@sm86 Can you ticket this as an idea to research in Issues, for Phase 2?
|
|
||
| // bob wants to switch to a different Team. | ||
| if (exists<Member>(addr)) { | ||
| let member_state = borrow_global_mut<Member>(addr); |
There was a problem hiding this comment.
Need to check if the account is in the member list of the old team and if so, remove them
There was a problem hiding this comment.
good catch, working on it.
There was a problem hiding this comment.
fixed with 7dd61b6
Added switch_team private function.
Includes the switch_team.move test in functional test.
There was a problem hiding this comment.
I think switch_team would allow a user to be added a team without having first met the mining threshold that is enforced is maybe_activate_member _to_team. Perhaps maybe_switch_team should call maybe_activate_member_to_team in order to prevent this?
There was a problem hiding this comment.
@jamesmeijers please check, I refactored as you suggested. See: 5688b6a
| // needs to check if this is a slow wallet. | ||
| // ask user to resubmit if not a slow wallet, so they are explicitly setting it, no surprises, no tears. | ||
|
|
||
| assert(DiemAccount::is_slow(addr), ENOT_SLOW_WALLET); |
There was a problem hiding this comment.
It might be a good idea to wait at least 1 epoch for a new team be able to receive new members because it creates anticipation for Carpe users, who can see new captains donation plans, and avoids validators to create their teams with few members near by the end of an epoch.
Implements delegation for consensus. Makes Carpe mining part of the security model, turning validators into DAOs