ซีรีส์ Web3 สำหรับผู้เริ่มต้น: การสำรวจโปรโตคอลการชำระเงินแบบ On-Chain ใหม่ – x402

Coinbase เพิ่งประกาศเปิดตัวโปรโตคอลการชำระเงินใหม่: x402 นับตั้งแต่ Coinbase เป็นผู้ริเริ่มใช้ x402 โปรโตคอลนี้จึงรองรับ Base Sepolia และพร้อมใช้งานเป็นค่าเริ่มต้น นอกจากนี้ ยังรองรับเครือข่าย Solana อยู่แล้ว ซึ่งพิสูจน์ให้เห็นว่า x402 ไม่ได้ผูกติดกับเครือข่ายใดเครือข่ายหนึ่งโดยเฉพาะ

https://github.com/coinbase/x402

เพื่อทำความเข้าใจกระบวนการนี้ ผมจึงได้สร้างคลังข้อมูลใหม่ (https://github.com/gin-lsl/x402-solana-demo) ซึ่งประกอบด้วยส่วนประกอบทั้งหมดของเซิร์ฟเวอร์ ไคลเอนต์ และตัวอำนวยความสะดวก ณ ที่นี้ เลือกใช้ Koa เป็นเฟรมเวิร์กพื้นฐานเพื่อให้ไคลเอนต์สามารถเข้าถึงอินเทอร์เฟซเฉพาะที่เซิร์ฟเวอร์จัดเตรียมไว้ให้ โดยชำระเงินด้วย USDC (โทเค็นแบบกำหนดเอง) ของ Devnet

คำอธิบายบางประการ

ขั้นแรก ฉันสร้างโทเค็นที่สอดคล้องกันโดยใช้เครื่องมือ spl-token ซึ่งสามารถดูได้ที่นี่: https://solscan.io/token/9gKBTRXgVTszU31A12oJKKSy6aje8LyoVvNfSimembHo?cluster=devnet

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

หากคุณจำเป็นต้องรันโปรเจ็กต์ คุณต้องสร้างไฟล์ .env กรอกตัวแปรสภาพแวดล้อมที่จำเป็น จากนั้นเริ่มเซิร์ฟเวอร์และรันโค้ดไคลเอนต์ในเทอร์มินัล:

คำอธิบายโค้ด

เนื่องจากเป็นเพียงการสาธิต จึงจัดวางไว้ในตำแหน่งเดียว ด้านล่างนี้คือคำอธิบายเอกสารสำคัญบางส่วน:

โซลานา.ทีเอส

มันมีอินเทอร์เฟซที่เรียกว่า "/solana/get-balance" ซึ่งเราถือว่ามันเป็นอินเทอร์เฟซที่มีประโยชน์ที่ต้องเสียค่าธรรมเนียมเล็กน้อยในการเรียกใช้ ในฐานะเซิร์ฟเวอร์ มันสอดคล้องกับส่วน (5) ถึง (8) ในแผนภาพลำดับ และโดยเฉพาะอย่างยิ่งคือส่วน (7)

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

ผู้ช่วยอำนวยความสะดวก.ts

โปรแกรมนี้ใช้ความสามารถของ Facilitator โดยหลักๆ แล้วจะมีอินเทอร์เฟซ /supported, /verify และ /settle ซึ่งใช้สำหรับสอบถามข้อมูลในเครือข่ายที่รองรับในปัจจุบัน ตรวจสอบข้อมูลธุรกรรม และให้ความสามารถในการชำระเงินแบบ on-chain ตามลำดับ ในส่วนนี้ระบบจะโต้ตอบกับเครือข่าย ซึ่งต้องใช้คีย์ส่วนตัวเพื่อชำระค่าธรรมเนียมธุรกรรมแบบ on-chain ในทางสถาปัตยกรรม ระบบจะไม่ขึ้นอยู่กับเซิร์ฟเวอร์ (เช่น solana.ts) ซึ่งสอดคล้องกับ (9) และ (10) ในแผนภาพลำดับ

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

สำหรับโซ่ Solana หลังจากคำขอถึง POST /settle แล้ว ฟังก์ชัน settle ใน "x402/facilitator" จะถูกเรียกใช้ หลังจากการตรวจสอบแล้ว ฟังก์ชัน sendTransaction บน RPC จะถูกเรียกใช้เพื่อส่งธุรกรรม จากนั้นจึงใช้ waitForRecentTransactionConfirmation เพื่อรอและยืนยันผลลัพธ์ของธุรกรรม โค้ดที่เกี่ยวข้องจัดทำโดย @solana/kit ส่วน EVM ก็ใช้ตรรกะที่คล้ายกัน

x402-มิดเดิลแวร์.ts

ใช้เพื่อเชื่อมต่อเซิร์ฟเวอร์และผู้ให้บริการ โดยทำหน้าที่เป็นมิดเดิลแวร์ Koa ที่คอยปกป้อง API ที่ต้องชำระเงินเพื่อเข้าถึง โค้ดอ้างอิงถึง "x402-express" อย่างเป็นทางการ ฟังก์ชันของโค้ดนี้คือการส่งคืนสถานะ 402 โดยอัตโนมัติ และส่งต่อคำขอ /verify และ /settle

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

• การตั้งค่า maxAmountRequired ให้มีค่าสูงมากจะได้รับการตรวจสอบความถูกต้องทางฝั่งไคลเอ็นต์ หากจำนวนเงินที่ผู้ใช้ต้องจ่ายสูงกว่าค่านี้ ระบบจะแจ้งข้อยกเว้นให้ทราบโดยตรง
• สินทรัพย์ถูกตั้งค่าเป็นโทเค็นที่เราสร้างขึ้นเอง: 9gKBTRXgVTszU31A12oJKKSy6aje8LyoVvNfSimembHo แทนที่จะเป็นที่อยู่โทเค็นที่สร้างไว้ใน x402 บนเมนเน็ต นี่ควรเป็นที่อยู่ USDC อย่างเป็นทางการ

ที่น่าสนใจคือ x402-express ได้นำแบบจำลองหัวหอมแบบ Koa มาใช้โดยการเขียนฟังก์ชันใหม่บน Response ดังนั้น ในมิดเดิลแวร์สำหรับ Express ของพวกเขา ขั้นตอนการทำงานจริงคือ การตรวจสอบ -> ตรรกะทางธุรกิจ -> การตั้งเงื่อนไข การส่งไปยังบล็อกเชนจะเกิดขึ้นหลังจากดำเนินการตรรกะทางธุรกิจ ซึ่งตรงกับแผนภาพลำดับข้างต้น การนำตรรกะนี้ไปใช้ใน Koa นั้นง่ายมาก แต่ต้องใช้โค้ดเพิ่มเติมใน Express ซึ่งอาจเป็นเหตุผลที่พวกเขาให้ความสำคัญกับการให้บริการมิดเดิลแวร์ Express

การชำระเงินของลูกค้า-fetch.ts

ทำหน้าที่เป็นไคลเอนต์ โดยจะเริ่มต้นคำขอไปยังเซิร์ฟเวอร์ ซึ่งสอดคล้องกับขั้นตอนที่ 1 ถึง 4 ในผังงาน การดำเนินการนี้ใช้ฟังก์ชันช่วยเหลือที่จัดเตรียมโดย "x402-fetch" เพื่อจัดการสถานะ 402 โดยอัตโนมัติ สร้างลายเซ็นโดยใช้คีย์ส่วนตัวของกระเป๋าเงินไคลเอนต์ และส่งข้อมูลอีกครั้ง

ระบบจะพยายามร้องขออินเทอร์เฟซโดยตรง เมื่อพบข้อผิดพลาด 402 ระบบจะอ่านเนื้อหาที่ส่งกลับมา (ซึ่งควรมีเวอร์ชัน x402 ที่เซิร์ฟเวอร์รองรับ ซึ่งปัจจุบันกำหนดไว้ที่ 1 และพารามิเตอร์ที่จำเป็นสำหรับเซิร์ฟเวอร์) ลงนามธุรกรรมโดยใช้คีย์ส่วนตัวของคุณ จากนั้นจึงจัดลำดับข้อมูลธุรกรรมและส่งกลับไปยัง URL เดิมอีกครั้งผ่านส่วนหัว X-PAYMENT

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

ผลลัพธ์และบันทึกการดำเนินการของไคลเอนต์:

คิด

ในความคิดของฉัน หากความพยายามก่อนหน้านี้ของนักพัฒนา Web3 มุ่งเป้าไปที่การลดอุปสรรคในการเข้าใช้งานสำหรับผู้ใช้ทั่วไปเพื่อให้ใช้งาน Web3 ได้ง่ายขึ้น ทำให้ผู้ใช้ปลายทางสามารถใช้งานระบบนิเวศ Web3 ได้ง่ายขึ้น (การชำระเงิน การลงทุน ฯลฯ) ดังนั้น x402 ในปัจจุบันจึงถูกสร้างขึ้นเพื่อลดอุปสรรคในการเข้าใช้งานสำหรับนักพัฒนา Web2 เพื่อเข้าถึงช่องทางการชำระเงินของ Web3

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

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

บางทีผู้ให้บริการ Node RPC อาจต้องการสิ่งนี้ นอกจากจะมีอินเทอร์เฟซพื้นฐานแล้ว ผู้ให้บริการ RPC ยังมี Advance API อินเทอร์เฟซเร่งความเร็วธุรกรรม และอื่นๆ อีกมากมาย หากสามารถให้บริการเหล่านี้ผ่าน x402 ได้ ผู้คนจำนวนมากอาจได้สัมผัสประสบการณ์บริการของพวกเขา

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

บทความนี้เขียนโดยทีม ZAN (บัญชี X @zan_team )