Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

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 that no one has access to, otherwise the "contract" may be violated. This procedure performs the following actions:

  1. Wait for an Asset transfer from a user
  2. Get information about exchanging assets (base asset ID, target asset ID, exchange rate).
  3. Check that these assets exist and can be exchanged.
  4. Calculate the target currency amount by passing the retrieved exchange rate to the mathematical instruction as an argument
  5. 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…

  1. 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.
  2. 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.
  3. 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.
  4. 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).
  5. How the calculated information will be placed in the store (step 4)?
    This is similar to the previous question but about writing data instead of reading it.


  • No labels