How The Code Runs:

  • Contracts react to a transaction it receives, but can’t make it’s own.
  • All nodes in the network are going to run the code. But isn’t that innefficient?
    • Yes. So every step a smart contract takes costs “gas”.
    • When you send an transaction for a contract to interact with, you must also cover the cost of “gas” (paid for in Ether). You’re thus incentivised to write optimised code.
    • Otherwise, your contract will run until it runs out of “gas”.

More On Gas:

  • User’s set a “Gas Limit”. They also set the price of each computation (Gas Price).

Gas Fairness:

Ideally, design your Smart Contracts so that computational costs (gas fees) are distributed equitably among users. It’s about avoiding where one “unlucky” user gets stuck with a massive gas bill for an action that benefits many.

  • The Unfair Scenario: A contract is raising 100 ETH. When the final contribution pushes the total over the 100 ETH goal, a function is triggered to send all 100 ETH to the campaign creator and issue refunds to every single previous contributor who overpaid. The user who made that final, goal-reaching contribution has to pay the gas for all of those refund operations, which could be hundreds of transactions. This is incredibly unfair.

  • A Fairer Solution (Creator Pays): When the goal is reached, the contract simply changes a state variable (e.g., isFunded = true;). It is now the campaign creator’s responsibility to call a separate withdrawFunds() function. The creator pays the large gas fee to receive their money, and the contract handles refunds separately.

  • The Fairest Solution (Pull Pattern): When the goal is reached, the creator can withdraw their funds, and each individual contributor becomes responsible for calling a claimRefund() function to “pull” their surplus back. This way, everyone pays their own small, predictable gas fee.