BTC
ETH
HTX
SOL
BNB
ดูตลาด
简中
繁中
English
日本語
한국어
ภาษาไทย
Tiếng Việt

Vitalik: คู่มือฉบับสมบูรณ์สำหรับ Rollups

ECN以太坊中国
特邀专栏作者
บทความนี้มีประมาณ 9121 คำ การอ่านทั้งหมดใช้เวลาประมาณ 14 นาที
Vitalik เผยแพร่บทวิเคราะห์สั้นๆ เกี่ยวกับโซลูชันการขยายระดับที่สองแบบต่างๆ Optimistic rollup vs. ZK rollup?
สรุปโดย AI
Vitalik เผยแพร่บทวิเคราะห์สั้นๆ เกี่ยวกับโซลูชันการขยายระดับที่สองแบบต่างๆ Optimistic rollup vs. ZK rollup?

ที่มา | Vitalik.ca

ผู้แต่ง | Vitalik Buterin

ผู้แต่ง | Vitalik Buterin

โซลูชัน Rollups เป็นที่นิยมอย่างมากในชุมชน Ethereum และคาดว่าจะกลายเป็นโซลูชันการปรับขนาดที่สำคัญสำหรับ Ethereum ในอนาคต แต่เทคโนโลยีนั้นเป็นอย่างไร? มันให้อะไรกับเราได้บ้าง? เราจะใช้เทคโนโลยีนี้อย่างไร? บทความนี้จะพยายามตอบคำถามสำคัญบางข้อเหล่านี้

ชื่อระดับแรก

ความเป็นมา: การขยายเลเยอร์ 1 และเลเยอร์ 2 คืออะไร

มีสองวิธีในการขยาย blockchain ประการแรกสามารถเพิ่มขีดความสามารถในการทำธุรกรรมของ blockchain ได้ ความท้าทายหลักของเทคโนโลยีนี้คือเมื่อขนาดบล็อกเพิ่มขึ้น บล็อกเชนจะตรวจสอบได้ยากขึ้นเรื่อย ๆ และระดับของการรวมศูนย์จะสูงขึ้นเรื่อย ๆ เพื่อหลีกเลี่ยงความเสี่ยงดังกล่าว นักพัฒนาสามารถปรับปรุงประสิทธิภาพของซอฟต์แวร์ไคลเอนต์ได้ หรือเลือกวิธีอื่นที่ยั่งยืนกว่า: ใช้เทคโนโลยี เช่น sharding เพื่อให้สามารถกระจายการสร้างบล็อกและงานตรวจสอบบนบล็อกเชนไปยังโหนดจำนวนมากได้ (เทคโนโลยีนี้จะนำไปใช้กับ Ethereum ในการอัปเกรด Eth2)

State Channels vs Plasma เทียบกับ Rollups

โซลูชันการปรับสเกลเลเยอร์ 2 สามประเภทหลักคือ: ช่องสถานะ พลาสมา และการยกเลิก เป็นสามกระบวนทัศน์ที่แตกต่างกันซึ่งมีจุดแข็งและจุดอ่อนต่างกัน เราสามารถแบ่งประเภทโซลูชันการขยายเลเยอร์ 2 ทั้งหมดออกเป็นสามประเภทอย่างคร่าว ๆ (แม้ว่าโซลูชันบางอย่างจะมีข้อโต้แย้งในการตั้งชื่อเนื่องจากการจำแนกประเภทที่คลุมเครือ เช่น การตรวจสอบความถูกต้อง)

ชื่อระดับแรก

หลักการของช่องทางของรัฐ

สำหรับข้อมูลเพิ่มเติม โปรดดูที่: https://www.jeffcoleman.ca/state-channels และ statechannels.org

สมมติว่าอลิซให้การเชื่อมต่ออินเทอร์เน็ตแก่บ็อบเพื่อแลกกับการที่บ๊อบจ่ายเงินให้เธอ 0.001 ดอลลาร์ต่อเมกะไบต์ แทนที่จะดำเนินธุรกรรมสำหรับการชำระเงินทุกครั้ง พวกเขาใช้โซลูชันเลเยอร์ 2 ด้านล่าง

ขั้นแรก Bob ฝากเงิน 1 ดอลลาร์ (หรือเทียบเท่าใน ETH หรือ Stablecoins) ในสัญญาอัจฉริยะ Bob ลงนามในตั๋วด้วย "$0.001" (ข้อความนอกเครือข่าย) และส่งไปให้ Alice จึงจะชำระเงินครั้งแรกให้ Alice ได้สำเร็จ สำหรับการชำระเงินครั้งที่สอง Bob เซ็นตั๋วอีกใบที่มี "0.002 ดอลลาร์" แล้วส่งไปให้อลิซ และอื่น ๆ ชำระเงินได้มากเท่าที่คุณต้องการ เมื่อทำธุรกรรมเสร็จแล้ว Alice สามารถโพสต์ตั๋วที่มีมูลค่าสูงสุดไปยังห่วงโซ่และลงนาม สัญญาอัจฉริยะบนเครือข่ายจะตรวจสอบลายเซ็นของอลิซและบ็อบ จากนั้นจึงจ่ายเงินให้อลิซตามจำนวนที่ระบุในบันทึกของบ็อบ และคืนเงินที่เหลือให้บ็อบ

เทคโนโลยีนี้มีประสิทธิภาพ: สามารถปรับสำหรับการชำระเงินแบบสองทาง สำหรับการจัดการความสัมพันธ์แบบสัญญาอัจฉริยะ (เช่น Alice และ Bob ทำสัญญาทางการเงินในช่องทางหนึ่ง) และสำหรับการรวมช่องทาง (เช่น เมื่อ Alice และ Bob, Bob และ ชาร์ลี อลิซและชาร์ลียังสามารถทำธุรกรรมที่ไม่ไว้วางใจได้เมื่อมีช่องทางเปิดระหว่างกัน)

อย่างไรก็ตาม บทบาทของช่องทางรัฐมีจำกัด: ไม่สามารถส่งเงินนอกเครือข่ายไปยังผู้ใช้ที่ไม่ได้เข้าร่วมได้ ช่องทางไม่สามารถเป็นตัวแทนของวัตถุที่ไม่มีเจ้าของที่ชัดเจน (เช่น Uniswap) และหากต้องทำธุรกรรมที่ซับซ้อนมากขึ้น ต้องล็อคเงินทุนจำนวนมากในช่อง

ชื่อระดับแรก

พลาสมาทำงานอย่างไร

http://plasma.io/plasma-deprecated.pdf

Plasma Cash:

https://ethresear.ch/t/plasma-cash-plasma-with-much-less-per-user-data-checking/1298

ดูข้อมูลเพิ่มเติมได้ที่👇

กระดาษพลาสมาที่เก่าแก่ที่สุด:

ผู้ใช้ส่งสินทรัพย์ไปยังสัญญาอัจฉริยะของ Plasma chain เพื่อดำเนินการฝากเงินให้เสร็จสมบูรณ์ Plasma chain กำหนด ID เฉพาะ (เช่น 537) ให้กับสินทรัพย์ ห่วงโซ่พลาสมาทุกเส้นมีตัวดำเนินการ "ตัวดำเนินการ" (ซึ่งสามารถเป็นตัวดำเนินการแบบรวมศูนย์ หลายลายเซ็น หรือบางอย่างที่ซับซ้อนกว่าเช่น PoS/DPoS) ทุกๆ ครั้ง (ซึ่งอาจอยู่ที่ใดก็ได้ตั้งแต่ 15 วินาทีถึงหนึ่งชั่วโมง) ผู้ดำเนินการจะสร้างธุรกรรมรวม (ประกอบด้วยธุรกรรม Plasma ทั้งหมดที่พวกเขารวบรวมนอกเครือข่าย) เพื่อรอการแบทช์

ตัวดำเนินการเหล่านี้จะสร้าง Merkle tree ที่แต่ละดัชนี X ในโครงสร้าง หากมีธุรกรรม รหัสสินทรัพย์ X ของธุรกรรมการโอนจะแสดงขึ้น หากไม่มีธุรกรรม มูลค่าของ leaf จะเป็นศูนย์ จากนั้นพวกเขาจะส่ง Merkle root ของ Merkle tree บนเครือข่ายพร้อมกับสาขา Merkle ของแต่ละดัชนี X ไปยังเจ้าของปัจจุบันของสินทรัพย์

หากผู้ใช้ต้องการถอนเงิน ให้เผยแพร่สาขาของ Merkle ของธุรกรรมที่ส่งทรัพย์สินให้พวกเขาล่าสุด จากนั้นสมาร์ทคอนแทรคจะเริ่มช่วงท้าทาย ซึ่งระหว่างนั้นใครก็ตามสามารถพยายามทำให้การถอนเป็นโมฆะได้โดยใช้สาขา Merkle อื่น ๆ ต้องพิสูจน์อย่างน้อยหนึ่งข้อ: (i) ผู้ส่งไม่ใช่เจ้าของเนื้อหาเมื่อส่ง (ii) ผู้ส่งได้ส่งเนื้อหาไปให้บุคคลอื่นในภายหลัง หากไม่มีใครพิสูจน์ได้ว่าการถอนเงินเป็นการฉ้อโกงภายในระยะเวลาหนึ่ง (เช่น เจ็ดวัน) ผู้ใช้สามารถถอนทรัพย์สินของตนได้

