DELEGATECALL vs CALL vs CALLCODE for second layer solutions

[tpmccallum]

What's your issue about?

This is a question

Could someone please let me know if Vyper will allow the use of DELEGATECALL OPCODE in its smart contracts? I see that the DELEGATECALL OPCODE is in the opcode file [1]

Here is some context

As I understand it, Vyper uses the CALL OPCODE for safety/security reasons. This makes sense. However, there is currently an immense amount of designing and coding of second layer solutions (side chains etc.).

These designs and implementations require interactive games (whereby participants on the side chain can provide proofs and so forth).

These interactive games require smart contracts to perform DELEGATECALLs as apposed to just CALLs.

How can it be fixed?

There is no fix required, it just is what it is.

Desired outcome

I would like to include this information in the Vyper chapter [2] of Mastering Ethereum.

I will be happy to just report the definitive answer. I think it would be really useful for developers to understand this important difference between Vyper and say Solidity in the event that they are designing and building second layer solutions.

Cute animal picture :)

Many thanks Tim

[1] https://github.com/ethereum/vyper/blob/master/vyper/opcodes.py [2] https://github.com/ethereumbook/ethereumbook/blob/tech-review2/vyper.asciidoc

[jacqueswww]

Hi Tim!

At this stage we don't allow direct use of the delegate call (we have identified one place where we will want to use it - #901) - interestingly enough no one has brought up the need for it yet either, and would be interesting to see how we approach it to maximise the secure use cases for it.

I think the main use case for it in a vyper sense will be when we implement the concept of libraries.

Syntax wise we would probably go with something like

contract Foo():
    def dosomething(amount: int128): delegate

And additionally constraint the usage to not allow storage changes after the call. @fubuloubu thoughts?

[fubuloubu]

I agree on the library insofar that it would be the first use case in Vyper that would directly require it (internal calls can use it as an optimization strategy, but I think that's out of scope for this discussion).

Supporting on-chain libraries would be a major feature to add to Vyper. It is not currently supported. We would have to discuss a mechanism for making sure security is respected when adding such a feature, and I have a feeling this is a longer term discussion involving ethPM integration and some checks of proper-initialization of the library. Uninitialized or improperly utilized libraries are a major source of security issues for the "not well versed" in EVM fundamentals, so a properly implemented feature with the Vyper Goal of making it maximally difficult to write insecure code would probably look much different than the equivalent Solidity.

---

Syntax-wise @jacqueswww I think that might work, but as I note above a LOT more considerations will be need to taken in account for how this feature looks in practice. I would say it's out of scope for Vyper's first release.

[charles-cooper]

this is a dup of https://github.com/vyperlang/vyper/issues/1015 - delegatecall can now be accessed with raw_call