ภาวะที่กลืนไม่เข้าคายไม่ออกของการระเบิดของรัฐของ Blockchain

ชื่อเรื่องรอง

ชั้นที่ 1 ควรมุ่งเน้นไปที่สถานะ

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

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

ในการหาว่าเลเยอร์ 1 ควรเน้นที่สิ่งใด ก่อนอื่นเราต้องหาความแตกต่างระหว่างมันกับโปรโตคอลเลเยอร์บน ที่มาของเลเยอร์ 2 เกี่ยวข้องกับการค้นพบของเราว่าประสิทธิภาพของ public chain (ในที่นี้หมายถึง blockchain ที่ไม่มีสิทธิ์) ไม่เพียงพอ และเป็นการยากที่จะขยายเพื่อตอบสนองความต้องการของเศรษฐกิจการเข้ารหัสทั้งหมด พัฒนาชุดของ Layer อย่างช้าๆ 2 โปรโตคอลที่สามารถรักษาความปลอดภัยด้วยบล็อกเชน เช่น ช่องทางการชำระเงิน, พลาสมา เป็นต้น

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

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

ชื่อเรื่องรอง

สถานะคืออะไร

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

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

ประวัติ: ทั้งข้อมูลบล็อกและข้อมูลธุรกรรมเป็นประวัติ และประวัติเป็นเส้นทางจาก Genesis ไปยังสถานะปัจจุบัน

สถานะ (เช่น ตอนนี้): ผลลัพธ์สุดท้ายที่เกิดจากโหนดหลังจากประมวลผลบล็อกและธุรกรรมทั้งหมดตั้งแต่ Genesis จนถึงความสูงปัจจุบัน สถานะเปลี่ยนแปลงอยู่เสมอด้วยการเพิ่มบล็อก และธุรกรรมเป็นสาเหตุของการเปลี่ยนแปลง

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

ชื่อเรื่องรอง

ตัวอย่าง: ประวัติและสถานะของ Bitcoin

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

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

จะเห็นได้ว่าเอาต์พุต (TXO, Transaction Output) ของธุรกรรม Bitcoin เป็น UTXO ที่กล่าวถึงข้างต้นทุกประการ และ UTXO เป็นเพียง TXO ในขั้นตอนพิเศษ (ยังไม่ได้ใช้) เนื่องจากส่วนประกอบที่ประกอบกันเป็นสถานะของ Bitcoin (UTXO) ก็เป็นส่วนประกอบที่ประกอบกันเป็นธุรกรรม (TXO) ด้วย

ดังนั้น Bitcoin จึงมีคุณสมบัติที่ยอดเยี่ยม: สถานะ ณ เวลาใด ๆ เป็นส่วนย่อยของประวัติศาสตร์ และประเภทข้อมูลที่มีอยู่ในประวัติศาสตร์และสถานะนั้นมีมิติเดียวกัน ประวัติของการทำธุรกรรม (การรวบรวมธุรกรรมที่เป็นแพ็คเกจทั้งหมด นั่นคือการรวบรวม TXO ที่สร้างขึ้นทั้งหมด) เป็นประวัติของสถานะ (การรวบรวม UTXO ที่สอดคล้องกับแต่ละบล็อก ซึ่งเป็นการรวบรวม TXO ที่สร้างขึ้นทั้งหมดด้วย) ประวัติของ Bitcoin มีการทำธุรกรรมเท่านั้น

ชื่อเรื่องรอง

อีกตัวอย่างหนึ่ง: ประวัติและสถานะของ Ethereum

สถานะของ Ethereum หรือที่เรียกว่า "สถานะของโลก" หมายถึงสถานะปัจจุบันของบัญชีแยกประเภท Ethereum สถานะของ Ethereum คือ Merkle tree ที่ประกอบด้วยบัญชี (บัญชีคือ leaf) บัญชีไม่เพียงแต่บันทึกยอดคงเหลือ (แสดงจำนวน ether จำนวนหนึ่ง) แต่ยังรวมถึงข้อมูลสัญญาด้วย (เช่น ข้อมูลของ cat ที่เข้ารหัสแต่ละตัว) สถานะของ Ethereum ถือได้ว่าเป็นบัญชีแยกประเภทขนาดใหญ่ คอลัมน์แรก ของบัญชีแยกประเภทคือชื่อ คอลัมน์ที่สอง คือยอดคงเหลือ และคอลัมน์ที่สามคือข้อมูลสัญญา

ประวัติของ Ethereum ยังประกอบด้วยธุรกรรมต่าง ๆ โครงสร้างหลักภายในธุรกรรมคือ:

ถึง: บัญชีอื่นซึ่งเป็นตัวแทนของผู้ส่งธุรกรรม

มูลค่า: ปริมาณของอีเธอร์ที่ดำเนินการโดยการทำธุรกรรม

ข้อมูล: ข้อมูลใด ๆ ที่ดำเนินการโดยการทำธุรกรรม

วิธีที่ธุรกรรมเปลี่ยนสถานะคือ EVM ค้นหาบัญชีเป้าหมายที่ธุรกรรมถูกส่งไป

1. คำนวณยอดคงเหลือใหม่ของบัญชีเป้าหมายตามมูลค่าของธุรกรรม

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

