คุณรู้จัก Optimism Superchain ดีแค่ไหน? มาลองทำความรู้จักมุมใหม่ ที่ Karl Floersch Co-Founder ของ OP จะมาขยายความแบบเจาะลึกกับ 4 คอนเซปต์ที่แตกต่างและสามารถทำให้เป็นจริงได้ โดยยกมาจาก ETHDenver ถอดความมาให้อ่านกันง่ายๆ พร้อมแล้วไปดูกันเลย

เนื้อหาในบทความนี้ถอดความมาจากคลิปนี้ สามารถไปดูตัวเต็มๆ ได้เลย

หรือสำหรับใครที่เพิ่งเคยได้ยินเรื่อง Superchain ก็สามารถปูพื้นฐานได้ที่นี่ แต่ถ้าใครพร้อมแล้วก็ไปต่อกันเลย

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

แล้วถ้าปัญหาเหล่านี้หายไปจะเกิดอะไรขึ้น? เริ่มจากลองจินตนาการถึงโลกอนาคตที่ Smart Contract สามารถ deploy ได้ โดยมีต้นทุนที่ต่ำมากๆ เราสามารถทำ Tx หากัน หรือทดลองอะไรสนุกๆ ก็ได้เต็มที่

ปัญหาที่ค่อยๆ ถูกแก้ไข เมื่อทุกอย่างในโลกนี้ถูกรันบน Blockchain จะเป็นยังไง?

1. ไม่ต้องปวดหัวกับปัญหา Server เพราะ EVM คือขั้นสุดยอดแพลทฟอร์มแบบ Serverless (ไม่ต้องการ server) แค่เพียงคุณ Deploy ทำให้ Smart Contract นั้นจะอยู่บนเชนตลอดกาล หมดปัญหาเซิร์ฟล่ม

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

3. ลดค่าใช้จ่ายแรกเริ่มสำหรับ Dev อยากขยายแบนวิธก็ไม่มีค่าใช้จ่ายเพิ่ม ทำให้สามารถช่วยลดต้นทุนในการดำเนินธุรกิจ โดยเฉพาะในช่วงเริ่มต้นได้อย่างดี

ทั้งสามข้อนี้เป็นตัวอย่างแค่บางส่วนที่ช่วยทำให้โลกของ Decentralized Web เป็นจริงได้

ซึ่ง OP ก็พยายามทำมาตลอดตั้งแต่ ETH2.0 > Plasma group จนถึง OP โดยตอนนี้ก็มีทุกคนๆ มาร่วมช่วยกันพัฒนา นี่คือสเน่ห์ของความเป็น Open-Source

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

Superchain แตกต่างจาก Multichain ที่มีปัญหาดังนี้

1. ปัญหาเรื่องความปลอดภัยที่เพิ่มความซับซ้อนเมื่อแต่ละเชนมีสถาปัตยกรรมการออกแบบที่แตกต่างกัน เชน A + เชน B + เชน C แฮกเกอร์อาจเจอจุดอ่อนระหว่าง B/C และใช้โจมตีได้

2. มีค่าใช้จ่ายใน Deploy chain สูง

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

มันจึงไม่ใช่เชน เชนเดียว และไม่ใช่ Multichain แต่เป็น Superchain

➡️Shared L1 Blockchain ช่วยในการจัดเรียงธุรกรรมให้ทุกเชนบน OP Chain

➡️Shared bridges สร้างมาตรฐานที่ปลอดภัยในการบริดจ์ระหว่างกัน

➡️OP chain deployment สามารถ Deploy ไปยัง OP Chain โดยตรง และสามารถย้ายไปหาระหว่างเชนได้โดยไม่ต้องเขียนโค้ดเพิ่ม

➡️มีออปชั่นสำหรับ OP chain เช่นเลือก DA Provider, Sequencer และอื่นๆ ➡️ ทำธุรกรรมหรือส่งข้อความแบบครอสเชนก็ปลอดภัย โดยในระดับ High level จะมีรูปแบบการทำงานแบบในภาพ

จบพาร์ทเกริ่น มาต่อที่พาร์ทหลักในวันนี้ กับ 4 คอนเซปต์ที่ทำให้ Superchain สเกลได้ดีขึ้น เพื่อปูทางในการสร้าง Open-Source internet ในอนาคตกัน

คือกระบวนการในการหา state ของ L2 chain โดยดึงข้อมูลจาก L1 ขึ้นมาแล้วฟังชั่นบน L2 ทั้งหมด เช่น Execute เพื่อทำ Tx หรือเพื่อหาจำนวน Balance เป็นต้น

