ชื่อเดิม:Should Ethereum be okay with enshrining more things in the protocol?

ผู้เขียนต้นฉบับ: Vitalik Buterin

นักแปล Odaily - Nian Yin Si Tang

ขอขอบคุณเป็นพิเศษสำหรับ Justin Drake, Tina Zhen และ Yoav Weiss สำหรับคำติชมและบทวิจารณ์

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

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

ปรัชญายุคแรกเกี่ยวกับความเรียบง่ายของโปรโตคอล

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

นี่เป็นการสร้างขึ้นใหม่โดยประมาณของไดอะแกรมไวท์บอร์ดที่ Gavin Wood และฉันวาดเมื่อต้นปี 2015 เมื่อฉันพูดถึงว่า Ethereum 2.0 จะมีหน้าตาเป็นอย่างไร

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

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

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

มีรหัสสำเร็จรูปจำนวนมากระหว่างการประมวลผลธุรกรรมและทำการเรียก EVM จริงจากที่อยู่ผู้ส่ง และรหัสสำเร็จรูปเพิ่มเติมหลังจากนั้น เราจะลดรหัสนี้ให้ใกล้ศูนย์มากที่สุดได้อย่างไร

หนึ่งในโค้ดหลักที่นี่คือ validate_transaction(state, tx) ซึ่งมีหน้าที่ตรวจสอบว่า nonce และลายเซ็นของธุรกรรมนั้นถูกต้อง เป้าหมายที่แท้จริงของการลบบัญชีตั้งแต่ต้นคือการอนุญาตให้ผู้ใช้สามารถแทนที่การตรวจสอบแบบพื้นฐานแบบไม่เพิ่มหน่วยและการตรวจสอบ ECDSA ด้วยตรรกะการตรวจสอบของตนเอง เพื่อให้ผู้ใช้สามารถใช้คุณสมบัติต่างๆ เช่น การกู้คืนทางสังคมและกระเป๋าสตางค์แบบหลายลายเซ็นได้ง่ายขึ้น ดังนั้นการค้นหาวิธีปรับโครงสร้าง Apply_transaction เป็นการเรียก EVM แบบง่ายๆ ไม่ใช่แค่งาน ทำให้โค้ดสะอาดเพื่อประโยชน์ในการทำให้โค้ดสะอาด แต่เป็นเรื่องเกี่ยวกับการย้ายตรรกะไปยังโค้ดบัญชีของผู้ใช้ ให้ความยืดหยุ่นแก่ผู้ใช้ที่พวกเขาต้องการ

อย่างไรก็ตาม การยืนยันว่า Apply_transaction มีตรรกะคงที่น้อยที่สุดเท่าที่จะเป็นไปได้ กลับกลายเป็นการสร้างความท้าทายมากมาย เราสามารถดูข้อเสนอนามธรรมบัญชีที่เก่าแก่ที่สุดรายการหนึ่งได้ นั่นคือ EIP-86

หากรวม EIP-86 ไว้ตามที่เป็นอยู่ มันจะลดความซับซ้อนของ EVM ด้วยต้นทุนในการเพิ่มความซับซ้อนของส่วนอื่นๆ ของ Ethereum Stack อย่างมหาศาล โดยกำหนดให้ต้องเขียนโค้ดเดียวกันที่อื่นเป็นหลัก นอกเหนือจากการแนะนำทั้งหมด ความแปลกประหลาดระดับใหม่ ตัวอย่างเช่น ธุรกรรมเดียวกันที่มีค่าแฮชเดียวกันอาจปรากฏขึ้นหลายครั้งในห่วงโซ่

ปัญหาการทำให้ใช้ไม่ได้หลายอย่างในการสรุปบัญชี ธุรกรรมหนึ่งรายการที่รวมอยู่ใน on-chain อาจทำให้ธุรกรรมอื่น ๆ นับพันรายการใน mempool เป็นโมฆะ ทำให้ง่ายสำหรับ mempool ที่จะถูกเติมเต็มอย่างถูก

