ERC: µTopic Delegation #2502
ERC: µTopic Delegation #2502
Conversation
|
There has been no activity on this pull request for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review. |
|
Yes, I would like to move forward this EIP. |
| A common trust network for ethereum. | ||
|
|
||
| A general purpose hierarchy of delegations which can divided into micro topics. |
There was a problem hiding this comment.
| A common trust network for ethereum. | |
| A general purpose hierarchy of delegations which can divided into micro topics. | |
| A general purpose hierarchy of delegations which can divided into micro topics. |
Simple Summary should be akin to an email subject line, forum thread title, GitHub Pull Request title line, etc.
| When "everything" becomes DAOable, it could become a problem to keep track of all the micro DAOs. Just like ERC20 have an allowance for other address spent on their behalf, | ||
| Cold wallets usually don't want to be unlocked very often to be able to vote. | ||
| Users might want to trust all their DAOs to other address for vote for them. | ||
| A group of people want to trust each other to vote in topics. | ||
| DAOs might want to inherit the _root_ delegate of users for their own _topic_, where users could define a specific delegate.. |
There was a problem hiding this comment.
| When "everything" becomes DAOable, it could become a problem to keep track of all the micro DAOs. Just like ERC20 have an allowance for other address spent on their behalf, | |
| Cold wallets usually don't want to be unlocked very often to be able to vote. | |
| Users might want to trust all their DAOs to other address for vote for them. | |
| A group of people want to trust each other to vote in topics. | |
| DAOs might want to inherit the _root_ delegate of users for their own _topic_, where users could define a specific delegate.. |
This all sounds like great content for the Motivation section, but not really appropriate for the Abstract section. The abstract should be a human readable form of the specification. Someone should be able to read the abstract and get the gist of the specification itself. Someone should be able to read the motivation section and get an idea of why someone may want to implement this specification.
| ```plantuml | ||
| @startuml | ||
| :A: -> :A: | ||
| @enduml | ||
| ``` |
There was a problem hiding this comment.
We should find out if UML is supported in all of the places this is rendered. GitHub, EIPs site, anywhere else? If not, then this syntax likely is going to be more confusing than helpful.
|
|
||
| ### Influence flow | ||
|
|
||
| The delegate which gets the influence is the first on the chain that vote, in the example above, if only `E` voted, it would accumulate the influence of all others and itself, `A,B,C,D,E,F,G,I`, while if `D` and `G` voted, then `D` would be able to claim influence of `A,B,I,C,D`, while `G` would claim from `E,F,H,G`. |
There was a problem hiding this comment.
| The delegate which gets the influence is the first on the chain that vote, in the example above, if only `E` voted, it would accumulate the influence of all others and itself, `A,B,C,D,E,F,G,I`, while if `D` and `G` voted, then `D` would be able to claim influence of `A,B,I,C,D`, while `G` would claim from `E,F,H,G`. | |
| The delegate which gets the influence is the first on the chain that vote, in the example above, if only `E` voted, it would accumulate the influence of all others and itself, `A,B,C,D,E,F,G,H,I`, while if `D` and `G` voted, then `D` would be able to claim influence of `A,B,I,C,D`, while `G` would claim from `E,F,H,G`. |
| /** | ||
| * @author Ricardo Guilherme Schmidt (Status Research & Development GmbH) | ||
| */ |
There was a problem hiding this comment.
Since everything in the EIPs repository is CC0, attribution is not required and just adds noise to the interface. Recommend removing.
Also, we are trying to minimize people using EIPs as a form of advertising their product/company, and one strategy to assist with that is strongly discouraging/disallowing people linking externally or referencing external products/businesses.
| /** | ||
| * @author Ricardo Guilherme Schmidt (Status Research & Development GmbH) | ||
| */ |
There was a problem hiding this comment.
Same suggestion as above.
| */ | ||
| function delegatedTo(address _who) | ||
| external | ||
| view | ||
| returns (address) | ||
| { | ||
| return findDelegatedToAt(_who, block.number); | ||
| } | ||
|
|
||
| /** | ||
| * @notice Reads `_who` configured delegation at block number `_block` in this level, | ||
| * or from parent level if `_who` never defined/defined to parent address. | ||
| * @param _who What address to lookup. | ||
| * @param _block Block number of what height in history. | ||
| * @return The address `_who` chosen delegate to. | ||
| */ | ||
| function delegatedToAt( | ||
| address _who, | ||
| uint _block | ||
| ) | ||
| external | ||
| view | ||
| returns (address directDelegate) | ||
| { | ||
| return findDelegatedToAt(_who, _block); | ||
| } | ||
|
|
||
| /** | ||
| * @dev Changes the delegation of `_from` to `_to`. | ||
| * If `_to` is set to 0x00, fall to parent proxy. | ||
| * If `_to == _from` removes delegation. | ||
| * @param _from Address delegating. | ||
| * @param _to Address delegated. | ||
| */ | ||
| function updateDelegate(address _from, address _to) internal { | ||
| emit Delegate(_from, _to); | ||
| DelegateSet memory _newFrom; //allocate memory | ||
| DelegateSet[] storage fromHistory = delegations[_from]; | ||
|
|
||
| //Add the new delegation | ||
| _newFrom.fromBlock = uint96(block.number); | ||
| _newFrom.to = _to; //delegate address | ||
|
|
||
| fromHistory.push(_newFrom); //register `from` delegation update; | ||
| } | ||
|
|
||
| /** | ||
| * @dev `_getDelegationAt` retrieves the delegation at a given block number. | ||
| * @param checkpoints The memory being queried. | ||
| * @param _block The block number to retrieve the value at. | ||
| * @return The delegation being queried. | ||
| */ | ||
| function getMemoryAt(DelegateSet[] storage checkpoints, uint _block) internal view returns (DelegateSet memory d) { | ||
| // Case last checkpoint is the one; | ||
| if (_block >= checkpoints[checkpoints.length-1].fromBlock) { | ||
| d = checkpoints[checkpoints.length-1]; | ||
| } else { | ||
| // Lookup in array; | ||
| uint min = 0; | ||
| uint max = checkpoints.length-1; | ||
| while (max > min) { | ||
| uint mid = (max + min + 1) / 2; | ||
| if (checkpoints[mid].fromBlock <= _block) { | ||
| min = mid; | ||
| } else { | ||
| max = mid-1; | ||
| } | ||
| } | ||
| d = checkpoints[min]; | ||
| } | ||
| } | ||
|
|
||
| /** | ||
| * @notice Reads `_who` configured delegation at block number `_block` in this level, | ||
| * or from parent level if `_who` never defined/defined to parent address. | ||
| * @param _who What address to lookup. | ||
| * @param _block Block number of what height in history. | ||
| * @return The address `_who` chosen delegate to. | ||
| */ | ||
| function findDelegatedToAt( | ||
| address _who, | ||
| uint _block | ||
| ) | ||
| internal | ||
| view | ||
| returns (address directDelegate) | ||
| { | ||
| DelegateSet[] storage checkpoints = delegations[_who]; | ||
|
|
||
| //In case there is no registry | ||
| if (checkpoints.length == 0) { | ||
| return ( | ||
| address(parentDelegation) == address(0) ? | ||
| address(0) : parentDelegation.delegatedToAt(_who, _block) | ||
| ); | ||
| } | ||
| return getMemoryAt(checkpoints, _block).to; | ||
| } | ||
| } | ||
| ``` |
There was a problem hiding this comment.
Consider moving this to ## Implementation section, as it doesn't define the public surface area, which is really what is critical for the specification.
| Democracies are seen as a multisig of infinite participants, which signatures weight are on their voting token and the threshold as usually 50%+1 or more. | ||
|
|
||
| Being possible to approve something in qualified quorums becomes more difficult the wider the community of holders is, and approving very specific tasks can be complicated to evaluate for most of holders. | ||
|
|
||
| Therefore the design was around solving the problem of defining delegates in a common but optionally specialized way building a trust network which can easily and carefully approve proposals. |
There was a problem hiding this comment.
This is all content better suited for the Motivation section. The Rationale section should describe why you made specific choices, like why did you decide to deploy at a deterministic address, or why did you decide to use a salt, or why a particular obviously desirable feature was not included or why a non-obvious feature was included.
| ## References | ||
|
|
||
| https://docs.google.com/presentation/d/1FJkaJlp_Fs0D5KHsn8oEgDOhg9QKiBwxHOvUL0dvC5I/edit#slide=id.g50bded6ab0_0_10 | ||
|
|
There was a problem hiding this comment.
EIPs don't have a References section, which is intentional. EIPs should be able to stand on their own without external reference material. If there is some critical content for the EIP that must be included (forever) then it should be added as an asset in ../assets/eip-2502/ and linked as part of one of the other sections.
|
There has been no activity on this pull request for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review. |
Co-authored-by: Micah Zoltu <micah@zoltu.net>
|
Please, keep it open. |
Co-authored-by: Micah Zoltu <micah@zoltu.net>
@3esmit You are saying you don't want this merged as a draft now that CI is passing? We can do that for a couple days, but the normal process is to get things merged as draft as soon as they are properly laid out and then the author (you) can iterate on the draft with auto-merges. |
|
Yes, I still need to address all the things here before going to draft. |
|
There has been no activity on this pull request for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review. |
|
This pull request was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment. |
Preview at: https://gitlab.com/status-im/docs/EIPs/blob/eip-2502/EIPS/eip-2502.md