3 ms·

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

by 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.

by px43 6y ago

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.