-
Notifications
You must be signed in to change notification settings - Fork 0
Description
Now that entries have been absorbed into the Equals statement, and literals are fully supported, most use cases don't need to declare new anchored keys. However, there's now no way in a POD REQUEST to ask for an entry to be explicitly included in the newly proven POD. Framed in programming-language terms, we have only a == operator not a :=. Framed in the context of statements and operations, there is no way to cause an Equals statement to be created by the solver using NewEntry operation, rather than an EqualFromEntries or TransativeEquals operation.
What would this be useful for? If we want to fully support the ZuKYC use case from Zupass, there are two new features needed which could use this. The simplest is for the watermark, which might look something like this (syntax definitely not final):
REQUEST(
NotContains(?sanctions["sanctionList"], ?gov["idNumber"]
Lt(?gov["dateOfBirth"], 18)
Equal(?pay["socialSecurityNumber"], ?gov["socialSecurityNumber"])
Lt(1706367566, ?pay["startDate])
NewEntry(?self["watermark"), "loan request 12345")
)
A more complicated case for this would be adding a new entry inside of a private statement and/or custom predicate, which would might be needed to perform the ownership
(private) NewEntry(?self["privateKey"], priv_key)
PublicKeyOf(PublicKey(123abc...)), ?self["privateKey")
This specific use case mighta work with literals-only if embedded in a custom predicate - I haven't thought through it in full, but I think the ability to add new entries to satisfy private statements or custom predicates might still be a useful feature.