กำหนดการ

ปัญหา

1. การกําหนดสถานะสิ้นสุด: สิ่งที่ทําให้แอปพลิเคชัน crypto "ใช้งานได้"

2. เหตุใด "chain abstraction" จึงเป็นวิธีแก้ปัญหา UX ที่เกิดขึ้นจากโทโพโลยีพื้นฐานของบล็อกเชนแบบแยกส่วน

3. เหตุใดแอปพลิเคชัน crypto ที่ใช้งานได้จึงต้องสร้างขึ้นบนโครงสร้างพื้นฐานที่เป็นนามธรรมของห่วงโซ่

พื้นที่การแก้ปัญหา

1. วิธีการสร้างโครงสร้างที่เชื่อมโยงโดยใช้จิตวิญญาณจะทำให้เกิดการแยกแยะของโซ่

2. เข้าใจว่าตลาดที่มีจุดประสงค์ใช้งานได้ดีที่สุดเมื่อเครือข่ายแก้ปัญหามีขนาดใหญ่และแข่งขัน

3. การเริ่มต้นเครือข่ายแก้ปัญหาต้องการนำเข้าแอปพลิเคชันเพิ่มเติมที่จะสร้างจุดประสงค์

ข้อเสนอ

1. ทำไมเราต้องมีมาตรฐาน cross-chain intents ที่จำคุกให้ 'solver UX' เพื่อเพิ่มขนาดตลาด solver และ intent ให้มีขนาดใหญ่พอที่จะบรรลุผลกระทบของเครือข่าย

การสร้างแอปพลิเคชันที่ใช้งานได้ไม่สามารถทำได้โดยไม่มีการผสานโซ่

ความสามารถและความฉลาดของเรากำลังสร้างโครงสร้างที่ไม่จำเป็นหรือไม่

Many have lamented that the best crypto engineers and most based thinkers are overallocating attention and energy toward offering more blockspace to end users. This criticism has merit; there are too many L2s available for end users relative to the demand for them.

อย่างไรก็ตาม ฉันปฏิเสธความคิดที่ว่าไม่มีการใช้งานที่มีประโยชน์ใด ๆ สำหรับสกุลเงินดิจิตอล

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

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

1. ความเร็ว: แอปพลิเคชันควรรู้สึกเร็วเหมือนแอปพลิเคชัน web2
2. ต้นทุน: ไม่เหมือนกับ web2 ทุกการกระทำ web3 จำเป็นต้องเกิดค่าใช้จ่ายบางประการ แต่ "ค่าต่อคลิก" ควรเป็นเล็กน้อย
3. ความต้านทานการเซ็นเซอร์ ("การไม่จำเป็น"): ผู้ใดก็ตามที่มีกระเป๋าสตางค์ควรสามารถปฏิสัมพันธ์กับแอปพลิเคชันได้หากพวกเขาสามารถเมาได้
4. ความปลอดภัย: คลิกควรทำตามที่ผู้ใช้คาดหวังและไม่ย้อนกลับ - อัปเดต web3 ทั้งหมดควรเป็นถาวร

นี่คือคุณสมบัติของแอปพลิเคชัน crypto ที่ "ใช้งานได้"

เราพยายามสร้างสกุลเงินดิจิทัลที่ใช้งานได้มานาน

Today’s modular blockchain solutions offer consumers all of these properties, but they are not all available in the same place.

ในปี 2020 บล็อกเชนเป็นแบบโมโนลิทิกซึ่งมอบสองในสามคุณสมบัติสำหรับผู้ใช้สุดท้ายคือ ความเร็ว ค่าใช้จ่าย หรือความปลอดภัย เราจึงมองว่าอนาคตที่เน้น rollup หรือ modularที่จะปลดล็อคทั้งสามคุณสมบัติพร้อมกัน

