ผู้เขียนต้นฉบับ: Yiping, IOSG Ventures

ภูมิทัศน์ของเลเยอร์ 2 มีการพัฒนาอย่างรวดเร็วเมื่อ ZKRU เช่น zkSync และ StarkNet เปิดตัว mainnet ตามเนื้อผ้า OPRU เช่น Arbitrum จะเป็นเจ้าแรกออกสู่ตลาด ดังนั้นจึงมีระบบนิเวศที่แข็งแกร่งกว่า ในทางตรงกันข้าม ZKRU เป็นความก้าวหน้าทางเทคโนโลยีที่ให้ปริมาณงานที่สูงขึ้นและค่าธรรมเนียมที่ต่ำกว่า

ในช่วงไม่กี่เดือนที่ผ่านมา มีการย้ายกิจกรรมจากเลเยอร์ 1 ไปยังเลเยอร์ 2 มากขึ้นเพื่อค้นหาธุรกรรมที่รวดเร็วและถูกกว่า TVL ของ Ethereum ลดลงจากเกือบ 40 พันล้านดอลลาร์เป็น 20 พันล้านดอลลาร์ในปีที่ผ่านมา อย่างไรก็ตาม เลเยอร์ 2 TVL นำเสนอภาพที่แตกต่างออกไป โดยมีการเติบโตอย่างมากบ่งชี้ว่าการนำเลเยอร์ 2 มาใช้กำลังเร่งตัวขึ้น

Arbitrum เป็นผู้นำด้วยส่วนแบ่งการตลาด Layer 2 TVL มากกว่า 50% แม้ว่า ZKRU จะพยายามอย่างเต็มที่ก็ตาม ความได้เปรียบในการเป็นผู้เสนอญัตติรายแรกของอนุญาโตตุลาการช่วยให้สามารถรักษาตำแหน่งที่โดดเด่นไว้ได้

การวิเคราะห์จำนวนธุรกรรมรายวันแสดงให้เห็นว่า ZKRU เช่น zkSync และ StarkNet มีปริมาณงานมากกว่า OPRU เล็กน้อย อย่างไรก็ตาม ความได้เปรียบด้านระบบนิเวศของ Arbitrum ยังคงอยู่ แม้ว่า TPS รายวันจะตามหลังเล็กน้อยก็ตาม

OPRU มีอายุการใช้งานยาวนานกว่า ZKRU อย่างไรก็ตาม ZKRU กำลังเปิดตัว mainnet และดึงดูดผู้ใช้จากระบบนิเวศอื่น ๆ ในฐานะผู้นำในพื้นที่ OPRU นั้น Arbitrum คาดว่าจะตอบโต้การเพิ่มขึ้นของ ZKRU ด้วยการอัปเดตใหม่

Arbitrum：Stylus

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

กล่าวโดยสรุปก็คือ Stylus คือสภาพแวดล้อมสัญญาอัจฉริยะใหม่ที่ปฏิวัติวงการซึ่งออกแบบมาสำหรับ Arbitrum ซึ่งช่วยให้นักพัฒนาสามารถเขียนโปรแกรมที่มีประสิทธิภาพและทำงานร่วมกันได้ในภาษาการเขียนโปรแกรม เช่น Rust, C++ และ Solidity

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

WASM

Stylus ทำงานโดยการเพิ่มเครื่องเสมือน WebAssembly (WASM) ที่ทำงานขนานกับ Ethereum Virtual Machine (EVM) ที่มีอยู่ สัญญาอัจฉริยะที่เขียนด้วยภาษาที่คอมไพล์เป็น WASM สามารถดำเนินการได้เร็วกว่า Solidity ถึง 10 เท่าหรือเร็วกว่า Solidity ซึ่งช่วยลดต้นทุนค่าก๊าซได้อย่างมาก EVM ยังคงทำงานได้อย่างสมบูรณ์ ดังนั้นสัญญา Solidity ที่มีอยู่จึงยังคงทำงานต่อไปได้ดังเช่นในปัจจุบัน VM ทั้งสองทำงานพร้อมกัน ช่วยให้สัญญาที่เขียนด้วยภาษาโปรแกรมที่แตกต่างกันสามารถเรียกหากันได้ ในขณะเดียวกันก็แก้ไขสถานะบล็อกเชนพื้นฐานเดียวกันด้วย

