---
title: "Optimistic Rollup"
description: "คู่มือตาม deployment จริงว่าด้วย receipt ของ sequencer ข้อมูล derivation บน L1 สถานะ unsafe safe และ finalized เกม fault proof การถอนแบบ canonical การกำกับดูแล และ fast exit"
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Optimistic Rollup

> จัดทำขึ้นเพื่อการศึกษาเท่านั้น ไม่ใช่คำแนะนำการลงทุน การลงทุนอาจทำให้สูญเสียเงินลงทุนได้

<a id="answer"></a>

## คำตอบโดยตรง

Optimistic Rollup ประมวลผลกระแสธุรกรรมตามลำดับ และเผยแพร่ข้อมูล derivation กับ state claim ตามที่โปรโตคอลกำหนดโดยไม่แนบหลักฐานความถูกต้องกับทุก batch คำว่า "Optimistic" หมายถึง claim ที่เข้าเกณฑ์สามารถดำเนินต่อไปตามกฎของ deployment เว้นแต่ข้อพิพาท fault proof ที่สำเร็จจะพิสูจน์ว่า claim นั้นผิด ไม่ได้หมายความว่าข้อความจาก sequencer พิสูจน์ความถูกต้อง และไม่ได้หมายความว่าทุกระบบเปิดให้ท้าทายแบบ permissionless หรือมีระยะรอถอนเท่ากัน

โหนด rollup ทำ derivation บล็อก L2 อย่างอิสระจาก input ของ L1 ตามเชนหลักและ configuration ของโปรโตคอลที่ตรงรุ่น ดังนั้นเส้นทางความปลอดภัยจึงรวมถึงความพร้อมใช้งานของข้อมูล derivation และการประมวลผลที่ถูกต้อง ระบบ fault proof ที่ทำงานและน่าเชื่อถือ การเข้าถึงและ finality ของ L1 การกำกับดูแล และสัญญา bridge การมีเพียง state root ไม่เพียงพอสำหรับสร้างเชนขึ้นใหม่หรือท้าทายการเปลี่ยนสถานะที่ไม่ถูกต้อง

<a id="mechanism"></a>

## กลไกการทำงาน

1. ยืนยัน deployment ที่ใช้จริง ได้แก่ chain ID ของ L1 และ L2, configuration และ fork ของ rollup, สัญญา inbox และ bridge, รูปแบบ batch และโหมด DA, สัญญา state claim และเกมข้อพิพาท, เวอร์ชัน portal, ผู้ดูแล, guardian และบล็อกที่ใช้อ้างอิง เอกสารของ stack ไม่ใช่หลักฐานว่าทุกฟีเจอร์เปิดใช้งานบนเชนหนึ่งแล้ว
2. จำแนกสถานะที่สังเกตเห็น receipt ของ sequencer หรือบล็อก unsafe คือคำรับรองลำดับในเครื่องที่รวดเร็ว batch ที่เผยแพร่บน L1 อาจรองรับ safe head ที่ได้จาก derivation และ finality ของ L1 อาจรองรับ finalized head ที่ได้จาก derivation ส่วน state หรือ output claim ข้อพิพาทที่สิ้นสุด และการถอนที่ดำเนินการได้เป็นคนละวัตถุและใช้คนละนาฬิกา
3. สร้าง pipeline derivation จาก L1 สู่ L2 ขึ้นใหม่ ตรวจสอบ deposit และ input ที่จัดลำดับ channel และ batch, L1 origin, การเปลี่ยน configuration และ state transition จากข้อมูล L1 ตามเชนหลัก สำหรับข้อมูลที่ใช้ blob ต้องแยกความพร้อมใช้งานในช่วงของโปรโตคอลออกจากการค้นคืนจาก archive ในภายหลัง
4. ทำแผนผัง liveness และการควบคุม แยกบทบาท sequencer, batcher, proposer, challenger, relayer, guardian และอำนาจอัปเกรด ตรวจสอบว่ามีเส้นทาง forced inclusion หรือ delayed inbox หรือไม่ ระยะหน่วงและเงื่อนไข pause เป็นอย่างไร และผู้ใช้ทั่วไปมีซอฟต์แวร์ที่ใช้งานเส้นทางนั้นได้จริงหรือไม่
5. ตรวจสอบเส้นทาง fault proof ที่ deploy อยู่จริง บันทึก respected game type สิทธิ์ของ proposer และ challenger, bond, absolute prestate, โปรแกรมพิสูจน์และ VM, preimage oracle, ความลึกของ claim, นาฬิกาและส่วนขยาย, กฎการตัดสิน, อำนาจ blacklist หรือ pause และระยะหน่วงการอัปเกรด ห้ามนำกลไก OP Stack ไปใช้สรุป Arbitrum หรือ rollup อื่น
6. ติดตามการถอนและเศรษฐศาสตร์แยกจากกัน ไล่ตั้งแต่เริ่มบน L2 การพิสูจน์บน L1 การพึ่งพา claim หรือเกม ระยะ maturity และ finality การพิสูจน์ใหม่ การตรวจสอบของ portal จนถึงการประมวลผลบน L1 ให้ถือ fast exit เป็นธุรกรรมสภาพคล่องหรือสินเชื่อที่มีราคากับคู่สัญญาอีกฝ่าย ไม่ใช่นาฬิกาท้าทายแบบ canonical ที่สั้นลง
7. กระทบยอดอย่างต่อเนื่อง จับคู่แฮชบล็อก unsafe, safe และ finalized ธุรกรรม batch บน L1, state claim, ผลเกม, ข้อความ bridge, receipt, สัญญาโทเค็น และยอดคงเหลือสุดท้าย เปิดการวิเคราะห์ใหม่หลังการปรับโครงสร้าง L1 หรือ L2, batch สูญหาย, ข้อพิพาท, pause, การอัปเกรดสัญญา หรือการย้าย DA

