ของดีแบบไม่กาวจาก @optimismFND กับ OP Stack Blockchain แบบ Modular ในฝันที่เราสามารถ Mix & Match เลเยอร์ต่างๆ ได้ตามใจ ฟังไอเดียจาก @karl_dot_tech ไปแล้ว วันนี้ @kelvinfichter

จะมาอธิบายหลักการทำงานแบบไม่กาว แปลจาก Devcon Bogota เธรดนี้อาจจะเทคนิดนึง แต่รับรองว่าเจ๋ง

ก่อนจะไปเข้าเนื้อหา อาจต้องปูที่มา เพื่อให้เข้าใจว่าทำไมแนวคิดของทีมมากขึ้น ย้อนกลับไปตอนปี 2020 ตอนนั้นใครๆ ก็แข่งกันสร้างเชน Monolith Rollups เช่น Solana ทำได้ครบ แต่มี Codebase ใหญ่ยักษ์

ยุคนั้นความรู้ความเข้าใจวิธีการทำงานมันยังไม่ชัดเจนเท่านี้ Data availability คืออะไร? ทำให้ทุกอย่างถูกนิยามและจำกัดโดยมี Proof system เป็นกรอบ พอคิดได้แบบนั้นไอเดียการสร้าง Optimistic Rollups เลยต้องเริ่มจากการสร้าง Fault Proof เป็นอย่างแรก แล้วค่อยๆงมเพื่อให้สามารถใช้ EVM ได้

หลังจากงมอยู่ 4-5 เดือนก็เพิ่งมาเก๊ทวิธีการทำงานต่างๆ ประหนึ่งตรัสรู้ว่าที่ผ่านมาเข้าใจอะไรหลายๆ อย่างผิดมาตลอด แม้แต่เรื่องที่ฟังดูง่ายๆ อย่าง Withdrawal ก็ไม่ได้ทำงานในแบบที่พวกเขาเคยคิด

สิ่งที่พวกเขาตกตะกอนในช่วง 2021-2022

1. เข้าใจว่า Proof ควรแยกออกจาก Execute โดยสมบูรณ์ และ Proof ไม่ควรเข้าไปควบคุมและจำกัดการทำงาน

2. เข้าใจว่าควรแตก Data availability layer

• Metis forked OP เพิ่ม DA committee

• Arb ปล่อย NOVA ที่มี DA committee

ถึงจุดนี้ Rollups เลยเปลี่ยนตัวเองเป็น Modular เริ่มจากแตก Layer เป็น 3 ระดับของการทำงาน

• Consensus (ตย. Rollups, Plasma)

• Execution (ตย. EVM, Move)

• Settlement (ตย. Fraud, ZKp, Multisig)

1. Data Availability Layer (DA)

2. Derivation

1. DA Layer คืออะไร?

• เป็นที่ๆโพสต์ Data และดึงข้อมูลต่างๆ ไปใช้

• มี ordered list of blobs

โดยมี 2 เงื่อนไข Data=available พร้อมใช้งาน Data=immutable เปลี่ยนแปลงไม่ได้

Code type DA = byte[]

• ตัวอย่าง DA Layers

• Ethereum (ผ่าน Calldata)

• Ethereum (ผ่าน 4844)

• Celestia

• Arrays of blobs = blobs blocks

2. Derivation สิ่งนี้น่าสนใจกว่า อธิบายแบบกว้างคือ การใช้ DA Layer และทำความเข้าใจสิ่งที่อยู่ข้างในก่อนส่งต่อโดยเพิ่ม current state ของ L2 system เพื่อสร้าง Input ให้เชน เพิ่มเติม Derive แปลว่าสืบ เหมือนสืบค้นข้อมูล

Derivation แบบเป็นทางการ เพื่อให้เข้าใจการทำงานมากขึ้น สิ่งนี้มี function signature ที่เรียบง่าย Derive (Sprev,Da) => {payload or null} แปลแบบบ้านๆ ระบบจะทำการสืบข้อมูลจาก (จาก state ก่อนหน้า+จาก DA) => เพื่อสร้าง {payload หรือไม่สร้างอะไรเลย}

