ผู้เขียนต้นฉบับ: Yuki, PaperMoon

ตั้งแต่ Substrate เริ่มต้นจนถึง Polkadot SDK ในปัจจุบัน เป้าหมายของ Polkadot ไม่เคยมุ่งเน้นไปที่ประสิทธิภาพสูงสุดของเชนเดียว แต่เป็นการสร้างรากฐานสากลเพื่อรองรับเชนหลายเชนที่มีความหลากหลาย ช่วยให้ทุกคนสามารถสร้างบล็อคเชนของตัวเองได้เหมือนกับบล็อกอาคาร

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

ดังที่ Gavin Wood กล่าวไว้ Polkadot ไม่ใช่ "เชนใหม่ที่รองรับการใช้งานแบบ Volume Compatibility" แต่เป็นระบบสร้างเชนที่รองรับนวัตกรรมระบบนิเวศและอนาคตของเชนหลายเชน Polkadot SDK คือรูปแบบล่าสุดของเครื่องนี้ ซึ่งประกอบด้วยอินเทอร์เฟซแบบรวมศูนย์ สแต็กการพัฒนาที่ได้มาตรฐาน และกลไกการสร้างเชนแบบ Cross-VM

ประวัติและข้อจำกัดของสารตั้งต้น

Substrate เปิดตัวโดย Parity ในปี 2018 เป็นเฟรมเวิร์กการพัฒนาบล็อกเชนแบบโมดูลาร์ที่เขียนด้วยภาษา Rust ซึ่งเป็นรากฐานทางเทคนิคหลักสำหรับเมนเน็ตของ Polkadot และเชนอื่นๆ อีกมากมายในระบบนิเวศ นวัตกรรมที่โดดเด่นที่สุดของ Substrate คือการแยกอัลกอริทึมคอนเซนซัส ตรรกะรันไทม์ โมเดลบัญชี การกำกับดูแลสินทรัพย์ และสัญญาอัจฉริยะ ให้เป็นโมดูลพาเลทที่สามารถผสานรวมได้อย่างอิสระ ทุกทีมสามารถสร้างบล็อกเชนที่ปรับแต่งได้ตามความต้องการ ทำให้ Substrate ได้รับการยอมรับอย่างกว้างขวางว่าเป็นเฟรมเวิร์ก Layer-0 อย่างแท้จริงตัวแรกของอุตสาหกรรม

Polkadot Substrate เป็นผู้บุกเบิกแนวทางใหม่ในการพัฒนาบล็อกเชน โดยเปลี่ยนแนวคิดการสร้างเชนจากการออกแบบที่เป็นอิสระและปิด ไปสู่บล็อกเชนที่ปรับแต่งได้เหมือนเลโก้ นักพัฒนาสามารถสร้างโมดูลที่ใช้งานได้ เช่น การกำกับดูแล การสเตคกิ้ง สัญญา การระบุตัวตน และ DEX ได้อย่างอิสระผ่านระบบ FRAME บรรลุ "การพัฒนาแบบโมดูลาร์ระดับเชน" และสร้างเชนแอปพลิเคชันสำหรับ DeFi, NFT, DID และสถานการณ์อื่นๆ ได้อย่างรวดเร็ว

การออกแบบนี้ทำให้ระบบนิเวศ Polkadot ในระยะเริ่มแรกสามารถส่งเสริมนวัตกรรมในระดับห่วงโซ่ที่หลากหลายได้ในช่วงเวลาสั้นๆ

อย่างไรก็ตาม อิสระในการปรับแต่งในระดับสูงที่ระบบโมดูลาร์มอบให้ยังนำมาซึ่งภาระของการแยกส่วนในระดับระบบนิเวศอีกด้วย หลังจากวนซ้ำมาหลายปี โค้ดและฟังก์ชันการทำงานสำหรับการสร้างพาราเชนก็กระจัดกระจายไปตามคลังโค้ดหลายแห่ง เช่น Substrate, Cumulus และ Polkadot แต่ละโปรเจกต์ขึ้นอยู่กับเวอร์ชันที่แตกต่างกันและใช้สาขาที่แตกต่างกัน ส่งผลให้เกิดการขาดการเชื่อมต่ออย่างรุนแรงระหว่าง API และระบบเอกสารประกอบ

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

