rollback tokens

robin·May 21, 2023ercrollbacktokens

what?

a rollback token gives an address or a contract a time period to roll back an erc20 transaction, if the transaction is not rolled back within the time period, the transaction is considered valid and cannot be rolled back.

why?

in recent times, there have been many cases of people losing their tokens due to a mistake in the transaction, due to a scam, or due to a hack. for a blockchain to handle this type of scams, large amount of hacks, it needs to be rolled back to the previous state to accumulate/reverse all the funds, as it was with ethereum that created ETC after hackers stole around $50 million from DAO

now the point is, after that, billions of dollars in crypto has been hacked and scammed from various blockchains. and many of them didn't rolled back, causing users and organizations to suffer great losses.

the rollback token standard proposes, instead of rolling back the entire blockchain, one can just undo the transfer transaction within a time period, safeguarding the assets that were compromised.

with rbts,

  • anyone can reverse their compromised token transfers
  • crypto hacks can be minimized to 0
  • new layer of security will be added on-chain
  • no losses to anyone

how?

rollback token standardizes an existing erc20 token with a rollback feature. behind the curtains, the process starts with assigning an helper address Y (sahayak) to the address X, when the latter is compromised or hacked, rbt tokens transferred to the exploiter can be reversed back using the helper address.

using zero-knowledge proofs, one can assign its helper in a way without exposing its details. only the sahayak will have the proof to prove its ownership over reversing transfers.

hold on, wouldn't the exploiter transfer to another address again? no! that's the catch (and a security level check), for the tokens to be reflected in the balance, the same time period will be considered.

struct TransferStruct {
    address to;
    uint256 amount;
    uint256 timestamp;
}

/**
    @dev get specific transfer details for the address
    @return TransferStruct
**/
mapping( address => mapping( uint => TransferStruct )) public transfers;
mapping( address => uint ) public transferCount;

... isValid( address account, uint tid ) internval view returns ( bool ) {
    uint lockPeriod = IRBOracle( _oracle ).getReversePeriod();
    uint locked = _transfers[account][tid].timestamp.add( lockPeriod );
    
    return block.timestamp > locked;
}

... getAmount( address account, uint tid ) internal view returns ( uint256 amount ) {
    amount = transfers[msg.sender][tid].amount;
}

... balanceOf( address account ) {
    uint256 balances = 0
    for ( uint i = 0; i < transferCount[account] i ++ ) {
        balances = isValid( account, i ) ? getAmount(account, i) : 0; 
    }
}

rbt will work using these components, rbtOracle, rbtWrapper, rbtToken, rbtSahayak

rbtSahayak

"sahayak" signifies a role of support and assistance in different contexts, where one person helps another in their tasks or responsibilities

a normal EOA address, or a contract address, that can be assigned to an EOA or a contract address.

rbtToken

logical token for rolling back the transaction, implementing all the existing methods of the ERC20 standard, with the below added methods

function rollBack(uint tid) external;
function getTransfer(uint tid) external view returns (TransferStruct memory);

rollBack(uint tid) will rollback the tid transfer happened

getTransfer(uint tid) will return the transfer details of tid transfer

rbtWrapper

to wrap an existing erc20 token to rbt

rbtOracle

this will be the captain of our ship, handling the core part of managing rbtSahayak (the helper) to an address. an EOA can assign its sahayak by giving their ownership proof using signature, and contract address can issue by verifying its owner() or contract creator ownership.

rbtOracle.register( bytes memory signature, address sahayak ) // for EOA
rbtOracle.assign( bytes memory signature, address contractAddress, address sahayak) // for contract address

once it's registered to the oracle, the sahayak will be able to reverse the rbt token transfers within the time period set by the oracle.

for verifying the sahayak address, we will be using zkSTARK for verifying proofsg without using a trusted base, which will receive the proof given at the time of assigning the sahayak, and verify the proof with the public inputs, and return the result.

function verify( bytes memory proof, Commitment memory publicInputs ) public view returns ( bool ) {
    return verifier.verify( proof, publicInputs );
}

extended features

  • one address can only have one sahayak
  • the sahayak can have its own sahayak ( long chain layered can be created )
  • incase of updating the sahayak, [ discussion required ]

*note: functions defined may vary (just for overview purpose)

if?

for now, i'm unable to get any ifs (any loopholes), but if you have any, feel free to raise an issue below.

for?

using rbt tokens, the crypto community will be in a more secured environment than ever! the endgame for most of the hacks

now?

there are many more questions that arises in using the rbt tokens, how will be a contract checks for the tokens transferred?, how will be the transfer event will be implemented? and is this compatible same with native token transfers?.

some questions needs dev community to engage in building a protocol that will be the most secured way of storing assets.

for this standard to be considered, we'll require a great response on this article, to be heard by the ethereum magicians.

with great feature, comes great responsibility, and with great responsibility, comes great security. the rbt tokens will be the most secured way of storing assets, and will be the most secured way of transferring assets.

contributions

feel free to contribute in this scholarly article, quick links given below