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
  • High availability and High auditability
  • Transparency and neutrality
  • Censorship Resistance
  1. LEARN
  2. Introduction
  3. 1. Ethereum Basics

1.2 Properties of the Ethereum Infrastructure

High availability and High auditability

High availability refers to the fact that Ethereum is always up and running (24 hours, 7 days a week, 365 days of the year): there's never a downtime that is expected because of upgrades or because of any issues (that's the goal) which, again, contrasts with most web2 services where they might be taken down for maintenance, upgrades or any other reasons.

High availability is given by decentralization, because of the absence of centralized infrastructure choke points that can go down and bring the whole infrastructure down with them.

High auditability refers to the fact that everything that happens on Ethereum (everything that happens on a blockchain) is auditable (it can be examined, analyzed and reasoned about).

Transparency and neutrality

The fundamental vision of Ethereum is that applications are permissionless: if somebody was to build any part of the infrastructure for Ethereum (the protocol, the Ethereum client, smart contracts...), they can do so without permission from any centralized entity within Ethereum.

The tools and the infrastructure are open sourced: you can look at it, extend it, deploy and use it without anybody's permission.

This is what lends to permissionless applications (decentralized applications), in contrast with how you build, deploy and use nowadays' mobile applications (say on the Apple platform or the Google platform) where you have a centralized entity that you have to register with, get the permission from, test with, follow the regulation set forth by the by that entity (by the Play store or the Apple store) and then deploy it while being subjected to certain "rules" that govern how you can use those apps.

This is the so-known contrast between the web3 space and the current existing web2 space. This is a key aspect of permissionless interaction, development and innovation. All this is incentivized because of the built-in economics (crypto economics) which makes people run the Ethereum nodes, deploy and use the applications.

Additionally, as it is built on a blockchain, Ethereum has a high degree of transparency: nothing is meant to be proprietary (the source code, the design of the protocols, the transactions that interact with it...) and behind pay walls, or hidden in such a way that you cannot reason about the security or transparency aspects of it.

That's, at least, the high level design goal and all these properties lend themselves to make the platform and everything that's built on it, highly neutral. We'll see more about how decentralization really contributes to neutrality because there's no centralized entity that can change the availability, auditability or transparency aspects of the platform or applications built on top of it.

Censorship Resistance

The aforementioned properties lend themselves to a very high degree of censorship resistance. This is may be something you're familiar with in existing platforms: if an app, a website or anything else does not subscribe itself to the compliance aspects of the platform or any other entity, then it might be taken away from the platform at any time by the entity that is controlling it. There are many many stories of this being done extremely wrong. There have been accidents where unintentionally some of these apps were taken down because they fit into some larger category type of applications that were being de-platformed. Blockchains in general make this very hard to do at a platform level.

Censorship leads to what is known as "lowering the counterparty risk": there is always a risk associated with the party, the platform, the application on top of it or the logic that you're interacting with. Thanks to the transparency, neutrality and censorship resistance, that risk is much much lower.

So none of this is black or white: it's all on a spectrum. We're going towards what is known as "progressive decentralization" where some of these properties might not be completely there yet. There might be elements of centralization that over time and by design are removed, so that we reach a point where these applications or platforms are completely decentralized with no single entity or groups of entities that can really manipulate the platform and abuse it. That is where we are headed towards.

Previous1.1 Ethereum: Concept, Infrastructure & PurposeNext1.3 Ethereum vs. Bitcoin

Last updated 1 year ago

📚
🔷