ตั้งแต่นั้นมา การแยกบัญชีได้พัฒนาไปเป็นขั้นๆ EIP-86 ต่อมากลายเป็น EIP-208 และในที่สุดก็กลายเป็น EIP-2938 ที่ใช้งานได้จริง

อย่างไรก็ตาม EIP-2938 นั้นเป็นอะไรที่มินิมอลลิสต์ เนื้อหาประกอบด้วย:

• ประเภทธุรกรรมใหม่

• ตัวแปรระดับโลกขอบเขตธุรกรรมใหม่สามตัว

• opcode ใหม่สองตัว รวมถึง opcode PAYgas ที่ยุ่งยากมากเพื่อจัดการราคาก๊าซและการตรวจสอบขีดจำกัดของก๊าซ เป็นจุดพักการดำเนินการ EVM และจัดเก็บ ETH ชั่วคราวสำหรับการชำระค่าธรรมเนียมครั้งเดียว

• ชุดกลยุทธ์การขุดและการออกอากาศซ้ำที่ซับซ้อน รวมถึงรายการ opcodes ที่ต้องห้ามในระหว่างขั้นตอนการตรวจสอบธุรกรรม

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

ERC-4337. มันขึ้นอยู่กับการโทร EVM โดยสิ้นเชิง!

เนื่องจากนี่คือ ERC จึงไม่จำเป็นต้องมีฮาร์ดฟอร์ก และในทางเทคนิคแล้วมีอยู่ นอกโปรโตคอล Ethereum ดังนั้น...ปัญหาได้รับการแก้ไขแล้วใช่ไหม? ปรากฎว่าไม่เป็นเช่นนั้น แผนงานระยะกลางปัจจุบันสำหรับ ERC-4337 จริงๆ แล้วเกี่ยวข้องกับการเปลี่ยนส่วนใหญ่ของ ERC-4337 ไปเป็นชุดคุณลักษณะโปรโตคอล ซึ่งเป็นตัวอย่างที่เป็นประโยชน์ของคำแนะนำว่าเหตุใดจึงควรพิจารณาเส้นทางนี้

แพ็คเกจ ERC-4337

มีเหตุผลสำคัญหลายประการที่มีการพูดคุยกันเพื่อนำ ERC-4337 กลับเข้าสู่โปรโตคอลในที่สุด:

• ประสิทธิภาพของแก๊ส: การดำเนินการใดๆ ที่ทำภายใน EVM จะทำให้เครื่องเสมือนมีค่าใช้จ่ายในระดับหนึ่ง ซึ่งรวมถึงความไร้ประสิทธิภาพเมื่อใช้ฟีเจอร์ที่มีราคาแพง เช่น ช่องจัดเก็บข้อมูล ในปัจจุบัน ความไร้ประสิทธิภาพเพิ่มเติมเหล่านี้รวมกันได้อย่างน้อย 20,000 ก๊าซ หากไม่มากกว่านั้น การใส่ส่วนประกอบเหล่านี้ลงในโปรโตคอลเป็นวิธีที่ง่ายที่สุดในการขจัดปัญหาเหล่านี้

• ความเสี่ยงจากข้อผิดพลาดของโค้ด: หาก “สัญญาจุดเข้าใช้งาน” ของ ERC-4337 มีข้อผิดพลาดที่น่ากลัวเพียงพอ กระเป๋าเงินที่รองรับ ERC-4337 ทั้งหมดจะเห็นว่าเงินทั้งหมดของพวกเขาหมดลง การแทนที่สัญญาด้วยฟังก์ชันการทำงานในโปรโตคอลจะสร้างข้อผูกมัดโดยนัยในการแก้ไขจุดบกพร่องของโค้ดผ่านการฮาร์ดฟอร์ก ซึ่งจะช่วยลดความเสี่ยงที่ผู้ใช้จะขาดแคลนเงินทุน

