การปรับขนาดบล็อคเชนด้วยข้อมูลนอกเชน

เผยแพร่ซ้ำโดยเพลโต

ผู้ติดตาม: 0

เมื่อแฮชมีค่าเป็นล้านคำ

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

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

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

การรักษาความลับและความสามารถในการปรับขนาด

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

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

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

หากเราใช้กรณีง่าย ๆ โดยที่แต่ละรายการมีโครงสร้าง JSON ขนาดเล็ก 100 ไบต์ อัตราการส่งข้อมูลโดยรวมจะเท่ากับ 100 กิโลไบต์ต่อวินาที โดยคำนวณจาก 500 × (100+100) ซึ่งแปลได้ต่ำกว่า 1 เมกะบิต/วินาทีของแบนด์วิดท์ ซึ่งเพียงพอกับความจุของการเชื่อมต่ออินเทอร์เน็ตสมัยใหม่ ข้อมูลจะสะสมในอัตราประมาณ 3 เทราไบต์ต่อปี ซึ่งไม่ใช่จำนวนเล็กน้อย แต่ด้วยฮาร์ดไดรฟ์ขนาด 12 เทราไบต์ในตอนนี้ สามารถใช้ได้อย่างกว้างขวางและ RAID คอนโทรลเลอร์ที่รวมฟิสิคัลไดรฟ์หลายตัวไว้ในโลจิคัลเดียว เราสามารถจัดเก็บข้อมูล 10-20 ปีบนทุกโหนดได้อย่างง่ายดายโดยไม่ต้องยุ่งยากหรือเสียค่าใช้จ่ายมากเกินไป

อย่างไรก็ตาม สิ่งต่างๆ จะดูแตกต่างออกไปมากหากเราจัดเก็บข้อมูลขนาดใหญ่ เช่น เอกสารที่สแกน การสแกน JPEG คุณภาพที่เหมาะสมของกระดาษ A4 อาจมีขนาด 500 กิโลไบต์ คูณสิ่งนี้ด้วย 500 ธุรกรรมต่อวินาที และเรากำลังดูปริมาณงานอยู่ที่ 250 เมกะไบต์ ต่อวินาที. นี่แปลเป็น 2 กิกะบิต/วินาทีของแบนด์วิดท์ ซึ่งเร็วกว่าเครือข่ายท้องถิ่นส่วนใหญ่ ไม่ต้องพูดถึงการเชื่อมต่ออินเทอร์เน็ต ที่ Amazon Web Services ถูกที่สุด ราคาเผยแพร่ 0.05 ดอลลาร์ต่อกิกะไบต์ ซึ่งหมายถึงค่าบริการแบนด์วิดท์รายปี 400,000 ดอลลาร์ต่อโหนด และแต่ละโหนดจะเก็บข้อมูลใหม่ 8000 เทราไบต์ที่สร้างขึ้นทุกปีไว้ที่ใด

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

โซลูชันการแฮช

แล้วเราจะแก้ปัญหาเรื่อง data scalability ได้อย่างไร? เราจะใช้ประโยชน์จากการพิสูจน์รับรองข้อมูลแบบกระจายศูนย์ของบล็อกเชนได้อย่างไร โดยไม่ต้องจำลองข้อมูลนั้นไปยังทุกโหนดในห่วงโซ่

คำตอบคือด้วยเทคโนโลยีอันชาญฉลาดที่เรียกว่า “แฮช” แฮชเป็นตัวเลขที่ยาว (คิดว่าเป็น 256 บิตหรือประมาณ 80 หลักทศนิยม) ซึ่งระบุชิ้นส่วนของข้อมูลโดยไม่ซ้ำกัน แฮชคำนวณจากข้อมูลโดยใช้ a ฟังก์ชั่นทางเดียว ซึ่งมีคุณสมบัติในการเข้ารหัสที่สำคัญ: เมื่อพิจารณาจากข้อมูลใดๆ ก็ตาม การคำนวณแฮชของข้อมูลนั้นทำได้ง่ายและรวดเร็ว แต่เมื่อพิจารณาจากแฮชเฉพาะแล้ว จึงเป็นไปไม่ได้ในการคำนวณที่จะค้นหาข้อมูลที่จะสร้างแฮชนั้น และเมื่อเราพูดว่า "คำนวณไม่ได้" เราหมายถึงการคำนวณมากกว่าที่มีอะตอมในจักรวาลที่รู้จัก

