FLIP-934: Interaction Templates

Governance FLIPs
21

I think even better model can be staking / slashing involved.

  • Auditor stakes some FLOW tokens. ( So anyone can be an auditor, so we solve problem of who decides who will be the auditor )
  • Anyone can challenge an auditor about an interaction template ( Let’s say for 10% of the staked )
  • Depending on the challenge result we can slash Auditor or Challenger.

Even this slashed amount can act as an insurance pool for the users who are effected negatively from the wrong auditor assurance.

This would be a totally decentralized and secure system. This is first that comes to mind, I am sure it is not a challenging task to make this secure for a team who secures the chain this will run.

22

A few thoughts and flip summary:

Important to get the transaction templates protocol setup. The “proof of audit” is where the protocol comes together, being all on-chain makes most sense. The actual templates can be stored where ever dapps wants to store them. Ultimately it’s not important.

Proof of Audit:
A simple smart contract can be created by dapper that will allow auditors to store the auditor signature and hash of the transaction template.
A “Verify” method can take in a transaction template and produce the hash for looking up audits, then return all auditors that submitted “Verified” for the specific transaction template hash.

Wallets can use this to verify transactions are audited by trusted auditors. It’s up to the wallet to use it. Of course users might only want to use wallets that have this added security.
Of course, Auditors can withdraw their audit at any time. If there is an exploit the Auditor would need to withdraw their auditor or risk losing all credibility.

dapps:
dapps can create transaction templates and get them verified by auditors that wallets trust.
They can use tools that dapper or whomever wants to create to leverage the transaction template format Structure has be described in the FLIP. I suspect this format will evolve over time as it gets used.

A key take-away is, anyone can create transaction templates and anyone can create tools, anyone can submit audits, no restrictions, only a transaction template format standard.

Ultimately, in the chain of trust, the user trusts the wallet, the wallet trusts the auditor. The wallet can be very strict or ignore audits all together. The whole thing is optional, but does give building blocks for trust and hopefully gives some peace of mind for the user, who is risking funds.

23

@bluesign Thank you for your comments! I’ve done some thinking on the points you raised and have these ideas:

  • Discovery: On-chain + off-chain repositories of templates and audits could improve their discoverability. Many on-chain + off-chain repositories of templates and audits should be able to exist. Entities querying for a template should know a set of these repositories to query from.

  • Audit (revocability, verification): On-chain + off-chain repositories where the validity of audits can be vouched for could help communities or other trusted entities invalidate existing audits. In the cases you highlighted (hostile auditor, leaked keys, accidental audit, incorrect audit etc), these repositories could allow either the auditor themselves, community or other trusted entity to flag an audit as invalidated.

    This mechanic could take a form something similar to OCSP, or like certificate revocation lists, where entities verifying an audit would query a set of these “audit validation repositories” to see if an audit they’re verifying has been flagged as invalidated.

    This could make the verification process of an Interaction Template Audit look something like:

    • (Optional) Verifier queries a set of “audit validation repositories” that they trust to see if the Interaction Template Audit has not been flagged as invalidated.

    • Verifier queries, using the Interaction Template Audit, the key_id on the account corresponding to address on the data.signer to check it is not revoked

    • Verifier queries, using the Interaction Template Audit, that the signature is valid for the key_id on the account corresponding to address on the data.signer.

      If these checks pass, the Interaction Template Audit could be considered valid.

—

I think crucially that most of the components highlighted in this FLIP + discussion are optional , and that it should be up to the entities engaged in the system to do what they want. For example:

  • An individual wallet (or any entity doing Audit verification) could choose to only accept Interaction Template Audits that are stored on-chain, and ignore any stored off-chain. This would be entirely up to them.
  • An individual application could use Interaction Templates only stored in repositories on-chain that are curated by some DAO they trust.
  • An individual application could choose to only use Interaction Templates stored on GitHub in a certain repo.
  • etc etc etc…

It’s up to the entities (Application, Wallet, Auditor, User) to do what they want to do and use what they want to use, and accept the tradeoffs involved in their decisions

—

As the concept around Interaction Templates progresses there could be many new optional “layers” that emerge on top of the base structure this FLIP proposes.

For example, this idea (which I think is really excellent) could exist as an optional “layer” that on-chain audit repositories could implement:

