บทนํา: หลังจาก Binance เปิดตัว Notcoin ซึ่งเป็นเกมที่ใหญ่ที่สุดในระบบนิเวศของ TON และเศรษฐกิจโทเค็นที่หมุนเวียนอย่างเต็มที่ได้สร้างผลกระทบด้านความมั่งคั่งอย่างมาก 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 ทีมโทรเลขถอนตัวออกจากโครงการ TON เนื่องจากปัญหาด้านกฎระเบียบ ต่อจากนั้นนักพัฒนาโอเพ่นซอร์สกลุ่มเล็ก ๆ และผู้ชนะการแข่งขัน Telegram ได้เข้าครอบครองโค้ดเบสของ TON เปลี่ยนชื่อโครงการเป็น The Open Network และยังคงพัฒนาบล็อกเชนอย่างแข็งขันมาจนถึงทุกวันนี้โดยยึดมั่นในหลักการที่ระบุไว้ในเอกสารไวท์เปเปอร์ TON ต้นฉบับ

เนื่องจาก TON ได้รับการออกแบบให้เป็นสภาพแวดล้อมการดําเนินการแบบกระจายอํานาจของ Telegram จึงต้องจัดการกับความท้าทายหลักสองประการ: คําขอพร้อมกันสูงและข้อมูลขนาดใหญ่ แม้แต่ TPS ที่ผ่านการทดสอบสูงสุด (ธุรกรรมต่อวินาที) ของ Solana ซึ่งอ้างว่าเร็วที่สุดก็มีเพียง 65,000 ซึ่งน้อยกว่า TPS ระดับล้านที่จําเป็นสําหรับ Telegram นอกจากนี้ข้อมูลจํานวนมากที่สร้างโดย Telegram ไม่สามารถจัดการได้โดยบล็อกเชนที่ทุกโหนดเก็บสําเนาข้อมูลที่สมบูรณ์

เพื่อรับมือกับความท้าทายเหล่านี้ TON ปรับโปรโตคอลบล็อกเชนกระแสหลักให้เหมาะสมในสองวิธี:

l ใช้ "Infinite Sharding Paradigm" เพื่อลดความซ้ําซ้อนของข้อมูลทําให้สามารถจัดการข้อมูลจํานวนมากและบรรเทาปัญหาคอขวดด้านประสิทธิภาพ

l โดยการแนะนําสภาพแวดล้อมการดําเนินการแบบขนานอย่างสมบูรณ์ตามรูปแบบนักแสดงเครือข่าย TPS ได้รับการปรับปรุงอย่างมาก

Building a Blockchain of Chains - ให้แต่ละบัญชีมีโซ่เฉพาะของตัวเองผ่าน Infinite Sharding

ตอนนี้เรารู้แล้วว่าการแบ่งส่วนได้กลายเป็นโซลูชันหลักสําหรับโปรโตคอลบล็อกเชนส่วนใหญ่เพื่อปรับปรุงประสิทธิภาพและลดต้นทุน และ TON ได้นําสิ่งนี้ไปสู่จุดสูงสุดและเสนอกระบวนทัศน์ Infinite Sharding ที่เรียกว่ากระบวนทัศน์การแบ่งส่วนอนันต์ หมายถึงการอนุญาตให้บล็อกเชนเพิ่มหรือลดจํานวนส่วนแบ่งข้อมูลแบบไดนามิกตามโหลดเครือข่าย กระบวนทัศน์นี้ช่วยให้ TON สามารถจัดการธุรกรรมขนาดใหญ่และการดําเนินการสัญญาอัจฉริยะในขณะที่ยังคงประสิทธิภาพสูง ในทางทฤษฎี TON สามารถสร้างห่วงโซ่บัญชีพิเศษสําหรับแต่ละบัญชีและรับรองการทํางานร่วมกันระหว่างห่วงโซ่เหล่านี้ผ่านกฎบางอย่าง ความสอดคล้อง

โดยพื้นฐานแล้วโครงสร้างโซ่ของ TON ประกอบด้วยสี่ชั้น

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

ShardChain: ในบริบทส่วนใหญ่ ShardChain เป็นหน่วยจริงภายใน TON ShardChain เป็นคอลเลกชันของ AccountChains เป็นหลัก

