Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Bridge-related data is encoded and placed in the asset KV-store. Currently, there is no way to restrict the format of data being saved. Therefore, anyone who has permission to mint asset parameters for the bridge domain is also able to store incorrect information about the bridge. Another example can be swapping assets on DEX: to make a deal one needs to be sure that the exchange rate placed in a store is correct. Thus, we need the ability to validate such data.

Possible solution

Form the data from instructions. We could have a mechanism to store data from the 'output' of some ISIsUsing permissions. Make permissions for minting special asset parameters (value types) by defining the format type either in the asset definition or in the permission ISI itself.

2. Persistence of the algorithms

...

1. Use separate ISI. It's the easiest solution, but it requires Iroha to depend on external entities.
2. Store predefined compositions of ISIs as procedures (or functions) on the Iroha's state. A procedure can be stored as an asset within a separate account with its own rights (permissions) or in an account directly. The main question here is how to prevent the user with a procedure executing other instructions (not saved as the procedure) to be sure that the contract (procedure) won't be violated.

These features should help in making bridges more safe and trustless.

...