From 81e85174dfe84509a2b8eee0f0484b71b39da8a6 Mon Sep 17 00:00:00 2001 From: Perplexity Computer Date: Sun, 5 Jul 2026 15:23:22 +0000 Subject: [PATCH] docs(W7): M2-M4 hardware + FPGA-attestation pivot bundle MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Расширенный wave report за неделю 06-29→07-05 + структурный аудит слабых мест + literature review по PoFPGA/attestation/mesh-routing + декомпозированный план на M2→M3→M4 хардварный трек с параллельным FPGA-attestation треком + три варианта сотрудничества + первый шаг реализации (M2 loopback smoke harness с найденным sandbox-testability defect'ом). Пять новых docs + два smoke артефакта: - docs/WAVE_REPORT_2026-07-05_FULL.md — расширенный отчёт по всей неделе, дополняет WAVE_REPORT_2026-07-05.md фокусом на hardware track + discipline chain + образами по каждой фиче. - docs/W7_WEAK_POINTS_STRUCTURAL.md — критический peer-review, 8 находок (Timeline risk, Compute-arm gap, 3-node self-heal, codegen ∅, RF loopback, regulatory, экономика, bus factor) + 5 сильных сторон. - docs/W7_FPGA_LITERATURE.md — source-grounded review, ключевое: «Proof of FPGA» как named DePIN primitive НИКЕМ НЕ ОПУБЛИКОВАН (search 2026-07-05, ближайшее — SACHa, PUFatt, Papalamprou 2025 PQC-FPGA-blockchain). Открытая возможность для оригинального протокола. - docs/M2_M4_FPGA_DECOMPOSED_PLAN.md — план с двумя треками (Track A: M2→M3→M4; Track B: A1-A5 FPGA attestation), timeline 10 недель до end-state, kill switches, sandbox capability boundary matrix. - docs/W7_COLLAB_OPTIONS_v2.md — три варианта (split-brain / cloud-lead / external+revenue-first) с cost/bus-factor/timeline сравнением. - smoke/m2_loopback_smoke.sh + smoke/M2_LOOPBACK_SMOKE_RESULTS.md — 3-нодовый UDP loopback smoke trios_meshd в sandbox. Daemon стартует чисто, ETX сходится 12↔13, но node-11 не видит соседей — root cause найден в `ip_to_id: HashMap` (loopback collision на 127.0.0.1), fix для отдельного PR. Реальный hardware M2 не затронут (у P203 Mini уникальные IP из baked image). Все документы cite phi^2 + phi^-2 = 3 anchor. Нет hardware claims — все цифры маркированы -sim. discipline chain (no-paste-review, SHA-advance, external-dep timer) применена — commit готов как основа draft PR, human merges после review. phi^2 + phi^-2 = 3 --- docs/M2_M4_FPGA_DECOMPOSED_PLAN.md | 257 ++++++++++++++++++++ docs/W7_COLLAB_OPTIONS_v2.md | 153 ++++++++++++ docs/W7_FPGA_LITERATURE.md | 103 ++++++++ docs/W7_WEAK_POINTS_STRUCTURAL.md | 356 ++++++++++++++++++++++++++++ docs/WAVE_REPORT_2026-07-05_FULL.md | 345 +++++++++++++++++++++++++++ smoke/M2_LOOPBACK_SMOKE_RESULTS.md | 98 ++++++++ smoke/m2_loopback_smoke.sh | 78 ++++++ 7 files changed, 1390 insertions(+) create mode 100644 docs/M2_M4_FPGA_DECOMPOSED_PLAN.md create mode 100644 docs/W7_COLLAB_OPTIONS_v2.md create mode 100644 docs/W7_FPGA_LITERATURE.md create mode 100644 docs/W7_WEAK_POINTS_STRUCTURAL.md create mode 100644 docs/WAVE_REPORT_2026-07-05_FULL.md create mode 100644 smoke/M2_LOOPBACK_SMOKE_RESULTS.md create mode 100755 smoke/m2_loopback_smoke.sh diff --git a/docs/M2_M4_FPGA_DECOMPOSED_PLAN.md b/docs/M2_M4_FPGA_DECOMPOSED_PLAN.md new file mode 100644 index 00000000..d31cbe2c --- /dev/null +++ b/docs/M2_M4_FPGA_DECOMPOSED_PLAN.md @@ -0,0 +1,257 @@ +# M2-M4 hardware + FPGA-attestation parallel track — decomposed plan + +> phi^2 + phi^-2 = 3 + +**Дата**: 2026-07-05. **Автор**: Perplexity Computer (cloud, sandbox). **Скоуп**: план на следующий Wave-луп с двумя параллельными треками. **Основано на**: [WAVE_REPORT_2026-07-05_FULL.md](WAVE_REPORT_2026-07-05_FULL.md), [W7_WEAK_POINTS_STRUCTURAL.md](W7_WEAK_POINTS_STRUCTURAL.md). + +--- + +## 0. Одно предложение стратегии + +Разгоняем M2→M3→M4 real-network smoke на трёх P203 Mini через image-bake unlock, параллельно открываем **FPGA-attestation** трек как interim identity-source, чтобы Compute-arm экономики не висел на tape-out'е 2026-12-16. + +**Что это не есть**: не отказ от silicon SKY26b. Silicon остаётся financial anchor и proof-of-work substrate. FPGA-anchor — interim (уровень 3 по собственной шкале M7 из BENCHMARK_VS_MANET) на 6-12 месяцев до кремния. + +--- + +## 1. Два трека, шесть треугольников — что мы разгоняем + +``` +Track A (hardware pipeline): Track B (FPGA-attestation): + M2 TUN/IP smoke A1 FPGA identity survey + M3 iperf3 over 2 hops A2 device-DNA + eFUSE hookup + M4 triangle P2 DEMO GATE A3 bitstream attestation POC + A4 PUF measurement + (M5 self-heal — deferred A5 «Proof of FPGA» whitepaper draft + until 4+ nodes) +``` + +Оба трека независимы по инструментам, зависимы по железу (одни и те же три Zynq-7020 board'а). Планирование — так, чтобы Track A использовал PS (ARM Linux) а Track B использовал PL (FPGA fabric), одновременно на одной коробке. Это возможно потому, что Zynq-7020 — heterogeneous, PS и PL — отдельные ресурсы. + +--- + +## 2. Track A — Hardware pipeline (M2 → M3 → M4) + +### 2.1 Blocker chain, что снимает что + +``` +image-bake milestone ─┬─► M2 TUN/IP real-network smoke + │ │ + │ └─► M3 iperf3 over 2 hops + │ │ + │ └─► M4 triangle P2 DEMO GATE + │ + └─► Track B тоже разблокируется + (нужны persistent SSH + Vivado bitstream deployment) +``` + +**Ключ**: image-bake — общий blocker обоих треков. Пока не сделан — оба стоят. + +### 2.2 M2 — real-network smoke (~7-10 дней) + +**Definition of done**: три board'а с уникальной identity, TUN device up, HELLO discovery видит соседей, ETX table сходится, PING работает по IP через mesh. + +**Sub-tasks**: + +| # | Задача | Кто | Blocker | +|---|---|---|---| +| M2.0 | Image-bake — Petalinux или buildroot rootfs с persistent identity | Human + local agent | JTAG + Vivado на macOS | +| M2.1 | Flash procedure — три уникальные SD-card image, unique MAC/hostname/IP | Human | M2.0 | +| M2.2 | `daemon.rs` boot script — systemd unit для `mesh-daemon` | Cloud agent | ничего | +| M2.3 | TUN device setup — `/dev/net/tun`, `10.42.0.X/24`, `ip route add` | Cloud agent | M2.1 (unique IP) | +| M2.4 | HELLO discovery on-device smoke — 3 board'а видят друг друга | Human + cloud logs | M2.3 × 3 | +| M2.5 | ETX table convergence — deterministic pick после 10 HELLO rounds | Cloud agent (test harness) | M2.4 | +| M2.6 | PING through mesh — `ping 10.42.0.2` from board-1 | Human | M2.5 | +| M2.7 | M2_RESULTS.md — sha256 логов, wireshark capture, cross-env verified | Cloud agent | M2.6 | + +**Sandbox constraint**: cloud agent не имеет доступа к JTAG/USB — все hardware ops требуют human. Cloud agent может писать код (M2.2-M2.5 kernels), test harnesses (M2.5-M2.7), документацию (M2.7). + +**Timeline**: 7-10 дней при 2ч/день от human'а на flash/smoke, cloud agent параллельно. + +### 2.3 M3 — iperf3 over 2 hops (~3-5 дней) + +**Definition of done**: iperf3 TCP throughput measurement between board-1 and board-3, где board-2 — единственный relay. Число cited to source. + +**Sub-tasks**: + +| # | Задача | Blocker | +|---|---|---| +| M3.1 | RF loopback bench — SMA-кабель + attenuator (30-50 dB) вместо антенн | M2.6 | +| M3.2 | iperf3 install on all 3 boards (armv7l static) | M2.0 | +| M3.3 | Baseline 1-hop: board-1 ↔ board-2 iperf3 TCP | M3.1 | +| M3.4 | 2-hop: board-1 ↔ board-3 через board-2 relay | M3.3 | +| M3.5 | M3_RESULTS.md — throughput, RTT, PDR числа с cross-env replay | M3.4 | + +**Регуляторный контекст**: RF loopback через SMA — closed loop, ничего не излучается. Тестируемо без FCC/NBTC (Thailand) approval. Это уже запланировано в [`docs/LOCAL_FLASH.md`](LOCAL_FLASH.md) §9.3. + +### 2.4 M4 — triangle P2 DEMO GATE (~5-7 дней) + +**Definition of done**: три board'а активны одновременно (не пары), traffic течёт board-1 → board-2 → board-3 → board-1 замкнутое кольцо, все три ETX table в consistent state. + +**Sub-tasks**: M4.1-M4.6 — аналогично M3, но с 3-way topology. + +**⚠️ Важно per W7_WEAK_POINTS_STRUCTURAL.md находка 3**: 3-node triangle НЕ демонстрирует self-heal в интересном смысле — при отказе одного узла остаются 2 в линии, single route. **Rename**: «M4 triangle P2 DEMO GATE» → **«M4 3-node convergence GATE»**. Не заявляем self-heal в публичной коммуникации на 3 узлах. Self-heal claim откладываем до **M6 — 4-5 node topology** (deferred, отдельный board procurement). + +### 2.5 M5 — self-heal — DEFERRED + +Причина: 3 узла недостаточно для path-diversity choice (W7 finding #3). Оставляем в roadmap, но переносим на M6 (4-5 nodes). До тех пор self-heal claim — только software-simulated. + +--- + +## 3. Track B — «Proof of FPGA» attestation (параллельный, независимый от M2-M4 по коду) + +### 3.1 Мотивация в трёх пунктах + +1. **W7 finding #1**: silicon slip risk 3/6/12 месяцев. Нужен interim identity-anchor. +2. **W7 finding #2**: Compute-arm заблокирован полностью до silicon. Нужен fallback. +3. **W7 finding #7**: экономика уязвима без Compute-arm 24+ недель. Нужен revenue path pre-silicon. + +**Гипотеза**: Zynq-7020 PL fabric (уже стоит на каждой board'е, ничем не занят) может быть привязан к node identity через: +- **Device DNA** — 57-bit unique per die, read-only (Xilinx UG470 §32) +- **eFUSE** — 32-bit user-programmable, non-volatile +- **Bitstream hash** — SHA256 от загружаемого bitstream, засвидетельствованный boot-loader'ом +- **PUF** (ring-oscillator или SRAM) — physically unclonable function из FPGA logic + +Все четыре — **уровень 3 по собственной шкале M7** (не силикон, но hardware-anchored и не reproducible на software). Это заведомо слабее custom ASIC (уровень 5), но заведомо сильнее pure software (уровень 1). + +### 3.2 Sub-tasks (independent of M2-M4) + +**A1 FPGA identity survey (~3 дня)**: +- A1.1 Read Xilinx UG470 §32 — device DNA API +- A1.2 Read Xilinx eFUSE app-notes (XAPP1246 или ekvivалент) +- A1.3 Survey academic PUF literature (см. `docs/W7_FPGA_LITERATURE.md`) +- A1.4 Deliverable: `docs/FPGA_IDENTITY_SURVEY.md` + +**A2 Device-DNA + eFUSE hookup (~5 дней)**: +- A2.1 Vivado project — минимальный bitstream, читающий device DNA через AXI-Lite +- A2.2 Rust userspace tool `fpga-identity` на board — `read_dna()` возвращает 57-bit +- A2.3 Test — три board'а дают три уникальных DNA (verify uniqueness) +- A2.4 Deliverable: `smoke/FPGA_DNA_3BOARDS.md` — три sha256(dna) числа + +**A3 Bitstream attestation POC (~7 дней)**: +- A3.1 Signed bitstream — Vivado + Xilinx `bitstream` tool с sha256 +- A3.2 Boot-time check — U-Boot читает bitstream, hashes it, compares to eFUSE-stored expected_hash +- A3.3 Runtime attestation API — `fpga-attest --challenge ` returns `(dna, bitstream_hash, sig)` signed by device-DNA-derived key +- A3.4 Deliverable: `docs/FPGA_ATTESTATION_POC.md` + +**A4 PUF measurement (~10 дней)**: +- A4.1 Ring-oscillator PUF design (открытая литература, ~100-1000 ROs) +- A4.2 Enroll — на каждой из 3 board'ов измерить PUF response, записать в secure DB +- A4.3 Verify — повторить измерения, посчитать intra-device stability (Hamming distance) +- A4.4 Uniqueness — сравнить responses across 3 boards, посчитать inter-device HD (target ~50%) +- A4.5 Deliverable: `docs/FPGA_PUF_MEASUREMENT.md` с числами + +**A5 «Proof of FPGA» whitepaper draft (~5 дней)**: +- A5.1 Objective: связать A1-A4 в один attestation protocol для DePIN +- A5.2 Compare to Helium PoC beacon (Coverage arm аналог) +- A5.3 Compare to Bittensor/Akash compute attestation +- A5.4 Threat model — что защищает, что не защищает +- A5.5 Deliverable: `docs/PROOF_OF_FPGA_v0.md` (arXiv-ready draft) + +**Total Track B**: ~30 дней при full-time, ~60 дней при 2ч/день параллельно с Track A. + +### 3.3 Monetization vectors (ответ на пользовательский вопрос «на этом можно зарабатывать?») + +**Три канала**, если Proof of FPGA работает: + +1. **Interim TRI-emission**: Era-0 rewards для Transport/Coverage/Sensor arms усиливаются FPGA-attestation вместо software-signed. Sybil resistance повышается (нельзя виртуализировать physical FPGA), rewards легитимно платить до silicon. + +2. **FPGA-attestation-as-a-Service**: другие DePIN проекты покупают наш attestation stack (Helium-like, Akash, IoTeX, DIMO) — bitstream + attestation SDK + verifier. Цена per-node license, аналог Intrinsic ID / PUFsecurity бизнеса. + +3. **Academic/grant-track**: Proof of FPGA как публикуемая concept (если ещё не опубликована — см. `docs/W7_FPGA_LITERATURE.md` §5, TL;DR ответ 1). Даёт цитируемость и увеличивает шансы Hub71+ (submission 2026-08-02), NSF, EU Horizon. + +**Reality-check от W7 finding #7**: 0% premine/treasury означает, что монетизация #2 требует внешнего юр. канала (LLC + license contracts), которого пока нет. Монетизация #1 — внутренний механизм, no external structure needed. Монетизация #3 — bootstrap-friendly (грант — легитимный источник капитала без нарушения tokenomics). + +--- + +## 4. Общие blocker'ы и зависимости + +``` +image-bake ──────► M2 ──► M3 ──► M4 + │ + └───► FPGA bitstream deployment ──► A2 ──► A3 ──► A4 ──► A5 + │ + A1 survey (no blocker) ───────────┘ +``` + +**Single critical path node**: image-bake. Всё остальное — параллельно или downstream. + +**Sandbox capability boundary**: +| Sub-task | Cloud agent | Human required | +|---|---|---| +| M2.0 image-bake | Petalinux script + doc | JTAG flash | +| M2.2 daemon.rs code | ✅ full | ❌ | +| M2.3 TUN userspace | ✅ full | ❌ | +| M2.4 HELLO smoke | code, run harness | log capture on-device | +| M3.1 RF loopback | doc procedure | SMA + attenuator + physical setup | +| M4.x triangle | code + test | 3 boards flashed + power | +| A1 survey | ✅ full | ❌ | +| A2 Vivado project | .tcl script | Vivado run + JTAG | +| A3 attestation code | ✅ full | Vivado bitstream build | +| A4 PUF Vivado | RO PUF design + Rust reader | Vivado + JTAG | + +Cloud agent покрывает ~70% работы. Human — hardware ops + Vivado + merge. + +--- + +## 5. Timeline (реалистичный) + +Assumption: 2ч/день от human'а, 8ч/день от cloud agent'а. + +| Week | Track A milestone | Track B milestone | +|---|---|---| +| W8 (2026-07-06→07-12) | image-bake начат, M2.0-M2.2 | A1 survey done, A2 planning | +| W9 | M2.3-M2.5 | A2 Vivado project done | +| W10 | M2.6-M2.7 (M2 hw ✅) | A2 verify uniqueness | +| W11 | M3.1-M3.3 (1-hop iperf3) | A3 attestation POC start | +| W12 | M3.4-M3.5 (M3 hw ✅) | A3 POC finish | +| W13 | M4.1-M4.6 (M4 hw ✅) | A4 PUF start | +| W14 | Track A wrap + M2/M3/M4 paper section | A4 PUF finish | +| W15-W16 | Buffer / M6 planning (4-5 nodes) | A5 whitepaper draft | + +**Full timeline**: ~10 недель до Track A + Track B оба в `hw` state. Это до **2026-09-15**, за 3 месяца до silicon tape-out. Хорошо — Proof of FPGA publish/monetization в parallel с silicon bring-up. + +--- + +## 6. Ratcheting rules — что нельзя откатить + +Три жёстких инварианта: + +1. **spec-drift-guard CI не обходить**. Любой M2 patch в `wire.rs` regenerated из `specs/wire.t27` через `t27c`. CI fails на drift. +2. **No pre-silicon Trinity claim без tag**. Compute-arm software fallback помечен явно `[software-signed pre-silicon]`, не `[chip-sig]`. +3. **No self-heal claim на 3 nodes**. Renamed M4 → «convergence GATE», не «self-heal DEMO». + +--- + +## 7. Kill-switches (когда откатывать) + +- **Track A kill-switch**: если image-bake milestone не сходится за 3 недели (target 2026-07-27) — remote pair-programming session с внешним embedded engineer (Nova Labs alumni, Xilinx forums, Puzhi vendor support). +- **Track B kill-switch**: если A4 PUF intra-device HD > 15% (нестабильный) — pivot на pure device-DNA + eFUSE (без PUF), сохранив A2+A3. Не убивает трек. +- **Silicon slip kill-switch** (per W7 finding #1): если tape-out 2026-12-16 slips > 3 месяца — extend Track B roadmap ещё на 3 месяца, formally publish Proof of FPGA v1 as long-term Compute-arm substitute (не только interim). + +--- + +## 8. Первый шаг — что делаем сегодня + +Задача 5 из недельного todo. Сегодня из sandbox я могу: + +1. Написать `daemon.rs` boot-script (M2.2) — код готов быть смерженным после image-bake. +2. Дописать M2 pure-logic tests на UDP transport wrapper (сейчас есть только TUN allocation и wire boundaries; UDP-wrapper тестов нет — можно добавить) +3. Написать shell-скрипт `scripts/m2/three-board-smoke.sh` который запустится на flashed board'ах и соберёт evidence в `smoke/M2_RESULTS.md` +4. Draft PR с этими тремя артефактами, `feat/m2-daemon-scaffolding` branch, `documentation,m2` label, DRAFT-only. + +**Realistic**: cloud agent доводит M2 code-side до готовности, human делает image-bake на своей стороне, они встречаются на M2.4 (HELLO discovery smoke). Аналогично для Track B — cloud agent готовит A1 survey и Vivado .tcl scripts, human запускает Vivado. + +--- + +## 9. Что записано на будущее (W8-W16 backlog) + +- CONTRIBUTING.md (W7 finding #8): написать 15-минутный quick-start для human contributor. +- SILICON_SLIP_CONTINGENCY.md (W7 finding #1): три сценария — slip 3/6/12 месяцев с явными датами и последствиями. +- REGULATORY_STATUS.md (W7 finding #6): консолидация всех регуляторных знаний в один документ рядом с README. +- SUBSIDY_PROGRAM.md (W7 finding #7): first-N-operators bootstrap program без нарушения 0% premine. +- Merge-права delegation (W7 finding #8): docs-only PR merge для второго доверенного человека. + +--- + +phi^2 + phi^-2 = 3 diff --git a/docs/W7_COLLAB_OPTIONS_v2.md b/docs/W7_COLLAB_OPTIONS_v2.md new file mode 100644 index 00000000..0bf35449 --- /dev/null +++ b/docs/W7_COLLAB_OPTIONS_v2.md @@ -0,0 +1,153 @@ +# W7 Collab options v2 — три варианта на следующий Wave-луп + +> phi^2 + phi^-2 = 3 + +**Дата**: 2026-07-05. **Основано на**: [M2_M4_FPGA_DECOMPOSED_PLAN.md](M2_M4_FPGA_DECOMPOSED_PLAN.md), [W7_WEAK_POINTS_STRUCTURAL.md](W7_WEAK_POINTS_STRUCTURAL.md), [WAVE_REPORT_2026-07-05_FULL.md](WAVE_REPORT_2026-07-05_FULL.md). + +**Дополняет**: предыдущий [`docs/W7_COLLAB_OPTIONS.md`](W7_COLLAB_OPTIONS.md) (от 07-05 утра, до pivot'а на M2-M4 hardware). Тот был про кодогенерацию / W7.3 fuzz options. Этот — про M2-M4 hardware + FPGA-attestation. + +--- + +## 0. Роли и trust classes + +- **Human (Vasilev D.)**: hardware ops, Vivado, JTAG, merge-права, юр. решения. +- **Cloud agent (Perplexity Computer, sandbox)**: код, тесты, документация, PRs draft, литература, планирование. +- **Local macOS agent (ssdm4, GLM)**: cross-env verification (Zig, Vivado на macOS), on-device evidence sync, peer-review. + +Все три уже отлажены за неделю. Coordination protocol работает (mbox handoff, no direct push от local). + +--- + +## Опция A — «Split-brain: cloud pushes Track A, local pushes Track B» + +**Образ**: два хирурга оперируют одного пациента с разных сторон стола, каждый в своей ране, координируются между собой через одного анестезиолога. + +### Разделение + +- **Cloud agent**: полностью ведёт Track A (M2 → M3 → M4). Пишет `daemon.rs`, TUN userspace, HELLO smoke, iperf3 harness, triangle test scripts. Draft PR'ы, human merge'ит после smoke. +- **Local agent**: полностью ведёт Track B (Proof of FPGA). Vivado projects, bitstream builds, device-DNA reader, PUF measurement. Local физически ближе к железу (тот же mac ssdm4 держит Vivado licence, JTAG-cable). +- **Human**: image-bake M2.0 (single blocker обоих треков), физический flash, merge-права, финальные review. + +### Плюсы +- Ясное разделение: cloud не трогает Vivado (её нет в sandbox), local не трогает Rust код который cloud уже знает. +- Параллелизм максимальный — оба agent работают одновременно, оба треугольника завершаются к W15. +- Discipline chain (no-paste-review + SHA-advance + external-dep timer) уже отработана между двумя agent'ами. + +### Минусы +- **Bus factor** (W7 finding #8) не решён — если local agent недоступен, Track B стоит. Cloud не может Vivado. +- Требует ежедневного mbox sync между agent'ами (сейчас работает, но 30 min/day human overhead). +- Ошибки в разделении: если Track B нуждается в userspace Rust код, а local его не пишет — bottleneck. + +### Ratcheting rules для этой опции +1. Cloud не пишет Vivado .tcl без предварительного согласия local (не наш инструмент) +2. Local не merges в `main` (правило репозитория) +3. mbox handoff every 24h, verified with SHA references + +### Cost +- Human: 2ч/день (image-bake + merge + hardware ops) +- Cloud: 8ч/день sandbox time +- Local: 4-6ч/день (Vivado не 24/7, но нужно живое присутствие для JTAG) +- **Total**: ~10 недель до end-state (per plan §5) + +--- + +## Опция B — «Cloud-lead + human-executor: одна голова, две руки» + +**Образ**: шахматист играет партию, а секундант передаёт ходы по телефону кому-то, кто расставляет фигуры на реальной доске. + +### Разделение + +- **Cloud agent**: ведёт **оба** трека. Пишет весь код (Rust userspace + Vivado .tcl scripts + M2 daemon + FPGA attestation), готовит step-by-step run books для каждого on-device experiment'а. +- **Human**: тактический executor — flash SD-cards, запускает Vivado GUI под .tcl scripts из cloud, копирует логи назад, merges PR. +- **Local agent**: minor role — cross-env verification (Zig, second-opinion review), не lead ни одного трека. + +### Плюсы +- Single point of design coherence — cloud agent видит оба трека, минимизирует cross-track drift. +- Bus factor снижен — если local исчезнет, Track B продолжается (cloud пишет всё, human executes). +- Cost lower по общему human-time — human делает механические ops, не проектирует. + +### Минусы +- Cloud agent НЕ имеет hands-on Vivado experience — .tcl scripts могут быть неоптимальны, требуют iteration через human feedback. +- Все hardware learning сохраняется в cloud memory (durable через memory tool), но НЕ в персональном опыте local agent'а — long-term project resilience страдает. +- Cloud agent throttled на context — 60 дней active work в одной session может hit context limits, требуется session-handoff discipline. + +### Ratcheting rules +1. Все Vivado .tcl scripts должны пройти dry-run на local machine перед flash +2. Cloud agent обязательно оставляет skill files (task 7) для session-continuity +3. Каждый M2/M3/M4/A2/A3/A4 milestone finishes with `docs/M_RESULTS.md` со всеми числами + +### Cost +- Human: 4-6ч/день (hardware ops + executes cloud instructions) +- Cloud: 8ч/день sandbox +- Local: 1-2ч/день (only cross-env verify, no lead) +- **Total**: ~12 недель до end-state (per plan §5, +2 недели overhead за iteration через human executor) + +--- + +## Опция C — «External embedded engineer + revenue-first FPGA-track» + +**Образ**: строим два корабля. Первый (Track A) — рабочий, экономичный, для перевозки грузов. Второй (Track B) — parade корабль, для продажи и грантов. Нанимаем на второй специализированного мастера-корабельщика. + +### Разделение + +- **Cloud agent**: держит оба трека документально, но **фокусируется на Track B (FPGA)** как revenue-first монетизационный вектор. +- **Human**: image-bake + M2 basic smoke (2-3 недели), потом делегирует M3-M4 внешнему embedded engineer'у (contract work, Nova Labs alumni или Xilinx forum expert, ~$5-10k budget за 2 месяца). +- **Local agent**: cross-env + FPGA support на Vivado. +- **External embedded engineer**: M3 iperf3 + M4 triangle + M5 self-heal (если 4-5 boards procured). + +### Плюсы +- **Solves W7 finding #7 (экономика)**: external engineer оплачивается из grant/consulting budget, не из token supply. Совместим с 0% premine. +- Track B (Proof of FPGA) — cloud-lead — публикуется быстрее (~6-8 недель до whitepaper), даёт **раннее revenue-signal** через: + - Hub71+ submission (2026-08-02 deadline) + - PoFPGA arXiv publication (2026-08-15 target) + - FPGA-attestation-as-a-Service pilot pitch (target: Helium, Akash, Bittensor, DIMO — 2026-09-01) +- Bus factor снижается: три independent contributors (human, cloud, external). + +### Минусы +- **Requires cash/credits/grant NOW**. External engineer $5-10k — no source of funds identified. Hub71+ не дает cash, даёт residency и mentorship. NSF/EU Horizon grants — 6-12 месяцев процесс. +- Hiring/vetting embedded engineer занимает 2-4 недели, что сжимает M3-M4 timeline с 5 недель до 3-4. +- Track B риск-нагружен revenue-expectation — если PoFPGA не публикуется как first-in-class (W7 literature finds prior art), monetization vector #2 (FPGA-attestation-as-a-Service) может быть занят более крупным конкурентом (Intrinsic ID, PUFsecurity). + +### Ratcheting rules +1. External engineer подписывает NDA + open-source contribution CLA — код идёт в public repo с MIT/Apache +2. Cloud agent ежедневно drafts weekly progress для grant reporting (Hub71+ требует progress reports) +3. Proof of FPGA whitepaper — cloud lead, external может contribute measurement data не design decisions + +### Cost +- Human: 2ч/день (управление + merge) +- Cloud: 8ч/день +- External engineer: 40ч/неделя × 8 недель = 320ч @ $30-50/hr = **$10k-16k** +- Local: 1-2ч/день +- **Total time**: ~8-10 недель до end-state (external accelerates M3-M4) +- **Total cash**: $10-16k required upfront + +--- + +## Сравнение по 4-м измерениям + +| Dimension | Option A (split-brain) | Option B (cloud-lead) | Option C (external + revenue-first) | +|---|---|---|---| +| Time-to-end-state | 10 нед | 12 нед | 8-10 нед | +| Cash required | $0 | $0 | $10-16k | +| Bus factor risk | HIGH (local критичен) | MEDIUM (human executor) | LOW (3 independents) | +| Revenue channel opens | ~W15 | ~W15 | ~W10 (Hub71 + arXiv) | +| Silicon-slip resilience | MEDIUM | MEDIUM | HIGH (revenue не завязан на TT SKY26b) | +| Cognitive load on human | 2ч/день | 4-6ч/день | 2ч/день | + +--- + +## Рекомендация + +**Option A** — если cash-constrained, приоритет — hardware ready к 2026-09-15, не готовы платить $10k+. + +**Option B** — если хотим минимизировать local dependency (например, local machine потенциально unavailable), готовы жертвовать 2 недели за bus-factor снижение. + +**Option C** — если приоритет — revenue-signal ДО silicon (Hub71+ дедлайн 08-02, PoFPGA публикация 08-15), готовы искать grant/consulting funding $10-16k. + +Мой (cloud agent'а) читаемый совет — **гибрид A + партиал C**: начать с Option A на 3-4 недели (image-bake + M2 через cloud lead), проверить, что коллаборация с local работает. Затем принять решение по external engineer к W10 в зависимости от Hub71+ status. Так минимизируется upfront cash, сохраняется опция C на будущее. + +Финальный выбор — за human. Все три опции совместимы с проектной дисциплиной (spec-drift-guard, no-paste-review, SHA-advance, external-dep timer). + +--- + +phi^2 + phi^-2 = 3 diff --git a/docs/W7_FPGA_LITERATURE.md b/docs/W7_FPGA_LITERATURE.md new file mode 100644 index 00000000..7d094de5 --- /dev/null +++ b/docs/W7_FPGA_LITERATURE.md @@ -0,0 +1,103 @@ +# Academic and industrial literature review — FPGA-attestation, PoFPGA, mesh-routing proofs, DePIN hardware proof-of-work + +`phi^2 + phi^-2 = 3` + +*Prepared for the Tri-Net drone-mesh DePIN project. Every factual claim below links to the exact URL fetched to support it. Values that could not be confirmed from a fetched primary source are marked "n.a." Search date: 2026-07-05.* + +--- + +## Section 1: FPGA attestation and Physically Unclonable Functions (PUFs) on Zynq/Xilinx + +### Zynq-7020 / 7-series device DNA and eFUSE identity — what it provides and what it doesn't + +The 7-series (and Zynq-7000) FPGA contains an embedded 64-bit device identifier that is used to provide a 57-bit Device DNA value; the identifier is nonvolatile, permanently programmed by the vendor, and unchangeable, making it tamper-resistant ([AMD/Xilinx 7 Series FPGAs Configuration User Guide UG470, as quoted in the cnblogs transcription](https://www.cnblogs.com/xingce/p/18312230)). Critically, the 57-bit `DNA_PORT` value is **not guaranteed globally unique** — up to 32 devices within a family can share the same DNA_PORT value, and only the full 64-bit `FUSE_DNA` read over JTAG is always unique ([UG470 text, cnblogs](https://www.cnblogs.com/xingce/p/18312230); corroborated by the JokerのZYNQ7020 DNA_PORT note stating DNA_PORT is a 57-bit value shareable with up to 32 devices and aligned to FUSE_DNA[63:7]](https://blog.csdn.net/u011565038/article/details/137007550)). The AMD Vivado primitive documentation confirms `DNA_PORT` exposes a factory-programmed, read-only shift register "primarily used with other circuitry to build added copy protection for the FPGA bitstream from possible theft" ([AMD DNA_PORT primitive, UG953](https://docs.amd.com/r/2022.2-English/ug953-vivado-7series-libraries/DNA_PORT)). The Zynq eFuse controller provides access to chip efuses holding device DNA, security settings and device status ([Xilinx linux-xlnx zynq-efuse device-tree binding](https://github.com/Xilinx/linux-xlnx/blob/master/Documentation/devicetree/bindings/arm/zynq/zynq-efuse.txt)). **Implication for Tri-Net:** device DNA gives a cheap, factory-fixed identifier but is not a secret and is not collision-free at 57 bits; it is a copy-protection aid, not a cryptographic root of trust on its own. + +### PUFs on 7-series FPGAs — measured uniqueness / reliability + +| Source | Authors / Year / Venue | One-line contribution & measured numbers | +|---|---|---| +| [Novel Randomized Placement for FPGA Based Robust ROPUF with Improved Uniqueness](https://arxiv.org/abs/2006.09290) | Arjun Singh Chauhan, Vineet Sahula, Atanendu Sekhar Mandal; 2019/2020; *Journal of Electronic Testing* v35, pp.581–601 | Randomized RO placement on Xilinx 7-series raises **uniqueness to 49.90%** (within 0.1% of the 50% ideal) and **reliability to 99.70%** (<1 bit flip average) using <1% of LUTs; passes NIST tests ([arxiv abstract](https://arxiv.org/abs/2006.09290)). | +| [Physically Cloning an FPGA Ring-Oscillator PUF](https://byuccl.github.io/assets/cook_fpt22.pdf) | Hayden Cook, Jonathan Thompson, Zephram Tripp, Brad Hutchings, Jeffrey Goeders; FPT 2022 (year not stated in body) | **First demonstrated physical cloning of an RO PUF** via targeted bitstream-induced aging: a 128-bit RO PUF on two Artix-7 boards was driven from Hamming distance 55 to **0 in ~2 days**, showing delay-based FPGA PUFs are clonable ([paper PDF](https://byuccl.github.io/assets/cook_fpt22.pdf)). | +| [Reliability improvement of SRAM PUFs based on a detailed ...](https://www.sciencedirect.com/science/article/pii/S1434841124000323) | Authors n.a.; 2024; *Microelectronics* (ScienceDirect) | SRAM-PUF reliability-improvement study; specific numbers were behind the abstract and n.a. from the fetched page ([ScienceDirect page](https://www.sciencedirect.com/science/article/pii/S1434841124000323)). | + +### FPGA-bitstream / measured-boot attestation schemes + +The Xilinx application note **"Measured Boot of Zynq-7000 All Programmable SoCs" (XAPP1309, Xilinx, 2017)** adds a TPM (Infineon OPTIGA SLB9670) to the Zynq HROT: the FSBL computes SHA-1 of BootROM and FSBL and extends them into TPM PCR[0]/PCR[4], the TPM signs the PCR values, and a server performs remote attestation against known-good measurements; measured boot is done in addition to secure boot ([TCG-hosted XAPP1309](https://trustedcomputinggroup.org/wp-content/uploads/Measured-Boot-of-Zynq-7000-All-Programmable-SoCs-.pdf)). An academic Zynq-family TEE survey notes secure-boot modes on ZU+ use RSA keypairs programmed into eFuse for authentication and AES-GCM (key in eFuse/BBRAM) for encrypt-only boot ([Towards Runtime Customizable TEE on Zynq, arXiv:2307.04375](https://arxiv.org/pdf/2307.04375)). A separate arXiv TEE paper describes the FPGA Configuration Module acting as Root of Trust for Measurement, verifying/decrypting an encrypted bitstream using BBRAM/eFUSE keys ([Building Your Own TEEs Using FPGA, arXiv:2203.04214](https://arxiv.org/html/2203.04214v3)). A classic Cambridge protocol shows how a unique non-secret FPGA identifier (e.g., Xilinx Device DNA) prevents replay of remote configuration updates to other FPGAs ([Kuhn et al., "A protocol for secure remote updates of FPGA configurations"](https://www.cl.cam.ac.uk/~mgk25/arc2009-remoteupdates.pdf)). + +### Commercial FPGA-attestation / PUF products + +- **Intrinsic ID** — inventor of the SRAM PUF; QuiddiKey-FLEX SRAM PUF ships inside Microsemi PolarFire FPGAs, generating full-entropy 256-bit hardware-intrinsic keys used e.g. for the device's private ECC identity key ([Microsemi + Intrinsic ID PR Newswire, 2017](https://www.prnewswire.com/news-releases/microsemi-and-intrinsic-id-collaboration-delivers-sram-puf-in-polarfire-fpgas-providing-advanced-security-300466679.html)); "QuiddiKey for Intel FPGAs" brings SRAM PUF to Intel Stratix/Agilex families ([Design & Reuse, 2022](https://www.design-reuse.com/news/52090/intrinsic-id-embedded-sram-puf-security-ip-military-grade-ip-protection-intel-fpga.html)). Intrinsic ID's **Apollo** is a "soft PUF" that uses circuits inside Xilinx FPGAs (Butterfly PUF where no uninitialized SRAM exists), delivered as part of the FPGA configuration file, enabling brownfield retrofit of a hardware root of trust ([Intrinsic ID Fact Sheet 2023](https://www.hannovermesse.de/apollo/hannover_messe_2023/obs/Binary/A1257469/Intrinsic%20ID%20Fact%20Sheet%202023%2002%2028.pdf)). This "soft PUF on the Zynq fabric" is the closest commercial analogue to what Tri-Net would deploy on the P201Mini's Zynq-7020. +- **PUFsecurity / eMemory** — PUFrt hardware root of trust includes a 1024-bit NeoPUF (quantum-tunneling), TRNG (NIST SP800-90B/22) and secure OTP; the vendor cites Hamming weight 50%, inter-HD 50%, intra-HD 0% for NeoPUF ([PUFsecurity PUFrt product page](https://www.pufsecurity.com/products/pufrt/); [PUF Series 4, NeoPUF metrics](https://www.pufsecurity.com/document/puf-series-4%EF%BC%9Asoftware-post-processing-makes-sram-puf-vulnerable-as-rot/)). Note NeoPUF is a silicon-IP macro, not deployable on existing Zynq fabric. + +--- + +## Section 2: Proof of FPGA / Proof of Physical Work / hardware-bound DePIN + +**No published scheme literally named "Proof of FPGA" was found.** Searches for a "Proof of FPGA" whitepaper returned FPGA-attestation and PUF-attestation papers but no protocol using that exact term (see Section 5.1 for the negative-result evidence). The closest published constructs are FPGA remote-attestation protocols and DePIN "Proof of Physical Work." + +| Source | Authors / Year / Venue | Contribution | +|---|---|---| +| [Post-Quantum and Blockchain-Based Attestation for Trusted FPGAs in B5G Networks](https://www.arxiv.org/abs/2506.21073) | Papalamprou, Fotos, Chatzivasileiadis, Angelogianni, Masouros, Soudris; 2025; arXiv:2506.21073 (cs.AR) | Hybrid HW/SW **remote attestation of FPGA bitstreams using PQC** (SHA3-512 checksums for SW+HW, DSA+KEM), with attestation evidence stored on a **blockchain**; ~2% overhead vs non-PQC across two FPGA families. The single most on-point "FPGA-attestation-on-a-chain" paper for Tri-Net. | +| [PUFatt: Embedded Platform Attestation Based on Novel Processor-based PUFs](https://yubi-ece.github.io/Attachments/teaching/ELE594/reading_assignments/PUFatt%20Embedded%20platform%20attestation%20based%20on%20novel%20processor-based%20PUFs.pdf) | Kong, Koushanfar, Pendyala, Sadeghi, Wachsmann; DAC 2014 (venue per title) | Combines a PUF-based hardware trust anchor (ALU PUF) with timed remote attestation; proof-of-concept on FPGA; detects impersonation. Foundational "PUF + attestation" primitive. | +| [Runtime Self-Attestation of FPGA-Based IoT Devices](https://www.ece.nus.edu.sg/stfpage/bsikdar/papers/iotj_ma_24.pdf) ([IEEE Xplore record](https://ieeexplore.ieee.org/document/10599137/)) | Ma & Sikdar (NUS); 2024; IEEE Internet of Things Journal | Lightweight **challenge-response self-attestation of an FPGA hardware design** (FSM + datapath) to detect malicious modification without heavy cryptographic bitstream hashing; validated in simulation. | +| [SACHa: Self-Attestation of Configurable Hardware](https://past.date-conference.com/proceedings-archive/2019/pdf/0884.pdf) | Perez et al.; DATE 2019 | FPGA performs **self-attestation via configuration-memory readback + AES-CMAC MAC over the bitstream** against a golden reference, making the FPGA a tamper-resistant trust module. Directly relevant to a PoFPGA "prove-your-loaded-bitstream" design. | +| [Helium Whitepaper — Proof-of-Coverage](http://whitepaper.helium.com) | Nova Labs / Helium; n.a. year | Defines **Proof-of-Coverage (PoC)**: an interactive challenge-response protocol proving a miner provides RF wireless coverage at an asserted GPS location, substituting permissioned identity with reusable physical work under a BFT consensus. The canonical DePIN proof-of-physical-work primitive. | +| [IoTeX DePIN Infra Modules docs](https://docs.iotex.io/depin) | IoTeX; 2025 | Describes writing **"proofs of physical work"** from devices to chain: devices register on-chain, raw data is parsed/sequenced/stored, and computations are verified before settlement. | + +Supporting economic/sybil context: an arXiv mechanism-design paper, **"Proof of Useful Attestation (PoUA)"** (Stefan Stefanović; arXiv:2605.25844, submitted 25 May 2026), proves a cost-to-grind floor (Lemma 1) and a **4×–10× cost premium against a capital adversary vs pure-stake PoS**, giving a formal template for hardware/attestation-anchored token distribution and sybil resistance ([arXiv:2605.25844](https://arxiv.org/abs/2605.25844)). Industry write-ups frame the three DePIN hardware-trust approaches as TEE attestation, Secure-Element/device-identity (Helium uses a Semtech-style secure chip with embedded key), and on-device ZK proofs ([TRUETECH DePIN development](https://truetech.dev/blockchain-development/services/blockchain-infrastructure/depin-project-development.html)); Helium's own PoC roadmap plans "specially hardened hardware elements that can cryptographically attest to their locations and observations" ([Helium IOT PoC Roadmap](https://docs.helium.com/iot/proof-of-coverage-roadmap/)), and its ECC-key verifier is a Rust service bridging hardware keys to the blockchain ([Solana Helium technical case study](https://solana.com/news/case-study-helium-technical-guide)). + +--- + +## Section 3: Mesh routing proofs and FANET/MANET protocols with formal verification + +| Source | Authors / Year / Venue | Contribution & numbers | +|---|---|---| +| [FANET Networks: Analysis of Routing Protocols](https://research.usfq.edu.ec/en/publications/fanet-networks-analysis-of-routing-protocols/) | Carvajal-Rodríguez, Moposita, Tipantuña, Urquiza, Vega-Sanchez; 2024; ETCM 2024 (IEEE) | NS3 comparison of **OLSR, DSDV, AODV, DSR, AOMDV, HWMP** across **25 and 50 UAVs**, static and at 10/20 m/s, on throughput/PDR/delay. Concrete per-protocol numbers were behind the record page (n.a.). | +| [Customized novel routing metrics for wireless mesh-based swarm-of-drones applications](https://www.sciencedirect.com/science/article/abs/pii/S2542660520300998) | Kemal (Yaşar) et al.; 2020; *Vehicular Communications* (per journal) | Two new **IEEE 802.11s link-quality metrics (SrFTime, CRP)** for FANETs, ns-3 + 3D mobility; consistently beat the default Airtime metric on throughput (numeric values n.a. from abstract). Directly relevant to Tri-Net's ETX-style mesh metric on 5.8 GHz. | +| [Formal Verification of Ad-Hoc Routing Protocols Using SPIN Model Checker](https://www.cs.purdue.edu/truselab/readings/renesse.pdf) | de Renesse & Aghvami; Purdue/KCL reading copy | **SPIN/Promela model checking** of ad-hoc routing (WARP), demonstrating formal verification of route-discovery correctness on wireless ad-hoc protocols. | +| [Formal verification of standards for distance vector routing protocols](https://dl.acm.org/doi/10.1145/581771.581775) | Bhargavan, Obradovic, Gunter; 2002; *Journal of the ACM* | Combines HOL theorem proving + SPIN model checking to prove **loop-freedom / convergence** of distance-vector (RIP/AODV-style) routing — the classic formal-verification-of-routing result Tri-Net can cite for routing-proof rigor. | +| [Byzantine Fault Tolerant Consensus in Open Wireless Networks via an Abstract MAC Layer](https://www.tkn.tu-berlin.de/bib/jing2024byzantine/jing2024byzantine.pdf) | Jing et al.; 2024 (venue n.a.) | BFT consensus over a **Byzantine-resilient abstract MAC layer** on a multi-channel wireless network tolerating up to n/3 faults incl. jamming; Theorems 1–2 give O(ckn/(k−f)·log n) round bounds; simulated n∈[1000,5000]. Strong model for BFT mesh routing under adversarial radio. | +| [ODSBR: An On-Demand Secure Byzantine Resilient Routing Protocol for Wireless Ad Hoc Networks](https://web.njit.edu/~crix/publications/ODSBR-TISSEC.pdf) | Awerbuch, Curtmola, Holmer, Nita-Rotaru, Rubens; 2008; ACM TISSEC | Canonical **Byzantine-resilient on-demand routing** using an adaptive probing/link-weight scheme to route around adversarial nodes on ad-hoc wireless. | + +Recency note: 2024 FANET simulation studies consistently report AODV/OLSR/TORA trade-offs (e.g., TORA best throughput/PDR, DSDV lowest jitter) but are **simulation-only in NS-2/NS-3/Netsim**, mirroring Tri-Net's own M2–M4 simulation status ([Exploiting Conventional MANET Routing in UAV-based FANET, 2024](https://iasj.rdd.edu.iq/journals/uploads/2024/12/17/2a962cf06ae9fafdc40dd92404e8a103.pdf)). + +--- + +## Section 4: Commercial monetization models for FPGA-attested compute/bandwidth + +### How compute DePINs attest to contribution +- **io.net** verifies contribution primarily by validators randomly replicating jobs plus a rewards/punishment system; its named primitive is **Proof of Time-Lock** (prove a rented GPU is 100% committed T1→T2, via benchmarks, container monitoring, and blocking foreign processes), and it explicitly states proof-of-compute "isn't mature" ([io.net FAQ](https://io.net/docs/guides/faq)). For confidential inference, io.net uses **TEE hardware attestation**: NVIDIA multi-GPU attestation (GPU genuine + in Confidential Computing mode) and AMD SEV-SNP / Intel TDX CPU quotes, plus image-digest and signing-address checks ([io.net Verification Guide](https://io.net/docs/guides/confidential-inference/verification-guide)). io.net + **NovaNet** are building **zkGPU-ID**, zero-knowledge GPU identification proving GPU specs meet claimed performance ([CryptoNews, 2024](https://cryptonews.net/news/altcoins/30065708/)), motivated by earlier fraud where fabricated uptime reported ~1M nonexistent GPUs ([NovaNet DePIN Verification Handbook coverage, Yahoo Finance 2024](https://finance.yahoo.com/news/device-proofs-solve-depin-verification-212754654.html)). An open-source MIT confidential-compute attestation agent (Intel TDX / NVIDIA H200) exists for io.net ([ionet-official cc-attestation-agent-api, GitHub](https://github.com/api-evangelist/io-net)). + +### FPGA-specific compute marketplaces and pricing +No dedicated **FPGA compute marketplace** with published pricing was found in this research pass; the compute-DePIN market (io.net, Akash, Render, Bittensor) is GPU/CPU-centric with attestation built around GPU firmware signatures and TEEs, not FPGA fabric ([io.net FAQ](https://io.net/docs/guides/faq); [AI crypto tokens overview](https://www.weloveeverythingcrypto.com/guides/ai-tokens-crypto-agents-guide)). FPGA-specific compute marketplace existence/pricing: **n.a.** + +### Legal / IP considerations for FPGA-bitstream distribution +- Bitstream IP piracy (reverse engineering, cloning, overuse) is a documented commercial threat; countermeasures include IEEE **P1735** encrypted-IP distribution, watermarking, and **PUF-based per-device licensing** that binds a design to a specific FPGA ([FPGA Bitstream Security: A Day in the Life, Duncan et al., Indiana University](https://homes.luddy.indiana.edu/lukefahr/papers/duncan2019fpga.pdf)). +- The IEEE P1735 scheme is **broken**: Speith et al. recovered IP-encryption keys for all major EDA/FPGA vendors, enabling decrypt/modify/re-encrypt of "protected" cores — an industry-wide break ([Toward FPGA IP Encryption from Netlist to Bitstream, ACM TRETS](https://dl.acm.org/doi/pdf/10.1145/3656644)). +- IP piracy in a deployed bitstream can be detected from the bitstream alone via netlist extraction + subgraph isomorphism ([ReCon: From the Bitstream to Piracy Detection, Skipper et al., Indiana University](https://sailin.luddy.indiana.edu/papers/skipper2020recon.pdf)). Pay-per-use/pay-per-device licensing bound to on-chip keys or PUFs is the established legal-technical model ([Cryptographically Enforced Pay-Per-Use Licensing of FPGA IP, Kean, Design&Reuse/FCCM](https://www.design-reuse.com/article/57675-cryptographically-enforced-pay-per-use-licensing-of-fpga-design-intellectual-property/); [Combining PUF with RLUTs: Two-Party Pay-Per-Device IP Licensing on FPGAs, NTU](https://dr.ntu.edu.sg/bitstream/10356/144668/2/Combining%20PUF%20with%20RLUTs%20a%20two%20party%20pay%20per%20device%20IP%20licensing%20scheme%20on%20FPGAs.pdf)). + +### Comparable revenue-per-node for mesh/wireless DePIN +| Project | Figure | Type / date | Source | +|---|---|---|---| +| Helium Mobile | $2.2M | Monthly revenue, Feb 2026 | [Solana Report, 2026-03-29](https://solanareport.com/2026/03/29/solana-depin-revenue-leaders-helium-mobile-2-2m-monthly-and-xnet-100tb-milestone-breakdown) | +| Helium (Mobile + carrier offload) | $35M | Annualized network revenue (2026) | [Solana Report](https://solanareport.com/2026/03/29/solana-depin-revenue-leaders-helium-mobile-2-2m-monthly-and-xnet-100tb-milestone-breakdown) | +| Helium hotspot operator | $20–$50 | Monthly earnings per hotspot (HNT/MOBILE) | [Solana Report](https://solanareport.com/2026/03/29/solana-depin-revenue-leaders-helium-mobile-2-2m-monthly-and-xnet-100tb-milestone-breakdown) | +| Helium (historical) | ~$20 | Monthly income per node (2022) | [ChainCatcher, 2022](https://www.chaincatcher.com/en/article/2077151) | +| XNET | 2.5M $XNET | Per 2-week epoch, split 70% by data / 25% to nodes ≥3GB / 5% to all active | [XNET Mobile writeup, Medium 2025](https://collinsdefipen.medium.com/xnet-mobile-how-a-stealth-network-hijacked-the-traditional-telecom-eee03a39ff5b) | +| XNET | ~14,000 $XNET/mo per device; ~$281.65/shard/mo (illustrative) | Per-shard earnings estimate, Jul–Oct 2025 window | [XNET Explained video transcript, 2025](https://www.youtube.com/watch?v=g70o1M4mUAs) | +| XNET | 100TB | Monthly traffic milestone, Mar 2026 (no revenue figure reported) | [Solana Report](https://solanareport.com/2026/03/29/solana-depin-revenue-leaders-helium-mobile-2-2m-monthly-and-xnet-100tb-milestone-breakdown) | + +Data-Credit unit economics: 1 Data Credit = $0.00001 USD; network revenue = burned DCs (data transfer, onboarding) + Helium Mobile subscriber revenue ([Blockworks Helium annualized revenue metric](https://blockworks.com/analytics/helium/helium-financials/helium-annualized-revenue-2)). + +--- + +## Section 5: TL;DR — three specific answers + +**1. Is "Proof of FPGA" already a published concept?** +**No published "Proof of FPGA" (PoFPGA) concept was found as of 2026-07-05.** Web searches for a "Proof of FPGA attestation whitepaper" surfaced only adjacent work — FPGA *remote/self-attestation* (SACHa, PUFatt, Runtime Self-Attestation, PQC+Blockchain FPGA attestation) and DePIN *Proof of Physical Work / Proof of Coverage* — but nothing using the term "Proof of FPGA" as a named protocol ([search results for "Proof of FPGA attestation whitepaper" — returned PUFatt, SACHa, PQC-blockchain FPGA attestation, none named PoFPGA](https://yubi-ece.github.io/Attachments/teaching/ELE594/reading_assignments/PUFatt%20Embedded%20platform%20attestation%20based%20on%20novel%20processor-based%20PUFs.pdf); [DePIN PoPW search returned Helium PoC / IoTeX PoPW, not PoFPGA](https://docs.iotex.io/depin)). The **earliest reference to the underlying idea** (binding a cryptographic proof to specific FPGA fabric so only that device can produce it) is Simpson & Schaumont's PUF-based FPGA IP-protection concept, discussed in **Guajardo et al., "FPGA Intrinsic PUFs and Their Use for IP Protection," CHES 2007** ([CHES 2007 paper](http://www.sandeepkumar.org/my/papers/2007_CHES_PUFsOnFPGA.pdf)), and Tom Kean's earlier cryptographic FPGA IP-binding work (2002–2003) ([Kean, Cryptographically Enforced Pay-Per-Use Licensing, Design&Reuse 2003](https://www.design-reuse.com/article/57675-cryptographically-enforced-pay-per-use-licensing-of-fpga-design-intellectual-property/)). So "PoFPGA" as a named DePIN primitive appears to be **greenfield / unclaimed terminology**, built from well-established parts. + +**2. Strongest existing cryptographic primitive for FPGA-based hardware attestation (2024–2026).** +The strongest **fabric-deployable** primitive is **self-attestation of the loaded bitstream via configuration-memory readback protected by a keyed MAC (AES-CMAC), rooted in an on-chip secret** — as in **SACHa (DATE 2019)** ([SACHa](https://past.date-conference.com/proceedings-archive/2019/pdf/0884.pdf)) and its 2024 runtime successor ([Runtime Self-Attestation of FPGA-Based IoT Devices, IEEE IoT-J 2024](https://www.ece.nus.edu.sg/stfpage/bsikdar/papers/iotj_ma_24.pdf)); for a quantum-resistant, chain-anchored version, use **PQC-based FPGA remote attestation with blockchain evidence storage** (SHA3-512 HW/SW checksums + PQC DSA/KEM, ~2% overhead), from **Papalamprou et al., arXiv:2506.21073 (2025)** ([paper](https://www.arxiv.org/abs/2506.21073)). Caveat for Tri-Net: **delay-based PUFs (RO/arbiter) on FPGAs are physically clonable** ([Cook et al., "Physically Cloning an FPGA RO PUF," FPT 2022](https://byuccl.github.io/assets/cook_fpt22.pdf)), so a PoFPGA design should lean on eFUSE/BBRAM-stored secret keys + MAC-over-readback (SACHa-style) rather than a raw RO-PUF response, or on an SRAM/Butterfly-PUF soft-IP such as Intrinsic ID Apollo on the Zynq fabric ([Intrinsic ID Fact Sheet, Apollo soft PUF for Xilinx FPGAs](https://www.hannovermesse.de/apollo/hannover_messe_2023/obs/Binary/A1257469/Intrinsic%20ID%20Fact%20Sheet%202023%2002%2028.pdf)). + +**3. DePIN project with the closest attestation model to Tri-Net's needs** (radio hardware + mesh contribution + cryptographic proof of physical presence). +**Helium** is the closest match. Its **Proof-of-Coverage** proves RF radio hardware is physically present at an asserted GPS location through an interactive, witnessed challenge-response, substituting permissioned identity with reusable physical work under BFT consensus ([Helium Whitepaper](http://whitepaper.helium.com)); hotspots self-beacon every ~6 hours and are witnessed by ~12 neighbors, with an on-chip/off-chain **ECC-key verifier (a Rust service)** bridging hardware keys to Solana ([Solana Helium technical case study](https://solana.com/news/case-study-helium-technical-guide)); device identity uses a secure element storing a private key that signs each message ([Helium PoC roadmap for hardened attesting hardware](https://docs.helium.com/iot/proof-of-coverage-roadmap/); [Nova Labs Proof-of-Coverage devdocs](https://github.com/novalabsxyz/devdocs/blob/master/blockchain/proof-of-coverage.md)). For the generalized device-identity/PoPW pattern (register on-chain, sign proofs with a device private key whose public key is the Device ID), **IoTeX's DePIN Infra Modules** provide the reference architecture ([IoTeX DePIN docs](https://docs.iotex.io/depin)). Tri-Net's radio-mesh, three-node-triangle model maps most naturally onto Helium's witnessed Proof-of-Coverage, upgraded with an FPGA bitstream-attestation step (SACHa/PQC-attestation) to bind the proof to the P201Mini's Zynq-7020 fabric before SKY26b silicon is available. diff --git a/docs/W7_WEAK_POINTS_STRUCTURAL.md b/docs/W7_WEAK_POINTS_STRUCTURAL.md new file mode 100644 index 00000000..e2070b1e --- /dev/null +++ b/docs/W7_WEAK_POINTS_STRUCTURAL.md @@ -0,0 +1,356 @@ +# W7 — структурный аудит слабых мест Tri-Net DePIN + +> phi^2 + phi^-2 = 3 + +Дата: 2026-07-05. Роль: критический peer-reviewer, внешний по отношению к команде. +Скоуп: только СТРУКТУРНЫЕ риски — архитектура, зависимости, экономика, регуляторика, +bus factor. Языковые/anchor-bias проблемы уже задокументированы отдельно +([`docs/W6_WEAK_POINTS_AND_W7_PLAN.md`](https://github.com/gHashTag/tri-net/blob/main/docs/W6_WEAK_POINTS_AND_W7_PLAN.md), +[`docs/W6_CODEGEN_AUDIT_2026-07-05.md`](https://github.com/gHashTag/tri-net/blob/main/docs/W6_CODEGEN_AUDIT_2026-07-05.md)) +и здесь не повторяются. + +Метод: каждое утверждение проверено по файлу в репозитории `gHashTag/tri-net` +(branch `main` @ `dd83ea4`) или по номеру PR. Где подтверждения нет — сказано прямо. + +--- + +## Резюме на одну фразу + +Проект честно документирует собственную слабость лучше, чем большинство стартапов +документируют свою силу, — но честность аудита не отменяет того, что **пять из +восьми найденных проблем — это hard-блокеры, которые не решаются кодом**, а решаются +деньгами, юристами и человеко-часами, которых пока не видно в плане. + +--- + +## Находка 1 — Timeline risk: весь compute-arm висит на одной дате в календаре + +**Severity: CRITICAL** + +Tape-out TT SKY26b Trinity назначен на 2026-12-16 — это `projected`, не `hw` +([README.md:26](https://github.com/gHashTag/tri-net/blob/main/README.md)). Между +сегодня (2026-07-05) и tape-out — более 5 месяцев, и это ещё не «кремний на столе», +а «кремний ушёл в фаб». Между tape-out и «returned silicon» на реальных ASIC-проектах +обычно ещё 8-16 недель. `docs/AGENT_ONBOARDING.md:198` фиксирует прямо: «4 dies +SKY26b — submitted, returned silicon отсутствует. Никогда не заявляй returned без +пруфа» — то есть команда сама признаёт, что резервный сценарий «а что если кремний +задержится» нигде не прописан в виде дат/чисел. + +Roadmap (`README.md:167`) вставляет весь compute-anchor arm в один пункт P6 — +«Trinity silicon back → BitNet benchmark → `[Open conjecture]` закрывается» — без +промежуточных milestone'ов на случай трёхмесячной, полугодовой или годовой задержки. +Единственная явная страховка найдена в `docs/BENCHMARK_VS_MANET_2026-07-04.md` +(шкала M7 «Silicon-anchor score»): уровень 3 — «FPGA bitstream anchor + signed +measurement», уровень 2 — «TPM/secure-element attestation», против уровня 5 — +«custom ASIC returned + on-chain verifier». Это ХОРОШАЯ рамка, но она существует +только как **система оценки конкурентов**, а не как **план перехода собственного +проекта** с уровня 2/3 на уровень 5. Ни один документ не говорит: «если 2026-12-16 +проходит без tape-out, мы автоматически остаёмся на FPGA-anchor N месяцев, вот +экономические последствия». + +**Evidence:** [`README.md:26,167`](https://github.com/gHashTag/tri-net/blob/main/README.md); [`docs/AGENT_ONBOARDING.md:198`](https://github.com/gHashTag/tri-net/blob/main/docs/AGENT_ONBOARDING.md); [`docs/BENCHMARK_VS_MANET_2026-07-04.md` §M7](https://github.com/gHashTag/tri-net/blob/main/docs/BENCHMARK_VS_MANET_2026-07-04.md). + +**Митигация:** зафиксировать в отдельном документе (`docs/SILICON_SLIP_CONTINGENCY.md`) +три явных сценария — slip 3/6/12 месяцев — с указанием, какой arm остаётся на +FPGA-bitstream-anchor (уровень 3 по своей же шкале M7) на каждый период, и что это +значит для эмиссии токена (см. находку 7). Без этого документа единственный сигнал +рынку — «увидим 16 декабря» — это не план, это ставка. + +--- + +## Находка 2 — Compute proof arm заблокирован полностью, softfallback не описан + +**Severity: CRITICAL** + +Whitepaper-таблица в `README.md:51` требует для Compute arm **3-of-3 Phi+Euler+Gamma +sigs** — то есть подписи трёх *разных* кристаллов Trinity. Ни один из них ещё не +существует в железе (`README.md:26`, «projected»). README сам констатирует это в +строке 70: «Compute proof требует silicon back» — это прямое признание, что данный +arm при текущей архитектуре **не может выдавать proof вообще**, ни в каком +software-signed режиме, в отличие от Transport/Coverage/Sensor, которые по +`README.md:67-70` уже могут работать «software-signed level». + +Разрыв между «software-signed» и «silicon-signed» с точки зрения sybil resistance — +конкретный и большой: software-подпись проверяет, что *какой-то* приватный ключ +подписал сообщение; она не проверяет, что подписант — уникальный физический чип, +которого нельзя виртуализировать/склонировать N раз на одном сервере. Именно +поэтому `MiningPool.claimReward()` в `README.md:112` требует «unique PUF» и +«φ-anchor 0x47C0 cross-die» отдельными строками — команда явно понимает разницу, +но нигде не описан промежуточный механизм (например, TPM/HSM-based +attestation — уровень 2 по собственной шкале M7 из +`docs/BENCHMARK_VS_MANET_2026-07-04.md`), который позволил бы Compute arm выдавать +хоть какой-то proof до кремния, пусть с более слабой sybil-гарантией. + +**Evidence:** [`README.md:51,67-70,112`](https://github.com/gHashTag/tri-net/blob/main/README.md). + +**Митигация:** явно объявить Compute arm «disabled by design pre-silicon» (не +пытаться обойти это программной заглушкой — README и так формулирует принцип «No +chip, no TRI» правильно), но добавить TPM/HSM-based interim attestation как +*опциональный, помеченный ниже-уровня-безопасности* путь, если экономика без +Compute-arm окажется нежизнеспособной за 6 месяцев ожидания (см. находку 7). + +--- + +## Находка 3 — 3-node triangle не может продемонстрировать содержательный self-heal + +**Severity: MAJOR** + +Математика тут элементарная, и сама команда её частично видит: `docs/STRENGTHEN.md:23` +формулирует «Triangle beats chain… precondition for R6 (2 next-hop candidates per +node)». Это верно **пока все три узла живы**. В момент, когда один узел или одна +связь падает, треугольник с 3 вершинами вырождается в прямую линию из 2 оставшихся +узлов — единственный путь между ними один, никакого «выбора маршрута» нет физически. +"Self-healing" в интересном смысле (система выбирает ДРУГОЙ путь в обход отказа) +на 3 узлах продемонстрировать нельзя — можно продемонстрировать только «обнаружение +отказа + переключение на единственный оставшийся линк», что является detection +latency, а не rerouting. + +`README.md:23` и `README.md:162` формулируют M4 (P2 DEMO GATE) именно как +«3-node triangle, shared uplink», и M5 как «self-healing convergence measured» — +но при всего 3 узлах M5 способен измерить только время до переключения на +единственно возможный оставшийся линк, не качество выбора между альтернативами. +Тесты в [`tests/m2_routing_pure_logic.rs:251`](https://github.com/gHashTag/tri-net/blob/main/tests/m2_routing_pure_logic.rs) +сами это признают комментарием «3-node mesh can validate it» — в контексте +ограниченной проверки, не полноценного path-diversity сценария. + +**Evidence:** [`README.md:23,162`](https://github.com/gHashTag/tri-net/blob/main/README.md); [`docs/STRENGTHEN.md:23`](https://github.com/gHashTag/tri-net/blob/main/docs/STRENGTHEN.md); [`tests/m2_routing_pure_logic.rs:251`](https://github.com/gHashTag/tri-net/blob/main/tests/m2_routing_pure_logic.rs). + +**Митигация:** либо (a) переименовать M4/M5 честно — «single-failover convergence +demo», не «self-healing» — пока стенд из 3 узлов, либо (b) добавить 4-й/5-й узел +к P2 DEMO GATE как обязательное условие для заявления «self-heal» в +маркетинговых/научных материалах. Вариант (b) дороже (ещё 1-2 платы Zynq), но это +единственный способ показать реальный path-diversity choice. + +--- + +## Находка 4 — codegen intersection = ∅: реформулировка «determinism под общим парсером» закрывает claim, но не отменяет архитектурный вопрос «зачем три бэкенда» + +**Severity: MAJOR** + +Матрица из [`docs/W6_CODEGEN_AUDIT_2026-07-05.md`](https://github.com/gHashTag/tri-net/blob/main/docs/W6_CODEGEN_AUDIT_2026-07-05.md) +(Rust 19/68, C 2/68, Zig 0/68, cross-backend ∩ = ∅, PR #42) и reality-check #4 в +[`docs/WAVE_REPORT_2026-07-05.md:73`](https://github.com/gHashTag/tri-net/blob/main/docs/WAVE_REPORT_2026-07-05.md) +корректно снимают claim «независимость через избыточность» — это была +переоценка, и её честно откатили. Но реформулировка «determinism под общим +парсером» ([`docs/W6_WEAK_POINTS_AND_W7_PLAN.md:13`](https://github.com/gHashTag/tri-net/blob/main/docs/W6_WEAK_POINTS_AND_W7_PLAN.md)) +сама по себе не отвечает на структурный вопрос: **если три бэкенда не являются +независимыми oracles друг для друга (общий front-end `t27c`), а ни один модуль не +компилируется во всех трёх — какую практическую ценность несёт сама по себе +tri-backend архитектура прямо сейчас**, кроме будущего опциона? [`PAPER_DELTA_v0.md:230`](https://github.com/gHashTag/tri-net/blob/main/docs/PAPER_DELTA_v0.md) +сам формулирует это честно: «byte-determinism… much weaker property today than… +downstream compilability» — то есть авторы признают, что нынешняя ценность — +это гарантия воспроизводимости *вывода генератора*, а не гарантия работоспособности +кода. Пока это так, «tri-backend» как маркетинговый и архитектурный тезис не имеет +эмпирической опоры — только опору «когда-нибудь заработает». + +**Evidence:** [`docs/W6_CODEGEN_AUDIT_2026-07-05.md`](https://github.com/gHashTag/tri-net/blob/main/docs/W6_CODEGEN_AUDIT_2026-07-05.md) (таблица + PR #42); [`docs/PAPER_DELTA_v0.md:230,251,253`](https://github.com/gHashTag/tri-net/blob/main/docs/PAPER_DELTA_v0.md). + +**Митигация:** не отказываться от tri-backend, но явно установить измеримый gate — +например «минимум 1 модуль (`wire`) компилируется во всех трёх backend'ах к дате X» +(в PR #44 уже идёт investigation E0425 root cause — «dropped let statements in t27c +Rust emitter», это правильный первый шаг) — и до достижения gate не использовать +tri-backend как argument силы проекта ни в статьях, ни в питчах. + +--- + +## Находка 5 — 108.6 дБ SNR — это digital loopback, эфирная цифра неизвестна и не тестируема без денег/разрешения + +**Severity: MAJOR** + +[`radio/README.md:7-14`](https://github.com/gHashTag/tri-net/blob/main/radio/README.md) +прямым текстом: «Uses the AD9361 **internal digital loopback** so nothing is +radiated», «SNR 108.6 dB over noise floor», и раздел «Next (still greenfield)» +перечисляет **RF loopback через SMA-кабель** как ещё не сделанный шаг, не говоря +уже об открытом эфире. 108.6 дБ — это, по сути, SNR внутренней цифровой петли ЦАП→АЦП +без единого метра пространства, без атмосферного затухания, без интерференции, +без реального фронтенда. Экстраполировать эту цифру на «5.8 GHz mesh работает» — +логическая ошибка того же типа, что уже зафиксирована как anchor-bias #1-3 в +[`docs/W6_CODEGEN_AUDIT_2026-07-05.md`](https://github.com/gHashTag/tri-net/blob/main/docs/W6_CODEGEN_AUDIT_2026-07-05.md), +только в радио-домене, а не в кодогене. + +Честная эфирная оценка уже частично посчитана в [`docs/STRENGTHEN.md`](https://github.com/gHashTag/tri-net/blob/main/docs/STRENGTHEN.md) +(строка P8): «FSPL 108 dB@1 km / 128 dB@10 km; sensitivity ~−93.8 dBm (BPSK½)» — +то есть на 1 км при слабом бортовом PA (10-15 dBm) link budget уже close to the +edge, задолго до учёта fading, multipath, doppler от дрона. Это не то же самое, +что «SNR 108.6 dB», и путать эти две цифры в публичной коммуникации — прямой +путь повторить anchor-bias. + +**Evidence:** [`radio/README.md:7-14,26-29`](https://github.com/gHashTag/tri-net/blob/main/radio/README.md); [`docs/STRENGTHEN.md` P8](https://github.com/gHashTag/tri-net/blob/main/docs/STRENGTHEN.md); [`README.md:19,91-93`](https://github.com/gHashTag/tri-net/blob/main/README.md). + +**Митигация:** везде, где 108.6 дБ фигурирует в публичных материалах (README, +paper draft), рядом ставить явный disclaimer «digital loopback only, not +over-the-air» — это уже частично сделано в README таблице статуса, но не в +Metrics-таблице (`README.md:92`), где цифра стоит голой. Плюс: SMA-кабель + аттенюатор +RF loopback (уже запланирован в `LOCAL_FLASH.md` §9.3) — следующий обязательный шаг +до любых заявлений про «5.8 GHz mesh», и он тестируем без FCC/regulatory allowance +(замкнутая цепь, ничего не излучается). + +--- + +## Находка 6 — регуляторная экспозиция 5.8 GHz: Таиланд уже явно закрыт для OTA, но это не выделено как отдельный, самостоятельный блокер верхнего уровня + +**Severity: MAJOR** + +Хорошая новость: команда это знает и написала прямым текстом — +[`docs/WAVE_REPORT_2026-07-03.md:145`](https://github.com/gHashTag/tri-net/blob/main/docs/WAVE_REPORT_2026-07-03.md): +«Cannot run 5.8 GHz OTA in Thailand — regulatory; keep the UDP transport for dev». +[`docs/LOCAL_FLASH.md:413`](https://github.com/gHashTag/tri-net/blob/main/docs/LOCAL_FLASH.md) +уточняет: «Внешний PA+LNA + разрешение — только после юридической подготовки +(ADGM/DIFC или локальный test license). До этого — все RF-эксперименты внутри +лаборатории на SMA/loopback». `docs/STRENGTHEN.md` (P8, строка «BVLOS / spectrum +regulatory») формулирует лимит «≤100 mW (TH/SG) licensed-by-rule ceiling» для +свободного полёта. + +Плохая новость: эта информация разбросана по трём разным doc'ам второго уровня +(wave report, local flash checklist, strengthen backlog) и нигде не собрана в один +«regulatory go/no-go» документ верхнего уровня рядом с README hardware-матрицей. +Пользователь базируется в Пхукете (Таиланд) — то есть основной физический адрес +разработки находится в юрисдикции, где OTA-излучение на 5.8 GHz для mesh уже +прямо запрещено без лицензии, и путь к легальному тестированию идёт либо через +ADGM/DIFC (UAE, см. `docs/LOCAL_FLASH.md:413` и Hub71 заявку в `README.md:169`), +либо через локальный test license, которых в репозитории нет ни одной ссылки/статуса. +Это значит, что весь путь от «digital loopback подтверждён» до «5.8 GHz mesh +летает» физически не может продвинуться дальше SMA-кабеля до появления +регуляторного разрешения — и этого разрешения сейчас нет ни в одной юрисдикции, +где команда имеет физическое присутствие. + +**Evidence:** [`docs/WAVE_REPORT_2026-07-03.md:145`](https://github.com/gHashTag/tri-net/blob/main/docs/WAVE_REPORT_2026-07-03.md); [`docs/LOCAL_FLASH.md:413`](https://github.com/gHashTag/tri-net/blob/main/docs/LOCAL_FLASH.md); [`docs/STRENGTHEN.md` P8 / BVLOS row](https://github.com/gHashTag/tri-net/blob/main/docs/STRENGTHEN.md); [`README.md:169`](https://github.com/gHashTag/tri-net/blob/main/README.md) (Hub71 UAE ADGM/DIFC track). + +**Митигация:** свести всё регуляторное знание в один `docs/REGULATORY_STATUS.md` +с таблицей «юрисдикция × статус (закрыто/тест-лицензия в процессе/чисто) × дата +следующего шага», и явно пометить его в README рядом с hardware-матрицей — этот +риск того же порядка важности, что и tape-out дата, но сейчас видим только по +фрагментам в трёх разных файлах. + +--- + +## Находка 7 — экономическая модель токена: кто платит за первые 6+ месяцев без кремния, ответа нет + +**Severity: CRITICAL** + +Токеномика в [`README.md:99-112`](https://github.com/gHashTag/tri-net/blob/main/README.md): +supply 3²⁷ = 7 625 597 484 987, 0% premine, 0% VC, 0% treasury, 9 халвингов +2026-2066, Era 0 (2026-2030) reward 1000 TRI/proof. Модель «честная» в смысле +отсутствия инсайдерского распределения — но именно из-за 0% premine/treasury у +проекта **нет собственного капитала для субсидирования раннего предложения**. +Compute arm заблокирован до кремния (находка 2), Transport/Coverage/Sensor arms +пока software-signed и, по логике находки 2, имеют более слабую sybil-защиту — +то есть именно в этот переходный период (минимум до 2026-12-16, реалистично +дольше) экономика максимально уязвима к тому, что либо (a) слабый спрос на +проверку (нет операторов, нет смысла майнить) либо (b) слабая sybil-защита +делает software-signed арки лёгкой мишенью для фарма. + +Мы искали в репозитории сравнение с моделью Helium — прямым текстом её нет ни в +одном файле (`docs/BENCHMARK_VS_MANET_2026-07-04.md`, `docs/PAPER_DELTA_v0.md`, +`docs/_recon/*`, README — во всех grep по «Helium»/«hotspot»/«subsidy» дал +только косвенные структурные аналогии в позиционировании README: «DePIN-узел +(Helium-style + edge compute)», [README.md:42](https://github.com/gHashTag/tri-net/blob/main/README.md)). +То есть Helium упомянут как референс модели ("Helium-style"), но **экономический +механизм** Helium — hotspot-производитель (Nova Labs) продавал субсидированное +железо и авансировал HNT под сделки с производителями — нигде не разобран и не +адаптирован. У Tri-Net нет аналога Nova Labs: нет производителя железа, который +взял бы на себя субсидию P203 Mini плат в обмен на будущую эмиссию, и нет +раздела treasury/VC, откуда можно было бы профинансировать subsidy-программу +самостоятельно. Формально это архитектурно чистая позиция («честный старт»), но +практически это означает, что единственный источник капитала на 3 платы сейчас — +личные средства/время фаундера, что не масштабируется на следующие 10-100 узлов +без внешнего финансирования, для которого структура 0% premine/VC/treasury прямо +закрывает стандартный путь (нечего продать инвестору). + +**Evidence:** [`README.md:42,99-112`](https://github.com/gHashTag/tri-net/blob/main/README.md); отсутствие Helium-subsidy разбора подтверждено отсутствием совпадений по `grep -i helium/hotspot/subsidy` в `docs/BENCHMARK_VS_MANET_2026-07-04.md`, `docs/PAPER_DELTA_v0.md`, `docs/_recon/`. + +**Митигация:** явно решить и задокументировать (не обязательно нарушая +0%-premine принцип): (a) grant/hackathon-путь — Hub71+ AI Cohort 20 заявка +(`README.md:169`, дедлайн 2026-08-02) уже является частичным ответом, но нужно +явно прописать, что произойдёт, если грант не будет получен; (b) явный, +опубликованный «bootstrap operator program» — например, first-N-operators получают +повышенный Era-0 reward multiplier без нарушения 0% premine (эмиссия всё ещё идёт +через proof, просто curve скошена в начале) — это ближе к духу проекта, чем +Helium's equity-based subsidy, и стоит явно так и сформулировать вместо тишины. + +--- + +## Находка 8 — bus factor: один человек держит физическое железо, мерж-права и юридические решения + +**Severity: MAJOR** + +`git log` по репозиторию за неделю 06-29→07-05 показывает 3 разных author-имени: +`Vasilev Dmitrii` (20 коммитов), `Perplexity Computer` (5 коммитов, cloud-агент), +`gHashTag` (2 коммита, вероятно локальный macOS-агент под тем же человеком). +Формально «три автора», но фактически — **один человек** (Dmitrii Vasilev / +gHashTag), плюс два AI-агента, которые действуют строго под его надзором. Это +прямо подтверждается собственными правилами онбординга: +[`docs/AGENT_ONBOARDING.md:188-190`](https://github.com/gHashTag/tri-net/blob/main/docs/AGENT_ONBOARDING.md) +— «Не флеши железо... human-only», «Не мержь PR — human-only», и +[`docs/BENCHMARK_VS_MANET_2026-07-04.md` §6](https://github.com/gHashTag/tri-net/blob/main/docs/BENCHMARK_VS_MANET_2026-07-04.md) +— «Cannot flash Zynq… needs Vivado + physical cable», «Cannot procure PA/LNA… +needs a human with a budget», «Cannot merge PRs — human-only per repo policy». + +Это значит: **все hardware-операции, все юридические/регуляторные решения и +единственная точка мержа PR завязаны на одного физического человека**. AI-агенты +могут писать код, тесты, документацию и открывать draft PR — но ни один из +22 PR за неделю не может попасть в `main` без ручного merge этим человеком, и +ни одна из трёх плат не может быть перепрошита без его физического присутствия +с JTAG-кабелем. Если этот человек станет недоступен (болезнь, форс-мажор, смена +приоритетов) — репозиторий продолжит накапливать draft PR (сейчас их уже 8 в +статусе DRAFT по данным `gh pr list`), но ни один не будет смержен, и ни одна +физическая операция с платами не продолжится. + +Проверка onboarding-скорости для нового человека: `docs/AGENT_ONBOARDING.md` +(286 строк) написан для AI-агента, а не для человека-контрибьютора — весь его +контент про git push proxy, mbox handoff, agent-to-agent coordination protocol. +Не найдено ни одного `CONTRIBUTING.md` файла в репозитории (проверено — +отсутствует). Человеку с улицы, который хочет контрибьютить в код (`src/`, +`specs/*.t27`), негде за 10 минут прочитать «как собрать, как тестировать, как +предложить PR» — придётся реконструировать это из README + AGENT_ONBOARDING.md + +AUTONOMOUS.md. + +**Evidence:** `git log --since="2026-06-29" --pretty=format:"%an"` (3 имени, де-факто 1 человек); [`docs/AGENT_ONBOARDING.md:188-190`](https://github.com/gHashTag/tri-net/blob/main/docs/AGENT_ONBOARDING.md); [`docs/BENCHMARK_VS_MANET_2026-07-04.md` §6 «Boundary»](https://github.com/gHashTag/tri-net/blob/main/docs/BENCHMARK_VS_MANET_2026-07-04.md); `gh pr list` (8 open draft PRs на момент аудита); отсутствие `CONTRIBUTING.md` в дереве репозитория. + +**Митигация:** (1) написать отдельный `CONTRIBUTING.md` для человеческих +контрибьюторов (не агентов) — сборка, тесты, code style, PR-процесс, 15-минутный +quick-start; (2) делегировать хотя бы merge-права на docs-only PR (не тронущие +`src/`, `specs/`, hardware) второму доверенному человеку, оставив hardware/`main`-critical +merge за собой; (3) явно записать в issue tracker процедуру «если Dmitrii +недоступен N дней — что происходит с открытыми draft PR» — сейчас такой записи нет. + +--- + +## Что УЖЕ сильно — не трогать + +1. **Честная маркировка `-sim` / `hw` по всей кодовой базе.** [`README.md`](https://github.com/gHashTag/tri-net/blob/main/README.md) + статус-таблица и [`smoke/M1_RESULTS.md`](https://github.com/gHashTag/tri-net/blob/main/smoke/M1_RESULTS.md) + держат жёсткую дисциплину: ни одна непроверенная цифра не выдаётся за + аппаратный факт. Это структурная защита от собственного anchor-bias, и три + зафиксированных anchor-эпизода в [`docs/W6_CODEGEN_AUDIT_2026-07-05.md`](https://github.com/gHashTag/tri-net/blob/main/docs/W6_CODEGEN_AUDIT_2026-07-05.md) + были пойманы именно благодаря этой дисциплине, а не вопреки ей. + +2. **spec-drift-guard CI (68×3 = 204 byte-identity checks).** [PR #38](https://github.com/gHashTag/tri-net/pull/38) + и его расширение — реальный, работающий, воспроизводимый механизм translation + validation, пусть и слабее полной формальной верификации. Это редкий случай, + когда claim в W6.2-аудите «слабейшая, но реальная форма translation validation» + абсолютно точен и не подлежит пересмотру. + +3. **Self-errata культура.** [`docs/W6_CODEGEN_AUDIT_2026-07-05.md`](https://github.com/gHashTag/tri-net/blob/main/docs/W6_CODEGEN_AUDIT_2026-07-05.md) + §«Anchor-bias record» и [`docs/WAVE_REPORT_2026-07-05.md`](https://github.com/gHashTag/tri-net/blob/main/docs/WAVE_REPORT_2026-07-05.md) + Часть 4 «Что не переживёт» — команда сама отменяет свои headline-claims, когда + находит контрдоказательства (`Vec<>` narrative, «C silently accepts», «under + any Zig mode»). Такая структурная привычка редка и должна быть сохранена как + процесс, а не как разовая акция. + +4. **M1 крипто-ядро на реальном железе с воспроизводимым хешем.** [`smoke/M1_RESULTS.md`](https://github.com/gHashTag/tri-net/blob/main/smoke/M1_RESULTS.md) — + два независимых прогона (2026-07-01, 2026-07-04) на разных платах, оба с + sha256 бинарника и RC=0 в логе. Это настоящий hardware-evidence, не + декларация, и единственный пункт всей дорожной карты, который уже прошёл + путь от идеи до `hw`-статуса полностью. + +5. **Признание собственных архитектурных пределов вместо их сокрытия.** Пример — + [`docs/PAPER_DELTA_v0.md:230,253`](https://github.com/gHashTag/tri-net/blob/main/docs/PAPER_DELTA_v0.md): + «byte-determinism… much weaker property today than downstream compilability» + написано в тексте, который идёт в академический препринт, а не спрятано в + internal notes. Это выше стандартной практики большинства DePIN-питчей на + рынке. + +--- + +phi^2 + phi^-2 = 3 diff --git a/docs/WAVE_REPORT_2026-07-05_FULL.md b/docs/WAVE_REPORT_2026-07-05_FULL.md new file mode 100644 index 00000000..d402e8f0 --- /dev/null +++ b/docs/WAVE_REPORT_2026-07-05_FULL.md @@ -0,0 +1,345 @@ +# Wave Report FULL — неделя 2026-06-29 → 2026-07-05 (расширенный, все треки) + +> phi^2 + phi^-2 = 3 + +**Кто говорит**: cloud-агент Perplexity, из sandbox. Пишу для генерала (Vasilev D.) через 7 дней после старта репозитория tri-net на GitHub, за час до pivot'а на M2-M4 hardware track. + +**Скоп этого отчёта**: полная неделя (27 коммитов на main, 22 merged PR, три автора). Дополняет [WAVE_REPORT_2026-07-05.md](WAVE_REPORT_2026-07-05.md) — тот был про W5-W7 (кодогенерация, δ-paper, fuzz baseline), этот покрывает всё: hardware track (M1 hw graduation, board-1, image-bake blocker), discipline chain (PR #43/#45), W7.3 grammar-expansion (#47), §4.5.6 companion (#36 merge), competitor-watch spec (#34). Один канонический документ на неделю с образами по каждой фиче. + +--- + +## Глава 0. Одна картина всей недели + +**Образ**: ювелир, который делал одно кольцо, а на седьмой день собрал ещё три и понял, что дело было не в кольце, а в станке. + +Стартовали в понедельник (07-01) с одной задачей — доказать M1 crypto на реальном железе (X25519 + ChaCha20-Poly1305 на Zynq-7020). Кончили в воскресенье (07-05) с семью артефактами, из которых M1-hw был только один — остальные шесть это инфраструктура: spec-drift-guard (3-backend byte-identity CI), 68/68 SSOT specs, W5 real-bench, W6.1 structural fuzz, W6.2 codegen audit, W7.3 grammar-expansion + три formal-review-правила (no-paste, SHA-advance, external-dep timer). Плюс DePIN pivot: репозиторий из «MANET vendor» переклонился в «reproducibility-first DePIN infrastructure». + +Что произошло на самом деле: **мы потратили 5 из 7 дней на инструментальный слой** (компилятор t27c, три backend'а, differential testing, review discipline). Это **не** отклонение от M2-M4 hardware track. Это его **предусловие**. Без spec-drift-guard любой M2 патч в `wire.rs` может молча разъехаться с `specs/wire.t27`, и paper-претензия «spec-first + reproducible-HDL» становится дырявой. Без review-rules любой M2 approve может уплыть под silent SHA-swap на shared branch и человек утверждает не то, что видел. + +**Дисциплинарный контекст**: три anchor-bias эпизода за неделю (Vec<> narrative, C-silently-accepts, Zig-under-any-mode) и один predicate-confusion эпизод на PR #36 (§4.5.6 companion). Все зафиксированы документально, ни один не остался в скрытом виде. Это отдельный научный результат — не про Rust/C/Zig, а про то, как static-token grep обманывает human judgement в компиляторной работе. + +--- + +## Глава 1. Hardware track — то, что реально произошло на железе + +### 1.1 M1 crypto graduation (два hw datapoint'а) + +**Образ**: врач, который два раза измеряет пульс — не потому, что не верит первому измерению, а потому, что второй пациент важен сам по себе. + +**Datapoint 1** ([`smoke/M1_RESULTS.md`](../smoke/M1_RESULTS.md), 2026-07-01): +- P201Mini · Zynq-7020, 2× Cortex-A9, armv7l +- Static binary `smoke-m1` 534 604 B, sha256 `e5abc335…7290a` +- Cross-built из macOS: `rustup rustc + rust-lld`, `-C target-feature=+crt-static`, target `armv7-unknown-linux-musleabihf` +- Run: X25519 handshake ✅, ChaCha20-Poly1305 AEAD round-trip ✅ (44 B pt → 79 B on-wire), tamper rejected ✅ (Auth error), replay rejected ✅ (Replay error), RC=0. + +**Datapoint 2** ([`smoke/M1_BOARD1_2026-07-04.md`](../smoke/M1_BOARD1_2026-07-04.md), 2026-07-04): +- Второй P201Mini (обозначен как board-1) +- Другой binary sha256 `a17e88e6…` (перерезали после смены toolchain на rustup-stable + `-C linker=rust-lld` — Homebrew rust толкнул нас на false LLD path, откатили) +- Тот же test-set, RC=0 + +**Что было бы, если бы board-2 и board-3 не запустились**: image-bake blocker (см. §1.3) остановил параллельный smoke. Boards 2/3 физически присутствовали, залогинились, но identity collision (IP + hostname коллизии из-за identical Xilinx OUI MAC `00:0a:35:00:01:22`) не дал их запустить одновременно. Ложная гипотеза от 07-04: «runtime MAC-spoof через `ip link set` + `ethtool` разрулит». Реальность (5/5 paths falsified 2026-07-04): не разрулит, потому что stock rootfs — ramfs, все `/etc` изменения испаряются при cold-boot. Единственный путь вперёд — baked-image milestone. + +**Научный контекст**: Zynq-7020 (Xilinx 7-series) — это классический heterogeneous SoC (dual Cortex-A9 hard-core + FPGA fabric). Мы используем только PS (processing system, ARM-часть) для M1. PL (programmable logic, FPGA) не тронут. Это — важный факт для главы 3 (FPGA-attestation): у нас на каждом узле уже есть неиспользуемая FPGA-фабрика с device-DNA (57-bit unique per die, Xilinx UG470 §32) и eFUSE-registers для non-volatile keys. См. [Xilinx UG470 — 7-Series Configuration User Guide](https://docs.amd.com/v/u/en-US/ug470_7Series_Config), device DNA описан в разделе «Device DNA and User eFUSE». + +### 1.2 AD9361 5.8 GHz PHY (radio confirmation) + +**Образ**: настройщик пианино, который дунул в камертон и увидел иглу вибрирующую строго на «ля»-440 — но в закрытой комнате, без публики. + +Один datapoint ([`radio/README.md`](../radio/README.md), 2026-07-01): +- LO 5.8 GHz, sample rate 30.72 MHz, capture 65 536 samples +- FFT peak +0.999 MHz (target 1.0 MHz digital-loopback tone) +- SNR 108.6 dB over noise floor + +**Что это значит и не значит**: 108.6 dB — это цифровая петля (TX → RX через digital loopback внутри AD9361). Это НЕ over-the-air SNR. Реальная эфирная SNR на 5.8 GHz с 20 MHz BW и типичной антенной 6 dBi будет в порядке 20-40 dB при коротких дистанциях. Разница материальная — три порядка. Мы этот факт держим в honest ledger paper §5.7, не в headline. Anchor-bias здесь был бы: цитировать 108.6 dB как «эфирную характеристику», когда это lab-bench digital-loopback число. + +### 1.3 Image-bake milestone (single hard blocker для M2) + +**Образ**: три одинаковых близнеца в одинаковых футболках заходят на день рождения — родственники не могут раздать разные подарки, пока близнецы не разошьют на футболках имена. + +`docs/IMAGE_BAKE_MILESTONE.md` фиксирует единственный hard-blocker M2 real-network smoke: +- Все три P201/P203 Mini имеют identity-image (одинаковый MAC, hostname, IP настройки в `/etc/network/interfaces`, root SSH keys) +- Stock rootfs — ramfs → любые изменения `/etc` теряются при power-cycle +- Falsified 5/5 runtime workarounds (07-04): MAC-spoof через `ip link`, `ethtool`, dhcpcd hooks, systemd-networkd-wait-online, cloud-init none — все не переживают reboot + +Единственный путь: **пересобрать rootfs с persistent identity** (baked image). Это включает: +1. Petalinux или buildroot rootfs generation +2. Уникальный MAC per-board (записать в SD-card overlay) +3. Уникальный hostname per-board +4. Static IP из подсети `10.42.0.0/24` (согласно `mesh_ip(node_id)` в `router.rs`) +5. SD-card image flash procedure (см. [`docs/LOCAL_FLASH.md`](LOCAL_FLASH.md)) + +Пока этого нет, любые M2 претензии — только host-only pure-logic. Что и сделал PR #32 (25 pure-logic tests) — тактическое решение: не сидеть и не ждать image-bake, а тем временем зафиксировать всю логику, которая НЕ требует TUN/UDP/радио. + +### 1.4 M2 pure-logic tests ([PR #32](https://github.com/gHashTag/tri-net/pull/32)) + +**Образ**: скульптор, который до заливки бронзы вылепил каждый узел из воска — если восковой не держит форму, бронза точно провалится. + +25 тестов в [`tests/m2_routing_pure_logic.rs`](../tests/m2_routing_pure_logic.rs) — все host-only, no `/dev/net/tun`, no UDP, no radios. Пять групп: + +1. **TUN allocation math** (`mesh_ip` / `node_of` над `10.42.0.0/24`): full 1..=254 roundtrip, rejection network/broadcast, wrap на out-of-range NodeId. +2. **Wire header boundaries**: все `FrameKind` roundtrip, unknown kind byte reject, truncation at every offset, TTL extremes, `Header::LEN` pin. +3. **HELLO wire boundaries**: 33-byte empty floor, linear length scaling, max n=255, silent truncation of oversized `heard[]`, per-byte truncation reject. +4. **ETX ordering / arithmetic**: deterministic pick under identical ETX, `compute_path_etx` overflow saturation to `+inf`, NaN/inf advertised reject, `force_dead` idempotence, `neighbors()` sorted-by-id. +5. **Cross-module invariant**: HELLO body > `Header::LEN` (нельзя confused). + +**Findings, поднятые самим тестированием**: +- `is_feasible` accepts `+inf` as first metric — асимметрия, любой финитный adver instantly её shadow'ит, поэтому impact bounded, но flagged. +- `Hello::to_bytes` silently truncates `heard[]` at 255 — intentional (u8 length prefix), но caller не может знать. Кандидат на `Result, HelloTooLarge>` future revision. + +**Научный контекст**: это классический defensive-testing подход [John Regehr, «It's Time for a Modern Synthesis in the Compiler Debugging Literature»](https://blog.regehr.org/) — тестировать boundaries ДО первого real integration'а. Если boundaries нестабильны в host-only, они точно нестабильны в M2 stack. + +### 1.5 Три board'а физически на столе (User confirmation 2026-07-04) + +**Образ**: три радиста в бункере, все три микрофона включены, но общий эфир ещё не согласован. + +Три P203 Mini подключены, запитаны, все три ARM-Linux буты в norm. Board-1 прошёл M1 hw smoke. Board-2/3 — идентичные реплики + identity-collision → нужен image-bake. Это база для будущего triangle P2 DEMO GATE (M4). + +--- + +## Глава 2. Инфраструктурный слой — тот, что мы построили за 5 из 7 дней + +### 2.1 T27-first flip — что это вообще + +**Образ**: раньше у нас был чертёж, нарисованный мелом на трёх разных досках; теперь одна доска — оригинал, две — фотокопии, а надзиратель проверяет каждую фотокопию побайтово. + +**Было** (до понедельника): `src/wire.rs` — рукописный Rust, `specs/wire.t27` — второстепенный документ, три backend'а не существовали. + +**Стало** (после `dc1bebb`): `specs/wire.t27` — SSOT (single source of truth), `t27c` компилирует его в: +- `gen/rust/wire.rs` +- `gen/c/wire.c` +- `gen/zig/wire.zig` + +Все три эмиссии — byte-identical при regeneration. CI (spec-drift-guard) проверяет каждый PR, касающийся `specs/`, на предмет `gen/*/X != t27c(specs/X.t27)` — fail и PR не мержится. + +**Пожалуйста, обратите внимание на слово «byte-identical»**. Это НЕ formal correctness. Это НЕ semantic equivalence between backends. Это output-stream determinism единственного codegen'а на трёх выходах. Слабейшая, но реальная форма translation validation. Ближайший научный ориентир — [Xavier Leroy, CompCert](https://xavierleroy.org/publi/compcert-CACM.pdf) — там верифицирована semantics preservation, у нас только output determinism. Мы это признаём в §4.5 paper-delta. + +### 2.2 Wire flip #1 (PR #33, `77a9a49`) — первая волна + +Portированный `wire.rs` → `specs/wire.t27`, добавлен `t27c gen-rust` path. Первый artifact — Rust-only, ещё без C/Zig. Первая попытка также запустила первый anchor-bias эпизод недели: initial framing «bit-shift lowering fails» → real cause «missing ExprCast in t27c parser» (найдено позже, `daeae62`, `880954e`). + +### 2.3 Wire flip #2 (post-audit) — фикс через ExprCast + +После `t27c` получил `Expr::Cast` node — regenerated `wire.rs` без Vec<> hack'ов. `78c29ba` — regenerate с real ExprCast lowering. + +### 2.4 Spec-drift-guard v1 → v2 (PRs #35 → #38) + +- **v1 (PR #35, `f126dca`)**: CI job, который на PR trigger'е делает `t27c gen-rust specs/wire.t27` и `diff gen/rust/wire.rs $(t27c ...)`. Fail → block merge. Только Rust. +- **v2 (PR #38, `dc1bebb`)**: расширили на Zig + C. Три backend'а × 68 spec'ов = 204 drift checks на push. Byte-identity enforcement. + +**Важное отличие от formal verification**: spec-drift-guard не гарантирует correctness. Он гарантирует, что gen/ файлы **не разошлись** с `t27c(specs/*.t27)`. Если сам `t27c` эмиссии bogus код (что и оказалось в W6.2), drift-guard молча пропустит. Он ловит tampering в gen/, не bugs в t27c. + +### 2.5 68/68 SSOT (Волна 5, batch flip) + +За одну ночь (07-04→07-05): 16 commit'ов, все 68 t27-specs пропущены через `t27c` в три backend'а. Одна из самых громких headline недели. + +**Reality-check** (W6.2 audit, глава 2.6): 68/68 SSOT true, но: +- 24 spec-функции имеют stub'ы **в трёх backend'ах с ТРЕМЯ разными policy of failure**: + - Rust: `panic!("todo: X")` — runtime fail + - Zig: `@compileError("todo: X")` — compile-time fail + - C: `// TODO: X` + падение в undefined behavior — silent +- Симметрия 24:24:24 — это НЕ decorative. Это policy divergence под одинаковой оболочкой. То есть один spec функция ведёт себя тремя разными способами при вызове. + +### 2.6 W6.2 codegen quality audit ([PR #42](https://github.com/gHashTag/tri-net/pull/42)) + +**Образ**: три ученика получили одну и ту же задачу, все написали работы одинакового объёма, а учитель обнаружил, что два ученика сдали пустые страницы и один — с ошибками, но всё выглядело как «100% сдали работы». + +Tri-backend compile matrix ([`docs/W6_CODEGEN_AUDIT_2026-07-05.md`](W6_CODEGEN_AUDIT_2026-07-05.md)): + +| Backend | OK | WARN | FAIL | Cross-env verified | +|---|---|---|---|---| +| Rust (rustc 1.93.1 --emit=metadata) | 19 | 0 | 49 | ✅ sandbox | +| C (cc -c -std=c11 -Wall -Wextra) | 2 | 66 | 68 (all fail-hard если -Werror) | ✅ sandbox | +| Zig (zig test --test-no-exec, cross-env only) | 0 | 4 | 64 | ✅ macbook ssdm4 | +| **Cross-backend OK ∩** | — | — | — | **∅ (пусто)** | + +Ни один из 68 модулей не собирается **во всех трёх backend'ах**. W6.2-B (runtime differential testing) — structurally infeasible, cancelled. + +**8-class defect taxonomy** (найдена аудитом): +1. Missing type declarations (E0412 Rust, unresolved import Zig) +2. Missing function declarations (E0425 Rust) +3. Vec<> unparameterised (E0107 Rust, 159 sites) +4. Missing lifetime bounds +5. Missing trait impls +6. Zig `@import` module missing +7. **NEW-CLASS discovered**: 867 `assert(cond, msg)` calls (C uses only 1-arg assert.h — Rust/Zig semantics leaked into C codegen) +8. Bit-shift semantic mismatch (mixed integer widths) + +**Anchor-bias records** (все три эпизода недели): +- **Anchor #1** — «grep Vec<> = главный Rust defect»: static count 132 (5.6%), real E0425 undeclared = 2609 (93%). Static grep пропустил доминирующую ошибку в 16 раз. +- **Anchor #2** — «C silently accepts what Rust rejects»: реально C 2/68 хуже Rust 19/68, оба разделяют один корень (undeclared из t27c codegen), плюс C дополнительно ломается на 867 assert-2arg. +- **Anchor #3** — «Zig fails under any mode»: precise version — 64 hard-fail + 4 soft (lazy analysis может пропустить `@compileError` в dead function под `zig build-obj` без `--test-no-exec`), 0 pass под `zig test --test-no-exec`. + +### 2.7 W7.3 grammar-directed fuzz baseline ([PR #46](https://github.com/gHashTag/tri-net/pull/46), `3272583`) + +**Образ**: старый механик, который заметил, что все его тесты — на одной и той же лестнице, а надо на десяти разных. + +E1 generator: рандомный корпус 1000 t27-модулей из grammar rules, каждый пропускается через `t27c` в три backend'а, затем round-trip test. Baseline: 100/100/100 pass (N=100 initial), затем N=1000, 1000/1000 pass. + +**Что мерит**: acceptance under shared parser. **Что НЕ мерит**: semantic correctness — все три backend разделяют один t27c parser. + +### 2.8 W7.3 grammar-expansion #1 ([PR #47](https://github.com/gHashTag/tri-net/pull/47), `fb23de5`) + +**Образ**: тот же механик добавил в тесты 10-й класс лестниц, которые он раньше не тестировал. + +Первый expansion: collection-typed parameters `[u32; NAMED_CONST]` через `gen_const_decls` + `NAMED_CONST_POOL` (top-10 audit names). Path-confirmation: N=1000 seed 0xC0FFEE, 100/100/0, `t27c gen-rust` на все 1000 = 1924 `[u32; NAMED_CONST]` → 1924 Vec<> exact match (dominant emission pattern сохранился). + +**Диспозиция GLM**: initial BLOCKING (Zig-style syntax mismatch с corpus), revision дала MERGE APPROVED. Merged под user autonomy override («мержи сам»). + +### 2.9 Paper-delta v0 (§4.5 + §4.5.6 companion, [PR #36 merged](https://github.com/gHashTag/tri-net/pull/36), `dd83ea4`) + +**Образ**: художник дописал на подписи к картине «холст 1.2м × 0.8м» — цифры правильные. Потом заметил, что забыл упомянуть, что на холсте есть надрыв 3 см в углу — не отменяет цифру, но её обязательно указать рядом. + +arXiv paper draft «tri-net delta» skeleton с §4.5 empirical bench matrix (spec-first + reproducible-HDL positioning) + §4.5.6 downstream compilability companion. + +**§4.5.6 companion** — это ответ на predicate-confusion anchor эпизод недели: initial framing paper §4.5 «100% cross-backend agreement» технически true для §4.5.1 clean-predicate (byte-determinism из shared codegen), но **omission** — не упомянута compile-success rate из W6.2 (Rust 19/68, C 2/68, Zig 0/68, cross ∅). Не fabrication, а omission. §4.5.6 добавляет companion статистику (26 insertions, 0 deletions, все прежние claims сохранены). + +Это — **Anchor #5** записан в agent memory: predicate-confusion. Разница между «применил compile-success predicate к byte-determinism claim» и «численный factivity error» — материальная. Fix через companion, а не через «correct false numbers». + +### 2.10 Три formal review-правила ([PR #43](https://github.com/gHashTag/tri-net/pull/43), [PR #45](https://github.com/gHashTag/tri-net/pull/45)) + +**Образ**: три правила игры, все три записаны на стене над столом — можно проверить в любой момент, кто нарушил. + +1. **No-paste-review rule** (PR #43): approve только против committed текста; в approval цитировать SHA. Против уплывающего draft'а approve невалиден. +2. **SHA-advance rule** (PR #45): approve связывается с cited SHA; branch advance требует explicit `Re-reviewed at : delta `. Silent SHA-swap запрещён. +3. **External-dep timer rule** (PR #45): PR, заблокированный внешней зависимостью, должен иметь terminal-event triggers + backstop timer (default 14 дней). Не мержим и не забываем — блокируем формально с deadline. + +Applied 4× total across #44/#46/#47/#36 в течение недели. Из pending state в шабашки перешли — сейчас это hard-обязательные правила. + +### 2.11 Competitor-watch spec ([PR #34](https://github.com/gHashTag/tri-net/pull/34), `91a5b63`) + cron `64822c1c` + +**Образ**: сторож в маяке, который каждую пятницу в 09:00 бангкокского времени включает бинокль на 5 минут, смотрит на 10 определённых кораблей + 4 научных полки, и записывает в судовой журнал только то, что достойно записи. Без событий — тишина. + +Спецификация в [`docs/COMPETITOR_WATCH_SPEC.md`](COMPETITOR_WATCH_SPEC.md) — портируемый протокол: +- 10 продукт-запросов (TERASi RU1, Elistair, AT&T Flying COW, Persistent MPU5 Wave Relay, Rajant Kinetic Mesh, Doodle Labs Mesh Rider, Fraunhofer IIS UASFeed, Meshmerize 8devices, goTenna Pro X2m, World Mobile HAPS) +- 4 академических запроса (mesh routing FANET, ternary NN inference, silicon-bound DePIN, Noise protocol IoT) +- Relevance filter: 6 триггеров + exclusion list +- Source discipline: Reddit/X/LinkedIn никогда не цитируются; преследуем first-party +- Filing: draft PR на `feat/competitor-watch-`, ярлык `documentation,drone-mesh` +- Silence-on-nothing: если 0 находок — no file, no branch, no notification + +Executor: cron id `64822c1c` (Fridays 02:00 UTC = 09:00 Asia/Bangkok). Ближайший запуск: 2026-07-10 (пятница). + +--- + +## Глава 3. DePIN pivot (07-04) — стратегический сдвиг + +### 3.1 Что изменилось + +**Образ**: физик, который переключил PhD с квантовой оптики на quantum sensing — не потому, что оптика неинтересная, а потому, что sensing получает 10× больше грантов. Все инструменты остались те же — интерференция, лазеры, детекторы. Только позиционирование другое. + +`c66d7cc` — README pivot. Раньше: «tri-net = MANET vendor для drone-mesh». Теперь: «tri-net = reproducibility-first DePIN infrastructure с mesh-radio arm'ой». + +### 3.2 Четыре плеча supply-side (WAVE_DEPIN_2026-07-04.md) + +Одна P203 Mini коробка = один DePIN узел с четырьмя arm'ами: + +| Плечо | Что делает | proof-payload | chip sigs | +|---|---|---|---| +| Transport | mesh-relay bandwidth | (from, to, bytes, ts_start, ts_end) | 2-of-3 Phi | +| Compute | ternary edge inference (BitNet) | (model_hash, input_hash, output_hash, ops) | 3-of-3 Phi+Euler+Gamma | +| Coverage | 5.8 GHz PoC beacon challenge-response | (challenger, responder, witness, rssi, tof) | 3-of-3 cross-die φ | +| Sensor | RF spectrum atlas + GPS-jam detection | (snapshot_hash, gps_time, location_hash) | 1-of-3 any | + +Все четыре оседают в `MiningPool.claimReward()` — 7 проверок, ни одна не обходится. TRI supply 3^27, 0% premine, 9 halvings 2026-2066. + +### 3.3 Ключевая уязвимость pivot'а (открытый вопрос, ведёт к главе 5) + +**«Compute» arm'а требует 3-of-3 Phi+Euler+Gamma sigs. Silicon TT SKY26b tape-out — 2026-12-16.** Между сегодня (07-05) и tape-out'ом ~24 недели. Плюс ~12-16 недель на bring-up и первый live BitNet-ternary benchmark. Итого ~40 недель до полноценного Compute-arm proof'а. + +**Что делать 40 недель**? Здесь и появляется идея «Proof of FPGA» — использовать неиспользуемую FPGA-фабрику (Zynq-7020 PL) как interim identity/attestation source, пока silicon не приехал. Об этом — глава 5. + +### 3.4 arXiv δ-paper (PR #26, `6f508db`) + +**Образ**: научная работа, которая описывает не «наш продукт», а «дыру в чужих продуктах». + +`docs/paper-delta-v0` — draft статьи «MANET vendor-field auditability gap»: MPU5 / Rajant / Silvus все публикуют benchmarks, но ни один не публикует SSOT-код с byte-drift CI. Tri-net этот gap закрывает (spec-drift-guard). Позиционирование: не «мы быстрее», а «мы аудируемее». + +--- + +## Глава 4. Дисциплинарные результаты (научные, не про Rust/C/Zig) + +### 4.1 Пять anchor-эпизодов недели + +**Образ**: пятикратный отчёт о том, как glaza обманывают. Каждый раз мы шли в одну сторону, потом останавливались, откручивали, шли в другую. + +1. **Anchor #1** (grep Vec<>): static-token grep ≠ compiler verdict. 16× underestimate. +2. **Anchor #2** (C silently accepts): оба tool показывают проблемы разных типов, root cause один и глубже обоих. +3. **Anchor #3** (Zig under any mode): overclaim в компиляторных verdict'ах — особый вид bias. «under any mode» ≠ «under mode X». +4. **Anchor #4** (corpus-scope error, PR #47): workspace-wide grep включил `../t27/specs/`, должен был `tri-net/specs/` only. Fixed at revision. +5. **Anchor #5** (predicate-confusion, PR #36): applied compile-success predicate к byte-determinism claim. Fix через companion §4.5.6, не через «correct false numbers». + +**Ключевая формулировка** (это уже не про эту неделю, это на весь проект): статические indicators (grep, LOC, file count) — это **не** substitute для dynamic verdict (compiler, test suite, on-device run). Даже приближённого. И это правило применимо не только к нашему codegen'у — оно применимо к любому inference'у из static evidence в dynamic behavior. + +### 4.2 Три formal rules как долгосрочный infra + +- `no-paste-review` — рекурсивно применимо к любому review-workflow. +- `SHA-advance` — рекурсивно применимо к любому shared-branch flow. +- `external-dep timer` — рекурсивно применимо к любому blocking-on-upstream PR. + +Все три уже applied 4× за 3 дня. Это infra не устарела через неделю. + +--- + +## Глава 5. Что готово для следующего лупа — pivot в M2-M4 hardware + FPGA-monetization + +**Что мы имеем в конце этой недели**: + +- ✅ M1 crypto на реальном железе (2 board datapoints) +- ✅ 3 board'а физически подключены +- ✅ AD9361 5.8 GHz радио с digital-loopback verified +- ✅ 25 M2 pure-logic тестов (host-only, boundaries) +- ✅ 68/68 t27 SSOT + 3-backend byte-drift CI +- ✅ Три formal review-правила applied +- ✅ Bench harness с real numbers (не спекуляции) +- ✅ DePIN pivot README + four-arm whitepaper +- ✅ Competitor-watch protocol + cron +- ✅ arXiv paper draft §4.5 + §4.5.6 companion + +**Что заблокировано**: + +- ⛔ M2 real-network smoke — hard blocker image-bake (persistent identity) +- ⛔ M3 iperf3 over 2 hops — downstream image-bake +- ⛔ M4 triangle P2 DEMO GATE — downstream image-bake +- ⛔ M5 self-heal convergence — downstream + spec still `-sim` +- ⛔ Compute arm proof — silicon SKY26b tape-out 2026-12-16 (+24 недели) + +**Открытый исследовательский вопрос** (пивот следующего лупа): + +> Можно ли использовать неиспользуемую FPGA-фабрику Zynq-7020 (уже стоит на каждом узле) как **interim attestation source** для DePIN identity — до появления silicon SKY26b? Если да, это: +> - Сокращает time-to-first-DePIN-node с 40 недель до сегодня +> - Даёт цитируемое «Proof of FPGA» — новая категория PoPW +> - Открывает второй монетизационный канал: **FPGA-bitstream attestation as a service** + +Ответ на этот вопрос — задача следующего Wave-лупа. См. отдельные документы: +- `docs/W7_WEAK_POINTS_STRUCTURAL.md` — что структурно слабо в текущей работе +- `docs/W7_FPGA_LITERATURE.md` — научная база (FPGA-attestation, PUFs, Proof of Physical Work) +- `docs/M2_M4_FPGA_DECOMPOSED_PLAN.md` — план на M2-M4 + FPGA-proof параллельный трек + +--- + +## Глава 6. Reproducibility — как проверить каждое утверждение этого отчёта + +Все цифры имеют либо script (reproducible в sandbox), либо PR (linked SHA), либо cross-env marker (macbook ssdm4 zig). + +| Цифра | Метод | Reproducibility | +|---|---|---| +| M1 binary size 534604 B | `ls -la target/armv7-unknown-linux-musleabihf/release/smoke-m1` | На host после `cargo build --release --target=...` | +| M1 sha256 e5abc335…7290a | `sha256sum` on device 2026-07-01 | one-time datapoint | +| M1 board-1 sha256 a17e88e6… | `sha256sum` on board-1 2026-07-04 | one-time datapoint | +| AD9361 SNR 108.6 dB | `radio/README.md` script | Digital loopback, `capture_65536_samples.py` | +| Rust 19/68 OK | `bash scripts/audit/rust_compile_sweep.sh` | sandbox verified | +| C 2/68 OK | `bash scripts/audit/c_compile_sweep.sh` | sandbox verified | +| Zig 0/68 empirical | `zig test --test-no-exec` | cross-env (macbook ssdm4, zig 0.15.2) | +| W5 bench 1.2μs / 8% CoV | `cargo bench --package wire` | sandbox verified | +| W7.3 fuzz 1000/1000 | `python scripts/fuzz/run_fuzz.py --n 1000 --seed 0xF1F1F1F1` | sandbox verified | +| W7.3 expansion 1924 Vec<> | see PR #47 path-confirmation section | sandbox verified | +| 68/68 SSOT | spec-drift-guard CI on every PR | CI verified per-PR | +| Applied review rules 4× | grep merged PR bodies for `Reviewed at :` | GitHub API | + +--- + +## Глава 7. Одна фраза для нового читателя + +> Мы за неделю превратили одну недоказанную crypto-функцию в семь bedrock артефактов (M1-hw × 2, 3-backend byte-drift CI, 68 SSOT specs, W5 bench, W6.1 fuzz, W6.2 codegen audit, W7.3 grammar-expansion + 3 review-rules), закрыли **пять** anchor-bias эпизодов документально, сделали DePIN pivot и открыли новый исследовательский вопрос — «Proof of FPGA как interim до silicon SKY26b». Плюс cron для weekly competitor-watch. Хардварная стена — image-bake milestone; ломается на следующем лупе. + +phi^2 + phi^-2 = 3 diff --git a/smoke/M2_LOOPBACK_SMOKE_RESULTS.md b/smoke/M2_LOOPBACK_SMOKE_RESULTS.md new file mode 100644 index 00000000..915a59fd --- /dev/null +++ b/smoke/M2_LOOPBACK_SMOKE_RESULTS.md @@ -0,0 +1,98 @@ +# M2 loopback smoke — sandbox results 2026-07-05 + +> phi^2 + phi^-2 = 3 + +**Что запущено**: `smoke/m2_loopback_smoke.sh` — 3 узла `trios_meshd` через UDP на loopback (127.0.0.1:5011/5012/5013), stagger 100ms между стартами, duration 10 с. + +**Trust class**: `-sim` (host loopback, sandbox), НЕ hardware M2 datapoint. Ничего радио-эфирного. Ничего на реальных P203 Mini. Это pre-flight sanity check daemon кода перед flash на 3 коробки. + +**Reproduction**: +```bash +cargo build --bin trios_meshd --release +DURATION=10 ./smoke/m2_loopback_smoke.sh +``` + +## Observed behaviour + +Три daemon процесса стартовали чисто, все три остались RUNNING в конце теста. HELLO периодические записи в лог каждые ~300 мс (по `HELLO_MS = 300` в `src/bin/trios_meshd.rs:26`). + +**ETX table state @ 10s**: + +| Node view | 11 | 12 | 13 | +|---|---|---|---| +| node 11 sees | — | inf | inf | +| node 12 sees | inf | — | 1.00 | +| node 13 sees | inf | 1.00 | — | + +**Аномалия**: node-11 не слышит никого; никто не слышит node-11. **Асимметрия**. + +## Root cause — sandbox-testability bug, not hardware defect + +Найден в `src/bin/trios_meshd.rs:125,138,168`: + +```rust +let mut ip_to_id: HashMap = HashMap::new(); +... +ip_to_id.insert(addr.ip(), *pid); // insert overwrites on IP collision +... +let from = match ip_to_id.get(&src.ip()) { // lookup by IP only + Some(f) => *f, + None => continue, // rejects unknown IP +}; +``` + +На loopback все три узла имеют `127.0.0.1` как source IP. `ip_to_id.insert(127.0.0.1, ...)` перезаписывает — последний peer occupies слот. Rest — silently dropped через `None => continue`. + +Node-11 стартовал первым (`sleep 0.1` stagger), к моменту его `ip_to_id` build'а peers 12/13 ещё не имеют bind'а — но фиксированные `addr` в config'е указывают на 127.0.0.1:5012 и 127.0.0.1:5013, у обоих `src.ip() == 127.0.0.1`. Второй `insert` перезаписал первый. Peer-12 lookup `src.ip() == 127.0.0.1` возвращает id 13 (последняя запись), а если src port 5012 — router думает это от peer 13. + +Плюс node-11 не занял слот в `ip_to_id` node-12 и node-13, потому что у них тоже коллизия — их последний insert конфликтует между 11 и 12 (для node-13) или между 12 и 13 (для node-12). + +## Implication + +**Hardware M2 не заблокирован**: на реальных P203 Mini каждая коробка имеет уникальный IP `10.42.0.1..3` из baked-image milestone. Проблема loopback-only. + +**Sandbox testability заблокирована**: без фикса мы не можем M2 smoke в CI/sandbox между flash-циклами. Каждое изменение в daemon требует физического board flash для теста, что медленно. + +## Fix — one-line change to key by SocketAddr not IpAddr + +Изменить `ip_to_id: HashMap` на `addr_to_id: HashMap` и lookup по `src` целиком, не `src.ip()`. Это будет корректно для loopback (порт различает) и корректно для hardware (у каждой P203 Mini уникальный IP и обычно фиксированный порт 5000). + +Draft PR — в следующем шаге текущего плана (M2.0-M2.2 sandbox code prep). + +## Что этот smoke уже доказал + +1. **daemon стартует без crash** на loopback UDP transport (три instance параллельно) — release build 9.75s cold, RC=0 на всех трёх. +2. **HELLO discovery работает между двумя из трёх узлов** (12↔13 converge to ETX 1.00 — тавтологично one-hop через loopback без потерь, но это baseline). +3. **ETX table в consistent state** после ~5-10 HELLO rounds. +4. **Найдена реальная testability проблема ДО flash на hardware** — это точная цель такого pre-flight smoke. + +Ни один из четырёх пунктов не требовал реального железа. Это добавляет **cargo test** уровня уверенности к M2, оставляя hardware smoke как ортогональное подтверждение. + +## Log artifact + +Полные логи per-node сохранены в `/tmp/m2-loopback-*/node{11,12,13}.log` (ephemeral в sandbox). + +## Next steps + +1. Draft PR `feat/m2-daemon-loopback-fix` — one-line изменение `ip_to_id → addr_to_id`. +2. Extended smoke script проверяющий full ETX symmetry (все три узла должны видеть остальных двух после N sec). +3. После fix — тот же harness должен показать 3×3 полную матрицу sub-2.0 ETX без inf. +4. Затем — flash на реальные board'ы (M2.0 image-bake blocker) и повторить с уникальными IP. + +## Sha of binary tested + +Не берётся в этот отчёт как cryptographic-grade attest (это ephemeral sandbox build), но: + +``` +$ sha256sum target/release/trios_meshd +``` +записывается автоматически в log через harness если требуется — сейчас без него, чтобы не переусложнять runbook. + +## Honesty ledger + +- Всё выше — sandbox (Perplexity Computer isolated Linux VM, 2 vCPU, 8 GB RAM, x86_64), НЕ armv7l ARM. +- Ничего в этом smoke не касалось `/dev/net/tun`, реального радио, реальной P203 Mini. +- HELLO 300ms и ETX 1.00 — консистентны с loopback zero-loss, НЕ с over-the-air 5.8 GHz. +- `-sim` marker обязателен на всех цифрах из этого файла. + +phi^2 + phi^-2 = 3 diff --git a/smoke/m2_loopback_smoke.sh b/smoke/m2_loopback_smoke.sh new file mode 100755 index 00000000..ac971357 --- /dev/null +++ b/smoke/m2_loopback_smoke.sh @@ -0,0 +1,78 @@ +#!/usr/bin/env bash +# M2 loopback smoke — sanity-check trios_meshd UDP transport on a single host. +# +# 3 nodes on loopback (127.0.0.1:5011-5013), fully connected topology. +# All traffic stays inside the machine — no radios, no external network. +# This is *not* a hardware M2 datapoint (still `-sim`), but it validates that +# daemon startup + HELLO discovery + ETX table code path runs end-to-end +# without segfaults or config errors before we push to the 3 boards. +# +# Anchor: phi^2 + phi^-2 = 3 + +set -euo pipefail + +BIN="${BIN:-./target/release/trios_meshd}" +LOGDIR="$(mktemp -d /tmp/m2-loopback-XXXX)" +DURATION="${DURATION:-8}" + +if [[ ! -x "$BIN" ]]; then + echo "FATAL: $BIN not found. Run: cargo build --bin trios_meshd --release" >&2 + exit 1 +fi + +cleanup() { + echo "[cleanup] killing daemons..." + kill $(jobs -p) 2>/dev/null || true + wait 2>/dev/null || true +} +trap cleanup EXIT + +for ID in 11 12 13; do + CFG="$LOGDIR/node${ID}.cfg" + LOG="$LOGDIR/node${ID}.log" + { + echo "id $ID" + echo "listen 127.0.0.1:50${ID}" + for PEER in 11 12 13; do + [[ "$PEER" == "$ID" ]] && continue + echo "peer $PEER 127.0.0.1:50${PEER}" + done + } > "$CFG" + "$BIN" "$CFG" > "$LOG" 2>&1 & + echo "[start] node $ID pid=$! log=$LOG" + sleep 0.1 # tiny stagger — avoid race where node-N starts before peer sockets bind +done + +sleep "$DURATION" + +echo "" +echo "=== per-node log summary (last 12 lines) ===" +for ID in 11 12 13; do + echo "--- node $ID ---" + tail -12 "$LOGDIR/node${ID}.log" || echo "(empty)" + echo +done + +echo "=== HELLO / neighbor discovery counts ===" +for ID in 11 12 13; do + HELLO_TX=$(grep -c "HELLO" "$LOGDIR/node${ID}.log" 2>/dev/null || echo 0) + NEIGH=$(grep -c -E "neighbor|added-link|link-up" "$LOGDIR/node${ID}.log" 2>/dev/null || echo 0) + echo "node $ID: HELLO-lines=$HELLO_TX neighbor-events=$NEIGH" +done + +echo "" +echo "=== return codes ===" +for ID in 11 12 13; do + PID=$(pgrep -f "trios_meshd.*node${ID}.cfg" 2>/dev/null || true) + if [[ -n "$PID" ]]; then + echo "node $ID: RUNNING (pid $PID)" + else + echo "node $ID: EXITED prematurely — check $LOGDIR/node${ID}.log" + fi +done + +echo "" +echo "logs preserved at: $LOGDIR" +echo "smoke duration: ${DURATION}s" +echo "" +echo "phi^2 + phi^-2 = 3"