블록체인 이론, 핵심만 정리했습니다 #1

sumong·2023년 1월 8일

Klaytn bapp blockchain ethereum wallet 블록체인 스마트 컨트랙트 이더리움 전자서명 지갑 클레이튼 트랜잭션 합의 알고리즘

블록체인

목록 보기

1/6

2021년 8월경에 제가 블록체인에 대해 공부한 내용들을 정리했습니다.

강의 : Klaytn 클레이튼 스마트계약과 탈중앙앱 강의(한양대학교)

블록체인이란?

정보들을 블록 단위로 저장하고, 이를 체인 형태로 묶은 저장기술. (해싱 + 암호화)

블록의 순서는 유지됨.
링크드 리스트랑 비슷한 형태.
각 블록이 자기 앞의 블록을 기억하는 방법 : 해시 함수(Hash Function)

그럼 해시 함수는 뭐지?

데이터를 고정된 길이의 데이터로 매핑하는 함수.

ex) bit.ly~로 시작하는 URL 주소(어떤 주소던 5글자로 줄임)

하나의 데이터에 대해선 단 하나의 해시값만 나옴.
데이터가 조금 바뀌면, 해시값은 크게 달라지는 경우가 일반적임.
두 해시값이 같다면, 두 해시값의 원본 데이터는 같은 경우가 대부분임. (다만 극히 드물게 다른 두 데이터의 해시값이 같은 경우도 있어서 완벽하게 성립하진 않음)
블록체인 분야에선 Keccak-256을 많이 사용함. (256bit 길이의 해시를 생성하는 함수)

해시포인터?

블록(Block) = 헤더(Header) + 바디(Body)
헤더(Header) = 블록을 설명하는 정보 + 이전 블록의 해시값(해시포인터)
바디(Body) = 정보의 묶음.
블록체인에선 동일한 데이터가 반복되는 경우가 거의 없다.

블록높이, 블록생성주기?

초기의 블록체인은 0번 블록이 맨 밑에 있고, 그 위에 블록들이 쌓이는 형태로 구성되었었다. ⇒ '블록높이'라는 용어가 나올 수 있는 이유.
블록높이 = 블록이 생성된 순서, 블록체인 내에서 블록의 순서. ('당연히' 0부터 시작함)
블록생성주기 = 블록체인에서 주기적으로 블록을 만드는 경우, 그 생성 주기.
블록생성주기는 블록이 체결되기까지 걸리는 시간에 큰 영향을 끼친다. 그리고 블록이 체결되기까지 걸리는 시간이 짧냐 기냐에 따라 해당 블록체인 기술의 쓰임이 달라진다. ex) 블록생성주기가 5분인 경우, 결제 시스템에는 쓸 수 없지만, 보험 시스템에는 쓸 수 있다.
클레이튼 = 지극히 서비스 지향적, 이 때문에 블록생성주기는 1초. (이 경우 평균적으로 3~4초 안에 체결이 이루어진다.)

블록체인 네트워크, 노드

Peer-to-Peer Network
모든 노드들이 같은 데이터를 동일한 순서로 가지고 있음. (만약 블록체인에서 블록이 100개 있다면, 모든 노드는 100개의 블록을 저장하고 있음)
노드들끼리 블록을 주고받음.
특정 데이터에 대해 특정 노드가 그 데이터를 가지고 있지 않아도, 다른 노드로부터 해당 데이터를 가져올 수 있음.

합의?

특정 노드가 새 데이터를 새 블록으로 추가하기 위한 과정.

자격이 있는 참여자는 블록을 제안(propose)할 수 있음.
블록 제안 자격은 네트워크마다 다름. (PoW 등)
노드들은 제안자가 올바른 자격을 취득했는지, 제안된 블록이 올바른지 검증한 뒤 블록을 자신의 체인에 추가.
해당 블록을 자신의 체인에 추가한 노드의 수가 정족수를 넘거나 정해진 기준을 만족하면, 합의가 이루어졌다고 판단 ⇒ 제안된 블록을 블록체인의 새 블록으로 받아들임.
(보통 longist chain 구조를 사용, 가장 긴 체인을 가진 노드를 신뢰함.)
한 번 쓰여진 블록은 이전의 합의를 번복할 수 없는 한 변경할 수 없음. (불변성) (블록을 수정하는 경우, 해당 블록 뒤에 따라오는 모든 블록에 대한 합의를 전부 번복할 수 있어야 한다. 이 때문에 변경이 '거의' 불가능하다.)

합의 알고리즘

비교분석

.	PoW	PoS	BFT-variants
제안자격 취득 방법	계산이 어려운 문제 풀기	플랫폼 토큰을 보유한 양과 기간에 따라 결정적으로 또는 확률적으로 뽑힐 것	정해진 순번 또는 정해진 확률에 의해 뽑힐 것
네트워크 참여 제한	없음	없거나 낮음	높음
합의에 필요한 연산량	높음	낮음	낮음 (네트워크 트래픽 제외)
위협	전체 연산량의 51%를 한 참여자가 소유할 경우 중앙화됨	전체 토큰의 51%를 한 참여자가 소유할 경우 중앙화됨	전체 참여노드의 1/3 이상이 담합할 경우 합의 불가, 전체 참여노드의 2/3 이상이 담합할 경우 중앙화됨
대표적인 블록체인	Bitcoin, Litecoin, Ethereum, Monero, QTUM	Ethereum FFG & CFG, EOS(dPoS)	Klaytn, Tendermint, Hyperledger Fabric, Ontology

PoW 기반 합의 구조

PoW = Proof of Work.

직전 블록의 데이터를 가지고 해시를 만듦. 이를 찾는 '문제'를 내고, 이를 먼저 푼 노드는 블록을 제안할 수 있음.
Nonce : 해시값을 크게 바꾸기 위해 집어넣는 Garbabe Value. (Sequence하게 저장하기도 하고, Random으로 지정하기도 함.)
해시를 하면 숫자가 나옴, 그 숫자의 맨 앞자리부터 시작하는 0의 갯수가 특정 수 이상이면 문제를 풀었다고 함.
퍼즐을 먼저 푼 노드는 블록을 제안할 수 있음.
문제를 풀긴 어렵지만, 올바르게 풀었는지 확인하긴 쉽다.
비트코인에서 사용하는 합의 구조.
해당 노드에 대한 신뢰성을 보장하면서, 동시에 그 익명성 또한 보장하는 방식.
난이도는 블록생성주기를 고려해서 설정하며, 요구하는 0의 갯수가 클수록 난이도가 상승함.
난이도는 시간당 전체 네트워크에서 나올 수 있는 해시 갯수를 고려해서 가변형으로 조정된다.
네트워크가 비동기 상태이더라도 합의가 가능하다.
합의를 위한 정족수는 전체 노드의 51% 이상이다.

Q. 특정 해시를 찾는 게 어렵나요?
A. 256bit짜리 해시를 찾아야 하는데, 그 경우의 수는 2^256으로, 이는 우주의 모든 먼지를 모은 수보다 크다.

PoS 기반 합의 구조

PoS = Proof of Stake.

네트워크에서 사용하는 토큰을 많이 가지고 있는 사람이 더 센 발언권을 가짐.
= 즉 토큰을 많이 가지고 있으면 더 높은 확률로 다음 블록을 제안할 수 있음.
보통은 PoW로 경쟁하면서 기반을 닦고 토큰을 최대한 분배한 뒤 PoS를 도입한다.
합의를 위한 정족수는 전체 노드의 51% 이상이다.

Q. 돈 많은 사람이 토큰을 다 사버리면 문제가 되지 않나? A. 이 때문에 보통 PoS만 단독으로 쓰진 않는다!

BFT-variants 합의 구조

BFT = Byzantine Fault Tolerance

다른 알고리즘에 비해 느리고, 합의를 이루기 위한 통신량이 매우 많다.
(현재는 노드가 15개만 넘어가도 느려진다고 함.)
네트워크에 누가 참여하는지를 모두가 알고 있으며, 참여자가 바뀌지 않는다. (네트워크가 동기화 상태를 유지한다.) (새로운 참여자가 생기는 경우, 모든 작업을 멈추고, 모든 노드가 새 참여자에 대한 정보를 확보하는 작업이 필요하다.)
정해진 네트워크 안에서는 굉장히 효율적임. + 참여자 수가 적을수록 빠름.
(단, 참여자 수가 적을수록 중앙화된다.)
네트워크를 확장시키기 매우 어렵다.
합의를 위한 정족수는 전체 노드의 2/3 이상이다.

