เส้นทางสู่ความสามารถในการยืนยัน

ความได้เปรียบหลักของ Web3 คือความสามารถในการตรวจสอบได้ - ผู้ใช้สามารถตรวจสอบว่าระบบทำงานอย่างไรจริง ๆ คุณสมบัตินี้อธิบายเหตุผลที่มีผู้ให้บริการและผู้ที่ไม่ได้อยู่ในอุตสาหกรรมคริปโตให้คำอธิบาย web3 เป็นการเคลื่อนไหวสู่อินเทอร์เน็ตที่โปร่งใสและสามารถตรวจสอบได้มากขึ้น

ไม่เหมือนแพลตฟอร์ม Web2 เช่น Facebook หรือ Instagram ที่อัลกอริทึมและกฎเกณฑ์ยังคงเป็นสิ่งที่ไม่โปร่งใส แม้ว่าจะมีเอกสารเผยแพร่ก็ตาม คุณยังขาดความสามารถในการตรวจสอบว่าแพลตฟอร์มทำงานตามที่กำหนดหรือไม่ นี่คือความตรงข้ามของการใช้เทคโนโลยีคริปโต ที่ทุกโปรโตคอลถูกออกแบบให้สามารถตรวจสอบได้ทั้งหมด หรืออย่างน้อยก็คาดหวังได้

วันนี้เราจะสํารวจ “The Verge” ซึ่งเป็นส่วนจาก Vitalik ที่เผยแพร่เมื่อเร็ว ๆ นี้ ซีรีส์ 6 ตอนเรื่องอนาคตของ Ethereumเพื่อวิเคราะห์ขั้นตอนที่ Ethereum กำลังดำเนินการเพื่อให้ได้มาซึ่งความสามารถในการตรวจสอบได้ ยังเป็นอย่างไรต่อไป ภายใต้หัวข้อ “เวิร์ก” เราจะพูดถึงวิธีที่สถาปัตยกรรมบล็อกเชนสามารถทำให้การตรวจสอบได้มากขึ้น นวัตกรรมเหล่านี้นำเอาการเปลี่ยนแปลงที่มาพร้อมกับระดับโปรโตคอลมา และวิธีที่พวกเขาให้ผู้ใช้ได้ระบบนิเวศที่ปลอดภัยมากขึ้น มาเริ่มกันเถอะ!

“verifiability” หมายความว่าอะไร?

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

“กระจายอำนาจให้เท่าที่จะเป็นไปได้ ตรวจสอบสิ่งที่เหลืออยู่”

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

ชุมชน Ethereum ดูเหมือนจะสอดคล้องกับมุมนี้ เนื่องจากแผนทางรวมถึงขั้นตอนสำคัญ (ที่เรียกว่า “The Verge”) ที่มุ่งเน้นทำให้ Ethereum มีความเชื่อถือมากขึ้น อย่างไรก็ตามก่อนที่จะลงไปใน The Verge เราต้องเข้าใจว่าด้านใดของบล็อกเชนควรที่จะถูกยืนยันและส่วนใดเป็นสิ่งสำคัญจากมุมมองของผู้ใช้

บล็อกเชนทำงานเป็นนาฬิกาทั่วโลกโดยจำลอง ในเครือข่ายที่กระจายอยู่ด้วยประมาณ 10,000 เครื่องคอมพิวเตอร์ อาจใช้เวลานานสำหรับธุรกรรมที่จะกระจายไปยังโหนดที่เกิดขึ้นและโหนดอื่น ๆ ทั้งหมด ดังนั้น โหนดทั่วเครือข่ายไม่สามารถกำหนดลำดับที่แน่นอนของการทำธุรกรรมได้ - ว่าธุรกรรมหนึ่งมาก่อนหรือหลังอีกธุรกรรมหนึ่ง - เนื่องจากพวกเขามีมุมมองอย่างไร้เสียงเฉพาะของตัวเองเท่านั้น

เนื่องจากลำดับของธุรกรรมมีความสำคัญ ระบบบล็อกเชนใช้วิธีการพิเศษที่เรียกว่า “ขั้นตอนของการตกลง“ เพื่อให้แน่ใจว่าโหนดยังคงซิงโครไนซ์และประมวลผลลําดับธุรกรรมในลําดับเดียวกัน แม้ว่าโหนดจะไม่สามารถกําหนดลําดับธุรกรรมได้ทั่วโลก แต่กลไกฉันทามติช่วยให้โหนดทั้งหมดสามารถตกลงในลําดับเดียวกันทําให้เครือข่ายสามารถทํางานเป็นคอมพิวเตอร์เครื่องเดียวที่เหนียวแน่น

นอกจากชั้นความเห็นร่วมกันแล้วยังมีชั้นการดำเนินการอีกหนึ่งชั้นที่มีอยู่ในทุกๆบล็อกเชน ชั้นการดำเนินการนี้จะถูกเป็นรูปแบบโดยธุรกรรมที่ผู้ใช้ต้องการดำเนินการ

หลังจากที่ธุรกรรมถูกสั่งลำดับโดยความเห็นร่วมกันแล้ว ทุก ๆ ธุรกรรมต้องถูกนำไปใช้กับสถานะปัจจุบันที่เลเยอร์การดำเนินการ หากคุณกำลังสงสัยว่า “สถานะคืออะไร” คุณอาจเคยเห็นบล็อกเชนถูกเปรียบเทียบกับฐานข้อมูล - หรือในทางเฉพาะกับฐานข้อมูลของธนาคาร โดยเช่นเดียวกับธนาคาร เบล็อกเชนรักษาบันทึกยอดคงเหลือของทุก ๆ คน

หากคุณมี $100 ในสถานะที่เราเรียกว่า “S” และต้องการส่ง $10 ให้คนอื่น ๆ จะได้ว่ายอดคงเหลือของคุณในสถานะถัดไป “S+1” คือ $90 กระบวนการนี้ของการปรับใช้ธุรกรรมเพื่อย้ายจากสถานะหนึ่งไปสู่อีกสถานะหนึ่งคือสิ่งที่เราเรียก STF (ฟังก์ชันการเปลี่ยนสถานะ)

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

ในบล็อกเชนนั้น มีสามส่วนประกอบพื้นฐานที่คุณต้องการหรือสามารถยืนยันได้:

1. สถานะ: คุณอาจต้องการอ่านข้อมูลบางส่วนบนบล็อกเชน แต่ขาดสิทธิ์ในการเข้าถึงสถานะเนื่องจากคุณไม่ได้เป็นผู้ดำเนินการโหนดเต็มดังนั้นคุณจะขอข้อมูลผ่านผู้ให้บริการ RPC (Remote Procedure Call) เช่น Alchemy หรือ Infura อย่างไรก็ตามคุณต้องตรวจสอบว่าข้อมูลไม่ได้ถูกแก้ไขโดยผู้ให้บริการ RPC
2. การดำเนินการ: ตามที่กล่าวไว้แล้ว บล็อกเชนใช้ STF คุณต้องตรวจสอบว่าการเปลี่ยนสถานะถูกดำเนินการถูกต้อง - ไม่ในรายการธุรกรรมต่อรายการ แต่ในรายการบล็อกต่อรายการ
3. ตรวจสอบ: หน่วยงานภายนอกที่ไม่ใช่ผู้รับรอง อย่างเช่น RPCs สามารถให้บล็อกที่ถูกต้องที่ยังไม่ได้รับการรวมเข้าสู่บล็อกเชนได้ ดังนั้นคุณต้องตรวจสอบว่าบล็อกเหล่านี้ได้รับการยอมรับผ่านทางความเห็นร่วมกันแล้วและถูกเพิ่มในบล็อกเชน

หากดูเหมือนจะสับสนหรือไม่ชัดเจน ไม่ต้องกังวล เราจะอธิบายแต่ละภาคส่วนโดยละเอียด ให้เริ่มต้นด้วยวิธีการยืนยันสถานะบล็อกเชน!

วิธีการยืนยันสถานะบล็อกเชน

“สถานะ” ของ Ethereum หมายถึงชุดข้อมูลที่เก็บไว้ในบล็อกเชนในขณะใดก็ได้ ซึ่งรวมถึงยอดคงเหลือของบัญชี (บัญชีสัญญาและบัญชีที่เป็นเจ้าของนอกสถานที่หรือ EOA) รหัสสัญญาฉบับอัจฉริยะ, การจัดเก็บสัญญาฉบับอัจฉริยะ และอื่น ๆ Ethereum เป็นเครื่องจักรที่ขึ้นอยู่กับสถานะเนื่องจากธุรกรรมที่ดำเนินการใน Ethereum Virtual Machine (EVM) จะเปลี่ยนแปลงสถานะก่อนหน้าและสร้างสถานะใหม่

แต่ละบล็อก Ethereum ประกอบด้วยค่าที่สรุปสถานะปัจจุบันของเครือข่ายหลังจากบล็อกนั้น: stateRoot ค่านี้เป็นการแทนที่แบบย่อของสถานะ Ethereum ทั้งหมด ประกอบด้วยแฮช 64 ตัวอักษร

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

ฟังก์ชันแฮชเป็นฟังก์ชันแบบหนึ่งทิศทางที่แปลงข้อมูลนำเข้าเป็นผลลัพธ์ที่มีความยาวคงที่ ใน Ethereum ฟังก์ชันแฮชเช่น Keccakใช้สร้างสรุปข้อมูล เป็นเหมือนนิ้วมือสำหรับข้อมูลนำเข้า Hash functions มีคุณสมบัติพื้นฐานทั้งหมด 4 ประการ

1. Determinism: ข้อมูลนำเข้าที่เหมือนกันจะสร้างผลลัพธ์ที่เหมือนกันเสมอ
2. ความยาวของผลลัพธ์ที่แน่นอน: ไม่ว่าความยาวของข้อมูลนำเข้าจะเป็นอย่างไร ความยาวของผลลัพธ์จะมีค่าคงที่เสมอ
3. คุณสมบัติในทิศทางเดียว: มันเป็นเรื่องเกือบจะเป็นไปไม่ได้ในการคำนวณค่านำเข้าต้นฉบับจากผลลัพธ์
4. ความเป็นเอกลักษณ์: แม้จะมีการเปลี่ยนแปลงขนาดเล็กในข้อมูลนำ ก็จะทำให้มีผลลัพธ์ที่แตกต่างอย่างสิ้นเชิง ดังนั้น ข้อมูลนำที่เฉพาะเจาะจงจะสร้างผลลัพธ์ที่เป็นไปได้เพียงครั้งเดียว

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

อย่างไรก็ตาม ผู้ตรวจสอบ Ethereum ไม่ได้ทำการแฮชสถานะทั้งหมดโดยตรงเพื่อหาสรุป ด้วยเหตุผลที่ฟังก์ชันแฮชมีลักษณะเป็นไปทางเดียว การแฮชสถานะโดยตรงจะทำให้ไม่สามารถทำให้เชื่อถือได้ เนื่องจากวิธีเดียวเพื่อที่จะสร้างแฮชจะต้องมีสถานะทั้งหมด

เนื่องจากสถานะของ Ethereum มีขนาดหลายเทราไบต์ การเก็บสถานะทั้งหมดบนอุปกรณ์ทุกวัน เช่น โทรศัพท์หรือคอมพิวเตอร์ส่วนตัว เป็นสิ่งที่ไม่น่าจะทำได้ ดังนั้น Ethereum ใช้โครงสร้างต้นไม้ Merkle เพื่อคำนวณ stateRoot ซึ่งสามารถยืนยันสถานะได้เท่าที่เป็นไปได้

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

1. โหนดใบ: โหนดเหล่านี้มีแฮชของชิ้นส่วนข้อมูลแต่ละชิ้นและอยู่ที่ระดับล่างของต้นไม้ แต่ละโหนดใบแสดงถึงแฮชของข้อมูลเฉพาะในต้นไม้เมอร์เคิล
2. โหนดสาขา: โหนดเหล่านี้ประกอบไปด้วยแฮชรวมของโหนดลูกของตน ตัวอย่างเช่นในต้นไม้ Merkle ทวิภาค (โดยที่ N=2) แฮชของโหนดลูกสองโหนดถูกต่อตั้งใหม่และถูกแฮชอีกครั้งเพื่อสร้างแฮชของโหนดสาขาที่ระดับสูงกว่า
3. โหนดราก: โหนดรากอยู่ที่ระดับสูงสุดของต้นไม้ Merkle และแทนสรุปโครงสร้างข้อมูลทั้งหมดในรูปแบบของการเข้ารหัส. โหนดนี้ใช้ในการตรวจสอบความถูกต้องและความถูกต้องของข้อมูลทั้งหมดภายในต้นไม้.

หากคุณกำลังสงสัยว่าจะสร้างต้นไม้แบบนี้อย่างไร มันเพียงเกี่ยวข้องกับขั้นตอนง่าย ๆ เพียงสองขั้นตอนเท่านั้น:

• การสร้างโหนดใบ: ข้อมูลแต่ละชิ้นถูกประมวลผ่านฟังก์ชันแฮช และแฮชที่ผลิตขึ้นเป็นโหนดใบ โหนดเหล่านี้ตั้งอยู่ในระดับต่ำสุดของต้นไม้ และแทนสรุปทางคริปโตของข้อมูล

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

แฮชสุดท้ายที่ได้รับที่ด้านบนของต้นไม้เรียกว่าราก Merkle ราก Merkle แสดงสรุปข้อมูลทางคริปโตของต้นไม้ทั้งหมดและช่วยให้สามารถยืนยันความถูกต้องของข้อมูลได้อย่างปลอดภัย

เราจะใช้ราก Merkle อย่างไรในการตรวจสอบสถานะของ Ethereum?

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

เริ่มต้นจากจุดข้อมูลที่เฉพาะเจาะจง ผู้ตรวจสอบรวมมันกับแต่ละค่ายอดพี่ที่ให้มาใน Merkle Proof และแฮชพวกเขาขั้นตอนต่อไปขึ้นไปยังต้นไม้ กระบวนการนี้ยังคงดำเนินไปจนกระทั้งแฮชเดี่ยวถูกสร้างขึ้น หากแฮชที่คำนวณนี้ตรงกับ Merkle Root ที่เก็บไว้ ข้อมูลถือเป็นถูกต้อง มิฉะนั้น ผู้ตรวจสอบสามารถกำหนดว่าข้อมูลไม่สอดคล้องกับสถานะที่อ้างถึง

ตัวอย่าง: การยืนยันจุดข้อมูลด้วย Merkle proof

เราจะสมมติว่าเราได้รับข้อมูล #4 จาก RPC และต้องการยืนยันความถูกต้องของข้อมูลโดยใช้ Merkle Proof ในการทำเช่นนี้ RPC จะให้ชุดของค่าแฮชที่จำเป็นในการเดินทางไปยัง Merkle Root สำหรับข้อมูลที่ 4 ค่าแฮชพี่น้องเหล่านี้จะรวมถึงค่าแฮช #3, ค่าแฮช #12 และค่าแฮช #5678

1. เริ่มต้นด้วยข้อมูลที่ 4: ก่อนอื่นเราแฮชข้อมูล # 4 เพื่อรับแฮช # 4
2. รวมกับพี่น้อง: จากนั้นเราจะรวม Hash #4 กับ Hash #3 (พี่น้องของมันที่ระดับใบไม้) และนำมาแฮชร่วมกันเพื่อสร้าง Hash #34
3. เลื่อนขึ้นต้นไม้: ถัดไปเราจะเอาแฮช #34 และรวมกับแฮช #12 (พี่น้องในระดับถัดไป) และแฮชพวกเขาเพื่อให้ได้แฮช #1234
4. ขั้นตอนสุดท้าย: ในที่สุดเรารวม Hash #1234 กับ Hash #5678 (พี่น้องคนสุดท้ายที่ให้ไว้) และแฮชเข้าด้วยกัน แฮชที่ได้ควรตรงกับ Merkle Root (Hash #12345678) ที่เก็บไว้ในส่วนหัวของบล็อก

หาก Merkle Root ที่คํานวณได้ตรงกับรูทสถานะในบล็อก เราจะยืนยันว่าข้อมูล #4 ถูกต้องภายในสถานะนี้จริงๆ หากไม่เป็นเช่นนั้นเรารู้ว่าข้อมูลนั้นไม่ได้อยู่ในสถานะที่อ้างสิทธิ์ซึ่งบ่งชี้ว่าอาจมีการปลอมแปลง อย่างที่คุณเห็นโดยไม่ต้องให้แฮชของข้อมูลทั้งหมดหรือกําหนดให้ผู้ตรวจสอบสร้าง Merkle Tree ใหม่ทั้งหมดตั้งแต่เริ่มต้น Prover สามารถพิสูจน์ได้ว่าข้อมูล # 4 มีอยู่ในสถานะและไม่ได้ถูกเปลี่ยนแปลงในระหว่างการเดินทางโดยใช้แฮชเพียงสามรายการ นี่คือเหตุผลหลักว่าทําไม Merkle Proofs จึงถือว่ามีประสิทธิภาพ

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

ปัจจัยสองปัจจัยที่มีผลต่อประสิทธิภาพของ Merkle Tree: ⌛

1. ปัจจัยกิ่งก้าน: จำนวนของโหนดลูกที่ต่อกัน
2. ขนาดข้อมูลทั้งหมด: ขนาดของชุดข้อมูลที่ถูกแทนด้วยต้นไม้

ผลของปัจจัยการแยกกิ่ง:

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

• ปัจจัยการแตกแขนงขนาดเล็ก (เช่น Binary Merkle Tree):
  หากใช้ต้นไม้ Merkle แบบไบนารี (branching factor ของ 2) ขนาดพิสูจน์จะเล็กมาก ทำให้กระบวนการตรวจสอบมีประสิทธิภาพมากขึ้นสำหรับผู้ตรวจสอบ ด้วยสองสาขาในแต่ละโหนดเท่านั้นผู้ตรวจสอบเพียงต้องประมวลผลแฮชพี่น้องเพียงหนึ่งต่อระดับ ส่วนนี้ช่วยเพิ่มความเร็วในการตรวจสอบและลดโหลดคำนวณ อย่างไรก็ตาม การลดจำนวนสาขาเพิ่มความสูงของต้นไม้ จำเป็นต้องมีการแฮชมากขึ้นในขณะที่กำลังสร้างต้นไม้ ซึ่งอาจเป็นภาระหนักสำหรับผู้ตรวจสอบ
• ขั้นตอนตัดสินใจที่มีปัจจัยเป็นอันดับสูง (เช่น 4):
  ปัจจัยการแบ่งสาขาที่ใหญ่ขึ้น (เช่น 4) จะลดความสูงของต้นไม้ลง ซึ่งสร้างโครงสร้างที่สั้นและกว้างขึ้น สำหรับ Full Nodes นี้ช่วยให้สร้างต้นไม้ได้เร็วขึ้นเนื่องจากการดำเนินการแฮชน้อยลง อย่างไรก็ตามสำหรับ Verifier นี้เพิ่มจำนวนของการแฮชพี่น้องที่พวกเขาต้องดำเนินการในแต่ละระดับ ซึ่งทำให้ขนาดพรูฟใหญ่ขึ้น การมีจำนวนแฮชมากขึ้นต่อขั้นตอนการตรวจสอบหมายความว่าต้นทุนทางคอมพิวเตอร์และแบนด์วิดท์สูงขึ้นสำหรับ Verifier ทำให้มีการเปลี่ยนแปลงการรับผิดชอบจากผู้ตรวจสอบไปสู่ผู้ตรวจสอบ

ผลของขนาดข้อมูลรวม:

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

• Full Nodes ต้องประมวลผลและอัปเดตชุดข้อมูลที่เพิ่มขึ้นอย่างต่อเนื่องเพื่อรักษา Merkle Tree
• ตรวจสอบการยืนยันต้องตรวจสอบพิสูจน์ที่ยาวและซับซ้อนมากขึ้นเมื่อชุดข้อมูลเติบโต ต้องใช้เวลาประมวลผลและแบนด์วิดท์เพิ่มเติม
  ขนาดข้อมูลที่เพิ่มขึ้นนี้เพิ่มความต้องการใช้งานใน Full Nodes และ Verifiers โดยทำให้เกิดปัญหาในการขยายขนาดเครือข่ายอย่างมีประสิทธิภาพ

สรุปมาดูกันว่า ถึงแม้ Merkle Trees จะมีประสิทธิภาพในบางระดับ แต่ก็ยังไม่สามารถเป็นตัวเลือกที่เหมาะสมสำหรับชุดข้อมูลที่เพิ่มขึ้นของ Ethereum อย่างต่อเนื่องได้ ด้วยเหตุนี้ ในช่วง The Verge Ethereum มีเป้าหมายที่จะดำเนินการแทนที่ Merkle Trees ด้วยโครงสร้างที่มีประสิทธิภาพมากขึ้นที่รู้จักกันดีว่า Verkle Trees. ต้นไม้ Verkle สามารถส่งมอบขนาดพิสูจน์ที่เล็กกว่าในขณะที่คงความปลอดภัยระดับเดียวกันได้ ทำให้กระบวนการยืนยันเป็นเรื่องที่ยั่งยืนและสามารถขยายขนาดได้สำหรับ Provers และ Verifiers

บทที่ 2: การเปลี่ยนแปลงการตรวจสอบใน Ethereum - The Verge

The Verge ได้รับการพัฒนาเป็นก้าวสําคัญในแผนงานของ Ethereum ที่มุ่งปรับปรุงความสามารถในการตรวจสอบ เสริมสร้างโครงสร้างการกระจายอํานาจของบล็อกเชน และเพิ่มความปลอดภัยของเครือข่าย หนึ่งในเป้าหมายหลักของเครือข่าย Ethereum คือการช่วยให้ทุกคนสามารถเรียกใช้ผู้ตรวจสอบความถูกต้องเพื่อตรวจสอบห่วงโซ่ได้อย่างง่ายดายสร้างโครงสร้างที่การมีส่วนร่วมเปิดให้ทุกคนโดยไม่ต้องรวมศูนย์ การเข้าถึงกระบวนการตรวจสอบนี้เป็นหนึ่งในคุณสมบัติหลักที่แยกบล็อกเชนออกจากระบบรวมศูนย์ แม้ว่าระบบแบบรวมศูนย์จะไม่มีความสามารถในการตรวจสอบ แต่ความถูกต้องของบล็อกเชนนั้นอยู่ในมือของผู้ใช้ทั้งหมด อย่างไรก็ตามเพื่อรักษาการรับประกันนี้การเรียกใช้ผู้ตรวจสอบความถูกต้องจะต้องสามารถเข้าถึงได้สําหรับทุกคนซึ่งเป็นความท้าทายที่ภายใต้ระบบปัจจุบันมีข้อ จํากัด เนื่องจากข้อกําหนดด้านการจัดเก็บและการคํานวณ

ตั้งแต่การเปลี่ยนโมเดลการตกลงความเห็น Proof-of-Stake ด้วยการรวมกันกับ Ethereum ผู้ตรวจสอบได้มีหน้าที่หลักอยู่สองประการ:

1. การรับรองความเห็น: การสนับสนุนการทำงานที่ถูกต้องของโปรโตคอลที่มีความน่าจะเป็นและแน่นอน และการปรับใช้อัลกอริทึมการเลือก fork-choice
2. การตรวจสอบความถูกต้องของบล็อก: หลังจากดำเนินการธุรกรรมในบล็อกแล้วตรวจสอบว่ารากของต้นไม้สถานะที่ได้ตรงกับรากสถานะที่ประกาศโดยผู้เสนอ

ในการปฏิบัติตามความรับผิดชอบที่สองผู้ตรวจสอบจะต้องมีสิทธิ์เข้าถึงสถานะก่อนการบล็อก สิ่งนี้ช่วยให้พวกเขาดําเนินธุรกรรมของบล็อกและได้รับสถานะที่ตามมา อย่างไรก็ตามข้อกําหนดนี้สร้างภาระหนักให้กับผู้ตรวจสอบความถูกต้องเนื่องจากจําเป็นต้องจัดการกับข้อกําหนดในการจัดเก็บที่สําคัญ ในขณะที่ Ethereum ได้รับการออกแบบมาให้เป็นไปได้และต้นทุนการจัดเก็บลดลงทั่วโลก แต่ปัญหาก็น้อยลงเกี่ยวกับค่าใช้จ่ายและการพึ่งพาฮาร์ดแวร์พิเศษสําหรับผู้ตรวจสอบความถูกต้อง The Verge มีจุดมุ่งหมายเพื่อเอาชนะความท้าทายนี้โดยการสร้างโครงสร้างพื้นฐานที่สามารถทําการตรวจสอบเต็มรูปแบบได้แม้ในอุปกรณ์ที่มีพื้นที่เก็บข้อมูล จํากัด เช่นโทรศัพท์มือถือกระเป๋าเงินเบราว์เซอร์และแม้แต่สมาร์ทวอทช์ทําให้ผู้ตรวจสอบสามารถทํางานบนอุปกรณ์เหล่านี้ได้

