From acc7d8f9f8bfc9a2ff2efb143953aeb18e8627bd Mon Sep 17 00:00:00 2001 From: Abinav Puthan Purayil Date: Sun, 8 Sep 2024 12:14:14 +0200 Subject: [PATCH] Define a custom CI and add docs for the downstream toolchain This change also updates the changelog, README (and related files) etc. The custom CI is authored by Anton Baliasnikov and the rest is authored by Oleksandr Zarudnyi . --- .github/CODEOWNERS | 1 - .github/ISSUE_TEMPLATE/bug_report.md | 55 ++-- .github/ISSUE_TEMPLATE/config.yml | 5 - .github/ISSUE_TEMPLATE/documentation_issue.md | 20 -- .github/ISSUE_TEMPLATE/feature_request.md | 42 +-- .github/actions/solc-build/action.yml | 110 ++++++++ .github/pull_request_template.md | 19 ++ .github/workflows/build-release.yaml | 134 ++++++++++ .github/workflows/buildpack-deps.yml | 46 ---- .github/workflows/stale.yml | 51 ---- .github/workflows/test.yaml | 131 ++++++++++ .github/workflows/welcome-external-pr.yml | 37 --- .truffleignore | 1 + CODE_OF_CONDUCT.md | 74 ------ CODING_STYLE.md | 243 ------------------ CONTRIBUTING.md | 42 ++- Changelog.md | 19 ++ README.md | 104 ++------ ReleaseChecklist.md | 123 --------- ReviewChecklist.md | 200 -------------- SECURITY.md | 122 +++++---- eraLogo.svg | 13 + 22 files changed, 595 insertions(+), 997 deletions(-) delete mode 100644 .github/CODEOWNERS delete mode 100644 .github/ISSUE_TEMPLATE/config.yml delete mode 100644 .github/ISSUE_TEMPLATE/documentation_issue.md create mode 100644 .github/actions/solc-build/action.yml create mode 100644 .github/pull_request_template.md create mode 100644 .github/workflows/build-release.yaml delete mode 100644 .github/workflows/buildpack-deps.yml delete mode 100644 .github/workflows/stale.yml create mode 100644 .github/workflows/test.yaml delete mode 100644 .github/workflows/welcome-external-pr.yml create mode 100644 .truffleignore delete mode 100644 CODE_OF_CONDUCT.md delete mode 100644 CODING_STYLE.md delete mode 100644 ReleaseChecklist.md delete mode 100644 ReviewChecklist.md create mode 100644 eraLogo.svg diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS deleted file mode 100644 index d50c44566a..0000000000 --- a/.github/CODEOWNERS +++ /dev/null @@ -1 +0,0 @@ -/docs/style-guide.rst @fulldecent diff --git a/.github/ISSUE_TEMPLATE/bug_report.md b/.github/ISSUE_TEMPLATE/bug_report.md index 30c09039ef..2d3e38a63a 100644 --- a/.github/ISSUE_TEMPLATE/bug_report.md +++ b/.github/ISSUE_TEMPLATE/bug_report.md @@ -1,46 +1,39 @@ --- -name: Bug Report -about: Problems, deficiencies, inaccuracies or crashes discovered on Solidity. +name: Bug report +about: Use this template for reporting issues title: '' -labels: 'bug :bug:' +labels: bug assignees: '' - --- - +#### πŸ€” Expected Behavior -## Description +Describe what you expected to happen. - +#### 😯 Current Behavior -## Environment +Describe what actually happened. -- Compiler version: -- Target EVM version (as per compiler settings): -- Framework/IDE (e.g. Truffle or Remix): -- EVM execution environment / backend / blockchain client: -- Operating system: +#### πŸ–₯️ Environment -## Steps to Reproduce +Any relevant environment details. - diff --git a/.github/ISSUE_TEMPLATE/config.yml b/.github/ISSUE_TEMPLATE/config.yml deleted file mode 100644 index 69f42abb0f..0000000000 --- a/.github/ISSUE_TEMPLATE/config.yml +++ /dev/null @@ -1,5 +0,0 @@ -blank_issues_enabled: false -contact_links: - - name: Initiate a language design or feedback discussion - url: https://forum.soliditylang.org - about: Open a thread on the Solidity forum. diff --git a/.github/ISSUE_TEMPLATE/documentation_issue.md b/.github/ISSUE_TEMPLATE/documentation_issue.md deleted file mode 100644 index 91082a9aaf..0000000000 --- a/.github/ISSUE_TEMPLATE/documentation_issue.md +++ /dev/null @@ -1,20 +0,0 @@ ---- -name: Documentation Issue -about: Corrections, improvements or requests for new content on Solidity's documentation. -title: '' -labels: 'documentation :book:' -assignees: '' - ---- - -## Page - - - -## Abstract - - - -## Pull request - - diff --git a/.github/ISSUE_TEMPLATE/feature_request.md b/.github/ISSUE_TEMPLATE/feature_request.md index 7ec729b1c7..d921e066cc 100644 --- a/.github/ISSUE_TEMPLATE/feature_request.md +++ b/.github/ISSUE_TEMPLATE/feature_request.md @@ -1,43 +1,21 @@ --- -name: Feature Request -about: Ideas, comments or messages asking for a particular functionality to be added - to Solidity. +name: Feature request +about: Use this template for requesting features title: '' -labels: feature +labels: feat assignees: '' - --- - - -## Abstract - - - -## Motivation +### 🌟 Feature Request - +#### πŸ“ Description -## Specification +Provide a clear and concise description of the feature you'd like to see. - +#### πŸ€” Rationale -## Backwards Compatibility +Explain why this feature is important and how it benefits the project. - +Add any other context or information about the feature request here. diff --git a/.github/actions/solc-build/action.yml b/.github/actions/solc-build/action.yml new file mode 100644 index 0000000000..1e366d780a --- /dev/null +++ b/.github/actions/solc-build/action.yml @@ -0,0 +1,110 @@ +name: 'Build' +description: 'Builds solc executable.' +inputs: + release-suffix: + description: 'Release suffix.' + required: false + default: '' + zksync-version: + description: 'Release version.' + required: true + solc-version: + description: 'Solidity version.' + required: true + build-type: + description: 'Build type: candidate or reference' + required: false + default: 'candidate' + extra-args: + description: 'Extra arguments for cmake.' + required: false + default: '' +runs: + using: "composite" + steps: + + - name: Install Boost (MacOS and Linux) + if: runner.os != 'Windows' + shell: bash + env: + BOOST_DOWNLOAD_URL: "https://boostorg.jfrog.io/artifactory/main/release/1.83.0/source" + BOOST_FILENAME: "boost_1_83_0" + run: | + [ ${RUNNER_OS} = macOS ] && PARALLEL=$(sysctl -n hw.ncpu) || PARALLEL=$(nproc) + curl -L -o ${BOOST_FILENAME}.tar.gz "${BOOST_DOWNLOAD_URL}/${BOOST_FILENAME}.tar.gz" + tar xzf "${BOOST_FILENAME}.tar.gz" && cd ${BOOST_FILENAME} + if [ ${RUNNER_OS} = macOS ]; then + if [ ${RUNNER_ARCH} = X64 ]; then + ./bootstrap.sh --prefix=${PWD}/boost --with-python-version=2.7 + else + ./bootstrap.sh --prefix=${PWD}/boost + fi + else + ./bootstrap.sh --prefix=/boost + fi + ./b2 link=static runtime-link=static -j${PARALLEL} + ./b2 install -j${PARALLEL} + + - name: Build solc + shell: ${{ runner.os == 'Windows' && 'msys2 {0}' || 'bash' }} + env: + CXXFLAGS: "-Wno-narrowing" + run: | + set -x + mkdir -p ./build + cd ./build + [ ${RUNNER_OS} = macOS ] && PARALLEL=$(sysctl -n hw.ncpu) || PARALLEL=$(nproc) + if [ ${RUNNER_OS} != Windows ]; then + export BOOST_ROOT=/boost + fi + if [ ${RUNNER_OS} = Linux ]; then + COMPILER_FLAGS="-DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++" + fi + if [ ${RUNNER_OS} = Windows ]; then + COMPILER_FLAGS="-DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_CXX_FLAGS=-fuse-ld=lld -DUSE_LD_GOLD=OFF" + export LDFLAGS='-lbcrypt -lwsock32 -static' + fi + cmake .. \ + -DCMAKE_BUILD_TYPE="Release" ${COMPILER_FLAGS} \ + -DSOL_VERSION_ZKSYNC="${{ inputs.solc-version }}-${{ inputs.zksync-version }}" \ + -DSOLC_VERSION_ZKEVM="${{ inputs.solc-version }}-${{ inputs.zksync-version }}" \ + -DSOL_VERSION_ZKEVM="${{ inputs.solc-version }}-${{ inputs.zksync-version }}" \ + -DUSE_Z3=OFF \ + -DUSE_CVC4=OFF \ + -DTESTS=0 \ + -DBoost_NO_BOOST_CMAKE=TRUE \ + -DSOLC_LINK_STATIC=1 \ + -DSTATIC_LINKING=1 \ + -DPEDANTIC=OFF ${{ inputs.extra-args}} + if [[ ${{ inputs.solc-version}} == "0.4"* ]]; then + cmake --build . --config Release --parallel ${PARALLEL} --target jsoncpp-project + cmake --build . --config Release --parallel ${PARALLEL} --target range-v3-project + fi + cmake --build . --config Release --parallel ${PARALLEL} --target solc + [ "$RUNNER_OS" = "Windows" ] && WIN_SUFFIX=".exe" + cp ./solc/solc${WIN_SUFFIX} ./solc/solc-${{ inputs.solc-version }}-${{ inputs.build-type }}${WIN_SUFFIX} + + - name: Upload binary for testing + if: inputs.release-suffix == '' + uses: actions/upload-artifact@v4 + with: + name: solc-${{ inputs.solc-version }}-${{ inputs.build-type }} + path: ./build/solc/solc-${{ inputs.solc-version }}-${{ inputs.build-type }} + + - name: Prepare binary + if: inputs.release-suffix != '' + shell: ${{ runner.os == 'Windows' && 'msys2 {0}' || 'bash' }} + run: | + [ "$RUNNER_OS" = "Windows" ] && WIN_SUFFIX=".exe" + SOLC_BIN="./build/solc/solc${WIN_SUFFIX}" + mkdir -p ./releases/${{ inputs.release-suffix }} + strip "${SOLC_BIN}" + ${SOLC_BIN} --version + mv ${SOLC_BIN} ./releases/${{ inputs.release-suffix }}/solc-${{ inputs.release-suffix }}-${{ inputs.solc-version}}-${{ inputs.zksync-version }}${WIN_SUFFIX} + + - name: Upload binary for release + if: inputs.release-suffix != '' + uses: actions/upload-artifact@v4 + with: + name: release-${{ inputs.release-suffix }} + path: releases diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md new file mode 100644 index 0000000000..54b4193537 --- /dev/null +++ b/.github/pull_request_template.md @@ -0,0 +1,19 @@ +# What ❔ + + + + + +## Why ❔ + + + + +## Checklist + + + + +- [ ] PR title corresponds to the body of PR (we generate changelog entries from PRs). +- [ ] Tests for the changes have been added / updated. +- [ ] Documentation comments have been added / updated. diff --git a/.github/workflows/build-release.yaml b/.github/workflows/build-release.yaml new file mode 100644 index 0000000000..402462b251 --- /dev/null +++ b/.github/workflows/build-release.yaml @@ -0,0 +1,134 @@ +name: Build and release + +on: + workflow_dispatch: + pull_request: + push: + tags: + - "**" + +concurrency: + group: ${{ github.repository_id }}-${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }} + cancel-in-progress: true + +jobs: + + setup: + runs-on: ubuntu-latest + outputs: + solc-version: ${{ steps.set.outputs.solc-version }} + zksync-version: ${{ steps.set.outputs.zksync-version }} + skip-windows: ${{ steps.check-version.outputs.result }} + steps: + + - name: Checkout + uses: actions/checkout@v4 + with: + submodules: recursive + + - name: Define release version + shell: bash + id: set + run: | + if [[ ${{ github.event_name }} != 'pull_request' ]]; then + echo "zksync-version=$(cut -d "-" -f2 <<< ${GITHUB_REF#refs/*/})" | tee -a "${GITHUB_OUTPUT}" + else + echo "zksync-version=1.0.${{ github.run_id }}" | tee -a "${GITHUB_OUTPUT}" + fi + SOLC_VERSION=$(grep 'PROJECT_VERSION' CMakeLists.txt | grep -oP '(\d+\.\d+\.\d+)') + echo "solc-version=${SOLC_VERSION}" | tee -a "${GITHUB_OUTPUT}" + + - name: Setup Node.js + uses: actions/setup-node@v4 + with: + node-version: '20' + + - name: Install semver + run: npm install semver + + - name: Check that version is >= 0.6.0 + id: check-version + uses: actions/github-script@v7 + with: + script: | + const semver = require('semver'); + const currentVersion = '${{ steps.set.outputs.solc-version }}'; + const result = semver.lt(currentVersion, '0.6.0'); + console.log(`Is the version < 0.6.0? ${result}`); + return result; + result-encoding: string + + build: + needs: setup + strategy: + fail-fast: false + matrix: + include: + - name: "MacOS x86" + runner: macos-12-large + release-suffix: macosx-amd64 + - name: "MacOS arm64" + runner: [self-hosted, macOS, ARM64] + release-suffix: macosx-arm64 + - name: "Linux x86" + runner: matterlabs-ci-runner-high-performance + image: matterlabs/llvm_runner:ubuntu20-llvm17-latest + release-suffix: linux-amd64 + - name: "Linux ARM64" + runner: matterlabs-ci-runner-arm + image: matterlabs/llvm_runner:ubuntu20-llvm17-latest + release-suffix: linux-arm64 + - name: Windows + runner: windows-2019-github-hosted-64core + release-suffix: windows-amd64 + runs-on: ${{ matrix.runner }} + container: + image: ${{ matrix.image || '' }} + name: ${{ matrix.name }} + steps: + + - name: Checkout + uses: actions/checkout@v4 + with: + submodules: recursive + + - name: Prepare Windows env + if: runner.os == 'Windows' + uses: matter-labs/era-compiler-ci/.github/actions/prepare-msys@v1 + + - name: Building the Solidity compiler + uses: ./.github/actions/solc-build + with: + release-suffix: ${{ matrix.release-suffix }} + zksync-version: ${{ needs.setup.outputs.zksync-version }} + solc-version: ${{ needs.setup.outputs.solc-version }} + + release: + runs-on: ubuntu-latest + if: startsWith(github.ref, 'refs/tags/') + needs: build + steps: + + - name: Checkout + uses: actions/checkout@v4 + with: + submodules: recursive + + - name: Download artifacts + uses: actions/download-artifact@v4 + with: + pattern: release* + path: releases + + - name: Generate changelog + shell: bash + run: awk '/###/ {flag=!flag; if (seen++) exit; next} flag' ./Changelog.md > release-changelog.txt + + - name: Prepare release + uses: softprops/action-gh-release@v2 + with: + generate_release_notes: false + name: ZKsync solc ${{ github.ref_name }} + body_path: release-changelog.txt + tag_name: ${{ github.ref_name }} + files: releases/**/** diff --git a/.github/workflows/buildpack-deps.yml b/.github/workflows/buildpack-deps.yml deleted file mode 100644 index fe6da11e16..0000000000 --- a/.github/workflows/buildpack-deps.yml +++ /dev/null @@ -1,46 +0,0 @@ -name: buildpack-deps - -on: - pull_request: - branches: [ develop ] - paths: - - 'scripts/docker/buildpack-deps/Dockerfile.emscripten' - - 'scripts/docker/buildpack-deps/Dockerfile.ubuntu.clang.ossfuzz' - - 'scripts/docker/buildpack-deps/Dockerfile.ubuntu2004' - - 'scripts/docker/buildpack-deps/Dockerfile.ubuntu2404' - - 'scripts/docker/buildpack-deps/Dockerfile.ubuntu2404.clang' - -jobs: - buildpack-deps: - env: - GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} - DOCKERHUB_TOKEN: ${{ secrets.DOCKERHUB_TOKEN }} - DOCKER_REPOSITORY: solbuildpackpusher/solidity-buildpack-deps - IMAGE_NAME: buildpack-deps - - runs-on: ubuntu-latest - - strategy: - fail-fast: false - matrix: - image_variant: [emscripten, ubuntu.clang.ossfuzz, ubuntu2004, ubuntu2404, ubuntu2404.clang] - - steps: - - uses: actions/checkout@v4 - with: - fetch-depth: 0 - - - name: Upgrade ${{ env.IMAGE_NAME }}-${{ matrix.image_variant }} - run: | - echo ${DOCKERHUB_TOKEN} | docker login -u solbuildpackpusher --password-stdin - scripts/ci/docker_upgrade.sh ${{ env.IMAGE_NAME }} ${{ matrix.image_variant }} ${{ env.DOCKER_REPOSITORY }} - docker logout - - - name: comment PR - if: "env.DOCKER_IMAGE" - # NOTE: Can't update to v1.3.1 due to an error: `/entrypoint.sh:5:in 'require_relative': cannot load such file -- /lib/github (LoadError)` - uses: unsplash/comment-on-pr@ffe8f97ccc63ce12c3c23c6885b169db67958d3b #v1.3.0 - with: - msg: "`${{ env.DOCKER_IMAGE }} ${{ env.DOCKER_REPO_DIGEST }}`." - check_for_duplicate_msg: false - diff --git a/.github/workflows/stale.yml b/.github/workflows/stale.yml deleted file mode 100644 index d982c43f2b..0000000000 --- a/.github/workflows/stale.yml +++ /dev/null @@ -1,51 +0,0 @@ -name: Check stale issues and pull requests - -on: - workflow_dispatch: - schedule: - - cron: '0 12 * * *' - -permissions: - issues: write - pull-requests: write - -env: - BEFORE_ISSUE_STALE: 90 - BEFORE_ISSUE_CLOSE: 7 - BEFORE_PR_STALE: 14 - BEFORE_PR_CLOSE: 7 - -jobs: - stale: - runs-on: ubuntu-latest - steps: - - uses: actions/stale@v6 - with: - debug-only: false - days-before-issue-stale: ${{ env.BEFORE_ISSUE_STALE }} - days-before-issue-close: ${{ env.BEFORE_ISSUE_CLOSE }} - stale-issue-message: | - This issue has been marked as stale due to inactivity for the last ${{ env.BEFORE_ISSUE_STALE }} days. - It will be automatically closed in ${{ env.BEFORE_ISSUE_CLOSE }} days. - close-issue-message: | - Hi everyone! This issue has been automatically closed due to inactivity. - If you think this issue is still relevant in the latest Solidity version and you have something to [contribute](https://docs.soliditylang.org/en/latest/contributing.html), feel free to reopen. - However, unless the issue is a concrete proposal that can be implemented, we recommend starting a language discussion on the [forum](https://forum.soliditylang.org) instead. - ascending: true - stale-issue-label: stale - close-issue-label: 'closed due inactivity' - exempt-issue-labels: 'bug :bug:,epic,roadmap,selected for development,must have,must have eventually,smt' - stale-pr-message: | - This pull request is stale because it has been open for ${{ env.BEFORE_PR_STALE }} days with no activity. - It will be closed in ${{ env.BEFORE_PR_CLOSE }} days unless the `stale` label is removed. - close-pr-message: | - This pull request was closed due to a lack of activity for ${{ env.BEFORE_PR_CLOSE }} days after it was stale. - stale-pr-label: stale - close-pr-label: closed-due-inactivity - days-before-pr-stale: ${{ env.BEFORE_PR_STALE }} - days-before-pr-close: ${{ env.BEFORE_PR_CLOSE }} - exempt-pr-labels: 'external contribution :star:,roadmap,epic' - exempt-draft-pr: false - exempt-all-milestones: true - remove-stale-when-updated: true - operations-per-run: 256 diff --git a/.github/workflows/test.yaml b/.github/workflows/test.yaml new file mode 100644 index 0000000000..c72315b344 --- /dev/null +++ b/.github/workflows/test.yaml @@ -0,0 +1,131 @@ +name: Tests and benchmarks + +on: + pull_request: + workflow_dispatch: + inputs: + compiler_tester_reference_branch: + description: "compiler-tester branch to use as a benchmark reference" + required: false + default: "main" + compiler_tester_candidate_branch: + description: "compiler-tester branch to use as a benchmark candidate" + required: false + default: "era-solidity-test" + +concurrency: + group: ${{ github.repository_id }}-${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }} + cancel-in-progress: true + +jobs: + + compiler-tester-ref: + runs-on: ubuntu-latest + name: Compiler tester ref + outputs: + reference-ref: ${{ steps.compiler_tester_ref.outputs.reference-ref }} + candidate-ref: ${{ steps.compiler_tester_ref.outputs.candidate-ref }} + env: + ERA_SOLIDITY_TEST_TAG: era-solidity-test + ERA_SOLIDITY_REF_DEFAULT: main + steps: + + - name: Checkout + uses: actions/checkout@v4 + with: + repository: matter-labs/era-compiler-tester + + - name: Define compiler tester ref + id: compiler_tester_ref + shell: bash + run: | + REFERENCE_REF=${{ inputs.compiler_tester_reference_branch || env.ERA_SOLIDITY_REF_DEFAULT }} + if [ -n "$(git ls-remote --tags --heads --refs origin ${REFERENCE_REF})" ]; then + echo "reference-ref=${REFERENCE_REF}" | tee -a "${GITHUB_OUTPUT}" + else + echo "reference-ref=${{ env.ERA_SOLIDITY_REF_DEFAULT }}" | tee -a "${GITHUB_OUTPUT}" + fi + CANDIDATE_REF=${{ inputs.compiler_tester_candidate_branch || env.ERA_SOLIDITY_TEST_TAG }} + if [ -n "$(git ls-remote --tags --heads --refs origin ${CANDIDATE_REF})" ]; then + echo "candidate-ref=${CANDIDATE_REF}" | tee -a "${GITHUB_OUTPUT}" + else + echo "candidate-ref=${{ env.ERA_SOLIDITY_REF_DEFAULT }}" | tee -a "${GITHUB_OUTPUT}" + fi + + build: + strategy: + fail-fast: false + matrix: + include: + - type: "reference" + ref: ${{ github.base_ref }} + - type: "candidate" + ref: '' + runs-on: [ci-runner-compiler, Linux] + name: build-${{ matrix.type }} + container: + image: matterlabs/llvm_runner:ubuntu20-llvm17-latest + outputs: + solc-version: ${{ steps.project_version.outputs.solc-version }} + steps: + + - name: Checking out the Solidity repository + uses: actions/checkout@v4 + with: + ref: ${{ matrix.ref }} + submodules: recursive + + - name: Define project version + id: project_version + shell: bash + run: | + SOLC_VERSION=$(grep 'PROJECT_VERSION' CMakeLists.txt | grep -oP '(\d+\.\d+\.\d+)') + echo "solc-version=${SOLC_VERSION}" | tee -a "${GITHUB_OUTPUT}" + + - name: Building the Solidity compiler + if: matrix.type == 'candidate' + uses: ./.github/actions/solc-build + with: + solc-version: ${{ steps.project_version.outputs.solc-version }} + zksync-version: 1.0.${{ github.run_id }} + build-type: ${{ matrix.type }} + + - name: Building the Solidity compiler + if: matrix.type == 'reference' + uses: matter-labs/era-solidity/.github/actions/solc-build@latest-ci + with: + solc-version: ${{ steps.project_version.outputs.solc-version }} + zksync-version: 1.0.${{ github.run_id }} + build-type: ${{ matrix.type }} + + # Integration tests workflow call from the era-compiler-ci repository + # This is a common part of the integration tests workflow for all repositories + # If you would like to make a change to the integration tests workflow, please do it in the era-compiler-ci repository + integration-tests: + needs: [ compiler-tester-ref, build ] + uses: matter-labs/era-compiler-ci/.github/workflows/integration-tests.yaml@main + secrets: inherit + with: + compiler-tester-ref: ${{ needs.compiler-tester-ref.outputs.candidate-ref }} + path: 'tests/solidity/' + custom-solc-run-id: ${{ github.run_id }} + custom-solc-version: ${{ needs.build.outputs.solc-version }} + extra-args: --mode "${{ github.base_ref }}" + save-ccache: 'true' + ccache-key-type: 'static' + + + # Benchmarks workflow call from the era-compiler-ci repository + # This is a common part of the benchmarks workflow for all repositories + # If you would like to make a change to the benchmarks workflow, please do it in the era-compiler-ci repository + benchmarks: + needs: [ compiler-tester-ref, build ] + uses: matter-labs/era-compiler-ci/.github/workflows/benchmarks.yml@main + secrets: inherit + with: + compiler_tester_reference_branch: ${{ needs.compiler-tester-ref.outputs.reference-ref }} + compiler_tester_candidate_branch: ${{ needs.compiler-tester-ref.outputs.candidate-ref }} + compiler_llvm_benchmark_mode: '+M^B3 ${{ needs.build.outputs.solc-version }}' + compiler_llvm_benchmark_path: 'tests/solidity/' + custom-solc-run-id: ${{ github.run_id }} + custom-solc-version: ${{ needs.build.outputs.solc-version }} diff --git a/.github/workflows/welcome-external-pr.yml b/.github/workflows/welcome-external-pr.yml deleted file mode 100644 index ac8d1362ea..0000000000 --- a/.github/workflows/welcome-external-pr.yml +++ /dev/null @@ -1,37 +0,0 @@ -name: External contributor greeter - -on: - pull_request_target: - types: - - opened - -env: - DRY_RUN: false - -jobs: - comment-external-pr: - runs-on: ubuntu-latest - steps: - # Note: this step requires that the INTERNAL_CONTRIBUTORS environment variable - # is already defined in the repository with the current json list of internal contributors. - - name: Comment on external contribution PR - if: "!contains(fromJSON(vars.INTERNAL_CONTRIBUTORS), github.event.pull_request.user.login)" - env: - GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} - PR: ${{ github.event.pull_request.html_url }} - run: | - echo "Commenting in a newly submitted or reopened external PR: $PR" - if [[ $DRY_RUN == 'false' ]]; then - gh pr edit "$PR" --add-label "external contribution :star:" - comment_body=( - "Thank you for your contribution to the Solidity compiler! A team member will follow up shortly." - "\n\n" - "If you haven't read our [contributing guidelines](https://docs.soliditylang.org/en/latest/contributing.html) and our " - "[review checklist](https://github.com/ethereum/solidity/blob/develop/ReviewChecklist.md) before, " - "please do it now, this makes the reviewing process and accepting your contribution smoother." - "\n\n" - "If you have any questions or need our help, feel free to post them in the PR or talk to us directly on the " - "[#solidity-dev](https://matrix.to/#/#ethereum_solidity-dev:gitter.im) channel on Matrix." - ) - gh pr comment $PR --body "$(IFS='' ; echo -e "${comment_body[*]}")" - fi diff --git a/.truffleignore b/.truffleignore new file mode 100644 index 0000000000..3b2af7f987 --- /dev/null +++ b/.truffleignore @@ -0,0 +1 @@ +test/benchmarks/chains.sol diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md deleted file mode 100644 index 4c75649ae8..0000000000 --- a/CODE_OF_CONDUCT.md +++ /dev/null @@ -1,74 +0,0 @@ -# Contributor Covenant Code of Conduct - -## Our Pledge - -In the interest of fostering an open and welcoming environment, we as -contributors and maintainers pledge to making participation in our project and -our community a harassment-free experience for everyone, regardless of age, body -size, disability, ethnicity, sex characteristics, gender identity and expression, -level of experience, education, socio-economic status, nationality, personal -appearance, race, religion, or sexual identity and orientation. - -## Our Standards - -Examples of behavior that contributes to creating a positive environment -include: - -* Using welcoming and inclusive language -* Being respectful of differing viewpoints and experiences -* Gracefully accepting constructive criticism -* Focusing on what is best for the community -* Showing empathy towards other community members - -Examples of unacceptable behavior by participants include: - -* The use of sexualized language or imagery and unwelcome sexual attention or - advances -* Trolling, insulting/derogatory comments, and personal or political attacks -* Public or private harassment -* Publishing others' private information, such as a physical or electronic - address, without explicit permission -* Other conduct which could reasonably be considered inappropriate in a - professional setting - -## Our Responsibilities - -Project maintainers are responsible for clarifying the standards of acceptable -behavior and are expected to take appropriate and fair corrective action in -response to any instances of unacceptable behavior. - -Project maintainers have the right and responsibility to remove, edit, or -reject comments, commits, code, wiki edits, issues, and other contributions -that are not aligned to this Code of Conduct, or to ban temporarily or -permanently any contributor for other behaviors that they deem inappropriate, -threatening, offensive, or harmful. - -## Scope - -This Code of Conduct applies both within project spaces and in public spaces -when an individual is representing the project or its community. Examples of -representing a project or community include using an official project e-mail -address, posting via an official social media account, or acting as an appointed -representative at an online or offline event. Representation of a project may be -further defined and clarified by project maintainers. - -## Enforcement - -Instances of abusive, harassing, or otherwise unacceptable behavior may be -reported by contacting the project team at solidity@ethereum.org. -To report an issue involving the Solidity team please email JosΓ© Pedro Cabrita at zepedro@ethereum.org. -All complaints will be reviewed and investigated and will result in a response that -is deemed necessary and appropriate to the circumstances. The project team is -obligated to maintain confidentiality with regard to the reporter of an incident. -Further details of specific enforcement policies may be posted separately. - -Project maintainers who do not follow or enforce the Code of Conduct in good -faith may face temporary or permanent repercussions as determined by other -members of the project's leadership. - -## Attribution - -This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, -available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html - -[homepage]: https://www.contributor-covenant.org diff --git a/CODING_STYLE.md b/CODING_STYLE.md deleted file mode 100644 index 2305ae1ec7..0000000000 --- a/CODING_STYLE.md +++ /dev/null @@ -1,243 +0,0 @@ -## 0. Formatting - -**GOLDEN RULE**: Follow the style of the existing code when you make changes. - -1. Use tabs for leading indentation: - - tab stops are every 4 characters (only relevant for line length). - - one indentation level -> exactly one byte (i.e. a tab character) in the source file. -2. Line widths: - - Lines should be at most 99 characters wide to make diff views readable and reduce merge conflicts. - - Lines of comments should be formatted according to ease of viewing, but simplicity is to be preferred over beauty. -3. Single-statement blocks should not have braces, unless required for clarity. -4. Never place condition bodies on same line as condition. -5. Space between keyword and opening parenthesis, but not following opening parenthesis or before final parenthesis. -6. No spaces for unary operators, `->` or `.`. -7. No space before `:` but one after it, except in the ternary operator: one on both sides. -8. Add spaces around all other operators. -9. Braces, when used, always have their own lines and are at same indentation level as "parent" scope. -10. If lines are broken, a list of elements enclosed with parentheses (of any kind) and separated by a separator (of any kind) are formatted such that there is exactly one element per line, followed by the separator, the opening parenthesis is on the first line, followed by a line break and the closing parenthesis is on a line of its own unindented). See example below. - -Yes: -```cpp -if (a == b[i]) - printf("Hello\n"); // NOTE spaces used instead of tab here for clarity - first byte should be '\t'. -foo->bar( - someLongVariableName, - anotherLongVariableName, - anotherLongVariableName, - anotherLongVariableName, - anotherLongVariableName -); -cout << - "some very long string that contains completely irrelevant " << - "text that talks about this and that and contains the words " << - "\"lorem\" and \"ipsum\"" << - endl; -``` - -No: -```cpp -if( a==b[ i ] ) { printf ("Hello\n"); } -foo->bar(someLongVariableName, - anotherLongVariableName, - anotherLongVariableName, - anotherLongVariableName, - anotherLongVariableName); -cout << "some very long string that contains completely irrelevant text that talks about this and that and contains the words \"lorem\" and \"ipsum\"" << endl; -``` - -To set indentation and tab width settings uniformly, the repository contains an [EditorConfig](https://editorconfig.org/) [`.editorconfig`](https://github.com/ethereum/solidity/blob/develop/.editorconfig) file, which describes some of the styles used and which is recognized by many IDE's and editors. - -## 1. Namespaces - -1. No `using namespace` declarations in header files. -2. `using namespace solidity;` and other project local namespaces is fine in cpp files, and generally encouraged. -3. Avoid `using namespace` at file level for third party libraries, such as boost, ranges, etc. -4. All symbols should be declared in a namespace except for final applications. -5. Use anonymous namespaces for helpers whose scope is a cpp file only. -6. Preprocessor symbols should be prefixed with the namespace in all-caps and an underscore. - -Only in the header: -```cpp -#include -namespace myNamespace -{ -std::tuple meanAndSigma(std::vector const& _v); -} -``` - -## 2. Preprocessor - -1. File comment is always at top, and includes: - - Copyright - - License (e.g. see COPYING) -2. Never use `#ifdef`/`#define`/`#endif` file guards. Prefer `#pragma` once as first line below file comment. -3. Prefer static constexpr variables to value macros. -4. Prefer inline constexpr functions to function macros. -5. Split complex macro on multiple lines with `\`. - -## 3. Capitalization - -**GOLDEN RULE**: Preprocessor: `ALL_CAPS`; C++: `camelCase`. - -1. Use camelCase for splitting words in names, except where obviously extending STL/boost functionality in which case follow those naming conventions. -2. The following entities' first alpha is upper case: - - Type names - - Template parameters - - Enum members - - static const variables that form an external API. -3. All preprocessor symbols (macros, macro arguments) in full uppercase with underscore word separation. - -All other entities' first alpha is lower case. - -## 4. Variable prefixes - -1. Leading underscore "_" to parameter names: - - Exception: "o_parameterName" when it is used exclusively for output. See 6(f). - - Exception: "io_parameterName" when it is used for both input and output. See 6(f). -2. Leading "g_" to global (non-const) variables. -3. Leading "s_" to static (non-const, non-global) variables. - -## 5. Assertions - -Use `solAssert` and `solUnimplementedAssert` generously to check assumptions that span across different parts of the code base, for example before dereferencing a pointer. - -## 6. Declarations - -1. {Typename} + {qualifiers} + {name}. -2. Only one per line. -3. Associate */& with type, not variable (at ends with parser, but more readable, and safe if in conjunction with (b)). -4. Favour declarations close to use; do not habitually declare at top of scope ala C. -5. Pass non-trivial parameters as const reference, unless the data is to be copied into the function, then either pass by const reference or by value and use std::move. -6. If a function returns multiple values, use std::tuple (std::pair acceptable) or better introduce a struct type. Do not use */& arguments. -7. Use parameters of pointer type only if ``nullptr`` is a valid argument, use references otherwise. Often, ``std::optional`` is better suited than a raw pointer. -8. Never use a macro where adequate non-preprocessor C++ can be written. -9. Only use ``auto`` if the type is very long and rather irrelevant. -10. Do not pass bools: prefer enumerations instead. -11. Prefer enum class to straight enum. -12. Always initialize POD variables, even if their value is overwritten later. - -Yes: -```cpp -enum class Accuracy -{ - Approximate, - Exact -}; -struct MeanSigma -{ - float mean = 0.0f; - float standardDeviation = 1.0f; -}; -double const d = 0; -int i = 0; -int j = 0; -char* s = nullptr; -MeanAndSigma ms meanAndSigma(std::vector const& _v, Accuracy _a); -Derived* x = dynamic_cast(base); -for (auto i = x->begin(); i != x->end(); ++i) {} -``` - -No: -```cpp -const double d = 0; -int i, j; -char *s; -float meanAndSigma(std::vector _v, float* _sigma, bool _approximate); -Derived* x(dynamic_cast(base)); -for (map::iterator i = l.begin(); i != l.end(); ++l) {} -``` - -## 7. Structs & classes - -1. Structs to be used when all members public and no virtual functions: - - In this case, members should be named naturally and not prefixed with `m_`. -2. Classes to be used in all other circumstances. - -## 8. Members - -1. One member per line only. -2. Private, non-static, non-const fields prefixed with `m_`. -3. Avoid public fields, except in structs. -4. Use override, final and const as much as possible. -5. No implementations with the class declaration, except: - - template or force-inline method (though prefer implementation at bottom of header file). - - one-line implementation (in which case include it in same line as declaration). -6. For a property `foo` - - Member: `m_foo` - - Getter: `foo()` [ also: for booleans, `isFoo()` ] - - Setter: `setFoo()` - -## 9. Naming - -1. Avoid unpronounceable names. -2. Names should be shortened only if they are extremely common, but shortening should be generally avoided -3. Avoid prefixes of initials (e.g. do not use `IMyInterface`, `CMyImplementation`) -4. Find short, memorable & (at least semi-) descriptive names for commonly used classes or name-fragments: - - A dictionary and thesaurus are your friends; - - Spell correctly; - - Think carefully about the class's purpose; - - Imagine it as an isolated component to try to decontextualise it when considering its name; - - Don't be trapped into naming it (purely) in terms of its implementation. - -## 10. Type definitions - -1. Prefer `using` to `typedef`. e.g. `using ints = std::vector;` rather than typedef `std::vector ints;` -2. Generally avoid shortening a standard form that already includes all important information: - - e.g. stick to `shared_ptr` rather than shortening to `ptr`. -3. Where there are exceptions to this (due to excessive use and clear meaning), note the change prominently and use it consistently: - - e.g. `using Guard = std::lock_guard;` ///< Guard is used throughout the codebase since it is clear in meaning and used commonly. -4. In general expressions should be roughly as important/semantically meaningful as the space they occupy. -5. Avoid introducing aliases for types unless they are very complicated. Consider the number of items a brain can keep track of at the same time. - -## 11. Commenting - -1. Comments should be doxygen-compilable, using @notation rather than \notation. -2. Document the interface, not the implementation: - - Documentation should be able to remain completely unchanged, even if the method is reimplemented; - - Comment in terms of the method properties and intended alteration to class state (or what aspects of the state it reports); - - Be careful to scrutinise documentation that extends only to intended purpose and usage; - - Reject documentation that is simply an English transaction of the implementation. -3. Avoid in-code comments. Instead, try to extract blocks of functionality into functions. This often already eliminates the need for an in-code comment. - -## 12. Include Headers - -1. Includes should go in increasing order of generality (`libsolidity` -> `libevmasm` -> `libsolutil` -> `boost` -> `STL`). -2. The corresponding `.h` file should be the first include in the respective `.cpp` file. -3. Insert empty lines between blocks of include files. - -Example: -```cpp -#include - -#include -#include -#include -#include - -#include - -#include -#include - -#include -#include - -#include -#include -``` - -See [this issue](https://stackoverflow.com/questions/614302/c-header-order/614333#614333 "C header order") for the reason: this makes it easier to find missing includes in header files. - -## 13. Recommended reading - -- Herb Sutter and Bjarne Stroustrup: - - [C++ Core Guidelines](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md) - -- Herb Sutter and Andrei Alexandrescu: - - "C++ Coding Standards: 101 Rules, Guidelines, and Best Practices" - -- Scott Meyers: - - "Effective C++: 55 Specific Ways to Improve Your Programs and Designs (3rd Edition)" - - "More Effective C++: 35 New Ways to Improve Your Programs and Designs" - - "Effective Modern C++: 42 Specific Ways to Improve Your Use of C++11 and C++14" diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index e071a2290d..746e04f643 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,5 +1,43 @@ # Contribution Guidelines -Please see our contribution guidelines in [the Solidity documentation](https://docs.soliditylang.org/en/latest/contributing.html). +Hello! Thanks for your interest in joining the mission to accelerate the mass adoption of crypto for personal +sovereignty! We welcome contributions from anyone on the internet, and are grateful for even the smallest of fixes! -Thank you for your help! +## Ways to contribute + +There are many ways to contribute to the ZK Stack: + +1. Open issues: if you find a bug, have something you believe needs to be fixed, or have an idea for a feature, please + open an issue. +2. Add color to existing issues: provide screenshots, code snippets, and whatever you think would be helpful to resolve + issues. +3. Resolve issues: either by showing an issue isn't a problem and the current state is ok as is or by fixing the problem + and opening a PR. +4. Report security issues, see [our security policy](./SECURITY.md). +5. [Join the team!](https://matterlabs.notion.site/Shape-the-future-of-Ethereum-at-Matter-Labs-dfb3b5a037044bb3a8006af2eb0575e0) + +## Fixing issues + +To contribute code fixing issues, please fork the repo, fix an issue, commit, add documentation as per the PR template, +and the repo's maintainers will review the PR. +[here](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request-from-a-fork) +for guidance how to work with PRs created from a fork. + +## Licenses + +If you contribute to this project, your contributions will be made to the project under both Apache 2.0 and the MIT +license. + +## Resources + +We aim to make it as easy as possible to contribute to the mission. This is still WIP, and we're happy for contributions +and suggestions here too. Some resources to help: + +1. [ZKsync Era docs!](https://docs.zksync.io/) +2. Company links can be found in the [repo's readme](README.md) + +## Code of Conduct + +Be polite and respectful. + +### Thank you diff --git a/Changelog.md b/Changelog.md index eabd5b9eee..e5b8358f12 100644 --- a/Changelog.md +++ b/Changelog.md @@ -1,3 +1,22 @@ +### 1.0.1 - ZKsync Legacy Edition (2024-05-31) + +Bugfixes: +* Fixed nested try-catch lowering in EVM assembly codegen (^0.6.0) + + +### 1.0.0 - ZKsync Legacy Edition (2024-01-16) + +This release has changes in the lowering of EVM assembly in order to get the ZKsync's translator targeting LLVM IR to work correctly. + +Added: +* A new metadata output field called "extraMetadata" in standard-json that stores information of recursive functions + +Changed: +* Internal function pointers are lowered to static jump tables +* Disabled evmasm optimizations to avoid any potential invalidation of the new metadata for recursive functions +* Minor changes in the control-flow when lowering a try-catch block (^0.6.0) + + ### 0.8.28 (2024-10-09) Language Features: diff --git a/README.md b/README.md index 197259998f..a1123f4053 100644 --- a/README.md +++ b/README.md @@ -1,92 +1,32 @@ -# The Solidity Contract-Oriented Programming Language +# ZKsync Era: Solidity Compiler -[![Matrix Chat](https://img.shields.io/badge/Matrix%20-chat-brightgreen?style=plastic&logo=matrix)](https://matrix.to/#/#ethereum_solidity:gitter.im) -[![Gitter Chat](https://img.shields.io/badge/Gitter%20-chat-brightgreen?style=plastic&logo=gitter)](https://gitter.im/ethereum/solidity) -[![SolidityΒ Forum](https://img.shields.io/badge/Solidity_Forum%20-discuss-brightgreen?style=plastic&logo=discourse)](https://forum.soliditylang.org/) -[![X Follow](https://img.shields.io/twitter/follow/solidity_lang?style=plastic&logo=x)](https://X.com/solidity_lang) -[![Mastodon Follow](https://img.shields.io/mastodon/follow/000335908?domain=https%3A%2F%2Ffosstodon.org%2F&logo=mastodon&style=plastic)](https://fosstodon.org/@solidity) +[![Logo](eraLogo.svg)](https://zksync.io/) -You can talk to us on Gitter and Matrix, tweet at us on X (previously Twitter) or create a new topic in the Solidity forum. Questions, feedback, and suggestions are welcome! +ZKsync Era is a layer 2 rollup that uses zero-knowledge proofs to scale Ethereum without compromising on security +or decentralization. As it's EVM-compatible (with Solidity/Vyper), 99% of Ethereum projects can redeploy without +needing to refactor or re-audit any code. ZKsync Era also uses an LLVM-based compiler that will eventually enable +developers to write smart contracts in popular languages such as C++ and Rust. -Solidity is a statically typed, contract-oriented, high-level language for implementing smart contracts on the Ethereum platform. - -For a good overview and starting point, please check out the official [Solidity Language Portal](https://soliditylang.org). - -## Table of Contents - -- [Background](#background) -- [Build and Install](#build-and-install) -- [Example](#example) -- [Documentation](#documentation) -- [Development](#development) -- [Maintainers](#maintainers) -- [License](#license) -- [Security](#security) - -## Background - -Solidity is a statically-typed curly-braces programming language designed for developing smart contracts -that run on the Ethereum Virtual Machine. Smart contracts are programs that are executed inside a peer-to-peer -network where nobody has special authority over the execution, and thus they allow anyone to implement tokens of value, -ownership, voting, and other kinds of logic. - -When deploying contracts, you should use the latest released version of -Solidity. This is because breaking changes, as well as new features and bug fixes, are -introduced regularly. We currently use a 0.x version -number [to indicate this fast pace of change](https://semver.org/#spec-item-4). - -## Build and Install - -Instructions about how to build and install the Solidity compiler can be -found in the [Solidity documentation](https://docs.soliditylang.org/en/latest/installing-solidity.html#building-from-source). - - -## Example - -A "Hello World" program in Solidity is of even less use than in other languages, but still: - -```solidity -// SPDX-License-Identifier: MIT -pragma solidity >=0.6.0 <0.9.0; - -contract HelloWorld { - function helloWorld() external pure returns (string memory) { - return "Hello, World!"; - } -} -``` - -To get started with Solidity, you can use [Remix](https://remix.ethereum.org/), which is a -browser-based IDE. Here are some example contracts: - -1. [Voting](https://docs.soliditylang.org/en/latest/solidity-by-example.html#voting) -2. [Blind Auction](https://docs.soliditylang.org/en/latest/solidity-by-example.html#blind-auction) -3. [Safe remote purchase](https://docs.soliditylang.org/en/latest/solidity-by-example.html#safe-remote-purchase) -4. [Micropayment Channel](https://docs.soliditylang.org/en/latest/solidity-by-example.html#micropayment-channel) - -## Documentation - -The Solidity documentation is hosted using [Read the Docs](https://docs.soliditylang.org). - -## Development - -Solidity is still under development. Contributions are always welcome! -Please follow the -[Developer's Guide](https://docs.soliditylang.org/en/latest/contributing.html) -if you want to help. - -You can find our current feature and bug priorities for forthcoming -releases in the [projects section](https://github.com/ethereum/solidity/projects). - -## Maintainers -The Solidity programming language and compiler are open-source community projects governed by a core team. -The core team is sponsored by the [Ethereum Foundation](https://ethereum.foundation/). +This repository contains the Solidity compiler and language tuned for EraVM. ## License + Solidity is licensed under [GNU General Public License v3.0](LICENSE.txt). Some third-party code has its [own licensing terms](cmake/templates/license.h.in). -## Security +## Official Links + +- [Website](https://zksync.io/) +- [GitHub](https://github.com/matter-labs) +- [Twitter](https://twitter.com/zksync) +- [Twitter for Devs](https://twitter.com/ZKsyncDevs) +- [Discord](https://join.zksync.dev/) + +## Disclaimer -The security policy may be [found here](SECURITY.md). +ZKsync Era has been through extensive testing and audits, and although it is live, it is still in alpha state and +will undergo further audits and bug bounty programs. We would love to hear our community's thoughts and suggestions +about it! +It's important to note that forking it now could potentially lead to missing important +security updates, critical features, and performance improvements. diff --git a/ReleaseChecklist.md b/ReleaseChecklist.md deleted file mode 100644 index 8ca2e7f96e..0000000000 --- a/ReleaseChecklist.md +++ /dev/null @@ -1,123 +0,0 @@ -## Checklist for making a release: - -### Requirements - - [ ] GitHub account with access to [solidity](https://github.com/ethereum/solidity), [solc-js](https://github.com/ethereum/solc-js), - [solc-bin](https://github.com/ethereum/solc-bin), [solidity-website](https://github.com/ethereum/solidity-website). - - [ ] DockerHub account with push rights to the [``solc`` image](https://hub.docker.com/r/ethereum/solc). - - [ ] Launchpad (Ubuntu One) account with a membership in the ["Ethereum" team](https://launchpad.net/~ethereum) and - a gnupg key for your email in the ``ethereum.org`` domain (has to be version 1, gpg2 won't work). - - [ ] Ubuntu/Debian dependencies of the PPA scripts: ``devscripts``, ``debhelper``, ``dput``, ``git``, ``wget``, ``ca-certificates``. - - [ ] [npm Registry](https://www.npmjs.com) account added as a collaborator for the [``solc`` package](https://www.npmjs.com/package/solc). - - [ ] Access to the [solidity_lang Twitter account](https://twitter.com/solidity_lang). - - [ ] [Reddit](https://www.reddit.com) account that is at least 10 days old with a minimum of 20 comment karma (``/r/ethereum`` requirements). - -### Pre-flight checks -At least a day before the release: - - [ ] Run ``make linkcheck`` from within ``docs/`` and fix any broken links it finds. - Ignore false positives caused by ``href`` anchors and dummy links not meant to work. - **Note**: In order to run the link check, make sure you've built the docs first via ``docs.sh``. - - [ ] Double-check that [the most recent docs builds at readthedocs](https://readthedocs.org/projects/solidity/builds/) succeeded. - - [ ] Make sure that all merged PRs that should have changelog entries do have them. - - [ ] Rerun CI on the top commits of main branches in all repositories that do not have daily activity by creating a test branch or PR: - - [ ] ``solc-js`` - - [ ] ``solc-bin`` (make sure the bytecode comparison check did run) - - [ ] (Optional) Create a prerelease in our Ubuntu PPA by following the steps in the PPA section below on ``develop`` rather than on a tag. - This is recommended especially when dealing with PPA for the first time, when we add a new Ubuntu version or when the PPA scripts were modified in this release cycle. - - [ ] Verify that the release tarball of ``solc-js`` works. - Bump version locally, add ``soljson.js`` from CI, build it, compare the file structure with the previous version, install it locally and try to use it. - - [ ] Review [Learning from Past Releases](https://notes.ethereum.org/@solidity/release-mistakes) to make sure you don't repeat the same mistakes. - -### Drafts -At least a day before the release: - - [ ] Create a draft PR to sort the changelog. - - [ ] Create draft PRs to bump version in ``solidity`` and ``solc-js``. - **Note**: The ``solc-js`` PR won't pass CI checks yet because it depends on the soljson binary from ``solc-bin``. - - [ ] Create a draft of the release on github. - - [ ] Create a draft PR to update soliditylang.org. - - [ ] Create drafts of blog posts. - - [ ] Prepare drafts of Twitter, Reddit and Solidity Forum announcements. - -### Blog Post - - [ ] Create a post on [solidity-website](https://github.com/ethereum/solidity-website/tree/main/src/posts) in the ``Releases`` category and explain some of the new features or concepts. - - [ ] Create a post on [solidity-website](https://github.com/ethereum/solidity-website/tree/main/src/posts) in the ``Security Alerts`` category in case of important bug(s). - - [ ] Get the posts reviewed and approved **before the release starts**. - -### Changelog - - [ ] Sort the changelog entries alphabetically and correct any errors you notice. Commit it. - - [ ] Update the changelog to include a release date. - - [ ] Run ``scripts/update_bugs_by_version.py`` to regenerate ``bugs_by_version.json`` from the changelog and ``bugs.json``. - Make sure that the resulting ``bugs_by_version.json`` has a new, empty entry for the new version. - - [ ] Commit changes, create a pull request and wait for the tests. Then merge it. - - [ ] Copy the changelog into the release blog post. - -### Create the Release - - [ ] Create a [release on GitHub](https://github.com/ethereum/solidity/releases/new). - Set the target to the ``develop`` branch and the tag to the new version, e.g. ``v0.8.5``. - Include the following warning: ``**The release is still in progress. You may see broken links and binaries may not yet be available from all sources.**``. - Do not publish it yet - click the ``Save draft`` button instead. - - [ ] Thank voluntary contributors in the GitHub release notes. - Use ``scripts/list_contributors.sh v`` to get initial list of names. - Remove different variants of the same name manually before using the output. - - [ ] Check that all tests on the latest commit in ``develop`` are green. - - [ ] Click the ``Publish release`` button on the release page, creating the tag. - **Important: Must not be done before all the PRs, including changelog cleanup and date, are merged.** - - [ ] Wait for the CI runs on the tag itself. - -### Upload Release Artifacts and Publish Binaries - - [ ] Switch to the tag that archives have to be created for. - - [ ] Create the ``prerelease.txt`` file: (``echo -n > prerelease.txt``). - - [ ] Run ``scripts/create_source_tarball.sh`` while being on the tag to create the source tarball. This will create the tarball in a directory called ``upload``. - - [ ] Take the tarball from the upload directory (its name should be ``solidity_x.x.x.tar.gz``, otherwise ``prerelease.txt`` was missing in the step before) and upload the source tarball to the release page. - - [ ] Take the ``github-binaries.tar`` tarball from ``c_release_binaries`` run of the tagged commit in circle-ci and add all binaries from it to the release page. - Make sure it contains four binaries: ``solc-windows.exe``, ``solc-macos``, ``solc-static-linux`` and ``soljson.js``. - - [ ] Take the ``solc-bin-binaries.tar`` tarball from ``c_release_binaries`` run of the tagged commit in circle-ci and add all binaries from it to solc-bin. - - [ ] Run ``npm install`` if you've got a clean checkout of the solc-bin repo. - - [ ] Run ``npm run update -- --reuse-hashes`` in ``solc-bin`` and verify that the script has updated ``list.js``, ``list.txt`` and ``list.json`` files correctly and that symlinks to the new release have been added in ``solc-bin/wasm/`` and ``solc-bin/emscripten-wasm32/``. - - [ ] Create a pull request in solc-bin and merge. - -### Homebrew and MacOS - - [ ] Update the version and the hash (``sha256sum solidity_$VERSION.tar.gz``) in the [``solidity`` formula in Homebrew core repository](https://github.com/Homebrew/homebrew-core/blob/master/Formula/solidity.rb). - -### Docker - - [ ] Run ``./scripts/docker_deploy_manual.sh v$VERSION``. - -### PPA - - [ ] Create ``.release_ppa_auth`` at the root of your local Solidity checkout and set ``LAUNCHPAD_EMAIL`` and ``LAUNCHPAD_KEYID`` to your key's email and key id. - - [ ] Double-check that the ``DISTRIBUTIONS`` list in ``scripts/release_ppa.sh`` and ``scripts/deps-ppa/static_z3.sh`` contains the most recent versions of Ubuntu. - - [ ] Make sure the [``~ethereum/cpp-build-deps`` PPA repository](https://launchpad.net/~ethereum/+archive/ubuntu/cpp-build-deps) contains ``libz3-static-dev`` builds for all current versions of Ubuntu. - Note that it may be included in the ``z3-static`` multipackage (follow the ``View package details`` link to check). - If not present, run ``scripts/deps-ppa/static_z3.sh`` and wait for the builds to succeed before continuing. - - [ ] Run ``scripts/release_ppa.sh v$VERSION`` to create the PPA release. - This will create a single package containing static binary for older Ubuntu versions in the [``~ethereum/ethereum-static`` PPA](https://launchpad.net/~ethereum/+archive/ubuntu/ethereum-static) - and separate packages with dynamically-linked binaries for recent versions (those listed in ``DISTRIBUTIONS``) in the [``~ethereum/ethereum`` PPA](https://launchpad.net/~ethereum/+archive/ubuntu/ethereum). - - [ ] Wait for the build to be finished and published for *all architectures* (currently we only build for ``amd64``, but we may add ``arm`` in the future). - **SERIOUSLY: DO NOT PROCEED EARLIER!!!** - - [ ] *After* the package with the static build is *published*, use it to create packages for older Ubuntu versions. - Copy the static package to the [``~ethereum/ethereum`` PPA](https://launchpad.net/~ethereum/+archive/ubuntu/ethereum) - for the destination series ``Trusty``, ``Xenial`` and ``Bionic`` while selecting ``Copy existing binaries``. - -### Release solc-js - - [ ] Wait until solc-bin was properly deployed. You can test this via remix - a test run through remix is advisable anyway. - - [ ] Increment the version number, create a pull request for that, merge it after tests succeeded. - - [ ] Create a tag using ``git tag --annotate v$VERSION`` and push it with ``git push --tags``. - - [ ] Wait for the CI runs on the tag itself. - - [ ] Take the ``solc-x.y.z.tgz`` artifact from ``build-package`` run on the tagged commit in circle-ci. - Inspect the tarball to ensure that it contains an up-to-date compiler binary (``soljson.js``). - - [ ] Run ``npm publish solc-x.y.z.tgz`` to publish the newly created tarball. - -### Post-release - - [ ] Make sure the documentation for the new release has been published successfully. - Go to the [documentation status page at ReadTheDocs](https://readthedocs.org/projects/solidity/) and verify that the new version is listed, works and is marked as default. - - [ ] Remove "still in progress" warning from the [release notes](https://github.com/ethereum/solidity/releases). - - [ ] Merge the [blog posts](https://github.com/ethereum/solidity-website/pulls) related to the release. - - [ ] Create a commit to increase the version number on ``develop`` in ``CMakeLists.txt`` and add a new skeleton changelog entry. - - [ ] Update the release information section [in the source of soliditylang.org](https://github.com/ethereum/solidity-website/blob/main/src/pages/index.tsx). - - [ ] Announce on [Twitter](https://twitter.com/solidity_lang), including links to the release and the blog post. - - [ ] Announce on [Fosstodon](https://fosstodon.org/@solidity/), including links to the release and the blog post. - - [ ] Share the announcement on Reddit in [``/r/ethdev``](https://reddit.com/r/ethdev/), cross-posted to [``/r/ethereum``](https://reddit.com/r/ethereum/). - - [ ] Share the announcement on the [Solidity forum](https://forum.soliditylang.org) in the ``Announcements`` category. - - [ ] Share the announcement on [Project Updates](https://discord.com/channels/420394352083337236/798974456704925696) - - [ ] Share the announcement on [`#solidity` channel on Matrix](https://matrix.to/#/#ethereum_solidity:gitter.im) - - [ ] Share the announcement on [`#solc-tooling`](https://matrix.to/#/#solc-tooling:matrix.org) - - [ ] If anything went wrong this time, mention it in [Learning from Past Releases](https://notes.ethereum.org/@solidity/release-mistakes). - - [ ] Lean back, wait for bug reports and repeat from step 1 :). diff --git a/ReviewChecklist.md b/ReviewChecklist.md deleted file mode 100644 index 3f0af6f981..0000000000 --- a/ReviewChecklist.md +++ /dev/null @@ -1,200 +0,0 @@ -# PR Review Checklist -The Solidity compiler is a critical piece of infrastructure in the Ethereum ecosystem. -For this reason, our review process is quite strict and all PRs have to fulfill certain quality -expectations and guidelines. -The list below is meant to reduce the workload on the core team by helping contributors self-identify -and solve common issues before they are pointed out in the review. -It is also meant to serve as a final checklist for reviewers to go through before approving a PR. - -## Before You Submit a PR -- [ ] **Do you have any other open PRs?** - Work on a PR is not done until it is merged or closed. - Our reviewing capacity is limited, so we require that external contributors work on **no more than one PR at a time**. - - If your PR is not getting reviewed, feel free to bring it to our attention on the [#solidity-dev](https://gitter.im/ethereum/solidity-dev) channel. - - Unless they were requested, we are going to close any excess PRs, leaving only the earliest one open. - You may reopen them, one at a time, when your current PR is done. -- [ ] **Is the issue ready to be worked on?** - - If the issue does not have a desirability label (`nice to have`, `should have`, - `must have eventually`, `must have`, `roadmap`) we have not yet decided whether to implement it. - - If the issue has the `needs design` label, we have not yet decided how it should be implemented. - - `good first issue candidate` means that the issue will potentially be a `good first issue` - eventually but at the moment it is not yet ready to be worked on. -- [ ] **Is this a breaking change?** Breaking changes should be based on the `breaking` branch rather than on the `develop` branch. -- [ ] **Does the PR actually address the issue?** - - [ ] Mention the issue number in the PR description. - If the PR solves it completely, use the `Fixes #` form so that Github will close the issue automatically. - - [ ] Do not include the issue number in the PR title, branch name or commit description. -- [ ] When submitting a PR from a fork **create a branch and give it a descriptive name.** - E.g. `fix-array-abi-encoding-bug`. - Do not submit PRs directly from the `develop` branch of your fork since it makes rebasing and fetching new changes harder. -- [ ] **Does the PR depend on other PRs?** - - [ ] If the PR has dependencies, mention them in bold in the description. - - [ ] Avoid basing PRs from forks on branches other than `develop` or `breaking` because - GitHub closes them when the base branch gets merged. - Do this only for PRs created directly in the main repo. -- [ ] **Does the PR update test expectations to match the modified code?** If not, your PR will not pass some of the `_soltest_`, jobs in CI. - In many cases the expectations can be updated automatically: - - `cmdlineTests.sh --update` for command-line tests. - - `isoltest --enforce-gas-cost --accept-updates` for soltest-based tests. - - If your PR affects gas costs, an extra run of `isoltest --enforce-gas-cost --optimize --accept-updates` is needed to update gas expectations with optimizer enabled. - - Review updated files before committing them. - **Are expectations correct and do updated tests still serve their purpose?** - -## Abandoned PRs -- [ ] **Is the submitter still responsive?** - - If the PR had no activity from the submitter in the last 2 weeks (despite receiving reviews and our prompts) we consider it abandoned. -- [ ] **Is the abandoned PR easy to finish or relevant?** - - Apply the `takeover` label if the PR can be finished without significant effort or is something that actually needs to be done right now. - Otherwise close it. - It can still be taken over later or reopened by the submitter but until then we should not be getting sidetracked by it. - -## Light Review -Before an in-depth review, it is recommended to give new PRs a quick, superficial review, which -is not meant to provide complete and detailed feedback, but instead give the submitter a rough idea -if the PR is even on the right track and let them solve the obvious problems on their own. - -Light review should focus on the following three areas: -- [ ] **Are there any obvious mistakes?** Style issues, bad practices, easy to identify bugs, etc. -- [ ] **Is there anything missing?** Tests (of the right kind), documentation, etc. Does it address the whole issue? -- [ ] **Is it the right solution?** Are there better ways to do this? Is the change even necessary? - -If the answers above are "Yes, Yes, No", thank the contributor for their effort and **close the PR**. - -## Coding Style and Good Practices -- [ ] Does the PR follow our [coding style](CODING_STYLE.md)? - -### Reliability -- [ ] **Use assertions liberally.** If you are certain your assumption will not be broken, prove it with `solAssert()`. -- [ ] **Validate inputs and handle errors**. Note that assertions are **not** validation. - -### Readability -- [ ] **Choose good names.** - - [ ] Is the name straightforward to understand? - Do you feel the need to jump back to the definition and remind yourself what it was whenever you see it? - - [ ] Is the name unambiguous in the context where it is used? - - [ ] Avoid abbreviations. -- [ ] **Source files, classes and public functions should have docstrings.** -- [ ] **Avoid code duplication.** But not fanatically. Minimal amounts of duplication are acceptable if it aids readability. -- [ ] **Do not leave dead or commented-out code behind.** You can still see old code in history. - If you really have a good reason to do it, always leave a comment explaining what it is and why it is there. -- [ ] **Mark hacks as such.** If you have to leave behind a temporary workaround, make - sure to include a comment that explains why and in what circumstances it can be removed. - Preferably link to an issue you reported upstream. -- [ ] **Avoid obvious comments.** -- [ ] **Do include comments when the reader may need extra context to understand the code.** - -### Commits and PRs -- [ ] **Avoid hiding functional changes inside refactors.** - E.g. when fixing a small bug, or changing user-visible behavior, put the change in a separate commit. - Do not mix it with another change that renames things or reformats the code around, making the fix itself hard to identify. -- [ ] **Whenever possible, split off refactors or unrelated changes into separate PRs.** - Smaller PRs are easier and quicker to review. - Splitting off refactors helps focus on the main point of the PR. - -### Common Pitfalls -The following points are all covered by the coding style but come up so often that it is worth singling them out here: -- [ ] **Always initialize value types in the definition,** even if you are sure you will assign them later. -- [ ] **Use "east const" style.** I.e. `T const*`, not `const T *`. -- [ ] **Keep indentation consistent.** See our [`.editorconfig`](.editorconfig). - - [ ] Tabs for C++. But use them for indentation only. Any whitespace later on the line must consist of spaces. - - [ ] 4 spaces for most other file types. -- [ ] **Use `auto` sparingly.** Only use it when the actual type is very long and complicated or when it is - already used elsewhere in the same expression. -- [ ] **Indent braces and parentheses in a way that makes nesting clear.** -- [ ] **Use `using namespace` only in `.cpp` files.** Use it for `std` and our own modules. - Avoid unnecessary `std::` prefix in `.cpp` files (except for `std::move` and `std::forward`). -- [ ] **Use range-based loops and destructuring.** -- [ ] **Include any headers you use directly,** even if they are implicitly included through other headers. - -## Documentation -- [ ] **Does the PR update relevant documentation?** - -### Documentation Style and Good Practices -- [ ] **Use double backticks in RST (``` ``x`` ```). Prefer single backticks in Markdown (`` `x` ``),** - but note that double backticks are valid too and we use them in some cases for legacy reasons. -- [ ] **Always start a new sentence on a new line.** - This way you do not have to rewrap the surrounding text when you rewrite the sentence. - This also makes changes actually easier to spot in the diff. - -## Testing - -### What to Test -- [ ] **Is newly added code adequately covered by tests?** Have you considered all the important corner cases? -- If it is a bugfix: - - [ ] **The PR must include tests that reproduce the bug.** - - [ ] **Are there gaps in test coverage of the buggy feature?** Fill them by adding more tests. - - [ ] **Try to break it.** Can you of any similar features that could also be buggy? - Play with the repro and include prominent variants as separate test cases, even if they don't trigger a bug. -- [ ] **Positive cases (code that compiles) should have a semantic test.** -- [ ] **Negative cases (code with compilation errors) should have a syntax test.** -- [ ] **Avoid mixing positive and negative cases in the same syntax test.** - If the test produces an error, we stop at the analysis stage and we will not detect - problems that only occur in code generation, optimizer or assembler. - - [ ] If you have to do it, at least mark positive cases inside the file with a short comment. - - This way, when the test is updated, it is easier to verify that these cases still do not trigger an error. -- [ ] New syntax: **does it have an [`ASTJSON`](test/libsolidity/ASTJSON/) test?** -- [ ] New CLI or StandardJSON option: - - [ ] **Does it have a [command-line test](test/cmdlineTests/)?** - - [ ] **Is the option listed for every input mode in [`CommandLineParser` tests](test/solc/CommandLineParser.cpp)?** -- [ ] **Did you consider interactions with other language features?** - - [ ] Are all types covered? Structs? Enums? Contracts/libraries/interfaces? User-defined value types? - Value types: integers, fixed bytes, `address`, `address payable`, `bool`? Function pointers? - Static and dynamic arrays? `string` and `bytes`? Mappings? - Values of types that cannot be named: literals, tuples, array slices, storage references? - - [ ] If it accepts a function, does it also accept an event or an error? These have function types but are not functions. - - [ ] If it affects free functions, what about internal library functions? - - [ ] Attached library functions? Functions attached with `using for`? - - [ ] Possible combinations of `storage`, `memory`, `calldata`, `immutable`, `constant`? - Remember that internal functions can take `storage` arguments. - - [ ] Does it work at construction time as well? What if you store it at construction time and read after deployment? - - [ ] What about importing it from a different module or inheriting it? - - [ ] Have you tested it with the ternary operator? - -### Test Style and Good Practices -- [ ] **Make test case file names long and specific enough** so that it is easy to guess what is inside. - When checking if we have the case already covered the name is usually the only clue we see. - - [ ] Place them in the right subdirectory. - - [ ] **Avoid simply appending numbers to the name to distinguish similar cases.** - Coming up with good names is hard but figuring out if any of hundreds of tests with names that - match your search actually fits your case is even harder. -- [ ] **Do not include version pragma and the SPDX comment in semantic and syntax test cases**. - In other test types include them if necessary to suppress warnings. -- [ ] **If you have to use a version pragma, avoid hard-coding version.** Use `pragma solidity *`. -- [ ] **When writing StandardJSON command-line tests, use `urls` instead of `content`** and put - the Solidity or Yul code in a separate file. - -## Compiler-specific -- [ ] **Are error messages sensible and understandable to users?** -- [ ] **Are error codes consistent?** - - [ ] Avoid randomly changing or reassigning error codes. - - [ ] Avoid defining separate codes for trivial variants of the same issue. - Make it easy for tools to consistently refer to the same error with the same code. -- [ ] **Error messages should end with a full stop.** -- [ ] **Prefer Ranges v3 to Boost where possible.** - -## Take a Step Back -- [ ] **Do you fully understand what the PR does and why?** -- [ ] **Are you confident that the code works and does not break unrelated functionality?** -- [ ] **Is this a reasonable way to achieve the goal stated in the issue?** -- [ ] **Is the code simple?** Does the PR achieve its objective at the cost of significant - complexity that may be a source of future bugs? -- [ ] **Is the code efficient?** Does the PR introduce any major performance bottlenecks? -- [ ] **Does the PR introduce any breaking changes beyond what was agreed in the issue?** - -## Final Checks Before Merging -- [ ] **Is the PR rebased on top of the `develop` branch** (or `breaking` if it is a breaking change)? -- [ ] **Did all CI checks pass?** - - Note that we have a few jobs that tend to randomly fail due to outside factors, especially external tests (with `_ext_` in the name). - If these fail, rebase on latest `develop` (or `breaking`) and try rerunning them. - Note also that not all of these checks are required for the PR to be merged. -- [ ] If the change is visible to users, **does the PR have a [changelog](Changelog.md) entry?** - - [ ] Is the changelog entry in the right section? - Make sure to move it up if there was a release recently. -- [ ] **Is commit history simple and understandable?** - - [ ] Each commit should be a self-contained, logical step leading the goal of the PR, without going back and forth. - In particular, review fixups should be squashed into the commits they fix. - - [ ] Do not include any merge commits in your branch. Please use rebase to keep up to date with the base branch. -- [ ] **Is the PR properly labeled?** - - Use `external contribution` label to mark PRs not coming from the core team. - - If the PR depends on other PRs, use `has dependencies` and set the base branch accordingly. - - Labels like `documentation` or `optimizer` are helpful for filtering PRs. diff --git a/SECURITY.md b/SECURITY.md index d319b332f2..d77060818a 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -1,52 +1,74 @@ # Security Policy -The Solidity team and community take all security bugs in Solidity seriously. -We appreciate your efforts and responsible disclosure and will make every effort to acknowledge your contributions. - -## Scope - -Bugs in the Solidity repository are in scope. -Bugs in third-party dependencies e.g., jsoncpp, boost etc. are not in scope unless they result in a Solidity specific bug. - -Only bugs that have a demonstrable security impact on smart contracts are in scope. -For example, a Solidity program whose optimization is incorrect (e.g., leads to an incorrect output) qualifies as a security bug. -Please note that the [rules][2] of the [Ethereum bounty program][1] have precedence over this security policy. - -## Supported Versions - -As a general rule, only the latest release gets security updates. -Exceptions may be made when the current breaking release is relatively new, e.g. less than three months old. -If you are reporting a bug, please state clearly the Solidity version(s) it affects. - -Example 1: Assuming the current release is `0.6.3` and a security bug has been found in it that affects both `0.5.x` and `0.6.x` trees, we may not only patch `0.6.3` (the bug-fix release numbered `0.6.4`) but `0.5.x` as well (the bug-fix release numbered `0.5.(x+1)`). - -Example 2: Assuming the current release is `0.6.25` and a security bug has been found in it, we may only patch `0.6.25` (in the bug-fix release numbered `0.6.26`) even if the bug affects a previous tree such as `0.5.x`. - -## Reporting a Vulnerability - -To report a vulnerability, please follow the instructions stated in the [Ethereum bounty program][1]. - -In the bug report, please include all details necessary to reproduce the vulnerability such as: - -- Input program that triggers the bug -- Compiler version affected -- Target EVM version -- Framework/IDE if applicable -- EVM execution environment/client if applicable -- Operating system - -Please include steps to reproduce the bug you have found in as much detail as possible. - -Once we have received your bug report, we will try to reproduce it and provide a more detailed response. -Once the reported bug has been successfully reproduced, the Solidity team will work on a fix. - -The Solidity team maintains the following JSON-formatted lists of patched security vulnerabilities: - -- [Summary of known security vulnerabilities][3] -- [List of security vulnerabilities affecting a specific version of the compiler][4]. - - -[1]: https://bounty.ethereum.org/ -[2]: https://bounty.ethereum.org/#rules -[3]: https://docs.soliditylang.org/en/develop/bugs.html -[4]: https://github.com/ethereum/solidity/blob/develop/docs/bugs_by_version.json +We truly appreciate efforts to discover and disclose security issues responsibly! + +## Vulnerabilities + +If you'd like to report a security issue in the repositories of matter-labs organization, please proceed to our +[Bug Bounty Program on Immunefi](https://docs.zksync.io/build/resources/audit-bug-bounty#bug-bounty-program). + +## Other Security Issues + +We take an impact-first approach instead of a rules-first approach. Therefore, if you believe you found the impactful +issue but can't report it via the Bug Bounty, please email us at +[security@matterlabs.dev](mailto:security@matterlabs.dev). + +### PGP Key + +The following PGP key may be used to communicate sensitive information to developers: + +Fingerprint: `5FED B2D0 EA2C 4906 DD66 71D7 A2C5 0B40 CE3C F297` + +``` +-----BEGIN PGP PUBLIC KEY BLOCK----- + +mQINBGEBmQkBEAD6tlkBEZFMvR8kOgxXX857nC2+oTik6TopJz4uCskuqDaeldMy +l+26BBzLkIeO1loS+bzVgnNFJRrGt9gv98MzNEHJVv6D7GsSLlUX/pz7Lxn0J4ry +o5XIk3MQTCUBdaXGs6GBLl5Xe8o+zNj4MKd4zjgDLinITNlE/YZCDsXyvYS3YFTQ +cwaUTNlawkKgw4BLaEqwB2JuyEhI9wx5X7ibjFL32sWMolYsNAlzFQzM09HCurTn +q0DYau9kPJARcEk9/DK2iq0z3gMCQ8iRTDaOWd8IbSP3HxcEoM5j5ZVAlULmjmUE +StDaMPLj0Kh01Tesh/j+vjchPXHT0n4zqi1+KOesAOk7SIwLadHfQMTpkU7G2fR1 +BrA5MtlzY+4Rm6o7qu3dpZ+Nc4iM3FUnaQRpvn4g5nTh8vjG94OCzX8DXWrCKyxx +amCs9PLDYOpx84fXYv4frkWpKh2digDSUGKhoHaOSnqyyvu3BNWXBCQZJ20rqEIu +sXOQMxWIoWCOOPRRvrHrKDA2hpoKjs3pGsProfpVRzb9702jhWpTfbDp9WjQlFtX +2ZIDxlwAxcugClgrp5JiUxvhg2A9lDNwCF7r1e68uNv5usBZQVKPJmnvS2nWgKy8 +x9oJsnwrEjxwiRHd34UvfMkwY9RENSJ+NoXqBdS7Lwz4m6vgbzq6K56WPQARAQAB +tCRaa1N5bmMgU2VjdXJpdHkgPHNlY3VyaXR5QHprc3luYy5pbz6JAk4EEwEKADgW +IQRf7bLQ6ixJBt1mcdeixQtAzjzylwUCYQGZCQIbAwULCQgHAgYVCgkICwIEFgID +AQIeAQIXgAAKCRCixQtAzjzyl5y8EAC/T3oq88Dak2b+5TlWdU2Gpm6924eAqlMt +y1KksDezzNQUlPiCUVllpin2PIjU/S+yzMWKXJA04LoVkEPfPOWjAaavLOjRumxu +MR6P2dVUg1InqzYVsJuRhKSpeexzNA5qO2BPM7/I2Iea1IoJPjogGbfXCo0r5kne +KU7a5GEa9eDHxpHTsbphQe2vpQ1239mUJrFpzAvILn6jV1tawMn5pNCXbsa8l6l2 +gtlyQPdOQECy77ZJxrgzaUBcs/RPzUGhwA/qNuvpF0whaCvZuUFMVuCTEu5LZka2 +I9Rixy+3jqBeONBgb+Fiz5phbiMX33M9JQwGONFaxdvpFTerLwPK2N1T8zcufa01 +ypzkWGheScFZemBxUwXwK4x579wjsnfrY11w0p1jtDgPTnLlXUA2mom4+7MyXPg0 +F75qh6vU1pdXaCVkruFgPVtIw+ccw2AxD50iZQ943ZERom9k165dR9+QxOVMXQ4P +VUxsFZWvK70/s8TLjsGljvSdSOa85iEUqSqh0AlCwIAxLMiDwh5s/ZgiHoIM6Xih +oCpuZyK9p0dn+DF/XkgAZ/S91PesMye3cGm6M5r0tS26aoc2Pk6X37Hha1pRALwo +MOHyaGjc/jjcXXxv6o55ALrOrzS0LQmLZ+EHuteCT15kmeY3kqYJ3og62KgiDvew +dKHENvg7d7kCDQRhAZleARAA6uD6WfdqGeKV5i170+kLsxR3QGav0qGNAbxpSJyn +iHQ8u7mQk3S+ziwN2AAopfBk1je+vCWtEGC3+DWRRfJSjLbtaBG8e6kLP3/cGA75 +qURz6glTG4nl5fcEAa6B1st0OxjVWiSLX3g/yjz8lznQb9awuRjdeHMnyx5DsJUN +d+Iu5KxGupQvKGOMKivSvC8VWk9taaQRpRF+++6stLCDk3ZtlxiopMs3X2jAp6xG +sOBbix1cv9BTsfaiL7XDL/gviqBPXYY5L42x6+jnPo5lROfnlLYkWrv6KZr7HD4k +tRXeaSwxLD2EkUyb16Jpp0be/ofvBtITGUDDLCGBiaXtx/v8d52MARjsyLJSYloj +1yiW01LfAiWHUC4z5jl2T7E7sicrlLH1M8Z6WbuqjdeaYwtfyPA2YCKr/3fn6pIo +D+pYaBSESmhA92P+XVaf5y2BZ6Qf8LveDpWwsVGdBGh9T0raA1ooe1GESLjmIjUa +z5AeQ/uXL5Md9I6bpMUUJYQiH19RPcFlJriI3phXyyf6Wlkk8oVEeCWyzcmw+x1V +deRTvE2x4WIwKGLXRNjin2j1AP7vU2HaNwlPrLijqdyi68+0irRQONoH7Qonr4ca +xWgL+pAaa3dWxf0xqK7uZFp4aTVWlr2uXtV/eaUtLmGMCU0jnjb109wg5L0F7WRT +PfEAEQEAAYkCNgQYAQoAIBYhBF/tstDqLEkG3WZx16LFC0DOPPKXBQJhAZleAhsM +AAoJEKLFC0DOPPKXAAEP/jK7ch9GkoaYlsuqY/aHtxEwVddUDOxjyn3FMDoln85L +/n8AmLQb2bcpKSqpaJwMbmfEyr5MDm8xnsBTfx3u6kgaLOWfKxjLQ6PM7kgIMdi4 +bfaRRuSEI1/R6c/hNpiGnzAeeexldH1we+eH1IVmh4crdat49S2xh7Qlv9ahvgsP +LfKl3rJ+aaX/Ok0AHzhvSfhFpPr1gAaGeaRt+rhlZsx2QyG4Ez8p2nDAcAzPiB3T +73ENoBIX6mTPfPm1UgrRyFKBqtUzAodz66j3r6ebBlWzIRg8iZenVMAxzjINAsxN +w1Bzfgsi5ZespfsSlmEaa7jJkqqDuEcLa2YuiFAue7Euqwz1aGeq1GfTicQioSCb +Ur/LGyz2Mj3ykbaP8p5mFVcUN51yQy6OcpvR/W1DfRT9SHFT/bCf9ixsjB2HlZGo +uxPJowwqmMgHd755ZzPDUM9YDgLI1yXdcYshObv3Wq537JAxnZJCGRK4Y8SwrMSh +8WRxlaM0AGWXiJFIDD4bQPIdnF3X8w0cGWE5Otkb8mMHOT+rFTVlDODwm1zF6oIG +PTwfVrpiZBwiUtfJol1exr/MzSPyGoJnYs3cRf2E3O+D1LbcR8w0LbjGuUy38Piz +ZO/vCeyJ3JZC5kE8nD+XBA4idwzh0BKEfH9t+WchQ3Up9rxyzLyQamoqt5Xby4pY +=xkM3 +-----END PGP PUBLIC KEY BLOCK----- +``` diff --git a/eraLogo.svg b/eraLogo.svg new file mode 100644 index 0000000000..6ec790c081 --- /dev/null +++ b/eraLogo.svg @@ -0,0 +1,13 @@ + + + + + + + + + + + + +