การรวบรวมล่วงหน้าแบบกำหนดเอง

นอกจากนี้ Stylus ยังรองรับพรีคอมไพล์แบบกำหนดเองอีกด้วย

การคอมไพล์ล่วงหน้าเป็นโมดูลระดับต่ำบน Ethereum และ Arbitrum ที่ใช้ในการทำหน้าที่เข้ารหัสลับหรือยูทิลิตี้เฉพาะอย่างมีประสิทธิภาพมาก ตัวอย่างเช่น มีการคอมไพล์ล่วงหน้าสำหรับการตรวจสอบลายเซ็น ECDSA และการคำนวณแฮช SHA 256

การเพิ่มการคอมไพล์ล่วงหน้าใหม่ต้องการให้ผู้ตรวจสอบความถูกต้องทั้งหมดประสานงานการอัพเกรด EVM ดังนั้นเกณฑ์จึงสูง ด้วย Stylus นักพัฒนาสามารถใช้งานพรีคอมไพเลอร์ของตนเองที่เขียนด้วยภาษา Rust หรือ C++ ได้อย่างง่ายดาย

ตัวอย่างเช่น ทีมงานสามารถนำไลบรารีการเข้ารหัสที่เขียนด้วยภาษา C มาปรับใช้กับ Arbitrum ได้โดยไม่ต้องดัดแปลง สิ่งนี้จะช่วยให้การเข้ารหัสลับแบบดั้งเดิมเหล่านี้ดำเนินการด้วยความเร็วดั้งเดิมที่เร็วเป็นพิเศษ

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

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

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

สไตลัสทำงานอย่างไร

ก่อนที่จะเจาะลึกบทบาทที่กว้างขึ้นของ WASM ในจักรวาลบล็อกเชน จำเป็นอย่างยิ่งที่จะต้องทำความเข้าใจว่า Arbitrum ควบคุมการอยู่ร่วมกันของ EVM และ WASM อย่างไร ไม่ใช่แค่การมีเครื่องยนต์สองเครื่องแยกกันเท่านั้น แต่ยังเป็นความสัมพันธ์ที่ทำงานร่วมกันซึ่งช่วยเพิ่มจุดแข็งของทั้งสองเครื่องยนต์อีกด้วย

สถาปัตยกรรมอันเป็นเอกลักษณ์ของ Arbitrum ช่วยให้การทำงานระหว่าง EVM และ WASM ราบรื่นและประสานกัน ต้องขอบคุณสถานะที่เป็นหนึ่งเดียว การเรียกใช้งาน cross-VM และโมเดลทางเศรษฐกิจที่เข้ากันได้

Smart Contract ที่เขียนด้วย Solidity หรือภาษา EVM อื่นๆ จะถูกรวบรวมเป็น EVM bytecode ตามปกติ เมื่อดำเนินการแล้ว สัญญาเหล่านี้จะทำงานบน EVM เช่นเดียวกับที่ทำในปัจจุบัน

สำหรับภาษาที่คอมไพล์เป็น WASM เช่น Rust, C++ และ C ขั้นตอนการทำงานคือ:

• นักพัฒนาใช้คอมไพเลอร์ WASM ที่มีจำหน่ายทั่วไป เช่น Clang หรือ Rustc เพื่อรวบรวมสัญญาอัจฉริยะลงใน WASM

• รหัสไบต์ WASM ถูกอัปโหลดไปยัง Arbitrum chain ในรูปแบบบีบอัด

• เจ้าของสัญญาเรียกเมธอด `compileProgram` ที่คอมไพล์ไว้แล้วของ ArbWasm ซึ่งตั้งค่าเครื่องมือรักษาความปลอดภัยสำหรับ WASM เสียค่าใช้จ่าย และคอมไพล์เป็นโค้ดเนทิฟที่ปรับให้เหมาะสมสำหรับฮาร์ดแวร์ตรวจสอบความถูกต้อง

• เมื่อมีการเรียกสัญญา สัญญาจะทำงานบนรันไทม์ WASM เช่น Wasmer ซึ่งเร็วกว่า EVM มาก จึงช่วยประหยัดค่าน้ำมัน

การวัดค่า WASM จะเรียกเก็บเงินจากแก๊สก่อนแต่ละบล็อกพื้นฐาน แทนที่จะเรียกเก็บต่อ opcode เช่น EVM สิ่งนี้มีประสิทธิภาพมากกว่าและรับประกันว่าสัญญาจะไม่หลุดมือ

EVM และ WASM

เครื่องเสมือน (VM) ทั้งสองเครื่องทำงานพร้อมกัน ทำให้สามารถโทรหากันในขณะที่แชร์สถานะส่วนกลางเดียวกันได้ ธุรกรรมอาจถูกดำเนินการบางส่วนใน EVM และบางส่วนใน WASM และผลลัพธ์จะถูกรวมเข้าด้วยกันอย่างราบรื่น

เดี๋ยวก่อน VM สองตัวจะทำงานได้อย่างราบรื่นและซิงค์กันได้อย่างไร

Polkadot บรรลุเป้าหมายนี้ผ่าน XVM WASM และ EVM ต่างจาก Polkadot ที่ทำงานได้อย่างราบรื่นและพร้อมกันบน Arbitrum ด้วยเหตุผลสำคัญหลายประการ:

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

• การเรียกข้าม VM: เมื่อธุรกรรมโต้ตอบกับสัญญา EVM Geth จะประมวลผลและแจ้งผลลัพธ์ หากสัญญา EVM เรียกโปรแกรม WASM ในเวลาต่อมา WASM VM จะเข้ามาคำนวณผลลัพธ์ของส่วนนั้น

• บริบทที่ใช้ร่วมกัน: ข้อมูลระบบ เช่น ข้อมูลบล็อก ที่อยู่ผู้ส่ง ฯลฯ พร้อมใช้งานสำหรับ VM ทั้งสอง สัญญา WASM สามารถรับหมายเลขบล็อกได้เช่นเดียวกับสัญญา Solidity

• ฉันทามติเดียว: เครื่องมือตรวจสอบรัน VM สองเครื่องเพื่อตรวจสอบธุรกรรมและบรรลุฉันทามติเกี่ยวกับสถานะลูกโซ่ที่ถูกต้อง ข้อพิพาทจะเรียกใช้ระบบป้องกันการฉ้อโกงแบบเดียวกัน

• เศรษฐศาสตร์ที่เข้ากันได้: แนวคิดต่างๆ เช่น การวัดก๊าซขยายไปยัง VM แต่ละเครื่อง ทำให้มั่นใจได้ถึงต้นทุนการประมวลผลและทรัพยากรที่เหมาะสมในสภาพแวดล้อมทั้งสอง

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

บล็อคเชน - WASM

Arbitrum ไม่ใช่แพลตฟอร์มเดียวที่รับรู้ถึงศักยภาพในการเปลี่ยนแปลงของ WebAssembly (WASM) ทั้ง Polkadot และ Cosmos ยังได้รวม WASM เข้ากับระบบนิเวศของตน โดยแต่ละแพลตฟอร์มนำเสนอชุดคุณประโยชน์และฟีเจอร์เฉพาะตัว

Polkadot อนุญาตให้ผู้ใช้พัฒนาสัญญาอัจฉริยะโดยใช้ WASM และรองรับสองภาษา: AssemblyScript, DSL แบบฝัง และ Ink! ซึ่งคล้ายกับ Rust

ในทางกลับกัน Cosmos ใช้ CosmWasm เป็นรันไทม์สัญญาอัจฉริยะ ช่วยให้นักพัฒนาสามารถเขียนสัญญาใน Rust ได้

ก่อนที่จะเจาะลึกว่าทำไมอุตสาหกรรมบล็อกเชนจึงยอมรับ WASM จำเป็นต้องเข้าใจข้อดีเฉพาะที่ Cosmos และ Polkadot โดดเด่น:

Cosmos เน้นย้ำข้อดีของ WASM ดังต่อไปนี้:

• ความเข้ากันได้กับไลบรารี Rust

• ชุมชนนักพัฒนาที่หลากหลาย

• การรักษาความปลอดภัยที่ได้รับการปรับปรุง รวมถึงการป้องกันการโจมตีซ้ำ

• ง่ายต่อการทดสอบ

• ประสิทธิภาพสูง

รันไทม์ WASM ของ Polkadot มีคุณสมบัติเหล่านี้:

• ประสิทธิภาพสูง

• การทำงานร่วมกันกับ EVM

• ผู้ไม่เชื่อเรื่องพระเจ้าแพลตฟอร์ม

• ขนาดไบนารีขนาดกะทัดรัด

• รองรับทั้ง Rust และ AssemblyScript (สไตล์ TypeScript)

ในขณะที่ Polkadot, Cosmos และ Arbitrum มีข้อดีร่วมกันบางประการที่ WASM มอบให้ แต่แต่ละแพลตฟอร์มก็มีคุณสมบัติเฉพาะของตัวเองเช่นกัน

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

เหตุใดจึงเลือก WASM

WASM คืออะไร

เพื่อทำความเข้าใจการทำงานร่วมกันระหว่างบล็อคเชนและ WebAssembly (WASM) เราต้องเข้าใจก่อนว่า WASM คืออะไรและแรงผลักดันเบื้องหลังการพัฒนา

WebAssembly เป็นรูปแบบคำสั่งไบนารีที่ช่วยให้โค้ดดำเนินการด้วยความเร็วที่ใกล้เคียงกันภายในเว็บเบราว์เซอร์ โดยทำหน้าที่เป็นเป้าหมายในการคอมไพล์สำหรับภาษาการเขียนโปรแกรมต่างๆ รวมถึง C และ Rust และได้รับการออกแบบมาให้รวดเร็ว มีประสิทธิภาพ และปลอดภัย WASM เชื่อมช่องว่างระหว่างการเขียนโปรแกรมบนเว็บและระดับระบบได้อย่างมีประสิทธิภาพ ดังนั้นจึงปรับปรุงประสิทธิภาพและการทำงานของเว็บ

เว็บ ใน WebAssembly เน้นความสามารถในการทำงานในสภาพแวดล้อม JavaScript (มักพบในเบราว์เซอร์) ในการตั้งค่าเหล่านี้ นักพัฒนาสามารถเข้าถึง WASM API ได้อย่างเต็มที่ และรองรับ Web API ที่ครอบคลุม ทำให้พวกเขาสามารถควบคุมพฤติกรรมของเว็บได้อย่างมาก

ประวัติศาสตร์ WASM

ตามหลักการ เขียนเพียงครั้งเดียว ทำงานได้ทุกที่ WASM กลายเป็นโซลูชันที่ทรงพลังสำหรับความท้าทายที่มีมายาวนาน ในปี 2016 หลายโปรแกรมแนะนำฟังก์ชันการทำงานใหม่ผ่านภาษาเฉพาะโดเมน (DSL) ซึ่งมักจะเกี่ยวข้องกับการแลกเปลี่ยนระหว่างการบำรุงรักษา ประสิทธิภาพ และความปลอดภัย มีความต้องการโซลูชันที่สามารถมอบฟังก์ชันการทำงานใหม่ให้กับเซิร์ฟเวอร์จำนวนนับไม่ถ้วนโดยไม่กระทบต่อประเด็นเหล่านี้เพิ่มมากขึ้น

มีการประเมินข้อบกพร่องของโซลูชันต่างๆ ที่มีอยู่:

- ระบบเครื่องเสมือน

• การเริ่มต้นและปิดเครื่องบ่อยครั้งทำให้เกิดค่าใช้จ่ายมากเกินไป

• ขาดการมองเห็นโค้ดเพื่อความปลอดภัย

• เป็นนามธรรมเกินไปเกี่ยวกับข้อกำหนดด้านประสิทธิภาพ

- คอนเทนเนอร์

• ขาดการมองเห็นโค้ดเพื่อความปลอดภัย

• ไม่มีประสิทธิภาพเนื่องจากมีนามธรรมในระดับสูง

• การดำเนินงานบ่อยครั้งทำให้เกิดค่าใช้จ่ายจำนวนมาก

- เครื่องเสมือนระดับภาษา

• ต้องมีการปรับเปลี่ยนบ่อยครั้งเพื่อความปลอดภัย

• VM แบบฝัง เช่น V8 ต้องใช้ทรัพยากรมาก

• การปรับภาษาใหม่ให้เข้ากับโมเดลการรักษาความปลอดภัยอย่างช้าๆ

• ยังคงเป็นนามธรรมเกินไป

- สถาปัตยกรรมชุดคำสั่ง (ISA)

• ยากต่อแซนด์บ็อกซ์อย่างมีประสิทธิภาพ

• โครงการ Google ก่อนหน้านี้ได้ย้ายจากโครงการนี้ไปยัง WASM

• ขาดการนำไปปฏิบัติที่สมบูรณ์

ภายในปี 2018 การพัฒนา WASM ได้รับแรงผลักดันโดยมุ่งเน้นไปที่การทำงานบนสถาปัตยกรรม เซิร์ฟเวอร์ ฮาร์ดแวร์แบบฝังตัวที่หลากหลาย และแม้แต่การรองรับหลายภาษา WASM ต่างจาก Java ตรงที่ได้รับการออกแบบโดยไม่กระทบต่อความปลอดภัย ภายในปี 2019 มีการเปิดตัวโมเดลส่วนประกอบเพื่อปรับปรุงโมดูล WASM และเปิดใช้งานการทำงานร่วมกันข้ามภาษา ซึ่งช่วยให้สามารถแก้ไขปัญหาต่างๆ เช่น การเขียนไลบรารี HTTP เพียงครั้งเดียวและใช้ในหลายภาษา

จนถึงปัจจุบัน WASM มีความสามารถที่หลากหลายและมีการนำไปใช้มากขึ้นในสถานการณ์แบบคลาวด์เนทีฟ รวมถึงบล็อกเชน ข้อดีของมัน ได้แก่ :

• ประสิทธิภาพสูง

• ขนาดไบนารีขนาดกะทัดรัด

• พกพาข้ามแพลตฟอร์ม

• รองรับหลายภาษา เช่น C/C++, Rust, AssemblyScript เป็นต้น

• ดำเนินการในเอ็นจิ้น JavaScript

• แซนด์บ็อกซ์อันทรงพลังพร้อมขีดจำกัดหน่วยความจำและ CPU

• เวลาเริ่มต้นที่รวดเร็วมาก โดยทั่วไปจะอยู่ในหน่วยมิลลิวินาทีหรือน้อยกว่า

ชุมชน WASM ยังคงทำงานอย่างต่อเนื่องเพื่อการบูรณาการและประสิทธิภาพในภาษาต่างๆ ที่ดียิ่งขึ้น

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

Stylus Q&A

การสนับสนุนภาษา

วิวัฒนาการของ WASM เผยว่าเหตุใด Stylus จึงเป็นส่วนเสริมที่น่าตื่นเต้นในระบบนิเวศของ Arbitrum แต่ยังเน้นย้ำถึงข้อจำกัดและข้อกังวลบางประการด้วย ข้อกังวลประการหนึ่งคือการรองรับภาษา แม้ว่า Stylus ได้ขยายชุมชนนักพัฒนา Arbitrum ให้รวมภาษาอย่าง C++ และ Rust ไว้อย่างแน่นอน แต่ก็ยังขาดการรองรับภาษายอดนิยมอย่าง JavaScript และ Python

แม้ว่าจะมีโครงการเบื้องต้นที่มุ่งนำ Python และ JavaScript มาสู่ WASM แต่ความพยายามเหล่านี้ยังไม่พร้อมสำหรับการนำไปใช้ในวงกว้างเนื่องจากความท้าทายในการรวบรวมขยะและปัญหาด้านประสิทธิภาพ

ความเข้ากันได้ของภาษา

