ผู้เขียนต้นฉบับ: โยฮัน
พื้นหลัง
TON (The Open Network) เป็นแพลตฟอร์มบล็อกเชนแบบกระจายอำนาจที่ออกแบบและพัฒนาโดยทีมงาน Telegram เป้าหมายของ TON คือการจัดหาแพลตฟอร์มบล็อกเชนประสิทธิภาพสูงและปรับขนาดได้ เพื่อรองรับแอปพลิเคชันกระจายอำนาจขนาดใหญ่ (DApps) และสัญญาอัจฉริยะ
TON มีความพิเศษมาก ใช้งานง่าย มีการบูรณาการอย่างลึกซึ้งกับ Telegram ทำให้คนทั่วไปใช้โทเค็นได้ง่าย อีกทั้งยังซับซ้อน มีสถาปัตยกรรมที่แตกต่างอย่างสิ้นเชิงจากบล็อกเชนอื่น ๆ และใช้ FunC ที่ไม่ใช่กระแสหลัก ภาษาสัญญาอัจฉริยะ วันนี้เราจะหารือเกี่ยวกับลักษณะของ TON และปัญหาด้านความปลอดภัยของสินทรัพย์ผู้ใช้จากมุมมองของบัญชี โทเค็น และธุรกรรม
คุณสมบัติของตัน
การสร้างบัญชี
ที่อยู่บัญชี TON ถูกสร้างขึ้นแตกต่างจากบล็อกเชนส่วนใหญ่ มันเป็นที่อยู่สัญญาอัจฉริยะ ขั้นแรก สร้างคีย์ส่วนตัว TON ใช้อัลกอริธึม Ed 25519 เป็นหลักเพื่อสร้างคีย์สาธารณะ
กุญแจสาธารณะมีสองรูปแบบ หนึ่งคือกุญแจสาธารณะดั้งเดิมที่คำนวณจากกุญแจส่วนตัว ซึ่งมีลักษณะดังนี้:
E39ECDA0A7B0C60A7107EC43967829DBE8BC356A49B9DFC6186B3EAC74B5477D
อีกอันคือกุญแจสาธารณะที่ สวยงาม ซึ่งบรรจุข้อมูลบางส่วนและตรวจสอบตัวเลขของกุญแจสาธารณะในรูปแบบ: Pubjns2gp7DGCnEH7EOWeCnb6Lw1akm538YYaz6sdLVHfRB2
มันจะไร้เดียงสาเกินไปที่จะคิดว่าคุณสามารถรับที่อยู่บัญชีได้เช่นเดียวกับ Ethereum โดยการได้รับรหัสสาธารณะ การมีรหัสสาธารณะของผู้ใช้นั้นไม่เพียงพอที่จะคำนวณที่อยู่บัญชีของผู้ใช้ เราเพิ่งบอกว่าที่อยู่บัญชีผู้ใช้เป็นที่อยู่สัญญาอัจฉริยะ แต่เราไม่มีบัญชีด้วยซ้ำ เราจะปรับใช้สัญญาอัจฉริยะได้อย่างไร ลำดับที่ถูกต้องคือการคำนวณที่อยู่ก่อน รับโทเค็นจำนวนเริ่มต้น จากนั้นจึงปรับใช้สัญญาได้ ขั้นตอนการคำนวณที่อยู่บัญชีแสดงในรูปด้านล่าง:
ที่อยู่ของผู้ใช้ยังมาในหลายรูปแบบ รูปแบบแรกคือรูปแบบดั้งเดิม ซึ่งมีลักษณะดังนี้:
0:b4c1b2ede12aa76f4a44353944258bcc8f99e9c7c474711a152c78b43218e296
และรูปแบบที่ใช้งานง่าย เช่น
เมนเน็ต:
เด้งได้:
EQC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0MhjilkPX
ไม่สามารถตีกลับได้:
UQC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0Mhjilh4S
เครือข่ายทดสอบ:
เด้งได้:
kQC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0Mhjilvhd
ไม่สามารถตีกลับได้:
0QC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0MhjilqWY
หากคุณสังเกตที่อยู่เหล่านี้อย่างรอบคอบ คุณจะเห็นว่ามีความแตกต่างกันเฉพาะอักขระตัวแรกและตัวสุดท้าย และ `account_id` ที่อยู่ตรงกลางก็เหมือนกัน อย่างไรก็ตาม เรายังไม่เห็นความสัมพันธ์ระหว่างคีย์สาธารณะและที่อยู่ของบัญชี ในความเป็นจริง ความลึกลับอยู่ที่ `ข้อมูลเริ่มต้น ที่จุดเริ่มต้นประกอบด้วยรหัสสาธารณะของผู้ใช้ ซึ่งผู้ใช้จะควบคุมความเป็นเจ้าของสัญญากระเป๋าเงิน `workchainId` นั้นง่ายต่อการเข้าใจ TON ไม่ใช่แค่ chain เดียวเท่านั้น มันประกอบด้วย Shard จำนวนมาก แต่ละ Shard เป็นส่วนหนึ่งของเครือข่ายทั้งหมดและจัดการชุดบัญชีและธุรกรรมเฉพาะ เพื่อที่จะค้นหาและจัดการสัญญาอัจฉริยะ จำเป็นต้องระบุให้ชัดเจนว่าส่วนใดอยู่ที่ส่วนใด อะไรคือความแตกต่างระหว่าง ตีกลับได้ และ ไม่สามารถตีกลับได้? สิ่งนี้เกี่ยวข้องกับกลไกการทำงานของสัญญาอัจฉริยะ มาดูกันต่อด้านล่าง
สัญญากระเป๋าเงิน
ต่อไปนี้เป็นซอร์สโค้ดของสัญญากระเป๋าเงินผู้ใช้ คุณจะเห็นว่ามันอ่านพารามิเตอร์ 4 ตัว (stored_seqno, stores_subwallet, public_key, ปลั๊กอิน) เมื่อได้รับข้อความของผู้ใช้:
wallet-v4-code.fc
() recv_external (ชิ้น in_msg) ไม่บริสุทธิ์ {
ลายเซ็น var = in_msg~load_bits(512);
var cs = in_msg;
var (subwallet_id, valid_until, msg_seqno) = (cs~load_uint( 32), cs~load_uint( 32), cs~load_uint( 32));
Throw_if( 36, valid_until <= ตอนนี้());
var ds = get_data().begin_parse();
var (stored_seqno,stored_subwallet, public_key, Plugins) = (ds~load_uint( 32), ds~load_uint( 32), ds~load_uint( 256), ds~load_dict()); ;;##ข้อมูลเริ่มต้น
ds.end_parse();
Throw_unless( 33, msg_seqno == เก็บไว้_seqno);
Throw_unless( 34, subwallet_id == เก็บไว้_subwallet);
Throw_unless( 35, check_signature(slice_hash(in_msg), ลายเซ็นต์, public_key));
-
-
ถูกต้อง เมื่อปรับใช้สัญญากระเป๋าเงินของผู้ใช้รายนี้ คุณจะต้องส่งพารามิเตอร์เริ่มต้นบางอย่าง ซึ่งรวมถึงข้อมูล public_key 256 บิต เพื่อให้แน่ใจว่าผู้ใช้แต่ละคนมีสัญญาที่เป็นอิสระเมื่อใช้รหัสสัญญาเดียวกัน ธุรกรรมทั้งหมดที่เริ่มต้นโดยผู้ใช้จะต้องลงนาม `in_msg` จากนั้นตรวจสอบลายเซ็น (check_signature) ผ่านสัญญากระเป๋าเงินของตนเอง จากนั้นสัญญาจะเรียกใช้การดำเนินการทั้งหมดในห่วงโซ่ จากที่นี่ เรายังอนุมานได้ว่าคีย์สาธารณะของผู้ใช้สามารถสอดคล้องกับที่อยู่กระเป๋าสตางค์จำนวนนับไม่ถ้วน คุณจะต้องปรับใช้กระเป๋าสตางค์ด้วยซอร์สโค้ดที่แตกต่างกันหรือข้อมูลการเริ่มต้นที่แตกต่างกัน เพื่อให้ได้ที่อยู่สัญญาที่แตกต่างกันโดยสิ้นเชิง
เจ็ตตันโทเค็น
Token เป็นตัวแทนของสินทรัพย์ในห่วงโซ่ ดังนั้นจึงเป็นองค์ประกอบพื้นฐานที่เราต้องเข้าใจ Jetton เป็นรูปแบบมาตรฐานของโทเค็น TON Jetton ประกอบด้วยสัญญาสองส่วน ได้แก่ Jetton-minter และ Jetton-wallet:
เมื่อมีการออกโทเค็น สัญญา Jetton-minter จะถูกสร้างขึ้น การเริ่มต้นสัญญาจะบันทึกจำนวนโทเค็น ผู้ดูแลระบบ รหัสกระเป๋าเงิน และข้อมูลอื่น ๆ
เมื่อมีการแจกจ่ายโทเค็นให้กับผู้ใช้ สัญญา Minter จะปรับใช้สัญญากระเป๋าเงินสำหรับผู้ใช้ และบันทึกยอดคงเหลือของผู้ใช้ ความเป็นเจ้าของ ที่อยู่สัญญาโทเค็น รหัสกระเป๋าเงินของผู้ใช้ และข้อมูลอื่น ๆ เมื่อผู้ใช้แต่ละรายจะปรับใช้สัญญา อย่างอิสระ โปรดทราบว่าสัญญาที่สร้างขึ้นที่นี่คือสัญญากระเป๋าเงินที่ใช้เพื่อจัดการโทเค็น Jetton เฉพาะ ซึ่งแตกต่างจากสัญญากระเป๋าเงินของบัญชีผู้ใช้ ที่นี่จะบันทึกที่อยู่กระเป๋าเงินของบัญชีของผู้ใช้
เมื่อผู้ใช้ Alice โอนเงินให้กับผู้ใช้ Bob ความสัมพันธ์ในการโทรจะเป็นดังนี้:
อลิซลงนามในแอปนอกเครือข่ายและออกคำแนะนำในการดำเนินการโดยเรียกสัญญากระเป๋าเงินของเธอ คำแนะนำเหล่านี้เรียกกระเป๋าโทเค็นของเธอเพิ่มเติมเพื่อทำการโอน เมื่อกระเป๋าโทเค็นของ Bob ได้รับโทเค็น มันจะแจ้งสัญญากระเป๋าเงินของ Bob (นั่นคือ ที่อยู่ของเจ้าของกระเป๋าเงิน Bob Jetton) หากมีก๊าซเหลืออยู่ในระหว่างการทำธุรกรรม มันจะถูกส่งคืนไปยังที่อยู่ตอบกลับ ซึ่งโดยปกติจะเป็นสัญญาบัญชีของอลิซ
นี่คือการถ่ายโอนโทเค็น Jetton ที่แยกวิเคราะห์โดยเบราว์เซอร์ Tonviewer:
การโอน ERC 20 จำเป็นต้องเรียกสัญญาอย่างน้อย 1 สัญญา ในขณะที่การโอนโทเค็น Jetton จำเป็นต้องเรียกสัญญาอย่างน้อย 4 สัญญา ซึ่งทำเพื่อให้การโอนสามารถดำเนินการพร้อมกันในห่วงโซ่และปรับปรุงประสิทธิภาพการทำธุรกรรม
ซื้อขาย
เมื่อมีบางอย่างเกิดขึ้นกับบัญชีใน TON เหตุการณ์ที่พบบ่อยที่สุดคือ การรับข้อความ ธุรกรรมประกอบด้วยสิ่งต่อไปนี้:
ข้อความขาเข้าที่เริ่มทริกเกอร์สัญญา (มีวิธีทริกเกอร์พิเศษ)
การดำเนินการตามสัญญาที่เกิดจากข้อความขาเข้า เช่น การอัปเดตพื้นที่เก็บข้อมูลของสัญญา (ไม่บังคับ)
ข้อความขาออกถึงผู้เข้าร่วมคนอื่นๆ (ไม่บังคับ)
มีคุณสมบัติหลายประการที่คุณต้องใส่ใจเมื่อทำการซื้อขาย:
1. แบบอะซิงโครนัส: ธุรกรรม TON ไม่สมบูรณ์ในการโทรครั้งเดียว อาจต้องส่งข้อความไปยังสัญญาอัจฉริยะหลายรายการเพื่อดำเนินการโทรเป็นชุด เนื่องจากเส้นทางที่แตกต่างกันในกลุ่มชาร์ด TON จึงไม่สามารถรับประกันลำดับการส่งข้อความระหว่างสัญญาอัจฉริยะหลายสัญญาได้
2. ค่าธรรมเนียมการจัดการ: ลักษณะแบบอะซิงโครนัสยังนำมาซึ่งปัญหา กล่าวคือ ค่าธรรมเนียมการจัดการที่ใช้นั้นยากต่อการประมาณ ดังนั้นเมื่อเริ่มการทำธุรกรรม กระเป๋าเงินมักจะส่งโทเค็นเพิ่มเติมเป็นค่าธรรมเนียมการจัดการ หากสัญญาที่เรียกมีกลไกค่าธรรมเนียมการจัดการที่ดี ค่าธรรมเนียมการจัดการที่เหลือจะถูกส่งคืนไปยังกระเป๋าสตางค์ของผู้ใช้ในที่สุด ผู้ใช้อาจสังเกตเห็นว่าโทเค็นกระเป๋าสตางค์ของพวกเขาลดลงและเพิ่มขึ้นในทันทีหลังจากนั้นไม่กี่นาที ด้วยเหตุนี้
3. การตีกลับ: การตีกลับเป็นกลไกการจัดการข้อผิดพลาดของสัญญา เมื่อสัญญาการเรียกไม่มีอยู่หรือเกิดข้อผิดพลาด หากธุรกรรมถูกตั้งค่าให้ตีกลับ ข้อความที่ตีกลับจะถูกตีกลับไปยังสัญญาการเรียก ตัวอย่างเช่น หากผู้ใช้เริ่มต้นการโอนและมีข้อผิดพลาดเกิดขึ้นในกระบวนการโทร จำเป็นต้องมีข้อความตีกลับเพื่อให้สัญญากระเป๋าเงินของผู้ใช้สามารถคืนยอดคงเหลือได้ ข้อความภายในเกือบทั้งหมดที่ส่งระหว่างสัญญาอัจฉริยะควรสามารถตีกลับได้ กล่าวคือ ควรตั้งค่าบิต ตีกลับ
ความปลอดภัยของทรัพย์สิน
TON มีคุณสมบัติมากมายที่อาจทำให้เกิดปัญหาด้านความปลอดภัย ดังนั้นผู้ใช้จึงต้องตระหนักถึงข้อผิดพลาดทั่วไปบางประการด้วย
การโจมตีสกัดกั้นค่าธรรมเนียม
ตามที่กล่าวไว้ข้างต้น กระเป๋าเงินมักจะต้องส่งค่าธรรมเนียมการจัดการเพิ่มเติมเพื่อป้องกันความล้มเหลวในการดำเนินการธุรกรรม ซึ่งช่วยให้ผู้โจมตีสามารถค้นหาโอกาสในการทำสิ่งชั่วร้ายได้ หากคุณเป็นผู้ใช้กระเป๋าเงิน TON คุณอาจพบสถานการณ์นี้ คุณได้รับ NFT หรือโทเค็นต่าง ๆ ในกระเป๋าเงินของคุณเสมอ คุณคิดว่ามันเป็นเพียงโทเค็นขยะ แต่เมื่อคุณตรวจสอบข้อมูลธุรกรรม คุณพบว่าคุณไม่สามารถทำได้ ขายพวกเขา เงินน้อยลงเหรอ? อย่างไรก็ตาม เมื่อเริ่มการทำธุรกรรม คุณพบว่าค่าธรรมเนียมการจัดการที่จำเป็นนั้นสูงมาก (1 ตัน) ในเวลานี้ คุณต้องให้ความสนใจ นี่อาจเป็นการฉ้อโกงค่าธรรมเนียมการจัดการ
ผู้โจมตีใช้สัญญาโทเค็นที่สร้างขึ้นอย่างระมัดระวังเพื่อทำให้ค่าธรรมเนียมการโอนโดยประมาณของกระเป๋าเงินสูงมาก แต่ในระหว่างการดำเนินการจริง ผู้โจมตีจะระงับค่าธรรมเนียมเท่านั้นและไม่ได้ส่งข้อความการโอน
ตกปลาเลขตัวแรกและตัวสุดท้าย
การโจมตีแบบฟิชชิ่งแบบ Head และ Tail ไม่ได้เกิดขึ้นเฉพาะกับ TON เท่านั้น ผู้โจมตีจะสร้างบัญชีที่เลียนแบบสูงโดยมีหมายเลขแรกและหมายเลขสุดท้ายเหมือนกันสำหรับที่อยู่ผู้ใช้ทุกรายในเครือข่ายทั้งหมด เมื่อผู้ใช้ส่งการโอน ผู้โจมตีจะใช้บัญชีที่เลียนแบบสูงเพื่อส่งการโอนเล็กน้อยในเครือข่ายของผู้ใช้ ใบเสร็จรับเงิน ทิ้งบันทึกไว้ในบันทึกการชำระเงิน เมื่อผู้ใช้ที่รับต้องการโอนโทเค็นกลับ เขาอาจคัดลอกที่อยู่จากบันทึกประวัติ ในขณะนี้ มีแนวโน้มว่าจะถูกคัดลอกไปยังที่อยู่ของผู้โจมตี ทำให้การโอนไปยังที่อยู่ไม่ถูกต้อง ผู้โจมตีสามารถคาดเดาได้อย่างแม่นยำ พฤติกรรมของผู้ใช้
แสดงความคิดเห็นตกปลา
TON สามารถเพิ่มความคิดเห็นเมื่อถ่ายโอนไปยังหมายเหตุข้อมูลธุรกรรม มักใช้เมื่อชาร์จการแลกเปลี่ยน อย่างไรก็ตาม ฟังก์ชันนี้มักถูกนำไปใช้ในทางที่ผิด โดยผู้โจมตีจะฉ้อโกงผู้ใช้ทรัพย์สินของตนด้วยการเขียนข้อมูลที่เป็นการฉ้อโกงลงในบันทึก ดังแสดงในภาพ:
ผู้ใช้จำเป็นต้องให้ความสนใจเป็นพิเศษกับหมายเลขโทรเลขที่ไม่ระบุชื่อ NFT หากผู้ใช้ใช้หมายเลขโทรเลขที่ไม่ระบุชื่อเพื่อเปิดบัญชี TG แต่ไม่เปิดการยืนยันแบบสองขั้นตอน เมื่อ NFT ถูกฟิชชิ่ง แฮกเกอร์สามารถเข้าสู่ระบบบัญชี TG เป้าหมายได้โดยตรง และดำเนินการขโมยทรัพย์สินในภายหลัง
ช่องโหว่ของสัญญาอัจฉริยะ
ช่องโหว่ด้านความปลอดภัยในสัญญาอัจฉริยะจะสร้างความเสียหายให้กับเงินทุนของผู้ใช้ที่อยู่ในสัญญาอัจฉริยะ ผู้ใช้จำเป็นต้องเลือกโครงการที่ได้รับการตรวจสอบอย่างดีเมื่อเลือกโครงการ สัญญาอัจฉริยะของ TON ได้รับการตั้งโปรแกรมโดยใช้ภาษา FunC เป็นหลัก แต่ยังใช้ Tact ขั้นสูงกว่าหรือ Fift ระดับล่าง ซึ่งเป็นภาษาต้นฉบับทั้งหมด ภาษาการเขียนโปรแกรมใหม่จะนำมาซึ่งความเสี่ยงด้านความปลอดภัยใหม่ๆ โดยเฉพาะอย่างยิ่งสำหรับนักพัฒนา พวกเขาต้องมีนิสัยที่ดีในการเขียนโปรแกรมอย่างปลอดภัย ฝึกฝนแนวทางปฏิบัติด้านความปลอดภัยที่ดีที่สุด และผ่านการตรวจสอบความปลอดภัยที่เข้มงวดก่อนที่จะปรับใช้กับสภาพแวดล้อมการใช้งานจริง บทความนี้ Lets ยังไม่หารือเรื่องความปลอดภัยของสัญญาในตอนนี้
การโจมตีเติมเงินปลอม
ผู้ใช้กระเป๋าเงินหรือการแลกเปลี่ยนจำเป็นต้องให้ความสนใจกับการโจมตีการเติมเงินปลอม โดยปกติแล้วการโจมตีการเติมเงินปลอมจะมีอยู่สองประเภท:
สำหรับเหรียญปลอม ผู้โจมตีจะออกโทเค็นที่มีข้อมูลเมตาเดียวกันกับโทเค็นเป้าหมาย หากโปรแกรมป้อนอัตโนมัติไม่ได้ตรวจสอบว่านี่คือสัญญาการขุดที่ถูกต้องหรือไม่ จะนำไปสู่การป้อนที่ไม่ถูกต้อง
Bounce กระบวนการโอนของ TON ต้องการความสัมพันธ์ในการเรียกระหว่างสัญญากระเป๋าเงินของผู้ใช้ทั้งสอง หากไม่มีสัญญากระเป๋าเงินของผู้รับและธุรกรรมถูกตั้งค่าเป็น Bounceable ข้อความจะถูกตีกลับและเงินเดิมจะถูกหักออกจาก ค่าธรรมเนียมการจัดการ กลับไปยังผู้ส่ง เพื่อนๆ ที่สนใจรายละเอียดสามารถตรวจสอบบทความเติมเงินปลอมที่เราเคยเปิดเผยไปก่อนหน้านี้ได้
สรุป
บทความนี้จะแนะนำหลักการทางเทคนิคพื้นฐานของ TON จากมุมมองของการสร้างคีย์สาธารณะและคีย์ส่วนตัว สัญญากระเป๋าเงิน แบบฟอร์มโทเค็น ลักษณะธุรกรรม ฯลฯ และยังกล่าวถึงปัญหาด้านความปลอดภัยที่อาจเกิดขึ้นในกระบวนการใช้ TON ฉันหวังว่าสิ่งนี้จะช่วยได้ ทุกคนเรียนรู้ นำแรงบันดาลใจ
ลิงค์อ้างอิง:
