ถ้าจุดเน้นของเลเยอร์ 1 ควรเป็นสถานะมากกว่าการคำนวณชื่อเรื่องรอง

สถานะ

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

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

• สถานะ (เช่น ตอนนี้) - โหนดเสร็จสิ้นการประมวลผลจาก Genesis
  

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

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

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

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

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

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

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

ในเครือข่าย Bitcoin แต่ละบล็อกและแต่ละ UTXO จะยังคงใช้พื้นที่เก็บข้อมูลของโหนดต่อไป ในปัจจุบันขนาดของประวัติทั้งหมดของ Bitcoin (ขนาดของบล็อกทั้งหมดรวมกัน) คือประมาณ 200G,และขนาดของรัฐมีเพียง 3G เท่านั้น (ประกอบด้วย UTXO ประมาณ 50 ล้าน)ชื่อเรื่องรอง

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

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

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

• ถึง - บัญชีอื่นที่แสดงถึงผู้ส่งธุรกรรม

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

• ข้อมูล - ข้อมูลโดยพลการที่ดำเนินการโดยการทำธุรกรรม

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

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

จะเห็นได้ว่าประวัติและโครงสร้างการทำธุรกรรมของ Ethereum นั้นแตกต่างอย่างมากเมื่อเทียบกับ Bitcoin สถานะของ Ethereum ประกอบด้วยบัญชี ในขณะที่ธุรกรรมประกอบด้วยข้อมูลที่ก่อให้เกิดการเปลี่ยนแปลงของบัญชี สถานะและธุรกรรมบันทึกข้อมูลประเภทที่แตกต่างกันโดยสิ้นเชิง ไม่มีความสัมพันธ์แบบซูเปอร์เซ็ตและเซ็ตย่อยระหว่างสองสิ่งนี้ชนิดข้อมูลที่มีอยู่ในประวัติและสถานะเป็นแบบสองมิติไม่มีความสัมพันธ์ที่จำเป็นระหว่างขนาดประวัติการทำธุรกรรมและขนาดสถานะ หลังจากที่ทรานแซกชันแก้ไขสถานะแล้ว จะไม่เพียงสร้างสถานะใหม่ (เว้นในช่องเส้นทึบในรูป) แต่ยังปล่อยให้สถานะเก่า (ปล่อยในช่องเส้นประในรูป) เป็นสถานะย้อนหลังด้วย ดังนั้น ประวัติของ Ethereum ไม่เพียงรวมถึงการทำธุรกรรมเท่านั้น แต่ยังรวมถึงสถานะทางประวัติศาสตร์ด้วย เนื่องจากประวัติและสถานะอยู่ในมิติที่แตกต่างกัน ส่วนหัวของบล็อก Ethereum ไม่เพียงแต่มีราก Merkle ของธุรกรรมเท่านั้น แต่ยังต้องมีราก Merkle ของสถานะอย่างชัดเจนด้วย (คำถามชวนคิด: EOS ใช้รูปแบบบัญชีคล้ายกับ Ethereum แต่ไม่รวมสถานะ Merkle Tree Root ในส่วนหัวของบล็อก สิ่งนี้ดีหรือไม่ดี?)

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

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

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

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

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

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

1.EtherDelta, 5.09%
2.IDEX, 4.17%
3.CryptoKitties, 3.05%
4.ENS, 1.92%
5.EOS Sale, 1.73%

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

จะเห็นได้ว่าหากไม่มีการจัดการ ทรัพยากรการจัดเก็บของ blockchain จะถูกละเมิดโดยตั้งใจหรือไม่ตั้งใจ ในรูปแบบเศรษฐกิจที่ออกแบบมาอย่างดี ผู้ใช้ต้องรับภาระต้นทุนพื้นที่จัดเก็บชื่อเรื่องรอง。

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

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

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

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

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

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

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

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

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

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

ลิงค์ต้นฉบับ:

ลิงค์ต้นฉบับ:https://talk.nervos.org/t/top...