Ethereum เป็นคอมพิวเตอร์โลกที่ไม่ได้รับอนุญาตซึ่งมี (เนื้อหา) ความมั่นคงทางเศรษฐกิจจำนวนสูงสุดในขณะที่เขียน โดยทำหน้าที่เป็นบัญชีแยกประเภทการชำระบัญชีสำหรับสินทรัพย์ แอปพลิเคชัน และบริการจำนวนมาก Ethereum มีข้อจำกัด – Blockspace เป็นทรัพยากรที่หายากและมีราคาแพงบน Ethereum Layer One (L1) การปรับขนาดเลเยอร์สอง (L2) ได้รับการมองว่าเป็น วิธีการแก้ปัญหานี้ โดยมีโครงการจำนวนมากออกสู่ตลาดในช่วงไม่กี่ปีที่ผ่านมา โดยส่วนใหญ่อยู่ในรูปแบบของการโรลอัป อย่างไรก็ตาม โรลอัปใน ความหมายที่เข้มงวดของคำนี้ (หมายถึงข้อมูลโรลอัปอยู่บน Ethereum L1) ไม่อนุญาตให้ Ethereum ขยายขนาดอย่างไม่มีกำหนด โดยอนุญาต ให้มีธุรกรรมได้เพียงไม่กี่พันรายการต่อวินาที เท่านั้น
Trust-minimized – (คุณลักษณะของ) ระบบ L2 จะถูกลดความน่าเชื่อถือลง หากทำงานโดยไม่จำเป็นต้องเชื่อถือภายนอกฐาน L1
การปรับขนาดแนวนอน – ระบบสามารถปรับขนาดได้ในแนวนอนหากสามารถเพิ่มอินสแตนซ์ได้โดยไม่ทำให้เกิดปัญหาคอขวดทั่วโลก
ในบทความนี้ เราขอยืนยันว่าระบบที่ลดความน่าเชื่อถือและปรับขนาดได้ในแนวนอนเป็นวิธีการที่มีแนวโน้มมากที่สุดในการปรับขนาดแอปพลิเคชันบล็อกเชน แต่ขณะนี้ยังไม่ค่อยมีการสำรวจ เรานำเสนอข้อโต้แย้งโดยสำรวจคำถามสามข้อ:
(ข้อจำกัดความรับผิดชอบ: แม้ว่าเราจะเน้นที่ Ethereum เป็นฐาน L1 ในบทความนี้ แต่สิ่งที่เราพูดคุยกันในที่นี้ส่วนใหญ่นำไปใช้กับชั้นการชำระเงินแบบกระจายอำนาจนอกเหนือจาก Ethereum)
แอปพลิเคชันสามารถเชื่อมต่อกับ Ethereum ในลักษณะที่เชื่อถือได้ โดยสามารถเขียนและอ่านจากบล็อกเชน Ethereum ได้ แต่ความไว้วางใจนั้นอยู่ที่ผู้ดำเนินการในการดำเนินการตรรกะทางธุรกิจอย่างถูกต้อง การแลกเปลี่ยนแบบรวมศูนย์เช่น Binance และ Coinbase เป็นตัวอย่างที่ดีของแอปพลิเคชันที่เชื่อถือได้ การเชื่อมต่อกับ Ethereum หมายความว่าแอปพลิเคชันสามารถเข้าถึงเครือข่ายการชำระเงินทั่วโลกพร้อมชุดสินทรัพย์ที่หลากหลาย
มีความเสี่ยงที่สำคัญที่เกี่ยวข้องกับบริการนอกเครือข่ายที่เชื่อถือได้ การล่มสลายของการแลกเปลี่ยนและบริการที่สำคัญในปี 2022 เช่น FTX และ เซลเซียส ถือเป็นเรื่องราวเตือนที่ดีถึงสิ่งที่เกิดขึ้นเมื่อบริการที่เชื่อถือได้ทำงานผิดปกติและล้มเหลว
ในทางกลับกัน แอปพลิเคชันลดความน่าเชื่อถือสามารถเขียนและอ่านจาก Ethereum ได้อย่างสามารถตรวจสอบได้ ตัวอย่าง ได้แก่ แอปพลิเคชันสัญญาอัจฉริยะ เช่น Uniswap, Rollup เช่น Arbitrum หรือ zkSync และตัวประมวลผลร่วม เช่น Lagrange และ Axiom โดยทั่วไปแล้ว ความไว้วางใจจะถูกลบออกเมื่อแอปพลิเคชันได้รับการรักษาความปลอดภัยโดยเครือข่าย Ethereum เนื่องจากฟังก์ชันการทำงานเพิ่มเติม (ดูด้านล่าง) ได้รับการว่าจ้างจากภายนอกไปยัง L1 เป็นผลให้สามารถนำเสนอบริการทางการเงินที่ลดความไว้วางใจได้โดยไม่มีความเสี่ยงจากคู่สัญญาหรือผู้ดูแล
มีคุณสมบัติหลักสามประการที่แอปพลิเคชันและบริการสามารถมีได้ ซึ่งสามารถจ้าง L1 จากภายนอกได้:
สำหรับแต่ละคุณสมบัติข้างต้น เราสามารถคิดถึงสมมติฐานของความไว้วางใจที่ต้องการได้ โดยเฉพาะอย่างยิ่ง Eth L1 จัดเตรียมทรัพย์สินหรือจำเป็นต้องมีความไว้วางใจจากภายนอกหรือไม่ ตารางด้านล่างจัดหมวดหมู่สิ่งนี้สำหรับกระบวนทัศน์สถาปัตยกรรมที่แตกต่างกัน
มาตราส่วนแนวนอนหมายถึงมาตราส่วนโดยการเพิ่มอินสแตนซ์อิสระหรือขนานของระบบ เช่น แอปพลิเคชันหรือการยกเลิก สิ่งนี้ไม่จำเป็นต้องมีคอขวดทั่วโลก การปรับสเกลแนวนอนช่วยให้สามารถเติบโตแบบทวีคูณได้
การปรับขนาดแนวตั้งหมายถึงการปรับขนาดโดยการเพิ่มปริมาณงานของระบบขนาดใหญ่ เช่น Eth L1 หรือชั้นความพร้อมใช้งานของข้อมูล เมื่อการปรับขนาดแนวนอนเกิดปัญหาคอขวดบนทรัพยากรที่ใช้ร่วมกัน มักจะจำเป็นต้องมีการปรับขนาดแนวตั้ง
ข้ออ้างที่ 1: การสรุป (ข้อมูลธุรกรรม) ไม่สามารถปรับขนาดในแนวนอนได้ เนื่องจากอาจมีปัญหาคอขวดเนื่องจากความพร้อมใช้งานของข้อมูล (DA) โซลูชัน DA ที่ปรับขนาดในแนวตั้งจำเป็นต้องประนีประนอมกับการกระจายอำนาจ
ความพร้อมใช้งานของข้อมูล (DA) ยังคงเป็นปัญหาคอขวดสำหรับการยกเลิก ปัจจุบัน แต่ละบล็อก L1 มีเป้าหมายขนาดสูงสุด ~1 MB (85 KB/s) ด้วย EIP-4844 จะมีพื้นที่ให้บริการเพิ่มเติม ~2 MB (171 KB/s) (ในระยะยาว) ด้วย Danksharding ในที่สุด Eth L1 อาจรองรับแบนด์วิดท์ DA สูงถึง 1.3 MB/s Eth L1 DA เป็นทรัพยากรที่ใช้ร่วมกันซึ่งแอปพลิเคชันและบริการจำนวนมากแข่งขันกัน ดังนั้น แม้ว่าการใช้ L1 สำหรับ DA จะให้ความปลอดภัยที่ดีที่สุด แต่ก็ทำให้ความสามารถในการปรับขนาดของระบบดังกล่าวติดขัดได้ ระบบที่ใช้ L1 สำหรับ DA (โดยทั่วไป) จะไม่สามารถปรับขนาดในแนวนอนได้ และมี การประหยัดจากขนาด เลเยอร์ DA ทางเลือก เช่น Celestia หรือ EigenDA ก็มีขีดจำกัดแบนด์วิดท์เช่นกัน (แม้ว่าจะใหญ่กว่าที่ 6.67 MB/s และ 15 MB/s ตามลำดับ) แต่มันมาพร้อมกับค่าใช้จ่ายในการเปลี่ยนสมมติฐานความน่าเชื่อถือจาก Ethereum ไปยังเครือข่ายอื่น (ซึ่งมักจะกระจายอำนาจน้อยกว่า) ซึ่งกระทบต่อความปลอดภัย (ทางเศรษฐกิจ)
ข้อเรียกร้องที่ 2: วิธีเดียวที่จะปรับขนาดบริการลดความน่าเชื่อถือในแนวนอนได้คือการได้รับ (ใกล้เคียงกับ) ข้อมูล L1 ส่วนเพิ่มเป็นศูนย์ต่อธุรกรรม แนวทางที่ทราบสองวิธีคือ state-diff rollups (SDR) และ validium
State-diff rollups (SDR) คือโรลอัปที่โพสต์ความแตกต่างของสถานะระหว่างชุดธุรกรรมรวมไปยัง Ethereum L1 สำหรับ EVM เนื่องจากแบทช์ธุรกรรมมีขนาดใหญ่ขึ้น ข้อมูลต่อธุรกรรมที่โพสต์ไปยัง L1 จะลดลงเหลือค่าคงที่ซึ่งน้อยกว่าการรวบรวมข้อมูลธุรกรรมอย่างมาก
ตัวอย่างเช่น ในระหว่างเหตุการณ์การทดสอบความเครียดที่มีคำจารึกจำนวนมากหลั่งไหลเข้ามา zkSync พบว่าข้อมูลการโทรต่อธุรกรรมลดลง เหลือเพียง 10 ไบต์ต่อธุรกรรม ในทางตรงกันข้าม การรวบรวมข้อมูลธุรกรรม เช่น Arbitrum, Optimism และ Polygon zkEVM โดยทั่วไปจะเห็น ประมาณ 100 ไบต์ต่อธุรกรรม สำหรับการรับส่งข้อมูลปกติ
validium คือระบบที่โพสต์หลักฐานความถูกต้องของการเปลี่ยนสถานะเป็น Ethereum โดยไม่มีข้อมูลธุรกรรมหรือสถานะที่เกี่ยวข้อง Validium สามารถปรับขนาดในแนวนอนได้สูง แม้ภายใต้สภาพการรับส่งข้อมูลที่น้อย นี่เป็นเรื่องจริงโดยเฉพาะอย่างยิ่งเนื่องจากการชำระหนี้ของการตรวจสอบความถูกต้องที่แตกต่างกันสามารถนำมารวมกันได้
นอกจากความสามารถในการปรับขนาดในแนวนอนแล้ว validium ยังสามารถให้ความเป็นส่วนตัวแบบ onchain (จากผู้สังเกตการณ์สาธารณะ) การตรวจสอบความถูกต้องพร้อม DA ส่วนตัวมีข้อมูลแบบรวมศูนย์และควบคุม และความพร้อมใช้งานของรัฐ ซึ่งหมายความว่าผู้ใช้จะต้องตรวจสอบสิทธิ์ตนเองก่อนเข้าถึงข้อมูล และผู้ปฏิบัติงานสามารถบังคับใช้มาตรการความเป็นส่วนตัวที่ดีได้ สิ่งนี้ทำให้ผู้ใช้ได้รับประสบการณ์ในระดับที่คล้ายกับเว็บหรือบริการทางการเงินแบบดั้งเดิม กิจกรรมของผู้ใช้จะถูกซ่อนจากการตรวจสอบของสาธารณะ แต่มีผู้ดูแลข้อมูลผู้ใช้ที่เชื่อถือได้ ในกรณีนี้คือผู้ดำเนินการ validium
แล้วซีเควนเซอร์แบบรวมศูนย์และแบบกระจายอำนาจล่ะ? เพื่อให้ระบบสามารถปรับขนาดในแนวนอนได้ สิ่งสำคัญคือต้องสร้างอินสแตนซ์ของตัวเรียงลำดับอิสระ ไม่ว่าจะเป็นแบบรวมศูนย์หรือแบบกระจายอำนาจ โดยเฉพาะอย่างยิ่ง แม้ว่าระบบที่ใช้ซีเควนเซอร์ที่ใช้ร่วมกันจะมี <a href="https://hackmd.io/@EspressoSystems/SharedSequencing"> composability ของอะตอม แต่ก็ไม่สามารถปรับขนาดในแนวนอนได้ เนื่องจากซีเควนเซอร์อาจกลายเป็นคอขวดเมื่อมีการเพิ่มระบบมากขึ้น
แล้วการทำงานร่วมกันล่ะ? ระบบที่ปรับขนาดได้ในแนวนอนสามารถทำงานร่วมกันได้โดยไม่ต้องไว้วางใจเพิ่มเติม หากระบบทั้งหมดใช้ L1 เดียวกัน เนื่องจากสามารถส่งข้อความจากระบบหนึ่งไปยังอีกระบบหนึ่งผ่านเลเยอร์การชำระเงินที่ใช้ร่วมกัน มีข้อดีข้อเสียระหว่างต้นทุนการดำเนินงานและความล่าช้าในการส่งข้อความ (ซึ่งอาจ แก้ไขได้ ที่เลเยอร์แอปพลิเคชัน)
เราสามารถลดข้อกำหนดด้านความน่าเชื่อถือสำหรับความพร้อมใช้งาน การสั่งซื้อ และความพร้อมใช้งานของข้อมูลในระบบที่ปรับขนาดแนวนอนให้เหลือน้อยที่สุดได้หรือไม่
โปรดทราบว่าด้วยต้นทุนของความสามารถในการขยายแนวนอน เรารู้วิธีกอบกู้ความมีชีวิตชีวาที่ไร้ความน่าเชื่อถือและความพร้อมใช้งานของข้อมูล ตัวอย่างเช่น ธุรกรรม L2 สามารถเริ่มต้นได้จาก L1 เพื่อรับประกันการรวม Volition สามารถเสนอความพร้อมในสถานะ L1 ให้กับผู้ใช้ได้
อีกวิธีหนึ่งคือการ กระจายอำนาจ (แต่ไม่ต้องพึ่งพา L1) แทนที่จะใช้ซีเควนเซอร์ตัวเดียว ระบบอาจมีการกระจายอำนาจมากขึ้นโดยการใช้ซีเควนเซอร์แบบกระจายอำนาจ (เช่น Espresso Systems หรือ Astria) ดังนั้น จึงลดความน่าเชื่อถือที่จำเป็นสำหรับความมีชีวิตชีวา การสั่งซื้อ และความพร้อมใช้งานของข้อมูล การทำเช่นนี้ทำให้เกิดข้อจำกัดเมื่อเปรียบเทียบกับโซลูชันของผู้ดำเนินการรายเดียว: (1) ประสิทธิภาพอาจถูกจำกัดโดยประสิทธิภาพของระบบแบบกระจาย และ (2) สำหรับการตรวจสอบความถูกต้องด้วย DA ส่วนตัว การรับประกันความเป็นส่วนตัวเริ่มต้นจะสูญหายไปหากเครือข่ายซีเควนเซอร์แบบกระจายอำนาจไม่ได้รับอนุญาต
เราสามารถลดความไว้วางใจเพิ่มเติมสำหรับการตรวจสอบความถูกต้องหรือ SDR ของผู้ดำเนินการรายเดียวได้มากเพียงใด มีสองทิศทางที่เปิดอยู่ที่นี่
ทิศทางแบบเปิด 1: ความพร้อมใช้งานของข้อมูลที่จำกัดความน่าเชื่อถือในการตรวจสอบความถูกต้อง Plasma แก้ปัญหาความพร้อมใช้งานของสถานะได้ในระดับหนึ่ง โดยแก้ปัญหาได้ทั้งสำหรับการถอนออกเฉพาะสำหรับโมเดลสถานะบางรุ่นเท่านั้น (ซึ่งรวมถึงโมเดลสถานะ UTXO) หรือต้องการให้ผู้ใช้ออนไลน์เป็นระยะ (Plasma Free)
ทิศทางแบบเปิด 2: การยืนยันล่วงหน้าที่รับผิดชอบใน SDR และการตรวจสอบความถูกต้อง เป้าหมายคือเพื่อให้ผู้ใช้ได้รับการยืนยันล่วงหน้าอย่างรวดเร็วเกี่ยวกับการรวมธุรกรรมจากซีเควนเซอร์ และการยืนยันควรอนุญาตให้ผู้ใช้สามารถท้าทายและลดสัดส่วนการถือหุ้นทางเศรษฐกิจของซีเควนเซอร์ หากไม่ปฏิบัติตามสัญญาการรวม ความท้าทายที่นี่คือการพิสูจน์ว่าไม่รวม (จำเป็นสำหรับการตัดอย่างเจ็บแสบ) น่าจะต้องใช้ข้อมูลเพิ่มเติมสำหรับผู้ใช้ ซึ่งซีเควนเซอร์สามารถระงับได้ ดังนั้นจึงมีเหตุผลที่จะสรุปได้ว่าอย่างน้อยที่สุดเราต้องการ SDR หรือ validium เพื่อจ้างคณะกรรมการด้านความพร้อมใช้งานของข้อมูล (อาจได้รับอนุญาต) สำหรับข้อมูลการโทรหรือประวัติการทำธุรกรรมทั้งหมด ซึ่งช่วยให้คณะกรรมการชุดเดียวกันสามารถแสดงหลักฐานการไม่รวม (ของก่อน ธุรกรรมที่ยืนยันแล้ว) ตามคำขอของผู้ใช้
ทิศทางแบบเปิด 3: ฟื้นตัวอย่างรวดเร็วจากความล้มเหลวด้านความมีชีวิตชีวา ระบบปฏิบัติการแบบเดี่ยวอาจประสบกับความล้มเหลวในการใช้งาน (เช่น อนุญาโตตุลาการออฟไลน์ระหว่างกิจกรรมจารึก) เราสามารถออกแบบระบบที่ให้การหยุดชะงักของบริการน้อยที่สุดในสถานการณ์นี้ได้หรือไม่? ในแง่หนึ่ง L2 ที่ยอมให้มีการเรียงลำดับตนเองและข้อเสนอของรัฐจะให้การรับประกันต่อความล้มเหลวในการคงอยู่เป็นเวลานาน การออกแบบระบบผู้ปฏิบัติงานเดี่ยวที่มีความยืดหยุ่นมากขึ้นต่อความล้มเหลวในการใช้งานที่สั้นลงนั้นยังอยู่ระหว่างการสำรวจ แนวทางแก้ไขที่เป็นไปได้วิธีหนึ่งที่นี่คือการทำให้ความล้มเหลวของความมีชีวิตชีวาต้องรับผิดชอบ โดยจัดให้มีการเฉือนต่อความล้มเหลวของความมีชีวิตชีวา แนวทางแก้ไขที่เป็นไปได้อีกประการหนึ่งคือลดระยะเวลาล่าช้าให้สั้นลง (ซึ่งปัจจุบันกำหนดไว้ที่ประมาณหนึ่งสัปดาห์) ก่อนที่จะมีการเทคโอเวอร์เกิดขึ้น
การปรับขนาดบัญชีแยกประเภทการชำระหนี้ทั่วโลกในขณะที่ยังคงรักษาความไว้วางใจให้เหลือน้อยที่สุดนั้นเป็นปัญหาที่ยาก ยังไม่มีความแตกต่างที่ชัดเจนระหว่างการปรับขนาดแนวตั้งและแนวนอนในภาพรวมและความพร้อมใช้งานของข้อมูลในปัจจุบัน หากต้องการปรับขนาดระบบที่ลดความน่าเชื่อถือให้เหลือน้อยที่สุดให้กับทุกคนบนโลก เราจำเป็นต้องสร้างระบบที่ลดความน่าเชื่อถือและปรับขนาดได้ในแนวนอน
ขอขอบคุณ Vitalik Buterin และ Terry Chung มากสำหรับคำติชมและการอภิปราย รวมถึง Diana Biggs สำหรับความคิดเห็นด้านบรรณาธิการของเธอ
声明:
Ethereum เป็นคอมพิวเตอร์โลกที่ไม่ได้รับอนุญาตซึ่งมี (เนื้อหา) ความมั่นคงทางเศรษฐกิจจำนวนสูงสุดในขณะที่เขียน โดยทำหน้าที่เป็นบัญชีแยกประเภทการชำระบัญชีสำหรับสินทรัพย์ แอปพลิเคชัน และบริการจำนวนมาก Ethereum มีข้อจำกัด – Blockspace เป็นทรัพยากรที่หายากและมีราคาแพงบน Ethereum Layer One (L1) การปรับขนาดเลเยอร์สอง (L2) ได้รับการมองว่าเป็น วิธีการแก้ปัญหานี้ โดยมีโครงการจำนวนมากออกสู่ตลาดในช่วงไม่กี่ปีที่ผ่านมา โดยส่วนใหญ่อยู่ในรูปแบบของการโรลอัป อย่างไรก็ตาม โรลอัปใน ความหมายที่เข้มงวดของคำนี้ (หมายถึงข้อมูลโรลอัปอยู่บน Ethereum L1) ไม่อนุญาตให้ Ethereum ขยายขนาดอย่างไม่มีกำหนด โดยอนุญาต ให้มีธุรกรรมได้เพียงไม่กี่พันรายการต่อวินาที เท่านั้น
Trust-minimized – (คุณลักษณะของ) ระบบ L2 จะถูกลดความน่าเชื่อถือลง หากทำงานโดยไม่จำเป็นต้องเชื่อถือภายนอกฐาน L1
การปรับขนาดแนวนอน – ระบบสามารถปรับขนาดได้ในแนวนอนหากสามารถเพิ่มอินสแตนซ์ได้โดยไม่ทำให้เกิดปัญหาคอขวดทั่วโลก
ในบทความนี้ เราขอยืนยันว่าระบบที่ลดความน่าเชื่อถือและปรับขนาดได้ในแนวนอนเป็นวิธีการที่มีแนวโน้มมากที่สุดในการปรับขนาดแอปพลิเคชันบล็อกเชน แต่ขณะนี้ยังไม่ค่อยมีการสำรวจ เรานำเสนอข้อโต้แย้งโดยสำรวจคำถามสามข้อ:
(ข้อจำกัดความรับผิดชอบ: แม้ว่าเราจะเน้นที่ Ethereum เป็นฐาน L1 ในบทความนี้ แต่สิ่งที่เราพูดคุยกันในที่นี้ส่วนใหญ่นำไปใช้กับชั้นการชำระเงินแบบกระจายอำนาจนอกเหนือจาก Ethereum)
แอปพลิเคชันสามารถเชื่อมต่อกับ Ethereum ในลักษณะที่เชื่อถือได้ โดยสามารถเขียนและอ่านจากบล็อกเชน Ethereum ได้ แต่ความไว้วางใจนั้นอยู่ที่ผู้ดำเนินการในการดำเนินการตรรกะทางธุรกิจอย่างถูกต้อง การแลกเปลี่ยนแบบรวมศูนย์เช่น Binance และ Coinbase เป็นตัวอย่างที่ดีของแอปพลิเคชันที่เชื่อถือได้ การเชื่อมต่อกับ Ethereum หมายความว่าแอปพลิเคชันสามารถเข้าถึงเครือข่ายการชำระเงินทั่วโลกพร้อมชุดสินทรัพย์ที่หลากหลาย
มีความเสี่ยงที่สำคัญที่เกี่ยวข้องกับบริการนอกเครือข่ายที่เชื่อถือได้ การล่มสลายของการแลกเปลี่ยนและบริการที่สำคัญในปี 2022 เช่น FTX และ เซลเซียส ถือเป็นเรื่องราวเตือนที่ดีถึงสิ่งที่เกิดขึ้นเมื่อบริการที่เชื่อถือได้ทำงานผิดปกติและล้มเหลว
ในทางกลับกัน แอปพลิเคชันลดความน่าเชื่อถือสามารถเขียนและอ่านจาก Ethereum ได้อย่างสามารถตรวจสอบได้ ตัวอย่าง ได้แก่ แอปพลิเคชันสัญญาอัจฉริยะ เช่น Uniswap, Rollup เช่น Arbitrum หรือ zkSync และตัวประมวลผลร่วม เช่น Lagrange และ Axiom โดยทั่วไปแล้ว ความไว้วางใจจะถูกลบออกเมื่อแอปพลิเคชันได้รับการรักษาความปลอดภัยโดยเครือข่าย Ethereum เนื่องจากฟังก์ชันการทำงานเพิ่มเติม (ดูด้านล่าง) ได้รับการว่าจ้างจากภายนอกไปยัง L1 เป็นผลให้สามารถนำเสนอบริการทางการเงินที่ลดความไว้วางใจได้โดยไม่มีความเสี่ยงจากคู่สัญญาหรือผู้ดูแล
มีคุณสมบัติหลักสามประการที่แอปพลิเคชันและบริการสามารถมีได้ ซึ่งสามารถจ้าง L1 จากภายนอกได้:
สำหรับแต่ละคุณสมบัติข้างต้น เราสามารถคิดถึงสมมติฐานของความไว้วางใจที่ต้องการได้ โดยเฉพาะอย่างยิ่ง Eth L1 จัดเตรียมทรัพย์สินหรือจำเป็นต้องมีความไว้วางใจจากภายนอกหรือไม่ ตารางด้านล่างจัดหมวดหมู่สิ่งนี้สำหรับกระบวนทัศน์สถาปัตยกรรมที่แตกต่างกัน
มาตราส่วนแนวนอนหมายถึงมาตราส่วนโดยการเพิ่มอินสแตนซ์อิสระหรือขนานของระบบ เช่น แอปพลิเคชันหรือการยกเลิก สิ่งนี้ไม่จำเป็นต้องมีคอขวดทั่วโลก การปรับสเกลแนวนอนช่วยให้สามารถเติบโตแบบทวีคูณได้
การปรับขนาดแนวตั้งหมายถึงการปรับขนาดโดยการเพิ่มปริมาณงานของระบบขนาดใหญ่ เช่น Eth L1 หรือชั้นความพร้อมใช้งานของข้อมูล เมื่อการปรับขนาดแนวนอนเกิดปัญหาคอขวดบนทรัพยากรที่ใช้ร่วมกัน มักจะจำเป็นต้องมีการปรับขนาดแนวตั้ง
ข้ออ้างที่ 1: การสรุป (ข้อมูลธุรกรรม) ไม่สามารถปรับขนาดในแนวนอนได้ เนื่องจากอาจมีปัญหาคอขวดเนื่องจากความพร้อมใช้งานของข้อมูล (DA) โซลูชัน DA ที่ปรับขนาดในแนวตั้งจำเป็นต้องประนีประนอมกับการกระจายอำนาจ
ความพร้อมใช้งานของข้อมูล (DA) ยังคงเป็นปัญหาคอขวดสำหรับการยกเลิก ปัจจุบัน แต่ละบล็อก L1 มีเป้าหมายขนาดสูงสุด ~1 MB (85 KB/s) ด้วย EIP-4844 จะมีพื้นที่ให้บริการเพิ่มเติม ~2 MB (171 KB/s) (ในระยะยาว) ด้วย Danksharding ในที่สุด Eth L1 อาจรองรับแบนด์วิดท์ DA สูงถึง 1.3 MB/s Eth L1 DA เป็นทรัพยากรที่ใช้ร่วมกันซึ่งแอปพลิเคชันและบริการจำนวนมากแข่งขันกัน ดังนั้น แม้ว่าการใช้ L1 สำหรับ DA จะให้ความปลอดภัยที่ดีที่สุด แต่ก็ทำให้ความสามารถในการปรับขนาดของระบบดังกล่าวติดขัดได้ ระบบที่ใช้ L1 สำหรับ DA (โดยทั่วไป) จะไม่สามารถปรับขนาดในแนวนอนได้ และมี การประหยัดจากขนาด เลเยอร์ DA ทางเลือก เช่น Celestia หรือ EigenDA ก็มีขีดจำกัดแบนด์วิดท์เช่นกัน (แม้ว่าจะใหญ่กว่าที่ 6.67 MB/s และ 15 MB/s ตามลำดับ) แต่มันมาพร้อมกับค่าใช้จ่ายในการเปลี่ยนสมมติฐานความน่าเชื่อถือจาก Ethereum ไปยังเครือข่ายอื่น (ซึ่งมักจะกระจายอำนาจน้อยกว่า) ซึ่งกระทบต่อความปลอดภัย (ทางเศรษฐกิจ)
ข้อเรียกร้องที่ 2: วิธีเดียวที่จะปรับขนาดบริการลดความน่าเชื่อถือในแนวนอนได้คือการได้รับ (ใกล้เคียงกับ) ข้อมูล L1 ส่วนเพิ่มเป็นศูนย์ต่อธุรกรรม แนวทางที่ทราบสองวิธีคือ state-diff rollups (SDR) และ validium
State-diff rollups (SDR) คือโรลอัปที่โพสต์ความแตกต่างของสถานะระหว่างชุดธุรกรรมรวมไปยัง Ethereum L1 สำหรับ EVM เนื่องจากแบทช์ธุรกรรมมีขนาดใหญ่ขึ้น ข้อมูลต่อธุรกรรมที่โพสต์ไปยัง L1 จะลดลงเหลือค่าคงที่ซึ่งน้อยกว่าการรวบรวมข้อมูลธุรกรรมอย่างมาก
ตัวอย่างเช่น ในระหว่างเหตุการณ์การทดสอบความเครียดที่มีคำจารึกจำนวนมากหลั่งไหลเข้ามา zkSync พบว่าข้อมูลการโทรต่อธุรกรรมลดลง เหลือเพียง 10 ไบต์ต่อธุรกรรม ในทางตรงกันข้าม การรวบรวมข้อมูลธุรกรรม เช่น Arbitrum, Optimism และ Polygon zkEVM โดยทั่วไปจะเห็น ประมาณ 100 ไบต์ต่อธุรกรรม สำหรับการรับส่งข้อมูลปกติ
validium คือระบบที่โพสต์หลักฐานความถูกต้องของการเปลี่ยนสถานะเป็น Ethereum โดยไม่มีข้อมูลธุรกรรมหรือสถานะที่เกี่ยวข้อง Validium สามารถปรับขนาดในแนวนอนได้สูง แม้ภายใต้สภาพการรับส่งข้อมูลที่น้อย นี่เป็นเรื่องจริงโดยเฉพาะอย่างยิ่งเนื่องจากการชำระหนี้ของการตรวจสอบความถูกต้องที่แตกต่างกันสามารถนำมารวมกันได้
นอกจากความสามารถในการปรับขนาดในแนวนอนแล้ว validium ยังสามารถให้ความเป็นส่วนตัวแบบ onchain (จากผู้สังเกตการณ์สาธารณะ) การตรวจสอบความถูกต้องพร้อม DA ส่วนตัวมีข้อมูลแบบรวมศูนย์และควบคุม และความพร้อมใช้งานของรัฐ ซึ่งหมายความว่าผู้ใช้จะต้องตรวจสอบสิทธิ์ตนเองก่อนเข้าถึงข้อมูล และผู้ปฏิบัติงานสามารถบังคับใช้มาตรการความเป็นส่วนตัวที่ดีได้ สิ่งนี้ทำให้ผู้ใช้ได้รับประสบการณ์ในระดับที่คล้ายกับเว็บหรือบริการทางการเงินแบบดั้งเดิม กิจกรรมของผู้ใช้จะถูกซ่อนจากการตรวจสอบของสาธารณะ แต่มีผู้ดูแลข้อมูลผู้ใช้ที่เชื่อถือได้ ในกรณีนี้คือผู้ดำเนินการ validium
แล้วซีเควนเซอร์แบบรวมศูนย์และแบบกระจายอำนาจล่ะ? เพื่อให้ระบบสามารถปรับขนาดในแนวนอนได้ สิ่งสำคัญคือต้องสร้างอินสแตนซ์ของตัวเรียงลำดับอิสระ ไม่ว่าจะเป็นแบบรวมศูนย์หรือแบบกระจายอำนาจ โดยเฉพาะอย่างยิ่ง แม้ว่าระบบที่ใช้ซีเควนเซอร์ที่ใช้ร่วมกันจะมี <a href="https://hackmd.io/@EspressoSystems/SharedSequencing"> composability ของอะตอม แต่ก็ไม่สามารถปรับขนาดในแนวนอนได้ เนื่องจากซีเควนเซอร์อาจกลายเป็นคอขวดเมื่อมีการเพิ่มระบบมากขึ้น
แล้วการทำงานร่วมกันล่ะ? ระบบที่ปรับขนาดได้ในแนวนอนสามารถทำงานร่วมกันได้โดยไม่ต้องไว้วางใจเพิ่มเติม หากระบบทั้งหมดใช้ L1 เดียวกัน เนื่องจากสามารถส่งข้อความจากระบบหนึ่งไปยังอีกระบบหนึ่งผ่านเลเยอร์การชำระเงินที่ใช้ร่วมกัน มีข้อดีข้อเสียระหว่างต้นทุนการดำเนินงานและความล่าช้าในการส่งข้อความ (ซึ่งอาจ แก้ไขได้ ที่เลเยอร์แอปพลิเคชัน)
เราสามารถลดข้อกำหนดด้านความน่าเชื่อถือสำหรับความพร้อมใช้งาน การสั่งซื้อ และความพร้อมใช้งานของข้อมูลในระบบที่ปรับขนาดแนวนอนให้เหลือน้อยที่สุดได้หรือไม่
โปรดทราบว่าด้วยต้นทุนของความสามารถในการขยายแนวนอน เรารู้วิธีกอบกู้ความมีชีวิตชีวาที่ไร้ความน่าเชื่อถือและความพร้อมใช้งานของข้อมูล ตัวอย่างเช่น ธุรกรรม L2 สามารถเริ่มต้นได้จาก L1 เพื่อรับประกันการรวม Volition สามารถเสนอความพร้อมในสถานะ L1 ให้กับผู้ใช้ได้
อีกวิธีหนึ่งคือการ กระจายอำนาจ (แต่ไม่ต้องพึ่งพา L1) แทนที่จะใช้ซีเควนเซอร์ตัวเดียว ระบบอาจมีการกระจายอำนาจมากขึ้นโดยการใช้ซีเควนเซอร์แบบกระจายอำนาจ (เช่น Espresso Systems หรือ Astria) ดังนั้น จึงลดความน่าเชื่อถือที่จำเป็นสำหรับความมีชีวิตชีวา การสั่งซื้อ และความพร้อมใช้งานของข้อมูล การทำเช่นนี้ทำให้เกิดข้อจำกัดเมื่อเปรียบเทียบกับโซลูชันของผู้ดำเนินการรายเดียว: (1) ประสิทธิภาพอาจถูกจำกัดโดยประสิทธิภาพของระบบแบบกระจาย และ (2) สำหรับการตรวจสอบความถูกต้องด้วย DA ส่วนตัว การรับประกันความเป็นส่วนตัวเริ่มต้นจะสูญหายไปหากเครือข่ายซีเควนเซอร์แบบกระจายอำนาจไม่ได้รับอนุญาต
เราสามารถลดความไว้วางใจเพิ่มเติมสำหรับการตรวจสอบความถูกต้องหรือ SDR ของผู้ดำเนินการรายเดียวได้มากเพียงใด มีสองทิศทางที่เปิดอยู่ที่นี่
ทิศทางแบบเปิด 1: ความพร้อมใช้งานของข้อมูลที่จำกัดความน่าเชื่อถือในการตรวจสอบความถูกต้อง Plasma แก้ปัญหาความพร้อมใช้งานของสถานะได้ในระดับหนึ่ง โดยแก้ปัญหาได้ทั้งสำหรับการถอนออกเฉพาะสำหรับโมเดลสถานะบางรุ่นเท่านั้น (ซึ่งรวมถึงโมเดลสถานะ UTXO) หรือต้องการให้ผู้ใช้ออนไลน์เป็นระยะ (Plasma Free)
ทิศทางแบบเปิด 2: การยืนยันล่วงหน้าที่รับผิดชอบใน SDR และการตรวจสอบความถูกต้อง เป้าหมายคือเพื่อให้ผู้ใช้ได้รับการยืนยันล่วงหน้าอย่างรวดเร็วเกี่ยวกับการรวมธุรกรรมจากซีเควนเซอร์ และการยืนยันควรอนุญาตให้ผู้ใช้สามารถท้าทายและลดสัดส่วนการถือหุ้นทางเศรษฐกิจของซีเควนเซอร์ หากไม่ปฏิบัติตามสัญญาการรวม ความท้าทายที่นี่คือการพิสูจน์ว่าไม่รวม (จำเป็นสำหรับการตัดอย่างเจ็บแสบ) น่าจะต้องใช้ข้อมูลเพิ่มเติมสำหรับผู้ใช้ ซึ่งซีเควนเซอร์สามารถระงับได้ ดังนั้นจึงมีเหตุผลที่จะสรุปได้ว่าอย่างน้อยที่สุดเราต้องการ SDR หรือ validium เพื่อจ้างคณะกรรมการด้านความพร้อมใช้งานของข้อมูล (อาจได้รับอนุญาต) สำหรับข้อมูลการโทรหรือประวัติการทำธุรกรรมทั้งหมด ซึ่งช่วยให้คณะกรรมการชุดเดียวกันสามารถแสดงหลักฐานการไม่รวม (ของก่อน ธุรกรรมที่ยืนยันแล้ว) ตามคำขอของผู้ใช้
ทิศทางแบบเปิด 3: ฟื้นตัวอย่างรวดเร็วจากความล้มเหลวด้านความมีชีวิตชีวา ระบบปฏิบัติการแบบเดี่ยวอาจประสบกับความล้มเหลวในการใช้งาน (เช่น อนุญาโตตุลาการออฟไลน์ระหว่างกิจกรรมจารึก) เราสามารถออกแบบระบบที่ให้การหยุดชะงักของบริการน้อยที่สุดในสถานการณ์นี้ได้หรือไม่? ในแง่หนึ่ง L2 ที่ยอมให้มีการเรียงลำดับตนเองและข้อเสนอของรัฐจะให้การรับประกันต่อความล้มเหลวในการคงอยู่เป็นเวลานาน การออกแบบระบบผู้ปฏิบัติงานเดี่ยวที่มีความยืดหยุ่นมากขึ้นต่อความล้มเหลวในการใช้งานที่สั้นลงนั้นยังอยู่ระหว่างการสำรวจ แนวทางแก้ไขที่เป็นไปได้วิธีหนึ่งที่นี่คือการทำให้ความล้มเหลวของความมีชีวิตชีวาต้องรับผิดชอบ โดยจัดให้มีการเฉือนต่อความล้มเหลวของความมีชีวิตชีวา แนวทางแก้ไขที่เป็นไปได้อีกประการหนึ่งคือลดระยะเวลาล่าช้าให้สั้นลง (ซึ่งปัจจุบันกำหนดไว้ที่ประมาณหนึ่งสัปดาห์) ก่อนที่จะมีการเทคโอเวอร์เกิดขึ้น
การปรับขนาดบัญชีแยกประเภทการชำระหนี้ทั่วโลกในขณะที่ยังคงรักษาความไว้วางใจให้เหลือน้อยที่สุดนั้นเป็นปัญหาที่ยาก ยังไม่มีความแตกต่างที่ชัดเจนระหว่างการปรับขนาดแนวตั้งและแนวนอนในภาพรวมและความพร้อมใช้งานของข้อมูลในปัจจุบัน หากต้องการปรับขนาดระบบที่ลดความน่าเชื่อถือให้เหลือน้อยที่สุดให้กับทุกคนบนโลก เราจำเป็นต้องสร้างระบบที่ลดความน่าเชื่อถือและปรับขนาดได้ในแนวนอน
ขอขอบคุณ Vitalik Buterin และ Terry Chung มากสำหรับคำติชมและการอภิปราย รวมถึง Diana Biggs สำหรับความคิดเห็นด้านบรรณาธิการของเธอ
声明: