기본 콘텐츠로 건너뛰기

블록체인 기술의 취약점 및 고려 사항

요즘 많은 백서의 기술 검증을 하고 
여러 ICO에서의 설명을 듣고, 

Github에서 소스를 내려받으면서 
실제 소스를 보고 있습니다. 

Genesis 블럭은 어떻게 만들고 있는지?

기본 구조는 몇 세대 체인 구조를 가지고 있는지?

DAG이 최선?

고속 합의 및 용량 제약을 풀어낸 
DAG이 IOTA덕분에 좀 활기를 치고 있지만, 

최초의 DAG Whitepaper에서도 언급했던 것 처럼

이건 이론일 뿐이고 실제로는 어떻게 될지 모릅니다. 

즉, 현재 국내 DAG구조를 발표한 백서에서 
DAG원래 취약성의 보완 방법을 언급한 Whitepaper는 못봤습니다. 

블록체인이 최고인양, 

블록체인이 최첨단 기술인양

자기의 비즈니스를 
억지로 구겨넣고 있는 모습을 많이 봅니다. 

블록체인은 어떤 단점이 있는지조차 모른채..

블록체인의 중요한 단점은 다음과 같습니다. 

1. 블록체인은 Transaction이 느릴 수 밖에 없다!

요즘 들어 TPS(transaction per second, 초당 처리수) 우위로 
광고하는 블록체인들이 늘고 있습니다. 
5000TPS? 어떻게 그렇게 구현할 수 있죠? 
github에 구조좀 공개해 주세요! 

5000이라고 얘기한 것은 아마 
Open source RDB의 TPS허용량을 
기준으로 얘기한 것일 겁니다. 
 그렇다면 그냥 RDB라고 하지.. 

블록체인은 구조상 
네트워크로 요청을 보내서 
여러 네트워크에 오는 결과의 
정합성을 검증하여 참을 가리는 
합의 프로토콜을 가지고 있습니다. 

즉, 아무리 가까운 곳에 있다 하더라도
수 천대의 머신에 연결을 하려면, 
최소 수 백개의 L2장비가 필요하고, 
그 L2장비를 연결하는 
 수 십 또는 수 대의 대형 패치 패널을 보유한 
백본 사이즈 네트워크 기기가 필요합니다. 
이건 가정이므로.. 
이게 아니고 일반 유저의 Miner를 사용한다면

최소 20홉 이상의 네트워크 밖으로 
던져서돌아오는 것을 기다려야 합니다. 

만일 모든 마이너가 
수퍼 컴퓨터 급으로 0.1초 이내에 응답을 한다 
할지라도 
Network Latency(네트워크 지연)에 의한 시간에 의해 
최소 1초 이상 소요 됩니다. 
하지만 실제로는 이게 
1분 이상 소요되는 케이스가 더 많지요. 
왜 블록체인이 느릴 수 밖에 없는지를 
이렇게 설명하시는 분은 안계시네요. 

그 외에 
합의 알고리즘 도출 구조니 뭐니 하는 것은 
컴퓨팅 사양에 의해 얼마든지 단축 가능하니 생략합니다. 

2. 블록체인은 정합성이 완벽하지 않다.

많이 사고가 나는 것을 보았지요? 
지금도 무수하게 데이터 유실은 일어나고 있습니다. 
모 데이터에 의하면 이미 

블록체인 네트워크 상에 유실된 자산은 4조

가 넘었다고 합니다. 

NoSQL이 처음 나왔을 때와 비슷하네요. 

NoSQL은 내장애성, 확장성을 고려한 대신에
Relation과 Verification을 포기하였습니다. 
물론 0은 아닙니다. 
최대한 보정을 해주었으나 
데이터 유실에 대해 책임을 지지 않는다는 내용이 
항상 EULA(End User License Agreement)에 들어있습니다. 

블록체인과 마찬가지로 
네트워크 상에 데이터를 뿌리는 방식은 
언제나 정합성의 이슈를 가집니다. 
 이 정합성을 100% 지키기 위해서는 
DTC(Distributed Transaction Coordinator)같은 것으로 
묶어줘야 합니다.  
이 기술은 엄청나게 고도화된 기술로 
성능 저하를 감수하고 
데이터 정합성만을 위해서 
복잡한 구성을 가지게 됩니다..
(사실 개념은 쉽지만, 
거의 모든 예외상황에 모든 노드의 Rollback을 
DTC가 관장해야 하므로..) 
그렇기 때문에 
RDB에서조차 속도를 중요시할 때 
DTC를 꺼놓게 됩니다. 