WorkChain: หรือที่เรียกว่าชุดของ Shard Chain ที่มีกฎที่กําหนดเอง เช่น การสร้าง WorkChain ตาม EVM เพื่อเรียกใช้สัญญาอัจฉริยะ Solidity ในทางทฤษฎีทุกคนในชุมชนสามารถสร้าง WorkChain ของตนเองได้ อย่างไรก็ตามอาคารหนึ่งค่อนข้างซับซ้อนและต้องจ่ายค่าธรรมเนียมการสร้าง (สูง) และได้รับการอนุมัติจาก 2/3 ของผู้ตรวจสอบความถูกต้อง

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

กระบวนทัศน์นี้ทําให้เครือข่าย TON มีคุณสมบัติหลักสามประการ:

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

ความสามารถในการปรับขนาดสูง: ด้วยกระบวนทัศน์การแบ่งส่วนที่ไม่มีที่สิ้นสุด TON สามารถรองรับส่วนแบ่งข้อมูลได้เกือบไม่ จํากัด จํานวนในทางทฤษฎีสูงถึง 2 ^ 60 WorkChains

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

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

สมมติว่าบัญชี A ใน WorkChain 1 ต้องการส่งข้อความไปยังบัญชี C ใน WorkChain 3 สิ่งนี้ต้องออกแบบโซลูชันการกําหนดเส้นทางข้อความ ในตัวอย่างนี้ มีเส้นทางการกําหนดเส้นทางสองเส้นทาง: WorkChain 1 -> WorkChain 2 -> WorkChain 3 และ WorkChain 1 -> WorkChain 4 -> WorkChain 3

ในสถานการณ์ที่ซับซ้อนมากขึ้นอัลกอริธึมการกําหนดเส้นทางที่มีประสิทธิภาพและต้นทุนต่ําเป็นสิ่งจําเป็นสําหรับการสื่อสารข้อความที่รวดเร็ว TON ใช้ "อัลกอริธึมการกําหนดเส้นทางไฮเปอร์คิวบ์" สําหรับการค้นพบการกําหนดเส้นทางข้อความข้ามสายโซ่ โครงสร้างไฮเปอร์คิวบ์เป็นโทโพโลยีเครือข่ายพิเศษที่ไฮเปอร์คิวบ์ n มิติมีจุดยอด 2^n ซึ่งแต่ละจุดจะถูกระบุด้วยเลขฐานสอง n-bit ที่ไม่ซ้ํากัน ในโครงสร้างนี้จุดยอดสองจุดจะอยู่ติดกันหากการแสดงไบนารีของพวกเขาแตกต่างกันเพียงหนึ่งบิต ตัวอย่างเช่นในไฮเปอร์คิวบ์ 3 มิติจุดยอด 000 และจุดยอด 001 อยู่ติดกันเพราะแตกต่างกันเฉพาะในบิตสุดท้าย ตัวอย่างข้างต้นคือไฮเปอร์คิวบ์ 2 มิติ

ในโปรโตคอลการกําหนดเส้นทางไฮเปอร์คิวบ์การกําหนดเส้นทางของข้อความจาก WorkChain ต้นทางไปยัง WorkChain เป้าหมายจะทําได้โดยการเปรียบเทียบที่อยู่ไบนารี อัลกอริทึมจะค้นหาระยะห่างขั้นต่ําระหว่างที่อยู่เหล่านี้ (เช่น จํานวนบิตที่แตกต่างกัน) และส่งต่อข้อความผ่าน WorkChains ที่อยู่ติดกันจนกว่าจะถึงปลายทาง สิ่งนี้ทําให้มั่นใจได้ว่าแพ็กเก็ตข้อมูลเป็นไปตามเส้นทางที่สั้นที่สุดเพิ่มประสิทธิภาพการสื่อสารเครือข่าย เพื่อลดความซับซ้อนของกระบวนการนี้ TON ยังเสนอวิธีแก้ปัญหาในแง่ดี หากผู้ใช้สามารถแสดงหลักฐานที่ถูกต้องของเส้นทางเส้นทางโดยทั่วไปคือราก Merkle trie โหนดสามารถตรวจสอบความถูกต้องของข้อความได้ทันที สิ่งนี้เรียกว่าการกําหนดเส้นทางไฮเปอร์คิวบ์ทันที ด้วยเหตุนี้ ที่อยู่ TON จึงแตกต่างจากที่อยู่ในโปรโตคอลบล็อกเชนอื่นๆ อย่างมาก โปรโตคอลบล็อกเชนส่วนใหญ่ใช้แฮชของคีย์สาธารณะที่สร้างขึ้นโดยอัลกอริธึมการเข้ารหัสวงรีเป็นที่อยู่โดยเน้นที่เอกลักษณ์โดยไม่ต้องใช้ฟังก์ชันการกําหนดเส้นทาง ใน TON ที่อยู่ประกอบด้วยสองส่วน: (workchain_id, account_id) โดย workchain_id เข้ารหัสตามอัลกอริทึมการกําหนดเส้นทางไฮเปอร์คิวบ์ บางคนอาจสงสัยว่าทําไมไม่ถ่ายทอดข้อมูลข้ามสายโซ่ทั้งหมดผ่าน MasterChain คล้ายกับ Cosmos ในการออกแบบของ TON MasterChain จัดการเฉพาะงานที่สําคัญที่สุดในการรักษาขั้นสุดท้ายของ WorkChains แม้ว่าจะเป็นไปได้ที่จะกําหนดเส้นทางข้อความผ่าน MasterChain แต่ค่าธรรมเนียมที่เกี่ยวข้องจะสูงอย่างห้ามปราม

