ผู้เขียนต้นฉบับ: @Web3 Mario
บทนำ: ด้วยการเปิดตัว Notcoin เกมที่ใหญ่ที่สุดในระบบนิเวศ TON บน Binance และผลกระทบด้านความมั่งคั่งมหาศาลที่เกิดจากรูปแบบเศรษฐกิจโทเค็นที่หมุนเวียนอย่างเต็มรูปแบบ TON ได้รับความสนใจอย่างมากในช่วงเวลาสั้น ๆ หลังจากพูดคุยกับเพื่อน ฉันได้เรียนรู้ว่าเกณฑ์ทางเทคนิคของ TON นั้นค่อนข้างสูง และกระบวนทัศน์การพัฒนา DApp นั้นแตกต่างอย่างมากจากโปรโตคอลลูกโซ่สาธารณะทั่วไป ดังนั้นฉันจึงใช้เวลาทำการวิจัยเชิงลึกในหัวข้อที่เกี่ยวข้องและแบ่งปันข้อมูลเชิงลึกบางอย่างกับคุณ กล่าวโดยย่อ แนวคิดการออกแบบหลักของ TON คือการสร้างโปรโตคอลบล็อกเชนแบบดั้งเดิมขึ้นใหม่ในลักษณะ จากล่างขึ้นบน และบรรลุการทำงานพร้อมกันสูงและความสามารถในการปรับขนาดสูงโดยเสียค่าใช้จ่ายในการทำงานร่วมกัน
แนวคิดการออกแบบหลักของ TON - การทำงานพร้อมกันสูงและความสามารถในการปรับขนาดสูง
อาจกล่าวได้ว่าจุดประสงค์ของการเลือกเทคโนโลยีที่ซับซ้อนทั้งหมดใน TON นั้นมาจากการแสวงหาความพร้อมกันสูงและความสามารถในการขยายขนาดสูง แน่นอนว่าไม่ใช่เรื่องยากสำหรับเราที่จะเข้าใจสิ่งนี้จากภูมิหลังของมัน TON หรือ The Open Network คือเครือข่ายคอมพิวเตอร์แบบกระจายอำนาจที่ประกอบด้วยบล็อกเชน L1 และส่วนประกอบหลายรายการ TON เดิมได้รับการพัฒนาโดย Nikolai Durov ผู้ก่อตั้ง Telegram และทีมงานของเขา และขณะนี้ได้รับการสนับสนุนและดูแลโดยชุมชนผู้มีส่วนร่วมอิสระระดับโลก วันเกิดของมันย้อนกลับไปในปี 2017 เมื่อทีม Telegram เริ่มสำรวจโซลูชันบล็อคเชนด้วยตนเอง เนื่องจากไม่มีบล็อกเชน L1 ที่มีอยู่ในขณะนี้สามารถรองรับฐานผู้ใช้หลักเก้าหลักของ Telegram พวกเขาจึงตัดสินใจออกแบบบล็อกเชนของตัวเอง จากนั้นจึงเรียกว่า Telegram Open Network เวลามาถึงปี 2018 เพื่อให้ได้ทรัพยากรที่จำเป็นในการดำเนินการ TON Telegram ได้เปิดตัวการขายโทเค็น Gram (ต่อมาเปลี่ยนชื่อเป็น Toncoin) ในไตรมาสแรกของปี 2018 ในปี 2020 ทีม Telegram ถอนตัวจากโครงการ TON เนื่องจากปัญหาด้านกฎระเบียบ ต่อมา นักพัฒนาโอเพ่นซอร์สกลุ่มเล็กๆ และผู้ชนะการแข่งขัน Telegram เข้าครอบครองฐานโค้ดของ TON เปลี่ยนชื่อโครงการเป็น The Open Network และยังคงพัฒนาบล็อกเชนอย่างแข็งขันมาจนถึงทุกวันนี้ โดยยึดมั่นในหลักการที่ระบุไว้ในเอกสารไวท์เปเปอร์ต้นฉบับของ TON
ดังนั้นเนื่องจากได้รับการออกแบบให้เป็นสภาพแวดล้อมการดำเนินการแบบกระจายอำนาจสำหรับ Telegram จึงต้องเผชิญกับปัญหาสองประการ คำขอที่เกิดขึ้นพร้อมกันในระดับสูง และข้อมูลจำนวนมาก เรารู้ว่าด้วยการพัฒนาเทคโนโลยีจนถึงปัจจุบัน Solana ซึ่งเป็นที่รู้จักในนาม TPS ที่สูงที่สุด มี TPS ที่วัดได้สูงสุด 65,000 ซึ่งเห็นได้ชัดว่าไม่เพียงพอที่จะรองรับระบบนิเวศของ Telegram ที่ต้องใช้ TPS หลายล้าน ในเวลาเดียวกัน ด้วยแอปพลิเคชัน Telegram ขนาดใหญ่ ปริมาณข้อมูลที่สร้างขึ้นจึงเกินขีดจำกัด เนื่องจากเป็นระบบกระจายที่ซ้ำซ้อนอย่างมาก บล็อกเชนจึงต้องการให้ทุกโหนดในเครือข่ายบันทึกสำเนาข้อมูลทั้งหมด ไม่สมจริงเช่นกัน
ดังนั้น เพื่อแก้ไขปัญหาสองข้อข้างต้น TON ได้ทำการปรับให้เหมาะสมสองประการกับโปรโตคอลบล็อกเชนหลัก:
ด้วยการใช้ Infinite Sharding Paradigm ในการออกแบบระบบ เราจะแก้ไขปัญหาความซ้ำซ้อนของข้อมูลเพื่อให้สามารถส่งข้อมูลขนาดใหญ่และบรรเทาปัญหาคอขวดของประสิทธิภาพได้
ด้วยการแนะนำสภาพแวดล้อมการดำเนินการแบบขนานโดยสมบูรณ์ตามโมเดล Actor ทำให้ TPS ของเครือข่ายได้รับการปรับปรุงอย่างมาก
สร้างห่วงโซ่บล็อกเชน - ด้วยความสามารถในการแบ่งส่วนข้อมูลไม่จำกัด แต่ละบัญชีมีห่วงโซ่บัญชีพิเศษ
ตอนนี้เรารู้แล้วว่าการแบ่งส่วนกลายเป็นโซลูชันหลักสำหรับโปรโตคอลบล็อกเชนส่วนใหญ่เพื่อปรับปรุงประสิทธิภาพและลดต้นทุน และ TON ได้นำสิ่งนี้ไปสู่จุดสูงสุดและเสนอกระบวนทัศน์การแบ่งส่วนแบบไม่มีที่สิ้นสุด หรือที่เรียกว่ากระบวนทัศน์การแบ่งส่วนแบบไม่มีที่สิ้นสุด ซึ่งหมายถึงการอนุญาตให้บล็อกเชนทำได้ เพิ่มหรือลดจำนวนชาร์ดแบบไดนามิกตามโหลดของเครือข่าย กระบวนทัศน์นี้ช่วยให้ TON สามารถจัดการธุรกรรมขนาดใหญ่และการดำเนินการสัญญาอัจฉริยะในขณะที่ยังคงรักษาประสิทธิภาพที่สูงไว้ได้ ตามทฤษฎีแล้ว TON สามารถสร้างห่วงโซ่บัญชีพิเศษสำหรับแต่ละบัญชีและรับรองการทำงานร่วมกันระหว่างเครือข่ายเหล่านี้ผ่านกฎเกณฑ์บางประการ
เพื่อให้เข้าใจเชิงนามธรรม โครงสร้างลูกโซ่ใน TON มีทั้งหมดสี่ระดับ:
ห่วงโซ่บัญชี: ห่วงโซ่ชั้นนี้แสดงถึงห่วงโซ่ที่ประกอบด้วยชุดของธุรกรรมที่เกี่ยวข้องกับบัญชี เหตุผลที่ธุรกรรมสามารถสร้างโครงสร้างลูกโซ่ได้ก็เพราะสำหรับเครื่องของรัฐ ตราบใดที่กฎการดำเนินการสอดคล้องกัน เครื่องของรัฐจะ ผลลัพธ์ที่ได้รับหลังจากได้รับคำสั่งในลำดับเดียวกันนั้นมีความสอดคล้องกัน ดังนั้นการเรียงลำดับธุรกรรมแบบลูกโซ่จึงเป็นสิ่งจำเป็นในระบบกระจายบล็อคเชนทั้งหมด และ TON ก็ไม่มีข้อยกเว้น ห่วงโซ่บัญชีเป็นหน่วยองค์ประกอบพื้นฐานที่สุดในเครือข่าย TON โดยปกติแล้วห่วงโซ่บัญชีจะเป็นแนวคิดเสมือน และไม่น่าเป็นไปได้ที่จะมีห่วงโซ่บัญชีอิสระอยู่จริง
Shard Chain: ในบริบทส่วนใหญ่ shard chain คือหน่วยส่วนประกอบจริงใน TON สิ่งที่เรียกว่า shard chain คือชุดของห่วงโซ่บัญชี
WorkChain: นอกจากนี้ยังสามารถเรียกได้ว่าเป็นชุดของ sharding chains ที่มีกฎที่กำหนดเอง เช่น การสร้างห่วงโซ่งานที่ใช้ EVM และเรียกใช้ Solidity smart Contracts ตามทฤษฎีแล้ว ทุกคนในชุมชนสามารถสร้างห่วงโซ่งานของตนเองได้ ในความเป็นจริง การสร้างมันเป็นงานที่ค่อนข้างซับซ้อน นำหน้าด้วยการจ่ายค่าธรรมเนียม (แพง) เพื่อสร้างมัน และได้รับคะแนนเสียง 2/3 ของผู้ตรวจสอบเพื่ออนุมัติการสร้างห่วงโซ่การทำงานของคุณ
Main chain (MasterChain): ในที่สุดก็มี chain พิเศษใน TON ที่เรียกว่า main chain ซึ่งมีหน้าที่รับผิดชอบในการนำความสมบูรณ์มาสู่ Shard Chain ทั้งหมด เมื่อแฮชของบล็อกของชาร์ดเชนรวมเข้ากับบล็อกของเชนหลักแล้ว ชาร์ดเชนบล็อกนั้นและบล็อกพาเรนต์ทั้งหมดจะถือเป็นที่สิ้นสุด ซึ่งหมายความว่าเนื้อหาเหล่านั้นจะถือว่าคงที่และไม่สามารถแตกหักได้ ห่วงโซ่.
ด้วยการนำกระบวนทัศน์ดังกล่าวมาใช้ เครือข่าย TON จึงมีลักษณะสามประการดังต่อไปนี้:
การแบ่งส่วนแบบไดนามิก: TON สามารถแยกและรวมกลุ่มส่วนย่อยโดยอัตโนมัติเพื่อปรับให้เข้ากับการเปลี่ยนแปลงของโหลด ซึ่งหมายความว่าบล็อกใหม่จะถูกสร้างขึ้นอย่างรวดเร็วเสมอ และธุรกรรมไม่ต้องรอนาน
ปรับขนาดได้สูง: ด้วยกระบวนทัศน์การแบ่งส่วนข้อมูลแบบไม่มีที่สิ้นสุด TON สามารถรองรับส่วนย่อยได้เกือบไม่จำกัดจำนวน และในทางทฤษฎีแล้วสามารถเข้าถึง 2 ถึงกำลังของ 60 ห่วงโซ่งาน
ความสามารถในการปรับตัว: เมื่อโหลดเพิ่มขึ้นบนส่วนหนึ่งของเครือข่าย ส่วนนั้นสามารถแบ่งออกเป็นส่วนต่างๆ ได้มากขึ้นเพื่อรองรับปริมาณธุรกรรมที่เพิ่มขึ้น ในทางกลับกัน เมื่อโหลดลดลง ก็สามารถรวมชิ้นส่วนเข้าด้วยกันเพื่อเพิ่มประสิทธิภาพได้
สิ่งแรกที่ระบบหลายสายโซ่ต้องเผชิญคือปัญหาของการสื่อสารข้ามสายโซ่ โดยเฉพาะอย่างยิ่งเนื่องจากความสามารถในการแบ่งส่วนข้อมูลแบบไม่จำกัด เมื่อจำนวนส่วนแบ่งข้อมูลในเครือข่ายถึงระดับหนึ่ง ข้อมูลจะกำหนดเส้นทางระหว่างสายโซ่ จะกลายเป็นสิ่งที่ทำได้ยาก ลองนึกภาพว่ามี 4 โหนดในเครือข่าย และแต่ละโหนดมีหน้าที่รับผิดชอบในการรักษาห่วงโซ่การทำงานที่เป็นอิสระ ความสัมพันธ์ของลิงก์บ่งชี้ว่านอกเหนือจากการรับผิดชอบในการเรียงลำดับธุรกรรมในห่วงโซ่งานของตัวเองแล้ว โหนดยังต้องตรวจสอบและประมวลผลสถานะอีกด้วย การเปลี่ยนแปลงในห่วงโซ่เป้าหมาย ซึ่งนำไปใช้โดยเฉพาะใน TON โดยการตรวจสอบข้อความในคิวเอาต์พุต
สมมติว่าบัญชี A ในสายงาน 1 ต้องการส่งข้อความไปยังบัญชี C ในสายงาน 3 คุณต้องออกแบบปัญหาการกำหนดเส้นทางข้อความ ในตัวอย่างนี้ มีสองเส้นทางเส้นทาง ห่วงโซ่งาน 1 -> ห่วงโซ่งาน 2 -> ห่วงโซ่งาน 3 และห่วงโซ่งาน 1 -> ห่วงโซ่งาน 4 -> ห่วงโซ่งาน 3
เมื่อเผชิญกับสถานการณ์ที่ซับซ้อนมากขึ้น จำเป็นต้องใช้อัลกอริธึมการกำหนดเส้นทางที่มีประสิทธิภาพและต้นทุนต่ำเพื่อให้การสื่อสารข้อความเสร็จสมบูรณ์ได้อย่างรวดเร็ว TON เลือกสิ่งที่เรียกว่า อัลกอริธึมการกำหนดเส้นทางไฮเปอร์คิวบ์ เพื่อให้ทราบถึงการค้นหาเส้นทางการสื่อสารข้อความข้ามสายโซ่ โครงสร้างไฮเปอร์คิวบ์ที่เรียกว่าโครงสร้างเครือข่ายแบบพิเศษ ไฮเปอร์คิวบ์ขนาด n ประกอบด้วยจุดยอด 2^n และแต่ละจุดยอดสามารถระบุได้ไม่ซ้ำกันด้วยเลขฐานสอง n บิต ในโครงสร้างนี้ จุดยอดสองจุดจะติดกันหากต่างกันเพียงบิตเดียวในการแทนค่าไบนารี ตัวอย่างเช่น ในไฮเปอร์คิวบ์ 3 มิติ จุดยอด 000 และ 001 อยู่ติดกันเนื่องจากต่างกันเฉพาะในบิตสุดท้าย ตัวอย่างข้างต้นคือไฮเปอร์คิวบ์ 2 มิติ
ในโปรโตคอลการกำหนดเส้นทางไฮเปอร์คิวบ์ กระบวนการกำหนดเส้นทางของข้อความจากห่วงโซ่งานต้นทางไปยังห่วงโซ่งานเป้าหมายจะดำเนินการโดยการเปรียบเทียบการแสดงไบนารีของห่วงโซ่งานต้นทางและที่อยู่ของห่วงโซ่งานเป้าหมาย อัลกอริธึมการกำหนดเส้นทางค้นหาระยะทางขั้นต่ำ (เช่น จำนวนบิตที่แตกต่างกันในการแสดงไบนารี่) ระหว่างที่อยู่ทั้งสองนี้ และส่งต่อข้อมูลอย่างต่อเนื่องผ่านสายงานที่อยู่ติดกันจนกระทั่งถึงสายงานเป้าหมาย วิธีการนี้ช่วยให้มั่นใจได้ว่าแพ็กเก็ตข้อมูลจะถูกส่งไปตามเส้นทางที่สั้นที่สุด ซึ่งจะช่วยปรับปรุงประสิทธิภาพการสื่อสารของเครือข่าย
แน่นอนว่า เพื่อทำให้กระบวนการนี้ง่ายขึ้น TON ยังได้เสนอวิธีแก้ปัญหาทางเทคนิคในแง่ดี เมื่อผู้ใช้สามารถพิสูจน์เส้นทางเส้นทางที่แน่นอนได้ ซึ่งโดยปกติแล้วจะเป็น Merkle Trie Root โหนดก็จะสามารถรับรู้ความน่าเชื่อถือของ ข้อความที่ผู้ใช้ส่งมา ซึ่งเรียกอีกอย่างว่าการกำหนดเส้นทางไฮเปอร์คิวบ์แบบทันที
ดังนั้นเราจึงเห็นได้ว่ามีความแตกต่างที่ชัดเจนระหว่างที่อยู่ใน TON และโปรโตคอลบล็อกเชนอื่น ๆ ส่วนใหญ่ใช้แฮชที่สอดคล้องกับคีย์สาธารณะในคีย์สาธารณะและคีย์ส่วนตัวที่สร้างโดยอัลกอริธึมการเข้ารหัสแบบวงรีเป็นที่อยู่ เนื่องจาก ที่อยู่จะถูกใช้เป็นที่อยู่ที่ไม่ซ้ำกันเท่านั้น ไม่จำเป็นต้องมีฟังก์ชันการกำหนดเส้นทาง และที่อยู่ใน TON ประกอบด้วยสองส่วน (workchain_id, account_id) โดยที่ workchain_id จะถูกเข้ารหัสตามที่อยู่อัลกอริธึมการกำหนดเส้นทางไฮเปอร์คิวบ์ ซึ่ง จะไม่อธิบายเพิ่มเติมที่นี่
มีอีกประเด็นหนึ่งที่ทำให้เกิดข้อสงสัยได้ง่าย คุณอาจสังเกตเห็นว่า main chain มีความสัมพันธ์เชื่อมโยงกับแต่ละ chain ทำงาน ดังนั้นข้อมูล cross-chain ทั้งหมดจะไม่เพียงพอต่อการถ่ายทอดผ่าน main chain เพียงเท่านั้น เหมือนคอสมอส ในแนวคิดการออกแบบของ TON สายโซ่หลักจะใช้เพื่อจัดการกับงานที่สำคัญที่สุดเท่านั้น ซึ่งก็คือการรักษาขั้นสุดท้ายของสายโซ่งานจำนวนมาก เป็นไปไม่ได้ที่จะกำหนดเส้นทางข้อความผ่านสายโซ่หลัก แต่ค่าธรรมเนียมการจัดการที่เกิดขึ้นจะมีราคาแพงมาก .
สุดท้ายนี้ เราจะพูดถึงอัลกอริธึมที่เป็นเอกฉันท์โดยย่อ TON ใช้วิธี BFT+PoS กล่าวคือ ผู้เดิมพันรายใดก็ตามมีโอกาสที่จะมีส่วนร่วมในการบรรจุบล็อก สัญญาการกำกับดูแลการเลือกตั้งของ TON จะสุ่มเลือกผู้ตรวจสอบบรรจุภัณฑ์จาก Stakers ทั้งหมดในช่วงเวลาปกติ คลัสเตอร์ โหนดที่เลือกเป็นผู้ตรวจสอบความถูกต้องจะจัดทำแพ็กเกจและสร้างบล็อกผ่านอัลกอริธึม BFT หากทำแพ็กเกจข้อมูลที่ไม่ถูกต้องหรือทำสิ่งชั่วร้าย โทเค็นการเดิมพันจะถูกริบ มิฉะนั้นจะได้รับรางวัลบล็อก นี่เป็นตัวเลือกทั่วไป ดังนั้นฉันจะไม่แนะนำมันที่นี่
สัญญาอัจฉริยะและสภาพแวดล้อมการดำเนินการแบบขนานโดยสมบูรณ์ตามโมเดลนักแสดง
ข้อแตกต่างอีกประการระหว่าง TON และโปรโตคอลบล็อกเชนหลักคือสภาพแวดล้อมการดำเนินการตามสัญญาอัจฉริยะ เพื่อทำลายข้อจำกัดของโปรโตคอลบล็อกเชนกระแสหลัก TPS นั้น TON จึงใช้แนวคิดการออกแบบจากล่างขึ้นบน และใช้โมเดล Actor เพื่อสร้างสัญญาอัจฉริยะและวิธีการดำเนินการใหม่ เพื่อให้มีความสามารถในการขนานกันอย่างสมบูรณ์
เรารู้ว่าโปรโตคอลบล็อกเชนกระแสหลักส่วนใหญ่ใช้สภาพแวดล้อมการดำเนินการแบบอนุกรมแบบเธรดเดียว เมื่อพิจารณาจาก Ethereum เป็นตัวอย่าง สภาพแวดล้อมการดำเนินการ EVM จะเป็นเครื่องสถานะที่มีธุรกรรมเป็นอินพุต เมื่อโหนดที่สร้างบล็อกทำธุรกรรมให้เสร็จสิ้นโดยบรรจุบล็อกหลังจากการเรียงลำดับ ธุรกรรมจะถูกดำเนินการผ่าน EVM ตามลำดับนี้ กระบวนการทั้งหมดเป็นแบบอนุกรมและแบบเธรดเดียว นั่นคือ ธุรกรรมเดียวเท่านั้นที่สามารถดำเนินการได้ในช่วงเวลาหนึ่ง ข้อดีของสิ่งนี้คือตราบใดที่ลำดับธุรกรรมยังคงอยู่ ยืนยันว่าผลการดำเนินการจะมีความสอดคล้องกันในคลัสเตอร์แบบกระจายที่หลากหลาย ในเวลาเดียวกัน เนื่องจากมีการดำเนินการเพียงรายการเดียวพร้อมกัน ซึ่งหมายความว่าในระหว่างกระบวนการดำเนินการ เป็นไปไม่ได้ที่ธุรกรรมอื่น ๆ แก้ไขข้อมูลสถานะบางอย่างที่จะเข้าถึงเพื่อให้บรรลุการทำงานร่วมกันระหว่างสัญญาอัจฉริยะ ตัวอย่างเช่น เราใช้ USDT เพื่อซื้อ ETH ผ่าน Uniswap เมื่อทำธุรกรรม การกระจาย LP ในคู่การซื้อขายจะเป็นค่าที่แน่นอน ด้วยวิธีนี้ สามารถรับผลลัพธ์ที่สอดคล้องกันผ่านแบบจำลองทางคณิตศาสตร์บางอย่าง แต่สมมติว่าเป็นเช่นนี้ ไม่ใช่กรณี เมื่อทำการคำนวณเส้นโค้งพันธะบางเส้น หาก LP อื่นเพิ่มสภาพคล่องใหม่ ผลการคำนวณจะเป็นผลลัพธ์ที่ล้าสมัยซึ่งเป็นที่ยอมรับไม่ได้อย่างเห็นได้ชัด
แต่สถาปัตยกรรมนี้ก็มีข้อ จำกัด ที่ชัดเจนซึ่งเป็นคอขวดของ TPS และคอขวดนี้ดูเก่ามากภายใต้โปรเซสเซอร์แบบมัลติคอร์ในปัจจุบัน เช่นเดียวกับที่คุณใช้พีซีรุ่นล่าสุดในการเล่นเกมคอมพิวเตอร์เก่า ๆ เช่น Red Alert, When the จำนวนหน่วยรบถึงจำนวนที่กำหนด คุณจะยังคงพบว่ามันค้างอยู่ นี่เป็นปัญหากับสถาปัตยกรรมซอฟต์แวร์
คุณอาจได้ยินว่าโปรโตคอลบางตัวให้ความสนใจกับปัญหานี้อยู่แล้ว และได้เสนอวิธีแก้ปัญหาแบบคู่ขนานของตนเอง ตัวอย่างเช่น Solana ซึ่งปัจจุบันอ้างว่ามี TPS สูงสุด ก็ยังมีความสามารถในการดำเนินการแบบคู่ขนานอีกด้วย อย่างไรก็ตาม แนวคิดการออกแบบแตกต่างจาก TON ใน Solana แนวคิดหลักคือการแบ่งธุรกรรมทั้งหมดออกเป็นหลายกลุ่มตามการพึ่งพาการดำเนินการ และไม่มีการแบ่งปันข้อมูลสถานะระหว่างกลุ่มต่างๆ นั่นคือไม่มีการพึ่งพาที่เหมือนกัน ดังนั้นธุรกรรมในกลุ่มต่างๆ จึงสามารถดำเนินการแบบคู่ขนานได้โดยไม่ต้องกังวลกับข้อขัดแย้ง ในขณะที่ธุรกรรมภายในกลุ่มเดียวกันยังคงดำเนินการในลักษณะอนุกรมแบบดั้งเดิม
ใน TON นั้น ละทิ้งสถาปัตยกรรมการดำเนินการแบบอนุกรมโดยสิ้นเชิง และใช้กระบวนทัศน์การพัฒนาที่ออกแบบมาโดยเฉพาะสำหรับการขนาน ซึ่งเป็นโมเดลนักแสดงแทน เพื่อสร้างสภาพแวดล้อมการดำเนินการขึ้นมาใหม่ รูปแบบที่เรียกว่านักแสดงถูกเสนอครั้งแรกโดย Carl Hewitt ในปี 1973 เพื่อแก้ปัญหาความซับซ้อนของสถานะที่ใช้ร่วมกันในโปรแกรมที่เกิดขึ้นพร้อมกันแบบดั้งเดิมผ่านการส่งข้อความ นักแสดงแต่ละคนมีสถานะและพฤติกรรมส่วนตัวของตัวเอง และไม่เปิดเผยข้อมูลสถานะใดๆ กับนักแสดงคนอื่นๆ โมเดล Actor คือโมเดลการประมวลผลพร้อมกันที่ใช้การประมวลผลแบบขนานผ่านการส่งข้อความ ในโมเดลนี้ นักแสดง เป็นหน่วยการทำงานพื้นฐานที่สามารถประมวลผลข้อความที่ได้รับ สร้างนักแสดงใหม่ ส่งข้อความได้มากขึ้น และตัดสินใจว่าจะตอบกลับข้อความที่ตามมาอย่างไร โมเดลนักแสดงต้องมีคุณสมบัติดังต่อไปนี้:
การห่อหุ้มและความเป็นอิสระ: นักแสดงแต่ละคนมีความเป็นอิสระอย่างสมบูรณ์เมื่อประมวลผลข้อความ และสามารถประมวลผลข้อความแบบขนานโดยไม่รบกวนซึ่งกันและกัน
การส่งข้อความ: นักแสดงโต้ตอบกันโดยการส่งและรับข้อความเท่านั้น และการส่งข้อความเป็นแบบอะซิงโครนัส
โครงสร้างแบบไดนามิก: นักแสดงสามารถสร้างนักแสดงได้มากขึ้นในขณะรันไทม์ ลักษณะแบบไดนามิกนี้ช่วยให้โมเดลนักแสดงสามารถขยายระบบได้ตามต้องการ
TON ใช้สถาปัตยกรรมนี้เพื่อออกแบบโมเดลสัญญาอัจฉริยะ ซึ่งหมายความว่าใน TON สัญญาอัจฉริยะแต่ละอันจะเป็นโมเดลนักแสดงที่มีพื้นที่จัดเก็บข้อมูลที่เป็นอิสระอย่างสมบูรณ์ เพราะไม่ต้องอาศัยข้อมูลภายนอกใดๆ นอกจากนี้ การเรียกไปยังสัญญาอัจฉริยะเดียวกันยังคงดำเนินการตามลำดับของข้อความในคิวการรับ ดังนั้นธุรกรรมใน TON จึงสามารถดำเนินการแบบคู่ขนานได้อย่างมีประสิทธิภาพโดยไม่ต้องกังวลกับข้อขัดแย้ง
อย่างไรก็ตาม รูปแบบการออกแบบดังกล่าวยังนำมาซึ่งผลกระทบใหม่ๆ อีกด้วย สำหรับนักพัฒนา DApp กระบวนทัศน์การพัฒนาที่พวกเขาคุ้นเคยจะถูกทำลาย ดังต่อไปนี้:
1. การเรียกแบบอะซิงโครนัสระหว่างสัญญาอัจฉริยะ: ไม่สามารถเรียกสัญญาภายนอกแบบอะตอมมิกหรือเข้าถึงข้อมูลสัญญาภายนอกภายในสัญญาอัจฉริยะของ TON ได้ เรารู้ว่าใน Solidity ฟังก์ชัน 1 ของสัญญา A จะเรียกใช้ฟังก์ชัน 2 ของสัญญา B หรือเข้าถึงข้อมูลสถานะบางอย่าง ผ่านฟังก์ชันอ่านอย่างเดียว n3 ของสัญญา C กระบวนการทั้งหมดเป็นแบบอะตอมมิกและดำเนินการในธุรกรรมเดียว นี่เป็นเรื่องง่ายมาก อย่างไรก็ตาม ใน TON สิ่งนี้จะไม่สามารถทำได้ การโต้ตอบใด ๆ กับสัญญาอัจฉริยะภายนอก แบบอะซิงโครนัสโดยการบรรจุธุรกรรมใหม่ ธุรกรรมดังกล่าวที่เริ่มต้นโดยสัญญาอัจฉริยะเรียกอีกอย่างว่าข้อความภายใน และไม่สามารถบล็อกได้ระหว่างการดำเนินการเพื่อให้ได้ผลการดำเนินการ
ตัวอย่างเช่น หากเราพัฒนา DEX หากเราใช้กระบวนทัศน์ทั่วไปใน EVM โดยปกติแล้วจะมีสัญญาเราเตอร์แบบรวมที่ใช้เพื่อจัดการการกำหนดเส้นทางธุรกรรม และแต่ละ Pool จะจัดการข้อมูล LP ที่เกี่ยวข้องกับคู่การซื้อขายโดยอิสระ สมมติว่าเป็นเช่นนั้น ขณะนี้มีสองกลุ่ม USDT-DAI และ DAI-ETH เมื่อผู้ใช้ต้องการซื้อ ETH โดยตรงผ่าน USDT เขาหรือเธอสามารถขอพูลทั้งสองนี้ตามลำดับในธุรกรรมเดียวผ่านสัญญาเราเตอร์เพื่อทำธุรกรรมอะตอมมิกให้เสร็จสมบูรณ์ อย่างไรก็ตาม มันไม่ง่ายเลยที่จะนำไปใช้ใน TON จำเป็นต้องคิดถึงกระบวนทัศน์การพัฒนาใหม่ หากยังคงใช้กระบวนทัศน์นี้ซ้ำ การไหลของข้อมูลอาจเป็นเช่นนี้ ผู้ใช้และข้อความภายในสามข้อความเสร็จสมบูรณ์ (โปรดทราบว่าข้อความนี้ใช้เพื่อแสดงความแตกต่าง ในการพัฒนาจริง แม้แต่กระบวนทัศน์ของ ERC 20 ก็จะต้องได้รับการออกแบบใหม่)
2. จำเป็นต้องพิจารณากระบวนการประมวลผลสำหรับข้อผิดพลาดในการดำเนินการอย่างรอบคอบเมื่อทำการเรียกข้ามสัญญา และออกแบบฟังก์ชันตีกลับที่สอดคล้องกันสำหรับการเรียกระหว่างสัญญาแต่ละครั้ง เรารู้ว่าใน EVM กระแสหลัก เมื่อเกิดปัญหาระหว่างการดำเนินการธุรกรรม ธุรกรรมทั้งหมดจะถูกย้อนกลับ กล่าวคือ รีเซ็ตเป็นสถานะเริ่มต้นของการดำเนินการ ซึ่งง่ายต่อการเข้าใจในรุ่นเธรดเดี่ยวแบบอนุกรม อย่างไรก็ตาม ใน TON เนื่องจากการเรียกระหว่างสัญญาจะดำเนินการแบบอะซิงโครนัส แม้ว่าจะมีข้อผิดพลาดเกิดขึ้นในลิงก์ถัดไป เนื่องจากธุรกรรมที่ดำเนินการสำเร็จก่อนหน้านี้ได้รับการดำเนินการและยืนยันแล้ว สิ่งนี้อาจทำให้เกิดปัญหาได้ ดังนั้น ประเภทข้อความพิเศษจึงถูกตั้งค่าเป็น TON ซึ่งเรียกว่าข้อความตีกลับ นั่นคือ เมื่อมีข้อผิดพลาดเกิดขึ้นในขั้นตอนการดำเนินการตามมาซึ่งเกิดจากข้อความภายใน สัญญาที่ถูกกระตุ้นสามารถกระตุ้นให้เกิดเหตุการณ์บางอย่างในสัญญาได้โดยการกระตุ้นให้เกิดการตีกลับ ฟังก์ชั่นที่สงวนไว้ตามสัญญา สถานะบางอย่างจะถูกรีเซ็ต
3. ในสถานการณ์ที่ซับซ้อนบางรายการ ธุรกรรมที่ได้รับก่อนอาจไม่ถูกดำเนินการก่อน ดังนั้นจึงไม่สามารถตั้งค่าความสัมพันธ์ของเวลาล่วงหน้าได้ ในระบบของการเรียกสัญญาอัจฉริยะแบบอะซิงโครนัสและแบบขนาน การกำหนดลำดับการประมวลผลการดำเนินการอาจเป็นเรื่องยาก นี่คือสาเหตุที่แต่ละข้อความใน TON มีเวลาตรรกะ เวลาแลมพอร์ต (ต่อไปนี้จะเรียกว่า lt) ใช้เพื่อทำความเข้าใจว่าเหตุการณ์ใดที่กระตุ้นให้เกิดเหตุการณ์อื่น และสิ่งที่เครื่องมือตรวจสอบต้องจัดการก่อน สำหรับโมเดลแบบง่าย ธุรกรรมที่ได้รับก่อนจะต้องดำเนินการก่อน
ในแบบจำลองนี้ A และ B เป็นตัวแทนของสัญญาอัจฉริยะสองสัญญาตามลำดับ และมีความสัมพันธ์ด้านเวลา เช่น ถ้า msg 1 _lt < msg 2 _lt แล้ว tx 1 _lt < tx 2 _lt
อย่างไรก็ตาม ในสถานการณ์ที่ซับซ้อนมากขึ้น กฎนี้จะถูกทำลาย มีตัวอย่างสิ่งนี้ในเอกสารอย่างเป็นทางการ สมมติว่าเรามีสัญญา A, B และ C สามสัญญา ในการทำธุรกรรม A ส่งข้อความภายในสองข้อความ 1 และ msg 2: ข้อความหนึ่งถึง B และอีกข้อความหนึ่งถึง C แม้ว่าจะถูกสร้างขึ้นตามลำดับที่แน่นอน (msg 1 ก่อนแล้วจึง msg 2) เราไม่สามารถแน่ใจได้ว่า msg 1 จะถูกประมวลผลก่อน msg 2 เนื่องจากเส้นทางจาก A ไป B และจาก A ถึง C อาจมีความยาวและชุดเครื่องมือตรวจสอบที่แตกต่างกัน หากสัญญาเหล่านี้อยู่ในกลุ่มชาร์ดที่แตกต่างกัน ข้อความใดข้อความหนึ่งอาจใช้เวลาหลายช่วงตึกจึงจะบรรลุสัญญาเป้าหมาย นั่นคือเรามีเส้นทางการซื้อขายที่เป็นไปได้สองเส้นทาง ดังแสดงในรูป
4. ใน TON การจัดเก็บข้อมูลสัญญาอัจฉริยะแบบถาวรจะใช้กราฟอะไซคลิกที่มีเซลล์เป็นหน่วยเป็นโครงสร้างข้อมูล ข้อมูลจะถูกบีบอัดลงในเซลล์ตามกฎการเข้ารหัส และในเวลาเดียวกันตามกฎ ทิศทางของกราฟอะไซคลิกแบบกำหนดทิศทางลง ซึ่งแตกต่างจากการจัดโครงสร้างข้อมูลสถานะตามแฮชแมปใน EVM เนื่องจากอัลกอริธึมการร้องขอข้อมูลที่แตกต่างกัน TON จึงกำหนดราคาก๊าซที่แตกต่างกันสำหรับความลึกที่แตกต่างกัน การประมวลผลข้อมูลเซลล์ ยิ่งต้องการ Gas มากเท่าไรก็ยิ่งมีกระบวนทัศน์ของการโจมตี DOS ใน TON มากขึ้นเท่านั้น กล่าวคือ ผู้ใช้ที่เป็นอันตรายบางรายจะครอบครองเซลล์ตื้นทั้งหมดในสัญญาอัจฉริยะโดยการส่งข้อความสแปมจำนวนมาก ซึ่ง หมายความว่าต้นทุนการจัดเก็บข้อมูลของผู้ใช้จริงจะสูงขึ้นเรื่อยๆ ใน EVM เนื่องจากความซับซ้อนในการสืบค้นของ hashmap คือ O(1) จึงมี Gas เหมือนกันและจะไม่มีปัญหาที่คล้ายกัน ดังนั้น นักพัฒนา TON Dapp ควรพยายามหลีกเลี่ยงประเภทข้อมูลที่ไม่จำกัดในสัญญาอัจฉริยะ เมื่อประเภทข้อมูลที่ไม่จำกัดปรากฏขึ้น ควรแยกย่อยออกเป็นการแบ่งส่วน
5. นอกจากนี้ยังมีคุณสมบัติบางอย่างที่พิเศษน้อยกว่า เช่น สัญญาอัจฉริยะที่ต้องจ่ายค่าเช่าสำหรับการจัดเก็บ สัญญาอัจฉริยะใน TON สามารถอัปเกรดได้ตามธรรมชาติ และฟังก์ชันบัญชีนามธรรมดั้งเดิม นั่นคือ ที่อยู่กระเป๋าเงินทั้งหมดใน TON เป็นสัญญาอัจฉริยะ แค่ไม่ได้เริ่มต้น ฯลฯ สิ่งเหล่านี้ทำให้นักพัฒนาต้องให้ความสนใจอย่างระมัดระวัง
ข้างต้นคือประสบการณ์บางส่วนในการเรียนรู้เทคโนโลยีที่เกี่ยวข้องกับ TON ในช่วงเวลานี้ ฉันอยากจะแบ่งปันสิ่งเหล่านี้กับคุณ ฉันหวังว่าคุณจะสามารถแก้ไขฉันได้หากฉันทำผิดไป ในขณะเดียวกัน ฉันคิดว่าด้วยทรัพยากรการรับส่งข้อมูลจำนวนมหาศาลของ Telegram ระบบนิเวศของ TON จะทำหน้าที่เป็นแพลตฟอร์มสำหรับ Web3 อย่างแน่นอน เพื่อน ๆ ที่สนใจในการพัฒนา TON DApp ก็สามารถติดต่อฉันและพูดคุยกับเราได้
ลิงค์ X: https://x.com/web3_mario
โทรเลขจัดการ: @MarioChin Web3
