[TezosXSkkrypto] 테조스 실습노트 #2
테조스 지갑 사용하기
설치가 끝났다면 알파넷에 직접 참여해 네트워크를 이용하는 법에 대해 알아보겠습니다.
테조스 소프트웨어를 설치하신 폴더에서 ls 명령어를 입력하면, 8개의 실행파일(프로그램)을 확인해 보실 수 있습니다. 이 중 tezos-protocol-compiler와 tezos-signer를 제외한 나머지 6개 프로그램에 대해서 간략하게 살펴 보겠습니다.
tezos-accuser-003-PsddFKi3 는 모든 체인에서 오는 모든 블록들을 감시하는 데몬이며 같은 레벨에서 두 블록에 서명한 베이커, 같은 베이킹 슬롯에 대해 두 개 이상의 승인 작업을 수행한 인도서를 찾아냅니다.
tezos-client 는 이름에서 알 수 있듯이 사용자가 노드와 통신할 때 사용되는 라이브러리입니다. 노드는 클라이언트가 통신할 수 있도록 API end points를 노출시키고 RPC를 통해 통신합니다. 노드와의 서로 다른 통신 유형은 노드 쿼리를 통해 블록 또는 트랜잭션 정보와 잔액 정보를 얻고, 컨트랙트를 배포하고 상호작용하는 작업을 포함합니다.
tezos-admin-client 는 더 많은 커맨드를 사용할 수 있는 또 다른 client입니다. Admin client는 P2P 레이어와 상호작용함으로써 연결 상태를 확인하고, 알려진 피어와 강제로 연결이 가능하며, 피어를 제한하거나 풀 수 있는 권한을 가집니다.
tezos-baker-003-PsddFKi3 는 account에 연결되면, 그 account에 대한 베이킹 권한을 계산하고, mempool로부터 트랜잭션들을 수집하여 블록을 베이킹하는 데몬입니다. 베이커는 실행을 목적으로 노드 데이터 디렉터리에 직접 접근하는 유일한 프로그램입니다.
tezos-endorser-003-PsddFKi3 는 어카운트에 연결되면 그 어카운트에 대한 인도싱 권한을 확인하고 새 블록의 유효성을 검증하여 승인작업을 실시하는 데몬입니다. 특정 어카운트를 승인할 수 있고, 특정 어카운트 생략 시에는 모든 어카운트에 대해 승인하게 됩니다.
tezos-node 는 테조스의 핵심입니다. 노드는 다른 피어들과 연결되며 블록들을 보내거나 수신하고 상태를 업데이트하는 데몬입니다. 테조스의 블록체인 네트워크와 상호작용하기 위해서는 노드가 네트워크의 다른 피어와 완전히 동기화되어야 합니다. 즉, 모든 블록을 다운로드해야합니다.
테조스 네트워크
현재 작동 중인 테조스 네트워크는 제로넷, 알파넷, 메인넷 3 종류가 있습니다.
메인넷은 사람들이 실제로 거래하기 위해 사용하는 실시간 네트워크입니다. 메인넷에서는 실제 테조스 코인이 사용됩니다.
알파넷은 테스트 네트워크, 즉 테스트를 위한 목적으로만 사용되는 네트워크입니다. 메인넷과 거의 유사하지만, 메인넷에 적용되기 직전의 프로토콜이 포함되어 있습니다.
제로넷은 테조스 네트워크의 축소판 테스트 네트워크입니다. 블록 생성 주기도 메인넷, 알파넷에 비해 훨씬 짧아, 보다 빠른 테스트에 적합합니다. 가장 실험적인 프로토콜들이 테스트되는 네트워크로, 테조스 개발의 최전선에 있는 코어 개발자들이 주로 사용합니다.
https://tzscan.io/ 에서 각 네트워크의 최신 블록, 트랜잭션 등의 정보를 얻을 수 있습니다.
네트워크 사용 전에 몇 가지 바이너리와 매뉴얼을 보여주는 명령어가 있습니다. 제로넷, 베타넷과는 달리 알파넷은 최신 명령어만 사용 가능합니다.
tezos-node: 테조스 노드에 대한 설명을 보여줍니다.
tezos-client man –v 3: tezos-client man으로 매뉴얼을 볼 수 있고, -v 3으로 버전 3의 매뉴얼을 볼 수 있습니다.
tezos-client man <keyword>: keyword와 관련된 매뉴얼을 볼 수 있습니다.
이 매뉴얼들은 온라인 설명서에서도 볼 수 있습니다. (https://tezos.gitlab.io/master/api/cli-commands.html#client-manual)
테조스 노드
노드(tezos-node)는 P2P(peer to peer) 시스템 내의 한 구성원인 peer입니다. 즉, 다른 peer들과 서로 메세지를 주고 받으며 분산 네트워크가 작동하는 데 기여합니다. 노드는 가십 네트워크(gossip network)를 운영하는 것과 context 파일을 업데이트하는 두 가지 주요 기능을 가지고 있습니다. 가십 네트워크는 모든 테조스 노드가 블록 및 오퍼레이션들을 교환하는 곳입니다. 가십 네트워크를 통해 모든 노드들이 같은 context, 같은 head(최신 블록)를 공유하게 됩니다. Context는 분산 공개 장부 시스템의 목적인 ‘동일한 장부’를 의미합니다. 많은 블록체인 프로젝트에서 (global) state라고 부르는 것과 동일한 개념입니다.
노드를 네트워크에 연결하기 위해서는 새로운 ID를 만들어야 합니다. ID는 노드가 메시지를 암호화하는 데 사용하는 암호화 키 한 쌍과 컴퓨팅 능력을 증명하는 Antispam-PoW 스탬프*로 구성됩니다. 유의해야 할 점은 ID는 블록체인의 테조스 주소와 아무런 관련이 없다는 것입니다.
* 스팸 메세지(대량 메세지) 생성을 방지하기 위한 작업 증명. 약간의 컴퓨팅 자원을 사용해야만 가능한 작업을 요구함으로써, 해당 작업을 하면 작업을 한 것으로 간주합니다.
그 후 RPC interface를 활성화 시켜 클라이언트가 노드와 통신할 수 있게 해줍니다.
이제 생성한 노드를 네트워크와 동기화 해야 합니다. 새로운 탭을 생성해서 다음 명령어를 입력합니다. 새로운 탭을 생성하면 다음 두 가지 명령어를 다시 입력해주면 편하게 작업이 가능합니다.
timestamp가 현재 날짜와 맞고 Bootstrapped라는 단어가 보이면 동기화가 완료된 것입니다. 시간은 UTC시간이기 때문에 다를 수 있습니다. 만약 timestamp가 다른데 Bootstrapped가 뜬다면 RPC 인터페이스를 활성화 시킨 탭에서 ctrl + c로 빠져나온 후 다시 tezos-node run --rpc-addr 127.0.0.1 명령어를 입력한 후 다시 동기화를 시작합니다. 그래도 되지 않는다면 tezos-node config init과 tezos-node config update --peer=<point>로 업데이트 해준 후 다시 RPC 인터페이스를 활성화 시킵니다. <point>는 https://alphanet.tzscan.io/network?state=running에서 현재 사용가능한 Peer의 Point중 하나를 가져오면 됩니다.
peer중에 하나의 address를 사용해보겠습니다.
짧게는 몇 분, 길게는 몇 시간동안 위와 같은 문장이 반복되며 동기화가 진행되지 않을 수도 있습니다. 그러므로 인내심을 가지고 동기화가 되기를 기다리시면 됩니다.
tezos-client get timestamp 명령어로 현재의 timestamp를 볼 수 있습니다.
이제 ID생성이 완료되었습니다. 하지만 동기화가 끝나야 트랜잭션을 체인에 담을 수 있기 때문에 동기화가 완료되지 않으면 아무것도 할 수 없습니다.
테조스 지갑 사용하기
클라이언트(tezos-client)는 기본 지갑이며 RPC interface 활성화 후 .tezos-client 디렉토리가 contracts, public_key_hashs, public_keys, public_keys 및 secret_keys json파일로 채워집니다.
동기화가 완료되었다면 이제 tezos-client gen keys <name>으로 새 키 쌍을 생성할 수 있습니다. bob의 지갑을 만들고, tezos-client get balance for bob으로 bob 계좌의 잔액을 확인해 보겠습니다.
이제 alice의 계좌에 돈을 넣어보겠습니다.
먼저 https://faucet.tzalpha.net/에서 tz1__xxxxxxxxxxxxxxxx__.json 파일을 다운로드합니다.
다운받은 파일을 tezos 디렉토리에 넣어줍니다.
그 후에 tezos-client activate account <account name> with “<file name>”을 실행하면 이름이 account name인 계좌가 생성되고 그 안에 코인이 들어가게 됩니다. alice 계좌에 코인을 넣어보겠습니다.
이제 alice 계좌의 잔고를 확인해보면 bob과 달리 코인이 들어있는 것을 볼 수 있습니다.
계좌를 생성할 때 뒤에 --force 명령어를 붙여주면 같은 이름을 가지는 계좌가 있어도 그 위에 새로운 계좌를 덮어 씌우게 됩니다.
트랜잭션
트랜잭션은 몇 가지 특징을 가지고 있습니다.
1. counter, gas limit, storage limit이라는 3가지 인자들을 가지고 있습니다.
2. 모든 오퍼레이션은 고유한 오퍼레이션으로 취급합니다. 값이 모두 같아도 counter값이 달라집니다.
3. 모든 오퍼레이션은 한 번만 실행됩니다.
4. 오퍼레이션은 순서대로 적용됩니다. n번째와 n+1번째 오퍼레이션을 실행하고 n번째 오퍼레이션이 사라진다면, n+1번째 오퍼레이션도 적용되지 않습니다.
5. 오퍼레이션은 gas limit과 storage limit을 설정해야 합니다. 이 한도를 넘으면 오퍼레이션은 실행되지 않습니다. 하지만 위에서는 트랜잭션을 실행할 때 gas limit과 storage limit을 설정해주지 않았는데, 그 이유는 밑에서 설명하겠습니다.
6. 오퍼레이션이 실행된 즉시 돈을 사용할 수 없습니다. 오퍼레이션이 확실히 체인에 포함되었다는 확신이 생겨야(60 block) 사용할 수 있습니다. deposits, fees, rewards라는 동결계좌에 들어있다가, 몇 사이클이 지난 후 사용가능하게 됩니다.
이제 alice계좌에서 bob의 계좌로 코인을 보내보겠습니다.
tezos-client transfer <amount> <account A> from <account B>는 B에게 <amount>만큼의 코인을 전송하는 트랜잭션입니다. 트랜잭션이 체인에 포함되면, 영수증이 출력됩니다. 영수증에는 operation hash, counter, gas limit, storage limit 등 다양한 정보가 담겨있습니다.
이제 bob 계좌에는 1 xtz가 포함되고, alice계좌에서는 1 xtz, 베이커에게 수수료 0.001275 xtz가 빠져나갔습니다.
여기서 발생한 Fatal error는 이 트랜잭션이 기본 burn cap인 0 xtz보다 많은 0.257xtz를 소모한다고 알려줍니다. 만약 이 에러가 발생한다면 뒤에 --burn-cap 0.257을 붙이면 정상적으로 실행됩니다. burn-cap은 네트워크의 저장소 사용과 관련있는 내용으로, 뒤에서 자세히 다루겠습니다.
트랜잭션을 블록에 포함시키기 위해 블록이 생성되기 까지 기다리면 트랜잭션이 실행됩니다. 실행되면 트랜잭션의 모든 세부 정보가 포함된 영수증을 보여줍니다. 트랜잭션이 체인에 포함되었다는 것을 확신하기 위해서 테조스에서는 60블록을 기다리는 것을 권장합니다. 매우 중요한 거래라면 tezos-client wait for <operation hash> to be included 명령어를 실행한 후 기다리면 트랜잭션이 체인에 포함됐다는 것이 확실해지면 커맨드 창이 활성화됩니다. operation hash 값은 영수증 안에 포함되어 있습니다.
이번에는 fee를 직접 설정해서 트랜잭션을 실행시켜보겠습니다.
아까와 달리 Fee to the baker가 직접 설정한 0.5 xtz가 되어있는 것을 알 수 있습니다. bob계좌에 1 xtz가 포함되고, alice 계좌에서는 1.5 xtz가 빠져나갔습니다.
Fee를 기본 fee 0.001273 xtz보다 작게 설정하면 에러가 발생합니다.
트랜잭션에 관한 더 많은 명령어에 대한 설명은 tezos-client man transfer를 터미널에 입력하면 볼 수 있습니다.
만약 거래가 체인에 포함되지 않는다면, 블록이 체인에 포함되지 않았다는 것을 확신하는 방법은 60개의 블록이 생성되기를 기다리는 것입니다. 그 후에는 그 거래는 유효하지 않은 것으로 간주되고 더 이상 블록에 포함될 수 없습니다. 또 거래가 자동적으로 재실행되는 것을 방지하는 장치가 있기 때문에, 거래를 다시 실행하면 됩니다.
트랜잭션이 유효한지 검증하기
노드는 operation을 네트워크에 제출하기 전에 현재 context에서 시뮬레이션해서 operation이 유효한지 검증합니다. 만약 이 작업을 거치지 않는다면 유효하지 않은 operation, 예를 들어 가진 것보다 더 많은 것을 전송하는 operation같은 것은 실행되지 않을 것이 확실한데 거기에 대한 불필요한 fee를 지불해야 하므로 이런 것을 피하기 위해 클라이언트는 먼저 노드에게 거래의 유효성을 확인하도록 요청하고 나서 이를 전송합니다.
검증이 필요한 다른 이유는 gas limit와 storage limit을 자동으로 결정해주기 때문입니다. 노드는 우선 미켈슨 프로그램을 시뮬레이션하고 사용하는 gas와 storage의 양을 계산합니다. 그런 다음 클라이언트는 계산된 합리적인 gas limit와 storage limit를 가지고 거래를 송신합니다. 이런 이유로 우리는 지금까지 gas limit와 storage limit에 대한 명시없이 거래를 실행할 수 있었던 것입니다.
지금까지 알파넷에서 계좌를 생성하고 거래를 실행하는 법과 영수증에 대해서 알아보았습니다. 다음편에서는 노드가 어떻게 베이킹에 참여하는지에 대해서 알아보겠습니다.
작성자 : 김승태
개발팀 : 김승태, 김예서, 김형준
