If you have been in the blockchain space for any period of time, you are likely to have heard the phrase “smart contracts”. These are pieces of user supplied code that, once a consensus is reached, automatically perform tasks involving one or more assets on a platform.
These smart contracts can potentially grow to be quite large, grouping together loosely related functionality and making them more difficult to develop and maintain. This is likely to lead to more errors; errors which have caused a number of catastrophic financial losses.
To avoid these issues, we have developed an approach that breaks a single contract into smaller code components that can be directly associated with each asset. These can be more easily maintained so reducing the risk of errors. In addition, they allow development by separate parties, and can also be executed individually.
We call this approach Smart Assets.
Smart Assets involve commitments and expectations.
For example, if two identities, Farmer Alice and Farmer Bob, wish to trade assets, a horse for a 100 sheep, then it is possible for them to use expectations to ensure that they receive what they expected.
Farmer Alice would commit to transferring a horse and would set an expectation that Farmer Bob would transfer 100 sheep in return. Similarly Farmer Bob would commit to transferring 100 sheep and would have an expectation of a horse in return from Farmer Alice.
When the request is processed if either of these expectations are not met then the transaction will fail. Thus an identity can add rules to enforce business functionality.
Taking this further, expectations and commitments could be stored against an asset that trigger when specific operations are performed on it. This allows support for use cases that have governance requirements such as limiting the size of individual transfers.
For example, an expectation could be added to trigger when a transfer of sheep occurs. This expectation could enforce a business rule to check that a minimum of 20 sheep are being transferred. This would then be enforced on every transfer of sheep and not need to be added to each request.
In the future it will also be possible to check for state already stored in the platform such as claims and endorsements. As an example, this could be used to restrict operations on an asset type to just the identities that have had a known claim endorsed by a specific identity. Maybe a new horse can only be created on the platform if the identity adding the horse has a claim of “farmer” endorsed by a farming authority identity.
Other use cases such as the conversion of one or more asset types into different asset types based on a set of rules will also be possible using simple definitions of expectations and commitments. A request could include a number of different assets that are used to create a single new asset, for example the components for a chair could be passed (woof, materials, screws etc) and a new chair instance created.
This just touches some of the power of Smart Assets, to find out more please get in touch and one of our team will be happy to explain how our technology can help meet your business needs.