พิเศษ! เพียงใช้โค้ด freehosting1y รับฟรีโฮสติ้ง 1 ปี เฉพาะออเดอร์ที่มียอดซื้อตั้งแต่ 25,000 บาทขึ้นไปที่มีโฮสติ้ง

bitcoin ทำไมไม่บีบอัดเพื่อที่จะใช้พื้นที่น้อยลง

  • 0:18 min

  • 0 comments

แนวคิดเรื่องการ “บีบอัด” (Compression) ข้อมูลใน Bitcoin เป็นประเด็นที่น่าสนใจครับ แต่ในทางเทคนิคแล้ว Bitcoin ไม่สามารถบีบอัดข้อมูลให้เล็กลงได้แบบไฟล์ทั่วไป (เช่น .zip หรือ .rar) ด้วยเหตุผลหลักๆ ดังนี้ครับ:

1. ข้อมูลใน Blockchain คือ “หลักฐาน” ที่ต้องตรวจสอบได้ทันที

Bitcoin ไม่ใช่แค่ฐานข้อมูลที่เก็บตัวเลขยอดเงิน แต่มันคือ “สมุดบัญชีแยกประเภท (Ledger) ที่ทุกคนต้องตรวจสอบได้”
* หากเราบีบอัดข้อมูล เมื่อโหนด (Node) ใหม่ๆ เข้ามาในเครือข่าย หรือต้องการตรวจสอบย้อนหลัง พวกเขาจะต้องเสียเวลา “คลายการบีบอัด” (Decompress) ซึ่งจะกินทรัพยากรเครื่องมหาศาล
* หัวใจของ Bitcoin คือ ความโปร่งใสและการตรวจสอบได้ (Verifiability) ข้อมูลที่เก็บอยู่ปัจจุบันถูกจัดเก็บในรูปแบบที่คอมพิวเตอร์สามารถตรวจสอบลายเซ็นดิจิทัล (Digital Signature) และความเป็นเจ้าของได้ทันที

2. ข้อมูลถูกบีบอัดในระดับที่เหมาะสมอยู่แล้ว (Optimization)

อันที่จริงนักพัฒนา Bitcoin ได้ทำการ “บีบอัด” ข้อมูลในเชิงโครงสร้างมาแล้วตั้งแต่ออกแบบ เช่น:
* Merkle Trees: ใช้การรวมข้อมูลธุรกรรมเป็นกิ่งไม้ (Hash) เพื่อให้เราตรวจสอบได้ว่าธุรกรรมอยู่ในบล็อกนั้นจริงหรือไม่ โดยไม่ต้องเก็บข้อมูลดิบทั้งหมดของธุรกรรมเก่าๆ ไว้ในส่วนของ Header
* Segregated Witness (SegWit): การแยกส่วนลายเซ็นออกไป เพื่อให้บล็อกมีพื้นที่เก็บธุรกรรมมากขึ้นและประหยัดพื้นที่ในการจัดเก็บในส่วนที่ไม่จำเป็นต้องตรวจสอบซ้ำ
* Compact Blocks: ในการส่งข้อมูลระหว่างโหนด ก็มีการใช้เทคนิคส่งเฉพาะข้อมูลที่จำเป็นเพื่อประหยัด Bandwidth อยู่แล้ว

3. ปัญหาของ “การบีบอัดแบบสูญเสียข้อมูล” (Lossy Compression)

ถ้าเรามองว่าไฟล์วิดีโอหรือรูปภาพบีบอัดได้ เพราะมัน “ยอมลดความละเอียดลงได้” แต่ Bitcoin ไม่สามารถลดความละเอียดได้ แม้แต่บิตเดียว
* ถ้าข้อมูลหายไปแม้แต่จุดเดียว (Corruption) ยอดเงินหรือความเป็นเจ้าของจะเปลี่ยนไปทันที
* การบีบอัดแบบไม่สูญเสียข้อมูล (Lossless Compression) กับข้อมูลที่เป็นชุดตัวเลขสุ่ม (Random Data) เช่น Hash หรือลายเซ็นดิจิทัลนั้น แทบจะทำไม่ได้ เพราะข้อมูลเหล่านี้มีค่า Entropy สูงมาก (ไม่สามารถหาแพทเทิร์นซ้ำๆ มาย่อขนาดได้)

4. เราไม่จำเป็นต้องเก็บ “ทั้ง Blockchain” ไว้ที่เครื่องตัวเอง

