Progress of development from the last quarter of 2017
In the last quarter of 2017 we were heads down developing everything for the version 0.5 release of the Aragon Core app. Lots of progress was made, first audit of the smart contracts was conducted with good results and we're on track to get the testnet release out really soon™.
It has been an incredible quarter of building, in which we have laid down the foundation for everything that is to come in 2018. Brett and Pierre joined the development team, who together with Olivier are an amazing founding technical team.
Without further babbling, here's a list of some of the bigger changes that took place in Q4:
As we've been doing this major overhaul of the project that started with the re-design of the front-end and was further expanded with the creation of aragonOS, new tools were also needed.
The new approach makes Aragon modular and granular so that users have a choice of how to run their organizations, but also with the ability to create any functionality they feel is missing. We've started creating the tools necessary to build any apps on top of Aragon and these are the latest ones to help support the constructing of the Aragon ecosystem.
To provide transparency on the progress of our development, we published the initial audit report of the aragonOS system that powers the version 0.5 release of Aragon Core.
The audit motivated some changes in the codebase, but no critical problems were found.
Further audits and public bug bounty programs are scheduled to begin in January 2018. If you're interested in taking part and contributing on these bug bounties or any other bounties in our GitHub repositories, look for the bounty labels in the different repository issues!
Starting with the next version, v0.5 — The Refactor Release, Aragon will feature an entirely revamped interface. The decision to redesign the DApp was simple. There was a need to align the app and it's updated graphical identity, design principles and use cases to the origin of the project.
Smart contracts for running Aragon Core organizations
With the latest updates after the audit, aragonOS version was upgraded to 2.0.1.
I presented on this subject at the Ethereum Devcon3 conference titled Designing future-proof smart contract systems and the work on the subject continued even further.The presentation slides can be found in the wiki.
This PR abstracts the concept of a DelegateProxy that both KernelProxy and AppProxy now use for delegatecall'ing to the actual implementation.
Also forwards will revert when attempting to forward a call to an address without code, as it would just fail silently before.
Also updates Zeppelin's token contracts to the latest version to avoid failure with SafeMath assertions
In the current iteration of the Kernel ACL, every permission instance has its own 'parent'. A more detailed explanation can be found in the ACL section of the aragonOS doc. In this model the parent of a permission instance means two different things:
Parent can always revoke a permission instance.
If an entity has a permission and it is also its own parent, it can regrant the permission.
The problem with this permission model is that in case a permission has been granted to an entity that cannot do arbitrary calls (i.e. Finance or Fundraising)
Proposed new model
Introduce a permission owner at the permission level and remove the permission parent from the permission instance level. The owner is able to grant or revoke an arbitrary number of permission instances of that permission.
The idea behind having a Factory deploying organizations is only needing 1 on-chain transaction to completely set up a default organization with sane permission defaults.
It performs a deploy of a KernelProxy, one MiniMeToken and one instance of every default aragonOS apps.
The default permissions give too much power to the Group called 'Founders Group' in which the creator of the organization is added. For very destructive actions (such as upgrading the Kernel), a voting is required. The voting app uses the created token as its governance token, the creator of the organization is given 1 token so the voting app is usable.
When launch approaches we should create multiple types of factories (kind of like organization templates).
Makes it easier to "bundle" the interfaces for app development instead of having to copy the entire Kernel file.
After calling votingApp.changeMinAcceptQuorumPct(uint256 _minAcceptQuorumPct), a vote that was thought of not being approved because minimum quorum wasn't met, could become executable because of the quorum change.
The reverse case can also happen, in which a vote looks like it will be approved but changing the acceptance quorum makes it unsuccessful.
The proposed change is for every vote to keep track of what the minAcceptQuorumPct value was at creation time.
Instead of returning a hash of the evm call script, return the entire script.
Remove useless vote.open boolean from storage.
Improve calculations for support and min quorum for small quorums
Add tests for covering both basic ERC20 functionality and MiniMe specific functionality such as cloning.
Upgrade solium to most recent version and update the configuration file to use updated config syntax. Also added some of the fixes suggested by the linter.
Adds the ability to provide a payload to be executed when an AppProxy is deployed. This allows to perform an atomic deployment and initialization of any app without the need to have a specific factory.
It shouldn't introduce any security vulnerabilities as the proxy will forward any call in the same way after it being deployed.
Added most recent version of solium to package along with all the dependencies needed for that version.
As Node 9 and 8.9.x was released, we no longer have unsupported features in this repository. I think we can safely remove Babel and use Node 8.9.x or Node 9, since we only use Node for tests.
Adding this event will allow to recover forwarding paths from transaction receipts. This is needed to properly show the side-effects of a given transaction in components such as the tx queue
Apps have been moved to their own repo, aragon-apps so they can be developed along side their client code and have standard APM package structure.
What remains in aragonOS is the Kernel and common components used by apps. A decision on whether APM contracts should be moved in to aragonOS is still to be made.
This monorepo contains the core applications that are bundled with Aragon by default.
After a budget decrease, checking the remaining budget can fail because expenses are greater than the budget amount for a given token.
We should add a check on whether what was already spent is more than the budget and return 0 as remaining budget.
Changes in multiple apps to increase coverage
A similar PR was already merged for aragonOS.
I updated the aragonOS dependency to 1.0.2 and upgraded the test to check for assertRevert (the new opcode added in Byzantium) also had to upgrade ethereumjs-testrpc so it has the revert opcode.
All functions should have an explicit access modifier (external, public, etc.).
Aragon UI is the interface toolkit used by Aragon and its related projects.
The big change on aragon-ui was the move from Vue to React. Otherwise progress on this front-end toolkit has been steady and moving ahead very nicely.
Note: this PR also includes the color system.
The objective I have in mind is to release a documentation website (looking like an Aragon website), also providing the design specifications.
Eventually, I'd like to provide to Aragon developers a unified website, containing everything needed to build on the platform: node-aragon API, Aragon UI components API, but also guides and guidelines.
Storybook provides a super nice environment to develop components (it's my go-to solution), but I don't think it would be flexible enough for our case (or it would mean disabling its main features like the bottom panel).
To summarize: more control, trivial to implement (menu + routing + stories), dogfooding, and eventually a better experience.
Loader is the only component missing, I think it's too specific for now. I'd like to see how we manage loading states in the Aragon client before adding a generic Loader component.
Using the transpiled library solves all this problems, except one. Most modern build systems have some mechanism to import non-JS dependencies, which allows, in the context of a components library, to have the assets of a component in the same directory (instead of using a global folder).
When the modules are transpiled, the link between the importing module and the assets is lost in the process, and all the links to the assets are broken.
The solution implemented by this commit is the following:
The library is transpiled to "universal JS", with and without ES6 modules (for tree shaking, if the parent project build system supports it).
The parent project imports the transpiled version of Aragon UI, and also copy the Aragon UI assets into a directory where they can be served by a web server.
The parent project wraps the Aragon UI app into AragonApp, which allows to set the public URL of the toolkit assets: <AragonApp publicUrl="/">
That way, each Aragon UI component using an asset is aware of the URL where they can be fetched from.
Provides a small debugging quality-of-life upgrade in the gallery for component names and classnames.
I've left the plugin's own minification and transpilation step on since they seem fairly safe. They're producing a negligible ~3--4kb decrease on the non-minified builds for me right now.
Adds default Aragon app bar with pluggable child elements (some apps only have a title in the app bar; the chevron will be hidden in these cases).
They are SVG images, converted to components using svgr (to have them as inline SVGs and make it possible to change their color).
To prevent having all the icons in the final build, they are exported individually (prefixed with Icon)
This commit adds two new colors:
They are both white and should be used for text or outlines that are on top of the "positive" and "negative" colors.
It also fixes the color of theme.textTertiary for the light theme, which was the same as theme.textSecondary.
Enables display names for users of this component library.
Increases the build size by ~2--3kb, which I think is OK for now given the quality of life upgrade. In the future, we can have a production build where this is turned off, or perhaps even better, change the plugin so that all the display names are under a NODE_ENV flag.
Adds a basic, styled <input /> box.
I've added the README as src/Form/Input.md, since I can see src/Formcontaining multiple components in the future (all the other input types, etc). In general, it might be interesting to have folders under src/ be groups holding actual components, with each component's documentation living as <component name>.md.
Also contains documentation and a demo page.
CLI tool for creating, testing and publishing Aragon applications.
The toolkit was also refactored and support for scaffolding was added.
This is the initial refactor before we can start working on implementing the playground command
Adds support for scaffolding in the init command (for example aragon-dev-cli init [app ENS name] [template name, github repository name])
The command will clone a GitHub repository into a folder. It defaults to cloning aragon/aragon-react-boilerplate. The contents will be cloned to the "base name" of the application's ENS name, e.g. for foo.aragonpm.eth it would be cloned to a folder called foo.
Given we have multiple official boilerplates, we can alias them (for example, instead of typing aragon/aragon-react-boilerplate, simply typing react is good enough).
We somehow need to update the name key of the manifest.json file in templates, but they might be in different locations
Adds support to passing a custom ENS Registry address as an option. This allows to use aragon-dev- cli in a dev network without a canonical ENS Registry
Radspec is a safe alternative to Ethereum's natspec
Radspec will introduce the following features:
In the wiki you can find the contribution guide to aragonOS, aragonOS documentation and the Aragon Development Overview with a list of repository owners, and if you feel like contributing or have any questions from the devs, hop onto Aragon.Chat and let us know, we're happy to help!
Current open bounties: