HodlX Guest Post ส่งโพสต์ของคุณ
ปัจจุบันปัญหาความสามารถในการปรับขนาดของบล็อกเชนเป็นข้อ จำกัด หลักสำหรับการนำเทคโนโลยีบล็อกเชนมาใช้จำนวนมาก ในการออกแบบบล็อกเชน P2P ที่ไม่ได้รับอนุญาตมาตรฐานที่นำเสนอโดย Satoshi Nakamoto ทุกโหนดจะต้องประมวลผลข้อมูลทั้งหมดในเครือข่าย.
อย่างไรก็ตามโหนดในเครือข่ายมักมีความสามารถที่แตกต่างกัน ในการออกแบบมาตรฐานของ Nakamoto ประสิทธิภาพของเครือข่ายจะถูก จำกัด โดยประสิทธิภาพของโหนดเต็มรูปแบบที่อ่อนแอที่สุดในเครือข่าย.
แนวทางหนึ่งที่ไร้เดียงสาในการปรับขนาดเครือข่ายบล็อกเชนคือการ จำกัด การมีส่วนร่วมของเครือข่ายสำหรับโหนดที่อ่อนแอ ในกรณีนี้เครือข่ายจะอาศัยเฉพาะสิ่งที่เรียกว่า“ โหนดสูง” ที่มีการเชื่อมต่อเครือข่ายที่กว้างและรวดเร็วซึ่งสามารถประมวลผลข้อมูลจำนวนมากได้.
อย่างไรก็ตามเครือข่ายดังกล่าวกลายเป็นศูนย์กลางมากขึ้นอย่างหลีกเลี่ยงไม่ได้เนื่องจากการบำรุงรักษาโหนดสูงมักมีราคาแพงกว่า ในบริบทนี้การปรับขนาดจึงทำได้ด้วยต้นทุนของการกระจายอำนาจซึ่งเป็นที่ทราบกันดีว่าเป็นคุณสมบัติที่มีค่าที่สุดของเครือข่ายบล็อกเชน.
นักวิจัยทั่วโลกได้เสนอข้อเสนอที่แตกต่างกันสำหรับการแก้ปัญหาความสามารถในการปรับขนาด Sharding ถือได้ว่ามีแนวโน้มมากที่สุด ถึงกระนั้นไม่มีวิสัยทัศน์ทั่วไปเกี่ยวกับวิธีการใช้งาน Sharding เพื่อค้นหาการประนีประนอมที่ยอมรับได้ดีที่สุดท่ามกลางพารามิเตอร์ต่างๆของเครือข่าย.
โครงการต่างๆเช่น Ethereum 2.0, Algorand, Cardano, Near และ Zilliqa ได้พัฒนาการออกแบบบล็อกเชนของตนเองโดยอาศัยการแบ่งส่วน อย่างไรก็ตามโครงการทั้งหมดนี้มีรูปแบบการออกแบบที่คล้ายคลึงกัน พวกเขาทั้งหมดอาศัยอัลกอริธึมฉันทามติ Proof-of-Stake (PoS) และการเลือกตัวตรวจสอบความถูกต้องแบบสุ่มหลอกสำหรับคณะกรรมการแบ่งส่วน.
เพื่อที่จะเข้าร่วมในกระบวนการตรวจสอบความถูกต้องของบล็อกภายใต้แนวทางการหักล้างของ PoS ผู้เข้าร่วมทุกคนจะล็อกเหรียญจำนวนหนึ่งไว้ในเงินเดิมพัน ตัวอย่างเช่นใน Ethereum 2.0 หนึ่งสเตคอย่างน้อย 32 เหรียญจะเท่ากับ 1 โหวตในรอบการตรวจสอบบล็อก.
สิ่งสำคัญคือต้องทราบว่าผู้ตรวจสอบความถูกต้องแต่ละคนสามารถทำการเดิมพันหลายครั้งและรวบรวมคะแนนเสียงได้หลายครั้ง ด้วยเหตุนี้ผู้ใช้ที่วางเดิมพันตามจำนวนที่กำหนดอาจกลายเป็นผู้ตรวจสอบความถูกต้องของเศษที่แตกต่างกันจำนวนเท่า ๆ กันตามกลไกการเลือกตั้งคณะกรรมการแบบสุ่มหลอก.
ผู้เสนอ PoS Sharding บางคนมักจะเชื่อมโยงแนวคิดของ“ สเตค” กับ“ ตัวตรวจสอบความถูกต้อง” ฉันคิดว่าผู้อ่านหลายคนได้เห็นพาดหัวข่าวที่น่าดึงดูดว่า testnet ของ coin X ได้ดึงดูด “validators” มากกว่า 20,000 คน.
อย่างไรก็ตามการประมาณนี้ไม่เกี่ยวกับจำนวนผู้เข้าร่วม มันเป็นเรื่องเกี่ยวกับจำนวนเงินเดิมพัน เป็นไปไม่ได้ที่จะรู้ว่าใครเป็นผู้วางเดิมพันเหล่านั้น อาจมีผู้มีส่วนได้ส่วนเสียหนึ่งพันหรือร้อยคน นอกจากนี้ยังเป็นไปได้ว่าการเดิมพันส่วนใหญ่ถูกควบคุมโดยหน่วยงานเดียว ในกรณีนี้เป็นที่ชัดเจนว่าเครือข่ายรวมศูนย์.
ดังนั้นการติดฉลากโดยอ้างว่าเงินเดิมพันดังกล่าวข้างต้นของหน่วยงานเดียวนี้ไม่เพียง แต่สร้างความสับสนและทำให้เข้าใจผิดเท่านั้น แต่ยังเป็นอันตรายอีกด้วย.
แนวทางของเราคือการแยกผู้เข้าร่วมออกจากเงินเดิมพันของพวกเขา เพื่อเป็นตัวอย่างให้เราทำการคำนวณบางอย่าง สมมติว่ามีเศษ D ที่แตกต่างกันในเครือข่ายและผู้เข้าร่วมบางคนเดิมพัน S จำนวนเงินเดิมพัน.
จากนั้นความน่าจะเป็นที่ผู้เข้าร่วมรายนี้จะได้รับเลือกให้เป็นผู้ตรวจสอบความถูกต้องด้วยคะแนนโหวตอย่างน้อยหนึ่งคะแนนในส่วนใดส่วนหนึ่งโดยฟังก์ชันสุ่มหลอกในอุดมคติคือ
นอกจากนี้ยังเป็นความคาดหวังทางคณิตศาสตร์ของฟังก์ชันที่บรรลุ 1 หากผู้เข้าร่วมเป็นผู้ตรวจสอบความถูกต้องและ 0 ในกรณีตรงกันข้าม ผลรวมของฟังก์ชันเหล่านี้ในส่วนของเศษทั้งหมดคือจำนวนชาร์ดที่ผู้เข้าร่วมตรวจสอบความถูกต้อง.
ดังนั้นความคาดหวังทางคณิตศาสตร์ของจำนวนชิ้นส่วนที่ตรวจสอบความถูกต้องโดยผู้เข้าร่วมจะได้รับจากสูตร:
ตัวอย่างเช่นใน Ethereum 2.0 testnet จำนวนชาร์ด D คือ 64 ตามสูตรผู้เข้าร่วมที่ล็อก 44 สเตคจะตรวจสอบความถูกต้องโดยเฉลี่ย 32 ชาร์ด.
หมายความว่าโดยเฉลี่ยแล้วผู้เข้าร่วมนี้จะจัดการ 32 ชาร์ดหรือครึ่งหนึ่งของข้อมูลในเครือข่าย ผู้เข้าร่วมคนนั้นจะดาวน์โหลดและประมวลผลข้อมูลครึ่งหนึ่งในเครือข่าย อาจมีคนเถียงว่าครึ่งหนึ่งไม่ใช่ทั้งหมด PoS Sharding ได้รับการโฆษณาว่าเป็นความก้าวหน้าครั้งสำคัญในการลดภาระของโหนดที่อ่อนแอในระบบ.
อย่างไรก็ตามนี่ไม่ใช่การปรับปรุงครั้งใหญ่และผู้เข้าร่วมดังกล่าวยังคงต้องดำเนินการกับภาระงานจำนวนมากเพื่อดูแลระบบ ดังนั้นโหนดที่อ่อนแอจะไม่สังเกตเห็นการปรับปรุงประสิทธิภาพที่คาดการณ์ไว้.
อาจมีคนแย้งว่าไม่จำเป็นต้องล็อก 44 สเตค หากผู้เข้าร่วมมีทรัพยากรที่ จำกัด พวกเขาสามารถล็อคหนึ่งหรือสองเดิมพันและประมวลผลหนึ่งหรือสองชิ้น น่าเสียดายที่การออกแบบ PoS sharding ถือว่าคณะกรรมการชิ้นส่วนจะถูกสับเปลี่ยนทุกยุคเพื่อป้องกันการโจมตีจากศัตรูที่ปรับตัวได้.
ฝ่ายตรงข้ามที่ปรับเปลี่ยนได้ทำให้โหนดเป้าหมายเสียหายตัวอย่างเช่นผ่านการโจมตี DDoS หรือ eclipse โหนดที่เสียหายจะสูญเสียเงินเดิมพันเนื่องจากการลงโทษพื้นฐานและออกจากคณะกรรมการ ในท้ายที่สุดนักแสดงที่ประสงค์ร้ายสามารถเข้าควบคุมคณะกรรมการทั้งหมดได้ ใน
ตรงกันข้ามในระบบ PoW โหนดสามารถทำงานต่อได้ทันทีหลังการโจมตี.
ดังนั้นการสับคณะกรรมการจึงเป็นส่วนสำคัญของ PoS sharding หลังจากการสับเปลี่ยนดังกล่าวคณะกรรมการจะถูกเลือกอีกครั้งและผู้เข้าร่วมจะได้รับมอบหมายให้เป็นผู้ตรวจสอบความถูกต้องให้กับชิ้นส่วนอื่น ๆ.
น่าเสียดายที่เพื่อดำเนินการตามหน้าที่ในการตรวจสอบความถูกต้องและตรวจสอบธุรกรรมอย่างตรงไปตรงมาผู้เข้าร่วมที่มีสเตคหนึ่งจะต้องดาวน์โหลดสถานะของชิ้นส่วนนั้น นี่เป็นปริมาณการจราจรที่ค่อนข้างมาก.
ผู้เข้าร่วมควรทราบธุรกรรมที่ยังไม่ได้ใช้ทั้งหมดหรือยอดคงเหลือในบัญชีทั้งหมดเพื่อที่จะทำงานต่อไปได้ อีกทางเลือกหนึ่งคือการสูญเสียเงินเดิมพันหรือกลายเป็นหุ่นเชิดของโหนดอื่นซึ่งมีข้อมูลที่จำเป็น.
ให้เราทำการคำนวณบางอย่าง สมมติว่าทุกสเตคถูกล็อกไว้ประมาณ 180 วันและทุกสเตคจะได้รับเลือกให้เป็นผู้ตรวจสอบความถูกต้องวันละครั้ง สังเกตว่าสูตรด้านบนทำงานได้อย่างสมบูรณ์ในกรณีนี้เช่นกัน เราตั้งค่า D = 64 และ S = 180.
โดยเฉลี่ยแล้วผู้เข้าร่วมรายนี้จะดาวน์โหลดสถานะ 60 จาก 64 ชาร์ด นั่นคือเกือบทั้งเครือข่าย นี่คืออีกตัวอย่างหนึ่ง สมมติว่าผู้เข้าร่วมล็อค 4 เดิมพัน จากนั้นหลังจาก 11 วันพวกเขาจะดาวน์โหลดชาร์ดเกือบ 32 รายการซึ่งเป็นจำนวนครึ่งหนึ่งของสถานะของเครือข่าย.
อย่างไรก็ตามเราพิจารณาภาระที่เกิดจากผู้มีส่วนได้ส่วนเสียรายย่อย อีกด้านหนึ่งของเหรียญแสดงถึงผู้มีส่วนได้ส่วนเสียที่ร่ำรวยซึ่งมีเงินเดิมพันมากมาย ลองนึกภาพเซิร์ฟเวอร์ที่มีหน่วยประมวลผล 64 หน่วยที่ตรวจสอบความถูกต้อง 64 ชาร์ดโดยที่แต่ละหน่วยประมวลผลจะตรวจสอบชาร์ดของตน การจัดการเซิร์ฟเวอร์นี้เป็นงานที่ค่อนข้างง่าย.
เมื่อใดก็ตามที่เกิดการสับเปลี่ยนคณะกรรมการไม่จำเป็นต้องดาวน์โหลดหรืออัปเดตสถานะชาร์ดใด ๆ จำเป็นต้องสับคีย์ที่เกี่ยวข้องกับเงินเดิมพันระหว่างหน่วยประมวลผลตามผลการเลือกตั้งของคณะกรรมการอีกครั้ง.
ดังนั้นการดำเนินการที่มีค่าใช้จ่ายสูงสำหรับผู้มีส่วนได้ส่วนเสียขนาดเล็กจึงค่อนข้างถูกสำหรับผู้มีส่วนได้ส่วนเสียรายใหญ่ที่ใช้หน่วยประมวลผล 64 หน่วยบนเซิร์ฟเวอร์ ฉันคิดว่าผู้อ่านที่เอาใจใส่เข้าใจดีว่าเซิร์ฟเวอร์ดังกล่าวเป็นโหนดเต็มรูปแบบ ภายใต้การออกแบบนี้ผู้ที่สามารถใช้งานโหนดเต็มรูปแบบนี้จะประหยัดเงินได้มากขึ้นในการรับส่งข้อมูลเครือข่าย.
อาจมีคนโต้แย้งว่า 60 น้อยกว่า 64 และครึ่งหนึ่งของรัฐไม่ใช่ทั้งรัฐ อย่างไรก็ตามมันไม่ใช่วิธีแก้ปัญหาที่รอคอยมานานซึ่งคุ้มค่ากับ“ งบประมาณพันล้านดอลลาร์และการพัฒนา 10 ปี”.
กระนั้นผู้มีส่วนได้ส่วนเสียขนาดเล็กที่มีโหนดที่อ่อนแอต้องจัดการข้อมูลจำนวนมากหรือปริมาณการใช้งานเครือข่ายจำนวนมาก ข้อกำหนดนี้เอาชนะจุดประสงค์ของการปรับขนาดผ่านการชาร์ดโดยสิ้นเชิง.
โครงการต่าง ๆ ที่กำหนดเป้าหมายในการใช้การแบ่งสัดส่วนการพิสูจน์ผลการเดิมพันอาจมีจำนวนชิ้นส่วนที่แตกต่างกันช่วงเวลาสับเปลี่ยนของคณะกรรมการและช่วงเวลาในการล็อกสเตค.
อย่างไรก็ตามเราอาจสังเกตเห็น “ประสิทธิภาพต่ำกว่าความคาดหมาย” สำหรับชุดพารามิเตอร์ที่ใช้งานได้จริง เมื่อใดก็ตามที่โครงการดังกล่าวเผชิญกับ“ ความล่าช้าในการเปิดตัว” ทีมงานหลักมักจะนำเสนอว่าเป็นปัญหาในการพัฒนา อย่างไรก็ตามตามที่ฉันได้อธิบายไปแล้วข้อบกพร่องของการออกแบบธรรมดาที่มีอยู่ใน PoS sharding.
ที่น่าสนใจก็คือไม่จำเป็นต้องใช้ Sharding ตามหลักฐานการเดิมพันเพื่อลดภาระงานของผู้เข้าร่วมรายย่อย ลองนึกภาพว่าโครงการเสนอการแบ่งส่วนโดยอาศัยหลักฐานการทำงาน.
ตรงกันข้ามกับการออกแบบ PoS มีการตั้งค่าที่สะดวกสำหรับโหนดที่อ่อนแอเพื่อให้สามารถจัดการปริมาณงานได้ ในกรณีนี้ผู้เข้าร่วมทั้งหมดจะได้รับรางวัลตามสัดส่วนของความพยายามในการบำรุงรักษาเครือข่าย เป็นผลให้การรันโหนดที่อ่อนแอยังคงทำกำไรได้.
ข้อดีอีกอย่างของ PoW sharding คือการไม่มีปัญหาตามแบบฉบับของ PoS นั่นคือไม่มีอะไรในการโจมตีสเตคและการโจมตีด้วยการบดสเตค ด้วยเหตุนี้การพิสูจน์ผลงานจึงทำให้มีการแลกเปลี่ยนที่ดีกว่าสำหรับการปรับขนาดมากกว่าที่จะทำได้.
Vinod Manoharan เป็นผู้ประกอบการด้านเทคโนโลยีและเป็นผู้ก่อตั้งและซีอีโอของ Jax Multiversal Holdings, บริษัท โฮลดิ้งที่มีผลงานรวมถึง บริษัท เกมออนไลน์เกตเวย์การชำระเงินและ บริษัท เทคโนโลยีบล็อกเชน Manoharan ยังเป็นผู้ก่อตั้ง JAX.Network, การเริ่มต้นเทคโนโลยีในยูเครนที่มุ่งเน้นไปที่เทคโนโลยี Blockchain และโดยเฉพาะอย่างยิ่งการแก้ปัญหา Blockchain Scalability Trilemma ที่น่าอับอาย.
ภาพเด่น: Shutterstock /wirow
