ผู้เขียนต้นฉบับ: Kyle Samani หุ้นส่วนของ Multicoin Capital

ต้นฉบับเรียบเรียง: ลูฟี่, Foresight News

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

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

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

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

ระบบโมดูลาร์เพิ่มความซับซ้อนในการพัฒนา

ต้นทุนที่ซ่อนอยู่ที่ใหญ่ที่สุดของระบบโมดูลาร์คือความซับซ้อนที่เพิ่มขึ้นของกระบวนการพัฒนา

ระบบโมดูลาร์เพิ่มความซับซ้อนอย่างมากที่นักพัฒนาแอปพลิเคชันต้องจัดการ ทั้งในบริบทของแอปพลิเคชันของตนเอง (ความซับซ้อนทางเทคนิค) และในบริบทของการโต้ตอบกับแอปพลิเคชันอื่น (ความซับซ้อนทางสังคม)

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

ตัวอย่างเช่น ลองพิจารณา OP Stack ณ ตอนนี้ ดูเหมือนว่าจะเป็นเฟรมเวิร์กโมดูลาร์ที่ได้รับความนิยมมากที่สุด OP Stack บังคับให้นักพัฒนาเลือกที่จะนำมาใช้ Law of Chains(ซึ่งทำให้เกิดความซับซ้อนทางสังคมมากมาย) หรือแยกและจัดการแยกกัน ทั้งสองตัวเลือกทำให้เกิดความซับซ้อนด้านดาวน์สตรีมที่สำคัญแก่ผู้สร้าง หากคุณเลือกที่จะแยก คุณจะได้รับการสนับสนุนด้านเทคนิคจากผู้เล่นในระบบนิเวศรายอื่น (CEX, fiat onramps ฯลฯ) ที่ต้องแบกรับต้นทุนเพื่อให้เป็นไปตามมาตรฐานเทคโนโลยีใหม่หรือไม่? หากคุณเลือกที่จะปฏิบัติตามกฎแห่งโซ่ตรวน คุณจะมีกฎและข้อจำกัดอะไรบ้างในวันนี้และวันพรุ่งนี้?

ที่มา: โมเดล OSI

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

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

โดยบังเอิญ Ethereum กำลังลดความซับซ้อนที่เกิดขึ้นระหว่างยุค Bitcoin fork ปี 2554-2557 ผู้เสนอโมดูลาร์มักเน้นย้ำโมเดล Open Systems Interconnection (OSI) โดยโต้แย้งว่าความพร้อมใช้งานของข้อมูล (DA) และการดำเนินการควรแยกจากกัน อย่างไรก็ตาม ข้อโต้แย้งนี้ถูกเข้าใจผิดอย่างกว้างขวาง ความเข้าใจที่ถูกต้องเกี่ยวกับปัญหาที่เกิดขึ้นนำไปสู่ข้อสรุปที่ตรงกันข้าม: OSI เป็นข้อโต้แย้งสำหรับระบบบูรณาการมากกว่าระบบโมดูลาร์

Modular chains ไม่สามารถรันโค้ดได้เร็วขึ้น

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

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

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

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

ความเป็นโมดูลาร์เพียงอย่างเดียวไม่ได้ปรับปรุงปริมาณงาน

ความเป็นโมดูลจะเพิ่มต้นทุนการทำธุรกรรมให้กับผู้ใช้

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

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

• สภาพคล่องลดลง นำไปสู่การเลื่อนไหลของธุรกรรมที่สูงขึ้น

• ปริมาณการใช้ก๊าซโดยรวมที่มากขึ้น (ธุรกรรมข้ามสายโซ่ต้องมีธุรกรรมอย่างน้อยสองรายการในบัญชีแยกประเภทสินทรัพย์อย่างน้อยสองรายการ)

• เพิ่มการคำนวณบัญชีแยกประเภทข้ามสินทรัพย์สองเท่า (ซึ่งจะช่วยลดปริมาณงานรวมของระบบ): เมื่อราคาของ ETH-USDC เปลี่ยนแปลงใน Binance หรือ Coinbase โอกาสในการเก็งกำไรจะปรากฏในแต่ละกลุ่ม ETH-USDC ของบัญชีแยกประเภทสินทรัพย์ทั้งหมด (คุณสามารถจินตนาการได้อย่างง่ายดาย โลกที่ทุกครั้งที่ราคา ETH-USDC เคลื่อนไหวบน Binance หรือ Coinbase จะมีธุรกรรมมากกว่า 10 รายการในบัญชีแยกประเภทสินทรัพย์ต่างๆ การรักษาราคาให้สอดคล้องกันในสถานะที่กระจัดกระจายเป็นการใช้พื้นที่บล็อกที่ไม่มีประสิทธิภาพอย่างยิ่ง)

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

ข้อมูลหลักสำหรับ DeFi คือสถานะออนไลน์ (เช่น ใครเป็นเจ้าของสินทรัพย์) เมื่อทีมเปิดตัว appchains/rollups พวกเขาจะสร้างการกระจายตัวของสถานะซึ่งเป็นอันตรายต่อ DeFi อย่างมาก ไม่ว่าจะเป็นนักพัฒนาที่จัดการความซับซ้อนของแอป (บริดจ์ กระเป๋าเงิน เวลาแฝง MEV แบบข้ามสายโซ่ ฯลฯ) หรือผู้ใช้ ( การเลื่อนหลุด ความล่าช้าในการชำระบัญชี)

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

การเปิดตัวแอปจะไม่สร้างโอกาสในการสร้างรายได้ใหม่สำหรับนักพัฒนา

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

• การชำระบัญชี: หาก Compound หรือ Aave DAO ต้องการจับส่วนหนึ่งของ MEV ที่ไหลไปยังบอทการชำระบัญชี พวกเขาสามารถอัปเดตสัญญาที่เกี่ยวข้องเพื่อให้ค่าธรรมเนียมส่วนหนึ่งที่ไหลไปยังผู้ชำระบัญชีในปัจจุบันไปที่ DAO ของตนเอง ไม่มีห่วงโซ่ใหม่ /จำเป็นต้องมีการโรลอัพ

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

• การสร้าง NFT: การสร้าง NFT นั้นเต็มไปด้วยบอทแบบถลกหนัง สิ่งนี้สามารถบรรเทาลงได้อย่างง่ายดายโดยเพียงแค่เขียนโค้ดการกระจายผลกำไรที่ลดลง ตัวอย่างเช่น หากมีคนพยายามขาย NFT ของตนต่อภายในสองสัปดาห์หลังการผลิต รายได้ 100% จะถูกส่งกลับไปยังผู้ออกหรือ DAO เปอร์เซ็นต์นี้อาจเปลี่ยนแปลงเมื่อเวลาผ่านไป

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

การยกเลิกแอปพลิเคชันไม่สามารถแก้ไขความแออัดของแอปพลิเคชันข้ามได้

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

นี่เป็นปัญหาในอดีตซึ่งมีรากฐานมาจากลักษณะเธรดเดียวของ EVM ไม่ใช่เพราะ DA และการดำเนินการไม่ได้แยกจากกัน L2 ทั้งหมดชำระค่าธรรมเนียมให้กับ L1 และค่าธรรมเนียม L1 สามารถเพิ่มขึ้นได้ตลอดเวลา ในช่วงที่ Memecoin ได้รับความนิยมเมื่อต้นปีนี้ ค่าธรรมเนียมการทำธุรกรรมของ Arbitrum และ Optimism เกิน 10 ดอลลาร์ในช่วงสั้นๆ เมื่อเร็ว ๆ นี้ ค่าธรรมเนียมการมองโลกในแง่ดีก็เพิ่มขึ้นเช่นกันหลังจากการเปิดตัว Worldcoin

ทางออกเดียวที่จะจัดการกับค่าธรรมเนียมสูงสุดคือ: 1) เพิ่ม L1 DA ให้สูงสุด 2) ปรับแต่งตลาดค่าธรรมเนียมให้มากที่สุด:

หากทรัพยากรของ L1 ถูกจำกัด การใช้งานที่เพิ่มขึ้นอย่างฉับพลันใน L2 แต่ละตัวจะถูกส่งไปยัง L1 ซึ่งจะกำหนดต้นทุนที่สูงขึ้นสำหรับ L2 อื่นๆ ทั้งหมด ดังนั้น AppChain/Rollup จึงไม่สามารถต้านทาน Gas Spikes ได้

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

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