อีกครั้ง ทั้ง Plasma และ Channels มีจุดอ่อนที่สำคัญ: การทำให้ Scheme ทั้งสองมีความปลอดภัยจำเป็นต้องมี "เจ้าของ" ทางตรรกะของวัตถุที่ควบคุมโดยทั้งสองระบบ หากเจ้าของเนื้อหานั้นไม่สนใจเกี่ยวกับเนื้อหาของตน นั่นอาจนำไปสู่การพิสูจน์ว่าเนื้อหานั้นไม่ถูกต้อง สิ่งนี้เป็นที่ยอมรับสำหรับหลาย ๆ แอพพลิเคชั่น แต่เป็นตัวทำลายข้อตกลงสำหรับแอพพลิเคชั่นอื่น ๆ อีกมากมาย (เช่น Uniswap) แม้แต่ระบบที่สถานะของวัตถุสามารถเปลี่ยนแปลงได้โดยไม่ได้รับความยินยอมจากเจ้าของ (เช่น ระบบบัญชีซึ่งคุณสามารถเพิ่มยอดคงเหลือของใครบางคนโดยไม่ได้รับความยินยอมจากพวกเขา) ก็ไม่เหมาะสำหรับ Plasma

Rollups

ซึ่งหมายความว่าเมื่อปรับใช้พลาสมาหรือช่องสัญญาณจริงใดๆ จำเป็นต้องมี "เหตุผลมากมายเกี่ยวกับแอปพลิเคชันเฉพาะ" และไม่สามารถสร้างระบบช่องพลาสมาหรือสถานะที่จำลองสภาพแวดล้อม Ethereum เต็มรูปแบบ (หรือ "EVM") เพื่อแก้ปัญหานี้ แผนการยกเลิกต่างๆ ได้เกิดขึ้น

EthHub on optimistic rollups:

https://docs.ethhub.io/ethereum-roadmap/layer-2-scaling/optimistic_rollups/

ZK rollups:

https://docs.ethhub.io/ethereum-roadmap/layer-2-scaling/zk-rollups/

ชื่อระดับแรก

สำหรับแหล่งข้อมูลอื่น ๆ โปรดดูที่ 👇

คลาสของพลาสมาและแชนเนลเป็นโซลูชันเลเยอร์ 2 ที่ "บริสุทธิ์" ซึ่งย้ายทั้งข้อมูลและการคำนวณออกจากเครือข่าย อย่างไรก็ตาม ประเด็นพื้นฐานของทฤษฎีเกมเกี่ยวกับ "ความพร้อมใช้งานของข้อมูล" หมายความว่าแผนการเหล่านี้ไม่จำเป็นต้องปลอดภัยสำหรับทุกแอปพลิเคชัน โซลูชันพลาสมาและแชนเนลอาศัยความรู้ทั้งหมดเกี่ยวกับสถานะของเจ้าของ แต่สิ่งนี้จะป้องกันไม่ให้โซลูชันดังกล่าวสามารถสรุปได้อย่างสมบูรณ์ Rollups เป็นโซลูชันแบบสองชั้น "ไฮบริด" Rollups ย้ายการคำนวณ (และที่เก็บข้อมูลสถานะ) ออกจากเครือข่าย แต่ใส่ข้อมูลบางอย่างเกี่ยวกับธุรกรรมแต่ละรายการบนเครือข่าย

สิ่งสำคัญคือข้อมูลต้องอยู่บนสายโซ่ (หมายเหตุ: การใส่ข้อมูล "บน IPFS" จะไม่ทำงาน เนื่องจาก IPFS ไม่ได้ให้ความเห็นเป็นเอกฉันท์ว่าข้อมูลใดๆ นั้นพร้อมใช้งานหรือไม่ ข้อมูลนั้นต้องบันทึกบนสายโซ่) การใส่ข้อมูลบนเครือข่ายและเข้าถึงฉันทามติบนข้อมูลช่วยให้ทุกคนสามารถจัดการการดำเนินการทั้งหมดในการยกเลิกภายในเครื่องได้ตามต้องการ ทำให้พวกเขาสามารถตรวจจับการฉ้อโกง เริ่มต้นการถอนเงิน หรือเริ่มการทำธุรกรรมเป็นชุดได้เอง การขาดความพร้อมใช้งานของข้อมูลหมายความว่าผู้ปฏิบัติงานที่เป็นอันตรายหรือออฟไลน์สามารถมีผลกระทบน้อยลง (เช่น พวกเขาไม่สามารถทำให้เกิดความล่าช้าหนึ่งสัปดาห์) การเปิดพื้นที่การออกแบบเพิ่มเติมสำหรับใครก็ตามที่มีอำนาจในการออกแบทช์ของธุรกรรม และทำให้การติดตามง่ายขึ้น .

ที่สำคัญกว่านั้น การขาดความพร้อมใช้งานของข้อมูลหมายความว่าไม่จำเป็นต้องแมปสินทรัพย์กับเจ้าของอีกต่อไป ซึ่งนำเราไปสู่หนึ่งในเหตุผลสำคัญที่ชุมชน Ethereum คาดหวังการโรลอัปมากกว่าโซลูชันการสเกลเลเยอร์ 2 ก่อนหน้านี้: การโรลอัพเป็นแบบทั่วไปทั้งหมด เรายังสามารถเรียกใช้ EVM ในการยกเลิก เพื่อให้แอปพลิเคชัน Ethereum ที่มีอยู่สามารถย้ายไปยังการยกเลิกโดยแทบไม่ต้องเขียนโค้ดใหม่

