**คำสัญญาของบล็อกเชนเคยเป็นเพื่อทำให้การเงินและการปรับตัวเข้ากับส่วนรวมสะดวกขึ้น แต่ทุกคนที่เคยลองทำการสลับโทเคนอาจพบบ้างกับ
อินเทอร์เฟซกระเป๋าเงินที่หลากหลาย, โทเคนแก๊สเฉพาะแชน, การคำนวณที่ผิดพลาดในการเก็งกำไร,
และความเสี่ยงที่การทำธุรกรรมจะล้มเหลวและทำนายที่แห่งนำค่าใช้จ่ายของคุณ
การแตกต่างระหว่างความสามารถของบล็อกเชนและการใช้งานที่ง่าย
ยังคงกว้างขวาง.**
เข้าเยี่ยมชมการออกแบบที่เน้นเจตนา ซึ่งเป็นกระบวนทัศน์ที่กำลังเกิดขึ้นใหม่ ที่อาจจะปฏิรูปรูปแบบที่ผู้ใช้โต้ตอบใน Web3 แทนที่จะบังคับให้ผู้ใช้ระบุทุกขั้นตอนในการทำธุรกรรม
-
แชนใด บริการใด ๆ ลำดับของการเรียกสัญญาอัจฉริยะใดที่
-
สถาปัตยกรรมที่เน้นเจตนาให้ผู้ใช้ประกาศเพียง
ว่าต้องการบรรลุอะไร ดูแลที่เหลือทั้งหมด
...
โครงการอย่าง Anoma, SUAVE ของ Flashbots และ CoW Protocol ที่โผล่มาด้วยแนวทางที่ต่างออกไป
...
สถาปัตยกรรมที่เน้นเจตนาเสนอสถานการณ์ที่คล้ายกัน สำหรับบล็อกเชน: จากการโปรแกรมแบบเชิงวิธีการ ("ทำอย่างนี้ แล้วอย่างนี้ แล้วอย่างนี้")
ไปที่การแสดงเจตนาที่ลงมือปฏิุบัติ ("ทำให้สิ่งนี้เกิดขึ้น") บทบาทของ block builder จาก chains ที่มีอยู่ การที่ผู้ใช้ไม่ต้องยื่นธุรกรรมเฉพาะไปยัง chain mempools แต่ละแห่งอีกต่อไป แต่จะยื่นความตั้งใจ - intents - ไปยังการประมูลสากลของ SUAVE ซึ่งสามารถมีตั้งแต่ความตั้งใจที่เรียบง่าย ("แลก A เป็น B") ไปจนถึงความตั้งใจซับซ้อน ("ปรับสมดุลพอร์ตโฟลิโอของฉันข้าม chains เพื่อเพิ่มผลตอบแทนให้สูงสุด")
สถาปัตยกรรมนำเสนอองค์ประกอบใหม่หลายประการ SUAVE ใช้การประมวลผลแบบ confiential ผ่าน Intel SGX เพื่ออนุญาตให้ดำเนินการกับข้อมูลการสั่งซื้อที่ละเอียดอ่อนของผู้ใช้โดยไม่ต้องเปิดเผยข้อมูลให้ผู้ประสงค์ร้าย นี่เป็นการแก้ไขปัญหาพื้นฐาน: ผู้แก้ปัญหาต้องการข้อมูลเพื่อให้การบริหารจัดการมีประสิทธิภาพที่สุด แต่ข้อมูลที่มากเกินไปก็ทำให้เกิดการดึง MEV ได้
Block builders ที่ดำเนินการเพียง chain เดียวเท่านั้นพบว่าตัวเองเสียเปรียบ เนื่องจาก MEV ข้ามโดเมน SUAVE อนุญาตให้ builders จับคุณค่าจากหลาย chains พร้อมกัน ผู้ตรวจสอบพิสูจน์ต์เพิ่มรายได้สูงสุดจาก blockspace ผู้ใช้ทำธุรกรรมอย่างเป็นส่วนตัวด้วยการดำเนินการที่ดีกว่าและค่าใช้จ่ายต่ำ การออกแบบมีเป้าหมายเพื่อป้องกันการรวมศูนย์ที่เกิดจากการดึง MEV ข้าม chains
แผนงานของ SUAVE รวมถึง milestones ของการกระจายอำนาจอย่างค่อยเป็นค่อยไป รุ่นแรกใช้สภาพแวดล้อมการดำเนินงานที่เชื่อถือได้พร้อมกับสมมติฐานเกี่ยวกับ Flashbots ขณะนี้รุ่นต่อมาจะเคลื่อนสู่การดำเนินการที่กระจายอำนาจเต็มที่ โครงการนี้อย่างเปิดเผยเชิญชวนให้ผู้แข่งขันเข้าร่วม โดยยอมรับว่าการกระจายโครงสร้างพื้นฐาน MEV ให้บริการสุขภาพของระบบนิเวศในระยะยาวได้ดีกว่าการที่หน่วยงานเดียวควบคุม
แม้ว่า SUAVE จะมุ่งเน้นที่ความตั้งใจของผู้ค้นหามากกว่าความตั้งใจทั่วไปของผู้ใช้ ในขณะนี้ แต่โครงสร้างพื้นฐานนี้เป็นฐานสำหรับการประยุกต์ใช้แบบฐานความตั้งใจที่กว้างขึ้น เมื่อระบบเติบโตขึ้น มันอาจจะขยายเพื่อจัดการกับประเภทความตั้งใจที่หลากหลายกว่าในการเพิ่มประสิทธิภาพการสั่งซื้อ
CoW Protocol: การซื้อขายที่ใช้ฐานความตั้งใจในทางปฏิบัติ
CoW Protocol เป็นผู้บุกเบิกการซื้อขายที่ใช้ฐานความตั้งใจ ในปี 2021 ทำให้เป็นหนึ่งในนวัตกรรมการใช้งานการผลิตที่เก่าแก่ที่สุดของแนวคิดเหล่านี้ ชื่อของโปรโตคอลนี้อ้างอิงถึง "Coincidence of Wants" – แนวคิดทางเศรษฐศาสตร์ที่ว่าทั้งสองฝ่ายต้องการสินค้าของกันและกันและสามารถแลกเปลี่ยนได้โดยตรงโดยไม่ต้องผ่านตัวกลาง
CoW Protocol ทำงานโดยการรวบรวมการค้าตลอดเวลามาเป็นชุด ผู้ใช้ลงนามคำสั่งนอก chain แสดงความต้องการในการค้าของพวกเขา: สินค้าที่ต้องการ ช่วงราคาที่รับได้ เวลาจำกัด ความตั้งใจเหล่านี้จะถูกส่งไปยังเครือข่ายของผู้แก้ปัญหาซึ่งแข่งขันในประมูลเพื่อให้การดำเนินการที่ดีที่สุดสำหรับชุดการค้านั้นทั้งหมด
ผู้แก้ปัญหาสามารถทำให้ความตั้งใจสมบูรณ์ด้วยวิธีการหลายๆ แบบ:
- การจับคู่ตรง: เมื่อผู้ใช้สองรายต้องการการค้าตรงข้าม ผู้แก้ปัญหาจับคู่พวกเขาแบบ peer-to-peer โดยไม่ใช้ on-chain liquidity
- การค้ารูปแหวน: การค้ารูปหลายฝ่ายแบบวงกลมที่เพิ่มประสิทธิภาพตามความตั้งใจหลายอย่างที่เกิดขึ้นพร้อมกัน
- การคัดแยก DEX: การกำหนดเส้นทางผ่าน AMM ที่มีอยู่รวมถึงแหล่งสภาพคล่อง
- ผู้ผลิตตลาดเอกชน: การใช้สภาพคล่องนอก chain เมื่อมีกำไร
กลไกการประมูลชุดช่วยป้องกัน MEV แบบธรรมชาติ ธุรกรรมทั้งหมดภายในชุดถูกดำเนินการที่ราคาประมูลที่เหมือนกัน กำจัดพลวัตรแรกมาแรกได้ที่ช่วยให้เกิด front-running ผู้แก้ปัญหาแบกรับค่าแก๊ส ผู้ใช้ไม่ต้องจ่ายค่าธรรมเนียมใด ๆ หากธุรกรรมไม่ตรงกับที่กำหนดไว้
CoW Swap ได้ดำเนินการในการค้ามากกว่า $30 พันล้าน ประหยัดเงินให้ผู้ใช้มากกว่า $82 ล้านในส่วนเกินผ่านการดำเนินการที่เหมาะสมที่สุด และเติบโตจนมีส่วนแบ่งตลาดถึง 63% ในกลุ่มผู้คัดเลือก DEX ที่ใช้ฐานความตั้งใจ โปรโตคอลนี้แสดงให้เห็นว่าสถาปัตยกรรมที่ใช้ฐานความตั้งใจสามารถทำงานได้ในระดับใหญ่ในวันนี้ ไม่เพียงแต่ในระบบอนาคต
โครงการน่าจดจำอื่นๆ
โครงการอื่นๆ หลายโครงการมีส่วนร่วมในระบบนิเวศที่ใช้ความตั้งใจเป็นฐาน:
- Essential: การสร้างโปรโตคอลเฉพาะความตั้งใจจากพื้นฐาน ซึ่งไม่มีธุรกรรมที่ผู้ใช้ส่งเข้า – มีเพียงโซลูชันความตั้งใจที่รวบรวมเท่านั้น
- UniswapX: การกำหนดเส้นทางที่ใช้ฐานความตั้งใจของ Uniswap โดยใช้การประมูลแบบ Dutch และเครือข่ายผู้เติมเต็ม พร้อมคุณสมบัติข้าม chain จะเปิดตัวในปี 2024-2025
- Across Protocol: การเสนอแนวทางมาตรฐานสำหรับการข้าม chain ที่เข้ากันได้กับความตั้งใจ ร่วมกับ UniswapX
- 1inch Fusion: การกำหนดเส้นทางการแลกเปลี่ยนที่ใช้ฐานความตั้งใจจากผู้คัดเลือก DEX ที่ตั้ง
- DappOS: โครงสร้างพื้นฐานสำหรับการโต้ตอบกับแอพพลิเคชั่นที่ใช้ความตั้งใจ รวมถึงสินค้าความตั้งใจและการดำเนินการความตั้งใจ
โครงการเหล่านี้แบ่งปันรูปแบบทางเทคนิคทั่วไป: การกระจายความตั้งใจออกจาก chain การโต้แย้งโครงข่ายผู้แก้ปัญหาที่แข่งขัน การตรวจสอบการทำธุรกรรมบน chain และการประสานข้าม chain ความหลากหลายในการกำหนดแนวทางแสดงให้เห็นว่าเงื่อนไขในพื้นที่นี้ยังคงสำรวจว่าเลือกแบบใดของสถาปัตยกรรมมีประสิทธิภาพมากที่สุด
ทำไมสถาปัตยกรรมที่ใช้ความตั้งใจจึงสำคัญ
การออกแบบที่ใช้ความตั้งใจแก้ไขปัญหาพื้นฐานหลายประการที่รบกวนการนำ Web3 มาใช้และประสิทธิภาพ ประโยชน์ครอบคลุมประสบการณ์ของผู้ใช้ การเพิ่มประสิทธิภาพทางเศรษฐกิจ และความยืดหยุ่นของระบบ
ปรับปรุงประสบการณ์ของผู้ใช้ได้อย่างมาก
ประโยชน์ที่เห็นได้ทันทีคือการทำให้การเดินทางของผู้ใช้เรียบง่ายอย่างมาก ระบบ Web3 ปัจจุบันซับซ้อนและมีอุปสรรคในการเข้าสู่ ผู้ใช้ต้องเดินทางผ่านโครงสร้างพื้นฐานที่กระจัดกระจาย ผู้ใช้ที่ต้องการเข้าร่วม DeFi ข้าม chains มีความซับซ้อนมหาศาล: การจัดการกระเป๋าเดือนที่หลากหลาย การมี token gas ที่หลากหลาย การทำความเข้าใจกับอินเทอร์เฟซที่มีเฉพาะโปรโตคอล การตรวจสอบการกำหนดเวลาที่เหมาะสมที่สุด และความกังวลเกี่ยวกับการถูกหาประโยชน์ MEV
ระบบที่ใช้ความตั้งใจทำให้ความซับซ้อนเหล่านี้หายไป ผู้ใช้ระบุผลลัพธ์ที่ต้องการในแง่ธรรมชาติ ระบบสามารถใช้ AI แปลภาษาแบบง่าย ๆ เป็นความตั้งใจที่เป็นโครงสร้าง: "ฉันต้องการปรับสมดุลพอร์ตโฟลิโอให้เป็น 60% ETH, 30% stablecoins, 10% LINK" กลายเป็นความตั้งใจที่มีโครงสร้างที่มีผู้แก้ปัญหาจะดำเนินการอัตโนมัติ
การยกเว้นนี้มีประโยชน์ทางพิเศษสำหรับผู้ใช้น้อย ผู้ใช้ DeFi เฉลี่ยในปัจจุบันต้องดิ้นรนที่จะเข้าถึงประเภทการดำเนินการและการตั้งราคา ที่จะใช้ได้เฉพาะกับบริษัทที่มีทุนสูงที่มีทีมงานเทคนิคภายใน สถาปัตยกรรมที่ใช้ฐานความตั้งใจทำให้การเข้าถึงการดำเนินการระดับสูงของสถาบันเป็นไปได้น้อยค่าลง
ธุรกรรมที่ล้มเหลวไม่ได้มีค่าใช้จ่ายอะไรในแก๊สในระบบความตั้งใจ – ผู้แก้ปัญหารับค่าใช้จ่ายเหล่านั้น ผู้ใช้ไม่จำเป็นต้องถือ token gas หลายช่องโซลเลอร์จะเก็บค่าธรรมเนียมใน token ที่จะถูกแลกเปลี่ยน การควบคุมรายละเอียดทางเทคนิคลดลง ในขณะเดียวกันความมั่นใจในความเป็นไปได้ในการดำเนินการที่เหมาะสมเพิ่มขึ้น
การลดลงของ MEV และการฟื้นค่าของระบบ
Miner/Maximal Extractable Value แสดงให้เห็นถึงค่าพันล้านที่ถูกดึงจากผู้ใช้ blockchain ประจำปี โมเดลการทำธุรกรรมเก่าเปิดเผยผู้ใช้ต่อหน้าใช้แซนด์วิชและรูปแบบการดึงอื่น ๆ ห้องสมุดสาธารณะเผยแพร่ความตั้งใจของผู้ใช้ก่อการำนวณการใช้ก่อนการใช้ให้ตัวแสดงที่เชี่ยวชาญ
สถาปัตยกรรมที่ใช้ฐานความตั้งใจเปลี่ยนแปลงพลวัตรเหล่านี้ได้พื้นพุ่ม เนื่องจากผู้ใช้ลงชื่อความตั้งใจไม่ใช่ธุรกรรมที่สามารถประมวลผลได้ แถมยังไม่สามารถดำเนำการก่อนที่ความตั้งใจอีกต่อไป ผู้แก้ปัญหาแข่งขันในการทำให้ผลลัพธ์ที่ดีที่สุดของสถานะที่ลงนามสำเร็จ แต่การเส้นทางการดำเนินงานยังยืดหยุ่นด้วยการนี้ก็จะไม่มีการเรียกความตั้งใจที่ระบุได้ MEV
กลไกการประมูลชุดเช่นที่ใช้โดย CoW Protocol สร้างคำสั่งซื้อในช่วงเวลาหนึ่ง ลดโอกาสในการดึง MEV เมื่อการค้าหลายรายการถูกดำเนินการพร้อมกันด้วยราคาที่สะพานพอการใช้จะหายไป วิถีทางที่เกิดขึ้นก็จะถูกยุติตรงนี้ในเครือข่ายผู้แก้ปัญหาที่แข่งขัน ไม่ใช่ออกไปกับผู้แสดงที่ประสงค์ร้าย
สุที่สำคัญ ระบบความตั้งใจไม่ทำให้ MEV หายไปโดยสมบูรณ์ – พวกเขาเปลี่ยนจากการดึงมากเป็นการเพิ่มคุณค่า ผู้แก้ปัญหาในโครงข่ายที่แข่งขันจะเสนอค่ากลับไปยังผู้ใช้ มากกว่าการเรียกค่าดังกล่าว เกณฑ์สำหรับการชนะเกามาเป็นการเพิ่มพอใจของผู้ใช้มากกว่าที่จะหาประโยชน์จากความไม่เท่าเทียมด้านข้อมูล
การทำงานร่วมกันข้าม chain และการผสมผสาน
บางทีผลกระทบที่ลึกซึ้งที่สุดมาจากวิธีที่การออกแบบที่ใช้ความตั้งใจจัดการกับความเป็นจริงที่มีหลาย chain ของ Web3 ในปัจจุบัน ระบบสิ่งแวดล้อมนี้ถูกแตกกระจายไปทั่ว Layer 1s, Layer 2s, และ sidechains แต่ละอันมีความลื่นใน liquidity และฐานผู้ใช้งาน การเคลื่อนย้ายค่าว่าผ่าน chain จึงต้องการสะพาน สินค้าห่อด้วยความและสมมติฐานความไว้วางใจที่ซับซ้อนระดับมาก
สถาปัตยกรรมที่ใช้ความตั้งใจทำให้เกิดความสามารถในการใช้ซ้ำได้อย่างง่ายดายที่ตัวความตั้งใจแทนที่ระดับการดำเนินงาน รวมสถานะที่ multiple chains ในขณะเดียวกัน ผู้ใช้เผยแพร่ความต้องการโดยไม่ต้องระบุว่า chain ใดที่จะดำเนินการ ผู้แก้ปัญหาตัดสินใจว่าสถานที่ที่ดีที่สุดสำหรับการดำเนินงานเป็นไปอย่างไร อาจแบ่งคำสั่งซื้อมาก ๆ ไปกับ chain หลายที่หรือกำหนดเส้นทางผ่านสถานที่ใด ๆ ที่มี liquidity ที่ดีที่สุดในขณะนั้น
การยกเว้นนี้เป็นประโยชน์กับนักพัฒนามากพอ ๆ กับผู้ใช้ แทนที่จะกำหนดการตั้งรากแอปพลิเคชันเฉพาะ chain และการจัดการกับซีกันข้าม chain นักพัฒนาสามารถเขียนแอปพลิเคชันโดยยึดความตั้งใจที่เป็นศูนย์กลางได้Applications become truly portable, following liquidity and users, instead of being tied to specific chains.
Intent layers can aggregate liquidity across all connected domains, addressing the chicken-and-egg dilemma where new chains struggle to build usage due to lack of liquidity. If users and solvers participate in a unified intent network, liquidity fragmentation becomes less vital, with orders flowing to where they can be optimally filled.
Capital Efficiency and Innovation
Intent-based models foster new forms of capital efficiency. When solvers use their own inventory for trades, capital no longer sits idle in liquidity pools. Professional market makers provide liquidity dynamically, deploying capital only when profitable opportunities appear.
The system unlocks use cases unfeasible in traditional transaction models. Complex multi-party coordination is feasible when expressing outcomes rather than choreographing exact execution sequences. Applications impractical due to high gas costs or coordination complexity become feasible as intent networks handle execution details efficiently.
Transition: From Smart Contracts to Intent Layers
Understanding the position of intent-centric design in blockchain's evolution provides perspective on its significance and trajectory.
The Evolution of Web Architectures
Web1 was read-only: static pages from centralized servers. Users consumed content but rarely contributed. The architecture mirrored this passivity – simple HTML pages with minimal interactivity.
Web2 introduced user-generated content and dynamic applications but kept centralized control. Platforms like Facebook and Google enabled participation while capturing data and value centrally, creating the surveillance capitalism model Web3 aims to disrupt.
Web3’s first generation, exemplified by Bitcoin, introduced scriptable settlements. Users could program money with basic logic, but the scripting language was limited. Bitcoin proved blockchains could work but offered limited expressiveness.
Ethereum pioneered second-generation architecture with fully programmable settlements. The EVM enabled arbitrary computation, spawning numerous applications: tokens, DAOs, DeFi protocols, NFT marketplaces. But this programmability added complexity. Users, de facto programmers, composed transactions from smart contract calls.
As applications grew sophisticated, the limitations of Gen 2 architectures became evident. Complex applications like NFT marketplaces and orderbook DEXes needed centralized components for counterparty discovery and optimization – functions the blockchain didn't provide efficiently. Gen 2.5 architectures function but compromise on decentralization.
Third-generation intent-centric architectures aim for end-to-end decentralization for arbitrary application types. By making intents the fundamental primitive, these systems offer generalized intent completion, counterparty discovery, solving, and settlement – all applications need without forcing them into blockchain-centric designs.
Developer Changes
The shift to intent-centric architectures fundamentally changes the developer experience. Today’s blockchain developers must:
- Master several programming languages (Solidity, Rust, Move)
- Understand each chain's specific quirks and gas models
- Build custom bridges and cross-chain messaging
- Implement their own MEV protection
- Handle edge cases around chain reorganizations
- Optimize for costly on-chain computation
Intent-centric development abstracts many concerns. Developers define intent languages – the vocabulary applications understand. The underlying infrastructure handles execution details. Applications become portable by default, without needing separate implementations per chain.
This mirrors previous transitions in software development. Developers once manually managed memory allocation; now garbage collectors handle it. Developers once wrote platform-specific code; now frameworks provide cross-platform abstractions. Intent-centric design brings similar abstraction to blockchain development.
The transition won’t happen overnight. Existing smart contracts represent substantial investment and network effects. Migration paths must exist for current applications to gradually incorporate intent-based interactions. Hybrid architectures will likely dominate the transition period, with intent layers wrapping traditional transaction systems.
Infrastructure Changes
The infrastructure layer shifts from chains competing for applications to solver networks vying for order flow. Chains become settlement layers rather than execution environments. The valuable real estate moves up to intent orchestration and solver networks.
This redistribution of value and power has extensive implications. MEV searchers could become solvers, using similar skills in a value-positive, rather than value-extractive, context. Liquidity providers might operate differently, offering just-in-time liquidity instead of parking capital in pools. Validators’ role becomes verifying intent fulfillment, not ordering transactions.
New infrastructure needs emerge: intent gossip networks, solver reputation systems, constraint satisfaction engines, cross-chain settlement protocols. The ecosystem requires standards for expressing intents, allowing different systems to interoperate. Without these standards, the space risks fragmenting into incompatible intent silos.
Possible Risks and Trade-Offs
Like any architectural shift, intent-centric design introduces new attack vectors, centralization risks, and unintended consequences alongside its benefits.
Solver Centralization
The most significant risk involves solver network centralization. Operating competitive solver infrastructure requires sophisticated technical capabilities and significant capital. Solvers must manage multiple chains' inventories, run complex optimization algorithms, manage gas costs, and respond swiftly.
These requirements create entry barriers. If only a few entities can effectively solve intents, the system reintroduces centralization. A few dominant solvers might collude for suboptimal execution, extracting value similarly to how MEV bots exploit systems. Users gain simplified interfaces but lose blockchain’s decentralization.
Some protocols initially use permissioned solver networks, requiring whitelisting to participate. This ensures execution quality but contradicts Web3's permissionless ethos. The challenge is designing mechanisms for quality while allowing open participation.
Reputation systems, stake requirements, and slashing mechanisms might mitigate these risks. Solvers could post bonds that slash upon detected misconduct. Users could monitor solver performance publicly, routing intents to trustworthy operators. But these add complexity and might not solve centralization fully.
Privacy Concerns
Publicly expressing intents risks information leakage. Broadcasting large trade intentions reveals strategies, allowing solvers or observers to front-run at the intent level, not the transaction level. While intents provide protection through competitive solving, they don’t eliminate information asymmetry.
SUAVE addresses this with trusted execution environments, introducing security assumptions around Intel SGX and similar hardware. Cryptographic approaches like zero-knowledge proofs offer stronger privacy but with significant computational overhead.
The design space involves difficult tradeoffs. Solvers need information for optimal execution, but too much information enables exploitation. Finding the right balance is an open research question, with no clear winning solution yet.
Implementation Complexity and Latency
Building intent-centric systems involves substantial technical complexity. Efficient intent matching across potentially millions of users requires sophisticated algorithms. Cross-chain settlement introduces coordination challenges and latency. Ensuring atomic execution when multiple chains are involved demands careful protocol design.
These complexities can introduce failure modes. What happens when optimal solving takes longer than users tolerate? How do systems handle partial fulfillment?ผู้ใช้งานควรทำอย่างไรเมื่อเจตนาหมดอายุโดยไม่ประสบความสำเร็จ? ระบบการทำธุรกรรมแบบดั้งเดิมให้ผลลัพธ์ที่คาดเดาได้; ขณะที่ระบบเจตนาเพิ่มความไม่แน่นอนเกี่ยวกับว่าจะเกิดการดำเนินการหรือไม่และอย่างไร
ปัญหาการทำมาตรฐานซับซ้อนขยายอุปสรรคทางเทคนิคเหล่านี้ หากไม่มีรูปแบบการแสดงเจตนาที่เป็นกลาง ระบบต่าง ๆ ไม่สามารถทำงานร่วมกันได้ แต่การทำมาตรฐานก่อนเวลาอาจล็อกการออกแบบที่ไม่เหมาะสม ระบบนิเวศจึงต้องสมดุลระหว่างการเคลื่อนย้ายอย่างรวดเร็วและการสร้างฐานรากที่แข็งแกร่ง
มรดกและการย้ายข้อมูลสมาร์ทคอนแทรค
ระบบนิเวศ Web3 ที่มีอยู่มีมูลค่าหลายพันล้านที่ถูกล็อกในสมาร์ทคอนแทรคที่สร้างขึ้นบนโมเดลการทำธุรกรรม สัญญาเหล่านี้ไม่สามารถเขียนใหม่ได้ชั่วข้ามคืน จะต้องมีเส้นทางการย้ายสำหรับการนำเสนอเป็นกรอบทางเจตนาอย่างค่อยเป็นค่อยไป
สถาปัตยกรรมไฮบริดที่มีชั้นเจตนาห่อหุ้มสัญญาที่มีอยู่ เป็นวิธีแก้ไขหนึ่ง แต่เพิ่มความซับซ้อน นักพัฒนาต้องเรียนรู้แนวคิดใหม่ ๆ ขณะเดียวกันรักษาระบบเก่า ผู้ใช้เผชิญกับความสับสนว่าแอปพลิเคชันใดรองรับโมเดลการโต้ตอบใดซึ่งทำให้เกิดช่วงการเปลี่ยนที่กระจายตัวมากกว่าสามัคคี
การศึกษาของนักพัฒนายังเป็นปัญหาอีกประการหนึ่ง การเปลี่ยนแปลงโมเดลทางความคิดจากการเขียนโปรแกรมการทำธุรกรรมตามคำสั่งไปสู่การแสดงเจตนาเฉพาะเป็นสิ่งที่สำคัญ นักพัฒนาบล็อกเชนปัจจุบันมีความเชี่ยวชาญลึกซึ้งในภาษาและรูปแบบเฉพาะ; การฝึกอบรมใหม่ต้องใช้เวลา มหาวิทยาลัยและบูตแคมป์เพิ่งเริ่มต้นสอน Solidity การพัฒนาตามเจตนาเพิ่มเส้นโค้งการเรียนรู้เพิ่มเติม
การรับผิดชอบและการชดเชย
ระบบการทำธุรกรรมให้การรับผิดชอบที่ชัดเจน หากธุรกรรมของคุณล้มเหลวหรือทำงานไม่คาดคิด คุณสามารถตรวจสอบลำดับการทำงานที่แน่นอนได้ ระบบตามเจตนาซ่อนการดำเนินการ ทำให้ยากต่อการเข้าใจสิ่งที่ผิดพลาดเมื่อผลลัพธ์ไม่ตรงกับความคาดหวัง
ใครรับผิดชอบเมื่อผู้แก้ไขให้การดำเนินการที่ไม่เหมาะสม? ผู้ใช้งานมีการชดเชยอะไร? พวกเขาจะพิสูจน์ได้อย่างไรว่าผู้แก้ไขทำผิดไม่เป็นธรรมแทนที่จะเป็นข้อผิดพลาดซื่อสัตย์? คำถามเหล่านี้ขาดคำตอบที่ชัดเจนในหลาย ๆ การออกแบบในปัจจุบัน การสร้างเฟรมเวิร์คสำหรับความรับผิดชอบของระบบตามเจตนายังคงเป็นสิ่งสำคัญสำหรับการปกป้องผู้ใช้
รายการตรวจสอบก่อนเปิดตัวโทเค็นสำหรับโครงการตามเจตนา
ทีมที่เตรียมเปิดตัวโทเค็นในระบบตามเจตนาเผชิญกับการพิจารณาเฉพาะที่เกินกว่าการเตรียมการเปิดตัวโทเค็นทั่วไป โครงการเหล่านี้ต้องจัดตำแหน่งโทเคโนมิกส์กับพลวัตของเครือข่ายผู้แก้ไขพื้นฐานและกลไกการจับคู่เจตนา
กำหนดภาษาคำร้องที่ชัดเจนและโปรโตคอล
โครงการตามเจตนาที่ประสบความสำเร็จต้องการมาตรฐานการแสดงเจตนาที่ชัดเจน ทีมควร:
บันทึกสคริปต์เจตนาอย่างละเอียด: ระบุตัวแบบของเจตนาที่ระบบสนับสนุนอย่างแน่ชัด ว่าผู้ใช้แสดงข้อจำกัดอย่างไร พารามิเตอร์ใดที่จำเป็นและไม่จำเป็น ภาษาคำร้องต้องแสดงถึงความพึงพอใจของผู้ใช้ได้อย่างคล่องตัวพอสมควร ในขณะที่ยังคงความสามารถในการประมวลผลโดยเครือข่ายผู้แก้ไข
ให้ชุดพัฒนาและเครื่องมือสำหรับนักพัฒนา: การสร้างแอปพลิเคชันในระบบตามเจตนาต้องการเครื่องมือที่แตกต่างจากการพัฒนาตามธุรกรรม การมีเอกสารชัดเจน ตัวอย่างโค้ด และเฟรมเวิร์คทดสอบช่วยลดอุปสรรคต่อการนำไปใช้
พิจารณาความยืดหยุ่นในอนาคต: ภาษาคำร้องควรสนับสนุนการวิวัฒนาการ เจตนาใหม่จะเกิดขึ้น มาตรฐานควรรองรับไม่ทำลายการใช้งานเดิม โครงร่างเวอร์ชันและนโยบายหยุดใช้เป็นสิ่งสำคัญ
สร้างหรือเป็นพันธมิตรสำหรับโครงสร้างพื้นฐาน Solver
เครือข่าย Solver เป็นกระดูกสันหลังสำหรับการดำเนินการในระบบตามเจตนา โครงการโทเค็นต้องแน่ใจว่ามีศักยภาพในการแก้ไขที่แข็งแกร่ง:
เริ่มต้นการร่วมมือกับ Solver แรกเริ่ม: การเริ่มต้นต้องการ Solver เพียงพอเพื่อให้การดำเนินการแข็งขัน ทีมอาจต้องเริ่มต้น Solver เอง ให้เงินสนับสนุนแก่ผู้เข้าร่วมเริ่มต้น หรือเป็นพันธมิตรกับผู้ดำเนินการ Solver จากโปรโตคอลอื่น
ออกแบบกลไกจูงใจ Solver อย่างรอบคอบ: Solvers จำเป็นต้องได้รับการชดเชยที่ครอบคลุมค่าใช้จ่าย ขณะเดียวกันกระตุ้นผลลัพธ์ที่เหมาะสมสำหรับผู้ใช้ เศรษฐศาสตร์โทเค็นควรจูงใจพฤติกรรมที่ดีของ Solver – การให้ส่วนเกินของผู้ใช้ – ขณะลงโทษหรือกีดกันผู้กระทำผิด
หลีกเลี่ยงการผูกขาด Solver โดยการออกแบบ: มีกลยุทธ์หลายแบบที่ส่งเสริมการกระจาย Solver การลดอุปสรรคในการเข้าโดยลดความต้องการเงินทุนซึ่งเป็นสิ่งจำเป็น การออกแบบระบบชื่อเสียงที่ให้ Solver ใหม่สร้างความน่าเชื่อถืออย่างค่อยเป็นค่อยไป พิจารณารูปแบบการแก้ไขที่มอบหมายให้ Solver มีความเชี่ยวชาญแทนที่จะให้ทุกอย่างจัดการทั้งหมด
วางแผนการจับคู่ Solver ที่ทำงานข้ามเครือข่าย: หากโปรโตคอลเกี่ยวข้องกับเจตนาข้ามเครือข่าย Solver จำเป็นต้องมีการทำงานร่วมกันข้ามโดเมน กำหนดวิธีการคิดค่าชดเชย การรับค่าใช้จ่ายการเชื่อมท่อใคร และวิธีการแก้ไขข้อพิพาท
ตรวจสอบตรรกะการจับคู่เจตนา-Solver
แกนหลักของระบบตามเจตนาคือการจับคู่เจตนากับศักยภาพ Solver ก่อนการเปิดตัวโทเค็น:
ทดสอบความปลอดภัยอย่างละเอียด: ตรรกะการจับคู่เจตนาต้องไร้ข้อผิดพลาด บั๊กอาจเปิดโอกาสให้ Solver สกัดมูลค่าอย่างไม่ยุติธรรมหรือทิ้งเจตนาไม่สำเร็จ ดึงหลายบริษัทตรวจสอบที่มีประสบการณ์ในด้านการออกแบบกลไก ไม่เพียงแค่ความปลอดภัยของสมาร์ทคอนแทรค
ทดสอบการรับภาระของอัลกอริทึมจับคู่: จำลองสถานการณ์ที่มีภาระสูง เกิดอะไรขึ้นเมื่อมีเจตนาเป็นพันๆ เข้ามาพร้อมกัน? ระบบมีวิธีการลดการทำงานที่แย่ลงอย่างไรภายใต้โหลดอยู่สูง? จุดที่เป็นคอขวดที่ไหน?
ตรวจสอบความเข้ากันได้ของแรงจูงใจ: ทฤษฎีเกมมีความสำคัญอย่างมาก ยืนยันว่า Solver ไม่สามารถได้รับผลประโยชน์จากการเบี่ยงเบนจากความประพฤติซื่อสัตย์ ตรวจสอบว่าแคลคูลัสของ Nash ตรงกับผลลัพธ์ที่ต้องการ พิจารณาบล็อกการโจมตีที่ตัวแก้ไขอาจร่วมมือกันแสวงประโยชน์จากผู้ใช้
ให้ความสำคัญกับการทดสอบประสบการณ์ผู้ใช้
วัตถุประสงค์ของการออกแบบตามเจตนาคือการปรับปรุงประสบการณ์ผู้ใช้ ยืนยันดังนี้ก่อนการเปิดตัว:
ทดสอบกับผู้ใช้ที่ไม่มีพื้นฐานด้านเทคนิค: พลองอินเตอร์เฟซในหน้าผู้ที่ไม่คุ้นเคยกับความซับซ้อนของบล็อกเชน พวกเขาสามารถเข้าใจความหมายของเจตนาได้หรือไม่? พวกเขาวางใจในระบบว่าจะดำเนินการตามต้องการหรือไม่? พวกเขาสับสนที่ไหน?
เปรียบเทียบกับทางเลือกแบบดั้งเดิม: เปรียบเทียบประสบการณ์ตามเจตนากับธุรกรรมเทียบเท่า เป็นอย่างไรที่จริง ๆ แล้วง่ายขึ้น? ผลลัพธ์ดีขึ้นอย่างสม่ำเสมอหรือไม่? บันทึกการปรับปรุงเฉพาะอย่างเฉพาะเจาะจง
ออกแบบกลไกป้อนกลับที่ชัดเจน: ผู้ใช้จำเป็นต้องเข้าใจว่าเกิดอะไรขึ้นกับเจตนาของพวกเขา ให้สถานะปรับปรุง: เจตนาได้รับแล้ว ตัวแก้ไขกำลังแข่งขัน การดำเนินการที่เสนอ การชำระเงินได้รับการยืนยัน ข้อมูลป้อนแบบไม่ชัดเจนทำให้ความไว้วางใจลดลง
เตรียมพร้อมสำหรับสถานการณ์ขอบ: ผู้ใช้เห็นอะไรเมื่อเจตนาไม่สามารถสำเร็จได้? พวกเขาจะปรับหรือยกเลิกเจตนาได้อย่างไร? เกิดอะไรขึ้นในช่วงความแออัดของเครือข่าย? ปรับปรุงประสบการณ์เหล่านี้อย่างละเอียด
จัดตั้งเส้นทางการปกครองและการกระจายอำนาจ
การปกครองโทเค็นควรตรงกับหลักการของการเจตนา:
กำหนดกลไกการอัปเกรด: โปรโตคอลเจตนาจะวิวัฒนาการ กำหนดกระบวนการที่ชัดเจนในการเสนอ การทดสอบ และการปรับใช้การเปลี่ยนแปลง สมดุลการทำซ้ำอย่างรวดเร็วกับความเสถียรที่เครือข่ายต้องการ
วางแผนการมีส่วนร่วมในการปกครองของ Solver: Solver ควรมีสิทธิ์การปกครองพิเศษหรือไม่? โปรโตคอลจะป้องกันการจับจากกลุ่ม Solver เช่นไร? พิจารณาว่าการมีส่วนร่วมของ Solver ต้องถือครองโทเค็นและสิ่งนั้นมีความหมายสำหรับความเสี่ยงจากการรวมศูนย์
แผนภูมิการกระจายอำนาจแบบก้าวหน้า: โครงการส่วนใหญ่เปิดตัวด้วยส่วนกลางบางส่วนด้วยเหตุผลเชิงพฤติกรรม จัดทำเอกสารเส้นทางสู่การกระจายอำนาจเต็มรูปแบบอย่างชัดเจน มีเหตุการณ์สำคัญใดที่เป็นการเปลี่ยนผ่าน? อะไรจะเป็นสิ่งกระตุ้นการย้ายการควบคุม?
ความโปร่งใสในโทเคโนมิกส์: ผู้ใช้และ Solver จำเป็นต้องมีความเชื่อมั่นในเศรษฐศาสตร์โทเค็น เผยแพร่เอกสารที่ชัดเจนเกี่ยวกับการชดเชย การประกาศใช้ การใช้คลัง และกลไกการเพิ่มมูลค่า หลีกเลี่ยงความประหลาดใจที่ทำลายความไว้วางใจ
การันตีความเข้ากันได้ระหว่างโปรโตคอล
ระบบนิเวศตามเจตนาได้รับประโยชน์จากผลเครือข่าย การแยกโปรโตคอลของคุณจะจำกัดมูลค่า:
สนับสนุนมาตรฐานเจตนาที่เกิดขึ้นใหม่: เข้าร่วมในการพัฒนามาตรฐานเจตนาข้ามสาย นำเสนอ ERC ที่เกี่ยวกับการแสดงเจตนาที่ได้นำเสนอ ทำให้การบูรณาการกับโปรโตคอลอื่นเป็นเรื่องง่าย
สร้างสถาปัตยกรรมโมดูลาร์: หลีกเลี่ยงการล็อกผู้จำหน่ายด้วยการรักษาชิ้นส่วนแยกต่างหาก โครงการอื่นควรสามารถบูรณาการเครือข่าย Solver ของคุณหรือการจับคู่เจตนาได้โดยไม่ต้องนำมาใช้ทั้งกอง
เป็นพันธมิตรกับโปรโตคอลที่เสริมกัน: ระบบนิเวศตามเจตนามีผู้ให้บริการเฉพาะทาง – บางรายเน้นการชดเชยข้ามสาย บางเน้นประเภทสินทรัพย์บางประเภท ผู้อื่นเน้นบนความเป็นส่วนตัว การเป็นพันธมิตรกันที่เป็นกลยุทธ์สร้างมูลค่ามากกว่าการพัฒนาเดี่ยว
รักษาความเป็นกลางของสายโซ่: หลีกเลี่ยงการเอียงไปสนับสนุนสาย 1 หรือสาย 2 ยกเว้นกรณีที่ใช้กรณีของคุณเป็นสิ่งจำเป็น พลังของการออกแบบตามเจตนามาจากการย่อความแตกต่างของสายโซ่ ข้อจำกัดที่ไม่แท้จริงลดทอนความน่าสนใจ
อนาคตอาจเป็นอย่างไร
สถาปัตยกรรมตามเจตนาอาจปั้น Web3 ไปในทางที่ต่างไปอย่างมากหากได้รับการนำไปใช้แพร่หลาย การตีความแนวโน้มในปัจจุบันบอกถึงอนาคตหลายอย่างที่อาจเป็นไปได้
เกินกว่าการค้า: ทุกสิ่งตามเจตนา
ขณะที่การใช้งานครั้งแรกมุ่งเน้นที่การค้า DeFi แนวคิดนี้ขยายเกินกว่า แอปพลิเคชันเกมอาจใช้เจตนาสำหรับการจัดการสินทรัพย์ในเกม ช่วยให้ผู้เล่นระบุเกียร์หรือเส้นทางความก้าวหน้าโดยไม่ต้องเข้าใจกลศาสตร์ของบล็อกเชน การประสานงานซัพพลายเชนอาจแสดงเจตนาด้านโลจิสติกส์: "ส่งของเหล่านี้เนื้อหา: "วัสดุที่จะถูกส่งมาที่ตำแหน่งนี้ภายในวันที่นี้ พร้อมหลักฐานการรับรองความเป็นของแท้"
กลไกการประสานงานทางสังคมอาจทำงานบนเจตนา DAOs สามารถแสดงออกถึงความปรารถนาร่วมกัน – ให้ทุนทรัพย์แก่สิ่งของสาธารณะเหล่านี้ บรรลุผลลัพธ์เหล่านี้ – และเครือข่ายของผู้แก้ปัญหาอาจระบุการจัดสรรทรัพยากรที่เหมาะสม การให้ทุนแบบกำลังสอง การให้ทุนแก่สิ่งของสาธารณะย้อนหลัง และการออกแบบกลไกอื่น ๆ กลายเป็นการปฏิบัติได้จริงมากขึ้น เมื่อชั้นเจตนารับมือกับความซับซ้อนในการดำเนินการ
การเพิ่มประสิทธิภาพผลตอบแทนข้ามเชนอาจกลายเป็นอัตโนมัติทั้งหมด ผู้ใช้แสดงความเสี่ยงที่ยอมรับได้และความคาดหมายผลตอบแทน ผู้แก้ปัญหาทำการปรับสมดุลแบบไดนามิกทั่วทั้งโปรโตคอลและเชนเพื่อเพิ่มผลลัพธ์ให้สูงสุด ภาระทางจิตใจในการจัดการตำแหน่ง DeFi อย่างกระตือรือร้นจางหายไป
การเปลี่ยนแปลงของการออกแบบแลกเปลี่ยน
การออกแบบ DEX ปัจจุบันอาจเป็นก้าวระหว่าง มากกว่าสถานะสุดท้าย หากการจับคู่เจตนาเพียงพอแผงหน้าจอแลกเปลี่ยนอาจไม่จำเป็นอีกต่อไป กระเป๋าสตางค์เองอาจกลายเป็นการติดต่อเจตนา และผู้แก้ปัญหาให้น้ำมันเป็นครั้งคราวแทนที่จะเป็นผ่านสระน้ำมันที่มีการให้บริการตลอดเวลา
การเปลี่ยนแปลงนี้อาจปรับปรุงประสิทธิภาพของทุนอย่างมาก แทนที่จะมีพันล้านที่ล็อกอยู่ในสระ AMM และได้รับผลตอบแทนต่ำ ผู้ทำตลาดมืออาชีพจัดสรรทุนแบบไดนามิก ผู้ใช้ได้รับราคาที่ดีกว่า ผู้ให้บริการน้ำมันได้ผลตอบแทนที่สูงขึ้น ผู้กลางที่ให้คุณค่า – ผู้แก้ปัญหาที่มีความชำนาญ – ได้รับการชดเชยที่เหมาะสมมากกว่าทุนที่ไม่กระตือรือร้นที่ได้รับรางวัลมากที่สุด
ตัวรวมอาจวิวัฒนาการไปสู่ผู้แก้ปัญหาเมตา ประสานงานระหว่างเครือข่ายของผู้แก้ปัญหาเฉพาะด้าน แทนที่จะรวมแหล่งน้ำมัน DEX โดยตรง พวกเขารวมความสามารถของผู้แก้ปัญหา ส่งเสริมเจตนาไปยังเครือข่ายใดก็ตามที่สามารถดำเนินการได้ดีที่สุดสำหรับประเภทของเจตนานั้น ๆ
การเปลี่ยนแปลงอำนาจ: จากเชนสู่ผู้แก้ปัญหา
ตำแหน่งของมูลค่าและการควบคุมอาจเปลี่ยนจากบล็อกเชนชั้น 1 เป็นชั้นการประสานเจตนา หากผู้ใช้ใช้เจตนาเป็นหลักห่วงโซ่การชำระเงินพื้นฐานไม่สำคัญ ผู้แก้ปัญหาเลือกสถานที่ดำเนินการ และผู้ใช้สนใจเพียงผลลัพธ์
การเปลี่ยนแปลงนี้อาจลดการแข่งขันและการมัดรวมเชน หาก Ethereum, Solana และเชนอื่น ๆ ให้บริการเป็นชั้นการชำระเงินสำหรับเครือข่ายเจตนา ตัวแยกแยะของพวกเขากลายเป็นด้านเทคนิค (ความเร็ว ต้นทุน ความปลอดภัย) แทนที่จะเป็นด้านวัฒนธรรม แอปพลิเคชันกลายเป็นอิสระจากเชนอย่างแท้จริง
อย่างไรก็ตาม สิ่งนี้ยังทำให้พลังอยู่ในเครือข่ายของผู้แก้ปัญหา หากมีโอเปอเรเตอร์แก้ปัญหาบางรายครอบครองพวกเขาควบคุมว่าเชนใดทำงานได้และแอปพลิเคชันใดประสบความสำเร็จ และมูลค่าไหลอย่างไร การกระจายอำนาจที่บล็อกเชนสัญญาอาจถูกทำลายโดยโครงสร้างพื้นฐานการแก้ปัญหาที่กระจาย การป้องกันไม่ให้ผลลัพธ์นี้เกิดขึ้นต้องการความสนใจอย่างระมัดระวังต่อการออกแบบเครือข่ายแก้ปัญหา
การวิวัฒนาการของการพัฒนาสัญญาอัจฉริยะ
นักพัฒนาสัญญาอัจฉริยะอาจเปลี่ยนจุดโฟกัสจากการเขียนลอจิกการดำเนินการเป็นการนิยามภาษาที่เจตนาและเงื่อนไขที่เป็นไปได้ว่าสมเหตุสมผล แทนที่จะเขียนโปรแกรมว่า "หาก X เกิดขึ้น, ทำ Y" พวกเขาเขียนว่า "ผลลัพธ์เหล่านี้สมเหตุสมผล อื่นใดถือว่าไม่สมเหตุสมผล"
การเปลี่ยนแปลงนี้สะท้อนถึงการเปลี่ยนแปลงอื่น ๆ ในแบบแผนการเขียนโปรแกรม การเขียนโปรแกรมแบบประกาศได้ครองอยู่ในหลายสาขา SQL สำหรับฐานข้อมูล, CSS สำหรับรูปแบบ, React สำหรับ UI การพัฒนาบล็อกเชนที่เน้นเจตนาเพิ่มการเข้าถึงแบบประกาศไปยังการประสานงานบนเชน
ทักษะที่มีคุณค่าในนักพัฒนาอาจเปลี่ยนลึกไปที่ความรู้เฉพาะของ VM opcode ไม่สำคัญเท่าเดิม ความเข้าใจเรื่องการออกแบบกลไก ทฤษฎีเกม และความพอเพียงของข้อจำกัดกลายเป็นสิ่งสำคัญมากขึ้น การเปลี่ยนแปลงนี้จะช่วยพัฒนานักพัฒนาที่คิดเกี่ยวกับผลลัพธ์และแรงจูงใจมากกว่าที่สนใจรายละเอียดการดำเนินการ
ความหมายในการกำกับดูแล
ระบบที่อิงตามเจตนาอาจทำให้การกำกับดูแลซับซ้อนขึ้น เมื่อผู้ใช้แสดงผลลัพธ์และผู้แก้ปัญหาดำเนินการบังคับใช้ ใครรับผิดชอบในการปฏิบัติตาม? หากผู้แก้ปัญหาช่วยอำนวยความสะดวกในการละเมิดกฎระเบียบนั้น ในขณะที่บรรลุเจตนาที่เทคนิคนั้นถูกต้อง ความรับผิดชอบอยู่ที่ใคร?