ปัจจุบัน Stylus รองรับ C/C++ และ Rust SDK ซึ่งผสานรวมกับกลุ่มเครื่องมือของภาษาเหล่านี้ได้อย่างราบรื่น นักพัฒนายังสามารถรวมไลบรารีของบุคคลที่สาม เช่น การใช้งานการเข้ารหัสแบบเนทีฟ เมื่อสร้างสัญญาอัจฉริยะ ข้อจำกัดหลักในการทำสิ่งนี้คือต้นทุนน้ำมันที่เกี่ยวข้อง

แม้ว่า Rust SDK ยังอยู่ในช่วงเริ่มต้น แต่ทั้ง Rust และ C SDK ก็มีคุณสมบัติที่ขาดหายไปบางประการ ตัวอย่างเช่น C SDK ไม่รองรับฟังก์ชันที่ส่งออกโดย ABI และ SDK ตัวใดตัวหนึ่งยังไม่รองรับตัวแก้ไข

ปัจจุบันไม่มีสภาพแวดล้อมการทดสอบสไตลัสในเครื่อง แต่นักพัฒนาสามารถทำการทดสอบได้โดยตรงภายใน SDK สำหรับการปรับใช้สัญญาอัจฉริยะ ขณะนี้เทสเน็ตเป็นเพียงตัวเลือกเดียว และยังไม่รองรับการตรวจสอบสัญญาอัจฉริยะ ขณะนี้เรากำลังดำเนินการเพื่อนำโทเค็น ERC ต่างๆ และ **[Uniswap V2](https://twitter.com/evmcheb/status/1697537852522049990)** เข้าสู่ระบบนิเวศของ Stylus

ภาวะที่กลืนไม่เข้าคายไม่ออกของการเลือกภาษา

การเลือกระหว่างภาษาเฉพาะโดเมน (DSL), DSL แบบฝัง (eDSL) และภาษาสำหรับวัตถุประสงค์ทั่วไป จำเป็นต้องมีการแลกเปลี่ยนระหว่างการควบคุมระดับต่ำและนามธรรมระดับสูง การพัฒนา DSL ใหม่จำเป็นต้องมีการลงทุนจำนวนมากในห่วงโซ่เครื่องมือและการพัฒนาระบบนิเวศ ในทางตรงกันข้าม eDSL เป็นส่วนหนึ่งของภาษาสำหรับใช้งานทั่วไป ช่วยให้สามารถผสานรวมกับเครื่องมือที่มีอยู่ได้ง่ายขึ้นและมีช่วงการเรียนรู้ที่ต่ำกว่า ตัวอย่างเช่น การสร้าง eDSL ในภาษายอดนิยมอย่าง JavaScript หรือ Python จะเป็นประโยชน์

ภาษาทั่วไปจำเป็นต้องใช้ SDK ซึ่งแนะนำเครื่องมือเพิ่มเติม เพิ่มคำฟุ่มเฟือย และทำให้โค้ดแสดงออกน้อยลง พร้อมกับการเรียก API และการดำเนินการกับวัตถุที่นานขึ้น

การค้นหาสมดุลที่เหมาะสมระหว่างการเลือกภาษาและการพัฒนา eDSL อาจเป็นกุญแจสำคัญในการดึงดูดชุมชนนักพัฒนาในวงกว้าง ในขณะเดียวกันก็มอบเครื่องมือที่ใช้งานง่าย ตามข้อมูลปัจจุบัน ชุมชนนักพัฒนา crypto ชั้นนำยังคงกระจุกตัวอยู่ที่ Ethereum อย่างไรก็ตาม แพลตฟอร์มที่ใช้ประโยชน์จาก Rust สำหรับสัญญาอัจฉริยะ เช่น Polkadot, Cosmos และ Solana ก็ได้รับความสนใจและเติบโตอย่างรวดเร็วในหมู่ชุมชนนักพัฒนาของพวกเขา

ผลงาน

WASM ปรับปรุงความเร็วการดำเนินการอย่างมากและลดขนาดแพ็กเก็ต แม้ว่าสไตลัสจะยังไม่ได้ใช้งานบนเมนเน็ต แต่การวัดประสิทธิภาพจากเครือข่ายอื่นสามารถใช้เป็นข้อมูลอ้างอิงที่เป็นประโยชน์ได้ เวลาดำเนินการที่สังเกตได้จะเร็วขึ้น 4-8 เท่า และขนาดที่คอมไพล์ลดลงประมาณ 50%

ปัจจุบันสไตลัสมีขนาดจำกัดในสัญญา โดยมีขีดจำกัดบนประมาณ 128 KB ที่ไม่มีการบีบอัด ข้อจำกัดนี้ทำให้การย้ายสัญญาอัจฉริยะขนาดใหญ่จากภาษาอื่น เช่น Solidity เป็นเรื่องที่ท้าทาย ในโค้ดฐานสไตลัส ขีดจำกัดนี้อธิบายไว้ด้านล่าง:

เป็นที่น่าสังเกตว่า WASM มีค่าใช้จ่ายบางส่วนเมื่อเริ่มต้นและปิดเครื่อง สำหรับการดำเนินการแบบน้ำหนักเบา EVM อาจคุ้มค่ากว่า WASM จริงๆ

การทำงานร่วมกันกับ EVM

EVM และ WASM ใช้ช่องจัดเก็บข้อมูลและแผนผังสถานะเดียวกัน ซึ่งช่วยให้สไตลัสทำงานร่วมกับ EVM ได้ง่ายขึ้น ซึ่งสามารถทำได้ผ่าน EVM API ที่ใช้งานใน WASM โดยใช้รูปแบบ Host I/O ยอดนิยม รายการ EVM API ที่รองรับทั้งหมดแสดงให้เห็นว่ารองรับการทำงานร่วมกันอย่างสมบูรณ์

สัญญาที่คอมไพล์ไว้ล่วงหน้าแบบกำหนดเอง

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

คุณลักษณะนี้อาจยังอยู่ระหว่างการพัฒนา โดยใช้ประโยชน์จากความสามารถของ WASM EVM สามารถเรียกใช้ฟังก์ชันที่เขียนด้วย WASM แล้วคอมไพล์เป็นรหัสเครื่องได้

ฟังก์ชั่นการกลับเข้ามาใหม่

ตรงกันข้ามกับ CosmWasm (ซึ่งใช้โมเดลนักแสดงที่ไม่มีการกลับคืนสู่สภาพเดิม) Rust SDK ของสไตลัสจะปิดการกลับเข้าใหม่เป็นการตั้งค่าสถานะฟีเจอร์ตามค่าเริ่มต้น นักพัฒนามีตัวเลือกในการเปิดใช้งานคุณสมบัตินี้ด้วยตนเอง

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

ข้อมูลเชิงลึก

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

การรวมสไตลัสเข้ากับ SDK Layer 2 ของ Arbitrum ช่วยให้นักพัฒนา Layer 3 มีความยืดหยุ่นมากขึ้น ตอนนี้พวกเขาสามารถย้ายการคำนวณที่เข้มข้นซึ่งก่อนหน้านี้เกินขีดจำกัดของก๊าซไปยังห่วงโซ่ได้ ซึ่งเปิดโอกาสใหม่ ๆ นักพัฒนาไม่ได้จำกัดอยู่เพียง Solidity อีกต่อไป แต่ยังสามารถเลือก Rust หรือ C++ ได้ หากภาษาเหล่านั้นเหมาะสมกับความต้องการและความเชี่ยวชาญของพวกเขามากกว่า สัญญาที่คอมไพล์แบบกำหนดเองช่วยให้สามารถโยกย้ายฟังก์ชันการเข้ารหัสลับ ยูทิลิตี้ และตัวช่วยอื่น ๆ ที่ต้องการไปยังเชนได้อย่างราบรื่นเพื่อประสิทธิภาพสูงสุด การเขียนตรรกะระดับต่ำโดยตรงในภาษาที่ปรับให้เข้ากับกรณีการใช้งานแต่ละกรณีนำไปสู่การพัฒนาที่ราบรื่นยิ่งขึ้น นักพัฒนาซอฟต์แวร์สามารถมุ่งเน้นไปที่คุณลักษณะหลักของผลิตภัณฑ์ แทนที่จะดำเนินการแก้ไขอย่างรวดเร็วเพื่อหลีกเลี่ยงต้นทุนค่าน้ำมัน ด้วยการขจัดข้อจำกัดด้านภาษาและก๊าซ Stylus ช่วยให้ผู้สร้างระดับที่สามสามารถสร้างประสบการณ์ผู้ใช้ที่มีประสิทธิภาพสูงสุดตั้งแต่เริ่มต้น โดยใช้เครื่องมือที่เหมาะสมสำหรับโดเมนของตน

Stylus ยังแสดงให้เห็นถึงความสามารถของ Arbitrum ในการสร้างนวัตกรรมในวงกว้างและบูรณาการเครื่องเสมือนใหม่ Ed Felten ผู้ร่วมก่อตั้งและหัวหน้านักวิทยาศาสตร์ของ Arbitrum Offchain Labs กล่าวว่า Arbitrum ได้รับการพัฒนาโดยใช้เครื่องมือยอดนิยมและภาษาการเขียนโปรแกรมในอุตสาหกรรม พวกเขาสามารถเขียนการทดสอบได้รวดเร็วยิ่งขึ้นและพัฒนาคุณสมบัติใหม่นอกเหนือจากระบบเดิม OP ได้ก้าวไปอีกขั้นบนเส้นทางของ ZKization และค่อยๆ ก้าวไปสู่แนวคิด Rollup แบบไฮบริด ขณะนี้การมองโลกในแง่ดีกำลังทำงานร่วมกับ Risc 0 เพื่อใช้ Zeth เพื่อสร้างข้อพิสูจน์ที่ไม่มีความรู้สำหรับ OPRU การใช้โซลูชันนี้ การมองในแง่ดีไม่จำเป็นต้องทำการแก้ไขเพิ่มเติมกับ OPRU สนใจเซธอ่านที่ผมเขียนไว้ก่อนได้นะครับ [Twitter](https://x.com/glazecl/status/1709947992168710174? s= 20)

เราตั้งตารอที่จะได้เห็นแอปพลิเคชัน AI บน Arbitrum เป็นอย่างมาก ในปัจจุบัน การดำเนินการแมชชีนเลิร์นนิงบนเชนนั้นต้องใช้แก๊สมาก ส่งผลให้ต้นทุนการพัฒนาสูง Zero-knowledge ML สามารถลดต้นทุนได้ แต่ยังทำให้เกิดความซับซ้อนเพิ่มเติมที่สำคัญสำหรับนักพัฒนาอีกด้วย หากเราสามารถใช้การทำงานของเทนเซอร์เป็นสัญญาที่คอมไพล์ไว้ล่วงหน้าแบบกำหนดเองผ่าน Stylus และดำเนินการพวกมันแบบเนทีฟด้วยต้นทุนเพียงเล็กน้อย มันจะเปิดโอกาสใหม่สำหรับการเรียนรู้ของเครื่องบนเชนที่มีประสิทธิภาพสูง ด้วยการช่วยให้นักพัฒนาสามารถสร้างและปรับใช้อัลกอริธึม ML ได้อย่างรวดเร็ว ซึ่งเป็นสัญญาที่คอมไพล์แล้วในภาษาที่พวกเขาคุ้นเคย (เช่น Python) ที่ง่ายต่อการรวมเข้าด้วยกัน Arbitrum จึงสามารถขับเคลื่อนนวัตกรรม AI รุ่นต่อไปใน DeFi, GameFi และอื่นๆ อีกมากมาย ประสิทธิภาพและความยืดหยุ่นของสไตลัสจะช่วยให้เรามุ่งเน้นไปที่สถาปัตยกรรม ML ที่เป็นนวัตกรรมใหม่ แทนที่จะเพิ่มประสิทธิภาพของแก๊ส เราหวังว่าจะได้เห็นความคิดสร้างสรรค์ของชุมชนที่นำไปใช้กับกระบวนทัศน์ที่เกิดขึ้นใหม่นี้