그럼에도 불구하고 RDB처럼 쓰겠다? 

우선 데이터 저장 구조를 이해하고 시작하셔야 겠습니다. 

3. 토큰(코인) 데이터와
비즈니스 이력 데이터를
같이 저장할 수 있는
케이스는 드물다.

많은 ICO에서 웃게 만드는 내용이 바로 이 것입니다. 

ICO를 한다는 것은 토큰(코인)을 발행한 다는 것이고, 
이를 이용하여 자기의 비즈니스의 이력을 관리하겠다고 합니다. 
일부 맞는 이론도 있지만, 
많은 경우가 이력을 쪼갤 수도 없으면서 
토큰과 같은 네트워크를 가져가려 합니다. 
TxID를 두 개씩 만들어서 관리할 건가요? 
그렇지 않아도 느린데.. 
만약 ERC721을 이용하여 티켓이라는 불변의 제품을 팔겠다.. 
는 말이 되는데 그럼 이력은 필요없지 않나요? 

4. 블록에 쓰여진 데이터는
전세계에 노출 됩니다.

블록에 민감성 또는 개인 정보가 들어가면 아웃입니다. 

그렇다면 암호화?? 
그래도 느린데 도대체 서비스 할 생각이 있는건가요? 

복호화가 불가능한 파괴형 암호화인 
MD5도 깨버리는 마당에 암호화 만으로 다 된다 생각합니까? 
풀블럭 내려받고 로컬에서 천천히 깨버리면 되는데 
해커들에게 이보다 쉬운 밥이 어딨나요? 

5. 블록체인은 비싸다!

많은 분들이 간과하는데요..
일반적인 시스템을 구성하였을 때에 비해
비즈니스 프로세스당 코스트
(PPC, Process per Cost)는
블록체인이 약 6~10배에 달합니다. 
하지만 왜들 이렇게 쓰냐구요?
일반 유저의 네트워크는 
비즈니스 사업자가 내지 않기 때문에
자신의 비즈니스를 위한 시스템 유지 비용을 
조금만 나눠줘도 유저들은 이득을 얻을 수 있죠. 
어짜피 사용하고 있는 네트워크와 컴퓨터이니..
전문 채굴자들도 
떨어지는 코인 시세에 한숨만 쉬고구조는 모르니 
왜 떨어지는지는 모르고..
하는 것과 마찬가지 입니다. 

6. 블록에 쓸 수 있는 데이터 사이즈의 한계 및 속도와의 문제

블록에 이것저것 때려 넣으려 하지 마세요.. 
그렇지 않아도 느린데 더 느리게 만들지 맙시다. 
블록하나에 부족해서 여러 블록에 쪼개 넣고 합친다구요? 
블록체인이 뭔지부터 공부 하셔야 겠습니다. 

...
많은 분들께 가이드 해드리고 있지만, 

자신의 비즈니스를 마음껏 상상하세요. 

Ready Player One같은거 지금도 구현 가능합니다. 
자신의 비즈니스에 기술을 맞추고 타협하지 않는 자세는 중요하지만

(잡스나 엘런처럼), 

신기술이네 뭐네 하며 

자신의 비즈니스를 억지로 껴맞추다보면 

위와 같은 문제를 간과하고 설계가 들어가고, 

결국 망하는 지름길이 됩니다. 


Do not login your server any more!
Free server management tool!

Subscribe and publish your links as a book with friends 
My Linkbook

댓글

이 블로그의 인기 게시물

Alter table 에서 modify 와 change 의 차이 :: SQL Server

두 개의 차이를 모르는 경우가 많아서 정리합니다.  modify는 필드의 속성값을 바꿀때 사용하구요.. change는 필드명을 바꿀떄 사용합니다.  alter table tbbs modify bNote varchar(2000) NULL; alter table tbbs change bNoteOrg bNoteNew varchar(2000) NULL; change에는 원래 필드와 바꾸고 싶은 필드명을 넣어서 필드명을 바꾸는 것이죠~ 더 많은 SQL Server 팁을 보려면  https://github.com/LowyShin/KnowledgeBase/tree/master/wiki/SQL-Server giip :: Control all Robots and Devices! Free inter-RPA orchestration tool! https://giipasp.azurewebsites.net/

