เอกสารทางเทคนิค Optimism

บทคัดย่อ

เอกสารนี้กล่าวถึงปัญหาความสามารถในการปรับขนาดในการกระจายอำนาจ blockchains โดยการวิเคราะห์การแลกเปลี่ยนระหว่างปริมาณงานของธุรกรรมและข้อกำหนดด้านฮาร์ดแวร์เพื่อเรียกใช้โหนด Rollups เช่น เทคโนโลยีสำหรับการตรวจสอบ on-chain ของบล็อกที่ดำเนินการนอกลูกโซ่ จะถูกนำเสนอในรูปแบบของการพิสูจน์ข้อบกพร่องหรือความถูกต้อง เราเปรียบเทียบ Optimistic Rollups และ Validity Rollups โดยคำนึงถึงเวลาถอนเงิน ต้นทุนการทำธุรกรรม เทคนิคการปรับให้เหมาะสม และความเข้ากันได้กับระบบนิเวศ Ethereum การวิเคราะห์ของเราเผยให้เห็นว่า Optimism ปัจจุบัน Bedrock มีอัตราการบีบอัดก๊าซที่ประมาณ 20:1 ในขณะที่ StarkNet มีอัตราการบีบอัดต้นทุนการเขียนพื้นที่จัดเก็บที่ประมาณ 24:1 นอกจากนี้เรายังหารือถึงเทคนิคต่างๆ เพื่อเพิ่มประสิทธิภาพอัตราเหล่านี้ เช่น การใช้สัญญาแคชและตัวกรอง Bloom ท้ายที่สุดแล้ว ข้อสรุปของเราเน้นย้ำถึงการแลกเปลี่ยนระหว่างความซับซ้อนและความคล่องตัวในการเลือกระหว่างการโรลอัปในแง่ดีและความถูกต้อง คำสำคัญ Blockchain, Scalability, Rollup 1. บทนำ เทคโนโลยี Blockchain ได้รับความสนใจอย่างมากเนื่องจากมีศักยภาพในการปฏิวัติอุตสาหกรรมต่างๆ อย่างไรก็ตาม ความสามารถในการปรับขนาดยังคงเป็นความท้าทายที่สำคัญ เนื่องจาก blockchain ส่วนใหญ่ต้องเผชิญกับการแลกเปลี่ยนระหว่างความสามารถในการปรับขนาด การกระจายอำนาจ และความปลอดภัย โดยทั่วไปเรียกว่า Scalability Trilemma [1, 2] ในการเพิ่มปริมาณงานของ blockchain วิธีแก้ปัญหาเล็กน้อยคือการเพิ่มขนาดบล็อก ในบริบทของ Ethereum นี่หมายถึงการเพิ่มปริมาณก๊าซสูงสุดที่บล็อกสามารถกักเก็บได้ เนื่องจากแต่ละโหนดแบบเต็มจะต้องตรวจสอบทุกธุรกรรมของทุกบล็อก เมื่อปริมาณงานเพิ่มขึ้น ความต้องการฮาร์ดแวร์ก็เพิ่มขึ้นเช่นกัน ซึ่งนำไปสู่การรวมศูนย์ของเครือข่ายมากขึ้น blockchain บางตัว เช่น Bitcoin และ Ethereum เพิ่มประสิทธิภาพการออกแบบเพื่อเพิ่มการกระจายอำนาจทางสถาปัตยกรรมให้สูงสุด ในขณะที่ตัวอื่นๆ เช่น Binance Smart Chain และ Solana ได้รับการออกแบบมาให้รวดเร็วและราคาถูกที่สุดเท่าที่จะเป็นไปได้ เครือข่ายแบบกระจายอำนาจจะจำกัดปริมาณงานของ blockchain อย่างไม่ถูกต้อง เพื่อลดข้อกำหนดด้านฮาร์ดแวร์ในการเข้าร่วมในเครือข่าย ในช่วงหลายปีที่ผ่านมา มีความพยายามที่จะค้นหาวิธีแก้ปัญหาสำหรับไตรเลมมา เช่น ช่องสถานะ [3] และพลาสมา [4, 5] โซลูชันเหล่านี้มีลักษณะของการย้ายกิจกรรมบางอย่างนอกเครือข่าย การเชื่อมโยงกิจกรรมบนเครือข่ายไปยังกิจกรรมนอกเครือข่ายโดยใช้ smart contracts และการตรวจสอบ DLT 2023: 5th Distributed Ledger Technology Workshop, 25-26 พฤษภาคม 2023, โบโลญญา, อิตาลี $ [email protected] (L. Donno) https://lucadonnoh.github.io/ (L. Donno) 0000-0001-9221-3529 (L. Donno) © 2023 ลิขสิทธิ์บทความนี้โดยผู้เขียน ใช้ได้รับอนุญาตภายใต้ Creative Commons License Attribution 4.0 International (CC BY 4.0) CEUR Workshop Proceedings http://ceur-ws.org ISSN 1613-0073 CEUR Workshop Proceedings (CEUR-WS.org) สิ่งที่เกิดขึ้นนอกเครือข่ายแบบออนไลน์ อย่างไรก็ตาม ทั้งช่องพลาสมาและสถานะถูกจำกัดในการสนับสนุน smart contracts ทั่วไป การโรลอัปคือ blockchains (เรียกว่า Layer 2 หรือ L2) ที่เผยแพร่บล็อกของตนบน blockchain อื่น (Layer 1 หรือ L1) ดังนั้นจึงสืบทอดฉันทามติ ความพร้อมใช้งานของข้อมูล และคุณสมบัติด้านความปลอดภัย ซึ่งต่างจากโซลูชันอื่นๆ ตรงที่สนับสนุนการคำนวณตามอำเภอใจ Rollup มีองค์ประกอบหลักสามส่วน: • Sequencers: โหนดที่ได้รับธุรกรรม Rollup จากผู้ใช้และรวมเข้าด้วยกันเป็นบล็อกที่ส่งไปยัง Layer 1 บล็อกประกอบด้วยอย่างน้อยรากของสถานะ (เช่น รากของ Merkle) และข้อมูลที่จำเป็นในการสร้างใหม่และตรวจสอบความถูกต้องของสถานะ Layer 1 กำหนด...

การแนะนำ

