Sách trắng NEAR

โดย Alex Skidanov and Illia Polosukhin · 2019

🇺🇸 English (ต้นฉบับ)

🇻🇳 Tiếng Việt (คำแปล)

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

มาเริ่มกันด้วยวิธีที่ง่ายที่สุดในการแบ่งส่วน ในแนวทางนี้แทน เรียกใช้หนึ่ง 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 ด้านล่าง

Khái niệm cơ bản về Sharding

Hãy bắt đầu với cách tiếp cận đơn giản nhất để phân chia. Trong cách tiếp cận này thay vì đang chạy một blockchain, chúng tôi sẽ chạy nhiều cái và gọi mỗi cái đó là blockchain a “mảnh vỡ”. Mỗi phân đoạn sẽ có tập hợp validators riêng. Ở đây và dưới đây chúng tôi sử dụng thuật ngữ chung “validator” để chỉ những người tham gia xác minh giao dịch và tạo ra các khối bằng cách khai thác, chẳng hạn như trong Bằng chứng công việc hoặc thông qua cơ chế bỏ phiếu dựa trên 1Phần này đã được xuất bản trước đây tại https://near.ai/shard1. Nếu bạn đã đọc nó trước đây, chuyển sang phần tiếp theo.

cơ chế. Bây giờ hãy giả sử rằng các phân đoạn không bao giờ giao tiếp với nhau khác. Thiết kế này, mặc dù đơn giản, nhưng cũng đủ để phác thảo một số thách thức lớn ban đầu trong việc bảo vệ. 1.1 Phân vùng trình xác thực và chuỗi Beacon Giả sử hệ thống bao gồm 10 phân đoạn. Thử thách đầu tiên là với mỗi phân đoạn có validator riêng, mỗi phân đoạn hiện kém an toàn hơn 10 lần so với phân đoạn toàn bộ chuỗi. Vì vậy, nếu một chuỗi không được phân đoạn có X validators quyết định phân tách cứng thành một chuỗi phân đoạn và chia X validators thành 10 phân đoạn, bây giờ mỗi phân đoạn chỉ có X/10 validators và việc làm hỏng một phân đoạn chỉ cần làm hỏng 5,1% (51% / 10) trong tổng số validators (xem hình 1), Hình 1: Chia validator thành các phân đoạn điều này đưa chúng ta đến điểm thứ hai: ai chọn validators cho mỗi phân đoạn? Việc kiểm soát 5,1% trong số validator chỉ gây tổn hại nếu tất cả 5,1% trong số validator đó nằm trong cùng một phân đoạn. Nếu validator không thể chọn phân đoạn nào họ sẽ xác thực trong đó, người tham gia kiểm soát 5,1% trong số validator rất khó có thể nhận được tất cả validator của họ trong cùng một phân đoạn, làm giảm đáng kể khả năng thỏa hiệp của họ hệ thống. Hầu như tất cả các thiết kế sharding ngày nay đều dựa vào một số nguồn ngẫu nhiên để gán validators cho phân đoạn. Bản thân tính ngẫu nhiên của blockchain đã là một chủ đề rất khó khăn và nằm ngoài phạm vi của tài liệu này. Bây giờ hãy giả sử có một số nguồn ngẫu nhiên mà chúng ta có thể sử dụng. Chúng tôi sẽ thực hiện nhiệm vụ của validator trong chi tiết hơn ở phần 2.1. Cả tính ngẫu nhiên và phép gán validator đều yêu cầu tính toán không phù hợp cụ thể cho bất kỳ phân đoạn cụ thể nào. Đối với tính toán đó, thực tế tất cả hiện có các thiết kế có blockchain riêng biệt được giao nhiệm vụ thực hiện các hoạt động cần thiết cho việc duy trì toàn bộ mạng. Bên cạnh việc tạo ngẫu nhiêncác số và gán validators cho các phân đoạn, các thao tác này cũng thường bao gồm nhận thông tin cập nhật từ các phân đoạn và chụp ảnh nhanh chúng, xử lý đặt cược và cắt giảm trong hệ thống Proof-of-Stake, đồng thời tái cân bằng các phân đoạn khi điều đó tính năng được hỗ trợ. Chuỗi như vậy được gọi là chuỗi Beacon trong Ethereum, Rơle chuỗi trong PolkaDot và Cosmos Hub trong Cosmos. Trong suốt tài liệu này, chúng tôi sẽ gọi chuỗi đó là chuỗi Beacon. Sự tồn tại của chuỗi Beacon đưa chúng ta đến chủ đề thú vị tiếp theo, phân mảnh bậc hai. 1.2 Phân mảnh bậc hai Sharding thường được quảng cáo như một giải pháp có quy mô vô hạn theo số lượng của các nút tham gia vào hoạt động của mạng. Mặc dù về mặt lý thuyết có thể thiết kế một giải pháp sharding như vậy, bất kỳ giải pháp nào có khái niệm Beacon chuỗi không có khả năng mở rộng vô hạn. Để hiểu lý do tại sao, hãy lưu ý rằng Beacon chuỗi phải thực hiện một số tính toán kế toán, chẳng hạn như gán validators cho phân đoạn hoặc chụp nhanh các khối chuỗi phân đoạn, tỷ lệ thuận với số lượng của các phân đoạn trong hệ thống. Vì bản thân chuỗi Beacon là một blockchain duy nhất, với tính toán bị giới hạn bởi khả năng tính toán của các nút vận hành nó, số lượng mảnh vỡ đương nhiên là có hạn. Tuy nhiên, cấu trúc của một mạng phân mảnh mang lại khả năng nhân lên ảnh hưởng đến bất kỳ cải tiến nào đối với các nút của nó. Hãy xem xét trường hợp trong đó một cách tùy ý sự cải thiện được thực hiện đối với hiệu quả của các nút trong mạng sẽ cho phép họ có thời gian xử lý giao dịch nhanh hơn. Nếu các nút vận hành mạng, bao gồm các nút trong chuỗi Beacon, nhanh hơn bốn lần thì mỗi phân đoạn sẽ có thể xử lý gấp bốn lần giao dịch và chuỗi Beacon sẽ có thể duy trì số phân đoạn nhiều hơn 4 lần. Thông lượng trên toàn hệ thống sẽ tăng theo hệ số 4 × 4 = 16 - do đó có tên là sharding bậc hai. Thật khó để đưa ra một phép đo chính xác về số lượng mảnh vỡ khả thi ngày hôm nay, nhưng không chắc rằng trong tương lai gần, thông lượng nhu cầu của blockchain người dùng sẽ vượt qua giới hạn của phân đoạn bậc hai. Số lượng nút cần thiết để vận hành khối lượng phân đoạn như vậy một cách an toàn có khả năng cao hơn số lượng nút vận hành tất cả blockchain tổng hợp ngày hôm nay. 1.3 Phân chia trạng thái Cho đến nay chúng ta vẫn chưa định nghĩa rõ ràng chính xác cái gì là và cái gì không tách rời. khi một mạng được chia thành các phân đoạn. Cụ thể, các nút trong blockchain thực hiện ba nhiệm vụ quan trọng: không chỉ 1) xử lý các giao dịch mà còn đồng thời 2) chuyển tiếp các giao dịch đã được xác thực và các khối đã hoàn thành tới các nút khác và 3) lưu trữ trạng thái và lịch sử của toàn bộ sổ cái mạng. Mỗi cái trong số ba cái này nhiệm vụ đặt ra yêu cầu ngày càng tăng đối với các nút vận hành mạng:1. Sự cần thiết phải xử lý các giao dịch đòi hỏi nhiều sức mạnh tính toán hơn với số lượng giao dịch được xử lý tăng lên; 2. Sự cần thiết phải chuyển tiếp các giao dịch và khối đòi hỏi nhiều băng thông mạng hơn với số lượng giao dịch được chuyển tiếp tăng lên; 3. Nhu cầu lưu trữ dữ liệu đòi hỏi nhiều bộ nhớ hơn khi trạng thái phát triển. Điều quan trọng là, không giống như sức mạnh xử lý và mạng lưới, yêu cầu lưu trữ tăng lên ngay cả khi tốc độ giao dịch (số lượng giao dịch được xử lý) mỗi giây) không đổi. Từ danh sách trên, có vẻ như yêu cầu về dung lượng lưu trữ sẽ là cấp bách nhất, vì nó là thứ duy nhất đang được tăng lên theo thời gian ngay cả khi số lượng giao dịch mỗi giây không thay đổi, nhưng trên thực tế yêu cầu cấp bách nhất hiện nay là sức mạnh tính toán. Toàn bộ trạng thái của Ethereum tính đến thời điểm viết bài này là 100GB, hầu hết các nút đều có thể dễ dàng quản lý. Nhưng số lượng giao dịch Ethereum có thể xử lý là khoảng 20, đơn hàng cường độ nhỏ hơn mức cần thiết cho nhiều trường hợp sử dụng thực tế. Zilliqa là dự án nổi tiếng nhất xử lý phân đoạn nhưng không lưu trữ. Phân chia quá trình xử lý là một vấn đề dễ dàng hơn vì mỗi nút có toàn bộ trạng thái, nghĩa là các hợp đồng có thể tự do gọi các hợp đồng khác và đọc bất kỳ dữ liệu nào từ blockchain. Cần có một số kỹ thuật cẩn thận để đảm bảo cập nhật từ nhiều phân đoạn cập nhật các phần giống nhau của trạng thái không xung đột. trong những điều đó liên quan đến Zilliqa đang thực hiện một cách tiếp cận tương đối đơn giản2. Mặc dù việc phân chia lưu trữ mà không phân chia quá trình xử lý đã được đề xuất, nhưng cực kỳ không phổ biến. Do đó, trong thực tế phân mảnh lưu trữ, hay còn gọi là State Sharding, hầu như luôn bao hàm việc phân chia quá trình xử lý và phân chia mạng. Trên thực tế, theo State Sharding, các nút trong mỗi phân đoạn đang xây dựng sở hữu blockchain chứa các giao dịch chỉ ảnh hưởng đến phần cục bộ của trạng thái toàn cầu được gán cho phân đoạn đó. Do đó, validator trong phân đoạn chỉ cần lưu trữ phần cục bộ của trạng thái toàn cục và chỉ thực thi, và như vậy chỉ chuyển tiếp các giao dịch ảnh hưởng đến phần trạng thái của chúng. Cái này phân vùng giảm tuyến tính yêu cầu về tất cả sức mạnh tính toán, lưu trữ và băng thông mạng nhưng lại gây ra các vấn đề mới, chẳng hạn như tính sẵn có của dữ liệu và giao dịch chéo, cả hai giao dịch này chúng tôi sẽ đề cập bên dưới. 1.4 Giao dịch chéo Mô hình sharding mà chúng tôi mô tả cho đến nay không hữu ích lắm, bởi vì nếu cá nhân các mảnh không thể giao tiếp với nhau, chúng không tốt hơn nhiều độc lập blockchains. Thậm chí ngày nay, khi không có sharding, vẫn có một nhu cầu rất lớn về khả năng tương tác giữa các blockchain khác nhau. Bây giờ chúng ta chỉ xem xét các giao dịch thanh toán đơn giản, trong đó mỗi người tham gia có tài khoản trên chính xác một phân đoạn. Nếu người ta muốn chuyển tiền từ 2Bạn có thể tìm thấy phân tích của chúng tôi về cách tiếp cận của họ tại đây: https://medium.com/nearprotocol/ 8f9efae0ce3btài khoản này sang tài khoản khác trong cùng một phân đoạn, giao dịch có thể được xử lý hoàn toàn bởi validator trong phân đoạn đó. Tuy nhiên, nếu Alice cư trú trên mảnh vỡ

1 muốn gửi tiền cho Bob, người cư trú trên phân đoạn #2, không phải validators

