การตีความโพสต์บล็อกของ Vitalik: จุดหยุดถัดไปสำหรับการห่อหุ้มหรือขยายโครงสร้างพื้นฐาน Web3 หรือไม่

ชื่อเดิม: Encapsulation หรือ Extension? จุดต่อไปเพื่อหารือเกี่ยวกับโครงสร้างพื้นฐาน Web3 - การตีความบล็อก Vitalik Enshrinement

ผู้เขียนต้นฉบับ: CP, Artela CTO และผู้ร่วมก่อตั้ง

Vitalik เผยแพร่บล็อก Ethereum ควรโอเคกับการประดิษฐานสิ่งต่าง ๆ มากขึ้นในโปรโตคอลหรือไม่ เมื่อสัปดาห์ที่แล้ว แบ่งปันความคิดของเขาเกี่ยวกับฟังก์ชันพื้นฐานที่จำเป็นสำหรับแอปพลิเคชันชั้นบน enshrine ของ Ethereum และหารือเกี่ยวกับวิธีแนะนำเฟรมเวิร์กเพื่อห่อหุ้มพื้นฐานเพิ่มเติม ฟังก์ชั่นที่จำเป็นสำหรับแอปพลิเคชันชั้นบน

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

ในช่วงหกเดือนที่ผ่านมา โครงสร้างพื้นฐานที่สำคัญหลายแห่งได้เปิดตัวการอัปเดตทางเทคนิคที่สำคัญ: Uniswap เปิดตัวกลไก Hook เพื่อรองรับพูลที่ขยายฟังก์ชันที่กำหนดเอง กระเป๋าเงิน MetaMask เปิดตัว Snaps เพื่อรองรับนักพัฒนาในการเพิ่มส่วนขยายผู้ใช้ ขณะนี้ Ethereum กำลังเผชิญกับ การห่อหุ้มและส่วนขยาย “ปัญหาที่ยาก.

บทความนี้จะหารือเกี่ยวกับตัวเลือกการออกแบบ การห่อหุ้มเทียบกับส่วนขยาย ของโครงสร้างพื้นฐาน Web3 รวมถึงความคิดส่วนตัวบางประการเกี่ยวกับโครงสร้างพื้นฐานห่วงโซ่สาธารณะฉบับนี้

Ethereum ประสบปัญหาอะไรบ้าง? ห่อหุ้มหรือขยาย

ในประเด็น การห่อหุ้มเทียบกับส่วนขยาย Ethereum มักจะเลือก ส่วนขยาย เสมอ

ปรัชญาการออกแบบของ Ethereum มีต้นกำเนิดมาจาก Unix โดยการสร้างเคอร์เนลที่เรียบง่ายและเป็นสากลเพื่อให้นักพัฒนาในเลเยอร์แอปพลิเคชันสามารถรับรู้ความต้องการของผู้ใช้ได้ เทคโนโลยีหลักที่รองรับ Ethereum เพื่อให้บรรลุเป้าหมายนี้คือ: EVM ภาษาสัญญาอัจฉริยะที่สมบูรณ์ของทัวริงช่วยให้นักพัฒนาสามารถปรับแต่งแอปพลิเคชันของตนได้ที่ชั้นแอปพลิเคชัน

โมเดลนี้ดูสมเหตุสมผลแต่ทำงานได้ไม่ดีนักบน decentralized Unix หนึ่งในเหตุผลสำคัญก็คือสิ่งที่เรียกว่าความสมบูรณ์ของ EVM ของทัวริงนั้นไม่ได้ สมบูรณ์ ในการใช้งานจริง ภายใต้กลไกของแก๊สและ opcode ที่จำกัด โปรแกรมต้องใช้ opcode ที่จำกัดในขั้นตอนที่จำกัดเพื่อทำงานให้สำเร็จ สิ่งนี้จำกัดแอปพลิเคชันอย่างมากและทำให้ยากต่อการเป็นผู้มีอำนาจทุกอย่างเหมือนโปรแกรม Web2 ในเลเยอร์ผู้ใช้ของ Unix ระดับสูงมากมาย แอปพลิเคชัน ความสามารถที่ต้องการโดย dApps ระดับสูงไม่สามารถตอบสนองโดย EVM ไม่ว่าจะเป็น Rollup หรือ AA wallet แม้ว่าจะสามารถทำงานได้อย่างราบรื่นโดยไม่ต้องแก้ไข L1 แต่ก็ยังคงเป็นผลิตภัณฑ์ MVP และประสิทธิภาพและประสบการณ์ยังห่างไกลจากเป้าหมาย

