Unstoppable Applications


How to use the slides - Full screen (new tab)
Slides Content
--- title: Unstoppable Applications description: Unstoppable Applications in web3 duration: 1 hour ---

Unstoppable Applications

Notes:

Much like tokenomic design, that is a large component in unstoppable apps that incorporate cryptocurrency or other motivating factors, this lesson is far far too short to give you all the tools and techniques to make a robust DApp design.

Instead we strive to highlight the problem space we face and some classes of solutions to them.


Motivation

So far, we have discussed state machines and consensus... in isolation.

Does the contexts in which they operate within matter?

Notes:

  • So far mostly on simplified, idealized systems.
    • "Black boxes" of cryptography
    • Rational actors and assumed complete models of behavior in economics
    • Blockchains as an "isolated system" of sorts - external systems cannot be reasoned about in the same way... We will talk about the Oracle Problem.
  • In practice there are far more "unknown unknowns" and "black swan" behavior. More to come on that in this lesson.

Discussion

What properties of a system make it "stoppable"?

Notes:

  • Web2 context: central providers & authorities, ...
  • Web3 context: decentralized, ...
  • What properties of a system make it "stoppable"?

Unstoppable Apps Properties

  • Anitfragile
  • Trustless*
  • Censorship-less*
  • Accessible*
  • ...perhaps more?

Notes:

The "*" indicates the web3 context for defining properties, not generally. Not all of these can apply, nor is is possible all simultaneously apply. We need to craft the system properties based on what we must achieve. In reality we strive for Absolute Unstoppability, but likely cannot grantee it in every possible scenario.


Anitfragile

Some things benefit from shocks; they thrive and grow when exposed to volatility, randomness, disorder, and stressors and love adventure, risk, and uncertainty. Yet, in spite of the ubiquity of the phenomenon, there is no word for the exact opposite of fragile. Let us call it antifragile. Antifragility is beyond resilience or robustness. The resilient resists shocks and stays the same; the antifragile gets better.

-- Antifragile --

Notes:

  • Read Antifragile quote, recommend book recommended, see the links throughout slides for more after class.
  • Hydra fable & lore: https://en.wikipedia.org/wiki/Lernaean_Hydra - even though can be almost completely destroyed, it is resilient and recovers. Absolutely Unstoppable doesn't mean it cannot be damaged or even paused temporarily, it means it cannot cease to exist and will eventually recover, and ideally come back stronger in doing so.

An N-lemma

Hypothesis: a absolutely Unstoppable App cannot exist.

We must make trade-offs out of all N properties
that a absolutely Unstoppable App would possess.

Notes:

As with crypto, we can have astronomically good odds... But they are not perfect. We want the most robust system possible, given the environment and context the consensus system lives in.

More relevant trilemma:


Web3 Tech Stack

Notes:

This diagram is a bit dated with advancements in the field, but a good approx. representation.

Observation and clarification: DApps canonically refer to smart contract applications. These exist within the context of consensus systems that themselves inherit properties of unstoppability from. The academy is more focused on consensus system engineering - we reason about blockchains themselves - rather than "DApp"s that use those as platforms to operate in or on. The Smart contracts lessons may include detains on unstoppable dapps design considerations.


Much More Than Blockchain Architecture...

Blockchains only form one part of the stack.

Web3 applications must prevent attacks at all layers.

  • Networking
  • Consensus
  • Node access
  • Validator power
  • Inter-consensus trust
  • Human factors
  • Extrinsic factors

Notes:

These are for discussion today, but there are many more thank those listed here!


Human Level


Attacking Web3

Notes:

Key point: your "perfect" system in is likely weak to things outside of the "rules"! especially

Image Source: https://xkcd.com/538/

---v

Web3 Criticisms

There are valid criticisms of how many Web3 apps operate today.

  • Humans are cheap & lazy...
    No individuals run servers.
  • RPC node providers
  • A protocol improves
    slowly vs. a platform.
  • False marketing,
    frauds, & scams!

Notes:

https://moxie.org/2022/01/07/web3-first-impressions.html great critique on the state of the space, but founder of Signal messenger.

Not all hope is lost! This is valid mostly in the present, we will discuss these and what we're building to realize a better stack.


Systems Level

---v

Prove it!

We use the word "proof" a lot...
it means many things in different contexts:

  • Math โ†’ Provable Correct (algo)
  • Consensus โ†’ Proof of X (security)
  • Crypto โ†’ [ZK | VRF | Validity | ... ] Proofs

Notes:

The one so far not covered is Provable Correctness - where we can use maths to prove that our logic cannot do unexpected behavior. An interesting example is Cardano's design value proposition using haskell and provably correct most parts of their platform.

We have a lesson and exercise on formal verification methods latter on - this is how we can approach Provable Correctness in the context of Rust and thus Substrate.

BUT this property assumes a complete system model! Nuke proposes that when considering factors outside the consensus system, there cannot be a rigorous proof of correctness as we cannot model the universe.

---v

๐Ÿ”ฎ Oracle Problem

An oracle provides eternal data to a consensus system.
(i.e. a partial state of an external chain)

The oracle problem relates to the trust in the oracle.

Notes:

  • Example: Random Oracle, NOT like VRF we saw in the crypto module that can be in the consensus system.
  • Oracle needed for input from anything that lives outside of the boundary of the consensus system.
    • Everything in a chain is self-referential. Applications in a consensus system may want to try and reason about something outside itself.
  • Inclusive of bridges

---v

๐Ÿฆข Black Swans

  • known bounds of operation
    assumed impossible
  • death spirals

Notes:

Explain example of luna or other system collapse.

---v

๐Ÿคฏ Complexity

  • Illustrating how to map the intricacies of coupled, complicated, interactions of systems.
  • * You are not expected to understand this plot ๐Ÿ˜…

Notes:

Example: irrational actors can be represented in a very simple model as a completely random act, or opposite act of what a rational actor would do. If you "fuzz" you system you may discover fragility to irrational actions that could undermine your system. Perhaps it's far easier and more likely than it at first appears to experience a black swan event.

  • Image source - Describes the various categories of uncertainty, epistemology limits and statistical subjects touching on Taleb's Black swan / antifragility etc. ideas

---v

๐Ÿ‘ช Dependency

Notes:

  • yes in software and hardware, you are at risk of attack from poisoned deps through non-maintenance, up to targeted exploitation. One mitigation is vendoring these, need systems inn place to monitor. Dependabot is not sufficient.
  • Also in dependance on specific operational contexts. For example that it is legal to operate the software for nodes.

Image source: https://xkcd.com/2347/

---v

๐Ÿฆธ Dependency in Polkadot

Foundational to Polkadot ecosystem!

Notes:

  • Jaco is effectively the only maintainer of how just about everything communicates with Substrate nodes!
  • Capi is on the way, but just getting started.

---v

๐Ÿ™ˆ Unknown unknowns

Notes:

Outside of the system itself, we cannot guarantee/prove that every possible condition is accounted for in our models & system design. We must expect forces outside our system & it's model may interact in unexpected ways. Assumptions about context must be rigorously evaluated (i.e. - what does finality mean in the chain this pallet or contract lives in?) (Formal mathematical proofs reason only about the things we can and do account for.)


Network Level

---v

๐Ÿ•ธ๏ธ Peer-to-Peer Networks

---v

Network Attacks

  • Entry/Boot nodes and peer discovery
  • Data center faults
  • Traffic analysis and targeted takedowns
  • Eclipse attacks

Notes:

The network lesson covers these, just a reminder that the network is not in the direct command of the consensus system, so it's a threat!

  • security & stability
  • privacy! On chain might be ZK, but how about the gossip and RPCs?

Boot nodes typically hard coded to "bootstrap" and start peer discovery. Boot nodes can decide what peers to advertize, or can be inaccessible. Common data centers (AWS, GCP, ...) could fail or censor, potentially large number of peers go dark. Hard to hide! Most p2p traffic is easy to identify vs. web2 traffic.

---v

Node Queries

Running a node is hard, most people outsource.

These service have power to deceive, censor, and surveil.

---v

Multi-Chain Applications

If running one node is burdensome, try multiple.

---v

Trustless Messaging

In order to handle messages without trust,
systems must share common finality guarantees.

A should never process a message from B,
where B is reverted and A is not.

---v

A Note on Synchronicity

Smart contracts on a single chain (e.g. Ethereum)
can interact trustlessly because of their shared view of finality.

Asynchronous systems can also share finality.
i.e., be members of the same consensus system.

---v

Discussion

Minimum viable decentralization.

What key aspects should be considered?

Notes:

  • Quantitative: nodes needed (for what), incentives, ... FIXME TODO
  • Qualitative: social norms, ... FIXME TODO

Consensus

---v

Mining Pools

Proof of Work authority sets have no finite bound.
But people like to organize.

[Collaborating | Colluding] authority sets creates risk.

Notes:

Call out that Nomination pools exist and are discussed in the NPoS lesson latter. Similar issues, but in a more bounded set.

---v

Mining Pools

Notes:

Source: Buy Bitcoin Worldwide

---v

Security Dilution

Security is always a finite resource:

  • Centralized: Cost of corruption/influence
  • Proof of Work: Number of CPUs in the world
  • Proof of Stake: Value (by definition, finite)

---v

Security Dilution

Consensus systems compete for security,
and they have reason to attack each other.

Emergence of obscure/niche "Proof of X" algorithms
to shelter from attack only goes so far.

---v

โš” Blockchain Wars

Systems with high security have the
incentive to attack systems with low security
whom they perceive as competitors.

For fun and profit.

Notes:

"In a galaxy the universal consensus far far away not so far away..."

---v

โš” Proof of Work Battles

What might it cost to successfully attack?

Notes:

  • For PoW, hashing power for the same algo can be attacked! Buying hash power is possible:
  • Most GPU miners switch tasks to the mine the highest paying (relative to some base currency) chain using software like https://www.nicehash.com/.
  • ASICs are less flexible, but also can to the highest paying coin.
  • Example: ETH classic deep re-ogs

---v

Proof of...
Nothing at Stake

Forks are "free" to vote in favor of...
vote on them all!

(If you are not eventually slashed!)

What might it cost to successfully attack?

Notes:

  • Unlike PoW where voting on a chain costs something extrinsic to the system, PoS has only intrinsic measures to do accounting of consensus rules.
  • Critical: This was a problem with early naive implementations of PoS. Modern PoS schemes avoid this specific problem by having the security deposit and slashing for equivocation (in a few slides)
  • Good explainer, source of image: https://golden.com/wiki/Nothing-at-stake_problem-639PVZA

---v

Proof of...
Relatively Nothing at Stake

Risk-to-reward ratio of attacks is
relative to the valuation of the staked assets.

Rational actors take into account
extrinsic motivators in calculating the highest reward.

What might it cost to successfully attack?

Notes:

  • Again PoS ha only intrinsic measures to do accounting of consensus rules, but the system doesn't exist in a vacuum: the relative valuation of what is at stake needs to be accounted for.

---v

Validator Consolidation

How many validators does a system need?

Higher numbers should lead to a decrease in the ability for entities to collude.

But validators are expensive, both economically and computationally.

Notes:

Yet another N-lemma to consider.

---v

PoS Economic Security

Proposition: The upper bound of economic security in PoS is relative valuation can secure, that is correlated with the market capitalization of the network.

Market capitalization refers to the total market value of all assets inherent to a single company/chain/token.

Notes:

  • This market capitalization could be company shares, or total ETH in existence, or total X token associated with a specific smart contract or parachain.

---v

โš” PoS Economic Security Battles

Notes:

Here like in PoW we have relative safety in networks, but there is no way to "hop" from one chain to another, so the war is still in the relative security, but one stake cannot directly attach another stake in a separate consensus system...

What about an system of value within consensus?

---v

DApp PoS Economic Security

Notes:

Consideration: these notes are an oversimplification! We may talk more about this kind of problem in NPoS lesson (Nuke thinks at least). The details of a formal analysis are out of scope for this Academy.

