这些年我一直在帮一些远程工作团队搭建协作工具见过了太多数字游民被“你怎么证明你刚才真的在工作”这种问题卡住的情况。客户想看实时进度平台要审核工时签证申请需要居住地证明可一个人带着笔记本满世界跑的时候传统那套“打卡、GPS定位、公证处盖章”的办法几乎全都不好用。后来我干脆认真设计了一整套基于区块链的“在场证明”方案今天这篇就当是一份白话版技术白皮书把思路、架构、合约实现和踩坑记录都摊开讲。先给不熟悉这个领域的朋友点明核心这里说的“在场证明”不是要给数字游民做精确到米的物理定位而是要在某个时间点上由一个可信的数字身份发出一种可验证、不可篡改、可选择性披露的信号——说清楚“某个身份确实在某个时间点针对某份工作发生了某次可确认的活动”。区块链在这里的角色是一个公共见证者。它不关心你在咖啡店还是青旅它只负责把“那一刻发生过什么”变成谁都无法抵赖的客观事实。1. 在场证明到底证明什么需求拆解与方案选型1.1 数字游民的真实痛点先看一个典型场景。某位自由职业者人在泰国清迈远程给欧洲一家电商公司做数据分析。项目合同约定每个月要完成40小时的支持服务客户怎么确认这40小时确实发生了总不能开视频对着屏幕录40个小时吧。更麻烦的是续签某类居留签证时当地机构要求提供“实际停留在本地”的证据而数字游民往往没有租房合同、没有工资单只有一堆入境章和零散的银行流水。我整理过这类群体的真实需求无非是三个层面对客户和雇主需要可信的工作时长与交付节点证明而不是自说自话的截图。对签证和财税机构需要能证明“某人某段时间身处某地”且有一定规律的在场痕迹而不是凭空声明。对数字游民自己需要一个既能证明自身活动又不必把全部行程、聊天记录、工作内容都甩给对方的轻量方案。这三个需求放到一起难点出现了传统方案要么过度暴露隐私要么容易被伪造要么成本高到只有线下机构才用得起。区块链的分布式账本恰好提供了一种“第三方见证”的替代品它有公信力却不需要一个中心化平台来记账。1.2 区块链并非用于“定位”而是用于“见证”一定要纠正一个误区区块链的天然属性是存证和共识不是地理定位。链上记录的是经过哈希处理的证据指纹而不是“北纬18.79度东经98.98度”这种原始坐标。定位数据属于个人敏感信息直接裸露上链既不安全也没有必要。我们真正需要的是“见证链”数据在本地生成通过密码学方法压缩成一个哈希值连同时间戳一起写入区块链。需要验证时只需要拿出原始数据和链上哈希做一次比对。这个过程很像把一封信用火漆封好再寄出去邮局在信封上盖了章。邮局并不知道信的内容但能证明这个密封状态在特定时间之前已经存在。所以这套系统应该被设计成一个“时间戳与完整性证明层”而不是“跟踪系统”。这样既能满足客户对工时证据的核查需求也能保护数字游民具体在哪张桌子、哪个插座工作这类细节不被公开。1.3 与其他方案对比在决定用区块链之前我把市面上已有的方法全部摆在一起看过一遍方案核心机制优点致命缺陷中心化工时软件服务端记录登录和活动简单直接报表好看平台方可以改数据技术团队跑路证词就没了GPS打卡手机定位上传直观显示位置可伪造隐私暴露极端严重信号漂移频繁公证处现场证明人员到场核验法律效力强成本高数字游民不可能每换一个国家就去公证区块链哈希存证本地生成证据指纹链上时间戳锚定不可篡改隐私可控全球可达需要一定的技术门槛和链上费用当时做完这个对比表基本就确定了方向用去中心化身份DID作为人的唯一标识用可验证凭证VC作为工作合约的授权背书用链上哈希时间戳作为事件的最终锚点。这三样东西叠加起来才是一个完整的“在场证明”体系。2. 核心设计一条轻量级的在场证明协议2.1 身份层DID 与可验证凭证身份是整个方案的根基。不能用钱包地址裸奔因为一个钱包地址看不出“你是谁”也不能用身份证号上链因为那是个人隐私。我采用了 DID去中心化标识符作为主体身份每个数字游民在本地生成一对公私钥公钥派生出一个 DID 字符串私钥保管在手机或电脑的安全模块中。这个 DID 本身是一串看起来没有规律的字符串比如did:key:z6Mk...但它可以和现实身份建立可验证的关联客户可以签发一张可验证凭证声明“某 KYC 验证过的个人身份其 DID 为 xxx”这张凭证用客户自己的私钥签名。未来需要向某机构证明“我是我”时只需要用私钥出示这件由可信方签发的凭证再把链上签到记录对应起来就能形成完整证据链。这里的关键是DID 并不绑定真实姓名它只是一个密码学标识。真实身份与 DID 之间的映射关系掌握在用户和信任方手里链上永远只有一串字符串。这就解决了“到底是谁在打卡”的问题。2.2 数据采集基于口令与定时签到的双因子机制确定身份后下一个问题是怎么证明“这个 DID 所代表的真人此刻正在电脑前”纯 App 打卡可以交给别人代操作。所以我把当场签到设计成了双因子验证第一因子是解锁私钥第二因子是动态口令。动态口令来自一个独立的本地服务每 30 秒刷新一次六位数字。这个口令与当前时间、DID 的私钥种子、以及当日工作会话 ID 绑定在一起。签到时客户端必须同时提供口令和一个针对待签数据结构生成的 ECDSA 签名。动态口令保证了“这台设备上的真人正在看着屏幕”私钥签名保证了“该 DID 确实授权了这次签到”。有人问动态口令截获怎么办实际上 30 秒的口令有效期极短加上签名私钥从不离开本地安全存储远程截获到的只能是哈希和签名无法反向制作签到凭证。这样就把“代打卡”的难度从“借手机用一下”提升到了“拿到设备并破解安全芯片”的级别。2.3 锚定层哈希上链与时间戳服务双因子机制完成后客户端会把原始签到记录组织成一个 JSON 对象具体包含会话 ID由服务端生成的随机 UUIDDID用户去中心化身份活动类型例如“代码审查”“撰写文档”“会议讨论”工作内容哈希对当前正在处理的文件片段或任务摘要哈希签到时间本地时间稍后需要与链上时间戳比对设备指纹哈希防止同一设备滥用这些字段不直接上链而是先拼装成一个规范化的字符串计算 SHA-256 哈希。这个哈希连同用户签名、动态口令验证标识一起发送到链上智能合约。链上合约只负责一件事读取用户传入的哈希和签名检查该 DID 是否处于“已注册”状态校验签名有效后把keccak256(哈希, 区块时间戳, 调用者)存入一个ProofRecord结构体的数组中。每个记录会附带一个递增序号代表这是这个 DID 的第几次证明。2.4 隐私保护零知识证明的可选扩展基础方案里链上只存哈希不存原始数据已经能应对大部分隐私诉求。但为了应付更苛刻的验证场景比如需要向机构证明“我在某月确实每天有工作记录但不想泄露具体项目内容”我预留了零知识证明ZKP的接口。具体思路是用户把一段时间内的所有签到原始数据作为私有输入机构要求验证的条件作为公共输入电路计算后生成一个 ZK 证明。链上或者离线验证者只验证这个证明结果只有“满足条件”或“不满足条件”不暴露任何具体时间点、哈希和内容。这个方案我到现在也没有全量落地因为零知识证明的开发成本和审计成本都很高。但架构上需要预留这个能力否则将来用户面对“请证明过去六个月有足够工作时长”这类需求时会面临要么全给、要么没有的两难选择。3. 合约与流程实现从签到到生成证明3.1 智能合约接口设计为了让在场证明协议真正可复现我写了一份精简版 Solidity 合约。它不做复杂的业务逻辑只聚焦在身份注册、签到和链上查询三件事上。核心接口如下// SPDX-License-Identifier: MIT pragma solidity ^0.8.20; contract PresenceStamp { struct ProofRecord { bytes32 payloadHash; // 证据包哈希 uint256 timestamp; // 区块时间戳 bytes32 sessionId; // 会话唯一标识 uint256 sequence; // 该身份的递增序号 } mapping(address bool) public registered; mapping(address ProofRecord[]) private _proofs; event ProofRegistered( address indexed subject, bytes32 indexed sessionId, uint256 indexed sequence, uint256 timestamp, bytes32 payloadHash ); function register(address subject) external { // 由管理员或者用户自己调用初始化身份状态 require(!registered[subject], already registered); registered[subject] true; } function stamp(bytes32 sessionId, bytes32 payloadHash) external { require(registered[msg.sender], caller not registered); uint256 seq _proofs[msg.sender].length; _proofs[msg.sender].push( ProofRecord(payloadHash, block.timestamp, sessionId, seq) ); emit ProofRegistered( msg.sender, sessionId, seq, block.timestamp, payloadHash ); } function getProofCount(address subject) external view returns (uint256) { return _proofs[subject].length; } function getProof(address subject, uint256 index) external view returns (ProofRecord memory) { require(index _proofs[subject].length, index out of range); return _proofs[subject][index]; } }注意stamp()函数里没有用签名校验因为msg.sender本身就是钱包地址的哈希标识只有持有私钥的账户能发起交易。如果使用 DID 与合约地址分离的方案则需要在链下对交易参数额外签名并在链上通过ecrecover校验 DID 的签名。那份实现更长但原理相同。3.2 一次完整的在场证明生成流程从逻辑上讲整个流程可以拆成五个阶段。阶段一环境初始化。数字游民在本地生成 DID 和对应的链上账户调用register()完成身份接入。这个步骤只需要做一次之后所有签到都不需要重复注册。阶段二开始工作时主动发起会话。客户端向本地定时器要一个动态口令同时生成会话 ID并把当前工作内容的摘要计算成payloadHash。此时还没有产生链上交易。阶段三将口令、会话 ID、payloadHash 组合计算一次本地签名。然后把交易发给链上节点调用stamp()。阶段四等待超过 2/3 的区块确认后客户端把链上交易哈希、区块高度、事件日志中的sequence和timestamp存回本地证据包。这一步非常关键因为后续做验证时不能只拿链上交易哈希还要把链下数据归档好。阶段五客户或机构需要核验时先拿到用户提供的原始 JSON 证据包重新计算 SHA-256 哈希再把链上记录的payloadHash和事件中的时间戳取出来比对。如果完全一致并且时间戳落在双方约定的工作时段内这次“在场证明”就算被成功验证了。3.3 链下数据结构与证据包链上只是一个索引真正有说服力的是链下证据包。我在实际设计中将证据包设计成了下面这种目录结构presence-proof/ 2025-06-20/ session-8f7a.json session-8f7a.sig session-8f7a.tx.json 2025-06-21/ session-91b3.json session-91b3.sig session-91b3.tx.json一个会话中的三个文件分别承载不同职责session-xxx.json原始记录包含会话 ID、DID、当前任务摘要、动态口令验证结果、工作内容哈希、设备指纹哈希、本地时间。这是证明的“血肉”。session-xxx.sig对该 JSON 内容进行 ECDSA 签名的二进制文件证明该确权确由 DID 持有人产生。session-xxx.tx.json回执信息包括发往链网络端的交易哈希、区块号、确认时间、事件编号。这是证明与链上锚点的“接线”。成功验证一次依赖包需要依次验证签名、重新哈希、比对链上事件任何一个环节断开都说明证据被改动过。3.4 成本分析Gas 与存储优化链上存储每一次签到记录的燃料费不能忽视。在主网上普通的stamp()调用存储一个动态数组项大约消耗 6 万到 10 万 Gas。按当时常见价格换算一次签到可能要花费几美元。如果一个数字游民每天签八次到一个月下来会有上百美元成本完全不可接受。我采用的优化思路主要有三条选择低费率、高吞吐的 EVM 兼容链把单次签到成本压到人民币几分钱。也不要每次签到都写一个区块。本地先把一天内的签到记录聚合成一个“当日证据包”只做一次哈希上链。代价是链上时间戳只能证明“当日证据包存在”不能逐条证明具体时刻。折中方案是每 4 小时上链一次既降低费用又保留足够的时间分辨率。定期将旧证据的快照提交到去中心化存储网络链上只保留最新状态根和旧记录的压缩摘要。这样合约数据量不会无限膨胀查询也更快。4. 实操落地最小可行产品的搭建4.1 技术栈选择我在做最小可行产品MVP时没有一上来就用复杂的 Substrate 链或自研共识网络而是选择了一条成熟 EVM 兼容链和一套轻量级前端工具链。链端Solidity 0.8.20 Hardhat 编译部署前端JavaScript Ethers.js 和 MetaMask 钱包身份组件自研的本地 DID 管理模块使用noble/secp256k1和noble/hashes这类纯 JS 密码学库避免原生依赖存储JSON 文件直接存在本地测试验证中用 IPFS 兼容网关估算存储成本之所以选择 EVM 体系是因为它的工具链最成熟社区样例最多Solidity 的生态能覆盖我在合约调试和审计上的需求。数字游民项目本身不追求世界计算机级别的性能一个简单、稳定、可验证的合约已经够了。4.2 本地开发环境配置搭建环境时最核心的步骤是初始化 Hardhat 项目并配置好网络参数。我人比较懒整套流程已经记在小本本上了mkdir presence-stamp cd presence-stamp npm init -y npm install --save-dev hardhat ethers noble/hashes noble/secp256k1 npx hardhat init初始化完成后在hardhat.config.js里配置测试网和本地开发网络的私钥环境变量。私钥永远不要硬编码在代码里而是用.env文件加载。这一点在数字游民场景里尤其重要因为代码经常在公共网络下编写一旦私钥泄露整个身份体系都会崩盘。require(dotenv).config(); module.exports { solidity: 0.8.20, networks: { dev: { url: process.env.DEV_RPC_URL, accounts: [process.env.DEV_PRIVATE_KEY], chainId: 1337, }, }, };4.3 核心代码片段演示链下证据准备过程看起来大概是这样的import { sha256 } from noble/hashes/sha256; import { secp256k1 } from noble/secp256k1; import { v4 as uuidv4 } from uuid; function buildPayload({ did, workSummary, sessionCode }) { const sessionId uuidv4(); const contentHash sha256(new TextEncoder().encode(workSummary)); const payload { sessionId, did, workSummaryHash: toHex(contentHash), dynamicCode: sessionCode, deviceFingerprint: toHex(sha256(new TextEncoder().encode(navigator.userAgent))), localTime: Date.now(), }; // 对整个 payload 做统一哈希作为上链的 payloadHash const payloadHash sha256( new TextEncoder().encode(JSON.stringify(payload)) ); return { payload, payloadHash: toHex(payloadHash) }; } async function signPayload(payloadHash, privateKey) { const signature await secp256k1.sign(payloadHash, privateKey); return secp256k1.toCompactSignature(signature); }buildPayload返回的payloadHash就是最终传给合约stamp()的那个值。整个过程全部在本地完成链上只看到一个无法反推原始内容的哈希。部署合约到本地测试网络之后我用以下脚本做了一次完整的模拟签到const contract await ethers.getContractAt(PresenceStamp, deployed.address); await contract.register(user.address); const tx await contract.stamp( ethers.id(session-1234), ethers.keccak256(ethers.toUtf8Bytes(work summary hash placeholder)) ); await tx.wait();这段脚本跑通后我再通过getProof(user.address, 0)就能取出第一条证明记录并打印出区块时间戳。看到链上时间戳和本地时间差在几秒以内那种踏实感是中心化表格给不了的。4.4 测试网与模拟数据实验在真实引入用户之前我用测试网做了三轮压力测试。第一轮只验证合约逻辑正确性分别模拟同一 DID 连续签到、未注册账户直接签到、重复会话 ID 签到三种情况。最终确认合约对未注册账户会直接revert而重复会话 ID 虽未被拒绝但实际业务层可以单独校验不会产生混淆。第二轮模拟了多账号并行签到场景。用脚本生成 10 个模拟账户每个账户随机签到 20 次观察链上交易确认时间和事件日志的完整性。最终发现高频签到时最大的瓶颈不在链上而是本地 API 和支付非ce的排序错误这个后续单独讲。第三轮比较贴近真实把签到频率降到每小时一次连续运行 72 小时模拟数字游民一周的使用强度。测试结果验证了两件事一是链上费用完全可控二是链下证据包一天最多 25 个 JSON 文件一个月不到 1MB用网盘或邮件附件就能归档传输。5. 常见问题与排查技巧实录5.1 链上交易延迟导致签到超时怎么办动态口令有效期只有 30 秒但链上交易可能需要二十秒甚至更久才能被打包。如果你等到交易确认后才去验证下一个口令那系统基本没法用。我遇到过好多次点完签到钱包弹窗确认等了三分钟链上还没出块然后本地动态口令已经刷新客户端认为签到失败。解决办法是把“本地记录的签名时戳”与“链上确认的区块时戳”解耦。只要在发起交易前用户尝试验证动态口令的那一刻是有效且已签名的本地就把这次签到视为有效。链上时间戳只作为后续证据比对的一个参考而不是唯一标准。具体实现中我会把localTime同时写入证据包并把动态口令的“已通过验证”标记一并保存。这样即使链上区块延后一分钟只要交易被包含在合理时间窗口内证据依然逻辑自洽。5.2 如何防范他人代打卡钱包私钥在自己手里理论上别人无法伪造签名。但真实场景中总会有人为了赶工时把私钥导入到另一个设备上让远方的朋友代刷。这其实是身份管理的信任边界问题。我加了一个轻量的行为特征校验客户端每十分钟记录一次鼠标移动、键盘敲击间隔、前台窗口切换的组合哈希但与链上签到分开保存。验证者在拿到原始证据包时可以选择检查这些行为特征是否在一天内保持较高的一致性。如果某个账户早晨在亚洲时区活动晚上突然变成南北极时段的平均敲击节奏系统会给出警告。当然这个方案没法阻止用户主动把设备完全交给对方毕竟没有系统能对抗完全不设防的本人。我的建议是在服务协议里写明“证明仅辅助参考”并保持设备指纹与生物识别解锁的强绑定。5.3 隐私泄露风险与补救尽管链上只有哈希但哈希与真实生活一旦关联起来隐私就会意外泄露。举个真实教训某数字游民在分享自己的工作日志时不小心把证据包中的sessionId原样贴到了社交软件上。因为sessionId没有做混淆被好事者顺着这个 ID 关联到了链上的两份签到记录进而推断出这名游民某几天的工作时段。补救办法是在生成证据包时对sessionId和 DID 做额外混淆上链时只存混淆后的映射值。更稳妥的是所有分享出去的数据都用SHA-256(payloadHash 随机盐)二次哈希盐只留存于用户本地。验证时验证者拿到的是二次哈希结果和盐依然可以重建映射外部人员却无法从公开数据逆推出原始活动。5.4 跨链迁移与长期归档数字游民可能几年内换好几条链今天的链明天可能周边式维护。所以在一开始我就把“跨链迁移”纳入设计目标。具体做法是维护一份链间状态映射表每当用户完成新链注册就把旧链上最后证明确认哈希写入新链的备忘录字段同时将旧链的原始证据包完整归档到去中心化存储。这样迁移后验证机构只需要看“最新链上备忘录”指向的旧链哈希再通过归档数据即可串起完整的历史证明。我自己实测过迁移后所有历史证据依然可核验唯一需要注意的是迁移时旧链的状态快照必须包含所有事件日志不能在涨块回滚后丢失数据。最后分享一点个人体会我在实际搭建这套系统时不止一次被问到“为什么不干脆用中心化服务”。如果只是为了打卡确实没必要上链。但数字游民的核心资产就是“可验证的信用”这种信用需要由多方共同见证而中心化服务天生存在数据可被删改和平台存续风险的问题。区块链的价值不在于炫技而在于它把“ 证明权”交还给个人让任何第三方都能独立验证证据却无法单独控制证据。如果你也想做类似的事情我的建议是先不要急着搭完整协议只做一条链上“哈希时间戳空”的最小合约配合本地 JSON 文件跑通一次签到。等你亲自把证据包从一个国家传到另一个国家并在客户面前完成一次成功核验时你才能真正体会到“在场证明”这四个字的重量。