<a id="example"></a>

## ตัวอย่างพร้อมคำนวณ

- **Payload สำหรับ derivation.** Batch หนึ่งมีธุรกรรม `10,000` รายการ input โปรโตคอลดิบ `1,200 KB` และเหลือ `300 KB` หลังบีบอัด อัตราส่วนคือ `1,200 / 300 = 4.0x` การลดลงคือ `1 - 300 / 1,200 = 75%` และค่าเฉลี่ยฐานสิบคือ `300,000 / 10,000 = 30 bytes/tx` ตัวเลขเหล่านี้อธิบายเฉพาะ payload input ที่เข้ารหัส ไม่ใช่ gas บน L1 ความถูกต้องของการประมวลผล ขนาดสถานะ หรือการรับประกัน archive
- **ส่วนต่างก่อนต้นทุนที่ยังไม่รวม.** ผู้ใช้จ่าย `2.4 ETH` การประมวลผล L2 ที่วัดได้คือ `0.3 ETH` และ DA บน L1 คือ `1.2 ETH` ส่วนต่างคือ `2.4 - 0.3 - 1.2 = 0.9 ETH` หรือ `0.9 / 10,000 = 0.00009 ETH/tx` ซึ่งไม่ใช่กำไรสุทธิ เพราะยังไม่รวมโครงสร้างพื้นฐานของ operator การประมวลผล L1 เกมพิสูจน์ refund เงินทุน ความล้มเหลว และภาษี
- **การระบุตำแหน่งข้อพิพาท.** Trace การประมวลผลตัวอย่างมี `2^20 = 1,048,576` ขั้น การลดช่วงแบบทวิภาคในอุดมคติต้องใช้ `log2(2^20) = 20` ตัวเลือกเพื่อแยกหนึ่งขั้น หากแต่ละรอบตัวอย่างมีค่าสูงสุดแยกกัน `3-hour` ขอบเขตเรียงต่อแบบง่ายคือ `20 * 3 = 60 hours` แต่โปรโตคอลจริงใช้นาฬิกาแบบหมากรุก การทำงานพร้อมกัน ส่วนขยาย และตารางธุรกรรมของตนเอง
- **นาฬิกาการถอนและสภาพคล่องด่วน.** Batch ตัวอย่างถึง L1 หลัง `10 minutes` มี claim ที่ได้รับการยอมรับหลังจากนั้นอีก `30 minutes` แล้วมีช่วงท้าทายสมมติ `7 days` และ relay สุดท้ายใช้ `2 hours` เวลารวมตามลำดับคือ `10 + 30 + 10,080 + 120 = 10,240 minutes = 7 days 2 hours 40 minutes` Bridge สภาพคล่องที่จ่ายล่วงหน้า `4.97 ETH` เทียบกับ claim `5 ETH` เรียกเก็บ `0.03 ETH` หรือ `0.03 / 5 = 0.6%` ขณะที่ claim แบบ canonical ยังอยู่ภายใต้นาฬิกาและความเสี่ยงเดิม

<a id="risks"></a>

## ความเสี่ยง

