HAMA 블로그

블록체인 계층도 

블록체인을 구분하기 위해 위의 그림을 그려보았으며, 해당 그림에서 노란색 콘소시엄 체인 부분과 녹색의 일반DB의 차이점에 대해서 테이블로 세밀히 구분해 보았습니다.

분산장부 vs 분산DB 

이더리움의 스마트 컨트랙트 vs  하이퍼레저 패브릭의 체인코드 를 분석해보았다.

개인적으로 비트코인,이더리움만 블록체인 플랫폼이라 생각하지만, PBFT나 DPos를 사용한 체인들도 불록체인이라 말하는 사람들에 대해 틀렸다라고 말하지도 않는다. 네트워크 참여가 제한된 콘소시엄형 블록체인 (분산장부라고도 말하는)은 나름 "신뢰비용" 을 줄이는데 잘 사용 될 수 있는 자질을 가졌으므로 이것들 또한 블록체인이라고 불리는데 이제는 순수탈중앙주의자 빼고는 업계에서 합의를 한 분위기인거 같기도 하다. 당장의 호구지책도 중요하니까. 가끔 분산장부와 분산DB가 무슨 차이냐라고 묻는 사람이 있는데 이것도 큰 차이가 있는데, 첫째 악의의 노드(비잔틴)를 감안하냐, 둘째 불변이 필수적인 데이터만 저장되느냐, 마지막 세째가 바로 여기서 심플하게 이야기할 거버넌스 문제이다. 

최근 공공기관이라든지 여러 블록체인 SI사업들이 활발히 진행중인데, 여기서 사용 할 만한  플랫폼은 하이퍼레저패브릭이 거의 필수라고 나는 생각한다. 이유는 쿼롬이라든지, 기타 기업차원에서 만든 (패브릭기반이 아닌) 것들은 거버넌스 작동에 대한 철학이 없으며 지원 또한 거의 없다. 반면에 하이퍼레저 패브릭은 처음부터 이 거버넌스의 중요성에 집중하였다. 거버넌스 비용을 최소화 해야 콘소시엄 블록체인을 사용하는 유일한 이유인 "신뢰비용"을 줄일 수 있을 것이며, 거버넌스에 집중해야 새로운 비지니스 모델을 만들 수 있으며 기업들은 그에 따른 이득을 얻을 수 있는 것이다. 하이퍼레저 패브릭 콘소시엄 블록체인은 거버넌스를 유연하게 만들어주어 이것을 가능하게 해주며,(물론 참여자들의 노력기반하에)  이것의 중요성을 알고 지원에 집중하고 있다. 물론 거버넌스가 아예 없는 시스템도 만들 수 있겠지만 , 이 정도면 이제 블록체인이라는 말을 쓰면 안되는 단순 분산DB일 뿐 일 것이다. 

참고로 이더리움,비트코인 같은 퍼블릭체인에서의 거버넌스은 순수히 네트워크 프로토콜 상의 보상/조정 시스템에 의해서 돌아가며 모든것이 오픈되어있다. 따라서 좀 더 보안이 필요하며 세밀한 제어가 필요한 영역에서는 사용하기 힘들다.  

그럼 콘소시엄 블록체인에서 거버넌스란 무엇일까?

1. IT 거버넌스

이것은 IT인프라 종류,성능,보안,배포전략등에 관한 이슈를 네트워크 참여자들의 요구에 맞추어 구성,업데이트 해가야 하는 것을 말한다. IT SLA,OSS,BSS등에 대한 최적화 전략과 합의가 필요하다. 

2. 블록체인 네트워크 관리

IT거버넌스와 비슷한데, 네트워크 참여 및 비용에 관한 이슈에 집중되어 있다. 네트워크에 트랜잭션을 보낼 수 있는 사용자들을 참여/탈퇴/리소스제한에 대한 규칙을 지정하며, 네트워크 사용 및 스토리지 사용 비율에 따른 적절한 비용 분배 규칙도 지정해야 할것 이다.  

3. 비지니스 네트워크 거버넌스 

네트워크 공동체가 필요로한 사업모델을 수립하고 KYC절차,감사,보고등과 같은 네트워크에서 공통으로 공유하는 서비스 관리 및 법률/규제 준수 보장 전략을 수립해야한다. 콘소시엄 블록체인은 참여자들의 다양한 의미의 수익을 위해서, 공동 창조를 가능하게 해주는 플랫폼이며, 이를 위해서는 각 노드들의 적극적인 참여가 반드시 필요하다고 볼 수 있다. 

이런 거버넌스를 이루기 위한 네트워크 모형 중 아래는 설립자 주도형 네트워크 인데 

