Chainlink: เครือข่าย Oracle แบบกระจายอำนาจ

บทคัดย่อ

ในเอกสารไวท์เปเปอร์นี้ เราได้แสดงวิสัยทัศน์สำหรับวิวัฒนาการของ Chainlink นอกเหนือจากแนวความคิดเริ่มแรกในเอกสารไวท์เปเปอร์ต้นฉบับ Chainlink เราคาดการณ์ไว้ บทบาทที่กว้างขวางมากขึ้นสำหรับเครือข่าย oracle ซึ่งจะช่วยเสริมและปรับปรุง blockchains ที่มีอยู่และใหม่โดยการให้บริการที่รวดเร็ว เชื่อถือได้ และ การรักษาความลับของการเชื่อมต่อสากลและการคำนวณแบบออฟไลน์ smart contractวินาที รากฐานของแผนของเราคือสิ่งที่เราเรียกว่า Decentralized Oracle Networks หรือ DONs โดยย่อ DON เป็นเครือข่ายที่ดูแลโดยคณะกรรมการของ Chainlink โหนด รองรับฟังก์ชัน oracle ที่เลือกไว้สำหรับช่วงไม่จำกัด การปรับใช้โดยคณะกรรมการ DON จึงทำหน้าที่เป็นเลเยอร์นามธรรมที่ทรงพลัง นำเสนออินเทอร์เฟซสำหรับ smart contracts ไปยังทรัพยากรออฟเชนที่กว้างขวางและมีประสิทธิภาพสูง ทรัพยากรการประมวลผลแบบ off-chain ที่มีประสิทธิภาพแต่มีการกระจายอำนาจภายใน DON เอง โดยมี DONs เป็นจุดเริ่มต้น Chainlink วางแผนที่จะมุ่งเน้นไปที่ความก้าวหน้าในเจ็ด พื้นที่สำคัญ: • ไฮบริด smart contracts: นำเสนอเฟรมเวิร์กทั่วไปที่ทรงพลังสำหรับการเพิ่มความสามารถ smart contract ที่มีอยู่โดยการเขียนออนไลน์อย่างปลอดภัย และทรัพยากรการประมวลผลแบบออฟเชนเป็นสิ่งที่เราเรียกว่าไฮบริด smart contracts • ขจัดความซับซ้อนออกไป: นำเสนอนักพัฒนาและผู้ใช้ด้วยความเรียบง่าย ฟังก์ชั่นการทำงานช่วยลดความจำเป็นในการทำความคุ้นเคยกับสิ่งพื้นฐานที่ซับซ้อน โปรโตคอลและขอบเขตของระบบ • การปรับขนาด: ตรวจสอบให้แน่ใจว่าบริการ oracle บรรลุถึงเวลาแฝงและปริมาณงาน ต้องการโดยระบบกระจายอำนาจที่มีประสิทธิภาพสูง • การรักษาความลับ: การเปิดใช้งานระบบยุคถัดไปที่รวม blockchains' ความโปร่งใสโดยกำเนิดพร้อมการปกป้องความลับที่แข็งแกร่งแบบใหม่สำหรับความละเอียดอ่อน ข้อมูล • ความเป็นธรรมในการสั่งซื้อสำหรับธุรกรรม: สนับสนุนการจัดลำดับธุรกรรมในรูปแบบต่างๆ ที่ยุติธรรมสำหรับผู้ใช้ปลายทางและป้องกันการรุกล้ำหน้าและการโจมตีอื่นๆ โดย บอทและนักขุดแสวงหาผลประโยชน์ • การลดความน่าเชื่อถือ: การสร้างชั้นการสนับสนุนที่น่าเชื่อถือสูงสำหรับ smart contracts และระบบที่ขึ้นอยู่กับ oracle อื่นๆ โดยการกระจายอำนาจ การยึดเกาะที่แข็งแกร่งในความปลอดภัยสูง blockchains การเข้ารหัส เทคนิคและการค้ำประกันด้านเศรษฐกิจเข้ารหัส • การรักษาความปลอดภัยตามแรงจูงใจ (เศรษฐกิจเข้ารหัสลับ): การออกแบบอย่างเข้มงวดและกลไกการใช้งานที่แข็งแกร่งเพื่อให้แน่ใจว่าโหนดใน DONs มีแรงจูงใจทางเศรษฐกิจที่แข็งแกร่งเพื่อให้ทำงานได้อย่างน่าเชื่อถือและถูกต้อง แม้ว่าจะต้องเผชิญกับศัตรูที่มีทรัพยากรเพียงพอก็ตาม เรานำเสนอนวัตกรรมเบื้องต้นและต่อเนื่องโดยชุมชน Chainlink ในแต่ละด้านทำให้เห็นภาพที่กว้างและเพิ่มมากขึ้น ความสามารถอันทรงพลังที่วางแผนไว้สำหรับเครือข่าย Chainlink

การแนะนำ

Blockchain oracles มักถูกมองว่าเป็นบริการแบบกระจายอำนาจโดยมีวัตถุประสงค์เดียว: เพื่อส่งต่อข้อมูลจากทรัพยากรนอกเครือข่ายไปยัง blockchains แม้ว่าจะเป็นขั้นตอนสั้นๆ จากการส่งต่อข้อมูลไปสู่การประมวลผล จัดเก็บ หรือส่งข้อมูลแบบสองทิศทาง การสังเกตนี้แสดงให้เห็นถึงแนวคิดที่กว้างกว่ามากเกี่ยวกับการทำงานของ oracles เช่นกัน ทำตามข้อกำหนดการบริการที่เพิ่มขึ้นของ smart contracts และมีความหลากหลายมากขึ้น เทคโนโลยีที่ต้องอาศัยเครือข่าย oracle กล่าวโดยสรุป oracle สามารถทำได้และจำเป็น เป็นอินเทอร์เฟซอเนกประสงค์แบบสองทิศทางที่เปิดใช้งานการประมวลผลระหว่างและระหว่างระบบออนเชนและออฟเชน บทบาทของ Oracles ในระบบนิเวศ blockchain คือการปรับปรุง ประสิทธิภาพ ฟังก์ชันการทำงาน และความสามารถในการทำงานร่วมกันของ smart contracts เพื่อให้สามารถทำได้ นำโมเดลความไว้วางใจและความโปร่งใสใหม่ๆ มาสู่อุตสาหกรรมที่หลากหลาย การเปลี่ยนแปลงนี้จะเกิดขึ้นผ่านการขยายการใช้ไฮบริด smart contracts ซึ่งฟิวส์ คุณสมบัติพิเศษของ blockchains พร้อมความสามารถเฉพาะตัวของระบบออฟเชน เช่น oracle เครือข่าย และด้วยเหตุนี้จึงบรรลุการเข้าถึงและประสิทธิภาพที่มากกว่าระบบออนไลน์มาก ในการแยก ในเอกสารไวท์เปเปอร์นี้ เราได้แสดงวิสัยทัศน์สำหรับสิ่งที่เราเรียกว่า Chainlink 2.0 ซึ่งเป็นวิวัฒนาการของ Chainlink ที่นอกเหนือไปจากแนวความคิดเริ่มแรกในเอกสารไวท์เปเปอร์ Chainlink ต้นฉบับ [98] เราคาดการณ์ว่าจะมีบทบาทที่กว้างขวางมากขึ้นสำหรับเครือข่าย oracle ซึ่งหนึ่งในนั้น พวกเขาเสริมและปรับปรุง blockchains ที่มีอยู่และใหม่โดยมอบการเชื่อมต่อและการคำนวณสากลที่รวดเร็ว เชื่อถือได้ และรักษาความลับสำหรับไฮบริด smart contractส. เราเชื่อว่าเครือข่าย oracle จะพัฒนาไปสู่ระบบสาธารณูปโภคด้วยซ้ำ สำหรับการส่งออกข้อมูลระดับ blockchain ความสมบูรณ์สูงไปยังระบบที่อยู่นอกเหนือ blockchain ระบบนิเวศ ในปัจจุบัน โหนด Chainlink ที่ดำเนินการโดยชุดเอนทิตีที่หลากหลายมารวมกันในเครือข่าย oracle เพื่อถ่ายทอดข้อมูลไปยัง smart contracts ในสิ่งที่เรียกว่ารายงาน เราสามารถดูได้เช่นนี้ oracle โหนดในฐานะคณะกรรมการที่คล้ายคลึงกับที่เป็นเอกฉันท์แบบคลาสสิก blockchain [72], แต่มีเป้าหมายในการสนับสนุน blockchains ที่มีอยู่ แทนที่จะจัดให้มีฟังก์ชันการทำงานแบบอิสระ ด้วยฟังก์ชันสุ่มที่ตรวจสอบได้ (VRF) และการรายงานแบบ Off-Chain (OCR) Chainlink กำลังพัฒนาไปสู่กรอบงานและโครงสร้างพื้นฐานสำหรับวัตถุประสงค์ทั่วไปในการจัดหาทรัพยากรการคำนวณที่ smart contracts ต้องการสำหรับ ฟังก์ชั่นขั้นสูง รากฐานของแผนของเราสำหรับ Chainlink 2.0 คือสิ่งที่เราเรียกว่า Decentralized Oracle เครือข่าย หรือเรียกสั้น ๆ ว่า DONs เนื่องจากเราแนะนำคำว่า “oracle network” ใน เอกสารไวท์เปเปอร์ Chainlink ดั้งเดิม [98], oracles ได้พัฒนาฟังก์ชันการทำงานที่สมบูรณ์ยิ่งขึ้นและ ความกว้างของการใช้งาน ในบทความนี้ เรานำเสนอคำจำกัดความใหม่ของคำศัพท์ตามนี้ สู่วิสัยทัศน์ในอนาคตของเราสำหรับระบบนิเวศ Chainlink ในมุมมองนี้ DON คือเครือข่าย ดูแลโดยคณะกรรมการของ Chainlink โหนด ฝังอยู่ในโปรโตคอลฉันทามติมัน รองรับฟังก์ชัน oracle ไม่จำกัดช่วงที่เลือกไว้สำหรับการปรับใช้โดย คณะกรรมการ DON จึงทำหน้าที่เป็นเลเยอร์นามธรรม blockchain ซึ่งจัดเตรียมอินเทอร์เฟซ ไปยังทรัพยากรแบบ off-chain สำหรับทั้ง smart contracts และระบบอื่นๆ อีกทั้งยังให้ เข้าถึงทรัพยากรการประมวลผลแบบออฟเชนที่มีประสิทธิภาพสูงแต่มีการกระจายอำนาจ โดยทั่วไปแล้ว a DON รองรับการดำเนินการบนเชนหลัก เป้าหมายคือการเปิดใช้งานการรักษาความปลอดภัยและการเข้าถึงข้อมูลble hybrid smart contracts ซึ่งรวมการคำนวณแบบ on-chain และ of-chain เข้ากับ การเชื่อมต่อกับทรัพยากรภายนอก เราเน้นย้ำว่าถึงแม้จะมีการใช้คณะกรรมการใน DONs Chainlink เอง ยังคงไม่ได้รับอนุญาตโดยเนื้อแท้ DONs ทำหน้าที่เป็นรากฐานของการไม่ได้รับอนุญาต เฟรมเวิร์กที่โหนดสามารถมารวมกันเพื่อใช้เครือข่าย oracle แบบกำหนดเองด้วย ระบอบการปกครองของตนเองสำหรับการรวมโหนดซึ่งอาจได้รับอนุญาตหรือไม่ได้รับอนุญาต ด้วย DONs เป็นรากฐาน เราวางแผนที่จะมุ่งเน้นไปที่ Chainlink 2.0 ที่ความก้าวหน้าในเจ็ด พื้นที่สำคัญ: แบบผสม smart contracts การขจัดความซับซ้อน การปรับขนาด การรักษาความลับ ความเป็นธรรมในการสั่งซื้อสำหรับธุรกรรม การลดความน่าเชื่อถือให้เหลือน้อยที่สุด และการรักษาความปลอดภัยตามแรงจูงใจ (เศรษฐกิจแบบเข้ารหัสลับ) ในบทนำของบทความนี้ เราจะนำเสนอภาพรวมของการกระจายอำนาจ Oracle Networks ในส่วนที่ 1.1 และนวัตกรรมหลักเจ็ดประการของเราในส่วนที่ 1.2 เราอธิบายการจัดระเบียบส่วนที่เหลือของบทความนี้ในส่วนที่ 1.3 1.1 Oracle Networks แบบกระจายอำนาจ Oracle Networks แบบกระจายอำนาจได้รับการออกแบบมาเพื่อปรับปรุงและขยายขีดความสามารถ ของ smart contracts บนเป้าหมาย blockchain หรือลูกโซ่หลักผ่านฟังก์ชันที่ ไม่สามารถใช้ได้โดยกำเนิด พวกเขาทำเช่นนั้นโดยการจัดหาทรัพยากรพื้นฐานสามอย่างที่พบใน ระบบคอมพิวเตอร์: ระบบเครือข่าย การจัดเก็บ และการคำนวณ A DON มีเป้าหมายที่จะนำเสนอ ทรัพยากรเหล่านี้มีคุณสมบัติการรักษาความลับ ความสมบูรณ์ และความพร้อมใช้งานสูง1 เช่น ตลอดจนความรับผิดชอบ DONs ถูกสร้างขึ้นโดยคณะกรรมการของโหนด oracle ที่ร่วมมือกันเพื่อตอบสนองความต้องการเฉพาะ งานหรือเลือกที่จะสร้างความสัมพันธ์ที่ยาวนานเพื่อให้บริการอย่างต่อเนื่อง ให้กับลูกค้า DONs ได้รับการออกแบบในลักษณะ blockchain แบบไม่เชื่อเรื่องพระเจ้า พวกเขาสัญญาว่าจะทำหน้าที่เป็น เครื่องมือที่ทรงพลังและยืดหยุ่นสำหรับนักพัฒนาแอปพลิเคชันเพื่อสร้างการสนับสนุนแบบออฟไลน์ smart contracts ของพวกเขาบนเชนหลักที่รองรับ ฟังก์ชันการทำงานสองประเภทตระหนักถึงความสามารถของ DON: ปฏิบัติการและ อะแดปเตอร์ โปรแกรมปฏิบัติการคือโปรแกรมที่ทำงานอย่างต่อเนื่องและในลักษณะกระจายอำนาจบน DON แม้ว่าพวกเขาไม่ได้จัดเก็บสินทรัพย์สายหลักโดยตรง แต่ก็มีประโยชน์ที่สำคัญ รวมถึงประสิทธิภาพสูงและความสามารถในการดำเนินการเป็นความลับ การคำนวณ ไฟล์ปฏิบัติการทำงานโดยอัตโนมัติบน DON และดำเนินการตามที่กำหนด การดำเนินงาน ทำงานร่วมกับอะแดปเตอร์ที่เชื่อมโยง DON กับทรัพยากรภายนอก และอาจถูกเรียกโดยโปรแกรมปฏิบัติการ อะแดปเตอร์ ตามที่เราจินตนาการไว้สำหรับ DONs คือ ลักษณะทั่วไปของอะแดปเตอร์ภายนอกใน Chainlink วันนี้ ในขณะที่อะแดปเตอร์ที่มีอยู่ โดยทั่วไปจะดึงข้อมูลจากแหล่งข้อมูลเท่านั้น อะแดปเตอร์อาจทำงานแบบสองทิศทาง ใน DONs พวกเขาอาจใช้ประโยชน์จากการคำนวณร่วมกันเพิ่มเติมโดยโหนด DON เพื่อให้บรรลุ คุณสมบัติเพิ่มเติม เช่น การเข้ารหัสรายงานเพื่อการใช้งานที่รักษาความเป็นส่วนตัวโดย ปฏิบัติการได้ เพื่อให้เข้าใจถึงการทำงานพื้นฐานของ DON รูปที่ 1 แสดงแนวคิดว่า DON อาจใช้เพื่อส่งรายงานไปยัง blockchain และทำให้ได้รับฟังก์ชัน oracle แบบดั้งเดิมที่มีอยู่ DONs สามารถให้คุณสมบัติเพิ่มเติมมากมาย นอกเหนือจากนั้น 1 “CIA triad” ของการรักษาความปลอดภัยข้อมูล [123, p. 26, §2.3.5]เครือข่ายที่มีอยู่ของ Chainlink ตัวอย่างเช่น ภายในโครงสร้างทั่วไปของรูปที่ 1 ปฏิบัติการสามารถบันทึกข้อมูลราคาสินทรัพย์ที่ดึงมาใน DON โดยใช้ข้อมูลดังกล่าวเพื่อ คำนวณ เช่น ค่าเฉลี่ยต่อท้ายสำหรับรายงาน รูปที่ 1: รูปแบบแนวคิดที่แสดงเป็นตัวอย่างว่า Oracle Network แบบกระจายอำนาจสามารถใช้งานฟังก์ชัน oracle พื้นฐานได้อย่างไร กล่าวคือ ถ่ายทอดข้อมูลนอกสายโซ่ไปยังสัญญา อ ปฏิบัติการได้ใช้อะแดปเตอร์เพื่อดึงข้อมูลลูกโซ่ซึ่งประมวลผลและส่งเอาต์พุต ผ่านอะแดปเตอร์อื่นไปยังเป้าหมาย blockchain (อะแดปเตอร์เริ่มต้นโดยโค้ดในไฟล์ DON แสดงด้วยกล่องสีน้ำเงินเล็กๆ ลูกศรแสดงทิศทางของการไหลของข้อมูลสำหรับสิ่งนี้ ตัวอย่างเฉพาะ) ไฟล์ปฏิบัติการสามารถอ่านและเขียนเพิ่มเติมไปยังท้องถิ่น DON ที่เก็บข้อมูลเพื่อรักษาสถานะและ/หรือสื่อสารกับโปรแกรมปฏิบัติการอื่น ๆ เครือข่าย การคำนวณ และพื้นที่เก็บข้อมูลที่ยืดหยุ่นใน DONs ทั้งหมดนี้แสดงไว้ที่นี่ ช่วยให้สามารถโฮสต์ของสิ่งใหม่ๆ ได้ การใช้งาน ประโยชน์หลักของ DONs คือความสามารถในการบูตบริการ blockchain ใหม่ DONส เป็นเครื่องมือที่เครือข่าย oracle ที่มีอยู่สามารถรองรับแอปพลิเคชันบริการได้อย่างรวดเร็ว ซึ่งในปัจจุบันจะต้องมีการสร้างเครือข่ายที่สร้างขึ้นตามวัตถุประสงค์ เราให้จำนวน ตัวอย่างการสมัครดังกล่าวในมาตรา 4 ในส่วนที่ 3 เราจะให้รายละเอียดเพิ่มเติมเกี่ยวกับ DONs โดยอธิบายความสามารถของพวกเขาใน เงื่อนไขของอินเทอร์เฟซที่นำเสนอต่อนักพัฒนาและผู้ใช้ 1.2 เป้าหมายการออกแบบที่สำคัญเจ็ดประการ ที่นี่เราจะทบทวนประเด็นสำคัญเจ็ดประการที่แจกแจงไว้ข้างต้นสำหรับวิวัฒนาการของ Chainlink กล่าวคือ:ไฮบริด smart contracts: หัวใจสำคัญของวิสัยทัศน์ของเราสำหรับ Chainlink คือแนวคิดเรื่องความปลอดภัย การรวมส่วนประกอบ on-chain และ of-chain ใน smart contracts เราอ้างถึงสัญญา การตระหนักถึงแนวคิดนี้เป็นแบบไฮบริด smart contracts หรือสัญญาแบบไฮบริด2 บล็อกเชนเป็นและจะยังคงมีบทบาทสำคัญสองประการในบริการแบบกระจายอำนาจต่อไป ระบบนิเวศ: ทั้งสองเป็นสถานที่ที่แสดงความเป็นเจ้าของสกุลเงินดิจิทัล และจุดยึดที่แข็งแกร่งสำหรับบริการแบบกระจายอำนาจ ดังนั้นสัญญาอัจฉริยะจึงต้องแสดงหรือดำเนินการบนลูกโซ่ แต่ความสามารถบนลูกโซ่นั้นมีจำกัดอย่างมาก หมดจด รหัสสัญญาออนไลน์ช้า มีราคาแพง และโดดเดี่ยว ไม่สามารถรับประโยชน์จากโลกแห่งความเป็นจริงได้ ข้อมูลและฟังก์ชันต่างๆ ที่ไม่สามารถทำได้บนห่วงโซ่ รวมถึงรูปแบบต่างๆ ของการคำนวณที่เป็นความลับ การสร้าง (หลอก) การสุ่มที่ปลอดภัย กับคนงานเหมือง / validator การจัดการ ฯลฯ เพื่อให้ smart contracts ตระหนักถึงศักยภาพสูงสุดของตน ดังนั้นจึงต้องอาศัย smart contracts ได้รับการออกแบบทางสถาปัตยกรรมด้วยสองส่วน: ส่วนแบบออนไลน์ (ซึ่งโดยปกติแล้วเราจะแสดงโดย SC) และส่วนของ of-chain ซึ่งเป็นไฟล์ปฏิบัติการที่ทำงานบน DON (ซึ่งโดยทั่วไปเราจะแสดงโดย ผู้บริหาร) เป้าหมายคือการบรรลุองค์ประกอบที่ปลอดภัยของฟังก์ชันออนไลน์ด้วย บริการ off-chain ที่หลากหลายซึ่ง DONs มุ่งหวังที่จะให้ได้ รวมกันทั้งสองส่วน ทำสัญญาแบบไฮบริด เรานำเสนอแนวคิดตามแนวคิดในรูปที่ 2 แล้ววันนี้ Chainlink บริการ 3 เช่น ฟีดข้อมูลและ VRF เปิดใช้งานอย่างอื่นไม่สำเร็จ smart contract แอปพลิเคชัน ตั้งแต่ DeFi ไปจนถึง NFTs ที่สร้างขึ้นอย่างเป็นธรรม ไปจนถึงการประกันภัยแบบกระจายอำนาจ ซึ่งเป็นก้าวแรกสู่กรอบการทำงานทั่วไปมากขึ้น เป็นบริการ Chainlink ขยายและเติบโตอย่างมีประสิทธิภาพมากขึ้นตามวิสัยทัศน์ของเราในเอกสารไวท์เปเปอร์นี้เช่นกัน พลังของ smart contract ระบบจะครอบคลุม blockchains ทั้งหมดหรือไม่ จุดเน้นหลักอีกหกประการของเราในเอกสารไวท์เปเปอร์นี้อาจถูกมองว่าเป็นการดำเนินการในบริการ ของสัญญาแรกที่ครอบคลุมหนึ่งในสัญญาไฮบริด โฟกัสเหล่านี้เกี่ยวข้องกับการลบสิ่งที่มองเห็นได้ ความซับซ้อนจากสัญญาแบบไฮบริด การสร้างบริการออฟเชนเพิ่มเติมที่เปิดใช้งาน การสร้างสัญญาไฮบริดที่มีความสามารถมากขึ้น และในกรณีของการลดความน่าเชื่อถือ จะเป็นการเสริมคุณสมบัติด้านความปลอดภัยที่ได้รับจากสัญญาแบบไฮบริด เราทิ้งความคิดไว้ ของสัญญาแบบผสมโดยนัยตลอดทั้งรายงาน แต่การรวมกันของ ตรรกะ MAINCHAIN ที่มี DON อาจถูกมองว่าเป็นสัญญาแบบไฮบริด ขจัดความซับซ้อนออกไป: DONs ได้รับการออกแบบมาเพื่อใช้การกระจายอำนาจ ระบบที่ง่ายสำหรับนักพัฒนาและผู้ใช้โดยการแยกเครื่องจักรที่มักจะซับซ้อนออกไป เบื้องหลังบริการอันทรงพลังและยืดหยุ่นของ DONs บริการ Chainlink ที่มีอยู่ มีคุณสมบัตินี้อยู่แล้ว ตัวอย่างเช่น ฟีดข้อมูลใน Chainlink ในปัจจุบันนำเสนออินเทอร์เฟซแบบ onchain ที่ไม่ต้องการให้นักพัฒนาเกี่ยวข้องกับรายละเอียดระดับโปรโตคอล เช่น วิธีการที่ OCR บังคับใช้การรายงานที่เป็นเอกฉันท์ระหว่าง 2แนวคิดเรื่องการจัดองค์ประกอบสัญญาแบบออนไลน์/ออฟเชนเกิดขึ้นก่อนหน้านี้ในข้อจำกัดต่างๆ แบบฟอร์ม เช่น ระบบเลเยอร์ 2, TEE-based blockchains [80] ฯลฯ เป้าหมายของเราคือการสนับสนุนและสรุป แนวทางเหล่านี้และรับรองว่าสามารถรวมการเข้าถึงข้อมูลแบบออฟไลน์และคีย์อื่นๆ oracle บริการ 3Chainlink บริการประกอบด้วยบริการและฟังก์ชันการกระจายอำนาจที่หลากหลายที่มีให้บริการผ่าน เครือข่าย นำเสนอโดยตัวดำเนินการโหนดจำนวนมากที่ประกอบด้วยเครือข่าย oracle ต่างๆ ทั่วทั้งระบบนิเวศรูปที่ 2: ภาพแนวความคิดที่แสดงองค์ประกอบสัญญาแบบออนไลน์ / ออฟเชน ก ไฮบริด smart contract 3⃝ประกอบด้วยองค์ประกอบเสริมสองส่วน: แบบออนไลน์ ส่วนประกอบ SC 1⃝ อาศัยอยู่บน blockchain และส่วนประกอบ off-chain exec 2⃝นั้น ดำเนินการบน DON DON ทำหน้าที่เป็นสะพานเชื่อมระหว่างทั้งสององค์ประกอบเช่นกัน เป็นการเชื่อมต่อสัญญาแบบไฮบริดกับทรัพยากรนอกเครือข่าย เช่น บริการบนเว็บ และอื่นๆ blockchains พื้นที่เก็บข้อมูลแบบกระจายอำนาจ ฯลฯ ชุดโหนดแบบกระจายอำนาจ DONs ก้าวไปอีกขั้นในแง่ที่ว่าพวกเขาขยาย ช่วงของบริการที่ Chainlink สามารถนำเสนอเลเยอร์นามธรรมให้กับนักพัฒนาได้ มาพร้อมกับอินเทอร์เฟซที่มีประสิทธิภาพสำหรับบริการระดับสูง เรานำเสนอตัวอย่างการใช้งานหลายตัวอย่างในส่วนที่ 4 ที่เน้นแนวทางนี้ เราจินตนาการถึงองค์กรต่างๆ ที่ใช้ DONs เป็นรูปแบบหนึ่งของมิดเดิลแวร์ที่ปลอดภัยเพื่อ เชื่อมต่อระบบเดิมกับ blockchains (ดูหัวข้อ 4.2.) การใช้ DONs นี้ช่วยลดความซับซ้อนของไดนามิก blockchain ทั่วไป (ค่าธรรมเนียม การจัดองค์กรใหม่ ฯลฯ) มันยัง สรุปคุณลักษณะเฉพาะของ blockchains ออกไป ซึ่งช่วยให้องค์กรต่างๆ สามารถเชื่อมต่อระบบที่มีอยู่กับอาร์เรย์ของระบบ blockchain ที่ขยายวงกว้างขึ้นเรื่อยๆ โดยไม่ต้อง ความต้องการความเชี่ยวชาญพิเศษในระบบเหล่านี้ หรือโดยทั่วไป ในการพัฒนาระบบกระจายอำนาจ ท้ายที่สุดแล้ว ความทะเยอทะยานของเราคือการผลักดันระดับของความเป็นนามธรรมที่ทำได้โดย Chainlink จนถึงขั้นนำสิ่งที่เราเรียกว่า metalayer แบบกระจายอำนาจไปใช้ ชั้นดังกล่าว จะสรุปความแตกต่างแบบ on-chain / of-chain สำหรับนักพัฒนาทุกระดับ และผู้ใช้ DApps ช่วยให้สามารถสร้างและใช้บริการกระจายอำนาจได้อย่างราบรื่นเพื่อให้กระบวนการพัฒนาง่ายขึ้น นักพัฒนาสามารถระบุฟังก์ชันการทำงานของ DApp ในเมตาเลเยอร์เป็นแอปพลิเคชันเสมือนในโมเดลเครื่องที่รวมเป็นหนึ่งเดียว พวกเขาทำได้ จากนั้นใช้คอมไพเลอร์แบบกระจายอำนาจ-metalayer เพื่อสร้างอินสแตนซ์ DApp โดยอัตโนมัติ ชุดของฟังก์ชันการกระจายอำนาจที่ทำงานร่วมกันซึ่งครอบคลุม blockchains, DONs และ บริการภายนอก (หนึ่งในบริการภายนอกเหล่านี้อาจเป็นระบบขององค์กร ทำให้ metalayer มีประโยชน์สำหรับแอปพลิเคชันที่เกี่ยวข้องกับระบบองค์กรแบบเดิม) การคอมไพล์นั้นคล้ายกับคอมไพเลอร์และชุดพัฒนาซอฟต์แวร์ (SDK) สมัยใหม่ สนับสนุนโปรแกรมเมอร์ทั่วไปในการใช้ฮาร์ดแวร์ที่ต่างกันอย่างเต็มศักยภาพ สถาปัตยกรรมที่ประกอบด้วย CPU เอนกประสงค์และฮาร์ดแวร์พิเศษ เช่น GPU ตัวเร่งความเร็วการเรียนรู้ของเครื่องจักรหรือวงล้อมที่เชื่อถือได้ รูปที่ 3 นำเสนอแนวคิดนี้ในระดับแนวความคิด ไฮบริด smart contracts เป็นก้าวแรกสู่วิสัยทัศน์นี้และแนวคิดที่เราเรียกว่าสัญญาเมตา สัญญา Meta คือแอปพลิเคชันที่เข้ารหัสบนการกระจายอำนาจ metalayer และรวมลอจิกออนเชนโดยปริยาย (smart contracts) เช่นเดียวกับการคำนวณและการเชื่อมต่อของเชนระหว่าง blockchains ต่างๆ และออฟเชนที่มีอยู่ บริการ เมื่อพิจารณาถึงความต้องการการสนับสนุนด้านภาษาและคอมไพเลอร์ โมเดลการรักษาความปลอดภัยใหม่ๆ และ การประสานกันทางแนวคิดและทางเทคนิคของเทคโนโลยีที่แตกต่างกัน อย่างไรก็ตาม การตระหนักรู้ ของ metalayer แบบกระจายอำนาจที่แท้จริงคือเป้าหมายอันทะเยอทะยานที่เราปรารถนาในระยะยาว ขอบฟ้าเวลา อย่างไรก็ตาม ยังเป็นแบบจำลองในอุดมคติที่เป็นประโยชน์ที่ควรคำนึงถึงขณะอ่าน บทความนี้ไม่ได้ให้รายละเอียดไว้ที่นี่ แต่เป็นสิ่งที่เราวางแผนจะมุ่งเน้นในการทำงานในอนาคต Chainlink. การปรับขนาด: เป้าหมายที่มีความสำคัญโดดเด่นในการออกแบบที่พัฒนาของเราคือการทำให้ เครือข่าย Chainlink เพื่อตอบสนองความต้องการในการปรับขนาดที่เพิ่มขึ้นของระบบนิเวศ blockchain ด้วยความแออัดของเครือข่ายกลายเป็นปัญหาซ้ำซากในการไม่ได้รับอนุญาตที่มีอยู่ blockchains [86] การออกแบบ blockchain ใหม่และมีประสิทธิภาพยิ่งขึ้นกำลังจะถูกนำมาใช้ เช่น [103, 120, 203] เช่นเดียวกับเทคโนโลยีการปรับขนาดเลเยอร์ 2 เสริม เช่น [5, 12, 121, 141, 169, 186, 187]. บริการของ Oracle จะต้องบรรลุถึงเวลาแฝงและทรูพุต ที่ตอบสนองความต้องการด้านประสิทธิภาพของระบบเหล่านี้พร้อมทั้งลดค่าธรรมเนียมออนไลน์ให้เหลือน้อยที่สุด (เช่น ค่าน้ำมัน) สำหรับผู้ดำเนินการตามสัญญาและผู้ใช้ทั่วไป ด้วย DONs, Chainlink ฟังก์ชันการทำงานมีจุดมุ่งหมายที่จะก้าวไปอีกขั้นและมอบประสิทธิภาพที่สูงเพียงพอสำหรับระบบบนเว็บล้วนๆ DONs ได้รับประสิทธิภาพการทำงานส่วนใหญ่จากการใช้โปรโตคอลฉันทามติที่รวดเร็ว ตามคณะกรรมการ หรือไม่ได้รับอนุญาต ซึ่งรวมเข้ากับ blockchains พวกเขาสนับสนุน เราคาดหวังว่า DONs จำนวนมากที่มีการกำหนดค่าต่างกันจะทำงานแบบขนาน DApps และผู้ใช้สามารถนำทางการแลกเปลี่ยนในตัวเลือกที่เป็นเอกฉันท์ ตามความต้องการใช้งาน DONs อาจถูกมองว่าเป็นเทคโนโลยีเลเยอร์ 2 เราคาดหวังว่าในหมู่ บริการอื่นๆ DONs จะสนับสนุน Transaction Execution Framework (TEF) ซึ่ง อำนวยความสะดวกในการบูรณาการที่มีประสิทธิภาพของ DONs และ oracles กับประสิทธิภาพสูงอื่น ๆ ระบบเลเยอร์ 2—เช่น rollups ระบบที่รวมธุรกรรมของห่วงโซ่เข้าด้วยกันเพื่อให้บรรลุ การปรับปรุงประสิทธิภาพ เราแนะนำ TEF ในส่วนที่ 6

รูปที่ 3: รูปแบบแนวคิดที่แสดงให้เห็นถึงความตระหนักในอุดมคติของ metalayer ที่มีการกระจายอำนาจ สำหรับ ง่ายต่อการพัฒนา นักพัฒนาระบุ DApp ซึ่งเน้นด้วยสีชมพูเป็นเสมือน การประยุกต์ใช้ในโมเดลเครื่องจักรแบบครบวงจร คอมไพเลอร์แบบกระจายอำนาจ-metalayer จะสร้างฟังก์ชันการทำงานระหว่างกันที่สอดคล้องกันโดยอัตโนมัติ: smart contracts (แสดงแทน โดย SC), ตรรกะ (แสดงโดย exec) บน DONs, อะแดปเตอร์ที่เชื่อมต่อกับบริการภายนอกเป้าหมาย และอื่นๆ ตามที่ระบุไว้ในไฮไลต์สีเหลือง รูปที่ 4 แสดงแนวคิดว่า DONs ปรับปรุงมาตราส่วน blockchain (smart contract) อย่างไร โดยมุ่งเน้นธุรกรรมและ oracle-รายงานการประมวลผลของห่วงโซ่ แทนที่จะไปที่ โซ่ การเปลี่ยนแปลงในตำแหน่งหลักของการคำนวณนี้จะช่วยลดเวลาแฝงของธุรกรรมและ ค่าธรรมเนียมในขณะที่เพิ่มปริมาณการทำธุรกรรม การรักษาความลับ: บล็อกเชนให้ความโปร่งใสอย่างที่ไม่เคยมีมาก่อนสำหรับ smart contracts และแอปพลิเคชันที่พวกเขาตระหนัก แต่มีความตึงเครียดพื้นฐานระหว่างความโปร่งใสและการรักษาความลับ ตัวอย่างเช่น ในปัจจุบัน การแลกเปลี่ยนแบบกระจายอำนาจของผู้ใช้รูปที่ 4: ภาพแนวคิดที่แสดงให้เห็นว่า Oracle Networks แบบกระจายอำนาจปรับปรุงได้อย่างไร มาตราส่วนของ blockchain-เปิดใช้งาน smart contracts รูปที่ ก ⃝แสดง oracle แบบธรรมดา สถาปัตยกรรม ธุรกรรมจะถูกส่งโดยตรงไปยัง blockchain เช่นเดียวกับรายงาน oracle ดังนั้น blockchain ที่เน้นด้วยสีเหลืองจึงเป็นตำแหน่งหลักสำหรับการประมวลผลธุรกรรม รูปที่ B⃝แสดงการใช้ DON เพื่อรองรับสัญญาใน blockchain DON ประมวลผลธุรกรรมที่ปฏิบัติการได้พร้อมกับข้อมูลจากระบบภายนอกและส่งต่อ ผลลัพธ์—เช่น ธุรกรรมแบบรวมกลุ่มหรือการเปลี่ยนแปลงสถานะสัญญาอันเป็นผลมาจากผลของธุรกรรม—เป็น blockchain DON ที่เน้นด้วยสีเหลืองจึงเป็นตัวหลัก สถานที่สำหรับการประมวลผลธุรกรรม การดำเนินการจะถูกบันทึกไว้ในห่วงโซ่ ทำให้ง่ายต่อการตรวจสอบพฤติกรรมการแลกเปลี่ยน แต่ยังรวมถึง ทำให้ธุรกรรมทางการเงินของผู้ใช้ปรากฏต่อสาธารณะ ในทำนองเดียวกัน ข้อมูลจะถูกส่งต่อไปยังระบบอัจฉริยะ สัญญายังคงอยู่ในห่วงโซ่ ทำให้ข้อมูลดังกล่าวสามารถตรวจสอบได้อย่างสะดวก แต่ทำหน้าที่เป็น ความไม่จูงใจสำหรับผู้ให้บริการข้อมูลที่ต้องการมอบ smart contracts ด้วยความละเอียดอ่อนหรือ ข้อมูลที่เป็นกรรมสิทธิ์ เราเชื่อว่าเครือข่าย oracle จะมีบทบาทสำคัญในการกระตุ้นคนรุ่นต่อไป ระบบที่รวมความโปร่งใสโดยกำเนิดของ blockchains เข้ากับการปกป้องความลับแบบใหม่ ในบทความนี้ เราจะแสดงให้เห็นว่าพวกเขาจะทำเช่นนั้นได้อย่างไรโดยใช้แนวทางหลัก 3 ประการ: • อะแดปเตอร์ที่รักษาความลับ: สองเทคโนโลยีพร้อมการใช้งานตามแผน ในเครือข่ายของ Chainlink DECO [234] และ Town Crier [233] เปิดใช้งานโหนด oracle เพื่อ ดึงข้อมูลจากระบบลูกโซ่ในลักษณะที่ปกป้องความเป็นส่วนตัวและข้อมูลของผู้ใช้ การรักษาความลับ พวกเขาจะมีบทบาทสำคัญในการออกแบบอะแดปเตอร์สำหรับ DONs (ดูหัวข้อ 3.6.2 สำหรับรายละเอียดเกี่ยวกับเทคโนโลยีทั้งสองนี้) • การคำนวณที่เป็นความลับ: DONs สามารถปกปิดการคำนวณของตนจากการพึ่งพา blockchains การใช้การคำนวณแบบหลายฝ่ายที่ปลอดภัยและ/หรือสภาพแวดล้อมการดำเนินการที่เชื่อถือได้ ทำให้การรักษาความลับที่แข็งแกร่งยิ่งขึ้นยังสามารถทำได้ในโหนด DON ประมวลผลข้อมูลที่พวกเขาเองไม่สามารถมองเห็นได้

• รองรับระบบที่เป็นความลับเลเยอร์ 2: TEF ได้รับการออกแบบมาเพื่อรองรับระบบเลเยอร์ 2 ที่หลากหลาย ซึ่งหลายระบบใช้การพิสูจน์ความรู้แบบศูนย์เพื่อจัดเตรียม การรักษาความลับของธุรกรรมในรูปแบบต่างๆ เราจะหารือเกี่ยวกับแนวทางเหล่านี้ในส่วนที่ 3 (พร้อมรายละเอียดเพิ่มเติมในส่วนที่ 6 ภาคผนวก B.1 และภาคผนวก B.2) รูปที่ 5 นำเสนอมุมมองเชิงแนวคิดว่าข้อมูลที่ละเอียดอ่อนอาจไหลจากแหล่งภายนอกไปยัง smart contract ได้อย่างไรโดยใช้อะแดปเตอร์ที่รักษาความลับและ การคำนวณที่เป็นความลับใน DON รูปที่ 5: แผนภาพแนวคิดของการดำเนินการรักษาความลับใน DON บน ข้อมูลที่ละเอียดอ่อน (เน้นด้วยสีเหลือง) แหล่งข้อมูลที่ละเอียดอ่อน (วงกลมสีดำ) ในเว็บ เซิร์ฟเวอร์ถูกแยกไปยัง DON โดยใช้อะแดปเตอร์รักษาความลับ (สีน้ำเงิน เส้นลูกศรคู่) DON รับข้อมูลที่ได้รับ (วงกลมกลวง) จากอะแดปเตอร์เหล่านี้— ผลลัพธ์ของการใช้ฟังก์ชันหรือ เช่น การแบ่งปันความลับ กับแหล่งข้อมูลที่ละเอียดอ่อน ข้อมูล ไฟล์ปฏิบัติการบน DON อาจใช้การคำนวณที่เป็นความลับกับข้อมูลที่ได้รับ เพื่อสร้างรายงาน (วงกลมคู่) ซึ่งจะส่งผ่านอะแดปเตอร์ไปยัง blockchain เราเชื่อว่าเครื่องมืออันทรงพลังในการจัดการข้อมูลที่เป็นความลับจะเปิดกว้างในภาพรวม ช่วงของการใช้งาน ในบรรดาสิ่งเหล่านี้ ได้แก่ การเงินแบบกระจายอำนาจส่วนตัว (และแบบรวมศูนย์) การระบุตัวตนแบบกระจายอำนาจ การให้กู้ยืมแบบออนไลน์โดยใช้เครดิต และมีประสิทธิภาพมากขึ้นและ โปรโตคอลการรู้จักลูกค้าและการรับรองที่เป็นมิตรกับผู้ใช้ ดังที่เราอภิปรายในหัวข้อที่ 4 ความเป็นธรรมในการทำธุรกรรม: การออกแบบ blockchain ของวันนี้มีความสกปรกเล็กน้อย ความลับแบบเปิด: พวกมันถูกรวมศูนย์ไว้ชั่วคราว นักขุดและ validators สามารถสั่งซื้อทรานส์-การกระทำตามที่พวกเขาเลือก ลำดับธุรกรรมสามารถถูกจัดการโดยผู้ใช้ได้เช่นกัน ฟังก์ชั่นของค่าธรรมเนียมเครือข่ายที่พวกเขาจ่าย (เช่น ราคาน้ำมันใน Ethereum) และบางส่วน ขอบเขตโดยใช้ประโยชน์จากการเชื่อมต่อเครือข่ายที่รวดเร็ว การจัดการดังกล่าวสามารถทำได้ เช่น อยู่ในรูปแบบของ front-running ซึ่งมีบทบาทเชิงกลยุทธ์ เช่น นักขุดแร่ สังเกตธุรกรรมของผู้ใช้และแทรกธุรกรรมแสวงหาผลประโยชน์ของตนเองลงในรายการก่อนหน้า ตำแหน่งในบล็อกเดียวกัน - ขโมยเงินจากผู้ใช้อย่างมีประสิทธิภาพโดยใช้ประโยชน์จากความรู้ขั้นสูงเกี่ยวกับธุรกรรมของผู้ใช้ ตัวอย่างเช่น บอทอาจวางคำสั่งซื้อ ก่อนผู้ใช้ จากนั้นจึงสามารถใช้ประโยชน์จากการเพิ่มขึ้นของราคาสินทรัพย์ที่เกิดจาก การค้าของผู้ใช้ ดำเนินการล่วงหน้าโดยบอทบางตัวที่เป็นอันตรายต่อผู้ใช้ทั่วไป—คล้ายกับความถี่สูง การซื้อขายบนวอลล์สตรีท—แพร่หลายอยู่แล้วและมีการบันทึกไว้อย่างดี [90] เช่นเดียวกับที่เกี่ยวข้อง การโจมตีเช่น back-running [159] และการเลียนแบบธุรกรรมอัตโนมัติ [195] ข้อเสนอเพื่อจัดระบบการแสวงประโยชน์ตามคำสั่งโดยนักขุดยังปรากฏให้เห็นเมื่อเร็วๆ นี้ [110] เทคโนโลยีเลเยอร์ 2 เช่น rollups ไม่สามารถแก้ปัญหาได้ แต่เป็นเพียงการรวมศูนย์อีกครั้ง การสั่งซื้อ โดยวางไว้ในมือของเอนทิตีที่สร้าง rollup เป้าหมายประการหนึ่งของเราคือการแนะนำ Chainlink บริการที่เรียกว่า Fair Sequencing บริการ (FSS) [137] FSS ช่วยให้นักออกแบบ smart contract รับประกันการสั่งซื้อที่ยุติธรรมสำหรับพวกเขา และหลีกเลี่ยงการโจมตีแบบ front-runing, back-running และที่เกี่ยวข้องกับธุรกรรมของผู้ใช้ รวมถึงธุรกรรมประเภทอื่นๆ เช่น oracle การส่งรายงาน เอฟเอสเอส ช่วยให้ DON นำแนวคิดต่างๆ ไปใช้ เช่น แนวคิดที่เข้มงวดและชั่วคราวเกี่ยวกับความเป็นระเบียบเรียบร้อยที่นำมาใช้ใน [144] FSS ยังสามารถลดเครือข่ายของผู้ใช้ได้อีกด้วย ค่าธรรมเนียม (เช่น ค่าน้ำมัน) โดยสรุป ใน FSS ธุรกรรมจะผ่าน DON แทนที่จะเผยแพร่โดยตรงไปยังเป้าหมาย smart contract DON สั่งธุรกรรมแล้วส่งต่อ พวกเขาเป็นไปตามสัญญา รูปที่ 6: ตัวอย่างว่า FSS มีประโยชน์อย่างไร มะเดื่อ ก ⃝แสดงให้เห็นว่านักขุดใช้ประโยชน์จากมันอย่างไร อำนาจรวมศูนย์ในการทำธุรกรรมการสั่งซื้ออาจสลับคู่ของการทำธุรกรรม: ธุรกรรม 1⃝ มาถึงก่อน 2⃝ แต่คนขุดแร่จะเรียงลำดับตามหลัง 2⃝ แทน ในทางตรงกันข้าม รูปที่ B⃝แสดง DON กระจายอำนาจกระบวนการสั่งซื้อระหว่างโหนด DON อย่างไร ถ้าครบองค์ประชุม โหนดที่แท้จริงได้รับ 1⃝ก่อน 2⃝, FSS จะทำให้ 1⃝ปรากฏก่อน 2⃝บนลูกโซ่— ป้องกันไม่ให้นักขุดเรียงลำดับใหม่โดยการแนบหมายเลขลำดับที่บังคับใช้ตามสัญญา รูปที่ 6 เปรียบเทียบการขุดมาตรฐานกับ FSS มันแสดงให้เห็นว่าในการทำเหมืองแบบมาตรฐานกระบวนการสั่งซื้อธุรกรรมจะรวมศูนย์กับผู้ขุดและขึ้นอยู่กับ การยักย้าย เช่น การเรียงลำดับธุรกรรมคู่ใหม่ที่เกี่ยวข้องกับการมาถึง ครั้ง ในทางตรงกันข้าม ใน FSS กระบวนการจะมีการกระจายอำนาจระหว่างโหนด DON สมมุติ องค์ประชุมของโหนดที่ซื่อสัตย์ FSS ช่วยบังคับใช้นโยบาย เช่น การสั่งซื้อชั่วคราว การทำธุรกรรมลดโอกาสในการจัดการโดยนักขุดและหน่วยงานอื่น ๆ นอกจากนี้ เนื่องจากผู้ใช้ไม่จำเป็นต้องแข่งขันเพื่อสั่งซื้อพิเศษตามราคาน้ำมัน พวกเขาสามารถจ่ายราคาน้ำมันที่ค่อนข้างต่ำได้ (ในขณะที่ธุรกรรมจาก DON สามารถแบทช์ได้ เพื่อประหยัดน้ำมัน) การลดความน่าเชื่อถือ: เป้าหมายทั่วไปของเราในการออกแบบ DONs คือการอำนวยความสะดวกอย่างมาก ชั้นการสนับสนุนที่เชื่อถือได้สำหรับ smart contracts และระบบที่ขึ้นอยู่กับ oracle อื่นๆ โดยการกระจายอำนาจ เครื่องมือการเข้ารหัส และการค้ำประกันทางเศรษฐกิจแบบเข้ารหัส A DON มีการกระจายอำนาจ และผู้ใช้สามารถเลือกจาก DON ใดๆ ที่มีอยู่ที่ รองรับเชนหลักที่พวกเขาต้องการใช้งานหรือวางไข่เพิ่มเติม DONs กับคณะกรรมการของโหนดที่พวกเขาไว้วางใจ อย่างไรก็ตาม สำหรับบางแอปพลิเคชัน โดยเฉพาะ smart contracts ผู้ใช้ Chainlink อาจ นิยมใช้โมเดลความน่าเชื่อถือที่ปฏิบัติต่อเชนหลักที่ได้รับการสนับสนุนจาก DON ว่าน่าเชื่อถือมากกว่า กว่า DON เอง สำหรับผู้ใช้ดังกล่าว เรามีหรือวางแผนที่จะรวมเข้ากับ สถาปัตยกรรมของเครือข่าย Chainlink กลไกจำนวนหนึ่งที่เปิดใช้งานสัญญา บนสายโซ่หลักเพื่อเสริมสร้างการประกันความปลอดภัยที่จัดทำโดย DONs ในขณะที่อยู่ที่ ในขณะเดียวกันก็บังคับใช้การป้องกันความเป็นไปได้ของแหล่งข้อมูลที่เสียหาย เช่น เว็บเซิร์ฟเวอร์ที่ DON รับข้อมูล เราอธิบายกลไกเหล่านี้ในมาตรา 7 โดยอยู่ภายใต้หัวข้อหลัก 5 หัวข้อ: • การรับรองความถูกต้องแหล่งข้อมูล: เครื่องมือที่ช่วยให้ผู้ให้บริการข้อมูลสามารถลงนามแบบดิจิทัล ข้อมูลของพวกเขาและด้วยเหตุนี้จึงเสริมสร้างห่วงโซ่การดูแลระหว่างต้นทางและ อาศัยสัญญา • DON รายงานส่วนน้อย: แฟล็กที่ออกโดยส่วนย่อยของโหนด DON ที่ สังเกตเห็นความผิดพลาดส่วนใหญ่ใน DON • รางป้องกัน: ตรรกะบนสายโซ่หลักที่ตรวจจับสภาวะผิดปกติและการหยุดชั่วคราว หรือระงับการดำเนินสัญญา (หรือเรียกใช้การแก้ไขอื่น ๆ ) • การกำกับดูแลที่ลดความน่าเชื่อถือ: การใช้การอัปเดตทีละน้อยเพื่ออำนวยความสะดวกในการตรวจสอบชุมชน ตลอดจนการแทรกแซงฉุกเฉินแบบกระจายอำนาจเพื่อความรวดเร็ว การตอบสนองต่อความล้มเหลวของระบบ • การรับรองความถูกต้องเอนทิตีแบบกระจายอำนาจ: การใช้โครงสร้างพื้นฐานคีย์สาธารณะ (PKI) เพื่อ ระบุเอนทิตีในเครือข่าย Chainlink รูปที่ 7 นำเสนอแผนผังแนวคิดของเป้าหมายการลดความไว้วางใจของเรา การรักษาความปลอดภัยตามสิ่งจูงใจ (เศรษฐกิจเข้ารหัส): การกระจายอำนาจของการสร้างรายงานทั่วทั้งโหนด oracle ช่วยให้มั่นใจในความปลอดภัย แม้ว่าบางโหนดจะเสียหายก็ตาม

รูปที่ 7: การแสดงแนวคิดเป้าหมายการลดความไว้วางใจของ Chainlink ซึ่งก็คือ ลดความจำเป็นของผู้ใช้สำหรับพฤติกรรมที่ถูกต้องของ DON และแหล่งข้อมูล เช่น เว็บ เซิร์ฟเวอร์ ไฮไลท์สีเหลืองในรูปบ่งบอกถึงตำแหน่งการลดความไว้วางใจ: DON และ ชุดเว็บเซิร์ฟเวอร์ส่วนบุคคลหรือส่วนน้อย ไฮไลท์สีชมพูบ่งบอกถึงส่วนประกอบของระบบ ที่มีความน่าเชื่อถือสูงโดยสมมติฐาน: สัญญาใน blockchain และส่วนใหญ่ ของเว็บเซิร์ฟเวอร์ กล่าวคือ เว็บเซิร์ฟเวอร์โดยรวม สิ่งสำคัญไม่แพ้กันคือต้องแน่ใจว่าโหนดมีแรงจูงใจทางการเงินเพื่อให้ทำงานได้อย่างถูกต้อง การปักหลัก เช่น กำหนดให้โหนดต้องจัดเตรียมการฝากเงินของ LINK และการตัดอย่างเจ็บแสบ (ยึด) เงินฝากเหล่านี้ในกรณีที่ประพฤติตัวไม่เหมาะสม จะมีบทบาทสำคัญใน Chainlink เป็นการออกแบบสิ่งจูงใจที่สำคัญที่ใช้อยู่แล้วใน blockchains จำนวนหนึ่ง เช่น [81, 103, 120, 204] อย่างไรก็ตาม การปักหลักใน Chainlink ดูแตกต่างอย่างมากจาก staking ในแบบสแตนด์อโลน blockchainส. การปักหลักใน blockchains มีจุดมุ่งหมายเพื่อป้องกันการโจมตีโดยความเห็นพ้องต้องกัน มันมี เป้าหมายที่แตกต่างใน Chainlink: เพื่อให้แน่ใจว่ามีการส่งรายงาน oracle ที่ถูกต้องทันเวลา ระบบ staking ที่ออกแบบมาอย่างดีสำหรับเครือข่าย oracle ควรทำให้เกิดการโจมตี เช่น การติดสินบน ไม่เป็นประโยชน์สำหรับฝ่ายตรงข้าม แม้ว่าเป้าหมายจะเป็น smart contract ที่มีค่าสูง มูลค่าทางการเงิน ในบทความนี้ เรานำเสนอแนวทางทั่วไปสำหรับ staking ใน Chainlink ด้วยสามคีย์ นวัตกรรม:1. โมเดลฝ่ายตรงข้ามที่ทรงพลังซึ่งครอบคลุมการโจมตีที่ถูกมองข้ามที่มีอยู่ แนวทาง ตัวอย่างหนึ่งคือสิ่งที่เราเรียกว่าการติดสินบนในอนาคต นี่คือรูปแบบหนึ่งของ การติดสินบนที่กำหนดว่าโหนดใดจะได้รับสินบนตามเงื่อนไข เช่น มีการรับประกันสินบนล่วงหน้าให้กับโหนดที่กลไก staking เลือกที่ สุ่มสำหรับบทบาทเฉพาะ (เช่น การกระตุ้นให้มีการตัดสินรายงาน) 2. ผลกระทบแบบซุปเปอร์เชิงเส้น staking หมายความว่าอย่างไม่เป็นทางการที่จะประสบความสำเร็จ ฝ่ายตรงข้ามต้องมีงบประมาณ $B มากกว่าเงินฝากรวมของ oracle ทั้งหมด โหนด แม่นยำยิ่งขึ้น เราหมายถึงว่าในฐานะฟังก์ชันของ n \(B(n) ≫\)dn ใน เครือข่ายของ n oracle โหนดแต่ละโหนดด้วยจำนวนเงินฝากคงที่ $d (อย่างเป็นทางการมากขึ้น \(B(n) is asymptotically larger in n than \)dn) รูปที่ 8 ให้มุมมองแนวความคิดของ คุณสมบัตินี้ 3. กรอบงานสิ่งจูงใจโดยนัย (IIF) ซึ่งเป็นโมเดลสิ่งจูงใจที่เราได้คิดค้นขึ้น ครอบคลุมสิ่งจูงใจที่วัดผลได้เชิงประจักษ์ นอกเหนือจากการฝากที่ชัดเจน staking กองทุน รวมถึงโอกาสค่าธรรมเนียมในอนาคตของโหนด IIF ขยายแนวคิดเรื่อง เดิมพันเกินกว่าเงินฝากโหนดที่ชัดเจน รูปที่ 8: แผนภาพแนวคิดที่แสดงมาตราส่วนซุปเปอร์เชิงเส้นใน Chainlink staking ที่ สินบน $B(n) ที่ฝ่ายตรงข้ามต้องการจะเติบโตเร็วกว่าใน n มากกว่าเงินฝากรวม $dn ของโหนด oracle ทั้งหมด เราแสดงให้เห็นว่า IIF และ super-linear staking ส่งผลกระทบร่วมกันและกระตุ้นให้เกิดสิ่งที่เราเป็นอย่างไร เรียกวงจรความมั่นคงทางเศรษฐกิจที่ดีสำหรับเครือข่าย oracle เมื่อมีผู้ใช้ใหม่เข้ามา

ระบบ ซึ่งเพิ่มรายได้ที่เป็นไปได้ในอนาคตจากการรันโหนด Chainlink ต้นทุนส่วนเพิ่มของความมั่นคงทางเศรษฐกิจลดลงสำหรับผู้ใช้ในปัจจุบันและอนาคต ในระบอบการปกครองของ ความต้องการที่ยืดหยุ่น ต้นทุนที่ลดลงนี้จูงใจผู้ใช้เพิ่มเติมให้ใช้ประโยชน์จาก เครือข่ายที่สืบทอดมาอย่างต่อเนื่องในวงจรคุณธรรมที่ต่อเนื่อง หมายเหตุ: แม้ว่าเอกสารไวท์เปเปอร์นี้จะสรุปองค์ประกอบที่สำคัญของวิสัยทัศน์ของเราเกี่ยวกับวิวัฒนาการของ Chainlink แต่ก็ไม่เป็นทางการและมีรายละเอียดเฉพาะด้านเทคนิคเพียงเล็กน้อย เราวางแผนที่จะ เผยแพร่เอกสารทางเทคนิคที่มุ่งเน้นเกี่ยวกับคุณลักษณะและแนวทางเพิ่มเติมเมื่อมีการพัฒนา นอกจากนี้ สิ่งสำคัญคือต้องเน้นย้ำว่ามีองค์ประกอบหลายอย่างของวิสัยทัศน์ที่นำเสนอ ที่นี่ (การปรับปรุงขนาด เทคโนโลยีการรักษาความลับ FSS ฯลฯ) สามารถและจะเป็นได้ ปรับใช้ในรูปแบบเบื้องต้นก่อนที่ DONs ขั้นสูงจะกลายเป็นคุณสมบัติพื้นฐานของ Chainlink. 1.3 องค์กรของบทความนี้ เรานำเสนอรูปแบบการรักษาความปลอดภัยและสัญลักษณ์ของเราในส่วนที่ 2 และร่างโครงร่างการกระจายอำนาจ Oracle Network API ในส่วนที่ 3 ในส่วนที่ 4 เราจะนำเสนอตัวอย่างจำนวนหนึ่ง แอปพลิเคชันที่ DONs มีแพลตฟอร์มการปรับใช้ที่น่าดึงดูด ผู้อ่านสามารถ เรียนรู้แนวคิดหลักส่วนใหญ่ของบทความนี้โดยการอ่านจนถึงจุดนี้ ส่วนที่เหลือของกระดาษมีรายละเอียดเพิ่มเติม เราอธิบายการจัดลำดับอย่างยุติธรรม บริการ (FSS) ในส่วนที่ 5 และกรอบการดำเนินการธุรกรรม (TEF) ในส่วนที่ 6 เราอธิบายแนวทางของเราในการลดความน่าเชื่อถือในส่วนที่ 7 เราพิจารณาบางประการ ข้อกำหนดการปรับใช้ DON ที่สำคัญ ได้แก่ การเปิดตัวคุณลักษณะเพิ่มเติม สมาชิกบัญชีแยกประเภทแบบไดนามิก และความรับผิดชอบในส่วนที่ 8 สุดท้ายนี้ ในส่วนที่ 9 เราให้ ภาพรวมของแนวทางการพัฒนาของเราในการออกแบบสิ่งจูงใจ เราสรุปไว้ในส่วนที่ 10 เราเพื่อช่วยผู้อ่านที่มีความคุ้นเคยกับแนวคิดในบทความนี้อย่างจำกัด ให้อภิธานศัพท์ในภาคผนวก A เราจะนำเสนอรายละเอียดเพิ่มเติมเกี่ยวกับอินเทอร์เฟซ DON และฟังก์ชันการทำงานในภาคผนวก B และแสดงตัวอย่างอะแดปเตอร์บางส่วนในภาคผนวก C ในภาคผนวก D เราอธิบายการเข้ารหัสลับแบบดั้งเดิมสำหรับแหล่งข้อมูลที่ลดความน่าเชื่อถือ การรับรองความถูกต้องที่เรียกว่าลายเซ็นการทำงาน และแนะนำรูปแบบใหม่ที่เรียกว่าลายเซ็นการทำงานแบบแยกส่วน เราหารือเกี่ยวกับข้อพิจารณาบางประการที่เกี่ยวข้องกับคณะกรรมการ การเลือกสำหรับ DONs ในภาคผนวก F

รูปแบบและเป้าหมายด้านความปลอดภัย

Oracle Network แบบกระจายอำนาจเป็นระบบกระจายอำนาจที่โดดเด่นซึ่งเราคาดหวังไว้ ในขั้นแรกให้ดำเนินการโดยทั่วไป—ถึงแม้จะไม่จำเป็น—โดยคณะกรรมการก็ตาม โปรโตคอลฉันทามติและดำเนินการโดยชุดของโหนด oracle DON ได้รับการออกแบบมาเป็นหลัก เพื่อเพิ่มความสามารถของ smart contract บนเชนหลักด้วยรายงาน oracle และบริการอื่น ๆ แต่สามารถให้บริการสนับสนุนแบบเดียวกันนั้นกับระบบที่ไม่ใช่ blockchain อื่น ๆ ได้ และดังนั้นจึงไม่จำเป็นต้องเชื่อมโยงกับสายโซ่หลักเฉพาะ

โมเดลและคุณสมบัติที่เราพิจารณาจึงไม่ขึ้นอยู่กับการใช้งานเป็นส่วนใหญ่ แอปพลิเคชันเฉพาะของ DON 2.1 รูปแบบสถาปัตยกรรมปัจจุบัน สิ่งสำคัญคือต้องเน้นว่า Chainlink วันนี้ไม่ใช่บริการแบบเสาหิน แต่เป็นบริการ กรอบการทำงานที่ไม่ได้รับอนุญาตซึ่งสามารถเปิดตัวที่แตกต่างและเป็นอิสระได้ เครือข่ายของโหนด oracle [77] เครือข่ายมีชุดตัวดำเนินการโหนดที่ต่างกันและ การออกแบบ นอกจากนี้ยังอาจแตกต่างในแง่ของประเภทของบริการที่พวกเขาให้ซึ่งสามารถทำได้ รวมถึง เช่น ฟีดข้อมูล หลักฐานการสำรอง การสุ่มที่ตรวจสอบได้ และอื่นๆ อื่นๆ ความแตกต่างอาจรวมถึงระดับของการกระจายอำนาจ ขนาดของเครือข่ายในแง่ของ ค่าล็อคที่รองรับ และพารามิเตอร์ระดับบริการต่างๆ เช่น ความถี่ของข้อมูล และความแม่นยำ โมเดลที่ไม่ได้รับอนุญาตของ Chainlink ส่งเสริมการเติบโตของระบบนิเวศที่ซึ่ง ผู้ให้บริการมีความเชี่ยวชาญในบริการที่พวกเขาสามารถจัดหาให้แก่ชุมชนได้ดีที่สุด นี้ โมเดลมีแนวโน้มที่จะส่งผลให้ต้นทุนต่อผู้ใช้ลดลงและคุณภาพการบริการสูงกว่าโมเดล ที่ต้องใช้โหนดและเครือข่ายทั้งหมดเพื่อให้บริการอย่างเต็มรูปแบบ ที่สามารถส่งต่อไปสู่การนำบริการต่างๆ มาใช้ทั่วทั้งระบบได้อย่างง่ายดาย ตัวส่วนร่วมของทรัพยากรที่มีให้กับโหนด ในขณะที่ Chainlink พัฒนาไปสู่การออกแบบที่ใช้ DON ใน Chainlink 2.0 เรายังคงดำเนินการต่อไป สนับสนุนรูปแบบของกรอบการทำงานแบบเปิดที่ไม่ได้รับอนุญาต โดยคำนึงถึงเป้าหมายของ มอบทางเลือกบริการที่หลากหลายให้กับผู้ใช้ทั่วโลกซึ่งส่งผลให้เกิดการจับคู่ที่ดีที่สุด ด้วยข้อกำหนดการใช้งานเฉพาะ 2.2 สมมติฐานที่เป็นเอกฉันท์ เราใช้คำว่า Decentralized Oracle Network เพื่อรวมฟังก์ชันการทำงานเต็มรูปแบบของ ระบบ oracle ที่เราอธิบาย: ทั้งโครงสร้างข้อมูลที่โหนด oracle รักษาและ API หลักที่ซ้อนกันอยู่ด้านบน เราใช้คำว่า ledger (ตัวพิมพ์เล็ก) แทนด้วย L เพื่อหมายถึงข้อมูลพื้นฐาน โครงสร้างที่ดูแลโดย DON และใช้เพื่อรองรับบริการเฉพาะที่มีให้ เราเน้นย้ำว่า DON กรอบงานของเราไม่ได้ถือว่า L เป็นระบบอิสระ blockchain: จุดประสงค์คือเพื่อรองรับ blockchains และระบบอื่นๆ บล็อกเชนคือ แน่นอนว่าเป็นวิธีหนึ่งในการตระหนักถึงบัญชีแยกประเภทที่น่าเชื่อถือ แต่ก็มีวิธีอื่นอีก เราคาดหวัง DONs ในหลายกรณีเพื่อรับรู้บัญชีแยกประเภทที่ซ่อนอยู่โดยใช้ Byzantine Fault Tolerant (BFT) ระบบ ซึ่งเกิดขึ้นก่อน blockchains มาก เช่น Bitcoin [174] เราใช้ BFT-พิมพ์สัญกรณ์และคุณสมบัติตลอดทั้งกระดาษเพื่อความสะดวกแม้ว่าเรา เน้นย้ำว่า DONs สามารถรับรู้ได้โดยใช้โปรโตคอลฉันทามติที่ไม่ได้รับอนุญาต ตามแนวคิดแล้ว บัญชีแยกประเภท L คือกระดานข่าวที่มีการเรียงลำดับข้อมูลเป็นเส้นตรง โดยทั่วไปแล้ว เราถือว่าบัญชีแยกประเภทมีคุณสมบัติหลักบางประการที่กำหนดโดยทั่วไป blockchains [115]. บัญชีแยกประเภทคือ: • ผนวกเท่านั้น: ข้อมูลเมื่อเพิ่มแล้วไม่สามารถลบหรือแก้ไขได้• สาธารณะ: ใครๆ ก็สามารถอ่านเนื้อหาได้ซึ่งมีความสอดคล้องกันตามเวลาใน มุมมองของผู้ใช้ทั้งหมด4 • พร้อมใช้งาน: ผู้เขียนที่ได้รับอนุญาตสามารถเขียนบัญชีแยกประเภทและอ่านได้ตลอดเวลา โดยใครก็ตามในเวลาที่เหมาะสม คุณสมบัติทางเลือกเป็นไปได้ในบัญชีแยกประเภทสำหรับ DON เมื่อรับรู้โดย a คณะกรรมการ ตัวอย่างเช่น การเข้าถึงการเขียนบัญชีแยกประเภทอาจถูกจำกัดไว้เฉพาะผู้ใช้บางราย เช่น อาจอ่านการเข้าถึงสำหรับบางแอปพลิเคชัน เช่น บัญชีแยกประเภทไม่จำเป็นต้องเปิดเผยต่อสาธารณะตามที่กำหนดไว้ ด้านบน ในทำนองเดียวกัน กฎบัญชีแยกประเภทอาจอนุญาตให้มีการแก้ไขหรือปรับปรุงข้อมูลได้ เราทำไม่ได้ อย่างไรก็ตาม ให้พิจารณาตัวแปรดังกล่าวอย่างชัดเจนในบทความนี้ การออกแบบโมดูลาร์ของ DONs สามารถรองรับ BFT สมัยใหม่ได้หลากหลาย โปรโตคอล เช่น Hotstuff[231] ทางเลือกที่แน่นอนจะขึ้นอยู่กับสมมติฐานของความไว้วางใจและ ลักษณะเครือข่ายระหว่างโหนด oracle โดยหลักการแล้ว A DON สามารถทำได้ ใช้ blockchain ที่ไม่ได้รับอนุญาตที่มีประสิทธิภาพสูงสำหรับบัญชีแยกประเภทในบทบาทที่สนับสนุน ระบบเลเยอร์ 2 หรือ blockchain ที่ปรับขนาดได้อย่างเท่าเทียมกัน ในทำนองเดียวกัน การผสมพันธุ์ก็เป็นไปได้เช่นกัน: โดยหลักการแล้ว DON สามารถประกอบด้วยโหนดที่เป็น validators ในโหนดที่มีอยู่ blockchain เช่น ในระบบ Proof-of-Stake ซึ่งคณะกรรมการได้รับเลือกให้ดำเนินการ ธุรกรรม เช่น [8, 81, 120, 146, 204] โหมดการทำงานเฉพาะนี้ต้องการสิ่งนั้น โหนดทำงานในลักษณะการใช้งานสองทาง กล่าวคือ ทำงานทั้งแบบ blockchain โหนด และ DON โหนด (ดูหัวข้อ 8.2 สำหรับการอภิปรายเทคนิคเพื่อให้เกิดความต่อเนื่องในการเปลี่ยนแปลง คณะกรรมการและภาคผนวก F สำหรับคำเตือนบางประการเกี่ยวกับการคัดเลือกคณะกรรมการแบบสุ่ม) ในทางปฏิบัติ ในอัลกอริธึม BFT สมัยใหม่ โหนดจะเซ็นข้อความแบบดิจิทัลในบัญชีแยกประเภท เราถือว่าเพื่อความสะดวกที่ L มีคีย์สาธารณะที่เกี่ยวข้อง pkL และเนื้อหาดังกล่าว ได้รับการลงนามโดยคีย์ส่วนตัวที่เกี่ยวข้อง สัญกรณ์ทั่วไปนี้ใช้ได้แม้เมื่อใดก็ตาม ข้อมูลบน L ได้รับการลงนามโดยใช้ลายเซ็นเกณฑ์ 5 ลายเซ็นเกณฑ์นั้นสะดวก เนื่องจากเปิดใช้งานข้อมูลประจำตัวถาวรสำหรับ DON แม้ว่าจะมีการเปลี่ยนแปลงสมาชิกภาพก็ตาม โหนดที่ทำงานอยู่ (ดูภาคผนวก B.1.3.) เราจึงถือว่า skL มีการแบ่งปันแบบเป็นความลับ ในลักษณะ (k, n) -threshold สำหรับพารามิเตอร์ความปลอดภัยบางตัว k เช่น k = 2f + 1 และ n = 3f + 1 โดยที่ f คือจำนวนโหนดที่อาจผิดพลาด (โดยเลือก k ในข้อนี้ เรารับรองว่าโหนดที่มีข้อผิดพลาดจะไม่สามารถเรียนรู้ skL หรือติดตั้งการปฏิเสธการให้บริการได้ โจมตีขัดขวางการใช้งาน) ข้อความบน L อยู่ในรูปแบบ M = (m, z) โดยที่ m คือสตริง และ z เป็นค่าเฉพาะ หมายเลขดัชนีตามลำดับ ในกรณีที่เป็นไปได้ เราจะเขียนข้อความในรูปแบบ m = ⟨ประเภทข้อความ : เพย์โหลด⟩. ประเภทข้อความ MessageType คือน้ำตาลเชิงวากยสัมพันธ์ที่ระบุการทำงานของข้อความใดข้อความหนึ่ง 4ในกรณีที่ blockchain ที่ไม่มีจุดสิ้นสุดรับรู้บัญชีแยกประเภท โดยทั่วไปความไม่สอดคล้องกันจะถูกสรุปออก ออกไปโดยไม่สนใจบล็อกที่ลึกเกินไปหรือ "การตัดแต่งกิ่ง" [115] 5ในทางปฏิบัติ ฐานโค้ดบางฐาน เช่น LibraBFT [205] ซึ่งเป็นรูปแบบหนึ่งของ Hotstuff ได้ถูกนำมาใช้ในปัจจุบัน ลายเซ็นหลายลายเซ็น แทนที่จะเป็นลายเซ็นตามเกณฑ์ การซื้อขายลดความซับซ้อนในการสื่อสาร วิศวกรรมที่เรียบง่ายกว่า ด้วยค่าใช้จ่ายเพิ่มเติมบางส่วน โหนด oracle สามารถต่อท้ายลายเซ็นเกณฑ์กับข้อความได้ เขียนถึง L แม้ว่าโปรโตคอลฉันทามติที่ใช้สำหรับ L จะไม่ใช้งานก็ตาม2.3 สัญกรณ์ เราแสดงชุดของโหนด n oracle ที่รันบัญชีแยกประเภทโดย O = {Oi}n ผม=1. เช่นก ชุดของโหนดมักเรียกว่าคณะกรรมการ เพื่อความง่าย เราถือว่าเซตของ oracles การใช้ฟังก์ชัน DON เช่น บริการที่อยู่ด้านบนของ L นั้นเหมือนกับ ที่รักษา L ไว้แต่ก็สามารถแยกแยะได้ เราให้ pki แสดงถึงกุญแจสาธารณะของ ผู้เล่น Oi และเล่นสกีคีย์ส่วนตัวที่เกี่ยวข้อง อัลกอริธึม BFT ส่วนใหญ่ต้องการโหนดอย่างน้อย n = 3f + 1 โดยที่ f คือจำนวนของ โหนดที่อาจผิดพลาด โหนดที่เหลือมีความซื่อสัตย์ในแง่ที่พวกเขาปฏิบัติตาม โปรโตคอลตรงตามที่ระบุไว้ เราเรียกคณะกรรมการ O ว่าตรงไปตรงมาหากเป็นไปตามนี้ ข้อกำหนด กล่าวคือ มีโหนดที่ซื่อสัตย์มากกว่า 2/3 เศษส่วน เว้นแต่เป็นอย่างอื่น ระบุไว้ เราถือว่า O ซื่อสัตย์ (และเป็นแบบจำลองของการทุจริตแบบคงที่) เราใช้ pkO / skO สลับกันได้กับ pkL / skL ขึ้นอยู่กับบริบท เราให้ σ = Sigpk[m] แทนลายเซ็นบนข้อความ m เทียบกับ pk กล่าวคือ การใช้ sk คีย์ส่วนตัวที่เกี่ยวข้อง ให้ตรวจสอบ(pk, σ, m) →{false, true} แสดงถึงอัลกอริธึมการตรวจสอบลายเซ็นที่สอดคล้องกัน (เราปล่อยให้การสร้างคีย์โดยนัยตลอดทั้งรายงาน) เราใช้สัญกรณ์ S เพื่อแสดงถึงแหล่งข้อมูล และ S เพื่อแสดงถึงชุดเต็มของ แหล่งที่มาของ nS ในบริบทที่กำหนด เราแสดงโดย MAINCHAIN ว่าเป็นการเปิดใช้งานสัญญาอัจฉริยะ blockchain สนับสนุนโดย DON เราใช้คำว่าอาศัยสัญญาเพื่อแสดงถึงความฉลาด สัญญาบน MAINCHAIN ที่สื่อสารกับ DON และใช้สัญลักษณ์ SC เพื่อ แสดงถึงสัญญาดังกล่าว โดยทั่วไปเราถือว่า DON รองรับ MAINCHAIN สายหลักเดียว แม้ว่าจะสามารถรองรับหลายสายโซ่ดังกล่าวได้ ดังที่เราแสดงในตัวอย่างในส่วนที่ 4 DON สามารถและโดยทั่วไปจะสนับสนุนสัญญาที่ต้องพึ่งพาหลายสัญญาใน MAINCHAIN (เช่น ตามที่กล่าวไว้ข้างต้น DON สามารถรองรับบริการที่ไม่ใช่ blockchain ได้) 2.4 หมายเหตุเกี่ยวกับโมเดลความน่าเชื่อถือ ตามที่ระบุไว้ข้างต้น DONs อาจถูกสร้างขึ้นบนโปรโตคอลฉันทามติที่อิงจากคณะกรรมการ และเรา คาดว่าพวกเขาจะใช้โปรโตคอลดังกล่าวโดยทั่วไป มีข้อโต้แย้งที่รุนแรงมากมายว่า หนึ่งในสองทางเลือก blockchains ตามคณะกรรมการหรือไม่ได้รับอนุญาต การรักษาความปลอดภัยที่แข็งแกร่งกว่าที่อื่น สิ่งสำคัญคือต้องตระหนักว่าการรักษาความปลอดภัยของคณะกรรมการเทียบกับไม่ได้รับอนุญาต ระบบการกระจายอำนาจนั้นไม่สามารถเทียบเคียงได้ การประนีประนอมกับ PoW หรือ PoS blockchain ด้วยการโจมตี 51% ฝ่ายตรงข้ามจะต้องได้รับทรัพยากรส่วนใหญ่ชั่วคราวและ อาจไม่เปิดเผยชื่อ เช่น โดยการเช่าพลังงาน hash ในระบบ PoW เช่น การโจมตีในทางปฏิบัติได้ส่งผลกระทบต่อ blockchains หลายประการแล้ว [200, 34] ในทางตรงกันข้าม การประนีประนอมต่อระบบที่ใช้คณะกรรมการหมายถึงการทำลายจำนวนเกณฑ์ (โดยทั่วไปคือหนึ่งในสาม) ของโหนด โดยที่โหนดอาจเป็นที่รู้จักต่อสาธารณะ มีทรัพยากรที่ดี และหน่วยงานที่น่าเชื่อถือ ในทางกลับกัน ระบบที่อิงตามคณะกรรมการ (รวมถึง "ไฮบริด" ที่ไม่ได้รับอนุญาต ระบบที่สนับสนุนคณะกรรมการ) สามารถรองรับการทำงานได้มากกว่าที่เคร่งครัดต่อระบบที่ไม่มีภารกิจ ซึ่งรวมถึงความสามารถในการรักษาความลับถาวรเช่น คีย์การลงนามและ/หรือการเข้ารหัส—ความเป็นไปได้อย่างหนึ่งในการออกแบบของเรา เราเน้นย้ำว่าโดยหลักการแล้ว DONs สามารถสร้างขึ้นบนยอดของคณะกรรมการหรือ โปรโตคอลฉันทามติที่ไม่ได้รับอนุญาตและผู้ปรับใช้ DON อาจเลือกที่จะนำไปใช้ในที่สุด ทั้งสองวิธี การเสริมรูปแบบความไว้วางใจ: คุณลักษณะสำคัญของ Chainlink ในปัจจุบันคือความสามารถของผู้ใช้ในการ เลือกโหนดตามบันทึกการกระจายอำนาจของประวัติประสิทธิภาพตามที่กล่าวไว้ ในมาตรา 3.6.4 กลไก staking และกรอบงานสิ่งจูงใจโดยนัยที่เราแนะนำในส่วนที่ 9 ร่วมกันก่อให้เกิดการออกแบบกลไกที่มีขอบเขตกว้างและเข้มงวด เฟรมเวิร์กที่จะเสริมศักยภาพผู้ใช้ด้วยความสามารถที่เพิ่มขึ้นอย่างมากในการวัดความปลอดภัยของ DONs กรอบงานเดียวกันนี้จะทำให้ DONs เป็นไปได้ด้วย เพื่อบังคับใช้ข้อกำหนดด้านความปลอดภัยต่างๆ บนโหนดที่เข้าร่วมและรับรองการทำงาน ภายในโมเดลความไว้วางใจที่แข็งแกร่ง นอกจากนี้ยังสามารถใช้เครื่องมือที่อธิบายไว้ในเอกสารนี้สำหรับ DONs เพื่อบังคับใช้ข้อกำหนดโมเดลความน่าเชื่อถือพิเศษ เช่น การปฏิบัติตามข้อกำหนดด้านกฎระเบียบ สำหรับ เช่น การใช้เทคนิคที่กล่าวถึงในหัวข้อ 4.3 โหนดสามารถแสดงหลักฐานได้ คุณลักษณะของผู้ดำเนินการโหนด เช่น อาณาเขตของการดำเนินการ ที่สามารถนำมาใช้เพื่อช่วยได้ บังคับใช้การปฏิบัติตาม เช่น กฎการคุ้มครองข้อมูลทั่วไป (GDPR) มาตรา 3 (“ขอบเขตอาณาเขต”) [105] การปฏิบัติตามกฎระเบียบดังกล่าวอาจเป็นเรื่องที่ท้าทาย พบกันในระบบกระจายอำนาจ [45] นอกจากนี้ ในส่วนที่ 7 เราจะหารือถึงแผนการเสริมสร้างความแข็งแกร่งของ DONs ผ่านกลไกการลดความไว้วางใจบนเครือข่ายหลักที่พวกเขาสนับสนุน

Oracle Network Interface แบบกระจายอำนาจและ Ca-

ความพิการ ที่นี่เราสรุปสั้นๆ เกี่ยวกับความสามารถของ DONs ในแง่ของความเรียบง่ายแต่ทรงพลัง อินเทอร์เฟซที่พวกเขาได้รับการออกแบบมาให้ตระหนัก แอปพลิเคชันบน DON ประกอบด้วยโปรแกรมปฏิบัติการและอะแดปเตอร์ ปฏิบัติการได้คือ โปรแกรมที่มีตรรกะหลักเป็นโปรแกรมที่กำหนดขึ้น คล้ายคลึงกับ smart contract โปรแกรมเรียกทำงานยังมีตัวริเริ่มที่มาพร้อมกันจำนวนหนึ่ง ซึ่งเป็นโปรแกรมที่เรียกใช้รายการ ชี้ให้เห็นในตรรกะของปฏิบัติการเมื่อเกิดเหตุการณ์ที่กำหนดไว้ล่วงหน้า เช่น ในบางช่วงเวลา (เช่นงาน cron) เมื่อราคาเกินเกณฑ์ ฯลฯ—เหมือนกับ Keepers (ดูหัวข้อ 3.6.3) อะแดปเตอร์จัดเตรียมอินเทอร์เฟซให้กับทรัพยากรนอกสายโซ่และอาจถูกเรียกโดย ตัวเริ่มต้นหรือตรรกะหลักในโปรแกรมเรียกทำงาน เนื่องจากพฤติกรรมของพวกเขาอาจขึ้นอยู่กับสิ่งนั้น ของทรัพยากรภายนอก ตัวเริ่มต้น และอะแดปเตอร์อาจทำงานโดยไม่ได้กำหนดไว้ เราอธิบายอินเทอร์เฟซสำหรับนักพัฒนา DON และการทำงานของโปรแกรมปฏิบัติการและ อะแดปเตอร์ในแง่ของทรัพยากรทั้งสามที่โดยทั่วไปใช้เพื่อกำหนดลักษณะระบบคอมพิวเตอร์: เครือข่าย การคำนวณ และพื้นที่เก็บข้อมูล เราให้ภาพรวมโดยย่อของแต่ละสิ่งเหล่านี้ แหล่งข้อมูลด้านล่างและให้รายละเอียดเพิ่มเติมในภาคผนวก B

3.1 เครือข่าย อะแดปเตอร์คืออินเทอร์เฟซที่โปรแกรมปฏิบัติการที่ทำงานบน DON สามารถส่งและ รับข้อมูลจากระบบ offf-DON อะแดปเตอร์อาจถูกมองว่าเป็นลักษณะทั่วไปของ อะแดปเตอร์ที่ใช้ใน Chainlink วันนี้ [20] อะแดปเตอร์อาจเป็นแบบสองทิศทาง—กล่าวคือ ไม่สามารถดึงได้ แต่ส่งข้อมูลจาก DON ไปยังเว็บเซิร์ฟเวอร์ พวกเขายังสามารถใช้ประโยชน์ได้ โปรโตคอลแบบกระจายรวมถึงฟังก์ชันการเข้ารหัสเช่นหลายฝ่ายที่ปลอดภัย การคำนวณ รูปที่ 9: อะแดปเตอร์ที่เชื่อมต่อ DON ซึ่งแสดงด้วย DON1 พร้อมด้วยทรัพยากรที่แตกต่างกันจำนวนหนึ่ง รวมถึง DON อื่น ซึ่งแสดงด้วย DON2, blockchain (สายหลัก) และ mempool, ที่จัดเก็บข้อมูลภายนอก, เว็บเซิร์ฟเวอร์ และอุปกรณ์ IoT (ผ่านเว็บเซิร์ฟเวอร์) ตัวอย่างของรีซอร์สภายนอกที่อาจสร้างอะแด็ปเตอร์จะแสดงขึ้น ในรูปที่ 9 ประกอบด้วย: • Blockchains: อะแดปเตอร์สามารถกำหนดวิธีการส่งธุรกรรมไปยัง blockchain และ วิธีอ่านบล็อก ธุรกรรมแต่ละรายการ หรือสถานะอื่น ๆ จากบล็อกนั้น อะแดปเตอร์ ยังสามารถกำหนดสำหรับ mempool ของ blockchain ได้ (ดูหัวข้อ 3.5) • เว็บเซิร์ฟเวอร์: อะแดปเตอร์สามารถกำหนด API ที่อาจดึงข้อมูลได้ จากเว็บเซิร์ฟเวอร์รวมถึงระบบเดิมที่ไม่ได้ดัดแปลงเป็นพิเศษ กำลังเชื่อมต่อกับ DONs อะแดปเตอร์ดังกล่าวยังสามารถรวม API เพื่อส่งข้อมูลไปได้ เซิร์ฟเวอร์ดังกล่าว เว็บเซิร์ฟเวอร์ที่ DON เชื่อมต่ออาจทำหน้าที่เป็นเกตเวย์ ไปยังแหล่งข้อมูลเพิ่มเติม เช่น อุปกรณ์อินเทอร์เน็ตออฟธิงส์ (IoT)• ที่จัดเก็บข้อมูลภายนอก: อะแดปเตอร์สามารถกำหนดวิธีการอ่านและเขียนไปยังที่จัดเก็บข้อมูลได้ บริการภายนอก DON เช่น ระบบไฟล์แบบกระจายอำนาจ [40, 188] หรือระบบคลาวด์ การจัดเก็บ • DONs อื่นๆ: อะแดปเตอร์สามารถดึงและส่งข้อมูลระหว่าง DONs เราคาดหวังว่าการปรับใช้งานเบื้องต้นของ DONs จะรวมชุดของ Building Block ไว้ด้วย อะแดปเตอร์สำหรับทรัพยากรภายนอกที่ใช้กันทั่วไปดังกล่าว และจะอนุญาต DON-เฉพาะเพิ่มเติม อะแดปเตอร์ที่จะเผยแพร่โดยโหนด DON ในฐานะนักพัฒนา smart contract เขียนอะแดปเตอร์ วันนี้เราคาดหวังว่าพวกเขาจะสร้างอะแดปเตอร์ที่ทรงพลังยิ่งขึ้นโดยใช้ขั้นสูงนี้ ฟังก์ชั่น เราคาดหวังว่าท้ายที่สุดแล้วจะเป็นไปได้สำหรับผู้ใช้ในการสร้างอะแดปเตอร์ใหม่ใน ในลักษณะไม่ได้รับอนุญาต อะแด็ปเตอร์บางตัวต้องถูกสร้างขึ้นในลักษณะที่ช่วยให้มั่นใจถึงความคงอยู่และความพร้อมใช้งานของทรัพยากรภายนอกที่ควบคุมโดย DON ตัวอย่างเช่นที่เก็บข้อมูลบนคลาวด์อาจ ต้องการการบำรุงรักษาบัญชีบริการคลาวด์ นอกจากนี้ DON สามารถทำงานได้ การจัดการคีย์ส่วนตัวแบบกระจายอำนาจในนามของผู้ใช้ (เช่นใน เช่น [160]) และ/หรือ ปฏิบัติการ ด้วยเหตุนี้ DON จึงสามารถควบคุมทรัพยากร เช่น สกุลเงินดิจิทัล ที่อาจนำไปใช้ เช่น เพื่อส่งธุรกรรมไปยังเป้าหมาย blockchain ดูภาคผนวก B.1 สำหรับรายละเอียดเพิ่มเติมเกี่ยวกับอะแดปเตอร์ DON เช่นเดียวกับภาคผนวก C บางส่วน ตัวอย่างอะแดปเตอร์ 3.2 การคำนวณ โปรแกรมปฏิบัติการคือหน่วยพื้นฐานของโค้ดบน DON ไฟล์ปฏิบัติการคือคู่ exec = (ตรรกะ เริ่มต้น) ในที่นี้ ตรรกะคือโปรแกรมที่กำหนดขึ้นซึ่งมีรายการที่กำหนดจำนวนหนึ่ง จุด (logic1, logic2, . . . , logicel) และ init เป็นชุดของตัวเริ่มต้นที่สอดคล้องกัน (init1, init2, . . , inite) เพื่อให้แน่ใจว่า DON สามารถตรวจสอบได้อย่างสมบูรณ์ ซึ่งเป็นตรรกะของปฏิบัติการ ใช้บัญชีแยกประเภท L สำหรับอินพุตและเอาต์พุตทั้งหมด ตัวอย่างเช่นอะแดปเตอร์ใดๆ ข้อมูลที่ทำหน้าที่เป็นอินพุตไปยังปฏิบัติการจะต้องถูกเก็บไว้ก่อนบน L ผู้ริเริ่ม: ผู้ริเริ่มใน Chainlink ในวันนี้ทำให้การดำเนินการตามเหตุการณ์เปิดขึ้น Chainlink โหนด [21] ตัวเริ่มต้นใน DONs ทำงานในลักษณะเดียวกันมาก อย่างไรก็ตาม ตัวเริ่มต้น DON มีความเกี่ยวข้องเป็นพิเศษกับไฟล์เรียกทำงาน ผู้ริเริ่มอาจขึ้นอยู่กับ ในเหตุการณ์หรือสถานะภายนอก ในเวลาปัจจุบัน หรือบนเพรดิเคตในสถานะ DON ด้วยความที่ต้องพึ่งพาเหตุการณ์ ผู้ริเริ่มอาจมีพฤติกรรมที่ไม่ได้กำหนดไว้แน่นอน (แน่นอนว่าอาจเป็นอะแดปเตอร์) ผู้ริเริ่มสามารถดำเนินการภายในแต่ละโหนด DON ดังนั้นจึงไม่จำเป็นต้องพึ่งอะแดปเตอร์ (ดูตัวอย่างที่ 1 ด้านล่าง) ตัวเริ่มต้นเป็นคุณลักษณะที่สำคัญที่ทำให้ไฟล์ปฏิบัติการแตกต่างจาก smart contracts เนื่องจากไฟล์เรียกทำงานสามารถรันเพื่อตอบสนองต่อตัวเริ่มต้น จึงสามารถดำเนินการได้อย่างมีประสิทธิภาพ โดยอัตโนมัติ โดยการขยายสัญญาแบบไฮบริดที่รวมเอาปฏิบัติการเข้าด้วยกันได้ รูปแบบหนึ่งของผู้ริเริ่มในปัจจุบันคือ Chainlink Keepers ซึ่งทำธุรกรรมบริการอัตโนมัติที่กระตุ้นให้เกิดการดำเนินการ smart contract เช่น การชำระบัญชีเงินกู้ที่มีหลักประกันต่ำ และการดำเนินการซื้อขายแบบจำกัดคำสั่ง โดยอิงจากรายงาน oracle เพื่อความสะดวก ผู้ริเริ่มใน DONs อาจถูกมองว่าเป็นวิธีการระบุ ข้อตกลงการบริการที่ใช้บังคับกับปฏิบัติการตามที่ได้กำหนดสถานการณ์ภายใต้ ซึ่ง DON ต้องเรียกมัน ตัวอย่างต่อไปนี้แสดงให้เห็นว่า Initiator ทำงานอย่างไรภายในไฟล์เรียกทำงาน: ตัวอย่างที่ 1 (ฟีดราคาที่กระตุ้นการเบี่ยงเบน) smart contract SC อาจต้องการความสด ข้อมูลราคาฟีด (ดูหัวข้อ 3.6.3) เมื่อใดก็ตามที่มีการเปลี่ยนแปลงที่สำคัญ เช่น 1% ใน อัตราแลกเปลี่ยนระหว่างคู่สินทรัพย์ เช่น ETH-USD ราคาที่ไวต่อความผันผวน ฟีดได้รับการสนับสนุนใน Chainlink วันนี้ แต่แนะนำให้ดูว่าจะเป็นอย่างไร รับรู้บน DON โดยใช้ execfeed ที่ปฏิบัติการได้ execfeed ที่ปฏิบัติการได้จะรักษาราคา ETH-USD ล่าสุด r บน L ในรูปแบบ รูปแบบของลำดับของ ⟨NewPrice : j, r⟩entries โดยที่ j คือดัชนีที่เพิ่มขึ้นด้วย อัพเดทราคาแต่ละครั้ง Initiator init1 ทำให้แต่ละโหนด Oi ตรวจสอบราคา ETH-USD ปัจจุบัน ส่วนเบี่ยงเบนอย่างน้อย 1% จากราคาที่เก็บไว้ล่าสุด r พร้อมดัชนี j เมื่อ เมื่อตรวจพบความเบี่ยงเบนดังกล่าว Oi จะเขียนมุมมองปัจจุบันของราคาใหม่ให้ L ใช้ รายการของแบบฟอร์ม ⟨PriceView : i, j + 1, ri⟩ ผู้ริเริ่มคนที่สอง init2 เริ่มทำงานเมื่อรายการ PriceView ดังกล่าวอย่างน้อย k รายการมีราคาใหม่ ค่าสำหรับดัชนี j + 1 ที่สร้างขึ้นโดยโหนดที่แตกต่างกันได้สะสมอยู่บน L จากนั้น init2 เรียกใช้ตรรกะจุดเข้าใช้งาน2 เพื่อคำนวณค่ามัธยฐาน ρ ของ k แรกสด ค่าการดูราคาที่ถูกต้อง และเขียนค่าใหม่ ⟨NewPrice : j + 1, ρ⟩to L (ในทางปฏิบัติโหนด อาจผลัดกันเป็นนักเขียนได้) ผู้ริเริ่มคนที่สาม init3 เฝ้าดูรายการ NewPrice บน L เมื่อใดก็ตามที่มีรายงานใหม่ ⟨ราคาใหม่ : j, r⟩ปรากฏขึ้นตรงนั้น โดยเรียกใช้ตรรกะจุดเริ่มต้น 3 ที่ผลัก (j, r) ไปที่ SC โดยใช้อะแดปเตอร์ ดังที่เราได้กล่าวไปแล้ว ความสามารถในการเรียกทำงานมีความคล้ายคลึงกับ smart contract นอกเหนือจากประสิทธิภาพที่สูงขึ้นแล้ว ยังแตกต่างจากสัญญาลูกโซ่หลักทั่วไปอีกด้วย ด้วยสองวิธีที่สำคัญ: 1. การรักษาความลับ: โปรแกรมปฏิบัติการสามารถทำการคำนวณที่เป็นความลับ เช่น โปรแกรมลับอาจประมวลผลอินพุตข้อความธรรมดา หรือโปรแกรมที่เผยแพร่อาจประมวลผล ข้อมูลอินพุตที่เป็นความลับหรือทั้งสองอย่างรวมกัน ในรูปแบบที่เรียบง่าย ข้อมูลลับสามารถทำได้ เข้าถึงได้โดยโหนด DON ซึ่งปกปิดผลลัพธ์ระดับกลางและเปิดเผยเท่านั้น ประมวลผลและฆ่าเชื้อค่าให้กับ MAINCHAIN นอกจากนี้ยังสามารถปกปิดข้อมูลที่ละเอียดอ่อนจาก DONs ได้ด้วย: DONs มีไว้เพื่อสนับสนุนแนวทางดังกล่าว เป็นการคำนวณแบบหลายฝ่าย เช่น [42, 157] และสภาพแวดล้อมการดำเนินการที่เชื่อถือได้ (TEE) [84, 133, 152, 229] เพื่อจุดประสงค์นี้6 6โดยการขยาย การรักษาปฏิบัติการให้เป็นความลับในส่วนที่เกี่ยวกับโหนด DON ก็เป็นไปได้เช่นกัน แม้ว่านี่จะใช้งานได้จริงในปัจจุบันเท่านั้นสำหรับโปรแกรมปฏิบัติการที่ไม่สำคัญโดยใช้ TEE2. บทบาทสนับสนุน: ไฟล์ปฏิบัติการมีไว้เพื่อรองรับ smart contracts บนระบบปฏิบัติการหลัก โซ่แทนที่จะแทนที่พวกเขา ปฏิบัติการมีข้อจำกัดหลายประการที่ smart contract ไม่: (ก) โมเดลความน่าเชื่อถือ: ปฏิบัติการดำเนินการภายในโมเดลความน่าเชื่อถือที่กำหนดโดย DON: การดำเนินการที่ถูกต้องขึ้นอยู่กับพฤติกรรมที่ซื่อสัตย์ของ O. (A main อย่างไรก็ตาม chain สามารถจัดเตรียมรางป้องกันบางส่วนจาก DON การทำงานผิดพลาดได้ เนื่องจาก กล่าวถึงในมาตรา 7.3) (b) การเข้าถึงสินทรัพย์: A DON สามารถควบคุมบัญชีใน blockchain—และด้วยเหตุนี้ ควบคุมทรัพย์สินผ่านอะแดปเตอร์ แต่ DON ไม่สามารถเชื่อถือได้ เป็นตัวแทนของสินทรัพย์ที่สร้างขึ้นบนเชนหลัก เช่น Ether หรือ ERC20 tokens เนื่องจาก เครือข่ายท้องถิ่นของพวกเขาจะรักษาบันทึกที่เชื่อถือได้ของการเป็นเจ้าของ (c) วงจรชีวิต: DONs อาจถูกตั้งขึ้นโดยเจตนาโดยมีอายุการใช้งานที่จำกัด เนื่องจาก กำหนดโดยข้อตกลงระดับการให้บริการออนไลน์ระหว่าง DONs และเจ้าของ ของการพึ่งพาสัญญา ในทางตรงกันข้าม Blockchains มีไว้เพื่อทำหน้าที่เป็น ระบบเอกสารถาวร ดูภาคผนวก B.2 สำหรับรายละเอียดเพิ่มเติมเกี่ยวกับการคำนวณ DON 3.3 ที่เก็บของ ในฐานะระบบที่อิงตามคณะกรรมการ DON สามารถจัดเก็บข้อมูลจำนวนปานกลางได้อย่างถาวร บน L ในราคาที่ต่ำกว่า blockchain ที่ไม่ได้รับอนุญาตมาก นอกจากนี้ ผ่านอะแดปเตอร์ DONs สามารถอ้างอิงระบบกระจายอำนาจภายนอกสำหรับการจัดเก็บข้อมูล เช่น Filecoin [85], และสามารถเชื่อมต่อระบบดังกล่าวกับ smart contracts ได้ ตัวเลือกนี้เป็นพิเศษ น่าสนใจสำหรับข้อมูลจำนวนมากซึ่งเป็นวิธีการแก้ไขปัญหาที่แพร่หลายของ "การขยายตัว" blockchain ระบบ DONs จึงสามารถจัดเก็บข้อมูลไว้ภายในหรือภายนอกเพื่อใช้ในบริการที่รองรับโดยเฉพาะ DON สามารถใช้ข้อมูลดังกล่าวเพิ่มเติมในลักษณะที่เป็นความลับ การประมวลผลข้อมูลที่: (1) แบ่งปันความลับผ่านโหนด DON หรือเข้ารหัสภายใต้ คีย์ที่จัดการโดยโหนด DON ด้วยวิธีที่เหมาะสมสำหรับการคำนวณแบบหลายฝ่ายอย่างปลอดภัย หรือการเข้ารหัสแบบโฮโมมอร์ฟิกบางส่วนหรือทั้งหมด หรือ (2) ป้องกันโดยใช้การดำเนินการที่เชื่อถือได้ สิ่งแวดล้อม เราคาดหวังว่า DONs จะนำโมเดลการจัดการหน่วยความจำแบบธรรมดามาใช้ ระบบสัญญาอัจฉริยะ: โปรแกรมปฏิบัติการอาจเขียนลงในหน่วยความจำของตัวเองเท่านั้น ปฏิบัติการได้ อย่างไรก็ตามอาจอ่านจากหน่วยความจำของไฟล์ปฏิบัติการอื่น ๆ ดูภาคผนวก B.3 สำหรับรายละเอียดเพิ่มเติมเกี่ยวกับพื้นที่จัดเก็บ DON 3.4 กรอบการดำเนินการธุรกรรม (TEF) DONs มีวัตถุประสงค์เพื่อรองรับสัญญาบน MAINCHAIN สายหลัก (หรือบนหลายสายหลัก) กรอบการดำเนินการธุรกรรม (TEF) มีการอภิปรายโดยละเอียดในส่วนที่ 6 เป็นแนวทางที่มีจุดประสงค์ทั่วไปในการดำเนินการตามสัญญาอย่างมีประสิทธิภาพ SC ข้าม MAINCHAIN และ DON TEF มีวัตถุประสงค์เพื่อรองรับ FSS และเลเยอร์ 2 เทคโนโลยี—พร้อมกัน หากต้องการ แท้จริงแล้วน่าจะใช้เป็นพาหนะหลัก สำหรับการใช้งาน FSS (และด้วยเหตุผลดังกล่าว เราจะไม่กล่าวถึง FSS เพิ่มเติมในส่วนนี้) โดยสรุป ใน TEF สัญญาเป้าหมายดั้งเดิม SC ที่ออกแบบหรือพัฒนาสำหรับ MAINCHAIN ได้รับการปรับโครงสร้างใหม่ให้เป็นสัญญาแบบไฮบริด การปรับโครงสร้างใหม่นี้ทำให้ทั้งสองปฏิบัติการร่วมกัน ชิ้นส่วนของสัญญาไฮบริด: MAINCHAIN สัญญา SCa ที่เราอ้างถึงเพื่อความชัดเจน ในบริบทของ TEF ในฐานะสัญญาหลักและผู้บริหารที่ปฏิบัติการได้บน DON ที่ สัญญา SCa ดูแลทรัพย์สินของผู้ใช้ ดำเนินการเปลี่ยนสถานะที่เชื่อถือได้ และด้วย มีราวกั้น (ดูหัวข้อ 7.3) เพื่อป้องกันความล้มเหลวใน DON ผู้บริหารที่ปฏิบัติการได้ จัดลำดับธุรกรรมและให้ข้อมูล oracle ที่เกี่ยวข้องสำหรับธุรกรรมเหล่านั้น มันสามารถมัดรวมได้ การทำธุรกรรมสำหรับ SCa ด้วยวิธีต่างๆ เช่น การใช้ validity-proof-based หรือ rollups ในแง่ดี การดำเนินการที่เป็นความลับโดย DON ฯลฯ เราคาดหวังที่จะพัฒนาเครื่องมือที่ช่วยให้นักพัฒนาแบ่งพาร์ติชันสัญญาได้ง่าย SC เขียนด้วยภาษาระดับสูงเป็นส่วนของ MAINCHAIN และ DON ตรรกะ, SCa และ ผู้บริหารตามลำดับที่เขียนอย่างปลอดภัยและมีประสิทธิภาพ การใช้ TEF เพื่อรวมแผนธุรกรรมที่มีประสิทธิภาพสูงเข้ากับประสิทธิภาพสูง oracles เป็นส่วนสำคัญของแนวทางการปรับขนาด oracle ของเรา 3.5 บริการของเมมพูล คุณลักษณะชั้นแอปพลิเคชันที่สำคัญที่เราตั้งใจจะปรับใช้บน DONs เพื่อรองรับ ของ FSS และ TEF คือ Mempool Services (MS) MS อาจถูกมองว่าเป็นอะแดปเตอร์ แต่เป็นหนึ่งเดียวกับการสนับสนุนระดับเฟิร์สคลาส MS ให้การสนับสนุนการประมวลผลธุรกรรมที่เข้ากันได้กับระบบเดิม ในการใช้งานนี้ MS นำเข้าธุรกรรมเหล่านั้นจาก mempool ของเครือข่ายหลักสำหรับสัญญาเป้าหมาย SC บน MAINCHAIN จากนั้น MS จะส่งธุรกรรมเหล่านี้ไปยังไฟล์ปฏิบัติการบน DON โดยที่พวกเขาได้รับการประมวลผลในลักษณะที่ต้องการ ข้อมูล MS สามารถใช้โดย DON เพื่อเขียนธุรกรรมที่สามารถส่งผ่านไปยัง SC โดยตรงจาก DON หรือ ไปอีกสัญญาหนึ่งที่เรียกเอสซี ตัวอย่างเช่น DON สามารถส่งต่อธุรกรรมได้ เก็บเกี่ยวผ่าน MS หรือสามารถใช้ข้อมูล MS เพื่อกำหนดราคาก๊าซสำหรับธุรกรรมที่ส่งไป เมนเชน. เนื่องจากจะตรวจสอบ mempool ทำให้ MS สามารถรับธุรกรรมจากผู้ใช้ที่โต้ตอบกับ SC โดยตรง ดังนั้นผู้ใช้จึงสามารถสร้างธุรกรรมโดยใช้ต่อไปได้ ซอฟต์แวร์รุ่นเก่า เช่น แอปพลิเคชันที่ไม่ทราบถึงการมีอยู่ของ MS และ MS ที่กำหนดค่าไว้ สัญญา (ในกรณีนี้ต้องเปลี่ยน SC ให้ละเว้นธุรกรรมเดิมและ ยอมรับเฉพาะที่ประมวลผลโดย MS เท่านั้นเพื่อหลีกเลี่ยงการประมวลผลซ้ำซ้อน) สำหรับใช้กับสัญญา SC เป้าหมาย สามารถใช้ MS กับ FSS และ/หรือ TEF ได้3.6 Stepping Stones: ความสามารถ Chainlink ที่มีอยู่ 3.6.1 การรายงานออฟเชน (OCR) OF-Chain Reporting (OCR) [60] เป็นกลไกใน Chainlink สำหรับ oracle การรวมรายงานและการส่งผ่านไปยังสัญญา SC ที่เกี่ยวข้อง เพิ่งปรับใช้ในราคา Chainlink เครือข่ายฟีด แสดงถึงก้าวแรกตามเส้นทางสู่ DONs แบบเต็ม ที่แกนหลัก OCR คือโปรโตคอล BFT ที่ออกแบบมาเพื่อทำงานในแบบซิงโครนัสบางส่วน เครือข่าย ช่วยให้มั่นใจถึงความมีชีวิตชีวาและความถูกต้องเมื่อมี f < n/3 โดยพลการ โหนดที่มีข้อบกพร่องซึ่งรับประกันคุณสมบัติของการออกอากาศที่เชื่อถือได้ของ Byzantine แต่ก็ไม่เป็นเช่นนั้น โปรโตคอลฉันทามติที่สมบูรณ์ BFT โหนดไม่เก็บบันทึกข้อความที่เป็น สอดคล้องกันในแง่ของการเป็นตัวแทนของบัญชีแยกประเภทที่เหมือนกันในทุกมุมมอง และผู้นำของระเบียบการอาจโต้แย้งได้โดยไม่ละเมิดความปลอดภัย ปัจจุบัน OCR ได้รับการออกแบบมาสำหรับข้อความประเภทใดประเภทหนึ่ง: การรวมแบบมีเดียนไลซ์ของ (อย่างน้อย 2f +1) ค่าที่รายงานโดยโหนดที่เข้าร่วม จะให้หลักประกันที่สำคัญเกี่ยวกับ รายงานที่ส่งออกสำหรับ SC เรียกว่ารายงานที่ได้รับการรับรอง: ค่ามัธยฐานในการยืนยัน รายงานเท่ากับหรืออยู่ระหว่างค่าที่รายงานโดยสองโหนดที่ซื่อสัตย์ คุณสมบัตินี้คือ เงื่อนไขความปลอดภัยที่สำคัญสำหรับ OCR ผู้นำอาจมีอิทธิพลบางอย่างต่อค่ามัธยฐาน มูลค่าในรายงานที่ได้รับการรับรอง แต่ขึ้นอยู่กับเงื่อนไขความถูกต้องนี้เท่านั้น โอซีอาร์สามารถ ขยายไปถึงประเภทข้อความที่รวบรวมคุณค่าในรูปแบบต่างๆ แม้ว่าเป้าหมายความสดและความถูกต้องของเครือข่าย Chainlink ในปัจจุบันไม่จำเป็นต้องมีก็ตาม OCR เพื่อเป็นโปรโตคอลฉันทามติเต็มรูปแบบ พวกเขาจำเป็นต้องมี OCR เพื่อจัดเตรียมรูปแบบการทำงานเพิ่มเติมบางรูปแบบที่ไม่มีอยู่ในโปรโตคอล BFT ทั่วไป โดยเฉพาะอย่างยิ่ง: 1. การออกอากาศรายงานแบบไม่มีห่วงโซ่ทั้งหมดหรือไม่มีเลย: OCR ช่วยให้มั่นใจได้ว่ารายงานที่ได้รับการรับรอง พร้อมใช้งานได้อย่างรวดเร็วสำหรับโหนดที่ซื่อสัตย์ทั้งหมดหรือไม่มีเลย นี่คือความเป็นธรรม คุณสมบัติที่ช่วยให้แน่ใจว่าโหนดที่ซื่อสัตย์มีโอกาสที่จะเข้าร่วม ในการส่งรายงานที่ได้รับการรับรอง 2. การส่งข้อมูลที่เชื่อถือได้: OCR ช่วยให้มั่นใจได้ แม้ว่าจะมีข้อผิดพลาดหรือเป็นอันตรายก็ตาม โหนดที่รายงาน OCR และข้อความทั้งหมดถูกส่งไปยัง SC ภายในช่วงที่กำหนด ช่วงเวลาที่กำหนดไว้ล่วงหน้า นี่คือคุณสมบัติความมีชีวิตชีวา 3. การลดความไว้วางใจตามสัญญา: SC กรองรายงานที่สร้างโดย OCR ที่อาจมีข้อผิดพลาด เช่น หากค่าที่รายงานเบี่ยงเบนไปจากรายงานอื่นๆ อย่างมีนัยสำคัญ คนที่เพิ่งได้รับ นี่เป็นรูปแบบหนึ่งของการบังคับใช้ความถูกต้องของโปรโตคอลพิเศษ คุณสมบัติทั้งสามนี้จะมีบทบาทตามธรรมชาติใน DONs การออกอากาศแบบ All-or-nothing ofchain (DON) ถือเป็นองค์ประกอบสำคัญสำหรับการรับประกันทางเศรษฐกิจแบบเข้ารหัสลับ เกี่ยวกับการส่งข้อมูลที่เชื่อถือได้ ซึ่งเป็นคุณสมบัติของอะแดปเตอร์ที่จำเป็น ความไว้วางใจ การย่อขนาดใน SC เป็นประเภทของราวกั้น ตามที่กล่าวไว้ในส่วน 7.3 OCR ยังจัดเตรียมพื้นฐานสำหรับการนำไปใช้งานและการปรับแต่งโปรโตคอล BFT ในเครือข่าย oracle ของ Chainlink ของ oracle ดังนั้น ตามที่ระบุไว้ข้างต้น เส้นทางสู่ความสมบูรณ์ การทำงานของ DONs3.6.2 DECO และ Town Crier DECO [234] และ Town Crier [233] เป็นเทคโนโลยีที่เกี่ยวข้องกันในปัจจุบัน พัฒนาในเครือข่าย Chainlink เว็บเซิร์ฟเวอร์ส่วนใหญ่ในปัจจุบันอนุญาตให้ผู้ใช้เชื่อมต่อผ่านช่องทางที่ปลอดภัยโดยใช้โปรโตคอล เรียกว่า Transport Layer Security (TLS) [94] (HTTPS ระบุถึงตัวแปรของ HTTP นั้น เปิดใช้งานด้วย TLS เช่น URL ที่ขึ้นต้นด้วย “https” หมายถึงการใช้ TLS เพื่อความปลอดภัย) เซิร์ฟเวอร์ที่เปิดใช้งาน TLS ส่วนใหญ่มีข้อจำกัดที่น่าสังเกต: ไม่มีการเซ็นชื่อแบบดิจิทัล ข้อมูล ด้วยเหตุนี้ ผู้ใช้หรือ Prover จึงไม่สามารถนำเสนอข้อมูลที่ได้รับจากเซิร์ฟเวอร์ได้ ไปยังบุคคลที่สามหรือผู้ตรวจสอบ เช่น oracle หรือ smart contract ในลักษณะที่ทำให้มั่นใจได้ ความถูกต้องของข้อมูล แม้ว่าเซิร์ฟเวอร์จะลงนามข้อมูลแบบดิจิทัล แต่ก็ยังมีปัญหาเรื่องการรักษาความลับอยู่ ผู้พิสูจน์อักษรอาจต้องการแก้ไขหรือแก้ไขข้อมูลที่ละเอียดอ่อนก่อนที่จะนำเสนอต่อ ผู้ตรวจสอบ อย่างไรก็ตาม ลายเซ็นดิจิทัลได้รับการออกแบบมาโดยเฉพาะเพื่อทำให้ข้อมูลที่แก้ไขเป็นโมฆะ สิ่งเหล่านี้จึงป้องกันไม่ให้ผู้พิสูจน์ทำการเปลี่ยนแปลงเพื่อรักษาความลับ ไปยังข้อมูล (ดูหัวข้อ 7.1 สำหรับการสนทนาเพิ่มเติม) DECO และ Town Crier ได้รับการออกแบบมาเพื่อให้ Prover รับข้อมูลจากเว็บ เซิร์ฟเวอร์และนำเสนอต่อผู้ตรวจสอบในลักษณะที่รับประกันความสมบูรณ์และการรักษาความลับ ทั้งสองระบบรักษาความสมบูรณ์ในแง่ที่รับประกันว่าข้อมูลที่นำเสนอโดย Prover to the Veriifier มีต้นกำเนิดมาจากเซิร์ฟเวอร์เป้าหมายอย่างแท้จริง พวกเขาสนับสนุน การรักษาความลับในแง่ของการอนุญาตให้ผู้พิสูจน์สามารถแก้ไขหรือแก้ไขข้อมูล (ในขณะที่ยังคงอยู่ การรักษาความซื่อสัตย์) คุณลักษณะที่สำคัญของทั้งสองระบบคือไม่จำเป็นต้องมีการปรับเปลี่ยนใดๆ เว็บเซิร์ฟเวอร์เป้าหมาย สามารถทำงานร่วมกับเซิร์ฟเวอร์ที่เปิดใช้งาน TLS ที่มีอยู่ได้ ในความเป็นจริง มีความโปร่งใสต่อเซิร์ฟเวอร์: จากมุมมองของเซิร์ฟเวอร์ ผู้พิสูจน์คือ สร้างการเชื่อมต่อแบบธรรมดา ทั้งสองระบบมีเป้าหมายที่คล้ายกัน แต่แตกต่างกันในรูปแบบความไว้วางใจและการนำไปใช้ตามที่เราจะอธิบายโดยสรุป DECO ใช้โปรโตคอลการเข้ารหัสขั้นพื้นฐานเพื่อให้บรรลุความสมบูรณ์ และคุณสมบัติการรักษาความลับ ในขณะที่สร้างเซสชันกับเซิร์ฟเวอร์เป้าหมายโดยใช้ DECO Prover จะมีส่วนร่วมในเวลาเดียวกันในโปรโตคอลแบบโต้ตอบกับ ผู้ตรวจสอบ โปรโตคอลนี้ทำให้ผู้พิสูจน์สามารถพิสูจน์ต่อผู้ตรวจสอบได้ว่าได้รับแล้ว ชิ้นส่วนของข้อมูล D จากเซิร์ฟเวอร์ระหว่างเซสชันปัจจุบัน พระสุภาษิตสามารถ หรือนำเสนอผู้ยืนยันด้วยหลักฐานความรู้ที่ไม่มีความรู้เกี่ยวกับคุณสมบัติบางอย่างของ D จึงไม่เปิดเผย D โดยตรง ในการใช้งาน DECO โดยทั่วไป ผู้ใช้หรือโหนดเดียวสามารถส่งออกข้อมูล D จากส่วนตัวได้ เซสชันกับเว็บเซิร์ฟเวอร์ไปยังโหนดทั้งหมดใน DON ด้วยเหตุนี้ DON จึงสามารถเต็มได้ รับรองความถูกต้องของ D (หรือข้อเท็จจริงที่ได้มาจาก D ผ่านการพิสูจน์ความรู้เป็นศูนย์) นอกเหนือจากตัวอย่างการใช้งานที่ให้ไว้ในบทความนี้แล้ว ความสามารถนี้ยังสามารถเป็นได้อีกด้วย ใช้เพื่อขยายการเข้าถึงแหล่งข้อมูลที่มีความสมบูรณ์สูงโดย DON แม้จะเพียงโหนดเดียวก็ตาม มีสิทธิ์เข้าถึงแหล่งข้อมูลโดยตรง เช่น เนื่องมาจากข้อตกลงพิเศษกับ ผู้ให้บริการข้อมูล—ยังคงเป็นไปได้ที่ DON ทั้งหมดจะยืนยันถึงความถูกต้องของรายงานที่ปล่อยออกมาจากโหนดนั้น Town Crier อาศัยการใช้สภาพแวดล้อมการดำเนินการที่เชื่อถือได้ (TEE) เช่น Intel เอสจีเอ็กซ์ โดยสรุป TEE ทำหน้าที่เป็นกล่องดำชนิดหนึ่งที่เรียกใช้งานแอปพลิเคชันใน วิธีการป้องกันการงัดแงะและเป็นความลับ โดยหลักการแล้วแม้แต่เจ้าของโฮสต์ก็ตาม TEE กำลังทำงานไม่สามารถ (ตรวจไม่พบ) เปลี่ยนแปลงแอปพลิเคชันที่ได้รับการป้องกัน TEE หรือ ดูสถานะของแอปพลิเคชันซึ่งอาจรวมถึงข้อมูลที่เป็นความลับ Town Crier สามารถบรรลุฟังก์ชันทั้งหมดของ DECO และอีกมากมาย DECO จำกัด Prover ให้โต้ตอบกับ Veriifier เดียว ในทางตรงกันข้าม Town Crier เปิดใช้งาน a Prover เพื่อสร้างข้อพิสูจน์ที่สามารถตรวจสอบได้โดยสาธารณะเกี่ยวกับข้อมูล D ที่ดึงมาจากเซิร์ฟเวอร์เป้าหมาย กล่าวคือ ข้อพิสูจน์ว่าใครก็ตาม แม้แต่ smart contract ก็สามารถตรวจสอบได้โดยตรง เมือง Crier สามารถ นำเข้าและใช้ความลับได้อย่างปลอดภัย (เช่น ข้อมูลรับรองผู้ใช้) ข้อจำกัดหลักของ Town Crier คือการพึ่งพา TEE การผลิต TEE มี เมื่อเร็ว ๆ นี้แสดงให้เห็นว่ามีช่องโหว่ร้ายแรงจำนวนหนึ่ง แม้ว่าเทคโนโลยียังอยู่ในช่วงเริ่มต้นและจะเติบโตอย่างไม่ต้องสงสัย ดูภาคผนวก B.2.1 และ B.2.2 สำหรับ การอภิปรายเพิ่มเติมเกี่ยวกับ TEE สำหรับตัวอย่างการใช้งาน DECO และ Town Crier ดูส่วนที่ 4.3, 4.5 และ 9.4.3 และภาคผนวก C.1 3.6.3 บริการออนไลน์ที่มีอยู่ Chainlink Chainlink oracle เครือข่ายให้บริการหลักจำนวนหนึ่งผ่านหลากหลายของ blockchains และระบบกระจายอำนาจอื่น ๆ ในปัจจุบัน วิวัฒนาการเพิ่มเติมตามที่อธิบายไว้ ในเอกสารไวท์เปเปอร์นี้จะมอบบริการที่มีอยู่เหล่านี้ด้วยความสามารถเพิ่มเติมและ เข้าถึง สามตัวอย่างคือ: ฟีดข้อมูล: ปัจจุบัน ผู้ใช้ Chainlink ส่วนใหญ่พึ่งพา smart contracts การใช้ฟีดข้อมูล เหล่านี้เป็นรายงานเกี่ยวกับมูลค่าปัจจุบันของข้อมูลสำคัญตาม ไปยังแหล่งที่มาของห่วงโซ่ที่เชื่อถือได้ ตัวอย่างเช่น ฟีดราคาคือฟีดที่รายงานราคา ของสินทรัพย์—สกุลเงินดิจิทัล สินค้าโภคภัณฑ์ ฟอเร็กซ์ ดัชนี ตราสารทุน ฯลฯ—ตาม การแลกเปลี่ยนหรือบริการรวบรวมข้อมูล ฟีดดังกล่าวในปัจจุบันได้ช่วยรักษาความปลอดภัยให้กับผู้คนนับพันล้านแล้ว ดอลลาร์ในมูลค่าออนไลน์ผ่านการใช้งานในระบบ DeFi เช่น Aave [147] และ ซินธิติกส์ [208]. ตัวอย่างอื่นๆ ของฟีดข้อมูล Chainlink รวมถึงข้อมูลสภาพอากาศสำหรับ การประกันภัยพืชผลแบบพาราเมตริก [75] และข้อมูลการเลือกตั้ง [93] และอื่นๆ อีกมากมาย การใช้งาน DONs และเทคโนโลยีอื่นๆ ที่อธิบายไว้ในเอกสารนี้จะปรับปรุงการจัดหาฟีดข้อมูลในเครือข่าย Chainlink ในหลาย ๆ ด้าน รวมถึง: • การปรับขนาด: OCR และต่อมา DONs มุ่งหวังที่จะเปิดใช้งานบริการ Chainlink เพื่อขยายขนาด อย่างมากใน blockchains มากมายที่พวกเขาสนับสนุน ตัวอย่างเช่นเราคาดหวัง DONs จะช่วยเพิ่มจำนวนฟีดข้อมูลที่โหนดใช้ Chainlink จาก 100 ถึง 1,000 และมากกว่านั้น การปรับขนาดดังกล่าวจะช่วย Chainlink ระบบนิเวศบรรลุเป้าหมายในการจัดหาข้อมูลที่เกี่ยวข้องกับ smart contracts อย่างครอบคลุม และตอบสนองและคาดการณ์ความต้องการที่มีอยู่และในอนาคต• การรักษาความปลอดภัยขั้นสูง: ด้วยการจัดเก็บรายงานระดับกลาง DONs จะเก็บรักษาบันทึก ของพฤติกรรมของโหนดสำหรับการตรวจสอบและการวัดประสิทธิภาพและความแม่นยำที่มีความแม่นยำสูง ช่วยให้สามารถวางรากฐานระบบชื่อเสียงเชิงประจักษ์ที่แข็งแกร่ง สำหรับ Chainlink โหนด FSS และ TEF จะทำให้สามารถรวมฟีดราคาเข้าด้วยกันได้ ด้วยข้อมูลธุรกรรมในรูปแบบยืดหยุ่นที่ป้องกันการโจมตี เช่น การดำเนินหน้า (ชัดเจน) staking จะสนับสนุนการคุ้มครองความปลอดภัยแบบ cryptoeconomic ที่มีอยู่ ของฟีดข้อมูล • ความคล่องตัวของฟีด: เนื่องจาก blockchain-ระบบผู้ไม่เชื่อเรื่องพระเจ้า (โดยแท้จริงแล้วคือระบบที่ไม่เชื่อเรื่องผู้บริโภคในวงกว้างมากขึ้น) DONs สามารถอำนวยความสะดวกในการจัดหาฟีดข้อมูลให้กับหลายหลาก ของระบบการพึ่งพา DON ตัวเดียวสามารถส่งฟีดที่กำหนดพร้อมกันไปยังชุดได้ ของ blockchains ที่แตกต่างกัน ทำให้ไม่จำเป็นต้องใช้เครือข่าย oracle ต่อเชน และ ช่วยให้ปรับใช้ฟีดที่มีอยู่ได้อย่างรวดเร็วบน blockchains ใหม่และอื่นๆ อีกมากมาย ฟีดทั่วทั้ง blockchains ที่ให้บริการในปัจจุบัน • การรักษาความลับ: ความสามารถในการคำนวณทั่วไปใน DON ช่วยให้การคำนวณข้อมูลที่ละเอียดอ่อนเกิดขึ้นแบบออฟไลน์ โดยหลีกเลี่ยงแบบออนไลน์ การสัมผัส นอกจากนี้การใช้ DECO หรือ Town Crier ก็สามารถทำได้ การรักษาความลับที่แข็งแกร่งยิ่งขึ้น ช่วยให้สามารถสร้างรายงานตามข้อมูลที่ไม่ใช่ เปิดเผยแม้กระทั่งกับโหนด DON ดูตัวอย่างในส่วนที่ 4.3 และส่วนที่ 4.5 ฟังก์ชั่นสุ่มที่ตรวจสอบได้ (VRF): DApps หลายประเภทต้องการแหล่งที่มาของการสุ่มที่ถูกต้องที่สามารถยืนยันได้ เพื่อให้สามารถยืนยันการดำเนินการที่ยุติธรรมของตนเองได้ โทเค็นที่ไม่สามารถเข้ากันได้ (NFTs) เป็นตัวอย่าง ความหายากของคุณสมบัติ NFT ใน Aavegotchi [23] และ Axie Infinity [35] ถูกกำหนดโดย Chainlink VRF เช่นเดียวกับการกระจาย ของ NFTs โดยการวาดตามตั๋วในการ์ด Ether [102]; ความหลากหลายของ DApps ของเกมที่มีการสุ่มผลลัพธ์ และเครื่องมือทางการเงินที่แหวกแนว เช่น เกมออมทรัพย์ที่ไม่มีการสูญเสีย เช่น PoolTogether [89] ซึ่งจัดสรรเงินทุนให้กับ ผู้ชนะแบบสุ่ม แอปพลิเคชัน blockchain และไม่ใช่-blockchain อื่นๆ จำเป็นต้องมีความปลอดภัยเช่นกัน แหล่งที่มาของการสุ่ม รวมถึงการคัดเลือกคณะกรรมการระบบกระจายอำนาจ และ การดำเนินการลอตเตอรี แม้ว่าบล็อก hashes สามารถทำหน้าที่เป็นแหล่งที่มาของการสุ่มที่คาดเดาไม่ได้ แต่ก็มีความเสี่ยงที่จะถูกจัดการโดยนักขุดฝ่ายตรงข้าม (และในระดับหนึ่งโดยผู้ใช้ที่ส่ง ธุรกรรม) Chainlink VRF [78] นำเสนอทางเลือกที่ปลอดภัยกว่ามาก อ oracle มีคู่คีย์ส่วนตัว / สาธารณะที่เกี่ยวข้อง (sk, pk) ซึ่งมีคีย์ส่วนตัวถูกเก็บรักษาไว้แบบห่วงโซ่และมีเผยแพร่คีย์สาธารณะ pk หากต้องการส่งออกค่าสุ่มก็ ใช้ sk กับเมล็ดพันธุ์ที่คาดเดาไม่ได้ x ที่ได้รับการตกแต่งโดยสัญญาที่พึ่งพา (เช่น บล็อก hash และพารามิเตอร์เฉพาะของ DApp) โดยใช้ฟังก์ชัน F โดยให้ค่า y = Fsk(x) พร้อมกับ หลักฐานความถูกต้อง (ดู [180] สำหรับ VRF ที่มีใน Chainlink) อะไรทำให้ VRF ที่ตรวจสอบได้คือข้อเท็จจริงที่ว่าด้วยความรู้เรื่อง pk จึงสามารถตรวจสอบความถูกต้องของการพิสูจน์และดังนั้นของ y ได้ ส่งผลให้ค่า y ไม่สามารถคาดเดาได้สำหรับ a ฝ่ายตรงข้ามที่ไม่สามารถทำนาย x หรือเรียนรู้ sk และเป็นไปไม่ได้ที่บริการจะจัดการChainlink VRF อาจถูกมองว่าเป็นเพียงหนึ่งในตระกูลแอปพลิเคชันที่เกี่ยวข้องกับการดูแลคีย์ส่วนตัวของห่วงโซ่ โดยทั่วไปแล้ว DONs สามารถให้ความปลอดภัยได้ การจัดเก็บแบบกระจายอำนาจของแต่ละคีย์สำหรับแอปพลิเคชันและ/หรือผู้ใช้ และรวมเข้าด้วยกัน ความสามารถนี้ด้วยการคำนวณทั่วไป ผลลัพธ์ที่ได้คือโฮสต์ของแอพพลิเคชั่นของ ซึ่งเราจะยกตัวอย่างบางส่วนในบทความนี้ รวมถึงการจัดการคีย์สำหรับ Proof of สำรอง (ดูหัวข้อ 4.1) และสำหรับข้อมูลประจำตัวที่กระจายอำนาจของผู้ใช้ (และดิจิทัลอื่น ๆ ทรัพย์สิน) (ดูหัวข้อ 4.3) ผู้ดูแล: Chainlink Keepers [87] ช่วยให้นักพัฒนาสามารถเขียนโค้ดสำหรับการกระจายอำนาจ การดำเนินการของงาน off-chain โดยทั่วไปจะทริกเกอร์การดำเนินการที่อาศัย smart contracts ก่อนการถือกำเนิดของ Keepers เป็นเรื่องปกติที่นักพัฒนาจะต้องดำเนินการนอกเครือข่ายดังกล่าว ตรรกะของตัวเอง สร้างจุดรวมศูนย์ของความล้มเหลว (เช่นเดียวกับความพยายามในการพัฒนาซ้ำซ้อนจำนวนมาก) Keepers จะให้กรอบงานที่ใช้งานง่ายแทน การกระจายอำนาจจากภายนอกของการดำเนินงานเหล่านี้ ช่วยให้วงจรการพัฒนาสั้นลงและ รับประกันความมีชีวิตชีวาและคุณสมบัติด้านความปลอดภัยอื่น ๆ ผู้ดูแลสามารถรองรับใด ๆ ของเป้าหมายกระตุ้นที่หลากหลาย รวมถึงการชำระบัญชีเงินกู้ขึ้นอยู่กับราคาหรือ การดำเนินการธุรกรรมทางการเงิน การเริ่มต้น Airdrops หรือการชำระเงินขึ้นอยู่กับเวลา ในระบบที่มีการเก็บเกี่ยวผลผลิต เป็นต้น ในกรอบงาน DON ผู้ริเริ่มอาจถูกมองว่าเป็นเพียงภาพรวมของผู้รักษาในหลายแง่มุม ผู้ริเริ่มอาจใช้อะแดปเตอร์ จึงสามารถใช้ประโยชน์ได้ ไลบรารีอินเทอร์เฟซแบบโมดูลาร์สำหรับระบบออนไลน์และออฟเชน ช่วยให้เกิดความรวดเร็ว การพัฒนาฟังก์ชันการทำงานที่ปลอดภัยและซับซ้อน ผู้ริเริ่มเริ่มต้นการคำนวณใน ไฟล์ปฏิบัติการซึ่งตัวเองมีความสามารถรอบด้านเต็มรูปแบบของ DONs ทำให้สามารถ บริการกระจายอำนาจที่หลากหลายที่เรานำเสนอในบทความนี้สำหรับแอปพลิเคชันแบบออนไลน์และออฟไลน์ 3.6.4 ชื่อเสียงของโหนด / ประวัติประสิทธิภาพ ระบบนิเวศ Chainlink ที่มีอยู่จะบันทึกประวัติประสิทธิภาพของ การสนับสนุนโหนดบนห่วงโซ่ คุณลักษณะนี้ได้ก่อให้เกิดคอลเลกชันของทรัพยากรด้านชื่อเสียงที่นำเข้า กรอง และแสดงภาพข้อมูลประสิทธิภาพในแต่ละบุคคล ตัวดำเนินการโหนดและฟีดข้อมูล ผู้ใช้สามารถอ้างอิงแหล่งข้อมูลเหล่านี้เพื่อแจ้งให้ทราบ การตัดสินใจในการเลือกโหนดและติดตามการทำงานของเครือข่ายที่มีอยู่ ความสามารถที่คล้ายกันจะช่วยให้ผู้ใช้เลือก DONs ตัวอย่างเช่น ตลาดซื้อขายที่ไม่ได้รับอนุญาตในปัจจุบัน เช่น market.link อนุญาตโหนด ผู้ดำเนินการเพื่อแสดงรายการบริการ oracle ของตนและยืนยันตัวตนนอกสายโซ่ผ่านทาง บริการต่างๆ เช่น Keybase [4] ซึ่งผูกโปรไฟล์ของโหนดใน Chainlink เข้ากับ ชื่อโดเมนและบัญชีโซเชียลมีเดียที่มีอยู่ของเจ้าของ นอกจากนี้ประสิทธิภาพการทำงาน เครื่องมือวิเคราะห์ เช่น เครื่องมือที่มีอยู่ใน Market.link และ Reputation.link อนุญาต ผู้ใช้เพื่อดูสถิติเกี่ยวกับประสิทธิภาพที่ผ่านมาของแต่ละโหนด รวมถึงโหนดด้วย เวลาแฝงในการตอบสนองโดยเฉลี่ย ค่าเบี่ยงเบนของค่าในรายงานจากค่าที่เป็นเอกฉันท์ ถ่ายทอดผ่านห่วงโซ่ สร้างรายได้ เติมเต็มงาน และอื่นๆ เครื่องมือวิเคราะห์เหล่านี้ด้วย อนุญาตให้ผู้ใช้ติดตามการใช้งานเครือข่าย oracle ต่างๆ โดยผู้ใช้รายอื่น รูปแบบของการรับรองโดยนัยของโหนดที่รักษาความปลอดภัยเครือข่ายดังกล่าว ผลลัพธ์ที่ได้คือ fl ที่ "เว็บของ" trust” ซึ่งโดยการใช้โหนดเฉพาะ แอปพลิเคชันกระจายอำนาจที่มีมูลค่าสูงสร้างขึ้น สัญญาณของความไว้วางใจในโหนดเหล่านั้นที่ผู้ใช้รายอื่นสามารถสังเกตและคำนึงถึงได้ การตัดสินใจเลือกโหนดของตัวเอง ด้วย DONs (และเริ่มต้นด้วย OCR) ทำให้เกิดการเปลี่ยนแปลงในการประมวลผลธุรกรรมและ กิจกรรมสัญญาโดยทั่วไปของห่วงโซ่ โมเดลการกระจายอำนาจสำหรับโหนดการบันทึก ประสิทธิภาพยังคงเป็นไปได้ภายใน DON เอง ประสิทธิภาพสูงจริงๆ และความจุข้อมูล DONs ทำให้สามารถสร้างบันทึกแบบละเอียดได้ วิธีและยังดำเนินการคำนวณแบบกระจายอำนาจในบันทึกเหล่านี้ โดยให้ผลสรุปที่น่าเชื่อถือซึ่งสามารถใช้บริการชื่อเสียงและจุดตรวจสอบได้ เมนเชน. แม้ว่าโดยหลักการแล้วจะเป็นไปได้ที่ DON บิดเบือนพฤติกรรมของโหนดที่เป็นส่วนประกอบ หากโหนดส่วนใหญ่เสียหาย แต่เราสังเกตว่าส่วนรวม ประสิทธิภาพของ DON ในการส่งข้อมูลออนไลน์จะปรากฏบน MAINCHAIN จึงไม่อาจบิดเบือนความจริงได้ นอกจากนี้เรายังวางแผนที่จะสำรวจกลไกดังกล่าวด้วย กระตุ้นให้เกิดการรายงานภายในที่ถูกต้องเกี่ยวกับพฤติกรรมของโหนดใน DON ตัวอย่างเช่น โดยการรายงานชุดย่อยของโหนดที่มีประสิทธิภาพสูงซึ่งส่งคืนข้อมูลที่มีส่วนร่วมเร็วที่สุด ไปยังรายงานที่ถ่ายทอดบนลูกโซ่ DON สร้างแรงจูงใจให้โหนดโต้แย้งไม่ถูกต้อง รายงาน: การรวมโหนดอย่างไม่ถูกต้องในชุดย่อยนี้หมายถึงการยกเว้นโหนดอย่างไม่ถูกต้อง ที่ควรรวมไว้จึงลงโทษอย่างไม่ถูกต้อง ความล้มเหลวในการรายงานซ้ำโดย DON จะสร้างแรงจูงใจให้โหนดที่ซื่อสัตย์ออกจาก DON. การรวบรวมประวัติการปฏิบัติงานที่ถูกต้องและผลที่ตามมาโดยกระจายอำนาจ ความสามารถของผู้ใช้ในการระบุโหนดที่มีประสิทธิภาพสูงและสำหรับตัวดำเนินการโหนดในการสร้าง ชื่อเสียงเป็นคุณลักษณะเด่นที่สำคัญของระบบนิเวศ Chainlink เรา แสดงในส่วนที่ 9 ว่าเราจะให้เหตุผลเกี่ยวกับสิ่งเหล่านั้นในฐานะส่วนสำคัญของความเข้มงวดและได้อย่างไร มุมมองที่กว้างขวางของความมั่นคงทางเศรษฐกิจที่จัดทำโดย DONs

บริการกระจายอำนาจที่เปิดใช้งานโดยการกระจายอำนาจ

ออราเคิล เน็ตเวิร์กส์ เพื่อแสดงให้เห็นความเก่งกาจของ DONs และวิธีที่พวกมันเปิดใช้งานบริการใหม่ๆ มากมาย เรานำเสนอห้าตัวอย่างของแอปพลิเคชันที่ใช้ DON ในส่วนนี้และอธิบาย สัญญาแบบผสมที่ตระหนักถึง: (1) Proof of Reserves ซึ่งเป็นรูปแบบของบริการข้ามสายโซ่; (2) การเชื่อมต่อกับระบบองค์กร / ระบบเดิม นั่นคือ การสร้างมิดเดิลแวร์ เลเยอร์นามธรรมที่อำนวยความสะดวกในการพัฒนาแอปพลิเคชัน blockchain โดยน้อยที่สุด blockchain-รหัสเฉพาะหรือความเชี่ยวชาญ; (3) ข้อมูลระบุตัวตนแบบกระจายอำนาจ เครื่องมือที่ทำให้ผู้ใช้สามารถ รับและจัดการเอกสารประจำตัวและข้อมูลประจำตัวของตนเอง (4) ช่องทางลำดับความสำคัญ บริการที่ช่วยให้มั่นใจในการรวมธุรกรรมโครงสร้างพื้นฐานที่สำคัญได้ทันเวลา (เช่น oracle รายงาน) บน blockchain; และ (5) การรักษาความลับ DeFi นั่นคือ การเงิน smart contracts ที่ปกปิดข้อมูลที่ละเอียดอ่อนของบุคคลที่เข้าร่วม นี่เรา

ใช้ SC เพื่อแสดงส่วน MAINCHAIN ของสัญญาแบบไฮบริดและอธิบาย DON องค์ประกอบแยกกันหรือในแง่ของผู้บริหารที่ปฏิบัติการได้ 4.1 หลักฐานการสำรอง สำหรับหลายแอปพลิเคชัน การถ่ายทอดสถานะระหว่างหรือระหว่าง blockchains จะเป็นประโยชน์ ก แอปพลิเคชันยอดนิยมของบริการดังกล่าวคือการห่อสกุลเงินดิจิตอล ห่อเหรียญดังกล่าว เนื่องจาก WBTC [15] กำลังกลายเป็นสินทรัพย์ยอดนิยมใน Decentralized Finance (DeFi) พวกเขา เกี่ยวข้องกับการฝากสินทรัพย์สำรอง "ที่ห่อไว้" บนแหล่งที่มา blockchain MAINCHAIN(1) และสร้าง token ที่สอดคล้องกันบนเป้าหมาย blockchain MAINCHAIN(2) ที่แตกต่างกัน ตัวอย่างเช่น WBTC คือ ERC20 token บน Ethereum blockchain ที่สอดคล้อง เป็น BTC บน Bitcoin blockchain เนื่องจากสัญญาบน MAINCHAIN(2) ไม่สามารถมองเห็นได้โดยตรงใน MAINCHAIN(1) พวกเขาจะต้องอาศัย oracle อย่างชัดเจนหรือโดยปริยายเพื่อรายงานเงินฝากของที่ห่อไว้ สินทรัพย์ใน smart contract ซึ่งบางครั้งเรียกว่าหลักฐานการสำรอง ใน WBTC [15] ตัวอย่างเช่น ผู้ดูแล BitGo ถือ BTC และออก WBTC โดยมี Chainlink เครือข่ายที่ให้หลักฐานการสำรอง [76] DON สามารถแสดงหลักฐานการสำรองได้ด้วยตนเอง อย่างไรก็ตาม ด้วย DON ก็เป็นไปได้ เพื่อไปต่อ DON สามารถจัดการความลับและผ่านการใช้อะแดปเตอร์ที่เหมาะสม สามารถทำธุรกรรมกับ blockchain ที่ต้องการได้ ดังนั้นจึงเป็นไปได้ที่ DON จะดำเนินการ ในฐานะหนึ่งในผู้รับฝากทรัพย์สินจำนวนหนึ่ง—หรือแม้แต่ในฐานะผู้รับฝากทรัพย์สินที่มีการกระจายอำนาจแต่เพียงผู้เดียว—สำหรับ สินทรัพย์ที่ถูกห่อ DONs จึงสามารถใช้เป็นแพลตฟอร์มในการปรับปรุงความปลอดภัยของ บริการที่มีอยู่ซึ่งใช้หลักฐานการสำรอง ตัวอย่างเช่น สมมติว่า MAINCHAIN(1) คือ Bitcoin และ MAINCHAIN(2) คือ Ethereum ใน MAINCHAIN(2) สัญญา SC จะออก tokens ซึ่งเป็นตัวแทนของ BTC ที่ห่อไว้ DON ควบคุมที่อยู่ BTC addr(1) DON. ในการห่อ BTC ผู้ใช้ U ส่ง X BTC มา เพิ่ม(1) คุณ เพื่อเพิ่ม(1) DON พร้อมด้วย MAINCHAIN(2) - ที่อยู่ addr(2) คุณ จอภาพ DON เพิ่ม(1) DON ผ่านอะแดปเตอร์ไปยัง MAINCHAIN(1) เมื่อสังเกตเงินฝากของ U ด้วยการยืนยันความน่าจะเป็นสูงเพียงพอ มันจะส่งข้อความถึง SC ผ่านอะแดปเตอร์ไปที่ เมนเชน(2) ข้อความนี้แนะนำให้ SC สร้าง X tokens สำหรับ addr(2) คุณ สำหรับ U ที่จะปล่อย X tokens สิ่งที่ตรงกันข้ามจะเกิดขึ้น อย่างไรก็ตามบน MAINCHAIN(1) เพิ่ม(1) DON ส่ง X BTC ไปที่ addr(1) U (หรือไปยังที่อยู่อื่น หากผู้ใช้ร้องขอ) แน่นอนว่าโปรโตคอลเหล่านี้สามารถปรับเปลี่ยนให้ทำงานกับการแลกเปลี่ยนได้ แทนที่จะปรับใช้โดยตรง กับผู้ใช้ 4.2 การเชื่อมต่อกับระบบ Enterprise / Legacy DONs สามารถทำหน้าที่เป็นสะพานเชื่อมระหว่างและระหว่าง blockchains ได้ ดังในตัวอย่างของ Proof ของกำลังสำรอง แต่วัตถุประสงค์อีกประการหนึ่งคือเพื่อให้ทำหน้าที่เป็นสะพานเชื่อมสองทิศทางระหว่าง blockchains และระบบเดิม [176] หรือระบบที่คล้าย blockchain เช่น ธนาคารกลาง สกุลเงินดิจิทัล [30]. องค์กรต่างๆ เผชิญกับความท้าทายหลายประการในการเชื่อมต่อระบบที่มีอยู่และ กระบวนการไปสู่ระบบกระจายอำนาจ ได้แก่ :• ความคล่องตัวของบล็อคเชน: ระบบบล็อคเชนเปลี่ยนแปลงอย่างรวดเร็ว องค์กรอาจเผชิญกับรูปลักษณ์ใหม่ที่รวดเร็วหรือความนิยมที่เพิ่มขึ้นของ blockchains ซึ่ง คู่สัญญาประสงค์ที่จะทำธุรกรรม แต่กิจการไม่มี การสนับสนุนในโครงสร้างพื้นฐานที่มีอยู่ โดยทั่วไปแล้ว blockchains จะทำให้มีพลวัต เป็นเรื่องยากสำหรับองค์กรแต่ละแห่งที่จะตามทันระบบนิเวศที่สมบูรณ์ • ทรัพยากรการพัฒนาเฉพาะด้านบล็อคเชน: สำหรับหลายๆ องค์กร การจ้างหรือการบ่มเพาะความเชี่ยวชาญ blockchain ที่ล้ำสมัยนั้นเป็นเรื่องยาก โดยเฉพาะอย่างยิ่งในมุมมองของ ความท้าทายของความคล่องตัว • การจัดการคีย์ส่วนตัว: การจัดการคีย์ส่วนตัวสำหรับ blockchains หรือ cryptocurrencies ต้องใช้ความเชี่ยวชาญในการปฏิบัติงานที่แตกต่างจากความปลอดภัยทางไซเบอร์แบบเดิม แนวทางปฏิบัติและไม่สามารถใช้งานได้กับองค์กรหลายแห่ง • การรักษาความลับ: องค์กรต่างๆ มักหลอกลวงการเปิดเผยข้อมูลที่ละเอียดอ่อนและเป็นกรรมสิทธิ์ของตน ข้อมูลบนห่วงโซ่ เพื่อจัดการกับปัญหาสามประการแรก นักพัฒนาสามารถใช้ DON เป็นเลเยอร์มิดเดิลแวร์ที่ปลอดภัยเพื่อให้ระบบองค์กรสามารถอ่านหรือเขียนถึงได้ blockchainส. DON สามารถสรุปข้อพิจารณาทางเทคนิคโดยละเอียดได้ เช่น พลศาสตร์ของก๊าซ การปรับโครงสร้างห่วงโซ่ และอื่นๆ สำหรับทั้งนักพัฒนาและผู้ใช้ โดย นำเสนออินเทอร์เฟซ blockchain ที่มีความคล่องตัวให้กับระบบองค์กร ดังนั้น DON จึงสามารถทำได้ ลดความซับซ้อนอย่างมากในการพัฒนาแอปพลิเคชันระดับองค์กรที่รับรู้ blockchain โดยขจัดภาระจากองค์กรในการรับหรือบ่มเพาะ blockchain- ทรัพยากรการพัฒนาเฉพาะ การใช้ DONs ดังกล่าวมีความน่าสนใจเป็นพิเศษตรงที่ช่วยให้นักพัฒนาระดับองค์กรสามารถทำได้ สร้างแอปพลิเคชันสัญญาอัจฉริยะที่ส่วนใหญ่ blockchain ไม่เชื่อเรื่องพระเจ้า เป็นผลให้ ใหญ่กว่าชุดของ blockchains ซึ่ง DON ถูกกำหนดให้ทำหน้าที่เป็นมิดเดิลแวร์ เพิ่มชุด blockchains ซึ่งผู้ใช้ระดับองค์กรสามารถเข้าถึงได้ง่าย นักพัฒนา สามารถย้ายแอปพลิเคชันจาก blockchains ที่มีอยู่ไปยังแอปพลิเคชันใหม่โดยมีการปรับเปลี่ยนเพียงเล็กน้อย ไปยังแอปพลิเคชันที่พัฒนาขึ้นภายใน เพื่อแก้ไขปัญหาเพิ่มเติมเกี่ยวกับการรักษาความลับ นักพัฒนาสามารถยื่นอุทธรณ์ต่อ เครื่องมือที่เราแนะนำในบทความนี้และคาดว่าจะปรับใช้เพื่อรองรับแอปพลิเคชัน DON ซึ่งรวมถึง DECO และ Town Crier Section 3.6.2 ตลอดจนการรักษาความลับ การปรับเปลี่ยน API ที่กล่าวถึงในส่วนที่ 7.1.2 และแนวทางการใช้งานเฉพาะจำนวนหนึ่งที่กล่าวถึงในส่วนที่เหลือของส่วนนี้ ระบบ DON เหล่านี้สามารถให้ได้ การรับรองออนไลน์ที่มีความสมบูรณ์สูงเกี่ยวกับสถานะระบบขององค์กรโดยไม่เปิดเผย ข้อมูลต้นทางขององค์กรที่มีความละเอียดอ่อนบนเครือข่าย 4.3 การระบุตัวตนแบบกระจายอำนาจ การระบุตัวตนแบบกระจายอำนาจเป็นคำทั่วไปสำหรับความคิดที่ผู้ใช้ควรจะสามารถทำได้ รับและจัดการข้อมูลประจำตัวของตนเอง แทนที่จะอาศัยบุคคลที่สามทำ ดังนั้น ข้อมูลรับรองแบบกระจายอำนาจเป็นเครื่องยืนยันถึงคุณลักษณะหรือการยืนยันของผู้ถือซึ่งมักเรียกว่าการเรียกร้อง ข้อมูลรับรองจะมีการลงนามแบบดิจิทัลโดยหน่วยงานต่างๆ ซึ่งมักเรียกว่า ผู้ออกที่สามารถเชื่อมโยงการเรียกร้องกับผู้ใช้ได้อย่างน่าเชื่อถือ ในแผนการที่เสนอส่วนใหญ่ การเรียกร้องมีความเกี่ยวข้องกับตัวระบุแบบกระจายอำนาจ (DID) ซึ่งเป็นตัวระบุสากลสำหรับ ผู้ใช้ที่กำหนด ข้อมูลรับรองถูกผูกไว้กับกุญแจสาธารณะซึ่งมีรหัสส่วนตัวที่ผู้ใช้ถืออยู่ ผู้ใช้สามารถพิสูจน์การครอบครองการเรียกร้องได้โดยใช้รหัสส่วนตัวของเธอ มีวิสัยทัศน์ในฐานะอัตลักษณ์แบบกระจายอำนาจ ทั้งแผนงานที่มีอยู่และที่เสนอ เช่น [14, 92, 129, 216] มีข้อจำกัดร้ายแรงสามประการ: • ขาดความเข้ากันได้แบบเดิม: ระบบการระบุตัวตนแบบกระจายอำนาจที่มีอยู่นั้นอาศัย ชุมชนของหน่วยงานที่เรียกว่าผู้ออก เพื่อสร้างข้อมูลรับรอง DID เพราะว่า บริการเว็บที่มีอยู่โดยทั่วไปไม่ได้เซ็นชื่อแบบดิจิทัลในข้อมูล แต่จะต้องเปิดตัวผู้ออก เป็นระบบวัตถุประสงค์พิเศษ เพราะไม่มีแรงจูงใจให้ทำเช่นนี้หากไม่มี ระบบนิเวศกระจายอำนาจอัตลักษณ์ ปัญหาไก่กับไข่ส่งผลให้เกิด ในด้านอื่นๆ ยังไม่ชัดเจนว่าจะบูตระบบนิเวศของผู้ออกตราสารได้อย่างไร • การจัดการคีย์ที่ไม่สามารถใช้งานได้: ระบบการระบุตัวตนแบบกระจายอำนาจต้องการให้ผู้ใช้ดำเนินการ จัดการคีย์ส่วนตัว ซึ่งเป็นสิ่งที่ประสบการณ์เกี่ยวกับสกุลเงินดิจิทัลได้แสดงให้เห็นแล้ว ให้เป็นภาระที่ไม่สามารถดำเนินการได้ คาดว่ามีประมาณ 4,000,000 Bitcoin ไปแล้ว สูญหายไปตลอดกาลเนื่องจากความล้มเหลวในการจัดการคีย์ [194] และผู้ใช้จำนวนมากก็จัดเก็บไว้ สินทรัพย์ crypto ที่มีการแลกเปลี่ยน [193] ซึ่งบ่อนทำลายการกระจายอำนาจ • ขาดการต่อต้าน Sybil ที่รักษาความเป็นส่วนตัว: ข้อกำหนดด้านความปลอดภัยขั้นพื้นฐานของแอปพลิเคชัน เช่น การลงคะแนน การจัดสรร tokens อย่างยุติธรรมระหว่างการขาย token ฯลฯ ก็คือ ผู้ใช้ไม่สามารถยืนยันตัวตนหลายรายการได้ ข้อเสนอการระบุตัวตนแบบกระจายอำนาจที่มีอยู่กำหนดให้ผู้ใช้ต้องเปิดเผยตัวตนในโลกแห่งความเป็นจริงเพื่อที่จะบรรลุเป้าหมายดังกล่าว การต่อต้านของซีบิล ซึ่งบ่อนทำลายการรับประกันความเป็นส่วนตัวที่สำคัญ เป็นไปได้ที่จะแก้ไขปัญหาเหล่านี้โดยใช้การรวมกันของคณะกรรมการโหนด ดำเนินการคำนวณแบบกระจายภายใน DON และการใช้เครื่องมือเช่น DECO หรือ Town Crier ดังที่แสดงในระบบที่เรียกว่า CanDID [160] DECO หรือ Town Crier สามารถเปลี่ยนบริการเว็บที่มีอยู่ได้โดยไม่ต้องแก้ไข สู่ผู้ออกหนังสือรับรองที่รักษาความลับ พวกเขาเปิดใช้งาน DON เพื่อส่งออกที่เกี่ยวข้อง ข้อมูลเพื่อจุดประสงค์นี้ให้เป็นข้อมูลประจำตัวในขณะที่ปกปิดข้อมูลที่ละเอียดอ่อนซึ่งไม่ควร ปรากฏในหนังสือรับรอง นอกจากนี้ เพื่ออำนวยความสะดวกในการกู้คืนคีย์สำหรับผู้ใช้ ซึ่งเกี่ยวข้องกับการจัดการคีย์ ปัญหา DON สามารถอนุญาตให้ผู้ใช้สามารถจัดเก็บคีย์ส่วนตัวในรูปแบบการแชร์ที่เป็นความลับได้ ผู้ใช้สามารถ กู้คืนกุญแจของพวกเขาโดยการพิสูจน์โหนดใน DON ในทำนองเดียวกันโดยใช้ Town Crier หรือ DECO—ความสามารถในการลงชื่อเข้าใช้บัญชีด้วยชุดผู้ให้บริการเว็บที่กำหนดไว้ล่วงหน้า (เช่น ทวิตเตอร์, กูเกิล, เฟซบุ๊ก) ประโยชน์ของการใช้ Town Crier หรือ DECO เมื่อเทียบกับ OAUTH คือความเป็นส่วนตัวของผู้ใช้ เครื่องมือทั้งสองนี้ช่วยให้ผู้ใช้หลีกเลี่ยงการเปิดเผยต่อ DON ตัวระบุผู้ให้บริการเว็บ ซึ่งมักจะได้รับข้อมูลประจำตัวในโลกแห่งความเป็นจริง สุดท้ายนี้ เพื่อให้มีความต้านทานของซีบิล ดังที่แสดงใน [160] เป็นไปได้ที่ DON จะ ดำเนินการเปลี่ยนแปลงการรักษาความเป็นส่วนตัวของตัวระบุในโลกแห่งความเป็นจริงที่ไม่ซ้ำใครสำหรับผู้ใช้ (เช่น หมายเลขประกันสังคม (SSN)) ลงในตัวระบุออนไลน์เมื่อลงทะเบียนผู้ใช้ระบบจึงสามารถตรวจจับการลงทะเบียนซ้ำโดยไม่มีข้อมูลที่ละเอียดอ่อนเช่น SSN ถูกเปิดเผยแก่แต่ละ DON nodes.7 DON สามารถให้บริการใดๆ เหล่านี้ในนามของข้อมูลประจำตัวที่มีการกระจายอำนาจภายนอก ระบบบน blockchains ที่ไม่ได้รับอนุญาตหรือได้รับอนุญาต เช่น อินสแตนซ์ของ Hyperledger อินดี้ [129]. ตัวอย่างการใช้งาน: KYC: การระบุตัวตนแบบกระจายอำนาจถือเป็นหนทางในการ ปรับปรุงข้อกำหนดสำหรับแอปพลิเคชันทางการเงินบน blockchains ในขณะที่ปรับปรุงผู้ใช้ ความเป็นส่วนตัว ความท้าทายสองประการที่สามารถช่วยแก้ไขได้คือภาระหน้าที่ด้านการรับรองและการปฏิบัติตามข้อกำหนดภายใต้กฎระเบียบป้องกันการฟอกเงิน / การรับรู้ลูกค้าของคุณ (AML / KYC) กฎระเบียบ AML ในหลายประเทศกำหนดให้สถาบันการเงิน (และธุรกิจอื่นๆ) สร้างและตรวจสอบตัวตนของบุคคลและธุรกิจที่ พวกเขาทำธุรกรรม KYC เป็นองค์ประกอบหนึ่งของสถาบันการเงิน นโยบาย AML ที่กว้างขึ้น ซึ่งโดยทั่วไปเกี่ยวข้องกับการติดตามพฤติกรรมของผู้ใช้และการเฝ้าดูการไหลของเงินทุน เหนือสิ่งอื่นใด โดยทั่วไป KYC จะเกี่ยวข้องกับการนำเสนอข้อมูลประจำตัวของผู้ใช้ในบางรูปแบบ (เช่น เข้าสู่เว็บฟอร์มออนไลน์โดยชูเอกสารประจำตัวต่อหน้าผู้ใช้ ในเซสชันวิดีโอ ฯลฯ) การสร้างและการนำเสนอข้อมูลประจำตัวแบบกระจายอำนาจอย่างปลอดภัย โดยหลักการแล้วสามารถเป็นทางเลือกที่เป็นประโยชน์หลายประการได้ กล่าวคือ (1) การทำ กระบวนการ KYC มีประสิทธิภาพมากขึ้นสำหรับผู้ใช้และสถาบันการเงิน เพราะครั้งหนึ่ง ได้รับหนังสือรับรองแล้วสามารถนำเสนอต่อสถาบันการเงินใด ๆ ได้อย่างราบรื่น (2) การลดการฉ้อโกงโดยการลดโอกาสในการขโมยข้อมูลส่วนตัวผ่านการประนีประนอม ของข้อมูลส่วนบุคคล (PII) และการปลอมแปลงระหว่างการตรวจสอบวิดีโอ และ (3) การลดความเสี่ยงของการประนีประนอม PII ในสถาบันการเงิน เนื่องจากผู้ใช้ยังคงควบคุมได้ ของข้อมูลของตนเอง เมื่อพิจารณาจากค่าปรับหลายพันล้านดอลลาร์ที่สถาบันการเงินจ่ายสำหรับความล้มเหลวในการปฏิบัติตาม AML และสถาบันการเงินหลายแห่งใช้จ่ายหลายล้านดอลลาร์ต่อปีไปกับ KYC การปรับปรุงอาจช่วยประหยัดเงินได้มากสำหรับสถาบันการเงิน และสำหรับผู้บริโภค [196] ในขณะที่ภาคการเงินแบบดั้งเดิมยังชะลอตัว เพื่อนำเครื่องมือการปฏิบัติตามข้อกำหนดใหม่ๆ มาใช้ ระบบ DeFi จึงหันมาใช้ [43] มากขึ้น ตัวอย่างการใช้งาน: สินเชื่อที่มีหลักประกันต่ำ: แอปพลิเคชัน DeFi ส่วนใหญ่นั้น สนับสนุนการให้กู้ยืมในวันนี้มาจากสินเชื่อที่มีหลักประกันเท่านั้น เหล่านี้เป็นเงินกู้ที่ทำ แก่ผู้กู้ยืมที่ฝากทรัพย์สินสกุลเงินดิจิตอลที่มีมูลค่าเกินกว่าเงินกู้ยืม ความสนใจได้เกิดขึ้นเมื่อไม่นานมานี้ในสิ่งที่ชุมชน DeFi โดยทั่วไปเรียกว่าสินเชื่อที่มีหลักประกันต่ำเกินไป ในทางตรงกันข้ามเป็นการกู้ยืมที่มีหลักประกันที่เกี่ยวข้อง มีมูลค่าน้อยกว่าเงินต้นของเงินกู้ สินเชื่อที่มีหลักทรัพย์ค้ำประกันต่ำ คล้ายกับการกู้ยืมที่มักทำโดยสถาบันการเงินแบบดั้งเดิม แทนที่จะพึ่ง. สำหรับหลักประกันที่ฝากไว้เป็นหลักประกันการชำระคืนเงินกู้จะใช้การให้กู้ยืมแทน การตัดสินใจเกี่ยวกับประวัติเครดิตของผู้กู้ 7การแปลงนี้อาศัยฟังก์ชันสุ่มเทียมแบบกระจาย (PRF)สินเชื่อที่มีหลักประกันต่ำกว่านั้นถือเป็นส่วนใหม่แต่กำลังเติบโตของตลาดการให้กู้ยืม DeFi พวกเขาพึ่งพากลไกเช่นเดียวกับที่ใช้โดยการเงินแบบดั้งเดิม สถาบัน เช่น สัญญาทางกฎหมาย [91] ข้อกำหนดที่สำคัญสำหรับการเจริญเติบโต จะเป็นความสามารถในการจัดหาข้อมูลเกี่ยวกับความน่าเชื่อถือทางเครดิตของผู้ใช้ ซึ่งเป็นปัจจัยสำคัญในการตัดสินใจให้กู้ยืมแบบเดิม ให้กับระบบ DeFi ในลักษณะที่ให้ความสมบูรณ์ที่แข็งแกร่ง กล่าวคือ การประกันข้อมูลที่ถูกต้อง DON ที่เปิดใช้งานระบบการระบุตัวตนแบบกระจายอำนาจจะช่วยให้ผู้ที่จะเป็นผู้กู้ยืมสามารถ สร้างข้อมูลรับรองที่มีความเชื่อมั่นสูงเพื่อยืนยันถึงความน่าเชื่อถือทางเครดิตในขณะที่ยังคงรักษาไว้ การรักษาความลับของข้อมูลที่ละเอียดอ่อน โดยเฉพาะอย่างยิ่งผู้กู้ยืมสามารถสร้างสิ่งเหล่านี้ได้ ข้อมูลรับรองตามบันทึกจากแหล่งข้อมูลออนไลน์ที่เชื่อถือได้ในขณะที่เปิดเผยเฉพาะ ข้อมูลที่รับรองโดย DON โดยไม่เปิดเผยข้อมูลอื่นๆ ที่อาจละเอียดอ่อน สำหรับ ตัวอย่างเช่น ผู้กู้สามารถสร้างหนังสือรับรองที่ระบุคะแนนเครดิตของเธอด้วย สำนักงานข้อมูลเครดิตชุดหนึ่งเกินเกณฑ์ที่กำหนด (เช่น 750) โดยไม่เปิดเผยเธอ คะแนนที่แม่นยำหรือข้อมูลอื่นใดในบันทึกของเธอ นอกจากนี้ หากต้องการ หนังสือรับรองดังกล่าว สามารถสร้างได้โดยไม่เปิดเผยตัวตน กล่าวคือ ชื่อผู้ใช้สามารถถือเป็นข้อมูลที่ละเอียดอ่อนได้ และตัวมันเองไม่ได้ถูกเปิดเผยต่อโหนด oracle หรือในข้อมูลประจำตัวแบบกระจายอำนาจของเธอ หนังสือรับรอง สามารถใช้กับโซ่หรือออฟเชนได้ ขึ้นอยู่กับการใช้งาน โดยสรุป ผู้กู้สามารถให้ข้อมูลที่จำเป็นแก่ผู้ให้กู้เกี่ยวกับเครดิตของตนได้ ประวัติศาสตร์ที่มีความซื่อสัตย์สุจริตและไม่มีความเสี่ยงต่อการเปิดเผยสิ่งที่ไม่จำเป็นและละเอียดอ่อน ข้อมูล ผู้ยืมยังสามารถจัดเตรียมข้อมูลประจำตัวเพื่อรักษาความลับอื่นๆ ได้อีกมากมาย ช่วยในการตัดสินใจสินเชื่อ ตัวอย่างเช่น ข้อมูลประจำตัวสามารถเป็นพยานถึงผู้ยืมได้ การครอบครองสินทรัพย์ (นอกเครือข่าย) ดังที่เราแสดงในตัวอย่างถัดไป ตัวอย่างการใช้งาน: การรับรองระบบ: เขตอำนาจศาลหลายแห่งจำกัดประเภทของนักลงทุนที่สามารถขายหลักทรัพย์ที่ไม่ได้จดทะเบียนได้ ตัวอย่างเช่น ในสหรัฐอเมริกา SEC ระเบียบ D กำหนดว่าจะได้รับการรับรองสำหรับโอกาสในการลงทุนดังกล่าว บุคคลต้องมีมูลค่าสุทธิ 1 ล้านเหรียญสหรัฐ มีคุณสมบัติตรงตามข้อกำหนดรายได้ขั้นต่ำ หรือมีคุณสมบัติทางวิชาชีพบางอย่าง [209, 210] การรับรองในปัจจุบัน กระบวนการยุ่งยากและไม่มีประสิทธิภาพ โดยมักต้องมีหนังสือรับรองจาก นักบัญชีหรือหลักฐานที่คล้ายกัน ระบบการระบุตัวตนแบบกระจายอำนาจจะช่วยให้ผู้ใช้สามารถสร้างข้อมูลรับรองได้ บัญชีบริการทางการเงินออนไลน์ที่มีอยู่ซึ่งพิสูจน์การปฏิบัติตามการรับรอง กฎระเบียบ อำนวยความสะดวกให้กับกระบวนการ KYC ที่มีประสิทธิภาพและรักษาความเป็นส่วนตัวมากขึ้น ที่ คุณสมบัติการรักษาความเป็นส่วนตัวของ DECO และ Town Crier จะอนุญาตสิ่งเหล่านี้ด้วย ข้อมูลรับรองที่จะสร้างด้วยการรับประกันความซื่อสัตย์อย่างเข้มงวด โดยไม่เปิดเผยรายละเอียดสถานะทางการเงินของผู้ใช้โดยตรง ตัวอย่างเช่น ผู้ใช้สามารถสร้างข้อมูลรับรองได้ พิสูจน์ว่าเธอมีมูลค่าสุทธิอย่างน้อย 1 ล้านเหรียญสหรัฐโดยไม่เปิดเผยข้อมูลเพิ่มเติม ข้อมูลเกี่ยวกับสถานะทางการเงินของเธอ 4.4 ช่องลำดับความสำคัญ ช่องทางสำคัญเป็นบริการใหม่ที่มีประโยชน์ซึ่งสร้างได้ง่ายโดยใช้ DON พวกเขา

เป้าหมายคือการส่งมอบธุรกรรมที่มีลำดับความสำคัญสูงที่เลือกไว้ในเวลาที่เหมาะสมบน MAINCHAIN ในช่วงที่โครงข่ายขัดข้อง ช่องลำดับความสำคัญอาจถูกมองว่าเป็นรูปแบบหนึ่งของ สัญญาซื้อขายล่วงหน้าบน Block Space และในฐานะสินค้าโภคภัณฑ์ crypto ซึ่งเป็นคำที่บัญญัติขึ้นมาเป็นส่วนหนึ่ง ของโครงการชิคาโก [61, 136]. ช่องทางการจัดลำดับความสำคัญมีไว้สำหรับนักขุดโดยเฉพาะเพื่อเปิดใช้งานบริการโครงสร้างพื้นฐาน เช่น oracles ฟังก์ชันการกำกับดูแลสำหรับสัญญา ฯลฯ ไม่ใช่สำหรับกิจกรรมระดับผู้ใช้ทั่วไป เช่น ธุรกรรมทางการเงิน ที่จริงแล้ว ตามที่ออกแบบไว้ที่นี่ ถือเป็นเรื่องสำคัญ ช่องทางที่ดำเนินการโดยน้อยกว่า 100% ของกำลังการขุดในเครือข่ายสามารถทำได้เท่านั้น ให้ขอบเขตเวลาในการจัดส่งที่หลวม ป้องกันการใช้งานที่ขึ้นอยู่กับความเร็วสูง เป้าหมายเช่นการวิ่งหน้า รูปที่ 10: ช่องลำดับความสำคัญคือการรับประกันโดยนักขุด M หรือโดยทั่วไปคือ a ชุดของนักขุด M—ถึงผู้ใช้ U ว่าธุรกรรมของเธอ τ จะถูกขุดภายในบล็อก D ของการรวมอยู่ในเมมพูล สัญญา SC สามารถใช้การตรวจสอบ DON เพื่อบังคับใช้ เงื่อนไขการให้บริการของช่อง ช่องทางลำดับความสำคัญอยู่ในรูปแบบของข้อตกลงระหว่างนักขุดหรือกลุ่มนักขุด (หรือกลุ่มการขุด) M ที่ให้ช่องทางและผู้ใช้ U ที่จ่ายค่าธรรมเนียมในการเข้าถึง M ตกลงว่าเมื่อคุณส่งธุรกรรม τ ไปยัง mempool (ด้วยราคาก๊าซใด ๆแต่เป็นขีดจำกัดของก๊าซตามที่ตกลงกันไว้ล่วงหน้า) M จะวางไว้บนโซ่ภายในบล็อก D ถัดไป แนวคิดนี้แสดงไว้เป็นแผนผังในรูปที่ 10 คำอธิบายสัญญาช่องทางลำดับความสำคัญ: ช่องทางลำดับความสำคัญอาจถูกรับรู้เป็น ไฮบริด smart contract ประมาณนี้ เราปล่อยให้ SC แสดงถึงตรรกะบน MAINCHAIN และนั่นใน DON โดย exec SC รับเงินฝาก / เงินเดิมพัน \(d from M and an advance payment \)p จาก U.A DON ผู้บริหารที่ปฏิบัติการได้ตรวจสอบ mempool ซึ่งทริกเกอร์ในตำแหน่งของธุรกรรม โดย U จะส่งข้อความแจ้งความสำเร็จถึง SC หาก U ส่งธุรกรรมที่ M ทำเหมือง วิธีที่ทันท่วงทีและข้อความแจ้งข้อผิดพลาดในกรณีที่บริการขัดข้อง SC ชำระเงิน $p ให้กับ M โดยได้รับข้อความแสดงความสำเร็จ และส่งเงินคงเหลือทั้งหมด รวมถึง $d ถึง U หากได้รับข้อความแสดงความล้มเหลว เมื่อเลิกจ้างได้สำเร็จแล้ว ปล่อยเงินฝาก $d ให้กับ M แน่นอนว่าเครื่องขุด M สามารถจัดเตรียมช่องสัญญาณลำดับความสำคัญพร้อมกันให้กับหลายช่องได้ ผู้ใช้และสามารถเปิดช่องทางสำคัญกับ U สำหรับจำนวนข้อความที่ตกลงไว้ล่วงหน้า 4.5 การรักษาความลับ-การรักษา DeFi / Mixicles ในปัจจุบัน DeFi แอปพลิเคชัน [1] ให้ข้อมูลเป็นความลับเพียงเล็กน้อยหรือไม่มีเลยสำหรับผู้ใช้: ธุรกรรมทั้งหมดสามารถมองเห็นได้บนลูกโซ่ แนวทางที่อิงความรู้เป็นศูนย์ต่างๆ เช่น [149, 217] สามารถให้ความเป็นส่วนตัวของธุรกรรมได้ และ TEF ก็เพียงพอที่จะสนับสนุนพวกเขา แต่ แนวทางเหล่านี้ไม่ครอบคลุม และโดยทั่วไปไม่ได้ปกปิด ตัวอย่างเช่น สินทรัพย์ที่เป็นฐานของธุรกรรม ชุดเครื่องมือคำนวณที่หลากหลายซึ่งท้ายที่สุดแล้วเราตั้งใจจะสนับสนุนใน DONs ช่วยให้เกิดความเป็นส่วนตัวได้หลายวิธีซึ่งสามารถอุดช่องว่างดังกล่าวได้ ช่วยเสริมการรับประกันความเป็นส่วนตัวของระบบอื่นๆ ตัวอย่างเช่น Mixicles ซึ่งเป็นเครื่องมือที่รักษาความลับ DeFi เสนอโดย Chainlink นักวิจัยจาก Labs [135] สามารถปกปิดได้ ประเภทสินทรัพย์ที่สนับสนุนเครื่องมือทางการเงิน และลงตัวกับ DON อย่างเป็นธรรมชาติ กรอบงาน Mixicles สามารถอธิบายได้ง่ายที่สุดในแง่ของการใช้งานเพื่อให้ได้ไบนารี่แบบง่าย ตัวเลือก ไบนารี่ออฟชั่นเป็นเครื่องมือทางการเงินที่มีผู้ใช้สองคนซึ่งเราจะทำ อ้างถึงที่นี่เพื่อความสอดคล้องกับ [135] ในฐานะผู้เล่น เดิมพันเหตุการณ์ที่เป็นไปได้สองรายการ ผลลัพธ์ เช่น สินทรัพย์จะสูงกว่าราคาเป้าหมาย ณ เวลาที่กำหนดไว้ล่วงหน้าหรือไม่ ตัวอย่างต่อไปนี้แสดงให้เห็นถึงแนวคิดนี้ ตัวอย่างที่ 2 อลิซและบ็อบเป็นคู่สัญญาในไบนารี่ออฟชั่นตามมูลค่าของสินทรัพย์ เรียกว่า Carol's Bubble Token (CBT) อลิซเดิมพันว่า CBT จะมีราคาตลาดอยู่ที่ อย่างน้อย 250 USD ณ เวลา T = เที่ยงของวันที่ 21 มิถุนายน 2025 บ๊อบเดิมพันกลับกัน ผู้เล่นแต่ละคน ฝากเงิน 100 ETH ตามกำหนดเวลาที่กำหนดไว้ล่วงหน้า ผู้เล่นที่มีตำแหน่งชนะ ได้รับ 200 ETH (เช่น ได้รับ 100 ETH) แน่นอนว่า 8D จะต้องมีขนาดใหญ่พอที่จะทำให้ M สามารถปฏิบัติตามความน่าจะเป็นสูงได้ สำหรับ เช่น ถ้า M ควบคุม 20% ของกำลังการขุดในเครือข่าย ก็อาจเลือก D = 100 เพื่อให้มั่นใจว่า ความน่าจะเป็นที่จะล้มเหลวที่ µ2 × 10−10 นั่นคือน้อยกว่าหนึ่งในพันล้านด้วยเครือข่าย Chainlink oracle O ที่มีอยู่ ทำให้ง่ายต่อการใช้งานระบบอัจฉริยะ สัญญา SC ที่ตระหนักถึงข้อตกลงในตัวอย่างที่ 2 ผู้เล่นทั้งสองฝากเงินแต่ละครั้ง 100 ETH ในเซาท์แคโรไลนา บางครั้งหลังจาก T คำค้นหา q จะถูกส่งไปยัง O เพื่อขอราคา r ของ CBT ณ เวลานี้ T.O ส่งรายงานราคานี้ให้ SC SC จึงส่งเงินให้อลิซ ถ้า r ≥250 และ Bob ถ้าไม่ใช่ อย่างไรก็ตาม วิธีการนี้เผยให้เห็นถึง r on chain—ทำให้เป็นเรื่องง่าย สำหรับผู้สังเกตการณ์เพื่ออนุมานสินทรัพย์ที่อยู่ภายใต้ไบนารี่ออปชั่น ในศัพท์เฉพาะของ Mixicles การคิดตามแนวคิดเกี่ยวกับผลลัพธ์จะเป็นประโยชน์ ของ SC ในแง่ของสวิตช์ที่ส่งค่าไบนารี่ที่คำนวณเป็นเพรดิเคต สวิตช์(r) ในตัวอย่างของเรา switch(r) = 0 ถ้า r ≥250; เมื่อพิจารณาผลลัพธ์นี้ อลิซจึงชนะ มิฉะนั้น switch(r) = 1 และ Bob ชนะ DON สามารถรับรู้ Mixicle พื้นฐานเป็นสัญญาแบบไฮบริดได้โดยการเรียกใช้ไฟล์ปฏิบัติการ exec ที่คำนวณ switch(r) และรายงานบนเชนไปยัง SC เราแสดงการก่อสร้างนี้ ในรูปที่ 11 รูปที่ 11: ไดอะแกรมของ Mixicle พื้นฐานในตัวอย่างที่ 2 เพื่อให้ความลับบนเชนสำหรับ รายงาน r และสินทรัพย์ที่อยู่ภายใต้ไบนารี่ออฟชั่น oracle ส่งไปยัง สัญญา SC ผ่านสวิตช์เฉพาะสวิตช์ค่าไบนารี (r) เราระบุอะแดปเตอร์ ConfSwitch ในภาคผนวก C.3 ซึ่งช่วยให้บรรลุเป้าหมายนี้ได้ง่าย เป้าหมายใน DON แนวคิดพื้นฐานเบื้องหลัง ConfSwitch นั้นค่อนข้างเรียบง่าย แทนที่จะมารายงานตัว. ค่า r ConfSwitch รายงานเฉพาะค่าสวิตช์ไบนารีสวิตช์ (r) เอสซีก็ได้ ออกแบบมาเพื่อการชำระเงินที่ถูกต้องตาม switch(r) เพียงอย่างเดียว และ switch(r) ด้วยตัวเอง ไม่เปิดเผยข้อมูลเกี่ยวกับสินทรัพย์อ้างอิง — CBT ในตัวอย่างของเรา นอกจากนี้ โดยการวางไซเฟอร์เท็กซ์บน (q, r) บนบัญชีแยกประเภทที่เข้ารหัสภายใต้ pkaud ซึ่งเป็นกุญแจสาธารณะของ ผู้ตรวจสอบ อะแดปเตอร์ ConfSwitch จะสร้างเส้นทางการตรวจสอบที่รักษาความลับ Mixicle พื้นฐานที่เราเลือกเพื่อความเรียบง่ายในการอธิบายที่นี่ปกปิดเฉพาะ สินทรัพย์และเดิมพันหลังไบนารี่ออฟชั่นในตัวอย่างของเรา Mixicle ที่เต็มเปี่ยม [135] กระป๋อง ให้การรักษาความลับสองรูปแบบ มันปกปิดไม่ให้ผู้สังเกตเห็น: (1) เหตุการณ์อะไร ผู้เล่นเดิมพัน (เช่น q และ r) แต่ยัง (2) ผู้เล่นคนไหนชนะการเดิมพัน เนื่องจาก Mixicles ดำเนินการบน MAINCHAIN ผู้เล่นคนใดคนหนึ่งจึงจำเป็นต้องรีเลย์ switch(r) จาก DON เป็น MAINCHAIN หรือสามารถสร้าง exec ที่ปฏิบัติการได้

ถูกทริกเกอร์บนเอาต์พุตโดย ConfSwitch และเรียกอะแดปเตอร์อื่นเพื่อส่งสวิตช์ (r) ไป เมนเชน. การรักษาความลับประเภทที่สามที่ละเอียดอ่อนก็ควรค่าแก่การพิจารณาเช่นกัน ในการใช้งาน ConfSwitch ขั้นพื้นฐาน O กำลังรันอะแดปเตอร์บน DON และเรียนรู้ สินทรัพย์—CBT ในตัวอย่างของเรา—และด้วยเหตุนี้ลักษณะของไบนารี่ออฟชั่น ตามที่ได้หารือกัน อย่างไรก็ตามในภาคผนวก C.3 สามารถใช้ DECO หรือ Town Crier เพิ่มเติมได้ ปกปิดแม้กระทั่งข้อมูลนี้จาก O ในกรณีนี้ O จะไม่เรียนรู้ข้อมูลเพิ่มเติม กว่าผู้สังเกตการณ์สาธารณะของ คคช. สำหรับรายละเอียดเพิ่มเติมเกี่ยวกับ Mixicles เราแนะนำให้ผู้อ่านไปที่ [135]

บริการจัดลำดับอย่างยุติธรรม

บริการสำคัญอย่างหนึ่งที่เราคาดหวังว่า DON จะได้รับ ซึ่งใช้ประโยชน์จากความสามารถด้านเครือข่าย การคำนวณ และพื้นที่จัดเก็บข้อมูลเรียกว่า Fair Sequencing Services (FSS) แม้ว่า FSS อาจถูกมองว่าเป็นเพียงแอปพลิเคชันที่เกิดขึ้นภายในกรอบงาน DON แต่เราเน้นย้ำว่าเป็นบริการที่เราเชื่อว่าจะเป็นที่ต้องการสูงทั่วทั้ง blockchains และเราคาดหวังว่าเครือข่าย Chainlink จะให้การสนับสนุนอย่างแข็งขัน เมื่อดำเนินการบนเครือข่าย blockchain สาธารณะ แอปพลิเคชัน DeFi จำนวนมากในปัจจุบัน เปิดเผยข้อมูลที่ผู้ใช้สามารถนำไปใช้ประโยชน์เพื่อประโยชน์ของตนเองได้คล้ายคลึงกับ การรั่วไหลของข้อมูลภายในและโอกาสในการจัดการที่แพร่หลายในปัจจุบัน ตลาด [64, 155]. FSS กลับปูทางไปสู่ระบบนิเวศ DeFi ที่ยุติธรรม เอฟเอสเอส ช่วยให้นักพัฒนาสร้างสัญญา DeFi ที่ได้รับการปกป้องจากการปั่นป่วนตลาด อันเป็นผลมาจากการรั่วไหลของข้อมูล จากปัญหาที่เราเน้นด้านล่าง FSS คือ น่าสนใจเป็นพิเศษสำหรับบริการชั้นที่ 2 และเหมาะสมกับกรอบการทำงานสำหรับบริการดังกล่าว ที่เรากล่าวถึงในมาตรา 6 ความท้าทาย: ในระบบที่ไม่ได้รับอนุญาตที่มีอยู่ ธุรกรรมจะถูกเรียงลำดับทั้งหมด ขึ้นอยู่กับดุลยพินิจของคนงานเหมือง ในเครือข่ายที่ได้รับอนุญาต โหนด validator อาจทำงาน พลังเดียวกัน นี่คือรูปแบบหนึ่งของการรวมศูนย์ชั่วคราวที่ส่วนใหญ่ไม่รู้จัก มิฉะนั้นระบบกระจายอำนาจ นักขุดสามารถตรวจสอบธุรกรรมได้ (ชั่วคราว) ผลประโยชน์ของตัวเอง [171] หรือจัดลำดับใหม่เพื่อเพิ่มผลประโยชน์ของตัวเองให้สูงสุด แนวคิดที่เรียกว่ามูลค่าที่สกัดได้ (MEV) [90] คำว่า MEV เป็นการหลอกลวงเล็กน้อย: ไม่ได้อ้างอิงถึง เพื่อประเมินมูลค่าที่นักขุดสามารถจับได้เท่านั้น: ผู้ใช้ทั่วไปสามารถจับ MEV บางตัวได้ เนื่องจากนักขุดมีพลังมากกว่าผู้ใช้ทั่วไป อย่างไรก็ตาม MEV แสดงถึงขอบเขตบนของมูลค่าที่เอนทิตีใด ๆ สามารถรับได้จากการเรียงลำดับใหม่ของฝ่ายตรงข้าม และการแทรกธุรกรรมเสริม แม้ว่านักขุดจะสั่งทำธุรกรรมง่ายๆ ขึ้นอยู่กับค่าธรรมเนียม (ก๊าซ) โดยไม่มีการบิดเบือน ผู้ใช้เองสามารถเปลี่ยนแปลงราคาก๊าซได้ เพื่อข้อได้เปรียบในการทำธุรกรรมของพวกเขามากกว่าการทำธุรกรรมที่มีความซับซ้อนน้อยกว่า ไดอัน และคณะ [90] จัดทำเอกสารและระบุวิธีที่บอท (ไม่ใช่นักขุด) ใช้ ข้อได้เปรียบของพลศาสตร์ของแก๊สในลักษณะที่เป็นอันตรายต่อผู้ใช้ระบบ DeFi ในปัจจุบันและอย่างไร MEV ยังคุกคามความเสถียรของเลเยอร์ฉันทามติที่ซ่อนอยู่ใน blockchain ตัวอย่างอื่นๆ ของการจัดการคำสั่งซื้อธุรกรรมเกิดขึ้นเป็นประจำ เช่น [50, 154]วิธีการประมวลผลธุรกรรมแบบใหม่ เช่น rollups เป็นแนวทางที่น่าหวังมาก ถึงปัญหาการปรับขนาดของปริมาณงานสูง blockchains อย่างไรก็ตามพวกเขาไม่ได้อยู่ ปัญหาของ MEV แต่จะเปลี่ยนไปใช้เอนทิตีที่สร้าง rollup แทน นั่น เอนทิตี ไม่ว่าจะเป็นผู้ดำเนินการของ smart contract หรือผู้ใช้ที่ตกแต่ง (zk-)rollup ด้วย หลักฐานความถูกต้องมีอำนาจในการสั่งและแทรกธุรกรรม กล่าวอีกนัยหนึ่ง rollups สลับ MEV สำหรับ REV: ค่าสะสมที่แยกได้ MEV ส่งผลกระทบต่อธุรกรรมที่จะเกิดขึ้นซึ่งถูกส่งไปยัง mempool แต่ยังไม่ได้มุ่งมั่นในห่วงโซ่ ข้อมูลเกี่ยวกับธุรกรรมดังกล่าวมีอย่างกว้างๆ ที่มีอยู่ในเครือข่าย นักขุด validators และผู้เข้าร่วมเครือข่ายทั่วไปสามารถทำได้ จึงใช้ประโยชน์จากความรู้นี้และสร้างธุรกรรมที่ต้องพึ่งพา นอกจากนี้ นักขุดและ validators อาจมีอิทธิพลต่อลำดับของธุรกรรมที่พวกเขากระทำ ตนเองและใช้ประโยชน์จากสิ่งนี้ให้เป็นประโยชน์ ปัญหาของอิทธิพลที่ไม่เหมาะสมของผู้นำในการสั่งซื้อธุรกรรมอย่างเป็นเอกฉันท์ โปรโตคอลเป็นที่รู้จักในวรรณคดีมาตั้งแต่ปี 1990 [71, 190] แต่ไม่น่าพอใจ แนวทางแก้ไขได้รับการตระหนักในทางปฏิบัติแล้ว [97] เหตุผลหลักก็คือ แนวทางแก้ไขที่เสนอมา—อย่างน้อยก็จนกระทั่งเมื่อเร็วๆ นี้—ไม่สามารถบูรณาการเข้ากับสาธารณะได้ทันที blockchains เนื่องจากพวกเขาอาศัยเนื้อหาของธุรกรรมที่ยังคงเป็นความลับจนกระทั่งหลังจากนั้น การสั่งซื้อของพวกเขาได้รับการพิจารณาแล้ว ภาพรวมบริการการจัดลำดับที่ยุติธรรม (FSS): DONs จะจัดเตรียมเครื่องมือในการกระจายอำนาจการสั่งซื้อธุรกรรมและนำไปใช้ตามนโยบายที่ระบุโดยผู้พึ่งพา ผู้สร้างสัญญา ควรจะเป็นผู้ที่ยุติธรรมและไม่เอาเปรียบผู้แสดงที่ต้องการ จัดการลำดับธุรกรรม โดยรวมแล้ว เครื่องมือเหล่านี้ประกอบขึ้นเป็น FSS FSS มีองค์ประกอบสามประการ ประการแรกคือการติดตามธุรกรรม ใน FSS oracle โหนดใน O ทั้งตรวจสอบ mempool ของ MAINCHAIN และอนุญาต (หากต้องการ) การส่งธุรกรรมแบบลูกโซ่ผ่านช่องทางพิเศษ ประการที่สองคือการเรียงลำดับของการทำธุรกรรม โหนดใน O สั่งซื้อธุรกรรมสำหรับสัญญาที่พึ่งพา ตามนโยบายที่กำหนดไว้สำหรับสัญญานั้น ประการที่สามคือการผ่านรายการธุรกรรม หลังจากสั่งธุรกรรมแล้ว โหนดใน O จะร่วมกันส่งธุรกรรมไปที่ ห่วงโซ่หลัก ประโยชน์ที่เป็นไปได้ของ FSS ได้แก่: • ความเป็นธรรมในการสั่งซื้อ: FSS มีเครื่องมือที่ช่วยให้นักพัฒนามั่นใจได้ว่าธุรกรรมดังกล่าว ข้อมูลในสัญญาใดสัญญาหนึ่งได้รับคำสั่งในลักษณะที่ไม่ก่อให้เกิดความเป็นธรรม ข้อได้เปรียบสำหรับผู้ใช้ที่มีทรัพยากรเพียงพอและ/หรือเชี่ยวชาญทางเทคนิค นโยบายการสั่งซื้อ สามารถระบุเพื่อการนี้ได้ • การลดหรือกำจัดการรั่วไหลของข้อมูล: FSS สามารถลดหรือลดหรือขจัดการรั่วไหลของข้อมูลได้โดยทำให้แน่ใจว่าผู้เข้าร่วมเครือข่ายไม่สามารถใช้ประโยชน์จากความรู้เกี่ยวกับธุรกรรมที่กำลังจะเกิดขึ้นได้ กำจัดการโจมตีเช่นการวิ่งหน้าซึ่งอิงตามข้อมูลที่มีอยู่ใน เครือข่ายก่อนการทำธุรกรรมเกิดขึ้น ป้องกันการแสวงประโยชน์ดังกล่าว การรั่วไหลทำให้มั่นใจได้ว่าการทำธุรกรรมของฝ่ายตรงข้ามซึ่งขึ้นอยู่กับต้นฉบับที่ค้างอยู่ ธุรกรรมไม่สามารถเข้าสู่บัญชีแยกประเภทได้ก่อนที่จะมีการทำธุรกรรมดั้งเดิม• ลดต้นทุนการทำธุรกรรม: โดยขจัดความจำเป็นของผู้เล่นในเรื่องความเร็วในการส่ง การทำธุรกรรมของพวกเขาไปที่ smart contract FSS สามารถลดต้นทุนการประมวลผลธุรกรรมได้อย่างมาก • การจัดลำดับความสำคัญ: FSS สามารถจัดลำดับความสำคัญพิเศษให้กับธุรกรรมที่สำคัญได้โดยอัตโนมัติ การสั่งซื้อ ตัวอย่างเช่น เพื่อป้องกันการโจมตีแบบแนวหน้าต่อ oracle รายงาน เช่น [79] FSS สามารถแทรกรายงาน oracle ลงในสตรีมของธุรกรรม ย้อนหลัง เป้าหมายโดยรวมของ FSS ใน DONs คือการมอบอำนาจให้ผู้สร้าง DeFi ตระหนักถึงความยุติธรรม ระบบการเงิน นั่นคือระบบที่ไม่เอื้อประโยชน์ต่อผู้ใช้รายใดรายหนึ่ง (หรือนักขุด) เหนือผู้อื่นบนพื้นฐานของความเร็ว ความรู้ภายใน หรือความสามารถในการปฏิบัติงานด้านเทคนิค การจัดการ แม้ว่าแนวคิดทั่วไปเกี่ยวกับความยุติธรรมที่คมชัดจะเข้าใจยากและมีความเป็นธรรมที่สมบูรณ์แบบ ความรู้สึกที่สมเหตุสมผลใด ๆ นั้นไม่สามารถบรรลุผลได้ FSS มุ่งหวังที่จะมอบพลังอันทรงพลังให้กับนักพัฒนา ชุดเครื่องมือเพื่อให้สามารถบังคับใช้นโยบายที่ช่วยให้บรรลุเป้าหมายการออกแบบสำหรับ DeFi เราทราบว่าเป้าหมายหลักของ FSS คือการให้บริการจัดลำดับอย่างยุติธรรม MAINCHAIN ที่ DON กำหนดเป้าหมาย เป็นข้อกำหนดด้านความเป็นธรรมแบบเดียวกับที่ FSS การรับประกันยังเหมาะสมกับโปรโตคอล (กระจายอำนาจ) ที่ใช้งานอยู่ด้วย DON ปาร์ตี้ ดังนั้น FSS จึงสามารถมองได้กว้างมากขึ้นว่าเป็นบริการที่จัดทำโดยเซ็ตย่อย ของ DON โหนดเพื่อจัดลำดับอย่างยุติธรรม ไม่เพียงแต่ธุรกรรมที่ส่งโดยผู้ใช้ MAINCHAIN แต่ยังรวมถึงธุรกรรม (เช่น ข้อความ) ที่แชร์ระหว่างโหนด DON อื่นๆ ด้วย ในส่วนนี้ เราจะมุ่งเน้นไปที่เป้าหมายของการเรียงลำดับธุรกรรม MAINCHAIN เป็นหลัก การจัดส่วน: ในส่วนที่ 5.1 เราอธิบายแอปพลิเคชันระดับสูงสองแอปพลิเคชันที่กระตุ้นการออกแบบ FSS: การป้องกันการทำงานส่วนหน้าของรายงาน oracle และการป้องกัน การดำเนินการธุรกรรมของผู้ใช้ล่วงหน้า จากนั้นเราจะให้รายละเอียดเพิ่มเติมเกี่ยวกับการออกแบบ FSS ในข้อ 5.2 ส่วนที่ 5.3 อธิบายตัวอย่างการรับประกันและวิธีการสั่งซื้อที่เป็นธรรม เพื่อให้บรรลุเป้าหมายเหล่านั้น สุดท้ายนี้ ส่วนที่ 5.4 และส่วนที่ 5.5 จะหารือเกี่ยวกับภัยคุกคามระดับเครือข่าย นโยบายดังกล่าวและวิธีการแก้ไขปัญหาดังกล่าว ตามลำดับสำหรับน้ำท่วมในเครือข่ายและซีบิล การโจมตี 5.1 ปัญหาการวิ่งหน้า เพื่ออธิบายเป้าหมายและการออกแบบของ FSS เราจะอธิบายรูปแบบทั่วไปสองรูปแบบของการวิ่งหน้า การโจมตีและข้อจำกัดของโซลูชั่นที่มีอยู่ การวิ่งหน้าเป็นแบบอย่างของชนชั้น ของการโจมตีตามลำดับธุรกรรม: มีการโจมตีที่เกี่ยวข้องจำนวนหนึ่ง เช่น การถอยกลับและการประกบ (การวิ่งหน้าบวกการวิ่งถอยหลัง) [237] ที่เราไม่ครอบคลุม ที่นี่ แต่ FSS ก็ช่วยแก้ไขได้เช่นกัน 5.1.1 ออราเคิล ฟร้อนรันนิ่ง ในบทบาทดั้งเดิมในการให้ข้อมูล off-chain แก่แอปพลิเคชัน blockchain oracles กลายเป็นเป้าหมายธรรมชาติสำหรับการโจมตีแนวหน้าพิจารณารูปแบบการออกแบบทั่วไปของการใช้ oracle เพื่อจัดหาฟีดราคาต่างๆ ไปยังการแลกเปลี่ยนออนไลน์: เป็นระยะๆ (พูดทุกชั่วโมง) oracle รวบรวมข้อมูลราคาสำหรับ สินทรัพย์ที่แตกต่างกันและส่งสิ่งเหล่านี้ไปยังสัญญาแลกเปลี่ยน ธุรกรรมข้อมูลราคาเหล่านี้ นำเสนอโอกาสในการเก็งกำไรที่ชัดเจน: ตัวอย่างเช่น หากรายการรายงาน oracle ใหม่ล่าสุด ราคาที่สูงกว่ามากสำหรับสินทรัพย์บางอย่าง ฝ่ายตรงข้ามสามารถรันรายงาน oracle ล่วงหน้าได้ ซื้อสินทรัพย์และขายต่อทันทีเมื่อรายงานของ oracle ได้รับการประมวลผล การเร่งความเร็วและราคาย้อนหลัง: วิธีแก้ปัญหาทั่วไปสำหรับปัญหา oracle frontrunning คือการให้ความสำคัญกับรายงาน oracle เป็นพิเศษเหนือธุรกรรมอื่นๆ สำหรับ ตัวอย่างเช่น oracle สามารถส่งรายงานโดยมีค่าธรรมเนียมสูงเพื่อสนับสนุนให้นักขุดดำเนินการ พวกเขาก่อน แต่สิ่งนี้จะไม่ป้องกันการวิ่งล่วงหน้าหากโอกาสในการเก็งกำไรสูง และไม่สามารถป้องกันการเก็งกำไรโดยนักขุดเองได้ ตลาดแลกเปลี่ยนบางแห่งจึงหันไปใช้ “speedbumps” ที่มีน้ำหนักมากขึ้น เช่น การเข้าคิวธุรกรรมของผู้ใช้สำหรับบล็อกจำนวนหนึ่งก่อนที่จะประมวลผล หรือปรับราคาย้อนหลังเมื่อมีรายงาน oracle ใหม่มาถึง ข้อเสียของโซลูชันเหล่านี้คือเพิ่มความซับซ้อนให้กับการดำเนินการแลกเปลี่ยน เพิ่มข้อกำหนดในการจัดเก็บและทำให้ต้นทุนการทำธุรกรรม และขัดขวางประสบการณ์ผู้ใช้เนื่องจากการแลกเปลี่ยนสินทรัพย์จะได้รับการยืนยันหลังจากช่วงระยะเวลาที่สำคัญเท่านั้น ขี่หลัง: ก่อนที่จะก้าวไปสู่ FSS เราจะพูดถึงเรื่องการแบกหลัง ซึ่งค่อนข้างง่ายและ วิธีแก้ปัญหาที่หรูหราสำหรับ oracle ปัญหาการวิ่งหน้า มันใช้ไม่ได้กับที่อยู่ อย่างไรก็ตาม ในสถานการณ์อื่นๆ กล่าวโดยสรุป แทนที่จะส่งรายงานไปยังสัญญาออนไลน์เป็นระยะ oracles เผยแพร่รายงานที่ลงนามซึ่งผู้ใช้ผนวกเข้ากับธุรกรรมของตนเมื่อซื้อหรือขาย สินทรัพย์ออนไลน์ การแลกเปลี่ยนจะตรวจสอบว่ารายงานนั้นถูกต้องและใหม่หรือไม่ (เช่น oracle สามารถลงนามช่วงของบล็อกที่รายงานถูกต้อง) และแยก ฟีดราคาที่เกี่ยวข้องจากนั้น วิธีการง่ายๆ นี้มีข้อดีมากกว่า "การเร่งความเร็ว" ข้างต้นหลายประการ แนวทาง: (1) สัญญาแลกเปลี่ยนไม่จำเป็นต้องรักษาสถานะของฟีดราคาซึ่งควร ส่งผลให้ต้นทุนการทำธุรกรรมลดลง (2) เนื่องจากรายงาน oracle ถูกโพสต์แบบต่อเนื่องตามความจำเป็น oracles จึงสามารถสร้างการอัปเดตได้บ่อยมากขึ้น (เช่น ทุกนาที) ด้วยเหตุนี้ ลดโอกาสในการเก็งกำไรจากการดำเนินรายงาน9; (3) การทำธุรกรรมสามารถทำได้ ได้รับการตรวจสอบทันที เนื่องจากมีฟีดราคาใหม่อยู่เสมอ วิธีการนี้ยังไม่สมบูรณ์แบบ ขั้นแรก วิธีแก้ปัญหาการแบกหลังนี้ทำให้ ความรับผิดชอบของผู้ใช้การแลกเปลี่ยนเพื่อดึงรายงาน oracle ที่เป็นปัจจุบันและแนบไปกับรายงานของพวกเขา การทำธุรกรรม ประการที่สอง แม้ว่าการออมเงินจะช่วยลดโอกาสในการเก็งกำไร แต่ก็ไม่สามารถทำได้ ป้องกันอย่างเต็มที่โดยไม่กระทบต่อความมีชีวิตชีวาของสัญญาออนไลน์ จริงๆ แล้ว ถ้าเป็น รายงาน oracle ใช้ได้จนถึงบางหมายเลขบล็อก n จากนั้นธุรกรรมที่ส่งไปยังบล็อก n + 1 จะต้องมีรายงานที่ถูกต้องใหม่ เนื่องจากความล่าช้าในการขยายพันธุ์โดยธรรมชาติ รายงานจาก oracles ถึงผู้ใช้ รายงานใหม่ที่ถูกต้องสำหรับบล็อก n + 1 จะมี 9การหากำไรจะคุ้มค่าก็ต่อเมื่อความแตกต่างที่สามารถหาประโยชน์ได้ในราคาสินทรัพย์เกินกว่าราคาภายนอก ค่าธรรมเนียมที่จำเป็นในการซื้อและขายสินทรัพย์ เช่น ค่าธรรมเนียมที่นักขุดเก็บและการแลกเปลี่ยนเพื่อเผยแพร่ในช่วงระยะเวลาหนึ่งก่อนบล็อก n + 1 จะถูกขุด พูดที่บล็อก n −k ดังนั้น สร้างลำดับของ k บล็อกที่มีโอกาสเก็งกำไรระยะสั้น เรา ตอนนี้อธิบายว่า FSS หลีกเลี่ยงข้อจำกัดเหล่านี้ได้อย่างไร การจัดลำดับความสำคัญของรายงาน oracle ด้วย FSS: FSS สามารถจัดการกับ oracle front-running ได้ ปัญหาโดยการสร้างโซลูชัน piggybacking ข้างต้น แต่ผลักดันเพิ่มเติม งานเสริมธุรกรรมด้วย oracle รายงานไปยัง Decentralized Oracle Network ในระดับสูง โหนด oracle จะรวบรวมธุรกรรมที่กำหนดไว้สำหรับการแลกเปลี่ยนแบบออนไลน์ ตกลงฟีดราคาแบบเรียลไทม์ และโพสต์ฟีดราคาพร้อมกับธุรกรรมที่รวบรวมไปยังสัญญาลูกโซ่หลัก ตามแนวคิดแล้ว เราสามารถมองแนวทางนี้ว่าเป็น “การรวมกลุ่มธุรกรรมที่เสริมข้อมูล” โดยที่ oracle ช่วยให้มั่นใจได้ว่าข้อมูลล่าสุด ฟีดราคาจะถูกเพิ่มในธุรกรรมเสมอ โซลูชัน FSS สามารถนำไปใช้อย่างโปร่งใสกับผู้ใช้ของการแลกเปลี่ยนและด้วย การเปลี่ยนแปลงตรรกะของสัญญาเพียงเล็กน้อย ตามที่เราอธิบายรายละเอียดเพิ่มเติมในส่วน 5.2 มั่นใจ รายงาน oracle ใหม่จะมีลำดับความสำคัญเหนือธุรกรรมของผู้ใช้เสมอเป็นเพียงตัวอย่างหนึ่งเท่านั้น ของนโยบายการสั่งซื้อที่ FSS สามารถนำไปใช้และบังคับใช้ได้ นโยบายของ FSS เพื่อความมั่นใจในการสั่งซื้อ ความเป็นธรรมมีอธิบายไว้โดยทั่วไปในหัวข้อ 5.3 5.1.2 ธุรกรรมผู้ใช้ที่ดำเนินการอยู่แนวหน้า ตอนนี้เราหันไปใช้การวิ่งหน้าในการใช้งานทั่วไปซึ่งมีวิธีการป้องกันข้างต้น ไม่ทำงาน ปัญหาสามารถจับได้กว้างๆ ผ่านสถานการณ์ต่อไปนี้: ฝ่ายตรงข้ามเห็นธุรกรรมของผู้ใช้ tx1 ที่ส่งไปยังเครือข่าย P2P และแทรกซึมเข้าไป ธุรกรรมฝ่ายตรงข้ามของตัวเอง tx2 เพื่อให้ tx2 ได้รับการประมวลผลก่อน tx1 (เช่น โดยการจ่ายเงิน ค่าธรรมเนียมการทำธุรกรรมที่สูงขึ้น) ตัวอย่างเช่น การวิ่งหน้าแบบนี้เป็นเรื่องปกติในหมู่ บอทที่ใช้ประโยชน์จากโอกาสในการเก็งกำไรในระบบ DeFi [90] และส่งผลกระทบต่อผู้ใช้ของ แอปพลิเคชันกระจายอำนาจต่างๆ [101] การสร้างความเป็นธรรมในการทำธุรกรรม ประมวลผลบน blockchain แก้ไขปัญหานี้ โดยพื้นฐานแล้วบางครั้งการดูรายละเอียดของ tx1 ก็ไม่จำเป็นด้วยซ้ำ ความรู้เกี่ยวกับการดำรงอยู่ของมันอาจทำให้ฝ่ายตรงข้ามสามารถเรียกใช้ tx1 ผ่านทางมันได้ เป็นเจ้าของ tx2 และฉ้อโกงผู้ใช้บริสุทธิ์ที่สร้าง tx1 ตัวอย่างเช่น ผู้ใช้อาจ เป็นที่รู้กันว่ามีการซื้อขายสินทรัพย์เฉพาะในช่วงเวลาปกติ การป้องกันการโจมตีดังกล่าวจำเป็นต้องมี การบรรเทาผลกระทบที่หลีกเลี่ยงการรั่วไหลของข้อมูลเมตาเช่นกัน [62] วิธีแก้ไขปัญหาบางอย่างสำหรับปัญหานี้ มีอยู่จริง แต่ทำให้เกิดความล่าช้าและข้อกังวลด้านการใช้งาน จากการสั่งซื้อเครือข่ายไปจนถึงการสั่งซื้อขั้นสุดท้ายด้วย FSS: โอกาสในการวิ่งแนวหน้า เกิดขึ้นเนื่องจากระบบที่มีอยู่ไม่มีกลไกใดที่จะรับประกันได้ว่าจะมีลำดับใด ธุรกรรมที่ปรากฏบนลูกโซ่จะเคารพลำดับของเหตุการณ์และการไหลของข้อมูล ภายนอกเครือข่าย สิ่งนี้แสดงถึงปัญหาที่เกิดขึ้นจากข้อบกพร่องในการใช้งานแอปพลิเคชัน (เช่น แพลตฟอร์มการซื้อขาย) บน blockchain เป็นการดีที่จะมีใครคนหนึ่ง ตรวจสอบให้แน่ใจว่าการทำธุรกรรมเกิดขึ้นบน blockchain ในลำดับเดียวกันกับที่เป็นอยู่ สร้างและส่งไปยังเครือข่าย P2P ของ blockchain แต่เนื่องจากเครือข่าย blockchain

มีการกระจายออกไป ไม่สามารถยึดคำสั่งดังกล่าวได้ FSS จึงแนะนำกลไก เพื่อป้องกันการละเมิดความเป็นธรรมซึ่งเกิดขึ้นเพียงเพราะการแจกจ่ายเท่านั้น ลักษณะของเครือข่าย blockchain 5.2 รายละเอียด FSS รูปที่ 12: Mempool สำหรับงานสั่งซื้อที่มีเส้นทางการทำธุรกรรมที่แตกต่างกันสองเส้นทาง: โดยตรงและ อิง mempool รูปที่ 12 แสดงแผนผังทั่วไปของ FSS เพื่อให้มั่นใจถึงความเป็นธรรม DON การให้ FSS จะต้องรบกวนการทำธุรกรรมในขณะที่เข้าสู่ MAINCHAIN การปรับเปลี่ยนไคลเอนต์ เป็น smart contracts บน MAINCHAIN ​​หรือทั้งสองอย่างอาจจำเป็น ในระดับสูง การประมวลผลธุรกรรมโดย FSS สามารถแบ่งออกเป็นสามส่วน ขั้นตอนที่อธิบายไว้ด้านล่าง: (1) การติดตามธุรกรรม; (2) ลำดับการทำธุรกรรม และ (3) การผ่านรายการธุรกรรม ขึ้นอยู่กับวิธีการสั่งซื้อที่ใช้สำหรับการจัดลำดับธุรกรรม จำเป็นต้องมีขั้นตอนโปรโตคอลเพิ่มเติม ดังที่อธิบายไว้ในส่วนถัดไป 5.2.1 การประมวลผลธุรกรรม การตรวจสอบธุรกรรม: เรามองเห็นแนวทางที่แตกต่างกันสองแนวทางเพื่อให้ FSS ติดตาม ธุรกรรมของผู้ใช้ที่กำหนดไว้สำหรับ smart contract เฉพาะทางโดยตรงและแบบ mempool: • โดยตรง: แนวทางโดยตรงเป็นแนวคิดที่ง่ายที่สุด แต่ต้องมีการเปลี่ยนแปลง ลูกค้าผู้ใช้เพื่อให้ธุรกรรมถูกส่งโดยตรงไปยัง Decentralized Oracleโหนดเครือข่าย แทนที่จะเป็นโหนดของห่วงโซ่หลัก DON รวบรวม ธุรกรรมของผู้ใช้ที่กำหนดให้กับ smart contract SC เฉพาะเจาะจงและสั่งซื้อตาม เกี่ยวกับนโยบายการสั่งซื้อบางอย่าง จากนั้น DON จะส่งธุรกรรมที่สั่งซื้อไปที่ smart contract บนสายหลัก กลไกการสั่งซื้อบางอย่างยังต้องการวิธีการโดยตรง เนื่องจากผู้ใช้ที่สร้างธุรกรรมจะต้องเข้ารหัสลับ ป้องกันก่อนที่จะส่งไปยัง FSS • แบบ Mempool: เพื่ออำนวยความสะดวกในการรวม FSS กับไคลเอ็นต์แบบเดิม DON สามารถใช้ Mempool Services (MS) เพื่อตรวจสอบ mempool ของ chain หลักและรวบรวมได้ การทำธุรกรรม การส่งสัญญาณโดยตรงน่าจะเป็นการดำเนินการที่ต้องการสำหรับสัญญาหลายฉบับ และเราเชื่อว่าควรจะใช้ได้จริงในหลายกรณี เราพูดคุยกันสั้นๆ ว่า DApps ที่มีอยู่สามารถปรับเปลี่ยนเพื่อรองรับการสนับสนุนให้น้อยที่สุดได้อย่างไร การส่งผ่านโดยตรงในขณะที่ยังคงรักษาประสบการณ์ผู้ใช้ที่ดี เราอธิบายแนวทาง ใช้ Ethereum และ MetaMask [6] เนื่องจากเป็นตัวเลือกยอดนิยมในปัจจุบัน แต่ เทคนิคดังกล่าวควรขยายไปยังโซ่และกระเป๋าสตางค์อื่นๆ Ethereum ล่าสุด ข้อเสนอการปรับปรุง “EIP-3085: กระเป๋าเงินเพิ่ม Ethereum วิธี chain RPC” [100], จะทำให้ง่ายต่อการกำหนดเป้าหมาย Ethereum chain แบบกำหนดเอง (โดยใช้ CHAIN ID ที่แตกต่างจากนี้ ของ MAINCHAIN เพื่อป้องกันการโจมตีซ้ำ) จาก MetaMask และกระเป๋าเงินที่ใช้เบราว์เซอร์อื่น ๆ หลังจากดำเนินการตามข้อเสนอนี้แล้ว DApp ที่ต้องการใช้ DON จะเพิ่มการเรียกเมธอดเดียวไปที่ส่วนหน้าเพื่อให้สามารถส่งได้โดยตรง การทำธุรกรรมกับ DON ใด ๆ ที่เปิดเผย API ที่เข้ากันได้กับ Ethereum ในระหว่างนี้ “EIP-712: Ethereum พิมพ์ข้อมูลที่มีโครงสร้าง hashing และลงนาม” [49] ให้เล็กน้อย ทางเลือกที่เกี่ยวข้องมากกว่า แต่มีการใช้งานกันอย่างแพร่หลายแล้ว ซึ่งผู้ใช้ DApp สามารถใช้ได้ MetaMask เพื่อลงนามข้อมูลที่มีโครงสร้างซึ่งระบุธุรกรรม DON DApp สามารถส่งได้ ข้อมูลที่มีโครงสร้างลงนามนี้ไปยัง DON สุดท้ายนี้ เราทราบว่าแนวทางแบบผสมผสานก็เป็นไปได้เช่นกัน เช่น มรดก ลูกค้าสามารถส่งธุรกรรมไปยัง mempool ของเชนหลักต่อไปได้ แต่มีความสำคัญ ธุรกรรม (เช่น รายงาน oracle) จะถูกส่งไปยังโหนด DON โดยตรง (โดยเฉพาะ ชุดของโหนดที่ให้รายงาน oracle เช่น การอัปเดตฟีดราคาและชุดของโหนด การให้ FSS อาจทับซ้อนกันหรือเหมือนกัน) ลำดับการทำธุรกรรม: วัตถุประสงค์หลักของ FSS คือการรับประกันว่าธุรกรรมของผู้ใช้จะได้รับการสั่งซื้อตามนโยบายที่กำหนดไว้ล่วงหน้า ลักษณะของนโยบายนี้จะ ขึ้นอยู่กับความต้องการของแอปพลิเคชันและประเภทของการสั่งทำธุรกรรมที่ไม่เป็นธรรมนั่นเอง มีวัตถุประสงค์เพื่อป้องกัน เนื่องจาก FSS บน DON สามารถประมวลผลข้อมูลและรักษาสถานะท้องถิ่นได้ พวกเขาอาจกำหนดนโยบายการจัดลำดับตามอำเภอใจตามข้อมูลที่เป็นอยู่ มีจำหน่ายที่ oracles นโยบายการสั่งซื้อเฉพาะและการนำไปปฏิบัติจะกล่าวถึงต่อไปในส่วนที่ 5.3การโพสต์ธุรกรรม: หลังจากรวบรวมและสั่งซื้อธุรกรรมของผู้ใช้ ซึ่งได้รับโดยตรงจากผู้ใช้หรือรวบรวมจาก mempool แล้ว DON จะส่งธุรกรรมเหล่านี้ไปยังเชนหลัก ด้วยเหตุนี้ การโต้ตอบของ DON กับสายโซ่หลักจึงยังคงอยู่ ขึ้นอยู่กับการสั่งซื้อธุรกรรม (อาจไม่ยุติธรรม) ซึ่งควบคุมโดยผู้ขุดของเครือข่ายหลัก เพื่อควบคุมประโยชน์ของการสั่งซื้อธุรกรรมแบบกระจายอำนาจ เป้าหมายที่ชาญฉลาด สัญญา SC จึงต้องได้รับการออกแบบเพื่อปฏิบัติต่อ DON ในฐานะพลเมือง "ชั้นหนึ่ง" เรา แยกแยะสองแนวทาง: • DON-สัญญาเท่านั้น: ตัวเลือกการออกแบบที่ง่ายที่สุดคือการมีห่วงโซ่หลักที่ชาญฉลาด สัญญา SC ยอมรับเฉพาะธุรกรรมที่ประมวลผลโดย DON นี้ ตรวจสอบให้แน่ใจว่า smart contract ประมวลผลธุรกรรมตามลำดับที่เสนอโดย DON แต่โดยพฤตินัยจำกัด smart contract ให้ดำเนินการในระบบที่มีคณะกรรมการ (เช่น ขณะนี้คณะกรรมการ DON มีอำนาจอย่างต่อเนื่องในการพิจารณา การสั่งซื้อและการรวมธุรกรรม) • สัญญาแบบสองชั้น: การออกแบบที่ต้องการและละเอียดยิ่งขึ้นนั้นมีห่วงโซ่หลักที่ชาญฉลาด สัญญา SC ยอมรับธุรกรรมที่มีต้นกำเนิดทั้งจาก DON และจากมรดก ผู้ใช้10 แต่วาง "การเร่งความเร็ว" แบบดั้งเดิมกับธุรกรรมที่ไม่ได้ประมวลผลโดย DON ตัวอย่างเช่น ธุรกรรมจาก DON อาจถูกประมวลผล ทันที ในขณะที่ธุรกรรมแบบเดิมได้รับการ "บัฟเฟอร์" โดย smart contract สำหรับ ระยะเวลาที่แน่นอน กลไกมาตรฐานอื่น ๆ ในการป้องกันการวิ่งหน้า เช่นแผนการเปิดเผยคอมมิตหรือ VDF [53] สามารถนำไปใช้กับระบบเดิมได้ การทำธุรกรรม เพื่อให้แน่ใจว่าธุรกรรมที่สั่งซื้อ DON จะได้รับการประมวลผล คำสั่งที่ตกลงกัน โดยไม่มอบอำนาจที่ไม่พึงประสงค์แก่ DON ในการเซ็นเซอร์ การทำธุรกรรม เนื่องจากการกำหนดลำดับธุรกรรมโดย FSS กำหนดให้ธุรกรรมต้องถูกรวมแบบ "ออฟเชน" โซลูชันนี้จึงถูกรวมเข้ากับเทคนิคการรวมกลุ่มอื่นๆ โดยธรรมชาติซึ่งมีจุดมุ่งหมายเพื่อลดต้นทุนการประมวลผลบนเชน เช่น หลังจากรวบรวมและ การสั่งซื้อธุรกรรม DON อาจส่งธุรกรรมเหล่านี้ไปยังเชนหลักเป็น “ธุรกรรมแบบแบตช์” เดียว (เช่น rollup) ซึ่งจะช่วยลดธุรกรรมรวม ค่าธรรมเนียม การบังคับใช้คำสั่งธุรกรรม: ไม่ว่าจะอยู่ในการออกแบบ DON เท่านั้นหรือแบบสองคลาส เชนหลัก smart contract SC และ DON จะต้องได้รับการออกแบบร่วมกันเพื่อรับประกันว่าการสั่งซื้อธุรกรรมของ DON จะได้รับการสนับสนุน เรายังมองเห็นความแตกต่างอีกด้วย ตัวเลือกการออกแบบ: • หมายเลขลำดับ: DON สามารถต่อท้ายหมายเลขลำดับในแต่ละธุรกรรม และส่งธุรกรรมเหล่านี้ไปยัง mempool ของเชนหลัก หลัก 10หากการตรวจสอบธุรกรรมของ DON ขึ้นอยู่กับ mempool ธุรกรรมดั้งเดิมจะต้องแยกความแตกต่างจากธุรกรรม DON เพื่อไม่ให้ถูกรวบรวมโดย DON เช่น ผ่านแท็กพิเศษ ฝังอยู่ในธุรกรรมหรือโดยระบุราคาก๊าซเฉพาะเช่น DON ธุรกรรมมีแก๊ส ราคาต่ำกว่าเกณฑ์ที่กำหนดchain smart contract SC ละเว้นธุรกรรมที่มาถึง "ไม่ต่อเนื่อง" เรา โปรดทราบว่าในการตั้งค่านี้ นักขุดสายหลักสามารถตัดสินใจที่จะเพิกเฉยต่อ DON การสั่งซื้อธุรกรรมจึงทำให้ธุรกรรมล้มเหลว เป็นไปได้โดยการรักษาสถานะ (แพง) เพื่อให้ SC เพื่อบังคับใช้การสั่งซื้อธุรกรรมที่ถูกต้องบ้าง คล้ายคลึงกับวิธีที่บัฟเฟอร์ TCP แพ็กเก็ตที่ไม่อยู่ในลำดับจนกระทั่งแพ็กเก็ตที่หายไป ได้รับ. • ธุรกรรม nonces: สำหรับ blockchains จำนวนมาก และโดยเฉพาะอย่างยิ่งสำหรับ Ethereum วิธีการกำหนดหมายเลขลำดับข้างต้นสามารถใช้ประโยชน์จากธุรกรรมในตัว nonces ได้ บังคับใช้ว่าสายโซ่หลัก smart contract SC ประมวลผลธุรกรรมตามลำดับ ที่นี่ โหนด DON ส่งธุรกรรมไปยังห่วงโซ่หลักผ่านบัญชี mainchain เดียว ซึ่งได้รับการป้องกันด้วยคีย์ที่ใช้ร่วมกันระหว่างโหนด DON ของบัญชี ธุรกรรม nonce ทำให้แน่ใจว่าธุรกรรมถูกขุดและประมวลผลในลำดับที่ถูกต้อง • รวมธุรกรรม: DON สามารถรวมธุรกรรมหลายรายการไว้ใน rollup (หรือเป็นกลุ่มที่คล้ายกับ rollup) สายโซ่หลัก smart contract จำเป็นต้องเป็น ออกแบบมาเพื่อจัดการธุรกรรมรวมดังกล่าว • รวมธุรกรรมด้วยพร็อกซีลูกโซ่หลัก: ในที่นี้ DON รวมธุรกรรมไว้ในทำนองเดียวกันเป็น "ธุรกรรมเมตา" สำหรับลูกโซ่หลัก แต่อาศัย พร็อกซีที่กำหนดเอง smart contract เพื่อแยกธุรกรรมและส่งต่อไปยัง เป้าหมายสัญญาเอสซี. เทคนิคนี้สามารถเป็นประโยชน์สำหรับความเข้ากันได้แบบเดิม ธุรกรรมเมตาทำหน้าที่เหมือน rollups แต่แตกต่างตรงที่ประกอบด้วยรายการที่ไม่มีการบีบอัด รายการธุรกรรมที่โพสต์ครั้งเดียวในเครือข่ายหลัก การออกแบบล่าสุดมีข้อดีคือรองรับธุรกรรมของผู้ใช้ได้อย่างราบรื่น ตนเองได้รับมอบฉันทะผ่านสัญญาลูกโซ่หลักก่อนที่จะบรรลุเป้าหมายของ DON สัญญา เอสซี ตัวอย่างเช่น พิจารณาผู้ใช้ที่ส่งธุรกรรมไปยังกระเป๋าสตางค์บางใบ สัญญาซึ่งจะส่งธุรกรรมภายในไปยัง SC การกำหนดลำดับ จำนวนธุรกรรมดังกล่าวจะยุ่งยาก เว้นแต่สัญญากระเป๋าเงินของผู้ใช้จะเป็น ออกแบบมาเป็นพิเศษเพื่อส่งต่อหมายเลขลำดับพร้อมกับทุกธุรกรรมภายในไปยัง เอสซี ในทำนองเดียวกัน ธุรกรรมภายในดังกล่าวไม่สามารถรวมเข้ากับธุรกรรมเมตาที่ส่งโดยตรงไปยัง SC ได้อย่างง่ายดาย เราหารือเกี่ยวกับการพิจารณาการออกแบบเพิ่มเติมสำหรับ ธุรกรรมที่ได้รับมอบฉันทะดังกล่าวด้านล่าง 5.2.2 การทำธุรกรรมแบบอะตอมมิกซิตี้ การสนทนาของเราจนถึงขณะนี้ได้สันนิษฐานโดยปริยายว่าธุรกรรมโต้ตอบกับสิ่งเดียว ออนไลน์ smart contract (เช่น ผู้ใช้ส่งคำขอซื้อไปยังการแลกเปลี่ยน) ยังไงก็เข้า. ระบบเช่น Ethereum ธุรกรรมเดียวสามารถประกอบด้วยธุรกรรมภายในหลายรายการ เช่น smart contract หนึ่งรายการเรียกใช้ฟังก์ชันในสัญญาอื่น ข้างล่างนี้เรา. อธิบายกลยุทธ์ระดับสูงสองกลยุทธ์สำหรับการจัดลำดับธุรกรรม "หลายสัญญา" ในขณะที่ รักษาความเป็นอะตอมมิกของธุรกรรม (เช่น ลำดับของการกระทำที่กำหนดโดย ธุรกรรมทั้งหมดจะดำเนินการตามลำดับที่ถูกต้องหรือไม่เลย)อะตอมมิกที่แข็งแกร่ง: วิธีแก้ปัญหาที่ง่ายที่สุดคือการใช้ FSS ตามที่อธิบายไว้ข้างต้น กับธุรกรรม "หลายสัญญา" ทั้งหมดโดยตรง นั่นคือผู้ใช้ส่งธุรกรรมของพวกเขา ลงในเครือข่ายและ FSS จะตรวจสอบ ลำดับ และโพสต์ธุรกรรมเหล่านี้ไปที่ ห่วงโซ่หลัก วิธีการนี้เป็นแนวทางที่ง่ายในทางเทคนิค แต่มีข้อจำกัดที่อาจเกิดขึ้นประการหนึ่ง: หากเป็นผู้ใช้ การทำธุรกรรมโต้ตอบกับสัญญาสองฉบับ SC1 และ SC2 ที่ทั้งคู่ต้องการใช้ประโยชน์จากความยุติธรรม บริการจัดลำดับ ดังนั้นนโยบายการจัดลำดับของสัญญาทั้งสองนี้จะต้องสอดคล้องกัน นั่นคือ เมื่อพิจารณาธุรกรรมที่แตกต่างกันสองรายการ tx1 และ tx2 ที่แต่ละธุรกรรมโต้ตอบด้วย ทั้ง SC1 และ SC2 จะต้องไม่ใช่กรณีที่นโยบายของ SC1 สั่ง tx1 ก่อน tx2 ในขณะที่นโยบายของ SC2 กำหนดลำดับตรงกันข้าม สำหรับสถานการณ์ส่วนใหญ่ที่น่าสนใจ เราคาดว่านโยบายการจัดลำดับที่นำมาใช้โดยสัญญาที่แตกต่างกันจะมีความสอดคล้องกัน เช่น ทั้ง SC1 และ SC2 อาจต้องการให้ทำธุรกรรมโดยเวลาที่มาถึงโดยประมาณใน mempool และ SC1 อาจต้องการให้ส่งรายงาน oracle บางรายการก่อนเสมอ ในฐานะที่เป็น หลัง oracle รายงานธุรกรรมไม่มีการโต้ตอบกับ SC2 นโยบายมีความสอดคล้องกัน อะตอมมิกที่อ่อนแอ: โดยทั่วไปแล้ว FSS สามารถนำไปใช้ในระดับบุคคลได้ ธุรกรรมภายใน พิจารณาธุรกรรมในรูปแบบ tx = { ˜txpre, ˜txSC, ˜txpost} ซึ่งประกอบด้วยการเริ่มต้นบางส่วน ธุรกรรม ˜txpre ซึ่งส่งผลให้เกิดธุรกรรมภายใน ˜txSC ถึง SC ซึ่งในทางกลับกัน ออกธุรกรรมภายใน ˜txpost นโยบายการจัดลำดับของเซาท์แคโรไลนาอาจกำหนดวิธีการได้ ธุรกรรมภายใน ˜txSC จะต้องได้รับคำสั่งที่เกี่ยวข้องกับธุรกรรมอื่น ๆ ที่ส่งไป ถึง SC แต่ปล่อยให้เปิดลำดับตามลำดับสำหรับ ˜txpre และ ˜txpost เมื่อพิจารณาถึงลักษณะที่แท้จริงของการประมวลผลธุรกรรมในระบบ เช่น Ethereum การพัฒนาบริการลำดับที่กำหนดเป้าหมายธุรกรรมภายในที่เฉพาะเจาะจงนั้นไม่ได้ตรงไปตรงมา ด้วยสัญญา SC ที่ออกแบบมาเป็นพิเศษ สิ่งนี้อาจเกิดขึ้นได้ดังต่อไปนี้: 1. ธุรกรรม tx ถูกส่งไปยังเครือข่ายและขุด (โดยไม่มีลำดับใด ๆ ดำเนินการโดย FSS) ˜txpre เริ่มต้นถูกดำเนินการ และเรียก ˜txSC 2. SC ไม่ดำเนินการ ˜txSC และส่งคืน 3. FSS ติดตามธุรกรรมภายในไปยัง SC จัดลำดับ และโพสต์กลับ ไปยัง SC (เช่น โดยการส่งธุรกรรม ˜txSC ไปยัง SC โดยตรง) 4. SC ประมวลผลธุรกรรม ˜txSC ที่ได้รับจาก FSS และออกธุรกรรมภายใน ˜txpost ที่เป็นผลมาจาก ˜txSC ด้วยแนวทางนี้ ธุรกรรมจะไม่ถูกดำเนินการอย่างสมบูรณ์แบบอะตอมมิก (เช่น ดั้งเดิม ธุรกรรม tx ถูกแบ่งออกเป็นธุรกรรมออนไลน์หลายรายการ) แต่เป็นการสั่งซื้อของ ธุรกรรมภายในจะถูกเก็บรักษาไว้ โซลูชันนี้มีข้อจำกัดในการออกแบบหลายประการ ตัวอย่างเช่น ˜txpre ไม่สามารถ สมมติว่า ˜txSC และ ˜txpost จะถูกดำเนินการ นอกจากนี้ SC ควรได้รับการออกแบบให้เหมาะสม ดำเนินธุรกรรม ˜txSC และ ˜txpost ในนามของผู้ใช้บางราย แม้ว่าพวกเขาจะเป็นเช่นนั้นก็ตามส่งโดย FSS ด้วยเหตุผลเหล่านี้ สารละลาย "อะตอมมิกซิตีที่แข็งแกร่ง" ที่มีเนื้อหยาบมากขึ้น ข้างต้นน่าจะดีกว่าในทางปฏิบัติ สำหรับการเคารพการขึ้นต่อกันที่ซับซ้อนมากขึ้น ซึ่งเกี่ยวข้องกับธุรกรรมหลายรายการ และ ธุรกรรมภายในของตน กำหนดการธุรกรรมของ FSS อาจมี ฟังก์ชั่นที่ซับซ้อนซึ่งคล้ายกับที่พบในตัวจัดการธุรกรรมของความสัมพันธ์ ผู้จัดการฐานข้อมูล 5.3 ลำดับธุรกรรมที่ยุติธรรม ที่นี่เราจะหารือเกี่ยวกับแนวคิดสองประการเกี่ยวกับความเป็นธรรมสำหรับการจัดลำดับธุรกรรมและการใช้งานที่เกี่ยวข้อง ซึ่ง FSS อาจตระหนักได้: ความเป็นธรรมในการสั่งซื้อตามนโยบาย กำหนดโดย FSS และการรักษาสาเหตุอย่างปลอดภัย ซึ่งต้องใช้วิธีการเข้ารหัสเพิ่มเติมใน FSS ความเป็นธรรมในการสั่งซื้อ: ความเป็นธรรมในการสั่งซื้อเป็นแนวคิดเกี่ยวกับความเป็นธรรมชั่วคราวในระเบียบการที่เป็นเอกฉันท์ ที่ได้รับการแนะนำอย่างเป็นทางการครั้งแรกโดย Kelkar และคณะ [144]. เคลการ์ และคณะ มุ่งหวังที่จะบรรลุรูปแบบของนโยบายธรรมชาติในการทำธุรกรรม สั่งซื้อตามเวลาที่ได้รับครั้งแรกโดย DON (หรือเครือข่าย P2P ในกรณีของ FSS ที่ใช้ mempool) อย่างไรก็ตาม ในระบบการกระจายอำนาจนั้นมีความแตกต่างกัน โหนดอาจเห็นธุรกรรมมาถึงในลำดับที่แตกต่างกัน การสร้างคำสั่งซื้อทั้งหมด ในการทำธุรกรรมทั้งหมดคือปัญหาที่ได้รับการแก้ไขโดยโปรโตคอลฉันทามติที่เกี่ยวข้อง เมนเชน. เคลการ์ และคณะ [144] จึงแนะนำแนวคิดที่อ่อนแอกว่าที่สามารถเป็นได้ ประสบความสำเร็จด้วยความช่วยเหลือของเครือข่ายออราเคิลแบบกระจายอำนาจที่เรียกว่า "ความเป็นธรรมแบบบล็อก" โดยจัดกลุ่มธุรกรรมที่ DON ได้รับในช่วงเวลาหนึ่งเป็น “บล็อก” และแทรกธุรกรรมทั้งหมดของบล็อกพร้อมกันและอยู่ในตำแหน่งเดียวกัน (เช่น ความสูง) ลงใน MAINCHAIN พวกมันจึงถูกเรียงลำดับเข้าด้วยกันและจะต้องสามารถเรียกใช้งานได้ โดยไม่สร้างความขัดแย้งระหว่างกัน หากพูดโดยคร่าวๆ ความเป็นระเบียบเรียบร้อยจะระบุว่าหากโหนดส่วนใหญ่เห็นธุรกรรม τ1 ก่อน τ2 แล้ว τ1 จะถูกเรียงลำดับก่อนหรือในบล็อกเดียวกันกับ τ2 โดยยัดเยียดความหยาบดังกล่าว รายละเอียดเกี่ยวกับลำดับธุรกรรม โอกาสในการโจมตีส่วนหน้าและการโจมตีที่เกี่ยวข้องกับลำดับอื่น ๆ ลดลงอย่างมาก เคลการ์ และคณะ เสนอตระกูลโปรโตคอลที่เรียกว่า Aequitas [144] ซึ่งอยู่ โมเดลการใช้งานที่แตกต่างกัน รวมถึงการตั้งค่าเครือข่ายแบบซิงโครนัส ซิงโครนัสบางส่วน และแบบอะซิงโครนัส โปรโตคอลของ Aequitas กำหนดค่าใช้จ่ายในการสื่อสารที่สำคัญโดยสัมพันธ์กับฉันทามติพื้นฐาน BFT ดังนั้นจึงไม่เหมาะสำหรับการใช้งานจริง อย่างไรก็ตาม เราเชื่อว่า Aequitas เวอร์ชันที่ใช้งานได้จริงจะเกิดขึ้นและสามารถนำมาใช้ได้ สำหรับการจัดลำดับธุรกรรมใน FSS และแอปพลิเคชันอื่นๆ มีแผนการที่เกี่ยวข้องบางประการ ได้รับการเสนอแล้วซึ่งมีรูปแบบน้อยกว่าและมีคุณสมบัติที่อ่อนแอกว่า เช่น [36, 151, 236] แต่ประสิทธิภาพในทางปฏิบัติดีกว่า แผนเหล่านี้สามารถรองรับได้ ใน FSS เช่นกัน เป็นที่น่าสังเกตว่าคำว่า "ความเป็นธรรม" ปรากฏในที่อื่นใน blockchain วรรณกรรมที่มีความหมายแตกต่าง คือ ความยุติธรรมในแง่โอกาสผู้ขุดตามสัดส่วนกับทรัพยากรที่มุ่งมั่น [106, 181] หรือสำหรับ validators ในแง่ ของโอกาสที่เท่าเทียมกัน [153] การรักษาสาเหตุอย่างปลอดภัย: แนวทางที่เป็นที่รู้จักอย่างกว้างขวางที่สุดในการป้องกันการละเมิดลำดับหน้าและการสั่งซื้ออื่นๆ ในแพลตฟอร์มแบบกระจายนั้นอาศัยการเข้ารหัส เทคนิค คุณสมบัติทั่วไปของพวกเขาคือการซ่อนข้อมูลธุรกรรมโดยรอจนกระทั่ง มีการสร้างคำสั่งซื้อที่ชั้นฉันทามติและเพื่อเปิดเผยข้อมูลการทำธุรกรรม เพื่อนำไปประมวลผลในภายหลัง สิ่งนี้จะรักษาลำดับสาเหตุระหว่างธุรกรรมที่เป็นอยู่ ดำเนินการโดย blockchain แนวคิดด้านความปลอดภัยที่เกี่ยวข้องและโปรโตคอลการเข้ารหัส ได้รับการพัฒนาอย่างมากก่อนการถือกำเนิดของ blockchains [71, 190] เงื่อนไขความปลอดภัยของ "อินพุตเชิงสาเหตุ" [190] และ "การรักษาเชิงสาเหตุที่ปลอดภัย" [71, 97] กำหนดอย่างเป็นทางการว่าจะไม่มีการรู้ข้อมูลเกี่ยวกับธุรกรรม ก่อนที่จะมีการกำหนดตำแหน่งของธุรกรรมนี้ในคำสั่งซื้อทั่วโลก ฝ่ายตรงข้ามจะต้องไม่สามารถอนุมานข้อมูลใด ๆ ได้จนกว่าจะถึงเวลานั้นในรูปแบบการเข้ารหัส ความรู้สึกที่แข็งแกร่ง เราสามารถแยกแยะเทคนิคการเข้ารหัสสี่แบบเพื่อรักษาสาเหตุได้: • Commit-reveal protocols [29, 142, 145]: แทนที่จะประกาศธุรกรรม ชัดเจนว่าจะมีการถ่ายทอดเฉพาะข้อผูกมัดด้านการเข้ารหัสในการทำธุรกรรมเท่านั้น หลังจากที่มีการสั่งซื้อธุรกรรมที่กระทำการแต่ซ่อนเร้นทั้งหมดแล้ว (ในช่วงต้น blockchain ระบบบน MAINCHAIN เอง แต่ที่นี่โดย FSS) ผู้ส่งจะต้องเปิดข้อผูกพันและเปิดเผยข้อมูลธุรกรรมภายในช่วงเวลาที่กำหนดไว้ จากนั้นเครือข่ายจะตรวจสอบว่าการเปิดเป็นไปตามข้อผูกพันก่อนหน้านี้ ที่ ต้นกำเนิดของวิธีนี้เกิดขึ้นก่อนการถือกำเนิดของ blockchains แม้ว่าจะง่ายเป็นพิเศษ แต่แนวทางดังกล่าวก็มีข้อเสียอยู่มาก และไม่ใช่เรื่องง่ายที่จะใช้ด้วยเหตุผลสองประการ ประการแรก เนื่องจากมีเพียงข้อผูกพันในระดับโปรโตคอลการสั่งซื้อ ความหมายของธุรกรรม ไม่สามารถตรวจสอบได้ในระหว่างการลงประชามติ มีบริการรับส่งไป-กลับเพิ่มเติมให้กับลูกค้า เป็นสิ่งจำเป็น อย่างไรก็ตาม ที่ร้ายแรงกว่านั้นคือชั่งน้ำหนักความเป็นไปได้ที่อาจไม่สามารถเปิดได้ เคยมาถึง ซึ่งอาจเทียบเท่ากับการโจมตีแบบปฏิเสธการให้บริการ นอกจากนี้มัน เป็นการยากที่จะตัดสินว่าการเปิดนั้นถูกต้องในการกระจายที่สอดคล้องกันหรือไม่ เนื่องจากผู้เข้าร่วมทุกคนจะต้องตกลงกันว่าการเปิดมาถึงแล้วหรือไม่ เวลา. • ยอมรับโปรโตคอลเปิดเผยพร้อมการกู้คืนล่าช้า [145]: ความท้าทายประการหนึ่งกับ แนวทางเปิดเผยการกระทำคือการที่ลูกค้าอาจกระทำธุรกรรมโดยเก็งกำไรและเปิดเผยในภายหลังเฉพาะในกรณีที่ธุรกรรมต่อมาทำให้มีกำไร ก ตัวแปรล่าสุดของแนวทางเปิดเผยความมุ่งมั่นช่วยเพิ่มความยืดหยุ่นต่อสิ่งนี้ พฤติกรรมที่ไม่เหมาะสม โดยเฉพาะอย่างยิ่ง โปรโตคอล TEX [145] แก้ไขปัญหานี้ ใช้วิธีการอันชาญฉลาดซึ่งธุรกรรมที่เข้ารหัสจะมีคีย์ถอดรหัสด้วย หาได้จากการคำนวณฟังก์ชันหน่วงเวลาที่ตรวจสอบได้ (VDF) [53, 221] ถ้าเป็นลูกค้า ไม่สามารถถอดรหัสธุรกรรมของเธอได้ทันเวลา ผู้อื่นในระบบจะถอดรหัส ในนามของเธอด้วยการไขปริศนาการเข้ารหัสที่มีระดับความยากปานกลาง• การเข้ารหัสตามเกณฑ์ [71, 190]: วิธีการนี้ใช้ประโยชน์จากสิ่งที่ DON อาจดำเนินการ การดำเนินการเข้ารหัสตามเกณฑ์ สมมติว่า FSS รักษาการเข้ารหัสแบบสาธารณะ คีย์ pkO และ oracles แบ่งปันคีย์ส่วนตัวที่สอดคล้องกันระหว่างกัน จากนั้นลูกค้าจะเข้ารหัสธุรกรรมภายใต้ pkO และส่งไปที่ FSS คำสั่ง FSS ธุรกรรมบน DON จากนั้นถอดรหัสและแทรกลงในที่สุด MAINCHAIN ในลำดับคงที่ การเข้ารหัสจึงทำให้มั่นใจได้ว่าการสั่งซื้อนั้น ไม่ได้ขึ้นอยู่กับเนื้อหาธุรกรรม แต่ข้อมูลนั้นสามารถใช้ได้เมื่อใด จำเป็น วิธีนี้เดิมเสนอโดย Reiter และ Birman [190] และต่อมาได้รับการปรับปรุงโดย Cachin และคณะ [71] โดยที่มันถูกรวมเข้ากับฉันทามติที่ได้รับอนุญาต โปรโตคอล งานล่าสุดได้สำรวจการใช้การเข้ารหัสตามเกณฑ์เป็น กลไกระดับฉันทามติสำหรับข้อความทั่วไป [33, 97] และสำหรับการคำนวณทั่วไปด้วยข้อมูลที่แชร์ [41] เมื่อเปรียบเทียบกับโปรโตคอลการเปิดเผยคอมมิต การเข้ารหัสตามเกณฑ์จะป้องกันการโจมตีแบบปฏิเสธบริการแบบธรรมดา (แม้ว่าจะต้องใช้ความระมัดระวังเนื่องจากต้นทุนการถอดรหัสในการคำนวณ) ช่วยให้ DON ดำเนินการโดยอัตโนมัติด้วยความเร็วของตัวเองและไม่ต้องดำเนินการ รอการดำเนินการของลูกค้าต่อไป ธุรกรรมอาจได้รับการตรวจสอบทันทีหลังจากถูกถอดรหัสแล้ว นอกจากนี้ ลูกค้ายังเข้ารหัสธุรกรรมทั้งหมดด้วยเครื่องเดียว คีย์สำหรับ DON และรูปแบบการสื่อสารยังคงเหมือนกับรูปแบบอื่นๆ การทำธุรกรรม การจัดการคีย์เกณฑ์อย่างปลอดภัยและด้วยการเปลี่ยนโหนด O อย่างไรก็ตาม อาจก่อให้เกิดปัญหาเพิ่มเติม • เปิดเผยความลับที่มุ่งมั่น [97]: แทนที่จะเข้ารหัสข้อมูลธุรกรรมภายใต้ คีย์ที่ถือโดย DON ลูกค้าอาจแชร์คีย์นั้นแบบลับสำหรับโหนดใน O ได้ การใช้แผนการแบ่งปันความลับแบบไฮบริดที่มีความปลอดภัยทางคอมพิวเตอร์ในการทำธุรกรรม ถูกเข้ารหัสก่อนโดยใช้การเข้ารหัสแบบสมมาตรพร้อมคีย์สุ่ม เฉพาะคีย์สมมาตรที่เกี่ยวข้องเท่านั้นที่จะถูกแชร์ และไซเฟอร์เท็กซ์จะถูกส่งไปยัง DON ไคลเอ็นต์จะต้องส่งหนึ่งคีย์ที่ใช้ร่วมกันไปยังแต่ละโหนดใน O โดยใช้ข้อความที่เข้ารหัสแยกต่างหาก ขั้นตอนโปรโตคอลที่เหลือจะเหมือนกันกับเกณฑ์ การเข้ารหัส ยกเว้นว่าข้อมูลธุรกรรมจะถูกถอดรหัสด้วยความสมมาตร อัลกอริทึมหลังจากสร้างคีย์ต่อธุรกรรมใหม่จากการแชร์ วิธีการนี้ไม่จำเป็นต้องตั้งค่าหรือการจัดการระบบการเข้ารหัสคีย์สาธารณะ เกี่ยวข้องกับ DON อย่างไรก็ตามลูกค้าจะต้องตระหนักถึงโหนดต่างๆ O และสื่อสารในบริบทที่ปลอดภัยกับแต่ละสถานที่ เพิ่มภาระให้กับลูกค้า แม้ว่าวิธีการเข้ารหัสจะมีการป้องกันข้อมูลอย่างสมบูรณ์ รั่วไหลจากการทำธุรกรรมที่ส่งไปยังเครือข่าย พวกเขาไม่ได้ปกปิดข้อมูลเมตา สำหรับ ตัวอย่างเช่น ที่อยู่ IP หรือที่อยู่ Ethereum ของผู้ส่งยังคงสามารถใช้ได้ ศัตรูที่ทำการวิ่งหน้าและการโจมตีอื่น ๆ เพิ่มความเป็นส่วนตัวต่างๆ เทคนิคที่ใช้บนเลเยอร์เครือข่าย เช่น [52, 95, 107] หรือเลเยอร์ธุรกรรม เช่น [13, 65] จำเป็นต่อการบรรลุเป้าหมายนี้ ผลกระทบของชิ้นใดชิ้นหนึ่ง ของเมทาดาทา ซึ่งก็คือสัญญาที่ธุรกรรมถูกส่งไป สามารถปกปิดได้ (บางส่วน)ผ่านการมัลติเพล็กซ์หลายสัญญาใน DON เดียวกัน การปกปิดการเข้ารหัส ของธุรกรรมต่อ se ยังไม่ได้ป้องกันการจัดลำดับความสำคัญของธุรกรรมโดยเสียหาย DON โหนดสมรู้ร่วมคิดกับผู้ส่งธุรกรรม สาเหตุที่ปลอดภัยซึ่งรับประกันโดยโปรโตคอลการเข้ารหัสช่วยเสริมการรับประกันความเป็นธรรมสำหรับนโยบายใด ๆ และเราตั้งใจที่จะสำรวจการผสมผสานระหว่างทั้งสอง วิธีการต่างๆ ในกรณีที่เป็นไปได้ หากฝ่ายตรงข้ามไม่สามารถได้รับความได้เปรียบอย่างมีนัยสำคัญจาก จากการสังเกตข้อมูลเมตา สามารถใช้โปรโตคอลการรักษาเชิงสาเหตุที่ปลอดภัยควบคู่กันได้ วิธีการสั่งซื้อที่ไร้เดียงสาเช่นกัน ตัวอย่างเช่น โหนด oracle สามารถเขียนธุรกรรมได้ ถึง L ทันทีที่ได้รับโดยไม่มีการทำซ้ำ การทำธุรกรรมก็จะเป็น เรียงลำดับตามลักษณะที่ปรากฏบน L แล้วถอดรหัสในภายหลัง นอกจากนี้เรายังวางแผนที่จะพิจารณาการใช้ TEE เพื่อช่วยบังคับใช้การสั่งซื้อที่เป็นธรรม สำหรับ ตัวอย่างเช่น Tesseract [44] อาจถูกมองว่าเป็นการบรรลุรูปแบบของการจัดลำดับเชิงสาเหตุ แต่อย่างหนึ่ง เสริมความแข็งแกร่งด้วยความสามารถของ TEE ในการประมวลผลธุรกรรมในรูปแบบที่ชัดเจนในขณะที่ การรักษาความลับของพวกเขา 5.4 ข้อควรพิจารณาเกี่ยวกับเลเยอร์เครือข่าย จนถึงขณะนี้ คำอธิบายของ FSS ของเรามุ่งเน้นไปที่ปัญหาการบังคับใช้เป็นหลัก ลำดับการทำธุรกรรมขั้นสุดท้ายตรงกับลำดับที่สังเกตได้ในเครือข่าย ต่อจากนี้ไป เราพิจารณาปัญหาด้านความเป็นธรรมที่อาจเกิดขึ้นที่เลเยอร์เครือข่ายเอง ผู้ค้าที่มีความถี่สูงในตลาดอิเล็กทรอนิกส์ทั่วไปลงทุนเป็นจำนวนมาก ทรัพยากรเพื่อรับความเร็วเครือข่ายที่เหนือกว่า [64] และเทรดเดอร์ในการแลกเปลี่ยนสกุลเงินดิจิตอลก็มีพฤติกรรมที่คล้ายกัน [90] ความเร็วเครือข่ายทำให้เกิดความได้เปรียบทั้งใน สังเกตธุรกรรมของบุคคลอื่นและในการยื่นธุรกรรมที่แข่งขันกัน วิธีการรักษาอย่างหนึ่งที่นำไปใช้ในทางปฏิบัติและแพร่หลายในหนังสือ Flash Boys [155] คือ “speed bump” เปิดตัวครั้งแรกในการแลกเปลี่ยน IEX [128] และต่อมาในการแลกเปลี่ยนอื่นๆ แลกเปลี่ยน [179] (พร้อมผลลัพธ์แบบผสม [19]) กลไกนี้ทำให้เกิดความล่าช้า (350 ไมโครวินาทีใน IEX) ในการเข้าถึงตลาด โดยมีจุดประสงค์เพื่อลดความได้เปรียบใน ความเร็ว หลักฐานเชิงประจักษ์ เช่น [128] สนับสนุนประสิทธิภาพในการลดการซื้อขายบางอย่าง ต้นทุนสำหรับนักลงทุนทั่วไป FSS สามารถใช้เพียงเพื่อสร้างความไม่สมมาตรได้ speed bump—สิ่งหนึ่งที่ทำให้ธุรกรรมขาเข้าล่าช้า Budish, Cramton และ Shim [64] โต้แย้งว่าการใช้ประโยชน์จากข้อได้เปรียบในด้านความเร็ว เป็นสิ่งที่หลีกเลี่ยงไม่ได้ในตลาดที่ต่อเนื่องกันและโต้แย้งเพื่อหาแนวทางแก้ไขเชิงโครงสร้างใน รูปแบบของตลาดที่ใช้การประมูลเป็นชุด แต่แนวทางนี้ไม่ได้ยึดถือในวงกว้าง ในแพลตฟอร์มการซื้อขายที่มีอยู่ ระบบการซื้อขายแบบทั่วไปเป็นแบบรวมศูนย์ ซึ่งโดยทั่วไปจะได้รับธุรกรรมผ่าน การเชื่อมต่อเครือข่ายเดียว ในทางตรงกันข้าม ในระบบการกระจายอำนาจ สามารถทำได้ สังเกตการแพร่กระจายของธุรกรรมจากหลายจุดได้เปรียบ ดังนั้นจึงเป็นไปได้ที่จะสังเกตพฤติกรรม เช่น น้ำท่วมเครือข่ายในเครือข่าย P2P เราตั้งใจ เพื่อสำรวจแนวทางชั้นเครือข่ายสำหรับ FSS ที่ช่วยให้นักพัฒนาระบุนโยบายได้ ห้ามพฤติกรรมเครือข่ายที่ไม่พึงประสงค์ดังกล่าว5.5 นโยบายความเป็นธรรมระดับนิติบุคคล ความเป็นธรรมในการสั่งซื้อและเหตุที่ปลอดภัยมีจุดมุ่งหมายเพื่อบังคับใช้คำสั่งในการทำธุรกรรมนั้น คำนึงถึงเวลาที่ถูกสร้างขึ้นและส่งไปยังเครือข่ายเป็นครั้งแรก ข้อจำกัดของแนวคิดเรื่องความเป็นธรรมนี้คือไม่ได้ป้องกันการโจมตีของฝ่ายตรงข้าม ได้เปรียบจากน้ำท่วมระบบที่มีธุรกรรมจำนวนมาก ซึ่งเป็นกลยุทธ์ที่สังเกตได้ ในป่าเป็นวิธีหนึ่งในการทำธุรกรรมที่มีประสิทธิภาพในการขาย token [159] และ สร้างความแออัดส่งผลให้การชำระบัญชีหนี้ที่มีหลักประกัน (CDPs) [48]. กล่าวอีกนัยหนึ่ง ความเป็นธรรมในการสั่งซื้อบังคับใช้ความเป็นธรรมในส่วนที่เกี่ยวกับธุรกรรม ไม่ใช่ผู้เล่น ดังที่แสดงในระบบ CanDID [160] คุณสามารถใช้เครื่องมือ oracle เช่น DECO ได้ หรือ Town Crier ร่วมกับคณะกรรมการโหนด (เช่น DON) เพื่อให้บรรลุ การต่อต้านซีบิลในรูปแบบต่างๆ พร้อมปกป้องความเป็นส่วนตัว ผู้ใช้สามารถลงทะเบียนข้อมูลประจำตัวได้ และแสดงหลักฐานเอกลักษณ์ของตนโดยไม่เปิดเผยตัวตน ข้อมูลประจำตัวที่ทนต่อ Sybil นำเสนอแนวทางที่เป็นไปได้ในการเพิ่มคุณค่าให้กับการสั่งซื้อธุรกรรม นโยบายในลักษณะที่จะจำกัดโอกาสในการโจมตีน้ำท่วม ตัวอย่างเช่น ก token การขายอาจอนุญาตเพียงหนึ่งธุรกรรมต่อผู้ใช้ที่ลงทะเบียน โดยที่การลงทะเบียน ต้องมีหลักฐานพิสูจน์เอกลักษณ์ประจำตัวประชาชน เช่น หมายเลขประกันสังคม แนวทางดังกล่าวไม่สามารถป้องกันความผิดพลาดได้ แต่อาจพิสูจน์ได้ว่าเป็นนโยบายที่มีประโยชน์ในการลดการโจมตีจากธุรกรรมน้ำท่วม

DON กรอบการดำเนินการธุรกรรม

(DON-TEF) DONs จะให้การสนับสนุน oracle และทรัพยากรแบบกระจายอำนาจสำหรับโซลูชันเลเยอร์ 2 ภายใน สิ่งที่เราเรียกว่า Decentralized Oracle Network Transaction-Execution Framework (DONTEF) หรือเรียกย่อๆ ว่า TEF วันนี้ ความถี่ของการอัปเดตสัญญา DeFi ถูกจำกัดโดยเวลาแฝงของสายหลัก เช่น ช่วงเวลาบล็อกเฉลี่ย 10-15 วินาทีใน Ethereum [104] รวมถึงต้นทุนของ ส่งข้อมูลจำนวนมากบนห่วงโซ่และปริมาณการประมวลผล/tx ที่จำกัด— การสร้างแรงจูงใจในการขยายขนาด เช่น การแบ่งส่วน [148, 158, 232] และการประมวลผลเลเยอร์ 2 [5, 12, 121, 141, 169, 186, 187]. แม้แต่ blockchains ที่มีเวลาการทำธุรกรรมเร็วกว่ามาก เช่น [120] ได้เสนอกลยุทธ์การปรับขนาดที่เกี่ยวข้องกับการคำนวณแบบออฟเชน [168] TEF มีไว้เพื่อทำหน้าที่เป็นทรัพยากรเลเยอร์ 2 สำหรับระบบเลเยอร์ 1 / MAINCHAIN ​​ดังกล่าว การใช้ TEF นั้น DONs สามารถรองรับการอัปเดตที่เร็วขึ้นในสัญญา MAINCHAIN ในขณะที่ การรักษาหลักประกันความไว้วางใจที่ได้รับจากเครือข่ายหลัก TEF รองรับได้ เทคนิคและกระบวนทัศน์การดำเนินการเลเยอร์ 2 ใดๆ ก็ตาม รวมถึง rollups,11 rollups ในแง่ดี, Validium ฯลฯ รวมถึงโมเดลความน่าเชื่อถือตามเกณฑ์ที่ DON โหนดดำเนินธุรกรรม TEF เป็นส่วนเสริมของ FSS และมีวัตถุประสงค์เพื่อสนับสนุน กล่าวอีกนัยหนึ่งใด ๆ แอปพลิเคชันที่ทำงานใน TEF สามารถใช้ FSS ได้ 11มักเรียกว่า “zk-rollups” ซึ่งเป็นการเรียกชื่อผิด เนื่องจากไม่จำเป็นต้องมีการพิสูจน์ความรู้เป็นศูนย์

6.1 ภาพรวมของ TEF TEF เป็นรูปแบบการออกแบบสำหรับการสร้างและการใช้งานไฮบริดที่มีประสิทธิภาพ smart contract สค. ตามแนวคิดหลักเบื้องหลังไฮบริด smart contracts TEF เกี่ยวข้องกับ การสลายตัวของ SC ออกเป็นสองส่วน: (1) สิ่งที่เราเรียกว่าสมอในบริบท TEF ทำสัญญา SCa บน MAINCHAIN และ (2) DON ตรรกะที่เราเรียกว่าปฏิบัติการ TEF เราใช้ SC ที่นี่เพื่อแสดงถึงสัญญาเชิงตรรกะที่ดำเนินการโดยการรวมกันของ SCa และดำเนินการ (ตามที่ระบุไว้ข้างต้น เราคาดว่าจะพัฒนาเครื่องมือคอมไพเลอร์เพื่อแยกไฟล์ ทำสัญญา SC เข้ากับส่วนประกอบเหล่านี้โดยอัตโนมัติ) โปรแกรมปฏิบัติการ TEF คือกลไกที่ประมวลผลธุรกรรมของผู้ใช้ใน SC มัน สามารถดำเนินการได้อย่างมีประสิทธิภาพในขณะที่มันทำงานบน DON มีหลายฟังก์ชั่น: • การนำเข้าธุรกรรม: ยกเว้นการรับหรือดึงข้อมูลธุรกรรมของผู้ใช้ มันสามารถทำได้ โดยตรง เช่น ผ่านการส่งธุรกรรมบน DON หรือผ่านทาง MAINCHAIN mempool โดยใช้ MS • การดำเนินการธุรกรรมที่รวดเร็ว: ดำเนินการธุรกรรมที่เกี่ยวข้องกับสินทรัพย์ภายใน เอสซี มันทำในเครื่อง เช่น บน DON • oracle / การเข้าถึงอแดปเตอร์ที่รวดเร็วและราคาประหยัด: exect มีสิทธิ์เข้าถึงรายงาน oracle แบบเนทีฟ และข้อมูลอแด็ปเตอร์อื่นๆ ที่นำไปสู่สินทรัพย์ที่เร็วขึ้น ถูกลง และแม่นยำยิ่งขึ้น การกำหนดราคามากกว่าการดำเนินการ MAINCHAIN ยิ่งไปกว่านั้น การเข้าถึง of-chain oracle จะลดลง ต้นทุนการดำเนินงานของ oracle ดังนั้นต้นทุนในการใช้ระบบ โดยการหลีกเลี่ยง พื้นที่เก็บข้อมูลออนไลน์ราคาแพง • การซิงค์: exect จะพุชการอัปเดตจาก DON ไปยัง MAINCHAIN ​​เป็นระยะๆ เพื่ออัปเดต SCa สัญญายึดคือส่วนหน้าของ MAINCHAIN ​​ของ SC เนื่องจากเป็นองค์ประกอบที่มีความน่าเชื่อถือสูงกว่าของ SC จึงมีวัตถุประสงค์หลายประการ: • การดูแลสินทรัพย์: เงินของผู้ใช้จะถูกฝากเข้า ถือไว้ และถอนออกจาก SCa • การตรวจสอบการซิงค์: SCa อาจตรวจสอบความถูกต้องของการอัปเดตสถานะเมื่อดำเนินการ การซิงค์ เช่น SNARK ที่แนบกับ rollups • ราวกั้น: SCa อาจมีข้อกำหนดในการป้องกันการทุจริตหรือความล้มเหลว ในข้อยกเว้น (ดูส่วนที่ 7 สำหรับรายละเอียดเพิ่มเติม) ใน TEF เงินทุนของผู้ใช้จะถูกดูแลบน MAINCHAIN ซึ่งหมายความว่า DON นั้นไม่ใช่การควบคุมดูแล ผู้ใช้อาจต้องการ ทั้งนี้ขึ้นอยู่กับตัวเลือกกลไกการซิงค์ (ดูด้านล่าง) ที่จะเชื่อถือ DON สำหรับรายงาน oracle ที่แม่นยำเท่านั้น และการซิงค์กับ MAINCHAIN อย่างทันท่วงที โมเดลความน่าเชื่อถือที่ได้นั้นคล้ายกันมากกับ DEX ที่อิงตามสมุดคำสั่งซื้อ เช่น [2] ซึ่งโดยทั่วไปในปัจจุบันประกอบด้วยส่วนประกอบ of-chain สำหรับการจับคู่คำสั่งซื้อ และส่วนประกอบ onchain สำหรับการหักบัญชีและการชำระบัญชีการใช้คำศัพท์ของระบบการชำระเงินอาจมองว่า ext เป็นองค์ประกอบ ของ SC ที่รับผิดชอบในการหักบัญชี ในขณะที่ SCa จัดการการชำระหนี้ ดูรูปที่ 13 สำหรับแผนผัง ภาพของ TEF รูปที่ 13: แผนผัง TEF ในตัวอย่างนี้ ธุรกรรมจะผ่าน mempool ของ MAINCHAIN ผ่าน MS ไปยัง DON ประโยชน์ของ TEF: TEF มีคุณประโยชน์หลักสามประการ: • ประสิทธิภาพสูง: SC สืบทอดปริมาณงานของ DON ที่สูงกว่า MAINCHAIN มาก สำหรับทั้งธุรกรรมและรายงาน oracle นอกจากนี้ exect สามารถประมวลผลธุรกรรมได้เร็วขึ้นและตอบสนองต่อรายงาน oracle ได้ทันเวลามากกว่าการใช้งานบน MAINCHAIN ​​เพียงอย่างเดียว • ค่าธรรมเนียมต่ำกว่า: กระบวนการซิงค์มีเวลาน้อยกว่าการประมวลผลธุรกรรม และสามารถส่งธุรกรรมจาก DON ไปยัง MAINCHAIN ​​เป็นกลุ่มได้ ดังนั้นค่าธรรมเนียมออนไลน์ต่อธุรกรรม (เช่น ค่าน้ำมัน) ด้วยวิธีนี้จึงต่ำกว่าสัญญาที่ทำงานบน MAINCHAIN ​​เท่านั้น • การรักษาความลับ: กลไกการรักษาความลับของ DON สามารถนำมาสู่ ทนกับ SC

ข้อจำกัดของ TEF: ข้อจำกัดประการหนึ่งของ TEF คือไม่รองรับการทำงานแบบทันที การถอนเงินเนื่องจากเกิดขึ้นบน MAINCHAIN เท่านั้น: เมื่อส่งคำขอถอนเงิน ถึง SCa ผู้ใช้อาจต้องรอ exect ดำเนินการอัปเดตสถานะซึ่งรวมถึง ธุรกรรมการถอนเงินก่อนจึงจะสามารถอนุมัติได้ เราหารือถึงการเยียวยาบางส่วน อย่างไรก็ตามในข้อ 6.2 ข้อจำกัดอีกประการหนึ่งของ TEF ก็คือ ไม่รองรับองค์ประกอบอะตอมของ DeFi สัญญาบน MAINCHAIN โดยเฉพาะความสามารถในการกำหนดเส้นทางสินทรัพย์ผ่านหลาย ๆ DeFi สัญญาในธุรกรรมเดียว อย่างไรก็ตาม TEF สามารถรองรับอะตอมมิกซิตีดังกล่าวได้ DeFi สัญญาที่ทำงานบน DON เดียวกัน นอกจากนี้เรายังหารือเกี่ยวกับวิธีแก้ไขปัญหานี้ด้วย ปัญหาในส่วนที่ 6.2 6.2 การกำหนดเส้นทางธุรกรรม ธุรกรรมสำหรับ SC สามารถส่งโดยผู้ใช้โดยตรงไปยัง DON หรือสามารถกำหนดเส้นทางผ่าน mempool ใน MAINCHAIN (ผ่าน FSS) มีประเภทธุรกรรมที่แตกต่างกันสี่ประเภท แต่ละประเภท ซึ่งต้องมีการจัดการที่แตกต่างกัน: ธุรกรรมภายในสัญญา: เนื่องจากเป็นการหลีกเลี่ยงภาวะแทรกซ้อนของการเปลี่ยนแปลงของก๊าซ TEF จึงทำให้ SC มีความยืดหยุ่นมากขึ้นในการจัดการธุรกรรมมากกว่าที่จะเป็น มีอยู่ในสัญญาเลเยอร์ 1 ตัวอย่างเช่น ในขณะที่ธุรกรรม mempool ใน Ethereum สามารถเขียนทับได้โดยธุรกรรมใหม่ที่มีราคาก๊าซสูงกว่า SC สามารถปฏิบัติต่อธุรกรรมที่ดำเนินการกับสินทรัพย์ภายใน SC ได้อย่างน่าเชื่อถือทันทีที่มองเห็นได้ ในเมมพูล ดังนั้น SC จึงไม่ต้องรอการยืนยันธุรกรรม ภายในบล็อก ส่งผลให้เวลาแฝงลดลงอย่างมาก การมอบฉันทะ: ผู้ใช้อาจต้องการส่งธุรกรรม τ ไปยัง SC ผ่านสัญญากระเป๋าเงินหรือ สัญญาอื่น ๆ บน MAINCHAIN เป็นไปได้ที่ DON จะจำลองการดำเนินการของ τ บน MAINCHAIN เพื่อตรวจสอบว่าส่งผลให้เกิดธุรกรรมที่ตามมากับ SC หรือไม่ หากเป็นเช่นนั้น τ สามารถจัดลำดับกับธุรกรรมอื่นสำหรับ SC ที่ทำ มีไม่กี่อย่าง ความเป็นไปได้สำหรับวิธีที่ DON ระบุธุรกรรมดังกล่าว: (1) DON สามารถจำลอง ธุรกรรมทั้งหมดใน mempool (แนวทางที่มีราคาแพง) (2) สัญญาบางอย่างหรือ ประเภทสัญญา เช่น กระเป๋าเงิน สามารถแสดงรายการเพื่อการตรวจสอบโดย DON; หรือ (3) ผู้ใช้สามารถ ใส่คำอธิบายประกอบธุรกรรมสำหรับการตรวจสอบ DON เรื่องต่างๆ มีความซับซ้อนมากขึ้นเมื่อธุรกรรมหนึ่งมีปฏิสัมพันธ์กับสองธุรกรรม สัญญา SC1 และ SC2 ซึ่งทั้งสองอย่างนี้ใช้บริการ Fair Sequencing และมีนโยบายการสั่งซื้อที่เข้ากันไม่ได้ ตัวอย่างเช่น DON อาจเรียงลำดับ τ ในเวลาล่าสุด ที่เข้ากันได้ทั้งสองอย่าง เงินฝาก: ธุรกรรมที่ฝากสินทรัพย์ MAINCHAIN เข้าสู่ SC จะต้องได้รับการยืนยันในบล็อกก่อนที่ SC จะสามารถถือว่ารายการนั้นถูกต้อง เมื่อตรวจพบการขุดของ ธุรกรรมที่ส่งสินทรัพย์ (เช่น Ether) เข้าสู่ SCa สามารถยืนยันได้ทันทีเงินฝาก. ตัวอย่างเช่น สามารถใช้ oracle-ราคาที่รายงานปัจจุบันใน DON กับ สินทรัพย์ การถอนเงิน: ตามที่ระบุไว้ข้างต้น ข้อจำกัดของ TEF คือ การถอนเงินไม่สามารถดำเนินการได้ทันทีเสมอไป ในแบบจำลองการดำเนินการประเภท rollup การถอน คำขอจะต้องเรียงลำดับกับธุรกรรมอื่น ๆ เช่น สะสม เพื่อความปลอดภัย ประมวลผล อย่างไรก็ตาม มีการเยียวยาบางส่วนสำหรับข้อจำกัดนี้ หาก DON สามารถคำนวณ rollup หลักฐานความถูกต้องได้อย่างรวดเร็วจนถึงธุรกรรมการถอน ดังนั้นการสังเกตธุรกรรมของผู้ใช้ τ ใน mempool exect จะสามารถส่งธุรกรรมการอัปเดตสถานะ τ ′ สำหรับ τ ในราคาก๊าซที่สูงขึ้น ซึ่งถือเป็นการดำเนินกิจการแนวหน้าที่เป็นประโยชน์ โดยมีเงื่อนไขว่า τ ไม่ได้ถูกขุดก่อนที่ τ ′ จะถึง mempool, τ ′ จะอยู่ข้างหน้า τ และ τ จะทำให้เกิดการถอนเงินที่ได้รับอนุมัติ ในตัวแปร TEF ที่ DON อาศัยในการคำนวณการอัปเดตสถานะ (ดู ตัวแปรการลงนามตามเกณฑ์ด้านล่าง) DON สามารถกำหนดออฟเชนได้ ว่า τ ควรได้รับการอนุมัติหรือไม่เมื่อพิจารณาจากสถานะของ SC ในการดำเนินการ DON จากนั้นสามารถส่งธุรกรรม τ ′ ที่อนุมัติการถอน τ—โดยไม่ทำให้เกิดผลเต็มจำนวน อัปเดตสถานะ หากแนวทางนี้เป็นไปไม่ได้ หรือในกรณีที่ไม่ประสบผลสำเร็จ DON-ริเริ่ม ธุรกรรม τ ′ สามารถส่งเงินไปยังผู้ใช้เพื่อตอบสนองต่อ τ เพื่อให้ผู้ใช้ไม่ต้องการ เริ่มการทำธุรกรรมเพิ่มเติม 6.3 กำลังซิงค์ โปรแกรมปฏิบัติการ TEF จะพุชการอัปเดตจาก DON ไปยัง MAINCHAIN เป็นระยะ อัปเดตสถานะของ SCa ในกระบวนการที่เราเรียกว่าการซิงค์ การซิงค์อาจคิดได้ เป็นการเผยแพร่ธุรกรรมของเลเยอร์ 2 ไปยังเลเยอร์ 1 ดังนั้น TEF จึงสามารถดึงตัวเลขใดๆ ก็ได้ ของเทคนิคที่มีอยู่เพื่อจุดประสงค์นี้ รวมถึง rollups [5, 12, 16, 69] ในแง่ดี rollups [10, 11, 141], Validium [201] หรือการลงนามเกณฑ์พื้นฐาน เช่น เกณฑ์ BLS ชนอร์หรือ ECDSA [24, 54, 116, 202] โดยหลักการแล้ว สภาพแวดล้อมการดำเนินการที่เชื่อถือได้ ยังสามารถยืนยันถึงความถูกต้องของการเปลี่ยนแปลงสถานะ ทำให้มีประสิทธิภาพมากขึ้น ทางเลือกแทน rollups แต่มีโมเดลความน่าเชื่อถือที่ขึ้นกับฮาร์ดแวร์ (ดู เช่น [80].) ด้านล่างเราจะเปรียบเทียบตัวเลือกการซิงค์เหล่านี้กับคุณสมบัติหลักสามประการ เทฟ: • ความพร้อมใช้งานของข้อมูล: สถานะของ SC เก็บไว้ที่ไหน? อย่างน้อยสามตัวเลือกคือ มีอยู่ใน TEF: บน MAINCHAIN บน DON หรือโดยที่เก็บข้อมูลของบุคคลที่สาม ผู้ให้บริการเช่น IPFS พวกเขาบรรลุการรับประกันความปลอดภัยและความพร้อมใช้งานที่แตกต่างกัน ระดับและโปรไฟล์ประสิทธิภาพ สรุป สถานะการจัดเก็บบน MAINCHAIN เปิดใช้งาน การตรวจสอบแบบออนไลน์และลดการพึ่งพาฝ่ายใดฝ่ายหนึ่งในเรื่องความพร้อมใช้งานของรัฐ ในทางกลับกัน การจัดเก็บ state of-chain สามารถลดต้นทุนการจัดเก็บและปรับปรุงได้ ปริมาณงาน โดยเสียค่าใช้จ่ายของผู้ให้บริการพื้นที่จัดเก็บข้อมูลที่เชื่อถือได้ (DON หรือบุคคลที่สาม) สำหรับ ความพร้อมใช้งานของข้อมูล แน่นอนว่าโมเดลยืดหยุ่นที่รวมตัวเลือกเหล่านี้เข้าด้วยกันก็เช่นกัน เป็นไปได้ เราระบุรูปแบบความพร้อมของข้อมูลที่ต้องการในตารางที่ 1• รับประกันความถูกต้อง: SCa จะยืนยันความถูกต้องของการอัปเดตได้อย่างไร ผลักดันโดย exect? สิ่งนี้ส่งผลต่อภาระการคำนวณบน exect และ SCa และ เวลาแฝงในการซิงค์ (ดูด้านล่าง) • เวลาแฝง: เวลาแฝงในการซิงค์มีปัจจัยสามประการ: (1) เวลาที่ใช้ สำหรับ exect เพื่อสร้างธุรกรรมการซิงค์ τsync; (2) เวลาที่ใช้สำหรับ τsync เพื่อยืนยันใน MAINCHAIN; และ (3) เวลาที่ τsync มีผล เซาท์แคโรไลนา ใน TEF เวลาแฝงเป็นสิ่งสำคัญอย่างยิ่งสำหรับการถอนเงิน (แต่น้อยกว่าสำหรับ ธุรกรรมภายในสัญญา) เนื่องจากการถอนจำเป็นต้องมี (อย่างน้อย บางส่วน) การซิงค์สถานะ กำลังซิงค์ ตัวเลือก ข้อมูล ความพร้อมใช้งาน ความถูกต้อง การค้ำประกัน เวลาแฝง โรลอัพ [5, 12, 16, 69] ออนไลน์ หลักฐานความถูกต้อง เวลาที่ใช้ในการสร้าง การพิสูจน์ความถูกต้อง (เช่น นาทีในระบบปัจจุบัน) วาลิเดียม [201] ออฟ-เชน หลักฐานความถูกต้อง เช่นเดียวกับข้างต้น มองในแง่ดี rollup [10, 11,141] ออนไลน์ หลักฐานการฉ้อโกง ความยาวของความท้าทาย ระยะเวลา (เช่น วัน หรือ สัปดาห์) การลงนามเกณฑ์ [24, 54, 116, 202] มีความยืดหยุ่น ลายเซ็นเกณฑ์โดย DON ทันที สภาพแวดล้อมการดำเนินการที่เชื่อถือได้ [80] มีความยืดหยุ่น อิงฮาร์ดแวร์ การรับรอง ทันที ตารางที่ 1: ตัวเลือกการซิงค์ต่างๆ ใน TEF และคุณสมบัติต่างๆ ตารางที่ 1 สรุปคุณสมบัติเหล่านี้ในห้าตัวเลือกการซิงค์หลักใน TEF (หมายเหตุ เราไม่ได้ตั้งใจที่จะเปรียบเทียบเทคโนโลยีเหล่านี้เป็นการปรับขนาดเลเยอร์ 2 แบบสแตนด์อโลน โซลูชั่น เพื่อที่เราจะแนะนำผู้อ่านเช่น [121].) ตอนนี้เราจะพูดถึงตัวเลือกการซิงค์แต่ละรายการ โรลอัป: rollup [69] เป็นโปรโตคอลที่การเปลี่ยนแปลงสถานะได้รับผลกระทบจาก ชุดของธุรกรรมถูกคำนวณแบบลูกโซ่ จากนั้นจึงเผยแพร่การเปลี่ยนแปลงสถานะ สู่ MAINCHAIN หากต้องการนำ rollups ไปใช้นั้น สมอ smart contract SCa จะจัดเก็บ Rstate ที่เป็นตัวแทนแบบกะทัดรัด (เช่น Merkle root) ของสถานะจริง หากต้องการซิงค์ ให้ exect ส่ง τsync = (ต, ร' state) ถึง SCa โดยที่ T คือชุดของธุรกรรมที่ประมวลผลตั้งแต่ครั้งล่าสุดซิงค์และ R′ state คือการแสดงสถานะใหม่แบบกระชับซึ่งคำนวณโดยการใช้ ธุรกรรมใน T ไปยังสถานะ Rstate ก่อนหน้า มีสองรูปแบบยอดนิยมที่แตกต่างกันในวิธีที่ SCa ตรวจสอบการอัปเดตสถานะใน τsync ประการแรก (zk-)rollups แนบข้อโต้แย้งที่กระชับเกี่ยวกับความถูกต้อง บางครั้งเรียกว่า หลักฐานความถูกต้องสำหรับการเปลี่ยนแปลง Rstate → R′ รัฐ หากต้องการใช้ตัวแปรนี้ ให้ดำเนินการดังนี้ คำนวณและส่งหลักฐานความถูกต้อง (เช่น หลักฐาน zk-SNARK) พร้อมด้วย τsync พิสูจน์ว่า R′ state เป็นผลมาจากการใช้ T กับสถานะปัจจุบันของ SCa สมอเรือ สัญญายอมรับการอัปเดตสถานะหลังจากที่ได้ตรวจสอบหลักฐานแล้วเท่านั้น rollups ในแง่ดีไม่รวมข้อโต้แย้งของความถูกต้อง แต่มี staking และ ขั้นตอนการท้าทายที่อำนวยความสะดวกในการตรวจสอบแบบกระจายของการเปลี่ยนสถานะ สำหรับสิ่งนี้ rollup ตัวแปร SCa ยอมรับอย่างไม่แน่นอน τsync โดยสมมติว่ามันถูกต้อง (ด้วยเหตุนี้จึงเป็นการมองโลกในแง่ดี) แต่ τsync จะไม่มีผลจนกว่าจะผ่านช่วงท้าทาย ในระหว่างที่ฝ่ายใดฝ่ายหนึ่ง การตรวจสอบ MAINCHAIN สามารถระบุการอัปเดตสถานะที่ผิดพลาดและแจ้งให้ SCa ดำเนินการได้ การดำเนินการที่จำเป็น (เช่น เพื่อย้อนกลับสถานะและลงโทษผู้บริหาร) ตัวแปร rollup ทั้งสองรุ่นบรรลุความพร้อมใช้งานของข้อมูลออนไลน์ เมื่อมีการผ่านรายการธุรกรรม on-chain ซึ่งสามารถสร้างสถานะเต็มได้ เวลาแฝงของ zk-rollups คือ ถูกครอบงำโดยเวลาที่จำเป็นในการสร้างการพิสูจน์ความถูกต้อง ซึ่งโดยปกติจะอยู่ที่ ลำดับนาทีในระบบที่มีอยู่ [16] และมีแนวโน้มที่จะเห็นการปรับปรุงเมื่อเวลาผ่านไป ในทางกลับกัน rollups ในแง่ดีจะมีเวลาแฝงที่สูงกว่า (เช่น วันหรือสัปดาห์) เนื่องจากระยะเวลาท้าทายต้องนานเพียงพอในการพิสูจน์การฉ้อโกงจึงจะได้ผล ที่ นัยของการยืนยันที่ช้านั้นละเอียดอ่อนและบางครั้งก็เฉพาะเจาะจงกับแผนงาน ดังนั้น การวิเคราะห์อย่างละเอียดอยู่นอกขอบเขต ตัวอย่างเช่น บางโครงการพิจารณาการจ่ายเงิน ธุรกรรมเป็น "ขั้นสุดท้ายที่ไม่น่าเชื่อถือ" [109] ก่อนที่จะยืนยันการอัปเดตสถานะ เนื่องจาก ผู้ใช้ทั่วไปสามารถตรวจสอบ rollup ได้เร็วกว่า MAINCHAIN มาก วาลิเดียม: Validium เป็นรูปแบบหนึ่งของ (zk-)rollup ที่ทำให้ข้อมูลพร้อมใช้งานแบบออฟไลน์เท่านั้น และไม่เก็บข้อมูลทั้งหมดบน MAINCHAIN โดยเฉพาะ exect ส่งเฉพาะรายการใหม่เท่านั้น ระบุและพิสูจน์แต่ไม่ใช่ธุรกรรมกับ SCa ด้วยการซิงค์แบบ Validium ให้ดำเนินการ และ DON ที่ดำเนินการนั้นเป็นฝ่ายเดียวที่เก็บสถานะที่สมบูรณ์และ ที่ทำธุรกรรม เช่นเดียวกับ zk-rollups เวลาแฝงในการซิงค์จะถูกครอบงำโดยความถูกต้อง เวลาสร้างหลักฐาน ต่างจาก zk-rollups แต่การซิงค์สไตล์ Validium จะช่วยลด ต้นทุนการจัดเก็บและเพิ่มปริมาณงาน การลงนามตามเกณฑ์โดย DON: สมมติว่าเกณฑ์ของโหนด DON นั้นตรงไปตรงมา ตัวเลือกการซิงค์ที่ง่ายและรวดเร็วคือการให้ DON โหนดลงนามในสถานะใหม่ร่วมกัน แนวทางนี้สามารถรองรับความพร้อมใช้งานของข้อมูลทั้งแบบออนไลน์และออฟไลน์ โปรดทราบว่าถ้า ผู้ใช้ไว้วางใจ DON สำหรับการอัปเดต oracle พวกเขาไม่จำเป็นต้องเชื่อถือมากขึ้นในการยอมรับ อัปเดตสถานะ เนื่องจากอยู่ในโมเดลความน่าเชื่อถือตามเกณฑ์แล้ว ประโยชน์อีกอย่างหนึ่งของ การลงนามตามเกณฑ์มีเวลาแฝงต่ำ รองรับรูปแบบลายเซ็นธุรกรรมใหม่เช่น เสนอใน EIP-2938 [70] และรู้จักกันในชื่อบัญชีนามธรรมจะสร้างเกณฑ์ การลงนามทำได้ง่ายกว่ามาก เนื่องจากจะช่วยลดความจำเป็นในการเกณฑ์ขั้นต่ำ ECDSA ซึ่งเกี่ยวข้องกับโปรโตคอลที่ซับซ้อนกว่ามาก (เช่น [116, 117, 118])กว่าทางเลือกอื่นๆ เช่น ลายเซ็น Schnorr [202] หรือ BLS [55] เกณฑ์ สภาพแวดล้อมการดำเนินการที่เชื่อถือได้ (TEE): TEE คือสภาพแวดล้อมการดำเนินการแบบแยกส่วน (โดยปกติจะใช้ฮาร์ดแวร์) ซึ่งมีจุดมุ่งหมายเพื่อให้การป้องกันความปลอดภัยที่แข็งแกร่ง สำหรับโปรแกรมที่ทำงานอยู่ภายใน TEE บางตัว (เช่น Intel SGX [84]) สามารถสร้างหลักฐานได้ เรียกว่าการรับรองว่าเอาต์พุตได้รับการคำนวณอย่างถูกต้องโดยโปรแกรมเฉพาะสำหรับ อินพุตเฉพาะ 12 การซิงค์ TEF แบบอิง TEE สามารถใช้งานได้ แทนที่การพิสูจน์ใน (zk-)rollups หรือ Validium ด้วยการรับรอง TEE โดยใช้เทคนิค จาก [80]. เมื่อเปรียบเทียบกับการพิสูจน์ความรู้แบบศูนย์ที่ใช้ใน rollups และ Validium แล้ว TEE นั้นมีมากมาย มีประสิทธิภาพมากขึ้น เมื่อเปรียบเทียบกับการลงนามตามเกณฑ์ TEE จะขจัดความซับซ้อนของ การสร้างเกณฑ์ลายเซ็น ECDSA ตามหลักการแล้วจะต้องมี TEE เดียวเท่านั้น มีส่วนร่วม อย่างไรก็ตาม การใช้ TEE จะทำให้เกิดสมมติฐานด้านความน่าเชื่อถือที่ขึ้นกับฮาร์ดแวร์เพิ่มเติม เรายังสามารถรวม TEE เข้ากับการลงนามตามเกณฑ์เพื่อสร้างความยืดหยุ่น ต่อการประนีประนอมของอินสแตนซ์ TEE เพียงเล็กน้อย แม้ว่าจะเป็นมาตรการป้องกันก็ตาม รื้อฟื้นความซับซ้อนของการสร้างลายเซ็น ECDSA ตามเกณฑ์ ความยืดหยุ่นเพิ่มเติม: ตัวเลือกการซิงค์เหล่านี้สามารถปรับแต่งได้เพื่อให้มีความยืดหยุ่นมากขึ้นด้วยวิธีต่อไปนี้ • การทริกเกอร์ที่ยืดหยุ่น: แอปพลิเคชัน TEF สามารถกำหนดเงื่อนไขภายใต้นั้นได้ การซิงค์จะถูกทริกเกอร์ ตัวอย่างเช่น การซิงค์อาจเป็นแบบแบตช์ เช่น เกิดขึ้นหลังจากนั้น ทุกธุรกรรม N ตามเวลา เช่น ทุกๆ 10 บล็อก หรือตามเหตุการณ์ เช่น เกิดขึ้น เมื่อใดก็ตามที่ราคาสินทรัพย์เป้าหมายเคลื่อนไหวอย่างมีนัยสำคัญ • การซิงค์บางส่วน: เป็นไปได้และในบางกรณีเป็นที่ต้องการ (เช่น ด้วย rollups การซิงค์บางส่วนสามารถลดเวลาในการตอบสนองได้) เพื่อให้การซิงค์ข้อมูลขนาดเล็กรวดเร็ว จำนวนสถานะ ดำเนินการซิงค์แบบเต็มอาจเป็นระยะๆ เท่านั้น ตัวอย่างเช่น exect สามารถอนุมัติคำขอถอนเงินโดยอัปเดตยอดคงเหลือของผู้ใช้ใน SCa โดยไม่ต้องอัปเดตสถานะ MAINCHAIN เป็นอย่างอื่น 6.4 รีออร์กส์ การปรับโครงสร้างบล็อคเชนอันเป็นผลมาจากความไม่เสถียรของเครือข่ายหรือแม้กระทั่งจากการโจมตี 51% สามารถก่อให้เกิดภัยคุกคามต่อความสมบูรณ์ของห่วงโซ่หลักได้ ในทางปฏิบัติฝ่ายตรงข้ามได้ใช้ พวกเขาติดตั้งการโจมตีแบบใช้จ่ายสองครั้ง [34] ในขณะที่การโจมตีดังกล่าวบนเครือข่ายหลักๆนั้น ท้าทายในการติดตั้ง แต่ยังคงเป็นไปได้สำหรับโซ่บางอัน [88] เนื่องจากมันทำงานโดยไม่ขึ้นอยู่กับ MAINCHAIN ดังนั้น DON จึงนำเสนอสิ่งที่น่าสนใจ ความเป็นไปได้ในการสังเกตและให้ความคุ้มครองต่อองค์กรที่เกี่ยวข้อง การโจมตี ตัวอย่างเช่น DON สามารถรายงานต่อสัญญา SC ที่พึ่งพาบน MAINCHAIN ​​ว่ามีทางแยกที่แข่งขันกันซึ่งมีความยาวขีดจำกัด τ อยู่บ้าง DON สามารถทำได้เพิ่มเติม 12รายละเอียดเพิ่มเติมสามารถพบได้ในภาคผนวก B.2.1 ไม่จำเป็นสำหรับการทำความเข้าใจ

ให้หลักฐาน—ในการตั้งค่า PoW หรือ PoS—ของการมีอยู่ของทางแยกดังกล่าว ที่ สัญญา SC สามารถใช้การดำเนินการป้องกันที่เหมาะสม เช่น การระงับการดำเนินการธุรกรรมเพิ่มเติมเป็นระยะเวลาหนึ่ง (เช่น เพื่ออนุญาตให้การแลกเปลี่ยนขึ้นบัญชีดำที่ใช้จ่ายสองครั้ง สินทรัพย์) โปรดทราบว่าแม้ว่าฝ่ายตรงข้ามจะมีการโจมตีถึง 51% ก็สามารถพยายามเซ็นเซอร์ได้ รายงานจาก DON มาตรการตอบโต้ใน SC คือการต้องมีรายงานเป็นระยะจาก DON เพื่อประมวลผลธุรกรรม (เช่น การเต้นของหัวใจ) หรือต้องการรายงานใหม่ ตรวจสอบธุรกรรมที่มีมูลค่าสูง แม้ว่าการแจ้งเตือนการฟอร์กดังกล่าวโดยหลักการแล้วจะเป็นบริการทั่วไปที่ DON สามารถให้ได้ เพื่อวัตถุประสงค์หลายประการ แผนของเราคือการรวมสิ่งเหล่านี้เข้ากับ TEF

การลดความน่าเชื่อถือ

ในฐานะระบบการกระจายอำนาจที่มีส่วนร่วมจากกลุ่มเอนทิตีที่ต่างกัน เครือข่าย Chainlink ให้การป้องกันที่แข็งแกร่งต่อความล้มเหลวทั้งในด้านความพร้อมใช้งาน (ความพร้อมใช้งาน) และความปลอดภัย (ความสมบูรณ์ของรายงาน) อย่างไรก็ตาม ระบบกระจายอำนาจส่วนใหญ่จะแตกต่างกันไป ระดับที่องค์ประกอบที่เป็นส่วนประกอบมีการกระจายอำนาจ นี้ เป็นจริงแม้กระทั่งกับระบบขนาดใหญ่ ซึ่งมีการกระจายอำนาจที่จำกัดในหมู่นักขุด [32] และ คนกลาง [51] มีมานานแล้ว เป้าหมายของความพยายามในการกระจายอำนาจคือการลดความไว้วางใจ: เราพยายามที่จะลด ผลเสียของการทุจริตหรือความล้มเหลวของระบบภายในเครือข่าย Chainlink แม้ว่า เนื่องจาก DON ที่เป็นอันตราย หลักการชี้นำของเราคือหลักการของสิทธิพิเศษน้อยที่สุด [197] ส่วนประกอบของระบบและผู้ดำเนินการภายในระบบควรมีการกำหนดขอบเขตสิทธิ์อย่างเคร่งครัด เพื่อให้บรรลุผลสำเร็จตามบทบาทที่ได้รับมอบหมายเท่านั้น ที่นี่เราวางกลไกที่เป็นรูปธรรมหลายประการเพื่อให้ Chainlink นำไปใช้ในการขับเคลื่อน สู่การลดความไว้วางใจให้เหลือน้อยที่สุด เราอธิบายลักษณะกลไกเหล่านี้ในแง่ ของตำแหน่ง เช่น ส่วนประกอบของระบบที่มีการรูท แสดงในรูปที่ 14 เรา ที่อยู่แต่ละสถานที่ในส่วนย่อยที่เกี่ยวข้อง 7.1 การรับรองความถูกต้องแหล่งข้อมูล โมเดลการทำงานปัจจุบันสำหรับ oracles ถูกจำกัดด้วยข้อเท็จจริงที่ว่าแหล่งข้อมูลมีน้อย เซ็นชื่อแบบดิจิทัลในข้อมูลที่ละเว้น โดยส่วนใหญ่เนื่องจาก TLS ไม่ได้เซ็นชื่อโดยธรรมชาติ ข้อมูล TLS ใช้ลายเซ็นดิจิทัลในโปรโตคอล “handshake” (เพื่อสร้าง คีย์ที่ใช้ร่วมกันระหว่างเซิร์ฟเวอร์และไคลเอนต์) HTTPS-เซิร์ฟเวอร์ที่เปิดใช้งานจึงมีใบรับรอง บนกุญแจสาธารณะซึ่งโดยหลักการแล้วสามารถทำหน้าที่ลงนามข้อมูลได้ แต่โดยทั่วไปแล้วจะไม่ใช้งาน ใบรับรองเหล่านี้เพื่อรองรับการลงนามข้อมูล ดังนั้นการรักษาความปลอดภัยของ DON เช่น ในเครือข่าย oracle ในปัจจุบัน อาศัยโหนด oracle ที่ถ่ายทอดข้อมูลจากข้อมูลอย่างซื่อสัตย์ แหล่งที่มาของสัญญา องค์ประกอบระยะยาวที่สำคัญของวิสัยทัศน์ของเราในการลดความน่าเชื่อถือใน Chainlink เกี่ยวข้องกับการพิสูจน์ตัวตนแหล่งข้อมูลที่แข็งแกร่งยิ่งขึ้นผ่านการสนับสนุนเครื่องมือและมาตรฐานสำหรับการลงนามข้อมูล การลงนามข้อมูลสามารถช่วยบังคับใช้การรับประกันความสมบูรณ์ตั้งแต่ต้นทางถึงปลายทางได้ โดยหลักการแล้ว หากสัญญายอมรับเป็นอินพุตชิ้นส่วนของข้อมูล D ที่ลงนามโดยข้อมูลโดยตรง

รูปที่ 14: ตำแหน่งกลไกลดความไว้วางใจที่กล่าวถึงในส่วนนี้ 1⃝ข้อมูล แหล่งที่มาให้ข้อมูลแก่ 2⃝DON ซึ่งถ่ายทอดฟังก์ชันของข้อมูลไปยังผู้อยู่ในอุปการะ 3⃝smart contract. นอกจากนี้ เครือข่าย DON หรือ oracle ยังมีโหนด 4⃝ การจัดการ smart contracts บน MAINCHAIN สำหรับ เช่น การชดเชยโหนด การป้องกัน ราง และอื่นๆ แหล่งที่มา ดังนั้นเครือข่าย oracle ไม่สามารถยุ่งเกี่ยวกับ D. การสนับสนุนต่างๆ ได้ มีความพยายามในการเปิดใช้งานการลงนามข้อมูลดังกล่าว รวมถึง OpenID Connect ซึ่ง ได้รับการออกแบบมาเพื่อการตรวจสอบผู้ใช้เป็นหลัก [9], TLS-N ซึ่งเป็นโครงการทางวิชาการที่มุ่งหวังที่จะ ขยาย TLS [191] โดยการนำใบรับรอง TLS ไปใช้ใหม่และส่วนขยายหลักฐาน TLS [63] แม้ว่า OpenID Connect จะมีการนำไปใช้บ้าง แต่ TLS Evidence Extensions และ TLS-N ยังไม่เห็นการนำไปใช้ อีกช่องทางที่เป็นไปได้ในการตรวจสอบแหล่งข้อมูลคือการใช้ของผู้เผยแพร่เอง Signed HTTP Exchanges (SXG) [230] ซึ่งสามารถแคชบนเครือข่ายการจัดส่งเนื้อหาโดยเป็นส่วนหนึ่งของโปรโตคอล Accelerated Mobile Pages (AMP) [225] เบราว์เซอร์ Chrome บนอุปกรณ์เคลื่อนที่จะแสดงเนื้อหาจาก SXG ที่แคชด้วย AMP เหมือนกับว่ามาจากบริการดังกล่าว โดเมนเครือข่ายของผู้เผยแพร่โฆษณาแทนโดเมนแคชเซิร์ฟเวอร์ สิ่งจูงใจในการสร้างแบรนด์นี้ ควบคู่ไปกับความสะดวกในการเปิดใช้งานโดยใช้บริการต่างๆ เช่น Real URL ของ CloudFlare [83] และ amppackager ของ Google [124] อาจนำไปสู่การนำ SXG มาใช้อย่างกว้างขวางในเนื้อหาข่าวที่แคชไว้ ซึ่งจะทำให้สามารถป้องกันการงัดแงะที่เรียบง่ายและป้องกันการงัดแงะได้ วิธีสำหรับ Chainlink oracles เพื่อทริกเกอร์เหตุการณ์ที่น่าบอกใบเรื่องข่าวที่รายงานใน SXG ที่ถูกต้อง แม้ว่า SXG ที่แคชไว้สำหรับ AMP จากผู้เผยแพร่ข่าวจะไม่มีประโยชน์สำหรับจังหวะที่มีจังหวะสูง แอปพลิเคชันเช่นรายงานข้อมูลการซื้อขาย อาจเป็นแหล่งข้อมูลที่ปลอดภัยสำหรับการกำหนดเอง สัญญาที่เกี่ยวข้องกับเหตุการณ์ในโลกแห่งความเป็นจริง เช่น สภาพอากาศสุดขั้วหรือผลการเลือกตั้ง เราเชื่อว่าการปรับใช้อย่างง่าย เครื่องมือที่สมบูรณ์ และความยืดหยุ่นจะมีความสำคัญ เร่งการลงนามแหล่งข้อมูล การเปิดใช้งานผู้ให้บริการข้อมูลเพื่อใช้โหนด Chainlink เป็น ส่วนหน้า API ที่ผ่านการรับรองความถูกต้องดูเหมือนจะเป็นแนวทางที่ดี เราตั้งใจที่จะสร้างตัวเลือกสำหรับโหนดที่จะทำงานในโหมดนี้ ไม่ว่าจะเข้าร่วมในเครือข่ายหรือไม่ก็ตาม อย่างเต็มกำลัง oracle เราอ้างถึงความสามารถนี้ว่าเป็นการสร้างข้อมูลที่มีการรับรองความถูกต้อง (อดีโอ). ด้วยการใช้โหนด Chainlink กับ ADO แหล่งข้อมูลจะได้รับประโยชน์ จากประสบการณ์และเครื่องมือที่พัฒนาโดยชุมชน Chainlink ในการเพิ่มดิจิทัล ความสามารถในการลงนามกับชุด API ออฟไลน์ที่มีอยู่ หากพวกเขาเลือกที่จะวิ่ง โหนดของพวกเขาเป็น oracles พวกเขาสามารถเปิดแหล่งรายได้ใหม่ที่เป็นไปได้เพิ่มเติม ภายใต้โมเดลเดียวกันกับผู้ให้บริการข้อมูลที่มีอยู่ เช่น Kraken [28], Kaiko [140] และ อื่นๆ ที่รันโหนด Chainlink เพื่อขายข้อมูล API บนเชน 7.1.1 ข้อจำกัดของการสร้างข้อมูลที่มีการรับรองความถูกต้อง การลงนามแบบดิจิทัลโดยแหล่งข้อมูล แม้ว่าจะสามารถช่วยเสริมสร้างการตรวจสอบสิทธิ์ได้ แต่ก็ยังไม่เพียงพอที่จะบรรลุผลสำเร็จของการรักษาความปลอดภัยตามธรรมชาติหรือเป้าหมายการปฏิบัติงานของ oracle เครือข่าย ในการเริ่มต้น ชิ้นส่วนของข้อมูล D จะต้องได้รับการถ่ายทอดอย่างมีประสิทธิภาพและทันเวลา จากแหล่งข้อมูลไปยัง smart contract หรือผู้ใช้ข้อมูลอื่นๆ นั่นคือแม้กระทั่งใน การตั้งค่าที่เหมาะสมที่สุดซึ่งข้อมูลทั้งหมดจะถูกเซ็นชื่อโดยใช้คีย์ที่ตั้งโปรแกรมไว้ล่วงหน้าให้ขึ้นต่อกัน สัญญา DON ยังคงจำเป็นในการสื่อสารข้อมูลที่เชื่อถือได้จากแหล่งที่มา เพื่อสัญญา นอกจากนี้ มีหลายกรณีที่สัญญาหรือข้อมูล oracle อื่นๆ ผู้บริโภคต้องการเข้าถึงเอาต์พุตที่ผ่านการรับรองความถูกต้องของฟังก์ชันต่างๆ ที่คำนวณผ่าน แหล่งข้อมูลด้วยเหตุผลสองประการ: • การรักษาความลับ: API แหล่งข้อมูลอาจให้ข้อมูลที่ละเอียดอ่อนหรือเป็นกรรมสิทธิ์ ที่จำเป็นต้องได้รับการแก้ไขหรือฆ่าเชื้อก่อนที่จะเปิดเผยต่อสาธารณะบนเครือข่าย อย่างไรก็ตาม การปรับเปลี่ยนข้อมูลที่ลงนามจะทำให้ลายเซ็นเป็นโมฆะ ใส่อีก วิธี ADO ที่ไม่เกี่ยวข้องและการฆ่าเชื้อข้อมูลเข้ากันไม่ได้ เราแสดงในตัวอย่างที่ 3 วิธีที่ทั้งสองสามารถคืนดีผ่านรูปแบบ ADO ที่ปรับปรุงแล้ว • ข้อผิดพลาดของแหล่งข้อมูล: ทั้งข้อผิดพลาดและความล้มเหลวสามารถส่งผลต่อแหล่งข้อมูลได้ และลายเซ็นดิจิทัลก็ไม่ช่วยแก้ปัญหาแต่อย่างใด ตั้งแต่เริ่มก่อตั้ง [98], Chainlink มี ได้รวมกลไกในการแก้ไขข้อผิดพลาดดังกล่าวไว้แล้ว: ความซ้ำซ้อน รายงานที่ออกโดยเครือข่าย oracle มักจะแสดงถึงข้อมูลที่รวมกันของหลายเครือข่าย แหล่งที่มา ขณะนี้เรากำลังหารือถึงแผนการที่เรากำลังสำรวจในการตั้งค่า ADO เพื่อปรับปรุงการรักษาความลับของข้อมูลต้นฉบับ และเพื่อรวมข้อมูลจากหลายแหล่งอย่างปลอดภัย 7.1.2 การรักษาความลับ แหล่งข้อมูลอาจไม่คาดการณ์และจัดให้มีขอบเขต API ทั้งหมดที่ต้องการ โดยผู้ใช้ โดยเฉพาะอย่างยิ่งผู้ใช้อาจต้องการเข้าถึงข้อมูลที่ประมวลผลล่วงหน้าเพื่อช่วยให้แน่ใจว่า การรักษาความลับ ตัวอย่างต่อไปนี้แสดงให้เห็นถึงปัญหาตัวอย่างที่ 3 อลิซต้องการได้รับการระบุข้อมูลประจำตัวแบบกระจายอำนาจ (DID) ว่าเธอมีอายุเกิน 18 ปี (และสามารถกู้เงินได้) ที่จะทำ ดังนั้นเธอจึงต้องพิสูจน์ข้อเท็จจริงเกี่ยวกับอายุของเธอต่อผู้ออกใบรับรอง DID อลิซหวังที่จะใช้ข้อมูลจากกรมยานยนต์ (DMV) ของรัฐของเธอ เว็บไซต์เพื่อวัตถุประสงค์ DMV มีบันทึกวันเกิดของเธอและจะปล่อย หนังสือรับรอง A ที่ลงนามแบบดิจิทัลบนแบบฟอร์มต่อไปนี้: A = {ชื่อ: อลิซ วันเกิด: 16/02/1999} ในตัวอย่างนี้ เอกสารรับรอง A อาจเพียงพอที่จะให้ Alice พิสูจน์ต่อ DID ได้ ผู้ออกหนังสือรับรองที่เธออายุเกิน 18 ปี แต่ข้อมูลสำคัญก็รั่วไหลโดยไม่จำเป็น: ของอลิซ DoB ที่แน่นอน ตามหลักการแล้ว สิ่งที่อลิซต้องการจาก DMV แทนคือการลงนามใน a ข้อความง่ายๆ A′ ว่า “อลิซอายุเกิน 18 ปี” กล่าวอีกนัยหนึ่งเธอต้องการ ผลลัพธ์ของฟังก์ชัน G บนวันเกิดของเธอ X โดยที่ (อย่างไม่เป็นทางการ), A′ = G(X) = True ถ้า CurrentDate −X ≥18 ปี; มิฉะนั้น G(X) = เท็จ โดยสรุป Alice ต้องการขอลายเซ็นจากแหล่งข้อมูล หนังสือรับรอง A′ ของแบบฟอร์ม: A′ = {ชื่อ: อลิซ, Func:G(X), ผลลัพธ์: จริง}, โดยที่ G(X) หมายถึงคุณลักษณะเฉพาะของฟังก์ชัน G และอินพุต X ของฟังก์ชัน เราจินตนาการถึง ว่าผู้ใช้ควรจะสามารถระบุ G(X) ที่ต้องการเป็นอินพุตพร้อมกับคำขอของเธอสำหรับ a การรับรองที่สอดคล้องกัน A′ โปรดทราบว่าการรับรองของแหล่งข้อมูล A′ จะต้องมีข้อกำหนด G(X) ถึง ตรวจสอบให้แน่ใจว่า A′ ถูกตีความอย่างถูกต้อง ในตัวอย่างข้างต้น G(X) กำหนดความหมาย ของค่าบูลีนใน A′ และด้วยเหตุนี้ True จึงแสดงถึงเรื่องของการรับรอง มีอายุมากกว่า 18 ปี เราอ้างถึงการสืบค้นแบบยืดหยุ่นซึ่งผู้ใช้สามารถระบุ G(X) เป็นการสืบค้นเชิงฟังก์ชันได้ เพื่อรองรับกรณีการใช้งานเช่นนั้นในตัวอย่างที่ 3 รวมถึงกรณีที่เกี่ยวข้องกับการสืบค้น โดยตรงจากสัญญา เราตั้งใจที่จะรวมการสนับสนุนสำหรับการสืบค้นการทำงานที่เกี่ยวข้อง ฟังก์ชันอย่างง่าย G ซึ่งเป็นส่วนหนึ่งของ ADO 7.1.3 การรวมแหล่งข้อมูล เพื่อลดต้นทุนออนไลน์ โดยทั่วไปสัญญาได้รับการออกแบบให้ใช้ข้อมูลที่รวมกัน จากหลายแหล่ง ดังตัวอย่างต่อไปนี้ ตัวอย่างที่ 4 (ข้อมูลราคากลาง) เพื่อระบุฟีดราคา เช่น มูลค่าหนึ่ง สินทรัพย์ (เช่น ETH) ที่เกี่ยวข้องกับสินทรัพย์อื่น (เช่น USD) โดยทั่วไปเครือข่าย oracle จะ รับราคาปัจจุบันจากแหล่งต่างๆ เช่น การแลกเปลี่ยน เครือข่าย oracle โดยทั่วไปจะส่งค่ามัธยฐานของค่าเหล่านี้ไปยังสัญญา SC ที่ต้องพึ่งพา ในสภาพแวดล้อมที่มีการลงนามข้อมูล จะได้รับเครือข่าย oracle ที่ทำงานอย่างถูกต้อง จากแหล่งข้อมูล S = {S1, . . . , SnS} ลำดับของค่า V = {v1, v2, . . . , vnS} จาก แหล่งที่มา nS พร้อมด้วยลายเซ็นเฉพาะแหล่งที่มา Σ = {σ1, σ2, . . , σnS} เมื่อ การตรวจสอบลายเซ็นจะส่งราคา v = ค่ามัธยฐาน (V ) ไปยัง SCน่าเสียดายที่ไม่มีวิธีง่ายๆ สำหรับเครือข่าย oracle ในการส่งข้อมูลค่ามัธยฐาน ค่า v ในตัวอย่างที่ 4 ถึง SC พร้อมด้วยหลักฐานที่กระชับ σ∗ว่า v ถูกคำนวณอย่างถูกต้อง มากกว่าอินพุตที่ลงนาม แนวทางที่ไร้เดียงสาคือการเข้ารหัสคีย์สาธารณะใน SC ของแหล่งข้อมูล nS ทั้งหมด เครือข่าย oracle จะถ่ายทอด (V, Σ) และอนุญาตให้ SC คำนวณค่ามัธยฐานของ V อย่างไรก็ตาม สิ่งนี้จะส่งผลให้มีการพิสูจน์ σ ที่มีขนาด O(nS) กล่าวคือ σ∗ จะไม่กระชับ นอกจากนี้ยังจะทำให้ SC มีค่าใช้จ่ายน้ำมันสูง ซึ่งจะต้องตรวจสอบลายเซ็นทั้งหมด Σ. ในทางตรงกันข้าม การใช้ SNARK ช่วยให้สามารถพิสูจน์โดยย่อของค่าแหล่งที่มาที่ได้รับการรับรองความถูกต้องที่รวมเข้าด้วยกันอย่างถูกต้อง ในทางปฏิบัติอาจใช้ได้แต่มีปริมาณค่อนข้างสูง ค่าใช้จ่ายในการคำนวณบนเครื่องพิสูจน์ และต้นทุนก๊าซที่ค่อนข้างสูงในห่วงโซ่ การใช้ Town Crier ก็เป็นไปได้เช่นกัน แต่ต้องใช้ TEE ซึ่งไม่เหมาะกับทุกคน โมเดลความน่าเชื่อถือของผู้ใช้ แนวคิดที่เป็นประโยชน์ในการวางกรอบแนวทางแก้ไขปัญหาทั่วไปของการลงนามข้อมูลที่รวมจากแหล่งที่มาคือเครื่องมือเข้ารหัสที่เรียกว่าลายเซ็นการทำงาน [59, 132] โดยสรุป ลายเซ็นการทำงานช่วยให้ผู้ลงนามสามารถมอบหมายความสามารถในการลงนามได้ เช่นนั้น ผู้รับมอบสิทธิ์สามารถลงนามในข้อความในช่วงของฟังก์ชัน F ที่ผู้ลงนามเลือกเท่านั้น เราแสดงในภาคผนวก D ว่าข้อจำกัดการทำงานนี้สามารถให้บริการเพื่อผูกช่วงได้อย่างไร ของค่ารายงานที่ปล่อยออกมาโดย DON เป็นฟังก์ชันของค่าที่ลงนามโดยแหล่งข้อมูล นอกจากนี้เรายังแนะนำรูปแบบดั้งเดิมใหม่ที่เรียกว่าลายเซ็นการทำงานแบบแยกส่วน ซึ่งรวมถึงข้อกำหนดที่ผ่อนคลายสำหรับความแม่นยำ แต่อาจมีประสิทธิภาพมากกว่ามาก กว่าแนวทางเช่น SNARK ปัญหาของการรวมแหล่งข้อมูลในลักษณะที่มีการรับรองความถูกต้องของแหล่งที่มา ของเอาต์พุตยังนำไปใช้กับผู้รวบรวมข้อมูล เช่น CoinCap, CoinMarketCap, CoinGecko, CryptoCompare ฯลฯ ซึ่งได้รับข้อมูลจากการแลกเปลี่ยนหลายหลากซึ่งพวกเขา น้ำหนักตามปริมาตร โดยใช้วิธีการที่ในบางกรณีเปิดเผยต่อสาธารณะ และในกรณีอื่นๆ เป็นกรรมสิทธิ์ ผู้รวบรวมที่ต้องการเผยแพร่ค่าด้วย การตรวจสอบแหล่งที่มาต้องเผชิญกับความท้าทายเช่นเดียวกับการรวบรวมโหนด แหล่งข้อมูล 7.1.4 กำลังประมวลผลข้อมูลต้นฉบับ smart contract ที่ซับซ้อนมีแนวโน้มที่จะขึ้นอยู่กับสถิติรวมที่กำหนดเอง แหล่งข้อมูลหลัก เช่น ความผันผวนของประวัติราคาล่าสุดจากสินทรัพย์จำนวนมาก หรือ ข้อความและรูปถ่ายจากข่าวเหตุการณ์ที่เกี่ยวข้อง เนื่องจากการคำนวณและแบนด์วิธมีราคาค่อนข้างถูกใน DON สถิติเหล่านี้— แม้แต่โมเดลแมชชีนเลิร์นนิงที่ซับซ้อนซึ่งมีอินพุตจำนวนมาก ก็สามารถประมวลผลได้ในราคาประหยัด ตราบใดที่ค่าเอาท์พุตใดๆ ที่กำหนดไว้สำหรับ blockchain มีความกระชับเพียงพอ สำหรับงานที่ใช้คอมพิวเตอร์เข้มข้นซึ่งผู้เข้าร่วม DON อาจมีความแตกต่างกัน มุมมองเกี่ยวกับอินพุตที่ซับซ้อน การสื่อสารรอบพิเศษระหว่างผู้เข้าร่วม DON อาจจำเป็นต้องสร้างฉันทามติเกี่ยวกับอินพุตก่อนที่จะคำนวณผลลัพธ์ ตราบใดที่ค่าสุดท้ายถูกกำหนดโดยอินพุตทั้งหมด เมื่อมีการสร้างฉันทามติอินพุตแล้ว ผู้เข้าร่วมแต่ละคนก็สามารถคำนวณค่าและถ่ายทอดไปยังอีกฝ่ายหนึ่งได้ผู้เข้าร่วมพร้อมลายเซ็นบางส่วนหรือส่งไปยังผู้รวบรวม 7.2 DON การลดความน่าเชื่อถือ เราจินตนาการถึงสองวิธีหลักในการลดความไว้วางใจที่มีอยู่ในองค์ประกอบของ DON: ไคลเอ็นต์เฟลโอเวอร์และรายงานส่วนน้อย 7.2.1 ไคลเอนต์ที่ล้มเหลว โมเดลฝ่ายตรงข้ามในวิทยาการเข้ารหัสและวรรณกรรมระบบแบบกระจายโดยทั่วไป พิจารณาฝ่ายตรงข้ามที่สามารถสร้างความเสียหาย (เช่น การประนีประนอม) ชุดย่อยของโหนด เช่น น้อยกว่าหนึ่งในสามสำหรับโปรโตคอล BFT จำนวนมาก แต่ที่สังเกตได้ทั่วไปคือ ว่าหากโหนดทั้งหมดใช้ซอฟต์แวร์ที่เหมือนกัน ฝ่ายตรงข้ามที่สามารถระบุถึงช่องโหว่ร้ายแรงได้ โดยหลักการแล้วประนีประนอมโหนดทั้งหมดไม่มากก็น้อยพร้อมกัน การตั้งค่านี้มักจะเป็น เรียกว่าซอฟต์แวร์เชิงเดี่ยว [47] มีการเสนอข้อเสนอต่างๆ สำหรับการกระจายซอฟต์แวร์และการกำหนดค่าซอฟต์แวร์โดยอัตโนมัติเพื่อแก้ไขปัญหา เช่น [47, 113] ตามที่ระบุไว้ใน [47] อย่างไรก็ตาม ความหลากหลายของซอฟต์แวร์เป็นปัญหาที่ซับซ้อนและต้องพิจารณาอย่างรอบคอบ ตัวอย่างเช่น การกระจายซอฟต์แวร์ที่หลากหลายอาจส่งผลให้เกิดการรักษาความปลอดภัยที่เลวร้ายยิ่งกว่าการปลูกพืชเชิงเดี่ยวหากเป็นเช่นนั้น เพิ่มพื้นผิวการโจมตีของระบบและทำให้เวกเตอร์ของการโจมตีเป็นไปได้เกินกว่า ประโยชน์ด้านความปลอดภัยที่ได้รับ เราเชื่อว่าการรองรับไคลเอ็นต์เฟลโอเวอร์ที่แข็งแกร่ง เช่น ไคลเอ็นต์ที่โหนดใด สามารถเปลี่ยนเมื่อเผชิญกับเหตุการณ์ภัยพิบัติ - เป็นรูปแบบที่น่าสนใจอย่างยิ่ง ความหลากหลายของซอฟต์แวร์ ไคลเอ็นต์เฟลโอเวอร์ไม่เพิ่มจำนวนเวกเตอร์ที่เป็นไปได้ ของการโจมตี เนื่องจากไม่ได้ใช้งานเป็นซอฟต์แวร์หลัก มีคุณประโยชน์ที่ชัดเจน อย่างไรก็ตาม เป็นแนวป้องกันที่สอง เราตั้งใจที่จะสนับสนุนไคลเอ็นต์เฟลโอเวอร์ใน DONs เช่น วิธีสำคัญในการลดการพึ่งพาการรักษาความปลอดภัยบนไคลเอ็นต์เพียงเครื่องเดียว Chainlink มีระบบไคลเอนต์ Failover ที่แข็งแกร่งอยู่แล้ว แนวทางของเรา เกี่ยวข้องกับการดูแลรักษาเวอร์ชันไคลเอนต์ที่ผ่านการทดสอบการรบก่อนหน้านี้ ตัวอย่างเช่น ในปัจจุบัน Chainlink โหนดที่มี OF-Chain Reporting (OCR) เป็นไคลเอ็นต์หลักได้รวมการสนับสนุนไว้ด้วย สำหรับระบบ FluxMonitor ก่อนหน้าของ Chainlink หากจำเป็น ใช้งานมาบ้างแล้ว เวลา FluxMonitor ได้รับการตรวจสอบความปลอดภัยและการทดสอบภาคสนาม มันก็ให้เหมือนกัน ทำงานเป็น OCR เพียงในราคาที่สูงกว่า ซึ่งเป็นต้นทุนที่เกิดขึ้นตามความจำเป็นเท่านั้น 7.2.2 รายงานผู้ถือหุ้นส่วนน้อย เมื่อพิจารณาจากชุด Ominority ของชนกลุ่มน้อยที่มีขนาดใหญ่พอสมควร—เศษเสี้ยวของโหนดที่ซื่อสัตย์ซึ่งสังเกตพบข้อผิดพลาดของคนส่วนใหญ่— มันจะเป็นประโยชน์สำหรับพวกเขาในการสร้างชนกลุ่มน้อย รายงาน นี่คือรายงานแบบขนานหรือแฟล็กที่ส่งต่อไปยังสัญญา SC แบบออนไลน์ โดย ลางสังหรณ์. SC สามารถใช้ธงนี้ได้ตามนโยบายสัญญาเฉพาะของตนเอง ตัวอย่างเช่น สำหรับสัญญาที่ความปลอดภัยมีความสำคัญมากกว่าความมีชีวิตชีวาหรือการตอบสนอง รายงานส่วนน้อยอาจทำให้สัญญาขอรายงานเสริม จาก DON อื่น หรือสั่งงานเซอร์กิตเบรกเกอร์ (ดูหัวข้อถัดไป)รายงานของชนกลุ่มน้อยสามารถมีบทบาทสำคัญได้แม้ว่าคนส่วนใหญ่จะซื่อสัตย์ก็ตาม เนื่องจากรูปแบบการรวมรายงานใดๆ แม้ว่าจะต้องใช้ลายเซ็นการทำงานก็ตาม ทำงานในลักษณะเกณฑ์เพื่อให้แน่ใจว่ามีความยืดหยุ่นต่อ oracle หรือความล้มเหลวของข้อมูล ใน กล่าวอีกนัยหนึ่ง จะต้องเป็นไปได้ที่จะจัดทำรายงานที่ถูกต้องตามข้อมูลนำเข้าของ kS < nS oracles สำหรับเกณฑ์ kS บางส่วน ซึ่งหมายความว่า DON ที่เสียหายมีบางส่วน ละติจูดในการจัดการค่ารายงานโดยเลือกค่า kS ที่ต้องการจาก nS รายงานใน V โดย oracles ทั้งชุด แม้ว่าแหล่งข้อมูลทั้งหมดจะซื่อสัตย์ก็ตาม ตัวอย่างเช่น สมมติว่า nS = 10 และ kS = 7 ในระบบที่ใช้ฟังก์ชัน ลายเซ็นเพื่อตรวจสอบความถูกต้องของการคำนวณค่ามัธยฐานมากกว่า V สำหรับราคา USD ของ ETH สมมติว่าห้าแหล่งรายงานราคา \(500, while the other five report \)1,000 จากนั้นโดยการจัดสื่อรายงานต่ำสุด 7 รายการ DON สามารถส่งออกค่าที่ถูกต้อง v = $500 และโดยค่ามัธยฐานสูงสุด ก็จะสามารถส่งออก v = $1,000 โดยการปรับปรุงโปรโตคอล DON เพื่อให้โหนดทั้งหมดทราบว่าข้อมูลใดเป็นข้อมูลใด และข้อมูลใดที่ใช้ในการสร้างรายงาน โหนดสามารถตรวจจับและทำเครื่องหมายได้ แนวโน้มที่มีนัยสำคัญทางสถิติที่จะสนับสนุนชุดรายงานชุดหนึ่งมากกว่าชุดอื่นและสร้าง รายงานส่วนน้อยเป็นผล 7.3 ราวกั้น โมเดลความน่าเชื่อถือของเราสำหรับ DONs ถือว่า MAINCHAIN มีความปลอดภัยสูงกว่าและมีสิทธิพิเศษสูงกว่า ระบบมากกว่า DONs (แม้ว่าโมเดลความน่าเชื่อถือนี้อาจไม่เป็นจริงเสมอไป แต่ก็ง่ายกว่า เพื่อปรับกลไกผลลัพธ์ให้เข้ากับสถานการณ์ที่ DON มีความปลอดภัยสูงกว่า แพลตฟอร์มมากกว่าในทางกลับกัน) กลยุทธ์การลดความน่าเชื่อถือตามธรรมชาติจึงเกี่ยวข้องกับการดำเนินการตรวจสอบและกลไกความปลอดภัยเมื่อเกิดข้อผิดพลาดใน smart contracts—ไม่ว่าจะในส่วนหน้าของ MAINCHAIN สำหรับ DON หรือโดยตรงใน SC สัญญาที่ขึ้นอยู่กับสัญญา เราเรียกกลไกเหล่านี้ว่า ราวกั้น และแจกแจงสิ่งสำคัญที่สุดบางส่วนไว้ที่นี่: • เซอร์กิตเบรกเกอร์: SC อาจหยุดชั่วคราวหรือหยุดการอัปเดตสถานะเนื่องจากฟังก์ชันอย่างใดอย่างหนึ่งของคุณลักษณะของสถานะการอัปเดตด้วยตนเอง (เช่น ความแปรปรวนขนาดใหญ่ตามลำดับ รายงาน) หรือขึ้นอยู่กับอินพุตอื่น ๆ ตัวอย่างเช่น เซอร์กิตเบรกเกอร์อาจตัดการทำงานเข้าไป กรณีที่ oracle รายงานเปลี่ยนแปลงอย่างไม่น่าเชื่อเมื่อเวลาผ่านไป เซอร์กิตเบรกเกอร์ก็ได้ ยังถูกรายงานโดยชนกลุ่มน้อยสะดุด ดังนั้นเซอร์กิตเบรกเกอร์สามารถป้องกัน DONs ได้ จากการทำรายงานที่ผิดพลาดอย่างร้ายแรง เซอร์กิตเบรกเกอร์สามารถให้เวลาในการพิจารณาการแทรกแซงเพิ่มเติมได้ หรือออกกำลังกาย การแทรกแซงอย่างหนึ่งคือประตูหนีภัย • ช่องหลบหนี: ภายใต้สถานการณ์ที่ไม่พึงประสงค์ ตามที่ระบุโดยกลุ่มผู้ดูแล ผู้ถือ token ในชุมชน หรือหน่วยงานอื่นๆ ของผู้ดูแลผลประโยชน์ สัญญาอาจเรียกใช้ สิ่งอำนวยความสะดวกฉุกเฉินบางครั้งเรียกว่าประตูหนีภัย [163] ฟักหลบหนี ทำให้ SC ปิดตัวลงในลักษณะใดลักษณะหนึ่ง และ/หรือยุติการรอดำเนินการและอาจเป็นไปได้ การทำธุรกรรมในอนาคต ตัวอย่างเช่น อาจคืนเงินที่ถูกดูแลให้กับผู้ใช้ [17])อาจยกเลิกเงื่อนไขสัญญา [162] หรืออาจยกเลิกธุรกรรมที่รอดำเนินการและ/หรือในอนาคต [173] ช่องหนีภัยสามารถใช้งานได้กับสัญญาทุกประเภท ไม่ใช่แค่เพียงเท่านั้น สิ่งหนึ่งที่ต้องอาศัย DON แต่เป็นที่สนใจในฐานะผู้บัฟเฟอร์ที่มีศักยภาพ DON การทำงานผิดพลาด • การเฟลโอเวอร์: ในระบบที่ SC อาศัย DON สำหรับบริการที่จำเป็น ก็เป็นไปได้ที่ SC จะจัดเตรียมกลไกการเฟลโอเวอร์ที่รับรองว่าบริการจะดำเนินต่อไปได้ ในกรณีที่ DON ล้มเหลวหรือมีพฤติกรรมไม่เหมาะสม ตัวอย่างเช่น ใน TEF (มาตรา 6) สัญญา Anchor SCa อาจจัดให้มีอินเทอร์เฟซแบบคู่ทั้งแบบออนไลน์และแบบออนไลน์ รองรับอินเทอร์เฟซการดำเนินการแบบ off-chain สำหรับการดำเนินการที่สำคัญบางอย่าง (เช่น การถอนออก) หรือสำหรับธุรกรรมปกติ โดยมีความล่าช้าที่เหมาะสมเพื่อป้องกันการดำเนินธุรกรรมล่วงหน้าของ DON ในกรณีที่แหล่งข้อมูลลงนามข้อมูล ผู้ใช้สามารถทำได้ ยังจัดทำรายงานไปยัง SCa เมื่อ DON ล้มเหลวในการทำเช่นนั้น หลักฐานการฉ้อโกง ตามที่เสนอสำหรับรูปแบบต่างๆ ของการมองโลกในแง่ดี rollup (ดูหัวข้อ 6.3) มีความคล้ายคลึงกันในด้านรสชาติและเสริมกับกลไกที่เราระบุไว้ข้างต้น พวกเขา ก็มีรูปแบบของการตรวจสอบออนไลน์และการป้องกันความล้มเหลวที่อาจเกิดขึ้นด้วย ส่วนประกอบของระบบออฟเชน 7.4 การกำกับดูแลที่ลดความน่าเชื่อถือ เช่นเดียวกับระบบกระจายอำนาจทั้งหมด เครือข่าย Chainlink ต้องการกลไกการกำกับดูแล เพื่อปรับพารามิเตอร์เมื่อเวลาผ่านไป ตอบสนองต่อเหตุฉุกเฉิน และเป็นแนวทางในการวิวัฒนาการ กลไกบางอย่างเหล่านี้ปัจจุบันอยู่บน MAINCHAIN และอาจดำเนินต่อไป ทำเช่นนั้นแม้จะใช้งาน DONs ก็ตาม ตัวอย่างหนึ่งคือกลไกการชำระเงิน สำหรับผู้ให้บริการโหนด oracle (โหนด DON) DON สัญญาส่วนหน้าบน MAINCHAIN มีกลไกเพิ่มเติม เช่น ราวกั้น ที่อาจต้องปฏิบัติตามเป็นระยะ การปรับเปลี่ยน เราคาดการณ์กลไกการกำกับดูแลอยู่สองประเภท: เชิงวิวัฒนาการและภาวะฉุกเฉิน การปกครองเชิงวิวัฒนาการ: การปรับเปลี่ยนหลายอย่างในระบบนิเวศ Chainlink ได้แก่ เพื่อให้การดำเนินการไม่ใช่เรื่องเร่งด่วน: การปรับปรุงประสิทธิภาพ การปรับปรุงคุณสมบัติ การอัพเกรดความปลอดภัย (ไม่เร่งด่วน) และอื่นๆ เนื่องจาก Chainlink ก้าวไปสู่ผู้เข้าร่วมในการกำกับดูแลมากขึ้นเรื่อยๆ เราจึงคาดหวังว่าจะมีจำนวนมากหรือ การเปลี่ยนแปลงดังกล่าวส่วนใหญ่จะได้รับการให้สัตยาบันโดยชุมชนของ DON เฉพาะที่ได้รับผลกระทบจากสิ่งเหล่านั้น การเปลี่ยนแปลง เราเชื่อว่าในระหว่างนี้และบางทีอาจเป็นกลไกคู่ขนานในท้ายที่สุด ว่าแนวคิดเรื่องสิทธิพิเศษน้อยที่สุดชั่วคราวอาจเป็นวิธีที่มีประโยชน์ในการดำเนินการธรรมาภิบาลเชิงวิวัฒนาการ แนวคิดง่ายๆ ก็คือให้การเปลี่ยนแปลงค่อยๆ นำไปใช้งานเพื่อให้มั่นใจ ชุมชนมีโอกาสตอบสนองต่อพวกเขา เช่น ย้ายไปที่ใหม่ สัญญา MAINCHAIN สามารถถูกจำกัดได้ ดังนั้นสัญญาใหม่จึงต้องถูกปรับใช้ อย่างน้อยสามสิบวันก่อนเปิดใช้งานการกำกับดูแลกรณีฉุกเฉิน: ช่องโหว่ที่สามารถใช้ประโยชน์หรือหาประโยชน์ได้ใน MAINCHAIN สัญญาหรือรูปแบบอื่นๆ ของความมีชีวิตชีวาหรือความล้มเหลวด้านความปลอดภัยอาจต้องมีการแทรกแซงทันทีเพื่อให้แน่ใจว่าจะเกิดผลลัพธ์ที่เป็นหายนะ ความตั้งใจของเราคือการสนับสนุน multisig กลไกการแทรกแซงเพื่อประกันการทุจริตโดยองค์กรใด ๆ ผู้ลงนามจะกระจายไปตามองค์กรต่างๆ รับรองความพร้อมของผู้ลงนามอย่างสม่ำเสมอ และเข้าถึงสายการบังคับบัญชาที่เหมาะสมเพื่ออนุมัติเหตุฉุกเฉินได้อย่างทันท่วงที การเปลี่ยนแปลงอย่างชัดเจนจะต้องมีการวางแผนการปฏิบัติงานอย่างรอบคอบและการทบทวนอย่างสม่ำเสมอ เหล่านี้ ความท้าทายมีความคล้ายคลึงกับความท้าทายที่เกี่ยวข้องกับการทดสอบการตอบสนองต่อเหตุการณ์ด้านความปลอดภัยทางไซเบอร์อื่นๆ ความสามารถ [134] โดยมีความต้องการที่คล้ายกันในการต่อสู้กับปัญหาทั่วไป เช่น การลดความระมัดระวัง [223] การกำกับดูแลของ DONs นั้นแตกต่างจากระบบการกระจายอำนาจจำนวนมากใน ระดับที่เป็นไปได้ของความหลากหลาย DON แต่ละรายการอาจมีแหล่งข้อมูล ปฏิบัติการ ข้อกำหนดระดับบริการที่แตกต่างกัน เช่น เวลาทำงาน และผู้ใช้ เครือข่าย Chainlink กลไกการกำกับดูแลจะต้องมีความยืดหยุ่นเพียงพอที่จะรองรับการเปลี่ยนแปลงดังกล่าว เป้าหมายและพารามิเตอร์การปฏิบัติงาน เรากำลังสำรวจแนวคิดการออกแบบและวางแผนอย่างจริงจัง เผยแพร่งานวิจัยในหัวข้อนี้ในอนาคต 7.5 โครงสร้างพื้นฐานคีย์สาธารณะ ด้วยการกระจายอำนาจแบบก้าวหน้า ความต้องการการระบุตัวตนที่แข็งแกร่งของ ผู้เข้าร่วมเครือข่าย รวมถึง DON โหนด โดยเฉพาะอย่างยิ่ง Chainlink ต้องมีความแข็งแกร่ง โครงสร้างพื้นฐานคีย์สาธารณะ (PKI) PKI คือระบบที่ผูกคีย์เข้ากับข้อมูลระบุตัวตน สำหรับ ตัวอย่างเช่น PKI อยู่ภายใต้ระบบการเชื่อมต่อที่ปลอดภัย (TLS) ของอินเทอร์เน็ต: เมื่อใด คุณเชื่อมต่อกับเว็บไซต์ผ่าน HTTPS (เช่น https://www.chainlinklabs.com) และ lock ปรากฏในเบราว์เซอร์ของคุณ ซึ่งหมายความว่ามีรหัสสาธารณะของเจ้าของโดเมน ถูกผูกมัดกับเจ้าของโดยผู้มีอำนาจ - โดยเฉพาะผ่านลายเซ็นดิจิทัลใน ใบรับรองที่เรียกว่า ระบบลำดับชั้นของหน่วยงานออกใบรับรอง (CAs) ซึ่งหน่วยงานระดับรากระดับบนสุดเดินสายเข้ากับเบราว์เซอร์ยอดนิยม ช่วยให้แน่ใจว่าใบรับรอง จะออกให้เฉพาะเจ้าของโดเมนที่ถูกต้องตามกฎหมายเท่านั้น เราคาดหวังว่า Chainlink จะใช้บริการชื่อแบบกระจายอำนาจในที่สุด เริ่มแรก Ethereum Name Service (ENS) [22] ซึ่งเป็นรากฐานสำหรับ PKI ของเรา เช่น ชื่อของมันบ่งบอกว่า ENS นั้นคล้ายคลึงกับ DNS ซึ่งเป็นระบบชื่อโดเมนที่ทำแผนที่ ชื่อโดเมน (มนุษย์สามารถอ่านได้) ไปยังที่อยู่ IP บนอินเทอร์เน็ต อย่างไรก็ตาม ENS จะจับคู่ชื่อ Ethereum ที่มนุษย์สามารถอ่านได้กับที่อยู่ blockchain แทน เพราะอีเอ็นส์ ดำเนินการบน Ethereum blockchain ยกเว้นการประนีประนอมที่สำคัญ การดัดแปลง โดยหลักการแล้วเนมสเปซนั้นยากพอๆ กับการดัดแปลงสัญญาที่ดูแลมัน และ/หรือ blockchain ที่สำคัญ (ในทางตรงกันข้าม DNS มีช่องโหว่ในอดีต การปลอมแปลง การจี้ และการโจมตีอื่นๆ) เราได้ลงทะเบียน data.eth กับ ENS บนเมนเน็ต Ethereum และตั้งใจที่จะทำเช่นนั้น สร้างเป็นเนมสเปซรูทซึ่งมีข้อมูลประจำตัวของบริการข้อมูล oracle และ มีเอนทิตีเครือข่าย Chainlink อื่นๆ อยู่ โดเมนใน ENS เป็นแบบลำดับชั้น ซึ่งหมายความว่าแต่ละโดเมนอาจมีการอ้างอิง ไปยังชื่ออื่นภายใต้ชื่อนั้น โดเมนย่อยใน ENS สามารถใช้เป็นวิธีการจัดระเบียบและมอบความไว้วางใจ บทบาทหลักของ data.eth คือการให้บริการไดเรกทอรีออนไลน์สำหรับ ฟีดข้อมูล ตามเนื้อผ้า นักพัฒนาและผู้ใช้ oracles ได้ใช้แหล่งที่มาของเครือข่าย (เช่น เว็บไซต์ เช่น docs.chain.link หรือ data.chain.link หรือเครือข่ายโซเชียล เช่น Twitter) เพื่อเผยแพร่และรับที่อยู่ฟีดข้อมูล oracle (เช่น ราคา ETH-USD ฟีด) ด้วยเนมสเปซรูทที่น่าเชื่อถือสูง เช่น data.eth คุณสามารถสร้างการแมปของ eth-usd.data.eth กับที่อยู่ smart contract แทน เช่น ที่อยู่ smart contract ของเครือข่ายออนไลน์ oracle ผู้รวบรวมสำหรับฟีดราคา ETH-USD นี้จะ สร้างเส้นทางที่ปลอดภัยสำหรับทุกคนในการอ้างถึง blockchain ว่าเป็นแหล่งที่มาของความจริง ฟีดข้อมูลของคู่ราคา/ชื่อนั้น (ETH-USD) ดังนั้นการใช้ ENS ดังกล่าว ตระหนักถึงประโยชน์สองประการที่ไม่มีอยู่ในแหล่งข้อมูลนอกสายโซ่: • การรักษาความปลอดภัยที่แข็งแกร่ง: การเปลี่ยนแปลงและการอัปเดตทั้งหมดในโดเมนจะถูกบันทึกอย่างไม่เปลี่ยนแปลง และปลอดภัยด้วยการเข้ารหัส ตรงข้ามกับที่อยู่ข้อความบนเว็บไซต์ ซึ่ง เพลิดเพลินไปกับคุณสมบัติด้านความปลอดภัยทั้งสองนี้ • การเผยแพร่ออนไลน์แบบอัตโนมัติ: การอัปเดตที่อยู่พื้นฐานของฟีดข้อมูล smart contract สามารถทริกเกอร์การแจ้งเตือนที่เผยแพร่ไปยังสมาร์ทที่ขึ้นต่อกัน สัญญาและสามารถอัปเดตสัญญาที่ขึ้นอยู่กับสัญญาโดยอัตโนมัติได้ ที่อยู่ใหม่13 อย่างไรก็ตาม เนมสเปซเช่น ENS จะไม่ตรวจสอบความเป็นเจ้าของที่ถูกต้องตามกฎหมายโดยอัตโนมัติ ของชื่อที่ยืนยัน ดังนั้น ตัวอย่างเช่น ถ้าเนมสเปซมีรายการอยู่ด้วย ⟨“บริษัท Acme Oracle Node”, addr⟩, จากนั้นผู้ใช้จะได้รับการรับประกันว่า addr เป็นของผู้อ้างสิทธิ์ในชื่อ Acme Oracle Node Co. โดยไม่มีกลไกเพิ่มเติมเกี่ยวกับการดูแลระบบเนมสเปซ อย่างไรก็ตาม เธอไม่ได้รับการประกันว่าชื่อนั้นเป็นของนิติบุคคลโดยชอบด้วยกฎหมาย เรียกว่า Acme Oracle Node Co. ในโลกแห่งความเป็นจริงที่มีความหมาย แนวทางของเราในการตรวจสอบความถูกต้องของชื่อ กล่าวคือ การรับรองความเป็นเจ้าของโดยหน่วยงานในโลกแห่งความจริงที่ถูกต้องตามกฎหมายนั้น ขึ้นอยู่กับองค์ประกอบหลายประการ วันนี้ Chainlink ห้องทดลอง ทำหน้าที่เป็น CA สำหรับเครือข่าย Chainlink อย่างมีประสิทธิภาพ ในขณะที่ Chainlink ห้องทดลองจะดำเนินต่อไป เพื่อตรวจสอบความถูกต้องของชื่อ PKI ของเราจะพัฒนาเป็นรูปแบบการกระจายอำนาจมากขึ้นในสองวิธี: • โมเดล Web-of-trust: การกระจายอำนาจที่เหมือนกันของ PKI แบบลำดับชั้นมักถูกเรียกว่า web-of-trust14 มีการเสนอรูปแบบต่างๆ ตั้งแต่ปี 1990 เช่น [98] และนักวิจัยจำนวนหนึ่งได้สังเกตว่า blockchains สามารถอำนวยความสะดวกในการใช้แนวคิดนี้ได้ เช่น [227] โดยการบันทึกใบรับรองในความสอดคล้องทั่วโลก บัญชีแยกประเภท เรากำลังสำรวจรูปแบบต่างๆ ของแบบจำลองนี้เพื่อตรวจสอบความถูกต้องของตัวตนของเอนทิตี ในเครือข่าย Chainlink ในลักษณะที่มีการกระจายอำนาจมากขึ้น 13สัญญาที่ขึ้นอยู่กับสัญญาอาจรวมการหน่วงเวลาที่กำหนดไว้ล่วงหน้าเพื่อให้สามารถตรวจสอบด้วยตนเองได้ และการแทรกแซงโดยผู้บริหารตามสัญญา 14คำศัพท์ที่กำหนดโดย Phil Zimmermann สำหรับ PGP [238]• การเชื่อมโยงกับการตรวจสอบความถูกต้องของข้อมูล: ปัจจุบัน ข้อมูลประสิทธิภาพของโหนด oracle จำนวนมากสามารถมองเห็นได้แบบออนไลน์ และเชื่อมโยงกับที่อยู่ของโหนดแบบถาวร ข้อมูลดังกล่าวอาจถูกมองว่าเป็นการเสริมสร้างเอกลักษณ์ใน PKI โดยการจัดเตรียมหลักฐานทางประวัติศาสตร์ของการมีส่วนร่วม (เชื่อถือได้) ในเครือข่าย นอกจากนี้ยังมีเครื่องมือ สำหรับการระบุตัวตนแบบกระจายอำนาจตาม DECO และ Town Crier [160] เปิดใช้งานโหนด เพื่อสะสมข้อมูลประจำตัวที่ได้รับจากข้อมูลในโลกแห่งความเป็นจริง เป็นเพียงตัวอย่างเดียวก ตัวดำเนินการโหนดสามารถแนบข้อมูลประจำตัวกับข้อมูลประจำตัว PKI ที่พิสูจน์การครอบครองได้ ของการจัดอันดับ Dun และ Bradstreet แบบฟอร์มการตรวจสอบเพิ่มเติมเหล่านี้สามารถทำได้ เสริม staking ในการสร้างความมั่นใจในความปลอดภัยของเครือข่าย โหนด oracle ที่มีเอกลักษณ์เฉพาะตัวในโลกแห่งความเป็นจริงอาจถูกมองว่ามีส่วนได้ส่วนเสีย ในระบบที่มาจากชื่อเสียงของมัน (ดูหัวข้อ 4.3 และหัวข้อ 9.6.3) ข้อกำหนดสุดท้ายสำหรับ Chainlink PKI คือการบูตสแตรปที่ปลอดภัย กล่าวคือ อย่างปลอดภัย การเผยแพร่ชื่อรูทสำหรับเครือข่าย Chainlink ซึ่งปัจจุบันคือ data.eth (analogous ไปจนถึงการเดินสายโดเมนระดับบนสุดในเบราว์เซอร์) กล่าวอีกนัยหนึ่ง Chainlink ผู้ใช้ทำอย่างไร พิจารณาว่า data.eth เป็นโดเมนระดับบนสุดที่เกี่ยวข้องกับ Chainlink โครงการ? วิธีแก้ไขปัญหานี้สำหรับเครือข่าย Chainlink เป็นแบบหลายทางและ อาจเกี่ยวข้องกับ: • การเพิ่มบันทึก TXT [224] ไปยังบันทึกโดเมนของเราสำหรับ chain.link ที่ระบุ data.eth เป็นโดเมนรากสำหรับระบบนิเวศ Chainlink (Chainlink จึงใช้ประโยชน์จาก PKI สำหรับโดเมนอินเทอร์เน็ตโดยปริยายเพื่อตรวจสอบความถูกต้องของโดเมน ENS ราก) • เชื่อมโยงไปยัง data.eth จากเว็บไซต์ที่มีอยู่ของ Chainlink เช่น จาก https://docs.chain.link. (การใช้ PKI โดยนัยอีกครั้งสำหรับโดเมนอินเทอร์เน็ต) • ทำให้การใช้ data.eth เป็นที่รู้จักผ่านเอกสารต่างๆ รวมถึง whitepaper นี้ด้วย • การโพสต์ data.eth แบบสาธารณะบนช่องทางโซเชียลมีเดียของเรา เช่น Twitter และ บล็อก Chainlink [18] • วาง LINK จำนวนมากภายใต้การควบคุมของที่อยู่ผู้ลงทะเบียนเดียวกัน เป็น data.eth

DON ข้อควรพิจารณาในการปรับใช้

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

8.1 แนวทางการเปิดตัว เอกสารนี้วางวิสัยทัศน์ที่ทะเยอทะยานของฟังก์ชัน Chainlink ขั้นสูงที่มี การตระหนักรู้จะต้องมีวิธีแก้ไขปัญหาความท้าทายต่างๆ มากมายระหว่างทาง เอกสารไวท์เปเปอร์นี้ ระบุความท้าทายบางอย่างได้ แต่สิ่งที่ไม่คาดคิดก็จะเกิดขึ้นอย่างแน่นอน เราวางแผนที่จะนำองค์ประกอบของวิสัยทัศน์นี้ไปใช้แบบค่อยเป็นค่อยไป ระยะเวลาที่ขยายออกไป เราคาดหวังไว้ว่า DONs จะเปิดตัวด้วย การสนับสนุนส่วนประกอบที่สร้างไว้ล่วงหน้าเฉพาะที่สร้างขึ้นโดยทีมงานภายใน Chainlink ชุมชน จุดประสงค์คือการใช้ DONs ในวงกว้าง เช่น ความสามารถในการ เปิดตัวปฏิบัติการตามอำเภอใจ จะเห็นการสนับสนุนในภายหลัง เหตุผลหนึ่งที่ต้องระมัดระวังก็คือองค์ประกอบของ smart contracts อาจมีผลข้างเคียงที่ซับซ้อน โดยไม่ได้ตั้งใจ และเป็นอันตราย ดังเช่นการโจมตีแบบ Flash-loan ที่เกิดขึ้นเมื่อเร็วๆ นี้ เช่นที่แสดง [127, 189] ในทำนองเดียวกัน องค์ประกอบของ smart contracts อะแดปเตอร์ และ โปรแกรมปฏิบัติการจะต้องได้รับการดูแลเป็นพิเศษ ในการปรับใช้ DONs ครั้งแรกของเรา เราวางแผนที่จะรวมเฉพาะชุดโปรแกรมปฏิบัติการและอะแดปเตอร์ที่สร้างไว้ล่วงหน้าเท่านั้น ซึ่งจะช่วยให้สามารถศึกษาความมั่นคงขององค์ประกอบได้ ของฟังก์ชันการทำงานเหล่านี้โดยใช้วิธีการที่เป็นทางการ [46, 170] และแนวทางอื่นๆ มันจะ ยังทำให้การกำหนดราคาง่ายขึ้น: การกำหนดราคาด้านฟังก์ชันการทำงานสามารถกำหนดได้โดยโหนด DON บนพื้นฐานด้านฟังก์ชันการทำงาน แทนที่จะใช้การวัดแสงทั่วไป ซึ่งเป็นแนวทางที่นำมาใช้ ใน เช่น [156] นอกจากนี้เรายังคาดหวังให้ชุมชน Chainlink มีส่วนร่วมในการสร้างสรรค์นี้ ของเทมเพลตเพิ่มเติม การรวมอะแดปเตอร์และโปรแกรมปฏิบัติการต่างๆ เข้าด้วยกันเพิ่มมากขึ้น บริการกระจายอำนาจที่เป็นประโยชน์ซึ่งสามารถดำเนินการโดยบุคคลนับร้อยหรือนับพันราย DONส. นอกจากนี้ วิธีการนี้สามารถช่วยป้องกันการขยายตัวของรัฐได้ เช่น ความจำเป็นสำหรับ DON โหนดเพื่อรักษาสถานะที่ไม่สามารถทำงานได้ในหน่วยความจำการทำงาน ปัญหานี้คือ เกิดขึ้นแล้วใน blockchains ที่ไม่ได้รับอนุญาต ทำให้เกิดแนวทางเช่น "ไร้สัญชาติ ลูกค้า” (ดู เช่น [206]) อาจรุนแรงกว่าในระบบปริมาณงานที่สูงขึ้นซึ่งเป็นแรงจูงใจ แนวทางที่ DON ปรับใช้เฉพาะไฟล์ปฏิบัติการที่ปรับขนาดตามสถานะเท่านั้น ในขณะที่ DONs พัฒนาและเติบโตเต็มที่ และรวมถึงราวกั้นที่แข็งแกร่ง ตามที่กล่าวไว้ในส่วนที่ 7 กลไกการรักษาความปลอดภัยทางเศรษฐกิจแบบเข้ารหัสลับและตามชื่อเสียงตามที่กล่าวไว้ในส่วนที่ 9 และคุณลักษณะอื่น ๆ ที่ให้การรับประกันในระดับสูงสำหรับผู้ใช้ DON เรา ยังคาดหวังที่จะพัฒนากรอบการทำงานและเครื่องมือเพื่ออำนวยความสะดวกในการเปิดตัวและใช้งานในวงกว้าง DONs โดยชุมชน ตามหลักการแล้ว เครื่องมือเหล่านี้จะช่วยให้สามารถรวบรวมตัวดำเนินการโหนดได้ เพื่อมารวมกันเป็นเครือข่าย oracle และเปิดตัว DONs ของตัวเองโดยไม่ได้รับอนุญาต หรือลักษณะการบริการตนเอง ซึ่งหมายความว่าพวกเขาสามารถดำเนินการได้เพียงฝ่ายเดียว 8.2 ไดนามิก DON การเป็นสมาชิก ชุดของโหนดที่ทำงาน DON ที่กำหนด อาจเปลี่ยนแปลงเมื่อเวลาผ่านไป มีสองแนวทาง สู่การจัดการคีย์สำหรับ skL ที่ได้รับการเป็นสมาชิกแบบไดนามิกใน O สิ่งแรกคือการอัปเดตหุ้นของ skL ที่ถือโดยโหนดเมื่อมีการเปลี่ยนแปลงสมาชิก ในขณะที่รักษา pkL ไม่เปลี่ยนแปลง แนวทางนี้ ซึ่งมีการสำรวจใน [41, 161, 198] มีข้อดี ไม่ต้องการให้ฝ่ายที่เกี่ยวข้องอัปเดต pkLเทคนิคคลาสสิกของการแบ่งปันต่อซึ่งเปิดตัวใน [122] มีหลักการง่ายๆ และวิธีการที่มีประสิทธิภาพในการรับทราบการอัปเดตการแชร์ดังกล่าว ช่วยให้สามารถถ่ายโอนความลับได้ ระหว่างหนึ่งชุดของโหนด O(1) และวินาที ซึ่งอาจตัดกันหนึ่ง O(2) ในเรื่องนี้ เข้าใกล้แต่ละโหนด O(1) ฉัน ดำเนินการแบ่งปันความลับ (k(2), n(2)) ของการแบ่งปันความลับข้าม โหนดใน O(2) สำหรับ n(2) = |O(2)| และเกณฑ์ที่ต้องการ (อาจเป็นใหม่) k(2) แผนการแบ่งปันความลับที่ตรวจสอบได้ (VSS) ต่างๆ [108] สามารถให้ความปลอดภัยจากฝ่ายตรงข้ามที่ ทำให้โหนดเสียหายอย่างแข็งขัน กล่าวคือ นำเสนอพฤติกรรมที่เป็นอันตรายในโปรโตคอล เทคนิคใน [161] มุ่งหวังที่จะทำเช่นนั้นในขณะที่ลดความซับซ้อนและการให้บริการในการสื่อสาร ความยืดหยุ่นต่อความล้มเหลวในสมมติฐานความแข็งของการเข้ารหัส วิธีที่สองคือการอัปเดตคีย์บัญชีแยกประเภท pkL สิ่งนี้มีประโยชน์ในการส่งต่อ ความปลอดภัย: การประนีประนอมของหุ้นเก่าของ pkL (เช่น โหนดคณะกรรมการเดิม) จะไม่เกิดขึ้น ส่งผลให้เกิดการประนีประนอมของคีย์ปัจจุบัน อย่างไรก็ตาม การอัพเดต pkL มีข้อบกพร่องสองประการ: (1) ข้อมูลที่เข้ารหัสภายใต้ pkL จะต้องได้รับการเข้ารหัสอีกครั้งระหว่างการรีเฟรชคีย์ และ (2) การอัปเดตที่สำคัญจำเป็นต้องเผยแพร่ไปยังฝ่ายที่เกี่ยวข้อง เราตั้งใจที่จะสำรวจทั้งสองแนวทาง เช่นเดียวกับการผสมข้ามพันธุ์ของทั้งสองวิธี 8.3 DON ความรับผิดชอบ เช่นเดียวกับเครือข่าย Chainlink oracle ที่มีอยู่ DONs จะมีกลไกสำหรับความรับผิดชอบ เช่น การบันทึก การตรวจสอบ และการบังคับใช้พฤติกรรมของโหนดที่ถูกต้อง DONs จะมี ความจุข้อมูลที่สำคัญมากกว่า blockchains ที่ไม่ได้รับอนุญาตที่มีอยู่มากมาย โดยเฉพาะอย่างยิ่งเมื่อพิจารณาถึงความสามารถในการเชื่อมต่อกับที่จัดเก็บข้อมูลแบบกระจายอำนาจภายนอก ด้วยเหตุนี้ พวกเขาจึงสามารถบันทึกประวัติประสิทธิภาพของโหนดได้อย่างละเอียด เพื่อให้สามารถบันทึกได้ กลไกความรับผิดชอบที่ละเอียดยิ่งขึ้น ตัวอย่างเช่น การคำนวณแบบออฟเชนของ ราคาสินทรัพย์อาจเกี่ยวข้องกับข้อมูลนำเข้าที่ถูกละทิ้งก่อนที่จะส่งผลลัพธ์ค่ามัธยฐาน โซ่ ใน DON ผลลัพธ์ระดับกลางเหล่านี้สามารถถูกบันทึกได้ พฤติกรรมที่ไม่เหมาะสมหรือประสิทธิภาพที่ล่วงไปโดยแต่ละโหนดใน DON จึงสามารถแก้ไขได้หรือถูกลงโทษใน DON ในลักษณะที่ละเอียด เราได้หารือเพิ่มเติมเกี่ยวกับวิธีการสร้าง ราวกั้นในส่วนที่ 7.3 ที่ระบุถึงผลกระทบเฉพาะสัญญาจากความล้มเหลวของระบบ อย่างไรก็ตาม การมีกลไกป้องกันความผิดพลาดสำหรับ DONs เองก็เป็นสิ่งสำคัญเช่นกัน กล่าวคือ การป้องกันความล้มเหลวของระบบ DON ที่อาจเกิดภัยพิบัติ โดยเฉพาะอย่างยิ่ง ความล้มเหลวในการฟอร์กกิ้ง / การบิดเบือนและข้อตกลงระดับบริการ (SLA) ดังที่เราอธิบายไปแล้ว การฟอร์ก / การคลุมเครือ: เนื่องจากโหนดที่มีข้อบกพร่องจำนวนมากเพียงพอ DON สามารถแยกได้ หรือเปรียบเทียบ โดยสร้างบล็อกหรือลำดับของบล็อกที่แตกต่างกันและไม่สอดคล้องกันสองบล็อกใน L เนื่องจาก DON ลงนามแบบดิจิทัลในเนื้อหาของ L จึงเป็นไปได้ที่จะใช้ประโยชน์จาก main chain MAINCHAIN เพื่อป้องกันและ/หรือลงโทษความคลุมเครือ DON สามารถระบุสถานะจุดตรวจสอบจาก L เป็นระยะๆ ในสัญญาการตรวจสอบบน MAINCHAIN หากสถานะในอนาคตเบี่ยงเบนไปจากสถานะจุดตรวจสอบ ผู้ใช้ / ผู้ตรวจสอบสามารถแสดงหลักฐานได้ ของการประพฤติมิชอบต่อสัญญาการตรวจสอบนี้ หลักฐานดังกล่าวสามารถใช้เพื่อสร้างการแจ้งเตือนได้ หรือลงโทษ DON โหนดด้วยการตัดทอนในสัญญา แนวทางหลังนี้แนะนำ ปัญหาการออกแบบสิ่งจูงใจที่คล้ายกับปัญหาสำหรับฟีด oracle เฉพาะเจาะจง และสามารถสร้างต่อยอดได้ งานของเราตามที่อธิบายไว้ในส่วนที่ 9การบังคับใช้ข้อตกลงระดับการให้บริการ: ในขณะที่ DONs ไม่จำเป็นต้องมีความหมาย ทำงานอย่างไม่มีกำหนด สิ่งสำคัญคือต้องปฏิบัติตามข้อตกลงระดับการให้บริการ (SLA) กับผู้ใช้ของพวกเขา การบังคับใช้ SLA ขั้นพื้นฐานสามารถทำได้บนห่วงโซ่หลัก ตัวอย่างเช่น โหนด DON อาจมุ่งมั่นที่จะรักษา DON ไว้จนถึงวันที่กำหนด หรือแจ้งล่วงหน้าเกี่ยวกับการยุติการให้บริการ (เช่น การแจ้งเตือนสามเดือน) มีสัญญาอยู่ MAINCHAIN สามารถบังคับใช้ SLA ทางเศรษฐกิจเข้ารหัสขั้นพื้นฐานได้ ตัวอย่างเช่น สัญญา SLA สามารถลดเงินที่ฝากไว้ DON ได้ หากจุดตรวจสอบ ไม่ได้ระบุไว้ตามระยะเวลาที่กำหนด ผู้ใช้สามารถฝากเงินและท้าทาย DON เพื่อพิสูจน์ว่าจุดตรวจแสดงถึงลำดับของบล็อกที่ถูกต้องอย่างถูกต้อง (ในลักษณะ คล้ายคลึงกับเช่น [141]) แน่นอนว่าการผลิตแบบบล็อกไม่เท่ากับธุรกรรม การประมวลผล แต่สัญญา SLA ยังสามารถให้บริการเพื่อบังคับใช้ในภายหลังได้ ตัวอย่างเช่นใน FSS เวอร์ชันที่เข้ากันได้กับระบบเดิม ซึ่งธุรกรรมถูกดึงมาจาก mempool (ดูหัวข้อ 5.2) ในที่สุดธุรกรรมก็จะถูกขุดและวางบนลูกโซ่ ผู้ใช้ สามารถพิสูจน์ DON การกระทำผิดโดยจัดทำสัญญา SLA ด้วยธุรกรรมที่ ถูกขุดขึ้นมาแต่ไม่ได้ถูกส่งโดย DON เพื่อการประมวลผลโดยสัญญาเป้าหมาย ภายในระยะเวลาที่เหมาะสม15 นอกจากนี้ยังสามารถพิสูจน์การมีอยู่ของและลงโทษ SLA ที่มีรายละเอียดมากขึ้นได้อีกด้วย ความล้มเหลว รวมถึงข้อผิดพลาดในการคำนวณโดยใช้โปรแกรมปฏิบัติการ (ผ่าน เช่น กลไก เพื่อพิสูจน์ธุรกรรมสถานะลูกโซ่ที่ถูกต้องตามที่ระบุไว้ในส่วน 6.3) หรือความล้มเหลวในการดำเนินการ ไฟล์ปฏิบัติการตามตัวเริ่มต้นที่มองเห็นได้บน DON ไม่สามารถถ่ายทอดข้อมูลบน DON ไปยัง MAINCHAIN อย่างทันท่วงที เป็นต้น

เศรษฐศาสตร์และเศรษฐศาสตร์เข้ารหัส

เพื่อให้เครือข่าย Chainlink บรรลุการรักษาความปลอดภัยที่แข็งแกร่งภายในโมเดลความน่าเชื่อถือแบบกระจายอำนาจ จำเป็นอย่างยิ่งที่โหนดจะต้องแสดงพฤติกรรมที่ถูกต้องร่วมกัน ซึ่งหมายความว่าโหนดเหล่านั้นจะปฏิบัติตาม ส่วนใหญ่แล้วจะใช้โปรโตคอล DON อย่างแน่นอน ในส่วนนี้ เราจะหารือเกี่ยวกับแนวทางต่างๆ เพื่อช่วยบังคับใช้พฤติกรรมดังกล่าวด้วยสิ่งจูงใจทางเศรษฐกิจหรือที่เรียกว่า cryptoeconomic แรงจูงใจ สิ่งจูงใจเหล่านี้แบ่งออกเป็นสองประเภท: ชัดเจนและโดยปริยาย, ตระหนัก ตามลำดับผ่าน staking และโอกาสค่าธรรมเนียมในอนาคต (FFO) การปักหลัก: การปักหลักใน Chainlink เช่นเดียวกับในระบบ blockchain อื่นๆ เกี่ยวข้องกับผู้เข้าร่วมเครือข่าย เช่น โหนด oracle ซึ่งฝากเงินที่ถูกล็อคไว้ในรูปแบบของ LINK tokens เหล่านี้ กองทุนซึ่งเราเรียกว่าสัดส่วนการถือหุ้นหรือสัดส่วนการถือหุ้นที่ชัดเจนเป็นสิ่งจูงใจที่ชัดเจน พวกเขา อาจถูกริบเมื่อโหนดล้มเหลวหรือทำงานผิดปกติ ในบริบท blockchain ขั้นตอนนี้มักเรียกว่าการเฉือน อย่างไรก็ตาม การปักหลักโดยโหนด oracle ใน Chainlink นั้นแตกต่างโดยพื้นฐานจาก staking โดย validators ใน blockchains โดยไม่ได้รับอนุญาต ผู้ตรวจสอบความถูกต้องอาจประพฤติตนไม่เหมาะสมโดยการหลีกเลี่ยงหรือสั่งธุรกรรมที่ขัดแย้งกัน โปรโตคอลฉันทามติพื้นฐานใน 15เนื่องจากผู้ใช้สามารถแทนที่ธุรกรรมใน mempool ได้ จึงจำเป็นต้องมีการดูแลเพื่อให้แน่ใจว่าสอดคล้องกันที่ถูกต้องระหว่างธุรกรรมที่ขุดและ DON ที่ส่งอย่างไรก็ตาม blockchain ที่ไม่ได้รับอนุญาตนั้นใช้กฎการตรวจสอบความถูกต้องของบล็อกแบบแข็งและรวดเร็วและการเข้ารหัสลับเบื้องต้นเพื่อป้องกันไม่ให้ validators สร้างบล็อกที่ไม่ถูกต้อง ในทางตรงกันข้าม การป้องกันทางโปรแกรมไม่สามารถป้องกันการโกงเครือข่าย oracle ในการสร้างได้ รายงานไม่ถูกต้อง เหตุผลคือความแตกต่างที่สำคัญระหว่างระบบทั้งสองประเภท: การตรวจสอบธุรกรรมใน blockchains เป็นคุณสมบัติของความสอดคล้องภายใน ในขณะที่ความถูกต้อง ของ oracle รายงานบน blockchain เป็นคุณสมบัติของข้อมูลภายนอก เช่น ข้อมูลแบบออฟเชน เราได้ออกแบบกลไก staking เบื้องต้นสำหรับเครือข่าย Chainlink ที่ใช้ บนโปรโตคอลแบบโต้ตอบระหว่างโหนด oracle ที่อาจใช้ประโยชน์จากข้อมูลภายนอก นี้ กลไกสร้างแรงจูงใจทางการเงินสำหรับพฤติกรรมที่ถูกต้องโดยใช้รางวัลที่ชัดเจนและ บทลงโทษ (เฉือน) เนื่องจากกลไกนี้มีความประหยัด จึงได้รับการออกแบบมาเพื่อป้องกันโหนด การทุจริตโดยฝ่ายตรงข้ามที่ใช้ทรัพยากรทางการเงินในการทำให้โหนดเสียหายโดยวิธีการ การติดสินบน (ปฏิปักษ์ดังกล่าวเป็นเรื่องกว้างใหญ่ และขยายออกไป เช่น ไปยังโหนดที่ให้ความร่วมมือด้วย สกัดคุณค่าจากพฤติกรรมที่ไม่เหมาะสมร่วมกันของพวกเขา) กลไก Chainlink staking ที่เราออกแบบนั้นมีประสิทธิภาพและแปลกใหม่ features.16 คุณลักษณะหลักดังกล่าวคือการกระทบแบบซุปเปอร์เชิงเส้น staking (โดยเฉพาะ สมการกำลังสอง) ฝ่ายตรงข้ามจะต้องมีทรัพยากรมากเกินกว่าเงินทุนที่โหนดฝากไว้ เพื่อล้มล้างกลไก กลไก staking ของเรายังให้การป้องกันศัตรูที่แข็งแกร่งกว่าที่เคยพิจารณาในระบบที่คล้ายกัน กล่าวคือ ศัตรูที่สามารถสร้างเงื่อนไขการติดสินบนตามพฤติกรรมในอนาคตของโหนดได้ นอกจากนี้ เรายังพูดคุยถึงวิธีที่เครื่องมือ Chainlink เช่น DECO สามารถช่วยเสริมความแข็งแกร่งให้กับ staking ของเราได้อย่างไร กลไกโดยอำนวยความสะดวกในการพิจารณาตัดสินที่ถูกต้องในกรณีที่พฤติกรรมของโหนดผิดพลาด โอกาสค่าธรรมเนียมในอนาคต (FFO): blockchains ไม่ได้รับอนุญาต—ของ PoW ทั้งสอง และความหลากหลายของ PoS—ทุกวันนี้พึ่งพาอย่างยิ่งกับสิ่งที่เราเรียกว่าสิ่งจูงใจโดยนัย เหล่านี้คือ สิ่งจูงใจทางเศรษฐกิจสำหรับพฤติกรรมที่ซื่อสัตย์ซึ่งไม่ได้มาจากรางวัลที่ชัดเจน แต่ จากการเข้าร่วมแพลตฟอร์มนั่นเอง ตัวอย่างเช่น ชุมชนนักขุด Bitcoin ได้รับแรงจูงใจจากการโจมตีที่เพิ่มขึ้น 51% โดยมีความเสี่ยงที่จะบ่อนทำลายความเชื่อมั่นใน Bitcoin ทำให้คุณค่าของมันตกต่ำ และส่งผลให้คุณค่าของกลุ่มของพวกเขาลดลง การลงทุนในโครงสร้างพื้นฐานการขุด [150] เครือข่าย Chainlink ได้รับประโยชน์จากสิ่งจูงใจโดยนัยที่คล้ายกันที่เราอ้างถึง เป็นโอกาสค่าธรรมเนียมในอนาคต (FFO) โหนด Oracle ที่มีประวัติประสิทธิภาพที่แข็งแกร่งหรือ ชื่อเสียงดึงดูดค่าธรรมเนียมจากผู้ใช้ พฤติกรรมที่ไม่เหมาะสมโดยโหนด oracle เป็นอันตรายต่ออนาคต การชำระค่าธรรมเนียมและลงโทษโหนดด้วยค่าเสียโอกาสในแง่ของศักยภาพ รายได้ที่ได้รับจากการเข้าร่วมเครือข่าย โดยการเปรียบเทียบกับส่วนได้ส่วนเสียที่ชัดเจน FFO อาจถูกมองว่าเป็นรูปแบบหนึ่งของการมีส่วนร่วมโดยนัย ซึ่งเป็นสิ่งจูงใจสำหรับพฤติกรรมที่ซื่อสัตย์เช่นนั้น มาจากผลประโยชน์ร่วมกันของการรักษาความเชื่อมั่นในแพลตฟอร์มที่ ธุรกิจของผู้ให้บริการโหนดขึ้นอยู่กับประสิทธิภาพเชิงบวกและชื่อเสียงของ เครือข่าย สิ่งจูงใจนี้มีอยู่ในเครือข่าย Chainlink แต่ไม่ได้แสดงไว้อย่างชัดเจน โปรโตคอล ใน Bitcoin การรักษามูลค่าของการดำเนินการขุดตามที่กล่าวไว้ข้างต้น 16กลไก staking ที่เราอธิบายไว้ ณ ที่นี้ปัจจุบันมีจุดมุ่งหมายเพื่อบังคับใช้การส่งรายงานที่ถูกต้องเท่านั้น โดย oracle เครือข่าย เราคาดหวังในงานในอนาคตที่จะขยายออกไปเพื่อให้แน่ใจว่ามีการดำเนินการที่ถูกต้องในหลาย ๆ ด้าน ฟังก์ชันอื่นๆ DONs จะมีให้ในทำนองเดียวกันอาจถูกมองว่าเป็นรูปแบบหนึ่งของการเดิมพันโดยนัย เราเน้นย้ำว่า FFO มีอยู่แล้วใน Chainlink และช่วยรักษาความปลอดภัยเครือข่าย วันนี้ การสนับสนุนหลักของเราในการพัฒนาต่อไปของ Chainlink จะเป็นแนวทางที่มีหลักการและขับเคลื่อนด้วยประสบการณ์ในการประเมินสิ่งจูงใจโดยนัย เช่น FFO ผ่าน สิ่งที่เราเรียกว่ากรอบการทำงานโดยนัย-แรงจูงใจ (IIF) เพื่อประมาณปริมาณเช่น โอกาสค่าธรรมเนียมในอนาคตของโหนด IIF จะดึงอย่างต่อเนื่องบนที่ครอบคลุม ข้อมูลประสิทธิภาพและการชำระเงินที่รวบรวมโดยเครือข่าย Chainlink ประมาณการดังกล่าว จะเปิดใช้งานการกำหนดพารามิเตอร์ตาม IIF ของระบบ staking ที่สะท้อนถึงสิ่งจูงใจของโหนด มีความแม่นยำมากกว่าแบบจำลองการศึกษาสำนึกและ/หรือแบบคงที่ในปัจจุบัน เพื่อสรุป แรงจูงใจทางเศรษฐกิจหลักสองประการสำหรับโหนด oracle ที่ถูกต้อง พฤติกรรมในเครือข่าย Chainlink ที่กำลังพัฒนาจะเป็น: • การปักหลัก (เดิมพันที่ฝาก) โอ แรงจูงใจที่ชัดเจน • โอกาสค่าธรรมเนียมในอนาคต (FFO) โอ แรงจูงใจโดยนัย สิ่งจูงใจทั้งสองรูปแบบนี้เป็นสิ่งเสริมกัน โหนด Oracle สามารถทำได้พร้อมกัน เข้าร่วมในโปรโตคอล Chainlink staking เพลิดเพลินไปกับแหล่งรายได้อย่างต่อเนื่องจาก ผู้ใช้และได้รับประโยชน์โดยรวมจากพฤติกรรมที่ดีอย่างต่อเนื่องของพวกเขา ดังนั้นแรงจูงใจทั้งสอง มีส่วนช่วยในการรักษาความปลอดภัยทางเศรษฐกิจเข้ารหัสโดยเครือข่าย oracle นอกจากนี้ สิ่งจูงใจทั้งสองสามารถเสริมกำลังและ/หรือแลกเปลี่ยนกันได้ ตัวอย่างเช่น ตัวดำเนินการ oracle ใหม่ที่ไม่มีประวัติประสิทธิภาพและแหล่งรายได้สามารถเดิมพันได้ LINK จำนวนมากเพื่อรับประกันพฤติกรรมที่ซื่อสัตย์ จึงดึงดูดผู้ใช้ และค่าธรรมเนียม ในทางกลับกัน ตัวดำเนินการ oracle ที่จัดตั้งขึ้นนั้นมีความยาวและปราศจากข้อผิดพลาด ประวัติประสิทธิภาพสามารถเรียกเก็บค่าธรรมเนียมจำนวนมากจากฐานผู้ใช้ขนาดใหญ่และพึ่งพาได้ ให้ความสำคัญกับ FFO มากขึ้นซึ่งเป็นรูปแบบของแรงจูงใจโดยนัย โดยทั่วไป วิธีการที่เราพิจารณาในที่นี้มุ่งเป้าไปที่เครือข่าย oracle- จำนวนที่กำหนด ทรัพยากรเพื่อสร้างแรงจูงใจทางเศรษฐกิจที่ยิ่งใหญ่ที่สุดที่เป็นไปได้ใน Chainlink ด้วยเหตุผล ตัวแทน เช่น โหนดที่เพิ่มอรรถประโยชน์ทางการเงินให้เกิดประโยชน์สูงสุด ให้ประพฤติตนอย่างซื่อสัตย์ ใส่อีก เป้าหมายคือการเพิ่มทรัพยากรทางการเงินที่จำเป็นสำหรับฝ่ายตรงข้ามในการโจมตี เครือข่ายได้สำเร็จ โดยการสร้างโปรโตคอล staking ด้วยหลักคณิตศาสตร์ที่ดี กำหนดความมั่นคงทางเศรษฐกิจและการใช้ IIF เรามุ่งมั่นที่จะวัดความแข็งแกร่งของ สิ่งจูงใจของ Chainlink ถูกต้องที่สุด ผู้สร้างสัญญาที่พึ่งพาจะ จากนั้นจึงสามารถตัดสินใจได้อย่างมั่นใจว่าเครือข่าย oracle ตรงตามหรือไม่ ระดับความปลอดภัยทางเศรษฐกิจเข้ารหัสลับที่ต้องการ วงจรคุณธรรมของความมั่นคงทางเศรษฐกิจ: สิ่งจูงใจที่เราพูดคุยกันในส่วนนี้ staking และ FFO มีผลกระทบนอกเหนือจากการเสริมกำลังด้านความปลอดภัยของ DONส. พวกเขาสัญญาว่าจะกระตุ้นให้เกิดสิ่งที่เราเรียกว่าวงจรแห่งความมั่นคงทางเศรษฐกิจที่ดี ผลกระทบซุปเปอร์เชิงเส้น staking (และการประหยัดจากขนาดอื่นๆ) ส่งผลให้การปฏิบัติงานลดลง เสียค่าใช้จ่ายเมื่อความปลอดภัยของ DON เติบโตขึ้น ต้นทุนที่ต่ำกว่าจะดึงดูดผู้ใช้เพิ่มเติมมาที่ DONส่งเสริมการชำระค่าธรรมเนียม การจ่ายค่าธรรมเนียมที่เพิ่มขึ้นยังคงกระตุ้นให้เกิดการเติบโตของ เครือข่ายที่สืบสานวงจรคุณธรรม เราเชื่อว่าวงจรความมั่นคงทางเศรษฐกิจที่ดีเป็นเพียงตัวอย่างหนึ่งของ การประหยัดจากขนาดและผลกระทบของเครือข่าย และอื่นๆ ที่เรากล่าวถึงในหัวข้อนี้ การจัดส่วน: การปักหลักนำเสนอความท้าทายทางเทคนิคและแนวความคิดที่โดดเด่นสำหรับ ซึ่งเราได้ออกแบบกลไกที่มีคุณสมบัติแปลกใหม่ การปักหลักจึงจะเป็น จุดสนใจหลักของเราในส่วนนี้ เราให้ภาพรวมของแนวทาง staking ที่เราแนะนำในบทความนี้ในส่วนที่ 9.1 ตามด้วยการอภิปรายโดยละเอียดในส่วนที่ 9.2 ถึง 9.5 เรานำเสนอ IFF ในมาตรา 9.6 เรานำเสนอมุมมองสรุปของ Chainlink สิ่งจูงใจของเครือข่ายในส่วน 9.7 ในส่วนที่ 9.8 เราจะหารือเกี่ยวกับวงจรอันชอบธรรมของความมั่นคงทางเศรษฐกิจ แนวทาง staking ที่เราเสนอสามารถนำมาสู่เครือข่าย oracle ได้ สุดท้ายนี้ เราจะอธิบายสั้นๆ ถึงศักยภาพอื่นๆ ส่งผลต่อการเติบโตของเครือข่าย Chainlink ในส่วนที่ 9.9 9.1 ภาพรวมการปักหลัก การออกแบบกลไก staking ที่เราแนะนำที่นี่ ดังที่ระบุไว้ข้างต้น เกี่ยวข้องกับโปรโตคอลแบบโต้ตอบระหว่างโหนด oracle ที่อนุญาตให้มีการแก้ไขความไม่สอดคล้องกันใน การรายงานข้อมูลภายนอก การปักหลักมีจุดมุ่งหมายเพื่อให้แน่ใจว่ามีพฤติกรรมที่ซื่อสัตย์จากโหนด oracle ที่มีเหตุผล ดังนั้นเราจึงสามารถสร้างแบบจำลองฝ่ายตรงข้ามที่โจมตีโปรโตคอล staking เป็น ติดสินบน: กลยุทธ์ของฝ่ายตรงข้ามคือการทำให้โหนด oracle เสียหายโดยใช้สิ่งจูงใจทางการเงิน ปฏิปักษ์อาจได้รับทรัพยากรทางการเงินโดยคาดว่าจะมาจากการปลอมแปลงที่ประสบความสำเร็จ ด้วยรายงาน oracle เช่น การแบ่งปันผลกำไรที่ได้กับโหนดที่เสียหาย เรามุ่งเป้าไปที่การออกแบบกลไก staking พร้อมกันเพื่อบรรลุเป้าหมายอันทะเยอทะยานสองประการ: 1. การต่อต้านศัตรูที่ทรงพลัง: กลไก staking ได้รับการออกแบบมาเพื่อปกป้อง oracle เครือข่ายต่อต้านศัตรูประเภทกว้าง ๆ ที่มีความสามารถซับซ้อน กลยุทธ์การติดสินบนแบบมีเงื่อนไข รวมถึงการติดสินบนในอนาคตซึ่งมีการติดสินบน ถึง oracles ซึ่งมีการระบุตัวตนหลังจากข้อเท็จจริง (เช่น ผู้เสนอสินบน oracles สุ่มเลือกสำหรับการแจ้งเตือนที่มีลำดับความสำคัญสูง) ในขณะที่การออกแบบ oracle อื่นๆ ได้พิจารณาชุดการโจมตีแคบ ๆ โดยไม่มีความสามารถเต็มร้อยเหมือนจริง ปฏิปักษ์ เท่าที่เราทราบถึงกลไกปฏิปักษ์ที่เราแนะนำ นี่เป็นเรื่องแรกที่จะกล่าวถึงกลยุทธ์และการแสดงการติดสินบนในวงกว้างอย่างชัดเจน ความต้านทานในรุ่นนี้ แบบจำลองของเราถือว่าโหนดนอกเหนือจากผู้โจมตีเป็น มีเหตุผลทางเศรษฐกิจ (ตรงข้ามกับความซื่อสัตย์) และเราถือว่าการมีอยู่ของ แหล่งที่มาของความจริงที่มีราคาแพงสำหรับการใช้งานทั่วไป แต่มีให้ใช้งาน ในกรณีที่ไม่เห็นด้วย (จะกล่าวถึงเพิ่มเติมด้านล่าง) 2. บรรลุผลกระทบ staking แบบซุปเปอร์เชิงเส้น: เป้าหมายของเราคือเพื่อให้แน่ใจว่าเครือข่าย oracle ประกอบด้วยรายงานตัวแทนที่มีเหตุผล ตามความเป็นจริงแม้ต่อหน้าผู้โจมตีด้วยงบประมาณที่เกินเลยไปในจำนวนเงินเดิมพันทั้งหมดที่ฝากโดยเครือข่ายทั้งหมด ในระบบ staking ที่มีอยู่ ถ้า แต่ละโหนด n เดิมพัน $d ผู้โจมตีสามารถออกสินบนที่น่าเชื่อถือซึ่งร้องขอ โหนดนั้นประพฤติตนไม่ซื่อสัตย์เพื่อแลกกับการจ่ายเงินมากกว่าเล็กน้อย \(d to each node, using a total budget of about \)dn. นี่เป็นแถบที่สูงอยู่แล้ว ผู้โจมตีจะต้องมีงบประมาณสภาพคล่องตามลำดับของเงินฝากรวมของ ผู้เดิมพันทั้งหมดในเครือข่าย เป้าหมายของเราคือความมั่นคงทางเศรษฐกิจในระดับที่แข็งแกร่งยิ่งขึ้น กว่าอุปสรรคอันใหญ่หลวงนี้อยู่แล้ว เรามุ่งมั่นที่จะออกแบบระบบ staking แรก ที่สามารถบรรลุการรักษาความปลอดภัยสำหรับผู้โจมตีทั่วไปด้วยงบประมาณขั้นสูงใน n แม้ว่าการพิจารณาในทางปฏิบัติอาจบรรลุผลน้อยกว่า ตามที่เราจะกล่าวถึงด้านล่างนี้ การออกแบบเบื้องต้นของเราบรรลุความต้องการงบประมาณของฝ่ายตรงข้ามมากกว่า $dn2/2 กล่าวคือ การขยายกำลังสองใน n ทำให้การติดสินบนส่วนใหญ่ทำไม่ได้แม้แต่น้อย เมื่อโหนดเดิมพันในปริมาณปานกลางเท่านั้น การบรรลุเป้าหมายทั้งสองนี้ต้องอาศัยการผสมผสานนวัตกรรมของการออกแบบสิ่งจูงใจ และการเข้ารหัส แนวคิดหลัก: แนวทาง staking ของเราขึ้นอยู่กับแนวคิดที่เราเรียกว่าลำดับความสำคัญของสุนัขเฝ้าบ้าน รายงานที่สร้างโดยเครือข่าย Chainlink oracle และส่งไปยังสัญญาที่เกี่ยวข้อง (เช่น ราคาสินทรัพย์) ถูกรวบรวมจากรายงานแต่ละฉบับที่สนับสนุนโดยโหนดที่เข้าร่วม (เช่น โดยการใช้ค่ามัธยฐาน) โดยทั่วไปแล้วข้อตกลงระดับการให้บริการ (SLA) ระบุขอบเขตที่ยอมรับได้ของการเบี่ยงเบนสำหรับรายงาน เช่น รายงานของโหนดสามารถทำได้ไกลแค่ไหน เบี่ยงเบนไปจากรายงานรวมและควรอนุญาตให้รวมได้ไกลแค่ไหน เบี่ยงเบนไปจากมูลค่าที่แท้จริงจึงจะถือว่าถูกต้อง ในระบบ staking ของเรา สำหรับรอบการรายงานที่กำหนด แต่ละโหนด oracle สามารถทำหน้าที่เป็น เจ้าหน้าที่เฝ้าระวังเพื่อแจ้งเตือนหากเชื่อว่ารายงานรวมไม่ถูกต้อง ในแต่ละ รอบการรายงาน แต่ละโหนด oracle จะได้รับการกำหนดลำดับความสำคัญสาธารณะซึ่งกำหนด เพื่อดำเนินการแจ้งเตือน (ถ้ามี) กลไกของเรามุ่งหวังที่จะให้รางวัล ความเข้มข้น ซึ่งหมายความว่าหน่วยงานเฝ้าระวังที่มีลำดับความสำคัญสูงสุดในการแจ้งเตือนจะได้รับ รางวัลทั้งหมดที่ได้จากการยึดเงินฝากของโหนดที่มีข้อบกพร่อง การออกแบบระบบ staking ของเราเกี่ยวข้องกับสองระดับ: ระดับแรก ระดับเริ่มต้น และระดับที่สอง ชั้นหนุนหลัง ชั้นแรกคือเครือข่าย oracle เอง ซึ่งเป็นชุดของ n โหนด (เพื่อความเรียบง่าย เราถือว่า n เป็นคี่) หากโหนดส่วนใหญ่รายงานค่าที่ไม่ถูกต้อง จะมีการเฝ้าระวังใน ชั้นแรกมีแรงจูงใจอย่างยิ่งในการแจ้งเตือน หากมีการแจ้งเตือนให้รายงาน การตัดสินใจของเครือข่ายจะถูกยกระดับไปสู่ระดับที่สอง ซึ่งเป็นระบบที่มีต้นทุนสูงและความน่าเชื่อถือสูงสุดที่สามารถระบุโดยผู้ใช้ในข้อตกลงระดับบริการเครือข่าย นี่อาจเป็นระบบที่ประกอบด้วยเฉพาะโหนดที่มีความเข้มแข็งเท่านั้น คะแนนความน่าเชื่อถือในอดีต หรือคะแนนที่มีลำดับความสำคัญมากกว่า oracles มากกว่า ชั้นแรก นอกจากนี้ ตามที่กล่าวไว้ในหัวข้อ 9.4.3 DECO หรือ Town Crier สามารถให้บริการได้ เป็นเครื่องมืออันทรงพลังที่ช่วยให้มั่นใจในการตัดสินที่มีประสิทธิภาพและเป็นข้อสรุปในระดับที่สอง เพื่อความง่าย เราจึงถือว่าระบบชั้นสองนี้ได้รับรายงานที่ถูกต้อง ค่า แม้ว่าการพึ่งพาระดับที่สองเพื่อสร้างรายงานทั้งหมดอาจดูน่าสนใจก็ตาม ประโยชน์ของการออกแบบของเราคือการบรรลุคุณสมบัติด้านความปลอดภัยของระบบชั้นสองโดยจ่ายเพียงค่าใช้จ่ายในการดำเนินงาน ในกรณีทั่วไปของ ระบบชั้นแรก ลำดับความสำคัญของ Watchdog ส่งผลให้เกิดผลกระทบแบบซุปเปอร์เชิงเส้น staking ในลักษณะต่อไปนี้: ถ้า เครือข่าย oracle ระดับแรกให้ผลลัพธ์ที่ไม่ถูกต้องและโหนดเฝ้าระวังจำนวนหนึ่ง การแจ้งเตือน กลไกสิ่งจูงใจ staking จะให้รางวัลแก่หน่วยงานเฝ้าระวังที่มีลำดับความสำคัญสูงสุดด้วย มากกว่า $dn/2 ดึงมาจากเงินฝากของโหนดที่ทำงานผิดปกติ (ส่วนใหญ่) ที่ รางวัลทั้งหมดจึงกระจุกอยู่ในมือของสุนัขเฝ้าบ้านเพียงคนเดียวเท่านั้น ซึ่งด้วยเหตุนี้ กำหนดขั้นต่ำที่ฝ่ายตรงข้ามต้องสัญญากับหน่วยงานเฝ้าระวังที่อาจเกิดขึ้น กระตุ้นให้ไม่ตื่นตัว เนื่องจากกลไกของเราทำให้มั่นใจได้ว่าทุกๆ oracle จะได้รับ โอกาสที่จะทำหน้าที่เป็นหน่วยงานเฝ้าระวังหากหน่วยงานเฝ้าระวังที่มีลำดับความสำคัญสูงกว่ายอมรับสินบนของตน (และเลือกที่จะไม่แจ้งเตือน) ฝ่ายตรงข้ามจึงต้องเสนอสินบนมากกว่า $dn/2 ไปยังทุกโหนดเพื่อป้องกันการแจ้งเตือนใด ๆ ที่เกิดขึ้น เนื่องจากไม่มีโหนด งบประมาณที่จำเป็นของฝ่ายตรงข้ามสำหรับการติดสินบนที่ประสบความสำเร็จมีมูลค่ามากกว่า $dn2/2 ซึ่ง เป็นกำลังสองในจำนวน n ของโหนดในเครือข่าย 9.2 พื้นหลัง แนวทางของเราในการ staking อาศัยการวิจัยในสาขาทฤษฎีและกลไกเกม การออกแบบ (MD) (สำหรับการอ้างอิงตำราเรียน ดู [177]) ทฤษฎีเกมเป็นคณิตศาสตร์ การศึกษาปฏิสัมพันธ์เชิงกลยุทธ์อย่างเป็นทางการ ในบริบทนี้ เกมคือรูปแบบหนึ่งของสิ่งนั้น การโต้ตอบ โดยทั่วไปในโลกแห่งความเป็นจริง ซึ่งประมวลชุดของการกระทำที่มีอยู่ ผู้เข้าร่วมในเกมหรือที่เรียกว่าผู้เล่น เกมยังระบุการจ่ายเงินที่ได้รับด้วย โดยผู้เล่นแต่ละคน—รางวัลที่ขึ้นอยู่กับการกระทำที่ผู้เล่นเลือกและ การกระทำของผู้เล่นคนอื่น บางทีอาจเป็นตัวอย่างที่รู้จักกันดีของเกมที่ศึกษาในเกม ทฤษฎีคือภาวะที่กลืนไม่เข้าคายไม่ออกของนักโทษ [178] โดยทั่วไปแล้วนักทฤษฎีเกมมุ่งที่จะทำความเข้าใจ ความสมดุลหรือความสมดุล (ถ้ามี) ที่แสดงในเกมที่กำหนด มีความสมดุลคือ ชุดของกลยุทธ์ (หนึ่งอันสำหรับผู้เล่นแต่ละคน) โดยไม่มีผู้เล่นคนใดสามารถได้รับสิ่งที่สูงกว่า การจ่ายเงินโดยการเบี่ยงเบนไปจากกลยุทธ์เพียงฝ่ายเดียว การออกแบบกลไกนั้นเป็นศาสตร์แห่งการออกแบบสิ่งจูงใจเช่น ความสมดุลของการโต้ตอบ (และเกมที่เกี่ยวข้อง) มีคุณสมบัติที่พึงประสงค์บางประการ MD อาจถูกมองว่าเป็นสิ่งที่ตรงกันข้ามกับทฤษฎีเกม: คำถามที่เป็นที่ยอมรับในเกม ทฤษฎีคือ "เมื่อพิจารณาจากแรงจูงใจและแบบจำลองแล้ว ความสมดุลจะเป็นเช่นไร" ใน MD, the คำถามคือ “แรงจูงใจอะไรที่จะส่งผลให้เกมมีความสมดุลที่น่าพอใจ” เป้าหมายทั่วไปของผู้ออกแบบกลไกคือการสร้างกลไก 'ความเข้ากันได้ของสิ่งจูงใจ' ซึ่งหมายความว่าผู้เข้าร่วมในกลไก (เช่น การประมูลหรือข้อมูลอื่น ๆ ระบบการเชิญชวน [228]) ได้รับการกระตุ้นให้รายงานความจริงในบางเรื่อง (เช่น อย่างไร พวกเขาให้ความสำคัญกับรายการใดรายการหนึ่งมาก) การประมูล Vickrey (ราคาที่สอง) อาจจะเป็น กลไกที่เข้ากันได้กับสิ่งจูงใจที่รู้จักกันดีที่สุด ซึ่งผู้เข้าร่วมส่งการเสนอราคาที่ปิดผนึก สำหรับสินค้าและผู้เสนอราคาสูงสุดจะชนะสินค้าแต่จะจ่ายราคาสูงสุดเป็นอันดับสอง [214]. Cryptoeconomics เป็นรูปแบบเฉพาะโดเมนของ MD ที่ใช้ประโยชน์จากการเข้ารหัส เทคนิคการสร้างสมดุลที่พึงประสงค์ภายในระบบกระจายอำนาจ การติดสินบนและการสมรู้ร่วมคิดสร้างความท้าทายที่สำคัญตลอดทั้งสาขา MD กลไกเกือบทั้งหมดพังทลายเมื่อมีการสมรู้ร่วมคิด ซึ่งถูกกำหนดให้เป็นสัญญาข้างเคียงระหว่างฝ่ายที่เข้าร่วมในกลไก [125, 130] การติดสินบนซึ่งบุคคลภายนอกแนะนำสิ่งจูงใจใหม่ๆ เข้ามาในเกม ทำให้เกิดปัญหาที่ยากยิ่งกว่า มากกว่าการสมรู้ร่วมคิด การสมรู้ร่วมคิดอาจถูกมองว่าเป็นกรณีพิเศษของการติดสินบนในเกม ผู้เข้าร่วม ระบบบล็อกเชนมักถูกมองว่าเป็นเกมที่มีการจ่ายเงิน (ตามสกุลเงินดิจิทัล) ตัวอย่างง่ายๆ คือการขุดแบบ Proof-of-Work: นักขุดมีพื้นที่ดำเนินการ โดยที่พวกเขาสามารถเลือกอัตรา hash ที่จะขุดบล็อกได้ ผลตอบแทนของการขุดคือรางวัลติดลบที่รับประกัน (ค่าไฟฟ้าและอุปกรณ์) บวกกับค่าสุ่ม รางวัลเชิงบวก (เงินอุดหนุนการขุด) ซึ่งขึ้นอยู่กับจำนวนนักขุดรายอื่นที่ใช้งานอยู่ [106, 172] และค่าธรรมเนียมการทำธุรกรรม Crowdsourced oracles เช่น SchellingCoin [68] เป็นอีกตัวอย่างหนึ่ง: พื้นที่การดำเนินการคือชุดของรายงานที่เป็นไปได้ที่ oracle อาจส่ง ในขณะที่ การจ่ายเงินคือรางวัลที่ระบุโดยกลไก oracle เช่น การจ่ายเงินอาจขึ้นอยู่กับ ว่ารายงานของ oracle ใกล้ค่ามัธยฐานของรายงานอื่นๆ มากเพียงใด [26, 68, 119, 185] เกมบล็อกเชนเปิดโอกาสให้เกิดการสมรู้ร่วมคิดและการโจมตีติดสินบน แน่นอน smart contracts สามารถอำนวยความสะดวกในการโจมตีดังกล่าวได้ [96, 165] บางทีอาจจะรู้จักกันดีที่สุด การโจมตีติดสินบนจากมวลชน oracles คือการโจมตีแบบ p-plus-epsilon [67] การโจมตีครั้งนี้ เกิดขึ้นในบริบทของกลไกคล้าย SchellingCoin ที่ผู้เล่นส่งรายงานมูลค่าบูลีน (เช่น เท็จหรือจริง) และจะได้รับรางวัลเป็น p หากพวกเขาเห็นด้วยกับ การส่งส่วนใหญ่ ในการโจมตีแบบ p-plus-epsilon ผู้โจมตีให้คำมั่นสัญญาอย่างน่าเชื่อถือว่า เช่น จ่ายเงินให้ผู้ใช้ $p + ϵ สำหรับการลงคะแนนเท็จ หากว่าการเสนอเสียงข้างมากเป็นจริงเท่านั้น ผลลัพธ์ที่ได้คือความสมดุล โดยที่ผู้เล่นทุกคนจะถูกกระตุ้นให้รายงานเรื่องเท็จ ไม่ว่าผู้เล่นคนอื่นจะทำอะไร ดังนั้นผู้ติดสินบนสามารถชักจูงโหนดได้ ผ่านการติดสินบนที่สัญญาว่าจะรายงานเท็จโดยไม่ต้องจ่ายสินบนจริง (!) อย่างไรก็ตาม การสำรวจกลยุทธ์การให้สินบนอื่นๆ ในบริบทของ oracles—และโดยเฉพาะอย่างยิ่ง oracles ที่ไม่ได้มาจากมวลชน—ถูกจำกัดไว้เพียงฝ่ายตรงข้ามที่ค่อนข้างอ่อนแอ โมเดล ตัวอย่างเช่น ในการตั้งค่า PoW นักวิจัยได้ศึกษาผลลัพธ์ที่อาจเกิดขึ้น สินบน เช่น สินบนที่จ่ายก็ต่อเมื่อมีการเซ็นเซอร์ข้อความเป้าหมายและไม่เซ็นเซอร์เท่านั้น ปรากฏในบล็อกโดยไม่คำนึงถึงการกระทำของนักขุดแต่ละคน [96, 165] ในกรณีนี้ ของ oracles อย่างไรก็ตาม นอกเหนือจากการโจมตี p-plus-epsilon เราทราบเฉพาะการทำงานใน รูปแบบการติดสินบนที่จำกัดอย่างเคร่งครัด โดยผู้ติดสินบนส่งสินบนโดยมีเงื่อนไขว่า การกระทำของผู้เล่นแต่ละคน ไม่ใช่ผลที่ตามมา ที่นี่เราร่างการออกแบบกลไกการดึงข้อมูลที่ยังคงเป็นแรงจูงใจ เข้ากันได้แม้ในรูปแบบฝ่ายตรงข้ามที่แข็งแกร่ง ดังที่อธิบายไว้ในส่วนย่อยถัดไป 9.3 สมมติฐานการสร้างแบบจำลอง ในส่วนย่อยนี้ เราจะอธิบายว่าเราจำลองพฤติกรรมและความสามารถของผู้เล่นอย่างไร ระบบของเรา โดยเฉพาะโหนดระดับแรก oracle โหนดในระดับที่สอง (การพิจารณาคดี) ชั้นและศัตรู9.3.1 รูปแบบสิ่งจูงใจระดับแรก: นักแสดงที่มีเหตุผล ระบบ blockchain จำนวนมากพึ่งพาการรักษาความปลอดภัยโดยถือว่ามีความซื่อสัตย์จำนวนหนึ่ง โหนดที่เข้าร่วม โหนดถูกกำหนดให้ซื่อสัตย์หากพวกเขาปฏิบัติตามโปรโตคอลด้วยซ้ำ เมื่อไม่เป็นประโยชน์ทางการเงินที่จะทำเช่นนั้น โดยทั่วไประบบ Proof of Work พูดตามตรง ต้องการอำนาจ hash ส่วนใหญ่ พูดตามตรง ระบบ Proof-of-Stake โดยทั่วไปต้องการ 2/3 หรือมากกว่าของสัดส่วนการเข้าร่วมทั้งหมดจึงจะซื่อสัตย์ และแม้แต่ระบบเลเยอร์ 2 เช่น อนุญาโตตุลาการ [141] ต้องการผู้เข้าร่วมที่ซื่อสัตย์อย่างน้อยหนึ่งคน ในการสร้างแบบจำลองสำหรับกลไก staking ของเรา เราใช้สมมติฐานที่อ่อนแอกว่ามาก (จะเป็น สมมติฐานที่ชัดเจนและอ่อนแอกว่าหมายถึงคุณสมบัติด้านความปลอดภัยที่แข็งแกร่งกว่า และดังนั้นจึงดีกว่า) เราถือว่าฝ่ายตรงข้ามเสียหาย เช่น การควบคุม บางส่วน (ส่วนน้อย) เศษส่วนของโหนด oracle ระดับแรก เราจำลองโหนดที่เหลือไม่ใช่ตัวแทนที่ซื่อสัตย์ แต่เป็นตัวเพิ่มอรรถประโยชน์ที่คาดหวังอย่างมีเหตุผล โหนดเหล่านี้ดำเนินการตามสิ่งจูงใจทางการเงินที่สนใจในตนเอง โดยเลือกการกระทำที่ส่งผลให้เกิดการเงินที่คาดหวัง ได้รับ ตัวอย่างเช่น หากโหนดถูกเสนอให้ จะมีการติดสินบนที่มากกว่ารางวัลที่เกิดขึ้น ประพฤติสุจริตก็จะรับสินบน หมายเหตุเกี่ยวกับโหนดฝ่ายตรงข้าม: ตามแบบจำลองความไว้วางใจทั่วไปสำหรับ ระบบการกระจายอำนาจ เราถือว่าโหนดทั้งหมดมีเหตุผล นั่นคือ พยายามที่จะขยายให้สูงสุด รายได้สุทธิแทนที่จะถูกควบคุมโดยฝ่ายตรงข้ามที่เป็นอันตราย อย่างไรก็ตามการเรียกร้องของเรา— ผลกระทบแบบซุปเปอร์เชิงเส้นหรือกำลังสองโดยเฉพาะ staking ให้คงไว้แบบไม่แสดงกำกับ ว่าชุดของโหนดที่ควบคุมโดยฝ่ายตรงข้ามนั้นมีมากที่สุด (1/2 −c) n สำหรับค่าบวกบางอย่าง ค่าคงที่ค 9.3.2 รูปแบบการตัดสินชั้นสอง: ความถูกต้องตามสมมติฐาน โปรดจำไว้ว่าคุณลักษณะที่สำคัญของกลไก staking ของเราที่ช่วยให้บรรลุความปลอดภัย กับโหนดเหตุผลคือระบบระดับที่สอง ในกลไก staking ที่เราเสนอ oracle ใดๆ อาจส่งการแจ้งเตือนที่ระบุว่า เชื่อว่าผลลัพธ์ของกลไกไม่ถูกต้อง การแจ้งเตือนส่งผลให้มีความน่าเชื่อถือสูง ระบบชั้นสองเปิดใช้งานและรายงานผลลัพธ์ที่ถูกต้อง ดังนั้นการสร้างแบบจำลองที่สำคัญ ข้อกำหนดสำหรับแนวทางของเราคือการตัดสินที่ถูกต้อง เช่น การรายงานที่ถูกต้องโดย ระบบชั้นสอง โมเดล staking ของเราใช้ระบบระดับที่สองซึ่งทำหน้าที่เป็นแหล่งความจริงที่ไม่เน่าเปื่อยและเชื่อถือได้สูงสุด ระบบดังกล่าวมีแนวโน้มที่จะมีราคาแพงและช้าด้วยเหตุนี้ ไม่เหมาะสมกับการใช้งานตามกรณีทั่วไป อย่างไรก็ตาม ในกรณีสมดุล เช่น เมื่อใด ระบบชั้นแรกทำงานได้อย่างถูกต้อง ระบบชั้นสองจะไม่ถูกเรียกใช้ แต่การมีอยู่ของมันกลับช่วยเพิ่มความปลอดภัยของระบบ oracle ทั้งหมดโดยการจัดเตรียม แบ็คสต็อปที่มีความมั่นใจสูง การใช้ชั้นการพิจารณาคดีที่มีความน่าเชื่อถือสูงและมีค่าใช้จ่ายสูงคล้ายคลึงกับกระบวนการอุทธรณ์ เป็นหัวใจสำคัญของระบบตุลาการส่วนใหญ่ นอกจากนี้ยังเป็นเรื่องปกติในการออกแบบของ oracle ระบบต่างๆ เช่น [119, 185] เราพูดคุยสรุปถึงแนวทางในการบรรลุถึงระดับที่สอง ในกลไกของเราในส่วน 9.4.3โปรโตคอล staking ของเราใช้การพิจารณาตัดสินที่ถูกต้องของระบบระดับที่สองว่าเป็นภัยคุกคามที่น่าเชื่อถือในการบังคับใช้การรายงานที่ถูกต้องโดยโหนด oracle โปรโตคอล ยึดสัดส่วนการถือหุ้นบางส่วนหรือทั้งหมดของโหนด oracle ที่สร้างรายงานที่ระบุโดย ระบบชั้นสองไม่ถูกต้อง โหนด Oracle จึงถูกขัดขวางไม่ให้ทำงานผิดปกติ โดยผลของการลงโทษทางการเงิน แนวทางนี้มีความคล้ายคลึงกับวิธีการที่ใช้ มองโลกในแง่ดี rollup เช่น [141, 10] 9.3.3 โมเดลฝ่ายตรงข้าม กลไก staking ของเราได้รับการออกแบบมาเพื่อล้วงเอาข้อมูลที่เป็นความจริงไปพร้อมๆ กับการรักษาความปลอดภัยจากกลุ่มศัตรูในวงกว้างที่มีการกำหนดไว้อย่างดี มันปรับปรุงจากการทำงานก่อนหน้านี้ ซึ่งละเว้นแบบจำลองฝ่ายตรงข้ามที่ชัดเจนหรือมุ่งเน้นไปที่คลาสย่อยที่แคบของฝ่ายตรงข้าม เช่น ฝ่ายตรงข้าม p-plus-epsilon ที่กล่าวถึงข้างต้น เป้าหมายของเราคือการออกแบบ staking กลไกที่มีการรักษาความปลอดภัยที่ได้รับการพิสูจน์อย่างเป็นทางการแล้วต่อศัตรูทุกกลุ่ม ที่จะต้องพบเจอในทางปฏิบัติ เราจำลองปฏิปักษ์ของเราว่ามีงบประมาณคงที่ (กำหนดพารามิเตอร์ได้) ซึ่งแสดงโดย $บี. ฝ่ายตรงข้ามสามารถสื่อสารเป็นรายบุคคลและเป็นความลับกับแต่ละ oracle ใน เครือข่ายและสามารถแอบเสนอ oracle รับประกันการติดสินบนให้กับบุคคลใดๆ ก็ได้ ขึ้นอยู่กับผลลัพธ์ของกลไกที่สาธารณชนสามารถสังเกตได้ การกำหนดผลลัพธ์ สินบนอาจรวมถึงมูลค่าที่รายงานโดย oracle ข้อความสาธารณะใดๆ เช่น ส่งโดย oracle ใดๆ ไปยังกลไก (เช่น การแจ้งเตือน) ค่าที่รายงานโดยอื่นๆ oracles และค่าที่ส่งออกโดยกลไก ไม่มีกลไกใดที่สามารถป้องกันผู้โจมตีที่มีความสามารถไม่จำกัดได้ ดังนั้นเราจึงถือว่าพฤติกรรมบางอย่างไม่สมจริงหรืออยู่นอกขอบเขต เราถือว่าผู้โจมตีของเรา ไม่สามารถทำลายการเข้ารหัสแบบดั้งเดิมแบบมาตรฐานได้ และตามที่ระบุไว้ข้างต้น ได้มีการแก้ไขแล้ว (if อาจมีขนาดใหญ่) งบประมาณ $B เรายังสันนิษฐานอีกว่าฝ่ายตรงข้ามไม่ได้ควบคุม การสื่อสารในเครือข่าย oracle โดยเฉพาะอย่างยิ่งไม่สามารถหน่วงเวลาได้มากนัก การรับส่งข้อมูลระหว่างโหนดระดับแรกและ/หรือโหนดระดับสอง (ไม่ว่าปฏิปักษ์จะสังเกตเห็นการสื่อสารดังกล่าวหรือไม่นั้นขึ้นอยู่กับกลไกเฉพาะ ดังที่เราอธิบายด้านล่าง) อย่างไรก็ตาม ตามที่ระบุไว้ข้างต้นอย่างไม่เป็นทางการ เราถือว่าฝ่ายตรงข้ามสามารถ: (1) ทุจริตได้ เศษส่วนของ oracle โหนด ((1/2 −c) -fraction สำหรับค่าคงที่ c) นั่นคือควบคุมอย่างเต็มที่ พวกเขา และ (2) ให้สินบนไปยังโหนดที่ต้องการ พร้อมรับประกันการชำระเงินที่อาจเกิดขึ้น เกี่ยวกับผลลัพธ์ที่ระบุโดยปฏิปักษ์ตามที่อธิบายไว้ข้างต้น แม้ว่าเราจะไม่นำเสนอแบบจำลองที่เป็นทางการหรืออนุกรมวิธานที่สมบูรณ์ของฝ่ายตรงข้ามก็ตาม ความสามารถในการติดสินบนที่หลากหลายในเอกสารไวท์เปเปอร์นี้ ต่อไปนี้เป็นตัวอย่างของประเภทต่างๆ ผู้ติดสินบนถูกห้อมล้อมด้วยแบบจำลองของเรา เพื่อความง่าย เราถือว่า oracles ปล่อยบูลีน รายงานที่มีค่าที่ถูกต้อง (w.l.o.g.) เป็นจริง และผลลัพธ์สุดท้ายจะถูกคำนวณเป็น ผลรวมของรายงานเหล่านี้ที่จะใช้โดย smart contract ที่ใช้งาน ของติดสินบน จุดมุ่งหมายคือให้ผลลัพธ์สุดท้ายไม่ถูกต้อง เช่น เท็จ • การติดสินบนโดยไม่มีเงื่อนไข: ผู้ติดสินบนจะติดสินบน $b ให้กับ oracle ใดๆ ที่รายงานว่าเป็นเท็จ • ผู้ที่มีแนวโน้มจะติดสินบน: ผู้ติดสินบนจะติดสินบน $b ด้วยความน่าจะเป็นบางประการ q ต่อ oracle ที่รายงานเท็จ• การให้สินบนตามเงื่อนไขผลลัพธ์ที่เป็นเท็จ: ผู้ติดสินบนติดสินบน $b ให้กับ oracle ใดๆ ที่รายงานเท็จ โดยมีเงื่อนไขว่าผลลัพธ์สุดท้ายนั้นเป็นเท็จ • การให้สินบนโดยไม่มีเงื่อนไขการแจ้งเตือน: ผู้ติดสินบนติดสินบน $b ให้กับ oracle ใดๆ ที่รายงาน เท็จตราบใดที่ไม่มีการแจ้งเตือน • p-plus-epsilon Briber: ผู้ติดสินบนติดสินบน $b ให้กับ oracle ใดๆ ที่รายงานว่าเป็นเท็จ ตราบใดที่ oracles ส่วนใหญ่ไม่รายงานเท็จ • ผู้ที่คาดว่าจะติดสินบน: ผู้ติดสินบนจะติดสินบน $b ล่วงหน้าไม่ว่า oracle ใดก็ตามจะถูกเลือก สำหรับบทบาทแบบสุ่มและรายงานเท็จ ในโปรโตคอล staking ที่เราเสนอทั้งหมด โหนดทำหน้าที่เป็นหน่วยเฝ้าระวังที่มีศักยภาพ และเราสามารถแสดงการสุ่มนั้นได้ ลำดับความสำคัญของหน่วยงานเฝ้าระวังไม่ได้ให้ความสำคัญกับการติดสินบนในอนาคต การพิสูจน์การทำงานจำนวนมาก proof-of-stake และระบบที่ได้รับอนุญาตมีความอ่อนไหวต่อผู้มีแนวโน้มจะเป็นลูกค้า อย่างไรก็ตาม การติดสินบนซึ่งแสดงให้เห็นถึงความสำคัญของการพิจารณาเรื่องนี้กับฝ่ายตรงข้ามของเรา สร้างแบบจำลองและตรวจสอบให้แน่ใจว่าโปรโตคอล staking ของเรามีความยืดหยุ่น ดูภาคผนวก จ สำหรับรายละเอียดเพิ่มเติม 9.3.4 ความปลอดภัยทางเศรษฐศาสตร์ Crypto เท่าไหร่ก็เพียงพอแล้ว? ฝ่ายตรงข้ามที่มีเหตุผลจะใช้จ่ายเงินเพื่อโจมตีระบบก็ต่อเมื่อสามารถได้รับผลกำไรเท่านั้น ใหญ่กว่ารายจ่ายของมัน ดังนั้นสำหรับโมเดลฝ่ายตรงข้ามของเราและเสนอ staking กลไก $B อาจถูกมองว่าเป็นการวัดผลกำไรที่อาจเกิดขึ้นที่ฝ่ายตรงข้ามสามารถทำได้ เพื่อแยกจากการพึ่งพา smart contracts โดยทำให้เครือข่าย oracle เสียหายและทำให้เกิดความเสียหาย เพื่อสร้างรายงานหรือชุดรายงานที่ไม่ถูกต้อง ในการตัดสินใจว่าเครือข่าย oracle หรือไม่ ผู้ใช้ควรมีระดับความปลอดภัยทางเศรษฐกิจแบบเข้ารหัสที่เพียงพอสำหรับวัตถุประสงค์ของพวกเขา ประเมินเครือข่ายจากมุมมองนี้ สำหรับฝ่ายตรงข้ามที่เป็นไปได้ในทางปฏิบัติ เราคาดหวังว่าโดยทั่วไปแล้ว $B จะเป็นเช่นนั้น น้อยกว่าสินทรัพย์รวมอย่างมากในการพึ่งพา smart contracts ในกรณีส่วนใหญ่นั้น เป็นไปไม่ได้ที่ฝ่ายตรงข้ามจะดึงทรัพย์สินเหล่านี้ออกมาทั้งหมด 9.4 กลไกการปักหลัก: ร่าง ที่นี่เรานำเสนอแนวคิดหลักและโครงสร้างทั่วไปของกลไก staking ที่เรานำเสนอ กำลังพิจารณาอยู่. เพื่อความสะดวกในการนำเสนอเราขออธิบายแบบเรียบง่ายแต่ช้าๆ (หลายรอบ) โปรโตคอลในส่วนย่อยนี้ อย่างไรก็ตาม เราทราบว่าโครงการนี้ค่อนข้างจะดี ใช้งานได้จริง เมื่อพิจารณาจากการรับประกันทางเศรษฐกิจที่ได้รับจากกลไก เช่น การลงโทษและแรงจูงใจที่ตามมาต่อโหนดที่ผิดพลาด ผู้ใช้จำนวนมากอาจเต็มใจที่จะ ยอมรับรายงานในแง่ดี กล่าวอีกนัยหนึ่ง ผู้ใช้ดังกล่าวอาจยอมรับรายงานก่อน การตัดสินที่เป็นไปได้ตามชั้นที่สอง ผู้ใช้ที่ไม่เต็มใจที่จะยอมรับรายงานในแง่ดีสามารถเลือกรอจนถึงโปรโตคอลได้ การดำเนินการสิ้นสุดลง กล่าวคือ จนกว่าจะมีการยกระดับไปยังระดับที่สองที่อาจเกิดขึ้น นี้ อย่างไรก็ตาม สามารถชะลอเวลาการยืนยันสำหรับรายงานได้อย่างมาก ดังนั้นเราจึงสรุปสั้นๆรูปที่ 15: แผนผังของโครงการ staking พร้อมการแจ้งเตือน ในตัวอย่างนี้ 1⃝a ส่วนใหญ่ ของโหนดเสียหาย / ติดสินบนและปล่อยค่าที่ไม่ถูกต้อง ˜r แทนที่จะเป็นค่าที่ถูกต้อง ค่ารายงาน r โหนดเฝ้าระวัง 2⃝ส่งการแจ้งเตือนไปยังคณะกรรมการระดับที่สอง ซึ่ง3⃝กำหนดและปล่อยค่ารายงานที่ถูกต้อง r ส่งผลให้โหนดเสียหาย ริบเงินฝากของพวกเขา—แต่ละ $d ไปยังโหนดเฝ้าระวัง 4⃝ สรุปการเพิ่มประสิทธิภาพบางอย่างซึ่งส่งผลให้เร็วขึ้น (รอบเดียว) หากมากกว่านั้น การออกแบบที่ซับซ้อนในส่วนที่ 9.5 โปรดจำไว้ว่าระดับแรกในกลไก staking ของเราประกอบด้วย oracle พื้นฐาน เครือข่ายนั่นเอง โครงสร้างหลักของกลไกของเราตามที่อธิบายไว้ข้างต้นคือในแต่ละรอบ แต่ละโหนดสามารถทำหน้าที่เป็น "สุนัขเฝ้าบ้าน" โดยมีลำดับความสำคัญบางประการ ดังนั้นจึงมีความสามารถที่จะ เพิ่มการแจ้งเตือนหากกลไกมาถึงเอาต์พุตที่ไม่ถูกต้อง ˜r แทนที่จะเป็นที่ถูกต้อง หนึ่งอาร์ การแจ้งเตือนนี้ทำให้เกิดการแก้ไขปัญหาระดับที่สอง ซึ่งเราถือว่ามาได้ถูกต้องแล้ว รายงาน โหนดที่มีรายงานที่ไม่ถูกต้องจะถูกลงโทษในแง่ที่ว่าเป็นเดิมพัน เฉือนและมอบให้กับสุนัขเฝ้าบ้าน โครงสร้างพื้นฐานนี้เป็นเรื่องธรรมดาในระบบ oracle เช่นเดียวกับใน เช่น [119, 185] นวัตกรรมที่สำคัญในการออกแบบของเรา ดังที่กล่าวโดยย่อข้างต้น คือทุกโหนดเป็น ได้รับมอบหมายลำดับความสำคัญที่ชัดเจนในการจัดลำดับผู้เฝ้าระวังที่มีศักยภาพ นั่นคือสุนัขเฝ้าบ้าน ได้รับโอกาสในการแจ้งเตือนตามลำดับความสำคัญ จำได้ว่าถ้าโหนดมี ลำดับความสำคัญสูงสุดในการแจ้งเตือน จะได้รับเงินฝาก $d ของพฤติกรรมที่ไม่เหมาะสมทุกครั้ง โหนดสำหรับผลรวมมากกว่า \(dn/2 = \)d × n/2 เนื่องจากรายงานที่ไม่ถูกต้องแสดงถึง โหนดเสียส่วนใหญ่ ดังนั้นฝ่ายตรงข้ามจะต้องจ่ายรางวัลนี้อย่างน้อยที่สุด ติดสินบนโหนดตามอำเภอใจ ดังนั้น ในการติดสินบนโหนดส่วนใหญ่ ฝ่ายตรงข้ามจะต้องจ่ายเงิน ติดสินบนจำนวนมากไปยังโหนดส่วนใหญ่ กล่าวคือ มากกว่า $dn2/2 อย่างเคร่งครัด เราแสดงแผนผังว่าการยกระดับการแจ้งเตือนและการเฝ้าระวังทำงานอย่างไรในรูปที่ 159.4.1 รายละเอียดกลไกเพิ่มเติม ระบบต่อต้านการติดสินบนที่เราอธิบายในรายละเอียดเพิ่มเติมในขณะนี้เป็นเพียงภาพร่างที่เรียบง่าย การก่อสร้างสองชั้นที่เราตั้งใจจะสร้าง เราจะเน้นไปที่การอธิบายเป็นหลัก เครือข่ายชั้นหนึ่ง (ต่อจากนี้ไปเรียกง่ายๆ ว่า “เครือข่าย” ที่ชัดเจนจากบริบท) ไปด้วย ด้วยกลไกการสร้างแรงจูงใจและขั้นตอนการยกระดับไปสู่ระดับที่ 2 พิจารณาเครือข่าย Chainlink ที่ประกอบด้วยโหนด n oracle ที่รับผิดชอบ เป็นประจำ (เช่น นาทีละครั้ง) รายงานค่าบูลีน (เช่น ไม่ว่าจะเป็นตลาด การใช้อักษรตัวพิมพ์ใหญ่ของ BTC เกินกว่า ETH) เป็นส่วนหนึ่งของกลไก staking โหนด ต้องจัดให้มีเงินฝากสองรายการ: เงินฝาก $d อาจถูกตัดอย่างเจ็บแสบในกรณีที่ไม่เห็นด้วย โดยส่วนใหญ่และเงินฝากประจำ $dw อาจถูกตัดอย่างเจ็บแสบในกรณีที่เกิดข้อผิดพลาด การยกระดับ เราถือว่าโหนดไม่สามารถคัดลอกการส่งของโหนดอื่นได้ เช่น ผ่านโครงการเปิดเผยข้อผูกพันตามที่กล่าวไว้ในหัวข้อ 5.3 ในแต่ละรอบ โหนดก่อน ยอมรับรายงานของพวกเขา และเมื่อโหนดทั้งหมดได้กระทำ (หรือการหมดเวลาหมดอายุ) โหนดเปิดเผยรายงานของพวกเขา สำหรับแต่ละรายงานที่จะถูกสร้างขึ้น ทุกโหนดจะได้รับลำดับความสำคัญของโปรแกรมเฝ้าระวังระหว่าง 1 ถึง n ที่เลือกโดยการสุ่ม โดยที่ 1 มีความสำคัญสูงสุด ลำดับความสำคัญนี้ช่วยให้สามารถ ความเข้มข้นของรางวัลอยู่ในมือของสุนัขเฝ้าบ้านหนึ่งคน หลังจากที่รายงานทั้งหมดเปิดเผยต่อสาธารณะแล้ว ระยะการแจ้งเตือนเกิดขึ้น ตามลำดับของรอบ n (ซิงโครนัส) โหนดที่มี ลำดับความสำคัญ ฉันมีโอกาสแจ้งเตือนในรอบที่ 1 ให้เราพิจารณาผลลัพธ์ที่เป็นไปได้สำหรับกลไกนี้หลังจากเปิดเผยโหนดแล้ว รายงานของพวกเขา สมมติว่าเป็นรายงานไบนารีอีกครั้ง สมมติว่าค่าที่ถูกต้องเป็นจริงและ อันที่ไม่ถูกต้องนั้นเป็นเท็จ สมมติว่ากลไกระดับแรกส่งเอาต์พุต เอาต์พุตค่าส่วนใหญ่โดยโหนดเป็นรายงานขั้นสุดท้าย r ผลลัพธ์ที่เป็นไปได้สามประการในกลไกนี้: • ข้อตกลงที่สมบูรณ์: ในกรณีที่ดีที่สุด โหนดอยู่ในข้อตกลงที่สมบูรณ์: โหนดทั้งหมด มีอยู่และได้จัดทำรายงานทันเวลาของค่าเดียวกัน r (เป็นจริงอย่างใดอย่างหนึ่ง หรือเท็จ) ในกรณีนี้ เครือข่ายต้องการเพียงการส่งต่อ r ไปยังสัญญาที่อ้างอิงเท่านั้น และให้รางวัลแก่แต่ละโหนดด้วยการจ่ายเงินคงที่ต่อรอบ $p ซึ่งน้อยกว่ามาก กว่า $d • ข้อตกลงบางส่วน: เป็นไปได้ว่าบางโหนดเป็นแบบออฟไลน์หรือมีข้อขัดแย้งเกี่ยวกับค่าที่ถูกต้อง แต่โหนดส่วนใหญ่รายงานว่าเป็นจริงและมีเพียง ชนกลุ่มน้อยรายงานเท็จ กรณีนี้ก็ตรงไปตรงมาเช่นกัน ค่าส่วนใหญ่ (จริง) ถูกคำนวณ ส่งผลให้ได้รายงานที่ถูกต้อง r โหนดทั้งหมดที่รายงาน r คือ ได้รับรางวัล $p ในขณะที่ oracles ที่รายงานว่าไม่ถูกต้องมีเงินฝาก ลดลงเล็กน้อย เช่น ลง 10 เพนนี • การแจ้งเตือน: ในกรณีที่เจ้าหน้าที่เฝ้าระวังเชื่อว่าเอาต์พุตของเครือข่ายไม่ถูกต้อง โดยจะแจ้งเตือนต่อสาธารณะ โดยขยายกลไกไปยังเครือข่ายระดับสอง จึงมีผลลัพธ์ที่เป็นไปได้สองประการ: – การแจ้งเตือนที่ถูกต้อง: หากเครือข่ายชั้นสองยืนยันว่าเอาต์พุตของรูปที่ 16: การขยายต้นทุนของสินบนผ่านการให้รางวัลการแจ้งเตือนแบบเข้มข้น การติดสินบน ฝ่ายตรงข้ามจะต้องติดสินบนแต่ละโหนดด้วยมากกว่ารางวัลที่จะได้รับจากการแจ้งเตือน (แสดงเป็นแถบสีแดง) หากมีการแบ่งปันรางวัลการแจ้งเตือน รางวัลนี้อาจค่อนข้างจะค่อนข้าง เล็ก รางวัลการแจ้งเตือนแบบเข้มข้นจะเพิ่มรางวัลที่โหนดใด ๆ สามารถทำได้ รับ (แถบสีแดงสูง) ผลที่ตามมาก็คือการจ่ายเงินทั้งหมดโดยฝ่ายตรงข้ามสำหรับสินบนที่สามารถดำเนินการได้ (พื้นที่สีเทา) มีขนาดใหญ่กว่ามากและมีความเข้มข้นมากกว่ารางวัลแจ้งเตือนที่ใช้ร่วมกัน เครือข่ายระดับแรกไม่ถูกต้อง โหนดเฝ้าระวังที่แจ้งเตือนจะได้รับรางวัล ประกอบด้วยเงินฝากที่ถูกเฉือนทั้งหมด และมากกว่า $dn/2 – การแจ้งเตือนผิดพลาด: หาก oracles ระดับที่สองและระดับแรกเห็นด้วย การเพิ่มระดับคือ ถือว่ามีข้อผิดพลาดและโหนดแจ้งเตือนสูญเสียเงินฝาก $dw ในกรณีที่มีการยอมรับรายงานในแง่ดี การแจ้งเตือนจากสุนัขเฝ้าบ้านจะไม่เกิดขึ้น การเปลี่ยนแปลงใด ๆ ในการดำเนินการตามสัญญาที่อ้างอิง สำหรับสัญญาที่ออกแบบไว้เพื่อรอคอย อาจมีการอนุญาโตตุลาการโดยคณะกรรมการระดับสอง การแจ้งเตือนล่าช้า แต่ อย่าหยุดการดำเนินการตามสัญญา นอกจากนี้ยังเป็นไปได้ที่สัญญาจะกำหนดก เฟลโอเวอร์ DON สำหรับช่วงเวลาการพิจารณาคดี 9.4.2 ผลกระทบการปักหลักกำลังสอง ความสามารถสำหรับทุกโหนดในการทำหน้าที่เป็นผู้เฝ้าระวัง รวมกับลำดับความสำคัญของโหนดที่เข้มงวด รับประกันผลตอบแทนที่เข้มข้น ช่วยให้กลไกบรรลุกำลังสอง staking ผลกระทบต่อผู้โจมตีที่ติดสินบนแต่ละประเภทตามที่อธิบายไว้ในส่วนที่ 9.3.3 จำได้ว่าอันนี้. หมายถึงโดยเฉพาะในการตั้งค่าของเราว่า สำหรับเครือข่ายที่มี n โหนด แต่ละโหนดมีเงินฝาก $d การให้สินบนที่ประสบความสำเร็จ (ประเภทใดๆ ข้างต้น) จะต้องมีงบประมาณมากกว่า $dn2/2. พูดให้ถูกคือ ผู้ติดสินบนจะต้องสร้างความเสียหายอย่างน้อย (n+1)/2 โหนด เนื่องจากผู้ติดสินบนจะต้อง ทำให้โหนด n ส่วนใหญ่เสียหาย (สำหรับเลขคี่ n ตามสมมติฐาน) ดังนั้นสุนัขเฝ้าบ้านจึงยืนหยัดเพื่อ รับรางวัล $d(n + 1)/2 ผู้ติดสินบนจึงต้องจ่ายเงินจำนวนนี้ให้ทุกคนโหนดเพื่อให้แน่ใจว่าไม่มีใครทำหน้าที่เป็นสุนัขเฝ้าบ้าน เรากำลังดำเนินการเพื่อแสดงอย่างเป็นทางการว่าถ้า ผู้ติดสินบนมีงบประมาณมากที่สุด $d(n2 + n)/2 จากนั้นเกมย่อยจะมีความสมดุลที่สมบูรณ์แบบ ของเกมระหว่างผู้ติดสินบนและ oracles—หรืออีกนัยหนึ่ง ความสมดุลที่ จุดใด ๆ ในระหว่างการเล่นเกม - มีไว้สำหรับผู้ติดสินบนไม่ให้ติดสินบนและเพื่อ แต่ละ oracle เพื่อรายงานคุณค่าที่แท้จริงอย่างตรงไปตรงมา เราได้อธิบายไว้ข้างต้นแล้วว่าเป็นไปได้อย่างไรที่ผู้ติดสินบนที่ประสบความสำเร็จอาจเรียกร้อง งบประมาณมีขนาดใหญ่กว่าผลรวมของเงินฝากโหนดอย่างมาก เพื่ออธิบายสิ่งนี้ ผลลัพธ์ที่เข้าใจง่าย รูปที่ 16 แสดงผลกระทบของรางวัลการแจ้งเตือนแบบเข้มข้นในรูปแบบกราฟิก ดังที่เราเห็น ถ้ารางวัลสำหรับการแจ้งเตือนสุนัขเฝ้าบ้าน—คือเงินฝากของสินบน โหนดที่รายงานเท็จ)—ถูกแบ่งออกเป็นการแจ้งเตือนที่อาจเกิดขึ้นทั้งหมด ซึ่งเป็นจำนวนเงินทั้งหมด โหนดแจ้งเตือนใดๆ ที่คาดว่าจะมีขนาดค่อนข้างเล็ก ตามลำดับ $d. ผู้ติดสินบนโดยรู้ว่าการจ่ายเงินที่มากกว่า $d นั้นไม่น่าจะเป็นไปได้จึงสามารถนำมาใช้ได้ การให้สินบนแบบมีเงื่อนไขที่เป็นผลเท็จเพื่อติดสินบนแต่ละโหนดด้วยจำนวนที่มากกว่าเล็กน้อย $d + ϵ ในทางตรงกันข้าม รูปที่ 16 แสดงให้เห็นว่าระบบที่กระจายรางวัลในวงกว้าง ในบรรดาโหนดที่ส่งสัญญาณการแจ้งเตือนนั้นอ่อนแอกว่าโหนดที่เน้นไปที่รางวัล มือของสุนัขเฝ้าบ้านตัวเดียว พารามิเตอร์ตัวอย่าง: พิจารณาเครือข่าย (ชั้นแรก) ที่มี n = 100 โหนดในแต่ละโหนด ฝากเงิน \(d = \)20K เครือข่ายนี้จะมีเงินฝากทั้งหมด 2 ล้านเหรียญสหรัฐ แต่จะฝากไว้ ได้รับความคุ้มครองจากการติดสินบนด้วยงบประมาณ \(100M = \)dn2/2 การเพิ่มจำนวน oracles มีประสิทธิภาพมากกว่าการเพิ่ม $d แน่นอน และอาจมีผลกระทบอย่างมาก: เครือข่ายที่มี n = 300 โหนดและเงินฝาก \(d = \)20K จะได้รับการปกป้องจาก ติดสินบนด้วยงบประมาณสูงถึง 900 ล้านเหรียญสหรัฐ โปรดทราบว่าในหลายกรณีระบบ staking สามารถปกป้อง smart contracts ที่เป็นตัวแทนของ มีมูลค่ามากกว่าระดับการคุ้มครองการติดสินบนที่นำเสนอ เพราะเป็นศัตรูกัน การโจมตีสัญญาเหล่านี้ไม่สามารถดึงมูลค่าทั้งหมดออกมาได้ในหลายกรณี ตัวอย่างเช่น ก Chainlink-สัญญาที่ขับเคลื่อนด้วยมูลค่า 1 พันล้านดอลลาร์อาจต้องการการรักษาความปลอดภัยต่อ ติดสินบนด้วยทรัพยากรมูลค่า 100 ล้านเหรียญสหรัฐ เนื่องจากฝ่ายตรงข้ามดังกล่าวสามารถดึงผลกำไรออกมาได้อย่างเป็นไปได้ เพียง 10% ของมูลค่าสัญญา หมายเหตุ: แนวคิดที่ว่ามูลค่าของเครือข่ายสามารถเติบโตได้เป็นกำลังสองนั้นแสดงออกมาด้วย กฎของเมตคาล์ฟที่รู้จักกันดี [167, 235] ซึ่งระบุว่าคุณค่าของเครือข่าย เติบโตเป็นกำลังสองในจำนวนเอนทิตีที่เชื่อมต่อกัน อย่างไรก็ตาม กฎของเมตคาล์ฟ เกิดขึ้นจากการเติบโตของจำนวนการเชื่อมต่อเครือข่ายแบบคู่ที่เป็นไปได้ ซึ่งเป็นปรากฏการณ์ที่แตกต่างจากผลกระทบกำลังสอง staking ที่เป็นพื้นฐานในแรงจูงใจของเรา กลไก 9.4.3 การรับรู้ของชั้นที่สอง คุณสมบัติการดำเนินงานสองประการช่วยให้เกิดความน่าเชื่อถือสูงในระดับที่สอง: (1) การตัดสินในระดับที่สองควรเป็นเหตุการณ์ที่เกิดขึ้นไม่บ่อยนักในเครือข่าย oracle และด้วยเหตุนี้จึงสามารถทำได้ มีค่าใช้จ่ายสูงกว่าการดำเนินการปกติของชั้นแรกอย่างมีนัยสำคัญและ (2) สมมติว่ารายงานที่ยอมรับในแง่ดี—หรือสัญญาที่การดำเนินการสามารถรออนุญาโตตุลาการ— ชั้นที่สองไม่จำเป็นต้องดำเนินการแบบเรียลไทม์ คุณสมบัติเหล่านี้ส่งผลให้มีช่วงของ ตัวเลือกการกำหนดค่าสำหรับชั้นที่สองเพื่อให้ตรงตามข้อกำหนดของ DONs เฉพาะ ตามแนวทางตัวอย่าง คณะกรรมการระดับที่สองสามารถประกอบด้วยโหนดที่เลือกโดย a DON (เช่น ระดับแรก) จากโหนดที่ให้บริการยาวนานที่สุดและเชื่อถือได้มากที่สุดใน Chainlink เครือข่าย นอกเหนือจากประสบการณ์การดำเนินงานที่เกี่ยวข้องอย่างมากแล้วผู้ปฏิบัติงาน ของโหนดดังกล่าวมีแรงจูงใจโดยนัยอย่างมากใน FFO ที่กระตุ้นความปรารถนา เพื่อให้แน่ใจว่าเครือข่าย Chainlink ยังคงเชื่อถือได้สูง พวกเขายังได้เปิดเผยต่อสาธารณะ ประวัติประสิทธิภาพที่มีอยู่ซึ่งให้ความโปร่งใสในความน่าเชื่อถือ เป็นที่น่าสังเกตว่าโหนดระดับที่สองไม่จำเป็นต้องเป็นผู้เข้าร่วมในเครือข่ายระดับแรก และ อาจตัดสินข้อผิดพลาดในเครือข่ายระดับแรกหลายเครือข่าย โหนดใน DON ที่กำหนดสามารถกำหนดล่วงหน้าและยอมรับต่อสาธารณะกับชุดของ n ดังกล่าว โหนดที่ประกอบขึ้นเป็นคณะกรรมการระดับสองสำหรับ DON นั้น นอกจากนี้ DON โหนดเผยแพร่พารามิเตอร์ k′ ≤n′ ที่กำหนดจำนวนคะแนนโหวตระดับที่สอง จำเป็นต้องลงโทษโหนดระดับแรก เมื่อมีการสร้างการแจ้งเตือนสำหรับรายงานที่กำหนด สมาชิกของชั้นที่สองจะลงคะแนนเสียงถึงความถูกต้องของค่าที่แต่ละคนให้มา ของโหนดระดับแรก โหนดระดับแรกใด ๆ ที่ได้รับคะแนนโหวตเป็นลบ k จะถูกริบโหนดนั้น ฝากไปยังโหนดเฝ้าระวัง เนื่องจากคำพิพากษานั้นหาได้ยากและมีโอกาสที่จะมีการบังคับคดีที่ยืดเวลาออกไป ตามที่กล่าวไว้ข้างต้น ตรงกันข้ามกับชั้นแรก โหนดในระดับที่สองสามารถ: 1. ได้รับค่าตอบแทนสูงในการดำเนินการตัดสิน 2. ดึงแหล่งข้อมูลเพิ่มเติม นอกเหนือจากชุดข้อมูลที่หลากหลายที่ใช้โดยกลุ่มแรก 3. อาศัยการตรวจสอบและการแทรกแซงโดยเจ้าหน้าที่และ/หรือผู้เชี่ยวชาญ เช่น เพื่อระบุและ ปรับแก้ข้อผิดพลาดในแหล่งข้อมูลและแยกแยะระหว่างการถ่ายทอดโหนดที่ซื่อสัตย์ ข้อมูลผิดพลาดและโหนดทำงานผิดปกติ เราเน้นย้ำว่าแนวทางที่เราเพิ่งอธิบายไว้สำหรับการเลือกโหนดระดับรองและนโยบายที่ควบคุมการตัดสินเป็นเพียงจุดหนึ่งในกลุ่มใหญ่ พื้นที่การออกแบบของการรับรู้ที่เป็นไปได้ของชั้นที่สอง กลไกการสร้างแรงจูงใจของเรานำเสนอ ความยืดหยุ่นที่สมบูรณ์เกี่ยวกับวิธีการรับรู้ระดับที่สอง บุคคล DONs สามารถทำได้ สร้างและกำหนดกฎสำหรับระดับที่สองที่ตรงตามข้อกำหนดเฉพาะ และความคาดหวังของโหนดและผู้ใช้ที่เข้าร่วม DECO และ Town Crier เป็นเครื่องมือในการตัดสิน: มันเป็นสิ่งจำเป็นสำหรับชั้นที่สอง ในกลไกของเราเพื่อให้สามารถแยกแยะระหว่างโหนดระดับแรกของฝ่ายตรงข้ามได้ จงใจจัดทำรายงานที่ไม่ถูกต้องและโหนดชั้นหนึ่งที่ซื่อสัตย์โดยไม่ได้ตั้งใจ ถ่ายทอดข้อมูลไม่ถูกต้องที่ต้นทาง จากนั้นระดับที่สองจึงจะสามารถนำไปใช้ได้ อย่างเจ็บแสบเพื่อไม่จูงใจการโกงเป้าหมายของกลไกของเรา DECO และ Town Crier เป็นเครื่องมืออันทรงพลังที่สามารถเปิดใช้งานโหนดระดับที่สองเพื่อสร้างความแตกต่างที่สำคัญนี้ได้ ได้อย่างน่าเชื่อถือโหนดระดับที่สองในบางกรณีอาจสามารถสืบค้นแหล่งข้อมูลที่ใช้ได้โดยตรง โดยโหนดระดับแรก หรือใช้ ADO มาตรา 7.1 เพื่อตรวจสอบว่ารายงานไม่ถูกต้องหรือไม่ เกิดจากแหล่งข้อมูลผิดพลาด อย่างไรก็ตาม ในกรณีอื่นๆ โหนดระดับที่สองอาจขาดหายไป เข้าถึงแหล่งข้อมูลของโหนดระดับแรกได้โดยตรง ในกรณีเช่นนี้ให้พิพากษาให้ถูกต้อง ดูเหมือนจะเป็นไปไม่ได้หรือต้องอาศัยวิจารณญาณส่วนตัว ก่อนหน้า oracle ระบบข้อพิพาทอาศัยการลงคะแนนเสียงที่ไม่รอบด้านและทวีความรุนแรงขึ้นเพื่อแก้ไขปัญหาดังกล่าว ความท้าทาย อย่างไรก็ตาม การใช้ DECO หรือ Town Crier โหนดระดับแรกสามารถพิสูจน์พฤติกรรมที่ถูกต้องได้ ไปยังโหนดระดับที่สอง (ดูหัวข้อ 3.6.2 สำหรับรายละเอียดเกี่ยวกับทั้งสองระบบ) โดยเฉพาะถ้า โหนดระดับที่สองระบุโหนดระดับแรกว่ามีเอาต์พุตค่ารายงานที่ผิดพลาด ˜r โหนดระดับแรกสามารถใช้ DECO หรือ Town Crier เพื่อสร้างหลักฐานการงัดแงะได้ โหนดระดับที่สองที่มีการถ่ายทอดอย่างถูกต้องจากแหล่งที่มา (เปิดใช้งาน TLS) ได้รับการยอมรับว่าเชื่อถือได้โดย DON ในเชิงวิกฤต โหนดระดับแรกสามารถทำได้ โดยไม่ต้องใช้โหนดระดับสองที่ต้องการการเข้าถึงแหล่งข้อมูลโดยตรง17 ดังนั้น การพิจารณาคดีที่ถูกต้องเป็นไปได้ใน Chainlink สำหรับแหล่งข้อมูลที่ต้องการ 9.4.4 แจ้งประกันผิด. การต่อต้านการติดสินบนที่แข็งแกร่งซึ่งเกิดขึ้นได้จากกลไก staking ของเรานั้นขึ้นอยู่กับพื้นฐาน ในการตัดเงินที่มอบให้กับผู้แจ้งเตือน หากไม่มีรางวัลเป็นตัวเงิน ผู้แจ้งเตือนก็จะทำ ไม่มีแรงจูงใจโดยตรงในการปฏิเสธสินบน อย่างไรก็ตามเป็นผลให้กองทุนถูกตัดทอนไม่ได้ มีไว้เพื่อชดเชยผู้ใช้ที่ได้รับความเสียหายจากรายงานที่ไม่ถูกต้อง เช่น ผู้ใช้ที่สูญเสียเงิน เมื่อข้อมูลราคาไม่ถูกต้องถูกส่งไปยัง smart contract ตามสมมติฐาน รายงานที่ไม่ถูกต้องจะไม่ก่อให้เกิดปัญหาหากรายงานได้รับการยอมรับจาก a สัญญาเฉพาะหลังจากการตัดสินที่เป็นไปได้เท่านั้น เช่น การดำเนินการตามระดับที่สอง ตามที่อธิบายไว้ ข้างต้น แม้ว่าเพื่อให้ได้ประสิทธิภาพที่ดีที่สุดเท่าที่จะเป็นไปได้ สัญญาอาจต้องพึ่งพาแทน ในแง่ดีเกี่ยวกับกลไกในการบังคับใช้การรายงานที่ถูกต้อง ซึ่งหมายความว่าพวกเขายอมรับ รายงานก่อนที่จะมีการพิจารณาพิพากษาชั้นสองที่อาจเกิดขึ้น แท้จริงแล้วพฤติกรรมในแง่ดีดังกล่าว ปลอดภัยในรูปแบบของเราโดยสมมติว่าศัตรูที่มีเหตุผลซึ่งมีงบประมาณไม่เกิน staking ผลกระทบของกลไก ผู้ใช้กังวลเกี่ยวกับเหตุการณ์ที่ไม่น่าจะเป็นไปได้ของความล้มเหลวของกลไกอันเป็นผลมาจาก เช่น ฝ่ายตรงข้ามที่มีทรัพยากรทางการเงินอย่างล้นหลาม อาจต้องการใช้ชั้นความมั่นคงทางเศรษฐกิจเพิ่มเติมในรูปแบบของการรายงานประกันภัยที่ไม่ถูกต้อง เรารู้ของ บริษัทประกันภัยหลายรายตั้งใจที่จะเสนอกรมธรรม์ที่ได้รับการสนับสนุนจากสัญญาอัจฉริยะประเภทนี้อยู่แล้ว สำหรับ Chainlink-โปรโตคอลที่ปลอดภัยในอนาคตอันใกล้นี้ รวมถึงผ่านกลไกที่เป็นนวัตกรรมใหม่ เช่น DAOs เช่น [7] การมีอยู่ของประวัติประสิทธิภาพสำหรับ Chainlink โหนดและข้อมูลอื่น ๆ เกี่ยวกับโหนด เช่น จำนวนเดิมพัน ถือเป็นพื้นฐานที่แข็งแกร่งเป็นพิเศษสำหรับการประเมินความเสี่ยงตามหลักคณิตศาสตร์ประกันภัย ทำให้สามารถกำหนดนโยบายราคาได้ ในรูปแบบที่ไม่แพงสำหรับผู้ถือกรมธรรม์แต่ยังยั่งยืนสำหรับผู้ประกันตน 17ด้วย Town Crier เป็นไปได้เพิ่มเติมสำหรับโหนดระดับแรกเพื่อสร้างการรับรองในพื้นที่ ของความถูกต้องสำหรับรายงานที่ส่งออกและให้การรับรองเหล่านี้แก่โหนดระดับที่สองใน ตามความจำเป็นรูปแบบพื้นฐานของการประกันการรายงานที่ไม่ถูกต้องสามารถนำไปใช้ได้อย่างน่าเชื่อถือและ ลักษณะที่มีประสิทธิภาพโดยใช้ smart contracts ยกตัวอย่างง่ายๆ การประกันภัยแบบพาราเมตริก SCins สัญญาสามารถชดเชยผู้ถือกรมธรรม์ได้โดยอัตโนมัติหากกลไกแรงจูงใจของเรา ระดับที่สองระบุข้อผิดพลาดในรายงานที่สร้างขึ้นในระดับแรก ผู้ใช้ U ที่ต้องการซื้อกรมธรรม์ประกันภัย เช่น ผู้สร้างเป้าหมาย สัญญา SC สามารถส่งคำขอไปยังบริษัทประกันภัยแบบกระจายอำนาจตามจำนวนกรมธรรม์ได้ $M ในสัญญา เมื่ออนุมัติ U ผู้รับประกันภัยสามารถกำหนดระยะเวลาต่อเนื่องได้ (เช่น รายเดือน) พรีเมี่ยมของ $P ใน SCins ขณะที่คุณจ่ายเบี้ยประกันภัย กรมธรรม์ของเธอยังคงมีผลอยู่ หากความล้มเหลวในการรายงานเกิดขึ้นใน SC ผลลัพธ์จะเป็นการปล่อยสัญญาณคู่ (r1, r2) ของรายงานที่ขัดแย้งกันสำหรับ SC โดยที่ r1 ได้รับการลงนามโดยระดับแรกในกลไกของเราและ r2 ซึ่งเป็นรายงานที่แก้ไขแล้วที่เกี่ยวข้อง ได้รับการลงนามโดยระดับที่สอง ถ้ายูตกแต่ง คู่ที่ถูกต้อง (r1, r2) ไปยัง SCins สัญญาจะจ่าย $M ให้เธอโดยอัตโนมัติ การชำระเบี้ยประกันภัยของเธอเป็นข้อมูลล่าสุด 9.5 รุ่นรอบเดียว ระเบียบการที่อธิบายไว้ในส่วนย่อยก่อนหน้านี้กำหนดให้คณะกรรมการระดับที่สองรอ n รอบเพื่อพิจารณาว่าหน่วยงานเฝ้าระวังได้แจ้งเตือนหรือไม่ นี้ ข้อกำหนดยังคงอยู่แม้ในกรณีที่มองโลกในแง่ดี เช่น เมื่อเทียร์แรกทำงานได้ อย่างถูกต้อง สำหรับผู้ใช้ที่ไม่เต็มใจที่จะยอมรับรายงานในแง่ดี เช่น ก่อนที่จะมีศักยภาพ การพิจารณาตัดสิน ความล่าช้าที่เกี่ยวข้องกับแนวทางดังกล่าวจะไม่สามารถใช้งานได้ ด้วยเหตุนี้ เรายังสำรวจโปรโตคอลทางเลือกที่ต้องใช้เพียงโปรโตคอลเดียวด้วย รอบ ในแนวทางนี้ โหนด oracle ทั้งหมดจะส่งบิตลับที่ระบุว่าหรือไม่ พวกเขาต้องการแจ้งเตือน จากนั้นคณะกรรมการระดับที่สองจะตรวจสอบค่าเหล่านี้ ลำดับความสำคัญ เพื่อให้ร่างคร่าวๆ โครงการดังกล่าวอาจเกี่ยวข้องกับสิ่งต่อไปนี้ ขั้นตอน: 1. การส่งบิต Watchdog: แต่ละโหนด Oi Secret จะแชร์ค่า Watchdog หนึ่งบิต wi ∈{no alert, alert} ระหว่างโหนดในระดับที่สองสำหรับทุกรายงานที่สร้างขึ้น 2. เคล็ดลับที่ไม่ระบุชื่อ: โหนด oracle ใดๆ สามารถส่งเคล็ดลับที่ไม่ระบุชื่อ α ไปยังคณะกรรมการระดับที่สองในรอบเดียวกับที่มีการส่งบิตเฝ้าระวัง เคล็ดลับนี้α เป็นข้อความแจ้งว่ามีการแจ้งเตือนสำหรับรายงานปัจจุบัน 3. การตรวจสอบบิต Watchdog: คณะกรรมการระดับที่สองเปิดเผย oracle หน่วยงานเฝ้าระวังของโหนด บิตตามลำดับความสำคัญ โปรดทราบว่าโหนดจะต้องไม่ส่งบิตเฝ้าระวังเมื่อไม่แจ้งเตือน มิฉะนั้น การวิเคราะห์การรับส่งข้อมูลจะเปิดเผยบิตของโหนดทั้งหมด โปรโตคอลไม่เปิดเผยการแจ้งเตือน หน่วยเฝ้าระวังบิตของโหนดที่มีลำดับความสำคัญสูงกว่าหน่วยเฝ้าระวังการแจ้งเตือนที่มีลำดับความสำคัญสูงสุด สังเกตว่าสิ่งที่เปิดเผยนั้นเหมือนกันกับโปรโตคอล n-round ของเรา รางวัลยังจะแจกจ่ายเหมือนกันกับโครงการนั้น กล่าวคือ หน่วยเฝ้าระวังที่ระบุตัวเป็นคนแรก ได้รับเงินฝากที่เฉือนของโหนดที่ส่งรายงานไม่ถูกต้องการใช้เคล็ดลับที่ไม่ระบุชื่อช่วยให้คณะกรรมการระดับที่สองยังคงไม่โต้ตอบในกรณีที่ไม่มีการเตือน ช่วยลดความซับซ้อนในการสื่อสาร ในกรณีทั่วไป โปรดทราบว่าหน่วยงานเฝ้าระวังใดๆ ที่แจ้งเตือนมีแรงจูงใจทางเศรษฐกิจในการส่งทิปที่ไม่ระบุชื่อ: หากไม่มีการส่งทิป จะไม่มีการจ่ายรางวัลให้กับบุคคลใดๆ โหนด เพื่อให้แน่ใจว่าผู้ส่ง Oi ของทิปที่ไม่ระบุชื่อ α ไม่สามารถระบุได้โดย ฝ่ายตรงข้ามขึ้นอยู่กับข้อมูลเครือข่าย เคล็ดลับที่ไม่ระบุชื่อสามารถส่งผ่านข้อมูลที่ไม่ระบุชื่อได้ ช่องทาง เช่น ผ่าน Tor หรือในทางปฏิบัติมากกว่านั้นคือพร็อกซีผ่านผู้ให้บริการระบบคลาวด์ ถึง ตรวจสอบความถูกต้องของทิปที่มีต้นกำเนิดจาก O, Oi สามารถลงนาม α โดยใช้ลายเซ็นวงแหวน [39, 192] อีกทางหนึ่ง เพื่อป้องกันการโจมตีแบบปฏิเสธการให้บริการโดยไม่ได้ระบุแหล่งที่มาต่อคณะกรรมการระดับรองโดยโหนด oracle ที่เป็นอันตราย α สามารถเป็นข้อมูลประจำตัวที่ไม่ระบุตัวตนได้ การไม่เปิดเผยตัวตนที่สามารถเพิกถอนได้ [73] โปรโตคอลนี้แม้ว่าจะสามารถทำได้จริง แต่ก็มีวิศวกรรมที่ค่อนข้างหนัก ข้อกำหนด (ซึ่งเรากำลังสำรวจวิธีการลด) โหนดระดับแรก เช่น ต้องสื่อสารโดยตรงกับโหนดระดับที่สอง ซึ่งต้องมีการบำรุงรักษาไดเร็กทอรี ความจำเป็นในการใช้ช่องสัญญาณที่ไม่ระบุชื่อและลายเซ็นเสียงกริ่งช่วยเพิ่มประสิทธิภาพทางวิศวกรรม ความซับซ้อนของโครงการ สุดท้ายนี้ มีการหารือเกี่ยวกับข้อกำหนดด้านความไว้วางใจพิเศษโดยสรุป ในบันทึกด้านล่าง ดังนั้นเราจึงสำรวจแผนการที่เรียบง่ายกว่าที่ยังคงบรรลุผลสำเร็จ ผลกระทบแบบซุปเปอร์เชิงเส้น staking แต่อาจน้อยกว่ากำลังสอง ซึ่งผู้ติดสินบนต้องการทรัพยากรอย่างน้อย $n log n ตามลำดับ บางส่วนของแผนการภายใต้ การพิจารณาเกี่ยวข้องกับการสุ่มเลือกชุดย่อยของโหนดที่เข้มงวดเพื่อทำหน้าที่เป็นสุนัขเฝ้าบ้าน ในกรณีนี้การติดสินบนในอนาคตจะกลายเป็นการโจมตีที่ทรงพลังเป็นพิเศษ หมายเหตุ: การรักษาความปลอดภัยของกลไก staking รอบเดียวนี้จำเป็นต้องไม่สามารถใช้งานได้ ช่องสัญญาณระหว่าง oracle และโหนดระดับสอง ซึ่งเป็นข้อกำหนดมาตรฐานในระบบต้านทานการบีบบังคับ เช่น การลงคะแนนเสียง [82, 138] และข้อกำหนดที่สมเหตุสมผลในทางปฏิบัติ อย่างไรก็ตาม นอกจากนี้ โหนด Oi ที่พยายามร่วมมือกับผู้ติดสินบนก็สามารถสร้างได้ การแบ่งปันความลับในลักษณะที่แสดงให้ผู้ติดสินบนเห็นว่าได้เข้ารหัสรายการใดรายการหนึ่งไว้ ค่า ตัวอย่างเช่น หาก Oi ไม่รู้ว่าโหนดใดที่ผู้ติดสินบนควบคุม Oi ก็สามารถทำได้ เสนอหุ้นมูลค่า 0 หุ้นให้กับกรรมการทุกท่าน ผู้ติดสินบนสามารถตรวจสอบตัวตนของอ้อยได้ เป็นไปตามความน่าจะเป็น เพื่อหลีกเลี่ยงปัญหานี้ในโปรโตคอลแบบรอบเดียว เรา ต้องการให้ Oi รู้ตัวตนของโหนดระดับสองที่ซื่อสัตย์อย่างน้อยหนึ่งโหนด ด้วยโปรโตคอลแบบโต้ตอบซึ่งแต่ละโหนดระดับที่สองจะเพิ่มการสุ่ม ปัจจัยในการแบ่งปัน สิ่งที่ดีที่สุดที่ผู้ติดสินบนสามารถทำได้คือบังคับให้อ้อยเลือกโดยการสุ่ม สุนัขเฝ้าบ้านสักหน่อย 9.6 กรอบงานแรงจูงใจโดยนัย (IIF) FFO เป็นรูปแบบหนึ่งของแรงจูงใจโดยนัยสำหรับพฤติกรรมที่ถูกต้องในเครือข่าย Chainlink มัน ทำหน้าที่เหมือนกับการเดิมพันที่ชัดเจน เช่น เงินฝาก ซึ่งจะช่วยบังคับใช้ความมั่นคงทางเศรษฐกิจ เครือข่าย กล่าวอีกนัยหนึ่ง ควรรวม FFO เป็นส่วนหนึ่งของเงินฝาก (มีผลใช้บังคับ) $d ของโหนดในเครือข่ายคำถามคือ เราจะวัด FFO และแรงจูงใจโดยนัยรูปแบบอื่นๆ ได้อย่างไร ภายในเครือข่าย Chainlink หรือไม่ กรอบการทำงานโดยนัย-แรงจูงใจ (IIF) เป็นชุดของ หลักการและเทคนิคที่เราวางแผนจะพัฒนาเพื่อจุดประสงค์นี้ ระบบบล็อกเชน มอบความโปร่งใสที่ไม่เคยมีมาก่อนหลายรูปแบบ และบันทึกความน่าเชื่อถือสูงของโหนด ประสิทธิภาพที่พวกเขาสร้างขึ้นเป็นจุดเริ่มต้นสำหรับวิสัยทัศน์ของเราว่า IIF จะทำงานอย่างไร ที่นี่เราจะร่างแนวคิดสั้นๆ เกี่ยวกับองค์ประกอบสำคัญของ IIF IIF เองจะประกอบด้วยชุดปัจจัยที่เราระบุว่ามีความสำคัญในการประเมิน สิ่งจูงใจโดยนัยพร้อมกับกลไกในการเผยแพร่ข้อมูลที่เกี่ยวข้องในรูปแบบการรับประกันระดับสูงเพื่อการบริโภคโดยอัลกอริธึมการวิเคราะห์ ผู้ใช้ Chainlink ที่แตกต่างกันอาจ ต้องการใช้ IIF ในรูปแบบที่แตกต่างกัน เช่น ให้น้ำหนักที่แตกต่างกันกับปัจจัยที่แตกต่างกัน เราคาดหวังว่าบริการการวิเคราะห์จะเกิดขึ้นในชุมชนที่ช่วยผู้ใช้นำ IIF ไปใช้ ตามการตั้งค่าการประเมินความเสี่ยงส่วนบุคคล และเป้าหมายของเราคือการอำนวยความสะดวก บริการดังกล่าวโดยรับประกันการเข้าถึงข้อมูลสนับสนุนที่มีความมั่นใจสูงและทันเวลา ตามที่เราพูดคุยด้านล่าง (ส่วนที่ 9.6.4) 9.6.1 โอกาสค่าธรรมเนียมในอนาคต โหนดมีส่วนร่วมในระบบนิเวศ Chainlink เพื่อรับส่วนแบ่งค่าธรรมเนียมที่เครือข่ายจ่ายสำหรับบริการต่างๆ ที่เราอธิบายไว้ในเอกสารนี้ จาก การป้อนข้อมูลธรรมดาไปยังบริการขั้นสูง เช่น การระบุตัวตนแบบกระจายอำนาจ การจัดลำดับที่ยุติธรรม และการรักษาความลับ DeFi ค่าธรรมเนียมในเครือข่าย Chainlink สนับสนุนค่าใช้จ่ายของผู้ให้บริการโหนด เช่น การเรียกใช้เซิร์ฟเวอร์ การได้รับสิทธิ์การใช้งานข้อมูลที่จำเป็น และการบำรุงรักษา พนักงานระดับโลกเพื่อให้แน่ใจว่ามีสภาพพร้อมใช้งานสูง FFO หมายถึง ค่าบริการสุทธิจากค่าใช้จ่าย ว่าโหนดจะได้รับในอนาคตหรือสูญเสียหากโหนดแสดงพฤติกรรมที่ผิดพลาด FFO เป็นรูปแบบหนึ่งของการเดิมพันที่ช่วยรักษาความปลอดภัยเครือข่าย คุณลักษณะที่เป็นประโยชน์ของ FFO คือข้อเท็จจริงที่ว่าข้อมูล on-chain (เสริมด้วย of-chain ข้อมูล) สร้างบันทึกที่มีความน่าเชื่อถือสูงของประวัติของโหนด ทำให้สามารถคำนวณ FFO ได้ ในลักษณะที่โปร่งใสและขับเคลื่อนด้วยประสบการณ์ การวัด FFO ลำดับแรกอย่างง่ายสามารถได้มาจากรายได้สุทธิเฉลี่ยของ โหนดในช่วงเวลาหนึ่ง (เช่น รายได้รวมลบค่าใช้จ่ายในการดำเนินงาน) FFO อาจ แล้วคำนวณเป็น เช่น มูลค่าปัจจุบันสุทธิ [114] ของรายได้สุทธิสะสมในอนาคต กล่าวอีกนัยหนึ่งคือมูลค่าส่วนลดตามเวลาของรายได้ในอนาคตทั้งหมด อย่างไรก็ตาม รายได้จากโหนดอาจมีความผันผวน ดังตัวอย่างในรูปที่ 17 ที่สำคัญกว่านั้น รายได้จากโหนดอาจไม่เป็นไปตามการกระจายแบบคงที่ เมื่อเวลาผ่านไป ดังนั้น ปัจจัยอื่นๆ ที่เราวางแผนจะสำรวจในการประมาณ FFO ได้แก่: • ประวัติการปฏิบัติงาน: ประวัติการปฏิบัติงานของผู้ปฏิบัติงาน—รวมถึงความถูกต้องและทันเวลาของรายงาน ตลอดจนเวลาทำงาน—ให้วัตถุประสงค์ มาตรฐานสำหรับผู้ใช้ในการประเมินความน่าเชื่อถือ ประวัติการปฏิบัติงานจะเป็นเช่นนั้น ให้ปัจจัยสำคัญในการเลือกโหนด oracle ของผู้ใช้ (หรือด้วยการถือกำเนิด ของ DONs การเลือก DONs) ประวัติผลการดำเนินงานที่แข็งแกร่งมีแนวโน้มที่จะ สัมพันธ์กับรายได้ต่อเนื่องที่สูง18 18คำถามวิจัยที่สำคัญที่เราตั้งใจจะกล่าวถึงคือการตรวจหาปริมาณบริการที่ไม่ถูกต้องรูปที่ 17: รายได้ที่ได้รับจากโหนด Chainlink บนฟีดข้อมูลเดียว (ETH-USD) ในระหว่าง สัปดาห์ตัวแทนในเดือนมีนาคม 2021 • การเข้าถึงข้อมูล: แม้ว่า oracles อาจได้รับข้อมูลหลายรูปแบบจาก API แบบเปิด ข้อมูลบางรูปแบบหรือแหล่งข้อมูลคุณภาพสูงบางอย่างอาจมีให้บริการใน a เท่านั้น พื้นฐานการสมัครสมาชิกหรือผ่านข้อตกลงตามสัญญา สิทธิพิเศษในการเข้าถึงบางอย่าง แหล่งข้อมูลสามารถมีบทบาทในการสร้างแหล่งรายได้ที่มั่นคง • การมีส่วนร่วม DON: ด้วยการถือกำเนิดของ DONs ชุมชนของโหนดจะเกิดขึ้น ร่วมกันให้บริการโดยเฉพาะ เราคาดหวังว่าจะมี DONs จำนวนมากรวมอยู่ด้วย ผู้ประกอบการบนพื้นฐานการคัดเลือก โดยสร้างการมีส่วนร่วมใน DONs ที่มีชื่อเสียงในฐานะ ตำแหน่งทางการตลาดที่มีเอกสิทธิ์ซึ่งช่วยรับประกันแหล่งรายได้ที่สม่ำเสมอ • กิจกรรมข้ามแพลตฟอร์ม: ตัวดำเนินการโหนดบางตัวอาจมีสถานะและบันทึกการติดตามประสิทธิภาพที่เป็นที่ยอมรับในบริบทอื่น เช่น PoS validators หรือ ผู้ให้บริการข้อมูลในบริบทที่ไม่ใช่ blockchain ประสิทธิภาพในระบบอื่นๆ เหล่านี้ (เมื่อมีข้อมูลอยู่ในรูปแบบที่น่าเชื่อถือ) สามารถแจ้งการประเมินได้ ประวัติผลงานของพวกเขา ในทำนองเดียวกัน ลักษณะการทำงานที่ผิดพลาดในเครือข่าย Chainlink อาจเป็นอันตรายต่อรายได้ในระบบอื่นๆ เหล่านี้โดยการขับไล่ผู้ใช้ เช่น FFO สามารถขยายข้ามแพลตฟอร์มได้ 9.6.2 FFO แบบเก็งกำไร ผู้ดำเนินการโหนดมีส่วนร่วมในเครือข่าย Chainlink ไม่ใช่แค่เพื่อสร้างรายได้เท่านั้น แต่ต้องสร้างและวางตำแหน่งตัวเองเพื่อใช้ประโยชน์จากโอกาสใหม่ๆ ในการดำเนินธุรกิจ กล่าวอีกนัยหนึ่ง ค่าใช้จ่ายโดย oracle โหนดในเครือข่ายก็เช่นกัน ข้อความเชิงบวกเกี่ยวกับอนาคตของ DeFi และแอปพลิเคชันสัญญาอัจฉริยะอื่นๆ โดเมนตลอดจนแอปพลิเคชันที่ไม่ใช่ blockchain ใหม่ของเครือข่าย oracle ปัจจุบันผู้ดำเนินการโหนดจะได้รับค่าธรรมเนียมจากเครือข่าย Chainlink ที่มีอยู่และพร้อมกัน สิ่งเหล่านี้คล้ายคลึงกับรีวิวปลอมบนเว็บไซต์อินเทอร์เน็ต ยกเว้นว่าปัญหาจะง่ายกว่าใน oracle การตั้งค่าเนื่องจากเรามีบันทึกที่ชัดเจนว่าสินค้า เช่น รายงาน ได้รับการสั่งซื้อและ จัดส่ง—ซึ่งตรงข้ามกับ เช่น สินค้าที่จับต้องได้ที่สั่งซื้อในร้านค้าออนไลน์ กล่าวอีกนัยหนึ่ง ใน oracle การตั้งค่า สามารถตรวจสอบประสิทธิภาพได้ แม้ว่าความจริงของลูกค้าจะไม่สามารถทำได้ก็ตามสร้างชื่อเสียง ประวัติผลงาน และความเชี่ยวชาญในการดำเนินงานที่จะวางตำแหน่ง พวกเขาได้เปรียบในการรับค่าธรรมเนียมที่มีอยู่ในเครือข่ายในอนาคต (แน่นอนว่าเกิดขึ้นโดยบังเอิญ ด้วยความประพฤติซื่อสัตย์) โหนดที่ทำงานในระบบนิเวศ Chainlink ในปัจจุบันจะอยู่ในสิ่งนี้ Sense มีข้อได้เปรียบเหนือผู้มาใหม่ในการรับค่าธรรมเนียมเพิ่มเติม Chainlink มีบริการต่างๆ ข้อได้เปรียบนี้ใช้ได้กับผู้ให้บริการรายใหม่ เช่นเดียวกับบริษัทเทคโนโลยีที่มีชื่อเสียงเป็นที่ยอมรับ เช่น T-Systems แบบดั้งเดิม ผู้ให้บริการเทคโนโลยี (บริษัทในเครือของ Deutsche Telekom) และ Kraken ซึ่งเป็นบริษัทรวมศูนย์ขนาดใหญ่ การแลกเปลี่ยน ได้สร้างการปรากฏตัวครั้งแรกในระบบนิเวศ Chainlink [28, 143] การมีส่วนร่วมดังกล่าวโดยโหนด oracle ในโอกาสในอนาคตอาจได้รับการพิจารณาด้วยตัวมันเอง ในฐานะ FFO แบบเก็งกำไร และด้วยเหตุนี้จึงถือเป็นรูปแบบหนึ่งของสัดส่วนการถือหุ้นใน Chainlink เครือข่าย 9.6.3 ชื่อเสียงภายนอก IIF ตามที่เราได้อธิบายไว้สามารถทำงานในเครือข่ายที่ใช้นามแฝงอย่างเคร่งครัด ผู้ปฏิบัติงาน กล่าวคือ โดยไม่มีการเปิดเผยบุคคลหรือหน่วยงานในโลกแห่งความเป็นจริงที่เกี่ยวข้อง อย่างไรก็ตาม ปัจจัยที่อาจสำคัญประการหนึ่งสำหรับการเลือกผู้ให้บริการของผู้ใช้คือปัจจัยภายนอก ชื่อเสียง จากชื่อเสียงภายนอก เราหมายถึงการรับรู้ถึงความน่าเชื่อถือที่ยึดติดกับตัวตนในโลกแห่งความเป็นจริง มากกว่าการใช้นามแฝง ความเสี่ยงด้านชื่อเสียงติดอยู่ ตัวตนในโลกแห่งความเป็นจริงถือได้ว่าเป็นรูปแบบหนึ่งของแรงจูงใจโดยนัย เราดูชื่อเสียง ผ่านเลนส์ของ IIF เช่น ในแง่เศรษฐศาสตร์เข้ารหัส เพื่อเป็นแนวทางในการก่อตั้ง กิจกรรมข้ามแพลตฟอร์มที่อาจรวมอยู่ในการประมาณการ FFO ประโยชน์ของการใช้ชื่อเสียงภายนอกเป็นปัจจัยในการประมาณการ FFO ในทางตรงกันข้าม การเชื่อมโยงโดยใช้นามแฝงคือชื่อเสียงภายนอกเชื่อมโยงประสิทธิภาพไม่ใช่แค่กับ กิจกรรมที่มีอยู่ของผู้ปฏิบัติงาน แต่ยังรวมไปถึงกิจกรรมในอนาคตด้วย เช่นถ้าชื่อเสียงไม่ดี ยึดติดกับแต่ละบุคคล อาจทำให้กิจการในอนาคตของบุคคลนั้นเสียได้ กล่าวอีกนัยหนึ่ง ชื่อเสียงภายนอกสามารถครอบคลุม FFO ได้กว้างกว่าการใช้นามแฝง บันทึกผลการปฏิบัติงานเป็นผลจากการกระทำผิดต่อบุคคลหรือที่จัดตั้งขึ้น บริษัทจะหลบหนีได้ยากกว่าบริษัทที่เกี่ยวข้องกับการดำเนินการโดยใช้นามแฝง Chainlink เข้ากันได้กับเทคโนโลยีการระบุตัวตนแบบกระจายอำนาจ (ส่วนที่ 4.3) สามารถให้การสนับสนุนการใช้ชื่อเสียงภายนอกใน IIF ได้ เทคโนโลยีดังกล่าว สามารถตรวจสอบและช่วยให้มั่นใจในความจริงของโลกแห่งความเป็นจริงที่ผู้ปฏิบัติงานยืนยัน ตัวตน19 9.6.4 เปิดการวิเคราะห์ IIF ตามที่เราได้ระบุไว้ IIF มีเป้าหมายที่จะให้ข้อมูลและเครื่องมือโอเพ่นซอร์สที่เชื่อถือได้ การวิเคราะห์แรงจูงใจโดยนัย เป้าหมายคือเพื่อให้ผู้ให้บริการภายในชุมชน เพื่อพัฒนาการวิเคราะห์ที่เหมาะกับความต้องการในการประเมินความเสี่ยงในส่วนต่างๆ ของ Chainlink ฐานผู้ใช้ 19ข้อมูลประจำตัวที่มีการกระจายอำนาจสามารถเสริมแต่งนามแฝงด้วยการตรวจสอบความถูกต้องได้หากต้องการ ข้อมูลเสริม ตัวอย่างเช่น ผู้ดำเนินการโหนดโดยหลักการแล้วสามารถใช้ข้อมูลรับรองดังกล่าวได้ พิสูจน์ว่าเป็นบริษัท Fortune 500 โดยไม่เปิดเผยว่าเป็นบริษัทใดข้อมูลประวัติจำนวนมากเกี่ยวกับรายได้และประสิทธิภาพของโหนด อยู่บนห่วงโซ่ในรูปแบบที่มีความน่าเชื่อถือสูงและไม่เปลี่ยนรูป อย่างไรก็ตาม เป้าหมายของเราคือการจัดให้มี ข้อมูลที่ครอบคลุมมากที่สุด รวมถึงข้อมูลเกี่ยวกับพฤติกรรมที่มองเห็นได้จากเท่านั้น เชน เช่น กิจกรรม OF-Chain Reporting (OCR) หรือ DON ข้อมูลดังกล่าวสามารถ มีมากมาย วิธีที่ดีที่สุดในการจัดเก็บและรับรองความสมบูรณ์ของข้อมูล เช่น การปกป้องจาก เราเชื่อว่าการปลอมแปลงจะได้รับความช่วยเหลือจาก DONs โดยใช้เทคนิคที่กล่าวถึง ในมาตรา 3.3 สิ่งจูงใจบางประการส่งเสริมรูปแบบการวัดผลโดยตรง เช่น staking เงินฝากและ FFO ขั้นพื้นฐาน ส่วนอื่นๆ เช่น FFO ที่เป็นการเก็งกำไรและชื่อเสียงนั้นทำได้ยากกว่า วัดในลักษณะที่เป็นกลาง แต่เราเชื่อว่าสนับสนุนรูปแบบของข้อมูลรวมถึง การเติบโตในอดีตของระบบนิเวศ Chainlink ตัวชี้วัดชื่อเสียงของโซเชียลมีเดีย ฯลฯ สามารถรองรับโมเดลการวิเคราะห์ IIF ได้แม้กระทั่งองค์ประกอบที่ยากต่อการหาปริมาณเหล่านี้ เราสามารถจินตนาการได้ว่า DONs เฉพาะที่เกิดขึ้นโดยเฉพาะในการตรวจสอบ ตรวจสอบ และ บันทึกข้อมูลที่เกี่ยวข้องกับบันทึกประสิทธิภาพของโหนดตลอดจนข้อมูลอื่น ๆ ใช้ใน IIF เช่นข้อมูลประจำตัวที่ผ่านการตรวจสอบแล้ว DONs เหล่านี้สามารถให้ข้อมูล IIF ที่สม่ำเสมอและมีความน่าเชื่อถือสูงสำหรับผู้ให้บริการการวิเคราะห์ที่ให้บริการชุมชน Chainlink พวกเขายังจะมอบบันทึกทองที่อ้างสิทธิ์ของผู้ให้บริการวิเคราะห์ สามารถตรวจสอบได้โดยชุมชนอย่างอิสระ 9.7 การรวมทุกอย่างเข้าด้วยกัน: สิ่งจูงใจของผู้ดำเนินการโหนด สังเคราะห์การสนทนาของเราข้างต้นเกี่ยวกับสิ่งจูงใจที่ชัดเจนและโดยปริยายสำหรับผู้ดำเนินการโหนด ให้มุมมองแบบองค์รวมของวิธีการที่ผู้ดำเนินการโหนดมีส่วนร่วมและได้รับประโยชน์จาก เครือข่าย Chainlink ตามแนวทางเชิงแนวคิด เราสามารถแสดงสินทรัพย์ทั้งหมดที่เป็นเดิมพันตาม Chainlink ที่กำหนด ตัวดำเนินการโหนด $S ในรูปแบบคร่าวๆ และเก๋ไก๋ดังนี้: \(S ≈\)D + \(F + \)FS + $อาร์ ที่ไหน: • $D คือผลรวมของเงินเดิมพันที่ฝากไว้อย่างชัดเจนในทุกเครือข่ายที่ ผู้ปฏิบัติงานเข้าร่วม • $F คือมูลค่าปัจจุบันสุทธิของผลรวมของ FFO ทั้งหมดในเครือข่ายทั้งหมด ซึ่งผู้ปฏิบัติงานมีส่วนร่วม • $FS คือมูลค่าปัจจุบันสุทธิของ FFO เชิงเก็งกำไรของผู้ดำเนินการ และ • $R คือชื่อเสียงของผู้ปฏิบัติงานที่อยู่นอกระบบนิเวศ Chainlink ที่อาจเป็นอันตรายต่อการระบุพฤติกรรมที่ไม่เหมาะสมในโหนด oracle แม้ว่าจะเป็นแนวคิดส่วนใหญ่ ความเท่าเทียมกันคร่าวๆ นี้แสดงให้เห็นอย่างเป็นประโยชน์ว่ามีปัจจัยทางเศรษฐกิจหลายประการซึ่งสนับสนุนประสิทธิภาพความน่าเชื่อถือสูงโดยโหนด Chainlink ปัจจัยทั้งหมดเหล่านี้นอกเหนือจาก $D มีอยู่ในเครือข่าย Chainlink ในปัจจุบัน9.8 วงจรคุณธรรมแห่งความมั่นคงทางเศรษฐกิจ การรวมกันของผลกระทบแบบซุปเปอร์เชิงเส้น staking พร้อมการแสดงการชำระค่าธรรมเนียม เนื่องจากโอกาสค่าธรรมเนียมในอนาคต (FFO) ใน IIF สามารถนำไปสู่สิ่งที่เราเรียกว่าวงจรคุณธรรม ของความมั่นคงทางเศรษฐกิจในเครือข่าย oracle นี่ถือได้ว่าเป็นเศรษฐกิจประเภทหนึ่ง ของขนาด เมื่อจำนวนเงินทั้งหมดที่ป้องกันโดยเครือข่ายใดเครือข่ายหนึ่งเพิ่มขึ้น จำนวนเงินของ สัดส่วนการถือหุ้นเพิ่มเติมที่ใช้ในการเพิ่มความมั่นคงทางเศรษฐกิจจำนวนหนึ่งจะลดลงเช่นเดียวกัน ต้นทุนเฉลี่ยต่อผู้ใช้ ดังนั้นจึงถูกกว่าในแง่ของค่าธรรมเนียมสำหรับผู้ใช้ในการเข้าร่วม เครือข่ายที่มีอยู่แล้วมากกว่าที่จะบรรลุการเพิ่มขึ้นเท่าเดิมในเศรษฐกิจเครือข่าย ความปลอดภัยด้วยการสร้างเครือข่ายใหม่ ที่สำคัญการเพิ่มผู้ใช้ใหม่แต่ละรายจะลดลง ต้นทุนการบริการสำหรับผู้ใช้ก่อนหน้าทั้งหมดของเครือข่ายนั้น ด้วยโครงสร้างค่าธรรมเนียมเฉพาะ (เช่น อัตราผลตอบแทนเฉพาะของจำนวนเงินที่วางเดิมพัน) หากค่าธรรมเนียมรวมที่ได้รับจากเครือข่ายเพิ่มขึ้น สิ่งนี้จะจูงใจให้เกิดการไหลเวียนเพิ่มเติม เดิมพันในเครือข่ายเพื่อรักษาความปลอดภัยในอัตราที่สูงขึ้น โดยเฉพาะถ้าเงินเดิมพันทั้งหมด แต่ละโหนดอาจถืออยู่ในระบบถูกต่อยอดแล้วเมื่อมีการชำระค่าธรรมเนียมใหม่ เข้าสู่ระบบโดยเพิ่ม FFO จำนวนโหนด n จะเพิ่มขึ้น ขอขอบคุณ ผลกระทบเชิงเส้นสุดยอด staking ของการออกแบบระบบสิ่งจูงใจของเรา ความมั่นคงทางเศรษฐกิจของ ระบบจะเพิ่มขึ้นเร็วกว่า n เช่น n2 ในกลไกที่เราร่างไว้ในส่วนที่ 9.4 เป็นผลให้ต้นทุนเฉลี่ยสำหรับความมั่นคงทางเศรษฐกิจ—เช่น จำนวนหุ้นที่มีส่วนร่วม ความมั่นคงทางเศรษฐกิจหนึ่งดอลลาร์—จะลดลง เครือข่ายจึงสามารถเรียกเก็บเงินจากผู้ใช้ได้ ค่าธรรมเนียมที่ต่ำกว่า สมมติว่าความต้องการบริการ oracle นั้นมีความยืดหยุ่น (ดู เช่น [31] สำหรับการสรุป คำอธิบาย) ความต้องการจะเพิ่มขึ้น ก่อให้เกิดค่าธรรมเนียมและ FFO เพิ่มเติม เราอธิบายประเด็นนี้ด้วยตัวอย่างต่อไปนี้ ตัวอย่างที่ 5 เนื่องจากความมั่นคงทางเศรษฐกิจของเครือข่าย oracle ด้วยแรงจูงใจของเรา โครงการคือ \(dn2 for stake \)dn ความมั่นคงทางเศรษฐกิจที่มีส่วนสนับสนุนโดยเงินเดิมพันหนึ่งดอลลาร์ คือ n ดังนั้นต้นทุนเฉลี่ยต่อดอลลาร์ของความมั่นคงทางเศรษฐกิจ เช่น จำนวนหุ้น มีส่วนทำให้เกิดความมั่นคงทางเศรษฐกิจหนึ่งดอลลาร์—คือ 1/n พิจารณาเครือข่ายที่สิ่งจูงใจทางเศรษฐกิจประกอบด้วย FFO ทั้งหมดต่อยอด ที่ \(d ≤\)10K ต่อโหนด สมมติว่าเครือข่ายมี n = 3 โหนด แล้วต้นทุนเฉลี่ย. ความมั่นคงทางเศรษฐกิจต่อดอลลาร์อยู่ที่ประมาณ 0.33 ดอลลาร์ สมมติว่า FFO ทั้งหมดของเครือข่ายเพิ่มขึ้นมากกว่า \(30K (e.g., to \)31K) มอบให้ ค่าสูงสุดของ FFO ต่อโหนด เครือข่ายจะเติบโตเป็น (อย่างน้อย) n = 4 ตอนนี้ต้นทุนเฉลี่ย ความมั่นคงทางเศรษฐกิจต่อดอลลาร์ลดลงเหลือประมาณ 0.25 ดอลลาร์ เราแสดงให้เห็นวงจรความมั่นคงทางเศรษฐกิจที่สมบูรณ์ในเครือข่าย oracle ตามแผนผังในรูปที่ 18 เราเน้นย้ำว่าวงจรอันชอบธรรมของความมั่นคงทางเศรษฐกิจนั้นเกิดขึ้นจากผลกระทบ ของผู้ใช้ที่รวมค่าธรรมเนียมเข้าด้วยกัน FFO แบบรวมของพวกเขาทำหน้าที่เพื่อประโยชน์ที่ใหญ่กว่า ขนาดเครือข่ายและความปลอดภัยโดยรวมที่มากขึ้น เรายังทราบด้วยว่าวงจรคุณธรรม ของความมั่นคงทางเศรษฐกิจทำงานเพื่อให้ DONs บรรลุความยั่งยืนทางการเงิน ครั้งหนึ่ง สร้างขึ้น DONs ที่ตอบสนองความต้องการของผู้ใช้ควรเติบโตไปไกลกว่าจุดนั้น รายได้จากค่าธรรมเนียมสูงกว่าต้นทุนการดำเนินงานสำหรับโหนด oracle

รูปที่ 18: แผนผังวงจรคุณธรรมของ Chainlink staking ค่าธรรมเนียมผู้ใช้เพิ่มขึ้น การชำระเงินให้กับเครือข่าย oracle 1⃝ ทำให้มันเติบโต ซึ่งนำไปสู่การเติบโตทางเศรษฐกิจ ความปลอดภัย 2⃝ การเติบโตแบบเชิงเส้นตรงนี้ทำให้เกิดการประหยัดจากขนาดในเครือข่าย Chainlink 3⃝. โดยเฉพาะอย่างยิ่ง หมายถึงการลดต้นทุนโดยเฉลี่ยของความมั่นคงทางเศรษฐกิจ กล่าวคือ ความมั่นคงทางเศรษฐกิจต่อดอลลาร์ที่เกิดจากการชำระค่าธรรมเนียมหรือแหล่งที่มาอื่น ๆ เพิ่มขึ้น ต้นทุนที่ลดลง ส่งต่อไปยังผู้ใช้ กระตุ้นความต้องการที่เพิ่มขึ้นสำหรับ oracle บริการ4⃝ 9.9 ปัจจัยเพิ่มเติมที่ขับเคลื่อนการเติบโตของเครือข่าย ในขณะที่ระบบนิเวศ Chainlink ยังคงขยายตัวอย่างต่อเนื่อง เราเชื่อว่าความน่าดึงดูดใจของมัน ต่อผู้ใช้และความสำคัญในฐานะโครงสร้างพื้นฐานสำหรับเศรษฐกิจ blockchain จะเพิ่มขึ้นอย่างรวดเร็ว ค่าที่ได้รับจากเครือข่าย oracle เป็นแบบซุปเปอร์เชิงเส้น ซึ่งหมายความว่าจะขยายเร็วขึ้นมากกว่าขนาดของเครือข่ายเอง การเติบโตของมูลค่านี้มาจากทั้งสองอย่าง การประหยัดต่อขนาด—ความคุ้มค่าต่อต้นทุนต่อผู้ใช้ที่มากขึ้นเมื่อปริมาณการบริการเพิ่มขึ้น—และ ผลกระทบของเครือข่าย—การเพิ่มขึ้นของอรรถประโยชน์เครือข่ายเมื่อผู้ใช้ปรับใช้ DONs ในวงกว้างมากขึ้น เนื่องจาก smart contracts ที่มีอยู่ยังคงเห็นคุณค่าที่มากขึ้นและมีความปลอดภัยและใหม่ทั้งหมด แอปพลิเคชัน smart contract เกิดขึ้นได้จากบริการที่มีการกระจายอำนาจมากขึ้น รวมทั้งหมด การใช้และค่าธรรมเนียมรวมที่ชำระให้กับ DONs น่าจะเพิ่มขึ้น ค่าธรรมเนียมที่เพิ่มขึ้นใน เปลี่ยนการแปลเป็นวิธีการและแรงจูงใจในการสร้างบริการที่มีการกระจายอำนาจมากยิ่งขึ้น ส่งผลให้เกิดวงจรคุณธรรม วงจรอันดีงามนี้ช่วยแก้ปัญหาไก่และไข่วิกฤติได้ ปัญหาในระบบนิเวศไฮบริด smart contract: คุณสมบัตินวัตกรรม smart contract มักจะต้องการบริการแบบกระจายอำนาจที่ยังไม่มีอยู่ (เช่น ตลาด DeFi ใหม่บ่อยครั้ง ต้องการฟีดข้อมูลใหม่) แต่จำเป็นต้องมีความต้องการทางเศรษฐกิจที่เพียงพอเพื่อให้เกิดขึ้นได้ การรวมค่าธรรมเนียมโดย smart contracts ต่างๆ สำหรับ DONs ที่มีอยู่จะส่งสัญญาณถึงความต้องการ บริการกระจายอำนาจเพิ่มเติมจากฐานผู้ใช้ที่กำลังเติบโต ก่อให้เกิดการสร้างสรรค์ของพวกเขา โดย DONs และการเปิดใช้งาน smart contracts แบบไฮบริดใหม่และหลากหลายอย่างต่อเนื่อง โดยสรุป เราเชื่อว่าการเติบโตของความปลอดภัยเครือข่ายขับเคลื่อนด้วยความมีคุณธรรม วงจรในกลไก Chainlink staking เป็นตัวอย่างรูปแบบการเติบโตที่ใหญ่กว่านั้น เครือข่าย Chainlink สามารถช่วยนำมาซึ่งเศรษฐกิจแบบออนไลน์สำหรับการกระจายอำนาจ บริการ

บทสรุป

ในบทความนี้ เราได้กำหนดวิสัยทัศน์สำหรับวิวัฒนาการของ Chainlink ธีมหลัก ในวิสัยทัศน์นี้คือความสามารถของเครือข่าย oracle ในการให้บริการที่หลากหลายมากขึ้น smart contracts มากกว่าการส่งข้อมูลเพียงอย่างเดียว การใช้ DONs เป็นรากฐานสำหรับบริการแบบกระจายอำนาจแห่งอนาคต Chainlink จะมุ่งหวังที่จะมอบฟังก์ชันการทำงานของ oracle ที่มีประสิทธิภาพและรักษาความลับมากขึ้น เครือข่าย oracle ของมันจะมีการลดความน่าเชื่อถืออย่างมาก ผ่านการผสมผสานของกลไกเศรษฐกิจเข้ารหัสเชิงหลักการ เช่น staking และ สร้างราวกั้นอย่างระมัดระวังและการบังคับใช้ระดับการบริการบนโซ่หลักที่ต้องพึ่งพา DONs ยังช่วยให้ระบบเลเยอร์ 2 บังคับใช้นโยบายการสั่งซื้อที่เป็นธรรมและยืดหยุ่นได้ในธุรกรรม เช่นเดียวกับการลดต้นทุนค่าน้ำมันสำหรับธุรกรรมที่กำหนดเส้นทางแบบ mempool นำมารวมกัน, ความสามารถเหล่านี้ล้วนขับเคลื่อนไปในทิศทางของไฮบริดอัจฉริยะที่มีความปลอดภัยและฟังก์ชันครบครัน สัญญา ความสามารถในการยืดหยุ่นของ DONs จะปรับปรุงบริการ Chainlink ที่มีอยู่ และก่อให้เกิด คุณสมบัติและแอปพลิเคชัน smart contract เพิ่มเติมมากมาย กลุ่มคนเหล่านี้ไร้รอยต่อ การเชื่อมต่อกับระบบ off-chain ที่หลากหลาย การสร้างเอกลักษณ์แบบกระจายอำนาจจาก ข้อมูลที่มีอยู่ ช่องทางการจัดลำดับความสำคัญเพื่อช่วยให้แน่ใจว่าการส่งมอบโครงสร้างพื้นฐานที่สำคัญทันเวลา ธุรกรรมและเครื่องมือ DeFi ที่รักษาความลับ วิสัยทัศน์ที่เรากำหนดไว้ที่นี่มีความทะเยอทะยาน ในระยะสั้น เราพยายามที่จะเสริมศักยภาพ สัญญาแบบผสมเพื่อบรรลุเป้าหมายที่เกินขอบเขตของ smart contracts ในปัจจุบัน ในระยะยาวเรามุ่งมั่นที่จะสร้าง metalayer ที่มีการกระจายอำนาจ ดีใจที่เราสามารถวาดได้ เกี่ยวกับเครื่องมือและแนวคิดใหม่ๆ ตั้งแต่อัลกอริธึมที่เป็นเอกฉันท์ไปจนถึงการพิสูจน์ความรู้เป็นศูนย์ ระบบ—ที่ชุมชนกำลังพัฒนาเป็นผลจากการวิจัยที่มีการพัฒนาอย่างรวดเร็ว

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