TON: เครือข่ายเปิดโทรเลข ส่วนที่ 2: Blockchains การแบ่งส่วน

TON: เครือข่ายเปิดโทรเลข ส่วนที่ 2: Blockchains การแบ่งส่วน

ข้อความนี้เป็นความต่อเนื่องของบทความชุดหนึ่งที่ฉันตรวจสอบโครงสร้างของเครือข่ายแบบกระจาย (สันนิษฐาน) Telegram Open Network (TON) ซึ่งกำลังเตรียมพร้อมสำหรับการเปิดตัวในปีนี้ ใน ส่วนก่อนหน้า ฉันอธิบายระดับพื้นฐานที่สุดแล้ว - วิธีที่โหนดโต้ตอบซึ่งกันและกัน

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

วันนี้เราจะมาดูองค์ประกอบหลักของ TON - บล็อกเชน

แนวคิดพื้นฐาน

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

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

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

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

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

Blockchain ใน TON: มันคืออะไรและทำไม?

ดังที่ได้กล่าวไว้ในบทความก่อนหน้านี้ blockchain เป็นโครงสร้างข้อมูล องค์ประกอบ (บล็อก) ที่ถูกเรียงลำดับเป็น "ลูกโซ่" และแต่ละบล็อกที่ตามมาของลูกโซ่จะมีแฮชของบล็อกก่อนหน้า. ความคิดเห็นถามคำถาม: เหตุใดเราจึงต้องมีโครงสร้างข้อมูลเช่นนี้ในเมื่อเรามี DHT - ตารางแฮชแบบกระจายอยู่แล้ว? แน่นอนว่าข้อมูลบางอย่างสามารถจัดเก็บไว้ใน DHT ได้ แต่ข้อมูลนี้เหมาะสำหรับข้อมูลที่ไม่ "ละเอียดอ่อน" เกินไปเท่านั้น ยอดคงเหลือของ Cryptocurrency ไม่สามารถจัดเก็บใน DHT ได้ เนื่องจากขาดการตรวจสอบเป็นหลัก ความซื่อสัตย์. ที่จริงแล้วความซับซ้อนทั้งหมดของโครงสร้างบล็อคเชนเติบโตขึ้นเพื่อป้องกันการรบกวนกับข้อมูลที่เก็บไว้ในนั้น

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

TON มีแผนจะแก้ไขปัญหาทั้งสองข้อข้างต้นอย่างไร

เนื้อหาบล็อกเชน เวิร์กเชน

TON: เครือข่ายเปิดโทรเลข ส่วนที่ 2: Blockchains การแบ่งส่วน

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

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

ดังที่ได้กล่าวไว้ข้างต้น บล็อกนั้นประกอบด้วยธุรกรรม - ข้อความที่ส่งไปยังบัญชี account_id ต่างๆ อย่างไรก็ตาม นอกเหนือจาก account_id แล้ว ข้อความยังมีช่องแบบ 32 บิตอีกด้วย workchain_id - สิ่งที่เรียกว่าตัวระบุ เวิร์กเชน (เวิร์กเชน, บล็อกเชนที่ทำงาน). สิ่งนี้ช่วยให้คุณมีบล็อคเชนหลายอันแยกจากกันด้วยการกำหนดค่าที่แตกต่างกัน ในกรณีนี้ workchain_id = 0 ถือเป็นกรณีพิเศษ เวิร์กเชนเป็นศูนย์ — ยอดคงเหลือในนั้นจะสอดคล้องกับสกุลเงินดิจิตอล TON (Grams) เป็นไปได้มากว่าในตอนแรกเวิร์กเชนอื่นๆ จะไม่มีอยู่เลย

ชาร์ดเชนส์ กระบวนทัศน์การแบ่งส่วนที่ไม่มีที่สิ้นสุด

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

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

ดังนั้น shardchain จะรวมบัญชีตามคำนำหน้าไบนารีของตัวระบุ: หาก shardchain มีหมายเลขนำหน้าเป็น 0110 ก็จะรวมธุรกรรมของ account_ids ทั้งหมดที่ขึ้นต้นด้วยตัวเลขเหล่านี้ นี้ shard_prefix สามารถมีความยาวได้ตั้งแต่ 0 ถึง 60 บิต - และสิ่งสำคัญคือสามารถเปลี่ยนแปลงได้แบบไดนามิก

TON: เครือข่ายเปิดโทรเลข ส่วนที่ 2: Blockchains การแบ่งส่วน

