สรุป

• ความต้องการในการเก็บข้อมูลที่เพิ่มขึ้นนี้เป็นปัญหาที่สำคัญสำหรับโหนด Ethereum
• บางลูกค้าเริ่มตัดแต่งข้อมูลประวัติเพราะข้อจำกัดในการเก็บข้อมูล ทำให้พฤติกรรมการเก็บข้อมูลที่ไม่สอดคล้องกันเกิดขึ้นในระหว่างโหนดเต็มในเครือข่าย
• เพื่อให้แน่ใจว่ามีการจัดการให้สอดคล้องกันในทุก ๆ ลูกค้า การลดขนาดข้อมูลประวัติเป็นเรื่องมาตรฐานใน EIP-4444 และ EIP-4844
• ดังนั้น การกู้คืนสถานะ L1 หรือ L2 ล่าสุดโดยการเล่นข้อมูลประวัติศาสตร์พึงพอใจในบริการนอกเครือข่ายโปรโตคอล กระตุ้นการสำรวจของ Ethereum-aligned solutions ที่มีลักษณะที่มากขึ้น
• เครือข่ายพอร์ทัล Ethereum เป็นเครือข่าย P2P แบบเบา ๆ แบบกระจายทั่วทุกประเภทของข้อมูล Ethereum รวมถึงข้อมูลประวัติ มันถูกออกแบบสำหรับอุปกรณ์ที่มีข้อจำกัดของทรัพยากรและมีบริการ Ethereum JSON-RPC ระบบเครือข่ายประวัติและเครือข่ายสัญญาณเสริมเกือบพร้อมใช้งาน
• เครือข่าย EthStorage เป็นเครือข่ายการเก็บข้อมูลแบบโมดูลที่ได้รับสิทธิในการเก็บข้อมูลสำหรับ BLOBs EIP-4844 โดยเพื่อเก็บ BLOB ผู้ใช้จะเรียกสัญญาเก็บข้อมูล L1put()วิธีด้วย BLOB แฮชและค่าธรรมเนียมใน ETH ค่าธรรมเนียมจะถูกแจกจ่ายเป็นระยะเวลาต่อเนื่องให้ผู้ให้บริการพื้นที่จัดเก็บเมื่อส่งพิสูจน์ที่ถูกต้องของการเก็บข้อมูลของ BLOBs นอกเส้นตามเวลา EthStorage testnet กำลังทำงานบน Ethereum Sepolia testnet พร้อมกับผู้ร่วมชุมชนหลายๆ คนที่พิสูจน์พื้นที่จัดเก็บท้องถิ่นของพวกเขาอย่างเรียบร้อย
• กิจกรรมในอนาคตรวมถึงการพัฒนาเครือข่ายรัฐที่ไม่ centralize, การนำมาใช้พิสูจน์การเก็บข้อมูลสำหรับข้อมูลขนาดเปลี่ยนได้ และการเข้าถึงแบบไม่ centralize โดยตรงจากเบราว์เซอร์

การยอมรับ: ขอบคุณมากที่พายเปอร์ เมริอัม จาก EF, คาร์ธิก ราจู จาก Polychain, เชียง จาก EthStorage สำหรับการให้คำปรึกษาเกี่ยวกับบทความ

พื้นหลัง

เมื่อวันที่ 22 ตุลาคม พ.ศ. 2023 Péter Szilágyi หัวหน้าฝ่ายพัฒนา Go-Ethereum (Geth) ที่มีชื่อเสียงได้แสดงความกังวลอย่างลึกซึ้งบน Twitter เขาชี้ให้เห็นว่าในขณะที่ลูกค้า Geth เก็บรักษาข้อมูลในอดีตทั้งหมดลูกค้า Ethereum อื่น ๆ เช่น Nethermind และ Besu สามารถกําหนดค่าให้ทํางานได้โดยไม่ต้องมีข้อมูล Ethereum ในอดีตเช่นเนื้อหาบล็อกและส่วนหัวในอดีต สิ่งนี้ทําให้ลูกค้าทุกคนไม่สอดคล้องกันและไม่ยุติธรรมกับ Geth มันจุดประกายการอภิปรายและการอภิปรายอย่างเข้มข้นเกี่ยวกับปัญหา Ethereum Storage ภายในแผนงาน Ethereum

ความท้าทายในการเก็บข้อมูล

ทำไม Nethermind และ Besu เลือกจะหยุดเก็บข้อมูลประวัติ? ปัญหาอะไรที่อยู่เบื้องหลังการตัดสินใจนี้? จากมุมมองของฉัน มีสองสาเหตุหลัก:

• ความต้องการในการเก็บข้อมูลสำหรับ Ethereum client กำลังเริ่มที่จะเพิ่มขึ้นอย่างมาก
• ไม่มีสิทธิ์หรือโทษในโปรโตคอลเพื่อเก็บข้อมูลประวัติ Ethereum

เหตุผลแรกมาจากความต้องการเก็บข้อมูลที่เพิ่มขึ้นของ Ethereum client ที่กำลังทำงาน การศึกษาลึกลงเกี่ยวกับความต้องการที่เฉพาะเจาะจง กราฟวงกลมต่อไปนี้แสดงการกระจายต้นทุนเก็บข้อมูลสำหรับโหนด Geth ใหม่ ตามบล็อก 18,779,761 เมื่อวันที่ 13 ธันวาคม 2023

ตามภาพที่แสดง:

• ความต้องการพื้นที่จัดเก็บทั้งหมด: 925.39 GB
• ข้อมูลทางประวัติศาสตร์ (บล็อก/ใบเสร็จ): ประมาณ 628.69 GB
• สถานะใน Merkle Patricia Trie (MPT): ประมาณ 269.74 GB

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

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

ภาพประกอบ: การกำหนดค่า Nethermined เพื่อให้เรียกใช้โหนดโดยไม่มีประวัติของตัวกล่องบล็อก - ประหยัดค่าเก็บข้อมูลราว 460GB ในขณะนี้

คำท้าทายของการจัดเก็บไฟล์ที่คาดว่าจะเพิ่มมากขึ้นกับการอัพเกรดข้อมูลที่ใช้ให้ใช้ Ethereum Data Availability (DA) ที่กำลังจะมาถึงเส้นทางการขยาย Ethereum DA อย่างสมบูรณ์เริ่มต้นด้วย EIP-4844 ใน DenCun ซึ่งนำเสนอวัตถุใหญ่ขนาดคงที่แบบ Binary large object (BLOB) พร้อมกับโมเดลค่าธรรมเนียมอิสระที่รู้จักกันด้วย blobGasPrice แต่ละ BLOB ถูกตั้งค่าที่ 128KB และ EIP-4844 อนุญาตให้แต่ละบล็อกมีได้สูงสุด 6 BLOBs เพื่อเพิ่มประสิทธิภาพในการขยายข้อมูล แผนนี้รวมถึงการนำรหัส 1D Reed-Solomon เข้ามา ทำให้สามารถมี 32 BLOBs ต่อบล็อกในตอนแรก และในที่สุดสามารถมี 256 BLOBs ต่อบล็อกเมื่อขยายอย่างสมบูรณ์

กับ Ethereum DA ที่ทำงานที่ความจุข้อมูลเต็มพร้อมกับ 256 BLOBs ต่อบล็อก โครงข่าย Ethereum DA ประมาณว่าในระยะเวลาหนึ่งปีจะต้องรับประมาณ 80 TB ของข้อมูล ซึ่งเกินกว่าความจุการเก็บข้อมูลของโหนด Ethereum ส่วนใหญ่

โครงการเก็บ Ethereum และผลสืบพันธุ์

Vitalik’sทวีตของ Ethereum roadmap, ซึ่ง Purge จะเกี่ยวข้องกับการจัดเก็บข้อมูลโดยส่วนใหญ่

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

1. EIP-4444: Bound Historical Data in Execution Clients: ข้อเสนอนี้อนุญาตให้ลูกค้าตัดแบบลูกค้าเก่าเกิน 1 ปี โดยสมมติว่าขนาดบล็อกเฉลี่ยคือ 100K, ข้อมูลบล็อกประวัติศาสตร์จะถูกจำกัดที่ประมาณ 250 GB (100K (3600 24 * 365) / 12, given the block time = 12s).
2. EIP-4844: การทำธุรกรรม Shard BLOB: EIP-4844 ละทิ้ง BLOB เก่ากว่า 18 วัน นี่เป็นวิธีการที่มีการเข้าถึงที่รุนแรงกว่า EIP-4444 โดยจำกัดขนาด BLOB ทางประวัติศาสตร์ที่ประมาณ 100 GB ((18 360024)128K 6 / 12, given block time = 12s).

ผลของการตัดแต่งข้อมูลในอดีตจากลูกค้าทั้งหมดคืออะไร? สิ่งสําคัญคือโหนดใหม่ไม่สามารถซิงโครไนซ์กับสถานะล่าสุดผ่าน "full sync" - การซิงโครไนซ์เพื่อเล่นธุรกรรมซ้ําจากบล็อกกําเนิดไปยังบล็อกล่าสุด เราต้องหันไปใช้ "snap sync" หรือ "state sync" เพื่อซิงโครไนซ์สถานะล่าสุดจาก Ethereum peers แทน วิธีการนี้ถูกนําไปใช้แล้วใน Geth และทํางานเป็นการซิงค์เริ่มต้น

ในทํานองเดียวกันผลที่ตามมานี้ยังใช้กับ L2 ทั้งหมดเช่นโหนดใหม่ของ L2 ไม่สามารถเล่นซ้ําสถานะล่าสุดจากแหล่งกําเนิด L2 จาก Ethereum ได้อย่างเต็มที่โดยการเล่นบล็อก L2 ซ้ําจากแหล่งกําเนิด L2 นอกจากนี้ เนื่องจากโหนด L1 ไม่รักษาสถานะ L2 วิธีการ "สแน็ปซิงค์" สําหรับ L2 จึงไม่สามารถรับสถานะ L2 ล่าสุดจาก L1 ได้ ซึ่งทําลายสมมติฐาน L2 ที่สําคัญของการสืบทอดการรับประกันความปลอดภัยของ Ethereum โซลูชันที่คาดการณ์ไว้จะพึ่งพาบริการของบุคคลที่สามเช่นโครงการ Infura / Etherscan / L2 เพื่อจัดเก็บสําเนาข้อมูลหรือสถานะ L2 ในอดีตซึ่งรวมศูนย์ด้วยแรงจูงใจทางอ้อมนอกโปรโตคอล

คำถามหลักที่เรากำลังถาม

• เราสามารถมีทางเลือกที่ดีกว่าในการแยกส่วนการเก็บข้อมูลและการเข้าถึงในปัญหานี้ได้หรือไม่?
• เป็นไปได้ที่จะสร้าง Ethereum-aligned โซลูชั่นที่มีการเชื่อถือลดลง (เช่น บนส่วนบนของสัญญา L1) ด้วยโซลูชั่นกระตุ้นโดยตรงหรือไม่?
• ด้วยทุกสิ่งเหล่านี้ พวกเราสามารถปลูกทางสู่การแก้ไขโดยตรงในโปรโตคอลเพื่อการเก็บข้อมูล Ethereum และเข้าถึงข้อมูลเหล่านี้อย่างเต็มที่ใน Ethereum roadmap หรือไม่?

โซลูชัน

Solution 1: Ethereum Portal Network

เครือข่าย Ethereum Portal ทําหน้าที่เป็นเครือข่ายการเข้าถึงแบบกระจายอํานาจที่มีน้ําหนักเบาไปยังโปรโตคอล Ethereum นําเสนออินเทอร์เฟซ Ethereum JSON-RPC เช่น eth_call, eth_getBlockByNumber มันแปลคําขอ JSON-RPC เป็นคําขอ P2P ไปยังตารางแฮชแบบกระจายคล้ายกับเครือข่าย IPFS ซึ่งแตกต่างจาก IPFS ซึ่งอนุญาตให้จัดเก็บข้อมูลทุกประเภทและมีความอ่อนไหวต่อสแปมเครือข่าย Portal P2P โฮสต์ข้อมูล Ethereum โดยเฉพาะเช่นส่วนหัวและเนื้อหาในอดีต สิ่งนี้ทําได้โดยเทคนิคการตรวจสอบไคลเอ็นต์แบบเบาในตัวภายในเครือข่ายพอร์ทัล

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

การพัฒนาเครือข่าย Portal สอดคล้องกับ falsophy ความหลากหลายของไคลเอนต์ Ethereum ที่เขียนด้วย Rust, JavaScript, Nim, และ Go ระบบบีคันและระบบประวัติพร้อมสำหรับการใช้งานในขณะที่ระบบสถานะกำลังพัฒนาอย่างใต้ความสนใจ ควรระบบ Portal ไม่มีส่วนสนับสนุนโดยตรงสำหรับการเก็บรักษาข้อมูล-ทุกโหนดในเครือข่ายทำงานอย่างมีเจตคติ

ภาพประกอบ: การเรียกใช้เครือข่ายพอร์ทัล (Trin) พร้อมขีดจำกัดพื้นที่จัดเก็บไว้ที่ 100MB

Solution 2: EthStorage Network

เครือข่าย EthStorage เป็นเครือข่ายเก็บข้อมูลแบบกระจายและมีสิทธิในการแรงสร้างสรรค์ที่ออกแบบมาเพื่อเก็บข้อมูล BLOBs ตาม EIP-4844 ที่ได้รับการสนับสนุนจากโปรแกรม ESP

• ความน่าเชื่อถือน้อยที่สุด: ไม่เหมือนกับโซลูชันที่มีอยู่ซึ่งต้องการบริดจ์ข้อมูลแบบรวมศูนย์ EthStorage อาศัยฉันทามติของ Ethereum และรูปแบบความน่าเชื่อถือ $1/m$ ของผู้ให้บริการพื้นที่จัดเก็บข้อมูล EthStorage ที่ไม่ได้รับอนุญาต ขั้นตอนการจัดเก็บ BLOB เป็นเช่นนี้: ผู้ใช้ลงนามในธุรกรรม BLOB-carry ที่ calls_ใส่ (คีย์ blob_idx) _method ของสัญญาการจัดเก็บ สัญญาการจัดเก็บจะบันทึกแฮช BLOB และแจ้งให้ผู้ให้บริการพื้นที่จัดเก็บทราบถึงเหตุการณ์ ผู้ให้บริการพื้นที่เก็บข้อมูลหลังจากได้รับเหตุการณ์แล้วจะดาวน์โหลดและจัดเก็บ BLOB โดยตรงจากเครือข่าย Ethereum DA เพื่อหลีกเลี่ยงปัญหาบริดจ์ข้อมูล
• ปรับค่าเก็บรักษาข้อมูลให้สอดคล้องกับสิทธิแรงจูงใจ: เมื่อโทรput()ในกระบวนการ จำเป็นต้องส่งค่าธรรมเนียมการเก็บ (ผ่านmsg.value) และถูกฝากในสัญญา ค่าธรรมเนียมการจัดเก็บนี้จะถูกแจกจ่ายไปยังผู้ให้บริการการจัดเก็บในระยะเวลาตามที่สำเร็จการส่งมอบและการตรวจสอบพรูฟการจัดเก็บข้อมูล ในเปรียบเทียบกับระบบค่าธรรมเนียมการจัดเก็บข้อมูลใน Ethereum ปัจจุบันที่จ่ายค่าธรรมเนียมการจัดเก็บครั้งเดียวให้กับผู้เสนอ ค่าธรรมเนียมการจัดเก็บที่จ่ายตลอดเวลาจะตามรุ่นโมเดลการกระจายส่วนลดเงินสด - คาดว่าต้นทุนการจัดเก็บลดลงเมื่อเทียบกับ ETH ตลอดเวลา นวัตกรรมสำคัญนี้ที่ถูกนำเสนอโดย EthStorage จะช่วยให้ค่าธรรมเนียมที่ผู้ใช้จ่ายและการมีส่วนร่วมของผู้ให้บริการการจัดเก็บข้อมูลสอดคล้องกันตลอดเวลา
• พิสูจน์การจัดเก็บ: พิสูจน์การจัดเก็บได้รับแรงบันดาลจากการสุ่มข้อมูลที่มีอยู่ในขณะที่การสุ่มใน EthStorage จะถูกดำเนินการต่อกับ BLOBs ตลอดเวลาแทนที่จะเป็นของบล็อกที่เสนอ ในการยืนยันการสุ่มบนเชนอย่างมีประสิทธิภาพ EthStorage ใช้สัญญาอัจฉริยะอย่างหนักและพัฒนาการล่าสุดในเทคโนโลยี SNARK อย่างเต็มที่
• เครือข่ายแบบไม่จำกัดสิทธิ: โหนดใด ๆ ใน EthStorage สามารถรับการจ่ายเงินเป็นผู้ให้บริการพื้นที่จัดเก็บได้เมื่อได้เก็บข้อมูลและส่งพิสูจน์การจัดเก็บอย่างสม่ำเสมอบนเชื่อมโยง

