วิธีหนึ่งที่ Ethereum รักษาความปลอดภัยและการกระจายอำนาจที่ไม่ได้รับการกล่าวถึง แต่ก็ยังมีความสำคัญมากคือปรัชญา Multi-Client ของมัน Ethereum โดยเจตนาไม่มี "ไคลเอนต์อ้างอิง" ที่ทุกคนทำงานโดยค่าเริ่มต้น แต่มีข้อกำหนดที่ได้รับการจัดการร่วมกัน (ทุกวันนี้ เขียน ด้วยภาษา Python ที่มนุษย์สามารถอ่านได้มาก แต่ช้ามาก) และมีหลายทีมที่ทำการนำข้อมูลจำเพาะไปใช้ (เช่น เรียกว่า “ลูกค้า”) ซึ่งเป็นสิ่งที่ผู้ใช้ดำเนินการจริง

แต่ละโหนด Ethereum รันไคลเอนต์ที่เป็นเอกฉันท์และไคลเอนต์การดำเนินการ ณ วันนี้ ไม่มีฉันทามติหรือไคลเอ็นต์การดำเนินการใดที่คิดเป็นสัดส่วนมากกว่า 2/3 ของเครือข่าย หากไคลเอนต์ที่มีส่วนแบ่งน้อยกว่า 1/3 ในหมวดหมู่มีข้อบกพร่อง เครือข่ายก็จะดำเนินต่อไปตามปกติ หากลูกค้าที่มีส่วนแบ่งระหว่าง 1/3 ถึง 2/3 ในหมวดหมู่ของตน (เช่น Prysm, Lighthouse หรือ Geth) มีข้อบกพร่อง chain จะเพิ่มบล็อกต่อไป แต่จะหยุดการสรุปบล็อก เพื่อให้มีเวลาสำหรับนักพัฒนาในการแทรกแซง

การเปลี่ยนแปลงครั้งใหญ่ที่จะเกิดขึ้นเกี่ยวกับวิธีการตรวจสอบความถูกต้องของห่วงโซ่ Ethereum สิ่งหนึ่งที่ไม่ได้รับการกล่าวถึง แต่ก็ยังมีความสำคัญมากคือการเพิ่มขึ้นของ ZK-EVM SNARK ที่พิสูจน์ว่าการดำเนินการ EVM อยู่ระหว่างการพัฒนามาหลายปีแล้ว และเทคโนโลยีนี้กำลังถูกใช้งานโดยโปรโตคอลเลเยอร์ 2 ที่เรียกว่า ZK Rollups ZK Rollups เหล่านี้บางส่วน เปิดใช้งาน บน Mainnet แล้วในปัจจุบัน และ จะ มีเพิ่มเติม ในเร็วๆ นี้ แต่ในระยะยาว ZK-EVM ไม่ได้มีไว้สำหรับการโรลอัพเท่านั้น เราต้องการใช้มันเพื่อตรวจสอบการทำงานบนเลเยอร์ 1 เช่นกัน (ดูเพิ่มเติมที่: the Verge)

เมื่อสิ่งนั้นเกิดขึ้น ZK-EVM โดยพฤตินัยจะกลายเป็นไคลเอนต์ Ethereum ประเภทที่สาม ซึ่งมีความสำคัญต่อความปลอดภัยของเครือข่ายพอ ๆ กับไคลเอนต์การดำเนินการและไคลเอนต์ที่เป็นเอกฉันท์ในปัจจุบัน และสิ่งนี้ทำให้เกิดคำถามขึ้นมา: ZK-EVM จะโต้ตอบกับปรัชญาแบบหลายลูกค้าอย่างไร ส่วนที่ยากอย่างหนึ่งได้เสร็จสิ้นไปแล้ว: เรามีการใช้งาน ZK-EVM หลายรายการที่กำลังพัฒนาอย่างจริงจังอยู่แล้ว แต่ส่วนที่ยากอื่น ๆ ยังคงอยู่: เราจะสร้างระบบนิเวศ "หลายลูกค้า" เพื่อการพิสูจน์ความถูกต้องของ ZK ของบล็อก Ethereum ได้อย่างไร คำถามนี้เปิดประเด็นความท้าทายด้านเทคนิคที่น่าสนใจ และแน่นอนว่าคำถามที่ปรากฏขึ้นว่าการแลกเปลี่ยนนั้นคุ้มค่าหรือไม่

