ETH ; 화폐를 넘어서

SungJunEun·2021년 10월 8일
1

Case Studies

목록 보기
2/6
post-thumbnail

본 글은 백서를 기반으로 저만의 방식으로 이해하기 쉽게 정리한 글입니다. 하지만, 해당 내용 전체를 다루지 않을뿐만 아니라 포함되어 있지 않은 내용들도 설명을 위해 포함되어 있으므로 주의를 바랍니다. 저 또한 블록체인을 막 공부하기 시작한 사람으로써 오류와 보완할 점 및 피드백 주시면 큰 도움될 것 같습니다!🐶

해결하고자 하는 문제는

블록체인 프로토콜에서 단지 가상화폐를 주고받는 것 이상의 활동을 할 수 없을까?

방법론

  1. 프로젝트마다 자신만의 새로운 블록체인 프로토콜 만들기

  2. 비트코인의 scripting language 사용하기

  3. 비트코인 프로토콜 위에 meta-protocol 짓기

새로운 블록체인 프로토콜 만들기

이더리움 Whitepaper가 작성된 당시에도 독자적인 블록체인 프로토콜을 사용하는 Namecoin과 같은 프로젝트들은 존재하였다. 하지만, 프로젝트의 규모가 크지 않다면, 각자 자신의 블록체인 프로토콜을 만들고, 테스트를 하는 것이 현실적으로 어렵다. 또한 블록체인 생태계가 발전하기 위해서는 여러 프로젝트들이 서로 상호 작용하여야 하지만, 각자 독자적인 프로토콜을 가진다면 이는 힘들게 된다.

비트코인의 Scripting Language 사용하기

비트코인의 scripting language는 어느정도의 응용이 가능하다. 일반적으로 UTXO가 public key에 의해 제어되지만, scripting language의 작성에 따라 특정 script가 발동될 때 사용이 가능하도록 코드를 작성할 수도 있고, 한명이 아닌 여러명이 sign해야 UTXO가 사용가능하게도 할 수 있다.

하지만, scripting language에는 몇가지 큰 단점이 있다.

1) Not Turing-incompleteness

튜링 완전하지 않다는 말은 결국 scripting language가 모든 computation을 지원하지는 않는다는 것이다. 가장 대표적인 것이 루프인데, 비트코인이 루프를 지원하지 않는 이유는 transaction 검증에 무한 루프를 방지하기 위해서이다. 사실 단순히 코드를 반복하여 루프를 흉내낼 수는 있지만, 이는 공간적으로 비효율적이다.

2) UTXO는 값에 접근할 수 없다

단순히 얘기하여 UTXO는 자신의 잔고 중에서 얼마가 출금될지 정하거나 조절할 수 없다. 이렇게 UTXO가 값에 접근할 수 없다는 사실은 비트코인 프로토콜 위에서 금융 거래를 하는데 제약을 걸게 된다.

3) 상태의 다양성 부재

비트코인에서 UTXO는 사용되거나, 안되거나, 2가지 상태만 존재 가능하다. 이 역시도 복잡한 금융 계약을 만드는데 걸림돌이 된다.

한마디로 scripting language로는 복잡한 조건의 거래나 여러 단계의 smart contract를 작성할 수 없다. 이러한 사실이 비트코인의 모호성을 줄여주는 장점으로써의 역할도 하지만, 비트코인의 확장성의 관점에서는 단점으로 작용한다.

  • smart contract
    이미 작성된 규칙,코드에 따라서 디지털 자산을 자동으로 움직이는 시스템

하지만, 2021년 현재 비트코인에서 레이어 2 솔루션을 통해 확장성을 증가하려는 움직임이 보이고 있다. 고로 비트코인의 Scripting Language 사용하기는 미래에 가능할지도 모른다!
Transcript: This Is the Vision for DeFi Built on Bitcoin
Dfinity to Launch Bitcoin Smart Contracts on the Internet Computer

비트코인 위에 meta-protocol 사용하기