Bedrock Optimism derives ข้อมูลจาก 3 ทาง

1. Derive จากข้อมูล Sequencer ที่โพสต์บน Address แบบเจาะจงบน L1 (ส่วนใหญ่จะมาจากที่นี่) เช่น sequencer จับ txn มามัดรวมกันแล้วโพสต์บน L1 การโพสต์บน address ไม่ใช่บน contract เป็นวิธีที่ดีและน่าสนใจ

2. Derive จาก Deposit ที่ส่งไปยัง Portal contract (Deposit contract) ทุกครั้งที่มีการ Deposit เกิดในบล็อกปุ๊บ เราจะดึงข้อมูลมาสร้าง L2 deposit tx

3. สร้างจาก L1 block data ทุกครั้งที่มีบล็อกจาก L1 ที่พกข้อมูลของ L1 มาไว้บน L2 ทั้งสามทางนี้คือวิธีในการดึงข้อมูล payload เพื่อ Execute บน L2

ทั้งหมดนี้เป็นเรื่องที่ทรงพลังมากเพราะ จากเมื่อก่อนที่ Rollups อ่านข้อมูลจากไม่กี่ที่

• อ่าน sequenced txn โดยตรงจาก Tx data

• อ่าน deposit data จาก Events

แต่ Bedrock สามารถสืบข้อมูลได้มากกว่า และทำได้หลายช่องทางกว่านั้นมากๆ กลายเป็นว่าเราแทบจะสามารถดึงข้อมูลจากไหนก็ได้

ตัวอย่าง

สมมุติเรามี L2 ที่ยังไม่มี user tx ทุกครั้งที่มีการ swap ใน uniswap บน L1 เราสามารถสร้าง L2 tx ที่มีทั้งข้อมูล Assets และจำนวน ที่ swap อยู่ในนั้นไปพร้อมกัน หลังจากนั้นทุกๆ Tx จะอัปเดต Value บน smart contract และนับจำนวน Value ทั้งหมดตลอดเวลา

การฟีดข้อมูลตลอดเวลาจากหลายๆ ช่องทางนี้ มีหลักการทำงานเหมือน Indexer เปี๊ยบ ที่จิงแล้ว Indexer ก็คือ Rollups นั่นแหละ แค่คนส่วนใหญ่ยังไม่เก๊ท จุดนี้คือสิ่งที่ทำให้ Bedrock มีค่าทำธุรกรรมที่ถูกลงและเร็วขึ้น จบ Consensus

เมื่อ Derivation+Execution ทำงานร่วมกันจะสร้างฟังก์ชั่น loop ขึ้นมา

1. รอ element ใหม่จาก DA layer list

2. Run derivation Function ผลลัพธ์ = null ให้กลับไป Run Step 1 ใหม่ ถ้าผลลัพธ์ = payload ให้ส่งต่อไปที่ Execution Layer อัปเดตสถานะใหม่แล้วกลับไป Run Step2

Execution ของ Bedrock เป็นไง คือ EVM นั่นแหละแค่ปรับเล็กน้อย

• มี diff เล็กๆ deposit tx type ที่ allow contract บน L2 ติดต่อกับ L1

• โค้ดน้อยกว่า 1k Line ใน Single Commit ทำให้รองรับ multiple Client ช่วยปิดช่องโหว่ของ Proof ที่ไม่ว่าจะดีแค่ไหนแต่ถ้าใช้แค่ Client เดียวก็เสี่ยง

ทำไมการใช้ Client เดียว = เสี่ยง? เพราะว่า Proof คือระบบคอนเฟิร์ม execution บน Client ถ้าอยู่ๆ มีบัคเกิดขึ้นใน Client ขึ้น ตัว Proof มันก็จะ Proof บัคให้ผ่านอยู่ดี การทำ Client Diversity คือคำตอบ และเป็นเหตุผลที่ OP Stack จะรองรับหลาย Proof พร้อมกัน

