Vitalik เผย EIP-8288: ทางออกสุดท้ายเพื่อ Ethereum ที่เร็วและถูกกว่า

ผู้บรรยาย: Vitalik Buterin

เรียบเรียง: Yuliya, PANews

สวัสดีครับ! ยินดีต้อนรับสู่ ETHShanghai 2026 วันนี้ผมอยากพูดคุยเกี่ยวกับหัวข้อทางเทคนิคที่ค่อนข้างซับซ้อน แต่สำคัญอย่างยิ่งต่ออนาคตของ Ethereum ซึ่งจะช่วยให้ Ethereum บรรลุความสามารถในการปรับขนาดสูงมาก พร้อมทั้งรักษาความเป็นส่วนตัวและการกระจายศูนย์ไปพร้อมกัน และทั้งสามสิ่งนี้สามารถเกิดขึ้นได้พร้อมกัน ข้อเสนอนี้อาจเปลี่ยนแปลงสถาปัตยกรรมการทำงานขององค์ประกอบหลายอย่างในบล็อกเชนได้จริง มันสามารถเปลี่ยนแปลงหลายสิ่งได้ แต่ที่น่าแปลกใจคือการนำมันไปใช้จริงใน Ethereum ปัจจุบันไม่ใช่เรื่องยากนัก นี่คือ EIP-8288: Recursive Signature and Aggregation

ปัญหาหลัก: ความขัดแย้งระหว่างความปลอดภัย ความเป็นส่วนตัว และความสามารถในการปรับขนาด

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

• ธุรกรรม Ethereum ปกติใช้ gas ประมาณ 21,000 หน่วย การตรวจสอบลายเซ็น ECDSA (ประมาณ 65 ไบต์) แยกกันใช้ประมาณ 4,000 gas
• หากเปลี่ยนเป็นลายเซ็นที่ปลอดภัยเชิงควอนตัม (ไม่ว่าจะเป็นรูปแบบใด) การใช้ gas จะอยู่ระหว่าง 100,000 ถึง 300,000 gas ขึ้นอยู่กับขนาดพารามิเตอร์ที่เลือก (เช่น ต้องรองรับกระเป๋าเงินบล็อกเชนหรือไม่) แต่ไม่ว่าจะเลือกอย่างไร ต้นทุนจะสูงกว่าธุรกรรมปัจจุบันหลายเท่า ลายเซ็นที่ปลอดภัยเชิงควอนตัมมีขนาดใหญ่และแพง

ปัญหาที่สอง: proof ของโปรโตคอลความเป็นส่วนตัวก็ใหญ่และแพงเช่นกัน หากใครเคยใช้โปรโตคอลความเป็นส่วนตัวที่ใช้เทคโนโลยี zero-knowledge (ZK) จะรู้ว่าบน Ethereum การดำเนินการประเภทนี้ใช้ gas อย่างน้อยประมาณ 350,000 หน่วย เนื่องจากการออกแบบโปรโตคอลเหล่านี้หลายตัวไม่มีประสิทธิภาพ บางครั้งต้นทุนจริงอาจสูงถึงประมาณ 1 ล้าน gas ซึ่งแพงมาก ปัจจุบันธุรกรรมปกติอาจมีค่าใช้จ่ายเพียงไม่กี่เซนต์ แต่ธุรกรรมประเภทนี้อาจมีค่าใช้จ่าย 20 เซนต์ หรือแม้แต่ 2 ดอลลาร์

ปัญหาที่ร้ายแรงกว่านั้นคือ หากคุณต้องการทั้งความปลอดภัยเชิงควอนตัมและความเป็นส่วนตัว คุณต้องใช้การพิสูจน์ STARK แทนลายเซ็นแบบเดิม อย่างไรก็ตาม การพิสูจน์ STARK หนึ่งครั้งใช้ gas ประมาณ 8 ล้านหน่วย และอาจมากกว่านั้น นั่นหมายความว่า หากเราบังคับให้ทุกคนใช้ธุรกรรม "ปลอดภัยเชิงควอนตัม + ความเป็นส่วนตัว" ทันที ความสามารถในการประมวลผลของ Ethereum ที่ประมาณ 25 TPS จะลดลงเหลือประมาณ 0.25 TPS ซึ่งแทบจะใช้งานไม่ได้

