หมายเหตุบรรณาธิการ: บทความนี้มาจากAmbi Labs (รหัส: secbitlabs)พิมพ์ซ้ำโดย Odaily โดยได้รับอนุญาต

หมายเหตุบรรณาธิการ: บทความนี้มาจาก

Ambi Labs (รหัส: secbitlabs)

พิมพ์ซ้ำโดย Odaily โดยได้รับอนุญาต

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

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

บทความนี้จะพยายามแนะนำวิธีการรวมการออกแบบระบบแบบกระจายกับการออกแบบการเข้ารหัสใน Ethereum 2.0 เพื่อให้บรรลุความก้าวหน้าในประสิทธิภาพของเครือข่ายสาธารณะ

ชื่อเรื่องรอง

การแบ่งกลุ่มสถานะ: จากบัญชีแยกประเภทเดียวเป็นหลายบัญชีแยกประเภท

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

สำหรับห่วงโซ่สาธารณะที่ไม่แยกส่วน โหนดทั้งหมดจะถือบัญชีแยกประเภทเดียวกัน และเพื่อป้องกันความขัดแย้งในการทำบัญชี โหนดที่ผลิตบล็อกเดียวเท่านั้นที่ได้รับอนุญาตให้เก็บหนังสือในแต่ละครั้ง Ethereum เสนอ state sharding ซึ่งจริง ๆ แล้วแบ่งบัญชีแยกประเภทออกเป็นหลาย ๆ บัญชีแยกประเภท ด้วยวิธีนี้ บางโหนดจะเก็บบัญชีไว้ในบัญชีแยกประเภทอันดับ 1 และบางโหนดก็เก็บบัญชีในบัญชีแยกประเภทอันดับ 2... (เทียบเท่ากับ 7-11 จากเงินสด ลงทะเบียน แพลตฟอร์มเพิ่มขึ้นเป็นหลายเครื่องบันทึกเงินสด) และหลายโหนดเก็บบัญชีในเวลาเดียวกัน และประสิทธิภาพของห่วงโซ่สาธารณะทั้งหมดจะได้รับการปรับปรุงเชิงคุณภาพ

แต่ถ้าเราแก้ไขความสัมพันธ์ระหว่างโหนดที่ผลิตบล็อกกับบัญชีแยกประเภท/เศษ เช่น ถูกกำหนดให้สี่โหนด a, b, c และ d รับผิดชอบบัญชีแยกประเภทอันดับ 1 ดังนั้นคนร้ายก็จำเป็นต้องซื้อเท่านั้น บางส่วนของ a, b, c และ d มันสามารถทำลายบัญชีแยกประเภทและในขณะที่ประสิทธิภาพของห่วงโซ่สาธารณะได้รับการปรับปรุงความปลอดภัยจะลดลงในสัดส่วนที่เท่ากัน

วิธีแก้ไขที่ Ethereum มอบให้คือโหนดที่ผลิตบล็อกนั้นไม่ใช้บัญชีแยกประเภทใดๆ หรืออีกนัยหนึ่งคือโหนดที่ผลิตบล็อกไม่ต้องการบัญชีแยกประเภทเพื่อเก็บบัญชี

สิ่งนี้จะก่อให้เกิดประโยชน์หลักสองประการ ประการแรก ไม่ว่าจะกำหนด Shard ให้กับ Node ใด ก็สามารถเริ่มการทำบัญชี (Block Production) ได้ทันที และแทบจะไม่ต้องใช้เวลาเลยในการรับและซิงโครไนซ์ Ledger ของ Shard โหนดจึงสามารถ ง่ายต่อการข้ามไปมาระหว่าง shards ต่างๆ ประการที่สองคือโหนดที่ผลิตบล็อกไม่จำเป็นต้องจัดเก็บบัญชีแยกประเภทและไม่ต้องการการกำหนดค่าฮาร์ดแวร์ที่สูง ใครก็ตามที่จำนอง 32ETH สามารถเป็นผู้ตรวจสอบได้ซึ่งมีประโยชน์มากสำหรับการกระจายอำนาจของ Ethereum PoS และความปลอดภัยของห่วงโซ่สาธารณะทั้งหมด

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

ชื่อเรื่องรอง

ความมุ่งมั่นของเวกเตอร์: จากการค้นหาสู่การพิสูจน์

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

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

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

รูปด้านล่างคือ Merkle tree โหนดลีฟที่ชั้นล่างสุดจะเก็บข้อมูลแอปพลิเคชัน และโหนดอื่น ๆ ที่ไม่ใช่ลีฟจะเก็บค่าแฮชของโหนดย่อย หากคุณทราบค่าของโหนดสีเขียวและโหนดสีเหลืองทั้งหมด คุณสามารถทำการแฮชสามครั้งจากล่างขึ้นบนเพื่อรับค่าของรากของ Merkle tree ซึ่งก็คือ 6c0a

จากนั้น ถ้าตัวตรวจสอบมีค่าของทรีรูท (6c0a) ผู้พิสูจน์ใช้ค่าของโหนดสีเขียวและค่าทั้งหมดของโหนดสีเหลืองเป็นหลักฐานให้กับผู้ตรวจสอบ ผู้ตรวจสอบจะสามารถคำนวณได้หรือไม่ ค่าแฮชสามครั้ง เท่ากับ 6c0a เพื่อตัดสินว่าค่าของโหนดสีเขียวอยู่ใน Merkle tree นี้หรือไม่ คำตอบคือใช่ นี่คือหลักฐานการเป็นสมาชิกของโหนดสีเขียวของ Merkle tree ซึ่งทำขึ้นตามข้อตกลงแบบเวกเตอร์ และนี่เป็นวิธีที่โหนด Bitcoin SPV (Simple Payment Verification) ทำงานค่อนข้างมาก

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

คำอธิบายภาพ

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

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

สำหรับโหนดที่ผลิตบล็อกบน Ethereum 2.0 shard ระบบการพิสูจน์ยังประกอบด้วยสามส่วน ได้แก่ นามธรรม การพิสูจน์ และการยืนยัน แต่จะต้องใช้การพิสูจน์ที่ได้รับจากผู้ส่งธุรกรรม (ไม่ใช่โหนดแบบเต็ม) เพื่อตัดสินว่าโหนดใหม่ ธุรกรรมนั้นถูกกฎหมาย (ไม่ใช่ว่ามีธุรกรรมเก่าอยู่หรือไม่) และใช้วิจารณญาณนี้เป็นพื้นฐานในการลงบัญชี

ชื่อเรื่องรอง

ไร้สัญชาติ: จากหลักฐานบัญชีแยกประเภทไปจนถึงหลักฐานพฤติกรรม

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

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

จะทำอย่างไรถ้า A มีการทำธุรกรรมเมื่อวานนี้? มันง่ายมาก ในตอนนี้ A ไม่ได้พิสูจน์ว่าเขาไม่มีธุรกรรมใด ๆ แต่พิสูจน์ได้ว่าเมื่อวานเขาทำธุรกรรมเพียงครั้งเดียวและธุรกรรมนั้นมีค่าใช้จ่าย 3 หยวน หัวหน้าหมู่บ้านรู้ว่าเขายังมีเงินอยู่ 7 หยวน ดังนั้นเขาจึงบันทึกได้ ธุรกรรมใหม่

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

จะบรรลุความไร้สัญชาติได้อย่างไร? จะทำบัญชีให้สมบูรณ์ด้วยความช่วยเหลือของหลักฐานพฤติกรรมได้อย่างไร? ยังคงเป็นวิธีการรับรองสมาชิก สามารถใช้ Merkle tree เพื่อกรอกหลักฐานการเป็นสมาชิกนี้ได้หรือไม่? ในทางทฤษฎี เป็นไปได้ แต่สำหรับสถานการณ์แอปพลิเคชัน "ไร้สัญชาติ" ค่าใช้จ่ายในการใช้งานสูงเกินไป ในบทความนี้ เราแนะนำหลักฐานการเป็นสมาชิกผ่านภาระผูกพันของเวกเตอร์ย่อยแบบรวมสำหรับการทำบัญชีแยกประเภท

Aggregatable Subvector Commitments (aSVC) เป็นความพยายามในการวิจัยล่าสุดจากบทความเรื่อง "Aggregated Subvector Commitments for Stateless Cryptocurrencies" โดย Alin Tomescu, Ittai Abraham, Vitalik Buterin (Ethereum), Justin Drake (Ethereum Square), Dankrad Feist (Ethereum), Dmitry Khovratovich (อีเธอเรียม). มีขั้นตอนการทำงานดังนี้

