### การแนะนำเมื่อเราดูวิสัยทัศน์และแผนงานของโซลูชันการยกเลิกต่างๆ เราจะพบว่า การยกเลิกเกือบทั้งหมดมีเป้าหมายสูงสุด หากเป้าหมายนี้รวมเป็นประโยคเดียว: สร้างกองเทคโนโลยี จัดหาให้กับชุมชน แก้ปัญหา การขยายตัวของ บล็อกเชนและท้ายที่สุดคือการกระจายอำนาจของกองเทคโนโลยีของการดำเนินงานและการกำกับดูแล สิ่งนี้นำไปสู่คำว่าการกระจายอำนาจแบบกระจายอำนาจแล้วการกระจายอำนาจคืออะไรกันแน่? การแบ่งงานระหว่างส่วนต่างๆ ของระบบ Rollup คืออะไร? การกระจายอำนาจหมายถึงการเพิ่มผู้เข้าร่วมการทำงานของระบบให้ได้สูงสุดหรือไม่? ตัวคัดแยกแบบรวมศูนย์จะมีผลอย่างไร ผู้สั่งซื้อที่ใช้ร่วมกันและฉันทามติในท้องถิ่น L2 ควรได้รับการออกแบบอย่างไร อะไรคือหน้าที่ของตัวพิสูจน์เอกลักษณ์ใน ZK-Rollup? เครือข่ายผู้พิสูจน์การกระจายอำนาจแบบเปิดจะมีลักษณะอย่างไร ทำไมเราต้องการการเร่งด้วยฮาร์ดแวร์ zk วิธีแก้ไขปัญหาความพร้อมใช้งานของข้อมูลคืออะไร ....มีการพูดคุยไม่รู้จบเกี่ยวกับการยกเลิกแบบกระจายอำนาจในชุมชน ดังนั้น ECN จึงจัดทำชุดสัมภาษณ์พอดคาสต์ในหัวข้อ "การยกเลิกแบบกระจายอำนาจ" และเชิญผู้ก่อตั้งและนักวิจัยที่โดดเด่นในสาขานี้มาพูดคุยเกี่ยวกับความเข้าใจเกี่ยวกับการยกเลิกแบบกระจายอำนาจ ความเข้าใจเมื่อสภาพคล่องหลั่งไหลเข้าสู่แพลตฟอร์ม Layer 2 มากขึ้นเรื่อยๆ ผู้ให้บริการ Rollup จำนวนมากขึ้นเรื่อยๆ ก็ปรากฏตัวขึ้น ไม่เพียงแต่โซลูชัน Rollup ที่ใช้งานทั่วไป, Rollup Chain เฉพาะแอปพลิเคชันเท่านั้น แต่ยังรวมถึงแพลตฟอร์ม Rollup-as-a-Service ด้วย ดังนั้น ผู้คนจำนวนมากขึ้นจึงกังวลว่า "ซีเควนเซอร์" บทบาทที่สำคัญมากในการโรลอัพเกือบทั้งหมดยังคงรวมศูนย์อยู่ อะไรคือความเสี่ยงของตัวคัดแยกแบบรวมศูนย์? ตัวเรียงลำดับแบบกระจายอำนาจเป็นงานด่วนหรือไม่?**ในตอนที่ 2 เราได้เชิญ Yaoqi Jia ผู้ก่อตั้ง AltLayer Network, Toghrul Maharramov นักวิจัยของ Scroll และ Abdelhamid Bakhta หัวหน้าทีมสำรวจของ Starknet เพื่อทำการอภิปรายแบบโต๊ะกลมในหัวข้อของตัวเรียงลำดับแบบกระจายอำนาจ เพื่อให้ผู้ชมและผู้อ่าน สามารถเข้าใจความคืบหน้าและปัญหาบางอย่างในปัจจุบันของตัวเรียงลำดับแบบกระจายอำนาจ ****แขกรับเชิญในฉบับนี้:*** Yaoqi Jia ผู้ก่อตั้ง AltLayer Network, twitter @jiayaoqi* เลื่อนนักวิจัย Toghrul Maharramov, twitter @toghrulmaharram* หัวหน้าทีมสำรวจ Starknet Abdelhamid Bakhta, twitter @dimahledba**อดีต**ปัญหาที่ 1: วิธีการกระจายอำนาจ Rollup?* นักวิจัยอนุญาโตตุลาการ Patrick McCorry**ดูตัวอย่าง**ปัญหาที่ 3: Prover network และการเร่งด้วยฮาร์ดแวร์ zk* Ye Zhang ผู้ร่วมก่อตั้ง Scroll* Leo Fan ผู้ร่วมก่อตั้ง Cysicประเด็นที่ 4: ความพร้อมใช้งานของข้อมูลและพื้นที่จัดเก็บแบบกระจายอำนาจ* Qi Zhou ผู้ก่อตั้ง EthStorage**ฟัง**คลิกเพื่อสมัครรับข้อมูลพอดแคสต์เพื่อเรียนรู้เพิ่มเติม:ยูทูบ：พิภพเล็ก:**ประทับเวลา**- 00:49 เหยาฉีแนะนำตัวเอง- 01:37 น. อับเดลฮามิดแนะนำตัวเอง- 02:50 Toghrul แนะนำตัวเอง- 04:03 บทบาทของตัวเรียงลำดับในการยกเลิก- 08:37 ผู้สั่งซื้อแบบกระจายอำนาจ: การปรับปรุงประสบการณ์ผู้ใช้และการจัดการปัญหาความสดและการเซ็นเซอร์- 19:43 Starknet จะกระจายอำนาจไปยังตัวเรียงลำดับอย่างไร- 22:59 Scroll จะกระจายอำนาจตัวเรียงลำดับอย่างไร- 26:34 ความแตกต่างระหว่างฉันทามติ L2 ในบริบทของ Optimistic rollup และ zkRollup- 32:28 zkRollup กระจายอำนาจตัวเรียงลำดับและจำเป็นต้องพิจารณาตัวพิสูจน์ด้วย- 36:01 ค่าสะสมขึ้นอยู่กับอะไร- 40:53 ข้อเสียของซีเควนเซอร์ที่ใช้ร่วมกันและการยกเลิกตาม และสถานการณ์การใช้งาน- 49:02 ผู้สั่งซื้อแบบกระจายอำนาจจะมีผลอย่างไรต่อ MEV?### การแนะนำแขก**เหยาฉี**ฉันเป็นผู้ก่อตั้ง AltLayer AltLayer กำลังสร้างแพลตฟอร์ม "Rollup as a Service" ซึ่งนักพัฒนาเพียงคลิกปุ่มบางปุ่มและกำหนดค่าพารามิเตอร์ เมื่อใช้ Launchpad หรือแผงควบคุมของเรา พวกเขาสามารถเปิดใช้การยกเลิกเฉพาะแอปพลิเคชันได้อย่างรวดเร็วภายในไม่กี่นาที นั่นคือสิ่งที่เรากำลังพยายามทำอยู่ตอนนี้ เพื่อให้นักพัฒนามีสภาพแวดล้อมการดำเนินการและฟังก์ชันการทำงานทั่วไป เรายังมีซีเควนเซอร์หลายตัว ระบบเครื่องเสมือนหลายเครื่อง และระบบพิสูจน์ต่างๆ ให้นักพัฒนาเลือกใช้**อับเดลฮามิด**ฉันทำงานที่ Starkware และเป็นหัวหน้าทีมสำรวจ เป้าหมายของกลุ่มนี้คือการเปิดตัวโครงการโอเพ่นซอร์สที่มีลักษณะเหมือนการวิจัย แต่เน้นด้านวิศวกรรม เป้าหมายของเราคือการทำงานในโครงการโอเพ่นซอร์สโดยความร่วมมืออย่างใกล้ชิดกับชุมชนและผู้คนจากระบบนิเวศอื่นๆ หนึ่งในโครงการดังกล่าวคือ Madara ซึ่งเป็นตัวคัดแยกของ Starknet ไม่เพียงเป็นตัวเลือกสำหรับเครือข่ายสาธารณะของ Starknet เท่านั้น แต่ยังเป็นซีเควนเซอร์สำหรับห่วงโซ่แอปพลิเคชัน Starknet และ Layer3 สิ่งนี้ยังเกี่ยวข้องกับสิ่งที่แขกรับเชิญคนก่อนกล่าวไว้ เรากำลังคิดเกี่ยวกับการให้บริการการยกเลิกเป็นฟังก์ชันบริการ ผู้คนสามารถเปิดตัวห่วงโซ่แอปพลิเคชัน Starknet และเลือกโซลูชันความพร้อมใช้งานของข้อมูลที่แตกต่างกันในลักษณะที่ค่อนข้างเป็นโมดูล ก่อนหน้านั้นฉันทำงานเป็นนักพัฒนาหลักของ Ethereum เป็นเวลาสี่ปี โดยรับผิดชอบงาน EIP-1559 เป็นหลัก**ทางเลือก**ฉันเป็นนักวิจัยที่ Scroll และความรับผิดชอบหลักของฉันที่ Scroll คือการออกแบบโปรโตคอล การออกแบบบริดจ์ การกระจายอำนาจ แรงจูงใจ อะไรทำนองนั้น ดังนั้นเมื่อฉันไม่ได้ทวีต เวลาส่วนใหญ่ฉันแค่ทำงานเกี่ยวกับวิธีกระจายอำนาจโปรโตคอลหรือผู้สั่งการ ผู้พิสูจน์ อะไรทำนองนั้น เช่นเดียวกับ Starkware สิ่งหนึ่งที่เรากำลังดำเนินการคือ SDK แบบโรลอัป ดังนั้น คุณสามารถออกการยกเลิกตาม Scroll และใช้ตัวเลือกความพร้อมใช้งานของข้อมูลแบบโมดูลาร์ได้ และอื่นๆ เรายังคงพิจารณาตัวเลือกที่การยกเลิกตาม Scroll SDK สามารถใช้ตัวเรียงลำดับของ Scroll เพื่อช่วยให้บรรลุการกระจายอำนาจโดยไม่ต้องให้การยกเลิกแต่ละครั้งต้องจัดการการกระจายอำนาจด้วยตัวเอง แน่นอนว่าตอนนี้ยังไม่ได้สรุปแผน อย่างไรก็ตาม นี่เป็นแนวทางที่เรากำลังดำเนินการอยู่### ส่วนสัมภาษณ์**หัวข้อที่หนึ่ง**อธิบายตัวเรียงลำดับของการยกเลิก?**อับเดลฮามิด**ตัวเรียงลำดับเป็นองค์ประกอบที่สำคัญมากในสถาปัตยกรรมเลเยอร์ 2 ส่วนประกอบนี้รับธุรกรรมจากผู้ใช้ จากนั้นทำแพ็คเกจและรวมกลุ่มเป็นบล็อก ดำเนินการธุรกรรม และอื่น ๆ มันสำคัญมากเพราะนี่คือองค์ประกอบที่รับผิดชอบในการสร้างบล็อก เนื่องจากเลเยอร์ 2 ก็เป็นบล็อกเชนที่มีการบล็อกธุรกรรมด้วย ผู้สั่งซื้อสร้างบล็อกเหล่านี้และผู้พิสูจน์รับรองบล็อกเหล่านี้**เหยาฉี**ดังที่ Abdel กล่าวไว้ ผู้สั่งซื้อคือการรวมกันของหลายฟังก์ชันในบล็อกเชน ดังนั้นเราจึงอาจให้ความรับผิดชอบแก่ผู้สั่งซื้อมากเกินไปเมื่อเทียบกับบล็อกเชนสาธารณะทั่วไป ก่อนอื่นต้องรวบรวมธุรกรรมทั้งหมดจากผู้ใช้ จากนั้นจึงจัดเรียงธุรกรรมเหล่านั้นตามราคาน้ำมันหรือตามลำดับก่อนหลัง หลังจากนั้น ซีเควนเซอร์จำเป็นต้องดำเนินการธุรกรรมเหล่านี้ เช่นเดียวกับตอนนี้ Layer2 บางตัวใช้ EVM (Starware มีเครื่องเสมือนที่แตกต่างกัน) แต่โดยพื้นฐานแล้วซีเควนเซอร์จำเป็นต้องใช้เครื่องเสมือนเฉพาะเพื่อดำเนินการธุรกรรมและสร้างสถานะ จากนั้นธุรกรรมจะเข้าสู่ขั้นตอนการยืนยันล่วงหน้า ซึ่งหมายความว่าหากคุณเห็นเวลายืนยันหนึ่งหรือสองวินาที หรือแม้แต่เสี้ยววินาที ก็จะเป็นสถานะการยืนยันล่วงหน้าที่เสร็จสมบูรณ์โดยซีเควนเซอร์ จากนั้น สำหรับผู้คัดแยกส่วนใหญ่ พวกเขาจำเป็นต้องอัปโหลดหรือเผยแพร่จุดตรวจหรือสถานะแฮชเป็น L1 นี่คือการยืนยันที่ระดับ L1 ซึ่งเราเรียกว่าความพร้อมใช้งานของข้อมูล ดังนั้นตัวเรียงลำดับจึงมีบทบาทมากมายในระบบการยกเลิก แต่โดยทั่วไปแล้ว ฉันคิดว่ามันเป็นองค์ประกอบที่สำคัญที่สุดของระบบการยกเลิก** หัวข้อ 2 **เหตุใดตัวเรียงลำดับแบบกระจายอำนาจจึงมีความสำคัญ ถ้าเราใช้ตัวเรียงลำดับแบบรวมศูนย์ อันตรายที่ซ่อนอยู่ต่อผู้ใช้และระบบคืออะไร?**ทางเลือก**ก่อนอื่น เราต้องรู้ว่ายกเว้น Fuel V1 ในขั้นตอนปัจจุบัน จะไม่มีการสั่งสมจริง เนื่องจากรุ่นอื่นๆ ยังมีวงล้อฝึกหัดอยู่อย่างไรก็ตาม เราสามารถพูดได้ว่าเมื่อมันถูกจัดประเภทเป็นการยกเลิก หมายความว่ามีการลบ multi-sig ออกไป และอื่นๆ จากนั้นปัญหาการกระจายอำนาจของตัวเรียงลำดับจะกลายเป็นปัญหาประสบการณ์ของผู้ใช้ ไม่ใช่ปัญหาด้านความปลอดภัย ดังนั้นเมื่อผู้คนพูดถึง เช่น การกระจายอำนาจ L1 ปัญหาจะแตกต่างไปจากเดิมอย่างสิ้นเชิง เนื่องจาก L1 ต้องรับประกันการสั่งซื้อและลูกค้ารายย่อย ดังนั้นหากไคลเอ็นต์แบบไลท์ต้องการตรวจสอบว่าสถานะถูกต้อง ไคลเอ็นต์จะต้องเชื่อถือตัวตรวจสอบ L1 สำหรับการยกเลิก นี่ไม่ใช่กรณี เนื่องจากตัวเรียงลำดับจัดเตรียมการเรียงลำดับชั่วคราวเท่านั้น ซึ่ง L1 จะสรุปผลให้ และเนื่องจากการรับประกันว่าการยกเลิกการเซ็นเซอร์จะต้านทานการเซ็นเซอร์ เราจึงไม่จำเป็นต้องมีการกระจายอำนาจเพื่อทำให้สิ่งนี้เกิดขึ้นดังนั้นจึงมีเหตุผลหลายประการที่คุณต้องการตัวเรียงลำดับแบบกระจายอำนาจ ประการแรก หากกล่าวว่าการสรุปผล L1 ช้า (อาจเป็นเพราะการพิสูจน์ความถูกต้องที่คุณส่งมานั้นช้าเกินไป หรือเนื่องจากกลไกระยะเวลาท้าทายของการพิสูจน์การฉ้อโกงโดยรวมในแง่ดี) คุณต้องพึ่งพาบางสิ่งเพื่อให้ได้รับการยืนยันการทำธุรกรรมอย่างรวดเร็ว ในขั้นตอนของการยืนยันอย่างรวดเร็วนี้ แม้ว่าคุณจะวางใจได้ว่า Starkware หรือ Scroll จะไม่หลอกลวงคุณ แต่สิ่งเหล่านี้บ่งชี้ว่าหลังจากบล็อกได้รับการยืนยันแล้ว จะไม่มีการจัดระเบียบใหม่ นี่คือสมมติฐานของความไว้วางใจ และการกระจายอำนาจสามารถเพิ่มการรับประกันทางเศรษฐกิจ และอื่นๆแต่ตามนี้ การยกเลิกยังไม่มีการรับประกันการสิ้นสุดตามเวลาจริง โดยพื้นฐานแล้ว คุณสามารถบังคับให้ทำแพ็กเกจธุรกรรมผ่าน L1 ได้ แต่ต้องใช้เวลาหลายชั่วโมงในการแพ็กเกจธุรกรรมนั้น ตัวอย่างเช่น หากมี oracle ที่รับผิดชอบในการอัปเดตและเวลาผันผวน โดยทั่วไปแล้วหาก oracle ได้รับการอัปเดตเป็นเวลาหนึ่งชั่วโมงขึ้นไป แอปพลิเคชันในการยกเลิกจะไม่สามารถใช้งานได้ โดยพื้นฐานแล้ว การกระจายอำนาจช่วยให้เราสามารถรับประกันการต่อต้านการเซ็นเซอร์ตามเวลาจริงที่แข็งแกร่งยิ่งขึ้น เพราะจากนั้นฝ่ายตรงข้ามจะต้องประนีประนอม ไม่ใช่แค่หน่วยงานเดียวหรือไม่กี่หน่วยงาน แต่รวมถึงเครือข่ายผู้สั่งซื้อทั้งหมดด้วยสำหรับเราแล้ว การกระจายอำนาจเป็นวิธีแก้ปัญหามากกว่าในการปรับปรุงประสบการณ์ผู้ใช้หรือแก้ไขกรณีมุมของการอัปเดต oracle และอื่นๆ แทนที่จะให้การรับประกันความปลอดภัยขั้นพื้นฐาน L1 ทำสิ่งนี้**อับเดลฮามิด**ใช่ คำถามเกี่ยวกับตัวเรียงลำดับแบบกระจายอำนาจที่คุณกล่าวถึงนั้นไม่เหมือนกับ L1 แบบกระจายอำนาจทุกประการ ซึ่งฉันคิดว่าสำคัญมาก เนื่องจากเมื่อเราเห็น L1 บางคนวิจารณ์ตัวคัดแยกจากส่วนกลาง พวกเขาไม่ได้พิจารณาถึงการแลกเปลี่ยนที่ตัวคัดแยกส่วนกลางทำอย่างเหมาะสมบนพื้นฐานนี้ ฉันต้องการเพิ่มบางสิ่งที่เกี่ยวข้องกับประสบการณ์ของผู้ใช้ ที่เกี่ยวข้องกับกิจกรรม เนื่องจากเมื่อคุณมีเครื่องคัดแยกเพียงเครื่องเดียว คุณจะมีความเสี่ยงสูงที่เครื่องคัดแยกจะขัดข้อง ดังนั้น ผู้สั่งซื้อแบบกระจายอำนาจจึงเพิ่มความยืดหยุ่นและความมีชีวิตชีวาบนเครือข่าย แต่ถึงแม้จะอยู่ในบริบทแบบรวมศูนย์ เราก็มีความปลอดภัยที่ดีในเรื่องความปลอดภัย เนื่องจากเมื่อคุณสามารถบังคับธุรกรรมแพ็คเกจผ่าน L1 ได้ ความแตกต่างระหว่างสองสิ่งนี้จะเป็นเพียงไทม์ไลน์เท่านั้น และการมีตัวเรียงลำดับแบบกระจายอำนาจช่วยให้คุณมีการรับประกันการต่อต้านการเซ็นเซอร์อย่างรวดเร็ว ดังที่ Toghrul กล่าวถึง ดังนั้น ฉันแค่อยากเพิ่มเติมว่า การมีเครือข่ายผู้สั่งซื้อแบบกระจายอำนาจเป็นสิ่งสำคัญเช่นกันสำหรับความมีชีวิตชีวา**เหยาฉี**ฉันต้องการเพิ่มบางอย่าง กิจกรรมอาจเป็นสิ่งสำคัญที่สุดที่เราต้องพิจารณาในขั้นตอนนี้ กรณีล่าสุดของแอร์ดรอปบน L2 ที่ได้รับความนิยมสูงสุด เช่น Optimism และ Arbitrum หยุดทำงานไปช่วงหนึ่ง ดังนั้น ฉันคิดว่าสิ่งที่เราต้องแก้ไขคือวิธีจัดการกับคำขอธุรกรรมหลายพันรายการต่อวินาทีเมื่อเรามีตัวเรียงลำดับเพียงตัวเดียว แม้ว่าในทางทฤษฎีแล้ว หากคุณมีเพียงโหนดเดียว มันก็ไม่สามารถจัดการกับคำขอจำนวนมากในเวลาเดียวกันได้ ดังนั้น เกี่ยวกับความมีชีวิตชีวา เราต้องการผู้คัดแยกจำนวนมากอย่างแน่นอน ความล้มเหลวเพียงจุดเดียวเป็นอุปสรรคอย่างแท้จริง ไม่ใช่แค่สำหรับ Web3 แม้แต่ Web2 ก็เป็นปัญหาใหญ่นอกจากนั้น ยังมีปัญหาของการเซ็นเซอร์ หากเรามีผู้ประสานงานเพียงคนเดียว แม้ว่าเราจะเห็นว่าทีมสามารถดำเนินการได้ แต่คุณยังคงต้องพิสูจน์ว่าทีมจะไม่ตรวจสอบธุรกรรมจริงๆ บางครั้งก็เป็นไปได้และมีความสามารถสำหรับบุคคลที่ไม่ประสงค์ดีที่จะขึ้นบัญชีดำธุรกรรมบางอย่าง นั่นคือระบบออร์เดอร์แบบกระจายอำนาจ พวกเขายังสามารถลองส่งธุรกรรมผ่านออร์เดอร์อื่นๆ นั่นเป็นเหตุผลที่เราได้รับคำวิจารณ์มากมายเกี่ยวกับผู้คัดแยกเดี่ยวเมื่อเร็ว ๆ นี้นอกจากนั้นยังมีปัญหาอื่น ๆ เช่น MEV และการวิ่งเร็ว ในระบบที่มีตัวเรียงลำดับแบบรวมศูนย์ โดยเฉพาะอย่างยิ่งสำหรับโปรโตคอล DeFi พวกเขาอาจตรวจสอบ mempool ได้อย่างง่ายดาย อาจไม่ได้อยู่ในรูปแบบของผู้นำหน้า แต่พวกเขามีโอกาสที่ดีกว่าในการกลั่นกรองการค้าและอนุญาโตตุลาการปัญหาเหล่านี้มากมายด้วยเหตุผลหลายประการ แม้ว่าเราจะเห็นว่า L2 แตกต่างจาก L1 มากก็ตาม แต่ท้ายที่สุดแล้ว เรายังจำเป็นต้องทำให้การกระจายอำนาจเป็นไปได้มากที่สุด ดังนั้นเราจึงต้องเผชิญกับปัญหาที่คล้ายกันกับบล็อกเชนสาธารณะหรือ L1**อับเดลฮามิด**ใช่ ฉันยอมรับว่าตัวเรียงลำดับแบบกระจายศูนย์มีความสำคัญ แต่ฉันก็อยากจะบอกว่า อย่างที่เราทุกคนทราบกันดีว่า นี่ไม่ใช่คำถามที่ง่ายนอกจากนี้ **เนื่องจาก Rollups มีสถาปัตยกรรมเฉพาะที่มีหลายเอนทิตี มีผู้สั่งซื้อรายเดียวที่เรากำลังพูดถึง แต่ก็มีผู้พิสูจน์ด้วย และเราจำเป็นต้องกระจายอำนาจทั้งสองอย่าง **จะมีการแลกเปลี่ยนและความยากลำบากในการทำธุรกรรมราคาเนื่องจากปัจจัยที่แตกต่างกันที่จำเป็นในการเรียกใช้เครือข่าย ดังนั้นคุณกำหนดราคาข้อตกลงอย่างไร? เครื่องคัดแยกและเครื่องพิสูจน์มีข้อกำหนดด้านฮาร์ดแวร์ที่แตกต่างกัน เครื่องพิสูจน์ต้องการเครื่องที่ทรงพลังเป็นพิเศษ และอื่นๆ ดังนั้น การทำธุรกรรมการกำหนดราคาในโลกที่มีการกระจายอำนาจจึงเป็นปัญหาที่ยากมากเช่นกัน ซึ่งเป็นสาเหตุที่เราต้องใช้เวลาในการก้าวไปข้างหน้าอย่างช้าๆดังนั้นเราทุกคนจะต้องเผชิญกับการแลกเปลี่ยนดังกล่าว หากเราต้องการ Decentralize อย่างรวดเร็ว เราอาจต้องใช้วงล้อฝึกฝนและค่อยๆ Decentralize เพราะถ้าเราต้องการสถาปัตยกรรมที่สมบูรณ์แบบโดยตรงจะใช้เวลาหลายปี ดังนั้นฉันคิดว่าเราจะใช้วิธีปฏิบัติและพยายามกระจายอำนาจอย่างค่อยเป็นค่อยไป อย่างน้อยนั่นคือแผนปัจจุบันของเรา เช่น อาจเริ่มต้นด้วยกลไกฉันทามติง่ายๆ ของ BFT แล้วเพิ่มกลไกฉันทามติอื่นในระยะสั้นหรืออย่างอื่น ฉันแค่อยากจะบอกว่า มันไม่ใช่คำถามที่ง่ายเลย เนื่องจากเห็นได้ชัดว่ามีการแลกเปลี่ยนระหว่างความเร็วในการพัฒนาและความเหมาะสมของสถาปัตยกรรมกับสภาพแวดล้อมแบบกระจายอำนาจ**หัวข้อที่ 3**จะกระจายอำนาจไปยังตัวเรียงลำดับได้อย่างไร?**อับเดลฮามิด**มีฟีเจอร์มากมายที่เราต้องการกระจายอำนาจ และทั้งหมดมีการแลกเปลี่ยนที่แตกต่างกันตัวอย่างเช่น เมื่อกระจายอำนาจ คุณต้องการแนะนำกลไกฉันทามติบางประเภท อย่างไรก็ตามในกลไกฉันทามติมีหลายส่วน วิธีแรกคือการเลือกผู้นำ นั่นคือการเลือกว่าใครจะสร้างบล็อก ใครจะเป็นผู้สั่งรับผิดชอบในการสร้างบล็อกในช่องที่กำหนดหรือภายในเวลาที่กำหนด **สิ่งที่ทีม Starknet วางแผนที่จะทำคือการใช้เลเยอร์ 1 ให้ได้มากที่สุด กล่าวคือ ในอัลกอริธึมการเลือกผู้นำของเรา เราต้องการเดิมพันในเลเยอร์ 1 ตัวอย่างเช่น เรามีโทเค็น และคำมั่นสัญญาจะเกิดขึ้นในสัญญาอัจฉริยะของเลเยอร์ 1 Ethereum ซึ่งใช้เพื่อกำหนดกลไกการเลือกผู้นำ **นั่นหมายความว่าเราจำเป็นต้องมีการโต้ตอบโดยที่ผู้สั่งซื้อ L2 จะสอบถาม Ethereum smart contract เพื่อทราบว่าใครจะเป็นผู้นำคนต่อไปหรืออะไรทำนองนั้น เห็นได้ชัดว่าจำเป็นต้องมีการสุ่มบางอย่างและสิ่งอื่น ๆ จึงไม่ใช่คำถามง่ายๆ แต่นั่นเป็นส่วนแรก จากนั้นคุณต้องมีกลไกสำหรับฉันทามติ มีหลายตัวเลือก: กลไกลูกโซ่ที่ยาวที่สุดหรือ BFT หรือลูกผสมของทั้งสองอย่าง เช่นเดียวกับ Ethereum มันมี LMG Ghost และ Casper FFG สำหรับขั้นสุดท้ายดังนั้น เราอาจใช้แนวทางปฏิบัติและเริ่มด้วย BFT ก่อน ทำไม เมื่อเลเยอร์ 2 พิจารณาการกระจายอำนาจ เป้าหมายของเราคือไม่ต้องมีตัวเรียงลำดับขนาดใหญ่เช่นเลเยอร์ 1 ตัวอย่างเช่น บน Ethereum เป้าหมายคือการมีผู้ตรวจสอบหลายล้านคนเข้าร่วม ในกรณีนี้ คุณไม่สามารถใช้กลไก BFT ได้ เพราะมันจะมีประสิทธิภาพที่แย่มาก และจะทำให้เกิดปัญหาใหญ่ตามมา ตัวอย่างเช่น หากมีปัญหาในเครือข่าย Bitcoin หากเป็นกลไก BFT ห่วงโซ่จะหยุดทำงานโดยสิ้นเชิง แต่นี่ไม่ใช่กรณี เครือข่าย Bitcoin ยังคงสร้างบล็อกต่อไป มีเพียงกลไกขั้นสุดท้ายเท่านั้นที่ถูกโจมตีแต่ในเลเยอร์ 2 หากเป้าหมายคือเครื่องคัดแยกไม่กี่ร้อยถึง 1,000 เครื่อง อาจเป็นการดีที่จะเริ่มต้นด้วยกลไก BFT ดังนั้นเราจึงมีกลไกการเลือกผู้นำ แล้วก็ฉันทามติ แล้วก็มีอีกสองส่วน แต่ฉันจะปล่อยให้แขกคนอื่นๆ เพิ่มต่อไป แต่อีกสองส่วนคือการอัปเดตสถานะและการสร้างหลักฐาน**ทางเลือก**ประการแรก ใน L2 การกระจายอำนาจเป็นปัญหาหลายแง่มุมตามที่ Abdel อธิบายไว้ โดยเฉพาะอย่างยิ่งใน zkRollup เนื่องจากมีผู้พิสูจน์และผู้สั่ง คุณต้องประสานงานระหว่างพวกเขา คุณต้องกระจายอำนาจทั้งคู่ ปัญหานี้แตกต่างจาก L1 อย่างสิ้นเชิงข้อแตกต่างอีกประการหนึ่งคือใน L2 การออกแบบทั้งหมดของคุณคือการโน้มน้าวใจบริดจ์พื้นฐานว่าฉันทามตินั้นถูกต้อง ไม่ใช่เพื่อโน้มน้าวโหนดอื่นๆ เห็นได้ชัดว่าคุณควรทำเช่นเดียวกัน แต่จุดสนใจหลักของคุณควรเป็นสะพานขณะนี้เรากำลังทำงานในสองทิศทางที่แตกต่างกัน ข้อแรก ฉันคิดว่าเหมือนกับคนอื่นๆ เรากำลังทำงานบนโปรโตคอล BFT สิ่งนี้ไม่ได้มีประสิทธิภาพมากนักและมีจุดบกพร่องบางอย่างที่ต้องแก้ไข เราคิดวิธีแก้ปัญหาคร่าวๆ ได้ แต่ก็ยังไม่ดีที่สุด ตัวอย่างเช่น คำถามข้อหนึ่งคือ คุณจะสร้างสมดุลระหว่างสิ่งจูงใจระหว่างผู้คัดแยกและผู้พิสูจน์ได้อย่างไร เนื่องจากผู้สั่งควบคุม MEV และผู้พิสูจน์ไม่สามารถเข้าถึง MEV ได้ จึงมีสิ่งจูงใจให้ผู้คนเรียกใช้คำสั่งแทนผู้พิสูจน์ แต่ในความเป็นจริง เราต้องการผู้พิสูจน์มากกว่าผู้สั่ง ดังนั้น คุณจะสร้างสมดุลของสิ่งจูงใจระหว่างทั้งสองได้อย่างไร นี่เป็นหนึ่งในปัญหานั้นแนวทางที่สองที่เรากำลังดำเนินการคือแนวทางอื่น โปรดจำไว้ว่าสิ่งต่าง ๆ อาจเปลี่ยนแปลงได้ ข้อเสนอใหม่ออกมาทุกวัน ตัวอย่างเช่น เมื่อเร็ว ๆ นี้มีการพูดคุยกันมากมายเกี่ยวกับการยกเลิกตามและวิธีที่คุณสามารถจัดจ้างการเรียงลำดับจากภายนอกไปยัง L1 ได้อย่างสมบูรณ์ ทิศทางที่สองคือโดยทั่วไปทิ้งตัวเรียงลำดับทั้งหมดและใช้ตัวสร้างภายนอก ตัวอย่างเช่น ผู้สร้าง ethereum หรือ Flashbots SUAVE เป็นต้น เสนอบล็อกที่สั่งแล้วเรียกใช้ฉันทามติภายในตัวพิสูจน์ ข้อดีคือคุณไม่ต้องจัดการกับสิ่งจูงใจ เพราะโดยพื้นฐานแล้ว คุณสามารถใช้ PBS ภายในโปรโตคอลได้ และสร้างโปรโตคอลที่ง่ายกว่า แต่ข้อเสียคือเนื่องจากเราต้องการผู้พิสูจน์จำนวนมาก (เพราะเราสามารถพิสูจน์พร้อมกันได้) จึงค่อนข้างยากที่จะเรียกใช้โปรโตคอล BFT แบบคลาสสิกกับพวกเขา ดังนั้น คำถามคือคุณจะเพิ่มประสิทธิภาพโปรโตคอล BFT ที่มีอยู่อย่างไรให้ทำงานกับผู้พิสูจน์หลายร้อยหรือหลายพันคน และนั่นไม่ใช่คำถามที่ง่ายที่จะตอบการแนะนำฉันทามติ L2 จำเป็นสำหรับผู้สั่งซื้อแบบกระจายอำนาจหรือไม่?**เหยาฉี**ฉันสามารถตอบคำถามนี้ได้คร่าวๆ เนื่องจากเราเพิ่งเปิดตัวสิ่งดังกล่าวเมื่อไม่นานมานี้ดังนั้นการจะแนะนำฉันทามติไม่ได้ขึ้นอยู่กับว่าเราต้องการหรือไม่ เมื่อคุณมีผู้สั่งซื้อจำนวนมากหรือแม้แต่โหนด คุณต้องทำให้พวกเขาเห็นด้วย ขึ้นอยู่กับสมมติฐานของคุณจริงๆ หากเป็นข้อสันนิษฐานของไบแซนไทน์ เราสามารถใช้ BFT หรือโปรโตคอลฉันทามติของไบแซนไทน์ที่มีอยู่ หากเป็นการตั้งค่าที่ไม่ใช่ไบแซนไทน์ ตัวอย่างเช่น หากเราสันนิษฐานว่าโหนดสามารถออนไลน์และออฟไลน์ได้เท่านั้น และไม่สามารถดำเนินการที่เป็นอันตรายได้ เราก็สามารถใช้โปรโตคอล Raft หรือโปรโตคอลที่สอดคล้องกันอื่นๆ ที่เร็วกว่าได้ แต่ยังไงก็ตาม หากเรามีกลุ่มผู้สั่งซื้อหรือผู้พิสูจน์ หากเราต้องการจัดระเบียบพวกเขาเข้าด้วยกันเพื่อสร้างบล็อกในช่วงระยะเวลาหนึ่ง คุณจะต้องมีระเบียบการที่สอดคล้องกันดังที่ Toghrul และ Abdel เพิ่งกล่าวถึง ผมเชื่อว่ามีข้อเสนอและหัวข้อการวิจัยมากมายเกี่ยวกับวิธีที่เราสามารถนำระบบการสั่งซื้อหรือการพิสูจน์แบบกระจายอำนาจไปใช้ได้ ดังนั้น เนื่องจากเราเพิ่งเปิดตัวเครือข่ายทดสอบสำหรับระบบการยกเลิกหลายตัว (ขณะนี้รองรับเฉพาะการพิสูจน์การฉ้อโกงสำหรับการยกเลิกแบบ Optimistic เท่านั้น) จากประสบการณ์การออกแบบและการใช้งานของเรา จึงมีบางสิ่งที่ฉันสามารถแบ่งปันเกี่ยวกับความยากลำบากได้ ดังที่ Toghrul พูดถึงตอนนี้ ความยากไม่ได้อยู่ที่ Consensus Protocol เอง ความยากที่แท้จริงอยู่ที่สิ่งอื่นนอกเหนือจากนี้ เช่น ส่วนการพิสูจน์ เพราะถ้าเป็นตัวเรียงลำดับเดียว คุณก็ไม่จำเป็นต้องมีโหนดมากมาย เราสามารถคิดว่ามันเป็น EVM ซึ่งเป็นเครื่องเสมือน ดังนั้นเพียงแค่ดึงธุรกรรมและดำเนินการ ทำการเปลี่ยนสถานะ ผู้พิสูจน์มีหน้าที่รับผิดชอบในการสร้างหลักฐานสำหรับการเปลี่ยนสถานะของธุรกรรมชุดก่อนหน้า อย่างไรก็ตาม หากเราเรียกใช้โปรโตคอลที่สอดคล้องกันสำหรับผู้เปรียบเทียบและผู้พิสูจน์เมื่อยกเลิก เราจำเป็นต้องแนะนำตรรกะที่สอดคล้องกันเพิ่มเติมที่นั่น คุณต้องมีระบบพิสูจน์สำหรับระเบียบการฉันทามติ ดังนั้นสิ่งนี้จะแนะนำงานจำนวนมากสำหรับระบบพิสูจน์อักษรในการสร้าง จากนั้นเมื่อคุณสร้างหลักฐานแล้ว คุณสามารถยืนยันได้อย่างง่ายดายบน L1 Ethereumนั่นเป็นเหตุผลว่าทำไม เมื่อเราเปิดตัวเครือข่ายทดสอบแบบหลายคำสั่งซื้อแรก การยกเลิกในแง่ดีมีข้อดีบางประการในเรื่องนี้ โดยทั่วไป คุณสามารถลดความซับซ้อนของหลายสิ่งหลายอย่าง เช่น ไม่ต้องพิจารณาส่วนพิสูจน์ความถูกต้อง เช่นเดียวกับเรา เราเปรียบเทียบทุกอย่างกับ WASM โดยพื้นฐานแล้ว ในที่สุด มันคือคำสั่ง WASM ดังนั้น การตรวจสอบคำแนะนำ WASM เหล่านี้จึงค่อนข้างง่ายในการตรวจสอบโดยใช้รหัส Solidity หากเราเพิ่งปรับใช้การตีความคำสั่ง WASM ทั้งหมดบน Ethereumแต่โดยทั่วไปแล้วปัญหาไม่ใช่เรื่องเดียว หากเรามีวิธีแก้ไขปัญหาที่สอดคล้องกันก็จะมีงานอื่นๆ ตามมา ที่ต้องแก้ไขไปพร้อมๆ กัน แน่นอนว่าจะมีปัญหาเกี่ยวกับ MEV เช่น เราจะกระจาย MEV อย่างไรให้เป็นธรรม คุณสามารถกำหนดผู้สั่งและผู้พิสูจน์ทั้งหมดโดยขึ้นอยู่กับว่าพวกเขาสร้างบล็อกหรือตรวจสอบความถูกต้องของบล็อกหรือไม่ แต่ท้ายที่สุดแล้ว มันเป็นการรวมกันของหลาย ๆ ประเด็น ไม่ใช่แค่เรื่องทางเทคนิค แต่รวมถึงแรงจูงใจทางเศรษฐกิจด้วยและเราต้องจำไว้ว่าที่เสนอ L2 เพราะเราต้องการลดต้นทุนก๊าซลงอย่างมาก เราจึงมีโหนดมากไม่ได้ แม้ในการสร้างการพิสูจน์ L2 อาจมีราคาแพงกว่า L1 ดังนั้นเราจึงจำเป็นต้องหาแนวทางที่สมดุลสำหรับปัญหาประเภทนี้**อับเดลฮามิด**ฉันต้องการเพิ่มอีกจุดหนึ่ง ประการแรก ขณะนี้ยังไม่มีหลักฐานการฉ้อโกงที่ไม่ได้รับอนุญาตจริงสำหรับการยกเลิกในแง่ดี และฉันยังคงเน้นเรื่องนี้ทุกครั้งที่มีโอกาส เพราะสิ่งสำคัญคือต้องซื่อสัตย์เกี่ยวกับเรื่องนี้เมื่อเปรียบเทียบ ดังนั้นพวกมันจึงไม่ใช่ L2 เลย นั่นคือสิ่งแรกจากนั้นฉันต้องการเพิ่มบางอย่างเกี่ยวกับความไม่ตรงกันระหว่างการเรียงลำดับและการพิสูจน์เพราะมันสำคัญมาก อย่างที่คุณพูด เราต้องการเพิ่มประสิทธิภาพการจัดเรียง เนื่องจากขณะนี้เป็นคอขวดสำหรับโซลูชันทั้งหมด แต่ก็ไม่เป็นไรในบริบทของการจัดเรียงแบบรวมศูนย์ เพราะเรารู้ว่าตัวเรียงลำดับจะสร้างการเปลี่ยนค่าเท่านั้น และเราจะสามารถตรวจสอบได้ แต่จะยากขึ้นในบริบทของการจัดเรียงแบบกระจายอำนาจ เพราะบางทีตัวเรียงลำดับของคุณอาจสร้างสิ่งที่ไม่สามารถตรวจสอบได้ จากนั้นคุณจะต้องจัดการกับสิ่งนั้นในภายหลังในบริบทของการเรียงลำดับแบบรวมศูนย์ เพื่อปรับการเรียงลำดับให้เหมาะสม เนื่องจากเราไม่ต้องสร้างการพิสูจน์ในระหว่างกระบวนการคัดแยก เราสามารถลองทำด้วยความเร็วท้องถิ่นได้ ซึ่งเป็นสิ่งที่เราต้องการทำ แปลภาษาไคโรเป็นภาษาเครื่องระดับต่ำ เช่น LLVM และรันเร็วมากบนตัวเรียงลำดับ จากนั้นคุณสามารถพิสูจน์แบบอะซิงโครนัสได้ และสิ่งที่ยอดเยี่ยมที่สุดเกี่ยวกับการพิสูจน์คือคุณสามารถทำควบคู่กันไปได้ ความขนานใหญ่ทำได้โดยการพิสูจน์ว่าการเรียกซ้ำเป็นไปได้ นั่นเป็นเหตุผลที่เราจะสามารถไล่ตามความเร็วของตัวเรียงลำดับได้ แต่มันเป็นเรื่องยากเมื่อกระจายอำนาจ เนื่องจากเราจำเป็นต้องตรวจสอบให้แน่ใจว่าผู้สั่งซื้อสร้างการเปลี่ยนสถานะที่ถูกต้องเท่านั้น**ทางเลือก**ฉันจะเพิ่มว่าฉันไม่แน่ใจว่า Starknet กำลังทำอะไรอยู่ที่นี่ แต่สำหรับเรา ฉันเดาว่ามันเป็นข้อสันนิษฐานทั่วไปของทุก zkRollup ว่าหากคุณกระจายศูนย์ตัวเรียงลำดับ ระบบพิสูจน์ของคุณจะต้องสามารถจัดการกับแบทช์ที่ไม่ถูกต้องได้ โดยพื้นฐานแล้ว ถ้าคุณส่งชุดงานที่มีลายเซ็นไม่ถูกต้อง คุณต้องสามารถพิสูจน์ได้ว่าสถานะผลลัพธ์นั้นเทียบเท่ากับสถานะเริ่มต้น ดังนั้นจะมีค่าใช้จ่ายอยู่บ้างไม่ทางใดก็ทางหนึ่ง มันเกี่ยวกับวิธีที่คุณลดความน่าจะเป็นของเหตุการณ์นี้ให้น้อยที่สุด**อับเดลฮามิด**ถูกต้องเลย. นั่นเป็นเหตุผลที่เราแนะนำ Sierra ในไคโร 1 เพื่อทำให้ทุกอย่างสามารถตรวจสอบได้ การเป็นตัวแทนระดับกลางนี้จะทำให้มั่นใจได้ว่าทุกโปรแกรมของไคโร 1 สามารถตรวจสอบได้ เพื่อให้เราสามารถรวมธุรกรรมที่ย้อนกลับได้การยกเลิกตามคืออะไร**เหยาฉี**การรวบรวมตามเดิมมาจากบล็อกโพสต์โดย Justin Drake ในฟอรัม Ethereum หนึ่งในแนวคิดของเขาคือเราสามารถใช้ตัวตรวจสอบ Ethereum บางตัวซ้ำเพื่อตรวจสอบธุรกรรมการยกเลิก ดังนั้นเราไม่ต้องการกลุ่มโหนดแยกต่างหากเพื่อตรวจสอบธุรกรรมการยกเลิกที่แตกต่างกัน โดยเฉพาะอย่างยิ่ง เราจะมีการยกเลิกจำนวนมากในอนาคต รวมทั้งการยกเลิกวัตถุประสงค์ทั่วไปและการยกเลิกเฉพาะแอปพลิเคชันจำนวนมาก ดังนั้น ในกรณีนี้ จะเป็นการดีหากเราสามารถหาสถานที่ทั่วไป เช่น กลุ่มเครื่องมือตรวจสอบความถูกต้องของ Ethereum เพื่อตรวจสอบความถูกต้องของธุรกรรมเหล่านี้แน่นอนว่านี่เป็นเพียงแนวคิดเท่านั้น เนื่องจากยังทำให้เกิดปัญหาทางเทคนิคมากมาย ตัวอย่างเช่น ในทางทฤษฎี เราอาจกำหนดให้เครื่องมือตรวจสอบความถูกต้องของ Ethereum สามารถตรวจสอบธุรกรรมการยกเลิกได้ แต่เป็นการยากมากที่จะได้รับตรรกะในการตรวจสอบความถูกต้องของการยกเลิกที่รวมหรือฝังอยู่ในโปรโตคอล Ethereum เราเรียกสิ่งนี้ว่าการตรวจสอบในโปรโตคอล ซึ่งต้องมีการฮาร์ดฟอร์กโหนด Ethereum แน่นอน ในกรณีนี้ เราสามารถตรวจสอบธุรกรรมการยกเลิกบางรายการได้ แต่ถ้าเราทำคุณจะเห็นปัญหา มันเหมือนกับว่าเราต้องการให้ L2 เลิกใช้งานเพื่อแบ่งปันแรงกดดันของ Ethereum แต่ท้ายที่สุดแล้ว เรายังคงขอให้ผู้ตรวจสอบความถูกต้องของ Ethereum ดำเนินการบางส่วนที่ถ่ายโอนไปยัง L2 หลายคนพูดถึงว่าเราจะทำสิ่งนี้ได้อย่างไรจากนั้นเราได้พูดคุยกับ Barnabe นักวิจัยจาก Ethereum Foundation ซึ่งกำลังทำงานเกี่ยวกับ PBS นี่คือข้อเสนอของ Ethereum ซึ่งก็คือการแบ่งงานของผู้ตรวจสอบความถูกต้องออกเป็นหลายบทบาท ผู้สร้างและผู้เสนอ ตอนนี้เรามี Flashbots ที่จะทำหน้าที่เป็นผู้สร้างใน PBS พวกเขาสร้างบล็อกทั้งหมดและส่งไปยังผู้เสนอ Ethereum ดังนั้นเมื่อบล็อกเหล่านี้ถูกบรรจุในเครือข่าย Ethereum ผู้สร้างก็จะได้รับรางวัลเช่นกัน แล้วในกรณีนี้ จะให้รางวัลแก่โปรแกรมตรวจสอบเหล่านี้จากเครือข่าย Ethereum ได้อย่างไร? พวกเขายังรับผิดชอบในการตรวจสอบการยกเลิกหนึ่งในวิธีแก้ปัญหาคือ "การพักใหม่" ซึ่งคุณอาจเคยได้ยินมามากจาก EigenLayer หรือโปรโตคอลอื่นๆ ผู้ใช้สามารถเดิมพัน ETH อีกครั้งบนเครือข่ายการเรียงลำดับอื่นๆ หรือให้รางวัลแก่ผู้ตรวจสอบความถูกต้องของ Ethereum สำหรับการเรียกใช้ซอฟต์แวร์เพื่อดำเนินการตรวจสอบความถูกต้องสำหรับการยกเลิก ในกรณีนี้ สามารถรับรางวัลได้ทั้งจาก L2 และผ่านโปรโตคอลการเดิมพันใหม่ จนถึงขณะนี้มีข้อเสนอมากมายสำหรับเรื่องนี้ แต่โดยทั่วไปแล้วมันเป็นแนวคิดว่าจะสามารถปรับเปลี่ยนวัตถุประสงค์ของเครื่องมือตรวจสอบความถูกต้องของ Ethereum ที่มีอยู่ได้อย่างไร เราจะนำ ETH ที่มีอยู่กลับมาใช้ใหม่เพื่อช่วยนำระบบ Rollup หรือ L2 ยุคใหม่ได้อย่างไร โดยพื้นฐานแล้วมันเป็นการพยายามทำให้หลาย ๆ อย่างง่ายขึ้นสำหรับโปรเจ็กต์การยกเลิก หากการยกเลิกต้องการตัวเรียงลำดับใหม่ หากพวกเขาต้องการแหล่งหลักประกันใหม่ พวกเขาสามารถนำโครงสร้างพื้นฐานที่มีอยู่หรือหลักประกันที่มีอยู่กลับมาใช้ใหม่ได้ นั่นเป็นเหตุผลว่าทำไมจึงสร้างขึ้นบน Ethereum จากนั้นโครงสร้างพื้นฐานเพิ่มเติมและการปักหลักก็สามารถนำมาใช้ซ้ำได้สำหรับการยกเลิกและ L2 เช่นกันข้อเสียของซีเควนเซอร์ที่ใช้ร่วมกันและการยกเลิกตาม และสถานการณ์การใช้งาน**ทางเลือก**ฉันต้องการบ่นเกี่ยวกับข้อเสนอนี้ ฉันไม่มั่นใจในข้อเสนอที่เกี่ยวข้องกับซีเควนเซอร์ที่ใช้ร่วมกัน แน่นอนว่าพวกเขายังอยู่ในช่วงเริ่มต้น และหากการออกแบบเหล่านี้ดีขึ้นในอนาคต เป็นไปได้ว่าฉันจะสนับสนุนพวกเขา เป็นเพียงว่ารูปแบบปัจจุบันไม่น่าเชื่อถือสำหรับฉัน มีสาเหตุหลายประการประการแรก สำหรับผมแล้ว คุณค่าหลักของตัวเรียงลำดับที่ใช้ร่วมกันคือการอนุญาตให้ผู้ใช้ได้รับความสามารถในการจัดองค์ประกอบอะตอมระหว่างการย้อนกลับเพื่อวัตถุประสงค์ทั่วไป เช่น Scroll หรือ Starknet แต่ปัญหาคือถ้าคุณมีความสามารถในการสลายตัวของอะตอม การควบรวมของคุณจะถือเป็นขั้นสุดท้ายเหมือนกับการควบรวมที่ช้าที่สุดที่คุณรวมเข้าด้วยกัน ดังนั้น สมมติว่า Scroll รวมกับ Optimistic Rollup ระยะเวลาสิ้นสุดของ Scroll จะเป็นเจ็ดวัน ในขณะที่คุณค่าหลักของ ZKRollup คือการบรรลุผลสำเร็จค่อนข้างเร็ว ผู้ใช้สามารถถอนไปที่ L1 ได้ภายในไม่กี่นาที และในกรณีนี้ ให้เลิกทำสิ่งนั้นโดยพื้นฐานแล้วข้อเสียอีกประการหนึ่งคือหากคุณต้องการสิ้นสุดแบบออฟไลน์ คุณต้องรันโหนด L2 และตราบใดที่ข้อมูลที่ส่งไปยังเชนได้รับการสรุปผลโดย L1 คุณจะได้รับขั้นสุดท้ายแบบโลคัลใน L2 หากแต่ละ L2 ที่รวมกันไม่รันโหนดแบบเต็ม แทบจะเป็นไปไม่ได้เลยที่จะบรรลุผลสำเร็จในเครื่อง ซึ่งหมายความว่าการรันระบบนี้อาจมีราคาแพงกว่าการรันระบบอย่าง Solana เนื่องจากคุณมีโหนดแบบเต็มหลายโหนดที่ทำงานพร้อมกัน โดยมีค่าใช้จ่ายของตัวเองและอื่นๆด้วยเหตุผลเหล่านั้น ฉันไม่คิดว่ามันสมเหตุสมผลสำหรับ L2 มันแตกต่างออกไปเล็กน้อยสำหรับ L3 เพราะถ้าใครต้องการสร้างห่วงโซ่เฉพาะแอปพลิเคชันและไม่ต้องการจัดการกับการกระจายอำนาจ สมมติว่าฉันกำลังสร้างเกมและฉันแค่ต้องการจัดการกับการสร้างเกม จากนั้นฉันสามารถจ้างงานกระจายอำนาจจากภายนอกได้ แต่ฉันไม่คิดว่ามันสมเหตุสมผลสำหรับ L2 ในขณะนี้ฉันก็มีความกังวลเช่นกัน ตัวอย่างเช่น คุณจะแบ่งปันผลกำไรของ MEV กับผู้พิสูจน์ได้อย่างไร เนื่องจากหากไม่พิจารณาปัญหาการจัดสรร โดยทั่วไป L1 จะได้รับผลกำไร MEV ทั้งหมด อีกสิ่งเล็กน้อยคือเวลายืนยันจะเท่ากับเวลายืนยันของ L1 ซึ่งก็คือ 12 นาที ซึ่งไม่สามารถเร็วกว่านี้ได้ ปัญหาอีกประการหนึ่งคือเนื่องจากไม่ได้รับอนุญาต ผู้ค้นหาหลายคนสามารถส่งแบทช์ธุรกรรมพร้อมกันได้ ซึ่งหมายความว่าอาจจบลงด้วยผลลัพธ์ที่รวมศูนย์ เนื่องจากผู้สร้างได้รับแรงจูงใจให้รวมธุรกรรมของพวกเขา หากผู้ค้นหาคนหนึ่งเชื่อมต่อได้ง่ายกว่าคนอื่นๆ ดังนั้น อาจส่งผลให้มี Seeker เพียงรายเดียวที่เสนอกลุ่มสำหรับ L2 ในท้ายที่สุด ซึ่งไม่ใช่ทางออกที่ดีนัก เพราะหากเป็นเช่นนี้ เราจะกลับไปที่สี่เหลี่ยมจัตุรัสโดยพื้นฐานแล้ว**เหยาฉี**ที่น่าสนใจคือ ฉันเพิ่งได้คุยกับ Ben ผู้ก่อตั้ง Espresso เมื่อสัปดาห์ที่แล้ว เราพูดถึงเรื่องนี้บ่อยครั้งในหัวข้อตัวเรียงลำดับที่ใช้ร่วมกัน ตามที่ Toghrul กล่าวถึง ฉันคิดว่ามีความไม่แน่นอนเกี่ยวกับสถานการณ์การใช้งานสำหรับระบบการสั่งซื้อที่ใช้ร่วมกัน สาเหตุหลักเป็นเพราะ L2 สำหรับวัตถุประสงค์ทั่วไป เรามักไม่มีเครื่องคัดแยกจำนวนมากเนื่องจากประสิทธิภาพ ความซับซ้อน และความประหยัด และฉันยังรู้สึกว่าไม่ว่าจะเป็นซีเควนเซอร์ที่ใช้ร่วมกัน การยกเลิกตามหรือการหยุดใหม่ กรณีการใช้งานที่ดีที่สุดส่วนใหญ่จะใช้สำหรับ RAS (การยกเลิกแบบเป็นบริการ) หรือแพลตฟอร์มดังกล่าวที่เราสามารถเผยแพร่การยกเลิกจำนวนมากได้ เราไม่ต้องการเครือข่ายคัดแยกขนาดใหญ่ตามจริง ถ้าไม่มีการเลิกใช้จำนวนมาก การยกเลิกเหล่านี้มีระบบตัวเรียงลำดับของตนเองอยู่แล้ว และมีชุมชนหรือพันธมิตรของตนเองอยู่แล้ว เมื่อมี L2 ทั่วไปเพียงบางส่วนเท่านั้น พวกเขาไม่จำเป็นต้องมีเครือข่ายแยกต่างหากและเป็นบุคคลที่สาม นอกจากนี้ นี่เป็นภาระของเครือข่ายบุคคลที่สาม เนื่องจากคุณต้องปรับแต่งสำหรับแต่ละ L2 และแต่ละ L2 มีสแต็กการทดสอบที่แตกต่างกัน สิ่งนี้ต้องการการเปลี่ยนแปลงมากมายในเครือข่ายของคุณเองแต่ในขณะเดียวกัน ดังที่ Toghrul กล่าวถึง ในกรณีการใช้งานพิเศษบางกรณี ตัวอย่างเช่น หากเราต้องการให้มีการทำงานร่วมกันในระดับเครื่องคัดแยก เครื่องคัดแยกที่ใช้ร่วมกันอาจเป็นวิธีที่เป็นไปได้ ตัวอย่างเช่น ใช้ตัวเรียงลำดับเดียวกันสำหรับการยกเลิกหลายรายการ ในกรณีนี้ ตัวเรียงลำดับนี้สามารถจัดการธุรกรรมแบบ cross-rollup เพื่อให้แน่ใจว่า cross-chain atomicity ระหว่าง rollup A, B และ Cแต่คุณยังสามารถเห็นปัญหาที่นี่เมื่อฉันอธิบายสถานการณ์ ถ้าเรามีซีเควนเซอร์ที่ใช้ร่วมกันจำนวนมากจริงๆ พวกมันจะกลายเป็นคอขวดอีกครั้งและกลายเป็นจุดแห่งความล้มเหลวเพียงจุดเดียว เรากำลังให้อำนาจแก่สิ่งที่เรียกว่าคำสั่งที่ใช้ร่วมกันเหล่านี้มากเกินไป พวกเขาเป็นเหมือนเครือข่ายมากขึ้น ควบคุมการเลิกใช้จำนวนมาก สุดท้าย เราต้องหาวิธีกระจายอำนาจของตัวเรียงลำดับที่ใช้ร่วมกันนี้อีกครั้งแต่ยังไงก็ตาม ฉันคิดว่ามันเป็นเรื่องดีที่ผู้คนค่อยๆ ค้นพบปัญหามากขึ้นเรื่อยๆ และหาทางออกมากขึ้นเรื่อยๆ สรุปแล้ว เป็นเรื่องน่าตื่นเต้นที่จะได้เห็นว่ามีอะไรใหม่ในด้านนี้ทุกวัน ด้วยโซลูชั่นใหม่ทั้งหมดนี้ อย่างน้อยเราก็มาถูกทางแล้วที่จะกระจายอำนาจในพื้นที่โรลอัพทั้งหมดอย่างแท้จริง**อับเดล**ใช่ ฉันเห็นด้วยกับคุณทั้งคู่ ฉันคิดว่ามันเหมาะสมกว่าสำหรับ Layer3 และ Lisk เพราะพวกเขาไม่ต้องการรับผิดชอบในการจูงใจเครือข่ายแบบกระจายอำนาจอีกต่อไป และจำเป็นต้องหาพันธมิตรเพื่อเริ่มต้นสิ่งต่าง ๆ เช่น ตัวเรียงลำดับ ดังนั้นฉันคิดว่าสำหรับ Lisk มันสมเหตุสมผล แต่เช่นเดียวกับ Toghrul ฉันไม่คิดว่ามันสมเหตุสมผลสำหรับ Layer2 ในตอนนี้**หัวข้อที่ 4**ผู้สั่งซื้อแบบกระจายอำนาจจะมีผลอย่างไรต่อ MEV?**อับเดล**สำหรับ Starknet ในบริบทของการรวมศูนย์ เราไม่ทำ MEV ทุกประเภท และเราใช้รูปแบบมาก่อนได้ก่อน กล่าวคือในบริบทของการกระจายอำนาจ แน่นอนว่า MEV จะเข้ามาเพิ่มเติมในภายหลัง แต่ยังเร็วเกินไปที่จะบอกว่าอัตราส่วนใด เนื่องจากขึ้นอยู่กับการออกแบบกลไกฉันทามติและด้านอื่นๆ ด้วย**ทางเลือก**แต่ประเด็นก็คือ แม้ว่าคุณจะไม่ได้ทำ MEV แต่อาจมี MEV บางอย่างที่ยังคงเกิดขึ้นใน Starknet การกระจายอำนาจด้วยตัวมันเองไม่ได้ลด MEV หรือเพิ่ม MEV อย่างแท้จริง แน่นอน หากคุณใช้โปรโตคอลการสั่งซื้อที่ยุติธรรมหรือการเข้ารหัสเกณฑ์ เช่น ใช่ คุณจะลด MEV ให้เหลือน้อยที่สุด แต่คุณไม่สามารถกำจัดมันได้อย่างสมบูรณ์ ปรัชญาของฉันคือ: ไม่สามารถกำจัด MEV ได้ แต่สมมติว่าคุณกำลังสร้างฉันทามติ BFT หรือสร้างบางสิ่งที่เหนือกว่าฉันทามติ BFT สิ่งนี้ไม่ส่งผลกระทบต่อ MEV เลย MEV ยังคงมีอยู่ ควรเป็นคำถามว่าผู้ค้นหาทำงานร่วมกับตัวเรียงลำดับเพื่อแยก MEV นั้นอย่างไร**เหยาฉี**ปัญหาคือแม้แต่รุ่นที่มาก่อนได้ก่อนก็มีส่วนที่ยุ่งยาก เมื่อเราเปิดเผย mempool ต่อผู้ค้นหาบางคน พวกเขายังคงได้เปรียบที่จะเล่นมากขึ้น ตัวอย่างเช่น สำหรับซีเควนเซอร์ พวกเขาเทียบเท่ากับการรออยู่ที่ประตูสำนักงานของคุณ ดังนั้น ในกรณีนี้ เมื่อพวกเขาเห็นโอกาสในการเก็งกำไรบางประเภท ไม่ใช่แค่การโจมตีแบบ front-running หรือแบบแซนวิช ทันทีที่ผู้ใช้ส่งธุรกรรม พวกเขาสามารถเห็นได้ทันทีใน mempool ดังนั้น พวกเขาสามารถซื้อขายล่วงหน้าได้อย่างรวดเร็ว ดังนั้น พวกเขาจึงได้เปรียบเหนือผู้ค้นหาคนอื่นๆแต่ย้อนกลับไปที่การกระจายอำนาจ ฉันคิดว่าส่วนใหญ่เกี่ยวกับการต่อต้านการเซ็นเซอร์ ดังที่เราได้กล่าวไว้ตอนต้น ซีเควนเซอร์จัดการโดยทีม ทีมสามารถบอกได้ว่าพวกเขายุติธรรมกับทุกคน แต่สิ่งนี้ไม่ได้ป้องกันในรหัส ดังนั้น หากเราสามารถมีเครือข่าย P2P ได้ คงจะดีมากหากเรารู้สึกว่าโหนดเหล่านี้ตรวจสอบธุรกรรมของฉัน แล้วเราก็สามารถส่งไปยังโหนดอื่นๆ ได้ ดังนั้นจึงเป็นเรื่องของความยุติธรรมในการประมวลผลธุรกรรมที่ L2สำหรับ MEV เนื่องจากเมื่อเร็วๆ นี้ นอกจาก MEV ที่สร้างขึ้นในการยกเลิกครั้งเดียวแล้ว ยังมี MEV บางส่วนที่สร้างข้ามสะพานอีกด้วย ในเครือข่ายการคัดแยกที่ค่อนข้างกระจายอำนาจนี้ คุณจะมีโอกาสมากขึ้นในการแยก MEV สมมติว่าเรามีเครือข่ายการสั่งซื้อที่ใช้ร่วมกัน หากคุณสามารถโน้มน้าวให้ผู้สั่งซื้อที่ใช้ร่วมกันจัดลำดับธุรกรรมใหม่ได้ โดยพื้นฐานแล้วคุณจะมีข้อได้เปรียบอย่างมากเหนือคนอื่นๆมีข้อดีและข้อเสียสำหรับเครือข่ายซีเควนเซอร์ที่ใช้ร่วมกัน ในด้านบวก เราสามารถกระจายอำนาจของระบบจัดอันดับเพิ่มเติมได้ แต่ในทางกลับกัน ทุกคนมีโอกาสที่จะเป็นผู้คัดแยก ดังนั้นพวกเขาจึงสามารถทำอะไรก็ได้ตามต้องการ และป่าแห่งนี้ก็มืดมิดอีกครั้ง ดังนั้นเราจึงแนะนำการกระจายอำนาจ และจากนั้นเราต้องเผชิญกับปัญหาที่คล้ายกันที่เราเผชิญใน Ethereum นั่นเป็นเหตุผลที่ Flashbots และ Ethereum Foundation ต้องการก้าวไปข้างหน้ากับ PBS แยกผู้เสนอและผู้สร้างออกจากกัน จากนั้นจึงพยายามมีโซลูชันเดียวในด้านผู้สร้างดังนั้นเมื่อเราดูที่ปัญหา มันไม่ใช่แค่ปัญหาเดียว มันไม่ใช่ปัญหาแบบตัวต่อตัวอีกต่อไป แต่เป็นแบบตัวต่อตัวและแบบตัวต่อตัว และอื่นๆ
การสนทนากับทีม AltLayer, Scroll, Starknet: Sequencer ที่ใช้ร่วมกันและฉันทามติ L2
การแนะนำ
เมื่อเราดูวิสัยทัศน์และแผนงานของโซลูชันการยกเลิกต่างๆ เราจะพบว่า การยกเลิกเกือบทั้งหมดมีเป้าหมายสูงสุด หากเป้าหมายนี้รวมเป็นประโยคเดียว: สร้างกองเทคโนโลยี จัดหาให้กับชุมชน แก้ปัญหา การขยายตัวของ บล็อกเชนและท้ายที่สุดคือการกระจายอำนาจของกองเทคโนโลยีของการดำเนินงานและการกำกับดูแล สิ่งนี้นำไปสู่คำว่าการกระจายอำนาจแบบกระจายอำนาจ
แล้วการกระจายอำนาจคืออะไรกันแน่? การแบ่งงานระหว่างส่วนต่างๆ ของระบบ Rollup คืออะไร? การกระจายอำนาจหมายถึงการเพิ่มผู้เข้าร่วมการทำงานของระบบให้ได้สูงสุดหรือไม่? ตัวคัดแยกแบบรวมศูนย์จะมีผลอย่างไร ผู้สั่งซื้อที่ใช้ร่วมกันและฉันทามติในท้องถิ่น L2 ควรได้รับการออกแบบอย่างไร อะไรคือหน้าที่ของตัวพิสูจน์เอกลักษณ์ใน ZK-Rollup? เครือข่ายผู้พิสูจน์การกระจายอำนาจแบบเปิดจะมีลักษณะอย่างไร ทำไมเราต้องการการเร่งด้วยฮาร์ดแวร์ zk วิธีแก้ไขปัญหาความพร้อมใช้งานของข้อมูลคืออะไร ....
มีการพูดคุยไม่รู้จบเกี่ยวกับการยกเลิกแบบกระจายอำนาจในชุมชน ดังนั้น ECN จึงจัดทำชุดสัมภาษณ์พอดคาสต์ในหัวข้อ "การยกเลิกแบบกระจายอำนาจ" และเชิญผู้ก่อตั้งและนักวิจัยที่โดดเด่นในสาขานี้มาพูดคุยเกี่ยวกับความเข้าใจเกี่ยวกับการยกเลิกแบบกระจายอำนาจ ความเข้าใจ
เมื่อสภาพคล่องหลั่งไหลเข้าสู่แพลตฟอร์ม Layer 2 มากขึ้นเรื่อยๆ ผู้ให้บริการ Rollup จำนวนมากขึ้นเรื่อยๆ ก็ปรากฏตัวขึ้น ไม่เพียงแต่โซลูชัน Rollup ที่ใช้งานทั่วไป, Rollup Chain เฉพาะแอปพลิเคชันเท่านั้น แต่ยังรวมถึงแพลตฟอร์ม Rollup-as-a-Service ด้วย ดังนั้น ผู้คนจำนวนมากขึ้นจึงกังวลว่า "ซีเควนเซอร์" บทบาทที่สำคัญมากในการโรลอัพเกือบทั้งหมดยังคงรวมศูนย์อยู่ อะไรคือความเสี่ยงของตัวคัดแยกแบบรวมศูนย์? ตัวเรียงลำดับแบบกระจายอำนาจเป็นงานด่วนหรือไม่?
**ในตอนที่ 2 เราได้เชิญ Yaoqi Jia ผู้ก่อตั้ง AltLayer Network, Toghrul Maharramov นักวิจัยของ Scroll และ Abdelhamid Bakhta หัวหน้าทีมสำรวจของ Starknet เพื่อทำการอภิปรายแบบโต๊ะกลมในหัวข้อของตัวเรียงลำดับแบบกระจายอำนาจ เพื่อให้ผู้ชมและผู้อ่าน สามารถเข้าใจความคืบหน้าและปัญหาบางอย่างในปัจจุบันของตัวเรียงลำดับแบบกระจายอำนาจ **
แขกรับเชิญในฉบับนี้:
อดีต
ปัญหาที่ 1: วิธีการกระจายอำนาจ Rollup?
ดูตัวอย่าง
ปัญหาที่ 3: Prover network และการเร่งด้วยฮาร์ดแวร์ zk
ประเด็นที่ 4: ความพร้อมใช้งานของข้อมูลและพื้นที่จัดเก็บแบบกระจายอำนาจ
ฟัง
คลิกเพื่อสมัครรับข้อมูลพอดแคสต์เพื่อเรียนรู้เพิ่มเติม:
ยูทูบ：
พิภพเล็ก:
ประทับเวลา
00:49 เหยาฉีแนะนำตัวเอง
01:37 น. อับเดลฮามิดแนะนำตัวเอง
02:50 Toghrul แนะนำตัวเอง
04:03 บทบาทของตัวเรียงลำดับในการยกเลิก
08:37 ผู้สั่งซื้อแบบกระจายอำนาจ: การปรับปรุงประสบการณ์ผู้ใช้และการจัดการปัญหาความสดและการเซ็นเซอร์
19:43 Starknet จะกระจายอำนาจไปยังตัวเรียงลำดับอย่างไร
22:59 Scroll จะกระจายอำนาจตัวเรียงลำดับอย่างไร
26:34 ความแตกต่างระหว่างฉันทามติ L2 ในบริบทของ Optimistic rollup และ zkRollup
32:28 zkRollup กระจายอำนาจตัวเรียงลำดับและจำเป็นต้องพิจารณาตัวพิสูจน์ด้วย
36:01 ค่าสะสมขึ้นอยู่กับอะไร
40:53 ข้อเสียของซีเควนเซอร์ที่ใช้ร่วมกันและการยกเลิกตาม และสถานการณ์การใช้งาน
49:02 ผู้สั่งซื้อแบบกระจายอำนาจจะมีผลอย่างไรต่อ MEV?
การแนะนำแขก
เหยาฉี
ฉันเป็นผู้ก่อตั้ง AltLayer AltLayer กำลังสร้างแพลตฟอร์ม "Rollup as a Service" ซึ่งนักพัฒนาเพียงคลิกปุ่มบางปุ่มและกำหนดค่าพารามิเตอร์ เมื่อใช้ Launchpad หรือแผงควบคุมของเรา พวกเขาสามารถเปิดใช้การยกเลิกเฉพาะแอปพลิเคชันได้อย่างรวดเร็วภายในไม่กี่นาที นั่นคือสิ่งที่เรากำลังพยายามทำอยู่ตอนนี้ เพื่อให้นักพัฒนามีสภาพแวดล้อมการดำเนินการและฟังก์ชันการทำงานทั่วไป เรายังมีซีเควนเซอร์หลายตัว ระบบเครื่องเสมือนหลายเครื่อง และระบบพิสูจน์ต่างๆ ให้นักพัฒนาเลือกใช้
อับเดลฮามิด
ฉันทำงานที่ Starkware และเป็นหัวหน้าทีมสำรวจ เป้าหมายของกลุ่มนี้คือการเปิดตัวโครงการโอเพ่นซอร์สที่มีลักษณะเหมือนการวิจัย แต่เน้นด้านวิศวกรรม เป้าหมายของเราคือการทำงานในโครงการโอเพ่นซอร์สโดยความร่วมมืออย่างใกล้ชิดกับชุมชนและผู้คนจากระบบนิเวศอื่นๆ หนึ่งในโครงการดังกล่าวคือ Madara ซึ่งเป็นตัวคัดแยกของ Starknet ไม่เพียงเป็นตัวเลือกสำหรับเครือข่ายสาธารณะของ Starknet เท่านั้น แต่ยังเป็นซีเควนเซอร์สำหรับห่วงโซ่แอปพลิเคชัน Starknet และ Layer3 สิ่งนี้ยังเกี่ยวข้องกับสิ่งที่แขกรับเชิญคนก่อนกล่าวไว้ เรากำลังคิดเกี่ยวกับการให้บริการการยกเลิกเป็นฟังก์ชันบริการ ผู้คนสามารถเปิดตัวห่วงโซ่แอปพลิเคชัน Starknet และเลือกโซลูชันความพร้อมใช้งานของข้อมูลที่แตกต่างกันในลักษณะที่ค่อนข้างเป็นโมดูล ก่อนหน้านั้นฉันทำงานเป็นนักพัฒนาหลักของ Ethereum เป็นเวลาสี่ปี โดยรับผิดชอบงาน EIP-1559 เป็นหลัก
ทางเลือก
ฉันเป็นนักวิจัยที่ Scroll และความรับผิดชอบหลักของฉันที่ Scroll คือการออกแบบโปรโตคอล การออกแบบบริดจ์ การกระจายอำนาจ แรงจูงใจ อะไรทำนองนั้น ดังนั้นเมื่อฉันไม่ได้ทวีต เวลาส่วนใหญ่ฉันแค่ทำงานเกี่ยวกับวิธีกระจายอำนาจโปรโตคอลหรือผู้สั่งการ ผู้พิสูจน์ อะไรทำนองนั้น เช่นเดียวกับ Starkware สิ่งหนึ่งที่เรากำลังดำเนินการคือ SDK แบบโรลอัป ดังนั้น คุณสามารถออกการยกเลิกตาม Scroll และใช้ตัวเลือกความพร้อมใช้งานของข้อมูลแบบโมดูลาร์ได้ และอื่นๆ เรายังคงพิจารณาตัวเลือกที่การยกเลิกตาม Scroll SDK สามารถใช้ตัวเรียงลำดับของ Scroll เพื่อช่วยให้บรรลุการกระจายอำนาจโดยไม่ต้องให้การยกเลิกแต่ละครั้งต้องจัดการการกระจายอำนาจด้วยตัวเอง แน่นอนว่าตอนนี้ยังไม่ได้สรุปแผน อย่างไรก็ตาม นี่เป็นแนวทางที่เรากำลังดำเนินการอยู่
ส่วนสัมภาษณ์
หัวข้อที่หนึ่ง
อธิบายตัวเรียงลำดับของการยกเลิก?
อับเดลฮามิด
ตัวเรียงลำดับเป็นองค์ประกอบที่สำคัญมากในสถาปัตยกรรมเลเยอร์ 2 ส่วนประกอบนี้รับธุรกรรมจากผู้ใช้ จากนั้นทำแพ็คเกจและรวมกลุ่มเป็นบล็อก ดำเนินการธุรกรรม และอื่น ๆ มันสำคัญมากเพราะนี่คือองค์ประกอบที่รับผิดชอบในการสร้างบล็อก เนื่องจากเลเยอร์ 2 ก็เป็นบล็อกเชนที่มีการบล็อกธุรกรรมด้วย ผู้สั่งซื้อสร้างบล็อกเหล่านี้และผู้พิสูจน์รับรองบล็อกเหล่านี้
เหยาฉี
ดังที่ Abdel กล่าวไว้ ผู้สั่งซื้อคือการรวมกันของหลายฟังก์ชันในบล็อกเชน ดังนั้นเราจึงอาจให้ความรับผิดชอบแก่ผู้สั่งซื้อมากเกินไปเมื่อเทียบกับบล็อกเชนสาธารณะทั่วไป ก่อนอื่นต้องรวบรวมธุรกรรมทั้งหมดจากผู้ใช้ จากนั้นจึงจัดเรียงธุรกรรมเหล่านั้นตามราคาน้ำมันหรือตามลำดับก่อนหลัง หลังจากนั้น ซีเควนเซอร์จำเป็นต้องดำเนินการธุรกรรมเหล่านี้ เช่นเดียวกับตอนนี้ Layer2 บางตัวใช้ EVM (Starware มีเครื่องเสมือนที่แตกต่างกัน) แต่โดยพื้นฐานแล้วซีเควนเซอร์จำเป็นต้องใช้เครื่องเสมือนเฉพาะเพื่อดำเนินการธุรกรรมและสร้างสถานะ จากนั้นธุรกรรมจะเข้าสู่ขั้นตอนการยืนยันล่วงหน้า ซึ่งหมายความว่าหากคุณเห็นเวลายืนยันหนึ่งหรือสองวินาที หรือแม้แต่เสี้ยววินาที ก็จะเป็นสถานะการยืนยันล่วงหน้าที่เสร็จสมบูรณ์โดยซีเควนเซอร์ จากนั้น สำหรับผู้คัดแยกส่วนใหญ่ พวกเขาจำเป็นต้องอัปโหลดหรือเผยแพร่จุดตรวจหรือสถานะแฮชเป็น L1 นี่คือการยืนยันที่ระดับ L1 ซึ่งเราเรียกว่าความพร้อมใช้งานของข้อมูล ดังนั้นตัวเรียงลำดับจึงมีบทบาทมากมายในระบบการยกเลิก แต่โดยทั่วไปแล้ว ฉันคิดว่ามันเป็นองค์ประกอบที่สำคัญที่สุดของระบบการยกเลิก
** หัวข้อ 2 **
เหตุใดตัวเรียงลำดับแบบกระจายอำนาจจึงมีความสำคัญ ถ้าเราใช้ตัวเรียงลำดับแบบรวมศูนย์ อันตรายที่ซ่อนอยู่ต่อผู้ใช้และระบบคืออะไร?
ทางเลือก
ก่อนอื่น เราต้องรู้ว่ายกเว้น Fuel V1 ในขั้นตอนปัจจุบัน จะไม่มีการสั่งสมจริง เนื่องจากรุ่นอื่นๆ ยังมีวงล้อฝึกหัดอยู่
อย่างไรก็ตาม เราสามารถพูดได้ว่าเมื่อมันถูกจัดประเภทเป็นการยกเลิก หมายความว่ามีการลบ multi-sig ออกไป และอื่นๆ จากนั้นปัญหาการกระจายอำนาจของตัวเรียงลำดับจะกลายเป็นปัญหาประสบการณ์ของผู้ใช้ ไม่ใช่ปัญหาด้านความปลอดภัย ดังนั้นเมื่อผู้คนพูดถึง เช่น การกระจายอำนาจ L1 ปัญหาจะแตกต่างไปจากเดิมอย่างสิ้นเชิง เนื่องจาก L1 ต้องรับประกันการสั่งซื้อและลูกค้ารายย่อย ดังนั้นหากไคลเอ็นต์แบบไลท์ต้องการตรวจสอบว่าสถานะถูกต้อง ไคลเอ็นต์จะต้องเชื่อถือตัวตรวจสอบ L1 สำหรับการยกเลิก นี่ไม่ใช่กรณี เนื่องจากตัวเรียงลำดับจัดเตรียมการเรียงลำดับชั่วคราวเท่านั้น ซึ่ง L1 จะสรุปผลให้ และเนื่องจากการรับประกันว่าการยกเลิกการเซ็นเซอร์จะต้านทานการเซ็นเซอร์ เราจึงไม่จำเป็นต้องมีการกระจายอำนาจเพื่อทำให้สิ่งนี้เกิดขึ้น
ดังนั้นจึงมีเหตุผลหลายประการที่คุณต้องการตัวเรียงลำดับแบบกระจายอำนาจ ประการแรก หากกล่าวว่าการสรุปผล L1 ช้า (อาจเป็นเพราะการพิสูจน์ความถูกต้องที่คุณส่งมานั้นช้าเกินไป หรือเนื่องจากกลไกระยะเวลาท้าทายของการพิสูจน์การฉ้อโกงโดยรวมในแง่ดี) คุณต้องพึ่งพาบางสิ่งเพื่อให้ได้รับการยืนยันการทำธุรกรรมอย่างรวดเร็ว ในขั้นตอนของการยืนยันอย่างรวดเร็วนี้ แม้ว่าคุณจะวางใจได้ว่า Starkware หรือ Scroll จะไม่หลอกลวงคุณ แต่สิ่งเหล่านี้บ่งชี้ว่าหลังจากบล็อกได้รับการยืนยันแล้ว จะไม่มีการจัดระเบียบใหม่ นี่คือสมมติฐานของความไว้วางใจ และการกระจายอำนาจสามารถเพิ่มการรับประกันทางเศรษฐกิจ และอื่นๆ
แต่ตามนี้ การยกเลิกยังไม่มีการรับประกันการสิ้นสุดตามเวลาจริง โดยพื้นฐานแล้ว คุณสามารถบังคับให้ทำแพ็กเกจธุรกรรมผ่าน L1 ได้ แต่ต้องใช้เวลาหลายชั่วโมงในการแพ็กเกจธุรกรรมนั้น ตัวอย่างเช่น หากมี oracle ที่รับผิดชอบในการอัปเดตและเวลาผันผวน โดยทั่วไปแล้วหาก oracle ได้รับการอัปเดตเป็นเวลาหนึ่งชั่วโมงขึ้นไป แอปพลิเคชันในการยกเลิกจะไม่สามารถใช้งานได้ โดยพื้นฐานแล้ว การกระจายอำนาจช่วยให้เราสามารถรับประกันการต่อต้านการเซ็นเซอร์ตามเวลาจริงที่แข็งแกร่งยิ่งขึ้น เพราะจากนั้นฝ่ายตรงข้ามจะต้องประนีประนอม ไม่ใช่แค่หน่วยงานเดียวหรือไม่กี่หน่วยงาน แต่รวมถึงเครือข่ายผู้สั่งซื้อทั้งหมดด้วย
สำหรับเราแล้ว การกระจายอำนาจเป็นวิธีแก้ปัญหามากกว่าในการปรับปรุงประสบการณ์ผู้ใช้หรือแก้ไขกรณีมุมของการอัปเดต oracle และอื่นๆ แทนที่จะให้การรับประกันความปลอดภัยขั้นพื้นฐาน L1 ทำสิ่งนี้
อับเดลฮามิด
ใช่ คำถามเกี่ยวกับตัวเรียงลำดับแบบกระจายอำนาจที่คุณกล่าวถึงนั้นไม่เหมือนกับ L1 แบบกระจายอำนาจทุกประการ ซึ่งฉันคิดว่าสำคัญมาก เนื่องจากเมื่อเราเห็น L1 บางคนวิจารณ์ตัวคัดแยกจากส่วนกลาง พวกเขาไม่ได้พิจารณาถึงการแลกเปลี่ยนที่ตัวคัดแยกส่วนกลางทำอย่างเหมาะสม
บนพื้นฐานนี้ ฉันต้องการเพิ่มบางสิ่งที่เกี่ยวข้องกับประสบการณ์ของผู้ใช้ ที่เกี่ยวข้องกับกิจกรรม เนื่องจากเมื่อคุณมีเครื่องคัดแยกเพียงเครื่องเดียว คุณจะมีความเสี่ยงสูงที่เครื่องคัดแยกจะขัดข้อง ดังนั้น ผู้สั่งซื้อแบบกระจายอำนาจจึงเพิ่มความยืดหยุ่นและความมีชีวิตชีวาบนเครือข่าย แต่ถึงแม้จะอยู่ในบริบทแบบรวมศูนย์ เราก็มีความปลอดภัยที่ดีในเรื่องความปลอดภัย เนื่องจากเมื่อคุณสามารถบังคับธุรกรรมแพ็คเกจผ่าน L1 ได้ ความแตกต่างระหว่างสองสิ่งนี้จะเป็นเพียงไทม์ไลน์เท่านั้น และการมีตัวเรียงลำดับแบบกระจายอำนาจช่วยให้คุณมีการรับประกันการต่อต้านการเซ็นเซอร์อย่างรวดเร็ว ดังที่ Toghrul กล่าวถึง ดังนั้น ฉันแค่อยากเพิ่มเติมว่า การมีเครือข่ายผู้สั่งซื้อแบบกระจายอำนาจเป็นสิ่งสำคัญเช่นกันสำหรับความมีชีวิตชีวา
เหยาฉี
ฉันต้องการเพิ่มบางอย่าง กิจกรรมอาจเป็นสิ่งสำคัญที่สุดที่เราต้องพิจารณาในขั้นตอนนี้ กรณีล่าสุดของแอร์ดรอปบน L2 ที่ได้รับความนิยมสูงสุด เช่น Optimism และ Arbitrum หยุดทำงานไปช่วงหนึ่ง ดังนั้น ฉันคิดว่าสิ่งที่เราต้องแก้ไขคือวิธีจัดการกับคำขอธุรกรรมหลายพันรายการต่อวินาทีเมื่อเรามีตัวเรียงลำดับเพียงตัวเดียว แม้ว่าในทางทฤษฎีแล้ว หากคุณมีเพียงโหนดเดียว มันก็ไม่สามารถจัดการกับคำขอจำนวนมากในเวลาเดียวกันได้ ดังนั้น เกี่ยวกับความมีชีวิตชีวา เราต้องการผู้คัดแยกจำนวนมากอย่างแน่นอน ความล้มเหลวเพียงจุดเดียวเป็นอุปสรรคอย่างแท้จริง ไม่ใช่แค่สำหรับ Web3 แม้แต่ Web2 ก็เป็นปัญหาใหญ่
นอกจากนั้น ยังมีปัญหาของการเซ็นเซอร์ หากเรามีผู้ประสานงานเพียงคนเดียว แม้ว่าเราจะเห็นว่าทีมสามารถดำเนินการได้ แต่คุณยังคงต้องพิสูจน์ว่าทีมจะไม่ตรวจสอบธุรกรรมจริงๆ บางครั้งก็เป็นไปได้และมีความสามารถสำหรับบุคคลที่ไม่ประสงค์ดีที่จะขึ้นบัญชีดำธุรกรรมบางอย่าง นั่นคือระบบออร์เดอร์แบบกระจายอำนาจ พวกเขายังสามารถลองส่งธุรกรรมผ่านออร์เดอร์อื่นๆ นั่นเป็นเหตุผลที่เราได้รับคำวิจารณ์มากมายเกี่ยวกับผู้คัดแยกเดี่ยวเมื่อเร็ว ๆ นี้
นอกจากนั้นยังมีปัญหาอื่น ๆ เช่น MEV และการวิ่งเร็ว ในระบบที่มีตัวเรียงลำดับแบบรวมศูนย์ โดยเฉพาะอย่างยิ่งสำหรับโปรโตคอล DeFi พวกเขาอาจตรวจสอบ mempool ได้อย่างง่ายดาย อาจไม่ได้อยู่ในรูปแบบของผู้นำหน้า แต่พวกเขามีโอกาสที่ดีกว่าในการกลั่นกรองการค้าและอนุญาโตตุลาการ
ปัญหาเหล่านี้มากมายด้วยเหตุผลหลายประการ แม้ว่าเราจะเห็นว่า L2 แตกต่างจาก L1 มากก็ตาม แต่ท้ายที่สุดแล้ว เรายังจำเป็นต้องทำให้การกระจายอำนาจเป็นไปได้มากที่สุด ดังนั้นเราจึงต้องเผชิญกับปัญหาที่คล้ายกันกับบล็อกเชนสาธารณะหรือ L1
อับเดลฮามิด
ใช่ ฉันยอมรับว่าตัวเรียงลำดับแบบกระจายศูนย์มีความสำคัญ แต่ฉันก็อยากจะบอกว่า อย่างที่เราทุกคนทราบกันดีว่า นี่ไม่ใช่คำถามที่ง่าย
นอกจากนี้ **เนื่องจาก Rollups มีสถาปัตยกรรมเฉพาะที่มีหลายเอนทิตี มีผู้สั่งซื้อรายเดียวที่เรากำลังพูดถึง แต่ก็มีผู้พิสูจน์ด้วย และเราจำเป็นต้องกระจายอำนาจทั้งสองอย่าง **จะมีการแลกเปลี่ยนและความยากลำบากในการทำธุรกรรมราคาเนื่องจากปัจจัยที่แตกต่างกันที่จำเป็นในการเรียกใช้เครือข่าย ดังนั้นคุณกำหนดราคาข้อตกลงอย่างไร? เครื่องคัดแยกและเครื่องพิสูจน์มีข้อกำหนดด้านฮาร์ดแวร์ที่แตกต่างกัน เครื่องพิสูจน์ต้องการเครื่องที่ทรงพลังเป็นพิเศษ และอื่นๆ ดังนั้น การทำธุรกรรมการกำหนดราคาในโลกที่มีการกระจายอำนาจจึงเป็นปัญหาที่ยากมากเช่นกัน ซึ่งเป็นสาเหตุที่เราต้องใช้เวลาในการก้าวไปข้างหน้าอย่างช้าๆ
ดังนั้นเราทุกคนจะต้องเผชิญกับการแลกเปลี่ยนดังกล่าว หากเราต้องการ Decentralize อย่างรวดเร็ว เราอาจต้องใช้วงล้อฝึกฝนและค่อยๆ Decentralize เพราะถ้าเราต้องการสถาปัตยกรรมที่สมบูรณ์แบบโดยตรงจะใช้เวลาหลายปี ดังนั้นฉันคิดว่าเราจะใช้วิธีปฏิบัติและพยายามกระจายอำนาจอย่างค่อยเป็นค่อยไป อย่างน้อยนั่นคือแผนปัจจุบันของเรา เช่น อาจเริ่มต้นด้วยกลไกฉันทามติง่ายๆ ของ BFT แล้วเพิ่มกลไกฉันทามติอื่นในระยะสั้นหรืออย่างอื่น ฉันแค่อยากจะบอกว่า มันไม่ใช่คำถามที่ง่ายเลย เนื่องจากเห็นได้ชัดว่ามีการแลกเปลี่ยนระหว่างความเร็วในการพัฒนาและความเหมาะสมของสถาปัตยกรรมกับสภาพแวดล้อมแบบกระจายอำนาจ
หัวข้อที่ 3
จะกระจายอำนาจไปยังตัวเรียงลำดับได้อย่างไร?
อับเดลฮามิด
มีฟีเจอร์มากมายที่เราต้องการกระจายอำนาจ และทั้งหมดมีการแลกเปลี่ยนที่แตกต่างกัน
ตัวอย่างเช่น เมื่อกระจายอำนาจ คุณต้องการแนะนำกลไกฉันทามติบางประเภท อย่างไรก็ตามในกลไกฉันทามติมีหลายส่วน วิธีแรกคือการเลือกผู้นำ นั่นคือการเลือกว่าใครจะสร้างบล็อก ใครจะเป็นผู้สั่งรับผิดชอบในการสร้างบล็อกในช่องที่กำหนดหรือภายในเวลาที่กำหนด **สิ่งที่ทีม Starknet วางแผนที่จะทำคือการใช้เลเยอร์ 1 ให้ได้มากที่สุด กล่าวคือ ในอัลกอริธึมการเลือกผู้นำของเรา เราต้องการเดิมพันในเลเยอร์ 1 ตัวอย่างเช่น เรามีโทเค็น และคำมั่นสัญญาจะเกิดขึ้นในสัญญาอัจฉริยะของเลเยอร์ 1 Ethereum ซึ่งใช้เพื่อกำหนดกลไกการเลือกผู้นำ **นั่นหมายความว่าเราจำเป็นต้องมีการโต้ตอบโดยที่ผู้สั่งซื้อ L2 จะสอบถาม Ethereum smart contract เพื่อทราบว่าใครจะเป็นผู้นำคนต่อไปหรืออะไรทำนองนั้น เห็นได้ชัดว่าจำเป็นต้องมีการสุ่มบางอย่างและสิ่งอื่น ๆ จึงไม่ใช่คำถามง่ายๆ แต่นั่นเป็นส่วนแรก จากนั้นคุณต้องมีกลไกสำหรับฉันทามติ มีหลายตัวเลือก: กลไกลูกโซ่ที่ยาวที่สุดหรือ BFT หรือลูกผสมของทั้งสองอย่าง เช่นเดียวกับ Ethereum มันมี LMG Ghost และ Casper FFG สำหรับขั้นสุดท้าย
ดังนั้น เราอาจใช้แนวทางปฏิบัติและเริ่มด้วย BFT ก่อน ทำไม เมื่อเลเยอร์ 2 พิจารณาการกระจายอำนาจ เป้าหมายของเราคือไม่ต้องมีตัวเรียงลำดับขนาดใหญ่เช่นเลเยอร์ 1 ตัวอย่างเช่น บน Ethereum เป้าหมายคือการมีผู้ตรวจสอบหลายล้านคนเข้าร่วม ในกรณีนี้ คุณไม่สามารถใช้กลไก BFT ได้ เพราะมันจะมีประสิทธิภาพที่แย่มาก และจะทำให้เกิดปัญหาใหญ่ตามมา ตัวอย่างเช่น หากมีปัญหาในเครือข่าย Bitcoin หากเป็นกลไก BFT ห่วงโซ่จะหยุดทำงานโดยสิ้นเชิง แต่นี่ไม่ใช่กรณี เครือข่าย Bitcoin ยังคงสร้างบล็อกต่อไป มีเพียงกลไกขั้นสุดท้ายเท่านั้นที่ถูกโจมตี
แต่ในเลเยอร์ 2 หากเป้าหมายคือเครื่องคัดแยกไม่กี่ร้อยถึง 1,000 เครื่อง อาจเป็นการดีที่จะเริ่มต้นด้วยกลไก BFT ดังนั้นเราจึงมีกลไกการเลือกผู้นำ แล้วก็ฉันทามติ แล้วก็มีอีกสองส่วน แต่ฉันจะปล่อยให้แขกคนอื่นๆ เพิ่มต่อไป แต่อีกสองส่วนคือการอัปเดตสถานะและการสร้างหลักฐาน
ทางเลือก
ประการแรก ใน L2 การกระจายอำนาจเป็นปัญหาหลายแง่มุมตามที่ Abdel อธิบายไว้ โดยเฉพาะอย่างยิ่งใน zkRollup เนื่องจากมีผู้พิสูจน์และผู้สั่ง คุณต้องประสานงานระหว่างพวกเขา คุณต้องกระจายอำนาจทั้งคู่ ปัญหานี้แตกต่างจาก L1 อย่างสิ้นเชิง
ข้อแตกต่างอีกประการหนึ่งคือใน L2 การออกแบบทั้งหมดของคุณคือการโน้มน้าวใจบริดจ์พื้นฐานว่าฉันทามตินั้นถูกต้อง ไม่ใช่เพื่อโน้มน้าวโหนดอื่นๆ เห็นได้ชัดว่าคุณควรทำเช่นเดียวกัน แต่จุดสนใจหลักของคุณควรเป็นสะพาน
ขณะนี้เรากำลังทำงานในสองทิศทางที่แตกต่างกัน ข้อแรก ฉันคิดว่าเหมือนกับคนอื่นๆ เรากำลังทำงานบนโปรโตคอล BFT สิ่งนี้ไม่ได้มีประสิทธิภาพมากนักและมีจุดบกพร่องบางอย่างที่ต้องแก้ไข เราคิดวิธีแก้ปัญหาคร่าวๆ ได้ แต่ก็ยังไม่ดีที่สุด ตัวอย่างเช่น คำถามข้อหนึ่งคือ คุณจะสร้างสมดุลระหว่างสิ่งจูงใจระหว่างผู้คัดแยกและผู้พิสูจน์ได้อย่างไร เนื่องจากผู้สั่งควบคุม MEV และผู้พิสูจน์ไม่สามารถเข้าถึง MEV ได้ จึงมีสิ่งจูงใจให้ผู้คนเรียกใช้คำสั่งแทนผู้พิสูจน์ แต่ในความเป็นจริง เราต้องการผู้พิสูจน์มากกว่าผู้สั่ง ดังนั้น คุณจะสร้างสมดุลของสิ่งจูงใจระหว่างทั้งสองได้อย่างไร นี่เป็นหนึ่งในปัญหานั้น
แนวทางที่สองที่เรากำลังดำเนินการคือแนวทางอื่น โปรดจำไว้ว่าสิ่งต่าง ๆ อาจเปลี่ยนแปลงได้ ข้อเสนอใหม่ออกมาทุกวัน ตัวอย่างเช่น เมื่อเร็ว ๆ นี้มีการพูดคุยกันมากมายเกี่ยวกับการยกเลิกตามและวิธีที่คุณสามารถจัดจ้างการเรียงลำดับจากภายนอกไปยัง L1 ได้อย่างสมบูรณ์ ทิศทางที่สองคือโดยทั่วไปทิ้งตัวเรียงลำดับทั้งหมดและใช้ตัวสร้างภายนอก ตัวอย่างเช่น ผู้สร้าง ethereum หรือ Flashbots SUAVE เป็นต้น เสนอบล็อกที่สั่งแล้วเรียกใช้ฉันทามติภายในตัวพิสูจน์ ข้อดีคือคุณไม่ต้องจัดการกับสิ่งจูงใจ เพราะโดยพื้นฐานแล้ว คุณสามารถใช้ PBS ภายในโปรโตคอลได้ และสร้างโปรโตคอลที่ง่ายกว่า แต่ข้อเสียคือเนื่องจากเราต้องการผู้พิสูจน์จำนวนมาก (เพราะเราสามารถพิสูจน์พร้อมกันได้) จึงค่อนข้างยากที่จะเรียกใช้โปรโตคอล BFT แบบคลาสสิกกับพวกเขา ดังนั้น คำถามคือคุณจะเพิ่มประสิทธิภาพโปรโตคอล BFT ที่มีอยู่อย่างไรให้ทำงานกับผู้พิสูจน์หลายร้อยหรือหลายพันคน และนั่นไม่ใช่คำถามที่ง่ายที่จะตอบ
การแนะนำฉันทามติ L2 จำเป็นสำหรับผู้สั่งซื้อแบบกระจายอำนาจหรือไม่?
เหยาฉี
ฉันสามารถตอบคำถามนี้ได้คร่าวๆ เนื่องจากเราเพิ่งเปิดตัวสิ่งดังกล่าวเมื่อไม่นานมานี้
ดังนั้นการจะแนะนำฉันทามติไม่ได้ขึ้นอยู่กับว่าเราต้องการหรือไม่ เมื่อคุณมีผู้สั่งซื้อจำนวนมากหรือแม้แต่โหนด คุณต้องทำให้พวกเขาเห็นด้วย ขึ้นอยู่กับสมมติฐานของคุณจริงๆ หากเป็นข้อสันนิษฐานของไบแซนไทน์ เราสามารถใช้ BFT หรือโปรโตคอลฉันทามติของไบแซนไทน์ที่มีอยู่ หากเป็นการตั้งค่าที่ไม่ใช่ไบแซนไทน์ ตัวอย่างเช่น หากเราสันนิษฐานว่าโหนดสามารถออนไลน์และออฟไลน์ได้เท่านั้น และไม่สามารถดำเนินการที่เป็นอันตรายได้ เราก็สามารถใช้โปรโตคอล Raft หรือโปรโตคอลที่สอดคล้องกันอื่นๆ ที่เร็วกว่าได้ แต่ยังไงก็ตาม หากเรามีกลุ่มผู้สั่งซื้อหรือผู้พิสูจน์ หากเราต้องการจัดระเบียบพวกเขาเข้าด้วยกันเพื่อสร้างบล็อกในช่วงระยะเวลาหนึ่ง คุณจะต้องมีระเบียบการที่สอดคล้องกัน
ดังที่ Toghrul และ Abdel เพิ่งกล่าวถึง ผมเชื่อว่ามีข้อเสนอและหัวข้อการวิจัยมากมายเกี่ยวกับวิธีที่เราสามารถนำระบบการสั่งซื้อหรือการพิสูจน์แบบกระจายอำนาจไปใช้ได้ ดังนั้น เนื่องจากเราเพิ่งเปิดตัวเครือข่ายทดสอบสำหรับระบบการยกเลิกหลายตัว (ขณะนี้รองรับเฉพาะการพิสูจน์การฉ้อโกงสำหรับการยกเลิกแบบ Optimistic เท่านั้น) จากประสบการณ์การออกแบบและการใช้งานของเรา จึงมีบางสิ่งที่ฉันสามารถแบ่งปันเกี่ยวกับความยากลำบากได้ ดังที่ Toghrul พูดถึงตอนนี้ ความยากไม่ได้อยู่ที่ Consensus Protocol เอง ความยากที่แท้จริงอยู่ที่สิ่งอื่นนอกเหนือจากนี้ เช่น ส่วนการพิสูจน์ เพราะถ้าเป็นตัวเรียงลำดับเดียว คุณก็ไม่จำเป็นต้องมีโหนดมากมาย เราสามารถคิดว่ามันเป็น EVM ซึ่งเป็นเครื่องเสมือน ดังนั้นเพียงแค่ดึงธุรกรรมและดำเนินการ ทำการเปลี่ยนสถานะ ผู้พิสูจน์มีหน้าที่รับผิดชอบในการสร้างหลักฐานสำหรับการเปลี่ยนสถานะของธุรกรรมชุดก่อนหน้า อย่างไรก็ตาม หากเราเรียกใช้โปรโตคอลที่สอดคล้องกันสำหรับผู้เปรียบเทียบและผู้พิสูจน์เมื่อยกเลิก เราจำเป็นต้องแนะนำตรรกะที่สอดคล้องกันเพิ่มเติมที่นั่น คุณต้องมีระบบพิสูจน์สำหรับระเบียบการฉันทามติ ดังนั้นสิ่งนี้จะแนะนำงานจำนวนมากสำหรับระบบพิสูจน์อักษรในการสร้าง จากนั้นเมื่อคุณสร้างหลักฐานแล้ว คุณสามารถยืนยันได้อย่างง่ายดายบน L1 Ethereum
นั่นเป็นเหตุผลว่าทำไม เมื่อเราเปิดตัวเครือข่ายทดสอบแบบหลายคำสั่งซื้อแรก การยกเลิกในแง่ดีมีข้อดีบางประการในเรื่องนี้ โดยทั่วไป คุณสามารถลดความซับซ้อนของหลายสิ่งหลายอย่าง เช่น ไม่ต้องพิจารณาส่วนพิสูจน์ความถูกต้อง เช่นเดียวกับเรา เราเปรียบเทียบทุกอย่างกับ WASM โดยพื้นฐานแล้ว ในที่สุด มันคือคำสั่ง WASM ดังนั้น การตรวจสอบคำแนะนำ WASM เหล่านี้จึงค่อนข้างง่ายในการตรวจสอบโดยใช้รหัส Solidity หากเราเพิ่งปรับใช้การตีความคำสั่ง WASM ทั้งหมดบน Ethereum
แต่โดยทั่วไปแล้วปัญหาไม่ใช่เรื่องเดียว หากเรามีวิธีแก้ไขปัญหาที่สอดคล้องกันก็จะมีงานอื่นๆ ตามมา ที่ต้องแก้ไขไปพร้อมๆ กัน แน่นอนว่าจะมีปัญหาเกี่ยวกับ MEV เช่น เราจะกระจาย MEV อย่างไรให้เป็นธรรม คุณสามารถกำหนดผู้สั่งและผู้พิสูจน์ทั้งหมดโดยขึ้นอยู่กับว่าพวกเขาสร้างบล็อกหรือตรวจสอบความถูกต้องของบล็อกหรือไม่ แต่ท้ายที่สุดแล้ว มันเป็นการรวมกันของหลาย ๆ ประเด็น ไม่ใช่แค่เรื่องทางเทคนิค แต่รวมถึงแรงจูงใจทางเศรษฐกิจด้วย
และเราต้องจำไว้ว่าที่เสนอ L2 เพราะเราต้องการลดต้นทุนก๊าซลงอย่างมาก เราจึงมีโหนดมากไม่ได้ แม้ในการสร้างการพิสูจน์ L2 อาจมีราคาแพงกว่า L1 ดังนั้นเราจึงจำเป็นต้องหาแนวทางที่สมดุลสำหรับปัญหาประเภทนี้
อับเดลฮามิด
ฉันต้องการเพิ่มอีกจุดหนึ่ง ประการแรก ขณะนี้ยังไม่มีหลักฐานการฉ้อโกงที่ไม่ได้รับอนุญาตจริงสำหรับการยกเลิกในแง่ดี และฉันยังคงเน้นเรื่องนี้ทุกครั้งที่มีโอกาส เพราะสิ่งสำคัญคือต้องซื่อสัตย์เกี่ยวกับเรื่องนี้เมื่อเปรียบเทียบ ดังนั้นพวกมันจึงไม่ใช่ L2 เลย นั่นคือสิ่งแรก
จากนั้นฉันต้องการเพิ่มบางอย่างเกี่ยวกับความไม่ตรงกันระหว่างการเรียงลำดับและการพิสูจน์เพราะมันสำคัญมาก อย่างที่คุณพูด เราต้องการเพิ่มประสิทธิภาพการจัดเรียง เนื่องจากขณะนี้เป็นคอขวดสำหรับโซลูชันทั้งหมด แต่ก็ไม่เป็นไรในบริบทของการจัดเรียงแบบรวมศูนย์ เพราะเรารู้ว่าตัวเรียงลำดับจะสร้างการเปลี่ยนค่าเท่านั้น และเราจะสามารถตรวจสอบได้ แต่จะยากขึ้นในบริบทของการจัดเรียงแบบกระจายอำนาจ เพราะบางทีตัวเรียงลำดับของคุณอาจสร้างสิ่งที่ไม่สามารถตรวจสอบได้ จากนั้นคุณจะต้องจัดการกับสิ่งนั้นในภายหลัง
ในบริบทของการเรียงลำดับแบบรวมศูนย์ เพื่อปรับการเรียงลำดับให้เหมาะสม เนื่องจากเราไม่ต้องสร้างการพิสูจน์ในระหว่างกระบวนการคัดแยก เราสามารถลองทำด้วยความเร็วท้องถิ่นได้ ซึ่งเป็นสิ่งที่เราต้องการทำ แปลภาษาไคโรเป็นภาษาเครื่องระดับต่ำ เช่น LLVM และรันเร็วมากบนตัวเรียงลำดับ จากนั้นคุณสามารถพิสูจน์แบบอะซิงโครนัสได้ และสิ่งที่ยอดเยี่ยมที่สุดเกี่ยวกับการพิสูจน์คือคุณสามารถทำควบคู่กันไปได้ ความขนานใหญ่ทำได้โดยการพิสูจน์ว่าการเรียกซ้ำเป็นไปได้ นั่นเป็นเหตุผลที่เราจะสามารถไล่ตามความเร็วของตัวเรียงลำดับได้ แต่มันเป็นเรื่องยากเมื่อกระจายอำนาจ เนื่องจากเราจำเป็นต้องตรวจสอบให้แน่ใจว่าผู้สั่งซื้อสร้างการเปลี่ยนสถานะที่ถูกต้องเท่านั้น
ทางเลือก
ฉันจะเพิ่มว่าฉันไม่แน่ใจว่า Starknet กำลังทำอะไรอยู่ที่นี่ แต่สำหรับเรา ฉันเดาว่ามันเป็นข้อสันนิษฐานทั่วไปของทุก zkRollup ว่าหากคุณกระจายศูนย์ตัวเรียงลำดับ ระบบพิสูจน์ของคุณจะต้องสามารถจัดการกับแบทช์ที่ไม่ถูกต้องได้ โดยพื้นฐานแล้ว ถ้าคุณส่งชุดงานที่มีลายเซ็นไม่ถูกต้อง คุณต้องสามารถพิสูจน์ได้ว่าสถานะผลลัพธ์นั้นเทียบเท่ากับสถานะเริ่มต้น ดังนั้นจะมีค่าใช้จ่ายอยู่บ้างไม่ทางใดก็ทางหนึ่ง มันเกี่ยวกับวิธีที่คุณลดความน่าจะเป็นของเหตุการณ์นี้ให้น้อยที่สุด
อับเดลฮามิด
ถูกต้องเลย. นั่นเป็นเหตุผลที่เราแนะนำ Sierra ในไคโร 1 เพื่อทำให้ทุกอย่างสามารถตรวจสอบได้ การเป็นตัวแทนระดับกลางนี้จะทำให้มั่นใจได้ว่าทุกโปรแกรมของไคโร 1 สามารถตรวจสอบได้ เพื่อให้เราสามารถรวมธุรกรรมที่ย้อนกลับได้
การยกเลิกตามคืออะไร
เหยาฉี
การรวบรวมตามเดิมมาจากบล็อกโพสต์โดย Justin Drake ในฟอรัม Ethereum หนึ่งในแนวคิดของเขาคือเราสามารถใช้ตัวตรวจสอบ Ethereum บางตัวซ้ำเพื่อตรวจสอบธุรกรรมการยกเลิก ดังนั้นเราไม่ต้องการกลุ่มโหนดแยกต่างหากเพื่อตรวจสอบธุรกรรมการยกเลิกที่แตกต่างกัน โดยเฉพาะอย่างยิ่ง เราจะมีการยกเลิกจำนวนมากในอนาคต รวมทั้งการยกเลิกวัตถุประสงค์ทั่วไปและการยกเลิกเฉพาะแอปพลิเคชันจำนวนมาก ดังนั้น ในกรณีนี้ จะเป็นการดีหากเราสามารถหาสถานที่ทั่วไป เช่น กลุ่มเครื่องมือตรวจสอบความถูกต้องของ Ethereum เพื่อตรวจสอบความถูกต้องของธุรกรรมเหล่านี้
แน่นอนว่านี่เป็นเพียงแนวคิดเท่านั้น เนื่องจากยังทำให้เกิดปัญหาทางเทคนิคมากมาย ตัวอย่างเช่น ในทางทฤษฎี เราอาจกำหนดให้เครื่องมือตรวจสอบความถูกต้องของ Ethereum สามารถตรวจสอบธุรกรรมการยกเลิกได้ แต่เป็นการยากมากที่จะได้รับตรรกะในการตรวจสอบความถูกต้องของการยกเลิกที่รวมหรือฝังอยู่ในโปรโตคอล Ethereum เราเรียกสิ่งนี้ว่าการตรวจสอบในโปรโตคอล ซึ่งต้องมีการฮาร์ดฟอร์กโหนด Ethereum แน่นอน ในกรณีนี้ เราสามารถตรวจสอบธุรกรรมการยกเลิกบางรายการได้ แต่ถ้าเราทำคุณจะเห็นปัญหา มันเหมือนกับว่าเราต้องการให้ L2 เลิกใช้งานเพื่อแบ่งปันแรงกดดันของ Ethereum แต่ท้ายที่สุดแล้ว เรายังคงขอให้ผู้ตรวจสอบความถูกต้องของ Ethereum ดำเนินการบางส่วนที่ถ่ายโอนไปยัง L2 หลายคนพูดถึงว่าเราจะทำสิ่งนี้ได้อย่างไร
จากนั้นเราได้พูดคุยกับ Barnabe นักวิจัยจาก Ethereum Foundation ซึ่งกำลังทำงานเกี่ยวกับ PBS นี่คือข้อเสนอของ Ethereum ซึ่งก็คือการแบ่งงานของผู้ตรวจสอบความถูกต้องออกเป็นหลายบทบาท ผู้สร้างและผู้เสนอ ตอนนี้เรามี Flashbots ที่จะทำหน้าที่เป็นผู้สร้างใน PBS พวกเขาสร้างบล็อกทั้งหมดและส่งไปยังผู้เสนอ Ethereum ดังนั้นเมื่อบล็อกเหล่านี้ถูกบรรจุในเครือข่าย Ethereum ผู้สร้างก็จะได้รับรางวัลเช่นกัน แล้วในกรณีนี้ จะให้รางวัลแก่โปรแกรมตรวจสอบเหล่านี้จากเครือข่าย Ethereum ได้อย่างไร? พวกเขายังรับผิดชอบในการตรวจสอบการยกเลิก
หนึ่งในวิธีแก้ปัญหาคือ "การพักใหม่" ซึ่งคุณอาจเคยได้ยินมามากจาก EigenLayer หรือโปรโตคอลอื่นๆ ผู้ใช้สามารถเดิมพัน ETH อีกครั้งบนเครือข่ายการเรียงลำดับอื่นๆ หรือให้รางวัลแก่ผู้ตรวจสอบความถูกต้องของ Ethereum สำหรับการเรียกใช้ซอฟต์แวร์เพื่อดำเนินการตรวจสอบความถูกต้องสำหรับการยกเลิก ในกรณีนี้ สามารถรับรางวัลได้ทั้งจาก L2 และผ่านโปรโตคอลการเดิมพันใหม่ จนถึงขณะนี้มีข้อเสนอมากมายสำหรับเรื่องนี้ แต่โดยทั่วไปแล้วมันเป็นแนวคิดว่าจะสามารถปรับเปลี่ยนวัตถุประสงค์ของเครื่องมือตรวจสอบความถูกต้องของ Ethereum ที่มีอยู่ได้อย่างไร เราจะนำ ETH ที่มีอยู่กลับมาใช้ใหม่เพื่อช่วยนำระบบ Rollup หรือ L2 ยุคใหม่ได้อย่างไร โดยพื้นฐานแล้วมันเป็นการพยายามทำให้หลาย ๆ อย่างง่ายขึ้นสำหรับโปรเจ็กต์การยกเลิก หากการยกเลิกต้องการตัวเรียงลำดับใหม่ หากพวกเขาต้องการแหล่งหลักประกันใหม่ พวกเขาสามารถนำโครงสร้างพื้นฐานที่มีอยู่หรือหลักประกันที่มีอยู่กลับมาใช้ใหม่ได้ นั่นเป็นเหตุผลว่าทำไมจึงสร้างขึ้นบน Ethereum จากนั้นโครงสร้างพื้นฐานเพิ่มเติมและการปักหลักก็สามารถนำมาใช้ซ้ำได้สำหรับการยกเลิกและ L2 เช่นกัน
ข้อเสียของซีเควนเซอร์ที่ใช้ร่วมกันและการยกเลิกตาม และสถานการณ์การใช้งาน
ทางเลือก
ฉันต้องการบ่นเกี่ยวกับข้อเสนอนี้ ฉันไม่มั่นใจในข้อเสนอที่เกี่ยวข้องกับซีเควนเซอร์ที่ใช้ร่วมกัน แน่นอนว่าพวกเขายังอยู่ในช่วงเริ่มต้น และหากการออกแบบเหล่านี้ดีขึ้นในอนาคต เป็นไปได้ว่าฉันจะสนับสนุนพวกเขา เป็นเพียงว่ารูปแบบปัจจุบันไม่น่าเชื่อถือสำหรับฉัน มีสาเหตุหลายประการ
ประการแรก สำหรับผมแล้ว คุณค่าหลักของตัวเรียงลำดับที่ใช้ร่วมกันคือการอนุญาตให้ผู้ใช้ได้รับความสามารถในการจัดองค์ประกอบอะตอมระหว่างการย้อนกลับเพื่อวัตถุประสงค์ทั่วไป เช่น Scroll หรือ Starknet แต่ปัญหาคือถ้าคุณมีความสามารถในการสลายตัวของอะตอม การควบรวมของคุณจะถือเป็นขั้นสุดท้ายเหมือนกับการควบรวมที่ช้าที่สุดที่คุณรวมเข้าด้วยกัน ดังนั้น สมมติว่า Scroll รวมกับ Optimistic Rollup ระยะเวลาสิ้นสุดของ Scroll จะเป็นเจ็ดวัน ในขณะที่คุณค่าหลักของ ZKRollup คือการบรรลุผลสำเร็จค่อนข้างเร็ว ผู้ใช้สามารถถอนไปที่ L1 ได้ภายในไม่กี่นาที และในกรณีนี้ ให้เลิกทำสิ่งนั้นโดยพื้นฐานแล้ว
ข้อเสียอีกประการหนึ่งคือหากคุณต้องการสิ้นสุดแบบออฟไลน์ คุณต้องรันโหนด L2 และตราบใดที่ข้อมูลที่ส่งไปยังเชนได้รับการสรุปผลโดย L1 คุณจะได้รับขั้นสุดท้ายแบบโลคัลใน L2 หากแต่ละ L2 ที่รวมกันไม่รันโหนดแบบเต็ม แทบจะเป็นไปไม่ได้เลยที่จะบรรลุผลสำเร็จในเครื่อง ซึ่งหมายความว่าการรันระบบนี้อาจมีราคาแพงกว่าการรันระบบอย่าง Solana เนื่องจากคุณมีโหนดแบบเต็มหลายโหนดที่ทำงานพร้อมกัน โดยมีค่าใช้จ่ายของตัวเองและอื่นๆ
ด้วยเหตุผลเหล่านั้น ฉันไม่คิดว่ามันสมเหตุสมผลสำหรับ L2 มันแตกต่างออกไปเล็กน้อยสำหรับ L3 เพราะถ้าใครต้องการสร้างห่วงโซ่เฉพาะแอปพลิเคชันและไม่ต้องการจัดการกับการกระจายอำนาจ สมมติว่าฉันกำลังสร้างเกมและฉันแค่ต้องการจัดการกับการสร้างเกม จากนั้นฉันสามารถจ้างงานกระจายอำนาจจากภายนอกได้ แต่ฉันไม่คิดว่ามันสมเหตุสมผลสำหรับ L2 ในขณะนี้
ฉันก็มีความกังวลเช่นกัน ตัวอย่างเช่น คุณจะแบ่งปันผลกำไรของ MEV กับผู้พิสูจน์ได้อย่างไร เนื่องจากหากไม่พิจารณาปัญหาการจัดสรร โดยทั่วไป L1 จะได้รับผลกำไร MEV ทั้งหมด อีกสิ่งเล็กน้อยคือเวลายืนยันจะเท่ากับเวลายืนยันของ L1 ซึ่งก็คือ 12 นาที ซึ่งไม่สามารถเร็วกว่านี้ได้ ปัญหาอีกประการหนึ่งคือเนื่องจากไม่ได้รับอนุญาต ผู้ค้นหาหลายคนสามารถส่งแบทช์ธุรกรรมพร้อมกันได้ ซึ่งหมายความว่าอาจจบลงด้วยผลลัพธ์ที่รวมศูนย์ เนื่องจากผู้สร้างได้รับแรงจูงใจให้รวมธุรกรรมของพวกเขา หากผู้ค้นหาคนหนึ่งเชื่อมต่อได้ง่ายกว่าคนอื่นๆ ดังนั้น อาจส่งผลให้มี Seeker เพียงรายเดียวที่เสนอกลุ่มสำหรับ L2 ในท้ายที่สุด ซึ่งไม่ใช่ทางออกที่ดีนัก เพราะหากเป็นเช่นนี้ เราจะกลับไปที่สี่เหลี่ยมจัตุรัสโดยพื้นฐานแล้ว
เหยาฉี
ที่น่าสนใจคือ ฉันเพิ่งได้คุยกับ Ben ผู้ก่อตั้ง Espresso เมื่อสัปดาห์ที่แล้ว เราพูดถึงเรื่องนี้บ่อยครั้งในหัวข้อตัวเรียงลำดับที่ใช้ร่วมกัน ตามที่ Toghrul กล่าวถึง ฉันคิดว่ามีความไม่แน่นอนเกี่ยวกับสถานการณ์การใช้งานสำหรับระบบการสั่งซื้อที่ใช้ร่วมกัน สาเหตุหลักเป็นเพราะ L2 สำหรับวัตถุประสงค์ทั่วไป เรามักไม่มีเครื่องคัดแยกจำนวนมากเนื่องจากประสิทธิภาพ ความซับซ้อน และความประหยัด และฉันยังรู้สึกว่าไม่ว่าจะเป็นซีเควนเซอร์ที่ใช้ร่วมกัน การยกเลิกตามหรือการหยุดใหม่ กรณีการใช้งานที่ดีที่สุดส่วนใหญ่จะใช้สำหรับ RAS (การยกเลิกแบบเป็นบริการ) หรือแพลตฟอร์มดังกล่าวที่เราสามารถเผยแพร่การยกเลิกจำนวนมากได้ เราไม่ต้องการเครือข่ายคัดแยกขนาดใหญ่ตามจริง ถ้าไม่มีการเลิกใช้จำนวนมาก การยกเลิกเหล่านี้มีระบบตัวเรียงลำดับของตนเองอยู่แล้ว และมีชุมชนหรือพันธมิตรของตนเองอยู่แล้ว เมื่อมี L2 ทั่วไปเพียงบางส่วนเท่านั้น พวกเขาไม่จำเป็นต้องมีเครือข่ายแยกต่างหากและเป็นบุคคลที่สาม นอกจากนี้ นี่เป็นภาระของเครือข่ายบุคคลที่สาม เนื่องจากคุณต้องปรับแต่งสำหรับแต่ละ L2 และแต่ละ L2 มีสแต็กการทดสอบที่แตกต่างกัน สิ่งนี้ต้องการการเปลี่ยนแปลงมากมายในเครือข่ายของคุณเอง
แต่ในขณะเดียวกัน ดังที่ Toghrul กล่าวถึง ในกรณีการใช้งานพิเศษบางกรณี ตัวอย่างเช่น หากเราต้องการให้มีการทำงานร่วมกันในระดับเครื่องคัดแยก เครื่องคัดแยกที่ใช้ร่วมกันอาจเป็นวิธีที่เป็นไปได้ ตัวอย่างเช่น ใช้ตัวเรียงลำดับเดียวกันสำหรับการยกเลิกหลายรายการ ในกรณีนี้ ตัวเรียงลำดับนี้สามารถจัดการธุรกรรมแบบ cross-rollup เพื่อให้แน่ใจว่า cross-chain atomicity ระหว่าง rollup A, B และ C
แต่คุณยังสามารถเห็นปัญหาที่นี่เมื่อฉันอธิบายสถานการณ์ ถ้าเรามีซีเควนเซอร์ที่ใช้ร่วมกันจำนวนมากจริงๆ พวกมันจะกลายเป็นคอขวดอีกครั้งและกลายเป็นจุดแห่งความล้มเหลวเพียงจุดเดียว เรากำลังให้อำนาจแก่สิ่งที่เรียกว่าคำสั่งที่ใช้ร่วมกันเหล่านี้มากเกินไป พวกเขาเป็นเหมือนเครือข่ายมากขึ้น ควบคุมการเลิกใช้จำนวนมาก สุดท้าย เราต้องหาวิธีกระจายอำนาจของตัวเรียงลำดับที่ใช้ร่วมกันนี้อีกครั้ง
แต่ยังไงก็ตาม ฉันคิดว่ามันเป็นเรื่องดีที่ผู้คนค่อยๆ ค้นพบปัญหามากขึ้นเรื่อยๆ และหาทางออกมากขึ้นเรื่อยๆ สรุปแล้ว เป็นเรื่องน่าตื่นเต้นที่จะได้เห็นว่ามีอะไรใหม่ในด้านนี้ทุกวัน ด้วยโซลูชั่นใหม่ทั้งหมดนี้ อย่างน้อยเราก็มาถูกทางแล้วที่จะกระจายอำนาจในพื้นที่โรลอัพทั้งหมดอย่างแท้จริง
อับเดล
ใช่ ฉันเห็นด้วยกับคุณทั้งคู่ ฉันคิดว่ามันเหมาะสมกว่าสำหรับ Layer3 และ Lisk เพราะพวกเขาไม่ต้องการรับผิดชอบในการจูงใจเครือข่ายแบบกระจายอำนาจอีกต่อไป และจำเป็นต้องหาพันธมิตรเพื่อเริ่มต้นสิ่งต่าง ๆ เช่น ตัวเรียงลำดับ ดังนั้นฉันคิดว่าสำหรับ Lisk มันสมเหตุสมผล แต่เช่นเดียวกับ Toghrul ฉันไม่คิดว่ามันสมเหตุสมผลสำหรับ Layer2 ในตอนนี้
หัวข้อที่ 4
ผู้สั่งซื้อแบบกระจายอำนาจจะมีผลอย่างไรต่อ MEV?
อับเดล
สำหรับ Starknet ในบริบทของการรวมศูนย์ เราไม่ทำ MEV ทุกประเภท และเราใช้รูปแบบมาก่อนได้ก่อน กล่าวคือในบริบทของการกระจายอำนาจ แน่นอนว่า MEV จะเข้ามาเพิ่มเติมในภายหลัง แต่ยังเร็วเกินไปที่จะบอกว่าอัตราส่วนใด เนื่องจากขึ้นอยู่กับการออกแบบกลไกฉันทามติและด้านอื่นๆ ด้วย
ทางเลือก
แต่ประเด็นก็คือ แม้ว่าคุณจะไม่ได้ทำ MEV แต่อาจมี MEV บางอย่างที่ยังคงเกิดขึ้นใน Starknet การกระจายอำนาจด้วยตัวมันเองไม่ได้ลด MEV หรือเพิ่ม MEV อย่างแท้จริง แน่นอน หากคุณใช้โปรโตคอลการสั่งซื้อที่ยุติธรรมหรือการเข้ารหัสเกณฑ์ เช่น ใช่ คุณจะลด MEV ให้เหลือน้อยที่สุด แต่คุณไม่สามารถกำจัดมันได้อย่างสมบูรณ์ ปรัชญาของฉันคือ: ไม่สามารถกำจัด MEV ได้ แต่สมมติว่าคุณกำลังสร้างฉันทามติ BFT หรือสร้างบางสิ่งที่เหนือกว่าฉันทามติ BFT สิ่งนี้ไม่ส่งผลกระทบต่อ MEV เลย MEV ยังคงมีอยู่ ควรเป็นคำถามว่าผู้ค้นหาทำงานร่วมกับตัวเรียงลำดับเพื่อแยก MEV นั้นอย่างไร
เหยาฉี
ปัญหาคือแม้แต่รุ่นที่มาก่อนได้ก่อนก็มีส่วนที่ยุ่งยาก เมื่อเราเปิดเผย mempool ต่อผู้ค้นหาบางคน พวกเขายังคงได้เปรียบที่จะเล่นมากขึ้น ตัวอย่างเช่น สำหรับซีเควนเซอร์ พวกเขาเทียบเท่ากับการรออยู่ที่ประตูสำนักงานของคุณ ดังนั้น ในกรณีนี้ เมื่อพวกเขาเห็นโอกาสในการเก็งกำไรบางประเภท ไม่ใช่แค่การโจมตีแบบ front-running หรือแบบแซนวิช ทันทีที่ผู้ใช้ส่งธุรกรรม พวกเขาสามารถเห็นได้ทันทีใน mempool ดังนั้น พวกเขาสามารถซื้อขายล่วงหน้าได้อย่างรวดเร็ว ดังนั้น พวกเขาจึงได้เปรียบเหนือผู้ค้นหาคนอื่นๆ
แต่ย้อนกลับไปที่การกระจายอำนาจ ฉันคิดว่าส่วนใหญ่เกี่ยวกับการต่อต้านการเซ็นเซอร์ ดังที่เราได้กล่าวไว้ตอนต้น ซีเควนเซอร์จัดการโดยทีม ทีมสามารถบอกได้ว่าพวกเขายุติธรรมกับทุกคน แต่สิ่งนี้ไม่ได้ป้องกันในรหัส ดังนั้น หากเราสามารถมีเครือข่าย P2P ได้ คงจะดีมากหากเรารู้สึกว่าโหนดเหล่านี้ตรวจสอบธุรกรรมของฉัน แล้วเราก็สามารถส่งไปยังโหนดอื่นๆ ได้ ดังนั้นจึงเป็นเรื่องของความยุติธรรมในการประมวลผลธุรกรรมที่ L2
สำหรับ MEV เนื่องจากเมื่อเร็วๆ นี้ นอกจาก MEV ที่สร้างขึ้นในการยกเลิกครั้งเดียวแล้ว ยังมี MEV บางส่วนที่สร้างข้ามสะพานอีกด้วย ในเครือข่ายการคัดแยกที่ค่อนข้างกระจายอำนาจนี้ คุณจะมีโอกาสมากขึ้นในการแยก MEV สมมติว่าเรามีเครือข่ายการสั่งซื้อที่ใช้ร่วมกัน หากคุณสามารถโน้มน้าวให้ผู้สั่งซื้อที่ใช้ร่วมกันจัดลำดับธุรกรรมใหม่ได้ โดยพื้นฐานแล้วคุณจะมีข้อได้เปรียบอย่างมากเหนือคนอื่นๆ
มีข้อดีและข้อเสียสำหรับเครือข่ายซีเควนเซอร์ที่ใช้ร่วมกัน ในด้านบวก เราสามารถกระจายอำนาจของระบบจัดอันดับเพิ่มเติมได้ แต่ในทางกลับกัน ทุกคนมีโอกาสที่จะเป็นผู้คัดแยก ดังนั้นพวกเขาจึงสามารถทำอะไรก็ได้ตามต้องการ และป่าแห่งนี้ก็มืดมิดอีกครั้ง ดังนั้นเราจึงแนะนำการกระจายอำนาจ และจากนั้นเราต้องเผชิญกับปัญหาที่คล้ายกันที่เราเผชิญใน Ethereum นั่นเป็นเหตุผลที่ Flashbots และ Ethereum Foundation ต้องการก้าวไปข้างหน้ากับ PBS แยกผู้เสนอและผู้สร้างออกจากกัน จากนั้นจึงพยายามมีโซลูชันเดียวในด้านผู้สร้าง
ดังนั้นเมื่อเราดูที่ปัญหา มันไม่ใช่แค่ปัญหาเดียว มันไม่ใช่ปัญหาแบบตัวต่อตัวอีกต่อไป แต่เป็นแบบตัวต่อตัวและแบบตัวต่อตัว และอื่นๆ