Feedback Wanted: Allowances Design | The Radix Blog | Radix DLT
The topic for this call for feedback is the design of the Allowances feature in Scrypto & the Radix Engine.
Introduction
In the Radix Engine, proofs serve as a fundamental component for both authorization and authentication. A proof demonstrates that you have access to some resource, such as a badge. A proof may be placed in the “auth zone,” enabling it to be seen for passing authorization checks in a component that you call.
But the proof model presents a few key limitations:
- If you return a proof, you pass the holder the power to perform any action with that proof. If they can use the proof to withdraw 1 unit of a resource, they can withdraw 1 million units of that resource. If they can update metadata on an account, they can withdraw from the account.
- Proofs can be passed as method arguments, but they lose their authorization power when passed this way. Conceptually when passing a proof as an argument, the intention is to “show” a badge, so it doesn’t let the receiver use the proof themselves. But in some situations, this restriction is too limiting. Sometimes, once you’re comfortable with allowing an action to happen, you don’t care who actually performs it.
- There’s a learning curve to understanding the nuances of proof behavior, and how to utilize them properly, including when it’s appropriate to place them in the auth zone and when to pass them around directly.
Allowances attempt to address these limitations:
- Allowances enable scoping of authorization to enable up to a certain quantity of a specific action to be performed in the current transaction. These actions can then be performed at any time during the transaction, by any actor.
- Allowances exist in a single, global space during the transaction; they don’t need passing around and are only consumed by the particular action they were created for. There’s no need to solve the problem of making sure that the appropriate authorization is present when it’s going to be needed…allowances are always present everywhere.
Allowances let something with authority “pre-approve” a limited use of that authority, as long as it happens in that same transaction. They let you say, effectively, “I am hereby granting permission for up to 50 GUM to be minted later in this transaction.”
Even if a badge has the authority to do many different things—mint or burn some resource, access privileged methods on a component, update metadata on another component—allowances let you selectively specify which actions you’re permitting.
The Call for Feedback
While the purpose for allowances is known, there are some open design questions on the mechanical particulars of how they behave.
Here’s a detailed document which describes the options being considered, with an explanation of the tradeoffs between each. It also has a few explicit questions which we’re curious to hear your answers on.
As the details of the design options are quite nuanced, we’re electing not to use a survey form, but rather open the matter up for discussion in Discord, in the #feedback-allowances channel in the Developers section.
When presenting your view of how allowances should behave, please keep the following in mind:
- The overriding development philosophy for Radix is to always make the 90% case easy and safe, even if it makes some narrow use cases laborious or impossible.
- A developer with only a light understanding of how the feature works must be protected, as much as is practically possible, from shooting themselves in the foot because they didn’t understand some nuance of its behavior.
- We generally will sacrifice a bit of flexibility if it makes a feature easier to comprehend. If you’re struggling to communicate your idea of how it should work, think of how hard it would be to do the same in documentation and examples.
- As always, the best way to argue is to start with a concrete use case.
Even if you don’t have any particular insight to give, please feel free to just ask about use cases or clarify your understanding in the feedback channel. It will be the ongoing discussion hub for the feature up until it is released.