// 에드센스

블록체인에 대해 전반적인 그림을 그리기 위해 조사하며 얻은 얕은 지식입니다.


0. 코인말고 블록체인

암호화폐에 대한 글은 아니고 카카오의 블록체인 프로젝트 클레이튼으로써 클레이튼 네트워크 전반에 대해 얕게 조사해 본것을 정리하고자 한다.

이번 포스팅은 클레이튼 공식 문서에 있는 소개 동영상을 보고 정리한 내용이다.

https://ko.docs.klaytn.com/bapp/tutorials/bapp-on-baobab-video-lecture/1.-introduction

 

1. 소개 - Klaytn Docs KO

Baobab에서 BApp 개발하기(동영상 강의)

ko.docs.klaytn.com

 

 

 

 


1. 다른 블록체인 플랫폼들의 약점

  • Scalability(확장성)
  • Finality(확정성)
  • Fork(분기발생)

 

 

 

1. Scalability(확장성)

"얼마나 많은 일을 신속하게 처리할 수 있는지"

 

를 의미한다.

이때 TPS와 Block Interval의 개념이 나온다.

TPS란 Transaction Per Second로, 초당 몇개의 트랜잭션(거래)인지를 의미하고.

Block Interval은 블록 생성 주기를 의미한다.

 

  • 비트코인은 보통 7 TPS
  • 이더리움은 보통 15~20 TPS

반면,

  • VISA카드는 1700 TPS를 가진다.

 

또 Block Interval을 보면

  • 비트코인은 10분
  • 이더리움은 15~20초다.

 

다시말해

이더리움이 20 TPS에 15초의 인터벌을 가진다면 20 * 15 = 300 transactions라는 것을 알 수 있다.

이더리움으로 우리가 송금을 한다면, 이더리움 블록이 생성이 되어야 거래가 성사되기에 15초의 대기시간이 필요하다. 물론 비트코인의 10분에 비해서 이더리움의 15초는 많이 개선된 것이긴 하지만 여전히 너무 느리다.

 

왜 이렇게 느리지?

기존 평범한 중앙 서버 방식에서는 큰 request가 들어올 경우 많은 서버들이 request를 나누어 병렬적으로 처리를 하기에 서버의 개수를 증가시키면 처리 속도를 늘릴 수 있었다.

하지만 블록체인 네트워크에서는 노드의 수가 아무리 많다해도 일을 분산해서 처리하는 것이 아닌 모든 노드가 모든 일을 한다. 즉, 전체 네트워크에서 가장 낮은 퍼포먼스의 노드를 기준으로 전체 네트워크의 속도가 낮아지는 하향평준화가 발생한다.

 

하지만,

킹레이튼은 3000 TPS와 Block Interval 1초를 가진다.

 

 

 

2. Finality(확정성)

FInal이란 트랜잭션이 블록에 기록되고 그 블록을 더 이상 수정할 수 없는 상태를 의미한다.

Finality는 블록이 더 이상 변경될 수 없는 상태까지 소요되는 시간을 의미한다고 할 수 있다.

 

이전 포스팅에서 51%공격과 컨펌의 개념에 대해 살짝 다뤘는데 그 내용인 듯 하다.

  • 비트코인은 블록생성(채굴)까지 10분이 걸리고, 60분의 Finality 시간이 걸린다.(10분씩 6번의 검증)
  • 이더리움은 블록생성(채굴)까지 15초갸 걸리고, 6분의 Finality 시간이 걸린다.(15초씩 25번의 검증)

 

즉, 내가 만약 비트코인으로 송금을 했고, 10분이 지나서 나의 거래기록이 저장된 블록이 생성되어 체인에 붙었다고 해도,

그 거래를 확정하려면 그 뒤로 5개의 블록이 더 붙어야 한다는 것이다. 그 정도로 많은 블록이 추가로 붙은 체인이어야만 메인 체인으로 인정을 해 줄수 있기 때문이다.

거꾸로 말하면 비트코인은 60분동안은 내 거래내역이 무효화 될 수 있다는 뜻.

 

하지만,

갓레이튼은 Finality까지 1초면 충분하다.

 

 

 

3. fork(분기발생)

비트코인과 이더리움은 PoW 알고리즘으로 블록 생성 노드를 결정한다.

매우 복잡한 연산을 노드들끼리 경쟁적으로 하며 먼저 문제를 푼 노드가 블록을 생성하고, 주위 노드들로 자신이 문제를 풀었다고 전파를하는 원리인데,

 

만약 두개의 노드가 기가막힌 타이밍으로 동시에 문제를 푼다면?

그러면 블록체인에 분기가 발생한다.

 

하나의 예시 상황을 보자

  1. 내가 비트코인을 친구에게 전송했다.
  2. 내가 전송한 거래 기록은 트랜잭션 풀에 저장된다.
  3. 채굴 노드들은 트랜잭션 풀에서 거래 기록을 모으고 문제를 풀며 블록을 생성하기 위해 애쓴다.
  4. 이때 기막힌 타이밍에 A노드와 B노드가 동시에 문제를 풀어냈다.
  5. 따라서 A노드와 B노드는 동시에 자신이 문제를 풀었다는 사실을 주위 노드들에게 전파한다.
  6. 주위 노드들은 A노드에게 전파받은 노드는 A노드가 생성한 블록을 체인에 추가하고 다시 문제를 푼다.(B노드의 경우도 마찬가지) 이때 A노드와 B노드가 동시에 생성한 블록의 내용은 동일하다. 동일한 트랜잭션을 모았으니까.
  7. 그러면 현재 A노드가 생성한 #6-1블록이 체인 마지막에 붙은 줄 알고있는 노드가 있을 것이고, B노드가 생성한 #7블록이 체인 마지막에 붙은 줄 알고있는 노드가 있을 것이다.
  8. 이 상태로 노드들은 다시 열심히 채굴을 하고 이번에는 어떤 C노드가 문제를 풀어내어 블록 생성 권한을 가졌다고 해보자.
  9.  C노드는 B노드가 생성했던 #7블록을 마지막으로 하는 체인을 알고있는 노드라면 #7블록 뒤에 자신이 생성한 #8 블록을 붙인다. 그리고 이 사실은 모든 노드들에게 전파된다.
  10. #6-1 블록을 갖고있던 노드들은 #7블록이 없기에 자신들의 체인을 포기하고 #6 - #7 - #8 체인의 형태로 다시 채굴을 시작한다.

 