ทันทีที่หนึ่งใน shardchains เริ่มรับธุรกรรมมากเกินไป โหนดที่ทำงานตามกฎที่กำหนดไว้ล่วงหน้า "แยก" มันออกเป็นสองลูก - คำนำหน้าของพวกเขาจะยาวขึ้นอีกเล็กน้อย (และสำหรับหนึ่งในนั้น บิตนี้จะเป็น เท่ากับ 0 และอีกอัน - 1) ตัวอย่างเช่น, shard_prefix = 0110b จะแยกออกเป็น 01100b และ 01101ข. ในทางกลับกัน หาก shardchains "ที่อยู่ติดกัน" สองตัวเริ่มรู้สึกสบายใจเพียงพอ (ในบางครั้ง) พวกมันก็จะรวมกันอีกครั้ง

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

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

แก้ไขข้อผิดพลาด. บล็อกเชนแนวตั้ง

ตามเนื้อผ้า ธุรกรรมใดๆ บนบล็อกเชนจะถือว่า “มั่นคง” อย่างไรก็ตาม ในกรณีของ TON มีความเป็นไปได้ที่จะ "เขียนประวัติศาสตร์ใหม่" - ในกรณีที่มีใครบางคน (ที่เรียกว่า. ปมชาวประมง) จะพิสูจน์ได้ว่าบล็อกใดบล็อกหนึ่งมีการลงนามไม่ถูกต้อง ในกรณีนี้ บล็อกแก้ไขพิเศษจะถูกเพิ่มเข้าไปใน shardchain ที่เกี่ยวข้อง โดยมีแฮชของบล็อกที่ได้รับการแก้ไข (และไม่ใช่บล็อกสุดท้ายใน shardchain) เมื่อคิดว่า shardchain เป็นเหมือนห่วงโซ่ของบล็อกที่วางเรียงกันในแนวนอน เราสามารถพูดได้ว่าบล็อกแก้ไขนั้นติดอยู่กับบล็อกที่ผิดพลาดไม่ใช่ทางด้านขวา แต่จากด้านบน - ดังนั้นจึงถือว่ามันกลายเป็นส่วนหนึ่งของ "บล็อกเชนแนวตั้ง" ขนาดเล็ก . ดังนั้นเราจึงสามารถพูดได้ว่า shardchains เป็น บล็อกเชนสองมิติ.

TON: เครือข่ายเปิดโทรเลข ส่วนที่ 2: Blockchains การแบ่งส่วน

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

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

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

บล็อกเชนเดียวที่จะควบคุมพวกมันทั้งหมด

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

  • เกี่ยวกับจำนวนและการกำหนดค่าของเวิร์กเชน
  • เกี่ยวกับจำนวนชาร์ดเชนและคำนำหน้า
  • เกี่ยวกับโหนดใดที่รับผิดชอบในปัจจุบันสำหรับชาร์ดเชนใด
  • แฮชของบล็อกสุดท้ายที่เพิ่มใน shardchains ทั้งหมด

ดังที่คุณอาจเดาได้ สิ่งเหล่านี้ทั้งหมดจะถูกบันทึกไว้ในที่เก็บข้อมูลบล็อคเชนอื่น - มาสเตอร์เชน (มาสเตอร์เชน, บล็อกเชนหลัก). เนื่องจากการมีอยู่ของแฮชจากบล็อกของ shardchains ทั้งหมดในบล็อก มันทำให้ระบบมีการเชื่อมต่อสูง ซึ่งหมายความว่า เหนือสิ่งอื่นใด การสร้างบล็อกใหม่ใน Masterchain จะเกิดขึ้นทันทีหลังจากการสร้างบล็อกใน shardchains - คาดว่าบล็อกใน shardchains จะปรากฏขึ้นเกือบพร้อมกันทุกๆ 5 วินาทีโดยประมาณ และบล็อกถัดไปใน masterchain - วินาทีหลังจากนั้น

แต่ใครจะเป็นผู้รับผิดชอบในการดำเนินงานไททานิคทั้งหมดนี้ - สำหรับการส่งข้อความ, การดำเนินการสัญญาอัจฉริยะ, การสร้างบล็อกใน shardchains และ masterchain และแม้แต่การตรวจสอบบล็อกเพื่อหาข้อผิดพลาด? ทั้งหมดนี้จะถูกทำอย่างลับๆ โดยโทรศัพท์ของผู้ใช้หลายล้านคนที่ติดตั้งไคลเอ็นต์ Telegram ไว้หรือไม่ หรือบางทีทีม Durov จะละทิ้งแนวคิดเรื่องการกระจายอำนาจและเซิร์ฟเวอร์ของพวกเขาก็จะทำตามวิธีที่ล้าสมัย?

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

ที่มา: will.com

เพิ่มความคิดเห็น