เหตุใด Defi จึงใช้งานไม่ได้เนื่องจากความสำคัญของโปรโตคอลที่ปราศจาก Oracle

ผู้แต่ง: Dan Elitzer, NASCENT; ผู้รวบรวม: Tiny Bear, Denglian Translation Project

นำความหลากหลายของการพึ่งพามาสู่ DeFi แทนที่จะพึ่งพา oracle เดียว DeFi ดั้งเดิมควรมีการกำกับดูแลเป็นศูนย์ ไม่มีความสามารถในการอัปเกรด ไม่มี oracles หรือการพึ่งพาภายนอกใดๆ

พื้นหลัง

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

ในปี 2018 ฉันได้อ่านเกี่ยวกับ Uniswap ซึ่งทำให้ฉันเห็นถึงพลังแห่งการเปลี่ยนแปลงที่กำลังเกิดขึ้นในโลกของคริปโต ส่วนนี้จะเรียกว่า DeFi (แม้ว่าฉันจะยังชอบ Open Finance)

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

คำตอบคือ: จะไม่...อย่างน้อยก็ไม่ใช่ในลักษณะที่ตั้งค่าไว้ในปัจจุบัน

ที่ Nascent เราได้ลงทุนอย่างมากในการรักษาความปลอดภัย ในปี 2020 เราเป็นนักลงทุนรายแรกที่มอบความไว้วางใจให้บริษัทตรวจสอบบัญชีระดับ Tier 1 (Open Zeppelin) ให้กับบริษัทในพอร์ตโฟลิโอของเรา เพื่อให้มั่นใจว่าได้รับสิทธิ์ในการตรวจสอบความปลอดภัยที่เข้มงวดก่อนการเปิดตัว เรายังเป็นผู้สนับสนุนรายแรกๆ ของ Spearbit, Code4rena, Macro และ Skylock

เรายังอุทิศเวลาของเราเพื่อสร้างเครื่องมือสำหรับอุตสาหกรรม Simple Security Toolkit ถูก forked เกือบ 100 ครั้ง และเราเพิ่งประกาศการเปิดตัวเบต้าของ Pyrometer ซึ่งเป็นเครื่องมือโอเพ่นซอร์สสำหรับผู้ตรวจสอบและนักพัฒนาที่ผสานรวมการดำเนินการเชิงสัญลักษณ์ การตีความเชิงนามธรรม และการวิเคราะห์แบบคงที่

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

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

**หากเราต้องการเห็นผู้คนหลายพันล้านคนพึ่งพา DeFi เราจำเป็นต้องคิดทบทวนการออกแบบโปรโตคอลและความปลอดภัยโดยพื้นฐานเสียใหม่ **

ที่ Nascent เราเชื่อว่ามีแนวคิดที่เกี่ยวข้องกับความปลอดภัยมากมายที่สมควรได้รับการสำรวจและสำรวจเพิ่มเติม

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

โปรโตคอลโมดูลาร์และพื้นฐาน

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

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

ซึ่งหมายความว่าไม่มีธรรมาภิบาล ไม่มีความสามารถในการปรับขนาด ไม่มีออราเคิล

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

ดั้งเดิมควรทำตามที่เขียนไว้บน jar นั่นคือ ไม่มากหรือน้อย โดยไม่ต้องเพิ่มการพึ่งพาใดๆ

ทุกวันนี้ มีโปรโตคอล DeFi ไม่กี่ตัวที่เหมาะกับคำจำกัดความพื้นฐานนี้ Uniswap v1 น่าจะเป็นที่รู้จักกันดีที่สุด แต่แม้แต่ Uniswap v2 และ v3 (ตามเจตนารมณ์ของคำนิยามนี้จากมุมมองด้านความปลอดภัย) ก็ไม่มีคุณสมบัติเนื่องจากอนุญาตให้มีการจัดการฟังก์ชันบางอย่าง เช่น การแปลงค่าโปรโตคอลและเงินทุน ความสามารถของกลุ่มในการแนะนำ ระดับค่าธรรมเนียมใหม่

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

  • ไม่มีออราเคิล
  • ออนไลน์เต็มรูปแบบ

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