Proposition: Total applications valuation of their assets (tokens on smart contracts, or parachains) is limited and that limit is correlated with the total economic security of the consensus system they reside in.

In Polkadot's relay chain model, Nuke would argue it's feasible that an attack to extract value from a very highly valued asset could outweighs the cost of obtaining a byzantine level of stake to execute. Therefore the sum of all parachains market cap is also limited as that same level of stake control would enable take over of all chains on it.

Nuke argue this is the same for the sum of all contracts valuations on something like Ethereum.

---v

Authority Misbehavior

  • Equivocation
    • Authorship: Proposing mutually
      exclusive chains
    • Finality: Voting for mutually
      exclusive chains to be final
  • Invalidity
  • Lack of availability
  • Intentional protocol abuse (selfish mining)

Notes:

We already talked consensus faults, but abuse is newer. Nuke argues "abuse" as a term here isn't the intended mechanism design, and is adverse to the health of the system. Selfish mining where it's impossible to prove an author is withholding valid blocks to "cheat" by mining ahead of the rest of th network is a good example in the class of attacks that consensus authorities and others may have.

...Could other actors abuse the protocols?

---v

Accountability of Authority

Authority should imply accountability.

No matter how you design an authority selection mechanism, some people will have a privileged position within it.

Those who choose to become authorities should be liable for their actions.

---v

Provability and Equivocation

Some types of misbehavior are harder to prove than others.

Equivocation is simple:
Someone can just produce two signed messages as cryptographic proof.

Others rely on challenge-response games and dispute resolution.

Notes:

Nothing at stake solution, with the possible caveat of long range attacks Weak subjectivity can still potentially cause the same behavior in a much harder to orchestra way, with bad actors having already have their stake released to produce a valid, finalized fork.

---v

Design Considerations
in Polkadot

  • More validators increases the state transition throughput of the network: parachains.
  • Individual shards have full economic freedom by being members of a larger consensus system.
  • Superlinear slashing puts colluding validators at existential risk,
    while well-meaning ones should have little to worry about).

Notes:

A few interesting design decisions in Polkadot's architecture.

We will cover polkadot much more in depth latter!

---v

Transaction Censorship and Ordering

Block authors choose the transactions they include and in what order.

  • Censorship attacks
  • "Maximal extractable value" (MEV)

---v

Web3 Goal: Non-Censorship

There are a lot more system users than system authorities.

However, every transaction must be included by an authority.

If no authority will include a user's transaction, they do not have permissionless access.

If any authority (author) decides not to censor, it may be included.

Notes:

Most present systems have no mechanism to penalize censorship, and a much harder problem can be the ability to discover this is happening on the network at all, depending on the actors involved.

---v

Maximal Extractable Value (MEV)

A measure of the value that block authors can extract based on their knowledge of pending transactions and ability to order them.

  • Frontrunning
  • Backrunning
  • Sandwiching

https://www.mev.wiki/

Notes:

Emergent behavior. Not realized as possible by many until it quietly became the norm.

---v

Maximal Extractable Value

An environment in which detection means certain death...
...identifying someoneโ€™s location is as good as directly destroying them.

-- Ethereum is a Dark Forest --

Notes:

Tell the story of this article, basically a white hat engineered obfuscation to try and remove funds in a bugged contract -> someone decoded, realized extractable valued, and front-ran them.

This is now the norm on Ethereum at least, and further it's becoming institutionalized.

---v

๐Ÿ‘ผ Flashbots

Flashbots is a research and development organization formed to mitigate the negative externalities posed by Maximal Extractable Value (MEV) to stateful blockchains, starting with Ethereum.

-- Flashbots --

Notes:

This might be misleading, in that they are profiting in making MeV more effective and institutionalized!

---v

Flashbots ๐Ÿ˜ˆ

  • Flashbots Auction: a marketplace for transaction ordering including the Flashbots Relay and MEV-Geth.
  • MEV-Boost: an out-of-protocol implementation of proposer-builder separation (PBS) for proof-of-stake Ethereum.
  • Flashbots Protect: an rpc endpoint that anyone can use for protection from frontrunning and failed transactions.
  • Flashbots Data: tools and dashboards to improve the transparency of MEV activity on Ethereum and the Flashbots Auction.

