Jormungandr 사용자 매뉴얼(한글판)
출처: https://input-output-hk.github.io/jormungandr/introduction.html
번역: 카르다노 앰버서더 Paul Ko
목차
소개
1.일반적인 개념
1.1. 블록체인 개념
1.2. 스테이크
1.3. 노드 구성
2.빠른 시작
2.1. 명령 라인 도구
2.2. 수동 노드 시작
2.3. REST API
2.4. Explorer API
2.5. 리더 후보로 시작
3.구성
3.1. 로징
3.2. 노드 네트워크
3.3. 프레그먼트 풀
3.4. 리더 이벤트
4.jcli
4.1. 암호 키
4.2. 주소
4.3. 트랜잭션(거래)
4.4. 인증서
4.5. 제네시스
4.6. 레스트
5.스테이크 풀 및 스테이크 풀
5.1. 스테이크 위임
5.2. 스테이크 풀 등록
6.고급
6.1. 제네시스 블록
6.2. bft 블록체인 시작하기
6.3. 제네시스 블록체인 시작하기
소개
Jormungandr User Guide에 오신 것을 환영한다.
Jormungandr는 합의 프로토콜 유형인 Ouroboros를 지원하기 위한 초기 목표로 Rust로 쓰여진 노드 구현체이다.
노드는 블록체인 네트워크에 참여하여 블록을 지속적으로 생성하고, 보내고, 받고, 확인한다. 각 노드는 프로토콜의 모든 규칙을 준수할 책임이 있다.
Jörmungandr는 노르웨이 신화에 나오는 미드 가드 뱀을 가리킨다. 그것은 자신의 꼬리를 먹는 고대 이집트 뱀인 우로보로스 (Ouroboros)에 대한 힌트이자, 지분증명에 관한 IOHK 논문이기도 하다.
1. General Concepts(일반적인 개념)
이 장에서는 블록체인의 일반적인 개념과 노드에서의 응용 프로그램을 다루고 노드 조직과 사용자 간의 상호 작용을 설명한다.
1.1. Blockchain concepts(블록체인 개념)
슬롯은 블록체인의 기본 단위를 나타내며 각 슬롯에는 블록이 있을 수 있다.
연속 슬롯은 프로토콜에 의해 정의된 갱신 가능한 크기를 갖는 에포크로 그룹화된다.
프래그먼트는 블록체인 상태 (예 : 프로토콜 업데이트)와 관련된 모든 가능한 이벤트를 나타내는 블록체인 데이터의 일부이며 트랜잭션 및 인증서와 같은 정보의 일반적인 기록이다.
블록은 체인의 블록들을 안전하고 안전하게 연결하면서 유효한 조각을 함께 그룹화하는 블록체인의 등뼈를 나타낸다.
블록은 두 부분으로 구성된다.
-
헤더
-
콘텐츠
헤더는 콘텐츠를 블록과 안전하게 연결하는 반면 콘텐츠는 사실상 일련의 조각들이다.
블록체인은 정기적으로 생성되는 규칙과 블록의 일반적인 집합이다. 일부 규칙과 설정은 업데이트로 시스템에서 동적으로 변경될 수 있지만 일부는 최초 블록 (블록체인의 첫 번째 블록)에 하드 코딩된다.
+——-+ +——-+
|Genesis+<—–+Block 1+<— ….
|Header | |Header |
+—+—+ +—+—+
| |
+—v—+ +—v—+
|Genesis| |Block 1|
|Content| |Content|
+——-+ +——-+
노드는 현재 다음과 같은 합의 프로토콜을 지원한다.
-
Ouroboros BFT (OBFT)
-
우로보로스 제네시스 프라오스
Ouroboros BFT는 간단한 비잔틴 장애 허용 (BFT) 프로토콜로 이것은 블록 생성자가 블록을 연속적으로 만들고 네트워크에서 송출하는 리더들의 알려진 리스트이다.
Ouroboros Genesis Praos는 블록 생성자가 각 스테이크 풀이 지분에 비례하여 블록을 만들기 위해 선출될 수 있는 추첨을 통해 만들어진 지분 증명 (PoS) 프로토콜이다. 각 추첨은 각 스테이크 풀에 비공개이므로 전체 네트워크는 누가 블록을 만들 수 있는지 또는 만들 수 없는지 미리 알지 못한다.
Genesis-Praos에서 슬롯 시간 지속은 계속되지만, 블록을 생성하는 빈도는 안정적이지 않다. 왜냐하면 블록 생성은 스테이크 및 활성 슬롯 계수에 연결된 확률이기 때문이다.
리더십은 추상적인 용어로 표현되며 시스템의 전반적인 리더이며 각 노드가 특정 블록이 합법적으로 시스템에 생성되었는지 확인할 수 있다.
리더십은 새로운 에포크마다 재평가되고 에포크 기간 동안 지속된다.
리더는 블록을 만들 수 있는 권한을 가진 특정 실행자와 관련된 개념이다. OBFT 모드에서는 리더가 암호화 키의 소유자일뿐인 반면, GenesisPraos 모드에서는 리더가 스테이크 풀이 된다.
Transaction(거래)
트랜잭션은 블록체인의 초석을 형성하며 조각의 한 유형이며 가장 빈번한 것이다.
트랜잭션은 입력과 출력으로 구성된다. 한쪽면에서 입력은 송금된 코인을 나타내고, 다른 한면에서 출력은 코인을 받았다는 것을 나타낸다.
Inputs Alice (80$) Bob (20$)
\ /
\ /
———–
120$
———
/ \
Outputs Charlie (50$) Dan (50$)
거래에는 블록체인 설정 및 다음과 같은 고정 보유에 따른 정의된 수수료가 있다.
∑Inputs=∑Outputs+fees
∑Inputs=∑Outputs+fees
트랜잭션은 각각의 증인이 트랜잭션의 각 입력에 의해 권한을 부여 받아야 한다. 가장 기본적인 경우 증인은 암호 서명이지만 입력 유형에 따라 증인 유형이 다를 수 있다.
Accounting(회계)
블록체인에는 상호 운용 가능한 두 가지 회계 방법이 있다.
-
미사용 트랜잭션 출력 (UTXO)
-
계정
UTXO는 현금 / 어음처럼 작동하며 누적된 고정 금액 티켓처럼 작동한다. Bitcoin에서 발견된 회계 모델이다. UTXO는 트랜잭션 ID와 인덱스로 고유하게 참조된다.
계정은 은행계좌처럼 작동하며 정확한 금액을 사용할 수 있으므로 사용하기가 더 쉽다. 이것은 Ethereum에서 발견된 회계 모델이다. 계정은 공개 키로 고유하게 식별된다.
각 입력은 임의로 계정 또는 UTXO를 참조할 수 있으며, 마찬가지로 각 출력은 계정을 참조하거나 새로운 UTXO를 나타낼 수 있다.
지분 증명에 있어서 참가자는 자신이 보유한 코인의 양과 동등한 지분을 발행한다. 스테이크는 프로토콜에 참여할 때 사용되며 간단히 설명하면 다음과 같다.
더 많은 스테이크가 있을수록 네트워크의 건전한 상태에 더 많이 참여하게 될 것이다.
BFT 컨센서스를 사용할 때 스테이크는 시스템이 어떻게 실행되는 지에 영향을 미치지 않지만 나중에 체인을 다른 합의 모드로 전환하기 위해 조작될 수 있다.
Stake in the Account Model(계정 모델에서의 스테이크)
계정은 한가지 유형의 주소로 표시되며 단지 공개 키로 구성된다. 계정에 누적된 금액과 지분력은 그 금액에 직접 반영된다.
예 :
A – Account with 30$ => Account A has stake of 30
B – Account with 0$ => Account B has no stake
UTXO와 관련이 있을 수 있기 때문에 계정에 실제로 포함된 것보다 더 큰 지분이 있을 수 있으며 이 경우는 다음 섹션에서 다룬다.
Stake in the UTXO Model(UTXO모델에서의 스테이크)
UTXO는 두 가지 종류의 주소로 표현된다.
-
단일 주소 : 해당 유형의 주소에는 관련 지분이 없다.
-
그룹 주소 : 이러한 유형의 주소에는 UTXO 값의 스테이크 파워를 받는 계정이 있다
예를 들어 다음과 같은 utxos :
UTXO1 60$ (single address) => has stake of 0
UTXO2 50$ (group address A) \
->- A – Account with 10$ => Account A has stake of 100
UTXO3 40$ (group address A) /
UTXO4 20$ (group address B) –>- B – Account with 5$ => Account B has stake of 25
스테이크 풀은 제네시스 – 프라오스 시스템의 신뢰할 수 있는 블록 생성자이다. 풀은 소유자가 명시적으로 네트워크에서 선언하고 메타 데이터 및 암호화 자료를 포함합니다.
스테이크 풀은 독자적으로 스테이크 파워를 가지고 있지 않지만, 네트워크 참여자는 운영하는 풀에 스테이크를 위임한다.
스테이크는 시스템의 스테이크 풀에 위임할 수 있고 위임할 수 있어야 한다. 새로운 위임 인증서를 발행하면 시간이 지남에 따라 변경될 수 있다.
위임 인증서는 다음 형식의 간단한 선언문이다.
Account ‘A’ delegate to Stake Pool ‘Z’
실제로 그것은 다른 위임 증명서가 만들어 질 때까지 계정의 지분과 관련된 UTXO 지분을 위임한 풀에 할당된다.
안전한 엔클레이브는 비밀 암호 자료를 포함하고 나머지 노드에 안전하고 비밀적인 상위 인터페이스를 제공하는 컴포넌트(구성 요소)이다.
노드의 네트워크는 3가지 컴포넌트(구성 요소)이다.
-
상호 통신 API (GRPC)
-
공개 클라이언트 API (REST)
-
제어 클라이언트 API (REST)
Intercommunication API(상호통신 API)(GRPC)
이 인터페이스는 protobuf 형식과 GRPC 표준을 사용하는 이진수이며 효율적인 인터페이스이다. 형식 및 인터페이스의 protobuf 파일은 소스 코드에서 사용할 수 있다.
인터페이스는 네트워크의 다른 노드와 통신할 책임이 있다.
-
송수신 차단
-
프래그먼트 (트랜잭션, 인증서) 송출
-
피어투피어 간섭
이 인터페이스는 다음과 같은 클라이언트에 대한 간단한 쿼리용이다.
-
월렛 클라이언트 및 미들웨어
-
분석 및 디버깅 도구
-
익스플로러
이 인터페이스를 공개하지 않는 것이 좋습니다.
해야 할 것 : 그것이 하는 일에 대한 고차원적인 개요를 추가하기 바란다.
이 인터페이스는 완료되지 않았지만 프로세스에 대한 유지 보수 작업을 수행할 수 있도록 ACL과의 제한된 인터페이스이다.
-
셧다운
-
암호 자료의 로드 / 폐기
해야 할 것 : ACL / 보안 조치의 세부 사항
Jörmungandr 네트워크 기능은 다음과 같이 나뉜다.
-
정보 조회 또는 노드 제어에 사용되는 REST API;
-
블록체인 프로토콜 교환 및 참여를 위한 gRPC API;
여기서는 후자에 대해서만 언급할 것이다. REST API는 이미 다른 장에서 설명한다. REST 문서로 이동
The protocol(프로토콜)
이 프로토콜은 산업 도구에서 일반적으로 사용되는 HTTP / 2 및 RPC를 기반으로 한다. 보다 정확하게는, Jörmungandr은 gRPC를 사용한다.
이 선택은 이미 전 세계적으로 널리 지원되고 있기 때문에 프록시와 방화벽이 프로토콜을 인식하고 허용하기 쉽게하는 HTTP / 2를 사용하고 있다.
Type of queries(쿼리 유형)
이 프로토콜을 사용하면 노드간에 여러 유형의 메시지를 보낼 수 있다.
-
원격 피어의 마지막 블록에 블록 동기화한다 (tip(팁)).
-
새로운 프래그먼트 (새 트랜잭션, 인증서 등)를 제안한다. 이것은 프래그먼트 전파를 위한 것이다.
-
블록 전파를 위해 새로운 블록을 제안한다.
노드 간 통신 및 동기화를 최적화하는 다른 명령들이 있다.
또 다른 유형의 메시지는 Gossip(가십) 메시지이다. 이를 통해 노드는 네트워크의 다른 노드에 대한 정보 (gossips(가십들))를 교환하여 피어 발견을 허용한다.
Peer discovery(피어 발견)
피어 발견은 Poldercast의 P2P (Peer to Peer) 토폴로지 구성을 통해 수행된다. 이 아이디어는 노드가 p2p 네트워크의 분산 토폴로지를 구축하는 데 적극적으로 참여할 수 있도록 하는 것이다.
이것은 가십핑(gossiping)을 통해 이루어진다. 이것은 다른 토폴로지 정보를 공유하는 프로세스이다. 정보에는 네트워크에 있는 사람, 연락하는 방법 및 관심있는 대상이 포함된다.
폴더캐스트 논문에는 가십 노드와 가시핑 데이터를 선택하는 3가지 서로 다른 전략을 구현하는 3가지 모듈이 있다.
-
Cyclon(사이클론) :이 모듈은 가십 전략에 약간의 무작위성을 추가한다. 또한 노드가 남겨지는 것을 방지하여 가장 적게 사용된 노드와의 접촉을 선호한다.
-
Vicinity(부근) :이 모듈은 토폴로지 노드 사이에 관심 유도 링크를 작성하는 데 도움이 된다. 공통의 관심사를 가진 노드가 종종 접촉해야 한다.
-
RIngs(링스) :이 모듈은 지향적인 노드 목록을 만든다. 네트워크의 노드를 연결하는 임의의 방법이다. 각 주제에 대해 노드는 일련의 폐쇄 노드를 선택한다.
러스트 노드에는 노드를 빠르게 시작하고 블록체인에 연결하기 위한 도구와 도움말이 있다.
대부분의 플랫폼과 호환되며 일부 패키지에는 사전 패키지로 제공된다.
여기서는 jormungandr 과 헬퍼 jcli 를 설치하는 방법과 주어진 블록체인에 빠르게 연결하는 방법을 살펴 볼 것이다.
당신이 jormungandr을 시작할 수 있는 3가지 방법이 있다.
As a passive node in an existing network(현재하는 네트워크의 패시브 노드로서)
여기에 설명 된대로.
패시브 노드는 네트워크에서 가장 일반적인 유형의 노드이다. 피어에게 블록 및 송출 트랜잭션을 다운로드하는 데 사용할 수 있지만 암호화 자료가 없거나 블록을 만들 수 있는 수단이 없다. 이 노드 유형은 주로 지갑, 탐색기 또는 릴레이에 사용된다.
As a node generating blocks in an existing network(현재하는 네트워크에 블록을 생성하는 노드로서)
네트워크는 bft 또는 제네시스 합의 중 하나를 실행할 수 있다. 전자의 경우 노드는 슬롯 리더로 등록된 개인 키를 가지고 있어야 하며, 후자의 경우 등록된 스테이크 풀의 개인 키가 필요하다.
상세한 정보는 여기
Creating your own network(자체 네트워크를 생성)
이는 이전의 경우와 유사하지만 제네시스 파일을 구성해야 한다. 이 절차에 대한 자세한 내용은 고급 섹션을 참조하길 바란다.
2.1. Command lines tools(명령 라인 도구)
이 소프트웨어는 2가지 다른 커맨드 라인 소프트웨어와 번들로 제공된다 :
-
jormungandr : 노드;
-
jcli : Jormungandr Command Line Interface는 노드를 실행하고 노드와 상호 작용하는 헬퍼와 프리미티브입니다.
이것은 권장되는 방법입니다. 릴리즈는 모두 여기에서 사용할 수 있다.
Jormungandr의 코드 소스는 github에서 사용할 수 있다. 지침에 따라 소스에서 소프트웨어를 빌드하길 바란다.
Help and auto completion(도움 및 자동 완성)
모든 명령은 –help 또는 -h 옵션에 대한 사용법 도움말과 함께 제공된다.
jcli의 경우 다음을 사용하여 자동 완성을 생성할 수 있다.
jcli auto-completion bash ${HOME}/.bash_completion.d
지원되는 쉘은 bash, fish, zsh, powershell 및 elvish이다.
참고 : ${HOME}/.bash_completion.d 디렉토리가 이전에 HD에 존재하는지 확인요. 자동 완성 기능을 사용하려면 다음을 수행해야 한다.
source ${HOME}/.bash_completion.d/jcli.bash
${HOME}/.bashrc에 넣을 수도 있다.
2.2. Starting a passive node(수동 노드 시작)
노드를 시작하려면 먼저 연결해야 하는 블록체인 정보를 수집해야 한다.
-
blockchain의 제네시스블록의 해쉬, 이것이 블록체인의 진정성의 원천이 될 것이다. 64자리 16진수이다.
-
신뢰할 수 있는 피어 식별자 및 액세스 포인트
이 정보는 안전한 방법으로 노드를 시작하는 데 필수적이다.
제네시스블록은 블록체인의 첫 번째 블록이다. 여기에는 초기 자금뿐만 아니라 블록체인의 정적 매개 변수가 들어 있다. 당신의 노드는 해쉬를 이용하여 다른 피어들로부터 해쉬를 검색할 것이다. 또한 노드가 다운로드된 제네시스블록의 무결성을 확인할 수 있게 한다.
신뢰할 수 있는 피어는 피어투피어 네트워크를 초기화하기 위해 당신의 노드가 신뢰할 수있는 공용 네트워크의 노드이다.
노드 구성 파일은 다음과 같을 수 있다.
노드
이 설정은 그대로 작동해서는 안되며 신뢰할 수 있는 피어의 IP주소와 포트는 이미 실행중인 노드의 IP주소와 포트여야 한다. 또한 public_address ( ‘u.x.v.t’)는 유효한 주소여야 한다(내부 주소를 사용할 수 있다(예:127.0.0.1). 또한 스토리지 구성에서 지정한 경로에 쓸 수 있는 권한이 있어야 한다.
storage: “/mnt/cardano/storage”
rest:
listen: “127.0.0.1:8443”
peer_2_peer:
trusted_peers:
– id: 1
address: “/ip4/104.24.28.11/tcp/8299”
public_address: “/ip4/u.v.x.y/tcp/8299”
topics_of_interests:
messages: low
blocks: normal
필드 설명 :
-
storage: (선택 사항) 저장소의 경로이다. 생략하면 블록체인은 메모리에만 저장된다.
-
logger: (선택 사항) 로깅 구성 :
-
verbosity: 0 – 경고, 1 – 정보, 2 – 디버그, 3 이상 – 추적
-
format: 로그 출력 형식, plain 또는 json.
-
output: 로그 출력 대상. 가능한 값은 다음과 같다.:
-
stdout: 표준 출력
-
stderr: 표준 에러
-
syslog: syslog (Unix 시스템에서만 사용 가능)
-
journald: journald 서비스 (Linux에서 systemd로만 사용 가능, jormungandr이 systemd기능으로 빌드된 경우)
-
gelf: GELF (Graylog) 네트워크 로깅 프로토콜의 구성 필드 (jormungandr이 gelf기능으로 빌드된 경우):
-
backend: hostname:GELF 서버의 포트
-
log_id: 메세지의 host 필드에 대한 로그 소스의 ID.
-
-
-
-
rest: (선택 사항) REST 엔드 포인트의 구성.
-
listen: address:요청을 수신 대기하는 포트
-
pkcs12: (선택 사항) 인증서 파일
-
-
peer_2_peer: P2P 네트워크 설정
-
trusted_peers: (선택 사항) P2P 토폴로지를 부트스트랩하기 위해 (그리고 로컬 블록체인을 부트스트랩하기 위해) 연결할 노드 목록;
-
public_id: (선택 사항) P2P 네트워크의 다른 노드로 전송된 공개 ID이다. 설정하지 않으면 무작위로 생성된다.
-
public_address: P2P 서비스의 주소를 지정하는 multiaddr 문자열이다. 이것은 노드와의 블록체인 배포에 관심을 가질 수 있는 네트워크의 다른 피어들에게 배포될 공용 주소이다.
-
topics_of_interests: 이 노드가 알고 싶어하는 보급 주제:
-
messages: 거래 및 기타 원장 항목. 비 마이닝 노드의 일반적인 설정: low. 스테이크 풀의 경우 : high;
-
blocks: 새 블록에 대한 알림. 비 마이닝 노드의 일반적인 설정: low. 스테이크 풀의 경우 : high;
-
-
jormungandr –config config.yaml –genesis-block-hash ‘abcdef987654321….’
‘abcdef987654321 ….’부분은 연결하려는 네트워크의 피어 중 한 사람에게서 제공되어야 하는 초기 해시를 나타낸다.
예를 들어 네트워크 생성 때문에 초기 파일이 있는 경우 jcli를 사용하여이 해시를 얻을 수 있다.
cat block-0 | jcli genesis hash
또는 yaml 파일 만있는 경우
cat genesis.yaml | jcli genesis encode | jcli genesis hash
2.3. REST API
REST 인터페이스를 통해 노드를 쿼리할 수 있다.
노드 구성에서 다음과 같이 설정한다.
# …
rest:
listen: “127.0.0.1:8443”
#…
이것은 노드와 통신하거나, 블록을 조회하거나 트랜잭션을 전송하는 REST 엔드 포인트이다.
다음과 같은 엔드 포인트를 가진 노드 통계를 쿼리할 수 있다.
curl http://127.0.0.1:8443/api/v0/node/stats
결과는 이렇게 될 것이다:
{“blockRecvCnt”:120,”txRecvCnt”:92,”uptime”:245}
REST API는 아직 개발 중이다.
엔드 포인트와 결과는 앞으로 변경될 수 있음을 주의해 주길 바란다.
전체 노드 API 설명서를 보려면 여기를 클릭하라
2.4. Explorer API
Explorer mode(탐색기 모드)
탐색기로 작동하도록 노드를 구성할 수 있다. 이로 인해 더 많은 리소스가 소비되지만 사용할 수 없는 데이터를 쿼리할 수 있다.
구성
탐색기 API를 활성화하는 방법에는 두 가지가 있다. 시작 인수에 –enable-explorer 플래그를 전달하거나 구성 파일을 사용하여 수행할 수 있다.
explorer:
enabled: true
CORS
CORS 탐색기 API를 구성하려면 여기에 설명된대로 구성의 REST 섹션에서 수행해야 한다.
API
graphql 인터페이스를 사용하여 탐색기 데이터를 조회할 수 있다. 사용 가능한 경우 REST 인터페이스에서 /explorer/graphql 및 /explorer/graphiql의 두 엔드 포인트를 사용할 수 있다.
전자는 다음과 같이 쿼리가 만들어진 것이다. 예를 들어,
curl \
-X POST \
-H “Content-Type: application/json” \
–data ‘{‘\
‘”query”: “{‘\
‘ status {‘\
‘ latestBlock {‘\
‘ chainLength’\
‘ id’\
‘ previousBlock {‘\
‘ id’\
‘ }’\
‘ }’\
‘ }’\
‘}”‘\
‘}’ \
http://127.0.0.1:8443/explorer/graphql
그 반면에 후자는 대화식으로 쿼리를 시도하는 데 사용할 수있는 브라우저상의 graphql IDE를 제공한다.
2.5.How to start a node as a leader candidate(리더 후보자로서 노드 개시방법)
수동 노드의 경우와 마찬가지로 기존 네트워크에 연결하는 데 두 가지 작업이 필요하다.
-
blockchain의 제네시스블록의 해쉬, 이것이 블록체인의 진정성의 원천이 될 것이다. 64자리 16진수이다.
-
신뢰할 수 있는 피어 식별자 및 액세스 포인트
노드 구성은 패시브 노드를 실행하는 노드 구성과 동일할 수 있다.
제네시스 또는 bft 합의 프로토콜을 실행하는 네트워크에 연결하는 경우에 따라 약간의 차이가 있다.
Connecting to a genesis blockchain(제네시스 블록체인에의 연결)
Registering a stake pool(스테이크 풀 등록)
기존의 제네시스 네트워크에서 블록을 생성하려면 등록된 스테이크 풀이 필요하다.
Creating the secrets file(비밀 파일의 생성)
다음과 같은 방식으로 yaml 파일에 노드 ID와 개인 키를 입력한다.
filename: node_secret.yaml
genesis:
sig_key: Content of stake_pool_kes.prv file
vrf_key: Content of stake_pool_vrf.prv file
node_id: Content of stake_pool.id file
jormungandr –genesis-block-hash asdf1234… –config config.yaml –secret node_secret.yaml
‘asdf1234 …’부분은 네트워크의 실제 block0 해시여야 한다.
Connecting to a BFT blockchain(BFT 블록체인에의 연결)
블록을 생성하려면 노드를 네트워크의 슬롯 리더로 등록하고 다음과 같은 방법으로 시작해야 한다.
yaml file에 비밀키를 입력, 예 node_secret.yaml 를 다음과 같이 입력:
bft:
signing_key: ed25519_sk1kppercsk06k03yk4qgea….
여기서 signing_key는 슬롯 리더의 공개 ID와 연결된 개인 키입니다.
jormungandr –genesis-block asdf1234… –config node.config –secret node_secret.yaml
‘asdf1234 …’부분은 네트워크의 실제 block0 해시여야 한다.
3. 구성
이 장에서는 작동하는 시스템이 있어야 하는 노드 설명서에 대해 설명한다. 여기에는 네트워크, 로깅 및 저장소 매개 변수가 포함된다.
노드 구성은 YAML 형식을 사용한다.
다음은 구성 파일의 예이다.
storage: “/tmp/storage”
logger:
verbosity: 1
format: json
peer_2_peer:
trusted_peers:
– id: 1
address: “/ip4/104.24.28.11/tcp/8299”
– id: 2
address: “/ip4/104.24.29.11/tcp/8299”
public_address: “/ip4/127.0.0.1/tcp/8080”
topics_of_interests:
messages: low
blocks: normal
3.1. Logging(로징)
로거 섹션에서는 다음 옵션을 사용할 수 있다.
-
verbosity:
-
0: 경고
-
1: 정보
-
2: 디버스
-
3 그리고 상위: 추적
-
-
format: 로그 출력 형식 – plain or json.
-
output: 로그 출력 – stdout, stderr, syslog (Unix만), or journald (시스템 디스크만있는 Linux는 컴파일하는 동안 활성화해야 함).
3.2. Node network(노드 네트워크)
해당 섹션에서 다룰 수 있는 두 가지 네트워크 인터페이스가 있다:
rest:
…
peer_2_peer:
…
REST interface configuration(REST인터페이스 구성)
-
listen: listen address
-
pkcs12: certificate file (optional)
-
listen(듣기) : 수신 주소
-
pkcs12 : 인증서 파일 (선택 사항)
-
ttrusted_peers : (선택사항) p2p 토폴로지를 부트스트랩하기 위해 (그리고 로컬 블록체인을 부트스트랩하기 위해) 연결할 노드 목록.
-
public_id : (선택사항) 공개 식별자가 P2P 네트워크의 다른 노드로 전송된다. 설정되지 않은 경우 무작위로 생성된다.
-
public_address : 연결을 수신하고 받아 들일 주소이다. 이것은 노드와의 블록체인 배포에 관심을 가질 수 있는 네트워크의 다른 피어들에게 배포될 공개 주소이다.
-
topics_of_interests : 우리가 듣고 싶은 다양한 주제 :
-
-
메시지: 이 노드가 트랜잭션에 관심이 있음을 다른 피어에게 알림. 마이닝 노드에 대한 일반적인 설정 : “low”. 스테이크 풀의 경우 : “high”;
-
블록 :이 노드가 새로운 블록에 관심이 있음을 다른 피어에게 알림. 마이닝 노드의 일반적인 설정 : “normal”,스테이크 풀의 경우 : “high”;
-
-
3.3. Fragment Pool(프레그먼트 풀)
활성 노드 (BFT 리더 또는 스테이크 풀)를 실행할 때 보류 중인 트랜잭션을 어떻게 관리할 것인지 즉, 유지 기간, 우선 순위 지정 방법 등을 선택할 수 있는 것은 매우 흥미롭다.
노드 구성 파일의 mempool 필드는 필수는 아니며 기본적으로 다음과 같이 설정된다.
mempool:
fragment_ttl: 30m
log_ttl: 1h
garbage_collection_interval: 15m
-
fragment_ttl은 노드가 폐기되기 전에 프래그먼트 (트랜잭션)가 풀에 보류되는 시간을 나타낸다.
-
log_ttl은 노드가 풀에서 보류 / 수락 / 거부된 프래그먼트에 대한 로그를 보관하는 기간을 설명한다. REST 프래그먼트 로그 엔드 포인트에서 수신한 데이터에 대한 링크이다.
-
garbage_collection_interval은 2개의 가비지 수집 실행 간격, 즉 노드가 시간 초과된 항목 (프래그먼트 또는 로그)을 제거할 때의 간격을 나타낸다.
3.4. Leader Event(리더 이벤트)
노드 구성 파일의 리더십 필드는 필수는 아니며 기본적으로 다음과 같이 설정된다.
leadership:
log_ttl: 1h
garbage_collection_interval: 15m
log_ttl은 노드가 리더 이벤트의 로그를 유지하는 기간을 설명한다. 이것은 REST 리더십 로그 엔드 포인트에서 수신한 데이터에 대한 링크이다.
garbage_collection_interval은 2개의 가비지 수집 실행 간격, 즉, 노드가 시간 초과된 항목 로그를 제거할 때의 간격을 나타낸다.
4. jcli
이것은 노드 명령 라인 도우미이다. 이것은 주로 개발자와 스테이크 풀 운영자를 위한 것이다. 오프라인 작업을 허용한다.
-
지갑과 스테이크 풀을 위한 암호 자료 생성;
-
주소, 트랜잭션 및 인증서 작성;
-
새로운 블록체인 준비
노드와의 간단한 상호 작용을 허용한다.
-
쿼리 통계;
-
거래와 인증서를 송신.
-
원시 블록과 UTxO를 취득.
여러 용례에 대해 여러 유형의 키가 있다.
|
유형 |
용법 |
|
Ed25519 |
Ed25519 알고리즘을 위한 서명 알고리즘 |
|
Ed25519Bip32 |
HDWallet과 관련되어, 파생을 위한 체인코드로 Ed25519이 연장됨 |
|
Ed25519Extended |
체인코드 없이 Ed25519Bip32과 관련됨 |
|
SumEd25519_12 |
스테이크 풀을 위해 KES에 필요함 |
|
Curve25519_2HashDH |
스테이크 풀을 위해 VRF에 필요함 |
이 키를 생성하는 명령 라인 매개 변수가 있다:
$ jcli key generate –type=Ed25519
ed25519_sk1cvac48ddf2rpk9na94nv2zqhj74j0j8a99q33gsqdvalkrz6ar9srnhvmt
그리고 관련된 공개 키를 추출한다:
$ echo ed25519_sk1cvac48ddf2rpk9na94nv2zqhj74j0j8a99q33gsqdvalkrz6ar9srnhvmt | jcli key to-public
ed25519_pk1z2ffur59cq7t806nc9y2g64wa60pg5m6e9cmrhxz9phppaxk5d4sn8nsqg
4.2.Address(주소)
Jormungandr은 주소를 생성하고 조작하기 위해 별도의 CLI를 제공한다.
이는 CLI에서 구성 요소로 주소를 작성하고 주소를 디버깅하고 테스트할 때 유용하다.
Display address info(주소 정보 표시)
주소를 표시하고 주소가 유효한 형식인지 확인하려면:
$ jcli address info ta1svy0mwwm7mdwcuj308aapjw6ra4c3e6cygd0f333nvtjzxg8ahdvxlswdf0
discrimination: testing
public key: ed25519e_pk1pr7mnklkmtk8y5tel0gvnksldwywwkpzrt6vvvvmzus3jpldmtpsx9rnmx
또는 예를 들면:
$ jcli address \
info \
ca1qsy0mwwm7mdwcuj308aapjw6ra4c3e6cygd0f333nvtjzxg8ahdvxz8ah8dldkhvwfghn77se8dp76uguavzyxh5cccek9epryr7mkkr8n7kgx
discrimination: production
public key: ed25519_pk1pr7mnklkmtk8y5tel0gvnksldwywwkpzrt6vvvvmzus3jpldmtpsx9rnmx
group key: ed25519_pk1pr7mnklkmtk8y5tel0gvnksldwywwkpzrt6vvvvmzus3jpldmtpsx9rnmx
다음의 각 명령을 사용하면 프로덕션 및 테스트 체인의 주소를 만들 수 있다. 체인의 경우 구별을 테스팅할 경우에는 –testing 플래그를 사용해야 한다.
세 가지 유형의 주소가 있다.
단일 주소 : 간단한 지출 키. 이것은 시스템상에 아무런 이해 관계가 없다.
그룹화 된 주소 : 계정 키에 첨부된 지출 키. 스테이크는 자동
계정 주소 : 계정 키. 이 계정은 자체 지분 계정
다음 명령을 사용하여 이 주소에 대한 지출 공개 키를 사용하여 단일 주소 (비 스테이크)를 작성할 수 있다:
$ jcli address \
single ed25519e_pk1jnlhwdgzv3c9frknyv7twsv82su26qm30yfpdmvkzyjsdgw80mfqduaean
ca1qw207ae4qfj8q4yw6v3ned6psa2r3tgrw9u3y9hdjcgj2p4pcaldyukyka8
스테이킹 정보를 추가하고 그룹 주소를 만들려면 명령의 두 번째 매개 변수로 공개 키를 추가하기 만하면 된다:
$ jcli address \
single \
ed25519_pk1fxvudq6j7mfxvgk986t5f3f258sdtw89v4n3kr0fm6mpe4apxl4q0vhp3k \
ed25519_pk1as03wxmy2426ceh8nurplvjmauwpwlcz7ycwj7xtl9gmx9u5gkqscc5ylx
ca1q3yen35r2tmdye3zc5lfw3x992s7p4dcu4jkwxcda80tv8xh5ym74mqlzudkg42443nw08cxr7e9hmcuzals9ufsa9uvh723kvteg3vpvrcxcq
계정 주소를 만들려면 계정 공개 키가 필요하다:
$ jcli address \
account ed25519_pk1c4yq3hflulynn8fef0hdq92579n3c49qxljasrl9dnuvcksk84gs9sqvc2
ca1qhz5szxa8lnujwva8997a5q42nckw8z55qm7tkq0u4k03nz6zc74ze780qe
changing the address prefix(주소 접두사 변경)
주소 접두부를 변경하여 보다 풍부한 데이터를 사용자에게 제공할 수 있다. 그러나 이 접 두부는 노드로 전달되지 않으며 UI / UX 전용이다.
4.3.transaction(거래)
오프라인 트랜잭션 생성 및 서명을 위한 설정.
jcli transaction
cardano-cli 트랜잭션 빌더에 익숙한 사람들은 jcli transaction에서 유사한 점을 보게 될 것이다.
다음과 같은 두 가지 명령을 사용할 수 있다:
-
거래 준비:
-
new 새로운 무거래 형성;
-
add-input
-
add-account
-
add-output
-
-
finalize 서명을 위한 거래:
-
인증 설정 및 인증 추가:
-
make-witness
-
add-witness
-
-
seal 거래, 블록체인에 송신 준비
트랜잭션의 컨텐츠 정보를 디코딩하고 표시하는 기능도 있다:
-
info
-
id 거래시 거래 ID를 생성할 때
-
to-message cli rest message로 보낼 수 있는 16진수로 인코딩된 메시지를 얻을 때
다음 예제에서는 utxo를 입력으로 사용하는 것에 중점을 둔다. 필요한 경우 계정에서 전송할 때 약간의 차이점이 언급된다. 스테이크 풀 계정에서 참조로 사용할 수 있는 특정 주소로 거래를 보내는 스크립트도 있다.
다음 utxo를 입력으로 사용하여 50개의 lovelaces를 대상 주소로 전송해 보자.
|
Field(필드) |
Value(값) |
|
UTXO’s transaction ID |
55762218e5737603e6d27d36c8aacf8fcd16406e820361a8ac65c7dc663f6d1c |
|
UTXO’s output index |
0 |
|
associated address |
ca1q09u0nxmnfg7af8ycuygx57p5xgzmnmgtaeer9xun7hly6mlgt3pjyknplu |
|
associated value |
100 |
addressca1qvnr5pvt9e5p009strshxndrsx5etcentslp2rwj6csm8sfk24a2wlqtdj6
Create a staging area(준비 영역 생성)
jcli transaction new > tx
입력 값으로 UTXO의 트랜잭션 ID와 UTXO의 출력 인덱스 필드를 사용하여 uxto를 참조해야 하며 관련 값 필드에 얼마나 많은 코인이 있는지 지정해야 한다.
jcli transaction add-input 55762218e5737603e6d27d36c8aacf8fcd16406e820361a8ac65c7dc663f6d1c 0 100 –staging tx
입력이 계정인 경우 명령이 약간 다르다.
jcli transaction add-account account_address account_funds –staging tx
출력을 위해 우리는 전송하고자 하는 주소와 금액이 필요하다.
jcli transaction add-output ca1qvnr5pvt9e5p009strshxndrsx5etcentslp2rwj6csm8sfk24a2wlqtdj650 –staging tx
우리는 우리가 보내는 주소 (utxo의 관련 주소)에서 변경을 원한다. 우리는 또한 요금을 계산하는 방법을 지정한다. –fee-constant 5 –fee-coefficient 2 모두 0인 경우에는 생략할 수 있다.
jcli transaction finalize ca1q09u0nxmnfg7af8ycuygx57p5xgzmnmgtaeer9xun7hly6mlgt3pjyknplu –fee-constant 5 –fee-coefficient 2 –staging tx
자 이제, 실행을 하게 되면
jcli transaction info –fee-constant 5 –fee-coefficient 2 –staging tx
다음과 같은 결과를 볼 수 있을 것이다
Transaction `0df39a87d3f18a188b40ba8c203f85f37af665df229fb4821e477f6998864273′ (finalizing)
Input: 100
Output: 89
Fees: 11
Balance: 0
– 55762218e5737603e6d27d36c8aacf8fcd16406e820361a8ac65c7dc663f6d1c:0 100
+ ca1qvnr5pvt9e5p009strshxndrsx5etcentslp2rwj6csm8sfk24a2wlqtdj650 50
+ ca1q09u0nxmnfg7af8ycuygx57p5xgzmnmgtaeer9xun7hly6mlgt3pjyknplu 39
트랜잭션에 서명하려면 입력 주소 (utxos에 있는 것)와 연결된 개인 키와 연결되어있는 네트워크의 최초 블록 해시가 필요하다.
이 block0 해시에 의해 시작된 특정 블록체인에 대한 트랜잭션에 서명할 때 트랜잭션이 다른 블록체인에서 재사용 될 수 없도록 하고 오프라인 트랜잭션 서명에서 보안 문제를 해결위해서는 최초의 블록 해시가 필요하다.
다음 명령은 key.prv 파일에서 개인 키를 사용하고 현재 디렉터리에 witness라는 이름의 파일에 인증을 설정한다.
jcli transaction make-witness –genesis-block-hash abcdef987654321… –type utxo txid witness key.prv
계정을 입력으로 사용하는 경우 명령은 유형 및 추가 매개 변수로 account(계정)을 고려한다. –account-spending-counter는 계정이 입력으로 사용될 때마다 증가해야 한다.
예를 들면
jcli transaction make-witness –genesis-block-hash abcdef987654321… –type account –account-spending-counter 0 witness key.prv
jcli transaction add-witness witness –staging tx
jcli transaction seal –staging tx
jcli transaction to-message –staging tx > txmsg
Rest API를 사용하여 보내기
jcli rest v0 message post -f txmsg –host http://127.0.0.1:8443/api
Checking if the transaction was accepted(거래 승인여부 확인)
Rest api를 사용하여 전송한다. 트랜잭션이 승인되면 노드 로그를 점검하여 트랜잭션이 승인되었는지 점검할 수 있다. 예를 들면
jcli rest v0 message logs -h http://127.0.0.1:8443/api
—
– fragment_id: d6ef0b2148a51ed64531efc17978a527fd2d2584da1e344a35ad12bf5460a7e2
last_updated_at: “2019-06-11T15:38:17.070162114Z”
received_at: “2019-06-11T15:37:09.469101162Z”
received_from: Rest
status:
InABlock: “4.707”
Where the InABlock status means that the transaction was accepted in the block with date “4.707”.
The status here could also be:
Pending: if the transaction is received and is pending being added in the blockchain (or rejected).
or
Rejected: with an attached message of the reason the transaction was rejected.
여기서 InABlock 상태는 트랜잭션이 “4.707”날짜의 블록에서 승인되었음을 의미한다.
상태는 다음과 같다.
Pending(보류 중) : 트랜잭션이 수신되어 보류중인 경우 블록체인에 추가된다 (또는 거부 됨).
또는
Rejected(거부됨) : 트랜잭션이 거부 된 이유에 대한 첨부 메시지가 있습니다.
4.4.certificate(인증서)
오프라인 트랜잭션 생성을 위한 설정
서명된 인증서를 작성.
프로세스가 첫 번째 단계에서 여러 단계로 나뉘어져 인증서가 만들어진다.
jcli certificate new stake-pool-registration \
–vrf-key –kes-key \
[–owner ] \
–serial \
출력 파일을 생략하면 result가 stdout에 기록된다. 인증서가 준비되면 모든 소유자의 개인 키로 서명해야 한다:
jcli certificate sign
4.5. Genesis(제네시스)
제네시스 파일 작업을 위한 설정
jcli genesis [subcommand]
-
디코드 : 인코딩된 기원 블록에 해당하는 YAML파일을 출력한다.
-
인코드 : 주어진 yaml 파일로 부터 블록체인의 기원 블록을 만든다.
-
hash : 제네시스의 블록해시를 출력한다.
-
init : YAML 파일을 만드는 데 도움이 되는 적절한 문서가 있는 기본 Genesis 파일 만든다
-
도움말
Encode a genesis file(제네시스 파일을 인코드)
jcli genesis encode –input genesis.yaml –output block-0.bin
또는 동일하게
cat genesis.yaml | jcli genesis encode > block-0.bin
Get the hash of an encoded genesis file(인코딩된 제네시스 파일의 해쉬를 생성)
jcli genesis hash –input block-0.bin
4.6. REST(레스트)
Jormungandr에는 HTTP를 통한 노드와의 수동 통신을 위한 CLI 클라이언트가 함께 제공된다.
많은 CLI 명령에는 공통 인수가 있다:
-
-h 나 –host – 노드 API 주소. 항상 반드시 http:// 또는 https://의 접두사가 있어야 함. 예를 들면. -h http://127.0.0.1, –host https://node.com:8443/cardano/api
-
–debug – 추가 디버그 정보를 stderr에 출력 출력 형식이 의도적으로 문서화되지 않고 불안정하다.
-
–output-format – 출력 정보의 형식. 가능한 값은 json, yaml, default yaml이다. 다른 값은 출력 데이터 구조 값을 사용하여 사용자 정의 형식으로 처리된다. 구문은 Go 텍스트 템플릿이다: https://golang.org/pkg/text/template/.
노드 통계를 가져온다
jcli rest v0 node stats get
옵션은 다음과 같다.
-
-h – conventions(규칙)을 참조
-
–debug-conventions(규칙)을 참조
-
–output-format – conventions(규칙)을 참조
YAML은 성공으로 표시
—
blockRecvCnt: 7 # Blocks received by node
txRecvCnt: 90 # Transactions received by node
uptime: 2101 # Node uptitme in seconds
모든 UTXO를 불러온다
jcli rest v0 utxo get
옵션은 다음과 같다.
-
-h – conventions(규칙)을 참조
-
–debug-conventions(규칙)을 참조
-
–output-format – conventions(규칙)을 참조
YAML은 성공으로 표시
—
– in_idx: 0 # input index
in_txid: 50f21ac6bd3f57f231c4bf9c5fff7c45e2529c4dffed68f92410dbf7647541f1 # input transaction hash in hex
out_addr: ca1qvqsyqcyq5rqwzqfpg9scrgwpugpzysnzs23v9ccrydpk8qarc0jqxuzx4s # output address in bech32
out_value: 999999999 # output value
서명되고 16진수로 인코딩된 트랜잭션을 게시한다.
jcli rest v0 message post
옵션은 다음과 같다.
-
-h – conventions(규칙)을 참조
-
–debug-conventions(규칙)을 참조
-
-f –file – 16 진수로 인코딩된 트랜잭션을 포함하는 파일. 제공되지 않으면 트랜잭션이 stdin에서 읽혀진다.
프래그먼트 ID는 성공시 출력된다 (get message log 명령을 사용하여 트랜잭션 상태를 찾는 데 도움이 됨)
50f21ac6bd3f57f231c4bf9c5fff7c45e2529c4dffed68f92410dbf7647541f1
메시지 풀에서 노드의 로그를 가져온다. 보류중인 트랜잭션, 거부된 트랜잭션 또는 트랜잭션이 블록에 추가된 경우에 대한 정보를 제공한다.
jcli rest v0 message logs
옵션은 다음과 같다.
-
-h – conventions(규칙)을 참조
-
–debug-conventions(규칙)을 참조
-
–output-format – conventions(규칙)을 참조
YAML은 성공으로 표시
—
– fragment_id: 7db6f91f3c92c0aef7b3dd497e9ea275229d2ab4dba6a1b30ce6b32db9c9c3b2 # hex-encoded fragment ID
last_updated_at: 2019-06-02T16:20:26.201000000Z # RFC3339 timestamp of last fragment status change
received_at: 2019-06-02T16:20:26.201000000Z # RFC3339 timestamp of fragment receivement
received_from: Network, # how fragment was received
status: Pending, # fragment status
received_from 다음 중 하나가 될 수 있다:
received_from: Rest # fragment was received from node’s REST API
received_from: Network # fragment was received from the network
status 다음 중 하나가 될 수 있다::
status: Pending # fragment is pending
status:
Rejected: # fragment was rejected
reason: reason of rejection # cause
status: # fragment was included in a block
InABlock: “6637.3” # block epoch and slot ID formed as .
블록체인 팁의 16진수 코드 ID를 검색한다.
jcli rest v0 tip get
옵션은 다음과 같다.
-
-h – conventions(규칙)을 참조
-
–debug-conventions(규칙)을 참조
주어진 ID로 16진수로 인코딩된 블록 검색
jcli rest v0 block get
– 16진수로 인코딩된 블록 ID
옵션은 아래와 같다.
-
-h – conventions 를 참조
-
–debug – conventions 를 참조
Get next block ID(다음 블록 ID 생성)
지정된 ID를 가진 블록의 하위 항목의 16진수 코드 ID목록을 검색한다. 모든 목록 요소는 별도의 행에 있다. ID는 가까운 곳에서 먼 곳으로 정렬된다.
jcli rest v0 block next-id get
– 16진수로 인코딩된 블록 ID
옵션은 아래와 같다.
-
-h – conventions 를 참조
-
–debug – conventions 를 참조
-
-c –count – Maximum number of IDs, must be between 1 and 100, default 1
계정 상태 가져 오기
jcli rest v0 account get
– 계정 ID, bech32로 인코딩
옵션은 아래와 같다.
-
-h – conventions 를 참조
-
–debug – conventions 를 참조
-
–output-format – conventions 를 참조
YAML은 성공으로 표시
—
counter: 1
delegation: c780f14f9782770014d8bcd514b1bc664653d15f73a7158254730c6e1aa9f356
value: 990
-
value 계정의 현재 잔고;
-
counter 이 계정을 사용하여 수행된 트랜잭션 수입이다. 이는 새 트랜잭션에 서명할 때 알아두면 유용하다;
-
delegation 계정이 위임하는 스테이크 풀 식별자이다. 이 계정에 연결된 전송 위임 인증서가 없는 경우에 이 값이 설정되지 않을 수 있다.
Node settings(노드 설정)
노드 설정을 가져온다.
jcli rest v0 settings get
옵션은 다음과 같다.
-h – conventions(규칙)을 참조
–debug-conventions(규칙)을 참조
–output-format – conventions(규칙)을 참조
YAML은 성공으로 표시
—
block0Hash: 8d94ecfcc9a566f492e6335858db645691f628b012bed4ac2b1338b5690355a7 # block 0 hash of
block0Time: “2019-07-09T12:32:51+00:00” # block 0 creation time of
consensusVersion: bft # currently used consensus
currSlotStartTime: “2019-07-09T12:55:11+00:00” # current slot start time
fees: # transaction fee configuration
certificate: 4 # fee per certificate
coefficient: 1 # fee per every input and output
constant: 2 # fee per transaction
maxTxsPerBlock: 100 # maximum number of transactions in block
Node shutdown(노드 종료)
노드 종료
jcli rest v0 shutdown get
옵션은 다음과 같다.
-h – conventions(규칙)을 참조
–debug-conventions(규칙)을 참조
Get leaders(리더 얻기)
리더 ID 목록을 가져온다.
jcli rest v0 leaders get
옵션은 다음과 같다.
-h – conventions(규칙)을 참조
–debug-conventions(규칙)을 참조
–output-format – conventions(규칙)을 참조
YAML은 성공으로 표시
—
– 1 # list of leader IDs
– 2
Register leader(리더 등록)
새로운 리더를 등록하고 ID를 얻는다
jcli rest v0 leaders post
옵션은 다음과 같다.
-h – conventions(규칙)을 참조
–debug-conventions(규칙)을 참조
–output-format – conventions(규칙)을 참조. -f, –file-리더 비밀이 있는 YAML을 포함하는 파일. 비밀 YAML이 Jormungandr에 –secret과 같은 형식으로 전달되어야 한다. 만약 그렇지 않으면 stdin에서 YAML을 읽는다.
성공하면 리더 ID가 출력된다.
3
Delete leader(리더 삭제)
주어진 아이디로 리더 삭제
jcli rest v0 leaders delete
-삭제 된 리더 ID
-h – conventions(규칙)을 참조
–debug-conventions(규칙)을 참조
Get leadership logs(리더십 로그 얻기)
리더십 로그를 가져온다.
jcli rest v0 leaders logs get
옵션은 다음과 같다.
-h – conventions(규칙)을 참조
–debug-conventions(규칙)을 참조
–output-format – conventions(규칙)을 참조
YAML은 성공으로 표시
—
– created_at_time: “2019-08-19T12:25:00.417263555+00:00”
enclave_leader_id: 1
finished_at_time: “2019-08-19T23:19:05.010113333+00:00”
scheduled_at_date: “0.3923”
scheduled_at_time: “2019-08-19T23:18:35+00:00”
wake_at_time: “2019-08-19T23:18:35.001254555+00:00”
Get stake pools(스테이크 풀 생성)
스테이크 풀 리스트를 가져온다
jcli rest v0 stake-pools get
옵션은 다음과 같다.
-h – conventions(규칙)을 참조
–debug-conventions(규칙)을 참조
–output-format – conventions(규칙)을 참조
YAML은 성공으로 표시
—
– 5cf03f333f37eb7b987dbc9017b8a928287a3d77d086cd93cd9ad05bcba7e60f # list of stake pool IDs
– 3815602c096fcbb91072f419c296c3dfe1f730e0f446a9bd2553145688e75615
Get stake distribution(스테이크 분배 받기)
스테이크 정보를 가져온다
jcli rest v0 stake get
옵션은 다음과 같다.
-h – conventions(규칙)을 참조
–debug-conventions(규칙)을 참조
–output-format – conventions(규칙)을 참조
YAML은 성공으로 표시
—
epoch: 228 # Epoch of last block
stake:
dangling: 0 # Total value stored in accounts, but assigned to nonexistent pools
pools:
– – 5cf03f333f37eb7b987dbc9017b8a928287a3d77d086cd93cd9ad05bcba7e60f # stake pool ID
– 1000000000000 # staked value
– – 3815602c096fcbb91072f419c296c3dfe1f730e0f446a9bd2553145688e75615 # stake pool ID
– 1000000000000 # staked value
unassigned: 0 # Total value stored in accounts, but not assigned to any pool
Network stats(네트워크 통계)
네트워크 통계를 가져온다
jcli rest v0 network stats get
옵션은 다음과 같다.
-h – conventions(규칙)을 참조
–debug-conventions(규칙)을 참조
–output-format – conventions(규칙)을 참조
YAML은 성공으로 표시
—
# hex-encoded node ID
– nodeId: 0102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f20
# timestamp of when the connection was established
establishedAt: “2019-10-14T06:24:12.010231281+00:00”
# timestamp of last time block was received from node if ever (optional)
lastBlockReceived: “2019-10-14T00:45:57.419496113+00:00”
# timestamp of last time fragment was received from node if ever (optional)
lastFragmentReceived: “2019-10-14T00:45:58.419496150+00:00”
# timestamp of last time gossip was received from node if ever (optional)
lastGossipReceived: “2019-10-14T00:45:59.419496188+00:00”
5.staking and stake pool(스테이크 풀 및 스테이크 풀)
Staking with jormungandr(jormungandr로 스테이킹)
여기서는 다음과 같은 방법을 설명한다.
-
지분을 스테이크 풀에 위임하여 합의에 참여할 수 있고 그에 대한 보상을 받을 수도 있다.
블록체인 사용자인 경우 스테이크 풀 등록 방법에 대한 마지막 섹션을 볼 필요는 없다.
5.1.Delegating your stake(스테이크 위임)
how to create the delegation certificate(위임인증서를 생성 방법)
스테이크는 계정에 집중되어 있으며 관련 스테이크를 위임하려면 계정 키가 필요하다.
당신은 당신의 이하의 것이 필요할 것이다 :
-
계정 공개 키 : 공개 키의 bech32 문자열
-
Stake Pool ID : 스테이크를 위임할 스테이크 풀을 식별하는 16진수 문자열.
$ jcli certificate new stake-delegation STAKE_POOL_ID ACCOUNT_PUBLIC_KEY > stake_delegation.cert
how to sign your delegation certificate(위임 인증서에 서명하는 방법)
계정 소유자가 이 위임이 발생하도록 승인해야 하며,이를 위해 암호화 서명이 필요하다.
서명을 생성하려면 계정 비밀 키가 필요하다.
$ cat stake_delegation.cert | jcli certificate sign account_key.prv | tee stake_delegation.cert
cert1q8rv4ccl54k99rtnm39…zr0
이제 출력을 transaction (트랜잭션)에 추가하고 노드에 제출할 수 있다.
jcli transaction add-certificate 명령을 사용하여 최종화된 상태의 트랜잭션에 인증서를 추가할 수 있다.
예:
…
jcli transaction finalize CHANGE_ADDRESS –fee-constant 5 –fee-coefficient 2 –fee-certificate 2 –staging tx
jcli transaction add-certificate $(cat stake_delegation.cert) –staging tx
…
–fee-certificate 플래그는 수수료 계산에 사용되는 인증서를 추가하는 비용을 나타내며 0인 경우 생략할 수 있다.
트랜잭션 생성에 대한 자세한 내용은 여기를 참조하십시오.
5.2.registering stake pool(스테이크 풀 등록)
스테이크 풀을 실행할 때 알아야 할 여러 가지 구성 요소가 있다.
-
NodeId: 블록체인 프로토콜 내의 식별자이다 (지갑은 이 NodeId:(노드 아이디)를 통해 스테이크 풀에 위임한다).
-
당신의 VRF 키 쌍 : 리더 선거에 참여하기 위해 사용할 암호 자료이다.
-
당신의 [KES] 키 쌍 : 블록을 서명하기 위해 사용하는 암호 자료이다.
따라서 스테이크 풀을 시작하려면 이러한 개체를 생성해야 한다.
VRF 키 쌍을 생성하려면 여기에 설명 된대로 [jcli] 를 활용한다:
$ jcli key generate –type=Curve25519_2HashDH > stake_pool_vrf.prv
stake_pool_vrf.prv 파일에 VRF 개인 키가 포함된다.
$ cat stake_pool_vrf.prv | jcli key to-public > stake_pool_vrf.pub
상기와 유사
$ jcli key generate –type=SumEd25519_12 > stake_pool_kes.prv
stake_pool_kes.prv 파일에 KES 개인 키가 포함된다
$ cat stake_pool_kes.prv | jcli key to-public > stake_pool_kes.pub
creating your stake pool certificate
인증서는 스테이크 풀이라는 블록 체인의 다른 참가자들에게 자신을 등록하기 위해 블록체인으로 보내질 것이다.
$ jcli certificate new stake-pool-registration \
–kes-key $(cat stake_pool_kes.pub) \
–vrf-key $(cat stake_pool_vrf.pub) \
–serial 1010101010 > stake_pool.cert
이제 소유자 키로 이 인증서에 서명해야 한다.
$ cat stake_pool.cert | jcli certificate sign stake_key.prv | tee stake_pool.cert
cert1qsqqqqqqqqqqqqqqqqqqq0p5avfqp9tzusr26…cegxaz
이제 스테이크 풀 ID를 검색할 수 있다 (NodeId):
$ cat stake_pool.cert | jcli certificate get-stake-pool-id | tee stake_pool.id
ea830e5d9647af89a5e9a4d4089e6e855891a533316adf4a42b7bf1372389b74
이 섹션은 노드의 고급 사용자 및 개발자를 위한 것이거나 노드에 대해 자세히 알고자 하는 경우에 사용된다.
현재는 자신의 블록체인 제네시스 구성을 생성하는 방법에 대한 자세한 내용만을 다루지만 일반적인 경우에는 블록체인 구성이 특정 블록체인 시스템에서 사용 가능해야 한다.
제네시스 파일은 블록0에서 새로운 블록체인을 생성할 수 있게 해주는 파일이다. 이것은 블록체인의 다른 매개 변수인 초기 utxo, 시작 시간, 슬롯 지속 시간 등을 배치한다.
초기 주소 UTxO와 계정 UTxO를 가진 BFT 제네시스 파일의 예.
BFT 블록체인 시작에 관한 자세한 사항은 여기 및 주소에 관해서는 여기. jcli genesis tooling에 관한 정보도 또한 발견할 수 있다.
문서화된 미리 생성된 제네시스 파일을 생성할 수 있다:
jcli genesis init
예를 들면 당신의 제네시스 파일이 다음과 같을 수 있다:
# The Blockchain Configuration defines the settings of the blockchain.
blockchain_configuration:
# The block0-date defines the date the blockchain starts
# expected value in seconds since UNIX_EPOCH
#
# By default the value will be the current date and time. Or you can
# add a specific time by entering the number of seconds since UNIX
# Epoch
block0_date: {default_block0_date}
# This is the type of discrimination of the blockchain
# of this blockchain is meant for production then
# use ‘production’ instead.
#
# otherwise leave as this
discrimination: {discrimination}
# The initial consensus version:
#
# * BFT consensus: bft
# * Genesis Praos consensus: genesis
block0_consensus: bft
# Number of slots in each epoch.
#
# default value is {default_slots_per_epoch}
slots_per_epoch: {default_slots_per_epoch}
# The slot duration, in seconds, is the time between the creation
# of 2 blocks
#
# default value is {default_slot_duration}
slot_duration: {default_slot_duration}
# A list of Ed25519 PublicKey that represents the
# BFT leaders encoded as bech32. The order in the list matters.
consensus_leader_ids:
– {leader_1}
– {leader_2}
# Genesis praos parameter D
#
# default value: {default_bft_slots_ratio}
bft_slots_ratio: {default_bft_slots_ratio}
# Genesis praos active slot coefficient
# Determines minimum stake required to try becoming slot leader, must be in range (0,1]
#
# default value: {default_consensus_genesis_praos_active_slot_coeff}
consensus_genesis_praos_active_slot_coeff: {default_consensus_genesis_praos_active_slot_coeff}
# The fee calculations settings
#
# total fees: constant + (num_inputs + num_outputs) * coefficient [+ certificate]
linear_fees:
# this is the minimum value to pay for every transaction
constant: 2
# the additional fee to pay for every inputs and outputs
coefficient: 1
# the additional fee to pay if the transaction embeds a certificate
certificate: 4
# The speed to update the KES Key in seconds
#
# default value: {default_kes_update_speed}
kes_update_speed: {default_kes_update_speed}
# Initial state of the ledger. Each item is applied in order of this list
initial:
# Initial deposits present in the blockchain
– fund:
# UTxO addresses or account
– address: {initial_funds_address}
value: 10000
# Initial certificate
– cert: cert1qgqqqqqqqqqqqqqqqqqqq0p5avfqqmgurpe7s9k7933q0wj420jl5xqvx8lywcu5jcr7fwqa9qmdn93q4nm7c4fsay3mzeqgq3c0slnut9kns08yn2qn80famup7nvgtfuyszqzqrd4lxlt5ylplfu76p8f6ks0ggprzatp2c8rn6ev3hn9dgr38tzful4h0udlwa0536vyrrug7af9ujmrr869afs0yw9gj5x7z24l8sps3zzcmv
# Initial deposits present in the blockchain
#- legacy_fund:
# # Legacy Cardano address
# – address: 48mDfYyQn21iyEPzCfkATEHTwZBcZJqXhRJezmswfvc6Ne89u1axXsiazmgd7SwT8VbafbVnCvyXhBSMhSkPiCezMkqHC4dmxRahRC86SknFu6JF6hwSg8
# value: 123
제네시스 파일에는 여러 부분이 있다:
-
blockchain_configuration: 이것은 블록체인의 구성 매개 변수 목록이다.이 중 일부는 나중에 update protocol를 통해 변경할 수 있다;
-
initial: 원장 초기 상태를 만드는 단계 목록
|
옵션(option) |
형식(format) |
설명(description) |
|
block0_date |
number |
UNIX EPOCH 이후 초 단위로 블록체인의 공식 시작 시간 |
|
discrimination |
string |
production 또는 test |
|
block0_consensus |
string |
bft |
|
slot_duration |
number |
2 블록의 생성 사이의 초 수 |
|
epoch_stability_depth |
number |
포크의 허용된 크기 (블록 수) |
|
consensus_leader_ids |
array |
블록체인의 시작 부분에있는 BFT 리더 목록 |
|
max_number_of_transactions_per_block |
number |
블록에서 허용되는 최대 트랜잭션 수 |
|
bft_slots_ratio |
number |
위치 표시자, 사용하지 않음 |
|
linear_fees |
object |
선형 요금 설정, 거래 및 인증서 게시 수수료 설정 |
|
consensus_genesis_praos_active_slot_coeff |
number |
초기 praos 활성 슬롯 계수. 슬롯 리더가 되기 위해 필요한 최소 스테이크를 결정한다. 범위 내에 있어야한다 (0,1) |
|
kes_update_speed |
number |
KES 키를 초 단위로 업데이트하는 속도 |
|
slots_per_epoch |
number |
각 에포크의 슬롯 수 |
기원 파일의 BFT 리더에 대한 자세한 내용은 BFT 블록체인 시작을 참조한다.
Each entry can be one of 3 variants:
|
변수(variant) |
형식(format) |
설명(description) |
|
fund |
sequence |
블록체인에 존재하는 초기 입금 (입금당 최대 255개의 산출물) |
|
cert |
string |
초기 인증 |
|
legacy_fund |
sequence |
fund와 동일하나, 레거시 카르다노 주소 형식 |
예:
initial:
– fund:
– address:
value: 10000
– address:
value: 20000
– address:
value: 30000
– cert:
– legacy_fund:
– address:
value: 123
– fund:
– address:
value: 1001
|
변수(variant) |
형식(format) |
설명(description) |
|
address |
string |
single address(단일 주소) 또는r an account address(계정 주소)가 될 수 있음 |
|
value |
number |
위임된 가치 |
legacy_fund 레거시 카르다노는 주소 형식만 다름
6.2.starting a bft node(bft노드 개시)
BFT는 비잔틴 장애 허용 (Byzantine Fault Tolerant)의 약자이다(논문을 참조).
Jormungandr을 사용하면 BFT 블록체인을 비교적 쉽게 시작할 수 있다. 주된 단점은 그것이 중앙 집중화되어 있다는 것이다. 소수의 노드만이 항상 블록을 만들 권리를 갖게 될 것이다.
그것은 매우 간단하다. 주어진 수의 노드 (N)는 Ed25519 유형의 키 쌍을 생성합니다 (JCLI의 키 참조).
그들은 모두 공개 키를 공유하고 genesis.yaml 파일에 추가한다. 이것은 진정성의 근원이며 첫 번째 블록인 블록 0을 생성할 파일이다.
그런 다음 하나씩 차례대로 각 노드가 블록을 만들 수 있다. 라운드 로빈 알고리즘을 활용한 것이다.
Example of genesis file(제네시스 파일 예)
blockchain_configuration:
block0_date: 1550822014
discrimination: test
block0_consensus: bft
slots_per_epoch: 5
slot_duration: 15
epoch_stability_depth: 10
consensus_leader_ids:
– ed25519e_pk1k3wjgdcdcn23k6dwr0cyh88ad7a4ayenyxaherfazwy363pyy8wqppn7j3
– ed25519e_pk13talprd9grgaqzs42mkm0x2xek5wf9mdf0eefdy8a6dk5grka2gstrp3en
bft_slots_ratio: 0.220
consensus_genesis_praos_active_slot_coeff: 0.22
max_number_of_transactions_per_block: 255
linear_fees:
constant: 2
coefficient: 1
certificate: 4
kes_update_speed: 43200
initial:
– fund:
– address: ta1svy0mwwm7mdwcuj308aapjw6ra4c3e6cygd0f333nvtjzxg8ahdvxlswdf0
value: 10000
– cert: cert1qgqqqqqqqqqqqqqqqqqqq0p5avfqqmgurpe7s9k7933q0wj420jl5xqvx8lywcu5jcr7fwqa9qmdn93q4nm7c4fsay3mzeqgq3c0slnut9kns08yn2qn80famup7nvgtfuyszqzqrd4lxlt5ylplfu76p8f6ks0ggprzatp2c8rn6ev3hn9dgr38tzful4h0udlwa0536vyrrug7af9ujmrr869afs0yw9gj5x7z24l8sps3zzcmv
– legacy_fund:
– address: 48mDfYyQn21iyEPzCfkATEHTwZBcZJqXhRJezmswfvc6Ne89u1axXsiazmgd7SwT8VbafbVnCvyXhBSMhSkPiCezMkqHC4dmxRahRC86SknFu6JF6hwSg8
value: 123
BFT 모드에서 블록체인을 시작하려면 다음 사항을 확인해야 한다.
-
consensus_leader_ids 가 비어 있지 않다;
제네시스 파일에 관한 상세한 정보는 여기
jcli genesis encode –input genesis.yaml –output block-0.bin
이 명령은 주어진 초기구성 파일에서 블록체인의 블록 0을 생성 (또는 대체)한다 (genesis.yaml).
이제 블록체인이 초기화되었으므로 노드를 시작해야 한다.
개인 키를 HD 파일에 작성한다.
$ cat node_secret.yaml
bft:
signing_key: ed25519_sk1hpvne…
노드 (config.yml)를 구성하고 다음 명령을 실행한다 :
$ jormungandr –genesis-block block-0.bin \
–config example.config \
–secret node_secret.yaml
플래그 –secret을 여러 번 사용하여 여러 리더가 있는 노드를 실행할 수 있다.
Step by step to start the BFT node(BFT 노드 개시를 위한 절차)
-
1.initial config 생성 jcli genesis init > genesis.yaml
2.비밀 키 생성, 예. jcli key generate –type=Ed25519 > key.prv
3.파일 안에 공개 키 입력, 예. node_secret.yaml 에 다음과 같이 입력:
bft:
signing_key: ed25519_sk1kppercsk06k03yk4qgea….
4.이전에 생성된 키에서 공개 키 생성 cat key.prv | jcli key to-public
5.consensus_leader_ids:안에 있는 genesis.yaml에 생성된 공개 키 입력
6.블록 생성= jcli genesis encode –input genesis.yaml –output block-0.bin
7.config 파일 생성 및 node.config로 HD에 저장하기 예 ->
—
logger:
verbosity: 4
format: json
rest:
listen: “127.0.0.1:8607”
peer_2_peer:
public_address: /ip4/127.0.0.1/tcp/8606
topics_of_interests:
messages: low
blocks: normal
8.Jörmungandr 노드 개시 :
jormungandr –genesis-block block-0.bin –config node.config –secret node_secret.yaml
또한 bft 합의 프로토콜을 사용하여 테스트 노드를 부트스트랩하는 데 사용할 수 있는 스크립트가 여기에 있다.
6.3.starting a genesis blockchain(초기 블록체인 설정)
제네시스 프라오스 블록체인을 시작할 때 블록0을 구성하는 동안 고려해야 할 요소가 있다 : 스테이크 분배.
제네시스 / 프라오스의 맥락에서 네트워크는 완전히 분산되어 있으며, 초기 스테이크 풀에 대해 미리 생각하고 이 스테이크 풀에 스테이크가 위임되도록 해야 한다.
genesis yaml 파일에서 다음 값을 적절한 값 / 원하는 값으로 설정해야 한다.
# The Blockchain Configuration defines the settings of the blockchain.(블록체인 구성은 블록체인의 설정을 정의한다.)
blockchain_configuration:
block0_consensus: genesis
bft_slots_ratio: 0
consensus_genesis_praos_active_slot_coeff: 0.1
kes_update_speed: 43200 # 12hours
genesis로 설정된 block0_consensus는 합의 레이어상의 제네시스 프라오스를 가진 블록체인을 시작하고자 함을 의미한다.
bft_slots_ratio를 0으로 설정해야 한다 (아직 BFT 모드와 Genesis 모드 간의 합성 모드는 지원하지 않는다).
consensus_genesis_praos_active_slot_coeff는 슬롯 리더가 되려고하는 데 필요한 최소 스테이크를 결정하며 0 배타적이고 1을 포함하는 범위에 있어야 한다.
The initial certificates(초기 인증서 설정)
initial_certs 필드에 초기 인증서를 설정한다. 스테이크 풀을 선언하고 그들에게 스테이크를 위임하는 것은 중요하다. 그렇지 않으면 블록이 생성되지 않는다.
이 배열에서 순서가 중요하다는 것을 기억한다.
스테이크를 위임하려면 이미 스테이크 풀이 있어야 하므로 스테이크 풀 등록 인증서가 먼저 선행되어야 한다.
The stake key declaration(스테이크 키 생성)
스테이크 키를 생성하려면 단순히 스테이크 풀 가이드 등록 지침을 따른다.
Stake pool registration(스테이클 풀 등록)
이제 스테이크 풀을 등록할 수 있다. 스테이크 풀 가이드 등록 지침을 따른다.
소유자 키 (스테이크 풀 등록 인증서에 서명하는 키)는 이전에 등록된 스테이크 키와 연관된 비밀 키이다.
이제 스테이크 키가 있고 block0에 이용가능한 스테이크 풀이 있기 때문에 스테이크 풀 중 하나에 위임해야 한다. 스테이크 위임의 지시를 따른다.
그리고 초기 자금에서 주소를 추가하기 시작한다. 위임이 있는 주소를 만들려면 JCLI의 주소록에 있는 지침을 따른다. 이전에 그룹 주소로 등록된 스테이크 키를 활용한다:
jcli address single $(cat wallet_key.pub) $(cat stake_key.pub)
ta1sjx4j3jwel94g0cgwzq9au7h6m8f5q3qnyh0gfnryl3xan6qnmjse3k2uv062mzj34eacjnxthxqv8fvdcn6f4xhxwa7ms729ak3gsl4qrq2mm
위임이 있는 주소는 위임이 없는 주소보다 길다 (약 두 배 이상)는 것을 알 수 있다.
예를 들어, 가장 최소한의 설정은 다음과 같다.
initial_certs:
# register a stake pool (P), owner of the stake pool is the stake key (K)(스테이크 풀 (P)을 등록하고 스테이크 풀의 소유자는 스테이크 키 (K)이다.)
– cert1qsqqqqqqqqqqqqqqqqqqq0p5avfqp9tzusr26chayeddkkmdlap6tl23ceca8unsghc22tap8clhrzslkehdycufa4ywvqvs4u36zctw4ydtg7xagprfgz0vuujh3lgtxgfszqzqj4xk4sxxyg392p5nqz8s7ev5wna7eqz7ycsuas05mrupmdsfk0fqqudanew6c0nckf5tsp0lgnk8e8j0dpnxvjk2usn52vs8umr3qrccegxaz
# delegate stake associated to stake key (K) to stake pool (P)
(스테이크 키 (K)와 관련된 스테이크를 스테이크 풀 (P)에 위임)
– cert1q0rv4ccl54k99rtnm39xvhwvqcwjcm385n2dwvamahpu5tmdz3plt65rpewev3a03xj7nfx5pz0xap2cjxjnxvt2ma9y9dalzder3xm5qyqyq0lx05ggrws0ghuffqrg7scqzdsd665v4m7087eam5zvw4f26v2tsea3ujrxly243sgqkn42uttk5juvq78ajvfx9ttcmj05lfuwtq9qhdxzr0
initial_funds:
# address without delegation(위임되지 않은 주소)
– address: ta1swx4j3jwel94g0cgwzq9au7h6m8f5q3qnyh0gfnryl3xan6qnmjsczt057x
value: 10000
# address delegating to stake key (K)(스테이크 키에 위임하는 주소 (K))
– address: ta1sjx4j3jwel94g0cgwzq9au7h6m8f5q3qnyh0gfnryl3xan6qnmjse3k2uv062mzj34eacjnxthxqv8fvdcn6f4xhxwa7ms729ak3gsl4qrq2mm
value: 1000000
이제 노드를 시작하고 새 블록을 생성할 수 있도록 풀의 개인 키와 ID를 파일에 넣고 –secret filename매개 변수로 노드를 시작해야 한다.
예를 들어 스테이크 풀 등록 가이드의 예를 따르는 경우
다음 내용으로 poolsecret.yaml이라는 파일을 만들 수 있다.
genesis:
sig_key: Content of stake_pool_kes.prv file
vrf_key: Content of stake_pool_vrf.prv file
node_id: Content of stake_pool.id file
그리고이 명령으로 노드를 시작할 수 있다.
jormungandr –genesis-block block-0.bin –config config.yaml –secret poolsecret.yaml
미리 설정된 지갑과 스테이크 풀을 사용하여 테스트 노드를 부트스트랩하는 데 사용할 수 있는 스크립트가 여기에 있으며 예제로 사용할 수 있다.