#10. 유져 관리(1)

ㅇ서명 & 블록 & 유져 간의 상호작용

ㅇ패브릭의 유저관리

 

1) MSP, CA

 -MSP : 패브릭 제공의 멤버쉽 관리. PKI (공개키-개인키) 사용.

 -CA : 네트워크 셋업시, 오더러 피어 어드민 유져 등에게 개인키 제공, 컴포넌트에 필요한 인증서를 만들어 크립토 컨피           그에 넣어서 , 각 노드들이 서로를 인식할 수 있게 해줌. CA 인증서와 개인키 발급을 도움.

 

2) Chaincode

 -체인코드 내부에서 PKI를 새로이 구현하여 또다른 유져관리가 가능해짐.

 

서비스에 따른 유져관리 선택

 

ㅁ유저생성

 ㅇ비트코인과 이더리움은 회원가입의 개념이 없음. 오프라인상에서도 직접 개인키와 주소생성 가능.

 ㅇ패브릭은 특정기관(회사서버. CA)을 통해서 개인키와 인증서 발급을 받아야 함.(서비스 프로바이더는 회사).

 

#11. 유져 관리(2)

 ㅁ패브릭 네트워크에서 유져가 상호작용하는 3가지 방법.

 

 1. Delegated 방식 (위임하는 방식)

 ㅇBalance-Transfer 모델.

 ㅇ서버가 모든 유저의 키를 관리. (키를 모두 "위임")

 ㅇ회원 관리하는 서버가 유저 ID(token)과 인증서를 매칭하여 트랜잭션 생성.

 ㅇFabric CA를 통해 유저 생성(sign up).

< Delegated 방식 >

 

 2. Decentralized 방식 (분산하는 방식)

 ㅇdApp 모델(탈중앙화 모델로 서버를 배제함.).

 ㅇ모바일에서 유저의 키를 관리. (키를 모두 "분산")

  -유저가 인터액션을 진행하고, 그 키를 모바일 클라이언트가 소지함.

 ㅇFabric CA를 통해 유저 생성(sign up).

 

< Decentralized 방식 >

 

 3. Chaincode Level user

 ㅇ서버는 어드민 키만 소유.

  -체인코드 레벨에서 PKI를 도입해서 이용. 체인코드 내에서 유저를 인식.

 ㅇ크립토연산의 중복

 ㅇFabric CA 불필요.

< Chaincode Level user 방식 >

ㅁ자산관리

 ㅇUTXO와 Account 모델은 서로 상반됨- 

 

 ㅇUTXO 모델

  -비트코인.

  -자산우선 . 자산에 이름표를 부착함. 이름표(public key) - signature

  -fabtokken : utxo

  (1) 보안: 트랜잭션은 항상 고유한 UTXO와 연관돼 있어 높은 보안성 유지하며 리플레이 어택 방지가능.

  (2) 확장: 트랜잭션을 병렬 처리 가능하여 동시에 많은 트랜잭션을 처리가능.

  (3) 프라이버시: UTXO 시스템의 비상태(Stateless) 저장환경은 사용자들이 각 거래에 서로 다른 주소를 사용토록 함.

 

 ㅇ어카운트 모델

  -이더리움, 기존 시스템

  -명단우선 . 회원명단이 데이터베이스에 있고, 회원이름에 소유한 자산을 표시.

  (1) 단순: 계좌 모델의 전반적인 스마트 컨트랙트 기능과 DApp 실행가능.

  (2) 효율: 요청자의 계좌가 정확한지 파악하는 것으로만 유효성 검증 by TX.

  (3) 확장:  UTXO모델에선 UTXO갯수가 트랜잭션에 직접 영향 미치지만, 계좌 모델은 단지 단일 참조에만 영향받음.

 

 

#9. 패브릭 이벤트

ㅇ블록체인 상에서 발생한 사건들(블록생성, 스마트컨트랙트의 액션발생 ) 외부로 전달가능함.