อะไรคือแรงจูงใจดั้งเดิมสำหรับปรัชญาหลายลูกค้าของ Ethereum?

ปรัชญาแบบหลายไคลเอนต์ของ Ethereum คือประเภทของการกระจายอำนาจ และเช่นเดียวกับ <a href="https://medium.com/@VitalikButerin/the-meaning-of-decentralization-a0c92b76a274"> การกระจายอำนาจโดยทั่วไป เราสามารถมุ่งเน้นไปที่ ประโยชน์ทางเทคนิคของการกระจายอำนาจทางสถาปัตยกรรมหรือผลประโยชน์ทางสังคมของการกระจายอำนาจทางการเมือง ท้ายที่สุดแล้ว ปรัชญาของลูกค้าหลายรายได้รับแรงบันดาลใจจากทั้งสองฝ่ายและให้บริการทั้งสองอย่าง

ข้อโต้แย้งสำหรับการกระจายอำนาจทางเทคนิค

ประโยชน์หลักของการกระจายอำนาจทางเทคนิคนั้นง่ายมาก: ช่วยลดความเสี่ยงที่จุดบกพร่องในซอฟต์แวร์ชิ้นเดียวจะนำไปสู่การล่มสลายของเครือข่ายทั้งหมด สถานการณ์ในอดีตที่เป็นตัวอย่างความเสี่ยงนี้คือ ข้อผิดพลาด Bitcoin overflow ปี 2010 ในขณะนั้น รหัสไคลเอนต์ Bitcoin ไม่ได้ตรวจสอบว่าผลรวมของผลลัพธ์ของการทำธุรกรรมไม่ล้น (ล้อมรอบเป็นศูนย์โดยการรวมที่สูงกว่าจำนวนเต็มสูงสุดที่ 2⁶⁴−1) และดังนั้นจึงมีคนทำธุรกรรมที่ นั่นเอง โดยให้ bitcoins นับพันล้านแก่ตัวเอง ข้อผิดพลาดถูกค้นพบภายในไม่กี่ชั่วโมง และการแก้ไขก็ดำเนินไปอย่างรวดเร็วและปรับใช้อย่างรวดเร็วทั่วทั้งเครือข่าย แต่หากมีระบบนิเวศที่สมบูรณ์ในเวลานั้น เหรียญเหล่านั้นจะได้รับการยอมรับจากการแลกเปลี่ยน สะพาน และโครงสร้างอื่น ๆ และผู้โจมตีอาจมี หนีไปพร้อมกับเงินจำนวนมาก หากมีไคลเอนต์ Bitcoin ที่แตกต่างกันห้าราย มันไม่น่าจะเป็นไปได้มากที่ไคลเอนต์ทั้งหมดจะมีจุดบกพร่องแบบเดียวกัน ดังนั้นจะต้องมีการแยกส่วนทันที และฝั่งของการแยกที่มีปัญหาก็อาจจะสูญเสียไป

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