● อัพเกรดยาก: ทรั้งค์หลักกำลังดำเนินไปอย่างช้าๆ การอัปเดตโมดูลต้องใช้การซิงโครไนซ์ด้วยตนเอง และเชนจำนวนมากยังคงอยู่ในเวอร์ชันเก่าเป็นเวลานาน

● ความยากลำบากในการทำงานร่วมกัน: รันไทม์จากทีมต่างๆ ไม่สามารถนำกลับมาใช้ซ้ำได้โดยตรง และการพัฒนาแบบข้ามสายโซ่หรือแบบแชร์โมดูลต้องอาศัยการทำงานซ้ำๆ

● ยากต่อการเผยแพร่: เอกสารและเครื่องมือที่กระจัดกระจาย เส้นทางการเรียนรู้ที่สูงชัน ทำให้ผู้พัฒนาใหม่ประสบความยากลำบากในการเชี่ยวชาญการพัฒนาในระดับโซ่อย่างเป็นระบบ

ผลลัพธ์สุดท้ายคือ อิสระแบบโมดูลาร์ของ Substrate ก่อให้เกิดการแบ่งส่วนในระดับระบบนิเวศ ดังนั้น Parity จึงได้ก้าวสำคัญ นั่นคือการรวมและบูรณาการโมดูลหลัก อินเทอร์เฟซ และคลังข้อมูลทั้งหมดเข้าเป็น Polkadot SDK ที่สมบูรณ์และเป็นมาตรฐาน

การเกิดของ Polkadot SDK: การรีแฟกเตอร์กรอบงานรวม

หลังจากการทำงานร่วมกันแบบแยกส่วนเป็นเวลาหลายปี ในที่สุด Parity ก็ตัดสินใจดำเนินการรวมสถาปัตยกรรมทางประวัติศาสตร์ในปี 2023–2024

ทีมงานอย่างเป็นทางการได้ผสาน Substrate, Cumulus, Polkadot (เช่นเดียวกับ FRAME และที่เก็บข้อมูลที่เกี่ยวข้องกับโหนด) เข้าเป็นฐานโค้ดเดียว: Polkadot SDK

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

SDK ของ Polkadot ช่วยขจัดการซิงโครไนซ์และความขัดแย้งที่เกิดขึ้นบ่อยครั้งระหว่างที่เก็บข้อมูลหลายแห่งได้อย่างสมบูรณ์ผ่านการจัดการการอ้างอิงแบบรวม ข้อกำหนดการพัฒนามาตรฐาน และกลไกการอัปเดตโค้ดแบบซิงโครนัส

ในประกาศการควบรวมกิจการ Parity ระบุอย่างชัดเจนว่าขั้นตอนนี้มีเป้าหมายเพื่อเปลี่ยน Substrate จาก "กรอบงานวิศวกรรมที่ยืดหยุ่น" ให้กลายเป็นสแต็กโปรโตคอลมาตรฐานที่รองรับระบบนิเวศ Polkadot ทั้งหมด ไลบรารี Polkadot SDK ใหม่นี้ผสานรวมส่วนประกอบหลักทั้งหมดของ Polkadot ไว้ด้วยกัน

● Substrate: จัดเตรียมรันไทม์บล็อคเชน, ฉันทามติ และโมดูลหลัก

● FRAME: สร้างระบบโมดูลพาเลทเพื่อนำตรรกะรันไทม์แบบปลั๊กอินไปใช้งาน

● คิวมูลัส: ในฐานะเลเยอร์อะแดปเตอร์พาราเชน ช่วยให้เชนสามารถเชื่อมต่อกับเชนรีเลย์ได้โดยตรง

● Polkadot Node: กำหนดสแต็กโปรโตคอลโหนดหลักและตรรกะการสื่อสารเครือข่าย

โครงสร้างทางเทคนิคหลักของ Polkadot SDK

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

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

SDK Polkadot ที่ตามมาได้รับการยอมรับอย่างกว้างขวางจากนักพัฒนาและชุมชนระบบนิเวศ

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