ขั้นตอนแรกของการตรวจสอบ: สถานะ

การเปลี่ยนไปใช้ Verkle Trees เป็นส่วนสำคัญของกระบวนการนี้ แรกเรามุ่งเน้นที่จะแทนที่โครงสร้าง Merkle Tree ของ Ethereum ด้วย Verkle Trees สาเหตุหลักในการนำ Verkle Trees มาใช้ก็เพราะ Merkle Trees ทำให้ Ethereum ยากต่อการตรวจสอบอย่างมาก ในขณะที่ Merkle Trees และ proof ของพวกมันสามารถทำงานได้อย่างมีประสิทธิภาพในสถานการณ์ปกติ แต่ประสิทธิภาพของพวกมันจะลดลงอย่างมากในสถานการณ์เลวร้าย

ตามการคำนวณของ Vitalik ขนาดพิสูจน์เฉลี่ยอยู่ที่ประมาณ 4 KB ซึ่งดูเหมาะสม อย่างไรก็ตาม ในกรณีที่เลวร้ายที่สุดขนาดพิสูจ์สามารถขยายเป็น 330 MB ใช่ คุณอ่านถูกต้องนั่นเอง 330 MB

ความไร้ประสิทธิภาพอย่างมากของ Merkle Trees ของ Ethereum ในสถานการณ์ที่เลวร้ายที่สุดเกิดจากเหตุผลหลักสองประการ:

1. การใช้ต้นไม้ฮีกซารี่: ในปัจจุบัน Ethereum ใช้ Merkle Trees ที่มีปัจจัยความสามารถของ 16 นั่นหมายความว่าการยืนยันโหนดเดียวต้องการการให้โฮช์ 15 โฮช์ที่เหลือในสาขา ด้วยขนาดของสถานะ Ethereum และจำนวนของสาขา นี้สร้างภาระหนักในกรณีที่แย่ที่สุด

1. ไม่มีการ Merkelization ของรหัส: แทนที่จะนำรหัสสัญญาไปรวมกับโครงสร้างต้นไม้ Ethereum จะใช้การแฮชรหัสแล้วนำค่าที่ได้มาเป็นโหนด ด้วยขนาดสูงสุดของสัญญาที่เป็นไปได้คือ 24 KB วิธีการนี้จะสร้างภาระที่สำคัญสำหรับการทำให้การตรวจสอบเต็มรูปแบบ

ขนาดการพิสูจน์เป็นสัดส่วนโดยตรงกับปัจจัยการแตกแขนง การลดปัจจัยการแตกแขนงจะลดขนาดการพิสูจน์ เพื่อแก้ไขปัญหาเหล่านี้และปรับปรุงสถานการณ์ที่เลวร้ายที่สุด Ethereum สามารถเปลี่ยนจาก Hexary Trees เป็น Binary Merkle Trees และเริ่ม merklizing รหัสสัญญา หากปัจจัยการแตกแขนงใน Ethereum ลดลงจาก 16 เป็น 2 และรหัสสัญญายังถูกรวมเข้าด้วยกันขนาดหลักฐานสูงสุดอาจลดลงเหลือ 10 MB แม้ว่านี่จะเป็นการปรับปรุงที่สําคัญ แต่สิ่งสําคัญคือต้องทราบว่าค่าใช้จ่ายนี้ใช้กับการตรวจสอบข้อมูลเพียงชิ้นเดียว แม้แต่ธุรกรรมง่ายๆ ที่เข้าถึงข้อมูลหลายชิ้นก็ต้องใช้หลักฐานที่ใหญ่กว่า เมื่อพิจารณาจากจํานวนธุรกรรมต่อบล็อกและสถานะการเติบโตอย่างต่อเนื่องของ Ethereum โซลูชันนี้แม้ว่าจะดีกว่า แต่ก็ยังไม่สามารถทําได้ทั้งหมด

ด้วยเหตุนี้ ชุมชน Ethereum ได้เสนอวิธีการแก้ไขปัญหาอย่างชัดเจนสองวิธี

1. Verkle Trees
2. STARK Proofs + ต้นไม้เมอร์เคิลแบบไบนารี

ต้นไม้ Verkle & การสัญญาณเวกเตอร์

Verkle Trees หรือ ต้นไม้เวอร์เคิลเป็นโครงสร้างต้นไม้ที่คล้ายกับ Merkle Trees อย่างไรก็ตาม ความแตกต่างสำคัญที่สุดอยู่ที่ประสิทธิภาพที่พวกเขานำเสนอในกระบวนการตรวจสอบ ใน Merkle Trees หากมีสาขานั้นมีข้อมูล 16 ชิ้นและเราต้องการยืนยันเพียงหนึ่งในนั้น ต้องมีการให้บริการซี่งเชื่อมโยงที่เกี่ยวข้องกับ 15 ชิ้นอื่น ๆ นี้ ทำให้เกิดความเป็นภาระทางคอมพิวเตอร์ของกระบวนการตรวจสอบและทำให้ไซส์ของพิสูจน์ใหญ่ขึ้น

ในทางกลับกัน ต้นไม้ Verkle ใช้โครงสร้างที่เฉพาะเจาะจงที่เรียกว่า “Elliptic Curve-based Vector Commitments” โดยเฉพาะอย่างยิ่งเป็นฐานของ Inner Product Argument (IPA)-based Vector Commitment โดยส่วนใหญ่เวกเตอร์คือรายการข้อมูลที่ออกแบบมาในลำดับเฉพาะ Ethereum’s สถานะสามารถถือเป็นเวกเตอร์: โครงสร้างที่เก็บข้อมูลหลายชิ้นที่เก็บอยู่ในลำดับที่เฉพาะเจาะจง โดยในแต่ละองค์ประกอบมีความสำคัญ สถานะนี้ประกอบด้วยส่วนประกอบของข้อมูลต่าง ๆ เช่น ที่อยู่ รหัสสัญญา และข้อมูลการเก็บรักษา โดยลำดับขององค์ประกอบเหล่านี้เป็นสิ่งสำคัญในการเข้าถึงและการตรวจสอบ

Vector Commitments เป็นวิธีการเข้ารหัสที่ใช้สําหรับการพิสูจน์และตรวจสอบองค์ประกอบข้อมูลภายในชุดข้อมูล วิธีการเหล่านี้ช่วยให้สามารถตรวจสอบทั้งการมีอยู่และลําดับของแต่ละองค์ประกอบในชุดข้อมูลพร้อมกัน ตัวอย่างเช่น Merkle Proofs ที่ใช้ใน Merkle Trees ถือได้ว่าเป็นรูปแบบหนึ่งของ Vector Commitments ในขณะที่ Merkle Trees ต้องการสายแฮชที่เกี่ยวข้องทั้งหมดเพื่อตรวจสอบองค์ประกอบ แต่โครงสร้างโดยเนื้อแท้พิสูจน์ว่าองค์ประกอบทั้งหมดของเวกเตอร์เชื่อมต่อกันในลําดับเฉพาะ

ไม่เหมือน Merkle Trees, Verkle Trees ใช้ elliptic curve-based vector commitments ที่มีความสามารถสองอย่าง

• ความมุ่งมั่นของเวกเตอร์ตามเส้นโค้งวงรีช่วยลดความจําเป็นในการดูรายละเอียดขององค์ประกอบอื่นนอกเหนือจากข้อมูลที่กําลังตรวจสอบ ใน Merkle Trees ที่มีปัจจัยการแตกแขนง 16 การตรวจสอบสาขาเดียวต้องให้แฮชอีก 15 แฮช ด้วยขนาดที่กว้างใหญ่ของสถานะของ Ethereum ซึ่งเกี่ยวข้องกับหลายสาขาสิ่งนี้ทําให้เกิดความไร้ประสิทธิภาพอย่างมาก อย่างไรก็ตามความมุ่งมั่นของเวกเตอร์ตามเส้นโค้งวงรีจะขจัดความซับซ้อนนี้ทําให้สามารถตรวจสอบได้โดยใช้ข้อมูลน้อยลงและความพยายามในการคํานวณ \
• หลักฐานที่สร้างขึ้นโดยความมุ่งมั่นของเวกเตอร์ที่ใช้เส้นโค้งวงรีสามารถบีบอัดเป็นหลักฐานขนาดคงที่เดียวได้ สถานะของ Ethereum ไม่เพียง แต่มีขนาดใหญ่แต่ยังเติบโตอย่างต่อเนื่องซึ่งหมายความว่าจํานวนสาขาที่ต้องการการตรวจสอบเพื่อเข้าถึง Merkle Root เพิ่มขึ้นเมื่อเวลาผ่านไป อย่างไรก็ตามด้วย Verkle Trees เราสามารถ “บีบอัด” หลักฐานสําหรับแต่ละสาขาให้เป็นหลักฐานขนาดคงที่เดียวโดยใช้วิธีการที่มีรายละเอียดใน บทความของ Dankrad Feist. นี้ช่วยให้ Verifiers สามารถตรวจสอบต้นไม้ทั้งหมดด้วยพิสูจน์ขนาดเล็กหนึ่งครั้งแทนที่จะตรวจสอบแต่ละสาขาแยกต่างหาก นี่ยังหมายถึงว่า Verkle Trees จะไม่ได้รับผลกระทบจากการเติบโตของสถานะของ Ethereum

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

เช่นเดียวกับนวัตกรรมทั้งหมด Verkle Trees มีข้อ จํากัด หนึ่งในข้อเสียเปรียบหลักของพวกเขาคือพวกเขาพึ่งพาการเข้ารหัสเส้นโค้งวงรีซึ่งมีความเสี่ยงต่อคอมพิวเตอร์ควอนตัม คอมพิวเตอร์ควอนตัมมีพลังการคํานวณมากกว่าวิธีการแบบคลาสสิกซึ่งเป็นภัยคุกคามที่สําคัญต่อโปรโตคอลการเข้ารหัสที่ใช้เส้นโค้งวงรี อัลกอริธึมควอนตัมอาจทําลายหรือทําให้ระบบการเข้ารหัสเหล่านี้อ่อนแอลงทําให้เกิดความกังวลเกี่ยวกับความปลอดภัยในระยะยาวของ Verkle Trees

ด้วยเหตุนี้ในขณะที่ Verkle Trees เสนอทางออกที่มีแนวโน้มว่าจะไร้สัญชาติ แต่ก็ไม่ใช่การแก้ไขขั้นสูงสุด อย่างไรก็ตามตัวเลขเช่น Dankrad Feist ได้เน้นว่าในขณะที่การพิจารณาอย่างรอบคอบเป็นสิ่งจําเป็นเมื่อรวมการเข้ารหัสที่ทนต่อควอนตัมเข้ากับ Ethereum เป็นที่น่าสังเกตว่าความมุ่งมั่นของ KZG ที่ใช้ในปัจจุบันสําหรับ blobs ใน Ethereum นั้นไม่ทนต่อควอนตัม ดังนั้น Verkle Trees สามารถใช้เป็นโซลูชันชั่วคราวทําให้เครือข่ายมีเวลาเพิ่มเติมในการพัฒนาทางเลือกที่แข็งแกร่งยิ่งขึ้น

STARK proofs + ต้นไม้ Merkle แบบไบนารี

Verkle Trees มีขนาดการพิสูจน์ที่เล็กกว่าและกระบวนการตรวจสอบที่มีประสิทธิภาพเมื่อเทียบกับ Merkle Trees ทําให้ง่ายต่อการจัดการสถานะที่เติบโตอย่างต่อเนื่องของ Ethereum ด้วย Elliptic Curve-Based Vector Commitments การพิสูจน์ขนาดใหญ่สามารถสร้างได้โดยใช้ข้อมูลน้อยลงอย่างมาก อย่างไรก็ตาม แม้จะมีข้อได้เปรียบที่น่าประทับใจ แต่ช่องโหว่ของ Verkle Trees ต่อคอมพิวเตอร์ควอนตัมทําให้เป็นเพียงวิธีแก้ปัญหาชั่วคราวเท่านั้น ในขณะที่ชุมชน Ethereum มองว่า Verkle Trees เป็นเครื่องมือระยะสั้นในการซื้อเวลา แต่การมุ่งเน้นในระยะยาวคือการเปลี่ยนไปใช้โซลูชันที่ทนต่อควอนตัม นี่คือจุดที่ STARK Proofs และ Binary Merkle Trees นําเสนอทางเลือกที่แข็งแกร่งสําหรับการสร้างโครงสร้างพื้นฐานการตรวจสอบที่แข็งแกร่งยิ่งขึ้นสําหรับอนาคต

ในกระบวนการตรวจสอบสถานะของ Ethereum ปัจจัยกิ่งก้าวของ Merkle Trees สามารถลดลง (จาก 16 เป็น 2) โดยใช้ Binary Merkle Trees การเปลี่ยนแปลงนี้เป็นขั้นสำคัญในการลดขนาดพิสูจน์และทำให้กระบวนการตรวจสอบมีประสิทธิภาพมากขึ้น อย่างไรก็ตาม แม้กระทั้งในกรณีที่เลวร้ายที่สุดขนาดพิสูจน์ยังคงสามารถถึง 10 MB ซึ่งมีน้ำหนักมาก นี่คือจุดที่ STARK Proofs เข้ามามีบทบาท โดยการบีบอัดพิสูจน์ Binary Merkle Proofs ขนาดใหญ่เหล่านี้เหลือเพียง 100-300 kB เท่านั้น

การเพิ่มประสิทธิภาพนี้มีความสําคัญอย่างยิ่งเมื่อพิจารณาข้อ จํากัด ของผู้ตรวจสอบการทํางานบนไคลเอนต์ขนาดเล็กหรืออุปกรณ์ที่มีฮาร์ดแวร์ จํากัด โดยเฉพาะอย่างยิ่งหากคุณคํานึงถึงความเร็วในการดาวน์โหลดและอัปโหลดมือถือทั่วโลกโดยเฉลี่ยอยู่ที่ประมาณ 7.625 MB / s และ 1.5 MB / s ตามลําดับ ผู้ใช้สามารถตรวจสอบธุรกรรมด้วยหลักฐานขนาดเล็กแบบพกพาโดยไม่จําเป็นต้องเข้าถึงสถานะแบบเต็ม และผู้ตรวจสอบความถูกต้องสามารถทํางานการตรวจสอบการบล็อกได้โดยไม่ต้องจัดเก็บสถานะทั้งหมด

แนวทางผลประโยชน์สองประการนี้ช่วยลดทั้งข้อกําหนดด้านแบนด์วิดท์และพื้นที่เก็บข้อมูลสําหรับผู้ตรวจสอบความถูกต้องในขณะที่เร่งการตรวจสอบการปรับปรุงที่สําคัญสามประการที่สนับสนุนวิสัยทัศน์ของ Ethereum โดยตรงสําหรับความสามารถในการปรับขนาด

ความท้าทายสำหรับการพิสูจน์ STARK:

1. ภาระการคำนวณสูงสำหรับ Provers: \
   กระบวนการสร้างพิสูจน์ STARK เป็นกระบวนการที่ใช้คำนวณอย่างหนัก โดยเฉพาะอยู่ทางฝั่ง prover ซึ่งอาจทำให้ต้นทุนดำเนินการเพิ่มขึ้น
2. ความไร้ประสิทธิภาพในการพิสูจน์ข้อมูลขนาดเล็ก:

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

ควอนตัมความปลอดภัยมาพร้อมค่าใช้จ่าย: ฝั่งพิสูจน์ภาคเสียง

Merkle Proof ของบล็อกสามารถรวมรวมประมาณ 330,000 แฮช และในกรณีที่เลวร้ายที่สุด จำนวนนี้สามารถเพิ่มขึ้นไปถึง 660,000 ในกรณีเช่นนั้น พิสท์สแตร์คพรูฟ จะต้องประมวลผลประมาณ 200,000 แฮชต่อวินาที

นี่คือจุดที่ฟังก์ชันแฮชที่เป็นมิตรกับ zk เช่น Poseidon เข้ามามีบทบาทซึ่งได้รับการปรับให้เหมาะสมโดยเฉพาะสําหรับการพิสูจน์ STARK เพื่อลดภาระนี้ โพไซดอนได้รับการออกแบบมาให้ทํางานได้อย่างราบรื่นยิ่งขึ้นกับ ZK-proofs เมื่อเทียบกับอัลกอริธึมแฮชแบบดั้งเดิมเช่น SHA256 และ Keccak เหตุผลหลักสําหรับความเข้ากันได้นี้อยู่ที่วิธีการทํางานของอัลกอริทึมแฮชแบบดั้งเดิม: พวกเขาประมวลผลอินพุตเป็นข้อมูลไบนารี (0s และ 1s) ในทางกลับกัน ZK-proofs ทํางานร่วมกับฟิลด์เฉพาะโครงสร้างทางคณิตศาสตร์ที่แตกต่างกันโดยพื้นฐาน สถานการณ์นี้คล้ายกับคอมพิวเตอร์ที่ทํางานแบบไบนารีในขณะที่มนุษย์ใช้ระบบทศนิยมในชีวิตประจําวัน การแปลข้อมูลตามบิตเป็นรูปแบบที่เข้ากันได้กับ ZK เกี่ยวข้องกับค่าใช้จ่ายในการคํานวณที่สําคัญ โพไซดอนแก้ปัญหานี้โดยการดําเนินงานภายในสาขาที่สําคัญเร่งการรวมเข้ากับ ZK-proofs อย่างมาก

อย่างไรก็ตามเนื่องจากโพไซดอนเป็นฟังก์ชันแฮชที่ค่อนข้างใหม่จึงต้องการการวิเคราะห์ความปลอดภัยที่ครอบคลุมมากขึ้นเพื่อสร้างความมั่นใจในระดับเดียวกับฟังก์ชันแฮชแบบดั้งเดิมเช่น SHA256 และ Keccak ด้วยเหตุนี้ความคิดริเริ่มเช่น โครงการวิเคราะห์รหัสลับ Poseidonเปิดตัวโดย Ethereum Foundation เชิญผู้เชี่ยวชาญมาทดสอบและวิเคราะห์ความปลอดภัยของโพไซดอนอย่างเข้มงวด เพื่อให้แน่ใจว่าสามารถทนต่อการตรวจสอบของฝ่ายตรงข้ามและกลายเป็นมาตรฐานที่แข็งแกร่งสําหรับแอปพลิเคชันการเข้ารหัส ในทางกลับกันฟังก์ชั่นรุ่นเก่าเช่น SHA256 และ Keccak ได้รับการทดสอบอย่างกว้างขวางและมีประวัติความปลอดภัยที่พิสูจน์แล้ว แต่ไม่เป็นมิตรกับ ZK ส่งผลให้ประสิทธิภาพลดลงเมื่อใช้กับหลักฐาน STARK

ตัวอย่างเช่น การพิสูจน์ STARK โดยใช้ฟังก์ชันแฮชแบบดั้งเดิมเหล่านี้สามารถประมวลผลแฮชได้เพียง 10,000 ถึง 30,000 แฮชเท่านั้น โชคดีที่ความก้าวหน้าในเทคโนโลยี STARK ชี้ให้เห็นว่าปริมาณงานนี้อาจเพิ่มขึ้นเป็น 100,000 ถึง 200,000 แฮชในไม่ช้า ซึ่งช่วยปรับปรุงประสิทธิภาพได้อย่างมาก

ความไร้ประสิทธิภาพของ STARKs ในการพิสูจน์ข้อมูลขนาดเล็ก

แม้ว่าหลักฐานของ STARK จะเก่งในด้านความสามารถในการปรับขนาดและความโปร่งใสสําหรับชุดข้อมูลขนาดใหญ่ แต่ก็แสดงข้อ จํากัด เมื่อทํางานกับองค์ประกอบข้อมูลขนาดเล็กและจํานวนมาก ในสถานการณ์เหล่านี้ข้อมูลที่ถูกพิสูจน์มักจะมีขนาดเล็ก แต่ความจําเป็นในการพิสูจน์หลายครั้งยังคงไม่เปลี่ยนแปลง ตัวอย่างเช่น:

1. การตรวจสอบธุรกรรมหลัง-AA: \
   ด้วย Account Abstraction (AA) กระเป๋าเงินสามารถชี้ไปยังรหัสสัญญา โดยการ ข้ามหรือปรับแต่งขั้นตอนเช่น nonce และการตรวจสอบลายเซ็นเซอร์ที่เป็นบังคับใน Ethereum อย่างไรก็ตาม ความยืดหยุ่นในการตรวจสอบนี้ต้องการการตรวจสอบรหัสสัญญาหรือข้อมูลที่เกี่ยวข้องอื่น ๆ ในสถานะเพื่อพิสูจน์ความถูกต้องของธุรกรรม
2. การเรียกใช้งาน RPC ของไคลเอ็นต์เบา: \
   ไคลเอ็นต์ที่เบาสอบถามข้อมูลสถานะจากเครือข่าย (เช่นในระหว่างคำขอ eth_call) โดยไม่ต้องเรียกใช้โหนดเต็มรูปแบบ เพื่อให้มั่นใจได้ว่าสถานะนี้ถูกต้อง การพิสูจน์จะต้องสนับสนุนข้อมูลที่ถูกสอบถามและยืนยันว่ามันตรงกับสถานะปัจจุบันของเครือข่าย
3. รายการรวม: \
   Validator ขนาดเล็กสามารถใช้กลไกรายการรวมเพื่อให้แน่ใจว่าธุรกรรมถูกรวมอยู่ในบล็อกถัดไป จำกัดอิทธิพลของผู้ผลิตบล็อกที่มีอิทธิพลมาก อย่างไรก็ตาม การตรวจสอบความถูกต้องของธุรกรรมเหล่านี้ต้องการการตรวจสอบความถูกต้องของธุรกรรมเหล่านั้น

ในกรณีการใช้งานเช่นนี้ STARK proofs ให้ประโยชน์น้อยมาก STARKs ที่เน้นความมีประสิทธิภาพ (เช่นที่ได้รับการเน้นด้วยตัวอักษร ‘S’ ในชื่อ) ทำงานได้ดีสำหรับชุดข้อมูลขนาดใหญ่ แต่มีความยากลำบากในสถานการณ์ข้อมูลขนาดเล็ก ในทางกลับกัน SNARKs ออกแบบมาเพื่อความสั้น (เช่นที่ได้รับการเน้นด้วยตัวอักษร ‘S’ ในชื่อ) ให้ความสำคัญกับการลดขนาดหลักฐาน มีประโยชน์ชัดเจนในสภาพแวดล้อมที่มีข้อจำกัดในแบนด์วิดธ์หรือพื้นที่เก็บข้อมูล

โดยทั่วไปหลักฐาน STARK จะมีขนาด 40-50 KB ซึ่งใหญ่กว่าหลักฐาน SNARK ประมาณ 175 เท่าซึ่งมีขนาดเพียง 288 ไบต์ ความแตกต่างของขนาดนี้จะเพิ่มทั้งเวลาในการตรวจสอบและค่าใช้จ่ายเครือข่าย เหตุผลหลักสําหรับการพิสูจน์ที่ใหญ่กว่าของ STARKs คือการพึ่งพาความโปร่งใสและภาระผูกพันพหุนามเพื่อให้แน่ใจว่าสามารถปรับขนาดได้ซึ่งแนะนําต้นทุนประสิทธิภาพในสถานการณ์ข้อมูลขนาดเล็ก ในกรณีเช่นนี้วิธีการที่รวดเร็วและประหยัดพื้นที่มากขึ้นเช่น Merkle Proofs อาจใช้งานได้จริงมากกว่า Merkle Proofs เสนอต้นทุนการคํานวณที่ต่ําและการอัปเดตอย่างรวดเร็วทําให้เหมาะสําหรับสถานการณ์เหล่านี้

อย่างไรก็ตาม การพิสูจน์ STARK ยังคงมีความสําคัญต่ออนาคตที่ไร้สัญชาติของ Ethereum เนื่องจากความปลอดภัยควอนตัม

ตามสรุปในตาราง Ethereum มีทางเลือกสี่ทางที่เป็นไปได้:

• Verkle Trees
  1. Verkle Trees ได้รับการสนับสนุนอย่างกว้างขวางจากชุมชน Ethereum โดยมีการประชุมทุกสองสัปดาห์เพื่ออํานวยความสะดวกในการพัฒนา ด้วยการทํางานและการทดสอบที่สอดคล้องกันนี้ Verkle Trees จึงโดดเด่นในฐานะโซลูชันที่ครบถ้วนและได้รับการวิจัยอย่างดีที่สุดในบรรดาทางเลือกในปัจจุบัน ยิ่งไปกว่านั้นคุณสมบัติ homomorphic เสริมของพวกเขาไม่จําเป็นต้องคอมไพล์ทุกสาขาเพื่ออัปเดตรากของรัฐซึ่งแตกต่างจาก Merkle Trees ทําให้ Verkle Trees เป็นตัวเลือกที่มีประสิทธิภาพมากขึ้น เมื่อเทียบกับโซลูชันอื่น ๆ Verkle Trees เน้นความเรียบง่ายโดยยึดมั่นในหลักการทางวิศวกรรมเช่น “ทําให้เรียบง่าย” หรือ “เรียบง่ายที่สุด” ความเรียบง่ายนี้อํานวยความสะดวกในการรวมเข้ากับ Ethereum และการวิเคราะห์ความปลอดภัย
  2. อย่างไรก็ตาม Verkle Trees ไม่ปลอดภัยควอนตัมซึ่งทําให้ไม่สามารถแก้ปัญหาระยะยาวได้ หากรวมเข้ากับ Ethereum เทคโนโลยีนี้อาจต้องถูกแทนที่ในอนาคตเมื่อจําเป็นต้องใช้โซลูชันที่ทนต่อควอนตัม แม้แต่ Vitalik ยังมองว่า Verkle Trees เป็นมาตรการชั่วคราวในการซื้อเวลาสําหรับ STARKs และเทคโนโลยีอื่น ๆ ให้เติบโตเต็มที่ นอกจากนี้ ความมุ่งมั่นของเวกเตอร์ที่ใช้เส้นโค้งวงรีที่ใช้ใน Verkle Trees ยังกําหนดภาระการคํานวณที่สูงขึ้นเมื่อเทียบกับฟังก์ชันแฮชอย่างง่าย วิธีการที่ใช้แฮชอาจให้เวลาซิงโครไนซ์ที่เร็วขึ้นสําหรับโหนดแบบเต็ม นอกจากนี้ การพึ่งพาการดําเนินการ 256 บิตจํานวนมากทําให้ Verkle Trees พิสูจน์ได้ยากขึ้นโดยใช้ SNARKs ภายในระบบพิสูจน์ที่ทันสมัย ซึ่งทําให้ความพยายามในอนาคตในการลดขนาดการพิสูจน์มีความซับซ้อน

อย่างไรก็ตาม ควรทำความรู้จักว่า Verkle Trees เนื่องจากไม่ได้พึ่งพาการทำ hashing จึงมีความน่าเชื่อถือมากกว่า Merkle Trees อย่างมาก

• STARKs + ฟังก์ชันแฮชอนุรักษ์
  1. การผสม STARKs กับฟังก์ชันแฮชที่เป็นที่ยอมรับอย่างเข้มงวดเช่น SHA256 หรือ BLAKE จะให้ความแข็งแกร่งในโครงสร้างความมั่นคงของ Ethereum ฟังก์ชันเหล่านี้ได้รับการใช้งานอย่างกว้างขวางและทดสอบอย่างละเอียดในโดเมนทางวิชาการและการปฏิบัติ นอกจากนี้ความต้านทานต่อคอมพิวเตอร์ควอนตัมของพวกเขายังเสริมสร้างความทนทานของ Ethereum เมื่อเผชิญกับอุปสรรคในอนาคต สำหรับสถานการณ์ที่เกี่ยวกับความมั่นคงปลอดภัย การผสมเหล่านี้นั้นเสถียรเป็นพื้นฐานที่เชื่อถือได้
  2. อย่างไรก็ตามการใช้ฟังก์ชันแฮชแบบอนุรักษ์นิยมในระบบ STARK ทําให้เกิดข้อ จํากัด ด้านประสิทธิภาพที่สําคัญ ข้อกําหนดการคํานวณของฟังก์ชันแฮชเหล่านี้ส่งผลให้มีเวลาแฝงในการพิสูจน์สูงโดยการสร้างหลักฐานใช้เวลามากกว่า 10 วินาที นี่เป็นข้อเสียที่สําคัญโดยเฉพาะอย่างยิ่งในสถานการณ์เช่นการตรวจสอบบล็อกที่ต้องการเวลาแฝงต่ํา ในขณะที่ความพยายามเช่นข้อเสนอก๊าซหลายมิติพยายามที่จะจัดแนวเวลาแฝงในกรณีที่เลวร้ายที่สุดและค่าเฉลี่ยผลลัพธ์มี จํากัด นอกจากนี้ แม้ว่าวิธีการที่ใช้แฮชจะอํานวยความสะดวกในการซิงโครไนซ์ที่เร็วขึ้น แต่ประสิทธิภาพอาจไม่สอดคล้องกับเป้าหมายความสามารถในการปรับขนาดที่กว้างขึ้นของ STARKs เวลาในการคํานวณที่ยาวนานของฟังก์ชันแฮชแบบเดิมช่วยลดประสิทธิภาพในทางปฏิบัติและจํากัดการบังคับใช้
• STARKs + ฟังก์ชั่นแฮชที่เป็นรายล่าสุด
  1. STARKs รวมกับฟังก์ชันแฮชที่เป็นมิตรกับ STARK รุ่นใหม่ (เช่น Poseidon) ช่วยปรับปรุงประสิทธิภาพของเทคโนโลยีนี้อย่างมีนัยสําคัญ ฟังก์ชันแฮชเหล่านี้ได้รับการออกแบบมาเพื่อผสานรวมกับระบบ STARK ได้อย่างราบรื่นและลดเวลาแฝงของ prover ลงอย่างมาก ซึ่งแตกต่างจากฟังก์ชั่นแฮชแบบดั้งเดิมพวกเขาเปิดใช้งานการสร้างหลักฐานในเวลาเพียง 1-2 วินาที ประสิทธิภาพและค่าใช้จ่ายในการคํานวณที่ต่ําช่วยเพิ่มศักยภาพในการปรับขนาดของ STARKs ทําให้มีประสิทธิภาพสูงในการจัดการชุดข้อมูลขนาดใหญ่ ความสามารถนี้ทําให้น่าสนใจเป็นพิเศษสําหรับแอปพลิเคชันที่ต้องการประสิทธิภาพสูง
  2. อย่างไรก็ตามความใหม่ของฟังก์ชันแฮชเหล่านี้ต้องการการวิเคราะห์ด้านความปลอดภัยที่เป็นมากและการทดสอบอย่างเป็นอย่างมาก การขาดความสมบูรณ์ของการทดสอบที่ทำให้เกิดความเสี่ยงเมื่อพิจารณาการนำมาใช้ในระบบนิวกรรมสำคัญอย่าง Ethereum อีกทั้งยังมีการใช้ฟังก์ชันแฮชเหล่านี้อย่างกว้างขวางอย่างไม่เป็นทางการ กระบวนการทดสอบและการตรวจสอบที่จำเป็นอาจทำให้เป้าหมายในการตรวจสอบของ Ethereum ถูกล่าช้าลง การใช้เวลาในการตรวจสอบความปลอดภัยอย่างเต็มรูปแบบอาจทำให้ตัวเลือกนี้น้อยน้อยลงในระยะสั้น ซึ่งอาจทำให้เป้าหมายในการขยายของ Ethereum และความทรงจำของ Ethereum ล้มละลายได้
• ต้นไม้ Merkle ที่ใช้ตาข่าย
  1. Merkle Trees ที่ใช้ตาข่ายนําเสนอโซลูชันที่คิดไปข้างหน้าซึ่งรวมการรักษาความปลอดภัยควอนตัมเข้ากับประสิทธิภาพการอัปเดตของ Verkle Trees โครงสร้างเหล่านี้จัดการกับจุดอ่อนของทั้ง Verkle Trees และ STARKs และถือเป็นตัวเลือกระยะยาวที่มีแนวโน้ม ด้วยการออกแบบที่ใช้ตาข่ายพวกเขาให้ความต้านทานที่แข็งแกร่งต่อภัยคุกคามการประมวลผลควอนตัมซึ่งสอดคล้องกับการมุ่งเน้นของ Ethereum ในการพิสูจน์ระบบนิเวศในอนาคต ยิ่งไปกว่านั้นด้วยการรักษาข้อได้เปรียบด้านความสามารถในการอัปดายของ Verkle Trees พวกเขามุ่งมั่นที่จะมอบความปลอดภัยที่เพิ่มขึ้นโดยไม่ลดทอนประสิทธิภาพ
  2. อย่างไรก็ตาม การวิจัยเกี่ยวกับ lattice-based Merkle Trees ยังอยู่ในระหว่างการพัฒนาและมีลักษณะทางทฤษฎีอย่างมาก นี้สร้างความไม่แน่ใจอย่างมากเกี่ยวกับการนำไปใช้ในการดำเนินงานและประสิทธิภาพของพวกเขา การรวมซอลูชันเช่นนี้เข้ากับ Ethereum จะต้องใช้การวิจัยและการพัฒนาอย่างเต็มที่รวมถึงการทดสอบอย่างเข้มงวดเพื่อยืนยันประโยชน์ที่เป็นไปได้ของมัน ความไม่แน่ใจเหล่านี้และความซับซ้อนทางโครงสร้างทำให้ lattice-based Merkle Trees ไม่น่าจะเป็นทางเลือกที่เหมาะสมสำหรับ Ethereum ในอนาคตใกล้เคียง ซึ่งอาจทำให้การก้าวหน้าสู่วัตถุประสงค์ในการตรวจสอบของเครือข่ายล่าช้า

มีอะไรเกี่ยวกับการดำเนินการ: การพิสูจน์ความถูกต้องของการดำเนินการ EVM

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

ในขั้นต้น The Verge ถูกมองว่าเป็นเหตุการณ์สําคัญที่มุ่งเน้นไปที่การเปลี่ยนต้นไม้ของรัฐของ Ethereum จาก Merkle Trees เป็น Verkle Trees เพื่อปรับปรุงการตรวจสอบสถานะ อย่างไรก็ตามเมื่อเวลาผ่านไปได้พัฒนาเป็นความคิดริเริ่มที่กว้างขึ้นโดยมีวัตถุประสงค์เพื่อเพิ่มความสามารถในการตรวจสอบการเปลี่ยนผ่านของรัฐและฉันทามติ ในโลกที่ทั้งสามของรัฐการดําเนินการและฉันทามติสามารถตรวจสอบได้อย่างสมบูรณ์ผู้ตรวจสอบ Ethereum สามารถทํางานได้บนอุปกรณ์แทบทุกชนิดที่มีการเชื่อมต่ออินเทอร์เน็ตที่สามารถจัดประเภทเป็น Light Client ได้ สิ่งนี้จะทําให้ Ethereum เข้าใกล้การบรรลุวิสัยทัศน์ของ “การกระจายอํานาจที่แท้จริง”

ปัญหาที่กำหนดคืออะไร?

เหมือนที่ได้กล่าวไปแล้ว ผู้ตรวจสอบดำเนินการฟังก์ชันที่เรียกว่า STF (State Transition Function) ทุก ๆ 12 วินาที ฟังก์ชันนี้รับสถานะก่อนหน้าและบล็อกเป็นอินพุตและสร้างสถานะถัดไปเป็นเอาท์พุต ผู้ตรวจสอบต้องดำเนินการฟังก์ชันนี้ทุกครั้งที่มีบล็อกใหม่ที่เสนอขึ้นและยืนยันว่าแฮชที่แทนสถานะบนบล็อก (ที่เรียกว่ารากสถานะ) ถูกต้อง

ความต้องการของระบบสูงสำหรับการเป็นผู้ตรวจสอบโดยส่วนใหญ่มาจากความต้องการในการดำเนินกระบวนการนี้อย่างมีประสิทธิภาพ

หากคุณต้องการเปลี่ยนตู้เย็นอัจฉริยะ -ใช่ แม้กระทั่งตู้เย็น- เป็น Ethereum validator ด้วยความช่วยเหลือของซอฟต์แวร์ที่ติดตั้งแล้ว คุณจะเผชิญกับอุปสรรคสองปัญหาใหญ่:

1. ตู้เย็นของคุณเป็นไปได้ว่าจะไม่มีอินเทอร์เน็ตที่เร็วเพียงพอ ซึ่งหมายความว่ามันจะไม่สามารถดาวน์โหลดข้อมูลและพิสูจน์ที่จำเป็นสำหรับการดำเนินการได้ แม้ว่าจะมีการแก้ไขปัญหาการตรวจสอบสถานะที่เราได้พูดถึงกันมาแล้ว
2. แม้ว่าจะมีการเข้าถึงข้อมูลที่จำเป็นสำหรับ STF แต่มันก็ไม่มีพลังคำนวณที่จำเป็นสำหรับการทำงานตั้งแต่เริ่มต้นจนถึงสิ้นสุดหรือสร้างต้นไม้สถานะใหม่

เพื่อแก้ไขปัญหาที่เกิดจาก Light Clients ที่ไม่สามารถเข้าถึงสถานะก่อนหน้าหรือทั้งส่วนท้ายของบล็อกล่าสุด The Verge ข้อเสนอว่าผู้เสนอควรทำการดำเนินการและแนบพิสูจน์กับบล็อก พิสูจน์นี้จะรวมถึงการเปลี่ยนจากรากสถานะก่อนหน้าไปยังรากสถานะถัดไปและแฮชของบล็อก ด้วยข้อนี้ Light Clients สามารถตรวจสอบการเปลี่ยนสถานะโดยใช้แค่ 3 แฮชขนาด 32 ไบต์โดยไม่จำเป็นต้องใช้ zk-proof

อย่างไรก็ตาม เนื่องจากพิสูจน์นี้ทำงานผ่านการแฮช การบอกเล่าว่ามันเพียงแค่ตรวจสอบการเปลี่ยนสถานะเป็นความผิด ในทางกลับกัน พิสูจน์ที่แนบไว้ที่บล็อกต้องตรวจสอบสิ่งหลายอย่างพร้อมกัน

รากสถานะในบล็อคก่อนหน้า = S, รากสถานะในบล็อคถัดไป = S + 1, แฮชบล็อค = H

1. บล็อกเองต้องถูกต้อง และพรูฟสถานะภายใน ไม่ว่าจะเป็นพรูฟ Verkle หรือ STARKs ต้องทำการตรวจสอบข้อมูลที่มากับบล็อกอย่างถูกต้อง
   ในสรุป: การตรวจสอบบล็อกและพิสูจน์สถานะที่เกี่ยวข้อง
2. เมื่อ STF ถูกดำเนินการโดยใช้ข้อมูลที่จำเป็นสำหรับการดำเนินการและรวมอยู่ในบล็อกที่สอดคล้องกับ H ข้อมูลที่ควรเปลี่ยนแปลงในสถานะต้องถูกอัปเดตอย่างถูกต้อง
   สรุป: การตรวจสอบการเปลี่ยนสถานะ
3. เมื่อต้นไม้สถานะใหม่ถูกสร้างขึ้นด้วยข้อมูลที่อัพเดตอย่างถูกต้อง ค่ารากของมันต้องตรงกับ S + 1
   สรุป: การตรวจสอบขั้นตอนการสร้างต้นไม้

ในการเปรียบเทียบ Prover-Verifier ที่เราอ้างถึงก่อนหน้านี้โดยทั่วไปจะยุติธรรมที่จะบอกว่าโดยปกติจะมีความสมดุลในการคํานวณระหว่างนักแสดงทั้งสอง ในขณะที่ความสามารถของการพิสูจน์ที่จําเป็นในการทําให้ STF สามารถตรวจสอบได้เพื่อตรวจสอบหลายสิ่งพร้อมกันมีข้อได้เปรียบที่สําคัญสําหรับ Verifier แต่ก็บ่งชี้ว่าการสร้างหลักฐานดังกล่าวเพื่อให้แน่ใจว่าความถูกต้องของการดําเนินการจะค่อนข้างท้าทายสําหรับ Prover ด้วยความเร็วปัจจุบันของ Ethereum บล็อก Ethereum จะต้องได้รับการพิสูจน์ภายใน 4 วินาที อย่างไรก็ตามแม้แต่ EVM Prover ที่เร็วที่สุดที่เรามีในปัจจุบันก็สามารถพิสูจน์บล็อกเฉลี่ยได้ในเวลาประมาณ 15 วินาทีเท่านั้น [1]

กล่าวอีกนัยหนึ่ง มีทางเลือกสามเส้นทางที่แตกต่างกันที่เราสามารถเลือกเดินทางเพื่อเอาชนะความท้าทายใหญ่นี้ได้:

1. การประกอบเป็นขนาดของการพิสูจน์และการรวมกัน: หนึ่งในประโยชน์ที่สำคัญของ ZK-proofs คือความสามารถในการรวมกัน ความสามารถในการรวมพิสูจน์หลายอย่างเข้าด้วยกันเป็นหนึ่งเดียว นอกจากนี้ยังมีประสิทธิภาพที่มีความกะทัดรัดมากในเรื่องเวลาประมวลผล สิ่งนี้ไม่เพียงแค่ลดโหลดในเครือข่ายเท่านั้น แต่ยังเร่งความเร็วของกระบวนการตรวจสอบในลักษณะแบบกระจาย สำหรับเครือข่ายขนาดใหญ่เช่น Ethereum มันช่วยให้สร้างพิสูจน์ที่มีประสิทธิภาพมากขึ้นสำหรับแต่ละบล็อก

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

1. การใช้ระบบพิสูจน์ที่ถูกปรับแต่ง: ระบบพิสูจน์รุ่นใหม่มีศักยภาพในการทำให้กระบวนการคำนวณของ Ethereum เร็วขึ้นและมีประสิทธิภาพมากขึ้น ระบบที่ทันสมัยเช่น Orion, Binius, และ GKRสามารถลดเวลาการพิสูจน์ได้มากสำหรับการคำนวณแบบทั่วไป ระบบเหล่านี้มีเป้าหมายที่จะเอาชนะข้อจำกัดของเทคโนโลยีปัจจุบัน โดยเพิ่มความเร็วในการประมวลผลในขณะที่ใช้ทรัพยากรน้อยลง สำหรับเครือข่ายที่เน้นการขยายขนาดและประสิทธิภาพ เช่น Ethereum การปรับปรุงดังกล่าวจะเป็นประโยชน์อย่างมาก อย่างไรก็ตาม การใช้งานเต็มรูปแบบของระบบใหม่เหล่านี้ต้องผ่านการทดสอบอย่างละเอียดและความพร้อมทางเทคโนโลยีภายในระบบ
2. การเปลี่ยนแปลงค่า Gas: ในอดีตค่า gas สำหรับการดำเนินการบนเครื่องจำลองเสมือน Ethereum (EVM) มักจะถูกกำหนดโดยพฤติกรรมทางคำนวณของมัน อย่างไรก็ตาม ในปัจจุบัน มีตัวชี้วัดอีกตัวที่ได้รับความสำคัญมากขึ้น คือ ความซับซ้อนของการพิสูจน์ ในขณะที่บางการดำเนินการง่ายต่อการพิสูจน์ แต่การดำเนินการอื่นมีโครงสร้างที่ซับซ้อนมากและใช้เวลาในการตรวจสอบมากขึ้น การปรับค่า gas ไม่เพียงแต่ตามความพยายามทางคำนวณ แต่ยังตามความยากลำบากของการพิสูจน์การดำเนินการเป็นสิ่งสำคัญสำหรับการเสริมสร้างความปลอดภัยและประสิทธิภาพของเครือข่าย

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

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

ในทางกลับกันวงจรพิเศษ (เช่น ASIC, FPGA, GPU) ที่ออกแบบมาโดยเฉพาะสําหรับงานบางอย่างมีศักยภาพอย่างมากในการเร่งกระบวนการสร้างหลักฐาน โซลูชันเหล่านี้ให้ประสิทธิภาพที่สูงกว่ามากเมื่อเทียบกับฮาร์ดแวร์แบบเดิมและสามารถเร่งกระบวนการดําเนินการได้ อย่างไรก็ตามเป้าหมายการกระจายอํานาจของ Ethereum ในระดับเลเยอร์ 1 ป้องกันไม่ให้ฮาร์ดแวร์ดังกล่าวสามารถเข้าถึงได้เฉพาะกลุ่มนักแสดงที่เลือกเท่านั้น ด้วยเหตุนี้โซลูชันเหล่านี้จึงคาดว่าจะเห็นการใช้งานที่กว้างขวางมากขึ้นในระบบเลเยอร์ 2 อย่างไรก็ตามชุมชนจะต้องบรรลุฉันทามติเกี่ยวกับข้อกําหนดฮาร์ดแวร์สําหรับการสร้างหลักฐาน คําถามการออกแบบที่สําคัญเกิดขึ้น: การสร้างหลักฐานควรทํางานบนฮาร์ดแวร์ระดับผู้บริโภคเช่นแล็ปท็อประดับไฮเอนด์หรือต้องการโครงสร้างพื้นฐานทางอุตสาหกรรมหรือไม่? คําตอบเป็นตัวกําหนดสถาปัตยกรรมทั้งหมดของ Ethereum - ช่วยให้สามารถเพิ่มประสิทธิภาพเชิงรุกสําหรับโซลูชันเลเยอร์ 2 ในขณะที่ต้องการแนวทางที่อนุรักษ์นิยมมากขึ้นสําหรับเลเยอร์ 1

ในที่สุดการดําเนินการพิสูจน์การดําเนินการจะเชื่อมโยงโดยตรงกับวัตถุประสงค์แผนงานอื่น ๆ ของ Ethereum การแนะนําการพิสูจน์ความถูกต้องไม่เพียง แต่สนับสนุนแนวคิดเช่นการไร้สัญชาติ แต่ยังช่วยเพิ่มการกระจายอํานาจของ Ethereum โดยทําให้พื้นที่ต่างๆเช่นการปักหลักเดี่ยวสามารถเข้าถึงได้มากขึ้น เป้าหมายคือการเปิดใช้งานการปักหลักบนอุปกรณ์ที่มีสเปคต่ําที่สุด นอกจากนี้ การปรับโครงสร้างต้นทุนก๊าซใน EVM ตามความยากในการคํานวณและความสามารถในการพิสูจน์สามารถลดช่องว่างระหว่างสถานการณ์เฉลี่ยและสถานการณ์ที่เลวร้ายที่สุดได้ อย่างไรก็ตามการเปลี่ยนแปลงดังกล่าวอาจทําลายความเข้ากันได้ย้อนหลังกับระบบปัจจุบันและบังคับให้นักพัฒนาเขียนโค้ดใหม่ ด้วยเหตุนี้การดําเนินการพิสูจน์การดําเนินการจึงไม่ใช่แค่ความท้าทายทางเทคนิค แต่เป็นการเดินทางที่ต้องออกแบบมาเพื่อรักษาคุณค่าระยะยาวของ Ethereum

ขั้นตอนสุดท้ายสำหรับความสามารถในการตรวจสอบที่แท้จริง: ความเห็นชอบร่วมกัน

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

ความเห็นร่วมซึ่งเป็นการสร้างบนรูปแบบการสื่อสารแบบสบายๆ ในโมเดลนี้ แทนที่การสื่อสารโดยตรงกับโหนดทั้งหมดที่แทนเครือข่าย โหนดหนึ่งแชร์ข้อมูลกับเซ็ตที่เลือกแบบสุ่มของโหนด 64 หรือ 128 โหนด การเลือกโซ่ของโหนดมีพื้นฐานบนข้อมูลจำกัดนี้ ซึ่งทำให้เกิดโอกาสของความผิดพลาด อย่างไรก็ตาม ตลอดเวลา ขณะที่บล็อกเชนก้าวหน้า การเลือกเซ็ตเหล่านี้มีความคาดหวังที่จะเข้าใกล้โซ่ที่ถูกต้องกับอัตราความผิดพลาด 0%

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

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

Epochs ซึ่งครอบคลุม 32 ช่องนำเสนอความเห็นสนับสนุนที่กำหนดเอง ในระดับนี้ผู้ตรวจสอบโหวตเพื่อสิ้นสุดลำดับของโซ่ เพื่อให้มั่นใจและทำให้โซ่เป็นไปตามกฎหมาย อย่างไรก็ตาม ในขณะที่โครงสร้างที่กำหนดเองนี้จะให้การตรวจสอบได้ที่ระดับของช่วงเวลา Epochs เท่านั้น แต่ก็ไม่สามารถให้การตรวจสอบได้ทั่วไปภายในช่วงเวลา Epochs ด้วยโครงสร้างที่มีความน่าจะเป็น ด้วยเหตุนี้ Ethereum ได้พัฒนาวิธีการช่วยเสริมโครงสร้างที่มีความน่าจะเป็นภายในช่วงเวลา Epochs ซึ่งเรียกว่า Sync Committee