ตัวอย่างการ Derive

นาย เอ ทำการฝากเงินเข้าไปยังเชน ETH

เชน OP จะทำการ Derive (ขอ Output) จาก L1 มาไว้บน L2

ในนั้นก็จะมีข้อมูลการฝากเงินต่างๆครบ

หรือนายเอ ส่งข้อมูล Tx บน L2 ให้ Sequencer submit ลง L1 แล้ว Recall derive เราก็จะได้ข้อมูล L2 เช่นกัน

ค่อนข้างตรงไปตรงมา

แวะตอบคำถามยอดนิยม Sequncer สามารถดัดแปลงข้อมูล Tx เพื่อโกงได้มั้ย

ตัวอย่างเดิม นายเอ ส่งข้อมูล Tx ให้ Sequencer พร้อม Sign ด้วย Private Key ที่มีเขาที่รู้เท่านั้น

หลังจากนั้น Sequencer เอา Tx ไปเปลี่ยนแอดเดรสผู้รับ

วิธีนี้ Signature ที่นายเอ Sign จะถือเป็นโมฆะทันที

สิ่งที่ตามมาคือ Sequencer submit tx ที่มี sign ที่ผิด

เมื่อ OP node Derive ข้อมูลนั้นมาไว้บน L2

จะตรวจพบความผิดพลาดทันที แล้วจะโยน Tx นั้นทิ้งไป

ทำให้ไอเดียที่ว่า Sequencer จะเปลี่ยนแปลงส่วนนี้ได้ ไม่เป็นความจริง

จากการ Derive 1 Rollup ที่เล่าไป

แล้วถ้า Superchain ที่มีหลายๆ Rollup ทำงานพร้อมๆ กัน? ก็ทำงานได้เรียบง่ายแต่มีประสิทธิภาพ เมื่อแต่ละเชนต่างสามารถ Derive ข้อมูลจาก L1 เหมือนถนนที่ขยายจาก 2 เลนเป็น 8 เลน (แต่ละเชนสามารถใช้ Sequencer ที่ต่างกันได้)

หรือไปไกลกว่านั้นคือการ Derive แบบ Infinity Chain

ก็สามารถทำได้โดยการทำ Generalized Derivation function โดยการเพิม op_config สำหรับแต่ละเชนตามการใช้งาน เพื่อให้สามารถสั่งและค้นหาข้อมูลจากเชนต่างๆ ได้อย่างถูกต้อง

นายเอ อาจใช้งานแต่ละเชนพร้อมกัน ทำให้วิธีนี้สามารถสเกลได้มหาศาล

นี่คือพาร์ทที่ fault proof และ proof อื่นๆ เข้ามา และเป็นพาร์ทที่ secure message ถูกส่งจากเชนหนึ่งไปยังอีกเชนหนึ่งได้

นาย A ส่งจดหมายไปให้นาย B ต้องมีคำสั่ง หน้าตาของข้อความ

✅To ส่งให้ใคร Message

✅ข้อความคืออะไร

✅Proof คือ signature

นาย C เป็นบุรุษไปรษณีย์เป็นคนไปส่งข้อความให้

นาย B ที่ได้ข้อความก็เช็กลิสต์ทั้งหมด

กลับกันถ้า A และ B = เชน

เชน A ส่ง Msg บอก B

นาย C คือคนกลางจะ Re route ข้อมูลไปให้ B

✅To = เชน B

✅Message = ต้องการ migrate ข้อมูลเหรียญไปให้ B

✅ Proof อันนี้จะแตกต่างกันนิด เพราะเชน B จะใช้ Proof system ของตัวเองในการตรวจ

การทำ Cross-chain Messaging จะยากที่ขั้นตอนนี้

ตัวอย่างจริงเมื่อเราต้องการส่งเหรียญจาก L2 ไปยัง L1 เริ่มจากการส่ง Tx ไปยัง L2 เพื่อ Burn เหรียญเวอร์ชั่น L2 เพื่อไปรับบน L1 นาย C ที่เป็นคนส่งข้อความจำสร้าง Proof ว่าเรา Burn จริง ก่อนส่งข้อความไปแจ้งยัง L1 แล้วปลดล็อกเหรียญบน L1 อันนี้เป็นคำอธิบายยอย่างง่าย

ปกติแล้วเราจะใช้วิธีนี้สำหรับ Cross-chain Messaging

จาก L2 > L1 แต่จะไม่ใช้กับ L1 > L2

