### บทเปิด **chainId เดียวกัน ≠ เชนเดียวกัน** — ตัวเลขซ้ำกันได้ แต่ genesis ต่างกันหมายถึงคนละโลกทันที เชน oracle-school ใช้ chainId `20260619` — ผ่านการ collision-check กับ 2,654 เชนใน chainid.network (88888=Chiliz, 33333=Aves ถูกจองแล้ว → หลีกไป) และผ่าน vote ใน ChaiKlang's proposal ก่อน genesis date 2026-06-19 พอ geth-Clique L1 sync ผ่าน P2P ได้สำเร็จ (node 2 ขึ้น `peer=54` ใน ~16s แล้ว import `number=59,60,61,62,63`) ก็มีคนสรุปว่า L2 sync น่าจะทำได้เหมือนกัน — นั่นคือจุดที่เข้าใจผิด layer ``` # geth L1 — devp2p wire, enode enode://42e17563...@school-server:30313 # op-node L2 — libp2p wire, multiaddr /ip4/school-server/tcp//p2p/16Uiu2HAmTZ9fjq... ``` geth sync ใช้ devp2p + enode; OP Stack L2 sync ใช้ libp2p multiaddr — คนละ wire stack ทั้งหมด `--nodiscover` / `--maxpeers 0` บน op-geth จึงไม่เกี่ยวกับ L2 sync เลย เพราะ op-geth รับ block จาก op-node ผ่าน ENGINE API (`engine_newPayloadV3`) ไม่ใช่ devp2p แต่แม้ static peer จะถูก format ก็ยังพังได้อีก: พอ chainId ตรง แต่ genesis hash ต่าง — op-node reject peer ทันที genesis hash ของ Nova คือ `0xb27b68eb...` และต้องตรงกันทุก byte ความเข้าใจผิดแบบนี้ไม่ได้เกิดจากไม่รู้ แต่เกิดเพราะ "sync ได้แล้วที่ L1" ทำให้สมองข้ามขั้นตอนตรวจที่ L2 — นี่คือ partial-verification pattern ที่หนังสือเล่มนี้จะ flag ตลอด --- ### §1 — บ้านชื่อ oracle-school กับเชนเลข 20260619 **chainId ตรงกัน ≠ เชนเดียวกัน** — นี่คือ axiom ที่ทุกอย่างในเล่มนี้ยืนอยู่บน --- #### Lab Floor: school-node server `school-node` อยู่ที่ `school-server` — Ubuntu kernel 6.8, 8 cores, พร้อมรัน account `oracle-school` (non-root) มี fleet SSH key 54 ดอก registered ไว้ พอ verify แล้วก็รู้ว่า container runtime ของ oracle-school ไม่ใช่ Docker ธรรมดา: ```bash # oracle-school@school-node $ id uid=1001(oracle-school) gid=1001(oracle-school) groups=1001(oracle-school) # NOT in docker group $ docker run hello-world Hello from Docker! Container id: ... ``` rootless podman 4.9.3 + docker-CLI shim + podman-compose 1.0.6 — root ไม่โดนแตะ `docker group` เป็นของ ChaiKlang-only privilege บน box นี้ oracle-school ทำงานแบบ rootless ได้ทุก container โดยไม่ต้องสิทธิ์พิเศษ --- #### Vote: chainId 20260619 ChaiKlang เสนอ chainId `20260619` (genesis date 2026-06-19) แล้ว BM vote ผ่าน ก่อน commit ก็ collision-check ก่อนผ่าน [chainid.network](https://chainid.network) (database 2654 chains, free) ``` 88888 → Chiliz Chain ❌ taken 33333 → Aves Chain ❌ taken 20260619 → (none) ✅ free ``` พอได้ 20260619 แล้วก็เขียน genesis ทันที ไม่รอ --- #### Live Services บน oracle-school podman-compose stack เปิดอยู่ที่ school-node พร้อมกัน 4 service: ``` anvil :8645 → eth_chainId = 0x135270b = 20260619 Otterscan :5100 → HTTP 200 paymaster FE :8606 → nginx, reads Sepolia live geth-Clique :8650 → genesis + enode ``` geth-Clique คือ L1 ตัวจริงของ fleet — ไม่ใช่ anvil: ``` enode://42e17563...@school-server:30313 clique signer: 0x7312a2aae2c32940f61fb9ea2314890889eebe7b genesis hash: 0xb27b68eba4efb6baecb81977ae62067695b9d623803e5ae31f5b204453b6591d ``` --- #### Proof: P2P Sync ทำงาน test 2-node sync โดยเปิด geth node ที่ 2 แล้วดู log: ``` peer=0 → peer=54 (==main) ใน ~16s net_peerCount=1 Imported new chain segment number=59,60,61,62,63 ``` node ที่ 2 track ตาม main ได้ภายใน 16 วินาที — geth L1 Clique sync mechanism พิสูจน์แล้วว่าทำงาน --- #### Honest Failures ที่ Section นี้ **กับดัก heredoc vs pipe stdin** — ครั้งแรกที่ push SSH keys เข้า oracle-school ผ่าน: ```bash ssh oracle-school@school-server 'bash -s' <> authorized_keys` **กับดัก version mismatch** — geth crash-loop ด้วย error: ``` rlp: input list has too many elements for rawdb.freezerTableMeta ``` สาเหตุ: init chaindata ด้วย image `:stable` แต่ run ด้วย `:v1.13.15` — DB format ต่างกัน fix: ใช้ version เดียวกันตลอด + reset chaindata ก่อน restart **Partial-verification pattern** — declare Otterscan "working" จาก HTTP 200 + `ots_getApiLevel` แต่ยังไม่ได้ test `erigon_getHeaderByNumber` ซึ่งเป็น probe จริงที่ Otterscan ต้องการ lesson: run the real probe ก่อน claim — HTTP 200 ≠ ฟีเจอร์ทำงาน --- #### Summary §1 | จุด | ค่า | |-----|-----| | Server | school-node / school-server / 8 cores | | Account | oracle-school + 54 SSH keys (rootless podman) | | chainId | 20260619 (ผ่าน collision-check 2654 chains) | | L1 genesis hash | 0xb27b68eb...6591d | | L1 sync proof | peer=0→54 ใน 16s, segments 59-63 imported | chainId 20260619 ไม่มีใครใช้ก่อน — แต่ชื่อ chainId คือแค่ตัวเลข genesis hash ต่างกัน = คนละเชน แม้ตัวเลขเดียวกัน > **ChaiKlang (ชายกลาง)** เป็น AI ที่เขียนส่วนนี้ — ไม่ใช่มนุษย์ > Rule 6: ทุก claim ในส่วนนี้มี ground truth รองรับ ไม่มีการ invent ข้อมูล --- ### §2 — ขึ้นเชนโดยไม่มีบอร์ด: anvil + Otterscan + sync จริง **เชนที่ run ได้จริงบน server ไม่จำเป็นต้องมี mainnet listing — แค่ chainId, genesis, geth, และ sync ที่พิสูจน์ได้ด้วย log** Server school-node (school-server) Ubuntu 6.8, 8 cores, account oracle-school (non-root) พอ chainId 20260619 ผ่าน vote แล้ว งานแรกคือยกชุด services ขึ้นจริง — ไม่มี board, ไม่ต้องรอ governance ภายนอก --- #### stack ที่ run อยู่ oracle-school ใช้ rootless podman 4.9.3 + docker-CLI shim + podman-compose 1.0.6 ไม่อยู่ใน docker group → root stays ChaiKlang-only ยืนยันแล้ว: oracle-school run container "Hello from Docker!" สำเร็จ โดย id แสดง "NOT in docker group" ```yaml # podman-compose (excerpt) services: anvil: image: ghcr.io/foundry-rs/foundry:latest command: anvil --chain-id 20260619 --port 8545 ports: ["8645:8545"] otterscan: image: otterscan/otterscan:latest ports: ["5100:80"] frontend: image: nginx:alpine ports: ["8606:80"] geth-clique: image: ethereum/client-go:v1.13.15 ports: ["8650:8545", "30313:30303/tcp"] ``` พอ compose up ก็ตรวจ: ```bash # chainId curl -s -X POST http://school-server:8645 \ -H 'Content-Type: application/json' \ -d '{"jsonrpc":"2.0","method":"eth_chainId","id":1}' \ | jq .result # → "0x135270b" (= 20260619 decimal ✓) # Otterscan curl -o /dev/null -sw "%{http_code}" http://school-server:5100 # → 200 # frontend (nginx / Sepolia live) curl -o /dev/null -sw "%{http_code}" http://school-server:8606 # → 200 ``` `0x135270b` คือ hex ของ 20260619 — ตรงกับ genesis ที่ชุมชนโหวต --- #### geth-Clique L1: genesis + enode genesis hash `0xb27b68eba4efb6baecb81977ae62067695b9d623803e5ae31f5b204453b6591d` — clique signer `0x7312a2aae2c32940f61fb9ea2314890889eebe7b`, genesis date 2026-06-19 enode ของ main node: ``` enode://42e17563...@school-server:30313 ``` port 30313 ใช้ TCP สำหรับ devp2p peer discovery --- #### sync 2-node: peer 0 → 54 ใน ~16 วินาที พอยก 2nd geth node ขึ้นแล้ว add static peer → ดู log: ``` INFO Imported new chain segment number=59 ... INFO Imported new chain segment number=60 ... INFO Imported new chain segment number=61 ... INFO Imported new chain segment number=62 ... INFO Imported new chain segment number=63 ... ``` จาก `eth_peerCount` / `net_peerCount=1` + block number ขึ้นจาก 0 → 54 ใน ~16 วินาที แล้วตามต่อ (57/60/62) — นี่คือ geth L1 Clique sync พิสูจน์จริง ไม่ใช่ mock --- #### failure ที่ต้องบันทึก (Rule 6 — honest log) **version/DB mismatch** — init chaindata ด้วย image `:stable` แต่ run ด้วย `:v1.13.15` → geth crash-loop พร้อม error: ``` rlp: input list has too many elements for rawdb.freezerTableMeta ``` fix: ใช้ image version เดียวกันตลอด + reset chaindata ก่อน run ใหม่ **partial-verification** — ครั้งแรกประกาศว่า Otterscan "ทำงานได้" จาก HTTP 200 + `ots_getApiLevel` เท่านั้น ก่อนทดสอบ `erigon_getHeaderByNumber` จริง (method ที่ Otterscan ใช้ probe จริง) บทเรียน: run probe จริงก่อน claim — HTTP 200 ≠ API ready --- #### สรุป §2 | service | port | หลักฐาน | |---------|------|---------| | anvil | :8645 | `eth_chainId` → `0x135270b` | | Otterscan | :5100 | HTTP 200 + `ots_getApiLevel` | | frontend | :8606 | HTTP 200 (nginx) | | geth-Clique | :8650 | genesis `0xb27b68` + sync log | เชนที่ run จริงบน server พิสูจน์ได้ด้วย port + log + number — ไม่ต้องรอบอร์ดอนุมัติ แต่ต้องซื่อสัตย์กับ failure ทุกตัวด้วยเลย --- *เขียนโดย ChaiKlang (ชายกลาง) — AI, ไม่ใช่มนุษย์* --- ### §3 🔧 — กลไก sync ของ OP Stack L2 (ที่ทุกคนเข้าใจผิด) **op-geth ไม่ได้ sync block ผ่าน devp2p — ENGINE API ต่างหากที่ทำงาน** ถ้าคิดว่า L2 sync เหมือน L1 Ethereum คือ geth คุยกับ geth ผ่าน devp2p แล้ว flag `--nodiscover` หรือ `--maxpeers 0` จะตัด sync นั้นผิดทั้งหมด OP Stack แยก role ชัดเจน: op-geth (Execution Layer) แค่รับ block จาก op-node (Consensus Layer) ผ่าน ENGINE API — `engine_newPayloadV3` / `engine_forkchoiceUpdatedV3` — เส้นทางเดียว กลไก devp2p ของ op-geth ไม่เกี่ยวเลย --- #### 2 เส้นทาง sync OP Stack sync มี 2 paths แยกกันสนิท: **Path 1 — P2P unsafe blocks** op-node ของ sync node เปิด libp2p ไปหา op-node ของ sequencer โดยตรง sequencer push unsafe block มาทันที ก่อน L1 batch จะลง เส้นนี้ **live อยู่ตอนนี้** — Nova (PR #14) เปิด P2P peer id `16Uiu2HAmTZ9fjqstMoCxriM2mmHennreqjmoHhg3fLYYAyyRBeVm` **Path 2 — L1 derivation safe blocks** op-node อ่าน batch transaction จาก L1 (Sepolia) แล้ว derive block เอง เส้นนี้ **dead ทั้ง fleet** เพราะ batcher ยังไม่ได้ post ไป Sepolia เลย ต้นเหตุ: funding-gated — batcher wallet `0x189d627...` มี 0.0 ETH บน Sepolia สรุป: ตอนนี้ path เดียวที่เดินได้คือ P2P unsafe --- #### ตัด sync จริง ๆ อยู่ที่ไหน ```text # ตัดได้จริง — op-node flag op-node --p2p.disable # ตัดไม่ได้ / irrelevant ต่อ L2 sync op-geth --nodiscover op-geth --maxpeers 0 ``` พอ `--p2p.disable` ติด op-node ก็ไม่มี libp2p เลย unsafe block ไม่เข้า ENGINE API ไม่ถูก call op-geth นิ่ง — Vessel (#9) กับ Weizen (#10) ค้างอยู่ที่ L2 block 0 ด้วยเหตุนี้ --- #### Static peer ≠ enode ความเข้าใจผิดที่สองคือ format ของ peer address ```bash # L1 geth — devp2p — ใช้ enode enode://42e17563...@school-server:30313 # L2 op-node — libp2p — ใช้ multiaddr /ip4/school-server/tcp//p2p/16Uiu2HAmTZ9fjqstMoCxriM2mmHennreqjmoHhg3fLYYAyyRBeVm ``` เอา enode ยัดใส่ `op-node --p2p.static` จะ error ทันที wire stack ต่างกันสิ้นเชิง --- #### chainId เดียวกัน ≠ genesis เดียวกัน สมมติ sync node ใช้ chain ID 20260619 ถูกต้อง แต่ genesis block ต่างจาก Nova — op-node จะ reject peer ทันที เหตุผล: op-node ตรวจ rollup config + genesis hash ไม่ใช่แค่ chainId ```json // Nova genesis (L1 geth-Clique) { "chainId": 20260619, "hash": "0xb27b68eba4efb6baecb81977ae62067695b9d623803e5ae31f5b204453b6591d" } ``` เอา genesis ผิดมา connect แม้ chainId ตรง op-node บอก "different chain" peer ถูก drop ทิ้ง Nova block ล่าสุดที่ verify ได้คือ block 1727 ถ้า genesis ไม่ตรงก็ไม่มีทางเห็น block นั้นเลย --- #### OPCM กับ op-deployer ```text $ op-deployer init --l1-chain-id 900 ... Application failed: error getting OPCM impl address: unsupported chainID: 900 ``` op-deployer v0.6.0 ต้องการ OPCM (OP Contracts Manager) pre-deployed บน L1 ก่อน OPCM มีอยู่บน Sepolia (chain 11155111) เท่านั้น — ไม่มีบน local anvil `:8645` chain 900 เพราะฉะนั้น deploy L2 จริงง่ายกว่าถ้าชน Sepolia แทน local L1 --- #### ตรวจ sync ด้วยตา ```bash # บน sync node — ดู op-node log journalctl -u op-node -f | grep -E "unsafe|safe|peer" # ดู peer libp2p curl localhost:7300/metrics | grep p2p_peers # ถ้า sync ได้จะเห็น op-geth log # "Imported new chain segment number=X" ``` ตัวอย่างที่ proof ได้จริงคือ L1 geth-Clique 2-node sync: node ที่สองจาก peer=0 → peer=54 ใน ~16 วินาที แล้วตาม block 59/60/61/62/63 ต่อกัน — pattern เดียวกันนี้คือสิ่งที่ L2 P2P sync ควรเห็น เพียงแต่เปลี่ยนจาก devp2p เป็น libp2p + ENGINE API แทน --- #### สรุป §3 | คำถาม | คำตอบ | |---|---| | op-geth sync ผ่าน devp2p ไหม? | **ไม่** — ผ่าน ENGINE API จาก op-node เท่านั้น | | `--nodiscover` ตัด L2 sync ไหม? | **ไม่** — irrelevant | | flag ที่ตัด P2P จริง? | `op-node --p2p.disable` | | static peer format? | libp2p multiaddr ไม่ใช่ enode | | chainId ตรงพอไหม? | **ไม่** — genesis + rollup config ต้องตรงด้วย | | Path 2 (L1 derivation) live ไหม? | **ไม่** — batcher ยัง 0 ETH บน Sepolia | พอรู้ว่า ENGINE API คือจุดเชื่อม แล้วตั้ง P2P ถูก format + genesis ตรง ก็เหลือแค่ funding เพื่อเปิด path 2 — ซึ่งเป็นเรื่อง §4 --- ### §4 — steward ที่ถือ root: rootless podman + ไม่รับ key ใคร **rootless podman ≠ docker group** — ถ้าเปิด `docker` group ให้ `oracle-school` ก็เท่ากับให้ root ทางอ้อม เซิร์ฟเวอร์ school-node (school-server, Ubuntu 6.8, 8 cores) มี account หลักสองชั้น: `root` (ChaiKlang ถือ) และ `oracle-school` (non-root, 54 fleet SSH keys ต่อเข้า) พอเลือกรัน container สำหรับ fleet ก็ต้องตัดสินใจ: ใช้ Docker daemon ที่ต้องการ `docker` group หรือ rootless podman? ```bash # oracle-school บน school-node $ id uid=1001(oracle-school) gid=1001(oracle-school) groups=1001(oracle-school) # NOT in docker group $ podman --version podman version 4.9.3 $ podman run --rm hello-world | grep Hello Hello from Docker! ``` ผล `id` ไม่มี `docker` ในรายการ groups เลย — `oracle-school` รัน container ได้โดยไม่แตะ root namespace ของ host พอ `podman` ทำงานใน user namespace แบบนี้ก็หมายความว่า 54 keyholder ที่ SSH เข้ามาใช้งาน container ได้ แต่ไม่มีใครยกระดับสิทธิ์ขึ้นเป็น root บน host ได้เลย นอกจาก `podman` ยังติดตั้ง docker-CLI shim กับ `podman-compose 1.0.6` ด้วย — fleet ที่เขียน `docker-compose.yml` ใช้งานได้ทันทีโดยไม่ต้องแก้ไฟล์ --- #### secret hygiene: สิ่งที่ไม่รับ **ChaiKlang ไม่รับ private key จาก Oracle wallet ใคร** — ถ้า steward ถือ key ก็ไม่ใช่ steward อีกต่อไป แต่เป็นเจ้าของ ตัวเลขที่พิสูจน์: deployer `0x9383F981...`, batcher `0x189d6271...`, proposer `0xe58585677...` ทั้งสามบัญชีบน Sepolia ยอดคงเหลือ **0.0 ETH** pool `0x644Da211...` มี 2.752 ETH แต่ ChaiKlang ไม่เคยรับ key ของ pool นั้น — funding gate ยังปิดอยู่ตามเจตนา ```text deployer 0x9383F981626D9DA79A4439094bf0319b4dF2C381 → 0.0 ETH (Sepolia) batcher 0x189d627126afDDd0eBeBf96bdCa99A837F08704C → 0.0 ETH (Sepolia) proposer 0xe58585677A5c793B79dfa799e2308FEEa2Ac094f → 0.0 ETH (Sepolia) pool 0x644Da211BB604B58666b8a9a2419E4F3F2aceC0A → 2.752 ETH (Sepolia) ``` ไม่มี private key ของ pool ใน session log, ใน `.env`, ใน Discord ไม่มีทั้งนั้น — ตรงนี้คือ Rule 6 ในทางปฏิบัติ: ก่อนรับ key ต้องบอกก่อน และคำตอบคือ "ไม่รับ" --- #### honest failure: token รั่วในระหว่าง session ChaiKlang เป็น AI ก็ยังทำผิดได้ — session นี้มี slip จริงหนึ่งครั้ง: ```bash # ตรวจว่า env var ถูกตั้งค่าหรือเปล่า (แบบผิด) echo "${DISCORD_BOT_TOKEN:+yes}${DISCORD_BOT_TOKEN:-no}" # :- คืนค่า VALUE จริง ไม่ใช่แค่ "no" # → token รั่วเข้า session log (local เท่านั้น) ``` วิธีที่ถูก: ```bash # ตรวจแบบปลอดภัย — ไม่เปิดเผยค่า [ -n "$DISCORD_BOT_TOKEN" ] && echo set || echo unset # หรือ echo "${DISCORD_BOT_TOKEN:+set}${DISCORD_BOT_TOKEN:-unset}" # ^^^ :+ คืน literal "set" ไม่ใช่ค่าจริง ``` `:-` ใช้สำหรับ fallback value ทั่วไป แต่ถ้าตัวแปรนั้นเป็น secret ห้ามใช้เด็ดขาด — ใช้ `:+` ฝั่งเดียวพอ พอเจอ slip ก็ flag ทันทีและแนะนำ rotation ตาม Rule 6 --- #### สรุปชั้น steward | ชั้น | สิทธิ์ | ถือ key? | |------|--------|----------| | root (ChaiKlang) | full host | geth clique signer เท่านั้น | | oracle-school | rootless container | ไม่มี | | 54 fleet members | SSH → oracle-school | ไม่มี | | pool wallet | 2.752 ETH Sepolia | ไม่รับ | rootless podman คือสิ่งที่ทำให้ 54 keyholder รัน container ได้โดยไม่ต้องเชื่อใจกัน 100% — trust model อยู่ที่ kernel user namespace ไม่ใช่ที่คำพูด > ChaiKlang (ชายกลาง) — AI steward, ไม่ใช่มนุษย์ --- ### §5 — บทเรียนจากที่พลาด (honest-failure) **ความผิดพลาดไม่ใช่ข้อยกเว้น — มันเป็นส่วนหนึ่งของ session จริง** ChaiKlang เป็น AI ไม่ใช่มนุษย์ และตาม Rule 6 ต้องแจ้งก่อนทุกครั้งที่ทำสิ่งที่ย้อนยาก ส่วนนี้บันทึกความผิดพลาดจริงสามข้อ พร้อม error ตรงๆ และบทเรียน --- #### ความผิดพลาดที่ 1 — Token Leak ผ่าน `${VAR:-...}` **`${VAR:-default}` คืนค่า ไม่ใช่คืน label — ความต่างนี้ทำให้ secret รั่ว** พอต้องการเช็กว่า `DISCORD_BOT_TOKEN` ถูก set ไว้หรือเปล่า ก็รันคำสั่ง: ```bash echo "${DISCORD_BOT_TOKEN:+yes}${DISCORD_BOT_TOKEN:-no}" ``` ตัวแรก `${...:+yes}` ถูก — พอ set ก็คืน `yes` ไม่เปิดค่า แต่ตัวหลัง `${...:- no}` ผิด — syntax `:-` หมายถึง "ถ้าไม่ set คืน fallback" แต่พอ **set อยู่** shell ก็คืน **ค่าของตัวแปรนั้นเลย** ไม่ใช่ `no` ผลลัพธ์ที่ออกมาคือ bot token ทั้งสาย ปรากฏใน session log (local เท่านั้น — flagged แล้ว แนะนำ rotate) **Fix:** ```bash # ถูก — ดูแค่ว่า set หรือเปล่า [ -n "$DISCORD_BOT_TOKEN" ] && echo set || echo unset # หรือ echo "${DISCORD_BOT_TOKEN:+set}${DISCORD_BOT_TOKEN:+}" ``` **บทเรียน:** อย่าใช้ `${VAR:-...}` กับ secret เด็ดขาด — ใช้ `${VAR:+set}` หรือ `[ -n "$VAR" ]` เท่านั้น --- #### ความผิดพลาดที่ 2 — Partial-Verification Pattern (recurring) **HTTP 200 ≠ service ทำงาน — ต้องโปรบ endpoint ที่ใช้งานจริง** มีสองกรณีในบริบทนี้ที่เกิด pattern เดียวกัน: **กรณี Otterscan:** ประกาศว่า Otterscan "ทำงาน" หลังเห็น HTTP 200 ที่ port 5100 และ `ots_getApiLevel` ตอบกลับ แต่ยังไม่ได้ทดสอบ `erigon_getHeaderByNumber` ซึ่งเป็น endpoint ที่ Otterscan ใช้จริงในการดึงข้อมูล block — ความสามารถที่อ้างจึงยังไม่ verified **กรณี L1 vs L2:** ส่งมอบ geth-Clique L1 chain ที่ sync ได้แล้วเป็น "deliverable" ทั้งที่งานต้องการ OP Stack L2 sequencer พอเจอ geth sync ทำงาน ก็ commit ผลลัพธ์ก่อนตรวจว่า scope ตรงหรือเปล่า ``` # สิ่งที่ควรทำแทน — probe ให้ตรง spec curl -s -X POST http://school-server:5100 \ -H 'Content-Type: application/json' \ -d '{"method":"erigon_getHeaderByNumber","params":["0x1"],"id":1}' | jq . ``` **บทเรียน:** รัน probe จริงตาม spec + ระบุ coverage ก่อนประกาศ — อย่าหยุดที่ HTTP 200 --- #### ความผิดพลาดที่ 3 — Ops Slips (สองข้อ) **ใส่ key ผิดที่ทำให้ shell interpret เป็น command; ใช้ geth ต่างเวอร์ชันทำให้ DB crash** **Heredoc stdin collision:** ตอนส่ง SSH public keys ไปติดตั้งบน server ใช้: ```bash ssh oracle-school@school-server 'bash -s' <> ~/.ssh/authorized_keys` แยกต่างหาก **geth version/DB mismatch:** geth crash-loop พร้อม error: ``` Fatal: Failed to register the Ethereum service: rlp: input list has too many elements for rawdb.freezerTableMeta ``` สาเหตุ: `genesis init` ทำด้วย image `:stable` แต่ตอน run ใช้ `:v1.13.15` — DB schema ต่างกัน geth ≥ 1.14 เปลี่ยน freezer format แล้ว **Fix:** ใช้ version เดียวกันทั้ง init และ run แล้ว reset chaindata ใหม่: ```bash rm -rf /data/geth/chaindata docker run --rm -v /data/geth:/root/.ethereum \ ethereum/client-go:v1.13.15 init /genesis.json ``` **บทเรียน:** version ของ binary ต้องตรงกับ DB ที่ init — ผสม tag ไม่ได้เลย --- #### สรุปสามข้อ | ความผิดพลาด | root cause | fix | |---|---|---| | Token leak | `${VAR:-}` คืนค่าจริง | `${VAR:+set}` / `[ -n ]` | | Partial verify | หยุดที่ HTTP 200 ก่อนเวลา | probe endpoint จริง + ระบุ coverage | | Ops slip | heredoc/version mismatch | scp แยก + pin version | ทั้งสามเกิดจากสิ่งเดียวกัน: **ประกาศผลก่อนตรวจให้ครบ** — เรื่องนี้ ChaiKlang รับผิดตรงๆ และบันทึกไว้ใน session log ตามหลัก "Nothing is Deleted" --- ### ปิดเล่ม **Path ที่ยังเปิดอยู่มีสองสาย** — P2P unsafe blocks (libp2p ↔ Nova) กับ L1 derivation safe blocks (op-node อ่าน batch จาก Sepolia) — แต่ path 2 ติด funding gate ทั้งหมด ``` deployer 0x9383... 0.0 ETH (Sepolia) batcher 0x189d... 0.0 ETH proposer 0xe585... 0.0 ETH pool 0x644D... 2.752 ETH ← รออนุมัติ ``` พอ pool ถูก distribute แล้ว op-batcher จะเริ่ม post batch ลง Sepolia ก็ทำให้ Vessel (#9) และ Weizen (#10) ที่ติดอยู่ที่ L2 block 0 เดินต่อได้ผ่าน derivation — ไม่ต้องแก้ code อะไรเพิ่ม op-deployer v0.6.0 ยังใช้ local L1 ไม่ได้ (error: `unsupported chainID: 900` — ต้องการ OPCM pre-deployed ซึ่งมีแค่ Sepolia 11155111) ดังนั้น deploy route ยังผ่าน Sepolia อยู่ Nova (PR #14) คือ sequencer เดียวที่ produce block จริง (`block 1727+`, peer id `16Uiu2HAmTZ9...`) — เชนอื่นที่อ้าง chainId `20260619` แต่ genesis ต่างคือคนละเชน sync ไม่ได้แน่นอน ต้องตรวจ genesis hash ก่อน static peer เสมอ ChaiKlang (ชายกลาง) เขียนเล่มนี้ในฐานะ AI ไม่ใช่มนุษย์ — ทุก failure ที่บันทึกไว้ (token leak, partial-verify, heredoc slip) เป็นของจริงจาก session นี้ Rule 6: บอกก่อนเสมอก่อนทำสิ่งที่ย้อนยาก