เส้นทางสู่การทำงานร่วมกันของ Layer-2
หมายเหตุบรรณาธิการ: บทความนี้มาจากผู้ที่ชื่นชอบ Ethereum (ID: ethfans)ผู้ที่ชื่นชอบ Ethereum (ID: ethfans)
, ผู้แต่ง: Tom Brand & Uri Kolodny, แปล: A Jian, พิมพ์ซ้ำโดย Odaily โดยได้รับอนุญาต
สรุปสี่ประโยค
ความสามารถในการทำงานร่วมกันของ Layer-2 หมายความว่าผู้ใช้สามารถย้ายเงินทุนระหว่างระบบ Layer-2 โดยมีแรงเสียดทานน้อยที่สุดใน Layer-1
โซลูชันการทำงานร่วมกันของ Layer-2 ที่กล่าวถึงในบทความนี้ทั้งหมดอิงตาม "องค์ประกอบการเข้ารหัสธุรกรรมแบบมีเงื่อนไข" ที่เราแนะนำไปก่อนหน้านี้
StarkEx 3.0 (คาดว่าจะเปิดตัวในเดือนธันวาคม 2020) จะใช้ธุรกรรมแบบมีเงื่อนไขนอกเครือข่ายเพื่อให้การทำงานร่วมกันระหว่าง Layer-2 ถึง Layer-2 (การถอนที่รวดเร็ว)
พื้นหลัง
พื้นหลัง
โซลูชันการปรับขนาด Layer-2 (L2) กำลังดำเนินไปอย่างรวดเร็ว มีระบบพิสูจน์ความถูกต้องจำนวนมากอยู่แล้วบน Ethereum mainnet และระบบพิสูจน์การฉ้อโกงจำนวนมากได้เปิดตัวบนเครือข่ายทดสอบแล้ว แบบแผน L2 มีความสามารถในการปรับขยายได้ แต่ก็แลกมาด้วยข้อเสีย: ด้วยแบบแผน L2 ประโยชน์บางประการของการทำงานบน L1 ทั้งหมดจะเสียหายหรืออย่างน้อยก็ลดน้อยลง เราไม่เชื่อว่าโซลูชัน L2 หนึ่งเดียวจะสมบูรณ์แบบสำหรับทุกความต้องการ: แอปพลิเคชันที่แตกต่างกันมีความต้องการที่แตกต่างกันมากสำหรับการปรับขนาดปริมาณงาน แอปพลิเคชันจะเลือกสิ่งที่เหมาะสมจากไลบรารีการออกแบบ L2 ที่หลากหลาย
ก่อนจะไปต่อ ขอนิยามคำศัพท์สำคัญสองคำ:
การทำงานร่วมกัน: อนุญาตให้ผู้ใช้โอนเงินอย่างมีประสิทธิภาพระหว่างแอปพลิเคชัน 1 (สภาพแวดล้อมเริ่มต้น) และแอปพลิเคชัน 2 (สภาพแวดล้อมเป้าหมาย)
ความสามารถในการประกอบ: App_1, app_2, ..., app_n สามารถดำเนินการได้ในธุรกรรมเดียว (การเรียบเรียงไม่ใช่หัวข้อของบทความนี้ เราจะพูดถึงในครั้งต่อไป)
นอกจากคำจำกัดความที่ไม่ชัดเจนเหล่านี้แล้ว เรายังต้องการธุรกรรมแบบมีเงื่อนไขที่ได้รับการปรับปรุงอีกด้วย องค์ประกอบที่สำคัญนี้เป็นกุญแจสำคัญในการทำงานร่วมกัน
ข้อความ
เป็นขั้นเป็นตอน
นี่คือองค์ประกอบการเข้ารหัส (ซึ่งเราเสนอเป็นครั้งแรกที่นี่) ที่สามารถใช้เพื่อให้เกิดการทำงานร่วมกันบนบล็อกเชนที่ไม่ไว้วางใจ ธุรกรรมแบบมีเงื่อนไขคือธุรกรรมที่ขึ้นอยู่กับการเกิดขึ้นหรือไม่เกิดขึ้นของเหตุการณ์บางอย่าง (เช่น: การชำระเงินบางอย่าง การเปลี่ยนแปลงสถานะบางอย่าง) เพื่อพิจารณาว่าจะมีผลหรือไม่ แนวคิดพื้นฐานคือ เราสามารถกำหนดธุรกรรมแบบมีเงื่อนไขในสภาพแวดล้อมเริ่มต้น จากนั้นรอให้เงื่อนไขที่ระบุในนั้นเป็นไปตามในสภาพแวดล้อมอื่น (นั่นคือ สภาพแวดล้อมเป้าหมาย) ก่อนที่มันจะมีผล
เป็นขั้นเป็นตอน
ในกรณีที่ไม่มีวิธีแก้ปัญหาที่ดีกว่า อย่างน้อยที่สุดผู้ใช้สามารถโอนเงินจาก L2 เริ่มต้นกลับไปที่ L1 แล้วจึงลงทุนใน L2 เป้าหมาย วิธีหยาบนี้ช้าและมีราคาแพง และจะช้าลงและแพงขึ้นตามความต้องการที่เพิ่มขึ้น
ดังนั้นเราต้องทำให้ดีกว่านี้ อันที่จริง เราวางแผนที่จะทำตามขั้นตอนด้านล่างเพื่อให้ได้วิธีแก้ปัญหาที่ดีขึ้นทีละขั้นตอน
ระยะที่ 1: StarkEx (L2) → Ethereum (L1) — การถอนอย่างรวดเร็ว
ผู้เข้าร่วม:
"การถอนด่วน" สามารถแก้ปัญหาที่ผู้ใช้ต้องการถอนเงินอย่างรวดเร็วจากระบบ StarkEx ไปยัง L1 ไม่เพียงส่งเงินไปยังที่อยู่ L1 ของผู้ใช้เท่านั้น แต่ยังส่งเงินไปยังที่อยู่เป้าหมายของ L1 เช่น Compound, Aave เป็นต้น ที่สำคัญ เวลาแฝงของการถอนของผู้ใช้จะถูกวัดเป็น "เวลาบล็อก" โดยไม่ขึ้นกับความถี่ที่ StarkEx สร้างหลักฐานสำหรับชุดธุรกรรม
สถานการณ์การใช้งาน: Alice ต้องการส่งหมายเลข 1 ในบัญชี dYdX ของเธอใน L2 ไปยังที่อยู่ใน L1
อลิซ (ผู้ใช้ที่มีเงินฝากใน L2)
LP (ผู้ให้บริการสภาพคล่องที่มีกองทุน L1)
ตัวดำเนินการ StarkEx ในสภาพแวดล้อมเริ่มต้น (dYdX ในตัวอย่างข้างต้น)
- รูปที่ 1: ขั้นตอนการถอนด่วน -
Phase II：StarkEx (L2) → StarkEx (L2)
กระบวนการ: (1) ผู้ใช้ส่งธุรกรรมแบบมีเงื่อนไขไปยัง LP โดยสัญญาว่าจะจ่ายส่วนที่ 1 (บวกค่าธรรมเนียมการจัดการของ LP) โดยมีเงื่อนไขว่า LP เรียก 1th ไปยังที่อยู่ L1 ของ Alice ใน L1 หลังจากส่งเงินให้ Alice แล้ว ธุรกรรมแบบมีเงื่อนไขจะมีผล ; (3) LP ส่งธุรกรรมแบบมีเงื่อนไขไปยังผู้ดำเนินการเพื่อรอการบรรจุลงในธุรกรรมชุดถัดไปเพื่อพิสูจน์ (4) รอการพิสูจน์ครั้งต่อไป หลังจากยืนยันกับ L1 และตรวจสอบแล้ว ยอดคงเหลือ L2 ของ LP จะเพิ่มขึ้น เพื่อสะท้อนถึงเงินที่เขาได้รับจากอลิซ
ชื่อเรื่องรอง
ผู้เข้าร่วม:
StarkEx ดั้งเดิมโฮสต์หนึ่งแอปพลิเคชันต่อหนึ่งอินสแตนซ์ ในขั้นตอนนี้ เราต้องการให้ผู้ใช้สามารถย้ายเงินได้อย่างรวดเร็วระหว่างแอปพลิเคชันต่างๆ เหล่านี้ เช่นเดียวกับการถอนเงินที่รวดเร็ว เราหวังว่าจะช่วยให้ผู้ใช้ลดค่าใช้จ่ายในเครือข่ายให้ได้มากที่สุด และไม่ต้องรอให้ธุรกรรมการถอนเงินได้รับการบรรจุและพิสูจน์ใน L2
สถานการณ์การใช้งาน: Alice ต้องการโอนอันดับที่ 1 จากบัญชี dYdX ของเธอบน L2_1 ไปยังบัญชี DeversiFi ของเธอบน L2_2
อลิซ (ผู้ใช้ที่มีเงินฝากใน L2_1)
LP (ผู้ให้บริการสภาพคล่องที่มีกองทุน L2_2)
ตัวดำเนินการ StarkEx ในสภาพแวดล้อมเริ่มต้น (dYdX ในตัวอย่างข้างต้น)
คำอธิบายภาพ
กระบวนการ: (1) Alice ส่งธุรกรรมแบบมีเงื่อนไขที่ลงนามไปยัง LP โดยสัญญาว่าจะจ่ายส่วนที่ 1 (บวกค่าธรรมเนียมการจัดการของ LP) ใน L2_1 โดยมีเงื่อนไขว่า LP จะโอนส่วนที่ 1 ไปยังบัญชี L2_2 ของ Alice ( 2) LP จ่าย Alice ใน L2_2; ( 3) ผู้ดำเนินการของ L2_2 รวบรวมธุรกรรมการชำระเงินเป็นแบทช์และส่งใบรับรองซึ่งได้รับการตรวจสอบบน L1 หลังจากเผยแพร่แบทช์ของธุรกรรมใน L1 ธุรกรรมที่มีเงื่อนไขจะมีผล (4) LP ส่งธุรกรรมที่มีเงื่อนไข ไปยังผู้ดำเนินการของ L2_1 และผู้ดำเนินการรายหลังจะบรรจุลงในชุดถัดไปที่เขาต้องการพิสูจน์ (5) ฯลฯ หลังจากที่มีการเผยแพร่ธุรกรรม L2_1 ชุดถัดไปใน L1 และหลักฐานได้รับการยืนยันโดยสัญญาแล้ว บัญชี ยอดคงเหลือของ LP ใน L2_1 ได้รับการอัปเดตเพื่อให้สอดคล้องกับจำนวน TA ที่ได้รับจากอลิซ
Phase III：L2→ L2
ชื่อเรื่องรองแปลภาษาจีน）
ส่วนขยายตาม Phase II ช่วยให้สามารถโยกย้ายเงินทุนระหว่าง L2 ใดๆ ได้ ไม่ว่าจะเป็นระบบที่ใช้หลักฐานความถูกต้องหรือระบบที่ใช้หลักฐานการฉ้อโกง (Optimistic Rollup, Plasma) สิ่งที่ฉันต้องการเตือนก็คือ (เมื่อเทียบกับ zkRollup) Optimistic Rollup จะมีข้อเสียบางประการในด้านประสิทธิภาพเงินทุนเมื่อใช้ LP เพื่อให้เกิดการทำงานร่วมกัน ซึ่งเป็นสิ่งที่หลีกเลี่ยงไม่ได้ (ดูที่นี่) (
โมเดลความน่าเชื่อถือ
สำหรับผู้ใช้
ชื่อเรื่องรอง
สำหรับผู้ใช้
มันไม่น่าเชื่อถืออย่างสมบูรณ์
ชื่อเรื่องรอง
สำหรับหจก
การต่อต้านการเซ็นเซอร์: ส่งธุรกรรมแบบมีเงื่อนไขที่ถูกเซ็นเซอร์ไปยังสัญญาอัจฉริยะของ "ผู้ดำเนินการ" บนห่วงโซ่ อนุญาตให้ดำเนินการหลังเพื่อระงับผู้ดำเนินการ เพื่อให้หลักฐานที่ส่งโดยผู้ดำเนินการไม่สามารถดำเนินการได้
วางแผน
เงินฝากรักษาความปลอดภัย: ส่งธุรกรรมที่มีเงื่อนไขการตรวจสอบไปยังสัญญาสมาร์ทเงินฝากบนเครือข่ายซึ่งเงินจะได้รับโดยตรง
ชื่อระดับแรก