ㅇ다른 네트워크의 이벤트

  -이더리움 : 웹소켓 사용하여 이벤트를 주기적 전달 받거나, RPC콜로 이벤트 질문 가능.

  -비트코인 : 자신의 지갑주소로 돈이 들어왔을  알림 기능  서버에서 SDK 사용 .

 

ㅁ이벤트. 블록이 새로 생겼다? ”

 ㅇ다양한 레벨의 이벤트 수신 가능 , SDK 이용 PEER 부터 이벤트를 수신하며-

 

  -grpc 통해서 가능한 것임. 해쉬넷grpc”

https://developer.ibm.com/kr/cloud/blockchain/blockchain-special-series/2018/11/11/hyperledger-fabric-architecture-5-%ED%8A%B8%EB%9E%9C%EC%9E%AD%EC%85%98%EA%B3%BC-grpc/

 

[Hyperledger Fabric] Architecture: 5 트랜잭션과 gRPC - IBM Developer

chaincode 작성의 최대 챌린지인 gRPC 뽀개기 얼마전에 blockchain 프로젝트 수행을 위한 회사 내부 교육을 이수했습니다. go-lang으로 chaincode를 실제로 개발하면서 가장 많이 부딪혔던 문제는, gRPC의 버전 문제와 gRPC 인터페이스 처리였습니다. 사실 gRPC 자체를 아예 잘 몰랐던 터라 어떻게 동작하는지 알기 어려워서 겪었던 문제였죠. 그래서 도대체 왜 Hyperledger Fabric은 HTTP 통신이 아니라 gRPC

developer.ibm.com

  -() fabric-samples - balance transfer - artifacts - docker-compose.yaml

    개의 포트가 열려있음. ports : 7051:7051(오더러와 소통) , 7053:7053(외부 앱과의 소통)

 

  -() fabric-samples - balance transfer - artifacts - network-config.yaml

   my channel - peers :  피어 별로 설정 가능 부분. EventSource  true ,

   SDK에서 해당 .yaml  갖고 사용할 때에 해당 피어는 이벤트를 수여 가능하다고 보고 만들기 가능.

   그럼 해당 peer eventURL  가지고 설정 하는 . : 이것이 grpc 통해서 이벤트 푸쉬 받는 것임.

 

 ㅇ이벤트 기능

  -이벤트 받을 , 시작 블록  블록 설정 혹은 블록 넘버지정으로 이벤트를 요청가능.

   놓친 이벤트도 ‘replay’ 기능으로 가져올  있다.
   block from ~ to 가능(replay 가능)

  -1.1 이후, ‘ Channel based event ’ 추가: SDK에서 해당 채널에 관련된 정보주면 채널 관련 이벤트만 SDK 받아올  있음. 유져입장에서 유용한 기능이 추가된 .

    (1.0 까지는 이벤트 허브로 이벤트 서비스를 제공해서- 채널 상관없이 블락을 정렬없이 받았음-)

 

 ㅇ엔터프라이즈 블록체인의 아키텍쳐(보통)

 

 

 ㅇ패브릭 이벤트의 종류

  -블록 이벤트: 블록 새로 생성 됐을 , 이벤트 발생. SDK에서 생성된 채널.

   Full block : 전체 내용을 가지고 .

   Filtered block : event 있는 payload 안가지고 .

  -TX 이벤트: 유져가 트랜잭션 제출 했을 , 해당 트랜잭션이 커밋 가능한 지에 대한 여부 확인.

  -체인코드 이벤트: 체인코드 내부에서  이벤트 사용 가능.

   chainCode  SetEvent(eventname, payload) : 이벤트 네임 찍고, 그것이 발생했을 때에 무엇을  것인지.

       ※이벤트 네임을 특수하게 짓든지, 식별자를 두어야 .

 0. 요약

 

이더리움은 자체 블록체인을 기반, 다양한 탈중앙화 된 어플들이 작동가능하게 고안된 플랫폼 네트워크.

 

이더리움의 디앱은 스마트 계약을 이용해 쉽고 빠르게 토큰 발행가능.

 

