GOD동하님의 블로그

[해외송금] SWIFT 거래와 리플

GOD동하 — Fri, 23 Jul 2021 16:24:46 +0900

해외 송금 시 자국 통화를 외국 통화로 전달해야 하는데

전세계 금융기관이 사용하는 국제금융통신망인 SWIFT 라는 표준화된 형태를 통해 유통된다.

SWIFT란?

Society of Worldwide Interbank Financial Telecommunication 의 약자로

국제 은행들간의 표준 메세지를 주고받을 수 있는 통신 네트워크이다.

해외 송금은 SWIFT로 환거래 계좌를 통해 얼마를 입금하라는 메세지를 보내는 것이다.

환거래란?

환거래는 은행들이 서로 고객으로 계좌를 보유하여 통화를 교환하기 위한 거래를 뜻한다.

타 은행으로 송금할 때 아래 그림과 같이 A 은행에서 최영희씨가 B 은행의 박민지씨에게 송금을 한다.

간단하게 최영희 계좌에서 100만원을 차감하고, 박민지 계좌에서 100만원을 증가시키면 된다.

가 아니고!!!

전산상의 기록만 바뀔 뿐, 실제 은행간의 돈은 주고 받은게 없으므로 A은행은 B은행에게 직접 현금을 줘야 한다.

그럼 A은행에서 B은행까지 돈을 줄때까지 박민지씨는 100만원을 못받는다.

그럼 아래처럼은 어떨까.

B은행에 미리 A은행의 예치금 계좌를 개설해둔다.

최영희씨가 B은행으로 송금을 하면 최영희씨 계좌에 100만원을 차감 후,

B은행에선 A의 예치금 중 100만원을 차감 후 B은행의 박민지 계좌를 증가시켜준다.

SWIFT 거래 방식

SWIFT로 송금을 요청하게 되면 아래와 같은 프로세스로 흐르게 되며

중개 은행과 같은 상호 환거래 관리하는 기관을 통해 통화의 흐름이 발생하게 된다.

하지만, 위와 같은 방식에선 여러가지 문제점이 따른다.

기존 해외 송금의 문제점

느림

각 은행간 처리하는 병목이 생기고 (아마 환율, 처리, 거래 이력 관리 등)

그래서 소요시간이 영업일 기준 평균 3일 걸리며 총 3~5일정도 걸림

비쌈

또한, 각각의 수수료를 물기 때문에 해외송금 수수료가 매우 큼

소액 고액과 상관 없이 비싼 수수료를 내야함

변동성

5일정도 걸렸다 하면 환율의 차이 때문에 변동성이 클 수 있음

신뢰성

알 수 없는 이유로 거래가 취소되는 경우도 있음

각 은행이 독립된 저장소를 가지므로 사후 정산을 위해 데이터 검증 작업이 필요함

이 문제를 해결하기 위한 기술 등장

현재 금융쪽, 특히 은행과 같은 곳은 규제가 심하기 때문에 거의 정체되어 있어 문제가 많다.

리플은 블록체인 기술 기반의 Interledger 라는 송금 프로토콜을 개발하여 위와 같은 문제를 해결하고자 했다.

이를 위한 리플 사의 솔루션은 크게 두개로 볼 수 있는데,

xCurrent와 xRapid 이다.

xCurrent 란?

은행 간의 해외 송금 시 아래 과정이 필요한데 그 과정을 촉진시킨 것이다.

1. 송금, 수령인의 계좌 정보

2. 거래 내용 파악

3. 거래 완료 시 동기화

크게 Messanger 와 블록체인 기반의 Inter Ledger Protocol 레이어로 이루어져 있는데,

계좌 정보와 거래 내용을 Messanger를 통해 확인하고 양측 모두 거래를 할 준비가 되어있는지 Validator에 의해 승인이 된다면 자산의 이동이 한번에 이루어지고 거래 내용은 ILP Ledger에 기록된다.

이로 인해 최대 60% 수수료를 절감할 수 있다고 하며 거의 실시간으로 거래가 가능하다.

ILP 프로토콜은 오픈 소스이며 은행 간 Ledger를 이어주는 사실상의 표준으로 자리잡고 있다.

ILP 에서는 검증된 은행 네트워크만 참여하는 Private 블록체인이며 송금은 제 3자의 은행들로 구성된 ILP Validator 들에 의해서 검증을 수행하게 된다.

xRapid 란?

xRapid 는 xCurrent 와 유사하지만, 유동성 비용을 최소화 하고 국가간의 지불 거래를 더욱 빠르게 해준다.

기존의 국제 송금에 필요한 중계를 흔히 아는 XRP 코인을 기반으로 하여 그 과정을 생략하는 것이다.

중간에서 유동성을 공급해주는 은행들이 XRP를 기반으로 통일한다면 중개 통화 역할을 하게 되며

원화 / 달러 / 유로 등의 통화 계좌 관리가 심플해지고 이에 따라 불필요한 프로세스가 줄어들어 더 빠른 속도로 전송이 가능하다.

장점

1. 빠르다. 거래 속도도 4초에서 길게 봐야 몇분 이내에 일어난다

2. 수수료가 쌈

3. RTP (Real Time Payment) 가 가능하여 변동성이 적음

4. 블록체인 내 같은 데이터를 공유하여 신뢰성 확보

기타..

이 외에 xVia 라는 솔루션도 함께 Ripplenet 으로 통합된 것 같다.

최근 리플에서 CBDC 관련된 백서도 공개 했는데

https://ripple.com/wp-content/uploads/2021/01/cbdc-whitepaper-2020.pdf

CBDC 도입 시 리플이 필요한 이유를 설명해준다.

1. Interoperability

- 다른 CBDC간의 거래가 가능한 표준을 만들어야 한다.

2. Public and Private Partnerships

- 공공과 개인의 교류가 필요하다.

3. Neutral Bridge Cureencies

- 중립적인 브릿지 화폐를 사용해야 한다.

REFERENCES

https://namu.wiki/w/SWIFT%20%EC%BD%94%EB%93%9C

https://www.theswiftcodes.com/

http://xrpinfo.kr/article/%EC%A0%95%EB%B3%B4/1002/450/

[gRPC] gRPC 서비스 개발

GOD동하 — Mon, 5 Jul 2021 15:44:26 +0900

https://godd.tistory.com/88

[gRPC] gRPC 개념

gRPC란? gRPC는 구글에서 만든 HTTP2 기반의 RPC 통신을 위한 프레임워크이다. Google에서 내부 RPC 통신을 위해 만들던 Stubby 프로젝트를 기반으로 표준화하여 오픈소스로 공개했다. 이전에 구글에서 IDL

godd.tistory.com

gRPC 개념에 대해서는 위 포스팅을 참고,

여기서는 gRPC 서비스 개발을 위한 프로세스와 코드 구현에 대해서 알아본다.

gRPC 통신 패턴

통신 패턴은 크게 Unary와 Stream 이 있다. 기본적으로 Client - Server 구조이기 때문에 Client / Server 각각이 어떤 통신을 하느냐에 따라서 아래와 같이 4가지로 구분될 수 있다.

gRPC 구현 프로세스

구현 프로세스는 1. proto file 을 정의한 후 2. compile을 통해 stub/skeleton을 생성하고 그 기반으로 3. client/server를 구현한다.

하나씩 살펴보도록 한다.

1. proto 정의

먼저 proto file을 정의한다. java 기준으로 src/main/proto 디렉토리에 proto 파일을 정의한다.

안에는 아래와 같은 정의를 한다.

syntax = "proto3";

package com.example.greeting;

service Greeting {
  rpc sayHelloToOne(Person) returns (Output);
  rpc sayHelloToMany(stream Person) returns (Output) ;
  rpc sayHelloToOneMultiple(Person) returns (stream Output);
  rpc sayHelloToManyMultiple(stream Person) returns (stream Output);
}

message Person {
  string name = 1;
}

message Output {
  string value = 1;
}

syntax : proto 버전을 명시

package : package를 정의하며, 여기에 정의된 패키지로 stub이 생성된다.

service : 실제 서비스를 정의하며 인터페이스를 이 안에서 정의한다.

rpc : 메소드 인터페이스를 정의한다. Request와 Response에 stream 키워드로 정의할 수 있다.

message : RPC 통신을 할 때 주고받을 데이터에 대해 정의한다.

2. proto compile

proto 파일 Compile 후 stub을 생성해주는 단계이다.

Maven Plugin 기반으로 컴파일하는 형태로 설명할 예정이고, 아래와 같이 설정했다.

<plugin>
	<groupId>org.xolstice.maven.plugins</groupId>
	<artifactId>protobuf-maven-plugin</artifactId>
	<version>0.6.1</version>
	<configuration>
		<protocArtifact>com.google.protobuf:protoc:3.12.0:exe:${os.detected.classifier}</protocArtifact>
		<pluginId>grpc-java</pluginId>
		<pluginArtifact>io.grpc:protoc-gen-grpc-java:1.36.0:exe:${os.detected.classifier}</pluginArtifact>
		<outputDirectory>${basedir}/src/main/java</outputDirectory>
		<clearOutputDirectory>false</clearOutputDirectory>
	</configuration>
	<executions>
		<execution>
			<goals>
				<goal>compile</goal>
				<goal>compile-custom</goal>
			</goals>
		</execution>
	</executions>
</plugin>

그 후 1단계에서 정의된 proto 파일로 컴파일을 하고 나면, client / server간의 RPC 통신을 위한 코드가 생성된다.

protobuf:compile-custom을 하고 나면 아래와 같이 GreetingGrpc 코드가 생긴다. RPC 에서의 stub/server Layer 코드를 생성해주며, 이를 기반으로 비즈니스 로직을 개발하면 된다. 이름은 proto 파일의 service 명 기준으로 생성됨.

protobuf:compile을 하고 나면 아래와 같이 Hello 코드가 생긴다. RPC 에서의 Protocol Layer (Message) 코드를 생성해주며, 이를 사용하여 Request, Response 메세지를 주고 받는다.

3. client 및 server 구현

컴파일하여 나온 코드를 기반으로 Client / Server 를 개발하면 된다.

Stub 을 이용하여 Server와 통신을 할건데, 이 때 Channel을 통해서 하게 된다.

ManagedChannel channel = ManagedChannelBuilder.forAddress("localhost", 50051)
	.usePlaintext()
	.build();

GreetingBlockingStub stub = GreetingGrpc.newBlockingStub(channel);

channel 객체를 생성한 후 stub은 그 channel을 통해 서비스를 호출할 수 있다.

정리하면, Channel은 Client 와 Server 간 통신을 위한 객체이고 Stub은 channel을 통해 서비스를 호출할 수 있는 추상화된 객체라고 보면 된다.

Stub 방식은 blocking, async, future 3가지로 사용이 가능하다.

Unary 통신 개발

Client의 stub을 생성하여 Request (Person input) 를 생성한 후 데이터를 stub의 method로 호출하면 channel을 통해 메소드가 호출이 된다.

Server는 메소드가 호출이 되고 onNext 를 통해 데이터를 전송, onCompleted() 시점에서 connection이 종료된다.

Server Streaming 통신 개발

Client 에서는 이전 Unary 통신과 같고, 호출을 하면 Server에서 onNext를 통해 Stream 형태의 데이터를 전송한다.

onCompleted() 시점에서 Connection이 종료되고, 그 전까진 Client에서 stream을 받아 처리하는 형태로 개발한다.

Client Streaming 통신 개발

Client에서는 onCompleted() 시점에서 Stream 형태가 종료되면 Server의 Response 데이터를 리턴,

Server는 onNext()를 재정의하여 Stream 형태의 데이터를 받아서 처리한다.

여기서 onNext마다 resObserver.onNext()로 데이터를 처리하여 보내주게 되면, 양방향 Streaming이 된다.

