Update eip-4844.md

scalability/eip-4844.md

@@ -4,25 +4,33 @@
 
 ### tl; dr
 
-<br>
-
-
-<img width="550"  src="https://user-images.githubusercontent.com/1130416/235268925-57c622b1-7bf1-45dc-a685-b7a6fa03ad16.png">
+- 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)
+* [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>
 <br>
 
-<img width="550" src="https://user-images.githubusercontent.com/1130416/235269011-ef88917b-10ce-4d5c-acb6-25a65eda23b0.png">
-
-
+<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>
 <br>
 
 ----
@@ -31,5 +39,5 @@
 
 <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)
+* **[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)**