"Ethereum 2.0 Fragmentation Design" ที่ทุกคนสามารถเข้าใจได้
หมายเหตุบรรณาธิการ: บทความนี้มาจากค่าห่วงโซ่คาร์บอน (ID: ค่าซีซี)หมายเหตุบรรณาธิการ: บทความนี้มาจาก
ค่าห่วงโซ่คาร์บอน (ID: ค่าซีซี)
ค่าห่วงโซ่คาร์บอน (ID: ค่าซีซี)
เวลาเราซื้ออาหารเช้าที่ 7-11 ถ้ามีแคชเชียร์คนเดียวก็ต้องรอคิวยาว ถ้าแคชเชียร์ 2 คน จะเพิ่มเป็น 2 เท่าทันที ถ้ามีแคชเชียร์ 4 คน อาจจะไม่มีก็ได้ ต้องต่อคิว นี่เป็นตรรกะพื้นฐานของการแบ่งส่วน ซึ่งจะกระจายงานของบุคคลหนึ่งไปยังหลาย ๆ คนเพื่อปรับปรุงประสิทธิภาพ
จากมุมมองของบัญชีแยกประเภทแบบกระจายของ Ethereum: ก่อนการชาร์ด มีเพียงบัญชีแยกประเภทของห่วงโซ่หลักเท่านั้นที่สามารถประมวลผลได้ประมาณ 12 ถึง 45 ธุรกรรมต่อวินาที เมื่อปริมาณธุรกรรมมากกว่าข้อมูลนี้ มันจำเป็นต้องเข้าคิว ขึ้น กล่าวคือ เครือข่ายจะแออัด Sharding คือการเปลี่ยนบัญชีแยกประเภทหนึ่งบัญชีเป็น 64 บัญชีแยกประเภทและให้พวกเขาดำเนินการธุรกรรมในเวลาเดียวกันซึ่งเทียบเท่ากับการเปิดเครื่องบันทึกเงินสด 64 เครื่องที่ 7-11 เพื่อรวบรวมเงินสด
ตรรกะของการแบ่งส่วนนั้นง่าย แต่ทำไมมันจึงยากต่อการนำไปใช้ เนื่องจากการแบ่งบัญชีแยกประเภทเป็น 64 บัญชีแยกประเภทจะเผชิญกับปัญหาใหม่ๆ มากมาย สิ่งที่เทคโนโลยีการแบ่งกลุ่มต้องทำคือแก้ปัญหาดังกล่าว บทความนี้จะเริ่มต้นจากคำถามเหล่านี้เพื่อค้นหาว่า Sharding ของ Ethereum 2.0 นั้นเกี่ยวกับอะไร
ชื่อเรื่องรอง
วิธีการแยกส่วน
1. กำหนดธุรกรรมให้กับเศษ
ชาร์ดประกอบด้วยธุรกรรมและตัวตรวจสอบที่รวมธุรกรรมเป็นบล็อก ขั้นตอนแรก ในการทำชาร์ดให้เสร็จสมบูรณ์คือการกำหนดวิธีกำหนดธุรกรรมและตัวตรวจสอบความถูกต้องให้กับชาร์ด มาดูธุรกรรมการจัดสรรกันก่อน
ขอให้เราใช้เรื่องราวของสามหมู่บ้านเพื่อทำความเข้าใจ: มีหมู่บ้านชาวประมง, หมู่บ้านนักล่า, และหมู่บ้านชาวนา มักจะมีการทำธุรกรรมภายในและระหว่างหมู่บ้าน แต่ไม่มีสกุลเงิน และทุกคนก็เก็บบัญชีไว้ เมื่อก่อนสมุดบัญชี 1 เล่มใช้เก็บบัญชีของ 3 หมู่บ้าน ซึ่งค่อนข้างช้าหน่อย แต่ตอนนี้เปลี่ยนเป็น 3 สมุดบัญชี แล้วสมุดบัญชีเล่มไหนใช้เก็บบัญชีไหน?
วิธีหนึ่งคือใส่บัญชีแยกประเภท 3 บัญชีไว้ที่นั่น และหลังจากธุรกรรมมา จะบันทึกบัญชีแยกประเภทใดหากไม่มีคิวอยู่ข้างหน้า แต่จะเกิดปัญหาว่าบัญชีแยกประเภทแต่ละบัญชีต้องมีข้อมูลเจ้าของบัญชี มิฉะนั้น ฉันจะมาหาคุณเพื่อเข้าคิว แต่คุณไม่มีบัญชีของฉัน
ด้วยเหตุนี้ หนึ่งในปัญหาหลักของวิธีการแบ่งส่วนนี้คือไม่สามารถลดปริมาณข้อมูลที่จัดเก็บไว้ในบัญชีแยกประเภทเดียวได้ และข้อกำหนดในการจัดเก็บข้อมูลนี้เป็นเกณฑ์ที่สูงสำหรับโหนดที่ต้องการมีส่วนร่วมในการทำบัญชี วิธีการนี้ยังจำเป็นต้อง แก้ปัญหาการใช้จ่ายซ้ำซ้อน เพราะคน ๆ หนึ่งสามารถใช้จ่ายเงินก้อนเดียวกันในเศษต่าง ๆ ได้ในเวลาเดียวกัน
อีกวิธีหนึ่งคือหมู่บ้านชาวประมงมีบัญชีแยกประเภท 1 บัญชี หมู่บ้าน Orion มีบัญชีแยกประเภท 1 บัญชี และหมู่บ้านเกษตรกรมีบัญชีแยกประเภท 1 บัญชี บัญชีแยกประเภทจะมีเฉพาะข้อมูลบัญชีของหมู่บ้านของตนเองและบันทึกธุรกรรมภายในหมู่บ้านของตนเองเท่านั้น ด้วยวิธีนี้ บัญชีแยกประเภทสามบัญชีสามารถจัดเก็บได้ในเวลาเดียวกัน โดยมีประสิทธิภาพการทำบัญชีสูงและความต้องการในการจัดเก็บน้อยลง นี่คือวิธีการชาร์ดดิ้งที่ Ethereum นำมาใช้: การแบ่งสถานะ, ชาร์ดแต่ละอันจัดเก็บและจัดเก็บเฉพาะสถานะบัญชีที่เป็นของชาร์ดของตัวเอง ในแง่ของการใช้งาน ผู้ใช้ Ethereum เลือกว่าจะเข้าร่วมกลุ่มใด แทนที่จะเข้าร่วมกลุ่มย่อยตามหมู่บ้านตามธรรมชาติ
ปัญหาใหญ่ที่สุดของการแบ่งรัฐคือ ถ้าคนในหมู่บ้านชาวประมงต้องการค้าขายกับคนในหมู่บ้าน Orion ล่ะ? ไม่มีบัญชีของชาวบ้าน Orion ในบัญชีแยกประเภทของหมู่บ้านชาวประมง และไม่มีบัญชีของชาวประมงในบัญชีแยกประเภทของหมู่บ้าน Orion อันที่จริงแล้ว นี่เป็นการทดสอบครั้งใหญ่ที่สุดที่ต้องเผชิญกับเทคโนโลยีชาร์ดดิ้ง การสื่อสารข้ามชาร์ด เมื่อปัญหานี้ได้รับการแก้ไขอย่างสมบูรณ์ จะสามารถใช้ Ethereum 2.0 ได้ บทความนี้จะกล่าวถึงวิธีแก้ไขปัญหานี้ในส่วนที่สอง
2. กำหนดตัวตรวจสอบความถูกต้องให้กับเศษ
หลังจากจัดการธุรกรรมไปยังส่วนย่อยต่างๆ แล้ว ปัญหาต่อไปที่ต้องแก้ไขคือวิธีกำหนดผู้ทำบัญชีให้กับส่วนย่อย นั่นคือ กำหนดผู้ตรวจสอบ
มี 64 shards ใน Ethereum และแต่ละ shard มีผู้ตรวจสอบ 128 คน หากผู้ตรวจสอบ shards ได้รับการแก้ไขหรือคาดเดาได้ ผู้โจมตีจะควบคุม shards นั่นคือการซื้อ 2/3 ของ 128 เป็นเรื่องง่ายที่จะทำ ? วิธีแก้ไขของ Ethereum คือการสุ่มเลือกตัวตรวจสอบสำหรับชิ้นส่วนจากตัวตรวจสอบความถูกต้องทั้งหมด และเปลี่ยนตัวตรวจสอบทุก ๆ 6.4 นาที (ความยาวของหนึ่งยุค) ด้วยวิธีนี้ ผู้โจมตีมีโอกาสน้อยกว่าหนึ่งในล้านล้านที่จะควบคุมคน 2/3 ในเศษเสี้ยว (ดูเหตุผลอ้างอิง 1)
หนึ่งในภารกิจหลักของ beacon chain คือการกำหนดผู้ตรวจสอบให้กับ shard chains และสิ่งที่สำคัญที่สุดในงานนี้คือการทำให้เป็นจริงของการสุ่ม ประการแรกคือความสำคัญของการสุ่ม หากไม่สามารถกำหนดผู้ตรวจสอบความถูกต้องได้ จะไม่สามารถรับประกันความปลอดภัยของบัญชีแยกประเภท ประการที่สองคือความยากของการสุ่ม เป็นการยากมากที่จะบรรลุการสุ่มบนบล็อกเชน ถือได้ว่าจนถึงตอนนี้ ไม่มีอัลกอริทึมสุ่มที่ได้รับการพิสูจน์แล้วซึ่งสามารถเรียกได้ว่าเป็นการใช้งานทางวิศวกรรม
วิธีการแก้ปัญหาของ Ethereum คือการใช้ RANDAO+VDF เพื่อให้ตัวเลขสุ่มเพื่อให้ได้มาซึ่งการสุ่ม ง่ายต่อการเข้าใจโดยการแยก RANDAO ออกเป็น RAN (สุ่ม) และ DAO หมายความว่าแต่ละคนในกลุ่มเสนอหมายเลขสุ่มอย่างอิสระจากนั้นจึงรวมหมายเลขสุ่มของทุกคนเพื่อสร้างหมายเลขสุ่มล่าสุดที่ใช้ เนื่องจากเป็นการยากที่ใครจะรู้ตัวเลขที่ผู้อื่นให้มา จึงเป็นการยากที่จะคาดเดาตัวเลขสุดท้ายที่จะนำมารวมกัน
อย่างไรก็ตาม โมเดล RANDAO มีข้อบกพร่อง กล่าวคือ ผู้ที่ให้หมายเลขสุดท้ายมีโอกาสโกงได้ เขารู้ผลรวมของหมายเลขสุ่มที่บุคคลก่อนหน้าให้มาทั้งหมด และสามารถปรับหมายเลขที่ให้ด้วยตนเองได้ เพื่อให้ผลสุดท้ายเกิดประโยชน์แก่ตน
เพื่อแก้ปัญหานี้ Ethereum ได้เปิดตัว VDF (Verifiable Delay Function) การทำงานของมันง่ายมาก คือการป้องกันไม่ให้คนสุดท้ายที่ให้หมายเลขสุ่มคำนวณผลรวมของจำนวนสุ่มของคนก่อนหน้าทั้งหมดก่อนที่จะระบุหมายเลขเอง ดังนั้นจึงไม่มีวิธีจัดการกับตัวเลขสุ่ม (สำหรับคำแนะนำโดยละเอียดของ RANDAO+VDF โปรดดูข้อมูลอ้างอิง 2)
3. เศษชิ้นส่วนถูกจัดเก็บโดยรีเลย์
ฉันไม่รู้ว่าคุณสังเกตเห็นหรือไม่ว่าผู้ตรวจสอบบัญชีแยกประเภทแบบหมุนเวียนจะทำให้เกิดปัญหาใหม่: ผู้ตรวจสอบจะถูกมอบหมายให้กับหมู่บ้านชาวประมงเพื่อเก็บบัญชีไว้ระยะหนึ่ง และจะมอบหมายให้หมู่บ้าน Orion ชั่วขณะหนึ่ง หากเขาไม่มีข้อมูลบัญชีทั้งหมดอยู่ในมือจะรักษาบัญชีได้อย่างไร บัญชี? หากเขามีข้อมูลบัญชีทั้งหมด เขาก็จะถือบัญชีแยกประเภทแบบเต็มอีกครั้งโดยไม่มีการแบ่งสถานะ
เพื่อแก้ปัญหานี้ Ethereum ได้เสนอการออกแบบใหม่ที่สำคัญ: ไคลเอนต์ไร้สัญชาติ ความเข้าใจอย่างง่ายคือบัญชีแยกประเภทของหมู่บ้านชาวประมงนั้นอยู่ในหมู่บ้านชาวประมงและบัญชีแยกประเภทของหมู่บ้าน Orion นั้นอยู่ในหมู่บ้าน Orion ผู้ตรวจสอบไม่ได้ถือบัญชีแยกประเภท แต่มีหน้าที่รับผิดชอบในการวิ่งไปมาระหว่างหมู่บ้านต่างๆ เพื่อ เก็บบัญชี
แล้วใครจะเป็นผู้เก็บรักษาบัญชีแยกประเภทของหมู่บ้านต่างๆ? Ethereum แนะนำบทบาทของผู้ส่งต่อ (ผู้ให้บริการสถานะ) ซึ่งมีหน้าที่รับผิดชอบในการจัดเก็บสถานะบัญชีของชาร์ดต่างๆ และสามารถให้บริการชาร์ดได้เพียงบางส่วนเท่านั้น การทำงานของผู้ส่งต่อนั้นเข้าใจง่าย แต่จะชำระค่าบริการอย่างไร จะตรวจสอบความซื่อสัตย์ได้อย่างไร... การออกแบบกลไกที่เกี่ยวข้องเหล่านี้เป็นปัญหาใหม่ที่ต้องแก้ไข และยังเป็นปัญหาธรรมาภิบาลที่ชุมชน สมาชิกควรมีส่วนร่วมในการอภิปราย
แต่เราไม่สามารถกำหนดให้ผู้ใช้แต่ละรายจัดเก็บบัญชีเก่าทั้งหมดเพื่อให้สามารถพิสูจน์ธุรกรรมได้หลังจากเริ่มธุรกรรมแล้ว ในขณะนี้ จำเป็นต้องใช้ "รีเลย์" ซึ่งจัดเก็บสถานะบัญชีทั้งหมดของชาร์ด ตราบเท่าที่ ผู้ใช้เพิ่มความต้องการก็จะช่วยให้ผู้ใช้ให้ข้อมูลพยานของการทำธุรกรรมแก่ผู้ตรวจสอบ
Vitalik Buterin เผยแพร่บทความเมื่อวันที่ 11 มีนาคม โดยเสนอให้แทนที่ state root ด้วย polynomial Commitment เทคโนโลยีนี้ถูกนำมาใช้ที่นี่ โดยใช้วิธี Zero-knowledge Proof ในการพิสูจน์การทำธุรกรรมซึ่งสามารถเข้าใจได้ว่าเป็นการให้ผลการคำนวณของ ข้อมูล แทนที่จะให้ข้อมูลที่เกี่ยวข้องทั้งหมดโดยตรงแก่ผู้ตรวจสอบเพื่อตรวจสอบวิธีนี้สามารถลดขนาดของข้อมูลพยานได้อย่างมากและลดค่าใช้จ่ายต่างๆได้อย่างมีประสิทธิภาพ (สำหรับคำแนะนำโดยละเอียดเกี่ยวกับวิธีการใหม่ของ Vitalik โปรดดูเอกสารอ้างอิง 3 และสำหรับคำแนะนำโดยละเอียดเกี่ยวกับไคลเอนต์ไร้สัญชาติ โปรดดูเอกสารอ้างอิง 4)
ณ จุดนี้ การแบ่งบัญชีแยกประเภทออกเป็นหลายบัญชี นั่นคือ การแบ่งเป็นเศษ เสร็จสมบูรณ์แล้ว
ชื่อเรื่องรอง
การทำธุรกรรมข้ามเศษ
ถ้าคนในหมู่บ้านชาวประมงซื้อขายกับคนในหมู่บ้านชาวประมงเท่านั้นและคนในหมู่บ้าน Orion ค้าขายกับคนในหมู่บ้าน Orion เท่านั้น แต่ละหมู่บ้านก็สามารถเก็บบัญชีของตนเองได้ซึ่งไม่จำเป็นต้องใช้เทคโนโลยีใหม่ใดๆ . แต่ถ้าคนในหมู่บ้านชาวประมงต้องการค้าขายกับคนในหมู่บ้าน Orion ล่ะ บัญชีแยกประเภทต่าง ๆ จะสื่อสารกันได้อย่างไร นี่เป็นปัญหาที่ยุ่งยากที่สุดที่ต้องเผชิญกับการแบ่งส่วนสถานะ
มีสองวิธีในการแก้ปัญหานี้ วิธีหนึ่งคือซิงโครนัส (คู่แน่น) และอีกวิธีคืออะซิงโครนัส (คู่หลวม)
สมมติว่ามีคนชื่อ A ในหมู่บ้านชาวประมงและคนที่ชื่อ B ในหมู่บ้าน Orion A ต้องการจะให้ B 100 หยวน การซิงโครไนซ์หมายถึง: เมื่อ A เริ่มโอน คนทำบัญชีในหมู่บ้านประมงและหมู่บ้าน Orion ทราบ ธุรกรรมและความคืบหน้าของธุรกรรม นักบัญชีลบ 100 จาก A ในบัญชีแยกประเภท และผู้ทำบัญชีของ Orion Village เพิ่ม 100 ใน B ในบัญชีแยกประเภท หลังจากธุรกรรมเสร็จสิ้น ทั้งสองหมู่บ้านจะสร้างบล็อกใหม่พร้อมกัน
วิธีการแบบอะซิงโครนัส: เมื่อ A เริ่มต้นการโอน สมุดบัญชีของหมู่บ้านชาวประมงจะลด A ลง 100 และสร้างบล็อกใหม่ ผู้ทำบัญชีของหมู่บ้าน Orion ได้รับข้อความนี้ไม่ทางใดก็ทางหนึ่งในภายหลัง และหลังจากยืนยันว่าได้เงินของ A แล้ว ลดลงเขาจะเพิ่ม 100 ให้กับ B ในสมุดบัญชีของเขาเอง และธุรกรรมก็เสร็จสมบูรณ์ แต่ทั้งสองหมู่บ้านสร้างบล็อกใหม่แบบอะซิงโครนัส
วิธีการซิงโครไนซ์นั้นดูเป็นมิตร และรูปลักษณ์และความรู้สึกของกระบวนการดำเนินการธุรกรรมนั้นเหมือนกันกับการไม่แบ่งส่วนย่อย แต่ซ่อนปัญหาใหญ่ไว้ นั่นคือเป็นการยากที่จะจัดการกับ "การเปลี่ยนแปลงสถานะต่อเนื่อง" มันหมายความว่าอะไร?
หาก A โอนเพียง 100 หยวนให้ B หลังจากได้ยินการทำธุรกรรม หมู่บ้านชาวประมงและหมู่บ้าน Orion สามารถยืนยันได้อย่างง่ายดายว่าทุกคนเก็บบัญชีด้วยวิธีนี้ สมุดบัญชีของหมู่บ้านชาวประมงจะลดลง 100 สำหรับ A และหมู่บ้าน Orion จะ เพิ่ม 100 เป็น B. ทำบัญชีให้สมบูรณ์ อย่างไรก็ตาม หาก A โอน 100 ไปยัง B แล้วโอนไปยัง B 50 การเปลี่ยนแปลงสถานะอย่างต่อเนื่องจะเกิดขึ้น แต่ A มีทั้งหมดเพียง 120 เท่านั้น ในขณะนี้ เป็นเรื่องยากสำหรับทั้งสองหมู่บ้านที่จะยืนยันว่าอีกฝ่ายเก็บบัญชีไว้อย่างไร:
หากผู้ตรวจสอบแต่ละคนไปสื่อสารกับผู้ตรวจสอบความถูกต้องของอีกฝ่ายด้วยตัวเอง ค่าใช้จ่ายในการสื่อสารจะเพิ่มขึ้นอย่างรวดเร็ว และจะเป็นเรื่องยากมากที่จะบรรลุผล หากการสื่อสารผ่านหัวหน้าหมู่บ้านของทั้งสองฝ่าย แต่ละหมู่บ้านจำเป็นต้องดำเนินการ ฉันทามติล่วงหน้าแล้วหัวหน้าหมู่บ้านบอกอีกฝ่ายถึงผลลัพธ์ที่แน่นอนนอกจากจะเพิ่มต้นทุนแล้วยังยากที่จะบรรลุผลเนื่องจากกลไกฉันทามติของ Ethereum เองไม่สามารถบรรลุผลที่แน่นอนได้ (ขั้นสุดท้าย)
วิธีการแบบอะซิงโครนัสจะไม่มีปัญหากับการเปลี่ยนแปลงสถานะอย่างต่อเนื่อง เนื่องจากแนวทางของมันคือ "รอ" เมื่อสถานะของคุณได้รับการยืนยัน ฉันจะดำเนินการขั้นตอนต่อไป หลังจากลบ 100 หรือ 50 แล้ว ให้ตัดสินใจเพิ่ม 100 หรือ 50 ใน B
ปัญหาเกี่ยวกับวิธีการแบบอะซิงโครนัสคือความล้มเหลวของอะตอม ธุรกรรมควรเป็นแบบอะตอมมิก ไม่ว่าจะดำเนินการหรือไม่ดำเนินการ แต่ในลักษณะอะซิงโครนัส เป็นไปได้ที่ส่วนหนึ่งของธุรกรรมจะได้รับการยืนยัน แต่ส่วนอื่นๆ จะถูกละทิ้ง
ตัวอย่างเช่น ในที่สุดบล็อกที่หมู่บ้านชาวประมงลบ 100 จาก A ได้รับการยืนยันบนห่วงโซ่หลักของหมู่บ้านชาวประมง แต่ในที่สุดบล็อกที่หมู่บ้าน Orion เพิ่ม 100 ลงใน B ถูกละทิ้งในห่วงโซ่ด้านข้างของหมู่บ้าน Orion ความล้มเหลวของปรมาณูเป็นปัญหาแต่สามารถแก้ไขได้ด้วยการออกแบบ สำหรับคำแนะนำโดยละเอียดเกี่ยวกับส่วนนี้ โปรดดูข้อมูลอ้างอิง 5 ที่ส่วนท้ายของบทความ
Ethereum ได้กล่าวถึงโมเดลสถาปัตยกรรมแบบอะซิงโครนัสบางโมเดล Vitalik เสนอโมเดลล่าสุดในการประชุม DevCon 5 ในเดือนตุลาคม 2019 แนวคิดพื้นฐานคือการใช้ beacon chain เพื่อส่งข้อมูล: ในแต่ละช่อง (12 วินาที) นาที ห่วงโซ่ชิ้นส่วนจะสร้าง บล็อกและการเชื่อมโยงข้ามกับบล็อกเชนบีคอนวิธีการเชื่อมต่อดังแสดงในรูปด้านล่าง ด้วยวิธีนี้ ชิ้นส่วนใด ๆ จะสามารถทราบข้อมูลของชิ้นส่วนอื่น ๆ ทั้งหมดผ่านห่วงโซ่บีคอนเมื่อบรรจุธุรกรรมใหม่ของตัวเอง สล็อตเป็นแบบอะซิงโครนัสระหว่างชิ้นส่วนต่างๆ
วิธีนี้ช่วยลดเวลาแฝงของธุรกรรมข้ามชาร์ด แต่เพิ่มข้อกำหนดในบีคอนเชน ซึ่งจำเป็นต้องเก็บข้อมูลพิสูจน์สำหรับชาร์ดทั้งหมด วิธีนี้ยังเพิ่มจำนวนลิงก์ข้าม (เดิมออกแบบเป็นแต่ละยุค นั่นคือ , 6.4 นาที, 32 บล็อก crosslink หนึ่งครั้ง) ซึ่งจะเพิ่มค่าใช้จ่ายที่เกี่ยวข้องต่างๆ อย่างหลีกเลี่ยงไม่ได้ และด้วยเหตุนี้ จำนวนชิ้นส่วนใน Ethereum จึงเปลี่ยนจาก 1,024 เป็น 64 จากทิศทางการออกแบบอื่น ลดจำนวนรวมของลิงก์ (ดูอ้างอิง 6 สำหรับคำแนะนำโดยละเอียดเกี่ยวกับสถาปัตยกรรม)
เมื่อพิจารณาจากโครงร่างการออกแบบการแบ่งชิ้นส่วนในปัจจุบัน โมเดลแบบซิงโครนัสมีแนวโน้มที่จะสื่อสารระหว่างชิ้นส่วนและชิ้นส่วนด้วยกันมากกว่า ในขณะที่แบบจำลองอะซิงโครนัสมีแนวโน้มที่จะสื่อสารระหว่างชิ้นส่วนและชิ้นส่วนผ่านบุคคลที่สามมากกว่า แบบแรกประสบปัญหาข้อจำกัดด้านทราฟฟิก ส่วนแบบหลังเผชิญกับปัญหา ปัญหาความสมดุลของค่าโสหุ้ยหลายรายการ การออกแบบและการใช้งานธุรกรรมข้ามชาร์ดยังอยู่ในระหว่างดำเนินการ และยังไม่มีความแน่นอนว่าสถาปัตยกรรมใดที่ Ethereum 2.0 จะนำมาใช้ในที่สุด
ชื่อเรื่องรอง
สัญญาอัจฉริยะข้ามเศษ
หลังจากเปิดตัว Sharding และธุรกรรมข้าม Shard แล้ว หัวหน้าใหญ่ขั้นสูงสุดบนเส้นทางสู่การพัฒนา Ethereum 2.0 ก็มาถึง ซึ่งก็คือสัญญาอัจฉริยะข้าม Shard ความแตกต่างระหว่างธุรกรรมข้ามชาร์ดและสัญญาอัจฉริยะข้ามชาร์ดคือธุรกรรมจะมีตัวแปรส่วนกลางเท่านั้น ในขณะที่สัญญาอัจฉริยะมีตัวแปรท้องถิ่น ตัวแปรโลคัลทำให้เกิดปัญหาอะไร
หลังจากการแยกย่อย Ethereum มีบัญชีแยกประเภท 64 บัญชีจากมุมมองทางกายภาพ แต่มีเพียงบัญชีแยกประเภทเดียวจากมุมมองนามธรรม: บัญชีแยกประเภทสามารถจินตนาการได้ว่าเป็นต้นไม้ใหญ่ แต่ละใบของต้นไม้เก็บข้อมูลสถานะบัญชี 64 บัญชีแยกประเภทคือ ต้นไม้ 64 ต้น จากนั้นรากของต้นไม้เหล่านี้จะถูกส่งไปยังห่วงโซ่สัญญาณเพื่อสร้างต้นไม้ใหญ่ต้นใหม่ และบัญชีแยกประเภท 64 บัญชีจะรวมกันเป็นบัญชีแยกประเภท (นี่เป็นเพียงคำเปรียบเทียบโดยประมาณ)
ในธุรกรรมข้ามชาร์ด เมื่อชาร์ดต้องการทราบสถานะบัญชีของชาร์ดอื่น สามารถติดตามแผนผังเพื่อค้นหา leaf ที่จัดเก็บสถานะได้เสมอ จากนั้นเปลี่ยนสถานะบัญชีชาร์ดของตัวเองและทำธุรกรรมให้เสร็จสมบูรณ์ ถือได้ว่าผ่านต้นไม้นี้ เศษส่วนต่าง ๆ ทำให้การสื่อสารข้อมูลสมบูรณ์
แต่สำหรับ smart contracts ข้าม shards ปัญหาเกิดขึ้น ข้อมูลที่เก็บไว้บน leaf ของ tree นี้เป็นตัวแปร global ทั้งหมด และไม่มีตัวแปร local ถ้า smart contract ใน shard หนึ่งเรียก smart contract ในอีก shard จะเกิดอะไรขึ้นกับ ทั้งสองส่งผ่านข้อมูลไปยังตัวแปรท้องถิ่น? ต้นไม้ไม่สามารถให้บริการได้
ในปัจจุบัน ยังไม่มีแผนการออกแบบสมาร์ทคอนแทรคข้ามชาร์ดอย่างเป็นระบบ แต่มีสองข้อเสนอ หนึ่งคือการรวมสมาร์ทคอนแทรคที่เกี่ยวข้องไว้ในชาร์ดเดียวกันเพื่อดำเนินการ นั่นคือ การกำจัดสมาร์ทคอนแทรคข้ามชาร์ด หนึ่งคือ เสนอให้ใช้เทคโนโลยี SIMD (Single Instruction Stream Multiple Data Stream) เพื่อให้สามารถดำเนินการสัญญาอัจฉริยะได้พร้อมกัน
อ้างอิง:
1.《 Minimum Committee Size Explained》Ethereum 2.0 จะแนะนำสัญญาอัจฉริยะในเฟส 2 ซึ่งหมายความว่าสัญญาอัจฉริยะจะไม่เกิดขึ้นจนกว่าจะถึงเฟส 2 และหลังจากขั้นตอนนี้เท่านั้นที่สามารถประกาศได้ว่า Ethereum ได้เข้าสู่ยุค 2.0 แล้ว
3.《Using polynomial commitments to replace state roots》; ผู้แต่ง จื่อเฉิงเหลียง;
4."Ethereum 2.0: การสุ่ม"; ผู้แต่ง, บรูโน่ ชควอร์ก; ผู้แปล, จอนนี่, เอ เจียน;
5.; ผู้แต่ง ไวทลิก บูเทริน;"เครือข่ายรีเลย์ Eth2.0 และกลไกค่าธรรมเนียม"
6.《Eth2 shard chain simplification proposal》; ผู้แต่ง John Adler ผู้แปล IAN LIU, A Jian;
7."แนวคิดและความท้าทายของ Blockchain Fragmentation"; ผู้แต่ง Alexander Skidanov ผู้แปล Jhonny, Echo, A Jian;
8.《Merge blocks and synchronous cross-shard state execution》; ผู้แต่ง ไวทลิก บูเทริน;