Notes:

Centralizing force, as information asymmetry generally drives towards a monopoly on MeV. Competitive landscape for this exists, and to Flashbots' credit, they seem genuine in trying to help the health of Ethereum by decentralizing...

(BUT FIRST a discussion!) Especially in light of recent OFAC pressures revealing fragility in the system...

---v

Discussion

Front-running as a Service (FaaS) & MEV Auctions (MEVA)

A solution or crutch?

Notes:

  • Flashbots & Friends

---v

Compliance

Notes:

https://cryptoslate.com/op-ed-is-ethereum-now-under-u-s-control-99-of-latest-relay-blocks-are-censoring-the-network/

  • code is unstoppable, but platform can sensor. Ability -> responsibility (we may talk more on that latter)

---v

Social Context

Social systems and norms can help cover up weaknesses in protocols.

Public monitor to shame OFAC censors:

https://www.mevwatch.info/

Notes:

  • Pressure from peers through breaking norms, perhaps even losing of authority in consensus due to this. Peer reputation in computer networks, and here also in human ones.
  • Sometimes social pressures are healthy for the system, sometimes toxic depending on point of view and who benefits!
  • In monero "run your own node" culture helps keep it decentralized.
    Bitcoin big block wars show social pressures help decide the canonical forks.
  • Normalizing MEV for the profit of middlemen, providing extraction services in the worst case.

---v

Unbundling

Notes:

From before, but here point out how this is getting more fine grained as well, and where a single actor would do it all (early bitcoin for example) we are moving more and more to appear.

  • Especially if more things like MeV can be enhanced by doing so.
  • This introduces more complexity and interfaces that can provide weakness (especially when a network is required!)

---v

Unbundling

The vision of "blockspace" leads
more and more to this end

---v

Diversity

Notes:


Final Thoughts

  • Complexity generally increases the risks of failures, but we should not fear it.
    $~~~$Hypothesis: this _usually makes systems more brittle._
  • Observable behavior trumps models and theory.
    $~~~$Complex systems are not intuitive and may show your assumptions and models are wrong!
  • This lesson was a start down holes... $~~~$We encourage you to keep diving deeper!

Notes:

  • Risks and unknown unknowns increase exponentially so in many cases.
  • Examples of observables in things like MEV OFAC dominance and Babe fallback dominance etc.
  • Looking forward to explore the great unknown horizons in web3 together!

๐Ÿค Together, into the Deep


Questions


Additional Slides

Notes:

For reference mostly, outside of formal class time ๐Ÿ˜€


Governance... Unstoppable?

Unstoppable Code: The Difference Between Can't and Won't

Notes:

Watch after class! Perhaps assigned informally to everyone to watch in the next few days.

---v

Unstoppable Code

It seizes power from dominate forms of power: governments, corporations, states, associations, cultures, religions. It seizes power, from these big things and gives it to little people. And sooner or later, the people who are losing their undeserved, abusively applied power will start to fight back. And at that point, we will start to find out how unstoppable our code is.

-- Andreas Antonopoulos --

---v

Can't vs. Won't

The moment you go over the the line from "can't to won't, what started as an ability becomes a responsibility. And then if you claim that you don't have the ability anymore, that responsibility just became negligence, criminal negligence.

-- Andreas Antonopoulos --

Notes:

  • The difference?
  • Silk road founder getting 2 life sentences + 40 years.
  • moral relativism -> "who's law?"
  • Don't make your "oops clause" -> not too narrow.

DAOs

Decentralized Autonomous Organizations (DAOs).

A coordination mechanism.

---v

Democratic Systems

Democratic Mediums is a directory of patterns
for decision, deliberation, and noise.

Notes:

Very much encouraged to explore after class! Many novel and niece definitions in this wiki.


Modeling Behavior

Token Engineering
{especially the Academy & cadCAD Edu}

Notes:

Mostly free education and tools to dive deeper on tokenomics. Remember, these are models of idealized systems in general, real world conditions will differ!