Role contracts autogeneration

General
1

(from https://github.com/OpenZeppelin/openzeppelin-solidity/issues/1290)

This is something I've been wanting to do for a while: to reduce the potential for human error, to more more succinctly express the differences and similarities between the different roles, and because I have a taste for bad ideas :slight_smile:

In the WhitelistedCrowdsale - #5 by nventuro topic I noticed a couple things that may differ from role to role, requiring parametrization. These are:

  1. Which accounts are able to assign the role? By default, these are accounts with the same role (e.g. accounts with the Minter role can create other minters), but in some cases it will be a different role that can do it (like in the case of Whitelisters and Whitelistees).

  2. Which accounts are able to remove the role? So far we've kept the function internal, leaving it up to our users to implement a public one and call it if they need to, but in some cases (again, Whitelistee) a 'manager' account may have the ability to remove others by default.

  3. Is the role assigned at creation time to the deployer account? For some roles (especially those managed by a different role, like Whitelistee) this may not be true.

  4. Can the role be renounced? We may have roles that shouldn't allow this (e.g. some sort of blacklist)

Additionally, we could include some sort of description (e.g. 'accounts with this role can mint new tokens') to also improve the documentation (also autogenerated).

The actual code generation should be dead easy, since there are only a few variants: a simple JavaScript program could read the settings from a json file and create the .sol files, only writing to disk if the contents changed (to avoid unnecessary recompilations).

2

An open topic that I have not yet put much thought into is how we’d go about testing these contracts. Something similar to the current PublicRole behavior may work, if we only have a couple simple (i.e. boolean) variants.

3

I really don't think a blacklist should be a role. While reusing the Roles library would be useful, we should rather be wary of using The Wrong Abstraction.

Precisely because a role is simply a set of addresses, a lot of things might look like they're roles, but may not really be. I would not be so fast to generalize this in all the different ways that you enumerated.

I have two questions:

  1. What happens to our strongly held argument that role bearers being able to assign the role is a natural consequence of the rest of the API and the platform?
  2. Are you considering exposing the role generator for OpenZeppelin users?
4

To be honest, I didn't put much thought into the blacklist idea: I was just trying to come up with a scenario where not renouncing might make sense.

That is derived from the implicit transfer property, which is not present in some scenarios due to legal requirements (the WhitelistCrowdsale being a prime example). In cases where tight control over which accounts have a role is required, disallowing transfer may make sense.

Not at first. I'd experiment a bit internally beforehand, but once it's in a good place that might make sense (though we may have come up with better solutions by then).