แนวทางปฏิบัติที่ดีที่สุดสำหรับการใช้กลไกป้อนข้อความบน Ethereum

หมายเหตุบรรณาธิการ: บทความนี้มาจากผู้ที่ชื่นชอบ Ethereum (ID: ethfans)หมายเหตุบรรณาธิการ: บทความนี้มาจาก

ผู้ที่ชื่นชอบ Ethereum (ID: ethfans)

ผู้เขียน: Tellor Core แปลและพิสูจน์อักษร: Chen Liang & A Jian พิมพ์ซ้ำโดยได้รับอนุญาตจาก Odaily

แอปพลิเคชันทางการเงินแบบกระจายศูนย์เป็นประเภทที่เพิ่งเกิดขึ้นและเติบโตอย่างรวดเร็วในระบบนิเวศ Ethereum แต่ส่วนสำคัญของมัน - กลไกการป้อนข้อมูล (Oracle, การแปลแบบเก่า "กลไกการป้อนข้อมูล") - ดึงดูดความสนใจของทุกคน หากไม่มีกลไกการป้อนข้อมูล แอปพลิเคชันทางการเงินแบบกระจายศูนย์จะสามารถรับข้อมูลบนเครือข่ายได้เท่านั้น และความสามารถในการปรับตัวให้เข้ากับสถานการณ์แอปพลิเคชันจริงจะถูกจำกัดอย่างมาก หลายคนอาจทราบด้วยว่าหลายโครงการใช้กลไกการป้อนข้อมูลแบบออฟไลน์อยู่แล้ว แต่ทุกคนยังขาดความเข้าใจเกี่ยวกับการใช้กลไกการป้อนข้อมูลและมาตรการรักษาความปลอดภัยที่เกี่ยวข้อง ด้วยโครงการใหม่และโครงการที่มีอยู่จำนวนมากขึ้นเรื่อย ๆ ได้รับการออกแบบใหม่เพื่อความปลอดภัยที่มากขึ้น หวังว่าบทความนี้จะเป็นข้อมูลอ้างอิงแนวทางปฏิบัติที่ดีที่สุดสำหรับวิธีการใช้กลไกการป้อนข้อมูล เราจะไม่พูดมากเกินไปเกี่ยวกับหลักการออกแบบที่ดีที่สุดและรูปแบบความปลอดภัยสำหรับกลไกการป้อนข้อความ แต่จะใช้เฉพาะวิธีการใช้กลไกการป้อนข้อความหากคุณสร้างแอปพลิเคชันบน Ethereum หากคุณยังหวังว่าแอปพลิเคชันที่คุณพัฒนาจะได้รับความปลอดภัย การต่อต้านการเซ็นเซอร์ และการกระจายอำนาจ ต่อไปนี้เป็นคำแนะนำสำหรับคุณเมื่อสร้างสัญญาอัจฉริยะของ Ethereum:

คำแนะนำ 1: การออกแบบกลไกการป้อนข้อมูลและการโต้ตอบจะต้องมีความสำคัญในโปรโตคอลของคุณ

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

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

คำแนะนำ 2: อย่าวางใจกลไกการป้อนข้อมูลของคุณว่าจะตอบสนองอย่างรวดเร็วเสมอ

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

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

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

• คำแนะนำ 3: สันนิษฐานว่ากลไกการป้อนข้อมูลของคุณอาจเสียหาย

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

สรุป มีข้อผิดพลาดสองประเภทที่อาจเกิดขึ้นกับกลไกการป้อนข้อมูล:

กลไกการป้อนข้อความของคุณส่งค่าที่ไม่ถูกต้อง

กลไกการป้อนข้อความของคุณไม่ทำงานและไม่ได้ส่งข้อความไปยังห่วงโซ่

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

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

• วิธีที่สองในการบ่อนทำลายกลไกการป้อนข้อมูลคือวงเวียนมากขึ้น ตัวอย่างคือกลไกการป้อนข้อมูลแบบรวมศูนย์สูญเสียคีย์ส่วนตัวและไม่สามารถอัปเดตสัญญาได้ จะเกิดอะไรขึ้นกับสัญญาสมาร์ทอนุพันธ์ของคุณในเวลานี้ อีกสิ่งหนึ่งที่ส่งผลต่อกิจกรรมของกลไกการป้อนข้อมูลคือความไม่เต็มใจของผู้ให้ข้อมูลในการให้ข้อมูลอย่างรวดเร็ว สมมติว่าเครือข่าย Ethereum แออัด ค่าธรรมเนียมการขุดต่อการทำธุรกรรมคือ $20 และกลไกการป้อนข้อมูลของคุณให้ค่าธรรมเนียมการทำธุรกรรมเพียง $1 ต่อการทำธุรกรรม ดังนั้นสัญญาอัจฉริยะอาจใช้เวลาหลายชั่วโมงในการอัปเดต กลับไปที่คำแนะนำ 2 จากมุมมอง คุณอาจต้องเตรียมพร้อมสำหรับสิ่งนี้ แต่คุณควรทราบด้วยว่าผู้ให้บริการข้อมูลของคุณมีความสามารถในการควบคุมความล่าช้านี้เพียงฝ่ายเดียวหรือไม่ ในกลไกการป้อนข้อมูลของ Tellor เราใส่ข้อมูลในห่วงโซ่ผ่านการแข่งขันของ POW ดังนั้นกิจกรรมจึงรับประกันได้โดยกลไกจูงใจ กลไกการป้อนข้อมูลแบบรวมศูนย์บางส่วนไม่มีการรับประกันดังกล่าว และผู้ให้บริการกลไกการป้อนข้อมูลสามารถทนต่อการทำธุรกรรมที่ล่าช้า และแม้แต่การเซ็นเซอร์ข้อมูลตามสินบนหรือตำแหน่งของตนเอง

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

• หยุดการดำเนินการตามสัญญาและรอให้กลไกการป้อนข้อมูลตอบกลับค่าที่ถูกต้อง

ใช้กลไกการป้อนข้อมูลหลายรายการ

คืนเงินทั้งหมด / ชำระบัญชีให้เสร็จสมบูรณ์ด้วยค่าเริ่มต้น

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

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

สรุปแล้ว

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