ชื่อระดับแรก

หลักการของ Rollup คืออะไร?

มีสัญญาอัจฉริยะในห่วงโซ่ ซึ่งมีสถานะรูท ซึ่งเป็นราก Merkle ของสถานะการยกเลิก (นั่นคือ ยอดเงินในบัญชี รหัสสัญญา ฯลฯ ภายในการยกเลิก)

ทุกคนสามารถเผยแพร่ชุดของธุรกรรมแบบรวม (แบทช์) ซึ่งเป็นชุดของธุรกรรมที่มีการบีบอัดสูงซึ่งมีรูทสถานะก่อนหน้าและรูทสถานะใหม่ (รูท Merkle ใหม่หลังจากประมวลผลธุรกรรม) สัญญาจะตรวจสอบว่ารูทสถานะเก่าในชุดงานตรงกับรูทสถานะปัจจุบันหรือไม่ และหากตรงกัน สัญญาจะอัปเดตรูทสถานะ

เพื่อรองรับการฝากและถอน เราได้เพิ่มความสามารถในการนำเข้าและส่งออกธุรกรรมที่อยู่ "นอก" สถานะการยกเลิก หากแบทช์มีอินพุตจากภายนอก ธุรกรรมที่ส่งไปยังแบทช์จำเป็นต้องโอนสินทรัพย์ไปยังสัญญารวม หากแบทช์มีเอาต์พุตจากภายนอก สัญญาอัจฉริยะจะเริ่มการถอนเมื่อประมวลผลแบทช์

นี่คือวิธีการทำงานของการยกเลิก แต่มีรายละเอียดที่สำคัญอีกอย่างหนึ่ง: เราจะรู้ได้อย่างไรว่ารูทของ post-state ในแบทช์นั้นถูกต้อง หากมีใครสามารถส่งแบทช์ที่มีรูท post-state ตามอำเภอใจโดยไม่มีผลกระทบใด ๆ พวกเขาสามารถโอนโทเค็นทั้งหมดในการยกเลิกให้ตัวเองได้ คำถามนี้มีความสำคัญเนื่องจากนำไปสู่การแก้ปัญหาที่แตกต่างกัน 2 วิธี ซึ่งจะนำไปสู่การยกเลิก 2 ครั้งที่แตกต่างกัน

การยกเลิกในแง่ดีและการยกเลิก ZK

การยกเลิกสองครั้งคือ:

1. การเลิกใช้ในแง่ดี ซึ่งวิธีแก้ปัญหาคือการพิสูจน์การฉ้อโกง: การเลิกใช้ประเภทนี้จะติดตามรากของสถานะในอดีตทั้งหมดและค่าแฮชสำหรับแต่ละชุด ถ้าใครพบว่ารูทหลังสถานะของแบทช์หนึ่งไม่ถูกต้อง เขาสามารถโพสต์หลักฐานไปยังบล็อกเชนว่าแบทช์นั้นคำนวณผิด สัญญาจะตรวจสอบหลักฐานและย้อนกลับแบทช์และแบทช์ที่ตามมา

มีการแลกเปลี่ยนที่ซับซ้อนระหว่างการยกเลิกสองประเภทนี้:

โดยทั่วไปแล้ว ความเห็นส่วนตัวของฉันคือในระยะสั้น ข้อได้เปรียบที่สำคัญของการยกเลิกในแง่ดีนั้นอยู่ที่การคำนวณ EVM ที่มีจุดประสงค์ทั่วไป ในขณะที่การยกเลิก ZK มีแนวโน้มที่จะใช้สำหรับการชำระเงิน การทำธุรกรรม และกรณีการใช้งานเฉพาะอื่นๆ แต่ในระยะกลางและระยะยาว ด้วยความสมบูรณ์ของเทคโนโลยี ZK-SNARK การยกเลิก ZK จะได้เปรียบในทุกกรณีการใช้งาน

ชื่อระดับแรก

การแยกโครงสร้างหลักฐานการฉ้อโกง

ในแผนภาพด้านบน หลักฐานการฉ้อโกงที่อ้างว่าแบทช์ไม่ถูกต้องจะมีข้อมูลเป็นสีเขียว: จำเป็นต้องมีแบทช์เอง (ตรงกันข้ามกับแฮชที่เก็บไว้บนเครือข่ายเพื่อตรวจสอบ) และบางส่วนของ Merkle tree โหนดสีเหลืองในกราฟไม่จำเป็นต้องระบุ เนื่องจากโหนดสีเขียวสามารถสร้างขึ้นใหม่ได้ ข้อมูลนี้เพียงพอที่จะดำเนินการแบทช์และคำนวณรูทหลังสถานะ (ซึ่งเป็นวิธีเดียวกับที่ไคลเอนต์ไร้สัญชาติตรวจสอบบล็อกเดียว) หากรูทหลังสถานะที่คำนวณไม่สอดคล้องกับรูทหลังสถานะในชุดงานที่ได้รับ แสดงว่าชุดนั้นไม่ถูกต้อง

