ส่งต่อชื่อเรื่องเดิม 'Epochs and slots all the way down: วิธีให้ผู้ใช้ Ethereum มีเวลายืนยันธุรกรรมเร็วขึ้น'

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

ภาพรวมของความคิดและเทคนิคที่มีอยู่

ความสมบูรณ์ของช่องเดียว

วันนี้ Ethereum ของGasper consensus ใช้สถาปัตยกรรมช่องและยุค ทุกช่อง 12 วินาที ชุดของ validators จะเผยแพร่โหวตเกี่ยวกับหัวของเชื่อม, และตลอดระยะเวลาของ 32 ช่อง (6.4 นาที), ทุก validators จะได้โอกาสในการโหวตอีกครั้ง โหวตเหล่านี้จึงถูกตีความใหม่ว่าเป็นข้อความในลักษณะที่ไม่ชัดเจนเหมือน PBFTขั้นตอนของอัลกอริทึม konsensus ซึ่งหลังจากสองยุค (12.8 นาที) ทำให้มีการยืนยันทางเศรษฐกิจที่ยากมากที่เรียกว่า finality

ในช่วงสองปีที่ผ่านมาเรากลายเป็นคนที่ไม่สบายใจมากขึ้นกับวิธีการปัจจุบัน สาเหตุหลักที่ (i) มันซับซ้อนและมีข้อบกพร่องในการโต้ตอบระหว่างกลไกการลงคะแนนสล็อตต่อสล็อตและกลไกความสมบูรณ์ตามยาวรอบ และ (ii) 12.8 นาทีนั้นนานเกินไปและไม่มีใครสนใจที่จะรอนานขนาดนั้น

การสิ้นสุดช่องเดียวแทนที่สถาปัตยกรรมนี้ด้วยกลไกที่คล้ายกับ ความเห็นของ Tendermint, ซึ่งบล็อก N ถูกยืนยันก่อนที่จะสร้างบล็อก N+1 โดยหลักการที่แตกต่างหลักจาก Tendermint คือเรายังคงเก็บ “การรั่วไหลจากความไม่เคลื่อนไหว“ กลไกภายในที่ช่วยให้เครือข่ายสามารถทำงานต่อไปและกู้คืนตัวเองในกรณีที่ผู้ตรวจสอบมากกว่า 1/3 ของจำนวนรวมตัวตรวจสอบล้มเหลว

แผนภาพของแผนการเสนอชั้นนำการออกแบบความสมบูรณ์ของช่องเดียว_

ความท้าทายหลักของ SSF คือว่าอย่างไรก็ตาม ดูเหมือนว่าจะแสดงให้เห็นว่าผู้ stake Ethereum ทุกคนจะต้องเผยแพร่ข้อความ 2 ข้อทุก 12 วินาที ซึ่งจะเป็นภาระมากสำหรับเครือข่ายในการจัดการไอเดียฉลาดเพื่อวิธีการบรรเทาสถานการณ์นี้ รวมถึงเร็วที่สุดOrbit SSFโครงการ แต่แม้ว่าสิ่งนี้จะช่วยปรับปรุงประสบการณ์ผู้ใช้ได้มากขึ้นโดยทำให้ "ความสมบูรณ์" มาเร็วขึ้น แต่สิ่งนี้ไม่เปลี่ยนแปลงจริงๆ ว่าผู้ใช้ต้องรอ 5-20 วินาที

การยืนยันก่อน Rollup

ในระยะเวลาหลายปีที่ผ่านมา Ethereum ได้ติดตามแผนภูมิที่เน้น Rollup, ออกแบบชั้นฐานของ Ethereum (L1) โดยรอบเพื่อสนับสนุนข้อมูลที่มีพร้อมและฟังก์ชั่นอื่น ๆ ที่สามารถนำไปใช้โดยโปรโตคอลเลเยอร์ 2 เช่น rollups (but also validiums และ พลาสม่า) ที่สามารถให้ผู้ใช้ระดับความปลอดภัยเท่าเทียมกับ Ethereum แต่มีขนาดใหญ่มาก

นี้สร้างการแยกความสำคัญในระบบ Ethereum: Ethereum L1 สามารถเน้นไปที่การป้องกันการเซ็นเซอร์ชัน, การมั่นคง, คงที่ และการบำรุงรักษาและปรับปรุงฟังก์ชันพื้นฐานระดับฐาน และ L2s สามารถเน้นไปที่การเข้าถึงผู้ใช้โดยตรงมากขึ้น - ทั้งผ่านทางวัฒนธรรมและการจับคู่เทคโนโลยี แต่ถ้าคุณเดินทางไปในทางนี้ ปัญหาที่หนีไม่พ้นคือ: L2s ต้องการให้บริการผู้ใช้ที่ต้องการการยืนยันที่เร็วกว่า 5-20 วินาที

จนถึงตอนนี้อย่างน้อยในสํานวนโวหารมันเป็นความรับผิดชอบของ L2s ในการสร้างเครือข่าย "การจัดลําดับแบบกระจายอํานาจ" ของตนเอง กลุ่มผู้ตรวจสอบขนาดเล็กจะลงชื่อออกในบล็อกบางทีทุกๆสองสามร้อยมิลลิวินาทีและพวกเขาจะวาง "เดิมพัน" ไว้เบื้องหลังบล็อกเหล่านั้น ในที่สุดส่วนหัวของบล็อก L2 เหล่านี้ได้รับการเผยแพร่ไปยัง L1

ชุดผู้ตรวจสอบ L2 สามารถโกงได้: พวกเขาสามารถลงนามในบล็อก B1 ก่อนจากนั้นจึงลงนามในบล็อก B2 ที่ขัดแย้งกันในภายหลังและกระทําลงบนห่วงโซ่ก่อน B1 แต่ถ้าพวกเขาทําเช่นนี้พวกเขาจะถูกจับและสูญเสียเงินฝากของพวกเขา ในทางปฏิบัติเราได้เห็นเวอร์ชันรวมศูนย์ของสิ่งนี้ แต่ rollups ได้พัฒนาเครือข่ายการจัดลําดับแบบกระจายอํานาจช้า และคุณสามารถโต้แย้งได้ว่าการเรียกร้อง L2s ทั้งหมดทําการจัดลําดับแบบกระจายอํานาจเป็นข้อตกลงที่ไม่เป็นธรรม: เรากําลังขอให้ rollups ทํางานส่วนใหญ่เช่นเดียวกับการสร้าง L1 ใหม่ทั้งหมด ด้วยเหตุนี้และอื่น ๆ Justin Drake จึงได้ส่งเสริมวิธีที่จะให้ L2s ทั้งหมด (รวมถึง L1) เข้าถึงกลไกการยืนยันล่วงหน้าทั่วทั้ง Ethereum ที่ใช้ร่วมกัน: การยืนยันก่อน.

ข้อกำหนดก่อนการยืนยัน

วิธีการยืนยันก่อนที่อิเทอร์เรียมจะสมมติว่าผู้เสนอ Ethereum จะกลายเป็นผู้กระทำที่มีความชำนาญมาก ๆ เพื่อเหตุผลที่เกี่ยวข้องกับ MEV (ดูที่นี่สำหรับคำอธิบายของ MEV และดูเพิ่มเติมที่ตั๋วการดำเนินการวิธีการที่ใช้กันอย่างแพร่หลาย ในการเสนอเสนอ). การใช้วิธีการก่อนการยืนยันที่มีพื้นฐานนี้ ให้ประโยชน์จากความซับซ้อนนี้โดยการสร้างสะสมให้ผู้เสนอเชี่ยวชาญเหล่านี้รับผิดชอบในการเสนอการยืนยันก่อนให้บริการ

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

ตามที่กล่าวไว้ การยืนยันล่วงหน้าที่ใช้เป็นพื้นฐานให้ความมั่นใจกับธุรกรรม L1 หาก rollups “ตั้งอยู่”, จากนั้นบล็อก L2 ทั้งหมดก็คือธุรกรรม L1 ดังนั้นกลไกเดียวกันสามารถใช้เพื่อให้การยืนยันล่วงหน้าสำหรับ L2 ใดๆ ได้

เราจริงๆ กำลังมองอะไรอยู่ที่นี่?

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

มีม “พวกเขาคือรูปเดียวกัน” ได้ถูกใช้มากเกินไปในจุดนี้ เพราะฉะนั้นฉันจะใส่แผนภาพเก่าที่วาดไว้หลายปีก่อนเพื่ออธิบายสถาปัตยกรรมของ Gasper's slot-and-epoch และแผนภาพของ L2 preconfirmations ข้างๆกัน โดยหวังว่าจะสื่อความหมายได้

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

เหตุผลที่เรียบง่ายคือจำนวนของโหนด@VitalikButerinการพิจารณาพารามิเตอร์ Casper การแบ่งเบาะแส / เวลาการสิ้นสุด / การแลกเปลี่ยนความเสี่ยงดูอ่อนลงตอนนี้เนื่องจากการรวม BLS อย่างละเอียดและในอนาคตใกล้ ZK-STARKs แต่ก็ยังคงเป็นจริงตามพื้นฐานว่า:

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

ใน Ethereum วันนี้ช่อง 12 วินาทีถูกแบ่งเป็นสามสล็อตย่อยสำหรับ (i) การเผยแพร่และการกระจาย, (ii) การรับรอง, และ (iii) การรวมรวมการรับรอง หากจำนวนผู้รับรองมีน้อยลงมาก เราสามารถลดลงเป็นสล็อตย่อยสองและมีเวลาสล็อต 8 วินาที อีกปัจจัยหนึ่งที่สำคัญและสมจริงคือ "คุณภาพ" ของโหนด หากเราสามารถพึ่งพากับกลุ่มย่อยของโหนดที่มีความเป็นมืออาชีพในการทำข้อตกลงโดยประมาณ (และยังคงใช้ชุดผู้ตรวจสอบเต็มรูปแบบสำหรับความสมบูรณ์) เราสามารถลดลงไปถึง ~2 วินาทีได้โดยเป็นไปได้

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

L2s ควรทำอย่างไร?

ในมุมมองของฉัน มีกลยุทธ์ที่สามที่เหมาะสมสำหรับ L2s ที่จะทำในขณะนี้:

1. การ “ฐาน”, ทั้งทางเทคโนโลยีและจิตวิญญาณ นั่นคือการจัดเรียงให้เหมาะสำหรับการเป็นช่องทางผ่านสำหรับคุณสมบัติเทคนิคของเลเยอร์ฐาน Ethereum และคุณค่าของมัน (การกระจายอำนาจสูง, ความต้านทานการเซ็นเซอร์ชั่น, ฯลฯ) ในรูปแบบที่ง่ายที่สุดของพวกเขา, คุณสามารถคิดว่า rollups เหล่านี้เป็น “ชาร์ดที่มีแบรนด์”, แต่พวกเขายังสามารถมีความทะเยอทะยานมากกว่านั้นและทดลองอย่างหนักเกี่ยวกับการออกแบบเครื่องมือเสมือนและการปรับปรุงเทคนิคใหม่ๆ อีกมาก
2. ภูมิใจที่ได้เป็น "เซิร์ฟเวอร์ที่มีนั่งร้านบล็อกเชน" และทําให้ดีที่สุด หากคุณเริ่มต้นจากเซิร์ฟเวอร์แล้วเพิ่ม (i) หลักฐานความถูกต้องของ STARK เพื่อให้แน่ใจว่าเซิร์ฟเวอร์ปฏิบัติตามกฎ (ii) รับประกันสิทธิ์สําหรับผู้ใช้ในการออกจากหรือบังคับให้ทําธุรกรรมและอาจ (iii) เสรีภาพในการเลือกร่วมกันไม่ว่าจะผ่านการประสานงานจํานวนมากออกหรือผ่านความสามารถในการลงคะแนนเพื่อเปลี่ยนซีเควนเซอร์แล้วคุณได้รับประโยชน์มากมายจากการเป็น onchain ในขณะที่รักษาประสิทธิภาพส่วนใหญ่ของเซิร์ฟเวอร์
3. การดำเนินการที่เป็นการสอธิส: โซ่ที่เร็ว 100 โหนด โดย Ethereum ให้ความสามารถในการประสานงานและความปลอดภัยเพิ่มเติม นี่คือแผนงานปัจจุบันที่เป็นที่ยอมรับของโปรเจค L2 หลายๆ โปรเจค

สำหรับบางแอพพลิเคชั่น (เช่น ENS, keystores) การชําระเงินบางส่วน) เวลาบล็อก 12 วินาทีก็เพียงพอแล้ว สําหรับแอปพลิเคชันเหล่านั้นที่ไม่ใช่ทางออกเดียวคือสถาปัตยกรรมสล็อตและยุค ในทั้งสามกรณี "ยุค" เป็น SSF ของ Ethereum (บางทีเราสามารถย้อนกลับตัวย่อนั้นให้มีความหมายอย่างอื่นที่ไม่ใช่ "ช่องเดียว" เช่น อาจเป็น "Secure Speedy Finality") แต่ "สล็อต" เป็นสิ่งที่แตกต่างกันในแต่ละสามกรณีข้างต้น:

1. โครงสร้างสล็อตและยุคเกตเนทีฟของ Ethereum
2. การยืนยันก่อนเซิร์ฟเวอร์
3. คณะกรรมการยืนยันล่วงหน้า

คำถามสำคัญคือ วัตถุประสงค์หลักคือการที่เราสามารถทำให้สิ่งใดสิ่งหนึ่งดีขึ้นในหมวดหมู่ (1) ได้อย่างไร โดยเฉพาะอย่างยิ่ง หากมันดีขึ้นจริง ๆ แล้ว ก็รู้สึกเหมือนหมวดหมู่ (3) ก็จะไม่มีความหมายมากนัก หมวดหมู่ (2) จะยังคงอยู่เสมอ อย่างน้อยที่สุดเพราะอะไรที่ “ฐาน” ไม่ทำงานสำหรับ L2s ข้อมูลนอกเชือง เช่น แพลสมาและวาลิเดียม แต่หากสถาปัตยกรรมสล็อตและยุคของ Ethereum-native สามารถลดลงไปที่ 1 วินาที “สล็อต” (เช่น เวลาก่อนการยืนยัน) แล้วพื้นที่สำหรับหมวดหมู่ (3) ก็จะเล็กลงไปมากมาย

วันนี้ เราไกลจากการมีคำตอบสุดท้ายสำหรับคำถามเหล่านี้ คำถามสำคัญ - คำถามที่สำคัญมาก - ว่าผู้เสนอบล็อกจะกลายเป็นคนที่มีความซับซ้อนแค่ไหน - ยังเป็นพื้นที่ที่มีความไม่แน่นอนมากมาย การออกแบบเช่น Orbit SSFเป็นเร็วมากเสนอว่าพื้นที่การออกแบบของการออกแบบช่องและยุคที่สิ่งที่เหมือนออบิต SSF คือยุคยังไม่ได้รับการสำรวจอย่างเต็มที่ มีตัวเลือกมากขึ้นเราจะทำได้ดีขึ้นสำหรับผู้ใช้ทั้งบน L1 และบน L2s และเราสามารถทำให้งานของนักพัฒนา L2 ง่ายขึ้น

ข้อความปฏิเสธความรับผิดชอบ：

1. บทความนี้ถูกพิมพ์ใหม่จาก [ Vitalik]. ส่งต่อชื่อเรื่องต้นฉบับ 'Epochs and slots all the way down: วิธีให้ผู้ใช้ Ethereum มีเวลายืนยันธุรกรรมเร็วขึ้น'. ลิขสิทธิ์ทั้งหมดเป็นของผู้เขียนต้นฉบับ [Vitalik]. หากมีข้อขัดแย้งใดๆเกี่ยวกับการพิมพ์ฉบับนี้ กรุณาติดต่อ Gate Learnทีม และพวกเขาจะดำเนินการโดยเร็ว
2. คำประกาศความรับผิด: มุมมองและความคิดเห็นที่แสดงในบทความนี้เป็นเพียงของผู้เขียนเท่านั้น และไม่เป็นการให้คำแนะนำทางการลงทุนใด ๆ
3. การแปลบทความเป็นภาษาอื่นๆ จะมีการดำเนินการโดยทีม Gate Learn หากไม่ได้กล่าวถึง การคัดลอก การกระจาย หรือการลอกเลียนบทความที่ถูกแปลนั้นถูกห้าม