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

วิธีตรวจสอบที่อยู่สัญญา CREATE2

CREATE2 คาดการณ์ที่อยู่จาก deployer, salt และแฮช init code แต่การตรวจสอบยังต้องใช้หลักฐานเฉพาะ chain, factory, bytecode, deployment, proxy และ ownership

อัปเดต

จัดทำขึ้นเพื่อการศึกษาเท่านั้น ไม่ใช่คำแนะนำการลงทุน การลงทุนอาจทำให้สูญเสียเงินลงทุนได้

คำตอบโดยตรง

CREATE2 คาดการณ์ที่อยู่ที่สร้างโดยสัญญา deployer เฉพาะจาก 32-byte salt และแฮชของ init_code ที่ตรงกันทุกไบต์ สูตรของโปรโตคอลคือ address = keccak256(0xff || deployer(20 bytes) || salt(32 bytes) || keccak256(init_code))[12:]: แฮช 85-byte preimage แล้วเก็บ 20 bytes สุดท้าย deployer คือ factory ที่เรียกใช้ CREATE2 ไม่จำเป็นต้องเป็นกระเป๋าที่เรียก factory

init_code ประกอบด้วย creation bytecode และอาร์กิวเมนต์ constructor ที่เข้ารหัสแบบ ABI โค้ดนี้ทำงานครั้งเดียวและสร้าง runtime bytecode เวอร์ชัน compiler, การตั้งค่า optimizer, library ที่ลิงก์, metadata, อาร์กิวเมนต์ constructor หรือ entry point ของ factory อาจเปลี่ยนแฮชได้ runtime code เป็นผลลัพธ์ไม่ใช่ข้อมูลนำเข้า CREATE2 ที่อยู่จะนำมาเปรียบเทียบได้ก็ต่อเมื่อ deployer, salt, init code, กฎ EVM และสถานะ chain เหมือนกัน

ที่อยู่แบบ counterfactual อาจรับเงินก่อนมีโค้ด แต่ยังไม่มีตรรกะควบคุมที่ตรวจสอบแล้ว การคาดการณ์ไม่ใช่หลักฐานของการปรับใช้ ความเป็นเจ้าของ การอนุญาต finality หรือความปลอดภัย ตรวจสอบ bytecode และ calldata ของ factory, receipt และ event, eth_getCode, nonce, storage, balance, implementation ของ proxy, initializer และ owner บน chain และ block ที่ต้องการ

วิธีการทำงาน

ตรึง chain หรือ domain, กฎ fork, RPC และ block, ที่อยู่ factory และ runtime hash, raw salt, init bytes ที่แน่นอน, การเข้ารหัส constructor, compiler และ library ที่ลิงก์ คำนวณ keccak256(init_code) และ 85-byte preimage ใหม่ ตรวจ padding ของ ABI, ลำดับ byte, checksum และการดึง 20 byte สุดท้าย

ถอดรหัส factory call และ value ยืนยันว่า factory, entry point, salt domain, constructor, owner และ initializer ที่ต้องการถูกผูกไว้ด้วยกัน สำหรับ minimal proxy ให้แฮช creation bytecode ของ clone ที่มีที่อยู่ implementation ไม่ใช่ runtime bytecode ของ implementation สำหรับ proxy ให้ตรวจ implementation, admin, storage slot และนโยบาย upgrade แยกกัน

EIP-684 ทำให้ creation revert เมื่อ nonce ของปลายทางไม่เป็นศูนย์หรือ code ไม่ว่าง constructor ที่ล้มเหลวก็ไม่ทิ้ง deployment ที่สำเร็จ ความหมายของ SELFDESTRUCT และ redeployment ภายหลังขึ้นกับกฎ fork อย่าใช้สมมติฐานเก่าว่า code สามารถถูกแทนที่ได้ตามต้องการเสมอ

หลักฐาน deployment มีหลายชั้น ได้แก่ inclusion และ status ของธุรกรรม event code และ nonce storage และ balance แล้วจึงเป็นสถานะ chain ที่ปลอดภัยหรือ final การตอบกลับ RPC สำเร็จหรือ checksum ที่คาดการณ์ไม่แทนการตรวจ receipt และ state สำเนาที่อยู่เดียวกันข้าม chain อาจมี code, owner, storage และสินทรัพย์ต่างกัน

