ข้อความ

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

ชื่อระดับแรก

1. เครือข่ายพันธมิตรหลายแห่งในจีน เช่น FISCO-BCOS สนับสนุนการดำเนินการตรวจสอบธุรกรรมแบบขนานภายในบล็อก

2. Khipu โครงการเครือข่ายสาธารณะ เป็นการนำสกาล่าของโปรโตคอล Ethereum

3. Aptos โครงการเครือข่ายสาธารณะ ย้ายเครื่องเสมือน

ชื่อระดับแรก

ความยากลำบากในการดำเนินการธุรกรรมแบบคู่ขนาน

ขั้นแรกให้ตรวจสอบขั้นตอนการดำเนินการธุรกรรมแบบดั้งเดิม:

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

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

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

FISCO-BCOS

ชื่อระดับแรก

การเปรียบเทียบโครงร่างการทำธุรกรรมแบบคู่ขนาน

ชื่อระดับแรก

ภาพรวม

FISCO-BCOS 2.0 ใช้โครงสร้างกราฟในกระบวนการประมวลผลธุรกรรม และออกแบบตัวดำเนินการธุรกรรมแบบขนาน (PTE, Parallel Transaction Executor) ตามแบบจำลอง DAG PTE สามารถใช้ประโยชน์จากโปรเซสเซอร์แบบมัลติคอร์ได้อย่างเต็มที่ เพื่อให้ธุรกรรมในบล็อกสามารถดำเนินการแบบขนานได้มากที่สุดเท่าที่จะเป็นไปได้ ในขณะเดียวกัน ก็มอบอินเทอร์เฟซการเขียนโปรแกรมที่เรียบง่ายและเป็นมิตรแก่ผู้ใช้ ดังนั้นผู้ใช้จึงไม่จำเป็นต้องสนใจเกี่ยวกับรายละเอียดการใช้งานแบบขนานที่ยุ่งยาก ผลการทดลองของโปรแกรมทดสอบเกณฑ์มาตรฐานแสดงให้เห็นว่าเมื่อเปรียบเทียบกับแผนการดำเนินการธุรกรรมแบบซีเรียลแบบดั้งเดิม ภายใต้สภาวะที่เหมาะสม PTE ที่ทำงานบนโปรเซสเซอร์ 4 คอร์สามารถปรับปรุงประสิทธิภาพได้ประมาณ 200% ~ 300% และการปรับปรุงในการคำนวณเทียบได้กับ จำนวนคอร์ในสัดส่วนโดยตรง ยิ่งคอร์มาก ประสิทธิภาพก็ยิ่งสูงขึ้น

รายละเอียดโปรแกรม

กราฟกำกับที่ไม่มีวัฏจักรเรียกว่ากราฟอะไซคลิกกำกับ (DAG) ในชุดของธุรกรรม ทรัพยากรที่ไม่รวมร่วมกันซึ่งครอบครองโดยแต่ละธุรกรรมสามารถระบุได้ด้วยวิธีหนึ่ง จากนั้นสามารถสร้างกราฟ DAG ที่ขึ้นกับธุรกรรมได้ตามลำดับของธุรกรรมในบล็อกและความสัมพันธ์ของอาชีพของทรัพยากรที่พิเศษร่วมกัน . ดังที่แสดงในรูปด้านล่าง ธุรกรรมทั้งหมดที่มีระดับเป็น 0 (ไม่มีงานสั่งจองล่วงหน้าที่ขึ้นอยู่กับ) สามารถดำเนินการพร้อมกันได้ หลังจากการจัดเรียงโทโพโลยีตามลำดับของรายการธุรกรรมดั้งเดิมทางด้านซ้าย สามารถรับธุรกรรม DAG ทางด้านขวาได้

สถาปัตยกรรมโมดูลาร์

• ผู้ใช้เริ่มต้นธุรกรรมโดยตรงหรือโดยอ้อมผ่าน SDK

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