1. บทนำ เทคโนโลยีบล็อคเชนได้รับความสนใจอย่างมากเนื่องจากมีศักยภาพในการปฏิวัติ อุตสาหกรรมต่างๆ อย่างไรก็ตาม ความสามารถในการขยายขนาดยังคงเป็นความท้าทายที่สำคัญ ตามที่ blockchain ส่วนใหญ่เผชิญอยู่ การแลกเปลี่ยนระหว่างความสามารถในการปรับขนาด การกระจายอำนาจ และการรักษาความปลอดภัย โดยทั่วไปเรียกว่า ความสามารถในการปรับขยาย Trilemma [1, 2] ในการเพิ่มปริมาณงานของ blockchain วิธีแก้ปัญหาเล็กน้อยคือ เพื่อเพิ่มขนาดบล็อก ในบริบทของ Ethereum นี่หมายถึงการเพิ่มค่าสูงสุด ปริมาณก๊าซที่บล็อกสามารถเก็บได้ เนื่องจากแต่ละโหนดเต็มจะต้องตรวจสอบทุกธุรกรรมของทุก ๆ บล็อก เมื่อปริมาณงานเพิ่มขึ้น ความต้องการฮาร์ดแวร์ก็เพิ่มขึ้นเช่นกัน ซึ่งส่งผลให้มีมากขึ้น การรวมศูนย์ของเครือข่าย blockchains บางตัว เช่น Bitcoin และ Ethereum ปรับให้เหมาะสม การออกแบบเพื่อเพิ่มการกระจายอำนาจทางสถาปัตยกรรมให้สูงสุด ในขณะที่อื่นๆ เช่น Binance Smart Chain และ Solana ได้รับการออกแบบมาให้รวดเร็วและราคาถูกที่สุดเท่าที่จะเป็นไปได้ เครือข่ายกระจายอำนาจ จำกัดปริมาณงานของ blockchain โดยไม่ตั้งใจ เพื่อลดข้อกำหนดด้านฮาร์ดแวร์ลง มีส่วนร่วมในเครือข่าย ในช่วงหลายปีที่ผ่านมา มีการพยายามหาทางแก้ไขปัญหา Trilemma เช่น รัฐ ช่อง [3] และพลาสมา [4, 5] โซลูชันเหล่านี้มีลักษณะเฉพาะในการเคลื่อนย้ายกิจกรรมบางอย่าง นอกเครือข่าย เชื่อมโยงกิจกรรมออนไลน์กับกิจกรรมนอกเครือข่ายโดยใช้ smart contracts และการตรวจสอบ DLT 2023: การประชุมเชิงปฏิบัติการเทคโนโลยี Distributed Ledger ครั้งที่ 5, 25-26 พฤษภาคม 2023, โบโลญญา, อิตาลี $ [email protected] (แอล. ดอนโน) https://lucadonnoh.github.io/ (แอล. ดอนโน) 0000-0001-9221-3529 (แอล.ดอนโน) © 2023 ลิขสิทธิ์บทความนี้โดยผู้เขียน ใช้ได้รับอนุญาตภายใต้ Creative Commons License Attribution 4.0 International (CC BY 4.0) ซีอีอาร์ การประชุมเชิงปฏิบัติการ การดำเนินการ http://ceur-ws.org ISSN 1613-0073 การดำเนินการประชุมเชิงปฏิบัติการ CEUR (CEUR-WS.org)on-chain สิ่งที่เกิดขึ้นนอกเครือข่าย อย่างไรก็ตาม ทั้ง Plasma และ State Channel นั้นมีข้อจำกัด การสนับสนุนทั่วไป smart contracts Rollups คือ blockchains (เรียกว่า Layer 2 หรือ L2) ที่เผยแพร่บล็อกของพวกเขาใน blockchain อื่น (Layer 1 หรือ L1) ดังนั้นจึงสืบทอดความเห็นพ้องต้องกัน ความพร้อมใช้งานของข้อมูล และคุณสมบัติด้านความปลอดภัย พวกเขา ไม่เหมือนกับโซลูชันอื่น ๆ รองรับการคำนวณตามอำเภอใจ Rollups มีองค์ประกอบหลักสามประการ: • Sequencers: โหนดที่รับธุรกรรม Rollup จากผู้ใช้และรวมเข้าด้วยกันเป็น บล็อกที่ส่งไปที่ Layer 1 บล็อกประกอบด้วยอย่างน้อยรากของสถานะ (เช่น Merkle root) และข้อมูลที่จำเป็นในการสร้างใหม่และตรวจสอบสถานะ Layer 1 กำหนด ตามบัญญัติ blockchain ของ L2 โดยการสร้างการเรียงลำดับของข้อมูลที่เผยแพร่ • Rollup full nodes: โหนดที่ได้รับ ประมวลผล และตรวจสอบ Rollup block จาก Layer 1 โดยการตรวจสอบว่ารูตถูกต้อง หากบล็อกมีธุรกรรมที่ไม่ถูกต้อง แสดงว่าเป็นเช่นนั้น ละทิ้ง ซึ่งจะป้องกันไม่ให้ Sequencers สร้างบล็อกที่ถูกต้องซึ่งรวมถึงบล็อกที่ไม่ถูกต้อง การทำธุรกรรม • Rollup light nodes: โหนดที่ได้รับ Rollup block จาก Layer 1 แต่ไม่ได้คำนวณ รัฐใหม่นั่นเอง พวกเขาตรวจสอบว่ารูทสถานะใหม่นั้นถูกต้องโดยใช้เทคนิค เช่นการพิสูจน์ข้อบกพร่องหรือความถูกต้อง Rollups บรรลุความสามารถในการปรับขนาดได้โดยการลดต้นทุนตัดจำหน่ายของธุรกรรมตามตัวเลข ของผู้ใช้เพิ่มขึ้น นี่เป็นเพราะว่าต้นทุนในการรับรองความถูกต้องของ blockchain นั้นเพิ่มขึ้นแบบไม่เชิงเส้น เกี่ยวกับค่าใช้จ่ายในการตรวจสอบธุรกรรมเป็นรายบุคคล Rollups จะแตกต่างกันไปตาม กลไกที่พวกเขารับรองความถูกต้องของการทำธุรกรรมที่ light nodes: ใน Rollups ในแง่ดี รับประกันโดยแบบจำลองทางเศรษฐกิจและการพิสูจน์ข้อผิดพลาด ขณะที่ยังใช้งานได้ โรลอัปจะรับประกันด้วยการเข้ารหัสโดยใช้การพิสูจน์ความถูกต้อง Light nodes สามารถนำไปใช้เป็น smart contracts บน Layer 1 พวกเขายอมรับรากเหง้าของ สถานะใหม่และตรวจสอบความถูกต้องหรือการพิสูจน์ข้อบกพร่อง: การยกเลิกเหล่านี้จึงเรียกว่าสัญญาอัจฉริยะ โรลอัป หากโหนดแสงเป็นอิสระ พวกมันจะถูกเรียกว่า Sovereign Rollups [6] ข้อดีของ การใช้ Smart Contract Rollup จะสามารถสร้างสะพานเชื่อมที่ลดความน่าเชื่อถือระหว่างทั้งสองได้ blockchains: เนื่องจากความถูกต้องของสถานะ L2 ได้รับการพิสูจน์แล้วถึง L1 ซึ่งเป็นระบบธุรกรรมจาก สามารถใช้ L2 ถึง L1 ได้ ทำให้สามารถถอนเงินได้ ข้อเสียคือต้นทุนของการ ธุรกรรมขึ้นอยู่กับค่าใช้จ่ายในการตรวจสอบสถานะบน L1: หากชั้นฐานอิ่มตัวด้วย กิจกรรมอื่นๆ ต้นทุนของธุรกรรมบน Rollup ก็เพิ่มขึ้นเช่นกัน ชั้นข้อมูลและมติเป็นชั้นที่กำหนดความปลอดภัยของระบบ พวกเขากำหนดลำดับของธุรกรรม ป้องกันการโจมตี และทำให้ข้อมูลพร้อมใช้งานเพื่อพิสูจน์สถานะ ความถูกต้อง การบริจาคกระดาษ ในบทความนี้ เราศึกษา Rollups ในแง่ดีและความถูกต้อง ซึ่งเป็นนวัตกรรมสองรายการ โซลูชันสำหรับ Scalability Trilemma โดยมุ่งเน้นไปที่การใช้งานที่โดดเด่น เช่น Optimism Bedrock และ StarkNet การมีส่วนร่วมของเรามีการเปรียบเทียบสิ่งเหล่านี้อย่างครอบคลุม วิธีแก้ปัญหา การวิเคราะห์เวลาการถอน และการอภิปรายเกี่ยวกับการโจมตีที่เป็นไปได้ใน Optimism ข้อเท็จจริง นอกจากนี้ เรายังคำนวณอัตราส่วนการอัดแก๊ส เพิ่มประสิทธิภาพเฉพาะแอปพลิเคชัน และนำเสนอข้อดีและข้อเสียของการย้ายออกจาก Ethereum เครื่องเสมือน (EVM)

โครงสร้างกระดาษ กระดาษมีการจัดดังนี้ ในส่วนที่ 2 การโรลอัปในแง่ดีคือ แนะนำโดยการวิเคราะห์ Optimism Bedrock ในส่วนที่ 3 มีการแนะนำการโรลอัปความถูกต้องโดย กำลังวิเคราะห์ StarkNet ในส่วนที่ 4 เราจะเปรียบเทียบทั้งสองวิธี ในที่สุด ในส่วนที่ 5 เราวาด ข้อสรุปบางอย่าง

โรลอัปในแง่ดี

