หวังว่าจะขยายหรือแนวคิดที่ผิด? เหตุใด Layer3 จึงมีความขัดแย้งมาก?
ต้นฉบับ｜Odaily
ผู้เขียน｜อาซูมะ
ข้อโต้แย้งเกี่ยวกับเลเยอร์ 3 ได้ทวีความรุนแรงมากขึ้นในช่วงสองวันที่ผ่านมา
ในอีกด้านหนึ่ง โทเค็นที่เกี่ยวข้องของโครงการตัวแทนเลเยอร์ 3 เช่น Degen Chain ได้รับการเพิ่มขึ้นอย่างน่าประหลาดใจในช่วงไม่กี่วันที่ผ่านมา - DEGEN เองมีการเพิ่มขึ้นรายสัปดาห์สูงถึง 143%; หลังจากที่ Aavegotchi เลือกที่จะแปลงร่างเป็น Base-based Layer เมื่อวันที่ 3 กันยายน GHST ยังรีเฟรชจุดสูงสุดในอดีตอย่างแข็งแกร่ง
แต่ในทางกลับกัน ข้อสงสัยของชุมชนเกี่ยวกับเลเยอร์ 3 ก็เริ่มดังขึ้นเรื่อยๆ Vitalik ออกมาแสดงการต่อต้านเป็นการส่วนตัวในวันนี้:“เลเยอร์ 3 ไม่ได้เพิ่มปริมาณงานอย่างน่าอัศจรรย์”
เมื่อวานเป็นวันเอพริลฟูลส์ และหลายๆ โปรเจ็กต์ก็ให้ความสำคัญกับเรื่องนี้และพูดตลกเกี่ยวกับเลเยอร์ 4 และเลเยอร์ 5 ในลักษณะที่ค่อนข้างล้อเล่น ตัวอย่างเช่น dYdX เคยพูดติดตลกว่า เวอร์ชันใหม่จะถูกสร้างขึ้นโดยใช้ L4 สื่อบางแห่งมองว่าเรื่องตลกดังกล่าวเป็นข่าวด้วยซ้ำ
สมมติฐานความเป็นไปได้สำหรับเลเยอร์ 3
เหตุใด Layer 3 จึงถูกตั้งคำถาม? เหตุใดตรรกะของ Matryoshka ของ Rollup plus Rollup จึงไม่ถูกต้องทางการเมืองเพียงพอ เมื่อพิจารณาจากการอภิปรายในชุมชน จุดสำคัญของข้อสงสัยเกี่ยวกับเลเยอร์ 3 ส่วนใหญ่จะอยู่ที่ ว่าเลเยอร์ 3 มีความสำคัญในการขยายหรือไม่
จากคำจำกัดความคลาสสิกเลเยอร์ 2 มักถูกกำหนดให้เป็นเครือข่ายที่ต้องอาศัยเครือข่ายหลักของ Ethereum สำหรับการชำระเงินและสามารถปรับขนาดได้ โดยการเปรียบเทียบ เลเยอร์ 3 ถูกกำหนดให้เป็นเครือข่ายที่ต้องอาศัยเลเยอร์ 2 สำหรับการชำระเงินและสามารถปรับขนาดได้มากกว่า
ในสภาพแวดล้อมเลเยอร์ 2 สิ่งที่เรียกว่า การใช้ Ethereum เพื่อการชำระหนี้ นั้นถูกนำไปใช้ทางเทคนิคเป็น: บรรจุและบีบอัดข้อมูลธุรกรรมเลเยอร์ 2 จำนวนมาก จากนั้นซิงโครไนซ์กับเครือข่าย Ethereum และผ่าน Calldate (วิธีแก้ปัญหาเบื้องต้น) หรือพื้นที่ข้อมูล Blob (รูปแบบปัจจุบัน) สำหรับการจัดเก็บ
ตามหลักการแล้ว หากตรรกะการชำระบัญชีของเลเยอร์ 2 เป็นไปได้ ตรรกะของเลเยอร์ 3 ที่ใช้เลเยอร์ 2 ในการชำระหนี้ก็ดูเหมือนจะเป็นจริง กลไกการใช้งานทางเทคนิคควรเป็น: การบรรจุและบีบอัดข้อมูลธุรกรรมของเลเยอร์ 3 จำนวนมาก และ แล้วซิงโครไนซ์กับเครือข่าย Layer 2...
เมื่อมาถึงจุดนี้ปัญหาก็เริ่มเกิดขึ้น
เนื่องจากเลเยอร์ 2 เองไม่รับผิดชอบในการยืนยัน จุดสิ้นสุด ของเครือข่าย แต่อาศัย Ethereumตามทฤษฎีแล้ว ข้อมูลเลเยอร์ 3 ควรถูกส่งไปยัง Ethereum ในที่สุด และ Ethereum จะเป็นฝ่ายตัดสินใจขั้นสุดท้าย
สำหรับข้อมูลที่บีบอัดในเลเยอร์ 3 ที่ถูกส่งไปยังเลเยอร์ 2 มีโหมดการส่งที่เป็นไปได้สองโหมด (บีบอัดต่อไปหรือไม่บีบอัดอีกต่อไป) แต่น่าเสียดาย ไม่ว่าโหมดใดจะมีปัญหาบางอย่างในขณะนี้
ความขัดแย้งคู่ของการส่งข้อมูล Layer 3
ประการแรกคือโหมดการส่งที่เป็นไปได้ครั้งแรกข้อมูลที่บีบอัดจะถูกบีบอัดอีกครั้งและส่งไปยังเครือข่ายหลัก Ethereum พร้อมกับข้อมูลธุรกรรมเลเยอร์ 2 อื่นๆ
ฟังดูยอดเยี่ยม แต่ความจริงนั้นโหดร้าย - ไม่
Vitalik เขียนบทความวิเคราะห์เกี่ยวกับ Layer 3 ในปี 2022 Layer 3 แบบไหนที่มีความหมาย?บทความนี้อธิบายว่าทำไมเราไม่สามารถบีบอัดข้อมูลธุรกรรมหลายครั้งได้
Rollup ใช้ชุดของรูปแบบการบีบอัดเพื่อลดปริมาณข้อมูลที่จัดเก็บไว้ในธุรกรรม การถ่ายโอนแบบธรรมดาสามารถบีบอัดได้ตั้งแต่ประมาณ 100 ไบต์ถึงประมาณ 16 ไบต์ และการถ่ายโอน ERC 20 บนลูกโซ่ที่เข้ากันได้กับ EVM สามารถบีบอัดได้ตั้งแต่ประมาณ 180 ไบต์ ถึงประมาณ 23 ไบต์ ธุรกรรม ZK-SNARK สามารถบีบอัดได้ตั้งแต่ประมาณ 600 ไบต์ไปจนถึงประมาณ 80 ไบต์ กรณีทั้งหมดข้างต้นสามารถบรรลุประสิทธิภาพการบีบอัดได้ประมาณ 8 เท่า... อย่างไรก็ตาม เนื่องจาก Rollup ยังคงต้องรักษาความพร้อมใช้งานของข้อมูลในห่วงโซ่เพื่อให้แน่ใจว่าข้อมูลทั้งหมดสามารถเข้าถึงได้และตรวจสอบได้โดยผู้ใช้ เช่น การคำนวณสถานะของ Rollup อย่างอิสระ หรือใน ที่มีอยู่ เมื่อโหนดการตรวจสอบออฟไลน์ มันจะเข้าร่วมเป็นโหนดการตรวจสอบใหม่...ข้อมูลสามารถบีบอัดได้เพียงครั้งเดียว แต่ไม่สามารถบีบอัดซ้ำๆ ได้ซึ่งโดยปกติหมายความว่าเราสามารถใส่ตรรกะของคอมเพรสเซอร์ตัวที่สองลงในตัวแรกได้ ถ้าเป็นไปได้ แต่ก็หมายความว่าเราสามารถบรรลุผลแบบเดียวกันได้ด้วยการบีบอัดเพียงครั้งเดียว ดังนั้น การวางชุดรวมอัปเดตอื่นไว้ด้านบนของชุดรวมอัปเดต จึงไม่มีโซลูชันการขยายกำลังการผลิตที่แท้จริง
พูดง่ายๆ ก็คือ เนื่องจากการพิจารณาถึงความพร้อมใช้งานของข้อมูล จึงมีข้อจำกัดบางประการในการบีบอัดข้อมูลธุรกรรม
ภายใต้ปณิธานนี้หากเราสามารถบรรลุการบีบอัดข้อมูล Layer 3 ได้หลายครั้งโดยการรวมตรรกะของการบีบอัดครั้งที่สองเข้ากับกระบวนการบีบอัดครั้งแรก นั่นหมายความว่า เรายังสามารถทำการบีบอัดข้อมูล Layer 2 หลายรายการได้โดยตรง จากนั้นจึงทำการบีบอัดข้อมูล Layer 2 หลายรายการ เลเยอร์ 3 สามารถสร้างเอฟเฟกต์การขยายแบบเดียวกันได้ แล้วทำไมเราถึงยังต้องการเลเยอร์ 3 อีกด้วย
เหตุผลก็คืออัลกอริธึมการบีบอัดจะลบข้อมูลซ้ำซ้อนออกไปในระดับหนึ่งทำให้ข้อมูลมีขนาดกะทัดรัดมากขึ้น แต่เมื่อลบความซ้ำซ้อนเหล่านี้ออกไปแล้วก็จะบีบอัดข้อมูลที่บีบอัดแล้วอีกครั้งได้ยากขึ้นเพราะจะมีเพียงน้อยลงเรื่อยๆเท่านั้น ความซ้ำซ้อนที่สามารถลบออกได้ ดังนั้นการบีบอัดข้อมูลจึงไม่ใช่กระบวนการที่สามารถทำซ้ำได้อย่างไม่มีที่สิ้นสุด และผลตอบแทนของการบีบอัดก็ลดลง
ต่อไปเราจะดูโหมดการส่งที่เป็นไปได้ครั้งที่สองนั่นคือข้อมูลเลเยอร์ 3 จะไม่ถูกบีบอัดอีกต่อไป แต่จะถูกส่งโดยตรงไปยังเครือข่ายหลักของ Ethereum ร่วมกับธุรกรรมเลเยอร์ 2 อื่นๆ
นี่ก็น่าสับสนเล็กน้อยเช่นกัน เพราะโดยรวมแล้วปัญหาคอขวดหลักที่จำกัดการขยายตัวของระบบนิเวศ Ethereum ในปัจจุบันไม่ใช่การขาดแคลนพื้นที่บล็อกบนเลเยอร์ 2 (รวมถึงเลเยอร์ 3) แต่ความพร้อมใช้งานของข้อมูลที่จำกัดและความสามารถในการรองรับของเครือข่ายหลัก——พื้นที่เก็บข้อมูล Blob ที่ใช้ในการจัดเก็บข้อมูลเลเยอร์ 2 ยังมีจำกัด
Keone Hon ผู้ร่วมก่อตั้ง Monad โพสต์ก่อนหน้านี้ว่าความจุ Blob ปัจจุบันอยู่ที่ประมาณ 3 125 kb Blobs ต่อบล็อก (12 วินาที) ซึ่งเท่ากับ 31.25 kb ต่อวินาที เนื่องจากจำนวนธุรกรรมอยู่ที่ประมาณ 100 ไบต์ (สูงกว่าจำนวนที่ระบุเล็กน้อย) โดย Vitalik) ซึ่งหมายความว่า TPS ที่ใช้ร่วมกันของเลเยอร์ 2 ทั้งหมดอยู่ที่ประมาณ 300
ภายใต้สมมติฐานนี้ เลเยอร์ 2 ทั้งหมด (รวมถึงเลเยอร์ 3) จะต้องอยู่ภายใต้ขีดจำกัดสูงสุดของความพร้อมใช้งานของข้อมูลเดียวกัน นอกจากนี้ยังทำให้เป็นไปไม่ได้ที่จะเสร็จสิ้นการยืนยัน ขั้นสุดท้าย ไม่ว่าเลเยอร์ 2 บวกเลเยอร์ 3 จะจัดเตรียมพื้นที่บล็อกไว้เท่าใด . บางครั้งคุณต้องเข้าแถวทีละคน
นี่คือเหตุผลที่ Vitalik เน้นย้ำว่าเลเยอร์ 3 จะไม่ปรับปรุงการขยายตัวของระบบนิเวศ Ethereum อย่างน่าอัศจรรย์
Layer 3 ไม่มีจุดหมายหรือไม่?
จากการวิเคราะห์ข้างต้น จะเห็นได้ว่าเนื่องจากข้อจำกัดด้านประสิทธิภาพการบีบอัดและขีดจำกัดสูงสุดของความพร้อมใช้งานของข้อมูล เลเยอร์ 3 ในปัจจุบันจึงไม่สามารถให้ผลกระทบที่มีนัยสำคัญในการขยายทั่วไป นี่หมายความว่าเลเยอร์ 3 นั้นเป็น แนวคิดหลอก ล้วนๆ และไม่มีนัยสำคัญในทางปฏิบัติใช่หรือไม่ คำตอบนั้นไม่แน่นอนนัก
สตาร์กแวร์มีจุดเด่นใน การขยายแบบลำดับชั้นจาก L2 เป็น L3》 สรุปทิศทางการพัฒนาที่เป็นไปได้ของเลเยอร์ 3 ตัวอย่างเช่น เลเยอร์ 2 สามารถทำงานเป็นเครือข่ายวัตถุประสงค์ทั่วไปได้ และเลเยอร์ 3 สามารถทำงานเป็นเครือข่ายเฉพาะได้โดยเสริมความแข็งแกร่งให้กับฟังก์ชันการปรับแต่งเอง อีกตัวอย่างหนึ่งคือ เลเยอร์ 2 สามารถมุ่งเน้นไปที่การขยายที่ไม่เชื่อถือ และเลเยอร์ 3 สามารถมุ่งเน้นไปที่การขยายที่ไว้วางใจได้ จากนั้น คุณสามารถมุ่งเน้นไปที่การขยายความไว้วางใจที่อ่อนแอ กล่าวคือ โดยการแนะนำเงื่อนไขความเชื่อถือภายนอกบางอย่างเพื่อจัดการกับปัญหาที่ยากขึ้น เช่น ความพร้อมใช้งานของข้อมูล
สุดท้ายใช้ Vitalik ใน Layer 3 แบบไหนที่มีความหมาย?เรามาจบด้วยคำเดิมใน: “การวาง Rollup อีกอันไว้ด้านบนของ Rollup โดยเฉพาะอย่างยิ่งเมื่อสองชั้นใช้กลไกทางเทคนิคเดียวกันนั้นเห็นได้ชัดว่าเป็นไปไม่ได้ อย่างไรก็ตาม หาก Layer 2 และ Layer 3 มีการออกแบบที่แตกต่างกันและสำหรับเป้าหมายที่แตกต่างกัน สถาปัตยกรรมการขยายแบบสามชั้นดังกล่าวเป็นไปได้
