Vitalik: จะสร้างความสมดุลระหว่าง "ความซับซ้อนในการห่อหุ้ม" และ "ความซับซ้อนของระบบ" ในการ
เรียบเรียงข้อความต้นฉบับ: Nanfeng
เรียบเรียงข้อความต้นฉบับ: Nanfeng

อย่างไรก็ตาม ความท้าทายประการหนึ่งของเป้าหมายนี้คือความซับซ้อนนั้นยากจะนิยาม และบางครั้ง คุณต้องทำการแลกเปลี่ยนระหว่างสองตัวเลือกที่ทำให้เกิดความซับซ้อนประเภทต่างๆ และมีค่าใช้จ่ายที่แตกต่างกัน เราจะเปรียบเทียบได้อย่างไร?
เครื่องมือที่ทรงพลังและชาญฉลาดที่ช่วยให้เราสามารถคิดเกี่ยวกับความซับซ้อนได้ละเอียดยิ่งขึ้นคือความแตกต่างระหว่างสิ่งที่เราเรียกว่าความซับซ้อนที่ถูกห่อหุ้มและความซับซ้อนของระบบ(systemic complexity)。

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

H คือฟังก์ชันแฮช m คือข้อความ k และ K คือคีย์ส่วนตัวและคีย์สาธารณะ จนถึงตอนนี้ง่าย อย่างไรก็ตาม ความซับซ้อนที่แท้จริงนั้นซ่อนอยู่ในคำจำกัดความของฟังก์ชัน e: การจับคู่เส้นโค้งวงรี ซึ่งเป็นหนึ่งในส่วนทางคณิตศาสตร์ที่ยากจะเข้าใจมากที่สุดในบรรดาการเข้ารหัสทั้งหมด
ทีนี้ มาดูลายเซ็นของ Schnorr กัน ลายเซ็น Schnorr อาศัยเส้นโค้งวงรีพื้นฐานเท่านั้น แต่ตรรกะการลงนามและการยืนยันนั้นซับซ้อนกว่าเล็กน้อย:

