การอัปเกรด Glamsterdam โซลูชันการปรับขนาด L1 ของ Ethereum

ต้นฉบับ | Odaily Planet Daily jk

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

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

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

ข้อเสนอหลักสองประการของการอัปเกรดนี้มุ่งเน้นไปที่เลเยอร์ฉันทามติและเลเยอร์การดำเนินการ:

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

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

อันดับแรก เรามาพูดคุยเกี่ยวกับข้อเสนอหลักสำหรับเลเยอร์ฉันทามติ ซึ่งทำหน้าที่แยกผู้เสนอและผู้สร้างภายในโปรโตคอล ซึ่งมีชื่อย่อในภาษาอังกฤษว่า ePBS (EIP-7732)

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

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

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

ต่อไป เราจะมาพูดคุยเกี่ยวกับข้อเสนอหลักสำหรับเลเยอร์การดำเนินการ ซึ่งก็คือรายการควบคุมการเข้าถึงระดับบล็อก หรือเรียกย่อว่า BALs (EIP-7928)

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

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

ข้อเสนอสนับสนุน: การประเมินใหม่เกี่ยวกับ "การดำเนินงานที่ใช้พื้นที่"

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

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

วันเปิดตัวเมนเน็ต: ยังไม่กำหนด

ในแง่ของไทม์ไลน์ ปัจจุบัน Glamsterdam อยู่ในช่วงที่ค่อนข้างละเอียดอ่อน ในส่วนของข้อมูลอย่างเป็นทางการ การประชุมที่ตรวจสอบได้ครั้งล่าสุดของนักพัฒนาหลักทั้งหมดสำหรับเลเยอร์การดำเนินการ (ACDE) คือการประชุมครั้งที่ 241 ซึ่งจัดขึ้นเมื่อวันที่ 16 กรกฎาคม โดยวาระหลักรวมถึงการอัปเดตเกี่ยวกับเฟส Devnet ของ Glamsterdam และการคัดเลือกข้อเสนอหลักสำหรับการอัปเกรดครั้งต่อไป Hegota ตารางเวลาที่อ้างอิงกันอย่างกว้างขวางในอุตสาหกรรมระบุว่า เฟส Devnet ผ่านการพัฒนาแปดรอบตั้งแต่รอบที่ 0 ถึง 7 ครอบคลุมช่วงตั้งแต่วันที่ 28 มีนาคม 2026 ถึง 8 กรกฎาคม ตามด้วยการแยกเครือข่ายทดสอบ Sepolia ซึ่งเดิมกำหนดไว้สำหรับวันที่ 3 สิงหาคม 2026 และการแยกเครือข่ายทดสอบ Hoodi ซึ่งเดิมกำหนดไว้สำหรับวันที่ 17 สิงหาคม 2026 โดยมีเป้าหมายที่จะเปิดใช้งาน mainnet ในวันที่ 16 กันยายน 2026

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

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