ด้วยการเปิดตัวหลายเชน นักพัฒนาไม่สามารถปลดล็อกประสิทธิภาพที่เพิ่มขึ้นจริงได้ เมื่อมีแอปพลิเคชันที่ขับเคลื่อนปริมาณธุรกรรม ต้นทุนของ L2 chain ทั้งหมดจะได้รับผลกระทบ

ความยืดหยุ่นถูกประเมินมากเกินไป

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

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

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

• คำสั่งจำกัดใน DEX เช่น dYdX และ Sei (คำสั่งจำกัดจำนวนมากจบลงด้วยการยกเลิก)

• ประสานงานและระบุโฟลว์คำสั่งซื้อขายตามเวลาจริงใน dFlow (dFlow เป็นโปรโตคอลที่อำนวยความสะดวกให้กับตลาดโฟลว์คำสั่งซื้อแบบกระจายอำนาจระหว่างผู้ดูแลสภาพคล่องและกระเป๋าเงิน)

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

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

จำเป็นต้องใช้ประโยชน์จากโครงสร้างพื้นฐานของ Threshold Signature Scheme (TSS) ตัวอย่างบางส่วนของสิ่งนี้ ได้แก่ Sommelier, Thorchain, Osmosis, Wormhole และ Web3 Auth

ยกเว้น Pyth และ Wormhole ตัวอย่างทั้งหมดที่ระบุไว้ข้างต้นสร้างขึ้นโดยใช้ Cosmos SDK และทำงานเป็นเครือข่ายแบบสแตนด์อโลน ข้อมูลนี้บ่งบอกถึงความสามารถในการนำไปใช้และความสามารถในการปรับขนาดของ Cosmos SDK สำหรับกรณีการใช้งานทั้งสามกรณี ได้แก่ ระบบสถานะด่วน การแก้ไขฉันทามติ และระบบ Threshold Signature Scheme (TSS)

อย่างไรก็ตาม รายการส่วนใหญ่ในกรณีการใช้งานสามกรณีข้างต้นไม่ใช่แอปพลิเคชัน แต่เป็นโครงสร้างพื้นฐาน

Python และ dFlow ไม่ใช่แอปพลิเคชัน แต่เป็นโครงสร้างพื้นฐาน Sommelier, Wormhole, Sei และ Web3 Auth ไม่ใช่แอปพลิเคชัน แต่เป็นโครงสร้างพื้นฐาน มีแอปพลิเคชันที่ต้องเผชิญหน้าผู้ใช้เพียงประเภทเดียวเท่านั้น: DEX (dYdX, Osmosis, Thorchain)

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

ประการแรก ตัวอย่างโครงสร้างพื้นฐานไม่ควรมีอยู่ในชุดรวมอัปเดตเนื่องจากสร้างข้อมูลมูลค่าต่ำมากเกินไป (เช่น สถานะฮอต และจุดรวมของสถานะฮอตคือข้อมูลไม่ได้ถูกส่งกลับไปยัง L1) หรือเนื่องจากตัวอย่างเหล่านี้ทำบางสิ่งบางอย่าง ที่จงใจเชื่อมโยงกับฟังก์ชันการทำงานที่เกี่ยวข้องกับการอัปเดตสถานะบัญชีแยกประเภท (เช่น กรณีการใช้งาน TSS ทั้งหมด)

ประการที่สอง แอปพลิเคชันประเภทเดียวที่ฉันเคยเห็นว่าจะได้ประโยชน์จากการเปลี่ยนแปลงการออกแบบระบบหลักคือ DEX เนื่องจาก DEX เต็มไปด้วย MEV และ Universal Chains ไม่สามารถจับคู่เวลาแฝงของ CEX ได้ ฉันทามติเป็นพื้นฐานของคุณภาพการดำเนินการธุรกรรมและ MEV ดังนั้นการเปลี่ยนแปลงตามฉันทามติจะนำโอกาสทางนวัตกรรมมากมายมาสู่ DEX โดยธรรมชาติ อย่างไรก็ตาม ตามที่กล่าวไว้ก่อนหน้าในบทความนี้ ข้อมูลหลักสำหรับสปอต DEX คือสินทรัพย์ที่มีการซื้อขาย DEX แข่งขันกันเพื่อสินทรัพย์และเพื่อผู้ออกสินทรัพย์ ภายใต้กรอบการทำงานนี้ ห่วงโซ่ DEX แบบสแตนด์อโลนไม่น่าจะประสบความสำเร็จ เนื่องจากการพิจารณาเบื้องต้นของผู้ออกสินทรัพย์เมื่อการออกสินทรัพย์ไม่เกี่ยวข้องกับ MEV ที่เกี่ยวข้องกับ DEX แต่เป็นฟังก์ชันการทำงานของสัญญาอัจฉริยะทั่วไป และการรวมฟังก์ชันนี้เข้ากับแอปพลิเคชันของนักพัฒนาที่เกี่ยวข้อง

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

