คำถามยอดนิยมเกี่ยวกับระบบแบบกระจายจากบุคคลที่ไม่มีความรู้ทางเทคนิคคือ “บล็อคเชนของคุณมีกี่ tps” อย่างไรก็ตาม จำนวนที่ให้ในการตอบมักจะไม่ค่อยเหมือนกันกับสิ่งที่ผู้ถามต้องการจะได้ยิน ในความเป็นจริง เขาต้องการถามว่า “บล็อกเชนของคุณจะเหมาะกับความต้องการทางธุรกิจของฉันหรือไม่” และข้อกำหนดเหล่านี้ไม่ใช่ตัวเลขเดียว แต่มีเงื่อนไขมากมาย - นี่คือความทนทานต่อข้อผิดพลาดของเครือข่าย ข้อกำหนดขั้นสุดท้าย ขนาด ลักษณะของธุรกรรม และพารามิเตอร์อื่น ๆ อีกมากมาย ดังนั้นคำตอบสำหรับคำถาม "กี่ tps" จึงไม่น่าจะง่ายและแทบไม่เคยสมบูรณ์เลย ระบบแบบกระจายที่มีโหนดนับสิบหรือหลายร้อยโหนดที่ทำการคำนวณที่ค่อนข้างซับซ้อนสามารถอยู่ในสถานะที่แตกต่างกันจำนวนมากที่เกี่ยวข้องกับสถานะของเครือข่าย เนื้อหาของบล็อกเชน ความล้มเหลวทางเทคนิค ปัญหาทางเศรษฐกิจ การโจมตีบนเครือข่าย และเหตุผลอื่น ๆ อีกมากมาย . ขั้นตอนที่อาจเกิดปัญหาด้านประสิทธิภาพนั้นแตกต่างจากบริการแบบเดิม และเซิร์ฟเวอร์เครือข่ายบล็อกเชนเป็นบริการเครือข่ายที่รวมการทำงานของฐานข้อมูล เว็บเซิร์ฟเวอร์ และไคลเอนต์ฝนตกหนัก ซึ่งทำให้ซับซ้อนมากในแง่ของโปรไฟล์โหลดบนระบบย่อยทั้งหมด : โปรเซสเซอร์, หน่วยความจำ, เครือข่าย, ที่เก็บข้อมูล

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

ขั้นตอนของการร้องขอบริการโดยไคลเอนต์บล็อคเชน

เพื่อที่จะพูดอย่างตรงไปตรงมาเกี่ยวกับคุณภาพของบริการที่ซับซ้อนไม่มากก็น้อย คุณต้องคำนึงถึงไม่เพียงแต่ค่าเฉลี่ย แต่ยังรวมถึงค่าสูงสุด/ต่ำสุด ค่ามัธยฐาน เปอร์เซ็นไทล์ด้วย ตามทฤษฎีแล้ว เราสามารถพูดถึงประมาณ 1000 tps ในบล็อกเชนบางรายการได้ แต่ถ้าธุรกรรม 900 รายการเสร็จสิ้นด้วยความเร็วมหาศาล และ 100 รายการ "ค้าง" เป็นเวลาสองสามวินาที เวลาเฉลี่ยที่รวบรวมจากธุรกรรมทั้งหมดจะไม่ใช่ตัวชี้วัดที่ยุติธรรมอย่างสมบูรณ์สำหรับลูกค้า ซึ่งฉันไม่สามารถทำธุรกรรมให้เสร็จสิ้นได้ภายในไม่กี่วินาที “ช่องโหว่” ชั่วคราวที่เกิดจากการพลาดรอบฉันทามติหรือการแยกเครือข่ายสามารถทำลายบริการที่แสดงประสิทธิภาพที่ยอดเยี่ยมบนม้านั่งทดสอบได้อย่างมาก

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

1. ธุรกรรมเกิดขึ้นบนไคลเอนต์
2. ธุรกรรมได้รับการลงนามกับลูกค้า
3. ลูกค้าเลือกหนึ่งในโหนดและส่งธุรกรรมของเขาไปที่นั่น
4. ลูกค้าสมัครรับการอัปเดตฐานข้อมูลสถานะของโหนด โดยรอให้ผลลัพธ์ของธุรกรรมปรากฏขึ้น
5. โหนดกระจายธุรกรรมผ่านเครือข่าย p2p
6. BP (ผู้ผลิตบล็อก) หลายรายหรือหนึ่งรายประมวลผลธุรกรรมที่สะสม อัปเดตฐานข้อมูลสถานะ
7. BP สร้างบล็อกใหม่หลังจากประมวลผลธุรกรรมครบตามจำนวนที่ต้องการ
8. BP กระจายบล็อกใหม่ผ่านเครือข่าย p2p
9. บล็อกใหม่จะถูกส่งไปยังโหนดที่ไคลเอนต์กำลังเข้าถึง
10. โหนดอัพเดตฐานข้อมูลสถานะ
11. โหนดเห็นการอัปเดตเกี่ยวกับไคลเอนต์และส่งการแจ้งเตือนธุรกรรมให้เขา

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

การเตรียมธุรกรรมทางฝั่งไคลเอ็นต์

เริ่มจากสองประเด็นแรก: ธุรกรรมเกิดขึ้นและลงนามโดยลูกค้า น่าแปลกที่สิ่งนี้อาจเป็นปัญหาคอขวดของประสิทธิภาพบล็อกเชนจากมุมมองของลูกค้า นี่เป็นเรื่องปกติสำหรับบริการแบบรวมศูนย์ ซึ่งใช้การคำนวณและการดำเนินการกับข้อมูลทั้งหมด และลูกค้าเพียงแค่เตรียมคำขอสั้นๆ ที่สามารถขอข้อมูลหรือการคำนวณจำนวนมาก เพื่อให้ได้ผลลัพธ์ที่พร้อมทำ ในบล็อกเชน รหัสไคลเอ็นต์จะมีประสิทธิภาพมากขึ้นเรื่อยๆ และแกนบล็อกเชนจะมีน้ำหนักเบามากขึ้นเรื่อยๆ และงานประมวลผลขนาดใหญ่มักจะถูกถ่ายโอนไปยังซอฟต์แวร์ไคลเอ็นต์ ในบล็อกเชน มีไคลเอนต์ที่สามารถเตรียมธุรกรรมหนึ่งรายการได้เป็นเวลานาน (ฉันกำลังพูดถึง Merkle Proofs หลักฐานที่กระชับ ลายเซ็นเกณฑ์ และการดำเนินการที่ซับซ้อนอื่น ๆ ในฝั่งไคลเอ็นต์) ตัวอย่างที่ดีของการตรวจสอบออนไลน์ที่ง่ายดายและการจัดเตรียมธุรกรรมจำนวนมากบนไคลเอนต์คือหลักฐานการเป็นสมาชิกในรายการตาม Merkle-tree ที่นี่ บทความ.

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

การส่งธุรกรรมและการติดตามสถานะ

