ในสาขาเทคโนโลยีบล็อกเชนที่กำลังเจริญอย่างรวดเร็ว TON (The Open Network) ได้รับความสนใจเพิ่มมากขึ้นจากนักพัฒนาเนื่องจากเป็นแพลตฟอร์มบล็อกเชนที่มีประสิทธิภาพและยืดหยุ่น TON's สถาปัตยกรรมและคุณสมบัติที่เป็นเอกลักษณ์มอบเครื่องมือที่มีพลังและโอกาสที่มั่นใจสำหรับการพัฒนาแอปพลิเคชันโดยที่ไม่มีความเชื่อมั่น

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

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

การวิเคราะห์คุณสมบัติแบบไม่สม่ำเสมอของ TON และกลไกบัญชี

การเรียกข้อมูลแบบไม่โดยเกี่ยวข้องในสัญญาอัจฉริยะ

การแบ่งส่วนเครือข่ายและการสื่อสารแบบไม่สม่ำเสมอ

บล็อกเชน TON ถูกออกแบบมาพร้อมกับสามประเภทของเชน: Masterchain, Workingchains, และ Shardchains

Masterchain เป็นแกนหลักของเครือข่ายทั้งหมดซึ่งรับผิดชอบในการจัดเก็บข้อมูลเมตาและกลไกฉันทามติของเครือข่ายทั้งหมด มันบันทึกสถานะของ Workingchains และ Shardchains ทั้งหมดและรับประกันความสอดคล้องของเครือข่ายและความปลอดภัย Workingchains เป็นบล็อกเชนอิสระที่มีโซ่สูงสุด 2 ^ 32 ซึ่งรับผิดชอบในการจัดการธุรกรรมบางประเภทและสัญญาอัจฉริยะ แต่ละ Workingchain สามารถมีกฎและคุณสมบัติของตัวเองเพื่อตอบสนองความต้องการใช้งานที่แตกต่างกัน Shardchains เป็นโซ่ย่อยของ Workingchains ซึ่งใช้ในการแบ่งปริมาณงานของ Workingchains เพิ่มเติมเพิ่มความสามารถในการประมวลผลและความสามารถในการปรับขนาด แต่ละ Workingchain สามารถแบ่งออกเป็น Shardchains ได้สูงสุด 2 ^ 60 โดย Shardchains จัดการธุรกรรมบางอย่างอย่างอิสระเพื่อให้ได้การประมวลผลแบบขนานที่มีประสิทธิภาพ

ตามทฤษฎี แต่ละบัญชีสามารถครอบครอง Shardchain ได้แบบที่ไม่ซ้ำกัน โดยแต่ละบัญชีจะรักษาระดับคงเหลือ COIN/TOKEN ของตนอย่างอิสระ การทำธุรกรรมระหว่างบัญชีสามารถทำได้แบบพาราเลล บัญชีสื่อสารผ่านข้อความแบบไม่สม่ำเสมอ และเส้นทางสำหรับข้อความที่จะเดินทางไประหว่าง Shardchains คือ log_16(N) - 1 โดยที่ N คือจำนวนของ Shardchains

แหล่งที่มาของรูปภาพ: https://frontierlabzh.medium.com/ton-weixin-e1d3ae3b3574 ของ web3 worldIn Ton การโต้ตอบจะดําเนินการผ่านการส่งและรับข้อความ ข้อความเหล่านี้อาจเป็นข้อความภายใน (โดยทั่วไปจะส่งโดยสัญญาอัจฉริยะที่มีปฏิสัมพันธ์ซึ่งกันและกัน) หรือภายนอก (ส่งโดยแหล่งภายนอก) กระบวนการส่งข้อความไม่ต้องการการตอบกลับทันทีจากสัญญาเป้าหมายทําให้ผู้ส่งสามารถดําเนินการตรรกะที่เหลือต่อไปได้ กลไกการส่งข้อความแบบอะซิงโครนัสนี้ให้ความยืดหยุ่นและความสามารถในการปรับขนาดที่มากขึ้นเมื่อเทียบกับการโทรแบบซิงโครนัสของ Ethereum ซึ่งช่วยลดปัญหาคอขวดด้านประสิทธิภาพที่เกิดจากการรอการตอบกลับในขณะเดียวกันก็แนะนําความท้าทายในการจัดการกระบวนการทํางานพร้อมกันและเงื่อนไขการแข่งขัน

รูปแบบและโครงสร้างข้อความ

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

คิวข้อความและการประมวลผลสถานะ

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

ข้อดีของการส่งข้อความแบบไม่ตรงเวลา

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

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

•ความอภิปรายและความเชื่อถือได้: กลไกการส่งข้อความแบบไม่เชื่อมต่อเพิ่มความอภิปรายให้กับระบบ ตัวอย่างเช่น หากสัญญาไม่สามารถตอบกลับข้อความในเวลาทันทีเนื่องจากข้อจำกัดทรัพยากรหรือเหตุผลอื่น ๆ ผู้ส่งสามารถดำเนินการประมวลผลตรรกะอื่น ๆ เพื่อป้องกันระบบไม่ติดเนื่องจากความล่าช้าในสัญญาเดียว

ความท้าทายของการออกแบบสัญญาแบบไม่เชื่อมต่อ

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

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

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

โมเดลกระดาษบัญชี

TON (The Open Network) ใช้รูปแบบนามธรรมบัญชีและบัญชีแยกประเภทที่ไม่เหมือนใครในการออกแบบโครงสร้างพื้นฐานบล็อกเชน ความยืดหยุ่นของโมเดลนี้สะท้อนให้เห็นในวิธีจัดการสถานะบัญชีการส่งผ่านข้อความและการดําเนินการตามสัญญา

การนำเข้าบัญชี

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

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

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

โครงสร้าง Ledger

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

การเก็บข้อมูลสถานะ

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

สถานะบัญชีหรือสัญญาอัจฉริยะทั่วไปรวมถึงสิ่งต่อไปนี้:

1. ดุลของสกุลเงินหลัก 2. ยอดคงเหลือของสกุลเงินอื่น ๆ 3. รหัสสัญญาอัจฉริยะ (หรือแฮช) 4. ข้อมูลถาวรของสัญญาอัจฉริยะ (หรือแฮช Merkle) 5. สถิติเกี่ยวกับจํานวนหน่วยเก็บข้อมูลถาวรและการใช้ไบต์ดิบ 6. การประทับเวลาล่าสุดของการชําระเงินไปยังที่เก็บข้อมูลถาวรของสัญญาอัจฉริยะ (โดยพื้นฐานแล้วคือหมายเลขบล็อกโซ่หลัก) 7. คีย์สาธารณะที่จําเป็นสําหรับการโอนสกุลเงินและส่งข้อความจากบัญชีนี้ (ไม่บังคับ โดยค่าเริ่มต้น จะเท่ากับ account_id เอง) ในบางกรณีอาจพบรหัสตรวจสอบลายเซ็นที่ซับซ้อนมากขึ้นที่นี่คล้ายกับผลลัพธ์การทําธุรกรรม Bitcoin ในกรณีเช่นนี้ account_id จะเป็นแฮชของรหัสนี้

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

การส่งข้อความและการประมวลผล

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

โมเดลแก๊ส

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

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

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

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

สัญญาอัจฉริยะ Ton ง่ายต่อการละเว้นช่องโหว่

ในบทความวิเคราะห์ความปลอดภัยก่อนหน้าของเราใน TON เราได้สรุปรายละเอียดเกี่ยวกับช่องโหว่ความปลอดภัยที่พบบ่อยในระบบ TON สำหรับข้อมูลเพิ่มเติมโปรดดูตารางด้านล่าง:

บทความนี้จะเน้นไปที่ช่องโหว่ในสัญญา TON ที่มักถูกละเลยบ่อยครั้ง ตามสรุปโดยทีมของเรา:

(1) การปรับปรุงความอ่านได้ของโค้ด

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

1. check_std_addr(address);was msg = begin_cell() store_uint(0x18, 6) ;; nobounce store_slice(address) store_coins(amount) store_uint(0, 1 + 4 + 4 + 64 + 32 + 1 + 1) end_cell();send_raw_message(msg, 1);

นอกจากนี้สําหรับข้อความแสดงข้อผิดพลาดในเงื่อนไขการตัดสินสัญญาขอแนะนําให้กําหนดตัวแปรที่เกี่ยวข้องเพื่อแทนที่รหัสข้อผิดพลาด

(2) การใช้งาน end_parse()เพื่อให้มั่นใจในความสมบูรณ์ของข้อมูล

ในสัญญา TON การแยกวิเคราะห์ข้อมูลจะทำตามลำดับที่แน่นอนโหลดประเภทข้อมูลที่ระบุขั้นตอนละขั้นจากข้อมูลดิบ วิธีการแยกวิเคราะห์นี้จะให้ความสอดคล้องและความแม่นยำของข้อมูลตามที่แสดงไว้ด้านล่าง:

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

(3) ข้อยกเว้นที่เกิดจากการไม่ตรงกันของการจัดเก็บข้อมูลและประเภทข้อมูล

นี้เกี่ยวข้องกับการจับคู่ของINTและuintประเภทการเก็บข้อมูล ตัวอย่างเช่นในโค้ดต่อไปนี้store_int() ฟังก์ชันใช้เพื่อจัดเก็บ intค่าของ-42, แต่ load_uint() ใช้เพื่อโหลดค่านี้ ซึ่งอาจส่งผลให้เกิดข้อยกเว้น

(4) การใช้งานที่เหมาะสมของinline_ref และ แบบ อิน ไลน์Modifiers

