# Reddit Post

> A live proof of concept showing hundreds of thousands of transactions

The simulation is currently running. At the moment we have processed 40k transactions. We did some preprocessing so started everything ~12 hours ago. We will update the post here when the simulation has finished.

> Source code (for on & off-chain components as well tooling used for the PoC). The source code does not have to be shared publicly, but if Reddit decides to use a particular solution it will need to be shared with Reddit at some point

Smart contracts: https://github.com/thehubbleproject/RedditHubble

Node: https://github.com/thehubbleproject/reddit-commander

> Documentation

General Documentation: https://thehubbleproject.github.io/
Spec for Reddit RollApp: https://hackmd.io/yGcb_vWfT5679rEcebT0rw

> How it works & scales

We use optimistic rollup. Basically we create a commitment for a batch of transactions. If the commitment is incorrect anyone can execute a fraud proof to prove it is incorrect and revert the incorrect batch.

So our smart contract desribes the fraud proofs and commitments and the node watches the smart contract and validates every commitment is correct. If not it will produces a fraud proof and revert the state.

Currently a single coordiantor run by us is allowed to create batches. We plan to decentrlaize this later.

> How to run it

https://github.com/thehubbleproject/reddit-commander/blob/master/README.md

> Known issues or tradeoffs

We have several improvments still to apply

1. Bls signatures will reduce the size of our commitments and thus our cost per tx.
2. Mass migrations will allow users to move to any other scaling solutions as they see fit.
3. Decentralize coordinator: at the moment the coordinator is centralized which gives them alot of power. They can basically stop the whole system if they stop processing tarnsactions. We currently have a governance fall back to update teh coordinator if they become malicious. But this basically make the governece able to dos the whole chain. We plan to use https://ethresear.ch/t/spam-resistant-block-creator-selection-via-burn-auction/5851 to decentrlaize the coordinator.
4. General gas optimizations: Reducing footprint per batch, we limit our batching to 32 transactions per batch to ensure that the fraud proofs execute in 3-5 million gas, the batch footprint on-chain in terms of storage can be reduced quite a lot. We have some ideas around just storing one hash per batch on-chain

> Summary of cost & resource information for both on-chain & off-chain components used in the PoC, as well as cost & resource estimates for further scaling. If your PoC is not on mainnet, make note of any mainnet caveats (such as congestion issues).

Each batch contains 32 operations. We assume the gas block limit is 10,000,000 and
block time is 13.5 seconds when calculating transactions per second.

submitBatch for CreateAccount use 235533 gas
7360 gas per account creates
100 account creates per second

submitBatch for Airdrop use 269983 gas
8436.96 gas per Airdrop
87 airdrops per second

submitBatch for Transfer use 270046 gas
8438.9375 gas per Transfer
87.77654067715761 transactions per second

submitBatch for BurnConsent use 269202 gas
8421.56 gas per BurnConsent
88.05176316611599 burnConsent per second

submitBatch for BurnExecution use 234253 gas
7320.40625 gas per BurnExecution
101.188 BurnExections per second

The USD cost is dependent upon the gas price market which fluctuates alot.

Offchain costs are servers 0.1 USD per hour. Its same as basic laptop spec. We are probably over paying.

> Scaling. This PoC should scale to the numbers below with minimal costs (both on & off-chain). There should also be a clear path to supporting hundreds of millions of users.

See benchmarks

> Decentralization. Solutions should not depend on any single third-party provider.

Currently we have a centralized coordinator but plan to upgrade to decentralized coordinator.

> Transactions complete in a reasonable amount of time (seconds or minutes, not hours or days)

Coordinator needs to gather enough transactions to create a block. Once this is done transactiosn can be commited in ethereum block time.

We can offer sub second weak finality by the cooordinator placing a bond and commiting to include a transaction or else their bond will be slashed. This does not provide the same crypto economic finality that layer 1 does but it does allow for nice UX.

> Free to use for end users (no gas fees, or fixed/minimal fees that Reddit can pay on their behalf)

Yes. We currently have no fees and depend upon reddit to pay the coordinators costs. All gas fees can be done meta-tx style natively. This introduces some problems with the plan to decentralise the coordinator. We can add per users fees denomintated in the token they are transfering. There is more nuance here that we can dig into later.

> Users should be able to view their balances & transactions via a blockchain explorer-style interface

We don't have this yet but can add it later. We do have API's to view the balances and transactions but not a GUI.

> Exiting is fast & simple

We plan to add mass migrations which will make it cheap for users to leave. Which will allow users with very small balances to move to any other scaling solution.

To exit to layer 1 naively would require users to wait a 1 week delay. We can remove this requirement by providing users with fast withdraw. Basically a helper provides the withdrawed funds up front to the user. After the delay period the same helper gets the funds the user was trying to withdraw.

> Scaling solutions should be extensible and allow third parties to build on top of it

You cannot build custom solidity ethereum style dapps inside hubble. However our perfered approch is to allow mass migrations so users can move to other scaling solutions or other hubble-chains which will allow anyone to build programmable dapps.

> Third-party permissionless integrations should be possible & straightforward

Mass migrations should allow anyone to add a new feature and migrate hundreds of thousands of users to a new hubble chain in a single ethereum transaction :)

> Simple is better. Learning an uncommon or proprietary language should not be necessary. Advanced knowledge of mathematics, cryptography, or L2 scaling should not be required. Compatibility with common utilities & toolchains is expected.

This applies to us. You can use any scaling solution you like just need to accept mass migrations.

> Balances and transactions cannot be forged, manipulated, or blocked by Reddit or anyone else

An incorrect commitment can be put on chain but anyone can revert that commitment with the fraud proof, the coordinator who submits a fraud batch and the coordinators who build on fraud batch get heavily slashed.

> Points should be recoverable to on-chain ERC20 tokens even if all third-parties involved go offline

We can add a governance multisig that can update the coordinator if they go offline. But if the governance goes offline we will be stuck. We could hard spoon the token to recover. In future version we will decentralise the coordinator.

> A public, third-party review attesting to the soundness of the design should be available

Not availble at the moment. But we plan to audit soon.If this is a blocker we can start an audit ASAP but want to wait to finailze features required for community points as our entry is specific for that usecase.

> Compatibility with HSMs & hardware wallets

Currently yes because we use ethereum style signatures. But later we want to add BLS and that will need us to add BLS signature support to hardware wallets.

> Minting/distributing tokens is not performed by Reddit directly [1]

At the moment reddit does need to be aware of the current state of the system when doing airdrops. The airdrops happen sequentially which means that reddit need to publish aidrops. But they don't execute it. A future version we can remove this so that reddit is just signing a random string and provides it to just hte user.

> One off point burning, as well as recurring, non-interactive point burning (for subreddit memberships [2]) should be possible and scalable

We provide this. See benchmarks for costs

> Fully open-source solutions are strongly preferred

Of course github.com/thehubbleproject/

## Final note

We had alot of fun working on this project. We were really happy to see the other submissions. We think it would be a shame if just a single team were to "win". So we propose to use mass migrations so that users can pick which solution THEY want to use. The aidrop happens on a single solution. But then users can move to whatever solution suits their needs. Nobody wins unless everybody wins :D

## Get in touch, we love questions

Join our TG group [here](https://t.me/joinchat/HObf_xh7RxODl9vth3gKyQ)