Deprecate public_keys field in ConstructionMetadataRequest

[jingweicb]

Deprecate the public_keys field in the ConstructionMetadataRequest endpoint

The ConstructionMetadataRequest endpoint includes the public_keys field, which is optional. Our team is looking to remove this field from the ConstructionMetadataRequest endpoint.

Why we want to remove it

1. Safety reasons - We do not want to expose any keys in Rosetta online nodes.
2. Lack of use - Based on our research, no Assets use this field at this time.
3. Removes duplication - Any Aseet Issuers (AIs) that want to request a public_key value can use the options field in the ConstructionMetadataRequest endpoint to accomplish this task.

Potential risks

1. The possibility that we failed to detect AIs that are using this field.
2. For some AIs, the public_keys field is necessary, and updating the options value is not a good option for them.

Solution

After removal of the public_key field, the the ConstructionMetadataRequest would look like this:

{
    "network_identifier": {
        "blockchain": "bitcoin",
        "network": "mainnet",
        "sub_network_identifier": {
            "network": "shard 1",
            "metadata": {
                "producer": "0x52bc44d5378309ee2abf1539bf71de1b7d7be3b5"
            }
        }
    },
    "options": {}
}

• If there are no objections within the next two weeks (ending on August 12th, 2022), we will remove the public_key field from ConstructionMetadataRequest.
• If some AIs are using the field, we will work with them to remove it and enable it in options.
• We will work with all potential comments case by case

Backward compatible

No

[GeekArthur]

Suggest to add a sample of ConstructionMetadataRequest as proposal for enabling public keys in options in case the asset issuers (the public_keys field is necessary) need to directly refer it

[jingweicb]

good idea, but its depended on AIs implementation/logic.
and enabling public keys in options is a workaround, the best practice I think will be not to expose public_keys here

[ghost]

Some assets do require a secondary mechanism for identification that requires these public keys. It would become a problem to remove them and since its already an optional field for public keys, the risk factor on leaving it in should be minimal.

[patrick-ogrady]

This is why it was added to begin with 👍

[patrick-ogrady]

Some crypto schemes require the public key to be passed in for Rosetta to work properly basically.

[jingweicb]

@patrick-ogrady do you think add some information to the options could be a potential workaround?
e.g add the address or public_key in the options?

[patrick-ogrady]

Background on this convo is here:

• Provide PubKeys to /construction/metadata #46
• Access PublicKeys During Construction #45
• https://community.rosetta-api.org/t/any-way-to-get-public-key-from-signer-package-before-combine/189
• Need a way to derive the public key from an address - e.g. /construction/address #43

TL;DR this was needed for some reason:

Would you mind opening an issue in rosetta-specifications for this? I think the best way to handle this would be the addition of a /construction/address (or something like it) that could be used to get the public keys of various addresses if they are needed in the construction process. 

[patrick-ogrady]

As a design principle, I tried to avoid referring people to the options/metadata as much as possible. The purpose of Rosetta was to provide abstractions over common flows rather than being a transport protocol (options/metadata is basically unstructured/untestable shuffling of network-specific JSON to the Node). In my experience, these sort of approaches are exceptionally fragile and fail exactly when you don't want them to.

For these reasons, an optional, but structured field seemed like the right compromise. I agree, it feels weird to have to pass a public_key to the node to construct a tx though. It is definitely possible to remove this on the grounds of security but I wouldn't recommend options as a fix, just that the underlying chain needs to have an alternative construction path.