ในขณะที่อุตสาหกรรมพัฒนาขึ้น Uniswap ได้เปิดตัวเวอร์ชันใหม่ของโปรโตคอล ซึ่งเปลี่ยนพื้นที่การออกแบบให้คล้ายกับหนังสือสั่งซื้อมากขึ้น Uniswap v3 แนะนำแนวคิดของสถานะสภาพคล่องที่ไม่เป็นเนื้อเดียวกัน โดยที่ผู้ให้บริการสภาพคล่อง (LPs) มีความสามารถในการรวมสภาพคล่องภายในช่วงที่กำหนด ซึ่งช่วยให้ LP สามารถเก็บค่าธรรมเนียมการแปลงส่วนแบ่งได้มากขึ้นจากการทำธุรกรรมในช่วงนั้น แต่ยังเพิ่มการสูญเสียจากความแตกต่างเมื่อราคาเปลี่ยนแปลง สิ่งนี้นำไปสู่การใช้เงินทุนอย่างมีประสิทธิภาพมากขึ้นและความเป็นมืออาชีพของ LPs ในตลาด พร้อมกับการเกิดขึ้นของระบบนิเวศของเครื่องมือการจัดการตำแหน่ง ซึ่งรวมถึง Arrakis, Gamma และ Sommelier

ฉันคาดว่า ณ จุดนี้ผู้อ่านจำนวนมากจะคิดว่า "ไม่มี oracle ใดที่เหมาะกับ DEX แต่โปรโตคอลการให้ยืมล่ะ คุณต้องมี oracle สำหรับการให้ยืม!"

ฉันเห็นด้วย: การให้ยืมต้องใช้ oracles...แต่เช่นเดียวกับ DEXes พวกเขาสามารถย้ายออกไปนอกโปรโตคอลได้

ปรับโครงสร้างสินเชื่อ

เมื่อเร็ว ๆ นี้ เราสังเกตเห็นว่านักลงทุนสนใจอย่างมากในโปรโตคอลการให้ยืมแบบไม่ใช้ Oracle ที่กำลังจะเกิดขึ้น เช่น Ajna, Ethereum Credit Guild, Automated Tranche Maker ของ Metastreet และ Blend ของ Blur/Paradigm

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

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

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

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

ปลอดภัยหรือไม่สำหรับคนที่จำนอง ETH ของพวกเขาเพื่อยืม USDC ที่ 95% ของจำนวนเงินกู้ มันไม่สำคัญ

รู้สึกไม่สบายใจที่จะกู้เงินโดยมีหลักประกัน MKR แต่มีสัดส่วนหลักประกันเพียง 10%? มันไม่สำคัญ

Blur's Blend ถือว่า "การมีอยู่ของผู้ให้กู้ที่มีความซับซ้อนมากขึ้น ซึ่งสามารถเข้าร่วมในข้อตกลงแบบออนไลน์และออฟไลน์ที่ซับซ้อน ประเมินความเสี่ยง และใช้เงินทุนของตนเอง" สิ่งนี้สมเหตุสมผลในบริบทของ Blur ซึ่งเป็นสถานที่หลักสำหรับผู้ค้า NFT มืออาชีพ แต่สำหรับผู้ใช้ทั่วไป ดูเหมือนว่าจะทำงานมากกว่าการกู้เงินจาก Aave หรือ Compound

ข่าวดีก็คือ ไม่จำเป็นต้องเป็นอย่างนั้น

โปรโตคอลหรือบริการอื่น ๆ สามารถช่วยให้คุณรักษาข้อกำหนดอัตราหลักประกันที่สม่ำเสมอได้ง่าย แม้ว่าราคาของหลักประกันที่คุณให้ยืมจะผันผวนก็ตาม ยกตัวอย่าง Ajna คุณจะสามารถใช้ Oasis และ DeFi Saver (หรือโปรโตคอล/บริการอื่นๆ) เพื่อปรับติ๊กที่คุณให้โดยอัตโนมัติ คุณสามารถสร้างคลังที่อนุญาตให้ผู้ใช้จัดหา DAI หรือ USDC และทำให้สามารถยืมสินทรัพย์เดียวกันโดยมีปัจจัยหลักประกันเดียวกันกับ Aave ปรับสมดุลระหว่างกลุ่มกองทุนใหม่โดยอัตโนมัติเพื่อเพิ่มอัตราเงินกู้สูงสุด ห้องนิรภัยดังกล่าวสามารถใช้ Chainlink เป็นออราเคิลได้ ทำให้ประสบการณ์ของผู้ใช้และโปรไฟล์ความเสี่ยงสำหรับผู้ให้กู้เกือบจะเหมือนกันกับ Aave ในปัจจุบัน

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

ตลาดรวมที่ปลอดภัยผ่านความหลากหลาย

ให้ฉันชัดเจน: **สถาบันการเงินที่แท้จริงจะไม่ (และไม่ควร) ใส่เงินหลายพันล้านดอลลาร์ในโปรโตคอลที่ความปลอดภัยขึ้นอยู่กับ Chainlink เพียงอย่างเดียว **

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

ไม่มีโปรโตคอลของออราเคิล - อันที่จริง โปรโตคอลได้รับการออกแบบอย่างชัดเจนเพื่อให้ผู้ใช้นำออราเคิลของตนเองมา (BYOO: นำออราเคิลของคุณเอง) เป็นเส้นทางทางเลือกโดยเฉพาะอย่างยิ่งสำหรับผู้ที่ไม่จำเป็นต้องกระจายอำนาจหรือต้านทานการเซ็นเซอร์ แหล่งข้อมูลคุณภาพสูงของตนเอง

เป็นไปได้โดยสิ้นเชิงที่ผู้ใช้ส่วนใหญ่ที่ใช้โปรโตคอลที่ไม่ใช้ oracle เช่น Ajna จะยังคงพึ่งพาโปรโตคอลสาธารณะของ oracle เช่น Chainlink ผ่านเครื่องมืออย่าง Oasis เพื่อช่วยจัดการสถานะการให้ยืมอย่างปลอดภัย แต่พวกเขาจะสามารถทำงานได้อย่างราบรื่นในตลาดเดียวกันกับผู้ใช้ที่มีความซับซ้อนซึ่งตัดสินใจใช้โปรโตคอลอื่น (เช่น Pyth), ออราเคิลที่ใช้ zk, Bloomberg APIs หรือแม้กระทั่งการคำนวณราคาภายในของพวกเขาเอง

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

เท่าที่เกี่ยวข้องกับ Ajna โปรดจำไว้ว่ามันไม่ได้เป็นเพียงโปรโตคอลที่ปราศจาก oracle แต่เป็นโปรโตคอลดั้งเดิม: มันไม่มีการกำกับดูแล ไม่มีความสามารถในการอัพเกรด ไม่มี oracles หรือการพึ่งพาภายนอกใดๆ ซึ่งหมายความว่าผู้ยืมและผู้ให้ยืมต่างฝ่ายต่างสามารถสร้างข้อกำหนดของตนเอง เลือกข้อตกลงการจัดการและผู้ให้บริการของตนเอง โดยแต่ละรายมีการพึ่งพาผลลัพธ์ของตนเอง ผู้ใช้บางรายอาจเลือกใช้บริการที่อาศัย Chainlink และสะท้อนสินทรัพย์หลักประกันและอัตราส่วนของ Aave ในขณะที่บางรายอาจเลือกใช้ API ของ Bloomberg และให้ยืมเฉพาะ ETH ที่มีอัตราส่วนหลักประกันแบบอนุรักษ์นิยมเท่านั้น

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

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

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

อนาคตของ DeFi เป็นชั้นๆ

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

ฉันคิดว่ามันจำเป็น

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

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

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

อีกครั้งมันคุ้มค่าหรือไม่?

ฉันคิดอย่างนั้น.

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

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

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

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

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

จำไว้ว่าเราไม่ได้มาที่นี่เพื่อสร้างสิ่งที่ดีกว่าที่เคยเป็นมา 50% แต่เรากำลังสร้างสิ่งที่ดีกว่า 50 เท่า

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

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

ดูต้นฉบับ
เนื้อหานี้มีสำหรับการอ้างอิงเท่านั้น ไม่ใช่การชักชวนหรือข้อเสนอ ไม่มีคำแนะนำด้านการลงทุน ภาษี หรือกฎหมาย ดูข้อจำกัดความรับผิดชอบสำหรับการเปิดเผยความเสี่ยงเพิ่มเติม
  • รางวัล
  • แสดงความคิดเห็น
  • แชร์
แสดงความคิดเห็น
0/400
ไม่มีความคิดเห็น
  • ปักหมุด