[gRPC] gRPC 개념

GOD동하 — Mon, 5 Jul 2021 15:44:11 +0900

gRPC란?

gRPC는 구글에서 만든 HTTP2 기반의 RPC 통신을 위한 프레임워크이다.

Google에서 내부 RPC 통신을 위해 만들던 Stubby 프로젝트를 기반으로 표준화하여 오픈소스로 공개했다.

이전에 구글에서 IDL (Identity Definition Language) 로 인터페이스를 정의하는 언어인 Protocol Buffer를 제공했는데 HTTP/2 에 이 Protobuf 를 기반으로 RPC 통신을 할 수 있다.

그럼 여기서 몇가지 선수 개념을 짚고 넘어가면,

1. RPC

RPC는 Remote Procedure Call의 약자로 Client-Server 환경에서 통신 개발을 편하게 하기 위해서 등장했다.

Client에서는 function call을 통해 호출하여 응답 받고, Server에서는 외부에서 온 요청을 받아 응답을 해주는 형태이다. 이름 그대로 원격 서버의 프로시저를 호출할 수 있는 메커니즘으로 아래 그림에서 가장 중요한 개념은 Compiler가 IDL의 정의를 해당 언어로 생성해준 중간 Layer인 Stub인데, 여기서 마샬/언마샬링 처리를 통해 데이터 통신을 한다.

2. HTTP/2

HTTP/2 의 큰 특징은 헤더 데이터 압축과 Multiplexing으로 인한 성능 향상이다.

HTTP/1버전대에서의 Connection 비용 문제, 이를 위해서 keep-alive를 하지만 요청에서의 병목 현상이 있었고 pipelining을 함으로써 1.1 버전의 형태가 됐었다.

그리고, HTTP/1.1 에서 HOL 문제를 Multiplexing으로 해결한게 HTTP2이다.

HOL (Head Of Line) Blocking 문제란?

pipeline을 통해서 응답이 오기 전 요청을 모두 보내놓지만, 그림에서 보듯이 첫번째 (Head) 요청의 응답이 오기 전까진 다음 응답이 오지 않는다. 이 때 첫 요청이 지연될 경우 다른 요청들은 blocking 되는 현상이다.

이를 해결한 것이 HTTP/2 이다.

3. Protocol Buffer

Protocol Buffer란?

IDL(Interface Definition Language) 로 정의된 데이터 구조를 Byte 형태로 직렬화하는 방식

기존에 아래와 같이 주고받는 메세지는 HTTP 기반의 JSON으로 통신을 했다면,

gRPC는 HTTP/2 기반의 Protocol Buffer로 통신함으로써 Byte 형태로 메세지를 주고받는다.

그럼 여기서 어떤 형식으로 인코딩 되는지 살펴보자.

메세지는 위와 같이 필드들로 구성되어 있고, 필드는 다시 Tag / Value로 이루어져 있다.

JSON으로 따지면 Property : Value 의 매핑이라고 보면 됨.

Tag는 다시 Field Index 와 Type으로 이루어져 있는데, 아래 message 정의를 보면 string, int64와 같은게 Type이고 1, 2, 3번과 같은 값이 Field Index이다.

타입은 아래와 같다.

Type	Meaning	Used for
0	Varint	int32, int64, uint32, uint64, sint32, sint64, bool, enum
1	64-bit	fixed64, sfixed64, double
2	Length-delimited	string, bytes, embedded 메세지s, packed repeated fields
3	Start group	groups (deprecated)
4	End group	groups (deprecated)
5	32-bit	fixed32, sfixed32, float

여기서 보면 타입은 6개로 고정되어 있다. 이 6개를 binary 형태로 표현하면 3bit만 필요하다.

그래서 Type 은 3bit를 할당하고 나머지 bit는 Field Index에 할당을 해준다.

Tag를 위해 최소한으로 1byte를 할당해주며 Type을 위한 3bit 제외하고 나머지 5bit로 Field Index를 표시한다.

위 그림과 같이 string user_name = 1; 은 1번 인덱스이므로 00001 / string type은 2이므로 010 으로 인코딩 된다.

예를 들어, 위 메세지 정의와 데이터로 인코딩을 하게 되면 "userName" : "Martin" 은 아래와 같이 인코딩 된다. 이 경우 19 byte가 필요하다. 하지만 인코딩을 하게 되면..

Tag는 1byte로 표시되어 0a, 가변길이의 length를 1byte, 각각은 UTF-8로 인코딩 되어 8byte면 충분히 인코딩 된다.

gRPC의 장단점은 아래와 같다.

다음 포스팅에서 실제 개발에 대한 내용을 정리하겠다.

[블록체인] 카르다노 (ADA) 백서 정리 #2 - 메커니즘

GOD동하 — Wed, 23 Jun 2021 17:42:44 +0900

https://godd.tistory.com/96

[블록체인] 카르다노 (ADA) 백서 정리 #1 - 동기

카르다노는 플랫폼이고 ADA는 그 플랫폼 상에서 통용되는 가상화폐라고 보면 된다. 백서를 보면 카르다노에 대해서 정리가 되어있는데, 블록체인 상의 플랫폼 위주의 설명임 카르다노의 창립자

godd.tistory.com

카르다노가 나오게 된 동기는 위 포스팅에서 확인할 수 있다.

백서에서 소개된 카르다노만의 메커니즘을 이 포스팅에서 다뤄본다.

백서에서 소개하는 목차는 아래와 같고 순서대로 정리해본다.

1. PoS (지분 증명)

2. Social Elements of Money (돈의 사회적인 요소)

3. Designing in Layers - Cardano Settlement Layer (계층 설계 - 카르다노 세틀먼트 레이어)

4. Scripting (스크립팅)

5. Side Chain (사이드 체인)

6. Signitures (서명)

7. User Issued Assets (UIAs) (사용자 발행 자산)

8. Scalability (확장성)

9. Cardano Computation Layer (카르다노 연산 레이어)

10. Regulation (규제)

Proof of Stake

카르다노는 지분 증명 (PoS)를 사용하며 우로보로스라고 불리는 프로토콜을 사용한다고 한다.

※ 포스팅 참고 : https://godd.tistory.com/97

[블록체인] Proof of Stake (PoS) 란?

P2P 기반의 블록 체인을 유지하기 위해서는 ①노드들의 블록 생성을 유도하고, ②생성된 블록에 대한 검증 및 단일 체인을 채택해야 한다. 기존의 PoW (Proof of Work) PoW의 경우 컴퓨팅 파워 기반으로

godd.tistory.com

이 방식을 채택함으로써 미래에 대비할 수 있는 충분한 유연성을 확보했다고 한다.

Social Elements of Money

비트코인 vs 라이트코인 / 이더리움 vs 이더리움 클래식
기술적으로는 차이가 없다..라이트코인, 이더리움 클래식은 강력하고 역동적인 커뮤니티, 사회적 의무를 유지하고 있다

암호화폐의 다양성을 보이는건 사회적 요소에 대한 근거를 둔다.

철학, 통화 정책, 개발자 사이의 의견 충돌 등이 Fork로 이어지게 됨.

현금으로 보면 정치적 변화나 지역적인 충돌에도 통화 위기나 대규모 이탈 없이 살아남는다.
여기서 레거시 시스템의 요소들을 차용할 필요가 있다는 것이다.

카르다노 사용자들에게는 사회적 계약을 이해하기 위한 인센티브가 필요하고,

생산적인 방법으로 변화를 제안함에 있어서 자유를 가진다.

이 자유는 어떻게 시장이 규제되어야 하는지부터 어떤 프로젝트가 지원을 받아야 하는지 이르기까지 가치 교환 시스템의 모든 측면으로 확장된다.
중앙 집중화된 참여자에 의해 중개될 순 없고 rich한 소수에 의해 채택되어서도 안된다.

즉, 공평한 규제와 업데이트를 위해서 CSL 위에 구축되는 오버레이 프로토콜 시스템을 구현한다고 한다.

첫째, 탈 중앙화 된 신탁 시스템의 도입

-> 어느 사용자나 투표를 통해 자금을 지원 받을 수 있고 그에 대한 논의는 중앙화 된 기관이 아닌 CSL의 이해 관계자.

둘째, 소프트/하드 포크에 대해 제안하고 투표하기 위한 공식 시스템을 포함

-> 공식적인 규칙과 절차에 트랙잭션, 합의, 네트워크라는 부문을 가진 헌법처럼 검사할 수 있는 모델을 제공해야 함.

Designing in Layers - Cardano Settlement Layer

카르다노는 프로토콜이나 언어를 설계할 때 미래를 예상하는게 아니라 과거를 참조해서 만든다는데 아래는 그냥 참고

역사적 관점으로부터 아래와 같은 원칙을 따라 설계했다.
1. 미래를 예측하지 못하므로 변화할 수 있는 여지를 만든다.
2. 단순한게 좋다.
3. 사공이 많으면 배가 산으로 간다.
4. 표준이 설정되면 차선책인지 여부에 관계 없이 지속될 것이다.
5. 나쁜 아이디어라도 좋은 아이디어로 진화시킬 수 있다.

블록체인은 타임스탬프와 불변성에 대한 보장을 해주는 기술이고, 돈의 맥락에서는 자산의 소유권을 제공해준다.

크게 블록체인 플랫폼 위에서는 아래와 같이 두가지 개념이 공존한다.

- 자산의 이동

- 프로그램 저장 및 실행과 같은 연산

이 형태는 몇가지 문제점을 제기하며 Layer 구분을 강조한다.

1. 설계 원칙(관심 사항의 분리)에 위배된다.

이더리움의 경우 거래는 스마트 컨트랙트를 통해 하게 되고 자산의 이동도 같은 맥락으로 처리 된다.

이는 임의의 거래를 스크립트로 만들고 사기를 칠 경우 임의로 허가하여 트랜잭션을 롤백할 수도 있다는 걸 의미한다.

2. 메타데이터 저장에 대한 문제가 있다.

어떤 메타 데이터를 저장할 것인지 결정 문제.

언제까지 메타 데이터를 저장할 것인지 문제. (국가 별 개인정보 보관 기관과 같은 법 관련)

3. 유출하고 싶지 않은 프로그램 연산을 공개해야 한다.

예를들어, 회사 직원의 평균 연봉 측정 관련 연산 시 모든 연산을 공개적으로 알려야 한다면 각 개인의 연봉을 유출하게 될 수도 있다.

그래서 카르다노는 자산 관련 CSL과 연산 관련 CCL 레이어를 분리함으로써 스마트 컨트랙트의 설계, 사용, 개인정보 보호 등을 더 융통성 있게 허용한다고 한다.

기존의 분리되지 않은 체인의 경우 Block #13 에 다른데서 만든 스크립트로 인해 문제가 있거나 금융 규제로 인해 메타데이터를 삭제해야 한다면 합의를 통해 Hard Fork 할 수 밖에 없다.

그러나 자산 관리와 연산 로직에 대한 Layer를 분리하게 되면,

위 그림과 같이 CSL은 자산 관련된 정보를 처리하고, CCL은 다른 메타데이터를 저장하게 되므로 금융 규제나 스크립트 문제가 발생해도 CCL에서만 fork를 하므로 내 돈과는 관련이 없어진다.

레이어 분리에 대한 로드맵의 목표는 아래와 같다.

1. 두가지 스크립트 언어 set에 대한 지원.
- 자산의 이동 (실제 돈의 이동)
- 오버레이 프로토콜에 대한 지원을 강화 (스마트 컨트랙트)
2. 다른 Ledger와의 KMZ 사이드 체인 지원
3. 양자 저항 시그니처를 포함한 여러 유형의 시그니처 지원
4. 다중 사용자가 발행한 자산 지원
5. 확장성 달성, 더 많은 사용자가 가입할수록 시스템 기능이 향상됨

