ส่งต่อชื่อเรื่องต้นฉบับ 'เรากำลังสร้างสิ่งเดียวกัน'

แนะนำ

โพสต์นี้วิเคราะห์ต่อไปนี้

• การดำเนินการแบบไม่เชื่อมต่อ - ทำไมบล็อกเชนที่รวมประสิทธิภาพสูง (เช่น โซลานาและMonadการแยกการดำเนินการจากความเห็นรวมเรื่องการเรียงลำดับ
• การลำดับอย่างเร่งด่วน - วิธีที่พวกเขาจะสะท้อนการออกแบบของตัวคัดเลือกอย่างเร่งด่วน (เช่น @astriaorg/hj6ccpp9t">astria).
• preconfirmations - preconfs บน ethereum l1 และ rollups ที่พื้นฐานอยู่บน Ethereum
• เปรียบเทียบการใช้งานเบส + การปรับปรุงล่วงหน้าเทียบกับการใช้งานที่ไม่เบส + การสลับชั้นเบส
• ความสามารถในการรวมกันแบบทั่วไปแบบซิงโครนัส - ผ่านการรวมเข้าด้วยกันแบบอะตอม (จากตัวควบคุมที่ใช้ร่วมกัน) + ความปลอดภัยทางกลวิธี (เช่น AggLayerและ/หรือการพิสูจน์แบบเรียลไทม์
• fast based rollups - มุมมองที่เรียบง่าย ควรจะมีชั้นพื้นฐานที่รวดเร็ว
• เกมจับเวลา - เวลาคือเงินและวิธีที่สิ่งนั้นเป็นพื้นฐานของการเล่นเกมที่แตกต่างกันระหว่าง Solana กับ Ethereum
• การกระจายอำนาจเพื่อป้องกันการตรวจสอบ - วิธีไหนการแยก attester-proposerผ่านการประมูลการดําเนินการอาจสงวนผู้ตรวจสอบแบบกระจายที่สามารถบังคับการต้านการเซ็นเซอร์ชั่นได้ด้วยรายการการรวมกัน.

ท้ายที่สุด และสำคัญที่สุด พวกเราจะเห็นว่าเรากำลังสร้างสิ่งเดียวกันทั้งหมดนี่แหละดังนั้นเราอาจจะควรเพียง...

การปรับปรุงการเลียนแบบเครื่องใช้สถานะ (smr)

เราจะสร้างขึ้นจากพื้นฐานเพื่อดูว่าตัวจบสำหรับบล็อกเชนประสิทธิภาพสูง (เช่น Solana, Monad, @patrickogrady/rys8mdl5p#mitigation-strategy-enable-profit-maximizing-builders-to-minimize-invalidtps">hypersdk) ที่ใกล้เคียงกับตัวเลือกที่ขี้เกียจ (e.g., @astriaorg/hj6ccpp9t">astria). เราจะมาเต็มวงกลมในภายหลังเพื่อเปรียบเทียบกับ ethereum based rollups + preconfs.

การจัดลำดับกับการดำเนินการ

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

เราจะใช้คำศัพท์ต่อไปนี้ในส่วนนี้:

• สัณฐานทางไวยากรณ์ - การทำธุรกรรมถูกต้องตามหลักไวยากรณ์ด้วยโครงสร้างและลายเซ็นต์ที่ถูกต้อง
• สัมพันธ์ได้ตรงกับความหมาย - ธุรกรรมดำเนินการสถานะที่ถูกต้อง (เช่น ชำระค่าธรรมเนียมที่จำเป็น)
• ลำดับ - กำหนดลำดับและการรวมข้อมูล
• ดำเนินการ - ตีความและดำเนินการตามข้อมูลตามคำแนะนำ
• สร้าง - สร้างบล็อก (หรือชิ้นส่วนบล็อกบางส่วน / ชิ้นส่วนบล็อก) จากธุรกรรมที่เก็บไว้ในเครื่อง
• verify - ทำการตรวจสอบสัณฐานและ/หรือการตรวจสอบความหมายที่จำเป็นของบล็อก (หรือชิ้นบล็อกบางส่วน/ชิ้นขยะ)
• replcate - แพร่กระจายบล็อก (หรือชิ้นบล็อก/เศษบล็อกบางส่วน) ไปยังผู้ตรวจสอบอื่น

มาศึกษาการลำดับและการดำเนินการกันเถอะ เพราะเหล่านี้คืองานย่อยหลักที่จำเป็นต้องคำนวณสถานะของโซ่:

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

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

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

SMR เดิม

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

• ทุกธุรกรรมถูกต้องทางไวยากรณ์และในทางสามัญ
• สถานะใหม่ที่คำนวณแล้วตรงกับที่ถูกให้โดยผู้นำ

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

ในแบบจำลองที่เป็นแบบดั้งเดิมนี้ การสร้างและการตรวจสอบทั้งคู่รวมถึงการดำเนินการด้วย

แหล่งที่มา: @patrickogrady/rys8mdl5p#การสร้างกรณีสำหรับการทำระบบความเป็นอิสระของการจำลองเครื่องจักรชุด (DSMR)">vryx: เสริมความแข็งแกร่งให้กับการทำระบบความเป็นอิสระของการจำลองเครื่องจักรชุด

สตรีมมิ่ง smr

streaming smr (e.g., solana) เป็นรูปแบบการทำท่อทางที่มีประสิทธิภาพผู้ผลิตบล็อกสตรีมชิ้นของบล็อกอย่างต่อเนื่อง (เรียกเศษเหล็กหรือชิ้น (shreds) เมื่อสร้างขึ้น โหนดอื่นๆจะได้รับและยืนยัน (รวมถึงการดำเนินการ) ชิ้นเหล่านี้อย่างต่อเนื่อง แม้ว่าส่วนที่เหลือของบล็อกจะยังไม่ได้สร้างขึ้น ซึ่งทำให้ผู้นำขั้นต่อไปสามารถเริ่มสร้างบล็อกของพวกเขาได้เร็วขึ้น

แหล่งที่มา: @patrickogrady/rys8mdl5p#ทำความเข้าใจในกรณีของการทำสำเนาสถานะเครื่องจักรแบบปลดเชื่อม (DSMR)">vryx: การเสริมความแข็งแกร่งของการทำสำเนาสถานะเครื่องจักรแบบปลดเชื่อม

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

การดำเนินการแบบไม่ตรงเวลา

วิธีการรวมกัน

ตอนนี้เราสามารถเพิ่มประสิทธิภาพได้อีกไหมถ้าเราลดการจำกัดเหล่านั้นได้?

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

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

การสั่งซื้อกำหนดความจริง การดำเนินการเพียงแค่เปิดเผย ใครก็สามารถดำเนินการเพื่อเปิดเผยความจริงได้หลังจากที่การสั่งซื้อได้รับการกำหนดลำดับเสร็จสิ้น

นั้นคงเป็นเหตุผลที่Keone เชื่อว่าในที่สุดทุกๆบล็อกเชนจะใช้การปฏิบัติอย่างไม่สะดวกต่อกัน, และเป็นส่วนสำคัญของ วิสัยทัศน์ของ Toly เพื่อ Solana ในท้ายที่สุด:

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

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

ควรทราบว่าเรายังต้องการให้ความจริงเปิดเผยได้อย่างง่ายดายสำหรับผู้ใช้ และนั่นหมายความว่าต้องมีการสนับสนุนที่แข็งแกร่งสำหรับไคลเอ็นต์ที่เบา ออกแบบบางส่วนที่ทำให้ดำเนินการช้าลงนั้นจะทำให้เกิดความท้าทายในเรื่องนี้ (ตัวอย่างเช่นSolana กำลังพิจารณาที่จะต้องใช้มันเพียงครั้งเดียวต่อ epoch เท่านั้น) ที่มีรากสถานะในช่วงเวลาที่สั้นกว่า (เช่นใน hypersdk) คืออะไร

วิธีการแบ่งส่วน

การแยกการจัดลําดับและการดําเนินการอาจฟังดูคุ้นเคยมากเพราะนี่เป็นแนวทาง "โมดูลาร์" เช่นกัน! ผสมและจับคู่เลเยอร์ต่างๆที่เชี่ยวชาญในงานต่างๆ การแยกการจัดลําดับและการดําเนินการเป็นหลักการออกแบบที่สําคัญของซีเควนเซอร์ขี้เกียจ (เช่น Astria):

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

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

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

ในกรณีใดก็ตามท่อที่ใหญ่และเร็วมากในการสั่งข้อมูลคือสิ่งพื้นฐานที่เราต้องการ:

อย่างไรก็ตามคุณควรทราบว่าในทางเทคนิคคุณสามารถใช้โซ่ใดก็ได้เป็นซีเควนเซอร์ขี้เกียจ มันเป็นเพียงท่อข้อมูลขนาดใหญ่ในตอนท้ายของวันหลังจากทั้งหมด การยกเลิกสามารถโยนข้อมูลโดยพลการไปยังชั้นฐานที่เลือก (ไม่ว่าจะเป็น Ethereum, Bitcoin, Monad ฯลฯ ) เพื่อใช้เป็นซีเควนเซอร์โดยปริยาย โหนดสะสมสามารถรันข้อมูลแบบอะซิงโครนัสหลังจากข้อเท็จจริง

ความแตกต่างในการปฏิบัติจริงคือว่าเชือกที่เราอ้างถึงจริงๆ แล้วว่า "sequencers ขี้เกียจ" ได้รับการพิเศษสำหรับงานนี้ซึ่งมันยากกว่าที่จะพูด (เช่น การสนับสนุนประเภทธุรกรรมที่จำเป็น การเปิดเผยอินเตอร์เฟซที่ง่าย, การสร้างโครงสร้าง mev, เวลาสล็อตที่เร็ว, การรวมธุรกรรมที่เชื่อถือได้, แบนด์วิดท์สูง เป็นต้น) ผลลัพธ์คือ โหนดสำหรับเชือกที่รวมอยู่จบจากที่สุดท้ายที่ประมวลผลส่วนใหญ่ของข้อมูลที่พวกเขารวมเข้ามาในขณะที่ sequencers ขี้เกียจทิ้งให้ rollups โดยส่วนใหญ่

นั่นเป็นเหตุผลที่มันไม่ง่ายเท่ากับ 'ทำไมเราไม่ไปใช้ Solana (หรือเชื่อมต่อกับเครือข่ายอื่น ๆ เมื่อนั้นไม่เคยเป็นเป้าหมายของการออกแบบ) เป็นตัวควบคุมการเล่นเกมต่อเนื่อง?'

• ขาดสถาปัตยกรรม MEV ที่จำเป็นอย่างยิ่งที่ออกแบบมาเฉพาะสำหรับ Rollups (เช่น สถาปัตยกรรม PBS ที่จำเป็น กลไกการทำงานร่วมกันข้ามเชื่อมต่อเชิงพื้นที่ คอมโพเซอร์เพื่อการชำระค่าธรรมเนียมสำหรับผู้ใช้ Rollup ในโทเค็นแก๊สเบสเลเยอร์ ฯลฯ)
• ขาดประเภทธุรกรรมภาษาพื้นเมืองที่ออกแบบมาสำหรับการโพสต์ข้อมูลสำหรับ rollups
• การแข่งขันกับสภาพแวดล้อมการดำเนินการภายใน (เช่นมันถูกออกแบบโดยเฉพาะเพื่อบริโภคข้อมูลทั้งหมดหรือให้มากที่สุดที่เป็นไปได้ ซึ่งทำให้มีพื้นที่น้อยลงและการรวมธุรกรรมที่เชื่อถือได้น้อยลง เป็นต้น)
• การแข่งขันเพื่อสนับสนุนนักพัฒนาทั่วไปและการกำหนดลำดับความสำคัญในการอัพเกรด คุณอาจมีแนวโน้มที่จะไปที่โปรโตคอลและทีมที่เชี่ยวชาญในการช่วยคุณเปิด rollups และออกแบบโปรโตคอลของพวกเขาโดยเฉพาะสำหรับคุณเท่านั้น มากกว่าที่คนส่วนใหญ่ในชุมชนคิดว่า rollups เป็นสิ่งโง่

การเสริมความแข็งแรงของ smr ที่แยกออกมา

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

เราจะไม่จมอยู่กับรายละเอียดที่นี่ แต่คุณสามารถอ้างถึง Patrick o’grady’sงานที่น่าทึ่ง@patrickogrady/ rys8mdl5p # ทำให้เสถียรภาพของการทำซ้ำสถานะแบบแยกตัวออกจากกัน (DSMR) "> vryx เพื่อเสริมสร้างการทำซ้ำสถานะแบบแยกตัวออกจากกันการปฏิบัติการที่ไม่เป็นพร้อมและ การนำไปใช้ของ Monad ในการคำนวณค่าขนส่งสินค้าเกี่ยวกับวิธีการแก้ไขปัญหาเหล่านี้ อีกครั้ง การแก้ไขปัญหาเหล่านี้ดูเหมือนจะเหมือนกันในทั้งสองฝั่งทั้งฝั่งโมดูลและฝั่งรวม

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

ผู้เข้าร่วมภายในโปรโตคอลกับผู้เข้าร่วมภายนอกโปรโตคอล

ที่สําคัญเราต้องตระหนักว่ากระบวนการข้างต้นคิดเฉพาะนักแสดงในโปรโตคอลเท่านั้น ในความเป็นจริงนักแสดงนอกโปรโตคอลมีบทบาทอย่างมากในห่วงโซ่อุปทานการทําธุรกรรมเหล่านี้ นี่คือสิ่งที่เราเห็นก่อนหน้านี้สําหรับผู้ตรวจสอบ (ในโปรโตคอล) ใน SMR แบบดั้งเดิม:

แหล่งที่มา: @patrickogrady/rys8mdl5p#ทำความเร็วสำหรับการสร้างเคสสำหรับการทำการคัดลอกสถานะของเครื่องจักรโดยไม่ต้องผูกมัด (DSMR)">vryx: การเสริมพลังการคัดลอกสถานะของเครื่องจักรโดยไม่ต้องผูกมัด

ในการปฏิบัติจริงแล้ว,เกือบทุกผู้ตรวจสอบ ethereum จะนำเสนอบล็อกผ่าน mev-boostโดยมีผู้สร้างสามอันดับแรก (beaver, titan และ rsync) สร้างบล็อกเกือบทั้งหมด โปรดทราบว่า beaver และ rsync ตรวจสอบการทำธุรกรรมของ OFAC ในขณะที่ titan ไม่ทำ

แหล่งที่มา: com.mevboost.pics

เรลเยสจัดการทำซ้ำบล็อกเหล่านี้ไปยังเครือข่ายทั้งหมด นอกจากนี้ยังมีน้ำหนักด้านบนสูงสุดโดยผู้ดำเนินการสี่ราย (ultra sound, bloxroute, agnostic, และ flashbots) ที่ส่งผ่านจำนวนมากของบล็อก bloxroute และ flashbots ตัดสิทธิ์การทำธุรกรรม ofac ในขณะที่ agnostic และ ultra sound ไม่ตัดสิทธิ์

แหล่งที่มา: mevboost.pics

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

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

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

ความสามารถในการใช้งานร่วมกันทั่วไป

คำจำกัดความ

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

เมื่อฟังผู้คนพูดถึงการแก้ไขการกระจายตัวของสะสมคุณอาจเคยได้ยินคําฉวัดเฉวียนขนาดใหญ่รอบ ๆ ความสามารถในการรวมกันแบบซิงโครนัสทั่วไป (usc) อย่างไรก็ตามนี่อาจเป็นปฏิกิริยาของคุณ:

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

โปรดทราบว่าเราจะพูดถึง "Rollups" ตลอดส่วนที่เหลือของรายงานนี้ แต่แนวคิดเหล่านี้จํานวนมากใช้กับ "L2s" ประเภทอื่น ๆ เช่น validiums อย่างเท่าเทียมกัน ฉันเพียงแค่ไม่อยากต่อสู้กันเกี่ยวกับ wtf เป็น l2 อีกครั้ง.

ในตัวอย่างต่อไปนี้:

• r_{หนึ่ง} = ม้วน a
• r_บี = rollup b
• t_{ก 1} = ธุรกรรม 1 บน r_{หนึ่ง}
• t_b1 = ธุรกรรม 1 บน r_b
• บี_a1= บล็อก 1 บน r_a
• b_{ข 1} = บล็อก 1 ใน r_บี
  

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

หาก Rollups ทั้งสองมีกลไกความเห็นชุมนุมที่ให้การสั่งการ เราสามารถรับประกันได้ว่า:

• บี_a1 is before b_a2
• บี_b1 is before b_{ข 2}

อย่างไรก็ตาม วิธีเดียวที่จะยืนยัน:

• b_a1 ในเวลาเดียวกันที่ b_b1ดังนั้น
• t_{ก 1}และ t_b1เกิดขึ้นสะท้อนเวลา, ก็ถ้า
• พวกเขาแบ่งปันการสั่งซื้อที่ได้รับจากความเห็นร่วมกันสำหรับช่องที่กำหนด

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

อย่างไรก็ตามโปรดทราบว่าเราสามารถมีการสร้างความสามารถในการผสานความสามารถแบบไม่สม่ำเสมอได้ นับว่าฉันพบว่าบ่อยครั้งผู้คนใช้คำว่า "atomic" และ "synchronous" แทนกันไป แต่จริงๆ แล้วเป็นคำที่แตกต่างกัน

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

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

การรวมอะตอม - การจัดลำดับที่ใช้ร่วมกัน

การจัดลําดับที่ใช้ร่วมกันหมายความว่าสําหรับความสูงของสล็อตที่กําหนดเอนทิตีเดียว ("ซีเควนเซอร์" หรือที่เรียกว่า "ผู้เสนอ") มีสิทธิ์ผูกขาดในลําดับ (เช่นเสนอบล็อกสําหรับ) หลายเชน เพื่อย้ําว่าซีเควนเซอร์ที่ใช้ร่วมกันเหล่านี้ที่เราพูดถึงโดยทั่วไปคือ ตัวเลือกที่ขี้เกียจพวกเขากลายเป็นความเห็นร่วมกันเกี่ยวกับการจัดลำดับและความพร้อมของข้อมูล rollup แต่พวกเขาไม่ดำเนินการ พวกเขาไม่รู้อะไรเลยเกี่ยวกับเครื่องจักรสถานะ rollups

เหมือนที่ฉันเคยเขียนไว้ก่อนหน้านี้นี่หมายความว่าตัวจัดเก็บสายงานที่ขี้ข้ามสามารถให้ความมั่นใจที่น่าเชื่อถือในการรวมกลุ่มของสายงานข้ามเชือก (เช่น ชุดของธุรกรรม)

• อะตอมิกลี - ไม่ว่าจะเป็นการทำธุรกรรมทั้งหมดหรือไม่ก็ตาม และ
• synchronously - ในเวลาเดียวกัน (ความสูงของช่อง)

สิ่งนี้ช่วยให้การสกัด MEV ที่มีประสิทธิภาพมากขึ้นซุปเปอร์บิลเดอร์(คือ ผู้สร้าง cross-chain) เมื่อทำการทำธุรกรรม cross-chain พวกเขาจะไม่ต้องประเมินความเสี่ยงที่หนึ่งใน cross-chain bundle อาจล้มเหลว

การแยกตัวตามเครือข่ายข้ามเชื่อมต่อ

ตอนนี้เราจะทำอย่างไรให้ได้โดยไม่ต้องเชื่อมั่นในผู้สร้างและ / หรือผู้เสนอแนะที่ทำงานอยู่สำหรับ shared sequencer หากเราเพียงแค่ส่งธุรกรรมสองรายการที่ลงนามอย่างอิสระ (t₁และ t₂) สําหรับการยกเลิกแต่ละครั้งซีเควนเซอร์ที่ใช้ร่วมกันยังสามารถตัดสินใจที่จะรวมอย่างใดอย่างหนึ่ง

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

เราต้องการการรับประกันความปลอดภัยที่แข็งแกร่งมากมายที่นี่หากเราต้องการความทำงานร่วมกับโซนที่แท้จริง เราไม่ได้แค่พูดเกี่ยวกับการเอาเงินมาจากผู้ค้นหาบางคน หากสัญญา cross-chain defi จะออกแบบตัวเองบนสมมติฐานว่า cross-chain bundles จะได้รับความเคารพ แต่หากความเชื่อนี้ถูกล่วงล้ำ ผลลัพธ์ก็จะเลวร้ายสำหรับโปรโตคอลเหล่านั้น (เช่น ในกรณีของ cross-chain bridge bundle ที่เผาและขุดเหรียญได้ คุณสามารถไม่ทำการเผาแต่ขุดเงินในด้านอีกด้าน)

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

นี่หมายถึงเราต้องสร้างโครงสร้างธุรกรรมใหม่สำหรับบั้นเดิล跨เชนที่ไม่สามารถunbundled. วิธีการที่อ่อนโยนคือ “เราเพียงแค่ทำประเภทธุรกรรมใหม่สำหรับ rollups เหล่านี้เท่านั้น” แต่นั่นไม่ง่ายเลย มันจะต้องการการเปลี่ยนแปลง vm สำหรับ rollups เหล่านี้ซึ่งทำให้สูญเสียความเข้ากันได้ย้อนหลัง คุณยังต้องมีการผูกพัน rollups โดยการปรับเปลี่ยน state machines ของพวกเขาในทางที่ธุรกรรมแต่ละรายการถูกต้องเฉพาะกับการรวมกันกับอีกอย่างหนึ่ง

อย่างไรก็ตาม มีวิธีที่สะอาดกว่านี้. คุณสามารถให้แต่ละธุรกรรมในชุดรวมลงชื่อแฮชบันเดิลด้วย จากนั้นผนวกแฮชไดเจสต์เข้ากับฟิลด์ธุรกรรมฟรี (เช่น Calldata ใน EVM) ค่าสะสมต้องปรับเปลี่ยนไปป์ไลน์การได้มาเพื่อตรวจสอบสิ่งเหล่านี้ แต่ VM ยังคงไม่เปลี่ยนแปลง ด้วยเหตุนี้ผู้ใช้สะสมจึงสามารถส่งชุดรวมข้ามสายโซ่ที่พวกเขามั่นใจว่าไม่สามารถยกเลิกการรวมกลุ่มได้ การพยายามทําเช่นนั้นจะทําให้พวกเขาเป็นโมฆะ

source: เบ็น ฟิช

การรับรองความรวมรวดในการรับรองของรัฐ

ด้วยสิ่งที่กล่าวมาข้างต้น เราได้สร้างความเห็นในว่าตัวเรียงที่แชร์โดยการขีดขันทำงานอย่างเฉื่อย

• สามารถให้การยืนยันที่เชื่อถือได้เกี่ยวกับการรวมสมัครเข้าร่วมแบบอะตอมิกสำหรับกลุ่ม cross-chain (นั่นคือ ทุกรายการธุรกรรมจะถูกรวมเข้าไปหรือไม่มีรายการใดๆ)
• ไม่สามารถให้ความมั่นใจที่น่าเชื่อถือเกี่ยวกับสถานะที่เกิดจากธุรกรรมแบบนี้ที่ถูกรวมอยู่ (เช่น อาจเป็นไปได้ว่าทั้งสองธุรกรรมถูกรวมไว้ แต่มีธุรกรรมอื่นๆ ที่มาก่อให้มันย้อนกลับ)

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

เรายังมีปัญหาอยู่ - แต่ทุกคนจะรู้ได้อย่างแน่ใจว่าสถานะจะเป็นอย่างไร?

พิจารณาตัวอย่าง

• เรามีสอง rollups (RA และ RB) ร่วมกันซีเควนเซอร์ขี้เกียจเดียวกัน
• ฉันต้องการใช้สะพานการเผาและการสกัดเงินระหว่าง ra → rb ที่เผาบน ra และสกัดบน rb พร้อมกัน
• สัญญา Minting Bridge บน RB ต้องการการรับประกันการเปลี่ยนสถานะบน RA (Burn) เป็น Mint บน RB แต่สัญญาไม่สามารถทราบได้ว่าโทเค็นถูกเผาบน RA จริงหรือไม่ในขณะที่ดําเนินการเนื่องจากไม่สามารถเข้าถึงสถานะของ RA ได้

หากเราส่งแบบจับคู่ที่เหมาะสม ตัวเรียงลำดับที่เฉื่อยช้าสามารถรับรองได้ว่าธุรกรรมการเผาไหลไปยัง ra แต่คุณไม่รู้เช่นเดียวกันว่าบางทีอาจจะมีธุรกรรมตัวอื่นๆ ที่ล้มเหลวหลังจากนั้นที่ถูกนำมาไว้ข้างหน้าซึ่งทำให้มันเป็นโมฆะ (หมายความว่าโทเคนไม่ได้ถูกเผาไหม)

การแบ่งปันลำดับการทำงานอย่างเรียบง่ายไม่เพียงพอต่อการเชื่อมต่อเชื่อมโยงกันเพื่อเข้าถึงสถานะของกันและกันขณะการดำเนินการของกระเป๋าสตางค์ ความสามารถในการสื่อสารระหว่างสถานะของแต่ละกระเป๋าสตางค์ (เช่นสัญญาสะพานเองบน rb ต้องรู้สถานะของ ra) ในเวลาดำเนินการ ความสามารถนี้เป็นสิ่งที่ช่วยให้สามารถใช้งานร่วมกันได้อย่างสมบูรณ์ภายในเครือข่ายเดียว

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

เพื่อแก้ไขปัญหานี้ เราต้องเพิ่มกลไกบางอย่างเป็นการเสริมเพื่อลำดับร่วม:

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

พวกเขามีตัวเลือกอยู่สองอย่าง:

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

ความปลอดภัยทางเศรษฐกิจด้านสกุลเงิน - ตราสารหุ้นของผู้สร้าง

เรามาดูตัวอย่าง เพื่อเห็นว่า cryptoeconomics สามารถจำลองผลกระทบของการสร้างโมดูลข่าวสารได้อย่างไร ตัวอย่างที่ใช้บ่อยคือของ flashloan ข้ามสายโซ่. ฉันต้องการที่จะออกเงินกู้แฟลชใน RA, ใช้สําหรับการเก็งกําไรใน RB, และส่งคืนใน RA ทั้งหมดในช่องเดียวกัน สิ่งนี้เป็นไปได้หากโปรโตคอล DeFi เหล่านี้ปรับใช้ฟังก์ชันการทํางานข้ามสายโซ่ที่กําหนดเองกับสิ่งที่เราจะเรียกว่า "สัญญาธนาคาร" ในแต่ละด้าน:

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

ความปลอดภัยในการเข้ารหัส - Agglayer

มันคืออะไร

การ AggLayer เป็นโปรโตคอลที่ไม่จำกัดที่ให้ประโยชน์สามอย่างสำคัญ:

1. ความปลอดภัยสำหรับความสามารถในการทำงานร่วมกันข้ามโซนอย่างรวดเร็ว - มันสร้างพิสูจน์ zk ที่ให้ความปลอดภัยทางกายภาพสำหรับความสามารถในการทำงานร่วมกันข้ามโซนอย่างอะตอมิกที่มีความล่าช้าต่ำ (เช่นเร็วกว่าบล็อก ethereum) เมื่อทำงานแบบไม่สะดุดหรือทำงานแบบซิงโครนัส การออกแบบนี้แยกข้อบกพร่องของโซนอย่างไม่ซ้ำซ้อนเพื่อให้สามารถรองรับสภาพแวดล้อมการดำเนินงานและ prover ใดก็ได้
2. ความสามารถในการสลับสินทรัพย์ระหว่างโซนเครือข่าย - มันมีสะพานที่ใช้ร่วมกันเพื่อให้มั่นใจในความสามารถในการสลับสินทรัพย์ข้าม aggchains (เช่น โซนเครือข่ายที่ใช้งาน) เพื่อให้ผู้ใช้ไม่ต้องได้รับสินทรัพย์ที่ถูกห่อหุ้มไว้มากมาย สัญญาสะพานอยู่บน ethereum ซึ่งเป็นชั้นสำหรับการตกลง. (โปรดทราบว่าเชื่อมโยงที่แตกต่างกันยังสามารถมีการสมมติฐานด้านความปลอดภัยที่แตกต่างกันเนื่องจากการปฏิบัติภายใน ซึ่งจะถูกพูดถึงอย่างละเอียดในส่วนถัดไป)
3. การเพิ่มประสิทธิภาพในการใช้ก๊าซ - มันเป็นวิธีการยืนยันที่ใช้สำหรับการแบ่งต้นทุนคงที่ในทุกๆ ซีรีส์ การสำรองเงินร่วมกันยังเพิ่มประสิทธิภาพในการใช้ก๊าซด้วยการอนุญาตให้โอนจาก L2 ไปยัง L2 โดยตรงโดยไม่ต้องสัมผัส L1

ที่มา: เบรนดัน ฟาร์เมอร์, บล็อกเชนที่รวมกัน

เพื่อชี้แจงความเข้าใจผิดๆ ที่พบได้บ่อยเกี่ยวกับสิ่งที่ Agglayer ไม่ได้เป็น:

• Agglayer ไม่ใช่เพียงบริการในการรวมพิสูจน์ AggreGate.io เท่านั้น - นี่เป็นสิ่งที่สับสนเนื่องจากจริงๆ แล้วมันก็จริง มันยืนยัน aggreGate.io proofs และพวกเขาก็ใส่คำว่า "aggregation" ในชื่อของสิ่งนั้น อย่างไรก็ตาม วัตถุประสงค์ของ agglayer คือการรวมต่อเชื่อมโซ่ การแยกแยะที่สำคัญสำหรับวัตถุประสงค์ของโพสต์นี้คือ การรวมพิสูจน์เอกสารเดียวกันไม่สามารถทำให้ได้รับประกันความปลอดภัยที่เราต้องการที่นี่
• Agglayer และ shared sequencer ไม่ใช่การออกแบบที่ขัดกัน - ในขณะที่พวกเขาไม่จำเป็นต้องใช้งานร่วมกัน - พวกเขาจริงๆ แล้วเป็นตัวเต็มที่สมบูรณ์กัน ซึ่งให้การค้ําประกันที่แตกต่างกัน Agglayer ไม่เชื่อเรื่องวิธีการจัดลําดับ aggchains อย่างสมบูรณ์ มันไม่ได้จัดการกับการส่งข้อความใด ๆ ระหว่างห่วงโซ่ดังนั้นจึงอาศัยโครงสร้างพื้นฐานการประสานงานตลาดเสรีอย่างชัดเจน (เช่นรีเลย์ผู้สร้างซีเควนเซอร์ที่แยกได้ซีเควนเซอร์ที่ใช้ร่วมกัน ฯลฯ ) เพื่อประกอบโซ่

ตอนนี้เรามาเดินทางกันเลยว่ามันทำงานอย่างไร

การสะพายแว่นแย่

การสะพายระหว่าง rollups วันนี้ยาก. ถ้าคุณต้องการสะพาย eth ระหว่างออปติมิสติก rollups ของเอเธอร์รีอัลออปติมิสติกสองตัวหรือยู_{หนึ่ง}และ oru_บี:

• ผ่านสะพานธรรมชาติ - คุณจะต้องจ่ายค่าธรรมเนียมแก๊ส ethereum l1 ที่แพง (เช่น การสะพานจาก oru_{หนึ่ง}→ ethereum + ethereum → oru_b), และการเดินทางไปกลับจะใช้เวลามากกว่าหนึ่งสัปดาห์ (เนื่องจากหน้าต่างการพิสูจน์ความถูกต้องของข้อผิดพลาด)
• โรลอัพโดยตรง → โรลอัพ - เอทีเอชที่คุณได้รับบน oru_bจริงๆแล้ว จะไม่สามารถแลกเปลี่ยนได้กับ eth ต้นฉบับสำหรับ oru_{หนึ่ง}. การพึ่งพาเส้นทางของการผ่านสะพานต่าง ๆ ทําลายความสามารถในการฆ่าเชื้อรา ตัวอย่างเช่น หากโอรุ_aสะพานถูกระบายน้ำ จากนั้น ETH ที่คุณแพ็คและส่งผ่านสะพานไปยัง Orub จะไม่มีการสนับสนุนใด ๆ ในขณะที่ ETH ธรรมดาบน Oru_บี ไม่เป็นไร การกระจายตัวของสภาพคล่องแย่มากดังนั้นนี่ไม่ใช่สิ่งที่ผู้ใช้ต้องการ ในทางปฏิบัติผู้ใช้เชื่อมโยงโดยตรงผ่านผู้ให้บริการสภาพคล่อง ใครบางคนจะด้านหน้าคุณ ETH ใน ORU_บีและเก็บเงินของคุณบน oru_{หนึ่ง}. พวกเขาสามารถถอนเงินผ่านสะพานภาษาเข้าถึงและรอ แต่พวกเขาจะเรียกเก็บค่าธรรมเนียมแพงสำหรับความเสี่ยงและค่าใช้จ่ายสูงที่พวกเขาได้รับ

คุณอาจคิดว่า zk rollups แก้ปัญหานี้ได้ทันที แต่ที่จริงแล้วไม่ได้ การนำไปใช้โดยธรรมชาติยังต้องการให้คุณส่งธุรกรรม l1 ซึ่งยังคงทำให้คุณเสียค่าใช้จ่ายและมีความช้า (เช่น เวลาที่ ethereum ใช้ในการเสร็จสิ้น การสร้างพิสูจน์เวลา ถึงความถี่ของการโพสต์พิสูจน์ในการใช้งานจริง เป็นต้น)

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

นี่คือสิ่งที่การแบ่งปันสัญญาสะพานเข้ามาช่วย. สัญญาสะพานที่แบ่งปันเปิดประตูให้กับโซ่ที่ใช้สัญญาสะพานนั้นสามารถเชื่อมต่อโดยตรงกันได้โดยไม่ต้องผ่านทาง L1.

โทเค็นยังสามารถเปลี่ยนแปลงได้ในระบบเชือมจาก aggchains อีกด้วย การเชื่อมต่อ eth จากระบบ r_{หนึ่ง}→ r_บี หรือ r_ซี → r_บีเผาและสร้างเหรียญเดียวกัน มันไม่ใช่สินทรัพย์ที่ล็อกและสร้างเหรียญได้ มันเป็นเอทีเธอร์เป็นธรรมชาติ สิ่งนี้เป็นไปได้เพราะทรัพย์สินทั้งหมดถูกเก็บรักษาพร้อมกันและเชื่อมต่อผ่านสะพานรวมกัน สิ่งนี้เป็นจุดเจ็บปวดสำคัญสำหรับ L2s ในปัจจุบันที่ต้องการได้รับการตอบสนอง

อย่างไรก็ตาม โปรดทราบว่าผู้ใช้ที่ถือเอทีเอชบนร_avs. r_บี อาจมีโปรไฟล์ความเสี่ยงที่แตกต่างกันหากโซ่ที่แตกต่างกันใช้ตัวตรวจสอบที่แตกต่างกัน (เช่นบางทีคุณอาจย้ายจากห่วงโซ่ที่ปลอดภัยไปยังห่วงโซ่ที่มีข้อผิดพลาดของวงจร) โปรไฟล์ความเสี่ยงไม่เปลี่ยนแปลงระหว่างห่วงโซ่ที่ใช้มาตรฐานทั่วไปที่นี่ (ซึ่งในทางปฏิบัติเป็นบรรทัดฐานในปัจจุบัน) มาตรฐานที่สม่ําเสมอมากขึ้นและการตรวจสอบอย่างเป็นทางการจะปรับปรุงสิ่งนี้เมื่อเวลาผ่านไปแม้ว่าจะมีการเพิ่มโดเมนที่แตกต่างกันก็ตาม

พิสิฐ

aggchains ส่งอัปเดตสถานะและพิสูจน์ไปยังโหนดที่มีการจัดการโดย agglayer เพื่อสร้างการสร้างความมั่นใจต่อข้อความทั้งหมด และสร้างพิสูจน์ที่เกิดรอบ ๆ จากนั้น agglayer จะสร้างการพิสูจน์ zk ของ aggreGate.iod แบบเดียวพิสิฐ") เพื่อชําระให้กับ Ethereum สําหรับ aggchains ทั้งหมด เนื่องจากการรวมหลักฐานที่นี่ตัดจําหน่ายต้นทุนในห่วงโซ่จํานวนมากโดยพลการจึงใช้งานได้จริงจากมุมมองด้านต้นทุนเพื่อโพสต์ไปยัง Ethereum เพื่อการชําระบัญชีที่รวดเร็วโดยเร็ว โปรแกรมพิสูจน์ในแง่ร้ายเขียนด้วยรหัสสนิมปกติโดยใช้ zkvm ของ Succinct sp1สำหรับความสะดวกในการพัฒนาและประสิทธิภาพสูง

พิสูจน์ความเป็นคนที่มองโลกในแง่ลบเหล่านี้จะถูกบังคับให้เกิดขึ้น:

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

ด้วยสิ่งนี้ agglayer จะให้การตั้งค่าเกิดขึ้นบน Ethereum ก็ต่อเมื่อเงื่อนไขด้านบนถูกตรวจสอบแล้ว หากไม่ตรงตามเงื่อนไขดังกล่าว ระบบไม่สามารถตั้งค่าได้ ดังนั้น agglayer สามารถอนุญาตให้ผู้ประสาน (เช่น Sequencer หรือ Builder ที่ใช้ร่วมกัน) ส่งข้อความระหว่างเชื่อมต่อได้อย่างรวดเร็วโดยไม่บังคับให้วางใจผู้ประสานนั้นเพื่อความปลอดภัย

ความสามารถในการโอนย้ายข้ามเครือข่ายด้วยความเร็วและความปลอดภัย

aggchains สามารถใช้การรับรองที่นี่ในทั้งการต่อเนื่องและการต่อเนื่องอย่างแบบเชิงโครงสร้างเพื่อแสดงข้อจำกัดในความถูกต้องของบล็อกต่อเนื่องกับ rollups อื่นๆ

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

source: เบรนแดน เกษตรกร, เชื่อมโยงบล็อกเชน

ตัวอย่างที่เราใช้ตัวอย่างมาก่อนหน้านี้:

• เรามีรอลลัพด้วยกันสองรอลลัพ (r_{หนึ่ง}และ r_b) ที่ใช้ตัวจัดลำดับอย่างเหมือนกันและชั้นบางเหลือเศษ
• ฉันส่ง cross-chain bundle เพื่อเผา eth พร้อมกันบน r_{หนึ่ง}และเหรียญเงิน eth บน r_บี
• Super Builder สร้างบล็อกสําหรับทั้งสองเชนที่ทําเช่นนี้ซึ่งซีเควนเซอร์ที่ใช้ร่วมกันมุ่งมั่นที่จะ
• สัญญาสะพานกษาปณ์บน R_bสามารถทำการขุดคุณภาพได้อย่างมีความหวังโดยขึ้นอยู่กับสถานะของ r_a (ในกรณีนี้ดําเนินการเผา ETH สําเร็จ)
• บล็อกและพิสูจน์เหล่านี้ถูกส่งให้กับชั้นบรรยายที่พิสูจน์ว่าทั้งสองโซ่มีการดำเนินการอย่างถูกต้อง (ทั้งแยกต่างหากและต่อกับกัน) และสะพานที่ใช้ร่วมกันถูกใช้อย่างปลอดภัย

เพื่อให้สิ่งนี้ถูกตัดสินไปยัง Ethereum ได้สําเร็จขาทั้งสองข้างของมัดจะต้องดําเนินการอย่างถูกต้อง หากฝ่ายใดฝ่ายหนึ่งล้มเหลวบล็อกจะไม่ถูกต้องและไม่สามารถตัดสินได้ นั่นหมายความว่าถ้าบอกว่าซีเควนเซอร์ที่ใช้ร่วมกันลงชื่อออกในบล็อกที่ ETH ไม่ได้ถูกเผาบน r_อแต่เหรียญ eth ที่ผลิต_บีถ้าเกิดเป็นเช่นนั้นบล็อกนั้นจะถูกเรียงลำดับใหม่ สิ่งนี้รักษาความปลอดภัยของโซ่ทั้งหมดและป้องกันการกระทำที่ไม่ซื่อสัตย์ระหว่างโซ่

มีสองประเด็นที่ควรคํานึงถึงเกี่ยวกับ reorgs เหล่านี้:

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

การเรียงลำดับเหล่านี้ควรจะเกิดขึ้นน้อยมากและเป็นเรื่องน้อยเนื่องจากจุดดังกล่าว แต่เพราะเหตุนี้ aggchains จะมีควบคุมเต็มรูปแบบที่เกี่ยวข้องกับว่าลูกซองที่พวกเขาต้องการที่จะเชื่อมต่อเชือกกันได้อย่างไม่ขัดขวางและภายใต้สมมติฐานเชื่อถืออะไร เช่นเดียวกับ_{หนึ่ง} อาจยอมรับสถานะลูกโซ่จาก r_บี เพื่อแต่งตามฉันทามติของซีเควนเซอร์ แต่สําหรับ r_cอาจต้องการหลักฐานที่ส่งมาด้วยและสำหรับ r_d บางทีพวกเขาอาจต้องการให้พวกเขาเข้ารหัสลับในเชิงเศรษฐกิจเพื่อรักษาความปลอดภัยการพึ่งพาอะตอมข้ามสายโซ่ทั้งหมด ทุกห่วงโซ่สามารถสร้างการแลกเปลี่ยนที่ปรับแต่งได้เองที่นี่เพื่อเวลาแฝงและความมีชีวิตชีวาต่ํา Agglayer เป็นเพียงรากฐานที่ยืดหยุ่นและน้อยที่สุดสําหรับโซ่ที่จะมีปฏิสัมพันธ์ข้ามสายโซ่ที่ปลอดภัย

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

การแยกอนุกรมขัดข้องสำหรับตัวพิสูจน์ที่หลากหลาย

ที่สําคัญ Agglayer เปิดใช้งานโซ่ที่แตกต่างกันโดยสิ้นเชิง คุณสามารถมี aggchain กับสิ่งที่กําหนดเอง VM, Prover, DA เลเยอร์ ฯลฯ ในขณะที่แบ่งปันสะพานกับทุกคนอย่างปลอดภัย

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

ความเป็นธรรม

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

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

ที่ถูกกล่าวว่ามันไม่จําเป็นต้องเป็นกลางที่น่าเชื่อถืออย่างสมบูรณ์ไม่มีอะไรเป็น (เราจะเห็นสิ่งนี้อีกครั้งด้านล่างพร้อมค่าสะสมตาม) ในทางปฏิบัติมันเสนอวิสัยทัศน์การแข่งขันทางเทคนิคที่น่าสนใจที่สุดและต้องใช้ทัศนคติที่เรียบง่ายโดยเจตนาต่อการล็อคอินและการสกัดค่าเช่า เป้าหมายคือการอนุญาตให้ aggchains รักษาอํานาจอธิปไตยให้ได้มากที่สุดในขณะที่ยังคงสามารถขจัดความสามารถในการรวมข้ามสายโซ่ที่ลดความน่าเชื่อถือได้

aggchains ไม่ต้องใช้ vm, execution environment, sequencer, da layer, staking token, gas token, หรือ common governance ที่เฉพาะเจาะจง เชื่อมโยงสายงานสามารถออกไปเมื่อต้องการ ไม่มีข้อกำหนดในการแบ่งปันรายได้ ไม่ต้องการการปรับใช้ในฐานะ l3 บนสายงานของบุคคลอื่น

เหตุผลในการเปิดตัว L3 ที่ด้านบนของ L2 ทั่วไปส่วนใหญ่อยู่ในมุมมองของฉันคือ Band-Aids ในขณะที่สถาปัตยกรรมที่คล้ายกับ Agglayer กําลังถูกสร้างขึ้น เพื่อความชัดเจนแม้ว่านั่นเป็นเหตุผลที่ถูกต้องโดยสิ้นเชิงที่จะเปิดตัวในวันนี้ V1 Agglayer เป็นเพียงสัญญาสะพานที่ใช้ร่วมกันที่เรียบง่าย V2 ที่มีการรวมหลักฐานและความสามารถในการรับการทํางานร่วมกันที่มีเวลาแฝงต่ําอย่างปลอดภัยนั้นไม่ได้มีอยู่จริง คุณไม่สามารถคาดหวังให้ผู้คนรอเป็นเวลาหลายปีเมื่อพวกเขามีความเร่งด่วนในการจัดส่งสิ่งของในวันนี้ซึ่งจะทําให้พวกเขาแจกจ่ายได้เร็วที่สุด

การพิสูจน์แบบเรียลไทม์

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

• เรามี rollups สองอัน (r_aและ r_บี) แบ่งปันตัวตายที่เหมือนกัน
• ฉันต้องการใช้สะพาน Burn-and-Mint ระหว่าง RA → RB ซึ่งเผาไหม้พร้อมกันบน RA และ Mints บน RB
• นักสร้างที่ยอดเยี่ยมสร้างบล็อกที่เชื่อมโยงเครือข่ายที่รวมถึงข้อมูลการทำธุรกรรมที่เชื่อมโยงเหล่านี้ ภายในบล็อกนักสร้างรวมการพิสูจน์การเปลี่ยนสถานะที่ถูกเพิ่มเข้าไปในรอลลัพ

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

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

แหล่งที่มา: Justin drake, real-time proving

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

ที่มา: Justin drake, การพิสูจน์แบบเรียลไทม์

หากแรงจูงใจสูงสําหรับการพิสูจน์แบบเรียลไทม์นี้เกิดขึ้นจริงในอีกไม่กี่ปีข้างหน้าเราควรทราบด้วยว่าแน่นอนว่าสิ่งนี้ไม่เป็นมิตรกับการพิสูจน์แบบกระจายอํานาจ ผู้พิสูจน์จะต้องรวมศูนย์ค่อนข้างมากเมื่อรวมหรือทํางานร่วมกับผู้สร้าง

สรุป

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

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

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

โดยส่วนตัวแล้วฉันคิดว่าอาร์กิวเมนต์ที่ดีที่สุดในความโปรดปรานของความต้องการ USC คือในทางปฏิบัติมันจะนําไปสู่ UX และ Devex ที่ดีขึ้น เป็นไปไม่ได้ที่จะปฏิเสธผลประโยชน์มหาศาลที่มีต่อระบบนิเวศเช่น Solana อย่างไรก็ตามหวังว่าจะเป็นปัญหาในวันนี้มากกว่าและไม่ใช่ปัญหาตลอดไป

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

รวมเป็นระบบที่ใช้เทคโนโลยี Ethereum

ดี, ดังนั้นตอนนี้เราควรมีความคิดที่ดีเกี่ยวกับพื้นที่ของการแก้ไขการแยกแยะใน rollups คำถามถัดไปคือว่าเราควรเชื่อมโยงชั้นฐานในสิ่งเหล่านี้อย่างไร? Ethereum มีบทบาทอะไรที่นี่?

เราจะใช้ตัวย่อต่อไปนี้ตลอด:

• bl - ชั้นฐาน
• รวมบนพื้นฐาน br
• preconfs - การยืนยันล่วงหน้า

เว้นแต่จะระบุไว้เป็นอย่างอื่น, bl ในคำถามที่เราจะพูดคุยคือ ethereum, และ brs คือ ethereum brs อย่างไรก็ตาม, แนวคิดพื้นฐานนี้ใช้ได้ทั่วไปเช่นกันเมื่อเราสามารถเปิดใช้งาน brs ได้ที่ใดก็ได้

โรลอัพที่มีรสชาติวานิลลา

การประมวลผลครั้งแรกก่อนหน้านี้จริง ๆ มีช่วงเวลาหลายปีวางแผนที่จะเป็น brs, แต่เป็น ถูกทอดทิ้งไป เพื่อให้กำลังใจในการพัฒนาระบบจัดการศูนย์กลางสำหรับเร็วและมีประสิทธิภาพสูง. สิ่งที่เราเรียกว่าการสร้างลำดับขึ้นบนพื้นฐานนี้ vitalik จำเป็นต้องติดต่ออ้างถึงว่าความวุ่นวายทั้งหมด“ในเวลานั้น มันเป็นเรื่องที่ไม่ค่อยเหมาะสมและไม่มีประสิทธิภาพก่อนวิวัฒนาการของโครงสร้างพื้นฐานของอีเธอร์เรียม (ด้วยผู้สร้างที่ซับซ้อน)

brs จึงกลับมาอยู่ในโพงแสงในเดือนมีนาคม 2023ที่นี่พวกเขาได้ถูกกำหนดไว้ดังนี้:

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

พวกเขาควรมอบประโยชน์ต่อไปนี้:

การจัดลำดับของ rollups เช่นนี้ - การจัดลำดับโดยใช้การจัดลำดับ - เป็นอย่างมากเรียบง่ายและสืบทอดความมีชีวิตระดับ L1 และการกระจายอำนาจ นอกจากนี้ rollups ที่ใช้การจัดลำดับตามหลัก L1 ยังมีการจัดลำดับทางเศรษฐกิจที่สอดคล้องกับ L1 ฐานของมัน

โดยเฉพาะอย่างยิ่งคุณจะได้รับความปลอดภัยแบบเรียลไทม์ของเอเธอเรียม:

คุณรับมรดกความต้านทานการเซ็นเซอร์ชั่นและความมีชีวิตชีวาของ ethereum ด้วย ดังนั้นไม่เพียงแต่คุณมีการรับรองการชำระเงินของ ethereum แต่คุณยังมีความต้านทานการเซ็นเซอร์ชั่น ความต้านทานการเซ็นเซอร์ชั่นแบบเรียลไทม์ไม่ใช่แบบล่าช้าที่คุณรู้จักกับทางออกฉุกเฉินแต่เป็นแบบเรียลไทม์

การเป็นรอลลัพที่มีพื้นฐานคือการออกแบบที่ถูกต้องเมื่อคุณได้เลือกเลเยอร์พื้นฐาน:

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

ในรูปแบบที่ง่ายที่สุดของพวกเขา brs สามารถประสบความสำเร็จในเป้าหมายการออกแบบด้านบนได้แน่นอน หาก rollup ไม่ได้นำเสนอตัวเองเป็น sequencer แล้วโดยนิยามอัตโนมัติ proposer ethereum ปัจจุบันก็จะตัดสินใจว่าอะไรจะถูกนำเข้าไปในทุก ๆ 12 วินาที (เวลา slot ของ ethereum)

อย่างไรก็ตามการจัดลำดับตามพื้นฐานยังมีข้อเสียที่เกี่ยวข้อง ซึ่งตรงตามที่ว่าทำไม rollups โดยทั่วไปจะดำเนินการตามลำดับของตัวเอง:

• fast preconfs - ผู้ใช้ rollup ไม่ต้องการรอ 12 วินาทีขึ้นไปสำหรับบล็อก ethereum
• safe preconfs - บางครั้งบล็อก ethereum มีการ reorg ดังนั้นผู้ใช้ต้องรอเวลานานขึ้นเพื่อปลอดภัย ซึ่งผู้ใช้ไม่ชอบ ซีเควนเซอร์สามารถให้ preconfs ที่ไม่ขึ้นอยู่กับบล็อก ethereum ที่ยังไม่ได้เสร็จสมบูรณ์และดังนั้นไม่จำเป็นต้อง reorg แม้ว่า ethereum จะมีการ reorg ชั่วคราว
• การโพสต์แบทช์ที่มีประสิทธิภาพ - ตัวเรียงสามารถแบทช์ข้อมูลจำนวนมาก บีบอัดและโพสต์ไปยังบล็อกเชนได้อย่างเป็นระยะๆในรูปแบบที่ทำให้เสียค่าใช้จ่ายต่ำสุด (เช่น การตรวจสอบการใช้เต็มบล็อก)

โรลลัพเบส + พรีคอนฟ์ที่มีเตรียมแล้ว

ดังนั้นเราสามารถมีเค้กของเราและกินมันเกินไป? เข้า โครงการก่อตั้ง.

เราจะอธิบายสัญชาตญาณที่อยู่เบื้องหลัง preconfs ตามที่นี่ค่อนข้างสั้นเพื่อให้เราสามารถเปรียบเทียบ BRS + preconfs กับ rollups แบบดั้งเดิม หลังจากนั้นเราจะกลับมาวิเคราะห์ preconfs เพิ่มเติมในรายละเอียดที่มากขึ้นโดยทั่วไป (เช่นทั้ง br preconfs และ bl preconfs ในธุรกรรม ethereum l1)

แนวคิดหลักคือ BR preconfs ต้องมาจากผู้เสนอ BL ผู้เสนอเหล่านี้จะต้องวางหลักประกันบางอย่าง (เช่น restaking) และเลือกใช้เงื่อนไขการเฉือนเพิ่มเติม (เช่น preconfs ที่พวกเขาให้ไว้จะทําให้เป็นไปตามที่สัญญาไว้) ผู้เสนอใด ๆ ที่เต็มใจที่จะทําเช่นนั้นสามารถทําหน้าที่เป็นซีเควนเซอร์ BR และให้ preconfs

เราควรทราบว่าผู้เสนอ (เช่นผู้ตรวจสอบความถูกต้อง) คาดว่าจะ deleGate.io บทบาทนี้ในการจัดหา preconfs ให้กับหน่วยงานพิเศษที่เรียกว่า "Gate.ioways" การให้ preconfs จะต้องใช้เอนทิตีที่ค่อนข้างซับซ้อนและ Ethereum ต้องการทําให้ผู้เสนอไม่ซับซ้อน

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

โปรดทราบว่าในขณะที่ผู้ตรวจสอบบุ๊คเคอร์เรนต์ทำหน้าที่เป็นผู้เสนอบล็อกเชน, มีการพิจารณาสำหรับการอัพเกรดโดยที่โปรโตคอลเองจะประมูลสิทธิ์เสนอผ่านการประมูลการดําเนินการ. สิ่งนี้จะช่วยให้หน่วยงานที่มีความซับซ้อนสามารถซื้อสิทธิ์ข้อเสนอได้โดยตรงดังนั้นจึงไม่จําเป็นต้องให้ผู้ตรวจสอบความถูกต้อง (ผู้เสนอปัจจุบัน) deleGate.io กับพวกเขาตามที่พิจารณาที่นี่

ในทุกกรณี, จุดสำคัญคือ ในกรณีที่มีการก่อตั้งล่วงหน้าที่เร็วกว่าคอนเซนซัสของ Ethereum (12 วินาที) จำเป็นต้องมีบุคคลที่สามที่เชื่อถือได้ (TTP) ไม่ว่า TTP ของคุณจะเป็นวายณ์ตรงกลางซึ่งทำหน้าที่เป็นผู้ตรวจสอบที่ถูกย้อนกลับหรือผู้ถือสตางค์การประมูลการดำเนินการไม่ว่าจะเป็น winner, deleGate.iod Gate.ioway หรืออย่างอื่นๆ - มันไม่สามารถให้ความปลอดภัยของ Ethereum เรียลไทม์ได้ ไม่ว่าคุณจะได้รับ "based preconf" เป็นผู้เสนอ Ethereum หรือ "traditional preconf" เป็นผู้ต่อต้านการผสมกัน - คุณกำลังวางความไว้วางใจใน Coinbase อยู่ เขาก็สามารถวางหลักประกันเป็น eth บางส่วนได้ แต่ในทั้งสองกรณีนี้ก็เป็นอิสระจากความปลอดภัยของ Ethereum consensus

เราควรสังเกตแล้วว่าการออกแบบ preconf ตามใด ๆ จําเป็นต้องเบี่ยงเบนไปจากเป้าหมายที่ระบุไว้ของ BRS ที่เราเริ่มต้นด้วย (ความเรียบง่ายและการรักษาความปลอดภัย BL) การกำหนดค่าที่มีการพัฒนาขึ้นมา, และพวกเขาไม่สามารถให้การรับประกันความปลอดภัยแบบเรียลไทม์ของเอเธอร์รีอัสได้

อย่างไรก็ตามคุณควรเก็บไว้ว่า คุณสามารถบังคับธุรกรรมโดยตรงผ่านธุรกรรม bl หาก preconfers เหล่านี้ออฟไลน์หรือเริ่มเซ็นเซอร์คุณสามารถได้รับการรับรองเหล่านี้จาก ethereum ที่จะเข้มแข็งขึ้นอีกเมื่อ รายการการรวมถูกนำมาใช้งานแล้ว

สำหรับ BRS - TTPS ให้การยืนยันก่อนการดำเนินการอย่างรวดเร็ว และ BL ให้ความมั่นคงที่สุด

โรลอัพที่ไม่ขึ้นอยู่บนพื้นฐาน + การย้อนกลับที่ขึ้นอยู่บนพื้นฐาน

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

เหมือนที่ฉันได้ระบุไว้ในการสร้างลูกเล่นจะได้รับความปลอดภัยหรือไม่?:

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

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

โปรดทราบว่าเวลาถึงความปลอดภัยสุดท้ายคือตัวแปรสำคัญที่ต้องปรับปรุงที่นี่:

การถือว่าผู้ใช้ rollup สามารถกลับไปใช้งานได้เป็นอย่างดีเท่าที่โฮสต์เชนคาดหวังในเรื่องของความมั่นคงในการทำงาน หมายถึงคุณสามารถให้การรวมธุรกรรมบังคับเข้าไปในบล็อกของโฮสต์เชนในความเร็วเท่ากับบล็อกของโฮสต์เชน (เช่น ถ้าผู้ตัดสินใน rollup กำลังประกาศคุณ คุณสามารถบังคับการรวมธุรกรรมในบล็อก ethereum ถัดไป)

ในการปฏิบัติ, โดยทั่วไปจะมีความล่าช้าเล็กน้อย หากคุณอนุญาตให้รวมอัดเข้าไปทันที คุณอาจเปิดเผยการเฝ้าระวังที่มีกำไร MEV รวมถึงความซับซ้อนอื่น ๆ. อย่างไรก็ตาม ยังมีการออกแบบที่อาจให้การรับรองความมีชีวิตใกล้เคียงเวลาจริงจากโฮสต์เชน (เช่น อาจจะด้วยความเร็วของบล็อกโฮสต์เชนไม่กี่บล็อกแทนที่จะเป็นหนึ่งบล็อก)

ในจิตวิญญาณนี้,Sovereign labs มีการออกแบบซึ่งทำตามดังนี้:

• การจัดลำดับที่ได้รับอนุญาต - rollups ตั้งตัวจัดลำดับที่ได้รับอนุญาตซึ่งธุรกรรมของมันจะถูกประมวลผลทันทีเมื่อถูกรวมอยู่ในบล็อก เนื่องจากพวกเขามีการล็อกการเขียนบนสถานะของ rollup พวกเขาสามารถให้ preconfs ที่เชื่อถือได้เร็วกว่าเวลาบล็อกของ bl
• ตามลําดับตาม - ผู้ใช้ยังสามารถส่งธุรกรรมโดยตรงไปยัง BL ของพวกเขา แต่พวกเขาจะถูกประมวลผลด้วยความล่าช้าบล็อก n (โดยที่ n มีขนาดเล็กเพียงพอ) สิ่งนี้ช่วยลด "เวลาในการรักษาความปลอดภัยในที่สุด" ได้อย่างมากและในความเป็นจริงพวกเขายังเรียกการออกแบบว่า "การจัดลําดับตามการยืนยันที่นุ่มนวล" ด้วยเหตุนี้! (โปรดทราบว่าคําจํากัดความของ BRS นี้จะขัดแย้งกับคําจํากัดความที่เราให้ไว้ก่อนหน้านี้กล่าวคือผู้เสนอ BL ต้องมีสิทธิ์จัดลําดับ br หรือเป็น deleGate.iod โดยพวกเขา)

สำหรับ non-brs - ttps ให้ preconfs อย่างรวดเร็วและ bl ให้ความปลอดภัยที่สุด

ทำไมเนี่ย?

เห็นได้ว่าทั้งสองเส้นทางที่อธิบายข้างต้นจะสร้างผลลัพธ์ที่มีประสิทธิผลเดียวกัน:

BRS เหล่านี้ที่มี preconfs ไม่ได้ให้ความเรียบง่ายหรือการรักษาความปลอดภัยแบบเรียลไทม์ของ Ethereum อีกต่อไป แล้วตอนนี้ประเด็นทั้งหมดนี้คืออะไร? ทําไมเราไม่เพียงแค่กระชับขึ้นทางเลือกในการยกเลิก"แบบดั้งเดิม"? wtf แม้เป็น"rollup ตาม"ที่จุดนี้?

นี่กลับมาที่ฉันจริงๆหลักฐานการกํากับดูแลโพสต์จากปีที่แล้วที่ฉันได้สนทนาถึงการใช้งานพื้นฐานสำหรับการเติมเงินเฉพาะ Ethereum

1) ทางเทคนิค (การสัญญาของผู้เสนอ) - ไม่มีทางหลีกเลี่ยงได้ - หากคุณต้องการการสัญญาที่น่าเชื่อถือเกี่ยวกับการเรียงลำดับของบล็อก ethereum จะต้องมาจากผู้ตรวจสอบ ethereumMEV-Boost++เป็นตัวอย่างหนึ่งของการใช้ประโยชน์ที่อาจจะตกอยู่ในช่วงเวลานี้

2) สังคม - ฉันเห็น ethereum alignment เป็นกรณีการใช้งานหลักสำหรับแอปพลิเคชันการเก็บเงินสำหรับฟังก์ชันการเก็บเงินปัจจุบันส่วนใหญ่ ไม่ใช่การรวมความปลอดภัยทางเศรษฐกิจหรือการกระจายอำนาจ มันกำลังพูดว่า " ดูเราคือโครงการ Ethereum!”มันก็เหมือนเหตุผลเดียวกันที่เหล่าโซ่ยังคงเรียกตัวเองว่า ethereum l2sไม่ว่าจะเป็นสถาปัตยกรรมอย่างไรก็ตาม.

เราสามารถทำให้เป็นรุ่นปัจจุบันในบริบทของการถามค่าของ "br + preconfs" กับ "traditional rollup + fast fallback" ได้หรือไม่?

1) ทางเทคนิค (ข้อผูกพันของผู้เสนอ) - Ethereum BRS ที่มี preconfs มีประโยชน์ทางเทคนิคพื้นฐานอย่างหนึ่ง - พวกเขาสามารถได้รับคํามั่นสัญญาที่น่าเชื่อถือจากผู้เสนอ Ethereum ปัจจุบันเกี่ยวกับการรวมและการสั่งซื้อเนื้อหาของบล็อก Ethereum สิ่งนี้อาจมีประโยชน์ด้วยเหตุผลเดียวกับที่เราอาจต้องการให้กลุ่มของ rollups แบ่งปันซีเควนเซอร์ หากผู้เสนอ BL เป็นผู้เสนอ BR ด้วย (เช่นซีเควนเซอร์) พวกเขาสามารถให้การรับประกันการรวมอะตอมเดียวกันกับ BL เช่นเดียวกับที่คุณจะได้รับระหว่างการยกเลิกใด ๆ ที่แบ่งปันซีเควนเซอร์ พวกเขามีการผูกขาดในทั้งสองห่วงโซ่ ตอนนี้สิ่งนี้มีค่าแค่ไหน? เราจะกลับมาที่ในบิต

2) สังคม (การจัดเรียง / ความเป็น Neutral ที่น่าเชื่อถือ) - รักหรือเกลียดก็ได้,การจัดตําแหน่ง Ethereumเป็นจุดขายที่เป็นบริษัท ฉันจะเป็นซื่อตรงกับความจริงว่า ฉันไม่รู้อะไรมากเกินไปเกี่ยวกับไทโกะนอกจาก "พวกเขาคือคนที่เล่นเกม br" และฉันคงไม่รู้ว่าพวกเขาคือใครถ้าพวกเขาไม่ได้เป็นคนที่เล่นเกม br ทุกคนต้องการการตลาดร่วมกันที่ดี มีค่าได้ด้วยกับการเป็นผู้เริ่มต้นที่นี่ แต่ฉันคิดว่านี่ไม่ใช่คุณค่าย่อยที่ยังคงอยู่และไม่สามารถส่งต่อไปยัง br อื่น ๆ ในอนาคตได้มีความคล้ายคลึงกัน โดยเช่นเดียวกับที่เราได้ยินเกี่ยวกับ avss ไม่กี่ตัวแรก แต่คุณสามารถบอกชื่อตัวปัจจุบันทั้งหมดได้หรือไม่? ฉันไม่สามารถทำได้

ในระดับที่สูงขึ้นคุณจะไม่ได้รับ ethereum rollups ทั้งหมดเพื่อเลือกใช้ "Optimism Shared Sequencer" หรือ "Arbitrum Shared Sequencer" (สมมุติฐาน) คุณมีช็อตที่ดีกว่าแม้ว่าจะทําให้พวกเขาทั้งหมดเลือกใช้ "Ethereum Shared Sequencer" ไม่มีโทเค็นใหม่ไม่มีแบรนด์ใหม่ไม่มีฉันทามติใหม่ หากคุณคิดว่ามันมีค่าสําหรับ Ethereum L2 ทั้งหมดที่จะรวมกันในการจัดลําดับความเป็นกลางที่น่าเชื่อถือนี้อาจเป็นจุด schelling ที่แข็งแกร่งที่สุดในการบรรลุเป้าหมายนั้น

ความเป็นกลางที่น่าเชื่อถือนี้น่าจะมีค่ามากที่สุดสําหรับนักพัฒนา rollups ที่พยายามดึงดูดผู้ใช้ข้ามระบบนิเวศ (เช่นแอปพลิเคชันที่มีโครงสร้างพื้นฐานเช่น ENS) พวกเขาอาจลังเลที่จะใช้ซีเควนเซอร์มองโลกในแง่ดีหากจะทําให้ผู้ใช้ Arbitrum แปลกแยกหรือในทางกลับกัน

เราจะพูดถึงแต่ละส่วนในรายละเอียดเพิ่มเติมด้านล่าง

ความเป็นธรรมภาพที่น่าเชื่อถือ

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

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

มีคําถามเปิดหลายข้อเกี่ยวกับหลักประกันที่นี่:

ขนาดหลักประกัน

การออกแบบในช่วงต้นสันนิษฐานว่าผู้เสนอจะต้องวางหลักประกันจํานวนมากอย่างไม่น่าเชื่อในการสั่งซื้อ 1,000 ETH ปัญหาคือโดยพื้นฐานแล้วผู้เสนอสามารถปฏิบัติตามคํามั่นสัญญาที่จะ deleGate.io และสร้างบล็อกด้วยตนเองได้เสมอโดยเทียบเคียงกับ preconfs สิ่งนี้มีค่าอย่างไม่น่าเชื่อและ 1000 ETH นั้นสูงกว่าการชําระเงินสูงสุดที่เคยสังเกตได้ซึ่งผ่าน MEV-boost ตั้งแต่เริ่มก่อตั้ง ข้อเสียคือแน่นอนว่าสิ่งนี้จําเป็นต้องสร้างอุปสรรคสูงในการเข้าสําหรับผู้เสนอรายย่อยในขณะที่ผู้เสนอรายใหญ่ (เช่น Coinbase) สามารถวาง 1,000 ETH ได้อย่างสมเหตุสมผลมากขึ้นในขณะที่ได้รับรางวัลจากน้ําหนักเดิมพันทั้งหมด (>13% ของอีเธอเชื่อมั่นทั้งหมด) เนื่องจากผู้ลงทะเบียนสามารถวางพันธบัตรเดียวสําหรับผู้ตรวจสอบทั้งหมดของพวกเขา มี ไอเดียอื่น ๆ เพื่อให้ผู้เสนอข้อเสนอที่มีหลักประกันน้อยมาก, แต่แน่นอนว่ามาพร้อมกับการเสียสละ พื้นที่การออกแบบที่นี่เป็นเพียงความไม่แน่นอน

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

แหล่งที่มา: Barnabé monnot, จาก mev-boost ไปยัง epbs ไปยัง aps

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

ประเภทหลักประกัน

vanilla eth น่าจะเป็นหลักทรัพย์ที่เป็นกลางได้อย่างน่าเชื่อถือในสถานการณ์นี้ อย่างไรก็ตาม จะมีความปรารถนาที่จะใช้สินทรัพย์ที่มีประสิทธิภาพทางทุนมากขึ้น (เช่น steth) มีความคิดบางอย่างที่จะให้ผู้รับประกันจัดการกับการแปลงนี้ ตามที่ระบุโดยmteam ที่นี่.

แพลตฟอร์ม

มันจะไม่ "เป็นกลางที่น่าเชื่อถือ" มากนักหาก "preconfs ที่ใช้ Ethereum" เป็นเหมือน "preconfs ที่ใช้ eigenlayer" หรือ "preconfs ตาม symbiotic" มีทีมที่วางแผนที่จะไปในทิศทางนี้ แต่ไม่ใช่ข้อกําหนดที่เข้มงวดในการใช้แพลตฟอร์มดังกล่าว เป็นไปได้ที่จะสร้างมาตรฐานทั่วไปและเป็นกลางสําหรับทุกคนที่จะใช้และระบบดังกล่าวจะดูอยู่ในตําแหน่งที่ดีกว่าสําหรับการยอมรับทั่วไปเป็นตัวเลือกที่ใช้มากที่สุด

การนำมาใช้ตามมาตรฐานของสาธารณะที่ดีจะต้องใช้เพื่อให้การออกแบบก่อนการประชุมเป็นไปได้อย่างน่าเชื่อถือได้ว่า "เป็นกลางได้อย่างน่าเชื่อถือ"

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

การรวมกันกับการตั้งค่าพรีคอนฟ์ของรัฐ

ตอนนี้เราจะพูดถึง preconfs ในรายละเอียดมากขึ้น ในขณะที่เราได้พูดถึงประเภทเฉพาะของ preconf ไปก่อน (br preconfs on state) เราต้องระบุว่าพวกเขาเป็นแนวคิดที่สามารถใช้ได้เต็มรูปแบบ คุณสามารถเสนอ preconfs บนธุรกรรม bl นอกเหนือจาก brs และคุณสามารถเสนอความแข็งแรงของ preconfs ที่แตกต่างกัน:

• การรวม preconfs - ความมุ่งมั่นที่อ่อนแอกว่าว่าการทําธุรกรรมจะถูกรวมไว้ในห่วงโซ่ในที่สุด
• state preconfs - ความมุ่งมั่นที่แข็งแกร่งที่สุดที่การทําธุรกรรมในที่สุดจะรวม onchain และการรับประกันของรัฐที่เกิดขึ้น

ส่วนที่หลัง (สถานะ preconfs) เป็นสิ่งที่ผู้ใช้ต้องการให้กระเป๋าเงินของพวกเขาแสดงให้เห็น:

ฉันแลกเปลี่ยน 1 eth ในราคา 4000 ดอลลาร์ usdc และจ่ายค่าธรรมเนียม 0.0001 eth

ไม่รวม preconfs:

การทําธุรกรรมของฉันพยายามที่จะแลกเปลี่ยน 1 ETH สําหรับ $ 4000 USDC และจ่ายค่าธรรมเนียมสูงถึง 0.0001 ETH ในที่สุดจะลงจอดบน CHAIN แต่บางทีมันอาจจะประสบความสําเร็จบางทีมันอาจล้มเหลวเราจะเห็น

อย่างไรก็ตามเราควรทราบว่าการรวม preconfs สามารถใช้แทนกันได้อย่างมีประสิทธิภาพกับ preconfs ของรัฐในกรณีของการกระทําของผู้ใช้ที่ดําเนินการในสถานะที่ไม่ขัดแย้ง (เช่นการถ่ายโอนอย่างง่ายที่มีเพียงผู้ใช้เท่านั้นที่สามารถทําให้การทําธุรกรรมเป็นโมฆะ) ในกรณีนี้ คํามั่นสัญญาที่ว่าตัวอย่างเช่น "การโอน USDC ของอลิซไปยัง BOB จะรวมอยู่ในบล็อกถัดไป" นั้นดีพอที่กระเป๋าเงินจะแสดงให้ผู้ใช้เห็นว่า "คุณได้ส่ง USDC ของคุณไปยัง Bob"

นาจา, การมุ่งมั่นที่แข็งแกร่ง (สถานะ preconfs) มันยากมากที่จะได้รับ อย่างพื้นฐาน, พวกเขาต้องการ ความมั่นคงที่น่าเชื่อถือจากองค์กรที่มีการครอบครองลิขสิทธิ์ในการเสนอบล็อก (กล่าวคือ การเขียนล็อกลงในสถานะเชื่อมโยงของเครือข่าย) ในกรณีของ ethereum l1 preconfs นี้เป็นอันที่เป็นเจ้าของลิขสิทธิ์ในการเสนอใน ethereum l1 ปัจจุบัน ในกรณีของ br preconfs นี้เป็นอันที่คาดว่าเป็นเจ้าของลิขสิทธิ์ในการเสนอบล็อกใน ethereum l1 ต่อไปใน br’s lookahead (ทำให้เขาเป็นเจ้าของลิขสิทธิ์ในการเสนอบล็อกใน br) เหมือนจะเห็นด้านล่าง คำเสนอและตัวเรียงจะเป็นคำที่แทนกันได้โดยทั่วไป โดยคำแรกมักจะถูกใช้ในบริบทของ l1 และคำหลังในบริบทของ l2

การกำหนดราคาล่วงหน้า

ความแตกต่างที่ใหญ่อีกอย่างที่เราต้องทำคือประเภทของสถานะที่ preconfs เหล่านี้สัมผัสถึง:

• สถานะที่ไม่เป็นเรื่องขัดแย้ง - ไม่ใครต้องการเข้าถึงสถานะนี้ (เช่น แอลิซ ต้องการโอน USDC ให้บ็อบ)
• สถานะขัดแย้ง - ผู้อื่นต้องการเข้าถึงสถานะนี้ (เช่น สวอปในสระน้ำ eth/usdc)

preconfs เป็นข้อ จํากัด เกี่ยวกับสิ่งที่บล็อกอาจผลิตได้ในที่สุด การจํากัดพื้นที่การค้นหาสําหรับผู้สร้างโดยเนื้อแท้สามารถลดมูลค่าที่อาจเกิดขึ้นจากการสั่งซื้อได้เท่านั้น นั่นหมายความว่ามูลค่าที่น้อยลงจะถูกส่งกลับไปยังผู้เสนอ เพื่อให้เข้ากันได้กับสิ่งจูงใจ Gate.ioway จําเป็นต้องเรียกเก็บค่าธรรมเนียม preconf ≥ MEV ที่อาจเกิดขึ้นจากการ จํากัด ผลลัพธ์

นี่ง่ายมากเมื่อ MEV สูญหาย ~0 (เช่น เช่นในการโอน USDC) ในสถานการณ์นี้การเรียกเก็บค่าธรรมเนียมบางจำนวนก็สมเหตุสมผล แต่เรามีปัญหาใหญ่ - วิธีการกำหนดราคา preconfs ในสถานะโต้แยแล้ง การกำหนดราคา preconfs ล่วงหน้าเทียบกับการกำหนดราคาทันที ดูเหมือนว่าจะจ่ายน้อยกว่า ทั้งหมดเท่าเทียมกัน มันเป็นที่ไว้วางใจมากที่สุดสำหรับผู้สร้างที่จะรอจนถึงวินาทีสุดท้ายเท่าที่เป็นไปได้เพื่อจับและกำหนดราคา MEV อย่างแม่นยำ

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

การสตรีม preconfs ในรัฐที่ถูกโต้แย้งไปยังบล็อกจะขัดแย้งกับวิธีที่ผู้สร้างสร้างบล็อก การกำหนดราคา preconfs อย่างถูกต้องต้องคำนวณค่าผลกระทบ mev ในเวลาจริงของการรวมไว้ตอนนี้แทนที่จะเลื่อนการดำเนินการ ซึ่งหมายความว่าจะต้องดำเนินการและจำลองผลลัพธ์ที่เป็นไปได้ นั่นหมายความว่า Gate.ioway ตอนนี้จะต้องเป็นตัวค้นหา/สร้างที่ซับซ้อนมาก

เราได้สมมติไว้ก่อนว่า Gate.ioway และ relay จะทำการผสานกัน หากพวกเขาต้องการราคา preconfs อย่างต่อเนื่อง พวกเขายังจะผสานกับ builder ด้วย เรายังยอมรับว่า usc จะเร่งความเร็วในการผสาน builder และ prover ดูเหมือนว่าการประมูลการดําเนินการจะขายสิทธิ์ของผู้เสนอโครงการโดยตรงให้กับผู้ทรงความชำนาญ (คงจะเป็นผู้สร้าง) ที่สามารถกำหนดราคาได้

นี้นำความสมบูรณ์ของเชนการซื้อขายแบบ l1 และ br ของเอทีเธอเรียมมาไว้ในกล่องเดียวที่มีการล็อกเขียนแบบมอนโอโปลีบนสถานะของเชนทั้งหมดสำหรับช่วงเวลานั้น

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

ปัญหาการแลกเปลี่ยนที่ถูกต้อง

มีปัญหาการแลกเปลี่ยนที่เป็นธรรมกับ preconfs ที่ Gate.ioway จริงๆ ไม่ได้รับสรรพสิ่งโดยตรงให้ปล่อย preconf

พิจารณาตัวอย่างต่อไปนี้:

• ปัจจุบัน Gate.ioway มีการผูกขาด 12s
• ผู้ใช้ส่งคำขอธุรกรรมก่อนเริ่มช่องเวลา (t = 0)
• เกต.ioway รอจนถึง t = 11.5 เพื่อปล่อย preconfs ทั้งหมดที่ทำไว้ระหว่างช่องเวลาของพวกเขา โดยทิ้งเวลาเบริเพื่อให้ได้รับทั้งหมดด้วยบล็อกของพวกเขา ในเวลานั้นพวกเขาสามารถตัดสินใจว่าจะรวม preconfs ไหนถ้าพวกเขามีกำไร และจะไม่รวม preconfs ไหน

ในสถานการณ์นี้ผู้ใช้สามารถจ่ายค่า preconf แม้ว่าจะไม่ได้รับมันจนกว่าจะสิ้นสุดของช่องทาง แต่ Gate.ioway ยังสามารถทิ้งมันไว้ที่ส่วนท้ายของช่องทางหากพวกเขาตัดสินใจว่าไม่ได้ทำกำไรที่จะรวมเอาไว้ การยัดจาก Gate.ioway นี้ไม่ใช่ความผิดที่เป็นไปตามหลักวัดอย่างแน่นอนแต่นั้นอาจได้รับการสังเกตได้ในเชิงซับซ้อน).

