ร่าง EIP-8390 เสนอปลด Sync Committee ของ Ethereum ลดการออกเหรียญราว 33,800 ETH ต่อปี

ข้อเสนอใหม่ของ Ethereum ที่เพิ่งถูกรวมเข้าคลัง EIPs อย่างเป็นทางการเสนอให้ยุติการทำงานของ "sync committee" ซึ่งเป็นชุดตัวอย่างผู้ตรวจสอบ (validator) จำนวน 512 ราย ตัดรางวัลที่ผูกกับกลไกดังกล่าว และทำให้ส่วนติดต่อ light client ตามสเปก Altair ในปัจจุบันหมดความจำเป็น โดยจะหันไปใช้หลักฐานแบบ zero-knowledge ที่สร้างนอกเครือข่ายแทน ร่าง EIP-8390 ประเมินว่า หากลบ "น้ำหนักรางวัล" ของ sync committee ออก จะทำให้ปริมาณการออกเหรียญฝั่งฉันทามติ (consensus issuance) ลดลงราว 33,800 ETH ต่อปี ตามสูตรรางวัลของฉันทามติที่กำหนดน้ำหนักของ sync committee เท่ากับ 2 จากตัวหาร 64 การลบน้ำหนักนี้โดยไม่กระจายใหม่เท่ากับลด issuance ลง 2/64 หรือ 1/32 ทั้งนี้ ตัวเลขในเอกสารอ้างอิงสแนปช็อต 901,505 validators และ ETH ที่นำไปสเตก 42,328,615 ETH เมื่อเทียบกับประมาณการ consensus issuance ต่อปีราว 1.082 ล้าน ETH ส่วนที่ถูกตัดออกจึงอยู่แถว 33,800 ETH ต่อปี เอกสารระบุด้วยว่า การลด 1/32 ไม่ได้หมายความว่าผลตอบแทนจริงของ validators ทุกคนจะลดลง 3.125% แบบเท่ากันทั้งหมด เพราะเป็นการลดเฉพาะส่วน issuance ที่จัดสรรให้รางวัล sync committee ขณะที่ผลตอบแทนจริงยังรวมรางวัลฉันทามติรูปแบบอื่น และรายได้จากชั้น execution ด้วย ข้อเสนอถูกบันทึกเข้าสู่ EIPs repository เมื่อเวลา 02:04 UTC วันที่ 24 ส.ค. แต่ยังอยู่สถานะ "Draft" ซึ่งหมายถึงเป็นแบบร่างเพื่อถกเถียง ไม่ใช่อัปเกรดที่รับรองแล้ว เอกสารยังไม่ระบุ activation epoch และไม่มีข้อผูกพันกับโรดแมปของ Ethereum โดยปล่อยการจัดตารางให้ทีมไคลเอนต์พิจารณา อีกทั้งในอัปเดตฉบับร่างแรกของเธรดอภิปราย ผู้เขียนระบุว่าไม่มีรีวิวจากภายนอก ประเด็นความปลอดภัยถูกแลกด้วยการพึ่งพาโครงสร้างใหม่ ในปัจจุบัน sync committee ทำหน้าที่เป็นชุดตัวอย่าง 512 validators ที่ส่งข้อความให้ light clients ใช้ติดตาม beacon chain ได้แบบกระชับ โดยไม่ต้องประมวลผล validator ทั้งหมด อย่างไรก็ดี สเปก Altair ไม่ได้กำหนดเงื่อนไข slashing เฉพาะสำหรับ validator ที่ลงนามข้อความ sync committee ที่เป็นอันตราย ก่อนหน้านี้ EIP-7657 ซึ่งพยายามเพิ่มบทลงโทษลักษณะดังกล่าวถูกทำเครื่องหมายเป็น "Stagnant" และเคยเตือนว่าแอปพลิเคชันที่ปกป้องมูลค่ามากกว่า 512 เท่าของ 32 ETH หรือ 16,384 ETH ควรใช้โปรโตคอล light client ควบคู่กับมาตรการป้องกันอื่น ตัวเลขนี้เป็นคำเตือนเชิงออกแบบภายใต้เพดาน effective balance สูงสุด 32 ETH แต่สะท้อนความกังวลหลักเดียวกัน: ลายเซ็นจากชุดตัวอย่างช่วยให้ light clients ตามเครือข่ายได้ แต่ข้อความที่เป็นอันตรายจาก sync committee ไม่มีเงื่อนไข slashing ของตัวเองในโปรโตคอล EIP-8390 เลือกแก้ปัญหาความรับผิดชอบดังกล่าวด้วยการยกเลิกชุดตัวอย่าง และให้ light clients ตรวจสอบหลักฐาน zero-knowledge ของความเป็น "finality" ตาม Casper FFG ครอบคลุม validator ทั้งชุด โดยหลักฐานนี้จะกลายเป็นสัญญาณ finality สำหรับไคลเอนต์ที่ไม่ประมวลผล validator ทั้งหมด กระทบ light clients ตามสเปก Altair ที่ใช้งานอยู่ ร่าง EIP ระบุว่าจะตัดหน้าที่ของ validators ที่เกี่ยวข้อง ข้อความเครือข่าย คอนเทนเนอร์ข้อมูลของ light client และ Beacon API endpoints หลายรายการออกไป และระบุว่า light clients ที่ซิงก์ผ่าน LightClientUpdate ตามการไหลงานมาตรฐานของ Altair จะหยุดทำงานเมื่อเกิดฟอร์ก ตัวอย่างโครงการที่เข้าข่ายได้รับผลกระทบ ได้แก่ Helios ที่ฝังในกระเป๋าเงินและ dApps ได้และอาศัย consensus endpoint ที่รองรับ Beacon API สำหรับ light client, Lodestar ที่มีแพ็กเกจ light client ฝั่งผู้ใช้งานบนเส้นทางเดียวกัน, Nimbus ที่เปิดให้ใช้อินเทอร์เฟซ light client กับอ็อบเจ็กต์อัปเดตชุดเดียวกัน และ Ethereum IBC client ของ Datachain ที่ประกอบเฮดเดอร์จากข้อมูล LightClientUpdate และ FinalityUpdate ผ่าน Beacon RPC ทั้งนี้ ผลกระทบจริงขึ้นกับว่าแต่ละโปรเจกต์ยังใช้ส่วนติดต่อที่ถูกตัดออกหรือไม่ และผู้ดูแลจะปล่อยมิเกรชันอย่างไร แม้จะยกเลิกเส้นทางอัปเดตของ Altair แต่เอกสารไม่ได้ให้สัญญา Beacon API ทดแทน หรือสเปกมิเกรชันสำหรับไคลเอนต์อย่างชัดเจน ข้ออ้างด้านประสิทธิภาพยังไร้หลักฐานที่ทำซ้ำได้ ร่าง EIP-8390 ระบุว่าสามารถสร้างหลักฐาน Casper FFG finality ได้ภายใน 1 epoch ด้วย GPU หนึ่งตัว และให้ไคลเอนต์ตรวจสอบได้ในระดับมิลลิวินาที แต่ไม่มีการอ้างอิงถึงอิมพลีเมนเทชันที่ทำซ้ำได้ วงจร (circuit) โปรไฟล์ฮาร์ดแวร์ หรือเบนช์มาร์กเพื่อรองรับข้อกล่าวอ้างดังกล่าว เอกสารยังชี้ว่า มีงานออกแบบ full-set สาธารณะบางชิ้นรายงานการพรีโปรเซสต่ำกว่าหนึ่งนาทีบน CPU 64 คอร์โดยไม่ใช้ GPU และระบุว่าบางส่วนของการประกอบหลักฐานสุดท้ายยังเป็นงานในอนาคตหรือยังไม่ถูกสร้างขึ้น ซึ่งเป็นความคืบหน้าภายใต้สภาพแวดล้อมฮาร์ดแวร์ที่ต่างกัน ที่สำคัญ ร่าง EIP ไม่ได้กำหนดรายละเอียดของบริการผลิตหลักฐาน (proving service) อินเทอร์เฟซฝั่งไคลเอนต์ โมเดลความน่าเชื่อถือ ผู้ดำเนินการ หรือแหล่งทุน และยังระบุชัดว่าไม่ได้เพิ่มแรงจูงใจภายในโปรโตคอลเพื่อให้มีการผลิตหลักฐาน finality แม้ภายนอกโปรโตคอลอาจเกิดการสนับสนุนแบบ off-chain หรือ public goods ได้ โดยสรุป ข้อเสนอให้ผลประหยัดด้าน issuance ชัดเจนตามตัวเลขในเอกสาร แต่ความพร้อมใช้งานของระบบทดแทน เส้นทางมิเกรชัน และเศรษฐศาสตร์ของการผลิตหลักฐานยังเป็นคำถาม หากจะผลักดัน EIP-8390 ไปสู่การใช้งานจริงจำเป็นต้องมีอินเทอร์เฟซ light client ที่ผ่านการทดสอบ มิเกรชันที่ใช้งานได้สำหรับผู้ใช้ Altair ในปัจจุบัน และการผลิตหลักฐานสาธารณะที่พร้อมให้บริการอย่างต่อเนื่องเมื่อผู้ใช้ต้องพึ่งพา