GM 发放裁决之杖的记录被人从后台删掉,操作员矢口否认——普通审计日志是"谁都能改的一张表",没有防篡改能力。操作审计日志链封装:每条审计记录携带前一条的摘要,环环相扣成链,篡改或删除任何一条都会让后续链条校验失败——审计记录从"可以抵赖的流水"升级为"可验证的证据链"。
链式追加与完整性校验:前链摘要入新记录。示例代码如下:
local auditChain = { lastHash = 0 }
local function hashOf(text)
local sum = 0
for i = 1, #text do
sum = (sum * 31 + string.byte(text, i)) % 4294967296
end
return sum
end
local function audit(op, actorName, detail)
local row = op .. "|" .. actorName .. "|" .. detail .. "|" .. os.time()
local h = hashOf(row .. auditChain.lastHash)
auditChain[#auditChain + 1] = { row = row, hash = h }
auditChain.lastHash = h
print("审计入链:" .. row)
end
local function verifyChain()
local prev = 0
for i, e in ipairs(auditChain) do
local h = hashOf(e.row .. prev)
if h ~= e.hash then
return false, "第 " .. i .. " 条记录被篡改"
end
prev = e.hash
end
return true
end
敏感操作接线示例代码如下:
audit("发奖", "GM老王", "裁决之杖 x1 -> 玩家甲")
audit("封号", "GM老王", "玩家乙 7 天")
hashOf 用滚动乘法摘要(32 位空间),每条记录的摘要都混入了前一条的摘要(row 拼接 lastHash)——改任何一条的 row 会改变它的摘要,删任何一条会让后续所有条目的"前链摘要"对不上,verifyChain 从头重算一遍即可发现断点。auditChain.lastHash 缓存链尾摘要,追加成本是常数。
操作审计踩过三个坑:一是链越校越慢,千条记录的 verifyChain 全量重算约 5 毫秒,审计高峰每分钟校验一次就成了负担——按每 100 条设一个锚点摘要,校验从最近的锚点续算;二是操作与入链不同步,GM 执行了操作但进程崩溃丢了一条链尾,断链本身是正常的(崩溃丢尾可解释),校验器要区分"尾部截断"与"中间篡改"两种断链形态;三是审计内容含玩家敏感信息,导出证据时脱敏处理,链的完整性校验用原始数据、展示用脱敏数据,两套分开。
全站技术干货持续更新:996 引擎 / Lua 实战帖,语法、参数与示例一篇讲透。进入文章地图 · 查看全部 →
一、线上事故:阵容 3 职业 × 4 时段 × 2 难度共 24 种挑战方案,手写循环嵌套漏了一层,只枚举出 12 种,一半…
一、抛坑提问:红名惩罚公式要 A/B 两版对照跑,重启换版一次 5 分钟——把函数存进模块表字段,运行时改字段指向即完成切换…
一、一行代码拆解:local svc = {pricing = p, ledger = l} —— 这一行把结算器要用的依赖…
一、一行代码拆解:local obj = table.remove(pool) or {} —— 这一行是对象池的取件口:池…
一、隐蔽陷阱:攻方名单与守方名单各 200 人,找两边都在的重叠者用双层循环逐对比,4 万次比较跑 0.4 秒;名单翻倍直接…
一、线上事故:战利 30 件往剩余 8 格里塞,脚本按掉落顺序装满即停,价值 9000 的低阶货占格,价值 15000 的裁…