แน่นอนว่าฉันไม่เห็นด้วยกับการวิเคราะห์นี้ ประเด็นสำคัญของความขัดแย้งของฉันคือ (i) ข้อบกพร่องร้ายแรงแบบปี 2010 ก็มีความสำคัญเช่นกัน และ (ii) คุณไม่เคยมีลูกค้าเพียงรายเดียวจริงๆ จุดหลังนี้เห็นได้ชัดเจนที่สุดโดย Bitcoin fork ในปี 2013: การแยกลูกโซ่เกิดขึ้นเนื่องจากความขัดแย้งระหว่างไคลเอนต์ Bitcoin สองเวอร์ชันที่แตกต่างกัน ซึ่งหนึ่งในนั้นกลับกลายเป็นว่ามีการจำกัดจำนวนอ็อบเจ็กต์โดยไม่ได้ตั้งใจและไม่มีเอกสารที่สามารถทำได้ ได้รับการแก้ไขในบล็อกเดียว ดังนั้น ลูกค้าในทางทฤษฎีหนึ่งรายมักจะเป็นลูกค้าสองรายในทางปฏิบัติ และลูกค้าห้ารายในทางทฤษฎีอาจเป็นลูกค้าหกหรือเจ็ดรายในทางปฏิบัติ ดังนั้นเราควรกระโดดลงไปทางด้านขวาของเส้นโค้งความเสี่ยง และมีอย่างน้อย ลูกค้าที่แตกต่างกันไม่กี่ราย

ข้อโต้แย้งเพื่อการกระจายอำนาจทางการเมือง

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

ความกังวลเกี่ยวกับการเมืองโปรโตคอล โดยเฉพาะอย่างยิ่งในบริบทของ สงคราม Bitcoin OP_RETURN ในปี 2556-2557 ซึ่งผู้เข้าร่วมบางคนเห็นชอบอย่างเปิดเผยต่อการเลือกปฏิบัติต่อการใช้งานห่วงโซ่โดยเฉพาะ เป็นปัจจัยที่มีส่วนสำคัญในการนำปรัชญาหลายลูกค้ามาใช้ในช่วงแรกของ Ethereum ซึ่ง มีจุดมุ่งหมายเพื่อทำให้กลุ่มเล็กๆ ตัดสินใจแบบนั้นได้ยากขึ้น ข้อกังวลเฉพาะต่อระบบนิเวศ Ethereum กล่าวคือ การหลีกเลี่ยงการรวมตัวของอำนาจภายใน Ethereum Foundation เอง ได้ให้การสนับสนุนเพิ่มเติมสำหรับทิศทางนี้ ในปี 2018 ได้มีการตัดสินใจที่จะจงใจให้มูลนิธิไม่ดำเนินการตามโปรโตคอล Ethereum PoS (เช่น สิ่งที่เรียกว่า "ลูกค้าที่เป็นเอกฉันท์") โดยปล่อยให้งานนั้นตกเป็นหน้าที่ของทีมภายนอกทั้งหมด

ZK-EVM จะเข้ามาอยู่ในเลเยอร์ 1 ได้อย่างไรในอนาคต

ปัจจุบัน ZK-EVM ถูกนำมาใช้ในการยกเลิก สิ่งนี้จะเพิ่มขนาดโดยการอนุญาตให้การดำเนินการ EVM ราคาแพงเกิดขึ้นนอกเครือข่ายเพียงไม่กี่ครั้ง โดยที่คนอื่นๆ เพียงแค่ตรวจสอบ SNARK ที่โพสต์บนเครือข่ายเพื่อพิสูจน์ว่าการดำเนินการ EVM นั้นได้รับการคำนวณอย่างถูกต้อง นอกจากนี้ยังช่วยให้ข้อมูลบางอย่าง (โดยเฉพาะลายเซ็น) ไม่สามารถรวมไว้ในระบบออนไลน์ได้ ซึ่งช่วยประหยัดค่าน้ำมัน สิ่งนี้ทำให้เราได้รับประโยชน์มากมายจากความสามารถในการปรับขนาด และการผสมผสานระหว่างการคำนวณที่ปรับขนาดได้ด้วย ZK-EVM และข้อมูลที่ปรับขนาดได้ด้วย <a href="https://hackmd.io/@vbuterin/sharding_proposal#ELI5-data-availability-sampling"> การสุ่มตัวอย่างความพร้อมใช้งานของข้อมูลสามารถช่วยให้เราขยายขนาดได้ไกลมาก

