ข้ามไปยังเนื้อหา
Financial Context Wiki

วิธีตรวจสอบจำนวนทศนิยมของโทเค็น

ตรวจสอบ decimals ของ ERC-20 จากสัญญาและบล็อกที่ถูกต้อง แล้วกระทบยอดยอดคงเหลือดิบ การโอน การอนุมัติ และการแปลงผ่านบริดจ์โดยไม่มีข้อผิดพลาดแบบ floating-point

อัปเดต

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

คำตอบโดยตรง

สำหรับโทเค็น ERC-20 ฟังก์ชัน decimals() คือข้อมูลเมตาที่ไม่บังคับ ซึ่งบอกอินเทอร์เฟซว่าจะแสดงหน่วยโทเค็นจำนวนเต็มอย่างไร หากคืนค่า d จำนวนที่แสดงตามธรรมเนียมคือ raw / 10^d ค่านี้ไม่เปลี่ยนการคำนวณของสัญญาและไม่รับรองตัวตนโทเค็น ก่อนเชื่อผลลัพธ์ ให้ตรวจสอบเชน ที่อยู่สัญญาที่แน่นอน โค้ดหรือ implementation ของ proxy และบล็อก

อ่าน decimals() โดยตรงผ่าน RPC อิสระที่บล็อกที่ระบุ ถอดรหัสผล ABI เป็น uint8 แล้วเทียบกับทะเบียนสัญญาทางการของผู้ออกและ explorer ที่เชื่อถือได้ จากนั้นทดสอบสเกลกับค่า balanceOf ดิบ การโอน การอนุมัติ receipt และ event อย่าสมมติ 18 โดยอัตโนมัติเมื่อไม่มีฟังก์ชัน การเรียก revert ข้อมูลผิดรูป หรือขัดกับหลักฐานอื่น

กลไกการทำงาน

ERC-20 จัดเก็บและโอนจำนวนเป็นเลขจำนวนเต็มไม่มีเครื่องหมาย ชั้นแสดงผลเป็นผู้ใส่จุดทศนิยม ส่วนสัญญายังรับเลขจำนวนเต็ม แปลงอินพุตด้วยสตริงทศนิยมหรือจำนวนเต็มความแม่นยำไม่จำกัด ห้ามใช้ floating-point ฐานสอง จำนวนจะใช้ได้ก็ต่อเมื่อคูณด้วย 10^d แล้วได้จำนวนเต็ม

เนื่องจาก decimals() ไม่บังคับ โทเค็นที่เป็นไปตามมาตรฐานอาจไม่มีฟังก์ชันนี้ implementation แบบกำหนดเองหรืออัปเกรดได้อาจคืนค่าที่ไม่คาดคิดหรือเปลี่ยนหลังอัปเกรด สำหรับ proxy ERC-1967 ให้ตรวจที่อยู่ proxy, implementation หรือ beacon, ผู้ดูแล และ event การอัปเกรด อ่านสถานะโทเค็นที่ที่อยู่ proxy และตรึงการเปรียบเทียบทั้งหมดไว้ที่บล็อกเดียวกัน

Allowance และค่า ERC-2612 permit ก็เป็นจำนวนเต็มดิบเช่นกัน การแสดงผลการโอนถูกต้องไม่ได้พิสูจน์ว่าการอนุมัติ ค่าต่ำสุดของ router จำนวนบริดจ์ หรือฐานข้อมูลบัญชีใช้สเกลเดียวกัน สัญญาต้นทางและปลายทางของบริดจ์อาจมี decimals ต่างกัน จึงต้องเทียบมูลค่าที่อ่านได้และหน่วยดิบทั้งสองด้านตามกฎการแปลงและปัดเศษที่ระบุไว้

ใช้ขั้นตอนต่อไปนี้:

  1. ตรึง chain ID หรือ domain, สัญญาโทเค็น, เลขบล็อก, endpoint RPC และเวลาที่สังเกต
  2. ยืนยันที่อยู่จากทะเบียนทางการของผู้ออก อย่าถือว่าชื่อ สัญลักษณ์ ไอคอน หรือผลค้นหาเป็นหลักฐานที่เชื่อถือได้
  3. ตรวจโค้ดที่ deploy และดูว่าที่อยู่เป็น proxy หรือไม่ บันทึก implementation หรือ beacon, ผู้ดูแล และการอัปเกรดล่าสุด
  4. เรียก decimals() ถอดรหัส uint8 ตาม ABI และบันทึกผลสำเร็จ revert ค่าว่าง หรือผลผิดรูป โดยไม่แทนด้วยค่าเริ่มต้น
  5. อ่าน balanceOf, totalSupply, allowance, calldata ธุรกรรม, receipt และ event แบบดิบที่บล็อกสอดคล้องกัน แล้วจัดรูปแบบด้วยสเกลที่พบ
  6. คำนวณการโอน การอนุมัติ ราคาเสนอ และบริดจ์ใหม่ด้วยจำนวนเต็ม รวมค่าธรรมเนียม การปัดเศษ เศษคงเหลือ rebase หรือภาษีการโอน
  7. จำลองและส่งธุรกรรมขนาดเล็ก แล้วกระทบยอดดิบก่อนและหลัง หยุดหากอินเทอร์เฟซ RPC event หรือยอดคงเหลือไม่ตรงกัน

ตัวอย่าง

  • ค่าดิบเดียว สองสเกล เมื่อ raw = 123456789, d = 6 แสดง 123.456789 ส่วน d = 18 แสดง 0.000000000123456789 ต่างกันเป็น 10^12 เท่า
  • ต้องคำนึงถึงค่าที่แทนได้ เมื่อ d = 6, 1.25 โทเค็นเป็นหน่วยดิบ 1250000 ส่วน 0.0000001 โทเค็นเล็กกว่าหนึ่งหน่วยดิบ จึงต้องปฏิเสธหรือปัดตามกฎที่ระบุชัด
  • สเกลการอนุมัติผิด allowance 100 โทเค็นเมื่อ d = 6 คือ 100000000 หากเข้ารหัสด้วย d = 18 จะเป็น 100000000000000000000 หรือมากกว่าที่ตั้งใจ 10^12 เท่า
  • ปรับสเกลผ่านบริดจ์ หากเส้นทาง 1:1 ที่มีเอกสารแปลงโทเค็นต้นทาง d = 6 เป็นตัวแทนปลายทาง d = 18 ค่าดิบ 2500000 แทน 2.5 โทเค็น และค่าปลายทาง 2500000000000000000 ก็แทน 2.5 ยังต้องตรวจค่าธรรมเนียม เพดาน เศษ และยอดรับจริง

ความเสี่ยง

  • สอบถามที่อยู่ถูกต้องบนเชนที่ผิด
  • ชื่อ สัญลักษณ์ หรือไอคอนที่ลอกมาซ่อนสัญญาอื่น
  • implementation ของ proxy หรือ beacon เปลี่ยนหลังการตรวจ
  • RPC หรือ explorer ให้สถานะเก่า ยังไม่ final หรือไม่สอดคล้อง
  • ข้อมูลเมตาที่หายหรือผิดรูปถูกแทนด้วย 18 โดยไม่แจ้ง
  • floating-point ฐานสองปัดจำนวนมากหรือจำนวนละเอียด
  • กระเป๋าจัดรูปแบบการโอนถูก แต่จัด allowance หรือ permit ผิด
  • ฐานข้อมูลปะปนหน่วยดิบกับจำนวนที่คนอ่าน
  • บริดจ์สมมติ decimals เท่ากันหรือไม่เปิดเผยการปัดเศษ
  • fee-on-transfer, rebase, mint, burn, pause หรือ freeze ทำให้กระทบยอดแบบง่ายไม่ได้
  • calldata, event, receipt และการเปลี่ยนยอดจริงไม่ตรงกัน
  • เข้าใจผิดว่าการตรวจ decimals พิสูจน์ผู้ออก เงินสำรอง สภาพคล่อง หรือความปลอดภัย

ความเข้าใจผิดที่พบบ่อย

  • ERC-20 ทุกตัวมี 18 decimals ข้อมูลนี้ไม่บังคับและ implementation อาจคืนค่าอื่น
  • Decimals คือบิตความแม่นยำที่ EVM ใช้ นี่เป็นธรรมเนียมแสดงผลฐานสิบ การคำนวณโทเค็นยังเป็นจำนวนเต็ม
  • ยอดที่ explorer จัดรูปแบบคือการยืนยันอิสระ อาจพึ่งการเรียกข้อมูลเดียวกันและมีข้อผิดพลาดเดียวกัน
  • สัญลักษณ์และ decimals เดียวกันระบุสินทรัพย์เดียวกัน ยังต้องมีเชนถูกต้อง สัญญาแน่นอน และหลักฐานจากผู้ออก
  • การโอนเล็กที่สำเร็จตรวจสอบทุก integration แล้ว การอนุมัติ router บริดจ์ exchange และบัญชีอาจปรับสเกลแยกกัน

หัวข้อที่เกี่ยวข้อง

แหล่งข้อมูล

การนำทาง

ค้นหาในวิกิ...