기록하는 공간

[블록체인] Ethereum 채굴과 송금

cbw1030 — Wed, 2 Feb 2022 22:00:16 +0900

채굴

이더리움에서 채굴보상은 coinbase 계정으로 들어가게 되며 coinbase 계정을 따로 지정해주지 않을 시 0번째 계정이 coinbase 계정으로 지정됩니다.

miner.start(스레드의 수)를 명령어로 두고 실행을 하게 되면 채굴을 하게 됩니다.

miner.stop()은 채굴을 멈춥니다.

miner.start(1)로 하여 하나의 스레드로 채굴을 해보겠습니다.

우선 geth console을 실행합니다.

geth --rpc --rpcport "8485" --rpccorsdomain "*" --datadir . --port "30303" --nodiscover --maxpeers 0 --rpcapi "eth,net,web3" --networkid 8585 --nousb console 2>> ~/eth/geth.log

이더리움의 miner.start()는 비트코인의 generate와 달리 genesis.json에서 설정한 값과 해당되는 난이도로 채굴을 진행합니다.

처음에 miner.start()를 하고 다른 리눅스에서 /home/ethereum/eth/geth.log 파일 로그를 확인해보면 아래와 같이 로그가 찍히고 있습니다.

해당 로그에서 percentage=100까지 채워져야 채굴이 가능합니다.

percentage=100까지 채워졌다면 miner.stop()을 한 다음 다시 miner.start()를 진행하고 로그를 확인하면 아래처럼 채굴을 진행합니다.

로그를 보니 7번 블록까지 채굴되었습니다. geth console에서 명령어를 통해 확인해보겠습니다.

정확하게 나오네요

송금

송금을 하기 위해서는 트랜잭션에 서명을 해야 합니다.

트랜잭션에 서명을 하기 위해서는 비밀키가 필요하고 미리 생성해둔 keystore 파일로부터 비밀키를 알아내기 위해서는 계정생성 당시 설정한 암호를 입력하여 계정의 잠금을 풀어야 합니다.

* geth console에서 personal.newAccount("luna")로 만들었다면 암호는 luna입니다.

따라서 luna 계정의 비밀키로 서명하기 위해 unlock을 해야합니다.

geth console에 접근할 때 아래와 같이 명령어를 사용하면 됩니다.

geth --rpc --rpcport "8485" --rpccorsdomain "*" --datadir . --port "30303" --nodiscover --maxpeers 0 --rpcapi "eth,net,web3" --networkid 8585 --nousb --allow-insecure-unlock --unlock 0,1,2 console 2>> ~/eth/geth.log

현재는 private 네트워크이므로 allow insecure unlock을 옵션으로 부여한 후 unlock 0,1,2를 하여 0번, 1번, 2번 계정을 unlock시켜줍니다.

필자는 0번 계정(luna), 1번 계정(pine), 2번 계정(kim) 이렇게 총 3개를 갖고 있어서 3개를 unlock 시켰습니다.

패스워드는 계정별 패스워드를 입력하면 됩니다.

geth console에 접속했으니 luna, pine, kim 변수에 각 계정을 대입해줍니다.

현재 각 계정별 잔액을 알아봅시다.

kim 계정에서 pine 계정으로 0.5 이더(500000000000000000 wei)만 송금해보겠습니다.

eth.sendTransaction 명령어를 통해 해시된 TX 값을 얻어냈습니다.

miner.start()를 통한 블록을 새로 만들기 전까지는 tx는 pending 상태이므로 eth.pendingTransactions 명령어를 통해 펜딩을 확인할 수 있습니다.

현재 블록 넘버는 26입니다.

이제 miner.start(), miner.stop()으로 블록 1개를 추가해보겠습니다.

블록 1개를 추가했으니 kim 계정에서 pine 계정으로 보낸 tx는 컨펌이 되었는지 확인해보겠습니다.

펜딩 tx가 없습니다

각 계정별 잔액을 확인해보겠습니다.

코인베이스 계정인 luna 계정이 채굴을 했으므로 채굴 보상 + kim의 송금수수료까지 받은 것을 확인할 수 있습니다.

pine 계정은 kim으로부터 0.5 이더를 받은 것을 확인할 수 있으며 kim은 0.5 이더 + 수수료(42000 wei)까지 차감된 것을 확인할 수 있습니다.

참고

https://www.youtube.com/watch?v=mV7YCZeShaU&list=PLZwFtgKc35I_ROUsSev0xcy5poVH486CV&index=14

[블록체인] Ethereum Geth 설치

cbw1030 — Wed, 2 Feb 2022 20:16:13 +0900

이번 포스팅에서는 Ethereum Geth를 설치해보겠습니다.

제가 개발한 환경은 Ubuntu 18.04 LTS, Windows Terminal입니다.

다운로드 방법은 여기를 참고해주세요.

리눅스 계정 생성

리눅스 계정을 먼저 만들어보겠습니다.

sudo adduser ethereum
sudo usermod -aG sudo ethereum
su - ethereum

Geth 설치

Geth의 설치는 간단합니다.

깃허브에서 소스코드를 다운로드 후 go-ethereum 경로에 들어가서 make geth 명령어만 실행해주면 됩니다.

하지만 make 명령어를 사용하여 geth를 컴파일 하기 전에 1.13 버전 이후의 Go, C 컴파일러가 필요합니다.

이 부분이 어렵기 때문에 특정 버전의 ppa를 다운로드 받아서 진행하려고 합니다.

아래 ppa를 사용하여 go의 최신버전을 설치합니다.

sudo add-apt-repository ppa:longsleep/golang-backports
sudo apt update
sudo apt install golang-go
sudo apt-get install -y build-essential

go version 명령어를 통해 버전을 확인하면 정상적으로 설치가 되었음을 알 수 있습니다.

이제깃허브에서 소스코드를 clone합니다. 1.9 버전으로 진행하겠습니다.

git clone -b release/1.9 https://github.com/ethereum/go-ethereum

go-ethereum 경로에 들어가 make geth 명령어를 실행합니다.

해당 명령어가 끝나면 build/bin 경로에 접근하여 ./geth version 명령어를 통해 현재 설치된 geth version이 확인되면 끝입니다.

환경변수 설정

geth 명령어를 어떠한 경로에서도 사용가능하게 하려면 환경변수를 설정하는 과정을 거쳐야 합니다.

우분투에서는 환경변수를 추가할 때 .profile에서 설정을 합니다. 여기서 PATH를 수정하면 됩니다.

/home/ethereum/.profile을 vi 명령어로 실행합니다.

그리고 가장 아래에 사진처럼 작성하고 :wq를 눌러 저장합니다.

그리고 source .profile 명령어를 통해 설정한 값들을 적용시켜줍니다.

만약 geth를 1.9 버전이 아닌 최신버전을 설치하려면 아래 명령어만 실행하면 됩니다.

sudo add-apt-repository -y ppa:ethereum/Ethereum
sudo apt-get update
sudo apt-get install ethereum
geth version

참고

https://www.youtube.com/watch?v=S0AlQknWRKA&list=PLZwFtgKc35I_ROUsSev0xcy5poVH486CV&index=9

[블록체인] Bitcoin 트랜잭션 전송과 확인

cbw1030 — Wed, 2 Feb 2022 19:11:30 +0900

이번 포스팅은 이전 글에 이어 비트코인 송금을 통해 트랜잭션을 일으키고 확인해보겠습니다.

luna 노드의 address에서 pine 노드의 address에 25 비트코인을 송금해보도록 하자.

비트코인 송금을 위해서는 luna 노드는 address를 만들고 채굴을 통해 비트코인을 채워야 한다.

pine 노드도 비트코인을 송금받기 위한 address가 필요하므로 luna, pine 모두 address를 하나씩 만들어보자.

# luna 노드의 address 생성
bitcoin@DESKTOP-82KRV15:~/bitcoin/node3$ bitcoin-cli -rpcuser=luna -rpcpassword=luna -rpcport=1111 getnewaddress

# 생성된 luna 노드의 address
bcrt1qettlkccy5yxe6pnnchdncjr7ng5ypm38f9j3l9

# pine 노드의 address 생성
bitcoin@DESKTOP-82KRV15:~/bitcoin/node3$ bitcoin-cli -rpcuser=pine -rpcpassword=pine -rpcport=2222 getnewaddress

# 생성된 pine 노드의 address
bcrt1qtl69d5szefry4e7r9hwjxza5wxtsajfyd4yrh2

luna address에서 pine address에 25 비트코인을 송금해보자.

bitcoin-cli -rpcuser=luna -rpcpassword=luna -rpcport=1111 sendtoaddress "bcrt1qtl69d5szefry4e7r9hwjxza5wxtsajfyd4yrh2" 25

위 명령어를 실행하면 해시된 TX ID 값을 얻을 수 있다. (966be9204025c7150edc50b1925e69137c35b01448b4bce83dbb0134f3256df6)

해당 트랜잭션은 mempool에 들어가 있는 상태이다.

위 명령어를 통해 mempool에 있는 tx를 조회할 수 있다.

이제 TX를 컨펌하고 블록에 넣기 위해서는 마이너가 채굴을 한 번 해야 한다.

채굴을 함으로써 블록 하나를 추가했다.

블록 하나를 추가함으로써 luna 노드가 pine 노드에게 25 btc를 송금한 tx가 컨펌이 됐다.

getbalance 명령어를 통해 pine 노드의 address에는 25 btc가 잔고에 남아있는 것을 확인할 수 있다.

3번 노드인 kim 노드에서 getrawtransaction 명령어를 통해 tx hash 값을 넣어 조회해보자.

인코딩되어 출력된 값을 디코딩하면 아래처럼 TX 정보를 조회할 수 있다.

vout에는 value가 24.99997180, 25.00000000 두 개 존재하는 것을 확인할 수 있다.

비트코인은 전자는 luna 노드의 address에 돌려주고(UTXO 특징) 후자는 pine 노드의 address에 전송된 것이다.

참고

https://ww w.youtube.com/watch?v=_5bjloFz7l8&list=PLZwFtgKc35I_ROUsSev0xcy5poVH486CV&index=8

[블록체인] Bitcoin P2P Network 구성하기

cbw1030 — Wed, 2 Feb 2022 18:04:23 +0900

이전 글에 이어 하나의 로컬 컴퓨터에서 3개의 regtest 네트워크를 실행한 이후 각각의 네트워크를 P2P 방식으로 연결해보겠습니다.

노드를 띄우기 위해서는 여러 설정값들이 필요한데 주로 쓰이는 설정값에 대해 먼저 알아보겠습니다.

노드 설정값

풀 인덱스 노드를 위한 설정값

alternotify

스크립트나 명령어를 실행시켜 이메일 등을 통해 긴급 정보를 보내는 명령어이다.

datadir

설정값 없이 bitcoind -regtest를 실행하였을 때 기본적으로 이 위치는 .bitcoin이 된다.

이 경로에 regtest 폴더가 생성되게 되며 각 노드가 모든 블록체인 데이터를 저장하는 공간이 이곳이다.

이번 실습에서는 datadir에 각각 node1, 2, 3의 경로를 담아서 각 노드마다 블록체인 데이터를 저장하는 공간을 개별적으로 만들어 주도록 한다.

txindex