อย่างไรก็ตาม เครือข่าย Ethereum ในปัจจุบันก็มีปัญหาที่แตกต่างออกไป ปัญหาหนึ่งที่ไม่สามารถปรับขนาดเลเยอร์ 2 ได้ด้วยตัวเอง: เลเยอร์ 1 นั้นตรวจสอบได้ยาก จนถึงจุดที่ผู้ใช้จำนวนไม่มากเรียกใช้โหนดของตนเอง ผู้ใช้ส่วนใหญ่เพียงแค่ไว้วางใจผู้ให้บริการบุคคลที่สามแทน ไคลเอนต์ Light เช่น Helios และ Succinct กำลังดำเนินการแก้ไขปัญหา แต่ไคลเอนต์ light นั้นยังห่างไกลจากโหนดที่มีการตรวจสอบอย่างสมบูรณ์: ไคลเอนต์ light เพียงตรวจสอบลายเซ็นของชุดย่อยของผู้ตรวจสอบแบบสุ่มที่เรียกว่า คณะกรรมการการซิงค์ และไม่ได้ตรวจสอบว่า ห่วงโซ่เป็นไปตามกฎของโปรโตคอลจริงๆ เพื่อนำเราไปสู่โลกที่ผู้ใช้สามารถตรวจสอบได้ว่าห่วงโซ่นั้นเป็นไปตามกฎจริงหรือไม่ เราจะต้องทำอะไรบางอย่างที่แตกต่างออกไป

ตัวเลือกที่ 1: บีบชั้นที่ 1 บังคับให้กิจกรรมเกือบทั้งหมดย้ายไปที่ชั้นที่ 2

เมื่อเวลาผ่านไป เราสามารถลดเป้าหมายก๊าซต่อบล็อกของเลเยอร์ 1 ลงจาก 15 ล้านเป็น 1 ล้าน ซึ่งเพียงพอสำหรับบล็อกที่มี SNARK เดียวและการดำเนินการฝากและถอนเล็กน้อย แต่ไม่มาก และด้วยเหตุนี้จึงบังคับกิจกรรมผู้ใช้เกือบทั้งหมด เพื่อย้ายไปยังโปรโตคอลเลเยอร์ 2 การออกแบบดังกล่าวยังคงสามารถรองรับการโรลอัพจำนวนมากที่เกิดขึ้นในแต่ละบล็อกได้: เราสามารถใช้ โปรโตคอลการรวมกลุ่มแบบออฟไลน์ ที่ดำเนินการโดยผู้สร้างที่ปรับแต่งเองเพื่อรวบรวม SNARK จากโปรโตคอลเลเยอร์ 2 หลายตัวและรวมเข้าด้วยกันเป็น SNARK เดียว ในโลกเช่นนี้ หน้าที่เดียวของเลเยอร์ 1 ก็คือเป็นสำนักหักบัญชีสำหรับโปรโตคอลเลเยอร์ 2 ตรวจสอบหลักฐาน และอำนวยความสะดวกในการโอนเงินจำนวนมากระหว่างกันในบางครั้ง

วิธีการนี้อาจได้ผล แต่มีจุดอ่อนที่สำคัญหลายประการ:

• มันเป็นสิ่งที่เข้ากันไม่ได้แบบย้อนหลังโดยพฤตินัย ในแง่ที่ว่าแอปพลิเคชันที่ใช้ L1 ที่มีอยู่จำนวนมากกลายเป็นสิ่งที่ใช้ไม่ได้ในเชิงเศรษฐกิจ เงินทุนของผู้ใช้ที่มีมูลค่าสูงถึงหลายร้อยหรือหลายพันดอลลาร์อาจติดอยู่เนื่องจากค่าธรรมเนียมสูงมากจนเกินกว่าค่าใช้จ่ายในการล้างบัญชีเหล่านั้น ปัญหานี้สามารถแก้ไขได้โดยการให้ผู้ใช้เซ็นข้อความเพื่อเลือกเข้าร่วมการโยกย้ายจำนวนมากในโปรโตคอลไปยัง L2 ที่พวกเขาเลือก (ดู แนวคิดการใช้งานในช่วงแรก ๆ ที่นี่) แต่การทำเช่นนี้จะเพิ่มความซับซ้อนให้กับการเปลี่ยนแปลง และทำให้ราคาถูกพอที่จะต้องใช้ SNARK บางชนิดที่เลเยอร์ 1 อยู่แล้ว โดยทั่วไปฉันเป็นแฟนตัวยงของการทำลายความเข้ากันได้แบบย้อนหลังเมื่อพูดถึง <a href="https://hackmd.io/@vbuterin/selfdestruct"> สิ่งต่าง ๆ เช่น SELFDESTRUCT opcode แต่ในกรณีนี้ข้อดีข้อเสียดูเหมือนจะไม่ค่อยดีนัก
• มันอาจจะยังทำให้การยืนยันถูกไม่พอ ตามหลักการแล้ว โปรโตคอล Ethereum ควรตรวจสอบได้ง่ายไม่เพียงแต่บนแล็ปท็อปเท่านั้น แต่ยังรวมถึงในโทรศัพท์ ส่วนขยายเบราว์เซอร์ และแม้แต่ในเครือข่ายอื่นๆ การซิงค์ห่วงโซ่เป็นครั้งแรกหรือหลังจากออฟไลน์เป็นเวลานานก็ควรจะเป็นเรื่องง่ายเช่นกัน โหนดแล็ปท็อปสามารถตรวจสอบก๊าซ 1 ล้านครั้งในเวลาประมาณ 20 มิลลิวินาที แต่ถึงแม้จะหมายถึง 54 วินาทีในการซิงค์หลังจากออฟไลน์หนึ่งวัน (สมมติว่า<a href="https://notes.ethereum.org/ @vbuterin /single_slot_finality">เดียว slot Finality จะเพิ่มเวลาของสล็อตเป็น 32 วินาที) และสำหรับโทรศัพท์หรือส่วนขยายเบราว์เซอร์ อาจใช้เวลาสองสามร้อยมิลลิวินาทีต่อบล็อก และอาจยังคงเป็นการสิ้นเปลืองแบตเตอรี่โดยไม่สำคัญ ตัวเลขเหล่านี้สามารถจัดการได้แต่ไม่เหมาะ
• แม้แต่ในระบบนิเวศแรกของ L2 ยังมีประโยชน์ที่ L1 มีราคาไม่แพงนัก Validium จะได้รับประโยชน์จากโมเดลความปลอดภัยที่แข็งแกร่งขึ้น หากผู้ใช้สามารถถอนเงินได้ หากพบว่าไม่มีข้อมูลสถานะใหม่อีกต่อไป การเก็งกำไรจะมีประสิทธิภาพมากขึ้น โดยเฉพาะอย่างยิ่งสำหรับโทเค็นขนาดเล็ก หากขนาดขั้นต่ำของการถ่ายโอนโดยตรงข้าม L2 ที่มีประสิทธิภาพเชิงเศรษฐกิจมีขนาดเล็กลง

ดังนั้นจึงดูสมเหตุสมผลมากกว่าที่จะพยายามหาวิธีใช้ ZK-SNARK เพื่อยืนยันเลเยอร์ 1

ตัวเลือกที่ 2: SNARK-ยืนยันเลเยอร์ 1

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

นี่คือจุดที่เราเห็นจุดตัดกับกระบวนทัศน์แบบหลายไคลเอนต์: หากเราใช้ ZK-EVM เพื่อตรวจสอบเลเยอร์ 1 เราจะใช้ ZK-EVM ใด

ฉันเห็นสามตัวเลือก:

1. ZK-EVM เดี่ยว: ละทิ้งกระบวนทัศน์แบบหลายไคลเอนต์ และเลือก ZK-EVM เดียวที่เราใช้ในการตรวจสอบบล็อก
2. ZK-EVM หลายตัวแบบปิด: ยอมรับและยึดชุด ZK-EVM หลายชุดไว้เป็นเอกฉันท์ และมีกฎโปรโตคอลชั้นฉันทามติที่บล็อกต้องการการพิสูจน์จาก ZK-EVM มากกว่าครึ่งหนึ่งในชุดนั้นจึงถือว่าถูกต้อง .
3. เปิด ZK-EVM หลายตัว: ไคลเอนต์ที่แตกต่างกันมีการใช้งาน ZK-EVM ที่แตกต่างกัน และไคลเอนต์แต่ละรายรอการพิสูจน์ที่เข้ากันได้กับการใช้งานของตัวเองก่อนที่จะยอมรับบล็อกว่าถูกต้อง

สำหรับฉัน (3) ดูเหมือนเหมาะ อย่างน้อยก็จนกว่าและเว้นแต่เทคโนโลยีของเราจะปรับปรุงจนถึงจุดที่เราสามารถ พิสูจน์ได้อย่างเป็นทางการ ว่าการใช้งาน ZK-EVM ทั้งหมดเทียบเท่ากัน ณ จุดนี้เราสามารถเลือกได้ว่าอันไหนดีที่สุด มีประสิทธิภาพ. (1) จะเสียสละประโยชน์ของกระบวนทัศน์แบบหลายลูกค้า และ (2) จะปิดความเป็นไปได้ในการพัฒนาลูกค้าใหม่และนำไปสู่ระบบนิเวศแบบรวมศูนย์มากขึ้น (3) มีความท้าทาย แต่ความท้าทายเหล่านั้นดูเหมือนจะเล็กกว่าความท้าทายของอีกสองทางเลือก อย่างน้อยก็ในตอนนี้

การใช้งาน (3) จะไม่ยากเกินไป: อาจมีเครือข่ายย่อย p2p สำหรับการพิสูจน์แต่ละประเภท และไคลเอนต์ที่ใช้การพิสูจน์ประเภทหนึ่งจะรับฟังบนเครือข่ายย่อยที่เกี่ยวข้องและรอจนกว่าพวกเขาจะได้รับหลักฐานว่า ผู้ตรวจสอบยอมรับว่าถูกต้อง

ความท้าทายหลักสองประการของ (3) มีแนวโน้มดังต่อไปนี้:

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

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

ปัญหาประสิทธิภาพของข้อมูลจะต้องได้รับการแก้ไขโดยมีโปรโตคอลแยกต่างหากสำหรับรวบรวมข้อมูลที่เกี่ยวข้องกับการตรวจสอบ สำหรับลายเซ็น เราสามารถใช้ BLS aggregation ซึ่ง ERC-4337 รองรับแล้ว ข้อมูลที่เกี่ยวข้องกับการตรวจสอบหลักอีกประเภทหนึ่งคือ ZK-SNARK ที่ใช้เพื่อความเป็นส่วนตัว โชคดีที่สิ่งเหล่านี้มัก มีโปรโตคอลการรวมเป็นของตัวเอง

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

ข้อสรุป

การทำให้ระบบนิเวศ ZK-EVM แบบหลายไคลเอนต์แบบเปิดทำงานได้ดีจะต้องทำงานหนักมาก แต่ข่าวดีก็คือว่างานนี้ส่วนใหญ่กำลังเกิดขึ้นหรือจะเกิดขึ้นต่อไป:

• เรา มีการใช้งาน ZK-EVM ที่แข็งแกร่ง หลายรายการ แล้ว การใช้งานเหล่านี้ยังไม่ใช่ ประเภท 1 (เทียบเท่ากับ Ethereum โดยสมบูรณ์) แต่ส่วนใหญ่กำลังเคลื่อนไหวไปในทิศทางนั้น
• การทำงานกับไคลเอนต์แบบ light เช่น Helios และ Succinct อาจกลายเป็นการตรวจสอบ SNARK ที่สมบูรณ์ยิ่งขึ้นของด้านฉันทามติ PoS ของ Ethereum chain ในที่สุด
• ลูกค้ามีแนวโน้มที่จะเริ่มทดลองใช้ ZK-EVM เพื่อพิสูจน์การดำเนินการบล็อก Ethereum ด้วยตนเอง โดยเฉพาะอย่างยิ่งเมื่อเรามี ไคลเอ็นต์ไร้สถานะ และไม่มีความจำเป็นทางเทคนิคในการดำเนินการซ้ำทุกบล็อกโดยตรงเพื่อรักษาสถานะ เราอาจจะได้รับการเปลี่ยนแปลงอย่างช้าๆ และค่อยเป็นค่อยไปจากลูกค้าที่ตรวจสอบการบล็อก Ethereum โดยดำเนินการใหม่ไปยังลูกค้าส่วนใหญ่ที่ตรวจสอบการบล็อก Ethereum โดยการตรวจสอบการพิสูจน์ SNARK
• ระบบนิเวศ ERC-4337 และ PBS มีแนวโน้มที่จะเริ่มทำงานกับเทคโนโลยีการรวมกลุ่ม เช่น BLS และการรวมการพิสูจน์ในเร็วๆ นี้ เพื่อประหยัดต้นทุนก๊าซ ในการรวม BLS งานได้เริ่มต้นแล้ว

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

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

ในระยะอันใกล้นี้ ยังคงเป็นการเดินทางที่ยาวนาน ZK-EVM มาถึงแล้ว แต่ ZK-EVM ที่จะสามารถทำงานได้อย่างแท้จริงในเลเยอร์ 1 จะต้องให้พวกมันกลายเป็นประเภท 1 และต้องพิสูจน์ให้เร็วพอที่จะสามารถเกิดขึ้นได้แบบเรียลไทม์ ด้วยการขนานกันที่เพียงพอ สิ่งนี้ก็สามารถทำได้ แต่ก็ยังมีงานอีกมากที่จะต้องไปถึงจุดนั้น การเปลี่ยนแปลงที่เป็นเอกฉันท์ เช่น การเพิ่มต้นทุนก๊าซของ KECCAK, SHA256 และพรีคอมไพล์ฟังก์ชันแฮชอื่นๆ ก็จะเป็นส่วนสำคัญของภาพเช่นกัน อย่างไรก็ตาม ขั้นตอนแรกของการเปลี่ยนแปลงอาจเกิดขึ้นเร็วกว่าที่เราคาดไว้: เมื่อเราเปลี่ยนไปใช้ Verkle tree และไคลเอนต์ไร้สัญชาติ ลูกค้าสามารถเริ่มใช้ ZK-EVM แบบค่อยเป็นค่อยไป และการเปลี่ยนไปใช้โลก "open multi-ZK-EVM" สามารถทำได้ เริ่มเกิดขึ้นทั้งหมดด้วยตัวมันเอง

ข้อสงวนสิทธิ์：

1. บทความนี้พิมพ์ซ้ำจาก [vitalik] ลิขสิทธิ์ทั้งหมดเป็นของผู้เขียนต้นฉบับ [vitalik] หากมีการคัดค้านการพิมพ์ซ้ำนี้ โปรดติดต่อทีมงาน Gate Learn แล้วพวกเขาจะจัดการโดยเร็วที่สุด
2. การปฏิเสธความรับผิด: มุมมองและความคิดเห็นที่แสดงในบทความนี้เป็นเพียงของผู้เขียนเท่านั้น และไม่ถือเป็นคำแนะนำในการลงทุนใดๆ
3. การแปลบทความเป็นภาษาอื่นดำเนินการโดยทีมงาน Gate Learn เว้นแต่จะกล่าวถึง ห้ามคัดลอก แจกจ่าย หรือลอกเลียนแบบบทความที่แปลแล้ว