ระบบเอกสาร โครงสร้าง API และเครื่องมือสร้างได้รับการรวมเป็นหนึ่งอย่างสมบูรณ์ ช่วยลดเส้นโค้งการเรียนรู้และปรับปรุงประสิทธิภาพการทำงานร่วมกันอย่างมาก

สำหรับ Parity การผสานรวมนี้ถือเป็นวิวัฒนาการทางสถาปัตยกรรมที่สำคัญนับตั้งแต่การก่อตั้ง Polkadot สำหรับระบบนิเวศโดยรวม Polkadot SDK ถือเป็นจุดเริ่มต้นที่แท้จริงของการเปลี่ยนแปลงจาก "การอยู่ร่วมกันแบบหลายเชน" ไปสู่ ​​"การทำงานร่วมกันแบบหลายเชน" Substrate มอบอิสระในการสร้างเชน ขณะที่ SDK มอบความเป็นระเบียบให้กับระบบนิเวศ

จาก SDK สู่ REVM: ผลลัพธ์ที่หลีกเลี่ยงไม่ได้ของการสร้าง EVM แบบเนทีฟ

EVM ดั้งเดิมได้รับการรองรับบน Polkadot อยู่แล้ว การเกิดขึ้นของ REVM ช่วยให้เชนที่ใช้ Polkadot SDK สามารถผสานรวมฟังก์ชันการทำงานทั้งหมดของ Ethereum ได้อย่างง่ายดาย ซึ่งหมายความว่า Polkadot ไม่ต้องพึ่งพาโซลูชันความเข้ากันได้ของ EVM จากภายนอกอีกต่อไป แต่ผสานรวมสภาพแวดล้อมการทำงานหลักของระบบนิเวศ Ethereum เข้ากับระบบของตัวเองโดยตรง

ในช่วงเริ่มต้นของระบบนิเวศ Polkadot ความเข้ากันได้ของ EVM ได้รับการจัดการอย่างอิสระโดยพาราเชนแต่ละอัน เชนอย่าง Moonbeam, Astar และ Acala ได้นำเฟรมเวิร์ก Frontier ของ Parity มาใช้ ซึ่งเป็นแนวทางแบบโมดูลาร์สำหรับการนำฟังก์ชัน EVM มาใช้ โมเดลนี้ทำให้พาราเชนมีความยืดหยุ่นสูง แต่ก็ทำให้เกิดการแบ่งส่วนทางวิศวกรรม ทำให้แต่ละเชนต้องดูแลรักษาโมดูล Frontier จัดการความเข้ากันได้ของ RPC ดีบักตรรกะของ EVM และแก้ไขปัญหาความเข้ากันได้อย่างอิสระ

ทีม Parity ได้ฝังเอนจิน EVM ในรูปแบบ REVM ลงใน SDK หลักโดยตรง โดยวางไว้เคียงข้าง FRAME, Cumulus และ XCM ในฐานะโมดูลหลัก EVM สามารถทำงานร่วมกับส่วนเสริมจากพาราเชนต่างๆ และถูกรวมเข้ากับแกนหลักของระบบอย่างเป็นทางการ จนกลายเป็นความสามารถมาตรฐานของ Polkadot

REVM ถูกเขียนขึ้นใหม่ใน Rust โดย Parity และเข้ากันได้กับสถาปัตยกรรม Polkadot SDK อยู่แล้ว การสร้าง REVM นี้ไม่ใช่การเพิ่มเลเยอร์ความเข้ากันได้ แต่เป็นการผสานรวมระดับระบบ

คุณสมบัติหลัก ได้แก่:

● การใช้งาน Rust: ประสิทธิภาพสูง ปลอดภัยต่อหน่วยความจำ และบูรณาการกับส่วนประกอบ SDK อื่นๆ ได้อย่างราบรื่น

● การบูรณาการดั้งเดิม: REVM จะถูกคอมไพล์โดยตรงลงใน Polkadot SDK ซึ่งไม่จำเป็นต้องใช้ส่วนเสริม Frontier

● ประสบการณ์นักพัฒนาแบบรวมศูนย์: เข้ากันได้กับเครื่องมือ Ethereum ทั้งหมด (Foundry, Hardhat, Ethers.js) นักพัฒนาสามารถใช้เครื่องมือ Ethereum ที่มีอยู่ได้โดยตรง "ทันทีที่แกะกล่อง"