이런 흐름으로 PoW가 작동하는데 여기서 51%공격이 발생할 수 있다.

 

황레이튼은 이런 위험이 있는 PoW 방식 대신 IBFT 알고리즘을 사용하여 문제를 해결했다.

 

https://steemit.com/kr/@kanghamin/istanbul-byzantine-fault-tolerance

 

Istanbul Byzantine Fault Tolerance/이스탄불 비잔티움 장애 허용 — Steemit

Istanbul Byzantine Fault Tolerance(=IBFT)에서는 3단계로 합의과정이 이루어져있다. Pre-Prepare Prepare Commit 시스템은 잘못된 노드(나쁜 노드)가 F라고 가정했을때 총 노드수가 3F+1이상이면 돌아갈 수 있다. N =

steemit.com

 

 

 

 


2. 클레이튼의 합의 과정

참여 노드 수를 제한하여 성능을 높힌 BFT 알고리즘은 덜 분산적이고 투명성이 저하된다는 단점이 있다.

이 단점을 개선한 방식이 IBFT다. 이거에 대해선 따로 다시 공부를 해야한다...

 

IBFT의 경우 1명의 제안자(Proposal)다수의 위원회(Commit/Validator)로 구성된다.

제안자는 거버넌스 카운실(Governance Council) 노드들 중 랜덤으로 선정된 하나의 노드이며 이번 라운드는 자신이 선정다는 사실을 자신의 공개키를 통해 암호화하여 위원회 노드들에게 알린(전파한)다. (클레이튼의 블록 생성 주기를 라운드라고 한다.)

위원회 노드들의 경우도 자신이 합의 노드라는 것을 합의 노드들에게 공개키를 통해 암호화하여 알린다.

제안자는 합의 노드의 2/3의 서명을 받을 경우 블록을 생성하고 다른 위원회 노드들에게 전파한다.

 

 

 

 


3. 클레이튼 네트워크의 구조

CNN : consensus node network = 합의 노드 / 제한 노드

PNN : proxy node network = 블록을 앤드포인트 노드에게 전달하는 노드

ENN : Endpoint node network = 기타 노드 / 누구나 참여가능 노드

CN/PN/ENBootnode : 새로운 참가자의 노드를 등록하게 도와주는 노드

CNN + PNN : Core cell

출처: https://jeongbincom.tistory.com/88 [하나셋 - 프로그래머로써 살아남기]

CN노드들간의 합의 끝에 블록이 생성되고 CNN에서 PNN으로, PNN에서 EN들에게 전파된다.

 

 

왜 CN -> EN의 다이렉트 통신을 안하고 CN -> PN -> EN처럼 중간에 PN을 둘까?

위에 언급하였듯 블록체인 네트워크에서 커다란 request가 들어온다면 이 request를 여러 노드들이 분산하여 처리하는 것이 아닌 각각의 노드들이 모든 request를 처리해야한다. 따라서 네트워크의 성능은 그 네트워크에서 가장 낮은 성능의 노드에 맞춰진다.

 

즉, CN 노드들의 성능이 매우 중요한데, CN 노드들은 합의하는 것에만 최선을 다해도 모자란 판인데 EN들과 통신하는 것에 자원을 낭비해선 안된다. 따라서 CN 하나에 여러개의 EN을 연결하는 구조 대신, CN 하나와 여러개의 EN 사이에 PN을 두어 EN과 통신하는 측면에서 성능을 높힌것이다.

 

참고로 CN 노드가 되려면 

  • Physical core가 40개 이상
  • 256GB RAM
  • 14TB 이상 저장공간
  • 10G 네트워크

의 조건이 필요하다고 한다.

 

 

 

 


4. 서비스 체인

메인넷과 연결돼있고, 독립적으로 운영되는 체인이다.

  • Bapp이 특별한 노드 환경에서 수행되어야 할 때
  • 프라이빗 블록체인과 같이 보안 수준 맞춤형으로 설정해야 할 때
  • 많은 처리량을 요구하는 서비스라서 메인넷에서 사용하기엔 비용 부담이 될 때

서비스 체인을 사용한다.

 

메인체인과 서비스체인간 통신은 되지만 제한된 조건 하에서 통신한다.

요약하면 서비스 체인은 독립된 서비스 공간을 구축해서 필요할때 메인넷의 신뢰를 고정 시키는 것

참고로 클레이튼의 서비스 체인에서는 트랜잭션 가스비를 안받도록 설정할 수 있다.

 

 

 

 


5. 이더리움 VS 클레이튼

이더리움

  • 단일 네트워크
  • PoW방식이고, 어떤 노드가 블록을 생성하게 될지 모름
  • 따라서 최신 블록을 전파받기 위해서 노드는 다른 모든 노드들고 최대한 연결돼 있어야한다.

 

클레이튼

  • 2개의 레이어를 가지는 네트워크
  • 매 라운드마다 합의 노드들 중  하나가 뽑혀서 블록을 생성한다.
  • 이더리움과 달리 합의 노드들 중에서 블록이 생성되기에 어떤 노드에서 생성될지 거의 알 수 있다.
  • 따라서 최신 블록을 전파받기 위해서는 합의 노드들에게만 연결해 있으면 된다.
  • 개발자가 Bapp을 만들고 엔드포인트 노드에 접속한다. EN -> PN -> CN
  • 혹은 개발자의 Bapp 자체를 엔드포인트로 활용하여 네트워크에 접근할 수도 있다.
  • 메인넷과 부분적으로 소통하며 독립된 서비스 공간을 구축할 수 있는 서비스 체인이 있다.

 

 

 

 

 

참고:

더보기

https://media.fastcampus.co.kr/insight/why-blockchain-is-hard/