1. การโรลอัปในแง่ดี แนวคิดในการยอมรับผลลัพธ์ของบล็อกในแง่ดีโดยไม่ต้องตรวจสอบการดำเนินการคือ มีอยู่แล้วในเอกสารไวท์เปเปอร์ Bitcoin [7] ที่กำลังพูดถึงโหนดแสง โหนดเหล่านี้ติดตามเท่านั้น ห่วงโซ่ส่วนหัวโดยการตรวจสอบกฎฉันทามติ ทำให้มีความเสี่ยงที่จะยอมรับการบล็อก มีธุรกรรมที่ไม่ถูกต้องในกรณีที่มีการโจมตี 51% นากาโมโตะเสนอที่จะแก้ไขปัญหานี้ ปัญหาโดยใช้ระบบ "แจ้งเตือน" เพื่อเตือนโหนดแสงว่าบล็อกมีธุรกรรมที่ไม่ถูกต้อง กลไกนี้ถูกนำมาใช้ครั้งแรกโดย Al-Bassam, Sonnino และ Buterin [8] ซึ่งมีข้อผิดพลาด ใช้ระบบพิสูจน์ตามรหัสแก้ไขข้อผิดพลาด [9] เพื่อให้เกิดการสร้าง เพื่อป้องกันข้อผิดพลาด จำเป็นต้องมีข้อมูลจากบล็อกทั้งหมด รวมถึงบล็อกที่ไม่ถูกต้องด้วย เครือข่าย: นี่คือปัญหาความพร้อมใช้งานของข้อมูล ซึ่งแก้ไขได้โดยใช้ข้อมูลที่น่าจะเป็น กลไกการสุ่มตัวอย่าง การออกแบบ Rollup Optimistic ครั้งแรกนำเสนอโดย John Adler และ Mikerah Quintyne-Collins ในปี 2019 [10] ซึ่งมีการเผยแพร่บล็อกใน blockchain อื่น ที่กำหนดฉันทามติในการสั่งซื้อ 2.1. Optimism ข้อเท็จจริง Bedrock [11] คือเวอร์ชันล่าสุดของ Optimism ซึ่งเป็น Smart Contract Rollup เวอร์ชันก่อนหน้านี้ Optimistic Virtual Machine (OVM) จำเป็นต้องมีคอมไพเลอร์เฉพาะกิจเพื่อรวบรวม Solidity ลงในเครื่อง รหัสไบต์ของตัวเอง: ในทางตรงกันข้าม Bedrock นั้นเทียบเท่ากับ EVM อย่างสมบูรณ์โดยที่เอ็นจิ้นการดำเนินการ เป็นไปตาม Ethereum ข้อกำหนดกระดาษสีเหลือง [12] 2.1.1. เงินฝาก ผู้ใช้สามารถฝากธุรกรรมผ่านสัญญาบน Ethereum ซึ่งเป็นพอร์ทัล Optimism โดยการเรียกฟังก์ชันDepositTransaction เมื่อทำธุรกรรมแล้ว ก เหตุการณ์ TransactionDeposited ถูกส่งออกมา ซึ่งแต่ละโหนดใน Rollup รับฟังเพื่อดำเนินการ เงินฝาก ธุรกรรมที่ฝากคือธุรกรรม L2 ที่ได้มาจาก L1 หากผู้โทรเข้าของ ฟังก์ชั่นคือสัญญา ที่อยู่จะถูกเปลี่ยนโดยการเพิ่มค่าคงที่ลงไป ซึ่งจะช่วยป้องกัน การโจมตีที่สัญญาบน L1 มีที่อยู่เดียวกันกับสัญญาบน L2 แต่มีรหัสต่างกัน การรวม L2 ของธุรกรรมที่ฝากไว้นั้นรับประกันโดยข้อกำหนดภายในลำดับ หน้าต่าง ธุรกรรมที่ฝากเป็นธุรกรรมประเภทใหม่ที่รองรับ EIP-2718 [13] โดยมีคำนำหน้า 0x7E โดยที่ฟิลด์ที่เข้ารหัส rlp คือ: • bytes32 sourceHash: hash ที่ระบุแหล่งที่มาของธุรกรรมโดยไม่ซ้ำกัน • ที่อยู่จาก: ที่อยู่ของผู้ส่ง • ที่อยู่: ที่อยู่ของผู้รับ หรือที่อยู่ศูนย์หากธุรกรรมที่ฝากคือ a การสร้างสัญญา• uint256 mint: ค่าที่จะสร้างบน L2 • ค่า uint256: ค่าที่จะส่งไปยังผู้รับ • ข้อมูลไบต์: ข้อมูลอินพุต • bytes gasLimit: ขีดจำกัดก๊าซของธุรกรรม sourceHash คำนวณเป็น keccak256 hash ของบล็อก L1 hash และบันทึก L1 ดัชนี ระบุเหตุการณ์ในบล็อกโดยไม่ซ้ำกัน เนื่องจากธุรกรรมที่ฝากเริ่มต้นบน L1 แต่ดำเนินการบน L2 ระบบจึงจำเป็นต้องมี กลไกการจ่าย L1 สำหรับก๊าซที่ใช้ใน L2 ทางออกหนึ่งคือส่ง ETH ผ่านทางพอร์ทัล แต่นี่หมายความว่าผู้โทรทุกคน (แม้แต่ผู้โทรทางอ้อม) จะต้องถูกทำเครื่องหมายว่าต้องชำระ และนี่คือ ไม่สามารถทำได้สำหรับโครงการที่มีอยู่มากมาย อีกทางเลือกหนึ่งคือการเผาไหม้ก๊าซที่สอดคล้องกันบน L1 ก๊าซ 𝑔ที่จัดสรรให้กับธุรกรรมที่ฝากเรียกว่าก๊าซรับประกัน ราคาก๊าซ L2 บน L1 จะไม่ซิงโครไนซ์โดยอัตโนมัติ แต่ประเมินโดยใช้กลไกที่คล้ายกับ EIP-1559 [14]. ปริมาณก๊าซสูงสุดที่รับประกันต่อ Ethereum บล็อกคือ 8 ล้าน โดยมีเป้าหมาย จำนวน 2 ล้าน ปริมาณ 𝑐 ของ ETH ที่ต้องชำระค่าก๊าซบน L2 คือ 𝑐= 𝑔𝑏L2 โดยที่ 𝑏L2 คือ ค่าธรรมเนียมพื้นฐานบน L2 สัญญาของ L1 จะเผาผลาญก๊าซในปริมาณเท่ากับ 𝑐/𝑏L2 ค่าแก๊สที่ใช้ในการโทร การฝากเงินธุรกรรมจะคืนเงินให้กับ L2: หากจำนวนนี้มากกว่าก๊าซที่รับประกัน ไม่มีการเผาไหม้ของก๊าซ ธุรกรรมแรกของบล็อก rollup คือธุรกรรมที่ฝากแอตทริบิวต์ L1 ใช้ในการลงทะเบียน บน L2 ปรับใช้คุณลักษณะของบล็อก Ethereum ล่วงหน้า คุณลักษณะที่การปรับใช้ล่วงหน้ามอบให้ การเข้าถึงคือหมายเลขบล็อก การประทับเวลา ค่าพื้นฐาน บล็อก hash และลำดับ number ซึ่งเป็นหมายเลขบล็อกของ L2 ที่สัมพันธ์กับบล็อก L1 ที่เกี่ยวข้อง (เรียกอีกอย่างว่ายุค) หมายเลขนี้จะถูกรีเซ็ตเมื่อยุคใหม่เริ่มต้นขึ้น 2.1.2. การเรียงลำดับ โหนด Rollup ได้รับสายโซ่ Optimism ทั้งหมดจาก Ethereum ห่วงโซ่นี้จะขยายออกไป แต่ละครั้งที่มีการเผยแพร่ธุรกรรมใหม่บน L1 และบล็อกจะถูกจัดระเบียบใหม่ในแต่ละครั้ง Ethereum บล็อกได้รับการจัดระเบียบใหม่ Rollup blockchain แบ่งออกเป็นยุคต่างๆ สำหรับแต่ละฮันนา หมายเลขบล็อกของ Ethereum มียุคที่สอดคล้องกัน แต่ละยุคมีอย่างน้อยหนึ่งยุค บล็อก และแต่ละบล็อกในยุคนั้นมีธุรกรรมที่ฝากแอตทริบิวต์ L1 บล็อคแรก ในยุคประกอบด้วยธุรกรรมทั้งหมดที่ฝากผ่านพอร์ทัล Layer 2 บล็อกก็ได้ มีธุรกรรมที่เรียงลำดับ เช่น ธุรกรรมที่ส่งโดยตรงไปยัง Sequencer Sequencer ยอมรับธุรกรรมจากผู้ใช้และสร้างบล็อก สำหรับแต่ละบล็อกจะมีการสร้าง ชุดที่จะเผยแพร่เมื่อ Ethereum สามารถเผยแพร่แบทช์หลายชุดในลักษณะบีบอัด เอาชื่อช่อง. ช่องสามารถแบ่งออกเป็นหลายเฟรมได้ ในกรณีที่ช่องมีขนาดใหญ่เกินไป ธุรกรรมเดียว ช่องสัญญาณถูกกำหนดให้เป็นการบีบอัดด้วย ZLIB [15] ของการเข้ารหัส rlp แบตช์ ฟิลด์ของแบตช์คือหมายเลขยุค, ยุค hash, ระดับบนสุด hash, การประทับเวลาและรายการธุรกรรม หน้าต่างลำดับที่ระบุโดยยุค มีตัวเลขคงที่ 𝑤ของ L1 ที่ต่อเนื่องกัน บล็อกที่ขั้นตอนการรับมาใช้เป็นอินพุตเพื่อสร้างจำนวนตัวแปรของบล็อก L2 สำหรับ ยุคที่ 4, หน้าต่างลำดับของ 4 รวมถึงบล็อก [4, + 4 𝑤] นี่หมายความว่าการสั่งซื้อ ของธุรกรรมและบล็อก L2 ภายในหน้าต่างลำดับไม่ได้รับการแก้ไขจนกว่าหน้าต่างจะสิ้นสุด ธุรกรรม rollup จะถูกเรียกว่าปลอดภัย หากแบทช์ที่มีธุรกรรมนั้นได้รับการยืนยันบน L1 เฟรมถูกอ่านจากบล็อก L1 เพื่อสร้างแบทช์ใหม่ การใช้งานในปัจจุบันไม่อนุญาตให้มี การบีบอัดช่องสัญญาณเพื่อเริ่มต้นจนกว่าจะได้รับเฟรมที่เกี่ยวข้องทั้งหมด ไม่ถูกต้อง ชุดงานจะถูกละเว้น ธุรกรรมบล็อกแต่ละรายการจะได้รับจากแบทช์ ซึ่งก็คือ ใช้โดยกลไกการดำเนินการเพื่อใช้การเปลี่ยนสถานะและรับสถานะ Rollup 2.1.3. การถอนเงิน เพื่อดำเนินการถอนเงิน ระบบส่งข้อความ L2-to-L1 จะถูกนำมาใช้ Ethereum จำเป็นต้องทราบสถานะของ L2 เพื่อที่จะยอมรับการถอนเงิน และทำได้โดยการเผยแพร่ บน L2 Output Oracle smart contract บน L1 รูทสถานะของแต่ละบล็อก L2 รากเหล่านี้ ได้รับการยอมรับในแง่ดีว่าถูกต้อง (หรือสรุปแล้ว) หากไม่มีการดำเนินการพิสูจน์ข้อบกพร่องในระหว่าง ระยะเวลาข้อพิพาท เฉพาะที่อยู่ที่กำหนดให้เป็นผู้เสนอเท่านั้นที่สามารถเผยแพร่รูตเอาท์พุตได้ ความถูกต้อง ของรากเอาท์พุตนั้นได้รับการจูงใจโดยการให้ผู้เสนอวางเงินเดิมพันซึ่งจะถูกเฉือนหากเป็นเช่นนั้น แสดงว่าได้เสนอรูทที่ไม่ถูกต้อง ธุรกรรมเริ่มต้นโดยการเรียกใช้ฟังก์ชัน เริ่มต้นถอนการปรับใช้ล่วงหน้าบน L2 จากนั้นจึงสรุปบน L1 โดยการเรียกใช้ฟังก์ชัน สิ้นสุดการถอนธุรกรรมบนพอร์ทัล Optimism ที่กล่าวถึงก่อนหน้านี้ รูทเอาท์พุตที่สอดคล้องกับบล็อก L2 นั้นได้มาจาก L2 Output Oracle; มันคือ ตรวจสอบว่าได้สรุปแล้ว เช่น ผ่านช่วงข้อพิพาทไปแล้ว เป็นการตรวจสอบว่าเอาท์พุต Root Proof ตรงกับ Oracle Proof; ได้รับการตรวจสอบแล้วว่ารวม hash ของการถอนออกด้วย โดยใช้หลักฐานการถอนเงิน การถอนเงินยังไม่เสร็จสิ้น แล้ว การเรียกไปยังที่อยู่เป้าหมายจะดำเนินการ โดยมีขีดจำกัดก๊าซ ปริมาณอีเธอร์ และข้อมูลที่ระบุ 2.1.4. แคนนอน: ระบบป้องกันข้อผิดพลาด หาก Rollup Full Node ค้นพบสิ่งนั้นโดยการดำเนินการแบตช์ภายในเครื่องและธุรกรรมที่ฝากไว้ สถานะ Layer 2 ไม่ตรงกับสถานะรูทที่เผยแพร่บนเชนโดยผู้เสนอ มันสามารถดำเนินการได้ การพิสูจน์ข้อบกพร่องบน L1 เพื่อพิสูจน์ว่าผลลัพธ์ของการเปลี่ยนบล็อกไม่ถูกต้อง เนื่องจาก ค่าใช้จ่ายการประมวลผล Rollup block ทั้งหมดบน L1 นั้นแพงเกินไป ได้มีการนำแนวทางแก้ไขไปใช้แล้ว โดย Bedrock คือการดำเนินการบนเชนเฉพาะคำสั่งแรกของความไม่เห็นด้วยของ minigeth รวบรวมมันเป็นสถาปัตยกรรม MIPS ที่ดำเนินการบนล่ามออนไลน์และเผยแพร่ บน L1 minigeth เป็นเวอร์ชันที่เรียบง่ายของ geth 1 ซึ่งมีฉันทามติ RPC และฐานข้อมูล ได้ถูกลบออกแล้ว เพื่อค้นหาคำสั่งแรกของความขัดแย้ง การค้นหาแบบไบนารีเชิงโต้ตอบจะดำเนินการระหว่าง ผู้ที่ริเริ่มการพิสูจน์ข้อบกพร่องและผู้ที่เผยแพร่รูตเอาท์พุต เมื่อพิสูจน์แล้ว เริ่มต้น ทั้งสองฝ่ายเผยแพร่รูทของสถานะหน่วยความจำ MIPS ครึ่งทางของการดำเนินการ การบล็อกสัญญาการท้าทาย: หาก hash ตรงกัน หมายความว่าทั้งสองฝ่ายเห็นด้วยกับ ครึ่งแรกของการดำเนินการจึงเผยแพร่รากของครึ่งหนึ่งของครึ่งหลัง มิฉะนั้นครึ่งหนึ่ง ของครึ่งแรกมีการเผยแพร่เป็นต้น การทำเช่นนี้จะถือเป็นคำสั่งแรกของการไม่เห็นด้วย ในจำนวนขั้นตอนลอการิทึมเมื่อเทียบกับการดำเนินการเดิม หากหนึ่งในสองหยุด โต้ตอบ เมื่อสิ้นสุดระยะเวลาการโต้แย้ง ผู้เข้าร่วมรายอื่นจะชนะโดยอัตโนมัติ ในการประมวลผลคำสั่ง ล่าม MIPS จำเป็นต้องเข้าถึงหน่วยความจำของมัน: เนื่องจากรูทคือ พร้อมใช้งาน เซลล์หน่วยความจำที่จำเป็นสามารถเผยแพร่ได้โดยการพิสูจน์การรวมเข้าด้วยกัน ในการเข้าถึง สถานะของ EVM การใช้งานทำจาก Preimage Oracle: เมื่อพิจารณาจาก hash ของบล็อกที่ส่งคืน 1https://geth.ethereum.org/docs