1. เริ่มต้น Sharding นั่นคือกำหนดสถานการณ์เริ่มต้นของบัญชีเมื่อมีการสร้างสมุดบัญชี สมมติว่า shard มี 100 บัญชีเมื่อสร้างและบัญชีเหล่านี้มียอดคงเหลือเริ่มต้น เราจำเป็นต้องใช้ v(i) เพื่อแสดงบัญชี i-th ซึ่งเป็นคู่ของค่าต่างๆ เช่น (ที่อยู่ i, ยอดคงเหลือ i ); ใช้ V แทนบัญชีทั้งหมด เป็นชุดของค่าต่างๆ เช่น (ที่อยู่ 1, ยอดคงเหลือ 1) (ที่อยู่ 2, ยอดคงเหลือ 2)...(ที่อยู่ 100, ยอดคงเหลือ 100)

ในเวลาเดียวกัน ต้องสร้างค่า 2 ค่า ค่าแรกเรียกว่า c ซึ่งเป็นสัญญาผูกมัดกับ V ซึ่งเป็นตัวแทนของบัญชีทั้งหมดและยอดคงเหลือในบัญชีของส่วนแบ่งในเวลานี้ โหนดที่ผลิตบล็อกถือ c ไว้ในมือ (สามารถเปรียบเทียบได้กับรากของ Merkle tree เพื่อให้เข้าใจง่าย) ซึ่งเป็นบทสรุปสำหรับการตรวจสอบในอนาคต

อันที่สองเรียกว่า π(i) ซึ่งเป็นข้อพิสูจน์ว่า v(i) เป็นสมาชิกของ V ซึ่งเป็นตัวแทนของบัญชี i-th และยอดคงเหลือของบัญชีอยู่ในบัญชีแยกประเภททั่วไป V แต่ละบัญชีมีและเก็บเฉพาะ π(i) ของตัวเอง ซึ่งเป็นหลักฐานที่ส่งไปยังโหนดบล็อกเมื่อส่งธุรกรรมในอนาคต

ในระหว่างขั้นตอนการเริ่มต้น การสร้างข้อผูกพันและการพิสูจน์จำเป็นต้องมี "สถานะ" เริ่มต้น

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

3. ถัดไปคือจุดสำคัญ: อัปเดต c และ π(i)

c (ข้อผูกมัดต่อบัญชีแยกประเภททั้งหมด) ไม่ได้ถูกสร้างขึ้นตามสถานะอีกต่อไป มันถูกสร้างขึ้นโดยใช้ c ก่อนการทำธุรกรรมครั้งแรกและการเปลี่ยนแปลงยอดคงเหลือที่เกิดจากการทำธุรกรรมครั้งแรก π (i) (หลักฐานของบัญชี) ไม่ใช่ สร้างขึ้นตามสถานะ มันถูกสร้างด้วย π(i) ก่อนการทำธุรกรรมครั้งแรก และการเปลี่ยนแปลงของบัญชีโดยการทำธุรกรรมครั้งแรก

หลังจากอัปเดต c และ π(i) เสร็จสิ้นแล้ว โหนดที่สร้างบล็อกมีข้อผูกมัดใหม่ (new c) ที่สามารถรับประกันยอดคงเหลือใหม่ของผู้ใช้ทั้งหมด และบัญชียังมีหลักฐานใหม่ (new c) ที่สามารถ พิสูจน์ยอดใหม่ ))

โดยการเปรียบเทียบ ธุรกรรมแต่ละรายการจะเปลี่ยน c หนึ่งครั้ง และเปลี่ยน π(i) ทั้งหมดหนึ่งครั้ง แต่การเปลี่ยนแปลงนี้ไม่ได้ขึ้นอยู่กับข้อมูลสถานะอีกต่อไป แต่จะขึ้นอยู่กับ c และ π(i) เก่า เช่นเดียวกับธุรกรรมก่อนหน้า เมื่อ เมื่อจำเป็นต้องตรวจสอบธุรกรรมใหม่ โหนดที่สร้างบล็อกจะมี c ล่าสุดอยู่ในมือเสมอ สามารถตัดสินได้ว่าธุรกรรมนั้นถูกกฎหมายหรือไม่ และสามารถบรรจุลงในบล็อกผ่าน c และ π(i) ที่จัดทำโดย บัญชี.

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