ในความเป็นจริงแล้ว มีสิ่งที่เป็นสิ่งตั้งใจสำหรับ Gate.io เพื่อการพิจารณาก่อนจนกว่าจะถึงสิ้นสุดเมื่อมีอัตราส่วนของข้อมูลไม่เท่ากัน ก็จะมี MEV. การรักษาธุรกรรมให้เป็นส่วนตัวจะช่วยให้ผู้สร้างมีมุมมองที่ทันสมัยยิ่งขึ้นเกี่ยวกับสถานะของโลกทําให้พวกเขามีความเสี่ยงด้านราคาที่ดีขึ้นและจับ MEV ไม่มีฉันทามติเกี่ยวกับชุดของ preconfs ที่มอบให้กับผู้ใช้ดังนั้น Gate.ioway จึงไม่สามารถรับผิดชอบได้ที่นี่

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

preconfs ชั้นฐาน l1

ด้วยจุด preconf ทั่วไปออกจากทางตอนนี้เราจะพูดถึงความแตกต่างของ preconfs L1 แม้ว่าเราจะไม่ได้กล่าวถึงพวกเขาก่อนหน้านี้ แต่ก็มีโครงการที่สร้างสิ่งเหล่านี้และการมีปฏิสัมพันธ์กับ BR preconfs จะมีความสําคัญ

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

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