นี่คือทางออกที่ Bitcoin เลือกใช้แทนการบีบอัดครับ:
* Pruned Nodes: ผู้ใช้งานทั่วไปไม่จำเป็นต้องเก็บประวัติย้อนหลังทั้งหมดตั้งแต่ปี 2009 ก็ได้ คุณสามารถตั้งค่าให้เครื่อง “ลบ” บล็อกเก่าๆ ทิ้งไปหลังจากตรวจสอบเสร็จแล้ว เหลือไว้แค่ยอดคงเหลือปัจจุบัน (UTXO Set) ซึ่งช่วยลดพื้นที่จัดเก็บจากหลายร้อย GB เหลือเพียงหลักสิบ GB ได้
* SPV (Simplified Payment Verification): สำหรับผู้ใช้ทั่วไป (เช่น Wallet ในมือถือ) ไม่จำเป็นต้องเก็บ Blockchain เลย แต่จะอาศัยการถามจากโหนดอื่นและตรวจสอบเฉพาะส่วนหัวของบล็อก (Block Headers) ซึ่งใช้พื้นที่น้อยมาก

สรุป

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

ปัจจุบันขนาดของ Blockchain ของ Bitcoin มีขนาดประมาณ 500-600 GB ซึ่งสำหรับโลกคอมพิวเตอร์ในปัจจุบัน ถือว่าไม่ได้ใหญ่เกินกว่าที่โหนดทั่วไปจะรับไหวครับ (เทียบกับความปลอดภัยที่ได้รับ ถือว่าคุ้มค่ามาก)

Outsource.Men รับพัฒนาเว็บไซต์ Shopify, Wordpress, Wix, ดูแลระบบ ERP, SaaS, Cloud, เขียนโปรแกรม Tradingview, Liquid, Google และดูแลระบบธุรกิจออนไลน์ โดยทีมผู้เชี่ยวชาญอิสระ

รับคำปรึกษาฟรี >>คลิกที่นี่<<

แชร์โพสต์นี้:

27

Jul

ไม่ง้ออินเตอร์เน็ต! ใช้ Ubuntu Linux Mint แบบ Offline ยังไงดี

ถ้าคุณต้องการดาวน์โหลดแพ็กเกจไว้ติดตั้งเองแบบ Offline (ไม่ต้องต่ออินเทอร์เน็ต) ขนาดพื้นที่ที่ต้องใช้จะขึ้นอยู่กับ วิธี ที่คุณเลือกใช้งานครับ โดยแบ่งออกเป็น 3 แนวทางหลักๆ ดังนี้: 1. โหลดเฉพาะแพ็กเกจที่ระบุและ dependencies (แนะนำที่สุด) วิธีนี้คือการเลือกดาวน์โหลดเฉพาะโปรแกรมที่คุณต้องการจริงๆ ควบคู่กับไฟล์เสริมที่จำเป็น (Dependencies) ไปติดตั้ง โดยไม่ต้องโหลดมาทั้งคลังระบบ 2. ทำคลังเฉพาะส่วน (Partial Mirror / Local…

19

Jul

เตรียมตัวให้พร้อม! Google อัปเดตเงื่อนไขใหม่ Android Backup เริ่มนับรวมพื้นที่เก็บข้อมูลแล้ว

Google ประกาศเปลี่ยนนโยบาย Android Backup ใหม่! ข้อมูลเครื่องเริ่มนับรวมในพื้นที่ Google Account แล้ว เช็กผลกระทบและวิธีตั้งค่าปิด-เปิดสำรองข้อมูลแอปที่นี่ก่อนเริ่มจริงใน 45 วัน

15

Jul

anacron เริ่มทำงานวันไหน ถ้าไฟล์ weekly เพิ่มในโฟลเดอร์ cron

หากคุณเพิ่มไฟล์สคริปต์เข้าไปใน /etc/cron.weekly/ วันนี้ การทำงานของมันจะขึ้นอยู่กับ "ประวัติการรัน" ของระบบครับ โดยมีรายละเอียดดังนี้: 1. มันจะทำงานเมื่อไหร่? anacron จะตรวจสอบไฟล์ใน /var/spool/anacron/ เพื่อดูว่าสคริปต์นั้นๆ ถูกรันครั้งล่าสุดเมื่อไหร่: * ถ้ายังไม่เคยรันเลย: anacron มักจะมองว่ามัน "ถึงเวลาที่ต้องรันแล้ว" และจะรันสคริปต์นั้น ภายในเวลาไม่นานหลังจากที่คุณเพิ่มไฟล์เข้าไป (โดยปกติจะรอประมาณ 5-10 นาทีตามค่า START_HOURS_RANGE…