4 ms·

> I need a hero, and by that, I mean that I need a usable methodology for building scaleable decentralized apps. Yes, you've heard that right. We don't need mor

> I need a hero, and by that, I mean that I need a usable methodology for building scaleable decentralized apps. Yes, you've heard that right. We don't need more "Ethereum killers" that can do 10x more tx/s than Ethereum. Those are useless. Having worked on large Ethereum smart contracts (running a decentralized auction on chain) over two years, I fully agree with this. Ethereum needs better smart contract languages, better compilers and better dev tooling. As our smart contract written in Vyper (for ease of auditing) grew larger and larger, eventually we failed to deploy on the testnet, and closer inspection reveal that the compiler was blowing up code size which I had to patch[0]. Down the line upstream further increased gas costs by emitting code that zeroed out every member of an array (note the EVM already has all memory set to 0). To support efficient insertion/deletion of bids we had to handroll a skip list on the blockchain(!), because there are no Vyper libraries. On the language development side, things don't look too pretty either, I ended up having to write an EVM assembler from scratch[1], but deeper still are problems such as a lack of a separate call stack in EVM, so procedure calls always end up clunky and implementation-dependent. LLVM to EVM[2] is still experimental, so anyone who is writing a compiler will have to write codegen from scratch. Perhaps eWASM will alleviate some of these concerns. But until then, the entire dev process for writing smart contracts is painful. [0] https://github.com/vyperlang/vyper/pull/1488 https://github.com/vyperlang/vyper/pull/1488 [1] https://github.com/ActorForth/evm-assembler/blob/master/docs/evm-assembler-talk.pdf https://github.com/ActorForth/evm-assembler/blob/master/docs... [2] https://github.com/etclabscore/evm_llvm https://github.com/etclabscore/evm_llvm

px43 6y ago
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 https://github.com/Uniswap/uniswap-v1/tree/master/contracts
- siraben 6y ago
  > On chain logic should always be as minimal as possible. The goal of the project was to make the auction as transparent as possible, doesn't that imply moving as much of the logic on chain as possible? > 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. This was a different project aimed at implementing a new smart contract language. Didn't take off internally though because of shift in direction.
  - px43 6y ago
    > The goal of the project was to make the auction as transparent as possible, doesn't that imply moving as much of the logic on chain as possible? Not really. Unsure of the specifics of the project that you were working on, but a standard auction house type interface shouldn't be that much code. You have listings, and bids. A listing should only be a timestamp for when the listing was placed, a timestamp for when the listing should end, maybe a minimum bid, and then a hash pointing to IPFS with all the less relevant meta-details. Bids would just be a price and a timestamp, though the timestamp probabally isn't even needed. You could just keep a record of the highest bid in the listing itself, and any time a new bid comes in, refund the previous bid to the previous highest bidder, and lock the current bid, so bids don't even need to allocate any new memory. If you really really need on-chain arbitration, you can do it with a simple ownership contract for starters, then switch over to a governance contract as the arbitration needs become more complex for whatever reason.

px43 6y ago

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 https://github.com/Uniswap/uniswap-v1/tree/master/contracts

siraben 6y ago
> On chain logic should always be as minimal as possible. The goal of the project was to make the auction as transparent as possible, doesn't that imply moving as much of the logic on chain as possible? > 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. This was a different project aimed at implementing a new smart contract language. Didn't take off internally though because of shift in direction.
- px43 6y ago
  > The goal of the project was to make the auction as transparent as possible, doesn't that imply moving as much of the logic on chain as possible? Not really. Unsure of the specifics of the project that you were working on, but a standard auction house type interface shouldn't be that much code. You have listings, and bids. A listing should only be a timestamp for when the listing was placed, a timestamp for when the listing should end, maybe a minimum bid, and then a hash pointing to IPFS with all the less relevant meta-details. Bids would just be a price and a timestamp, though the timestamp probabally isn't even needed. You could just keep a record of the highest bid in the listing itself, and any time a new bid comes in, refund the previous bid to the previous highest bidder, and lock the current bid, so bids don't even need to allocate any new memory. If you really really need on-chain arbitration, you can do it with a simple ownership contract for starters, then switch over to a governance contract as the arbitration needs become more complex for whatever reason.