เอกสารไวท์เปเปอร์ บทความ รูปภาพ อภิธานศัพท์ กราฟ ค้นหา

Tài liệu kỹ thuật Optimism

โดย Optimism Collective · 2021

โหมดเดี่ยว community.optimism.io

Optimism ไม่มี whitepaper แบบดั้งเดิม ในฐานะ Ethereum Layer 2 optimistic rollup การออกแบบและข้อกำหนดของมันได้รับการจัดเก็บผ่านเอกสารทางเทคนิค, ข้อกำหนด OP Stack และบทความวิจัย แทนที่บทความวิชาการอย่างเป็นทางการฉบับเดียว

🇺🇸 English (ต้นฉบับ)
🇻🇳 Tiếng Việt (คำแปล)

บทคัดย่อ

เอกสารนี้กล่าวถึงปัญหาความสามารถในการปรับขนาดในการกระจายอำนาจ 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 กำหนด...

Tóm tắt

Bài viết giải quyết vấn đề về khả năng mở rộng trong blockchain phi tập trung bằng cách phân tích sự cân bằng giữa thông lượng giao dịch và yêu cầu phần cứng để chạy một nút. Bản tổng hợp, tức là các công nghệ để xác minh trên chuỗi các khối được thực hiện ngoài chuỗi, được trình bày dưới dạng bằng chứng lỗi hoặc tính hợp lệ. Chúng tôi so sánh Tổng hợp lạc quan và Tổng hợp hợp lệ về thời gian rút tiền, chi phí giao dịch, kỹ thuật tối ưu hóa và khả năng tương thích với hệ sinh thái Ethereum. Phân tích của chúng tôi cho thấy rằng Optimism Bedrock hiện có tốc độ nén khí xấp xỉ 20:1, trong khi StarkNet đạt được tốc độ nén chi phí ghi lưu trữ vào khoảng 24:1. Chúng tôi cũng thảo luận về các kỹ thuật để tối ưu hóa hơn nữa các tỷ lệ này, chẳng hạn như việc sử dụng hợp đồng bộ đệm và bộ lọc Bloom. Cuối cùng, kết luận của chúng tôi nêu bật sự cân bằng giữa độ phức tạp và tính linh hoạt trong việc lựa chọn giữa Tổng hợp lạc quan và hợp lệ. Từ khóa Blockchain, Khả năng mở rộng, Rollup 1. Giới thiệu Công nghệ Blockchain đã thu hút được sự chú ý đáng kể nhờ tiềm năng cách mạng hóa các ngành công nghiệp khác nhau. Tuy nhiên, khả năng mở rộng vẫn là một thách thức lớn, vì hầu hết blockchain phải đối mặt với sự đánh đổi giữa khả năng mở rộng, phân cấp và bảo mật, thường được gọi là Bộ ba bất khả thi về khả năng mở rộng [1, 2]. Để tăng thông lượng của blockchain, một giải pháp đơn giản là tăng kích thước khối của nó. Trong ngữ cảnh Ethereum, điều này có nghĩa là tăng lượng gas tối đa mà một khối có thể chứa. Vì mỗi nút đầy đủ phải xác thực mọi giao dịch của mọi khối nên khi thông lượng tăng lên, các yêu cầu về phần cứng cũng tăng lên, dẫn đến tính tập trung cao hơn của mạng. Một số blockchain, chẳng hạn như Bitcoin và Ethereum, tối ưu hóa thiết kế của họ để tối đa hóa khả năng phân cấp kiến ​​trúc của họ, trong khi những blockchain khác, chẳng hạn như Binance Smart Chain và Solana, được thiết kế để nhanh và rẻ nhất có thể. Mạng phi tập trung giới hạn một cách giả tạo thông lượng của blockchain để giảm yêu cầu phần cứng để tham gia vào mạng. Trong những năm qua, nhiều nỗ lực đã được thực hiện để tìm ra giải pháp cho Bộ ba bất khả thi, chẳng hạn như các kênh trạng thái [3] và Plasma [4, 5]. Các giải pháp này có đặc điểm là chuyển một số hoạt động ra khỏi chuỗi, liên kết hoạt động trên chuỗi với hoạt động ngoài chuỗi bằng cách sử dụng smart contracts và xác minh DLT 2023: Hội thảo công nghệ sổ cái phân tán lần thứ 5, ngày 25-26 tháng 5 năm 2023, Bologna, Ý $ [email protected] (L. Donno) https://lucadonnoh.github.io/ (L. Donno) 0000-0001-9221-3529 (L. Donno) © 2023 Bản quyền bài viết này thuộc về các tác giả. Được phép sử dụng theo Giấy phép Creative Commons Ghi công 4.0 Quốc tế (CC BY 4.0). Kỷ yếu hội thảo CEUR http://ceur-ws.org ISSN 1613-0073 Kỷ yếu hội thảo CEUR (CEUR-WS.org) trên chuỗi những gì đang diễn ra ngoài chuỗi. Tuy nhiên, cả kênh Plasma và kênh trạng thái đều bị hạn chế trong việc hỗ trợ smart contract chung. Các bản tổng hợp là blockchain (được gọi là Layer 2 hoặc L2) xuất bản các khối của chúng trên một blockchain (Layer 1 hoặc L1) khác và do đó kế thừa các thuộc tính đồng thuận, tính khả dụng của dữ liệu và bảo mật. Chúng, không giống như các giải pháp khác, hỗ trợ tính toán tùy ý. Tập hợp có ba thành phần chính: • Trình sắp xếp thứ tự: các nút nhận giao dịch Tổng hợp từ người dùng và kết hợp chúng thành một khối được gửi tới Layer 1. Khối này bao gồm ít nhất gốc trạng thái (ví dụ: gốc Merkle) và dữ liệu cần thiết để xây dựng lại và xác thực trạng thái. Layer 1 định nghĩa...

การแนะนำ

  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 เราวาด ข้อสรุปบางอย่าง