• ต้องมีการยืนยันการทำธุรกรรมก่อนที่จะบรรลุฉันทามติ และนี่คือจุดเริ่มต้นของงานของ PTE ดังที่เห็นได้จากแผนภาพสถาปัตยกรรม PTE จะอ่านธุรกรรมในบล็อกตามลำดับก่อนแล้วจึงป้อนข้อมูลลงใน DAG Constructor ตัวสร้าง DAG จะสร้างธุรกรรม DAG ที่มีธุรกรรมทั้งหมดตามการพึ่งพาของแต่ละธุรกรรม จากนั้น PTE จะปลุกเธรดพูลของผู้ปฏิบัติงานและใช้หลายเธรดเพื่อดำเนินการธุรกรรม DAG แบบขนาน ช่างเชื่อมมีหน้าที่ระงับเธรดหลักจนกว่าเธรดทั้งหมดในกลุ่มเธรดของผู้ปฏิบัติงานจะเสร็จสิ้นการดำเนินการ DAG ในขณะนี้ Joiner มีหน้าที่ในการคำนวณสถานะรูทและรูทใบเสร็จตามบันทึกการแก้ไขสถานะของแต่ละคู่ธุรกรรม และส่งกลับผลลัพธ์การดำเนินการไปยังผู้เรียกด้านบน

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

ขั้นตอนการสร้างธุรกรรม DAG

1. นำธุรกรรมทั้งหมดของบล็อกออกจากบล็อกที่บรรจุ

2. เริ่มต้นอินสแตนซ์ DAG ด้วยจำนวนธุรกรรมเป็นจำนวนจุดยอดสูงสุด

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

ข้อสังเกต: หลังจากสร้างขอบที่ขึ้นต่อกันทั้งหมดแล้ว จะไม่สามารถดำเนินการแบบขนานได้ แต่สามารถดำเนินการตามลำดับเท่านั้น

ขั้นตอนการดำเนินการ DAG

1. เธรดหลักจะเริ่มต้นกลุ่มเธรดที่มีขนาดที่สอดคล้องกันตามจำนวนแกนฮาร์ดแวร์ หากล้มเหลวในการรับจำนวนแกนฮาร์ดแวร์ จะไม่มีการสร้างเธรดอื่น

2. เมื่อ DAG ยังดำเนินการไม่เสร็จ เธรดจะวนซ้ำและรอเมธอด waitPop จาก DAG เพื่อนำธุรกรรมที่พร้อมออกโดยมีค่าเป็น 0 หากธุรกรรมที่จะดำเนินการสำเร็จลุล่วง ธุรกรรมจะถูกดำเนินการ และระดับของงานที่ขึ้นต่อกันตามมาจะลดลง 1 หลังจากดำเนินการ หากระดับของธุรกรรมลดลงเป็น 0 ให้เพิ่มธุรกรรมไปที่ระดับบนสุด หากล้มเหลว หมายความว่า DAG ถูกดำเนินการและเธรดออกจากระบบ

ปัญหาและแนวทางแก้ไข

1. สำหรับบล็อกเดียวกัน จะแน่ใจได้อย่างไรว่าโหนดทั้งหมดถูกเรียกใช้งานและมีสถานะเหมือนกัน (ตรงกันสามรูท)

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

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

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

2. จะทราบได้อย่างไรว่าธุรกรรมสองรายการขึ้นอยู่กับ?

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

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

ในธุรกรรมการโอนอย่างง่าย เราสามารถตัดสินได้ว่ามีการพึ่งพากันระหว่างธุรกรรมสองรายการโดยพิจารณาจากที่อยู่ของผู้ส่งและผู้รับของการโอน

ยกตัวอย่างการโอน 3 รายการต่อไปนี้: A→B, C→D, D→E จะเห็นได้ว่าธุรกรรม D→E ขึ้นอยู่กับผลลัพธ์ของธุรกรรม C→D แต่ธุรกรรม A→B ไม่มีส่วนเกี่ยวข้องกับอีกสองธุรกรรม ดังนั้นจึงสามารถดำเนินการแบบคู่ขนานกันได้

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

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

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

