2

I am aware that metamask will enable effective security for processing via the web browser a payable function action to a smart contract.

What happens in batch?

I have an API service which then needs to call payable functions in smart contracts. There would be no direct human involvement in the call. It would be all machine based.

Is there a secure way to call the function so that the private keys are not exposed on the server or in the code under these conditions?

I wondered if truffle would work for this.

Trevor Lee Oakley
  • 2,327
  • 2
  • 19
  • 48

2 Answers2

0

If you are running in batches, on a schedule, you could presign the transactions offline, and simply broadcast them when you want to process them.

There is no way to sign transactions in realtime without having a key somewhere. It doesn't necessarily have to be on the primary server, but it will have to be on some system that your primary server can request a signature from.

Raghav Sood
  • 4,040
  • 2
  • 11
  • 20
  • That then means a rawTransaction can then be executed without any other checks? Is that a security risk anyway? But how metamask store the private keys securely? When I use metamask, I just enter my password, so it must store the private key somewhere. Can the same method be used but in batch? – Trevor Lee Oakley Oct 11 '18 at 13:36
  • It stores your private key locally somewhere in the browser extension storage. If you have presigned transactions prepared with incrementing nonces on an offline machine, you can broadcast them at any time without requiring the private key. You still need the key to sign it offline, though. – Raghav Sood Oct 11 '18 at 13:40
0

MetaMask is a user-facing solution that requires authorization. It's not really suited for "batch" operations like spraying tokens on a large list of users.

For the latter, you would usually use a server with an unlocked account to iterate over the list, sign and send. The private key will be there, but it might be in a file like .secret that is carefully guarded. It is certainly not presented to the public.

Transactions are asynchronous and the nonce is managed by the sender. What works for a single transaction:

  • sign
  • send
  • verify
  • repeat

... doesn't work for efficient batch processes and are more like:

  • sign, sign, sign, sign ...
  • send, send, send, send ...
  • verify, verify, verify ...

You have to manage the nonce and know the nonce of each transaction, especially the next because the blockchain can't reliably tell you where you are. And, if a single transaction is jammed up (gas too low?) then everything behind it will also fail to verify. That means you will have to deal with cancel and retry.

Have a look over here for a slightly more technical discussion of the options. Concurrency patterns for account nonce

Some implementations use on-chain contracts that accept an array of accounts/jobs and process them in one gulp.

Hope it helps.

Rob Hitchens
  • 55,151
  • 11
  • 89
  • 145