การแนะนำ

function getAbsolutelyRandomNumer() {
        return 4; // returns absolutely random number!
}

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

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

สองวิธีในการนำ PVRB ไปใช้

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

สัญญาแบบสแตนด์อโลน

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

ตัวเลือกที่มีสัญญาแบบสแตนด์อโลนนั้นดี:

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

นอกจากนี้ยังมีข้อเสีย:

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

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

ฉันทามติแบบบูรณาการ

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

เมื่ออธิบายการใช้งาน PVRB ในระดับฉันทามติของเครือข่าย ไม่มีใครสามารถหลีกเลี่ยงปัญหาขั้นสุดท้ายได้ไม่ว่าด้วยวิธีใดก็ตาม สุดท้ายเป็นกลไกที่ใช้ในฉันทามติที่กำหนดขึ้นซึ่งล็อคอยู่ในบล็อก (และห่วงโซ่ที่นำไปสู่บล็อกนั้น) ซึ่งเป็นที่สิ้นสุดและจะไม่มีวันถูกโยนทิ้งไป แม้ว่าจะมีทางแยกขนานเกิดขึ้นก็ตาม ตัวอย่างเช่น ใน Bitcoin ไม่มีกลไกดังกล่าว - หากคุณเผยแพร่ห่วงโซ่ที่มีความซับซ้อนมากขึ้น มันจะเข้ามาแทนที่กลไกที่ซับซ้อนน้อยกว่า โดยไม่คำนึงถึงความยาวของห่วงโซ่ ตัวอย่างเช่นใน EOS บล็อกสุดท้ายเรียกว่า Last Irreversible Blocks ซึ่งปรากฏโดยเฉลี่ยทุกๆ 432 บล็อก (12*21 + 12*15, โหวตล่วงหน้า + กระทำล่วงหน้า) โดยพื้นฐานแล้วกระบวนการนี้กำลังรอลายเซ็นของผู้ผลิตบล็อก 2/3 (ต่อไปนี้จะเรียกว่า BP) เมื่อส้อมปรากฏขึ้นซึ่งเก่ากว่า LIB สุดท้าย ส้อมเหล่านั้นจะถูกละทิ้งไป กลไกนี้ทำให้สามารถรับประกันได้ว่าธุรกรรมจะรวมอยู่ในบล็อกเชน และจะไม่มีวันถูกย้อนกลับ ไม่ว่าผู้โจมตีจะมีทรัพยากรใดก็ตาม นอกจากนี้ บล็อกสุดท้ายยังเป็นบล็อกที่ลงนามโดย 2/3 BP ใน Hyperledger, Tendermint และมติอื่นๆ ที่ใช้ pBFT นอกจากนี้ การสร้างโปรโตคอลเพื่อให้แน่ใจว่าเป็นส่วนเสริมที่เป็นเอกฉันท์ในขั้นสุดท้าย เนื่องจากสามารถทำงานแบบอะซิงโครนัสกับการผลิตและการเผยแพร่บล็อกได้ นี่เป็นสิ่งที่ดี บทความ เกี่ยวกับจุดสิ้นสุดใน Ethereum

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

ดังนั้น ทางเลือกที่ดีที่สุดคือการรวม PVRB และ Finality ไว้ในโปรโตคอลเดียว จากนั้นบล็อกที่สรุปผล = สุ่มสรุป และนี่คือสิ่งที่เราจำเป็นต้องได้รับ ตอนนี้ผู้เล่นจะได้รับการสุ่มรับประกันภายใน N วินาที และมั่นใจได้ว่าจะไม่สามารถย้อนกลับหรือเล่นซ้ำอีกครั้งได้

ตัวเลือกบูรณาการฉันทามติเป็นสิ่งที่ดี:

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

นอกจากนี้ยังมีข้อเสีย:

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

ทั้งสองวิธีในการนำ PVRB ไปใช้มีสิทธิ์ที่จะมีชีวิต แต่การใช้งานสัญญาอัจฉริยะในบล็อกเชนสมัยใหม่ยังมีข้อจำกัดด้านทรัพยากรในการประมวลผลค่อนข้างมาก และการเปลี่ยนไปใช้การเข้ารหัสที่ร้ายแรงมักเป็นไปไม่ได้เลย และเราต้องการการเข้ารหัสที่จริงจัง ดังที่แสดงด้านล่าง แม้ว่าปัญหานี้จะเกิดขึ้นชั่วคราวอย่างชัดเจน แต่จำเป็นต้องมีการเข้ารหัสที่จริงจังในสัญญาเพื่อแก้ไขปัญหาต่างๆ และปัญหานี้ก็ค่อยๆ ปรากฏขึ้น (เช่น สัญญาระบบสำหรับ zkSNARK ใน Ethereum)

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

PVRB และตัวแปรบล็อก

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

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

แต่แม้แต่แฮชที่ปลอดภัยหลังควอนตัมก็ยังไม่เพียงพอ ความลับอยู่ในข้อกำหนดสำหรับ PVRB ฉันขอเตือนคุณจากบทความก่อนหน้านี้:

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

ในกรณีนี้เป็นไปตามข้อกำหนด 1 เท่านั้นและไม่เป็นไปตามข้อกำหนด 2 โดยการแฮชค่าที่คาดเดาไม่ได้จากบล็อกเราจะได้รับการกระจายที่สม่ำเสมอและการสุ่มที่ดี แต่อย่างน้อย BP ก็มีตัวเลือกในการ "เผยแพร่บล็อกหรือไม่" ดังนั้น BP อย่างน้อยสามารถเลือกจากสองตัวเลือกแบบสุ่ม: "ของตัวเอง" และตัวเลือกที่จะปรากฎหากมีคนอื่นสร้างบล็อก BP สามารถ "สอดแนม" ล่วงหน้าได้ว่าจะเกิดอะไรขึ้นหากเขาเผยแพร่บล็อก และตัดสินใจว่าจะดำเนินการหรือไม่ ดังนั้น เมื่อเล่นรูเล็ต เช่น “คู่-คี่” หรือ “แดง/ดำ” เขาสามารถเผยแพร่บล็อกได้ก็ต่อเมื่อเห็นว่าชนะเท่านั้น นอกจากนี้ยังทำให้กลยุทธ์การใช้บล็อกแฮช "จากอนาคต" ไม่สามารถใช้งานได้ ในกรณีนี้ พวกเขากล่าวว่า “จะใช้แบบสุ่ม ซึ่งได้มาจากการแฮชข้อมูลปัจจุบันและแฮชของบล็อกในอนาคตที่มีความสูง เช่น N + 42 โดยที่ N คือความสูงของบล็อกปัจจุบัน สิ่งนี้ทำให้โครงการแข็งแกร่งขึ้นเล็กน้อย แต่ยังคงช่วยให้ BP สามารถเลือกได้ว่าจะระงับบล็อกหรือเผยแพร่ในอนาคต แม้ว่าในอนาคต

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

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

PVRB และการเปิดเผยการกระทำ

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

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

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

PVRB และลายเซ็นที่กำหนด

มีอีกวิธีหนึ่งในการบังคับให้ RP จัดเตรียมตัวเลขสุ่มหลอกซึ่งไม่สามารถมีอิทธิพลได้หากมี "ภาพล่วงหน้า" มาให้ - นี่คือลายเซ็นที่กำหนด ลายเซ็นดังกล่าวคือ ตัวอย่างเช่น RSA และไม่ใช่ ECS หาก RP มีคีย์คู่หนึ่ง: RSA และ ECC และเขาลงนามค่าบางอย่างด้วยคีย์ส่วนตัวของเขา ในกรณีของ RSA เขาจะได้รับลายเซ็นเดียวเท่านั้น และในกรณีของ ECS เขาสามารถสร้างจำนวนเท่าใดก็ได้ของ ลายเซ็นที่ถูกต้องที่แตกต่างกัน เนื่องจากเมื่อสร้างลายเซ็น ECS จะมีการใช้ตัวเลขสุ่มโดยผู้ลงนามเลือก และสามารถเลือกด้วยวิธีใดก็ได้ ทำให้ผู้ลงนามมีโอกาสเลือกลายเซ็นใดลายเซ็นหนึ่งจากหลายลายเซ็น ในกรณีของ RSA: “หนึ่งค่าอินพุต” + “หนึ่งคู่คีย์” = “หนึ่งลายเซ็น” เป็นไปไม่ได้ที่จะคาดเดาว่า RP อื่นจะได้รับลายเซ็นใด ดังนั้น PVRB ที่มีลายเซ็นที่กำหนดสามารถจัดระเบียบได้โดยการรวมลายเซ็น RSA ของผู้เข้าร่วมหลายคนที่ลงนามในค่าเดียวกัน เช่น การสุ่มครั้งก่อน โครงการนี้ช่วยประหยัดทรัพยากรได้มากเพราะว่า ลายเซ็นเป็นทั้งการยืนยันพฤติกรรมที่ถูกต้องตามโปรโตคอลและเป็นแหล่งที่มาของการสุ่ม

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

