Git-Mirrors/decentralized-protocols-toolkit
1
0
Fork 0
mirror of https://github.com/autistic-symposium/decentralized-protocols-toolkit.git synced 2025-08-04 20:44:15 -04:00
Code Issues Projects Releases Packages Wiki Activity

reorganize chapters

Browse source
This commit is contained in:
bt3gl 2024-11-04 16:06:42 +07:00
parent 5a05bea513
commit bf1f5938c1
23 changed files with 554 additions and 46 deletions
Download patch file Download diff file Expand all files Collapse all files

43
blockchains/README.md Normal file
View file

@ -0,0 +1,43 @@
## blockchains 101
<br>
### 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.
<br>
----
### cool resources
<br>
* **[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)**

124
blockchains/ethereum/README.md Normal file
View file

@ -0,0 +1,124 @@
## the ethereum blockchain
<br>
* **[the ethereum yellow paper](https://ethereum.github.io/yellowpaper/paper.pdf)**
* the ethereum roadmap:
<br>
<p align="center">
<img width="600" src="https://user-images.githubusercontent.com/1130416/234419153-76ab9f89-00e8-48e7-93c4-c8d880ec2007.png">
</p>
<br>
<br>
---
### tl; drs
<br>
##### 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
<br>
##### 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.
<br>
##### 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)**
<br>
##### 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.
<br>
<p align="center">
<img width="250" src="https://user-images.githubusercontent.com/1130416/234379326-901ed83c-4bc5-4c97-bad8-3b9d96dfb1b7.png">
<img width="250" src="https://user-images.githubusercontent.com/1130416/234935489-f65f98a0-a6ac-4b86-b40d-e4aac97733b7.png">
<img width="250" src="https://user-images.githubusercontent.com/1130416/234379163-f55493b4-7ad5-4d0d-9021-0f722cbe34a6.png">
</p>
<br>
* 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
<br>
##### 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)**
<br>
##### 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)**
<br>
---
### cool resources
<br>
* **[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)**

41
blockchains/ethereum/eip-4844.md Normal file
View file

@ -0,0 +1,41 @@
## eip-4844
<br>
### 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.
<br>
<br>
<p align="center">
<img src="https://user-images.githubusercontent.com/1130416/235268925-57c622b1-7bf1-45dc-a685-b7a6fa03ad16.png" width="80%" align="center" style="padding:1px;border:1px solid black;"/>
</p>
<br>
<br>
* **[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).
<br>
<p align="center">
<img src="https://user-images.githubusercontent.com/1130416/235269011-ef88917b-10ce-4d5c-acb6-25a65eda23b0.png" width="80%" align="center" style="padding:1px;border:1px solid black;"/>
</p>
<br>
----
### cool resources
<br>
* **[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)**