ถึงแม้ทีม OP จะทำ Execution Layer ให้เป็น EVM แต่สิ่งนี้ก็ไม่จำกัดอยู่แค่นี้ เพราะมีความยืดหยุ่นสูงมาก จะเอาไปใส่เกมส์มายคร๊าฟอย่าง OPCraft ของ @latticexyz จะใส่ Gameboy ก้ได้ ใส่ Python ก็ได้ ทำอะไรก็ได้แค่ compile MIPS

ส่วนใหญ่เค้าจะเคลมว่ามันคือ state root ของระบบ L2 เช่น Fault Proof / Validity Proof ซึ่งแต่ละเชนก็จะใช้เคลมเป็นจุดขาย ถ้าเอา OP Stack ไปใช้ ก็สามารถเลือกแบบที่ชอบ หรือจะใช้ Proof หลายๆ แบบก็ได้ แค่ทำให้มันเข้าถึง DA layer ได้ก็เวิร์ก

จะทำให้เข้าถึง DA Layer โดยใช้ type DA = byte[] เพื่อให้เข้าถึง Array of blobs แล้ว getBlobByIndexer

Idea นี้มี property ที่สำคัญสองอย่าง

1. ต้องสามารถ return the blobs ซึ่งต้องพึ่ง Data availability Layer

2. ต้องมีระบบที่ Proof ความถูกต้องของ Blobs

Validation function ใน Bedrock ข้อดีของ ETH คือเราสามารถย้อนดูบล็อกก่อนหน้าได้เรื่อยๆ Bedrock ก็จะตรวจสอบความถูกต้องของ Blobs ด้วยการทำแบบนั้น

หลังจากที่รวมทุกอย่างที่เล่าเข้าด้วยกัน Bedrock Codebase สามารถเอาไปทำอะไรก็ได้ตามใจ ไม่ว่าจะเป็นเรื่องเล็กๆหรือเรื่องใหญ่ๆ

• ทำ bitcoin plasma

• ทำ Bridge rollup ที่ใช้ multiple DA และ Settlement Layer

• สร้าง VM คู่ขนาด ไว้ Raise fund ขำๆ (แซะ) ทำอะไรก็ได้ที่ลงตัวกับ APIs

ของดีแบบไม่กาวจาก @optimismFND กับ OP Stack Blockchain แบบ Modular ในฝันที่เราสามารถ Mix & Match เลเยอร์ต่างๆ ได้ตามใจ ฟังไอเดียจาก @karl_dot_tech ไปแล้ว วันนี้ @kelvinfichter

จะมาอธิบายหลักการทำงานแบบไม่กาว แปลจาก Devcon Bogota เธรดนี้อาจจะเทคนิดนึง แต่รับรองว่าเจ๋ง

ก่อนจะไปเข้าเนื้อหา อาจต้องปูที่มา เพื่อให้เข้าใจว่าทำไมแนวคิดของทีมมากขึ้น ย้อนกลับไปตอนปี 2020 ตอนนั้นใครๆ ก็แข่งกันสร้างเชน Monolith Rollups เช่น Solana ทำได้ครบ แต่มี Codebase ใหญ่ยักษ์

ยุคนั้นความรู้ความเข้าใจวิธีการทำงานมันยังไม่ชัดเจนเท่านี้ Data availability คืออะไร? ทำให้ทุกอย่างถูกนิยามและจำกัดโดยมี Proof system เป็นกรอบ พอคิดได้แบบนั้นไอเดียการสร้าง Optimistic Rollups เลยต้องเริ่มจากการสร้าง Fault Proof เป็นอย่างแรก แล้วค่อยๆงมเพื่อให้สามารถใช้ EVM ได้

หลังจากงมอยู่ 4-5 เดือนก็เพิ่งมาเก๊ทวิธีการทำงานต่างๆ ประหนึ่งตรัสรู้ว่าที่ผ่านมาเข้าใจอะไรหลายๆ อย่างผิดมาตลอด แม้แต่เรื่องที่ฟังดูง่ายๆ อย่าง Withdrawal ก็ไม่ได้ทำงานในแบบที่พวกเขาเคยคิด

สิ่งที่พวกเขาตกตะกอนในช่วง 2021-2022