이더리움 블록체인에선 이더가 사용되고, 디앱은 여러 분야에 적용가능한 각각 솔루션들로 그에 맞는 토큰 발행.

 

발행된 토큰은 독자적인 토큰인 듯 하지만 실제는 이더리움 생태계에서 호환 및 사용 가능.

 

)

 ○ 안드로이드 = 이더리움 플랫폼   /    그 안에 앱들 = 디앱들.

 ○ 각 앱 사용하면서 발생되는 일정 포인트를 통합 및 사용하는 건 같은 회사계열의 앱이 아니면 불가능하지만

 ○ 이더리움 플랫폼에서는 각각의 디앱이 발행한 토큰을 통합하여 현금화가 가능.

 ○ 디앱 내에서의 토큰 교환은 물론, 이더리움 플랫폼 기반의 타 디앱의 토큰과 교환 가능한데

 ○ 이를 위해 ERC-20 토큰 표준 있는 것.

 ○ 디앱들에 흩어져있는 ERC-20 표준 호환 토큰들은 나중에 통합되어 한 번에 이더로 모두 바꾸어 현금화 가능.

 

 

 

1. 배경

 

비트코인(Bitcoin) 탄생 : ‘코인개념 생성.

 ○ 2008101세대 암호화폐. 기축 통화 (국제간 결제 및 금융거래에서 통용되는 통화. ex. )

 

알트코인(Altcoin) 탄생 : 이 당시만 해도 코인들만 존재.

 ○ 암호화폐 생태계에, 독자적 알고리즘과 생태계 소유한 여러 암호화폐들 탄생

 ○ 비트코인과 유사한 이 암호화폐를 사람들은 알트코인으로 일컫음.

 

이더리움(Ethereum) 탄생

 ○ 이더리움은 비트코인에선 제공하지 않는 스마트계약 기능 소재.

 ○ 스마트컨트랙트 기능 이용으로 이더리움은 플랫폼 코인으로 영역을 확장가능해짐.

 

. 이더리움의 (코인)플랫폼 기능?

- 마치 아이폰의 앱스토어 기능.

- 독자적인 하드웨어(이더리움)를 개발하지 않고도

- 개발자들은 앱스토어에 본인의 어플 업로드 및 판매 가능 하게 되는 것.

 

 

 

2. 목적 및 생성

 

목적

 ○ 토큰을 지분으로 투자자금 모음.

  - 메인넷 개발완료 시 토큰으로 변환.

  - 메인넷 개발 전 개발할 때 까지의 자금”, “토큰거래만 가능

  - 메인넷 개발 후 자체 네트워크 통화”, “자체기능 개발 및 배포

 

 ○ 상호 호환 가능

  - ERC-20 (기반) 토큰은 이더리움과 교환 가능 및 이더리움 지갑으로 전송이 가능.

  - ex) 안드로이드 운영체제를 사용하는 네이버 지도를 카카오톡으로 바로 공유할 수 있는 것처럼.

 

이더리움의 스마트컨트랙트로 생성

 ○ 독자적 생태계 구축없이 이더리움의 기능(스마트계약)을 이용, 암호화폐를 제작하게 됨.

 ○ 이렇게 제작된 암호화폐는 ERC-20 (Ethereum Request for Comment) 토큰이라 불림.
 ○ ERC-20 기반 토큰 : 펀디엑스(NPXS), 오미세고(OMG), 비체인(VEN) .

 ○ 이오스(EOS), 트론(TRX) 등은 이더리움 기반 토큰 생성 후, 자체 메인넷을 출시로 독립적 코인으로 재탄생.

 

 

 

3. ERC-20

 

토큰?

 ○ ERC-20은 이더리움 블록체인 네트워크에서 정한 표준 토큰 스펙.

 ○ 각각의 커스텀 토큰을 관리 가능하게 해주는 기능(스펙).

 ○ 이더리움 블록체인에서 또 다른 토큰 실행위해선 ERC-20라는 스마트계약에서 코드나 기술 표준 설정필요.

 ○ (시장화폐로서) 필요한 이더리움과 호환성이 있는 모든 요구 사항의 표준은 ERC-20로 간주.

 