อีกปัญหาหนึ่งคือ ผู้คนอาจต้องการรองรับรูปแบบการเข้ารหัสแบบกำหนดเอง เช่น เปลี่ยนจาก elliptic curve ในปัจจุบันไปเป็น lattice-based cryptography ในอนาคต ปัญหาคือ ทุกครั้งที่คุณต้องการรองรับรูปแบบใหม่ จะเพิ่มขนาดของโปรโตคอลเอง ต้องใช้ไฟล์ precompute มากขึ้น (ขนาดใหญ่ ต้นทุนสูง) และหากคุณไม่รองรับรูปแบบเหล่านี้ใน EVM โดยตรง หรือไม่มีไฟล์ precompute ที่เกี่ยวข้อง การตรวจสอบลายเซ็นใด ๆ บนเชนจะใช้ gas จำนวนมหาศาล

กล่าวคือ เป้าหมายทั้งหมดของเราในด้านความปลอดภัยและความเป็นส่วนตัว กำลังขัดขวางความสามารถในการปรับขนาด อย่างน้อยก็ด้วยสถาปัตยกรรมปัจจุบัน

วิธีแก้หลัก: ย้ายการคำนวณการรวมกลุ่มไปไว้ใน mempool

แล้วเราจะแก้ปัญหานี้อย่างไร? นี่คือกลไกหลักที่ EIP-8288 นำมาใช้

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

โดยเฉพาะ: เมื่อผู้ใช้ส่งธุรกรรม จะมีกลุ่มโหนดใน mempool ที่ทำงานก่อนที่ธุรกรรมจะถูกบรรจุลงบล็อก โหนดเหล่านี้ทำสิ่งที่เรียกว่า "การรวมกลุ่ม (aggregation)" โดยแทนที่ลายเซ็นและการพิสูจน์จำนวนมากด้วยการพิสูจน์เดียวที่สามารถตรวจสอบได้ว่าลายเซ็นและการพิสูจน์ทั้งหมดมีอยู่จริงและถูกต้อง

ดังนั้นจากมุมมองของผู้ใช้: ผู้ใช้ส่งธุรกรรมพร้อมกับวัตถุขนาดใหญ่ (ลายเซ็น/การพิสูจน์) แต่วัตถุขนาดใหญ่นี้จะไม่ถูกบันทึกลงบนเชนจริง สิ่งที่ถูกบันทึกลงบนเชนจริงมีเพียงการพิสูจน์ STARK เดียวที่ใช้ตรวจสอบว่าลายเซ็นและการพิสูจน์ทั้งหมดในธุรกรรมของผู้ใช้มีอยู่จริงและถูกต้อง

กลไกนี้สร้างขึ้นบน EIP-8141 (native account abstraction) ที่จะนำมาใช้ในการ hard fork ครั้งถัดไป EIP-8141 ผนวกรวมผลงานวิจัยเกือบทศวรรษของชุมชน Ethereum ในด้าน account abstraction โดยอนุญาตให้แต่ละธุรกรรมประกาศองค์ประกอบ ข้อกำหนดลายเซ็น และอัลกอริทึมการตรวจสอบอย่างชัดเจนและแม่นยำ ทำให้ธุรกรรมมีโครงสร้างและความสามารถในการโปรแกรมมากขึ้น