ส่วนหัวของบล็อกซึ่งสามารถรับ hash ของบล็อกก่อนหน้าและย้อนกลับไปใน chain หรือรับ hash ของสถานะและบันทึกที่สามารถรับพรีอิมเมจได้ oracle ดำเนินการโดย minigeth และแทนที่ฐานข้อมูล มีการสอบถามไปยังโหนดอื่นเพื่อ รับภาพเบื้องต้น

Rollups ความถูกต้อง

1. การยกเลิกความถูกต้อง เป้าหมายของการยกเลิกความถูกต้องคือการพิสูจน์ความถูกต้องของการเปลี่ยนแปลงสถานะด้วยการเข้ารหัส โดยมีลำดับการทำธุรกรรมพร้อมหลักฐานสั้นๆ ที่สามารถตรวจสอบเปรียบเทียบแบบเชิงเส้นย่อยได้ จนถึงเวลาคำนวณแบบเดิม ใบรับรองประเภทนี้เรียกว่าการพิสูจน์ความสมบูรณ์ทางคอมพิวเตอร์ และนำไปใช้งานได้จริงกับ SNARK (Succint Non-interactive ARgument of Knowledge) ซึ่งใช้เลขคณิต วงจรเป็นแบบจำลองการคำนวณ การใช้งาน SNARK ที่แตกต่างกันต่างกันในเรื่องเวลาในการพิสูจน์ เวลาในการตรวจสอบ ความจำเป็นในการตั้งค่าที่เชื่อถือได้ และความต้านทานควอนตัม [16, 17] สตาร์ค (ปรับขนาดได้ ARgument of Knowledge ที่โปร่งใส) [18] เป็น SNARK ประเภทหนึ่งที่ไม่จำเป็นต้องมีความน่าเชื่อถือ การตั้งค่าและทนทานต่อควอนตัม ขณะเดียวกันก็ทำให้ประสิทธิภาพในการพิสูจน์และการตรวจสอบลดลง เมื่อเทียบกับโซลูชั่นอื่นๆ 3.1. StarkNet StarkNet คือ Smart Contract Validity Rollup ที่พัฒนาโดย StarkWare ที่ใช้ STARK ระบบพิสูจน์เพื่อตรวจสอบสถานะเป็น Ethereum เพื่ออำนวยความสะดวกในการสร้างหลักฐานความถูกต้อง มีการใช้เครื่องเสมือนที่แตกต่างจาก EVM ซึ่งมีภาษาระดับสูงคือไคโร 3.1.1. เงินฝาก ผู้ใช้สามารถฝากธุรกรรมผ่านสัญญาใน Ethereum โดยการเรียก sendMessageToL2 ฟังก์ชั่น ข้อความถูกบันทึกโดยการคำนวณ hash และเพิ่มตัวนับ ซีเควนเซอร์ ฟังเหตุการณ์ LogMessageToL2 และเข้ารหัสข้อมูลในธุรกรรม StarkNet ที่เรียกใช้ฟังก์ชันของสัญญาที่มีมัณฑนากร l1_handler เมื่อสิ้นสุดการประหารชีวิต เมื่อมีการสร้างหลักฐานการเปลี่ยนสถานะ การใช้ข้อความจะถูกแนบไปด้วย และมันถูกลบโดยการลดตัวนับ การรวมธุรกรรมที่ฝากไม่จำเป็นตามข้อกำหนด StarkNet ดังนั้นจึงเป็นแก๊ส จำเป็นต้องมีตลาดเพื่อจูงใจให้ Sequencers เผยแพร่บน L2 ในเวอร์ชั่นปัจจุบันเพราะว่า Sequencer ได้รับการรวมศูนย์และจัดการโดย StarkWare ซึ่งเป็นต้นทุนของธุรกรรมที่ฝากไว้ ถูกกำหนดโดยค่าใช้จ่ายในการดำเนินการฝากเงินเท่านั้น ค่าใช้จ่ายนี้ชำระโดยการส่ง ETH ไปที่ sendMessageToL2. อีเทอร์เหล่านี้ยังคงล็อคอยู่บน L1 และจะถูกถ่ายโอนไปยังซีเควนเซอร์บน L1 เมื่อธุรกรรมที่ฝากรวมอยู่ในการเปลี่ยนสถานะ จำนวน ETH ที่ส่ง ถ้า รวมธุรกรรมที่ฝากไว้แล้ว ใช้ไปจนหมด โดยไม่คำนึงถึงปริมาณการใช้ก๊าซ บน L2 StarkNet ไม่มีระบบที่ทำให้แอ็ตทริบิวต์บล็อก L1 พร้อมใช้งานโดยอัตโนมัติ อีกทางหนึ่ง Fossil เป็นโปรโตคอลที่พัฒนาโดย Oiler Network 2 ที่อนุญาต โดยให้ hash ของ บล็อก ข้อมูลใด ๆ ที่จะได้รับจาก Ethereum โดยการเผยแพร่ภาพล่วงหน้า 2https://www.oiler.network/3.1.2. การเรียงลำดับ สถานะปัจจุบันของ StarkNet สามารถได้รับมาจาก Ethereum ทั้งหมด ความแตกต่างของรัฐใด ๆ ระหว่างช่วงการเปลี่ยนภาพถูกเผยแพร่บน L1 เป็น calldata มีการเผยแพร่ความแตกต่างสำหรับแต่ละสัญญา และบันทึกเป็น uint256[] โดยมีการเข้ารหัสต่อไปนี้: • จำนวนฟิลด์ที่เกี่ยวข้องกับการปรับใช้สัญญา • สำหรับสัญญาที่เผยแพร่แต่ละฉบับ: – ที่อยู่ของสัญญาที่เผยแพร่ – hash ของสัญญาที่เผยแพร่ – จำนวนข้อโต้แย้งของผู้สร้างสัญญา – รายการข้อโต้แย้งของคอนสตรัคเตอร์ • จำนวนสัญญาที่มีการแก้ไขการจัดเก็บ • สำหรับแต่ละสัญญาที่ได้รับการแก้ไข: – ที่อยู่ของสัญญาที่แก้ไข – จำนวนการอัปเดตที่เก็บข้อมูล – คู่คีย์-ค่าของที่อยู่หน่วยเก็บข้อมูลที่มีค่าใหม่ ความแตกต่างของรัฐได้รับการเผยแพร่ตามลำดับ ดังนั้นจึงเพียงพอที่จะอ่านตามลำดับ สร้างรัฐขึ้นใหม่ 3.1.3. การถอนเงิน หากต้องการส่งข้อความจาก L2 ถึง L1 จะใช้ syscall send_message_to_L1 ข้อความก็คือ เผยแพร่ไปยัง L1 โดยเพิ่มตัวนับ hash พร้อมกับการพิสูจน์และสรุปโดยการเรียก ฟังก์ชั่น consumeMessageFromL2 บน StarkGate smart contract บน L1 ซึ่งลดลง เคาน์เตอร์ ทุกคนสามารถสรุปการถอนเงินได้ 3.1.4. หลักฐานความถูกต้อง เครื่องเสมือนของไคโร [19] ได้รับการออกแบบมาเพื่ออำนวยความสะดวกในการสร้างหลักฐาน STARK ภาษาไคโรช่วยให้สามารถอธิบายการคำนวณด้วยการเขียนโปรแกรมระดับสูงได้ ภาษาและไม่ใช่วงจรโดยตรง ซึ่งสามารถทำได้โดยระบบสมการพหุนาม 3 แสดงถึงการคำนวณครั้งเดียว: วงจร FDE ของสถาปัตยกรรม von Neumann หมายเลข ข้อจำกัดจึงได้รับการแก้ไขและไม่ขึ้นกับประเภทของการคำนวณ โดยอนุญาตให้ทำได้เพียงรายการเดียวเท่านั้น โปรแกรมตรวจสอบสำหรับทุกโปรแกรมที่ต้องพิสูจน์การคำนวณ StarkNet รวมธุรกรรมหลายรายการไว้ในหลักฐาน STARK เดียวโดยใช้เครื่องพิสูจน์ที่ใช้ร่วมกัน ชื่อชาร์ป หลักฐานจะถูกส่งไปยัง smart contract ใน Ethereum ซึ่งจะตรวจสอบความถูกต้อง และอัพเดตรูต Merkle ที่สอดคล้องกับสถานะใหม่ ต้นทุนย่อยเชิงเส้นของการตรวจสอบ หลักฐานความถูกต้องช่วยให้สามารถตัดจำหน่ายต้นทุนในการทำธุรกรรมหลายรายการได้ 3เรียกว่าการเป็นตัวแทนระดับกลางพีชคณิต (AIR)

