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

คอมไพล์ | Odaily ดาราดาวเดียวของนานจู

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

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

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

ในปัจจุบัน Ethereum ใช้โครงสร้างของ Slot และ Epoch ใน Gasper consensus โดยมี 1 Slot ทุก 12 วินาที ซึ่งส่วนหนึ่งของผู้ตรวจสอบจะโหวตหัวบล็อกของโซ่ และในช่วง 32 Slot (6.4 นาที) ทุกๆ ผู้ตรวจสอบจะมีโอกาสโหวต 1 ครั้ง โหวตเหล่านี้จะถูกแปลงใหม่เป็นข้อความในอัลกอริธึมฉันทามติที่คล้ายกับ PBFT หลังจาก 2 Epoch (12.8 นาที) จะมีการให้ความมั่นใจทางเศรษฐศาสตร์ที่แข็งแรงที่เรียกว่า finality

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

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

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

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

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

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

จนถึงขณะนี้อย่างน้อยในทฤษฎีแล้ว เป็นหน้าที่ของ L2 ที่จะสร้างเครือข่าย "เรียงลำดับศูนย์กลาง" ของตนเอง กลุ่มเล็กๆ ของผู้ตรวจสอบอาจลงลายมือรับรองบล็อกทุกไมโครวินาทีและลงทุนสินทรัพย์พันธบัตรของพวกเขาในบล็อกเหล่านี้ ในที่สุด หัวข้อบล็อก L2 เหล่านี้จะถูกเผยแพร่ไปยัง L1

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

การยืนยันพื้นฐาน

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

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

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

เรากำลังมองอะไรอยู่จริงๆหรือ?

สมมติว่าเราได้รับความสามารถในการเสร็จสิ้นในสล็อตเดียว โดยเราใช้เทคโนโลยีที่คล้ายกับ Orbit เพื่อลดจำนวนผู้ตรวจสอบที่ต้องลงนามในแต่ละสล็อต แต่จำนวนนี้ก็ไม่ลดลงมากเกินไป เพื่อให้เรายังสามารถดำเนินการในเป้าหมายสำคัญที่จะลดขั้นต่ำของการเงินหลัก 32 ETH ได้ ระยะเวลาของสล็อต (slot time) อาจเพิ่มขึ้นเป็น 16 วินาทีแล้วเราใช้การยืนยันล่วงหน้า rollup หรือการยืนยันล่วงหน้าของพื้นฐานเพื่อให้ผู้ใช้ได้รับการยืนยันที่รวดเร็วกว่า สุดท้ายเราได้รับอะไร: โครงสร้างสล็อตแบบ epoch-slot

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

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

• "ฉันทามติโดยประมาณ" ต้องการโหนดจํานวนน้อยในขณะที่ขั้นสุดท้ายทางเศรษฐกิจต้องการโหนดส่วนใหญ่
• เมื่อจำนวนโหนดเกินขนาดที่กำหนดคุณจะต้องใช้เวลามากขึ้นในการเก็บลายมือ

ใน Ethereum วันนี้สล็อต 12 วินาทีแบ่งออกเป็นสามช่องย่อย: Block Release and Distribution, Proof Aggregation และ Proof Aggregation หากจํานวนตัวพิสูจน์ลดลงอย่างมากเราสามารถลดเหลือสองช่องย่อยและใช้เวลาสล็อต 8 วินาที อีกปัจจัยหนึ่งที่ใช้งานได้จริงและใหญ่กว่าคือ "คุณภาพ" ของโหนด อีกปัจจัยที่ใหญ่กว่าคือ "คุณภาพ" ของโหนด หากเราสามารถพึ่งพาชุดย่อยของโหนดพิเศษเพื่อเข้าถึงโปรโตคอลโดยประมาณ (และยังคงใช้ตัวตรวจสอบแบบเต็มชุดเพื่อกําหนดขั้นสุดท้าย) เราสามารถลดเหลือประมาณ 2 วินาที

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

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

ในความเห็นของฉัน L2 ปัจจุบันมีกลยุทธ์ที่ถูกต้องอยู่สามแบบ:

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

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

• โครงสร้าง epoch-and-slot ที่เป็นเอธีเรียมเฉพาะ
• การยืนยันล่วงหน้าของเซิร์ฟเวอร์
• คณะกรรมการยืนยันล่วงหน้า

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

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