สุดท้ายเรามาพูดถึงอัลกอริทึมฉันทามติสั้น ๆ TON ใช้การรวมกันของ BFT (Byzantine Fault Tolerance) และ PoS (Proof of Stake) ซึ่งหมายความว่าสเตเกอร์ทุกคนสามารถมีส่วนร่วมในการสร้างบล็อกได้ สัญญาธรรมาภิบาลการเลือกตั้ง TON จะเลือกกลุ่มผู้ตรวจสอบความถูกต้องแบบสุ่มจากผู้เดิมพันทั้งหมดเป็นระยะ ผู้ตรวจสอบที่เลือกเหล่านี้จะใช้อัลกอริทึม BFT เพื่อสร้างบล็อก หากผู้ตรวจสอบสร้างบล็อกที่ไม่ถูกต้องหรือกระทําการที่เป็นอันตรายโทเค็นที่เดิมพันของพวกเขาจะถูกยึด ในทางกลับกันพวกเขาได้รับรางวัลสําหรับการสร้างบล็อกที่ถูกต้องสําเร็จ วิธีนี้ค่อนข้างธรรมดาดังนั้นเราจะไม่ลงรายละเอียดเพิ่มเติมที่นี่

สัญญาอัจฉริยะที่ใช้โมเดล Actor ภายในสภาพแวดล้อมการดําเนินการแบบขนานอย่างสมบูรณ์

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

โปรโตคอลบล็อกเชนกระแสหลักส่วนใหญ่ใช้สภาพแวดล้อมการดําเนินการแบบอนุกรมแบบเธรดเดียว ตัวอย่างเช่น EVM สภาพแวดล้อมการดําเนินการของ Ethereum ทํางานเป็นเครื่องของรัฐที่ประมวลผลธุรกรรมตามลําดับ หลังจากสร้างบล็อกและสั่งซื้อธุรกรรมพวกเขาจะดําเนินการทีละรายการผ่าน EVM กระบวนการแบบอนุกรมและเธรดเดียวทั้งหมดนี้หมายความว่ามีการประมวลผลธุรกรรมเดียวในเวลาใดก็ตาม ข้อดีคือเมื่อสร้างคําสั่งธุรกรรมแล้วผลลัพธ์การดําเนินการจะยังคงสอดคล้องกันในเครือข่ายแบบกระจาย ยิ่งไปกว่านั้นเนื่องจากมีการดําเนินการธุรกรรมเพียงรายการเดียวในแต่ละครั้งจึงไม่มีธุรกรรมอื่นใดที่สามารถเปลี่ยนแปลงข้อมูลของรัฐที่เข้าถึงได้เพื่อให้มั่นใจถึงการทํางานร่วมกันระหว่างสัญญาอัจฉริยะ ตัวอย่างเช่นเมื่อใช้ Uniswap เพื่อซื้อ ETH ด้วย USDT การกระจายของกลุ่มสภาพคล่องเป็นค่าคงที่ระหว่างการดําเนินการ สิ่งนี้ช่วยให้แบบจําลองทางคณิตศาสตร์สามารถกําหนดผลลัพธ์ที่แน่นอน ในทางกลับกันหากผู้ให้บริการสภาพคล่องรายอื่นเพิ่มสภาพคล่องในระหว่างการคํานวณเส้นโค้งพันธะผลลัพธ์จะล้าสมัยซึ่งเป็นที่ยอมรับไม่ได้อย่างชัดเจน

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

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

