아메리카노가 그렇게 맛있답니다 여러분

비트코인 가격이 떨어지고 있는 요즘, 하락에 쐐기를 박은 사건이 있습니다.

 

한국 이름 권도형, 혹은 트위터에서 권 도라고 불리는 분이 만드신 LUNA 코인 때문입니다.

 

블록체인에 관심이 있지만 LUNA를 들어본 적이 없다면, NFT와 관련해서 활발하게 다양한 프로젝트들이 만들어지는 플랫폼으로써 테라(TERRA)라는 이름을 접하셨을 수도 있습니다.

 

사건의 전반을 모두 소개해드리면 좋겠지만, 제가 글을 쓰는 지금이라면 블록체인에 관심이 없는 분들도 뉴스를 통해 많이 접하셨을 테니 어떻게 LUNA가 떨어졌고, $1의 역할을 수행하던 UST 토큰이 어떻게 반토막이 넘게 무너졌는지에 대한 설명은 길게 하지 않겠습니다.

 

LUNA, -99%의 추락 원인

루나의 추락은 UST가 추락했기 때문입니다. 그리고 이 추락의 원인은 UST를 매수한 세력들의 공격이라 봐도 무방합니다.

 

$1를 유지해야 하는 토큰이 하락하는 모습을 보여주어 불신이 생기게 되고, 이로 인한 투매가 나옵니다.

 

물론 루나 대표는 이를 비트코인 매각으로 극복하려 했으나, 비트코인은 블록 컨펌 시간이 1시간입니다.

 

즉, 대응은 무조건 1시간 늦게 나올 수 밖에 없는 약점과 비트코인이라는 하락기에 있는 고위험 자산이 신뢰를 더 떨어뜨립니다.

 

(그리고 $1 회복을 위한 대응 과정에서 줄어드는 대표의 비트코인 수는 이를 가속시킵니다)

 

그렇다면 고점에서 매도한 공격자들은 무슨 수로 이득을 얻었을까요? 술집처럼 미자 밀어넣기로 신고해서 정지라도 시킬 수 있는 경쟁 업체(혹은 경쟁 블록체인)이 공격을 계획했을까요?

 

공격을 수행한 사람은 아니니 정확히 어떤 식으로 수익을 얻었는진 알 수 없으나, 숏 포지션을 통해 이득을 얻었을 것이라 봅니다.

 

그리고 이 공격은 충분한 수치의 자본이라면 무조건 성공할 수 밖에 없는 공격이었기 때문에 감행했을 것이라 봅니다. 사례가 있었거든요.

 

LUNA와 동일한 사례, IRON-TITAN

사실 LUNA와 같은 사례는 이번이 처음이 아닙니다. 11개월 전, 편하게 1년 전에도 이런 사례가 있었고 그렇기 때문에 LUNA 공격자들도 가능성을 보았을 것이라 생각합니다.

 

IRON의 역할을 UST가, LUNA의 역할을 TITAN이 그대로 수행하는 이 프로젝트 역시 알고리즘 방식의 스테이블 토큰(코인)입니다.

 

해당 프로젝트도 다량의 IRON이 매각되는 과정(공격)에서 TITAN이 무제한 발행되었고 당시 최고가 $70 수준이었던 TITAN은 순식간에 소수점 자리로 떨어집니다.

 

LUNA 사태와 차이점이 있다면 IRON은 3:1 비율로 달러가 상당 부분 페깅되어 있었다는 점이고 LUNA는 달러와 페깅이 전혀 없었다는 차이가 있습니다. (페깅;pegging - 1:1 사상됨)

 

1 IRON은 $0.75와 TITAN으로 구성되어 있었습니다. TITAN의 가격에 따라 $0.25에 해당하는 수량의 TITAN이 IRON을 만들기 위해 소모되는 구조입니다.

 

프로젝트의 규모에서 차이가 나기 때문에 정확한 비교는 할 수 없지만, 단순히 안정성만 놓고 본다면 상당 부분 달러와 페깅되어 있는 IRON이 훨씬 안정성이 높아보입니다.

 

그러나 실패했습니다. 완전한 수준으로 달러와 페깅되지 않은 스테이블은 사실 성공한 적이 없습니다.

 

스테이블 코인 종류, 그리고 알고리즘 스테이블만 실패한 이유

스테이블을 만드는 방법은 크게 세 가지가 있습니다.

 

첫번째는 담보물입니다. 단, 담보의 비율이 실제 발행하려는 스테이블 코인보다 큽니다.

 

블록체인을 직접 경험한 분들은 보셨을 수 있는 DAI가 담보물 방식으로 생성된 코인입니다. 2017년도 대하락 시기에도 살아남은 프로젝트이며 약 120%를 담보로 요구합니다. ( 1DAI를 만들기 위해 $1.2 수준의 토큰을 받습니다)

 

담보물은 일정 수준 이하로 떨어지면 매각되기 때문에 안정적으로 $1를 유지하게 됩니다. 물론 유지하지 못하더라도, 2017년도 이후의 코인 가격을 생각해본다면 쌓인 담보의 비율은 엄청날 것이기에 무너지기 쉽지 않습니다.

 