3. สร้าง leaf ใหม่เพื่อจัดเก็บ state ใหม่ และอัพเดต state Merkle tree

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

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

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

ทุกบล็อกและทุกบัญชีใน Ethereum จะยังคงใช้พื้นที่เก็บข้อมูลของโหนดต่อไป โหนด Ethereum มีหลายโหมดเมื่อซิงโครไนซ์ ในโหมด Archive ประวัติและสถานะทั้งหมดจะถูกรักษาไว้ รวมถึงประวัติธุรกรรมและสถานะในอดีต ขนาดรวมกันของข้อมูลทั้งหมดเกิน 2TB ในโหมดเริ่มต้น สถานะประวัติจะถูกตัดออก และเฉพาะธุรกรรมในอดีตและสถานะปัจจุบันเท่านั้นที่จะถูกเก็บไว้ภายในเครื่อง ข้อมูลทั้งหมดคือประมาณ 170G ซึ่งขนาดประวัติการทำธุรกรรมคือ 150G และขนาดสถานะปัจจุบันคือ 10G

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

ปล. ความเข้าใจผิดที่พบบ่อยคือ "ขนาดบล็อกเชน" ของ Ethereum เกิน 1T จากการวิเคราะห์ข้างต้น เราจะเห็นว่า "ขนาดบล็อกเชน" เป็นคำจำกัดความที่คลุมเครือมาก หากนับประวัติสถานะ มันเกินจริง แต่สำหรับโหนดทั้งหมด จะไม่มีปัญหาในการลบสถานะประวัติ เพราะตราบใดที่ มี Genesis และประวัติการทำธุรกรรม สถานะในอดีตสามารถคำนวณใหม่ได้ตลอดเวลา (โดยไม่คำนึงถึงเวลาที่ต้องใช้ในการคำนวณ)

ข้อมูลที่มีความหมายอย่างแท้จริงคือขนาดของข้อมูลที่จำเป็นสำหรับโหนดแบบเต็ม Bitcoin คือ 200G และ Ethereum คือ 170G โดยพื้นฐานแล้วทั้งสองจะเหมือนกันและสามารถติดตั้งบนโฮสต์คลาวด์ที่กำหนดค่าโดยเฉลี่ย การลดลงนี้ไม่ได้เกิดจากพื้นที่เก็บข้อมูลที่เพิ่มขึ้น (สาเหตุที่แท้จริงคือค่าใช้จ่ายในการคำนวณที่การซิงโครไนซ์)

ชื่อเรื่องรอง

โศกนาฏกรรมของ (Storage) Commons: โศกนาฏกรรมของ Commons เวอร์ชั่น Blockchain

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

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

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

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

เนื่องจากการมีอยู่ของ DApps ต่างๆ บน Ethereum โศกนาฏกรรมของ (Storage) Commons จึงค่อนข้างรุนแรงกว่า ตัวอย่างเช่น ณ เวลาบล็อก 5700001 (30 พฤษภาคม 2018) สัญญาที่ใช้มากที่สุด 5 สัญญาได้แก่:

• EtherDelta,     5.09%

• IDEX,     4.17%

• CryptoKitties,     3.05%

• ENS,     1.92%

• EOS Sale, 1.73%

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

การระเบิดของรัฐ

การระเบิดของรัฐ

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

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

จากกราฟนี้ เราจะเห็นว่าในขณะที่เครือข่าย Ethereum พัฒนาขึ้น จำนวนข้อมูลสถานะที่สะสมเพิ่มขึ้นแบบทวีคูณ ต้องใช้เวลา 10 ปีกว่าที่ข้อมูลสถานะของ Bitcoin จะสะสมจาก 0 ถึง 3G; ต้องใช้เวลา 4 ปีกว่าที่ข้อมูลสถานะของ Ethereum จะสะสมจาก 0 ถึง 10G; และนี่คือก่อนที่เราจะแก้ปัญหาความสามารถในการปรับขนาดได้ และ blockchain ยังคงอยู่ อัตราการเติบโตของกรณีเทคโนโลยีเฉพาะ

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

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

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

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

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

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

1. ค่าเช่าที่ชำระล่วงหน้าจะถูกใช้จนหมดในวันหนึ่ง จะจัดการกับสถานะการครอบครองในเวลานี้ได้อย่างไร? เพื่อแก้ปัญหานี้ Storage Rent ต้องการกลไกต่างๆ เช่น การกู้คืน ซึ่งเพิ่มความซับซ้อนของการออกแบบ ลดการไม่เปลี่ยนแปลงของสัญญาอัจฉริยะลงอย่างมาก และนำปัญหามาสู่ประสบการณ์ของผู้ใช้

2. โมเดลสถานะของ Ethereum เป็นโมเดลสถานะที่ใช้ร่วมกัน ไม่ใช่สถานะชั้นหนึ่ง ยกตัวอย่าง ERC20Token บันทึกสินทรัพย์ของผู้ใช้ทั้งหมดจะถูกจัดเก็บไว้ในที่เก็บสัญญา ERC20 เดียว ในกรณีนี้ ใครควรจ่ายค่าเช่า

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