공개 여부

Public VS Private

누구든지 기록된 정보(블록)를 자유롭게 읽을 수 있는가?

명시적인 등록 또는 자격취득 없이 정보를 블록체인 네트워크에 기록할 수 있는가?

Public(공개형) : 정보가 공개되어 있고, 네트워크가 정한 기준에 따라 정보를 기록요청할 수 있다.
Private(비공개형) : 정보가 공개되어 있지 않고, 미리 자격을 획득한 사용자만이 정보를 기록할 수 있다.

네트워크 참여

(넓은 의미) 블록체인 P2P 네트워크에 참여

(좁은 의미) 합의과정의 참여

Permissioned : 네트워크의 참여가 제한된 경우 (BFT에선 네트워크엔 참여했지만 합의에는 참여하지 못하는 경우가 있다. 이런 게 Permissioned.)
Permissionless : 네트워크의 참여가 제한되지 않은 경우

※ 클레이튼의 경우, 데이터는 공개되어 있지만, 정해진 노드들만 합의에 참여할 수 있는 구조이다.

암호화 기본

대칭키 암호/비대칭키 암호

암호화에 사용한 키와 복호화에 사용한 키가

동일함 = 대칭키 암호

다름 = 비대칭키 암호

비대칭키 암호(공개키 암호)

공개키(Public Key, PK) : 암호화에 사용되는 키
비밀키(Private Key/Secret Key, SK) : 복호화에 사용되는 키
목적 : 누구든지 암호화할 수 있지만, 비밀키를 아는 사람만 복호화할 수 있다.
공개키 - 비밀키는 한쌍으로 묶여있는 아주 큰 숫자들로, 비밀키를 만들면 그에 해당하는 공개키가 존재한다.
비밀키 → 공개키를 도출하는 것은 쉬움.
공개키 → 비밀키를 찾는 것은 '암호학적으로' 매우 어려움. (최신 컴퓨터를 써서 계산해도 풀 수 없거나, 푸는 과정이 경제적으로 매우 비효율적이다.)

공개키 암호의 용도 : 안전한 통신

가정 : 아래 그림처럼, Alice ↔ Bob 사이에 통신한다고 가정한다.

Alice는 Bob의 공개키로 정보를 암호화한 뒤, 인터넷을 통해 Bob에게 전송한다.
Bob은 Alice가 보낸 정보를 자신의 비밀키로 복호화한 뒤, 내용을 확인한다.
이번엔 Bob이 Alice에게 정보를 보내는데, 이 때 Alice의 공개키로 암호화한다.
Alice는 Bob이 보낸 내용을 자신의 비밀키로 복호화한 뒤, 내용을 확인한다.

해커가 중간에 가로채더라도, Alice나 Bob이 가진 비밀키가 없기 때문에 내용을 볼 수 없다.
Alice ↔ Bob 사이의 통신에선 서로의 공개키만을 알고 있으면 되며, 비밀키를 공유할 필요가 없다. (비밀키를 공유하는 과정에서 탈취되는 등의 리스크가 없어진다.)

전자서명

누가 정보를 보냈는지 확인하기 위해 사용

비대칭 암호의 응용 프로그램.
비밀키로 서명
공개키로 해당 서명이 누구의 것인지를 검증.

공개키 암호 + 전자서명을 이용한 안전한 통신

가정 : Alice가 Bob한테 메세지를 보냄. 이 때, Bob은 자신에게 온 메세지가 Alice가 보낸 게 맞는지 확인하고 싶어함.

Alice는 Bob의 공개키로 정보를 암호화한 뒤, 인터넷을 통해 Bob에게 전송한다.
Alice는 자신의 비밀키로 전자서명을 한 뒤, 이를 같이 Bob에게 전송한다.
Bob은 Alice가 보낸 정보를 자신의 비밀키로 복호화한 뒤, 내용을 확인한다.
Bob은 Alice의 공개키로 전자서명을 검증해서, Alice가 보낸 정보가 맞다는 것을 확인한다.

공개키 암호만 썼을 때의 문제점 : Alice뿐만 아니라, 다른 사람들도 Bob의 공개키로 정보를 암호화해서 보낼 수 있으므로, Bob 입장에선 자신이 받은 정보가 Alice가 보낸 건지 다른 사람이 보낸 건지 알 수 없다.

공개키 암호 + 전자서명 + 해싱을 통한 더 안전한 통신

해싱의 목적 : 송신자가 메세지를 보낸 시점 이후로, 해당 메세지가 변조되지 않았음을 확인하기 위한 것.
현재 사용하고 있는 안전한 통신 구조의 근간.

블록체인에서의 암호화

소유권을 확인하는 방법?

(여기서는 비트코인을 예시로 설명함)

원장(블록)은 어느 주소에 BTC가 얼마나 있는지는 기록되어 있지만, 해당 주소가 누구에게 속하는지에 대한 정보는 가지고 있지 않다. (익명성)
따라서, 비트코인에선 전자서명을 사용하여, 명시적인 비밀교환과정 없이 BTC의 소유권을 확인한다. (해당 소유주가 누구인지 그 신원을 확인할 필요 없이, 전자서명을 제출하면 해당 BTC의 소유주라고 인정하는 것.)
대부분의 블록체인 주소는 공개키를 가공한 값을 쓴다.
비트코인 : SHA256으로 해싱한 뒤 RIPEMD160이라는, 160bit?로 줄이는 암호화 기법을 씀. 이더리움 : 해싱 후 뒤의 160bit만 뜯어내서 사용.
어느 주소에서 다른 주소로 BTC를 옮기는 트랜젝션이 발생함.

트랜잭션

블록체인의 상태

블록체인은 트랜잭션으로 변화하는 상태 기계(State Machine)이다.

초기값 = 이전 블록의 상태 / 최종값 = 현재 블록의 상태.
변경값 = 트랜잭션. 이 때, 항상 같은 결과를 보장하기 위해서 하나의 트랜잭션이 반영되는 과정에선 다른 트랜잭션의 개입은 제한된다.
초기값 + 변경사항 = 최종값
앞 블록의 최종값 = 다음 블록의 초기값.

(위 모델은 어카운트 기반 블록체인으로, 수수료 개념이 빠져 있음.)

Block_0 : Alice에게 토큰 100개 지급
Block_1 i (초기값) : Block_0의 상태. 작업 : Alice에게 토큰 100개 추가 지급 + Alice→Bob에게 30개 전송.
Coinbase : 블록을 생성한 사람이 현 트랜잭션의 source인 경우. (즉, Block_1을 캔 사람은 Alice가 되는 것.)

어카운트의 추가

트랜잭션 과정을 통해 어카운트가 생성되거나 변경된다.
어카운트에 해당하는 key-pair를 하나 만들고, 해당 key-pair로 트랜잭션이 일어나서 비트코인에 변화를 주어야, 해당 어카운트의 존재가 블록체인에 알려진다.
즉, 트랜잭션이 일어나야만 어카운트가 블록체인에 더해지는 것이다.
(기존의 회원가입 느낌하고는 다름)

이더리움의 어카운트?

이더리움이 관리하는 '상태'는, 어카운트의 '상태'이다.

External Account : 사용자(end user)가 사용하는 어카운트. EOA 등. 트랜잭션을 실제로 만들고 블록에 기록할 수 있다.
Contract Account : 스마트 컨트랙트를 표현하는 어카운트. 수동적이고, 트랜잭션을 스스로 만들 수 없다. 누군가가 실행 요청을 하면 그 때서야 실행되고, 그 실행 결과를 요청자에게 돌려주는 형식이다.
(Q. 스마트 컨트랙트가 어카운트인 이유?
A. 스마트 컨트랙트도 프로그램이고, 프로그램은 '상태'를 가지기 때문이다.)

트랜잭션(TX)

트랜잭션 = 블록체인의 상태를 변경하는 것.

TX = 보내는 사람(sender, from) + 받는 사람(recipient, to)
받는 사람(to)이 누구냐에 따라 TX의 목적이 달라짐. ex)

to가 External Account = Value transfer, 토큰을 전송.
to가 Contract Account = 스마트 컨트랙트 실행
to가 미지정 = 새로운 스마트 컨트랙트 배포.

[처리 과정]

1) sender가 TX를 처리하는데 필요한 가스비를 가지고 있는지 확인한다.
2) 이후, sender를 확인해서, 그 account에 가스비 이상의 balance가 있는지 확인.
3-1) 만약 없다면 거절하고 종료,
3-2) 있다면 keep해두었다가 노드가 블록에 넣을 수 있다고 판단한 시점에 블록에 편입 후 실행시킴.
4) 블록에 들어갔다는 것이 모두에게 broadcast되면(=TX가 체결되면) 그 때 가스비를 차감함.

