ฉันจะดำเนินการแปลเนื้อหานี้เป็นภาษาไทยตามคำขอ โดยคงโครงสร้าง HTML และแท็กทั้งหมดไว้ รวมถึงตัวแบ่ง `

ต้นฉบับ｜Odaily 星球日报（@OdailyChina）

ผู้เขียน｜jk

การอัปเกรด Glamsterdam ที่กำลังจะมาถึงของ Ethereum คือการปรับโครงสร้างโปรโตคอลครั้งใหญ่ที่สุดในสายตาของนักพัฒนาหลัก นับตั้งแต่ The Merge โดยเป็นการปรับสถาปัตยกรรมระดับโปรโตคอลครั้งใหญ่ที่สุด ชื่อนี้มาจากการรวมกันของสองส่วน: ส่วนการอัปเกรดเลเยอร์Executionยังคงใช้ชื่อ "Amsterdam" ตามชื่อเมืองอัมสเตอร์ดัมซึ่งเป็นสถานที่จัดงาน Devconnect ครั้งก่อน ส่วนการอัปเกรดเลเยอร์Consensusถูกตั้งชื่อว่า "Gloas" ตามชื่อดาวฤกษ์ดวงหนึ่ง ต่อจากการอัปเกรด Fusaka ก่อนหน้านี้ Glamsterdam ขับเคลื่อนการขยายขนาด L1 ด้วยการปรับโครงสร้างวิธีการที่เครือข่ายประมวลผลธุรกรรมและจัดการฐานข้อมูลที่เติบโตอย่างต่อเนื่อง โดยเปลี่ยนแปลงวิธีการสร้างและตรวจสอบบล็อกของ Ethereum อย่างพื้นฐาน

การอัปเกรดครั้งนี้มุ่งเน้นไปที่เป้าหมายหลักสามประการ:

• การประมวลผลที่เร็วขึ้น (Parallelization): ปรับโครงสร้างวิธีการบันทึกความสัมพันธ์ของข้อมูลของเครือข่าย เพื่อให้สามารถประมวลผลธุรกรรมจำนวนมากได้อย่างปลอดภัยพร้อมกัน แทนที่จะประมวลผลแบบเรียงตามลำดับทีละรายการอย่างช้าๆ
• การขยายขนาด: แบ่งงานหนักในการสร้างและตรวจสอบบล็อก เพื่อให้เครือข่ายมีเวลามากขึ้นในการแพร่กระจายข้อมูลปริมาณมากขึ้นโดยไม่ช้าลง
• ความยั่งยืน: ปรับค่าธรรมเนียมเครือข่ายเพื่อสะท้อนต้นทุนฮาร์ดแวร์ระยะยาวของการจัดเก็บข้อมูลใหม่ได้อย่างแม่นยำ ปูทางไปสู่การเพิ่มขีดจำกัด Gas ในอนาคต พร้อมทั้งหลีกเลี่ยงประสิทธิภาพฮาร์ดแวร์ที่ถดถอย

ข้อเสนอหลักสองรายการของการอัปเกรดอยู่ที่เลเยอร์ Consensus และเลเยอร์ Execution:

มีข้อเสนอ Headliner หลักสองรายการ ที่มา: Ethereum

ข้อเสนอหลักรายการที่หนึ่ง: ePBS เปลี่ยน "ตัวกลางที่จ้างจากภายนอก" เป็น "กฎในตัว"

พูดถึงข้อเสนอหลักบนเลเยอร์ Consensus ก่อน นั่นคือการแยก Proposer และ Builder ในโปรโตคอล เรียกย่อในภาษาอังกฤษว่า ePBS (EIP-7732)

การสร้างบล็อกของ Ethereum ในแต่ละครั้งแบ่งเป็นสองขั้นตอน: คนหนึ่ง負責 "เลือกว่าบล็อกไหน" (Proposer) และอีกคน負責 "ประกอบธุรกรรมในบล็อกจริงๆ" (Builder) ปัจจุบันการแบ่งงานนี้ไม่ได้ถูกกำหนดโดยโปรโตคอลของ Ethereum เอง แต่อาศัยกลุ่ม "บริษัทตัวกลาง" นอกเครือข่าย (เรียกในวงการว่า Relay) เป็นผู้ประสานงาน ความสัมพันธ์นอกเครือข่ายนี้ยังสร้างเส้นทางระหว่างการตรวจสอบบล็อก ซึ่งบังคับให้ Validator ต้องรีบดำเนินการ Broadcast และ Execution ธุรกรรมภายในหน้าต่างเวลาอันจำกัด 2 วินาที ซึ่งจำกัดปริมาณข้อมูลที่เครือข่ายสามารถรองรับได้ อุปมาอุปไมยก็คือ เหมือนร้านอาหารแห่งหนึ่งที่ขั้นตอนการสั่งอาหารและการทำอาหารเดิมต้องอาศัยผู้ประสานงานภายนอกอิสระมาช่วยส่งอาหาร เมื่อผู้ประสานงานคนนี้พลาดท่า ครัวและหน้าร้านก็อาจบันทึกข้อมูลไม่ตรงกัน

สิ่งที่ ePBS ทำ คือการเขียนกฎการแบ่งงาน "สั่งอาหาร-ทำอาหาร" นี้ลงในคู่มือการปฏิบัติงานของร้านเอง ไม่ต้องพึ่งพาผู้ประสานงานภายนอกอีกต่อไป ด้วยวิธีนี้ กลไกการส่งมอบและการชำระเงินบล็อกที่เชื่อถือได้บนเครือข่ายจึงถูกสร้างเข้าไปในโปรโตคอลโดยตรง โดยไม่ต้องพึ่งพา Middleware ของบุคคลที่สาม อย่างไรก็ตาม หากทั้งสองฝ่ายต้องการใช้ฟีเจอร์ซับซ้อนที่ยังไม่ได้กำหนดไว้ในโปรโตคอล ก็ยังสามารถเลือกใช้ผู้ประสานงานภายนอกต่อไปได้ ในเวลาเดียวกัน เพื่อไม่ให้ขั้นตอน "ส่งอาหาร" ยุ่งเหยิง ePBS ยังได้จัดตั้ง "ทีมตรวจสอบอาหาร" แยกต่างหาก เพื่อตรวจสอบ "ใครสั่งอาหาร" และ "อาหารถูกทำเสร็จและเสิร์ฟตรงเวลาหรือไม่" แยกจากกัน ทำให้หน้าต่างเวลาส่งอาหารเดิม 2 วินาทีขยายเป็นประมาณ 9 วินาที ทำให้ร้านสามารถรองรับออเดอร์ได้มากขึ้นในครั้งเดียว นั่นก็คือทำให้ Ethereum รองรับข้อมูลที่ส่งไปยัง Layer2 ได้มากขึ้น

ข้อเสนอหลักรายการที่สอง: BALs เตรียม "รายการช้อปปิ้ง" ให้พร้อมก่อนออกเดินทาง

พูดถึงข้อเสนอหลักบนเลเยอร์ Execution ต่อ นั่นคือ Block-Level Access Lists เรียกย่อในภาษาอังกฤษว่า BALs (EIP-7928)

ปัจจุบันวิธีที่ Ethereum ประมวลผลธุรกรรม คล้ายกับคนๆ หนึ่งถูกปิดตาไปซื้อของที่ซูเปอร์มาร์เก็ต: ต้องคลำหาสินค้าก่อน ยืนยันว่าคืออะไร จึงจะตัดสินใจขั้นตอนต่อไปได้ ดังนั้นจึงต้องต่อคิวทีละรายการ เนื่องจากไม่รู้ล่วงหน้าว่าธุรกรรมหนึ่งๆ จะใช้ข้อมูลใดบ้าง เช่น เกี่ยวข้องกับบัญชีใด ระบบจึงต้องประมวลผลธุรกรรมตามลำดับอย่างเคร่งครัด ไม่เช่นนั้นธุรกรรมสองรายการอาจพยายามแก้ไขข้อมูลเดียวกันพร้อมกันโดยไม่ตั้งใจ (เช่น ยอดคงเหลือของที่อยู่เดียวกัน) ทำให้เกิดความขัดแย้งและข้อผิดพลาด

BALs เทียบเท่ากับการให้คนๆ นั้นได้รับรายการช้อปปิ้งที่เขียนไว้ชัดเจนว่า "ต้องไปชั้นวางไหน หยิบอะไรบ้าง" ก่อนออกเดินทาง เมื่อมีรายการนี้ ระบบจะมองเห็นล่วงหน้าได้ว่าธุรกรรมใดบ้างที่ไม่เกี่ยวข้องกันโดยสิ้นเชิง จึงสามารถแบ่งธุรกรรมที่ไม่เกี่ยวข้องกันออกเป็นกลุ่มๆ และประมวลผลแบบขนานพร้อมกัน โดยไม่ต้องต่อคิวทีละรายการอีกต่อไป รายการนี้ยังมีประโยชน์เพิ่มเติมอีกอย่าง: เมื่อโหนดใหม่เข้าร่วมเครือข่าย สามารถคัดลอกผลลัพธ์สุดท้ายที่บันทึกไว้ในรายการนี้ได้โดยตรง โดยไม่ต้องคำนวณธุรกรรมประวัติศาสตร์ที่ซับซ้อนทั้งหมดใหม่ ทำให้โหนดใหม่ซิงค์ข้อมูลได้เร็วขึ้นมาก เพื่อให้รายการนี้กระจายตัวในเครือข่ายได้จริง Glamsterdam ยังได้รวมการอัปเกรดโปรโตคอลการ传输ที่รองรับ ซึ่งให้โหนดต่างๆ สามารถแชร์ Access Lists เหล่านี้ได้จริง ในปัจจุบันโปรโตคอลการ传输นี้กลายเป็นข้อบังคับสำหรับไคลเอนต์ Execution Layer ทั้งหมด

ข้อเสนอเสริม: คิดราคาใหม่สำหรับการดำเนินการที่ "กินพื้นที่"

นอกจากข้อเสนอหลักสองรายการนี้ Glamsterdam ยังได้รวมข้อเสนอเสริมด้านการปรับราคาใหม่สองรายการ ซึ่งสามารถเข้าใจได้ว่าเป็นการปรับตารางราคา "ค่าจัดเก็บ" และ "ค่าค้นหา" ของเครือข่ายแยกกัน

• รายการแรกคือการดำเนินการที่ "กินพื้นที่ถาวร" ในเครือข่าย เช่น การสร้างบัญชีใหม่ การ Deploy คอนแทรก ซึ่งเดิมค่าธรรมเนียมไม่ค่อยเป็นสัดส่วนกับพื้นที่จริงที่ใช้ ตอนนี้จะคิดค่าธรรมเนียมใหม่ตามหลัก "ใช้พื้นที่เท่าไรจ่ายเท่านั้น" โดยมีเป้าหมายเพื่อควบคุมอัตราการเติบโตของข้อมูลทั้งเครือข่ายให้อยู่ที่ระดับ 120 GiB ต่อปี ซึ่งเป็นระดับที่ปลอดภัยและคาดเดาได้ เพื่อให้แน่ใจว่าเครือข่ายยังคงทำงานได้อย่างต่อเนื่องบนฮาร์ดแวร์ทั่วไป ในขณะเดียวกันค่าจัดเก็บนี้จะแยกบัญชีในการคำนวณ ไม่ปะปนกับค่าคำนวณสำหรับการประมวลผลธุรกรรมเอง หากนักพัฒนายินดีจ่ายค่าจัดเก็บเพิ่มขึ้น ก็ยังสามารถ Deploy แอปพลิเคชันที่มีขนาดใหญ่และซับซ้อนมากขึ้นได้ โดยไม่ถูกจำกัดด้วยขีดจำกัด Gas โดยรวมในทันที
• รายการที่สองคือการดำเนินการที่เกี่ยวข้องกับการค้นหาและอ่านข้อมูลที่มีอยู่แล้วในเครือข่าย ซึ่งเดิม定价ต่ำเกินไป ไม่ทันกับต้นทุนการค้นหาจริงเมื่อข้อมูลมีปริมาณมากขึ้น ครั้งนี้จะเพิ่มอัตราค่าธรรมเนียมของ Opcode ประเภทนี้ เพื่อให้ราคาใกล้เคียงกับภาระจริงของฮาร์ดแวร์สมัยใหม่มากขึ้น พร้อมทั้งป้องกันไม่ให้มีคนฉวยโอกาสจากค่าธรรมเนียมที่ถูกเกินไป จงใจส่งคำขอค้นหาจำนวนมากมาอุดตันเครือข่าย

เวลาเปิดตัว Mainnet: ยังไม่ถูกกำหนด

ในด้านกำหนดการ ตอนนี้ Glamsterdam อยู่ในช่วงที่ค่อนข้างละเอียดอ่อน ในระดับทางการ การประชุม All Core Developers Execution (ACDE) ครั้งที่ได้รับการยืนยันล่าสุดคือครั้งที่ 241 เมื่อวันที่ 16 กรกฎาคม วาระหลักรวมถึงการอัปเดตความคืบหน้าล่าสุดของ Glamsterdam Devnet และการลงคะแนนเลือกข้อเสนอหลักสำหรับการอัปเกรดครั้งถัดไป Hegota ก่อนหน้านี้กำหนดการที่ถูกอ้างอิงอย่างกว้างขวางในอุตสาหกรรมแสดงให้เห็นว่าเฟส Devnet มีการ Iteration ทั้งหมดแปดครั้งตั้งแต่ 0 ถึง 7 โดยมีช่วงเวลาตั้งแต่วันที่ 28 มีนาคม 2026 ถึง 8 กรกฎาคม ต่อมา Sepolia Testnet Fork เดิมกำหนดไว้ในวันที่ 3 สิงหาคม 2026 และ Hoodi Testnet Fork เดิมกำหนดไว้ในวันที่ 17 สิงหาคม 2026 โดยวันที่เป้าหมายสำหรับการเปิดใช้งาน Mainnet คือวันที่ 16 กันยายน 2026

กำหนดการเดิมคือช่วงครึ่งแรกของปี 2026 ที่มา: Ethereum

แต่จากความเคลื่อนไหวล่าสุด กำหนดการนี้มีแนวโน้มสูงที่จะถูกเลื่อนออกไป ทีม EthPandaOps เพิ่งเปิดตัว Testnet ใหม่ชื่อ Plataberget ซึ่งเป็น Testnet สาธารณะระยะสั้นตัวแรกที่ออกแบบมาสำหรับ Glamsterdam โดยเฉพาะ การ Deploy บน Sepolia และ Hoodi อย่างเป็นทางการคาดว่าจะเลื่อนออกไปเป็นเดือนกันยายน และเป้าหมายการเปิดตัว Mainnet ก็เลื่อนออกไปเป็นไตรมาสที่สี่ของปี 2026 เช่นกัน นี่เป็นการเลื่อนวันที่ครั้งที่สองของ Glamsterdam ต่อจากการเลื่อนจากครึ่งแรกของปี 2026 ตามกำหนดการเดิม นักพัฒนาหลักได้เน้นย้ำหลายครั้งแล้วว่าความถูกต้องของการอัปเกรดสำคัญกว่าการทันกำหนดการใดๆ ดังนั้นก่อนที่การประชุม ACD อย่างเป็นทางการจะล็อกหมายเลขบล็อกที่แน่นอน เราอาจต้องรอจนถึงไตรมาสที่สี่หรือ甚至สิ้นปีจึงจะได้เห็นการอัปเกรดครั้งนี้