블록체인에 대해 전반적인 그림을 그리기 위해 조사하며 얻은 얕은 지식입니다.


1. DID란?

  • 탈중앙화 신원증명(Decentralized Identity)이다.
  • 개인 정보를 사용자 개인이 보관하여(개인 소유의 단말기 등에) 개인 정보 인증 시 필요한 정보들만 골라서 인증을 진행할 수 있도록 해주는 전자신원 증명기술이다.
  • 기존에는 기업이 사용자의 모든 개인 정보를 중앙집중형으로 관리하는 형태였지만, DID는 자신의 개인정보를 자신이 직접 관리하는 분산형태이다.
  • 사용자들의 개인 정보는 사용자들의 개인 단말기에 저장되고, 블록체인에 존재하는 DID 문서라는 것을 통해서 개인 정보를 제출하여 인증받을 수 있다.

 

 

 


2. 왜 DID?

기존 인증 시스템만으로도 세상은 잘 돌아갔다. 굳이 이런 어려운 기술을 사용하는 이유는 뭘까?

 

1. 개인정보 관리의 위험

https://www.thedailypost.kr/news/articleView.html?idxno=80609

 

 

 

"유저 데이터를 소유하는 것은 자산에서 부채가 되고있다"

-비탈릭 부테린-

 

 

이런 이슈를 DID는 해결해줄 수 있다.

  • 개인의 입장에선, 자신의 정보를 직접 자신이 직접 관리하기에 나의 개인 정보를 기업에 의존하지 않아도 되고,
  • 기업의 입장에선, 직접 관리했다가 유출사고가 발생할 수 있는 리스크를 줄일 수 있다.

그러면 DID 기술을 어떻게 구현되는지 살펴보자.

 

 

 

 


3. DID의 구성 요소

1. DID 아이디

DID 아이디는 DID 문서의 위치를 나타낸다. 콜론을 통해서 3등분으로 구분되는데 의미는 다음과 같다.

  • did: DID 스키마를 따를 것임을 의미
  • example: DID 메소드의 이름을 의미, DID 메소드란 특정 분산 원장 또는 네트워크에서 DID와 관련된 DID 문서들을 생성, 읽기, 갱신, 그리고 비활성화 하는 메커니즘이다. DID 메소드들은 여기에서 확인해볼 수 있다.
  • 123456789abcdefghi: DID 메소드 안의 고유 아이디를 의미한다.

 

 

2. DID 문서

DID문서는 DID아이디의 제어권, 소유권을 증명할 수 있는 공개키와 인증정보를 가지고있다. 블록체인에 올라가있으며 여기에는 민감한 개인정보는 포함돼 있지 않다.(블록체인에 보관하지 않아도 되지만 대부분 블록체인에 보관한다고 한다.)

  • id: 이 DID문서가 설명하고 있는 아이디를 의미한다.
  • publicKey: 아이디와 관련된 공개키 리스트.
  • authentication: 이 아이디의 소유권 증명을 위한 정보.
  • service: 이 아이디와 상호작용이 가능한 서비스들을 의미한다.

 

 

3. VC(Verifiable Credential)

블록체인에 올라가서 모두에게 보여지는 DID문서에는 당연히 사용자의 개인정보가 포함되면 안된다. 사용자의 민감한 정보들은 사용자가 소지하는 단말기(휴대전화 등)에 저장되며 이를 VC라고 한다. 

  • VC에는 이름, 나이, 주소, 백신접종여부등의 정보가 들어있다.
  • VC는 개인이 단말기의 지갑 애플리케이션과 같은 안전한 영역에서 보관한다.
  • 자신이 가진 모든 VC들을 인증을 위해 제출해야 하는것이 아닌, 원하는 VC들만 골라서 제출할 수 있다. 즉, 담배를 구입할 때 신분증을 제출하면 나의 이름과 주민등록번호와 주소지 등이 노출되지만, 성인여부에 대한 VC만 골라서 제출하면 다른 민감한 정보의 노출을 막을 수 있다.
  • VC의 단위는 Claim이라고 한다.

 

 

 

 


4. 인증 과정

모든 종류의 DID가 다음과 같은 인증 절차를 가지는 것은 아니기에 거시적인 관점에서만 DID발급, 사용, 검증으로 나누어서 살펴보도록 하자.

 

 

1. 발급하는 법

신원정보발행자가 어떤 유저의 클레임을 발급해주는 과정이다.

  1. 사용자는 신원정보발행자(이슈어)에게 클레임(인증하고자 하는 항목, 예를들어 백신접종여부) 발급을 요청한다.
  2. 공인 인증된 이슈어는 사용자의 클레임을 생성하고 클레임에 이슈어의 개인키로 서명을 한다.
  3. 그 후 이슈어는 블록체인에 존재하는 사용자의 DID문서에 이슈어의 공개키를 등록한다.
  4. 발급된 클레임을 사용자에게 반환한다.

이제 사용자는 어떤 권한에 대해 인증할 수 있는 하나의 클레임을 얻은 것이다.(성인 여부, 백신 접종여부 등)

 

 

 

2. 사용하는 법

사용자가 발급받은 클레임을 통해서 자신의 정보를 인증하는 과정이다.

  1. 사용자는 발급받은 클레임에 자신의 개인키로 서명을 한다. (클레임은 현재 사용자의 개인키로 1회, 이슈어의 개인키로 1회, 총 두번의 개인키 서명이 된 상태)
  2. 사용자의 공개키를 블록체인에 존재하는 자신의 DID 문서에 등록한다. (혹은 클레임과 함께 공개키도 직접 보낸다)
  3. 검증자에게 클레임을 제출한다.

여기서 검증자는 백신패스를 확인하는 음식점 사장님이라고 가정해보자.

 

 

 