가스(Gas)

TX를 처리하는데 필요한 자원을 비용으로 전환한 것.

sender가 지불함.
(정확히는 account의 소유자. 예를 들어, 특정 트랜잭션이 내 account로 실행되지만, 그 트랜잭션을 실행한 건 다른 사람인 경우, 내가 가스비를 지불해야 한다.)
이더리움의 경우, sender는 TX의 처리를 위해 필요한 가스의 총량과 같은 가치의 플랫폼 토큰을 제공해야 함. 이 때, 연산당 가스비가 더 비싼 TX를 먼저 처리함.
클레이튼의 경우, 성능이 이더리움보다 더 높기 때문에, 연산당 가스비를 적어서 내지 않음. → 사용자들끼리 경쟁하지 않음. TX는 생성된 순서되로 처리됨.

트랜잭션과 서명

sender가 트랜잭션이 발생하는 account의 소유자임을 증명하기 위해서, 트랜잭션에는 서명이 같이 따라와야 한다.

이더리움
TX에 서명이 들어가 있고, 아래 과정은 miner의 컴퓨터상에서 실행됨.
(아래 과정에선 네트워크 자원을 소모하지 않음.)
서명 → 공개키 도출 → account 주소 도출 → account 존재유무 확인.
- '서명을 가지고 있다. = 유효한 비밀키를 가지고 있다.'이기 때문에 논리 자체는 문제가 없음.
- 단점 : 공개키 도출 함수가 무거워서, 연산량이 늘어남.
클레이튼
TX에 from 주소를 포함시킴.(서명과 account 주소가 따로 놈)
from 주소 확인 → 저장된 공개키 불러오기 → 서명 직접 검증

Account 기반 트랜잭션

nonce : 특정 account의 몇 번째 TX인지를 표시하는, 순서에 해당하는 값. (동일한 TX를 여러 번 보내는 것을 방지. 병렬화가 불가능해짐.)
value : TX가 전송하는 토큰의 갯수. (보통은 토큰보다 작은 단위의 값으로 표시됨.)

이더리움 트랜잭션 예시

from이 없음.
gas : 명렁에 몇 개까지의 가스를 쓸 것인가.
gasPrice : 한 가스마다 얼마만큼 지불할 것인지.
→ gas X gasPrice = (TX 실행에 지불할 금액.)
v : 서명의 식별자.
r, s : 서명.

클레이튼 트랜잭션 예시

type : 어떤 형태의 TX인지 표시.
gasPrice : 사용자가 임의로 바꿀 수 없음.
(사용자가 임의로 변경 시 reject됨. 당시에는 25stone로 고정되어 있었음.)
클레이튼 사용 시, 트랜잭션을 아래의 형태로 만들어서 전송해야 한다!!!
(노드↔사용자 간 동일 프로토콜 사용 필수)

스마트 컨트랙트

스마트 컨트랙트 = 특정 주소에 배포되어 있는 TX로 실행 가능한 코드

함수 + 상태. 블록체인에 저장되어 있음.
함수는 상태를 변경하는 함수, 상태를 변경하지 않는 함수로 분류.
사용자가 스마트 컨트랙트 함수를 실행하거나 상태를 읽을 때 주소가 필요.
트랜잭션으로 컨트랙트를 실행하고, 트랜잭션의 결과가 컨트랙트에 반영됨.

스마트 컨트랙트의 실행

사용자가 실행함.

상태를 변경하는 함수 실행 : 그에 맞는 TX를 생성해서 블록에 추가, TX 체결 시 함수가 실행됨.
상태를 변경하지 않는 함수, 상태를 읽는 행위 : 노드에서 실행, TX 필요 없음.

Solidity

이더리움, 클레이튼에서 지원하는 스마트 컨트랙트 언어.
일반적인 프로그래밍 언어와 그 문법, 사용은 유사하지만 몇 가지 제약이 존재.
ex) 포인터의 개념이 없음 → recursive type 선언 불가능.
ex) 대신 블록체인의 주소 개념이 들어감.
클레이튼 : 솔리디티의 특정 버전을 지원함.

