DappRadar

 안녕하세요. 박연구원입니다.

 오늘은 DAPP 서비스 순위를 한눈에 볼 수 있는 사이트를 소개시켜 드리겠습니다. 내부에서 이더리움기반의 ERC_20 토큰을 활용하여 플랫폼 서비스를 만들고 있습니다. 

 기획자가 DAPP서비스를 기획한 후에 런칭 및 참고하기에도 좋고, 다양한 DAPP 서비스를 분석하여 서비스 Plan을 설계하는데 도움이 될 수 있을거라 판단됩니다. DAPP 서비스를 이해 하시려면 [블록체인]DAPP의 구동방식 을 참고해주세요.

블록체인을 기반으로 서비스를 설계한다는 것이 다소 생소하지만 사이트를 보시면, 국내 보다는 해외 서비스에서 보다 더 활발하게 생성되고, 활성화 되어 가고 있다고 판단이 됩니다. 

1. 다음과 같이 총 3개의 코인의 DAPP들을 한눈에 볼 수 있습니다.

• 이더리움(ETH) DAPP 순위
• 이오스(EOS) DAPP 순위
• 트론(TRON) DAPP 순위

[DappRadar] DAPP 참고사이트 주소 : https://dappradar.com

(DappRadarMAIN_화면)

2. 현재 이더리움, 이오스. 트론등과 같은 코인 중에 실제 DAPP 서비스가 활성화 되고 있는 방향을 볼 수 있습니다. 이더리움의 1위의 DAPP 서비스는  My Crypto Heroes 가 1순위로 되어 있네요. 

보는 방법으로는 24시간 기준으로 약 3천명 정도 사용자가 가입했고, Transcations 또한 3천 600명으로 높군요. 이 서비스는 게임서비스인것 같습니다. 이더리움은 24시간 기준 119.05(ETH)를 사용한 것은 한화로 약 1500만원의 이더리움이 발생한 것으로 한달에 4억정도 가치가 발생했다고 볼 수 있습니다.

https://dappradar.com

안녕하세요. 감성 IT : 박연구원입니다.

이번에는 이더리움 기반의 서비스를 기획할때 가장 고민이 되는 부분에 대해 논의해 볼까 합니다.

현재 연구소에서 서비스 기획일을 하고 있으며, 이더리움 ERC20의 기반한 DAPP 서비스를 기획하면서 기존의 앱/웹 서비스와는 다른 블록체인 기획을 접하며 경험한 내용을 공유합니다.

이더리움을 이해하는 핵심 중 하나인 가스(GAS)와 머클 패트리샤 트리(World State)가 있습니다.

1. 가스(GAS) 란?

 정의는 연료를 의미합니다. EVM 상에 트랜잭션을 동작시키지 위해 소모 비용(GAS)을 말합니다.

비트코인의 수수료 개념에서 진화된 형태이며, 코트의 복잡성에 따라 다르게 측정합니다.

#GAS

단위 : Gas 21000Gas (최소의 비용) 

단위: 원 : 약 3.5원 (2019.01.03 ETH = 169,000원 기준)

 ETH 와 가스 변환 공식에 대한 부분은 이더리움 단위와 환산표 을 참고해 보시면 됩니다.

2. 가스(GAS) 측정 방법은?

 DAPP 서비스를 기획하고 개발하고 있다면, 기획자/개발자가 가장 고충을 겪는 부분일 거라 생각이 됩니다. 가스를 계산하기 위해서는 총 3가지의 개념이 필요합니다. 가스를 설정하기 위해서는 이더리움이라는 코인의 개념을 알아야 합니다. 블록체인 서비스 기획자가 알아야할 기본적인 상식 Part-1 를 참고해 주세요.

#GAS&ETH

 "DAPP 서비스를 기획시 일반적으로 가스(GAS)를 누가 낼 것인가가 가장 중요한 핵심 입니다."

