diff --git a/README.md b/README.md
index 94be0aa..da082ab 100644
--- a/README.md
+++ b/README.md
@@ -1,51 +1,11 @@
-# notes and resources on protocol economy
+## ⛓🧱 decentralized protocols toolkit
-## 🛵 design
-
-### proposer-builder separation
-
-* [notes on pbs, by barnabe.eth](https://barnabe.substack.com/p/pbs)
- - thoughts on in-protocol pbs, market structure and allocation mechanism, whole vs. partial block building, block vs. slot auctions, inclusion lists, capturing true pbs value via consensus bid and protocol capture.
-
-* [decentralizing the builder role, by j. charbonneau](https://joncharbonneau.substack.com/p/decentralizing-the-builder-role)
-
-
-
-
-### eip-1559
-
-* [transaction fee mechanism design for ethereum, by tim roughgarden](https://timroughgarden.org/papers/eip1559.pdf)
- - thoughts on how eip-1559 proposes a major change to ethereum's transaction fee mechanism, the market for ethereum transactions, incentive-compatible transaction fee mechanisms, and alternative designs.
-
-* [congestion control and eip1559, by barnabe.eth](https://barnabe.substack.com/p/congestion-control-and-eip1559)
-
-
-
-### mev-smoothing
-
-* [burning mev through block proposer auctions, by domothy](https://ethresear.ch/t/burning-mev-through-block-proposer-auctions/14029)
-
-
-
-
-### algorithmic game theory
-
-* [algorithmic game theory, by tim roughgarden](https://theory.stanford.edu/~tim/papers/cacm.pdf)
-
-
-
-
-### inclusion lists
-
-* [inclusion list economics](https://efdn.notion.site/Inclusion-list-economics-b0d61d0e21a74963a54448e48d9adc8a)
-
-
-
-
-## 👾 resources
-
-* [CADlabs's ethereum economic model](https://github.com/CADLabs/ethereum-economic-model)
+* ⬛️ **[blockchains 101](blockchains)**
+* ⬛️ **[ethereum](blockchains/ethereum)**
+* ⬛️ **[consensus](consensus)**
+* ⬛️ **[cryptoeconomics](cryptoeconomics)**
+* ⬛️ **[data availability](data_availability)**
diff --git a/blockchains/README.md b/blockchains/README.md
new file mode 100644
index 0000000..e9e9647
--- /dev/null
+++ b/blockchains/README.md
@@ -0,0 +1,43 @@
+## blockchains 101
+
+
+
+### tl; dr
+
+* **in general, blockchains have four core functions** (although modular blockchains specialize in one or two):
+ * execution: transaction execution and state update.
+ * settlement: finality and dispute resolution.
+ * consensus: agreement on transaction ordering.
+ * data availability: prove data was published to the network.
+
+* **in general, each block in a blockchain consists of two pieces**:
+ * a block header: metadata for the block, which consists of some basic information about the block, including the merkle root of txs.
+ * the transaction data: making up the majority of the block, and consisting of actual transactions.
+
+* **in general, a blockchain has two types of nodes**:
+ * full nodes (fully validating nodes): they download and check that every tx in the blockchain is valid, and require lots of resources.
+ * light clients: they don't download or validate any tx, but instead thye only download the block header and assume that the block only contains valid txs (less secure). light clients can rely on full nodes sending them a fraud proof if a block contains a invalid tx.
+
+* **the data availability problem:**
+ * in order to a full node to generate a fraud proof for a block, they need to know the tx data for that block. if a block producer just publishes the block header, but not the tx data, then full nodes won't be able to check if the txs are valid and generate fraud proofs.
+ * it's a requirement that block producers must publish all the data for the blocks, but this needs to be enforced.
+ * to solve this problem, there need to be a way for light clients to check that the tx data for a block was actually published to the network so full nodes can check it.
+
+
+
+----
+
+### cool resources
+
+
+
+* **[celestia's namespaced merkle tree](https://github.com/celestiaorg/nmt)**
+* **[jellyfish merkle tree, by z. gao et al.](https://developers.diem.com/papers/jellyfish-merkle-tree/2021-01-14.pdf?ref=127.0.0.1)**
+* **[leaves of hash, by trail of bits](https://blog.trailofbits.com/2019/06/17/leaves-of-hash/)**
+* **[how merkle trees work, by consensys](https://media.consensys.net/ever-wonder-how-merkle-trees-work-c2f8b7100ed3)**
+* **[bitcoin memory pool](https://www.blockchain.com/explorer/mempool/btc)**
+* **[on a rusty sparse merkle tree experiment, by bt3gl](https://mirror.xyz/go-outside.eth/zX1BaGZLHAcQOKdhFnSSM0VW67_-OFCi5ZegGFPryvg)**
+* **[on uploading your soul to the interplanetary sys, by bt3gl](https://mirror.xyz/go-outside.eth/A3iJGhXTJI5fgQoZVgIu3ovPV1P8zrxigpwngm0n4I0)**
+* **[understanding trie databases, by d. brickwood](https://medium.com/shyft-network/understanding-trie-databases-in-ethereum-9f03d2c3325d)**
+
+
diff --git a/blockchains/ethereum/README.md b/blockchains/ethereum/README.md
new file mode 100644
index 0000000..2bd2ba9
--- /dev/null
+++ b/blockchains/ethereum/README.md
@@ -0,0 +1,124 @@
+## the ethereum blockchain
+
+
+
+* **[the ethereum yellow paper](https://ethereum.github.io/yellowpaper/paper.pdf)**
+* the ethereum roadmap:
+
+
+
+
+
+
+
+
+
+---
+
+### tl; drs
+
+
+
+##### evm execution
+
+* in native execution, evm will load the bytecode and execute the opcodes in the bytecodes one by one from the beginning.
+* each opcode can be thought as doing the following steps:
+ 1. read elements from stack, memory, or storage
+ 2. perform some computation on these elements
+ 3. write back results to stack, memory, or storage
+
+
+
+##### light clients
+
+* light clients receive the block headers, which contain a merkle root (more on this later) that can be used to query full nodes to verify if a transaction is included in a particular block.
+
+
+
+##### scalability
+
+* **[eip-4844 tl; dr](eip-4844.md)**
+* **[possible futures of the ethereum protocol, part 1: the merge, by vub](https://vitalik.eth.limo/general/2024/10/14/futures1.html)**
+* **[possible futures for the ethereum protocol, part 2: the surge, by vub](https://vitalik.eth.limo/general/2024/10/17/futures2.html)**
+
+
+
+##### rollups
+
+* rollups move computation (and state storage) off-chain, but keep some data per tx on-chain, using compression tricks to replace data with computation wherever possible (but scalability is still limited by the data bandwidth of the underlying blockchain).
+* an onchain smart contract maintains a state root (the merkle root) of the state of the rollup.
+* anyone can publish a batch (collection of txs, compressed to form the previous state root and the new state root).
+* the contract checks that the previous state root in the batch matches the current state root - if not, it switches the state root to the new state root.
+* for depositing and withdrawing, txs can have input or output outside the rollup state (processed within the batches).
+* optimistic (fraud proof) or zk (validity proof) rollups are solutions to know that the post-state roots in the batches are correct.
+
+
+
+
+
+
+
+
+
+
+
+* optimistic l2s
+ * arbitrum one
+ - started rollups
+ - largest TVL
+ * optimism
+ - rollup from optimism collective, with a rich ecosystem of l2
+ - tool to create l2 part of the superchain
+ * mantle
+ - l2 from bitdao
+
+* zk-rollups l2s
+ - zksync era
+ - the leading zk-rollup and a zkevm (zk-rollups that use ethereum virtual machine to execute transactions are called zkevms)
+ - the only zkevm that supports native account abstraction in the consensus layer of the chain
+* starknet
+ - zk-rollups from starkware
+ - not a zkevm
+ - used the cairo language
+ - has recently open-souced their STARK prover
+* polygon zkevm
+ - part of polygon 2.0, an ecosystem of zk-rollups
+ - converting polygon pos into a zk-validum
+ - has their prover open-sourced
+* linea
+ - another recent zkevm from consensys
+
+
+
+##### proposer-builder separation
+
+* **[notes on pbs, by barnabe.eth](https://barnabe.substack.com/p/pbs)** (thoughts on in-protocol pbs, market structure and allocation mechanism, whole vs. partial block building, block vs. slot auctions, inclusion lists, capturing true pbs value via consensus bid and protocol capture)
+* **[decentralizing the builder role, by j. charbonneau](https://joncharbonneau.substack.com/p/decentralizing-the-builder-role)**
+
+
+
+##### inclusion lists
+
+* **[inclusion list economics](https://efdn.notion.site/Inclusion-list-economics-b0d61d0e21a74963a54448e48d9adc8a)**
+* **[eip-7547 inclusion list, by m. neuder](https://ethereum-magicians.org/t/eip-7547-inclusion-lists/17474)**
+
+
+
+
+---
+
+### cool resources
+
+
+
+* **[what are rollups, by ef](https://ethereum.org/en/developers/docs/scaling/zk-rollups/)**
+* **[upgrading ethereum book, by b. edgington](https://eth2book.info/bellatrix/)**
+* **[an incomplete guide to rollups, by vub](https://vitalik.ca/general/2021/01/05/rollup.html)**
+* **[validity rollups on bitcoin, by j. light](https://bitcoinrollups.org/)**
+* **[covenants, by bitcoin optech](https://bitcoinops.org/en/topics/covenants/)**
+* **[a rollup-centric ethereum roadmap](https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698)**
+* **[resources for mev on ethereum](https://github.com/autistic-symposium/mev-toolkit/tree/main/MEV_by_chains/MEV_on_Ethereum)**
+* **[ef's ethereum protocol wiki](https://epf.wiki/#/)**
+* **[ethereum transaction visualizer](https://github.com/naddison36/tx2uml)**
+
+
diff --git a/blockchains/ethereum/eip-4844.md b/blockchains/ethereum/eip-4844.md
new file mode 100644
index 0000000..8391953
--- /dev/null
+++ b/blockchains/ethereum/eip-4844.md
@@ -0,0 +1,41 @@
+## eip-4844
+
+
+
+### tl; dr
+
+- first interation of sharding design of ethereum: a way to have more data through the network.
+- eip-4844 creates a cheap palce for l2 solutions to post data on ethereum and reduce overall tx fees users pay on l2.
+- a new tx format for "blob-carrying txs" (large amount of data that cannot be accessed by evm execution, but which commitment can).
+- zk rollups would need to provide 2 commitments: the kzg in the blob and some commitment using zkp syste. they would prove that the kzg and the zk rollup commitment refer to the same data.
+
+
+
+
+
+
+
+
+
+* **[eip-4844: shard blob transactions](https://www.eip4844.com/)** introduces a new kind of tx type, that accepts "blobs" of data to be persisted in the beacon node for a short period of time. blobs are significantly larger than transaction (~125kb).
+* blobs are small enough to keep disk use manageable. they are ephemeral data storage and cheaper than on-chain storage (calldata).
+* this eip is designed for rollups to further reduce the cost of data submission and verification. rollups can use this storage to post tx data or proof back to the mainnet.
+* proto-danksharding requires a new cryptographic scheme: kzg commitments, also called a **["trusted setup"](https://github.com/go-outside-labs/blockchains-protocol-design/tree/main/zero_knowledge_proofs/proofs#common-reference-strings-trusted-setup-multi-party-computation-ceremony)**. it generates a structured reference string (SRS) which is needed for the commitments to work.
+* because nodes will have to download full blob contents with proto-danksharding, the ethereum block capacity is targeted to 1-2MB of space rather than 16MB with full danksharding (where data availability sampling will be possible).
+
+
+
+
+
+
+
+
+
+----
+
+### cool resources
+
+
+
+* **[vitalik's proto-danksharding faq](https://notes.ethereum.org/@vbuterin/proto_danksharding_faq#Proto-Danksharding-FAQ)**
+* **[code for testing EIP-4844 on EL and CL clients](https://github.com/Inphi/eip4844-interop)**
diff --git a/consensus/README.md b/consensus/README.md
new file mode 100644
index 0000000..83bb0c4
--- /dev/null
+++ b/consensus/README.md
@@ -0,0 +1,11 @@
+## consensus
+
+
+
+### chapters
+
+
+
+* **[tendermint](tendermint)**
+* **[leader election](leader_election)**
+* **[decentralized sequencers](decentralized_sequencers)**
diff --git a/consensus/decentralized_sequencers/README.md b/consensus/decentralized_sequencers/README.md
new file mode 100644
index 0000000..0361308
--- /dev/null
+++ b/consensus/decentralized_sequencers/README.md
@@ -0,0 +1,25 @@
+## decentralized sequencers
+
+
+
+#### bt3gl's diagram for **[espresso systems](https://docs.espressosys.com/sequencer/espresso-sequencer-architecture/readme)**:
+
+
+
+
+
+
+
+
+
+---
+
+### cool resources
+
+
+
+* **[shared sequencers, by bridge harris](https://bridgeharris.substack.com/p/a-primer-on-shared-sequencers)**
+* **[shared sequencers, by maven11](https://maven11.substack.com/p/the-shared-sequencer)**
+* **[shared sequencers, dba](https://dba.mirror.xyz/NTg5FSq1o_YiL_KJrKBOsOkyeiNUPobvZUrLBGceagg)**
+* **[shared sequencers, by celestia](https://forum.celestia.org/t/sharing-a-sequencer-set-by-separating-execution-from-aggregation/702)**
+* **[shared sequencing, by expresso](https://hackmd.io/@EspressoSystems/SharedSequencing)**
diff --git a/consensus/leader_election/README.md b/consensus/leader_election/README.md
new file mode 100644
index 0000000..74222d6
--- /dev/null
+++ b/consensus/leader_election/README.md
@@ -0,0 +1,35 @@
+## leader election
+
+
+
+### secret leader election
+
+
+
+* **[leader election overview](le_overview.pdf)**
+* **[wtf is a secret leader election, by 2077](https://etherpedia.2077.xyz/posts/wtf-is-secret-leader-election/)**
+* **[secret leader election, by ef](https://ethereum.org/en/roadmap/secret-leader-election/)**
+
+
+
+---
+
+### single secret leader election
+
+
+
+* **[single secret leader election, by d. boneh et al.](https://eprint.iacr.org/2020/025.pdf)**
+* **[post-quantum single secret leader election, by d. boneh](https://www.youtube.com/watch?v=8caTi0JNGYA)**
+* **[private attacks in longest chain proof-of-stake protocols with ssle, by a. azouv](https://arxiv.org/pdf/2109.07440)** (hiding the identity of the leader)
+* **[a framework for constructing ssle from mpc, backes et al.](https://eprint.iacr.org/2022/1040.pdf)** (computational cost for N parties as low as O(N), garbled circuits, concerns over linear blow-up)
+* **[whisk, a practical shuffle-based SSLE protocol](https://ethresear.ch/t/whisk-a-practical-shuffle-based-ssle-protocol-for-ethereum/11763)** (ef's choice)
+
+
+
+---
+
+### leaderless consensus protocols
+
+
+
+* **[red belly: a secure, fair and scalable open blockchain, crain et al.](https://cognizium.io/uploads/resources/Red%20Belly-A%20secure,%20fair%20and%20scalable%20open%20blockchain%20-%20Tyler%20Crain,%20Christopher%20Natoli,%20Vincent%20Gramoli%20-%202021%20-%20paper.pdf)**
diff --git a/consensus/leader_election/le_overview.pdf b/consensus/leader_election/le_overview.pdf
new file mode 100644
index 0000000..dcd075a
Binary files /dev/null and b/consensus/leader_election/le_overview.pdf differ
diff --git a/consensus/tendermint/README.md b/consensus/tendermint/README.md
new file mode 100644
index 0000000..10c2e12
--- /dev/null
+++ b/consensus/tendermint/README.md
@@ -0,0 +1,31 @@
+## tendermint
+
+
+
+### tl; dr
+
+
+
+* consensus protocol for ordering events in a distributed network under adversarial conditions (aka byzantine fault tolerant consenus, or atomic broadcast).
+* tendermint consists of two technical components: a blockchain consensus engine and a generic application interface, and works even if up to 1/3 of machines fail in arbitrary ways.
+* tendermint core (the consensus engine) performs BFT state machine replication (SMR) for arbitrary deterministic, finite state machines.
+* the application interface (abci) enables the transactions to be processed in any programming language.
+
+
+
+
+
+
+
+
+
+---
+
+### cool resources
+
+
+
+* **[tendermint docs](https://docs.tendermint.com/)**
+* **[tenderming abci](https://github.com/tendermint/tendermint/tree/v0.34.x/abci)**
+* **[the latest gossip on BFT consensus, e. buchman et al.](https://arxiv.org/abs/1807.04938)**
+* **[cometbft (a distributed byzantine fault-tolerant derterministic state machine replication engine)](https://github.com/cometbft/cometbft)**
diff --git a/cryptoeconomics/README.md b/cryptoeconomics/README.md
new file mode 100644
index 0000000..138d89f
--- /dev/null
+++ b/cryptoeconomics/README.md
@@ -0,0 +1,23 @@
+## cryptoeconomics
+
+
+
+
+### game theory
+
+* **[columbia cryptoeconomics workshop 2022](https://www.youtube.com/playlist?list=PLpktWkixc1gUqkyc1-iE6TT0RWQTBJELe)**
+* **[standford class on game theory](https://www.coursera.org/learn/game-theory-1#syllabus) and [advanced course](https://www.coursera.org/learn/game-theory-2)**
+* **[finding pure strategy nash equilibrium in finite simultaneous games](https://www.youtube.com/watch?v=gINERi_wbbg)**
+* **[censorship resistance in on-chain auctions, pai et al.](https://github.com/eljhfx/Decentralized-Auctions/blob/main/Censorship_Resistance_in_On-Chain_Auctions.pdf)**
+ - single proposer blockchains are not ideal for holding time sensitive auctions when the number of potential bidders is large. collusion arrangements are extremely profitable for the colluding bidder but only marginally profitable for the proposer. order agnostics mechanism should solve mev.
+* **[algorithmic game theory, by t. roughgarden](https://theory.stanford.edu/~tim/papers/cacm.pdf)**
+* **[algorithmic game theory (the book), by nisan et al.](https://www.cs.cmu.edu/~sandholm/cs15-892F13/algorithmic-game-theory.pdf)**
+
+
+
+
+### protocol economics and auctions
+* **[CADlabs's ethereum economic model](https://github.com/CADLabs/ethereum-economic-model)**
+* **[protocol economics: the ethereum protocol’s perspective, by vub](https://hackmd.io/@vbuterin/mev_presentation_3#/)**
+* **[a16z menagerie of auction mechanisms implemented in solidity](https://github.com/a16z/auction-zoo)**
+* **[on some results and challenges in cryptoeconomics, by t. roughgarden](https://www.youtube.com/watch?v=hMbXH3SdWd4)**
diff --git a/data_availability/README.md b/data_availability/README.md
new file mode 100644
index 0000000..464047a
--- /dev/null
+++ b/data_availability/README.md
@@ -0,0 +1,29 @@
+## data availability
+
+
+
+### tl; dr
+
+* data availability is the proof that the underlying data behind a particular hash was actually published and can
+* in the case of ethereum, da is one of the primary scaling bottlenecks. protocol-level changes such as sharding and eip-4488 (proto-sharding) are intended to increase da and reduce the cost of storing data on ethereum (the current leading design is **danksharding**, which should happen in several steps).
+
+
+
+---
+
+### chapters
+
+
+
+* **[celestia](celestia.md)**
+
+
+
+---
+
+### cool resources
+
+
+
+* **[private data attestation using merkle trees, by ethereum attestation service](https://mirror.xyz/0xeee68aECeB4A9e9f328a46c39F50d83fA0239cDF/BiFUEFJKo6ZsIvPwsP9WPC2UZX0-x_9BdtrvmQo1FwY)**
+* **[bitcoin as a data availability layer, by rolkit](https://github.com/rollkit/bitcoin-da)**
diff --git a/data_availability/celestia.md b/data_availability/celestia.md
new file mode 100644
index 0000000..2b3d7eb
--- /dev/null
+++ b/data_availability/celestia.md
@@ -0,0 +1,186 @@
+## celestia's das network
+
+
+
+### tl; dr
+
+
+
+* celestia is a modular data availability network that scales with the number of users, by decoupling execution from consensus and introducing a new primitive, **data availability sampling** (das), through **namespaced merkle trees**.
+* celestia da layer consists of a pos blockchain (celestia app), an application that provides transactions to faciliate the da layer and is built using cosmos sdk.
+* rollups and l2s use celestia as a network for publishing and making transaction da available, where optimistic rollups require data availability to detect fraud and zero-knowledge rollups require data availability to reconstruct the state of the chain (celestia can scale to the data throughput needed for millions of rollups without compromising on security).
+
+
+
+
+
+
+* lexicon:
+ * **blobs**: data is posted to celestia's da layer by using `MsgPayForBlobs` transactions to the core network.
+ * **namespaces**: celestia partitions the block data into multiple namespaces, one for every application. this allows applications to only download their data, and not the data of other applications.
+ * **blockchain cluster:** a group of blockchains that can communicate with each other in a trust-minimized way.
+ * **consensus**: the ordering of txs is agreed upon by a set of validators.
+ * **data availability commitee (dac)**: permissioned group of nodes responsible for providing da to a blockchain.
+ * **data availability layer**: a blockchain that provides for other types of chains (e.g., rollups).
+ * **settlement layer**: a modular blockchain whose primary role is to provide proof verification and dispute resolution for rollups.
+ * **data throughput**: a measurement of the data capacity of a blockchain, and calculated by the amount of data that a block.
+ * **the data availability problem**: concerned with whether the data in the proposed block can be verified that is available.
+
+
+
+-----
+
+### data availability sampling (das)
+
+
+
+* da answers the question "has the data for this blockchain been published?".
+ - celestia solves the problem of having to download all the blockchain data by making it possible for users to verify very large blocks with data availability sampling.
+ - this new primitive enables celestia light nodes to, instead of downloading all data, download only **block headers that contain commitments** (i.e. merkle roots) of the block data (i.e. the list of transactions).
+ - to make das possible, celestia uses as **2D reed-solomon encoding scheme** to encode the block data: every block data is split into `k x k` chunks, arranged in a `k x k` matrix, and extended with parity data into a `2k x 2k` extended matrix by applying multiple times reed-solomon encoding.
+
+
+
+
+
+
+
+
+
+
+* celestia does not require a majority of the consensus (i.e. block producers) to be honest to guarantee data availability.
+ - if the extended data is invalid, the original data might not be recoverable, even if the light nodes are sampling sufficient unique chunks.
+ - as a solution, da fraud proofs of incorrectly generated extended data enable light nodes to reject blocks with invalid extended data (data availability proofs using erasure codes).
+ - such proofs require reconstructing the encoding and verifying the mismatch.
+
+
+
+
+
+
+
+
+
+----
+
+### namespaced merkle trees
+
+
+
+* celestia partitions the block data into **multiple namespaces**, one for every application (e.g. rollup), using the da layer.
+ - every application needs to download only its own data and can ignore the data of other applications.
+ - for this to work, the da layer must be able to prove that the provided data is complete, i.e., all the data for a given namespace is returned.
+* a nmt is a merkle tree with the leafs ordered by the namespace identifiers and the hash function modified so that every node in the tree includes the range of namespace of all its descendants.
+ - when an application requests the data for `namespace 2`, the da layer must provide the data chunks `D3`, `D4`, `D4`, `D6`, and the nodes `N2`, `N8`, `N7` as proof.
+ - the application is able to check that the provided data is part of the block data. furthermore, the application can verify that all the data for `namespace 2` was provided. if the DA layer provides only the data chunks `D4` and `D5`, it must also provide nodes `N12` and `N11` as proofs. however, the application can identify that the data is incomplete by checking the namespace range of the two nodes, i.e., both `N12` and `N11` have descendants part of `namespace 2`.
+
+
+
+
+
+
+
+
+
+----
+
+### building a pos blockchain for da
+
+
+
+* celestia-app is built on top of celestia-core, a modified version of the tendermint consensus algorithm. it ensures:
+ * the erasure coding of block data (using the 2D reed-solomon encoding scheme).
+ * the replacement of regular merkle tree used by tendermint to store block data wiht a namespaced merkle tree that enables the above layers (execution and settlement) to only download the needed data.
+* celestia-core nodes are still using the tendermint p2p network.
+* similarly to tendermint, celestia-core is connected to the application layer (i.e., the state machine) by ABCI++.
+ - like its predecessor, ABCI++ is the interface between tendermint (a state-machine replication engine) and the actual state machine being replicated (i.e., the application). yhe api consists of a set of methods, each with a corresponding request and response message type.
+ - all ABCI++ messages and methods are defined in protocol buffers.
+* the celestia-app state machine is necessary to execute the pod logic and to enable the governance of the fs layer. however, the celestia-app is data-agnostic - the state machine neither validates nor stores the data that is made available by the celestia-app.
+
+
+
+----
+
+### celestia light nodes
+
+
+
+* light nodes ensure da, and they are the most common way to interact with celestia.
+
+
+
+
+
+
+
+
+
+
+---
+
+### celestia full nodes
+
+
+
+* full nodes store all the data.
+* they send block shares, headers, and fraud proofs to light nodes (while light nodes gossif headers, fraud proofs, and sometimes block shares between one another).
+
+
+
+
+
+
+
+
+
+---
+
+### ethereum fallback
+
+
+
+* a mechanism that enables l2s to "fallback" to using ethereum calldata for da when celestia mainnet is under downtime. it's triggered whenever the sequencer has an error sending the `PayForBlobs` transacations to celestia.
+* fallback can also be triggered due a congested mempool or nonce error, and can be simulated with an error as low as balance or incorrect sequence.
+
+
+
+
+
+
+
+
+
+-----
+
+### blockspace
+
+
+
+* to publish data on celestia, developers can submit `PayForBlobs` transactions, which consist of the identity of the sender, the data to be made available, the data size, the namespace, and a signature.
+* each `PayForBlobs` transaction is split into two parts: the blob or blobs which include the data to be made available along with the namespace, and the executable payment transaction which includes a commitment to the data.
+* both the blobs and executable payment transactions are put into the block within the appropriate namespace, the block data is extended using erasure coding and then merkelized into a data root commitment included in the block header.
+
+
+
+
+
+
+
+
+
+* celestia uses a standard gas-price prioritised mempool, where transactions with higher fees will be prioritised by validators. fees are comprised of a flat fee per transaction and then a variable fee based on the size of each blob in the transaction.
+
+
+
+---
+
+### cool resources
+
+
+
+* **[celestia docs](https://docs.celestia.org/learn/how-celestia-works/data-availability-layer#namespaced-merkle-trees-nmts)**
+* **[cosmos sdk](https://docs.cosmos.network/)**
+* **[tendermint consensus algorithm docs](https://docs.tendermint.com/)**
+* **[building a sparse merkle tree from scratch in rust, by bt3gl](https://mirror.xyz/go-outside.eth/zX1BaGZLHAcQOKdhFnSSM0VW67_-OFCi5ZegGFPryvg)**
+* **[lazyledger: a distributed da ledger with client-side smart contracts, by m. al-bassam](https://arxiv.org/abs/1905.09274)**
+* **[fraud and da proofs: maximising light client security, by m. al-bassam et al.](https://arxiv.org/abs/1809.09044)**
diff --git a/docs/IPFS1.png b/docs/IPFS1.png
new file mode 100644
index 0000000..197edaf
Binary files /dev/null and b/docs/IPFS1.png differ
diff --git a/docs/IPFS10.png b/docs/IPFS10.png
new file mode 100644
index 0000000..d68f423
Binary files /dev/null and b/docs/IPFS10.png differ
diff --git a/docs/IPFS2.png b/docs/IPFS2.png
new file mode 100644
index 0000000..0ec448c
Binary files /dev/null and b/docs/IPFS2.png differ
diff --git a/docs/IPFS3.png b/docs/IPFS3.png
new file mode 100644
index 0000000..16df857
Binary files /dev/null and b/docs/IPFS3.png differ
diff --git a/docs/IPFS4.png b/docs/IPFS4.png
new file mode 100644
index 0000000..42ce8dd
Binary files /dev/null and b/docs/IPFS4.png differ
diff --git a/docs/IPFS5.png b/docs/IPFS5.png
new file mode 100644
index 0000000..ec6c737
Binary files /dev/null and b/docs/IPFS5.png differ
diff --git a/docs/IPFS6.png b/docs/IPFS6.png
new file mode 100644
index 0000000..42635a3
Binary files /dev/null and b/docs/IPFS6.png differ
diff --git a/docs/IPFS7.png b/docs/IPFS7.png
new file mode 100644
index 0000000..8d545d2
Binary files /dev/null and b/docs/IPFS7.png differ
diff --git a/docs/IPFS8.png b/docs/IPFS8.png
new file mode 100644
index 0000000..cebdf29
Binary files /dev/null and b/docs/IPFS8.png differ
diff --git a/docs/IPFS9.png b/docs/IPFS9.png
new file mode 100644
index 0000000..c50adbc
Binary files /dev/null and b/docs/IPFS9.png differ
diff --git a/docs/LIBP2P1.png b/docs/LIBP2P1.png
new file mode 100644
index 0000000..bb637be
Binary files /dev/null and b/docs/LIBP2P1.png differ