*ส่งต่อชื่อเรื่องต้นฉบับ 'Epochs and slots all the way down: ways to give Ethereum users faster transaction confirmation times'

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

ภาพรวมของไอเดียและเทคนิคที่มีอยู่ในปัจจุบัน

ความสมบูรณ์ของสล็อตเดียว

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

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

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

แผนภาพของคำเสนอที่นำไปสู่การออกแบบความสมบูรณ์ของสล็อตเดียว_

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

Rollup preconfirmations

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

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

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

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

โดยการยืนยันล่วงหน้า

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

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

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

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

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

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

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

เหตุผลที่ง่าย ๆ คือจำนวนของโหนด ในขณะที่เก่าเส้นตรง@VitalikButerin/parametrizing-casper-the-decentralization-finality-time-overhead-tradeoff-3f2011672735">การแบ่งพารามิเตอร์และการค้าของ Decentralization / Finality Time / Overhead ดูเบาลงตอนนี้เนื่องจากการรวมกลุ่ม BLS แบบไฮเปอร์แอ็กติเกียนและในอนาคตใกล้ๆ ZK-STARKs แต่ก็ยังเป็นความจริงที่มีพื้นฐานว่า:

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

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

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

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

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

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

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

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

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

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

คำประกาศปฏิเสธความรับผิดชอบ：

1. บทความนี้ถูกพิมพ์ซ้ำจาก [vitalik].ส่งต่อชื่อเรื่องต้นฉบับ 'Epochs and slots all the way down: ways to give Ethereum users faster transaction confirmation times'. สิทธิ์ในการคัดลอกทั้งหมดเป็นของผู้เขียนต้นฉบับ [ vitalik*]. If there are objections to this reprint, please contact theGate Learnทีม และพวกเขาจะดำเนินการด้วยรวดเร็ว
2. การปฏิเสธความรับผิดชอบ: มุมมองและความคิดเห็นที่แสดงในบทความนี้เป็นเพียงเจ้าของบทความเท่านั้นและไม่เป็นการให้คำแนะนำใด ๆ เกี่ยวกับการลงทุน
3. การแปลบทความเป็นภาษาอื่นๆ ทำโดยทีม Gate Learn หากไม่ได้ระบุไว้ การคัดลอก การกระจาย หรือการลอกเลียนแบบบทความที่แปลนั้นถือเป็นการละเมิด