Blockchain Application (BApp)

BApp = 블록체인을 사용하는 어플리케이션. 기존의 기술로 풀기 어려운 문제들을, 블록체인의 특성을 활용해서 풀어내는 것이 목적.

블록체인의 특성?

블록체인의 특성 = 불변성, 투명성.

한 번 기록된 정보는 변경할 수 없다.
정해진 규칙(프로토콜이 가진 규칙, 컨트랙트로 구현된 규칙 등)에 따라 상태를 변경한다.
기록의 내역이 블록에 공개되어 있으므로 누구든지 정보의 진실여부를 확인할 수 있다.
(원래 '신뢰'에는 큰 비용이 든다. 하지만 블록체인은 그 특성 때문에, '신뢰'를 기반으로 하지 않아도 그 정보의 진실여부를 믿을 수 있다!)

⇒ 이를 이용하면, 기존에는 '신뢰'의 문제 때문에 하기 어려웠던 여러 서비스들을 할 수 있게 된다!!!

블록체인을 사용하는 유형

결제 수단 : 토큰을 사용한 결제, but 암호화폐를 결제 수단으로 쓰기엔 문제가 있음.
저장 수단 : 블록체인을 정보를 추가할 수만 있는, 안전한 저장소로 사용.
(블록의 수정이나 삭제가 매우 어렵기 때문)
실행 환경 : 모든 노드가 같은 데이터를 가지고 있으며, 동일한 연산을 수행(⇒ 모든 노드에서 같은 결과가 나옴), 어느 한 노드에 의존하지 않는 탈중앙화된 실행 환경을 제공함. (스마트 컨트랙트를 이용하면 가능함.)

※ 암호화폐를 결제 수단으로 쓰기 어려운 이유 : 암호화폐의 가치 변동 폭이 너무 크기 때문. → 이 때문에 Stable coin이 등장함.

BApp의 유형

Fully decentralized (완전한 탈중앙화) = 블록체인의 특성(모든 노드가 같은 데이터를 가지고 있다, 한 노드에 의존하지 않는다, 어느 노드와 통신하더라도 같은 결과값을 받을 수 있다)을 완벽하게 지키는 형태. 클라이언트가 직접 블록체인과 통신한다. 다만, 완전한 탈중앙화를 이루려면 몇 가지 제약이 존재한다.
ex) 메타마스크 등의 암호화폐 지갑.
Semi-decentralized with centralized proxy (불완전한 탈중앙화, 중개 서버 이용) = Fully decentralized의 제약을 완화한 것. 클라이언트 ↔ 중개서버 ↔ 블록체인 블록체인 기반으로 만들어진 서비스가 있고, 그 서비스를 사용자들이 사용하는 형태.

Q. Semi-decentralized는 믿을 수 있는 방식인가?

A. 믿을 수 있다! 데이터의 무결성은 블록체인이 보증하는 것이고, 그 무결성 여부를 서비스가 확인해서 클라이언트에게 전달하는 것이기 때문.
(기존의 방식 또한 결국 클라이언트가 서비스를 신뢰한다는 전제조건 위에서 동작하는 것이기 때문에, 어찌 보면 블록체인에 전통적인 방식을 결합한 것이다.)

Fully Decentralized

장점

높은 투명성 (어플리케이션이 블록체인에 무언가를 요청하면 바로 TX가 생겨서 블록에 기록되기 때문. 즉, 어플리케이션이 하는 모든 액션이 블록에 기록된다!)
신뢰 형성에 필요한 비용이 없음 (블록체인을 믿는 형태이므로.)
경우에 따라 사용자의 익명성 보장 가능 (블록체인에 account를 만드는 경우 내 신원을 드러낼 필요가 없다는 점을 생각하면 된다.)
(설치형 BApp의 경우) 관리 비용이 낮음

단점

사용자 책임이 증가, 이로 인해 UX가 나빠짐 (블록체인을 쓰기 위해, 모든 블록을 저장하는 것부터가 어려움. 이로 인해 스토리지 비용이 발생하고, 연산 비용도 발생하는 등의 문제가 발생한다. 추가로, 모바일 환경에서는 스토리지 문제가 더욱 심각해진다.)
이 때문에, 헤더만 죽 복사해서 다운받은 뒤, 이를 이용해서 검증을 하는 기술도 존재한다.
로직의 변경이 어려움
경우에 따라 사용자가 블록체인에 상시 접속할 필요가 생기고, 블록을 복제할 필요도 생김. (새로 생성되는 블록을 기록해야 하기 때문에 상시 접속할 필요가 생긴다. 모바일 환경에선 이로 인해 배터리 문제도 발생한다.)

