LJandxermicus
a4163512ff
# Description
Compilation times for resolc were significantly slower than solc when:
* Multiple files were included in the JSON input file via
`--standard-json`
* And none of the files requested code generation
* (If only a subset of files requested code generation, both resolc and
solc were very slow)
Reason:
* Resolc unconditionally generated bytecode for all contracts, even if
not requested.
* When compiling to PolkaVM bytecode, we need to pass additional flags
(e.g. `irOptimized`) to solc. If these flags were not explicitly
requested, resolc also added these to the requested output since PolkaVM
bytecode was always generated.
## Breaking Changes
The following changes are breaking, but fix the semantics to match its
intended behavior:
* Compiling with `--standard-json` now compiles to PolkaVM bytecode
***only*** for the contracts explicitly requested in the
`outputSelection`.
* Compiling with `--standard-json` now outputs ***only*** the explicitly
requested output (e.g. `evm.assembly`, `evm.bytecode`, `ast`, etc.).
```jsonc
// Example:
{
"settings": {
// ...
"outputSelection": {
"src/common/GasService.sol": {
// Contracts in this file will generate bytecode.
// Only these fields of the JSON output selection will be in the `contracts` output.
"*": ["abi", "evm.methodIdentifiers", "metadata", "evm.bytecode"],
// Only this field of the JSON output selection will be in the `sources` output.
"": ["ast"]
},
"src/common/Gateway.sol": {
// No contracts in this file will generate bytecode.
"*": ["abi", "evm.methodIdentifiers", "metadata"],
// No `ast` will be in the `sources` output (only the automatically added `id`,
// similar to solc as this is not a configurable output selection).
"": []
},
}
}
}
```
## Performance Improvements
When e.g. the standard JSON input file includes multiple files and
requests output for every contract as per this setting:
```jsonc
{
"settings": {
// ...
"optimizer": { "enabled": true, "runs": 1 },
"viaIR": true,
"outputSelection": {
"src/common/GasService.sol": {
"*": ["abi", "evm.methodIdentifiers", "metadata", "evm.bytecode"],
},
// Rest of files..
}
}
}
```
The differences in compilation times depending on whether `evm.bytecode`
is selected in every file, one file, or no files can be seen below:
| Solc Optimizer (runs=1) | ViaIR | Request `abi`,
`evm.methodIdentifiers`, `metadata` | Request `evm.bytecode` | resolc
before | resolc after | solc v0.8.33 |
|:-----------------------:|:-----:|:---------:|:---------:|:-------------:|:------------:|:----------:|
| ✅ | ✅ | All files | All files | `~14.5s` | `~14.5s` | `~13.5s` |
| ✅ | ✅ | All files | One file | `~14.5s` | `~450ms` | `~13.5s` |
| ✅ | ✅ | All files | No files | `~14.5s` | `~390ms` | `~350ms` |
**Observations:**
* `resolc before` is roughly the same no matter the request
* This is due to unconditionally generating bytecode
* When not requesting bytecode for any contracts:
* `resolc after` now compiles in ~390ms (vs ~14.5s), similar to `solc`
* Neither `solc` nor `resolc after` generates bytecode when none of the
contracts request it
* When requesting bytecode for all contracts in _only one_ file:
* `resolc after` now compiles in ~450ms (vs ~14.5s)
* `solc` still compiles in the same time as when requesting bytecode for
all contracts in all files
* This is something they have tried to improve (see
[Solidity#15373](https://github.com/argotorg/solidity/issues/15373) and
[Solidity#15615](https://github.com/argotorg/solidity/issues/15615)),
and the intended behavior seems to now be that bytecode should only be
generated when explicitly requested for each contract.
* Even though PRs have merged to try to fix it, their issue seems to
persist as of v0.8.33.
# Open Questions
* Foundry:
* [x] Pruning of the AST:
* Just saw [this past
commit](https://github.com/paritytech/revive/pull/385) to not prune the
AST for Foundry compatibility.
* Can Foundry not explicitly request `"": "ast"`?
* **Answer:**
* Pruning the AST when not requested should be fine, as long as Foundry
explicitly requests it when needed.
* Will be tested by Foundry maintainer.
# Review Notes
Changes in `docs/` (~25 files) can be skipped as they are automatically
updated after adding content to `book/` and rebuilding it.
# Resolved Issues
Closes #326
---------
Co-authored-by: xermicus <cyrill@parity.io>
revive
Yul recompiler to LLVM, targetting RISC-V on PolkaVM.
Check the docs or visit contracts.polkadot.io to learn more about revive and contracts on Polkadot!
Discussion around the development is hosted on the Polkadot Forum.
Warning
Solidity on PVM is running on the
pallet-reviveruntime. This introduces observable semantic differences in comparison with the EVM.Study the differences section carefully. Ignoring these differences may lead to defunct contracts.
Notable examples:
- The 63/64 gas rule isn't implemented in the pallet (introduces potential DoS vector when calling other contracts)
- Contract instantiation works differently (by hash instead of by code)
- The gas model implemented by
pallet-revivediffers from Ethereum- The heap size is fixed instead of gas-metered and there's a fixed amount of stack size (contracts working fine on EVM may trap on PVM)
Installation
Building Solidity contracts for PolkaVM requires installing the following two compilers:
resolc: The revive Solidity compiler Yul frontend and PolkaVM code generator (provided by this repository).solc: The Ethereum Solidity reference compiler implemenation.resolcusessolcduring the compilation process, please refer to the Ethereum Solidity documentation for installation instructions.
resolc binary releases
resolc is distributed as a standalone binary (with solc as the only external dependency). Please download one of our binary releases for your target platform and mind the platform specific instructions below. We also provide nightly builds.
MacOS users
MacOS users need to clear the
downloadedattribute from the binary and set the executable flag.xattr -rc resolc-universal-apple-darwin chmod +x resolc-universal-apple-darwin
Linux users
Linux users need to set the executable flag.
chmod +x resolc-x86_64-unknown-linux-musl
resolc NPM package
We distribute the revive compiler as node.js module and hardhat plugin.
Note: The solc dependency is bundled via NPM packaging and defaults to the latest supported version.
Building from source
Building revive requires a stable Rust installation and a C++ toolchain for building LLVM on your system.
LLVM
revive depends on a custom build of LLVM v18.1.8 with the RISC-V embedded target, including the compiler-rt builtins. You can either download a build from our releases (recommended for older hardware) or build it from source.
Download from our LLVM releases
Download the latest LLVM build from our releases.
MacOS users need to clear the
downloadedattribute from all binaries after extracting the archive:xattr -rc </path/to/the/extracted/archive>/target-llvm/gnu/target-final/bin/*
After extracting the archive, point $LLVM_SYS_181_PREFIX to it:
export LLVM_SYS_181_PREFIX=</path/to/the/extracted/archive>/target-llvm/gnu/target-final
Building from source
The Makefile provides a shortcut target to obtain a compatible LLVM build, using the provided revive-llvm utility. Once installed, point $LLVM_SYS_181_PREFIX to the installation afterwards:
make install-llvm
export LLVM_SYS_181_PREFIX=${PWD}/target-llvm/gnu/target-final
The resolc Solidity frontend
To build the resolc Solidity frontend executable, make sure you have obtained a compatible LLVM build and did export the LLVM_SYS_181_PREFIX environment variable pointing to it (see above).
To install the resolc Solidity frontend executable:
make install-bin
resolc --version
Development
Please consult the Developer Guide to learn more about how contribute to the project.
Acknowledgements
The revive compiler project, after some early experiments with EVM bytecode translations, decided to fork the era-compiler framework.
Frontend, code generator and some supporting libraries are based of ZKSync zksolc. I'd like to express my gratitude and thank the original authors for providing a useable code base under a generous license.