ตัวเลือกก่อนนักพัฒนาคือ: EIP ปล่อยให้ทีมงานหลักของ Ethereum สรุป ฟังก์ชันสำคัญที่ขึ้นอยู่กับเลเยอร์ด้านล่าง ดังนั้นจึงจัดเตรียมไว้สำหรับใช้งานในเลเยอร์แอปพลิเคชัน

ส่วนขยาย ที่ใช้ EVM ไม่สามารถตอบสนองความต้องการในการพัฒนาแอปพลิเคชันได้ และตอนนี้พวกเขาจำเป็นต้องพิจารณาอย่างรอบคอบว่าจะ ห่อหุ้ม ส่วนขยายเหล่านั้นอย่างไร

อย่างไรก็ตาม ไม่ใช่เรื่องง่ายสำหรับโครงสร้างพื้นฐานแบบกระจายอำนาจที่จะห่อหุ้มฟังก์ชันแอปพลิเคชันชั้นบนไว้ ไม่เพียงแต่เกี่ยวกับการบูรณาการโค้ดเพียงชิ้นเดียวเท่านั้น เบื้องหลังคือปัญหาที่ใหญ่ที่สุดของระบบการกระจายอำนาจ ซึ่งก็คือ การกำกับดูแล “Encapsulation” หมายความว่านอกเหนือจากการพัฒนาและบำรุงรักษาแล้ว ทีมหลักยังต้องรับผิดชอบในการกำกับดูแลฟังก์ชันเหล่านี้ด้วย ขณะเดียวกัน ก็มีความเสี่ยงที่จะทำให้โมเดลความน่าเชื่อถือของ Ethereum อ่อนแอลง และแนะนำปัญหาที่อาจส่งผลกระทบอย่างยั่งยืน การพัฒนา.

ดังนั้นผลลัพธ์สุดท้ายจึงมองเห็นได้ง่าย: มีฟังก์ชันจำนวนจำกัดที่ทีมงานหลักสามารถ ห่อหุ้ม ได้ ประการที่สอง ความสำคัญของฟังก์ชันนี้จำเป็นต้องได้รับการยอมรับอย่างกว้างขวางจากชุมชน ท้ายที่สุด ประสิทธิภาพการใช้งานจะไม่เป็นเช่นนั้น สูง และคงต้องใช้เวลาอีกหลายปี .

ในขณะเดียวกัน นี่ก็หมายความว่าหากฟังก์ชันที่คุณต้องการไม่ใช่ฟังก์ชันพื้นฐานที่ได้รับการยอมรับอย่างกว้างขวาง Ethereum ก็อาจไม่สามารถรองรับคุณได้ แม้ว่าคุณจะลองแล้ว คุณอาจต้องเลือกสร้าง Application Chain ของคุณเองและ แบกรับต้นทุนการพัฒนาและการดำเนินงานที่สูงและสูญเสียความสวยงามของความสามารถในการประกอบในโลกแห่งสัญญาอัจฉริยะ

ในประเด็น การห่อหุ้มและการขยาย Ethereum ยังไม่มีวิธีแก้ปัญหาที่ชัดเจน วิธีทำให้ การห่อหุ้ม เกิดขึ้น อย่างเป็นระเบียบ คือสิ่งที่ Vitalik กล่าวถึง พวกเขายังคงสำรวจกรอบการทำงาน วิธีกำหนดฟังก์ชันเป้าหมายที่จะห่อหุ้ม และวิธีการห่อหุ้มฟังก์ชันเหล่านั้น

คุณสามารถเรียนรู้อะไรอีกจาก Unix? ส่วนขยายดั้งเดิม!

ในประเด็นของ การห่อหุ้มเทียบกับการขยาย นั้น Ethereum ต้องการให้ทีมงานหลักทำการห่อหุ้มเป็นหลักเพื่อชดเชยการขาดความสามารถในการขยายของ EVM ลองคิดดูจากอีกมุมมองหนึ่ง ถ้าเราปรับปรุง scalability ของ application layer เราจะสามารถแก้ปัญหาส่วนใหญ่ได้หรือไม่ ตัวอย่างเช่น: นักพัฒนาแอปพลิเคชันสามารถปรับแต่งฟังก์ชันพื้นฐานที่จำเป็นสำหรับแอปพลิเคชันของตนตามแนวคิดของตนเองโดยไม่ต้องรอให้ทีมต้นแบบสรุปฟังก์ชันเหล่านั้น

