พื้นฐานการแบ่งส่วน

มาเริ่มกันด้วยวิธีที่ง่ายที่สุดในการแบ่งส่วน ในแนวทางนี้แทน เรียกใช้หนึ่ง blockchain เราจะเรียกใช้หลายรายการ และเรียกแต่ละรายการดังกล่าว blockchain a “เศษ” แต่ละชาร์ดจะมีชุด validators ของตัวเอง ที่นี่และด้านล่างเราใช้ คำทั่วไป “validator” เพื่ออ้างถึงผู้เข้าร่วมที่ตรวจสอบธุรกรรมและ ผลิตบล็อกโดยการขุด เช่น ใน Proof of Work หรือผ่านการลงคะแนนเสียง 1ส่วนนี้เผยแพร่ก่อนหน้านี้ที่ https://near.ai/shard1. หากคุณได้อ่านมาก่อน ข้ามไปยังส่วนถัดไป

กลไก. ในตอนนี้ สมมติว่าชิ้นส่วนไม่เคยสื่อสารกับแต่ละส่วน อื่น ๆ การออกแบบนี้แม้ว่าจะเรียบง่าย แต่ก็เพียงพอที่จะสรุปความท้าทายหลักเบื้องต้นบางประการในการแบ่งส่วนได้ 1.1 การแบ่งพาร์ติชันเครื่องมือตรวจสอบและเครือข่ายบีคอน สมมติว่าระบบประกอบด้วย 10 ส่วน ความท้าทายแรกนั้นก็คือแต่ละ ชิ้นส่วนที่มี validators ของตัวเอง แต่ละชิ้นส่วนมีความปลอดภัยน้อยกว่า 10 เท่า ห่วงโซ่ทั้งหมด ดังนั้นหากเชนที่ไม่แบ่งส่วนซึ่งมี X validators ตัดสินใจที่จะฮาร์ดฟอร์ก ออกเป็นห่วงโซ่ที่แยกส่วน และแบ่ง X validators เป็น 10 ส่วน แต่ละส่วนในตอนนี้ มีเพียง X/10 validators และการเสียหายเพียงส่วนเดียวนั้นต้องการการเสียหายเท่านั้น 5.1% (51% / 10) ของจำนวน validators ทั้งหมด (ดูรูปที่ 1) รูปที่ 1: การแยก validators ออกเป็นชาร์ด ซึ่งนำเราไปสู่ประเด็นที่สอง: ใครเลือก validators สำหรับแต่ละส่วน การควบคุม validators 5.1% จะสร้างความเสียหายได้ก็ต่อเมื่อ 5.1% ของ validators ทั้งหมดนั้น อยู่ในส่วนเดียวกัน หาก validators ไม่สามารถเลือกชิ้นส่วนที่จะตรวจสอบได้ ใน ผู้เข้าร่วมที่ควบคุม 5.1% ของ validators นั้นไม่น่าจะได้รับทั้งหมด validators ของพวกเขาอยู่ในชาร์ดเดียวกัน ซึ่งลดความสามารถในการประนีประนอมลงอย่างมาก ระบบ การออกแบบการแบ่งส่วนเกือบทั้งหมดในปัจจุบันอาศัยแหล่งที่มาของการสุ่ม กำหนด validators ให้กับชาร์ด การสุ่มใน blockchain ในตัวมันเองเป็นหัวข้อที่ท้าทายมากและอยู่นอกขอบเขตสำหรับเอกสารนี้ ตอนนี้สมมติว่ามี แหล่งที่มาของการสุ่มที่เราสามารถใช้ได้ เราจะครอบคลุมการมอบหมาย validators ใน รายละเอียดเพิ่มเติมในส่วนที่ 2.1 ทั้งการสุ่มและการมอบหมาย validator จำเป็นต้องมีการคำนวณที่ไม่ใช่ เฉพาะเจาะจงกับส่วนใดส่วนหนึ่งโดยเฉพาะ สำหรับการคำนวณนั้นมีอยู่จริงทั้งหมด การออกแบบมี blockchain แยกต่างหากที่ได้รับมอบหมายให้ดำเนินการ ที่จำเป็นสำหรับการบำรุงรักษาเครือข่ายทั้งหมด นอกจากจะสร้างแบบสุ่มแล้วตัวเลขและการกำหนด validators ให้กับชาร์ด การดำเนินการเหล่านี้ก็มักจะเช่นกัน รวมถึงการรับการอัปเดตจากชาร์ดและการถ่ายภาพสแนปช็อตและการประมวลผล เดิมพันและฟันในระบบ Proof-of-Stake และปรับสมดุลชิ้นส่วนเมื่อเป็นเช่นนั้น รองรับคุณสมบัติแล้ว ห่วงโซ่ดังกล่าวเรียกว่าห่วงโซ่บีคอนใน Ethereum ซึ่งเป็นรีเลย์ chain ใน PolkaDot และ Cosmos Hub ใน Cosmos ตลอดทั้งเอกสารนี้ เราจะอ้างถึงห่วงโซ่ดังกล่าวเป็นห่วงโซ่บีคอน การมีอยู่ของ Beacon chain นำเราไปสู่หัวข้อที่น่าสนใจถัดไป การแบ่งส่วนกำลังสอง 1.2 การแบ่งส่วนกำลังสอง Sharding มักถูกโฆษณาว่าเป็นโซลูชันที่ปรับขนาดได้อย่างไม่สิ้นสุดตามจำนวน ของโหนดที่เข้าร่วมในการดำเนินงานเครือข่าย ในขณะที่ในทางทฤษฎีเป็นไปได้ ออกแบบโซลูชันการแบ่งส่วน ซึ่งเป็นโซลูชันใดๆ ที่มีแนวคิดของบีคอน chain ไม่มีความสามารถในการขยายขนาดได้ไม่จำกัด เพื่อทำความเข้าใจว่าทำไมโปรดทราบว่าบีคอน chain ต้องทำการคำนวณทางบัญชีบางอย่าง เช่น มอบหมาย validators ให้ เศษหรือบล็อกลูกโซ่สแน็ปช็อตที่เป็นสัดส่วนกับจำนวน ของเศษต่างๆ ในระบบ เนื่องจาก Beacon chain นั้นเป็น blockchain ตัวเดียวด้วย การคำนวณที่จำกัดด้วยความสามารถในการคำนวณของโหนดที่ปฏิบัติการ จำนวนชิ้นส่วนนั้นมีจำกัดตามธรรมชาติ อย่างไรก็ตาม โครงสร้างของเครือข่ายแบบแบ่งส่วนทำให้เกิดการคูณ ส่งผลต่อการปรับปรุงโหนดต่างๆ พิจารณากรณีที่เป็นการโดยพลการ มีการปรับปรุงประสิทธิภาพของโหนดในเครือข่ายซึ่งจะช่วยให้ ช่วยให้ประมวลผลธุรกรรมได้เร็วขึ้น หากโหนดปฏิบัติการเครือข่าย รวมถึงโหนดในห่วงโซ่บีคอน เร็วขึ้นสี่เท่า จากนั้นแต่ละส่วนจะสามารถประมวลผลได้มากขึ้นสี่เท่า การทำธุรกรรมและ Beacon chain จะสามารถรักษาส่วนแบ่งได้มากขึ้น 4 เท่า ปริมาณงานทั่วทั้งระบบจะเพิ่มขึ้นตามปัจจัย 4 × 4 = 16 — จึงได้ชื่อว่าการแบ่งส่วนกำลังสอง เป็นการยากที่จะให้การวัดจำนวนชิ้นส่วนที่แม่นยำ เป็นไปได้ในปัจจุบัน แต่ไม่น่าเป็นไปได้ที่ปริมาณงานในอนาคตอันใกล้นี้ ความต้องการของผู้ใช้ blockchain จะเกินขีดจำกัดของการแบ่งส่วนกำลังสอง จำนวนโหนดที่จำเป็นในการใช้งานชิ้นส่วนจำนวนมากอย่างปลอดภัย มีแนวโน้มว่าจะมีขนาดสูงกว่าจำนวนโหนดที่ทำงานทั้งหมด blockchains รวมกันวันนี้ 1.3 การแบ่งส่วนของรัฐ จนถึงขณะนี้เรายังระบุได้ไม่ชัดเจนนักว่าอะไรคืออะไรและไม่ได้แยกจากกัน เมื่อเครือข่ายถูกแบ่งออกเป็นส่วนๆ โดยเฉพาะโหนดใน blockchain ปฏิบัติงานที่สำคัญสามประการ: ไม่เพียงแต่ 1) ประมวลผลธุรกรรมเท่านั้น 2) ถ่ายทอดธุรกรรมที่ได้รับการตรวจสอบและบล็อกที่เสร็จสมบูรณ์ไปยังโหนดอื่นและ 3) เก็บสถานะและประวัติของบัญชีแยกประเภทเครือข่ายทั้งหมด ทั้งสามรายนี้. งานกำหนดข้อกำหนดที่เพิ่มขึ้นบนโหนดที่ทำงานเครือข่าย:1. ความจำเป็นในการประมวลผลธุรกรรมต้องใช้พลังการประมวลผลที่มากขึ้นด้วย จำนวนธุรกรรมที่เพิ่มขึ้นที่กำลังดำเนินการ 2. ความจำเป็นในการถ่ายทอดธุรกรรมและการบล็อกนั้นต้องการแบนด์วิธเครือข่ายมากขึ้นโดยมีจำนวนธุรกรรมที่ถูกถ่ายทอดเพิ่มขึ้น 3. ความจำเป็นในการจัดเก็บข้อมูลต้องใช้พื้นที่จัดเก็บมากขึ้นเมื่อรัฐเติบโตขึ้น ที่สำคัญ ไม่เหมือนกับพลังการประมวลผลและเครือข่าย ความต้องการพื้นที่เก็บข้อมูลจะเพิ่มขึ้นแม้ว่าอัตราธุรกรรม (จำนวนธุรกรรมที่ประมวลผล) ต่อวินาที) คงที่ จากรายการด้านบนอาจปรากฏว่าข้อกำหนดการจัดเก็บน่าจะเป็น เร่งด่วนที่สุดเนื่องจากเป็นสิ่งเดียวที่เพิ่มขึ้นเมื่อเวลาผ่านไป แม้ว่าจำนวนธุรกรรมต่อวินาทีจะไม่เปลี่ยนแปลง แต่ในทางปฏิบัติ ข้อกำหนดเร่งด่วนที่สุดในปัจจุบันคือพลังการประมวลผล รัฐทั้งหมด Ethereum ณ วันที่เขียนนี้คือ 100GB ซึ่งโหนดส่วนใหญ่จัดการได้ง่าย แต่จำนวนธุรกรรม Ethereum ที่สามารถประมวลผลได้คือประมาณ 20 คำสั่งซื้อของ ขนาดน้อยกว่าที่จำเป็นสำหรับกรณีการใช้งานจริงหลายกรณี Zilliqa เป็นโปรเจ็กต์ที่มีชื่อเสียงที่สุดที่ประมวลผลชิ้นส่วน แต่ไม่ใช่พื้นที่เก็บข้อมูล การแบ่งส่วนการประมวลผลเป็นปัญหาที่ง่ายกว่าเนื่องจากแต่ละโหนดมีทั้งหมด สถานะ ซึ่งหมายความว่าสัญญาสามารถเรียกใช้สัญญาอื่นๆ และอ่านข้อมูลใดๆ ได้อย่างอิสระ จาก blockchain จำเป็นต้องมีวิศวกรรมที่ระมัดระวังเพื่อให้แน่ใจว่ามีการอัพเดต จากหลาย ๆ ชาร์ดที่อัปเดตส่วนเดียวกันของรัฐไม่ขัดแย้งกัน ใน สิ่งเหล่านี้ Zilliqa กำลังใช้แนวทางที่ค่อนข้างง่าย2 ในขณะที่มีการเสนอการแบ่งส่วนพื้นที่เก็บข้อมูลโดยไม่มีการแบ่งส่วนการประมวลผล ผิดปกติอย่างยิ่ง ดังนั้นในทางปฏิบัติ การแบ่งส่วนการจัดเก็บหรือการแบ่งส่วนของรัฐ มักจะหมายถึงการแบ่งส่วนการประมวลผลและการแบ่งเครือข่าย ในทางปฏิบัติภายใต้ State Sharding โหนดในแต่ละส่วนกำลังสร้างมันขึ้นมา เป็นเจ้าของ blockchain ที่มีธุรกรรมที่ส่งผลกระทบเฉพาะส่วนท้องถิ่นของ สถานะสากลที่ได้รับมอบหมายให้กับส่วนนั้น ดังนั้น validators ใน shard จำเป็นต้องจัดเก็บส่วนท้องถิ่นของสถานะส่วนกลางและดำเนินการเท่านั้น และมีเพียงการถ่ายทอดธุรกรรมที่ส่งผลกระทบต่อรัฐเท่านั้น นี้ พาร์ติชันจะช่วยลดความต้องการด้านกำลังประมวลผล พื้นที่เก็บข้อมูล และทั้งหมดเป็นเส้นตรง แบนด์วิธเครือข่าย แต่กลับนำมาซึ่งปัญหาใหม่ๆ เช่น ความพร้อมใช้งานของข้อมูลและ ธุรกรรมข้ามส่วน ซึ่งเราจะกล่าวถึงทั้งสองอย่างนี้ด้านล่างนี้ 1.4 การทำธุรกรรมข้ามส่วน โมเดลการแบ่งส่วนที่เราอธิบายไปแล้วนั้นไม่มีประโยชน์มากนัก เพราะหากเป็นรายบุคคล ชิ้นส่วนไม่สามารถสื่อสารถึงกันได้ พวกมันไม่ได้ดีไปกว่าหลาย ๆ อัน อิสระ blockchains แม้กระทั่งทุกวันนี้ เมื่อการแบ่งส่วนไม่พร้อมใช้งาน ก็ยังมี ความต้องการการทำงานร่วมกันอย่างมากระหว่าง blockchains ต่างๆ ตอนนี้มาพิจารณาเฉพาะธุรกรรมการชำระเงินธรรมดาๆ เท่านั้น โดยที่ผู้เข้าร่วมแต่ละคนมีบัญชีอยู่ในส่วนเดียวเท่านั้น หากท่านมีความประสงค์จะโอนเงินจาก 2การวิเคราะห์แนวทางของเราสามารถพบได้ที่นี่: https://medium.com/nearprotocol/ 8f9efae0ce3bบัญชีหนึ่งไปยังอีกบัญชีหนึ่งภายในชาร์ดเดียวกัน ธุรกรรมสามารถดำเนินการได้ ทั้งหมดโดย validators ในชาร์ดนั้น อย่างไรก็ตาม หากอลิซนั้นอาศัยอยู่บนเศษชิ้นส่วน

1 ต้องการส่งเงินให้ Bob ซึ่งอาศัยอยู่บนเศษ #2 ทั้ง validators

บนชาร์ด #1 (พวกเขาจะไม่สามารถให้เครดิตบัญชีของ Bob ได้) หรือ validators บน ชิ้นส่วน #2 (พวกเขาจะไม่สามารถหักเงินจากบัญชีของ Alice ได้) สามารถประมวลผลทั้งหมดได้ การทำธุรกรรม มีสองแนวทางในการทำธุรกรรมข้ามส่วน: • ซิงโครนัส: เมื่อใดก็ตามที่จำเป็นต้องดำเนินการธุรกรรมข้ามส่วน บล็อกในหลายส่วนที่มีการเปลี่ยนสถานะที่เกี่ยวข้องกับ ธุรกรรมได้รับการผลิตทั้งหมดในเวลาเดียวกัน และ validators ของส่วนย่อยหลาย ๆ ร่วมมือกันในการดำเนินการธุรกรรมดังกล่าว3 • อะซิงโครนัส: ธุรกรรมข้ามชาร์ดที่ส่งผลกระทบต่อหลายชาร์ด จะถูกดำเนินการในส่วนแบ่งข้อมูลเหล่านั้นแบบอะซิงโครนัส โดยที่ส่วนแบ่ง "เครดิต" จะดำเนินการ ครึ่งหนึ่งเมื่อมีหลักฐานเพียงพอว่าเศษ "เดบิต" ได้ดำเนินการตามสัดส่วนแล้ว แนวทางนี้มีแนวโน้มที่จะแพร่หลายมากขึ้นเนื่องจากมี ความเรียบง่ายและความสะดวกในการประสานงาน วันนี้ระบบนี้เสนอใน Cosmos, Ethereum Serenity, Near, Kadena และอื่นๆ มีปัญหากับสิ่งนี้ วิธีการอยู่ที่ว่าถ้าบล็อกถูกสร้างแยกกัน มีโอกาสไม่เป็นศูนย์ที่หนึ่งในหลายๆ บล็อกจะถูกละเลย ดังนั้นจึงทำให้ การทำธุรกรรมมีผลเพียงบางส่วนเท่านั้น พิจารณารูปที่ 2 ที่แสดงถึงสอง ชาร์ดซึ่งทั้งคู่พบกับทางแยกและธุรกรรมข้ามชาร์ด ที่ถูกบันทึกไว้ในบล็อก A และ X' ตามลำดับ ถ้าโซ่ A-B และ V'-X'-Y'-Z' กลายเป็น Canonical ในชาร์ดที่สอดคล้องกัน การทำธุรกรรมเสร็จสมบูรณ์แล้ว หาก A'-B'-C'-D' และ V-X กลายเป็นมาตรฐาน จากนั้นธุรกรรมจะถูกยกเลิกโดยสิ้นเชิงซึ่งเป็นที่ยอมรับ แต่ถ้าเพื่อ ตัวอย่างเช่น A-B และ V-X กลายเป็น Canonical จากนั้นส่วนหนึ่งของธุรกรรมจะถูกสรุปและอีกส่วนหนึ่งถูกละทิ้ง ทำให้เกิดความล้มเหลวของอะตอมมิก เรา จะกล่าวถึงวิธีแก้ปัญหานี้ในโปรโตคอลที่เสนอในส่วนที่สอง เมื่อครอบคลุมการเปลี่ยนแปลงกฎและมติของทางเลือกทางแยก อัลกอริธึมที่เสนอสำหรับโปรโตคอลแบบแบ่งส่วน โปรดทราบว่าการสื่อสารระหว่างเครือข่ายจะมีประโยชน์นอกการแบ่งส่วน blockchains เกินไป การทำงานร่วมกันระหว่างโซ่เป็นปัญหาที่ซับซ้อนในหลายโครงการ กำลังพยายามแก้ไข ในการแบ่งส่วน blockchains ปัญหาก็ค่อนข้างง่ายกว่าตั้งแต่นั้นมา โครงสร้างบล็อกและฉันทามติจะเหมือนกันในทุกส่วน และมีสายสัญญาณบีคอนที่สามารถใช้เพื่อประสานงานได้ อย่างไรก็ตามใน blockchain ที่แบ่งส่วน ห่วงโซ่ชิ้นส่วนทั้งหมดเหมือนกัน ในขณะที่อยู่ในระบบนิเวศ blockchains ทั่วโลกที่นั่น มี blockchains ที่แตกต่างกันมากมาย โดยมีกรณีการใช้งานเป้าหมายที่แตกต่างกัน การกระจายอำนาจ และการรับประกันความเป็นส่วนตัว การสร้างระบบซึ่งชุดของโซ่มีคุณสมบัติที่แตกต่างกันแต่ ใช้ฉันทามติและโครงสร้างบล็อกที่คล้ายกันมากพอ และมีสายสัญญาณบีคอนร่วมกันสามารถเปิดใช้งานระบบนิเวศของ blockchains ที่ต่างกันซึ่งมี 3 มากที่สุด รายละเอียด ข้อเสนอ รู้จัก ถึง ที่ ผู้เขียน ของ นี้ เอกสาร คือ ผสาน บล็อก อธิบายไว้ ที่นี่: https://ethresear.ch/t/ ผสานบล็อกและซิงโครนัสข้ามชาร์ดสถานะการดำเนินการ / 1240รูปที่ 2: ธุรกรรมข้ามส่วนแบบอะซิงโครนัส ระบบย่อยการทำงานร่วมกันที่ทำงาน ระบบดังกล่าวไม่น่าจะมีการหมุน validator ดังนั้นจึงจำเป็นต้องมีมาตรการเพิ่มเติมบางอย่างเพื่อความปลอดภัย ทั้งสองอย่าง Cosmos และ PolkaDot เป็นระบบดังกล่าวอย่างมีประสิทธิภาพ4 1.5 พฤติกรรมที่เป็นอันตราย ในส่วนนี้ เราจะตรวจสอบพฤติกรรมของฝ่ายตรงข้ามที่อาจเป็นอันตราย validators ออกกำลังกายหากพวกเขาสามารถทำลายชิ้นส่วนได้ เราจะทบทวนแนวทางแบบคลาสสิก เพื่อหลีกเลี่ยงไม่ให้ชิ้นส่วนเสียหายในส่วนที่ 2.1 1.5.1 ส้อมที่เป็นอันตราย ชุดของ validators ที่เป็นอันตรายอาจพยายามสร้างทางแยก โปรดทราบว่ามันไม่ได้ ไม่ว่าฉันทามติพื้นฐานจะเป็น BFT หรือไม่ก็ตาม ทำให้จำนวนที่เพียงพอเสียหาย ของ validators จะทำให้สามารถสร้างทางแยกได้เสมอ มีแนวโน้มว่า 50% ของชิ้นส่วนเดี่ยวจะเสียหายมากกว่า 50% ของเครือข่ายทั้งหมดที่จะเสียหายอย่างมีนัยสำคัญ (เราจะ เจาะลึกความน่าจะเป็นเหล่านี้ในหัวข้อ 2.1) ตามที่กล่าวไว้ในหัวข้อ 1.4 ธุรกรรมข้ามส่วนเกี่ยวข้องกับการเปลี่ยนแปลงสถานะบางอย่างในหลายส่วนและ บล็อกที่เกี่ยวข้องในชิ้นส่วนที่ใช้การเปลี่ยนแปลงสถานะดังกล่าวจะต้อง จะถูกสรุปทั้งหมด (เช่น ปรากฏในห่วงโซ่ที่เลือกตามลำดับที่เกี่ยวข้อง ชิ้นส่วน) หรือทั้งหมดถูกกำพร้า (เช่น ไม่ปรากฏในห่วงโซ่ที่เลือกบนชิ้นส่วนที่เกี่ยวข้อง) เนื่องจากโดยทั่วไปแล้วความน่าจะเป็นที่ชิ้นส่วนจะเสียหาย 4อ้างอิงถึงบทความนี้โดย Zaki Manian จาก Cosmos: https://forum.cosmos.network/ t/polkadot-vs-cosmos/1397/2 และทวีตพายุนี้โดยผู้เขียนคนแรกของเอกสารนี้: https://twitter.com/AlexSkidanov/status/1129511266660126720 สำหรับการเปรียบเทียบโดยละเอียด ของทั้งสอง

ไม่ได้ละเลย เราไม่สามารถสรุปได้ว่าการ forks จะไม่เกิดขึ้นแม้ว่าจะมีการบรรลุฉันทามติแบบไบแซนไทน์ในกลุ่มชาร์ด validators หรือหลายบล็อกก็ตาม ผลิตที่ด้านบนของบล็อกพร้อมกับการเปลี่ยนแปลงสถานะ ปัญหานี้มีวิธีแก้ไขหลายวิธี โดยวิธีที่พบบ่อยที่สุดเกิดขึ้นเป็นครั้งคราว การเชื่อมโยงข้ามของบล็อกลูกโซ่ชิ้นส่วนล่าสุดกับลูกโซ่บีคอน ส้อม กฎการเลือกในชาร์ดเชนจะเปลี่ยนไปใช้เชนที่เป็นแบบนั้นเสมอ เชื่อมโยงข้าม และใช้เฉพาะกฎการเลือกแยกส่วนเฉพาะสำหรับบล็อกที่เป็นเช่นนั้น เผยแพร่ตั้งแต่การเชื่อมโยงข้ามครั้งล่าสุด 1.5.2 การอนุมัติการบล็อกที่ไม่ถูกต้อง ชุด validators อาจพยายามสร้างบล็อกที่ใช้ฟังก์ชันการเปลี่ยนสถานะไม่ถูกต้อง เช่น เริ่มจากรัฐที่อลิซ มี 10 tokens และ Bob มี 0 tokens บล็อกอาจมีธุรกรรมที่ ส่ง 10 tokens จาก Alice ไปยัง Bob แต่จบลงด้วยสถานะที่ Alice มี 0 tokens และ Bob มี 1,000 tokens ดังแสดงในรูป 3 รูปที่ 3: ตัวอย่างการบล็อกที่ไม่ถูกต้อง ใน blockchain แบบ non-sharded แบบคลาสสิก การโจมตีดังกล่าวเป็นไปไม่ได้ เนื่องจากทั้งหมด ผู้เข้าร่วมในเครือข่ายตรวจสอบบล็อกทั้งหมดและบล็อกด้วย การเปลี่ยนสถานะที่ไม่ถูกต้องจะถูกปฏิเสธโดยผู้ผลิตบล็อกรายอื่นและ ผู้เข้าร่วมเครือข่ายที่ไม่ได้สร้างบล็อก ถึงแม้จะเป็นคนใจร้ายก็ตาม validators สร้างบล็อกต่อจากบล็อกที่ไม่ถูกต้องดังกล่าวได้เร็วกว่า validators ที่ซื่อสัตย์สร้างเชนที่ถูกต้อง ดังนั้นการมีเชนที่ไม่ถูกต้อง บล็อกจะยาวขึ้นก็ไม่สำคัญ เนื่องจากผู้เข้าร่วมทุกคนที่ใช้ blockchain เพื่อวัตถุประสงค์ใดๆ ก็ตามจะตรวจสอบบล็อกทั้งหมด และละทิ้งบล็อกทั้งหมด สร้างขึ้นบนบล็อกที่ไม่ถูกต้อง ในรูปที่ 4 มี validator ห้ารายการ โดยสามรายการเป็นอันตราย พวกเขา สร้างบล็อก A' ที่ไม่ถูกต้อง จากนั้นจึงสร้างบล็อกใหม่ต่อจากด้านบน ของมัน validators ที่ซื่อสัตย์สองคนละทิ้ง A' เนื่องจากไม่ถูกต้องและกำลังสร้างอยู่ด้านบนรูปที่ 4: พยายามสร้างบล็อกที่ไม่ถูกต้องใน blockchain ที่ไม่ใช่การแบ่งส่วน ของบล็อกที่ถูกต้องสุดท้ายที่พวกเขารู้จัก ทำให้เกิดทางแยก เนื่องจากมีน้อย validators เมื่ออยู่ในทางแยกที่เที่ยงตรง โซ่ของมันสั้นกว่า อย่างไรก็ตาม ใน blockchain แบบ nonsharded แบบคลาสสิก ผู้เข้าร่วมทุกคนที่ใช้ blockchain เพื่อวัตถุประสงค์ใดๆ ก็ตาม รับผิดชอบในการตรวจสอบบล็อกทั้งหมดที่พวกเขาได้รับและคำนวณสถานะใหม่ ดังนั้นบุคคลใดก็ตามที่มีความสนใจใน blockchain จะสังเกตเห็นว่า A' ไม่ถูกต้องและจึงละทิ้ง B', C' และ D' ทันทีเช่นการสละ chain A-B เป็น chain ที่ยาวที่สุดในปัจจุบัน อย่างไรก็ตาม ในชาร์ด blockchain ไม่มีผู้เข้าร่วมคนใดสามารถตรวจสอบธุรกรรมทั้งหมดบนชาร์ดทั้งหมดได้ ดังนั้นพวกเขาจึงต้องมีวิธีใดที่จะยืนยันได้ว่าไม่ จุดในประวัติของส่วนใดๆ ของ blockchain ไม่มีการบล็อกที่ไม่ถูกต้อง โปรดทราบว่าการเชื่อมโยงข้ามไปยัง Beacon chain นั้นต่างจาก forks ไม่ใช่วิธีแก้ปัญหาที่เพียงพอ เนื่องจาก Beacon chain ไม่มีความสามารถในการตรวจสอบความถูกต้องของ บล็อก สามารถตรวจสอบว่ามีจำนวน validators เพียงพอในส่วนนั้นเท่านั้น ลงนามในบล็อก (และด้วยเหตุนี้จึงได้รับรองความถูกต้อง) เราจะหารือเกี่ยวกับวิธีแก้ไขปัญหานี้ในส่วน 2.2 ด้านล่าง

ความถูกต้องของรัฐและความพร้อมใช้งานของข้อมูล

แนวคิดหลักใน blockchains แบบแบ่งส่วนคือผู้เข้าร่วมส่วนใหญ่ปฏิบัติการหรือ การใช้เครือข่ายไม่สามารถตรวจสอบความถูกต้องของบล็อกในชาร์ดทั้งหมดได้ เช่นนี้เมื่อไรก็ตาม ผู้เข้าร่วมจำเป็นต้องโต้ตอบกับชิ้นส่วนเฉพาะที่พวกเขาไม่สามารถทำได้ ดาวน์โหลดและตรวจสอบประวัติทั้งหมดของชาร์ด อย่างไรก็ตาม การแบ่งพาร์ติชั่นของการแบ่งส่วนนั้นเพิ่มศักยภาพที่สำคัญ ปัญหา: โดยไม่ต้องดาวน์โหลดและตรวจสอบประวัติทั้งหมดโดยเฉพาะ ผู้เข้าร่วมไม่จำเป็นต้องแน่ใจว่าสถานะนั้นเป็นอย่างไร 5ส่วนนี้ ยกเว้นส่วนย่อย 2.5.3 ได้รับการเผยแพร่ก่อนหน้านี้ที่ https://near.ai/ เศษ2. หากคุณอ่านมาก่อนให้ข้ามไปยังส่วนถัดไป

พวกมันโต้ตอบกันเป็นผลมาจากลำดับบล็อกที่ถูกต้องและลำดับดังกล่าว ของบล็อกนั้นเป็นสายโซ่มาตรฐานในชาร์ด ปัญหาที่ไม่ได้ มีอยู่ใน blockchain ที่ไม่แบ่งส่วน ก่อนอื่นเราจะนำเสนอวิธีแก้ปัญหาง่ายๆ สำหรับปัญหานี้ตามที่เสนอไว้ โดยโปรโตคอลต่างๆ มากมาย แล้ววิเคราะห์ว่าโซลูชันนี้จะพังได้อย่างไรและอะไร มีความพยายามที่จะแก้ไขปัญหาดังกล่าว 2.1 การหมุนเวียนของเครื่องมือตรวจสอบความถูกต้อง วิธีแก้ปัญหาไร้เดียงสาสำหรับความถูกต้องของรัฐแสดงไว้ในรูปที่ 5: สมมติว่าเราสมมติ ที่ทั้งระบบมีตามลำดับหลายพัน validators จากจำนวนนั้น ไม่เกิน 20% เป็นอันตรายหรือจะล้มเหลว (เช่น ล้มเหลว ออนไลน์เพื่อสร้างบล็อก) ถ้าเราสุ่มตัวอย่าง 200 validators ความน่าจะเป็น มากกว่า 1 3 ความล้มเหลวในทางปฏิบัติสามารถถือว่าเป็นศูนย์ได้ รูปที่ 5: การสุ่มตัวอย่าง validators 1 3 เป็นเกณฑ์ที่สำคัญ มีกลุ่มโปรโตคอลฉันทามติที่เรียกว่า BFT โปรโตคอลฉันทามติที่รับประกันว่าตราบเท่าที่น้อยกว่า 1 3ของ ผู้เข้าร่วมล้มเหลว ไม่ว่าจะโดยการชนหรือโดยการกระทำบางอย่างที่ฝ่าฝืน โปรโตคอลก็จะบรรลุฉันทามติ ด้วยสมมติฐานนี้ที่ซื่อสัตย์ validator เปอร์เซ็นต์ หากชุดปัจจุบันของ validators ในส่วนแบ่งทำให้เรามีบล็อกบางส่วน วิธีแก้ปัญหาที่ไร้เดียงสาถือว่า บล็อกนั้นถูกต้องและสร้างขึ้นจากสิ่งที่ validators เชื่อว่าเป็น ห่วงโซ่มาตรฐานสำหรับชิ้นส่วนนั้นเมื่อเริ่มตรวจสอบความถูกต้อง validators เรียนรู้สายโซ่แบบบัญญัติจากชุดก่อนหน้าของ validators ซึ่งเหมือนกัน ข้อสันนิษฐานที่สร้างขึ้นบนบล็อกซึ่งเป็นหัวของห่วงโซ่มาตรฐาน ก่อนหน้านั้น โดยการเหนี่ยวนำ เชนทั้งหมดนั้นถูกต้อง และเนื่องจากไม่มีชุดของ validators ณ จุดใดที่เกิดส้อมการแก้ปัญหาที่ไร้เดียงสาก็มั่นใจได้ว่าในปัจจุบัน โซ่เป็นโซ่เดียวในเศษ ดูรูปที่ 6 สำหรับการแสดงภาพ