เพราะ L2 รู้ state ทั้งหมดของ L1 อยู่แล้ว (จากฟังก์ชั่น Derive ในคอนเซป 1)

ตัวอย่างถัดมา

คือการทำ Cross-chain Messaging ระหว่าง L2 กัน เหมือนเดิม หน้าตาของข้อความ

✅To ส่งให้ใคร (ChainID)

✅Message ข้อความ byte

❌ Proof ข้อนี้เป็นเรื่องยากมาก

Proof Fundamental principle = Verifying the authenticity of msg คือการยืนยันความถูกต้องของ msg

ถ้าเชนแดง ต้องการส่งข้อมูลให้เชนฟ้า

แต่ละเชนจะไม่สามารถเข้าถึงข้อมูลระหว่างกัน แต่จะสามารถ derive จาก L1 มาอีกที แปลว่าทุกอย่างจะต้องเริ่มจากการ derive L1

ถ้าเชนฟ้า อยากได้ข้อมูลของ เชนแดง จะต้องใช้คำสั่ง

red_chain = derive(L1_chain, red_config) และยืนยันความถูกต้องของ Msg

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

แต่ความจริงแล้วไม่เป็นแบบนั้น เพราะแต่ละเชนจะ compress ข้อมูล Proof ให้เป็นข้อมูลที่เล็กลง โดยไม่ต้องส่งไปทั้งหมด

Proof ว่าข้อความนั้นถูกต้องโดยเปิดให้คนมาแย้ง (challenge) ทำให้มีต้องมี dispute window เพื่อตัดสิน เช่น 7 วัน

ถ้าครบกำหนดเวลาไม่มีใครค้าน ถือว่าข้อความนั้นถูกต้อง

ข้อดีคือต้นทุนในการ Proof ถูก

ข้อเสียคือระยะเวลารอนาน

ใช้วิธียืนยันข้อมูลที่แย้งไม่ได้ เช่นการใช้ zkp หรือ Zero Knowledge Proof ทำให้สามารถยืนยันความถูกต้องได้ทันที

ข้อดีคือเร็วมาก ไม่มี Dispute window ข้อเสียคือใช้การประมวลผลที่สูง กินทรัพยากร และค่าแกสแพง

แต่ไม่ว่าจะใช้ Proof แบบไหน Superchain ก็รองรับหมด

แถมเรื่องประเภทของ Proof ในแง่ของความเร็ว ราคา และระดับของ Trust เมื่อเชนต่างๆ ใน Superchain มีการใช้ proof รูปแบบต่างๆ มากขึ้น จะช่วยทำให้เราเรียนรู้และหา Best used case อีกด้วย

โดยแต่ละเชนอาจเลือกใช้ sequencing protocol ที่แตกต่างกัน อาจเลือกใช้ Single Sequencer หรือหลายๆ ตัวแบบ Complex ก็ได้

*ตอนนี้ตัว Configuration ยังไม่เสร็จสมบูรณ์ เมื่อมี Use Case ที่มากขึ้นจะสามารถหา Config ที่ลงตัวได้

จากข้างบนคอนเซปต์แค่นี้คงฟังแล้วดูไม่ได้มีอะไร ซึ่ง OP มองไปไกลกว่านั้น

🔐 เราสามารถปลดล็อกการทำ synchronous cross-chain transaction ไปดูตัวอย่างทวิตถัดไปเพื่อความเข้าใจง่าย

ตัวอย่าง(Old)

EVM smart contract เมื่อ Contract A > loan > Contract B A จะส่งคำสั่ง Loan พร้อมล็อก A จนกว่า B Payback

Eth smart contract สามารถทำ risk free loan ได้ ถ้า execute หมดนี้ใน tx เดียว(Atomic) แต่ถ้า A Loan B โดยที่ทั้งสองเชนมี proof ต่างกัน Atomic จะเกิดขึ้นไม่ได้

ตัวอย่าง (New)

การทำ synchronous cross-chain Tx คือการทำให้ Contract A ในเชน A และ Contract B ในเชน B สามารถ Execute คำสั่งได้พร้อมกันแบบข้ามเชน

สิ่งนี้จะเกิดขึ้นได้เมื่อ Sequencer ของทั้งสองเชนมีการ Shared Ordering = Shared Sequencing

เราสามารถทำสิ่งนี้ได้โดยการสร้างการร่วมมือกันระหว่าง Sequencer ของแต่ละเชน อาจจะมีการให้ Incentive กลาง เพื่อให้ Sequencer ต่างๆ เหล่านี้ ไม่เพียงทำหน้าที่ Ordering เฉพาะเชนตัวเอง แต่ร่วมมือกัน Sequence ในส่วนที่เป็น Atomic Tx