3. 검증하는 법

  1. 음식점 사장님은 사용자의 클레임을 받아서 검증을 진행한다.
  2. 검증은 클레임에 걸린 두번의 개인키 서명을 풀어야한다(복호화)
  3. 먼저 사용자의 DID문서를 조회하여 사용자의 공개키를 획득하고(혹은 직접 받은 공개키를 획득하고),
  4. 사용자가 전달한 클레임에서 사용자가 개인키로 서명한 것을 복호화한다.
  5. 사용자의 개인키로 된 서명이 풀렸다는 것은 -> 인증 정보가 해당 사용자의 것이 맞다는 것을 의미한다.
  6. 다음으로, 사용자의 DID문서에 존재하는 이슈어의 공개키를 통해서 이슈어의 개인키로 서명한 것을 복호화한다.(이제 모든 서명이 풀렸다!)
  7. 이슈어의 공개키로 복호화가 되었다는 것은, 해당 이슈어가 발급한 클레임이 맞다는 것이고, 이는 사용자의 인증 정보가 신뢰할 수 있음을 의미한다.

 

 

 

 

 

 

참고:

더보기

https://media.fastcampus.co.kr/insight/why-blockchain-is-hard/

블록체인에 대해 전반적인 그림을 그리기 위해 조사하며 얻은 얕은 지식입니다.


1. 채굴이란?

채굴은 새로운 블록을 생성하는 것을 의미한다.

블록은 채굴 노드가 생성한다.

저번 포스팅에서 말했 듯, 트랜잭션들은 검증노드로부터 네트워크 여러곳으로 전파된다.

채굴노드는 네트워크에 공유되고 있는 트랜잭션들을 모아서 블록 만들기를 시도한다.

 

 

비트코인은 블록 한개당 1MB의 크기이다. 물론 모든 코인이 동일하지는 않고 어떤 블록체인을 사용하느냐에 따라 다르다.

 

 

비트코인은 블록 한개가 생성되는데 10분이 걸린다. 즉, 나의 거래내역이 블록에 포함되어 체인에 붙기까지 10분이 걸린다는 것이다. 또 컨펌의 과정을 위해서 추가로 6개의 블록이 이어져야한다.(비트코인의 경우)

컨펌이란 나의 트랜잭션이 포함된 블록이 블록체인의 메인 체인에 들어있다고 확정하는 것이다.

 

 

 

 


2. 어떤 채굴노드가 블록을 생성하는가?

채굴 노드들은 블록을 생성하기 위한 경쟁을 서로 한다.

모든 노드들이 블록을 생성하면 체인은 너무 많은 분기(갈래)가 발생할 것이다.

이 경쟁은 수학문제를 푸는 것이며, 정확히는 특정 해쉬값이 나오게 하는 임의의 논스(nonce)값을 먼저 찾는 경쟁이다.

이 경쟁에서 승리하면 블록을 생성할 수 있고 이 노드에게는 보상이 주어진다.

논스값을 찾는 것은 CPU보다는 GPU를 사용하는 것이 훨씬 빠르기에 그래픽카드를 사용한 채굴이 많은 것이다.

아무튼 이런 고생을 PoW 알고리즘이라고 하며 모든 블록체인이 이 방법을 사용하는 것은 아니다.

여러가지 채굴 알고리즘이 존재하는데, 다음 포스팅에서 공부해보겠다.

 

 

 

 


3. 동시에 블록이 만들어진다면?

경쟁을 하였음에도 동시에 블록을 생성하여 분기가 발생한다면?

 

6번 블록 이후 두개의 갈래로 나눠졌다.

이때 6-1블록과 7블록 중 어떤 블록쪽으로 계속 이어나가야 할까? 

이때 위에 언급한 확정(컨펌)의 개념이 나온다.

 

PoW알고리즘은 

 

"네트워크에 더 많은 기여를 한 사용자는 신뢰할 수 있는 사용자다"

 

라는 전제를 하고있다.

따라서 최초로 분기가 발생하고 그 뒤로 더 많은 블록들이 붙은 쪽이 더 많은 기여를 받은 분기이고 이 쪽을 메인 체인으로 인정한다. 블록들을 더 붙혀보고 많이 붙은 분기를 선택하는 이 과정이 위에서 언급한 컨펌(확정)의 과정이다.

인정받지 못한 분기의 블록들은 고아블록(스테일블록)이 된다.

 

 

 

 


4. 51%공격

블록을 수정하거나 조작하는 것은 불가능할까?

채굴하는 과정에서 GPU는 많은 전력을 소모한다. 논스값을 찾는 경쟁을 하기 때문인데,

왜 채굴하는데 이렇게 많은 전력을 쓰도록 설계한 것일까?

그냥 다음 블록을 생성할 노드를 랜덤으로 정하면 안되는 것일까?

 

이유는 블록체인 네트워크를 해킹으로부터 보호하기 위함이다.

블록 1개를 만드는데 많은 고생(채굴)을 했으니 이것을 수정하기 위해서는 그 이상의 고생(컴퓨팅 파워)를 하도록 만든 것이다. 또 블록 하나를 조작하면 그 블록의 해시값이 바뀌고 이로인해 연결된 블록들의 해시값도 바뀌기 때문에 사실상 블록체인 네트워크 전체 노드들의 고생보다 더 큰 고생이 필요하다.

 

하지만 그렇다해도 방법은 존재한다.

51% 공격이라고 불리는 수단인데, 과정은 다음과 같다.

 

 

 

1. A가 B에게 30코인을 줬다는 거래 내역이 101번 블록에 기록됐다.

 

 

2. A는 전체 네트워크의 51%이상의 컴퓨팅 파워를 지니고 있다고 가정한다.

3. A는 자기의 거래내역을 없애버린 새로운 블록을 만들고 그 뒤로 컨펌을 위한 블록들을 더 빠르게 생성한다.(자신이 가진 51% 이상의 압도적인 컴퓨팅 파워를 사용해서)

 

 

4. 이렇게 되면 A가 조작한 블록이 속한 분기가 메인 체인으로 인정된다. 

고로 A가 B에게 코인을 보낸 사실은 사라진다.

 

 

 

 


5. 51% 공격 대응

사실 이 공격은 공격자가 손해를 보는 모순을 가지고있다.

 

첫째로,

공격자가 이득을 취하기 위해서는 해당 암호화폐의 가치가 올라야한다.

하지만 이런 공격으로인해 해당 암호화폐에 대한 신뢰가 떨어지게 되고, 가치도 떨어진다.

