การพัฒนาหลายสายโซ่ของ Ethereum ไปอยู่ที่ไหน บางที Polkadot อาจให้คำตอบอ้างอิงแก่คุณได้
ข้อความต้นฉบับ: ตัวจัดลำดับที่ใช้ร่วมกันสำหรับเครือแอป Starknet และ Madara
ผู้เขียน : อปูร์ สาดานา
เรียบเรียงโดย: Odaily How about
เมื่อ L2 และเครือข่ายแอปพลิเคชันจำนวนมากขึ้นเรื่อยๆ อาศัย Ethereum เป็นชั้นการชำระบัญชี การทำงานร่วมกันระหว่างหลายเครือข่ายและระดับการกระจายอำนาจของแต่ละเครือข่ายจึงมีความสำคัญอย่างยิ่ง
บทความนี้กล่าวถึงแนวคิดของตัวจัดลำดับที่ใช้ร่วมกัน ซึ่งช่วยให้กลุ่มแอปพลิเคชันที่แตกต่างกันสามารถแชร์ชุดตัวตรวจสอบเพื่อให้เกิดการกระจายอำนาจ และจัดการลำดับธุรกรรมและการดำเนินการผ่านกลไกคำสั่งและกลไกสะสม
อย่างไรก็ตาม ซีเควนเซอร์ที่ใช้ร่วมกันและสถาปัตยกรรมการออกแบบหลายสายโซ่ของ Polkadot นั้นคล้ายกันมาก เทคโนโลยีสำเร็จรูปของ Polkadot สามารถนำไปใช้กับระบบนิเวศ Ethereum เพื่อปรับปรุงกระบวนการพัฒนาของหลายสายโซ่ของ Ethereum ได้หรือไม่
ข้อมูลต่อไปนี้รวบรวมโดย Odaily
จะเกิดอะไรขึ้นกับ 100 App Chains?
สมมติว่าเราอยู่ในอนาคตที่ขณะนี้มี Application Chains ที่แตกต่างกันกว่า 100 รายการบน Ethereum มาแก้ไขปัญหาที่เกิดขึ้นกันดีกว่า
การกระจายตัวแบบกระจายอำนาจ
แต่ละห่วงโซ่แอปพลิเคชันจำเป็นต้องแก้ไขปัญหาการกระจายอำนาจด้วยตัวมันเอง ตอนนี้ การกระจายอำนาจของห่วงโซ่แอปพลิเคชันไม่จำเป็นเท่ากับ L1 เนื่องจากเราพึ่งพา L1 เพื่อรับประกันความปลอดภัย อย่างไรก็ตาม เรายังจำเป็นต้องมีการกระจายอำนาจเพื่อให้แน่ใจว่ามีความอยู่รอด ต่อต้านการเซ็นเซอร์ และหลีกเลี่ยงข้อได้เปรียบผูกขาด (เช่น ค่าธรรมเนียมสูง) อย่างไรก็ตาม หากแต่ละสายโซ่แอปพลิเคชันใช้วิธีการของตัวเองในการแก้ปัญหาการกระจายอำนาจ สิ่งนี้จะนำไปสู่การแตกแฟรกเมนต์ของชุดเครื่องมือตรวจสอบความถูกต้อง แต่ละห่วงโซ่แอปพลิเคชันจะต้องพัฒนาแรงจูงใจทางเศรษฐกิจเพื่อดึงดูดผู้ตรวจสอบรายใหม่ นอกจากนี้ ผู้ตรวจสอบความถูกต้องยังต้องเลือกไคลเอนต์ที่พวกเขายินดีใช้งานอีกด้วย สิ่งนี้สร้างอุปสรรคใหญ่ในการเข้าสู่นักพัฒนาในการเปิดตัวเครือข่ายแอปพลิเคชันของตนเอง (เทียบกับการปรับใช้สัญญาอัจฉริยะซึ่งเป็นเพียงธุรกรรมเดียว)
ความสามารถในการประกอบ
ความสามารถในการรวมองค์ประกอบโดยทั่วไปหมายถึงการโต้ตอบระหว่างแอปพลิเคชัน บน Ethereum หรือ Starknet นี่หมายถึงการเรียกสัญญาอัจฉริยะอันอื่น และโปรโตคอลอื่นๆ จะจัดการทุกอย่างเอง อย่างไรก็ตาม ในห่วงโซ่แอปพลิเคชัน สิ่งนี้จะยากขึ้น กลุ่มแอปพลิเคชันที่แตกต่างกันมีบล็อกและกลไกที่เป็นเอกฉันท์ของตัวเอง ทุกครั้งที่คุณพยายามโต้ตอบกับ Application Chain อื่น คุณจะต้องตรวจสอบอัลกอริธึมฉันทามติและการรับประกันขั้นสุดท้ายอย่างรอบคอบ และตั้งค่า Cross-Chain Bridge ตามนั้น (ไม่ว่าจะโดยตรงไปยัง Chain หรือผ่าน L1) หากคุณต้องการโต้ตอบกับ App Chain 10 ตัวที่มีการออกแบบที่แตกต่างกัน คุณต้องทำสิ่งนี้ 10 ครั้ง
ประสบการณ์การพัฒนา
การแก้ปัญหาการกระจายอำนาจและการเชื่อมโยงไม่ใช่เรื่องง่าย หากทุกห่วงโซ่แอปพลิเคชันจำเป็นต้องแก้ไขปัญหาเหล่านี้ ก็จะกลายเป็นเรื่องยากสำหรับนักพัฒนาสัญญาอัจฉริยะทั่วไปในการสร้างห่วงโซ่แอปพลิเคชันของตนเอง นอกจากนี้ เนื่องจากแต่ละห่วงโซ่แอปพลิเคชันพยายามแก้ไขปัญหาเหล่านี้ด้วยวิธีของตัวเอง ในไม่ช้าเราจะเห็นห่วงโซ่ที่แตกต่างกันตามมาตรฐานที่แตกต่างกัน ซึ่งจะทำให้ฝ่ายโครงการใหม่เข้าร่วมระบบนิเวศได้ยากขึ้น
ตัวเรียงลำดับที่ใช้ร่วมกันสามารถแก้ปัญหานี้ได้
หากคุณติดตาม App Chain Space คุณอาจเคยได้ยินคำว่า ตัวจัดลำดับที่ใช้ร่วมกัน มันหมายถึงแนวคิดในการแบ่งปันชุดเครื่องมือตรวจสอบทั่วไปเพื่อแก้ไขปัญหาข้างต้น นี่คือวิธีการทำงาน
การกระจายอำนาจที่ใช้ร่วมกัน
แนวคิดหลักของซีเควนเซอร์ที่ใช้ร่วมกันคือ ไม่จำเป็นต้องมีชุดตรวจสอบที่แตกต่างกันสำหรับแต่ละสายโซ่แอปพลิเคชันหรือ L2 แต่มันเป็นไปได้ที่จะมีชุดเครื่องมือตรวจสอบความถูกต้องที่มีประสิทธิภาพและกระจายอำนาจมาก ซึ่งสั่งการบล็อกสำหรับเชนทั้งหมด
เนื่องจากปัจจุบันซีเควนเซอร์เกือบทุกตัวเป็นแบบรวมศูนย์ ซีเควนเซอร์จึงถือเป็นแอปพลิเคชันเดียวที่รวบรวมธุรกรรม เรียงลำดับ ดำเนินการ และเผยแพร่ผลลัพธ์ไปยัง L1 อย่างไรก็ตาม งานเหล่านี้สามารถแบ่งออกเป็นส่วนประกอบแบบโมดูลาร์ได้ เพื่อการอธิบาย ผมจะแบ่งออกเป็นสองส่วน
ระบบการเรียงลำดับ:รับผิดชอบในการจัดเรียงธุรกรรมตามลำดับเฉพาะ เมื่อกลไกการเรียงลำดับกำหนดลำดับนี้แล้ว จะต้องปฏิบัติตาม สิ่งนี้ถูกนำไปใช้โดยการยอมรับคำสั่งนี้ใน L1 และบังคับให้ผู้ตรวจสอบ L1 ตรวจสอบว่าธุรกรรมได้รับการดำเนินการในลำดับที่ต้องการ
เครื่องยนต์โรลอัพ:โดยพื้นฐานแล้วกลไก Rollup จะรวมทุกอย่างที่ Rollup ทำ: รวบรวมธุรกรรมจากผู้ใช้ ดำเนินธุรกรรม สร้างการพิสูจน์ และอัปเดตสถานะบน L1 ตามหลักการแล้ว สิ่งนี้สามารถแบ่งออกเป็นองค์ประกอบต่างๆ ได้มากขึ้น แต่เราจะหลีกเลี่ยงการทำเช่นนั้นในบทความนี้ ที่นี่ กลไกการเรียงลำดับคือตัวเรียงลำดับที่ใช้ร่วมกัน และกลไก Rollup โดยพื้นฐานแล้วคือตรรกะ Rollup ทั้งหมด
ดังนั้นวงจรชีวิตของธุรกรรมจึงเป็นดังนี้
ซีเควนเซอร์ที่ใช้ร่วมกันโดยทั่วไปจะเรียงลำดับธุรกรรมในการยกเลิกและส่งมอบให้กับ L1 ตัวเรียงลำดับที่ใช้ร่วมกันจะกระจายอำนาจชุดตัวเรียงลำดับที่ใช้ร่วมกัน ซึ่งหมายความว่าชุดรวมทั้งหมดที่เชื่อมต่อกับชุดตัวเรียงลำดับนี้จะมีการกระจายอำนาจ
ความสามารถในการประกอบ
ปัญหาสำคัญเกี่ยวกับความสามารถในการจัดองค์ประกอบคือการรู้ว่าเมื่อใดที่ธุรกรรมได้รับการสรุปใน Application Chain อื่นๆ และดำเนินการกับ Chain ตามลำดับ แต่ตัวเรียงลำดับที่ใช้ร่วมกันอนุญาตให้ Rollups ที่เขียนได้แบ่งปันบล็อกระหว่างกัน ดังนั้น หากการย้อนกลับของธุรกรรมเกิดขึ้นใน Rollup B บล็อกทั้งหมดจะถูกย้อนกลับ ซึ่งจะทำให้ธุรกรรมใน Rollup A ถูกย้อนกลับด้วย
ตอนนี้ฟังดูง่ายกว่าที่เป็นอยู่อย่างแน่นอน เมื่อต้องการทำเช่นนี้ การสื่อสารระหว่าง Rollups จะต้องมีประสิทธิภาพและปรับขนาดได้ ตัวจัดลำดับที่ใช้ร่วมกันจำเป็นต้องพัฒนามาตรฐานที่เหมาะสมสำหรับวิธีการสื่อสารของ Rollup ข้อความข้ามสายโซ่ควรมีลักษณะอย่างไร วิธีจัดการการอัพเกรด Rollup เป็นต้น แม้ว่าปัญหาเหล่านี้จะแก้ไขได้ แต่ก็ไม่ใช่เรื่องง่ายที่จะนำไปใช้
ประสบการณ์ของนักพัฒนา
แม้ว่าซีเควนเซอร์ที่ใช้ร่วมกันจะสรุปแง่มุมของการกระจายอำนาจ ทำให้การส่งข้อความข้ามเชนง่ายขึ้น แต่ก็ยังมีมาตรฐานบางอย่างที่แต่ละเชนต้องปฏิบัติตามเพื่อให้เข้ากันได้กับซีเควนเซอร์ที่ใช้ร่วมกัน ตัวอย่างเช่น ธุรกรรม Rollup ทั้งหมดจะต้องถูกแปลงเป็นรูปแบบทั่วไปที่ตัวจัดลำดับเข้าใจ ในทำนองเดียวกัน บล็อกของซีเควนเซอร์จำเป็นต้องได้รับการกรองเพื่อรับธุรกรรมที่เกี่ยวข้อง เพื่อแก้ไขปัญหานี้ฉันคิดว่าซีเควนเซอร์ที่ใช้ร่วมกันจะเปิดตัวเฟรมเวิร์ก Rollup หรือ SDK ที่จะสรุปโค้ดสำเร็จรูปและเปิดเผยเฉพาะส่วนตรรกะทางธุรกิจให้กับผู้พัฒนาห่วงโซ่แอปพลิเคชันเท่านั้น
ต่อไปนี้เป็นแผนผังของสายโซ่แอปพลิเคชันเมื่อใช้ซีเควนเซอร์ที่ใช้ร่วมกัน
multi-chain ของ Ethereum สามารถเรียนรู้จากสถาปัตยกรรมการออกแบบของ Polkadot ได้หรือไม่?
Polkadot กำลังทำงานเกี่ยวกับอนาคตแบบ multi-chain ก่อน Ethereum ที่จริงแล้วพวกเขาทำงานเกี่ยวกับเรื่องนี้มานานกว่า 5 ปีแล้ว หากคุณคุ้นเคยกับ Polkadot คุณอาจสังเกตเห็นว่าการออกแบบด้านบนได้สร้างสรรค์หลายสิ่งหลายอย่างที่ Polkadot ทำอยู่แล้ว
ห่วงโซ่รีเลย์ (การกระจายอำนาจที่ใช้ร่วมกัน)
ห่วงโซ่รีเลย์โดยพื้นฐานแล้วคือกลไกการเรียงลำดับ + L1 ในแผนภาพลำดับด้านบน หน้าที่ของห่วงโซ่รีเลย์ประกอบด้วย:
จัดเรียงธุรกรรมของ Parachains ทั้งหมด (Rollup) เพื่อตรวจสอบว่าธุรกรรมได้รับการดำเนินการอย่างถูกต้อง (ไม่ได้ใช้การตรวจสอบความรู้ที่ไม่มีศูนย์ แต่จะรันโค้ดการดำเนินการของ Rollup อีกครั้งเพื่อตรวจสอบความแตกต่างของสถานะ)
ดังที่คุณอาจทราบแล้วว่ารีเลย์เชนนั้นเป็นซีเควนเซอร์ที่ใช้ร่วมกันที่เรากล่าวถึงข้างต้น ความแตกต่างก็คือรีเลย์เชนยังต้องมีการดำเนินการตรวจสอบ และเราปล่อยให้สิ่งนี้เป็นหน้าที่ของ Ethereum
XCM และ XCMP
เราได้กล่าวไว้ในหัวข้อที่แล้วว่า หากแต่ละ chain กำหนดแนวทางของตัวเองในการทำงานร่วมกันกับ chain อื่นๆ ในไม่ช้า เราจะได้เห็นมาตรฐานและรูปแบบที่แตกต่างกันในทุก chain คุณต้องติดตามรูปแบบทั้งหมดที่โต้ตอบกับแต่ละเชน นอกจากนี้ คุณจะต้องตอบคำถามต่างๆ เช่น จะเกิดอะไรขึ้นหากเชนได้รับการอัพเกรด อย่างไรก็ตาม ปัญหาเหล่านี้สามารถแก้ไขได้ด้วยการแนะนำมาตรฐานที่ทุกเครือข่ายต้องปฏิบัติตาม
อย่างที่คุณอาจเดาได้ Polkadot ทำสิ่งนี้ไปแล้ว XCM เป็นรูปแบบข้อความและ XCMP เป็นโปรโตคอลข้อความที่เครือข่ายย่อยทั้งหมดสามารถใช้เพื่อสื่อสารระหว่างกัน
สารตั้งต้นและคิวมูลัส
Substrate เป็นเฟรมเวิร์กที่พัฒนาโดย Parity สำหรับการสร้างบล็อกเชน ในขณะที่พาราเชนทั้งหมดบน Polkadot ใช้ Substrate แต่จริงๆ แล้ว Substrate นั้นถูกสร้างขึ้นในลักษณะที่ไม่เชื่อเรื่องพระเจ้าแบบลูกโซ่ เฟรมเวิร์กสรุปแง่มุมทั่วไปทั้งหมดของบล็อกเชนและมุ่งเน้นไปที่ตรรกะของแอปพลิเคชัน ดังที่เราทราบ Madara สร้างขึ้นบน Substrate เช่นเดียวกับ Polkadot, Polygon Avail และโปรเจ็กต์อื่นๆ อีกมากมาย นอกจากนี้ Cumulus ยังเป็นมิดเดิลแวร์ที่อยู่ด้านบนของ Substrate ที่สามารถเชื่อมต่อ chain ของคุณกับ Polkadot ได้
ดังนั้น การดำเนินการเปรียบเทียบก่อนหน้านี้ต่อไป สารตั้งต้นและคิวมูลัสถือได้ว่าเป็นโซลูชันทางเลือกสำหรับเฟรมเวิร์ก Rollup ซึ่งอนุญาตให้สร้างสายโซ่ของแอปพลิเคชันและเชื่อมต่อแอปพลิเคชันเหล่านั้นกับซีเควนเซอร์ที่ใช้ร่วมกัน
ซีเควนเซอร์ที่ใช้ร่วมกัน → โซ่รีเลย์
ความสามารถในการประกอบ → XCM และ XCMP
เฟรมเวิร์ก/สแต็กแบบโรลอัพ → วัสดุพิมพ์และคิวมูลัส
ข้อมูลข้างต้นนั้นเป็นสำเนาคาร์บอนของ Polkadot ยกเว้นว่า Polkadot และ Parity มีทีมงานที่มีประสบการณ์และได้รับทุนสนับสนุนเป็นอย่างดี ซึ่งยังคงปรับปรุง Substrate และ Polkadot ต่อไป โดยเพิ่มคุณสมบัติเพิ่มเติมและปรับปรุงความสามารถในการปรับขนาด เทคโนโลยีนี้ได้รับการทดสอบภาคสนามมาหลายปีแล้วและมาพร้อมกับเครื่องมือการพัฒนามากมาย
กำลังปักหลัก Polkadot บน Ethereum หรือไม่?
ในขณะที่ Polkadot เริ่มสร้างอนาคตแบบ multi-chain ก่อน Ethereum แต่ก็ปฏิเสธไม่ได้ว่า ณ วันนี้ Ethereum เป็นบล็อกเชนที่มีการกระจายอำนาจมากที่สุด และเป็นที่ที่แอปพลิเคชันและสภาพคล่องส่วนใหญ่อาศัยอยู่ อย่างไรก็ตาม จะเกิดอะไรขึ้นหากมีวิธีที่จะนำเทคโนโลยี Polkadot ทั้งหมดมาสู่ระบบนิเวศของ Ethereum?
อันที่จริงเราได้เริ่มดำเนินการเรื่องนี้แล้ว และมาดาระก็เป็นตัวอย่าง Madara ใช้เฟรมเวิร์ก Substrate เพื่อให้ใครก็ตามสามารถสร้างโซลูชัน L2/L3 ที่ใช้ ZK ของตนเองบน Ethereum ได้ สิ่งต่อไปที่เราต้องการคือห่วงโซ่รีเลย์ Polkadot ในรูปแบบของซีเควนเซอร์ที่ใช้ร่วมกัน หากเราสามารถใช้ Polkadot Relay Chain ซ้ำได้ แต่ลบส่วนการตรวจสอบออก เนื่องจากลำดับของธุรกรรมได้รับการตรวจสอบผ่าน zk proofs บน L1 และลำดับของธุรกรรมจะถูกส่งไปยัง L1 โดยปรับโหนดและอัลกอริธึมฉันทามติให้เหมาะสมเพื่อรองรับ Tendermint/HotStuff เราสามารถทำได้ รับตัวเรียงลำดับที่ใช้ร่วมกันดังกล่าวข้างต้น
แน่นอนว่านี่พูดง่ายกว่าทำ อย่างไรก็ตาม ฉันคิดว่าเส้นทางนี้ใช้งานได้จริงมากกว่าการสร้างซีเควนเซอร์ มาตรฐาน และเฟรมเวิร์กขึ้นมาใหม่ตั้งแต่ต้น Polkadot ได้แก้ไขปัญหามากมายด้วยวิธีไม่เชื่อเรื่องพระเจ้าแบบลูกโซ่ซึ่งเราสามารถยืมมาใช้กับ Ethereum ได้ จากผลิตภัณฑ์ข้างเคียง เรายังได้รับ:
● ชุมชนนักพัฒนาที่กระตือรือร้นซึ่งยังคงสร้างและให้ความรู้แก่โลกเกี่ยวกับ Substrate
● ชุดเครื่องมือการพัฒนาที่กระตือรือร้นและชุมชนที่เข้มแข็ง
● Parachains ที่ใช้งานอยู่จำนวนมากยังมีตัวเลือกในการชำระเงินบน Ethereum หากต้องการทำเช่นนั้น (เมื่อเร็ว ๆ นี้เราเห็น Astar ทำสิ่งเดียวกันโดยใช้ Polygon CDK)
สรุปแล้ว
เป้าหมายหลักของฉันในการเขียนบทความนี้คือเพื่อจุดประกายการอภิปรายภายในระบบนิเวศที่กว้างขึ้นของ Starknet และ Ethereum ฉันคิดว่ารูปแบบการสั่งซื้อที่ใช้ร่วมกันจะมีบทบาทสำคัญในการกระจายอำนาจของ Starknet และการกระจายอำนาจของห่วงโซ่แอปพลิเคชันทั้งหมดที่พิจารณาสร้างทับกัน ตราบใดที่เรามีความมั่นใจในอาร์กิวเมนต์ AppChain และความสามารถในการปรับขนาดของ ZK การวิเคราะห์โมเดลการสั่งซื้อที่ใช้ร่วมกันอย่างละเอียดก็เป็นสิ่งที่หลีกเลี่ยงไม่ได้ นอกจากนี้ เมื่อ Madara ก้าวไปสู่การผลิตและ Starknet ได้เริ่มทำงานเกี่ยวกับการกระจายอำนาจ ฉันคิดว่าตอนนี้เป็นเวลาที่จะแก้ไขปัญหานี้ ดังนั้นฉันจึงขอคำติชม/ข้อเสนอแนะในหัวข้อนี้จากทุกคนที่อ่านโพสต์นี้ รอคอยที่จะอ่านความคิดของคุณ
