ข่าว 
ข้อมูลเหรียญ 
แนะนำสื่อ 
นักพัฒนา อีเธอเรียม(ETH) เสนอแนวทางตรวจสอบและรวมลายเซ็นพร้อมหลักฐานเข้ารหัสไว้ที่ mempool แล้วใส่ recursive STARK เพียงชุดเดียวลงในบล็อก ร่าง EIP-8288 มุ่งลดภาระจากการบรรจุข้อมูลเข้ารหัสขนาดใหญ่ที่ตรวจสอบยาก เช่น ลายเซ็นต้านควอนตัม ลงบล็อกซ้ำ ๆ
EIP-8288 (In-mempool signature and proof aggregation) เขียนโดย วิทาลิก บูเทริน(Vitalik Buterin) และ โธมัส โคราตเกอร์ เมื่อวันที่ 3 มิถุนายน ขณะนี้อยู่ในสถานะ ‘ร่าง (Draft)’ ข้อเสนอระบุว่าลายเซ็นแบบแฮชที่อยู่ระหว่างพิจารณามีขนาดราว 2-3KB และการตรวจสอบโดยตรงอาจใช้แก๊ส 150,000-200,000 หน่วย ตัวเลขนี้เป็นค่าประมาณตามตัวอย่างในข้อเสนอ ไม่ใช่ค่ายืนยันของทุกรูปแบบลายเซ็นหรือการใช้งานจริง
mempool คือพื้นที่พักธุรกรรมก่อนถูกบรรจุลงบล็อก ในดีไซน์นี้ ธุรกรรมจะประกาศ ‘ข้อกำหนดการตรวจสอบ’ แทนการแนบลายเซ็นหรือหลักฐานต้นฉบับ โหนดจะตรวจสอบข้อกำหนดเหล่านี้ก่อนส่งต่อธุรกรรม จากนั้นโหนด mempool และผู้สร้างบล็อกจะรวมหลักฐานหลายชุดเข้าด้วยกัน ส่วนบล็อกจะมี recursive STARK หนึ่งชุดเพื่อยืนยันว่าข้อกำหนดทั้งหมดของธุรกรรมที่ถูกบรรจุนั้นถูกต้อง
STARK คือหลักฐานเข้ารหัสที่ยืนยันว่าการคำนวณทำถูกต้อง ส่วนแบบ recursive จะรวมการยืนยันความถูกต้องของหลักฐานอื่นไว้ในหลักฐานเดียว ข้อมูลจึงไม่ได้หายไปจากเครือข่าย เพียงแต่จุดที่ตรวจสอบและรวมข้อมูลเปลี่ยนไป
แนวทางนี้ยังหวังลดภาระการเพิ่มฟังก์ชันตรวจสอบแยกทุกครั้งที่มีรูปแบบลายเซ็นใหม่ ร่างดังกล่าวออกแบบบนพื้นฐานธุรกรรมแบบเฟรมของ EIP-8141 เพื่อให้ลายเซ็นและหลักฐาน STARK ผ่านเส้นทางเดียวกัน ธุรกรรมแบบเฟรมคือโครงสร้างที่ให้บัญชีเลือกตรรกะการตรวจสอบและรูปแบบลายเซ็นของตัวเองได้ นอกจากนี้ ร่างยังเสนอแนวทางที่เข้ากันได้กับรายการบรรจุ FOCIL โดยแนบ recursive STARK เพิ่มเติม
ที่มาของข้อเสนอคือเรื่องต้นทุน ลายเซ็นต้านควอนตัมและหลักฐานด้านความเป็นส่วนตัวอาจมีขนาดข้อมูลและต้นทุนการตรวจสอบสูงกว่าวิธีเดิม ข้อเสนอจึงเลือกทางสายกลาง คือห่อลายเซ็นและหลักฐานด้วย STARK แล้วรวมที่ขั้น mempool แทนการเพิ่มฟังก์ชันแยกสำหรับแต่ละวิธีเข้ารหัสใหม่
อย่างไรก็ตาม ภาระไม่ได้หายไปทั้งหมด งานตรวจสอบและรวมหลักฐานที่ mempool อาจเพิ่มขึ้น และร่างเองก็ระบุว่า mempool อาจเสี่ยงต่อการโจมตีแบบปฏิเสธการให้บริการมากขึ้น ร่างจึงเสนอให้จำกัดจำนวนข้อกำหนดลายเซ็นและ STARK ต่อธุรกรรม นอกจากนี้ หลักฐาน STARK เองอาจใหญ่เกิน 128KB หรือสูงถึงราว 512KB หากปรับให้สร้างได้เร็ว ทั้งหมดเป็นตัวเลขตามดีไซน์ในข้อเสนอ
ประเด็นที่ยังถกเถียงกันอยู่คือจะใช้ชุดคำสั่งใดสำหรับโปรแกรมที่ต้องพิสูจน์ โพสต์ของนักพัฒนาบน Ethereum Research เมื่อวันที่ 8 ตุลาคม เปรียบเทียบ EVM, RISC-V และชุดคำสั่งเฉพาะของอีเธอเรียม โพสต์ระบุว่า RISC-V อาจเป็นตัวเลือกได้ในแง่เครื่องมือพิสูจน์และประสิทธิภาพ แต่ต้องดูแลกฎและเวอร์ชันของชุดคำสั่งในระยะยาว ซึ่งยังเป็นเพียงการถกเถียงทางเทคนิคในขั้นเปรียบเทียบตัวเลือก
ก่อนหน้านี้ TokenPost รายงานแนวคิด EIP-8288 ของบูเทรินที่มุ่งรวมการตรวจสอบลายเซ็นหลายรายการด้วยหลักฐาน STARK การถกเถียงรอบนี้ชี้ประเด็นที่เจาะจงขึ้น คือชุดคำสั่งที่จะใช้เป็นเกณฑ์พิสูจน์ และความเข้ากันได้ระยะยาว บูเทรินเขียนเมื่อวันที่ 27 กันยายนว่า recursive STARK และการรวมลายเซ็นอยู่ในภาพระยะยาวของอีเธอเรียม แต่ยังไม่ใช่กำหนดการอัปเกรดหรือรายการฟีเจอร์ที่ยืนยันแล้ว
EIP-8288 ยังอยู่ในขั้นร่าง และยังไม่มีการยืนยันว่าจะถูกนำไปใช้หรือไม่ รวมถึงกำหนดเวลาฮาร์ดฟอร์ก
ความคิดเห็น 0