Secureum Book
  • 🛡️Secureum Bootcamp
    • 🛡️Secureum Bootcamp
    • 🙌Participate
    • 📜History
  • 📚LEARN
    • Introduction
      • 🔷1. Ethereum Basics
        • 1.1 Ethereum: Concept, Infrastructure & Purpose
        • 1.2 Properties of the Ethereum Infrastructure
        • 1.3 Ethereum vs. Bitcoin
        • 1.4 Ethereum Core Components
        • 1.5 Gas Metering: Solving the Halting Problem
        • 1.6 web2 vs. web3: The Paradigm Shift
        • 1.7 Decentralization
        • 1.8 Cryptography, Digital Signature & Keys
        • 1.9 Ethereum State & Account Types
        • 1.10 Transactions: Properties & Components
        • 1.11 Contract Creation
        • 1.12 Transactions, Messages & Blockchain
        • 1.13 EVM (Ethereum Virtual Machine) in Depth
        • 1.14 Transaction Reverts & Data
        • 1.15 Block Explorer
        • 1.16 Mainnet & Testnets
        • 1.17 ERCs & EIPs
        • 1.18 Legal Aspects in web3: Pseudonymity & DAOs
        • 1.19 Security in web3
        • 1.20 web2 Timescales vs. web3 Timescales
        • 1.21 Test-in-Prod. SSLDC vs. Audits
        • Summary: 101 Keypoints
      • 🌀2. Solidity
        • 2.1 Solidity: Influence, Features & Layout
        • 2.2 SPDX & Pragmas
        • 2.3 Imports
        • 2.4 Comments & NatSpec
        • 2.5 Smart Contracts
        • 2.6 State Variables: Definition, Visibility & Mutability
        • 2.7 Data Location
        • 2.8 Functions
        • 2.9 Events
        • 2.10 Solidity Typing
        • 2.11 Solidity Variables
        • 2.12 Address Type
        • 2.13 Conversions
        • 2.14 Keywords & Shorthand Operators
        • 2.15 Solidity Units
        • 2.16 Block & Transaction Properties
        • 2.17 ABI Encoding & Decoding
        • 2.18 Error Handling
        • 2.19 Mathematical & Cryptographic Functions
        • 2.20 Control Structures
        • 2.21 Style & Conventions
        • 2.22 Inheritance
        • 2.23 EVM Storage
        • 2.24 EVM Memory
        • 2.25 Inline Assembly
        • 2.26 Solidity Version Changes
        • 2.27 Security Checks
        • 2.28 OpenZeppelin Libraries
        • 2.29 DAppSys Libraries
        • 2.30 Important Protocols
        • Summary: 201 Keypoints
      • 🔏3. Security Pitfalls & Best Practices
        • 3.1 Solidity Versions
        • 3.2 Access Control
        • 3.3 Modifiers
        • 3.4 Constructor
        • 3.5 Delegatecall
        • 3.6 Reentrancy
        • 3.7 Private Data
        • 3.8 PRNG & Time
        • 3.9 Math & Logic
        • 3.10 Transaction Order Dependence
        • 3.11 ecrecover
        • 3.12 Unexpected Returns
        • 3.13 Ether Accounting
        • 3.14 Transaction Checks
        • 3.15 Delete Mappings
        • 3.16 State Modification
        • 3.17 Shadowing & Pre-declaration
        • 3.18 Gas & Costs
        • 3.19 Events
        • 3.20 Unary Expressions
        • 3.21 Addresses
        • 3.22 Assertions
        • 3.23 Keywords
        • 3.24 Visibility
        • 3.25 Inheritance
        • 3.26 Reference Parameters
        • 3.27 Arbitrary Jumps
        • 3.28 Hash Collisions & Byte Level Issues
        • 3.29 Unicode RTLO
        • 3.30 Variables
        • 3.31 Pointers
        • 3.32 Out-of-range Enum
        • 3.33 Dead Code & Redundant Statements
        • 3.34 Compiler Bugs
        • 3.35 Proxy Pitfalls
        • 3.36 Token Pitfalls
        • 3.37 Special Token Pitfalls
        • 3.38 Guarded Launch Pitfalls
        • 3.39 System Pitfalls
        • 3.40 Access Control Pitfalls
        • 3.41 Testing, Unused & Redundand Code
        • 3.42 Handling Ether
        • 3.43 Application Logic Pitfalls
        • 3.44 Saltzer & Schroeder's Design Principles
        • Summary: 201 Keypoints
      • 🗜️4. Audit Techniques & Tools
        • 4.1 Audit
        • 4.2 Analysis Techniques
        • 4.3 Specification, Documentation & Testing
        • 4.4 False Positives & Negatives
        • 4.5 Security Tools
        • 4.6 Audit Process
        • Summary: 101 Keypoints
      • ☝️5. Audit Findings
        • 5.1 Criticals
        • 5.2 Highs
        • 5.3 Mediums
        • 5.4 Lows
        • 5.5 Informationals
        • Summary: 201 Keypoints
  • 🌱CARE
    • CARE
      • CARE Reports
  • 🚩CTFs
    • A-MAZE-X CTFs
      • Secureum A-MAZE-X
      • Secureum A-MAZE-X Stanford
      • Secureum A-MAZE-X Maison de la Chimie Paris