그렇다면 51% 소유자가 가장 큰 손해를 보는 상황이 돼 버린다.

실제로 2014년 특정 마이닝풀이 일시적으로 코인의 해시파워가 51%를 초과하는 일이 발생했을 때, 가격이 폭락했다. 즉, 이론적으로 가능하나 경제적인 이유로 불가능한 공격이라는 것이다.

 

둘째로,

블록체인 네트워크의 참여자가 많을수록 51%의 해시파워를 확보하는 것은 매우 높은 비용이 필요하다.

따라서 해킹을 통해 얻는 수익보다 적자가 난다는 것이다.

하지만 참여자가 적은 네트워크는 51%의 파워를 확보하고 유지할 수도 있기 때문에 이 부분에서는 대안이 필요하다.

이것도 다음 포스팅에서 공부해보겠다.

 

 

 

 

 

참고:

더보기


1. Github Actions를 구성하는 요소

너무 잘 정리하신분의 글을 퍼왔다.

 

  • 1) Workflow
    • 여러 Job으로 구성되고, Event에 의해 트리거될 수 있는 자동화된 프로세스
    • 최상위 개념
    • Workflow 파일은 YAML으로 작성되고, Github Repository의 .github/workflows 폴더 아래에 저장됨
  • 2) Event
    • Workflow를 Trigger(실행)하는 특정 활동이나 규칙
    • 예를 들어 다음과 같은 상황을 사용할 수 있음
      • 특정 브랜치로 Push하거나
      • 특정 브랜치로 Pull Request하거나
      • 특정 시간대에 반복(Cron)
      • Webhook을 사용해 외부 이벤트를 통해 실행
    • 자세한 내용은 Events that trigger workflows 참고
  • 3) Job
    • Job은 여러 Step으로 구성되고, 가상 환경의 인스턴스에서 실행됨
    • 다른 Job에 의존 관계를 가질 수 있고, 독립적으로 병렬 실행도 가능함
  • 4) Step
    • Task들의 집합으로, 커맨드를 날리거나 action을 실행할 수 있음
  • 5) Action
    • Workflow의 가장 작은 블럭(smallest portable building block)
    • Job을 만들기 위해 Step들을 연결할 수 있음
    • 재사용이 가능한 컴포넌트
    • 개인적으로 만든 Action을 사용할 수도 있고, Marketplace에 있는 공용 Action을 사용할 수도 있음
  • 6) Runner
    • Gitbub Action Runner 어플리케이션이 설치된 머신으로, Workflow가 실행될 인스턴스
    • Github에서 호스팅해주는 Github-hosted runner와 직접 호스팅하는 Self-hosted runner로 나뉨
    • Github-hosted runner는 Azure의 Standard_DS2_v2로 vCPU 2, 메모리 7GB, 임시 스토리지 14GB

 

참고:

 

 

 

 


2. Beanstalk으로 배포하기

프로젝트 최상위에 .github/worfklows 폴더를 만들고 그 안에 .yml 스크립트로 깃헙 액션의 동작을 지정할 수 있다.

yml 파일 대부분은 처음 보더라도 대충 어떤 의미인지 알 수 있다.

 

name: Backend CI/CD

on:
  push:
    branches: [ develop ]

jobs:
  build:
    name: Build and Test
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [14.x]

    steps:
      - uses: actions/checkout@v2
      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v2
        with:
          node-version: ${{ matrix.node-version }}
          cache: 'npm'

      # Download AWS CLI 2
      - name: Install AWS CLI 2
        run: |
          curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
          unzip awscliv2.zip
          which aws
          sudo ./aws/install --bin-dir /usr/local/bin --install-dir /usr/local/aws-cli --update
          
      # Configure AWS credentials
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ${{ secrets.AWS_REGION }}

      # npm install for ci
      - run: npm ci

      # Build
      - run: npm run build

      # Unit test
      - run: npm run test:unit

  deploy:
    name: BeanStalk Deploy
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: ['14.x']
    needs: build
    steps:
      - uses: actions/checkout@v2

      # Initialize Node.js
      - name: Install Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v1
        with:
          node-version: ${{ matrix.node-version }}

      # Install project dependencies
      - name: Install dependencies
        run: npm install

      # Download AWS CLI 2
      - name: Install AWS CLI 2
        run: |
          curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
          unzip awscliv2.zip
          which aws
          sudo ./aws/install --bin-dir /usr/local/bin --install-dir /usr/local/aws-cli --update
      # Configure AWS credentials
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ${{ secrets.AWS_REGION }}

      # Build
      - name: Run build
        run: npm run build

      # Make upload zip file
      - name: Generate deployment package
        run: zip -r deploy.zip . -x '*.git*' './aws/*' './node_modules/*' './dist/*' awscliv2.zip

      # Deploy to Elastic Beanstalk
      - name: Deploy to EB
        uses: einaregilsson/beanstalk-deploy@v18
        with:
          aws_access_key: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws_secret_key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          application_name: ${{ secrets.APPLICATION_NAME }}
          environment_name: ${{ secrets.ENVIRONMENT_NAME }}
          region: ${{ secrets.AWS_REGION }}
          version_label: ${{github.SHA}}

위에서부터 살피며 내려가자

 

 

 

 

on

jobs를 실행시킬 트리거를 지정한다. 위의 코드처럼하면 develop 브랜치에 push가 발생했을때 github actions가 실행된다는 의미다.

다음처럼 여러개의 트리거를 지정할 수 있다.

  on:
    push:
      branches: [ master ]
    pull_request:
      branches: [ master ]

 

 

 

 

jobs

jobs는 Build와 Deploy로 구성된다. 그리고 각각 name을 지정한 것을 볼 수 있다.

 

 

 

 

Configure AWS Credentials

      # Configure AWS credentials
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ${{ secrets.AWS_REGION }}

코드 내부에 aws를 사용한 부분이 다수 존재하기에 runner에 aws cli를 설치해 주어야한다.

${{ secrets.블라블라 }}

