base on Go implementation of an Avalanche node. <div align="center"> <img src="resources/AvalancheLogoRed.png?raw=true"> </div> --- Node implementation for the [Avalanche](https://avax.network) network - a blockchains platform with high throughput, and blazing fast transactions. ## Installation Avalanche is an incredibly lightweight protocol, so the minimum computer requirements are quite modest. Note that as network usage increases, hardware requirements may change. The minimum recommended hardware specification for nodes connected to Mainnet is: - CPU: Equivalent of 8 AWS vCPU - RAM: 16 GiB - Storage: 1 TiB - Nodes running for very long periods of time or nodes with custom configurations may observe higher storage requirements. - OS: Ubuntu 20.04/22.04 or macOS >= 12 - Network: Reliable IPv4 or IPv6 network connection, with an open public port. If you plan to build AvalancheGo from source, you will also need the following software: - [Go](https://golang.org/doc/install) version >= 1.22.8 - [gcc](https://gcc.gnu.org/) - g++ ### Building From Source #### Clone The Repository Clone the AvalancheGo repository: ```sh git clone [email protected]:ava-labs/avalanchego.git cd avalanchego ``` This will clone and checkout the `master` branch. #### Building AvalancheGo Build AvalancheGo by running the build script: ```sh ./scripts/build.sh ``` The `avalanchego` binary is now in the `build` directory. To run: ```sh ./build/avalanchego ``` ### Binary Repository Install AvalancheGo using an `apt` repository. #### Adding the APT Repository If you already have the APT repository added, you do not need to add it again. To add the repository on Ubuntu, run: ```sh sudo su - wget -qO - https://downloads.avax.network/avalanchego.gpg.key | tee /etc/apt/trusted.gpg.d/avalanchego.asc source /etc/os-release && echo "deb https://downloads.avax.network/apt $UBUNTU_CODENAME main" > /etc/apt/sources.list.d/avalanche.list exit ``` #### Installing the Latest Version After adding the APT repository, install `avalanchego` by running: ```sh sudo apt update sudo apt install avalanchego ``` ### Binary Install Download the [latest build](https://github.com/ava-labs/avalanchego/releases/latest) for your operating system and architecture. The Avalanche binary to be executed is named `avalanchego`. ### Docker Install Make sure Docker is installed on the machine - so commands like `docker run` etc. are available. Building the Docker image of latest `avalanchego` branch can be done by running: ```sh ./scripts/build_image.sh ``` To check the built image, run: ```sh docker image ls ``` The image should be tagged as `avaplatform/avalanchego:xxxxxxxx`, where `xxxxxxxx` is the shortened commit of the Avalanche source it was built from. To run the Avalanche node, run: ```sh docker run -ti -p 9650:9650 -p 9651:9651 avaplatform/avalanchego:xxxxxxxx /avalanchego/build/avalanchego ``` ## Running Avalanche ### Connecting to Mainnet To connect to the Avalanche Mainnet, run: ```sh ./build/avalanchego ``` You should see some pretty ASCII art and log messages. You can use `Ctrl+C` to kill the node. ### Connecting to Fuji To connect to the Fuji Testnet, run: ```sh ./build/avalanchego --network-id=fuji ``` ### Creating a Local Testnet The [avalanche-cli](https://github.com/ava-labs/avalanche-cli) is the easiest way to start a local network. ```sh avalanche network start avalanche network status ``` ## Bootstrapping A node needs to catch up to the latest network state before it can participate in consensus and serve API calls. This process (called bootstrapping) currently takes several days for a new node connected to Mainnet. A node will not [report healthy](https://docs.avax.network/build/avalanchego-apis/health) until it is done bootstrapping. Improvements that reduce the amount of time it takes to bootstrap are under development. The bottleneck during bootstrapping is typically database IO. Using a more powerful CPU or increasing the database IOPS on the computer running a node will decrease the amount of time bootstrapping takes. ## Generating Code AvalancheGo uses multiple tools to generate efficient and boilerplate code. ### Running protobuf codegen To regenerate the protobuf go code, run `scripts/protobuf_codegen.sh` from the root of the repo. This should only be necessary when upgrading protobuf versions or modifying .proto definition files. To use this script, you must have [buf](https://docs.buf.build/installation) (v1.31.0), protoc-gen-go (v1.33.0) and protoc-gen-go-grpc (v1.3.0) installed. To install the buf dependencies: ```sh go install google.golang.org/protobuf/cmd/[email protected] go install google.golang.org/grpc/cmd/[email protected] ``` If you have not already, you may need to add `$GOPATH/bin` to your `$PATH`: ```sh export PATH="$PATH:$(go env GOPATH)/bin" ``` If you extract buf to ~/software/buf/bin, the following should work: ```sh export PATH=$PATH:~/software/buf/bin/:~/go/bin go get google.golang.org/protobuf/cmd/protoc-gen-go go get google.golang.org/protobuf/cmd/protoc-gen-go-grpc scripts/protobuf_codegen.sh ``` For more information, refer to the [GRPC Golang Quick Start Guide](https://grpc.io/docs/languages/go/quickstart/). ### Running mock codegen To regenerate the [gomock](https://github.com/uber-go/mock) code, run `scripts/mock.gen.sh` from the root of the repo. This should only be necessary when modifying exported interfaces or after modifying `scripts/mock.mockgen.txt`. ## Versioning ### Version Semantics AvalancheGo is first and foremost a client for the Avalanche network. The versioning of AvalancheGo follows that of the Avalanche network. - `v0.x.x` indicates a development network version. - `v1.x.x` indicates a production network version. - `vx.[Upgrade].x` indicates the number of network upgrades that have occurred. - `vx.x.[Patch]` indicates the number of client upgrades that have occurred since the last network upgrade. ### Library Compatibility Guarantees Because AvalancheGo's version denotes the network version, it is expected that interfaces exported by AvalancheGo's packages may change in `Patch` version updates. ### API Compatibility Guarantees APIs exposed when running AvalancheGo will maintain backwards compatibility, unless the functionality is explicitly deprecated and announced when removed. ## Supported Platforms AvalancheGo can run on different platforms, with different support tiers: - **Tier 1**: Fully supported by the maintainers, guaranteed to pass all tests including e2e and stress tests. - **Tier 2**: Passes all unit and integration tests but not necessarily e2e tests. - **Tier 3**: Builds but lightly tested (or not), considered _experimental_. - **Not supported**: May not build and not tested, considered _unsafe_. To be supported in the future. The following table lists currently supported platforms and their corresponding AvalancheGo support tiers: | Architecture | Operating system | Support tier | | :----------: | :--------------: | :-----------: | | amd64 | Linux | 1 | | arm64 | Linux | 2 | | amd64 | Darwin | 2 | | amd64 | Windows | 3 | | arm | Linux | Not supported | | i386 | Linux | Not supported | | arm64 | Darwin | Not supported | To officially support a new platform, one must satisfy the following requirements: | AvalancheGo continuous integration | Tier 1 | Tier 2 | Tier 3 | | ---------------------------------- | :-----: | :-----: | :-----: | | Build passes | &check; | &check; | &check; | | Unit and integration tests pass | &check; | &check; | | | End-to-end and stress tests pass | &check; | | | ## Security Bugs **We and our community welcome responsible disclosures.** Please refer to our [Security Policy](SECURITY.md) and [Security Advisories](https://github.com/ava-labs/avalanchego/security/advisories). ", Assign "at most 3 tags" to the expected json: {"id":"7501","tags":[]} "only from the tags list I provide: [{"id":77,"name":"3d"},{"id":89,"name":"agent"},{"id":17,"name":"ai"},{"id":54,"name":"algorithm"},{"id":24,"name":"api"},{"id":44,"name":"authentication"},{"id":3,"name":"aws"},{"id":27,"name":"backend"},{"id":60,"name":"benchmark"},{"id":72,"name":"best-practices"},{"id":39,"name":"bitcoin"},{"id":37,"name":"blockchain"},{"id":1,"name":"blog"},{"id":45,"name":"bundler"},{"id":58,"name":"cache"},{"id":21,"name":"chat"},{"id":49,"name":"cicd"},{"id":4,"name":"cli"},{"id":64,"name":"cloud-native"},{"id":48,"name":"cms"},{"id":61,"name":"compiler"},{"id":68,"name":"containerization"},{"id":92,"name":"crm"},{"id":34,"name":"data"},{"id":47,"name":"database"},{"id":8,"name":"declarative-gui "},{"id":9,"name":"deploy-tool"},{"id":53,"name":"desktop-app"},{"id":6,"name":"dev-exp-lib"},{"id":59,"name":"dev-tool"},{"id":13,"name":"ecommerce"},{"id":26,"name":"editor"},{"id":66,"name":"emulator"},{"id":62,"name":"filesystem"},{"id":80,"name":"finance"},{"id":15,"name":"firmware"},{"id":73,"name":"for-fun"},{"id":2,"name":"framework"},{"id":11,"name":"frontend"},{"id":22,"name":"game"},{"id":81,"name":"game-engine "},{"id":23,"name":"graphql"},{"id":84,"name":"gui"},{"id":91,"name":"http"},{"id":5,"name":"http-client"},{"id":51,"name":"iac"},{"id":30,"name":"ide"},{"id":78,"name":"iot"},{"id":40,"name":"json"},{"id":83,"name":"julian"},{"id":38,"name":"k8s"},{"id":31,"name":"language"},{"id":10,"name":"learning-resource"},{"id":33,"name":"lib"},{"id":41,"name":"linter"},{"id":28,"name":"lms"},{"id":16,"name":"logging"},{"id":76,"name":"low-code"},{"id":90,"name":"message-queue"},{"id":42,"name":"mobile-app"},{"id":18,"name":"monitoring"},{"id":36,"name":"networking"},{"id":7,"name":"node-version"},{"id":55,"name":"nosql"},{"id":57,"name":"observability"},{"id":46,"name":"orm"},{"id":52,"name":"os"},{"id":14,"name":"parser"},{"id":74,"name":"react"},{"id":82,"name":"real-time"},{"id":56,"name":"robot"},{"id":65,"name":"runtime"},{"id":32,"name":"sdk"},{"id":71,"name":"search"},{"id":63,"name":"secrets"},{"id":25,"name":"security"},{"id":85,"name":"server"},{"id":86,"name":"serverless"},{"id":70,"name":"storage"},{"id":75,"name":"system-design"},{"id":79,"name":"terminal"},{"id":29,"name":"testing"},{"id":12,"name":"ui"},{"id":50,"name":"ux"},{"id":88,"name":"video"},{"id":20,"name":"web-app"},{"id":35,"name":"web-server"},{"id":43,"name":"webassembly"},{"id":69,"name":"workflow"},{"id":87,"name":"yaml"}]" returns me the "expected json"