Proof of Antiquity makes an unusual claim about network identity: physical hardware characteristics and age can matter to participation. The useful way to evaluate that claim is not to repeat a multiplier table. It is to design tests that can fail.
This checklist focuses on reproducibility. It separates source inspection, local hardware evidence, VM controls, public network observations and economic conclusions so that a successful result in one layer is not silently promoted into proof of another.
1. Define the question
“Does RustChain work?” is too broad. Better questions include: Does the current detector distinguish my physical laptop from a VM? Are results stable across repeated runs? Does the same physical machine retain a consistent identity after reboot? Does a known VM trigger anti-emulation signals? Can I reproduce a claimed antiquity category from the current source?
2. Pin the implementation
Use the canonical repository and record the commit:
git clone https://github.com/Scottcjn/Rustchain.git
cd Rustchain
git rev-parse HEAD
git status --shortNever compare two test runs if the detector changed between them without noting that fact.
3. Create an environment sheet
Record CPU model, architecture, OS/kernel, virtualization status, Python version, firmware information when relevant, and whether the machine is physical, VM, container or compatibility layer. Do not infer physical status from the detector you are testing—that would be circular.
uname -a
python3 --version
lscpu 2>/dev/null | head -404. Run read-only or dry-run paths first
Check the miner’s current help. Use documented dry-run behavior where available and capture raw output. Do not enroll or mine merely to test a local fingerprint.
5. Repeat measurements
Timing signals are noisy. Run multiple trials under similar conditions, then under changed load. A detector that flips categories every run is operationally different from one that is stable. Save all results, not just the best-looking one.
6. Add negative controls
Run the same version inside a VM you know is virtual. If possible, compare multiple hypervisors or containers. The point is not to “beat” the system on production infrastructure; it is to measure false acceptance in a controlled environment.
7. Add diverse physical controls
Test a normal modern x86 machine and, if you legitimately have access, unusual physical hardware. Old machines expose compatibility assumptions. Missing thermal sensors or unusual timer behavior should not automatically be interpreted as deception.
8. Separate detection from weighting
First evaluate whether the system classifies identity plausibly. Only then inspect antiquity weighting. Otherwise a multiplier can distract from a broken identity boundary.
9. Inspect public state independently
Use documented public endpoints at rustchain.org for read-only observations. Record timestamps and exact responses. If you later enroll a test machine, verify its public representation independently rather than trusting only the miner console.
10. Report failures precisely
A good report includes commit, environment, exact command, expected result, actual result and sanitized raw output. “VM detection broken” is weak. “Known KVM guest on kernel X, commit Y, three runs all classified physical; here are outputs” is actionable.
11. Do not overclaim environmental benefits
Hardware reuse can reduce waste when it extends useful life, but old computers can consume more electricity per unit of conventional compute. Measure the actual workload and lifecycle assumptions. Proof of Antiquity is an incentive design, not automatic carbon accounting.
12. Do not overclaim Sybil resistance
Physical identity can increase the cost of cloning identities, but an operator can own many physical machines. The experiment changes the resource required for influence; it does not make concentrated ownership impossible.
13. Keep economic observations separate
A technically interesting detector does not imply a token is valuable or mining is profitable. Record network rewards as protocol observations and avoid extrapolating income from a short test.
14. Publish reproducible evidence
When sharing results, remove secrets but preserve enough detail for another person to repeat the test. Include source links and corrections when the implementation changes.
A useful outcome can be “it failed”
Experimental systems improve when tests are designed to falsify assumptions. A reproducible false positive, false negative or unstable fingerprint is not a wasted test; it is exactly the kind of evidence a hardware-attestation project needs.
That is the standard worth applying to Proof of Antiquity: measured behavior, pinned source, explicit controls and modest conclusions.
Disclosure: prepared with AI assistance for a paid RustChain ecosystem content bounty. Technical claims should be checked against the current public repositories; no profitability or token-price claim is made.
0 comentarii