เรายังทราบด้วยว่า Ethereum ได้ซึมซับปรัชญาการออกแบบมากมายจาก Unix ดังนั้นให้เราค้นหาแนวคิดในระบบ Unix ต่อไป

ระบบปฏิบัติการเชิงพาณิชย์ที่ใช้ Unix มุ่งเน้นไปที่ตลาดพีซี และเผชิญกับความต้องการที่หลากหลายมากขึ้นในเลเยอร์แอปพลิเคชัน และแม้กระทั่งความต้องการขยายจากสถานการณ์การใช้งานระดับองค์กร แต่สำหรับระบบปฏิบัติการเชิงพาณิชย์เหล่านี้ ทีมงานหลักไม่มีภาระ การห่อหุ้ม มากนัก ความสามารถในการปรับขนาดที่พวกเขามีให้สำหรับแอปพลิเคชันนั้นสูงเพียงพอเพื่อให้ผู้ใช้สามารถแก้ไขฟังก์ชันส่วนใหญ่ได้ด้วยตัวเอง

ระบบปฏิบัติการทั่วไปจะแยกความแตกต่างระหว่างโหมดเคอร์เนลและโหมดผู้ใช้ โดยใช้ Mac OS X เป็นตัวอย่าง โดยทั่วไปแอปพลิเคชันผู้ใช้จะทำงานในโหมดผู้ใช้และใช้ฟังก์ชันที่ได้รับจากโปรแกรมโหมดเคอร์เนล การเปรียบเทียบง่ายๆ (แต่ไม่สมบูรณ์) คือสัญญาอัจฉริยะบน EVM เทียบเท่ากับแอปพลิเคชันโหมดผู้ใช้ และเลเยอร์โปรโตคอล Ethereum เทียบเท่ากับโหมดเคอร์เนล

อย่างไรก็ตาม Mac OS X ช่วยให้นักพัฒนาแอปพลิเคชันสามารถปรับใช้โปรแกรมในสถานะเคอร์เนลได้อย่างอิสระเพื่อขยายฟังก์ชันของสถานะเคอร์เนลโดยไม่ต้องใช้ Mac OS กลไกหลักที่มีให้โดยฟังก์ชัน Mac OS

แรงบันดาลใจที่เราได้รับคือโมเดล ส่วนขยายเคอร์เนล เป็นไปได้บน Unix แบบกระจายอำนาจ หรือไม่ ลวดลายของมันดังแสดงในรูปด้านล่าง

นอกเหนือจากการสนับสนุน สัญญาอัจฉริยะ แล้ว โปรโตคอลบล็อกเชนยังรองรับโปรแกรมอื่น Native Extension ซึ่ง

1) มีสิทธิ์การเข้าถึง API โปรโตคอลพื้นฐานมากกว่าสัญญาอัจฉริยะ

2) และประสิทธิภาพของสภาพแวดล้อมในการดำเนินการนั้นมีลำดับความสำคัญที่สูงกว่า EVM

3) และมันถูกแยกออกจากโปรโตคอลพื้นฐาน และไม่ส่งผลกระทบต่อความเสถียรของโปรโตคอลพื้นฐาน

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

หากโมเดลนี้สามารถตอบสนองสี่จุดข้างต้นในทางเทคนิค ดูเหมือนว่าจะสามารถแก้ไขปัญหาต่างๆ ได้มากมาย กล่าวคือ นักพัฒนาแอปพลิเคชันสามารถปรับแต่งฟังก์ชันพื้นฐานที่จำเป็นสำหรับแอปพลิเคชันของตนตามแนวคิดของตนเอง โดยไม่ต้องรอให้ทีมต้นแบบสรุปมัน

เราจะสรุปกระบวนทัศน์นี้ว่าเป็นกระบวนทัศน์ ส่วนขยายดั้งเดิม ในขณะนี้ จากนั้นดูว่ามีเงาของกระบวนทัศน์ดังกล่าวในโครงสร้างพื้นฐาน Web3 ที่มีอยู่หรือไม่