PVRB และแผนการแบ่งปันความลับ

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

หากโครงการ FSSS (Fiat-Shamir Secret Sharing) ถูกนำมาใช้ในรูปแบบที่บริสุทธิ์ มันจะเป็น PVRB ที่ไม่สามารถทำลายได้ ในรูปแบบที่ง่ายที่สุด โปรโตคอลอาจมีลักษณะดังนี้:

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

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

นี่อาจเป็นตัวเลือกในอุดมคติ โครงการ PVRB นี้ที่ใช้การแบ่งปันความลับของ Fiat-Shamir ได้รับการอธิบายไว้เป็นตัวอย่าง นี้ บทความ. แต่ดังที่กล่าวไว้ข้างต้น หากคุณพยายามนำไปใช้โดยตรงในบล็อกเชน ข้อจำกัดทางเทคนิคก็จะปรากฏขึ้น นี่คือตัวอย่างการทดสอบการใช้งานโปรโตคอลในสัญญาอัจฉริยะของ EOS และส่วนที่สำคัญที่สุด - การตรวจสอบผู้เข้าร่วมการแชร์ที่เผยแพร่: รหัส. คุณสามารถดูได้จากโค้ดว่าการตรวจสอบความถูกต้องของการพิสูจน์ต้องใช้การคูณสเกลาร์หลายครั้ง และตัวเลขที่ใช้มีขนาดใหญ่มาก ควรเข้าใจว่าในบล็อกเชน การตรวจสอบจะเกิดขึ้นในขณะที่ผู้ผลิตบล็อกประมวลผลธุรกรรม และโดยทั่วไป ผู้เข้าร่วมใดๆ จะต้องตรวจสอบความถูกต้องของโปรโตคอลอย่างง่ายดาย ดังนั้นข้อกำหนดสำหรับความเร็วของฟังก์ชันตรวจสอบจึงมีความสำคัญมาก . ในตัวเลือกนี้ ตัวเลือกนี้กลายเป็นว่าไม่ได้ผล เนื่องจากการตรวจสอบไม่พอดีกับขีดจำกัดธุรกรรม (0.5 วินาที)

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

PVRB และลายเซ็นเกณฑ์

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

การรวมกันของลายเซ็นที่กำหนดและแผนเกณฑ์ทำให้สามารถพัฒนารูปแบบที่สะดวกและมีแนวโน้มมากสำหรับการนำ PVRB ไปใช้ - สิ่งเหล่านี้คือลายเซ็นเกณฑ์ที่กำหนด ที่นี่ บทความ เกี่ยวกับการใช้ลายเซ็นเกณฑ์ต่างๆ และนี่คือข้อดีอีกอย่างหนึ่ง longread จากแดช.

