1

As of now whenever I try to perform any operation by invoking any of the methods of a contract it expects to unlock the account. Now the account which is used to perform the transaction, has to pay the price to perform the transaction.

So in a live environment want to understand how it works.

Lets say have a Book Lending DApp where one user can lend books by invoking a method of DApp. Hoping that the web interface of the DApp will be hosted on a server and the contracts are deployed on the block chain. The contract instances are initialized and the addresses are used internally in the DApp.

We know that the host name and port of the blockchain node is configured in the web app.

Questions:
1. So want to understand how will that single instance of the DApp will be used to be invoked by each node in the blockchain network?
2. In the web interface how to determine current user's address dynamically?
3. Is the user expected to keep his/her account unlocked while performing activities on the DApp otherwise every time when performing any transaction unlock it manually?

Am sure missing something pretty obvious.

Improve this question

1 Answer 1

Reset to default
1

Q1: You can configure the universal web interface to look for RPC on localhost:8545 (default) and/or check browser (isMist?) to consider using special capabilities in the front-end.

Q2: You can interrogate the wallet:

var account;
web3.eth.getAccounts(function(err, accounts) {
  var account = accounts[0];
});

... or even let the user select from the available accounts.

Q3: Most (D)apps read from the backing system more then they write to it. You can "hard wire" read-only contract functions with the keyword constant, indicating that the function will not change the contract state. Or, you can transform any contract invocation into a read-only "dry run" by appending .call() in web3. That means your user can browse the Dapp, but the wallet account will have to be unlocked in order to sendTransaction(), i.e. do something that changes the state.

Improve this answer
4
  • Thanks for your reply Rob! I have added my queries against your answers.
    – Susmit
    Mar 23, 2017 at 4:55
  • Q1: It means all clients need access "A" node. It can be a full node or (future) light client and "client" can be a browser or a server. Q2: The "local" node has the private keys for owned accounts. Use web3.eth.getAccounts() for personal accounts. Q3: You don't want the encourage accounts unlocked at all times. Mist and MetaMask do a good job of prompting the user when needed. Other browsers can prompt the user. Only needed to send a state-changing transaction. This is a front-end concern that we can expect to improve over time.
    – Rob Hitchens
    Mar 23, 2017 at 13:50
  • Updated code. This is "personal" accounts on the node.
    – Rob Hitchens
    Mar 23, 2017 at 13:54
  • Is there a way that I can accept the password from the user on the web interface and invoke unlockAccount method dynamically. So that I can remove the manual dependency to accept password from the client (i.e. Mist or MetaMask). This way which ever account i use to perform the transaction i can dynamically unlock it.
    – Susmit
    Mar 24, 2017 at 1:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.