ขั้นตอนต่อไปคือการส่งธุรกรรมไปยังโหนด blockchain ที่เลือก และรับสถานะการยอมรับเข้าสู่กลุ่มธุรกรรม ขั้นตอนนี้คล้ายกับการเข้าถึงฐานข้อมูลปกติ โหนดจะต้องบันทึกธุรกรรมในกลุ่มและเริ่มกระจายข้อมูลเกี่ยวกับธุรกรรมผ่านเครือข่าย p2p วิธีการประเมินประสิทธิภาพที่นี่คล้ายกับการประเมินประสิทธิภาพของไมโครเซอร์วิส Web API แบบดั้งเดิม และธุรกรรมในบล็อกเชนสามารถอัปเดตและเปลี่ยนสถานะได้อย่างแข็งขัน โดยทั่วไป การอัปเดตข้อมูลธุรกรรมบนบล็อกเชนบางตัวอาจเกิดขึ้นได้หลายครั้ง เช่น เมื่อสลับระหว่าง chain forks หรือเมื่อ BP ประกาศความตั้งใจที่จะรวมธุรกรรมไว้ในบล็อก การจำกัดขนาดของพูลนี้และจำนวนธุรกรรมในพูลอาจส่งผลต่อประสิทธิภาพของบล็อคเชน หากกลุ่มธุรกรรมถูกเติมจนเต็มขนาดสูงสุดที่เป็นไปได้ หรือไม่พอดีกับ RAM ประสิทธิภาพเครือข่ายอาจลดลงอย่างรวดเร็ว บล็อกเชนไม่มีวิธีการแบบรวมศูนย์ในการป้องกันข้อความขยะจำนวนมาก และหากบล็อกเชนรองรับธุรกรรมปริมาณมากและค่าธรรมเนียมต่ำ ก็อาจทำให้กลุ่มธุรกรรมล้นได้ ซึ่งเป็นอีกปัญหาคอขวดด้านประสิทธิภาพที่อาจเกิดขึ้นได้

ในบล็อกเชน ลูกค้าจะส่งธุรกรรมไปยังโหนดบล็อกเชนใดๆ ที่เขาชอบ โดยปกติแล้วลูกค้าจะทราบแฮชของธุรกรรมก่อนส่ง ดังนั้นสิ่งที่เขาต้องทำคือทำการเชื่อมต่อให้สำเร็จ และหลังจากส่งแล้ว ให้รอให้บล็อกเชนเปลี่ยนแปลง สถานะของมัน ทำให้การทำธุรกรรมของเขาเกิดขึ้นได้ โปรดทราบว่าการวัด "tps" จะทำให้คุณได้ผลลัพธ์ที่แตกต่างกันโดยสิ้นเชิงสำหรับวิธีการเชื่อมต่อกับโหนด blockchain ที่แตกต่างกัน ซึ่งอาจเป็น HTTP RPC ปกติหรือ WebSocket ที่อนุญาตให้คุณใช้รูปแบบ “สมัครสมาชิก” ในกรณีที่สอง ลูกค้าจะได้รับการแจ้งเตือนก่อนหน้านี้ และโหนดจะใช้ทรัพยากรน้อยลง (ส่วนใหญ่เป็นหน่วยความจำและการรับส่งข้อมูล) ในการตอบสนองต่อสถานะธุรกรรม ดังนั้นเมื่อทำการวัด "tps" จำเป็นต้องคำนึงถึงวิธีที่ไคลเอ็นต์เชื่อมต่อกับโหนดด้วย ดังนั้น เพื่อประเมินความเสี่ยงของปัญหาคอขวดนี้ บล็อกเชนมาตรฐานจะต้องสามารถจำลองไคลเอนต์ที่มีทั้งคำขอ WebSocket และ HTTP RPC ในสัดส่วนที่สอดคล้องกับเครือข่ายจริง รวมถึงเปลี่ยนลักษณะของธุรกรรมและขนาดของธุรกรรม

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

การส่งธุรกรรมและการบล็อกผ่านเครือข่าย p2p

