อีเธอร์สแกน(Etherscan) จับมือ GitMyABI แปลง ABI สัญญายืนยันแล้วเป็นแพ็กเกจ npm ติดตั้งได้ทันที

อีเธอร์สแกน(Etherscan) ขยายการเชื่อมต่อกับ GitMyABI ให้ครอบคลุมมากขึ้น โดยดึงข้อมูล ABI ของสัญญาอัจฉริยะ (smart contract) ที่ผ่านการยืนยันแล้ว มาแปลงเป็นแพ็กเกจ npm ที่ติดตั้งได้ พร้อม TypeScript bindings ให้นักพัฒนานำไปใช้ต่อได้ทันที การเปลี่ยนแปลงครั้งนี้ไม่ได้เพิ่มฟังก์ชันใหม่บนเชน แต่เป็นการลดภาระการจัดการ ‘อินเทอร์เฟซ’ ที่นักพัฒนา dApp ต้องทำซ้ำๆ ในกระบวนการพัฒนา

เว็บไซต์ทางการของ GitMyABI ระบุว่าการเชื่อมต่อกับอีเธอร์สแกนอยู่ในสถานะ ‘live’ แล้ว และอธิบายว่าผู้ใช้สามารถติดตั้ง SDK ได้จากแท็บ Cards บนหน้าสัญญาที่ยืนยันแล้วโดยตรง

Crypto Briefing รายงานว่าการเชื่อมต่อนี้คือฟีเจอร์ที่แปลงสัญญายืนยันแล้วให้กลายเป็นแพ็กเกจ npm แบบติดตั้งได้ หากตัดส่วนที่เป็นการรายงานต่อออกไป ใจความหลักที่ยืนยันได้คือสัญญาที่ผ่านการยืนยันบนอีเธอร์สแกนกับเครื่องมือแพ็กเกจของ GitMyABI ถูกเชื่อมเข้าด้วยกันแล้ว

ABI คือเอกสารรูปแบบ JSON ที่กำหนดฟังก์ชัน อีเวนต์ และรูปแบบข้อมูลเข้า-ออกที่สัญญาอัจฉริยะเปิดให้เรียกใช้จากภายนอก dApp ต้องอาศัย ABI นี้ในการสื่อสารกับสัญญา และทุกครั้งที่ ABI เปลี่ยน โค้ดฝั่งหน้าบ้าน (frontend) ก็ต้องแก้ตามไปด้วย

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

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

เว็บไซต์ทางการของ GitMyABI ชูจุดเด่นสามเรื่องคือ การออกรีลีสตามเวอร์ชัน การสร้าง TypeScript bindings อัตโนมัติ และระบบแคชกลางสำหรับส่งต่อข้อมูล แนวทางนี้ต่างจากการย้ายไฟล์ ABI ด้วยมือ เพราะดึงการจัดการอินเทอร์เฟซของสัญญาเข้าไปอยู่ในระบบจัดการ dependency ของแพ็กเกจแทน

บนที่เก็บ npm สาธารณะก็มีแพ็กเกจที่เกี่ยวข้องเผยแพร่อยู่จริง โดย @gitmyabi/cli ระบุว่าสามารถสร้างแพ็กเกจ npm แบบ typed-ABI จาก Foundry, Hardhat หรือไฟล์ ABI JSON ดิบ แล้วเผยแพร่ขึ้นเรจิสทรีได้โดยตรง

นอกจากนี้ยังพบแพ็กเกจชนิดสร้างไทป์อัตโนมัติ เช่น @gitmyabi-stg/nas, @gitmyabi-stg/leo, @gitmyabi-stg/avi และ @gitmyabi-stg/uniswap--v4-protocol ซึ่งบน npm สาธารณะระบุไว้ว่าเป็น ‘Auto-generated TypeScript type bindings’

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

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

สิ่งที่มีนัยสำคัญกับนักพัฒนาคือการลดปัญหา ‘ABI drift’ หรือการที่อินเทอร์เฟซสัญญากับโค้ดฝั่งหน้าบ้านอ้างอิงคนละเวอร์ชันกัน ซึ่งอาจทำให้การเรียกใช้ฟังก์ชันล้มเหลวหรือเกิดข้อผิดพลาดที่ไม่คาดคิด การใช้แพ็กเกจที่ล็อกเวอร์ชันไว้ชัดเจนจึงช่วยลดภาระตรงนี้ได้

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

ข้อกำหนดการใช้งานของ GitMyABI ระบุว่าให้บริการในรูปแบบ ‘as is’ และไม่รับประกันความถูกต้องของ ABI หรือการทำงานต่อเนื่องโดยไม่มีสะดุด ดังนั้นหากจะนำไปใช้ในสภาพแวดล้อมจริง (production) ผู้ใช้ต้องตรวจสอบความถูกต้องของ ABI ด้วยตัวเองก่อน

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

แหล่งข้อมูลที่ใช้ตรวจสอบ: เว็บไซต์ทางการของ GitMyABI, ข้อกำหนดการใช้งานของ GitMyABI, ศูนย์ข้อมูลอีเธอร์สแกน, ethereum.org, npm @gitmyabi/cli, แพ็กเกจสร้างอัตโนมัติของ GitMyABI บน npm และ Crypto Briefing