[ERTP] ERC1155 Example

[katelynsills]

We should write up a ERC1155 example. For instance, let's say that we want to represent an asset that is the combination of two fungible assets. The extent might be { apples: 5, oranges: 10 }. We would want to be able to add this to { apples: 1, oranges: 2}. In ERTP this would be just writing up the extentOps for this, and everything else in ERTP would work the same as usual due to the polymorphic nature of extentOps.

[erights]

Mostly a historical note, but relevant to what we might do.

Once upon a time, I think when our current UnitOps were called Assays, I did something that would now be called a MetaUnitOps, for creating units whose extents were sets of other units, each defined by their own unitOps. It will take some digging to find out where it remains in some github repository somewhere.

At the time, it was much more complex and hard to understand than what we actually needed, which turned out to be the "Uni"s, used for invites. However, it would be a generalization of the functionality of ERC1155 described above. (I make no claims about ERC1155 beyond the description above, because I haven't looked.)

1 apple would be a unit whose label is the label of fungible apple unitOps and whose extent is 1. 2 oranges would be a unit whose label is the label of the fungible orange unitOps and whose extent is 2. We would then have a metaUnit whose label is the label of the metaUnitOps and whose extent is a set containing the 1 apple unit and the 2 orange unit.

This uses the identity of the contained unitOps as the non-fungible-token identity distinctions. To directly mirror the ERC1155 functionality described above, each of those would be simple fungible units. But the metaUnits approach imposes no such restriction. It can be an arbitrary mix of other kinds of units.

However, we might still find the general metaUnits approach too hard to understand, in which case we could special case it. One possibility we have now, that we didn't have then, is to go meta at the extentOps level rather than the unitOps level. This might be much less confusing.

[katelynsills]

We don't have the motivating problems listed here:

Tokens standards like ERC-20 and ERC-721 require a separate contract to be deployed for each token type or collection. This places a lot of redundant bytecode on the Ethereum blockchain and limits certain functionality by the nature of separating each token contract into its own permissioned address. With the rise of blockchain games and platforms like Enjin Coin, game developers may be creating thousands of token types, and a new type of token standard is needed to support them. However, ERC-1155 is not specific to games and many other applications can benefit from this flexibility.

New functionality is possible with this design such as transferring multiple token types at once, saving on transaction costs. Trading (escrow / atomic swaps) of multiple tokens can be built on top of this standard and it removes the need to “approve” individual token contracts separately. It is also easy to describe and mix multiple fungible or non-fungible token types in a single contract.

We can mint many different token kinds in the same contract. Furthermore, we can reuse code easily, both at the library and contract installation levels. We also can transfer multiple token types at once, and Zoe allows us to make offers for multiple kinds at once.

Given that we don't have the same motivations, I'm going to close this until we have a motivation, at which point, we should create a new issue.