ลองนึกภาพสิ่งนี้: คุณอยู่ในครัวที่วุ่นวายซึ่งพ่อครัวต้องรอให้คนๆ หนึ่งสับผักให้เสร็จก่อนที่คนต่อไปจะเริ่มอบมันฝรั่ง ฟังดูช้าและไม่มีประสิทธิภาพอย่างน่าผิดหวังใช่ไหม? นั่นคือสิ่งที่การดําเนินการแบบซิงโครนัสเป็นเหมือนในการคํานวณและบล็อกเชน: งานหนึ่งจะต้องเสร็จสิ้นก่อนที่จะเริ่มงานถัดไป ตอนนี้ลองนึกภาพห้องครัวที่ประสานงานกันอย่างดีซึ่งพ่อครัวแต่ละคนทํางานในส่วนต่างๆของอาหารหลายจานพร้อมกันเตรียมส่วนผสมทําอาหารและชุบทั้งหมดในครั้งเดียว นั่นคือการดําเนินการแบบอะซิงโครนัส - งานทํางานพร้อมกันสร้างเวิร์กโฟลว์ที่มีประสิทธิภาพและเร็วขึ้น

ที่จุดทางแยกของการวิวัฒนาบล็อกเชน ความสามารถในการประกอบกันแบบเสียงซิงโครนัสได้กลายเป็นคำศัพท์ที่มีผลเชื่อมต่อระบบชั้นที่ 2 ที่แตกต่างกันบนเครือข่าย Ethereum ด้วยวิธีการนี้สามารถแก้ไขปัญหา UX และ DevEx ที่เลวร้าย ที่แม้แต่การโอนง่ายๆ ระหว่างชั้นที่ 2 อาจใช้เงินตั๋วและใช้เวลาถึง 7 วันการมีส่วนร่วมของวิทาลิคในการอภิปรายเหล่านี้เน้นว่าความบังเอิญสากลไม่จําเป็นต้องเป็นข้อกําหนดสําหรับการแก้ไขปัญหาเหล่านี้ เราเห็นพ้องกันว่าการดําเนินการแปลที่มีประสิทธิภาพไม่จําเป็นต้องเกี่ยวข้องกับความบังเอิญและมีต้นทุนที่แท้จริงในการสร้างและบํารุงรักษาโครงสร้างพื้นฐานแบบซิงโครนัส เราเชื่อว่ามันไม่ใช่ตัวเลือกไบนารีระหว่างทุกอย่างที่เป็นซิงโครนัสหรืออะซิงโครนัส ทั้งสองสามารถอยู่ร่วมกันได้แบบเฉพาะกิจโดยมีแนวโน้มที่จะเปลี่ยนไปทางหลัง

1. การแยกแยะที่เป็นอิสระ

ในการค้นหาประสิทธิภาพในเทคโนโลยีบล็อกเชน การดำเนินการขั้นตอนของสัญญาอัจฉริยะแต่ละรายได้รับความสนใจมากมาย ตามปกติ ประสิทธิภาพของสัญญาอัจฉริยะแต่ละรายถูกจำกัดโดยความสามารถของเครื่องจำลองเสมือน (EVM) เดียว แม้ว่ามีการเปิดใช้ระบบ multi-chain หรือ Layer-2 แล้ว การเสมือนจำลองพร้อมกันเสนอทางออกที่ดีมีความหวัง ทำให้ธุรกรรมของสัญญาอัจฉริยะรายเดียวสามารถดำเนินการได้พร้อมกัน ดังนั้น การใช้งาน CPU cores เพิ่มเติมเพื่อประสิทธิภาพที่ดีขึ้น

Parallel Relay-Execution Distributed Architecture (PREDA) เป็นรูปแบบการเขียนโปรแกรมแบบกระจายการทํางานเชิงขอบเขตและระดับสูงที่ออกแบบมาสําหรับสัญญาอัจฉริยะทั่วไปที่ขนานกันโดยเนื้อแท้บนระบบบล็อกเชนหลาย EVM แบบกระจาย จากมุมมองของระบบ PREDA ทําให้ EVM แบบขนานสามารถย่อยสลายได้และอะซิงโครนัสทําให้สามารถขนานกันได้เต็มรูปแบบของฟังก์ชันสัญญาและเพิ่มการทํางานพร้อมกันของชุดธุรกรรม สิ่งนี้ทําให้มั่นใจได้ว่าอินสแตนซ์ทั้งหมดของ EVM สามารถใช้งานได้เป็นส่วนใหญ่ เพื่อให้ได้ประสิทธิภาพและความสามารถในการปรับขนาดที่ดีที่สุด