รับประกันได้ว่าหากแบทช์ไม่ถูกต้อง แต่แบทช์ก่อนหน้านี้ทั้งหมดถูกต้อง สามารถสร้างหลักฐานการฉ้อโกงเพื่อระบุว่าแบทช์ไม่ถูกต้อง โปรดสังเกตการประกาศของชุดงานก่อนหน้า: หากมีการเผยแพร่ชุดงานที่ไม่ถูกต้องมากกว่าหนึ่งชุดในการยกเลิก วิธีที่ดีที่สุดคือพยายามพิสูจน์ชุดงานแรกสุดที่ไม่ถูกต้อง อาจกล่าวได้ว่าหากแบทช์ถูกต้อง จะไม่สามารถสร้างหลักฐานการฉ้อโกงเพื่อทำให้เป็นโมฆะได้

ชื่อระดับแรก

วิธีการบีบอัด?

ธุรกรรม Ethereum อย่างง่าย (ส่ง ETH) มีขนาดประมาณ 110 ไบต์ อย่างไรก็ตาม สำหรับการถ่ายโอน ETH เมื่อยกเลิก จะมีขนาดประมาณ 12 ไบต์เท่านั้น:

ส่วนหนึ่งของสิ่งนี้เป็นเพียงการเข้ารหัสระดับสูง: การเข้ารหัส RLP ของ Ethereum เสีย 1 ไบต์ต่อค่า แต่ยังรวมถึงเทคนิคการบีบอัดที่ชาญฉลาด:

➤ Nonce: จุดประสงค์หลักของพารามิเตอร์นี้คือเพื่อป้องกันการโจมตีซ้ำ หาก nonce ปัจจุบันของบัญชีเป็น 5 ธุรกรรมถัดไปสำหรับบัญชีนั้นต้องมี nonce 5 แต่ทันทีที่ประมวลผลธุรกรรม nonce ในบัญชีนั้นจะเพิ่มขึ้นเป็น 6 ดังนั้นธุรกรรมจึงไม่สามารถดำเนินการได้อีก ในการยกเลิก เราสามารถละเว้น nonce ได้ทั้งหมด เนื่องจากเราสามารถกู้คืน nonce ได้โดยตรงจากสถานะก่อนหน้า ถ้ามีคนพยายามเล่นธุรกรรมซ้ำกับ nonce ก่อนหน้า ลายเซ็นจะไม่สามารถตรวจสอบได้ เนื่องจากข้อมูลที่มี nonce สูงกว่าจะขึ้นอยู่กับ เพื่อตรวจสอบลายเซ็น

➤ Gasprice: เราสามารถอนุญาตให้ผู้ใช้จ่ายในช่วงราคาก๊าซคงที่ เช่น 2 ยกกำลัง 16 หรือเราสามารถเรียกเก็บค่าธรรมเนียมก๊าซคงที่ในแต่ละแบทช์ หรือแม้กระทั่งย้ายการชำระค่าธรรมเนียมก๊าซออกจากโปรโตคอลการยกเลิกทั้งหมด และให้ผู้ค้าใช้ช่องทางเพื่อชำระค่าธรรมเนียมที่เกี่ยวข้องให้กับผู้สร้างแบทช์

➤ แก๊ส: ในทำนองเดียวกัน เราสามารถตั้งค่าแก๊สรวมเป็นหลายกำลังของ 2 หรือเรายังจำกัดปริมาณก๊าซไว้ที่ระดับแบทช์

➤ ถึง: คุณสามารถใช้ดัชนีเพื่อแทนที่แอดเดรสขนาด 20 ไบต์ (เช่น หากแอดเดรสเป็นแอดเดรส 4527 ที่เพิ่มในแผนผัง Merkle เราจำเป็นต้องใช้ดัชนี 4527 เพื่อแทนแอดเดรสเท่านั้น จากนั้นเพิ่ม "ทรีย่อย" (ทรีย่อย ) เพื่อเก็บความสัมพันธ์การแมประหว่างดัชนีและแอดเดรสเอง)

➤ ค่า: เราสามารถเก็บค่าในรูปแบบสัญกรณ์วิทยาศาสตร์ ในกรณีส่วนใหญ่ การทำธุรกรรมต้องใช้ตัวเลขนัยสำคัญ 1-3 หลักเท่านั้น

➤ ลายเซ็น: เราสามารถใช้ลายเซ็นรวม BLS เพื่อรวมลายเซ็นจำนวนมากเป็นลายเซ็นประมาณ 32-96 ไบต์ (ขึ้นอยู่กับโปรโตคอล) สามารถตรวจสอบลายเซ็นรวมได้ในครั้งเดียวตามชุดข้อความและชุดผู้ส่งของแบทช์ "~0.5" ในตารางระบุว่ามีการจำกัดจำนวนลายเซ็นที่สามารถรวมอยู่ในลายเซ็นรวมได้ เนื่องจากจำเป็นต้องสามารถตรวจสอบลายเซ็นรวมในหลักฐานการฉ้อโกง

