➡️Next step: Slashing Authorization
Slashing Authorization
Our goal is to fully decentralize Ta-da. However, this cannot be achieved all at once, so we are progressing gradually. In this second step, we are addressing the slashing system. In the previous version, the backend could theoretically slash an arbitrary amount of tokens. Therefore, it is necessary to implement a solution that prevents or mitigates this risk. This section describes such a system.
When the user performs a task he sends to the backend a slashing authorization signed by his private key. A signed authorization is irrefutable proof that the user allows the deduction of a precisely determined deposit amount for a specific task.
The backend stores this authorization and sends it to the Deposit Pool if the user is slashed. This smart contract then checks that the authorization is valid thanks to the signature and slashes the user accordingly. That way, a user cannot lose more than he has previously authorized.
A slashing authorization must contain this information:
the identifier of the task
the amount of tokens the user accepts to lose through slashing
a nonce avoiding replay attacks
a timestamp
the signature
Before accepting and storing the slashing authorization, the backend checks the validity of each field.
The nonce prevents replay attacks. Without it, the backend could send the same authorization multiple times to slash all of a user's tokens. The Deposit Pool prevents this attack by checking that the authorization has not already been executed using this nonce.
At this stage, the backend could still arbitrarily slash a user. However, it could only do so for the amount specified in the authorizations that have been sent to it and have not yet been executed. This greatly mitigates the risk.
Auto withdrawal
As a reminder, the Deposit Pool executes withdrawal requests only after backend confirmation. This means that if the backend fails for any reason, the withdrawals cannot be processed. To address this issue, the smart contract implements a period during which the backend must authorize or refuse the withdrawal (it must respond either way). If there is no response after this period, the tokens are automatically released and returned to the user.