이 부분은 깃허브 - Settings - Secrets 탭에서 Name-Value를 지정할 수 있다.

 

 

${{ secrets.블라블라 }} 에서 블라블라에 Name을 입력해주면 대응되는 Value를 사용할 수 있다.

 

 

 

 

npm ci

이거는 npm install과 같은 역할이다.

다만,

ci 과정에서 쓰는 install이다.

거의 두배 이상 빠른 속도를 보여준다.

 

npm install은 package.json 내부의 dependencies와 devDependencies를 기준으로 패키지 파일을 설치하는 반면

npm ci는 package-lock.json의 lockfile을 기준으로 패키지를 설치한다.

 

이렇게 되면 package.json내의 파일과 package-lock.json 내의 버전 등이 다를 경우,

package-lock.json을 기준으로 package.json 파일을 수정하며, 명시되지 않은 부분에서는 오류를 발생시키므로 Application 관리에 있어서 안정성을 확보할 수 있다.

 

 

 

 

npm run build

# Build
- run: npm run build

package.json에 build 스크립트를 실행한다.

이때 한가지 사용한것이 

 

 

npm install concurrently --save

이거다.

 

 

 

빌드시 .env파일을 비롯한 여러 설정파일들이 존재해야하는데,

이런 중요파일들은 S3에서 다운로드해야만 한다.

따라서 build 스크립트 이전에 수행되는 prebuild스크립트에서 중요 파일들을 미리 다운 받는 행동을 먼저 해야한다.

 

그런데 중요 파일들이 2개 이상일 경우 prebuild 안에서 동시에 스크립트가 수행될 수 있도록 해주는 concurrently를 사용했다.

 

"scripts": {
	...
    "prebuild": "concurrently \"aws s3 cp s3://blahblah .env\" \"aws s3 cp s3://blahblah somethingimportant.json \"",
    "build": "tsc",
    ...
  },

이렇게 concurrently 키워드를 쓰고 ""로 묶어서 스크립트를 넣어주면 된다.

 

 

 

 

deploy - Make upload zip file

# Make upload zip file
- name: Generate deployment package
  run: zip -r deploy.zip . -x '*.git*' './aws/*' './node_modules/*' './dist/*' awscliv2.zip

Beanstalk에 올리기위한 zip 파일을 생성한다.

zip 명령어로 압축파일을 생성하고 다음 step에서 S3로 업로드하고, Beanstalk에 배포된다.

 

 

이때, 압축파일에 포함시키지 않을 파일들을 -x 옵션으로 지정하는데,

node_modules를 지정하지 않았더니 문제가 생겼었다. (node_modules를 zip에 포함시켰더니)

 

 

어자피 .ebextensions에 npm install 키워드가 있기에 node_modules를 zip에 안넣어도 되지만,

어자피 덮어쓰기가 될 줄 알고 딱히 신경쓰지 않았었다.

그랬더니 안됏따아아아ㅏㅏ

정확히는 

 ./lib/cli

를 찾을 수 없다고 에러가 발생했다. 저게 뭔지 모르겠다.

* .ebextensions란 Beanstalk 구성파일로, Beanstalk에 배포될 때 최초에 실행되는 커맨드라고 보면된다.

 

 

우연히 node_modules를 제외시키면서 문제가 해결되긴 했는데 왜 내부에서 충돌이 난것인지는 모르겠다.

혹시 명쾌한 답을 아신다면 댓글 부탁드립니다.

 

 

 

 


삽질한 점

  • ci때와 cd때 둘다 aws cli를 설치해야한다.
  • zip할때 node_modules를 빼줘야한다.

 

 

 

참고:

더보기

'DevOps' 카테고리의 다른 글

[DevOps] CI/CD 파이프라인이란  (0) 2021.11.17
[DevOps] 도커(docker)란?  (0) 2021.10.09

https://media.fastcampus.co.kr/insight/why-blockchain-is-hard/

블록체인에 대해 전반적인 그림을 그리기 위해 조사하며 얻은 얕은 지식입니다.


1. 왜 검증이 필요한가?

블록체인에서 블록은 곧 데이터베이스다.

근데 이 데이터베이스는 모든 사람이 접근하여 작성할 수 있다.

이 데이터베이스를 거래장부라고 할 수 있다.

거래장부에 모든 사람들이 접근하여 거래를 기록할 수 있다면 어떻게 될까?

 

만약

"A가 B에게 100만원을 줬다."

라는 진실된 거래가 있다.

하지만 B가 돈을 갚기 싫어서 다음과 같은 가짜 거래 내역을 썼다.

"B가 A에게 100만원을 줬다"

그러면 실제로 B가 돈을 갚지 않았지만 A와 B사이에는 더 이상 빚진 돈이 없게된다.

 

이런 일을 방지하기 위해 거래내역을 위조할 수 없도록 검증이 필요하다.

 

 

 

 


2. 검증 방법

현실세계에서는 자필 서명이나 도장을 찍는다.

사람이라면 타인의 자필 서명을 완벽하게 흉내낼 수 없다는 전제,

도장은 자신이 소중하게 관리를 한다는 전제,

가 있기 때문이고 이는 잘 작동된다.

 

하지만 모든것이 ctrl+c / ctrl+v로 복제가 되는 인터넷에서는 어떻게 할까?

 

 

 

1. 트랜잭션이란?

데이터베이스에서 상호작용 및 수행의 논리적 단위를 뜻하는 단어이다.

블록이 곧 데이터베이스이니 이렇게 표현한다.

 

 

 

2. 비대칭 암호화 방식

비트코인을 포함한 많은 암호화폐들이 이 방식을 사용한다.

혹은 공개키 알고리즘이라고도 부른다.

 

클라이언트에서 거래를 하면 거래내역이 생성된다.

클라이언트는 이 거래내역을 노드에게 전송하여 검증을 맡긴다.

노드가 이제 검증을 수행하게되는데,

이를 위해서는 거래내역에 노드에게 전송될 때 "전자서명"이 포함되어야 한다.

비대칭 암호화 방식을 통해 전자서명을 생성한다.

