# กว่าจะมาเป็น 4844 ต้องผ่านขั้นตอนอะไรบ้าง?

By [thesleeper (✨🔴_🔴✨)](https://paragraph.com/@thesleeper) · 2023-01-05

---

อยากรู้มั้ยกว่าจะปล่อยเทคใหม่ Dev ต้องผ่านอะไรบ้าง? เล่าผ่านเคส EIP-4844 ตัวตึงที่จะทำให้ Rollups ถูกลง 10-100x โดบสรุปจากสิ่งที่เกิดขึ้นในงาน [@EFDevcon](https://twitter.com/EFDevcon) แบบสั้น กระชับ จับใจความง่าย ไม่เปลืองแบนด์วิธ แปลจากเธรดของ [@jessepollak](https://twitter.com/jessepollak) (หนึ่งในทีมจาก Coinbase) พร้อมแล้วไปลุยกันเลย

ปูพื้น : EIP4844 คือสิ่งที่จะช่วยลดค่าทำธุรกรรมและเพิ่มความเร็ว (TPS) ของ L2 Rollups ได้ 10-100X โดยสร้าง data availability แบบใหม่บน ETH เรียกว่า "Blobspace" อ่านเพิ่มได้ที่

[

EIP-4844: Shard Blob Transactions
---------------------------------

EIP-4844 introduces a new kind of transaction type to Ethereum which accepts 'blobs' of data to be persisted in the beacon node for a short period of time.

https://www.eip4844.com

![](https://storage.googleapis.com/papyrus_images/d91b8e5165626d232edcbf24c82868f731853a1baec363e11bcd4538bbb60018.png)

](https://www.eip4844.com/)

สิ่งนี้นี้จะช่วยเร่ง Adoptionให้ ETH แบบเบิ้มๆ แต่จะเบิ้มแค่ไหนก็ขอยกคำพูดจาก [@coinbase](https://twitter.com/coinbase) มาเลยดีกว่า

> **"เราเชื่อว่า EIP4844 จะเป็นกุญแจสำคัญในการดึงผู้ใช้ (ลูกค้า) ใหม่ๆ ให้เข้าสู่โลกคริปโตได้อย่างปลอดภัย ใช้งานง่าย รวดเร็วกว่าเดิมได้ แถมยังถูกลงด้วย"**

[https://www.coinbase.com/blog/supporting-eip-4844-reducing-fees-for-ethereum-layer-2-rollups](https://www.coinbase.com/blog/supporting-eip-4844-reducing-fees-for-ethereum-layer-2-rollups)

เป้าหมายหลักที่ Devcon คือการดึงเอาหัวกระทิจากทีม Client ต่างๆ มาคิดหาวิธีที่ดีที่สุดในการปล่อย EIP4844 โดยทีม [@Ethereum](https://twitter.com/ethereum) [@OPLabsPBC](https://twitter.com/OPLabsPBC) และ [@Coinbase](https://twitter.com/coinbase) ใช้เวลาเขียนสเปคร่วมกันนาน 5 เดือน โดย Implement ลงบน Geth & Prysm ลอนช์ใน 2 Devnet และเตรียม KZG ceremony

โดยในงานทีมได้มีการประชุมกันแทบทุกวัน ถกกันเรื่องเซ็ตติ้งแบบต่างๆ จัดเวิร์กช้อปอีกหลายครั้ง ระหว่างทีม Client และมีการแลกเปลี่ยนกับ [@EthMagicians](https://twitter.com/EthMagicians) จนได้ข้อสรุปในการปรับอะไรเล็กๆ น้อยๆ เช่นสเปกของ Execution & Consensus Layer เพื่อลดข้อกังวลเรื่อง Network impact จาก Blobs

ใน Consensus Layer ทีมตัดสินใจรวม Blobs และ Block ไว้ด้วยกันก่อน (แทนการปล่อยให้แยกกัน) เพื่อลดความซับซ้อนในการ Implement Note : แต่เมื่อ Danksharding ตัวเต็มมาถึง ทีมค่อยปรับให้มันแยกกันทีหลัง

[

EIP4844: couple beacon block and blob sidecar for p2p by terencechain · Pull Request #3046 · ethereum/consensus-specs
---------------------------------------------------------------------------------------------------------------------

Part of #3043 Here we couple beacon block and blob sidecar under a single gossip topic- beacon\_block\_and\_blob\_sidecar. We introduce a new network container SignedBeaconBlockAndBlobsSidecar which co...

https://github.com

![](https://storage.googleapis.com/papyrus_images/fa5e23d99da8c40e7a0ab6f0e185d62b5cbd5f42fce03f05de70e7cad4a9c3e4.png)

](https://github.com/ethereum/consensus-specs/pull/3046)

ใน Execution Layer เพื่อลดโอกาสในการทำ DOS Vector ทีมตัดสินใจอัพเดต Wire Protocol เพื่อจำกัดให้ Announced เฉพาะธุรกรรมที่มี Blobs แทนการใช้ Broadcast วิธีนี้จะช่วยจัดการความปลอดภัยในการค้น Blobs ให้ Client ได้ดีขึ้น

[

Add EIP-5793: eth/68: Add transaction type to tx announcement by MariusVanDerWijden · Pull Request #5793 · ethereum/EIPs
------------------------------------------------------------------------------------------------------------------------

EIP-5793 adds the transaction type and size to the transaction announcement

https://github.com

![](https://storage.googleapis.com/papyrus_images/e21922a9687b07eb532f5645d053cc2b454c9da67b8e135e0e77d37133f4dcca.png)

](https://github.com/ethereum/EIPs/pull/5793/files)

สิ่งที่ทีมกังวลที่สุด (จากฟีดแบ็กของทีม Client) คือเรื่องความล่าช้าของระบบจากแบนวิธบนเครือข่ายที่เพิ่มขึ้นเมื่อใช้ Blobs ซึ่งทีมก็พอจะเดาได้ แต่ก็อยากลดความเสี่ยงให้เหลือน้อยที่สุด

เพื่อแก้ปัญหานี้ทีมได้ทำการจำลองสิ่งที่น่าจะเกิดขึ้นเมื่อเครือข่ายมีการใช้ Blob โดยการสร้างบล็อกจำนวนนึง ที่แต่ละอันจะยัด CALLDATA ใส่เข้าไป โดยลองทั้ง Testnet และ Mainnet แล้วดูว่า Node ต่างๆ จะตอบสนองยังไง

ผลจากการทดลองได้ข้อสรุปว่า ทีมต้องทำการปรับแต่งขนาดของขนาดของ Blobs ให้เหมาะกับแบนวิธที่จำกัดเพื่อลดปัญหา ทีมยังตื่นเต้นจากการได้เดต้าจริงๆ ของ final 4844 parameters

ตอนท้ายทีมได้มีการคุยกันเรื่องจะใช้ Library ไหน สำหรับ KZG commitments ระหว่าง EL และ CL โดยสรุปให้ใช้ c-kzg library เป็น Default โดย Client สามารถ เลือกใช้ Library เฉพาะได้

[

GitHub - benjaminion/c-kzg: Simple implementation of KZG commitments in C
-------------------------------------------------------------------------

Simple implementation of KZG commitments in C. Contribute to benjaminion/c-kzg development by creating an account on GitHub.

https://github.com

![](https://storage.googleapis.com/papyrus_images/b79c5f9bc3fdb17d27f8a988ddc011a5d753ffb919d1f0835506b715ad010a19.png)

](https://github.com/benjaminion/c-kzg)

จากการพูดคุยที่ยาวนานในงาน Devcon ถึงช่วงเวลาในการลอนช์ 4844 โดยทีม Client ส่วนใหญ่ยังโฟกัสการ Sharding และ Scaling เป็นอันดับแรกก่อน และเพื่อป้องกันไม่ให้ 4844 ไปบล็อก Withdrawal

ถ้าใครอยากฟังเรื่อง Tradeoffs ของเรื่องนี้ สามารถฟังเพิ่มที่ลิ้งด้านล่างนี้ ประมาณชั่วโมงแรก 1 ของ

[@EthMagicians](https://twitter.com/EthMagicians) ใน [https://youtu.be/idBYmaok520?t=13461](https://t.co/J2RMDDxs2k) ในนี้ยังมีคนเจ๋งๆ นั่งคุยกันอย่าง [@vdWijden](https://twitter.com/vdWijden) [@dankrad](https://twitter.com/dankrad) [@VitalikButerin](https://twitter.com/VitalikButerin) [@peter\_szilagyi](https://twitter.com/peter_szilagyi)และคนอื่นๆ อีกเพียบ

ยังไม่มีการตัดสินใจแบบเป็นทางการในการเพิ่ม 4844 เข้าไปในฮาร์ดฟอร์กถัดไป (Shanghai Hardfork) แต่ก็เปิดรับฟังไอเดียเต็มที่ ถ้าบังเอิญทันเวลา Withdrawals พอดี (สารภาพว่าคนแปลงงท่อนนี้) ส่วนวิธีที่ดีที่สุดในการแสดงสิ่งนี้ใน specs และ client codebases ยังอยู่ระหว่างการตัดสินใจ

จากฟีดแบ็กที่ได้ ทีมที่ดูแลโปรเจคจะลุยต่อแบบฟูลสตรีม ส่วนทีม Client ก็ไปจัดการเรื่อง withdrawals ให้เสร็จก่อน ในช่วงสั้นๆ นี่หมายถึงการ Implement ลงใน Cilent ซัก 2-3 ตัว (Lodestar, Erigon, Nethermind) ทำแบนวิธเทส และลอนช์บน Devnet 3

ช่วงสิ้นเดือน (ตค) ทีมวางแผนจะลองเช็กความคืบหน้าใหม่อีกทีเพื่อให้ทัน Shanghai Hardfork ทีมยังแฮปปี้กับการทำงานแบบ Joint ข้ามบริษัท (Coinbase, OP labs) และตั้งเป้าจะปล่อย 4844 ให้เร็วที่สุด

สุดท้ายแล้วขอยกเครดิตให้

[@ethereum](https://twitter.com/ethereum), [@OPLabsPBC](https://twitter.com/OPLabsPBC), [@coinbase](https://twitter.com/coinbase), [@worldcoin](https://twitter.com/worldcoin) , [@paradigm](https://twitter.com/paradigm), [@prylabs](https://twitter.com/prylabs), [@go\_ethereum](https://twitter.com/go_ethereum) และอีกหลายๆ คนที่มีส่วนในการ Contribute ให้ มาร่วม scaling Ethereum ไปด้วยกัน

---

*Originally published on [thesleeper (✨🔴_🔴✨)](https://paragraph.com/@thesleeper/4844)*