ใน EIP-8288 เราเพิ่มประเภทเฟรม (frame type) ใหม่ ซึ่งสามารถเข้าใจได้ว่าเป็น "dependency" มี dependency สองประเภท: ประเภทหนึ่งสำหรับลายเซ็น และอีกประเภทหนึ่งสำหรับการพิสูจน์ (STARK) ต่างจากรูปแบบปัจจุบันที่ลายเซ็นฝังอยู่ในธุรกรรมโดยตรง ภายใต้กลไกใหม่ ธุรกรรมเองมีเพียงคำประกาศนามธรรมที่ระบุว่าธุรกรรมขึ้นอยู่กับลายเซ็นและการพิสูจน์ประเภทใด เมื่อธุรกรรมถูก broadcast แม้ว่าข้อมูลทั้งหมดจะถูกส่งไปด้วย แต่สิ่งที่ถูกเขียนลงบล็อกเป็นเพียงโครงสร้าง frame ขนาดเล็กที่บรรจุ dependency ข้อมูลของแต่ละ dependency ใช้เพียง 96 ไบต์ ส่วนใหญ่ต่ำถึง 65 ไบต์ เอนทิตีการเข้ารหัสขนาดใหญ่ที่เหลือจะถูกดูดซับและรวมกลุ่มภายใน mempool และสุดท้ายปรากฏบนบัญชีแยกประเภทบล็อกเชนในรูปแบบการพิสูจน์เดียว

ภายใต้สถาปัตยกรรมนี้ โหนดต่าง ๆ ใน mempool จะคอยฟังข้อมูลที่เรียกว่า "envelope" อย่างต่อเนื่อง envelope เดียวสามารถบรรจุธุรกรรมหลายรายการพร้อมการพิสูจน์ที่เกี่ยวข้อง

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

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

สาระสำคัญของสถาปัตยกรรม: "การแบ่งส่วนเฉพาะทาง"

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

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

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

โดยการแยกภาระการตรวจสอบออกไปผ่านการแบ่งส่วน (sharding) ภาระข้อมูลที่ชั้น consensus ของ main chain ต้องให้โหนดตรวจสอบทั้งหมดรับผิดชอบร่วมกันถูกบีบอัดอย่างเข้มงวดให้อยู่ในช่วง 100 ถึง 300 KB ต่อบล็อก ค่าใช้จ่ายนี้ประมาณสองเท่าของปริมาณข้อมูลบล็อก Ethereum ปัจจุบัน และเมื่อปริมาณงานรวมของเครือข่ายขยายตัวเชิงเส้น สัดส่วนของค่าใช้จ่ายคงที่นี้ต่อภาระรวมทั้งหมดจะถูกเจือจางลงเรื่อย ๆ

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

สิ่งนี้หมายความว่าอย่างไรสำหรับ Ethereum?

จากมุมมองทางเทคนิค นี่หมายความว่า Ethereum กำลังทำ hyper-scaling สำหรับการคำนวณบางประเภทโดยเฉพาะ ผมคิดว่านี่เป็นแนวโน้มที่เราจะเห็นมากขึ้นเรื่อย ๆ เมื่อ Ethereum พัฒนาต่อไป

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

ในขณะเดียวกัน เราก็ทำให้การคำนวณที่ต้องประมวลผลด้วยวิธีที่มีประสิทธิภาพต่ำกว่ามีขนาดเล็กลงและจัดการง่ายขึ้น EIP-8288 คือการขยายขนาดพิเศษ (hyper-scaling) สำหรับ "การตรวจสอบลายเซ็น" และ "การตรวจสอบ zero-knowledge proof" โดยเฉพาะ

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

กล่าวคือ ตรรกะการตรวจสอบที่แสดงใน RISC-V ต้องถูกประมวลผลทางกายภาพเพียงครั้งเดียวในเครื่องไคลเอนต์ของผู้ใช้: ผู้ใช้สร้างการพิสูจน์ที่เกี่ยวข้อง (ในกรณีความเป็นส่วนตัวคือ ZK-STARK) แล้วส่งเข้า mempool โหนด relay แรกที่ตามมาจะบีบอัดมันรวมกับการพิสูจน์ที่คล้ายกันหลายร้อยหรือหลายพันรายการทั่วเครือข่ายเป็นเอนทิตีเดียวแบบ recursive

นี่เทียบเท่ากับการแบ่งการคำนวณทั้งหมดออกเป็นสองประเภทใหญ่:

• ประเภทหนึ่งคือ "dependency" ซึ่งเป็นส่วนที่ต้องรับประกันความถูกต้องเพื่อให้ธุรกรรมมีผล
• อีกประเภทหนึ่งคือ "business logic" ซึ่งเป็นสิ่งที่ธุรกรรมทำจริง

