Decentralizing a social network poses some challenges. Networks like Twitter can do over 10,000 operations per second on average. Users of these networks expect them to be easy to use and free. App devs expect changes to propagate in seconds and with few failures.
Farcaster, our social network, uses a CRDT-based consensus model called a deltagraph. It has handled volumes of up to 500 TPS which many blockchains have not yet been able to do. The eventually consistent nature of the deltagraph causes sync issues as the network grows. In some edge cases, user data may be out of sync for days at a time [see Appendix C]. A better sync and consensus model is necessary to scale farcaster beyond 1 million users.
Blockchains are becoming faster and cheaper every day. We considered using them, but the appetite for financial transactions seems to grow just as fast at their capacity. This makes it slow and expensive to store user data in practice. There’s also no good way to remove data permanently which is important to users [see Appendix D].
Federation is an alternative but its a really bad developer experience. Apps would need to query hundreds or thousands of servers and handle failures and invalid data themselves. It would also take a long time for changes to propagate and users expect their data to show up in seconds.
We propose Snapchain, a blockchain-like system designed for a social network. It’s a hybrid system that relies on an external blockchain for account creation and focusses only on storing and syncing account data. Accounts can only take simple actions such as liking posting, liking and following which must not depend on the state of other accounts. This makes it easily shardable, unlike blockchains which must deal with double-spend attacks. It is also able to prune unnecessary historical state which limits state growth.
An account is identified by a unique number called the fid. A contract on an external blockchain called the registry handles account creation. Calling this contract issues a new fid to the wallet, whose signatures can then be used to authorize actions on behalf of the account. Accounts can be transferred to other wallets and even pick a recovery address, in case the wallet is lost.
An external blockchain is necessary to manage user accounts. It has strong security guarantees and can provide consistency across accounts which is important for features like recovery. It’s also flexible and users can share control of accounts with smart contracts easily. The downside is that there is a fee for each transaction, but this is tolerable since such actions are infrequent. Farcaster uses OP Mainnet as its external blockchain, but any modern chain could be used.
< Diagram of user accounts>
The registry also lets users generate “app keys” which can post messages on behalf of the account. App keys have limited permissions and cannot modify the account itself or other app keys. Users can use them like auth tokens to delegate permissions to third party applications without exposing their entire wallet.
Accounts also need usernames for convenience and there exist many systems like ENS. If the user’s wallet can prove ownership of such a name via onchain or offchain proof, the account is said to own the name. While all references to the account in data structures are made to its fid*,* apps can replace it with the friendly username in their user interface.
An account can take actions like writing a post or following another account which adds to its current state. It can also take negative actions like deleting a post which subtracts from its state. Actions are performed by signing messages with an account’s app keys and are called deltas because they can change the state of an account.
An accounts state also changes when things happen in the onchain registry. If there is an onchain event that adds a new app key that can also be considered a state change on the account. Here is a simple example illustrating the relationship between events, deltas and the state.
You can think of deltas and events collectively as the event log and the account state as the current, viewable state of the account. The account state is always some subset of the entire event log that was produced by the user, in a literal sense.