● ต้นทุนการโยกย้ายเป็นศูนย์: สัญญา Solidity สามารถปรับใช้กับเครือข่ายหลัก Polkadot หรือเครือข่าย SDK ใดๆ ได้โดยไม่ต้องปรับเปลี่ยน

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

ซึ่งหมายความว่าการปรับใช้และการดำเนินการตามสัญญา EVM จะกลายเป็นฟังก์ชันพื้นฐานที่ระดับเมนเน็ต Polkadot เป็นครั้งแรก

การเกิดขึ้นของ REVM ไม่ได้เป็นผลมาจากการแข่งขันภายนอก แต่เป็นผลลัพธ์ที่หลีกเลี่ยงไม่ได้จากการผสานรวม SDK เมื่อโมดูลและโปรโตคอลพื้นฐานได้รับการทำให้เป็นมาตรฐานอย่างสมบูรณ์ ความเข้ากันได้ของ EVM จะถูกรวมเข้ากับมาตรฐานระบบโดยอัตโนมัติ แทนที่จะกลายเป็นปลั๊กอินเสริม นี่เป็นครั้งแรกที่ Polkadot ได้ "ผสาน Ethereum" เข้ากับระดับการประมวลผลอย่างแท้จริง นับเป็นการก้าวกระโดดจาก "ความเข้ากันได้" ไปสู่ ​​"เนทีฟ"

ในปี 2025 Parity ตัดสินใจที่จะเขียนกรอบการพัฒนาใหม่ทั้งหมด

SDK Polkadot ใหม่ไม่เพียงสืบทอดแก่นแท้ของ Substrate เท่านั้น แต่ยังคอมไพล์ EVM ของ Ethereum ลงในแกนหลักโดยตรงอีกด้วย

นี่ไม่ใช่แค่การทำซ้ำเวอร์ชันเท่านั้น แต่เป็นการสร้างปรัชญาพื้นฐานขึ้นมาใหม่

Polkadot ไม่เพียงแต่เข้ากันได้กับ Ethereum เท่านั้น แต่ยังดูดซับและทำให้มันกลายเป็นส่วนหนึ่งดั้งเดิมอีกด้วย

แต่คำถามก็คือ Polkadot สามารถรักษาสถานะเดิมเอาไว้ได้ ดังนั้นเหตุใดจึงต้องเสี่ยงเขียน SDK ใหม่ทั้งหมดในปี 2025 และใส่ EVM ลงในเคอร์เนลของระบบโดยตรง?

Substrate ซึ่งเดิมพัฒนาโดย Parity (บริษัทที่อยู่เบื้องหลังการพัฒนาหลักของ Polkadot) เป็นเฟรมเวิร์กการพัฒนาบล็อกเชนแบบโมดูลาร์สำหรับ Rust ใช้เพื่อสร้างบล็อกเชนแบบอิสระและประกอบด้วยโมดูลหลักต่างๆ เช่น ฉันทามติ พื้นที่จัดเก็บ เครือข่าย และรันไทม์ Substrate เป็นรากฐานทางเทคโนโลยีพื้นฐานของเครือข่าย Polkadot

ระหว่างปี 2023 ถึง 2024 Parity ได้รวม Substrate, Cumulus (โมดูลข้ามสายโซ่) และไคลเอนต์ Polkadot เข้าไว้ในที่เก็บข้อมูลเดียวที่ชื่อว่า Polkadot SDK (ชุดพัฒนาซอฟต์แวร์) เพื่อลดความซับซ้อนของโครงสร้างการพัฒนาและการจัดการ API

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

ส่วนประกอบหลักของ Polkadot SDK ปัจจุบัน:

ในอนาคต REVM จะเป็นส่วนหนึ่งของระบบนิเวศ PolkaVM/PVM ในฐานะโมดูลแบ็กเอนด์ของเครื่องเสมือนที่รองรับความเข้ากันได้ของ EVM (Ethereum Virtual Machine) โดยเป็นส่วนหนึ่งของ "โซลูชันที่เข้ากันได้กับ EVM" ร่วมกับ pallet-revive + ETH-RPC