Then wallets (or any entity doing Audit verification) might choose to only trust Auditors that have their audits submitted to such an on-chain audit repository and are sufficiently staked.

25

Great proposal !

I’m Hao from lilico wallet, I have been looking for something like this for a while.
So glad that we are doing some actions and thoughts on this.

Here are some of my thoughts:
Both off-chain and on-chain storage looks good to me, I’m more concerned about developer experience will look like. How do they submit and track their temple auditing process and how to communicate with auditor.
I feel like using a offical or community driven GitHub board or issues to track and manage will be easy to manage.

From wallet provider perspective, I think it will be nicer if we could add some extra param in the metadata to give user a better experience :

  • code
  • hash
  • data structure with arguments and their types
  • friendly description that can be i18n by community members

  • Risk level

    • Identity the level of dangers in this operation. For example, enable a collection vault is low. Adding a public key to address should be identity as high

  • Contract Metatdata

    • If each transaction can show logo and name of the transaction provider will be great, the one from the fcl config is not 100% can be trusted.

And also I strongly agreed that some common transaction like NFT or FT transfer and create account should be labelled. It will be easier for wallet to show and identity what kind of token this transfer is about.

26

There is allowance for custom metadata in the transaction template. As I understand it, this FLIP is meant to help different interested parties to coordinate trusted transactions.

If a wallet demands specific metadata they would have to work with the template creator and auditor to get that information added to the template and verified by the auditor. I like the idea of Risk Level added by the auditor. There would need to be an Audit Format that is submitted when template is verified by the auditor.

What information the Auditor submits still needs to be teased out. Here is something to start with:
RiskLevel
IsVerified
Signature/key
TemplateHash
Notes

As I see it the Wallet has the most influence since they are the gate keeper of user’s funds. Generally speaking I’d recommend looking at transaction templates as malicious and shouldn’t be trusted. Any template provider info can be faked. It’s the job of the Auditor to verify the transaction template.

27

@JeffreyDoyle Thanks for the answers,

Discovery: On-chain + off-chain repositories of templates and audits could improve their discoverability.

I am confused, how can this be possible ? Do you mean I will go auditor github and discover something ?

But one question, and I think the most important is: How I will know when some auditor sign something?

This mechanic could take a form something similar to OCSP like certificate revocation lists, where entities verifying an audit would query a set of these “audit validation repositories” to see if an audit they’re verifying has been flagged as invalidated.

I am not sure now having some other auditors auditing auditors is good idea.

An individual wallet (or any entity doing Audit verification) could choose to only accept Interaction Template Audits that are stored on-chain, and ignore any stored off-chain. This would be entirely up to them.

If wallet’s will trust who they want, it will be chaos. I will get same transaction audited for Blocto, Dapper Wallet and lilico. Or do I have to find an auditor who covers all ?

Imagine a hostile wallet comes into future which gains high user count, and doesn’t care about decentralization, openness etc, does gatekeeping, and they say I will only work with XCORP for audits.

An individual application could use Interaction Templates only stored in repositories on-chain that are curated by some DAO they trust.

  • Should I choose interaction template for user’s wallet provider? I mean if user has blocto, blocto doesn’t trust

@JeffreyDoyle Thanks for the answers,

Discovery: On-chain + off-chain repositories of templates and audits could improve their discoverability.

I am confused, how can this be possible ? Do you mean I will go auditor github and discover something ?

But one question, and I think the most important is: How I will know when some auditor sign something?

This mechanic could take a form something similar to OCSP like certificate revocation lists, where entities verifying an audit would query a set of these “audit validation repositories” to see if an audit they’re verifying has been flagged as invalidated.

I am not sure now having some other auditors auditing auditors is good idea. We need to solve this with some centric authority managed decentralized, ( something like DAO )

An individual wallet (or any entity doing Audit verification) could choose to only accept Interaction Template Audits that are stored on-chain, and ignore any stored off-chain. This would be entirely up to them.

If wallet’s will trust who they want, it will be chaos. I will get same transaction audited for Blocto, Dapper Wallet and lilico. Or do I have to find an auditor who covers all ?