การเปรียบเทียบ

1. การเปรียบเทียบ 4.1. เวลาถอนเงิน สิ่งสำคัญที่สุดที่ทำให้ Rollups ในแง่ดีแตกต่างจาก Rollups ที่มีความถูกต้องคือ เวลาที่ผ่านไประหว่างการเริ่มต้นของการถอนและการสรุป ในทั้งสองกรณี การถอนเงินจะเริ่มต้นใน L2 และสิ้นสุดใน L1 ใน StarkNet การสรุปสามารถทำได้ดังนี้ ทันทีที่หลักฐานความถูกต้องของรูทสถานะใหม่ได้รับการยอมรับใน Ethereum: ตามทฤษฎีแล้ว สามารถถอนเงินได้ในบล็อคแรกของ L1 หลังจากการเริ่มต้น ในทางปฏิบัตินั้น ความถี่ในการส่งหลักฐานความถูกต้องใน Ethereum ถือเป็นการแลกเปลี่ยนระหว่างความเร็วของบล็อก การสรุปและการรวมหลักฐาน ปัจจุบัน StarkNet มีหลักฐานยืนยันความถูกต้องสำหรับการตรวจสอบ ทุก 10 ชั่วโมง 4 แต่ตั้งใจให้ลดลงเมื่อกิจกรรมธุรกรรมเพิ่มขึ้น ใน Optimism Bedrock เป็นไปได้ที่จะสรุปการถอนตัวเมื่อสิ้นสุดข้อพิพาทเท่านั้น ระยะเวลา (ปัจจุบันคือ 7 วัน) หลังจากนั้นรูทจะถือว่าใช้ได้โดยอัตโนมัติ ความยาวของ ช่วงเวลานี้ถูกกำหนดโดยข้อเท็จจริงที่ว่าการพิสูจน์ข้อบกพร่องสามารถตรวจสอบได้ใน Ethereum จนกระทั่ง จุดสิ้นสุดของมัน ความน่าจะเป็นที่สำเร็จของการโจมตีประเภทนี้จะลดลงแบบทวีคูณเมื่อเวลาผ่านไป: E[ค่าที่ลบออก] = 𝑉𝑝크 โดยที่ ñ คือจำนวนบล็อกในช่วงเวลา 𝑉 คือจำนวนเงินที่สามารถลบได้ โดยการเผยแพร่รูทที่ไม่ถูกต้อง และ 𝑝คือความน่าจะเป็นในการดำเนินการเซ็นเซอร์ได้สำเร็จ โจมตีในบล็อคเดียว สมมติว่าความน่าจะเป็นนี้คือ 99% ที่ค่าถูกล็อกไว้ในค่าสะสม คือหนึ่งล้านอีเธอร์ และบล็อกในช่วงเวลาคือ 1800 (บล็อก 6 ชั่วโมงด้วย 12 ช่วงเวลาวินาที): ค่าที่คาดหวังคือประมาณ 0.01391 อีเธอร์ ระบบมีความปลอดภัยโดย ขอให้ผู้เสนอเดิมพันอีเธอร์ในปริมาณที่มากกว่าที่คาดไว้ วินเซอร์ และคณะ แสดงวิธีดำเนินการโจมตีด้วยการเซ็นเซอร์โดยใช้ smart contract แบบง่ายๆ เพื่อให้แน่ใจว่าพื้นที่บางส่วนของหน่วยความจำในสถานะไม่เปลี่ยนแปลง [20] การสร้างแบบจำลองการโจมตี ในฐานะเกมของ Markov บทความนี้แสดงให้เห็นว่าการเซ็นเซอร์เป็นกลยุทธ์ที่โดดเด่นสำหรับเหตุผล บล็อกผู้ผลิตหากพวกเขาได้รับค่าตอบแทนมากกว่าการรวมธุรกรรมที่เปลี่ยนแปลง หน่วยความจำ ค่า 𝑝 ที่กล่าวถึงข้างต้นสามารถดูได้เป็นเปอร์เซ็นต์ของบล็อกตรรกยะ ผู้ผลิตในเครือข่ายโดยที่ “เหตุผล” ไม่คำนึงถึงการลงโทษ ภายนอก เช่น ความไว้วางใจน้อยลงใน blockchain ที่ทำให้มูลค่าสกุลเงินดิจิทัลลดลง รหัสต่อไปนี้แสดง smart contract ที่สามารถใช้เพื่อโจมตีด้วยการเซ็นเซอร์ บนพื้นหิน การโจมตีดังกล่าวใช้ประโยชน์จากสิ่งจูงใจของผู้ผลิตบล็อกโดยการเสนอสินบนให้พวกเขา เพื่อเซ็นเซอร์ธุรกรรมที่จะแก้ไขส่วนใดส่วนหนึ่งของรัฐ หลักสัญญา ฟังก์ชั่นการเรียกร้องสินบนช่วยให้ผู้ผลิตบล็อกสามารถเรียกร้องสินบนได้หากพวกเขาเซ็นเซอร์ได้สำเร็จ ธุรกรรมเป้าหมายโดยการตรวจสอบว่าไม่ได้แตะรูทเอาท์พุตที่ไม่ถูกต้อง ฟังก์ชั่นการเรียกร้องสินบน (หน่วยเก็บข้อมูลไบต์หลักฐาน) ภายนอก { need(!claimed[block.number], "สินบนถูกอ้างสิทธิ์แล้ว"); หน่วยความจำ OutputProposal ปัจจุบัน = storageOracle.getStorage(L2_ORACLE, block.number, SLOT, หลักฐานการจัดเก็บ); ต้องการ (invalidOutputRoot == current.outputRoot, "การโจมตีล้มเหลว"); อ้างสิทธิ์ [block.number] = จริง; (บูลที่ส่ง ) = block.coinbase.call{value: bribeAmount}(""); 4https://etherscan.io/address/0xc662c410c0ecf747543f5ba90660f6abebd9c8c4ต้องการ (ส่ง "ไม่สามารถส่งอีเธอร์"); } รายการ 1: ตัวอย่างของสัญญาที่จูงใจให้เกิดการโจมตีด้วยการเซ็นเซอร์ใน Bedrock ระยะเวลาของข้อพิพาทจะต้องคำนึงถึงข้อเท็จจริงที่พิสูจน์ความผิดด้วย หลักฐานเชิงโต้ตอบและจึงต้องจัดเตรียมเวลาให้เพียงพอเพื่อให้ผู้เข้าร่วมโต้ตอบได้ และปฏิสัมพันธ์ใดๆ ก็ตามสามารถถูกเซ็นเซอร์ได้ หากการเคลื่อนไหวครั้งล่าสุดเกิดขึ้นในเวลาที่ใกล้กับจุดนั้นมาก เมื่อสิ้นสุดระยะเวลาข้อพิพาท ค่าใช้จ่ายในการเซ็นเซอร์จะน้อยลงอย่างมาก แม้ว่าการเซ็นเซอร์จะเป็น กลยุทธ์ที่โดดเด่น โอกาสที่จะประสบความสำเร็จจะลดลงเนื่องจากการเซ็นเซอร์โหนดมีความเสี่ยง การโจมตีแบบปฏิเสธการให้บริการ: ผู้โจมตีสามารถสร้างธุรกรรมที่ซับซ้อนมากซึ่งลงท้ายด้วย การเผยแพร่หลักฐานข้อบกพร่องโดยไม่มีค่าใช้จ่าย เนื่องจากไม่ต้องเสียค่าธรรมเนียม ในกรณีที่ร้ายแรง ระยะเวลาการโต้แย้งที่ยาวนานจะช่วยให้สามารถประสานงานในกรณีที่ประสบความสำเร็จ การโจมตีเซ็นเซอร์เพื่อจัดระเบียบทางแยกและแยกผู้ผลิตบล็อกการโจมตี อีกอัน การโจมตีที่เป็นไปได้ประกอบด้วยการเผยแพร่ข้อเสนอรากของรัฐมากกว่าที่ผู้โต้แย้งสามารถตรวจสอบได้ ซึ่งสามารถหลีกเลี่ยงได้โดยใช้การจำกัดความถี่ 4.1.1. การถอนเงินในแง่ดีอย่างรวดเร็ว เนื่องจากความถูกต้องของ Optimistic Rollup สามารถตรวจสอบได้ตลอดเวลาโดยโหนดเต็มใดๆ a oracle ที่เชื่อถือได้ สามารถใช้เพื่อทราบใน L1 ว่าการถอนเงินสามารถสรุปได้อย่างปลอดภัยหรือไม่ นี้ กลไกถูกเสนอครั้งแรกโดย Maker [21]: oracle ตรวจสอบการถอนออก เผยแพร่ ส่งผลให้ L1 กำหนดเงินกู้ที่มีดอกเบี้ยให้กับผู้ใช้ซึ่งเป็นไปโดยอัตโนมัติ ปิดเมื่อครบ 7 วัน นั่นคือเมื่อการถอนสามารถสรุปได้จริง วิธีแก้ปัญหานี้ แนะนำสมมติฐานความน่าเชื่อถือ แต่ในกรณีของ Maker จะถูกย่อให้เล็กสุดเนื่องจากตัวดำเนินการ oracle ได้รับการจัดการโดยองค์กรเดียวกับที่รับความเสี่ยงโดยการให้เงินกู้ 4.2. ต้นทุนการทำธุรกรรม ต้นทุนของธุรกรรม L2 ส่วนใหญ่ถูกกำหนดโดยการโต้ตอบกับ L1 ในโซลูชั่นทั้งสอง ต้นทุนการคำนวณของธุรกรรมมีราคาถูกมากเนื่องจากมีการดำเนินการนอกเครือข่ายทั้งหมด Optimism เผยแพร่ calldata ธุรกรรม L2 เป็น calldata และแทบจะไม่ (หรือไม่เคย) ดำเนินการผิดพลาดเลย หลักฐาน ดังนั้น calldata จึงเป็นทรัพยากรที่แพงที่สุด เมื่อวันที่ 12 มกราคม 2022 เครือข่าย Bedrock ได้รับการเปิดตัวบน Goerli testnet ของ Ethereum สามารถคำนวณอัตราการอัดแก๊สได้ โดยการติดตามปริมาณก๊าซที่ใช้ใน Bedrock ในช่วงเวลาหนึ่งและเปรียบเทียบกับ ปริมาณก๊าซที่ใช้ใน L1 สำหรับบล็อกที่เกี่ยวข้อง การใช้วิธีนี้เป็นการบีบอัดแก๊ส พบอัตรา ∼20 : 1 แต่ตัวเลขนี้อาจแตกต่างกับกิจกรรมจริงบนเมนเน็ต StarkNet เผยแพร่บน Ethereum ทุกการเปลี่ยนแปลงในสถานะ L2 เป็น calldata ดังนั้นที่เก็บข้อมูลจึงเป็น ทรัพยากรที่แพงที่สุด เนื่องจากเครือข่ายไม่ได้ใช้ EVM ต้นทุนการทำธุรกรรม การบีบอัดไม่สามารถประมาณได้เล็กน้อย โดยสมมติค่าใช้จ่ายในการดำเนินการและข้อมูลการโทรไปที่ เพียงเล็กน้อยก็เป็นไปได้ที่จะคำนวณอัตราส่วนการบีบอัดของการเขียนที่เก็บข้อมูลเมื่อเปรียบเทียบกับ L1. สมมติว่าไม่มีการปรับใช้สัญญาและ 10 เซลล์ที่ไม่เคยเข้าถึงก่อนหน้านี้บน StarkNet คือ แก้ไขแล้ว พบอัตราการบีบอัดต้นทุนการเขียนหน่วยเก็บข้อมูลที่ ∼24: 1 หากเซลล์ถูกเขียนทับ ระยะเวลาระหว่างการเผยแพร่ข้อมูล ค่าใช้จ่ายในการเขียนแต่ละครั้งจะเท่ากับ 1/ เมื่อเทียบกับค่าใช้จ่าย ของการเขียนเพียงฉบับเดียวเนื่องจากเผยแพร่เฉพาะฉบับสุดท้ายเท่านั้น สามารถลดต้นทุนได้อีกโดยการบีบอัดค่าที่ใช้บ่อย ค่าใช้จ่ายในการตรวจสอบหลักฐานความถูกต้องจะแบ่งออกเป็น ธุรกรรมที่อ้างถึง: ตัวอย่างเช่น StarkNet บล็อก 4779 มี 200 ธุรกรรมและ หลักฐานความถูกต้องใช้ก๊าซ 267830 หน่วย หรือ 1339.15 หน่วยก๊าซสำหรับแต่ละธุรกรรม 4.2.1. การเพิ่มประสิทธิภาพ calldata: สัญญาแคช ด้านล่างนี้คือ smart contract ที่ใช้แคชที่อยู่สำหรับการใช้งานบ่อย ที่อยู่โดยการใช้ประโยชน์จากความจริงที่ว่าการจัดเก็บและการดำเนินการนั้นมีราคาถูกกว่ามาก ทรัพยากรต่างๆ พร้อมด้วยสัญญา Friends ที่สาธิตการใช้งาน หลังติดตามของ “เพื่อน” ของที่อยู่ที่สามารถลงทะเบียนได้โดยการเรียกใช้ฟังก์ชัน addFriend ถ้าเป็นที่อยู่ มีการใช้งานมาแล้วอย่างน้อย 1 ครั้ง สามารถเพิ่มได้ด้วยการเรียก addFriendWithCache ฟังก์ชั่น: ดัชนีแคชเป็นจำนวนเต็ม 4 ไบต์ในขณะที่ที่อยู่แสดงด้วย 20 ไบต์ ดังนั้นจึงมีการบันทึก 5:1 ในอาร์กิวเมนต์ของฟังก์ชัน ตรรกะเดียวกันนี้สามารถนำไปใช้กับข้อมูลอื่นได้ ประเภทต่างๆ เช่น จำนวนเต็ม หรือไบต์โดยทั่วไป AddressCache สัญญา { การทำแผนที่ (ที่อยู่ => uint32) address2key สาธารณะ; ที่อยู่ [] กุญแจสาธารณะ2ที่อยู่; ฟังก์ชั่น cacheWrite (ที่อยู่ _ ที่อยู่) ส่งคืนภายใน (uint32) { ต้องการ (key2address.length < ประเภท (uint32).max, "AddressCache: แคชเต็ม"); ต้องการ (address2key[_address] == 0, "AddressCache: ที่อยู่แคชไว้แล้ว"); // คีย์ต้องเริ่มจาก 1 เพราะ 0 หมายถึง "ไม่พบ" คีย์ uint32 = uint32 (key2address.length + 1); address2key[_address] = คีย์; key2address.push(_ที่อยู่); ส่งคืนกุญแจ; } ฟังก์ชั่น cacheRead (uint32 _key) มุมมองสาธารณะส่งคืน (ที่อยู่) { ต้องการ(_key <= key2address.length && _key > 0, "AddressCache: ไม่พบคีย์"); กลับคีย์2ที่อยู่[_key - 1]; } } รายการ 2: สัญญาแคชที่อยู่ เพื่อนสัญญาคือ AddressCache { การทำแผนที่ (ที่อยู่ => ที่อยู่ []) เพื่อนสาธารณะ; ฟังก์ชั่น addFriend (ที่อยู่ _friend) สาธารณะ { เพื่อน[msg.sender].push(_friend); แคชเขียน(_เพื่อน); } ฟังก์ชั่น addFriendWithCache (uint32 _friendKey) สาธารณะ { เพื่อน[msg.sender].push(cacheRead(_friendKey)); } ฟังก์ชั่น getFriends() ส่งคืนมุมมองสาธารณะ (หน่วยความจำที่อยู่ []) { ส่งกลับเพื่อน[msg.sender];} } รายการ 3: ตัวอย่างของสัญญาที่สืบทอดแคชที่อยู่ สัญญารองรับที่อยู่แคชประมาณ 4 พันล้าน (232) ที่อยู่และเพิ่มอีกหนึ่งไบต์ ประมาณ 1 ล้านล้าน (240) 4.2.2. การเพิ่มประสิทธิภาพพื้นที่เก็บข้อมูล: ตัวกรองของ Bloom ใน StarkNet มีเทคนิคหลายประการในการลดการใช้พื้นที่เก็บข้อมูล ถ้าไม่จำเป็น รับประกันความพร้อมใช้งานของข้อมูลต้นฉบับ จากนั้นการบันทึกแบบออนไลน์ก็เพียงพอแล้ว hash: สิ่งนี้ เป็นกลไกที่ใช้ในการบันทึกข้อมูลสำหรับ ERC-721 (NFT) [22] เช่นลิงก์ IPFS ที่แก้ไข hash ของข้อมูล หากมี สำหรับข้อมูลที่เก็บไว้หลายครั้ง สามารถใช้การค้นหาได้ ตารางที่คล้ายกับระบบแคชที่แนะนำสำหรับ Optimism โดยกำหนดให้ต้องบันทึกค่าทั้งหมดไว้ที่ อย่างน้อยหนึ่งครั้ง สำหรับบางแอปพลิเคชัน คุณสามารถหลีกเลี่ยงการบันทึกค่าทั้งหมดได้โดยใช้ตัวกรอง Bloom [23, 24, 25] กล่าวคือ โครงสร้างข้อมูลความน่าจะเป็นที่ช่วยให้ทราบได้อย่างแน่นอนว่า องค์ประกอบไม่ได้อยู่ในชุด แต่ยอมรับความน่าจะเป็นเท็จเล็กน้อยแต่ไม่อาจมองข้ามได้ แง่บวก ตัวกรอง Bloom เริ่มต้นเป็นอาร์เรย์ของ 𝑚บิตที่ศูนย์ หากต้องการเพิ่มองค์ประกอบ ให้ใช้ฟังก์ชัน 𝑘hash ด้วยการแจกแจงแบบสุ่มแบบสม่ำเสมอ แต่ละอันจะแมปกับบิตของอาเรย์ที่ตั้งค่าไว้ ถึง 1. เพื่อตรวจสอบว่าองค์ประกอบเป็นของชุดหรือไม่ เราเรียกใช้ฟังก์ชัน 𝑘hash และตรวจสอบ ว่า 𝑘bits ถูกตั้งค่าเป็น 1 ในตัวกรองของ Bloom แบบธรรมดา ไม่มีทางที่จะแยกแยะได้ว่า องค์ประกอบจริงๆ นั้นเป็นของเซตหรือเป็นผลบวกลวง ความน่าจะเป็นที่เพิ่มขึ้นตามตัวเลข ของรายการเพิ่มขึ้น หลังจากใส่องค์ประกอบแล้ว: P[ผลบวกลวง] = (︃ 1 − [︂ 1 −1 𝑚 ]︂𝑘न)︃𝑘 data (︁ 1 −ฎ−𝑘크/𝑚)︁𝑘 สมมติความเป็นอิสระของความน่าจะเป็นของแต่ละชุดบิต หากองค์ประกอบ (ขนาดใดก็ได้!) เป็น คาดว่าจะรวมไว้และความน่าจะเป็นของผลบวกลวงที่ยอมรับได้คือ 𝑝 ซึ่งเป็นขนาดของอาร์เรย์ สามารถคำนวณได้ดังนี้: 𝑚= −โทนลน์ 𝑝 (ใน 2)2 ในขณะที่จำนวนที่เหมาะสมที่สุดของฟังก์ชัน hash คือ: 𝑘= 𝑚 ฮันอิน 2 หากเราถือว่าแทรก 1,000 องค์ประกอบโดยมีค่าความคลาดเคลื่อน 1% ขนาดของอาร์เรย์จะเป็น 9585 บิต ด้วย 𝑘= 6 ในขณะที่ค่าความคลาดเคลื่อน 0.1% จะกลายเป็น 14377 บิต โดยที่ 𝑘= 9 หากมีองค์ประกอบล้านองค์ประกอบ คาดว่าจะใส่ได้ขนาดของอาเรย์จะอยู่ที่ประมาณ 1170 kB สำหรับ 1% และ 1775 kB สำหรับ 0.1% โดยมีค่าเท่ากันคือ 𝑘 เนื่องจากขึ้นอยู่กับ 𝑝[26] เท่านั้น ในเกมที่ผู้เล่นจะต้องไม่ถูกมอบหมายให้กับคู่ต่อสู้ที่พวกเขาท้าทายไปแล้ว แทนที่จะบันทึกในที่เก็บข้อมูลสำหรับผู้เล่นแต่ละคน รายชื่อคู่ต่อสู้ที่ผ่านมาเราสามารถใช้ Bloom ได้ กรอง ความเสี่ยงที่จะไม่ท้าทายผู้เล่นบางคนมักจะยอมรับได้ และสามารถรีเซ็ตตัวกรองได้ เป็นระยะๆ4.3. Ethereum ความเข้ากันได้ ข้อได้เปรียบหลักของความเข้ากันได้กับ EVM และ Ethereum คือการนำสิ่งที่มีอยู่ทั้งหมดกลับมาใช้ใหม่ เครื่องมือ Ethereum smart contracts สามารถเผยแพร่บน Optimism โดยไม่มีการแก้ไขหรือ การตรวจสอบใหม่ กระเป๋าเงินยังคงเข้ากันได้ เครื่องมือการพัฒนาและการวิเคราะห์แบบคงที่ การวิเคราะห์ทั่วไป เครื่องมือ เครื่องมือจัดทำดัชนี และ oracles Ethereum และ Solidity มีประวัติอันยาวนานของการศึกษามาอย่างดี ช่องโหว่ เช่น การโจมตีซ้ำ, ล้นและอันเดอร์โฟลว์, สินเชื่อแฟลช และ oracle กิจวัตร ด้วยเหตุนี้ Optimism จึงสามารถจับมูลค่าจำนวนมากได้ในระยะสั้น เวลา. การเลือกใช้เครื่องเสมือนอื่นหมายถึงต้องสร้างระบบนิเวศใหม่ทั้งหมด ด้วยความได้เปรียบจากอิสระในการดำเนินการที่มากขึ้น StarkNet ใช้งานบัญชีโดยกำเนิด นามธรรม ซึ่งเป็นกลไกที่แต่ละบัญชีเป็น smart contract ที่สามารถนำมาใช้ได้ ตรรกะตามอำเภอใจตราบใดที่มันสอดคล้องกับอินเทอร์เฟซ (ดังนั้นคำว่านามธรรม): สิ่งนี้อนุญาต การใช้รูปแบบลายเซ็นดิจิทัลที่แตกต่างกัน ความสามารถในการเปลี่ยนคีย์ส่วนตัวโดยใช้ ที่อยู่เดียวกัน หรือใช้ multisig ชุมชน Ethereum เสนอการแนะนำสิ่งนี้ กลไก EIP-2938 ในปี 2563 แต่ข้อเสนอดังกล่าวยังคงค้างอยู่นานกว่าหนึ่งปีเนื่องจาก การอัปเดตอื่นๆ มีลำดับความสำคัญมากกว่า [27] ประโยชน์ที่สำคัญอีกประการหนึ่งที่ได้รับจากความเข้ากันได้คือการนำไคลเอนต์ที่มีอยู่กลับมาใช้ใหม่: Optimism ใช้เวอร์ชันของ geth สำหรับโหนดของตัวเองโดยมีความแตกต่างเพียง 800 บรรทัดเท่านั้น พัฒนา ทดสอบ และบำรุงรักษามาตั้งแต่ปี 2014 การมีลูกค้าที่แข็งแกร่งถือเป็นสิ่งสำคัญตามที่กำหนดไว้ สิ่งที่ได้รับการยอมรับว่าถูกต้องหรือไม่อยู่ในเครือข่าย จุดบกพร่องในการใช้งานการพิสูจน์ข้อบกพร่อง ระบบอาจทำให้ข้อพิสูจน์ที่ไม่ถูกต้องได้รับการยอมรับว่าถูกต้องหรือข้อพิสูจน์ที่ถูกต้องสำหรับข้อที่ไม่ถูกต้อง ถือว่าบล็อกไม่ถูกต้อง ส่งผลให้ระบบเสียหาย ความน่าจะเป็นของประเภทนี้ การโจมตีสามารถจำกัดได้ด้วยความหลากหลายของไคลเอนต์ที่กว้างขึ้น: Optimism สามารถใช้ซ้ำได้ นอกเหนือจากการรับ ไคลเอนต์ Ethereum อื่น ๆ ได้รับการดูแลอยู่แล้ว และการพัฒนาไคลเอนต์ที่ใช้ Erigon อื่นก็คือ กำลังดำเนินการอยู่ ในปี 2559 เกิดปัญหาในการจัดการหน่วยความจำของ geth สำหรับ a การโจมตีแบบ DoS และแนวป้องกันแนวแรกคือแนะนำให้ใช้ Parity มากเป็นอันดับสอง ลูกค้าที่ใช้ในขณะนั้น 5. StarkNet ประสบปัญหาเดียวกันกับการพิสูจน์ความถูกต้อง แต่ลูกค้า จะต้องเขียนตั้งแต่เริ่มต้น และระบบพิสูจน์อักษรก็ซับซ้อนกว่ามาก และด้วยเหตุนี้ มันยังซับซ้อนกว่ามากในการรับรองความถูกต้อง

บทสรุป

1. บทสรุป Rollups เป็นโซลูชันที่มีแนวโน้มมากที่สุดที่มีอยู่ในปัจจุบันในการแก้ปัญหาความสามารถในการขยายขนาด การกระจายอำนาจ blockchains ปูทางไปสู่ยุคของโมดูลาร์ blockchains เมื่อเทียบกับ เสาหิน blockchains ทางเลือกในการพัฒนา Optimistic Rollup หรือ Validity Rollup จะแสดงไว้เป็นหลัก เป็นการแลกเปลี่ยนระหว่างความซับซ้อนและความคล่องตัว StarkNet มีข้อดีมากมาย เช่น รวดเร็ว การถอนตัว การไร้ความสามารถเชิงโครงสร้างเพื่อให้มีการเปลี่ยนสถานะที่ไม่ถูกต้อง ลดต้นทุนการทำธุรกรรมที่ ค่าใช้จ่ายของระยะเวลาการพัฒนาที่ยาวนานขึ้นและความเข้ากันไม่ได้กับ EVM ในขณะที่ Optimism มี ใช้ประโยชน์จากเศรษฐกิจแบบเครือข่ายเพื่อให้ได้ส่วนแบ่งตลาดที่สำคัญอย่างรวดเร็ว Optimism อย่างไรก็ตาม Bedrock มีการออกแบบแบบโมดูลาร์ที่ทำให้กลายเป็นสิ่งที่ใช้ได้ 5https://blog.ethereum.org/2016/09/22/ethereum-network-currently-undergoing-dos-attack

การยกเลิกในอนาคต: ปัจจุบัน Cannon ใช้ minigeth ที่คอมไพล์เป็น MIPS เพื่อพิสูจน์ข้อผิดพลาด แต่สถาปัตยกรรมเดียวกันสามารถใช้เพื่อรับวงจรและสร้างข้อพิสูจน์ความถูกต้องได้ การรวบรวมเครื่องที่ซับซ้อน เช่น EVM สำหรับสถาปัตยกรรมไมโครส่งผลให้ง่ายขึ้น วงจรที่ไม่ต้องดัดแปลงและตรวจสอบซ้ำในกรณีอัพเกรด RISC Zero คือ ก สถาปัตยกรรมไมโครที่ตรวจสอบได้พร้อมการพิสูจน์ STARK แล้วในการพัฒนาตาม RISC-V นั้น สามารถใช้เพื่อจุดประสงค์นี้เป็นทางเลือกแทน MIPS [28] แง่มุมหนึ่งที่ไม่ควรมองข้ามคือความซับซ้อนในการทำความเข้าใจวิธีการ เทคโนโลยีทำงาน จุดแข็งของ blockchains แบบดั้งเดิมคือสามารถตรวจสอบสถานะของได้ blockchain โดยไม่ไว้วางใจหน่วยงานบุคคลที่สามใดๆ อย่างไรก็ตาม ในกรณีของ StarkNet เป็นเช่นนั้น จำเป็นต้องเชื่อถือการดำเนินการเมื่อไม่สามารถตรวจสอบส่วนประกอบต่างๆ ได้ ขึ้นอยู่กับการเข้ารหัสและคณิตศาสตร์ขั้นสูง ซึ่งในขั้นต้นอาจสร้างความขัดแย้งให้กับ การนำเทคโนโลยีมาใช้ แต่เนื่องจากเครื่องมือและการใช้การพิสูจน์ความสมบูรณ์ก้าวหน้ายิ่งขึ้น นอกฟิลด์ blockchain หวังว่าปัญหานี้จะได้รับการแก้ไข