ใน Polkadot SDK เวอร์ชันล่าสุดนี้ REVM ได้ถูกรวมเข้ากับส่วนประกอบหลักอย่างชัดเจน (เช่น โมดูลมาตรฐานสำหรับเลเยอร์การดำเนินการสัญญาอัจฉริยะ) เชน SDK ในอนาคตทั้งหมดจะรองรับ REVM/EVM โดยอัตโนมัติ โดยไม่จำเป็นต้องใช้ส่วนเสริมหรือแพ็คเกจความเข้ากันได้จากภายนอก กลยุทธ์ "การมอบความเข้ากันได้ของ EVM แบบดั้งเดิมให้กับระบบนิเวศ Polkadot" ได้รับการเสริมความแข็งแกร่งในฐานโค้ดหลักและเอกสารประกอบการพัฒนาอย่างเป็นทางการ

เทคโนโลยีหลักของ Polkadot SDK

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

โครงสร้างนี้ทำให้ Polkadot SDK ไม่ใช่แค่เพียง "กรอบการสร้างแบบโซ่" เท่านั้น แต่ยังเป็นระบบปฏิบัติการที่สามารถพัฒนาได้อย่างต่อเนื่องอีกด้วย

ตามที่เอกสารอย่างเป็นทางการเน้นย้ำ: SDK ไม่เพียงแต่ให้โมดูล แต่ยังกำหนดด้วยว่าโมดูลสามารถทำงานร่วมกันอย่างปลอดภัย แบ่งปันทรัพยากร และอัปเกรดได้อย่างไร

จาก Substrate สู่ Polkadot SDK: เหตุใด EVM จึงเข้าสู่ "ยุคดั้งเดิม" ด้วย Polkadot

ตัว Substrate เองไม่ได้มาพร้อมกับ EVM แต่จะผสานรวมแบบไดนามิกผ่านพาเลทและโมดูล RPC ในคลัง Frontier เชน Substrate ใดๆ (เช่น Moonbeam, Astar, Acala เป็นต้น) จำเป็นต้องนำเข้าโมดูลเหล่านี้

โหนดชายแดนรักษาโครงสร้างข้อมูลเพิ่มเติม (แฮชบล็อก Ethereum ดัชนีธุรกรรม บันทึก ฯลฯ) เพื่อตอบสนองฟังก์ชันการค้นหาดัชนี RPC ดังนั้นจึงต้องใช้ทรัพยากรมากกว่าโหนด Substrate ล้วนๆ

นักพัฒนาบางคนเรียกมันว่า "Ethereum sandbox ใน Substrate" เนื่องจากมันจำลองการดำเนินการ EVM และโมเดลการจัดเก็บข้อมูลแบบเต็มรูปแบบนอกสภาพแวดล้อม Substrate

อย่างไรก็ตาม มันยังมีข้อจำกัดบางประการด้วย:

การแบ่งกลุ่มประสบการณ์ผู้ใช้: กระเป๋าสตางค์แบบ Polkadot.js จำเป็นต้องผสานรวมกับ Metamask สินทรัพย์ EVM/ERC20 และ Substrate มักจะทำงานแยกกัน (บางโครงการช่วยบรรเทาปัญหานี้ด้วยการแมปที่อยู่และส่วนหน้าแบบกำหนดเอง แต่สาระสำคัญยังคงเหมือนเดิม)

การใช้ทรัพยากรสูง: โหนดจำเป็นต้องดำเนินการจัดทำดัชนีเฉพาะและการแยกวิเคราะห์บล็อกสำหรับ RPC ที่เกี่ยวข้องกับ EVM ซึ่งจะเพิ่มแรงกดดันต่อข้อมูลและการจัดเก็บ (โดยเฉพาะอย่างยิ่งสำหรับ ETH-style_block/explorer เป็นต้น)

การแยกโมดูล EVM และ Substrate: สัญญา EVM มีปัญหาในการเรียกหรือจัดการพาเลทดั้งเดิมของ Substrate โดยตรง ทำให้การนำตรรกะมาใช้ซ้ำ/การจัดการสิทธิ์มีความซับซ้อนมากขึ้น และ "เอฟเฟกต์แซนด์บ็อกซ์" ก็ชัดเจน

