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

“คุณกำลังใช้ oracles ของคุณเอง? ทำไมไม่แค่เสียบเข้ากับ Chainlink?”

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

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

คำอธิบายพื้นฐานฉบับย่อ สำหรับทุกคนที่ไม่ได้อยู่ในวงการนี้

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

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

สิ่งที่เราต้องการให้คำทำนายของเราทำ

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

การแลกเปลี่ยนที่ต้องยอมรับ นำเสนออย่างตรงไปตรงมา

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

สำหรับเรา ช่องว่างนั้นกลายเป็นสามปัญหาที่แท้จริง:

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

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

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

สิ่งที่เราสร้างแทน: GHOST

GHOST คือโปรโตคอล Oracle ของเราเอง สร้างมาโดยเฉพาะสำหรับข้อมูลการโรงแรมและการเดินทาง ชื่อนี้ไม่มีความหมายอะไรพิเศษ มันสั้นและทีม backend ของเราชอบมัน

สิ่งต่างๆ ที่ GHOST ทำได้ซึ่ง Oracle แบบทั่วไปไม่สามารถทำได้:

• เส้นทางหลักภายในหนึ่งวินาที การสอบถามความพร้อมและราคาส่งคืนในหน่วยมิลลิวินาทีเพราะมันเป็นส่วนหนึ่งของระบบโดยกำเนิด ไม่ใช่ผ่านการเชื่อมต่อ
• โครงสร้างข้อมูลที่รู้จักโดเมน โปรโตคอลพูดถึง “การจอง” “แผนอัตรา” “นโยบายการยกเลิก” “เหตุการณ์เช็คอิน” ไม่ใช่แค่ฟีดตัวเลขทั่วไป
• การปรับขนาดต้นทุน ต้นทุน oracle เพิ่มเติมใกล้ศูนย์ที่ปริมาณสูง ซึ่งเป็นวิธีเดียวที่การประหยัดของผู้ให้บริการ 28 ถึง 36 เปอร์เซ็นต์ยั่งยืน
• การรวบรวมจากหลายแหล่ง GHOST รวบรวมสินค้าคงคลังและราคาจากเครือข่ายของเราที่ครอบคลุมทรัพย์สินหลายพันแห่ง ตรรกะการรวบรวมข้อมูลได้รับการปรับแต่งสำหรับกรณีการใช้งานธุรกิจโรงแรมโดยเฉพาะ
• การตรวจสอบอิสระ ระบบทั้งหมดได้ผ่านการตรวจสอบความปลอดภัยอิสระเป็นส่วนหนึ่งของกระบวนการตรวจสอบ smart-contract ที่กว้างขึ้นของเรา

สิ่งที่เรายอมแพ้

ฉันต้องการซื่อสัตย์เกี่ยวกับเรื่องนี้ การเป็นเจ้าของที่สิทธิ์การใช้งานไม่ได้ฟรี เรายอมรับต้นทุนจริงสามประการ

เราไม่ได้รับความปลอดภัยจากผลกระทบของเครือข่ายของชุด validator แบบกระจายศูนย์ขนาดใหญ่ทันที เราชดเชยด้วยการตรวจสอบ การกำกับดูแล multi-signature บนโปรโตคอล และโปรแกรม bug bounty ที่อัปเดตอย่างต่อเนื่อง แต่มันคือโมเดลความไว้วางใจที่แตกต่าง เรายอมรับอย่างเปิดเผย

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

เราไม่ได้รับการทำงานร่วมกันฟรีกับระบบนิเวศ DeFi ที่กว้างขึ้น หากเราต้องการบูรณาการกับโปรโตคอล DeFi ที่คาดหวังฟีด Chainlink เราต้องสร้างสะพานเชื่อม เราทำส่วนนี้บางส่วนแล้วและจะทำมากขึ้น

การพนันในประโยคเดียว

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

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

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

— Carol

ผู้จัดการชุมชน Tratok