Meta-protocol이란 원래 있던 프로토콜을 기반으로 필요한 부분을 변형한 프로토콜이다. 장점은 기본적으로 현재 이미 존재하는 프로토콜 위에서 새로운 것을 작성하는 것이기 때문에 낮은 개발 비용으로도 가능하다.
하지만, 큰 단점은 SPV를 할 수 없다는 사실이다. 비트코인에서 Light node들이 SPV가 가능한 이유는 이미 많은 블록들이 검증되어서 과거의 블록들은 유효하다는 보장이 되기 때문이다. 하지만, 비트코인 위에서 새로 만들어지는 프로토콜에서는 SPV를 하게되면, 악의적인 노드가 잘못된 transaction을 포함시켜도 알아챌 방법이 없다. 이러한 사실은 프로토콜을 사용하려면 full node여야만 하고, 이는 많은 사람들을 네트워크에 참여시키기 어려울 것이다.

그래서...

이더리움은 아무나 smart contract을 작성하거나 자신만의 토큰을 발행시킬 수 있는 플랫폼의 역할을 하기 위하여 만들어 졌다. 이를 가능하게 하기 위하여 튜링 완전함 및 값에 접근할 수 있고, 여러 상태가 존재하는 scripting language를 적용하였다.


Smart Contract는 어떻게 발동되나?

Smart Contract는 어떻게 발동되나?

UTXO 기반인 비트코인과 달리 이더리움은 각각의 account가 존재하고, account에는 2가지 종류가 있다. 나, Alice, Bob이 소유할 수 있는 일반적인 은행 계좌와 같은 Externally Owned Account와 Smart Contract를 발동시키는 Contract Account이다.

여기서 중요한 사실은 두가지 종류의 account가 동등한 능력치를 가진다는 것이다. Contract Account 역시 일반적인 account처럼 Message를 보내고, 다른 contract를 발동시킬 수 있다.

Account의 4가지 구성요소는 다음과 같다.

  1. Nonce

    Nonce는 transaction을 만들 때마다 1씩 올라간다. Nonce의 역할은 transaction의 시간적 순서를 알 수 있게 하고, 동일한 transaction이 여러번 처리되는 것을 방지한다.

  2. Ether Balance

    Ether가 들어있는 잔고이다.

  3. Contract Code

    Contract code는 말 그대로 contract account에만 있고, contract account가 특정 message를 전달받았을 때 이 contract code가 발동되어서 smart contract를 실행한다.

  4. Storage

    Contract data가 저장되는 곳이다.

작성한 코드가 거쳐가는 과정

우리가 작성하는 코드는 컴퓨터가 바로 이해할 수 없다. 이는 이더리움에서도 마찬가지인데, 보통 우리는 Solidity나 Vypher를 사용하여서 smart contract code를 작성한다. 이런 high-level 언어를 컴파일하게 되면 우리가 이해할 수 있는 코드와 완전 기계어 사이 중간 정도인 이더리움 Bytecode로 변환되고, 이 이더리움 바이트코드를 최종적으로 Ethereum Virtual Machine(EVM)이 실행하게 된다.

Ethereum Virtual Machine (EVM) 개요

  • Ethereum Virtual Machine
    이더리움 블록체인 네트워크의 노드들이 공유하는 가상의 컴퓨터로 smart contract가 EVM에서 실행된다.

EVM은 이더리움의 state를 변화시킨다.

State라는 것

비트코인의 블록체인 프로토콜은 분산화된 장부(ledger)처럼 작동하여 한번 장부에 기록된 transaction에 대해서는 수정이 불가능하여 비트코인의 시스템이 굴러가게 한다. 단순히 BTC을 주고 받기 위해 만들어진 비트코인과 달리 이더리움은 smart contract이 존재한다. 그리하여 이더리움은 분산화된 state machine의 형태를 띈다.

여기서 State란 이더리움 네트워크 상에서 모든 account들의 상태 및 잔고, 실행되고 있는 smart contract들의 상태를 포함한다. 즉, 이더리움 네트워크의 현재 상태이다. 하나의 최종적인 block은 하나의 state만 가질 수 있고, 해당 state는 모든 노드들이 합의되어야만 한다. 다음 block이 등장한다면 또 새로운 state에 도달할 것이다.

모든 행위에는 값이 따른다.

EVM은 공짜로 코드들을 실행하지 않는다. 자신이 transaction을 실행하고 싶다면 해당 transaction의 내용에 따라서 합당한 비용을 지불해야한다. Gas Fee가 필요한 이유는 transaction을 실행시키는데 비용이 0이라면 노드들은 아무 의미없는 smart contract나 무한 루프등을 실행시켜서 이더리움 네트워크에 손해를 입힐 수 있기 때문이다.

Fee = Gas X Fee per Gas

