TON มีตรรกะทางเทคโนโลยีหลักที่มีศูนย์กลางอยู่ที่แอปพลิเคชันความเร็วสูง: TON มาจาก Telegram โดยมีการบันทึกธุรกรรมโดยตรงบนเครือข่ายตามข้อความ ซึ่งรองรับการสื่อสารแบบเพียร์ทูเพียร์
สถาปัตยกรรมหลายส่วนแบบไดนามิกของ TON ช่วยอำนวยความสะดวกในการปรับขนาดแอปพลิเคชัน: TON ช่วยเพิ่มความเร็วผ่านการสืบค้นแบบขนาน ปรับปรุงความแม่นยำในการสืบค้นด้วยการแบ่งส่วนแบบไดนามิก และเพิ่มความสามารถในการขยายผ่านโครงสร้างเซลล์แบบถุง
TON จะยังคงเพิ่มประสิทธิภาพกรอบทางเทคนิคต่อไปในอนาคต: ด้วยการขยายแบบขนาน การเปิดตัวเครื่องมือ chain sharding และการเสริมการตรวจสอบโหนด TON ตั้งเป้าที่จะรักษาข้อได้เปรียบในด้านความเร็วและความสามารถในการปรับขนาด
ความสามารถในการปรับขนาดของบล็อกเชนเป็นความท้าทายทางเทคนิคที่สำคัญและเป็นแรงผลักดันสำคัญสำหรับการพัฒนาเทคโนโลยีบล็อกเชน เนื่องจากแอปพลิเคชันบล็อกเชนเติบโตขึ้นและจำนวนผู้ใช้เพิ่มขึ้น เครือข่ายบล็อกเชนที่มีอยู่มักจะเผชิญกับปัญหาปริมาณงานไม่เพียงพอและเวลายืนยันธุรกรรมที่ยาวนาน การออกแบบบล็อกเชนแบบดั้งเดิมจำกัดความสามารถในการจัดการธุรกรรมขนาดใหญ่และความต้องการของผู้ใช้ นำไปสู่ความแออัดของเครือข่าย ต้นทุนการทำธุรกรรมที่สูง และความไร้ประสิทธิภาพ
ความท้าทายของความสามารถในการปรับขนาดบล็อกเชนส่วนใหญ่มาจากสถาปัตยกรรมแบบกระจายและกลไกฉันทามติ: กลไกฉันทามติและลักษณะการกระจายของบล็อกเชนต้องการให้ทุกโหนดในเครือข่ายตรวจสอบและบันทึกธุรกรรมทั้งหมด ซึ่งจำกัดปริมาณงานของเครือข่าย นอกจากนี้ การรักษาความปลอดภัยและคุณสมบัติการกระจายอำนาจของบล็อกเชนต้องการให้โหนดทั้งหมดรักษาสำเนาบล็อกเชนให้สมบูรณ์ ซึ่งจะเพิ่มภาระในการจัดเก็บและการส่งข้อมูล
เพื่อจัดการกับความท้าทายของความสามารถในการปรับขนาดบล็อกเชน นักวิจัยได้เสนอโซลูชันการปรับขนาดที่หลากหลาย เช่น โซลูชัน Sharding, Sidechains และเลเยอร์ 2: วิธีการเหล่านี้มีจุดมุ่งหมายเพื่อปรับปรุงปริมาณงานและประสิทธิภาพของเครือข่ายโดยการแบ่งเครือข่ายออกเป็นส่วนเล็ก ๆ แนะนำบล็อกเชนที่เป็นอิสระ หรือสร้างโครงสร้างเพิ่มเติม บนห่วงโซ่หลัก อย่างไรก็ตาม โซลูชันเหล่านี้นำมาซึ่งความท้าทายด้านเทคนิคและปัญหาด้านความปลอดภัยใหม่ๆ เช่น การสื่อสารระหว่างชาร์ด การถ่ายโอนสินทรัพย์ข้ามชาร์ด และการออกแบบกลไกที่เป็นเอกฉันท์
TON blockchain ซึ่งมีต้นกำเนิดจาก Telegram เกิดขึ้นโดยมีแนวคิดในการให้บริการฐานผู้ใช้จำนวนมาก Telegram เป็นหนึ่งในแพลตฟอร์มโซเชียลที่ได้รับความนิยมมากที่สุดในโลก โดยมีผู้ใช้งานมากกว่า 800 ล้านคนต่อเดือน และส่งข้อความนับพันล้านข้อความภายในซอฟต์แวร์ทุกวัน TON ซึ่งเป็นการโจมตีของ Telegram สู่ web3 ได้รับการออกแบบตั้งแต่เริ่มแรกเพื่อรองรับผู้ใช้นับพันล้านราย ไม่ใช่แค่ฐานผู้ใช้ขนาดเล็ก
การแบ่งส่วนย่อยของ TON เป็นแบบจากล่างขึ้นบน: แม้ว่าแผนการแบ่งส่วนบล็อกเชนแบบเดิมมักจะใช้แนวทางจากบนลงล่าง โดยสร้างบล็อกเชนเดี่ยวขึ้นมาก่อน จากนั้นจึงแยกย่อยออกเป็นบล็อกเชนเชิงโต้ตอบเพื่อเพิ่มประสิทธิภาพ แต่การแบ่งส่วนย่อยของ TON ใช้แนวทางจากล่างขึ้นบน โดยจะจัดกลุ่มบัญชีเหล่านี้ออกเป็น shardchain โดยสร้าง Shardchain โดยที่ Workchains มีอยู่ในรูปแบบเสมือนหรือเชิงตรรกะเท่านั้น TON ประสบความสำเร็จในการประมวลผลธุรกรรมแบบคู่ขนานข้ามเครือข่ายต่างๆ ที่เรียกว่า "บล็อกเชนแห่งบล็อกเชน" วิธีการนี้จะช่วยเพิ่มประสิทธิภาพของระบบได้อย่างมีประสิทธิภาพ
TON มีสถาปัตยกรรมการแบ่งส่วนแบบไดนามิก ซึ่งประกอบด้วยมาสเตอร์เชน เวิร์กเชน และชาร์ดเชน: พิกัดมาสเตอร์เชน ในขณะที่การประมวลผลธุรกรรมจริงเกิดขึ้นภายในเวิร์กเชนและชาร์ดเชนต่างๆ นอกจากนี้ การแบ่งส่วนข้อมูลของ TON ยังเป็นแบบไดนามิก โดยแต่ละบัญชีจะทำหน้าที่เป็นชาร์ดเชน สิ่งเหล่านี้สามารถรวมกันเป็น shardchains ที่ใหญ่ขึ้นได้ โดยขึ้นอยู่กับการโต้ตอบระหว่างบัญชี เพื่อตอบสนองความต้องการในการขยายแบบไดนามิก
หากการแบ่งส่วนข้อมูลถึงขีดจำกัด แต่ละชาร์ดเชนจะจัดเก็บเพียงบัญชีเดียวหรือสัญญาอัจฉริยะเท่านั้น สิ่งนี้ส่งผลให้เกิด “account-chain” จำนวนมากที่อธิบายสถานะและการเปลี่ยนแปลงของแต่ละบัญชี โดย chain เหล่านี้ส่งข้อมูลร่วมกัน สร้าง Workchain ผ่าน Shardchains
ข้อความ: เนื่องจาก TON ใช้ฟังก์ชัน send_raw_message ของ FunC เพื่อพัฒนาภาษา ข้อความที่ส่งผ่านโหนด TON จึงเรียกว่า "ข้อความ" ธุรกรรมใน TON ประกอบด้วยข้อความขาเข้าที่ทริกเกอร์ในตอนแรกและชุดข้อความขาออกที่ส่งไปยังสัญญาอื่น
การกำหนดเส้นทางไฮเปอร์คิวบ์: กลไกการส่งข้อความที่มีโครงสร้างสามมิติที่ช่วยให้ข้อความที่สร้างขึ้นในหนึ่งบล็อกของเชนที่แบ่งส่วนสามารถจัดส่งและประมวลผลอย่างรวดเร็วไปยังบล็อกถัดไปของเชนที่แบ่งส่วนเป้าหมาย
การโทรแบบอะซิงโครนัสทำให้เกิดความท้าทายในการซิงโครไนซ์: ในบล็อกเชนแบบซิงโครนัส ธุรกรรมสามารถรวมถึงการเรียกสัญญาอัจฉริยะหลายรายการ ในระบบอะซิงโครนัส ผู้ใช้ไม่สามารถรับการตอบสนองจากสัญญาอัจฉริยะเป้าหมายในธุรกรรมเดียวกันได้ทันที ความล่าช้านี้เกิดขึ้นเนื่องจากการเรียกสัญญาอาจใช้เวลาหลายบล็อกในการประมวลผล และระยะทางในการกำหนดเส้นทางระหว่างบล็อกต้นทางและปลายทางส่งผลต่อกระบวนการนี้
เพื่อให้บรรลุการแบ่งส่วนข้อมูลแบบไม่มีที่สิ้นสุด จำเป็นอย่างยิ่งที่จะต้องแน่ใจว่าข้อความมีความขนานกันอย่างสมบูรณ์ ซึ่งนำไปสู่การแนะนำแนวคิดเรื่องเวลาเชิงตรรกะ: ใน TON แต่ละธุรกรรมจะดำเนินการในสัญญาอัจฉริยะเดียวเท่านั้น และสื่อสารระหว่างสัญญาโดยใช้ข้อความ สิ่งนี้แนะนำแนวคิดเรื่องเวลาแบบลอจิคัลในเครือข่ายแบบอะซิงโครนัส ซึ่งช่วยให้สามารถซิงโครไนซ์ข้อความระหว่างเครือข่ายได้ แต่ละข้อความมีเวลาตรรกะหรือเวลาแลมพอร์ต (ต่อไปนี้จะเรียกว่า lt) เวลานี้ใช้เพื่อติดตามความสัมพันธ์ระหว่างเหตุการณ์และกำหนดว่าผู้ตรวจสอบเหตุการณ์ใดที่ต้องดำเนินการก่อน
รับประกันตรรกะการดำเนินการโดยปฏิบัติตามลำดับการดำเนินการของข้อความ lt อย่างเคร่งครัด: ข้อความที่ส่งจากบัญชีและธุรกรรมที่เกิดขึ้นในบัญชีจะได้รับการสั่งซื้ออย่างเคร่งครัด โดยจำนวนธุรกรรมที่สร้างขึ้นมากกว่า lt ของข้อความ นอกจากนี้ จำนวนข้อความที่ส่งในธุรกรรมจะมากกว่าจำนวนข้อความของธุรกรรมที่ทำให้เกิดข้อความอย่างเคร่งครัด ในกรณีที่มีข้อความหลายข้อความ ข้อความที่มีค่า lt ต่ำกว่าจะได้รับการประมวลผลเร็วกว่า
TON ใช้การดำเนินการแบบขนานกับ Fast Routing + Slow Routing:
การกำหนดเส้นทางที่ช้า: วิธีการประมวลผลข้อมูลแบบข้ามสายโซ่แบบดั้งเดิมที่มีความเสถียรมากกว่า โดยที่ข้อมูลจะถูกบรรจุลงในบล็อกบนสายโซ่ต้นทาง จากนั้นจึงถ่ายทอดจากสายโซ่ชิ้นส่วนหนึ่งไปยังอีกสายหนึ่งผ่านรีเลย์ สามารถใช้โซ่ชาร์ดตัวกลางหลายตัวในการส่งสัญญาณได้ ชาร์ดเชนทั้งหมดก่อตัวเป็นกราฟ "ไฮเปอร์คิวบ์" และข้อความจะแพร่กระจายไปตามขอบของไฮเปอร์คิวบ์นี้ หลังจากการตรวจสอบความถูกต้องโดยผู้ตรวจสอบความถูกต้อง ข้อมูลจะถูกบรรจุลงในบล็อกอื่น
ข้อดีของ Slow Routing อยู่ที่ความปลอดภัยและการกระจายอำนาจที่สูงขึ้น เนื่องจากข้อมูลทั้งหมดจำเป็นต้องผ่านกระบวนการยืนยันบล็อกโดยสมบูรณ์ สำหรับเครือข่ายไฮเปอร์คิวบ์ของชาร์ดเชนที่มีสเกล N จำนวนเส้นทางที่กระโดด = log16(N) ดังนั้นจึงจำเป็นต้องมีโหนดการกำหนดเส้นทางเพียง 4 โหนดเพื่อรองรับชาร์ดเชนนับล้าน
การกำหนดเส้นทางแบบรวดเร็ว: ในการกำหนดเส้นทางแบบช้า ข้อความจะเผยแพร่ไปตามขอบของไฮเปอร์คิวบ์ เพื่อเร่งความเร็ว Fast Routing ช่วยให้ผู้ตรวจสอบความถูกต้องของห่วงโซ่ชาร์ดปลายทางประมวลผลข้อความล่วงหน้า แสดงหลักฐาน Merkle และส่งใบเสร็จรับเงินเพื่อทำลายข้อความที่ส่งสัญญาณ
การกำหนดเส้นทางด่วนนั้นเร็วกว่า (โหนดสามารถค้นหาเส้นทางที่เหมาะสมที่สุด) และป้องกันการส่งซ้ำซ้อน อย่างไรก็ตาม ไม่สามารถแทนที่ Slow Routing ได้ เนื่องจากผู้ตรวจสอบความถูกต้องจะไม่ถูกลงโทษสำหรับการสูญเสียใบเสร็จรับเงิน ซึ่งก่อให้เกิดความเสี่ยงด้านความปลอดภัย
“ถุงของเซลล์”: ชุดของเซลล์ที่ได้รับการอัปเดตในลักษณะที่คล้ายคลึงกับ Directed Acyclic Graph (DAG) สิ่งนี้เกี่ยวข้องกับการแสดงสถานะใหม่เป็น "ถุงของเซลล์" อีกอันหนึ่งที่มีรากของมันเอง จากนั้นจึงรวมชุดเซลล์ใหม่และชุดเก่าในขณะเดียวกันก็กำจัดรากเก่าออกไปพร้อมกัน
การซ่อมแซมบล็อกแนวตั้ง: ใน TON shard chain แต่ละบล็อกไม่ได้เป็นเพียงบล็อกเดียว แต่เป็นโซ่ เมื่อจำเป็นต้องแก้ไขบล็อกในห่วงโซ่ชิ้นส่วนที่ผิดพลาด บล็อกใหม่จะถูกส่งไปยัง "ห่วงโซ่บล็อกแนวตั้ง" เพื่อทำการเปลี่ยนบล็อก
เครือข่าย POS ประกอบด้วยสามบทบาท:
BFT (Byzantine Fault Tolerance ): TON หลังจากชั่งน้ำหนักตัวเลือกแล้ว เลือก BFT มากกว่า DPOS เนื่องจากมีระดับความน่าเชื่อถือและความเร็วที่สูงกว่า แม้ว่า DPOS จะเร็วกว่าก็ตาม
TON บรรลุความเร็วในการทำธุรกรรมสูงและขั้นสุดท้ายผ่านสถาปัตยกรรมหลายส่วนแบบไดนามิก: กระเป๋าเงินผู้ใช้แต่ละรายใน TON สามารถมีสายโซ่ของตัวเองได้ และพื้นฐานทางทฤษฎีสำหรับ TPS สูงนั้นรวมถึงการคำนวณส่วนแบ่งข้อมูลแบบขนาน การสนับสนุนการสื่อสารข้ามส่วนทันที และการสนับสนุน TVM การคำนวณแบบอะซิงโครนัส
TON นำความสามารถในการปรับขนาดที่สูงขึ้นผ่านกลไกการส่งผ่านข้อมูล: ใน TON blockchain การเรียกระหว่างสัญญาอัจฉริยะเป็นแบบอะซิงโครนัสแทนที่จะเป็นแบบอะตอมมิก ซึ่งหมายความว่าเมื่อสัญญาอัจฉริยะอันหนึ่งเรียกอีกอันหนึ่ง การโทรจะไม่ถูกดำเนินการทันที แต่จะถูกประมวลผลในบล็อกในอนาคตหลังจากธุรกรรมสิ้นสุดลง การออกแบบนี้ช่วยให้สามารถขยายขนาดได้สูงขึ้น เนื่องจากไม่จำเป็นต้องดำเนินการประมวลผลธุรกรรมทั้งหมดให้เสร็จสิ้นในบล็อกเดียว
แผนงานทางเทคนิคของ TON จะช่วยเพิ่มความเร็วและข้อได้เปรียบด้านความสามารถในการปรับขนาดของ TON อย่างต่อเนื่อง:
TON มีตรรกะทางเทคโนโลยีหลักที่มีศูนย์กลางอยู่ที่แอปพลิเคชันความเร็วสูง: TON มาจาก Telegram โดยมีการบันทึกธุรกรรมโดยตรงบนเครือข่ายตามข้อความ ซึ่งรองรับการสื่อสารแบบเพียร์ทูเพียร์
สถาปัตยกรรมหลายส่วนแบบไดนามิกของ TON ช่วยอำนวยความสะดวกในการปรับขนาดแอปพลิเคชัน: TON ช่วยเพิ่มความเร็วผ่านการสืบค้นแบบขนาน ปรับปรุงความแม่นยำในการสืบค้นด้วยการแบ่งส่วนแบบไดนามิก และเพิ่มความสามารถในการขยายผ่านโครงสร้างเซลล์แบบถุง
TON จะยังคงเพิ่มประสิทธิภาพกรอบทางเทคนิคต่อไปในอนาคต: ด้วยการขยายแบบขนาน การเปิดตัวเครื่องมือ chain sharding และการเสริมการตรวจสอบโหนด TON ตั้งเป้าที่จะรักษาข้อได้เปรียบในด้านความเร็วและความสามารถในการปรับขนาด
ความสามารถในการปรับขนาดของบล็อกเชนเป็นความท้าทายทางเทคนิคที่สำคัญและเป็นแรงผลักดันสำคัญสำหรับการพัฒนาเทคโนโลยีบล็อกเชน เนื่องจากแอปพลิเคชันบล็อกเชนเติบโตขึ้นและจำนวนผู้ใช้เพิ่มขึ้น เครือข่ายบล็อกเชนที่มีอยู่มักจะเผชิญกับปัญหาปริมาณงานไม่เพียงพอและเวลายืนยันธุรกรรมที่ยาวนาน การออกแบบบล็อกเชนแบบดั้งเดิมจำกัดความสามารถในการจัดการธุรกรรมขนาดใหญ่และความต้องการของผู้ใช้ นำไปสู่ความแออัดของเครือข่าย ต้นทุนการทำธุรกรรมที่สูง และความไร้ประสิทธิภาพ
ความท้าทายของความสามารถในการปรับขนาดบล็อกเชนส่วนใหญ่มาจากสถาปัตยกรรมแบบกระจายและกลไกฉันทามติ: กลไกฉันทามติและลักษณะการกระจายของบล็อกเชนต้องการให้ทุกโหนดในเครือข่ายตรวจสอบและบันทึกธุรกรรมทั้งหมด ซึ่งจำกัดปริมาณงานของเครือข่าย นอกจากนี้ การรักษาความปลอดภัยและคุณสมบัติการกระจายอำนาจของบล็อกเชนต้องการให้โหนดทั้งหมดรักษาสำเนาบล็อกเชนให้สมบูรณ์ ซึ่งจะเพิ่มภาระในการจัดเก็บและการส่งข้อมูล
เพื่อจัดการกับความท้าทายของความสามารถในการปรับขนาดบล็อกเชน นักวิจัยได้เสนอโซลูชันการปรับขนาดที่หลากหลาย เช่น โซลูชัน Sharding, Sidechains และเลเยอร์ 2: วิธีการเหล่านี้มีจุดมุ่งหมายเพื่อปรับปรุงปริมาณงานและประสิทธิภาพของเครือข่ายโดยการแบ่งเครือข่ายออกเป็นส่วนเล็ก ๆ แนะนำบล็อกเชนที่เป็นอิสระ หรือสร้างโครงสร้างเพิ่มเติม บนห่วงโซ่หลัก อย่างไรก็ตาม โซลูชันเหล่านี้นำมาซึ่งความท้าทายด้านเทคนิคและปัญหาด้านความปลอดภัยใหม่ๆ เช่น การสื่อสารระหว่างชาร์ด การถ่ายโอนสินทรัพย์ข้ามชาร์ด และการออกแบบกลไกที่เป็นเอกฉันท์
TON blockchain ซึ่งมีต้นกำเนิดจาก Telegram เกิดขึ้นโดยมีแนวคิดในการให้บริการฐานผู้ใช้จำนวนมาก Telegram เป็นหนึ่งในแพลตฟอร์มโซเชียลที่ได้รับความนิยมมากที่สุดในโลก โดยมีผู้ใช้งานมากกว่า 800 ล้านคนต่อเดือน และส่งข้อความนับพันล้านข้อความภายในซอฟต์แวร์ทุกวัน TON ซึ่งเป็นการโจมตีของ Telegram สู่ web3 ได้รับการออกแบบตั้งแต่เริ่มแรกเพื่อรองรับผู้ใช้นับพันล้านราย ไม่ใช่แค่ฐานผู้ใช้ขนาดเล็ก
การแบ่งส่วนย่อยของ TON เป็นแบบจากล่างขึ้นบน: แม้ว่าแผนการแบ่งส่วนบล็อกเชนแบบเดิมมักจะใช้แนวทางจากบนลงล่าง โดยสร้างบล็อกเชนเดี่ยวขึ้นมาก่อน จากนั้นจึงแยกย่อยออกเป็นบล็อกเชนเชิงโต้ตอบเพื่อเพิ่มประสิทธิภาพ แต่การแบ่งส่วนย่อยของ TON ใช้แนวทางจากล่างขึ้นบน โดยจะจัดกลุ่มบัญชีเหล่านี้ออกเป็น shardchain โดยสร้าง Shardchain โดยที่ Workchains มีอยู่ในรูปแบบเสมือนหรือเชิงตรรกะเท่านั้น TON ประสบความสำเร็จในการประมวลผลธุรกรรมแบบคู่ขนานข้ามเครือข่ายต่างๆ ที่เรียกว่า "บล็อกเชนแห่งบล็อกเชน" วิธีการนี้จะช่วยเพิ่มประสิทธิภาพของระบบได้อย่างมีประสิทธิภาพ
TON มีสถาปัตยกรรมการแบ่งส่วนแบบไดนามิก ซึ่งประกอบด้วยมาสเตอร์เชน เวิร์กเชน และชาร์ดเชน: พิกัดมาสเตอร์เชน ในขณะที่การประมวลผลธุรกรรมจริงเกิดขึ้นภายในเวิร์กเชนและชาร์ดเชนต่างๆ นอกจากนี้ การแบ่งส่วนข้อมูลของ TON ยังเป็นแบบไดนามิก โดยแต่ละบัญชีจะทำหน้าที่เป็นชาร์ดเชน สิ่งเหล่านี้สามารถรวมกันเป็น shardchains ที่ใหญ่ขึ้นได้ โดยขึ้นอยู่กับการโต้ตอบระหว่างบัญชี เพื่อตอบสนองความต้องการในการขยายแบบไดนามิก
หากการแบ่งส่วนข้อมูลถึงขีดจำกัด แต่ละชาร์ดเชนจะจัดเก็บเพียงบัญชีเดียวหรือสัญญาอัจฉริยะเท่านั้น สิ่งนี้ส่งผลให้เกิด “account-chain” จำนวนมากที่อธิบายสถานะและการเปลี่ยนแปลงของแต่ละบัญชี โดย chain เหล่านี้ส่งข้อมูลร่วมกัน สร้าง Workchain ผ่าน Shardchains
ข้อความ: เนื่องจาก TON ใช้ฟังก์ชัน send_raw_message ของ FunC เพื่อพัฒนาภาษา ข้อความที่ส่งผ่านโหนด TON จึงเรียกว่า "ข้อความ" ธุรกรรมใน TON ประกอบด้วยข้อความขาเข้าที่ทริกเกอร์ในตอนแรกและชุดข้อความขาออกที่ส่งไปยังสัญญาอื่น
การกำหนดเส้นทางไฮเปอร์คิวบ์: กลไกการส่งข้อความที่มีโครงสร้างสามมิติที่ช่วยให้ข้อความที่สร้างขึ้นในหนึ่งบล็อกของเชนที่แบ่งส่วนสามารถจัดส่งและประมวลผลอย่างรวดเร็วไปยังบล็อกถัดไปของเชนที่แบ่งส่วนเป้าหมาย
การโทรแบบอะซิงโครนัสทำให้เกิดความท้าทายในการซิงโครไนซ์: ในบล็อกเชนแบบซิงโครนัส ธุรกรรมสามารถรวมถึงการเรียกสัญญาอัจฉริยะหลายรายการ ในระบบอะซิงโครนัส ผู้ใช้ไม่สามารถรับการตอบสนองจากสัญญาอัจฉริยะเป้าหมายในธุรกรรมเดียวกันได้ทันที ความล่าช้านี้เกิดขึ้นเนื่องจากการเรียกสัญญาอาจใช้เวลาหลายบล็อกในการประมวลผล และระยะทางในการกำหนดเส้นทางระหว่างบล็อกต้นทางและปลายทางส่งผลต่อกระบวนการนี้
เพื่อให้บรรลุการแบ่งส่วนข้อมูลแบบไม่มีที่สิ้นสุด จำเป็นอย่างยิ่งที่จะต้องแน่ใจว่าข้อความมีความขนานกันอย่างสมบูรณ์ ซึ่งนำไปสู่การแนะนำแนวคิดเรื่องเวลาเชิงตรรกะ: ใน TON แต่ละธุรกรรมจะดำเนินการในสัญญาอัจฉริยะเดียวเท่านั้น และสื่อสารระหว่างสัญญาโดยใช้ข้อความ สิ่งนี้แนะนำแนวคิดเรื่องเวลาแบบลอจิคัลในเครือข่ายแบบอะซิงโครนัส ซึ่งช่วยให้สามารถซิงโครไนซ์ข้อความระหว่างเครือข่ายได้ แต่ละข้อความมีเวลาตรรกะหรือเวลาแลมพอร์ต (ต่อไปนี้จะเรียกว่า lt) เวลานี้ใช้เพื่อติดตามความสัมพันธ์ระหว่างเหตุการณ์และกำหนดว่าผู้ตรวจสอบเหตุการณ์ใดที่ต้องดำเนินการก่อน
รับประกันตรรกะการดำเนินการโดยปฏิบัติตามลำดับการดำเนินการของข้อความ lt อย่างเคร่งครัด: ข้อความที่ส่งจากบัญชีและธุรกรรมที่เกิดขึ้นในบัญชีจะได้รับการสั่งซื้ออย่างเคร่งครัด โดยจำนวนธุรกรรมที่สร้างขึ้นมากกว่า lt ของข้อความ นอกจากนี้ จำนวนข้อความที่ส่งในธุรกรรมจะมากกว่าจำนวนข้อความของธุรกรรมที่ทำให้เกิดข้อความอย่างเคร่งครัด ในกรณีที่มีข้อความหลายข้อความ ข้อความที่มีค่า lt ต่ำกว่าจะได้รับการประมวลผลเร็วกว่า
TON ใช้การดำเนินการแบบขนานกับ Fast Routing + Slow Routing:
การกำหนดเส้นทางที่ช้า: วิธีการประมวลผลข้อมูลแบบข้ามสายโซ่แบบดั้งเดิมที่มีความเสถียรมากกว่า โดยที่ข้อมูลจะถูกบรรจุลงในบล็อกบนสายโซ่ต้นทาง จากนั้นจึงถ่ายทอดจากสายโซ่ชิ้นส่วนหนึ่งไปยังอีกสายหนึ่งผ่านรีเลย์ สามารถใช้โซ่ชาร์ดตัวกลางหลายตัวในการส่งสัญญาณได้ ชาร์ดเชนทั้งหมดก่อตัวเป็นกราฟ "ไฮเปอร์คิวบ์" และข้อความจะแพร่กระจายไปตามขอบของไฮเปอร์คิวบ์นี้ หลังจากการตรวจสอบความถูกต้องโดยผู้ตรวจสอบความถูกต้อง ข้อมูลจะถูกบรรจุลงในบล็อกอื่น
ข้อดีของ Slow Routing อยู่ที่ความปลอดภัยและการกระจายอำนาจที่สูงขึ้น เนื่องจากข้อมูลทั้งหมดจำเป็นต้องผ่านกระบวนการยืนยันบล็อกโดยสมบูรณ์ สำหรับเครือข่ายไฮเปอร์คิวบ์ของชาร์ดเชนที่มีสเกล N จำนวนเส้นทางที่กระโดด = log16(N) ดังนั้นจึงจำเป็นต้องมีโหนดการกำหนดเส้นทางเพียง 4 โหนดเพื่อรองรับชาร์ดเชนนับล้าน
การกำหนดเส้นทางแบบรวดเร็ว: ในการกำหนดเส้นทางแบบช้า ข้อความจะเผยแพร่ไปตามขอบของไฮเปอร์คิวบ์ เพื่อเร่งความเร็ว Fast Routing ช่วยให้ผู้ตรวจสอบความถูกต้องของห่วงโซ่ชาร์ดปลายทางประมวลผลข้อความล่วงหน้า แสดงหลักฐาน Merkle และส่งใบเสร็จรับเงินเพื่อทำลายข้อความที่ส่งสัญญาณ
การกำหนดเส้นทางด่วนนั้นเร็วกว่า (โหนดสามารถค้นหาเส้นทางที่เหมาะสมที่สุด) และป้องกันการส่งซ้ำซ้อน อย่างไรก็ตาม ไม่สามารถแทนที่ Slow Routing ได้ เนื่องจากผู้ตรวจสอบความถูกต้องจะไม่ถูกลงโทษสำหรับการสูญเสียใบเสร็จรับเงิน ซึ่งก่อให้เกิดความเสี่ยงด้านความปลอดภัย
“ถุงของเซลล์”: ชุดของเซลล์ที่ได้รับการอัปเดตในลักษณะที่คล้ายคลึงกับ Directed Acyclic Graph (DAG) สิ่งนี้เกี่ยวข้องกับการแสดงสถานะใหม่เป็น "ถุงของเซลล์" อีกอันหนึ่งที่มีรากของมันเอง จากนั้นจึงรวมชุดเซลล์ใหม่และชุดเก่าในขณะเดียวกันก็กำจัดรากเก่าออกไปพร้อมกัน
การซ่อมแซมบล็อกแนวตั้ง: ใน TON shard chain แต่ละบล็อกไม่ได้เป็นเพียงบล็อกเดียว แต่เป็นโซ่ เมื่อจำเป็นต้องแก้ไขบล็อกในห่วงโซ่ชิ้นส่วนที่ผิดพลาด บล็อกใหม่จะถูกส่งไปยัง "ห่วงโซ่บล็อกแนวตั้ง" เพื่อทำการเปลี่ยนบล็อก
เครือข่าย POS ประกอบด้วยสามบทบาท:
BFT (Byzantine Fault Tolerance ): TON หลังจากชั่งน้ำหนักตัวเลือกแล้ว เลือก BFT มากกว่า DPOS เนื่องจากมีระดับความน่าเชื่อถือและความเร็วที่สูงกว่า แม้ว่า DPOS จะเร็วกว่าก็ตาม
TON บรรลุความเร็วในการทำธุรกรรมสูงและขั้นสุดท้ายผ่านสถาปัตยกรรมหลายส่วนแบบไดนามิก: กระเป๋าเงินผู้ใช้แต่ละรายใน TON สามารถมีสายโซ่ของตัวเองได้ และพื้นฐานทางทฤษฎีสำหรับ TPS สูงนั้นรวมถึงการคำนวณส่วนแบ่งข้อมูลแบบขนาน การสนับสนุนการสื่อสารข้ามส่วนทันที และการสนับสนุน TVM การคำนวณแบบอะซิงโครนัส
TON นำความสามารถในการปรับขนาดที่สูงขึ้นผ่านกลไกการส่งผ่านข้อมูล: ใน TON blockchain การเรียกระหว่างสัญญาอัจฉริยะเป็นแบบอะซิงโครนัสแทนที่จะเป็นแบบอะตอมมิก ซึ่งหมายความว่าเมื่อสัญญาอัจฉริยะอันหนึ่งเรียกอีกอันหนึ่ง การโทรจะไม่ถูกดำเนินการทันที แต่จะถูกประมวลผลในบล็อกในอนาคตหลังจากธุรกรรมสิ้นสุดลง การออกแบบนี้ช่วยให้สามารถขยายขนาดได้สูงขึ้น เนื่องจากไม่จำเป็นต้องดำเนินการประมวลผลธุรกรรมทั้งหมดให้เสร็จสิ้นในบล็อกเดียว
แผนงานทางเทคนิคของ TON จะช่วยเพิ่มความเร็วและข้อได้เปรียบด้านความสามารถในการปรับขนาดของ TON อย่างต่อเนื่อง: