วิสัยทัศน์ Ethereum ปี 2030 ขึ้นอยู่กับ Proofs แต่ส่วนที่ยากคือใครเป็นผู้ตรวจสอบ

โรดแมปล่าสุดของ Vitalik Buterin ชี้ไปยังเครือข่ายที่แตกต่างออกไป

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

ส่วนหนึ่งของวิสัยทัศน์นั้นเกิดขึ้นแล้ว PeerDAS เปิดใช้งานพร้อมกับการอัปเกรด Fusaka ของ Ethereum ในเดือนธันวาคม 2025 ช่วยให้ผู้ตรวจสอบสุ่มตัวอย่างข้อมูล blob แทนที่จะดาวน์โหลดทั้งหมด

การเปลี่ยนแปลงที่ใหญ่กว่า คือการใช้ proofs เพื่อตรวจสอบการประมวลผลชั้นฐานในวงกว้าง ยังคงเป็นงานในอนาคต

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

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

สิ่งที่มีอยู่แล้ว

ส่วนที่ใช้งานแล้วคือ PeerDAS ซึ่งย่อมาจาก peer-to-peer data availability sampling

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

PeerDAS เปลี่ยนแปลงสิ่งนี้โดยอนุญาตให้โหนดสุ่มตัวอย่างข้อมูลชิ้นเล็ก ๆ เทียบกับข้อผูกมัดทางเข้ารหัส เอกสารของ Ethereum ระบุว่าข้อมูล blob แบบขยายถูกแบ่งออกเป็น 128 คอลัมน์ โหนดปกติสมัครรับ subnet ของคอลัมน์ที่สุ่มเลือกอย่างน้อยแปดคอลัมน์

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

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

PeerDAS ตรวจสอบความพร้อมใช้งานของข้อมูล แต่ไม่ได้ตรวจสอบการคำนวณทุกอย่าง

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

Proofs ย้ายงานหนักไปที่อื่น

ในโมเดลการประมวลผลแบบ proof-based ยังต้องมีคนประมวลผลธุรกรรม

ฝ่ายนั้นอาจใช้ฮาร์ดแวร์ราคาแพงและซอฟต์แวร์เฉพาะทางเพื่อสร้าง cryptographic proof ที่แสดงว่าการเปลี่ยนสถานะที่อ้างว่าเป็นไปตามกฎที่ตกลงกัน จากนั้นผู้ตรวจสอบสามารถตรวจสอบ proof ได้ถูกกว่ามากเมื่อเทียบกับการประมวลผลธุรกรรมทุกตัวใหม่

นั่นคือคำมั่นสัญญาหลักของ L1 zkEVM: ลดต้นทุนการตรวจสอบบล็อก Ethereum โดยไม่ต้องให้โหนดตรวจสอบทุกโหนดทำการประมวลผลทั้งหมดซ้ำ

แต่ต้องมีเงื่อนไขหลายประการ

ผู้ตรวจสอบต้องใช้ระบบ proof, verification key, public inputs และกฎการประมวลผลที่ถูกต้อง วงจรที่ผิดพลาดสามารถพิสูจน์ข้อความที่ผิดได้ บั๊กของไคลเอนต์สามารถยอมรับ proof ที่ควรปฏิเสธ กลไกการอัปเกรดที่เปลี่ยนโค้ดผู้ตรวจสอบได้โดยไม่มีการควบคุมที่เข้มงวดสามารถลดทอนการรับประกันได้

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

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

Buterin สามารถเสนอทิศทางได้ แต่เขาไม่สามารถทำให้ผู้ตรวจสอบในอนาคตปลอดภัยหรือบังคับใช้ได้ด้วยตัวเอง

การตรวจสอบและการผลิต Proof เป็นตลาดที่แตกต่างกัน

ระบบ proof ของ Ethereum ในอนาคตอาจทำให้การตรวจสอบเข้าถึงได้อย่างกว้างขวางในขณะที่การผลิต proof ยังคงกระจุกตัว

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

ความเสี่ยงคือ liveness

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

นั่นเป็นความเสี่ยงที่แตกต่างจากการยอมรับ proof ที่ไม่ถูกต้อง แต่มันก็เป็นความเสี่ยงจริง

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

Ethereum ยังไม่ได้สรุปการออกแบบนั้น

Proofs ไม่ได้แก้ทุกปัญหา

คำว่า "proof" มักบีบอัดการรับประกันสามอย่างแยกกันเป็นหนึ่งเดียว

ผู้ใช้ที่ส่งธุรกรรมผ่าน rollup ต้องการสามสิ่ง

ประการแรก ธุรกรรมต้องถูกรวมอยู่ในชุดที่จัดลำดับแล้ว ประการที่สอง ข้อมูลที่จำเป็นในการสร้างสถานะใหม่ต้องพร้อมใช้งาน ประการที่สาม การเปลี่ยนสถานะต้องเป็นไปตามกฎ

validity proof จัดการกับประเด็นที่สาม PeerDAS จัดการความพร้อมใช้งานสำหรับข้อมูล blob ของ Ethereum Sequencers, ผู้สร้างบล็อก และกลไกการรวมมีผลต่อประเด็นแรก

นั่นเป็นปัญหาที่แตกต่างกัน

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

ความแตกต่างเดียวกันนี้ใช้กับข้อมูล

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

rollup ที่โพสต์ข้อมูลเพียงพอไปยัง Ethereum มีโมเดลความเชื่อใจที่แตกต่างกัน

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

ชั้นฐานไม่ใช่แค่ Rollup อีกตัว

ZK rollups ส่ง validity proofs ไปยัง Ethereum แล้ว ผู้ดำเนินการสร้าง proofs สำหรับชุดธุรกรรม และสัญญาผู้ตรวจสอบยอมรับ state roots ใหม่หลังจากตรวจสอบ proofs เหล่านั้นเท่านั้น

นั่นเป็นแบบอย่างที่มีประโยชน์ แต่ไม่ได้หมายความว่าชั้นฐานของ Ethereum ได้ย้ายการตรวจสอบการประมวลผลไปยัง proofs แล้ว

ขอบเขตแตกต่างกัน

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

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

ระบบ proof ชั้นฐานจึงเป็นปัญหาการประสานงานที่ใหญ่กว่า ต้องมีข้อกำหนด ไคลเอนต์ เทสเน็ต การตรวจสอบ และข้อตกลงระหว่างผู้เข้าร่วม

วลี "cryptographic world computer" ของ Buterin เป็นทิศทางการเดินทาง ไม่ใช่การอ้างว่าบริการพิสูจน์หนึ่งจะรัน Ethereum

สถานะยังคงเป็นปัญหาที่ยาก

Buterin ระบุว่าการเข้าถึงสถานะร่วมขนาดใหญ่มากเป็นหนึ่งในปัญหาที่ยังไม่ได้รับการแก้ไขที่ยากที่สุดของ Ethereum

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

หากธุรกรรมจำนวนมากแตะสถานะเดียวกันในเวลาเดียวกัน การแบ่งงานจะยากขึ้น การชำระเงินจากบัญชีหนึ่งและการสวอปกับ liquidity pool ไม่สามารถสรุปจาก snapshot ที่ไม่สอดคล้องกันได้

นี่คือเหตุผลที่สเกลไม่ใช่แค่ปัญหาการสร้าง proof

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

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

ความเป็นส่วนตัวก็ไม่ใช่เรื่องอัตโนมัติ

วิสัยทัศน์ของ Buterin รวมถึงส่วนประกอบนอกเชนแบบกระจายศูนย์และความเป็นส่วนตัวเชิงเข้ารหัสที่ดีขึ้น

นั่นไม่ได้หมายความว่า validity proofs ทำให้ Ethereum เป็นส่วนตัวโดยอัตโนมัติ

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

ความเป็นส่วนตัวต้องใช้กลไกแยกต่างหาก ระบบต้องระบุว่าข้อมูลใดถูกซ่อน ใครเข้าถึงได้ proofs ถูกสร้างอย่างไร และ metadata ใดยังมองเห็นได้

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

การเข้ารหัสสามารถลดความเชื่อใจได้ แต่มันไม่ได้ลบตัวเลือกการออกแบบ

วิธีทดสอบความเป็นอิสระ

คำกล่าวที่ว่า "ใครก็ตรวจสอบได้" มีข้อกำหนดในทางปฏิบัติ

โหนดทั่วไปต้องการโค้ดผู้ตรวจสอบ public inputs การเข้าถึงสถานะเชนที่ยอมรับ และความสามารถในการประมวลผลเพียงพอที่จะตรวจสอบ proofs ภายในเวลาที่โปรโตคอลกำหนด

การทดสอบหลายอย่างสำคัญก่อนการ fork ครั้งสุดท้าย

รันซอฟต์แวร์ผู้ตรวจสอบจากทีมไคลเอนต์มากกว่าหนึ่งทีมกับ block proof ที่ถูกต้องเดียวกัน ยืนยันว่าทั้งคู่ยอมรับ เปลี่ยน public inputs และยืนยันว่าทั้งคู่ปฏิเสธ ถามว่าทีมพิสูจน์แยกกันสามารถสร้าง proofs ที่ยอมรับได้ภายใต้กฎเดียวกันหรือไม่ เร็วแค่ไหน และต้องใช้ฮาร์ดแวร์อะไร

จากนั้นทำซ้ำบนเทสเน็ตสาธารณะภายใต้โหลด

นี่ไม่ใช่เกณฑ์การเปิดตัวอย่างเป็นทางการ แต่เป็นสัญญาณที่สังเกตได้ว่า validation แบบ proof-based พร้อมหรือยัง

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

โปรแกรมที่ถูกพิสูจน์ต้องเป็นโปรแกรมที่ถูกต้อง

proof มีประโยชน์เท่ากับข้อความที่มันพิสูจน์

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

แฮชสาธารณะของโค้ดผู้ตรวจสอบ กระบวนการอัปเกรดที่ชัดเจน และการทดสอบวงจรอิสระช่วยให้บุคคลภายนอกเปรียบเทียบกฎที่โฆษณากับสิ่งที่โหนดบังคับใช้จริง

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

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

Hegota เป็นเครื่องหมาย ไม่ใช่การรับประกัน

Buterin อ้างถึง Hegota ซึ่งเป็น fork ที่วางแผนไว้สำหรับปี 2027 ว่าอาจเป็นการอัปเกรดครั้งสุดท้ายที่ส่วนประกอบจะดูคุ้นเคยสำหรับผู้สังเกตการณ์ Ethereum ในปี 2015

หลังจากนั้น โรดแมปของเขาชี้ไปยัง recursive STARKs, การตรวจสอบอย่างเป็นทางการ, ฉันทามติที่ปรับให้เหมาะสม และความปลอดภัยเชิงควอนตัม Crypto.news ได้รายงานแยกต่างหากเกี่ยวกับเป้าหมายความปลอดภัยเชิงควอนตัมปี 2029 ของ Ethereum ว่าเป็นเป้าหมายการวางแผน

ไม่มีสิ่งใดรับประกันการส่งมอบภายในปี 2030

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

PeerDAS สามารถตรวจสอบได้วันนี้ผ่าน Fusaka และกฎโหนดปัจจุบัน zkEVM ชั้นฐานทั่วไปไม่สามารถตรวจสอบได้ด้วยการอ่านบทความ หลักฐานจะมาจากข้อกำหนด การนำไปใช้ การทดสอบสาธารณะ และแผน fork ที่เป็นรูปธรรม

ทิศทางชัดเจน แต่การทดสอบเป็นเรื่องปฏิบัติ

ข้อโต้แย้งสำหรับอนาคตที่เน้น proof ของ Ethereum นั้นแข็งแกร่ง

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

นั่นคือข้อดี

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

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

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

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