-- พื้นหลัง--

ในปัจจุบัน วิธีการเข้าถึงของแพลตฟอร์ม blockchain cross-chain ค่อนข้างแตกต่างกันในแง่ของการออกแบบสถาปัตยกรรม วิธีการเชื่อมต่อ application chain กับระบบ cross-chain อย่างรวดเร็วและสะดวกเป็นปัญหาเร่งด่วนที่ต้องแก้ไข แพลตฟอร์มบริการข้ามสายโซ่ของ BitXHub ใช้โซลูชันข้ามสายโซ่ของรีเลย์เชน + เกตเวย์ ซึ่งเกตเวย์ข้ามสายมีบทบาทในการรวบรวมและเผยแพร่ธุรกรรมระหว่างบล็อกเชน การออกแบบกลไกปลั๊กอินจะแยกโมดูลที่โต้ตอบระหว่างเกตเวย์ (Pier) และห่วงโซ่แอ็พพลิเคชันออกจากโมดูลฟังก์ชันหลักของเกตเวย์แบบครอสเชน เพื่อให้สามารถเชื่อมต่อแอ็พพลิเคชันเชนประเภทต่างๆ กับครอส-เชนได้อย่างมีประสิทธิภาพ ระบบโซ่. เมื่อ Pier กำลังทำงาน การปรับเปลี่ยนที่ยืดหยุ่นของห่วงโซ่แอปพลิเคชันต่างๆ จะเสร็จสมบูรณ์โดยการโหลดปลั๊กอินแบบไดนามิก เพื่อปรับปรุงการโต้ตอบระหว่าง Pier และ application chain ให้ดีขึ้น ปลั๊กอินของ application chain เฉพาะจำเป็นต้องใช้อินเทอร์เฟซเฉพาะตามลักษณะของ blockchains ต่าง ๆ อินเทอร์เฟซการโต้ตอบต้องเป็นไปตามฟังก์ชันต่อไปนี้:

1) ตรวจสอบเหตุการณ์ข้ามสายโซ่บนห่วงโซ่แอปพลิเคชันและส่งต่อไปยังโมดูลหลักสำหรับการประมวลผล

2) ดำเนินการคำขอข้ามเชนจากเกตเวย์ (จากแอพพลิเคชั่นเชนอื่น ๆ );

3) ความสามารถในการค้นหาสถานะของคำขอข้ามสายโซ่ที่ได้รับและดำเนินการในสายแอปพลิเคชัน

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

—— ปลั๊กอินเนทีฟ ——

ภาษา go รองรับการคอมไพล์เป็นปลั๊กอินจากเวอร์ชั่น 1.13 และการใช้งานมีดังนี้

• go build --buildmode=plugin -o appchain.so *.go

โครงการ go สามารถระบุเป็นโหมดปลั๊กอินผ่าน --buildmode เมื่อคอมไพล์ และเอาต์พุตจะเป็นไฟล์ลิงก์แบบไดนามิกด้วยวิธีนี้ ไฟล์นี้ไม่ใช่ไฟล์ไบนารีที่สามารถเรียกใช้ได้โดยตรง แต่เป็นการเรียกแบบไดนามิกที่จัดเตรียมให้กับไบนารีรันไทม์อื่นๆ

ใช้ในไบนารีหลักดังนี้:

ข้อได้เปรียบ:

ข้อได้เปรียบ:

1) ประสบการณ์ของผู้ใช้สอดคล้องกับรหัสเนทีฟ คล้ายกับไบนารีของโมดูลรหัส

ข้อบกพร่อง:

ข้อบกพร่อง:

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

—— เปลี่ยนเป็นปลั๊กอิน RPC ——

ข้อจำกัดของเวอร์ชันที่เข้มงวดในปลั๊กอินเนทีฟทำให้เป็นไปได้ว่าเมื่ออัปเกรดฟังก์ชันหลักของโปรแกรมหลักปลั๊กอินและ/หรือเกตเวย์ การพึ่งพาบางอย่างของโปรแกรมหลักอาจได้รับการอัปเกรดโดยไม่ได้ตั้งใจ และปลั๊กอินต้องทำการปรับแบบเดียวกันด้วย อัปเกรด วิธีนี้ไม่เอื้อต่อการแยกปลั๊กอินทั้งหมด เราจึงหันไปใช้โปรเจ็กต์ปลั๊กอิน GO อื่นที่ใช้ RPC (ที่อยู่ GitHub ของโครงการ: https://github.com/hashicorp/go-plugin)

go-plugin ของ Hashicorp มีอยู่แล้วก่อนที่กลไกปลั๊กอินเนทีฟของ GO จะปรากฏขึ้น แต่หลังจากปลั๊กอินเนทีฟของ GO ออกมา พวกเขาไม่ได้เลิกสนับสนุนโครงการ เพราะโดยทั่วไปแล้ว ปลั๊กอินเนทีฟไม่ใช่ สมบูรณ์แบบมาก ในบางสถานการณ์ go-plugin จะสะดวกกว่า

ปลั๊กอิน go-plugin ใช้ดังนี้:

วิธีปลั๊กอินที่ใช้โดยโครงการ go-plugin ใช้โหมด C/S โปรแกรมหลักใช้เป็น RPC Client และปลั๊กอินเฉพาะใช้เป็น RPC Server การสื่อสารระหว่างเซิร์ฟเวอร์และ ไคลเอนต์ยังขึ้นอยู่กับข้อกำหนดของอินเทอร์เฟซ

ขั้นตอนการใช้งานเฉพาะมีดังนี้:

1) Abstraction ต้องการอินเทอร์เฟซปลั๊กอิน ที่นี่ คำจำกัดความอินเทอร์เฟซที่ใช้ในปลั๊กอินเนทีฟสามารถนำมาใช้ซ้ำได้โดยตรง

2) ทั้งไคลเอนต์และเซิร์ฟเวอร์ใช้อินเทอร์เฟซข้างต้น การใช้งานฝั่งเซิร์ฟเวอร์คือรหัสสำหรับตรรกะการประมวลผลปลั๊กอินเฉพาะ การใช้งานฝั่งไคลเอนต์จำเป็นต้องสรุปผลการประมวลผล gRPC และข้อมูลข้อยกเว้นเท่านั้น จากนั้นโปรแกรมหลักจะรับรู้ gRPC เพียงเล็กน้อยเมื่อใช้ปลั๊กอิน ใน.

ส่วนการใช้งานเซิร์ฟเวอร์:

ส่วนการใช้งานไคลเอนต์:

▲ควรให้ความสนใจเพิ่มเติมกับ:

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

• โปรแกรมหลักใช้วัตถุ plugin.Client เพื่อเริ่มการทำงานของปลั๊กอิน ซึ่งทำงานในกระบวนการอื่น ดังนั้นการหยุดทำงานของปลั๊กอินจะไม่ส่งผลกระทบต่อโปรแกรมหลัก

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

-- บทสรุป--

เกี่ยวกับผู้เขียน

เกี่ยวกับผู้เขียน

ทีม FunChain Technology Data Grid Lab BitXHub

ทีม FunChain Technology Data Grid Lab BitXHub