1. เข้าใจว่า Proof ควรแยกออกจาก Execute โดยสมบูรณ์ และ Proof ไม่ควรเข้าไปควบคุมและจำกัดการทำงาน

2. เข้าใจว่าควรแตก Data availability layer

• Metis forked OP เพิ่ม DA committee

• Arb ปล่อย NOVA ที่มี DA committee

ถึงจุดนี้ Rollups เลยเปลี่ยนตัวเองเป็น Modular เริ่มจากแตก Layer เป็น 3 ระดับของการทำงาน

• Consensus (ตย. Rollups, Plasma)

• Execution (ตย. EVM, Move)

• Settlement (ตย. Fraud, ZKp, Multisig)

1. Data Availability Layer (DA)

2. Derivation

1. DA Layer คืออะไร?

• เป็นที่ๆโพสต์ Data และดึงข้อมูลต่างๆ ไปใช้

• มี ordered list of blobs

โดยมี 2 เงื่อนไข Data=available พร้อมใช้งาน Data=immutable เปลี่ยนแปลงไม่ได้

Code type DA = byte[]

• ตัวอย่าง DA Layers

• Ethereum (ผ่าน Calldata)

• Ethereum (ผ่าน 4844)

• Celestia

• Arrays of blobs = blobs blocks

2. Derivation สิ่งนี้น่าสนใจกว่า อธิบายแบบกว้างคือ การใช้ DA Layer และทำความเข้าใจสิ่งที่อยู่ข้างในก่อนส่งต่อโดยเพิ่ม current state ของ L2 system เพื่อสร้าง Input ให้เชน เพิ่มเติม Derive แปลว่าสืบ เหมือนสืบค้นข้อมูล

Derivation แบบเป็นทางการ เพื่อให้เข้าใจการทำงานมากขึ้น สิ่งนี้มี function signature ที่เรียบง่าย Derive (Sprev,Da) => {payload or null} แปลแบบบ้านๆ ระบบจะทำการสืบข้อมูลจาก (จาก state ก่อนหน้า+จาก DA) => เพื่อสร้าง {payload หรือไม่สร้างอะไรเลย}

Bedrock Optimism derives ข้อมูลจาก 3 ทาง

1. Derive จากข้อมูล Sequencer ที่โพสต์บน Address แบบเจาะจงบน L1 (ส่วนใหญ่จะมาจากที่นี่) เช่น sequencer จับ txn มามัดรวมกันแล้วโพสต์บน L1 การโพสต์บน address ไม่ใช่บน contract เป็นวิธีที่ดีและน่าสนใจ

2. Derive จาก Deposit ที่ส่งไปยัง Portal contract (Deposit contract) ทุกครั้งที่มีการ Deposit เกิดในบล็อกปุ๊บ เราจะดึงข้อมูลมาสร้าง L2 deposit tx

3. สร้างจาก L1 block data ทุกครั้งที่มีบล็อกจาก L1 ที่พกข้อมูลของ L1 มาไว้บน L2 ทั้งสามทางนี้คือวิธีในการดึงข้อมูล payload เพื่อ Execute บน L2

ทั้งหมดนี้เป็นเรื่องที่ทรงพลังมากเพราะ จากเมื่อก่อนที่ Rollups อ่านข้อมูลจากไม่กี่ที่

• อ่าน sequenced txn โดยตรงจาก Tx data

• อ่าน deposit data จาก Events

แต่ Bedrock สามารถสืบข้อมูลได้มากกว่า และทำได้หลายช่องทางกว่านั้นมากๆ กลายเป็นว่าเราแทบจะสามารถดึงข้อมูลจากไหนก็ได้

ตัวอย่าง

สมมุติเรามี L2 ที่ยังไม่มี user tx ทุกครั้งที่มีการ swap ใน uniswap บน L1 เราสามารถสร้าง L2 tx ที่มีทั้งข้อมูล Assets และจำนวน ที่ swap อยู่ในนั้นไปพร้อมกัน หลังจากนั้นทุกๆ Tx จะอัปเดต Value บน smart contract และนับจำนวน Value ทั้งหมดตลอดเวลา

