---
title: "Chain ID"
description: "คู่มือที่เริ่มจากการตรวจสอบ chain ID ของ EVM, โดเมนป้องกัน replay ของธุรกรรม legacy ตาม EIP-155, ธุรกรรมแบบ typed, CHAINID, การตรวจสอบกระเป๋าเงินและ RPC, โดเมน EIP-712 และตัวระบุเครือข่ายที่ไม่ใช่ EVM"
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Chain ID
> จัดทำขึ้นเพื่อการศึกษาเท่านั้น ไม่ใช่คำแนะนำการลงทุน การลงทุนอาจทำให้สูญเสียเงินลงทุนได้
## คำตอบโดยตรง
ในระบบนิเวศ EVM chain ID คือจำนวนเต็มที่กำหนดค่าไว้เพื่อใช้เป็นพารามิเตอร์ของโดเมนป้องกัน replay โดย EIP-155 ผูกค่านี้เข้ากับลายเซ็นของธุรกรรม legacy ที่มีการป้องกัน รูปแบบธุรกรรมแบบ typed เช่น type 2 จะเข้ารหัสค่านี้ไว้ใน payload ที่ลงนามของตนเอง คำสั่ง `CHAINID` เปิดเผยค่านี้ระหว่างการประมวลผล EVM และ `eth_chainId` รายงานค่าผ่าน JSON-RPC สิ่งเหล่านี้เป็นอินเทอร์เฟซที่เกี่ยวข้องกัน ไม่ใช่ใบรับรองตัวตนสากล
ไม่มีหลักประกันว่าค่านี้จะไม่ซ้ำกันทั่วโลกหรือคงอยู่ตลอดไป เครือข่ายส่วนตัวและ fork ที่มีข้อขัดแย้งอาจใช้ค่าซ้ำ RPC อาจรายงานเท็จ และ address เดียวกันอาจมี code กับ state ต่างกันในคนละ chain EIP-712 มี field chain ID ที่ไม่บังคับในโดเมน ขณะที่ข้อความดิบและระบบที่ไม่ใช่ EVM มีกฎป้องกัน replay และระบุตัวตนเครือข่ายต่างออกไป การใช้งานที่ถูกต้องจึงต้องระบุรูปแบบการลงนาม endpoint, genesis หรือ checkpoint และโดเมนของแอปพลิเคชันอย่างแน่นอน
## กลไกการทำงาน
1. ระบุระบบนิเวศและความหมายของตัวระบุก่อน ได้แก่ จำนวนเต็ม EIP-155 ของ EVM, โดเมน EIP-712, reference ที่มี namespace ของ CAIP-2, chain ID แบบ string ของ Cosmos, genesis hash ของ Solana หรือรูปแบบอื่น ห้ามเปรียบเทียบตัวเลขที่ไม่มีตัวกำกับข้ามระบบนิเวศ
2. ตรึงภาพเครือข่ายที่เชื่อถือได้ ได้แก่ URL ของ RPC, chain ID ที่คาดไว้ทั้งเลขฐานสิบและฐานสิบหก, genesis หรือ checkpoint ที่ final แล้ว, head block, การกำหนดค่าของ client, `codeHash` ของสัญญาหลัก และเวลาของแหล่งข้อมูล ชื่อและไอคอนเครือข่ายในกระเป๋าเงินเป็น metadata ที่เชื่อถือไม่ได้
3. เรียก `eth_chainId` สำหรับการลงนาม EVM และแปลงค่า quantity ฐานสิบหกของ JSON-RPC โดยไม่สูญเสียความแม่นยำ เปรียบเทียบจำนวนเต็มที่ปรับรูปแบบแล้วกับการกำหนดค่าที่คาดไว้และ state ของ wallet provider ห้ามใช้ `net_version` แทน และให้ปฏิเสธเมื่อค่าไม่ตรงก่อนสร้างลายเซ็น
4. สร้างโดเมนการลงนามขึ้นใหม่อย่างแม่นยำ แยกธุรกรรม legacy ที่ไม่มีการป้องกัน การเข้ารหัส legacy ที่ EIP-155 ป้องกัน และ envelope แบบ typed สำหรับ EIP-712 ให้ตรวจ field ของโดเมน `verifyingContract`, nonce และ deadline ส่วน intent ที่ส่งผ่าน relayer หรือ smart account ให้ตรวจ hash ภายในของโปรโตคอล
5. ตรวจสอบเป้าหมายการประมวลผลบน chain ที่ใช้งานอยู่ ได้แก่ ผู้รับ มูลค่า calldata, address ของโทเค็น code ของสัญญาหรือ proxy implementation, nonce ของบัญชี ค่าธรรมเนียม และ state จากการจำลอง chain ID แยกโดเมนออกจากกัน แต่ไม่ได้พิสูจน์ว่าวัตถุเหล่านี้เป็นของแท้
6. ถือว่า EIP-1193 `chainChanged` การเปลี่ยนบัญชี และการตัดการเชื่อมต่อเป็นขอบเขต state ที่เข้มงวด ทิ้ง quote, allowance, nonce, simulation และคำขอลงนามที่ cache ไว้ อ่าน chain กับเป้าหมายใหม่ และ broadcast เฉพาะธุรกรรมดิบที่ตรวจทานแล้วไปยัง endpoint ที่ตรึงไว้
7. กระทบยอดธุรกรรมบน chain ที่ตั้งใจ ได้แก่ signed raw bytes กับ hash, การยอมรับของ RPC, สถานะ receipt, เลขและ hash ของบล็อก การใช้ nonce, การเปลี่ยน state และ finality ที่ต้องการ เฝ้าระวัง chain split, การเปลี่ยน ID, ความสับสนระหว่างโดเมน L1/L2 และ provider drift แล้วหยุดเมื่อพบความแตกต่างที่อธิบายไม่ได้
## ตัวอย่างคำนวณ
- **ด่านตรวจค่า RPC ฐานสิบหกและฐานสิบ** Base มี chain ID ฐานสิบเป็น `8453` ซึ่ง `eth_chainId` แสดงเป็น `0x2105`: `2 * 4096 + 1 * 256 + 0 * 16 + 5 = 8453` ส่วน Ethereum mainnet คือ `1 = 0x1` และ Arbitrum One คือ `42161 = 0xa4b1` หากกระเป๋าเงินคาดว่าเป็น `8453` แต่ได้รับ `0x1` ต้องยกเลิกก่อนลงนามแทนที่จะเชื่อชื่อเครือข่ายที่แสดง
- **ค่า v ของธุรกรรม legacy ที่มีการป้องกัน** สำหรับธุรกรรม legacy ตาม EIP-155 ใช้ `v = 35 + 2 * chainId + yParity` เมื่อ chain ID เป็น `1` ค่าจะเป็น `37` หรือ `38` และเมื่อ chain ID เป็น `61` ค่าจะเป็น `157` หรือ `158` ในทางกลับกัน `floor((37 - 35) / 2) = 1` การคำนวณนี้ใช้ไม่ได้กับ field y-parity ของธุรกรรมแบบ typed หรือกับลายเซ็น legacy ที่ไม่มีการป้องกันซึ่งใช้ `27` หรือ `28`
- **ธุรกรรมแบบ typed และการปฏิเสธบน chain ที่ผิด** payload แบบ type 2 ผูกกับ `chain_id=8453` เมื่อมี `21,000 gas`, base fee `20 gwei`, maximum priority fee `2 gwei` และ maximum fee `30 gwei` ราคา gas ที่ใช้จริงคือ `min(30, 20 + 2) = 22 gwei` และค่าธรรมเนียมคือ `21,000 * 22 gwei = 0.000462 ETH` chain ที่บังคับใช้กฎอย่างถูกต้องและกำหนด ID เป็น `1` จะปฏิเสธ payload ที่ลงนามนี้เพราะโดเมนไม่ตรง ดังนั้นการปฏิเสธเองจึงไม่ใช้ gas บน chain นั้น แต่ธุรกรรมยังอาจล้มเหลวด้วยเหตุผลอื่นบน ID 8453
- **ระบบที่ไม่ใช่ EVM และตัวระบุสองชุด** การติดตั้ง Cosmos EVM อาจใช้ ID แบบ string ของ Cosmos SDK เป็น `local-1` และ ID แบบจำนวนเต็มของ EVM ที่เป็นอิสระเป็น `262144 = 0x40000` การลงนามแบบ native ของ Cosmos ใช้ string ร่วมกับ account number และ sequence ส่วนการลงนามธุรกรรม EVM ใช้โดเมนจำนวนเต็ม ขณะที่ Solana เปิดเผย genesis hash และใช้ recent blockhash หรือ durable nonce ในข้อความธุรกรรม ไม่ได้ใช้จำนวนเต็ม EIP-155
## ความเสี่ยง
- เชื่อมต่อ RPC endpoint ผิดหรืออยู่บน chain ของกระเป๋าเงินที่ไม่ตั้งใจใช้
- เชื่อ RPC ที่ประสงค์ร้ายซึ่งรายงาน chain ID, state หรือผล broadcast เป็นเท็จ
- สับสนระหว่างการแสดง chain ID แบบฐานสิบหกกับฐานสิบ
- สูญเสียความแม่นยำจากการแปลง chain ID ขนาดใหญ่ด้วยชนิดตัวเลขที่ไม่ปลอดภัย
- ใช้ `net_version` ราวกับว่าเท่ากับ `eth_chainId` เสมอ
- พลาด event EIP-1193 `chainChanged` หรือเกิด race ระหว่างสลับเครือข่าย
- ใช้ nonce, quote, approval หรือ simulation ที่ cache ไว้ซ้ำหลังสลับเครือข่าย
- สมมติว่า chain ID มีทะเบียนกลางและไม่ชนกัน
- ลงนามข้ามเครือข่ายส่วนตัวหรือ fork ที่ใช้ chain ID เดียวกันซ้ำ
- ไม่กำหนดวิธีรับมือเมื่อ fork เปลี่ยนหรือคง ID เดิม
- ยอมรับธุรกรรม legacy ที่ไม่มีการป้องกันและไม่มีโดเมน EIP-155
- นำสูตร legacy `v` ไปใช้กับธุรกรรมแบบ typed หรือลายเซ็นชนิดอื่น
- สมมติว่าข้อความดิบหรือคำขอ `personal_sign` มีโดเมนของ chain
- ไม่ใส่หรือเข้ารหัส chain ID ผิดในโดเมน EIP-712
- ไม่ใส่ `verifyingContract`, nonce ของแอปพลิเคชัน deadline หรือวัตถุประสงค์
- เชื่อ address ของสัญญาที่เหมือนกันโดยไม่เปรียบเทียบ code และ state
- สับสนโดเมนการลงนามของ L1, L2, ต้นทางบริดจ์ และปลายทาง
- มองข้ามโดเมนภายในของ intent ที่ส่งผ่าน relayer, permit หรือการทำงานของ smart account
- ถือว่า metadata การเพิ่มเครือข่าย ป้ายของ explorer หรือไอคอนเป็นการยืนยันตัวตนเครือข่าย
- นำความหมายของ EVM ไปใช้กับ Cosmos, Solana, Bitcoin หรือโปรโตคอลอื่น
## ความเข้าใจผิดที่พบบ่อย
- Chain ID เป็นหมายเลขทะเบียนทางการที่ไม่ซ้ำกันทั่วโลกและคงอยู่ถาวร
- Chain ID ที่ถูกต้องพิสูจน์ว่า RPC endpoint เครือข่าย และสัญญาเป็นของแท้
- ลายเซ็น Ethereum ทุกแบบผูกกับ chain ID โดยอัตโนมัติ
- Chain ID ที่ต่างกันป้องกัน replay ของข้อความที่ลงนามและ intent ของแอปพลิเคชันได้ทุกชนิด
- บล็อกเชนทุกเครือข่ายใช้ chain ID แบบจำนวนเต็มตาม EIP-155
## หัวข้อที่เกี่ยวข้อง
- [ลายเซ็นแบบ typed ตาม EIP-712](/th/crypto/eip712-typed-signature/)
- [ลายเซ็นกระเป๋าเงิน](/th/crypto/wallet-signature/)
- [โหนด RPC](/th/crypto/rpc-node/)
## แหล่งข้อมูล
- [EIP-155: Simple replay attack protection](https://eips.ethereum.org/EIPS/eip-155) - Ethereum Improvement Proposals (เข้าถึง: 2026-08-12)
- [EIP-1559: Fee market change for ETH 1.0 chain](https://eips.ethereum.org/EIPS/eip-1559) - Ethereum Improvement Proposals (เข้าถึง: 2026-08-12)
- [EIP-1344: ChainID opcode](https://eips.ethereum.org/EIPS/eip-1344) - Ethereum Improvement Proposals (เข้าถึง: 2026-08-12)
- [EIP-1193: Ethereum Provider JavaScript API](https://eips.ethereum.org/EIPS/eip-1193) - Ethereum Improvement Proposals (เข้าถึง: 2026-08-12)
- [EIP-3085: wallet_addEthereumChain RPC Method](https://eips.ethereum.org/EIPS/eip-3085) - Ethereum Improvement Proposals (เข้าถึง: 2026-08-12)
- [EIP-712: Typed structured data hashing and signing](https://eips.ethereum.org/EIPS/eip-712) - Ethereum Improvement Proposals (เข้าถึง: 2026-08-12)
- [CAIP-2: Blockchain ID Specification](https://standards.chainagnostic.org/CAIPs/caip-2) - Chain Agnostic Improvement Proposals (เข้าถึง: 2026-08-12)
- [getGenesisHash RPC Method](https://solana.com/docs/rpc/http/getgenesishash) - Solana Documentation (เข้าถึง: 2026-08-12)
Source: https://wiki.fcontext.com/th/crypto/chain-id/index.mdx