txindex를 1로 두면 모든 거래의 인덱스를 유지하면서 블록체인 네트워크 상의 모든 장부를 온전히 내려받아 사용하게 된다.

port

연결을 위한 포트를 열어준다. 설정을 따로 안할 시 기본 포트 번호는 아래와 같다.

(default: 8333, testnet: 18333, regtest: 18444)

addnode

다른 노드를 추가하는 명령어로 하나 또는 여러 개의 노드를 추가할 수 있다.

3개의 노드를 만들 때는 2, 3 번째 노드부터 addnode 명령어를 사용하여 다른 노드를 추가할 수 있다.

지갑 관련 설정값

disablewallet

지갑 기능을 사용하지 않겠다는 의미이다.

fallbackfee

기본적으로 비트코인 네트워크에서 지불하는 수수료이다. 수수료는 채굴자에게 채굴보상과 함께 지급된다.

원래 테스트넷에서는 0.0002 만큼의 수수료를 지불하게 되어 있었으나 0.20 버전 이후부터는 올라가면서 메인넷과 동일하게 기본값이 0이 되었으며 이 값을 0으로 설정해 둔다면 수수료를 지불하지 못해 송금 실습 시에 에러가 나기 때문에 실습에서는 0.0002로 fallbackfee를 설정해준다.

keypool

keypool의 사이즈를 조정해주는 명령어이다.

keypool은 HD 지갑에서 address를 최대 만들 수 있는 개수이다. address를 하나씩 만들수록 keypool이 1씩 감소한다.

walletbroadcast

지갑 프로그램의 기능중 p2p 네트워크로 전파하는 기능을 하도록 설정해주는 값이다.

기본값이 1로 설정되기 때문에 그대로 두면 된다.

RPC 통신 관련 설정값

rpcuser=<user>

JSON-RPC 연결을 하기 위해 설정하는 유저이름 정보이다.

rpcpassword=<pw>

JSON-RPC 연결을 하기 위해 설정하는 비밀번호이다.

rpcport=<port>

JSON-RPC 연결을 입력한 <port>번호에 따라서 수신하게 된다. 따로 설정하지 않을 시의 포트번호는 아래와 같다.

(default: 8332, testnet: 18332, regtest: 18443)

-chain=<chain>

체인 자리에 main, test, regtest 중 하나를 선택하여 지정해준다.

자원 제한을 위한 설정값

prune

이전의 오래된 블록을 삭제하여 디스크 공간 요구치를 줄이는 옵션이다.

maxconnections

연결을 수락하기 위한 최대의 노드수를 설정하여 대역폭의 소비를 줄일 수 있다. 기본값은 125이다.

maxmempool

입력된 값 만큼 거래 메모리 풀을 제한하여 노드의 메모리 사용량을 줄인다.(메가바이트 단위)

maxreceivebuffer/maxsendbuffer

연결된 메모리 버퍼를 제한한다. 입력된 값을 n으로 두면 n * 1000 bytes 만큼 제한된다.

기본값은 각각 5000/1000이다.

노드를 regtest 네트워크에 띄우기

총 3개의 regtest 네트워크를 하나의 로컬 컴퓨터에서 실행하고자 한다.

regtest 네트워크를 실행하는 명령어는 아래와 같다.

bitcoind -conf=<conf location> -rpcport=<rpc port> -port=<port> -wallet=<wallet name> -daemon

노드를 실행하기 전에 conf 파일을 설정해야 한다.

각각의 conf 파일이 위치하는 경로는 /home/bitcoin/bitcoin/node1, /home/bitcoin/bitcoin/node2, /home/bitcoin/bitcoin/node3 이다.

/home/bitcoin/bitcoin/node1/bitcoin.conf

chain=regtest
rpcuser=luna
rpcpassword=luna
rpcport=1111
txindex=1
port=8881
fallbackfee=0.0002
server=1
datadir=/home/bitcoin/bitcoin/node1

/home/bitcoin/bitcoin/node2/bitcoin.conf

chain=regtest
rpcuser=pine
rpcpassword=pine
rpcport=2222
txindex=1
port=8882
fallbackfee=0.0002
server=1
datadir=/home/bitcoin/bitcoin/node2

/home/bitcoin/bitcoin/node3/bitcoin.conf

chain=regtest
rpcuser=kim
rpcpassword=kim
rpcport=3333
txindex=1
port=8883
fallbackfee=0.0002
server=1
datadir=/home/bitcoin/bitcoin/node3

각각의 conf 파일을 생성했으니 3개의 regtest 네트워크를 백그라운드로 실행해보자.

bitcoind -conf="../bitcoin/node1/bitcoin.conf" -rpcport=1111 -port=8881 -wallet="luna" -daemon
bitcoind -conf="../bitcoin/node2/bitcoin.conf" -rpcport=2222 -port=8882 -wallet="pine" -daemon
bitcoind -conf="../bitcoin/node3/bitcoin.conf" -rpcport=3333 -port=8883 -wallet="kim" -daemon

백그라운드에서 모두 잘 실행되고 있다(pid 1163은 무시해주세요)

첫 번째 네트워크(노드)가 잘 연결되어 있는지 확인해보자.

잘 연결되어 있다. 나머지 pine, kim 노드도 연결되어 있음을 예상할 수 있다.

첫 번째 노드에서 채굴을 해보자.

블록을 하나 생성했으니 getblockcount를 통해 카운트를 확인해보자.

첫 번째 노드에서 블록을 생성했으니 카운트가 1로 출력되는 것이 맞고 나머지 2, 3번째 노드는 아직 블록을 생성하지 않았기 때문에 0으로 출력되는 것이 맞다.

현재는 아래 사진처럼 같이 regtest 네트워크에서 3개의 노드들이 실행되고 있는 상태이다.

