contracts: submit pre-signed transaction

[CedarMist]

Fixes #179:

Error: Un-enveloped data was passed to sendRawTransaction, which is likely incorrect. Is the dapp using the Sapphire compat lib correctly?

I have added tests transaction envelope tests:

✔ Wrapper encrypts self-signed transaction calldata (4038ms)
✔ Other-Signed transaction submission via un-wrapped provider (4223ms)
✔ Other-Signed transaction submission via wrapped provider (4115ms)
✔ Self-Signed transaction submission via wrapped provider (4061ms)

This slightly modifies sapphire.wrap behavior so if it receives a signed but unencrypted transaction from an address which it can't sign for the transaction will pass through as-is.

[CedarMist]

The repackRawTx function rejects things that it could easily handle.

And if you CBOR encode the envelope you end up with the contract receiving CBOR encoded data, rather than the calldata...

[CedarMist]

This will fix #179

[CedarMist]

There are a few scenarios we want to handle with sendRawTransaction:

• User submits signed but unencrypted transaction
  • Will be unable to encrypt, as that requires re-signing
  • Submits unencrypted transaction to RPC endpoint
• User submits signed & encrypted transaction
  • Pass it verbatim to RPC endpoint
• User submits unsigned unencrypted transaction
  • Sign it, encrypt it & submit to RPC endpoint

However, currently the wrapper will raise an error if you submit a transaction signed by somebody else. This matches Ethers behavior.

If you submit a pre-signed but unencrypted transaction to a provider, it won't be able to encrypt it because no signer exists. (Error: signing transactions is unsupported (operation="signTransaction", code=UNSUPPORTED_OPERATION, version=providers/5.7.2)

The Ethers API doesn't let you submit pre-signed transactions to a signer, it requires you decode it and re-submit it in the Deferrable<TransactionRequest> format.

Realistically, this means the sapphire wrapper, with Ethers, cannot re-encrypt pre-signed transactions even when the tx signer matches the address of the Ethers signer.

And the contract is unable to get the calldata public key, so it can't trust that if it encrypts something with a key provided by the user that they won't be able to intercept it.

[CedarMist]

So... looks like the error I want to fix is fundamentally unfixable.

But, instead I added a test to make sure the EIP155 module can sign and submit transactions, and that transactions submitted by the wrapped provider are encrypted.

[CedarMist]

So I can fix this error where we submit pre-signed transactions through the provider which is attached to a signer with a different address. But we can't automatically encrypt pre-signed transactions.

[matevz]

So I can fix this error where we submit pre-signed transactions through the provider which is attached to a signer with a different address. But we can't automatically encrypt pre-signed transactions.

Why not? Encryption with an ephemeral key derived from the runtime and the client key has nothing to do with who signed the tx.

[CedarMist]

Why not? Encryption with an ephemeral key derived from the runtime and the client key has nothing to do with who signed the tx.

The calldata is signed, modifying the calldata by wrapping it in an encrypted envelope would invalidate the existing signature.

When I use:

const [owner] = await ethers.getSigners();
const provider = testContract.provider;
const wallet = sapphire.wrap(owner.connect(provider));

The repackRawTx function encrypts the calldata then asks the signer to re-sign the modified transaction, however with the JSON-RPC Signer it's

Error: cannot alter JSON-RPC Signer connection (operation="connect", code=UNSUPPORTED_OPERATION, version=providers/5.7.2)

If I wrap the owner directly, e.g. const wallet = sapphire.wrap(owner); I get:

Error: signing transactions is unsupported (operation="signTransaction", code=UNSUPPORTED_OPERATION, version=providers/5.7.2)

And only via creating a new ethers.Wallet directly and connect() it to the provider does it work because it can sign the transaction.

If this happens via MetaMask and the dApp signs a transaction without encrypting it then sends it through a wrapped signer it will try to encrypt it before submission.

I have slightly modified the behavior and added test cases so it you pass a transaction not signed by the signers address it will not attempt to encrypt it and pass it on. This makes submitting the gasless transactions easier because you don't need to setup a different unwrapped provider to submit it.

---

[CedarMist]

This may be relevant: #106

[aefhm]

Non-blocking comments.