ในทางตรงกันข้าม TON ละทิ้งสถาปัตยกรรมการดําเนินการแบบอนุกรมอย่างสมบูรณ์และใช้กระบวนทัศน์การพัฒนาที่ออกแบบมาโดยเฉพาะสําหรับความคล้ายคลึงกันโดยใช้โมเดล Actor เพื่อสร้างสภาพแวดล้อมการดําเนินการใหม่ โมเดลนักแสดงซึ่งเสนอครั้งแรกโดย Carl Hewitt ในปี 1973 มีจุดมุ่งหมายเพื่อแก้ปัญหาความซับซ้อนของรัฐที่ใช้ร่วมกันในโปรแกรมพร้อมกันแบบดั้งเดิมผ่านการส่งข้อความ นักแสดงแต่ละคนมีสถานะและพฤติกรรมส่วนตัวของตนเองและไม่แบ่งปันข้อมูลของรัฐกับนักแสดงคนอื่น ๆ โมเดล Actor เป็นรูปแบบการคํานวณพร้อมกันที่บรรลุการประมวลผลแบบขนานผ่านการส่งข้อความ ในรุ่นนี้ "นักแสดง" เป็นหน่วยพื้นฐานที่สามารถจัดการข้อความที่ได้รับสร้างนักแสดงใหม่ส่งข้อความเพิ่มเติมและตัดสินใจว่าจะตอบกลับข้อความที่ตามมาอย่างไร โมเดลนักแสดงต้องมีลักษณะดังต่อไปนี้:

การห่อหุ้มและความเป็นอิสระ: นักแสดงแต่ละคนทํางานอย่างอิสระอย่างสมบูรณ์เมื่อประมวลผลข้อความทําให้สามารถประมวลผลข้อความแบบขนานได้โดยไม่มีการรบกวน

การส่งผ่านข้อความ: นักแสดงโต้ตอบผ่านการส่งและรับข้อความเพียงอย่างเดียวโดยที่การส่งข้อความเป็นแบบอะซิงโครนัส

โครงสร้างแบบไดนามิก: นักแสดงสามารถสร้างนักแสดงเพิ่มเติมได้ในขณะที่รันไทม์ทําให้โมเดลนักแสดงสามารถขยายระบบแบบไดนามิกได้ตามต้องการ

TON ใช้สถาปัตยกรรมนี้สําหรับรูปแบบสัญญาอัจฉริยะซึ่งหมายความว่าสัญญาอัจฉริยะแต่ละสัญญาในปี TON นั้นขึ้นอยู่กับรูปแบบนักแสดงและมีพื้นที่เก็บข้อมูลอิสระอย่างสมบูรณ์เนื่องจากไม่ได้ขึ้นอยู่กับข้อมูลภายนอกใด ๆ ยิ่งไปกว่านั้นการโทรไปยังสัญญาอัจฉริยะเดียวกันจะดําเนินการตามลําดับของข้อความในคิวรับ สิ่งนี้ทําให้ธุรกรรมใน TON สามารถดําเนินการควบคู่กันได้อย่างมีประสิทธิภาพโดยไม่ต้องกังวลกับความขัดแย้ง อย่างไรก็ตามการออกแบบนี้ยังแนะนําความท้าทายใหม่ ๆ สําหรับนักพัฒนา DApp กระบวนทัศน์การพัฒนาที่คุ้นเคยของพวกเขาจะหยุดชะงักด้วยวิธีต่อไปนี้:

1. การโทรสัญญาอัจฉริยะแบบอะซิงโครนัส: ในปี TON เป็นไปไม่ได้ที่จะเรียกสัญญาภายนอกหรือเข้าถึงข้อมูลสัญญาภายนอกภายในสัญญาอัจฉริยะ ตัวอย่างเช่นใน Solidity ฟังก์ชันของสัญญา A นั้นตรงไปตรงมา 1 เพื่อเรียกฟังก์ชันของสัญญา B2 หรือเข้าถึงข้อมูลสถานะบางอย่างผ่านฟังก์ชันอ่านอย่างเดียวของสัญญา C3 ทั้งหมดในธุรกรรมเดียว อย่างไรก็ตามในปี TON สิ่งนี้ไม่สามารถทําได้ การโต้ตอบใด ๆ กับสัญญาอัจฉริยะภายนอกจะดําเนินการแบบอะซิงโครนัสโดยการสร้างธุรกรรมใหม่ซึ่งเรียกว่าข้อความภายในที่เริ่มต้นโดยสัญญาอัจฉริยะ ไม่สามารถบล็อกกระบวนการดําเนินการเพื่อรอผลลัพธ์ได้