우선 다음의 배경지식이 필요하다.

  • 모든 클라이언트들은 자신의 [공개키]와 [개인키]가 있다.
  • [공개키]는 모두에게 노출되어도 괜찮은 키이다.
  • [개인키]는 오직 자신만 알고있어야 하는 키이다.
  • [개인키]로 암호화한 데이터(거래내역)은 [공개키]로만 해독할 수 있다.

[개인키]를 [비밀키], [비공개키]라고도 하는데 나는 그냥 [개인키]라고 하겠다.

 

[개인키], [비밀키], [주소]는 다음과 같은 관계를 가진다.

https://www.google.co.kr/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0ahUKEwi567Lu-ojVAhXDHJQKHZWcC-cQFggmMAA&url=https%3A%2F%2Fdocs.google.com%2Fa%2Fieee.org%2Fuc%3Fid%3D0Byw4AEomZK2edlQwel95S1J0VTg%26export%3Ddownload&usg=AFQjCNHfjSAx7d59S3UDVHjxBQcl3OmkWw

[개인키]를 타원곡선 곱셈함수로 돌리면 [공개키]가 나오고,

[공개키]를 해시함수로 돌리면 [주소]가 나온다.

이 흐름은 그림에서처럼 일방향으로만 진행할 수 있다.

[개인키]로 [공개키]를 알 수는 있지만,

[공개키]로 [개인키]를 알아낼 수는 없다는 것이다.

 

 

 

3. 검증 과정

다른 블로그의 글에는 막 그림도 있고 그러던데, 우리는 그냥 눈을 감고 생각해 보자. 오히려 이해가 잘 될지도?

 

  1. 클라이언트 A는 자신의 거래 내역이 있다.
  2. A는 자신의 거래 내역을 자신의 [개인키]로 암호화한다.
  3. 그 후 A는 노드에게 [개인키로 암호화한 거래내역] + [원본 거래내역] + [A의 공개키]를 세트로 보낸다.
  4. 노드는 저거 3종 세트를 받아서 검증을 수행한다.
  5. 우선, [A의 공개키]로 [개인키로 암호화한 거래내역]을 해독하고 그걸 [원본 거래내역]과 비교한다.
  6. 비교 결과 동일하면 이 거래내역은 A가 생성한 올바른 거래임을 인정한다.
  7. 이후 검증된 거래내역은 해당 노드 근처의 다른 노드들로 전파된다.

5번 과정이 핵심이다.

 

참고로 거래내역을 바로 [개인키]로 암호화하는 것이 아니라

[개인키]를 해시함수로 돌려서 해시값을 뽑아내고 그 해시값을 [개인키로] 암호화하는 것이다.

이렇게 하면 거래내역이 아무리 길어도 고정된 길이의 해시값이 나오기에 송수신시 유리하다.

 

 

 

 


3. 검증자가 조작하면?

A와 검증노드가 합심해서 조작하면 어떻게 될까?

A가 가짜 거래내역을 노드에게 검증신청을 하고,

이 노드가 가짜 거래내역임에도 불구하고 검증완료 처리를 한다면?

 

이를 막기위해 신뢰할 수 있는 노드(검증자)만 검증을 진행할 수 있도록 제한한다.

신뢰할 수 있는 노드를 가리기 위해

 

  1. 검증에 참여하기 위해서는 비용이 발생하도록 만든다.
  2. 검증이 완료되면 네트워크에서 보상을 지급한다.

이런 안전장치를 마련해 두었다.

일종의 입장료를 내야만 검증에 참여할 수 있기에 나쁜 의도를 가진 검증 참여자를 걸러낼 수 있다.

또 보상으로 암호화폐를 받기에 이 화폐의 가치가 올라가기 위해서는 정직한 검증이 이어져야 한다. 

즉, 검증을 정직하게 해야만 하는 이유가 생기는 것이다.

 

 

 

 


4. 헷갈렸던 부분

공개키와 개인키 중에 어떤 것으로 암호화를 하고 복호화를 하는지 헷갈렸다.

내가 지금까지 알아온 방식은

 

  1. A와 B가 있고, A -> B로 데이터를 보낸다면
  2. A는 [B의 공개키]로 보낼 데이터를 암호화해서 보내면
  3. B는 자신만 가지고있는 [B의 개인키]로 복호화해서 보는 것

(이 비유에서 A는 트랜잭션의 생성자가 되겠고, B는 검증노드가 되겠다.)

 

 

 

이런 흐름이었는데 블록체인의 전자서명도 같겠거니 했지만,

[개인키]로 암호화해서 [공개키]로 복호화한다는 점이 반대였다.

누구나 가질 수 있는 [공개키]로 복호화하게 되면 데이터를 누구나 들여다 볼 수 있지 않은가?

라는 생각에 빠져 혼란이 왔었는데,

 

 

생각해보니 데이터를 비밀스럽게 보내기 위한 비대칭키 암호화 방식이 아니라,

데이터를 생성(전송)한 사람의 본인확인을 위한 절차였기에 개인키, 공개키를 반대로 쓰는 것 이었다.

 

 

굳이 검증노드가 생성된 트랜잭션을 비밀스럽게 확인 할 필요는 없고,

오히려 모든 검증노드가 이런 트랜잭션을 까봐서 올바른 트랜잭션인지 확인하기 위해서는 공개키로 복호화를 해야만 하는 것이었다.

 

A의 공개키로 복호화가 된다면?

그 암호는 A의 비밀키로 암호화 했다는 의미 

왜?

비밀키 -[해싱]-> 공개키 -[해싱]-> 지갑주소

이기에 공개키로 해독이 되는 암호는 그 공개키에 해당하는 비밀키로 암호화음이 분명하다.

 

 

[개인키] <-> [공개키] 양쪽으로 암/복호화가 된다는 성질을 이렇게도 활용하는구나 싶어서 소소한 깨달음이었다.

뭔가 적어놓고 보니 당연한 사실이긴한데,

처음 전자서명 암호화를 접할 당시에는 헷갈렸다ㅠㅠ

 

 

 

 


아무튼,

장황하게 썼지만 생각보다 간단하다.