โปรโตคอลไคลเอ็นต์ของ Altair: คณะกรรมการซิงค์

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

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

อย่างไรก็ตาม คณะกรรมการ Sync ได้ถูกวิจารณ์ในบางด้าน โดยเฉพาะโปรโตคอลขาดกลไกสำหรับการตัดสินใจคณะกรรมการสำหรับพฤติกรรมที่เป็นอันตราย แม้ว่าผู้ตรวจที่เลือกได้กระทำอย่างตั้งใจเพื่อต่อต้านโปรโตคอล ผลที่เกิดขึ้นคือมีผู้พิจารณา Sync Committee ว่าเป็นความเสี่ยงทางด้านความปลอดภัยและไม่ได้จัดอยู่ใน Light Client Protocol อย่างแท้จริง อย่างไรก็ตาม ความปลอดภัยของ Sync Committee ได้รับการพิสูจน์ทางคณิตศาสตร์แล้ว และรายละเอียดเพิ่มเติมสามารถหาได้ในบทความนี้เกี่ยวกับการตัดสินใจของคณะกรรมการการประสาน.

การไม่มีกลไกเฉือนในโปรโตคอลไม่ใช่ทางเลือกในการออกแบบ แต่เป็นความจําเป็นที่เกิดจากลักษณะของฉันทามติที่น่าจะเป็นไปได้ ฉันทามติที่น่าจะเป็นไปได้ไม่ได้ให้การรับประกันที่แน่นอนเกี่ยวกับสิ่งที่ผู้ตรวจสอบสังเกต แม้ว่าผู้ตรวจสอบส่วนใหญ่จะรายงานส้อมเฉพาะว่าเป็นส้อมที่หนักกว่า แต่ก็ยังมีผู้ตรวจสอบพิเศษที่สังเกตส้อมที่แตกต่างกันว่าหนักกว่า ความไม่แน่นอนนี้ทําให้ยากต่อการพิสูจน์เจตนาร้ายและดังนั้นจึงเป็นไปไม่ได้ที่จะลงโทษพฤติกรรมที่ไม่เหมาะสม

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

เนื่องจากข้อจำกัดเหล่านี้ มีการพยายามอย่างต่อเนื่องในระบบนิวัตรของ Ethereum เพื่อการออกแบบกลไกความเห็นร่วมใหม่และใช้วิธีการที่ให้ความชัดเจนในช่วงเวลาที่สั้นลง ข้อเสนอแบบOrbit-SSFและ3SF มีจุดมุ่งหมายเพื่อปรับเปลี่ยนโครงสร้างฉันทามติของ Ethereum ตั้งแต่ต้นสร้างระบบที่มีประสิทธิภาพมากขึ้นเพื่อแทนที่ฉันทามติที่น่าจะเป็นไปได้ วิธีการดังกล่าวไม่เพียง แต่พยายามลดระยะเวลาสุดท้ายของห่วงโซ่ แต่ยังเพื่อส่งมอบโครงสร้างเครือข่ายที่มีประสิทธิภาพและตรวจสอบได้มากขึ้น ชุมชน Ethereum ยังคงพัฒนาและเตรียมข้อเสนอเหล่านี้อย่างแข็งขันสําหรับการดําเนินการในอนาคต

การทำให้ Consensus ด้วย Snark

The Verge มีจุดมุ่งหมายเพื่อปรับปรุงกลไกฉันทามติในปัจจุบันและอนาคตของ Ethereum โดยทําให้สามารถตรวจสอบได้มากขึ้นผ่านเทคโนโลยี zk-proof แทนที่จะแทนที่ทั้งหมด แนวทางนี้พยายามปรับปรุงกระบวนการฉันทามติของ Ethereum ให้ทันสมัยในขณะที่ยังคงรักษาหลักการสําคัญของการกระจายอํานาจและความปลอดภัย การเพิ่มประสิทธิภาพกระบวนการฉันทามติในอดีตและปัจจุบันทั้งหมดของห่วงโซ่ด้วยเทคโนโลยี zk มีบทบาทสําคัญในการบรรลุเป้าหมายความสามารถในการปรับขนาดและประสิทธิภาพในระยะยาวของ Ethereum การดําเนินการพื้นฐานที่ใช้ในชั้นฉันทามติของ Ethereum มีความสําคัญอย่างยิ่งในการเปลี่ยนแปลงทางเทคโนโลยีนี้ ลองมาดูการดําเนินงานเหล่านี้และความท้าทายที่พวกเขาเผชิญอย่างใกล้ชิด

• ECADDs:
  • วัตถุประสงค์: การดำเนินการนี้ใช้สำหรับรวบรวมกุญแจสาธารณะของผู้ตรวจสอบและเป็นสิ่งที่สำคัญในการให้ความแม่นยำและประสิทธิภาพของเชื่อมต่อ ด้วยลักษณะของลายเซ็น BLS ที่สามารถรวมลายเซ็นได้หลายลายเข้าไปในโครงสร้างเดียวกัน ส่งผลให้การสื่อสารลดลงและทำให้กระบวนการตรวจสอบบนเชื่อมต่อมีประสิทธิภาพมากขึ้น การตระหนักให้มีการประสานงานระหว่างกลุ่มผู้ตรวจสอบขนาดใหญ่อย่างมีประสิทธิภาพมากขึ้นทำให้การดำเนินการนี้เป็นสิ่งสำคัญ
  • ความท้าทาย: ดังที่ได้กล่าวไว้ก่อนหน้านี้ผู้ตรวจสอบของ Ethereum จะลงคะแนนให้กับคําสั่งของห่วงโซ่ในช่วงยุค วันนี้ Ethereum เป็นเครือข่ายที่มีผู้ตรวจสอบความถูกต้องประมาณ 1.1 ล้านคน หากผู้ตรวจสอบทั้งหมดพยายามเผยแพร่คะแนนเสียงพร้อมกันมันจะสร้างความเครียดอย่างมีนัยสําคัญในเครือข่าย เพื่อหลีกเลี่ยงปัญหานี้ Ethereum อนุญาตให้ผู้ตรวจสอบความถูกต้องลงคะแนนแบบสล็อตในช่วงยุคหนึ่งซึ่งมีเพียง 1/32 ของผู้ตรวจสอบทั้งหมดเท่านั้นที่ลงคะแนนต่อสล็อต ในขณะที่กลไกนี้ช่วยลดค่าใช้จ่ายในการสื่อสารเครือข่ายและทําให้ฉันทามติมีประสิทธิภาพมากขึ้นเมื่อพิจารณาจากจํานวนผู้ตรวจสอบในปัจจุบันผู้ตรวจสอบความถูกต้องประมาณ 34,000 คนลงคะแนนในแต่ละช่อง สิ่งนี้แปลว่าการดําเนินการ ECADD ประมาณ 34,000 รายการต่อสล็อต
• คู่:
  • วัตถุประสงค์: การดำเนินการจับคู่ถูกใช้สำหรับการยืนยันลายเซ็น BLS เพื่อให้แน่ใจถึงความถูกต้องของยุคบนโซน ดำเนินการนี้อนุญาตให้มีการยืนยันลายเซ็นแบบแช่เชื่อมได้ อย่างไรก็ตาม มันไม่เหมาะกับ zk-friendly ทำให้การพิสูจน์โดยใช้เทคโนโลยี zk-proof เป็นเรื่องที่มีค่าใช้จ่ายมากมาย สิ่งนี้นำมาซึ่งความท้าทายใหญ่ในการสร้างกระบวนการยืนยันที่เชื่อมโยงกับเทคโนโลยีที่ไม่มีความรู้
  • ความท้าทาย: การดําเนินการจับคู่ใน Ethereum ถูกจํากัดไว้ที่ 128 attestations (ลายเซ็นรวม) ต่อสล็อต ส่งผลให้การดําเนินการจับคู่น้อยลงเมื่อเทียบกับ ECADDs อย่างไรก็ตามการขาดความเป็นมิตรต่อ zk ในการดําเนินงานเหล่านี้ก่อให้เกิดความท้าทายที่สําคัญ การพิสูจน์การดําเนินการจับคู่กับ zk-proofs นั้นมีราคาแพงกว่าการพิสูจน์การดําเนินการ ECADD หลายพันเท่า [2] สิ่งนี้ทําให้การปรับการดําเนินการจับคู่สําหรับเทคโนโลยีที่ไม่มีความรู้เป็นหนึ่งในอุปสรรคที่ยิ่งใหญ่ที่สุดในกระบวนการตรวจสอบฉันทามติของ Ethereum
• SHA256 Hashes:
  • วัตถุประสงค์: ฟังก์ชันแฮช SHA256 ใช้สำหรับอ่านและอัปเดตสถานะของโซ่เพื่อให้มั่นใจในความถูกต้องของข้อมูลของโซ่ แต่ความไม่เป็นมิตรกับ zk-proof-based ทำให้เกิดปัญหาด้านประสิทธิภาพในกระบวนการตรวจสอบและยืนยัน ซึ่งเป็นอุปสรรคใหญ่ต่อเป้าหมายในการยืนยันของ Ethereum ในอนาคต
  • ความท้าทาย: ฟังก์ชันแฮช SHA256 มักใช้สําหรับการอ่านและอัปเดตสถานะของเชน อย่างไรก็ตาม ความไม่เป็นมิตรของ zk ขัดแย้งกับเป้าหมายการตรวจสอบตาม zk-proof ของ Ethereum ตัวอย่างเช่นระหว่างสองยุคผู้ตรวจสอบแต่ละคนเรียกใช้ STF ของ Consensus Layer ของ Ethereum เพื่ออัปเดตสถานะด้วยรางวัลและบทลงโทษตามประสิทธิภาพของผู้ตรวจสอบความถูกต้องในช่วงยุค กระบวนการนี้อาศัยฟังก์ชันแฮช SHA256 อย่างมากซึ่งเพิ่มต้นทุนอย่างมากในระบบที่ใช้ zk-proof สิ่งนี้สร้างอุปสรรคสําคัญในการปรับกลไกฉันทามติของ Ethereum ให้สอดคล้องกับเทคโนโลยี zk

การดําเนินการ ECADD, Pairing และ SHA256 ที่ใช้ในเลเยอร์ฉันทามติปัจจุบันมีบทบาทสําคัญในเป้าหมายการตรวจสอบของ Ethereum อย่างไรก็ตามการขาดความเป็นมิตรต่อ zk ทําให้เกิดความท้าทายที่สําคัญบนเส้นทางสู่การบรรลุวัตถุประสงค์เหล่านี้ การดําเนินงานของ ECADD สร้างภาระที่มีค่าใช้จ่ายสูงเนื่องจากการโหวตผู้ตรวจสอบความถูกต้องจํานวนมากในขณะที่การดําเนินการจับคู่แม้จะมีจํานวนน้อยกว่า แต่ก็มีราคาแพงกว่าหลายพันเท่าในการพิสูจน์ด้วย zk-proofs นอกจากนี้, ความเป็นมิตร zk-unfriendliness ของฟังก์ชันแฮช SHA256 ทําให้การพิสูจน์การเปลี่ยนสถานะของบีคอนเชนมีความท้าทายอย่างยิ่ง. ปัญหาเหล่านี้เน้นย้ําถึงความจําเป็นในการเปลี่ยนแปลงที่ครอบคลุมเพื่อปรับโครงสร้างพื้นฐานที่มีอยู่ของ Ethereum ให้สอดคล้องกับเทคโนโลยีที่ไม่มีความรู้

สิ่งที่เรียกว่า “Beam Chain”: การสร้างภาพใหม่ของเลเยอร์ความเห็นร่วมใน Ethereum