ตัวอย่างเช่นหากเรากําลังพัฒนา DEX และปฏิบัติตามกระบวนทัศน์ EVM ทั่วไปเรามักจะมีสัญญาเราเตอร์แบบรวมเพื่อจัดการการกําหนดเส้นทางธุรกรรมในขณะที่แต่ละพูลจะจัดการข้อมูล LP สําหรับคู่การซื้อขายเฉพาะอย่างอิสระ สมมติว่าเรามีสองกลุ่ม: USDT-DAI และ DAI-ETH เมื่อผู้ใช้ต้องการซื้อ ETH โดยตรงกับ USDT พวกเขาสามารถใช้สัญญาเราเตอร์เพื่อโต้ตอบกับพูลทั้งสองนี้ตามลําดับในธุรกรรมอะตอมเดียว อย่างไรก็ตามในปี TON กระบวนการนี้ไม่ตรงไปตรงมาและต้องใช้แนวทางการพัฒนาที่แตกต่างกัน หากเราพยายามใช้กระบวนทัศน์ EVM นี้อีกครั้งการไหลของข้อมูลจะเกี่ยวข้องกับข้อความภายนอกที่เริ่มต้นโดยผู้ใช้และข้อความภายในสามข้อความเพื่อทําธุรกรรมให้เสร็จสมบูรณ์ (โปรดทราบว่าตัวอย่างนี้เพื่อเน้นความแตกต่างในการพัฒนาจริงแม้แต่กระบวนทัศน์ ERC20 ก็จะต้องได้รับการออกแบบใหม่)

1. การพิจารณาอย่างรอบคอบเป็นสิ่งจําเป็นสําหรับการจัดการข้อผิดพลาดในการโทรข้ามสัญญาการออกแบบฟังก์ชั่นการตีกลับที่เหมาะสมสําหรับการโต้ตอบระหว่างสัญญาแต่ละครั้ง ในระบบ EVM หลักหากมีข้อผิดพลาดเกิดขึ้นระหว่างการดําเนินการธุรกรรมธุรกรรมทั้งหมดจะถูกย้อนกลับไปยังสถานะเริ่มต้น สิ่งนี้ตรงไปตรงมาในรุ่นเธรดเดี่ยวแบบอนุกรม อย่างไรก็ตามในปี TON เนื่องจากการโทรระหว่างสัญญาจะดําเนินการแบบอะซิงโครนัสหากมีข้อผิดพลาดเกิดขึ้นในภายหลังธุรกรรมที่ดําเนินการก่อนหน้านี้ได้รับการยืนยันแล้วซึ่งอาจทําให้เกิดปัญหาได้ ดังนั้น TON จึงได้แนะนําประเภทข้อความพิเศษที่เรียกว่าข้อความตีกลับ หากเกิดข้อผิดพลาดในการดําเนินการข้อความภายในในภายหลังสัญญาที่ทริกเกอร์สามารถใช้ฟังก์ชันตีกลับที่สงวนไว้ในสัญญาทริกเกอร์เพื่อรีเซ็ตบางสถานะในสัญญาทริกเกอร์

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

ในรุ่นนี้ A และ B เป็นตัวแทนของสัญญาอัจฉริยะสองสัญญา ถ้า msg1_lt < msg2_lt แล้ว tx1_lt < tx2_lt ในแง่ของลําดับ

อย่างไรก็ตามในสถานการณ์ที่ซับซ้อนมากขึ้นกฎนี้สามารถถูกทําลายได้ เอกสารอย่างเป็นทางการให้ตัวอย่าง: สมมติว่าเรามีสัญญาสามฉบับคือ A, B และ C ในธุรกรรมหนึ่ง A จะส่งข้อความภายในสองข้อความคือ msg1 และ msg2 ข้อความหนึ่งไปยัง B และอีกข้อความหนึ่งไปยัง C แม้ว่าจะถูกสร้างขึ้นตามลําดับเฉพาะ (msg1 ก่อนจากนั้น msg2) เราไม่สามารถมั่นใจได้ว่า msg1 จะถูกประมวลผลก่อน msg2 ความไม่แน่นอนนี้เกิดขึ้นเนื่องจากเส้นทางจาก A ถึง B และจาก A ถึง C อาจแตกต่างกันในความยาวและชุดผู้ตรวจสอบความถูกต้อง หากสัญญาเหล่านี้อยู่ในห่วงโซ่ส่วนแบ่งข้อมูลที่แตกต่างกันข้อความหนึ่งอาจใช้เวลาหลายช่วงตึกเพื่อบรรลุสัญญาเป้าหมาย ดังนั้นจึงมีเส้นทางการทําธุรกรรมที่เป็นไปได้สองเส้นทางดังที่แสดงไว้