FISCO BCOS มอบหมายงานในการระบุการพึ่งพาธุรกรรมให้กับนักพัฒนาที่คุ้นเคยกับเนื้อหาสัญญามากกว่า โดยเฉพาะอย่างยิ่ง ทรัพยากรพิเศษร่วมกันที่การทำธุรกรรมขึ้นอยู่กับสามารถแสดงโดยชุดของสตริง FISCO BCOS เปิดเผยอินเทอร์เฟซแก่ผู้พัฒนา ผู้พัฒนากำหนดทรัพยากรที่ธุรกรรมขึ้นอยู่กับในรูปแบบของสตริง และแจ้งให้ผู้ดำเนินการทราบบนเชน ผู้ดำเนินการจะจัดเรียงธุรกรรมทั้งหมดในบล็อกโดยอัตโนมัติเป็นธุรกรรม DAG ตาม การพึ่งพาธุรกรรมที่ระบุโดยผู้พัฒนา . ตัวอย่างเช่น ในสัญญาการโอนอย่างง่าย นักพัฒนาเพียงแค่ระบุว่าการพึ่งพาของธุรกรรมการโอนแต่ละรายการคือ {ที่อยู่ผู้ส่ง + ที่อยู่ผู้รับ} นอกจากนี้ หากผู้พัฒนาแนะนำที่อยู่ของบุคคลที่สามอื่นในลอจิกการโอน การพึ่งพาจะต้องกำหนดเป็น {sender address + receiver address + third-party address}

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

กรอบสัญญาคู่ขนานFISCO BCOS ได้กำหนดข้อกำหนดการเขียนสัญญาบางประการสำหรับนักพัฒนาเพื่อใช้กรอบของสัญญาคู่ขนานโดยมีรายละเอียดดังนี้มิวเท็กซ์แบบขนานการทำธุรกรรมสองรายการสามารถดำเนินการพร้อมกันได้หรือไม่นั้นขึ้นอยู่กับว่ามีธุรกรรมสองรายการนั้นอยู่หรือไม่。

แยกกันไม่ออก

• . การยกเว้นร่วมกันหมายความว่าธุรกรรมสองรายการคือมีจุดตัดระหว่างชุดของตัวแปรการจัดเก็บสัญญาการดำเนินงานตัวอย่างเช่น ในสถานการณ์การถ่ายโอน ธุรกรรมคือการดำเนินการโอนระหว่างผู้ใช้ การใช้การถ่ายโอน (X, Y) เพื่อแสดงอินเทอร์เฟซการถ่ายโอนจากผู้ใช้ X ไปยังผู้ใช้ Y การยกเว้นร่วมกันมีดังนี้:พารามิเตอร์พิเศษร่วมกัน

• :สัญญาอินเตอร์เฟซ

พารามิเตอร์ที่เกี่ยวข้องกับการดำเนินการ "อ่าน/เขียน" ของตัวแปรการจัดเก็บสัญญา ตัวอย่างเช่น อินเทอร์เฟซการถ่ายโอนคือการถ่ายโอน (X, Y) โดยที่ X และ Y เป็นพารามิเตอร์พิเศษร่วมกัน

มิวเท็กซ์

: ในการทำธุรกรรม เนื้อหาที่แยกออกจากกันเฉพาะเจาะจงตามพารามิเตอร์ที่แยกจากกันไม่ได้ ตัวอย่างเช่น อินเตอร์เฟสการถ่ายโอนคือ ทรานแซกชัน (X, Y) และในทรานแซกชันที่เรียกใช้อินเทอร์เฟสนี้ พารามิเตอร์เฉพาะคือ ทรานแซกชัน (A, B) จากนั้นออบเจกต์พิเศษร่วมกันของการดำเนินการนี้คือ [A, B]; ทรานแซกชันอื่น พารามิเตอร์ของการโทรคือ โอน (A, C) จากนั้นวัตถุ mutex ของการดำเนินการนี้คือ [A, C]

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

FISCO-BCOS ให้สองวิธีในการเขียนสัญญาคู่ขนาน วิธีหนึ่งคือสัญญาที่มั่นคงและอีกวิธีหนึ่งคือสัญญาที่คอมไพล์ไว้ล่วงหน้า ที่นี่แนะนำเฉพาะสัญญาความมั่นคงและสัญญาที่คอมไพล์แล้วเหมือนกัน

กรอบสัญญาความมั่นคงคู่ขนาน

เมื่อเขียนสัญญาแบบคู่ขนาน คุณต้องใช้ ParallelContract.sol เป็นคลาสพื้นฐานของสัญญาที่ต้องขนานกัน และเรียกใช้เมธอด registerParallelFunction() เพื่อลงทะเบียนอินเทอร์เฟซแบบขนาน

รหัส ParallelContract เป็นดังนี้:

• ต่อไปนี้เป็นสัญญาการโอนที่เขียนขึ้นตามสัญญากรอบคู่ขนาน:

ตรวจสอบว่าอินเทอร์เฟซเป็นแบบขนานหรือไม่

