SMART CONTRACTS, DEFI & WEB3 SECURITY - Chapter 5, Exercise 2 Solution
==========================================================
Why getCount() Skips the Signature Prompt but increment() Doesn't

PROBLEM
-------
Using this chapter's own five-step interaction flow, explain
specifically why step 2 (reading getCount()) doesn't trigger a
MetaMask signature prompt, while step 3 (increment()) does.

SOLUTION
--------
The deciding factor, established back in Course 2 Chapter 1 and
Chapter 2, is whether the function actually modifies the contract's
own on-chain state.

getCount() is marked view (Chapter 1) - it only reads the existing
value of the count state variable and returns it, without changing
anything. Because it doesn't modify state, Chapter 2 explained that a
call like this can be executed locally, directly by the RPC node
provider (this chapter's own third stack layer), without needing to be
broadcast as a real network transaction at all. Since there's no real
transaction being created, there's nothing for the user to sign, and
therefore nothing for MetaMask to prompt about - the whole operation
never leaves the "just asking a node what a value currently is" stage.

increment(), by contrast, has no view or pure modifier, because it
genuinely writes a new value to the count state variable (Chapter 1).
Changing on-chain state permanently requires a real, gas-paying
transaction, per Chapter 2 - and any transaction that will actually be
broadcast to the network must first be signed with the user's own
private key to prove they authorized it (Course 1, Chapter 2). Since
this chapter established that MetaMask, not the website, is the only
thing that can produce that signature, calling increment() has to pause
and show the user a real approval prompt before anything can proceed.

ANSWER: getCount() is a view function that only reads state, so it can
be answered locally with no real transaction and therefore nothing to
sign. increment() genuinely modifies state, which requires a real,
broadcast transaction - and any transaction needs the user's own
signature, which is exactly what triggers MetaMask's approval prompt.

----
WHY THIS WORKS AS AN ANSWER

This ties the observed behavioral difference (no prompt vs. a prompt)
directly back to the underlying technical distinction (view/no state
change vs. a real state-changing transaction) established in earlier
chapters, rather than treating it as an arbitrary UI difference.