규칙(함수)

 ○ totalSupply (): 총발행량. 토큰이 총 몇 개 있는지 알려주고 생성되어 사용가능한 토큰 수 지정.

 

 ○ transfer (): 송금. 토큰을 총 발행 주소에서 개인 계정으로 송금가능초기 토큰 배포를 지정된 지갑으로 실행. 이 함수로 인해 ICO 토큰이 일반적으로 ERC-20 토큰으로 사용.

 

 ○ balanceOf (): 잔액. 계정 내 토큰을 반환하고, 모든 지갑의 토큰 균형을 추적.

 

 ○ transferFrom (): 사용자는 송금 기능을 사용하여 측정 토큰을 사용자가 전송하고 교환가능. 이 함수는 지갑 주소, 수령인, 송금액을 얻은 중개인처럼 작동한 다음, 거래 수행.

 

 ○ approve (): 승인. 위조 토큰 제작 방지. 토큰 총 발행 양을 확인해 트랜잭션을 허용 및 거부, 최대 토큰 수를 유지 관리하고 어떤 지갑에 어떤 토큰이 있는지 추적.

 

 ○ allowance (): 허용. 누군가 시스템을 속이고 본인이 소유한 것보다 더 많은 토큰을 보내고자 할 때, 이를 방지함. 거래가 이뤄지면 취소되며 모든 트랜잭션은 실행되기 전 유효한지 이중 확인됨.

 

 

 

4. 다른 기준의 등장

 

변화

 ○ 대부분 토큰들은 ERC-20 규정을 따르고 있는 만큼, 디앱 사용자들은 이들 토큰을 지갑에 저장가능.

 ○ 그러나 많은 디앱프로젝트들이 ERC-20을 수행할 때 발생한 토큰손실 등 ERC-20 시스템의 불완전성으로-

 ○ 이더리움 커뮤니티는 이를 수정하였고 다른 규칙들이 등장하게 됨.

 

ERC-223

 ○ 토큰을 스마트 컨트랙트에서 직접 보냈을 때 토큰 손실가능성 문제를 수정한 것.

 ○ ERC-223이 제공하는 또 다른 혜택은 토큰들이 스마트계약에서 한번에 다른 지갑으로 송금가능하게 지원.

  - 이 기능으로 지갑은 원장 업데이트를 위해 토큰 스마트 컨트랙트가 필요하지 않음.

  - 이 기능에 불러온 부산물은 가스비가 절반 정도 밖에 안됨. 두개가 아니라 하나의 기능을 확인하는 것이기 때문.

 

ERC-777

 ○ ERC-20 버그를 위한 또 다른 솔루션이 20171120일 이더리움 커뮤니티에 제안됨.

 ○ 누구나 스마트계약 주소 및 기능 확인가능. (ERC-820 기능 가져온 것)

 ○ ERC-20의 간단한 전송과 확인에서, ERC-777의 보내기 기능으로 - 본질을 바꿈으로서-

 ○ 토큰과 스마트 컨트랙트 그 자체로 보다 많은 것들을 가능하게 함.

 

