diff --git a/.gitbook/docs.json b/.gitbook/docs.json index cb39358b..52e0b805 100644 --- a/.gitbook/docs.json +++ b/.gitbook/docs.json @@ -1116,6 +1116,30 @@ "redirects/https_testnet_blockscout_injective_network_blocks" ] }, + { + "group": "인프라", + "icon": "network-wired", + "expanded": false, + "pages": [ + "ko/infra/index", + { + "group": "노드와 상호작용", + "expanded": false, + "pages": [ + "ko/infra/interact-node/index", + "ko/infra/interact-node/command-line", + "ko/infra/interact-node/grpc", + "ko/infra/interact-node/go", + "ko/infra/interact-node/rest" + ] + }, + "ko/infra/run-node", + "ko/infra/set-up-keyring", + "ko/infra/join-a-network", + "ko/infra/cosmovisor", + "ko/infra/upgrade-node" + ] + }, "ko/faq", "ko/glossary", "ko/references" diff --git a/.gitbook/ko/infra/cosmovisor.mdx b/.gitbook/ko/infra/cosmovisor.mdx new file mode 100644 index 00000000..2d978c2d --- /dev/null +++ b/.gitbook/ko/infra/cosmovisor.mdx @@ -0,0 +1,171 @@ +--- +title: Injective 네트워크를 위한 Cosmovisor 설정 가이드 +--- + +Cosmovisor는 바이너리(체인) 업그레이드 관리를 단순화하는 Cosmos SDK 기반 블록체인용 프로세스 관리자입니다. 이 가이드는 Injective 네트워크 노드에 Cosmovisor를 설정하는 단계별 지침을 제공합니다. + +> **참고:** 이 지침은 기존 체인 바이너리(예: `injectived`)와 소스에서 Cosmovisor를 설치하려는 경우 작동하는 Go 환경이 이미 있다고 가정합니다. 특정 설정에 맞게 이름과 경로를 조정하세요. + +--- + +## 목차 + +1. [설치](#installation) + - [Go를 통한 설치](#installing-via-go) +2. [환경 변수](#environment-variables) +3. [디렉터리 구조](#directory-structure) +4. [Cosmovisor 실행](#running-cosmovisor) +5. [체인 업그레이드 처리](#handling-chain-upgrades) +6. [Systemd 서비스로 Cosmovisor 실행](#running-cosmovisor-as-a-systemd-service) + +--- + +## 설치 + +### Go를 통한 설치 + +Go가 설치되어 있으면 다음 명령으로 Cosmovisor를 설치할 수 있습니다: + +```bash +go install cosmossdk.io/tools/cosmovisor/cmd/cosmovisor@v1.5.0 +``` + +> **팁:** Go 바이너리 설치 경로(일반적으로 `$GOPATH/bin` 또는 `$HOME/go/bin`)가 시스템의 `PATH`에 추가되어 있는지 확인하세요. 다음을 실행하여 설치를 확인할 수 있습니다: +> +> ```bash +> which cosmovisor +> ``` + +## 환경 변수 + +Cosmovisor가 실행할 바이너리와 위치를 알 수 있도록 다음 환경 변수를 설정합니다: + +- **`DAEMON_NAME`** + 체인 바이너리의 이름입니다(예: `injectived`). + +- **`DAEMON_HOME`** + 노드의 홈 디렉터리입니다(예: `~/.injectived`). + +이러한 변수를 쉘의 프로필(`~/.bashrc` 또는 `~/.profile`)에 설정하거나 터미널 세션에서 직접 내보낼 수 있습니다: + +```bash +export DAEMON_NAME=injectived +export DAEMON_HOME=~/.injectived +``` + +--- + +## 디렉터리 구조 + +Cosmovisor는 노드의 홈 디렉터리에서 특정 폴더 구조를 예상합니다: + +1. **Genesis 디렉터리 생성** + + 이 디렉터리는 초기(genesis) 바이너리를 보관합니다. + + ```bash + mkdir -p $DAEMON_HOME/cosmovisor/genesis/bin + ``` + +2. **현재 바이너리 복사** + + 현재 체인 바이너리(예: `injectived`)를 genesis 폴더에 넣습니다. 파일 이름이 `DAEMON_NAME` 값과 일치하는지 확인하세요(다음 섹션 참조). + + ```bash + cp $(which injectived) $DAEMON_HOME/cosmovisor/genesis/bin/injectived + ``` + +--- + +## Cosmovisor 실행 + +체인의 바이너리를 직접 실행하는 대신 다음을 실행하여 Cosmovisor로 노드를 시작합니다: + +```bash +cosmovisor run start +``` + +Cosmovisor는: + +- `$DAEMON_HOME/cosmovisor/genesis/bin`(또는 적절한 업그레이드 폴더)에서 바이너리를 찾습니다. +- 해당 바이너리를 사용하여 노드를 시작합니다. +- 온체인 업그레이드 신호를 모니터링하고 필요할 때 자동으로 바이너리를 전환합니다. + +--- + +## 체인 업그레이드 처리 + +업그레이드가 온체인에서 발표되면 Cosmovisor가 자동으로 전환할 수 있도록 새 바이너리를 준비합니다: + +1. **업그레이드 디렉터리 생성** + + 온체인에서 제공된 업그레이드 이름을 사용합니다(예: `v1.14.0`): + + ```bash + mkdir -p $DAEMON_HOME/cosmovisor/upgrades//bin + ``` + +2. **새 바이너리 배치** + + 새 바이너리를 컴파일하거나 다운로드한 다음 업그레이드 디렉터리에 복사합니다. 바이너리 이름이 `DAEMON_NAME`과 일치하는지 확인하세요. + + ```bash + cp /path/to/new/injectived $DAEMON_HOME/cosmovisor/upgrades//bin + cp /path/to/new/libwasmvm.x86_64.so $DAEMON_HOME/cosmovisor/upgrades//bin + ``` + +> **팁:** GitHub에서 `injectived` 바이너리 패키지를 다운로드한 경우 `libwasmvm.x86_64.so`를 업그레이드 `bin` 디렉터리에 복사합니다. 이 디렉터리를 `LD_LIBRARY_PATH`에 추가하는 환경 변수가 나중에 systemd 서비스에 추가됩니다. + +3. **업그레이드 프로세스** + + 업그레이드 높이에 도달하면 Cosmovisor가 예약된 업그레이드를 감지하고 해당 업그레이드 폴더에 있는 바이너리로 자동 전환합니다. + +--- + +## Systemd 서비스로 Cosmovisor 실행 + +프로덕션 환경에서는 노드를 systemd 서비스로 실행하는 것이 일반적입니다. 아래는 예시 서비스 파일입니다. + +1. **서비스 파일 생성** + + 다음 내용으로 파일(예: `/etc/systemd/system/injectived.service`)을 생성합니다. 경로와 ``을 적절히 조정하세요: + + ```ini + [Unit] + Description=Injective Daemon managed by Cosmovisor + After=network-online.target + + [Service] + User= + ExecStart=/home//go/bin/cosmovisor run start + Restart=always + RestartSec=3 + Environment="DAEMON_NAME=injectived" + Environment="DAEMON_HOME=/home//.injectived" + Environment="PATH=/usr/local/bin:/home//go/bin:$PATH" + Environment="DAEMON_ALLOW_DOWNLOAD_BINARIES=false" + Environment="DAEMON_RESTART_AFTER_UPGRADE=true" + Environment="UNSAFE_SKIP_BACKUP=true" + Environment="LD_LIBRARY_PATH=/home//.injectived/cosmovisor/current/bin" + + [Install] + WantedBy=multi-user.target + ``` + +2. **서비스 활성화 및 시작** + + ```bash + sudo systemctl daemon-reload + sudo systemctl enable injectived.service + sudo systemctl start injectived.service + ``` + +3. **로그 확인** + + 서비스가 원활하게 실행되는지 확인합니다: + + ```bash + journalctl -u injectived.service -f + ``` + +--- diff --git a/.gitbook/ko/infra/index.mdx b/.gitbook/ko/infra/index.mdx new file mode 100644 index 00000000..bdcebdd2 --- /dev/null +++ b/.gitbook/ko/infra/index.mdx @@ -0,0 +1,8 @@ +--- +description: >- + 이 섹션은 노드 운영자 및 검증자가 센트리/검증자 노드를 실행, 업그레이드 및 유지 관리하는 데 도움을 제공합니다. +title: 개요 +--- + +* [메인넷 검증자](/ko/infra/validator-mainnet/) +* [테스트넷 검증자](/ko/infra/validator-testnet/) diff --git a/.gitbook/ko/infra/interact-node/command-line.mdx b/.gitbook/ko/infra/interact-node/command-line.mdx new file mode 100644 index 00000000..b2bd2be1 --- /dev/null +++ b/.gitbook/ko/infra/interact-node/command-line.mdx @@ -0,0 +1,7 @@ +--- +title: CLI를 사용하여 노드와 상호작용 +--- + +`injectived` CLI를 사용하여 노드와 상호작용할 수 있습니다. 로컬 프라이빗 네트워크의 노드와 상호작용하는 경우, CLI를 사용하기 전에 터미널에서 노드가 실행 중인지 확인하세요. + +`injectived` 사용 방법에 대한 자세한 내용은 [injectived 사용하기](/developers/injectived/use/ "mention")를 참조하세요. diff --git a/.gitbook/ko/infra/interact-node/go.mdx b/.gitbook/ko/infra/interact-node/go.mdx new file mode 100644 index 00000000..13173383 --- /dev/null +++ b/.gitbook/ko/infra/interact-node/go.mdx @@ -0,0 +1,88 @@ +--- +title: Go를 사용하여 프로그래밍 방식으로 노드와 상호작용 +--- + + +다음 예제는 Go로 작성되었지만, Python 및 TS SDK를 사용하여 프로그래밍 방식으로 노드/Injective와 상호작용할 수도 있습니다. + +* [TypeScript 예제](/developers-native/examples/) +* [Python 예제](https://github.com/InjectiveLabs/sdk-python/tree/master/examples) + + +다음 스니펫은 Go 프로그램 내에서 gRPC를 사용하여 상태를 쿼리하는 방법을 보여줍니다. 아이디어는 gRPC 연결을 만들고 Protobuf로 생성된 클라이언트 코드를 사용하여 gRPC 서버를 쿼리하는 것입니다. + +```go +import ( + "context" + "fmt" + + "google.golang.org/grpc" + + sdk "github.com/cosmos/cosmos-sdk/types" + "github.com/cosmos/cosmos-sdk/types/tx" +) + +func queryState() error { + myAddress, err := sdk.AccAddressFromBech32("inj...") + if err != nil { + return err + } + + // gRPC 서버에 연결을 생성합니다. + grpcConn := grpc.Dial( + "127.0.0.1:9090", // gRPC 서버 주소. + grpc.WithInsecure(), // SDK는 전송 보안 메커니즘을 지원하지 않습니다. + ) + defer grpcConn.Close() + + // x/bank 서비스를 쿼리하기 위한 gRPC 클라이언트를 생성합니다. + bankClient := banktypes.NewQueryClient(grpcConn) + bankRes, err := bankClient.Balance( + context.Background(), + &banktypes.QueryBalanceRequest{Address: myAddress, Denom: "inj"}, + ) + if err != nil { + return err + } + + fmt.Println(bankRes.GetBalance()) // 계정 잔액을 출력합니다 + + return nil +} +``` + +#### **Go를 사용한 과거 블록 쿼리** + +과거 블록을 쿼리하려면 gRPC 요청에 블록 높이 메타데이터를 추가합니다. + +```go +import ( + "context" + "fmt" + + "google.golang.org/grpc" + "google.golang.org/grpc/metadata" + + grpctypes "github.com/cosmos/cosmos-sdk/types/grpc" + "github.com/cosmos/cosmos-sdk/types/tx" +) + +func queryState() error { + // --snip-- + + var header metadata.MD + bankRes, err = bankClient.Balance( + metadata.AppendToOutgoingContext(context.Background(), grpctypes.GRPCBlockHeightHeader, "12"), // 요청에 메타데이터 추가 + &banktypes.QueryBalanceRequest{Address: myAddress, Denom: denom}, + grpc.Header(&header), // 응답에서 헤더 검색 + ) + if err != nil { + return err + } + blockHeight = header.Get(grpctypes.GRPCBlockHeightHeader) + + fmt.Println(blockHeight) // 블록 높이를 출력합니다 (12) + + return nil +} +``` diff --git a/.gitbook/ko/infra/interact-node/grpc.mdx b/.gitbook/ko/infra/interact-node/grpc.mdx new file mode 100644 index 00000000..3891050c --- /dev/null +++ b/.gitbook/ko/infra/interact-node/grpc.mdx @@ -0,0 +1,62 @@ +--- +title: gRPC를 사용하여 노드와 상호작용 +--- + +Protobuf 생태계는 `*.proto` 파일에서 다양한 언어로 코드를 생성하는 도구를 포함하여 여러 사용 사례를 위한 도구를 개발했습니다. 이러한 도구를 통해 클라이언트를 쉽게 구축할 수 있습니다. 종종 클라이언트 연결(즉, 전송)은 쉽게 교체할 수 있습니다. 인기 있는 전송 방법인 gRPC를 살펴보겠습니다. + +코드 생성 라이브러리는 대부분 여러분의 기술 스택에 따라 다르므로, 두 가지 대안만 제시합니다: + +* 일반적인 디버깅 및 테스트를 위한 `grpcurl` +* Go, Python 또는 TS를 통한 프로그래밍 방식 + +## grpcurl + +[grpcurl](https://github.com/fullstorydev/grpcurl)은 `curl`과 비슷하지만 gRPC용입니다. Go 라이브러리로도 사용할 수 있지만, 여기서는 디버깅 및 테스트 목적의 CLI 명령으로만 사용합니다. 설치하려면 이전 링크의 지침을 따르세요. + +로컬 노드가 실행 중이라고 가정하면(로컬넷이든 라이브 네트워크에 연결되어 있든), 다음 명령을 실행하여 사용 가능한 Protobuf 서비스를 나열할 수 있습니다. `localhost:9090`을 다른 노드의 gRPC 서버 엔드포인트로 대체할 수 있으며, 이는 `app.toml` 내의 `grpc.address` 필드에서 구성됩니다: + +```bash +grpcurl -plaintext localhost:9090 list +``` + +`cosmos.bank.v1beta1.Query`와 같은 gRPC 서비스 목록이 표시됩니다. 이것을 리플렉션이라고 하며, 사용 가능한 모든 엔드포인트에 대한 설명을 반환하는 Protobuf 엔드포인트입니다. 이들 각각은 서로 다른 Protobuf 서비스를 나타내며, 각 서비스는 쿼리할 수 있는 여러 RPC 메서드를 노출합니다. + +서비스에 대한 설명을 얻으려면 다음 명령을 실행하세요: + +```bash +# 검사하려는 서비스 +grpcurl \ + localhost:9090 \ + describe cosmos.bank.v1beta1.Query +``` + +노드에서 정보를 쿼리하기 위해 RPC 호출을 실행할 수도 있습니다: + +```bash +grpcurl \ + -plaintext + -d '{"address":"$MY_VALIDATOR"}' \ + localhost:9090 \ + cosmos.bank.v1beta1.Query/AllBalances +``` + +## grpcurl을 사용한 과거 상태 쿼리 + +일부 [gRPC 메타데이터](https://github.com/grpc/grpc-go/blob/master/Documentation/grpc-metadata.md)를 쿼리에 전달하여 과거 데이터를 쿼리할 수도 있습니다: `x-cosmos-block-height` 메타데이터에 쿼리할 블록이 포함되어야 합니다. 위의 grpcurl을 사용하면 명령은 다음과 같습니다: + +```bash +grpcurl \ + -plaintext \ + -H "x-cosmos-block-height: 279256" \ + -d '{"address":"$MY_VALIDATOR"}' \ + localhost:9090 \ + cosmos.bank.v1beta1.Query/AllBalances +``` + +해당 블록의 상태가 아직 노드에서 정리되지 않았다면, 이 쿼리는 비어 있지 않은 응답을 반환해야 합니다. + +## 트랜잭션 전송 + +gRPC 및 REST를 사용하여 트랜잭션을 전송하려면 몇 가지 추가 단계가 필요합니다: 트랜잭션 생성, 서명, 그리고 마지막으로 브로드캐스트. + +자세한 내용은 [트랜잭션](/defi/transactions/ "mention")에서 확인할 수 있습니다. diff --git a/.gitbook/ko/infra/interact-node/index.mdx b/.gitbook/ko/infra/interact-node/index.mdx new file mode 100644 index 00000000..79a7a974 --- /dev/null +++ b/.gitbook/ko/infra/interact-node/index.mdx @@ -0,0 +1,10 @@ +--- +title: 노드와 상호작용 +--- + +이 섹션에서는 Injective 노드와 상호작용하는 다양한 방법을 다룹니다. + +- [명령줄](/ko/infra/interact-node/command-line) +- [gRPC](/ko/infra/interact-node/grpc) +- [Go](/ko/infra/interact-node/go) +- [REST](/ko/infra/interact-node/rest) diff --git a/.gitbook/ko/infra/interact-node/rest.mdx b/.gitbook/ko/infra/interact-node/rest.mdx new file mode 100644 index 00000000..243db1d3 --- /dev/null +++ b/.gitbook/ko/infra/interact-node/rest.mdx @@ -0,0 +1,44 @@ +--- +title: REST 엔드포인트를 사용하여 노드와 상호작용 +--- + +Cosmos SDK의 모든 gRPC 서비스는 gRPC-gateway를 통해 더 편리한 REST 기반 쿼리에 사용할 수 있습니다. URL 경로의 형식은 Protobuf 서비스 메서드의 전체 정규화된 이름을 기반으로 하지만, 최종 URL이 더 관용적으로 보이도록 약간의 사용자 정의가 포함될 수 있습니다. 예를 들어, `cosmos.bank.v1beta1.Query/AllBalances` 메서드의 REST 엔드포인트는 `GET /cosmos/bank/v1beta1/balances/{address}`입니다. 요청 인수는 쿼리 매개변수로 전달됩니다. + +다음 예제에서는 로컬 프라이빗 네트워크의 노드와 상호작용하기 위해 REST 엔드포인트를 사용한다고 가정합니다. 도메인을 퍼블릭 네트워크로 변경할 수 있습니다. + +구체적인 예로, 잔액 요청을 하는 `curl` 명령은 다음과 같습니다: + +```bash +curl \ + -X GET \ + -H "Content-Type: application/json" \ + http://localhost:1317/cosmos/bank/v1beta1/balances/$MY_VALIDATOR +``` + +`localhost:1317`을 `api.address` 필드에서 구성된 노드의 REST 엔드포인트로 대체하세요. + +사용 가능한 모든 REST 엔드포인트 목록은 Swagger 사양 파일로 제공됩니다; `localhost:1317/swagger`에서 확인할 수 있습니다. `app.toml` 파일에서 `api.swagger` 필드가 true로 설정되어 있는지 확인하세요. + +## REST를 사용한 과거 상태 쿼리 + +과거 상태를 쿼리하려면 HTTP 헤더 `x-cosmos-block-height`를 사용합니다. 예를 들어 curl 명령은 다음과 같습니다: + +```bash +curl \ + -X GET \ + -H "Content-Type: application/json" \ + -H "x-cosmos-block-height: 279256" \ + http://localhost:1317/cosmos/bank/v1beta1/balances/$MY_VALIDATOR +``` + +해당 블록의 상태가 아직 노드에서 정리되지 않았다면, 이 쿼리는 비어 있지 않은 응답을 반환해야 합니다. + +## Cross-Origin Resource Sharing (CORS) + +보안을 위해 [CORS 정책](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS)은 기본적으로 활성화되어 있지 않습니다. rest-server를 사용하려면 리버스 프록시를 제공하는 것이 좋습니다. 이는 [nginx](https://www.nginx.com/)로 수행할 수 있습니다. 테스트 및 개발 목적으로 `app.toml` 내에 `enabled-unsafe-cors` 필드가 있습니다. + +## 트랜잭션 전송 + +gRPC 및 REST를 사용하여 트랜잭션을 전송하려면 몇 가지 추가 단계가 필요합니다: 트랜잭션 생성, 서명, 그리고 마지막으로 브로드캐스트. + +자세한 내용은 [트랜잭션](/defi/transactions/ "mention")에서 확인할 수 있습니다. diff --git a/.gitbook/ko/infra/join-a-network.mdx b/.gitbook/ko/infra/join-a-network.mdx new file mode 100644 index 00000000..542bde96 --- /dev/null +++ b/.gitbook/ko/infra/join-a-network.mdx @@ -0,0 +1,376 @@ +--- +title: 네트워크 참여 +--- + +이 가이드는 로컬에서 독립형 네트워크를 설정하고 메인넷 또는 테스트넷에서 노드를 실행하는 과정을 안내합니다. + +각 네트워크의 하드웨어 요구 사항도 해당 탭에서 확인할 수 있습니다. + + + +로컬 노드를 쉽게 설정하려면 `setup.sh` 스크립트를 다운로드하고 실행하세요. 이렇게 하면 로컬 Injective 네트워크가 초기화됩니다. + +```bash +wget https://raw.githubusercontent.com/InjectiveLabs/injective-chain-releases/master/scripts/setup.sh +chmod +x ./setup.sh # 스크립트를 실행 가능하게 만들기 +./setup.sh +``` + +다음을 실행하여 노드를 시작합니다: + +```bash +injectived start # 이 명령을 실행하면 블록이 들어오기 시작합니다 +``` + +스크립트가 수행하는 작업에 대한 자세한 설명과 설정 프로세스에 대한 더 세밀한 제어를 원하면 아래를 계속 읽으세요. + +#### 체인 초기화 + +Injective 노드를 실행하기 전에 체인과 노드의 제네시스 파일을 초기화해야 합니다: + +```bash +# 인수는 노드의 사용자 지정 사용자 이름입니다. 사람이 읽을 수 있어야 합니다. +injectived init --chain-id=injective-1 +``` + +위의 명령은 노드를 실행하는 데 필요한 모든 구성 파일과 네트워크의 초기 상태를 정의하는 기본 제네시스 파일을 생성합니다. 이러한 모든 구성 파일은 기본적으로 `~/.injectived`에 있지만 `--home` 플래그를 전달하여 이 폴더의 위치를 덮어쓸 수 있습니다. `~/.injectived` 이외의 다른 디렉터리를 사용하기로 선택한 경우 `injectived` 명령을 실행할 때마다 `--home` 플래그로 위치를 지정해야 합니다. 이미 제네시스 파일이 있는 경우 `--overwrite` 또는 `-o` 플래그로 덮어쓸 수 있습니다. + +`~/.injectived` 폴더의 구조는 다음과 같습니다: + +```bash +. # ~/.injectived + |- data # 노드에서 사용하는 데이터베이스를 포함합니다. + |- config/ + |- app.toml # 애플리케이션 관련 구성 파일. + |- config.toml # Tendermint 관련 구성 파일. + |- genesis.json # 제네시스 파일. + |- node_key.json # p2p 프로토콜에서 노드 인증에 사용할 개인 키. + |- priv_validator_key.json # 합의 프로토콜에서 검증자로 사용할 개인 키. +``` + +#### `genesis.json` 파일 수정 + +이 시점에서 `genesis.json` 파일을 수정해야 합니다: + +* staking `bond_denom`, crisis `denom`, gov `denom`, mint `denom` 값을 `"inj"`로 변경합니다. 이것이 Injective의 네이티브 토큰이기 때문입니다. + +다음 명령을 실행하여 쉽게 수행할 수 있습니다: + +```bash +cat $HOME/.injectived/config/genesis.json | jq '.app_state["staking"]["params"]["bond_denom"]="inj"' > $HOME/.injectived/config/tmp_genesis.json && mv $HOME/.injectived/config/tmp_genesis.json $HOME/.injectived/config/genesis.json +cat $HOME/.injectived/config/genesis.json | jq '.app_state["crisis"]["constant_fee"]["denom"]="inj"' > $HOME/.injectived/config/tmp_genesis.json && mv $HOME/.injectived/config/tmp_genesis.json $HOME/.injectived/config/genesis.json +cat $HOME/.injectived/config/genesis.json | jq '.app_state["gov"]["deposit_params"]["min_deposit"][0]["denom"]="inj"' > $HOME/.injectived/config/tmp_genesis.json && mv $HOME/.injectived/config/tmp_genesis.json $HOME/.injectived/config/genesis.json +cat $HOME/.injectived/config/genesis.json | jq '.app_state["mint"]["params"]["mint_denom"]="inj"' > $HOME/.injectived/config/tmp_genesis.json && mv $HOME/.injectived/config/tmp_genesis.json $HOME/.injectived/config/genesis.json +``` + + +위의 명령은 기본 `.injectived` 디렉터리를 사용하는 경우에만 작동합니다. 특정 디렉터리의 경우 위의 명령을 수정하거나 `genesis.json` 파일을 수동으로 편집하여 변경 사항을 반영하세요. + + +#### 검증자 계정용 키 생성 + +체인을 시작하기 전에 최소 하나의 계정으로 상태를 채워야 합니다. 이를 위해 먼저 `test` keyring 백엔드 아래에 `my_validator`라는 새 계정을 keyring에 생성합니다(다른 이름과 다른 백엔드를 자유롭게 선택하세요): + +```bash +injectived keys add my_validator --keyring-backend=test + +# 생성된 주소를 나중에 사용하기 위해 변수에 저장합니다. +MY_VALIDATOR_ADDRESS=$(injectived keys show my_validator -a --keyring-backend=test) +``` + +이제 로컬 계정을 생성했으므로 체인의 제네시스 파일에서 `inj` 토큰을 부여합니다. 이렇게 하면 체인이 제네시스부터 이 계정의 존재를 인식하게 됩니다: + +```bash +injectived add-genesis-account $MY_VALIDATOR_ADDRESS 100000000000000000000000000inj --chain-id=injective-1 +``` + +`$MY_VALIDATOR_ADDRESS`는 keyring의 `my_validator` 키 주소를 보유하는 변수입니다. Injective의 토큰은 `{amount}{denom}` 형식입니다: `amount`는 18자리 정밀도의 소수이고 `denom`은 명명 키(예: `inj`)가 있는 고유한 토큰 식별자입니다. 여기서는 `injectived`에서 스테이킹에 사용되는 토큰 식별자인 `inj` 토큰을 부여합니다. + +#### 체인에 검증자 추가 + +이제 계정에 토큰이 있으므로 체인에 검증자를 추가해야 합니다. 검증자는 체인에 새 블록을 추가하기 위해 합의 과정에 참여하는 특수 풀 노드입니다. 모든 계정이 검증자 운영자가 되겠다는 의사를 선언할 수 있지만, 충분한 위임을 받은 계정만 활성 세트에 들어갈 수 있습니다. 이 가이드에서는 위의 `init` 명령을 통해 생성된 로컬 노드를 체인의 검증자로 추가합니다. 검증자는 `gentx`라는 제네시스 파일에 포함된 특수 트랜잭션을 통해 체인이 처음 시작되기 전에 선언할 수 있습니다: + +```bash +# gentx를 생성합니다. +injectived genesis gentx my_validator 1000000000000000000000inj --chain-id=injective-1 --keyring-backend=test + +# 제네시스 파일에 gentx를 추가합니다. +injectived genesis collect-gentxs +``` + +`gentx`는 세 가지 작업을 수행합니다: + +1. 생성한 `validator` 계정을 검증자 운영자 계정(즉, 검증자를 제어하는 계정)으로 등록합니다. +2. 제공된 `amount`의 스테이킹 토큰을 셀프 위임합니다. +3. 운영자 계정을 블록 서명에 사용될 Tendermint 노드 pubkey와 연결합니다. `--pubkey` 플래그가 제공되지 않으면 위의 `injectived init` 명령을 통해 생성된 로컬 노드 pubkey가 기본값으로 사용됩니다. + +`gentx`에 대한 자세한 정보는 다음 명령을 사용하세요: + +```bash +injectived genesis gentx --help +``` + +#### `app.toml` 및 `config.toml`을 사용하여 노드 구성 + +`~/.injectived/config` 내에 두 개의 구성 파일이 자동으로 생성됩니다: + +* `config.toml`: Tendermint를 구성하는 데 사용됩니다([Tendermint 문서](https://docs.tendermint.com/v0.34/tendermint-core/configuration.html)에서 자세히 알아보기). +* `app.toml`: Cosmos SDK(Injective가 구축된 기반)에서 생성되며 상태 정리 전략, 텔레메트리, gRPC 및 REST 서버 구성, 상태 동기화 등의 구성에 사용됩니다. + +두 파일 모두 자세한 주석이 있습니다. 노드를 조정하려면 직접 참조하세요. + +조정할 예시 구성 중 하나는 `app.toml` 내의 `minimum-gas-prices` 필드입니다. 이 필드는 검증자 노드가 트랜잭션 처리를 위해 기꺼이 수락하는 최소 가스 가격을 정의합니다. 비어 있으면 필드를 `10inj`와 같은 값으로 편집해야 합니다. 그렇지 않으면 노드가 시작 시 중단됩니다. 이 튜토리얼에서는 최소 가스 가격을 0으로 설정합니다: + +```toml + # 검증자가 트랜잭션 처리를 위해 기꺼이 수락하는 최소 가스 가격입니다. + # 트랜잭션 수수료는 이 구성에 지정된 모든 명명의 + # 최소값을 충족해야 합니다 (예: 0.25token1;0.0001token2). + minimum-gas-prices = "0inj" +``` + +#### 로컬넷 실행 + +이제 모든 것이 설정되었으므로 마침내 노드를 시작할 수 있습니다: + +```bash +injectived start # 이 명령을 실행하면 블록이 들어오기 시작합니다 +``` + +이 명령을 사용하면 단일 노드를 실행할 수 있으며, 이것만으로도 노드를 통해 체인과 상호작용하기에 충분하지만 여러 노드를 동시에 실행하여 노드 간의 합의가 어떻게 이루어지는지 확인할 수도 있습니다. + + + +#### 하드웨어 사양 + +노드 운영자는 최적의 성능을 달성하기 위해 베어메탈 서버를 배포해야 합니다. 또한 검증자 노드는 높은 가동 시간을 보장하기 위해 권장 하드웨어 사양, 특히 CPU 요구 사항을 충족해야 합니다. + +| _최소_ | _권장_ | +| :-------------------: | :-------------------: | +| RAM 메모리 128GB | RAM 메모리 128GB | +| CPU 12 코어 | CPU 16 코어 | +| CPU 기본 클럭 3.7GHz | CPU 기본 클럭 4.2GHz | +| 스토리지 2TB NVMe | 스토리지 2TB NVMe | +| 네트워크 1Gbps+ | 네트워크 1Gbps+ | + +#### `injectived` 및 `peggo` 설치 + +가장 최근 릴리스는 [Injective 릴리스 저장소](https://github.com/InjectiveLabs/testnet/releases)를 참조하세요. 검증자가 아닌 노드 운영자는 `peggo`를 설치할 필요가 없습니다. + +```bash +wget https://github.com/InjectiveLabs/testnet/releases/latest/download/linux-amd64.zip +unzip linux-amd64.zip +sudo mv peggo /usr/bin +sudo mv injectived /usr/bin +sudo mv libwasmvm.x86_64.so /usr/lib +``` + +#### 새 Injective 체인 노드 초기화 + +Injective 노드를 실행하기 전에 체인과 노드의 제네시스 파일을 초기화해야 합니다: + +```bash +# 인수는 노드의 사용자 지정 사용자 이름입니다. 사람이 읽을 수 있어야 합니다. +export MONIKER= +# Injective 테스트넷의 chain-id는 "injective-888"입니다 +injectived init $MONIKER --chain-id injective-888 +``` + +`init` 명령을 실행하면 `~/.injectived`에 `injectived` 기본 구성 파일이 생성됩니다. + +#### 테스트넷 참여를 위한 구성 준비 + +이제 기본 구성을 테스트넷의 제네시스 파일과 애플리케이션 구성 파일로 업데이트하고, 시드 노드로 영구 피어를 구성해야 합니다. + +```bash +git clone https://github.com/InjectiveLabs/testnet.git + +# 제네시스 파일을 config 디렉터리에 복사 +aws s3 cp --no-sign-request s3://injective-snapshots/testnet/genesis.json . +mv genesis.json ~/.injectived/config/ + +# config 파일을 config 디렉터리에 복사 +cp testnet/corfu/70001/app.toml ~/.injectived/config/app.toml +cp testnet/corfu/70001/config.toml ~/.injectived/config/config.toml +``` + +제네시스 체크섬도 확인할 수 있습니다 - a4abe4e1f5511d4c2f821c1c05ecb44b493eec185c0eec13b1dcd03d36e1a779 + +```bash +sha256sum ~/.injectived/config/genesis.json +``` + +#### `injectived`용 `systemd` 서비스 구성 + +`/etc/systemd/system/injectived.service`에서 구성을 편집합니다: + +```bash +[Unit] + Description=injectived + +[Service] + WorkingDirectory=/usr/bin + ExecStart=/bin/bash -c '/usr/bin/injectived --log-level=error start' + Type=simple + Restart=always + RestartSec=5 + User=root + +[Install] + WantedBy=multi-user.target +``` + +systemd 서비스 시작 및 재시작 + +```bash +sudo systemctl daemon-reload +sudo systemctl restart injectived +sudo systemctl status injectived + +# 시스템 부팅 시 시작 활성화 +sudo systemctl enable injectived + +# 로그 확인 +journalctl -u injectived -f +``` + +#### 네트워크와 동기화 + +스냅샷을 다운로드하고 네트워크와 동기화하려면 [Polkachu Injective 테스트넷 노드 스냅샷](https://polkachu.com/testnets/injective/snapshots)을 참조하세요. + +**지원** + +추가 질문이 있으시면 [Discord](https://discord.gg/injective), [Telegram](https://t.me/joininjective) 또는 [이메일](mailto:contact@injectivelabs.org)을 통해 Injective 팀에 문의하세요. + + + +#### 하드웨어 사양 + +노드 운영자는 최적의 성능을 달성하기 위해 베어메탈 서버를 배포해야 합니다. 또한 검증자 노드는 높은 가동 시간을 보장하기 위해 권장 하드웨어 사양, 특히 CPU 요구 사항을 충족해야 합니다. + +| _최소_ | _권장_ | +| :-------------------: | :-------------------: | +| RAM 메모리 128GB | RAM 메모리 128GB | +| CPU 12 코어 | CPU 16 코어 | +| CPU 기본 클럭 3.7GHz | CPU 기본 클럭 4.2GHz | +| 스토리지 2TB NVMe | 스토리지 2TB NVMe | +| 네트워크 1Gbps+ | 네트워크 1Gbps+ | + +#### `injectived` 및 `peggo` 설치 + +가장 최근 릴리스는 [Injective 체인 릴리스 저장소](https://github.com/InjectiveLabs/injective-chain-releases/releases/)를 참조하세요. 검증자가 아닌 노드 운영자는 `peggo`를 설치할 필요가 없습니다. + +```bash +wget https://github.com/InjectiveLabs/injective-chain-releases/releases/latest/download/linux-amd64.zip +unzip linux-amd64.zip +sudo mv peggo /usr/bin +sudo mv injectived /usr/bin +sudo mv libwasmvm.x86_64.so /usr/lib +``` + +#### 새 Injective 노드 초기화 + +Injective 노드를 실행하기 전에 체인과 노드의 제네시스 파일을 초기화해야 합니다: + +```bash +# 인수는 노드의 사용자 지정 사용자 이름입니다. 사람이 읽을 수 있어야 합니다. +export MONIKER= +# Injective 메인넷의 chain-id는 "injective-1"입니다 +injectived init $MONIKER --chain-id injective-1 +``` + +`init` 명령을 실행하면 `~/.injectived`에 `injectived` 기본 구성 파일이 생성됩니다. + +#### 메인넷 참여를 위한 구성 준비 + +이제 기본 구성을 메인넷의 제네시스 파일과 애플리케이션 구성 파일로 업데이트하고, 시드 노드로 영구 피어를 구성해야 합니다. + +```bash +git clone https://github.com/InjectiveLabs/mainnet-config + +# 제네시스 파일을 config 디렉터리에 복사 +cp mainnet-config/10001/genesis.json ~/.injectived/config/genesis.json + +# config 파일을 config 디렉터리에 복사 +cp mainnet-config/10001/app.toml ~/.injectived/config/app.toml +``` + +제네시스 체크섬도 확인할 수 있습니다 - 573b89727e42b41d43156cd6605c0c8ad4a1ce16d9aad1e1604b02864015d528 + +```bash +sha256sum ~/.injectived/config/genesis.json +``` + +그런 다음 `~/.injectived/config/config.toml`의 `seeds` 필드를 `mainnet-config/10001/seeds.txt`의 내용으로 업데이트하고 `timeout_commit`을 `300ms`로 업데이트합니다. + +```bash +cat mainnet-config/10001/seeds.txt +nano ~/.injectived/config/config.toml +``` + +#### `injectived`용 `systemd` 서비스 구성 + +`/etc/systemd/system/injectived.service`에서 구성을 편집합니다: + +```bash +[Unit] + Description=injectived + +[Service] + WorkingDirectory=/usr/bin + ExecStart=/bin/bash -c '/usr/bin/injectived --log-level=error start' + Type=simple + Restart=always + RestartSec=5 + User=root + +[Install] + WantedBy=multi-user.target +``` + +systemd 서비스 시작 및 재시작: + +```bash +sudo systemctl daemon-reload +sudo systemctl restart injectived +sudo systemctl status injectived + +# 시스템 부팅 시 시작 활성화 +sudo systemctl enable injectived + +# 로그 확인 +journalctl -u injectived -f +``` + +스냅샷 데이터가 올바른 디렉터리에 로드되기 전에 서비스를 중지하고 이후에 시작해야 합니다. + +```bash +# 노드 중지 +sudo systemctl stop injectived + +# 노드 시작 +sudo systemctl start injectived +``` + +#### 네트워크와 동기화 + +**옵션 1. State-Sync** + +_곧 추가 예정_ + +**옵션 2. 스냅샷** + +**정리됨** + +1. [Polkachu](https://polkachu.com/tendermint_snapshots/injective). +2. [HighStakes](https://tools.highstakes.ch/files/injective.tar.gz). +3. [Imperator](https://www.imperator.co/services/chain-services/mainnets/injective). +4. [Bware Labs](https://bwarelabs.com/snapshots). +5. [AutoStake](https://autostake.com/networks/injective/#validator). + +Injective `mainnet-config seeds.txt` 목록이 작동하지 않는 경우(노드가 블록 동기화에 실패), ChainLayer, Polkachu 및 Autostake는 피어 목록(`config.toml`의 `persistent_peers` 필드에 사용 가능) 또는 주소록(더 빠른 피어 검색용)을 유지 관리합니다. + +**지원** + +추가 질문이 있으시면 [Discord](https://discord.gg/injective), [Telegram](https://t.me/joininjective) 또는 [이메일](mailto:contact@injectivelabs.org)을 통해 Injective 팀에 문의하세요. + + diff --git a/.gitbook/ko/infra/run-node.mdx b/.gitbook/ko/infra/run-node.mdx new file mode 100644 index 00000000..213ba5c6 --- /dev/null +++ b/.gitbook/ko/infra/run-node.mdx @@ -0,0 +1,56 @@ +--- +title: 노드 실행하기 +--- + +퍼블릭 네트워크에 참여하기 전에 로컬 프라이빗 네트워크를 먼저 설정하는 것이 좋습니다. 이렇게 하면 설정 프로세스에 익숙해지고 테스트를 위한 환경을 제공받을 수 있습니다. + +### **프라이빗 네트워크** + +* 로컬에서 독립형 네트워크를 설정하여 참여 + +### **퍼블릭 네트워크** + +* 퍼블릭 엔드포인트를 통해 네트워크 사용; 또는 +* 노드를 실행하여 참여 + +누구나 Injective 블록체인과 통신하기 위한 엔드포인트가 있는 자체 노드를 설정할 수 있습니다. 편의를 위해 체인을 쿼리하는 데 사용할 수 있는 일부 퍼블릭 엔드포인트도 있습니다. 이러한 엔드포인트는 개발 및 테스트 목적으로 권장됩니다. 최대한의 제어와 신뢰성을 위해서는 자체 노드를 실행하는 것이 좋습니다. + +## 노드 실행을 위한 준비 + +노드를 실행하기로 선택한 경우(프라이빗 네트워크 설정 또는 퍼블릭 네트워크 참여), keyring을 설정해야 합니다. 또한 최소한의 다운타임으로 체인 업그레이드를 지원하는 Cosmovisor를 설치할 수도 있습니다. + +## 노드와 상호작용 + +노드가 실행되면 gRPC 엔드포인트, REST 엔드포인트 또는 `injectived` CLI를 사용하여 노드와 상호작용하는 여러 가지 방법이 있습니다. [노드와 상호작용](/ko/infra/interact-node/) 섹션에서 자세히 알아볼 수 있습니다. + +## 노드 실행 가이드 + + + + keyring 설정 방법 알아보기 + + + 네트워크 참여 방법 알아보기 + + + 노드 업그레이드 방법 알아보기 + + diff --git a/.gitbook/ko/infra/set-up-keyring.mdx b/.gitbook/ko/infra/set-up-keyring.mdx new file mode 100644 index 00000000..2cbdf5df --- /dev/null +++ b/.gitbook/ko/infra/set-up-keyring.mdx @@ -0,0 +1,96 @@ +--- +title: Keyring 설정 +--- + + +이 문서는 Injective 노드의 keyring과 다양한 백엔드를 구성하고 사용하는 방법을 설명합니다. keyring을 설정하기 전에 `injectived`가 설치되어 있어야 합니다. 자세한 내용은 [`injectived` 설치 페이지](../developers/injectived/install/)를 참조하세요. + + +keyring은 노드와 상호작용하는 데 사용되는 개인/공개 키 쌍을 보관합니다. 예를 들어, Injective 노드를 실행하기 전에 블록에 올바르게 서명할 수 있도록 검증자 키를 설정해야 합니다. 개인 키는 파일 또는 운영 체제의 자체 키 저장소와 같은 "백엔드"라는 다양한 위치에 저장할 수 있습니다. + +### 사용 가능한 keyring 백엔드 + +#### `os` 백엔드 + +`os` 백엔드는 키 저장을 안전하게 처리하기 위해 운영 체제별 기본값을 사용합니다. 일반적으로 운영 체제의 자격 증명 하위 시스템은 사용자의 암호 정책에 따라 암호 프롬프트, 개인 키 저장 및 사용자 세션을 처리합니다. 가장 인기 있는 운영 체제와 해당 암호 관리자 목록은 다음과 같습니다: + +* macOS (Mac OS 8.6 이후): [Keychain](https://support.apple.com/en-gb/guide/keychain-access/welcome/mac) +* Windows: [Credentials Management API](https://docs.microsoft.com/en-us/windows/win32/secauthn/credentials-management) +* GNU/Linux: + * [libsecret](https://gitlab.gnome.org/GNOME/libsecret) + * [kwallet](https://api.kde.org/frameworks/kwallet/html/index.html) + +GNOME을 기본 데스크톱 환경으로 사용하는 GNU/Linux 배포판은 일반적으로 [Seahorse](https://wiki.gnome.org/Apps/Seahorse)가 함께 제공됩니다. KDE 기반 배포판 사용자에게는 일반적으로 [KDE Wallet Manager](https://userbase.kde.org/KDE_Wallet_Manager)가 제공됩니다. 전자는 실제로 `libsecret`의 편리한 프론트엔드이고, 후자는 `kwallet` 클라이언트입니다. + +`os`는 운영 체제의 기본 자격 증명 관리자가 사용자의 가장 일반적인 요구를 충족하고 보안을 손상시키지 않으면서 편안한 경험을 제공하도록 설계되었기 때문에 기본 옵션입니다. + +헤드리스 환경에서 권장되는 백엔드는 `file` 및 `pass`입니다. + +#### `file` 백엔드 + +`file`은 앱의 구성 디렉터리 내에 암호화된 keyring을 저장합니다. 이 keyring은 액세스할 때마다 암호를 요청하며, 단일 명령에서 여러 번 발생할 수 있어 반복적인 암호 프롬프트가 나타날 수 있습니다. bash 스크립트를 사용하여 `file` 옵션으로 명령을 실행하는 경우 여러 프롬프트에 대해 다음 형식을 사용할 수 있습니다: + +```bash +# KEYPASSWD가 환경에 설정되어 있다고 가정 +yes $KEYPASSWD | injectived keys add me +yes $KEYPASSWD | injectived keys show me +# keyring-backend 플래그로 injectived 시작 +injectived --keyring-backend=file start +``` + + +빈 keyring에 처음 키를 추가할 때 암호를 두 번 입력하라는 메시지가 표시됩니다. + + +#### `pass` 백엔드 + +`pass` 백엔드는 [pass](https://www.passwordstore.org/) 유틸리티를 사용하여 키의 민감한 데이터와 메타데이터의 디스크 암호화를 관리합니다. 키는 앱별 디렉터리 내의 `gpg` 암호화된 파일에 저장됩니다. `pass`는 가장 인기 있는 UNIX 운영 체제와 GNU/Linux 배포판에서 사용할 수 있습니다. 다운로드 및 설치 방법에 대한 정보는 매뉴얼 페이지를 참조하세요. + + +`pass`는 암호화를 위해 [GnuPG](https://gnupg.org/)를 사용합니다. `gpg`는 실행 시 GnuPG 자격 증명 캐싱을 처리하는 `gpg-agent` 데몬을 자동으로 호출합니다. 자격 증명 TTL 및 암호 만료와 같은 캐시 매개변수 구성 방법에 대한 자세한 내용은 `gpg-agent` 매뉴얼 페이지를 참조하세요. + + +암호 저장소는 처음 사용하기 전에 설정해야 합니다: + +```sh +pass init +``` + +``를 GPG 키 ID로 바꾸세요. 개인 GPG 키 또는 암호 저장소를 암호화하는 데 특별히 사용하려는 대체 키를 사용할 수 있습니다. + +#### `kwallet` 백엔드 + +`kwallet` 백엔드는 KDE를 기본 데스크톱 환경으로 제공하는 GNU/Linux 배포판에 기본적으로 설치되는 `KDE Wallet Manager`를 사용합니다. 자세한 내용은 [KWallet 핸드북](https://docs.kde.org/stable/en/kdeutils/kwallet/index.html)을 참조하세요. + +#### `test` 백엔드 + +`test` 백엔드는 `file` 백엔드의 암호 없는 변형입니다. 키는 디스크에 암호화되지 않은 상태로 저장됩니다. + +**테스트 목적으로만 제공됩니다. `test` 백엔드는 프로덕션 환경에서 사용하지 않는 것이 좋습니다**. + +#### `memory` 백엔드 + +`memory` 백엔드는 키를 메모리에 저장합니다. 프로그램이 종료되면 키는 즉시 삭제됩니다. + +**테스트 목적으로만 제공됩니다. `memory` 백엔드는 프로덕션 환경에서 사용하지 않는 것이 좋습니다**. + +### keyring에 키 추가 + +`injectived keys`를 사용하여 keys 명령에 대한 도움말을 볼 수 있고, `injectived keys [command] --help`를 사용하여 특정 하위 명령에 대한 자세한 정보를 얻을 수 있습니다. + + +`injectived completion` 명령으로 자동 완성을 활성화할 수도 있습니다. 예를 들어, bash 세션 시작 시 `. <(injectived completion)`을 실행하면 모든 `injectived` 하위 명령이 자동 완성됩니다. + + +keyring에 새 키를 만들려면 `` 인수와 함께 `add` 하위 명령을 실행합니다. 이 튜토리얼에서는 `test` 백엔드만 사용하고 새 키를 `my_validator`라고 부릅니다. 이 키는 다음 섹션에서 사용됩니다. + +```bash +$ injectived keys add my_validator --keyring-backend test + +# 생성된 주소를 나중에 사용하기 위해 변수에 저장합니다. +MY_VALIDATOR_ADDRESS=$(injectived keys show my_validator -a --keyring-backend test) +``` + +이 명령은 새로운 24단어 니모닉 구문을 생성하고 관련 백엔드에 저장한 다음 키 쌍에 대한 정보를 출력합니다. 이 키 쌍을 가치 있는 토큰을 보관하는 데 사용할 경우 니모닉 구문을 안전한 곳에 기록해 두세요! + +기본적으로 keyring은 `eth_secp256k1` 키 쌍을 생성합니다. keyring은 `--algo ed25519` 플래그를 전달하여 생성할 수 있는 `ed25519` 키도 지원합니다. keyring은 물론 두 가지 유형의 키를 동시에 보관할 수 있습니다. diff --git a/.gitbook/ko/infra/upgrade-node.mdx b/.gitbook/ko/infra/upgrade-node.mdx new file mode 100644 index 00000000..c9f54caf --- /dev/null +++ b/.gitbook/ko/infra/upgrade-node.mdx @@ -0,0 +1,28 @@ +--- +title: 노드 업그레이드 +--- + +### 체인 업그레이드 + +Injective는 정기적으로 소프트웨어 업그레이드를 진행합니다. 체인 업그레이드 거버넌스 제안이 통과되면 모든 노드가 자동으로 패닉 상태가 되어 실행이 중지되는 블록 높이가 지정됩니다. 이 시점에서 업그레이드된 `injectived` 바이너리를 설치하고 노드를 다시 시작할 수 있습니다. + +가장 최근 및 이전 체인 릴리스는 [InjectiveLabs/injective-chain-releases](https://github.com/InjectiveLabs/injective-chain-releases/releases)를 참조하세요. + +### 노드 업그레이드 지침 + +요약하면 노드를 업그레이드하려면 다음 단계를 따르세요: + +1. 업그레이드 거버넌스 제안에서 미리 결정된 블록 높이까지 노드를 동기화합니다. +2. 노드는 미리 결정된 업그레이드 높이에서 자동으로 패닉/중지됩니다. +3. 이전 바이너리를 제거하고 새 릴리스 바이너리를 설치합니다. +4. 노드를 다시 시작합니다. + +### Cosmovisor를 사용한 업그레이드 + +체인 업그레이드를 관리하려면 [Cosmovisor](./cosmovisor/)를 사용하세요. + +### 노드 유지 관리 (스토리지 관리) + +Injective 상태가 커지면 디스크 공간이 가득 찰 수 있습니다. 새 스냅샷을 다운로드하여 체인 데이터를 주기적으로 정리하는 것이 좋습니다. 디스크의 오버헤드 외에도 체인 상태가 작을수록 노드 성능이 더 좋아집니다. + +Injective 검증자는 체인 상태를 정리하는 데 사용할 수 있는 일일 라이트 스냅샷을 만들며, 이는 하루에 약 10-15GB씩 증가합니다. 이러한 스냅샷은 일반적으로 약 2-3GB 정도입니다. 300-400GB마다 체인 데이터를 정리하는 것이 좋습니다. 스냅샷 링크와 스냅샷 적용/노드 동기화 지침은 [메인넷 참여](./join-a-network/)를 참조하세요.