จากที่เล่ามาว่า Sequencer ในเชนต่างๆ ของ Superchain จะต้องทำการ Submit ข้อมูลลง L1 อยู่ดี

ทำให้มีปัญหาคอขวดตามมา คำถามคือเราจะโพสต์ข้อมูลบน L1 ให้มีขนาดใหญ่ขึ้นได้ยังไง?

ทำได้โดย

1. เพิ่มขนาด DA ของ L1 โดยใช้ EIP4844

2. เพิ่มตัวเลือกของ DA provider โดยใช้ Plasma Protocol ซึ่ง Plasma API สามารถ commit ข้อมูลที่มีขนาดใหญ่กว่า data hash(raw tx data) ที่ขนาด 32 bytes

Data Commitment นี้สามารถนำไปใช้ร่วมกับ Pre-image Oracle เพื่อส่งข้อมูลแบบ off-chain หรือสามารถนำไปใช้เพื่อยืนยันการ Ordering จะช่วยทำให้เราซิ้งกับ L1 โดยได้ข้อมูลเพิ่มขึ้น จากเดิมซิงค์โดยใช้ sequencer/EOA/Deposit

เปลี่ยนมาดึงข้อมูล offchain อื่นๆที่แชร์โดย DA provider

แม้ Plasma สามารถช่วยดึงข้อมูลได้อย่างมหาศาล แต่ตัว Plasma เองยังมีปัญหาสำคัญเรื่อง Liveness ต่างกับ L1 DA ที่การันตีว่าคุณจะสามารถหา Pre-image เจอเสมอ

จึงไม่สามารถพึ่ง DA ด้วย Plasma ทางเดียว และแก้ปัญหาการติดๆดับๆ โดยสามารถยืนยันความถูกต้องของข้อมูลย้อนหลังด้วย DA challenge

ตัวอย่างของ Data availability (DA) challenge

นาย A ขอข้อมูลจาก Plasma DA ผ่าน L1 L1 สามารถตอบสนองได้ 2 แบบคือ

1. เผยข้อมูลให้

2. ลบข้อมูล Commitment

ถ้าคำตอบคือเผยนาย A ก็สามารถดาวน์โหลดข้อมูลทั้งหมดได้

แต่ Fault ที่ได้มาจะมาในรูปแบบของ Non-Attribute ซึ่ง L1 จะไม่สามารถรู้ได้เลยว่านาย A โกหกหรือพูดจริง

โดยในทางปฏิบัติแล้ว นาย A จะเป็นคนจ่ายเงินเพื่อแลกกับการขอดูข้อมูล ซึ่งถ้านาย A มีหลักฐานยืนยันว่า DA Provider ผิดจริง นาย A ก็สามารถถอนเงินเพื่อไปใช้ DA Provider ตัวอื่น

จะเห็นว่า Worst Case ของผู้ใช้ที่ดึงข้อมูลจาก DA Provider ที่ยืนยันข้อมูลผิดพลาด คือการถอนเงินได้ แล้วไปเลือกใช้เจ้าใหม่

หรือถ้าเป็นแบบที่ 2 / L1 ลบข้อมูล Commitment ก็ง่ายๆ ตามตัวเลยคือการโยน Tx นี้ทิ้งไปเลย

สรุปเรื่องประเภทของ Data availability

1. Rollup - Full tx on L1 / ปลอดภัย, มีราคาสูง

2. Plasma - commitment to tx data on L1 / ปลอดภัยต่ำกว่า/ เกือบจะฟรี / สเกลได้แบบสุดๆ = Infinity Data

*plasma คล้ายๆ (blob) ของ 4844 แหละ

ด้วยคอนเซปในการสเกลที่ครอบคลุมครบทุกมิติ ทำให้ Superchain สามารถเปลี่ยน Web app ธรรมดาให้กลายเป็น Protocol ได้ และทุกคนสามารถร่วมกันสร้างโลก Open-Source Internet ที่ทุกคนได้ประโยชน์และแบ่งปันผลประโยชน์ร่วมกัน ซึ่ง OP ยังคงเน้นเรื่องการทำ RPGF เพื่อสร้างโลก Internet ที่ยั่งยืน

หากมีข้อสงสัยเกี่ยวกับ Optimism สามารถอ่านเธรดภาษาไทยที่เคยแปลไว้ในนี้และฝากติดตามด้วยนะครับ