ดังนั้น business logic จึงเบาลงและสะอาดขึ้น ซึ่งหมายความว่าตรรกะการสร้างบล็อกที่ขึ้นอยู่กับลำดับธุรกรรมก็จะง่ายขึ้นด้วย ส่วน "dependency" สามารถประมวลผลแบบขนานได้ในระดับมหาศาล โดยแทบไม่ต้องเปลี่ยนแปลงประสบการณ์การพัฒนาของนักพัฒนา Ethereum อย่างมีนัยสำคัญ

คุณค่าเชิงปฏิบัติสำหรับนักพัฒนา ผู้ใช้ และ Layer 2

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

• ค่าใช้จ่ายในการดำเนินการธุรกรรมที่ปลอดภัยเชิงควอนตัมจะถูกบีบอัดจนต่ำมากจนแทบไม่สำคัญ
• แอปพลิเคชันความเป็นส่วนตัวที่สร้างบน zk-SNARK/STARK จะหลุดพ้นจากข้อจำกัดของค่า gas ที่สูง และแพร่หลายด้วยต้นทุนระดับประชาชน พร้อมทั้งต้านทานควอนตัมโดยกำเนิด

นอกเหนือจากกรณีความเป็นส่วนตัว ประสิทธิภาพของ zk-SNARK ในการปรับขนาด (โดยเฉพาะ Layer 2) จะก้าวกระโดดเชิงคุณภาพ ปัจจุบัน ZK-Rollup หลายตัวถูกบังคับให้ยืดรอบการส่งเพื่อกระจายต้นทุน gas ที่สูงในการเผยแพร่ state proof ไปยัง mainnet โดยทำ batch settlement ทุกสิบนาทีหรือแม้แต่ชั่วโมงละครั้ง ซึ่งจำกัดความเร็วในการยืนยันขั้นสุดท้ายอย่างรุนแรงในช่วงที่เครือข่ายมีธุรกรรมน้อย

ปัจจุบัน ZK-Rollup หลายตัวถูกบังคับให้ยืดรอบการส่งเพื่อกระจายต้นทุน gas ที่สูงในการเผยแพร่ state proof ไปยัง mainnet โดยทำ batch settlement ทุกสิบนาทีหรือแม้แต่ชั่วโมงละครั้ง ซึ่งจำกัดความเร็วในการยืนยันขั้นสุดท้ายอย่างรุนแรงในช่วงที่เครือข่ายมีธุรกรรมน้อย

วิวัฒนาการขั้นสุดท้าย: ผลักการคำนวณไปยังขอบ

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

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

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

การมีส่วนร่วมของระบบนิเวศและความคืบหน้าในการนำไปใช้

ปัจจุบัน การสำรวจเบื้องต้นและการตรวจสอบทางวิศวกรรมเกี่ยวกับข้อเสนอนี้กำลังดำเนินไปอย่างเข้มข้น ชุมชนเทคนิคสามารถเข้าร่วมการพัฒนาได้จากหลายจุด:

• แบบจำลองการจำลองระดับเครือข่าย: เครื่องมือจำลองเบื้องต้นสำหรับโทโพโลยี mempool และกลไกการแพร่กระจายการรวมกลุ่มได้เปิดให้ใช้แล้ว
• การดำเนินการ testnet: testnet ที่รองรับ EIP-8141 สำหรับรูปแบบธุรกรรมแบบ frame ได้เริ่มทดสอบแล้ว
• การแข่งขันเพิ่มประสิทธิภาพอัลกอริทึม: การแข่งขันอัลกอริทึมเฉพาะสำหรับชุมชนนักพัฒนากำลังดำเนินอยู่ โดยทุ่มเทการนำระบบพิสูจน์พื้นฐานไปใช้อย่างมีประสิทธิภาพ
• การนำโค้ดไปใช้และการตรวจสอบ: ไลบรารีโค้ดต้นแบบพื้นฐานมีโครงสร้างเบื้องต้นแล้ว สำหรับนักพัฒนาในระบบนิเวศใช้ในการนำไคลเอนต์ไปใช้อย่างอิสระและการตรวจสอบอย่างเป็นทางการ

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