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 @@ + + + + + + + + + + + + +