Semi-Decentralized with Centralized Proxy

장점

(기존 서비스들과 동일한) 높은 수준의 UX (단적으로, 사용자가 직접 TX를 만들지 않아도 된다.)
사용자가 블록체인과 직접 통신할 필요 없음
로직의 변경이 비교적 쉬움

단점

신뢰 비용이 발생 (일반적인 서비스들이 겪는 문제와 같음.)
서비스가 Single Point of Failure (SPoF)가 됨 (서버가 다운되면 서비스 이용이 불가능해진다. Fully Decentralized 환경의 경우, 한 노드가 죽으면 다른 노드를 이용하면 되기 때문에 SPoF가 존재하지 않는다.)
관리 비용이 높음 (신뢰 비용, SPoF 등의 이유 때문.)

프론트엔드/벡엔드의 역할 구분

프론트엔드 : TX 생성, 서명, 전송 등을 처리
백엔드 : 블록체인 동기화, 블록 파싱, TX 전달, 가스비 대납 등을 처리

지갑(Wallet)

Key와 Wallet

key = TX를 서명하기 위해서 필요함.
- 서로 다른 키는 다른 account에 매핑된다.
- 하나의 account로 여러 BApp을 사용하려는 사용자의 니즈가 존재한다. ⇒ wallet이 등장.
wallet = key를 관리하는 프로그램.
- key를 보관하고, BApp이 요청할 때마다 보관중인 key로 TX를 서명.
- 여러 유형의 지갑이 존재함.
  ex) 브라우저 플러그인(메타마스크), Dapp 브라우저 내장 지갑, 클라우드 지갑, 디바이스 지갑...

MetaMask

MetaMask = 이더리움 개인지갑을 편리하고 안전하게 관리할 수 있게 하는 구글 확장프로그램.

웹브라우저에서 발생하는 모든 일을 관찰하다가, 웹앱으로부터 TX를 만들어달라는 요청을 받으면 메타마스크가 사용자에게 서명할 지 물어보고, 사용자가 이를 승인하면 TX를 서명해서 웹앱을 통해 블록체인에 보냄.
wallet과 사용 로직이 분리된 형태를 지원함.
(기존에는 wallet 안에 사용 로직이 포함되어 있었음. 이를 분리할 수 있게 된 것.)
크롬 브라우저 플러그인이라는 태생적 한계를 벗어나지 못함.

Cloud Wallet

Cloud Wallet = MetaMask의 단점을 보완.

key를 클라우드(서버)에 보관하고, 만들고자 하는 TX를 key에 대한 암호와 함께 wallet에 보내면, wallet이 TX를 서명해서 to address에 보냄.
어떤 장비를 쓰던, key를 사용할 수 있게 됨.
탈중앙화의 원칙에선 조금 벗어남.

Device Wallet

삼성 블록체인 keystore가 대표적인 예시.
key를 device level(스마트폰)에서 관리하고, 삼성에선 앱 개발사들에게 keystore 관련 라이브러리를 제공함.
S10 이후에 나온 삼성폰에서 사용 가능.

지갑을 고려한 BApp 개발

어떤 지갑을 사용하느냐에 따라 사용자 환경이 달라진다.

어떤 형태로 BApp을 만들 것인가?
(웹앱, 모바일 웹, 모바일 네이티브, 데스크톱 등)
BApp에 지갑을 내장할 것인가, 아니면 외부 지갑을 사용할 것인가?
외부 지갑을 쓸 경우, 개발하려는 BApp의 형태와 맞는 지갑은 어떤 것인가?
ex1) 웹앱 + 이더리움 ⇒ Metamask
ex2) 모바일 웹 or 모바일 네이티브 + 클레이튼 ⇒ 삼성 블록체인 keystore

⇒ BApp의 목적 및 타겟 사용자를 분석하여, 어느 형태로 키를 관리할지 결정해야 한다!

sumong

Flutter 메인의 풀스택 개발자 / 한양대 컴퓨터소프트웨어학과, HUHS의 화석

다음 포스트