• รองรับรหัส EVMเช่น txt.origin ERC-4337 เองทำให้ txt.origin ส่งคืนที่อยู่ของ bundler ที่รวมชุดการกระทำของผู้ใช้ไว้ในธุรกรรม นามธรรมบัญชีดั้งเดิมแก้ปัญหานี้โดยทำให้ txt.origin ชี้ไปที่บัญชีจริงที่ส่งธุรกรรม ทำให้ทำงานเหมือนกับ EOA

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

เป็นที่น่าสังเกตว่าในรูปแบบปัจจุบัน ERC-4337 มีราคาแพงกว่าธุรกรรม Ethereum “พื้นฐาน” อย่างมาก: ธุรกรรมมีค่าใช้จ่าย 21,000 gas ในขณะที่ ERC-4337 มีราคาประมาณ 42,000 gas

ตามทฤษฎี ควรเป็นไปได้ที่จะปรับระบบต้นทุนก๊าซ EVM จนกว่าต้นทุนในโปรโตคอลและต้นทุนในการเข้าถึงพื้นที่เก็บข้อมูลภายนอกโปรโตคอลจะตรงกัน ไม่มีเหตุผลที่จะต้องใช้แก๊ส 9,000 เพื่อถ่ายโอน ETH เมื่อแก้ไขพื้นที่เก็บข้อมูลประเภทอื่น การดำเนินงานมีราคาถูกกว่า ในความเป็นจริง EIP สองตัวที่เกี่ยวข้องกับการเปลี่ยนแปลงแผนผัง Verkle ที่กำลังจะมาถึงนั้น จริงๆ แล้วพยายามที่จะทำเช่นนั้น แต่ถึงแม้ว่าเราจะทำเช่นนั้น ก็มีเหตุผลที่ชัดเจนว่าทำไมไม่ว่า EVM จะมีประสิทธิภาพเพียงใด ฟังก์ชันโปรโตคอลแบบห่อหุ้มจะมีราคาถูกกว่าโค้ด EVM อย่างหลีกเลี่ยงไม่ได้ โค้ดแบบห่อหุ้มไม่จำเป็นต้องจ่ายค่าน้ำมันสำหรับการโหลดล่วงหน้า

กระเป๋าเงิน ERC-4337 ที่ทำงานได้อย่างสมบูรณ์มีขนาดใหญ่ โดยการใช้งานนี้รวบรวมและวางบนเชนโดยใช้พื้นที่ประมาณ 12,800 ไบต์ แน่นอน คุณสามารถปรับใช้โค้ดนี้เพียงครั้งเดียวและใช้ DELEGATECALL เพื่ออนุญาตให้กระเป๋าเงินแต่ละใบเรียกรหัสได้ แต่คุณยังคงต้องเข้าถึงรหัสในทุกบล็อกที่มีการใช้งาน ภายใต้ต้นทุน EIP ของ Verkle tree gas นั้น 12,800 ไบต์จะสร้าง 413 ชิ้น การเข้าถึงชิ้นส่วนเหล่านี้จะต้องจ่าย 2 เท่าของ allowance branch_cost (รวมเป็น 3,800 gas) และ 413 เท่าของ allowance chunk_cost (รวม 82,600 gas) นั่นไม่ได้เริ่มพูดถึงจุดเข้าใช้งาน ERC-4337 ด้วยซ้ำ ซึ่งในเวอร์ชัน 0.6.0 มี 23,689 ไบต์แบบออนไลน์ (ประมาณ 158,700 ก๊าซที่จะโหลดตามกฎ Verkle tree EIP)

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

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

ในตัวอย่างนี้ เราเห็นเหตุผลที่แตกต่างกันบางประการสำหรับการสรุปสรุปบัญชีในโปรโตคอล

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

• การตอบสนองทั่วทั้งชุมชนต่อข้อบกพร่องของโค้ดหากผู้ใช้ทุกคนหรือผู้ใช้ในวงกว้างใช้โค้ดบางโค้ด มักจะสมเหตุสมผลกว่าที่ชุมชนบล็อกเชนจะต้องรับผิดชอบในการฮาร์ดฟอร์คเพื่อแก้ไขข้อบกพร่องใดๆ ที่เกิดขึ้น ERC-4337 นำเสนอโค้ดที่แชร์ทั่วโลกจำนวนมาก และในระยะยาว การแก้ไขจุดบกพร่องในโค้ดผ่านการฮาร์ดฟอร์กย่อมสมเหตุสมผลกว่าการทำให้ผู้ใช้สูญเสีย ETH จำนวนมากอย่างไม่ต้องสงสัย

• บางครั้ง รูปแบบที่แข็งแกร่งของโปรโตคอลสามารถนำไปใช้ได้โดยการใช้ประโยชน์จากฟังก์ชันการทำงานโดยตรงตัวอย่างสำคัญที่นี่คือคุณสมบัติป้องกันการเซ็นเซอร์ภายในโปรโตคอล เช่น รวมรายการ: รายการรวมในโปรโตคอลสามารถรับประกันการต่อต้านการเซ็นเซอร์ได้ดีกว่าวิธีนอกโปรโตคอล เพื่อให้การดำเนินงานระดับผู้ใช้ได้รับประโยชน์อย่างแท้จริงจากในโปรโตคอล รวมรายการ การดำเนินการระดับผู้ใช้แต่ละรายจำเป็นต้องมี ความชัดเจน ในโปรโตคอล อีกตัวอย่างที่ไม่ค่อยมีใครรู้จักคือการออกแบบ Ethereum Proof-of-Stake ในยุคปี 2017 มีบัญชีที่เป็นนามธรรมของ Stake Key ซึ่งถูกละทิ้งเพื่อสนับสนุน BLS แบบห่อหุ้ม เนื่องจาก BLS สนับสนุนกลไก การรวมกลุ่ม ที่ต้องดำเนินการที่โปรโตคอลและ ระดับเครือข่าย ทำให้การประมวลผลลายเซ็นจำนวนมากมีประสิทธิภาพมากขึ้น

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

เรามาดูรายละเอียดเพิ่มเติมโดยดูตัวอย่างคุณลักษณะอื่นๆ ที่เพิ่งได้รับการพิจารณาสำหรับการห่อหุ้มเมื่อเร็วๆ นี้ เราจะให้ความสนใจเป็นพิเศษกับ:ZK-EVM, การแยกผู้เสนอ-ผู้สร้าง, พูลหน่วยความจำส่วนตัว, การปักหลักสภาพคล่อง และการคอมไพล์ล่วงหน้าใหม่。

แพ็คเกจ ZK-EVM

เรามาดูเป้าหมายการห่อหุ้มที่เป็นไปได้อีกประการหนึ่งสำหรับโปรโตคอล Ethereum: ZK-EVM ขณะนี้ เรามี ZK-rollup จำนวนมากที่ทุกคนต้องเขียนโค้ดที่ค่อนข้างคล้ายกันเพื่อตรวจสอบการดำเนินการของบล็อก Ethereum ที่คล้ายกันใน ZK-SNARK มีระบบนิเวศที่ค่อนข้างหลากหลายสำหรับการใช้งานอิสระ: PSE ZK-EVM, Kakarot, Polygon ZK-EVM, Linea, Zeth และอื่นๆ อีกมากมาย

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

ในระยะกลาง การยกเลิกมีแนวโน้มที่จะอาศัยระบบการรับรองหลายระบบ โดยคณะมนตรีความมั่นคงจะมีอำนาจเฉพาะในกรณีร้ายแรงเท่านั้นที่ระบบการรับรองที่แตกต่างกันสองระบบแตกต่างกัน

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

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

นี่เป็นหัวข้อที่สำคัญและท้าทาย