ลองพิจารณาแอปพลิเคชัน L1 แบบบูรณาการทั่วไปที่มีอยู่ในปัจจุบัน รวมถึง: เกม, ระบบ DeSoc (เช่น Farcaster และ Lens), โปรโตคอล DePIN (เช่น Helium, Hivemapper, Render Network, DIMO และ Daylight), เสียง, การแลกเปลี่ยน NFT และอื่นๆ . สิ่งเหล่านี้ไม่ได้รับประโยชน์เป็นพิเศษจากความยืดหยุ่นที่ได้รับจากการแก้ไขฉันทามติ และบัญชีแยกประเภทสินทรัพย์ที่เกี่ยวข้องนั้นมีข้อกำหนดที่ค่อนข้างเรียบง่าย ชัดเจน และเหมือนกัน: ค่าธรรมเนียมต่ำ เวลาแฝงต่ำ การเข้าถึงสปอต DEX การเข้าถึง Stablecoin และการเข้าถึง ช่องคำสั่งเช่น CEX

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

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

Extended DA ไม่จำเป็นต้องจำนองใหม่

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

โดยคร่าวๆ ระบุว่าเนื่องจากการตั้งสมมุติฐานใหม่ (เช่น ผ่านระบบ เช่น EigenLayer) ระบบนิเวศของ crypto ทั้งหมดจึงสามารถตั้งสมมุติฐาน ETH ใหม่ได้ไม่จำกัดจำนวนครั้ง ทำให้สามารถเลเยอร์ DA ได้ไม่จำกัดจำนวน (เช่น EigenDA) และเลเยอร์การดำเนินการ ดังนั้นในขณะที่รับประกันมูลค่าเพิ่มของ ETH ความสามารถในการปรับขนาดก็ได้รับการแก้ไขจากทุกด้าน

แม้ว่าสภาพที่เป็นอยู่และอนาคตทางทฤษฎีจะมีความไม่แน่นอนอย่างมาก แต่เราถือว่าสมมติฐานการแบ่งชั้นทั้งหมดเป็นไปตามที่โฆษณาไว้

DA ปัจจุบันของ Ethereum อยู่ที่ประมาณ 83 KB/s ด้วยการเปิดตัว EIP-4844 ในปลายปีนี้ ความเร็วดังกล่าวอาจเพิ่มขึ้นเป็นสองเท่าเป็นประมาณ 166 KB/s EigenDA สามารถเพิ่มได้อีก 10 MB/s แต่ต้องมีชุดสมมติฐานด้านความปลอดภัยที่แตกต่างกัน (ไม่ใช่ ETH ทั้งหมดจะถูกตั้งสมมุติฐานใหม่ให้กับ EigenDA)

ในการเปรียบเทียบ ปัจจุบัน Solana ให้ DA ประมาณ 125 MB/s (32,000 ชิ้นต่อบล็อก, 1,280 ไบต์ต่อชิ้น, 2.5 บล็อกต่อวินาที) Solana มีประสิทธิภาพมากกว่า Ethereum และ EigenDA มาก นอกจากนี้ตามกฎของเนลสัน, DA ของ Solana จะขยายตามเวลา

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

สร้างขึ้นสำหรับนักพัฒนาแอปพลิเคชัน

หลังจากคิดมาหลายปี ฉันก็สรุปได้ว่าโมดูลาร์ไม่ควรเป็นเป้าหมายในตัวมันเอง

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

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