<이더리움 사용가스 조회 참고 / 참고사이트 : https://ethgasstation.info>

 일반적인 Web 사이트와는 다르게 이더리움 기반 DAPP 서비스는 블록체인상에 올라갈 경우 가스(GAS)가 발생됩니다. 이부분의 기획과 설계를 잘해야만 문제점이 없습니다. 만약 플랫폼 제공자가 블록체인상에 올라가는 가스(GAS) 비용을 전부 부담한다면, 사용자가 많아짐에 가스(GAS)가 많이 사용됩니다. 그러면 이더리움(ETH)의 보유량 또한 많은 소비를 이루기 때문에 플랫폼 제공자는 부담을 느낄 수 밖에 없습니다. 그래서 트랜잭션 처리시 꼭 인지하고 기획해야 됩니다. 모든 데이터가 다 블록체인화 되면 문제의 소지가 있기 때문에, 어떤 정보를 블록에 담을 것인가?.그래서 다음과 같은 상반된 개념이 있습니다. ON/OFF Chain 의 개념입니다.

 ON Chain : 블록에 담을 것 

 OFF Chain : 블록에 담지 않을 것

#트랜잭션

 트랜잭션을 수동으로 보내려면 함수의 인코팅 된 매개변수를 번환. Web3.eth에 트랜잭션을 전송하는 시뮬레이션을 보면 전송하는 Data의 용량에 따라 가스의 전송도 변환되어 전송이 가능하다.

 3. 기획자가 바라보는 가스(GAS)의 정의 

  상위 가스에 대한 내용을 어느 정도 이해했다면, 다시 근본적인 문제점을 가지고 고민합니다. 여러 블로그에서 소개해준 가스 비용 정산 및 트랜잭션에 대한 내용을 담기보다는 기획자가 생각하고 고민해야 되는 부분의 고충을 적어 보았습니다.

#블록체인 #서비스기획자 #토큰이코노미

● 다음과 같은 질문 사항에 대해 스스로 답변이 가능해야 합니다. (기획)

 1. 블록체인에 꼭 담을 내용인 것인가? (토큰 이코노미에 대한 설계가 있는가?)

 2. RDBMS로 관리해도 문제 없는 사항인가? ( 반드시 On Chain화 시킬 필요가 있는지? ) 

 3. GAS를 내는 사용자는 누구인가? (플랫폼 or 사용자)

 4. 런칭시 확보해야 되는 이더리움은 얼마인가? (초기 GAS 비용)

2018/09/17 - [블록체인/블록체인 서비스 기획 일기] - [블록체인] DApp의 구동환경

2019/01/31 - [블록체인/블록체인 서비스 기획 일기] - [블록체인] 서비스로 성공할 수 있을까?

[블록체인 기획] 샤딩(Sharding)&이더리움

◎샤딩(Sharding)이란?

전통적으로 관계형 데이터 베이스에서 데이터를 분할하는 기술이다.

◎이더리움(ETHEREUM) 샤딩의 이유는?

메인엣을 여러 개의 작은 네트워크들로 분할하여 이더리움의 확장성을 확보하기 위함.

1) 이슈

•  

          기술적 운영적 측면에서 최적방안 탐색 및 선정의 이슈가 있다.
•         코인 이코노미 측면 참여자의 이해 관계의 이슈가 있다.

2) 현황

•         활발한 연구 및 프로토타입 코드의 실험 단계이다.
•         본격도입을 위해서는 이더리움재단 내부합의 및 기존 노드운영자들의 합의가 필요하여 상당한 시간이 소요될 것으로 예상된다.

3) 고려사항

•         현재 네트워크 노드 부담하는 하드웨어 비용증가를 고려해야 
•         하위 네트워크 내부 트랜잭션에서 기존 트랜잭션의 방식 사용성이다.
•         네트워크 간 트랜잭션은 트랜잭션 요청 영수증 기반처리에 대한 부분을 고려해야 한다.

◎샤딩(Sharding) 블록체인 형태

◎샤드 간 트랜잭션

•         중앙화 이슈.
•         보안성 이슈.
•        1% attack : 100개 샤드 시스템으로 오직 1%의 hash rate로 샤드 지배 가능성이 있음.
•        샤드 간의 커뮤니케이션이 너무 빈번하게 일어난다면, 커뮤니케이션으로 인한 시간 지연의 문제가 발생함.

• 네트워크 샤딩
• 트랜잭션 샤딩
• 스테이트 샤딩

1) 네트워크 샤딩