การยกเลิกที่มีการป้องกันความเป็นส่วนตัวเป็นตัวอย่างที่สำคัญ: ในการยกเลิกในแง่ดี การพิสูจน์ ZK-SNARK สำหรับการปกป้องความเป็นส่วนตัวในแต่ละธุรกรรมจำเป็นต้องเป็นแบบออนไลน์และใช้พื้นที่ประมาณ 500 ไบต์ ในการยกเลิก ZK ZK-SNARK ที่มีทั้งชุดได้พิสูจน์ประสิทธิภาพของ ZK-SNARK "ภายใน"

เทคนิคการบีบอัดเหล่านี้เป็นกุญแจสำคัญในการปรับขนาดของโรลอัป มิฉะนั้น ความสามารถในการปรับขนาดของโรลอัปจะเพิ่มขึ้นได้ประมาณ 10 เท่าเท่านั้นเมื่อเทียบกับเครือข่ายพื้นฐาน ข้อมูลได้รับการประมวลผลหลังจากการบีบอัด ความสามารถในการปรับขนาดสามารถปรับปรุงได้มากกว่า 100 เท่าสำหรับแอปพลิเคชันเกือบทั้งหมด

ชื่อระดับแรก

ใครสามารถจัดแพคเกจธุรกรรมเป็นชุดและส่งได้

มีข้อเรียกร้องมากมายเกี่ยวกับสิทธิ์ในการบรรจุของธุรกรรมในการยกเลิกเชิงบวกและการยกเลิก ZK โดยทั่วไปแล้ว ผู้ใช้ที่ต้องการทำธุรกรรมและส่งจะต้องล็อคเงินฝากจำนวนมาก หากผู้ใช้ส่งแบทช์ที่มีธุรกรรมฉ้อฉล/ไม่ถูกต้อง (เช่น มีสถานะรูทที่ไม่ถูกต้อง) ส่วนหนึ่งของเงินฝากของผู้ใช้จะถูกทำลายและอีกส่วนหนึ่งจะได้รับรางวัลแก่ผู้พิสูจน์การฉ้อโกง นอกจากนั้น มีความเป็นไปได้อื่นๆ:

➤ สมบูรณ์ "อนาธิปไตย": ทุกคนสามารถแบทช์และส่งธุรกรรมได้ตลอดเวลา นี่เป็นวิธีที่ง่ายที่สุด แต่แน่นอนว่ามีข้อเสีย โดยเฉพาะอย่างยิ่งเมื่อผู้เข้าร่วมหลายคนพยายามส่งพร้อมกัน แต่ท้ายที่สุดแล้วสามารถบรรจุชุดเดียวได้สำเร็จ ซึ่งส่งผลให้เกิดงานที่สูญเปล่าจำนวนมากในการสร้างการพิสูจน์และ/หรือแก๊สในการออกแบทช์

➤ การประมวลผลแบบรวมศูนย์: มีนักแสดง ซีเควนเซอร์ ที่ส่งแบตช์ (แต่มีข้อยกเว้นสำหรับการถอน: โดยทั่วไปผู้ใช้สามารถส่งคำขอถอนก่อน ถ้าซีเควนเซอร์ไม่ประมวลผลการถอนในแบทช์ถัดไป จากนั้นผู้ใช้ สามารถยื่นชุดได้เอง) นี่เป็นวิธีที่ "มีประสิทธิภาพ" ที่สุด แต่ต้องพึ่งพาบทบาทจากส่วนกลาง

➤ การเลือกชุด PoS แบบสุ่ม: ทุกคนสามารถฝาก ETH (หรือโทเค็นของโปรโตคอลการยกเลิก) ลงในสัญญาการยกเลิก จากนั้นสุ่มเลือกตัวเรียงลำดับของแต่ละกลุ่มระหว่างผู้ฝาก ความเป็นไปได้ที่จะถูกเลือกจะขึ้นอยู่กับสัดส่วนของสินทรัพย์ที่ถูกล็อค สัดส่วน . ข้อเสียเปรียบหลักของวิธีนี้คือเงินทุนจำนวนมากจะถูกล็อคโดยไม่จำเป็น

➤ การลงคะแนน DPoS: ผู้คัดแยกถูกกำหนดผ่านการประมูล หากนักแสดงทำผลงานได้ไม่ดี ผู้ถือโทเค็นสามารถลงคะแนนเพื่อขับไล่เขาและเริ่มการประมูลใหม่

ชื่อระดับแรก

แยกบรรจุภัณฑ์จำนวนมากและการจัดการรูทสถานะ

โครงการยกเลิกบางโครงการที่กำลังอยู่ในระหว่างการพัฒนาใช้วิธี "การบรรจุชุดงานอิสระ" นั่นคือกระบวนการส่งชุดงานของธุรกรรมระดับที่สองและกระบวนการส่งสถานะรูทจะถูกแยกออกจากกัน ข้อดีของวิธีนี้คือ:

2. หาก state root ไม่ถูกต้อง เราไม่จำเป็นต้องย้อนกลับทั้งแบตช์ เราสามารถย้อนกลับ state root และรอให้ผู้อื่นจัดเตรียม state root ใหม่สำหรับแบตช์ สิ่งนี้ทำให้มั่นใจได้ว่าธุรกรรมของผู้ส่งจะไม่ถูกย้อนกลับ

โดยสรุป การแลกเปลี่ยนประสิทธิภาพ ความเรียบง่าย และการต่อต้านการเซ็นเซอร์นั้นซับซ้อน และกำลังมีการสำรวจทางเลือกมากมาย ยังเร็วเกินไปที่จะบอกว่าแนวคิดใดเป็นส่วนผสมที่ดีที่สุด แล้วเวลาจะเป็นเครื่องพิสูจน์

ชื่อระดับแรก

Rollup สามารถบรรลุการขยายตัวได้มากน้อยเพียงใด?

บนห่วงโซ่ Ethereum ที่มีอยู่ ขีดจำกัดบนของก๊าซคือ 12.5 ล้าน ในการทำธุรกรรม ข้อมูลแต่ละไบต์มีค่าใช้จ่าย 16 ก๊าซ ซึ่งหมายความว่าหากบล็อกมีแบทช์เพียงชุดเดียว (เราว่ามันเทียบเท่ากับการบรรจุ zk rollup และใช้จ่าย 500,000 แก๊สในการตรวจสอบการพิสูจน์) ชุดนั้นสามารถบรรจุ (12 ล้าน / 16) 750,000 ไบต์ของข้อมูล ดังที่แสดงไว้ด้านบน สำหรับการยกเลิกการถ่ายโอน Ethereum การดำเนินการของผู้ใช้แต่ละคนต้องการเพียง 12 ไบต์เท่านั้น ซึ่งหมายความว่าชุดของธุรกรรมสามารถมีธุรกรรมได้มากถึง 62,500 รายการ เวลาบล็อกเฉลี่ยอยู่ที่ 13 วินาที ซึ่งเทียบเท่ากับประมาณ 4807 ธุรกรรมต่อวินาที (เทียบกับ 12.5 ล้าน/21000/13~=45 ธุรกรรมต่อวินาทีสำหรับการโอนโดยตรงบน Ethereum)

ตารางต่อไปนี้เป็นตัวอย่างของกรณีการใช้งานอื่นๆ:

ตอนนี้ เป็นที่น่าสังเกตว่าตัวเลขเหล่านี้เป็นแง่ดีเกินไปด้วยเหตุผลหลายประการ สิ่งสำคัญที่สุดคือ แทบจะเป็นไปไม่ได้เลยที่บล็อกจะมีเพียงชุดเดียว เพราะอย่างน้อยที่สุดก็จะมีการยกเลิกหลายรายการ ประการที่สอง การฝากและถอนเงินจะมีอยู่เสมอ ประการที่สาม ในระยะสั้น อัตราการใช้งานจะต่ำ ดังนั้น ต้นทุนคงที่จะมีอิทธิพลเหนือ แต่ถึงแม้จะคำนึงถึงปัจจัยเหล่านี้แล้ว ระดับการปรับขนาดที่มากกว่า 100x นั้นคาดว่าจะเป็นบรรทัดฐาน

จะเป็นอย่างไรหากเราต้องการบรรลุธุรกรรม 1,000-4,000 รายการต่อวินาที (ขึ้นอยู่กับกรณีการใช้งานเฉพาะ) นี่คือที่มาของการแบ่งกลุ่มข้อมูล eth2 โปรโตคอลการชาร์ดดิ้งให้พื้นที่ 16MB สำหรับข้อมูลใดๆ ทุก 12 วินาที และระบบจะรับรองความเห็นพ้องต้องกันเกี่ยวกับความพร้อมใช้งานของข้อมูล สามารถใช้พื้นที่ข้อมูลได้โดยการยกเลิก พื้นที่ประมาณ 1398kb ต่อวินาทีนี้สูงกว่า 60kb ต่อวินาทีในปัจจุบันบนเครือข่าย Ethereum ถึง 23 เท่า และในระยะยาวความจุข้อมูลคาดว่าจะเพิ่มขึ้นอย่างต่อเนื่อง ดังนั้น การยกเลิกโดยใช้ eth2 sharded data สามารถแบทช์ที่ทรูพุตประมาณ 100,000 ธุรกรรมต่อวินาที และอาจมากกว่านั้นในอนาคต

ชื่อระดับแรก

มีปัญหาอะไรที่ยังไม่ได้รับการแก้ไขใน Rollup?

แม้ว่าตอนนี้เข้าใจแนวคิดพื้นฐานของการยกเลิกแล้ว แต่เรามั่นใจว่าเป็นไปได้อย่างสมบูรณ์และปลอดภัย และตอนนี้มีการปรับใช้การยกเลิกหลายรายการบน mainnet แล้ว ยังมีการออกแบบการยกเลิกหลายส่วนที่ยังไม่ได้สำรวจอย่างเต็มที่ และการนำไปใช้งาน ของการเชื่อมระบบนิเวศ Ethereum มีปัญหาในการย้ายกิจกรรมส่วนใหญ่ไปสู่การหมุนเวียนเพื่อใช้ประโยชน์จากความสามารถในการปรับขนาด ปัญหาสำคัญบางประการ ได้แก่ :