หัวข้ออภิปรายการที่เป็นไปได้ประการหนึ่งเกี่ยวกับความพร้อมใช้งานของข้อมูลใน ZK-EVM ดั้งเดิมคือความเป็นสถานะ ZK-EVM จะให้ข้อมูลมีประสิทธิภาพมากขึ้นหากไม่จำเป็นต้องพกพาข้อมูล พยาน นั่นคือ หากมีการอ่านหรือเขียนข้อมูลชิ้นใดชิ้นหนึ่งไปแล้วในบล็อกก่อนหน้า เราก็สามารถสันนิษฐานได้ว่าผู้พิสูจน์สามารถเข้าถึงข้อมูลนั้นได้ และไม่จำเป็นต้องทำให้ข้อมูลนั้นพร้อมใช้งานอีกครั้ง ไม่ใช่แค่การไม่โหลดพื้นที่เก็บข้อมูลและโค้ดซ้ำเท่านั้น ปรากฎว่าหาก Rollup บีบอัดข้อมูลอย่างถูกต้อง การบีบอัดแบบ stateful จะสามารถบันทึกข้อมูลได้มากถึง 3 เท่า เมื่อเทียบกับการบีบอัดแบบ stateless

ซึ่งหมายความว่าสำหรับการคอมไพล์ล่วงหน้าของ ZK-EVM เรามีสองตัวเลือก:

1.การคอมไพล์ล่วงหน้าต้องการให้ข้อมูลทั้งหมดอยู่ในบล็อกเดียวกัน. ซึ่งหมายความว่าตัวพิสูจน์สามารถไร้สถานะได้ แต่ก็หมายความว่าการใช้ ZK-rollup ที่คอมไพล์ไว้ล่วงหน้านี้มีราคาแพงกว่าการใช้โค้ดที่กำหนดเองสำหรับการยกเลิกมาก

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

เราเรียนรู้อะไรได้บ้างจากสิ่งนี้? มีเหตุผลที่ดีที่จะสรุปการตรวจสอบ ZK-EVM ในทางใดทางหนึ่ง: rollup กำลังสร้างเวอร์ชันที่กำหนดเองของตัวเองแล้ว และ Ethereum ยินดีที่จะใช้งาน EVM บน L1 โดยมีน้ำหนักของการใช้งานที่หลากหลายและความเห็นพ้องต้องกันทางสังคมแบบ off-chain สิ่งนี้ให้ความรู้สึกนี้ ผิด แต่ L2 ที่ทำงานเดียวกันเป๊ะๆ จะต้องใช้เครื่องมือที่ซับซ้อนที่เกี่ยวข้องกับคณะมนตรีความมั่นคง แต่ในทางกลับกัน มีรายละเอียดที่น่าสนใจมาก: ZK-EVM มีเวอร์ชันต่างๆ กัน โดยมีต้นทุนและผลประโยชน์ต่างกัน ความแตกต่างระหว่าง stateful และ stateless เพียงแต่ทำให้พื้นผิวเสียหายเท่านั้น ความพยายามที่จะสนับสนุนโค้ดแบบกำหนดเอง เกือบ EVM ที่ได้รับการพิสูจน์โดยระบบอื่นอาจทำให้พื้นที่การออกแบบมีขนาดใหญ่ขึ้น ดังนั้น,บรรจุภัณฑ์ ZK-EVM นำมาซึ่งทั้งคำมั่นสัญญาและความท้าทาย。

ผู้เสนอการห่อหุ้มและการแยกตัวสร้าง (ePBS)

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

