Reserve some TransactionAttributeTypes for experimental/private usage

[roman-khimov]

Summary or problem description
Many protocol-related experiments and extensions around transactions can start as simple attributes. Some private networks may also want to have extensions based on attributes for their internal usage. We have TransactionAttributeType and associated logic that regulates attributes, but at the moment it's not really encouraging these experiments as any type code might get used by the official node and decoding unknown attribute will always fail.

Do you have any solution you want to propose?

1. Specify a reserved range of attribute types (for example, 224-255) that could be used for experiments and private networks. These would only be compatible between nodes that support them and may differ from node to node, but official Neo node would never use them.
   That costs nothing and I think we can do it easily.
2. Add an option to allow reserved attributes on the network. For nodes that don't support some particular attribute that would just mean that they won't fail decoding it and will forward transactions containing them as usual. Nodes that support this attribute can use it for whatever purpose they want to. For mainnet this option will always be disabled (it's not for experiments). For testnet we can enable it and get an additional ability for broader experimentation without breaking the network.
   This is a bit more invasive and dangerous (think of two nodes using the same type but with a different meaning for it), but for testing purposes maybe it's worth it.

Neo Version

• Neo 3

Where in the software does this update applies to?

• P2P (TCP)

[roman-khimov]

Add an option to allow reserved attributes on the network

That would imply VarBytes encoding for reserved attribute's data, probably.

[roman-khimov]

There is a prototype now implemented in nspcc-dev/neo-go#1496, 0xe0-0xff range is used for that.

[ZhangTao1596]

We can add ExtensionAttribute with VarBytes payload and multiple allowed. Users can deserialize the payload to the structure they want.

[shargon]

Attributes are not exposed to SmartContracts, isn't it?

[ZhangTao1596]

Attributes are not exposed to SmartContracts, isn't it?

No, they aren't. https://github.com/neo-project/neo-devpack-dotnet/blob/master/src/Neo.SmartContract.Framework/Services/Transaction.cs

[shargon]

What's the sense if is not possible to use in a smart contract

[roman-khimov]

Experimental protocol extensions of various sorts. Attributes we have now mostly affect P2P/validation/mempool behavior, contracts don't care about this, same thing with #1991 or #1992.

[erikzhang]

We can add ExtensionAttribute with VarBytes payload and multiple allowed. Users can deserialize the payload to the structure they want.

Do you agree on this solution? @roman-khimov

[roman-khimov]

That essentially means using one attribute type for all potential extensions which requires further demultiplexing in practice. Could be done, but a range of attributes seems to be a bit more natural.