ERC-721

 ○ = NFT, Non-Fungible Token, 대체 불가능한 토큰.(성질)

 ○ 개발자들에게 복수의 소유자들 사이에서 공유불가한 토큰을 개발할 수 있게 함.

 ○ 개별적인 각각의 NFT를 위한 기능과 상태를 포함할 수 있게 해줌.

 ○ 디앱 게임들에 광범위하게 적용됨. (캐릭터나 아이템을 나타내기 위해 NFT를 구현한 게임들)

 

 ○ 대표적 사례) 이더몬. 각각의 이더몬은 ERC-721 기능을 수행하는 NFT.

  - 플레이어들은 이더몬을 상호 거래가능. 누구도, 이더몬의 한 조각을 공유불가.

  - 누군가 타인에게 전송할 경우, 전체 NFT로서 전송됨.

  - 반면, 게임에서 플레이어들은 그들의 이더몬을 훈련시키고 싸우게 할 수 있음.

  - 이것은 이더몬 상태를 늘/줄이는 결과로 이어질 수 있음.

  - 게임의 육성 기능은 새 이더몬이 생성 됐을 때, NFT가 이더리움 네트워크에 만들어짐.

  - 소유권은 자동으로 액션을 요구한 개인에게 감.

 

 ○ 본질적으로 토큰이, 디앱 내에서 공유가능하고, 미래 NFT 생성에 영향주는 수집물이 되도록 함.

 ○ NFT는 무제한 공급 가능하나 대부분 디앱 프로젝트는 전체 공급량을 제한함. (NFT의 가치유지 위함.)

 

1. 이더리움 계정(Account)

 

이더리움 계정은 20바이트의 주소와 상태변환(정보 직접 전달) 갖고 있음.

 

이더리움 계정 내 필드 4 존재.

 

 1) Nonce :  트랜잭션이 오직 한번만 처리되게 하는 카운터

 

 2) Value : 계정의 현재 ether 잔고

 

 3) Contract code : 계정의 컨트랙트 코드 ( 없을  있음)

 

 4) Storage :  계정의 저장공간(초기설정엔 값없음)

 

 

이더리움 계정은 2가지 종류가 있음.

 

 1) 외부소유계정(EOA. External Owned Account)

 

  - ‘지갑’. CA보다 상위계정.

 

  - 새로 생성되는 트랜잭션은 모두 EOA에서 시작.

 

  - 하지만  계정엔 코드 없으며,  계정에서 메시지 발신하려면  트랜잭션 생성  서명필요.

 

 

  모든 컨트랙트에는 해당 컨트랙트가 참이라는 인증이 존재해야한.

  인증을 담당하는 것은 개인키를 통한 서명이며  서명을 수행하는 것이 EOA.

    

 2) 계약계정(CA. Contract Account)

 

  - 스마트컨트랙트 역할 가능배포된 코드 ‘저장공간 추가로 존재.

 

  - CA 컨트랙트 실행 가능. 생성 불가. ( EOA 만든 컨트랙트만 실행가능. 생성X )

 

  - EOA 보낸 메시지를 CA 수신할 때마다 자신의 코드를 활성화.

 

  - (기능수행)  활성화 코드따라 메시지 읽기, 내부저장공간 기록, 다른 메시지 발신. 컨트랙트들을 차례로 생성.

 

 

 

스마트컨트랙트는 이더리움 실행환경 내에 살아있는 자율 에이전트.

 

 ○ 이더리움에서 컨트랙트는 수행 당하는 , 컴파일 되는 .

 

 ○ 메시지, 트랜잭션이 도착하면 항상 특정코드 실행.

 

 ○ 자신의 이더잔고와 영속적 변수들 추적키 위해 자신의 / 저장소를 직접 통제함.(=스마트)

 

 

 

이더리움의 비대칭암호키 = 개인키와 공개키 => “address” 주소로 표현

 

 ○ 이더리움은 속도와 보안성 조절 위해 다양한 매개변수를 갖음.

 

 ○ 이더리움은 타원곡선암호(=ECC) *secp256k1 사용함.

  *secp256k1 : 타원곡선암호기술의 종류( https://m.blog.naver.com/aepkoreanet/221178375642 )

 

비트코인에서 사용하는 타원곡선암호기술(ECC)

지난, “비트코인 시스템에서 사용하는 암호 기술“ 기사에서, 비트코인은 디지털 서명 암호기술로, 공개키...

blog.naver.com

 ○ 암호와 매개변수로 비대칭 암호키를 생성함.

 

 ○ 공개키를 이용해 주소를 만드는 것이지만, ‘ ‘주소 표현.

     *1) 공개 키의 keccak-256 해시 생성

     *2) 12바이트 제거

     *3) 16진수 문자열 인코딩. 최종 40 문자의 바이트 스트링이 유저의 계정주소.

 

 

 

