180 upvotes, 9 direct replies (showing 9)
View submission: The Great Reddit Scaling Bake-Off
Security. Users have full ownership & control of their points.
This is the most stringent requirement in this document. The consequence of having this level of security for user assets is that it must auditable by all parties, and therefore must be made available to all parties. At this time, the only known solution to the data availability problem [1[1]] are blockchains themselves. A probabilistic solution has been proposed [2[2]] and is currently being implemented in Ethereum 2 Phase 1. Any scaling solution that does not post all input data on-chain is insecure with respect to this requirement.
1: https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding
2: https://arxiv.org/abs/1809.09044
Only one category of scaling solution possesses this kind of security: rollups. They come in two flavors, optimistic [3[3]] and zero-knowledge [4[4]]. Because avoiding "moon math" is preferred and ZK-rollups are generally very expensive to compute, let's focus on optimistic rollups (ORU). The ORU derives its name from the fact that its values should be treated optimistically. To update an ORU, a relayer will submit on-chain all the transactions they wish to include in the ORU's next block + the resulting state root of the next block. It's possible that the relayer submitted an incorrect root, so users must treat this root optimistically until either they i) verify for themselves that the txs do evaluate to the new root or ii) reach a level of confidence (k-deep some might say [5[5]]) in the current progress of the chain. Because all data is posted on-chain, all parties can verify all transactions from the beginning of the ORU. Assuming a robust leader-election algorithm, the ORU will inherit the same safety and liveness properties of the base chain. So how much is it going to cost?
3: https://medium.com/@adlerjohn/the-why-s-of-optimistic-rollup-7c6a22cbb61a
4: https://docs.ethhub.io/ethereum-roadmap/layer-2-scaling/zk-rollups/
5: http://web.stanford.edu/class/ee374/downloads/l3_notes.pdf
The requirement for the POC is 300,000 txs over a 5 day period. That's 6MB per day if we assume transactions are roughly 100B each [6[6]]. Ethereum is currently seeing around 6,400 blocks [7[7]] mined a day with an average size of 28KB [7[8]]. That works out to 179MB a day -- plenty of room for Reddit's 6MBs.
6: https://ethereum.stackexchange.com/a/39033
7: https://bitinfocharts.com/ethereum/
8: https://bitinfocharts.com/ethereum/
As of EIP-2028 [8[9]], that would cost 16 gas per non-zero byte or around 96,000,000 gas a day. A reasonable gas price right now is 22 gwei [9[10]], which would come out to 2.112 ether a day. At the current exchange rate of $231 [10[11]], that would be approximately $488 a day spent submitting data on-chain. We're simplifying things by not taking into account the intrinsic cost of a transaction [11[12]] or any execution in the EVM that will occur, but $500 a day is a reasonable estimate.
9: https://eips.ethereum.org/EIPS/eip-2028
10: https://ethgasstation.info/
11: https://coinmarketcap.com/currencies/ethereum/
A major improvement to this would be batching the signatures together. Unfortunately, the current ECDSA signature scheme that Ethereum uses is not amenable to batching [12[13]]. However, BLS [13[14]] can prove n signatures in constant time and the specific curve, BLS12-381, has been implemented as part of EIP-2357 [14[15]] and has been accepted into the Berlin network upgrade of Ethereum. If we recalculate the daily cost, replacing the tx size with 34 bytes, it would only cost 0.704 ether per day to post all the Community Points txs on-chain.
13: https://cse.iitkgp.ac.in/~abhij/publications/ECDSA-JCEN.pdf
14: https://eprint.iacr.org/2018/483.pdf
15: https://eips.ethereum.org/EIPS/eip-2537
Some implementations of ORUs that are at varying degrees of production-ready:
Comment by abhuptani at 18/06/2020 at 22:33 UTC*
42 upvotes, 2 direct replies
I don't agree that posting data to chain makes a makes a scalability solution more *secure*.
Data availability helps with other things, e.g. information symmetry, liveness. However, the tradeoff here is an increased cost/limit to scalability due to needing to post calldata to mainnet.
Channels on the other hand require users to figure out where to store state themselves. This can *absolutely* still happen in a decentralized/user-friendly way, for instance using 3box. They also have liveness assumptions in that *someone* needs to be online to dispute your state in case you go offline for a long period of time and your counterparty attempts to force the channel to chain - however, this can *also* be done in a decentralized way using watchtower networks. In return for these tradeoffs, the flat cost/time of updating a channel is effectively 0, the on/offboarding is ultra-simple, and the developer experience is highly similar to web2 -- i.e. high reliability and consistency.
What these tradeoffs mean is that both channels and rollups are great for different things. ORU are great for peer-to-contract/consensus systems where you need everyone to have information about the same stuff, specifically want an incremental improvement to scalability for UX, and dont care that much about privacy. E.g. Uniswap.
Channels on the other hand are great for *peer to peer* systems involving highly interactive usecases and high-volume/low-value interactions. Channels are also inherently chain-agnostic, so can be used to bridge funds to L2s and between chains giving users a seamless experience that looks and feels just like a normal wallet. Great for things like micropayments.
If I were reddit, I would look into combining channels and ORU. Use rollups for minting, where the output is a user's Connext channel multisig running on the rollup chain. From there the user can transfer instantly to any other user on the rollup chain, or can even transfer to Ethereum itself and call contract functions like Uniswaps's `swap` (all while circumventing the mandatory 1 week exit period). When subscribing, the user can withdraw funds from the channel (instantly) directly to reddit's subscription contract running on the ORU chain.
Comment by stev0lutionlol at 18/06/2020 at 21:04 UTC
24 upvotes, 1 direct replies
Congrats, this appears to be the most comprehensive comment in this thread so far. Do you think there could be a path to efficiently transition from fraud proofs to validity (zk) proofs later on (when they have matured some more)? I mean other than withdrawing and redepositing.
Comment by decibels42 at 18/06/2020 at 23:28 UTC
14 upvotes, 0 direct replies
Whoa this was a great write up.
Comment by Robin_Hood_Jr at 18/06/2020 at 23:15 UTC
7 upvotes, 0 direct replies
end thread
Comment by geppetto123 at 18/06/2020 at 21:28 UTC
6 upvotes, 2 direct replies
Are STARK zk rollups still so compuational expensive? I thought that applies foremost to SNARK zk calculations.
Comment by jdkanani at 19/06/2020 at 03:36 UTC
2 upvotes, 1 direct replies
Pushing data on chain for community points would be overhead. If transfers go even 20x in future, whole solution will go on toss.
Comment by ElBuenMayini at 19/06/2020 at 04:15 UTC
3 upvotes, 1 direct replies
Considering Tether users are burning 2.5 million dollars every 30 days to move the stable coin, which roughly translates into 80k daily, 500 dollars sounds great.
Comment by RionFerren at 03/07/2020 at 10:14 UTC
3 upvotes, 0 direct replies
This approach is hugely flawed. That price of 2.1 Eth spent per day on gas will increase dramatically from today’s $500 if ETH price goes up and its network use increases
Ethereum is the wrong crypto to use here and won’t last long in this case
Comment by consideritwon at 19/06/2020 at 00:57 UTC
2 upvotes, 0 direct replies
Nice commentary. Although I think you are a little fast to dismiss zk-roll ups. In my opinion they are the most exciting scaling solution out there, particularly the STARK variety