Ethereum Defi, a New Fork Coming? – Trustnodes

Ethereum Defi, a New Fork Coming?


Defi meme

Ethereum has a great problem. There’s so much demand to the point it can’t handle it all unless it gets a bit creative.

Sharding is two or more networks right. So why not create an ethereum ‘shard’ by literally copy pasting current eth and call the new one ethereum defi?

Unlike in sharding, here these two networks wouldn’t be able to talk to each other after the fork point, but the idea isn’t to replace eth or challenge it or offer an alternative, it’s more to try and provide a temporary solution while we all wait for eth 2.0.

Unlike previous forks, this would be the first complementary fork and it could even be launched by the Ethereum Foundation itself like a stock split or some defi consortium could launch it or anyone can launch it really.

Then what would happen is the constrain on node resources would change significantly because each network has its own nodes.

Thus for those that currently have eth this would allow for 2.4 million transactions a day, but with the same resource requirements as for current nodes and new resource demands would also grow at the current rate.

Basically you’d be getting double the capacity for free, but thats for current eth holders. Newcomers would be stuck with the current capacity as they have to choose one network or the other, unless they buy both for an equal amount at the same time.

If this was officially launched, you can even call it eth-a and eth-b, or eth and eth-b, and just as the current eth will be merged into an ethereum shard, eth-b can be merged as well because you just copy paste right.

Or if people don’t like the split stock idea, you can get the last letters of ethereum and call it RUM.

Rum just to make it clear that this isn’t trying to interfere with eth in any way, it’s meant to be very, very complementary.

We prefer eth and eth-b, in which case the latter shouldn’t be called ethereum defi but just ethereum as eth and eth b makes it clear it’s the same thing (kind of), but we don’t really care about the ticker or even about the name as long as it’s not a rubbish one and as long as it is an identical copy pasta of the current network with zero changes.

How to do that is very easy, you just fork the Geth github repo, compile it into a new client, and to split the networks you can do some non-meaningful consensus change like publish an empty contract on eth and tell Geth b or Geth defi to delete that.

Why would this work and why did no one think of it or why has bitcoin not done it in a complementary way?

Well the use case for bitcoin is either for payments, in which case you accept either btc or bch, or you accept both, but it’s not really complementary as you pay with one or the other. Or the other use case is a store of value where again either one or the other stores that value.

For ethereum however it’s main use case now is to provide financial services through dapps as well as other services like betting on Trump v Biden on Augur.

So once it is forked, then all the current eth on say sushi or yeth or maker are ethb on sushib or yethb or makerb. Basically, it’s a literal copy clone.

All the bots and everything, all the set-ups, just get cloned like magic really, and then on MetaMask like you can now switch from eth to Ropsten or some other testnet, they can offer the functionality of switching from eth to ethb.

So nothing changes except if you didn’t deposit on yeth because of high fees, you probably would deposit on yeth-b as initially you’d think fees would be low or conceptually if people do use both as equals then fees on current eth would halve or they’d be the same on both networks but with twice the activity.

What may well be the case as well is that if you go to the sushi website and change to eth-b, then the same site/interface may respond as normal because all of it is on eth-b and therefore nothing might need to be changed at all with the switch to different ‘universes’ being just a click on MetaMask.

Eth-b however wouldn’t be stakeable on eth 2.0 because that accepts eth and to add eth-b to it as well would probably be complicated.

For various other reasons the two would have different prices in any event and since they’re not pegged, if someone sold eth-b but kept eth or vice versa, then to them the other network wouldn’t be very complementary because they’d want new money to go to the token they held.

Also it’s not clear actually whether you can RPC this to eth2 because it’s a different token and in eth2 there’s only eth, but you can either copy clone eth2 as well or keep ethb as a running Proof of Work network.

So holistically for some this wouldn’t be very complementary, but that’s in the future and in the future there should be eth2 when then you can have different networks but with the same token.

In the present however this would be complementary because any additional value that the network currently can’t capture due to capacity constrains would go to ethb, which for current eth holders is basically eth, rather than to say Tron.

The latter is trying to copy pasta defi, but they don’t have gas, they have bandwidth, meaning the current running smart contracts would need to be re-written.

That would take time and skill, while for ethb or Rum, it would take just a few hours to double the capacity as far as current ethereans are concerned.

So why not do it? It would give current eth some competition as well so miners won’t be able to get as greedy, which can only be good for end users because we all know monopolies are bad.

Meaning in addition to layer 2s, this can also be a partial solution, but while implementing layer2s can take some time, this would be practically instant, so allowing ethereans within days to continue with their sushis or yeths or whatever rando token they want on uniswap.

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>