Arbitrum เปิดตัว BOLD protocol ที่จะช่วยทำให้ chain มีความปลอดภัยสูงขึ้น

ณ ปัจจุบันอย่างที่เรารู้กันดีว่าเทคโนโลยี L2s ต่างๆนั้นยังอยู่ในช่วงกำลังพัฒนา โดยถ้าหากพูดถึง 1 ใน Optimistic rollups ยอดนิยมหลายๆคนก็คงจะนึกถึง Arbitrum ซึ่งตอนนี้มียอด TVL มาเป็นอันดับ 1 และ ก็มีอัปเกรดอยู่หลายครั้งไม่ว่าจะเป็น Arbitrum Nitro ที่ช่วยลดค่าแก๊ส, จะมีการอัปเกรดชื่อ stylus ที่จะช่วยให้ developer สามารถเขียน smart contract ด้วยภาษา Rust,C และ C++ ได้, และ ล่าสุดได้ประกาศอัปเกรดที่จะช่วยให้ทุกๆคนสามารถตรวจสอบความถูกต้องของ chain ได้ ด้วย Dispute protocol ที่ชื่อว่า “BOLD” สามารถอ่านเพิ่มเติมเกี่ยวกับ Arbitrum และ การทำงานของ L2s ได้ที่นี้

*Dispute protocol หมายถึง ระบบที่ใช้ในการตรวจสอบความถูกต้องของการประมวลผลได้ โดยการใช้ Fraud proof

ขอบคุณภาพจาก https://offchain.medium.com/bold-permissionless-validation-for-arbitrum-chains-9934eb5328cc 

BOLD คืออะไร

BOLD (Bounded Liquidity Delay) คือ Dispute protocol ที่ถูกสร้างด้วย Offchain labs ที่จะช่วยให้ทุกๆคนสามารถที่จะตรวจสอบการประมวลผล validator ของ Arbitrum ว่าทำงานได้อย่างถูกต้องหรือไม่ จากเดิมเป็นแบบ permissioned เปลี่ยนเป็นแบบ permissionless และด้วยเทคโนโลยีนี้จะช่วยให้ Arbitrum มีความปลอดภัยมากยิ่งขึ้น โดยหัวใจหลักมีอยู่ 3 อย่างคือ

1. Guarantee : ช่วยเพิ่มความ liveness (ระบบไม่ล่ม) และ safety (ความปลอดภัย) ให้กับ chain มากยิ่งขึ้น
2. Minimize : ลดความหน่วงในการ settle states
3. Prevent : เนื่องจากใครๆก็สามารถตรวจสอบความถูกต้องได้ ช่วยป้องกัน validator ผู้ที่ไม่หวังดีกับ chain 

Dispute game คืออะไร

ขอบคุณภาพจาก https://www.alchemy.com/overviews/optimistic-rollups 

เนื่องจาก L2s แบบ Optimistic rollups เป็นการที่ประมวลผลแบบการมองโลกในแง่ดี และ จะสันนิฐานว่าข้อมูลที่บันทึกลง L1 ทั้งหมดนั้นถูกต้อง โดยการบันทึกจะแบ่งออกเป็น 2 อย่างคือ

1. Transactions data : ถูกบันทึกในรูปแบบ calldata (ในอนาคตหลังจากมีการอัปเกรด EIP-4844 จะเปลี่ยนเป็น blobs data)
2. State root : เป็น hash root ของ state trie (account balance, contract storage, contract code, account nonce ของทุก account บน L2s นั้นๆ) หลังจากที่ transactions ถูก executed โดย L2s

ด้วยการที่ L1 ไม่ได้เป็นผู้ประมวลผลธุรกรรมด้วยตนเอง ทำให้เกิดสิ่งที่เรียกว่า Dispute game ขึ้น เพราะเราไม่รู้ว่า L2s นั้นประมวลผลธุรกรรมถูกต้องหรือไม่ โดยหากมีผู้ที่พบว่ามีการบันทึก invalid state root จะสามารถ dispute ได้ โดยการสร้าง Fraud proof (Fault proof) ขึ้นมา เพื่อ challenge นั้นเอง ซึ่งจะอาศัยแค่คนที่ซื่อสัตย์แค่ 1 คนในการตรวจสอบความถูกต้อง chain  

BOLD จะทำให้ Arbitrum ช่วยให้มีความ Decentralized มากขึ้นหรือไม่

ขอบคุณภาพจาก https://l2beat.com/scaling/summary 

อ้างอิงข้อมูลจาก L2beat ณ ปัจจุบัน ที่ใช้ประเมินความปลอดภัยของ L2s ต่างๆ โดยใช้ Metrics ดังนี้

