Extending Smart Filters

Question

HI

We are looking at enforcing rules regarding asset issuances and transfers directly on the MultiChain nodes to remove the need for participants to use our own services for this purpose.

To do this we really need a way to publish and store rule metadata on the chain that could then be accessed by a smart filter and applied to transactions.  We had thought we could use a stream to mange this metadata.

Browsing the documentation, I don't think we can do this.  It looks like the only place we could store metadata that we could retrieve from within the filter would be to inject it into the initial asset issuance which for asset rules should be OK bar we could never change it, but ideally we would want to be able to manage the meta-data in such a way we could update it over time.

In addition, is there any way to find the chain burn address from within the filter?

Marty

Answer 1

Thanks for the question. You have a couple of options here:

1. If it's just a matter of permission changes, you can use custom permissions (e.g. high1) to control the privileges of any particular address and check them in a filter using the verifypermission callback.
2. For other metadata, consider using the asset reissuance pattern (issuemore), which allows new metadata to be added to the asset by those who have permission to do so. This metadata can be retrieved by filter from the list of issuances using the getassetinfo callback with verbose=true. The only drawback here is that this list of issuances will get long if there frequent changes to this metadata, and eventually this will slow down the filter.

In case you didn't see it, the MultiChain Web Demo gives you an easy way to experiment with filters and callbacks, and test them out on transactions.

Do either of these methods work for you? If not could you say something about the content and size of this metadata and how often you expect it to change? I ask because we are looking into adding a purpose-built mechanism for this kind of filter-affecting metadata in the next protocol upgrade.

Comments

Thanks,

I think for the initial set of rules we want to implement we will get away with adding the meta-data to the asset issuance.  I share your concern that adding updated metadata to a re-issue could be problematic and could get unwieldy.

The metadata I'm thinking about is not large, but is more around asset pairs and what can be exchanged for what, any min/max rates etc that can be used to verify a transaction.

We are also looking to try and enforce a burn rule whereby some transactions will have to burn a custom token to execute.   

Having a more general place to manage this data would be better for us to manage going forward and having them in one place.

---

OK, thanks for the feedback. We have been discussing the notion of a "variable" which has write permissions, and which can be queried from within filters. It sounds like that this would do what you need?

---

Possibly, depends what you mean by a variable :)

If this variable is capable of:
- holding json
- have state on a per filter basis
- be able to update the variable or create new instances of it with some indication as to when it supercedes the previous version, say by block number

That would be really useful!

---

Yes, the plan would be for it to hold JSON, and for their to be callbacks that can both retrieve the latest value for the variable, and also selected parts of its history. We don't envisage it having state on a per-filter basis but we do envisage it being possible to have any number of separate variables, so I assume this would achieve the same thing?

---

Great, that sounds exactly what we need :)

Thanks

Marty