แฮชมีบทบาทสำคัญในบล็อคเชนทั้งหมด โดยระบุธุรกรรมและบล็อกที่ไม่ซ้ำกัน พวกเขายังรองรับความท้าทายด้านการคำนวณในระบบพิสูจน์การทำงาน เช่น bitcoin ฟังก์ชันแฮชต่างๆ ได้รับการพัฒนาขึ้น โดยมีชื่อ gobbledygook เช่น BLAKE2, MD5 และ RIPEMD160 แต่เพื่อให้ฟังก์ชันแฮชเชื่อถือได้ ฟังก์ชันดังกล่าวต้องทนต่อการตรวจสอบและการทดสอบทางวิชาการอย่างกว้างขวาง การทดสอบเหล่านี้มาในรูปแบบของความพยายามโจมตี เช่น "preimage" (ค้นหาอินพุตด้วย hash ที่กำหนด), "preimage ที่สอง" (ค้นหาอินพุตที่สองด้วย hash เดียวกันกับอินพุตที่กำหนด) และ "collision" (ค้นหาใดๆ สองอินพุตที่แตกต่างกันด้วยแฮชเดียวกัน) การเอาชีวิตรอดจากถุงมือนี้ไม่ใช่เรื่องง่าย ด้วยประวัติอันยาวนานและน่าเศร้าของฟังก์ชันแฮชที่เสียหาย ซึ่งพิสูจน์คติพจน์ที่มีชื่อเสียง: “อย่าม้วน crypto ของคุณเอง”

เพื่อย้อนกลับไปที่ปัญหาเดิมของเรา เราสามารถแก้ไขความสามารถในการปรับขนาดของข้อมูลในบล็อคเชนโดยฝังแฮชของข้อมูลขนาดใหญ่ภายในธุรกรรม แทนที่จะเป็นตัวข้อมูลเอง แฮชแต่ละรายการทำหน้าที่เป็น "ความมุ่งมั่น" ต่อข้อมูลที่ป้อนเข้า โดยข้อมูลนั้นถูกจัดเก็บไว้นอกบล็อคเชนหรือ "นอกเครือข่าย" ตัวอย่างเช่น การใช้ฟังก์ชันแฮช SHA256 ที่เป็นที่นิยม รูปภาพ JPEG ขนาด 500 กิโลไบต์สามารถแสดงด้วยตัวเลข 32 ไบต์ ซึ่งลดลงกว่า 15,000 เท่า แม้ในอัตรา 500 ภาพต่อวินาที สิ่งนี้ทำให้เรากลับมาอยู่ในขอบเขตของความต้องการแบนด์วิดธ์และพื้นที่เก็บข้อมูลที่เป็นไปได้ ในแง่ของข้อมูลที่จัดเก็บไว้ในเชนนั้นเอง

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

คำถามเกี่ยวกับการจัดส่ง

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

เราจะส่งเนื้อหานอกสายโซ่ดั้งเดิมไปยังโหนดที่ต้องการได้อย่างไร หากไม่ผ่านสายโซ่เอง

คำถามนี้มีคำตอบที่เป็นไปได้หลายประการ และเราทราบดีว่าผู้ใช้ MultiChain ใช้งานพวกเขาทั้งหมด วิธีพื้นฐานวิธีหนึ่งคือการตั้งค่าพื้นที่เก็บข้อมูลส่วนกลางในฝ่ายที่เชื่อถือได้ โดยที่ข้อมูลนอกเครือข่ายทั้งหมดจะถูกอัปโหลด จากนั้นจึงดึงข้อมูลในภายหลัง ระบบนี้สามารถใช้ "การกำหนดที่อยู่เนื้อหา" ได้ตามปกติ ซึ่งหมายความว่าแฮชของข้อมูลแต่ละชิ้นทำหน้าที่เป็นตัวระบุโดยตรงสำหรับการดึงข้อมูล อย่างไรก็ตาม แม้ว่าการตั้งค่านี้อาจใช้ได้สำหรับการพิสูจน์แนวคิด แต่ก็ไม่สมเหตุสมผลสำหรับการผลิต เนื่องจากจุดรวมของบล็อกเชนคือการลบตัวกลางที่เชื่อถือได้ แม้ว่าแฮชแบบ on-chain จะป้องกันตัวกลางจากการปลอมแปลงข้อมูล แต่ก็ยังสามารถลบข้อมูลหรือไม่สามารถส่งข้อมูลให้ผู้เข้าร่วมบางคนได้ เนื่องจากความผิดพลาดทางเทคนิคหรือการกระทำของพนักงานที่หลอกลวง

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

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

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

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

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

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

