รุ่งอรุณของโปรโตคอลไฮบริดเลเยอร์ 2
หมายเหตุบรรณาธิการ: บทความนี้มาจากข่าวลูกโซ่ ChainNewsหมายเหตุบรรณาธิการ: บทความนี้มาจาก
ข่าวลูกโซ่ ChainNews
ข่าวลูกโซ่ ChainNews
ผู้เขียน: Vitalik Buterin รวบรวมโดย Lianwen ทำซ้ำโดย Odaily โดยได้รับอนุญาต
โซลูชันการขยาย Ethereum Layer 2 ในปัจจุบัน (ส่วนใหญ่หมายถึงช่องสัญญาณพลาสมาและสถานะ) กำลังเปลี่ยนจากทฤษฎีไปสู่การปฏิบัติ แต่ในขณะเดียวกัน มันก็ชัดเจนมากขึ้นเรื่อย ๆ ว่าเทคโนโลยีเหล่านี้มีความท้าทายโดยธรรมชาติ และยังคงมีระยะห่างจากเทคโนโลยีการขยายตัวของ Ethereum ที่เติบโตเต็มที่
ในระดับใหญ่ Ethereum ประสบความสำเร็จเนื่องจากประสบการณ์ของนักพัฒนาบน Ethereum นั้นยอดเยี่ยม: เขียนโปรแกรม เผยแพร่ และทุกคนสามารถโต้ตอบกับมันได้ ในทางกลับกัน การออกแบบ state channel หรือ Plasma application อาศัยเหตุผลที่ชัดเจนมากมายเกี่ยวกับสิ่งจูงใจและความซับซ้อนของการพัฒนา use-case เฉพาะแอพพลิเคชั่น ช่องทางของรัฐเหมาะสำหรับกรณีการใช้งานเฉพาะ เช่น การชำระเงินที่เกิดซ้ำหลายครั้งระหว่างผู้ค้าสองรายหรือผู้เล่นเกมสองคน (ประสบความสำเร็จใน Celer) แต่กรณีการใช้งานทั่วไปยังดูเป็นเรื่องยาก Plasma (โดยเฉพาะอย่างยิ่ง Plasma Cash) สามารถใช้ในสถานการณ์การชำระเงินได้ แต่มีความท้าทายบางประการในการปรับใช้กรณีการใช้งานทั่วไป: แม้แต่การปรับใช้การแลกเปลี่ยนแบบกระจายอำนาจ ลูกค้าก็ต้องจัดเก็บข้อมูลประวัติมากขึ้น และปรับใช้บน Plasma Ethereum แบบสมาร์ทเอนกประสงค์แบบ Ethereum สัญญาก็ดูเหมือนจะยากมาก
แต่ในเวลาเดียวกัน คลาสโปรโตคอล "semi-Layer 2" ที่ถูกลืมได้ปรากฏขึ้นอีกครั้ง - ประเภทนี้ไม่สามารถปรับปรุงความสามารถในการปรับขนาดได้ แต่สามารถบรรลุโมเดลทั่วไปและปลอดภัยมากขึ้น
ในบล็อกโพสต์ที่เผยแพร่ในปี 2014 ฉันได้แนะนำแนวคิดของ "shadow chain" ซึ่งเป็นสถาปัตยกรรมที่เผยแพร่ข้อมูลบล็อกบนเชน แต่ไม่ได้ตรวจสอบบล็อกตามค่าเริ่มต้น บล็อกจะได้รับการยอมรับอย่างไม่แน่นอนและสรุปผลหลังจากช่วงระยะเวลาหนึ่ง (เช่น สองสัปดาห์หรือมากกว่านั้น) ในช่วงสองสัปดาห์นี้ บล็อกที่ยอมรับชั่วคราวอาจถูกท้าทาย และบล็อกได้รับการยืนยันผ่านการทดสอบ หากบล็อกได้รับการพิสูจน์ว่าไม่ถูกต้อง ในที่สุดเชนที่เป็นที่ตั้งของบล็อกจะได้รับการกู้คืน และเงินประกันของผู้เผยแพร่ต้นฉบับจะ ถูกหักเป็นเบี้ยปรับ สัญญาไม่ได้ติดตามสถานะที่สมบูรณ์ของระบบ เฉพาะสถานะรูท และผู้ใช้เองสามารถประมวลผลข้อมูลที่ส่งไปยังบล็อกเชนตั้งแต่ต้นจนจบเพื่อคำนวณสถานะ
ข้อเสนอล่าสุดที่เรียกว่า ZK Rollup ใช้ ZK-SNARK เพื่อตรวจสอบความถูกต้องของบล็อก แม้ว่าจะไม่มีช่วงท้าทาย แต่ก็สามารถบรรลุผลแบบเดียวกันได้
ด้านบน: กายวิภาคของแพ็คเกจ ZK Rollup ที่เผยแพร่บนเครือข่าย "ธุรกรรมภายใน" หลายร้อยรายการที่ส่งผลต่อสถานะของระบบ ZK Rollup (เช่น ยอดคงเหลือในบัญชี) ถูกบีบอัดลงในแพ็คเกจ ซึ่งบรรจุธุรกรรมภายในแต่ละรายการที่มีขนาดประมาณ 10 ไบต์ และคีย์ที่ใช้พิสูจน์ความถูกต้องสมบูรณ์ของ กระบวนการถ่ายโอนที่เกี่ยวข้อง (ขนาดประมาณ 100-300 ไบต์) SNARK ขนาดประมาณ 100-300 ไบต์
ในกรณีข้างต้น ห่วงโซ่หลักจะใช้ในการตรวจสอบความพร้อมใช้งานของข้อมูล แต่ไม่ได้ (โดยตรง) ตรวจสอบความถูกต้องของบล็อกหรือดำเนินการคำนวณที่สำคัญใดๆ (เว้นแต่จะมีความท้าทายเกิดขึ้น) ดังนั้นเทคโนโลยีนี้จึงไม่มีข้อได้เปรียบหลักในแง่ของการขยายความจุ เนื่องจากภาระข้อมูลในห่วงโซ่จะกลายเป็นคอขวดในที่สุด แต่ก็ปฏิเสธไม่ได้ว่ามันยังคงเป็นวิธีที่สำคัญมาก
ข้อมูลมีราคาถูกกว่าการคำนวณ และมีหลายวิธีในการบีบอัดข้อมูลธุรกรรมอย่างมีนัยสำคัญ ส่วนใหญ่เป็นเพราะข้อมูลส่วนใหญ่ในธุรกรรมเป็นข้อมูลลายเซ็น และลายเซ็นจำนวนมากสามารถบีบอัดเป็นลายเซ็นเดียวผ่านการรวมหลายรูปแบบ ZK Rollup สัญญาว่าจะประมวลผล 500 ธุรกรรมต่อวินาที ซึ่งมีประสิทธิภาพมากกว่า Ethereum ถึง 30 เท่า เนื่องจากบีบอัดแต่ละธุรกรรมให้เหลือเพียง 10 ไบต์ และความถูกต้องของธุรกรรมได้รับการตรวจสอบโดย Zero-knowledge Proof ดังนั้นจึงไม่จำเป็นต้องใช้ลายเซ็น ที่จะรวม ในทางกลับกัน ทรูพุตที่คล้ายคลึงกันสามารถทำได้ใน "shadow chains" โดยใช้ลายเซ็นรวมของ BLS (คล้ายกับ Optimistic Rollup ซึ่งเป็นสถาปัตยกรรมใหม่ที่เพิ่งเปิดตัวโดย Karl Floersch ผู้พัฒนาหลักของ Ethereum Casper) การฮาร์ดฟอร์กของอิสตันบูลที่กำลังจะเกิดขึ้นจะช่วยลดต้นทุนของข้อมูลจาก 68 หน่วยต่อไบต์เป็น 16 หน่วยต่อไบต์ ในขณะเดียวกันก็เพิ่มทรูพุตเป็นสี่เท่า (เช่น มากกว่า 2,000 ธุรกรรมต่อวินาที)
ดังนั้น อะไรคือประโยชน์ของเทคนิค data on-chain เช่น ZK/Optimistic Rollup เมื่อเทียบกับเทคโนโลยี off-chain scaling เช่น Plasma?
ประการแรก ZK/Optimistic Rollup ไม่ต้องการตัวดำเนินการที่ "กึ่งน่าเชื่อถือ" ใน ZK Rollup เนื่องจากความถูกต้องของธุรกรรมได้รับการตรวจสอบโดยหลักฐานการเข้ารหัส ผู้ส่งของแพ็คเกจจึงไม่มีทาง "ทำสิ่งที่ไม่ดี" ได้มากนัก (แน่นอน ตามการตั้งค่าแล้ว ผู้ส่งที่ประสงค์ร้ายอาจทำให้ระบบหยุดชั่วคราว ไม่กี่วินาที แต่นั่นก็สร้างความเสียหายให้กับระบบได้มากพอๆ กัน) ใน Optimistic Rollup ผู้กระทำการที่ประสงค์ร้ายสามารถเผยแพร่ "บล็อกที่ไม่ดี" ได้ แต่ผู้กระทำการรายต่อไปสามารถท้าทายการปิดกั้นนั้นได้ทันทีก่อนที่จะเผยแพร่ของตนเอง ใน ZK Rollup และ Optimistic Rollup ข้อมูลที่เพียงพอจะถูกปล่อยไปยังเชน ทำให้ทุกคนสามารถคำนวณสถานะภายในที่สมบูรณ์ได้ เดลต้าที่ส่งทั้งหมดต้องได้รับการประมวลผลตามลำดับ และไม่มี "การโจมตีแบบหัก ณ ที่จ่าย" ที่ยกเลิกคุณสมบัตินี้ " กล่าวอีกนัยหนึ่ง การเป็นผู้ประกอบการสามารถ "ไม่ได้รับอนุญาต" โดยสิ้นเชิง และเงินฝากที่จำเป็น (เพียง 10 ETH) จะใช้เพื่อวัตถุประสงค์ในการป้องกันสแปมเท่านั้น
ประการที่สอง การนำ Optimistic Rollup ไปใช้งานนั้นมีลักษณะทั่วไปมากขึ้น ฟังก์ชันการเปลี่ยนสถานะในระบบ Optimistic Rollup สามารถใช้ในการคำนวณทั่วไปมากขึ้นภายในขีดจำกัดก๊าซของบล็อกเดียว (รวมถึง Merkle สาขาที่ให้ส่วนสถานะที่จำเป็นในการตรวจสอบการเปลี่ยนแปลง ระยะเวลา). ในทางทฤษฎี ZK Rollup ยังสามารถบรรลุการประมวลผลวัตถุประสงค์ทั่วไปในลักษณะเดียวกัน แต่ในทางปฏิบัติ เป็นเรื่องยากมากที่จะใช้ ZK SNARK สำหรับการประมวลผลวัตถุประสงค์ทั่วไป (เช่น การดำเนินการใน EVM) อย่างน้อยก็จนถึงขณะนี้
ขอย้ำอีกครั้งว่า Optimistic Rollup นั้นง่ายกว่าในการสร้างไคลเอนต์เพราะต้องการโครงสร้างพื้นฐานเครือข่ายเลเยอร์ 2 น้อยกว่า และงานจำนวนมากสามารถทำได้โดยการสแกนบล็อกเชน
อย่างไรก็ตาม อะไรคือข้อดีของ ZK/Optimistic Rollup? ความจริงแล้ว นี่เป็นปัญหาทางเทคนิคขั้นสูง หรือที่เรียกว่าปัญหาความพร้อมใช้งานของข้อมูล (รายละเอียดโปรดดูในเอกสารคำอธิบาย
https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding และวิดีโออธิบาย: https://www.youtube.com/watch?v=OJT_fR7wexw)
โดยทั่วไป มีสองวิธีในการ "โกง" ในระบบเลเยอร์ 2: วิธีแรกคือการเผยแพร่ข้อมูลที่ไม่ถูกต้องไปยังบล็อกเชน และวิธีที่สองคือการไม่เผยแพร่ข้อมูลเลย (ตัวอย่างเช่น ในพลาสมา รากของบล็อกใหม่ของพลาสมา แฮชถูกเผยแพร่บนเชนหลัก แต่เนื้อหาของบล็อกจะไม่เปิดเผยให้ใครทราบ)
การเผยแพร่ข้อมูลที่ไม่ถูกต้องนั้นจัดการได้ง่ายมาก เพราะเมื่อเผยแพร่ข้อมูลบนเครือข่ายแล้ว มีหลายวิธีในการพิจารณาว่าข้อมูลนั้นถูกต้องหรือไม่ และข้อมูลที่ส่งไม่ถูกต้องจะถูกทำเครื่องหมายว่าไม่ถูกต้อง และผู้ส่งจะถูกลงโทษอย่างรุนแรง สำหรับสิ่งนี้. ในทางกลับกัน ข้อมูลที่ไม่พร้อมใช้งานจะจัดการได้ยากกว่า เนื่องจากเป็นไปไม่ได้ที่จะตรวจพบความไม่พร้อมใช้งานแม้ว่าจะถูกท้าทายก็ตาม และเป็นไปไม่ได้ที่จะระบุว่าข้อมูลที่ไม่ได้เผยแพร่เหล่านี้เป็นความผิดของใคร โดยเฉพาะอย่างยิ่งเมื่อข้อมูลถูกเก็บไว้ตามค่าเริ่มต้น แสดงเฉพาะ ตามความต้องการหากกลไกการรับรองความถูกต้องบางอย่างพยายามตรวจสอบความพร้อมใช้งาน สิ่งนี้แสดงให้เห็นในภาวะที่กลืนไม่เข้าคายไม่ออกของ Fisherman ซึ่งในเกมตอบสนองความท้าทายนั้นเป็นไปไม่ได้ที่จะแยกความแตกต่างระหว่างผู้ส่งที่ประสงค์ร้ายและผู้ท้าทายที่ประสงค์ร้าย:
ด้านบน: ภาวะที่กลืนไม่เข้าคายไม่ออกของชาวประมง หากคุณเริ่มดูเฉพาะข้อมูลที่ระบุในเวลา T3 คุณจะไม่มีทางรู้ได้ว่าคุณอยู่ในกรณีที่ 1 หรือกรณีที่ 2 ดังนั้นคุณจึงไม่รู้ว่าความผิดของใคร
พลาสมาและช่องสถานะแก้ปัญหา "ภาวะที่กลืนไม่เข้าคายไม่ออกของชาวประมง" ได้อย่างมีประสิทธิภาพโดยการส่งปัญหาไปยังผู้ใช้: หากคุณเป็นผู้ใช้และตัดสินใจที่จะโต้ตอบกับผู้ใช้รายอื่น (คู่สัญญาในช่องทางของรัฐหรือผู้ดำเนินการในพลาสมา) สมมติว่าผู้ใช้รายนั้น ไม่ส่งข้อมูลที่ควรจะเป็น จากนั้นคุณก็ออกไปและไปยังคู่สัญญา/ผู้ดำเนินการรายถัดไป ข้อเท็จจริงที่ว่าคุณในฐานะผู้ใช้ เป็นเจ้าของข้อมูลก่อนหน้าทั้งหมดและข้อมูลการทำธุรกรรมทั้งหมดที่คุณลงนาม ทำให้คุณสามารถพิสูจน์ในบล็อคเชนได้ว่าคุณเป็นเจ้าของทรัพย์สินในโปรโตคอลเลเยอร์ 2 ดังนั้น จึงนำทรัพย์สินเหล่านั้นออกจากระบบได้อย่างปลอดภัย นอกจากนี้ คุณยังต้องมี (ที่ตกลงกันไว้ก่อนหน้านี้) หลักฐานการปฏิบัติการในการรับทรัพย์สิน และในขณะเดียวกันก็ไม่มีใครสามารถพิสูจน์ได้ว่าคุณส่งทรัพย์สินที่เกี่ยวข้องให้กับผู้อื่น จากนั้นคุณจะได้รับทรัพย์สินนี้
เทคนิคนี้สวยงามจริงๆ แต่ต้องอาศัยสมมติฐานหลัก: แต่ละสถานะของอ็อบเจกต์มี "เจ้าของ" เชิงตรรกะ และสถานะของอ็อบเจกต์จะไม่สามารถเปลี่ยนแปลงได้หากไม่ได้รับความยินยอมจากเจ้าของ ดังนั้น เทคนิคนี้ใช้ได้กับธุรกรรมการชำระเงินตามผลลัพธ์ของธุรกรรมที่ไม่ได้ใช้งาน (UTXO) (แต่ไม่ใช่ธุรกรรมการชำระเงินตามรูปแบบบัญชี เนื่องจากในกรณีนี้ คุณสามารถแก้ไขยอดคงเหลือในบัญชีของผู้อื่นให้สูงขึ้นได้โดยไม่ได้รับความยินยอม ซึ่งเป็นสาเหตุที่พลาสมาของ รูปแบบบัญชีนั้นยากมาก) และยังสามารถใช้ในการแลกเปลี่ยนแบบกระจายอำนาจ แต่แอตทริบิวต์ "เจ้าของ" นี้ยังไม่เพียงพอ แอปพลิเคชันบางตัว (เช่น Uniswap) ไม่มีเจ้าของตามธรรมชาติ และแม้แต่ในแอปพลิเคชันเหล่านั้นที่มี ก็มักจะมีหลายคนที่สามารถแก้ไขวัตถุที่เป็นปัญหาได้อย่างถูกกฎหมาย ไม่มีทางใดที่จะอนุญาตให้บุคคลที่สามตามอำเภอใจถอนสินทรัพย์โดยไม่แนะนำความเป็นไปได้ของการโจมตีแบบ denial of service (DoS) เนื่องจากไม่มีใครสามารถพิสูจน์ได้ว่าผู้ออกหรือผู้ส่งเป็นฝ่ายผิด
นอกจากนี้ Plasma และ State Channel ยังมีปัญหาอื่น ๆ ตามลำดับ สำหรับผู้ใช้ที่ยังไม่ได้เข้าร่วมช่องทางของรัฐ จะไม่อนุญาตให้ทำธุรกรรมนอกเครือข่าย Plasma ต้องการให้ผู้ใช้จัดเก็บข้อมูลประวัติจำนวนมาก ซึ่งจะยิ่งใหญ่ขึ้นเมื่อสินทรัพย์ต่างๆ เชื่อมโยงกัน (ตัวอย่างเช่น เงื่อนไขของการถ่ายโอนสินทรัพย์หนึ่งจะขึ้นอยู่กับการถ่ายโอนสินทรัพย์อื่น เช่นเดียวกับที่มีขั้นตอนเดียว ( single-stage) เช่นเดียวกับที่เกิดขึ้นในการแลกเปลี่ยนแบบกระจายอำนาจด้วยกลไกการสั่งซื้อ)
เนื่องจากเทคโนโลยีเลเยอร์ 2 ของการประมวลผลแบบ data-on-chain-off-chain ไม่มีปัญหาความพร้อมใช้งานของข้อมูล จึงไม่มีจุดอ่อนดังกล่าว ZK Rollups และ Optimistic Rollups ใช้ความระมัดระวังอย่างมากในการใส่ข้อมูลให้เพียงพอบนเครือข่ายเพื่อให้ผู้ใช้สามารถคำนวณสถานะของระบบเลเยอร์ 2 ได้อย่างสมบูรณ์ เพื่อให้มั่นใจว่าหากมีผู้เข้าร่วมคนใดหายไป คนใหม่จะเข้ามาแทนที่ได้อย่างง่ายดาย ปัญหาเดียวของเทคโนโลยีเลเยอร์ 2 คือการตรวจสอบความถูกต้องของการคำนวณโดยไม่ทำการประมวลผลแบบออนไลน์ แต่นั่นเป็นปัญหาที่แก้ไขได้ง่าย ยิ่งไปกว่านั้น การปรับขนาดจะทำให้เกิดประโยชน์มากขึ้น: แต่ละธุรกรรมใน ZK Rollup มีขนาดประมาณ 10 ไบต์ และ Optimistic Rollup สามารถเข้าถึงระดับที่ใกล้เคียงกันได้โดยใช้ลายเซ็นรวม BLS ในทางทฤษฎี สามารถเข้าถึงธุรกรรมได้สูงสุด 500 ธุรกรรมต่อวินาที และหลังจากการอัปเกรดอิสตันบูล หมายเลขตัวบ่งชี้สามารถเข้าถึง 2,000 ธุรกรรมต่อวินาที
แต่ถ้าคุณต้องการความสามารถในการปรับขนาดที่สูงขึ้นล่ะ
ความจริงแล้ว มีจุดกึ่งกลางขนาดใหญ่ระหว่างโปรโตคอลออนลิงก์เลเยอร์ 2 และโปรโตคอลออฟลิงก์เลเยอร์ 2 และโซลูชันแบบไฮบริดจำนวนมากใช้ประโยชน์จากทั้งสองอย่าง ดังตัวอย่างง่ายๆ โดยการเผยแพร่แผนผังการจับคู่คำสั่งซื้อ (น้อยกว่า 4 ไบต์) บนเชน เป็นไปได้ที่จะป้องกันปัญหาการระเบิดของสตอเรจในอดีตของการแลกเปลี่ยนแบบกระจายศูนย์ที่ใช้งานบน Plasma Cash:
ด้านบนซ้าย: ผู้ใช้ Plasma Cash ที่เป็นเจ้าของโทเค็นจำเป็นต้องจัดเก็บข้อมูลประวัติ
ด้านบน: ผู้ใช้ Plasma Cash จำเป็นต้องจัดเก็บข้อมูลประวัติเมื่อเป็นเจ้าของโทเค็น และโทเค็นนั้นได้มาจากการสลับปรมาณู
ด้านบนขวา: ผู้ใช้ Plasma Cash จำเป็นต้องจัดเก็บข้อมูลประวัติหากมีการเผยแพร่การจับคู่คำสั่งซื้อในเครือข่าย