ทีมพรีคอนฟ์ทั้งหมดเหล่านี้มีความทะเยอทะยานมากกว่า (เช่น มีระบบพรีคอนฟ์รัฐบาล การประมูลบล็อกบางส่วน สล็อตหรือการประมูลสล็อตบางส่วน) ดังนั้นสิ่งที่ยังคงยับยั้งพวกเขาคืออะไร?

• ความรับผิดชอบ - การละเมิดความมุ่งมั่นควรสามารถพิสูจน์ได้บน Onchain เพื่อลดความเสี่ยง การพิสูจน์การรวมธุรกรรมนั้นเป็นเรื่องที่ง่ายแต่ไม่ชัดเจนว่าจะกระทำการสอดคล้องกับความมุ่งมั่นอื่น ๆ เช่นการประมูลช่องว่าง
• ความต้องการทุน - การให้คำสัญญาอย่างสมมติหมายความว่ามูลค่าของการละเมิดคำสัญญาอาจสูงอย่างสมควร Gate.ioways อาจจะต้องคาดหวังที่จะต้องลงทุนจำนวนมาก (เช่นพัน ETH) เพื่อให้บริการเหล่านี้ นั่นอาจจะกลายเป็นเงินทุนร่วมกันที่ใหญ่ที่สุด (เช่นบริษัทซื้อขายหุ้นใหญ่หรือ Coinbase) และปล่อยออกมาจากธุรกิจขนาดเล็ก
• ราคา - มีคำถามหลายอย่างที่ยังไม่ได้รับการตอบคำถามเกี่ยวกับวิธีการกำหนดราคาสำหรับสิ่งที่เหมือนกับ continuously streamed state preconfs แม้ว่าเราจะตัดสินใจว่าเป็นเรื่องที่เป็นไปได้และมีค่า
• การมีส่วนร่วมของเครือข่าย - นี่อาจเป็นจุดสําคัญและพื้นฐานที่สุด ดังที่เราได้กล่าวไปแล้วมีเพียงผู้เสนอปัจจุบันที่มีการเขียนล็อคเกี่ยวกับรัฐเท่านั้นที่สามารถให้คํามั่นสัญญาเช่น preconfs ของรัฐ ในทางทฤษฎี 100% ของผู้เสนอสามารถเลือกใช้ระบบนี้และเลียนแบบสิ่งนี้ได้ ในทางปฏิบัติสิ่งนั้นจะไม่เกิดขึ้น

mev-boost ผลิตภัณฑ์ที่เรียบง่ายแต่มีประวัติศาสตร์ยาวนานที่มีกำไรมากมายในการดำเนินงานมีส่วนร่วม >92%สำหรับบริบท (เป็นไปได้ที่สูงขึ้นอีกบ้างเพราะว่านี่ไม่ได้คิดรวมเอาการmin-bid). บริการ preconf ใหม่จะได้รับอัตราการมีส่วนร่วมที่ต่ํากว่ามากอย่างแน่นอน แต่แม้ว่าจะสามารถเข้าสู่ช่วง ~ 90% ได้ แต่ก็ดูเหมือนจะไม่ใช่ผลิตภัณฑ์ที่มีประโยชน์สําหรับผู้ใช้ทั่วไป คุณไม่สามารถบอกผู้ใช้ 10% ของเวลา "โอ้ขออภัยไม่มี preconfs ใช้ได้ในขณะนี้ตรวจสอบกลับในบิต."

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

การตั้งค่าก่อน l2 based rollup

br preconfs ต้องมาจากผู้เสนอ BL (นั่นคือเหตุผลที่พวกเขา "ตาม") สิ่งนี้ทําให้พวกเขาต้องเดิมพันหลักประกันบางส่วนและเลือกใช้เงื่อนไขการเฉือนเพิ่มเติม (เช่น preconfs ที่พวกเขาให้ไว้จะทําให้เป็นไปตามที่สัญญาไว้) ผู้เสนอใด ๆ ที่เต็มใจที่จะทําเช่นนั้นสามารถทําหน้าที่เป็นซีเควนเซอร์ BR และให้ preconfs

ที่สําคัญ preconfs br เหล่านี้เป็น preconfs ของรัฐไม่เพียง แต่รวม peconfs สิ่งนี้เป็นไปได้เพราะ BRS กําลังเลือกใช้การออกแบบที่พวกเขาให้การผูกขาดซีเควนเซอร์แบบหมุนให้กับผู้เสนอ BL ที่ลงทะเบียนเป็น Gate.ioways

ในปัจจุบัน ผู้ตรวจสอบ Ethereum 1 คนเป็นผู้เสนอชื่อสำหรับแต่ละช่อง และตารางเสนอชื่อเป็นที่ทราบเสมอสำหรับยุคปัจจุบันและยุคถัดไป ยุคคือช่อง 32 ช่องดังนั้นเราทราบเสมอถึงผู้เสนอชื่อต่อไป 32-64 คนในเวลาที่กำหนด การออกแบบทำงานโดยการให้ซีเควนเซอร์ที่ใช้งานถัดไป (เช่นซีเควนเซอร์ถัดไปในการมองไกล) เป็นเจ้าของอำนาจพิเศษในการจัดลำดับธุรกรรมสำหรับระบบ BRS ที่เลือกใช้ระบบก่อนการตั้งค่านี้ Gate.io ต้องลงนามเพื่อกระจายสถานะของเส้นสัญญา

โปรดทราบว่าผู้เสนอทุกคน (แม้แต่ผู้ที่ยังไม่ได้เลือกเป็น Gate.ioway) มีสิทธิ์ แต่ไม่ใช่ภาระผูกพันที่จะรวมธุรกรรมที่ได้รับ preconfs โดยซีเควนเซอร์ (เช่นผู้เสนอที่เลือกเป็น Gate.ioway) พวกเขาอาจทําหน้าที่เป็นผู้รวมตราบใดที่พวกเขามีรายการธุรกรรมทั้งหมดที่ได้รับการยืนยันล่วงหน้าจนถึงเวลานั้น (ซีเควนเซอร์สามารถสร้าง BL Blob ที่มีธุรกรรม BR และนินทาพวกเขา)

source: การจัดลำดับ Ethereum, justin drake

กระแสธุรกรรมทำงานดังนี้:

1. ผู้ใช้ BR ส่งธุรกรรมไปยังซีเควนเซอร์ถัดไปใน Lookahead (ผู้เสนอช่อง N + 1 ในภาพด้านล่าง)
2. ตัวเรียงลำดับจะให้การยืนยันก่อนล่วงหน้าสำหรับสถานะผลลัพธ์ทันที (เช่นผู้ใช้แลกเปลี่ยน 1 eth เป็น $4000 usdc บน br และจ่ายค่าธรรมเนียม 0.0001 eth)
3. ในจุดนี้ ผู้รวมที่ใดก็ได้สามารถรวมธุรกรรมที่เรียงลำดับ (ผู้เสนอข้อเสนอสล็อต n ทำดังภาพด้านล่าง)

แหล่งที่มา: อีเธอร์เรียมซีเควนซิ่ง, justin drake

ถ้าผู้ร่วมอื่น ๆ ไม่รวม preconfs จากนั้น sequencer ที่ให้ไว้สามารถรวมเข้าไปในเครือข่ายเมื่อถึงตามคิวของตนเองเป็นผู้เสนอชื่อบล็อก ตัวอย่างเช่น ในภาพด้านบนเราสมมุติว่าผู้ร่วมช่อง n ตัดสินใจไม่รวม preconfs ที่ sequencer ช่อง n+1 ให้ แล้ว sequencer ช่อง n+1 จะรับผิดชอบในการรวม preconfs ทั้งหมดที่ได้ให้ในช่อง n และช่อง n+1 เมื่อส่งบล็อก bl สำหรับ n+1 นี้ นี้ช่วยให้ sequencer สามารถให้ preconfs ได้อย่างมั่นใจสำหรับระยะเวลาทั้งหมดระหว่างตัวเองและ sequencer คนสุดท้ายเป็นใครก็ได้

เพื่อลดความซับซ้อนของคําอธิบายข้างต้นเราเพิ่งสันนิษฐานว่าผู้เสนอ L1 จะปฏิบัติตามบทบาท preconfer นี้ ตามที่อธิบายไว้ก่อนหน้านี้แม้ว่าจะไม่น่าจะเป็นเช่นนั้น มันจะต้องใช้เอนทิตีที่ซับซ้อนในการกําหนดราคา preconfs, เรียกใช้โหนดเต็มรูปแบบสําหรับ BRs ทั้งหมด, มีการป้องกัน DOS และแบนด์วิดธ์ที่เพียงพอสําหรับธุรกรรม BR ทั้งหมด, ฯลฯ Ethereum ต้องการเก็บผู้ตรวจสอบความถูกต้องไว้ไม่ซับซ้อนมาก, ดังนั้นผู้เสนอจะสันนิษฐานว่า outsource preconfs ไปยังหน่วยงานอื่นในลักษณะเดียวกับที่พวกเขา outsource การผลิตบล็อก L1 เต็มรูปแบบผ่าน MEV-boost วันนี้.

ผู้เสนอข้อเสนอสามารถใช้กลไก onchain หรือ offchain เพื่อเป็นตัวแทน Gate.io ได้และสามารถทำได้จนถึงเวลาสล็อต ก่อนที่บทบาทนี้จะถูกเปลี่ยนแปลงโดยผู้ส่งสัญญาณ เห็นว่าบทบาทนี้จะถูกเปลี่ยนแปลงโดยผู้ส่งสัญญาณ อีกทั้งยังเป็นไปได้ว่าพวกเขาจะต้องผสานกับผู้สร้างด้วย

source: การจัดลำดับตามพื้นฐาน, justin drake

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

ethereum rollups - มันจะเกิดขึ้นอย่างไร?

ด้วยพื้นหลังที่เพียงพอที่จะใช้งานได้ - Ethereum rollups ควรจะพื้นฐานอย่างไร? จริงๆ แล้วมีคำถามที่ซ่อนอยู่สองข้อที่นี่:

1. ควร rollups ethereum จํานวนมากแบ่งปันซีเควนเซอร์?
2. ถ้าใช่ควรเป็นซีเควนเซอร์ตาม (เช่นเกี่ยวข้องกับผู้เสนอ Ethereum BL และโครงสร้างพื้นฐาน MEV โดยรอบ) หรือไม่?

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

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

ตอนนี้ควรที่ตัวควบคุมที่ใช้ร่วมกันนี้จะเป็นตัวควบคุมที่ใช้ Ethereum หรือไม่?

เทคนิค (การสัญญาของผู้เสนอ)

ฉันไม่เห็นเหตุผลทางเทคนิคที่แข็งแกร่งสำหรับการใช้ Ethereum เป็นตัวจัดลำดับ การประสานสมรรถนะระหว่าง BRS และ Ethereum L1 จะถูก จำกัด อย่างมากเนื่องจากไม่สามารถดำเนินการได้ใน L1 อย่างเป็นนัย(เช่น ไม่สามารถทำการเขียนล็อกบนสถานะ L1 ได้อย่างสม่ำเสมอ) เวลาบล็อกยาว (12 วินาที) และข้อว่างใจว่าธุรกรรม BR ที่ต้องการที่จะปฏิสัมพันธ์กับ L1 จะต้องทำการสร้างรูปแบบใหม่พร้อมกับ L1 ไม่มีเรื่องราวฟรีที่นี่ สิ่งนี้ไม่ปลดล็อกผลิตภัณฑ์ที่มีคุณค่าที่สำคัญต่อผู้ใช้เมื่อเทียบกับตัวจัดลำดับที่แชร์ภายนอกอื่นๆ

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

นี่เป็นเพียงการเน้นว่ามีความซับซ้อนทางเทคนิคและสังคมที่แท้จริงในการสร้างและเลือกทุกคนในการประมูลที่ใช้ร่วมกันนี้ซึ่งมีต้นทุนจริงซึ่งในใจของฉันน่าจะมีมากกว่ามูลค่าเพิ่มเติมทางทฤษฎีที่สร้างขึ้นที่นี่ คุณสามารถสร้างการออกแบบทางเทคนิคที่ดีกว่ามากเพื่อเรียกใช้สิ่งนี้จากหลักการแรกหากเราไม่ได้พยายามรัดไว้ด้านบนของ Ethereum L1 (เช่นเพียงแค่มีกลไกฉันทามติที่รวดเร็วอย่างง่ายที่สร้างขึ้นเพื่อจุดประสงค์นี้) ไม่ต้องพูดถึงความจริงที่ว่าการประมูลแบบผสมผสานดังกล่าวจะสร้างการระเบิดแบบทวีคูณในความซับซ้อน

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

สังคม (ความเป็นที่น่าเชื่อถือ)

ฉันเห็นว่ามีข้อโต้แย้งทางสังคมที่ถูกต้องสำหรับตัวจัดลำดับที่ใช้ Ethereum

เหมือนที่ได้กล่าวไปก่อนหน้านี้ ไม่มีความสงสัยว่า "การจัดเรียง" เป็นสิ่งที่ขายใน brs เบื้องต้น นั่นเป็นเรื่องดี แต่ฉันไม่คิดว่าสิ่งนี้จะยังอยู่ต่อไป การเป็น br แรกนั้นเยี่ยงยิ่ง แต่การเป็น br ที่ 8 ก็ไม่เท่ากับการเป็นเจ้าเดียวกัน จึงต้องมีคุณค่าเพิ่มเติมอื่น ๆ

ฉันคิดว่าความเป็นกลางที่น่าเชื่อถือของซีเควนเซอร์ที่ใช้ Ethereum อาจเป็นค่านั้น มันน่าจะเป็นข้อโต้แย้งที่แข็งแกร่งที่สุดในความโปรดปรานของการออกแบบดังกล่าวอย่างน้อย มีโซ่จํานวนมากที่ต้องการรับซีเควนเซอร์แบบกระจายอํานาจออกจากชั้นวาง หากในที่สุดเราสามารถออกแบบโครงสร้างพื้นฐานที่เพียงพอนอกเหนือจากสิ่งนี้ซึ่งช่วยปรับปรุง UX ข้ามสายโซ่ได้ก็ยิ่งดียิ่งขึ้น จากโครงการที่ต้องการการออกแบบดังกล่าวฉันคิดว่าพวกเขาจํานวนมากลังเลที่จะ "เลือกข้าง" ด้วยโปรโตคอลของบุคคลที่สาม ตามที่ระบุไว้ก่อนหน้านี้ลองนึกภาพว่าคุณเป็นเครือข่ายแอปที่มีโครงสร้างพื้นฐานทั่วไปบางอย่างเช่น ENS และคุณต้องการสะสม คุณไม่ต้องการเลือกซีเควนเซอร์ที่ใช้ร่วมกันของ Arbitrum (สมมุติฐาน) และปิดฝูงชนในแง่ดีหรือในทางกลับกัน

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

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

รวมเข้าด้วยกันอย่างรวดเร็ว

ชั้นล่างที่รวดเร็ว

เราควรเข้าใจว่าเราสามารถมี brs บนบล็อกเชนช้าเช่นเดียวกับ ethereum ได้ คุณสามารถเพิ่มการยืนยันก่อนหน้าที่เชื่อถือได้เพื่อให้มีความสะดวกสบายมากขึ้น และคุณยังสามารถรับประกันความปลอดภัยเมื่อเคลื่อนย้ายระหว่างเชนโดยใช้การรับรองทางเศรษฐศาสตร์หรือการรับรองทางกลวิธี

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

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

อย่างไรก็ตามเราไม่ได้พูดถึงความสามารถในการเป็น br โดยไม่ต้องมี preconfs อย่างจริงจัง เราเพียงแค่ทิ้งสิ่งนี้ไปเพราะเอธีเรียมช้าและผู้ใช้ไม่อดใจ

ดังนั้นทำไมเราไม่ใช้ fast bl สำหรับ brs เลยล呢?

นี่แก้ไขเรื่องซับซ้อนทั้งหมดแทบทุกกรณีและข้อกังวลที่เรามีก่อน เราไม่ต้องการกรณีที่แปลกปลอมที่ Gate.ioways มีความล้มเหลวในการดำเนินการ (ซึ่งส่งผลเช่นเดียวกับความล้มเหลวในเรื่องความปลอดภัยที่นี่) เราไม่ต้องการให้พวกเขาย้อนกลับจาก preconfs ที่ได้สัญญาไว้ (เช่น ความล้มเหลวในเรื่องความปลอดภัย) และเราไม่ต้องการ ethereum reorgs นี่คือเหตุผลที่ถูกต้องที่ทำให้มีความเห็นร่วม

เลเยอร์ทั้งหมดถูกลบสิ้นแล้ว ให้ชีวิตอยู่กับเลเยอร์การจัดลำดับ!

ส่วนใหญ่ของการสนทนาเกี่ยวกับตัวจัดลำดับที่เกิดความขี้เกียจนั้นมักจะพิจารณาว่าเป็นตัวจัดลำดับที่ครอบคลุมซึงจะส่งข้อมูลของมันไปยังชั้นข้อมูลอื่น ๆ ตัวอย่างเช่น ครั้งแรกสองของ astria’s rollupsฟอร์มาและเปลวไฟ) จะใช้ Celestia เป็นชั้น DA ของพวกเขา โดยการตกลงของ Astria จะเรียงลำดับ Rollup เหล่านี้ จากนั้นจะส่งข้อมูลของพวกเขาไปยัง Celestia

การผสมผสานนี้เป็นอันดับที่ดีมาก เนื่องจากว่าพวกเขาเป็นคู่เสมือนที่ชัดเจน - อาสเตรียจัดหาโครงสร้างการจัดลำดับทั้งหมดและเซลเซเตียจัดหาการตรวจสอบที่มีการลดความเชื่อมั่นผ่านการสุ่มตัวอย่างการมีข้อมูลที่พร้อมใช้งาน (DAS).

อย่างไรก็ตาม, Astria สามารถใช้ในการสร้างลำดับของ Rollup ที่เป็น Native กับ Ethereum, Bitcoin, Solana หรืออะไรก็ตามที่คุณต้องการได้เช่นกัน ตัวอย่างเช่น มันสามารถตั้งค่าให้ใช้เป็น Preconfer สำหรับ Ethereum "brs with preconfs" (เช่นแทนที่ Gate.ioway แบบกลาง ๆ, เนื่องจาก lazy sequencer พื้นฐานก็คือการส่งข้อมูลแบบกระจายที่ได้รับการสนับสนุนและกระจายอย่างไร้สัดส่วน)

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

อย่างไรก็ตาม ตามที่ฉันได้ระบุไว้ในระบบ Rollups สืบทอดความปลอดภัยได้หรือไม่?, โซ่ที่เร็วเช่น astria อาจเพิ่มเส้นทางที่ช้าสำหรับ das (เพื่อเพิ่มความสามารถในการตรวจสอบ) และโซ่ที่ช้าเช่น celestia อาจเพิ่มเส้นทางที่เร็วสำหรับการจัดลำดับ (โดยมีการสมมติความไว้วางใจจากส่วนใหญ่และไม่มี das) ที่เรียกว่า บล็อกเร็วสี่เหลี่ยมช้า.”

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

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

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

เลเยอร์ฐานที่เร็วกว่า vs. เลเยอร์ช้า + การตั้งค่าล่วงหน้า

แต่คุณยังสามารถใช้ astria เพียงแค่เป็น bl สำหรับ rollups ได้อีกด้วย ตัวรวมลำดับที่แบ่งปันสามารถคิดเป็น bls ที่ถูกปรับแต่งไว้สำหรับ brs ของตนเองได้

เมื่อ bl ของคุณเร็ว br ของคุณก็ไม่จำเป็นต้องมี preconfs เพราะมันก็ได้การยืนยันที่เร็วออกมาอย่างรวดเร็ว! แล้ว rollup ของคุณจะได้ความปลอดภัยแบบ real-time จาก bl ของคุณ ต่างจาก brs + preconfs ที่เสียคุณสมบัตินี้

brs โดยไม่มี preconfs นั้นจริงๆ แล้วเป็นวิธีที่มีเหตุผลที่สุดในการสร้าง rollup นั่นคือเหตุผลที่ rollups ทุกตัวในปัจจุบันเริ่มต้นจากนั่น:

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

เรากำลังสร้างสิ่งเดียวกันทุกคน

ความโมดูลาริตีกำหนดไว้

ดังนั้นเราจึงเห็นว่าเราสามารถ aggreGate.io โซ่โมดูลาร์กลับมารวมกันได้อย่างไรโดยให้ความสามารถในการประกอบแบบซิงโครนัสสากล (USC) แน่นอนว่ามีข้อแลกเปลี่ยน แต่พวกเขาแนะนําระดับความสามัคคีที่มีความหมายในขณะที่รักษาความยืดหยุ่นได้มากกว่าการใช้เครื่องสถานะเดียว นอกจากนี้ยังมีกรณีที่น่าสนใจมากสําหรับฉันว่าความสามารถในการแต่งแบบอะซิงโครนัสเป็นสิ่งที่เราต้องการสําหรับกรณีการใช้งานส่วนใหญ่ เราต้องการเวลาแฝงต่ําประสิทธิภาพและ UX ที่ดี อินเทอร์เน็ตเป็นแบบอะซิงโครนัสและใช้งานได้ดีเป็นนามธรรมที่ดีที่ทั้งหมดออกไป ความสามารถในการแต่งเพลงเป็นการเพิ่มมูลค่ามหาศาลของ crypto แต่ความสามารถในการแต่งเพลง≠ซิงโครนี

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

ethereum + preconfs → solana?

ตอนนี้เรามาเปรียบเทียบเกมสุดท้ายที่นี่ โดยเฉพาะอย่างยิ่งเราจะเปรียบเทียบ Solana endgame กับ Ethereum's endgame ถ้ามันเกิดเป็นทางนี้โดยการสูญเสียความสามารถในการเชื่อมโยงและประสบการณ์ผู้ใช้ร่วมกันกับ based rollups + preconfs

ในวิสัยทัศน์นี้เรามี BRs เหล่านี้จํานวนมากโดยใช้ซีเควนเซอร์ที่ใช้ Ethereum Gate.ioways กําลังสตรีมผู้เสนอสัญญาอย่างต่อเนื่อง (เช่นไม่มีน้ําหนักฉันทามติใด ๆ ) preconfs ให้กับผู้ใช้ที่เวลาแฝงต่ําจากนั้นผู้เสนอ ethereum จะมอบพวกเขาให้เป็นบล็อกเต็มทุกครั้ง นี่อาจฟังดูคุ้นเคยเพราะนั่นคือสิ่งที่เราอธิบายไว้สําหรับ Solana ก่อนหน้านี้ด้วยการสตรีมแบบฉีก!

ดังนั้น นี่เป็นเพียงซอลานาที่ซับซ้อนมากขึ้นหรือเปล่า? ความแตกต่างสำคัญที่นี่อยู่ที่เวลาสล็อต:

Ethereum พยายามเพิ่มสิ่งนี้นอกเหนือจากห่วงโซ่ที่ช้าอย่างชัดเจนนําเสนอปัญหาได้อย่างรวดเร็วก่อน:

• ความเห็นร่วมใน Ethereum ช้าเกินไปสำหรับผู้ใช้งาน ดังนั้นวิธีเดียวที่จะได้รับการใช้ประโยชน์แบบเร็วที่น่าเชื่อถือและเนื้อหาที่เป็นกลางได้คือการมี preconfs ที่ได้รับการยอมรับเป็นพื้นฐาน เจาะจง ปัญหาหลักของ Ethereum ในปัจจุบันคือการรวมลายเซ็นเจ้าของเพราะขนาดของกลุ่มผู้ตรวจสอบที่มีอยู่ (MaxEBและการรวมลายเซ็นต์ที่ปรับปรุงแล้วอาจช่วยได้ที่นี่
• นี้ส่งผลให้มีการครอบครองที่ยาวนานมากขึ้น ซึ่งทำให้มีสิทธิและเสรีภาพที่มากขึ้นในการจับเอ็มอีวีมากขึ้นโดยการกระทำอย่างไม่ซื่อสัตย์ (เช่น การไม่เผยแพร่ก่อน)
• หาก Gate.ioways เริ่มล่าช้าหรือควบคุมการยืนยันธุรกรรม (preconfs) ผู้ใช้ที่เลวร้ายที่สุดก็ต้องพึ่งพาเวลาสล็อตของอีเธอร์เรียม แม้ว่าโปรดิวเซอร์บล็อก Solana จะหยุดสร้างบล็อกแบบต่อเนื่องและสตรีมมิ่งภายในการครอบครองที่ได้รับจัดสรรของพวกเขาเนื่องจากมันน่าจะมีเหตุผลที่เหมาะสมสำหรับพวกเขาที่จะทำอย่างไรก็ตามอย่างไรก็ตามเกือบเท่ากันเพราะเหตุผลที่แท้จริง), ในกรณีที่แย่ที่สุดจะต้องพึ่งพาบนความเห็นร่วมกันที่หมุนอย่างรวดเร็วการควบคุมสี่ช่องวันนี้จำเป็นต้องใช้เพื่อความเชื่อถือของเครือข่าย.
• ในปฏิบัติจริงนั้น มีโอกาสที่จะมีเพียงไม่กี่วิธี Gate.ioways อย่างน้อยก็ตอนแรก ทำให้มีชุดผู้ดำเนินการที่มีลักษณะที่มากกว่าโซลาน่า
• ความต้องการหลักทรัพย์ที่สูงอาจจะสูงมากสำหรับผู้เสนอ (โน้ตว่าพื้นที่การออกแบบยังคงเป็นงานที่กำลังดำเนินการ)
• ความกังวลเกี่ยวกับปัญหาการดำเนินการที่มีความสำคัญอย่างยิ่งที่นี่ (เนื่องจากปัญหาการดำเนินการของผู้ให้บริการที่นำไปสู่การตัดสินใจล่วงหน้าที่เป็นปัญหาในการรักษาความปลอดภัยสำหรับผู้ใช้ และต้องมีการตัดสินใจที่เป็นอันตรายอย่างรุนแรง)

ทั้งหมดนี้ถูกแก้ไขด้วยความเห็นที่รวดเร็ว ระบบเหล่านี้ทั้งหมดก็คือเหตุผลที่ทำให้เราสร้างระบบ BFT ในที่แรก ดังนั้นทำไม Ethereum ไม่ทำให้ความเห็นของตนเร็วขึ้น? มีการแลกเปลี่ยนที่ไม่เป็นทางการบางส่วนเมื่อมีเวลาบล็อกในเลเยอร์ฐานที่ต่ำมากหรือไม่?

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

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

source: ข้อมูลเสมอ

เกมการจับเวลาเป็นหัวข้อที่ได้รับความสนใจอย่างมากในช่วงเวลาที่โด่งดังอย่างหนึ่งพ็อดแคสต์ Justin vs. toly banklessจากไม่กี่สัปดาห์ก่อน:

เช่นว่าคุณเร็วกว่าทุกคน 100 มิลลิวินาที

หากคุณมีช่องว่าง 1 วินาที คุณสามารถทำได้มากกว่าทุกคน 10%

ถ้าคุณมีช่องเวลา 10 รูปแบบ คุณสามารถทำได้เพิ่มอีก 1% มากกว่าคนอื่น ๆ

— jon charbonneau (@jon_charbไม่มีข้อความที่จะถูกแปล4 มิถุนายน 2024

จัสติน โต้แย้งว่าเกมเวลาจะเป็นปัญหาและรางวัลเพิ่มขึ้นจะเป็นสิ่งที่สำคัญตลอดเวลา โทลี โต้แย้งว่าเกมเวลาจะไม่เป็นปัญหาและรางวัลเพิ่มขึ้นจากการสกัด mev เพิ่มเติมไม่เพียงพอที่จะกังวลเกี่ยวกับ

ส่วนตัวฉันพบว่ายากที่จะเพิกเฉยต่อความสำคัญของการจับเวลาเกมได้ที่นี่:

• เราเห็นพวกเขาใช้งานอยู่บนเอธีเรียมแล้ววันนี้ข้อวิจารณ์เกี่ยวกับ Solanaเป็นเพราะว่า MEV กลายเป็นสิ่งที่เป็นปกติทางสังคมใน Ethereum มาก่อน แต่สิ่งนี้ไม่ได้ทำให้เชื่อได้เมื่อมีการประท้วงของประชาชนต่อการจัดเวลาเกมในช่วงเร็วๆนี้ ที่ตอนนี้กลายเป็นการยอมรับที่จะออกแบบโลกใหม่นี้
• รางวัล mev มีความสำคัญ - เรากำลังพูดถึงหลายพันล้านดอลลาร์ในการชำระเงิน mev ที่นี่ไม่ใช่เพนนีใต้เบาะโซฟา แม้แต่การทํา "อีกเพียงไม่กี่เปอร์เซ็นต์" กับเรื่องนี้ก็เป็นเงินจํานวนมหาศาล
• แม้ว่าคุณอาจจะไม่เชื่อว่าผู้เสี่ยงโชคมีความไวต่อผลตอบแทนในเรื่องของขอบเขตการเสี่ยงโชคผู้ประกอบการจริงกำลังดำเนินธุรกิจ และนั่นก็ตรงไปที่บรรทัดล่างของพวกเขา
• การพึ่งพาผู้เล่นใหญ่ที่เป็นอัลทรูอิสติกทำให้ Solana ง่ายขึ้นตัวอย่างเช่น มันมีผู้ร่วมลงทุนหลักและนักลงทุนในช่วงเริ่มต้นของวงจรชีวิตของมัน แต่นั้นไม่สามารถที่จะคงอยู่ได้เมื่อเครือข่ายทำการกระจายตัวไปอีก.

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

preconf.wtf เกิดอะไรขึ้นที่ zuberlin ที่ผ่านมา และอาจจะไม่แปลกใจว่าทุกคนกำลังพูดถึง preconfs และ based rollups และนั่นเป็นสิ่งที่ดีมาก แต่ส่วนตัวผมค้นพบ บรรยายของวิทาลิคบนรายการการรวมหนึ่งบิตต่อผู้รับรองและการพูดของบาร์นาเบเท่านั้นโอเวอร์โหลดผู้เสนอข้อเสนอการดำเนินการแทน (จาก mev-boost เป็น epbs เป็น aps)เป็นสิ่งสำคัญที่สุดต่ออนาคตของ Ethereum

แหล่งที่มา: บาร์นาเบ มอนโน, จาก mev-boost ไปยัง epbs ไปยัง aps

การสนทนาเกี่ยวกับ preconf และ based rollup ได้เริ่มต้นเพิ่งได้เพิ่มเสถียรภาพเมื่อเร็ว ๆ นี้ และผมแน่ใจว่ายังคงระวังอยู่มากกว่าเกมสุดท้าย:

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

แหล่งที่มา: พิสูจน์การปกครอง

อย่างเชิงประจักษ์ว่า โครงสร้างการผลิต mev ของ ethereum l1 ในปัจจุบันมีการเซ็นเซอร์บล็อกแบบเรียลไทม์มากกว่า l2 ที่ใช้ sequencers แบบกลาง

l2s สามารถรับ cr ของ l1 ได้แล้ว (ซึ่งยังดีอยู่) โดยไม่ต้องอิงตาม. based preconfs จะไม่ได้รับความปลอดภัยแบบ real-time ของโปรโตคอล ethereum แต่จะได้รับความปลอดภัยแบบ real-time จากผู้ให้บริการโครงสร้างพื้นฐานน้อยๆ ที่เป็นส่วนกลาง. สำหรับการรับ cr แบบ real-time ที่ดีขึ้น ทางเลือกที่ดีที่สุดคือการออกแบบจัดลำดับของข้อมูลให้กับ decentralized sequencer ที่ทำงานด้วย simple bft consensus ซึ่งจะมีความแข็งแกร่งกว่าการที่จะให้มีการ centralize หลายๆ โซนเข้ามาที่จุด bottleneck ที่ถูก centralize อยู่ในปัจจุบัน. สถานการณ์นี้อาจปรับปรุงได้ด้วยการเปลี่ยนแปลงเช่น execution auctions และ inclusion lists แต่นั่นไม่ได้อยู่ในอนาคตใกล้เคียง

เมื่อพิจารณาทั้งหมดนี้แล้วมันไม่ชัดเจนสําหรับฉันว่าการขยายการพึ่งพาโครงสร้างพื้นฐาน MEV ของ Ethereum L1 แล้วดึงดูดมันสําหรับ L2 เป็นความคิดที่ดีในขั้นตอนนี้เมื่อมีคนจํานวนหนึ่งที่สร้างและถ่ายทอดบล็อก Ethereum ทั้งหมดบล็อกที่ปราศจากการเซ็นเซอร์ของ Ethereum ส่วนใหญ่ในปัจจุบันพึ่งพาผู้สร้างคนเดียว (ไททัน) และยังไม่มีการใช้เครื่องมือ CR ในโปรโตคอล สิ่งนี้ให้ความรู้สึกเร่งเร้าอย่างรุนแรงในจุดที่เปราะบาง Ethereum ควรทํางานเพื่อปรับปรุง UX ของ L2 อย่างแน่นอน แต่ไม่ใช่ค่าใช้จ่ายของคุณสมบัติพื้นฐานทั้งหมดที่เราต้องการตั้งแต่แรก

สรุป

เรากำลังสร้างสิ่งเดียวกันทั้งหมด

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

ความแตกต่างทางเทคนิคที่ละเอียดอ่อนระหว่างพวกเขาสามารถมีผลมีนัยสำคัญต่อสิ้นสุดที่พวกเขาจะลงไป และเราไม่สามารถประมาณความสำคัญของการเดินทางในระบบเหล่านี้ได้แม้ว่าพวกเขาจะหันไปสู่จุดสิ้นสุดที่คล้ายคลึงกัน

นอกจากนี้ มันใกล้เคียงกับการนึกคิดถึงบางสิ่งที่เป็นไปไม่ได้มากตามที่วิทย์พูด:

"หมายเหตุหนึ่งของข้อควรระวังที่ฉันมีสําหรับ APS คือผมคิดว่าจากมุมมองทางเทคนิคอย่างหมดจดที่จริงผมคิดว่ามันค่อนข้างเบาและเราสามารถดึงมันออกได้ทั้งหมดโดยมีโอกาสค่อนข้างน้อยของข้อผิดพลาดทางเทคนิค แต่จากมุมมองทางเศรษฐกิจมีโอกาสมากขึ้นสําหรับสิ่งที่ผิดพลาด

เช่น eip-1559 เราสามารถค้นหาด้วยทฤษฎีได้ โดยเราไปที่การประชุมทางเศรษฐศาสตร์ที่น่ารักและเรียนรู้เกี่ยวกับอันตรายของการประมูลราคาแรกและว่าพวกเขาเป็นอย่างไรและคิดค้นวิธีการใช้กลไกที่เป็นราคาคงที่ภายในแต่ละบล็อก และเราสามารถทำได้มากกับเศรษฐศาสตร์จิตวิทยาเล็กน้อย

แต่แอปไม่เหมือนกันใช่ไหม และคำถามว่า แอปจะนำไปสู่ citadel หรือ jane street หรือ justin sun หรือผู้ใดก็ตามที่จะผลิตบล็อกเอเธอเรียม 1% หรือ 99% นั้นเป็นเรื่องยากมาก อาจเป็นไปไม่ได้ในการหาคำตอบจากหลักการพื้นฐาน

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

ใช่ฉันไม่รู้ว่าจะเกิดอะไรขึ้นเช่นกัน เราจะต้องรอดู ไม่ว่าในกรณีใดในขณะที่เราทุกคนมาบรรจบกันกับสิ่งที่ endgame นี้เรามีหลายอย่างที่เหมือนกันมากกว่าไม่ดังนั้นอย่าลืม...

คำเตือน:

1. บทความนี้เป็นการนำเอามาจาก [ dba]. ส่งต่อชื่อเดิม 'เราทุกคนกําลังสร้างสิ่งเดียวกัน' ลิขสิทธิ์ทั้งหมดเป็นของผู้เขียนต้นฉบับ [Jon Charbonneau]. หากมีการคัดค้านการเผยแพร่นี้โปรดติดต่อ Gate.io เรียนรู้ ทีมและพวกเขาจะจัดการกับมันทันที
2. คำแนะนำในบทความนี้เป็นความคิดเห็นส่วนบุคคลของผู้เขียนเท่านั้น และไม่เป็นการให้คำแนะนำใด ๆ เกี่ยวกับการลงทุน
3. การแปลบทความเป็นภาษาอื่นๆ โดยทีม Gate.io learn ถูกดำเนินการ ยกเว้นกำหนดไว้เป็นอย่างอื่น การคัดลอก การกระจาย หรือการลอกเลียนแบบบทความที่ถูกแปลเป็นภาษาอื่นๆ นั้นถูกห้าม