Notes
  • Blockchain
  • About this repository
  • References
  • Carret Position
  • Loggia and Balcony
  • automobile
    • Motorbike
  • computer
    • Kubernetes Event-driven Autoscaling (KEDA)
    • Protobuf
    • [[Amazon]] [[Identity and Access Management]] ([[IAM]])
    • Apdex
    • Architecture Decision Record
    • Audio
    • [[Amazon Web Services]] (AWS) Lambda
    • Blockchain
    • C/C++
    • Cache line
    • Caching strategies
    • Database
    • Design Patterns
    • Docker compose
    • Event Driven Design
    • False sharing
    • Git
    • [[Go]] common mistakes
    • [Go] [[subtests]]
    • Go
    • Janus
    • Jest
    • Kubernetes
    • Log-Structured Merge-tree
    • Media server
    • MySQL: Charset, Collation and UCA
    • Netflix
    • Opus Codec
    • Process, Thread
    • ReDoS - [[Regular expression]] Denial of Service
    • Rust
    • ScyllaDB
    • Shell Functions
    • Signals (The GNU Library)
    • Solidity
    • Sources
    • SQL
    • Transmission Control Protocol (TCP)
    • Ten design principles for Azure applications
    • Transient Fault Handling
    • twemproxy
    • Video
    • Web2 vs Web3
    • WebRTC
    • Microservice architecture
      • 3rd party registration
      • Command Query Responsibility Segregation (CQRS)
      • Access token
      • Aggregate
      • API Composition
      • API gateway/Backends for Frontends
      • Application metrics
      • Audit logging
      • Circuit Breaker
      • Client-side discovery
      • Client-side UI composition
      • Consumer-driven contract test
      • Consumer-side contract test
      • Database per Service
      • Decompose by business capability
      • Decompose by subdomain
      • Distributed tracing
      • Domain event
      • Domain-specific
      • Event sourcing
      • Exception tracking
      • Externalized configuration
      • Health check API
      • Log aggregation
      • Log deployments and changes
      • Messaging
      • Microservice architecture
      • Microservice Chassis
      • Multiple Service instances per host
      • Polling publisher
      • Remote Procedure invocation
      • Saga
      • Self-contained service
      • Self registration
      • Server-side discovery
      • Server-side page fragment composition
      • Serverless deployment
      • Service Component test
      • Service deployment platform
      • Service instance per Container
      • Service instance per VM
      • Service mesh
      • Service per team
      • Service registry
      • Service template
      • Shared database
      • Single Service instance per host
      • Transaction log tailling
      • Transactional outbox
  • food-and-beverage
    • Cheese
    • Flour
    • Japanese Plum liqueur or Umeshu
    • Sugar
  • management
    • Software Engineering processes
  • medic
    • Desease, disorder, condition, syndrome
    • Motion Sickess
  • others
    • Elliðaey
    • ASCII art
    • Empirical rule
    • Hindsight bias
    • Outcome bias
    • Tam giác Reuleaux
    • Luật Việt Nam
  • soft-skills
    • Emotional intelligence
Powered by GitBook
On this page
  • Web3 benefits
  • Practical comparisons
  • Web3 limitations
  • Centralization vs decentralization
  • Further reading
  1. computer

Web2 vs Web3

https://ethereum.org/en/developers/docs/web2-vs-web3/

[[Web2]] refers to the version of the internet most of us know today. An internet dominated by companies that provide services in exchange for your personal data. [[Web3]], in the context of [[Ethereum]], refers to decentralized apps that run on the blockchain. These are apps that allow anyone to participate without monetising their personal data.

Web3 benefits

Many Web3 developers have chosen to build dapps because of Ethereum's inherent decentralization:

  • Anyone who is on the network has permission to use the service – or in other words, permission isn't required.

  • No one can block you or deny you access to the service.

  • Payments are built in via the native [[token]], [[ether]] ([[ETH]]).

  • Ethereum is turing-complete, meaning you can pretty much program anything.

Practical comparisons

Web2
Web3

Twitter can censor any account or tweet

Web3 tweets would be uncensorable because control is decentralized

Payment service may decide to not allow payments for certain types of work

Web3 payment apps require no personal data and can't prevent payments

Servers for gig-economy apps could go down and affect worker income

Web3 servers can't go down – they use Ethereum, a decentralized network of 1000s of computers as their backend

This doesn't mean that all services need to be turned into a dapp. These examples are illustrative of the main differences between web2 and web3 services.

Web3 limitations

Web3 has some limitations right now:

  • Scalability – transactions are slower on web3 because they're decentralized. Changes to state, like a payment, need to be processed by a miner and propagated throughout the network.

  • UX – interacting with web3 applications can require extra steps, software, and education. This can be a hurdle to adoption.

  • Accessibility – the lack of integration in modern web browsers makes web3 less accessible to most users.

  • Cost – most successful dapps put very small portions of their code on the blockchain as it's expensive.

Centralization vs decentralization

In the table below, we list some of the broad-strokes advantages and disadvantages of centralized and decentralized digital networks.

Centralized Systems
Decentralized Systems

Low network diameter (all participants are connected to a central authority); information propagates quickly, as propagation is handled by a central authority with lots of computational resources.

The furthest participants on the network may potentially be many edges away from each other. Information broadcast from one side of the network may take a long time to reach the other side.

Usually higher performance (higher throughput, fewer total computational resources expended) and easier to implement.

Usually lower performance (lower throughput, more total computational resources expended) and more complex to implement.

In the event of conflicting data, resolution is clear and easy: the ultimate source of truth is the central authority.

A protocol (often complex) is needed for dispute resolution, if peers make conflicting claims about the state of data which participants are meant to be synchronized on.

Single point of failure: malicious actors may be able to take down the network by targeting the central authority.

No single point of failure: network can still function even if a large proportion of participants are attacked/taken out.

Coordination among network participants is much easier, and is handled by a central authority. Central authority can compel network participants to adopt upgrades, protocol updates, etc., with very little friction.

Coordination is often difficult, as no single agent has the final say in network-level decisions, protocol upgrades, etc. In the worst case, network is prone to fracturing when there are disagreements about protocol changes.

Central authority can censor data, potentially cutting off parts of the network from interacting with the rest of the network.

Censorship is much harder, as information has many ways to propagate across the network.

Participation in the network is controlled by the central authority.

Anyone can participate in the network; there are no "gatekeepers." Ideally, the cost of participation is very low.

Note that these are general patterns that may not hold true in every network. Furthermore, in reality the degree to which a network is centralized/decentralized lies on a spectrum; no network is entirely centralized or entirely decentralized.

Further reading

PreviousVideoNextWebRTC

Last updated 2 years ago

Feb 6, 2017 - Vitalik Buterin

Feb 18, 2018 - Chris Dixon

Dec 31, 2019 - Max Mersch and Richard Muirhead

The Meaning of Decentralization
Why Decentralization Matters
What Is Web 3.0 & Why It Matters