curve-contract VS vyper

In terms of DeFi codebases I'd recommend that you read the code of a project you're already familiar with. That way you know what to expect. Good codebases IMHO are the Curve one (written in Vyper and well documented), Harvest strategies and yearn strategies: - https://github.com/curvefi/curve-contract - https://github.com/harvest-finance/harvest-strategy - https://github.com/yearn/yearn-protocol

🚧 To do this, we need to create a mocks/ folder inside the contracts/ folder, and within it, create an Token.vy file. You can add the code from the following link to this file: Vyper ERC20 Token.

Patrick Collins, CEO of uh "Chain Accel / Cyfrin / Alpha Chain" (video, kinda) gave a different kind of talk than most, focusing on the differences between Solidity and Vyper in terms of their compilation strategies and optimizations. Maybe it's just nice to see a talk that's just a collection of technical fun facts rather than trying to shill me on their product. I'll admit I didn't realize people still used Vyper, but I'm not a smart contract dev and their github is still active at least. An interesting look into compiled EVM bytecode/opcode.

Feel stuck? Take a look at the Vyperlang Official Implemenation

Vyper - Pythonic Smart Contract Language for the EVM

Create a new file named SampleToken.vy in contracts/ directory. Then implement a smart contract while referring to the Vyper ERC20 example.

1) Research the community that surrounds the project and see how the general ecosystem works. Normally, on Discord or Telegram you can start talking with devs and get a deeper understanding of the project. 2) Try to narrow down, which kind of project you want to contribute. A DEX / DeFi project like UniSwap or SushiSwap or yarn.finance? Or more like a tool like MetaMask? Or even, more like an Ethereum client like Besu, Geth or Erigon? Or even, Vyper or Solidity?

You could try Vyper if you'd want to try developing smart contracts.

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

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

[1] https://github.com/ActorForth/evm-assembler/blob/master/docs...