1. Data availability : มีการบันทึก data ในรูปแบบใด เช่น on-chain หรือ off-chain
2. Upgradeability : ขั้นตอนอัปเกรดทำได้อย่างไร เช่น ถูกกำหนดด้วยการโหวตจาก DAO หรือ จาก Multisig 
3. Proposer failure : หาก proposer (L2 ส่วนใหญ่จะเป็นคนเดียวกับ sequencers) ไม่ยอมบันทึก L2s state root จะสามารถแก้ไขได้ยังไง จะสามารถแก้ไขได้ยังไง เช่น หาก proposer หยุดทำงานเป็นเวลาหลายๆวันใครจะสามารถมาเป็น proposer ก็ได้ หรือ จะมีแค่ whitelist proposer เท่านั้นที่สามารถบันทึก state root จาก L2s ลงไปบน L1 ได้
4. Sequencer failure : หาก sequencers ไม่ยอมบันทึก data ลงบน L1 จะสามารถแก้ไขได้ยังไง  เช่น user สามารถบันทึกข้อมูลลงบน L1 ได้ด้วยตนเอง หรือ หาก sequencers ล่มจะไม่สามารถบันทึกข้อมูลลงบน L1 ได้ 
5. State validation : มีการตรวจสอบความถูกต้อง state ของแต่ละ L2s อย่างไร เช่น Fraud proof หรือ Validity proof

ขอบคุณภาพจาก https://l2beat.com/scaling/projects/arbitrum 

โดยสีของ pie chart จะแบ่งออกเป็น 3 สี ไล่ตามความปลอดภัย คือ เขียว, เหลือง, แดง ซึ่งจากภาพด้านล่างจะเห็นได้ว่า Arbitrum นั้นเขียว 3 ช่อง คือ 

1. Data availability : Transactions data ถูกบันทึกลงบน L1 (on-chain) จึงมีความปลอดภัยสูงสุด
2. Sequencer failure : user สามารถบันทึก data ลงบน L1 ได้ด้วยตนเอง หาก sequencer หยุดทำงาน
3. Proposer failure : หาก proposer หยุดทำงานเป็นเวลาประมาณ 6 วัน ใครก็จะสามารถมาเป็น proposer ได้

และ เหลือง 2 ช่อง คือ

1. State validation : เนื่องจาก ณ ปัจจุบัน ผู้ที่ตรวจสอบความถูกต้อง และ ในกรณีที่จะมีความผิดพลาดเกิดขึ้น คนที่สามารถ submit fraud proof ได้ จะมีแค่ผู้ที่ได้รับเลือกเท่านั้น (Whitelisted actors)
2. Upgradeability : การอัปเกรดจะถูกกำหนดด้วย Arbitrum DAO แต่จะมีทาง Security council 12 คนที่สามารถยกเลิก หรือ อัปเกรดได้ในกรณีฉุกเฉินเช่น พบบัคร้ายแรงที่จะรีบแก้ไข จะสามารถอัปเกรดได้ทันทีโดยไม่มี delay ซึ่งจะต้องได้รับการ approve จาก 9/12 คน จาก Multisig

“โดย BOLD จะช่วยให้ pie chart ส่วนของ state validation นั้นเป็นสีเขียว” เนื่องจากจะเปิดให้ state validation จากเดิมที่เป็นแบบ permissioned เป็นแบบ permissionless ซึ่งช่วยให้มีความ decentralized มากขึ้น

Roadmap

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

1. จะมีการ share วิธีการทดลองใช้งาน BOLD บน Arbitrum Nitro devnet ในสัปดาห์หน้า
2. ทำการ publish code ของ BOLD ที่เขียนด้วยภาษา Isabelle programming และ academic-style paper (เป็นรายละเอียดข้อมูลแบบเชิงลึก)
3. ทำการทดสอบบน public testnet โดยให้ community มีส่วนร่วมทดสอบ
4. หากผลตอบรับเป็นไปในทางที่ดีจะมีการเสนอ AIP และ ให้ DAO เป็นคนผู้โหวตเพื่อปรับใช้กับ Arbitrum one และ Nova

สรุป

การที่ Arbitrum มีระบบ dispute system แบบใหม่ที่เรียกว่า “BOLD” จะช่วยให้ทุกๆคนสามารถตรวจสอบความถูกต้องของการประมวลผลต่างๆของ L2s ได้ โดยจากเดิมที่ต้องเชื่อใจ whitelist actors ที่คอยรักษาความปลอดภัยให้กับ chain (แบบ permissioned) ก็เปิดให้มีการตรวจสอบแบบ permissionless ซึ่งจะช่วยเสริมความแข็งแกร่งด้านความปลอดภัยมากขึ้น มีความ decentralized มากขึ้น (ในส่วนของการตรวจสอบความถูกต้อง)