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

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

Byzantine Fault Tolerance: รากฐานของความปลอดภัยในบล็อกเชน

นักคริปโตจำนวนหลายล้านคนคงเคยได้ยินเรื่อง Byzantine Fault Tolerance แต่ 99.9% ของพวกเขาไม่สามารถบอกความหมายที่แน่ชัดได้

ปกติแล้ว คนที่ศึกษาประวัติการสร้างบิตคอยน์และพบว่า Satoshi Nakamoto ใช้การขุดเพื่อแก้ไขปัญหา Byzantine Fault Tolerance ก็ยังมักขาดความเข้าใจที่ชัดเจนว่าเป็นอย่างไร

ปัญหานี้เกี่ยวข้องกับการขุดหรือไม่? จริง ๆ แล้วไม่

Byzantine Fault Tolerance (BFT) เป็นคำที่มาจากปัญหาวิทยาการคอมพิวเตอร์เชิงทฤษฎีที่รู้จักกันในนามปัญหา Byzantine Generals ซึ่งเป็นสิ่งสำคัญต่อเทคโนโลยีบล็อกเชน ปัญหานี้ถูกนำเสนอครั้งแรกในปี 1982 โดย Leslie Lamport, Robert Shostak, และ Marshall Pease เป็นปัญหาที่เน้นย้ำถึงความยากลำบากในการทำงานร่วมกันในระบบกระจายที่สมาชิกอาจมีความเป็นปฏิปักษ์หรือไม่น่าเชื่อถือ

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

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

โดยวิธีการกลไกการยอมรับข้อเสนอที่เรียกว่า proof-of- work (PoW) Satoshi Nakamoto ผู้เขียนที่ใช้นามแฝงของ Bitcoin ได้แก้ปัญหา Byzantine Generals สำหรับเงินดิจิทัลอย่างแท้จริง นักขุดใน PoW จะแข่งขันกันเพื่อแก้ปัญหาคณิตศาสตร์ที่ท้าทาย ผู้ชนะจะได้โอกาสเพิ่มบล็อกของบล็อกเชนถัดไป เนื่องจากวิธีการนี้มีความสิ้นเปลืองทรัพยากรคอมพิวเตอร์มาก นักขุดจึงมีแรงจูงใจทางการเงินอย่างใหญ่หลวงที่จะปฏิบัติอย่างซื่อสัตย์

วิธีการ PoW ทำงานเพราะ:

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

แต่ PoW ไม่ใช่คำตอบเดียวสำหรับปัญหา Byzantine Generals ในบล็อกเชน เพื่อแก้ไข BFT อย่างมีประสิทธิภาพแหล่งพลังงานอื่นๆ ได้มีการสร้างกลไกยอมรับอื่น ๆ เช่น delegated proof-of-stake (DPoS) และ proof-of-stake (PoS)

ตัวอย่างเช่น Ethereum ใช้กลไก BFT ที่เรียกว่า Gasper เมื่อเปลี่ยนจาก PoW เป็น PoS ซึ่งบางครั้งเรียกว่า "The Merge" ความมั่นใจใน BFT ได้รับโดยการรวม Casper FFG (ระบบ finality ที่ใช้ PoS) กับกฎการเลือกระบบ LMD-GHOST ลดการใช้พลังงานลงอย่างมาก

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

Nonce: ชิ้นส่วนปริศนาการเข้ารหัส

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

แม้ว่าจะดูเหมือนเรียบง่าย แนวคิดของ nonce นั้นสำคัญมากในเทคโนโลยีบล็อกเชน โดยเฉพาะในระบบ proof-of-work เช่น Bitcoin "Nonce" เป็นคำที่ย่อมาจาก "number only used once" และมันเป็นส่วนสำคัญของกระบวนการขุดที่ช่วยยืนยันและตรวจสอบธุรกรรมในบล็อกเชน

ในการขุดบิตคอยน์ nonce เป็นฟิลด์ 32 บิต (4 ไบต์) ที่พบในหัวบล็อก นักขุดปรับเปลี่ยนตัวเลขนี้เพื่อสร้างแฮชหัวบล็อกที่ตรงตามข้อกำหนดเฉพาะ โดยเฉพาะแฮชที่น้อยกว่าค่าที่กำหนดโดยความยากในเครือข่ายปัจจุบัน

กระบวนการขุดทำงานดังนี้ นักขุดจะรวบรวมบล็อกของธุรกรรมที่ค้างอยู่

หัวบล็อกถูกสร้างขึ้น ซึ่งรวมถึงหลายองค์ประกอบ:

• หมายเลขเวอร์ชัน
• แฮชของบล็อกก่อนหน้า
• Merkle root (แฮชที่แทนทุกธุรกรรมในบล็อก)
• เวลาประทับ
• เป้าหมายความยาก
• Nonce (ตั้งค่าเริ่มต้นที่ 0)

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