pine, kim 노드를 luna 노드에 연결시켜 보자.

연결을 시켰으니 잘 연결되었는지 확인을 해보자.

잘 연결 되었다

port 8881에 둘 다 모두 잘 연결되었다.

블록 카운트를 확인하면 luna 노드의 블록 카운트가 출력이 되는지 확인해보자.

pine, kim은 luna 노드에 연결시키 전에 블록 카운트가 0이었는데 연결을 한 이후에는 카운트가 1인 것을 확인할 수 있다.

각 노드별로 몇 개가 연결되어있는지도 확인할 수 있다.

참고

https://www.youtube.com/watch?v=_5bjloFz7l8&list=PLZwFtgKc35I_ROUsSev0xcy5poVH486CV&index=8

[블록체인] Bitcoin 지갑과 주소

cbw1030 — Wed, 2 Feb 2022 15:17:11 +0900

이번 포스팅은 비트코인 지갑과 주소에 대해 알아보겠습니다.

tree 명령어로 .bitcoin 디렉토리의 구조를 살펴본다.

tree가 설치되어 있지 않다면 sudo apt install tree 명령어로 설치하면 된다.

.bitcoin 디렉토리 구조

/.bitcoin/regtest/wallets/wallet.dat 파일이 털리면 개인키가 털리므로 조심해야 한다.

지갑 정보 조회

bitcoin-cli -regtest getwalletinfo

walletinfo

해당 지갑은 regtest 네트워크를 생성할 때 만들어진 default wallet이다.

walletname이 ""인 부분은 bitcoind를 실행할 때 지갑 목록을 bitcoin.conf나 설정값을 주어서 추가할 수 있다.

hdseedid 부분은 HDseed에 해시(Hash 160)를 적용한 것이다. 이를 통해 hd지갑의 seed를 찾을 수 있다.

지갑 생성

"luna"라는 이름의 지갑을 생성하고자 한다. 이를 위해 아래 명령어를 사용한다.

bitcoin-cli -regtest createwallet "luna"

luna wallet 생성

지갑 정보를 조회해보자.

default wallet, luna wallet을 리스트에서 확인할 수 있다.

현재 지갑이 총 2개인데 이렇게 지갑이 여러 개라는 의미는 HD 시드가 여러 개라는 의미이다.

하나의 HD 시드에는 여러 개의 address를 만들 수 있다. HD 시드만 알면 하위 address의 주소를 모두 찾아낼 수 있다.

이제 지갑별로 잔고를 확인할 수 있다.

여러 지갑이 존재하므로 "-rpcwallet=<filename>"을 추가하여 지갑별로 접근하여 명령어를 내려야 한다.

getnewaddress 명령어를 이용하여 지갑마다 address를 하나씩 만들어준다.

luna 지갑의 bcrt1qdey09y6694m9mlccm65vwdj3rnzyjzadsdmaq2 address를 하나 생성했다.

방금 생성한 address의 정보를 조회해보자.

bitcoin-cli -regtest -rpcwallet="luna" getaddressinfo bcrt1qz4sm0qr39p3ta5yeq603y8wfscuf4az7yaxv8d

참고

https://www.youtube.com/watch?v=wktPUoxiZu0&list=PLZwFtgKc35I_ROUsSev0xcy5poVH486CV&index=5

[블록체인] Bitcoin Core 실행과 Genesis Block

cbw1030 — Wed, 2 Feb 2022 14:14:57 +0900

비트코인 네트워크는 메인넷, 테스트넷, 로컬 테스트넷(regtest)으로 나뉜다.

메인넷은 실제 비트코인을 주고 받는 네트워크이다.

테스트넷은 주로 개발자들이 블록체인 관련 개발을 하고 테스트를 할 때 사용하는 네트워크이다. 비트코인에 가치가 없으며 채굴의 난이도가 낮다는 특징이 있다.

로컬 테스트넷(regtest)은 개인 로컬 컴퓨터에서 노드를 생성하여 여러가지 테스트를 해볼 수 있는 네트워크이다.

이번 포스팅에서는 레그테스트(regtest) 모드를 이용하여 제네시스 블록을 생성하는 과정부터 새로운 참여자가 추가되는 것까지 테스트하고자 한다.

regtest 네트워크 생성

레그테스트 모드를 사용하는 방법은 아래와 같다.

# 먼저 bitcoin 디렉토리로 이동해야 한다.
bitcoind -regtest

위 명령어를 실행하면 진행과정이 출력되는데 중간에 Config file: ~~~.. 부분을 볼 수 있다.

이 부분은 configuration 파일을 따로 지정하지 않았기 때문에 기본적인 설정으로 진행됐다는 의미이다.

regtest 네트워크를 생성하면 default wallet을 하나 만들어준다.

default wallet 생성 부분

bitcoind -regtest 명령어를 사용하면 백그라운드가 아닌 앞단에서 노드를 실행시키는 것이라 다른 동작을 진행할 수가 없다. 아래에서 멈출 것이다.

regtest 네트워크를 정상적으로 실행하지만 백그라운드가 아니라 어떠한 동작을 할 수가 없다.

따라서 백그라운드로 재 시작을 해줘야 한다.

백그라운드로 bitcoind 실행

regtest 네트워크를 생성하면 설정값이 들어있는 ~/.bitcoin 이라는 경로가 생긴다.

여기서 regtest라는 폴더 안에 지갑과 블록체인의 상태정보(chainstate)가 저장된다.

만약 초기화를 하고 싶다면 regtest 디렉토리를 지우고 다시 실행하면 된다.

regtest 디렉토리를 지운다는 것은 분산장부를 지운다는 의미로 하나의 네트워크가 소멸된다고 볼 수 있다.

bitcoin-cli 명령어로 함수 호출하기