คุณรู้จัก Optimism Superchain ดีแค่ไหน? มาลองทำความรู้จักมุมใหม่ ที่ Karl Floersch Co-Founder ของ OP จะมาขยายความแบบเจาะลึกกับ 4 คอนเซปต์ที่แตกต่างและสามารถทำให้เป็นจริงได้ โดยยกมาจาก ETHDenver ถอดความมาให้อ่านกันง่ายๆ พร้อมแล้วไปดูกันเลย

เนื้อหาในบทความนี้ถอดความมาจากคลิปนี้ สามารถไปดูตัวเต็มๆ ได้เลย

หรือสำหรับใครที่เพิ่งเคยได้ยินเรื่อง Superchain ก็สามารถปูพื้นฐานได้ที่นี่ แต่ถ้าใครพร้อมแล้วก็ไปต่อกันเลย

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

แล้วถ้าปัญหาเหล่านี้หายไปจะเกิดอะไรขึ้น? เริ่มจากลองจินตนาการถึงโลกอนาคตที่ Smart Contract สามารถ deploy ได้ โดยมีต้นทุนที่ต่ำมากๆ เราสามารถทำ Tx หากัน หรือทดลองอะไรสนุกๆ ก็ได้เต็มที่

ปัญหาที่ค่อยๆ ถูกแก้ไข เมื่อทุกอย่างในโลกนี้ถูกรันบน Blockchain จะเป็นยังไง?

1. ไม่ต้องปวดหัวกับปัญหา Server เพราะ EVM คือขั้นสุดยอดแพลทฟอร์มแบบ Serverless (ไม่ต้องการ server) แค่เพียงคุณ Deploy ทำให้ Smart Contract นั้นจะอยู่บนเชนตลอดกาล หมดปัญหาเซิร์ฟล่ม

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

3. ลดค่าใช้จ่ายแรกเริ่มสำหรับ Dev อยากขยายแบนวิธก็ไม่มีค่าใช้จ่ายเพิ่ม ทำให้สามารถช่วยลดต้นทุนในการดำเนินธุรกิจ โดยเฉพาะในช่วงเริ่มต้นได้อย่างดี

ทั้งสามข้อนี้เป็นตัวอย่างแค่บางส่วนที่ช่วยทำให้โลกของ Decentralized Web เป็นจริงได้

ซึ่ง OP ก็พยายามทำมาตลอดตั้งแต่ ETH2.0 > Plasma group จนถึง OP โดยตอนนี้ก็มีทุกคนๆ มาร่วมช่วยกันพัฒนา นี่คือสเน่ห์ของความเป็น Open-Source

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

Superchain แตกต่างจาก Multichain ที่มีปัญหาดังนี้

1. ปัญหาเรื่องความปลอดภัยที่เพิ่มความซับซ้อนเมื่อแต่ละเชนมีสถาปัตยกรรมการออกแบบที่แตกต่างกัน เชน A + เชน B + เชน C แฮกเกอร์อาจเจอจุดอ่อนระหว่าง B/C และใช้โจมตีได้

2. มีค่าใช้จ่ายใน Deploy chain สูง

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

มันจึงไม่ใช่เชน เชนเดียว และไม่ใช่ Multichain แต่เป็น Superchain

➡️Shared L1 Blockchain ช่วยในการจัดเรียงธุรกรรมให้ทุกเชนบน OP Chain

➡️Shared bridges สร้างมาตรฐานที่ปลอดภัยในการบริดจ์ระหว่างกัน

➡️OP chain deployment สามารถ Deploy ไปยัง OP Chain โดยตรง และสามารถย้ายไปหาระหว่างเชนได้โดยไม่ต้องเขียนโค้ดเพิ่ม

➡️มีออปชั่นสำหรับ OP chain เช่นเลือก DA Provider, Sequencer และอื่นๆ ➡️ ทำธุรกรรมหรือส่งข้อความแบบครอสเชนก็ปลอดภัย โดยในระดับ High level จะมีรูปแบบการทำงานแบบในภาพ

จบพาร์ทเกริ่น มาต่อที่พาร์ทหลักในวันนี้ กับ 4 คอนเซปต์ที่ทำให้ Superchain สเกลได้ดีขึ้น เพื่อปูทางในการสร้าง Open-Source internet ในอนาคตกัน

คือกระบวนการในการหา state ของ L2 chain โดยดึงข้อมูลจาก L1 ขึ้นมาแล้วฟังชั่นบน L2 ทั้งหมด เช่น Execute เพื่อทำ Tx หรือเพื่อหาจำนวน Balance เป็นต้น