การเพิ่ม nonce และทำแฮชใหม่จะดำเนินไปจนกว่าจะพบแฮชที่ถูกต้องหรือพื้นที่ nonce หมด 2^32 หรือประมาณ 4 พันล้านความเป็นไปได้ หมดค่านักขุดได้ หากพื้นที่ nonce หมดโดยไม่มีแฮชถูกต้อง นักขุดสามารถเปลี่ยนองค์ประกอบอื่น ๆ ของหัวบล็อก (เช่น เวลาประทับ) และเริ่มต้นใหม่

Nonce ทำหน้าที่สำคัญหลายอย่าง

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

Nonce เป็นตัวแปรที่นักขุดควบคุมเพื่อทำ "งาน" จริงใน proof-of- work การหาร nonce ที่ถูกต้องแสดงว่านักขุดใช้ทรัพยากรคอมพิวเตอร์

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

Nonce ให้ความเป็นธรรมกับนักขุด การหาบล็อกถูกต้องเป็นเรื่องสุ่มพึ่งพากำลังการประมวลผลที่นักขุดมอบให้

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

ฟังก์ชันของ nonces อาจเปลี่ยนไปเมื่อเทคโนโลยีบล็อกเชนพัฒนา สำหรับระบบ proof-of- stake เช่น แนวคิดของการขุดและ nonces ตามที่ใช้ใน PoW ไม่มีอย่างไรก็ตาม ในหลายระบบบล็อกเชน แนวคิดพื้นฐานของการใช้หมายเลขสุ่มเพียงครั้งเดียวเพื่อรับรองความปลอดภัยและความเป็นธรรมยังคงสำคัญ

Rollups: กระบวนการจัดการธุรกรรมของ Layer-2

หากคุณอยู่ในโลก DeFi คุณคงเคยได้ยินเรื่อง rollups แต่โอกาสที่ความรู้ของคุณเกี่ยวกับมันจะเกี่ยวข้องกับโซลูชัน layer 2 เหนือ layer 1 blockchain

ใช่แล้ว, แต่มันยังมีเพิ่มเติมมากกว่านั้น

Rollups ได้กลายเป็นคำตอบที่มีศักยภาพในการเพิ่มขีดความสามารถในการทำธุรกรรมและลดค่าธรรมเนียมขณะที่ระบบบล็อกเชนเช่น Ethereum ประสบปัญหาความสามารถในการขยายตัว Rollups เป็นวิธีการสเกลิงของ layer-2 ที่โพสต์ข้อมูลธุรกรรมบน layer-1 ขณะดำเนินการทำธุรกรรมภายนอกบล็อกเชนหลัก (layer-1)

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

การม้วนแบ่งออกเป็นสองประเภทหลัก:

Optimistic rollups ดำเนินการคำนวณผ่านหลักฐานการโกงในกรณีที่มีการท้าทายและถือว่าธุรกรรมถูกต้องโดยปริยายลักษณะที่สำคัญรวมถึง:

• ถูกกว่าและเร็วกว่า ZK-rollups สำหรับการคำนวณทั่วไป
• การพอร์ตแอปรายปัจจุบันของ Ethereum ง่ายขึ้นเนื่องจากความเข้ากันได้กับ Ethereum Virtual Machine (EVM)
• ระยะเวลาท้าทายมักใช้เวลาหนึ่งสัปดาห์ทำให้ใครก็ตามสามารถท้าทายผลธุรกรรม เช่น Arbitrum และ Optimism.

Zero-knowledge (ZK) rollups สร้างหลักฐานการเข้ารหัสที่เรียกว่า validity proof ที่ยืนยันความถูกต้องของธุรกรรมที่รวมกัน ลักษณะสำคัญอย่างหนึ่งคือการยืนยันบนเชนทันทีของ validity proof ทำให้มั่นใจได้ว่ามีการยืนยันที่รวดเร็วขึ้น สามารถขยายได้มากกว่าที่คาดไว้ใน optimistic roll-ups การเข้ารหัสที่ซับซ้อนมากขึ้นทำให้ยากต่อการนำไปใช้สำหรับการคำนวณทั่วไป เช่น StarkNet และ zkSync.

Roll-ups มีประโยชน์หลายประการ:

Roll-ups สามารถเพิ่มจำนวนธุรกรรมต่อวินาที (TPS)ได้อย่างมากที่เครือข่ายสามารถประมวลผลได้โดยการส่งผ่านการประมวลผลออกไปนอกเครือข่ายหลัก ค่าธรรมเนียมการทำธุรกรรมลดลงเนื่องจากมีการประมวลผลข้อมูลน้อยลงในเครือข่ายหลัก Rollups ยังสืบทอดความปลอดภัยของเครือข่ายหลักเนื่องจากข้อมูลสำคัญยังคงถูกเก็บไว้บน layer-1 โดยเฉพาะอย่างยิ่งกับ ZK-rollups การยืนยันธุรกรรมสามารถทำได้เร็วกว่ามากเมื่อเทียบกับเครือข่ายหลัก