regtest 네트워크를 생성했으니 bitcoin-cli 명령어로 사용가능한 함수를 호출한다.

bitcoin-cli -regtest getblockchaininfo

출력된 몇 가지 Key에 대해 설명을 하자면 아래와 같다.

blocks: 서버에서 처리된 블록 수 (첫 번째로 생성한 제네시스 블록이므로 0으로 표시된다)

headers: 확인된 현재 헤더 수

bestblockhash: 현재 최고 블록의 해시 값

difficulty: 채굴 난이도

bitcoin-cli에서는 채굴 명령의 실행이 한 번에 바로 이루어지기 때문에 메인넷처럼 기다리는 대기 시간이 없다.

원하는 block number의 해시값을 가져올 수도 있다.

block hash 값으로 block에 대한 정보를 가져올 수도 있다.

위에 출력된 key들 중에서 confirmations를 확인할 수 있다.

블록체인에서 거래가 확정이 되기 위해서는 confirm이 6개 이상되어야 하는데 confirmations의 값이 해당하는 숫자이다.

현재 출력된 block 정보는 제네시스 블록이므로 confirmations는 1로 나오게 된다.

이후 1개의 블록이 연결될 때마다 confirmations는 1씩 증가하게 된다.

block hash 값으로 block에 대한 정보를 가져 오는 것에서 추가적인 옵션 '2'를 주게 되면 transaction까지 출력하게 된다.

transaction의 key인 coinbase는 채굴자들에게 보상을 주는 트랜잭션을 의미한다.

트랜잭션의 종류는 송금할 때 나오는 트랜잭션과 채굴자들에게 보상을 주는 코인베이스 트랜잭션인 2가지가 존재한다.

제네시스 블록은 코인베이스 트랜잭션일 수 밖에 없다.

코인베이스 트랜잭션의 UTXO는 블록체인 분기(fork)가 일어나게 되면 버려지는 블록이 있을 수 있기 때문에 보상을 받은 뒤 100 블록이 경과하지 않으면 이용할 수가 없다.

또한 제네시스 블록의 채굴 보상은 수신자가 없으므로 제네시스 블록의 다음 순서인 1번 블록의 보상이 들어오는 101번째 블록부터 잔고를 확인할 수가 있다.

참고

해당 포스팅은 위데이터랩 조현기 팀장의 강의를 정리한 내용입니다.

https://www.youtube.com/watch?v=Sh8v9jm9cK0&list=PLZwFtgKc35I_ROUsSev0xcy5poVH486CV&index=4

[블록체인] Bitcoin Core 설치

cbw1030 — Wed, 2 Feb 2022 12:35:09 +0900

Microsoft store에서 아래 파일 2개 설치

1. Ubuntu 18.04 LTS

2. Windows Terminal

Windows Terminal에서 우분투 실행하여 아래 명령어 수행하여 계정 생성

1. sudo adduser [계정명]

2. sudo usermod -aG sudo [계정명]

-> 새로 만든 계정에 관리자 권한을 부여한다.

3. su - [계정명]

-> 새로 만든 계정으로 로그인

bitcoin core 설치 전 기본적인 셋팅 진행

1. sudo apt-get update

2. sudo apt-get install build-essential libtool autotools-dev automake pkg-config bsdmainutils python3

3. sudo apt-get install libevent-dev libboost-system-dev libboostfilesystem-dev libboost-test-dev libboost-thread-dev
   만약 E: Unable to locate package libboostfilesystem-dev 에러가 발생한다면 아래 명령어 실행
   sudo apt-get install libevent-dev libboost-dev libboost-system-dev libboost-filesystem-dev libboost-test-dev

bitcoin core 설치 진행

1. sudo add-apt-repository ppa:bitcoin/bitcoin (지갑을 사용하기 위해서는 ppa가 필요함)

2. sudo apt-get update

3. sudo apt-get install libdb4.8-dev libdb4.8++-dev

4. apt-cache search libdb4.8 (libdb4.8이 잘 설치되어있는지 확인하는 절차)

5. sudo apt-get install libminiupnpc-dev (Depency 중 방화벽을 뛰어넘게 도와주는 라이브러리 miniupnpc)

6. sudo apt-get install libzmq3-dev

bitcoin 깃허브에서 자료를 개인 컴퓨터로 받는다.

git clone -b v0.20.0 https://github.com/bitcoin/bitcoin.git

GitHub - bitcoin/bitcoin: Bitcoin Core integration/staging tree

Bitcoin Core integration/staging tree. Contribute to bitcoin/bitcoin development by creating an account on GitHub.

github.com

bitcoin network를 만들기 위한 명령어는 다음 4줄이다.

./autogen.sh

./configure

make

make install

https://www.youtube.com/watch?v=LU0WSOeZ0sQ&amp;amp;amp;amp;amp;list=PLZwFtgKc35I_ROUsSev0xcy5poVH486CV&amp;amp;amp;amp;amp;index=3

만약 ./autogen.sh, ./configure까지는 잘 되었는데 make에서 recipe for target 'bitcoind' failed 에러가 발생한다면 아래 사이트 참조한다.

https://stackoverflow.com/questions/52871871/bitcoin-compile-undefined-reference-to-blockassemblerblockassemblercchainp