trên phân đoạn số 1(họ sẽ không thể ghi có vào tài khoản của Bob) cũng như validator trên phân đoạn số 2 (họ sẽ không thể ghi nợ tài khoản của Alice) có thể xử lý toàn bộ giao dịch. Có hai nhóm phương pháp tiếp cận giao dịch chéo: • Đồng bộ: bất cứ khi nào một giao dịch chéo phân đoạn cần được thực hiện, các khối trong nhiều phân đoạn chứa sự chuyển đổi trạng thái liên quan đến tất cả giao dịch được thực hiện cùng một lúc và validator của nhiều phân đoạn cộng tác để thực hiện các giao dịch đó.3 • Không đồng bộ: giao dịch chéo ảnh hưởng đến nhiều phân đoạn được thực thi không đồng bộ trong các phân đoạn đó, phân đoạn “Tín dụng” thực thi một nửa của nó khi nó có đủ bằng chứng cho thấy phân đoạn “Ghi nợ” đã thực hiện phần của nó. Cách tiếp cận này có xu hướng phổ biến hơn do nó sự đơn giản và dễ phối hợp. Hệ thống này ngày nay được đề xuất ở Cosmos, Ethereum Serenity, Near, Kadena và các hệ thống khác. Một vấn đề với điều này Cách tiếp cận nằm ở chỗ nếu các khối được tạo độc lập thì có khả năng khác không là một trong nhiều khối sẽ mồ côi, do đó tạo ra giao dịch chỉ được áp dụng một phần. Hãy xem xét hình 2 mô tả hai cả hai phân đoạn đều gặp phải phân nhánh và giao dịch phân đoạn chéo được ghi vào khối A và X’ tương ứng. Nếu chuỗi A-B và V'-X'-Y'-Z' cuối cùng trở thành chuẩn trong các phân đoạn tương ứng, giao dịch được hoàn tất đầy đủ. Nếu A’-B’-C’-D’ và V-X trở thành chuẩn, thì giao dịch bị hủy bỏ hoàn toàn, điều này có thể chấp nhận được. Nhưng nếu, vì ví dụ: A-B và V-X trở thành hợp quy, khi đó một phần của giao dịch được hoàn tất và một phần bị hủy, tạo ra lỗi về tính nguyên tử. Chúng tôi sẽ đề cập đến cách giải quyết vấn đề này trong các giao thức được đề xuất ở phần thứ hai, khi đề cập đến những thay đổi đối với quy tắc lựa chọn ngã ba và sự đồng thuận các thuật toán được đề xuất cho các giao thức sharded. Lưu ý rằng giao tiếp giữa các chuỗi rất hữu ích bên ngoài blockchain được phân chia quá. Khả năng tương tác giữa các chuỗi là một vấn đề phức tạp mà nhiều dự án đang cố gắng giải quyết. Trong blockchain được phân chia, vấn đề có phần dễ dàng hơn vì cấu trúc khối và sự đồng thuận là giống nhau giữa các phân đoạn và có một chuỗi đèn hiệu có thể được sử dụng để phối hợp. Tuy nhiên, trong một blockchain phân mảnh, tất cả các chuỗi phân đoạn đều giống nhau, trong khi đó trong hệ sinh thái blockchain toàn cầu thì có có rất nhiều blockchain khác nhau, với các trường hợp sử dụng mục tiêu khác nhau, phân cấp và đảm bảo quyền riêng tư. Xây dựng một hệ thống trong đó một tập hợp các chuỗi có các đặc tính khác nhau nhưng sử dụng sự đồng thuận và cấu trúc khối tương tự nhau và có một chuỗi báo hiệu chung có thể tạo ra một hệ sinh thái gồm các blockchain không đồng nhất có 3Cái nhất chi tiết đề nghị được biết đến để cái tác giả của cái này tài liệu là Hợp nhất khối, được mô tả đây: https://ethresear.ch/t/ hợp nhất-khối-và-đồng bộ-thực thi chéo-shard-state/1240Hình 2: Giao dịch chéo không đồng bộ hệ thống con có khả năng tương tác làm việc. Hệ thống như vậy khó có thể có tính năng xoay validator, vì vậy cần thực hiện một số biện pháp bổ sung để đảm bảo an ninh. Cả hai Cosmos và PolkaDot thực sự là những hệ thống như vậy4 1,5 Hành vi độc hại Trong phần này, chúng tôi sẽ xem xét hành vi đối nghịch nào có thể gây hại cho validators tập thể dục nếu họ cố gắng làm hỏng một phân đoạn. Chúng tôi sẽ xem xét các phương pháp cổ điển để tránh làm hỏng các phân đoạn trong phần 2.1. 1.5.1 Những nhánh độc hại Một tập hợp validator độc hại có thể cố gắng tạo một nhánh. Lưu ý rằng nó không quan trọng là sự đồng thuận cơ bản có phải là BFT hay không, làm hỏng đủ số trong số validator sẽ luôn có thể tạo một nhánh. Có nhiều khả năng hơn 50% của một phân đoạn bị hỏng hơn là hơn 50% toàn bộ mạng bị hỏng (chúng tôi sẽ đi sâu hơn vào các xác suất này trong phần 2.1). Như đã thảo luận ở phần 1.4, giao dịch chéo liên quan đến những thay đổi trạng thái nhất định trong nhiều phân đoạn và các khối tương ứng trong các phân đoạn áp dụng những thay đổi trạng thái đó phải đều đã được hoàn thiện (tức là xuất hiện trong các chuỗi đã chọn trên tương ứng của chúng các phân đoạn) hoặc tất cả đều mồ côi (tức là không xuất hiện trong các chuỗi đã chọn trên các phân đoạn tương ứng của chúng). Vì nhìn chung xác suất các mảnh bị hỏng 4Tham khảo bài viết này của Zaki Manian từ Cosmos: https://forum.cosmos.network/ t/polkadot-vs-cosmos/1397/2 và cơn bão tweet này của tác giả đầu tiên của tài liệu này: https://twitter.com/AlexSkidanov/status/1129511266660126720 để so sánh chi tiết của hai

không phải là không đáng kể, chúng tôi không thể cho rằng việc phân nhánh sẽ không xảy ra ngay cả khi đã đạt được sự đồng thuận lớn giữa các phân đoạn validator hoặc nhiều khối đã được được sản xuất trên đầu khối với sự thay đổi trạng thái. Vấn đề này có nhiều giải pháp, giải pháp phổ biến nhất là thỉnh thoảng liên kết chéo của khối chuỗi phân đoạn mới nhất với chuỗi báo hiệu. Cái nĩa quy tắc lựa chọn trong chuỗi phân đoạn sau đó được thay đổi để luôn ưu tiên chuỗi đó được liên kết chéo và chỉ áp dụng quy tắc lựa chọn phân nhánh cụ thể cho các khối đã được được xuất bản kể từ liên kết chéo cuối cùng. 1.5.2 Phê duyệt các khối không hợp lệ Một tập hợp validator có thể cố gắng tạo một khối áp dụng chức năng chuyển trạng thái không chính xác. Ví dụ: bắt đầu với trạng thái mà Alice có 10 token và Bob có 0 token, khối có thể chứa giao dịch gửi 10 token từ Alice tới Bob nhưng cuối cùng lại rơi vào trạng thái mà Alice có 0 tokens và Bob có 1000 tokens, như thể hiện trên hình 3. Hình 3: Ví dụ về khối không hợp lệ Trong blockchain cổ điển không phân đoạn, một cuộc tấn công như vậy là không thể, vì tất cả người tham gia mạng xác nhận tất cả các khối và khối có như vậy quá trình chuyển đổi trạng thái không hợp lệ sẽ bị cả hai nhà sản xuất khối khác từ chối và những người tham gia mạng không tạo khối. Cho dù có ác ý validator tiếp tục tạo các khối trên khối không hợp lệ đó nhanh hơn validator trung thực xây dựng chuỗi chính xác, do đó có chuỗi không hợp lệ khối có thể dài hơn, điều đó không thành vấn đề vì mọi người tham gia đang sử dụng blockchain vì bất kỳ mục đích nào sẽ xác thực tất cả các khối và loại bỏ tất cả các khối được xây dựng trên khối không hợp lệ. Trên hình 4 có năm validator, ba trong số đó là độc hại. Họ đã tạo khối A' không hợp lệ và sau đó tiếp tục xây dựng các khối mới ở trên cùng của nó. Hai validator trung thực đã loại bỏ A’ vì không hợp lệ và đang xây dựng trên cùngHình 4: Cố gắng tạo khối không hợp lệ trong blockchain không được phân đoạn của khối hợp lệ cuối cùng mà họ biết, tạo ra một nhánh. Vì có ít hơn validator ở ngã ba trung thực, chuỗi của họ ngắn hơn. Tuy nhiên, trong blockchain cổ điển không được phân chia, mọi người tham gia sử dụng blockchain cho bất kỳ mục đích nào đều được chịu trách nhiệm xác nhận tất cả các khối họ nhận được và tính toán lại trạng thái. Vì vậy, bất kỳ ai có bất kỳ sự quan tâm nào đến blockchain đều sẽ nhận thấy rằng A’ không hợp lệ và do đó cũng loại bỏ ngay B’, C’ và D’, như vậy lấy chuỗi A-B là chuỗi hợp lệ dài nhất hiện tại. Tuy nhiên, trong phân đoạn blockchain, không người tham gia nào có thể xác thực tất cả giao dịch trên tất cả các phân đoạn, vì vậy họ cần có cách nào đó để xác nhận điều đó mà không điểm trong lịch sử của bất kỳ phân đoạn nào của blockchain không có khối không hợp lệ nào được đưa vào. Lưu ý rằng không giống như fork, liên kết chéo với chuỗi Beacon không phải là giải pháp hiệu quả vì chuỗi Beacon không có khả năng xác thực khối. Nó chỉ có thể xác nhận rằng có đủ số validator trong phân đoạn đó đã ký vào khối (và như vậy đã chứng thực tính đúng đắn của nó). Chúng ta sẽ thảo luận các giải pháp cho vấn đề này trong phần 2.2 dưới đây.

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

แนวคิดหลักใน 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], ซึ่งใช้รหัสการลบเพื่อทำให้บล็อกพร้อมใช้งานข้ามเศษแม้ว่าจะมีหลายส่วนก็ตาม ชาร์ดจะสูญเสียข้อมูลไปโดยสิ้นเชิง น่าเสียดายที่ต้องใช้แนวทางเฉพาะของพวกเขา ชิ้นส่วนทั้งหมดเพื่อดาวน์โหลดบล็อกจากชิ้นส่วนอื่น ๆ ทั้งหมดซึ่งเป็นสิ่งต้องห้าม ราคาแพง ความพร้อมใช้งานในระยะยาวไม่ได้เป็นปัญหาเร่งด่วน เนื่องจากไม่มีผู้เข้าร่วม ในระบบคาดว่าจะสามารถตรวจสอบความถูกต้องของลูกโซ่ทั้งหมดได้ทั้งหมด

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

Hiệu lực của trạng thái và tính sẵn có của dữ liệu

Ý tưởng cốt lõi trong sharded blockchains là hầu hết người tham gia đều vận hành hoặc việc sử dụng mạng không thể xác thực các khối trong tất cả các phân đoạn. Như vậy, bất cứ khi nào bất kỳ người tham gia nào cũng cần tương tác với một phân đoạn cụ thể mà họ thường không thể tải xuống và xác thực toàn bộ lịch sử của phân đoạn. Tuy nhiên, khía cạnh phân vùng của sharding làm tăng tiềm năng đáng kể vấn đề: không tải xuống và xác thực toàn bộ lịch sử của một ứng dụng cụ thể phân đoạn, người tham gia không nhất thiết phải chắc chắn rằng trạng thái của nó 5Phần này, ngoại trừ tiểu mục 2.5.3, đã được xuất bản trước đây tại https://near.ai/ mảnh vỡ2. Nếu bạn đã đọc nó trước đó, hãy chuyển sang phần tiếp theo.