이렇게 많은 노드들로 전파된 거래내역을 채굴노드가 모아서 블록을 생성한다.

이 과정은 다음 글에서 알아보겠다.

 

 

 

 

 

참고:

더보기

 

 


1. 언제 사용할까

develop 브랜치에서 분기한 feat1 브랜치가 있다고 하자.

feat1 브랜치에서 작업을 하며 여러가지 변경사항들이 생겨나고있다.

이때 develop 브랜치나 다른 브랜치로 checkout 해야할 경우가 종종 생긴다.

 

이때 그냥 checkout을 시도하면 git은 commit을 먼저 하라는 경고를 뱉는다.

하지만 난 아직 feat1 브랜치에서의 작업이 끝나지 않아서 커밋하고 싶지 않다면?

 

이때 git stash 명령어를 사용할 수 있다.

 

 

 

 


2. 사용법

feat1 브랜치에서 

git stash

를 쳐주면 feat1에 내가 싸놓은 변경사항들이 스택으로 잠깐 이동된다.

즉 feat1과 내가 분기해서 가져온 로컬 develop 브랜치간의 차이가 없어지고 

다른 브랜치로 이동할 수 있게된다.

 

 

 

다른 브랜치에서 작업을 끝내고 다시 feat1로 돌아와서 내가 옮겨 두었던 변경사항들을 불러오고 싶다면

git stash apply

를 해주면 된다.

 

 

 

단, 이때 스택에 여러개의 stash된 내용들이 쌓여있다면 가장 최근에 stash된 내용이 꺼내와지며(이 경우 stash@{0})

 

 

꺼내와졌다고 자동으로 pop되지 않기에

git stash drop

을 통해 꺼내온 stash 내용을 지워주어야 한다.

 

 

 

 

참고:

https://media.fastcampus.co.kr/insight/why-blockchain-is-hard/

블록체인에 대해 전반적인 그림을 그리기 위해 조사하며 얻은 얕은 지식입니다.


 

1. 어디에 저장?

노드에 저장된다

블록체인을 설명할때 주로 블록은 데이터베이스, 체인은 체인 이라는 표현을 한다. 

블록에 정보를 저장하고 체인형태로 쭉 이은 구조이기 때문인데,

이러한 탈중앙화 구조로 인해 해킹에 안전하다고 한다.

 

그런데 문뜩 궁금해졌다. 거래내역과 같은 정보들은 블록에 저장된다고 하는데,

그럼 이 블록은 실제로 어디에 존재하는 것일까?

무엇이 됐든 물리적인 저장 공간은 있어야 기록이 계속 유지되지 않는가?

어딘가의 서버에 존재하면 그것은 중앙화된 구조기에 말이 안되지 않는가?

 

 

 

 


2. 블록체인 노드

블록들은 노드에 저장된다.

노드라는 단어를 많이 들었지만 정확히는 잘 몰랐다. 

우선 암호화폐 시장은 3종류의 사람들로 구성된다.

  1. 채굴자 (컴퓨터로 암호를 풀고 블록을 생성할 권한을 얻음)
  2. 소비자 (생성된 코인을 가지고 거래를 함)
  3. 네트워크 참여자 (거래가 안전한지 검토하고 승인하는 관리자)

이때 네트워크 참여자들이 사용하는 기계를 노드라고 한다.

노드는 새로운 블록이 생성되면 그 블록이 안전한 거래인지 검토하고 승인하는 역할이다.

데이터를 다운로드할 수 있는 모든 종류의 전자기기는 노드가 될 수 있다.

즉, 모든 스마트폰이나 데스크탑 PC가 노드가 될 수 있다. 

 

노드가 되려면 블록체인 네트워크에 접속하면 된다.

블록체인 네트워크에 접속하려면 데이터(블록)를 다운받거나 지갑을 생성하는 등의 행위를 의미한다.

이런 노드는 전 세계에 무수히 많이 있기에 탈중앙화었다고 말할 수 있고, 이를 해킹하기 위해선 전세계의 스마트폰과 데스크탑을 해킹해야 한다는 말이 된다.

 

검증의 원리와 과정은 다음 포스팅으로 알아보도록 하자.

 

 

 

 


3. 노드의 종류

노드는 풀노드라이트노드로 구분할 수 있다.

더 많은 종류의 노드가 있긴하지만 일단 대표적인 종류부터 알아보자.

 

 

1. 풀노드

풀노드는 모든 기능을 다 가지고 있는 노드이다.

이때 모든 기능이란

  • 지갑
  • 채굴
  • 데이터베이스
  • 라우팅

을 의미한다.

풀노드는 최초의 블록부터 최신의 블록까지 모든 블록을 가지고있다.

따라서 독자적으로 어떤 거래에 대한 검증을 할 수 있다.

모든 블록을 저장하고 있어야하기에 저장공간이 많이 필요하다.

 

비트코인의 경우 최초블록(제네시스블록)부터 현재의 블록까지 모든 정보를 저장하기 위해서는 200GB 이상의 용량이 필요하다고 한다. 

 

이곳에서 소프트웨어를 다운로드받으면 풀노드가 될 수 있다.

https://bitcoin.org/ko/download

 

다운로드 - Bitcoin

Bitcoin.org is a community funded project, donations are appreciated and used to improve the website. Make a donation

bitcoin.org

 

2. 라이트노드

라이트노드는 블록체인의 모든 블록을 가지고있지는 않다.

따라서 풀노드보다 요구되는 저장용량이 적다.

헤더정보만 가지고있는 일종의 요약본이다.

라이트노드도 거래는 가능하다. 다만 거래에 대한 검증은 불가능하다.

검증을 하기위해 풀노드에 검증된 거래인지 머클트리를 통해 확인하는 요청이 필요하다.

이를 SPV(Simple Payment Verification)라고 한다.

 

 

 

 

참고:

더보기

 

아침에 노트북을 켜서 보니 갑자기 안뜨던 에러가 떴다.

 

npm install --g eslint

 

를 해주고 인텔리제이를 재실행했더니 해결됐다.

 

(권한문제가 발생하면 sudo를 사용하자)

+ Recent posts