Doubts regarding Smart Contract

What exactly is Smart Contract?

Why the name Smart Contract instead of Smart function?

What is the difference between a transaction and a call?

What is the difference between contract address and wallet address?

How do I invoke a function in Smart Contract?

Hope the following content solves my doubts.

A contract is a collection of code (its functions) and data (its state) that resides at a specific address on the Ethereum blockchain. Contract accounts are able to pass messages between themselves as well as doing practically Turing complete computation. Contracts live on the blockchain in a Ethereum-specific binary format called Ethereum Virtual Machine (EVM) bytecode.
It is termed as Smart because it can execute some piece of code.

Invocation of Smart Contract:
Once your contract deployment transaction is mined into a block, any node on the network can broadcast a transaction that interacts with that contract by making calls to its address. The address can be found in the tx receipt that deployed the contract.

Note that for read-only calls, the node making the call must have synced past the block that deploys the contract. Similarly, for writing to it, the results of the write transaction (such as logs) will only be available once the write tx has been mined.

Among the most confusing topics in the world of Ethereum smart contracts is the difference between read-only calls and potentially state-changing transactions.

Local vs. verified

The Ethereum state is somewhat different from a typical database. The implications take some getting used to. Each node has a copy of the state, much like a replica, and each node independently verifies the authenticity of the state as the blocks arrive and transactions are processed locally. In this way, each node can know that its own copy of the state is legitimate.

Local copies mean that a node can explore and inspect the state without any further assistance from the network. Nodes can even run contract functions to discover what would happen if the same inputs were actually sent to the network. Since the network is not even consulted during such local explorations, the network cannot possibly know about any attempted state change. Consequently, such operations are read-only, by definition.

Callers can invoke any contract function on a local read-only basis with the call() method Web3 attaches to every contract function. This relies on local resources, and returns values sent by contract return statements. This is useful for “dry-run”, “what if” exercises. This is part of the gas cost estimation process, and this is the normal way to invoke read-only contract functions, a.k.a. “getters”.

Contract authors can hard-code this behavior into contract functions using the keywords “view” and “pure” (in the past, “constant” was used).

• view: Will read the state but will not change it.
• pure: Does not need access to the state and will not change it.

Read-only invocations, whether hard-coded at the contract level or requested with the client-side “call()” method, run much faster than transactions that require network verification.

Verified transactions that potentially change the state are sent to the network for verification. Consequently, senders don’t receive return values. Instead, they receive a transaction hash and must wait for the transaction to be mined. Even then, the return results won’t be returned and they must inspect the logs or call other functions to discover what happened.

This causes a significant delay, the mining delay, that needs to be carefully accounted for in user interface design in order to create a responsive, informative and satisfying user experience — at least if the users are expected to be human.

Does a call that does not change the state cost gas?

Remember, a client can also invoke any function using the Web3 .call() method.

In all three cases (view, pure and .call()) the following apply:

1. The contract will run on local CPU using local copy of the blockchain (if needed at all) and there will be no network verification of anything.
2. The EVM gas accounting applies and will be tracked. That is, if the contract function includes gas accounting (how much is left?) then it will work as normal in a “dry run” mode, using call(), for example. Same applies to “out of gas” situations. Sufficient gas must be supplied with the request.
3. Since there is no network verification, there is no possibility of a state change. This includes the result that ether spent to supply gas is, effectively, returned. More precisely, it was never really sent because the network wasn’t informed.