อย่างไรก็ตาม MEV-Boost สร้างสมมติฐานความน่าเชื่อถือในนักแสดงประเภทใหม่ที่เรียกว่ารีเลย์ ในช่วงสองปีที่ผ่านมา มีข้อเสนอมากมายในการสร้าง Packaged PBS ประโยชน์ของการทำเช่นนี้คืออะไร? ในกรณีนี้ คำตอบนั้นง่ายมาก: PBS ที่สร้างขึ้นโดยใช้คุณสมบัติโปรโตคอลโดยตรงจะมีประสิทธิภาพมากกว่า (ในแง่ของสมมติฐานด้านความน่าเชื่อถือที่อ่อนแอกว่า) มากกว่า PBS ที่สร้างขึ้นโดยไม่ใช้งาน สิ่งนี้คล้ายกับกรณีของการห่อหุ้มราคา oracles ภายในโปรโตคอล - แม้ว่าในกรณีนี้จะมีการคัดค้านอย่างรุนแรงก็ตาม

แค็ปซูลพูลหน่วยความจำส่วนตัว

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

เมื่อเร็ว ๆ นี้ มีหลายโครงการที่อุทิศให้กับการสร้าง mempools ส่วนตัว (หรือ mempools ของ crypto) ซึ่งจะเข้ารหัสธุรกรรมของผู้ใช้จนกว่าจะได้รับการยอมรับอย่างถาวรในบล็อก

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

มีเทคนิคต่างๆ มากมายที่มีข้อดีต่างกันเพื่อใช้การเข้ารหัสรูปแบบนี้ Jon Charbonneau เคยอธิบายไว้อย่างดีว่า:

• การเข้ารหัสตัวดำเนินการแบบรวมศูนย์เช่น Flashbots Protect。

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

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

• ฮาร์ดแวร์ที่เชื่อถือได้เช่น SGX

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

การวางเดิมพันสภาพคล่องแบบห่อหุ้ม

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

อินเทอร์เฟซ การปักหลักที่ง่ายที่สุดที่ตรงกับความต้องการทั้งสองนี้เป็นเพียงโทเค็น ERC 20: แปลง ETH ของคุณเป็น การปักหลัก ETH ค้างไว้แล้วแปลงกลับ ในความเป็นจริง ผู้ให้บริการเดิมพันสภาพคล่องเช่น Lido และ Rocket Pool กำลังทำเช่นนี้อยู่แล้ว อย่างไรก็ตาม มีกลไกการรวมศูนย์ตามธรรมชาติบางประการที่เล่นกับการวางเดิมพันสภาพคล่อง ผู้คนจะเข้าสู่การวางเดิมพัน ETH เวอร์ชันที่ใหญ่ที่สุดโดยธรรมชาติ เนื่องจากเป็นเวอร์ชันที่คุ้นเคยและมีสภาพคล่องมากที่สุด

แต่ละเวอร์ชันของ Stake ETH จำเป็นต้องมีกลไกบางอย่างในการพิจารณาว่าใครสามารถเป็นผู้ดำเนินการโหนดพื้นฐานได้ ไม่สามารถไม่จำกัดได้เนื่องจากผู้โจมตีจะเข้าร่วมและใช้เงินทุนของผู้ใช้เพื่อขยายการโจมตี ปัจจุบัน สองอันดับแรกคือ Lido ซึ่งมีผู้ดำเนินการโหนดที่ได้รับอนุญาตจาก DAO และ Rocket Pool ซึ่งอนุญาตให้ทุกคนเรียกใช้โหนดด้วยเงินฝาก 8 ETH ทั้งสองวิธีมีความเสี่ยงที่แตกต่างกัน: วิธี Rocket Pool ช่วยให้ผู้โจมตีทำการโจมตีเครือข่ายได้ 51% และบังคับให้ผู้ใช้จ่ายค่าใช้จ่ายส่วนใหญ่ สำหรับวิธี DAO หากโทเค็นที่เดิมพันบางส่วนครอบงำ ก็จะนำไปสู่ อุปกรณ์กำกับดูแลเดียวที่อาจถูกบุกรุกจะควบคุมส่วนใหญ่ของเครื่องมือตรวจสอบความถูกต้องของ Ethereum ทั้งหมด เพื่อเครดิต โปรโตคอลอย่าง Lido มีระบบป้องกันอยู่แล้ว แต่การป้องกันชั้นเดียวอาจไม่เพียงพอ

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

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

