You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A frequent use-case in blockchains is to have a user sign some data structure, similarly to how we asks users to sign transactions. Depending on the application, the data structures could be very different. They could be as simple as a few integers, or it could be a complicated structure with nested arrays and dictionaries.
Ideally, there would be a way in Cadence to easily handle such data structures: make it easy for client software to generate signed structures, and make it easy for smart contracts (or off-chain code) to verify those structures.
Suggested Solution
I'm imagining a wrapper mechanism similar to Capabilities. If I had a structure called Foo, Cadence code could refer to Signed<Foo> datatypes. Signed<Foo> instances would look and act just like the base type with a few caveats:
The direct data members of the Signed instance would act like let declarations, so they couldn't be written directly.
A new data member signatureSet would be available, which is a list of KeyListSignature objects.
A new member method verify(keyList: Crypto.KeyList): Bool would check if the current contents of the structure (including the signatureSet) are consistent with the keys in the given KeyList.
As a rule, Signed<> structures would be constructed off-chain and serialized to be used as arguments to scripts and transactions, so we'd also need to make sure that any client libraries had convenience methods for constructing signed objects. I don't think it would typically make much sense for Cadence code to construct Signed<> instances directly. I don't believe signed resource objects are useful (or perhaps even possible).
The type of the wrapped object could be used as a domain tag to prevent cross-domain attacks.
Open Question: What (if any) protection against replay attacks can/should we provide here?
The text was updated successfully, but these errors were encountered:
Issue to be solved
A frequent use-case in blockchains is to have a user sign some data structure, similarly to how we asks users to sign transactions. Depending on the application, the data structures could be very different. They could be as simple as a few integers, or it could be a complicated structure with nested arrays and dictionaries.
Ideally, there would be a way in Cadence to easily handle such data structures: make it easy for client software to generate signed structures, and make it easy for smart contracts (or off-chain code) to verify those structures.
Suggested Solution
I'm imagining a wrapper mechanism similar to Capabilities. If I had a structure called
Foo
, Cadence code could refer toSigned<Foo>
datatypes.Signed<Foo>
instances would look and act just like the base type with a few caveats:let
declarations, so they couldn't be written directly.signatureSet
would be available, which is a list of KeyListSignature objects.verify(keyList: Crypto.KeyList): Bool
would check if the current contents of the structure (including the signatureSet) are consistent with the keys in the given KeyList.The resulting code could look sort of like this:
As a rule,
Signed<>
structures would be constructed off-chain and serialized to be used as arguments to scripts and transactions, so we'd also need to make sure that any client libraries had convenience methods for constructing signed objects. I don't think it would typically make much sense for Cadence code to constructSigned<>
instances directly. I don't believe signed resource objects are useful (or perhaps even possible).The type of the wrapped object could be used as a domain tag to prevent cross-domain attacks.
Open Question: What (if any) protection against replay attacks can/should we provide here?
The text was updated successfully, but these errors were encountered: