ในการตั้งค่าของ Astria ตัวเรียงลำดับจะส่งบล็อกที่สั่งไปยังเลเยอร์ DA และไปยังโหนดค่าสะสมด้วย Rollups ได้รับการค้ำประกันขั้นสุดท้ายแบบนุ่มนวลจากผู้สั่งซื้อและการรับประกันขั้นสุดท้ายแบบตายตัวจากชั้น DA (หลังจากสิ้นสุดการบล็อกแล้ว) จากนั้นจะดำเนินการธุรกรรมที่ถูกต้อง
สิ่งนี้เหมาะสมกว่าเมื่อพิจารณาถึงบริษัทเดิมของ Josh และ Jordan ใน Astria นั่นคือ Google ตั้งแต่เริ่มก่อตั้ง ผลิตภัณฑ์ของ Google ได้รับแรงบันดาลใจจากแนวคิดของ AT โดยเฉพาะอย่างยิ่งใน Google Search ซึ่งสร้างขึ้นโดยการปรับแต่ละหน้าและบทความให้เป็นโมดูล ทำให้เข้าถึงได้โดยตรงผ่านหน้าต่างค้นหาทั่วโลก
Succinct ยังครอบคลุมถึงธุรกรรม "atomic" ข้ามเชนระหว่าง Rollups กับผู้สั่งซื้อที่ใช้ร่วมกัน (และผู้พิสูจน์การฉ้อโกงที่ใช้ร่วมกัน) ภายในระบบนิเวศไฮเปอร์เชน Optimism ซึ่งสามารถดูได้ที่นี่ นอกจากนี้ตามที่ Bo Du ของ Polymer กล่าวไว้ว่า: "ธุรกรรมปรมาณูข้ามสายโซ่เปรียบเสมือนการได้มาซึ่งล็อคระหว่างเศษฐานข้อมูลเมื่อเขียน"
อนาคตของการบูรณาการในแนวดิ่ง
การทำงานภายในที่เป็นไปได้ของโซ่ SUAVE ได้รับการสำรวจในเชิงลึกแล้วโดย Jon Charbonneau et al ดังนั้นเราจะไม่ลงรายละเอียดมากเกินไป หากคุณต้องการคำอธิบายโดยละเอียด คุณสามารถอ่านบทความของเขาได้ อย่างไรก็ตาม เราคิดว่าการผสานรวมในแนวดิ่งสมควรได้รับการแนะนำแยกต่างหาก ทั้งเพื่อเน้นย้ำว่าเราเป็นโมดูลาร์ได้อย่างไร (และทำไม) และเพื่อแนะนำประเด็นและข้อกังวลบางประการที่เกี่ยวข้องกับการผสานรวมในแนวดิ่ง
ตัวเรียงลำดับที่ใช้ร่วมกันแบบละเอียด 4 มิติ: หลักการทำงาน ทฤษฎีการรวม และการรวมในแนวตั้ง
ชื่อเดิม: "ซีเควนเซอร์ที่ใช้ร่วมกัน"
เขียนโดย: MAVEN11
เรียบเรียง: Kxp, BlockBeats
ลองนึกดูว่าจะเป็นอย่างไรหาก Rollup "นอกกรอบ" สามารถบรรลุผลในการต้านทานการเซ็นเซอร์ในระดับสูง ความสะดวกในการปรับใช้ การทำงานร่วมกัน การสิ้นสุดที่รวดเร็ว ความมีชีวิตชีวา นั่นอาจดูเหมือนเป็นเป้าหมายที่ยิ่งใหญ่ แต่ด้วยการกำเนิดของ Sequencer ที่ใช้ร่วมกัน มันอาจกลายเป็นความจริงในไม่ช้า อย่างไรก็ตาม ค่าสะสมทั้งหมดไม่เหมือนกัน ดังนั้นเราต้องพิจารณาวิธีการแจกจ่ายรางวัลและ MEV บนเครือข่ายซีเควนเซอร์ที่ใช้ร่วมกัน ในเอกสารนี้ เราจะสำรวจวิธีการใช้เครือข่าย Ranker แบบแบ่งใช้ และคุณสมบัติที่สามารถทำได้
Share Sequencer Networks ได้รับการแนะนำโดย Alex Beckett เป็นหลัก ต่อมาโดย Evan Forbes (และ Radius) จากทีม Celestia และ Espresso และบทความใหม่โดย Jon Charbonneau ซึ่งครอบคลุมหัวข้อนี้ในเชิงลึกมากขึ้น Josh, Jordan และทีม Astria ของพวกเขากำลังสร้างเครือข่ายซีเควนเซอร์ที่ใช้ร่วมกันที่พร้อมสำหรับการผลิตเครือข่ายแรก Shared Orderer Network ของ Astria เป็นบล็อกเชนแบบโมดูลาร์ที่รวบรวมและสั่งซื้อธุรกรรมของ Rollup โดยไม่ต้องดำเนินการ
ในการตั้งค่าของ Astria ตัวเรียงลำดับจะส่งบล็อกที่สั่งไปยังเลเยอร์ DA และไปยังโหนดค่าสะสมด้วย Rollups ได้รับการค้ำประกันขั้นสุดท้ายแบบนุ่มนวลจากผู้สั่งซื้อและการรับประกันขั้นสุดท้ายแบบตายตัวจากชั้น DA (หลังจากสิ้นสุดการบล็อกแล้ว) จากนั้นจะดำเนินการธุรกรรมที่ถูกต้อง
เครือข่ายซีเควนเซอร์ที่ใช้ร่วมกันโดยพื้นฐานแล้วเป็นกลุ่มของซีเควนเซอร์ที่เข้ากันได้กับค่าสะสม ตามชื่อของมัน มันสามารถให้บริการสำหรับค่าสะสมต่างๆ สิ่งนี้มีข้อแลกเปลี่ยนและคุณสมบัติต่าง ๆ ซึ่งเราจะให้รายละเอียดในภายหลัง ก่อนอื่น เราต้องอธิบายคุณสมบัติที่สำคัญที่สุดของตัวเรียงลำดับ (หรือชุดของตัวเรียงลำดับ) ใน Rollup ข้อกำหนดหลักสำหรับซีเควนเซอร์หรือกลุ่มของซีเควนเซอร์คือการต่อต้านการเซ็นเซอร์หรือความคงอยู่ (บางส่วนมาจากเลเยอร์ฐาน เช่นเดียวกับความปลอดภัย) ซึ่งหมายความว่าธุรกรรมที่ถูกต้องที่ส่งไปยังผู้สั่งซื้อจะต้องรวมอยู่ในห่วงโซ่ภายในระยะเวลาที่จำกัด (พารามิเตอร์การหมดเวลา) กลุ่มผู้สั่งซื้อที่ใช้ร่วมกันต้องการเพียงให้แน่ใจว่าธุรกรรมรวมอยู่ในบล็อก (เช่น crLists)
การตอบสนองการต่อต้านการเซ็นเซอร์และความฉับไวในเวลาเดียวกันนั้นค่อนข้างยาก ดังที่เราได้อธิบายไว้ใน Modular MEV Part II ในอัลกอริธึมที่เป็นเอกฉันท์ เช่น Tendermint คุณสามารถรับประกันการฟื้นตัวหลังการโจมตีได้ อย่างไรก็ตาม ในกรณีของการโจมตี คุณจะสูญเสียความฉับไว โดยพื้นฐานแล้ว การกำหนดให้ collator อื่นทั้งหมดลงนามในบล็อก แทนที่จะเลือก masternode แบบกำหนดเองนั้นอาจไม่เหมาะสม แม้ว่าวิธีนี้จะช่วยเพิ่มความต้านทานการเซ็นเซอร์ แต่ก็แลกมาด้วยต้นทุนของ "การรวมศูนย์" และการแยก MEV ไปยังโหนดหลักเดียว กลไกการเรียงลำดับแบบอื่นสามารถเปรียบเทียบได้กับ Duality's Multiplicity ซึ่งเป็นเครื่องมือขนาดเล็กสำหรับ non-masternodes (หรือตัวเรียงลำดับ) เพื่อรวมธุรกรรมอื่น ๆ ลงในบล็อก โดยรวมแล้ว การต่อต้านการเซ็นเซอร์และความฉับไวหลังการโจมตีนั้นยากที่จะบรรลุผลสำเร็จในโปรโตคอลที่เป็นเอกฉันท์ส่วนใหญ่
อัลกอริทึมที่เป็นเอกฉันท์อื่นที่อาจใช้คือ HotStuff 2 ซึ่งช่วยให้มั่นใจได้ถึงความฉับไวในกรณีที่มีการโจมตี
สิ่งที่ช่วยให้หลีกเลี่ยงการรอเครือข่ายล่าช้าสูงสุด (หมดเวลา) ในกรณีที่มีการเซ็นเซอร์หรือไม่ได้ลงนามเพื่อเลือกโหนดหลักใหม่ เหตุผลที่อาจเป็นอัลกอริธึมฉันทามติที่น่าสนใจสำหรับชุดคำสั่งแบบกระจายอำนาจ เป็นเพราะสามารถแก้ปัญหาความฉับไวในฉันทามติโดยไม่ต้องเพิ่มขั้นตอนพิเศษ หากมาสเตอร์โหนดรู้ถึงการล็อคสูงสุด (จำนวนผู้เข้าร่วมสูงสุดที่เห็นด้วยกับเอาต์พุตเฉพาะ) และสามารถโน้มน้าวใจฝ่ายที่ซื่อสัตย์ได้ ปัญหาก็จะได้รับการแก้ไข หากไม่มี โหนดหลักที่ซื่อสัตย์หลังจากถึงจุดหนึ่งสามารถรับผิดชอบการพุชได้ โดยช่วยเหลือมาสเตอร์โหนดถัดไป ตัวอย่างเช่น โหนด Hotstuff ไม่จำเป็นต้องรับทราบข้อความการสลับก่อนที่จะแจ้งต้นแบบใหม่ แต่สามารถสลับไปยังมุมมองใหม่ได้โดยตรงและแจ้งต้นแบบใหม่
ความแตกต่างของ Tendermint คือ แม้ว่าทั้งสองจะเป็นสองเฟส (Hotstuff1 มีสามเฟส, Hotstuff2 มีสองเฟส) Tendermint มีการสื่อสารเชิงเส้นแต่ไม่ตอบสนอง ในขณะที่ Hotstuff2 เป็นแบบโต้ตอบ หากมีห่วงโซ่ของโหนดหลักที่ซื่อสัตย์ โปรโตคอลจะตอบสนองในเชิงบวก เนื่องจากขั้นตอนทั้งหมดยกเว้นข้อเสนอของโหนดหลักแรกขึ้นอยู่กับการได้รับข้อมูลจำนวนมากจากขั้นตอนก่อนหน้า ในการตั้งค่าคำสั่งที่ใช้ร่วมกัน สิ่งนี้ทำให้โปรโตคอลบรรลุความฉับไวที่ดีขึ้นโดยไม่ถอยกลับไปที่เลเยอร์ล่างสุด ในขณะที่ไม่ยกเลิกความเป็นไปได้นี้
การสร้างกลุ่มตัวเรียงลำดับที่ใช้ร่วมกัน
ชุดของผู้สั่งซื้อได้รับอนุญาตให้ส่งธุรกรรมไปยังชั้นการชำระบัญชี (ชั้นที่ Rollup อยู่) คุณสามารถเข้าร่วมกลุ่ม collator นี้ได้ หากตรงตามข้อกำหนดบางประการ และผู้ผลิตบล็อกไม่ครบตามจำนวนที่กำหนด ซึ่งช่วยเพิ่มประสิทธิภาพเวลาแฝง ปริมาณงาน และอื่นๆ ข้อกำหนดเหล่านี้คล้ายกับข้อกำหนดในการเป็นผู้ตรวจสอบความถูกต้องของบล็อกเชน ตัวอย่างเช่น คุณต้องปฏิบัติตามข้อกำหนดด้านฮาร์ดแวร์บางอย่าง เช่นเดียวกับเงินฝากเริ่มต้น โดยเฉพาะอย่างยิ่งหากคุณต้องการให้เงื่อนไขทางการเงินที่แน่นอน
กลุ่มผู้สั่งซื้อที่ใช้ร่วมกัน (หรือกลุ่มผู้สั่งซื้อที่กระจายอำนาจ) ประกอบด้วยองค์ประกอบหลายอย่างที่ทำงานร่วมกันเพื่อให้แน่ใจว่าการประมวลผลธุรกรรมถูกต้อง รวมถึง:
จัดเตรียม JSON-RPC สำหรับแต่ละ Rollup สำหรับการส่งธุรกรรม (สำหรับตัวดำเนินการโหนดที่ไม่เต็ม) ไปยังโหนดเป็นพูลหน่วยความจำ จากนั้นสร้างและเรียงลำดับ ใน mempool จำเป็นต้องมีกลไกบางอย่างในการกำหนดคิว เช่นเดียวกับกระบวนการเลือกธุรกรรม เพื่อให้แน่ใจว่าการสร้างบล็อกมีประสิทธิภาพ
อัลกอริทึมการสร้างบล็อก/แบทช์ รับผิดชอบการประมวลผลธุรกรรมในคิวและแปลงเป็นบล็อกหรือแบทช์ ขั้นตอนนี้อาจรวมถึงการบีบอัดเพื่อลดขนาดบล็อกผลลัพธ์ (เรียกว่าการบีบอัดข้อมูล) ดังที่กล่าวไว้ สิ่งนี้ควรแยกจาก Proposer ซึ่งก็คือ PBS การบีบอัดข้อมูลทำได้หลายวิธี เช่น
การละเว้นฟิลด์ข้อมูล: ฟิลด์ข้อมูลไม่จำเป็นสำหรับการถ่ายโอนแบบธรรมดา แต่จำเป็นสำหรับธุรกรรมที่ซับซ้อนมากขึ้น
แทนที่ลายเซ็นแต่ละรายการด้วยลายเซ็นรวมของ BLS: ลายเซ็นเป็นองค์ประกอบที่ใหญ่ที่สุดของธุรกรรม Ethereum แทนที่จะจัดเก็บลายเซ็นแต่ละรายการ คุณสามารถจัดเก็บลายเซ็นรวมของ BLS สำหรับการทำธุรกรรมตามจำนวนที่ระบุ คุณยังสามารถตรวจสอบลายเซ็นรวม BLS กับชุดข้อความและชุดผู้ส่งเพื่อให้แน่ใจว่าถูกต้อง
ใช้ฟิลด์ From เป็นดัชนี เช่นเดียวกับฟิลด์ To คุณสามารถใช้ฟิลด์ From เป็นดัชนีสำหรับการแมป
แนวคิดที่น่าสนใจของการออกแบบ "โมดูลาร์" คือคุณสามารถปรับเปลี่ยนและแลกเปลี่ยนได้ตามต้องการเพื่อให้ใช้งานได้กับชุดสะสมของคุณ
อัลกอริทึมการหมุนเวียนหลักสำหรับชุดคำสั่งที่ใช้ร่วมกัน (ไม่จำเป็นต้องมีเอกฉันท์ในกรณีของการเลือกหลักเดียว) คุณสามารถเลือกที่จะตั้งค่าอัลกอริทึมการหมุนโหนดหลักเท่านั้น หรือใช้เส้นทางผู้ผลิตบล็อกหลายรายการพร้อมกันที่เสนอโดย Duality
อัลกอริธึมที่เป็นเอกฉันท์ เช่น Tendermint หรือ Hotstuff2 ที่กล่าวมา สามารถรับประกันได้ว่าโหนด Rollup เห็นด้วยกับลำดับที่เสนอโดยบัญชีแยกประเภท
ไคลเอ็นต์ RPC สำหรับส่งบล็อก/แบทช์ไปยังเลเยอร์ฉันทามติของ DA+ เพื่อให้สามารถเพิ่มบล็อก/แบทช์ลงในเลเยอร์ DA ได้อย่างปลอดภัย ทำให้มั่นใจได้ในขั้นสุดท้าย "ขั้นสุดท้าย" และทำให้ข้อมูลธุรกรรมทั้งหมดพร้อมใช้งานบนเครือข่าย
แยกบทบาทของผู้สร้างและบล็อกผู้ผลิตเพื่อให้มีความยุติธรรมและสม่ำเสมอ และหลีกเลี่ยงการขโมย MEV ยังลบการจัดเรียงที่ดำเนินการ ซึ่งเป็นสิ่งสำคัญในการเพิ่มประสิทธิภาพ ลด PGA และเพิ่ม CR
*โหนดค่าสะสมได้รับบล็อกที่สั่งจากตัวเรียงลำดับสำหรับการส่งแบบไม่ละเอียด และรับบล็อกเลเยอร์ DA ที่สั่งสำหรับการส่งแบบถาวร *
Calldata ได้รับการเผยแพร่เป็นครั้งแรกในเครือข่ายฐาน ซึ่งมีการเรียกใช้ฉันทามติเพื่อรับประกันผู้ใช้และธุรกรรมค่าสะสม จากนั้น โหนดค่าสะสมจะดำเนินการธุรกรรมและส่งฟังก์ชันการเปลี่ยนสถานะไปยังสายค่าสะสมตามบัญญัติ เครือข่ายของผู้สั่งซื้อที่ใช้ร่วมกันช่วยให้ Rollup มีความฉับไวและการต่อต้านการเซ็นเซอร์ Rollups รักษาอำนาจอธิปไตยของตนเนื่องจากข้อมูลธุรกรรมทั้งหมดถูกจัดเก็บไว้ในชั้นฐาน ซึ่งช่วยให้สามารถแยกออกจากผู้สั่งซื้อที่ใช้ร่วมกันได้ทุกเมื่อ รากสถานะของฟังก์ชันการเปลี่ยนสถานะค่าสะสม (STF) คำนวณจากรากของธุรกรรม (อินพุต) ที่ส่งจากใบสั่งที่ใช้ร่วมกันไปยังเลเยอร์ DA ใน Celestia รากของสถานะจะถูกสร้างขึ้นเมื่อข้อมูลถูกเพิ่มเข้าไปในห่วงโซ่และถึงฉันทามติ เนื่องจากคุณมีรูทธุรกรรมอยู่แล้ว (และข้อมูลทั้งหมดที่มีอยู่) Celestia จึงสามารถให้บริการไคลเอนต์แบบ light (โหนดสะสมที่ทำงานบน Celestia) พร้อมหลักฐานการรวมเล็กน้อย
เพื่อมอบประสบการณ์ผู้ใช้ตามที่ผู้ใช้คาดหวัง โหนดค่าสะสมจะได้รับบล็อกที่สั่ง (ซึ่งจะถูกส่งไปยังเลเยอร์ DA ด้วย) สิ่งนี้สามารถให้ Rollup ด้วยการรับประกันแบบ soft deterministic - รับประกันว่าในที่สุดบล็อกจะถูกจัดเรียงตามลำดับในเลเยอร์ DA ซึ่งโหนด Rollup จะดำเนินการธุรกรรมและระบุสถานะใหม่
การสร้างบล็อกและสล็อต
ในการกำหนดเวลาในการสร้างบล็อก ซีเควนเซอร์จำเป็นต้องตั้งค่าสล็อต ซีเควนเซอร์ควรส่งแบทช์ตามช่วงเวลาที่กำหนด (โดยทั่วไปคือ X วินาที) โดยที่ X คือเวลาสล็อต สิ่งนี้ทำให้มั่นใจได้ว่าธุรกรรมจะได้รับการประมวลผลอย่างรวดเร็วและมีประสิทธิภาพ เพราะไม่เช่นนั้น masternode สำหรับสล็อตใดสล็อตหนึ่งจะหมดเวลาและสูญเสียรางวัลการลงนาม (และรางวัลการดำเนินการ) ตัวอย่างเช่น เวลาบล็อกของ Celestia (ตามข้อกำหนดของ GitHub) คือประมาณ 15 วินาที เนื่องจากสิ่งนี้เป็นที่ทราบกันดีอยู่แล้ว เราจึงสามารถตั้งสมมติฐานเกี่ยวกับจำนวน "ช่อง/บล็อก" ที่เราอาจมีจากชุดของ coorters ที่ใช้ร่วมกันไปยังเลเยอร์ DA และโหนด Rollup จะถูกโหลดลงในบล็อกที่สรุปแล้ว ในเรื่องนี้เราสามารถอ้างถึง Tendermint หรือ Hotstuff2 ที่ปรับให้เหมาะสม
ภายในสล็อตเดียวกัน เราสามารถส่งชุดธุรกรรมได้หลายชุด โดยมีเงื่อนไขว่าการออกแบบจะมีกลไกสำหรับโหนดเต็มค่าสะสมเพื่อประมวลผลเป็นบล็อกเดียวอย่างมีประสิทธิภาพ (ภายในช่วงเวลาดังกล่าวและพารามิเตอร์ระยะหมดเวลา) สิ่งนี้ช่วยเพิ่มประสิทธิภาพการสร้างบล็อกเพิ่มเติมและทำให้มั่นใจได้ว่าธุรกรรมจะได้รับการประมวลผลอย่างรวดเร็ว นอกจากนี้ยังสามารถใช้ช่องเพื่ออำนวยความสะดวกในการเลือกโหนดหลักตัวเรียงลำดับ ตัวอย่างเช่น คุณสามารถสุ่มเลือกโหนดหลักสล็อตจากพูลการเดิมพันตามน้ำหนักการเดิมพัน การทำเช่นนี้ในลักษณะที่รักษาความลับและใช้บางอย่าง เช่น การเลือกผู้นำแบบลับเพื่อลดการเซ็นเซอร์คือตัวเลือกที่ดีที่สุด หรือแม้แต่การตั้งค่าเทคโนโลยีตัวตรวจสอบความถูกต้องแบบกระจาย เช่น โซลูชันเช่น Obol/SSV เวลาแฝงและเวลาสล็อตมีผลกระทบอย่างมากต่อการส่งบล็อกและการสร้างโปรโตคอล ดังนั้นเราต้องดูว่าสิ่งนี้ส่งผลต่อระบบอย่างไร Bloxroute มีการวิจัยและจุดข้อมูลที่ยอดเยี่ยมเกี่ยวกับ Ethereum โดยเฉพาะ ใน MEV-Boost ผู้ผลิตบล็อกที่เข้าร่วม (ตัวตรวจสอบความถูกต้องหรือตัวจัดลำดับในกรณีของ Rollup) จะร้องขอ GetHeader จากรีเลย์ ซึ่งให้มูลค่าการเสนอราคาแบบบล็อกแก่พวกเขา ซึ่งเป็นมูลค่าของบล็อกหนึ่งๆ นี่อาจเป็นบล็อกมูลค่าสูงสุดที่ได้รับในแต่ละครั้ง สำหรับแต่ละสล็อต โดยทั่วไปตัวตรวจสอบความถูกต้องจะร้องขอ GetHeader ประมาณ 400 มิลลิวินาทีหลังจากที่สล็อตเริ่มทำงาน เนื่องจากตัวตรวจสอบความถูกต้องมีจำนวนมาก รีเลย์จึงมักต้องส่งคำขอจำนวนมาก สิ่งนี้สามารถเกิดขึ้นได้กับกลุ่มตัวเรียงลำดับที่ใช้ร่วมกันขนาดใหญ่ ซึ่งหมายความว่าคุณต้องมีโครงสร้างพื้นฐานเพื่ออำนวยความสะดวกในกระบวนการนี้
รีเลย์ยังช่วยอำนวยความสะดวกในการแยกตัวสร้างและตัวผลิตบล็อก ขณะเดียวกันก็ตรวจสอบว่าตัวสร้างสร้างบล็อกที่ถูกต้อง พวกเขายังตรวจสอบว่ามีการชำระค่าธรรมเนียมอย่างถูกต้องและทำหน้าที่เป็นการป้องกัน DoS นอกจากนี้ พวกเขายังเป็นผู้ดูแลบล็อกและจัดการการลงทะเบียนของผู้ตรวจสอบความถูกต้อง นี่เป็นสิ่งสำคัญอย่างยิ่งในสถาปัตยกรรมของซีเควนเซอร์ที่ไม่มีขอบเขต เนื่องจากคุณต้องติดตามว่าใครเข้าร่วมและใครไม่เข้าร่วม (ตัวอย่างเช่น เลเยอร์การซิงโครไนซ์ที่กล่าวถึงก่อนหน้านี้)
เกี่ยวกับเวลาการบล็อก (เช่น การบล็อกที่ส่งโดยผู้สร้าง) โดยปกติแล้วจะใช้เวลาประมาณ 200 มิลลิวินาที ส่วนใหญ่จะเริ่มทำงานก่อน/หลังประมาณ 200 มิลลิวินาที แม้ว่า GetHeader จะมีรูปแบบที่หลากหลาย หากตัวสร้างส่งบล็อกไปยังรีเลย์หลายตัว จะทำให้เกิดความล่าช้าอย่างมาก Bloxroute ยังดูด้วยว่าเกิดอะไรขึ้นเมื่อบล็อกถูกส่งไปยังรีเลย์หลายตัว อย่างที่คุณคาดไว้ ความล่าช้าในการแพร่กระจายบล็อกไปยังรีเลย์จำนวนมากขึ้นจะมากขึ้น โดยเฉลี่ยแล้ว รีเลย์ตัวที่สองใช้เวลา 99 มิลลิวินาทีในการบล็อก รีเลย์ตัวที่สามใช้เวลา 122 มิลลิวินาที และตัวที่สี่ 342 มิลลิวินาที
สิ่งที่เราอาจได้เรียนรู้ในช่วงไม่กี่เดือนที่ผ่านมาคือ RPC มีความสำคัญต่อบล็อกเชนมาก เป็นภาระอย่างมากหากไม่มีโครงสร้างพื้นฐานที่เหมาะสม และการมีตัวเลือก RPC ที่เหมาะสมก็มีความสำคัญเช่นกัน ในกรณีนี้ RPC มีความสำคัญสำหรับนักลงทุนรายย่อยที่ส่งธุรกรรมไปยัง RPC (และ mempool สาธารณะ) Bloxroute ทำการทดสอบธุรกรรมเล็กๆ 20 รายการที่ส่งไปยัง RPC ต่างๆ และวัดเวลาที่ใช้สำหรับธุรกรรมแต่ละรายการที่จะรวมอยู่ในบล็อก
ที่มา: Bloxroute Labs
ที่น่าสนใจคือ RPC บางตัวไม่รวมธุรกรรมจนกว่าจะผ่านไปหลายช่วงตึก ขึ้นอยู่กับว่าผู้สร้างรายใดจะชนะในบล็อกถัดไป หาก RPC ส่งธุรกรรมไปยังผู้สร้างจำนวนมากขึ้น ความน่าจะเป็นของการรวมอย่างรวดเร็วก็จะสูงขึ้น แม้ว่าจะเป็นไปได้ที่ผู้สร้างธุรกรรมจะใช้ประโยชน์จากตำแหน่งเฉพาะของตนในลำดับขั้นตอนเพื่อกำหนดเป้าหมายผู้สร้างที่เฉพาะเจาะจงหรือแม้แต่สร้างบล็อกของตนเอง
ประสิทธิภาพของพวกเขายังน่าสนใจในสถิติประสิทธิภาพการถ่ายทอดของ Ethereum สิ่งนี้ช่วยให้เราได้รับความเข้าใจอย่างลึกซึ้งยิ่งขึ้นเกี่ยวกับวิธีการทำงานของ PBS ในโลกของเครื่องมือตรวจสอบความถูกต้อง/เครื่องมือสร้าง/รีเลย์หลายตัว ซึ่งเป็นสิ่งที่เราหวังว่าจะบรรลุผลสำเร็จด้วยการอัปเกรดชุดรวมอัปเดต Metrika มีสถิติที่ยอดเยี่ยมในเรื่องนี้และจุดข้อมูลทั้งหมดเป็นเพราะพวกเขา
สิ่งสำคัญคือต้องทราบว่าการพลาดการเสนอราคาเกิดขึ้นเมื่อคาดว่าผู้ส่งต่อจะเสนอราคา แต่ไม่ได้เสนอราคา ความคาดหวังของเป้าหมายมาจากตัวตรวจสอบความถูกต้องที่ลงทะเบียนกับรีเลย์เฉพาะสำหรับสล็อตที่กำหนด นี่ไม่ใช่ความผิดพลาดของรีเลย์ และไม่ได้จัดการด้วยวิธีนั้นที่ระดับโปรโตคอล
ที่มา: app.metrika.co
หากเกิดข้อผิดพลาด (เช่น รีเลย์ที่ให้บริการบล็อกที่ไม่ถูกต้อง) และเป็นผู้รับผิดชอบ ข้อผิดพลาดนั้นจะถูกนับเป็นข้อผิดพลาด สิ่งเหล่านี้มักเกิดขึ้นไม่บ่อยนักและส่วนใหญ่เป็นความล้มเหลวในการลงทะเบียน (เช่น ขีดจำกัดก๊าซหรือค่าธรรมเนียมที่ไม่ตรงกับการลงทะเบียนสำหรับผู้ตรวจสอบความถูกต้องโดยเฉพาะ) สิ่งที่หายากกว่านั้นคือความล้มเหลวของเลเยอร์ฉันทามติ ซึ่งไม่สอดคล้องกับกฎเลเยอร์ฉันทามติของ Ethereum เช่น สล็อตไม่ถูกต้องหรือแฮชพาเรนต์ไม่สอดคล้องกับบล็อกก่อนหน้า เป็นต้น
ในแง่ของเวลาแฝง (เช่น เวลาที่ตัวตรวจสอบความถูกต้องใช้เพื่อรับส่วนหัวของบล็อกที่สร้างโดยตัวสร้าง) ข้อมูลมีความสอดคล้องกันมาก แม้ว่าจะมีค่าผิดปกติบางอย่าง เช่น การส่งต่อที่ร้องขออยู่ในตำแหน่งทางภูมิศาสตร์ที่แตกต่างจากตัวตรวจสอบความถูกต้องที่เลือก
ที่มา: app.metrika.co
สำหรับผู้สร้าง จำนวนผู้สร้างทั้งหมดใน MEV-boost อยู่ที่ประมาณ 84 โดยผู้สร้างสามอันดับแรกสร้างประมาณ 65% ของบล็อกที่สร้างขึ้น แม้ว่าสิ่งนี้อาจทำให้เข้าใจผิดอยู่บ้างเนื่องจากเป็นผู้สร้างที่ดำเนินการมายาวนานที่สุดเช่นกัน ผลลัพธ์จะคล้ายกันหากกรอบเวลาลดลง จำนวนผู้สร้างที่ใช้งานจริงนั้นต่ำกว่ามาก 35 รายการใน 30 วันที่ผ่านมา และ 24 รายการในสัปดาห์ที่ผ่านมา การแข่งขันเป็นไปอย่างดุเดือด และโดยปกติแล้วผู้สร้างที่แข็งแกร่งที่สุดจะเป็นผู้ชนะ ขั้นตอนการสั่งซื้อพิเศษอาจมีอยู่แล้ว ซึ่งมีแต่จะทำให้สถานการณ์เลวร้ายลง เราคาดว่าการกระจายตัวของผู้สร้างจะยังคงค่อนข้างรวมศูนย์ (เนื่องจากเป็นการแข่งขันเพื่อลำดับการสั่งการที่ดีที่สุดและการปรับแต่งฮาร์ดแวร์ให้เหมาะสม) เว้นแต่ว่าเราจะทำการเปลี่ยนแปลงที่สำคัญกับการตั้งค่า แม้ว่าจะไม่ใช่ปัญหาพื้นฐาน แต่ก็ยังเป็นแรงรวมศูนย์ในสแต็ก และเรายินดีรับฟังแนวคิดเกี่ยวกับวิธีท้าทายสถานะที่เป็นอยู่ ณ ที่นี้ หากคุณสนใจที่จะเจาะลึกลงไปในปัญหา (ร้ายแรง) นี้ เราขอแนะนำให้อ่านบทความของ Quintus เกี่ยวกับขั้นตอนการสั่งซื้อ การประมูล และการรวมศูนย์
สำหรับบทบาท Builder ในสแต็กโมดูลาร์ในอนาคต เราค่อนข้างมั่นใจว่า (อย่างน้อยในการตั้งค่า Cosmos SDK) เราจะเห็นการตั้งค่า Builder Modules แบบ Skip/Mekatek อีกวิธีหนึ่งคือการตั้งค่าประเภท SUAVE เช่น เชนตัวสร้างทั่วโลกเฉพาะที่ให้บริการการสร้างบล็อกและการตั้งค่าการเสนอราคาแก่เชนจำนวนเท่าใดก็ได้เพื่อให้แน่ใจว่า PBS เราจะสำรวจโซลูชันนี้ในเชิงลึกในภายหลัง และให้คำตอบสำหรับคำถามที่ไม่ได้กล่าวถึงที่นี่
เกี่ยวกับรีเลย์ เราขอแนะนำให้อ่านบทความโดย Ankit Chiplunkar จาก Frontier Research และ Mike Neuder จาก Ethereum Foundation ที่เรียกว่า Optimistic relays และตำแหน่งที่จะหาได้ โพสต์นี้ให้รายละเอียดว่ารีเลย์ใน MEV-boost ทำงานอย่างไร การแลกเปลี่ยนปัจจุบันและต้นทุนการดำเนินงาน และการเปลี่ยนแปลงบางอย่างที่อาจเพิ่มประสิทธิภาพ ที่น่าสนใจคือ การรันรีเลย์ใน MEV-Boost ปัจจุบันมีค่าใช้จ่ายประมาณ 100,000 เหรียญสหรัฐต่อปีตามการประมาณการของ Flashbot
กำหนด
ก่อนที่เราจะพูดถึงระดับของบล็อกเชนแบบโมดูลาร์ (ตามที่เห็นในปัจจุบัน) มาดูบทความ "โมดูลาร์ MEV" ก่อนหน้าของเรากันก่อน โปรดทราบว่านี่ไม่ใช่มุมมอง "อย่างเป็นทางการ" หรือมุมมองที่ครอบคลุมเกี่ยวกับการสิ้นสุด แต่เราเชื่อว่ามันแสดงถึงความแตกต่างของการสิ้นสุดบทสรุปอย่างถูกต้องที่สุดเพื่อให้เข้าใจได้ง่าย
รอดำเนินการ_เปิด_L2: คำสั่งสะสมแสดงถึงข้อผูกมัดที่นุ่มนวลว่าธุรกรรมของผู้ใช้จะถูกผูกมัดและสิ้นสุดในชั้นพื้นฐานของการรักษาความปลอดภัยในที่สุด
Finality_On_L2: ซีเควนเซอร์ยอมรับฟังก์ชันการเปลี่ยนสถานะของค่าสะสม และมีการเพิ่มบล็อกลงในสายมาตรฐานของค่าสะสม
รอดำเนินการ_เปิด_L1: ฟังก์ชันการเปลี่ยนอินพุตหรือเอาต์พุต/สถานะของธุรกรรมได้รับการเผยแพร่ใน L1 แล้ว แต่ยังไม่มีการออกหลักฐานความถูกต้อง หรือระยะเวลาอนุญาโตตุลาการยังไม่สิ้นสุด ซึ่งต้องใช้ Ethereum เป็นเวลาสองยุคติดต่อกัน นี่คือจุดที่ Optimistic Rollups ส่วนใหญ่บอกว่าพวกเขามาถึงจุดสิ้นสุดแล้ว แต่ยังคงมีช่วงเวลาท้าทาย 7 วันโดยพลการ ณ จุดนี้ ตามข้อมูลจำเพาะของสะพานข้ามโซ่
ขั้นสุดท้าย_เปิด_L1: สำหรับการสรุปผลในแง่ดี ระยะเวลาอนุญาโตตุลาการสิ้นสุดลงแล้ว หรือมีการเผยแพร่และพิสูจน์ความถูกต้องของหลักฐานที่ได้รับการยืนยันโดยเสียงข้างมากในสองยุคติดต่อกัน
ตอนนี้ ใน Sovereign Shared Sort Rollup จะดูแตกต่างออกไปเล็กน้อย ลองอธิบายด้วยแผนภาพ:
ในกรณีนี้ ในทางทฤษฎี เราสามารถรับค่ากำหนดของ L1 ก่อน L2 ฯลฯ ได้หรือไม่ ใช่ ในกรณีนี้ L2 มีอำนาจอธิปไตย ซึ่งถือว่าไม่มีหลักฐานการฉ้อโกงและระยะเวลาท้าทาย หรือคุณกำลังใช้หลักฐานยืนยันความถูกต้อง
แล้วเราจะบรรลุระดับสุดท้ายเหล่านี้ได้อย่างไร? การสิ้นสุดการบล็อกจะเกิดขึ้นได้เมื่อมีการเพิ่มการบล็อกในสายมาตรฐานซึ่งไม่สามารถถอนออกได้ อย่างไรก็ตาม มีความแตกต่างบางประการที่นี่ ขึ้นอยู่กับโหนดเต็มหรือโหนดเบา ในกรณีของบล็อกที่สั่งซื้อ จะถูกกำหนดเมื่อรวมอยู่ในบล็อกเลเยอร์ DA การบล็อก (ที่มีสถานะรูท) ถูกบังคับใช้โดยโหนดเต็ม/ตัวตรวจสอบความถูกต้องของ Rollup ซึ่งทำให้รับประกันสถานะรูทที่ถูกต้องที่ได้มาจากบล็อกที่สั่งของชั้นฐาน สำหรับการกำหนดระดับที่เกินโหนดเต็ม (เช่น สำหรับไคลเอ็นต์แบบเบาหรือสะพานข้ามโซ่) คุณต้องมั่นใจในความถูกต้องของสถานะรูทนี้ ที่นี่ คุณสามารถใช้หนึ่งในวิธีที่อธิบายไว้ด้านล่าง นอกจากนี้ อีกวิธีหนึ่งคือการทำให้ผู้ตรวจสอบความถูกต้องรับผิดชอบต่อการพิสูจน์ที่ถูกต้องของรากสถานะ (เส้นทางที่มองโลกในแง่ดี) ผ่านการผูกมัดและการพิสูจน์การฉ้อโกงที่ตามมา นอกจากนี้ คุณสามารถแสดงหลักฐานยืนยันความถูกต้อง (ZK)
วิธีต่างๆ เพื่อให้ได้ผลลัพธ์สุดท้ายของบล็อก:
ผ่าน Proof of Work (PoW), LMD+Ghost, Goldfish, Ouroboros (PoS) และวิธีความน่าจะเป็นอื่นๆ
วิธีการพิสูจน์โดยการลงนามของคณะกรรมการที่เพียงพอ (เช่น Tendermint 2/3, Hotshot2 หรือ PBFT ชนิดอื่นๆ)
ขึ้นอยู่กับลำดับของธุรกรรม/บล็อกในเลเยอร์ DA และกฎของมัน ได้แก่ กฎการเลือกเชนแบบบัญญัติและส้อม
เราสามารถบรรลุขั้นสุดท้ายประเภทต่างๆ ผ่านกลไกที่แตกต่างกัน
การสิ้นสุดประเภทหนึ่งคือ "การสิ้นสุดอย่างนุ่มนวล" (เช่น การรอดำเนินการ) ซึ่งสามารถทำได้โดยการเลือกตั้งผู้นำคนเดียว ในกรณีนี้ แต่ละช่องจะมีเพียงบล็อกเดียวหรือเป็นศูนย์ (คอมมิชชันหรือไม่ก็ได้) และเลเยอร์การซิงโครไนซ์สามารถรับลำดับของธุรกรรมในบล็อกเหล่านี้ได้อย่างปลอดภัย
ขั้นสุดท้ายอีกประเภทหนึ่งคือ "ขั้นสุดท้ายที่พิสูจน์ได้" ซึ่งให้การรับประกันที่หนักแน่นกว่า (ขั้นสุดท้ายโดยพื้นฐาน) กว่าขั้นสุดท้ายแบบนุ่มนวล เพื่อให้บรรลุผลสุดท้ายที่พิสูจน์ได้ ผู้สั่งซื้อส่วนใหญ่ต้องลงนามในบล็อก ดังนั้นจึงเป็นการแสดงข้อตกลงว่าบล็อกนั้นเป็นที่ยอมรับ แม้ว่าแนวทางนี้จะดี แต่อาจไม่จำเป็นหากมีการใช้การเลือกตั้งผู้นำคนเดียว เนื่องจากเป็นการรับประกันการสั่งซื้อแบบบล็อกเป็นหลัก เห็นได้ชัดว่าสิ่งนี้ขึ้นอยู่กับอัลกอริทึมการเลือกผู้นำเฉพาะที่กำลังดำเนินการอยู่ ตัวอย่างเช่น การดำเนินการ 51% การดำเนินการ 66% หรือผู้นำคนเดียว (ควรเป็นแบบสุ่ม (VRF) และการเลือกตั้งลับ) หากคุณต้องการเรียนรู้เพิ่มเติมเกี่ยวกับปัจจัยกำหนดใน Ethereum โปรดอ่านบทความนี้ที่เราแนะนำเป็นอย่างยิ่ง และบทความที่เราจะแนะนำในภายหลังสำหรับชุดตัวเรียงลำดับที่ไม่มีขอบเขต
มีใบอนุญาต กึ่งมีใบอนุญาต หรือไม่มีใบอนุญาต
เพื่อป้องกันการโจมตี DoS ที่อาจเกิดขึ้น ต้องตั้งค่าอุปสรรคทางเศรษฐกิจเพื่อเข้าร่วมกลุ่มผู้สั่งซื้อและส่งธุรกรรมไปยังชั้นผู้สั่งซื้อ ในกลุ่มที่มีขอบเขต (ตัวเรียงลำดับจำนวนจำกัด) และกลุ่มไม่จำกัด (ตัวเรียงลำดับไม่จำกัดจำนวน) จะต้องวางอุปสรรคทางเศรษฐกิจในการส่งแบทช์ไปยังชั้น DA เพื่อป้องกันไม่ให้ชั้นการซิงโครไนซ์ (การแพร่กระจายบล็อกระหว่างตัวเรียงลำดับ) ทำงานช้าลงหรืออยู่ภายใต้การโจมตี DDoS . อย่างไรก็ตาม เลเยอร์ DA เองก็มีการป้องกันอยู่บ้าง เนื่องจากการส่งข้อมูลไปยังเลเยอร์นั้นต้องมีค่าใช้จ่าย (da_fee) เงินประกันที่จำเป็นในการเข้าร่วมกลุ่มที่ไม่มีขอบเขตควรครอบคลุมค่าใช้จ่ายเพิ่มเติมที่จำเป็นเพื่อป้องกันไม่ให้เลเยอร์การซิงค์ถูกสแปม ในทางกลับกัน มาร์จิ้นที่จำเป็นสำหรับการเข้าร่วมกลุ่มที่มีขอบเขตจะขึ้นอยู่กับความต้องการ (สมดุลจากมุมมองของต้นทุน/รายได้)
สำหรับชุดตัวเรียงลำดับที่ไม่มีขอบเขต เราไม่สามารถบรรลุขั้นสุดท้ายที่พิสูจน์ได้ที่ชั้นตัวเรียงลำดับ (เนื่องจากเราไม่มีทางทราบแน่ชัดว่ามีผู้ลงคะแนนเสียง/ผู้ลงนามที่ใช้งานอยู่จำนวนเท่าใด) ในทางกลับกัน ในกลุ่มของผู้ประสานงานที่มีขอบเขต การสิ้นสุดที่พิสูจน์ได้สามารถทำได้โดยผู้ประสานงานส่วนใหญ่ที่ลงนามในบล็อค สิ่งนี้ต้องการเลเยอร์การซิงโครไนซ์เพื่อรับรู้เลเยอร์ซีเควนเซอร์และจำนวนซีเควนเซอร์ที่ใช้งานอยู่ ณ เวลาใดก็ตาม ซึ่งเป็นค่าใช้จ่ายเพิ่มเติมบางส่วน ในชุดตัวเรียงลำดับที่มีขอบเขต (เช่น สูงสุด 100 ตัว) คุณยังสามารถปรับจำนวนตัวเรียงลำดับให้เหมาะสมเพื่อปรับปรุง "ประสิทธิภาพ" แม้ว่าจะต้องเสียค่าใช้จ่ายในการกระจายอำนาจและการต่อต้านการเซ็นเซอร์ ความสำคัญของกลุ่มที่มีขอบเขตและการรับประกันทางเศรษฐกิจเพื่อให้ความแน่นอนที่พิสูจน์ได้ "รวดเร็ว" นั้นเป็นตัวกำหนดเช่นกัน
ประเภทของตัวเรียงลำดับแบบไม่มีขอบเขตและตัวเรียงลำดับแบบมีขอบเขตยังสะท้อนให้เห็นในบล็อกเชนแบบดั้งเดิมด้วย ตัวอย่างเช่น PoS (Casper+LMD-GHOST) ใน Ethereum จะใช้แบบไม่มีขอบเขต ในขณะที่เชนที่ใช้ Cosmos SDK/Tendermint จะใช้แบบแบบมีขอบเขต ความคิดที่น่าสนใจคือ เราคาดหวังที่จะเห็นเศรษฐกิจและทางเลือกที่พิสูจน์ได้ว่ามีสัดส่วนการได้ส่วนเสียจากชุมชนรอบคำสั่งซื้อที่ใช้ร่วมกันหรือไม่ ในเรื่องนี้ เราได้เห็นการเคลื่อนไหวไปสู่การรวมศูนย์ของบางเอนทิตี (ดังนั้นการไม่มีขอบเขตจึงไม่สำคัญหากคุณมีผู้ให้บริการ/กลุ่มหลักฐานการถือหุ้นจำนวนมากอยู่แล้ว) แม้ว่าพวกเขาจะ "ซ่อน" การรวมศูนย์ไว้ แต่คุณก็ยังขุดเหมืองได้หากต้องการ จากมุมมองเชิงอุดมคติ ทางเลือกควรไม่มีขอบเขตเกือบตลอดเวลา แต่โปรดจำไว้ว่าหลักการทางเศรษฐศาสตร์ทำให้พวกมันคล้ายกันมากอยู่ดี ไม่ว่าผู้เข้าร่วมจะเป็นใคร เศรษฐศาสตร์ของสิ่งที่คุณจ่ายควรยังคงเหมือนเดิม เช่น ต้นทุนของ DA และต้นทุนของฮาร์ดแวร์ (แม้ว่าสิ่งนี้อาจลดลงตามจำนวนของหลักฐานการเดิมพันที่คุณจัดสรรและประสบการณ์ และมีประสิทธิภาพ การทำงานของโครงสร้างพื้นฐาน) แม้แต่ในโลกของ PoS ที่มีขอบเขต เราก็ได้เห็นกลุ่มผู้ให้บริการโครงสร้างพื้นฐานกลายเป็นตัวตรวจสอบความถูกต้องที่ใหญ่ที่สุดและพบได้บ่อยที่สุดในห่วงโซ่เกือบทั้งหมด ในเครือข่าย Cosmos ส่วนใหญ่ การพึ่งพาระหว่างตัวตรวจสอบความถูกต้องนั้นมีขนาดใหญ่มากอยู่แล้ว และแน่นอนว่าสิ่งนี้เป็นอันตรายต่อการกระจายอำนาจและการต่อต้านการเซ็นเซอร์ของเชนดังกล่าว ถึงกระนั้น ข้อเท็จจริงที่แตกต่างกันมากก็คือนักลงทุนรายย่อยสามารถเดิมพันด้วยตัวตรวจสอบความถูกต้องที่พวกเขาเลือก น่าเสียดายที่สิ่งนี้มักจะถูกกำหนดให้อยู่ในอันดับต้น ๆ ของรายการและชีวิตก็ดำเนินต่อไป เราถามอีกครั้ง: เราคาดหวังรูปแบบเศรษฐกิจที่คล้ายกันในโลกแบบโมดูลาร์หรือไม่? ความปรารถนาหนึ่งที่ไม่เป็นเช่นนั้น แต่ด้วยความเชี่ยวชาญ คุณมักจะต้องการสิ่งที่ดีที่สุด และพวกเขามักจะเป็นผู้ให้บริการพิสูจน์การเดิมพันมืออาชีพ นอกจากนี้ เราจะกล่าวถึงประเด็นทางเศรษฐกิจเหล่านี้ในบทที่แยกต่างหากในภายหลัง
อย่างไรก็ตาม สิ่งสำคัญอย่างหนึ่งที่ต้องจำไว้สำหรับประเด็นเหล่านี้ก็คือ สิ่งที่สำคัญที่สุดคือการรับรองความถูกต้องของผู้ใช้ปลายทาง ซึ่งทุกคนสามารถใช้ได้ ไม่ว่าจะอยู่ที่ไหน (แม้แต่ในกิซ่า) ผ่านไคลเอ็นต์แบบเบาและพีระมิด DAS)
ที่มา: @JosephALChami
ต่อไปนี้เป็นข้อเสียและข้อดีของตัวคัดแยกที่มีขอบเขตและไม่มีขอบเขต:
ชุดตัวเรียงลำดับที่ไม่มีขอบเขต:
*ใครก็ตามที่มีพันธะ/การปักหลักเพียงพอสามารถเป็นผู้คัดแยกได้ = มีการกระจายอำนาจในระดับสูง
ชุดตัวเรียงลำดับที่มีขอบเขต:
นี่เป็นหนึ่งในวิธีแก้ปัญหาของ Ethereum สำหรับการกำหนดสล็อตเดียว และการมีคณะกรรมการ "เสียงข้างมาก"
มีห้องออกแบบจำนวนมากสำหรับวิธีตรวจสอบชุดตัวเรียงลำดับเหล่านี้และเพิ่มหรือลบสมาชิกใหม่ ตัวอย่างเช่น สิ่งนี้จะสำเร็จได้ผ่านการกำกับดูแลผู้ถือโทเค็น (แล้วโทเค็นและโรลอัพต่างๆ ซึ่งหมายความว่าการส่งสัญญาณการเปลี่ยนแปลงนอกเครือข่ายอาจเป็นไปได้ผ่านฉันทามติทางสังคม (เช่น ใช้ Ethereum เป็นตัวอย่าง) อย่างไรก็ตาม โปรดจำไว้ว่าฉันทามติบนเครือข่ายจริงนั้นถูกกำหนดขึ้นอย่างชัดเจน และมีบทลงโทษสำหรับการละเมิดกฎฉันทามติอยู่แล้ว
กลไกทางเศรษฐกิจสำหรับผู้คัดแยกที่ใช้ร่วมกัน
เศรษฐศาสตร์ของการแบ่งปันเครือข่ายของซีเควนเซอร์ทำให้มีตัวเลือกที่น่าสนใจบางอย่าง ดังที่เราได้กล่าวไปแล้วก่อนหน้านี้ เครื่องมือตรวจสอบความถูกต้องในเครือข่ายที่ใช้ร่วมกันนั้นไม่แตกต่างจากเครื่องมือตรวจสอบ L1 ทั่วไปมากนัก เครือข่ายที่เข้าร่วมได้รับการปรับให้เหมาะสมยิ่งขึ้นเพื่อทำงานหนึ่งอย่าง ซึ่งก็คือการรับ Intents (เดิมคือ PBS) และดังนั้นจึงเสนอและสั่งซื้อธุรกรรม เช่นเดียวกับตัวตรวจสอบความถูกต้อง "ปกติ" มีองค์ประกอบรายได้และต้นทุน ทั้งสองด้านของสมการมีความยืดหยุ่นอย่างมากในเครือข่ายที่ตัวตรวจสอบความถูกต้องเข้าร่วม คล้ายกับ L1 ปกติ
รายได้มาจากผู้ใช้หรือ Rollups ที่พวกเขาต้องการโต้ตอบกับการจ่ายค่าธรรมเนียมสำหรับการใช้ซีเควนเซอร์ร่วมกันในท้ายที่สุด ค่าธรรมเนียมนี้อาจเป็นเปอร์เซ็นต์ของ MEV ที่ถอนออก (การป้อนตัวเลขอาจเป็นเรื่องยากที่จะประมาณได้) การโอนมูลค่าข้ามสายโซ่ ก๊าซ หรือค่าธรรมเนียมคงที่ต่อการโต้ตอบ โซลูชันรายได้ที่เหมาะสมที่สุดอาจเป็นการจ่ายเงินให้กับผู้สั่งซื้อที่ใช้ร่วมกันในมูลค่าที่น้อยกว่ามูลค่าเพิ่มเติมที่ได้รับจากผู้สั่งซื้อที่แบ่งปันค่าสะสม พร้อมกับผลประโยชน์ของความปลอดภัยและสภาพคล่องที่ใช้ร่วมกัน แต่ข้อเสียคือเป็นการยากที่จะบอกปริมาณผลประโยชน์จากการกระจายอำนาจของส่วนอื่นๆ ของสแต็ก อย่างไรก็ตาม เมื่อเครือข่ายผู้สั่งซื้อที่ใช้ร่วมกันเติบโตขึ้นในระบบนิเวศของตนเอง ความสามารถในการดึงค่าธรรมเนียมอาจเพิ่มขึ้น สาเหตุส่วนใหญ่เกิดจากความสามารถในการรวมเข้าด้วยกันอย่างง่ายดายด้วยการประหยัดต่อขนาด เมื่อมี Rollups และแอปพลิเคชันเข้าร่วมเครือข่ายมากขึ้น MEV ข้ามโดเมนจำนวนมากขึ้นเรื่อยๆ จะสามารถดึงข้อมูลได้
ในแง่ของต้นทุน เครือข่ายการสั่งซื้อที่ใช้ร่วมกันยังมีตัวเลือกการแข่งขัน พวกเขาสามารถให้เงินสนับสนุนการใช้เครือข่ายได้อย่างง่ายดายโดยการให้ทุนเป็นค่าใช้จ่ายในการเผยแพร่บนเลเยอร์ DA หรือแม้แต่ค่าใช้จ่ายในการโต้ตอบกับแอปพลิเคชันใน Rollup ซึ่งคล้ายกับกลยุทธ์ที่ใช้โดยบริษัท Web 2.0 ซึ่งคุณจะยอมขาดทุนในเบื้องต้นจากการได้ผู้ใช้ใหม่ (หรือยกเลิก) โดยหวังว่ารายได้ระยะยาวของพวกเขาจะมากกว่าค่าธรรมเนียม อีกวิธีที่แปลกใหม่หรือแบบพื้นเมืองของ Crypto คือการอนุญาตให้ Rollup ชำระค่าธรรมเนียม DA ด้วยโทเค็นดั้งเดิม ที่นี่ ชั้นตัวเรียงลำดับที่ใช้ร่วมกันจะแบกรับความเสี่ยงด้านราคาระหว่างโทเค็นที่จำเป็นในการเผยแพร่ข้อมูลในชั้น DA และโทเค็นดั้งเดิมของ Rollup โดยพื้นฐานแล้ว มันยังคงเป็นค่าใช้จ่ายล่วงหน้าของตัวเรียงลำดับที่ใช้ร่วมกัน แต่จะสร้างความสอดคล้องของระบบนิเวศด้วยการได้รับโทเค็นของ "ซัพพลายเออร์" (เช่น การรวม) สิ่งนี้ค่อนข้างคล้ายกับการสร้างคลังสินค้าที่เราอธิบายไว้ในเอกสารของ AppChain และสามารถใช้รูปแบบต่างๆ ของ DA เพื่อลดต้นทุนได้ ระดับ DA ที่แตกต่างกันจะเสนอราคาที่แตกต่างกันเนื่องจากการใช้งาน ความสามารถของผู้ใช้ในการตรวจสอบได้อย่างง่ายดายผ่านไคลเอนต์ขนาดเล็ก หรือเพียงแค่เลือกขนาดบล็อกที่แตกต่างกัน สุดท้าย ผู้สั่งซื้อที่ใช้ร่วมกันยังสามารถทำธุรกรรมเป็นชุดก่อนที่จะเผยแพร่ไปยังเลเยอร์ DA ในกรณีของ ZKR สิ่งนี้สามารถลดต้นทุนการทำธุรกรรมผ่านยอดคงเหลือของธุรกรรมจำนวนหนึ่ง และในแง่ของ ORU คุณสามารถดำเนินการชุดการประมวลผลต่างๆ ให้เหมาะสม Gas ซึ่งปัจจุบันเราสามารถเห็นได้ใน Rollups ต่างๆ วิธีนี้จะลดปริมาณข้อมูลที่ต้องเผยแพร่ไปยังเลเยอร์ DA ซึ่งจะช่วยลดต้นทุนของเครือข่ายซีเควนเซอร์ที่ใช้ร่วมกัน และเพิ่มความสามารถในการทำกำไรของเครือข่ายทั้งหมด สิ่งนี้จะมาพร้อมกับการจำกัดความสามารถในการทำงานร่วมกันและการเปลี่ยนแปลงเวลาสิ้นสุดของบล็อก (การกำหนดใน L1 ตามที่กล่าวไว้ก่อนหน้านี้)
โดยรวมแล้ว เศรษฐศาสตร์ของการแบ่งปันเครือข่ายของซีเควนเซอร์ช่วยให้สามารถทดลองและวางกลยุทธ์ที่น่าสนใจได้ เราประเมินว่าความแตกต่างที่สำคัญคือขนาดของระบบนิเวศ ดังนั้นจำนวน MEV ข้ามโดเมนจึงมากกว่าด้านต้นทุน นอกจากนี้ เราขอแนะนำให้ตรวจสอบบล็อกโพสต์ของทีม Espresso เกี่ยวกับผู้สั่งซื้อที่ใช้ร่วมกัน พวกเขายังครอบคลุมถึงการแลกเปลี่ยนทางเศรษฐกิจ (และข้อดี) ของเครือข่ายประเภทนี้ เพื่อแสดงให้เห็นว่าเหตุใด Rollup จึงมีแรงจูงใจให้ใช้ประโยชน์จากตัวเรียงลำดับที่ใช้ร่วมกัน (นอกเหนือจากเศรษฐศาสตร์) เราสามารถพิจารณาได้จากมุมมองของทฤษฎีการรวม
ทฤษฎีการรวมตัวและตัวเรียงลำดับที่ใช้ร่วมกัน
อีกวิธีหนึ่งในการอธิบายคุณสมบัติที่เกิดจากตัวเรียงลำดับที่ใช้ร่วมกันคือผ่านเลนส์ของทฤษฎีการรวมตัว ทฤษฎีการรวมหมายถึงแนวคิดของวิธีที่แพลตฟอร์มหรือตัวรวบรวมรวมแพลตฟอร์มอื่นและผู้ใช้เข้าด้วยกันอย่างเป็นระบบเพื่อให้ได้รับความสนใจจากผู้ใช้อย่างมีนัยสำคัญ โดยพื้นฐานแล้ว คุณกำลังย้ายเกมจากการจัดสรรทรัพยากรที่หายาก (เช่น พื้นที่บล็อก) ไปสู่ความต้องการในการควบคุมทรัพยากรที่มีอยู่มากมาย (อีกครั้ง การบล็อกพื้นที่เหมาะสมในตัวอย่างนี้) ทฤษฎีการรวมรวมซัพพลายเออร์และผลิตภัณฑ์ (เช่น Rollup และ Blockspace) เข้ากับประสบการณ์ผู้ใช้ขั้นสูงเพื่อให้บริการฐานผู้ใช้โดยรวม เมื่อเอฟเฟกต์เครือข่ายของผู้รวบรวมเหล่านี้เติบโตขึ้น ความสัมพันธ์นี้จะกลายเป็นเอกสิทธิ์มากขึ้นเรื่อยๆ เมื่อสิ่งนี้เกิดขึ้น ประสบการณ์ของผู้ใช้จะกลายเป็นตัวสร้างความแตกต่างที่สำคัญระหว่างการตั้งค่าที่คล้ายคลึงกัน หากมีแรงจูงใจในการดึงดูดผู้ใช้ใหม่ (เช่น ประสบการณ์ผู้ใช้ที่ดีและความสามารถในการทำงานร่วมกันที่ดีขึ้น) ก็ไม่น่าเป็นไปได้ที่ Rollup จะย้ายไปที่เครือข่ายของตนเองหรือการตั้งค่าอื่น เนื่องจากผลกระทบของเครือข่ายทำให้ซัพพลายเออร์รายใหม่และผู้ใช้รายใหม่เข้าร่วม สิ่งนี้สร้างเอฟเฟ็กต์มู่เล่ ไม่เพียงแต่จากมุมมองของผู้ให้บริการและผู้ใช้เท่านั้น แต่ยังรวมถึงจากมุมมองที่ต่อต้านการเซ็นเซอร์โดยรวมด้วย
ที่มา: ทฤษฎีการรวมตัว 2015, Ben Thompson
ในขอบเขตของตัวเรียงลำดับที่ใช้ร่วมกัน ทฤษฎีการรวมตัวสามารถมองได้ว่าเป็น "ชุดค่าผสม" และการรวมศูนย์ของ Rollups ต่างๆ โดยทั้งหมดใช้ประโยชน์จากแนวดิ่งของสแต็กที่คล้ายคลึงกัน - เพิ่มขีดความสามารถให้กับตนเองและผู้อื่น ในขณะที่ให้ผู้ใช้ได้รับประสบการณ์เดียวกัน
ผู้ให้บริการ (เช่น Rollups) ในทางทฤษฎีไม่ได้จำกัดเฉพาะชุด coorter ที่ใช้ร่วมกัน แต่ในทางปฏิบัติ ชุด coorter ที่ใช้ร่วมกัน การยกเลิก และผู้ใช้จะได้รับประโยชน์จากชุดเอฟเฟกต์เครือข่ายแบบวนซ้ำซึ่งนำไปสู่การใช้การยกเลิกเหล่านี้ที่เพิ่มขึ้น ประโยชน์เหล่านี้ช่วยให้ Rollups และผู้ใช้สามารถผสานรวมเข้ากับสแต็คที่ใช้ร่วมกันได้ง่ายขึ้น เนื่องจากพวกเขาต้องสูญเสียมากกว่าเดิมหากไม่เข้าร่วม แม้ว่าประโยชน์เหล่านี้จะมองเห็นได้ยากเมื่อคุณมีเพียงสองค่าสะสมที่ใช้ร่วมกันในชุดซีเควนเซอร์ชุดเดียว ประโยชน์เหล่านี้จะชัดเจนขึ้นเมื่อคุณเพิ่มค่าสะสมและผู้ใช้ในสมการมากขึ้นเรื่อยๆ ชุดตัวเรียงลำดับที่ใช้ร่วมกันมีความสัมพันธ์โดยตรงกับผู้ใช้ ขณะที่พวกเขาสั่งธุรกรรม แม้ว่าผู้ใช้เองจะไม่รู้ว่ากำลังโต้ตอบกับพวกเขา เนื่องจากจากมุมมองของพวกเขา พวกเขาแค่ใช้ Rollups ที่พวกเขามีเหตุผลที่จะโต้ตอบด้วย ( ซึ่งหมายความว่าผู้สั่งซื้อ/ผู้คัดแยกจะกลายเป็นเอกสิทธิ์) ค่าใช้จ่ายเพียงอย่างเดียวของตัวคัดแยกเหล่านี้คือต้นทุนฮาร์ดแวร์ในการเรียกใช้ ตราบใดที่พื้นที่บล็อกและโทเค็นที่รักษาความปลอดภัยนั้นมีค่าสำหรับผู้ใช้ปลายทาง ค่าธรรมเนียมการทำธุรกรรมจะถูกแปลงเป็นรูปแบบดิจิทัล จ่ายออกจากกระเป๋าเงินของผู้ใช้ และบางทีในอนาคต อาจถูกยกเลิกผ่านความก้าวหน้า เช่น โฮสต์การชำระเงินในการแยกบัญชี (อย่างไรก็ตาม ใครบางคนจะต้องแบกรับค่าใช้จ่ายของ DA การสั่งซื้อ และการดำเนินการ)
สิ่งนี้เหมาะสมกว่าเมื่อพิจารณาถึงบริษัทเดิมของ Josh และ Jordan ใน Astria นั่นคือ Google ตั้งแต่เริ่มก่อตั้ง ผลิตภัณฑ์ของ Google ได้รับแรงบันดาลใจจากแนวคิดของ AT โดยเฉพาะอย่างยิ่งใน Google Search ซึ่งสร้างขึ้นโดยการปรับแต่ละหน้าและบทความให้เป็นโมดูล ทำให้เข้าถึงได้โดยตรงผ่านหน้าต่างค้นหาทั่วโลก
ในกรณีของชุดตัวเรียงลำดับที่ใช้ร่วมกัน ผู้ใช้ที่ใช้ Rollups (ผู้ที่ใช้ชุดตัวเรียงลำดับร่วมกัน) จะมีต้นทุนการได้มาซึ่งถูกลงและถูกลง เนื่องจากเมื่อจำนวนซัพพลายเออร์ (Rollup) เพิ่มขึ้น พวกเขามีแนวโน้มที่จะดึงดูดมาที่ชุด . ซึ่งหมายความว่า ในกรณีส่วนใหญ่ ตัวรวบรวม (หรือตัวรวบรวมหลายตัว) มีผลแบบวิน-วิน เนื่องจากมูลค่าของตัวรวบรวมจะเพิ่มขึ้นตามจำนวนซัพพลายเออร์ (แน่นอนว่าตราบใดที่ผู้ใช้ได้รับประสบการณ์ที่ดี) ในทางตรงกันข้าม ในเครือข่ายอนุกรมเดียว การได้มาซึ่งลูกค้าจะจำกัดอยู่ที่เครือข่ายเดียวและแอปพลิเคชันของเครือข่ายนั้น หากผู้ใช้ต้องการใช้แอปพลิเคชั่น Rollup บน Rollup อื่น พวกเขาจะต้องออกจากระบบเครือข่ายทั้งหมด (ภายในข้อจำกัดปัจจุบัน) ซึ่งหมายความว่าความเหนียวแน่นและมูลค่าของผู้ใช้ไม่สูงมากนัก และยังหมายความว่าเมื่อใดก็ตามที่ระบบ Rollup อื่นมีมูลค่าสูง (หรือมีสิ่งจูงใจมากกว่า) เงินทุนอาจสูญเสีย
สรุปแอตทริบิวต์และการแลกเปลี่ยน
คุณลักษณะ
ชุดตัวเรียงลำดับที่ใช้ร่วมกันคือเครือข่ายการยกเลิกที่รวบรวมและเรียงลำดับธุรกรรมสำหรับการยกเลิกหลายรายการ Rollups เหล่านี้ใช้ตัวเรียงลำดับเดียวกัน การรวมทรัพยากรนี้หมายความว่า Rollups ได้รับความปลอดภัยทางเศรษฐกิจที่แข็งแกร่งขึ้นและความสามารถในการต่อต้านการเซ็นเซอร์ ซึ่งสามารถให้การรับประกันเชิงกำหนดที่นุ่มนวลอย่างรวดเร็วและการทำธุรกรรมข้ามรายการแบบมีเงื่อนไข
ขณะนี้ มีข้อกังขามากมายเกี่ยวกับความเป็นปรมาณูใน Rollups ที่ใช้ตัวเรียงลำดับชุดเดียวกัน โดยส่วนใหญ่จะประมาณว่าเป็นปรมาณูโดยค่าเริ่มต้นหรือไม่ ซึ่งไม่ใช่ อย่างไรก็ตาม หาก Rollups ที่เป็นปัญหาใช้ State Transition Function (STF) ของกันและกันเป็นการพึ่งพาระหว่างกัน ซึ่งเกี่ยวข้องกับธุรกรรมแบบมีเงื่อนไข พวกมันจะสามารถบรรลุ Atomicity ระหว่างพวกมันได้ ตราบใดที่การจัดตำแหน่ง Slot/blocktime (เช่นเดียวกับชุดตัวเรียงลำดับที่ใช้ร่วมกัน) ในกรณีนี้ เพื่อให้ได้ความสามารถในการทำงานร่วมกันในระดับปรมาณู คุณจะต้องเรียกใช้ไคลเอ็นต์แบบเบาของเชน B บนเชน A และในทางกลับกัน (คล้ายกับวิธีการทำงานของ IBC) เพื่อเสริมสร้างความสามารถในการทำงานร่วมกันของมาตรการรักษาความปลอดภัย (นอกเหนือจากการไว้วางใจโหนดเดียวเต็มรูปแบบเป็นโหนดแสง) คุณสามารถใช้ ZKP (Proof of State) เพื่อแก้ปัญหา "ปัญหาของ oracle" เพื่อรับรองความถูกต้องของสถานะ การดำเนินการนี้จะทำให้เห็นได้ชัดเจนว่าธุรกรรมแบบมีเงื่อนไขหรืออะไรทำนองนั้นชนสะพานข้ามสายโซ่แบบบัญญัติระหว่างกันหรือไม่ หลักฐานการฉ้อโกงก็เป็นไปได้เช่นกัน แต่เห็นได้ชัดว่าจะปล่อยให้มีระยะเวลาท้าทาย (หมายความว่าบุคคลที่สามจะเข้ามารับผิดชอบค่าใช้จ่ายของความเสี่ยงนี้) นอกจากนี้ ในกรณีของไลท์ไคลเอนต์ (แทนที่จะเป็นโหนดเต็ม) จะช้ากว่านั้นอย่างน้อยหนึ่งบล็อกเนื่องจากรอส่วนหัวลายเซ็น + หน้าต่างหลักฐานการฉ้อโกง (ถ้ามี)
เราเชื่อว่าปัญหา "สะพานข้ามโซ่" มักจะได้รับการแก้ไขด้วยไคลเอนต์ที่มีน้ำหนักเบาและการพิสูจน์ที่ไม่มีความรู้ ความท้าทายในการใช้ไคลเอนต์ที่มีน้ำหนักเบา (แทนที่จะเป็นสัญญาอัจฉริยะ) ในกรณีนี้คือฮาร์ดฟอร์ก (การอัปเกรด ฯลฯ) ที่ฝั่งโหนด Rollup จำเป็นต้องประสานงานกันเพื่อให้บริดจ์ทำงาน (เช่นเดียวกับที่ IBC ต้องเปิดใช้งาน โมดูลสถานะเดียวกัน ) หากคุณต้องการเจาะลึกในหัวข้อนี้โดยเฉพาะ (และวิธีแก้ไขปัญหา) เราขอแนะนำให้ตรวจสอบงานนำเสนอนี้
เหตุผลที่ผู้สั่งใช้ร่วมกันปรับขนาดได้ดีคือพวกเขาไม่ได้ดำเนินการและจัดเก็บสถานะใดๆ เช่นเดียวกับโหนดค่าสะสม (เว้นแต่ว่าพวกเขาต้องการความเป็นปรมาณูระหว่างกัน - เช่นไคลเอ็นต์แบบเบา/การพิสูจน์สถานะ) โหนดเหล่านี้ดำเนินการเฉพาะธุรกรรมที่ถูกต้องสำหรับการยกเลิก และธุรกรรมข้ามโดเมนแบบมีเงื่อนไขใดๆ ที่ถูกต้องสำหรับโหนดเหล่านี้ หากโหนดค่าสะสมต้องดำเนินการและจัดเก็บสถานะสำหรับค่าค่าสะสมหลายค่า จะขัดขวางความสามารถในการปรับขนาดและลดการกระจายอำนาจ (และทำให้มีการต่อต้านการเซ็นเซอร์) สิ่งนี้ยังตอกย้ำแนวคิดของการแยกผู้ผลิตและผู้สร้างบล็อก (PBS) แม้ว่าเรายังจำเป็นต้องแยกผู้สร้างและบล็อกผู้ผลิตออกจากกันโดยสิ้นเชิง ในการตั้งค่าปัจจุบัน ผู้สั่งซื้อโดยพื้นฐานแล้วจะเป็นผู้สร้างและผลิตบล็อก (แม้ว่าพวกเขาจะไม่ได้ทำธุรกรรมก็ตาม) การตั้งค่าในอุดมคติอาจเป็นการตั้งค่าที่ผู้สั่งซื้อมีอยู่เพียงเพื่อลงนามบล็อกแบบสุ่มสี่สุ่มห้าจากการตั้งค่าตัวสร้างที่ปรับให้เหมาะสมในระดับสูง และตรวจสอบให้แน่ใจว่ามีการใช้บล็อกอย่างถูกต้อง (ในขณะเดียวกันก็ให้ความแน่นอนทางเศรษฐกิจในระดับสูงและการต่อต้านการเซ็นเซอร์ต่อการรับรองนั้น) ด้วยวิธีนี้ พวกเขาสามารถให้ความปลอดภัยระดับสูงและความมุ่งมั่นในการรับประกันการสิ้นสุดที่นุ่มนวลให้กับโหนดค่าสะสม
สำหรับธุรกรรมแบบมีเงื่อนไขแบบ cross-rollup พวกมันยังมีอยู่เพื่อช่วยเปิดใช้งานโหนดการยกเลิก (executors) เพื่อให้รูทสถานะระดับกลาง เปิดใช้งานความเป็นปรมาณูระหว่างการยกเลิก
###งดแลกครับ
พารามิเตอร์การหมดเวลาดังกล่าวข้างต้นมีผลที่น่าสนใจบางอย่างต่อ MEV และการรวมธุรกรรม ขึ้นอยู่กับกลไกของโหนดหลัก/ฉันทามติของชุดคำสั่ง ตัวอย่างเช่น หากพารามิเตอร์การหมดเวลาได้รับการอธิบายค่อนข้างสั้นในรายงานห่วงโซ่เฉพาะแอปพลิเคชันของเรา จำเป็นอย่างยิ่งที่จะต้องบล็อกผู้ผลิตชุดคำสั่งที่กระจายอำนาจเผยแพร่ข้อมูลให้เร็วที่สุดเท่าที่จะเป็นไปได้ ในโลกดังกล่าว คุณสามารถเห็นการแข่งขันระหว่าง "ผู้ตรวจสอบความถูกต้อง" ที่แข่งขันกันเพื่อเป็นโหนดหลักและประมูลพื้นที่บล็อกในเลเยอร์ DA จนกว่าจะไม่สามารถทำกำไรได้อีกต่อไป
ดังที่ Evan ได้กล่าวไว้ในโพสต์ขี้เกียจสั่งดั้งเดิมของเขาบนฟอรัม Celestia การรอธุรกรรมที่จะเผยแพร่ไปยังเลเยอร์พื้นฐาน (ในกรณีนี้คือ Celestia) ก่อนที่จะดำเนินการนั้นไม่มีประสิทธิภาพมากนัก เนื่องจากตอนนี้คุณถูกจำกัดด้วยเวลาบล็อกของชั้นฐาน ซึ่งนานเกินไปที่จะรอประสบการณ์ของผู้ใช้ เพื่อให้ผู้ใช้ได้รับประสบการณ์ที่ดีขึ้น ผู้สั่งซื้อที่ใช้ร่วมกันจะจัดเตรียม Rollups ด้วยข้อผูกมัดที่กำหนดขึ้นอย่างนุ่มนวล (ตามที่อธิบายไว้ก่อนหน้านี้) ซึ่งมอบประสบการณ์การใช้งานของผู้ใช้ที่พวกเขาคุ้นเคยใน Rollups แบบรวมศูนย์ที่มีอยู่ (ในขณะที่ยังคงการกระจายอำนาจและการต่อต้านการเซ็นเซอร์สูง) ภาระผูกพันที่นุ่มนวลโดยพื้นฐานแล้วเป็นเพียงภาระผูกพันต่อลำดับสุดท้ายของการทำธุรกรรม แต่ได้รับการสนับสนุนจากการรับประกันทางเศรษฐกิจที่หนักหน่วงและการสรุปผลอย่างรวดเร็วเมื่อเผยแพร่ นอกจากนี้ยังครอบคลุมถึงหลักฐานการฉ้อโกง (ตามที่กล่าวไว้ในบทนำ) การสิ้นสุดขั้นสุดท้ายที่แท้จริงจะเกิดขึ้นหลังจากข้อมูลธุรกรรมทั้งหมดได้รับการเผยแพร่ไปยังชั้นฐาน (หมายความว่า L1 บรรลุขั้นสุดท้ายได้เร็วขึ้น) ขึ้นอยู่กับว่า Rollup ใช้หลักฐานการฉ้อโกงหรือหลักฐานที่ไม่มีความรู้สำหรับการตรวจสอบหลักฐานอำนาจอธิปไตย ซึ่งเกิดขึ้นใน Rollup เหตุผลที่ต้องการการแยกนี้คือเพื่อขจัดคอขวดขนาดใหญ่ของการเปลี่ยนสถานะออกจากตัวเรียงลำดับ แทน โหนดค่าสะสมจะจัดการกับโหนดที่ถูกต้องเท่านั้น (หมายความว่าเราต้องเพิ่มธุรกรรมแบบมีเงื่อนไข การพิสูจน์สถานะ หรือการตรวจสอบความถูกต้องของไลท์โหนดเพื่อการทำงานร่วมกันที่เหมาะสม) การกำหนดระดับยากยังคงขึ้นอยู่กับชั้นฐาน (แต่อาจถึง 15 วินาทีใน Celestia และยังกำหนดระดับได้ภายใต้ Tendermint) ซึ่งทำให้เราสามารถรับประกันการกำหนดระดับยากที่ค่อนข้างรวดเร็วใน Rollup
ใช้การพิสูจน์ที่ไม่มีความรู้ภายในเครือข่ายเพื่อเพิ่มประสิทธิภาพการตรวจสอบความถูกต้อง ขนาดธุรกรรม (เช่น เผยแพร่เฉพาะความแตกต่างของสถานะ - แต่จะเพิ่มระดับความน่าเชื่อถือให้สูงขึ้นจนกว่า ZKP จะได้รับการเผยแพร่) ดังที่ได้กล่าวไว้ก่อนหน้านี้ การพิสูจน์สถานะเหล่านี้สามารถใช้เพื่อให้เชน/โรลอัปที่เชื่อมต่อกันมีความสามารถในการทำงานร่วมกันที่ง่ายและรวดเร็วขึ้น (โดยไม่ต้องรอหน้าต่างท้าทาย)
ข้อเสียของการทำธุรกรรมแบบมีเงื่อนไขเหล่านี้คือ ธุรกรรมเหล่านี้มีแนวโน้มที่จะมีราคาแพงกว่า ซึ่งต้องใช้ค่าใช้จ่ายในการตรวจสอบและการออกที่สูงขึ้น (เช่น ค่าใช้จ่ายในการตรวจสอบส่วนหัวของบล็อก Tendermint ซึ่งได้รับการสนับสนุนในเครือข่าย Cosmos) และเพิ่มเวลาแฝงให้กับระบบ ( แต่ก็ยังเร็วกว่า Isolated Rollups ที่เร็วกว่ามาก) ความเป็นปรมาณูที่เกิดจากการรวมเข้าด้วยกันในแนวดิ่งสามารถชดเชยปัญหาเหล่านี้ได้
ในระหว่างขั้นตอนการบู๊ตสแตรปของการยกเลิกใหม่ การใช้ชุดคอลเลเตอร์ที่ใช้ร่วมกันเป็นสิ่งที่สมเหตุสมผล และข้อดีที่คุณได้รับในฐานะผู้ให้บริการน่าจะเกินดุลการแลกเปลี่ยนบางอย่างที่คุณอาจถูก "บังคับ" ให้ทำในระดับคูเมือง อย่างไรก็ตาม สำหรับค่าสะสมที่ครบกำหนดแล้ว ซึ่งมีธุรกรรมและกิจกรรมทางเศรษฐกิจจำนวนมาก อาจไม่สมเหตุสมผลที่จะละทิ้งส่วนหนึ่งของคูเมือง
สิ่งนี้ทำให้เกิดคำถามว่าเราต้องการการกระจายน้ำหนักของ MEV ที่แยกออกมาในเชิงเศรษฐกิจ/ธุรกรรม (ต่อ Rollup) ที่คล้ายคลึงกันหรือไม่ เพื่อชักนำ Rollups ที่ครบกำหนดแล้วให้เข้าร่วมชุดที่ใช้ร่วมกัน หรือแม้กระทั่งกันไม่ให้ Rollups ที่ครบกำหนดมากสร้างเครือข่ายของตัวเอง ทั้งหมดนี้ค่อนข้างเป็นทฤษฎี แต่ไม่ต้องสงสัยเลยว่าเป็นกระบวนการคิดที่น่าสนใจเกี่ยวกับวิธีที่ MEV ในโลกแนวตั้งที่ใช้ร่วมกันจะแสดงระหว่าง Rollups จำนวนมากที่มีกิจกรรมหลายระดับ ตัวอย่างเช่น หากค่าสะสมที่ไม่ซ้ำกันที่ขับเคลื่อนมูลค่าแบ่งปันผลกำไรเหล่านี้บางส่วนกับผู้อื่น (อาจไม่นำ "มูลค่า" มากนัก) ผ่านทาง Sequencer Set จะต้องมีเหตุผลมากกว่านี้ที่พวกเขาย้ายเข้าสู่ระบบแยกของตนเอง Sreeram โดย EigenLayr ก็มีความคิดเกี่ยวกับเรื่องนี้เช่นกัน ซึ่งเราขอแนะนำให้อ่านเช่นกัน
สิ่งนี้มีความสำคัญมากขึ้นเมื่อพิจารณาว่ามีค่าใช้จ่ายทางเทคนิคจำนวนมากสำหรับผู้ค้นหาในการพัฒนาเชนใหม่ ดังนั้นการสร้างมาตรฐานและมอบอำนาจอธิปไตยเหนือ MEV "ของพวกเขา" อาจเป็นจุดเริ่มต้นที่ดี ในทางปฏิบัติ ใน MEV อินเทอร์เฟซ (หรือซอฟต์แวร์) ที่โดดเด่นอาจชนะ แต่จริง ๆ แล้วการสร้างรายได้จากซอฟต์แวร์นั้นโดยการเรียกใช้ส่วนที่สำคัญของโครงสร้างพื้นฐานนั้นยากมาก (นำไปสู่การรวมศูนย์) ในระดับตลาด สิ่งที่ผู้สั่งซื้อร่วมกันมอบให้นั้นโดยพื้นฐานแล้วจะเป็น mempool ทั่วไปสำหรับผู้ให้บริการหลายราย โดยมีการประมูลแบบรวมศูนย์ ซึ่งอาจนำไปสู่การแข่งขันที่ดียิ่งขึ้น
ข้อกังวลคือหาก Rollups สองรายการกำลังเรียกใช้ตัวเรียงลำดับในชุดที่ใช้ร่วมกัน ดังนั้นอาจมีการเลือก Rollup ที่มีค่า "ประหยัดน้อยกว่า" (A) เพื่อเสนอการยกเลิกที่มี MEV + ค่าธรรมเนียมจำนวนมากจาก Rollup (B) . จากมุมมองของ Rollup B พวกเขาพลาดคุณค่าบางอย่างไปโดยหลักแล้ว พวกเขามักจะเก็บไว้เพื่อตัวเอง
การจัดการการแลกเปลี่ยนการทำงานร่วมกัน
ข้อควรทราบอีกประการหนึ่งเกี่ยวกับการแลกเปลี่ยนที่นำเสนอโดยความสามารถในการทำงานร่วมกัน และอีกวิธีหนึ่งในการแก้ปัญหาบางอย่างดังต่อไปนี้:
จุดประสงค์ของเครือข่ายผู้สั่งซื้อที่ใช้ร่วมกันคือเพื่อให้การรับประกันมาตรฐานสำหรับเชนหลายตัว ซึ่งเห็นได้ชัดว่าเป็นข้อได้เปรียบอย่างมากในกรณีนี้ สิ่งนี้สามารถใช้ร่วมกับกลไกเพื่อรับประกันการเปลี่ยนสถานะที่มีประสิทธิภาพระหว่าง Rollups นี่อาจเป็นแนวทางของคณะกรรมการ (เช่น PoS) การพิสูจน์ที่ปลอดภัย (แนวทางในแง่ดี) หรือแนวทางที่เราต้องการ - ZKP ที่ได้รับการสนับสนุนโดยลายเซ็นของคณะกรรมการ เนื่องจากตัวเรียงลำดับที่ใช้ร่วมกันนั้น "ขี้เกียจ" พวกเขาจึงสร้างบล็อกขั้นสูงเพื่อจัดเรียงธุรกรรมของค่าสะสมหลายรายการเท่านั้น และการดำเนินการธุรกรรมเฉพาะจะถูกปล่อยให้เป็นค่าสะสมที่ระบุ การพิสูจน์สถานะ (เช่น Lagrange, Axiom หรือ Herodotus เป็นต้น) เป็นวิธีแก้ปัญหาที่เป็นไปได้ทั้งหมดสำหรับการได้รับหลักฐานการสิ้นสุดของอำนาจอธิปไตย คุณยังสามารถเพิ่มข้อพิสูจน์ของการรับประกันการสิ้นสุดทางเศรษฐกิจผ่านสิ่งต่างๆ เช่น stake pools, EigenLayr เป็นต้น แนวคิดพื้นฐานคือเครื่องคัดแยกที่ใช้ร่วมกันให้การรับประกันทางเศรษฐกิจของการสั่งซื้อ และการพิสูจน์ความถูกต้องที่เกิดจากการคัดแยกนี้จะถูกกำหนดขึ้น แนวคิดพื้นฐานคือ Rollups สามารถดำเนินธุรกรรมพร้อมกันได้ ตัวอย่างเช่น เครือข่ายของโหนดค่าสะสมสองโหนดสามารถทราบแบบมีเงื่อนไขว่าประวัติค่าสะสมทั้งสองนั้นถูกต้อง ผ่าน ZKP และข้อมูลที่มีอยู่ (ข้อมูลที่เผยแพร่ไปยังชั้น DA ที่มีประสิทธิภาพ) ด้วยการเผยแพร่คำนำหน้าบล็อกค่าสะสมเดียวจากทั้งเครือข่าย A และ B โหนดค่าสะสมสามารถชำระค่าค่าสะสมสองค่าพร้อมกันได้ สิ่งหนึ่งที่ต้องชี้ให้เห็นก็คือ ธุรกรรมการย้อนกลับแบบมีเงื่อนไขใช้ทรัพยากรจากสองระบบที่แยกจากกันผ่านการดำเนินการที่ใช้ร่วมกัน ดังนั้นธุรกรรมแบบอะตอมมิก (หรือซิงโครนัส) การย้อนกลับข้ามรายการจึงมีแนวโน้มที่จะมีราคาแพงกว่าการทำธุรกรรมภายในแบบการยกเลิกครั้งเดียว
Succinct ยังครอบคลุมถึงธุรกรรม "atomic" ข้ามเชนระหว่าง Rollups กับผู้สั่งซื้อที่ใช้ร่วมกัน (และผู้พิสูจน์การฉ้อโกงที่ใช้ร่วมกัน) ภายในระบบนิเวศไฮเปอร์เชน Optimism ซึ่งสามารถดูได้ที่นี่ นอกจากนี้ตามที่ Bo Du ของ Polymer กล่าวไว้ว่า: "ธุรกรรมปรมาณูข้ามสายโซ่เปรียบเสมือนการได้มาซึ่งล็อคระหว่างเศษฐานข้อมูลเมื่อเขียน"
อนาคตของการบูรณาการในแนวดิ่ง
การทำงานภายในที่เป็นไปได้ของโซ่ SUAVE ได้รับการสำรวจในเชิงลึกแล้วโดย Jon Charbonneau et al ดังนั้นเราจะไม่ลงรายละเอียดมากเกินไป หากคุณต้องการคำอธิบายโดยละเอียด คุณสามารถอ่านบทความของเขาได้ อย่างไรก็ตาม เราคิดว่าการผสานรวมในแนวดิ่งสมควรได้รับการแนะนำแยกต่างหาก ทั้งเพื่อเน้นย้ำว่าเราเป็นโมดูลาร์ได้อย่างไร (และทำไม) และเพื่อแนะนำประเด็นและข้อกังวลบางประการที่เกี่ยวข้องกับการผสานรวมในแนวดิ่ง
ในขณะที่แผนการสั่งซื้อที่ใช้ร่วมกันในปัจจุบันของ Astria, Espresso และ Radius เป็นแบบโมดูลาร์มาก ผู้สั่งซื้อยังคงทำหน้าที่เป็นผู้สร้างและผู้ผลิตบล็อก (แม้ว่าในกรณีของ Astria พวกเขาไม่ได้ทำธุรกรรมก็ตาม) Astria ยังสร้าง PBS อย่างจริงจังในสถาปัตยกรรมตั้งแต่เริ่มต้น
หาก PBS ไม่ได้รวมอยู่ในโปรโตคอล มีหลายวิธีที่จะนำ PBS ไปใช้งาน (แม้ว่าจะมีการกระจายอำนาจหลายระดับก็ตาม) ผลิตภัณฑ์เช่น SUAVE ใช้โมเดลออฟไลน์ เช่น MEV-Boost หรือใช้โมดูลตัวสร้าง เช่น โมดูล Cosmos SDK ที่สร้างโดย Mekatek และ Skip
เป็นที่น่าสังเกตว่าวิธีการเหล่านี้ไม่มีข้อยกเว้นร่วมกัน คุณมีความยืดหยุ่นในการใช้วิธีต่างๆ มากมายและให้ทุกคนแสดงความชอบได้ ด้วยวิธีนี้ คุณสามารถให้ผู้ดำเนินการแข่งขันกันเพื่อเติมเต็มตำแหน่งงานว่างเหล่านั้นได้ การเพิ่มตัวเลือกเป็นสิ่งที่ดีเสมอ (และสอดคล้องกับความเชื่อของเราในเรื่องโมดูลาร์) ถึงกระนั้น การใช้งานที่แตกต่างกันจะมีจุดเปลี่ยนที่แตกต่างกัน ตัวอย่างเช่น ในกรณีเช่น SUAVE คุณสามารถเพิ่มการปกป้องความเป็นส่วนตัวผ่านเทคโนโลยี SGX หรือ Crypto และเพิ่มความปลอดภัยทางเศรษฐกิจของ Crypto ให้กับความจริง แทนที่จะพึ่งพาตัวสร้าง PBS จากส่วนกลางที่เชื่อถือได้อย่างเต็มที่ (ขอบคุณ Jon Charbonneau สำหรับความคิดเห็นของเขาที่นี่)
การผสานรวมในแนวดิ่งเข้ากับห่วงโซ่ตัวสร้างช่วยให้มั่นใจได้ถึงความยุติธรรมโดยไม่ต้องใช้ทางลัด เพิ่มเวลาแฝงและลดประสิทธิภาพ ดังนั้น ห่วงโซ่ตัวสร้างจำเป็นต้องได้รับการปรับให้เหมาะสมอย่างมาก และอาจต้องใช้ฮาร์ดแวร์ที่มีราคาแพงและทรงพลัง (นำไปสู่การรวมศูนย์) ซึ่งหมายความว่าเพื่อให้ได้รับการตรวจสอบความถูกต้องของผู้ใช้ปลายทาง เราอาจต้องใช้โหนดแบบเบาบางประเภท (แม้ว่าพวกเขาจะต้องเชื่อถือโหนดแบบสมบูรณ์) หรือใช้หลักฐานการตั้งค่าประเภทสถานะเพื่อให้แน่ใจว่าเชนและผู้ใช้มีหลักฐานว่าการตั้งค่าการเสนอราคา ได้รับการเติมเต็มและบล็อกมีโครงสร้างที่ถูกต้อง
ห่วงโซ่เช่นนี้อาจเป็นสถานะที่หนักมาก (เราต้องการหลีกเลี่ยงสิ่งนี้) แม้ว่าธุรกรรมจำนวนมากของรัฐเหล่านี้จะได้รับการจัดลำดับความสำคัญผ่านสัญญาอัจฉริยะ ในกรณีของการเสนอราคาที่มีลำดับความสำคัญ อาจได้รับการเติมเต็มหรือไม่ได้รับการเติมเต็ม (ในช่วงเวลาสั้นๆ) เนื่องจากการเสนอราคามักจะใช้ได้ในช่วงเวลาสั้นๆ เท่านั้น ขึ้นอยู่กับความต้องการ ซึ่งหมายความว่าเราอาจสามารถใช้การหมดอายุสถานะที่มีประสิทธิภาพมาก (และก่อนกำหนด) สำหรับการเสนอราคา ซึ่งจะช่วยให้เราตัดข้อมูลและทำให้ห่วงโซ่ "สะอาด" วันที่หมดอายุนี้ต้องนานพอที่จะยังคงอนุญาตให้เสนอราคาได้ก่อน แต่การลดมากเกินไปจะทำให้แทบจะเป็นไปไม่ได้เลยที่จะบรรลุอนาคตของบล็อกสเปซในอนาคต เราไม่จำเป็นต้องอัปเดตและเรียกคืนสัญญาการประมูลที่หมดอายุเนื่องจากไม่จำเป็นต้องมีอยู่ตลอดไป (ไม่เหมือนกับแอป) ซึ่งสามารถทำได้โดยการให้หลักฐานสถานะ/พื้นที่เก็บข้อมูลเมื่อมีการเสนอราคาหรือโดยโซลูชันพื้นที่เก็บข้อมูล DAS (เช่น ที่เสนอ โดยโซลูชัน Joachim Neu) เพื่อให้ "ปลอดภัย" และน่าเชื่อถือยิ่งขึ้น
ดังที่ได้กล่าวไว้ก่อนหน้านี้ ความจำเป็นในการยืนยัน "ความถูกต้อง" ของ SUAVE อาจจำกัดอยู่ที่ "jusha" (ผู้ใช้ขั้นสูง) ของแพลตฟอร์ม เนื่องจากผู้ใช้และลูกค้าส่วนใหญ่ของ SUAVE สามารถได้รับประโยชน์ทางเศรษฐกิจสูงจากแพลตฟอร์มดังกล่าว การดำเนินการนี้อาจผลักดันให้เราอนุญาตให้ผู้ใช้เรียกใช้โหนดแบบเต็มได้เฉพาะในกรณีที่ต้องการตรวจสอบความถูกต้อง แม้ว่าการดำเนินการนี้จะไม่รวมคนส่วนใหญ่ (คุณอาจกล่าวได้ว่าพวกเขาไม่จำเป็นต้องตรวจสอบความถูกต้อง) นี่คือ (ในความเห็นของเรา) ตรงกันข้ามกับ Crypto ซึ่งเราต้องการใช้การตรวจสอบ SUAVE ที่ "ไม่น่าเชื่อถือ" ผ่านการพิสูจน์ของรัฐหรือการใช้งานที่เป็นมิตรกับลูกค้า
เหตุผลที่จำเป็นคือคุณต้องการตรวจสอบว่าลำดับความสำคัญของการเสนอราคาของคุณได้รับการเติมอย่างถูกต้อง และการบล็อกนั้นเต็มไปด้วยข้อมูลที่ถูกต้องเมื่อชำระเงิน (เพื่อหลีกเลี่ยงการคืนสินค้าและบั๊กอื่นๆ) นี่เป็นปัญหาของ oracle โดยพื้นฐานแล้ว - อันที่จริงสามารถแก้ไขได้ด้วยการพิสูจน์สถานะ (เช่นเดียวกับ SUAVE ทั้งหมด) อย่างไรก็ตาม การพิสูจน์สถานะเหล่านี้ทำให้เกิดปัญหาอีกประการหนึ่งเมื่อทำการข้ามสายโซ่ วิธีการถ่ายทอดข้อมูลนี้ข้ามสายโซ่ในลักษณะที่ไม่ถูกแก้ไขหรือปกปิด? การดำเนินการนี้อาจต้องผ่านขั้นตอนสุดท้ายทางเศรษฐกิจที่แข็งแกร่ง (เช่นข้อเสนอของ Lagrangian) ซึ่งในกรณีนี้คุณสามารถใช้เครื่องมือตรวจสอบความถูกต้องของ EigenLayr เพื่อพิสูจน์ความถูกต้องของห่วงโซ่ได้ และมีข้อจำกัดทางเศรษฐกิจที่แข็งแกร่งมาก สิ่งนี้นำมาซึ่งปัญหาอื่น (เช่น สัญญาการประมูลระบุว่า "เครื่อง oracle" - ในกรณีนี้คือผู้จำนำใหม่ - ได้กำหนดโทเค็นที่ให้คำมั่นและให้ผลผูกพันทางเศรษฐกิจ - แต่เราจะทำฉันทามติระหว่างการเฉือนจากภายนอกได้อย่างไร ในขณะที่ คุณสามารถเขียน slashing criteria ได้ ซึ่งไม่อยู่ในฉันทามติ ซึ่งหมายความว่า social slashing จะถูกใช้ประโยชน์ผ่าน smart contracts (ซึ่งแทบจะไม่ "ยุติธรรม" เลย และอาจทำให้เกิดปัญหาได้) ปัจจุบัน EigenLayr เป็นปัญหาใหญ่อย่างหนึ่งของการริบ .
แล้วสิ่งนี้จะทิ้งเราไว้ที่ไหน? อาจเป็นไปได้ จนกว่าเราจะได้รับ "ความไม่ไว้วางใจ" บนเครือข่ายอย่างเจ็บแสบเกินฉันทามติ เครือข่ายอย่าง SUAVE อาจต้องการอัลกอริทึมที่เป็นเอกฉันท์ของตนเองและความปลอดภัยของ Cryptoeconomic เพื่อพิสูจน์การตั้งค่าราคาเสนอและสร้างความแน่นอนในการบล็อก— อย่างไรก็ตาม นี่หมายถึงการเพิ่มเวกเตอร์การโจมตีทางเศรษฐกิจแบบเข้ารหัสลับให้มากขึ้น โดยเฉพาะอย่างยิ่งหากมีการยกเลิก มูลค่าของหน่วยการสร้างนั้นสูงกว่าการรักษาความปลอดภัย cryptoeconomic ของมันเองมาก
นอกจากนี้ ยังมีพื้นที่การออกแบบอีกมากในห่วงโซ่ประเภท SUAVE และ MEV ข้ามโดเมน ต่อไปนี้เป็นทิศทางการวิจัยที่เป็นไปได้บางส่วน:
เกี่ยวกับการแสดงออกของการตั้งค่า ในการโต้ตอบกับสัญญาอัจฉริยะใน EVM จำเป็นต้องส่งการเรียกตามสัญญา (ข้อความ) ไปยังฟังก์ชันเฉพาะตามที่อยู่ของรหัสที่ใช้งานซึ่งมีคำสั่งการดำเนินการ ในขณะที่ผู้ใช้ป้อนข้อมูล พวกเขาอาจไม่สามารถควบคุมเอาต์พุตได้เนื่องจากสถานะที่เป็นไปได้
ในทางตรงกันข้าม ระบบการออกแบบการแสดงออกตามความชอบ (เช่น SUAVE และ Anoma) กำหนดให้ผู้ใช้ลงนามในการกำหนดลักษณะด้วยพันธบัตรเท่านั้น ซึ่งจะจ่ายให้กับผู้สร้างและบล็อกผู้ผลิตหากตรงกับการตั้งค่าของผู้ค้นหา สำหรับตรรกะเชิงผสมที่ซับซ้อน เช่น ลำดับธุรกรรมสำหรับผู้ค้นหาและผู้สร้าง MEV อาจจำเป็นต้องใช้ภาษาและเครื่องเสมือนที่แตกต่างกัน เป็นพื้นที่ดีไซน์ใหม่ที่ได้รับความสนใจอย่างมากในช่วงหลังมานี้ โดยเฉพาะ สถาปัตยกรรมอโนมา นอกจากนี้ เราขอแนะนำบทความสั้นๆ นี้เป็นอย่างยิ่ง