esn custom_top_html:no
default debug random = 2 / type = READ / detected = READ / doc_Srl = 11333874
ESN
2019-07-12 12:44:05

51% 공격 경보 시스템 소개

3780 11 14

일전의 Pirl에서 제안한 것으로 알려진 Penalty System을 알려드린바 있습니다.

https://www.ddengle.com/develop/10694967

위 글에서 Pirl의 Penalty System 코드를 분리해서 ESN에 적용하여 테스트한 다음의 코드도 함께 참고하실 수 있습니다.

https://github.com/EthersocialNetwork/go-ethereum/pull/1 (2019년 1월)

 

이 패널티 시스템은 ESN 2분기 로드맵에 명시되어 있는데,

Pirl의 Penalty System을 다시 리뷰하고 이를 ESN에 적용할 것인지 검토하였습니다.

 

사실 Penalty System은 Pirl에서 고안했던 것은 아니고, Zen Cash(지금은 이름을 바꿔서 Horizon)에서 최초 고안했던 것과 같은 것이며,

다음과 같은 여러 이더리움 소스코드 기반의 포크 코인에 적용되어있습니다.

 

- Music 코인

- 칼리스토

- Ether-1 (Ether-1은 재밌게도, 제가 리팩토링 한 Penalty System을 적용하였습니다. https://github.com/Ether1Project/Ether1/pull/2 )

 

패널티 시스템의 단점: 분리된 체인은 누가 도태시키는가?

이 코드를 리뷰했을 당시에 잠재적인 문제가 있음을 발견하였고,

https://www.ddengle.com/develop/10694967 이 글의 댓글에도 "체인분리"에 대한 대책이 있는지 없는지를 @사과야채 님이 질문하고 계시는데, 페널티 시스템의 가장 큰 단점이 바로 체인 분리입니다.

 

체인 분리는 ESN도 경험한 바 있고, 칼리스토 최초 채굴 러시때에도 경험하신 분이 계실것입니다만,

분권화를 중요시하는 블록체인에서는 소규모 체인 분리는 수시로 일어나며, 이러한 국소적 체인분리는 금방 복구됩니다. (이를 체인 reorganization (체인 재편성)줄여서 chain reorg. 라 부름) 즉, 국소적으로 노드간의 연결이 원활하지 않은 경우 A가 캔 블록이 B가 캔 블록에 의해 취소되고 엉클 블록으로 처리되거나 아예 고아(orphan) 블록이 되는 경우가 발생합니다. 이 잠깐동안의 체인 분리는 "가장 빨리 문제를 풀고, 가장 긴 체인을 선택한다"는 블록체인 기본 컨센서스에 의해 금방 복구되어버리고 마는 것입니다.

 

그러나 패널티 시스템의 경우에는 가장 긴 체인이라 할지라도, 패널티값이 너무 높은 체인은 도태시키는 "패널티" 컨센서스가 추가됩니다.

패널티 시스템에서는 51% 공격을 감행하게 되면 공격자는 이중 지불을 발생시키기 위해 약간 늦은 타이밍에 블록을 캐내게 되는데,

적게는 60블럭에서 100블록 이상의 약간 늦은 타이밍에서 캤지만, 가장 긴 체인을 만들어 대규모 체인 재편성(chain reorg)를 일으키는 체인은 패널티 시스템에서는 체인 분리를 일으키는 것입니다.

 

이러한 체인 분리가 된 체인 및 노드는 일반적인 상황이라면 자연적으로 도태가 되기 마련인 것입니다만,

문제는 "게으른 채굴자와 게으른 풀 관리자"가 네트워크 풀상에 항상 상존한다는 것입니다.

패널티 시스템이 제대로 작동하려면, 이러한 체인 분리를 풀 관리자 혹은 채굴자가 지속적으로 모니터링하고 분리된 체인을 도태될 수 있도록 하는 최소한의 관리가 추가적으로 필요한 것입니다.

 

안타깝게도, 불특정 다수의 채굴자는 채굴을 주업으로 하는 것이 아닌 취미로 하고 있으며, 일부 풀 관리자는 상당히 관리를 소홀히 하고 있으며, 패널티 시스템을 개발했던 Pirl 네트워크는 지난 수개월 동안 이러한 체인 분리로 수차례 문제를 겪게됩니다.

 

minerpool.net 의 경우 체인 분리가 발생했는데도 수일동안 이를 방치했고, 이곳에서 캤던 Pirl은 무용지물이 되게 됩니다.

이런 일이 수차례 발생하자 Pirl에서는 minerpool.net을 퇴출시킵니다.

그러나 여전히 이곳에서 Pirl을 캐고 있는 채굴자도 있습니다;; http://pirl.minerpool.net/

42464d9be7527238dcb466136c93487a.png

 

패널티 시스템은 소규모의 잘 관리되는 네트워크에는 유용할 수 있으나, 퍼블릭 블록체인의 특성상 적용하기 힘든이유이며,

여전히 수많은 이더리움 소스코드 기반 네트워크에서 이를 적용하지 않는 이유이기도 한 것입니다.

 

공격감지 시스템

그렇다면 51% 공격 발생이 가능한 ESN 네트워크에서는 패널티시스템 적용을 하지 않으면서 51% 공격을 어떻게 방지할 수 있을까요? 어떻게하면 컨센서스 변경 없이 이중지불을 방지할 수 있을까요? 결국 51% 공격은 이중 지불문제가 거래소에서 발생할 수 있다는 것인데, 이더리움 클래식과 같은 상당히 큰 규모의 네트워크도 51% 공격이 가능한 것이 최근에 알려졌는데 이를 어떻게 하면 방지할 수 있을까요?

 

이더리움 클래식이나 기타 여러 코인들이 패널티 시스템을 적용하지 않았으나, 그들은 블록 confirmation 회수를 적게는 300에서 많게는 500이상까지 늘려서 51% 공격을 하기 어렵도록 조치하고 있습니다.

 

300블록 컨펌이 필요한 거래소에서 이중 지불을 일으키려면 적어도 301 블록 x 15초 = 대략 1시간 30분 정도의 시간동안 51%의 네트워크를 동원해서 캐야 하며, 공격이 실패할 하거나, 공격이 중간에 발각되기라도 1시간 30분동안 캔 블록이 무용지물이 될 수 있다는 점을 감수해야 합니다.

 

이렇게 해시 공격이 일어나게 될 때 네트워크는 몇가지 현상이 일어나게 됩니다.

- 네트워크 해시가 급격히 늘어나 난이도가 올라가게 되면 엉클 확률이 5% 이상으로 확 올라간다.

- 공격자가 주도면밀하지 않은 경우, 예를 들어 20블록 수준의 체인 재편성(chain reorg.)을 공격자가 테스트로 일으키는 경우 => chain reorg. 확률이 올라간다.

 

이러한 미동의 이상한 현상이 감지되기라도 하면 거래소는 컨펌 회수를 300에서 1000으로 확 올려버릴 수도 있습니다. 이 경우 공격자의 실패 확률은 더 올라가게 되고 51% 공격은 무위에 그칠 가능성이 높아지게 됩니다.

 

이더리움 소스코드는 내부적으로 체인 재편성을 감지하는 코드가 있으며, 이러한 공격 감지 시스템을 노드 소스코드 간단히 개선하는 방식으로도 고칠 수 있고 (https://github.com/ethereum/go-ethereum/pull/18950 참고. 본인이 제출하여 approved되었으나 아직 적용 안됨),

노드를 고치지 않고도 공격 감지를 할 수 있게 만드는 것이 얼마든지 가능합니다.

 

이더리움 클래식의 경우에는 classic-geth의 로그 데이터를 분석하는 방식으로 만든 바 있으며 https://github.com/etclabscore/classic-geth-supervisor.sh https://etcstatus.live/ 참조)

 

ESN의 경우에는 이더 클래식에서 제공하는 서비스와 유사하나 더 간단한 모니터링 툴을 제공하고 있고 https://stats.ethersocial.org/ 이를 좀 더 개선하여 엉클 확률과 체인 재편성(chain reorg.)를 디스코드 메신져를 통해 즉각적으로 알려주는 공격감지 시스템 초기 버전을 만들었습니다. (아직 https://stats.ethersocial.org 에 적용하지 않았으나, ESN 공식 디스코드의 #netstat 채널(https://discord.gg/zjFNJMQ )에서 공격 감지 봇이 이를 알려주게끔 하였습니다.

 

6f71a417ded1e498a704226d305b0713.png

 

디스코드 메신져를 통한 공격감지 봇의 알림의 예
205969ad5c992f28779a539f964eb96e.png

- 1개 체인의 체인 재편성은 매우 빈번하며, 이를 알려주고 있습니다. (덜 빈번하게 알려주게 하려면 세팅을 고칠 수 있음)

- 엉클 확률이 올라가면 붉은색으로 경보. 5% 이하로 낮아지면 파란색으로 경보 알림.

 

공격 경보시스템의 장단점

이러한 경보시스템은 다음과 같은 장단점을 가집니다.

- 패널티 시스템처럼 추가적인 컨센서스를 필요로 하지 않으며, 체인 분리도 일어나거나 하는 단점은 없습니다.

- 경보시스템은 chain reorg가 공격에 의한 체인 재편성인지 아니면 정상적인 체인 재편성인지 구별하지 않습니다. 단지 경고만 합니다.

- 공격자가 매우 치밀하지 않은 이상 체인 재편성 초기에 조기 징후가 발생하는 것을 가정합니다.

- 일반적인 상황이라면 긴체인의 chain reorg가 거의 일어나지 않으나, 전체 네트워크의 불안정 혹은 단속등으로 인해 정상적인 체인 재편성도 가능합니다. 경보시스템은 정상적인 체인 재편성과 공격에 의한 체인 재편성을 구별하지는 않습니다.

- 갑자기 난이도가 올라가는 경우 추가적으로 엉클 비율이 높아지게 되는데 이를 함께 경보로 알려줍니다.

- 대규모 체인 재편성이라 할지라도 상당히 짧은 시간 안에 체인 재편성이 발생됩니다. 따라서 경보 알람 => 수동으로 거래소에서 컨펌 회수 조정의 과정이 원활하지 않은 경우 이중지불 발생이 가능합니다.

- 따라서 경보시스템의 소스를 공개하여 거래소 시스템이 이를 활용할 수 있도록 해야 합니다.

3,303

ethminer님의 서명

profile

주업은 오픈소스 프로그래머

 

ESN 디스코드 - https://discord.gg/hqHm69E

ESN 텔레그램 - https://t.me/ethersocialofficial

 

ESN 주소: 0x0c74e46b115e19726997dd559d2b6ff1bfb79af6

ETH 주소: 0x89307cb2fa6b9c571ab0d7408ab191a2fbefae0a

Atachment
첨부 '3'
댓글 14
  • profile
    불바다 2019.07.12 14:02
    블록체인 코드의 핵심으로 점점 접근하고 있네요...
  • profile
    ddengle BOT 2019.07.12 14:02
    @불바다
    불바다님 축하합니다. 3 보너스 캐시에 당첨되셨습니다.!!
  • profile
    외노자 2019.07.12 22:43
    코드쪽은 잘 모르겠지만 이런 기술글 좋습니다 ㅎㅎ
  • profile
    쌩광부 2019.07.12 23:53
    질문입니다.
    글 정독해서 읽었는데요.
    이게 정상적인 chain reorg 인지 악의적인 chain reorg 인지는 어떻게 구분하죠?
    예를들어 노드의 피어가 부족한 상황에서 대량의 해시를 투입해 채굴을 한 상황(지극히 정상적인 방법으로)에서 차후 피어가 충족되면 다른 노드에 자연스럽게 chain reorg 이 발생될 것인데요.
    이때 다른 노드에서 이것을 공격으로 생각하고 블록을 무효화시킬수도 있는것 아닌가요?
  • profile
    ddengle BOT 2019.07.12 23:53
    @쌩광부
    쌩광부님 축하합니다. 16 보너스 캐시에 당첨되셨습니다.!!
  • profile
    ethminer 2019.07.13 10:59
    @쌩광부
    페널티 시스템에서 하는 일이 긴 체인의 chain reorg가 일반적인 상황이 아니므로 방지(혹은 무효화) 하게 되는 것이고요
    (긴 체인의 chain reorg도 정상적인 경우에 가능할 수도 있습니다. 불가항력적 네트워크의 단속등으로 인해 노드간의 연결이 원활하지 않는경우)
    이 글은 이러한 패널티 시스템의 문제점을 지적한 것이고, 그 대안으로 chain reorg가 발생하는 경우 효과적인 대처를 하기 위해 모니터링 시스템을 제안한 것입니다. (본문에 이점이 명확히 짚어지지 않은 것 같네요. 본문을 좀 수정해야 할 듯)
    (공격 경보시스템은 chain reorg + 엉클확률등을 단순히 모니터링만 하기때문에 블록을 임의로 무효화시키거나 하지는 않습니다)
  • profile
    쌩광부 2019.07.13 11:40
    @ethminer
    그렇군요. 글의 의도를 이제 이해했습니다.
  • ?
    잘살자아 2019.07.13 13:44
    감사합니다
  • profile
    coincoin 2019.07.14 11:39
    기존 confirm + 페널티 시스템에 문제가 있어서
    기존 confirm + 페널티 시스템 + 자동 모니터링 시스템
    으로 점점 확장하는 것으로 보입니다.

    모니터링 시스템이 있다면 페널티 시스템이 아예 필요없지 않나요?
    기존 confirm + 자동 모니터링 시스템
    이 더 유연하고 대응이 쉽습니다.

    결국 길게 보면 이걸 사람이 모니터링 하는 것은 한계가 있을 수밖에 없을 것입니다. 24시간 365일 보는게 아니니까요.
    거래소나 기타 페이먼트를 관리하는 업체에서 reorg 가 발생하는 것을 모니토링 시스템으로 자동 캐치해서 일시적으로 confirm 을 높이거나 입금을 중지시키면 되고요.
    minerpool 같은 경우 공격을 한 것도 아닌데 거기 풀과 채굴자가 페널티를 입게 된다면 그야말로 공격자가 원하는 상황이 되는게 아닐까요?
    그 풀에서 지불되는 코인은 지금 막 캔 무효 블럭에서 나온 코인이 아니기 때문에 채굴한 것은 무효고 지불한 것은 유효한 코인이 되는 난처한 상황이 됩니다.

    뭐든지 이렇게 복잡한 상황이 생길 수 있을 때는 심플한게 제일 좋은거 같습니다. 이를 위해 비트코인과 이더리움 등은 confirm 을 높이는 아주 좋은 방식을 이미 갖고 있구요.
    개인적으로 페널티 시스템은 24시간 무중단으로 돌아가는 시스템에서 인간의 개입을 꼭 필요로하게 만들기 때문에 회의적입니다.
  • profile
    ethminer 2019.07.14 13:35
    @coincoin
    이 글에서 주장하는 것은, Pirl등에서 사용하고 있는 패널티시스템을 실제로 적용하기에는 난점이 있다는 점이고요,
    말씀하시는 것처럼 기존의 컨펌을 늘리는 것 + 자동 모니터링 시스템을 이 글에서 주장하는 것입니다.

    자동 모니터링 시스템은 이 글에도 언급하였듯이 이더리움 코어를 살짝 고쳐도 되고 (이더리움 코어 코드는 이미 reorg를 판독하고 있음. 여기에 간단한 모니터링 코드 몇 줄 추가하면 됨) 혹은 이 글에 소개된 것처럼 별도로 디텍트 시스템을 만들어도 됩니다.

    다만, 이 글 마지막 부분에 언급이 되어 있듯이 단순 모니터링 시스템만으로는 51%에 의한 이중지불을 100% 무효화 할 수 있는 것을 보장하지는 않습니다. 정확한 실험을 하지 않아서 수치를 말씀드리기는 어렵습니다만,
    간단한 예를 생각해보자면,

    이더리움 소스 기반 코인의 51% 공격을 막으려면 거래소의 컨펌수는 충분히 길어야 합니다. 예를 들어 300 컨펌을 하고 있는 거래소를 이중지불 공격을 감행하려면 공격자는 301개의 블록이 체인 재편성이 일어나게 만들어야 하는데,
    블록 재편성시, 300개의 블록이 검증되려면 대략 4ms(~8ms) x 300 = 1.2 초 (~2.4초)의 지연이 발생하게 되며, 여기에 노드 sync에 대한 지연이 추가적으로 발생하게 되고, chain reorg 검출은 이보다 좀 더 빠르게 2초 이내에 이루어져야 하며,
    검출 즉시 거래소 컨펌수를 500으로 올려버리면 51%공격을 무효화 시킬 수 있다는 것입니다.
  • profile
    coincoin 2019.07.15 12:01
    @ethminer
    네 아마도 같은 결론으로 도달하는 것 같습니다.
    제 글의 요점은 혹여나 ESN 에 페널티 시스템이 들어갈까봐 페널티 시스템에 대한 관리의 어려움에 대해 알리고 싶었습니다.
    자세한 설명 감사드립니다.
  • profile
    ethminer 2019.07.16 22:30
    @coincoin

    패널티시스템 리뷰를 했고, 패널티 시스템이 적절치 않다는 어느정도의 결론을 내었을 뿐, (즉, 패널티시스템을 위한 하드포크는 바람직하지 않음) 나머지는 특별히 결정된 것이 없습니다.
    (여기서 초기 구현한 공격 모니터링 시스템은 하드포크와도 무관하고, 이미 이더리움 노드 소스코드에서 이루어지고 있다는 것이고요)

  • profile
    coincoin 2019.07.16 23:05
    @ethminer
    넵~
  • ?
    루미팜 17 시간 전
    https://github.com/loki-project/loki-improvement-proposals/blob/master/LIPS/LIP-3.md

ESN

이더소셜 네트워크

List of Articles
번호 분류 제목 추천 수 조회 수 글쓴이 날짜
공지 [소각 공지] 3,000,000 ESN 소각 완료 4 4 1299
ESN운영
2019.06.28
공지 ESN 비트인 가입인증 에어드랍 이벤트 3 13 3235
ESN운영
2019.06.12
공지 ESN ESN 추천글, 채굴풀, 소프트웨어 모음 27 33 56431
ESC메니저
2018.02.02
공지 탑마이닝 쌩광부님 땡글운영위 합류 13 file 25 7211
땡글운영위
2019.07.03
공지 땡글 회원 / ESN 홀더분들을 위한 땡글인의 밤 공지 38 file 6 10633
ESN홍보
2019.06.20
공지 [Air Drop 이벤트] 게시판을 신설합니다 31 updatefile 2 55879
땡글운영위원회
2019.05.17
3729 ESN 헐.. esn 100토시 붕괴 실화인가요..?   mayday mayday mayday!!                       2 newfile 99
메르시
2019.07.21
3728 ESN 뫼비우스 , 머큐리 투자유의 글을 보니.. https://www.upbit.com/service_center/notice?id=923   위 업비트 공지사항을 보니..   투자자들과 의견소통이 1년째 이루어지지 않고, 관련프로젝트 모두 중단...   그런데도 업빗에 상장되어있는거 보면... 어쩌면... 1 new 1 313
불바다
2019.07.21
3727 ESN 땡글 캐쉬가 원래 1원 개념이였었는데요..   땡글캐쉬 1원으로 잡아서.. ESN이 100원일때..    땡글캐쉬 100 캐쉬면   1ESN 정도   맞추도록 교환비가 된것 같은데요..   근데 지금은 땡글캐쉬 100 캐쉬로  1ESN으로 바꾸게 되는데.. 1ESN은 20원 정도 하니까... 3 update 1 1358
불바다
2019.07.19
3726 ESN 끝없는 추락..으음..           항상 원하는 가격에서 5%만 내려도 팔리는거 그걸 못버리고 다 먹으려다가 못팔았는데 이렇게 반토막까지 떨어져버리는군요..   다시 오를날이 있을려나요.. 여유돈 몇백있는걸로 다른코인 추매좀 했더니 ... 3 3 1137
da_mc
2019.07.17
3725 ESN 비트지 거래소도 마진거래 되더군요 저는 안해봐서 모르겠는데요   일단 되긴 되는데 어찌하는지는 모르겠어요..   여하튼 비트맥스만 되는게 아니고, 우리가 많이 가입해있는 비트지도 마진거래가 된다는것..   그냥 써보네요..       3 1 1025
불바다
2019.07.16
3724 ESN ESN 24시간 거래금액           비트인과 비트지   정보가 잘못된건가요?                        4 file 1 1146
루미팜
2019.07.15
3723 ESN ESN과 땡글을 지지합니다.     안녕하세요.  항상 눈팅만 하다가 이번에 땡글인의 밤 행사 참여하고 ESN의 활성화를 위해서 미약하나만 도움이 되고자 ESN의 거래 활성화를 기원하며, 이렇게 소액거래 내역을 인증합니다.   앞으로 ESN을 기대... 6 file 9 5339
kkarm2
2019.07.14
3722 ESN 이번 땡글인의밤 행사   아쉽지만..본가에 간병인이 필요해 원래 가보려고 했으나 가지 못하게되었네요.   저번에 운영위 방문 했을때 많은 분들이 오신다고 전해 들었는데 즐겁게 보내셨으면 젛겠습니다.ㅎㅎ                     2 602
메르시
2019.07.12
ESN 51% 공격 경보 시스템 소개 일전의 Pirl에서 제안한 것으로 알려진 Penalty System을 알려드린바 있습니다. https://www.ddengle.com/develop/10694967 위 글에서 Pirl의 Penalty System 코드를 분리해서 ESN에 적용하여 테스트한 다음의 코드도... 14 updatefile 11 3780
ethminer
2019.07.12
3720 ESN 주말 모임에 가기 전 10만개 채웁니다. ㅎㅎ     ESN 보유분이 좀 적은 감이 있어 이번기회에 10만개를 채워봅니다. 주말에 맛있는 모임을 가진다고해서 신청했는데, 초청받아서 너무 기쁩니다.   좋은 자리에서 좋은 분들 만나서 무식 좀 털어내고 오고 싶습니... 5 2 743
지나니
2019.07.10
3719 ESN 현재 게시판에 글써서 ESN받고, 그걸로 실생활 사용이 가능하네요.     땡글 게시판에 글을 써서 캐쉬얻어가지고 ESN을 받고.. 그걸로 비트코인이나 타 코인으로 거래소에서 매매해서 사용할수도 있고.   ESN을 지불가능한 머니셔틀 카드에 충전해서, 실제 물건을 살수도 있게 되었네... 11 file 13 2793
불바다
2019.07.10
3718 ESN 비트인 거래소 나름 홍보에 노력을 하는것 같긴 하네요 코인판에 광고 올리려면 돈 많이 들텐데   코인판에도 비트인거래소 광고를 올려놨네요   부디 잘되어서  ESN도 활성화 되는데 도움이 되었으면 좋겠습니다.     예전에 바이맥스 거래소는 홍보노력을 전혀 하질 않아... 2 2 527
불바다
2019.07.08
3717 ESN 머니셔틀 아이포인트 중천 가능 시기?   목요일인가부터 안되기 시작했는데, 베타테스트 기간은 이제 종료 되고, 정식 출시 후에 다시 사용해야 하는건가요?     전환 대기중인 0.5 ETC와 소량의 비트지에 있는 esn이 기다리고 잇서용...ㅜㅜ             2 1 342
메르시
2019.07.07
3716 ESN 누군가 비트지 ESN 40만개 한번에 매수     오 요즘 재미있네요...    마치 바둑이나 장기같기도 하고.. 호가창 게임~~     그 결과 24시간 상승률 55.8%   거래량 509311개 기록 달성.   5 file 2 1267
불바다
2019.07.07
3715 ESN 비트지 ESN 고래 매도벽 등장     771K  지금까지 봤던 매도벽중에 가장 강력하군요..     그래도 ESN은 20원 아래로 안떨어지고, 끈질기게 버티고 있네요..           5 file 778
불바다
2019.07.06
3714 ESN 현재 ESN 풀 현황 현재 ESN의 해시 현황은 다음을 통해서 보실 수 있습니다.   https://stats.ethersocial.org/   오늘처럼 특히 마이닝풀허브의 해시가 높은 경우 (70% 가까이 됨)에는 블록이 연속적으로 마이닝풀 허브에 의해 캐지게... 3 file 1 740
ethminer
2019.07.05
3713 ESN 그래요.....제가 3만개 털었어요....... 소고기사먹을려구요....어쩌겠어요....존버가 답은 아닌것같아요.....   다들 장투해서 꼭! 대박나시길 바래요!!!                             10 3 1568
딩딩이안산리더
2019.07.02
3712 ESN 개인적인 생각이지만.. 광고가 많이 필요할거같습니다.           어찌보면 지금 나온 어떤코인보다 실생활에 많이 침두된 상태인데.. 이걸 아무도 모르는거자나요.. 땡글 메인에라도.. " 내가 채굴한 코인으로 햄버거를 사먹는다고? " 이런 배너라도 하나 깜빡거리고 있어... 13 7 2078
da_mc
2019.07.02
3711 ESN 채굴양(발행량) 제한 계획이 있나요?   댓글들을 보니 발행량 제한이 없으면 해당 코인을 추가 매수할 이유가 없다고 전망을 보시는 분들이 많았습니다.    혹시 esn에도 발행량 제한 하드포크 등을 검토할 계획이 있으신지 한번 여쭈어 봅니다.         ... 4 636
메르시
2019.07.01
3710 ESN Ledger Live 에서 Ethersocial 등록 방법 문의 Ledger Live 에서 Accounts 에 + Add account 목록에 Ethersocial 가 없는데 등록 방법 문의 드립니다.                         2 file 418
ctxclub
2019.06.30
Board Pagination Prev 1 2 3 4 5 6 7 8 9 10 ... 187 Next
/ 187