Skip to main content

Solidity

Solidity for EVM compatible smart contracts.

REPL

Learning Path

Fundamentals

Copy examples into Scaffold Eth then play around.

TaskDoneNotes
Primitive Data TypesYboolean, uint, int, address
MappingsTDocument best use cases
StructsYCan written external to a contract and imported
ModifiersYClean up repetitive code, example auth checks
EventsYCheap for of data storage
InheritanceYAllows multiple
PayableYAllows a method to recieve ether
FallbackYCalled when no method exists

Global Variable and MSG

Official Docs

Explanatory Articles:

Random Numbers

No easy solution with Smart Contracts.

Oracles exist to solve this problem.

Mappings

Good for single value lookups.

Use instead of arrays to hold sets of data to save time and gas.

  • Keys are not stored
  • Values are not iterable
  • Default value of type is returned

Default values, provides challenges.

Reference Types

NameRulesUse When
Fixed ArraySingle type of element; Size cannot change
Dynamic ArraySingle type of element; Size can change
MappingCollection of entities
StructStructure of an entity

Testing Solidity

Packages

Javascript Bridge

  • Cannot communicate nested dynamic arrays
  • Strings in Solidity are dynamic arrays

Context

Diagrams

Resources

Questions

When on-chain randomness is impossible without oracles, how do you design a prediction game that is both fair and trustless?

  • The Mappings table notes that values are not iterable and default values cause challenges — what patterns prevent silent bugs from uninitialized mappings in production contracts?
  • The Fallback function is called when no method exists — how does this interact with the upgrade patterns needed as smart contract logic evolves?
  • Given that strings in Solidity are dynamic arrays with a costly JavaScript bridge, when is it better to store data off-chain and reference it on-chain by hash?