ตัวอย่างเช่น:
ตัวอย่างเช่น:
การทำ BLS multisignature (รวมลายเซ็นของสองคีย์ k1 และ k2) นั้นง่ายมาก เพียงแค่ σ1+σ2 แต่ Schnorr หลายลายเซ็นต้องการการโต้ตอบสองรอบ และจำเป็นต้องจัดการกับการโจมตีด้วยการยกเลิกคีย์ที่ยุ่งยาก
ลายเซ็น Schnorr จำเป็นต้องสร้างตัวเลขสุ่ม แต่ลายเซ็น BLS ไม่จำเป็นต้องสร้าง
ชื่อเรื่องรอง
การเข้ารหัสเทียบกับเศรษฐศาสตร์แบบเข้ารหัส
ตัวเลือกการออกแบบที่สำคัญที่เกิดขึ้นในการออกแบบบล็อกเชนจำนวนมากคือการเปรียบเทียบระหว่างการเข้ารหัสและเศรษฐศาสตร์การเข้ารหัสลับ สิ่งนี้ (เช่นใน Rollups) มักจะเป็นตัวเลือกระหว่างการพิสูจน์ความถูกต้อง (เช่น ZK-SNARK) และการพิสูจน์การฉ้อโกง
ZK-SNARK เป็นเทคโนโลยีที่ซับซ้อน ในขณะที่แนวคิดพื้นฐานเบื้องหลังวิธีการทำงานของ ZK-SNARK สามารถอธิบายได้อย่างชัดเจนในบทความเดียว การนำ ZK-SNARK ไปใช้จริงเพื่อตรวจสอบการคำนวณบางอย่างนั้นซับซ้อนกว่าการคำนวณเองหลายเท่า (ดังนั้น นี่คือเหตุผลว่าทำไมการพิสูจน์ ZK-SNARK สำหรับ EVM ยังอยู่ระหว่างการพัฒนา ในขณะที่หลักฐานการฉ้อโกงสำหรับ EVM อยู่ในรุ่นเบต้าแล้ว) การนำการพิสูจน์ ZK-SNARK ไปใช้อย่างมีประสิทธิภาพนั้นเกี่ยวข้องกับการออกแบบวงจรที่ปรับให้เหมาะสมตามวัตถุประสงค์พิเศษ การใช้ภาษาโปรแกรมที่ไม่คุ้นเคย และความท้าทายอื่นๆ อีกมากมาย ในทางกลับกัน การพิสูจน์การฉ้อโกงนั้นเรียบง่ายในตัวเอง: คุณเพียงเรียกใช้การคำนวณโดยตรงบนเครือข่ายหากมีคนเสนอความท้าทาย เพื่อประสิทธิภาพ บางครั้งรูปแบบการค้นหาแบบไบนารีจะถูกเพิ่มเข้ามา แต่ถึงแม้จะไม่ได้เพิ่มความซับซ้อนมากนัก
แม้ว่า ZK-SNARK จะซับซ้อน แต่ความซับซ้อนของพวกมันคือความซับซ้อนที่ห่อหุ้มไว้ ในทางกลับกัน ความซับซ้อนค่อนข้างต่ำของการพิสูจน์การทุจริตคือความซับซ้อนของระบบ ต่อไปนี้เป็นตัวอย่างของความซับซ้อนของระบบบางส่วนที่นำเสนอโดยหลักฐานการฉ้อโกง:
พวกเขาต้องการวิศวกรรมสิ่งจูงใจอย่างระมัดระวังเพื่อหลีกเลี่ยงภาวะที่กลืนไม่เข้าคายไม่ออกของผู้ตรวจสอบความถูกต้อง
หากดำเนินการโดยฉันทามติ พวกเขาจะต้องมีประเภทธุรกรรมเพิ่มเติมสำหรับการพิสูจน์การฉ้อโกง ในขณะเดียวกันก็ต้องคำนึงถึงสิ่งที่จะเกิดขึ้นหากผู้เข้าร่วมจำนวนมากแข่งขันกันเพื่อส่งหลักฐานการฉ้อโกงพร้อมกัน
พวกเขาอาศัยเครือข่ายการซิงโครไนซ์
พวกเขาอนุญาตให้ใช้การโจมตีด้วยการเซ็นเซอร์เพื่อขโมย
Rollups ที่ป้องกันการฉ้อโกงต้องการผู้ให้บริการสภาพคล่องเพื่อรองรับการถอนทันที
ชื่อเรื่องรอง
ตัวอย่างต่างๆ
PoW (ฉันทามติของนากาโมโตะ):ความซับซ้อนของการห่อหุ้มที่ต่ำกว่า เนื่องจากกลไกนั้นเรียบง่ายและเข้าใจง่าย แต่ความซับซ้อนของระบบที่สูงขึ้น (เช่น การโจมตีการขุดที่เห็นแก่ตัว)
ฟังก์ชันแฮช:ความซับซ้อนของบรรจุภัณฑ์สูง แต่มีคุณสมบัติที่เข้าใจเป็นอย่างดี ดังนั้นความซับซ้อนของระบบจึงต่ำ
อัลกอริทึมการสับแบบสุ่ม:อัลกอริทึมการสับเปลี่ยนสามารถซับซ้อนภายในได้ (เช่น Whisk) แต่ให้แน่ใจว่ามีการสุ่มที่แข็งแกร่งและเข้าใจง่าย หรือเรียบง่ายภายใน แต่สามารถสร้างคุณสมบัติสุ่มที่อ่อนแอและยากต่อการวิเคราะห์ (เช่น ความซับซ้อนของระบบ)
ค่าที่ขุดได้ (MEV):โปรโตคอลที่แข็งแกร่งพอที่จะรองรับธุรกรรมที่ซับซ้อนอาจค่อนข้างเรียบง่ายภายใน แต่ธุรกรรมที่ซับซ้อนเหล่านั้นสามารถมีผลกระทบเชิงระบบที่ซับซ้อนต่อสิ่งจูงใจของโปรโตคอลโดยการเสนอการบล็อกในรูปแบบที่ผิดปกติมาก
ต้นไม้ Verkle:ชื่อเรื่องรอง
เราจะชั่งน้ำหนักอย่างไร?
โดยปกติแล้ว ตัวเลือกที่มีความซับซ้อนของบรรจุภัณฑ์ต่ำกว่าจะเป็นตัวเลือกที่มีความซับซ้อนของระบบต่ำกว่า ดังนั้นจึงมีตัวเลือกหนึ่งที่ง่ายกว่าอย่างชัดเจน แต่ในบางครั้ง คุณต้องเลือกอย่างยากลำบากระหว่างความซับซ้อนหนึ่งกับอีกความซับซ้อนหนึ่ง ณ จุดนี้ควรชัดเจนว่าหากเป็นการสรุปความซับซ้อน มันก็อันตรายน้อยกว่า ความเสี่ยงที่เกิดจากความซับซ้อนของระบบไม่ใช่ฟังก์ชันง่ายๆ ของความยาวของข้อมูลจำเพาะ ส่วนย่อย 10 บรรทัดเล็กๆ ของข้อมูลจำเพาะที่โต้ตอบกับส่วนอื่นๆ จะซับซ้อนกว่าฟังก์ชัน 100 บรรทัดที่จะพิจารณาเป็นอย่างอื่น กล่องดำ
อย่างไรก็ตาม แนวทางนี้มีข้อจำกัดที่สนับสนุนการห่อหุ้มความซับซ้อน ข้อบกพร่องของซอฟต์แวร์อาจปรากฏในโค้ดส่วนใดก็ได้ เมื่อโค้ดใหญ่ขึ้นเรื่อย ๆ ความน่าจะเป็นของข้อผิดพลาดจะใกล้เคียงกับ 1 บางครั้งสิ่งที่เริ่มต้นจากความซับซ้อนของการห่อหุ้มอาจกลายเป็นความซับซ้อนของระบบเมื่อคุณต้องการโต้ตอบกับระบบย่อยในรูปแบบใหม่และไม่คาดคิด
ตัวอย่างของสิ่งหลังคือแผนผังสถานะสองระดับในปัจจุบันของ Ethereum ซึ่งมีแผนผังของวัตถุบัญชี โดยที่แต่ละวัตถุของบัญชีจะมีแผนผังการจัดเก็บของตัวเอง

