详解ERC-8183：以太坊攻坚AI Agent互信难题的答案

ต้นฉบับ | Odaily (@OdailyChina)

ผู้เขียน｜Azuma (@azuma_eth)

วันที่ 10 มีนาคม ทีม dAI ของมูลนิธิ Ethereum ซึ่งมุ่งเน้นในการส่งเสริม "การบูรณาการอย่างลึกซึ้งระหว่างปัญญาประดิษฐ์ (AI) และบล็อกเชน" ร่วมกับ Virtuals Protocol ได้เปิดตัวมาตรฐานใหม่ ERC-8183

Davide Crapis หัวหน้าฝ่าย AI ของมูลนิธิ Ethereum กล่าวเกี่ยวกับมาตรฐานนี้ว่า ERC-8183 เป็นหนึ่งในองค์ประกอบที่ขาดหายไปของระบบเศรษฐกิจ Agent แบบเปิดที่ชุมชน Ethereum กำลังสร้างอยู่ มาตรฐานนี้สามารถใช้ร่วมกับ x402 และ ERC-8004 เพื่อทำหน้าที่เป็นโครงสร้างพื้นฐานสำหรับการโต้ตอบที่ปลอดภัยระหว่าง Agent ทีม dAI จะสนับสนุนการนำ ERC-8183 มาใช้ และมุ่งมั่นที่จะทำให้มันกลายเป็นมาตรฐานที่เป็นกลาง

ERC-8183 ต้องการแก้ปัญหาอะไร?

ตามบทความแนะนำที่เผยแพร่โดย Virtuals Protocol ERC-8183 ออกแบบมาสำหรับธุรกรรมเชิงพาณิชย์ระหว่าง AI Agent โดยมาตรฐานนี้กำหนดชุดกฎบนเชนที่ช่วยให้ Agent สองตัวที่ไม่ไว้วางใจซึ่งกันและกันสามารถดำเนินกระบวนการทางธุรกิจแบบ "จ้าง-ส่งมอบ-ชำระเงิน" ได้ โดยไม่ต้องพึ่งพาแพลตฟอร์มแบบรวมศูนย์

ปัญหาหลักที่ ERC-8183 พยายามแก้ไขคือ เมื่อ Agent จ้างและทำงานร่วมกัน จะทำธุรกรรมให้สำเร็จได้อย่างไรโดยไม่มีแพลตฟอร์ม ไม่มีกฎหมาย และไม่มีอนุญาโตตุลาการมนุษย์?

ตัวอย่างเช่น หาก Agent A ที่เน้นด้านการตลาดต้องการจ้าง Agent B ที่เน้นการสร้างภาพเพื่อผลิตโปสเตอร์การตลาดจำนวนหนึ่ง จะมีปัญหาความไว้วางใจทางธุรกิจเกิดขึ้น — ทั้งสองฝ่ายไม่รู้จักกันและไม่มีพื้นฐานความไว้วางใจ ควรชำระเงินเมื่อไหร่? หาก A ชำระเงินก่อน B อาจหยุดทำงานหรือส่งผลงานที่ไม่เป็นไปตามมาตรฐาน; หาก B ทำงานก่อน A ก็อาจปฏิเสธที่จะจ่ายค่าตอบแทน...

ในโลกอินเทอร์เน็ตแบบดั้งเดิม ผู้ใช้และผู้ขายก็เผชิญกับปัญหาความไว้วางใจทางธุรกิจที่คล้ายกัน โดยแพลตฟอร์มทำหน้าที่เป็นตัวกลางที่สำคัญ — แพลตฟอร์มจะดูแลจัดการเงินของ A รับผิดชอบในการตัดสินว่าบริการของ B เสร็จสมบูรณ์หรือไม่ และดูแลการปล่อยเงินในขั้นตอนสุดท้าย แพลตฟอร์มที่เราคุ้นเคยอย่าง Taobao, JD.com, Meituan, Didi โดยพื้นฐานแล้วล้วนเป็นตัวกลางประเภทแพลตฟอร์มเหล่านี้

สิ่งที่มูลนิธิ Ethereum และ Virtuals Protocol ต้องการทำคือ การทำให้หน้าที่ของแพลตฟอร์มเป็นนามธรรมผ่าน ERC-8183 ให้กลายเป็นโปรโตคอลบนเชน ที่ดำเนินการโดยสัญญาอัจฉริยะ เพื่อทำหน้าที่เป็นตัวกลางแบบกระจายศูนย์ในระบบเศรษฐกิจ Agent

การวิเคราะห์กลไกการทำงานของ ERC-8183

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

• Client: "ลูกค้า" พูดง่ายๆ ก็คือ Agent ที่เผยแพร่งานประเภทต่างๆ
• Provider: "ผู้ให้บริการ" คือ Agent ที่รับผิดชอบในการทำงานให้สำเร็จ
• Evaluator: "ผู้ประเมิน" เป็นบทบาทที่พิเศษที่สุด รับผิดชอบในการตัดสินว่างานเสร็จสมบูรณ์หรือไม่

ที่นี่จำเป็นต้องอธิบาย Evaluator ให้ละเอียด การแนะนำบทบาทนี้เป็นการออกแบบที่สำคัญที่สุดของ ERC-8183 ในมาตรฐานนี้ Evaluator ถูกกำหนดให้เป็นเพียงที่อยู่บนเชน (address) แต่ในมุมมองที่กว้างขึ้น ที่อยู่นี้สามารถสอดคล้องกับรูปแบบการดำเนินการที่แตกต่างกันหลายรูปแบบ

• สำหรับงานที่มีลักษณะอัตนัย เช่น การเขียน การออกแบบ หรือการวิเคราะห์ Evaluator สามารถเป็น AI Agent ที่จะอ่านผลลัพธ์ที่ส่งมา เปรียบเทียบกับข้อกำหนดงานเริ่มต้น แล้วจึงตัดสิน
• สำหรับงานที่มีลักษณะกำหนดได้ เช่น การคำนวณ การสร้างพิสูจน์ หรือการแปลงข้อมูล Evaluator สามารถเป็นสัญญาอัจฉริยะที่ห่อหุ้มตัวตรวจสอบความรู้เป็นศูนย์ (ZK verifier) Provider ส่งพิสูจน์ Evaluator ตรวจสอบบนเชน และเรียกใช้ฟังก์ชัน 'complete' หรือ 'reject' โดยอัตโนมัติเพื่อทำให้งานเสร็จสมบูรณ์หรือปฏิเสธงานนั้น
• ในสถานการณ์งานที่มีมูลค่าสูงหรือมีความเสี่ยงสูง Evaluator ยังสามารถเป็นบัญชีหลายคนลงนาม (multi-signature account), DAO, หรือคลัสเตอร์ผู้ตรวจสอบที่ได้รับการสนับสนุนโดยกลไกการวางเงินประกัน (staking)

ERC-8183 จะไม่แยกแยะรูปแบบที่แตกต่างกันเหล่านี้ เลเยอร์โปรโตคอลสนใจเพียงสิ่งเดียว — ที่อยู่หนึ่งเรียกใช้ 'complete' หรือ 'reject' ไม่ว่าที่อยู่หลังนั้นจะขับเคลื่อนโดย AI Agent ที่ใช้ LLM หรือเป็นวงจร ZK ก็ไม่ใช่ขอบเขตที่โปรโตคอลต้องสนใจ

กลับมาที่ Job อีกครั้ง วงจรชีวิตของแต่ละ Job จะมีสถานะสี่สถานะต่อไปนี้ ซึ่งสอดคล้องกับกระบวนการต่างๆ ที่เกิดขึ้นเมื่อ ERC-8183 ทำงาน

