Blockchain technology for enterprise service
건강 보험 등 이력에 대한 불변의 상태기록을 원하는 비즈니스에서는 상당히 유용하게 사용될 수 있다.
인센티브의 경우 네트워크 망을 유지하고 서비스에서 인센티브를 제공하는 기능을 어떻게 활용 가능한가?
Case1 분산 원장으로써의 블록체인
롯데카드 -> 블록체인 기반 생체 인증
삼성페이에서 로그인 정보를 다른 쪽에도 유지하기 위해 사용 =>
Case2 스마트 컨트랙트로써의 블록체인
현대카드 포인트 페이먼트를 스마트 컨트랙트로 구성
제일 큰 문제는 성능문제. => 추가로 컨센서스를 만드는 작업 등
신한금융 => 인증서 발급 로직을 스마트 컨트랙트로 구성
금융보안원, 금융 결제원 => 폰뱅킹 및 은행 송금 시스템
은행 송금 시스템을 블록체인화, 기존에는 중앙 시스템이 모든 은행의 거래 내역을 다 처리하고 매일 한번씩 정산하여 데이터베이스를 맞추는 식으로 햇었음
이 경우 스마트 컨트랙을 통해 했는데 역시 성능문제가 생겼음
여기서 가장 중요한 점은 고객 데이터는 데이터베이스에 올라갈 수 없음
때문에 블록체인과 외부 디비가 어떤 식으로 연동하는 것이 매우 중요한 포인트임
고객의 주요 쟁점
- 퍼포먼스 컨트랙트 내부 병렬화에 대한 요구가 나온다. 보통 컨트랙트 내에서 락을 걸어서 처리를 하는데 이 경우 처리가 빠르게 일어나지 못함
- privacy개인정보를 올리려면 어떻게? => 난스 만들어라
- Multi chain
- 익명 기술
- 파이널리티 가령 블록이 생성되어 트랜잭션이 만들어 지더라도 블럭이 폐기되면 다시 뒤로 돌아가기 때문에 고객의 지갑이 변동되는 문제가 생기며 이는 매우 큰 이슈이다,
블록체인 비즈니스 활용 Tip
사이드 체인을 유지하고 퍼블릭 네트워크와 연동하는 형태로 많이 서비스를 하게 된다.
이렇게 하면 기존 서비스의 품질을 해치지 않으면서도 블록체인을 적용할 수 있다.
가령 포인트를 적립시킨다고 하면 별도 사이드 체인을 만들어서 포인트를 등록하고 해당 체인을 다른 퍼블릭체인과 연동하여 포인트를 유통시킬 수 있다.
즉 이더 송금 수수료를 한번만 이용하지만 여러 거래를 별도 사이드체인에서 동작시키고 퍼블릭체인과 연동함으로써 해결이 가능하다.
Ex) aergo => 블록체인 sass 서비스
업그레이드 가능한 스마트 컨트랙트
투명성, 위변조 불가성
왜 업그레이드 가능한 스마트 컨트랙트가 필요한가?
- 배포 후 취약점이 발견되면 수정이 가능하다.
- 비즈니스 로직이 수정 불가하기 때문에 겪게 되는 불편함이 있다.
Delegate call 특정 컨트랙트를 통해 다른 컨트랙트를 실행시킴
조건
업그레이드로 스마트 컨트랙트 주소 안변함데이터 마이그레이션 없이 데이터보존여러 스마트 컨트랙을 한번에 배포
Proxy contract 를 만들어 버전관리를 하고 유저는 proxy contract 로 전달하고 proxy contract는 최신버전의 contract로 명령을 전달한다.
Registry contract upgrade Earl => 업그레이드하고자 하는 proxy contract의 주소를 받아온다. registry contract 모두를 업그레이드 하기 위해 registry contract를 실행시킨다.
스마트 컨트랙트 버전관리 툴
- deploy
- Registry contract 가 없으면 registry contract 배포
업그레이 가능한 스마트 컨트랙트의 이점
유저 입장에서는 스마트 컨트랙트 주소가 고정됨, 버전 정볼르 생각하지 않고 특정 호출만 계속 함개발자 입장에서는 모든 데이터가 그대로 유지되고 재사용 되게 됨업그레이드가 매우 편리함.
Token Model Design Process
토큰 모델이랑 탈중앙화 네트워크의 보이지 않는 손이다.
토큰이라는 인센티브를 가지고 경제가 어떻게 굴러가는지를 설계한다.
게임 이론
주어진 게임의 규칙에서 최선의 전략을 찾는 이론
메커니즘 디자인
모든 플레이어가 게임에 충실하게 참여를 했을 때 이를 원하는 방향으로 굴러가게 하기 위한 메커니즘에 대한 디자인
어떻게 기존의 경제 시장에서 토큰 모델을 적용시킬 것인가?
메커니즘 디자인의 기초
Agent 행동 주체
Type agent의 사적인 정보
Decision 가능한 사회적 결과의 집합
Utility function 에이전트가 특정 결과에 대해 얻는 효용
Decision function agent의 각 행동을 종합한 결정 규칙
Transfer function agent의 행동에 따라서 받거나 내야하는 돈
Social choice function
가령 마을에 쓰레기 처리장을 짓는 문제를 생각해 보자.
제일 쉬운 방법은 누군가가 모든 사람들에게 의견을 물어보는 것이다.
여기서 transfer function 은 agent의 type 에따라서 받거나 내야하는 돈의 규칙이다.
메커니즘의 특성
Efficiency
최대 다수의 최대 행복
trustfulness
모든 에이전트의 균형 전략이 자신의 type을 솔직하게 보고하는 것일때
Budget balanced
agent의 type이 바뀌더라도 메커니즘이 transfer function으로 얻는 수입이 일정할 때
메커니즘을 최적화 문제로 정의할 수 있다!!
메커니즘 최적화 적용
가령 서울의 평균 기온을 블록체인에 기록하는 메커니즘을 만든다고 해보자
- 오라클 선출 => 신뢰할 수 있는 외부 데이터를 선정한다.
- Shelling coin 많은 사람들이 준 값들의 중간값을 실제값으로 정한다.
계속해서 decision function 과 transfer function 을 바꾸어 보면서 실 데이터를 분석하여 효율적인 메커니즘을 도출해 내야 한다.
토큰 모델 디자인 프로세스
agents와 목표 행동 정의최적화 문제 설정반복메커니즘 규칙 설정규칙 변경결과 추론제약조건 변경
예시 - steemit
Object => 좋은 글의 공급을 극대화
Constraint => 초보 작가들이 글을 쓰기가 쉬워야 함, 독자들은 글을 쓸 때 돈을 내지 않아야 함 등
Decision => 추천수에 스팀 파워 가중치를 계산해 퀄리티로 인정함
Transfer =>
더 나은 설계를 위해 필요한 것들
좋은 규칙의 집합, 패턴실제 돌아가는 프로젝트에서 나오는 실증 데이터복잡한 메커니즘의 정량적 추론을 위한 시뮬레이션 툴
토큰 디자인 패턴
Incentive, curation , judgement, governance
메커니즘 디자인의 한계
닫힌 시스템을 가정한 설계이기 때문에 경쟁 프로토콜, 암호화폐 시장 등 외부 요소는 고려하지 못하기에
블록체인과 같은 완벽하게 공개된 플랫폼 내에서 어떤 사이드 이펙트가 나올지 알 수 없다.
토큰 디자이너를 위한 팁
- 플레이어가 아니라 디자이너처럼 생각하라.
- 목적과 제약조건 정의만 잘해도 반은 먹고 들어간다. => 토큰 가치 상승이 목적인가 이중 지불 방지가 목적인가, 목적과 제약조건만 확실하다면 솔루션은 얼마든지 바꿀 수 있음
- 솔루션을 decision function 과 transfer function 으로 바꾼다.
- 알고 있는 패턴이 풍부해야 문제를 잘 풀어나갈 수 있다.
화폐가치와 메커니즘 디자인은 어떻게 결합될 것인가
IOT에서의 블록체인
오프라인 데이터의 위변조를 막기 위해 가량 씨씨티비의 경우 해당 영상의 해시값을 저장하여 블록체인에 저장하고 추후 검증이 필요한 경우 해당 해시와 비교를 통해 할 수 있따.
Digital forensic => 영상 데이터의 법정에서 신뢰를 얻을 수 있음
가령 자율주행차의 경우 수동으로 운전을 했는가 혹은 자동으로 운동을 했는가가 과실에 매우 중요하다. 이를 블록체인에 실시간으로 저장하면 이를 막을 수 있다.
DAICO 모델 - 블록체인 위에서 ico 플랫폼
메커니즘
하스켈
Comments