โครงสร้างแบบทรีนี้ซับซ้อน แต่ในตอนแรก ความซับซ้อนนี้ดูเหมือนจะถูกห่อหุ้มอย่างดี: โปรโตคอลที่เหลือโต้ตอบกับทรีในฐานะที่เก็บคีย์/ค่าที่อ่านและเขียนได้ ดังนั้นเราจึงไม่ต้องกังวลว่าทรีจะถูกสร้างขึ้นอย่างไร .
อย่างไรก็ตาม ในเวลาต่อมา ความซับซ้อนนี้ได้รับการพิสูจน์ว่ามีผลกระทบอย่างเป็นระบบ: ความสามารถของบัญชีที่มีแผนผังหน่วยเก็บข้อมูลขนาดใหญ่ตามอำเภอใจ หมายความว่าไม่มีทางที่จะคาดหวังได้อย่างน่าเชื่อถือว่าส่วนสถานะใดส่วนหนึ่ง (เช่น "บัญชีทั้งหมดที่เริ่มต้นด้วย 0x1234") จะมีขนาดที่คาดเดาได้ . สิ่งนี้ทำให้การแบ่งสถานะออกเป็นหลายส่วนทำได้ยากขึ้น ทำให้การออกแบบโปรโตคอลการซิงโครไนซ์ซับซ้อนขึ้น และพยายามกระจายกระบวนการจัดเก็บข้อมูลเหตุใดความซับซ้อนของบรรจุภัณฑ์จึงกลายเป็นระบบ เนื่องจากอินเทอร์เฟซมีการเปลี่ยนแปลงทางออกคืออะไร? ข้อเสนอปัจจุบันที่จะย้ายไปที่ต้นไม้ Verkle ยังรวมถึงการย้ายไปที่การออกแบบต้นไม้ระดับเดียวที่สมดุล
ท้ายที่สุดแล้ว ประเภทของความซับซ้อนที่ต้องการในสถานการณ์ใดก็ตามเป็นคำถามที่ไม่มีคำตอบง่ายๆสิ่งที่ดีที่สุดที่เราสามารถทำได้คือรองรับความซับซ้อนของการห่อหุ้มในระดับปานกลาง แต่ไม่มากเกินไป และใช้วิจารณญาณของเราในแต่ละกรณีที่เป็นรูปธรรม มีบางครั้ง แนวทางปฏิบัติที่ดีที่สุดคือการสละความซับซ้อนของระบบเพียงเล็กน้อยเพื่อลดความซับซ้อนของบรรจุภัณฑ์ลงอย่างมาก ในบางครั้ง คุณอาจตัดสินผิดด้วยซ้ำว่าอะไรถูกสรุปและอะไรไม่ได้ ทุกสถานการณ์แตกต่างกัน


