Merge branch 'master' into fix/interface-intrinsic

charles-cooper · Oct 11, 2024 · 9621397 · 9621397
2 parents 2d5f67d + fdc05d6
commit 9621397
Show file tree

Hide file tree

Showing 107 changed files with 3,456 additions and 601 deletions.
diff --git a/.github/workflows/pull-request.yaml b/.github/workflows/pull-request.yaml
@@ -24,6 +24,7 @@ jobs:
         with:
           types: |
             feat
+            perf
             fix
             chore
             refactor

diff --git a/FUNDING.json b/FUNDING.json
@@ -0,0 +1,10 @@
+{
+  "drips": {
+    "ethereum": {
+      "ownedBy": "0x70CCBE10F980d80b7eBaab7D2E3A73e87D67B775"
+    }
+  },
+  "opRetro": {
+    "projectId": "0x9ca1f7b0e0d10d3bd2619e51a54f2e4175e029c87a2944cf1ebc89164ba77ea0"
+  }
+}
diff --git a/SECURITY.md b/SECURITY.md
@@ -3,7 +3,7 @@
 ## Supported Versions
 
 - it is recommended to follow the list of known [vulnerabilities](https://github.com/vyperlang/vyper/security/advisories) and stay up-to-date with the latest releases
-  - as of May 2024, the `0.4.0` release is the most secure and the most comprehensively reviewed one and is recommended for use in production environments
+  - as of May 2024, the [`0.4.0`](https://github.com/vyperlang/vyper/releases/tag/v0.4.0) release is the most comprehensively reviewed one and is recommended for use in production environments
 - if a compiler vulnerability is found, a new compiler version with a patch will be released. The vulnerable version itself is not updated (see the examples below).
   - `example1`: suppose `0.4.0` is the latest version and a hypothetical vulnerability is found in `0.4.0`, then a patch will be released in `0.4.1`
   - `example2`: suppose `0.4.0` is the latest version and a hypothetical vulnerability is found both in `0.3.10` and `0.4.0`, then a patch will be released only in `0.4.1`
@@ -26,7 +26,22 @@ we will add an entry to the list of security advisories for posterity and refere
 
 
 ## Bug Bounty Program
-- as of May 2024, Vyper does not have a bug bounty program. It is planned to instantiate one soon.
+- Vyper runs a bug bounty program via the Ethereum Foundation.
+  - Bugs should be reported through the [Ethereum Foundation's bounty program](https://ethereum.org/bug-bounty).
+
+### Scope
+- Rules from the Ethereum Foundation's bug bounty program apply; for any questions please reach out [here](mailto:[email protected]). Here we further clarify the scope of the Vyper bounty program.
+- If a compiler bug affects production code, it is in scope (excluding known issues).
+  - This includes bugs in older compiler versions still used in production.
+- If a compiler bug does not currently affect production but is likely to in the future, it is in scope.
+  - This mainly applies to the latest compiler release (e.g., a new release is available but contracts are not yet deployed with it).
+  - Experimental features (e.g. `--experimental-codegen`) are out of scope, as they are not intended for production and are unlikely to affect production code.
+  - Bugs in older compiler versions are generally out of scope, as they are no longer used for new contracts.
+    - There might be exceptions, e.g., when an L2 doesn't support recent compiler releases. In such cases, it might be reasonable for an older version to be used. It is up to the discretion of the EF & Vyper team to decide if the bug is in scope.
+- If a vulnerability affects multiple contracts, the whitehat is eligible for only one payout (though the severity of the bug may increase).
+- Eligibility for project-specific bounties is independent of this bounty.
+- [Security advisories](https://github.com/vyperlang/vyper/security/advisories) and [known issues](https://github.com/vyperlang/vyper/issues) are not eligible for the bounty program, as they are publicly disclosed and protocols should structure their contracts accordingly.
+- Individuals or organizations contracted or engaged specifically for security development, auditing, or testing of this project are ineligible for the bounty program.
 
 ## Reporting a Vulnerability
 

diff --git a/docs/built-in-functions.rst b/docs/built-in-functions.rst
@@ -264,7 +264,7 @@ Vyper has three built-ins for contract creation; all three contract creation bui
             x: uint256 = 123
             success, response = raw_call(
                 _target,
-                _abi_encode(x, method_id=method_id("someMethodName(uint256)")),
+                abi_encode(x, method_id=method_id("someMethodName(uint256)")),
                 max_outsize=32,
                 value=msg.value,
                 revert_on_failure=False
@@ -1023,7 +1023,7 @@ Utilities
         >>> ExampleContract.foo()
 	0xa9059cbb
 
-.. py:function:: _abi_encode(*args, ensure_tuple: bool = True) -> Bytes[<depends on input>]
+.. py:function:: abi_encode(*args, ensure_tuple: bool = True) -> Bytes[<depends on input>]
 
     Takes a variable number of args as input, and returns the ABIv2-encoded bytestring. Used for packing arguments to raw_call, EIP712 and other cases where a consistent and efficient serialization method is needed.
     Once this function has seen more use we provisionally plan to put it into the ``ethereum.abi`` namespace.
@@ -1041,7 +1041,7 @@ Utilities
         def foo() -> Bytes[132]:
             x: uint256 = 1
             y: Bytes[32] = b"234"
-            return _abi_encode(x, y, method_id=method_id("foo()"))
+            return abi_encode(x, y, method_id=method_id("foo()"))
 
     .. code-block:: vyper
 
@@ -1052,15 +1052,18 @@ Utilities
         "0000000000000000000000000000000000000000000000000000000000000003"
         "3233340000000000000000000000000000000000000000000000000000000000"
 
+    .. note::
+        Prior to v0.4.0, this function was named ``_abi_encode``.
+
 
-.. py:function:: _abi_decode(b: Bytes, output_type: type_, unwrap_tuple: bool = True) -> Any
+.. py:function:: abi_decode(b: Bytes, output_type: type_, unwrap_tuple: bool = True) -> Any
 
     Takes a byte array as input, and returns the decoded values according to the specified output types. Used for unpacking ABIv2-encoded values.
     Once this function has seen more use we provisionally plan to put it into the ``ethereum.abi`` namespace.
 
     * ``b``: A byte array of a length that is between the minimum and maximum ABIv2 size bounds of the ``output type``.
     * ``output_type``: Name of the output type, or tuple of output types, to be decoded.
-    * ``unwrap_tuple``: If set to True, the input is decoded as a tuple even if only one output type is specified. In other words, ``_abi_decode(b, Bytes[32])`` gets decoded as ``(Bytes[32],)``. This is the convention for ABIv2-encoded values generated by Vyper and Solidity functions. Except for very specific use cases, this should be set to True. Must be a literal.
+    * ``unwrap_tuple``: If set to True, the input is decoded as a tuple even if only one output type is specified. In other words, ``abi_decode(b, Bytes[32])`` gets decoded as ``(Bytes[32],)``. This is the convention for ABIv2-encoded values generated by Vyper and Solidity functions. Except for very specific use cases, this should be set to True. Must be a literal.
 
     Returns the decoded value(s), with type as specified by `output_type`.
 
@@ -1071,9 +1074,12 @@ Utilities
         def foo(someInput: Bytes[128]) -> (uint256, Bytes[32]):
             x: uint256 = empty(uint256)
             y: Bytes[32] = empty(Bytes[32])
-            x, y =  _abi_decode(someInput, (uint256, Bytes[32]))
+            x, y =  abi_decode(someInput, (uint256, Bytes[32]))
             return x, y
 
+    .. note::
+        Prior to v0.4.0, this function was named ``_abi_decode``.
+
 
 .. py:function:: print(*args, hardhat_compat=False) -> None
 
@@ -1084,3 +1090,6 @@ Utilities
 .. note::
 
     Issuing of the static call is *NOT* mode-dependent (that is, it is not removed from production code), although the compiler will issue a warning whenever ``print`` is used.
+
+.. warning::
+    In Vyper, as of v0.4.0, the order of argument evaluation of builtins is not defined. That means that the compiler may choose to reorder evaluation of arguments. For example, ``extract32(x(), y())`` may yield unexpected results if ``x()`` and ``y()`` both touch the same data. For this reason, it is best to avoid calling functions with side-effects inside of builtins. For more information, see `GHSA-g2xh-c426-v8mf <https://github.com/vyperlang/vyper/security/advisories/GHSA-g2xh-c426-v8mf>`_ and `issue #4019 <https://github.com/vyperlang/vyper/issues/4019>`_.
diff --git a/docs/compiling-a-contract.rst b/docs/compiling-a-contract.rst
@@ -308,10 +308,10 @@ The following example describes the expected input format of ``vyper-json``. (Co
             //    devdoc - Natspec developer documentation
             //    evm.bytecode.object - Bytecode object
             //    evm.bytecode.opcodes - Opcodes list
+            //    evm.bytecode.sourceMap - Source mapping (useful for debugging)
             //    evm.deployedBytecode.object - Deployed bytecode object
             //    evm.deployedBytecode.opcodes - Deployed opcodes list
-            //    evm.deployedBytecode.sourceMap - Solidity-style source mapping
-            //    evm.deployedBytecode.sourceMapFull - Deployed source mapping (useful for debugging)
+            //    evm.deployedBytecode.sourceMap - Deployed source mapping (useful for debugging)
             //    evm.methodIdentifiers - The list of function hashes
             //
             // Using `evm`, `evm.bytecode`, etc. will select every target part of that output.
@@ -388,15 +388,37 @@ The following example describes the output format of ``vyper-json``. Comments ar
                             // The bytecode as a hex string.
                             "object": "00fe",
                             // Opcodes list (string)
-                            "opcodes": ""
+                            "opcodes": "",
+                            // The deployed source mapping.
+                            "sourceMap": {
+                                "breakpoints": [],
+                                "error_map": {},
+                                "pc_ast_map": {},
+                                "pc_ast_map_item_keys": [],
+                                "pc_breakpoints": [],
+                                "pc_jump_map": {},
+                                "pc_pos_map": {},
+                                // The deployed source mapping as a string.
+                                "pc_pos_map_compressed": ""
+                            }
                         },
                         "deployedBytecode": {
                             // The deployed bytecode as a hex string.
                             "object": "00fe",
                             // Deployed opcodes list (string)
                             "opcodes": "",
-                            // The deployed source mapping as a string.
-                            "sourceMap": ""
+                            // The deployed source mapping.
+                            "sourceMap": {
+                                "breakpoints": [],
+                                "error_map": {},
+                                "pc_ast_map": {},
+                                "pc_ast_map_item_keys": [],
+                                "pc_breakpoints": [],
+                                "pc_jump_map": {},
+                                "pc_pos_map": {},
+                                // The deployed source mapping as a string.
+                                "pc_pos_map_compressed": ""
+                            }
                         },
                         // The list of function hashes
                         "methodIdentifiers": {

diff --git a/docs/constants-and-vars.rst b/docs/constants-and-vars.rst
@@ -26,6 +26,7 @@ Name                  Type             Value
 ``chain.id``          ``uint256``      Chain ID
 ``msg.data``          ``Bytes``        Message data
 ``msg.gas``           ``uint256``      Remaining gas
+``msg.mana``          ``uint256``      Remaining gas (alias for ``msg.gas``)
 ``msg.sender``        ``address``      Sender of the message (current call)
 ``msg.value``         ``uint256``      Number of wei sent with the message
 ``tx.origin``         ``address``      Sender of the transaction (full call chain)

diff --git a/docs/index.rst b/docs/index.rst
@@ -6,14 +6,17 @@
 Vyper
 #####
 
-Vyper is a contract-oriented, pythonic programming language that targets the `Ethereum Virtual Machine (EVM) <https://ethereum.org/learn/#ethereum-basics>`_.
+Vyper is a contract-oriented, Pythonic programming language that targets the `Ethereum Virtual Machine (EVM) <https://ethereum.org/learn/#ethereum-basics>`_.
+It prioritizes user safety, encourages clear coding practices via language design and efficient execution. In other words, Vyper code is safe, clear and efficient!
 
 Principles and Goals
 ====================
 
 * **Security**: It should be possible and natural to build secure smart-contracts in Vyper.
 * **Language and compiler simplicity**: The language and the compiler implementation should strive to be simple.
-* **Auditability**: Vyper code should be maximally human-readable. Furthermore, it should be maximally difficult to write misleading code. Simplicity for the reader is more important than simplicity for the writer, and simplicity for readers with low prior experience with Vyper (and low prior experience with programming in general) is particularly important.
+* **Auditability**: Vyper code should be maximally human-readable.
+  Furthermore, it should be maximally difficult to write misleading code.
+  Simplicity for the reader is more important than simplicity for the writer, and simplicity for readers with low prior experience with Vyper (and low prior experience with programming in general) is particularly important.
 
 Because of this Vyper provides the following features:
 

diff --git a/docs/installing-vyper.rst b/docs/installing-vyper.rst
@@ -7,50 +7,55 @@ any errors.
 
 .. note::
 
-    The easiest way to experiment with the language is to use the `Remix online compiler <https://remix.ethereum.org>`_.
-    (Activate the vyper-remix plugin in the Plugin manager.)
+    The easiest way to experiment with the language is to use either `Try Vyper! <https://try.vyperlang.org>`_ (maintained by the Vyper team) or the `Remix online compiler <https://remix.ethereum.org>`_ (maintained by the Ethereum Foundation).
+    - To use Try Vyper, go to https://try.vyperlang.org and log in (requires Github login).
+    - To use remix, go to https://remix.ethereum.org and activate the vyper-remix plugin in the Plugin manager.
 
-Docker
-******
 
-Vyper can be downloaded as docker image from `dockerhub <https://hub.docker.com/r/vyperlang/vyper/tags?page=1&ordering=last_updated>`_:
-::
+Standalone
+**********
 
-    docker pull vyperlang/vyper
+The Vyper CLI can be installed with any ``pip`` compatible tool, for example, ``pipx`` or ``uv tool``. If you do not have ``pipx`` or ``uv`` installed, first, go to the respective tool's installation page:
 
-To run the compiler use the ``docker run`` command:
-::
+- https://github.com/pypa/pipx?tab=readme-ov-file
+- https://github.com/astral-sh/uv?tab=readme-ov-file#uv
 
-    docker run -v $(pwd):/code vyperlang/vyper /code/<contract_file.vy>
+Then, the command to install Vyper would be
 
-Alternatively you can log into the docker image and execute vyper on the prompt.
 ::
 
-    docker run -v $(pwd):/code/ -it --entrypoint /bin/bash vyperlang/vyper
-    root@d35252d1fb1b:/code# vyper <contract_file.vy>
+    pipx install vyper
+
+Or,
 
-The normal parameters are also supported, for example:
 ::
 
-    docker run -v $(pwd):/code vyperlang/vyper -f abi /code/<contract_file.vy>
-    [{'name': 'test1', 'outputs': [], 'inputs': [{'type': 'uint256', 'name': 'a'}, {'type': 'bytes', 'name': 'b'}], 'constant': False, 'payable': False, 'type': 'function', 'gas': 441}, {'name': 'test2', 'outputs': [], 'inputs': [{'type': 'uint256', 'name': 'a'}], 'constant': False, 'payable': False, 'type': 'function', 'gas': 316}]
+    uv tool install vyper
 
-.. note::
 
-    If you would like to know how to install Docker, please follow their `documentation <https://docs.docker.com/get-docker/>`_.
+Binaries
+********
+
+Alternatively, prebuilt Vyper binaries for Windows, Mac and Linux are available for download from the GitHub releases page: https://github.com/vyperlang/vyper/releases.
+
 
 PIP
 ***
 
 Installing Python
 =================
 
-Vyper can only be built using Python 3.6 and higher. If you need to know how to install the correct version of python,
+Vyper can only be built using Python 3.10 and higher. If you need to know how to install the correct version of python,
 follow the instructions from the official `Python website <https://wiki.python.org/moin/BeginnersGuide/Download>`_.
 
 Creating a virtual environment
 ==============================
 
+Because pip installations are not isolated by default, this method of
+installation is meant for more experienced Python developers who are using
+Vyper as a library, or want to use it within a Python project with other
+pip dependencies.
+
 It is **strongly recommended** to install Vyper in **a virtual Python
 environment**, so that new packages installed and dependencies built are
 strictly contained in your Vyper project and will not alter or affect your
@@ -76,13 +81,43 @@ Each tagged version of vyper is uploaded to `pypi <https://pypi.org/project/vype
 To install a specific version use:
 ::
 
-    pip install vyper==0.3.7
+    pip install vyper==0.4.0
 
 You can check if Vyper is installed completely or not by typing the following in your terminal/cmd:
 ::
 
     vyper --version
 
+
+Docker
+******
+
+Vyper can be downloaded as docker image from `dockerhub <https://hub.docker.com/r/vyperlang/vyper/tags?page=1&ordering=last_updated>`_:
+::
+
+    docker pull vyperlang/vyper
+
+To run the compiler use the ``docker run`` command:
+::
+
+    docker run -v $(pwd):/code vyperlang/vyper /code/<contract_file.vy>
+
+Alternatively you can log into the docker image and execute vyper on the prompt.
+::
+
+    docker run -v $(pwd):/code/ -it --entrypoint /bin/bash vyperlang/vyper
+    root@d35252d1fb1b:/code# vyper <contract_file.vy>
+
+The normal parameters are also supported, for example:
+::
+
+    docker run -v $(pwd):/code vyperlang/vyper -f abi /code/<contract_file.vy>
+    [{'name': 'test1', 'outputs': [], 'inputs': [{'type': 'uint256', 'name': 'a'}, {'type': 'bytes', 'name': 'b'}], 'constant': False, 'payable': False, 'type': 'function', 'gas': 441}, {'name': 'test2', 'outputs': [], 'inputs': [{'type': 'uint256', 'name': 'a'}], 'constant': False, 'payable': False, 'type': 'function', 'gas': 316}]
+
+.. note::
+
+    If you would like to know how to install Docker, please follow their `documentation <https://docs.docker.com/get-docker/>`_.
+
 nix
 ***
 

diff --git a/docs/interfaces.rst b/docs/interfaces.rst
@@ -85,10 +85,6 @@ The ``default_return_value`` parameter can be used to handle ERC20 tokens affect
     extcall IERC20(USDT).transfer(msg.sender, 1, default_return_value=True) # returns True
     extcall IERC20(USDT).transfer(msg.sender, 1) # reverts because nothing returned
 
-.. warning::
-
-   When ``skip_contract_check=True`` is used and the called function returns data (ex.: ``x: uint256 = SomeContract.foo(skip_contract_check=True)``, no guarantees are provided by the compiler as to the validity of the returned value. In other words, it is undefined behavior what happens if the called contract did not exist. In particular, the returned value might point to garbage memory. It is therefore recommended to only use ``skip_contract_check=True`` to call contracts which have been manually ensured to exist at the time of the call.
-
 Built-in Interfaces
 ===================