จากมุมมองของความโมดูลาร์ิตี้ของบล็อกเชน ฟังก์ชัน EthStorage ทำหน้าที่เป็น Ethereum Layer 2 แต่รวบรวมค่าธรรมเนียมการจัดเก็บข้อมูลแทนค่าธรรมเนียมการทำธุรกรรม โดยการทำดัชนีบนเชนของ BLOB hashes, EthStorage เป็นชั้นเก็บข้อมูลโมดูลาร์ Ethereum ที่มีความยืดหยุ่นในการจัดเก็บข้อมูลและประหยัดค่าใช้จ่ายอย่างมีนัยสำคัญ - เน้นที่ประมาณ 1000 เท่า

ในเชิงพัฒนา EthStorage ได้รับการผสมกับ EIP-4844 บน Ethereum Sepolia testnet แล้ว มีการทดสอบแรงกดดันบน EthStorage และ Ethereum Sepolia testnet จัดขึ้น โดยมีการเขียน BLOBs ขนาดรวมกว่าร้อยกิกะไบต์ไปยัง EthStorage มากกว่า 50 ผู้เข้าร่วมชุมชนเข้าร่วมเครือข่ายและพิสูจน์พื้นที่เก็บข้อมูลท้องถิ่นของพวกเขาอย่างประสบความสำเร็จ

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

แดชบอร์ดของ EthStorage บน Ethereum Devnet

การคาดการณ์อนาคต

การเก็บรักษา Ethereum ถึงอย่างไรก็ตาม มีความสำคัญอย่างมากภายในระบบนิเวศ Ethereum แม้ว่าเครือข่าย Ethereum กำลังประสบการเจริญอย่างรวดเร็ว การเก็บรักษาและการเข้าถึงข้อมูล Ethereum กลายเป็นความท้าทายที่สำคัญ ในขณะที่เครือข่าย Portal และเครือข่าย EthStorage กำลังอยู่ในช่วงเริ่มต้นของพวกเขา เรามองเห็นทิศทางที่น่าสนใจหลายทิศทางสำหรับระยะยาว:

• การเข้าถึง Ethereum State ที่มีเวลาแฝงต่ําแบบกระจายอํานาจ การเข้าถึงสถานะ Ethereum ในลักษณะกระจายอํานาจและตรวจสอบได้เป็นงานที่สําคัญแต่ท้าทาย ด้วยการตั้งค่า DHT แบบดั้งเดิมการสืบค้นบัญชีมักจะต้องใช้การสืบค้นหลายรายการของโหนด trie ภายในที่เก็บไว้ในโหนด P2P ที่แตกต่างกัน สิ่งนี้มักจะนําไปสู่เวลาแฝงที่ยาวนานมาก วิธีการใช้โครงสร้างของต้นไม้ของรัฐเพื่อเร่งการเข้าถึงเป็นกุญแจสําคัญตามที่ได้รับการแก้ไขโดยเครือข่ายสถานะที่จะเกิดขึ้นของเครือข่าย Ethereum Portal
• การผสานรวมระหว่าง Portal Network และ EthStorage Network: เครือข่าย Portal สามารถขยายการสนับสนุนได้อย่างราบรื่นเพื่อรวม BLOBs ภายในเครือข่าย ซึ่งเป็นขั้นตอนที่ทีม EthStorage ดําเนินการไปแล้วบางส่วน ความก้าวหน้าตามธรรมชาติคือการรวมเครือข่ายเหล่านี้เข้าด้วยกันเพื่อนําเสนอเครือข่าย JSON-RPC แบบกระจายอํานาจที่สามารถโทรสัญญาด้วยการเข้าถึง BLOBs การรวมตรรกะแอปพลิเคชันในสัญญาและที่เก็บข้อมูล BLOB ที่ปรับขนาดโดย EthStorage เราเปิดใช้งาน dApps ใหม่บน Ethereum เช่นเว็บไซต์กระจายอํานาจแบบไดนามิก (เช่น twitter/youtube/wikipedia/etc) แบบกระจายอํานาจ
• การเข้าถึงแบบกระจายอํานาจจากเบราว์เซอร์: คล้ายกับโปรโตคอล ipfs:// ที่ใช้ในการเข้าถึงข้อมูลในเครือข่าย IPFS มีความจําเป็นเพิ่มขึ้นสําหรับโปรโตคอลการเข้าถึง Ethereum-native จากเบราว์เซอร์เพื่อปลดล็อกศักยภาพมหาศาลของข้อมูลที่หลากหลายของ Ethereum ข้อมูลนี้ครอบคลุมสเปกตรัมที่หลากหลายตั้งแต่การเป็นเจ้าของโทเค็นและยอดคงเหลือไปจนถึงภาพ NFT และเว็บไซต์กระจายอํานาจแบบไดนามิกทั้งหมดนี้เกิดขึ้นได้จากความสามารถของสัญญาอัจฉริยะและพื้นที่เก็บข้อมูล Ethereum ในอนาคต ในขอบเขตนี้โปรโตคอล web3:// ตามที่กําหนดไว้ใน ERC-4804/6860 กําลังอยู่ระหว่างการพัฒนาอย่างแข็งขันเพื่อให้บรรลุวัตถุประสงค์นี้
• พิสูจน์ความมั่นคงขั้นสูงสำหรับข้อมูลขนาดเคลื่อนไหว: นอกจาก BLOBs ที่มีขนาดคงที่, การสำรวจพิสูจน์ความมั่นคงขั้นสูงกลายเป็นเรื่องจำเป็นในการแก้ไขข้อมูลขนาดเคลื่อนไหว เช่น บล็อกประวัติหรือออบเจ็กต์สถานะ การพัฒนาอัลกอริทึมที่ซับซ้อนสามารถเพิ่มประสิทธิภาพของการจัดการข้อมูล

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

คำแถลง:

1. บทความนี้ถูกคัดลอกมาจาก [ เทคโนโลยีไหลลึกลึก] ชื่อเรื่องต้นฉบับคือ “Ethereum Storage Roadmap: Challenges and Opportunities”, ลิขสิทธิ์เป็นของผู้เขียนต้นฉบับ [EthStorage] หากคุณมีข้อขัดแย้งใด ๆ เกี่ยวกับการนำเผยแพร่อีกครั้ง กรุณาติดต่อทีม Gate Learn, ทีมจะดำเนินการให้เร็วที่สุดตามขั้นตอนที่เกี่ยวข้อง

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

3. ภาษาอื่น ๆ ของบทความถูกแปลโดยทีม Gate Learn ซึ่งไม่ได้กล่าวถึงในGate.io, บทความที่ถูกแปลอาจจะไม่นำเสนอ แจกจ่าย หรือเลียนแบบ