chúng tương tác với nhau là kết quả của một chuỗi khối hợp lệ nào đó và chuỗi đó của các khối thực sự là chuỗi chuẩn trong phân đoạn. Một vấn đề không tồn tại trong blockchain không được phân chia. Đầu tiên chúng tôi sẽ trình bày một giải pháp đơn giản cho vấn đề này đã được đề xuất bằng nhiều giao thức và sau đó phân tích xem giải pháp này có thể bị hỏng như thế nào và điều gì đã có những nỗ lực để giải quyết nó. 2.1 Xoay vòng xác thực Giải pháp đơn giản cho tính hợp lệ của trạng thái được thể hiện trên hình 5: giả sử chúng ta giả sử mà toàn bộ hệ thống có khoảng hàng nghìn validator, trong đó không quá 20% là độc hại hoặc sẽ thất bại (chẳng hạn như không thể trực tuyến để tạo ra một khối). Sau đó, nếu chúng ta lấy mẫu 200 validators thì xác suất nhiều hơn 1 3 không đạt trong mục đích thực tế có thể được coi là bằng không. Hình 5: Đang lấy mẫu validators 1 3 là một ngưỡng quan trọng. Có một nhóm các giao thức đồng thuận, được gọi là BFT giao thức đồng thuận, đảm bảo rằng chỉ cần ít hơn 1 3 trong số người tham gia thất bại, do vi phạm hoặc do hành động theo cách nào đó vi phạm giao thức thì sẽ đạt được sự đồng thuận. Với giả định về tỷ lệ phần trăm validator trung thực này, nếu tập hợp hiện tại validator trong một phân đoạn cung cấp cho chúng ta một số khối, giải pháp ngây thơ giả định rằng khối đó hợp lệ và nó được xây dựng dựa trên những gì validator được cho là chuỗi chuẩn cho phân đoạn đó khi họ bắt đầu xác thực. validators đã học chuỗi chuẩn từ tập hợp validator trước đó, cũng bằng cách đó giả định được xây dựng trên khối đứng đầu chuỗi kinh điển trước đó. Bằng quy nạp, toàn bộ chuỗi là hợp lệ và vì không có tập hợp validator nào tại bất kỳ thời điểm nào sản xuất nĩa, giải pháp ngây thơ cũng chắc chắn rằng hiện tại chuỗi là chuỗi duy nhất trong phân đoạn. Xem hình 6 để hình dung.

Hình 6: blockchain với mỗi khối được hoàn tất thông qua sự đồng thuận BFT Giải pháp đơn giản này sẽ không hiệu quả nếu chúng ta giả sử rằng validator có thể bị hỏng một cách thích ứng, đây không phải là một giả định vô lý6. Thích ứng làm hỏng một phân đoạn trong hệ thống có 1000 phân đoạn sẽ rẻ hơn đáng kể hơn là làm hỏng toàn bộ hệ thống. Do đó, tính bảo mật của giao thức giảm tuyến tính theo số lượng phân đoạn. Để có sự chắc chắn về tính hợp lệ của một khối, chúng ta phải biết rằng tại bất kỳ thời điểm nào trong lịch sử không có phân đoạn nào trong hệ thống có phần lớn validator thông đồng; với những đối thủ có khả năng thích ứng, chúng ta không còn có sự chắc chắn như vậy. Như chúng ta đã thảo luận trong phần 1.5, việc thông đồng với validator có thể gây ảnh hưởng hai hành vi độc hại cơ bản: tạo nhánh và tạo các khối không hợp lệ. Các nhánh độc hại có thể được xử lý bằng các khối được liên kết chéo với chuỗi Beacon thường được thiết kế để có độ bảo mật cao hơn đáng kể so với các chuỗi khác. những chuỗi mảnh vỡ. Tuy nhiên, việc tạo ra các khối không hợp lệ là một vấn đề đáng kể hơn. vấn đề đầy thách thức cần giải quyết. 2.2 Hiệu lực của tiểu bang Hãy xem hình 7 trong đó Shard #1 bị hỏng và một tác nhân độc hại tạo ra khối B không hợp lệ. Giả sử trong khối B này 1000 token được đúc từ mỏng phát sóng trên tài khoản của Alice. Sau đó, tác nhân độc hại tạo ra khối C hợp lệ (trong một cảm thấy rằng các giao dịch trong C được áp dụng chính xác) trên B, làm xáo trộn khối B không hợp lệ và bắt đầu giao dịch chéo tới Phân đoạn số 2 chuyển 1000 tokens đó vào tài khoản của Bob. Từ lúc này trở đi không đúng cách đã tạo token nằm trên blockchain hoàn toàn hợp lệ trong Phân đoạn #2. Một số cách tiếp cận đơn giản để giải quyết vấn đề này là: 6Đọc cái này bài viết cho chi tiết trên làm thế nào thích nghi tham nhũng có thể được mang theo ra: https://medium.com/nearprotocol/d859adb464c8. cho hơn thế nữa chi tiết trên thích nghi tham nhũng, đọc https://github.com/ethereum/wiki/wiki/Sharding-FAQ# mô hình bảo mật mà chúng tôi đang vận hành là gìHình 7: Giao dịch chéo từ chuỗi có khối không hợp lệ 1. Dành cho validator của Phân đoạn số 2 để xác thực khối nơi giao dịch được thực hiện được khởi xướng. Điều này sẽ không hoạt động ngay cả trong ví dụ trên, vì khối C dường như hoàn toàn hợp lệ. 2. Dành cho validator trong Phân đoạn số 2 để xác thực một số lượng lớn khối trước khối mà giao dịch được bắt đầu. Đương nhiên, đối với bất kỳ số lượng khối N nào được xác nhận bởi phân đoạn nhận độc hại validators có thể tạo N+1 khối hợp lệ lên trên khối không hợp lệ mà họ được sản xuất. Một ý tưởng đầy hứa hẹn để giải quyết vấn đề này là sắp xếp các mảnh thành một đồ thị vô hướng trong đó mỗi phân đoạn được kết nối với một số phân đoạn khác và chỉ cho phép giao dịch chéo giữa các phân đoạn lân cận (ví dụ: đây là cách Về cơ bản, sharding của Vlad Zamfir hoạt động7 và ý tưởng tương tự được sử dụng trong Kadena Chuỗi mạng [1]). Nếu cần một giao dịch chéo giữa các phân đoạn không phải hàng xóm, giao dịch đó được định tuyến qua nhiều phân đoạn. Trong thiết kế này validator trong mỗi phân đoạn phải xác thực cả hai khối trong phân đoạn của chúng cũng như tất cả các khối trong tất cả các mảnh lân cận. Hãy xem xét một hình dưới đây với 10 phân đoạn, mỗi phân đoạn có bốn phân đoạn lân cận và không có phân đoạn nào yêu cầu nhiều hơn hơn hai bước nhảy cho giao tiếp chéo được hiển thị trên hình 8. Phân đoạn số 2 không chỉ xác thực blockchain của chính nó mà còn blockchain của tất cả những người hàng xóm, bao gồm cả Shard #1. Vì vậy, nếu một tác nhân độc hại trên Shard #1 đang cố gắng tạo khối B không hợp lệ, sau đó xây dựng khối C lên trên khối đó và bắt đầu một giao dịch chéo, giao dịch chéo đó sẽ không diễn ra kể từ khi Phân đoạn số 2 sẽ xác thực toàn bộ lịch sử của Phân đoạn số 1 sẽ khiến nó xác định khối B không hợp lệ. 7Đọc thêm về thiết kế tại đây: https://medium.com/nearprotocol/37e538177ed9

Hình 8: Một giao dịch chéo không hợp lệ trong hệ thống giống như chainweb sẽ bị phát hiện Mặc dù việc làm hỏng một phân đoạn không còn là một cuộc tấn công khả thi nữa, việc làm hỏng một vài mảnh vẫn còn là một vấn đề. Trên hình 9, một đối thủ đang làm hỏng cả Shard

1 và Shard #2 thực hiện thành công giao dịch chéo tới Shard #3

với số tiền từ khối B không hợp lệ: Hình 9: Một giao dịch chéo không hợp lệ trong hệ thống giống như chainweb sẽ không bị phát hiện Phân đoạn số 3 xác thực tất cả các khối trong Phân đoạn số 2, nhưng không có trong Phân đoạn số 1 và không có cách nào để phát hiện khối độc hại. Có hai hướng chính để giải quyết đúng đắn tính hợp lệ của trạng thái:

và bằng chứng mật mã của tính toán. 2.3 ngư dân Ý tưởng đằng sau cách tiếp cận đầu tiên là như sau: bất cứ khi nào một tiêu đề khối được truyền đạt giữa các chuỗi vì bất kỳ mục đích nào (chẳng hạn như liên kết chéo với chuỗi đèn hiệu hoặc giao dịch chéo), có một khoảng thời gian trong mà bất kỳ validator trung thực nào cũng có thể cung cấp bằng chứng cho thấy khối không hợp lệ. Ở đó là những công trình khác nhau cho phép chứng minh rất ngắn gọn rằng các khối không hợp lệ, do đó chi phí liên lạc cho các nút nhận sẽ nhỏ hơn nhiều hơn là nhận được một khối đầy đủ. Với cách tiếp cận này miễn là có ít nhất một validator trung thực trong mảnh vỡ, hệ thống được an toàn. Hình 10: ngư dân Đây là cách tiếp cận chủ đạo (ngoài việc giả vờ như vấn đề không tồn tại) trong số các giao thức được đề xuất hiện nay. Tuy nhiên, cách tiếp cận này có hai nhược điểm lớn: 1. Thời gian thử thách cần phải đủ dài đối với người trung thực validator để nhận biết một khối đã được tạo, tải xuống, xác minh đầy đủ và chuẩn bị thử thách nếu khối không hợp lệ. Giới thiệu một thời kỳ như vậy sẽ làm chậm đáng kể các giao dịch chéo. 2. Sự tồn tại của giao thức thử thách tạo ra một hướng tấn công mới khi các nút độc hại spam với các thách thức không hợp lệ. Một giải pháp rõ ràng của vấn đề này là bắt những người thách đấu gửi một số tiền tokens được trả lại nếu thử thách hợp lệ. Đây chỉ là giải pháp một phần vì nó vẫn có thể có lợi cho kẻ thù gửi thư rác vào hệ thống (và đốt cháy tiền gửi) với những thách thức không hợp lệ, ví dụ để ngăn chặn hợp lệthách thức từ validator trung thực khi vượt qua. Những cuộc tấn công này là được gọi là Cuộc tấn công đau buồn. Xem phần 3.7.2 để biết cách giải quyết điểm sau. 2.4 Lập luận ngắn gọn về kiến thức không tương tác Giải pháp thứ hai cho vấn đề hỏng nhiều phân đoạn là sử dụng một số loại cấu trúc mật mã cho phép người ta chứng minh rằng một tính toán nhất định (chẳng hạn như như việc tính toán một khối từ một tập hợp các giao dịch) đã được thực hiện chính xác. Những công trình như vậy tồn tại, ví dụ: zk-SNARK, zk-STARK và một số loại khác, và một số được sử dụng tích cực trong các giao thức blockchain ngày nay để thanh toán riêng tư, đáng chú ý nhất là ZCash. Vấn đề chính với những thứ nguyên thủy như vậy là chúng nổi tiếng là tính toán chậm. Ví dụ. Giao thức Coda, sử dụng zk-SNARK cụ thể là để chứng minh rằng tất cả các khối trong blockchain đều hợp lệ, được nói trong một trong số các cuộc phỏng vấn rằng có thể mất 30 giây cho mỗi giao dịch để tạo bằng chứng (con số này có lẽ bây giờ đã nhỏ hơn). Điều thú vị là, bằng chứng không cần phải được tính toán bởi một bên đáng tin cậy, vì bằng chứng không chỉ chứng thực tính hợp lệ của tính toán mà nó được xây dựng mà còn giá trị pháp lý của chính bằng chứng. Vì vậy, việc tính toán các chứng minh đó có thể được chia giữa một nhóm người tham gia với mức độ dư thừa ít hơn đáng kể so với cần thiết để thực hiện một số tính toán không tin cậy. Nó cũng cho phép người tham gia những người tính toán zk-SNARK để chạy trên phần cứng đặc biệt mà không làm giảm phi tập trung hóa hệ thống. Những thách thức của zk-SNARK, ngoài hiệu suất, là: 1. Sự phụ thuộc vào các mật mã nguyên thủy ít được nghiên cứu và thử nghiệm ít thời gian hơn; 2. ”Chất thải độc hại” — zk-SNARK phụ thuộc vào thiết lập đáng tin cậy trong đó một nhóm mọi người thực hiện một số tính toán và sau đó loại bỏ kết quả trung gian các giá trị của phép tính đó. Nếu tất cả những người tham gia thủ tục thông đồng và giữ nguyên các giá trị trung gian, có thể tạo ra bằng chứng giả; 3. Độ phức tạp cao hơn được đưa vào thiết kế hệ thống; 4. zk-SNARK chỉ hoạt động đối với một tập hợp con các phép tính có thể, do đó, một giao thức với ngôn ngữ Turing-complete smart contract sẽ không thể sử dụng SNARK để chứng minh tính hợp lệ của chuỗi. 2,5 Tính sẵn có của dữ liệu Vấn đề thứ hai chúng ta sẽ đề cập đến là tính sẵn có của dữ liệu. Nói chung các nút việc vận hành một blockchain cụ thể được tách thành hai nhóm: Nút đầy đủ, những thứ tải xuống mọi khối đầy đủ và xác thực mọi giao dịch và Light Các nút chỉ tải xuống tiêu đề khối và sử dụng bằng chứng Merkle cho các bộ phận của nhà nước và các giao dịch mà họ quan tâm, như thể hiện trên hình 11.