ในบล็อกเชน เครือข่ายเพียร์ทูเพียร์ (p2p) ใช้เพื่อถ่ายโอนธุรกรรมและการบล็อกระหว่างผู้เข้าร่วม ธุรกรรมแพร่กระจายไปทั่วเครือข่าย เริ่มต้นจากโหนดใดโหนดหนึ่ง จนกระทั่งไปถึงผู้สร้างบล็อกเพียร์ ซึ่งบรรจุธุรกรรมลงในบล็อก และใช้ p2p เดียวกันในการกระจายบล็อกใหม่ไปยังโหนดเครือข่ายทั้งหมด พื้นฐานของเครือข่าย p2p ที่ทันสมัยที่สุดคือการปรับเปลี่ยนโปรโตคอล Kademlia ต่างๆ ที่นี่ บทสรุปที่ดีของโปรโตคอลนี้และ ที่นี่ - บทความที่มีการวัดต่างๆ ในเครือข่าย BitTorrent ซึ่งสามารถเข้าใจได้ว่าเครือข่ายประเภทนี้มีความซับซ้อนมากกว่าและคาดเดาได้น้อยกว่าเครือข่ายที่กำหนดค่าไว้อย่างเข้มงวดของบริการแบบรวมศูนย์ อีกด้วย, ที่นี่ บทความเกี่ยวกับการวัดตัวชี้วัดที่น่าสนใจต่างๆ สำหรับโหนด Ethereum

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

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

การประมวลผลบล็อคเชนและการอัพเดตฐานข้อมูลสถานะ

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

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

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

การรับการแจ้งเตือนจากลูกค้าเกี่ยวกับการรวมธุรกรรมในบล็อคเชน

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

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

ข้อสรุป

ด้วยเหตุนี้ เราสามารถอธิบายประเภทของการดำเนินการที่ทำบนบล็อกเชนและแบ่งออกเป็นหลายประเภท:

1. การแปลงรหัสลับ การสร้างหลักฐาน
2. เครือข่ายเพียร์ทูเพียร์ ธุรกรรม และการจำลองแบบบล็อก
3. การประมวลผลธุรกรรม การดำเนินการสัญญาอัจฉริยะ
4. ใช้การเปลี่ยนแปลงในบล็อคเชนกับฐานข้อมูลสถานะ อัปเดตข้อมูลเกี่ยวกับธุรกรรมและบล็อค
5. คำขอแบบอ่านอย่างเดียวไปยังฐานข้อมูลสถานะ, blockchain node API, บริการสมัครสมาชิก

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

เมื่อออกแบบและประเมินประสิทธิภาพของบล็อกเชน คุณจะต้องคำนึงถึงประเด็นเหล่านี้ทั้งหมดด้วย ในการดำเนินการนี้ คุณต้องรวบรวมและวิเคราะห์ตัวชี้วัดพร้อมกันจากไคลเอนต์และโหนดเครือข่าย มองหาความสัมพันธ์ระหว่างสิ่งเหล่านั้น ประเมินเวลาที่ใช้ในการให้บริการแก่ลูกค้า คำนึงถึงทรัพยากรหลักทั้งหมด: cpu/หน่วยความจำ/เครือข่าย/ที่เก็บข้อมูล เข้าใจวิธีการใช้และมีอิทธิพลต่อกัน ทั้งหมดนี้ทำให้การเปรียบเทียบความเร็วของบล็อกเชนต่างๆ ในรูปแบบของ “จำนวน TPS” นั้นเป็นงานที่ไร้คุณค่าอย่างยิ่ง เนื่องจากมีการกำหนดค่าและสถานะที่แตกต่างกันจำนวนมาก ในระบบรวมศูนย์ขนาดใหญ่ กลุ่มเซิร์ฟเวอร์หลายร้อยเครื่อง ปัญหาเหล่านี้ยังซับซ้อนและยังต้องมีการรวบรวมตัวชี้วัดที่แตกต่างกันจำนวนมาก แต่ในบล็อคเชน เนื่องจากเครือข่าย p2p สัญญาการประมวลผลเครื่องเสมือน เศรษฐกิจภายใน จำนวนองศา ของอิสรภาพนั้นยิ่งใหญ่กว่ามาก ซึ่งทำให้การทดสอบแม้บนเซิร์ฟเวอร์หลาย ๆ ตัว มันไม่ได้บ่งชี้และแสดงเฉพาะค่าโดยประมาณอย่างยิ่งยวดซึ่งแทบไม่มีความเกี่ยวข้องกับความเป็นจริงเลย

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

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

ที่มา: will.com