There are dozen of sources on the internet that state the view functions, which are called externally (i.e. from oustide of contract), that do not call other contracts' functions and do not change the state of the contract - consume no GAS. As long as the call is done on a local node.

I would like to hear some clarifications about what exactly considered to be a local node and what is a remote node. And how exactly does it work with web3.js library.

  1. Is the node only considered local when is run on local machine resources? i.e. addressed by web3.js by the domain name localhost.

  2. Is the node still considered local, if I host it on Azure services? i.e. it's my own local node, which is publicly available in order to use it in the front-end. I no longer use the "localhost" domain to access it. But I want to use it in order to avoid paying GAS for view functions.

  3. If I use a remote node such as infura - then do view functions start costing GAS?

  4. (in in case answer to previous question is yes) Is this possible to publish my own local node (essentially making it a remote node), so the client would still be able to call it and spend no-gas on view function?

  5. In cases when functions (otherwise-free when called locally) start costing GAS - is the cost taken from the contract?

  6. In cases when functions (otherwise-free when called locally) start costing GAS - does the call become a transaction to cover the cost? (connected to previous question)

  7. Is it so that when web3.js is used on the front-end then node is always remote. And when web3.js is used on the back-end, then the node is always local (unless local is not available, of course)?

  8. How do you use web3.js on the front-end, to allow users querying non-state-changing contract functions without a cost? I guess this is my main question which kind of summarizes why I have so much confusion about local/remote node. :)

  9. (optional - dApp architecture advice). Could you tell if there is a flaw or a global misconception in my understanding? If we always use the remote nodes on the front-end then there is no "free" transactions/calls by definition. It looks like there should always be an interface on top of the backend that accepts the "calls" from the front-end, essentially making them GAS-free. So there are always 2 instances of web3.js running. 1st - is the one that client uses to create paid transactions, 2nd - is running on the backend to make GAS-free calls that do not change state. Unless it is possible to make front-end web3.js to tell the node to use local resources for free.

Backstory: I am working on my first contract and I am new in the world of blockchain. I want to expose my contract on the internet so the user would be able to "work" with it. I don't want the user (or the contract itself) to pay for the view (non-state-changing) functions. Sorry if some questions are stupid. I don't own a node or a website (yet) :)

Please do not mark the topic as duplicate unless all questions are answered in the linked topic. Thank you.


I'll try to answer your points:

  1. A local node is a full node that you're connecting directly. Or a light node that has access to a full node. Remote nodes would be other nodes from the network that you communicate updates through transactions.
  2. Yes, it would still be a local node.
  3. No, view functions with Infura don't cost gas. They do have a limit on how much gas a call can burn, but it's just to avoid DDoS attacks from people. The gas won't be used, just calculated to avoid stuff like infinite loops that could clog their system.
  4. Nop, gas can never be taken from the contract, it doesn't matter what type of function you call. There is a thing called the "Ethereum Gas Station Network", that you can use to subsidise your user's fees if you need to, for example to improve onboarding and UX. https://www.opengsn.org/

I think the other points have been answered, but let me know if you want more clarification.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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