ตัวอย่างการ Derive

นาย เอ ทำการฝากเงินเข้าไปยังเชน ETH

เชน OP จะทำการ Derive (ขอ Output) จาก L1 มาไว้บน L2

ในนั้นก็จะมีข้อมูลการฝากเงินต่างๆครบ

หรือนายเอ ส่งข้อมูล Tx บน L2 ให้ Sequencer submit ลง L1 แล้ว Recall derive เราก็จะได้ข้อมูล L2 เช่นกัน

ค่อนข้างตรงไปตรงมา

แวะตอบคำถามยอดนิยม Sequncer สามารถดัดแปลงข้อมูล Tx เพื่อโกงได้มั้ย

ตัวอย่างเดิม นายเอ ส่งข้อมูล Tx ให้ Sequencer พร้อม Sign ด้วย Private Key ที่มีเขาที่รู้เท่านั้น

หลังจากนั้น Sequencer เอา Tx ไปเปลี่ยนแอดเดรสผู้รับ

วิธีนี้ Signature ที่นายเอ Sign จะถือเป็นโมฆะทันที

สิ่งที่ตามมาคือ Sequencer submit tx ที่มี sign ที่ผิด

เมื่อ OP node Derive ข้อมูลนั้นมาไว้บน L2

จะตรวจพบความผิดพลาดทันที แล้วจะโยน Tx นั้นทิ้งไป

ทำให้ไอเดียที่ว่า Sequencer จะเปลี่ยนแปลงส่วนนี้ได้ ไม่เป็นความจริง

จากการ Derive 1 Rollup ที่เล่าไป

แล้วถ้า Superchain ที่มีหลายๆ Rollup ทำงานพร้อมๆ กัน? ก็ทำงานได้เรียบง่ายแต่มีประสิทธิภาพ เมื่อแต่ละเชนต่างสามารถ Derive ข้อมูลจาก L1 เหมือนถนนที่ขยายจาก 2 เลนเป็น 8 เลน (แต่ละเชนสามารถใช้ Sequencer ที่ต่างกันได้)

หรือไปไกลกว่านั้นคือการ Derive แบบ Infinity Chain

ก็สามารถทำได้โดยการทำ Generalized Derivation function โดยการเพิม op_config สำหรับแต่ละเชนตามการใช้งาน เพื่อให้สามารถสั่งและค้นหาข้อมูลจากเชนต่างๆ ได้อย่างถูกต้อง

นายเอ อาจใช้งานแต่ละเชนพร้อมกัน ทำให้วิธีนี้สามารถสเกลได้มหาศาล

นี่คือพาร์ทที่ fault proof และ proof อื่นๆ เข้ามา และเป็นพาร์ทที่ secure message ถูกส่งจากเชนหนึ่งไปยังอีกเชนหนึ่งได้

นาย A ส่งจดหมายไปให้นาย B ต้องมีคำสั่ง หน้าตาของข้อความ

✅To ส่งให้ใคร Message

✅ข้อความคืออะไร

✅Proof คือ signature

นาย C เป็นบุรุษไปรษณีย์เป็นคนไปส่งข้อความให้

นาย B ที่ได้ข้อความก็เช็กลิสต์ทั้งหมด

กลับกันถ้า A และ B = เชน

เชน A ส่ง Msg บอก B

นาย C คือคนกลางจะ Re route ข้อมูลไปให้ B

✅To = เชน B

✅Message = ต้องการ migrate ข้อมูลเหรียญไปให้ B

✅ Proof อันนี้จะแตกต่างกันนิด เพราะเชน B จะใช้ Proof system ของตัวเองในการตรวจ

การทำ Cross-chain Messaging จะยากที่ขั้นตอนนี้

ตัวอย่างจริงเมื่อเราต้องการส่งเหรียญจาก L2 ไปยัง L1 เริ่มจากการส่ง Tx ไปยัง L2 เพื่อ Burn เหรียญเวอร์ชั่น L2 เพื่อไปรับบน L1 นาย C ที่เป็นคนส่งข้อความจำสร้าง Proof ว่าเรา Burn จริง ก่อนส่งข้อความไปแจ้งยัง L1 แล้วปลดล็อกเหรียญบน L1 อันนี้เป็นคำอธิบายยอย่างง่าย

ปกติแล้วเราจะใช้วิธีนี้สำหรับ Cross-chain Messaging

จาก L2 > L1 แต่จะไม่ใช้กับ L1 > L2