Giới thiệu

  1. Giới thiệu Công nghệ chuỗi khối đã thu hút được sự chú ý đáng kể do tiềm năng cách mạng hóa các ngành công nghiệp khác nhau. Tuy nhiên, khả năng mở rộng vẫn là một thách thức lớn vì hầu hết blockchain đều gặp phải sự đánh đổi giữa khả năng mở rộng, phân cấp và bảo mật, thường được gọi là Khả năng mở rộng Trilemma [1, 2]. Để tăng thông lượng của blockchain, một giải pháp tầm thường là để tăng kích thước khối của nó. Trong ngữ cảnh Ethereum, điều này có nghĩa là tăng mức tối đa lượng khí mà một khối có thể chứa. Vì mỗi nút đầy đủ phải xác thực mọi giao dịch của mọi khối, khi thông lượng tăng lên thì các yêu cầu về phần cứng cũng tăng lên, dẫn đến yêu cầu lớn hơn tập trung của mạng. Một số blockchain, chẳng hạn như Bitcoin và Ethereum, tối ưu hóa được thiết kế để tối đa hóa khả năng phân cấp kiến trúc của họ, trong khi những nền tảng khác, chẳng hạn như Binance Smart Chain và Solana, được thiết kế để nhanh và rẻ nhất có thể. Mạng phi tập trung giới hạn thông lượng của blockchain một cách giả tạo để hạ thấp yêu cầu phần cứng xuống tham gia vào mạng lưới. Trong những năm qua, người ta đã nỗ lực tìm ra giải pháp cho Bộ ba bất khả thi, chẳng hạn như nhà nước kênh [3] và Plasma [4, 5]. Các giải pháp này có đặc điểm là di chuyển một số hoạt động ngoài chuỗi, liên kết hoạt động trên chuỗi với hoạt động ngoài chuỗi bằng smart contracts và xác minh DLT 2023: Hội thảo Công nghệ sổ cái phân tán lần thứ 5, ngày 25-26 tháng 5 năm 2023, Bologna, Ý $ [email protected] (L. Donno) https://lucadonnoh.github.io/ (L. Donno) 0000-0001-9221-3529 (L. Donno) © 2023 Bản quyền của bài viết này thuộc về tác giả của nó. Được phép sử dụng theo Giấy phép Creative Commons Ghi công 4.0 Quốc tế (CC BY 4.0). CEUR Xưởng Thủ tục tố tụng http://ceur-ws.org ISSN 1613-0073 Kỷ yếu Hội thảo CEUR (CEUR-WS.org)trên chuỗi những gì đang xảy ra ngoài chuỗi. Tuy nhiên, cả hai kênh Plasma và trạng thái đều bị hạn chế về sự ủng hộ của họ đối với smart contracts chung. Các tập hợp là blockchain (được gọi là Layer 2 hoặc L2) xuất bản các khối của chúng trên một blockchain khác (Layer 1 hoặc L1) và do đó kế thừa các thuộc tính đồng thuận, tính khả dụng của dữ liệu và bảo mật. Họ, không giống như các giải pháp khác, hỗ trợ tính toán tùy ý. Bản tổng hợp có ba thành phần chính: • Trình sắp xếp: các nút nhận giao dịch Tổng hợp từ người dùng và kết hợp chúng thành một khối được gửi tới Layer 1. Khối này bao gồm ít nhất gốc trạng thái (ví dụ: Merkle root) và dữ liệu cần thiết để xây dựng lại và xác thực trạng thái. Layer 1 xác định chính tắc blockchain của L2 bằng cách thiết lập thứ tự của dữ liệu được xuất bản. • Nút cuộn đầy đủ: các nút lấy, xử lý và xác thực các khối Rollup từ Lớp 1 bằng cách xác minh rằng gốc là chính xác. Nếu một khối chứa các giao dịch không hợp lệ thì đó là bị loại bỏ, điều này ngăn cản Trình sắp xếp chuỗi tạo các khối hợp lệ bao gồm các khối không hợp lệ giao dịch. • Nút ánh sáng cuộn lên: các nút nhận khối cuộn lên từ Layer 1 nhưng không tính toán bản thân nhà nước mới. Họ xác minh rằng gốc trạng thái mới là hợp lệ bằng cách sử dụng các kỹ thuật chẳng hạn như bằng chứng lỗi hoặc tính hợp lệ. Bản tổng hợp đạt được khả năng mở rộng bằng cách giảm chi phí phân bổ của các giao dịch theo số lượng của người dùng tăng lên. Điều này là do chi phí đảm bảo tính hợp lệ của blockchain tăng tuyến tính liên quan đến chi phí xác minh các giao dịch riêng lẻ. Các bản cuộn khác nhau tùy theo cơ chế đảm bảo tính hợp lệ của việc thực hiện giao dịch tại các nút nhẹ: trong Optimistic Rollups nó được đảm bảo bởi một mô hình kinh tế và bằng chứng lỗi, trong khi Hiệu lực Rollups nó được đảm bảo bằng mật mã bằng cách sử dụng bằng chứng hợp lệ. Các nút ánh sáng có thể được triển khai dưới dạng smart contract trên Layer 1. Họ chấp nhận gốc rễ của trạng thái mới và xác minh tính hợp lệ hoặc bằng chứng lỗi: do đó, các bản tổng hợp này được gọi là Hợp đồng thông minh Bản cuộn. Nếu các nút nhẹ độc lập thì chúng được gọi là Bản tổng hợp có chủ quyền [6]. Ưu điểm của sử dụng Hợp đồng thông minh Rollup là để có thể xây dựng một cầu nối giảm thiểu sự tin cậy giữa hai bên blockchains: vì tính hợp lệ của trạng thái L2 được chứng minh cho L1, nên một hệ thống giao dịch từ L2 đến L1 có thể được thực hiện, cho phép rút tiền. Nhược điểm là chi phí của giao dịch phụ thuộc vào chi phí xác minh trạng thái trên L1: nếu lớp cơ sở bị bão hòa bởi các hoạt động khác, chi phí giao dịch trên Rollup cũng tăng lên. Các lớp dữ liệu và đồng thuận là những lớp quyết định tính bảo mật của hệ thống như họ xác định thứ tự của các giao dịch, ngăn chặn các cuộc tấn công và cung cấp dữ liệu để chứng minh trạng thái hiệu lực. Đóng góp giấy tờ Trong bài viết này, chúng tôi nghiên cứu Tổng hợp lạc quan và hợp lệ, hai cải tiến giải pháp cho Bộ ba bất khả thi về khả năng mở rộng, tập trung vào các triển khai đáng chú ý, chẳng hạn như Optimism Bedrock và StarkNet. Những đóng góp của chúng tôi bao gồm sự so sánh toàn diện về những giải pháp, phân tích thời gian rút tiền và thảo luận về cuộc tấn công có thể xảy ra vào Optimism Đá nền. Ngoài ra, chúng tôi tính toán tỷ lệ nén khí của chúng, cung cấp các tối ưu hóa dành riêng cho ứng dụng và trình bày những ưu điểm cũng như nhược điểm của việc loại bỏ Ethereum Máy ảo (EVM).

Cấu trúc giấy Bài viết được tổ chức như sau. Trong phần 2 Bản tổng hợp lạc quan là được giới thiệu bằng cách phân tích Optimism Bedrock. Trong phần 3 Bản tổng hợp hợp lệ được giới thiệu bởi phân tích StarkNet. Trong phần 4 chúng ta so sánh hai giải pháp. Cuối cùng, trong phần 5 chúng ta vẽ một số kết luận.

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

  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 และแทนที่ฐานข้อมูล มีการสอบถามไปยังโหนดอื่นเพื่อ รับภาพเบื้องต้น