เพื่อเอาชนะข้อจำกัดเหล่านี้ พาราเชน Moonbeam ของ Polkadot จึงสามารถผสานรวมเข้ากับความเข้ากันได้ของ EVM ได้อย่างลึกซึ้งยิ่งขึ้นบน Frontier ที่มีอยู่เดิม Moonbeam ไม่เพียงแต่ "ผสานรวมกับ Frontier" เท่านั้น แต่ยังได้เขียน Frontier ขึ้นใหม่ทั้งหมดและเชื่อมโยงเข้ากับ Substrate อย่างลึกซึ้ง โดยฝังพาเลท EVM, พาเลท Ethereum, การจัดการบัญชี และอินเทอร์เฟซคอนเซนซัสแบบครอสเชนของ XCM ไว้ในรันไทม์หลัก และรวมการกระจาย Substrate พื้นฐานเข้ากับสินทรัพย์ เหตุการณ์ และการกำกับดูแลของ EVM

Moonbeam ใช้การออกแบบการทำแผนที่หลายรายการและพาเลทสะพานเพื่อทำการแมปที่อยู่ EVM ไปยังที่อยู่ Substrate ช่วยให้บัญชีต่างๆ สามารถโอนเงิน จัดการสินทรัพย์ และเรียกพาเลทดั้งเดิมระหว่างเลเยอร์ EVM และ Substrate ได้อย่างราบรื่น ช่วยลดการขาดการเชื่อมต่อระหว่าง "กระเป๋าเงินคู่" ของผู้ใช้ได้อย่างมาก (แม้ว่ารูปแบบคีย์ส่วนตัวจะแตกต่างกัน แต่ส่วนใหญ่จะรองรับลายเซ็นคู่และการจดจำอัตโนมัติ)

โหนด Moonbeam เปิดเผยทั้ง Ethereum JSON-RPC และ Substrate RPC ต่อโลกภายนอก ช่วยให้นักพัฒนา สามารถโต้ตอบกับสินทรัพย์เดียวกันได้โดยใช้ Metamask/Hardhat/tools และ Polkadot.js/app

อย่างไรก็ตาม แม้ว่า Moonbeam จะใช้สะพานเชื่อมระหว่างที่อยู่ EVM และที่อยู่ Substrate แต่ประเภทคีย์ส่วนตัวของผู้ใช้และอัลกอริทึมลายเซ็น (Ethereum secp256k1 และ Substrate sr25519/ed25519) มักจะแตกต่างกันเสมอ กระเป๋าสตางค์ฮาร์ดแวร์หรือเครื่องมือระบบนิเวศทั้งหมดไม่สามารถ "รองรับ" ลายเซ็นแบบคู่ได้โดยอัตโนมัติ ซึ่งอาจทำให้เกิดอุปสรรคด้านความเข้ากันได้ในสถานการณ์ที่รุนแรง

การดำเนินการขั้นสูงบางอย่าง (โดยเฉพาะการกำกับดูแลแบบเนทีฟเชน การมอบหมาย ฯลฯ) ต้องใช้กระเป๋าเงิน Substrate เฉพาะ และประสบการณ์การเชื่อมต่อยังคงด้อยกว่าเชน EVM ล้วนๆ

สถานการณ์ข้ามสายโซ่ที่เกี่ยวข้องกับสินทรัพย์และโทเค็นหลายรายการ (สินทรัพย์เนทีฟ, ERC20, สินทรัพย์ซับสเตรต) ยังคงต้องจัดการรูปแบบต่างๆ ของที่อยู่/รหัส ตรรกะการอนุมัติ และตารางการแมป การพัฒนาและการดำเนินการยังคงมีความซับซ้อนในการบำรุงรักษา และการถ่ายโอนระหว่างสายโซ่บางส่วนต้องอาศัย XCM หรือโปรโตคอลบริดจ์สำหรับการประมวลผลภายหลัง ส่งผลให้เกิดความล่าช้าในการซิงโครไนซ์

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

คำปฏิเสธความรับผิดชอบ

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

อ่านเพิ่มเติม

https://polkadot-evm.github.io/frontier/ภาพรวม

https://github.com/polkadot-evm/frontier