ข้อมูลเบื้องต้นเกี่ยวกับการออกแบบสถาปัตยกรรมแอปพลิเคชัน DeFi

ข้อความ

ชื่อเรื่องรอง

คำนำ

คำนำ

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

แทนที่จะพูดถึงโมเดลธุรกิจและโมเดลผลิตภัณฑ์ เราจะพูดถึงกองเทคโนโลยีเท่านั้น กองเทคโนโลยีที่เกี่ยวข้องกับแอปพลิเคชัน DeFi ในปัจจุบันส่วนใหญ่ประกอบด้วย: Solidity, Subgraph, Price Oracle, Hardhat, Ethers เป็นต้น เทคโนโลยีเหล่านี้ส่วนใหญ่ไม่เคยได้ยินแม้แต่ผู้เล่นรายใหญ่ในระดับ P9 ในบริษัทอินเทอร์เน็ตรายใหญ่ เช่น Ali, Tencent และ Byte สถาปัตยกรรมไมโครเซอร์วิสที่เป็นที่นิยม สถาปัตยกรรมบิ๊กดาต้า และสถาปัตยกรรมแบบเนทีฟบนคลาวด์ในสถาปัตยกรรมแอปพลิเคชันแบบดั้งเดิมนั้นไร้ประโยชน์โดยพื้นฐานแล้วในแอปพลิเคชัน DeFi

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

ชื่อเรื่องรอง

โครงสร้างโดยรวม

มาดูสถาปัตยกรรมทั่วไปของระบบแอพพลิเคชั่น DeFi:

• ให้ฉันแนะนำโมดูลสองสามโมดูลถัดไปทีละรายการ:

• บล็อกเชน: เครือข่ายบล็อกเชนพื้นฐาน แอปพลิเคชัน DeFi จะถูกปรับใช้กับเครือข่ายบล็อกเชนที่แตกต่างกันหลายแห่ง

• สัญญาอัจฉริยะ: สัญญาอัจฉริยะเป็นธุรกิจหลักของแอปพลิเคชัน DeFi และจิตวิญญาณ

• Price Oracle: price oracle ใช้ในการให้ข้อมูลราคา โดยทั่วไปสามารถแบ่งออกเป็น off-chain oracle และ on-chain oracle

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

• กราฟย่อย: กราฟย่อยหรือที่เรียกว่าตัวทำดัชนี ส่วนใหญ่จะประกอบข้อมูลในห่วงโซ่ใหม่ให้เป็นข้อมูลที่สะดวกสำหรับการสืบค้นส่วนหน้า

• Graph Node: สภาพแวดล้อมที่ Subgraph ทำงานจะซิงโครไนซ์ข้อมูลบล็อกบนเชนกับ Subgraph เพื่อประมวลผล

• Wallet: แอปพลิเคชันกระเป๋าเงิน กระแสหลักที่สุดคือ MetaMask

• WebUI: หน้า UI ที่แสดงที่ส่วนหน้า โดยทั่วไปจะใช้เฟรมเวิร์กส่วนหน้า เช่น Vue และ React

SDK: สรุปแบบสอบถามของ Subgraph, การเรียกใช้สัญญาอัจฉริยะ, การเชื่อมต่อของกระเป๋าเงิน ฯลฯ เพื่ออำนวยความสะดวกในการเรียก UI ส่วนหน้า

ผมเชื่อว่าหลายคนคงสงสัยว่าทำไมระบบแอพพลิเคชั่น DeFi ถึงมีส่วนประกอบต่างๆ มากมาย?

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

Keepers ส่วนใหญ่เป็นโปรแกรมส่วนกลางแบบออฟไลน์ ในปีที่ผ่านมา เครือข่าย Keeper แบบกระจายศูนย์บางส่วนได้เกิดขึ้นทีละเครือข่าย เครือข่ายที่ฉันรู้จัก ได้แก่ keep3r.network, Chainlink Keepers และ KeeperDAO

ประการที่สอง เนื่องจากข้อจำกัดของสัญญาอัจฉริยะเอง จึงเป็นไปไม่ได้ที่จะเริ่มต้นคำขอเครือข่ายไปยังโปรแกรมภายนอกเพื่อรับข้อมูลเช่นแอปพลิเคชัน Web2 มิฉะนั้น หากสัญญาอัจฉริยะสามารถส่งคำขอเครือข่ายไปยังการแลกเปลี่ยนแบบรวมศูนย์ เช่น Coinbase และ Binance เพื่อรับข้อมูลราคา โหนดต่างๆ จะไม่สามารถบรรลุข้อตกลงร่วมกันได้ เนื่องจากเวลาคำขอที่แตกต่างกันและราคาที่ได้รับที่แตกต่างกัน แต่สัญญาอัจฉริยะจำเป็นต้องได้รับข้อมูลราคา ดังนั้นจึงมี Price Oracle

ราคา Oracle สามารถแบ่งออกได้เป็น 2 ประเภทหลักๆ คือ oracle แบบ off-chain และ on-chain oracle

ออราเคิลแบบ off-chain แสดงโดย Chainlink หลักการพื้นฐานของมันคือการรวมแหล่งข้อมูลของการแลกเปลี่ยนหลายแห่ง อ่านข้อมูลราคาของสัญญาอัจฉริยะบนเครือข่ายได้โดยตรงออราเคิลออนเชนอิงตาม TWAP ของ Uniswap (ราคาถัวเฉลี่ยถ่วงน้ำหนักตามเวลา) ของ Uniswap ซึ่งเป็นหลักการที่ฉันกล่าวถึงในบทความก่อนหน้านี้"การวิเคราะห์ Uniswap สำหรับผลิตภัณฑ์การซื้อขาย DeFi: ตอนที่ 2 ของ V2"

ได้มีการพูดคุยกันแล้ว ดังนั้นฉันจะไม่พูดซ้ำ

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

เฉพาะสำหรับแต่ละแอปพลิเคชัน DeFi สถาปัตยกรรมจริงอาจแตกต่างกันเล็กน้อย ตัวอย่างเช่น Uniswap ไม่ต้องการ Keeper Services หรือ Price Oracle แต่โดยพื้นฐานแล้ว แอปพลิเคชัน DeFi ที่ซับซ้อนกว่าเล็กน้อยส่วนใหญ่ต้องการส่วนประกอบเหล่านี้ ดังนั้น สถาปัตยกรรมนี้จึงกลายเป็นสถาปัตยกรรมทั่วไปของแอปพลิเคชัน DeFi ส่วนใหญ่

ชื่อเรื่องรอง

การออกแบบสัญญาอัจฉริยะ

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

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

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

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

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

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

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

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

ชื่อเรื่องรอง

ปฏิบัติการออกแบบ

ลองใช้แอปพลิเคชัน DeFi ที่ฉันดูแลอยู่เป็นตัวอย่างเพื่อพูดคุยเกี่ยวกับสรุปการปฏิบัติของฉัน

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

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

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

สีเขียวแสดงถึงหลายบทบาทที่เข้าร่วมในระบบเท่านั้น และสีอื่นๆ คือโมดูลย่อยในสัญญาอัจฉริยะ

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

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

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

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

ชื่อเรื่องรอง

สรุป

สรุป

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