Hook, Hook, Hooks…

ในโลกของซอฟต์แวร์ วงล้อที่ยอดเยี่ยมมักถูกสร้างขึ้นจากสถานการณ์ที่ยอดเยี่ยม ในฐานะโครงสร้างพื้นฐาน DeFi Uniswap อยู่ในขั้นตอนสำคัญของการเป็น แพลตฟอร์ม และมีการออกแบบที่น่าทึ่งเกี่ยวกับลักษณะของ การห่อหุ้มและการขยาย: Hook ช่วยให้นักพัฒนาสามารถใช้ Hooks เพื่อเพิ่มส่วนขยายลงในพูลโดยไม่ได้รับอนุญาตเพื่อให้ได้ประสบการณ์พูลที่มีฟังก์ชันการใช้งานที่หลากหลาย โดยไม่จำเป็นต้องให้ทีมหลักอัปเกรดฟังก์ชันอย่างต่อเนื่องผ่าน การห่อหุ้ม

กลไกของ Hook นั้นคล้ายคลึงกับเงื่อนไขหลายประการของ Native Extension ที่กล่าวไว้ข้างต้น:

· Hook สามารถตัดเข้าสู่วงจรการดำเนินการของพูลและสามารถเข้าถึงข้อมูลรันไทม์ได้ นี่เป็นระดับการเข้าถึงขั้นสูงกว่า

· Hook และ Pool เป็นสัญญาอิสระสองสัญญา และการรักษาความปลอดภัยของ Hook จะไม่ส่งผลกระทบต่อพูล

· ในแง่ของการกำกับดูแล Hooks ได้รับการพัฒนาและใช้งานโดยนักพัฒนาบุคคลที่สามโดยไม่ได้รับอนุญาตและไม่ได้เปิดใช้งานทั่วโลก แต่พูลที่ต่างกันจะผูก Hooks ที่แตกต่างกันตามความจำเป็นเพื่อเปิดใช้งานคุณสมบัติที่กำหนดเอง

Hook เป็นดีไซน์ที่เล็กแต่สวยงาม ซึ่งช่วยแก้ปัญหาเรื่องความสามารถในการปรับขนาดของสระน้ำได้ โครงสร้างพื้นฐานของเลเยอร์แอปพลิเคชันเป็นผู้นำในการใช้แนวคิดเหล่านี้ มาดูแนวคิดของโปรโตคอลพื้นฐานที่ซับซ้อนมากขึ้น (L1/L2) กันต่อ

แนวคิดในการขยายโครงการห่วงโซ่สาธารณะใหม่

Ethereum กำลังประสบปัญหา มาดูแนวคิดของโปรเจ็กต์เลเยอร์ 2 ที่เน้นการขยายเลเยอร์ 1 กันดีกว่า

Arbitrum Stylus ช่วยให้นักพัฒนาแอพพลิเคชั่นสามารถจัดทำสัญญาที่คอมไพล์ไว้ล่วงหน้าได้ด้วยตัวเอง!

ทุกคนควรรู้ว่า EVM สามารถขยายฟังก์ชันผ่าน สัญญาที่คอมไพล์แล้ว ได้ โค้ดของมันไม่ได้ทำงานใน EVM แต่รวมอยู่ในโหนดและทำงานที่ด้านล่างสุด ตัวอย่างเช่น หากคุณต้องการเพิ่มอัลกอริธึมการเข้ารหัสใหม่ เนื่องจากมีความซับซ้อนและมีราคาแพงเกินไปในการคำนวณ คุณสามารถนำไปใช้เป็นสัญญาที่คอมไพล์แล้วได้ และสัญญาแอปพลิเคชันสามารถเรียกใช้และใช้อัลกอริธึมการเข้ารหัสใหม่ได้ อย่างไรก็ตาม สิทธิ์เพิ่มเติมของสัญญาที่คอมไพล์ไว้ล่วงหน้าไม่ได้เปิดให้นักพัฒนาแอปพลิเคชัน และต้อง ห่อหุ้ม โดยทีมพัฒนา Ethereum ผ่าน EIP ก่อนจึงจะสามารถเพิ่มได้