ก่อนที่จะตกลงไปในรายละเอียดอย่างละเอียดเรื่องนี้ ให้เรามาชี้แจงก่อนว่าคำศัพท์หลายคำที่อ้างถึงในบทความนี้หมายถึงอะไร

Tx1= ธุรกรรม 1

Tx2= ธุรกรรม 2

เราสมมติว่า,

การดำเนินการของ Tx1 ต้องเปลี่ยนสถานะ A, B, C

การดำเนินการของ Tx2 ต้องเปลี่ยนสถานะ A, สถานะ D, สถานะ E

วิธีการขนานที่ล้ําสมัยสําหรับ EVMs¹ เช่นเดียวกับที่ดําเนินการโดย Sei, Aptos และ Sui พยายามดําเนินการทุกขั้นตอนในทุกธุรกรรมพร้อมกัน ลองนึกภาพการซูมเข้าในฉากธุรกรรมเดียวในระบบเหล่านี้ธุรกรรมจะดําเนินการภายในความสูงหนึ่งบล็อกโดยไม่คํานึงถึงลักษณะของการพึ่งพาข้อมูลที่กระจัดกระจาย (เช่นการเข้าถึงสถานะสัญญาที่แตกต่างกัน) ดังนั้นหากขั้นตอนใด ๆ ของรัฐสัญญาที่เข้าถึงถูกแชร์หรืออัปเดตระหว่างธุรกรรมสองรายการพวกเขาจะถูกระบุว่าเป็นข้อขัดแย้งในการอ่าน - เขียนหรือเขียน - เขียนและไม่สามารถดําเนินการควบคู่กันได้ซึ่งเป็นอุปสรรคต่อปริมาณงานโดยรวมและความสามารถในการปรับขนาดของระบบ สถานการณ์นี้แย่ลงอย่างมากเมื่อกิจกรรมบนโซ่พุ่งสูงขึ้นอย่างกะทันหัน

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

2. การประเมินผล

ธุรกรรมการโอนโทเค็น ETH ในอดีตจะถูกเล่นซ้ําเพื่อประเมิน Sei (V2), Aptos, Sui และ PREDA ตามปริมาณงานและความสามารถในการปรับขนาด โปรดทราบว่าการประเมินของเราใช้ธุรกรรมการโอนโทเค็น ETH ในอดีตในโลกแห่งความเป็นจริงแทนที่จะสร้างชุดธุรกรรมการโอนระหว่างที่อยู่แบบสุ่ม ธุรกรรมแบบสุ่มจะให้ผลการทดลองมากเกินไปมากกว่าประสิทธิภาพในกรณีคําจริงเนื่องจากธุรกรรมในโลกแห่งความเป็นจริงเกี่ยวข้องกับที่อยู่ที่เกี่ยวข้องไม่ทางใดก็ทางหนึ่งซึ่งทําให้เกิดการพึ่งพาข้อมูลจํานวนมาก

การตั้งค่าการทดลองได้แก่:

การเปรียบเทียบในรูปที่ 1 ย้ำความจำเป็นของการนำรูปแบบโปรแกรม PREDA เข้ามา เพื่อให้ได้การปรับปรุงสำคัญในประสิทธิภาพ PREDA สาธิตว่า มี TPS สูงขึ้น 3.3 เท่า ถึง 28.2 เท่า มากกว่า Aptos สำหรับการทำธุรกรรมการโอนเงินประวัติจริงบนเครือข่าย Ethereum

เนื่องจากระบบเหล่านี้ถูกนำมาใช้ในภาษาต่าง ๆ (รวมถึง Go, Rust, และ C++) และเครื่องจำลองเสมือนต่าง ๆ ทำให้เราประเมินความสามารถในการขยายขนาดของระบบต่าง ๆ โดยใช้ค่าความเร็วสัมพันธ์ต่อระบบพื้นฐานของการใช้ EVM เดียว ๆ เพื่อยกเว้นผลกระทบจากการดำเนินการของระบบที่แตกต่างกัน

รูปที่ 1 จำนวนผลลัพธ์ของการประมวลผลสัญญาอัจฉริยะการโอนโทเค็นเทียบเท่าใน TPS บน Sei, Aptos, Sui, และ PREDA

รูปที่ 2. ความเร็วสัมพันธ์สำหรับ Aptos, Sui, Sei และ PREDA สูงกว่าเส้นใต้ของตนเอง

3. โมเดลโปรแกรมมิ่ง

