注册表是什么

FlareWatch 历史上出现的每一类重复性bug都已被提炼成一个编号的保护措施：一段落的规则、理由以及代码中执行该规则的位置指针。当出现应该防止重复出现的bug类别或模式时，会添加新的保护措施。

注册表是一份工作文档，不是营销宣传。它的目的是让团队和团队使用的审计优先的审核流程对适用规则的位置保持诚实态度。注册表在内联代码注释（如// Safeguard 24）中被引用，以便任何单个文件的读者都能找到管理其周围代码行的规则。

本页面是公开摘要。完整注册表存在于源代码库中，与它所管理的代码并排放置。这里的目的是让安全研究人员、拨款审查员或潜在贡献者了解注册表涵盖的类别以及它所执行的纪律类型。

为什么需要注册表

保护措施注册表只有在防止同一个bug出现两次时才能证明其价值。注册表的历史记录证明了这一点：

每项保护措施都命名了它所防止的bug。一项没有任何实际事件记忆支持的规则不是保护措施，而是风格偏好。风格偏好应该在lint规则中，而不是在注册表中。
保护措施在代码中被引用，而不仅仅在文档中。违反保护措施的代码更改在审核时会显示为标记，因为保护措施号在周围的注释中。
某些保护措施是自动执行的。其中一部分通过ESLint规则或在CI中运行的shell脚本来执行。其余的依赖于作者的纪律加上在实践中表现良好的审计优先审核模式。
注册表通过测试来保持诚实。几项保护措施由回归测试固定，这些测试以字符串形式读取源文件，并声明反模式不会出现。易碎性是一个特性：未来的重构如果恢复为反模式，测试会在回归到生产环境之前失败。

注册表按域组织。以下类别是稳定的；随着发现新的故障模式，会在每个类别中添加具体的防护措施。

类别	覆盖内容
身份验证与授权	会话验证的单一控制点、每条路由上的每钱包所有权检查、访问令牌和刷新令牌之间的交叉令牌拒绝、管理员路由限制。
数据完整性	地址规范化、生产者/消费者边界处的单位转换合约、密钥构建规范，以及反对将故障静默合并为零值的规则。
链上读取	从智能合约读取的任何值的单一实现规则、从链上注册表进行合约地址解析、反对复制奖励逻辑的规则。
显示正确性	集中式数字、货币和日期格式化；每个数字显示上的空值安全性；APR与APY标签规范；有效税率标签规范。
警报与通知	客户端和服务器之间警报评估的单一真实来源；对哪些警报扇出到监视钱包的显式允许列表；取消规则使"奖励已到账"警报取消过时的"奖励可用"警报；跨设备关闭同步。
持久化与缓存	关于规范存储何时为键值后端与localStorage的规则；迁移规范；部署范围的Service Worker缓存；对读取实时状态的路由的显式动态选择退出。
UI与生命周期	页面就绪门控、防止瞬间零值替代已知余额的单调下界，以及冷启动窗口期间骨架渲染的规则。
流程与工具	明确的功能发布同意规则、针对告警面变更的完整测试运行、服务器端代码结构化日志记录，以及针对快速修复风格的审查纪律。

这些是保障措施的公开摘要，用以说明该注册表的特点。内容已经改述和缩写；规范文本位于代码旁边。

从智能合约中读取的任何值——可索取的奖励、余额、质押状态、时期数据、价格——由服务层中恰好一个函数计算。每个需要该值的功能都导入同一个函数。如果两个函数计算同一个值，其中一个是错误的；规则是删除它，而不是添加第三个。

FlareWatch 中的每条认证路由都通过一个单一助手验证会话 cookie。没有路由处理器独立验证会话令牌。这个不变量是使服务器端撤销普遍有效的原因——没有绕过检查的后门。

钱包级路由在服务器端验证所有权，而不是客户端。原始审计确立了该规则，因为早期工作已关闭客户端门控但服务器端端点完全没有门控。这两个部分现在被跟踪为单独的明确交付成果——客户端关闭，服务器端关闭——以防止该故障模式再次发生。

所有数字、货币和日期格式化都通过一个小的集中助手集合进行。没有组件内联格式化。该规则与样式无关：当单个区域设置或货币定义更改时，应用程序中的每个界面都会随之更新。界面之间的偏差是无声的，很难被发现，直到用户注意到。

当系统的两个部分交换单位可能不明确的值（秒对毫秒、十进制对百分比、小写对校验和地址）时，约定在生产者和消费者两端都有文档记录。仅在一端的注释会腐烂；只有在两端都断言的边界契约才能在重构中存活下来。

每个用户发起的操作——添加监视的钱包、更改税率、关闭告警、登出——恰好有一个实现。该规则的存在是因为从 UI 的不同部分触发的操作过去常常以微妙的方式漂移：一个入口点会清除缓存，另一个不会，导致

某些失败模式本质上是无声的——奖励分类错误、单位不匹配导致通知变成空操作、清除记录从未到达键值存储。在可能的情况下，该注册表要求这些值的生产者足够大声地声明其合约，以便任何违反它的未来更改都会在测试中失败，在到达生产环境之前就暴露问题。

FlareWatch发布此概述而不是完整的内部注册表，原因有两个。

内部注册表包含代码级的详细信息（文件路径、键值模式名称、事件时间戳），这些信息对团队和有代码访问权限的安全审查员很有用，但在没有该访问权限的情况下不适合发布。
类别和规程才是真正的故事。评估FlareWatch的赠款审查者或安全研究人员想要了解它是什么类型的项目、它对正确性的重视程度、以及它的工作流程是什么样的——而不是第91条规则在哪个文件中。

想要讨论特定保障措施、提出新建议或报告漏洞的研究人员欢迎通过[email protected]联系我们.