เพราะ L2 รู้ state ทั้งหมดของ L1 อยู่แล้ว (จากฟังก์ชั่น Derive ในคอนเซป 1)

ตัวอย่างถัดมา

คือการทำ Cross-chain Messaging ระหว่าง L2 กัน เหมือนเดิม หน้าตาของข้อความ

✅To ส่งให้ใคร (ChainID)

✅Message ข้อความ byte

❌ Proof ข้อนี้เป็นเรื่องยากมาก

Proof Fundamental principle = Verifying the authenticity of msg คือการยืนยันความถูกต้องของ msg

ถ้าเชนแดง ต้องการส่งข้อมูลให้เชนฟ้า

แต่ละเชนจะไม่สามารถเข้าถึงข้อมูลระหว่างกัน แต่จะสามารถ derive จาก L1 มาอีกที แปลว่าทุกอย่างจะต้องเริ่มจากการ derive L1

ถ้าเชนฟ้า อยากได้ข้อมูลของ เชนแดง จะต้องใช้คำสั่ง

red_chain = derive(L1_chain, red_config) และยืนยันความถูกต้องของ Msg

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

แต่ความจริงแล้วไม่เป็นแบบนั้น เพราะแต่ละเชนจะ compress ข้อมูล Proof ให้เป็นข้อมูลที่เล็กลง โดยไม่ต้องส่งไปทั้งหมด

Proof ว่าข้อความนั้นถูกต้องโดยเปิดให้คนมาแย้ง (challenge) ทำให้มีต้องมี dispute window เพื่อตัดสิน เช่น 7 วัน

ถ้าครบกำหนดเวลาไม่มีใครค้าน ถือว่าข้อความนั้นถูกต้อง

ข้อดีคือต้นทุนในการ Proof ถูก

ข้อเสียคือระยะเวลารอนาน

ใช้วิธียืนยันข้อมูลที่แย้งไม่ได้ เช่นการใช้ zkp หรือ Zero Knowledge Proof ทำให้สามารถยืนยันความถูกต้องได้ทันที

ข้อดีคือเร็วมาก ไม่มี Dispute window ข้อเสียคือใช้การประมวลผลที่สูง กินทรัพยากร และค่าแกสแพง

แต่ไม่ว่าจะใช้ Proof แบบไหน Superchain ก็รองรับหมด

แถมเรื่องประเภทของ Proof ในแง่ของความเร็ว ราคา และระดับของ Trust เมื่อเชนต่างๆ ใน Superchain มีการใช้ proof รูปแบบต่างๆ มากขึ้น จะช่วยทำให้เราเรียนรู้และหา Best used case อีกด้วย

โดยแต่ละเชนอาจเลือกใช้ sequencing protocol ที่แตกต่างกัน อาจเลือกใช้ Single Sequencer หรือหลายๆ ตัวแบบ Complex ก็ได้

*ตอนนี้ตัว Configuration ยังไม่เสร็จสมบูรณ์ เมื่อมี Use Case ที่มากขึ้นจะสามารถหา Config ที่ลงตัวได้

จากข้างบนคอนเซปต์แค่นี้คงฟังแล้วดูไม่ได้มีอะไร ซึ่ง OP มองไปไกลกว่านั้น

🔐 เราสามารถปลดล็อกการทำ synchronous cross-chain transaction ไปดูตัวอย่างทวิตถัดไปเพื่อความเข้าใจง่าย

ตัวอย่าง(Old)

EVM smart contract เมื่อ Contract A > loan > Contract B A จะส่งคำสั่ง Loan พร้อมล็อก A จนกว่า B Payback

Eth smart contract สามารถทำ risk free loan ได้ ถ้า execute หมดนี้ใน tx เดียว(Atomic) แต่ถ้า A Loan B โดยที่ทั้งสองเชนมี proof ต่างกัน Atomic จะเกิดขึ้นไม่ได้

ตัวอย่าง (New)

การทำ synchronous cross-chain Tx คือการทำให้ Contract A ในเชน A และ Contract B ในเชน B สามารถ Execute คำสั่งได้พร้อมกันแบบข้ามเชน

สิ่งนี้จะเกิดขึ้นได้เมื่อ Sequencer ของทั้งสองเชนมีการ Shared Ordering = Shared Sequencing

เราสามารถทำสิ่งนี้ได้โดยการสร้างการร่วมมือกันระหว่าง Sequencer ของแต่ละเชน อาจจะมีการให้ Incentive กลาง เพื่อให้ Sequencer ต่างๆ เหล่านี้ ไม่เพียงทำหน้าที่ Ordering เฉพาะเชนตัวเอง แต่ร่วมมือกัน Sequence ในส่วนที่เป็น Atomic Tx