เพื่อให้เข้าใจ PREDA ได้ง่ายสำหรับผู้ที่คุ้นเคยกับ parallel EVM มีระบบการขนานกันสองประเภทที่พบได้ในระบบบล็อกเชน parallel EVM ในปัจจุบัน¹

• การขนส่งแบบอิงตามความมุ่งหวังร่วมกัน ซึ่งรวมถึง Aptos, Sei (V2), และ Monad, ละเว้นความขึ้นตรงระหว่างภาวะของธุรกรรม ดำเนินการและตรวจสอบธุรกรรมพร้อมกัน และย้อนกลับธุรกรรมเพื่อการดำเนินการใหม่ในกรณีของความขัดแย้ง
• การแบ่งแยกแบบเฉียบพลันซึ่งรวมถึง Solana (Sealevel), Sui, และ Sei (V1), ตรวจสอบสถานะที่ขึ้นอยู่กับก่อนที่จะดำเนินการทุกธุรกรรม วิเคราะห์สถานะที่ขึ้นอยู่ของพวกเขา และดำเนินการพร้อมกันเฉพาะธุรกรรมเหล่านั้นโดยไม่มีความขัดแย้ง

ทั้งสองวิธีตามโครงสร้างแบบแชร์ทุกอย่างและจัดการธุรกรรมเป็นรวมทั้งหมดในการควบคุมการแข่งขัน; ขั้นตอนทั้งหมด (เช่นการเข้าถึงสถานะสัญญาต่าง ๆ) ไม่สามารถแยกแยะได้และต้องถูกดำเนินการโดยสะท้อนเวลา@devteam_48518/crystality-the-parallel-evm-model-implementing-shared-nothing-architecture-8d82fc0a836a">Shared-nothing Architecture เพื่อขัดขวางความขึ้นตรงกันของสถานะและรับรองว่าตัวอย่างต่าง ๆ ของ EVM จะไม่เข้าถึงส่วนเดียวกันของสถานะของสัญญา ป้องกันความขัดแย้งในการเขียนอย่างสมบูรณ์

ในส่วนหลัก PREDA นำเสนอ Programmable Contract Scopes เพื่อแยกส่วนสถานะสัญญาเป็นชิ้นย่อยที่ไม่ซ้อนทับกันและสามารถแบ่งเบาๆ และ Asynchronous Functional Relay เพื่ออธิบายการสลับการกระทำของการดำเนินการใน EVM ต่าง ๆ อย่างไม่เชื่อมต่อกันได้

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

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

4. ภาษา

เราได้นำรูปแบบการเขียนโปรแกรม PREDA มาใช้งานเป็นภาษาที่คล้ายกับ C/C++ และ Javascript โดยต่อไปนี้คือฟังก์ชันการโอนโทเค็นที่แบบเรียบง่ายใน Solidity และภาษา PREDA

โค้ด Solidity ในรูปภาพ (a) มีสถานะสัญญา (balances) ที่แทนยอดเงินคงเหลือของที่อยู่ และฟังก์ชันการโอนเงินเพื่อโอนจำนวนที่ระบุของโทเค็นจากผู้ส่งธุรกรรม (msg.sender) ไปยังผู้รับ (payee)

ในการนำไปใช้ใน PREDA ที่แสดงในภาพ (b) คำสำคัญ @addressกำหนดขอบเขตสัญญาที่เป็นไปได้ ที่สถานะของสัญญาที่เป็นของตัวแปรสัญญา (ยอดคงเหลือ) ถูกแบ่งแยกตามที่อยู่ และกระจายและจัดการโดย EVMs คำสำคัญเรลเลย์ระบุการเรลเลย์ฟังก์ชันอย่างไม่ตรงเวลา

มีสามส่วนในการนำไปใช้งาน PREDA ส่วนที่ (1) คือคำสำคัญ@address กําหนดยอดคงเหลือของผู้ใช้โดยให้คําอธิบายสถานะที่ละเอียดและแยกออกจากกันได้ ยอดคงเหลือตัวแปรขอบเขตที่อยู่มีอินสแตนซ์ที่ไม่ซ้ํากันสําหรับที่อยู่ผู้ใช้แต่ละราย อินสแตนซ์ของที่อยู่ผู้ใช้ที่แตกต่างกันจะถูกเข้าถึงและดูแลโดย EVM ที่แตกต่างกันโดยไม่ทับซ้อนกัน ฟังก์ชันการโอนถูกกําหนดในขอบเขตที่อยู่เดียวกันในส่วน (2) ซึ่งเรียกใช้โดยระบุที่อยู่ของผู้ชําระเงินเป็นขอบเขตเป้าหมายเมื่อเริ่มต้นธุรกรรมการโอนโดยผู้ใช้ ในส่วน (3) ในการดําเนินการฝากเงินไปยังผู้รับเงินหลังจากการถอนเงินสําเร็จการส่งต่อจะเริ่มต้นด้วยที่อยู่ของผู้รับเงินเป็นขอบเขตเป้าหมายเพิ่มเงินไปยังยอดคงเหลือของผู้รับเงินและดําเนินการโดย EVM ที่โฮสต์อินสแตนซ์ยอดคงเหลือของที่อยู่ของผู้รับเงิน