Arbitrum Stylus เสนอกระบวนทัศน์ EVM+ เลเยอร์ 2 ในขณะที่ดำเนินการตามความเทียบเท่า/ความเข้ากันได้ของ EVM ช่วยให้นักพัฒนาสามารถทะลุขีดจำกัดของ EVM และปรับใช้สัญญาที่คอมไพล์แล้วประสิทธิภาพสูงกว่าโดยไม่ได้รับอนุญาต หลักการนำไปใช้คือการเพิ่มสภาพแวดล้อมการดำเนินการ WASM ให้กับเลเยอร์การดำเนินการเพื่อโหลดและรันสัญญา WASM แบบไดนามิก WASM มอบลำดับความสำคัญที่สูงกว่า EVM และยังรองรับภาษาการเขียนโปรแกรมหลายภาษาอีกด้วย

เป็นหนึ่งในการใช้งานที่สามารถเพิ่มประสิทธิภาพปัญหา การห่อหุ้ม ของ Ethereum ได้ ข้อกำหนดการขยายของ EVM ไม่ต้องรอให้ทีมระดับล่างทำการสรุปอีกต่อไป ทีมระดับล่างมุ่งเน้นไปที่การบำรุงรักษาสภาพแวดล้อมส่วนขยายของเลเยอร์การดำเนินการ ในขณะที่การแนะนำ มีการแลกเปลี่ยนการพัฒนาและการกำกับดูแลฟังก์ชั่นใหม่ ๆ ได้รับการพัฒนาโดยชั้นแอปพลิเคชัน

อย่างไรก็ตาม Stylus ยังอยู่ในช่วงเริ่มต้น ความท้าทายเพิ่มเติมของโมเดลนี้ยังไม่ถูกเปิดเผย และปัญหาที่สามารถแก้ไขได้นั้นมีจำกัด ปัจจุบัน รองรับเฉพาะแพ็คเกจไดนามิกของสัญญาที่คอมไพล์แล้วเท่านั้น และ Ethereum ยังประสบปัญหาด้านแพ็คเกจเพิ่มเติมนอกเหนือจากการคอมไพล์ล่วงหน้า สัญญา แต่น่ายินดี นี่คือหนึ่งในการใช้งานที่เราเห็นได้ซึ่งใกล้เคียงกับกระบวนทัศน์ Native Extension ในฐานะตัวแทนของโครงสร้างพื้นฐานรุ่นใหม่ แนะนำการออกแบบความสามารถในการปรับขนาดเพื่อแก้ปัญหา การห่อหุ้ม ที่ระบบนิเวศจะต้องเผชิญในอนาคต ” ปัญหาโดยคำนึงถึงการพัฒนาระบบนิเวศในระยะยาว

ส่วนขยายดั้งเดิม: แนวคิด การห่อหุ้มแบบแยกส่วน!

หลังจากพิจารณาโครงการโครงสร้างพื้นฐาน เช่น Web2 และ Web3 แล้ว เมื่อมองย้อนกลับไปที่คำถาม การห่อหุ้ม กับ การขยาย เราจะเห็นแนวคิดที่ชัดเจน: นักพัฒนาสามารถใช้วิธีการแบบโมดูลาร์เพื่อห่อหุ้มสิ่งที่พวกเขาต้องการได้โดยการปรับปรุงความสามารถในการขยาย

นี่คือบทบาทสำคัญที่กระบวนทัศน์ Native Extension เล่นในโครงสร้างพื้นฐาน โดยการปรับปรุงความสามารถในการปรับขนาดของโครงสร้างพื้นฐาน ตัวเลือกจะถูกส่งกลับไปยังนักพัฒนา เพื่อให้นักพัฒนาสามารถใช้งานได้อย่างอิสระโดยไม่กระทบต่อความเสถียรของโปรโตคอลหลัก วิธีการแบบโมดูลาร์ในการห่อหุ้มและ ขยายฟังก์ชั่นที่ต้องการ

Ethereum พยายามปรับปรุงประสิทธิภาพของ การห่อหุ้ม และ Arbitrum Stylus กำลังปลดปล่อยสัญญาที่คอมไพล์ไว้ล่วงหน้า เมื่อมองไกลออกไป เชนสาธารณะยังสามารถปลดปล่อยความคิดสร้างสรรค์ของเลเยอร์แอปพลิเคชันได้อย่างสมบูรณ์ผ่านกระบวนทัศน์ Native Extension เช่นเดียวกับที่ Uniswap V4 นำมา ถึงทุกคน รู้สึกอย่างนั้น

