Hi, this is a little complicated so we are testing the Construction API using rosetta-sdk signer. We realize that for it to pass, before the signing and verifying process. we have to convert the payload into our blockchain transaction object (which adds additional param stuffs like ID, provider after converting to bytes format)
The thing is after /payloads, rosetta specifications uses the rosetta-signer package to sign the unsigned transaction -> signature whereas in our blockchain the usual way is the unsigned transaction (including public key in the json) -> transaction object -> signature.
There are 2 ways we can go about, one is if we have access to the public key during /payloads we can use the unsigned transaction, add the public key and convert it to our transaction object before spitting out the proper “unsigned transaction” for /payloads response.
The second solution is we have added the conversion process into rosetta-sdk:
Hence as per title, do we have a way to access the signer module / public key of the sender before /combine? If retrieving the public key is not feasible, is our second solution alright as we have added a considerable amount in the rosetta signer and verifier?
There is not currently a way for a Rosetta API implementation to access the public key of an address prior to /payloads if the public key cannot be found on-chain (accessible using /construction/metadata) or cannot be re-hydrated from the address (decoding address == public key).
I’d strongly discourage the “option 2” you’ve proposed as we believe the keys package should not have any network-specific information. Requiring some network-specific transaction construction during sign and verify seems like the wrong way to go.
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. A Rosetta implementation would return the public keys it needed from /construction/preprocess and they caller would provide them in the call to /construction/payloads with the retrieved metadata.
Our address is derived from a hash function, so it is impossible to re-hydrate the public key given an address.
Yes, I do agree with you that “option 2” is not the right way to go as the signer and verifier should only have one function. Having a /construction/address sounds like a great idea to complement /construction/derive. The only thing is to figure out how to incorporate this to the rosetta-cli tests given that not all blockchain require such an api. I will open an issue in the rosetta-specifications for this.