Powered by GitBook
On this page
  1. LEARN
  2. Introduction
  3. 1. Ethereum Basics

1.1 Ethereum: Concept, Infrastructure & Purpose

Previous1. Ethereum BasicsNext1.2 Properties of the Ethereum Infrastructure

Last updated 1 year ago

Ethereum is a next generation blockchain that supports smart contracts to allow decentralized applications to be built on itself. Ethereum was one of the first blockchains to put forth this idea and enter into this concept of a next generation smart contract based decentralized application platform.

One of the fundamental aspects of Ethereum is the fact that it is Turing complete: Ethereum supports a Turing complete programming language. Turing completeness is a fundamental concept in computer science, which refers to the expressiveness of a programming language: what can you do with it, is the logic that you can express with that language arbitrary, is it bounded, is it unbounded...

Many of the high level languages that you may be familiar today (like C, C++, Java, Python, Rust, Golang...) are Turing complete.

Therefore, the language supported by Ethereum is expressive enough in arbitrary and unbounded ways. This property is very powerful and it affects both the design and security of Ethereum, smart contracts and the decentralized applications governed by them.

Smart contracts, given that the programming language they are written with is Turing complete, are also Turing complete. This subsequently means that these smart contracts, and the applications they govern, can encode arbitrary rules over arbitrary states in such a way that said states can be read and written using those arbitrary rules. This contributes to what is known as a state transition.

Think about finite state automatons from computer science:

  1. You have a state rule

  2. Said state rule is applied to a state

  3. The state is read and modified (which means that it is taken from state to state')

The fundamental state transition rule can be done with a Turing complete programming language in arbitrary ways without any constraints on it. These aforementioned rules can be of any kind: rules for ownership, transaction formats, state transition functions... So any state/any rule allows Ethereum to support any application on it without any artificial constraints coming from the programming language or the platform.

At a high level, Ethereum is an open source globally decentralized computing infrastructure that executes smart contracts. By design, everything in the space is open source (the protocol, the specification of the protocol itself and all the code that that actually implements that protocol) so that everything is transparent. This has big implications to security.

Ethereum uses a blockchain (namely the Ethereum blockchain) to store the various states from the smart contracts, and given that it's a blockchain, it's decentralized: there are many nodes which to agree upon and synchronize the "single view" (global state) that every node agrees on and works with.

So, what is the purpose of Ethereum as a platform? What is the vision that is being worked towards? Due to the decentralization aspect (there's not one central entity controlling the vision), a lot of these can be thought of as narratives.

Ethereum's initial purpose, put forth in the white paper, was for it not to be just a currency nor just a payment network. This becomes clearer if you are aware of how Bitcoin works: Bitcoin is a predecessor of Ethereum and a large source of inspiration, but Ethereum's vision was to go beyond it being a currency or a payment network.

There is a native currency in Ethereum called Ether (Ξ\XiΞ). Ether is divisible up to 18 decimals. The smallest unit of ether is known as wei: 101810^{18}1018 wei add up to one Ether. There are other units as well: 1 a Babbage is 10310^3103 wei; 1 Lovelace is 10610^6106 wei... These names are in honour of Charles Babbage and Ada Lovelace, which are important people that contributed a lot to computer science.

Ether is used to measure the amount of resources that is being used when smart contracts are run. This allows to constrain how long and how many resources the smart contracts use up. It is an important property because it ties with Turing completeness: since smart contracts are Turing complete, the resources and time of execution of a smart contract must be bounded so that it does not take over all the resources of the network, and consecutively collapse it.

While being integral to Ethereum, Ether is not the "be-all" or "end-all" goal of Ethereum. The idea for Ether was for it to be a utility token: you need the Ether token to utilize the benefits of the Ethereum platform, so if somebody wants to use Ethereum they need to pay using Ether. This is the high level purpose.

You have probably been reading about narratives of Ether being a store of value in a medium of exchange, or a digital gold or a world computer productive asset, things like that. These are all the narratives that are being discussed in the community. The vision of Ethereum being a world computer is enabled by its rich infrastructure.

📚
🔷