ก่อนอื่น สิ่งที่สำคัญคือการแยกแยะระหว่างinlineและinline_ref ตัวดัดแปลง:

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

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

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

(5) กำหนด Workchain ที่ถูกต้อง

TON ช่วยให้สามารถสร้างเวิร์กเชนได้มากถึง 2 ^ 32 ซึ่งแต่ละชิ้นสามารถแบ่งออกเป็น 2 ^ 60 ส่วนแบ่งข้อมูล เริ่มแรกมีสอง workchains: masterchain (-1) และ basechain (0) เมื่อคํานวณที่อยู่เป้าหมายในสัญญาสิ่งสําคัญคือต้องระบุรหัสเวิร์กเชนที่ถูกต้องเพื่อให้แน่ใจว่าที่อยู่กระเป๋าเงินที่สร้างขึ้นนั้นอยู่ในเวิร์กเชนที่ถูกต้อง เพื่อหลีกเลี่ยงการสร้างที่อยู่ที่ไม่ถูกต้องขอแนะนําให้ใช้ force_chain()เพื่อระบุ Chain ID โดยชัดแจ้ง

(6) หลีกเลี่ยงความขัดแย้งรหัสข้อผิดพลาด

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

(7) การเก็บข้อมูลและการเรียกใช้return()หลังการดำเนินการเสร็จสิ้น

ในสัญญาอัจฉริยะ TON การจัดการข้อความเกี่ยวข้องกับการเลือกตรรกะที่แตกต่างกันตาม op-code หลังจากเสร็จสิ้นตรรกะที่เกี่ยวข้องแล้วจําเป็นต้องมีขั้นตอนเพิ่มเติมสองขั้นตอน: ขั้นแรกหากมีการแก้ไขข้อมูลให้โทร save_data()เพื่อให้มั่นใจว่าการเปลี่ยนแปลงถูกจัดเก็บไว้ มิเช่นนั้นการเปลี่ยนแปลงจะไม่มีผล ในขั้นตอนถัดไป โทรอีกครั้งกลับ()เพื่อแสดงว่าการดำเนินการเสร็จสิ้น; มิฉะนั้น โยน (0xffff)จะเกิดข้อยกเว้น

() recv_internal(int my_balance, int msg_value, cell in_msg_full, slice in_msg_body) ไม่บริสุทธิ์ {

int flags = cs~load_uint(4);

IF (ธง & 1) {

;; ละเว้นข้อความที่ตีกลับทั้งหมด

return ();

}

slice sender_address = cs~load_msg_addr();

load_data();

int op = in_msg_body~load_op();

ถ้า ((op == op::op_1())) {

handle_op1();

บันทึกข้อมูล();

return ();

}

if ((op == op::op_2())) {

handle_op2();

บันทึกข้อมูล();

return ();

}

if ((op == op::op_3())) {

handle_op3();

save_data();

กลับ ();

}

โยน (0xffff);

}

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

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

Beosin มีกรณีทดสอบที่ประสบความสำเร็จมากมายภายในระบบ TON มากมาย ก่อนหน้านี้ Beosin ได้ดำเนินการทดสอบความปลอดภัยอย่างละเอียดสำหรับโครงการเหรียญเสถียรแบบกระจายชั้นนำ Aqua Protocol และโครงสร้างพื้นฐาน ONTON Finance การทดสอบครอบคลุมด้านหลายด้าน รวมถึงความปลอดภัยของโค้ดสัญญาอัจฉริยะ ความถูกต้องของการปฏิบัติตามตรรกะธุรกิจ การปรับปรุงแก๊สของโค้ดสัญญา และการตรวจพบและแก้ไขช่องโหว่ที่เป็นไปได้

คำอธิบาย:

1. บทความนี้ถูกคัดลอกมาจาก [บีโอซิน] ชื่อเดิม "Beosin Hard Core Research | Beosin Hard Core Research จากความเสี่ยงสู่การป้องกัน: ความเสี่ยงด้านความปลอดภัยและข้อเสนอแนะการเพิ่มประสิทธิภาพของ TON Smart Contracts》 ลิขสิทธิ์เป็นของผู้เขียนต้นฉบับ [Beosin], หากคุณมีคำประทับใจใด ๆ เกี่ยวกับการเผยแพร่ซ้ำ โปรดติดต่อทีม Gate Learnทีมจะดำเนินการให้เร็วที่สุดตามขั้นตอนที่เกี่ยวข้อง

2. คำประกาศ: มุมมองและความคิดเห็นที่แสดงในบทความนี้แสดงเพียงมุมมองส่วนบุคคลของผู้เขียนเท่านั้น และไม่เป็นการให้คำแนะนำในการลงทุนใด ๆ

3. เวอร์ชันภาษาอื่น ๆ ของบทความถูกแปลโดยทีม Gate Learn และไม่ได้กล่าวถึงในGate.ioบทความที่แปลแล้วต้องไม่ทําซ้ําแจกจ่ายหรือลอกเลียนแบบ