➤ การปรับตัวของผู้ใช้และระบบนิเวศน์ - มีแอปพลิเคชั่นไม่มากนักที่ใช้การยกเลิก ผู้ใช้ไม่คุ้นเคยกับการยกเลิก และมีกระเป๋าเงินเพียงไม่กี่แห่งเท่านั้นที่เริ่มรวมการยกเลิก ร้านค้าและองค์กรการกุศลยังไม่รองรับวิธีการชำระเงินนี้

➤ การทำธุรกรรมข้ามรายการ — ย้ายสินทรัพย์และข้อมูลอย่างมีประสิทธิภาพ (เช่น เอาต์พุตของออราเคิล) จากรายการหนึ่งไปยังอีกรายการหนึ่งโดยไม่มีค่าธรรมเนียมผ่านชั้นฐาน

➤ สิ่งจูงใจในการตรวจสอบ - วิธีเพิ่มโอกาสที่โหนดที่ซื่อสัตย์อย่างน้อยหนึ่งโหนดจะตรวจสอบการสรุปผลในแง่ดีอย่างสมบูรณ์ เพื่อให้พวกเขาออกหลักฐานการฉ้อโกงหากมีสิ่งผิดปกติเกิดขึ้น สำหรับการเลิกใช้ขนาดเล็ก (มากถึงหลายร้อยธุรกรรมต่อวินาที) ปัญหานี้ไม่ใช่ปัญหาใหญ่ เพราะมันเป็นเพียงเรื่องเล็กๆ น้อยๆ สำหรับผู้ขุด แต่สำหรับการเลิกใช้ขนาดใหญ่ จำเป็นต้องมีเหตุผลมากกว่านี้เพื่อโน้มน้าวให้นักขุดทำ การตรวจสอบ

➤ สำรวจพื้นที่การออกแบบระหว่างพลาสม่าและโรลอัพ - มีเทคโนโลยีที่สามารถใส่ข้อมูลที่เกี่ยวข้องกับการอัพเดตสถานะบางส่วนบนห่วงโซ่แทนที่จะเป็นข้อมูลทั้งหมด และข้อมูลนี้จะก่อให้เกิดสิ่งที่มีประโยชน์หรือไม่

➤ ZK-VM ที่มีประสิทธิภาพ - สร้างการพิสูจน์ ZK-SNARK ว่ารหัส EVM ทั่วไป (หรือ VM อื่น ๆ ที่สามารถรวบรวมสัญญาอัจฉริยะที่มีอยู่ได้) ได้รับการดำเนินการอย่างถูกต้องและด้วยผลลัพธ์ที่กำหนด

สรุปแล้ว

ชื่อระดับแรก

ลิงค์ต้นฉบับ:

ลิงค์ต้นฉบับ:https://vitalik.ca/general/2021/01/05/rollup.html

งานแปลของ ECN มีเป้าหมายเพื่อส่งมอบข้อมูลและทรัพยากรการเรียนรู้คุณภาพสูงสำหรับชุมชน Ethereum ของจีน ลิขสิทธิ์ของบทความเป็นของผู้เขียนต้นฉบับและต้องระบุแหล่งที่มาของข้อความต้นฉบับและเว็บไซต์ ETH ภาษาจีนเมื่อพิมพ์ซ้ำ สำหรับการพิมพ์ซ้ำในระยะยาว โปรดติดต่อ eth@ecn.co เพื่อขออนุญาต

บัญชีอย่างเป็นทางการ: สถานีจีน ​​ETH

งานแปลของ ECN มีเป้าหมายเพื่อส่งมอบข้อมูลและทรัพยากรการเรียนรู้คุณภาพสูงสำหรับชุมชน Ethereum ของจีน ลิขสิทธิ์ของบทความเป็นของผู้เขียนต้นฉบับและต้องระบุแหล่งที่มาของข้อความต้นฉบับและเว็บไซต์ ETH ภาษาจีนเมื่อพิมพ์ซ้ำ สำหรับการพิมพ์ซ้ำในระยะยาว โปรดติดต่อ eth@ecn.co เพื่อขออนุญาต

ETH
Vitalik
ยินดีต้อนรับเข้าร่วมชุมชนทางการของ Odaily
กลุ่มสมาชิก:
https://t.me/Odaily_News
กลุ่มสนทนา:
https://t.me/Odaily_GoldenApe
บัญชีทางการ:
https://twitter.com/OdailyChina
สารบัญบทความ
คลังบทความของผู้เขียน
ECN以太坊中国
อันดับบทความร้อน
Daily
Weekly
ดาวน์โหลดแอพ Odaily พลาเน็ตเดลี่
ให้คนบางกลุ่มเข้าใจ Web3.0 ก่อน
IOS
Android