<100 subscribers
Share Dialog
Share Dialog


อยากรู้มั้ยกว่าจะปล่อยเทคใหม่ Dev ต้องผ่านอะไรบ้าง? เล่าผ่านเคส EIP-4844 ตัวตึงที่จะทำให้ Rollups ถูกลง 10-100x โดบสรุปจากสิ่งที่เกิดขึ้นในงาน @EFDevcon แบบสั้น กระชับ จับใจความง่าย ไม่เปลืองแบนด์วิธ แปลจากเธรดของ @jessepollak (หนึ่งในทีมจาก Coinbase) พร้อมแล้วไปลุยกันเลย
ปูพื้น : EIP4844 คือสิ่งที่จะช่วยลดค่าทำธุรกรรมและเพิ่มความเร็ว (TPS) ของ L2 Rollups ได้ 10-100X โดยสร้าง data availability แบบใหม่บน ETH เรียกว่า "Blobspace" อ่านเพิ่มได้ที่
สิ่งนี้นี้จะช่วยเร่ง Adoptionให้ ETH แบบเบิ้มๆ แต่จะเบิ้มแค่ไหนก็ขอยกคำพูดจาก @coinbase มาเลยดีกว่า
"เราเชื่อว่า EIP4844 จะเป็นกุญแจสำคัญในการดึงผู้ใช้ (ลูกค้า) ใหม่ๆ ให้เข้าสู่โลกคริปโตได้อย่างปลอดภัย ใช้งานง่าย รวดเร็วกว่าเดิมได้ แถมยังถูกลงด้วย"
https://www.coinbase.com/blog/supporting-eip-4844-reducing-fees-for-ethereum-layer-2-rollups
เป้าหมายหลักที่ Devcon คือการดึงเอาหัวกระทิจากทีม Client ต่างๆ มาคิดหาวิธีที่ดีที่สุดในการปล่อย EIP4844 โดยทีม @Ethereum @OPLabsPBC และ @Coinbase ใช้เวลาเขียนสเปคร่วมกันนาน 5 เดือน โดย Implement ลงบน Geth & Prysm ลอนช์ใน 2 Devnet และเตรียม KZG ceremony
โดยในงานทีมได้มีการประชุมกันแทบทุกวัน ถกกันเรื่องเซ็ตติ้งแบบต่างๆ จัดเวิร์กช้อปอีกหลายครั้ง ระหว่างทีม Client และมีการแลกเปลี่ยนกับ @EthMagicians จนได้ข้อสรุปในการปรับอะไรเล็กๆ น้อยๆ เช่นสเปกของ Execution & Consensus Layer เพื่อลดข้อกังวลเรื่อง Network impact จาก Blobs
ใน Consensus Layer ทีมตัดสินใจรวม Blobs และ Block ไว้ด้วยกันก่อน (แทนการปล่อยให้แยกกัน) เพื่อลดความซับซ้อนในการ Implement Note : แต่เมื่อ Danksharding ตัวเต็มมาถึง ทีมค่อยปรับให้มันแยกกันทีหลัง
ใน Execution Layer เพื่อลดโอกาสในการทำ DOS Vector ทีมตัดสินใจอัพเดต Wire Protocol เพื่อจำกัดให้ Announced เฉพาะธุรกรรมที่มี Blobs แทนการใช้ Broadcast วิธีนี้จะช่วยจัดการความปลอดภัยในการค้น Blobs ให้ Client ได้ดีขึ้น
สิ่งที่ทีมกังวลที่สุด (จากฟีดแบ็กของทีม Client) คือเรื่องความล่าช้าของระบบจากแบนวิธบนเครือข่ายที่เพิ่มขึ้นเมื่อใช้ Blobs ซึ่งทีมก็พอจะเดาได้ แต่ก็อยากลดความเสี่ยงให้เหลือน้อยที่สุด
เพื่อแก้ปัญหานี้ทีมได้ทำการจำลองสิ่งที่น่าจะเกิดขึ้นเมื่อเครือข่ายมีการใช้ Blob โดยการสร้างบล็อกจำนวนนึง ที่แต่ละอันจะยัด CALLDATA ใส่เข้าไป โดยลองทั้ง Testnet และ Mainnet แล้วดูว่า Node ต่างๆ จะตอบสนองยังไง
ผลจากการทดลองได้ข้อสรุปว่า ทีมต้องทำการปรับแต่งขนาดของขนาดของ Blobs ให้เหมาะกับแบนวิธที่จำกัดเพื่อลดปัญหา ทีมยังตื่นเต้นจากการได้เดต้าจริงๆ ของ final 4844 parameters
ตอนท้ายทีมได้มีการคุยกันเรื่องจะใช้ Library ไหน สำหรับ KZG commitments ระหว่าง EL และ CL โดยสรุปให้ใช้ c-kzg library เป็น Default โดย Client สามารถ เลือกใช้ Library เฉพาะได้
จากการพูดคุยที่ยาวนานในงาน Devcon ถึงช่วงเวลาในการลอนช์ 4844 โดยทีม Client ส่วนใหญ่ยังโฟกัสการ Sharding และ Scaling เป็นอันดับแรกก่อน และเพื่อป้องกันไม่ให้ 4844 ไปบล็อก Withdrawal
ถ้าใครอยากฟังเรื่อง Tradeoffs ของเรื่องนี้ สามารถฟังเพิ่มที่ลิ้งด้านล่างนี้ ประมาณชั่วโมงแรก 1 ของ
@EthMagicians ใน https://youtu.be/idBYmaok520?t=13461 ในนี้ยังมีคนเจ๋งๆ นั่งคุยกันอย่าง @vdWijden @dankrad @VitalikButerin @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, @OPLabsPBC, @coinbase, @worldcoin , @paradigm, @prylabs, @go_ethereum และอีกหลายๆ คนที่มีส่วนในการ Contribute ให้ มาร่วม scaling Ethereum ไปด้วยกัน
อยากรู้มั้ยกว่าจะปล่อยเทคใหม่ Dev ต้องผ่านอะไรบ้าง? เล่าผ่านเคส EIP-4844 ตัวตึงที่จะทำให้ Rollups ถูกลง 10-100x โดบสรุปจากสิ่งที่เกิดขึ้นในงาน @EFDevcon แบบสั้น กระชับ จับใจความง่าย ไม่เปลืองแบนด์วิธ แปลจากเธรดของ @jessepollak (หนึ่งในทีมจาก Coinbase) พร้อมแล้วไปลุยกันเลย
ปูพื้น : EIP4844 คือสิ่งที่จะช่วยลดค่าทำธุรกรรมและเพิ่มความเร็ว (TPS) ของ L2 Rollups ได้ 10-100X โดยสร้าง data availability แบบใหม่บน ETH เรียกว่า "Blobspace" อ่านเพิ่มได้ที่
สิ่งนี้นี้จะช่วยเร่ง Adoptionให้ ETH แบบเบิ้มๆ แต่จะเบิ้มแค่ไหนก็ขอยกคำพูดจาก @coinbase มาเลยดีกว่า
"เราเชื่อว่า EIP4844 จะเป็นกุญแจสำคัญในการดึงผู้ใช้ (ลูกค้า) ใหม่ๆ ให้เข้าสู่โลกคริปโตได้อย่างปลอดภัย ใช้งานง่าย รวดเร็วกว่าเดิมได้ แถมยังถูกลงด้วย"
https://www.coinbase.com/blog/supporting-eip-4844-reducing-fees-for-ethereum-layer-2-rollups
เป้าหมายหลักที่ Devcon คือการดึงเอาหัวกระทิจากทีม Client ต่างๆ มาคิดหาวิธีที่ดีที่สุดในการปล่อย EIP4844 โดยทีม @Ethereum @OPLabsPBC และ @Coinbase ใช้เวลาเขียนสเปคร่วมกันนาน 5 เดือน โดย Implement ลงบน Geth & Prysm ลอนช์ใน 2 Devnet และเตรียม KZG ceremony
โดยในงานทีมได้มีการประชุมกันแทบทุกวัน ถกกันเรื่องเซ็ตติ้งแบบต่างๆ จัดเวิร์กช้อปอีกหลายครั้ง ระหว่างทีม Client และมีการแลกเปลี่ยนกับ @EthMagicians จนได้ข้อสรุปในการปรับอะไรเล็กๆ น้อยๆ เช่นสเปกของ Execution & Consensus Layer เพื่อลดข้อกังวลเรื่อง Network impact จาก Blobs
ใน Consensus Layer ทีมตัดสินใจรวม Blobs และ Block ไว้ด้วยกันก่อน (แทนการปล่อยให้แยกกัน) เพื่อลดความซับซ้อนในการ Implement Note : แต่เมื่อ Danksharding ตัวเต็มมาถึง ทีมค่อยปรับให้มันแยกกันทีหลัง
ใน Execution Layer เพื่อลดโอกาสในการทำ DOS Vector ทีมตัดสินใจอัพเดต Wire Protocol เพื่อจำกัดให้ Announced เฉพาะธุรกรรมที่มี Blobs แทนการใช้ Broadcast วิธีนี้จะช่วยจัดการความปลอดภัยในการค้น Blobs ให้ Client ได้ดีขึ้น
สิ่งที่ทีมกังวลที่สุด (จากฟีดแบ็กของทีม Client) คือเรื่องความล่าช้าของระบบจากแบนวิธบนเครือข่ายที่เพิ่มขึ้นเมื่อใช้ Blobs ซึ่งทีมก็พอจะเดาได้ แต่ก็อยากลดความเสี่ยงให้เหลือน้อยที่สุด
เพื่อแก้ปัญหานี้ทีมได้ทำการจำลองสิ่งที่น่าจะเกิดขึ้นเมื่อเครือข่ายมีการใช้ Blob โดยการสร้างบล็อกจำนวนนึง ที่แต่ละอันจะยัด CALLDATA ใส่เข้าไป โดยลองทั้ง Testnet และ Mainnet แล้วดูว่า Node ต่างๆ จะตอบสนองยังไง
ผลจากการทดลองได้ข้อสรุปว่า ทีมต้องทำการปรับแต่งขนาดของขนาดของ Blobs ให้เหมาะกับแบนวิธที่จำกัดเพื่อลดปัญหา ทีมยังตื่นเต้นจากการได้เดต้าจริงๆ ของ final 4844 parameters
ตอนท้ายทีมได้มีการคุยกันเรื่องจะใช้ Library ไหน สำหรับ KZG commitments ระหว่าง EL และ CL โดยสรุปให้ใช้ c-kzg library เป็น Default โดย Client สามารถ เลือกใช้ Library เฉพาะได้
จากการพูดคุยที่ยาวนานในงาน Devcon ถึงช่วงเวลาในการลอนช์ 4844 โดยทีม Client ส่วนใหญ่ยังโฟกัสการ Sharding และ Scaling เป็นอันดับแรกก่อน และเพื่อป้องกันไม่ให้ 4844 ไปบล็อก Withdrawal
ถ้าใครอยากฟังเรื่อง Tradeoffs ของเรื่องนี้ สามารถฟังเพิ่มที่ลิ้งด้านล่างนี้ ประมาณชั่วโมงแรก 1 ของ
@EthMagicians ใน https://youtu.be/idBYmaok520?t=13461 ในนี้ยังมีคนเจ๋งๆ นั่งคุยกันอย่าง @vdWijden @dankrad @VitalikButerin @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, @OPLabsPBC, @coinbase, @worldcoin , @paradigm, @prylabs, @go_ethereum และอีกหลายๆ คนที่มีส่วนในการ Contribute ให้ มาร่วม scaling Ethereum ไปด้วยกัน
thesleeper (✨🔴_🔴✨)
thesleeper (✨🔴_🔴✨)
No comments yet