Tổng hợp lạc quan

  1. Bản tổng hợp lạc quan Ý tưởng chấp nhận một cách lạc quan đầu ra của các khối mà không cần xác minh việc thực hiện chúng là đã có mặt trong báo cáo chính thức Bitcoin [7], thảo luận về các nút ánh sáng. Các nút này chỉ theo sau chuỗi tiêu đề bằng cách xác minh quy tắc đồng thuận, khiến chúng dễ bị chấp nhận khối chứa các giao dịch không hợp lệ trong trường hợp bị tấn công 51%. Nakamoto đề xuất giải quyết việc này vấn đề bằng cách sử dụng hệ thống “cảnh báo” để cảnh báo các nút ánh sáng rằng một khối chứa các giao dịch không hợp lệ. Cơ chế này lần đầu tiên được thực hiện bởi Al-Bassam, Sonnino và Buterin [8] trong đó có lỗi hệ thống bằng chứng dựa trên mã sửa lỗi [9] được sử dụng. Để có thể tạo điều kiện cho bằng chứng lỗi, điều cần thiết là dữ liệu từ tất cả các khối, bao gồm cả các khối không hợp lệ, có sẵn để mạng: đây là Vấn đề về tính khả dụng của dữ liệu, được giải quyết bằng cách sử dụng dữ liệu xác suất cơ chế lấy mẫu Thiết kế Optimistic Rollup đầu tiên được trình bày bởi John Adler và Mikerah Quintyne-Collins vào năm 2019 [10], trong đó các khối được xuất bản trên blockchain khác điều đó xác định sự đồng thuận của họ về việc đặt hàng. 2.1. Optimism Đá gốc Bedrock [11] là phiên bản mới nhất của Optimism, một Bản tổng hợp hợp đồng thông minh. Phiên bản trước, Máy ảo Optimistic (OVM) yêu cầu một trình biên dịch đặc biệt để biên dịch Solidity thành mã byte riêng: ngược lại, Bedrock hoàn toàn tương đương với EVM ở chỗ công cụ thực thi tuân theo thông số kỹ thuật của Giấy vàng Ethereum [12]. 2.1.1. Tiền gửi Người dùng có thể gửi tiền giao dịch thông qua hợp đồng trên Ethereum, Cổng thông tin Optimism bằng cách gọi hàm DepositTransaction. Khi một giao dịch được thực hiện, một Sự kiện TransactionDeposited được phát ra, mỗi nút trong Rollup sẽ lắng nghe để xử lý tiền gửi. Giao dịch ký gửi là giao dịch L2 có nguồn gốc từ L1. Nếu người gọi của là một hợp đồng, địa chỉ được chuyển đổi bằng cách thêm một giá trị không đổi vào nó: điều này ngăn cản các cuộc tấn công trong đó hợp đồng trên L1 có cùng địa chỉ với hợp đồng trên L2 nhưng có mã khác. Việc đưa vào L2 của giao dịch gửi tiền được đảm bảo bằng thông số kỹ thuật trong trình tự cửa sổ. Giao dịch đã gửi là loại giao dịch tương thích EIP-2718 mới [13] với tiền tố 0x7E, trong đó các trường được mã hóa rlp là: • byte32 sourceHash: hash xác định duy nhất nguồn của giao dịch. • địa chỉ từ: địa chỉ của người gửi. • địa chỉ tới: địa chỉ người nhận hoặc địa chỉ 0 nếu giao dịch gửi tiền là việc tạo hợp đồng.• uint256 mint: giá trị được tạo trên L2. • Giá trị uint256: giá trị được gửi tới người nhận. • dữ liệu byte: dữ liệu đầu vào. • byte gasLimit: giới hạn gas của giao dịch. sourceHash được tính là keccak256 hash của khối L1 hash và nhật ký L1 chỉ mục, xác định duy nhất một sự kiện trong một khối. Vì các giao dịch ký gửi được bắt đầu trên L1 nhưng được thực hiện trên L2 nên hệ thống cần có cơ chế thanh toán L1 cho lượng gas sử dụng cho L2. Một giải pháp là gửi ETH qua Cổng thông tin, nhưng điều này ngụ ý rằng mọi người gọi (ngay cả những người gọi gián tiếp) đều phải được đánh dấu là phải trả tiền và đây là không thể thực hiện được đối với nhiều dự án hiện có. Cách khác là đốt khí tương ứng trên L1. Gas 𝑔được phân bổ cho giao dịch ký gửi được gọi là gas được đảm bảo. Giá khí L2 trên L1 không được đồng bộ hóa tự động mà được ước tính bằng cơ chế tương tự như EIP-1559 [14]. Lượng gas tối đa được đảm bảo cho mỗi khối Ethereum là 8 triệu, với mục tiêu là 2 triệu. Số lượng 𝑐 ETH cần thiết để thanh toán gas trên L2 là 𝑐= 𝑔𝑏L2 trong đó 𝑏L2 là phí cơ bản trên L2. Hợp đồng trên L1 đốt cháy một lượng khí bằng 𝑐/𝑏L2. Gas dành để gọi Giao dịch gửi tiền được hoàn trả trên L2: nếu số tiền này lớn hơn lượng gas được đảm bảo, không có khí đốt. Giao dịch đầu tiên của khối rollup là giao dịch ký gửi thuộc tính L1, được sử dụng để đăng ký trên L2 triển khai trước các thuộc tính của khối Ethereum. Các thuộc tính mà predeploy cung cấp quyền truy cập là số khối, dấu thời gian, phí cơ sở, khối hash và trình tự số, là số khối của L2 so với khối L1 được liên kết (còn gọi là epoch); con số này được đặt lại khi một kỷ nguyên mới bắt đầu. 2.1.2. Trình tự Các nút Tổng hợp lấy chuỗi Optimism hoàn toàn từ Ethereum. Chuỗi này được mở rộng mỗi khi giao dịch mới được xuất bản trên L1 và các khối của nó được tổ chức lại mỗi lần Ethereum khối được tổ chức lại. Bản tổng hợp blockchain được chia thành các kỷ nguyên. Đối với mỗi 𝑛 số khối của Ethereum thì có 𝑛epoch tương ứng. Mỗi kỷ nguyên chứa ít nhất một khối và mỗi khối trong một kỷ nguyên chứa một giao dịch được ký gửi thuộc tính L1. Khối đầu tiên trong một kỷ nguyên chứa tất cả các giao dịch được gửi qua Cổng thông tin. Layer 2 khối cũng có thể chứa các giao dịch được sắp xếp theo trình tự, tức là các giao dịch được gửi trực tiếp đến Bộ sắp xếp thứ tự. Trình sắp xếp chuỗi chấp nhận các giao dịch từ người dùng và xây dựng các khối. Với mỗi khối, nó xây dựng một đợt sẽ được xuất bản vào Ethereum. Một số lô có thể được xuất bản theo cách nén, lấy tên kênh. Một kênh có thể được chia thành nhiều khung, trong trường hợp nó quá lớn để một giao dịch duy nhất. Một kênh được định nghĩa là nén với ZLIB [15] của mã hóa rlp lô. Các trường của một lô là số kỷ nguyên, kỷ nguyên hash, kỷ nguyên gốc hash, kỷ nguyên dấu thời gian và danh sách giao dịch. Cửa sổ tuần tự, được xác định bằng một kỷ nguyên, chứa số cố định 𝑤 của L1 liên tiếp các khối mà bước phái sinh lấy làm đầu vào để xây dựng số lượng khối L2 thay đổi. cho kỷ nguyên 𝑛, cửa sổ tuần tự 𝑛bao gồm các khối [𝑛, 𝑛+𝑤). Điều này ngụ ý rằng việc đặt hàng các giao dịch và khối L2 trong cửa sổ tuần tự không được cố định cho đến khi cửa sổ kết thúc. Giao dịch rollup được gọi là an toàn nếu lô chứa nó đã được xác nhận trên L1. Khungđược đọc từ các khối L1 để xây dựng lại các lô. Việc triển khai hiện tại không cho phép quá trình giải nén kênh bắt đầu cho đến khi nhận được tất cả các khung tương ứng. không hợp lệ lô được bỏ qua. Các giao dịch khối riêng lẻ được lấy từ các đợt, được được công cụ thực thi sử dụng để áp dụng các chuyển đổi trạng thái và thu được trạng thái Tổng hợp. 2.1.3. Rút tiền Để xử lý việc rút tiền, hệ thống nhắn tin L2-to-L1 được triển khai. Ethereum cần biết trạng thái L2 để chấp nhận rút tiền và điều này được thực hiện bằng cách xuất bản trên L2 Đầu ra Oracle smart contract trên L1 gốc trạng thái của mỗi khối L2. Những rễ này được chấp nhận một cách lạc quan là hợp lệ (hoặc đã hoàn thiện) nếu không có bằng chứng lỗi nào được thực hiện trong quá trình thời gian tranh chấp. Chỉ những địa chỉ được chỉ định là Người đề xuất mới có thể xuất bản các gốc đầu ra. Hiệu lực nguồn gốc đầu ra được khuyến khích bằng cách yêu cầu Người đề xuất đặt cọc một khoản tiền sẽ bị cắt giảm nếu họ cho thấy đã đề xuất một gốc không hợp lệ. Giao dịch được bắt đầu bằng cách gọi hàm bắt đầu Rút tiền khi triển khai trước trên L2 và sau đó hoàn tất trên L1 bằng cách gọi hàm FinalizeWithdrawalTransaction trên Cổng thông tin Optimism đã đề cập trước đó. Gốc đầu ra tương ứng với khối L2 được lấy từ L2 Output Oracle; nó là xác minh rằng nó đã được hoàn tất, tức là thời gian tranh chấp đã trôi qua; nó được xác minh rằng đầu ra Bằng chứng gốc khớp với Bằng chứng của Oracle; đã xác minh rằng đã bao gồm hash số tiền rút trong đó sử dụng Bằng chứng rút tiền; việc rút tiền vẫn chưa được hoàn tất; và sau đó là cuộc gọi đến địa chỉ đích được thực hiện, với giới hạn gas, lượng Ether và dữ liệu được chỉ định. 2.1.4. Cannon: hệ thống chống lỗi Nếu một Rollup Full Node, bằng cách thực hiện cục bộ các lô và giao dịch được gửi, phát hiện ra rằng trạng thái Layer 2 không khớp với gốc trạng thái được Người đề xuất xuất bản trên chuỗi, nó có thể thực thi bằng chứng lỗi trên L1 để chứng minh rằng kết quả của quá trình chuyển khối là không chính xác. Bởi vì chi phí chung, việc xử lý toàn bộ khối Rollup trên L1 là quá tốn kém. Giải pháp đã thực hiện của Bedrock chỉ thực hiện trên chuỗi chỉ dẫn đầu tiên về sự bất đồng của minigeth, biên dịch nó thành kiến trúc MIPS được thực thi trên trình thông dịch trực tuyến và được xuất bản trên L1. minigeth là phiên bản đơn giản của geth 1 trong đó sự đồng thuận, RPC và cơ sở dữ liệu đã được gỡ bỏ. Để tìm hướng dẫn đầu tiên về sự bất đồng, tìm kiếm nhị phân tương tác được tiến hành giữa người khởi xướng bằng chứng lỗi và người xuất bản gốc đầu ra. Khi bằng chứng bắt đầu, cả hai bên xuất bản gốc của trạng thái bộ nhớ MIPS trong quá trình thực thi khối trong hợp đồng Thử thách: nếu hash khớp thì có nghĩa là cả hai bên đều đồng ý về nửa đầu của quá trình thực hiện do đó xuất bản phần gốc của nửa sau, nếu không thì nửa của nửa đầu được xuất bản, v.v. Làm như vậy đạt được chỉ dẫn đầu tiên về sự bất đồng theo số bước logarit so với lần thực hiện ban đầu. Nếu một trong hai điểm dừng tương tác, khi kết thúc thời gian tranh chấp, người tham gia kia sẽ tự động thắng. Để xử lý hướng dẫn, trình thông dịch MIPS cần truy cập vào bộ nhớ của nó: vì gốc là sẵn có, các ô nhớ cần thiết có thể được xuất bản bằng cách chứng minh sự bao gồm của chúng. Để truy cập trạng thái của EVM, việc sử dụng được tạo ra từ Preimage Oracle: đưa ra hash của một khối mà nó trả về 1https://geth.ethereum.org/docs

tiêu đề khối, từ đó người ta có thể lấy hash của khối trước đó và quay lại chuỗi hoặc lấy hash trạng thái và nhật ký mà từ đó người ta có thể lấy tiền ảnh. oracle được minigeth triển khai và thay thế cơ sở dữ liệu. Các truy vấn được thực hiện tới các nút khác để có được những hình ảnh tiền đề.

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)

Bản tổng hợp hiệu lực

  1. Bản tổng hợp hiệu lực Mục tiêu của Tổng hợp tính hợp lệ là để chứng minh tính hợp lệ của quá trình chuyển đổi trạng thái bằng mật mã đưa ra chuỗi các giao dịch với bằng chứng ngắn có thể được xác minh dưới dạng so sánh tuyến tính đến thời điểm tính toán ban đầu. Các loại chứng chỉ này được gọi là bằng chứng toàn vẹn tính toán và được triển khai trên thực tế với SNARK (ARgument of Knowledge không tương tác ngắn gọn), sử dụng số học mạch làm mô hình tính toán của chúng. Việc triển khai SNARK khác nhau sẽ khác nhau về thời gian chứng minh, thời gian xác minh, nhu cầu thiết lập đáng tin cậy và khả năng kháng lượng tử [16, 17]. STARK (Có thể mở rộng Đối số kiến thức minh bạch) [18] là một loại SNARK không yêu cầu độ tin cậy thiết lập và có khả năng chống lượng tử, đồng thời mang lại một số hiệu quả trong việc chứng minh và xác minh so với các giải pháp khác. 3.1. StarkNet StarkNet là Bản tổng hợp hiệu lực hợp đồng thông minh được phát triển bởi StarkWare sử dụng STARK hệ thống bằng chứng để xác thực trạng thái của nó thành Ethereum. Để tạo thuận lợi cho việc xây dựng các bằng chứng có giá trị, một máy ảo khác với EVM được sử dụng, có ngôn ngữ cấp cao là Cairo. 3.1.1. Tiền gửi Người dùng có thể gửi tiền giao dịch qua hợp đồng vào Ethereum bằng cách gọi sendMessageToL2 chức năng. Thông báo được ghi lại bằng cách tính hash của nó và tăng bộ đếm. Trình sắp xếp chuỗi lắng nghe sự kiện LogMessageToL2 và mã hóa thông tin trong giao dịch StarkNet gọi một hàm của hợp đồng có trang trí l1_handler. Khi kết thúc quá trình thực hiện, khi bằng chứng về sự chuyển đổi trạng thái được tạo ra, việc tiêu thụ tin nhắn sẽ được đính kèm với nó và nó bị xóa bằng cách giảm bộ đếm của nó. Thông số kỹ thuật StarkNet không yêu cầu bao gồm các giao dịch ký gửi, do đó, gas cần có thị trường để khuyến khích Người sắp xếp chuỗi xuất bản chúng trên L2. Ở phiên bản hiện tại, vì Sequencer được tập trung và quản lý bởi StarkWare, chi phí của các giao dịch ký gửi chỉ được xác định bởi chi phí thực hiện khoản tiền gửi. Chi phí này được thanh toán bằng cách gửi ETH tới gửiMessageToL2. Các Ether này vẫn bị khóa trên L1 và được chuyển đến Bộ sắp xếp chuỗi vào ngày L1, khi giao dịch gửi tiền được đưa vào quá trình chuyển đổi trạng thái. Số lượng ETH được gửi, nếu giao dịch gửi tiền được bao gồm, được chi tiêu đầy đủ, bất kể lượng gas tiêu thụ trên L2. StarkNet không có hệ thống tự động cung cấp các thuộc tính khối L1. Ngoài ra, Fossil là một giao thức được phát triển bởi Oiler Network 2 cho phép, với hash của một chặn, mọi thông tin có được từ Ethereum bằng cách xuất bản các hình ảnh đầu tiên. 2https://www.oiler.network/3.1.2. Trình tự Trạng thái hiện tại của StarkNet có thể được bắt nguồn hoàn toàn từ Ethereum. Bất kỳ sự khác biệt trạng thái giữa các lần chuyển đổi được xuất bản trên L1 dưới dạng calldata. Sự khác biệt được công bố cho từng hợp đồng và được lưu dưới dạng uint256[] với mã hóa sau: • Số lĩnh vực liên quan đến triển khai hợp đồng. • Đối với từng hợp đồng được công bố: – Địa chỉ hợp đồng được công bố. – hash của hợp đồng đã công bố. – Số lượng đối số của người xây dựng hợp đồng. – Danh sách các đối số của hàm tạo • Số hợp đồng đã được sửa đổi lưu trữ. • Đối với mỗi hợp đồng được sửa đổi: – Địa chỉ của hợp đồng sửa đổi. – Số lượng cập nhật lưu trữ. – Cặp khóa-giá trị của địa chỉ lưu trữ với các giá trị mới. Sự khác biệt về trạng thái được công bố theo thứ tự, do đó chỉ cần đọc chúng một cách tuần tự là đủ xây dựng lại nhà nước. 3.1.3. Rút tiền Để gửi tin nhắn từ L2 đến L1, syscall send_message_to_L1 được sử dụng. Tin nhắn là được xuất bản lên L1 bằng cách tăng bộ đếm hash của nó cùng với bằng chứng và được hoàn thiện bằng cách gọi hàm tiêu thụMessageFromL2 trên StarkGate smart contract trên L1, hàm này giảm dần quầy. Bất kỳ ai cũng có thể hoàn tất việc rút tiền. 3.1.4. Bằng chứng hiệu lực Máy ảo Cairo [19] được thiết kế để hỗ trợ việc xây dựng các bằng chứng STARK. Ngôn ngữ Cairo cho phép mô tả tính toán bằng chương trình cấp cao ngôn ngữ, và không trực tiếp như một mạch. Điều này được thực hiện bằng hệ phương trình đa thức 3 thể hiện một phép tính đơn lẻ: chu trình FDE của kiến trúc von Neumann. số do đó, các ràng buộc là cố định và độc lập với loại tính toán, chỉ cho phép một Chương trình xác minh cho mọi chương trình có tính toán cần được chứng minh. StarkNet tổng hợp nhiều giao dịch thành một bằng chứng STARK duy nhất bằng cách sử dụng một bằng chứng được chia sẻ có tên là SHARP. Bằng chứng được gửi tới smart contract vào ngày Ethereum để xác minh tính hợp lệ của chúng và cập nhật gốc Merkle tương ứng với trạng thái mới. Chi phí tuyến tính để xác minh một bằng chứng hợp lệ cho phép chi phí của nó được khấu hao qua nhiều giao dịch. 3gọi là Biểu diễn trung gian đại số (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 ประสบปัญหาเดียวกันกับการพิสูจน์ความถูกต้อง แต่ลูกค้า จะต้องเขียนตั้งแต่เริ่มต้น และระบบพิสูจน์อักษรก็ซับซ้อนกว่ามาก และด้วยเหตุนี้ มันยังซับซ้อนกว่ามากในการรับรองความถูกต้อง