ในวันที่ 12 พฤศจิกายน พ.ศ. 2567 ในงาน Devcon Justin Drake ได้นำเสนอข้อเสนอที่เรียกว่า “Beam Chain” ซึ่งมีจุดประสงค์เพื่อเปลี่ยนแปลงระดับความเห็นของ Ethereum อย่างเบื้องต้นและอย่างเป็นรากฐาน. Beacon Chain ได้เป็นส่วนสำคัญของเครือข่าย Ethereum เป็นเวลาเกือบห้าปี อย่างไรก็ตาม ในช่วงเวลานี้ไม่มีการเปลี่ยนแปลงโครงสร้างหลักของ Beacon Chain ในทางตรงข้าม ความคืบหน้าทางเทคโนโลยีได้เร็วขึ้นอย่างมาก ทำให้เกินกว่าความคงที่ของ Beacon Chain

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

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

ในส่วนนี้เราได้สำรวจขั้นตอนของ The Verge’s Consensus, State และ Execution อย่างละเอียด และหนึ่งในปัญหาที่สำคัญที่ได้รับการเน้นขึ้นในระหว่างกระบวนการนี้คือการใช้ฟังก์ชันการเข้ารหัส SHA256 ใน Ethereum’s Beacon Chain ขณะที่ SHA256 เป็นส่วนสำคัญในการให้ความปลอดภัยของเครือข่ายและการประมวลผลธุรกรรม ความขาดสมบูรณ์ของ zk-friendliness ทำให้เกิดอุปสรรคที่สำคัญในการบรรลุเป้าหมายในการทวีตยอดของ Ethereum ค่าใช้จ่ายในการคำนวณสูงและความไมเข้ากันของ zk technologies ทำให้เป็นปัญหาที่สำคัญที่ต้องแก้ไขในการพัฒนาอนาคตของ Ethereum

โดย Justin Drake ในโครงการถนน ที่นำเสนอในการพูดคุยใน Devcon ของเขา มองว่าการแทนที่ SHA256 ใน Beacon Chain ด้วยฟังก์ชันแฮชที่เป็นมิตรกับ zk เช่น Poseidon ข้อเสนอนี้มีเป้าหมายที่จะทำให้ Ethereum’s consensus layer ทันสมัยขึ้น ทำให้มันมีความสามารถในการทำการตรวจสอบ มีประสิทธิภาพ และสอดคล้องกับเทคโนโลยี zk-proof มากขึ้น

ในบริบทนี้เราจะเห็นว่า Ethereum ไม่เพียง แต่เผชิญกับความท้าทายด้วยฟังก์ชันแฮชที่ไม่เป็นมิตร zk แต่ยังต้องประเมินลายเซ็นดิจิทัลที่ใช้ในเลเยอร์ฉันทามติเพื่อความปลอดภัยในระยะยาว ด้วยความก้าวหน้าของการประมวลผลควอนตัมอัลกอริธึมลายเซ็นดิจิทัลเช่น ECDSA ที่ใช้อยู่ในปัจจุบันอาจเผชิญกับภัยคุกคามที่สําคัญ ตามที่ระบุไว้ในแนวทางที่เผยแพร่โดย NIST ตัวแปรของ ECDSA ที่มีระดับความปลอดภัย 112 บิตจะถูกเลิกใช้ภายในปี 2030 และถูกแบนอย่างสมบูรณ์ภายในปี 2035 สิ่งนี้จําเป็นต้องมีการเปลี่ยนแปลงสําหรับ Ethereum และเครือข่ายที่คล้ายกันไปสู่ทางเลือกที่ยืดหยุ่นมากขึ้นเช่นลายเซ็นที่ปลอดภัยระดับควอนตัมในอนาคต

ในจุดนี้ ลายเซ็นที่ใช้ฟังก์ชันแฮชเป็นทางเลือกที่สามารถต้านทานการโจรกรรมด้านควอนตัมได้ ซึ่งอาจเป็นสิ่งสำคัญในการสนับสนุนความปลอดภัยและเป้าหมายในการตรวจสอบของเครือข่าย การแก้ไขปัญหานี้ยังสามารถกำจัดอุปสรรคหลักที่สองในการทำให้ Beacon Chain เป็นแพลตฟอร์มที่สามารถตรวจสอบได้: BLS Signatures หนึ่งในขั้นตอนสำคัญที่ Ethereum สามารถทำเพื่อให้มั่นใจได้ในเรื่องความปลอดภัยจากควอนตัมคือการนำเสนอฟังก์ชันหลังควอนตัมเช่นลายเซ็นที่ใช้ฟังก์ชันแฮชและ SNARKs แบบที่ใช้ฟังก์ชันแฮชได้

ตามที่ Justin Drake เน้นในการนำเสนอ Devcon ของเขาฟังก์ชันแฮชมีความทนทานต่อคอมพิวเตอร์ควอนตัมโดยเนื้อแท้เนื่องจากการพึ่งพาความต้านทานก่อนภาพทําให้เป็นหนึ่งในหน่วยการสร้างพื้นฐานของการเข้ารหัสสมัยใหม่ คุณสมบัตินี้ช่วยให้มั่นใจได้ว่าแม้แต่คอมพิวเตอร์ควอนตัมก็ไม่สามารถทําวิศวกรรมย้อนกลับอินพุตดั้งเดิมจากแฮชที่กําหนดได้อย่างมีประสิทธิภาพ ระบบลายเซ็นที่ใช้แฮชช่วยให้ผู้ตรวจสอบและผู้ยืนยันสามารถสร้างลายเซ็นทั้งหมดตามฟังก์ชันแฮชทําให้มั่นใจได้ถึงความปลอดภัยหลังควอนตัมในขณะเดียวกันก็ให้ความสามารถในการตรวจสอบในระดับที่สูงขึ้นทั่วทั้งเครือข่ายโดยเฉพาะอย่างยิ่งหากใช้ฟังก์ชันแฮชที่เป็นมิตรกับ SNARK วิธีการนี้ไม่เพียง แต่ช่วยเพิ่มความปลอดภัยของเครือข่าย แต่ยังทําให้โครงสร้างพื้นฐานด้านความปลอดภัยระยะยาวของ Ethereum แข็งแกร่งยิ่งขึ้นและรองรับอนาคต

ระบบนี้อาศัยการรวมลายเซ็นที่ใช้แฮชและ SNARKs ที่ใช้แฮช (หลักฐานคล้าย STARK) เพื่อสร้างรูปแบบลายเซ็นที่รวบรวมได้ ลายเซ็นแบบรวมได้จะบีบอัดลายเซ็นหลายพันรายการลงในโครงสร้างเดียว โดยลดการพิสูจน์ลงเหลือเพียงไม่กี่ร้อยกิโลไบต์ การบีบอัดนี้ช่วยลดภาระข้อมูลบนเครือข่ายได้อย่างมากในขณะที่เร่งกระบวนการตรวจสอบอย่างมาก ตัวอย่างเช่นลายเซ็นผู้ตรวจสอบความถูกต้องหลายพันรายการที่ผลิตสําหรับสล็อตเดียวบน Ethereum สามารถแสดงด้วยลายเซ็นรวมเดียวช่วยประหยัดทั้งพื้นที่จัดเก็บและพลังการคํานวณ

อย่างไรก็ตามฟีเจอร์ที่โดดเด่นที่สุดของระบบนี้คือการรวมกลุ่มซ้ำอย่างไม่สิ้นสุด กลุ่มหนึ่งของลายเซ็นต์สามารถรวมกันได้อีกใต้กลุ่มหนึ่ง และกระบวนการนี้สามารถดำเนินต่อไปบนโซ่ได้ ด้วยกลไกนี้และพิจารณาความก้าวหน้าทางเทคโนโลยีในอนาคต สามารถกล่าวได้ว่านี้เปิดโอกาสให้เกิดความเป็นไปได้ที่ยังไม่สามารถทำได้ด้วย BLS ในปัจจุบัน

ข้อคิดสุดท้ายและสรุป

เส้นทางสู่การตรวจสอบของ Ethereum แสดงถึงการเปลี่ยนแปลงพื้นฐานในเทคโนโลยีบล็อกเชน ความคิดริเริ่ม Verge จัดการกับความไร้ประสิทธิภาพหลักผ่าน Verkle Trees สําหรับการตรวจสอบสถานะและการพิสูจน์ STARK สําหรับการเปลี่ยนที่ปรับขนาดได้

หนึ่งในข้อเสนอที่น่าทึ่งที่สุดคือ Beam Chain การออกแบบใหม่ของ Ethereum’s consensus layer โดยการแก้ไขข้อจำกัดของ Beacon Chain และรวมองค์ประกอบที่เป็นมิตรกับ zk-friendly ทางนี้มีเป้าหมายที่จะเพิ่มประสิทธิภาพของ Ethereum ในขณะที่ยังคงรักษาหลักการที่สำคัญของการกระจายอำนาจและการเข้าถึง อย่างไรก็ตาม การเปลี่ยนแปลงนี้ยังย้ำให้เห็นถึงความท้าทายที่ Ethereum ต้องเผชิญในการสมดุลความต้องการการคำนวณกับเป้าหมายของการรักษาเครือข่ายที่ไม่สมัครสมาชิกและที่สามารถเข้าถึงได้

กับ NIST ที่วางแผนที่จะยกเลิกการใช้รหัสวงกลมทางเลขปัจจุบันภายในปี 2035 Ethereum ต้องนำเสนอวิธีที่ป้องกันการโควันต์ที่มีประสิทธิภาพเช่นลายเซ็นที่ใช้รหัสแฮชและพอสีดอน วิธีเหล่านี้จะมีการแลกเปลี่ยนประสิทธิภาพของตัวเอง

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

แม้จะมีความก้าวหน้าเหล่านี้ แต่ความท้าทายที่สําคัญยังคงอยู่ Ethereum ต้องสํารวจปัญหาของความเป็นมิตรต่อ zk ความสามารถในการปรับขนาดฉันทามติและความซับซ้อนของการรวมการเข้ารหัสที่ทนต่อควอนตัม นอกจากนี้ความเข้ากันได้ย้อนหลังของโครงสร้างพื้นฐานที่มีอยู่ก่อให้เกิดอุปสรรคในทางปฏิบัติที่ต้องใช้โซลูชันทางวิศวกรรมอย่างรอบคอบเพื่อป้องกันการหยุดชะงักของนักพัฒนาและผู้ใช้

สิ่งที่ทำให้ Ethereum แตกต่างไม่ได้เพียงแค่นวัตกรรมทางเทคนิคของมันเป็นสิ่งที่เป็นวงจรในการแก้ไขปัญหาที่ยากที่สุดในบล็อกเชน ทางข้างหน้า - ไม่ว่าจะเป็นผ่านเทคโนโลยีเช่น Beam Chain, Verkle Trees หรือ STARK proofs - ขึ้นอยู่กับความพยายามร่วมกันของนักพัฒนา นักวิจัย และชุมชนทั่วไป การพัฒนาเหล่านี้ไม่ได้เกี่ยวกับการบรรลุความสมบูรณ์ในแต่ละคืน แต่เกี่ยวกับการสร้างพื้นฐานสำหรับอินเทอร์เน็ตที่โปร่งใส ที่กระจายและที่สามารถตรวจสอบได้

วิวัฒนาการของ Ethereum เน้นย้ําถึงบทบาทในฐานะผู้เล่นที่สําคัญในการกําหนดยุค Web3 ด้วยการรับมือกับความท้าทายในปัจจุบันด้วยโซลูชันที่ใช้งานได้จริง Ethereum จะเข้าใกล้อนาคตที่ความสามารถในการตรวจสอบความต้านทานควอนตัมและความสามารถในการปรับขนาดกลายเป็นมาตรฐานไม่ใช่ข้อยกเว้น

คำประกาศ:

1. บทความนี้ถูกพิมพ์ใหม่จาก[[](https://research.2077.xyz/the-verge-making-ethereum-verifiable-and-sustainable#the-path-to-verifiability)[2077 งานวิจัย](https://research.2077.xyz/)\]. ลิขสิทธิ์ทั้งหมดเป็นของผู้เขียนต้นฉบับ [Koray Akpinarr]. หากมีคำปฏิเสธต่อการเผยแพร่นี้ กรุณาติดต่อ เกตเรียนทีมของเราจะดูแลมันโดยเร็ว
2. ข้อจํากัดความรับผิดชอบความรับผิด: มุมมองและความคิดเห็นที่แสดงในบทความนี้เป็นเพียงของผู้เขียนและไม่ถือเป็นคําแนะนําการลงทุนใด ๆ
3. การแปลบทความเป็นภาษาอื่น ๆ ทําโดยทีม Gate Learn ห้ามคัดลอก แจกจ่าย หรือลอกเลียนแบบบทความที่แปลแล้ว เว้นแต่จะกล่าวถึง