• Open: Client จะสร้าง Job ในช่วงนี้ เผยแพร่งานและระบุข้อกำหนดให้ชัดเจน
• Funded: Client จะโอนค่าคอมมิชชันไปยังที่อยู่สัญญาอัจฉริยะสำหรับเก็บรักษา (escrow) แทนที่จะจ่ายให้ Provider โดยตรง
• Submitted: Provider เสร็จสิ้นงานและส่งพิสูจน์
• Terminal (Completed / Rejected / Expired): Evaluator รับผิดชอบในการตรวจสอบงาน และตัดสินว่างานเสร็จสมบูรณ์หรือไม่ (Completed หรือ Rejected) ตามผลการตรวจสอบ และโอนเงินให้ Client หรือ Provider ตามลำดับ หากไม่มี Provider ตอบรับหรือทำงานให้เสร็จภายในเวลาที่กำหนด เงินจะถูกคืนให้ Client

นอกจากกระบวนการมาตรฐานข้างต้นแล้ว ERC-8183 ยังสามารถใช้ฟังก์ชันขยายแบบโมดูลาร์ที่เรียกว่า Hooks เพื่อใช้งานเพิ่มเติมอื่นๆ ได้ เพื่อให้สอดคล้องกับกรณีใช้เชิงพาณิชย์ที่ซับซ้อนในโลกแห่งความเป็นจริง Hooks คือสัญญาอัจฉริยะเสริมที่เลือกได้ซึ่งเพิ่มเข้ามาเมื่อสร้าง Job สามารถดำเนินลอจิกที่กำหนดเองก่อนหรือหลังแต่ละช่วงของวงจรชีวิตของ Job ได้ เช่น เกณฑ์ความน่าเชื่อถือ กลไกการประมูล การกระจายค่าธรรมเนียม หรือข้อกำหนดพิเศษอื่นๆ

ERC-8183 แตกต่างจาก x402 และ ERC-8004 อย่างไร?

จาก x402 ไปยัง ERC-8004 จนถึง ERC-8183 ในปัจจุบัน ผู้อ่านที่ไม่คุ้นเคยอาจสับสน สงสัยว่าทำไมต้องสร้างสิ่งใหม่ทุกครั้ง แต่จริงๆ แล้ว สามสิ่งนี้อยู่ในสามส่วนที่แตกต่างกันของระบบเศรษฐกิจ AI Agent และพยายามแก้ปัญหาที่แตกต่างกัน

x402 เป็นโปรโตคอลการชำระเงิน HTTP มันพยายามแก้ปัญหาการทำให้ AI Agent สามารถชำระเงินได้โดยตรงเหมือนเรียกใช้ API; ERC-8004 เป็นมาตรฐานตัวตนและชื่อเสียงของ AI Agent มันแก้ปัญหาว่าจะตัดสินได้อย่างไรว่า Agent หนึ่งน่าเชื่อถือหรือไม่; ERC-8183 มุ่งเน้นไปที่ส่วนของธุรกรรมเชิงพาณิชย์ พยายามแก้ปัญหาว่าจะทำให้ Agent สองตัวที่ไม่ไว้วางใจกันทำธุรกรรมสำเร็จได้อย่างไร

หากสรุปด้วยประโยคเดียว x402 รับผิดชอบแก้ปัญหา "จะจ่ายเงินอย่างไร"; ERC-8004 รับผิดชอบรู้ว่า "อีกฝ่ายคือใคร น่าเชื่อถือหรือไม่"; ERC-8183 รับผิดชอบจัดการ "จะทำธุรกรรมอย่างไรให้มั่นใจ"

ทั้งสามสิ่งนี้ไม่ได้แข่งขันกัน แต่เป็นความสัมพันธ์ที่เสริมกัน พวกมันชี้ไปที่เป้าหมายเดียวกัน — การสร้างระบบเศรษฐกิจ AI Agent แบบกระจายศูนย์ที่สามารถทำงานได้ด้วยตัวเอง