책에서는 안 알려주는 대규모 트래픽을 위한 설계

음성 버전 :  https://www.youtube.com/watch?v=ZZlW6diG_XM 대규모 트래픽을 커버하는 첫 페이지 만드는 법..  보통 DB를 연결할 때 대규모 설계는 어떻게 하시나요?  잘 만들었다는 전제 하에 동접 3000명 이하는  어떤 DBMS를 사용해도 문제 없이 돌아갑니다.  여기서 이미 터졌다면 이 콘텐츠를 보기 전에 DB의 기초부터 보셔야 합니다.  아.. 개발 코드가 터졌다구요? 그럼 개발자를 때리셔야지요..  만약 3000명을 넘겼다면? 이제 Write/Read를 분리해서  1 CRUD + n개의 READ Replica를 만들겠죠?  보통 Read Replica는 5개가 최대라고 보시면 됩니다.  누가 연구한 자료가 있었는데...  6번째 레플리카를 만든느 순간 마스터가 되는 서버의 효율 저하 때문에  5번째에서 6번쨰로 올릴때의 성능이 급격히 줄어든다는 연구 결과가 있습니다.  때문에 Azure에서도 replica설정할 때 5대까지 밖에 설정 못하게 되어 있지요.  유저의 행동 패턴에 따라 다르긴 하지만,  1 CRUD + 5 Read Replica의 경우 동접 15000명 정도는 커버 합니다.  즉, 동접 15000명 에서 다시 터져서 저를 부르는 경우가 많지요..  이 때부터는  회원 DB, 게시판DB, 서비스DB, 과금 DB 등등 으로 성격, 서로의 연관도에 따라 나누기 시작합니다.  물리적으로 DB가 나눠지면 Join을 못하거나 Linked Table또는 LinkDB등의 연결자를 이용해서 JOIN이 되기도 합니다.  그에 따라 성능 차이가 생기지만 가장 중요한 포인트는  서로 다른 물리적 테이블의 JOIN은 인덱스를 타지 않는다!  라는 것입니다. 즉, JOIN할 테이블들을 최소한으로 만든 뒤에 JOIN을 걸지 않으면 NoSQ...

BI의 궁극판! Apache Drill을 써보자!

사실 Apache Drill 은 BI(Business Intelligence)라고 부르는 것 보다는 단순 데이터 연결 엔진이다. https://drill.apache.org/ 하지만 내가 왜 극찬을 하느냐면.. DBA로서 항상 문제가 되어왔던게, 이기종 데이터의 변환이나 처리였다. 포맷을 맞추는데 엄청난 시간이 걸리고, 데이터 임포트 실패가 무수하게 나고.. 한 번 잘못 데이터를 추출하면 다시 조정, 변환, 추출하는데 시간이 많이 걸린다. 그런데! Apache Drill은 그냥 RDB를 CSV랑 연결해서 조인해서 통계를 낼 수 있다. 그것도 표준 SQL을 사용하여! 예를 들어, CSV의 세 번째 컬럼이 price 이고, 물건의 판매이력을 PG사에서 CSV로 출력 받았다. 우리 DB와의 검증을 위해서는 수동으로 Import를 한 뒤에 포맷이 안맞아 잘리는 데이터가 있다면 다시 맞춰주고, 재 임포트를 수십 번, 그리고 나서 겨우 들어간 데이터를 조인하여 빠진 데이터를 분간한다. 숫자가 적다면 개발자가 개발로 처리할 수도 있지만, 건수가 하루에 300만건 짜리라면.. 한 달 온 파일은 9천만 건이다. 프로그램으로 고작 처리하는 것이 초당 500건. 거의 20만초, 에러 없이 약 56시간.. 에러가 생기면 다시 56시간.. ㅠㅡㅠ 이런게 현실이기 때문에 쿼리 말고는 방법이 없다. apache drill 의 진면목을 보자! 이번에는 좀 범용 적인 MySQL DB와 붙여 보자. . 난 이번에는 Mac에서 작업을 했기 때문에 그냥 다운 받아서 풀었음.. https://drill.apache.org/download/ 여기서 자기 OS에 맞는 버전을 받아서 설치하시길.. 압축을 풀고 나면 MySQL 커넥터를 붙여야 한다. https://dev.mysql.com/downloads/connector/j/5.1.html 여기서 다운로드 이런 커넥터 들을 붙일 때마다 콘피그를 수정해 줘야 하지만, 몇 번만...