โอ้วว : ทุก L2 นั่นมี Upgrade Keys นะ
มันมีความจริงที่สำคัญอย่างนึงที่ไม่ค่อยนำมาพูดคุยกันบ่อยๆ เกี่ยวกับ layer 2 : ในทุกๆ โปรเจ็คหลักของ L2 นั้นจะมีทีมงานที่ได้รับความไว้วางใจสามารถแก้ไข(อัพเกรด) Protocol ได้ ณ ตอนนี้มันคือ สิ่งที่ให้ความสำคัญหลักของการเป็น Centralization (การรวมศูนย์) ของทุกคนรวมถึงเราด้วย ถ้าหากว่า upgrade keys (การเข้าถึงการแก้ไข) ถูกใช้ในทางที่ผิด ทุกๆ assets (สินทรัพย์) ที่ฝากไว้บน L2 จะมีความเสี่ยง
Alternative L1s (เช่น AVAX หรือ SOL) ที่มีการใช้ bridged assets บน Ethereum สุ่มเสี่ยงที่จะถูกโจมตีอย่างมาก การนำวิธีรักษาความปลอดภัยแบบ L1 เพื่อหลีกเลี่ยงความเสี่ยงนี้มันจึงเป็นกุญแจส่วนหนึ่งของวิสัยทัศน์ใน L2 แต่เรายังไม่ถึงจุดนั้น ลึกๆแล้วเราทุกคนก็อยากไปถึงจุดนั้นทั้งนั้น
คราวนี้เรามาพูดถึง สิ่งอันตรายที่ทำให้โปรเจ็ก L2 ยังคงใช้ upgrade keys, Ethereum หลีกเลี่ยงปัญหานี้ได้ด้วยตัวเองอย่างไร, และเราสามารถที่จะทำตามยังไงได้บ้าง
State of Layer 2 Centralization
ระบบความปลอดภัยของคุณนั้นจะปลอดภัยถึงเพียงแค่สิ่งที่คุณสร้างไว้ในส่วนที่เปราะบางที่สุด ไม่ว่าจะมีการเข้ารหัสดีแค่ไหนก็ไม่สามารถช่วยคุณได้หากคุณตั้งรหัสไว้ เช่น passwordpasswordpassword ดังนั้นแล้วอะไรคือส่วนที่เปราะบางที่สุดใน L2 ทั้งหมด?
คุณลองทายดูสิ : มันคือ upgrade keys ทุกโปรเจ็กของ L2 มีลักษณะเดียวกันคือสามารถแก้ไข contracts ที่ใช้ติดต่อกับ L1 ได้ทั้งนั้น มันดูดีเลยเพราะว่ามันสามารถให้โปรเจ็กพัฒนา และแก้ไขข้อบกพร่องได้ แต่สุดท้ายแล้วมันก็หมายความว่ามีคนกลุ่มนึงที่มีสิทธิ์ที่จะอยากจะกำหนดมูลค่าของ L2 ตามที่ตัวเองต้องการได้เหมือนกัน
มันจึงเป็นคำถามที่ว่า แล้วจะมีประโยชน์อะไรของการมี fault หรือ validity proofs มาใช้ ถ้าสุดท้ายแล้วระบบความปลอดภัยสามารถแก้ไขเขียนทับโดยใช้วิธีการอัพเกรดได้?
เราไม่ได้กำลังจะหมายถึงว่าให้หยุดพัฒนาสิ่งที่เรากำลังสร้างสรรค์กันมา ณ ตอนนี้ แล้วมุ่งไปสู่การ decentralized เลย พวกเรากำลังทำก้าวที่ใหญ่อยู่ สังเกตุว่าเราเพิ่งที่จะตั้งค่าตอบแทนสำหรับคนที่หา bug ของ next-gen fault proofs อยู่ อีกนัยนึงก็คือว่ามันเป็นสิ่งที่บ่งบอกว่าไม่มี L2s ไหนพร้อมใช้ fault/validity proofs ในทุกวันนี้
สิ่งที่กระทำอยู่ในระหว่างนี้มันจำเป็น - การจะสร้างต้นแบบ protocol ที่ซับซ้อนนี้มันมีนัยยะที่สำคัญ - แต่เราก็จำเป็นจะต้องพูดว่าควรจะมีเส้นทางที่เกี่ยวกับการยกเลิกการใช้ keys และตระหนักถึงวิสัยทัศน์ของ decentralized L2 จริงๆ
Why L2 is not Decentralized (แล้วทำไม L2 ถึงไม่ Decentralized)
A Necessary Evil
ก่อนที่จะเข้าถึงการแก้ปัญหา อันดับแรกเราต้องหาปัญหานั้นก่อน: เหตุผลที่ทุก L2s มี upgrade keys ก็เพราะว่าการเขียนโค้ดมันซับซ้อน จะเขียนให้ไม่มีบั๊กเลยนั้นมันยากจริงๆ ทุกๆบรรทัดที่ถูกเขียนขึ้นใหม่ก็จะมีโอกาสจะเกิดบั๊กใหม่ๆ เช่นกัน
ในคริปโตนั้นหากเจอข้อบกพร่องที่สำคัญเพียงอย่างเดียวก็สามารถทำให้โปรเจ็คพังไปได้เลย พวกเราจะต้องระวังอย่างมากที่สุด นั่นหมายความว่าควรจะมีโค้ดที่ง่ายหรือกระทัดรัดจะดีกว่า การที่เขียนโค้ดให้น้อยเป็นปรัชญาที่ทางทีมยึดถือไว้อยู่ และมันเป็นตัวกระตุ้นให้เกิด EVM equivalence upgrade เราของนั่นเอง (ถึงแม้อยากจะเป็นอย่างนั้นก็ตาม ก็ยังมี bug เกิดขึ้น slip through the cracks)
มันเป็นความจริงที่ว่าทุก bug ใหญ่ๆ ใน L2 จะก่อให้เกิดหายนะ: smart contracts ที่เป็นการออกแบบโครงสร้างหลักของ L2 นั้นจะถูกนำมาใช้ผ่าน security ของ L1 หากเกิดความเสียหายนั่นเอง หากไม่มี upgrade keys ซึ่งเป็นหนทางสุดท้ายแล้ว ก็ไม่สามารถแก้ไขกลับคืนหายนะนั้นได้ มันจึงถูกตั้งไว้ปราการด่านสุดท้าย
Look to Ethereum
ด้วยตัว Ethereum เอง เป็นตัวอย่างที่ดีที่สุดในการ decentralized security และพวกเราสามารถใช้มันเป็นตัวชี้วัดได้ว่าความยากเย็นในการเขียนโค้ดโดยไม่มี bug เลย ใน L2 เป็นอย่างไร หากย้อนไปแล้ว Ethereum เจอปัญหา bugs มากมาย ทั้งแบบเจอเนิ่นๆ, เจอแบบเต็มๆ, รวมทั้งต้องแก้ไข, หรือแม้กระทั่งต้อง hard forks โดยที่ไม่อยากจะทำ (เชื่อเราสิ มันไม่สนุกเลย)
ถึงแม้ว่าจะเจอ bug สำคัญๆ Ethereum ก็ยังสามารถอยู่รอดมาได้ และเพิ่ง 2 ปีมานี้ Ethereum ก็เกือบจะไม่รอดจากการโจมตีใน Shanghai DoS attacks แต่การโจมตีนี้ก็ยังคงมีอยู่จนถึงทุกวันนี้ มันจึงเป็นความสำเร็จที่น่ายินดี
จนถึงตอนนี้พวกเราสามารถมั่นใจได้ถึงที่สุดว่า Ethereum L1 จะไม่พังลง หรือถูกยึดครอง เราจำเป็นต้องสร้างความมั่นใจในระดับเดียวกันนี้ใน L2 โดยการยกเลิกการใช้ upgrade keys แล้วอะไรคือ ความลับอันนี้? แล้วเราสามารถดำเนินรอยตามเพื่อมี securityใน L2 ที่ยอมรับกันได้หรือไม่
เราไปขอพรดราก้อนบอลกันเถอะ… ล้อเล่น ล้อเล่น เราทำได้
Pragmatic Path to Decentralization
ความสำเร็จของ Ethereum ที่มีโอกาสเสียหายน้อยที่สุด และอยู่ให้ได้นานที่สุดนั่นไม่ใช่ได้มาง่ายๆ มันบ่งบอกให้เห็นความจริงที่ว่า Ethereum โดยยุทธศาสตร์แล้วสร้าง Multi-client ecosystem ที่ซึ่งมีการทำงานแบ่งแยกกันในส่วนต่างๆ โดยทำงานร่วมกันได้
วิธีการสร้างความปลอดภัยนี้อยู่บนพื้นฐานที่ว่าการเกิดบั๊คจะไม่มีความสัมพันธ์กันในส่วนต่างๆ หรือในอีกความหมายนึงว่า ถ้าในส่วนใดส่วนหนึ่งมีบั๊คเกิดขึ้น, ส่วนอื่นๆ ก็จะไม่ได้ผลกระทบตามกันมาในบั๊คเดียวกัน
โดยวิธีนี้ หากเกิดส่วนที่ผิดพลาด คุณก็แก้ไขตรงจุดนั้นโดยที่ระบบยังทำงานได้ปกติ การที่มีการรองรับระบบไว้ขนาดนี้จึงเป็นกุญแจของหลักประกันระดับสูงที่ถูกใช้อยู่ทุกวันนี้
เราสามารถดำเนินรอยตาม Ethereum และใช้รูปแบบนี้ใน L2 ได้ แทนที่มีส่วนการทำงานเพียงส่วนเดียว, fault proof แบบเดียว หรือ ZK proof แบบเดียว เราสามารถที่จะสร้าง Multi-client ecosystem บน L2 อย่างที่เป็น L1 ได้เหมือนกัน มันจะทำให้มั่นใจได้ว่าหากมีช่องโหว่ทางความปลอดภัยที่น่ากังวล ก็จะไม่ทำให้เน็ตเวิร์คล่มลง หรือแม้กระทั่งมันจะคงช่องโหว่ไว้ก็ตาม
Decentralizing Optimism with a Multi-client Architecture
พวกเราออกแบบ Optimism โดยยึดแบบปรัชญาของ Ethereum ไม่ใช่แค่เพื่อสังคมแต่รวมถึงทางเทคนิคด้วย ตั้งแต่วันแรกที่พวกเราออกแบบ Bedrock designs พวกเราใช้โครงสร้างของ ETH2 merge API เพื่อที่จะเชื่อมกับ multiple clients ได้
อันที่จริงแล้วพวกเราตั้งเป้าว่าจะลดโค้ดให้ต่ำกว่า 1,000 บรรทัด เพื่อเพียงพอกับ Ethereum client ให้เป็น Optimism client หากเป็น EVM equivalence แล้วเราแยกการใช้งาน faut proof และ rollup client ออกไปเป็นส่วนๆด้วย หากรวมทั้ง 2 อย่างนี้แล้ว วิธีการนี้จะทำให้เราผสมสานทั้ง proofs และ clients เพื่อก่อให้เกิดระบบรองรับข้อผิดพลาดได้สูงที่สุด
ZK Rollups: An Extra Layer of Security
พวกเราถูกถามอยู่บ่อยๆ ว่า “คุณจะนำเทคโนโลยี zero knowledge proof มาใช้มั๊ย” คำถามตอบก็คือว่า มันเป็นไปได้ แต่อาจจะไม่ใช่ในมุมที่คุณคิด มันมีหนทางอยู่ แต่ถ้าเทคโนลยี ZK เกิดมีประสิทธิภาพสูงจนสามารถสนับสนุน EVM equivalence ได้ มันก็เป็นไปได้ที่เพิ่ม client เข้าไปใน multi-client นี้ นี่ไม่ได้หมายความว่าเรากำลังจะเปลี่ยนโครงสร้างหรือการทำงานหลัก แต่มันหมายถึงเพิ่มความปลอดภัยในอีกรูปแบบหนึ่งเข้าไป
ดังนั้นในขณะที่ ZK ดูน่าสนใจ เราไม่จำเป็นต้องรอให้มีค่าใช้จ่ายที่ต่ำ, ความปลอดภัยที่สูง และรอให้มี EVM equivalent กับ L2 ตอนนี้ Optimism ก็สามารถทำได้อยู่แล้ว และถ้า ZK เสถียรแล้ว เราก็สามารถบรรจุเข้าโครงสร้างของเราได้ทันที
The Rollout
ถึงตอนนี้แล้วเราอยู่ในช่วงพัฒนาแก่นของรากฐานสำคัญ (Bedrock) โดยจะมาจาก EVM Equivalent, rollup client และ MIPs fault proof (หรือ Cannon) ถึงตอนนั้นแล้ว multi-client ถึงจะเริ่มได้
เป้าหมายของเราคือ การทำงานและส่งเสริมทีมงานภายนอกให้สร้าง clients มากขึ้น มันจะไม่ใช่กระบวนการที่เร็ว แต่รากฐานสำคัญ(Bedrock😉) กำลังจะถูกสร้างขึ้น และอยูในกรอบของการมีโค้ดที่น้อยที่สุด การที่รวมทั้งหมดนี้เข้าไปใน multi-client proof system ได้ จำเป็นจะต้องใช้โครงสร้างของ Hydra จนถึงจุดนี้แล้วพวกเราจะมั่นใจได้ว่าเราจะไม่ใช้ upgrade keys อีกต่อไป
บทสรุป:
- รวบรวมคนที่มองโลกในแง่ดีมารวมกัน
- เปิดใช้งานโครงสร้างพื้นฐาน (Bedrock) และนำ multi-client มาใช้
- ช่วยเหลือและส่งเสริมการสร้าง Optimism clients
- ใช้งาน multi-client proof contracts
- หลอมละลาย upgrade keys ไปในภูเขาไฟที่ร้อนระอุ (ยกเลิกการใช้งาน)
We’re Decentralized Now
ยินดีด้วย คุณได้อ่านมาถึงบรรทัดสุดท้ายแล้ว ซึ่งหมายถึง L2 มัน decentralized อย่างสมบูรณ์แบบ และเราก็บรรลุถึงวิสัยทัศน์ของ L2 อย่างเต็มรูปแบบ คุณกำลังอยู่ในโลกคริปโตที่ปราถนา
CAREFUL - หวังว่าเราไม่ได้หลอกคุณ มันจะต้องใช้เวลาในการเขียนซอฟทแวร์ กรุณาเฝ้ารอและติดตาม มองโลกในแง่ดีให้มากขึ้นด้วยการเฝ้ามองมัน ถึงแม้ว่าเรายังไม่ได้อยู่ในโลกคริปโตที่ปราถนา แต่เราจะไล่ตามมัน
L2 จะทำมาสู่ยุคคอมพิวเตอร์แบบ decentralize ในระดับโลก เรายังไปไม่ถึงแต่เราจะอดทน - ที่จริงแล้วการที่เรายังไปไม่ถึงจุดจบของการเดินทาง มันคือ โอกาส !
มันแปลว่าคุณสามารถที่จะมีส่วนร่วมและสร้างให้มันเป็นจริงได้
We’re hiring! Join our community! Have fun! Enjoy life! Don’t worry so much! Brush your teeth! Eat apples! Eat bacon! Research the origins of public relations! Give back to your community! Tweet things you don’t actually believe! Download free music using your library card! Don’t download a car! Don’t listen to anyone except for your parents, and even then, with a grain of salt!
Last — we’d like to give a very special thanks to Yoav Weiss for helping us come up with this pragmatic path to decentralizing fault proofs!
แปลจาก :