From 9eced0ce0563b3bc7c15c679265ec76272d4f680 Mon Sep 17 00:00:00 2001 From: Oleksandr Zarudnyi Date: Sat, 13 Jan 2024 20:46:19 +0100 Subject: [PATCH] Remove Solidity documents and replace them with Era ones (#545) (cherry picked from commit dc469f8496870edaad75ebacaf31b698a12c56fb) --- .github/ISSUE_TEMPLATE/bug_report.md | 39 ++++ .github/ISSUE_TEMPLATE/feature_request.md | 21 ++ .github/pull_request_template.md | 19 ++ CODING_STYLE.md | 243 ---------------------- CONTRIBUTING.md | 42 +++- README.md | 37 ++-- ReleaseChecklist.md | 21 -- SECURITY.md | 74 +++++++ eraLogo.svg | 13 ++ 9 files changed, 231 insertions(+), 278 deletions(-) create mode 100644 .github/ISSUE_TEMPLATE/bug_report.md create mode 100644 .github/ISSUE_TEMPLATE/feature_request.md create mode 100644 .github/pull_request_template.md delete mode 100644 CODING_STYLE.md delete mode 100644 ReleaseChecklist.md create mode 100644 SECURITY.md create mode 100644 eraLogo.svg diff --git a/.github/ISSUE_TEMPLATE/bug_report.md b/.github/ISSUE_TEMPLATE/bug_report.md new file mode 100644 index 0000000000..2d3e38a63a --- /dev/null +++ b/.github/ISSUE_TEMPLATE/bug_report.md @@ -0,0 +1,39 @@ +--- +name: Bug report +about: Use this template for reporting issues +title: '' +labels: bug +assignees: '' +--- + +### 🐛 Bug Report + +#### 📝 Description + +Provide a clear and concise description of the bug. + +#### 🔄 Reproduction Steps + +Steps to reproduce the behaviour + +#### 🤔 Expected Behavior + +Describe what you expected to happen. + +#### 😯 Current Behavior + +Describe what actually happened. + +#### 🖥️ Environment + +Any relevant environment details. + +#### 📋 Additional Context + +Add any other context about the problem here. If applicable, add screenshots to help explain. + +#### 📎 Log Output + +``` +Paste any relevant log output here. +``` diff --git a/.github/ISSUE_TEMPLATE/feature_request.md b/.github/ISSUE_TEMPLATE/feature_request.md new file mode 100644 index 0000000000..d921e066cc --- /dev/null +++ b/.github/ISSUE_TEMPLATE/feature_request.md @@ -0,0 +1,21 @@ +--- +name: Feature request +about: Use this template for requesting features +title: '' +labels: feat +assignees: '' +--- + +### 🌟 Feature Request + +#### 📝 Description + +Provide a clear and concise description of the feature you'd like to see. + +#### 🤔 Rationale + +Explain why this feature is important and how it benefits the project. + +#### 📋 Additional Context + +Add any other context or information about the feature request here. 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/CODING_STYLE.md b/CODING_STYLE.md deleted file mode 100644 index 3244466b44..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; -``` - -## 1. Namespaces - -1. No `using namespace` declarations in header files. -2. All symbols should be declared in a namespace except for final applications. -3. Use anonymous namespaces for helpers whose scope is a cpp file only. -4. Preprocessor symbols should be prefixed with the namespace in all-caps and an underscore. - -Yes: -```cpp -#include -std::tuple meanAndSigma(std::vector const& _v); -``` - -No: -```cpp -#include -using namespace std; -tuple meanAndSigma(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 const variable 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; don't 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, ``boost::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; - float standardDeviation; -}; -double const d = 0; -int i; -int j; -char* s; -MeanAndSigma ms meanAndSigma(std::vector const& _v, Accuracy _a); -Derived* x = dynamic_cast(base); -for (auto i = x->begin(); i != x->end(); ++i) {} -``` - -No: -```cp -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 unpronouncable 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` -> `libdevcore` -> `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](http://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 2b591f4e19..152aec38d3 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,5 +1,43 @@ # Contribution Guidelines -Please see our contribution guidelines in [the Solidity documentation](http://solidity.readthedocs.io/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](./github/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://era.zksync.io/docs/) +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/README.md b/README.md index 8303131c84..bfb637ed21 100644 --- a/README.md +++ b/README.md @@ -1,19 +1,32 @@ -# The Solidity Contract-Oriented Programming Language -[![Join the chat at https://gitter.im/ethereum/solidity](https://badges.gitter.im/Join%20Chat.svg)](https://gitter.im/ethereum/solidity?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge) [![Build Status](https://travis-ci.org/ethereum/solidity.svg?branch=develop)](https://travis-ci.org/ethereum/solidity) +# zkSync Era: Solidity Compiler -## Useful links -To get started you can find an introduction to the language in the [Solidity documentation](https://solidity.readthedocs.org). In the documentation, you can find [code examples](https://solidity.readthedocs.io/en/latest/solidity-by-example.html) as well as [a reference](https://solidity.readthedocs.io/en/latest/solidity-in-depth.html) of the syntax and details on how to write smart contracts. +[![Logo](eraLogo.svg)](https://zksync.io/) -You can start using [Solidity in your browser](http://remix.ethereum.org) with no need to download or compile anything. +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. -The changelog for this project can be found [here](https://github.com/ethereum/solidity/blob/develop/Changelog.md). +This repository contains the Solidity compiler and language tuned for EraVM. -Solidity is still under development. So please do not hesitate and open an [issue in GitHub](https://github.com/ethereum/solidity/issues) if you encounter anything strange. +## License -## Building -See the [Solidity documentation](https://solidity.readthedocs.io/en/latest/installing-solidity.html#building-from-source) for build instructions. +Solidity is licensed under [GNU General Public License v3.0](LICENSE.txt). -## How to Contribute -Please see our [contribution guidelines](https://solidity.readthedocs.io/en/latest/contributing.html) in the Solidity documentation. +Some third-party code has its [own licensing terms](cmake/templates/license.h.in). -Any contributions are welcome! +## 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 + +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 ebdb75392c..0000000000 --- a/ReleaseChecklist.md +++ /dev/null @@ -1,21 +0,0 @@ -Checklist for making a release: - - - [ ] Ensure that a Github project exists for the release. - - [ ] Check that all issues and pull requests from the Github project to be released are merged to ``develop``. - - [ ] Create a commit in ``develop`` that updates the ``Changelog`` to include a release date (run ``./scripts/tests.sh`` to update the bug list). Sort the changelog entries alphabetically and correct any errors you notice. - - [ ] Create a pull request and wait for the tests, merge it. - - [ ] Create a pull request from ``develop`` to ``release``, wait for the tests, then merge it. - - [ ] Make a final check that there are no platform-dependency issues in the ``solc-test-bytecode`` repository. - - [ ] Wait for the tests for the commit on ``release``, create a release in Github, creating the tag. - - [ ] Thank voluntary contributors in the Github release page (use ``git shortlog -s -n -e origin/release..origin/develop``). - - [ ] Wait for the CI runs on the tag itself (they should push artefacts onto the Github release page). - - [ ] Run ``scripts/release_ppa.sh release`` to create the PPA release (you need the relevant openssl key). - - [ ] Check that the Docker release was pushed to Docker Hub (this still seems to have problems, run ``./scripts/docker_deploy_manual.sh release``). - - [ ] Update the homebrew realease in https://github.com/ethereum/homebrew-ethereum/blob/master/solidity.rb (version and hash) - - [ ] Update the default version on readthedocs. - - [ ] Make a release of ``solc-js``: Increment the version number, create a pull request for that, merge it after tests succeeded. - - [ ] Run ``npm publish`` in the updated ``solc-js`` repository. - - [ ] Create a commit to increase the version number on ``develop`` in ``CMakeLists.txt`` and add a new skeleton changelog entry. - - [ ] Merge ``release`` back into ``develop``. - - [ ] Announce on Twitter and Reddit. - - [ ] Lean back, wait for bug reports and repeat from step 1 :) diff --git a/SECURITY.md b/SECURITY.md new file mode 100644 index 0000000000..2f2871cea1 --- /dev/null +++ b/SECURITY.md @@ -0,0 +1,74 @@ +# Security Policy + +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://era.zksync.io/docs/reference/troubleshooting/audit-bug-bounty.html#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 @@ + + + + + + + + + + + + +