[LSP2] Add contract / Contract as a valid valueType + valueContent

[CJ42]

Proposal

Currently in EVM chains like LUKSO, an address can point to either a smart contract or an Externally Owned Account.
In a LSP2 schema, the address type is used in instances for metadata keys such as:

• LSP5ReceivedAssets
• LSP12IssuedAssets

However, in some cases of certain metadata, it might be important to notify strictly that the address MUST BE a smart contract.

Example where contract as value type make sense.

However, an encoding library could ensure that the addresses are actually smart contracts. In the two examples above, this is relevant as a digital has to be a smart contract (for instance, LSP7 or LSP8). In this case, the schema of LSP5 would change as follow.

Before

[
  {
    "name": "LSP5ReceivedAssets[]",
    "key": "0x6460ee3c0aac563ccbf76d6e1d07bada78e3a9514e6382b736ed3f478ab7b90b",
    "keyType": "Array",
    "valueType": "address",
    "valueContent": "Address"
  },
  {
    "name": "LSP5ReceivedAssetsMap:<address>",
    "key": "0x812c4334633eb816c80d0000<address>",
    "keyType": "Mapping",
    "valueType": "(bytes4,uint128)",
    "valueContent": "(Bytes4,Number)"
  }
]

After

[
  {
    "name": "LSP5ReceivedAssets[]",
    "key": "0x6460ee3c0aac563ccbf76d6e1d07bada78e3a9514e6382b736ed3f478ab7b90b",
    "keyType": "Array",
    "valueType": "contract",
    "valueContent": "Contract"
  },
  {
    "name": "LSP5ReceivedAssetsMap:<contract>",
    "key": "0x812c4334633eb816c80d0000<contract>",
    "keyType": "Mapping",
    "valueType": "(bytes4,uint128)",
    "valueContent": "(Bytes4,Number)"
  }
]

Other cases where address make sense

In other cases, when the specifications want to be loose to allow both either EOAs or Contracts, the address value type can be used. This is the case for instance in LSP6 for AddressPermissions[] can store a list of controllers, where these controllers can be either EOAs or smart contracts.

Additional infos

Libraries like erc725.js could check when encoding at runtime that the address being encoded is actually a smart contract, and for instance fail if it is not.

Such thing could be bypassed, by setting data keys / value pairs manually without such library, but still the library could discard entries that are not a contract from large arrays being read from the ERC725Y storage.