v1-contracts VS quadrable

If you're working on "large Ethereum smart contracts" you've missed the point. On chain logic should always be as minimal as possible. Uniswap v1 was two vyper files. One was 46 lines, and the other was 496 lines[1]. It took like 20 minutes to read through the code thoroughly, and was one of the most impactful contracts ever deployed to the network.

Solidity also matured a lot, which is why Uniswap v2 moved back. If you find yourself writing an EVM assembler from scratch, and you're trying to build something other than a compiler, you have veered way way off course, and need to re-evaluate your system architecture.

Feature creep might work well if you're trying to leech money from a government contract or something, or being paid by line of code you contribute, but it's fatal in the Ethereum world. I consulted for a number of projects that made the exact same mistake, and most of them aren't around anymore.

[1] https://github.com/Uniswap/uniswap-v1/tree/master/contracts

Quadrable: Multiversion DB – Sparse binary Merkle tree with partial-tree proofs\ (5 comments)

Hey, I think you're making a valid point and I probably should have explained more what I meant by my statement.

IMO, there's a middle ground we can go between slow PoW on L1 and scaleability. I think that it can be done by having tools that give us the same guarantees like deploying a smart contract on the main chain. It's difficult to explain: But what I want is Plasma but as a framework to develop dapps.

This project is going that route: https://github.com/hoytech/quadrable