iCKB is now approaching its final stage before launch: iCKB is undergoing an internal audit, later a formal external audit, then shortly after iCKB will finally launch on mainnet.
Given all this, I'd like to once again document the Busywork Attack and ask for more eyes on it.
This attack works very similarly to the one described in the Standard Deposit section, but it's even simpler.
An attacker who can borrow a big enough capital can simply attack by repeating the following two steps:
- Deposit CKB for iCKB in standard deposits.
- Exchange iCKB back to CKB.
Depending on the amount of capital used for the attack, this could reduce the quality of the service for everyone, as the only remaining deposits would be those whose maturity date is a bit more far away, so this could hamper the protocol fruition.
When I first analyzed this attack, the project was still named CKB++, I ask forgiveness for quoting my old analys:
Let's say an attacker controls a percentage of the capital stacked in CKB++, let's see how much time a whale/user have to wait and how much interests he loses. Let's assume a 0.3% APR per 180 epochs (which is an over-valuation of what NervosDAO is currently disbursing).
-
Let's assume the attacker is able to fully control the first available epoch, then he controls 1/180 ~ 0.6% of the funds locked in CKB++, then the whale have to choose a deposit that expires one epoch later and he is blocked for one epoch and he loses less than *0.3%1/180 ~ 0.0017% of interests.
-
An attacker controls the first available day, then he controls 6/180 ~ 3.33% of the CKB++ total supply, the whale loses 0.3%*6/180 ~ 0.01% of interests.
-
An attacker controls the first three available days, then he controls 18/180 ~ 10% of the CKB++ total supply, the whale loses 0.3%*180/180 ~ 0.03% of interests.
-
An attacker controls the first six available days, then he controls 36/180 ~ 20% of the CKB++ total supply, the whale loses 0.3%*36/180 ~ 0.06% of interests.
So basically once CKB++ grows big enough, an attacker can't really do much damage.
Quoting @jordanmack:
I see it as acceptable. It will take a tremendous amount of capital to do minimal damage.
@XuJiandong does all this sound reasonable?
iCKB is now approaching its final stage before launch: iCKB is undergoing an internal audit, later a formal external audit, then shortly after iCKB will finally launch on mainnet.
Given all this, I'd like to once again document the Busywork Attack and ask for more eyes on it.
This attack works very similarly to the one described in the Standard Deposit section, but it's even simpler.
An attacker who can borrow a big enough capital can simply attack by repeating the following two steps:
Depending on the amount of capital used for the attack, this could reduce the quality of the service for everyone, as the only remaining deposits would be those whose maturity date is a bit more far away, so this could hamper the protocol fruition.
When I first analyzed this attack, the project was still named CKB++, I ask forgiveness for quoting my old analys:
Quoting @jordanmack:
@XuJiandong does all this sound reasonable?