เชนสาธารณะ L1 ใหม่อิงตามกระบวนทัศน์ Native Extension: Artela

มาเปลี่ยนมุมมองกันที่นี่ “เรา” หมายถึงทีมที่ฉันทำงานด้วยในฐานะ CTO: Artela ให้เราแบ่งปันความคิดและการดำเนินการของเราในประเด็นนี้

บนบล็อกเชน Artela นอกเหนือจาก EVM แล้ว เรายังติดตั้งสภาพแวดล้อมการดำเนินการ WASM ด้วย ในด้านหนึ่ง มันสามารถรันโปรแกรม stateful ได้ คล้ายกับสัญญาที่คอมไพล์ stateful ในทางกลับกัน รองรับกลไกคล้าย Hook ทำให้สามารถทริกเกอร์ที่โหนดวงจรชีวิตหลายโหนดของการประมวลผลบล็อกและธุรกรรม กล่าวอีกนัยหนึ่ง มันไม่ได้ใช้เพื่อห่อหุ้มสัญญาที่คอมไพล์ไว้ล่วงหน้าเช่น Arbitrum Stylus เท่านั้น แต่ยังสามารถปรับแต่งขั้นตอนการดำเนินการของธุรกรรมและบล็อกเพื่อให้เกิดการห่อหุ้มการทำงานที่กว้างขึ้น ตัวอย่างเช่น Native Extension ของ WASM จะถูกทริกเกอร์ในระหว่างขั้นตอนการตรวจสอบธุรกรรม และใช้อัลกอริธึมใหม่เพื่อระบุและตรวจสอบธุรกรรม Hooks เหล่านี้เรียกว่า Join Points ใน Artela และ Native Extensions เหล่านี้ไม่ได้เรียกว่า Smart Contracts แต่เป็น Aspects คล้ายกับแนวคิดของ AoP (Aspect-Orient Programming) ในระบบ blockchain ที่ทำงานอยู่ จะมีการเพิ่มคุณสมบัติใหม่แบบไดนามิก เพื่อเข้าร่วม Point!

เราได้สื่อสารกับนักลงทุนและสถาบัน Web2 เพื่อค้นหาว่าอะไรคืออุปสรรคที่ใหญ่ที่สุดในการนำเข้าสินทรัพย์ขนาดใหญ่เข้าสู่ Web3 ปัญหาที่ถูกกล่าวถึงมากที่สุดคือความปลอดภัย! แม้ว่าเทคโนโลยีการควบคุมความเสี่ยงระดับ Web2 จะรับประกันความปลอดภัยของสินทรัพย์นับพันล้านรายการ แต่ก็เป็นเรื่องยากที่จะเข้าสู่กลุ่มเทคโนโลยี Web3 คาร์ล ซึ่งมาจากสาขาการบินและอวกาศของ NASA ยังได้แสดงความคิดเห็นแบบเดียวกัน: เหตุใดเราจึงต้องมี Runtime Proctection และ Aspect

Runtime Protection เป็นวิธีการหลักในการควบคุมความเสี่ยงด้านความปลอดภัย ใน Web3 ในปัจจุบัน เราจะเห็นได้ว่ากลุ่มบริษัทรักษาความปลอดภัยที่แข็งแกร่งมากมีทั้งการตรวจสอบแบบคงที่และการตรวจสอบอย่างเป็นทางการ การตรวจสอบแบบเรียลไทม์ และการทำธุรกรรมแบบ front-running นี่ดูเหมือนจะเป็นวิธีการทั้งหมด แต่ก็ยังห่างไกลจากการควบคุมความเสี่ยงแบบเรียลไทม์ระดับ Web2 ปัญหาหลักคือมีวิธีรักษาความปลอดภัยมากมายรอบๆ mempool เพราะเมื่อธุรกรรมข้าม Mempool ก็ทำอะไรไม่ได้ ในขั้นตอนการดำเนินการธุรกรรมหลังจาก Mempool หากมีความสามารถในการขยายและผู้เชี่ยวชาญด้านความปลอดภัยสามารถนำนโยบายความปลอดภัยระดับรันไทม์ไปใช้ ระดับความปลอดภัยจะถูกยกระดับขึ้นไปที่ระดับที่สูงขึ้น Aspect ช่วยให้นักพัฒนามีความสามารถในการขยายการรักษาความปลอดภัยที่เจาะลึกเข้าไปในเลเยอร์การดำเนินการ!

