aragonOS new documentation #204
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
I can do some of them
Also it might make sense to find a consistent way to visualize the ACL/transaction pathing (not just for this document), as many governance mechanism might be a collab between 2 or 3 apps. |
|
Merging but edits still need to happen #280 |
Kyrrui
reviewed
May 22, 2018
|
|
||
| **Upgradeability** is really important when developing high-stakes systems in | ||
| platforms that are still evolving fast. Done well, it can allow for bug fixes | ||
| and improvements with very little disruption and not causing problems at the |
There was a problem hiding this comment.
Change "disruption and not causing" to "disruption and without causing"
| **Upgradeability** is really important when developing high-stakes systems in | ||
| platforms that are still evolving fast. Done well, it can allow for bug fixes | ||
| and improvements with very little disruption and not causing problems at the | ||
| protocol level. As a history lesson, if *The DAO* had had an effective |
There was a problem hiding this comment.
Change "if The DAO had had an effective" to "if The DAO would have had an effective"
| platforms that are still evolving fast. Done well, it can allow for bug fixes | ||
| and improvements with very little disruption and not causing problems at the | ||
| protocol level. As a history lesson, if *The DAO* had had an effective | ||
| upgradeability mechanism, no hard fork would have been required to fix the problem. |
| making governance the most important aspect of upgradeability. | ||
|
|
||
| In a similar way, you cannot have effective governance without a way for upgrading | ||
| itself to a superior form of governance. Therefore we feel very strongly that |
There was a problem hiding this comment.
change "without a way for upgrading itself" to just "without a way of upgrading"
|
|
||
| In a similar way, you cannot have effective governance without a way for upgrading | ||
| itself to a superior form of governance. Therefore we feel very strongly that | ||
| **upgradeability** and **governance**, in the context of smart contract, are actually |
There was a problem hiding this comment.
change "smart contract" to "smart contracts"
| 3. Deploy the Voting app | ||
| 4. Grant the Voting app the ability to call `createPermission()`: | ||
| `grantPermission(votingAppAddress, aclAddress, CREATE_PERMISSIONS_ROLE)` (must be executed by `rootAddress`) | ||
| 5. Deploy the Vault app, which has a action called `transferTokens()` |
| assigned an array of parameters that will be evaluated every time the ACL is checked | ||
| to see if the entity can perform the action. | ||
|
|
||
| Parameters allow to perform certain computations with the arguments of a role in |
There was a problem hiding this comment.
Change "Parameters allow to" to "Parameters allow you to"
| An ACL parameter is comprised of a data structure with 3 values: | ||
|
|
||
| - **Argument Value** (`uint240`): It is the value to compare against depending on | ||
| the argument. It is a regular Ethereum memory word, that looses it 2 most significant |
| Even though `uint240`s are used, it can be used to store any integer up to `2^30 - 1`, | ||
| addresses and bytes32 (in the case of comparing hashes, losing 2 bytes of precision | ||
| shouldn't be a dealbreaker if the hash algorithm is secure). The only problem is | ||
| when |
|
|
||
| ## 7. Aragon app development guide | ||
|
|
||
| This is a small walk through on how to build a fully upgradeable registry app with pluggable governance. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Scaffolded document. Section progress:
1. General architecture, Kernel and apps
2. Kernel
2.1 The app mapping
2.2 Namespaces
~3. Upgradeability
3.1 DelegateProxies3.2 Kernel upgradeability3.3 AppProxies and upgradeability3.4 App sandbox
4. ACL
4.1 The ACL as an Aragon app, the Interface
4.2 Basic ACL
4.3 Permission managers
4.4 Parameter interpretation
4.5 Examples of rules
5. Forwarders and EVMScript
5.1 Forwarding and transaction pathing
5.2 Forwarding interface
5.2 EVMScripts
5.2.1 Warnings
5.2.2 Script executors
5.2.2.1 CallsScript
5.2.2.1 DelegateScript
5.2.2.3 DeployDelegateScript
6. The Aragon Package Manager
6.1 APM as an Aragon DAO
6.2 APMRegistry
6.2.1 ENSSubdomainRegistrar
6.2.2 APMRegistry governance
6.3 Repos
6.3.1 New version rules
7. Aragon app development guide
7.1 Using the ACL
7.2 Upgradeability: storage considerations
7.3 Testing and publishing your app with aragon-dev-cli