2. 트랜잭션(Transaction)

 

□ EOA(외부소유계정, 지갑) 보낼 메시지를 포함한 서명된 데이터 패키지.

 

 ○ A→B계정으로 이더, 컨트랙트(함수호출,  컨트랙트 배포 ) 보낼  서명으로 사용

 

  - 타원곡선암호 기반의 디지털서명 알고리즘인 ECDSA이용하여 서명함.

 

  - 트랜잭션은 다음 값을 포함

to

메시지 수신처

to, signature, value

암호화폐에서

표준처럼

사용되는 

signature

발신처 확인가능한 서명

value

발신처가 수신처로 보내는 이더의 

data

선택적 데이터 필드(컨트랙트 메시지를 담을  있는 데이터 필드)

 *초기값은 없지만 EVM 컨트랙트가 여기 접근할  사용할 수행코드 소유.

gaslimit

start가스값. 최대 계산 단계 (트랜잭션 실행이 수행되도록 허용된)

gaslimit, gasprice

코드  무한루프

 계산 낭비 방지 용도.

gasprice

 계산단계마다 발신처가 지불하는 수수료

   · 이더리움의 디도스예방. 해킹시 실행되는 모든 리소스에 강제수수료 부과.

 

   · 계산기본단위 ‘가스’, 계산단계별 소모비용은 연산마다, 데이터 용량마다 다름.

 

   · 트랜잭션 데이터 내에 바이트랑 5가스 수수료 지불.

 

 블록체인 위에 도메인등록서비스 기능하는 컨트랙트가 있는 경우,

 이 컨트랙트로 보내지는 data 등록하고자 하는 ‘도메인 ‘IP주소 개의 필드를 소유함.

 컨트랙트는 메시지 데이터로부터  값들을 읽어 저장소  적당한 위치에 저장함.

 EVM 데이터에 어떤 값이 존재하는  미리 알고 있음.

 

 

 

3. 메시지(message)

 

이더리움 실행환경(EVM)에서만 존재하는 가상 객체 (저장 불필요)

 

 ○ 컨트랙트는 다른 컨트랙트에게 메시지 전달가능함.

from

메시지 발신처(암묵적)

to

메시지 수신처

value

메시지와 함께 전달되는 이더

data

선택적 데이터 필드

gaslimit

start 가스값. 최대 계산 단계 (트랜잭션 실행이 수행되도록 허용된)

 

메시지는 컨트랙트에 의해 생성됨. (트랜잭션은 EOA 의해 생성됨)

 

 

그러나, 메시지는 트랜잭션과 매우 유사함.

 

 ○ 수행과정

 

  - 코드수행 중인 컨트랙트가

  - 메시지 생성  실행 지시하는 수행코드(opcode) 만나게 되면

  - 메시지를 생성함. 그리고 해당코드를 실행하는 수신자계정(컨트랙트 계정) 도달하게 .

  - 따라서, 컨트랙트는 EOA 하는 동일한 방식으로 다른 컨트랙트와 관계를 맺음.

 

 

□ GAS 관련

 

 ○ 트랜잭션이나 컨트랙트에 의해 할당된 가스 허용치는

 

 ○  트랜잭션과 모든 하위 실행에 의해 소모된  가스에 적용됨.

  * EOA A B에게 1,000가스와 함께 트랜잭션을 보내고 (1,000부여)

  * B 600가스를 소모  C에게 메시지를 보내고, C 내부 실행에 300가스를 소모한  반환하면 (900사용)

  * B 가스가 모두 소모되기  100가스  사용가능.

 

 

 

#. 출처 사이트 :

https://steemit.com/kr/@yahweh87/36-5  : 스팀잇 이더리움백서 설명.

https://hamait.tistory.com/965?category=   : 컨트랙트 비용.

https://hamait.tistory.com/966?category=276132:  [이더리움 메모] 트랜잭션의 실전적 종류 구분.

+ Recent posts