นักพัฒนาสามารถปรับใช้แง่มุมที่ให้บริการเฉพาะโปรเจ็กต์ของตนเองเพื่อปรับแต่งฟังก์ชันเลเยอร์โปรโตคอลที่ต้องการ ตัวอย่างเช่น เพื่อเพิ่มความปลอดภัยรันไทม์ หากธุรกรรมที่อาจนำไปสู่การขโมยเงินจำนวนมาก ธุรกรรมนั้นจะถูกบล็อกใน Aspect

นักพัฒนายังสามารถปรับใช้แง่มุมสาธารณะเพื่อสรุปฟังก์ชันพื้นฐานที่สามารถนำมาใช้ซ้ำได้ในหลายๆ โปรเจ็กต์ ตัวอย่างเช่น Aspect ใช้อัลกอริธึมและประเภทธุรกรรมเฉพาะ ทำให้กระเป๋าเงิน AA สามารถตั้งโปรแกรมและรวมกันได้มากขึ้น นักพัฒนารายอื่นยังสามารถเปิดใช้งาน Aspect นี้และใช้คุณสมบัติพื้นฐานนี้สำหรับโปรเจ็กต์ของตนเองได้

สำหรับอาร์เทลา ความคิดของเรามีความมุ่งมั่นมากขึ้นเรื่อยๆ ระหว่างทาง:

· อนุญาตให้นักพัฒนาแก้ไขปัญหาโดยไม่ได้รับอนุญาตผ่าน Native Extension ในสถานะแอปพลิเคชัน แทนที่จะรอให้ทีมเครือข่ายสาธารณะที่เกี่ยวข้องทำการสรุป

· ให้สถาบันขนาดใหญ่ที่มีพื้นหลัง Web2 กล้าที่จะให้คำมั่นสัญญาเงินจำนวนมากในบล็อกเชน (ปรับปรุงโดยการแนะนำการควบคุมความเสี่ยงรันไทม์ระดับ Web2)

· ช่วยให้นักพัฒนามีสภาพแวดล้อมทางนิเวศน์ที่ดีในการทำสิ่งที่แหวกแนว (EVM อาจไปถึงจุดสูงสุดในไม่ช้า และ EVM+Native Extension อาจมีศักยภาพมากกว่า)

· ให้เกม full-chain, RWA และ dApps อื่น ๆ ที่ต้องการย้ายตรรกะทางธุรกิจมากขึ้นไปยัง chain มีบ้านในอุดมคติ

เราจะเห็นได้ว่า Ethereum อยู่ในขั้นตอนของวิธีการ ห่อหุ้ม คุณสมบัติของแอปพลิเคชัน และไม่มีแผนที่จะคลายความกดดันในการ ห่อหุ้ม และปล่อยให้ความคิดสร้างสรรค์กลับคืนสู่มือของนักพัฒนาอีกครั้ง สำหรับกลุ่มนักสร้างสรรค์นวัตกรรมรุ่นต่อไปที่มีศักยภาพซึ่งกล้าหาญพอที่จะสำรวจนวัตกรรมที่ก้าวล้ำในแอปพลิเคชันแบบกระจายอำนาจ สถานการณ์นี้มีข้อจำกัดมาก ในด้านหนึ่ง พวกเขาต้องการเครือข่ายแบบกระจายอำนาจที่แข็งแกร่ง แต่ในทางกลับกัน พวกเขาไม่สามารถใช้ มือและเท้า นี่คือเหตุผลหลักว่าทำไมเราจึงมุ่งมั่นที่จะสร้างเครือข่ายสาธารณะ L1 ใหม่ตามกระบวนทัศน์ Native Extension เพื่อให้โครงสร้างพื้นฐานไม่ต้านทานการเปลี่ยนแปลงของนวัตกรรม

Import Web2

สุดท้ายนี้ ปิดท้ายบทความนี้ด้วยสองคำนี้ แม้ว่าในระดับการเขียนโค้ด Web3 stack แบบกระจายอำนาจและ Web2 stack เป็นสองแนวคิดที่แตกต่างกันโดยสิ้นเชิง แต่ก็ไม่ได้ขัดขวางเราจากการมองหาสมบัติในไลบรารี Web2 ในแง่ของปรัชญาการออกแบบและประวัติการพัฒนา สร้างต่อไป!