bitcoin compile (.undefined reference to `BlockAssembler::BlockAssembler(CChainParams const&)')

I'm getting error after make command like, undefined reference to `BlockAssembler::BlockAssembler(CChainParams const&)' and in last Makefile:774: recipe for target 'all-recursive' failed m...

stackoverflow.com

해결방법은 이대로 기본 세팅을 다시 하면 된다.

sudo apt-get install build-essential libtool autotools-dev automake pkg-config bsdmainutils python3  

sudo apt-get install libssl-dev libevent-dev libboost-system-dev libboost-filesystem-dev libboost-chrono-dev libboost-test-dev libboost-thread-dev

sudo apt-get install software-properties-common
sudo add-apt-repository ppa:bitcoin/bitcoin
sudo apt-get update
sudo apt-get install libdb4.8-dev libdb4.8++-dev

필자는 위 명령어로 다시 진행하여 성공적으로 make, make install 까지 진행하였다.

이후 which bitcoind, which bitcoin-cli 명령어를 통해 경로를 찾아낼 수 있으면 bitcoin core 설치는 완료된 것이다.

참고

https://www.youtube.com/watch?v=LU0WSOeZ0sQ&list=PLZwFtgKc35I_ROUsSev0xcy5poVH486CV&index=3

[Jackson] 민감한 데이터를 JsonProperty를 통해 serialize, deserialize 하는 방법

cbw1030 — Sat, 22 Jan 2022 13:16:41 +0900

안녕하세요. 이번 포스팅은 클라이언트가 정보를 조회했을 때 모든 데이터를 보여주는 것이 아닌 Jackson 라이브러리를 사용해서 필요한 데이터만 보여주는 방법에 대해 소개하겠습니다.

아래의 User 클래스가 있다고 가정하겠습니다.

@Data // lombok
public class User {
    private int id;
    private String userId;
    private String password;
}

클라이언트가 어떤 회원에 대한 정보를 조회하기 위해 GET 요청을 했을 때 아무런 조치를 하지 않는다면 id, userId, password를 모두 조회할 수 있게 됩니다.

password는 중요한 정보이기 때문에 보여주면 문제가 발생합니다.

스프링부트에서는 Jackson 라이브러리를 기본적으로 갖고 있기 때문에 의존성을 추가할 필요는 없습니다.

@Data // lombok
public class User {
    private int id;
    private String userId;
    
    @JsonIgnore
    private String password;
}

password에 @JsonIgnore 어노테이션을 추가함으로써 클라이언트가 정보를 조회할 때 서버에서는 password 필드를 제외한 id, userId만 응답하게 됩니다.

하지만 @JsonIgnore는 직렬화 뿐만 아니라 역직렬화를 할 때에도 적용된다는 특징이 있습니다.

회원이 로그인을 할 때 userId, password를 입력하는데 @JsonIgnore를 password 필드에 적용함으로써 서버로 userId만 넘어오게 됩니다. 이렇게 되면 회원은 로그인을 할 수가 없습니다.

이를 해결하는 방법은 @JsonProperty를 사용하면 됩니다. (더 있을 수도 있어요)

AUTO
READ_ONLY
WRITE_ONLY
READ_WRITE

@Data // lombok
public class User {
    private int id;
    private String userId;
    
    @JsonProperty(access = Access.WRITE_ONLY)
    private String password;
}

@JsonProperty(access = Access.WRITE_ONLY)

@JsonProperty 어노테이션에 access 옵션을 Access.WRITE_ONLY로 주면 됩니다.

말 그대로 역직렬화(deserialize; JSON -> Java Object)할 때에만 접근이 허용된다는 뜻입니다.

클라이언트의 요청이 들어올 때는 password 데이터를 받을 수 있지만, 조회를 할 때에는 제외되기 때문에 응답 본문에 표시되지 않습니다.

@JsonProperty의 access 옵션은 WRITE_ONLY 말고도 세 가지가 더 있습니다.

- AUTO

- READ_ONLY

- READ_WRITE

직관적이라 쉽게 이해하실겁니다.

롬복을 사용하지 않는다면 아래처럼 사용도 가능합니다.

Getter에 @JsonIgnore를 설정하고 Setter에 @JsonProperty를 설정하면 역직렬화할 때에만 접근이 허용됩니다.

참고

https://github.com/cheese10yun/blog-sample/tree/master/jackson

[스프링] MultipartFile 인터페이스를 활용한 다중 파일 업로드

cbw1030 — Sat, 15 Jan 2022 14:51:15 +0900

과거엔 HttpServletRequest 인터페이스를 상속받은 MultipartHttpServletRequest 인터페이스를 활용하여 파일을 업로드 할 수 있었습니다.

MultipartHttpServletRequest를 사용해서 파일 업로드를 구현할 수 있지만 스프링이 제공해주는 MultipartFile 인터페이스를 활용함으로써 더욱 쉽게 파일을 단일, 다중으로 업로드를 할 수 있습니다.

공통적으로 사용하는 HTML은 아래와 같습니다. 타임리프를 사용했습니다.

<div class="container">
    <div class="py-5 text-center">
        <h2>상품 등록 폼</h2>
    </div>
    <h4 class="mb-3">상품 입력</h4>
    <form th:action method="post" enctype="multipart/form-data">
        <ul>
            <li>상품명 <input type="text" name="itemName"></li>
            <li>파일<input type="file" name="file"></li>
            <li>파일2<input type="file" name="file2"></li>
        </ul>
        <input type="submit"/>
    </form>
</div> <!-- /container -->

파일을 2개 보낼 수 있습니다.

type은 file로 해야 MultipartFile이 인식을 할 수 있으며 각각의 파일을 구분지어야 하므로 name은 file, file2로 달라야 합니다.

input 옵션의 multiple을 사용하지 않았으므로 각각 파일 선택은 1개씩만 가능합니다.

상품 등록 폼

단일 업로드를 해보겠습니다.

위의 HTML 파일에서 <li>파일2<input type="file" name="file2"></li> 을 빼고 진행했습니다.

@PostMapping("/upload")
public String saveFile(@RequestParam String itemName,
                       @RequestParam(name = "file") MultipartFile file) throws IOException {

    if (!file.isEmpty()) {
        String fullPath = fileDir + file.getOriginalFilename();
        file.transferTo(new File(fullPath));
    }
    return "upload-form";
}

위의 코드에 대해 설명을 하자면 사용자가 폼으로 파일을 전송하면 컨트롤러는 POST 방식으로 이를 처리합니다.

HTTP Method가 POST인 경우에는 컨트롤러의 매개변수에 주로 @RequestBody를 넣어 처리를 하는데 파일을 처리하는 경우에는 조금 다릅니다.

기본적으로 @RequestBody는 body로 전달받은 JSON 형태의 데이터를 파싱을 합니다. 반면 Content-Type이 multipart/form-data로 전달되어 올 때는 Exception을 발생시켜 문제가 됩니다.

따라서 Content-Type이 multipart/form-data인 경우에는 @RequestBody가 아닌 다른 방법을 사용해야 합니다.

방법은 @RequestParam, @RequestPart 어노테이션을 사용하는 방법이 있는데 여기서는 @RequestParam을 사용했습니다.

이번엔 그리 좋지 않은 방법으로 다중 업로드를 해보겠습니다.

@PostMapping("/upload")
public String saveFile(@RequestParam String itemName,
                       @RequestParam(name = "file") MultipartFile file,
                       @RequestParam(name = "file2") MultipartFile file2) throws IOException {

    if (!file.isEmpty()) {
        String fullPath = fileDir + file.getOriginalFilename();
        file.transferTo(new File(fullPath));
    }

    if (!file2.isEmpty()) {
        String fullPath = fileDir + file2.getOriginalFilename();
        file2.transferTo(new File(fullPath));
    }
    return "upload-form";
}

보통 폼으로 데이터를 전송할 때는 전송하는 데이터들이 서로 연관이 있는 관계입니다.

어떤 상품을 등록한다고 가정할 때 상품이름, 상품이미지1, 상품이미지2 데이터를 폼으로 넘겨준다면 서로 연관이 있는 관계란 뜻입니다.

그런데 위 컨트롤러의 saveFile의 파라미터를 @RequestParam으로 받아버린다면 저것을 구현한 개발자가 아닌 또 다른 개발자가 본다면 서로 연관이 있는 데이터가 아니라고 생각할 수도 있습니다.

따라서 @RequestParam을 사용해서 데이터를 각각 받는 것 보다는 Product 클래스를 만들고 상품이름, 상품이미지1, 상품이미지2를 필드로 지정한다음 @ModelAttribute를 사용해서 받으면 훨씬 깔끔해질 뿐만 아니라 다른 개발자가 이것을 봐도 데이터의 연관 관계를 쉽게 파악할 수 있습니다.

@RequestBody를 사용하지 않고 @ModelAttribute를 사용하는 이유는 클라이언트에서 전송하는 HTTP Request의 Content-Type이 multipart/form-data이기 때문입니다.

@RequestBody의 역할은 클라이언트가 보내는 HTTP 요청의 본문(JSON 또는 XML)을 HttpMessageConverter를 통해 Java 객체로 변환하는 것입니다. 더 정확히 말하면 HttpMessageConverter 인터페이스를 구현한 MappingJackson2HttpMessageConverter를 통해 Java 객체로 변환합니다.

그런데 이번에 다루는 내용은 Content-Type이 application/json이 아닌 multipart/form-data이기 때문에 @ModelAttribute를 사용해야 합니다. @ModelAttribute는 Content-Type이 x-www-form-urlencoded, multipart/form-data 일 때 사용합니다.

깔끔한 다중 파일 업로드 실습을 하기 전에 HTML input을 수정하겠습니다.

현재는 파일 선택에서 1개씩만 파일을 선택할 수 있지만, 실제 서비스를 이용하다보면 파일 선택에서 여러 개의 파일을 선택합니다. 1개씩만 선택할 수 있다면 사용자의 입장에서는 불만이 많겠죠.

여러 개의 파일을 선택하기 위해서는 type="file"을 유지한 채 multiple 옵션을 주고 name에는 배열 형식으로 이름을 지정해줘야 합니다. (itemImgList[])

<div class="container">
    <div class="py-5 text-center">
        <h2>상품 등록 폼</h2>
    </div>
    <h4 class="mb-3">상품 입력</h4>
    <form th:action method="post" enctype="multipart/form-data">
        <ul>
            <li>상품명 <input type="text" name="itemName"></li>
            <li>파일<input type="file" name="itemImgList[]" multiple></li>
        </ul>
        <input type="submit"/>
    </form>
</div> <!-- /container -->

다중 선택이 가능한 상품 등록 폼

그럼 Product 클래스를 만들고 @ModelAttribute를 사용해보겠습니다.

롬복 @Data를 사용하여 Getter, Setter를 생성했습니다.

위의 input의 name="itemImgList[]" 였으므로 List<MultipartFile>로 이를 받았습니다.

@Data
public class ProductDomain {
    private String itemName;
    private List<MultipartFile> itemImgList;
}

@PostMapping("/upload")
public String saveFile(@ModelAttribute ProductDomain productDomain,
                       HttpServletRequest request) throws Exception {
    log.info("request={}", request);

    if (productDomain == null) {
        throw new Exception("전달받은 폼 데이터가 없음");
    }

    log.info("mutipartList = {}", productDomain.getItemImgList());

    for (MultipartFile file : productDomain.getItemImgList()) {
        log.info("file name = {}", file.getOriginalFilename());
    }
    return "upload-form"
}

저는 파일 2개를 선택했고 아래 로그에서 잘 가져오는 것을 확인했습니다.

파일 2개를 잘 가져옵니다.

[리눅스] logrotate를 사용하여 날짜별 tomcat 로그 관리하기

cbw1030 — Tue, 21 Dec 2021 23:48:21 +0900

스프링 웹 애플리케이션을 운영하는 경우에는 톰캣을 직접 설치(외장 톰캣)하고 catalina.sh을 커스터마이징함으로써 날짜별로 로그를 관리할 수 있습니다.

하지만 스프링부트 웹 애플리케이션을 운영하는 경우에는 내장 톰캣 방식이라 catalina.sh을 커스터마이징 하기가 힘듭니다.

스프링 부트는 백그라운드로 배포할 때 명령어를 아래와 같이 사용합니다.

nohup java -jar demo-0.0.1-SNAPSHOT.jar &

nohup 명령어를 사용해서 배포를 할 때 로그가 저장되는 경로 및 로그 파일명을 지정하지 않으면 현재 위치에서 아래처럼 nohup.out으로 저장이 됩니다.

로그가 저장되는 경로 및 로그 파일명을 지정하려면 아래처럼 하면 됩니다. (단, 로그 파일을 저장하려는 경로는 존재한 상태여야 합니다.)

nohup java -jar demo-0.0.1-SNAPSHOT.jar > /home/logs/tomcat/server.log &

/home/logs/tomcat 경로에 server.log가 생긴 것을 확인할 수 있다.

실제 운영하는 서비스에서 server.log에만 로그가 계속 쌓인다면 로그를 분석하기에도 힘들고 용량이 커져서 서버에 부하가 걸릴겁니다. 그래서 톰캣 로그를 날짜별로 관리하는 것이 중요합니다.

logrotate

로그를 주기적으로 자동 관리해주는 프로그램입니다. 리눅스에 기본적으로 설치되어 있습니다.

설치되어 있지 않다면 설치 방법은 아래와 같습니다. (centos 기준)

yum install logrotate

logrotate 설정

/etc/logrotate.conf 파일을 열어보면 logrotate 관련 기본정보 및 설명들이 작성이 되어 있습니다.

# see "man logrotate" for details
# rotate log files weekly
weekly

# keep 4 weeks worth of backlogs
rotate 4

# create new (empty) log files after rotating old ones
create

# use date as a suffix of the rotated file
dateext

# uncomment this if you want your log files compressed
#compress

# RPM packages drop log rotation information into this directory
include /etc/logrotate.d

# no packages own wtmp and btmp -- we'll rotate them here
/var/log/wtmp {
    monthly
    create 0664 root utmp
        minsize 1M
    rotate 1
}

/var/log/btmp {
    missingok
    monthly
    create 0600 root utmp
    rotate 1
}

# system-specific logs may be also be configured here.

logrotate는 logrotate.conf를 참조하여 기본적으로 /etc/logrotate.d 디렉토리에 있는 설정에 맞게 로그를 롤링/삭제/백업을 진행합니다.

logrotate.conf는 건들지 않아도 되고 /etc/logrotate.d 디렉토리에서 server라는 파일을 만들어서 logrotate 설정을 해보겠습니다.

/home/logs/tomcat/server.log {
    daily        # weekly(주 단위로 로테이트), monthly(월 단위로 로테이트)
    rotate 30    # daily인 경우 30일만 로그파일을 관리함(weekly인 경우는 30주 관리)
    copytruncate # (아래에서 자세히 설명)
    dateext      # 로테이트로 인해 생성된 파일명에 날짜를 부여
    notifempty   # 로그 파일에 내용이 없다면 로테이트 하지 않음
    missingok    # 로그파일이 없을 경우 에러메세지를 출력하고 다음으로 실행
    nocompress   # 로테이트로 인해 생성된 파일을 압축하지 않음
}

위 옵션 말고도 여러 옵션이 존재하는데 여기를 참고해주세요.

logrotate 실행

실행하는 방법은 총 4가지가 있습니다. 필자는 4번으로 진행했습니다.

/usr/sbin/logrotate -f /etc/logrotate.d/server  # (실행만함) 
/usr/sbin/logrotate -o /etc/logrotate.d/server  # (디버그 모드) 
/usr/sbin/logrotate -v /etc/logrotate.d/server  # (실행과정 화면에 표시) 
/usr/sbin/logrotate -vf /etc/logrotate.d/server # (실행 + 실행과정 화면에 표시)

/home/logs/tomcat 경로에 server.log 파일만 존재했는데 server.log-20211221 파일이 생성되었습니다.

logrotate 실행 여부 확인

logrotate가 잘 실행되고 있는지 확인하는 방법은 아래 파일을 실행하면 확인이 가능합니다.

vi /var/lib/logrotate/logrotate.status

잘 실행되고 있습니다

logrotate의 동작 방식

logrotate는 기본적으로 rename을 기반으로 동작합니다.

로테이트의 대상이 되는 로그 파일(server.log)을 찾은 다음 설정에 맞게 날짜 suffix를 붙이고 rename을 합니다.

rename은 기존 파일의 이름만 바꾸기 때문에 파일명이 변경된 파일(server.log-20211221)을 그대로 둔다면 이름이 바뀐 파일에 계속해서 로그가 쌓입니다.

이를 방지하기 위해 logrotate 설정 파일에 copytruncate를 설정을 하게 됩니다.

copytruncate는 rename을 기반으로 동작하면서 copy와 truncate 작업을 병행합니다.

https://brunch.co.kr/@alden/27 참고

copytruncate가 장점만 갖는 것은 아닙니다. copy 하는 크기가 GB이상 될 경우 I/O를 하는데에 있어 부하가 생길 수 있습니다. 따라서 쌓이게 될 로그의 예상 크기를 고려해서 사용하는 것이 좋을 것 같습니다.

참고 사이트

https://brunch.co.kr/@alden/27

https://server-talk.tistory.com/271