จากที่เล่ามาว่า Sequencer ในเชนต่างๆ ของ Superchain จะต้องทำการ Submit ข้อมูลลง L1 อยู่ดี

ทำให้มีปัญหาคอขวดตามมา คำถามคือเราจะโพสต์ข้อมูลบน L1 ให้มีขนาดใหญ่ขึ้นได้ยังไง?

ทำได้โดย

1. เพิ่มขนาด DA ของ L1 โดยใช้ EIP4844

2. เพิ่มตัวเลือกของ DA provider โดยใช้ Plasma Protocol ซึ่ง Plasma API สามารถ commit ข้อมูลที่มีขนาดใหญ่กว่า data hash(raw tx data) ที่ขนาด 32 bytes

Data Commitment นี้สามารถนำไปใช้ร่วมกับ Pre-image Oracle เพื่อส่งข้อมูลแบบ off-chain หรือสามารถนำไปใช้เพื่อยืนยันการ Ordering จะช่วยทำให้เราซิ้งกับ L1 โดยได้ข้อมูลเพิ่มขึ้น จากเดิมซิงค์โดยใช้ sequencer/EOA/Deposit

เปลี่ยนมาดึงข้อมูล offchain อื่นๆที่แชร์โดย DA provider

แม้ Plasma สามารถช่วยดึงข้อมูลได้อย่างมหาศาล แต่ตัว Plasma เองยังมีปัญหาสำคัญเรื่อง Liveness ต่างกับ L1 DA ที่การันตีว่าคุณจะสามารถหา Pre-image เจอเสมอ

จึงไม่สามารถพึ่ง DA ด้วย Plasma ทางเดียว และแก้ปัญหาการติดๆดับๆ โดยสามารถยืนยันความถูกต้องของข้อมูลย้อนหลังด้วย DA challenge

ตัวอย่างของ Data availability (DA) challenge

นาย A ขอข้อมูลจาก Plasma DA ผ่าน L1 L1 สามารถตอบสนองได้ 2 แบบคือ

1. เผยข้อมูลให้

2. ลบข้อมูล Commitment

ถ้าคำตอบคือเผยนาย A ก็สามารถดาวน์โหลดข้อมูลทั้งหมดได้

แต่ Fault ที่ได้มาจะมาในรูปแบบของ Non-Attribute ซึ่ง L1 จะไม่สามารถรู้ได้เลยว่านาย A โกหกหรือพูดจริง

โดยในทางปฏิบัติแล้ว นาย A จะเป็นคนจ่ายเงินเพื่อแลกกับการขอดูข้อมูล ซึ่งถ้านาย A มีหลักฐานยืนยันว่า DA Provider ผิดจริง นาย A ก็สามารถถอนเงินเพื่อไปใช้ DA Provider ตัวอื่น

จะเห็นว่า Worst Case ของผู้ใช้ที่ดึงข้อมูลจาก DA Provider ที่ยืนยันข้อมูลผิดพลาด คือการถอนเงินได้ แล้วไปเลือกใช้เจ้าใหม่

หรือถ้าเป็นแบบที่ 2 / L1 ลบข้อมูล Commitment ก็ง่ายๆ ตามตัวเลยคือการโยน Tx นี้ทิ้งไปเลย

สรุปเรื่องประเภทของ Data availability

1. Rollup - Full tx on L1 / ปลอดภัย, มีราคาสูง

2. Plasma - commitment to tx data on L1 / ปลอดภัยต่ำกว่า/ เกือบจะฟรี / สเกลได้แบบสุดๆ = Infinity Data

*plasma คล้ายๆ (blob) ของ 4844 แหละ

ด้วยคอนเซปในการสเกลที่ครอบคลุมครบทุกมิติ ทำให้ Superchain สามารถเปลี่ยน Web app ธรรมดาให้กลายเป็น Protocol ได้ และทุกคนสามารถร่วมกันสร้างโลก Open-Source Internet ที่ทุกคนได้ประโยชน์และแบ่งปันผลประโยชน์ร่วมกัน ซึ่ง OP ยังคงเน้นเรื่องการทำ RPGF เพื่อสร้างโลก Internet ที่ยั่งยืน

หากมีข้อสงสัยเกี่ยวกับ Optimism สามารถอ่านเธรดภาษาไทยที่เคยแปลไว้ในนี้และฝากติดตามด้วยนะครับ