•         임의로 네트워크가 무작위로 느드를 샘플링하여 블록 단위로 샤드를 형성하는 것이다.
•         네트워크가 샤드의 구성원에 대한 동의를 구하지 않아 구성원들이 원하는 방향으로 가지 않는 경우, 구성원들의 불만을 해결하지 못한다는 단점이 있다.

2) 트랜잭션 샤딩

•         트랜잭션 해시의 마지막 몇 비트를 기반으로 샤드를 결정하고 트랜잭션의 유효성을 확인한다.
•         사용자가 악의적인 경우, 동일한 두입력이지만 출력이 다른 트랜잭션을 생성할 수 있다.
• 이중 지출을 방지하기 위해 유효기간이 진행되는 동안에 샤딩이 된 조각의 노드들간의 통신이 필요하다.

3) 스테이트 샤딩

•         Account-based model 이다.
•         상태가 지정된 블록체인에서 특정 샤드는 상태의 일부만을 유지한다.
• 교차분할 트랜잭션을 수행하지 못하도록 제한됨.
• 시스템의 상태가 모든 샤드에 복제되어 있지 않기 때문에 네트워크는 더이상 오프라인 샤드에 대한 트랜잭션의 유효성을 검사하지 못하게 된다.
  
• 오프라인 샤드를 유지하기 위해 백업 노드를 갖게된다면 중앙집중식이 되어 보안성에 위협이 된다.
• 네트워크가 한 번씩 재편성될 때 한번에 네트워크를 전환하게 되면 일부 동기화가 완료될 때 까지 전체 시스템을 사용할 수 없게 될 수도 있다.

◎샤딩(Sharding) 관련 과제

1) 난수생성

 난수를 사용하여 검증자를 샤드에 배정하는데, 공격자가 난수를 예측하거나 조작할 수 있다면, 샤딩 보안에 문제가 생길 것이다. 기존의 RANDAO 난수 생성방식을 VDF(Verifiable Delay Function)를 통하여 개선하는 중이다.

2) 빠른 샤드 전환

 샤드에 대한 공격 성공 가능성을 줄이고자 한다면 검증자를 빠르게 전환해야 한다. 이를 위하여 이 전부터 터 look ahead time을 두어 검증자가 자신이 맡을 샤드 블록을 미리 동기화 시킨다. 미리 동기화하기 위해서는 동기화할 자료를 줄여서 빠르게 검증자를 준비할 수 있는 stateless client를 제안한다. stateless client는 블록 헤더만을 저장한다. 하지만 블록헤더만을 저장하기 때문에 거래에 대한 검증은 불가능하다. 거래 검증을 하려면 거래를 만들 때, 검증에 필요한 witness를 첨부해야 한다. 아니면 영지식을 사용하여 witness의 크기를 줄이는 방법도 제안되었다.

3) 자료 가용성

 만약 모두가 stateless client라면 블록의 내용을 손실할 수 있다. 그렇기 때문에 누군가는 state를 저장하고 있도록 해야한다. 이를 위해 적절한 보상과 검증 (Proof of Custody)가 필요하다. Fisherman 딜레마는 Erasure Coding으로 해결 가능하다.

4) 검증자간 효율적인 통신

샤드 배정이 자주 바뀌는 상황에서 샤드 검증자들끼리의 효율적인 P2P 통신은 필수적이다. 이를 위해, libp2p의 floodsub와 gossipsub (meshsub)이 사용된다.

5) 샤드 간 비동기 통신

거래 당사자나 스마트 계약이 여러 샤드에 나누어져 있다면 샤드 간의 통신(cross-shard communication)이 필요하게 된다. 하지만 여러 단계를 거치게 되므로 시간이 오래 걸리므로 결국 메인 체인에 무리를 주게되고 이렇게 샤드 간 통신이 너무 자주 일어난다면 샤딩이 가지고 있는 장점은 사라지게 된다. 이에 이더리움은 crosslink를 가지고 메인체인의 무리를 덜고, yanking으로 필요한 스마트 계약을 현재 샤드로 가져와 샤드 간의 통신을 줄이고자 한다 .또한 현재 지연상태 전이 (delayed state transition)을 통한 샤드 간의 비동기 통신도 구상 중에 있다고 한다.