บทความสุดท้ายอธิบายลายเซ็น BLS (BLS ย่อมาจาก Boneh-Lynn-Scham ที่นี่ บทความ) ซึ่งมีคุณภาพที่สำคัญและสะดวกอย่างยิ่งสำหรับโปรแกรมเมอร์ - สาธารณะ, ความลับ, กุญแจสาธารณะและลายเซ็น BLS สามารถรวมเข้าด้วยกันได้โดยใช้การดำเนินการทางคณิตศาสตร์อย่างง่าย ในขณะที่ชุดค่าผสมยังคงเป็นคีย์และลายเซ็นที่ถูกต้อง ช่วยให้คุณสามารถรวมหลาย ๆ อย่างได้อย่างง่ายดาย ลายเซ็นเป็นหนึ่งเดียวและหลายกุญแจสาธารณะเป็นหนึ่งเดียว นอกจากนี้ยังกำหนดไว้และให้ผลลัพธ์เดียวกันสำหรับข้อมูลอินพุตเดียวกัน เนื่องจากคุณภาพนี้ การรวมกันของลายเซ็น BLS จึงเป็นคีย์ที่ถูกต้อง ซึ่งช่วยให้สามารถนำตัวเลือกที่ผู้เข้าร่วม M จาก N สร้างลายเซ็นเดียวและลายเซ็นเดียวเท่านั้นที่กำหนดได้ ตรวจสอบได้ต่อสาธารณะ และคาดเดาไม่ได้จนกว่า Mth จะถูกเปิด ผู้เข้าร่วม .

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

ดังนั้น หากคุณกำลังสร้าง PVRB บนบล็อกเชนของคุณ คุณมักจะจบลงด้วยรูปแบบลายเซ็นเกณฑ์ BLS ซึ่งหลายโครงการกำลังใช้งานอยู่ ตัวอย่างเช่น DFinity (ที่นี่ เกณฑ์มาตรฐานที่ใช้วงจรและ ที่นี่ ตัวอย่างการใช้งานการแบ่งปันความลับที่ตรวจสอบได้) หรือ Keep.network (นี่คือสัญญาณสุ่ม กระดาษเหลืองและที่นี่ ตัวอย่าง สัญญาอัจฉริยะที่ให้บริการโปรโตคอล)

การดำเนินการ PVRB

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

ฉันจะแสดงรายการปัจจัยที่คุณจะต้องพิจารณาเมื่อเลือก PVRB ที่มีคุณภาพ:

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

ตัวอย่างเช่น ลายเซ็น BLS ตามเกณฑ์มีปัญหาสำคัญ - ก่อนที่จะเริ่มทำงาน ผู้เข้าร่วมจะต้องแจกจ่ายคีย์ให้กันและกัน โดยจัดกลุ่มภายในเกณฑ์ที่จะใช้งานได้ ซึ่งหมายความว่าจะต้องมีการแลกเปลี่ยนอย่างน้อยหนึ่งรอบในเครือข่ายการกระจายอำนาจ และเนื่องจากแรนด์ที่สร้างขึ้นนั้นมีความจำเป็นในเกม เกือบจะแบบเรียลไทม์ ซึ่งหมายความว่าการก่อวินาศกรรมของโปรโตคอลเป็นไปได้ในขั้นตอนนี้ และข้อดีของโครงการเกณฑ์ก็จะหายไป ปัญหานี้ง่ายกว่าปัญหาก่อนหน้านี้ แต่ก็ยังต้องมีการพัฒนาขั้นตอนแยกต่างหากสำหรับการสร้างกลุ่มเกณฑ์ซึ่งจะต้องได้รับการคุ้มครองเชิงเศรษฐกิจผ่านการฝากและถอนเงิน (อย่างเจ็บแสบ) จากผู้เข้าร่วมที่ไม่ปฏิบัติตาม มาตรการ. นอกจากนี้ การตรวจสอบ BLS ด้วยระดับความปลอดภัยที่ยอมรับได้นั้นไม่เหมาะกับการทำธุรกรรม EOS หรือ Ethereum มาตรฐาน เนื่องจากมีเวลาไม่เพียงพอในการตรวจสอบ รหัสสัญญาคือ WebAssembly หรือ EVM ซึ่งดำเนินการโดยเครื่องเสมือน ฟังก์ชันการเข้ารหัสยังไม่ได้ถูกนำมาใช้ตั้งแต่แรก (แต่) และทำงานช้ากว่าไลบรารีการเข้ารหัสทั่วไปหลายสิบเท่า โปรโตคอลจำนวนมากไม่ตรงตามข้อกำหนดโดยอิงจากปริมาณคีย์ เช่น 1024 และ 2048 บิตสำหรับ RSA ซึ่งใหญ่กว่าลายเซ็นธุรกรรมมาตรฐานใน Bitcoin และ Ethereum ถึง 4-8 เท่า

การมีอยู่ของการใช้งานในภาษาการเขียนโปรแกรมที่แตกต่างกันก็มีบทบาทเช่นกัน ซึ่งมีน้อยโดยเฉพาะอย่างยิ่งสำหรับโปรโตคอลใหม่ ตัวเลือกที่มีการผสานรวมเป็นเอกฉันท์จำเป็นต้องเขียนโปรโตคอลในภาษาแพลตฟอร์ม ดังนั้นคุณจะต้องค้นหาโค้ดใน Go for geth ใน Rust for Parity ใน C++ สำหรับ EOS ทุกคนจะต้องค้นหาโค้ด JavaScript และเนื่องจาก JavaScript และการเข้ารหัสไม่ใช่เพื่อนสนิทโดยเฉพาะ WebAssembly จะช่วยได้ ซึ่งตอนนี้อ้างว่าเป็นมาตรฐานอินเทอร์เน็ตที่สำคัญถัดไปอย่างแน่นอน

ข้อสรุป

ฉันหวังว่าในอันที่แล้ว статье ฉันพยายามโน้มน้าวคุณว่าการสร้างตัวเลขสุ่มบนบล็อกเชนมีความสำคัญต่อหลายแง่มุมของชีวิตเครือข่ายแบบกระจายอำนาจ และในบทความนี้ ฉันแสดงให้เห็นว่างานนี้มีความทะเยอทะยานและยากอย่างยิ่ง แต่มีวิธีแก้ปัญหาที่ดีอยู่แล้ว โดยทั่วไป การออกแบบโปรโตคอลขั้นสุดท้ายจะทำได้เฉพาะหลังจากทำการทดสอบจำนวนมากที่คำนึงถึงทุกแง่มุมตั้งแต่การตั้งค่าไปจนถึงการจำลองข้อผิดพลาด ดังนั้น คุณไม่น่าจะพบสูตรอาหารสำเร็จรูปในเอกสารไวท์เปเปอร์และบทความของทีม และแน่นอนว่าเราจะไม่ ตัดสินใจในปีหน้าหรือสองปีข้างหน้าว่า “ทำอย่างนี้ ถูกต้องเลย”

ลาก่อน สำหรับ PVRB ของเราในบล็อกเชนที่กำลังพัฒนา Hayaเราตกลงใจในการใช้ลายเซ็น BLS ตามเกณฑ์ เราวางแผนที่จะใช้ PVRB ในระดับที่เป็นเอกฉันท์ เนื่องจากการตรวจสอบในสัญญาอัจฉริยะที่มีระดับความปลอดภัยที่ยอมรับได้ยังไม่สามารถทำได้ เป็นไปได้ที่เราใช้สองแผนงานพร้อมกัน: ประการแรก การแบ่งปันความลับที่มีราคาแพงเพื่อสร้าง Random_seed ในระยะยาว จากนั้นเราใช้มันเป็นพื้นฐานสำหรับการสร้างแบบสุ่มความถี่สูงโดยใช้ลายเซ็น BLS ตามเกณฑ์ที่กำหนด บางทีเราอาจจำกัดตัวเราเองเพียงเท่านั้น หนึ่งในแผนการ น่าเสียดายที่เป็นไปไม่ได้ที่จะพูดล่วงหน้าว่าโปรโตคอลจะเป็นอย่างไร สิ่งเดียวที่ดีก็คือเช่นเดียวกับในด้านวิทยาศาสตร์ในปัญหาทางวิศวกรรมก็ให้ผลลัพธ์เชิงลบเช่นกันและความพยายามครั้งใหม่ในการแก้ปัญหาก็เป็นอีกก้าวหนึ่งสำหรับ การวิจัยของทุกคนที่เกี่ยวข้องกับปัญหา เพื่อตอบสนองความต้องการทางธุรกิจ เราได้แก้ไขปัญหาเชิงปฏิบัติโดยเฉพาะ - การจัดหาแอปพลิเคชันเกมที่มีแหล่งที่มาของเอนโทรปีที่เชื่อถือได้ ดังนั้นเราจึงต้องให้ความสนใจกับบล็อกเชนด้วย โดยเฉพาะอย่างยิ่งปัญหาของจุดสิ้นสุดของห่วงโซ่และการกำกับดูแลเครือข่าย

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

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

ที่มา: will.com