ข้อมูลนอกระบบใน MultiChain 2.0

วันนี้เรามีความยินดีที่จะปล่อย รุ่นตัวอย่างที่สาม (alpha 3) ของ MultiChain 2.0 พร้อมโซลูชันที่ผสานรวมอย่างสมบูรณ์และราบรื่นสำหรับข้อมูลนอกเครือข่าย ข้อมูลทุกชิ้นที่เผยแพร่ไปยังสตรีมสามารถเป็นแบบ on-chain หรือ off-chain ได้ตามต้องการ และ MultiChain จะดูแลทุกอย่าง

ไม่จริง เราหมายถึง ทุกอย่าง. ในฐานะนักพัฒนาที่สร้างบน MultiChain คุณจะไม่ต้องกังวลเกี่ยวกับแฮช พื้นที่จัดเก็บในเครื่อง การค้นพบเนื้อหา การจัดส่งแบบกระจายศูนย์ หรือการตรวจสอบข้อมูล นี่คือสิ่งที่เกิดขึ้นเบื้องหลัง:

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

ที่สำคัญที่สุด ทั้งหมดนี้เกิดขึ้นเร็วมาก ในเครือข่ายที่มีเวลาแฝงต่ำ ข้อมูลนอกเครือข่ายเล็กๆ น้อยๆ จะมาถึงสมาชิกภายในเสี้ยววินาทีของธุรกรรมที่อ้างอิงถึงพวกเขา และสำหรับแอปพลิเคชันที่มีภาระงานสูง การทดสอบของเราแสดงให้เห็นว่า MultiChain 2.0 alpha 3 สามารถรักษาอัตรารายการ off-chain ได้กว่า 1000 รายการ หรือข้อมูล off-chain 25 MB ที่ดึงมาต่อวินาที บนเซิร์ฟเวอร์ระดับกลาง (Core i7) ด้วยค่าที่เหมาะสม การเชื่อมต่ออินเทอร์เน็ต. ทุกอย่างทำงานได้ดีกับรายการนอกระบบที่มีขนาดไม่เกิน 1 GB ซึ่งเกินขีดจำกัด 64 MB สำหรับข้อมูลในสายโซ่ แน่นอน เราหวังว่าจะปรับปรุงตัวเลขเหล่านี้ให้ดียิ่งขึ้นในขณะที่เราใช้เวลาในการเพิ่มประสิทธิภาพ MultiChain 2.0 ในช่วงเบต้าของมัน

เมื่อใช้ off-chain มากกว่าข้อมูล on-chain ในสตรีม นักพัฒนาแอปพลิเคชัน MultiChain ต้องทำสองสิ่งเท่านั้น:

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

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

สามารถใช้รายการแบบ on-chain และ off-chain ภายในสตรีมเดียวกันได้ และฟังก์ชันการสืบค้นและสรุปข้อมูลของสตรีมต่างๆ จะสัมพันธ์กับข้อมูลทั้งสองประเภทเหมือนกัน ซึ่งช่วยให้ผู้เผยแพร่โฆษณาสามารถเลือกที่เหมาะสมสำหรับทุกรายการในสตรีม โดยไม่กระทบต่อส่วนที่เหลือของแอปพลิเคชัน ตัวอย่างเช่น สตรีมของรายการ JSON เกี่ยวกับกิจกรรมของผู้คนอาจใช้ข้อมูลนอกเครือข่ายเพื่อระบุข้อมูลส่วนบุคคล และข้อมูลในเครือข่ายสำหรับส่วนที่เหลือ สมาชิกสามารถใช้การรวม JSON ของ MultiChain เพื่อรวมข้อมูลทั้งสองประเภทเป็น JSON เดียวสำหรับการอ่าน

หากคุณต้องการทดลองใช้ไอเท็มสตรีมนอกระบบ เพียงทำตามรายการปกติของ MultiChain เริ่มต้นใช้งาน กวดวิชาและอย่าลืมข้ามส่วนที่ 5

แล้วอะไรต่อไป?

ด้วยการสนับสนุนที่ราบรื่นสำหรับข้อมูลนอกเครือข่าย MultiChain 2.0 จะนำเสนอการก้าวไปข้างหน้าครั้งใหญ่สำหรับแอปพลิเคชันบล็อคเชนที่เน้นการประทับเวลาข้อมูลขนาดใหญ่และการรับรองเอกสาร ในระยะยาว เรากำลังคิดถึงการปรับปรุงที่เป็นไปได้มากมายในอนาคตสำหรับฟีเจอร์นี้สำหรับ MultiChain รุ่น Community และ/หรือ Enterprise:

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

เราชอบที่จะ รับฟังความคิดเห็นของคุณ ในรายการด้านบนเช่นเดียวกับรายการนอกระบบโดยทั่วไป ด้วย MultiChain 2.0 ที่ยังคงเป็นเวอร์ชันอัลฟ่าอย่างเป็นทางการ จึงมีเวลาอีกมากที่จะปรับปรุงคุณลักษณะนี้ก่อนการเปิดตัวครั้งสุดท้าย

ในระหว่างนี้ เราได้เริ่มทำงานกับ “ตัวกรองอัจฉริยะ” ซึ่งเป็นฟีเจอร์หลักล่าสุดที่วางแผนไว้สำหรับชุมชน MultiChain 2.0 ตัวกรองอัจฉริยะคือโค้ดที่ฝังอยู่ในบล็อกเชนซึ่งใช้กฎที่กำหนดเองสำหรับตรวจสอบข้อมูลหรือธุรกรรม ตัวกรองอัจฉริยะมีความคล้ายคลึงกันบางประการกับ "สัญญาอัจฉริยะ" และสามารถทำสิ่งเดียวกันได้หลายอย่าง แต่มีข้อแตกต่างที่สำคัญในแง่ของความปลอดภัยและประสิทธิภาพ เราหวังว่าจะบอกคุณเพิ่มเติมในระยะเวลาอันสมควร

กรุณาโพสต์ความคิดเห็นใด ๆ ใน LinkedIn.

รายละเอียดทางเทคนิค

แม้ว่ารายการสตรีมนอกเครือข่ายใน MultiChain 2.0 จะใช้งานง่าย แต่ก็มีการตัดสินใจในการออกแบบมากมายและคุณสมบัติเพิ่มเติมที่อาจสนใจ รายการด้านล่างส่วนใหญ่จะเกี่ยวข้องกับนักพัฒนาที่สร้างแอปพลิเคชันบล็อคเชน และสามารถข้ามได้ตามประเภททางเทคนิคที่น้อยกว่า:

นโยบายต่อสตรีม เมื่อสร้างสตรีม MultiChain สามารถเลือกที่จะจำกัดให้อนุญาตเฉพาะข้อมูลแบบ on-chain หรือ off-chain มีสาเหตุที่เป็นไปได้หลายประการในการทำเช่นนี้ แทนที่จะอนุญาตให้ผู้จัดพิมพ์แต่ละรายตัดสินใจด้วยตนเอง ตัวอย่างเช่น รายการในเครือข่ายมีการรับประกันความพร้อมใช้งานที่เข้มงวด ในขณะที่รายการนอกเครือข่ายแบบเก่าอาจไม่สามารถเรียกคืนได้หากผู้เผยแพร่และสมาชิกรายอื่นๆ ออกจากเครือข่าย ในทางกลับกัน รายการในสายโซ่ไม่สามารถ "ถูกลืม" ได้หากไม่มีการปรับเปลี่ยนบล็อคเชน ในขณะที่รายการนอกระบบจะมีความยืดหยุ่นมากกว่า สิ่งนี้มีความสำคัญในแง่ของกฎความเป็นส่วนตัวของข้อมูล เช่น ข้อบังคับ GDPR ใหม่ของยุโรป
ข้อมูลเมตาบนเชน สำหรับรายการนอกสายโซ่ ธุรกรรมบนเครือข่ายจะยังคงประกอบด้วยผู้เผยแพร่รายการ คีย์ รูปแบบ (JSON ข้อความหรือไบนารี) และขนาดรวม ทั้งหมดนี้ใช้พื้นที่น้อยมาก และช่วยให้นักพัฒนาแอปพลิเคชันสามารถระบุได้ว่าความไม่พร้อมใช้งานของรายการนอกสายโซ่นั้นเป็นปัญหาสำหรับการสืบค้นสตรีมเฉพาะหรือไม่
ขีด จำกัด สองฮอป เมื่อส่งการสืบค้นแบบกลุ่มข้ามเครือข่ายแบบเพียร์ทูเพียร์ มีข้อแลกเปลี่ยนระหว่างความสามารถในการเข้าถึงและประสิทธิภาพ แม้ว่าการสืบค้นข้อมูลทุกรายการจะถูกเผยแพร่ไปตามเส้นทางทุก ๆ ทางจะเป็นการดี แต่สิ่งนี้สามารถอุดตันเครือข่ายด้วย "การพูดคุย" ที่ไม่จำเป็น ดังนั้นสำหรับตอนนี้การสืบค้นแบบกลุ่มจะถูกจำกัดให้อยู่ที่สองฮ็อป ซึ่งหมายความว่าโหนดสามารถดึงข้อมูลนอกสายโซ่จากเพียร์ของเพียร์ของตนได้ ในเครือข่ายขนาดเล็กกว่า 1000 โหนดที่มีแนวโน้มที่จะกำหนดลักษณะเฉพาะของบล็อคเชนขององค์กร เราเชื่อว่าสิ่งนี้จะทำงานได้ดี แต่เป็นเรื่องง่ายสำหรับเราที่จะปรับข้อจำกัดนี้ (หรือเสนอให้เป็นพารามิเตอร์) หากเรากลายเป็นข้อผิดพลาด
ที่เก็บข้อมูลในเครื่อง โหนด MultiChain แต่ละโหนดจัดเก็บข้อมูลนอกเครือข่ายภายในไดเร็กทอรี "chunks" ของไดเร็กทอรี blockchain ปกติ โดยใช้รูปแบบไบนารีที่มีประสิทธิภาพและดัชนี LevelDB ไดเร็กทอรีย่อยแยกต่างหากใช้สำหรับไอเท็มในแต่ละสตรีมที่สมัครรับข้อมูล เช่นเดียวกับที่เผยแพร่โดยโหนดเอง ภายในไดเร็กทอรีย่อยเหล่านี้ ชิ้นส่วนที่ซ้ำกัน (ที่มีแฮชเดียวกัน) จะถูกเก็บไว้เพียงครั้งเดียว เมื่อโหนดยกเลิกการสมัครรับข้อมูลจากสตรีม โหนดสามารถเลือกได้ว่าจะล้างข้อมูลนอกสายโซ่ที่ดึงมาสำหรับสตรีมนั้นหรือไม่
แคชไบนารี เมื่อเผยแพร่ข้อมูลไบนารีจำนวนมาก ไม่ว่าจะเป็นแบบ on-chain หรือ off-chain อาจไม่เป็นประโยชน์สำหรับนักพัฒนาแอปพลิเคชันในการส่งข้อมูลนั้นไปยัง API ของ MultiChain ในคำขอ JSON-RPC เดียว ดังนั้น MultiChain 2.0 จึงใช้ไบนารีแคช ซึ่งช่วยให้ข้อมูลขนาดใหญ่สามารถสร้างขึ้นผ่านการเรียก API หลายรายการ จากนั้นจึงเผยแพร่ในขั้นตอนสุดท้ายโดยสังเขป แต่ละรายการในไบนารีแคชจะถูกจัดเก็บเป็นไฟล์อย่างง่ายในไดเร็กทอรีย่อย "แคช" ของไดเร็กทอรีบล็อคเชน ซึ่งช่วยให้สามารถพุชข้อมูลกิกะไบต์ได้โดยตรงผ่านระบบไฟล์
การตรวจสอบ API MultiChain 2.0 alpha 3 เพิ่ม API ใหม่สองตัวสำหรับการมอนิเตอร์การดึงข้อมูลแบบ off-chain แบบอะซิงโครนัส API แรกอธิบายสถานะปัจจุบันของคิว โดยแสดงจำนวนชิ้น (และข้อมูล) ที่กำลังรอหรือถูกสอบถามหรือดึงข้อมูล API ที่สองให้สถิติรวมสำหรับการสืบค้นและคำขอกลุ่มทั้งหมดที่ส่งตั้งแต่โหนดเริ่มทำงาน รวมถึงการนับความล้มเหลวประเภทต่างๆ
ล้างเมื่อเผยแพร่ เมื่อเผยแพร่รายการนอกระบบ MultiChain จะตรวจสอบให้แน่ใจว่าสำเนาข้อมูลในเครื่องนั้นถูกเขียนอย่างสมบูรณ์ (หรือ "ล้างข้อมูล") ไปยังดิสก์ไดรฟ์ที่มีอยู่จริง ก่อนที่ธุรกรรมจะอ้างอิงข้อมูลดังกล่าวจะออกอากาศไปยังเครือข่าย มิฉะนั้น หากโหนดโชคไม่ดีพอที่จะสูญเสียพลังงานทันทีหลังจากออกอากาศธุรกรรม ข้อมูลนอกเครือข่ายอาจสูญหายอย่างถาวร นี่ไม่ใช่ปัญหาสำหรับ MultiChain เอง เนื่องจากความล่าช้าระหว่างการพยายามดึงข้อมูลของ Chunk จะเพิ่มขึ้นโดยอัตโนมัติเมื่อเวลาผ่านไป แต่มันอาจทำให้เกิดปัญหาในระดับแอปพลิเคชัน ซึ่งทุกคนรู้ว่ามีข้อมูลบางอย่างอยู่ แต่ไม่มีใครสามารถค้นหาได้
ประสิทธิภาพการเผยแพร่ ด้วยการล้างข้อมูลนอกเชนไปยังดิสก์ในลักษณะนี้ MultiChain อาจมีโทษด้านประสิทธิภาพ เนื่องจากฟิสิคัลดิสก์นั้นช้า ตัวอย่างเช่น ฮาร์ดไดรฟ์ระดับกลาง 7200 รอบต่อนาทีสามารถเขียนข้อมูลแบบสุ่มได้ประมาณ 100 รายการต่อวินาทีเท่านั้น ซึ่งจะจำกัดอัตราที่แต่ละโหนดสามารถเผยแพร่รายการนอกสายโซ่ได้ มีวิธีแก้ปัญหาที่เป็นไปได้สามวิธีสำหรับปัญหานี้ ประการแรกและอย่างง่ายที่สุด โหนดสามารถใช้ไดรฟ์โซลิดสเตต (SSD) แทนฮาร์ดไดรฟ์ปกติ ซึ่งรองรับการดำเนินการเขียนแบบสุ่ม 10,000 ครั้งต่อวินาที ประการที่สอง สามารถเผยแพร่รายการนอกเครือข่ายหลายรายการในธุรกรรมเดียวโดยใช้ API "createrawsendfrom" ในกรณีนี้ MultiChain จะเขียนข้อมูล off-chain ทั้งหมดที่อ้างอิงโดยธุรกรรมในการทำงานของดิสก์เดียว สุดท้าย สามารถกำหนดค่า MultiChain ไม่ให้ล้างข้อมูล off-chain ไปยังดิสก์ก่อนที่จะแพร่ภาพธุรกรรมที่อ้างอิง ใช้ตัวเลือกนี้ด้วยความระมัดระวัง
การรวมสกุลเงินพื้นเมือง สำหรับกรณีการใช้งานที่ต้องการ MultiChain ได้เสนอทางเลือกในการใช้สกุลเงินท้องถิ่นบนบล็อคเชนเสมอ เพื่อป้องกันสแปมธุรกรรมและ/หรือสร้างแรงจูงใจให้ผู้ตรวจสอบบล็อก (“ผู้ขุด”) ในกรณีเหล่านี้ การทำธุรกรรมจะต้องเสนอค่าธรรมเนียมขั้นต่ำแก่ผู้ขุดซึ่งเป็นสัดส่วนกับขนาดของพวกเขาในหน่วยไบต์ เพื่อที่จะได้รับการถ่ายทอดและยืนยันในห่วงโซ่ กลไกนี้ได้รับการขยายเพื่อให้สามารถป้องกันสแปมนอกสายโซ่ได้ โดยต้องมีค่าธรรมเนียมเพิ่มเติมขั้นต่ำต่อกิโลไบต์ของข้อมูลนอกเครือข่ายที่อ้างอิงในธุรกรรม
โหนดที่เก็บถาวร หากโหนดต้องการสมัครรับข้อมูลทุกสตรีม ดังนั้นดึงและจัดเก็บทุกรายการนอกเครือข่ายที่เผยแพร่ สามารถกำหนดค่าให้ทำเช่นนั้นได้โดยใช้พารามิเตอร์รันไทม์ "autosubscribe" โหนดดังกล่าวจะทำหน้าที่เป็นตัวสำรองสำหรับเครือข่ายทั้งหมด รับประกันว่ารายการนอกสายโซ่จะไม่สูญหายหรือไม่พร้อมใช้งาน ไม่ว่าโหนดอื่นจะหายไป ใครๆ ก็นึกภาพบริษัทบุคคลที่สามที่เสนอบริการนี้ในเชิงพาณิชย์