Git-Mirrors/decentralized-protocols-toolkit
1
0
Fork 0
mirror of https://github.com/autistic-symposium/decentralized-protocols-toolkit.git synced 2025-11-30 18:46:46 -05: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

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)**