Imagine a hostile wallet comes into future which gains high user count, and doesn’t care about decentralization, openness etc, does gatekeeping, and they say I will only work with XCORP for audits.

  • Now every dapp has to go XCORP to audit their transactions for new wallet ?

An individual application could use Interaction Templates only stored in repositories on-chain that are curated by some DAO they trust.

  • Should I choose interaction template for user’s wallet provider? What if DAO curated transactions but some is trusted with blocto, some by dapper etc

I think it is very important to have consensus on trust. Users should be able to manage their own auditor lists, and wallets should not be gatekeeper here.

1 Like
28

Hey @bastian , thank you for your comment!

Re:

Contract developers could choose to make available Interaction Templates by storing and making them them available from the same account their contract is deployed to - this would be an excellent mechanic for consumers of a contracts templates to determine that the contract developer vouches for them.

Verifiable authorship of Interaction Templates stored off-chain is more tricky. I think there could be a few options:

  • Part of the auditing process could include an Auditor authenticating that an Interaction Template was created by a specified entity in the Interaction Template. We could add an author field to Interaction Template that contains a Flow address. Entities verifying an Interaction Audit of that template could gain confidence that it was produced by the entity in control of that address if the verification succeeds.

  • OR: Consumers of Interaction Templates could query for them from places they know are connected to a contract. For example, if I know that http://nft-project.com and contract NftProject on account 0xABC123 are connected, I can have confidence that any InteractionTemplates published on a web server at http://interactions.nft-project.com come from the same entity that created the NftProject contract.

This all said - I think authorship information isn’t a crucial piece of information for an Interaction Template. For example - if I have an Interaction Template, and a verifiable Interaction Template Audit for it produced by an auditor I trust, then I can have confidence that the Interaction Template will do what it claims to do regardless of who created it.

Do you have differing thoughts?

—

Re:

The intention with the f_ prefix is to denote this is a “meta” field about the data structure. It’s used in f_type to denote the data structure type, and f_version to denote the version of this data structure.

Re:

The content inside the data is serialized and then hashed to generate the id of the data structure. The content outside of data is not included in whats used to generate the id. data is meant to be where the content of the data structure lives - that content could live a layer up in the data structure but I believe nesting it there makes it clearer as to whats used to generate the id and what’s not.

It could be an array! The intent here was to make it easier to look up a specific argument by argument name in this map, and that the ordering of arguments is important. Alternatively, the ordering information could be found by looking up the argument order from the cadence content of the Interaction Template, in which case the index field could be removed, but would be more complex for consumers of the Interaction Template to compute.

29

It could be an array! The intent here was to make it easier to look up a specific argument by argument name in this map, and that the ordering of arguments is important. Alternatively, the ordering information could be found by looking up the argument order from the cadence content of the Interaction Template, in which case the index field could be removed, but would be more complex for consumers of the Interaction Template to compute.

I would prefer to have a way to know the name and the type of an argument and not just the index. It is so much more convenient to know firstName:String, lastName:String, compared to just [String, String]

30

Hi all - @bluesign and I had a video call last week (May 30 2022) - we chatted about the topics in this thread and have some notes to share:

On-Chain vs Off-Chain storage of Interaction Template and Interaction Template Audit.

-The storage of these data structures could be anywhere, however, there are certain qualities that are achievable by creating and storing Interaction Template Audits on chain that aren’t as easy to get if they are stored off-chain.

Interaction Template Audit Trail

-For example, if there were a contract that could be used to generate Interaction Template Audit data structures (probably structs on-chain in Cadence), this contract could emit events from it about who created an Interaction Template Audit, to create an “Audit Trail” - a mechanism for listeners to learn about who audited what. This could facilitate monitoring the credibility of an auditor, since if they audit a template that is later found not to be safe / accurate, there would be a way to find out they previously audited it.

Importance of sufficiently defined transaction pre, post and prepare phases

-Well defined pre, post and prepare transaction phases help increase the security of a transaction, and aid in an auditors process of determining if a transaction is safe and its Interaction Template is accurate. Auditors of Interaction Templates should be strongly encouraged to ensure Interaction Templates contain well defined cadence transactions

Optionality of the various “layers” discussed in this thread