กระแสการดำเนินการของธุรกรรมการโอนโทเค็นใน PREDA

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

1. ระหว่างธุรกรรมที่ผู้ใช้เริ่มขึ้น: เนื่องจากสถานะที่แบ่งแยกตามที่อยู่ไม่ซ้อนทับกัน การทำธุรกรรมที่ผู้ใช้เริ่มขึ้นสามารถดำเนินการพร้อมกันโดยไม่มีข้อขัดแย้ง ตัวอย่างเช่น ในสัญญาการโอนโทเค็นที่อัปเดตสถานะของผู้จ่ายต่อที่อยู่ การทำธุรกรรมที่ผู้ใช้เริ่มขึ้นที่แตกต่างกันสามารถทำพร้อมกันได้ทั่ว EVMs
2. ด้วยธุรกรรมรีเลย์: ในสถานการณ์ที่ Bob โอนโทเค็นไปยัง Alice และ Carol ธุรกรรมรีเลย์สําหรับการฝากเงินไปยัง Alice (จาก Bob ไปยัง Alice transfer) สามารถดําเนินการพร้อมกันกับธุรกรรมที่ผู้ใช้เริ่มต้นสําหรับการถอนเงินจาก Bob (ในการโอน Bob ถึง Carol) และการฝากเงินไปยัง Carol เฉพาะกับความสามารถในการสลายตัวของแบบจําลอง PREDA เท่านั้นที่การขนานโดยธรรมชาติในสัญญาอัจฉริยะจะสัมผัสกับระบบบล็อกเชนพื้นฐานทําให้ผู้ใช้เริ่มต้นและถ่ายทอดธุรกรรมสามารถประมวลผลในลักษณะไปป์ไลน์เพื่ออํานวยความสะดวกในการดําเนินการแบบขนาน

ถัดไปและไกลกว่า

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

ความทั่วไปของ PREDA กว้างไกลถึงการใช้งาน@addressเพื่อแยกแยะสถานะของสัญญาโดยที่อยู่ มันช่วยให้สามารถแบ่งส่วนประเภทที่กำหนดเองได้ด้วยคำสำคัญเช่น@type, ที่ชนิดสามารถเป็นชื่อประเภท Solidity พื้นฐานได้เช่น@uintนอกจากนี้ PREDA ยังสนับสนุนสถานะสัญญาที่ไม่ได้แบ่งแยกด้วย @globalโดยการแบ่งแยกการเก็บข้อมูลออกเป็นสถานะต่าง ๆ ที่แตกต่างกัน ทำให้ทุก EVM รักษารายละเอียดต่าง ๆ นี้ได้อย่างสม่ำเสมอ การแบ่งแยกสถานะนี้เพิ่มความยืดหยุ่นและประสิทธิภาพของโมเดลในสัญญาอัจฉริยะที่หลากหลาย

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

คำประกาศ:

1. บทความนี้เป็นการโพสต์ซ้ำจาก [ Medium]. ลิขสิทธิ์เป็นของผู้เขียนต้นฉบับ [PREDA Parallel VMs] หากคุณมีข้อความคัดลอกนี้และต้องการให้ลบ โปรดติดต่อgate Learn Team. ทีมงานจะดำเนินการตอบกลับความกังวลของคุณโดยรวดเร็วตามขั้นตอนที่เกี่ยวข้อง
2. คำประกาศรับผิดชอบ: มุมมองและความคิดเห็นที่แสดงในบทความนี้เป็นเพียงของผู้เขียนเท่านั้น และไม่เป็นที่ปรึกษาการลงทุน
3. ทีมเรียนรู้ Gate ได้แปลบทความเป็นภาษาอื่น ๆ การคัดลอก กระจาย หรือลอกเลียนแบบบทความที่แปลนั้นถือเป็นการฝ่าฝืนห้าม