There are may be more ways to use ephemeral resources, but this post is focusing on these four.
1. Padding for compliance units
Currently, each compliance unit takes 2 resources: 1 consumed and 1 created. In case the transaction doesn’t have an equal number of consumed and created resources, padding resources must be used.
| Parameter | Ephemeral resource |
|---|---|
| Kind | Doesn’t matter |
| Quantity | 0 |
| Created/consumed? | Depends on what is missing in the compliance unit |
2. Mint/burn balancing resource
A transaction must be balanced, which means the total quantity of consumed resources of a certain kind is equal to the total quantity of created resources of the same kind. What if we want to mint or burn resources without being able to balance them naturally?
The natural solution is to use ephemeral resources for balancing. Such usage of ephemeral resources must be constrained by the resource logic to prevent unauthorised minting/burning of resources.
| Parameter | Ephemeral resource |
|---|---|
| Kind | Same as the resource being minted/bu |
| Quantity | Total quantity of the minted/burned res |
| Created/co If the persistent resource is minted, consumed. If the persistent resource is burned, created. ed. ed. |
3. Cross-action constraints
Resource logics of persistent resources can only constraint resources within the same action. Ephemeral resources, unlike persistent resources, can be created and consumed in the same transaction, which allows to enforce cross-action constraints.
Cross-action constraints become relevant when the user who wants to constrain a different action doesn’t naturally have access to it. For example, the full transaction is created by a third party (solver) with contributions from multiple users. This could be utilised to express and match intents.
Alice has a resource A_Alice and would like to get a resource B_Alice. Bob has a resource B_Bob and would like to get a resource A_Bob. They do the following:
Alice creates an action Action_Alice:
- consume
A_Alice - create
Intent_Alice, which is an ephemeral resource of quantity 1. It can only be consumed if there is a resourceB_Alicecreated in the same action
Alice sends this action to the solver.
Bob creates an action Action_Bob:
- consume
B_Bob - create
Intent_Bob, which is an ephemeral resource of quantity 1. It can only be consumed if there is a resourceA_Bobcreated in the same action
Bob sends this action to the solver.
Solver sees the two actions and creates a transaction that includes Action_Alice, Action_Bob and a third action:
- create
B_Alice - create
A_Bob - consume
Intent_Alice - consume
Intent_Bob
| Parameter | Ephemeral resource |
|---|---|
| Kind | Unique |
| Quantity | Non-zero (by default it is 1) |
| Created/consumed? | Created in the user’s action, consumed in the action satisfying the intent |
4. Extra constraints
Ephemeral resources can be used to add extra constraints to the action. That can be handy when we want to split the logic into a static component (carried by the resource logic field) and a more dynamic component (carried by an ephemeral resource of its own kind).
One question to answer with such dynamic logics is how to bind them to the “main” resource. Here are two ways:
- Encode the extra logic in the label of the “main” resource. In this case, the resource kind of the main resource depends on the extra logic we associate with it
- Include a constraint in the main logic that verifies the presence of some extra logic that is authorised by the owner of the main resource. So the owner says “this extra logic should be verified for this action” and the main logic verifies that a resource with this logic is included. In that case the exact logic is not fixed and doesn’t influence the kind of the main resource, but extra checks have to be performed in the main logic and the user has to actively participate.
Both of these ways are used in the kudos application design. Denomination logics are encoded in the label of the kudo resource, receive logics are authorised externally.
| Parameter | Ephemeral resource |
|---|---|
| Kind | Derived from the added constraints |
| Quantity | 0 |
| Created/consumed? | Doesn’t really matter |
