Consider a case of assets exchange. Assume we already have procedures functionality (a procedure - is an ISI stored in an Asset, one may call it a smart-contract). The ‘exchange’ procedure is owned by an account without any signatories, otherwise, the "contract" may be violated. This procedure performs the following actions with the following algorithm:
- Wait for an Asset transfer from a useran Account
- Get information about exchanging assets (base asset ID, target asset ID, exchange rate).
- Check that these assets exist and can be exchanged.
- Calculate the target currency amount by passing the retrieved exchange rate to the mathematical instruction as an argument
- Make a transfer by passing the calculated amount of the target currency, recipient account ID (that is, the user who made the transfer in step 1), and the target asset ID as an argument in the AssetTransfer ISI.
Let's assume that the passing of values as arguments is done through third-party assets. That is, one ISI writes the result to an asset-store, and the other reads from it.
Then, a few questions arise…
Requirements for this case are the following:
- To have the ability to pass exchange-related data like 'exchanging asset ID' and etc. to the algorithm (from asset-store, for example).
- To be able to manipulate the given data. For example, to calculate the exchanged currency amount.
- To store new data. For example, to store the calculated amount.
- To load saved data and pass it as an argument for an ISI. E.g. passing the calculated amount to the `TransferAsset` ISI.
- To have a guarantee that all the stored data is consistent, so the user would not have to verify all the data by itself.
Additional requirements for the algorithm:
- It should be persisted, so no one could change the order of the instructions.
- It should be guaranteed that the creator of the algorithm is not permitted to call these instructions by itself
- How will the user transfer information about the exchanging assets to the procedure (steps 1 and 2)?
If the sender writes this information into the same asset that he sends, then he must have permission to do so. So it is necessary to decide how this permission will be granted. - What if the storage was not empty and the sender did not update/delete this information? (security problem)
This can happen when another account that has previously exchanged with the same asset has stored some exchange-related information there, so our user may accidentally exchange it with incorrect data. - How to make sure that the information placed in the asset-stores is valid (step 2)?
It seems that there should be an opportunity to predetermine the type of data that can be stored in the asset, otherwise the authorized user will be able to put there any "garbage", which will have a bad impact on the consistency of data. This could be done with permissions, but they somehow should be granted too. - How will the information from the asset-stores get to any other ISI (steps 3-5)?
For example, if the AssetTransfer(From, To, Asset) instruction is used, it should probably be possible to specify as its arguments the IDs of the assets which contain the corresponding information. Then, it is necessary to decide how exactly this information should be “packed” (that is, by what key in the asset-store it should be obtained, what type of data should be, and how to compose it, if necessary).