รูปที่ 6: A blockchain กับแต่ละบล็อกสรุปผ่าน BFT ฉันทามติ วิธีแก้ปัญหาง่ายๆ นี้ใช้ไม่ได้หากเราถือว่า validators สามารถเป็นได้ เสียหายในการปรับตัว ซึ่งไม่ใช่สมมติฐานที่ไม่สมเหตุสมผล6 ปรับตัวได้ การทำลายชิ้นส่วนเดียวในระบบที่มี 1,000 ชิ้นส่วนนั้นถูกกว่าอย่างเห็นได้ชัด มากกว่าที่จะเสียหายทั้งระบบ ดังนั้นความปลอดภัยของโปรโตคอลจึงลดลงเชิงเส้นตามจำนวนชาร์ด เพื่อให้เกิดความแน่นอนในความถูกต้องของ บล็อก เราต้องรู้ว่า ณ จุดใด ๆ ในประวัติศาสตร์ไม่มีชิ้นส่วนในระบบ validators ส่วนใหญ่สมรู้ร่วมคิด; เมื่อมีศัตรูที่ปรับตัว เราก็ไม่มีอีกต่อไป ความแน่นอนดังกล่าว ดังที่เราได้พูดคุยกันในหัวข้อ 1.5 การสมรู้ร่วมคิด validators สามารถออกกำลังกายได้ พฤติกรรมที่เป็นอันตรายพื้นฐานสองประการ: สร้างทางแยก และสร้างบล็อกที่ไม่ถูกต้อง ส้อมที่เป็นอันตรายสามารถแก้ไขได้โดยบล็อกที่เชื่อมโยงข้ามกับลูกโซ่บีคอนซึ่งโดยทั่วไปได้รับการออกแบบให้มีความปลอดภัยสูงกว่าอย่างมีนัยสำคัญ โซ่เศษ อย่างไรก็ตาม การสร้างบล็อกที่ไม่ถูกต้องนั้นมีความสำคัญมากกว่านั้น ปัญหาที่ท้าทายในการแก้ไข 2.2 ความถูกต้องของรัฐ พิจารณารูปที่ 7 ซึ่ง Shard #1 เสียหายและนักแสดงที่เป็นอันตรายสร้างขึ้น บล็อก B ไม่ถูกต้อง สมมติว่าในบล็อกนี้ B 1,000 tokens ถูกสร้างเสร็จเรียบร้อยแล้ว ออกอากาศในบัญชีของอลิซ ผู้ที่เป็นอันตรายจะสร้างบล็อก C ที่ถูกต้อง (ใน a รู้สึกว่าธุรกรรมใน C ถูกนำไปใช้อย่างถูกต้อง) ที่ด้านบนของ B ซึ่งทำให้สับสน บล็อก B ที่ไม่ถูกต้อง และเริ่มธุรกรรมข้ามชาร์ดไปยัง Shard #2 นั้น โอน 1,000 tokens เหล่านั้นไปยังบัญชีของ Bob ตั้งแต่บัดนี้เป็นต้นไปอย่างไม่เหมาะสม tokens ที่สร้างขึ้นนั้นอยู่บน blockchain ที่ถูกต้องโดยสมบูรณ์ใน Shard #2 แนวทางง่ายๆ ในการแก้ไขปัญหานี้คือ: 6อ่าน นี้ บทความ สำหรับ รายละเอียด บน อย่างไร ปรับตัวได้ การทุจริต สามารถ เป็น ดำเนินการ ออก: https://medium.com/nearprotocol/d859adb464c8. สำหรับ มากขึ้น รายละเอียด บน ปรับตัวได้ การทุจริต อ่าน https://github.com/ethereum/wiki/wiki/Sharding-FAQ# โมเดลการรักษาความปลอดภัยที่เรากำลังดำเนินการอยู่คืออะไรรูปที่ 7: ธุรกรรมข้ามส่วนจากเครือข่ายที่มีบล็อกที่ไม่ถูกต้อง 1. สำหรับ validators ของ Shard #2 เพื่อตรวจสอบความถูกต้องของบล็อกที่ธุรกรรม กำลังเริ่มต้น สิ่งนี้จะไม่ทำงานแม้ในตัวอย่างนี้ เนื่องจากบล็อก C ดูเหมือนจะถูกต้องสมบูรณ์ 2. สำหรับ validators ใน Shard #2 เพื่อตรวจสอบบล็อกจำนวนมากที่อยู่ก่อนหน้าบล็อกที่ธุรกรรมเริ่มต้นขึ้น โดยธรรมชาติแล้วสำหรับ จำนวนบล็อก N ใด ๆ ที่ได้รับการตรวจสอบโดยส่วนที่รับที่เป็นอันตราย validators สามารถสร้างบล็อกที่ถูกต้อง N+1 ที่ด้านบนของบล็อกที่ไม่ถูกต้องได้ ผลิต แนวคิดที่มีแนวโน้มในการแก้ไขปัญหานี้คือการจัดชิ้นส่วนให้เป็น กราฟที่ไม่มีทิศทางซึ่งแต่ละส่วนเชื่อมต่อกับส่วนอื่น ๆ อีกหลายส่วนและ อนุญาตให้ทำธุรกรรมข้ามส่วนระหว่างส่วนใกล้เคียงเท่านั้น (เช่น เป็นเช่นนี้) การแบ่งส่วนย่อยของวลาด ซัมเฟอร์ใช้งานได้จริง7 และแนวคิดที่คล้ายกันนี้ถูกนำมาใช้ในผลงานของคาเดนา เชนเว็บ [1]) หากจำเป็นต้องมีการทำธุรกรรมข้ามส่วนระหว่างส่วนย่อยนั้น ไม่ใช่เพื่อนบ้าน ธุรกรรมดังกล่าวจะถูกส่งผ่านหลายส่วน ในการออกแบบครั้งนี้ validator ในแต่ละชาร์ดนั้นคาดว่าจะตรวจสอบทั้งสองบล็อกทั้งหมดในชาร์ดของพวกเขา เช่นเดียวกับบล็อกทั้งหมดในเศษใกล้เคียงทั้งหมด พิจารณารูปด้านล่าง มีชิ้นส่วน 10 ชิ้น แต่ละชิ้นมีเพื่อนบ้าน 4 ชิ้น และไม่มีชิ้นส่วนใดที่ต้องการเพิ่มอีก มากกว่าสองครั้งสำหรับการสื่อสารแบบ cross-shard ที่แสดงในรูปที่ 8 Shard #2 ไม่เพียงแต่ตรวจสอบความถูกต้อง blockchain ของตัวเองเท่านั้น แต่ยังรวมถึง blockchains ของ เพื่อนบ้านทั้งหมด รวมถึง Shard #1 ดังนั้นหากนักแสดงที่เป็นอันตรายใน Shard #1 กำลังพยายามสร้างบล็อก B ที่ไม่ถูกต้อง จากนั้นสร้างบล็อก C ด้านบน และเริ่มต้นธุรกรรมแบบ cross-shard ธุรกรรมแบบ cross-shard ดังกล่าวจะไม่เกิดขึ้น นับตั้งแต่ Shard #2 จะมีการตรวจสอบประวัติทั้งหมดของ Shard #1 ซึ่ง จะทำให้ระบุบล็อก B ที่ไม่ถูกต้อง 7อ่านเพิ่มเติมเกี่ยวกับการออกแบบได้ที่นี่: https://medium.com/nearprotocol/37e538177ed9

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

1 และ Shard #2 ดำเนินธุรกรรมข้ามชาร์ดไปยัง Shard #3 ได้สำเร็จ

ด้วยเงินทุนจากบล็อก B ที่ไม่ถูกต้อง: รูปที่ 9: ธุรกรรมข้ามส่วนไม่ถูกต้องในระบบที่คล้ายกับเว็บลูกโซ่ที่จะเกิด ไม่ถูกตรวจพบ Shard #3 ตรวจสอบบล็อกทั้งหมดใน Shard #2 แต่ไม่ใช่ใน Shard #1 และ ไม่มีวิธีตรวจจับบล็อกที่เป็นอันตราย มีสองแนวทางหลักในการแก้ปัญหาความถูกต้องของรัฐอย่างเหมาะสม: ชาวประมง

และการพิสูจน์การเข้ารหัสของการคำนวณ 2.3 ชาวประมง แนวคิดเบื้องหลังแนวทางแรกมีดังต่อไปนี้: เมื่อใดก็ตามที่มีส่วนหัวของบล็อก มีการสื่อสารระหว่างเครือข่ายเพื่อวัตถุประสงค์ใดๆ (เช่น การเชื่อมโยงข้ามไปยัง บีคอนเชนหรือธุรกรรมข้ามส่วน) จะมีช่วงระยะเวลาหนึ่งในระหว่างนั้น ซึ่ง validator ที่ซื่อสัตย์คนใดสามารถพิสูจน์ได้ว่าบล็อกนั้นไม่ถูกต้อง นั่น. เป็นสิ่งก่อสร้างต่าง ๆ ที่ช่วยให้สามารถพิสูจน์ได้ชัดเจนว่าบล็อกนั้นเป็นอย่างไร ไม่ถูกต้อง ดังนั้นค่าใช้จ่ายในการสื่อสารสำหรับโหนดรับจึงน้อยกว่ามาก มากกว่าการรับบล็อกเต็ม ด้วยแนวทางนี้ตราบใดที่มี validator ที่ซื่อสัตย์อย่างน้อยหนึ่งรายการใน ชาร์ด ระบบมีความปลอดภัย รูปที่ 10: ชาวประมง นี่เป็นแนวทางที่โดดเด่น (นอกเหนือจากการแสร้งทำเป็นว่าไม่มีปัญหา) ในบรรดาโปรโตคอลที่เสนอในปัจจุบัน อย่างไรก็ตาม แนวทางนี้มีอยู่สองประการ ข้อเสียเปรียบที่สำคัญ: 1. ช่วงเวลาท้าทายต้องยาวนานเพียงพอสำหรับผู้ซื่อสัตย์ validator เพื่อรับรู้ว่ามีการสร้างบล็อก ให้ดาวน์โหลด ตรวจสอบบล็อกให้ครบถ้วน และเตรียมพร้อม ความท้าทายหากบล็อกไม่ถูกต้อง การแนะนำช่วงเวลาดังกล่าวจะ ทำให้การทำธุรกรรมข้ามส่วนช้าลงอย่างมาก 2. การมีอยู่ของโปรโตคอลการท้าทายจะสร้างเวกเตอร์ใหม่ของการโจมตี เมื่อโหนดที่เป็นอันตรายส่งสแปมพร้อมกับความท้าทายที่ไม่ถูกต้อง ทางออกที่ชัดเจน สำหรับปัญหานี้คือการทำให้ผู้ท้าชิงฝากเงินจำนวน tokens ไว้ จะถูกส่งกลับหากการท้าทายนั้นถูกต้อง นี่เป็นเพียงวิธีแก้ปัญหาบางส่วนเท่านั้น อาจยังเป็นประโยชน์สำหรับฝ่ายตรงข้ามที่จะสแปมระบบ (และเผา เงินฝาก) ด้วยความท้าทายที่ไม่ถูกต้อง เช่น เพื่อป้องกันความถูกต้องความท้าทายจาก validator ผู้ซื่อสัตย์จากการผ่าน การโจมตีเหล่านี้คือ เรียกว่าการโจมตีด้วยความโศกเศร้า ดูหัวข้อ 3.7.2 สำหรับวิธีแก้ไขจุดหลัง 2.4 ข้อโต้แย้งความรู้ที่ไม่โต้ตอบโดยย่อ วิธีแก้ปัญหาที่สองสำหรับความเสียหายหลายส่วนคือการใช้โครงสร้างการเข้ารหัสบางประเภทที่ช่วยให้สามารถพิสูจน์ได้ว่าการคำนวณบางอย่าง (เช่น เนื่องจากการคำนวณบล็อกจากชุดธุรกรรม) ดำเนินการอย่างถูกต้อง การก่อสร้างดังกล่าวก็มีอยู่จริง เช่น zk-SNARKs, zk-STARKs และอีกสองสามอย่าง และบางส่วนมีการใช้งานอย่างแข็งขันในโปรโตคอล blockchain ในปัจจุบันสำหรับการชำระเงินส่วนตัว ZCash ที่สะดุดตาที่สุด ปัญหาหลักของสิ่งดึกดำบรรพ์ดังกล่าวก็คือพวกเขา ถือว่าช้ามากในการคำนวณ เช่น Coda Protocol ที่ใช้ zk-SNARK โดยเฉพาะเพื่อพิสูจน์ว่าบล็อกทั้งหมดใน blockchain นั้นถูกต้อง กล่าวในที่เดียว ของการสัมภาษณ์ว่าอาจใช้เวลา 30 วินาทีต่อรายการในการพิสูจน์ (จำนวนนี้น่าจะน้อยกว่านี้ในตอนนี้) ที่น่าสนใจคือ ฝ่ายที่เชื่อถือได้ไม่จำเป็นต้องคำนวณหลักฐานเนื่องจาก การพิสูจน์ไม่เพียงแต่พิสูจน์ถึงความถูกต้องของการคำนวณที่สร้างขึ้นเท่านั้น แต่ยังพิสูจน์ถึงความถูกต้องของการคำนวณด้วย ความถูกต้องของหลักฐานนั้นเอง ดังนั้นจึงสามารถแยกการคำนวณการพิสูจน์ดังกล่าวได้ ในกลุ่มผู้เข้าร่วมที่มีความซ้ำซ้อนน้อยกว่าที่ควรจะเป็นอย่างมาก จำเป็นต้องทำการคำนวณที่ไม่น่าเชื่อถือ อีกทั้งยังเปิดโอกาสให้ผู้เข้าร่วม ผู้คำนวณ zk-SNARK ให้ทำงานบนฮาร์ดแวร์พิเศษโดยไม่ลดขนาด การกระจายอำนาจของระบบ ความท้าทายของ zk-SNARK นอกเหนือจากประสิทธิภาพแล้วคือ: 1. การพึ่งพาการเข้ารหัสแบบดั้งเดิมที่มีการวิจัยน้อยและทดสอบน้อย 2. ”ขยะพิษ” — zk-SNARK ขึ้นอยู่กับการตั้งค่าที่เชื่อถือได้ซึ่งกลุ่ม ของคนทำการคำนวณบางอย่างแล้วทิ้งตัวกลางไป ค่าของการคำนวณนั้น หากผู้เข้าร่วมขั้นตอนทั้งหมดมารวมตัวกัน และเก็บค่ากลางไว้สร้างหลักฐานปลอมได้ 3. ความซับซ้อนพิเศษที่นำมาใช้ในการออกแบบระบบ 4. zk-SNARK ใช้ได้กับชุดย่อยของการคำนวณที่เป็นไปได้เท่านั้น ดังนั้นโปรโตคอล ด้วยภาษา smart contract ที่สมบูรณ์ของทัวริงจะไม่สามารถใช้งานได้ SNARK เพื่อพิสูจน์ความถูกต้องของห่วงโซ่ 2.5 ความพร้อมใช้งานของข้อมูล ปัญหาที่สองที่เราจะพูดถึงคือความพร้อมใช้งานของข้อมูล โดยทั่วไปโหนด ปฏิบัติการเฉพาะ blockchain ถูกแบ่งออกเป็นสองกลุ่ม: โหนดเต็ม ผู้ที่ดาวน์โหลดทุกบล็อกเต็มและตรวจสอบทุกธุรกรรมและ Light โหนดที่ดาวน์โหลดเฉพาะส่วนหัวของบล็อก และใช้การพิสูจน์ Merkle สำหรับชิ้นส่วน ของรัฐและธุรกรรมที่พวกเขาสนใจ ดังแสดงในรูปที่ 11

