Contract deployment workflow with truffle/ether-pudding

Question

I've managed to deploy a contract on geth by unlocking the account of the node. (How this would work in production I have no idea, as I think it would pose a security risk)

Now I connect with my truffle app to the local geth node (connecting my truffle app to the testrpc works completely, with callbacks etc.)

What I'm missing is the 10 accounts & 10 private keys that I get with testrpc on my geth account.

Correct me if I'm wrong, but I could add these in my genesis.json, but they are different each time I start the testrpc, but the same when I start geth.

What I'm missing, or can't see any clear instructions or workflow for, is switching between the two.

Where would I start when I want to test it on a geth (or other eth node) instance?

Main issues:

• I can't influence the accounts being used/created with testrpc, only the number of default accounts.
• When I successfully deploy contracts and compile .sol.js files and the addresses match the ones registered in the geth instance, I do a transfer, but the promise callback (then) doesn't get triggered, whereas on the testrpc it does.

The callback in question:

    shares.sendShares(destinationAccountId, amount, {from: accountId}).then(function() {

       return getShares(accountId, function(val){
         store.dispatch(setSendStatus("Shares Sent!", val))
       })      

       return getDestinationShares(destinationAccountId, function(val){
         store.dispatch(setDestinationStatus("Shares received!", val))
       });

  })

• Right now, I'm just retrieving the accounts array and use the 0 and 1 of that, what if I want a default existing account integrated in testrpc?

Not sure how relevant, but my genesis.json: (from: http://tech.lab.carl.pro/kb/ethereum/testnet_setup)

  {
    "nonce": "0x0000000000000042", 
    "mixhash": "0x0000000000000000000000000000000000000000000000000000000000000000", 
    "difficulty": "0x4000", 
    "alloc": {},
    "coinbase": "0x0000000000000000000000000000000000000000", 
    "timestamp": "0x00", 
    "parentHash": "0x0000000000000000000000000000000000000000000000000000000000000000", 
    "extraData": "Custem Ethereum Genesis Block", 
    "gasLimit": "0xffffffff"
  }

Answer 1

I've managed to deploy a contract on geth by unlocking the account of the node. (How this would work in production I have no idea, as I think it would pose a security risk)

I'm assuming you've used the console to unlock the account and not a scripted approach through JSON-RPC (which can be easily invoked from web request command line tools or browsers).

In production one would most likely use a secure network (with rigorous firewall rules, etc.) and run sensitive operations (which expose the private keys used to sign transactions) within there and synchronize with external peers.

It is also possible to write an SSL wrappers over current client implementations so that accessing client endpoints requires mutual authentication. This way the host running the Ethereum client can control who is connecting to it.

Now I connect with my truffle app to the local geth node (connecting my truffle app to the testrpc works completely, with callbacks etc.)

What I'm missing is the 10 accounts & 10 private keys that I get with testrpc on my geth account.

Correct me if I'm wrong, but I could add these in my genesis.json, but they are different each time I start the testrpc, but the same when I start geth

You can assign balances to addresses in the genesis block (see the alloc key) but make sure you store the private keys used to generate those addresses as they are required if you later want to make use of the balance.

Regarding testrpc, there is an example usage here that shows how to assign balances to accounts.

Main issues:

I can't influence the accounts being used/created with testrpc, only the number of default accounts.

See the above link/other answer.

When I successfully deploy contracts and compile .sol.js files and the addresses match the ones registered in the geth instance, I do a transfer, but the promise callback (then) doesn't get triggered, whereas on the testrpc it does.

What do you mean registered in he geth instance? Created accounts using geth? If so you might be using different accounts for geth and testrpc.

Answer 2

You can influence the accounts:

$ testrpc --account="<privatekey>,balance" [--account="<privatekey>,balance"]