Hình 11: Cây Merkle Bây giờ nếu phần lớn các nút đầy đủ thông đồng với nhau, chúng có thể tạo ra một khối, hợp lệ hoặc không hợp lệ và gửi hash của nó tới các nút ánh sáng nhưng không bao giờ tiết lộ toàn bộ nội dung của khối. Có nhiều cách khác nhau để họ có thể hưởng lợi từ nó. Ví dụ, xét hình 12: Hình 12: Vấn đề về tính sẵn có của dữ liệu Có ba khối: khối trước, A, được tạo bởi validators trung thực; hiện tại, B, có validator thông đồng; và loại tiếp theo, C, cũng sẽ được sản xuất bởi validators trung thực (blockchain được mô tả ở góc dưới cùng bên phải). Bạn là một thương gia. validators của khối hiện tại (B) đã nhận được khối A từ validator trước đó, đã tính toán một khối trong đó bạn nhận được tiền,và gửi cho bạn tiêu đề của khối đó cùng với bằng chứng Merkle về trạng thái bạn có tiền (hoặc bằng chứng Merkle về giao dịch hợp lệ gửi tiền cho bạn). Tin chắc rằng giao dịch đã hoàn tất, bạn cung cấp dịch vụ. Tuy nhiên, validator không bao giờ phân phối toàn bộ nội dung của khối B cho bất cứ ai. Do đó, validator trung thực của khối C không thể truy xuất khối và hoặc bị buộc phải đình trệ hệ thống hoặc xây dựng trên đỉnh A, tước bỏ tư cách của bạn người buôn tiền. Khi chúng tôi áp dụng kịch bản tương tự cho sharding, các định nghĩa về đầy đủ và nút nhẹ thường áp dụng cho mỗi phân đoạn: validators trong mỗi lần tải xuống phân đoạn chặn trong phân đoạn đó và xác thực mọi giao dịch trong phân đoạn đó, nhưng các giao dịch khác các nút trong hệ thống, bao gồm cả các nút có trạng thái chuỗi phân đoạn nhanh vào chuỗi đèn hiệu, chỉ tải xuống các tiêu đề. Do đó, validator trong phân đoạn là các nút đầy đủ hiệu quả cho phân đoạn đó, trong khi những người tham gia khác trong hệ thống, bao gồm chuỗi đèn hiệu, hoạt động như các nút ánh sáng. Để cách tiếp cận của ngư dân mà chúng ta đã thảo luận ở trên có hiệu quả, validators trung thực cần có khả năng tải xuống các khối được liên kết chéo với chuỗi đèn hiệu. Nếu validator độc hại liên kết chéo tiêu đề của một khối không hợp lệ (hoặc sử dụng nó để bắt đầu một giao dịch chéo), nhưng không bao giờ phân phối khối, thì giao dịch trung thực validator không có cách nào để tạo ra thử thách. Chúng tôi sẽ đề cập đến ba cách tiếp cận để giải quyết vấn đề này, bổ sung cho lẫn nhau. 2.5.1 Bằng chứng về quyền nuôi con Vấn đề trước mắt nhất cần giải quyết là liệu một khối có sẵn một lần hay không nó được xuất bản. Một ý tưởng được đề xuất là có cái gọi là Công chứng viên luân phiên giữa các phân đoạn thường xuyên hơn validator có công việc duy nhất là tải xuống chặn và chứng thực rằng họ có thể tải xuống nó. Họ có thể được luân chuyển thường xuyên hơn vì họ không cần tải xuống toàn bộ trạng thái của phân đoạn, không giống như validator không thể xoay thường xuyên vì chúng phải tải xuống trạng thái của phân đoạn mỗi lần chúng xoay, như thể hiện trên hình 13. Vấn đề với cách tiếp cận ngây thơ này là không thể chứng minh sau này cho dù Công chứng viên có thể tải xuống khối hay không, vì vậy Công chứng viên có thể chọn luôn chứng thực rằng họ có thể tải xuống khối mà không cần thậm chí còn cố gắng lấy lại nó. Một giải pháp cho vấn đề này là Công chứng viên cung cấp một số bằng chứng hoặc đặt cược số lượng token chứng thực rằng khối đã được đã tải xuống. Một giải pháp như vậy được thảo luận ở đây: https://ethresear.ch/t/ Trái phiếu lưu ký thân thiện với tập hợp 1 bit/2236. 2.5.2 Mã xóa Khi một nút nhẹ cụ thể nhận được hash của một khối, để tăng sức mạnh của nút đó tin rằng khối đó có sẵn, nó có thể thử tải xuống một vài thông tin ngẫu nhiên các mảnh của khối. Đây không phải là một giải pháp hoàn chỉnh, vì trừ khi các nút ánh sáng tải xuống chung toàn bộ khối mà nhà sản xuất khối độc hại có thể chọn

Hình 13: Trình xác thực cần phải tải xuống trạng thái và do đó không thể xoay được thường xuyên để giữ lại các phần của khối không được tải xuống bởi bất kỳ nút ánh sáng nào, do đó vẫn làm cho khối không có sẵn. Một giải pháp là sử dụng một cấu trúc có tên là Erasure Codes để thực hiện điều đó. để khôi phục toàn bộ khối ngay cả khi chỉ có một phần của khối, như được hiển thị trên hình 14. Hình 14: Merkle tree được xây dựng dựa trên dữ liệu đã mã hóa bị xóa Cả Polkadot và Ethereum Serenity đều có thiết kế xoay quanh ý tưởng này cung cấp một cách để các nút nhẹ có thể tin cậy một cách hợp lý rằng các khối có sẵn. Phương pháp Ethereum Serenity có mô tả chi tiết trong [2].2.5.3 Cách tiếp cận của Polkadot đối với tính khả dụng của dữ liệu Trong Polkadot, giống như trong hầu hết các giải pháp phân đoạn, mỗi phân đoạn (được gọi là parachain) chụp nhanh các khối của nó vào chuỗi báo hiệu (được gọi là chuỗi chuyển tiếp). Giả sử có 2f + 1 validator trên chuỗi chuyển tiếp. Các nhà sản xuất khối của khối parachain, được gọi là đối chiếu, sau khi khối parachain được tạo ra, hãy tính toán một phiên bản mã hóa xóa của khối bao gồm 2f +1 phần sao cho bất kỳ phần f nào cũng đủ để xây dựng lại khối. Sau đó, họ phân phối một phần cho mỗi validator trên chuỗi rơle. Chuỗi chuyển tiếp cụ thể validator sẽ chỉ đăng nhập vào chuỗi chuyển tiếp khối nếu họ có phần của mình cho mỗi khối parachain được chụp nhanh vào khối chuỗi chuyển tiếp như vậy. Do đó, nếu khối chuỗi chuyển tiếp có chữ ký từ 2f + 1 validators và miễn là không quá f trong số chúng vi phạm giao thức, mỗi khối parachain có thể được xây dựng lại bằng cách tìm nạp các phần từ validators tuân theo giao thức. Xem hình 15. Hình 15: Tính khả dụng của dữ liệu Polkadot 2.5.4 Tính sẵn có của dữ liệu dài hạn Lưu ý rằng tất cả các phương pháp được thảo luận ở trên chỉ chứng thực thực tế là một khối đã được xuất bản và hiện có sẵn. Các khối sau này có thể không còn khả dụng vì nhiều lý do: các nút ngoại tuyến, các nút cố tình xóa lịch sử dữ liệu và những thứ khác. Sách trắng đáng được đề cập giải quyết vấn đề này là Polyshard [3], sử dụng mã xóa để cung cấp các khối trên các phân đoạn ngay cả khi một số mảnh vỡ hoàn toàn mất dữ liệu của họ. Thật không may, cách tiếp cận cụ thể của họ đòi hỏi tất cả các phân đoạn để tải xuống các khối từ tất cả các phân đoạn khác, điều này bị cấm đắt tiền. Tính khả dụng lâu dài không phải là vấn đề cấp bách: vì không có người tham gia trong hệ thống dự kiến sẽ có khả năng xác nhận tất cả các chuỗi trong tất cả

phân đoạn, tính bảo mật của giao thức phân đoạn cần phải được thiết kế theo cách cách mà hệ thống được an toàn ngay cả khi một số khối cũ trong một số phân đoạn trở thành hoàn toàn không có sẵn.

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) จากนั้นจึงทำการซิงค์เท่านั้น บล็อกลูกโซ่หลักจากบล็อกสแน็ปช็อตสุดท้าย

Nightshade

3.1 Từ chuỗi mảnh đến mảnh vỡ Mô hình sharding với chuỗi phân đoạn và chuỗi đèn hiệu rất mạnh mẽ nhưng có những phức tạp nhất định. Đặc biệt, quy tắc lựa chọn ngã ba cần được thực thi trong mỗi chuỗi riêng biệt, quy tắc lựa chọn ngã ba trong chuỗi phân đoạn và đèn hiệu chuỗi phải được xây dựng khác nhau và được thử nghiệm riêng biệt. Trong Nightshade, chúng tôi lập mô hình hệ thống dưới dạng một blockchain duy nhất, trong đó mỗi khối chứa tất cả các giao dịch cho tất cả các phân đoạn một cách hợp lý và thay đổi toàn bộ trạng thái của tất cả các mảnh vỡ. Tuy nhiên, về mặt vật lý, không có người tham gia nào tải xuống trạng thái đầy đủ hoặc khối logic đầy đủ. Thay vào đó, mỗi người tham gia mạng chỉ duy trì trạng thái tương ứng với các phân đoạn mà họ xác thực giao dịch và danh sách tất cả các giao dịch trong khối được chia thành các phần vật lý khối, một khối cho mỗi mảnh. Trong điều kiện lý tưởng, mỗi khối chứa chính xác một đoạn trên mỗi phân đoạn. khối, gần tương ứng với mô hình với các chuỗi phân đoạn trong đó chuỗi phân đoạn tạo ra các khối có cùng tốc độ với chuỗi đèn hiệu. Tuy nhiên, do sự chậm trễ của mạng, một số khối có thể bị thiếu, vì vậy trong thực tế mỗi khối chứa một hoặc không khối trên mỗi phân đoạn. Xem phần 3.3 để biết chi tiết về cách khối được sản xuất. Hình 16: Một mô hình có các chuỗi mảnh ở bên trái và có một chuỗi có các khối được chia thành các khối bên phải

