Often it is a requirement to model and implement a requirements in different smart contract systems. For such a requirements it is important to know the differences between the different languages and abstraction possibilities. In our serial, we try to investigate the possibilities how Hyperledger Fabric Composer language elements can be translated into Solidity Ethereum.
A simple asset in Hyperledger Fabric Composer has some properties and some kind of a primary key:
asset TestAsset identified by primaryKey{
o String primaryKey
o String property1
o String property2
}
one way to associate it with Solidity is to implement a Solidity smart contract for that, like:
contract TestAsset {
string primaryKey;
string property1;
string property2;
}
However assets are not really handled as individual contracts but rather as a set of crypto-assets that are identified by the primaryKey. As a consequence such contracts should be embedded into a factory contract that creates and administrates the assets. One example might be:
contract TestAssetFactory {
mapping (string => TestAsset) testAssets;
function createTestAsset(string _primaryKey) {
testAssets[_primaryKey] = new TestAsset();
}}
Another option can be however that instead of contracts we use rather structs and the factory token creates a new struct instead of a new smart contract. From a point of view of gas consumption the second solutions will surely be cheaper.