두번째는 1:1 교환입니다. 바이낸스에서 쓰는 USDT, BUSD가 이런 방식이며 최근에는 USDC가 다수의 블록체인에서 주류로 사용되고 있습니다.

 

이들 이름은 발행사가 다르기 때문에 다르지만 실제 달러와 1:1로 교환되었다는 점에서 안전한 스테이블로 취급받습니다.

 

물론 이들이 실제로 안전한지는 알 수 없습니다. USDT를 발행하는 TETHER만 해도 자금 관리에 대한 부분을 비공개로 일관합니다.

(일부 관계자들만 한정하는 식으로 공개를 한다는 이야기가 있습니다)

 

하지만, LUNA 사태 이후로 상당히 많은 스테이블들이 검증 받았고, 이들이 살아남아 있다는 점에서 안전하다고 믿어볼 수 있습니다.

 

마지막으로 알고리즘 스테이블입니다.

 

알고리즘 스테이블은 위에서 소개한 LUNA-UST 방식, 그리고 BOND (또는 Share-Bond)방식이 있습니다.

 

LUNA의 사례는 모두가 알고, 또 왜 망할 수 밖에 없었는지 설명되었으니 본드(BOND)를 아는 것이 좋을 것 같습니다.

 

본드 방식은 발행권(Ticket)과 스테이블코인($table), 그리고 채권(Bond)로 이뤄져 있습니다.

 

본드 방식에서 사람들이 스테이블 코인을 얻을 수 있는 방법은 비싼 발행권을 구매하는 방법 밖에 없습니다. 발행권을 구매한 사람들은 비율에 따라 일정 주기로 스테이블 코인을 나눠받게 됩니다.

 

발행한 스테이블 코인이 $1 아래로 가치가 하락하면, 스테이블 코인은 발행되지 않습니다. 대신 이를 대체할 수 있는 본드를 발행합니다.

 

본드(채권)은 $1보다 싼 토큰이며 미래에 스테이블 코인이 $1로 돌아올 경우 스테이블 코인으로 교환할 수 있는 권리를 갖습니다.

 

본드를 구매한 자금은 모두 $1로 스테이블 코인을 복귀시키는 데 쓰입니다.

 

개발자들의 이상적 시나리오는 하락하면 하락 원인인 발행을 중단하고 본드를 통해 가격 회복 효과를 얻고 일정 시간 후에 본드를 스테이블 코인으로 교환할 수 있도록 하여 시스템을 운영하는 것입니다.

 

하지만 위 시나리오 역시 LUNA처럼 근거없는 믿음과 신앙이 필요합니다. 만약 이것들이 없다면 아래의 패턴에 빠지게 됩니다.

 

1. $1 아래로 떨어졌다! 모두 팔고 도망쳐!

2. $1 올 것 같지도 않고, 발행권이 들고 있어봤자 소득이 없으니 매각해야겠다.

3. 참여자들의 수가 줄고 있네? 본드(채권) 사면 물릴 것 같은데 빼야겠다.

 

위의 삼 박자가 필수는 아닙니다. 이들 중에서 1과 2, 2와 3, 또는 1과 3만 발생해도 서서히 붕괴하는 시스템입니다.

 

LUNA 예견되었나

결론적으로 예견은 되었다고 생각됩니다.

 

다만, 공격자들도 루나의 규모를 생각해본다면 쉽지 않았을 수 있었는데 공격을 쉽게 만든 것이 대표의 포지션 노출이라는 지적이 많습니다.

 

스테이블이라면 안전하게 유지할 수 있는 것이 필수인데 비트코인 같은 변동성이 크고 즉각적인 대응을 할 수 없는 자산에 상당수를 투자했다는 사실은 하락 시기와 맞물려 큰 약점으로 드러났습니다.

 

그리고 이와 같은 논리에 입각하여 무엇으로 스테이블을 발행하며 회사를 유지할 수 있는지 공개하지 않은 여러 스테이블 코인이 검증당한 것이라 생각합니다.

 

루나에 투자한 스트리머가 대표의 주택에 침입하는 등 많은 일이 일어났고 많은 고래들부터 개미까지 큰 손실을 얻었습니다.

 

자산 배분을 안전하게 합시다.

문자열을 dict 타입으로 만들기


import ast   def parse_json(input_string: str) -> dict:   json_dict: dict = ast.literal_eval(input_string)   return json_dict



dict 타입을 문자열로 만들기


import json
 
def stringify_json(input_dict: dict) -> str:
 
    string_json = json.dumps(input_dict)
 
    return string_json






빨간 네모 박스 위치에 대략


Project Interpreter Error: Please Specify a different SDK Name


같은 오류가 뜬다. 


이는 같은 인터프리터 이름이 있는 경우에 발생하며 동일한, 중복된 이름의 인터프리터(venv이름)를 설정에서 제거하면 된다.



프로젝트가 많아지다보면 우연치 않게 중복이 되는 경우가 생기는 듯 하다.


하나도 똑같은 이름이 없게 만들고서야 인터프리터를 설정할 수 있었다.


'프레임워크 > Django2(장고)' 카테고리의 다른 글

Django + MySQL 연동  (0) 2018.09.27