การฟีดข้อมูลตลอดเวลาจากหลายๆ ช่องทางนี้ มีหลักการทำงานเหมือน Indexer เปี๊ยบ ที่จิงแล้ว Indexer ก็คือ Rollups นั่นแหละ แค่คนส่วนใหญ่ยังไม่เก๊ท จุดนี้คือสิ่งที่ทำให้ Bedrock มีค่าทำธุรกรรมที่ถูกลงและเร็วขึ้น จบ Consensus

เมื่อ Derivation+Execution ทำงานร่วมกันจะสร้างฟังก์ชั่น loop ขึ้นมา

1. รอ element ใหม่จาก DA layer list

2. Run derivation Function ผลลัพธ์ = null ให้กลับไป Run Step 1 ใหม่ ถ้าผลลัพธ์ = payload ให้ส่งต่อไปที่ Execution Layer อัปเดตสถานะใหม่แล้วกลับไป Run Step2

Execution ของ Bedrock เป็นไง คือ EVM นั่นแหละแค่ปรับเล็กน้อย

• มี diff เล็กๆ deposit tx type ที่ allow contract บน L2 ติดต่อกับ L1

• โค้ดน้อยกว่า 1k Line ใน Single Commit ทำให้รองรับ multiple Client ช่วยปิดช่องโหว่ของ Proof ที่ไม่ว่าจะดีแค่ไหนแต่ถ้าใช้แค่ Client เดียวก็เสี่ยง

ทำไมการใช้ Client เดียว = เสี่ยง? เพราะว่า Proof คือระบบคอนเฟิร์ม execution บน Client ถ้าอยู่ๆ มีบัคเกิดขึ้นใน Client ขึ้น ตัว Proof มันก็จะ Proof บัคให้ผ่านอยู่ดี การทำ Client Diversity คือคำตอบ และเป็นเหตุผลที่ OP Stack จะรองรับหลาย Proof พร้อมกัน

ถึงแม้ทีม OP จะทำ Execution Layer ให้เป็น EVM แต่สิ่งนี้ก็ไม่จำกัดอยู่แค่นี้ เพราะมีความยืดหยุ่นสูงมาก จะเอาไปใส่เกมส์มายคร๊าฟอย่าง OPCraft ของ @latticexyz จะใส่ Gameboy ก้ได้ ใส่ Python ก็ได้ ทำอะไรก็ได้แค่ compile MIPS

ส่วนใหญ่เค้าจะเคลมว่ามันคือ state root ของระบบ L2 เช่น Fault Proof / Validity Proof ซึ่งแต่ละเชนก็จะใช้เคลมเป็นจุดขาย ถ้าเอา OP Stack ไปใช้ ก็สามารถเลือกแบบที่ชอบ หรือจะใช้ Proof หลายๆ แบบก็ได้ แค่ทำให้มันเข้าถึง DA layer ได้ก็เวิร์ก

จะทำให้เข้าถึง DA Layer โดยใช้ type DA = byte[] เพื่อให้เข้าถึง Array of blobs แล้ว getBlobByIndexer

Idea นี้มี property ที่สำคัญสองอย่าง

1. ต้องสามารถ return the blobs ซึ่งต้องพึ่ง Data availability Layer

2. ต้องมีระบบที่ Proof ความถูกต้องของ Blobs

Validation function ใน Bedrock ข้อดีของ ETH คือเราสามารถย้อนดูบล็อกก่อนหน้าได้เรื่อยๆ Bedrock ก็จะตรวจสอบความถูกต้องของ Blobs ด้วยการทำแบบนั้น

หลังจากที่รวมทุกอย่างที่เล่าเข้าด้วยกัน Bedrock Codebase สามารถเอาไปทำอะไรก็ได้ตามใจ ไม่ว่าจะเป็นเรื่องเล็กๆหรือเรื่องใหญ่ๆ

• ทำ bitcoin plasma

• ทำ Bridge rollup ที่ใช้ multiple DA และ Settlement Layer

• สร้าง VM คู่ขนาด ไว้ Raise fund ขำๆ (แซะ) ทำอะไรก็ได้ที่ลงตัวกับ APIs