ใช้ขั้นตอนนี้:

  1. ตรึง chain, fork, RPC และ block, ที่อยู่ factory หรือ deployer และ runtime hash, salt bytes, init code, constructor arguments, compiler และ linked libraries
  2. คำนวณ init-code hash และ CREATE2 preimage ที่แน่นอน ตรวจ widths, padding, 0xff, 20 bytes สุดท้าย และ checksum
  3. ถอดรหัส factory calldata และ value เปรียบเทียบ predicted address, owner, initializer, proxy target และ permissions
  4. ตรวจ receipt, status, events, eth_getCode, nonce, balance และ storage บน chain ที่ถูกต้อง บันทึก state not-deployed และ collision
  5. ตรวจสมมติฐานของ factory, proxy, implementation, admin, initializer, upgrade และ singleton factory รวมถึง target ของ ERC-1167
  6. ทดสอบ constructor failure, nonce/code collision, redeployment ที่ขึ้นกับ fork, nested factory และสมมติฐาน chain-domain หรือ replay
  7. ก่อน funding หรือ signing ให้เทียบจำนวนที่มนุษย์อ่านได้กับ raw หลัง deployment ให้ติดตาม code hash, owner, implementation, role, events และ finality

ตัวอย่าง

  • เวกเตอร์ EIP-1014: deployer 0x0000000000000000000000000000000000000000, salt เป็นศูนย์ทั้งหมด และ init 0x00 ให้ผล 0x4D1A2e2bB4F88F0250f26Ffff098B0b30B26BF38
  • การผูกกับ constructor: เมื่อ deployer และ salt คงที่ การเปลี่ยนอาร์กิวเมนต์ constructor ที่เข้ารหัส ABI หนึ่งค่าเปลี่ยน keccak256(init_code) และ predicted address การแฮช runtime bytecode จะตรวจวัตถุผิดรายการ
  • Collision: หาก nonce ปลายทางมากกว่า 0 หรือ code ไม่ว่าง CREATE2 ต้อง revert ตาม EIP-684 ที่อยู่ที่มีเงินแต่ code และ nonce เป็นศูนย์ยังเป็นเพียง counterfactual และยังไม่ผ่านการตรวจ
  • Minimal proxy: ที่อยู่ clone ของ ERC-1167 แฮช clone creation bytecode ที่มีที่อยู่ implementation การแฮช runtime bytecode ของ implementation ให้ prediction ที่ไม่เกี่ยวข้อง

ความเสี่ยง

  • ใช้ factory หรือ deployer ผิดรายการ
  • ความกว้าง padding endian หรือ domain encoding ของ salt ผิด
  • สับสน init code กับ runtime bytecode
  • ละเว้นหรือเรียง constructor arguments ผิด
  • factory entry point, value หรือ calldata แตกต่าง
  • proxy หรือ delegate target ไม่ใช่ implementation ที่ต้องการ
  • chain, fork หรือ EVM domain แตกต่าง
  • nonce ที่มีอยู่ทำให้เกิด collision
  • code ที่มีอยู่ทำให้เกิด collision
  • ใช้สมมติฐานเก่าเกี่ยวกับ SELFDESTRUCT และ redeployment
  • nested CREATE2 เปลี่ยน deployer ที่มีผลจริง
  • สับสนสูตร CREATE กับ CREATE2
  • ไม่ตรวจ implementation target ของ ERC-1167
  • ไม่ตรวจที่อยู่ singleton factory และสมมติฐานการปรับใช้
  • upgrade หรือ admin control เปลี่ยนพฤติกรรมของ implementation
  • compiler, metadata, library หรือ source artifact แตกต่าง
  • สับสน receipt, mempool, failure และ finality
  • checksum หรือ UI poisoning ซ่อนที่อยู่ผิด
  • เงินใน counterfactual ที่เติมไว้ล่วงหน้าไม่มีหลักฐาน ownership
  • สมมติฐาน EIP-7702, replay, gas, denial-of-service หรือ monitoring ไม่ถูกต้อง

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

  • “ที่อยู่ว่างปลอดภัยหรือมีเจ้าของแล้ว” อาจไม่มี code หรือ controller ที่ตรวจสอบได้
  • “salt เพียงอย่างเดียวกำหนดที่อยู่” deployer และ init-code hash ก็เป็นส่วนผูกมัดเช่นกัน
  • “CREATE2 แฮช runtime bytecode” มันแฮช creation code รวมอาร์กิวเมนต์ constructor
  • “ที่อยู่เดียวกันบนสอง chain หมายถึง code และ control เหมือนกัน” ต้องตรวจ state และ deployment ของแต่ละ chain แยกกัน
  • “การคาดการณ์สำเร็จพิสูจน์ deployment และความปลอดภัย” มีเพียง receipt, code, state, permissions และ finality ที่ยืนยันสิ่งซึ่งมีอยู่จริง

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

แหล่งข้อมูล

การนำทาง

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