รูปที่ 11: ต้นไม้เมิร์เคิล ตอนนี้ถ้าโหนดเต็มส่วนใหญ่ชนกัน พวกเขาก็สามารถสร้างบล็อก ถูกต้อง หรือ ไม่ถูกต้อง และส่ง hash ไปยัง light nodes แต่อย่าเปิดเผยเนื้อหาทั้งหมด ของบล็อก มีหลายวิธีที่พวกเขาสามารถได้รับประโยชน์จากมัน ตัวอย่างเช่น พิจารณารูปที่ 12: รูปที่ 12: ปัญหาความพร้อมใช้งานของข้อมูล มีสามช่วงตึก: ก่อนหน้านี้ A ผลิตโดยซื่อสัตย์ validators; ปัจจุบัน B มีการสมรู้ร่วมคิด validators; และตัวถัดไป C ก็จะถูกผลิตขึ้นมาด้วย โดยสุจริต validators (blockchain ปรากฏที่มุมขวาล่าง) คุณเป็นพ่อค้า validators ของบล็อกปัจจุบัน (B) ที่ได้รับบล็อก A จาก validators ก่อนหน้า คำนวณบล็อกที่คุณได้รับเงินและส่งส่วนหัวของบล็อกนั้นไปให้คุณพร้อมหลักฐาน Merkle ของรัฐนั้น คุณมีเงิน (หรือหลักฐาน Merkle ของธุรกรรมที่ถูกต้องที่ส่งเงิน) กับคุณ) มั่นใจว่าธุรกรรมได้รับการสรุปแล้ว คุณจึงให้บริการได้ อย่างไรก็ตาม validators จะไม่แจกจ่ายเนื้อหาทั้งหมดของบล็อก B ไปให้ ใครก็ได้ ด้วยเหตุนี้ validators ที่ซื่อสัตย์ของบล็อก C จึงไม่สามารถเรียกคืนบล็อกได้ และ ถูกบังคับให้หยุดระบบหรือสร้างบน A ทำให้คุณถูกลิดรอน พ่อค้าเงิน เมื่อเราใช้สถานการณ์เดียวกันกับการแบ่งส่วน คำจำกัดความของ full และ โดยทั่วไปแล้ว light node จะใช้ต่อชาร์ด: validators ในแต่ละชาร์ด ดาวน์โหลดทุกครั้ง บล็อกในชาร์ดนั้นและตรวจสอบทุกธุรกรรมในชาร์ดนั้น ยกเว้นอย่างอื่น โหนดในระบบ รวมถึงโหนดที่สแนปชอตชาร์ดเชนระบุสถานะไว้ใน บีคอนเชน ดาวน์โหลดเฉพาะส่วนหัวเท่านั้น ดังนั้น validators ในชาร์ดจึงเป็นเช่นนั้น โหนดเต็มประสิทธิภาพสำหรับชาร์ดนั้น ในขณะที่ผู้เข้าร่วมคนอื่นๆ ในระบบ รวมทั้งสายบีคอนทำงานเป็นโหนดไฟ สำหรับแนวทางชาวประมงที่เรากล่าวถึงข้างต้นในการทำงาน ตรงไปตรงมา validators จะต้องสามารถดาวน์โหลดบล็อกที่เชื่อมโยงข้ามกับลูกโซ่บีคอนได้ หาก validators ที่เป็นอันตรายเชื่อมโยงข้ามส่วนหัวของบล็อกที่ไม่ถูกต้อง (หรือใช้เพื่อ เริ่มต้นการทำธุรกรรมข้ามส่วน) แต่ไม่เคยกระจายบล็อกเลย validators ไม่มีทางสร้างความท้าทายได้ เราจะกล่าวถึงแนวทางสามประการในการแก้ไขปัญหานี้ที่เสริมกัน กันและกัน 2.5.1 หลักฐานการควบคุมตัว ปัญหาเร่งด่วนที่สุดที่ต้องแก้ไขคือบล็อกนั้นพร้อมใช้งานเพียงครั้งเดียวหรือไม่ มันถูกตีพิมพ์ แนวคิดหนึ่งที่เสนอคือการมีสิ่งที่เรียกว่า Notaries ที่หมุนเวียน ระหว่างชาร์ดบ่อยกว่า validators ซึ่งมีหน้าที่แค่ดาวน์โหลด บล็อกและรับรองว่าพวกเขาสามารถดาวน์โหลดได้ พวกเขาสามารถเป็นได้ หมุนเวียนบ่อยขึ้นเนื่องจากไม่จำเป็นต้องดาวน์โหลดสถานะทั้งหมด ของชาร์ด ซึ่งแตกต่างจาก validators ที่ไม่สามารถหมุนได้บ่อยครั้งตั้งแต่นั้นมา จะต้องดาวน์โหลดสถานะของชิ้นส่วนทุกครั้งที่หมุน ดังแสดงในรูป 13. ปัญหาของแนวทางไร้เดียงสานี้คือไม่สามารถพิสูจน์ได้ในภายหลัง ไม่ว่าทนายความจะเป็นหรือไม่สามารถดาวน์โหลดบล็อกได้ ดังนั้นทนายความ สามารถเลือกยืนยันได้เสมอว่าพวกเขาสามารถดาวน์โหลดบล็อกได้โดยไม่ต้อง แม้กระทั่งพยายามดึงมันกลับมา ทางออกหนึ่งสำหรับเรื่องนี้คือให้โนตารีเป็นผู้จัดหา หลักฐานบางอย่างหรือเดิมพันจำนวน tokens ที่ยืนยันว่ามีการบล็อก ดาวน์โหลดแล้ว มีการกล่าวถึงวิธีแก้ปัญหาอย่างหนึ่งที่นี่: https://ethresear.ch/t/ พันธบัตรการดูแลแบบรวมมิตรแบบ 1 บิต/2236 2.5.2 รหัสลบ เมื่อโหนดไฟเฉพาะได้รับ hash ของบล็อก เพื่อเพิ่มโหนด โดยมั่นใจว่าบล็อกนั้นพร้อมใช้งาน ก็สามารถพยายามดาวน์โหลดบางส่วนแบบสุ่มได้ ชิ้นส่วนของบล็อก นี่ไม่ใช่วิธีแก้ปัญหาที่สมบูรณ์ เนื่องจากยกเว้นโหนดไฟ ดาวน์โหลดบล็อกทั้งหมดที่ผู้สร้างบล็อกที่เป็นอันตรายสามารถเลือกรวมกันได้

รูปที่ 13: เครื่องมือตรวจสอบจำเป็นต้องดาวน์โหลดสถานะ จึงไม่สามารถหมุนเวียนได้ บ่อยครั้ง เพื่อระงับส่วนของบล็อกที่ไม่ได้ดาวน์โหลดโดยโหนดแสงใด ๆ จึงยังคงทำให้การบล็อกใช้งานไม่ได้ ทางออกหนึ่งคือการใช้โครงสร้างที่เรียกว่า Erasure Codes เพื่อทำให้เป็นไปได้ เพื่อกู้คืนบล็อกทั้งหมดแม้ว่าจะมีเพียงบางส่วนของบล็อกเท่านั้นดังที่แสดง รูปที่ 14 รูปที่ 14: Merkle tree สร้างขึ้นจากข้อมูลที่เข้ารหัสไว้ ทั้ง Polkadot และ Ethereum Serenity มีการออกแบบตามแนวคิดนี้ว่า จัดให้มีวิธีสำหรับโหนดแสงที่จะมั่นใจได้อย่างสมเหตุสมผลว่ามีบล็อกอยู่ Ethereum วิธีการ Serenity มีคำอธิบายโดยละเอียดใน [2]2.5.3 แนวทางของ Polkadot ในด้านความพร้อมใช้งานของข้อมูล ใน Polkadot เช่นเดียวกับในโซลูชันการแบ่งส่วนส่วนใหญ่ แต่ละส่วน (เรียกว่า parachain) จะสแน็ปช็อตบล็อกของตนไปยังสายสัญญาณบีคอน (เรียกว่าสายโซ่รีเลย์) บอกว่ามี 2f + 1 validators บนห่วงโซ่รีเลย์ ผู้ผลิตบล็อกของบล็อกพาราเชนเรียกว่า collators เมื่อสร้างบล็อก parachain ให้คำนวณเวอร์ชันการลบรหัสของบล็อกที่ประกอบด้วย 2f +1 ส่วนเพื่อให้ส่วน f ใด ๆ เพียงพอ เพื่อสร้างบล็อกขึ้นใหม่ จากนั้นพวกเขาจะแจกจ่ายหนึ่งส่วนให้กับแต่ละ validator บน โซ่รีเลย์ ห่วงโซ่รีเลย์เฉพาะ validator จะลงนามในห่วงโซ่รีเลย์เท่านั้น บล็อกหากมีส่วนสำหรับบล็อกพาราเชนแต่ละบล็อกที่ถูกสแน็ปช็อต บล็อกลูกโซ่รีเลย์ดังกล่าว ดังนั้นหากบล็อกลูกโซ่รีเลย์มีลายเซ็นจาก 2f + 1 validators และตราบเท่าที่ไม่เกิน f ละเมิดโปรโตคอล แต่ละรายการ บล็อกพาราเชนสามารถสร้างขึ้นใหม่ได้โดยการดึงชิ้นส่วนจาก validators ที่เป็นไปตามระเบียบการ ดูรูปที่ 15 รูปที่ 15: ความพร้อมใช้งานของข้อมูล Polkadot 2.5.4 ความพร้อมใช้งานของข้อมูลในระยะยาว โปรดทราบว่าวิธีการทั้งหมดที่กล่าวถึงข้างต้นเพียงยืนยันถึงความจริงที่ว่าบล็อก ได้รับการเผยแพร่เลยและสามารถใช้ได้ในขณะนี้ การบล็อกอาจไม่สามารถใช้งานได้ในภายหลัง ด้วยเหตุผลหลายประการ: โหนดไม่ทำงาน โหนดจงใจลบข้อมูลประวัติศาสตร์ ข้อมูลและอื่น ๆ เอกสารไวท์เปเปอร์ที่ควรกล่าวถึงซึ่งแก้ไขปัญหานี้คือ Polyshard [3], ซึ่งใช้รหัสการลบเพื่อทำให้บล็อกพร้อมใช้งานข้ามเศษแม้ว่าจะมีหลายส่วนก็ตาม ชาร์ดจะสูญเสียข้อมูลไปโดยสิ้นเชิง น่าเสียดายที่ต้องใช้แนวทางเฉพาะของพวกเขา ชิ้นส่วนทั้งหมดเพื่อดาวน์โหลดบล็อกจากชิ้นส่วนอื่น ๆ ทั้งหมดซึ่งเป็นสิ่งต้องห้าม ราคาแพง ความพร้อมใช้งานในระยะยาวไม่ได้เป็นปัญหาเร่งด่วน เนื่องจากไม่มีผู้เข้าร่วม ในระบบคาดว่าจะสามารถตรวจสอบความถูกต้องของลูกโซ่ทั้งหมดได้ทั้งหมด

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

Nightshade

3.1 จากเศษโซ่เป็นเศษชิ้นส่วน รูปแบบการแบ่งส่วนที่มีการแบ่งส่วนและห่วงโซ่บีคอนนั้นทรงพลังมาก มีความซับซ้อนบางอย่าง โดยเฉพาะอย่างยิ่ง กฎการเลือกทางแยกจำเป็นต้องได้รับการดำเนินการ ในแต่ละโซ่แยกกัน กฎการเลือกส้อมในโซ่ชิ้นส่วนและบีคอน โซ่จะต้องสร้างต่างกันและทดสอบแยกกัน ใน Nightshade เราจำลองระบบเป็น blockchain เดียว ซึ่งแต่ละอัน block มีธุรกรรมทั้งหมดสำหรับ shards ทั้งหมดอย่างมีเหตุผล และทำการเปลี่ยนแปลง สภาพสมบูรณ์ของเศษทั้งหมด อย่างไรก็ตาม โดยทางกายภาพแล้ว ไม่มีผู้เข้าร่วมดาวน์โหลดไฟล์ สถานะเต็มหรือบล็อกลอจิคัลเต็ม แทนผู้เข้าร่วมแต่ละคนในเครือข่ายเท่านั้น รักษาสถานะที่สอดคล้องกับส่วนย่อยที่พวกเขาตรวจสอบธุรกรรม และรายการธุรกรรมทั้งหมดในบล็อกจะถูกแบ่งออกเป็นทางกายภาพ ชิ้นละหนึ่งชิ้น ภายใต้สภาวะที่เหมาะสม แต่ละบล็อกจะมีหนึ่งชิ้นต่อส่วนต่อชิ้น บล็อกซึ่งสอดคล้องกับโมเดลที่มีโซ่ชาร์ดโดยประมาณซึ่ง โซ่ชิ้นส่วนสร้างบล็อกด้วยความเร็วเท่ากับห่วงโซ่บีคอน อย่างไรก็ตาม เนื่องจากความล่าช้าของเครือข่าย ชิ้นส่วนบางส่วนอาจหายไป ดังนั้นในทางปฏิบัติแต่ละบล็อก มีหนึ่งหรือเป็นศูนย์ชิ้นต่อชาร์ด ดูหัวข้อ 3.3 สำหรับรายละเอียดเกี่ยวกับวิธีการ มีการผลิตบล็อก รูปที่ 16: โมเดลที่มีโซ่ชิ้นส่วนอยู่ทางด้านซ้ายและมีโซ่เส้นเดียว บล็อกแบ่งออกเป็นชิ้นทางด้านขวา

3.2 ฉันทามติ แนวทางที่โดดเด่นสองประการต่อฉันทามติใน blockchains ในปัจจุบันคือ โซ่ที่ยาวที่สุด (หรือหนักที่สุด) ซึ่งเป็นโซ่ที่มีงานหรือเดิมพันมากที่สุด ใช้ในการสร้างจะถือว่าเป็นที่ยอมรับและ BFT ซึ่งในบางบล็อกสำหรับแต่ละบล็อก ชุดของ validators บรรลุความเห็นพ้องต้องกันของ BFT ในระเบียบการที่เสนอเมื่อเร็วๆ นี้ วิธีหลังเป็นแนวทางที่โดดเด่นกว่า เนื่องจากมันให้ผลลัพธ์ทันที ในขณะที่ห่วงโซ่ที่ยาวที่สุดจำเป็นต้องมีบล็อคมากขึ้น ที่จะสร้างขึ้นบนบล็อกเพื่อให้แน่ใจว่าขั้นสุดท้าย มักจะมีความหมาย การรักษาความปลอดภัยคือเวลาที่ต้องใช้ในการสร้างบล็อกให้เพียงพอ ลำดับชั่วโมง การใช้ BFT ฉันทามติในแต่ละบล็อกก็มีข้อเสียเช่นกัน เช่น: 1. BFT ฉันทามติเกี่ยวข้องกับการสื่อสารในปริมาณมาก ในขณะที่ ความก้าวหน้าล่าสุดทำให้สามารถบรรลุฉันทามติได้ในเวลาเชิงเส้นเป็นจำนวน ของผู้เข้าร่วม (ดูเช่น [4]) ยังคงมองเห็นค่าใช้จ่ายต่อบล็อกได้ชัดเจน 2. เป็นไปไม่ได้ที่ผู้เข้าร่วมเครือข่ายทั้งหมดจะเข้าร่วมใน BFT ฉันทามติต่อบล็อก ดังนั้นโดยปกติแล้วมีเพียงกลุ่มย่อยที่สุ่มตัวอย่างเท่านั้นถึงฉันทามติ โดยหลักการแล้ว ชุดสุ่มตัวอย่างสามารถ เสียหายแบบปรับตัวได้ และในทางทฤษฎีก็สามารถสร้างทางแยกได้ ระบบ จำเป็นต้องมีการสร้างแบบจำลองเพื่อให้พร้อมสำหรับเหตุการณ์ดังกล่าวและยังคงเป็นเช่นนั้น มีกฎ fork-choice นอกเหนือจากมติ BFT หรือได้รับการออกแบบให้ปิด ลงในเหตุการณ์ดังกล่าว เป็นมูลค่าการกล่าวขวัญว่าการออกแบบบางอย่างเช่น Algorand [5] ลดความน่าจะเป็นของความเสียหายแบบปรับตัวได้อย่างมาก 3. ที่สำคัญที่สุด ระบบจะหยุดทำงานหาก 1 3 คนขึ้นไปจากผู้เข้าร่วมทั้งหมด ออฟไลน์ ดังนั้นความผิดพลาดของเครือข่ายชั่วคราวหรือการแยกเครือข่ายอาจทำให้ระบบหยุดชะงักได้อย่างสมบูรณ์ ตามหลักการแล้วระบบจะต้องสามารถดำเนินการต่อไปได้ ดำเนินการตราบเท่าที่ผู้เข้าร่วมอย่างน้อยครึ่งหนึ่งออนไลน์อยู่ (หนักที่สุด โปรโตคอลแบบลูกโซ่ยังคงทำงานต่อไปแม้ว่าผู้เข้าร่วมน้อยกว่าครึ่งหนึ่งจะออนไลน์ แต่ความปรารถนาของคุณสมบัตินี้เป็นที่ถกเถียงกันมากกว่า ภายในชุมชน) โมเดลไฮบริดที่ใช้ฉันทามติถือเป็นรุ่นที่หนักที่สุด แต่บางบล็อกจะได้รับการสรุปเป็นระยะโดยใช้อุปกรณ์ BFT finality โดยจะรักษาข้อดีของทั้งสองรุ่นไว้ BFT อุปกรณ์ขั้นสุดท้ายดังกล่าวคือ Casper FFG [6] ใช้ใน Ethereum 2.0 8, Casper CBC (ดู https://vitalik. ca/general/2018/12/05/cbc_casper.html) และ GRANDPA (ดู https:// medium.com/polkadot-network/d08a24a021b5) ใช้ใน Polkadot Nightshade ใช้ฉันทามติลูกโซ่ที่หนักที่สุด โดยเฉพาะเมื่อมีการบล็อก ผู้ผลิตสร้างบล็อก (ดูหัวข้อ 3.3) พวกเขาสามารถรวบรวมลายเซ็นได้ ผู้ผลิตบล็อกรายอื่นและ validators ยืนยันถึงบล็อกก่อนหน้า ดูหัวข้อ 3.8 เพื่อดูรายละเอียดวิธีการรวมลายเซ็นจำนวนมากดังกล่าว น้ำหนัก 8ดูเซสชันไวท์บอร์ดกับ Justin Drake เพื่อรับทราบภาพรวมเชิงลึกของ Casper FFG และวิธีรวมเข้ากับฉันทามติของ GHOST chain ที่หนักที่สุดที่นี่: https://www. youtube.com/watch?v=S262StTwkmoของบล็อกจึงเป็นยอดเดิมพันสะสมของผู้ลงนามทั้งหมดที่มีลายเซ็น รวมอยู่ในบล็อก น้ำหนักของโซ่คือผลรวมของน้ำหนักบล็อก นอกเหนือจากความเห็นพ้องต้องกันของห่วงโซ่ที่หนักที่สุดแล้ว เรายังใช้อุปกรณ์ขั้นสุดท้ายที่ใช้ การรับรองเพื่อสรุปบล็อก เพื่อลดความซับซ้อนของระบบ เราใช้โปรแกรมเบ็ดเตล็ดสุดท้ายที่ไม่ส่งผลต่อกฎการเลือกทางแยก แต่อย่างใด และแทนที่จะแนะนำเฉพาะเงื่อนไขการเฉือนเพิ่มเติม เช่น เมื่อบล็อกแล้ว เมื่อสรุปโดยอุปกรณ์ขั้นสุดท้ายแล้ว ทางแยกนั้นเป็นไปไม่ได้เว้นแต่จะมีเปอร์เซ็นต์ที่สูงมาก ของสัดส่วนการถือหุ้นทั้งหมดถูกตัดออก Casper CBC เป็นอุปกรณ์ขั้นสุดท้ายและเรา ปัจจุบันเป็นโมเดลที่มี Casper CBC อยู่ในใจ นอกจากนี้เรายังทำงานบนโปรโตคอล BFT แยกต่างหากที่เรียกว่า TxFlow ในเวลาที่ การเขียนเอกสารนี้ไม่ชัดเจนว่าจะใช้ TxFlow แทน Casper หรือไม่ ซีบีซี. อย่างไรก็ตาม เราสังเกตว่าตัวเลือกอุปกรณ์ขั้นสุดท้ายนั้นส่วนใหญ่จะตั้งฉากกับส่วนที่เหลือของการออกแบบ 3.3 การผลิตแบบบล็อก ใน Nightshade มีสองบทบาท: ผู้ผลิตบล็อกและ validators ได้เลย ชี้ว่าระบบประกอบด้วยตัวสร้างบล็อก w, w = 100 ในแบบจำลองของเรา และ wv validators ในโมเดลของเรา v = 100, wv = 10, 000 ระบบนี้เป็น Proof-of-Stake หมายความว่าทั้งผู้ผลิตบล็อกและ validators มีจำนวนภายในจำนวนหนึ่ง สกุลเงิน (เรียกว่า ”tokens”) ถูกล็อคเป็นระยะเวลาเกินกว่า เวลาที่พวกเขาใช้ในการปฏิบัติหน้าที่ในการสร้างและตรวจสอบห่วงโซ่ เช่นเดียวกับระบบ Proof of Stake ทั้งหมด ไม่ใช่ทุก w ที่บล็อกผู้ผลิตและไม่ใช่ wv validators ทั้งหมดเป็นเอนทิตีที่แตกต่างกัน เนื่องจากไม่สามารถบังคับใช้ได้ แต่ละ ของ w บล็อกโปรดิวเซอร์และ wv validators มีการแยกกัน สัดส่วนการถือหุ้น ระบบมี n ชาร์ด n = 1,000 ในโมเดลของเรา ดังที่กล่าวไว้ใน ส่วนที่ 3.1 ใน Nightshade นั้นไม่มี shard chains แต่ผู้สร้างบล็อกทั้งหมดและ validators กำลังสร้าง blockchain เดียว ที่เราเรียกว่า ห่วงโซ่หลัก สถานะของห่วงโซ่หลักแบ่งออกเป็น n ส่วนและแต่ละบล็อก โปรดิวเซอร์และ validator ดาวน์โหลดเฉพาะชุดย่อยในเครื่องเท่านั้น สถานะที่สอดคล้องกับเซตย่อยบางส่วนของชาร์ด และประมวลผลและเท่านั้น ตรวจสอบธุรกรรมที่ส่งผลกระทบต่อส่วนเหล่านั้นของรัฐ ในการเป็นผู้ผลิตบล็อก ผู้เข้าร่วมเครือข่ายจะต้องล็อกกลุ่มใหญ่ไว้บางส่วน จำนวน tokens (เงินเดิมพัน) การบำรุงรักษาเครือข่ายเสร็จสิ้นในยุค โดยที่ยุคคือช่วงเวลาหนึ่งตามลำดับวัน ผู้เข้าร่วม โดยเดิมพันที่ใหญ่ที่สุดในช่วงเริ่มต้นของยุคหนึ่งๆ ก็คือบล็อก ผู้ผลิตในยุคนั้น ผู้ผลิตบล็อกแต่ละคนถูกกำหนดให้ sw shards (เช่น sw = 40 ซึ่งจะทำให้ sww/n = 4 ผู้ผลิตบล็อกต่อชาร์ด) บล็อก โปรดิวเซอร์จะดาวน์โหลดสถานะของส่วนแบ่งข้อมูลที่ได้รับมอบหมายก่อนยุคสมัย เริ่มต้นและตลอดยุคสมัยจะรวบรวมธุรกรรมที่ส่งผลกระทบต่อชิ้นส่วนนั้น และนำไปประยุกต์ใช้กับรัฐ สำหรับแต่ละบล็อก b บนเชนหลัก และสำหรับทุก ๆ เศษ จะมีหนึ่งในนั้น มอบหมายให้ผู้ผลิตบล็อกเป็นผู้รับผิดชอบในการผลิตชิ้นส่วนที่เกี่ยวข้องกับข ไปที่เศษ ส่วนของ b ที่เกี่ยวข้องกับชาร์ด s เรียกว่า chunk และมี รายการธุรกรรมสำหรับชาร์ดที่จะรวมอยู่ใน b เช่นเดียวกับ merkleรากของสถานะผลลัพธ์ b ในที่สุดจะมีส่วนหัวที่เล็กมากเท่านั้น ส่วนนั้นคือราก Merkle ของธุรกรรมที่ใช้ทั้งหมด (ดูหัวข้อ 3.7.1 สำหรับรายละเอียดที่แน่นอน) และรากเหง้าของสภาวะสุดท้าย ตลอดส่วนที่เหลือของเอกสาร เรามักจะอ้างถึงผู้สร้างบล็อก ที่รับผิดชอบในการผลิตชิ้นส่วนในช่วงเวลาหนึ่งสำหรับชิ้นส่วนเฉพาะ ในฐานะผู้ผลิตก้อน ผู้ผลิตก้อนมักจะเป็นหนึ่งในผู้ผลิตบล็อกเสมอ ผู้ผลิตบล็อกและผู้ผลิตก้อนจะหมุนเวียนแต่ละบล็อกตาม ให้มีกำหนดเวลาที่แน่นอน ผู้ผลิตบล็อกมีการสั่งซื้อและผลิตซ้ำหลายครั้ง บล็อกตามลำดับนั้น เช่น หากมีผู้ผลิตบล็อก 100 ราย บล็อกแรก ผู้ผลิตมีหน้าที่ผลิตบล็อก 1, 101, 201 ฯลฯ ประการที่สองคือ รับผิดชอบในการผลิต 2, 102, 202 ฯลฯ) เนื่องจากการผลิตแบบก้อนนั้นต่างจากการผลิตแบบบล็อกซึ่งต้องมีการบำรุงรักษา สถานะและสำหรับแต่ละส่วนเฉพาะผู้ผลิตบล็อก sww/n เท่านั้นที่จะรักษาสถานะ ต่อชิ้นส่วน เฉพาะผู้ผลิตบล็อก sw/n เหล่านั้นเท่านั้นที่หมุนเพื่อสร้าง ชิ้น เช่น ด้วยค่าคงที่ข้างต้นโดยมีผู้ผลิตบล็อกสี่รายที่ได้รับมอบหมายให้ แต่ละชิ้นส่วน ผู้ผลิตบล็อกแต่ละรายจะสร้างชิ้นส่วนทุกๆ สี่บล็อก 3.4 รับรองความพร้อมใช้งานของข้อมูล เพื่อให้แน่ใจว่าข้อมูลมีความพร้อมใช้งาน เราใช้วิธีการที่คล้ายคลึงกับ Polkadot อธิบายไว้ในส่วน 2.5.3 เมื่อผู้ผลิตบล็อกสร้างชิ้นส่วนขึ้นมา พวกเขาก็จะสร้าง เวอร์ชันที่เข้ารหัสการลบด้วยโค้ดบล็อกที่เหมาะสมที่สุด (w, ⌊w/6 + 1⌋) ของ ก้อน จากนั้นพวกเขาก็ส่งชิ้นส่วนที่มีรหัสการลบออกหนึ่งชิ้น (เราเรียกว่าชิ้นส่วนดังกล่าว ชิ้นหรือเพียงบางส่วน) ให้กับผู้ผลิตบล็อกแต่ละราย เราคำนวณต้นไม้เมอร์เคิลที่มีส่วนต่างๆ ทั้งหมดเป็นใบ และ ส่วนหัวของแต่ละชิ้นมีราก Merkle ของต้นไม้ดังกล่าว ชิ้นส่วนจะถูกส่งไปยัง validators ผ่านข้อความส่วนหนึ่ง แต่ละข้อความดังกล่าว ประกอบด้วยส่วนหัวของชิ้นส่วน ลำดับของชิ้นส่วน และเนื้อหาชิ้นส่วน ที่ ข้อความยังมีลายเซ็นของผู้ผลิตบล็อกที่ผลิต chunk และเส้นทาง Merkle เพื่อพิสูจน์ว่าส่วนนั้นสอดคล้องกับส่วนหัว และผลิตโดยผู้ผลิตบล็อกที่เหมาะสม เมื่อผู้ผลิตบล็อกได้รับบล็อกลูกโซ่หลักแล้ว พวกเขาจะต้องตรวจสอบก่อนว่าตนได้รับหรือไม่ มีข้อความส่วนหนึ่งสำหรับแต่ละอันที่รวมอยู่ในบล็อก ถ้าไม่ใช่ก็บล็อก จะไม่ถูกประมวลผลจนกว่าจะเรียกค้นข้อความส่วนหนึ่งที่หายไป เมื่อได้รับข้อความทั้งหมดแล้ว ผู้ผลิตบล็อกจะดึงข้อมูล ส่วนที่เหลือจากเพื่อนและสร้างชิ้นส่วนที่พวกเขาถือไว้ใหม่ รัฐ ผู้ผลิตบล็อกไม่ประมวลผลบล็อกลูกโซ่หลักหากมีอย่างน้อยหนึ่งรายการ chunk ที่รวมอยู่ในบล็อกนั้นไม่มีข้อความส่วนหนึ่งที่สอดคล้องกัน หรือหากอย่างน้อยหนึ่งส่วนที่พวกเขารักษาสถานะไว้ก็ไม่สามารถทำได้ สร้างชิ้นส่วนทั้งหมดขึ้นมาใหม่ เพื่อให้ก้อนใดก้อนหนึ่งพร้อมใช้งาน มันก็เพียงพอแล้วที่ ⌊w/6⌋+1 ของบล็อก ผู้ผลิตมีส่วนของตนและให้บริการ ดังนั้นตราบเท่าที่จำนวน นักแสดงที่เป็นอันตรายไม่เกิน ⌊w/3⌋no chain ที่มีมากกว่าครึ่งบล็อก ผู้ผลิตที่สร้างมันขึ้นมาอาจมีชิ้นส่วนที่ไม่พร้อมใช้งานได้รูปที่ 17: แต่ละบล็อกประกอบด้วยหนึ่งหรือศูนย์ชิ้นต่อชิ้นส่วน และแต่ละชิ้น มีการเข้ารหัสการลบข้อมูล แต่ละส่วนของชิ้นส่วนที่มีรหัสการลบจะถูกส่งไปยังสถานที่ที่กำหนด ผู้ผลิตบล็อกผ่านข้อความพิเศษ onepart 3.4.1 การจัดการกับผู้ผลิตบล็อกขี้เกียจ หากผู้ผลิตบล็อกมีบล็อกที่ข้อความส่วนหนึ่งหายไป อาจเลือกที่จะยังคงลงชื่อเข้าใช้อยู่ เพราะหากบล็อกจบลงด้วยการถูกลูกโซ่ จะเพิ่มรางวัลสูงสุดให้กับผู้ผลิตบล็อก ไม่มีความเสี่ยงสำหรับการบล็อก ผู้ผลิตเนื่องจากเป็นไปไม่ได้ที่จะพิสูจน์ในภายหลังว่าผู้ผลิตบล็อกไม่มี ข้อความส่วนหนึ่ง เพื่อแก้ไขปัญหาดังกล่าว เราจึงสร้างผู้สร้างแต่ละชิ้นเมื่อสร้างชิ้นส่วนนั้น เลือกสี (สีแดงหรือสีน้ำเงิน) สำหรับแต่ละส่วนของชิ้นส่วนที่เข้ารหัสในอนาคต และจัดเก็บ บิตมาสก์ของสีที่กำหนดในกลุ่มก่อนที่จะเข้ารหัส แต่ละอัน ข้อความจะมีสีที่กำหนดให้กับชิ้นส่วน และใช้สีเมื่อใด คำนวณราก Merkle ของส่วนที่เข้ารหัส หากผู้ผลิตก้อนเบี่ยงเบน จากโปรโตคอล มันสามารถพิสูจน์ได้อย่างง่ายดาย เนื่องจากราก Merkle ทั้งสองจะไม่ทำเช่นนั้น ตรงกับข้อความส่วนหนึ่งหรือสีในข้อความส่วนหนึ่งนั้น ตรงกับรากเมิร์เคิลจะไม่ตรงกับมาส์กในก้อน เมื่อผู้ผลิตบล็อกลงนามในบล็อก พวกเขารวมบิตมาสก์ของทั้งหมดด้วย ชิ้นส่วนสีแดงที่พวกเขาได้รับสำหรับชิ้นส่วนที่รวมอยู่ในบล็อก การเผยแพร่ บิตมาสก์ที่ไม่ถูกต้องเป็นพฤติกรรมที่เฉือนได้ หากผู้ผลิตบล็อกไม่ได้รับ ข้อความเพียงส่วนเดียว พวกเขาไม่มีทางรู้สีของข้อความได้ และ จึงมีโอกาส 50% ที่จะถูกเฉือนหากพวกเขาพยายามเซ็นชื่อโดยไม่ตั้งใจ บล็อก 3.5 ใบสมัครเปลี่ยนสถานะ ผู้ผลิตก้อนจะเลือกเฉพาะธุรกรรมที่จะรวมไว้ในก้อนเท่านั้น อย่าใช้การเปลี่ยนสถานะเมื่อมันสร้างก้อน ตามลำดับ

ส่วนหัวของก้อนประกอบด้วยรากแบบ Merkle ของสถานะแบบ Merkelized เมื่อก่อน ธุรกรรมในกลุ่มจะถูกนำไปใช้ ธุรกรรมจะถูกใช้เฉพาะเมื่อบล็อกเต็มที่มีส่วนรวมอยู่ด้วย ได้รับการประมวลผล ผู้เข้าร่วมจะประมวลผลบล็อกก็ต่อเมื่อ 1. ได้รับและประมวลผลบล็อกก่อนหน้าแล้ว 2. สำหรับแต่ละกลุ่ม ผู้เข้าร่วมจะไม่รักษาสถานะตามที่ตนมีอยู่ เห็นข้อความส่วนหนึ่ง 3. สำหรับแต่ละชิ้นส่วน ผู้เข้าร่วมจะคงสถานะตามที่พวกเขามีอยู่ เต็มชิ้น เมื่อบล็อกได้รับการประมวลผล สำหรับแต่ละชิ้นส่วนที่ผู้เข้าร่วมได้รับ รักษาสถานะไว้เพื่อใช้ธุรกรรมและคำนวณสถานะใหม่ หลังจากทำรายการแล้วจึงพร้อมดำเนินการ ชิ้นส่วนสำหรับบล็อกถัดไป หากถูกกำหนดให้กับชิ้นส่วนใดๆ เนื่องจากพวกเขามี รากเมิร์เคิลของสภาวะเมอร์เคิลไลซ์ใหม่ 3.6 ธุรกรรมและใบเสร็จรับเงินข้ามส่วน หากธุรกรรมจำเป็นต้องส่งผลกระทบมากกว่าหนึ่งส่วน จะต้องต่อเนื่องกัน ดำเนินการในแต่ละส่วนแยกกัน ธุรกรรมทั้งหมดจะถูกส่งไปยังชาร์ดแรก ได้รับผลกระทบ และเมื่อธุรกรรมถูกรวมไว้ในส่วนของชิ้นส่วนดังกล่าว และ ถูกใช้หลังจากที่รวมชิ้นส่วนไว้ในบล็อกแล้ว มันจะสร้างสิ่งที่เรียกว่าใบเสร็จรับเงิน ธุรกรรมที่ถูกส่งไปยังส่วนถัดไปที่ธุรกรรมจำเป็นต้องทำ ถูกประหารชีวิต หากต้องการขั้นตอนเพิ่มเติม การดำเนินการธุรกรรมการรับสินค้า สร้างธุรกรรมการรับสินค้าใหม่เป็นต้น 3.6.1 อายุการใช้งานธุรกรรมการรับ เป็นที่พึงประสงค์ว่ามีการใช้ธุรกรรมการรับสินค้าในบล็อกที่ตามหลังบล็อกที่สร้างขึ้นทันที การทำรายการรับเงินเท่านั้น สร้างขึ้นหลังจากได้รับบล็อกก่อนหน้าและนำไปใช้โดยผู้ผลิตบล็อก ที่รักษาชิ้นส่วนต้นกำเนิดไว้ และจำเป็นต้องทราบเมื่อถึงเวลานั้น ชิ้นสำหรับบล็อกถัดไปผลิตโดยผู้ผลิตบล็อกของปลายทาง เศษ ดังนั้นใบเสร็จรับเงินจะต้องได้รับการสื่อสารจากชาร์ดต้นทางไปยัง ชิ้นส่วนปลายทางในช่วงเวลาอันสั้นระหว่างทั้งสองเหตุการณ์ ให้ A เป็นบล็อกที่ผลิตครั้งสุดท้ายซึ่งมีธุรกรรม t ที่สร้างใบเสร็จรับเงิน r ให้ B เป็นบล็อกที่ผลิตถัดไป (เช่น บล็อกที่มี A เป็น บล็อกก่อนหน้า) ที่เราต้องการมี r อย่าให้อยู่ในชาร์ด a และ r เลย ในเศษข อายุการใช้งานของใบเสร็จรับเงิน ซึ่งแสดงไว้ในรูปที่ 18 ก็มีดังต่อไปนี้: จัดทำและจัดเก็บใบเสร็จรับเงิน CPA ของผู้ผลิตก้อนสำหรับชาร์ด a รับบล็อก A ใช้ธุรกรรม t และสร้างใบเสร็จรับเงิน r ผู้สอบบัญชีรับอนุญาต จากนั้นจัดเก็บใบเสร็จรับเงินที่ผลิตดังกล่าวทั้งหมดไว้ในที่เก็บข้อมูลถาวรภายในที่จัดทำดัชนีไว้ ตามรหัสชาร์ดแหล่งที่มาแจกจ่ายใบเสร็จรับเงิน เมื่อ cpa พร้อมที่จะผลิตก้อนสำหรับ shard a สำหรับบล็อก B พวกเขาดึงข้อมูลใบเสร็จรับเงินทั้งหมดที่สร้างขึ้นโดยการใช้ธุรกรรมจากบล็อก A สำหรับ shard a และรวมไว้ใน chunk สำหรับ shrad a ในบล็อก B เมื่อสร้างชิ้นส่วนดังกล่าวแล้ว cpa จะสร้างรหัสการลบข้อมูล เวอร์ชันและข้อความส่วนหนึ่งที่เกี่ยวข้องทั้งหมด cpa รู้ว่าผู้ผลิตบล็อกรายใดรักษาสถานะเต็มสำหรับชิ้นส่วนใด สำหรับผู้ผลิตบล็อกโดยเฉพาะ bp cpa รวมใบเสร็จรับเงินที่เกิดจากการใช้ธุรกรรมในบล็อก A สำหรับชาร์ด a ที่มีชาร์ดใดๆ ที่ bp ใส่ใจเป็นจุดหมายปลายทาง ในข้อความส่วนหนึ่งเมื่อพวกเขาแจกจ่ายชิ้นส่วน A ในบล็อก B (ดูรูปที่ 17 ซึ่งแสดงใบเสร็จรับเงินที่รวมอยู่ในข้อความส่วนหนึ่ง) การรับใบเสร็จรับเงิน โปรดจำไว้ว่าผู้เข้าร่วม (ทั้งผู้สร้างบล็อกและ validators) จะไม่ประมวลผลบล็อกจนกว่าพวกเขาจะมีข้อความเพียงส่วนเดียว สำหรับแต่ละชิ้นที่รวมอยู่ในบล็อก ดังนั้น เมื่อถึงเวลาที่ผู้เข้าร่วมคนใดคนหนึ่งใช้บล็อก B พวกเขาก็จะมีข้อความส่วนหนึ่งทั้งหมดที่ตรงกัน ชิ้นใน B และด้วยเหตุนี้พวกมันจึงมีใบเสร็จรับเงินขาเข้าทั้งหมดที่มีเศษชิ้นส่วน ผู้เข้าร่วมรักษาสถานะไว้เป็นจุดหมายปลายทาง เมื่อสมัคร การเปลี่ยนสถานะสำหรับชิ้นส่วนเฉพาะ ผู้เข้าร่วมจะใช้ทั้งใบเสร็จรับเงิน ที่พวกเขารวบรวมไว้เป็นเศษข้อความในข้อความเดียวและทั้งหมด ธุรกรรมที่รวมอยู่ในก้อนนั้นเอง รูปที่ 18: อายุของธุรกรรมการรับสินค้า 3.6.2 การจัดการใบเสร็จรับเงินมากเกินไป เป็นไปได้ว่าจำนวนใบเสร็จรับเงินที่กำหนดเป้าหมายไปยังส่วนข้อมูลเฉพาะใน บล็อกใดบล็อกหนึ่งมีขนาดใหญ่เกินกว่าจะประมวลผลได้ ตัวอย่างเช่น ลองพิจารณารูปที่ 19 ใน ซึ่งแต่ละธุรกรรมในแต่ละชาร์ดจะสร้างใบเสร็จรับเงินที่กำหนดเป้าหมายชาร์ด 1 ในบล็อกถัดไป จำนวนใบเสร็จรับเงินที่ชาร์ด 1 ต้องดำเนินการคือ เทียบได้กับโหลดที่ชิ้นส่วนทั้งหมดรวมกันในการประมวลผลขณะจัดการ บล็อกก่อนหน้า

รูปที่ 19: หากใบเสร็จรับเงินทั้งหมดมุ่งเป้าไปที่ชาร์ดเดียวกัน ชาร์ดนั้นอาจไม่มี ความสามารถในการประมวลผล เพื่อแก้ไขปัญหานี้ เราใช้เทคนิคที่คล้ายกับที่ใช้ใน QuarkChain 9 โดยเฉพาะสำหรับแต่ละชิ้นส่วน บล็อก B สุดท้ายและชิ้นส่วนสุดท้ายภายในนั้น บล็อกที่ใช้ใบเสร็จรับเงินจะถูกบันทึก เมื่อเศษใหม่เป็น สร้างขึ้น ใบเสร็จรับเงินจะถูกนำไปใช้ตามลำดับแรกจากเศษที่เหลือใน B จากนั้นในบล็อกที่ตาม B จนกว่าก้อนใหม่จะเต็ม ภายใต้สภาวะปกติ สถานการณ์ที่มีภาระสมดุล โดยทั่วไปจะส่งผลให้ใบเสร็จรับเงินทั้งหมด ถูกนำมาใช้ (และดังนั้นชิ้นส่วนสุดท้ายของบล็อกสุดท้ายจะถูกบันทึกไว้ แต่ละชิ้น) แต่ในช่วงเวลาที่ภาระไม่สมดุลและเป็นช่วงเฉพาะ เศษได้รับใบเสร็จรับเงินจำนวนมากอย่างไม่เป็นสัดส่วน เทคนิคนี้ช่วยให้สามารถรับได้ ได้รับการประมวลผลโดยคำนึงถึงขีดจำกัดของจำนวนธุรกรรมที่รวมอยู่ โปรดทราบว่าหากโหลดที่ไม่สมดุลดังกล่าวคงอยู่เป็นเวลานาน ความล่าช้าจะเกิดขึ้นจาก การสร้างใบเสร็จรับเงินจนกว่าใบสมัครจะเติบโตต่อไปอย่างไม่มีกำหนด หนึ่ง วิธีแก้ไขคือยกเลิกธุรกรรมใดๆ ที่สร้างใบเสร็จรับเงินที่กำหนดเป้าหมาย ชิ้นส่วนที่มีความล่าช้าในการประมวลผลซึ่งเกินค่าคงที่บางอย่าง (เช่น หนึ่งยุค) พิจารณารูปที่ 20 โดยบล็อก B ชิ้นส่วนที่ 4 ไม่สามารถประมวลผลใบเสร็จรับเงินทั้งหมดได้ ดังนั้นจึงประมวลผลเฉพาะการรับต้นทางตั้งแต่จนถึงส่วนที่ 3 ในบล็อก A และ บันทึกมัน ในบล็อก C จะมีการรวมใบเสร็จรับเงินจนถึงชิ้นส่วน 5 ในบล็อก B และ จากนั้นโดยบล็อก D ชิ้นส่วนจะจับขึ้นมาและประมวลผลใบเสร็จรับเงินที่เหลือทั้งหมดเข้ามา บล็อก B และใบเสร็จรับเงินทั้งหมดจากบล็อก C 3.7 การตรวจสอบชิ้นส่วน ชิ้นที่ผลิตสำหรับชิ้นส่วนเฉพาะ (หรือบล็อกชิ้นส่วนที่ผลิตสำหรับห่วงโซ่ชิ้นส่วนเฉพาะในแบบจำลองที่มีห่วงโซ่ชิ้นส่วน) สามารถตรวจสอบได้โดย 9ดูตอนไวท์บอร์ดกับ QuarkChain ที่นี่: https://www.youtube.com/watch? v=opEtG6NM4x4 ซึ่งมีการพูดคุยถึงแนวทางการทำธุรกรรมข้ามส่วน และอื่นๆ สิ่งต่างๆรูปที่ 20: การประมวลผลใบเสร็จรับเงินล่าช้า ผู้เข้าร่วมที่รักษารัฐ พวกเขาสามารถเป็นผู้ผลิตบล็อก validators หรือเพียงพยานภายนอกที่ดาวน์โหลดสถานะและตรวจสอบความถูกต้องของชาร์ด ซึ่งพวกเขาเก็บทรัพย์สินไว้ ในเอกสารนี้ เราถือว่าผู้เข้าร่วมส่วนใหญ่ไม่สามารถจัดเก็บได้ สภาพของเศษชิ้นส่วนจำนวนมาก อย่างไรก็ตาม เป็นเรื่องที่น่ากล่าวถึงว่า ว่ามีการแบ่งส่วน blockchains ที่ได้รับการออกแบบโดยมีข้อสันนิษฐานว่า ผู้เข้าร่วมส่วนใหญ่มีความสามารถในการจัดเก็บสถานะและตรวจสอบได้ส่วนใหญ่ ชิ้นส่วนต่างๆ เช่น QuarkChain เนื่องจากมีผู้เข้าร่วมเพียงเศษเสี้ยวเท่านั้นที่มีสถานะในการตรวจสอบความถูกต้องของส่วนข้อมูล ชิ้นมันเป็นไปได้ที่จะปรับตัวทุจริตเฉพาะผู้เข้าร่วมที่มี สถานะ และใช้การเปลี่ยนสถานะที่ไม่ถูกต้อง มีการเสนอการออกแบบการแบ่งส่วนหลายส่วนโดยให้ตัวอย่าง validators ทุกๆ สองสามตัวอย่าง วัน และภายในหนึ่งวัน บล็อกใดๆ ในห่วงโซ่ชาร์ดที่มีมากกว่า 2/3 ของลายเซ็นของ validators ที่กำหนดให้กับชาร์ดดังกล่าวจะได้รับการพิจารณาทันที สุดท้าย ด้วยแนวทางดังกล่าว ศัตรูที่ปรับตัวได้จำเป็นต้องทำลาย 2n/3+1 เท่านั้น ของ validators ในชาร์ดเชนเพื่อใช้การเปลี่ยนสถานะที่ไม่ถูกต้อง ซึ่ง แม้ว่ายากที่จะดึงออกมา แต่ก็ไม่ใช่ระดับความปลอดภัยที่เพียงพอสำหรับสาธารณะ blockchain. ตามที่กล่าวไว้ในหัวข้อ 2.3 วิธีการทั่วไปคือการอนุญาตให้มีกรอบเวลาที่แน่นอนหลังจากสร้างบล็อกสำหรับผู้เข้าร่วมที่มีสถานะ (ไม่ว่าจะ เป็นผู้ผลิตบล็อก validator หรือผู้สังเกตการณ์ภายนอก) เพื่อท้าทายความถูกต้อง ผู้เข้าร่วมดังกล่าวเรียกว่าชาวประมง เพื่อให้ชาวประมงสามารถ ท้าทายการบล็อกที่ไม่ถูกต้อง จะต้องแน่ใจว่าบล็อกดังกล่าวพร้อมใช้งาน พวกเขา ความพร้อมใช้งานของข้อมูลใน Nightshade จะกล่าวถึงในหัวข้อ 3.4 ใน Nightshade เมื่อสร้างบล็อกแล้ว ชิ้นส่วนจะไม่ได้รับการตรวจสอบความถูกต้อง ใครก็ได้ยกเว้นผู้ผลิตชิ้นที่แท้จริง โดยเฉพาะผู้ผลิตบล็อกนั้น แนะนำว่าบล็อกโดยธรรมชาติแล้วไม่มีสถานะสำหรับชิ้นส่วนส่วนใหญ่และไม่สามารถตรวจสอบชิ้นส่วนได้ เมื่อบล็อกถัดไปถูกสร้างขึ้น จะมีการรับรอง (ดูหัวข้อ 3.2) ของผู้ผลิตบล็อกหลายรายและ validators แต่เนื่องจากผู้ผลิตบล็อกส่วนใหญ่และ validators ไม่รักษาสถานะ สำหรับชิ้นส่วนส่วนใหญ่เช่นกัน บล็อกที่มีชิ้นส่วนที่ไม่ถูกต้องเพียงชิ้นเดียวจะรวบรวมมากกว่าครึ่งหนึ่งของการรับรองอย่างมีนัยสำคัญและจะยังคงเป็นชิ้นที่หนักที่สุดต่อไป โซ่ เพื่อแก้ไขปัญหานี้ เราอนุญาตให้ผู้เข้าร่วมที่รักษาสถานะของ ชิ้นส่วนที่จะส่งการท้าทายออนไลน์สำหรับชิ้นส่วนที่ไม่ถูกต้องที่สร้างขึ้นในนั้น เศษ 3.7.1 ความท้าทายด้านความถูกต้องของรัฐ เมื่อผู้เข้าร่วมตรวจพบว่าส่วนใดส่วนหนึ่งไม่ถูกต้อง พวกเขาจะต้องแสดงหลักฐานว่าส่วนนั้นไม่ถูกต้อง เนื่องจากผู้เข้าร่วมเครือข่ายส่วนใหญ่ไม่ได้รักษาสถานะของส่วนแบ่งข้อมูลซึ่งมีส่วนที่ไม่ถูกต้องอยู่ หลักฐานจะต้องมีข้อมูลที่เพียงพอเพื่อยืนยันว่าบล็อกนั้นเกิดขึ้น ไม่ถูกต้องโดยไม่ต้องมีรัฐ เรากำหนดขีดจำกัด Ls ของจำนวนสถานะ (เป็นไบต์) ที่ธุรกรรมเดียว สามารถอ่านหรือเขียนสะสมได้ รายการใดแตะมากกว่า Ls รัฐถือว่าไม่ถูกต้อง จำจากข้อ 3.5 ที่ว่าอันนั้น ในบล็อก B มีเพียงธุรกรรมที่จะนำไปใช้เท่านั้น แต่ไม่มี รูตสถานะใหม่ รูตสถานะที่รวมอยู่ในส่วนในบล็อก B คือสถานะ root ก่อนที่จะใช้ธุรกรรมดังกล่าว แต่หลังจากใช้ธุรกรรมจาก ชิ้นสุดท้ายในเศษเดียวกันก่อนบล็อกบีนักแสดงตัวร้ายนั้น ความปรารถนาที่จะใช้การเปลี่ยนสถานะที่ไม่ถูกต้องจะรวมถึงการรูทสถานะที่ไม่ถูกต้อง ในบล็อก B ที่ไม่ตรงกับสถานะรากที่เป็นผลมาจากการสมัคร ธุรกรรมในส่วนก่อนหน้า เราขยายข้อมูลที่ผู้ผลิตก้อนรวมไว้ในก้อนนั้น แทนที่จะรวมสถานะหลังจากใช้ธุรกรรมทั้งหมดแทน รวมสถานะรูทหลังจากใช้ชุดธุรกรรมที่ต่อเนื่องกันแต่ละชุด อ่านและเขียน Ls ไบต์ของรัฐร่วมกัน ด้วยข้อมูลนี้สำหรับ ชาวประมงสร้างความท้าทายว่าการเปลี่ยนสถานะถูกนำไปใช้อย่างไม่ถูกต้องนั่นเอง เพียงพอที่จะค้นหารากสถานะที่ไม่ถูกต้องตัวแรกและรวมเพียง Ls ไบต์ของ สถานะที่ได้รับผลกระทบจากธุรกรรมระหว่างรูตสถานะสุดท้าย (ซึ่งก็คือ ถูกต้อง) และรูตสถานะปัจจุบันพร้อมหลักฐาน Merkle แล้วผู้เข้าร่วมคนใด สามารถตรวจสอบการทำธุรกรรมในส่วนและยืนยันว่าเป็นก้อน ไม่ถูกต้อง ในทำนองเดียวกัน หาก chunk โปรดิวเซอร์พยายามรวมธุรกรรมที่อ่านไว้ และเขียนมากกว่า Ls ไบต์ของ state สำหรับความท้าทายก็เพียงพอแล้วที่จะรวมไว้ ไบต์ Ls แรกที่สัมผัสกับ Merkle Proofs ซึ่งจะเพียงพอแล้ว ใช้ธุรกรรมและยืนยันว่ามีช่วงเวลาที่พยายามจะทำ อ่านหรือเขียนเนื้อหาเกิน Ls ไบต์

3.7.2 ชาวประมงและการทำธุรกรรมข้ามส่วนที่รวดเร็ว ตามที่กล่าวไว้ในหัวข้อ 2.3 เมื่อเราถือว่าชิ้นส่วนนั้น (หรือ shard บล็อกในโมเดลที่มีชาร์ดเชน) อาจไม่ถูกต้องและทำให้เกิดความท้าทายได้ มันจะส่งผลเสียต่อจุดสิ้นสุดและทำให้เกิดการสื่อสารข้ามส่วน ใน โดยเฉพาะอย่างยิ่ง ชิ้นส่วนปลายทางของการทำธุรกรรมข้ามส่วนใดๆ ไม่สามารถแน่นอนได้ ชิ้นส่วนหรือบล็อกต้นกำเนิดจะถือเป็นที่สิ้นสุดจนกว่าระยะเวลาการท้าทายจะสิ้นสุดลง (ดูรูปที่ 21) รูปที่ 21: รอช่วงท้าทายก่อนที่จะสมัครใบเสร็จ วิธีการจัดการในลักษณะที่ทำธุรกรรมข้ามส่วน ทันทีคือการที่ชิ้นส่วนปลายทางไม่ต้องรอช่วงท้าทาย หลังจากเผยแพร่ธุรกรรมส่วนแบ่งข้อมูลต้นทางแล้ว และใช้ธุรกรรมการรับสินค้า ทันทีแต่แล้วย้อนกลับชาร์ดปลายทางพร้อมกับต้นทาง shard หากต่อมาพบว่าก้อนหรือบล็อกต้นกำเนิดไม่ถูกต้อง (ดูรูปที่ 22) สิ่งนี้ใช้ได้กับการออกแบบ Nightshade ที่ชิ้นส่วนนั้นอย่างเป็นธรรมชาติมาก เชนไม่เป็นอิสระ แต่มีการเผยแพร่เศษชิ้นส่วนทั้งหมดแทน รวมกันอยู่ในบล็อกลูกโซ่หลักเดียวกัน หากพบว่าส่วนใดส่วนหนึ่งไม่ถูกต้อง บล็อกทั้งหมดที่มีอันนั้นถือว่าไม่ถูกต้อง และบล็อกทั้งหมดที่สร้างขึ้น ด้านบนของมัน ดูรูปที่ 23 ทั้งสองวิธีข้างต้นให้ความเป็นอะตอมมิกโดยสมมติว่าเป็นความท้าทาย ระยะเวลายาวนานพอควร เราใช้แนวทางหลังเนื่องจากการทำธุรกรรมข้ามส่วนที่รวดเร็วภายใต้สถานการณ์ปกติมีน้ำหนักมากกว่าความไม่สะดวก ชิ้นส่วนปลายทางย้อนกลับเนื่องจากการเปลี่ยนสถานะที่ไม่ถูกต้องในหนึ่งในนั้น ชิ้นส่วนแหล่งที่มาซึ่งเป็นเหตุการณ์ที่หายากมาก 3.7.3 กำลังซ่อน validators การมีอยู่ของความท้าทายลดความน่าจะเป็นลงอย่างมาก การคอร์รัปชั่นแบบปรับตัว เนื่องจากเพื่อสรุปส่วนที่มีการโพสต์การเปลี่ยนสถานะที่ไม่ถูกต้องรูปที่ 22: ใช้ใบเสร็จรับเงินทันทีและย้อนกลับปลายทาง chain หากเชนต้นทางมีบล็อกที่ไม่ถูกต้อง รูปที่ 23: ความท้าทายของชาวประมงใน Nightshade ช่วงเวลาแห่งความท้าทายที่ศัตรูที่ปรับตัวได้จำเป็นต้องทำให้ผู้เข้าร่วมทั้งหมดเสียหาย ที่รักษาสถานะของชาร์ด รวมถึง validators ทั้งหมด การประมาณความน่าจะเป็นของเหตุการณ์ดังกล่าวนั้นซับซ้อนมาก เนื่องจากไม่ Sharded blockchain ใช้งานได้นานเพียงพอสำหรับการพยายามโจมตีดังกล่าว เรายืนยันว่าความน่าจะเป็นแม้จะต่ำมาก แต่ก็ยังเพียงพอ ขนาดใหญ่สำหรับระบบที่คาดว่าจะทำธุรกรรมหลายล้านรายการและ ดำเนินการทางการเงินทั่วโลก มีสองเหตุผลหลักสำหรับความเชื่อนี้: 1. validators ส่วนใหญ่ของเครือข่าย Proof-of-Stake และนักขุดของ

เครือข่าย Proof-of-Work ได้รับการจูงใจจากส่วนต่างทางการเงินเป็นหลัก ถ้า ศัตรูที่ปรับตัวได้จะให้เงินแก่พวกเขามากกว่าผลตอบแทนที่คาดหวัง จากการดำเนินงานโดยสุจริต ก็สมเหตุสมผลที่จะคาดหวังว่าจะมี validators มากมาย จะยอมรับข้อเสนอ 2. หน่วยงานหลายแห่งทำการตรวจสอบความถูกต้องของเครือข่าย Proof-of-Stake อย่างมืออาชีพ และ คาดว่าจะมีสัดส่วนการถือหุ้นจำนวนมากในห่วงโซ่ใดๆ จากหน่วยงานดังกล่าว จำนวนเอนทิตีดังกล่าวมีน้อยเพียงพอสำหรับ ศัตรูที่ปรับตัวได้เพื่อทำความรู้จักกับพวกเขาส่วนใหญ่เป็นการส่วนตัวและมี มีความเข้าใจดีถึงความอวดดีของตนที่จะเสื่อมทราม เราก้าวไปอีกขั้นหนึ่งในการลดความน่าจะเป็นของความเสียหายแบบปรับตัวได้โดยการซ่อนว่า validators ใดถูกกำหนดให้กับชาร์ดใด ความคิดก็คือ คล้ายกับวิธีที่ Algorand [5] ปกปิด validators จากระยะไกล เป็นสิ่งสำคัญที่จะต้องทราบว่าแม้ว่า validators จะถูกปกปิด เช่นเดียวกับใน Algorand หรือตามที่อธิบายไว้ด้านล่าง การทุจริตแบบปรับตัวยังคงเป็นไปได้ในทางทฤษฎี ในขณะที่ ฝ่ายตรงข้ามที่ปรับตัวไม่รู้จักผู้เข้าร่วมที่จะสร้างหรือตรวจสอบ บล็อกหรือชิ้นเดียว ผู้เข้าร่วมเองก็รู้ว่าตนจะต้องแสดง งานดังกล่าวและมีหลักฐานการเข้ารหัส ดังนั้นฝ่ายตรงข้ามจึงสามารถ เผยแพร่เจตนาที่จะคอร์รัปชั่นและจ่ายเงินให้กับผู้เข้าร่วมที่จะจัดหา เป็นการพิสูจน์การเข้ารหัส อย่างไรก็ตาม เราทราบว่าเนื่องจากฝ่ายตรงข้ามไม่ได้ทำ รู้จัก validators ที่ได้รับมอบหมายให้กับชาร์ดที่พวกเขาต้องการทำให้เสียหาย ไม่มีทางเลือกอื่นนอกจากต้องถ่ายทอดเจตนารมณ์ที่จะทำลายชิ้นส่วนเฉพาะให้เสียหาย ชุมชนทั้งหมด เมื่อถึงจุดนั้น จะเป็นประโยชน์เชิงเศรษฐกิจสำหรับผู้ซื่อสัตย์ทุกคน ผู้เข้าร่วมจะหมุนโหนดเต็มเพื่อตรวจสอบความถูกต้องของส่วนนั้น เนื่องจากมีระดับสูง โอกาสที่บล็อกที่ไม่ถูกต้องจะปรากฏในส่วนนั้นซึ่งเป็นโอกาสที่จะ สร้างความท้าทายและสะสมรางวัลที่เกี่ยวข้อง เพื่อไม่ให้เปิดเผย validators ที่ได้รับมอบหมายให้กับส่วนข้อมูลเฉพาะ เราทำอย่างนั้น ต่อไปนี้ (ดูรูปที่ 24): การใช้ VRF เพื่อรับงาน ในตอนต้นของแต่ละยุคแต่ละสมัย validator ใช้ VRF เพื่อรับบิตมาสก์ของชาร์ดที่ validator ถูกกำหนดให้ บิตมาสก์ของ validator แต่ละตัวจะมีบิต Sw (ดูคำจำกัดความที่ 3.3 หัวข้อ ของ SW) จากนั้น validator จะดึงข้อมูลสถานะของส่วนที่เกี่ยวข้อง และ ในช่วงยุคสำหรับแต่ละบล็อกที่ได้รับจะตรวจสอบชิ้นส่วนที่เกี่ยวข้อง ไปยังชิ้นส่วนที่ validator ถูกกำหนดให้ ลงชื่อเข้าใช้บล็อกแทนที่จะเป็นชิ้นๆ เนื่องจากการกำหนดส่วนแบ่งข้อมูลถูกปกปิด validator จึงไม่สามารถลงนามในชิ้นส่วนได้ แต่มันจะส่งสัญญาณทั้งหมดแทนเสมอ บล็อก จึงไม่เปิดเผยว่าชิ้นส่วนใดที่ตรวจสอบได้ โดยเฉพาะอย่างยิ่ง เมื่อ validator ได้รับบล็อกและตรวจสอบความถูกต้องของชิ้นส่วนทั้งหมด มันก็จะสร้างข้อความขึ้นมา ที่พิสูจน์ว่าชิ้นส่วนทั้งหมดในชิ้นส่วนทั้งหมดที่ validator ได้รับมอบหมายให้เป็น ถูกต้อง (โดยไม่ได้ระบุว่าชิ้นส่วนเหล่านั้นคืออะไร) หรือข้อความนั้น มีหลักฐานการเปลี่ยนสถานะที่ไม่ถูกต้องหากส่วนใดส่วนหนึ่งไม่ถูกต้อง ดู ส่วนที่ 3.8 สำหรับรายละเอียดเกี่ยวกับวิธีการรวบรวมข้อความดังกล่าว ส่วนที่ 3.7.4 สำหรับ รายละเอียดเกี่ยวกับวิธีป้องกัน validators จากการสนับสนุนแบบหมูในข้อความ validators อื่นๆ และส่วนที่ 3.7.5 สำหรับรายละเอียดวิธีการให้รางวัลและการลงโทษ validators ควรประสบความสำเร็จในการท้าทายการเปลี่ยนสถานะที่ไม่ถูกต้องเกิดขึ้นจริงรูปที่ 24: ซ่อน validators ใน Nightshade 3.7.4 กระทำ-เปิดเผย หนึ่งในปัญหาทั่วไปของ validators คือ validator สามารถข้ามการดาวน์โหลดสถานะและตรวจสอบความถูกต้องของชิ้นส่วนและบล็อกได้จริง และแทน สังเกตเครือข่าย ดูว่า validators อื่นๆ ส่งอะไรและทำซ้ำ ข้อความ validator ที่เป็นไปตามกลยุทธ์ดังกล่าวไม่ได้ให้อะไรเพิ่มเติม ความปลอดภัยให้กับเครือข่ายแต่สะสมผลตอบแทน วิธีแก้ไขปัญหาทั่วไปสำหรับปัญหานี้คือการให้ validator แต่ละรายการแสดงหลักฐาน พวกเขาตรวจสอบความถูกต้องของบล็อกแล้ว เช่น โดยการระบุการติดตามที่ไม่ซ้ำกัน ของการใช้การเปลี่ยนสถานะ แต่การพิสูจน์ดังกล่าวทำให้ต้นทุนเพิ่มขึ้นอย่างมาก ของการตรวจสอบ รูปที่ 25: มุ่งมั่นเปิดเผย

แต่เราให้ validators กระทำการแรกกับผลการตรวจสอบ (อย่างใดอย่างหนึ่ง ข้อความที่ยืนยันถึงความถูกต้องของชิ้นส่วนต่างๆ หรือการพิสูจน์ว่าไม่ถูกต้อง การเปลี่ยนสถานะ) ให้รอสักระยะหนึ่งแล้วจึงเปิดเผยผลการตรวจสอบจริงตามที่แสดงในรูปที่ 25 ระยะเวลาที่กระทำไม่ตัดกับ ระยะเวลาการเปิดเผย และด้วยเหตุนี้ validator ที่ขี้เกียจจึงไม่สามารถลอกเลียนแบบ validators ที่ซื่อสัตย์ได้ ยิ่งไปกว่านั้น หาก validator ที่ไม่ซื่อสัตย์ได้กระทำการต่อข้อความที่เป็นเครื่องยืนยันถึง ความถูกต้องของชิ้นที่ได้รับมอบหมาย และอย่างน้อยหนึ่งชิ้นที่ไม่ถูกต้อง เมื่อเป็นเช่นนั้น แสดงว่าอันนั้นไม่ถูกต้อง validator ไม่สามารถหลีกเลี่ยงการทับได้เนื่องจาก ดังที่เราแสดงในส่วน 3.7.5 วิธีเดียวที่จะไม่ถูกเฉือนในสถานการณ์เช่นนี้ คือการนำเสนอข้อความที่มีการพิสูจน์การเปลี่ยนสถานะที่ไม่ถูกต้องว่า ตรงกับการคอมมิต 3.7.5 การจัดการกับความท้าทาย ตามที่กล่าวไว้ข้างต้น เมื่อ validator ได้รับบล็อกที่มีชิ้นส่วนที่ไม่ถูกต้อง ก่อนอื่นพวกเขาเตรียมหลักฐานการเปลี่ยนสถานะที่ไม่ถูกต้อง (ดูหัวข้อ 3.7.1) จากนั้น ยอมรับการพิสูจน์ดังกล่าว (ดู 3.7.4) และหลังจากผ่านไประยะหนึ่งก็เปิดเผยการท้าทาย เมื่อรวมความท้าทายที่เปิดเผยไว้ในบล็อกแล้ว สิ่งต่อไปนี้จะเกิดขึ้น: 1. การเปลี่ยนแปลงสถานะทั้งหมดที่เกิดขึ้นจากบล็อกที่มี ชิ้นที่ไม่ถูกต้องจนกระทั่งบล็อกที่มีการท้าทายที่เปิดเผยรวมอยู่ด้วย เป็นโมฆะ สถานะก่อนบล็อกที่มีการท้าทายที่เปิดเผย ถือว่าเหมือนกับสถานะก่อนบล็อกที่มีอยู่ ชิ้นที่ไม่ถูกต้อง 2. ภายในระยะเวลาที่กำหนด แต่ละ validator จะต้องเปิดเผยบิตมาสก์ของตน ของชิ้นส่วนที่พวกเขาตรวจสอบ เนื่องจากบิตมาสก์ถูกสร้างขึ้นผ่าน VRF ถ้า พวกเขาได้รับมอบหมายให้อยู่ในชิ้นส่วนที่มีการเปลี่ยนสถานะที่ไม่ถูกต้อง ไม่สามารถหลีกเลี่ยงการเปิดเผยได้ validator ใดๆ ที่ไม่เปิดเผยบิตมาสก์ ถือว่าได้รับมอบหมายให้ชาร์ด 3. validator แต่ละอันที่พบว่าหลังจากช่วงเวลาดังกล่าวถูกกำหนดให้กับชาร์ด ที่กระทำต่อผลการตรวจสอบความถูกต้องบางอย่างสำหรับบล็อกที่มี ชิ้นที่ไม่ถูกต้องและนั่นไม่ได้เปิดเผยหลักฐานการเปลี่ยนสถานะที่ไม่ถูกต้อง ที่สอดคล้องกับการกระทำของพวกเขาจะถูกเฉือน 4. validator แต่ละตัวได้รับการมอบหมายส่วนย่อยใหม่ และมีการกำหนดยุคใหม่ไว้ เพื่อเริ่มต้นหลังจากเวลาผ่านไปพอสมควรสำหรับ validators ทั้งหมดที่จะดาวน์โหลด สถานะดังแสดงในรูปที่ 26 โปรดทราบว่าตั้งแต่วินาทีที่ validators เปิดเผยส่วนแบ่งข้อมูลที่พวกเขาได้รับมอบหมาย จนถึงยุคใหม่ความปลอดภัยของระบบก็ลดลงตั้งแต่ การเปิดเผยการมอบหมายเศษ ผู้เข้าร่วมเครือข่ายจำเป็นต้องเก็บไว้ คำนึงถึงขณะใช้งานเครือข่ายในช่วงเวลาดังกล่าว 3.8 การรวมลายเซ็น เพื่อให้ระบบที่มีชาร์ดจำนวนมากทำงานอย่างปลอดภัย เราต้องการให้มี คำสั่งซื้อ 10, 000 หรือมากกว่า validators ตามที่กล่าวไว้ในหัวข้อ 3.7 เราต้องการแต่ละอย่างรูปที่ 26: จัดการกับความท้าทาย validator เพื่อเผยแพร่การกระทำต่อข้อความบางอย่างและลายเซ็นโดยเฉลี่ย หนึ่งครั้งต่อบล็อก แม้ว่าข้อความการคอมมิตจะเหมือนกันก็ตาม แต่โดยรวมแล้ว การลงนาม BLS และการตรวจสอบความถูกต้องจะมีราคาแพงมาก แต่ โดยธรรมชาติแล้วข้อความที่ส่งและเปิดเผยจะไม่เหมือนกันใน validators และด้วยเหตุนี้เราจึงจำเป็นต้องมีวิธีที่จะรวมข้อความดังกล่าวและลายเซ็นไว้ใน วิธีที่ช่วยให้สามารถตรวจสอบความถูกต้องได้อย่างรวดเร็วในภายหลัง แนวทางเฉพาะที่เราใช้มีดังต่อไปนี้: ผู้ตรวจสอบความถูกต้องเข้าร่วมกับผู้ผลิตบล็อก ผู้ผลิตบล็อกเป็นที่รู้จัก ก่อนที่ยุคจะเริ่มต้น เนื่องจากต้องใช้เวลาในการดาวน์โหลด ระบุก่อนที่ยุคจะเริ่มต้น และไม่เหมือนกับ validators ที่ผู้สร้างบล็อกเป็น ไม่ได้ปกปิด ผู้ผลิตบล็อกแต่ละรายมีช่อง v validator ผู้ตรวจสอบส่ง ข้อเสนอของ off-chain ให้กับผู้ผลิตบล็อกเพื่อรวมเป็นหนึ่งใน v validatorส. หากผู้ผลิตบล็อกต้องการรวม validator พวกเขาจะส่งข้อมูล ธุรกรรมที่มีคำขอ of-chain เริ่มต้นจาก validator และ ลายเซ็นของผู้ผลิตบล็อกที่ทำให้ validator เข้าร่วมกับผู้ผลิตบล็อก โปรดทราบว่า validators ที่กำหนดให้กับผู้สร้างบล็อกนั้นไม่จำเป็นเสมอไป ตรวจสอบชิ้นส่วนเดียวกันกับที่ผู้สร้างบล็อกสร้างชิ้นส่วนให้ ถ้าก validator นำไปใช้กับผู้ผลิตบล็อกหลายราย เฉพาะธุรกรรมจากเท่านั้น ผู้ผลิตบล็อกแรกจะประสบความสำเร็จ ผู้ผลิตบล็อกรวบรวมคอมมิต ผู้ผลิตบล็อกรวบรวมคอมมิตและเปิดเผยข้อความจาก validators อย่างต่อเนื่อง เมื่อสะสมข้อความดังกล่าวครบจำนวนหนึ่งแล้ว ผู้ผลิตบล็อกจะคำนวณ Merkle แผนผังของข้อความเหล่านี้ และส่งไปยังแต่ละ validator ราก Merkle และ เส้นทาง Merkle ไปยังข้อความของพวกเขา validator ตรวจสอบเส้นทางและลงชื่อเข้าใช้ รากเมิร์เคิล ผู้ผลิตบล็อกจะสะสมลายเซ็น BLS บน merkle root จาก validators และเผยแพร่เฉพาะ merkle root และ ลายเซ็นสะสม ผู้ผลิตบล็อกยังลงนามในความถูกต้องของ ลายเซ็นหลายลายเซ็นโดยใช้ลายเซ็น ECDSA ราคาถูก หากลายเซ็นหลายฉบับไม่เป็นเช่นนั้น ตรงกับราก Merkle ที่ส่งมาหรือบิตมาสก์ของ validators ที่เข้าร่วม ซึ่งเป็นพฤติกรรมที่สามารถเฉือนได้ เมื่อซิงโครไนซ์ห่วงโซ่ผู้เข้าร่วม สามารถเลือกตรวจสอบความถูกต้องของลายเซ็น BLS ทั้งหมดจาก validators (ซึ่งมีราคาแพงมากเนื่องจากเกี่ยวข้องกับการรวมกุญแจสาธารณะ validators) หรือเท่านั้นลายเซ็น ECDMA จากผู้ผลิตบล็อกและอาศัยข้อเท็จจริงที่ว่า ผู้ผลิตบล็อกไม่ถูกท้าทายและเฉือน การใช้ธุรกรรมออนไลน์และการพิสูจน์ Merkle เพื่อความท้าทาย มัน สามารถสังเกตได้ว่าไม่มีประโยชน์ในการเปิดเผยข้อความจาก validators หากไม่มี ตรวจพบการเปลี่ยนสถานะที่ไม่ถูกต้อง เฉพาะข้อความที่มีเนื้อหาจริงเท่านั้น จำเป็นต้องเปิดเผยหลักฐานการเปลี่ยนสถานะที่ไม่ถูกต้อง และสำหรับข้อความดังกล่าวเท่านั้น จะต้องแสดงให้เห็นว่าตรงกับการกระทำก่อนหน้า ข้อความที่ต้องการ เปิดเผยเพื่อวัตถุประสงค์สองประการ: 1. เพื่อเริ่มต้นการย้อนกลับของห่วงโซ่จนถึงช่วงเวลาก่อนหน้า การเปลี่ยนสถานะไม่ถูกต้อง (ดูหัวข้อ 3.7.5) 2. เพื่อพิสูจน์ว่า validator ไม่ได้พยายามยืนยันถึงความถูกต้องของ ชิ้นที่ไม่ถูกต้อง ไม่ว่าในกรณีใด เราจำเป็นต้องแก้ไขปัญหาสองประเด็น: 1. การคอมมิตจริงไม่ได้รวมอยู่ใน chain มีเพียง merkle root ของ the เท่านั้น กระทำรวมกับข้อความอื่น ๆ validator จำเป็นต้องใช้ เส้นทาง Merkle จัดทำโดยผู้สร้างบล็อกและการกระทำดั้งเดิมของพวกเขา พิสูจน์ว่าพวกเขามุ่งมั่นที่จะท้าทาย 2. เป็นไปได้ที่ validators ทั้งหมดที่กำหนดให้กับส่วนแบ่งที่ไม่ถูกต้อง การเปลี่ยนแปลงสถานะถูกกำหนดให้กับผู้ผลิตบล็อกที่เสียหาย กำลังเซ็นเซอร์พวกเขา เพื่อแก้ไขปัญหานี้ เราอนุญาตให้พวกเขาส่งการเปิดเผยของพวกเขา เป็นธุรกรรมออนไลน์ปกติและข้ามการรวมกลุ่ม ส่วนหลังได้รับอนุญาตเฉพาะสำหรับการพิสูจน์การเปลี่ยนสถานะที่ไม่ถูกต้องเท่านั้น ซึ่งได้แก่ หายากมาก และไม่ควรส่งผลให้เกิดการส่งสแปมบล็อก ปัญหาสุดท้ายที่ต้องแก้ไขคือผู้ผลิตบล็อกสามารถทำได้ เลือกที่จะไม่มีส่วนร่วมในการรวบรวมข้อความหรือจงใจเซ็นเซอร์ validators โดยเฉพาะ เราทำให้มันเสียเปรียบทางเศรษฐกิจโดยการสร้างบล็อก รางวัลผู้ผลิตตามสัดส่วนของจำนวน validators ที่ได้รับมอบหมาย เรา โปรดทราบว่าเนื่องจากผู้ผลิตบล็อกระหว่างยุคส่วนใหญ่ตัดกัน (since จะเป็นผู้เข้าร่วมอันดับต้นๆ ที่มีเดิมพันสูงสุดเสมอ) validators สามารถทำได้ ส่วนใหญ่ยึดติดกับการทำงานร่วมกับผู้ผลิตบล็อกรายเดียวกัน จึงช่วยลดความเสี่ยงได้ ของการได้รับมอบหมายให้เป็นผู้ผลิตบล็อกที่เคยเซ็นเซอร์พวกเขาในอดีต 3.9 ห่วงโซ่ภาพรวม เนื่องจากบล็อกบนเชนหลักมีการผลิตบ่อยมาก จึงทำการดาวน์โหลด ประวัติทั้งหมดอาจมีราคาแพงอย่างรวดเร็ว นอกจากนี้เนื่องจากทุกๆ บล็อกมีลายเซ็น BLS ของผู้เข้าร่วมจำนวนมาก เพียงการรวมคีย์สาธารณะเพื่อตรวจสอบลายเซ็นอาจกลายเป็นสิ่งต้องห้าม แพงเช่นกัน ในที่สุด เนื่องจากในอนาคตอันใกล้นี้ Ethereum 1.0 จะยังคงเป็นหนึ่งเดียว ของ blockchains ที่ใช้มากที่สุด ซึ่งมีวิธีการถ่ายโอนเนื้อหาที่มีความหมาย

ใกล้ Ethereum เป็นข้อกำหนด และในปัจจุบันมีการตรวจสอบลายเซ็น BLS เพื่อให้มั่นใจ ความถูกต้องของ Near Block บนฝั่งของ Ethereum นั้นเป็นไปไม่ได้ แต่ละบล็อกในสายโซ่หลักของ Nightshade สามารถมี Schnorr ได้หรือไม่ multisignature บนส่วนหัวของบล็อกสุดท้ายที่มี Schnorr ดังกล่าว หลายลายเซ็น เราเรียกบล็อกดังกล่าวว่าบล็อกสแน็ปช็อต บล็อกแรกของ ทุกยุคจะต้องเป็นบล็อกสแน็ปช็อต ในขณะที่ทำงานเกี่ยวกับลายเซ็นหลายใบดังกล่าว ผู้ผลิตบล็อกจะต้องสะสมลายเซ็น BLS ของ validators ด้วย ในบล็อกสแน็ปช็อตสุดท้าย และรวมเข้าด้วยกันในลักษณะเดียวกับที่อธิบายไว้ใน มาตรา 3.8 เนื่องจากชุดตัวสร้างบล็อกมีค่าคงที่ตลอดยุค จึงมีการตรวจสอบความถูกต้อง เฉพาะบล็อกสแน็ปช็อตแรกในแต่ละยุคเท่านั้นที่เพียงพอหากถือว่าไม่ใช่ ชี้ให้เห็นถึงผู้ผลิตบล็อกจำนวนมากและ validators สมรู้ร่วมคิดและสร้าง ส้อม บล็อกแรกของยุคจะต้องมีข้อมูลที่เพียงพอในการคำนวณ ผู้ผลิตบล็อกและ validators สำหรับยุค เราเรียกห่วงโซ่ย่อยของห่วงโซ่หลักที่มีเฉพาะสแน็ปช็อตเท่านั้น บล็อกลูกโซ่สแน็ปช็อต การสร้างลายเซ็นหลายลายเซ็นของ Schnorr นั้นเป็นกระบวนการเชิงโต้ตอบ แต่เนื่องจากเรา จำเป็นต้องดำเนินการไม่บ่อยนัก ไม่ว่าจะดำเนินการจะด้อยแค่ไหนก็ตาม จะประสบความสำเร็จ ลายเซ็นหลายลายเซ็นของ Schnorr สามารถตรวจสอบได้อย่างง่ายดายบน Ethereum, จึงให้พื้นฐานที่สำคัญสำหรับวิธีการที่ปลอดภัยในการดำเนินการ cross-blockchain การสื่อสาร หากต้องการซิงค์กับ Near chain จะต้องดาวน์โหลดสแนปช็อตทั้งหมดเท่านั้น บล็อกและยืนยันว่าลายเซ็น Schnorr นั้นถูกต้อง (หรืออาจเลือกตรวจสอบลายเซ็น BLS แต่ละรายการของ validators) จากนั้นจึงทำการซิงค์เท่านั้น บล็อกลูกโซ่หลักจากบล็อกสแน็ปช็อตสุดท้าย

บทสรุป

ในเอกสารนี้ เราได้กล่าวถึงแนวทางในการสร้างการแบ่งส่วน blockchains และ ครอบคลุมความท้าทายหลักสองประการด้วยแนวทางที่มีอยู่ ได้แก่ ความถูกต้องของรัฐ และความพร้อมของข้อมูล จากนั้นเราก็นำเสนอ Nightshade ซึ่งเป็นการออกแบบการแบ่งส่วนนั้น อำนาจ NEAR โปรโตคอล การออกแบบอยู่ในระหว่างดำเนินการ หากคุณมีความคิดเห็น คำถาม หรือข้อเสนอแนะ ในเอกสารนี้ โปรดไปที่ https://near.chat.