- เลือก L1, L2, chain ID, configuration ของ rollup หรือ deployment สัญญาผิด
- ถือ receipt จาก sequencer ที่ยัง unsafe ว่า safe หรือ final แล้ว
- Sequencer ให้ข้อมูลขัดกัน เซ็นเซอร์ เปลี่ยนลำดับ หรือหยุดทำงาน
- การเผยแพร่ batch บน L1 ล่าช้า สูญหาย ผิดรูปแบบ หรือไม่ถูกต้อง
- ข้อมูล blob หรือ DA ทางเลือกไม่พร้อมใช้งานหรือไม่ได้เก็บ archive
- Derivation client, configuration หรือ fork ไม่ตรงกัน
- การปรับโครงสร้าง L1 ทำให้ input derivation ที่เคย safe ใช้ไม่ได้
- Batcher, state proposer หรือผู้เข้าร่วมการพิสูจน์หยุดทำงาน
- เส้นทาง forced inclusion หรือ delayed inbox ไม่มี ถูก pause หรือถูกเข้าใจผิด
- Fault proof ยังไม่ deploy ไม่ active หรือผูกกับ game type ผิด
- บทบาท proposer หรือ challenger ต้องมีสิทธิ์หรืออยู่ใน allowlist
- Challenger offline ถูกเซ็นเซอร์ ทุนไม่พอ หรือพลาดกำหนดเวลา
- บั๊กในโปรแกรมพิสูจน์ VM, absolute prestate, oracle หรือ verifier
- ข้อผิดพลาดด้านนาฬิกา ส่วนขยาย ตำแหน่ง claim, bond หรือบัญชีการตัดสิน
- การแทรกแซงจาก guardian, security council, pause หรือ blacklist
- การอัปเกรดทันที timelock สั้น หรือคีย์ผู้ดูแลถูกเจาะ
- ช่องโหว่ของ canonical bridge, messenger, replay หรือการจับคู่สินทรัพย์
- การพิสูจน์ถอน maturity การพิสูจน์ใหม่ finalization หรือ relay ล้มเหลว
- ความเสี่ยงด้านสภาพคล่อง ราคา routing การล้มละลาย หรือคู่สัญญาของ fast exit
- สับสน finality ของ L1, finality ของ L2 ที่ได้จาก derivation, การตัดสิน claim และการได้รับสินทรัพย์

<a id="misconceptions"></a>

## ความเข้าใจผิดที่พบบ่อย

- Optimistic หมายถึงผู้ใช้ไว้วางใจผลที่ sequencer แสดงโดยไม่มีเงื่อนไข
- การเผยแพร่ state root เพียงอย่างเดียวให้ทั้งความพร้อมใช้งานของข้อมูลและ derivation อิสระ
- Optimistic Rollup ทุกระบบมี fault proof แบบ permissionless ที่ active และนาฬิกา 7 วันเหมือนกัน
- บล็อก L2 ที่ safe หรือ finalized หมายความว่าการถอน L2 ไป L1 ดำเนินการได้แล้ว
- Fast bridge ทำให้ช่วงท้าทายแบบ canonical สั้นลงหรือมีเพียงความเสี่ยงของ rollup

<a id="related"></a>

## หัวข้อที่เกี่ยวข้อง

- [Fault proof](/th/crypto/fraud-proof/)
- [ความพร้อมใช้งานของข้อมูล](/th/crypto/data-availability/)
- [Rollup](/th/crypto/rollup/)

<a id="sources"></a>

## แหล่งข้อมูล

- [Optimistic Rollups](https://ethereum.org/developers/docs/scaling/optimistic-rollups/) - Ethereum.org (เข้าถึงเมื่อ: 2026-08-13)
- [EIP-4844: Shard Blob Transactions](https://eips.ethereum.org/EIPS/eip-4844) - Ethereum Improvement Proposals (เข้าถึงเมื่อ: 2026-08-13)
- [Rollup Node](https://specs.optimism.io/protocol/rollup-node.html) - OP Stack Specification (เข้าถึงเมื่อ: 2026-08-13)
- [Derivation](https://specs.optimism.io/protocol/derivation.html) - OP Stack Specification (เข้าถึงเมื่อ: 2026-08-13)
- [Fault Proof](https://specs.optimism.io/fault-proof/index.html) - OP Stack Specification (เข้าถึงเมื่อ: 2026-08-13)
- [Optimism Portal](https://specs.optimism.io/fault-proof/stage-one/optimism-portal.html) - OP Stack Specification (เข้าถึงเมื่อ: 2026-08-13)
- [Stage 1 Roles and Requirements](https://specs.optimism.io/protocol/stage-1.html) - OP Stack Specification (เข้าถึงเมื่อ: 2026-08-13)
- [Arbitrum Nitro: A Second-Generation Optimistic Rollup](https://docs.arbitrum.io/nitro-whitepaper.pdf) - Offchain Labs (เข้าถึงเมื่อ: 2026-08-13)

Source: https://wiki.fcontext.com/th/crypto/optimistic-rollup/index.mdx