Gas는 EVM이 특정 작업을 실행하는데 필요한 계산의 단위이다. 물리에서 J과 같은 단위랑 흡사하다. 말이 마차를 끄는데 어느정도의 힘이 드는 것처럼 EVM이 특정 transaction을 실행하기 위해서는 어느 정도의 Gas가 필요하다. 예를 들어 ADD(더하기)는 3 gas, MUL(곱하기)는 5 gas가 든다.

Fee per Gas는 1 gas당 지불해야하는 ETH의 값을 말한다. 이 값은 ETH의 값이 변함에 따라 함께 조정된다. 이 두값을 곱하면 최종적으로 원하는 transaction을 실행하기 위한 최종 수수료가 나온다.


Ethereum State Transition Function

Y(S,T) = S'

결국 개별적인 사람들이 EVM을 통하여 다양한 transaction을 실행하면서 그 transaction들이 이더리움의 state를 변경시키는 것을 우리는 다음과 같이 개념적으로 표현할 수 있다.

Y(S,T) = S'

  • Y는 이더리움의 state를 변경시키는 함수로 EVM이다.(사실 EVM이라기보다 EVM을 통해 state가 변경되는 행위를 말하는 것 같은데, 확실하지 않다!)

  • S는 state이고,

  • T는 유효한 transaction의 set이다.

다시 한번 말하자면, 유효한 transaction들이 EVM을 통해서 이더리움의 state를 변경시킨다.

그렇다면 transaction에는 어떠한 것들이 포함되어 있을까?

Transaction의 구성요소

  1. 수령자

  2. 발송자의 signature

  3. 보내는 ether의 값과 데이터

  4. Gas Limit(Start Gas) & Gas Price

    Gas Limit은 발송자가 자신의 transaction이 필요한 최대 Gas의 한계값이다. 발송자는 transaction에 사전에 예상을 통해 Gas의 한계값을 포함시킴으로써 무한 루프와 같은 악의적인 행동이 사전에 방지된다. Gas Price는 앞서 언급한 Fee per Gas이다.

Ethereum State Transition Function의 과정

  1. Transaction이 유효한지 본다. Signature은 유효한지, nonce가 보내는 사람의 account nonce외 일치한지 등을 확인한다.

  2. Transaction fee를 계산해서 발송자의 account에서 transaction fee만큼을 차감한다.

  3. Gas 값을 transaction의 Gas Limit으로 정한 다음, transaction을 실행함에 따라서 Gas를 차감한다.

  4. transaction value를 발송자의 account에서 수령자의 account로 옮긴다. 이 때 수령자의 account가 Contract Account라면 contract의 code를 실행한다.

  5. 4번 도중에 Gas가 다 떨어지면, gas fee를 제외하고 나머지 상태를 원래대로 되돌리고, gas fee는 채굴자의 account로 전송된다.

  6. 정상적으로 4가 마무리된 경우에는 남은 gas를 발송자에게 환불하고, 사용된 gas에 대한 fee는 채굴자의 account로 전송된다.

말, 당근, 달리기

EVM을 말, gas를 당근으로 생각하여서 말이 특정 일을 힐 때 거기에 해당하는 수의 당근을 먹어야한다고 하자.

말에게 대구에서 서울까지 왕복하는 일을 시켰을 때 일을 시키는 사람은 말이 먹을 수 있는 최대의 당근 수(Gas Limit)과 당근 가격(Gas Price)를 먼저 정한다.
말은 1km를 달릴 때 필요한 당근을 일을 함에 따라 차감하고 만약 당근이 부족해지면 모든 변화를 되돌린다. 사용된 총 당근에 대한 fee는 채굴자에게로 간다.


Gas Price의 현재

2021.08.05에 일어난 London Upgrade를 통해 Gas Price에 관한 내용이 변화되었다.

이전 방식에서는 transaction을 보낼 때 발송자가 알아서 Gas Price를 정해야해서 적절한 Gas Price 값이 가늠이 잘 안됐다.
그리하여 이번 London Upgrade에서는 transaction fee의 예측이 더 잘되는 방향으로 Gas Price에 관한 내용이 바뀌었다. London Upgrade를 통해 wallet들은 사용자들에게 자동적으로 적절한 transaction fee를 제시할 수 있게 되었다.