-Most of the components discussed beyond the base “protocol” of this proposal can be considered optional. Really, what this FLIP aims to define is the Interaction Template, Interaction Template Interface and Interaction Template Audit data structures, and the roles of what the contract/template developer, application developer and wallet could do in creating, storing, exchanging, validating (etc) these data structures. Lots of additional layers can be built on top of the base “protocol” (eg: On chain storage of templates / audits, Auditor staking DAO, Audit revocation systems etc etc), and those layers can be established in subsequent FLIPs.

1 Like
31

Hi all!

Here is a quick video highlighting a demo of Interaction Templates. It showcases an InteractionTemplate and InteractionTemplateAudit, and how they might be used by applications and wallets in carrying out a transaction. Please leave any feedback/thoughts in this thread! We’re excited to hear what you think!

4 Likes
32

This is such a needed tool in the flow ecosystem! We want a safe chain that protects normies from getting scammed.

Today I saw an contract that took in AuthAccount as a method parameter. The way this interaction is written now is safe, but if that contract is updated it could not be safe at all.

1 Like
33

Hi @JeffreyDoyle

Great work! Love the demo, lilico couldn’t wait to support this interaction templates. I will follow up with this proposal.

Got some questions, if there is some network issue on wallet side, let’s say the the auditor calls is failed in some reason. I guess wallet still could sign the transaction, is it correct ?

And other thought is it might be a bit tricky sometime for auditor to audit the all languages message.

1 Like
34

Hi @Hao !

This should be up to each wallet to decide!

Submitting a template to the wallet during the signing process should be optional, and wallets should not always expect to receive a template along with the rest of the transaction to sign. Also, wallets should not expect that all templates to have audits produced for them by the auditors the wallet choses to trust.

My hope is that in the event you highlighted, that wallets would still accept the transaction and sign it - but perhaps doing so without making use of the template, or make the lack of an audit known to the user through the UI. Of course, all of this would be up to each wallet to decide to do or not to do.

Auditors could always choose to only accept templates with messaging in them produced in languages the auditor is comfortable with - this would be a decision up to them. My hope is that auditors will do their best to support auditing with as many languages as they can!

2 Likes
35

Sorry @JeffreyDoyle, super occupied lately and finally found the time to read through the Interaction Templates proposal.

Overall I like every component of this proposal and it’s a much more refined version of our attempt to keep an audited list of transactions.

Blocto can serve two roles when this rolls out:

  1. Consumer of the interaction template service and show proper message to users
  2. Auditor of the service and migrate the list we had in https://github.com/portto/flow-transactions to this service
1 Like
36

Thanks @JeffreyDoyle , for your explanation.
I think for now, all looks good.
I’m just can’t wait to add the support on this. :grin:

Do we know when this kind of API or service will be available ?
who will be maintain and manage this service by flow official or some DAO like Emerald :smiley: ?
And is there anything that lilico can do for helping this ?

37

Instead of using a “service” would it be possible to just maintain these templates in a public Github repo that is managed by a consortium of team members from the major wallets?

I think this would be a good time to have a small but broad set of individuals who are helping to maintain the main list, and then have each wallet fork that and add changes that they care about at that level.

Thoughts?

39

I looked at this recently a bit deeper and after that I have some more comments.

This is the repo i have looked at

  • There should be a docblock standard for flow that can be parsed to generate a template, if this is to be truly usefull one cannot answer questions when generating these. The data has to be version controlled with the interactions.

  • Translation of interaction templates should not belong with the template instead I feel that only a single language should be provided and a translation file with the corresponding keys should be specified. This way a technical translator can work on translating these without having to deal with the technical side of things. And also the technical implementation can change and the translation still be the same

  • Deprecation and replaceBy features are needed. If I want to fix a bug in an interaction i have to expand collapse said interaction. That is I first need to create a new interaction that fixes the bug and verify that in a production environment, then I need to mark the current interaction as deperactec and replaceBy this new one. The alternative is to version templates.

  • the json format is verbose in ways that I IMHO do not feel is needed when specifying messages/descriptions. These can simply be i18n keys and a default translation file can be provided for the langauge that is standard for this interation.

  • the dependencies specification is also verbose, i get that one address can have more then one contract so nesting is needed, but it can also be flat.

  • currently the mapping from id → name is done manually. This is not sustainable.