1/ Have you noticed an impressive TVL increase on @bobanetwork, which quickly climbed up to #2 on @l2beatcom ? Quick 𧡠on what is this rollup (and what it is not) that you may not have heard about before π
2/ So, TL/DR is that π§ is an @optimismPBC fork, but with a token, $BOBA. And if you are thinking that the massive and quick TVL increase is due to $BOBA airdrop and liquidity mining, you might be right
3/ They seem to be following @optimismPBC so close, that they upgraded to OVM 2.0 on the 28th of Oct, actually before @optimismPBC did themselves (on 11th of Nov) π€―
4/ Risk profile, given how close they are to their origin, is the same. Main point - right now fraud proofs are entirely disabled as for OVM 2.0 they are still WiP π
5/ The main extra feature is the "native" support for fast exits via liquidity providers. If math on their bridge is correct, you might be able to earn e.g. over 9% APR on supplying ETH. Note very low liquidity on some of the pools though
6/ With @optimismPBC fast exits are obviously also supported, but by third party bridges and providers. The list of available solutions is growing as is the whole ecosystem
7/ We have obviously seen many forks of different projects in the past - the verdict is still out what role forks of major rollups will play in the future. The challenge, as always, is to make liquidity stick and built vibrant ecosystem of DApps. Good luck to π§ π
β’ β’ β’
Missing some Tweet in this thread? You can try to
force a refresh
2/ If you are more interested in a project vision, especially "DACs", roadmap, etc... you can find more strategy and marketing-oriented resources on the web, this is a quick peek of what was deployed and launched on the 18th of Nov
3/ Metis under the hood is another fork of @optimismPBC - expect more of these to come in the future. The main difference is that @MetisDAO plans to launch multiple "instances" of L2 rollups
1/ After seeing so much confusion about upcoming data sharding in Ethereum, here's my take on why you will soon see massive increase in tx throughput on Ethereum and how this is achieved ππ§΅
2/ The main factor limiting Rollup scalability today (both Optimistic and ZK) is the fact they both use tx calldata to store L2 txs on L1 and the size of calldata is limited by L1 block size. Hence ideas such as Validium or zkPorter (blog.matter-labs.io/zkporter-a-breβ¦)
3/ These ideas are nice, but they introduce additional security assumptions, such as "Data Availability Committees" with their own tokenomics. What if there was a way to somehow make L1 validators to be such a committee ?
1/ What are your favourite blockchain myths ? Can you add sth to this list of my personal favourites (in no particular order) ? Which one you disagree with ? Myths and Truths below: ππ§΅
2/ M: There is no extra social layer in blockchains, consensus is programmed into the software and blockchains are truly immutable
T: Users can decide to change consensus rules, fork the blockchains, change history
3/ M: Users will prefer immutable, code-is-law, blockchains over blockchain that changes former consensus rules
T: If programmed consensus rules seriously clash with what is understood to be the social consensus (the intent) users prefer a forked blockchain (ETH vs $ETC)
1/ Let's try to dispel the biggest confusion about Optimistic Rollups and their 7-day fraud proof window. Imagine you have 1000$ DAI and send it to Alice. Then you send it again to Bob. Obviously you expect that first tx confirms, the second reverts with "out-of-balance" error π
2/ Clearly Alice should now have 1000$ DAI and not Bob, provided that the *sequence* of txs are as above. Now, Sequencer posts both transactions to L1 in a batch and also posts a state root (a magic number). L1 does not do anything fancy, except recording these.
3/ If Sequencer is honest, the state root "confirms" to L1 that it's Alice that has $DAI on L2 and not Bob. So Alice can withdraw that $DAI to L1, i.e. release them from L1 deposit contract. Not Bob. But how L1 can be sure that L2 Sequencer is honest ?
3/ Pushing state roots is crucial so that users can withdraw their funds from the bridge. And to be able to do it, you need to provide Merkle Proof of your balance against that state root on L1
1/ How important is Censorship Resistance for L2s ? Applications can censor individual users based on where they come from, or whole dApps could be rendered useless if Rollups censored all incoming txs to them. What are the possible solutions right now ? π@l2beatcom
2/ @arbitrum and @optimismPBC allow users to "force" their transactions via L1. This is perhaps inconvenient for the end users, but it is a very generic mechanism that works for all dApps on a Rollup. And dApps don't need to do anything, it's just there. And it works
3/ @StarkWareLtd based L2s (@SorareHQ, @dydxprotocol, @deversifi, @Immutable) also have force transaction mechanism, but they are application specific. Namely, they allow you to force only certain tx (typically withdrawal request). It's as if each dApp had to implement it on L1