คำอธิบายโดยละเอียดเกี่ยวกับคุณลักษณะทางเทคนิคของ TON และรูปแบบการพัฒนาสัญญาอัจฉริยะ

ผู้เขียนต้นฉบับ: @Web3 มาริโอ

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

แนวคิดการออกแบบหลักของ TON คือ การทำงานพร้อมกันจำนวนมากและความสามารถในการปรับขนาดสูง

อาจกล่าวได้ว่าจุดประสงค์ของการเลือกใช้เทคโนโลยีที่ซับซ้อนทั้งหมดใน TON นั้นมาจากการแสวงหาการทำงานพร้อมกันในระดับสูงและการปรับขนาดได้สูง แน่นอนว่ามันไม่ใช่เรื่องยากสำหรับเราที่จะเข้าใจสิ่งนี้จากภูมิหลังของการกำเนิด TON หรือ Open Network เป็นเครือข่ายคอมพิวเตอร์แบบกระจายอำนาจที่ประกอบด้วยบล็อคเชน L1 และส่วนประกอบหลายส่วน TON ได้รับการพัฒนาโดยผู้ก่อตั้ง Telegrams Nikolai Durov และทีมงานของเขา และตอนนี้ได้รับการสนับสนุนและดูแลโดยชุมชนผู้สนับสนุนอิสระทั่วโลก การถือกำเนิดของ TON นั้นย้อนกลับไปในปี 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 มีอยู่ 4 ชั้น:

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

• ชาร์ดเชน: ในบริบทส่วนใหญ่ ชาร์ดเชนคือหน่วยส่วนประกอบที่แท้จริงของ TON ชาร์ดเชนคือกลุ่มของบัญชีเชน

• WorkChain: เรียกอีกอย่างหนึ่งว่าชุดของ shard chain ที่มีกฎเกณฑ์ที่กำหนดเอง เช่น การสร้าง workchain ที่ใช้ EVM และเรียกใช้ smart contracts ของ Solidity บนนั้น ในทางทฤษฎี ทุกคนในชุมชนสามารถสร้าง workchain ของตัวเองได้ ในความเป็นจริง การสร้างมันเป็นงานที่ค่อนข้างซับซ้อน และก่อนหน้านั้น คุณต้องจ่ายค่าธรรมเนียม (ราคาแพง) เพื่อสร้างมันขึ้นมา และได้รับคะแนนเสียง 2/3 จากผู้ตรวจสอบเพื่ออนุมัติการสร้าง workchain ของคุณ

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

จากการนำแนวคิดนี้มาใช้ เครือข่าย TON จะมีลักษณะเด่น 3 ประการดังต่อไปนี้:

• การแบ่งส่วนแบบไดนามิก: 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 โหนดจะสามารถยืนยันความน่าเชื่อถือของข้อความที่ส่งโดยผู้ใช้ได้โดยตรง ซึ่งเรียกอีกอย่างว่าการกำหนดเส้นทาง Hypercube แบบทันที

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

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

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

สัญญาอัจฉริยะตามผู้แสดงและสภาพแวดล้อมการดำเนินการแบบคู่ขนานอย่างสมบูรณ์

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

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

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

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

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

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

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

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

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

อย่างไรก็ตาม การออกแบบนี้ยังส่งผลกระทบใหม่ๆ อีกด้วย สำหรับนักพัฒนา DApp รูปแบบการพัฒนาที่คุ้นเคยจะถูกทำลายลง ดังนี้:

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

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

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

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

ในโมเดลนี้ A และ B แสดงถึงสัญญาอัจฉริยะสองฉบับตามลำดับ และมีความสัมพันธ์ด้านเวลาที่หาก msg 1 _lt

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

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

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

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

ลิงก์ X: https://x.com/web3_mario

ที่จับ Telegram: @MarioChin Web3

บทความนี้มีที่มาจากอินเทอร์เน็ต: คำอธิบายโดยละเอียดเกี่ยวกับคุณลักษณะทางเทคนิคของ TON และรูปแบบการพัฒนาสัญญาอัจฉริยะ

ที่เกี่ยวข้อง: การตีความมีมที่อิงตามและสถาบันที่อิงตาม: อนาคตของระบบนิเวศฐานอยู่ที่ไหน

ที่มา: Jesse Pollak เรียบเรียงโดย: Odaily Planet Daily Wenser หมายเหตุบรรณาธิการ: ในฐานะหนึ่งในระบบนิเวศ L2 ที่ร้อนแรงที่สุดในปี 2024 การเติบโตของ Base อาจกล่าวได้ว่าเป็นผลมาจากเวลาที่เหมาะสม สถานที่ที่เหมาะสม และผู้คนที่เหมาะสม ไม่เพียงแต่มีโอกาสอันยอดเยี่ยมจากกระแสความนิยมของ Memecoin เท่านั้น แต่ยังรวมถึงเครือข่าย L2 low-gas ที่ใช้ระบบนิเวศ OP และได้รับการสนับสนุนจาก Coinbase และการทำงานหนักของผู้นำโปรโตคอล Jesse Pollak และกลุ่มผู้สร้างระบบนิเวศ สำหรับระบบนิเวศ Base ซึ่ง TVL สูงถึง 5.5 พันล้านดอลลาร์สหรัฐ Jesse เพิ่งให้บทวิจารณ์และสรุปสั้นๆ ที่ New York Meme Hackathon และเพิ่งโพสต์เนื้อหาเกี่ยวกับ Zora ในรูปแบบ NFT และได้สร้างมากกว่า 4,000...