แนวคิดที่น่าสนใจคือบทความของ Dankrad Feist เกี่ยวกับการเพิ่มการวางเดิมพันสภาพคล่องสูงสุด ก่อนอื่น เรามากัดกระสุนกันก่อนและสมมติว่าหาก Ethereum ถูกโจมตี 51% ETH ที่ถูกโจมตีเพียง 5% เท่านั้นที่อาจถูกเฉือน นี่เป็นการแลกเปลี่ยนที่สมเหตุสมผล เนื่องจากปัจจุบันมีการเดิมพัน ETH มากกว่า 26 ล้าน ETH ค่าใช้จ่ายในการโจมตีหนึ่งในสามของจำนวนนั้น (ประมาณ 8 ล้าน ETH) จึงสูงเกินไป โดยเฉพาะอย่างยิ่งเมื่อพิจารณาว่าการโจมตี นอกรูปแบบ สามารถทำได้กี่ครั้งใน ต้นทุนที่ต่ำกว่า ในความเป็นจริง การแลกเปลี่ยนที่คล้ายคลึงกันได้รับการสำรวจแล้วในข้อเสนอ คณะกรรมการขั้นสูง เพื่อดำเนินการขั้นสุดท้ายของช่องเดียว

หากเรายอมรับว่ามีเพียง 5% ของการโจมตี ETH เท่านั้นที่ถูกเฉือน ดังนั้นมากกว่า 90% ของ ETH ที่เดิมพันจะไม่ได้รับผลกระทบจากการโจมตีดังกล่าว ดังนั้นจึงสามารถใช้เป็นโทเค็นการปักหลักของเหลวที่เปลี่ยนได้ภายในโปรโตคอล ซึ่งจากนั้นสามารถใช้งานได้โดย แอปพลิเคชันอื่น ๆ

เส้นทางนี้น่าสนใจ แต่ก็ยังมีคำถามอยู่ข้อหนึ่งว่าแท้จริงแล้วห่อหุ้มอะไรกันแน่?Rocket Pool ทำงานคล้ายกันมาก: ผู้ดำเนินการโหนดแต่ละรายจะจัดสรรเงินทุนบางส่วน และผู้เดิมพันสภาพคล่องจะจัดสรรส่วนที่เหลือ เราสามารถปรับค่าคงที่เพื่อจำกัดการลงโทษสูงสุดที่ 2 ETH และ rETH ที่มีอยู่ของ Rocket Pool จะปราศจากความเสี่ยง

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

แค็ปซูลการคอมไพล์ล่วงหน้าเพิ่มเติม

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

ขณะนี้มีการผลักดันให้เพิ่มการคอมไพล์ล่วงหน้าสำหรับ secp 256 r 1 ซึ่งเป็นเส้นโค้งรูปไข่ที่แตกต่างกันเล็กน้อยจาก secp 256 k 1 ที่ใช้สำหรับบัญชี ethereum พื้นฐาน ซึ่งใช้กันอย่างแพร่หลายเนื่องจากได้รับการสนับสนุนอย่างดีจากโมดูลฮาร์ดแวร์ที่เชื่อถือได้ ใช้เพื่อเพิ่มความปลอดภัยของกระเป๋าเงิน ในช่วงไม่กี่ปีที่ผ่านมา ชุมชนยังได้ผลักดันให้เพิ่มการคอมไพล์ล่วงหน้าสำหรับ BLS-12-377, BW 6-761, การจับคู่ทั่วไป และคุณสมบัติอื่นๆ

ข้อโต้แย้งของการเรียกพรีคอมไพเลอร์เหล่านี้เพิ่มเติมก็คือพรีคอมไพเลอร์จำนวนมากที่เพิ่มไว้ก่อนหน้านี้ (เช่น RIPEMD และ BLAKE) ลงเอยด้วยการใช้น้อยกว่าที่คาดไว้มาก และเราควรเรียนรู้จากสิ่งนี้ แทนที่จะเพิ่มการคอมไพล์ล่วงหน้าเพิ่มเติมสำหรับการดำเนินการเฉพาะ เราควรมุ่งเน้นไปที่แนวทางที่นุ่มนวลกว่าโดยอิงตามแนวคิดเช่น EVM-MAX และข้อเสนอ SIMD แบบ Hibernate-But-Always-Resumable ซึ่งจะทำให้การใช้งาน EVM ทำงานด้วยต้นทุนที่ต่ำกว่า ค่าใช้จ่ายในการดำเนินการ คลาสโค้ดที่หลากหลาย บางทีแม้แต่การคอมไพล์ล่วงหน้าที่ใช้น้อยที่มีอยู่ก็สามารถลบออกและแทนที่ด้วยการใช้โค้ด EVM (มีประสิทธิภาพน้อยกว่าอย่างหลีกเลี่ยงไม่ได้) ของฟังก์ชันเดียวกัน ถึงกระนั้นก็ยังเป็นไปได้ที่จะมีการดำเนินการเข้ารหัสลับบางอย่างที่มีคุณค่าเพียงพอที่จะเร่งความเร็ว ดังนั้นจึงสมเหตุสมผลที่จะเพิ่มการดำเนินการเหล่านั้นเป็นการคอมไพล์ล่วงหน้า

เราได้เรียนรู้อะไรจากทั้งหมดนี้?

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

ในหลายกรณี ตัวอย่างอื่นๆ เหล่านี้คล้ายคลึงกับสิ่งที่เราเห็นในการสรุปบัญชี แต่เรายังได้เรียนรู้บทเรียนใหม่ๆ อีกด้วย:

• ฟังก์ชันการห่อหุ้มสามารถช่วยหลีกเลี่ยงความเสี่ยงในการรวมศูนย์ในพื้นที่อื่นๆ ของสแต็กได้：

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

• การห่อหุ้มมากเกินไปอาจทำให้ภาระความไว้วางใจและการกำกับดูแลในโปรโตคอลมากเกินไป：

นี่คือหัวข้อของบทความก่อนหน้าในหัวข้อ Dont Overload Ethereum Consensus: หากการสรุปคุณลักษณะเฉพาะทำให้โมเดลความน่าเชื่อถืออ่อนแอลง และทำให้ Ethereum เป็นแบบ ส่วนตัว มากขึ้น สิ่งนี้จะทำให้ Ethereum อ่อนแอลง ความเป็นกลางที่น่าเชื่อถือ ในกรณีเหล่านี้ การมีฟังก์ชันเฉพาะเป็นกลไกที่อยู่ด้านบนของ Ethereum จะดีกว่า แทนที่จะพยายามนำมันมาไว้ใน Ethereum เอง พูลหน่วยความจำที่เข้ารหัสคือตัวอย่างที่ดีที่สุดที่นี่ ซึ่งอาจเป็นเรื่องยากสักหน่อยในการห่อหุ้ม อย่างน้อยก็จนกว่าการเข้ารหัสเวลาแฝงจะดีขึ้น

• การห่อหุ้มมากเกินไปอาจทำให้โปรโตคอลซับซ้อนเกินไป：

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

• ฟังก์ชันการห่อหุ้มอาจไม่เกิดผลในระยะยาวเนื่องจากความต้องการของผู้ใช้ไม่สามารถคาดเดาได้：

คุณลักษณะที่หลายคนคิดว่ามีความสำคัญและผู้ใช้จำนวนมากจะใช้อาจไม่ได้ใช้บ่อยนักในทางปฏิบัติ

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

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

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

• แทนที่จะสรุปแนวคิดทั้งหมดของการยกเลิก คุณสามารถสรุปการตรวจสอบ EVM เพียงอย่างเดียวได้

เราสามารถขยายไดอะแกรมก่อนหน้านี้ได้ดังนี้:

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

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