Solidity
Solidity for EVM compatible smart contracts.
REPL
Learning Path
Fundamentals
Copy examples into Scaffold Eth then play around.
| Task | Done | Notes |
|---|---|---|
| Primitive Data Types | Y | boolean, uint, int, address |
| Mappings | T | Document best use cases |
| Structs | Y | Can written external to a contract and imported |
| Modifiers | Y | Clean up repetitive code, example auth checks |
| Events | Y | Cheap for of data storage |
| Inheritance | Y | Allows multiple |
| Payable | Y | Allows a method to recieve ether |
| Fallback | Y | Called when no method exists |
Global Variable and MSG
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
| Name | Rules | Use When |
|---|---|---|
| Fixed Array | Single type of element; Size cannot change | |
| Dynamic Array | Single type of element; Size can change | |
| Mapping | Collection of entities | |
| Struct | Structure 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?