อินเทอร์เฟซสัญญาคู่ขนานต้องเป็นไปตาม:

ไม่มีการเรียกสัญญาภายนอก

• ไม่มีอินเทอร์เฟซสำหรับการเรียกใช้ฟังก์ชันอื่นๆ

กำหนดพารามิเตอร์การยกเว้นร่วมกัน

ก่อนเขียนอินเทอร์เฟซ คุณต้องกำหนดพารามิเตอร์การยกเว้นร่วมกันของอินเทอร์เฟซ การยกเว้นร่วมกันของอินเทอร์เฟซเป็นการยกเว้นร่วมกันของตัวแปรส่วนกลาง กฎสำหรับการกำหนดพารามิเตอร์พิเศษร่วมกันคือ:

• อินเทอร์เฟซเข้าถึงการแม็ปส่วนกลาง และคีย์ของการแมปคือพารามิเตอร์ที่แยกจากกัน"globalA",• อินเทอร์เฟซเข้าถึงอาร์เรย์ส่วนกลาง และตัวห้อยของอาร์เรย์เป็นพารามิเตอร์พิเศษร่วมกัน

• อินเทอร์เฟซเข้าถึงตัวแปรส่วนกลางของประเภทอย่างง่าย และตัวแปรส่วนกลางของประเภทอย่างง่ายใช้พารามิเตอร์ mutex ร่วมกัน และใช้ชื่อตัวแปรที่แตกต่างกันเป็นวัตถุ mutexตัวอย่างเช่น มีตัวแปรส่วนกลางหลายประเภทในสัญญา และอินเทอร์เฟซที่แตกต่างกันจะเข้าถึงตัวแปรส่วนกลางที่แตกต่างกัน หากคุณต้องการขนานอินเทอร์เฟซต่างๆ คุณต้องกำหนดพารามิเตอร์ร่วมกันในพารามิเตอร์อินเทอร์เฟซที่แก้ไขตัวแปรส่วนกลาง และระบุว่าจะใช้ตัวแปรส่วนกลางใดเมื่อเรียกใช้ เมื่อเรียกใช้ ให้ส่งผ่าน "ชื่อตัวแปร" ของตัวแปรส่วนกลางที่แก้ไขที่สอดคล้องกันไปยังพารามิเตอร์ mutex เพื่อระบุวัตถุ mutex ของธุรกรรมนี้ ตัวอย่างเช่น หากพารามิเตอร์ส่วนกลาง globalA ถูกแก้ไขในฟังก์ชัน setA(int x) ฟังก์ชัน setA จะต้องถูกกำหนดเป็น set(string aflag, int x) และเมื่อเรียกใช้ ให้ส่งผ่าน setA(

10) ใช้ชื่อตัวแปร "globalA" เพื่อระบุว่าวัตถุ mutex ของธุรกรรมนี้คือ globalAstring、address、uint 256、int 256 หลังจากกำหนดพารามิเตอร์ร่วมกันแล้ว ให้กำหนดประเภทพารามิเตอร์และลำดับตามกฎ กฎคือ:

กำหนดประเภทพารามิเตอร์และลำดับ

- พารามิเตอร์อินเทอร์เฟซถูกจำกัดไว้ที่:

(ประเภทอื่น ๆ จะได้รับการสนับสนุนในอนาคต)- พารามิเตอร์พิเศษร่วมกันทั้งหมดจะจัดไว้ที่ด้านบนของพารามิเตอร์อินเทอร์เฟซ。

Khipu

ที่สามารถมองเห็น,

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

ชื่อระดับแรก

ภาพรวม

ซึ่งแตกต่างจาก FISCO-BCOS, Khipu เชื่อว่าไม่สมจริงสำหรับผู้ใช้ในการระบุและทำเครื่องหมายช่วงที่อยู่ที่ความขัดแย้งคงที่จะเกิดขึ้นเมื่อเขียนสัญญาโดยไม่มีข้อผิดพลาด

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

Khipu ได้พยายามอย่างรอบด้านในเรื่องนี้และดำเนินโครงการจนเสร็จสิ้น

รายละเอียดโปรแกรม

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