So sánh

  1. So sánh 4.1. Thời gian rút tiền Khía cạnh quan trọng nhất giúp phân biệt Bản tổng hợp lạc quan với Bản tổng hợp hợp lệ là thời gian trôi qua kể từ khi bắt đầu rút tiền cho đến khi hoàn tất việc rút tiền. Trong cả hai trường hợp, việc rút tiền được khởi tạo trên L2 và hoàn tất trên L1. Vào StarkNet, việc quyết toán có thể thực hiện được vì ngay khi bằng chứng hợp lệ của gốc trạng thái mới được chấp nhận vào Ethereum: về mặt lý thuyết, đó là có thể rút tiền trong khối đầu tiên của L1 sau khi khởi tạo. Trong thực tế, tần suất gửi bằng chứng hợp lệ trên Ethereum là sự cân bằng giữa tốc độ chặn hoàn thiện và tổng hợp bằng chứng. Hiện StarkNet cung cấp bằng chứng hợp lệ để xác minh cứ sau 10 giờ 4, nhưng nó dự định sẽ giảm khi hoạt động giao dịch tăng lên. Trên Optimism Bedrock, chỉ có thể hoàn tất việc rút tiền khi tranh chấp kết thúc khoảng thời gian (hiện tại là 7 ngày), sau đó root sẽ tự động được coi là hợp lệ. Chiều dài của khoảng thời gian này chủ yếu được xác định bởi thực tế là các bằng chứng lỗi có thể được kiểm duyệt trên Ethereum cho đến khi sự kết thúc của nó. Xác suất thành công của kiểu tấn công này giảm theo cấp số nhân khi thời gian tăng lên: E[giá trị bị trừ] = 𝑉𝑝𝑛 trong đó 𝑛 là số khối trong một khoảng, 𝑉 là số tiền có thể bị trừ bằng cách xuất bản một gốc không hợp lệ và 𝑝là xác suất thực hiện kiểm duyệt thành công tấn công trong một khối duy nhất. Giả sử xác suất này là 99%, giá trị bị khóa trong Rollup là một triệu Ether và số khối trong một khoảng là 1800 (6 giờ khối với 12 giờ khoảng thời gian giây): giá trị dự kiến là khoảng 0,01391 Ether. Hệ thống được đảm bảo an toàn bởi yêu cầu Người đề xuất đặt cược số lượng Ether lớn hơn nhiều so với giá trị dự kiến. Winzer và cộng sự. đã chỉ ra cách thực hiện một cuộc tấn công kiểm duyệt bằng cách sử dụng smart contract đơn giản điều đó đảm bảo rằng các vùng bộ nhớ nhất định ở trạng thái không thay đổi [20]. Mô hình hóa cuộc tấn công như một trò chơi Markov, bài báo cho thấy rằng kiểm duyệt là chiến lược chủ đạo cho một nhà sản xuất khối nếu họ nhận được nhiều tiền bồi thường hơn mức bao gồm giao dịch thay đổi bộ nhớ. Giá trị 𝑝được thảo luận ở trên có thể được xem là phần trăm của khối hợp lý các nhà sản xuất trong mạng lưới, nơi “hợp lý” không tính đến việc có thể bị phạt các yếu tố bên ngoài, chẳng hạn như ít tin tưởng hơn vào blockchain làm giảm giá trị tiền điện tử của nó. Đoạn mã sau trình bày một smart contract có thể được sử dụng để thực hiện một cuộc tấn công kiểm duyệt trên Bedrock. Cuộc tấn công khai thác động cơ của các nhà sản xuất khối bằng cách đưa hối lộ cho họ để kiểm duyệt các giao dịch có thể sửa đổi các phần cụ thể của bang. Hợp đồng chính chức năng, requireBribe, cho phép các nhà sản xuất khối nhận hối lộ nếu họ kiểm duyệt thành công giao dịch được nhắm mục tiêu bằng cách kiểm tra xem gốc đầu ra không hợp lệ không được chạm vào. hàm requireBribe(byte bộ nhớ storageProof) bên ngoài { require(!claimed[block.number], "đã nhận hối lộ"); Dòng điện bộ nhớ đề xuất đầu ra = storageOracle.getStorage(L2_ORACLE, block.number, SLOT, lưu trữProof); require(invalidOutputRoot == current.outputRoot, "tấn công thất bại"); đã xác nhận quyền sở hữu[block.number] = true; (bool đã gửi, ) = block.coinbase.call{value: hối lộAmount}(""); 4https://etherscan.io/address/0xc662c410c0ecf747543f5ba90660f6abebd9c8c4require(đã gửi, "không gửi được ether"); } Liệt kê 1: Ví dụ về một hợp đồng khuyến khích cuộc tấn công kiểm duyệt vào Bedrock. Độ dài của thời gian tranh chấp cũng phải tính đến thực tế là bằng chứng lỗi được bằng chứng tương tác và do đó phải cung cấp đủ thời gian để người tham gia tương tác và mọi tương tác đều có thể bị kiểm duyệt. Nếu nước đi cuối cùng xảy ra vào thời điểm rất gần với khi kết thúc thời gian tranh chấp, chi phí kiểm duyệt sẽ ít hơn đáng kể. Mặc dù kiểm duyệt là chiến lược thống trị, khả năng thành công sẽ thấp hơn vì các nút kiểm duyệt dễ bị tấn công Tấn công từ chối dịch vụ: kẻ tấn công có thể tạo ra các giao dịch rất phức tạp kết thúc bằng công bố bằng chứng lỗi miễn phí vì sẽ không phải trả phí. Trong những trường hợp đặc biệt, thời gian tranh chấp kéo dài cho phép phối hợp trong trường hợp giải quyết thành công. tấn công kiểm duyệt để tổ chức một fork và loại trừ các nhà sản xuất khối tấn công. Khác cuộc tấn công có thể xảy ra bao gồm việc xuất bản nhiều đề xuất gốc cấp bang hơn mức mà các bên tranh chấp có thể xác minh, có thể tránh được bằng cách sử dụng giới hạn tần số. 4.1.1. Rút tiền lạc quan nhanh chóng Vì tính hợp lệ của Tổng hợp lạc quan có thể được xác minh bất kỳ lúc nào bởi bất kỳ Nút đầy đủ nào, nên đáng tin cậy oracle có thể được sử dụng để biết trên L1 liệu việc rút tiền có thể được hoàn tất một cách an toàn hay không. Cái này cơ chế được đề xuất lần đầu tiên bởi Maker [21]: oracle xác minh việc rút tiền, xuất bản kết quả trên L1 trong đó khoản vay chịu lãi được gán cho người dùng, kết quả này được tự động đóng cửa sau 7 ngày, tức là khi việc rút tiền thực sự có thể được hoàn tất. Giải pháp này đưa ra một giả định về độ tin cậy, nhưng trong trường hợp của Maker, nó được giảm thiểu do toán tử oracle được quản lý bởi cùng một tổ chức chịu rủi ro bằng cách cung cấp khoản vay. 4.2. Chi phí giao dịch Chi phí của giao dịch L2 chủ yếu được xác định bởi sự tương tác với L1. Trong cả hai giải pháp chi phí tính toán của các giao dịch rất rẻ vì nó được thực hiện hoàn toàn ngoài chuỗi. Optimism xuất bản dữ liệu cuộc gọi giao dịch L2 dưới dạng dữ liệu cuộc gọi và hiếm khi (hoặc không bao giờ) thực hiện lỗi bằng chứng, do đó calldata là tài nguyên đắt nhất. Vào ngày 12 tháng 1 năm 2022, mạng Bedrock đã được khởi chạy trên mạng thử nghiệm Goerli của Ethereum. Có thể tính được tốc độ nén khí bằng cách theo dõi lượng gas được sử dụng trên Bedrock trong một khoảng thời gian nhất định và bằng cách so sánh nó với lượng gas tiêu tốn cho L1 cho các khối tương ứng. Sử dụng phương pháp này để nén khí tỷ lệ ∼20: 1 được tìm thấy, nhưng con số này có thể khác với hoạt động thực tế trên mạng chính. StarkNet xuất bản trên Ethereum mọi thay đổi ở trạng thái L2 dưới dạng dữ liệu cuộc gọi, do đó dung lượng lưu trữ sẽ bị hạn chế nguồn tài nguyên đắt giá nhất. Vì mạng không sử dụng EVM nên chi phí giao dịch nén không thể được ước tính tầm thường. Bằng cách giả định chi phí thực hiện và lệnh gọi tới không đáng kể, có thể tính được tỷ lệ nén của việc ghi lưu trữ so với L1. Giả sử không có hợp đồng nào được triển khai và 10 ô chưa được truy cập trước đó trên StarkNet được đã sửa đổi, tỷ lệ nén chi phí ghi lưu trữ là ∼24: 1. Nếu một ô bị ghi đè 𝑛lần giữa các lần xuất bản dữ liệu, chi phí cho mỗi lần ghi sẽ là 1/𝑛so với chi phí của một lần viết, vì chỉ có lần cuối cùng được xuất bản. Chi phí có thể được giảm thiểu hơn nữa bằng cáchnén các giá trị được sử dụng thường xuyên. Chi phí xác minh bằng chứng hợp lệ được chia cho các giao dịch mà nó đề cập đến: ví dụ: StarkNet khối 4779 chứa 200 giao dịch và bằng chứng hợp lệ tiêu tốn 267830 đơn vị gas hoặc 1339,15 gas cho mỗi giao dịch. 4.2.1. Tối ưu hóa dữ liệu cuộc gọi: hợp đồng bộ đệm Trình bày bên dưới là smart contract triển khai bộ nhớ đệm địa chỉ cho các địa chỉ được sử dụng thường xuyên địa chỉ bằng cách tận dụng thực tế là việc lưu trữ và thực thi ít tốn kém hơn nhiều tài nguyên, cùng với hợp đồng Bạn bè thể hiện việc sử dụng nó. Cái sau theo dõi “bạn bè” của một địa chỉ có thể được đăng ký bằng cách gọi hàm addFriend. Nếu một địa chỉ đã được sử dụng ít nhất một lần, nó có thể được thêm bằng cách gọi addFriendWithCache chức năng: các chỉ mục bộ đệm là số nguyên 4 byte trong khi địa chỉ được biểu thị bằng 20 byte, vì vậy có mức tiết kiệm 5:1 cho đối số hàm. Logic tương tự có thể được sử dụng cho dữ liệu khác các loại như số nguyên hoặc nói chung hơn là byte. hợp đồng Địa chỉCache { ánh xạ (địa chỉ => uint32) địa chỉ công cộng2key; địa chỉ[] public key2address; hàm cacheWrite(address _address) trả về nội bộ (uint32) { require(key2address.length < type(uint32).max, "AddressCache: bộ đệm đã đầy"); require(address2key[_address] == 0, "AddressCache: địa chỉ đã được lưu vào bộ nhớ đệm"); // khóa phải bắt đầu từ 1 vì 0 có nghĩa là "không tìm thấy" khóa uint32 = uint32(key2address.length + 1); address2key[_address] = khóa; key2address.push(_address); chìa khóa trả lại; } hàm cacheRead(uint32 _key) chế độ xem công khai trả về (địa chỉ) { require(_key <= key2address.length && _key > 0, "AddressCache: không tìm thấy khóa"); trả về key2address[_key - 1]; } } Liệt kê 2: Hợp đồng bộ nhớ đệm địa chỉ. hợp đồng Bạn bè là Địa chỉCache { ánh xạ (địa chỉ => địa chỉ []) bạn bè công khai; hàm addFriend(địa chỉ _friend) công khai { bạn bè[msg.sender].push(_friend); cacheWrite(_friend); } hàm addFriendWithCache(uint32 _friendKey) public { bạn bè[msg.sender].push(cacheRead(_friendKey)); } hàm getFriends() chế độ xem công khai trả về (địa chỉ [] bộ nhớ) { trả lại bạn bè[msg.sender];} } Liệt kê 3: Ví dụ về một hợp đồng kế thừa bộ đệm địa chỉ. Hợp đồng hỗ trợ trong bộ đệm khoảng 4 tỷ (232) địa chỉ và việc thêm một byte sẽ mang lại khoảng 1 nghìn tỷ (240). 4.2.2. Tối ưu hóa lưu trữ: Bộ lọc của Bloom Trên StarkNet có một số kỹ thuật để giảm thiểu mức sử dụng bộ nhớ. Nếu không cần thiết phải đảm bảo tính sẵn có của dữ liệu gốc thì chỉ cần lưu hash trên chuỗi của nó là đủ: cái này là cơ chế được sử dụng để lưu dữ liệu cho ERC-721 (NFT) [22], tức là liên kết IPFS giải quyết vấn đề hash dữ liệu nếu có. Đối với dữ liệu được lưu trữ nhiều lần, có thể sử dụng tra cứu bảng tương tự như hệ thống bộ nhớ đệm được giới thiệu cho Optimism, yêu cầu tất cả giá trị phải được lưu tại ít nhất một lần. Đối với một số ứng dụng, có thể tránh việc lưu tất cả các giá trị bằng cách sử dụng bộ lọc Bloom [23, 24, 25], tức là cấu trúc dữ liệu xác suất cho phép người ta biết chắc chắn liệu một phần tử không thuộc về một tập hợp nhưng thừa nhận một xác suất sai nhỏ nhưng không đáng kể tích cực. Bộ lọc Bloom được khởi tạo dưới dạng mảng 𝑚bit ở mức 0. Để thêm một phần tử, các hàm 𝑘hash với sự phân bố ngẫu nhiên đồng đều được sử dụng, mỗi ánh xạ tới một bit của mảng được đặt đến 1. Để kiểm tra xem một phần tử có thuộc tập hợp hay không, chúng tôi chạy các hàm 𝑘hash và xác minh rằng các 𝑘bit được đặt thành 1. Trong bộ lọc Bloom đơn giản, không có cách nào để phân biệt liệu một phần tử thực sự thuộc về tập hợp hoặc là dương tính giả, xác suất tăng theo số số mục tăng lên. Sau khi chèn phần tử 𝑛: P[dương tính giả] = (︃ 1 − [︂ 1 −1 𝑚 ]︂𝑘𝑛)︃𝑘 ≈ (︁ 1 −𝑒−𝑘𝑛/𝑚)︁𝑘 giả định tính độc lập của xác suất của mỗi tập hợp bit. Nếu 𝑛 phần tử (có kích thước tùy ý!) dự kiến sẽ được đưa vào và xác suất cho phép dương tính giả là 𝑝, kích thước của mảng có thể được tính như sau: 𝑚= −𝑛ln 𝑝 (ln 2)2 Trong khi số hàm hash tối ưu là: 𝑘= 𝑚 𝑛ln 2 Nếu chúng ta giả sử chèn 1000 phần tử với dung sai 1% thì kích thước của mảng là 9585 bit với 𝑘= 6, trong khi với dung sai 0,1%, nó trở thành 14377 bit với 𝑘= 9. Nếu một triệu phần tử dự kiến sẽ được chèn vào, kích thước của mảng sẽ trở thành khoảng 1170 kB cho 1% và 1775 kB cho 0,1%, có cùng giá trị 𝑘, vì nó chỉ phụ thuộc vào 𝑝[26]. Trong một trò chơi mà người chơi không được phân công vào đối thủ mà họ đã thách đấu, thay vì lưu vào bộ nhớ cho mỗi người chơi danh sách các đối thủ trong quá khứ, người ta có thể sử dụng Bloom bộ lọc. Rủi ro không thách thức một số người chơi thường có thể chấp nhận được và bộ lọc có thể được đặt lại định kỳ.4.3. Ethereum khả năng tương thích Ưu điểm chính của việc tương thích với EVM và Ethereum là sử dụng lại tất cả các tính năng có sẵn công cụ. Ethereum smart contracts có thể được xuất bản trên Optimism mà không cần sửa đổi hay các cuộc kiểm toán mới. Ví vẫn tương thích, các công cụ phát triển và phân tích tĩnh, phân tích chung công cụ, công cụ lập chỉ mục và oracle. Ethereum và Solidity có lịch sử lâu đời được nghiên cứu kỹ lưỡng các lỗ hổng bảo mật, chẳng hạn như các cuộc tấn công vào lại, tràn và tràn, flash loan và oracle thao tác. Vì điều này, Optimism đã có thể nắm bắt được một lượng lớn giá trị trong thời gian ngắn thời gian. Việc chọn sử dụng một máy ảo khác đồng nghĩa với việc phải xây dựng lại toàn bộ hệ sinh thái, với lợi thế là có quyền tự do thực hiện lớn hơn. StarkNet thực hiện tài khoản sự trừu tượng hóa, là một cơ chế trong đó mỗi tài khoản là một smart contract có thể triển khai logic tùy ý miễn là nó tuân thủ một giao diện (do đó có thuật ngữ trừu tượng): điều này cho phép việc sử dụng các sơ đồ chữ ký số khác nhau, khả năng thay đổi khóa riêng bằng cách sử dụng cùng một địa chỉ hoặc sử dụng multisig. Cộng đồng Ethereum đề xuất giới thiệu tính năng này cơ chế với EIP-2938 vào năm 2020, nhưng đề xuất này vẫn tồn tại hơn một năm vì các bản cập nhật khác được ưu tiên hơn [27]. Một lợi ích quan trọng khác thu được từ tính tương thích là khả năng sử dụng lại các ứng dụng khách hiện có: Optimism sử dụng một phiên bản geth cho nút riêng của nó chỉ với ∼800 dòng khác nhau, đã được được phát triển, thử nghiệm và duy trì từ năm 2014. Có một khách hàng mạnh mẽ là rất quan trọng vì nó xác định những gì được chấp nhận là hợp lệ hay không có trong mạng. Một lỗi trong việc thực hiện bằng chứng lỗi hệ thống có thể khiến bằng chứng không chính xác được chấp nhận là đúng hoặc bằng chứng chính xác cho một bằng chứng không hợp lệ khối được chấp nhận là không chính xác, làm tổn hại đến hệ thống. Khả năng xảy ra loại này cuộc tấn công có thể được hạn chế với sự đa dạng của khách hàng rộng hơn: Optimism có thể sử dụng lại ngoài việc lấy các ứng dụng khách Ethereum khác đã được duy trì và việc phát triển một ứng dụng khách khác dựa trên Erigon đang được tiến hành đã được tiến hành. Vào năm 2016, một vấn đề trong việc quản lý bộ nhớ của geth đã bị khai thác để Tấn công DoS và tuyến phòng thủ đầu tiên là khuyến nghị sử dụng Parity, tuyến phòng thủ thứ hai ứng dụng khách đã sử dụng tại thời điểm đó 5. StarkNet gặp phải vấn đề tương tự với bằng chứng hợp lệ, nhưng ứng dụng khách phải được viết từ đầu và hệ thống chứng minh phức tạp hơn nhiều, và do đó nó cũng phức tạp hơn nhiều để đảm bảo tính chính xác.

บทสรุป

  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 หวังว่าปัญหานี้จะได้รับการแก้ไข

Phần kết luận

  1. Kết luận Rollups là giải pháp hứa hẹn nhất hiện nay để giải quyết vấn đề về khả năng mở rộng trong blockchains phi tập trung, mở đường cho kỷ nguyên blockchain mô-đun trái ngược với nguyên khối blockchains. Lựa chọn phát triển Tổng hợp lạc quan hoặc Tổng hợp hợp lệ chủ yếu được hiển thị như một sự đánh đổi giữa sự phức tạp và sự nhanh nhẹn. StarkNet có nhiều ưu điểm như nhanh rút tiền, cấu trúc không có khả năng chuyển đổi trạng thái không hợp lệ, chi phí giao dịch thấp hơn tại chi phí cho thời gian phát triển dài hơn và tính không tương thích với EVM, trong khi Optimism có tận dụng nền kinh tế mạng để nhanh chóng chiếm được thị phần lớn trên thị trường. Optimism Tuy nhiên, Bedrock sở hữu thiết kế mô-đun cho phép nó trở thành Hiệu lực 5https://blog.ethereum.org/2016/09/22/ethereum-network-currently-undergoing-dos-attack

Cập nhật trong tương lai: Cannon hiện đang sử dụng minigeth được biên dịch thành MIPS để kiểm tra lỗi của nó hệ thống, nhưng kiến trúc tương tự có thể được sử dụng để thu được một mạch điện và tạo ra các bằng chứng hợp lệ. Việc biên dịch một máy phức tạp như EVM cho một vi kiến trúc sẽ mang lại kết quả đơn giản hơn mạch không cần phải sửa đổi và xác minh lại trong trường hợp nâng cấp. RISC Zero là một vi kiến trúc có thể xác minh được với bằng chứng STARK đã được phát triển dựa trên RISC-V rằng có thể được sử dụng cho mục đích này thay thế cho MIPS [28]. Một khía cạnh không nên đánh giá thấp là sự phức tạp trong việc hiểu cách thức công nghệ hoạt động. Điểm mạnh của blockchain truyền thống là có thể xác minh trạng thái của blockchain mà không tin cậy bất kỳ thực thể bên thứ ba nào. Tuy nhiên, trong trường hợp StarkNet, đó là cần thiết phải tin tưởng vào việc triển khai khi không thể xác minh các thành phần khác nhau dựa trên mật mã và toán học nâng cao. Điều này ban đầu có thể tạo ra xích mích đối với việc áp dụng công nghệ, nhưng khi các công cụ và việc sử dụng bằng chứng về tính toàn vẹn ngày càng phát triển bên ngoài trường blockchain hy vọng vấn đề này sẽ được giải quyết.