Scripting

카르다노에서 Simon이라는 신규 언어를 선택했는데

이 언어의 주요 개념은 금융 트랜잭션이 보통 기본적인 요소들의 집합으로 구성되어 있으므로 일반적인 프로그래밍 없이 대부분의 트랜잭션 유형들을 지원할 수 있다는 점이다.

이걸 사용한 장점은

1. 보안이나 프로그램 실행 이벤트를 철저하게 다룸

-> 새로운 돈을 생성하는 등의 문제가 있는 거래 이벤트 실행을 철저하게 다루도록 작성이 가능
2. 새로운 기능이 필요한 경우 소프트 포크를 통해 확장이 가능함
-> CSL과 특수 목적 서버나 기존 금융 시스템, 오버레이 프로토콜 등과 연결이 필요한 경우 소프트 포크로 업데이트

또한, 스마트 컨트랙트 언어로는 상호운용성을 위한 DSL로 하스켈 기반의 함수형 언어인 Plutus를 사용한단다.

Sidechains

카르다노는 작업 증명의 증명 (Proofs of proofs of works) 을 기반으로 한 KMZ Sidechains 를 지원한다.

(이거 논문 정리 -> http://fc16.ifca.ai/bitcoin/papers/KLS16.pdf)

Sidechain을 통해 CSL에서 CCL, 프로토콜이 지원되는 다른 블록체인으로 안전하게 이동할 수 있다.

KMZ Sidechain은 캡슐화가 잘 되어 있어 CSL에서는 실질적으로 블랙박스이지만 계산이 완료된 자산에 대한 정보는 알 수 있도록 보장할 수 있다.

Sidechain을 통해 다른 블록체인 (CCL 포함) 과의 이동이 가능하다.

Signitures

기본적으로 그림과 같이 Alice가 Bob에게 자산을 보낼 때는 공개키 기반의 전자서명을 포함해서 보낸다.

암호화폐가 이 서명 체계를 선택할 때 직면하는 조건은

1. 구조 자체에 장기적인 보안 내구성이 있는가

2. 사용하는 기관에서 사용하는 특정 서명 체계를 따를 수 있는가

결국 서명을 사용함에 있어서 확장성을 제공해야 한다는 말인데, 카르다노는 타원 곡선 암호화 기술인 Ed25519 curve를 사용하면서 HD Wallet에 대한 지원을 추가함으로써 기존의 라이브러리를 향상시켰다.

여러 서명 체계로 확장한 사례는 많은 의미가 있다.

- 추후 양자 컴퓨팅으로 인한 서명 알고리즘 무효화를 방어할 수 있는 알고리즘으로 향상 가능

- 타 암호화폐와의 상호 운용성을 향상 시키기 위한 서명 체계 추가 가능

User Issued Assets (UIAs)

UIA는 한마디로 토큰이다.

Cardano는 토큰을 위해서는 다음과 같은 것들이 필요하다고 한다.

매우 큰 UTXO 상태를 추적 할 수 있도록 특수 목적으로 인증된 데이터 구조
대기중인 트랜잭션 집합을 보유 할 수있는 분산형 mempool 기능
거대한 글로벌 블록 체인을 허용하는 블록 체인 파티셔닝 및 체크 포인트
서로 다른 체계의 거래를 포함하는 합의 노드를 보상하기 위한 인센티브 제도
사용자가 추적하려는 통화를 결정할 수있게 하는 구독 메커니즘
UIAs가 기본 자산과 유사한 보안을 누릴 수 있는 강력한 보안 보장
UIA와 기본 토큰 간의 유동성 개선을 위한 탈중앙화 된 시장 지원

Scalability

현재 암호화폐의 블록체인은 Append-Only Linked List 이다.

합의 알고리즘의 경우 노드들이 항상 같은 일을 하므로 처리 및 스토리지 성능을 향상시키기 어렵다.

카르다노는 탈중앙화 된 Ouroboros 협의체 선출 방식을 이용하여 확장성을 제공한다.

예를 들면, 특정 기간동안 Ledger를 유지하는 협의체로 선출하여 신뢰할 수 있는 특정 노드 집합을 통해서 트랜잭션들을 처리하고 다른 곳으로 분할하는 방식을 사용한다.

Cardano Computation Layer

CCL 에서의 기능은 두가지가 있을 수 있음

1. Private 한 단발성 프로그램

-> 이 경우 기존 블록체인 패러다임을 피하는게 좋음.

신뢰해야 하는 게시판이나 메세지 패싱의 채널로만 CSL을 레퍼런스 하면 됨

2. 이더리움과 비슷한 Ledger

-> 블록체인 필요

-> Plutus 라는 Solidity와 비슷한 스마트 컨트랙트 언어 지원

Regulation

금융에 있어서 규제는 필요하다. 하지만, 암호화폐 도입을 위해서는 문제점이 많다

카르다노는 개인이 자산을 관리하는 권리와 정부기관과 같은 시장들의 권리를 나눠서 생각해야 한다고 한다.

1. 개인적으로 항상 자신의 자산을 독자적으로 접근해야 한다.

어떤 기관의 접근은 허용하지 않고 최소한의 공통 분모만 가지도록 설계 한다.

2. 블록체인을 기반으로 History에 대한 불변성을 제공한다. 특정 그룹에 변경에 대한 권한을 가지면 악용을 하기 때문.

3. 자산의 이동은 누구나 할 수 있다.

[블록체인] Proof of Stake (PoS) 란?

GOD동하 — Wed, 23 Jun 2021 11:44:04 +0900

P2P 기반의 블록 체인을 유지하기 위해서는 ①노드들의 블록 생성을 유도하고, ②생성된 블록에 대한 검증 및 단일 체인을 채택해야 한다.

기존의 PoW (Proof of Work)

PoW의 경우 컴퓨팅 파워 기반으로 작업 증명을 이뤄내 블록을 생성하는데, 노드들의 블록 생성을 유도하기 위해 ①블록을 채굴한 Miner들에게 보상을 지급하고 ②컴퓨팅 파워가 가장 많이 들어간 Longest Chain 만을 채택하도록 하였다.

근데 PoW는 전력 소모가 심하고 채굴 단합등으로 인해 몇 세력들로 중앙화 되는 형태로 변질되기도 하였다.

그럼 PoS (Proof of Stake) 는?

PoS (Proof of Stake) 는 자산을 얼마나 가지고 있는지 Stake(지분) 에 따라서 블록을 형성할 확률이 더 높아진다.

지분이 많을수록 해당 네트워크를 필요로 하고 그로 인해서 체인을 잘 유지하려고 한다는게 전제이다.

그림을 보면 B가 지분이 제일 많아 40% 확률로 권한을 획득하여 블록을 형성하고 나머지 노드들은 검증자 (validator)로써 자산들을 증명하게 되고 거래들의 수수료로 나온 보상으로 지분에 대한 이자를 지급된다.

확률상으로 봤을 때 10개의 블록이 형성되면, A는 3개 / B는 4개 / C는 3개 를 형성하게 된다.

블록을 형성하면 노드들은 블록에 합의를 하기 위해 자신들의 지분을 증명하게 된다.

지분이 많을수록 체인을 계속해서 유지할 것이고 블록체인에 참여를 하게 되는 노드들은 ①지분에 따라 공평하게 블록 형성 권한을 받고 블록 형성 시 발생하는 보상을 지분만큼 이자로 받는 개념이 적용되는 것이다.

또한, 참여한 노드들은 자신이 합의하는 블록들을 증명하고 fork된 체인들은 ②더 많은 지분을 검증하는 블록을 보유하는 체인으로 합의가 이뤄진다.

그럼 블록 형성할 노드를 어떻게 선출하지?

보통 지분의 크기에 따라 블록의 형성할 확률이 결정되는데 일반적인 확률상으론 가장 지분이 많은 노드만 선택되는 것을 방지해야 하며 대표적으로 아래 방식들이 있다.

Randomized Block Selection

각 노드들 중 가장 낮은 해시값과 가장 높은 지분의 조합을 가진 노드를 검증자로 선택

Coin Age Selection

토큰이 얼마나 오래 Staking 되었는지에 따라 선택. 코인을 Staking 한 일수 x 코인의 지분 크기로 선출하게 된다.
계속해서 선출되는 것을 막기 위해 Staking 일수를 aging 한다. 한번 선출되면 다시 Staking 일수를 0 부터 시작한다.

Ouroboros PoS 는 무엇인가?

지분 증명의 경우 Stale Grinding Attack 이라는 공격에 취약한데, 노드를 선출하기 위해 마지막 블록 생성자는 추첨을 통해 랜덤 변수를 생성하는데 이 랜덤 변수를 조작할 수 있다는 것이다.

이전 블록 생성자가 자신을 선출할 때 랜덤 변수를 계산하면서 조작하는것을 방지하기 위해서 랜덤 변수 생성에 전체 노드가 참여하는 방식이다.

-> 카르다노에서 채택

※ 참고 : http://wiki.hash.kr/index.php/%EC%9A%B0%EB%A1%9C%EB%B3%B4%EB%A1%9C%EC%8A%A4_%EC%A7%80%EB%B6%84%EC%A6%9D%EB%AA%85

우로보로스 지분증명 - 해시넷

우로보로스(Ouroboros) 그림 (1478년) 우로보로스 지분증명(OPoS, Ouroboros PoS, Ouroboros Proof of Stake)은 기존 지분증명(PoS) 방식의 문제점인 그라인딩 공격(Grinding Attack)을 방어하기 위해 코인토싱(coin tossing

wiki.hash.kr

PoS 체인 합의할 때 치명적인 문제점

PoS에는 'Nothing at Stake' 라는 문제점이 있는데 지분 증명의 한계 비용이 없다는 것이다.

일단 블록을 형성할 때 악의적으로 fork를 발생시켜 여러 branch가 생길 경우, Validator들은 어떤 블록이든 자신의 지분을 증명하게 될 것이다. 아래 설명을 보자.

Chain의 길이에 따라서 두가지 Attack이 발생한다.

Long Range Attack

지분이 많은 Validator가 악의적인 목적으로 두 체인의 블록을 모두 올바른 블록이라 검증하는 것이다.

그렇게 긴 체인이 형성된 경우 새로 참여한 Validator는 모든 체인이 올바르다고 생각할 것이다. 이 경우 새로 참여한 Validator가 지분이 많으면 악의적인 블록에도 합의를 해버리게 되므로 올바른 거래들도 모두 공격 당하는 형태가 된다.

Short Range Attack

일단 악의적인 fork가 발생하고 나면, Validator들은 항상 두쪽 체인을 합의하려고 할 것이다. 두 체인에 대해 자신의 지분을 증명했다면 어떤 체인이 선택되든 보상받을 수 있기 때문이다.

이렇게 악의적인 체인이 발생했을 때 양쪽에 지분 증명을 해도 잃을 것이 없다는 'Nothing at Stake' 문제가 있다는 것이다. 이 문제는 체인 유지를 함에 있어서 큰 문제이다.

이럴때 해결방안

리워드를 통해 획득한 지분은 특정 기간 이후 사용 가능하게 하여 검증할 수 있는 네트워크 시간을 확보하고

만약에 노드 형성 시 악의적인 거래가 발견될 경우 형성자는 지분을 잃고 추후 블록 형성에 참여할 수 없다.

최근에는 전력 소비로 인한 환경문제 때문에 PoS를 채택한 블록체인 플랫폼들이 많아지고 있으며 필연적으로 보인다.

[블록체인] 카르다노 (ADA) 백서 정리 #1 - 동기

GOD동하 — Tue, 22 Jun 2021 17:55:28 +0900

카르다노는 플랫폼이고 ADA는 그 플랫폼 상에서 통용되는 가상화폐라고 보면 된다.

백서를 보면 카르다노에 대해서 정리가 되어있는데, 블록체인 상의 플랫폼 위주의 설명임

카르다노의 창립자는 전 이더리움의 CEO로 아마 이더리움의 단점들을 잘 보완할 수 있는 플랫폼을 만들지 않았을까..

이번 포스트에서는 카르다노의 백서를 살펴본다.

https://why.cardano.org/

Why Cardano

Documentation Gatsby starter for IOHK's web assets.

why.cardano.org

카르다노가 만들어진 Motivation에 대해서 요약하자면, 기존의 암호화폐는 아래와 같은 문제점이 있어 해결할 필요가 있다는것이다.

1. 암호화폐의 설계에 Layer가 없다.
- Accounting과 Computation 이 단일 Layer에서 동작을 한다. 즉, 실제 플랫폼 위에 동작하는 Dapp 들과 비용은 분리해야 한다.
2. DPoS 와 같은 합의 알고리즘이 있는데 사용하지 않는다.
- PoW 말고 PoS와 같은 알고리즘이 기존에 존재 했는데 이걸 사용하는게 더 좋다.
3. 소프트 또는 하드 포크 업데이트에 대비하지 않았다.
- 업데이트 때문에 발생하게 되는 분기되는 문제에 대비해 생태계를 유지하는 것이 필요하다.
4. 기존 상거래에 대한 특성들을 적용시키기 어렵다.
- 화폐의 이동 뿐만 아니라 여러 거래 관련 기록들도 관리할 수 있어야 한다.

위 문제들을 해결하기 위한 메커니즘들에 대한 소개가 나오겠지 이제.

아래는 백서 Motivation 부분 전체 번역본이다.

Motivation

Cardano is a project that began in 2015 as an effort to change the way cryptocurrencies are designed and developed. The overall focus beyond a particular set of innovations is to provide a more balanced and sustainable ecosystem that better accounts for the needs of its users as well as other systems seeking integration.
In the spirit of many open source projects, Cardano did not begin with a comprehensive roadmap or even an authoritative white paper.

카르다노는 암호화폐가 설계되고 개발되는 방식을 바꾸기 위한 노력으로 2015년에 시작한 프로젝트이다.

더 균형있고 지속 가능한 에코시스템을 제공하는 것에 전반적인 포커스가 맞춰져 있으며, 통합을 추구하는 다른 시스템뿐만 아니라 사용자들의 니즈를 잘 충족시키기 위함이다.

많은 오픈 소스 프로젝트의 정신으로, 카르다노는 종합적인 로드맵이나 권위있는 백서조차도 없이 시작했다.

카르다노가 추구하는 품질은 곧 Sustainability (지속 가능성), Compatibility (호환성) 에 초점을 맞추는듯 하다.

하드 포크와 같은 다른 생태계가 생기는 것을 지양하고 플랫폼 특성 상 다른 시스템과의 호환을 통해 Integration에 초점을 맞추는 것 같다. 이런 품질과 관련해서는 뒤에 얘기가 나올듯

Rather it embraced a collection of design principles, engineering best practices and avenues for exploration. These include the following:
- Separation of accounting and computation into different layers
- Implementation of core components in highly modular functional code
- Small groups of academics and developers competing with peer reviewed research
- Heavy use of interdisciplinary teams including early use of InfoSec experts
- Fast iteration between white papers, implementation and new research required to correct issues discovered during review
- Building in the ability to upgrade post-deployed systems without destroying the network
- Development of a decentralized funding mechanism for future work
- A long-term view on improving the design of cryptocurrencies so they can work on mobile devices with a reasonable and secure user experience
- Bringing stakeholders closer to the operations and maintenance of their cryptocurrency
- Acknowledging the need to account for multiple assets in the same ledger
- Abstracting transactions to include optional metadata in order to better conform to the needs of legacy systems
- Learning from the nearly 1,000 altcoins by embracing features that make sense
- Adopt a standards-driven process inspired by the Internet Engineering Task Force using a dedicated foundation to lock down the final protocol design
- Explore the social elements of commerce
- Find a healthy middle ground for regulators to interact with commerce without compromising some core principles inherited from Bitcoin

오히려 카르다노는 설계 원칙들의 모음, 엔지니어링 BP 사례와 탐구를 위한 방안들을 수용했다. 다음 것들을 포함해서.

- 회계와 연산을 다른 Layer로 분리

- 높은 모듈화된 기능 코드로 코어 컴포넌트들 구현

- 소규모 그룹의 학술 집단과 개발자들이 피어 리뷰 연구와 경쟁

- InfoSec 전문가들을 조기에 활용하는걸 포함하여 여러 학술 분야에서 적극 활용

- 리뷰동안 발견되는 이슈를 수정하기 위해 필요한 백서, 구현, 새로운 연구들 빠른 Iteration으로 수행

- 기존 네트워크 파괴 없이 시스템 업그레이드 할 수 있는 능력 구축

- 향후 작업을 위한 탈중앙화된 펀딩 메커니즘의 개발

- 합리적이고 안전한 UX로 모바일 상에서 작동할 수 있도록 암호화폐의 설계를 개선하는 장기적인 관점

- 이해관계자들을 암호화폐 유지와 운영에 긴밀하게 접근하도록 유도

- 동일한 장부에서 여러 자산들을 처리할 필요가 있음을 인정

- 레거시 시스템의 니즈에 더 잘 따르기 위해서 선택적으로 메타데이터를 포함시키도록 거래들을 추상화

- 천여개의 알트 코인에서 의미있는 기능들을 학습

- IETF를 참고하여 표준 기반의 프로세스를 채택하고 최종 프로토콜 설계를 확정

- 상거래의 사회적 요소 탐구

- 비트코인으로부터 상속받은 핵심 원칙을 지키면서 상거래와 상호 작용할 수 있는 Healthy한 중간 지점을 탐색

From this unstructured set of ideas, the principals working on Cardano began both to explore cryptocurrency literature and to build a toolset of abstractions. The output of this research is IOHK’s extensive library of papers
, numerous survey results such as this recent scripting language overview as well as an Ontology of Smart Contracts, and the Scorex project. Lessons yielded an appreciation for the cryptocurrency industry’s unusual and at times counterproductive growth.

이런 체계화되지 않은 아이디어들로부터, 카르다노에서 일하는 주체들은 암호화폐 문헌을 탐구하고 추상화하기 위한 도구들을 만들기 시작했다. 이 연구들의 결과는 IOHK의 광범위한 논문 라이브러리와 최근 스크립트 언어에 대한개요 뿐만 아니라 스마트 컨트랙트의 온톨로지, 스코렉스 프로젝트 등에 대한 서베이 보고서들이다. 이 교훈은 암호화폐 산업의 비정상적이고 때때로 비생산적인 성장에 대한 실체를 알게 해줬다.

First, unlike successful protocols such as TCP/IP, there is little layering in the design of cryptocurrencies. There has been a desire to preserve a single notion of consensus around facts and events recorded in a single ledger, regardless of whether it makes sense.
For example, Ethereum has encumbered enormous complexity attempting to become a universal world computer, but suffers from trivial concerns potentially destroying the system’s ability to operate as a store of value. Should everyone’s program be a first class citizen regardless of its economic value, cost to maintain, or regulatory consequences?

첫째, TCP/IP 와 같은 성공적인 프로토콜들과 달리, 암호화폐의 설계에는 Layer가 거의 없다. 하나의 원장에 기록된 이벤트와 사실들을 둘러싼 합의에 대해 단일 개념을 유지하려고 했다.

예를 들면, 이더리움은 저장소로 동작하는 시스템의 능력을 잠재적으로 파괴할 수 있는 사소한 우려들부터 어려움을 겪고 있다.

-> https://blog.ethereum.org/2016/10/13/announcement-imminent-hard-fork-eip150-gas-cost-changes/

Announcement of imminent hard fork for EIP150 gas cost changes

During the last couple of weeks, the Ethereum network has been the target of a sustained attack. The attacker(s) have been very crafty in locating vulnerabilities in the client implementations as well as the protocol specification. While the recent patches

blog.ethereum.org

EIP-150에 대한 패치 내용으로 *SLOAD와 같은 IO-heavy한 연산에 대해서 Gas 비용을 더 받겠다는 내용이다.

Accounting과 Computation 이 단일 Layer에서 동작을 한다. 즉, 실제 플랫폼 위에 동작하는 Dapp 들과 비용은 분리해야 한다는 얘기를 하고 싶나보다.

* SLOAD : 이더리움에서 Gas 비용이 비싼 저장연산

Second, there is little appreciation for prior results in mainstream cryptographic research. For example, Bitshares’
Delegated Proof of Stake could have easily and reliably generated random numbers using coin tossing with guaranteed output delivery, which is a technique known since the 1980s (see the seminal paper by Rabin and Ben-Or).

둘째, 주요 암호학 연구의 이전 결과에 대해서 감사를 표하지 않았다. 예를 들어, Bitshares의 DPoS의 경우 결과 전달이 보장되는 동전 던지기를 사용하여 쉽고 신뢰성있는 보장된 난수값을 생성할 수 있는데, 그 기술은 1980년대부터 있던 기술이다.

Third, most altcoins (with a few notable exceptions such as Tezos) have not made any accommodation for future updates. The ability to successfully push a soft or hard fork is pivotal to the long-term success of any cryptocurrency.
As a corollary, enterprise users cannot commit millions of dollars worth of resources to protocols where the roadmap and actors behind them are ephemeral, petty or radicalized. There needs to be an efficient process through which social consensus can form around a vision for evolving the underlying protocol. If this process is enormously burdensome, fragmentation could break the community apart.

셋째, 대부분의 알트코인들은 미래의 업데이트에 대해서 수용하지 않았다. 소프트 또는 하드 포크를 성공적으로 적용할 수 있는 능력은 가상화폐의 장기적인 성공에 중추적인 역할을 한다.

필연적으로 기업 사용자들은 해당 프로토콜에 관계된 로드맵과 사용자가 임시적이고 사소하거나 급진적이라면 수백만 달러에 해당하는 자원을 투입할 수 없다. 프로토콜을 진화시키는 비전에 대해 사회적 합의를 형성할 수 있는 효율적인 프로세스가 필요하다. 만약 이 과정이 부담이 된다면, 분열로 인해 커뮤니티가 깨질 수 있다.

Finally, money is ultimately a social phenomenon. In the effort to anonymize and disintermediate central actors, Bitcoin and its contemporaries have also discarded the need for stable identities, metadata and reputation in commercial transactions. Adding these data through centralized solutions removes the auditability, global availability and immutability — which is the entire point of using a blockchain.
Legacy financial systems such as those composed of SWIFT, FIX and ACH are rich in transactional metadata. It is not enough to know how much value moved between accounts, regulation often requires the attribution of actors involved, compliance information, reporting suspicious activity, and other records and actions. In some cases, the metadata is more important than the transaction.

마지막으로, 돈은 궁극적으로 사회적인 현상이다. 중앙 행위자의 중개를 탈피하고 익명화하려는 노력속에서 비트코인과 같은 시기의 암호화폐들은 안정적인 신원, 메타데이터, 그리고 상거래에 대한 평판들을 폐기해왔다. 이 데이터들을 중앙 집중화된 솔루션을 통해 추가하게 되면 감사 가능성, 전역 가용성 및 불변성이 제거되어버리는데 이 특성들은 블록체인을 사용하는 가장 중요한 이유이다.

SWIFT, FIX, ACH등으로 구성된 레거시 금융 시스템은 거래 메타데이터가 풍부하다. 얼마의 값이 계정간에 이동하였는지 아는것만으로는 충분하지 않다. 규제는 종종 관련된 행위자의 속성, 규정 준수 정보, 의심스러운 행위 보고와 다른 기록들과 행위를 요구한다. 어떨때는 메타 데이터가 거래보다 더 중요하다.

Hence, it seems reasonable to infer that the manipulation of metadata could be as harmful as counterfeiting currency or rewriting transaction history. Making no accommodation for actors who want to voluntarily include these fields seems counterproductive to mainstream adoption and consumer protection.

그러므로, 메타데이터의 조작이 화폐위조나 거래기록을 다시 쓰는 것만큼 해롭다고 추론하는것은 타당하다. 자발적으로 이러한 값들을 포함시키기 원하는 참여자들을 수용하지 않는 것은 암호화폐가 주류로 채택되는 것과 소비자 보호 측면에서 비생산적으로 보인다.

[블록체인] Bitcoin 백서 정리 #3 - 정리

GOD동하 — Fri, 4 Jun 2021 15:47:02 +0900

https://godd.tistory.com/94?category=825121

[블록체인] Bitcoin 백서 정리 #2 - 메커니즘

https://godd.tistory.com/92 [블록체인] Bitcoin 백서 정리 #1 - 도입부 Bitcoin 백서는 사토시 나가모토라는 가명으로 발표한 신뢰할 수 있는 제 3자 없이 온라인으로 지불이 가능한 P2P 전자 화폐인 Bitcoin을..

godd.tistory.com

지난번은 비트코인이 동작할 수 있는 메커니즘을 정의한 포스팅이다.

이어서 지속적인 화폐 유통과 운영상의 필요한 정책들을 정리하는 방법을 정리한다.

Incentive

By convention, the first transaction in a block is a special transaction that starts a new coin owned by the creator of the block. This adds an incentive for nodes to support the network, and provides a way to initially distribute coins into circulation, since there is no central authority to issue them. The steady addition of a constant of amount of new coins is analogous to gold miners expending resources to add gold to circulation. In our case, it is CPU time and electricity that is expended.

관례적으로, Block의 첫번째 거래는 Block의 생성자에 의해 소유되는 신규 코인을 생성하는 특별한 거래이다. 이것은 노드들이 네트워크를 유지하도록 인센티브를 주는 것이다. 그리고 코인을 발행할 중앙 기관이 없기 때문에 최초로 코인을 유통할 수 있는 방법을 제공해준다. 일정량의 신규 코인 증가는 금을 유통하기 위해 자원을 소비하는 Miner들과 유사하다. 우리의 경우에는 컴퓨팅 시간과 전기를 소비하는 것이다.

Block 생성이 유일한 신규 코인 발행이라는 인센티브를 줌으로써 유통을 유지할 수 있게 해준다.

사실 비트코인은 Nick Szabo 가 고안한 Bit Gold 시스템과 매우 유사한데 실제로 Nick Szabo 는 금과 같은 역할을 할 수 있는 전자 화폐를 만드려고 했으며 금 유통 환경과 실제 Miner들이 시간과 힘을 써가며 금을 채굴 하는 것과 유사한 환경을 만들었다.

The incentive can also be funded with transaction fees. If the output value of a transaction is less than its input value, the difference is a transaction fee that is added to the incentive value of the block containing the transaction. Once a predetermined number of coins have entered circulation, the incentive can transition entirely to transaction fees and be completely inflation free.

인센티브는 또한 거래 수수료로 제공 받을 수 있다. 거래의 Output 값은 Input 값들보다 더 적다면, 그 차이는 거래가 포함되는 Block의 인센티브 값으로 수수료인 것이다. 일단 미리 정해진 수량의 코인이 모두 발행된다면, 인센티브는 완전히 거래 수수료 체제로 전환되고 인플레이션으로부터 자유로워진다.

실제 세상의 금의 한정 수량이 정해져 있듯이, 코인도 일정 수량 이상 채굴할 수 없다. 금이 무한정으로 채굴할 수 있다면 금의 가치가 없듯이 코인도 마찬가지로 보고 있다. 대신 코인이 모두 채굴되고 나면 Block을 계속해서 만들 이유가 없어지므로 거래 수수료를 인센티브로 지급함으로써 노드들은 지속적인 유통을 위해 일 할 것이다.

The incentive may help encourage nodes to stay honest. If a greedy attacker is able to assemble more CPU power than all the honest nodes, he would have to choose between using it to defraud people by stealing back his payments, or using it to generate new coins. He ought to find it more profitable to play by the rules, such rules that favour him with more new coins than everyone else combined, than to undermine the system and the validity of his own wealth.

인센티브는 정직함을 유지할 수 있게 해준다. 만약 욕심많은 Attacker들이 정직한 노드들보다 더 큰 CPU 파워를 가진다면, 그는 지불한 것들을 훔쳐 속이는 것과 새로운 코인을 생성할 지 선택해야 한다. Attacker들은 시스템과 자신의 부의 유효성을 약화시키기 보다 규칙대로 하는것이 더 많은 이득을 얻는것임을 알아야 한다.

과반수 이상의 CPU 파워를 가진 악의적인 노드가 있다 해도 결국 위변조를 위한 컴퓨팅 파워를 사용하는 것보다 인센티브를 획득하는 것이 자신에게 이득을 얻게 해줄 것이라고 얘기한다.

가치 유지를 위한 인센티브 정책으로 인해 악의적인 노드들이 없는 환경을 만들었지만, 전자 화폐 신뢰성 유지를 위해 전체 거래를 저장 할 공간이 너무 많지 않나 의문이 아직 남아있다.

Reclaiming Disk Space

Once the latest transaction in a coin is buried under enough blocks, the spent transactions before it can be discarded to save disk space. To facilitate this without breaking the block's hash, transactions are hashed in a *Merkle Tree [7][2][5], with only the root included in the block's hash. Old blocks can then be compacted by stubbing off branches of the tree. The interior hashes do not need to be stored.

코인의 최종 거래가 충분한 Block들에 묻힌다면, 이 전에 소비된 거래들은 저장 공간을 절약하기 위해 버려질 수 있다. Block의 해시 값을 깨지 않고 해결하기 위해 거래들은 Merkle Tree로 해시되어 오직 루트만 Block 해시에 포함된다. 오래된 Block들은 트리의 가지치기로 압축할 수 있다. 중간 해시들은 저장될 필요가 없다.

※ Merkle Tree는 이진트리 기반이지만 기존 이진트리는 검색을 위한 자료구조이면, 이건 검증을 위한 자료구조라고 설명된다.

오랫동안 코인이 사용되지 않아 Block 들이 쌓이면서 저장 공간을 위해 그 당시 거래들에 대한 내용을 버려야 할텐데, 모든 거래를 Merkle Tree로 만들어 가지고 있음으로써 거래들을 저장하지 않고 있어도 된다고 한다.

Merkle Tree는 이진트리인데 위 왼쪽 그림을 보면 거래들을 해시화 해서 두개씩 묶어 다시 해시로 바꿈으로써 결국 루트 해시가 나올거고 Block Header에 이 Merkle Tree만 가지고 있으면 된다는 말이다. 노드들은 Block의 모든 거래들을 가지고 있을 필요가 없다.

A block header with no transactions would be about 80 bytes. If we suppose blocks are generated every 10 minutes, 80 bytes * 6 * 24 * 365 = 4.2MB per year. With computer systems typically selling with 2GB of RAM as of 2008, and Moore's Law predicting current growth of 1.2GB per year, storage should not be a problem even if the block headers must be kept in memory.

거래들이 없는 Block 헤더는 약 80byte일 것이다. 만약 Block을 10분마다 생성한다고 가정하면, 1년에 80 bytes * 6 * 24 * 365 = 4.2MB 이다. 2008년 보통 2GB 램을 가진 컴퓨터가 팔리고 있고 *무어의 법칙에 따른다면 해마다 1.2GB 씩 성장할거라 예측해보면 메모리에 Block 헤더들을 저장한다 해도 저장공간은 문제가 되지 않을 것이다.

※ 무어의 법칙 : 메모리 용량이나 CPU 속도가 18~24개월마다 2배씩 향상된다는 법칙

그럼 다시 처음으로 돌아가서 전자 화폐를 전자 서명의 체인으로 정의 했는데, 루트만 가지고 지불 검증을 할 수 있느냐에 대한 의문점이 생긴다.

Simplified Payment Verification

It is possible to verify payments without running a full network node. A user only needs to keep a copy of the block headers of the longest proof-of-work chain, which he can get by querying network nodes until he's convinced he has the longest chain, and obtain the Merkle branch linking the transaction to the block it's timestamped in. He can't check the transaction for himself, but by linking it to a place in the chain, he can see that a network node has accepted it, and blocks added after it further confirm the network has accepted it.

전체 네트워크 노드의 실행 없이 지불 검증이 가능하다. 사용자는 오직 가장 긴 작업증명체인 (가장 긴 체인임을 확신할 때까지 네트워크 노드들에게 질의함으로써 얻을 수 있는) 의 Block 헤더의 카피본만 유지할 필요가 있다. 그리고 그 거래가 Timestamp 되어 있는 Block으로 연결된 Merkle Branch를 얻기만 하면 된다. 해당 노드는 스스로 거래를 체크하진 못하지만, 체인의 한 부분을 연결함으로써 네트워크 노드가 거래를 받아들이는지 추가로 확인해주게 된다.

모든 거래 내역을 가진 노드를 Full 노드라 하고 위처럼 Block 헤더만 유지하는 노드들을 SPV (Simplified Payment Verification) 노드라고 한다. SPV 노드는 거래에 대한 검증을 하기 위해 Full 노드로부터 Merkle Branch 를 얻는다. 위 그림의 빨간 부분의 Branch 만 얻어오게 되면 특정 Tx3의 검증이 가능하다.

Tx3를 해시 한 Hash3을 만듦 -> Hash2와 합쳐서 Hash23을 만듦 -> Hash01과 합친 해시 값과 Merkle Root를 비교하면 검증이 완료된다.

As such, the verification is reliable as long as honest nodes control the network, but is more vulnerable if the network is overpowered by an attacker. While network nodes can verify transactions for themselves, the simplified method can be fooled by an attacker's fabricated transactions for as long as the attacker can continue to overpower the network. One strategy to protect against this would be to accept alerts from network nodes when they detect an invalid block, prompting the user's software to download the full block and alerted transactions to confirm the inconsistency. Businesses that receive frequent payments will probably still want to run their own nodes for more independent security and quicker verification.

이 검증 방식은 정직한 노드들이 네트워크를 통제하는 한 신뢰할 수 있지만, 만약 Attacker들이 장악하게 된 네트워크라면 취약해지게 된다. 네트워크 노드들은 스스로 검증할 수 있지만, 이 단순한 방법은 Attacker들의 계속해서 네트워크를 장악하는 한 Attacker들의 날조된 거래들로 속을 수 있다. 이를 막기 위한 한 전략은 네트워크 노드들로부터 유효하지 않은 블럭을 발견했을 때 경고를 받아, 사용자의 소프트웨어가 불일치를 확인하기 위해 전체 블록과 경고를 받은 거래들을 다운받도록 하는 것이다. 빈번한 지불을 받는 사업자들은 독립적인 보안과 빠른 검증을 위해 자체 노드를 운영하려고 할 것이다.

SPV 노드는 악의적인 Attacker들이 많을 경우 Merkle Branch를 받을 때 날조해서 보낼 수 있다는 얘기다. 이를 방지하는 방법은 결국 alert를 받았을 때 전체 거래를 받아서 불일치를 확인하는 방법이라고 얘기한다.. 어쨌든 내 노드의 안전을 위해서는 자체 Full 노드를 운영하는 것이 나을 것이라고 얘기하는 듯 하다.

Combining and Splitting Value

Although it would be possible to handle coins individually, it would be unwieldy to make a separate transaction for every cent in a transfer. To allow value to be split and combined, transactions contain multiple inputs and outputs. Normally there will be either a single input from a larger previous transaction or multiple inputs combining smaller amounts, and at most two outputs: one for the payment, and one returning the change, if any, back to the sender.

비록 코인들을 개별적으로 다룰 수 있지만, 한 송금의 잔돈을 개별적인 거래로 만드는 것은 다루기 불편하다. 금액을 나누고 합치는 것을 허용하기 위해 거래들은 여러개 입력과 출력을 포함한다. 보통 이전 거래로부터 오는 단일 입력이나 작은 금액들로 이루어진 여러 개의 입력, 그리고 최대 두개의 출력이 있다. 하나는 지불을 위한 출력이고, 다른 하나가 있다면 거스름돈이다.

어딘가에서 나온 Output은 다른 거래의 Input이 된다. 내가 받은 코인들을 하나하나씩 거래로 만드는 것은 귀찮으니까 그림과 같이 여러개의 Input으로 모아서 한번에 Output으로 보낼 수 있다는 얘기다. Output이 두개가 있다면 지불에 대한 Output과 보낸 사람에게 거스름돈을 보내기 위한 거래의 Input 값으로 들어갈 거스름돈 Output이 있다.

It should be noted that fan-out, where a transaction depends on several transactions, and those transactions depend on many more, is not a problem here. There is never the need to extract a complete standalone copy of a transaction's history.

한 거래가 여러 거래들을 의존하고 또 이 여러 거래들은 더 많은 거래들에 의존되고 있는 팬아웃은 여기서 문제가 되지 않는다. 한 거래내역의 완전한 독립 사본을 추출해야 할 필요는 절대 없다.

금액이 분할되고 병합되면서 발생하는 거래들의 의존성은 어차피 In - Out에 대한 내역들을 알 필요가 없으므로 중요하지 않다는 뜻이다.

Privacy

The traditional banking model achieves a level of privacy by limiting access to information to the parties involved and the trusted third party. The necessity to announce all transactions publicly precludes this method, but privacy can still be maintained by breaking the flow of information in another place: by keeping public keys anonymous. The public can see that someone is sending an amount to someone else, but without information linking the transaction to anyone. This is similar to the level of information released by stock exchanges, where the time and size of individual trades, the "tape", is made public, but without telling who the parties were.

전통적인 은행 모델은 거래 당사자들과 신뢰할 수 있는 제 3자에게만 접근 권한을 제한함으로써 일정 수준의 Privacy를 제공한다. 모든 거래들을 알려야할 필요성은 이 방식을 불가능하게 하지만, 정보의 흐름을 다른 면에서 차단함으로써 보호가 가능하다. 그것은 공개키를 익명으로 유지하는 것이다. 대중은 누군가가 다른 누군가에게 얼마를 보냈는지 볼 수 있지만 그 거래를 특정인으로 연결할 정보가 없다. 이것은 기존 증권 거래소에서 시간, 거래 내용을 공개하지만 거래자들이 누군지는 말하지 않는 "tape" 수준의 정보공개 레벨과 비슷하다.

As an additional firewall, a new key pair should be used for each transaction to keep them from being linked to a common owner. Some linking is still unavoidable with multi-input transactions, which necessarily reveal that their inputs were owned by the same owner. The risk is that if the owner of a key is revealed, linking could reveal other transactions that belonged to the same owner.

추가적인 보호책으로 신규 키 페어를 사용하여 공통된 소유자를 연결시킬 수 있는 여지를 막아야 한다. 여러개의 입력을 가지는 거래의 경우 해당 입력들이 동일한 소유자의 것임이 드러날 수 밖에 없어서 일부의 연결고리는 피할 수 없다. 만약 한 키의 소유자가 드러나게 된다면 해당 연결고리는 동일한 소유자의 다른 거래들까지 드러나게 된다.

기존 전통적인 모델은 개인정보가 사용된 거래들을 신뢰할 수 있는 제 3자를 통해 Counterparty로 제공됨으로써 대중들에게 개인정보를 차단할 수 있다.

하지만 신규 키 페어의 생성 , 기존 거래의 정의를 보면 공개키, 거래내용, 전자서명만 노출 되는데 공개키는 노출이 되더라도 익명으로 유지함으로써 개인정보를 지킬 수 있다는 것이다. Private Key 는 온라인 상 나의 Identitiy를 나타내는 것이므로 노출되지 않도록 주의해야한다.

Calculations

계산식만 따로 가져와서 해석해보자.

p = probability an honest node finds the next block
q = probability the attacker finds the next block
qz = probability the attacker will ever catch up from z blocks behind

Attacker가 정직한 체인을 언젠가는 따라잡을 확률이다.

p = 정직한 노드들이 다음 Block을 찾을 확률

q = Attacker들이 다음 Block을 찾을 확률

qz = z 개만큼 뒤처진 Attacker가 언젠가 따라잡을 확률

Attacker가 따라잡을 수 있는 확률을 구하기 위해 가능한 진척도에 대한 푸아송 확률에 그 시점부터 따라잡을 수 있는 확률을 곱해준다.

분포 끝부분에 무한급수를 피하기 위해 식을 정리하고 계산해보면..

Attacker가 Block을 생성할 확률이 0.1

뒤처진 Block 개수가 클수록 따라잡을 수 있는 확률이 급격하게 감소한다.

Attacker가 Block을 생성할 확률이 0.3

일때도 마찬가지..

따라잡을 확률이 0.1 % 이하를 유지하려 할 때

Attacker가 Block을 생성할 확률에 따라 따라잡을 Block의 수를 보여준다.

Attacker가 과반수를 넘는다 해도 정직한 노드의 역할을 하는게 경제적으로 이득이라는 것을 잊으면 안된다..

Reference

https://www.bitcoin.com/get-started/bitcoin-white-paper-beginner-guide/

http://wiki.hash.kr/index.php/%EB%B9%84%ED%8A%B8%EA%B3%A8%EB%93%9C

https://en.wikipedia.org/wiki/Merkle_tree

https://en.wikipedia.org/wiki/Moore%27s_law

[블록체인] Bitcoin 백서 정리 #2 - 메커니즘

GOD동하 — Fri, 4 Jun 2021 13:15:33 +0900

https://godd.tistory.com/92

[블록체인] Bitcoin 백서 정리 #1 - 도입부

Bitcoin 백서는 사토시 나가모토라는 가명으로 발표한 신뢰할 수 있는 제 3자 없이 온라인으로 지불이 가능한 P2P 전자 화폐인 Bitcoin을 정리한 논문이다. 요거 한번 정리해보자. 빨간색은 기존 시스

godd.tistory.com

지난 포스팅에는 비트코인에 대한 간략한 소개와 나오게 된 배경에 대한 서론쪽을 정리해보았다.

이어서 비트코인을 사용하기 위한 메커니즘들에 대해서 정리해본다.

Transaction

We define an electronic coin as a chain of digital signatures. Each owner transfers the coin to the next by digitally signing a hash of the previous transaction and the public key of the next owner and adding these to the end of the coin. A payee can verify the signatures to verify the chain of ownership

전자 화폐를 전자서명의 체인으로 정의한다. 각 Owner는 이전 Transaction와 다음 Owner의 Public Key에 대한 Hash에 전자서명을 한 것을 추가하여 코인을 전달한다. 수취인은 소유권의 체인을 검증하기 위해서는 전자서명을 검증할 수 있다.

수취인의 Public Key와 이전 거래의 Hash를 하고 그 값에 발행인의 Private Key로 서명함으로써 체인을 형성한 것을 전자화폐로 정의한다. 즉, 전자상의 거래를 정의하기 위해 필요한 요소는 수취인 정보, 이전 거래 정보, 여기에 발행인의 전자서명으로 이뤄지는 것이다. 여기서 사용되는 공개 키 방식은 타원곡선암호 알고리즘 쓰는데 여기 길이 제한이 있어서 Hash 값으로 사용한다.

The problem of course is the payee can't verify that one of the owners did not double-spend the coin. A common solution is to introduce a trusted central authority, or mint, that checks every transaction for double spending. After each transaction, the coin must be returned to the mint to issue a new coin, and only coins issued directly from the mint are trusted not to be double-spent. The problem with this solution is that the fate of the entire money system depends on the company running the mint, with every transaction having to go through them, just like a bank.

이렇게 정의한 전자 화폐의 문제점은 소유자들중 한명이 이중 지불을 했는지 검증할 수 없는 것이다. 이중 지불을 안했다는 신뢰성이 있어야 하는데 보통은 신뢰 기관인 조폐국 (mint) 이 모든 거래들을 체크하도록 하는 방식을 도입한다. 거래가 완료된 코인은 회수 되었다가 직접 새로 코인을 발행함으로써 이중 지불이 되지 않은 코인임을 신뢰할 수 있다. 하지만 은행처럼 전체 통화 시스템의 운명이 결국 조폐국을 운영하는 회사에 의존적이라는 것이다.

결국, 이중 지불을 검증하기 위한 기존의 전자 화폐 시스템의 큰 문제는 제 3자에 의해 운명이 결정된다는 것이다.

We need a way for the payee to know that the previous owners did not sign any earlier transactions. For our purposes, the earliest transaction is the one that counts, so we don't care about later attempts to double-spend. The only way to confirm the absence of a transaction is to be aware of all transactions. In the mint based model, the mint was aware of all transactions and decided which arrived first.

수취인은 이전 소유자들이 이전 거래에서 서명하지 않았다는 걸 알 수 있는 방법이 필요하다. 여기서는 가장 최초의 거래만이 중요하며, 나중에 이중 지불을 하려는 시도들은 신경쓰지 않는다는 것이다. 거래의 부재를 확인하기 위한 유일한 방법은 모든 거래들을 확인하는 방법이다. 조폐국 기반의 모델에서는 모든 거래들을 확인하여 먼저 도착한 거래인지 결정한다.

To accomplish this without a trusted party, transactions must be publicly announced [1], and we need a system for participants to agree on a single history of the order in which they were received. The payee needs proof that at the time of each transaction, the majority of nodes agreed it was the first received.

제 3자 없이 이중 지불을 확인하려면, 거래들은 공개적으로 알려져야 하며 참가자들이 거래 순서의 단일 기록을 동의할 수 있는 시스템이 필요하다. 수취인은 각각 그 시간의 거래들에 대해 대다수의 노드들이 첫번째 지불이라는 것을 동의하는 증명이 필요하다.

데이터의 무결성, 신뢰성을 입증하기 위해서는 두가지 방법이 있다.

1. 중앙에서 데이터를 접근 못하게 관리하여 신뢰성을 유지하는 방법

2. 전체 공개해서 누구나 볼 수 있게 하여 신뢰성을 유지하는 방법

이 논문에선 2번의 방법을 택하며 결국 P2P 기반으로 모든 거래들을 참여자들에게 공개적으로 알림으로써 이중 지불에 대한 신뢰성을 해결할 수 있다. B-money라는 Wei Dai 가 만든 초기 암호화폐로부터 인용 됐으며 이 Wei Dai 가 사토시 나가모토 라고 추측하기도 한다.

하지만, P2P 기반은 거래가 다른 노드로 Broadcast 되고 동기화 시간 등으로 인해 어떤 거래가 먼저 일어났는지 판단하기 힘들다. 그 시간에 대한 증명을 위해 Timestamp Server가 필요하며 대신 이 때 퍼지는 거래 기록의 순서들이 단일 기록이라는 걸 보장하기 위해 합의 알고리즘이 필요한데 그것이 작업 증명이고 과반수 이상의 노드가 합의하는 Longest Chain만이 단일 기록이라고 볼 수 있다.

Timestamp Server

The solution we propose begins with a timestamp server. A timestamp server works by taking a hash of a block of items to be timestamped and widely publishing the hash, such as in a newspaper or Usenet post [2-5].

위 문제의 솔루션은 Timestamp Server로 시작한다. Timestamp Server는 Timestamp 할 거래들의 블록에 대한 해시를 계산하여 신문이나 Usenet처럼 공표하는 방식이다.

The timestamp proves that the data must have existed at the time, obviously, in order to get into the hash. Each timestamp includes the previous timestamp in its hash, forming a chain, with each additional timestamp reinforcing the ones before it.

Timestamp는 해시로 계산되기 위해 명백하게 그 시점에 데이터가 존재했음을 증명한다. 각 Timestamp는 이전 Timestamp를 포함한 해시들의 체인들을 형성하여 증명을 강화시킬 수 있다.

이중 지불을 막기 위해서는 최초의 거래만 받아들이며 이 거래가 이중 지불이 아님을 증명해야 한다. 따라서, 시간순으로 모든 거래를 확인해야 하는데 이를 위해서 P2P 방식으로 Timestamp를 찍어 거래에 대한 순서를 공표 한다는 것이다. 그림은 이전 Hash와 현재 Block에 대한 Timestamp를 기록하여 이를 다시 Chain 형태로 위조를 할 수 없도록 강화한다는 내용이다.

만약 Timestamp나 Block의 Item을 조작하게 되면 Hash 값이 바뀔 것이고 다시 이 Hash를 바꾸려면 Chain의 모든 값들을 바꿔줘야 하므로 사실상의 조작이 불가능하다.

Proof-Of-Work

To implement a distributed timestamp server on a peer-to-peer basis, we will need to use a proofof-work system similar to Adam Back's Hashcash [6], rather than newspaper or Usenet posts. The proof-of-work involves scanning for a value that when hashed, such as with SHA-256, the hash begins with a number of zero bits. The average work required is exponential in the number of zero bits required and can be verified by executing a single hash.

P2P 기반의 분산 Timestamp Server를 구현하기 위해선 Adam Back의 Hashcash와 비슷한 PoW 시스템을 사용할 필요가 있다. PoW는 SHA-256 같은 방식으로 해시할 때 제로 비트로 시작되는 해시 값을 찾는 작업을 포함한다. 평균적인 작업은 제로 비트의 개수에 따라 지수적으로 증가하지만 한번의 수행으로 검증이 가능하다.

SHA-256 기준으로 256비트의 값이 나오고 16진수로 표현되면 64 Byte로 표시할 수 있다.

dongha는 해시로 "8209EDB0971093DCD5ED976E4B300CFC12E0F5947C34D31B767366CBC79C271D"인데, 제로 비트 해시 값이란 "0000C9BE8DB6E29D340963A0F301E633BE089CF932C2E43936F65B39BA2EAA2C" 과 같이 해시 앞의 값이 제로로 시작되는 값을 말한다.

제로 개수에 따라 난이도가 어려워지는데 그 이유는 아래와 같다.

"0XXX..." -> 맨 앞은 0, 63개는 아무거나 : 전체 (64^16)개 중 (63^16)개 허용

"00XX..." -> 맨 앞의 2개는 0, 62개는 아무거나 : 전체 (64^16)개 중 (62^16) 개 허용

"000X..." -> 맨 앞의 3개는 0, 61개는 아무거나 : 전체 (64^16)개 중 (61^16) 개 허용

...

따라서 지수적으로 증가한다는 뜻은 앞의 제로 개수에 따라서 해시 값을 찾을 수 있는 확률 범위가 적어지므로 찾는데 시간이 더 많이 걸릴것이란 뜻이다.

For our timestamp network, we implement the proof-of-work by incrementing a nonce in the block until a value is found that gives the block's hash the required zero bits. Once the CPU effort has been expended to make it satisfy the proof-of-work, the block cannot be changed without redoing the work. As later blocks are chained after it, the work to change the block would include redoing all the blocks after it.

우리의 Timestamp 네트워크를 위해 우리는 필요한 제로 비트를 포함한 Block의 해시 값을 찾을 때 까지 Block의 nonce를 증가시킴으로써 PoW 를 구현한다. 일단 CPU 연산으로 PoW를 만족시켰다면, Block은 이 작업을 다시 하지 않고는 변경할 수 없다. 그 이후 Block들이 체인으로 연결되기 때문에, 그 Block의 작업 변경은 그 후의 모든 Block들을 다시 해야 할 것이다.

위 그림에서 빨간 표시 된 부분은 Block을 생성할 때 고정 값인 거래 (Tx) 들과 이전 Block의 해시 값이다. 거래들과 이전 해시를 포함하여 해시를 만들면, 항상 같은 값이 나올텐데 여기에 Nonce 값을 증가시켜가면서 제로로 시작하는 해시 값을 찾는 과정인 것이다. 이 과정을 작업증명 (PoW) 라고 하고 이 해시값을 가장 먼저 찾아낸 노드만이 Block을 생성하게 된 것이다.

The proof-of-work also solves the problem of determining representation in majority decision making. If the majority were based on one-IP-address-one-vote, it could be subverted by anyone able to allocate many IPs. Proof-of-work is essentially one-CPU-one-vote. The majority decision is represented by the longest chain, which has the greatest proof-of-work effort invested in it.

작업 증명은 다수결 의사결정에 있어서 투표자 선정 문제도 해결해 준다. 과반수가 한 IP당 한표 방식으로 결정된다면 많은 IP를 할당받는 것이 가능한 사람에게 공격받을 수 있다. 작업증명은 한 CPU당 한 표 방식이다. 다수결의 결정은 가장 긴 체인으로 나타내지며 작업 증명을 위한 가장 많은 노력이 들어간 체인이다.

If a majority of CPU power is controlled by honest nodes, the honest chain will grow the fastest and outpace any competing chains. To modify a past block, an attacker would have to redo the proof-of-work of the block and all blocks after it and then catch up with and surpass the work of the honest nodes. We will show later that the probability of a slower attacker catching up diminishes exponentially as subsequent blocks are added.

만약 과반수의 컴퓨팅 파워가 정직한 노드들로 통제된다면, 정직한 체인이 가장 빠르게 길어져 다른 경쟁 체인들을 앞서게 될 것이다. 지난 Block을 수정하기 위해 Attacker들은 Block의 작업 증명을 다시 해야 할 것이고 또 정직한 노드들의 작업을 추월하고 따라잡아야 한다. 우리는 더 느린 Attacker들이 따라잡을 확률은 Block이 추가됨에 따라 지수적으로 감소함을 보여줄 것이다.

작업 증명은 결국 CPU를 많이 돌리는 노력이 들어가야 하고 이런 정직한 노드들로만 통제될 경우 Block을 수정하려고 해도 가장 긴 체인이 될 확률은 사실상 낮다는 뜻이다. 저자는 과반수 이상을 통제하는 Attacker가 될 경우도 결국 Block을 수정하기 보다는 Incentive를 얻기 위해 노력하는게 경제적으로 이득이라고 말한다.

To compensate for increasing hardware speed and varying interest in running nodes over time, the proof-of-work difficulty is determined by a moving average targeting an average number of blocks per hour. If they're generated too fast, the difficulty increases.

시간이 흘러 하드웨어의 속도 증가나 노드 운영에 대한 관심의 변화를 보정하기 위해서 작업 증명의 난이도는 정해진 시간 당 평균 Block 수를 목표로 하는 이동 평균 (moving average) 에 의해 결정 될 것이다. 너무 빨리 생성된다면 난이도는 증가하게 된다.

현재 비트코인에서는 평균 10분에 하나씩 Block이 생성된다고 알려져 있는데, 예를 들면 작업 난이도나 채굴 속도에 따라 5분만에 목표 해시 값을 찾았을 경우 난이도를 높여서 더 오랜 시간에 걸쳐 작업 증명을 할 수 있도록 조정한다는 뜻이다.

작업 증명은 결국 해시 값을 구하는 과정인데 신규 Block을 기존의 체인에 추가하는 작업을 완료했음을 증명하고 싶은 것으로 불특정 노드들의 작업을 믿지 못하기 때문에 시스템 규칙에 따라 작업을 한 내용을 통해 생성 된 Block만을 체인에 추가하겠다는 의미로 보인다.

또한, 아무나 Block 을 마구 생성해서 Longest Chain을 만드는 것을 막는 용도로도 사용된다.

Network

The steps to run the network are as follows:
1) New transactions are broadcast to all nodes.
2) Each node collects new transactions into a block.
3) Each node works on finding a difficult proof-of-work for its block.
4) When a node finds a proof-of-work, it broadcasts the block to all nodes.
5) Nodes accept the block only if all transactions in it are valid and not already spent.
6) Nodes express their acceptance of the block by working on creating the next block in the chain, using the hash of the accepted block as the previous hash.

네트워크를 실행하는 단계들은 다음과 같다.

1) 새로운 거래들이 모든 노드들로 Broadcast 된다.

2) 각 노드는 새로운 거래들을 Block으로 수집한다.

3) 각 노드는 그 Block에 대한 어려운 PoW를 수행한다.

4) 한 노드가 PoW를 찾아낼 때, 모든 노드들로 Block을 Broadcast 한다.

5) 노드들은 모든 거래들이 유효하고 소비되지 않았다면 그 Block을 승인한다.

6) 노드들은 이전 해시에 해당 Block을 Chain으로 만듦으로써 Block의 승인을 표현한다.

6번 단계는 위 Timestamp Server의 해시 Chain을 뜻하며 사실상의 조작을 불가능하게 해준다. 하지만, 여기서의 문제는 P2P이므로 Block의 도착이 노드마다 다를 수 있어 PoW를 찾아낸 Block Chain이 여러개가 발생할 수 있다는 점이다.

아래 그림으로 어떤 경우인지 확인해보자.

P2P 환경이므로 노드들은 연결된 노드들에만 Broadcast를 할 것이고 순서를 보자.

1. 2번 노드에서 PoW를 찾아 Timestamp를 찍어 Block을 생성한다.

2. Block을 Broadcast. 여기서는 연결된 3번 노드에 Block을 알리고 1번 노드로 Block을 보내줄 것임을 기대한다.

3. 3번 노드에 새로운 Block이 오기 전 99번 노드에서는 다른 시간대의 PoW를 찾아 Block을 생성한다.

4. 생성된 Block을 Broadcast. 여기서는 연결된 1번 노드에 알리고 연결된 다른 노드로 보내줄 것임을 기대한다.

5. 그 사이 3번 노드에 Block이 도착하고 Chain을 함으로써 승인한다.

6. 그 후 3번 노드에서 Block을 1번 노드로 알리기 전 1번 노드는 다른 버전의 Block을 받아 Chain을 형성한다.

이렇게 될 경우 여러 Branch의 Chain이 발생할 수 있어 단일 기록으로 알 수가 없는 것이다.

Nodes always consider the longest chain to be the correct one and will keep working on extending it. If two nodes broadcast different versions of the next block simultaneously, some nodes may receive one or the other first. In that case, they work on the first one they received, but save the other branch in case it becomes longer. The tie will be broken when the next proofof-work is found and one branch becomes longer; the nodes that were working on the other branch will then switch to the longer one.

노드들은 항상 가장 긴 체인을 올바른것으로 간주하고 그 체인을 확장하도록 유지할 것이다. 만약 두 노드가 다른 버전의 다음 Block을 동시에 Broadcast 했다면 어떤 노드들은 서로 다른 블록을 먼저 받게 될 지도 모른다. 이 상황에선, 노드들은 그들이 첫번째로 받은 한 Block만 작업하지만 다른 Branch도 더 길어질 경우를 대비해 저장한다. Chain 길이의 Tie는 다음 PoW 발견 때 깨질 것이다. 그리고 한 Branch가 더 길어질 것이다. 다른 Branch 에서 작업하던 노드들은 더 긴 Branch로 전환 할 것이다.

Chain이 여러개 발생하더라도 결국 가장 긴 체인만을 유지하여 단일 기록으로 유지할 것이므로 여러 Branch에 대한 문제점은 해결될 수 있다는 것이다.

New transaction broadcasts do not necessarily need to reach all nodes. As long as they reach many nodes, they will get into a block before long. Block broadcasts are also tolerant of dropped messages. If a node does not receive a block, it will request it when it receives the next block and realizes it missed one.

새로운 거래는 모든 노드들에게 도달할 필요가 없다. 많은 노드들에게 도착하기만 한다면 그 노드들은 머지 않아 Block을 받아들일 것이다. 노드에서 Block을 받지 못했다 해도 다음 Block을 받았을 때 유실한 Block을 발견해서 바로 다시 요청하게 될 것이다.

다음 포스팅에서는 그 외 P2P 암호화폐를 지속적으로 유통시키기 위한 기타 정책 및 방법에 대해서 알아보겠다.

Reference

https://www.bitcoin.com/get-started/bitcoin-white-paper-beginner-guide/

https://en.wikipedia.org/wiki/Hashcash

http://wiki.hash.kr/index.php/%EB%B9%84%EB%A8%B8%EB%8B%88

[암호학] 공개키 암호 방식과 전자서명

GOD동하 — Mon, 31 May 2021 16:19:51 +0900

공개키란?

공개키 암호 방식은 공개 키 (Public Key)와 비밀 키 (Private Key)가 존재하며, 암호화할 때와 복호화할 때의 키가 달라 비대칭키라고도 한다. 공개 키는 누구나 알 수 있으며 비밀 키는 Owner만이 알아야만 한다.

공개 키 방식은 크게 메세지 암호화와 서명 두가지 종류로 볼 수 있다.

메세지 암호화

메세지 암호를 위해 공개 키 방식을 주로 사용하는데, 주로 공개키로 암호화를 하고 비밀키로 복호화를 한다.

즉, 누구나 확인할 수 없고 비밀키를 가지고 있는 Owner만 메세지를 확인할 수 있다.

이런 특징 때문에 웹서버 통신 시 암호화에 많이 쓰였다.

서버로 메세지 전송 시 공개키로 암호화를 하여 보내면 메세지는 서버에서만 복호화하여 볼 수 있기 때문이다.

아래 그림은 초기 비대칭키 개념을 확립한 모델이라고 볼 수 있다.

메세지를 비트화 한 값에 특정 x 값을 제곱하여 암호화 해서 보내면, 그 역수인 1/x 를 제곱하여 복호화 하는 방식이다.

위 그림을 차례대로 이해해보자. 한 Client가 "A"라는 메세지를 서버로 전송하는 시나리오이다.

특정 키가 13이라고 공개 된 상태에서 아래와 같이 암호화, 복호화 과정이 이뤄진다.

※ 어떤 사이트를 통해 공개할 수도 있고, Client와의 초기 Connection중 받을수도 있고 루트는 다양하다

Encryption

1. "A"라는 메세지를 ASCII 코드인 65로 변경한다.

2. 이 코드 값에 공개키인 13을 제곱하여 서버로 전송한다.

Decryption

3. 전송받은 값을 비밀키인 1/31을 제곱한다.

4. 계산된 값인 ASCII 코드를 다시 메세지로 변경한다.

하지만, 위와 같은 방식은 두가지 단점이 있다.

첫째, 공개 키에서 비밀 키를 유추하기가 쉽다는 것이다.

둘째, 메세지가 길어질수록 제곱을 하기 때문에 통신 비용이 커진다는 것이다.

이 때문에 아래와 같이 mod를 이용한 연산을 통해 개선이 되어서 사용되고 있다.

방식은 동일하고, mod를 위한 값을 함께 공개하고 암호화 시 mod를 해서 보내준다.

암호화 된 값은 어떠한 과정을 통해 역산하여 mod를 할 경우 복호화 될 수 있는 Private Key 를 사용한다.

비밀 키를 쉽게 유추할 수 없고 mod를 함으로써 길이가 짧아지게 되므로 위 단점을 커버할 수 있다.

전자서명

온라인 상에서 계약을 하려면 아래 두가지가 확인 되어야 한다.

첫째, 계약자의 신원을 증명하기 위한 서명 (계약서의 도장)

둘째, 데이터의 위조가 없음을 증명 (계약서 원본)

전자 서명은 위 공개키 방식을 역발상 한 것으로 주로 서명과 검증을 위해 사용되며 아래 그림과 같다.

※ 이전 RSA에서 mod 방식은 계산이 복잡하므로 단순한 방식을 가지고 이해해본다

위 그림대로 어떤 "A"라는 계약이 있고 여기에 계약을 위한 서명을 한다.

이 때 자신만이 가지고 있는 비밀키를 통해서 암호화 한 값을 Digital Signature (전자서명) 라고 하며,

"A"라는 계약서에 서명 데이터를 첨부하여 전송한다.

그리고 추후에 이 계약의 서명 전 데이터와 동일한지 검증하려고 할 때 공개키를 통해 서명을 복호화 한 값과 "A" 계약서가 같은지 확인하면 된다.

Private Key는 도장과 같은 개념으로 항상 자신만 소유해야 하며 모바일이나 개인PC 등 개인적인 공간에서 관리되어야 한다.

[블록체인] Bitcoin 백서 정리 #1 - 도입부

GOD동하 — Sun, 30 May 2021 20:56:29 +0900

Bitcoin 백서는 사토시 나가모토라는 가명으로 발표한 신뢰할 수 있는 제 3자 없이 온라인으로 지불이 가능한 P2P 전자 화폐인 Bitcoin을 정리한 논문이다. 요거 한번 정리해보자.

빨간색은 기존 시스템의 문제점이고 파란색은 이 논문에서 제시하고 있는 솔루션이다.

Abstract

A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution. Digital signatures provide part of the solution, but the main benefits are lost if a trusted third party is still required to prevent double-spending. We propose a solution to the double-spending problem using a peer-to-peer network. The network timestamps transactions by hashing them into an ongoing chain of hash-based proof-of-work, forming a record that cannot be changed without redoing the proof-of-work. The longest chain not only serves as proof of the sequence of events witnessed, but proof that it came from the largest pool of CPU power. As long as a majority of CPU power is controlled by nodes that are not cooperating to attack the network, they'll generate the longest chain and outpace attackers. The network itself requires minimal structure. Messages are broadcast on a best effort basis, and nodes can leave and rejoin the network at will, accepting the longest proof-of-work chain as proof of what happened while they were gone

문제는 P2P 전자화폐는 온라인 Payment를 가능하게 하지만, 이중 지불을 막기 위한 제 3의 신뢰 기관이 필요하며

이 논문에서 제시하는 P2P Network를 통해 이중 지불을 해결하는 Pure P2P 전자화폐 시스템이 가능하다는 내용

Introduction

Commerce on the Internet has come to rely almost exclusively on financial institutions serving as trusted third parties to process electronic payments. While the system works well enough for most transactions, it still suffers from the inherent weaknesses of the trust based model. Completely non-reversible transactions are not really possible, since financial institutions cannot avoid mediating disputes.

전자 상거래의 Payment의 경우 신뢰할 수 있는 제 3자 역할의 금융기관에 의존하고 잘 동작하고 있지만 문제점이 있다.

금융 기관들은 분쟁 조정을 피할수 없으므로 완전히 취소 불가능한 거래는 사실상 불가능하다.

The cost of mediation increases ① transaction costs, limiting the minimum practical transaction size and cutting off the possibility for small casual transactions, and ② there is a broader cost in the loss of ability to make non-reversible payments for nonreversible services. With the possibility of reversal, the need for trust spreads. Merchants must be wary of their customers, hassling them for more information than they would otherwise need.

조정 비용으로 인해 발생할 수 있는 문제

① 거래 비용의 증가, 최소한의 실용적 트랜잭션 크기를 제한하고 최소 일상 거래의 가능성을 차단해야 하기 때문

② 환불과 같은 취소 규정이 없는 서비스를 실제 취소 불가능하게 만들기 위한 비용이 더 많이 듦

즉 ,100원과 같은 소규모 거래들 분쟁까지 조정할 수 없으므로 트랜잭션을 제한함으로써 비용이 증가한다는 말이다. 거래 취소 가능성으로 더 큰 수준의 신뢰수준이 필요하며 판매자는 소비자들에게 주민등록번호와 같은 필요하지 않았을 귀찮은 정보들을 요구할 수 밖에 없다는 것이다.

A certain percentage of fraud is accepted as unavoidable. These costs and payment uncertainties can be avoided in person by using physical currency, but no mechanism exists to make payments over a communications channel without a trusted party.

일정 수준의 사기는 불가피하다. 이런 불확실성은 실제 화폐를 직접 사용함으로써 피할 수 있지만, 제 3의 신뢰기관 없이 이런 communication channel을 통해 Payment를 할 수 있는 메커니즘은 없다.

위 내용을 요약해보면, 실생활의 온라인 거래는 금융기관 같은 제 3의 신뢰기관을 통해 하고 이로 인해 거래 조정을 위한 불필요한 제약과 비용이 들며 사용자들만 불편해 지는 것이다.

위 그림과 같이 기존의 전자 상거래를 보면 A는 B에게 온라인을 통한 송금 거래를 할 때 은행이라는 금융기관을 통해서 요청을 하고 실제로는 A 계좌의 돈을 차감, B 계좌의 돈을 증액 시키는 기록상의 변경이 일어난다. 하지만, 이 온라인 Payment에 대한 프로세스는 제 3의 기관을 통해서만 가능하다는 것이다.

결국, 제 3의 기관 없이 온라인 상의 거래를 신뢰성 있게 하고 싶은게 궁극적인 목표이다. 제 3의 기관에게 전적으로 의존하게 된다면 위와 같은 문제도 있고 Single Point of Failure 문제도 발생하게 되는데 은행과 같은 신뢰기관이 파산되거나 사기를 친다면 누구를 탓할 수 없다.

What is needed is an electronic payment system based on cryptographic proof instead of trust, allowing any two willing parties to transact directly with each other without the need for a trusted third party. Transactions that are computationally impractical to reverse would protect sellers from fraud, and routine *escrow mechanisms could easily be implemented to protect buyers

필요한 것은 신뢰 대신 암호학적 증명 기반의 전자상 거래 시스템이며 이는 제 3자 없이 서로간의 직접 거래를 가능하게 해준다. 이 시스템의 계산적으로 취소가 불가능한 거래는 판매자들을 사기로부터 보호해준다. 구매자를 보호해주는 *escrow 메커니즘은 쉽게 구현될 수 있다.

※ escrow : 흔히 안전거래 시스템과 같이 제 3자가 개입하여 구매자의 지불한 금액을 판매자로부터 거래 물품을 받았음을 확인할 때 넘겨주는 서비스를 말한다.

In this paper, we propose a solution to the double-spending problem using a peer-to-peer distributed timestamp server to generate computational proof of the chronological order of transactions. The system is secure as long as honest nodes collectively control more CPU power than any cooperating group of attacker nodes.

이 논문에서는 거래의 시간적인 순서의 계산적 증명을 생성하기 위한 P2P 분산 Timestamp 서버를 사용해 이중 지불 문제를 해결할 솔루션을 제시한다. 이 시스템은 정직한 노드들의 컴퓨팅 파워 합이 공격자 노드들의 연합보다 크면 안전하다.

서론을 정리하자면, 제 3의 기관 없이 전자 상거래를 위해서는 이중 지불과 같은 문제가 없다는 신뢰성이 필요한데 이 논문에서 제시하는 솔루션으로 해결할 수 있다고 한다.

시간적인 순서의 계산적 증명을 생성하기 위한 P2P 분산 Timestamp 서버에서 사용되는 개념들을 아래에서 소개한다.

Reference

https://www.bitcoin.com/get-started/bitcoin-white-paper-beginner-guide/