LossLess项目简析
0x8888
December 27th, 2021

项目目标

解决DeFi 生态存在的安全问题,减少黑客攻击损失。

项目状态

只有白皮书文档,产品没有上线。

方案内容

项目本身不负责寻找可疑攻击交易,是期望搭建一个平台,让社区用户(白帽子)为了激励制造出高效的检测工具。

  1. 在项目代币中嵌入lossless的代码,用于紧急冻结黑客地址;
  2. 攻击事件由社区用户发起,发起人需要质押LSS代币,可立即直接临时冻结地址24-48小时;
  3. 临时冻结后,由 LossLess Committee 审核,可继续冻结14天;

具体代码层面,计划通过给Token增加如下公开方法支持任意用户冻结任意地址:

function allegeHack(address allegedHacker, uint256 freezeDuration) external returns (bool);

方案问题

如何吸引项目方在Token合约中嵌入该平台的代码?

为了能冻结任意地址的余额,token合约需要集成lossless的代码。这种方案是侵入式的,需要修改项目的Token合约代码,这不仅给项目方带来了额外技术成本,也给普通用户的每一次转账交易都增加了Gas Fee成本。

另外lossless并不能保证嵌入项目合约中的代码是100%安全的。

DeFi项目众多,如果项目方自己的项目发展很好,但LSS项目因为种种原因无法继续运营,而项目Token的合约集成lossless的代码,将给项目方带来持续的影响。

如何确定hack finder 应该质押多少LSS 代币?

漏报率和误报率是传统互联网安全产品的两个常见评估指标。

分析该项目的经济模型,我们可以预见,如果finder质押的金额过少,将带来大量误报(允许判断错误,不放过任何一个可疑交易)。相反,如果质押的金额过多,将产生大量漏报,finder必须100%保证发现的交易一定是恶意的攻击(否则会被罚没质押金)。

而这个数字,在官方文档中并没有提及(只提到奖励金额是挽回损失的2%)。

如何保证finder提交疑似攻击的及时性?

该项目的解决方案是监测攻击的发生,期望攻击事件发生后第一时间冻结相关地址的资产。

官方文档中以PAID Network的攻击事件举例,攻击发生到黑客卖出Token中间有4分10秒的时间差,这个时间差足以finder提交冻结信息。

但事实上,黑客的攻击都是精心准备的,如果黑客事先知道该项目的Token有被中心化冻结的可能,一定不会给别人留下操作的时间。例如通过MEV等方式将攻击交易、卖出交易甚至洗币交易组合执行。

观察目前发生过的攻击事件,黑客都会第一时间将获取的USDT兑换为DAI等去中心化稳定币。

个人看法

黑客攻击确实给参与DeFi的用户造成了大量损失,合约的安全性也是各个项目方应当着重考虑的问题。但lossless的解决方案是一种理想状态下的经济学安全方案而非数学安全方案,且存在较多的技术问题,个人推测其非常难得到项目方的支持。

Arweave TX
pvaXl_RAvvuOAqzelqsn6sZLw6aigCgsQ2OBljDi0nM
Ethereum Address
0x88884421a2a5A26A28Abd6D3a528915ACAD25c8f
Content Digest
hfePn12r2INrtvz8e_M5gAYUGWfghRA_aXYQZTOqUnY