현재의 많은 프로젝트들이 이 수준에 머무르고 있다. 턴키를 받아서 "을" 회사에서 주도적으로 만들어 상납하는 구조이다. 네트워크의 참여자들 간의 거버넌스는 전무하며, POC 개념에 머무르고 있는데 좀 더 성숙함에 따라서 거버넌스의 중요성이 떠오를 것이며, 이것을 편하게 만들어주는 UI/UX도 절실할 것이다. 이런 적극적인 거버넌스 참여 없이는 프로젝트는 단발성에 그칠 수 밖에 없으며, 진정한 수익을 거두기도 힘들 것이다. 

참고)
Hands-On Blockchain with Hyperledger:

매우 길고 복잡한 글을 썼으나 5년만에 지웠습니다.
다시 읽어보니 재밌긴 한데, 그 글을 읽는 분들에게 복잡함을 더 가중 할 수 있겠다 싶어서요..
그냥 핵심만 잘 정리된 아래 링크로 대신해서 새 글을 올립니다. 
문자열 포맷 및 자바/웹개발에 대한 역사가 깊어서 인지 너무너무 복잡하죠. ㅎㅎ

Guide to Character Encoding
www.baeldung.com/java-char-encoding

[Spring] Spring UTF8 한글 설정하기
gmlwjd9405.github.io/2019/01/01/spring-utf8.html  

한글 인코딩의 이해 2편: 유니코드와 Java를 이용한 한글 처리
http://d2.naver.com/helloworld/76650

인코딩(Encoding)에 대한 이해 - (3) JSP 에서의 인코딩 설정 및 한글 매개변수 가져오기에 대한 고찰.  
http://okky.kr/article/284291

인코딩(Encoding)에 대한 이해 - (1) ASCII 부터 UTF-8 까지의 변화.
http://okky.kr/article/283470

JAVA String의 Encoding 과 Decoding에 대한 개념 정리
http://nomore7.tistory.com/entry/JAVA-Encoding-%EA%B3%BC-Decoding%EC%97%90-%EB%8C%80%ED%95%9C-%EC%A0%95%EB%A6%AC    

패턴은 추상적인 "의도"를 보다 명확한 의미로 "규정" 을 짓습니다.
패턴을 사용하는 이유와 공부하는 이유는 아래와 같습니다.

- 그로 인해 선배로 부터 값진 경험을 물려 받게 해 줍니다. 
- 그로 인해 의사소통을 원할하게  만들어 줍니다.
- 그로 인해 자신의 생각에 확신을 갖게 합니다.
- 그로 인해 장점과 단점을 드러내 줍니다. 모든 패턴에는 장점과 단점이 있습니다. (모든 기술도 마찬가지)  
- 그로 인해 연관 패턴들과의 계층적 구조를 보여주어 큰 규모에서의 설계를 가능하게 합니다.
- 그로 인해 시야가 넓어집니다. 
- 그로 인해 이름 짓기 능력을 발전 시킬 수 있습니다. 
- 그로 인해 추상화 & 모듈화 능력을 발전 시킬 수 있습니다.

이제 다양한 패턴들에 대한 이름과 의도에 대해서 정리 해 보겠습니다. 

Gof 디자인패턴 

Creational 

Sturctural

Behavioral

켄트백 구현 패턴 

멀티쓰레드 디자인패턴 

POSA-2 (네트워킹) 디자인패턴 

이벤트 핸들링 패턴 

Synchronization Patterns

Concurrency Patterns

POSA-3 (리소스) 디자인패턴 

Resource Acquisition

Resource Lifecycle

Resource Release

메세지 큐 디자인패턴 

마이크로서비스 디자인패턴 

엔터프라이즈 어플리케이션 디자인패턴 

Spring 프레임워크 디자인 패턴  www.baeldung.com/spring-framework-design-patterns

J2EE 프리젠테이션 패턴 

J2EE 비지니스 티어 패턴 

기업통합 디자인패턴 

데이터 모델 패턴

DDD 디자인패턴 

빅데이터 디자인패턴 

메모리 매니지먼트 디자인패턴 

데이타 베이스 디자인 패턴 

React 에서 사용되는 패턴 

패턴매칭 (데이터 분석) 디자인패턴 

크립토 이코노미 디자인패턴 

크립토 보안 디자인패턴 

이라는 후배의 질문에.....그냥 이 얘기 저 얘기 두서없이 주절거려 봅니다. 

------------------------------------------------------------------------
세상은  하나를 얻으면 하나를 버려야 한다고 합니다.
다 사람사는 곳이라.. 여러 생각들이 바람처럼 부드럽헤 흐르다가도 부딪히기도 하고 그렇습니다.

회사는 먼저 동호회가 아닙니다. 가족같은 회사, 친구같은 회사는 결국 문제만 생깁니다. 
따라서 아래 원칙만 지키시고, 중심을 잡으세요. (저도 못하는 것들 이고 저에게 하는 말이기도..)

1. 모두에게 친절하고 상냥하게 대한다. 조금은 손해보고 살자. 
2. 일과시간엔 적어도 6시간은 일에 초집중 하고 공유한다. (다만 일을 더 잘하기 위한 휴식같은건 필요합니다.) 
3. 특정 밥친구, 술친구, 커피, 담배 동료를 두지 않는다. 