원래는 하나였던 Gas Price가 3가지 값으로 나뉘어졌다.(Gas에 대한 개념 및 내용은 동일하다.)

  1. Base Fee

    Base Fee는 transaction을 block에 포함시킬 때 드는 gas 당 수수료이다.

    Base Fee는 이더리움 네트워크에서 이전 block의 사이즈에 따라서 자동적으로 정해진다. London Upgrade 이전에는 Block의 사이즈가 고정되었지만, London Upgrade 이후에는 가변적인 사이즈를 도입하여서 포함될려는 transaction의 양에 따라서 사이즈가 변한다.

    예를 들어서 이전 block이 block limit size에 도달했으면 Base Fee를 12.5% 상승시키고, block limit size의 50%이면 유지, 50%보다 작으면 12.5% 하락시킨다. 이러한 메커니즘은 transaction fee가 갑자기 급상승하거나 하락하는 것을 방지한다.

    한가지 중요한 사실은 이 Base Fee는 채굴자에게 전달되는 것이 아니고 그냥 네트워크 상에서 삭제된다(burn). Base Fee를 통해서 이더리움은 deflationary asset의 형태를 본격적으로 띄기 시작한다.

  2. Max Priority Fee

    Priority Fee는 채굴자에게 온전히 돌아가는 값으로 채굴자가 자신의 transaction을 block에 포함시키도록 하는 인센티브의 역할을 한다.

    Max Priority Fee는 발송자가 자신이 낼 Priority Fee의 최대 한계값으로 당연히 높은 Priority Fee를 제공할수록 더 빨리 자신의 transaction이 block에 포함될 확률이 올라간다.

  3. Max Fee per Gas

    Max Fee는 최종적으로 발송자가 transaction을 실행하기 위해 낼 수 있는 Fee의 최대 한계값이다. Max Fee는 Base Fee와 Max Priority Fee의 합보다 커야되고, 남는 Gas Fee는 다시 환불된다.


주목할만한 적용 사례

금융 파생 상품과 오라클 문제

금융 파생 상품은 이더리움의 smart contract가 적용될 수 있는 가장 가깝고도 중요도가 큰 섹터이다. 현재 smart contract로 금융 파생 상품을 만들 때 가장 큰 문제점은 어떻게 외부 데이터를 참조하는가이다.

예를들어 ETH를 달러로 헷지하는 상품을 만든다고 했을 때 smart contract는 ETH의 시장가를 알아야 그에 맞는 코드를 실행할 수 있을 것이다. 이렇게 외부 세계의 정보를 블록체인으로 전달하는 것을 오라클이라고 한다. 오라클의 가장 큰 문제는 데이터를 제공하는 제 3자에 대한 신뢰가 필요하다는 것이다.

이 문제를 해결하기 위하여 체인링크는 여러 노드로부터 데이터를 받아서 데이터를 검증하고 안정화한다. 하지만, 여전히 스마트컨트랙트에서는 체인링크를 무조건적으로 신뢰해야되고, 노드가 잘못된 오라클을 제공함으로써 이득을 취하는 문제등 여러 문제가 존재한다. 체인링크외에도 NEST 프로토콜, Umbrella 네트워크등 여러 프로젝트들이 이 오라클 문제를 목표로 하고 있다.

DAO의 가능성

Decentralized Autonomous Organization, DAO는 스마트 컨트랙트로 비즈니스 규칙을 정하고 하나의 중앙화된 주체없이 분산화된 개인들(주주/멤버)의 의견을 종합하여 운영되는 단체이다.

DAO를 통하면 국경과 인맥에 상관없이 가치에 공감하는 개인들이 뜻을 모아 동참하고, 복잡한 의사결정 단계가 필요한 중앙화된 단체보다 훨씬 높은 효율로 성장하는 단체를 만들 수 있다. 또한 코드로 비즈니스 규칙이 정해지기 때문에 다수의 구성원의 동의 없이는 함부로 이 규칙을 변경할 수 없다는 점도 큰 장점이다.


References

White Paper

https://ethereum.org/en/whitepaper/

EVM

https://ethereum.org/en/developers/docs/evm/

https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf

https://blog.qtum.org/the-ethereum-virtual-machine-def21fdc8953

GAS FEE

https://ethereum.org/en/developers/docs/gas/

https://opentutorials.org/course/2869/18360

Turing Completeness

https://hackernoon.com/turing-completeness-and-the-ethereum-blockchain-c5a93b865c1a

State

https://medium.com/hackernoon/getting-deep-into-ethereum-how-data-is-stored-in-ethereum-e3f669d96033

profile
블록체인 개발자(진)

0개의 댓글