3.2 Sự đồng thuận Hai cách tiếp cận chủ yếu để đạt được sự đồng thuận trong blockchain ngày nay là chuỗi dài nhất (hoặc nặng nhất), trong đó chuỗi có nhiều công việc hoặc cổ phần nhất được sử dụng để xây dựng nó được coi là chuẩn và BFT, trong đó đối với mỗi khối một số tập hợp validator đạt được sự đồng thuận BFT. Trong các giao thức được đề xuất gần đây thì cách thứ hai là cách tiếp cận ưu việt hơn, vì nó cung cấp tính hữu hạn ngay lập tức, trong khi ở chuỗi dài nhất cần nhiều khối hơn được xây dựng trên đỉnh của khối để đảm bảo tính cuối cùng. Thường vì một ý nghĩa bảo mật mất thời gian để xây dựng đủ số khối thứ tự giờ. Việc sử dụng sự đồng thuận BFT trên mỗi khối cũng có những nhược điểm, chẳng hạn như: 1. BFT sự đồng thuận đòi hỏi lượng trao đổi đáng kể. Trong khi những tiến bộ gần đây cho phép đạt được sự đồng thuận trong thời gian tuyến tính về số lượng của người tham gia (xem ví dụ: [4]), chi phí này vẫn đáng chú ý trên mỗi khối; 2. Tất cả những người tham gia mạng lưới đều không thể tham gia BFT sự đồng thuận trên mỗi khối, do đó thường chỉ có một tập hợp con người tham gia được lấy mẫu ngẫu nhiên đạt được sự đồng thuận. Về nguyên tắc, một tập hợp được lấy mẫu ngẫu nhiên có thể là về mặt lý thuyết có thể bị hỏng một cách thích ứng và một nhánh phân nhánh có thể được tạo ra. hệ thống hoặc cần phải được lập mô hình để sẵn sàng cho một sự kiện như vậy, và do đó vẫn có quy tắc lựa chọn nhánh bên cạnh sự đồng thuận BFT hoặc được thiết kế để đóng xuống trong một sự kiện như vậy. Điều đáng nói là một số thiết kế như Algorand [5], giảm đáng kể khả năng tham nhũng thích ứng. 3. Quan trọng nhất là hệ thống sẽ ngừng hoạt động nếu 1 3 hoặc nhiều hơn trong số tất cả những người tham gia là ngoại tuyến. Do đó, bất kỳ trục trặc mạng tạm thời hoặc sự chia tách mạng nào cũng có thể khiến hệ thống bị đình trệ hoàn toàn. Lý tưởng nhất là hệ thống phải có khả năng tiếp tục hoạt động miễn là có ít nhất một nửa số người tham gia trực tuyến (nặng nhất các giao thức dựa trên chuỗi tiếp tục hoạt động ngay cả khi có ít hơn một nửa số người tham gia trực tuyến, nhưng mức độ mong muốn của đặc tính này còn gây tranh cãi hơn trong cộng đồng). Một mô hình kết hợp trong đó sự đồng thuận được sử dụng là một trong những mô hình nặng nề nhất chuỗi, nhưng một số khối được hoàn thiện định kỳ bằng cách sử dụng tiện ích cuối cùng BFT duy trì những ưu điểm của cả hai mô hình. BFT tiện ích cuối cùng như vậy là Casper FFG [6] được sử dụng trong Ethereum 2.0 8, Casper CBC (xem https://vitalik. ca/general/2018/12/05/cbc_casper.html) và GRANDPA (xem https:// Medium.com/polkadot-network/d08a24a021b5) được sử dụng trong Polkadot. Nightshade sử dụng sự đồng thuận chuỗi cao nhất. Cụ thể khi một khối nhà sản xuất tạo ra một khối (xem phần 3.3), họ có thể thu thập chữ ký từ các nhà sản xuất khối khác và validator chứng thực khối trước đó. Xem phần 3.8 để biết chi tiết về cách tổng hợp số lượng chữ ký lớn như vậy. trọng lượng 8Ngoài ra, hãy xem phiên bảng trắng với Justin Drake để có cái nhìn tổng quan sâu sắc hơn về Casper FFG và cách nó được tích hợp với sự đồng thuận chuỗi nặng nhất GHOST tại đây: https://www. youtube.com/watch?v=S262StTwkmocủa một khối khi đó là cổ phần tích lũy của tất cả những người ký có chữ ký được đưa vào khối. Trọng lượng của chuỗi là tổng trọng lượng của khối. Để đạt được sự đồng thuận cao nhất trong chuỗi, chúng tôi sử dụng tiện ích cuối cùng sử dụng các chứng thực để hoàn thiện các khối. Để giảm độ phức tạp của hệ thống, chúng tôi sử dụng một tiện ích cuối cùng không ảnh hưởng đến quy tắc lựa chọn ngã ba dưới bất kỳ hình thức nào, và thay vào đó chỉ đưa ra các điều kiện cắt bổ sung, sao cho khi một khối được được hoàn thiện bởi tiện ích cuối cùng, việc phân nhánh là không thể trừ khi có một tỷ lệ phần trăm rất lớn tổng số cổ phần bị cắt giảm. Casper CBC là một tiện ích cuối cùng và chúng tôi hiện đang lưu ý đến mô hình Casper CBC. Chúng tôi cũng làm việc trên một giao thức BFT riêng biệt có tên là TxFlow. Vào thời điểm viết tài liệu này, không rõ liệu TxFlow có được sử dụng thay vì Casper hay không CBC. Tuy nhiên, chúng tôi lưu ý rằng việc lựa chọn tiện ích cuối cùng phần lớn là trực giao với phần còn lại của thiết kế. 3.3 Sản xuất khối Trong Nightshade có hai vai trò: nhà sản xuất khối và validators. Tại bất kỳ điểm hệ thống chứa w nhà sản xuất khối, w = 100 trong mô hình của chúng tôi và wv validators, trong mô hình của chúng tôi v = 100, wv = 10.000. Hệ thống là Bằng chứng cổ phần, có nghĩa là cả nhà sản xuất khối và validator đều có một số quyền nội bộ loại tiền tệ (được gọi là ”tokens”) bị khóa trong một khoảng thời gian vượt xa thời gian họ dành để thực hiện nhiệm vụ xây dựng và xác nhận chuỗi. Giống như tất cả các hệ thống Proof of Stake, không phải tất cả các nhà sản xuất khối w và không tất cả wv validator đều là các thực thể khác nhau vì điều đó không thể thực thi được. Mỗi Tuy nhiên, trong số các nhà sản xuất khối w và wv validators có một sự tách biệt cổ phần. Hệ thống chứa n phân đoạn, n = 1000 trong mô hình của chúng tôi. Như đã đề cập ở phần 3.1, trong Nightshade không có chuỗi phân đoạn, thay vào đó tất cả các nhà sản xuất khối và validator đang xây dựng một blockchain duy nhất mà chúng tôi gọi là chuỗi chính. Trạng thái của chuỗi chính được chia thành n phân đoạn và mỗi khối nhà sản xuất và validator bất kỳ lúc nào cũng chỉ tải xuống cục bộ một tập hợp con của trạng thái tương ứng với một số tập hợp con của phân đoạn và chỉ xử lý và xác thực các giao dịch ảnh hưởng đến các phần đó của trạng thái. Để trở thành nhà sản xuất khối, một người tham gia mạng sẽ khóa một số lượng lớn số lượng tokens (tiền đặt cọc). Việc bảo trì mạng được thực hiện theo thời gian, trong đó một kỷ nguyên là một khoảng thời gian theo thứ tự ngày. Những người tham gia với w cổ phần lớn nhất vào đầu một kỷ nguyên cụ thể là khối nhà sản xuất của thời đại đó. Mỗi nhà sản xuất khối được gán cho các phân đoạn sw, (giả sử sw = 40, điều này sẽ tạo ra sww/n = 4 nhà sản xuất khối trên mỗi phân đoạn). khối nhà sản xuất tải xuống trạng thái của phân đoạn mà họ được chỉ định trước kỷ nguyên bắt đầu và trong suốt thời kỳ đó sẽ thu thập các giao dịch ảnh hưởng đến phân đoạn đó, và áp dụng chúng cho nhà nước. Đối với mỗi khối b trên chuỗi chính và với mỗi phân đoạn, có một trong giao các nhà sản xuất khối cho s, người chịu trách nhiệm sản xuất phần liên quan của b đến mảnh vỡ. Phần của b liên quan đến phân đoạn s được gọi là đoạn và chứa danh sách các giao dịch cho phân đoạn được bao gồm trong b, cũng như merklegốc của trạng thái kết quả. b cuối cùng sẽ chỉ chứa một tiêu đề rất nhỏ của đoạn, cụ thể là gốc merkle của tất cả các giao dịch được áp dụng (xem phần 3.7.1 để biết chi tiết chính xác) và nghiệm merkle của trạng thái cuối cùng. Trong suốt phần còn lại của tài liệu, chúng tôi thường đề cập đến nhà sản xuất khối có trách nhiệm tạo ra một đoạn tại một thời điểm cụ thể cho một phân đoạn cụ thể với tư cách là một nhà sản xuất chunk. Nhà sản xuất chunk luôn là một trong những nhà sản xuất khối. Các nhà sản xuất khối và các nhà sản xuất khối xoay vòng từng khối theo theo một lịch trình cố định. Các nhà sản xuất khối có đơn đặt hàng và liên tục sản xuất khối theo thứ tự đó. Ví dụ. nếu có 100 nhà sản xuất khối thì khối đầu tiên nhà sản xuất chịu trách nhiệm sản xuất khối 1, 101, 201, v.v., khối thứ hai là chịu trách nhiệm sản xuất 2, 102, 202, v.v.). Vì sản xuất theo khối, không giống như sản xuất theo khối, đòi hỏi phải duy trì trạng thái và đối với mỗi phân đoạn, chỉ có nhà sản xuất khối sww/n mới duy trì trạng thái trên mỗi phân đoạn, tương ứng chỉ những nhà sản xuất khối sww/n mới xoay vòng để tạo khối. Ví dụ. với các hằng số ở trên với bốn nhà sản xuất khối được gán cho mỗi phân đoạn, mỗi nhà sản xuất khối sẽ tạo ra các khối cứ bốn khối một lần. 3,4 Đảm bảo tính sẵn có của dữ liệu Để đảm bảo tính khả dụng của dữ liệu, chúng tôi sử dụng phương pháp tương tự như phương pháp của Polkadot được mô tả ở phần 2.5.3. Khi nhà sản xuất khối tạo ra một đoạn, họ sẽ tạo một phiên bản được mã hóa xóa của nó với mã khối tối ưu (w, ⌊w/6 + 1⌋) của khúc. Sau đó, họ gửi một phần của đoạn mã bị xóa (chúng tôi gọi những phần đó là từng phần hoặc chỉ các phần) cho mỗi nhà sản xuất khối. Chúng tôi tính toán một cây merkle chứa tất cả các phần là lá và tiêu đề của mỗi đoạn chứa gốc merkle của cây đó. Các bộ phận được gửi tới validator thông qua tin nhắn một phần. Mỗi tin nhắn như vậy chứa tiêu đề chunk, thứ tự của phần và nội dung phần. các tin nhắn cũng chứa chữ ký của nhà sản xuất khối đã tạo ra chunk và đường dẫn merkle để chứng minh rằng phần đó tương ứng với tiêu đề và được sản xuất bởi nhà sản xuất khối thích hợp. Khi nhà sản xuất khối nhận được khối chuỗi chính, trước tiên họ sẽ kiểm tra xem chúng có có các thông điệp một phần cho mỗi đoạn được bao gồm trong khối. Nếu không, khối không được xử lý cho đến khi các tin nhắn onepart bị thiếu được lấy ra. Sau khi nhận được tất cả các tin nhắn một phần, nhà sản xuất khối sẽ tìm nạp các phần còn lại từ các đồng nghiệp và xây dựng lại các khối mà chúng nắm giữ nhà nước. Nhà sản xuất khối không xử lý khối chuỗi chính nếu có ít nhất một khối đoạn được bao gồm trong khối thì chúng không có thông báo một phần tương ứng hoặc nếu đối với ít nhất một phân đoạn mà chúng duy trì trạng thái thì chúng không thể xây dựng lại toàn bộ đoạn. Để có sẵn một đoạn cụ thể, chỉ cần ⌊w/6⌋+1 của khối là đủ nhà sản xuất có bộ phận của họ và phục vụ họ. Vì vậy, miễn là số lượng tác nhân độc hại không vượt quá ⌊w/3⌋không có chuỗi nào có hơn nửa khối các nhà sản xuất xây dựng nó có thể có những phần không có sẵn.Hình 17: Mỗi khối chứa một hoặc không có khối trên mỗi phân đoạn và mỗi khối được mã hóa xóa. Mỗi phần của đoạn mã xóa được gửi đến một địa chỉ được chỉ định nhà sản xuất khối thông qua tin nhắn onepart đặc biệt 3.4.1 Đối phó với các nhà sản xuất khối lười biếng Nếu nhà sản xuất khối có một khối bị thiếu thông báo một phần, họ sẽ có thể chọn vẫn đăng nhập vào nó, bởi vì nếu khối đó cuối cùng vẫn nằm trong chuỗi sẽ tối đa hóa phần thưởng cho nhà sản xuất khối. Không có rủi ro cho việc chặn nhà sản xuất vì sau này không thể chứng minh rằng nhà sản xuất khối không có tin nhắn một phần. Để giải quyết vấn đề này, chúng tôi tạo ra mỗi nhà sản xuất đoạn khi tạo đoạn để chọn một màu (đỏ hoặc xanh) cho từng phần của đoạn được mã hóa trong tương lai và lưu trữ bitmask của màu được gán trong đoạn trước khi nó được mã hóa. Mỗi phần một sau đó thông báo chứa màu được gán cho phần đó và màu này được sử dụng khi tính toán gốc merkle của các phần được mã hóa. Nếu nhà sản xuất chunk đi chệch hướng từ giao thức, điều đó có thể được chứng minh dễ dàng vì gốc merkle sẽ không tương ứng với tin nhắn một phần hoặc màu sắc trong tin nhắn một phần tương ứng với gốc merkle sẽ không khớp với mặt nạ trong đoạn. Khi nhà sản xuất khối ký vào một khối, họ sẽ bao gồm một bitmask của tất cả phần màu đỏ mà họ nhận được cho các khối có trong khối. Xuất bản một bitmask không chính xác là một hành vi có thể gạch chéo. Nếu nhà sản xuất khối chưa nhận được một tin nhắn, họ không có cách nào biết được màu sắc của tin nhắn, và do đó có 50% khả năng bị chém nếu họ cố gắng mù quáng ký vào bản hợp đồng. khối. 3,5 Ứng dụng chuyển trạng thái Nhà sản xuất khối chỉ chọn những giao dịch nào sẽ được đưa vào khối nhưng không áp dụng chuyển đổi trạng thái khi chúng tạo ra một đoạn. Tương ứng,

tiêu đề chunk chứa gốc merkle của trạng thái merkelized như trước các giao dịch trong chunk được áp dụng. Các giao dịch chỉ được áp dụng khi một khối đầy đủ bao gồm đoạn được xử lý. Một người tham gia chỉ xử lý một khối nếu 1. Khối trước đó đã được nhận và xử lý; 2. Đối với mỗi đoạn, người tham gia không duy trì trạng thái vì họ có đã xem tin nhắn onepart; 3. Đối với mỗi đoạn, người tham gia duy trì trạng thái vì họ có đoạn đầy đủ. Sau khi khối được xử lý, đối với mỗi phân đoạn mà người tham gia duy trì trạng thái, áp dụng các giao dịch và tính toán trạng thái mới kể từ sau khi các giao dịch được áp dụng, sau đó họ đã sẵn sàng sản xuất các khối cho khối tiếp theo, nếu chúng được gán cho bất kỳ phân đoạn nào, vì chúng có gốc merkle của trạng thái merkelized mới. 3.6 Giao dịch và biên lai chéo Nếu một giao dịch cần ảnh hưởng đến nhiều phân đoạn, thì nó cần phải được thực hiện liên tục được thực hiện trong từng phân đoạn riêng biệt. Giao dịch đầy đủ được gửi đến phân đoạn đầu tiên bị ảnh hưởng và khi giao dịch được bao gồm trong khối cho phân đoạn đó và được áp dụng sau khi đoạn được đưa vào một khối, nó tạo ra cái gọi là biên nhận giao dịch, được chuyển đến phân đoạn tiếp theo mà giao dịch cần thực hiện được thực thi. Nếu cần nhiều bước hơn, việc thực hiện giao dịch nhận tạo ra một giao dịch biên nhận mới, v.v. 3.6.1 Thời gian nhận giao dịch Điều mong muốn là giao dịch nhận được áp dụng trong khối ngay sau khối mà nó được tạo. Giao dịch nhận tiền chỉ được tạo sau khi khối trước đó được các nhà sản xuất khối nhận và áp dụng duy trì phân đoạn ban đầu và cần được biết vào thời điểm chunk cho khối tiếp theo được tạo ra bởi nhà sản xuất khối của đích mảnh vỡ. Do đó, biên nhận phải được truyền từ phân đoạn nguồn đến phân đoạn đích trong khung thời gian ngắn giữa hai sự kiện đó. Đặt A là khối được tạo cuối cùng chứa giao dịch t tạo ra biên nhận r. Đặt B là khối được tạo tiếp theo (tức là khối có A là khối trước đó của nó) mà chúng ta muốn chứa r. Đặt t ở trong mảnh a và r là trong mảnh vỡ b. Thời hạn sử dụng của biên nhận, cũng được mô tả trên hình 18, như sau: Lập và lưu trữ hóa đơn. Cpa của nhà sản xuất chunk cho phân đoạn a nhận khối A, áp dụng giao dịch t và tạo biên nhận r. cpa sau đó lưu trữ tất cả các biên lai được tạo ra như vậy trong bộ lưu trữ liên tục nội bộ được lập chỉ mục theo id phân đoạn nguồn.Phân phối các khoản thu. Khi cpa đã sẵn sàng để tạo đoạn cho phân đoạn a cho khối B, họ tìm nạp tất cả các biên lai được tạo bằng cách áp dụng các giao dịch từ khối A cho phân đoạn a và đưa chúng vào đoạn cho phân đoạn a trong khối B. Một khi đoạn như vậy được tạo ra, cpa sẽ tạo ra mã xóa của nó phiên bản và tất cả các thông báo onepart tương ứng. cpa biết nhà sản xuất khối nào duy trì trạng thái đầy đủ cho phân đoạn nào. Đối với một nhà sản xuất khối cụ thể bp cpa bao gồm các khoản thu được từ việc áp dụng các giao dịch trong khối A đối với phân đoạn a có bất kỳ phân đoạn nào mà bp quan tâm làm đích đến của họ trong tin nhắn onepart khi họ phân phối đoạn cho phân đoạn a trong khối B (xem hình 17, hiển thị các biên nhận có trong thông báo một phần). Nhận biên lai. Hãy nhớ rằng những người tham gia (cả nhà sản xuất khối và validator) không xử lý các khối cho đến khi họ có thông báo một phần cho mỗi đoạn có trong khối. Do đó, vào thời điểm bất kỳ người tham gia cụ thể nào áp dụng khối B, họ có tất cả các thông báo một phần tương ứng với các khối trong B và do đó họ có tất cả các biên nhận đến có các phân đoạn người tham gia duy trì trạng thái làm điểm đến của họ. Khi áp dụng các chuyển trạng thái cho một phân đoạn cụ thể, người tham gia sẽ áp dụng cả biên lai mà họ đã thu thập cho phân đoạn trong tin nhắn một phần, cũng như tất cả các giao dịch được bao gồm trong chính đoạn đó. Hình 18: Thời gian tồn tại của một giao dịch biên nhận 3.6.2 Xử lý quá nhiều biên lai Có thể số lượng biên lai nhắm mục tiêu vào một phân đoạn cụ thể trong một khối cụ thể quá lớn để được xử lý. Ví dụ, hãy xem xét hình 19, trong mỗi giao dịch trong mỗi phân đoạn sẽ tạo ra một biên nhận nhắm mục tiêu phân đoạn 1. Ở khối tiếp theo, số biên nhận mà phân đoạn 1 cần xử lý là có thể so sánh với tải mà tất cả các phân đoạn kết hợp được xử lý trong khi xử lý khối trước đó.

Hình 19: Nếu tất cả các khoản thu đều nhắm mục tiêu vào cùng một phân đoạn thì phân đoạn đó có thể không có khả năng xử lý chúng Để giải quyết vấn đề này, chúng tôi sử dụng một kỹ thuật tương tự như kỹ thuật được sử dụng trong QuarkChain 9. Cụ thể, đối với mỗi phân đoạn, khối B cuối cùng và phân đoạn cuối cùng trong đó khối mà biên lai được áp dụng được ghi lại. Khi có phân đoạn mới được tạo, biên nhận được áp dụng theo thứ tự đầu tiên từ các phân đoạn còn lại trong B, và sau đó theo các khối theo B, cho đến khi khối mới đầy. Dưới mức bình thường trường hợp có tải trọng cân bằng nhìn chung sẽ dẫn đến tất cả các khoản thu đang được áp dụng (và do đó phân đoạn cuối cùng của khối cuối cùng sẽ được ghi lại cho từng đoạn), nhưng trong những thời điểm tải không cân bằng và một phần cụ thể phân đoạn nhận được nhiều biên lai không tương xứng, kỹ thuật này cho phép họ được xử lý đồng thời tôn trọng các giới hạn về số lượng giao dịch được đưa vào. Lưu ý rằng nếu tải không cân bằng như vậy tồn tại trong một thời gian dài thì độ trễ từ việc tạo biên lai cho đến khi ứng dụng có thể tiếp tục phát triển vô thời hạn. một cách để giải quyết vấn đề này là loại bỏ bất kỳ giao dịch nào tạo ra biên nhận nhắm mục tiêu phân đoạn có độ trễ xử lý vượt quá một số hằng số (ví dụ: một kỷ nguyên). Hãy xem xét hình 20. Theo khối B, phân đoạn 4 không thể xử lý tất cả các biên nhận, vì vậy nó chỉ xử lý nguồn gốc biên lai từ tối đa phân đoạn 3 trong khối A và ghi lại nó. Trong khối C, bao gồm các khoản thu lên tới phân đoạn 5 trong khối B và sau đó đến khối D, phân đoạn sẽ bắt kịp, xử lý tất cả các khoản thu còn lại trong khối B và tất cả các khoản thu từ khối C. 3,7 Xác thực khối Một đoạn được tạo cho một phân đoạn cụ thể (hoặc một khối phân đoạn được tạo cho một chuỗi phân đoạn cụ thể trong mô hình có chuỗi phân đoạn) chỉ có thể được xác thực bởi 9Xem tập bảng trắng với QuarkChain tại đây: https://www.youtube.com/watch? v=opEtG6NM4x4, trong đó cách tiếp cận các giao dịch chéo được thảo luận, cùng với các vấn đề khác nhiều thứHình 20: Xử lý biên lai bị trì hoãn những người tham gia duy trì trạng thái. Họ có thể là nhà sản xuất khối, validators, hoặc chỉ những nhân chứng bên ngoài đã tải xuống trạng thái và xác thực phân đoạn trong mà họ lưu trữ tài sản. Trong tài liệu này chúng tôi giả định rằng phần lớn những người tham gia không thể lưu trữ trạng thái cho một phần lớn các phân đoạn. Tuy nhiên, điều đáng nói là rằng có blockchain được phân chia được thiết kế với giả định rằng hầu hết người tham gia đều có khả năng lưu trữ trạng thái và xác thực hầu hết các phân đoạn, chẳng hạn như QuarkChain. Vì chỉ một phần nhỏ người tham gia có trạng thái xác thực phân đoạn các khối, có thể thích ứng với tham nhũng chỉ những người tham gia có trạng thái và áp dụng chuyển đổi trạng thái không hợp lệ. Nhiều thiết kế phân đoạn đã được đề xuất lấy mẫu validator cứ sau vài lần ngày và trong vòng một ngày, bất kỳ khối nào trong chuỗi phân đoạn có hơn 2/3 chữ ký của validator được gán cho phân đoạn đó sẽ được xem xét ngay lập tức cuối cùng. Với cách tiếp cận như vậy, đối thủ thích ứng chỉ cần làm hỏng 2n/3+1 của validator trong chuỗi phân đoạn để áp dụng chuyển đổi trạng thái không hợp lệ, trong đó, mặc dù có thể khó thực hiện nhưng mức độ bảo mật không đủ cho công chúng blockchain. Như đã thảo luận trong phần 2.3, cách tiếp cận phổ biến là cho phép một khoảng thời gian nhất định sau khi khối được tạo cho bất kỳ người tham gia nào có trạng thái (cho dù đó là nhà sản xuất khối, validator hoặc người quan sát bên ngoài) để thách thức tính hợp lệ của nó. Những người tham gia như vậy được gọi là Ngư dân. Để một ngư dân có thể thách thức một khối không hợp lệ, phải đảm bảo rằng khối đó có sẵn để họ. Tính khả dụng của dữ liệu trong Nightshade được thảo luận trong phần 3.4. Trong Nightshade khi một khối được tạo ra, các khối không được xác thực bởi bất cứ ai ngoại trừ nhà sản xuất chunk thực sự. Đặc biệt, nhà sản xuất khối đó đề xuất khối tự nhiên không có trạng thái cho hầu hết các phân đoạn vàđã không thể xác nhận các khối. Khi khối tiếp theo được tạo ra, nó chứa các chứng thực (xem phần 3.2) của nhiều nhà sản xuất khối và validators, nhưng vì phần lớn các nhà sản xuất khối và validator không duy trì trạng thái đối với hầu hết các phân đoạn, một khối chỉ có một đoạn không hợp lệ sẽ thu thập được hơn một nửa số chứng thực và sẽ tiếp tục ở trạng thái nặng nhất. chuỗi. Để giải quyết vấn đề này, chúng tôi cho phép bất kỳ người tham gia nào duy trì trạng thái một phân đoạn để gửi thử thách trên chuỗi cho bất kỳ đoạn không hợp lệ nào được tạo ra trong đó mảnh vỡ. 3.7.1 Thử thách tính hợp lệ của trạng thái Khi người tham gia phát hiện thấy một đoạn cụ thể không hợp lệ, họ cần cung cấp bằng chứng cho thấy đoạn đó không hợp lệ. Vì phần lớn những người tham gia mạng không duy trì trạng thái cho phân đoạn có đoạn không hợp lệ được tạo ra, bằng chứng cần phải có đủ thông tin để xác nhận khối đó là không hợp lệ nếu không có trạng thái. Chúng tôi đặt giới hạn Ls về số lượng trạng thái (tính bằng byte) mà một giao dịch đơn lẻ có thể đọc hoặc viết tích lũy. Bất kỳ giao dịch nào chạm nhiều hơn Ls trạng thái được coi là không hợp lệ. Hãy nhớ từ phần 3.5 rằng đoạn trong khối B cụ thể chỉ chứa các giao dịch được áp dụng chứ không chứa gốc trạng thái mới. Gốc trạng thái có trong đoạn trong khối B là trạng thái root trước khi áp dụng các giao dịch đó, nhưng sau khi áp dụng các giao dịch từ đoạn cuối cùng trong cùng phân đoạn trước khối B. Một tác nhân độc hại mong muốn áp dụng chuyển đổi trạng thái không hợp lệ sẽ bao gồm gốc trạng thái không chính xác trong khối B không tương ứng với gốc trạng thái do áp dụng các giao dịch ở đoạn trước. Chúng tôi mở rộng thông tin mà nhà sản xuất chunk đưa vào chunk. Thay vì chỉ thêm trạng thái sau khi áp dụng tất cả các giao dịch, nó thay vào đó bao gồm một gốc trạng thái sau khi áp dụng từng bộ giao dịch liền kề đọc và ghi chung Ls byte trạng thái. Với thông tin này cho Fisherman tạo ra một thách thức rằng việc chuyển đổi trạng thái được áp dụng không chính xác là đủ để tìm ra gốc trạng thái không hợp lệ đầu tiên và chỉ bao gồm Ls byte của trạng thái bị ảnh hưởng bởi các giao dịch giữa trạng thái gốc cuối cùng (được hợp lệ) và trạng thái gốc hiện tại với bằng chứng merkle. Sau đó bất kỳ người tham gia nào có thể xác thực các giao dịch trong phân đoạn và xác nhận rằng đoạn đó là không hợp lệ. Tương tự, nếu nhà sản xuất chunk cố gắng đưa vào các giao dịch đọc và ghi nhiều hơn L byte trạng thái, đối với thử thách này, chỉ cần bao gồm Ls byte đầu tiên mà nó chạm tới với bằng chứng merkle, điều này sẽ đủ để áp dụng các giao dịch và xác nhận rằng sẽ có lúc cố gắng thực hiện đọc hoặc ghi nội dung vượt quá Ls byte được thực hiện.

3.7.2 Ngư dân và giao dịch xuyên mảnh nhanh chóng Như đã thảo luận trong phần 2.3, khi chúng ta giả định rằng các đoạn phân đoạn (hoặc phân đoạn các khối trong mô hình có chuỗi phân đoạn) có thể không hợp lệ và gây ra thách thức theo thời gian, nó ảnh hưởng tiêu cực đến tính cuối cùng và do đó giao tiếp giữa các phân đoạn. trong cụ thể, phân đoạn đích của bất kỳ chuyển đổi chéo nào đều không thể chắc chắn đoạn hoặc khối phân đoạn ban đầu là cuối cùng cho đến khi giai đoạn thử thách kết thúc (xem hình 21). Hình 21: Chờ đợi thời gian thử thách trước khi áp dụng biên nhận Cách giải quyết vấn đề theo cách thực hiện các giao dịch chéo tức thời là để mảnh đích không phải đợi đến giai đoạn thử thách sau khi giao dịch phân đoạn nguồn được xuất bản và áp dụng giao dịch biên nhận ngay lập tức, nhưng sau đó khôi phục phân đoạn đích cùng với phân đoạn nguồn phân đoạn nếu sau đó đoạn hoặc khối ban đầu được phát hiện là không hợp lệ (xem hình 22). Điều này áp dụng rất tự nhiên cho thiết kế Nightshade trong đó mảnh vỡ các chuỗi không độc lập mà thay vào đó, các đoạn phân đoạn đều được xuất bản cùng nhau trong cùng một khối chuỗi chính. Nếu bất kỳ đoạn nào được phát hiện là không hợp lệ, toàn bộ khối có đoạn đó được coi là không hợp lệ và tất cả các khối được xây dựng trên trên hết. Xem hình 23. Cả hai cách tiếp cận trên đều cung cấp tính nguyên tử giả định rằng thách thức thời gian đủ dài. Chúng tôi sử dụng phương pháp thứ hai vì việc cung cấp các giao dịch chéo nhanh trong các trường hợp thông thường sẽ vượt qua sự bất tiện của phân đoạn đích quay trở lại do chuyển đổi trạng thái không hợp lệ ở một trong các các mảnh nguồn, đây là một sự kiện cực kỳ hiếm. 3.7.3 Đang ẩn validators Sự tồn tại của những thách thức đã làm giảm đáng kể khả năng xảy ra tham nhũng thích ứng, vì để hoàn thiện một đoạn có bài chuyển đổi trạng thái không hợp lệHình 22: Áp dụng biên lai ngay lập tức và quay trở lại điểm đến chuỗi nếu chuỗi nguồn có khối không hợp lệ Hình 23: Thử thách làm ngư dân trong Nightshade giai đoạn thử thách mà đối thủ thích ứng cần để làm hỏng tất cả những người tham gia duy trì trạng thái của phân đoạn, bao gồm tất cả validator. Việc ước tính khả năng xảy ra một sự kiện như vậy là vô cùng phức tạp, vì không có sharded blockchain đã tồn tại đủ lâu để thực hiện bất kỳ cuộc tấn công nào như vậy. Chúng tôi lập luận rằng xác suất, mặc dù cực kỳ thấp, nhưng vẫn đủ lớn đối với một hệ thống dự kiến sẽ thực hiện hàng triệu giao dịch và điều hành các hoạt động tài chính trên toàn thế giới. Có hai lý do chính cho niềm tin này: 1. Hầu hết validator của chuỗi Bằng chứng cổ phần và công cụ khai thác của

Chuỗi Proof-of-Work chủ yếu được khuyến khích bởi lợi ích tài chính. Nếu một đối thủ có khả năng thích ứng mang lại cho họ nhiều tiền hơn lợi nhuận kỳ vọng từ việc vận hành một cách trung thực, thật hợp lý khi mong đợi rằng nhiều validators sẽ chấp nhận lời đề nghị. 2. Nhiều tổ chức thực hiện xác thực chuỗi Proof-of-Stake một cách chuyên nghiệp và người ta dự kiến rằng một tỷ lệ lớn cổ phần trong bất kỳ chuỗi nào sẽ được từ các thực thể đó. Số lượng các thực thể như vậy đủ nhỏ để đối thủ thích nghi để tìm hiểu cá nhân hầu hết họ và có một hiểu rõ khuynh hướng của họ là bị tha hóa. Chúng tôi tiến thêm một bước nữa trong việc giảm khả năng xảy ra lỗi thích ứng bằng cách ẩn validator được gán cho phân đoạn nào. Ý tưởng là tương tự như cách Algorand [5] che giấu validators. Điều quan trọng cần lưu ý là ngay cả khi validator bị ẩn, như trong Algorand hoặc như được mô tả dưới đây, về mặt lý thuyết, tham nhũng thích ứng vẫn có thể xảy ra. Trong khi đối thủ thích ứng không biết những người tham gia sẽ tạo hoặc xác thực một khối hay một đoạn, bản thân những người tham gia đều biết rằng họ sẽ thực hiện một nhiệm vụ như vậy và có bằng chứng mật mã về nó. Vì vậy, đối thủ có thể truyền bá ý định tham nhũng của họ và trả tiền cho bất kỳ người tham gia nào sẽ cung cấp một bằng chứng mật mã như vậy. Tuy nhiên, chúng tôi lưu ý rằng vì đối thủ không biết validator được gán cho phân đoạn mà chúng muốn làm hỏng, chúng không có lựa chọn nào khác ngoài việc truyền bá ý định làm hỏng một phân đoạn cụ thể tới toàn bộ cộng đồng. Vào thời điểm đó, nó mang lại lợi ích kinh tế cho bất kỳ người trung thực nào. người tham gia tạo ra một nút đầy đủ để xác thực phân đoạn đó vì có mức cao khả năng một khối không hợp lệ xuất hiện trong phân đoạn đó, đây là cơ hội để tạo ra một thử thách và thu thập phần thưởng liên quan. Để không tiết lộ validator được gán cho một phân đoạn cụ thể, chúng tôi thực hiện sau đây (xem hình 24): Sử dụng VRF để nhận nhiệm vụ. Vào đầu mỗi thời đại, mỗi validator sử dụng VRF để lấy mặt nạ bit của các phân đoạn mà validator được gán cho. Mặt nạ bit của mỗi validator sẽ có các bit Sw (xem phần 3.3 để biết định nghĩa của Sw). validator sau đó tìm nạp trạng thái của các phân đoạn tương ứng và trong kỷ nguyên cho mỗi khối nhận được sẽ xác thực các khối tương ứng vào các phân đoạn mà validator được gán cho. Đăng nhập vào khối thay vì khối. Vì việc gán phân đoạn bị ẩn nên validator không thể đăng nhập vào các phân đoạn. Thay vào đó nó luôn ký trên toàn bộ chặn, do đó không tiết lộ những phân đoạn mà nó xác nhận. Cụ thể, khi validator nhận được một khối và xác thực tất cả các khối, nó sẽ tạo ra một thông báo chứng thực rằng tất cả các đoạn trong tất cả các phân đoạn mà validator được chỉ định là hợp lệ (không cho biết những phân đoạn đó là gì) hoặc một thông báo rằng chứa bằng chứng về việc chuyển đổi trạng thái không hợp lệ nếu bất kỳ đoạn nào không hợp lệ. Xem phần 3.8 để biết chi tiết về cách tổng hợp các thông báo đó, phần 3.7.4 để biết chi tiết về cách ngăn chặn validator lợi dụng tin nhắn từ validators khác và phần 3.7.5 để biết chi tiết về cách khen thưởng và trừng phạt validators nếu thử thách chuyển đổi trạng thái không hợp lệ thành công thực sự xảy ra.Hình 24: Che giấu validator trong Nightshade 3.7.4 Cam kết-Tiết lộ Một trong những vấn đề phổ biến với validator là validator có thể bỏ qua việc tải xuống trạng thái và thực sự xác thực các khối và khối, thay vào đó quan sát mạng, xem những gì validator khác gửi và lặp lại tin nhắn. validator tuân theo chiến lược như vậy sẽ không cung cấp thêm bất kỳ bảo mật cho mạng nhưng thu thập phần thưởng. Một giải pháp phổ biến cho vấn đề này là mỗi validator cung cấp bằng chứng rằng họ thực sự đã xác thực khối đó, chẳng hạn như bằng cách cung cấp dấu vết duy nhất áp dụng chuyển đổi trạng thái, nhưng những bằng chứng như vậy làm tăng đáng kể chi phí xác nhận. Hình 25: Cam kết tiết lộ

Thay vào đó, chúng tôi thực hiện cam kết đầu tiên của validator với kết quả xác thực (hoặc thông báo chứng thực tính hợp lệ của các khối hoặc bằng chứng về tính hợp lệ của chuyển trạng thái), đợi một khoảng thời gian nhất định và chỉ sau đó mới tiết lộ kết quả xác thực thực tế, như được hiển thị trên hình 25. Khoảng thời gian cam kết không giao nhau với khoảng thời gian tiết lộ và do đó một validator lười biếng không thể bắt chước những validator trung thực. Hơn nữa, nếu một validator không trung thực cam kết thực hiện một thông báo chứng thực tính hợp lệ của các đoạn được gán và ít nhất một đoạn không hợp lệ một khi nó được đã chỉ ra rằng đoạn đó không hợp lệ nên validator không thể tránh được việc gạch chéo, vì, như chúng tôi trình bày trong phần 3.7.5, cách duy nhất để không bị chém trong tình huống như vậy là đưa ra một thông báo chứa bằng chứng về việc chuyển đổi trạng thái không hợp lệ phù hợp với cam kết. 3.7.5 Xử lý thử thách Như đã thảo luận ở trên, khi validator nhận được một khối có đoạn không hợp lệ, đầu tiên họ chuẩn bị bằng chứng về sự chuyển đổi trạng thái không hợp lệ (xem phần 3.7.1), sau đó cam kết với một bằng chứng như vậy (xem 3.7.4), và sau một thời gian hãy tiết lộ thách thức. Khi thử thách được tiết lộ được đưa vào một khối, điều sau đây sẽ xảy ra: 1. Tất cả các chuyển đổi trạng thái xảy ra từ khối chứa đoạn không hợp lệ cho đến khi khối chứa thử thách được tiết lộ bị vô hiệu hóa. Trạng thái trước khối bao gồm thử thách được tiết lộ được coi là giống với trạng thái trước khối chứa đoạn không hợp lệ. 2. Trong một khoảng thời gian nhất định, mỗi validator phải tiết lộ mặt nạ bit của mình của các phân đoạn mà họ xác nhận. Vì mặt nạ bit được tạo thông qua VRF, nếu họ được gán cho phân đoạn có quá trình chuyển đổi trạng thái không hợp lệ, họ không thể tránh khỏi việc tiết lộ nó. Bất kỳ validator nào không tiết lộ được mặt nạ bit được cho là được gán cho phân đoạn. 3. Mỗi validator sau khoảng thời gian đó được phát hiện sẽ được gán cho phân đoạn, đã cam kết với một số kết quả xác thực cho khối chứa đoạn không hợp lệ và điều đó không tiết lộ bằng chứng về việc chuyển đổi trạng thái không hợp lệ tương ứng với cam kết của họ bị cắt giảm. 4. Mỗi validator nhận được một phân đoạn mới và một kỷ nguyên mới được lên lịch bắt đầu sau một khoảng thời gian đủ để tất cả validator tải xuống trạng thái, như thể hiện trên hình 26. Lưu ý rằng kể từ thời điểm validator tiết lộ các phân đoạn mà chúng được chỉ định cho đến khi kỷ nguyên mới bắt đầu, tính bảo mật của hệ thống sẽ bị giảm do phân công mảnh vỡ được tiết lộ. Những người tham gia mạng cần phải giữ nó lưu ý khi sử dụng mạng trong thời gian đó. 3,8 Tổng hợp chữ ký Để một hệ thống có hàng trăm phân đoạn hoạt động an toàn, chúng tôi muốn có trên đơn hàng từ 10.000 trở lên validators. Như đã thảo luận trong phần 3.7, chúng tôi muốn mỗiHình 26: Xử lý thử thách validator để xuất bản một cam kết cho một tin nhắn nhất định và một chữ ký ở mức trung bình một lần cho mỗi khối. Ngay cả khi các thông điệp cam kết giống nhau, việc tổng hợp như vậy Chữ ký BLS và việc xác nhận nó sẽ rất tốn kém. Nhưng đương nhiên các thông báo cam kết và tiết lộ không giống nhau trên validators, và do đó chúng ta cần một số cách để tổng hợp các thông điệp và chữ ký đó trong một cách cho phép xác nhận nhanh chóng sau này. Cách tiếp cận cụ thể mà chúng tôi sử dụng như sau: Người xác nhận tham gia các nhà sản xuất khối. Các nhà sản xuất khối được biết đến một thời gian trước khi kỷ nguyên bắt đầu, vì họ cần một chút thời gian để tải xuống trạng thái trước khi kỷ nguyên bắt đầu và không giống như validator, các nhà sản xuất khối không che giấu. Mỗi nhà sản xuất khối có v validator vị trí. Trình xác nhận gửi đề xuất ngoài chuỗi cho các nhà sản xuất khối để được đưa vào như một trong những v validators. Nếu nhà sản xuất khối muốn bao gồm validator, họ sẽ gửi giao dịch chứa yêu cầu ngoài chuỗi ban đầu từ validator và chữ ký của nhà sản xuất khối khiến validator tham gia nhà sản xuất khối. Lưu ý rằng validator được gán cho nhà sản xuất khối không nhất thiết xác thực các phân đoạn tương tự mà nhà sản xuất khối tạo ra các khối. Nếu một validator áp dụng để tham gia nhiều nhà sản xuất khối, chỉ giao dịch từ nhà sản xuất khối đầu tiên sẽ thành công. Các nhà sản xuất khối thu thập các cam kết. Nhà sản xuất khối liên tục thu thập các thông báo cam kết và tiết lộ từ validator. Khi một số lượng tin nhắn như vậy nhất định được tích lũy, nhà sản xuất khối sẽ tính toán một merkle cây của những tin nhắn này và gửi tới mỗi validator gốc merkle và đường dẫn merkle đến tin nhắn của họ. validator xác thực đường dẫn và đăng nhập rễ merkle. Sau đó, nhà sản xuất khối sẽ tích lũy chữ ký BLS trên gốc merkle từ validators và chỉ xuất bản gốc merkle và chữ ký tích lũy Nhà sản xuất khối cũng ký vào tính hợp lệ của đa chữ ký bằng cách sử dụng chữ ký ECDSA giá rẻ. Nếu đa chữ ký không khớp với gốc merkle được gửi hoặc bitmask của validator tham gia, đó là hành vi có thể cắt được. Khi đồng bộ hóa chuỗi, người tham gia có thể chọn xác thực tất cả chữ ký BLS từ các validator (việc này cực kỳ tốn kém vì nó liên quan đến việc tổng hợp các khóa công khai của validator) hoặc chỉchữ ký ECDMA từ các nhà sản xuất khối và dựa vào thực tế là nhà sản xuất khối không bị thách thức và bị chém. Sử dụng các giao dịch trên chuỗi và bằng chứng merkle để giải quyết các thách thức. Nó có thể lưu ý rằng việc tiết lộ tin nhắn từ validator sẽ không có giá trị gì nếu không chuyển đổi trạng thái không hợp lệ đã được phát hiện. Chỉ những tin nhắn có chứa thông tin thực tế bằng chứng về việc chuyển đổi trạng thái không hợp lệ cần phải được tiết lộ và chỉ dành cho những tin nhắn như vậy nó cần phải được chứng minh rằng chúng phù hợp với cam kết trước đó. Thông điệp cần phải được tiết lộ nhằm hai mục đích: 1. Để thực sự bắt đầu quá trình khôi phục chuỗi về thời điểm trước khi thực hiện chuyển trạng thái không hợp lệ (xem phần 3.7.5). 2. Để chứng minh rằng validator không cố gắng chứng thực tính hợp lệ của đoạn không hợp lệ. Trong cả hai trường hợp, chúng ta cần giải quyết hai vấn đề: 1. Cam kết thực tế không được đưa vào chuỗi, chỉ có gốc merkle của cam kết tổng hợp với các tin nhắn khác. validator cần sử dụng đường dẫn merkle do nhà sản xuất khối cung cấp và cam kết ban đầu của họ đối với chứng minh rằng họ đã cam kết với thử thách. 2. Có thể tất cả validator được gán cho phân đoạn có giá trị không hợp lệ quá trình chuyển đổi trạng thái xảy ra được gán cho các nhà sản xuất khối bị hỏng đang kiểm duyệt chúng. Để giải quyết vấn đề này, chúng tôi cho phép họ gửi tiết lộ của mình như một giao dịch thông thường trên chuỗi và bỏ qua việc tổng hợp. Cái sau chỉ được phép đối với các bằng chứng về sự chuyển đổi trạng thái không hợp lệ, đó là cực kỳ hiếm và do đó sẽ không dẫn đến việc gửi thư rác vào các khối. Vấn đề cuối cùng cần được giải quyết là các nhà sản xuất khối có thể chọn không tham gia vào việc tổng hợp tin nhắn hoặc cố tình kiểm duyệt validators cụ thể. Chúng tôi làm cho nó trở nên bất lợi về mặt kinh tế bằng cách tạo ra khối phần thưởng của nhà sản xuất tỷ lệ thuận với số validator được chỉ định cho họ. Chúng tôi cũng lưu ý rằng vì các nhà sản xuất khối giữa các kỷ nguyên phần lớn giao nhau (vì luôn là những người tham gia có số tiền đặt cược cao nhất), validator có thể phần lớn tập trung vào làm việc với cùng một nhà sản xuất khối và do đó giảm thiểu rủi ro về việc được giao cho một nhà sản xuất khối đã kiểm duyệt chúng trong quá khứ. 3,9 Chuỗi ảnh chụp nhanh Vì các khối trên chuỗi chính được sản xuất rất thường xuyên nên việc tải xuống toàn bộ lịch sử có thể trở nên đắt đỏ rất nhanh. Hơn nữa, vì mỗi khối chứa chữ ký BLS của một số lượng lớn người tham gia, chỉ cần tổng hợp các khóa công khai để kiểm tra chữ ký có thể trở nên quá khó khăn. đắt tiền là tốt. Cuối cùng, vì trong bất kỳ tương lai gần nào Ethereum 1.0 có thể sẽ vẫn là một trong số blockchain được sử dụng nhiều nhất, có một cách hiệu quả để chuyển nội dung từ

Gần Ethereum là một yêu cầu và hôm nay việc xác minh chữ ký BLS để đảm bảo Không thể có hiệu lực ở các khối gần về phía Ethereum. Mỗi khối trong chuỗi chính Nightshade có thể tùy ý chứa Schnorr đa chữ ký trên tiêu đề của khối cuối cùng bao gồm Schnorr đa chữ ký. Chúng tôi gọi những khối như vậy là khối chụp nhanh. Khối đầu tiên của mỗi kỷ nguyên phải là một khối ảnh chụp nhanh. Trong khi làm việc trên một hệ thống đa chữ ký như vậy, nhà sản xuất khối cũng phải tích lũy chữ ký BLS của validators trên khối ảnh chụp nhanh cuối cùng và tổng hợp chúng theo cách tương tự như được mô tả trong phần 3.8. Vì bộ sản xuất khối không đổi trong suốt kỷ nguyên, nên việc xác thực chỉ các khối ảnh chụp nhanh đầu tiên trong mỗi kỷ nguyên là đủ với giả định rằng không có chỉ ra một tỷ lệ lớn các nhà sản xuất khối và validator đã thông đồng và tạo ra một cái nĩa. Khối đầu tiên của kỷ nguyên phải chứa thông tin đủ để tính toán nhà sản xuất khối và validator cho kỷ nguyên. Chúng tôi gọi chuỗi con của chuỗi chính chỉ chứa ảnh chụp nhanh chặn một chuỗi ảnh chụp nhanh. Tạo đa chữ ký Schnorr là một quá trình tương tác, nhưng vì chúng ta chỉ cần thực hiện nó không thường xuyên, bất kỳ quy trình nào, dù kém hiệu quả đến đâu sẽ đủ. Có thể dễ dàng xác thực đa chữ ký Schnorr trên Ethereum, do đó cung cấp các nguyên hàm quan trọng để thực hiện một cách an toàn chéo-blockchain giao tiếp. Để đồng bộ với chuỗi Gần, người ta chỉ cần tải xuống tất cả ảnh chụp nhanh chặn và xác nhận rằng chữ ký Schnorr là chính xác (tùy chọn cũng xác minh chữ ký BLS riêng lẻ của validators), sau đó chỉ đồng bộ hóa khối chuỗi chính từ khối ảnh chụp nhanh cuối cùng.

บทสรุป

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

Phần kết luận

Trong tài liệu này, chúng tôi đã thảo luận các phương pháp tiếp cận để xây dựng blockchain phân đoạn và đã giải quyết được hai thách thức lớn với các phương pháp tiếp cận hiện có, đó là tính hợp lệ của trạng thái và tính sẵn có của dữ liệu. Sau đó chúng tôi đã giới thiệu Nightshade, một thiết kế sharding quyền hạn NEAR Giao thức. Thiết kế đang được tiến hành, nếu bạn có ý kiến, câu hỏi hoặc phản hồi trên tài liệu này, vui lòng truy cập https://near.chat.