Khipu แนะนำดัชนีความเท่าเทียมที่นี่ นั่นคือสัดส่วนของธุรกรรมในบล็อกที่สามารถรวมผลลัพธ์โดยตรงโดยไม่ต้องดำเนินการซ้ำ จากการสังเกตการเล่นซ้ำบน Ethereum หลายวันตั้งแต่บล็อกการกำเนิดจนถึงบล็อกล่าสุด Khipu พบว่าอัตราส่วนนี้ (ความขนาน) สามารถเข้าถึง 80% โดยเฉลี่ย

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

ทฤษฎีบทของ Andal

ขีดจำกัดที่คุณสามารถเพิ่มความเร็วให้กับระบบคือสิ่งที่ตรงกันข้ามกับสิ่งที่ไม่สามารถขนานกันได้ นั่นคือ ถ้าคุณสามารถขนานกันได้ 99% ของเวลาทั้งหมด คุณจะสามารถเพิ่มความเร็วได้ถึง 100 เท่า แต่ถ้าคุณสามารถบรรลุการขนานกันได้เพียง 95% คุณก็จะสามารถเร่งความเร็วได้เพียง 20 เท่าเท่านั้น

เครื่องหมายความขัดแย้ง

จากการเล่นซ้ำของธุรกรรมทั้งหมดใน Ethereum ประมาณ 80% ของธุรกรรมสามารถขนานกันได้ และ 20% ไม่สามารถขนานกันได้ ดังนั้น ประสิทธิภาพเฉลี่ยของ Khipu ในการเร่ง Ethereum จึงอยู่ที่ประมาณ 5 เท่า

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

จากการเล่นธุรกรรมซ้ำของ Ethereum mainnet พบว่าที่ที่มีความขัดแย้งจำนวนมาก ส่วนใหญ่เป็นธุรกรรมระหว่างกันที่ดำเนินการโดยการแลกเปลี่ยนในบล็อกเดียวกัน ซึ่งสอดคล้องกับกระบวนการนี้เช่นกัน

Aptos

แผนภูมิการไหลของกระบวนการ

กระบวนการดำเนินการคู่ขนานเฉพาะ

ชื่อระดับแรก

ภาพรวม

Aptos สร้างห่วงโซ่ปริมาณงานสูงโดยใช้ภาษา Move ของ Diem และ MoveVM ทำให้สามารถดำเนินการแบบขนานได้ วิธีการของ Aptos คือการตรวจจับการเชื่อมโยงในขณะที่ต้องโปร่งใสต่อผู้ใช้/นักพัฒนา นั่นคือ ธุรกรรมไม่จำเป็นต้องระบุอย่างชัดเจนว่าส่วนใดของสถานะ (ตำแหน่งหน่วยความจำ) ที่พวกเขาใช้

รายละเอียดโปรแกรม

Aptos ใช้กลไกการดำเนินการแบบขนานโดยใช้กระดาษ Block-STM โดยใช้เวอร์ชันแก้ไขของหน่วยความจำธุรกรรมซอฟต์แวร์ที่เรียกว่า Block-STM

Block-STM ใช้ MVCC (การควบคุมการทำงานพร้อมกันหลายเวอร์ชัน) เพื่อหลีกเลี่ยงความขัดแย้งในการเขียน การเขียนทั้งหมดไปยังตำแหน่งเดียวกันจะถูกจัดเก็บด้วยเวอร์ชันที่มี tx-id และจำนวนครั้งที่ดำเนินการเขียน tx ซ้ำ เมื่อทรานแซกชัน tx อ่านค่าของตำแหน่งหน่วยความจำหนึ่งๆ จะได้รับค่าที่เขียนไปยังตำแหน่งที่ปรากฏก่อน tx จาก MVCC รวมถึงเวอร์ชันที่เกี่ยวข้อง เพื่อพิจารณาว่ามีความขัดแย้งในการอ่าน-เขียนหรือไม่ ใน Block-STM ธุรกรรมจะถูกสั่งซื้อล่วงหน้าภายในบล็อกและแบ่งระหว่างเธรดตัวประมวลผลระหว่างการดำเนินการเพื่อดำเนินการแบบขนาน ในการดำเนินการแบบขนาน สมมติว่าไม่มีการพึ่งพาเพื่อดำเนินการธุรกรรม ตำแหน่งหน่วยความจำที่แก้ไขโดยธุรกรรมจะถูกบันทึก หลังจากดำเนินการแล้ว ผลลัพธ์ของธุรกรรมทั้งหมดจะได้รับการตรวจสอบ ในระหว่างการตรวจสอบความถูกต้อง หากพบว่าธุรกรรมเข้าถึงตำแหน่งหน่วยความจำที่แก้ไขโดยธุรกรรมก่อนหน้า ธุรกรรมนั้นจะไม่ถูกต้อง รีเฟรชผลลัพธ์ของธุรกรรมและดำเนินการธุรกรรมใหม่ กระบวนการนี้จะเกิดขึ้นซ้ำจนกว่าธุรกรรมทั้งหมดในบล็อกจะถูกดำเนินการ Block-STM เพิ่มความเร็วในการดำเนินการเมื่อใช้แกนประมวลผลหลายตัว ความเร่งขึ้นอยู่กับระดับของการพึ่งพาระหว่างธุรกรรม

