Shielded Kudos Pt. 3: KL constraints

Applications
13

KL constraints update

This update is meant to fix a number of issues with the current design:

  • equivalent classes members are not treated equally
  • the action structure is very limited and prohibits desired use cases

Base kudo structure

  • label: encodes the denomination logic verifying key. Can include additional parameters defined by the DL such as the issuer’s identity
  • value: encodes the owner’s identity

Consume

  1. The DL is triggered: there is a resource R_{DL} in the same action s.t. R_DL.logic = self.label.dl_vk

Create

  1. The DL is triggered: there is a resource R_{DL} in the same action s.t. R_DL.logic = self.label.dl_vk
  2. The receive logic is triggered[1]:
    1. There is a created resource R_{receive} in the transaction s.t.: Signature.Verify(Sig,R_receive.logic, self.value.owner) = True

Consequences:

  • We drop most of the KL constraints.
  • We no longer encode transaction functions in the logic and only constraint creation and consumption.
  • All equivalence classes properties hold[2]
  • I believe we still can get away with one DL trigger per denomination per action. Number of DL resources in the action = number of kudo denominations in the action. I’ll modify the DL logic accordingly and see if it works.
  • We can no longer have a verifiable intent mechanics, but that is okay because it only means that the user cannot delegate creating the initial transaction anymore.
  • We need to validate creating ephemeral kudos (e.g., with receive logic). More thoughts on this below

Validating created ephemeral kudos

What is the role of ephemeral resources in the kudos application? They are used exclusively for balancing. At the same time, if users are allowed to send ephemeral resources to other users, we must trigger their receive logic. If we don’t do that, it is still possible for users to “spam” other users with ephemeral kudos. At the same time, triggering receive logic for ephemeral kudos has no value and is costly. Sending ephemeral kudos shouldn’t be allowed.

The problem here is that we can’t just fail a transaction that contains ephemeral kudos since we do need them for balancing. My proposal is to prohibit sending ephemeral resources to anyone but the owner of the balancing consumed resources. This removes the incentive to spam since the user can only spam themselves. To enforce that, we must have the balancing consumed resource in the same transaction (which is somewhat limiting).

What if there are multiple consumed resources with different owners that correspond to such a created ephemeral resource? I don’t have a good answer for that question. Remember that the only situation when we need to create ephemeral kudos is burning, which is a somewhat special use case.

  • Do we want to allow burning multiple kudos of different owners at once?
  • Perhaps we can then call the receive logic for the group identity combining the owners of consumed resources (how to work with such an identity is out of scope of this post)

What I see as the best solution is to somehow bind the created ephemeral kudos to the creator of the kudo to remove the incentive.

Another idea I had is to remove ownership concept from ephemeral resources but this unfortunately doesn’t help since the resources themselves still are sent to someone. We need to make sure that someone can either control what they receive or the creator doesn’t have the incentive to spam the possible receiver.

Anyway, curious to hear what you think.

Example

Alice has some appleKudos and wants some orangeKudos. Bob has some orangeKudos and wants some appleKudos. They swap their resources without intents.

Alice’s action:

  • consume appleKudos
  • create orangeKudos
  • create e-appleDL (e- means ephemeral)
  • create e-orangeDL
  • create e-AliceReceive

Bob’s action:

  • create appleKudos
  • consume orangeKudos
  • create e-appleDL
  • create e-orangeDL
  • create e-BobReceive

What must be in the same action

  • Every action that contains a kudo of denomination D must contain a DL e-resource for D
  • Every action that contains a created kudo must contain a receive logic associated with the kudo’s owner

  1. if we find another way to constrain sending ephemeral kudos, this constrain can be checked for persistent resources only ↩︎

  2. ignoring the created ephemeral resources issue, depending on how we solve that ↩︎

1 Like