เป้าหมายการออกแบบของ aSVC คือการพิสูจน์การเป็นสมาชิกที่มีประสิทธิภาพ ลดค่าใช้จ่ายในการสื่อสารและค่าใช้จ่ายในการคำนวณในกระบวนการข้างต้น เพื่อให้สามารถใช้โครงร่างนี้สำหรับการใช้งานบล็อกเชนไร้สัญชาติ จากมุมมองของเอกสาร การใช้รูปแบบ aSVC ขนาดของ c และ π(i) เพียงไม่กี่สิบไบต์ เวลาอัปเดตของ π(i) คือ O(1) และเวลาในการตรวจสอบก็เป็น O( 1) รองรับการรวมหลักฐานหลายรายการเข้าเป็นหนึ่งหลักฐาน O(1) การใช้งานแบบโอเวอร์เฮดต่ำนี้คือสิ่งที่ aSVC ให้ความสำคัญทุกประการ อย่างไรก็ตาม เช่นเดียวกับการสนทนาของ Vitalik ใน Ethereum Researcher Forum, aSVC ยังคงต้องการการเพิ่มประสิทธิภาพเพิ่มเติม

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

1. เพื่อความปลอดภัย State Sharding ของ Ethereum 2.0 จำเป็นต้องกำหนดโหนดการสร้างบล็อกแบบสุ่ม

2. หากโหนดที่ผลิตบล็อกต้องการบัญชีแยกประเภท การซิงโครไนซ์บัญชีแยกประเภทจะกลายเป็นปัญหาคอขวดด้านประสิทธิภาพใหม่ และการจัดเก็บบัญชีแยกประเภทจะส่งผลต่อการกระจายอำนาจของ PoS ด้วย

4. การเปลี่ยนแปลงความคิดอย่างแรก: เปลี่ยนวิธีค้นหาบัญชีแยกประเภทเป็นวิธีพิสูจน์บัญชีแยกประเภท สิ่งนี้ต้องทำด้วยความช่วยเหลือของการเข้ารหัส

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

6. มีเครื่องมือมากมายสำหรับการเข้ารหัส เมื่อคุณมีเป้าหมาย คุณต้องเลือกและรวมเครื่องมือที่เหมาะสมเพื่อสร้างโซลูชันตามความต้องการของแอปพลิเคชัน และเพิ่มประสิทธิภาพโซลูชัน

ชื่อเรื่องรอง

ไข่อีสเตอร์: คำสัญญาของเวกเตอร์ย่อยที่รวบรวมได้

ในบทความ เราอธิบายการทำงานของ aSVC ในภาษาธรรมชาติ หากคุณสนใจ คุณสามารถทำความเข้าใจได้ชัดเจนยิ่งขึ้นผ่านข้อกำหนด API ของ aSVC ดังแสดงในรูปด้านล่าง: กล่องสีแดงกล่องแรกคือการสร้างข้อผูกพัน c ระหว่างการเริ่มต้น กล่องสีแดงที่สองคือการอัปเดต c ตามการทำธุรกรรม กล่องสีเขียวกล่องแรกคือการสร้างหลักฐาน π(i) ระหว่างการเริ่มต้น และ ช่องสีเขียวที่สองคือ The transaction updates π(i) ช่องสีฟ้าคือ block node โดยใช้ c และ π(i) ในการตรวจสอบ

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

ตามที่กล่าวไว้ข้างต้น สิ่งที่ c สัญญาคือ V และจาก c ไปสู่ ​​new c จริง ๆ แล้วจากสัญญาว่าจะเป็น V ไปสู่การให้สัญญากับ V ใหม่ สำหรับ V จะประกอบด้วยชุดของจุด (ที่อยู่ 1, ยอด 1) คือหนึ่งจุด, (ที่อยู่ 2, ยอด 2) เป็นอีกจุดหนึ่ง... (ที่อยู่ 100, ยอด 100) คือจุดที่ 100

ด้วยความช่วยเหลือของการแก้ไขลากรองจ์ ชุดของจุดเหล่านี้สามารถเปลี่ยนเป็นพหุนามได้ (เส้นโค้งที่แสดงโดยพหุนามจะผ่านจุดเหล่านี้ทั้งหมด) ซึ่งหมายความว่าความมุ่งมั่นต่อชุดของจุดสามารถกลายเป็นความมุ่งมั่นต่อพหุนามได้ ; จาก c ถึง new c เท่ากับการเปลี่ยนจากการส่งพหุนามหนึ่งไปยังการส่งพหุนามอีกตัวหนึ่งhttps://eprint.iacr.org/2020/527.pdf。