นักพัฒนา Ethereum เสนอ FCR เพื่อเร่งการยืนยัน L2 และการแลกเปลี่ยน

4 ชั่วโมง ที่ผ่านมา
อ่าน 7 นาที
3 มุมมอง

การทดสอบกลไกใหม่ของ Ethereum

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

การลดเวลาการยืนยัน

ข้อเสนอนี้คาดว่าจะลดเวลาการยืนยันลงเหลือประมาณ 13 วินาที ตามที่นักวิจัย Ethereum, Julian Ma กล่าว. ด้วยการใช้วิธีนี้ แพลตฟอร์มสามารถเลิกใช้ระบบที่พึ่งพาสะพานที่เป็นมาตรฐาน ซึ่งการโอนมักใช้เวลาถึง 13 นาที เพื่อให้ได้รับการยืนยันอย่างเต็มที่.

กฎการยืนยัน “k-deep”

อย่างไรก็ตาม หลายแห่งยังคงพึ่งพากฎการยืนยัน “k-deep” ซึ่งไม่มีการรับประกันอย่างเป็นทางการ. ธุรกรรมในโมเดลดังกล่าวจะถือว่าถูกยืนยันเมื่อมีการเพิ่มบล็อกจำนวนหนึ่งตามที่กำหนดไว้แล้ว. นักพัฒนากล่าวว่ากฎนี้สามารถนำมาใช้ได้โดยไม่ต้องทำ hard-fork แม้ว่าการรวมเข้ากับลูกค้าและ API ยังคงจำเป็น.

การนำไปใช้ FCR

ทีมงานลูกค้ากำลังทำงานเกี่ยวกับการนำไปใช้ โดยคาดว่าการปรับใช้จะอนุญาตให้โหนดนำกฎนี้ไปใช้โดยไม่ต้องประสานงานทั่วทั้งเครือข่าย. เมื่อใช้ FCR แทนที่จะนับบล็อก ระบบจะประเมินการรับรองของผู้ตรวจสอบเพื่อกำหนดว่าบล็อกนั้นปลอดภัยที่จะถือว่าถูกยืนยันหรือไม่.

การแก้ปัญหาการเชื่อมต่อที่ช้า

ซึ่งสามารถแก้ปัญหาการเชื่อมต่อที่ช้าระหว่าง Ethereum L1 และแพลตฟอร์มที่อยู่ด้านล่าง โดยอิงจากสมมติฐานสองประการ: ข้อความของผู้ตรวจสอบแพร่กระจายอย่างรวดเร็วทั่วทั้งเครือข่าย และไม่มีหน่วยงานใดควบคุม Ether ที่ถูกวางเดิมพันมากกว่า 25%. แม้ว่าขีดจำกัดเหล่านี้จะต่ำกว่าการรับประกันความแน่นอนที่เข้มงวดของ Ethereum แต่ก็ถือว่ามีความเพียงพอสำหรับกรณีการใช้งานในโลกจริง.

ความปลอดภัยและการรับประกัน

ในกรณีที่ต้องการความปลอดภัยมากขึ้น ระบบจะรอเวลานานขึ้นก่อนที่จะยืนยันบล็อก. Ma อธิบายเพิ่มเติมว่า

“มันเป็นฟีเจอร์ ไม่ใช่บั๊ก”

. Vitalik Buterin ผู้ร่วมก่อตั้ง Ethereum กล่าวว่า กลไกนี้สามารถให้ “การรับประกันที่แน่นอน” ว่าธุรกรรมจะไม่ถูกย้อนกลับหลังจากช่องว่างเดียวภายใต้เงื่อนไขเครือข่ายที่เหมาะสม.

ข้อกังวลจากชุมชน

แต่สมาชิกในชุมชนคนอื่นยังคงสงสัยเกี่ยวกับข้อเสนอ. บางคนโต้แย้งว่าโมเดลนี้พึ่งพาสมมติฐานด้านความไว้วางใจอย่างมากและอาจเผชิญกับความท้าทายภายใต้เงื่อนไขเครือข่ายที่ตึงเครียด.

ล่าสุดจาก Blog