Introduction
Vyper is an experimental, contract-oriented programing language for the Ethereum Virtual Machine that strives to supply superior suitability, by making it easier for developers to supply intelligible code. In fact, one among the principles of Vyper is to form it virtually impossible for developers to write down misleading code.
Vulnerabilities and Vyper
A recent study analyzed nearly a million deployed Ethereum smart contracts and located that a lot of those contracts contained serious vulnerabilities. The academics outlined three basic categories of trace vulnerabilities during their analysis:
Suicidal contracts
Smart contracts which will be killed by arbitrary addresses
Greedy contracts
Smart contracts will reach a state during which they can’t release ether
Prodigal contracts
Smart contracts which will be made to release ether to arbitrary addresses
Vulnerabilities are introduced into smart contracts via code. It’s going to be strongly argued that these and other vulnerabilities aren’t intentionally introduced, but regardless, undesirable smart contract code evidently leads to the unexpected loss of funds for Ethereum users, and this is often not ideal. Vyper is meant to form it easier to write down secure code, or equally to form it harder to accidentally write misleading or vulnerable code.
Comparison to Solidity
By deliberately omitting a number of Solidity’s features, Vyper tries to form unsafe code harder to write down. What features Vyper doesn’t have, and why, it’s important for those developing smart contracts in Vyper to know. Therefore, during this section, we’ll explore those features and supply justification for why they need to be omitted.
Modifiers
In Solidity, we’ll write a function using modifiers. For example, the subsequent function, changeOwner, will run the code during a modifier called onlyBy as a part of its execution:
function changeOwner(address _newOwner)
public
onlyBy(owner)
{
owner = _newOwner;
}
This modifier enforces a rule out reference to ownership. As we’ll see, this particular modifier acts as a mechanism to perform a pre-check on behalf of the changeOwner function:
modifier onlyBy(address _account)
{
require(msg.sender == _account);
_;
}
But modifiers aren’t just there to perform checks, as shown here. In fact, as modifiers, they will significantly change a sensible contract’s environment, within the context of the calling function. Put simply, modifiers are pervasive.
On the one hand, developers should check the other code that their own code is looking. However, it’s possible that in certain situations (like when time constraints or exhaustion end in lack of concentration) a developer may overlook one line of code. This is often even more likely if the developer has got to jump around inside an outsized file while mentally keeping track of the call hierarchy and committing the state of smart contract variables to memory.
Let’s check out the preceding example with a bit more depth. Visualize that a developer is writing a public function called A. The developer is new to this contract and is utilizing a modifier written by somebody else. At a look, it appears that the stageTimeConfirmation modifier is just performing some checks regarding the age of the accept reference to the calling function. What the developer might not realize is that the modifier is additionally calling another function, nextStage. During this simplistic demonstration scenario, simply calling the general public function a leads to the smart contract’s stage variable moving from SafeStage to DangerStage.
Vyper has done away with modifiers altogether. The recommendations from Vyper are as follows: if only performing assertions with modifiers, then simply use inline checks and asserts as a part of the function; if modifying smart contract state then forth, again make these changes explicitly a part of the function. Doing this improves audibility and readability because the reader doesn’t need to mentally (or manually) “wrap” the modifier code around the function to ascertain what it does.
Class Inheritance
Inheritance permits programmers to harness the facility of prewritten code by acquiring preexisting functionality, properties, and behaviors from existing software libraries. Inheritance promotes the reuse of code because inheritance is powerful. Solidity supports multiple inheritances also as polymorphism, but while these are key features of object-oriented programming, Vyper doesn’t support them. Vyper maintains that the implementation of inheritance requires coders and auditors to leap between multiple files so as to know what the program is doing. Vyper also takes the view that multiple inheritances can make code too complicated to understand—a view tacitly admitted by the Solidity documentation, which provides an example of how multiple inheritances are often problematic.
Inline Assembly
The inline assembly provides developers low-level contact to the Ethereum Virtual Machine, letting Solidity programs perform operations by directly accessing EVM instructions. For instance, the subsequent inline assembly code adds 3 to memory location 0x80:
3 0x80 mload add 0x80 mstore
Vyper considers the loss of readability to be too high a price to buy the additional power and thus doesn’t support inline assembly.
Function Overloading
Function overloading allows developers to write down multiple functions of an equivalent name. Which function is employed on a given occasion depends on the kinds of arguments supplied. Take the subsequent two functions, for example:
function f(uint _in) public pure returns (uint out) { out = 1; }
function f(uint _in, bytes32 _key) public pure returns (uint out) { out = 2; }
The first function named f accepts an input argument of type uint. The second function also named f takes two arguments, one among type uint and one among type bytes32. Having multiple function definitions with an equivalent name taking different arguments is often confusing, so Vyper doesn’t support function overloading.
For more details visit:https://www.technologiesinindustry4.com/2021/05/ethereum-smart-contracts-and-vyper.html