วันนี้เราได้สร้างพื้นฐานสำหรับโครงสร้างนี้ที่มุ่งเน้นการเก็บเกี่ยวแบบ rollup L2 ให้ blockspace ราคาถูกและเร็ว ซึ่งบางส่วนให้ blockspace ที่ไม่ต้องขออนุญาต ในทวิตราเป็นตรงข้ามกับ L1 ซึ่งให้ blockspace ที่ปลอดภัยจาก WW3 (คุณสามารถอ่านข้อมูลเพิ่มเติมเกี่ยวกับการแลกเปลี่ยนความปลอดภัยและประสบการณ์ของ L1 และ L2 ได้ในบทความสำรวจสั้นของฉัน. พวก L2 เหล่านี้เชื่อมต่อไปยัง L1 อย่างปลอดภัยผ่านเส้นทางข้อความที่เป็นที่ยอมรับ ซึ่งเป็นพื้นฐานสำหรับเครือข่ายที่ modular แต่สามารถทำงานร่วมกันได้ เราได้สร้างเส้นใยแสงระหว่างบล็อกเชนในระยะเวลา 4 ปีที่ผ่านมา ซึ่งในอนาคตจะสนับสนุนแอปพลิเคชันคริปโตที่มีประโยชน์ แต่ทำไมบล็อกเชน modular ถึงขั้นที่ใช้งานไม่ได้?

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

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

วิทัลิคเกี่ยวกับประเภท L2 ที่แตกต่างกัน

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

ดังนั้น การแยกชั้นของเครือข่ายขึ้นอยู่กับความสามารถของผู้ใช้ในการโอนค่าข้ามเครือข่ายอย่างปลอดภัย ราคาถูก และรวดเร็ว ขั้นตอนการใช้งานของผู้ใช้ทั่วไปในปัจจุบันคือผู้ใช้ที่มียอด USDC บนเครือข่าย 'ปลอดภัย' เช่น Ethereum ต้องการสร้าง NFT หรือสว็อปสำหรับเหรียญใหม่บนเครือข่ายที่อัพเดตเช่น Blast หรือ Base วิธีที่ดีที่สุดในการทำเช่นนี้ในขั้นตอนที่น้อยที่สุดคือ การดำเนินการต่อเนื่องของธุรกรรมในรูปแบบ Bridge→Swap→Mint (หรือ Swap→Bridge→Mint)

ในตัวอย่างนี้ จุดประสงค์ของผู้ใช้คือการใช้ USDC ของพวกเขาบนโซ่ที่ปลอดภัยเพื่อสร้าง NFT บนโซ่อื่น ผู้ใช้จะพอใจก็ต่อเมื่อพวกเขาได้รับ NFT และยอด USDC ของพวกเขาถูกหักที่พวกเขาเลือกจัดเก็บ

สถาปัตยกรรมที่ขึ้นอยู่กับความตั้งใจเป็นวิธีเดียวที่จะสร้างการสรรหา

การนามธรรมของเชื่อมโยงขึ้นอยู่กับการโอนค่าข้ามเชน แต่การส่งค่าผ่านเส้นทางข้อความแบบแคนอนิคอลเป็นเรื่องที่แพงหรือช้า “สะพานที่เร็ว” ให้ทางเลือกที่ถูกและเร็วให้กับผู้ใช้เพื่อส่งค่าข้ามเครือข่าย แต่พวกมันให้การสมมติใหม่ไปกับความไว้วางใจ การส่งข้อความเป็นวิธีที่สามารถเข้าใจได้ที่สุดในการสร้างสะพานที่เร็วเพราะมันถูกออกแบบจากสถาปัตยกรรม TCP/IP มันพึงพอใจกับโปรโตคอลสะพานที่เป็นเหมือน TCP Router เพื่อเชื่อมต่อสองเชน

แผนภาพ TCP/IP จาก ResearchGate

การถ่ายโอนมูลค่าผ่านการส่งข้อความเกี่ยวข้องกับโปรโตคอลบริดจ์ที่ส่งข้อความระหว่างสัญญาในห่วงโซ่ต้นทางและปลายทาง ข้อความนี้จะถูกทริกเกอร์ที่ฝั่งต้นทางโดยธุรกรรมของผู้ใช้และส่งต่อไปยังด้านปลายทางเมื่อ "ความถูกต้อง" ของข้อความได้รับการยืนยันแล้ว

ข้อความสามารถตรวจสอบได้หลังจากธุรกรรมห่วงโซ่ต้นทางที่เริ่มต้นข้อความเสร็จสิ้นแล้วซึ่งหมายความว่าธุรกรรมจะรวมอยู่ในบล็อกเชน Canonical ของ Origin Chain อย่างถาวร การตรวจสอบนี้สามารถทําได้เพื่อเป็นหลักฐานความถูกต้องที่พิสูจน์การรวมฉันทามติของธุรกรรมในห่วงโซ่ต้นทางเป็นข้อเสนอในแง่ดีหรือหลังจากเกณฑ์ของลายเซ็นพยานที่ยืนยันการรวมได้สะสมในด้านต้นทาง เมื่อข้อความถูกส่งต่อไปยังสัญญาบริดจ์บนห่วงโซ่ปลายทางโทเค็นจะถูกปล่อยให้กับผู้ใช้

มีปัญหาพื้นฐานหลายอย่างกับโครงสร้างนี้:

1. กลไกการตรวจสอบจะต้องรอคอยจนกระทั่งมีความสมบูรณ์ก่อนที่จะส่งข้อความไปยังสัญญาโปรโตคอลของเชนปลายทาง สิ่งนี้อาจใช้เวลาสูงสุดถึงเจ็ดวันสำหรับ L2s ที่มีช่วงเวลาสมบูรณ์เชื่อมโยง
2. ส่งข้อความ cross-chain หนึ่งครั้งต่อธุรกรรมสะพาน หรือส่งข้อความเป็นชุดรวมกัน แต่ชุดนั้นสามารถส่งได้เพียงหลังจากข้อความสุดท้ายในชุดได้เสร็จ
3. สะพานมีความสามารถจำกัดในการที่จะได้รับ Likuiditi ภายนอกเพื่อเพิ่มประสิทธิภาพของราคาผู้ใช้เนื่องจากจะต้องระบุเส้นทางการปฏิบัติตามความตั้งใจของผู้ใช้

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

ค่าเป็นสิ่งที่สามารถแลกเปลี่ยนได้และไม่ควรสำคัญต่อผู้รับว่ามูลค่าถูกโอนไปอย่างไร แค่ว่าเขาได้รับเงิน

สะพานสามารถนำค่าโอนออกที่จะไปที่เอเยนต์ที่ซับซ้อนเพื่อเพิ่มความเร็วและลดค่าใช้จ่ายได้หรือไม่? Likuiditas เป็นไปได้ทั้ง on และ offchain และการปรับปรุงราคาสามารถที่จะเข้าใจถ้ากลไกสะพานมีความยืดหยุ่นในการเลือกเส้นทางการดำเนินการที่เหมาะสมในเวลาของการโอนของสะพาน

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

ความตั้งใจที่เป็นไปได้ขั้นต่ำคือคำสั่งให้จ่าย X โทเคนจากเชน A เพื่อรับ Y โทเคนบนเชน B

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

โปรโตคอลการชำระเงินตามสมตวัด

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

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

การส่งสารสารสารสารสารสารสารสารสารสารสารสารสารสารสารสารสารสารสารสารสารสารสารสารสารสารสารสารสารสารสารสารสารสารสารสารสารสารสารสารสารสารสารสารสารสารสารสารสารสารสารสารสารสารสารสารสารสารสารสารสารสารสารสารสารสารสารสารสารสารสารสารสารสาร

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

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

แหล่งที่มาของการปรับปรุงราคาขนาดใหญ่มาจากสติปัญญาที่ค่าความสามารถในการแลกเปลี่ยนกับการค้นหาเส้นทางที่ดีที่สุดแบบเร็วๆ นี้จะมีประสิทธิภาพกว่าการโอนค่าใช้จ่าย (อย่างไรก็ตาม บางเส้นทางจะเป็นไปไม่ได้ที่จะเอาชนะต้นทุนแบบเร็วๆ นี้ เช่น เมื่อสะพาน USDC ผ่าน CCTP)

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

เมื่อปฏิบัติตามจุดมุ่งหมายของผู้ใช้ ตัวแทนสามารถที่จะนำเสนอ Likuiditi จากการรวมกันของตลาด Likuiditi บนเชนและออฟเชน และเครือข่ายแก้ปัญหาที่แข่งขันนั้นให้ผู้ใช้มี Likuiditi ที่ไม่จำกัดในทฤษฎี (แต่แม้ว่าแหล่ง Likuiditi เหล่านี้อาจถูกใช้หมดได้เร็วเมื่อมีแนวโน้มของปริมาณไปในทิศทางเดียวระหว่างเหตุการณ์บนเชนที่มีความผันผวนสูง เช่นการเหรา NFT ยอดนิยม การแจกฟรีและการถอดถอนเงินแบบฉลาด)

การส่งคำสั่ง cross-chain ในฐานะเจตนา ช่วยให้ผู้แก้ปัญหา internalize MEV ที่สร้างขึ้นจากคำสั่งเป็นการปรับปรุงราคา

โครงสร้างที่มีแนวคิดเชิงจุลภาคถูกออกแบบให้มีความปลอดภัยในพื้นฐาน

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

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

ดังนั้น การสร้างการมองเส้นจากสถาปัตยกรรมที่มีการวางแผนมา

การยกเลิกว่าการรวมเชือมต้องการการโอนค่าข้ามเชื่อม๠ที่รวดเร็วและถูกกว่า นอกจากนี้ ก็ไม่ควรต้องการผู้ใช้ต้องส่งธุรกรรมบนเครือข่ายที่เงินทรัพย์ของพวกเขาถูกเก็บ

ความตั้งใจของผู้ใช้ไม่จำเป็นต้องส่งในเชนโดยผู้ใช้หากมี Permit2หรือEIP3074สัญญา. นี้เป็นจริงสำหรับสองสถาปัตยกรรมทั้งการส่งข้อความและการสร้างสรรค์ขึ้นจากความตั้งใจ สถาปัตยกรรมสองประเภทสามารถใช้ประโยชน์จากแบบแพทเทิร์น Permit2 เพื่ออนุญาตให้ผู้ใช้ลงลายเซ็นอย่าง offchain จำนวน token ที่พวกเขาพร้อมจะจ่ายจากกระเป๋าสตางค์ในเครือข่ายต้นฉบับของพวกเขา

Intent marketplaces best support chain abstraction because they offer cheap and fast cross-chain value transfer. Imagine a world where a user could request a solver to give them a quote to enter into a WETH staking position on Arbitrum, using their USDC on Optimism as payment. The user could send this intent offchain to an RFQ auction where solvers could bid on it. The winning solver of the auction could then receive the user’s signed intent, containing an allowance to spend their USDC on Optimism, their desired amount of WETH to receive on Arbitrum, and the calldata needed to deposit this WETH into a staking position on Arbitrum. The solver could subsequently submit this transaction on Optimism (on behalf of the user) to initiate the cross-chain intent and pull USDC from the user’s Optimism wallet. Finally, the solver could fill the user’s intent on Arbitrum by sending them WETH and forwarding the calldata to enter the user into the onchain staking position.

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

โครงสร้างการสร้างเจต โดย Across

สําหรับประสบการณ์การใช้งานเคสที่ดีที่สุดเพื่อให้เป็นรูปธรรมจากนามธรรมโซ่ตามเจตนาเราต้องการเครือข่ายนักแก้ปัญหาที่แข่งขันได้

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

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

เราจะใช้วิธีใดในการเริ่มต้นเครือข่ายโซลเวอร์

เราต้องให้ความสำคัญกับผู้ใช้แก้ไข

การเรียกใช้โซลเวอร์ของบุคคลที่มีจุดประสงค์เป็นเรื่องซับซ้อนและต้องการความเชี่ยวชาญในการสร้างซอฟต์แวร์ที่มีประสิทธิภาพสูงรวมถึงการจัดการความเสี่ยงในการคงคลังข้ามเชน โดยธรรมชาติแล้วจะมีฝ่ายที่จำกัดที่สนใจที่จะชำระค่าใช้จ่ายเริ่มต้นเพื่อเรียกใช้โค้ดนี้ ในกรณีที่ดีที่สุด โซลเวอร์ที่เขียนสำหรับ dapp หนึ่ง เช่น โซลเวอร์ UniswapX อาจถูกใช้อีกครั้งเพื่อแก้ปัญหาสำหรับ dapp ผลิตจากจุดประสงค์อื่น เช่น Across และ CowSwap

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

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

คุณค่าของเครือข่ายการตั้งความตั้งใจคือการมอบความปลอดภัยให้แก้ปัญหาซึ่งสามารถมีผลต่อความสามารถในการแก้ปัญหาของผู้แก้ปัญหา

ความเลือกของเครือข่ายการตั้งค่าจะส่งผลต่อความสามารถของผู้แก้ปัญหาที่จะเสนอค่าธรรมเนียมและการรับรองเวลาดำเนินการให้แก่ผู้ใช้ บางเครือข่ายการตั้งค่าอาจเสนอช่วงเวลาของผู้แก้ปัญหาที่เป็นสิทธิพิเศษ ซึ่งจะสนับสนุนการพัฒนาการประมูลออฟเชนที่ผู้แก้ปัญหาและผู้ใช้สามารถต่อรองและทำข้อสัญญาเกี่ยวกับค่าธรรมเนียมการส่งข้อมูล (การประมูลเหล่านี้อาจเสนอการยืนยันล่วงหน้าทางเศรษฐศาสตร์อีกด้วย ซึ่งจะเพิ่มประสิทธิภาพขึ้น หากต้องการเรียนรู้เพิ่มเติมเกี่ยวกับการใช้งานผู้ใช้ที่มีความรู้สึกผ่านการค้นหาผ่านการประมูลและการยืนยันล่วงหน้าฉันขอแนะนำให้ดูที่นี่พูดคุยโดย Karthik ของ Sorella.)

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

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

มันชัดเจนว่าเราต้องการมาตรฐานสำหรับความตั้งใจข้ามโซ่

ถ้าผู้แก้ปัญหาสามารถสมมติว่าจะมีส่วนผสมที่เหมือนกันระหว่างจุดประสงค์ แล้วพวกเขาก็สามารถ reuse โค้ดของพวกเขาเพื่อแก้ไขจุดประสงค์ที่มาจาก dapps ที่แตกต่างกัน และจากนั้นลดต้นทุนในการ setup ของพวกเขา หาก dapps ที่แตกต่างกันสร้างจุดประสงค์ที่เป็นไปตามมาตรฐานเดียวกัน แล้วพวกเขาก็สามารถ route จุดประสงค์ของพวกเขาไปยัง solver pools เดียวกัน นี่จะช่วยในการ onboard รุ่นต่อไปของ dapps โดยการให้พวกเขาสามารถ plug จุดประสงค์ cross-chain ของพวกเขาโดยตรงเข้ากับ existing และ mature solver pool ให้ dapps รุ่นใหม่จะไม่ต้อง onboard ผู้แก้ปัญหาแต่ละคนและแทนที่นั้นจะได้รับการเข้าถึงการโอนค่าที่ถูก และเร็ว ปลอดภัย และไร้การอนุญาต

โปรแกรมติดตามบุคคลที่สาม ยังสามารถติดตามสถานะความตั้งใจของ dapp ใหม่ได้ง่ายขึ้น หากมันเข้ากันได้กับมาตรฐาน

มาตรฐานของความตั้งใจนี้ควรทำให้ผู้ตั้งความตั้งใจหรือผู้แก้ปัญหาระบุว่าต้องการตกลงกับเครือข่ายการตั้งบัญชีใด

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

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

ในการทำงานร่วมกับ Uniswap และจากข้อเสนอจากกลุ่มทำงาน CAKE Across และผมขอแนะนำมาตรฐานความ Absolu ของ Cross-chain ต่อไปนี้โดยให้ความสำคัญกับ UX ของตัวแก้ปัญหา

///@titleประเภท CrossChainOrder

///@noticeโครงสร้างคำสั่งมาตรฐานที่จะถูกเซ็นต์โดยผู้สลับและกระจ散ออกไปยังผู้填充และส่งให้สัญญาการตกลง

struct CrossChainOrder {

@dev ที่อยู่สัญญาที่คําสั่งซื้อนั้นมีไว้เพื่อชําระโดย./// ฟิลเลอร์ส่งคําสั่งนี้ไปยังที่อยู่สัญญานี้ในการตั้งถิ่นฐาน chainaddress ต้นทางสัญญา/// @dev ที่อยู่ของผู้ใช้ที่เริ่มต้นการแลกเปลี่ยน/// ซึ่งโทเค็นอินพุตจะถูกนํามาและ escrowedaddress swapper;/// @dev Nonce เพื่อใช้เป็นการป้องกันการเล่นซ้ําสําหรับ orderuint256 nonce;/// @dev chainId ของต้นทาง chainuint32 originChainId;/// @dev การประทับเวลาที่คําสั่งซื้อต้องเป็น initiateduint32 initiateDeadline;/// @dev การประทับเวลาที่ต้องกรอกคําสั่งซื้อบน chainuint32 ปลายทาง fillDeadline;/// @dev ข้อมูลเฉพาะการใช้งานโดยพลการ/// สามารถใช้เพื่อกําหนดโทเค็น จํานวนเงิน ห่วงโซ่ปลายทาง ค่าธรรมเนียม พารามิเตอร์การชําระเงิน/// หรือข้อมูลเฉพาะประเภทคําสั่งอื่น ๆ bytes orderData;

}

มาตรฐานนี้ออกแบบมาเพื่อทําให้งานของนักแก้ง่ายขึ้น ทางเลือกหนึ่งที่แสดงความคิดเห็นคือการสนับสนุน Permit2 / EIP3074 โดยกําเนิดด้วย nonce และ initiateDeadline และให้การรับประกันบางอย่างแก่ฟิลเลอร์เช่นจํานวนเงินที่พวกเขาจะได้รับคืนจากเครือข่ายการชําระเงินและรูปแบบของความตั้งใจของผู้ใช้ที่พวกเขาสามารถติดตามได้ ยิ่งไปกว่านั้นฟังก์ชันเริ่มต้นถูกกําหนดไว้ในมาตรฐานที่สําคัญช่วยให้ฟิลเลอร์ผู้ที่จะนําคําสั่งซื้อ onchain เพื่อระบุ "fillerData" onchain เพิ่มเติมที่ผู้ใช้จะไม่ทราบในเวลาที่พวกเขาลงนามใน CrossChainOrder สิ่งนี้ช่วยให้ฟิลเลอร์มั่นใจได้ว่าพวกเขาจะได้รับรางวัลจากสัญญาการชําระเงินสําหรับการส่งธุรกรรมเมตาของผู้ใช้และยังตั้งค่าข้อมูลเฉพาะการชําระคืนเช่นห่วงโซ่การชําระคืน

มาตรฐานนี้ยังได้รับการออกแบบมาเพื่อให้ dapps สามารถติดตามสถานะการปฏิบัติตามความตั้งใจได้ง่ายขึ้นตลอดวงจรชีวิต สัญญาการชําระเงินใด ๆ ที่ใช้มาตรฐานนี้ควรสร้างประเภทย่อยที่กําหนดเอง ResolvedCrossChainOrder ที่สามารถแยกวิเคราะห์ได้จากฟิลด์ orderData โดยพลการ ซึ่งอาจรวมถึงข้อมูลเช่นโทเค็นที่เกี่ยวข้องกับการแลกเปลี่ยนห่วงโซ่ปลายทางและข้อ จํากัด การปฏิบัติตามอื่น ๆ ฟังก์ชันการแก้ไขจะรวมอยู่ในมาตรฐานเพื่อให้ dapps เข้าใจวิธีแสดงสถานะเจตนาต่อผู้ใช้และเพื่อให้ผู้แก้ไขทราบโครงสร้างคําสั่งเจตนาที่แน่นอนที่พวกเขากําลังทํางานด้วย

///@titleประเภท ResolvedCrossChainOrder

///@noticeการแสดงอย่างทั่วไปของคำสั่ง

///@devกำหนดความต้องการทั้งหมดสำหรับการเติมลำดับโดยการถอดการได้ที่เป็นพิเศษของข้อมูลลำดับ

///@devตั้งใจที่จะปรับปรุงการรวมรวมโดยอนุญาตให้ผู้เติมคำคำนวณข้อมูลขาเข้าและข้อมูลขาออกที่แน่นอนของลำดับใดๆ

struct ResolvedCrossChainOrder {

/// @dev ที่อยู่สัญญาที่จะใช้ในการตกลงการชำระเงินที่ settlementContract;/// @dev ที่อยู่ของผู้ใช้ที่เริ่มต้นการสลับ address swapper;/// @dev Nonce ที่จะใช้เป็นการป้องกันการทำซ้ำสำหรับคำสั่ง uint256 nonce;/// @dev chainId ของ chain ที่มา uint32 originChainId;/// @dev เวลาที่ต้องเริ่มต้นคำสั่ง uint32 initiateDeadline;/// @dev เวลาที่ต้องเติมคำสั่งใน chain(s) ปลายทาง uint32 fillDeadline;/// @dev ข้อมูลที่จะถูกเอาไปจาก swapper เป็นส่วนหนึ่งของคำสั่งที่ swapperInputs;/// @dev ผลลัพธ์ที่จะได้รับจาก swapper เป็นส่วนหนึ่งของการปฏิบัติตามคำสั่ง Output[] swapperOutputs;/// @dev ผลลัพธ์ที่จะได้รับจาก filler เป็นส่วนหนึ่งของการชำระเงินคำสั่ง Output[] fillerOutputs;

}

/// @noticeโทเค็นที่ส่งโดยผู้สว๊าปเป็นอินพุทสำหรับคำสั่ง

struct Input {

/// @dev ที่อยู่ของโทเค็น ERC20 บนเชนต้นสายที่เกี่ยวข้องที่เกี่ยวข้องโทเค็น;/// @dev จำนวนโทเค็นที่จะส่งuint256 จำนวน;

}

///@noticeโทเค็นที่ต้องได้รับสำหรับคำสั่งที่ถูกต้อง

struct Output {

/// @dev ที่อยู่ของโทเค็น ERC20 บนเชนปลายทาง/// @dev ที่อยู่(0) ใช้เป็น sentinel สำหรับโทเคนเกืบเงินaddress token;/// @dev จำนวนของโทเคนที่ต้องการส่งuint256 amount;/// @dev ที่อยู่ที่จะได้รับโทเคนเอาท์พุตaddress recipient;/// @dev ชุดข้อมูลเชนปลายทางสำหรับเอาท์พุตนี้uint32 chainId;

}

การปฏิบัติตามสัญญาการชำระเงินต้องดำเนินการโดยการปฏิบัติตามอินเทอร์เฟซ ISettlementContract:

///@titleISettlementContract

///@noticeอินเทอร์เฟซมาตรฐานสำหรับสัญญาการชำระเงิน

interface ISettlementContract {

/// @notice เริ่มการตั้งค่าของคำสั่ง cross-chain/// @dev ให้เรียกโดยผู้เติม/// @param คำสั่ง คำนิยาม CrossChainOrder/// @param ลายเซ็นเจเนอร์ ลายเซ็นเจเนอร์ของ swapper สำหรับคำสั่ง/// @param fillerData ข้อมูลที่กำหนดโดย filler ที่จำเป็นโดย settlerfunction initiate(CrossChainOrder order, bytes signature, bytes fillerData) external;/// @notice แก้ไข CrossChainOrder เฉพาะเจาะจงเป็น ResolvedCrossChainOrder ทั่วไป/// @dev ตั้งใจที่จะปรับปรุงการบูรณาการมาตรฐานของ various order types และ settlement contracts/// @param คำสั่ง คำนิยาม CrossChainOrder/// @param fillerData ข้อมูลที่กำหนดโดย filler ที่จำเป็นโดย settler/// @returns ResolvedCrossChainOrder ข้อมูลคำสั่งที่ถูกเติบโตร้อยข้อมูลของการนำเข้าและการนำออกของคำสั่งfunction resolve(CrossChainOrder order, bytes fillerData) external view returns (ResolvedCrossChainOrder);

}

วัตถุประสงค์ในการออกแบบของมาตรฐานนี้คือการเสริมสร้างประสบการณ์ของโซลเวอร์เพื่อทำให้ง่ายต่อการสนับสนุนเครือข่ายการชำระเงินหลายระบบและคำนวณรางวัลของพวกเขาอย่างแน่นอน ฉันเชื่อว่านี้จะช่วยให้พวกเขาสามารถให้ราคาที่แม่นยำและเข้มงวดมากขึ้นกับผู้ใช้ คุณสามารถอ่านรายละเอียดเพิ่มเติมเกี่ยวกับมาตรฐานนี้ชื่อโค้ด ERC7683 ได้ในโพสต์ X/Twitter นี้และการอภิปรายที่เกี่ยวข้องกับมันบนเว็บบอร์ดของ Ethereum Magicians.

คำแนะนำสุดท้าย

“Intents” ทำให้สับสนเพราะไม่ได้ถูกกำหนดไว้ และข้อบกพร่องในประสบการณ์ผู้ใช้จริงๆ ก็เป็นผลมาจากข้อบกพร่องในการกำหนดหรือการนิยาม

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

ในความคิดของฉันวิธีการที่ฉุดลากมากขึ้นสําหรับ dapps ที่มีการไหลของผู้ใช้จํานวนมากอยู่แล้วและสร้างเจตนาของผู้ใช้จํานวนมากจะตกลงที่จะปฏิบัติตามมาตรฐานขั้นต่ําที่ตัวแก้ปัญหาที่มีอยู่จะนํามาใช้ สิ่งนี้จะสร้างกลุ่มตัวแก้ใหม่และใหญ่ขึ้น ด้วยการเข้าถึงกระแสคําสั่งซื้อที่ผสานจากสถานที่ที่โดดเด่นอยู่แล้วกลุ่มตัวแก้ใหม่นี้จะได้รับผลกําไรมากขึ้นและสามารถเสนอราคาที่ดีขึ้นให้กับผู้ใช้ปลายทาง ในที่สุด dapps ที่ใหม่กว่าจะต้องกําหนดเส้นทางความตั้งใจของพวกเขาไปยังกลุ่มตัวแก้นี้และจะสนับสนุนมาตรฐานความตั้งใจ

เพื่อเริ่มต้นให้เรา Kickstarted, Across และ Uniswap ทำงานร่วมกันproposing a standardสำหรับฝ่ายสุนัขบุรุษทั้งหมดที่จะใช้เมื่อจัดการคำสั่งของผู้ใช้เพื่อส่งโทเค็น X จากเชน A และรับโทเค็น Y บนเชน B กระบวนการสั่งที่ผ่าน UniswapX (ที่มีข้อได้เปรียบในการออกของประมูลและต้นแบบจริยธรรม) และ Across (ที่มีข้อได้เปรียบในการชำระการปฏิบัติตามความจงรักภักดี) สามารถผสานและเริ่มกระบวนการสูญเสียของเครือข่ายแก้ปัญหาที่ใหญ่ขึ้นและมีความแข่งขันมากขึ้น

Disclaimer：

1. บทความนี้ถูกพิมพ์ซ้ำจาก [Gateกระจก ], สิทธิ์ในการคัดลอกทั้งหมดเป็นของผู้เขียนเดิม [GateNick Pai]. หากมีข้อขัดแย้งใดๆ เกี่ยวกับการพิมพ์ฉบับนี้ กรุณาติดต่อ Gate Learnทีม และพวกเขาจะดำเนินการโดยเร็ว
2. Liability Disclaimer: ข้อความและความคิดเห็นที่แสดงอยู่ในบทความนี้เป็นเพียงเพียงของผู้เขียนเท่านั้น และไม่เป็นการให้คำแนะนำทางด้านการลงทุนใดๆ
3. การแปลบทความเป็นภาษาอื่น ๆ โดยทีม Gate Learn ถูกทำขึ้น หากไม่ได้กล่าวถึง การคัดลอก การแจกจ่าย หรือการลอกเลียนแบบบทความที่ถูกแปลนั้นถือเป็นการละเมิดกฎหมาย