회사에는 2,6,2 법칙이 있다고 합니다. 

자신을 좋아하는 사람 2
무신경한 사람 6
싫어하는 사람 2

모든 사람도 예외가 없습니다. 

님이 일에 에너지를 쏟는것으로 중심을 잡았으면 사람 (윗분이건 아랫분이건) 신경 쓰지마시고, 밀고 나가세요. 좀 외로워 질수도 있지만 두마리 토끼를 다 가질 수 없어요. 원칙,중심이 중요합니다. 한번 결과가 안 좋았다고 해서(야근안한다고 짤렸다? 실수가 있었다등 ) 원칙을 옮기지 마세요. 그럴수도 있지하고 쿨하게 넘기세요.  원칙을 옮기지 마세요. 그리고 사람에게 에너지를 쏟으면  인기인이 될 수도 있겠지만 불필요한 오해가 생길 수도 있습니다.  즉 다른 토끼를 놓치게 되는 것이 인지상정입니다. 

명확한 이유/보상이 동반되지 않은 "야근" ......님이 열심히 일 했으므로 눈치 보지 마십시요. 원칙대로 살면 ..스스로 떳떳하면 된 것입니다. 전 부장인데 6시 전에 퇴근하며, 다른 직급 분들은 야근하는 분들도 많은 거 같습니다. 저는 일찍 출근해서 일찍 가는 것을 좋아하고 늦게 출근해서 늦게 가는걸 선호하는 사람이 있을 뿐입니다. 강요하는 회사는 어차피 님 수준 보다 낮으니 미련두지 마세요

모두에게 시간은 똑같이 부여되나 사용하는 방식은 다릅니다.  스스로 명확하게 시간관리를 하게 되면 남들보다 더 많은 것을 얻을 수 있는데, 남 눈치보면 결국 인생의 많은 시간을 낭비하게 될 것입니다.
 
나이먹고 직급 높아지면 더 눈치보게 되는게 인생입니다. (꼰대는 나이랑 상관없어요.상황이 안그런 인간을 그렇게 만들기도 하고...아니기도 하고...저도 엄청 꼰대였다가 아니었다가 그럽니다.) 젊을 수록 기회도 많습니다. 요즘은 야근 강요하는 회사가 없어지고 있으며 점점 더 그럴 겁니다. 옮길 좋은 회사가 많아지고 있으니 실력을 쌓으시고 자신감 가지시고 화이팅 합시다.

현대 프로그래밍에서 가장 중요한 오류들인 동기화 문제( 레이스컨디션이나 데드락등 )는 C++같은 언어로 개발한 제품들에서 굉장히 많은 문제를 발생시키곤 한다. 윈도우즈 오류의 대부분이 동기화문제, 메모리관리 문제라니까..

그중 동시성에서 레이스컨디션 문제는 
1. 가변변수인데 게다가 동시접근가능 할 때 발생된다.

즉
2. 가변변수가 없거나 ㅡ 순수함수형
3. 동시접근예방 ㅡ Actor패턴 , CSP (예방이지 불가는 아님)

둘 중 하나만 충실 하면 근본적으로 없앨수 있다는 얘기이다. 

1번 경우는 뮤텍스등을 통해 직접 보호 장치를 해야 하는데 , C++,Java, Go 같은 착한 (방종 or 자유로운) 부모하에서 인간의 실수는 비일비재 하다. 배움이 모자르고 막나가는 아이들도 생겨남.

근데 러스트는 엄한부모라 자식 (프로그래머) 에게 관련 지식(스마트포인트류,LifeTime,RefCell등등)을 강제 요구하고, 각종 메모리를 사용하는 규칙이 이미 단단히 정해져있기 때문에  오류가능성을 컴파일 타임에 알려준다.

만약 팀을 결성하고 C++만큼 빠른 성능에 다가 무엇인가 오류없는 결과물을 만들고자 출발 할 때, 러스트를 선택하면 팀내에 최소한 막나가는 아이들은 없다는 안도감은 가질 수 있겠다. 

1. 메모리에서의 안전요소

https://medium.com/a-journey-with-go/go-memory-safety-with-bounds-check-1397bef748b5

https://insanitybit.github.io/2016/12/28/golang-and-rustlang-memory-safety

* Go에서 디폴트로 지원하지 않아서 Go는 메모리세이프한 언어라고 하기 좀 머하다는 Address Space Layout Randomization (ASLR)이란?

https://blog.stalkr.net/2015/04/golang-data-races-to-break-memory-safety.html

2. 웹서비스에서의 안전요소

https://blog.sqreen.com/top-6-security-best-practices-for-go/

3. 동시성에서의 안전요소

https://medium.com/@sargun/go-concurrency-considered-harmful-26499a422830

https://medium.com/dm03514-tech-blog/golang-candidates-and-contexts-a-heuristic-approach-to-race-condition-detection-e2b230e70d08