1. ในปี TON ที่เก็บข้อมูลถาวรสําหรับสัญญาอัจฉริยะใช้โครงสร้างกราฟ acyclic (DAG) โดยตรงโดยมีเซลล์เป็นหน่วย ข้อมูลจะถูกบีบอัดลงในเซลล์อย่างกะทัดรัดตามกฎการเข้ารหัสเฉพาะและขยายลงในลักษณะที่ DAG สิ่งนี้ตรงกันข้ามกับโครงสร้างที่ใช้แฮชแมปที่ใช้ใน EVM สําหรับข้อมูลสถานะ เนื่องจากอัลกอริธึมการเข้าถึงข้อมูลที่แตกต่างกัน TON จึงกําหนดราคาก๊าซที่แตกต่างกันสําหรับการประมวลผลข้อมูลที่ระดับความลึกต่างกัน การประมวลผลข้อมูลเซลล์ที่ลึกขึ้นต้องใช้ก๊าซมากขึ้น ดังนั้น TON ต้องเผชิญกับการโจมตีแบบ DOS ประเภทหนึ่งซึ่งผู้ใช้ที่เป็นอันตรายจะท่วมสัญญาอัจฉริยะด้วยข้อความขยะจํานวนมากเติมเซลล์ตื้นทั้งหมด สิ่งนี้จะเพิ่มต้นทุนการจัดเก็บสําหรับผู้ใช้ที่ซื่อสัตย์ ในทางตรงกันข้าม แฮชแมปของ EVM มีความซับซ้อนในการสืบค้นของ O(1) ทําให้มั่นใจได้ถึงต้นทุนก๊าซที่สม่ําเสมอและหลีกเลี่ยงปัญหาที่คล้ายคลึงกัน ดังนั้นนักพัฒนา TON Dapp ควรหลีกเลี่ยงการใช้ประเภทข้อมูลที่ไม่มีขอบเขตในสัญญาอัจฉริยะ เมื่อจําเป็นต้องใช้ชนิดข้อมูลที่ไม่มีขอบเขต ควรแบ่งพาร์ติชันโดยใช้การแบ่งส่วน

1. คุณสมบัติบางอย่างมีความพิเศษน้อยกว่าเช่นข้อกําหนดสําหรับสัญญาอัจฉริยะในการจ่ายค่าเช่าสําหรับการจัดเก็บ ในปี TON สัญญาอัจฉริยะสามารถอัปเกรดได้โดยเนื้อแท้และมาพร้อมกับฟังก์ชันบัญชีนามธรรมดั้งเดิมซึ่งหมายความว่าที่อยู่กระเป๋าเงินทั้งหมดใน TON เป็นสัญญาอัจฉริยะที่ยังไม่ได้เริ่มต้น นักพัฒนาต้องใส่ใจกับประเด็นเหล่านี้อย่างใกล้ชิด

ข้อจํากัดความรับผิดชอบ:

1. บทความนี้พิมพ์ซ้ําจาก [Theblockbeats] ลิขสิทธิ์ทั้งหมดเป็นของผู้เขียนต้นฉบับ [Web3Mario] หากมีการคัดค้านการพิมพ์ซ้ํานี้ โปรดติดต่อทีม Gate Learn และพวกเขาจะจัดการทันที
2. ข้อจํากัดความรับผิดชอบความรับผิด: มุมมองและความคิดเห็นที่แสดงในบทความนี้เป็นเพียงของผู้เขียนและไม่ถือเป็นคําแนะนําการลงทุนใด ๆ
3. การแปลบทความเป็นภาษาอื่นทําโดยทีม Gate Learn ห้ามคัดลอก แจกจ่าย หรือลอกเลียนแบบบทความที่แปล