Vitalik新文：SSF如何让以太坊单槽签名数稳定在8192次？

ชื่อเดิม: การยึดลายเซ็น 8192 ต่อช่องโพสต์ SSF: อย่างไรและทำไม

ผู้เขียนต้นฉบับ: Vitalik Buterin การวิจัย ETH

การรวบรวมต้นฉบับ: Luccy, BlockBeats

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

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

Vitalik กลับมา สู่การวิจัย ETH และหารือว่าทำไมจึงจำเป็นต้องอนุญาตให้ผู้ตรวจสอบที่เข้าร่วมมีลายเซ็นสองรายการต่อช่องหลังจาก SSF นั่นคือมีลายเซ็นถึง 8192 รายการ ในเวลาเดียวกัน เขาได้เสนอสมมติฐานสามประการเกี่ยวกับวิธีการบรรลุเป้าหมายนี้ กล่าวคือ การวางเดิมพันแบบเต็ม การวางเดิมพันแบบสองชั้น และการหมุนเวียนการมีส่วนร่วม วิเคราะห์วิธีจัดการจำนวนลายเซ็นต่อช่องได้อย่างมีประสิทธิภาพมากขึ้น ขณะเดียวกันก็รักษาความปลอดภัยของโปรโตคอล และหารือเกี่ยวกับข้อดีและข้อเสีย รวมถึงผลกระทบต่อโปรโตคอลและผู้ใช้ BlockBeats รวบรวมข้อความต้นฉบับดังนี้:

หนึ่งในความแตกต่างที่สำคัญระหว่าง Ethereum และระบบ Proof-of-stake อื่นๆ ส่วนใหญ่ (โดยสมบูรณ์) ก็คือ Ethereum มุ่งมั่นที่จะสนับสนุนผู้ตรวจสอบความถูกต้องจำนวนมาก: ปัจจุบันเรามีผู้ตรวจสอบความถูกต้อง 895,000 คน และการวิเคราะห์กฎหมายของ Zipf แสดงให้เห็นว่าสิ่งนี้เทียบเท่ากับสิบของ บุคคลหรือองค์กรอิสระหลายพันราย จุดประสงค์ของสิ่งนี้คือเพื่อสนับสนุนการกระจายอำนาจ และช่วยให้คนทั่วไปมีส่วนร่วมในการวางเดิมพันโดยไม่ต้องให้ทุกคนละทิ้งความสามารถในการดำเนินการและมอบการควบคุมให้กับหนึ่งในแหล่งรวมการวางเดิมพันจำนวนหนึ่ง

อย่างไรก็ตาม วิธีการนี้ต้องการให้เครือข่าย Ethereum จัดการลายเซ็นจำนวนมากต่อสล็อต (ประมาณ 28,000 ในปัจจุบัน; 1,790,000 หลังจาก SSF) ซึ่งเป็นภาระที่สูงมาก เพื่อรองรับภาระนี้ จำเป็นต้องเสียสละทางเทคนิคหลายประการ:

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

• ขณะนี้เราไม่มีทางเลือกอื่นในการต้านทานควอนตัมที่ชัดเจนที่สามารถรับมือกับมันได้อย่างมีประสิทธิภาพ

• การแก้ไขการเลือกแบบแยกส่วน เช่น การรวมมุมมองจะซับซ้อนมากขึ้น เนื่องจากไม่สามารถแยกลายเซ็นแต่ละรายการได้

• SNARKing ลายเซ็นจำนวนมากเป็นเรื่องยาก Helios จำเป็นต้องทำงานบนลายเซ็นเพิ่มเติมเฉพาะทางที่เรียกว่าลายเซ็นของคณะกรรมการการซิงค์

• ต้องใช้ช่องย่อยสามช่องภายในหนึ่งช่องแทนที่จะเป็นสองช่อง ดังนั้นจึงเป็นการเพิ่มเวลาช่องขั้นต่ำที่ปลอดภัย

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

แถมยังไม่บรรลุเป้าหมายด้วยซ้ำ ข้อกำหนดขั้นต่ำสำหรับการวางเดิมพันยังคงเป็น 32 ETH ซึ่งหลาย ๆ คนเข้าถึงไม่ได้ จากมุมมองการวิเคราะห์เชิงตรรกะ เป้าหมายของระบบที่ช่วยให้ทุกคนลงชื่อเข้าใช้ทุกสล็อตและให้การเดิมพันสำหรับคนธรรมดาอย่างแท้จริงดูเหมือนจะเป็นไปไม่ได้ในระยะยาว: หาก Ethereum มีผู้ใช้ 500 ล้านคน และ 10% ของพวกเขาเข้าร่วมการเดิมพัน นั่นหมายถึง 100 ล้านลายเซ็นต่อช่อง จากมุมมองทางทฤษฎีข้อมูล การประมวลผลในการออกแบบนี้ต้องการพื้นที่ว่างข้อมูลอย่างน้อย 12.5 MB ต่อช่อง ซึ่งเทียบเท่ากับเป้าหมายของการแบ่งส่วนทั้งหมดโดยประมาณ อาจทำได้ แต่การกำหนดให้ตัวเองพึ่งพาการสุ่มตัวอย่างความพร้อมใช้งานของข้อมูลนั้นเพิ่มความซับซ้อนอย่างมาก และถึงกระนั้น มีเพียงประมาณ 0.6% ของประชากรโลกเท่านั้นที่มีส่วนร่วมในการเดิมพัน และนั่นไม่ได้เริ่มเกี่ยวข้องกับปัญหาการคำนวณในการตรวจสอบลายเซ็นจำนวนมากด้วยซ้ำ

ดังนั้น แทนที่จะพึ่งพาผู้เข้ารหัสเพื่อสร้าง Magic Bullet (หรือ Magic Bulletproof) เพื่อให้ได้ลายเซ็นที่เพิ่มมากขึ้นในแต่ละช่อง ฉันขอแนะนำให้เราทำการเปลี่ยนแปลงทางปรัชญา: เลิกคาดหวังเช่นนั้นตั้งแต่แรก สิ่งนี้จะขยายพื้นที่การออกแบบ Proof-of-Stake ได้อย่างมาก และช่วยให้ลดความซับซ้อนทางเทคนิคได้อย่างมาก ทำให้มีความปลอดภัยมากขึ้นด้วยการอนุญาตให้ Helios สามารถ SNARK ได้โดยตรงจากฉันทามติของ Ethereum และสร้างแผนลายเซ็นที่ไม่น่าสนใจแต่มีมายาวนานเช่น Winternitz It สามารถแก้ปัญหาความต้านทานควอนตัมได้

ทำไมไม่ แค่ใช้คณะกรรมการ?

บล็อกเชนที่ไม่ใช่ Ethereum จำนวนมากที่ประสบปัญหานี้นำแนวทางการรักษาความปลอดภัยแบบคณะกรรมการมาใช้ ในแต่ละช่อง พวกเขาจะสุ่มเลือกเครื่องมือตรวจสอบความถูกต้อง N รายการ (เช่น N γ 1,000) ที่มีหน้าที่รับผิดชอบในการสรุปช่อง เราควรย้ำเตือนว่าเหตุใดแนวทางนี้จึงไม่เพียงพอ เนื่องจากไม่ได้ให้ความรับผิดชอบ

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

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

ฉันคิดว่ามันเป็นค่าใช้จ่ายที่สูง แต่ก็สูงมากจนเราสามารถเสียสละเรื่องนี้ได้ แม้ว่าค่าโจมตีจะอยู่ที่ 1-2 ล้าน ETH แต่ก็เพียงพอแล้ว นอกจากนี้ ความเสี่ยงจากการรวมศูนย์หลักในปัจจุบันใน Ethereum นั้นแสดงออกมาในรูปแบบที่แตกต่างไปจากเดิมอย่างสิ้นเชิง: หากจำนวนเงินฝากขั้นต่ำลดลงจนใกล้เป็นศูนย์ พลังของกลุ่ม Stake ขนาดใหญ่จะไม่ลดลงมากนัก

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

จะเกิดอะไรขึ้นกับลายเซ็น 8192 ต่อช่องภายใต้ SSF

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

วิธีที่ 1: ใช้กลุ่มจำนำแบบกระจายอำนาจอย่างเต็มที่

Zen of Python มีประโยคที่สำคัญมาก:

ควรมีวิธีเดียวที่ชัดเจนในการทำสิ่งนี้ และควรมีเพียงวิธีเดียวเท่านั้น

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

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

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

วิธีที่ 2: การจำนำสองชั้น

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

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

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

วิธีที่ 3: การมีส่วนร่วมแบบหมุนเวียน (เช่น คณะกรรมการแต่มีความรับผิดชอบ)

เราใช้แนวทางที่คล้ายกับการออกแบบ Super Committee ที่เสนอไว้ที่นี่: สำหรับแต่ละช่อง เราเลือกเครื่องมือตรวจสอบความถูกต้องที่ใช้งานอยู่ในปัจจุบัน 4096 และปรับชุดนี้อย่างระมัดระวังในแต่ละช่องเพื่อให้เรายังคงมีความปลอดภัย

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

ที่นี่เรามีกลไกที่น่าสนใจที่จะแยก น้ำหนัก เพื่อจุดประสงค์ด้านแรงจูงใจจาก น้ำหนัก เพื่อวัตถุประสงค์ที่เป็นเอกฉันท์: รางวัลสำหรับเครื่องมือตรวจสอบความถูกต้องทุกคนในคณะกรรมการควรจะเท่ากัน (อย่างน้อยสำหรับเครื่องมือตรวจสอบความถูกต้องที่ใช้ ≤M ETH ) เพื่อให้รางวัลเฉลี่ยเป็นสัดส่วน ไปยังยอดคงเหลือ แต่เรายังคงสามารถคำนวณน้ำหนักตัวตรวจสอบฉันทามติในคณะกรรมการได้โดยการถ่วงน้ำหนัก ETH สิ่งนี้ทำให้แน่ใจได้ว่าจำนวน ETH ที่จำเป็นในการทำลายขั้นสุดท้ายจะเท่ากับมากกว่า 1/3x ของ ETH ทั้งหมดในคณะกรรมการ

การวิเคราะห์กฎหมายโดยคร่าวๆ ของ Zipf จะคำนวณจำนวน ETH ดังนี้:

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

• ดังนั้น คณะกรรมการจะมี ETH จำนวนเท่ากันที่เข้าร่วมจากแต่ละระดับยอดคงเหลือ ยกเว้นระดับที่อยู่เหนืออุปสรรค M ซึ่งผู้ตรวจสอบจะอยู่ในคณะกรรมการเสมอ

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

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

ข้อได้เปรียบหลักคือรักษาการเดิมพันที่เป็นอิสระในรูปแบบที่จดจำได้ รักษาระบบหมวดหมู่เดียว และยังช่วยให้จำนวนเงินฝากขั้นต่ำลดลงเหลือระดับที่ต่ำมาก (เช่น 1 ETH)

สรุปแล้ว

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

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

ลิงค์เดิม