The problem Safer3 solves

Bybit's 1.5B attack was caused by the attack of the safe frontend server. By replacing malicious frontend files of Safe, the attacker successfully tricked the Bybit cosigners to sign a tx to transfer the ownership of their multi-sign safe wallet to the attacker. Then the 1.5B Ether was drained by the attacker to their wallets. To address the centralized frontend problem, we upload the Safe website on-chain to a smart contract so that it enjoys the same security level of application contracts including integrity of the files, transparency, and availabilities.

User Interaction and Data Flow

After uploading the Safe website to on-chain smart contract, the user can interact the website using web3:// access protocol defined in ERC-4804. To access web3:// website, one way is to use official gateway (and we are also deploying one by ourself), or to use a native web3:// browser https://github.com/web3-protocol/evm-browser. We are also exploring client-side verification technolgies to verify the website integrity.

The project architecture and development process

The project is running on top of SWC L2 with EthStorage as storage backend. The components are:

• a FlatDirectory contract, which is smart contract deployed on SWC L2 that organizes the directory structures of Safe website and points the file data via EthStorage smart contract.
• the EthStorage contract, which is a smart contract deployed on SWC L2 that maintain the data hashes and verify off-chain-storage proof;
• the EthStorage L3 network, which is a P2P storage network that stores the actual data;
• browser: either using gateway or a browser with native web3:// support

Key differentiators and uniqueness of the project

All files of the Safe website are stored on-chain and thus enjoy the same level of security as smart contracts including: integrity of the files, transparency, availability. Compared to IPFS contenthash, we use a smart contract to emulate the filesystem so that uploading a modified website only needs to submit the diffs - while contenthash requires to update the whole files again. Taking Vitalik's blog as an example, updating the whole blob with a new article takes a fews, while IPFS contenthash can take hours. In addition, IPFS cannot guarantee availability - the files can disappear any time.

Trade-offs and shortcuts while building

To ensure full integrity, a client-side verification is needed, especially for browsers. Unforunately, we have not find a mature client-side verification tool. One exploration is the helios developed by a16z.

Additional, accessing the website using gateway still suffers from censorship attack or gateway down. One solution is to use Ethereum portal network, which is a decentralized Ethereum JSON-RPC network powered by P2P technologies.