จะเห็นได้ว่าโครงร่างที่นำมาใช้โดย Aptos นั้นมีความคล้ายคลึงกับ Khipu ที่กล่าวถึงข้างต้นโดยคร่าว ๆ แต่รายละเอียดการใช้งานนั้นแตกต่างกันเล็กน้อย ความแตกต่างหลักมีดังนี้:

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

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

เกณฑ์มาตรฐาน

หลังจากผสานรวม Block-STM แล้ว Aptos ได้สร้างมาตรฐานที่สอดคล้องกันและเปรียบเทียบประสิทธิภาพของบล็อกธุรกรรม 10,000 รายการในกรณีของการดำเนินการตามลำดับและการดำเนินการแบบขนาน ผลลัพธ์มีดังนี้:

ดังที่เห็นได้จากรูปด้านบน Block STM บรรลุความเร็วที่เพิ่มขึ้น 16 เท่าเมื่อเทียบกับการดำเนินการตามลำดับของเธรดเมื่อมีการดำเนินการ 32 เธรดพร้อมกัน ในขณะที่ Block-STM บรรลุความเร็วมากกว่า 8 เท่าภายใต้เงื่อนไขที่มีการแข่งขันสูง

ชื่อระดับแรก

สรุป

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

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

เมื่อพิจารณาถึงการใช้งานด้านวิศวกรรมและปัญหาด้านประสิทธิภาพ OlaVM มักจะนำโซลูชันโมเดลสตอเรจแบบกำหนดเองของ Khipu+ มาใช้ ในขณะที่ปรับปรุงประสิทธิภาพ ให้หลีกเลี่ยงความซับซ้อนที่เกิดจากการเปิดตัว Block-STM และอำนวยความสะดวกในการปรับให้เหมาะสมทางวิศวกรรมที่ดีขึ้นในระยะหลัง

2.FISCO-BCOS Github, FISCO-BCOS

3.Khipu Github, GitHub - khipu-io/khipu: An enterprise blockchain platform based on Ethereum

4.Aptos Github, GitHub - aptos-labs/aptos-core: Aptos is a layer 1 blockchain built to support the widespread use of of blockchain through better technology and user experience.

อ้างถึง:

1. กระดาษ Block-STM: [ 2203.06871 ] Block-STM: ปรับขนาดการดำเนินการของ Blockchain โดยการเปลี่ยนคำสั่งคำสาปให้เป็นคำอวยพรด้านประสิทธิภาพ (arxiv.org)

ชื่อระดับแรก

เกี่ยวกับเรา

Sin7y ก่อตั้งขึ้นในปี 2564 และประกอบด้วยนักพัฒนาบล็อกเชนชั้นนำ เราเป็นทั้งผู้บ่มเพาะโครงการและทีมวิจัยเทคโนโลยีบล็อกเชน สำรวจเทคโนโลยีที่สำคัญและล้ำสมัยที่สุด เช่น EVM, Layer 2, cross-chain, การประมวลผลเพื่อความเป็นส่วนตัว และโซลูชันการชำระเงินอัตโนมัติ ทีมงานเปิดตัวเอกสารไวท์เปเปอร์ OlaVM ในเดือนกรกฎาคม 2022 โดยมีเป้าหมายเพื่อสร้าง ZKVM ที่รวดเร็ว ปรับขนาดได้ และเข้ากันได้กับ EVM เครื่องแรก

บัญชีสาธารณะ WeChat: บาป 7 ปี

เว็บไซต์ทางการ: https://sin 7 y.org/

เอกสารไวท์เปเปอร์: https://olavm.org/

Github：Sin 7 y

ชุมชน: http://t.me/sin 7 y_labs