แต่ rollups ก็มีความยากลำบากด้วยเช่นกัน:

ความซับซ้อนทางเทคนิค: การใช้ roll-ups โดยเฉพาะอย่างยิ่ง ZK-rollups เป็นเรื่องยาก ผู้ดำเนินการ roll-up มีความสำคัญมากและอาจก่อให้เกิดผลรวมศูนย์บางส่วน ใน optimistic roll-ups ผู้ใช้อาจต้องรอขณะที่ถอนเงินไปยังเครือข่ายหลักเนื่องจากระยะเวลาท้าทาย

Roll-ups จะมีความสำคัญมากขึ้นในสภาพแวดล้อมของการขยายขนาดบล็อกเชนเมื่อพัฒนาโครงการอย่าง Ethereum 2.0 ซึ่งแสดงให้เห็นถึงความสำคัญของเทคโนโลยีนี้ในอนาคตของบล็อกเชนเมื่อพวกเขาวางแผนที่จะรวมความสามารถในการสเกลแบบ roll-up-centric เป็นส่วนประกอบหลักของแผนที่ทางของพวกเขา

Blobs: ชิ้นส่วนข้อมูลที่กำลังเปลี่ยนแปลง Ethereum

Blobs ตอนนี้กลายเป็นสิ่งใน Ethereum universe. Many consumers, meanwhile, cannot really understand what blobs are. And finally the word becomes one of those you wish you knew, but it's never a good time to explore the tech specs.

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

    Let's fix it, then.

    มาซ่อมกันเถอะ

    Particularly in relation to the forthcoming Dencun upgrade—a mix of Deneb and Cancun upgrades—blobs, short for Binary Large Objects, mark a major shift in Ethereum's scaling road map.

    โดยเฉพาะอย่างยิ่งในส่วนที่เกี่ยวข้องกับการอัปเกรด Dencun ที่กำลังจะมาถึง ซึ่งเป็นการรวมกันของการอัปเกรด Deneb และ Cancun blobs, ชื่อย่อของ Binary Large Objects แสดงถึงการเปลี่ยนแปลงครั้งใหญ่ในแผนที่ทางการขยายของ Ethereum

    Understanding blobs calls for exploring the technical sides of Ethereum's data management and path towards higher scalability.

    การทำความเข้าใจ blobs ต้องการการสำรวจด้านเทคนิคของการจัดการข้อมูลของ Ethereum และเส้นทางสู่ความสามารถในการปรับขยายที่สูงขึ้น

    Blobs in the Ethereum context are big amounts of data away from the execution layer—where smart contracts run—but nevertheless part of the Ethereum ecosystem. Designed as transitory, they stay on the network for eighteen to twenty-25 days before being thrown away.

    Blobs ในบริบทของ Ethereum เป็นปริมาณข้อมูลขนาดใหญ่ที่อยู่นอกชั้นการประมวลผล—ที่ที่สัญญาอัจฉริยะทำงาน—แต่ยังคงเป็นส่วนหนึ่งของระบบนิเวศของ Ethereum ออกแบบมาเพื่อเป็นชั่วคราว พวกเขาจะอยู่ในเครือข่ายเป็นเวลา 18 ถึง 25 วันก่อนที่จะถูกทิ้ง

    Key characteristics of blobs include:

    ลักษณะสำคัญของ blobs ประกอบด้วย:

    1. Size: Each blob can be up to 128 KB in size, significantly larger than the data typically included in Ethereum transactions.
    1. ขนาด: แต่ละ blob มีขนาดสูงสุดถึง 128 KB ใหญ่กว่าข้อมูลที่รวมอยู่ในธุรกรรมของ Ethereum อย่างมีนัยสำคัญ

    2. Purpose: Blobs are primarily intended to serve layer-2 solutions, particularly rollups, by providing a more cost-effective way to post data on the Ethereum mainnet.
    2. วัตถุประสงค์: Blobs มีจุดประสงค์หลักเพื่อให้บริการแก่โซลูชั่นเลเยอร์ 2 โดยเฉพาะอย่างยิ่ง rollups โดยให้วิธีการโพสต์ข้อมูลบน Ethereum mainnet ที่ประหยัดต้นทุนมากขึ้น

    3. Verification: While blobs are not processed by the Ethereum Virtual Machine (EVM), their integrity is verified using a cryptographic technique called KZG commitments.
    3. การตรวจสอบ: แม้ว่า blobs จะไม่ถูกประมวลผลโดย Ethereum Virtual Machine (EVM) ความถูกต้องของพวกเขาจะถูกตรวจสอบโดยใช้เทคนิคการเข้ารหัสที่เรียกว่า KZG commitments

    4. Temporary Nature: Unlike traditional blockchain data that is stored indefinitely, blobs are designed to be temporary, reducing long-term storage requirements.
    4. ลักษณะชั่วคราว: แตกต่างจากข้อมูล blockchain แบบดั้งเดิมที่ถูกจัดเก็บอย่างไม่มีกำหนด blobs ถูกออกแบบมาให้เป็นแบบชั่วคราว ลดความต้องการในการจัดเก็บระยะยาว

    Blobs are intimately related to the idea of "proto-danksharding," an intermediary stage toward complete sharding in Ethereum (we'll discuss this in a minute). Named for its proposers Protolambda and Dankrad Feist, protos-danksharding presents a novel transaction type (EIP-4844) allowing bl blob insertion.

    Blobs มีความเกี่ยวข้องอย่างใกล้ชิดกับแนวคิดของ "proto-danksharding" ซึ่งเป็นขั้นตอนกลางสู่การแยกส่วนอย่างสมบูรณ์ใน Ethereum (เราจะพูดถึงประเด็นนี้ในอีกสักครู่) ชื่อของข้อเสนอนี้มาจาก Protolambda และ Dankrad Feist proto-danksharding นำเสนอประเภทธุรกรรมใหม่ (EIP-4844) ที่อนุญาตให้แทรก_blob

    Here's how blobs work in the context of proto-danksharding:

    นี่คือวิธีการทำงานของ blobs ในบริบทของ proto-danksharding:

    1. Layer-2 solutions (like rollups) generate transaction data.
    1. โซลูชั่นเลเยอร์ 2 (เช่น rollups) สร้างข้อมูลธุรกรรม

    2. This data is formatted into blobs.
    2. ข้อมูลนี้จะถูกจัดรูปแบบเป็น blobs

    3. The blobs are attached to special transactions on the Ethereum mainnet.
    3. Blobs ถูกแนบไปกับธุรกรรมพิเศษบน Ethereum mainnet

    4. Validators and nodes verify the integrity of the blobs using KZG commitments, without needing to process the entire blob data.
    4. ผู้ตรวจสอบและโหนดตรวจสอบความสมบูรณ์ของ blobs โดยใช้ KZG commitments โดยไม่ต้องประมวลผลข้อมูล_blob ทั้งหมด

    5. The blob data is available for a limited time, allowing anyone to reconstruct the layer-2 state if needed.
    5. ข้อมูล_blob จะสามารถใช้งานได้เป็นระยะเวลาจำกัด อนุญาตให้ใครก็ตามสามารถสร้างเลเยอร์ 2 อันใหม่ได้หากจำเป็น

    6. After 18-25 days, the blob data is discarded, but a commitment to the data remains on-chain indefinitely.
    6. หลังจาก 18-25 วัน ข้อมูล_blob จะถูกทิ้ง แต่การกำหนดพันธะสัญญากับข้อมูลนั้นยังคงอยู่บนเชนอย่างถาวร

    Blobs' introduction has various advantages:

    การแนะนำ blobs มีข้อดีหลายประการ:

    1. Reduced Costs: By providing a more efficient way for rollups to post data on Ethereum, blob transactions can significantly reduce fees for layer-2 users.
    1. ลดต้นทุน: โดยการให้วิธีที่มีประสิทธิภาพมากขึ้นสำหรับ rollups ในการโพสต์ข้อมูลบน Ethereum ธุรกรรม blobs สามารถลดค่าธรรมเนียมสำหรับผู้ใช้เลเยอร์ 2 ได้อย่างมีนัยสำคัญ

    2. Increased Scalability: Blobs allow for more data to be included in each Ethereum block without increasing the computational load on the network.
    2. เพิ่มความสามารถในการขยาย: Blobs อนุญาตให้มีข้อมูลมากขึ้นในแต่ละบล็อกของ Ethereum โดยไม่เพิ่มภาระการคำนวณในเครือข่าย

    3. Improved Data Availability: While blob data is temporary, it ensures that layer-2 data is available for challenge periods in optimistic rollups or for users who need to reconstruct the layer-2 state.
    3. การปรับปรุงความพร้อมใช้งานของข้อมูล: แม้ว่าข้อมูล_blob จะเป็นแบบชั่วคราว แต่มันจะรับรองว่าข้อมูลเลเยอร์ 2 พร้อมใช้งานในช่วงเวลาที่ท้าทายใน optimistic rollups หรือสำหรับผู้ใช้ที่ต้องการสร้างเลเยอร์ 2 ขึ้นใหม่

    4. Preparation for Sharding: Proto-danksharding serves as a stepping stone towards full sharding, allowing the Ethereum ecosystem to gradually adapt to new data management paradigms.
    4. การเตรียมการสำหรับการแยกส่วน: Proto-danksharding เป็นเสาหลักสำคัญสู่การแยกส่วนเต็มรูปแบบ อนุญาตให้ระบบนิเวศของ Ethereum ปรับตัวสู่รูปแบบการจัดการข้อมูลใหม่ ๆ อย่างค่อยเป็นค่อยไป

    Blobs' introduction, meantime, also brings difficulties:

    การแนะนำ blobs ในขณะเดียวกันก็มีความยากลำบากเช่นกัน:

    1. Increased Bandwidth and Storage Requirements: Nodes will need to handle larger amounts of data, even if temporarily.
    1. ความต้องการแบนด์วิธและการจัดเก็บที่เพิ่มขึ้น: โหนดจะต้องจัดการกับปริมาณข้อมูลที่ใหญ่ขึ้น แม้ว่าจะเป็นเพียงระยะเวลาชั่วคราว

    2. Complexity: The addition of a new transaction type and data structure increases the overall complexity of the Ethereum protocol.
    2. ความซับซ้อน: การเพิ่มประเภทธุรกรรมใหม่และโครงสร้างข้อมูลทำให้ความซับซ้อนโดยรวมของโปรโตคอล Ethereum เพิ่มขึ้น

    3. Potential Centralization Pressures: The increased resource requirements might make it more challenging for individuals to run full nodes.
    3. ความดันสู่การรวมศูนย์ที่เป็นไปได้: ความต้องการทรัพยากรที่เพิ่มขึ้นอาจทำให้ยากยิ่งขึ้นสำหรับบุคคลในการรันโหนดเต็มตัว

    Blobs and proto-danksharding are a key component in balancing scalability, decentralization, and security as Ethereum keeps developing towards Ethereum 2.0. Blobs provide the path for a more scalable Ethereum ecosystem by offering a more efficient data availability layer, especially helping layer-2 solutions growingly significant in the blockchain scene.

    Blobs และ proto-danksharding เป็นส่วนสำคัญในการสร้างสมดุลระหว่างการปรับขยาย การกระจายศูนย์ และความปลอดภัยในขณะที่ Ethereum พัฒนาไปสู่ Ethereum 2.0 Blobs เปิดทางให้กับระบบนิเวศ Ethereum ที่สามารถขยายได้มากขึ้นด้วยการนำเสนอชั้นความพร้อมใช้งานของข้อมูลที่มีประสิทธิภาพมากขึ้น โดยเฉพาะอย่างยิ่งช่วยเหลือโซลูชั่นเลเยอร์ 2 ที่เริ่มมีความสำคัญในการฉาก blockchain

    ![Crypto terms you need to know](https://media.yellow.com/uploads/000005845686_9956141a57.jpg)

    ## Proto-danksharding: Ethereum's Stepping Stone to Scalability

    ## Proto-danksharding: เสาหินของ Ethereum สู่ความสามารถในการขยาย

    Proto-danksharding was already mentioned above. Let's investigate it more closely.

    Proto-danksharding ถูกกล่าวถึงข้างต้นแล้ว มาสำรวจรายละเอียดเพิ่มเติมกันเถอะ

    Representing a major turning point in Ethereum's scalability road plan, it is sometimes known as EIP-4844 (Ethereum Improvement Proposal 4844). Aiming to drastically lower data costs for roll-ups and other layer-2 scaling solutions, this idea—named for its proposers Protolambda and Dankrad Feist—serves as an intermediary toward true sharding.

    แสดงถึงจุดเปลี่ยนสำคัญในแผนที่ทางการขยายของ Ethereum บางครั้งเรียกว่า EIP-4844 (ข้อเสนอการปรับปรุง Ethereum 4844) มีเป้าหมายเพื่อลดต้นทุนข้อมูลอย่างมากสำหรับ roll-ups และโซลูชั่นการขยายเลเยอร์ 2 อื่น ๆ แนวคิดนี้—ได้รับการตั้งชื่อจากผู้เสนอ Protolambda และ Dankrad Feist—ทำหน้าที่เป็นขั้นตอนกลางสู่การแยกส่วนที่แท้จริง

    First one must comprehend sharding before one can grasp proto-danksharding.

    ก่อนอื่นจะต้องเข้าใจ sharding ก่อนที่จะเข้าใจ proto-danksharding

    Sharding is a method of database partitioning whereby a blockchain is broken out into smaller, more controllable shards. By means of parallel data storage and transaction processing, each shard can theoretically increase the capacity of the network. Implementing full sharding, however, is a difficult task requiring major modifications to the Ethereum protocol.

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

    Proto-danksharding brings many important ideas:

    Proto-danksharding นำเสนอแนวคิดสำคัญหลายประการ:

    1. Blob-carrying Transactions: A new transaction type that can carry large amounts of data (blobs) that are separate from the execution layer.
    1. ธุรกรรมแบบแบกลูกบล็อบ: ประเภทธุรกรรมใหม่ที่สามารถถือข้อมูลจำนวนมาก (blobs) ที่แยกออกจากชั้นการประมวลผล

    2. Data Availability Sampling: A technique that allows nodes to verify the availability of blob data without downloading the entire blob.
    2. การสุ่มตรวจสอบความพร้อมใช้งานของข้อมูล: เทคนิคที่อนุญาตให้โหนดตรวจสอบความพร้อมใช้งานของข้อมูล_blob โดยไม่ต้องดาวน์โหลดข้อมูล_blob ทั้งหมด

    3. KZG Commitments: A cryptographic method used to create succinct proofs of blob contents, enabling efficient verification.
    3. พันธสัญญา KZG: วิธีการเข้ารหัสที่ใช้ในการสร้างหลักฐานที่สั้นของเนื้อหา_blob ช่วยให้การตรวจสอบมีประสิทธิภาพ

    4. Temporary Data Storage: Blob data is only stored by the network for a limited time (18-25 days), after which it can be discarded while maintaining a commitment to the data on-chain.
    4. การจัดเก็บข้อมูลชั่วคราว: ข้อมูล_blob ถูกเก็บไว้โดยเครือข่ายเป็นเวลาจำกัด (18-25 วัน) หลังจากนั้นสามารถทิ้งได้ในขณะที่ยังคงรักษาพันธสัญญากับข้อมูลบนเชน

    Proto-danksharding operates in this manner:

    Proto-danksharding ทำงานในลักษณะนี้:

    1. Layer-2 solutions (like rollups) generate transaction data.
    1. โซลูชั่นเลเยอร์ 2 (เช่น rollups) สร้างข้อมูลธุรกรรม

    2. This data is formatted into blobs (binary large objects).
    2. ข้อมูลนี้จะถูกจัดรูปแบบเป็น blobs (binary large objects)

    3. The blobs are attached to special transactions on the Ethereum mainnet.
    3. Blobs ถูกแนบไปกับธุรกรรมพิเศษบน Ethereum mainnet

    4. Validators and nodes verify the integrity of the blobs using KZG commitments, without needing to process the entire blob data.
    4. ผู้ตรวจสอบและโหนดตรวจสอบความสมบูรณ์ของ blobs โดยใช้ KZG commitments โดยไม่ต้องประมวลผลข้อมูล_blob ทั้งหมด

    5. The blob data is available for a limited time, allowing anyone to reconstruct the layer-2 state if needed.
    5. ข้อมูล_blob จะสามารถใช้งานได้เป็นระยะเวลาจำกัด อนุญาตให้ใครก็ตามสามารถสร้างเลเยอร์ 2 อันใหม่ได้หากจำเป็น

    6. After the retention period, the blob data is discarded, but a commitment to the data remains on-chain indefinitely.
    6. หลังช่วงเวลาการเก็บรักษา ข้อมูล_blob จะถูกทิ้ง แต่การกำหนดพันธะสัญญากับข้อมูลนั้นยังคงอยู่บนเชนอย่างถาวร

    Proto-danksharding has numerous important advantages:

    Proto-danksharding มีข้อดีสำคัญหลายประการ:

    1. Reduced Costs: By providing a more efficient way for rollups to post data on Ethereum, blob transactions can significantly reduce fees for layer-2 users. This could potentially reduce costs by a factor of 10-100x.
    1. ลดต้นทุน: โดยการให้วิธีที่มีประสิทธิภาพมากขึ้นสำหรับ rollups ในการโพสต์ข้อมูลบน Ethereum ธุรกรรม blobs สามารถลดค่าธรรมเนียมสำหรับผู้ใช้เลเยอร์ 2 ได้อย่างมีนัยสำคัญ นี่อาจลดต้นทุนได้เป็น 10-100 เท่า

    2. Increased Scalability: Blobs allow for more data to be included in each Ethereum block without increasing the computational load on the network. Ethereum's data capacity might so rise by up to 100x.
    2. เพิ่มความสามารถในการขยาย: Blobs อนุญาตให้มีข้อมูลมากขึ้นในแต่ละบล็อกของ Ethereum โดยไม่เพิ่มภาระการคำนวณในเครือข่าย ความสามารถในการจัดการข้อมูลของ Ethereum อาจเพิ่มขึ้นได้สูงสุด 100 เท่า

    3. Improved Data Availability: While blob data is temporary, it ensures that layer-2 data is available for challenge periods in optimistic rollups or for users who need to reconstruct the layer-2 state.
    3. การปรับปรุงความพร้อมใช้งานของข้อมูล: แม้ว่าข้อมูล_blob จะเป็นแบบชั่วคราว แต่มันจะรับรองว่าข้อมูลเลเยอร์ 2 พร้อมใช้งานในช่วงเวลาที่ท้าทายใน optimistic rollups หรือสำหรับผู้ใช้ที่ต้องการสร้างเลเยอร์ 2 ขึ้นใหม่

    4. Gradual Protocol Evolution: Proto-danksharding allows the Ethereum ecosystem to adapt to new data management paradigms gradually, paving the way for full sharding in the future.
    4. การวิวัฒนาการโปรโตคอลอย่างค่อยเป็นค่อยไป: Proto-danksharding อนุญาตให้ระบบนิเวศของ Ethereum ปรับตัวสู่รูปแบบการจัดการข้อมูลใหม่ๆ อย่างค่อยเป็นค่อยไป เปิดทางสู่การแยกส่วนเต็มรูปแบบในอนาคต

    However, implementing proto-danksharding also presents challenges:

    อย่างไรก็ตาม การดำเนินการ proto-danksharding ยังมีความท้าทาย:

    1. Increased Complexity: The addition of a new transaction type and data structure increases the overall complexity of the Ethereum protocol.
    1. ความซับซ้อนที่เพิ่มขึ้น: การเพิ่มชนิดธุรกรรมใหม่และโครงสร้างข้อมูลใหม่ทำให้โปรโตคอล Ethereum ซับซ้อนขึ้นโดยรวม

    2. Node Requirements: Nodes will need to handle larger amounts of data, even if temporarily, which could increase hardware requirements.
    2. ความต้อง```

single point of failure is dramatically reduced. Even if one operator is compromised or goes offline, the validator can continue to function.

2. Increased Uptime: With multiple operators, the chances of the validator being available to perform its duties at all times are greatly improved, potentially leading to higher rewards and better network performance.

3. Decentralization: DVT allows for a more decentralized network by enabling smaller operators to participate in validation without taking on the full risk and responsibility of running a validator independently.

4. Slashing Protection: In proof-of-stake systems, validators can be penalized (slashed) for misbehavior. By requiring several operators to concur on activities, DVT can help avoid inadvertent slicing.

However, DVT also presents certain challenges:

1. Complexity: Implementing DVT requires sophisticated cryptographic protocols and coordination between multiple parties, adding complexity to validator operations.

2. Latency: The need for multiple operators to coordinate could potentially introduce latency in validator actions, although this can be mitigated with proper implementation.

3. Trust Assumptions: While DVT reduces single points of failure, it introduces the need for trust between operators of a distributed validator.

4. Regulatory Considerations: The distributed nature of DVT may raise questions about regulatory compliance and liability in some jurisdictions.

DVT is probably going to become more crucial in maintaining their security and decentralization as proof-of-stake networks develop. While various implementations are now under development or early deployment, projects like Ethereum 2.0 are aggressively investigating the inclusion of DVT.

Adoption of DVT could have broad effects on the architecture of proof-of-stake networks, so enabling new types of validator pooling and delegation that strike security, decentralization, and accessibility in balance.

Dynamic Resharding: Adaptive Blockchain Partitioning

Last but not least, let’s talk dynamic resharding. Based on the idea of sharding but adding a layer of flexibility that lets the network react to changing needs in real-time, it offers a fresh method of blockchain scalability.

Often referred to as "the holy grail of sharding" by some blockchain aficionados, this technology promises to solve one of the most enduring issues in blockchain design: juggling network capacity with resource use. Sounds really complicated, right?

Understanding dynamic resharding requires first a comprehension of the fundamentals of sharding:

Adapted for blockchain systems, sharding is a database partitioning method. It entails breaking out the blockchain into smaller, more controllable shards. Every shard may store data in parallel and handle transactions, therefore theoretically increasing the capacity of the network.

Dynamic resharding advances this idea by letting the network change the amount and arrangement of shards depending on present network state.

This flexible strategy presents a number of possible benefits.

The network can guarantee effective use of network resources by building new shards during periods of high demand and merging unused shards during low demand.

Dynamic resharding lets the blockchain expand its capacity without using a hard fork or significant protocol update as network use rises. Redistributing data and transactions among shards helps the network to keep more constant performance throughout the blockchain.

Dynamic resharding can also enable the network to change with unanticipated events as shard breakdowns or demand surges.

The process of dynamic resharding typically involves several key components.

Monitoring System continuously analyzes network metrics such as transaction volume, shard utilization, and node performance. Decision engine uses predefined algorithms and possibly machine learning techniques to determine when and how to reshard the network. Coordination protocol ensures all nodes in the network agree on the new shard configuration and execute the resharding process consistently. As shards are split or combined, safely moves data and state information between them.

Here is a condensed synopsis of possible dynamic resharding applications:

1. The monitoring system detects that a particular shard is consistently processing near its maximum capacity.

2. The decision engine determines that this shard should be split into two to balance the load.

3. The coordination protocol initiates the resharding process, ensuring all nodes are aware of the impending change.

4. The network executes a carefully choreographed process to create the new shard, migrate relevant data, and update routing information.

5. Once complete, the network now has an additional shard to handle the increased load.

While dynamic resharding offers exciting possibilities, it also presents significant technical challenges.

Implementing a system that can safely and efficiently reshard a live blockchain network is extremely complex, requiring sophisticated consensus and coordination mechanisms. Also, ensuring that all pertinent state information is accurately kept and easily available when data flows across shards is a non-trivial issue in state management.

Dynamic resharding has to consider transactions across several shards, which can get more difficult depending on the shard arrangement. Then, the security issues. The resharding procedure itself has to be safe against attacks aiming at network manipulation during this maybe vulnerable operation. The dynamic resharding monitoring and decision-making procedures add extra computational burden to the network.

Notwithstanding these difficulties, various blockchain initiatives are actively looking at and creating dynamic resharding techniques. Near Protocol, for instance, has set up a kind of dynamic resharding in its mainnet so the network may change the amount of shards depending on demand.

Dynamic resharding may become increasingly important as blockchain technology develops in building scalable, flexible networks able to enable general adoption of distributed apps and services.

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

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

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

4. การป้องกันการตัด: ในระบบพิสูจน์การถือหุ้น, ผู้ตรวจสอบอาจถูกลงโทษ (ถูกตัด) สำหรับการประพฤติผิด ด้วยการต้องการให้หลายผู้ดำเนินการยอมรับในกิจกรรม DVT สามารถช่วยหลีกเลี่ยงการตัดที่ไม่ได้ตั้งใจ

อย่างไรก็ตาม DVT ยังมีความท้าทายบางประการ:

1. ความซับซ้อน: การดำเนินการ DVT ต้องการโปรโตคอลคริปโตกราฟิกที่ซับซ้อนและการประสานงานระหว่างหลายฝ่าย เพิ่มความซับซ้อนในการดำเนินการตรวจสอบ

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

3. การสมมติฐานความไว้วางใจ: ในขณะที่ DVT ลดจุดอ่อนจุดเดียว มันก็แนะนำความจำเป็นในการไว้วางใจระหว่างผู้ดำเนินการของตัวตรวจสอบแบบกระจาย

4. ข้อพิจารณาด้านกฎระเบียบ: ลักษณะการกระจายของ DVT อาจก่อให้เกิดคำถามเกี่ยวกับการปฏิบัติตามกฎระเบียบและความรับผิดชอบในบางเขตแดน

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

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

## Dynamic Resharding: Adaptive Blockchain Partitioning

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

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

การเข้าใจ dynamic resharding ต้องเริ่มต้นจากการเข้าใจพื้นฐานของการแบ่งชิ้น:

ปรับแต่งสำหรับระบบบล็อกเชน, การแบ่งชิ้นเป็นวิธีการแบ่งฐานข้อมูล ซึ่งประกอบด้วยการแบ่งบล็อกเชนออกเป็นชิ้นเล็ก ๆ ที่ง่ายต่อการจัดการ ทุกชิ้นอาจจัดเก็บข้อมูลแบบขนานกันและจัดการธุรกรรม ดังนั้นทฤษฎีนี้จะเพิ่มความสามารถของเครือข่าย

dynamic resharding นำแนวคิดนี้มาพัฒนาด้วยการให้เครือข่ายเปลี่ยนจำนวนและการจัดการของชิ้นขึ้นอยู่กับสภาพเครือข่ายปัจจุบัน

กลยุทธ์ที่ยืดหยุ่นนี้นำเสนอประโยชน์ที่หลากหลาย

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

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

dynamic resharding ยังช่วยให้เครือข่ายปรับตัวกับเหตุการณ์ที่ไม่คาดคิด เช่น การเสียของชิ้นหรือการพุ่งของความต้องการ

กระบวนการ dynamic resharding โดยทั่วไปรวมถึงส่วนสำคัญหลายประการ

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

นี่คือสรุปย่อของการประยุกต์ใช้งาน dynamic resharding ที่เป็นไปได้:

1. ระบบตรวจสอบตรวจพบว่าชิ้นหนึ่งกำลังประมวลผลเกือบถึงขีดความสามารถสูงสุด

2. เครื่องยนต์การตัดสินใจตัดสินว่าชิ้นนี้ควรถูกแยกเป็นสองชิ้นเพื่อปรับสมดุลโหลด

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

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

5. เมื่อเสร็จสิ้น เครือข่ายตอนนี้มีชิ้นเพิ่มเติมเพื่อจัดการกับโหลดที่เพิ่มขึ้น

ในขณะที่ dynamic resharding นำเสนอความเป็นไปได้ที่น่าตื่นเต้น, ก็ยังก่อให้เกิดความท้าทายทางเทคนิคที่สำคัญ

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

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

แต่แม้จะมีความยากลำบากเหล่านี้, โครงการบล็อกเชนหลายโครงการกำลังสำรวจและพัฒนาเทคนิค dynamic resharding. Near Protocol ตัวอย่างเช่น ได้ตั้งค่า dynamic resharding แบบหนึ่งใน mainnet เพื่อให้เครือข่ายสามารถเปลี่ยนจำนวนชิ้นได้ขึ้นอยู่กับความต้องการ

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