웹소켓 속도 제한 문제 발생, 2019년 6월 25일

6월 25일 21:09:00 UTC (한국시간 기준 6월 26일 오전 6시 9분), 저희 비트멕스는 API 레이어에 대한 업데이트를 발표했습니다. 본 업데이트는 의도치 않게 특정 테이블에 대한 웹소켓 구독 수를 이와 달리 제외되었던 요청 속도 제한과 비교하여 산출하였습니다. 이번 업데이트로 인해 웹소켓 API를 많이 활용하는 고객들이 영향을 받았을 수 있습니다. 저희는 6월 26일 00:19 UTC (한국시간 기준 6월 26일 오전 9시 19분)에 해당 문제를 확인 후, 즉시 업데이트를 롤백하여 시스템을 정상화하였습니다.

이번 문제로 불편을 끼쳐드려 죄송합니다. 요청 속도 제한기에서 제외되는 구독에 대한 자세한 내용은 이전 블로그 게시물을 참고해 주시기 바랍니다.

ETHUSD 주문장 피드 문제 발생, 2019년 6월 24일

2019년 6월 24일 09:25:54 UTC와 09:44:30 UTC 사이에 orderBookL2, orderBookL2_25, orderBook10 및 ETHUSD에 대한 실시간 웹소켓 피드는 성능이 저하된 상태였습니다. 이 기간 동안 해당 피드들에 대한 ETHUSD 주문장의 상태에는 오류가 있었습니다.

저희는 1분 이내에 문제의 근본 원인을 파악하고 이를 해결할 수 있었습니다. 이 문제는 문제 발생 몇 시간 전 프로덕션 환경에 배포된 orderBookL2 계산 최적화의 버그를 유발하는 드문 일련의 주문 이벤트 (order events)로 인해 발생했습니다. 이후 이 변동 사항은 취소되었습니다.

이 문제가 거래 엔진 자체의 주문에 미친 영향은 없었습니다 – 거래 엔진의 ETHUSD 다운스트림에 대한 계산된 주문장만이 표시되었을 뿐입니다.

저희는 향후의 잠재적이고 유사한 문제점을 감지하고 미리 알림 받기 위해 추가적으로 자동 피드 검사기를 배포했습니다.

이번 문제로 불편을 끼쳐드려 죄송합니다. 문의 사항이 있으시면 다음의 양식에 따라 문의해주시기 바랍니다: https://www.bitmex.com/app/support/contact.

중요 보안 권고사항 업데이트에 관한 공지, 2019년 6월

요약: 저희는 고객 계정에 대한 무단 접속 시도가 증가했음을 확인했습니다. 모든 고객과 사용자 분들은 다음과 같은 방법으로 비트멕스 및 개인 계정을 보호해주시기 바랍니다: 강력하고 복잡한 비밀번호 사용; 모든 계정에 대한 이중 인증 장치 (2FA) 활성화; 비밀번호 관리자 서비스 사용.

보안은 비트멕스에서 항상 최우선순위로 유지되어왔습니다. 이것은 비트멕스가 고객 자금 보호를 위해 수동 다중 서명 콜드 월렛 설정을 채택한 첫 번째 플랫폼이었던 이유이기도 합니다. 저희는 보안 프로토콜을 지속적으로 검토하고 자체 보안 기준을 강화하고 있습니다. 또한 플랫폼 보안과 고객 보안을 지속적으로 개선하기 위해 최선을 다하고 있습니다.

대규모 봇넷 자격증명 재사용 공격이 휩쓸고 지나간 2016년, 저희는 비트멕스에서의 복잡한 비밀번호 사용의 중요성을 강조한 블로그 글을 게시했습니다. 또한, 저희는 2FA 활성화를 권고했습니다. ‘2단계 인증’ 혹은 ‘다중 인증’으로도 불리는 2FA는 로그인 시 사용자명과 비밀번호뿐만 아니라 시간 제한이 있는 고유한 토큰을 입력하게 함으로써 계정에 보안 레이어를 추가합니다. 토큰은 Google Authenticator 또는 Authy와 같은 소프트웨어 기반의 인증 어플리케이션에서 휴대폰에 저장할 수 있습니다.

다음 메시지는 지금과 마찬가지로 시기 적절한 것이었습니다: 계정의 보호를 위해서는 다중 인증 솔루션 및 비밀번호 관리자 서비스와 더불어 항상 강력하고 복잡한 비밀번호를 사용해야 합니다.

최근 저희는 고객 계정에 대한 무단 접속 또는 손상 시도 횟수가 증가한 것을 확인했습니다. 계정에 대한 2FA 활성화는 이러한 공격으로부터 스스로를 보호하는 가장 쉽고 검증된 방법입니다.

또한 금전적 동기를 가진 범죄자가 사용하는 전략과 그 치밀함이 계속해서 증가했음을 알게 되었습니다. 한 가지 예를 들면: 공격자가 즉시 출금 요청을 하는 대신, 그들이 관리하는 다른 계정에 의도적으로 손실을 입혀 자금을 거래하는 수법을 목격했습니다. 저희는 사전에 이 같은 공격 수법을 식별하고, 적발 시 해당 거래 활동을 중지시키고 있습니다.

공격자들의 계정 도용에서 관찰되는 또 다른 반복적인 수법은 무단 계정 접속으로 비트멕스 로그인 알림 이메일 수신을 비활성화하는 것입니다. 공격자는 출금 권한이 있는 API 키를 생성하기 위해 피해 고객 계정에서 2FA 활성화를 시도할 수도 있습니다. 거의 모든 경우에 해당하는 공통적인 의견은 고객이 출금 알림 또는 기타 계정 관련 이메일 알림을 확인하지 못했을 수 있다는 것입니다; 예를 들면, 로그인 알림이 이에 해당합니다.

2FA 및 기타 로그인 액세스 기능과 같은 사례를 검토하면서 저희는 다음의 변경 사항을 적용하게 되었습니다:

  1. 비트멕스 사용자는 더 이상 로그인 알림 기능을 비활성화 할 수 없습니다. 이제부터 기존의 알림 수신 설정 여부와 관계없이 로그인 알림 메일이 발송됩니다.
  2. API를 통한 출금 요청은 사용된 API 키가 2019년 6월 10일 오후 8시 (UTC 기준) 이전에 생성되지 않은 경우, 출금 확인을 위한 이메일 승인 단계를 항상 완료해야 합니다.

위 같은 변경 사항은 고객의 계정 보안 강화를 위한 것이지만, 이것이 완벽한 해결책이 아니라는 점을 유념해주시기 바랍니다. 저희는 2FA 활성화를 가장 강력히 권고해드립니다.

상술한 내용 외에도 저희 비트멕스는 고객의 모든 계정 도용 사례를 검토했으며, 피해 계정 사이의 몇 가지 공통점을 발견했습니다:

  1. 동일 비밀번호 재사용 또는 비트멕스 플랫폼 및 고객 개인 이메일 계정에서 쉽게 유추할 수 있는 비밀번호 사용.
  2. 비밀번호 복구를 통해 계정 도용으로 이어지는 손상된 개인 이메일 계정의 사용.
  3. 사용자 컴퓨터의 악성 소프트웨어를 통해 비밀번호를 도용한 후 bitmex.com 플랫폼에 로그인.

이러한 공격을 방지하기 위해서는 보안에 대해 철저하고 엄격한 접근방식을 취하는 것이 중요합니다. 상기의 모든 시나리오 하에서 2FA를 사용하면 계정 손상의 위험이 크게 감소합니다. 2FA가 보안 키에 적용된 경우, 공격을 100% 차단할 수 있다는 구글의 최근 연구는 이 사실을 더욱 명확히 보여줍니다.

저희는 비트멕스 사용자의 2FA 활성화 의무 방안을 고려하면서 아래에 설명된 대로 좋은 보안 방법을 채택하는 것의 중요성을 다시 한 번 강조할 것입니다.

다음의 조치는 비트멕스 계정뿐만 아니라 기밀 정보를 저장하는 개인 계정에도 적용되어야 합니다:

  1. 2FA 활성화하기
      1. Google Authenticator 또는 Authy와 같은 다양한 옵션 중 하나를 사용하는 것이 좋습니다.
  2. 강력하고 복잡한 비밀번호를 사용하고 LastPass와 같은 비밀번호 관리자 서비스 사용하기
      1. 강력한 비밀번호는 글자, 숫자 그리고 특수문자 (@, #, $, %, 등)가 조합된 10자 이상으로 구성되어 있습니다 (비밀번호가 길수록 더 강력해집니다). 비밀번호는 대∙소문자를 구분하므로 강력한 비밀번호에는 대문자와 소문자 모두가 포함되어야 합니다.
      2. Facebook, Spotify 또는 Instagram 계정과 같은 SNS 계정과 동일한 비밀번호를 비트멕스 거래 계정 혹은 은행 계좌에 사용하지 마십시오. 각 계정마다 강력하고 복잡하며 서로 다른 비밀번호를 사용하십시오!
  3. 현재 위험도 평가하기
      1. HIBP와 같은 서비스를 통해 비밀번호가 제3자에게 유출되었는지 확인하십시오.
      2. 거래 계정을 정기적으로 확인하여 계정 잔고를 확실히 파악하십시오.
      3. 보유 계정의 정기적인 조정은 계좌 내의 모든 거래가 여러분의 승인 하에 이루어지도록 하는 유용한 방법입니다.
  4. support@bitmex.com을 연락처 목록에 추가하고 비트멕스 발송 이메일이 스팸 메일로 분류되지 않도록 하기
      1. bitmex.com에서 발송하는 공식 커뮤니케이션 이메일을 스팸 처리하거나 수신 거부 설정하지 마십시오. 공식 커뮤니케이션 이메일에는 로그인 및 출금 알림 메일이 포함됩니다.
  5. 비트멕스 고객지원팀은 절대로 여러분의 계정 비밀번호를 묻지 않습니다

비트멕스는 보안을 매우 중요하게 생각하여 내부적으로 동시에 외부적으로 보안 기능을 계속해서 개선하고 있지만, 궁극적으로 보안은 모든 이들의 책임입니다. 여러분께서 온라인 계정에 디지털 자산을 보관하고 있다면, 위와 같이 계정의 안전/보안을 보장하기 위한 조치를 취하는 것은 매우 중요합니다.

만일 여러분의 계정에서 비정상적인 거래 활동이 포착될 경우, 문의하기 페이지를 통해 비트멕스 고객지원팀으로 즉시 문의해주시기 바랍니다.

2019년 3분기 분기별 선물 계약 상품 목록

2019년 6월 14일 8:30 UTC (한국시간 기준 2019년 6월 14일 오후 5시 30분), 비트멕스에서 새로운 분기별 선물 계약 상품이 출시될 예정입니다.

아래의 표를 통해 기존 및 출시 예정인 2019년 3분기 선물 계약 상품의 상장일과 결산일을 확인하십시오. 굵은 글씨로 표시된 상품은 신규 계약 상품입니다.

상품코드 페어 상장일 결산일
ADAM19 Cardano / Bitcoin 2019년 3월 15일 2019년 6월 28일
ADAU19 Cardano / Bitcoin 2019년 6월 14일 2019년 9월 27일
BCHM19 Bitcoin Cash / Bitcoin 2019년 3월 15일 2019년 6월 28일
BCHU19 Bitcoin Cash / Bitcoin 2019년 6월 14일 2019년 9월 27일
EOSM19 EOS Token / Bitcoin 2019년 3월 15일 2019년 6월 28일
EOSU19 EOS Token / Bitcoin 2019년 6월 14일 2019년 9월 27일
ETHM19 Ether / Bitcoin 2019년 3월 15일 2019년 6월 28일
ETHU19 Ether / Bitcoin 2019년 6월 14일 2019년 9월 27일
LTCM19 Litecoin / Bitcoin 2019년 3월 15일 2019년 6월 28일
LTCU19 Litecoin / Bitcoin 2019년 6월 14일 2019년 9월 27일
TRXM19 Tron / Bitcoin 2019년 3월 15일 2019년 6월 28일
TRXU19 Tron / Bitcoin 2019년 6월 14일 2019년 9월 27일
XRPM19 Ripple Token (XRP) / Bitcoin 2019년 3월 15일 2019년 6월 28일
XRPU19 Ripple Token (XRP) / Bitcoin 2019년 6월 14일 2019년 9월 27일
XBTM19 Bitcoin / USD 2018년 12월 17일 2019년 6월 28일
XBTU19 Bitcoin / USD 2019년 3월 15일 2019년 9월 27일
XBTZ19 Bitcoin / USD 2019년 6월 14일 2019년 12월 27일

예정된 시스템 업데이트 완료, 2019년 6월 4일

예정된 시스템 업데이트가 성공적으로 완료되었습니다. 비트멕스 플랫폼은 현재 완전히 정상적으로 작동 중입니다. 시스템 업데이트는 2019년 6월 4일 01:00 UTC에서 02:58 UTC까지 (한국시간: 오전 10시에서 오전 11시 58분 까지) 시행되었으며, 거래 활동에는 아무런 지장이 없었습니다.

2019년 6월 4일에 시행 예정인 시스템 업데이트

저희 비트멕스는 2019년 6월 4일 01:00 UTC (한국시간 기준 2019년 6월 4일 오전 10시)부터 데이터베이스 서비스에 대한 예정된 시스템 업데이트가 수행될 예정이며 본 업데이트는 3 ~ 5시간 동안 지속될 것으로 예상됩니다. 거래, 로그인 및 기타 주요 API 기능은 계속 작동될 예정이며 다음 기능은 해당 업데이트 기간 동안에 비활성화된다는 점 유의해 주시기 바랍니다:

  • 신규 계정 가입
  • 이메일 인증
  • 이중인증 활성화
  • 이중인증 비활성화
  • 비밀번호 재설정
  • 출금
  • 기본 설정 업데이트
  • 트롤박스 상에서 사용자 음소거 처리
  • API 키 생성
  • API 키 비활성화
  • API 키 활성화
  • API 키 삭제

해당 시스템 업데이트 완료 후 추가 공지를 게시할 예정입니다.

본 업데이트 시행으로 인해 서비스 이용에 불편을 끼쳐드려 모든 사용자 분들께 사과의 말씀을 전하는 바입니다. 해당 업데이트와 관련하여 궁금한 점이 있으시면 다음 연락처 양식을 통해 고객 지원팀에 문의해 주시기 바랍니다: https://www.bitmex.com/app/support/contact.

2019년 5월 30일에 발생한 웹소켓 지연 현상

2019년 5월 30일 16:00 UTC 부터 17:00 (한국시간 기준 5월 31일 오전 1시 ~ 오전 2시) 사이에 웹소켓 API는 큰 규모의 시장 움직임이 발생하는 도중에 거래 엔진에서 발생한 트래픽 급증으로 인해 상당한 지연 기간을 겪었습니다. 해당 기간 동안에 일부 웹소켓 연결은 내부 전달 계층의 메모리 제한에 따라 시장 데이터 업데이트가 중단되어 재차 연결이 시도되었습니다.

저희 비트멕스 엔지니어들은 이미 계획한 시장 데이터 배포 구조의 전략적 업그레이드를 통해 거래 처리 용량을 대폭 늘릴 뿐만 아니라, 웹소켓 정보 제공에 있어 대기 시간 또한 줄일 수 있도록 개발 작업을 가속화하고 있습니다. 본 거래 처리 용량 업데이트는 이번 주 내로 테스트넷에서 시행될 예정이며 향후 비트멕스의 실거래 플랫폼에 시행된 후에도 사용자 분들께 안내 드릴 예정입니다.

궁금한 점이 있으시면 다음 연락처 양식을 통해 고객지원팀에 문의해 주시기 바랍니다: https://www.bitmex.com/app/support/contact.

암호화폐 연구 지원의 일환으로 매사추세츠 공과 대학의 선두적 전자화폐 계획 (MIT DCI)에 기부한 HDR Global Trading Limited

이번에 저희는 비트멕스의 소유주인 HDR Global Trading이 세계적인 암호화폐 생태계의 발전과 개선에 대한 연구를 수행하는 메사추세츠 공과 대학의 선두적 전자화폐 계획에 지원하게 되어 기쁘게 생각합니다.

HDR Global Trading의 최고 기술 책임자이자 비트멕스 거래 플랫폼의 공동 창립자인 Sam Reed가 다음과 같이 후원 계획을 발표했습니다:

저희 비트멕스는 항상 암호화폐의 잠재력으로 인해 활력을 받아왔습니다. 연구 개발에 대한 저희의 기부는 네트워크가 더 견고하게 유지되는 것에 초점에 두고 있습니다. 더 강력한 비트코인 네트워크는 모두에게 유익할 것이며 저희는 이에 대한 지원을 할 수 있게 되어 매우 기쁘게 생각합니다.

HDR Global Trading은 거래량 기준으로 세계 최대 규모의 암호화폐 거래 플랫폼인 비트멕스를 소유 및 운영 중에 있습니다. HDR Global Trading은 비트코인을 더 강력하게 만들어 비트코인의 견고성, 확장성 및 개인정보 보호를 개선시켜줄 연구와 공학을 지원하게 되어 자랑스럽게 생각합니다.

특히 HDR은 비트코인 코어 개발자인 Wladimir van der Laan과 Cory Fields의 작업을 지원하는 데에 힘을 쏟고 있습니다. 이들의 역할은 비트코인 프로토콜의 각기 다른 부분에서 중요한 의미를 가집니다.

본 기부는 무조건, 무제한적으로 제공될 예정입니다.

볼록성: 청산을 방지하는 방법

2014년 11월 24일 비트멕스가 출시된 이래 암호화폐 파생상품 거래가 기하급수적으로 증가했습니다. 저희는 파생상품 거래에 관한 미래 비전을 가지고 다양한 벤처 캐피탈 회사들을 접촉했지만 허사였습니다. 그 당시에는 지원이 준비되어 있지 않았습니다; 그러나 저희는 2019년에 겪은 실패에 대해 더할 나위 없이 기쁩니다.
 
비트멕스의 비트코인 무기한 스왑 계약과 OKEx 및 Deribit에서 거래되는 다양한 기타 계약들은 동일한 유형입니다. 이러한 계약들을 통해 일정 미화 금액의 비트코인을 거래할 수 있습니다. 저희는 이를 역 파생상품 계약으로 부르고 있습니다. 많은 본래의 암호화폐 거래자들은 제가 본 계약 구조의 미묘하면서도 심오한 의미에 대해 이야기하는 것을 본 적이 있습니다. 그러나 많은 신규 거래자들이 이제 파생상품 거래를 시도하기 때문에 이와 관련한 재교육 과정이 필요합니다.
 
일반적인 통념과는 달리 저희는 비트멕스 Rekt 트위터 피드 (블로그의 글을 트위터로 자동 전송해주는 기능)가 큰 소란을 일으킬 때 반갑지 않습니다. 저희는 장기적인 입장으로 욕심을 부리고자 합니다. 저희는 차라리 장기간의 거래 경험을 통해 수익을 얻으면서 비트멕스의 거래 수수료를 지불하는 편이 청산 절차가 진행되는 중에 자기 자본을 잃는 것보다 낫다고 믿습니다. 따라서 당사의 거래자들이 모범 거래 관행에 관한 충분한 교육을 받을 수 있도록 하는 것이 저희의 가장 큰 관심사입니다.
 
저희는 모든 거래자들을 소중하게 여기고 있지만, 사람들이 청산이 이루어지는 것에 대해 웃음거리로 만든다고 할 때 당혹스럽기 그지 없습니다. 진정한 거래자는 적절한 위험 관리를 실천하며 이는 결코 청산되지 않는다는 것을 의미합니다.
 
위로 더 도약하기 위해서는 아래로 내려갈 줄도 알아야 합니다
 
볼록성 혹은 감마는 가격과 관련하여 계약 가치의 두 번째 파생상품입니다. 이는 올바르게 사용되면 포트폴리오의 수익을 극대화할 수 있습니다. 그러나 만일 거래하고 있는 파생상품에 볼록성이 어떻게 영향을 미치는지 이해하지 못하는 경우, 반복적으로 청산을 당할 수 있습니다.


역형 계약의 경우 마진 통화는 자국 통화와 동일합니다. 저희는 본 기사 전체에 XBTUSD 상품을 표시할 예정입니다.
 
자국 통화: XBT (비트코인)
외국 통화: USD (미화 달러)
마진 통화: XBT
미화 달러 가치: 1 미화 달러
XBT 가치: 1 USD / 가격 (비트코인/미화 환율 혹은 .BXBT 지수)
 
저희는 가격 (.BXBT 지수)과 관련하여 10만개 수량의 공매수 포지션이 어떻게 변화하는지 살펴 볼 예정입니다.

먼저 공매수 포지션 측을 살펴보도록 하겠습니다. 상승장과 하락장에서 이들은 대부분 투기자가 될 가능성이 높습니다. 이는 공매수 포지션의 비트코인이 비대칭적인 수익을 제공하기 때문에 이치에 맞습니다. 비트코인은 무한대로 상승할 수 있지만 0으로 하락할 수 밖에 없습니다. 자기 자본의 수익률 관점에서 볼 때, 시장의 밑바닥에서 공매수 포지션을 취한 후 시장의 꼭대기에서 공매도 포지션을 취하는 편이 낫습니다. 이더리움을 100달러 이하에서 매수한 거래자들은 이에 대해 절실히 인지하고 있습니다. 따라서 레버리지를 사용하여 증거금으로 공매수 포지션 취한 거래자들은 대부분의 시장 환경에서 주로 투기자로 남을 것입니다.

첫 번째 도표는 비트코인 수익 및 손실에 대한 개요와 곡률을 보여줍니다. 직선은 계약이 선형으로 이동된 경우에 따른 수익률이며 곡선은 공매수 역방향 계약 포지션의 수익률입니다. 이로 인해 여러분은 시장이 하락할 때 더 많은 돈을 잃고 시장이 상승함에 따라 더 적은 돈을 벌게 된다는 사실을 즉시 알 수 있습니다. 이는 비트코인에 마진을 게시해야 되므로 차선책에 불과합니다. 따라서 증거금 요건은 비선형적으로 증가하며 이는 하락장에서 공매수 포지션이 빠르게 청산되는 이유입니다.

이제 공매도 포지션 측을 살펴보도록 하겠습니다. 상승장과 하락장에서 이들은 위험 회피자와 시장 조성자가 될 가능성이 높습니다. 두 경우 모두 이러한 시장 참여자들은 비트코인의 미화 가치를 고정시키고자 합니다. 역방향 계약의 경우, 동등한 XBTUSD 상품의 공매도 포지션과 결합된 실물 기반의 공매수 비트코인 포지션은 통합된 미화 가치를 생성합니다. 실물 비트코인의 100%가 비트멕스의 교차 마진에 투자되는 경우 청산이 불가합니다.

공매수 포지션 측과 달리 공매도 포지션 측은 양수의 비트코인 볼록성에서 이점을 얻습니다. 공매도 포지션은 가격이 하락함에 따라 점점 더 많은 비트코인 수익을 얻고 가격이 상승함에 따라 점점 더 적은 손실을 입습니다.

이 두 가지 예에서 시사하는 바는 공매수 포지션의 투기자들이 하락장에서 더 빨리 청산될 것이라는 점입니다. 이는 왜 파생상품이 지배하는 시장에서 투매는 매집보다 더 극단적이며, 역방향 파생상품이 암호화폐 파생상품 시장을 지배하고 있는 한 지속될 이유를 설명해 줍니다.

시카고 상품거래소의 계약은 가격에 관계없이 고정된 비트코인 수량을 공개하고 있으며 미화 달러 공개는 가격에 따라 선형적으로 변화합니다. 이는 미화 달러화를 벤치마킹하는 투자자들에게 이로울 수 있는 반면, 노출을 회피하려는 사람들에게는 문제가 될 수 있습니다. CME 계약의 공매도 포지션을 헤지 (위험 분산)하기 위해 매수된 비트코인은 담보로 사용될 수 없습니다. 이는 실물 비트코인을 보유한 위험 회피자들과 상호 담보적인 구제 없이 파생상품과 현물 시장 사이에 귀중한 자본을 나눠야 하는 시장 조성자들에게 해결해야 할 몇 가지 과제를 제시합니다.

비트코인 캐시 하드포크 – 세 건의 상호 관련 사건

요약: 2019년 5월 15일에 시행된 비트코인 캐시 하드포크는 세 가지 중대한 상호 관련 문제로 인해 어려움을 겪은 것으로 보여집니다. “공격 거래”에 의해 악용된 취약점으로 인해 마이너들이 빈 블록을 생산하게 되었습니다. 빈 블록을 둘러싼 불확실성은 본래의 비 하드포크 체인에서 채굴 시도를 했을 수 있는 마이너들 사이에서 우려를 불러 일으켰을 수 있으며, 이는 합의된 체인 분할을 야기합니다. 실수로 세그윗 주소로 보내진 자금을 회수하기 위한 개발자와 마이너의 계획이 있었던 것으로 보이며, 위에서 언급한 취약점이 본 계획을 무산시켰을 수도 있습니다. 이 실패로 인해 의도적이고 조정된 2개 블록체인의 리오그를 초래했을 수 있습니다. 저희의 산출 방식에 따르면 약 3,392 개의 비트코인 캐시가 조정된 전환 거래에서 성공적으로 이중 지불되었을 수 있었습니다. 그러나 이렇게 이중 지불된 코인과 관련한 유일한 희생자는 원래의 “도둑”일 수도 있었습니다.

2019년 5월 15일에 시행된 비트코인 캐시 네트워크 분할 도표

(출처: BitMEX Research)
(공지사항: 분할을 도식화한 그림)

비트코인 캐시의 세 가지 문제점

2019년 5월에 시행된 비트코인 캐시의 하드포크 업그레이드는 세 가지 중요 문제로 인해 어려움을 겪었으며, 이 중 두 가지는 빈 블록을 초래한 버그 때문에 간접적으로 발생한 것일 수도 있습니다. 아래의 그림은 이 세 가지 사건 간의 잠재적 관계성을 보여주고 있습니다.

하드포크 업그레이드 과정에서 비트코인 캐시가 직면한 세 가지 문제 간의 관계성

(출처: BitMEX Research)

빈 블록 문제

비트코인 캐시에 대한 중요한 소프트웨어 구현체인 비트코인 ABC는 버그를 가지고 있는 것으로 보이며, 여기서 메모리 풀에 진입하기 위한 거래의 유효 조건은 합의된 유효 조건보다 덜 부담스러웠을 수 있습니다. 이는 비트코인 (및 비트코인 캐시)이 어떻게 운영될 것으로 예상되는 지와는 정반대이며 합의된 유효성 규칙은 메모리 풀보다 느슨해야 합니다. 이는 악성 지출자가 네트워크를 통해 전달하고 상업용 메모리 풀 진입에 있어 조건을 충족하는 거래를 생성하지 못하지만, 유효한 블록에 진입하기 위한 필요 조건을 충족하지 못하기 때문에 실제로 매우 중요한 특성입니다. 이는 본래 결제가 블록체인 상에서 이루어지지 않기를 바랄 필요 없이 제로 컨펌 이중지불공격 (0-confirmation double spend attacks)을 비교적 쉽게 수행할 수 있도록 허용합니다. 이러한 상황에서 공격자는 악의적으로 구성된 거래가 블록체인으로 연결되지 않을 것임을 상당히 확신할 수 있습니다.

공격자는 비트코인 캐시 ABC에서 이 버그를 발견한 후, 하드포크 시행 직후에 혼돈과 혼란을 일으키려는 시도로 해당 버그를 악용한 것으로 보입니다. 본 공격은 언제든지 수행될 수 있었습니다. 공격자는 메모리 풀 유효성 조건을 충족했지만 합의 검증에 실패한 거래 만을 전파할 수 밖에 없었습니다. 마이너들은 이러한 거래로 블록을 생성하려 했지만 결국 실패하고 말았습니다. 안전책으로 블록을 전혀 만들지 않는 대신, 적어도 대부분의 경우 마이너들은 빈 블록을 만든 것으로 보여집니다.

비트코인 캐시 – 블록 당 거래 수 – 하드포크를 나타내는 주황색 선

(출처: BitMEX Research)

비대칭 체인 분할

빈 블록을 둘러싼 불확실성이 최고조에 달했을 때, 저희 비트멕스의 사전 하드포크 비트코인 ABC 0.18.2 노드는 새로운 블록인 582,680을 받았습니다. 당시 많은 사람들이 빈 블록에 대해 우려했고, 일부 마이너들은 더 긴 체인은 문제가 되어 하드포크 이전으로 되돌아갈 수도 있다고 생각하여 이들 또한 하드포크 이전의 고객으로 되돌아갔을 가능성이 있습니다. 그러나 이는 저희의 추측일 뿐이며 빈 블록 버그는 체인 분할과 아무런 관련이 없었을 가능성이 있습니다. 본 버그는 너무 느려 업그레이드를 수행할 수 없는 마이너에 의해 야기되었을 수 있습니다.

비트코인 캐시 컨센서스 체인 분할

(출처: BitMEX Research)

본 체인 분할은 하드포크의 구조와 관련하여 저희에게 한 가지 문제를 부각시켰습니다. 저희 는 향후 하드포크 클라이언트인 ABC 0.19.0이 분할의 비 하드포크 측면을 유효한 것으로 간주할 지 여부를 시험했습니다. 본 분할이 “올바르게” 이루어지기 위해서는 분할의 각 측에서 다른 쪽을 유효하지 않은 것으로 간주해야 합니다.

더 짧은 사전 하드포크 체인의 유효성을 시험하기 위해 저희는 비트코인 ABC 0.19.0 노드의 관점에서 분할 이후 첫 번째 하드포크 블록을 무효화해야 했습니다. 그리고 나서 저희는 노드가 체인 분할을 따르는지 혹은 하드포크 지점에 고착되어 있는지를 살펴보았습니다. 놀랍게도 아래 스크린 샷에서 알 수 잇듯이 노드는 분할의 반대 쪽을 따랐습니다. 따라서 분할은 올바르게 이루어지지 않고 비대칭적이어서 공격자에게 더 많은 공격 기회를 제공했습니다.

비트멕스 비트코인 ABC 0.19.0 노드의 명령행 스크린 샷

(출처: BitMEX Research)

조정된 2개 블록의 리오그

하드포크 이후 몇 블록 후, 분할의 하드포크 측면에는 길이 2개의 블록체인 리오그가 존재했습니다. 당시 저희는 이것이 정상적인 블록 전파 문제에서 비롯된 것으로 간주했기에 크게 신경 쓰지 않았습니다. 예를 들어 비트코인 SV는 이보다 몇 주 전에 길이 6개 블록의 리오그를 경험했습니다. 비트코인 SV에 대한 리오그가 발생했을 때, 고아 체인 (orphaned chain)의 모든 거래는 결국 저희의 분석을 바탕으로 주요 성공적인 체인 (코인베이스 거래 제외)으로 진입하게 되었습니다. 그러나 본 비트코인 캐시 리오그에서 저희는 이 부분이 사실이 아닌 것을 확인하였습니다.

고아 블록 (the orphaned block)인 582,698은 137 건의 거래 (코인베이스 포함)를 포함하고 있었으며, 그 중 111건 만이 성공적인 체인으로 진입하였습니다. 따라서 25개의 거래와 관련하여 성공적인 2개 블록의 이중 지불이 발생한 것으로 보입니다. 아래 표에 나와 있는 바와 같이 이 25개의 거래의 산출값은 3,300 BCH (비트코인 캐시) 이상까지 합산됩니다.

주 체인으로 진입하지 못한 고아 블록 (582,698)의 거래 목록

거래 ID 산출량 합계 (BCH)
1e7ed3efb7975c06ca46598808e17c6f42c66a085fcb65356dc090e3c434d874 코인베이스 (집계되지 않음)
0cdd5afff40831199d78ac55116a94aaf4ea7d53e599ac44962c29861ef9f05e 79.9
1907e59313a5c2607f706e8439feb613ed3ff89530d17bd9deced7113928df79 358.9
27553ff15a9d58b10b33da69bef3ccd570c007fc0d695cf8b88817cfc4d49065 65.2
2ff74d9b244469dcd87f9c853b70f9bc72d4116c662ee12783a1c32a6825d45e 196.3
357e31bcf17b4d557954b2d69b7169559a64605a628c4bb9eb11adbd416967d1 117.4
3801dc4ee11ccaeda243ac287ee5e40afb0f07dc0ba26f534ea52f4bfde0d3da 161.2
83e6065dd31ef706f6a90669e460000741820c4dcb753290bd2b003a9f853211 71.2
8950cae069562893aa3583b75fd14f2aaef4f0db72292bd05e11f915ca38cd86 107.8
8e10f1f85d9707ca974ddabd9cb8188d0b890586781ef4161a9133dadefbe0e6 72.0
8fc0b3665f4734b56686ffec83f6b23000720af90102e20f39d9dddb5f1f5c25 183.0
99bd320fb7e3fc487b393c3b9afbc6a7bc765d7f9df5902201a70d3cb8fc5a63 57.8
a38b43f85cc592c4bd69b2b1f0f865df6d36f3b89dfa6119780197369e48192a 177.8
b091bf34d72444ff1669dd13b6c912d8801b94aad8a92d162a9680d46d4b727f 89.2
bd8ee13735dcbdad983fe9624c5b3fd3d257b15a62b269ddb40bb4be9d4a15cb 100.5
beae5bc9137beebddea6f5fbc6fe79b77f6d59f2aa2a5da675ccc39b2b2f8cb6 166.3
c47d1c18c39d28df21ce0e3c34021295658b56c7e669af3aebe685cea32462dc 210.3
c8031b2fd429d9e2838dccc7fa0631788139443a7609958c5d2ce195aec97f8a 85.7
cf3af954a7c3b327107aa42498ec31924075bd926a61428352695a696af8d6c4 114.8
cf8f47928c37bc24c88ff8ff8ea3c84419d4cedc907e74d113e681b055c566dc 162.0
dff4537328f2568db5b7f0fa81a57024fdeb9da23a432a893fb48eca1ab63079 115.9
e1398e628da1258db08f969efdade13e6daac6a53e5b43121dab3604c605af29 69.9
e926ce8ca0192b3ea7f971d93eec3f651e8a35839a76101512cb8c37f98caa89 126.8
e9e0482d61300d3b3d6a9340f9ee66bd6d098328cd7ced50416bb28eb8dc796e 307.4
ebc4392b27056b84a0337638f1257031172d842c148f9ffa10e80afc4080d8a1            82.7
f81267d65855040bf08bb5291a87733555067041ab611cd4e874368c8c1a2c2a 111.9
합계 3,391.7

(출처: BitMEX Research)

위의 표에서 알 수 있듯이, 이 25개의 이중 지불 거래의 총 산출값은 3,391.7 BCH 이며 이는 경제적인 측면에서 상당한 규모의 금액입니다. 따라서 본 리오그는 우연히 발생한 것이 아닌 계획된 사건으로 결론 지을 수 있습니다. 만일 본 리오그가 우연히 발생했을 경우, 분할된 각 측의 거래 간에 불일치가 없을 가능성이 있습니다. 그러나 이와 같은 조정과 고의적인 리오그를 가정하는 것은 저희의 추측일 뿐입니다.

저희는 아래 두 가지 이중 지불 예를 포함하였습니다:

이중 지불 UTXO (Unspent Transaction Output, 미사용 거래 산출량) 중 첫 번째 예시 – “0014”

(출처: BitMEX Research)

위의 표는 리오그가 발생했을 시 5 BCH 상당의 유동량에 어떠한 일이 일어났는지를 보여줍니다. 5 BCH는 582,698 블록의 qzyj4lzdjjq0unuka59776tv4e6up23uhyk4tr2anm 주소로 처음 보내졌습니다. 이 체인은 연결이 끊겨 동일한 유동량은 결국 7개의 블록 후에 다른 주소인 qq4whmrz4xm6ey6sgsj4umvptrpfkmd2rvk36dw97y로 보내졌습니다.

이중 지불 UTXO (Unspent Transaction Output, 미사용 거래 유동량) 중 두 번째 예시 – “0020”

(출처: BitMEX Research)

위의 산출량에 발생한 건은 25개의 이중 지불 거래에서 거의 모든 자금과 특성을 공유합니다. 대부분의 산출량은 주요 체인에 위치한 582,705 블록을 중심으로 고아 블록 이후 약 7번 째 블록에서 두 배 지불된 것으로 보입니다.

거래 입력 값을 반환 받는 데에 사용되는 SigScript는 위의 예에서 강조 표시된 “0020” 혹은 “0014”로 시작합니다. 이는 분리된 증인 (Segregated Witness, 비트코인 거래처리 용량 해결을 위한 업그레이드)과 관련이 있을 수 있습니다. 분리된 증인의 사양에 따르면, “0014”는 P2WPKH (공개 키 해시를 증명하기 위해 지불)에서 푸시되고 “0020”은 P2WSH (스크립트 해시를 증명하기 위해 지불)에서 푸시됩니다. 따라서 이러한 입력 값 반환은 비트코인 업그레이드인 분리된 증인과 관련이 있을 수 있으며 그 중 일부만 비트코인 캐시에 채택되었습니다.

실제로 저희의 분석에 따르면, 고아 블록 582,698의 25개 거래에서 모든 입력값은 “0014” 혹은 “0020”으로 시작하는 스크립트를 통해 반환되었습니다. 따라서 이러한 세그윗 산출량을 반환 받은 “공격자” 혹은 “도난자” 외에는 아무도 본 체인 리오그와 관련된 자금을 손실하지 않았을 가능성이 있으며, 이는 애초에 우연한 산출량으로 보내졌을 수 있습니다.

2019년 5월에 이루어진 비트코인 캐시 하드포크의 일환으로, 실수로 세그윗 주소로 보내진 코인을 회수할 수 있도록 허용하는 변경사항이 적용되었습니다. 따라서 이번 사건에서 이와 같은 일이 발생했을 수도 있습니다.

세그윗 복구 허용

마지막 업그레이드에서 실수로 세그윗 P2SH 주소로 보내진 코인은 CLEANSTAK 규칙에 따라 사용할 수 없게 되었습니다. 본 업그레이드는 이러한 코인에 대해 예외를 두고 사용 가능한 이전 상황으로 되돌릴 수 있습니다. 즉, P2SH 반환 스크립트의 사전 이미지가 공개되면 (예: 해당 비트코인 주소에서 코인 사용) 모든 마이너가 코인을 가져갈 수 있습니다.

(출처: https://github.com/bitcoincashorg/bitcoincash.org/blob/master/spec/2019-05-15-upgrade.md)

이 2개의 블록 리오그는 빈 블록 버그와 관련이 없을 수 있습니다. 그러나 버그가 해결된 후 단 한 블록 만에 분할이 발생한 것으로 보여 관련성이 있을 수 있습니다. 아마도 “정직한” 마이너들은 분할 직후 이러한 산출량의 사용을 조정 혹은 본래 소유주들에게 반환하기 위한 시도를 했을 것이며, 빈 블록 버그는 이들의 시기를 망침으로써 공격자가 수익을 얻고 이로 인해 발생한 자금을 쓸 수 있게 되었을 것입니다.

반면에 본 공격은 상당히 복잡하기 때문에 공격자는 고도의 정교함을 갖출 가능성이 높으며 광범위한 계획에 관여해야 합니다. 따라서 본 공격은 빈 블록 버그가 존재하지 않더라도 효과적일 수 있습니다.

결론

비트코인 캐시 하드포크 업그레이드를 둘러싼 여러 사건에서 많은 교훈을 얻을 수 있습니다. 하드포크는 악의적인 해커가 불확실성을 공격 및 생성할 수 있는 기회를 제공하는 것으로 보이기 때문에 이에 대한 신중한 계획과 조정이 중요합니다. 반면에 다른 두 사건의 근본적 원인일 수 있는 본 블록 버그는 언제든지 발생할 수 있었으며, 이러한 버그를 방지하려는 노력은 하드포크 시도 여부와 관계없이 중요합니다.

이러한 사건에서 또 다른 중요한 교훈은 투명성의 필요성입니다. 사건 발생 당시, 개발자의 계획, 버그의 성격 혹은 마이너들이 지원하는 체인을 확인하기 어려웠습니다. 공개 채널에서 이러한 문제에 대한 자유로운 의사소통은 더 큰 도움이 될 수 있었습니다. 특히 많은 사람들은 개발자가 세그윗 주소로 보내진 손실된 자금을 조정하고 회수하려는 계획을 인지하지 못했습니다. 본 계획과 관련하여 겉보기에 의도적이고 조정된 리오그가 발생하고 있는 동안뿐만 아니라 보다 사전에 커뮤니티에서 논의되었다면 도움이 되었을 수 있습니다. 이는 물론 후자를 공개할 시간이 있었다는 가정 하에 추측한 결론 임을 참고해 주시기 바랍니다. 또한 사후에 관련자들이 이러한 사건에 대한 세부사항을 공개하는 것도 도움이 될 수 있습니다.

이 모든 부분에서 저희의 견해로 볼 때, 가장 큰 관심사는 의도적이고 조정된 리오그입니다. 논쟁의 한 측면에서는 자금이 손실되었고 따라서 단기적인 혼란을 야기하더라도 해당 자금을 “본래의 소유자”에게 반환하는 행동이 정당화되었습니다. 그러나 현금과 같은 거래 완결성은 많은 사람들 또는 일부가 이러한 블록체인 시스템의 유일한 특징으로 보고 있습니다. 거래를 번복할 수 있는 기능은 이 경우, 중요한 거래는 경제적인 측면에서 시스템의 전체적인 전제를 훼손할 수 있습니다. 이러한 행위은 자금을 적절하게 확보하기 위한 동기를 없애고 선례를 남길 뿐만 아니라, 기대치를 변화시킬 수 있기 때문에 추가적인 거래 번복을 일으킬 수 있습니다.

비트코인 캐시를 좋아하지 않는 비트코인 커뮤니티의 모든 사람들에게 이는 코인을 비웃는 기회로 볼 수 있습니다. 그러나 비트코인 캐시는 비트코인보다 해시래이트가 훨씬 낮기 때문에 이러한 거래 번복이 더 수월해졌지만, 비트코인 캐시에서 이렇게 경제적인 측면으로 중요한 거래 번복의 성공은 저희의 견해로썬 비트코인과 관련하여 긍정적인 소식은 아닙니다. 어떤 면에서 이러한 사건들은 위험한 선례가 될 수도 있습니다. 이는 비트코인으로도 가능할 수 있음을 보여줍니다. 이는 또한 비트코인 캐시가 직면한 위험을 소수 체인으로 설명할 수 있습니다.

비트멕스 기술 확장 및 개선, 2부: 100배의 레버리지를 향한 길

본 보고서의 1부에서 저희는 비트멕스의 기원에 대해 살펴보았습니다.

오늘 저희는 본 시리즈의 2부를 게시하고자 합니다 – 즉, 과부하와 수평적 확장에 내재된 문제에 대한 심층적인 고찰입니다. 저희는 지금까지의 전례 없는 거래량을 처리하기 위한 노력을 결과를 살펴 볼 예정이며, 일렬 (단일)로 유지되어야 하는 비트멕스 엔진의 일부분을 비롯해 병렬화 (동시)될 수 있는 부분들과 비트멕스 API의 초기 설계에 대한 이점 또한 살펴 볼 예정입니다.

3부에서 저희는 이미 적용된 코드 최적화, 병렬화된 시스템, 그리고 특정 기능이 제거된 이유에 대해서 설명할 예정입니다. 저희는 또한 공정하고 동등한 기회에 대한 비트멕스만의 노력을 살펴 볼 예정입니다 – 그리고 이 부분이 동일 위치 제공 거부에 있어 어떤 의미로 해석되는지도 포함됩니다.

그럼 본격적으로 시작해보겠습니다.

성장

비트멕스는 암호화폐 업계에서 유일무이한 플랫폼입니다. 업계 최고의 레버리지와 기능을 제공하기 위해 비트멕스 거래 엔진은 암호화폐 및 전통적 금융 분야의 엔진과는 근본적으로 다릅니다. 저희는 예외적으로 정확한 거래 및 마진을 제공할 수 있지만 아직 특별히 빠른 편은 아니였습니다.

2017년 내내 비트멕스의 일일 평균 거래량은 129배 증가했습니다. 이는 놀라운 성장률이며 2018년과 2019년까지 계속 성장했습니다.

2016~2018년 매주 처리된 주문량
2018~2019년 매주 처리된 주문량.
본 도표는 마지막 도표 끝의 최고점에서 시작된다는 점을 유의해 주시기 바랍니다.

위의 도표에서 확인할 수 있듯이 주당 주문량도 2017년부터 급격히 증가했습니다. 특히 흥미로운 점은 주문율이 낮음에도 불구하고 2018년 7월 사상 최고치인 미화 8억 달러의 거래량에 달했습니다. 해당 기록은 11억 미화 달러가 거래된 지난 주 2019년 5월 11일까지 깨지지 않았습니다. 이러한 기록들은 여전히 단일 암호화폐 거래소에서 하루 동안 가장 많은 거래가 이루어지는 것을 의미하며, 비트코인 무기한 스왑 계약이 지금까지 개발된 상품 중에 가장 많이 거래되는 상품입니다. 그 이후로 설립된 열정적인 암호화폐 거래소들에 의해 수십 번 이상 모방되었습니다.

2018년 5월, 저희는 거래 엔진에서 주문 취소, 수정 및 이행 작업을 최적화하고, 내부 데이터 구조, 알고리즘 및 감사 점검을 재 작업하여 kdb+가 제공할 수 있는 종류의 속도를 구체적으로 조정하기 위한 집중적인 노력을 시작했습니다. 이는 기존의 거래 엔진이 수행하는 작업을 계속 수행할 수 있도록 하기 위한 초점적인 노력이었고, 단지 수행 속도가 훨씬 더 빨랐습니다. 저희는 이번 노력으로 불과 30일 만에 4.6배, 8월 말까지 10배 이상의 성능을 달성했다는 점에서 매우 자랑스럽게 생각합니다. 7월 중순까지 성능이 향상된 거래 엔진으로 인해 사실상 모든 과부하가 제거되었으며 저희는 이러한 놀라운 결과를 달성한 기술 팀이 매우 자랑스럽습니다.

아래는 과부하를 모든 쓰기 요청의 백분율로 나타낸 도표입니다 (주문 실행, 수정, 취소). 더 많은 빨간색 = 더 많은 과부하.

2018년 5월 5일
2018년 7월 16일

시장은 증가된 거래 처리 용량에 반응하며 비트멕스 거래량을 성층권으로 밀어 넣었습니다. 저희는 암호화폐 업계 사상 처음으로 거래량이 백만 비트코인에 이르는 날을 맞이했습니다. 여분의 거래 처리 용량으로 저희는 최초의 ETHUSD 콴토 무기한 스왑과 같은 혁신적인 신규 상품을 계속 출시할 수 있었습니다. 이는 상장 후 6주 이내에 거래된 ETHUSD 상품 중 1위를 차지했습니다. 2018년 11월, 저희 비트멕스는 24시간 만에 200만 비트코인에 도달했고 2019년 5월에는 11억 달러의 거래량을 달성했습니다.

7월 도표는 완전히 선명하게 보이지만, 본 글을 읽고 계신다면 여러분은 해당 도표는 앞서 언급한 바와 같이 유지되지 않았다는 것을 확인할 수 있습니다. 왜 완전히 고쳐지지 않는 걸까요? 왜 저희는 단순히 100배 이상에 도달하기 위한 노력을 계속하지 않았을까요?

그 배경을 살펴보도록 하겠습니다.

대기 행렬

비트멕스에서의 서비스 요청은 매표소에서 줄을 서서 기다리는 것과 유사합니다. 대기 행렬에 합류하고 대기 행렬이 원활해짐과 동시에 요청을 진행합니다.

티켓을 구매하는 데까지 시간이 얼마나 소요될까요? 음, 만일 대기 행렬이 없는 경우라면 매우 빠를 것입니다. 전체 상호 작용은 개별 요청을 처리하는 데에 걸리는 시간 동안만 지속됩니다. 이 때문에 부하와 거래량이 현저히 낮은 일부 다른 거래 서비스들은 최대 거래 처리 용량이 더 낮더라도 빠르게 느껴질 수 있습니다: 대기 행렬에 요청 수가 적습니다.

대기 행렬이 길면 어떤 일이 일어나는지 생각해 보시기 바랍니다. 요청이 처리될 때까지 기다려야 할 뿐만 아니라 앞서 대기하고 있는 모든 사람들의 요청이 완료될 때까지도 기다려야 합니다. 여러분 앞에는 세계에서 가장 효율적인 점원이 존재할 수는 있지만, 대기 행렬이 형성되기 시작하면 평균 사용자 경험은 매우 열악할 것입니다.

어떤 요청은 매우 간단하고 따라서 빠르지만, 어떤 요청은 더 복잡하고 더 많은 시간이 걸립니다. 만일 요청을 완전히 피할 수 있는 경우 (예: 사용자가 이를 완료하기 위한 충분한 잔고가 없는 경우), 자동 체크인 카운터 및 수화물 위탁과 같이 대기 행렬에 합류하지 않도록 최적화 방식을 도입합니다.

웹 서비스의 부하는 여러 가지 동일한 방식으로 작동합니다. 개별 요청을 처리하는 것이 매우 빠르더라도 단일 리소스에 대한 대기 행렬이 형성되면 사용자 경험이 저하됩니다.

여러분은 전에 이를 경험해 본적이 있을 것입니다. Amazon과 Alibaba는 휴일에 심각할 정도의 중단 시간을 겪은 적이 있습니다. Twitter는 악명 높은 고래 이미지 (과부하 될 시에 오류를 의미)를 내보내기도 했습니다. 그리고 비트멕스를 포함한 많은 플랫폼들은 때때로 역행의 대기 행렬 동작을 나타냅니다.

과부하

여러분이 알다시피 “시스템 과부하”는 저희 비트멕스가 본 문제를 해결하기 위해 활용하는 매커니즘 중 하나입니다. 혹시 의아해 하고 계신가요? 어떻게 과부하가 문제가 아닌 해결책이 될 수 있을까요? 과부하는 방어 매커니즘으로 업계에선 “부하 차단”으로 더 잘 알려져 있으며, 이는 정보 시스템에서 시스템을 손상시키고 어떠한 요청도 처리하지 못하게 하는 대신 일부 요청을 무시함으로써 시스템 과부하를 방지하는 기술입니다.

저희는 부하 차단과 관련된 명확한 규칙을 보여주고 해당 매커니즘을 설명하는 보고서를 게시했습니다:

미해결된 요청의 대기 행렬이 꽉 차지 않았을 시의 주문 실행
미해결된 요청의 대기 행렬의 꽉 찼을 시의 주문 실행 (과부하)

이를 이해하기 위해서는 부하 차단이 없는 시스템을 고려해야 합니다. 수요가 증가 함에 따라 대기 행렬이 형성되고 증가하기 시작합니다.

이러한 상황은 얼마나 나빠질 수 있을까요? 시장이 움직이기 시작하면 거대한 무리의 거래자들이 자신들의 포지션 증가 혹은 감소를 위한 주문 경쟁을 합니다. 이러한 지연이 스스로를 규제할 것이라고 생각할 수 있습니다: 서비스 품질이 저하됨에 따라 거래자들은 다음 주문을 이행하기 앞서 이전 주문에 대한 확인을 기다리면서 더 느린 속도로 주문을 이행합니다. 하지만 사실 그 반대 현상이 일어납니다: 응답 시간이 증가 함에 따라 자동화된 차익거래자들은 다른 거래소들과 일치하는 시가를 유지하기 위해 빠르게 개입할 수 없습니다. 다른 현명한 거래자들은 가격 책정에서 감지된 차이를 수동으로 거래하려고 시도하며, 이는 대기 행렬의 규모를 더욱 증가시킵니다.

보호 기능이 없으면 대기 행렬이 오랫동안 지연될 수 있습니다. 주문장 스프레드는 사용자가 효과적으로 지정가 주문을 이행하지 못함에 따라 증가합니다. 굉장히 매력적인 시장 가격은 실제로 주문이 대기 행렬을 통과하여 이행될 때는 형편없는 가격이 됩니다. 이러한 환경에서는 거래가 사실상 불가능합니다. 이는 단지 가설적인 것이 아닙니다; 다른 암호화폐 시장에서도 직면하고 있는 일반적인 문제입니다.

이에 대한 비트멕스의 해결책은 거래 엔진의 대기 행렬에 있을 수 있는 최대 주문 관리 요청 수를 제한하는 것입니다. 읽기 (예. GET /api/v1/position과 같은 데이터 불러오기) 및 쓰기 (예. 주문 이행/수정/취소 및 레버리지 변경)로 요청을 식별하는 서비스가 거래 엔진 앞에 존재합니다. 만일 요청이 쓰기인 경우, 주요 엔진에 할당되며 대기 행렬이 형성됩니다. 만일 이 대기 행렬이 너무 길어지는 경우, 주문은 대기 행렬에서 기다리지 않고 즉시 거부됩니다. 이러한 대기 행렬의 깊이는 엔진 성능에 맞춰 조정되어 최악의 경우 3초에서 5초까지로 대기 시간을 제한합니다.

저희 비트멕스의 부하 차단 문서에 따르면 취소와 같은 특정 유형의 요청은 크기와 관계없이 대기 행렬에 합류할 수 있지만, 다른 요청과 마찬가지로 대기 행렬의 뒤에서부터 합류하게 됩니다.

결과: 거래자들은 주문이 대기 행렬에 존재하는 것을 확인하는 대신 시스템에 지연이 겪고 있다는 것을 즉시 알 수 있으며, 주문을 이행하는 데까지는 몇 초가 소요됩니다. 해당 엔진은 속도를 늦추지 않습니다: 사실 과부하 중에 엔진은 최대 주문율에 도달하고 주문장과 거래 정보는 매우 빠르게 움직입니다.

과부하 시 거래

일부 거래자들은 과부하 중에도 거래가 지속된다는 점에 불만을 표했습니다. 사실 저희는 Twitter와 거래자들 간의 채팅 방에서 이는 특정 거래자들만이 시스템에 불공평하게 접근이 가능하기 때문이라는 점을 든 많은 음모론을 지켜봐 왔습니다. 이는 근본적으로 사실이 아닙니다: 비트멕스의 모든 거래자는 동일한 접근 권한을 가지며 동일한 대기 행렬에 합류합니다. 거래 엔진은 항상 대기 행렬의 요청을 가능한 한 빨리 처리합니다.

만일 시스템에 입력되는 주문 수가 시스템이 처리할 수 있는 주문의 5배일 경우, 총 주문 수의 20%만 승인되고 나머지 80%는 거부됩니다. 어떤 주문이 거부되고 어떤 주문이 받아들여지는지에 대한 결정은 단순히 주문이 제출되는 순간 대기 행렬에 공간이 있는지의 여부에 달려 있습니다. 만일 응답이 제공된 직후에 요청이 대기 행렬에 도달하는 경우, 대기 행렬이 최대 깊이 아래로 이동하면서 해당 요청은 승인됩니다. 여러분이 제출한 주문 이후의 주문은 여러분의 주문이 아닐 수도 있습니다.

거래가 가장 집중되는 시간 동안 비트멕스는 주문 입력율이 평균보다 20배에서 30배 증가하는 현상을 경험하게 됩니다! 실행된 거래량이 분당 100만 달러 이상의 최고점에 도달했습니다. 만일 이 비율이 지속되는 경우, 시간당 6억 미화 달러 혹은 하루에 144억 미화 달러 이상의 거래량을 달성할 수 있습니다. 이는 비트멕스 혹은 다른 암호화폐 플랫폼에서 하루 만에 기록된 상위 거래량의 13배입니다.

상단: 총 요청 수. 보라색 = API, 파란색 = 프런트엔드.
하단: 10초 단위마다 거부된 주문 비율. 본 예시는 비정상적으로 높은 비율을 보이며 최악의 경우에 발생할 수 있는 과부하를 나타냅니다. 실제로 매일 비트멕스에 제출되는 모든 주문의 2~3%만이 부하 차단 기능에 의해 거부됩니다.
위에서 보여진 주문율의 큰 증가를 초래한 급격한 시장의 움직임.

저희 비트멕스는 항상 원할한 거래 경험을 제공하기 위해 이와 같이 강력한 이벤트를 처리할 수 있는 큰 규모의 예비 용량을 보유해야 합니다. 저희는 본 목표를 달성하는 데에 있어 직면한 몇 가지 과제를 아래와 같이 문서화할 예정입니다.

높은 확장성과 암달의 법칙 (Amdahl’s Law)

확장성 문제는 어떻게 해결될 수 있을까요? 확장성에는 두 가지 유형이 있습니다: “수직” 및 “수평”입니다. 수직적 확장은 개별 시스템을 더 빨리 만드는 작업을 포함합니다. 본 작업은 더 빠른 프로세서 (행운을 빕니다; CPU에 대한 무어의 법칙은 더 이상 존재하지 않습니다)를 구매하거나 작업량을 줄일 수 있는 방법을 찾음으로써 수행할 수 있습니다. 반면에 수평적 확장은 “더 많은 돈을 쏟아 붓는 것”의 다양성을 의미합니다: 더 많은 서버를 운영하고 그 중에서 부하량을 분산시킵니다.

웹 서버는 수평적으로 확장 가능한 서비스의 좋은 예입니다. 가장 적절하게 구성된 시스템에서는 더 많은 웹 서버를 추가하여 고객의 요구를 처리할 수 있습니다. 하나의 응답이 다른 응답에 의존하지 않을 때, 식료품 점의 계산대 점원과 같이 서버가 동시에 작동하는 것이 안전합니다.

이는 대규모의 간소화 작업이지만 많은 사람들에게 확장성 해결책은 “문제 해결을 위한 막대한 비용”의 긴 버전입니다. 많은 시스템들이 수평으로 확장됩니다. 대부분의 고객 경험은 서로 완전히 독립적이며 단순히 더 많은 웹 서버에서 제공할 수 있습니다. 백업 데이터베이스는 흔히 서로 복제하여 수평적으로 확장될 수 있습니다.

수평적 확장이 가능한 정도에는 한계가 있으며 이를 흔히 암달의 법칙(Amdahl’s Law)으로 표현합니다. 간단히 말하자면, 시스템의 수평적 확장성은 연쇄 작업 (혹은 특정 순서에서 발생해야 하는 작업)에 의해 제한됩니다. 이는 다음과 같이 설명할 수 있습니다: 속도를 높이고자 하는 단순하고 단일 스레드 (하나의 프로그램 내에서 동작하는 여러 갈래의 작업 흐름) 서비스를 여러 서버를 통한 동시 작업을 상상해 보시기 바랍니다. 일부 성능 분석을 통해 작업의 25%만이 순서대로 완료되어야 한다는 것을 알 수 있습니다. 이는 아무리 많은 코어 혹은 서버를 해당 문제에 투입하더라도, 1/25% = 4 공식과 같이 4배까지만 속도를 낼 수 있다는 것을 의미합니다. 이 정도의 연쇄 작업은 병목 현상을 야기합니다.

출처: https://learnyousomeerlang.com

이러한 연쇄 작업 요구사항은 비트멕스가 대부분의 일반 웹 서비스와 크게 차별을 두는 점입니다. 비트멕스 거래 엔진은 훨씬 더 많은 연쇄 작업 요구사항을 가지고 있어 병렬화 기회를 심각하게 제한하고 있습니다.

순차적인 문제: 주문 및 추가 증거금

비트멕스 거래 엔진은 순차적인 FIFO (First-In-First-Out, 선입선출법) 방식으로 주문을 처리합니다. 여러분이 가장 좋아하는 케이블 공급업체와의 통화를 기다리는 것과 마찬가지로, 거래 엔진으로의 요청은 수신되는 순서대로 처리됩니다.

이는 시장의 기본 원칙이며 변경될 수 없습니다. 주문장에는 순차적으로 주문이 적용되어야 합니다 – 즉, 주문 순서가 중요합니다. 공격적인 주문이 이행될 때, 해당 주문은 주문장에서 유동성을 취하고 다른 어떤 주문도 이를 소모하지 않습니다. 이러한 이유로 개별 시장에서의 일치성은 효과적으로 분산될 수 없습니다; 그러나 이러한 일치성은 시장별로 단일 프로세스에 할당될 수 있습니다.

보고서 작성 당시 비트멕스는 엔진에 앞서 프록시 (proxy, 서버와 클라이언트 사이에서 대리로 통신을 수행하는 기능)와 직접 통신을 수행하는 약 150개의 API 서버를 운영합니다. 본 프록시는 읽기 요청 및 웹소켓 데이터를 각각 데이터 이중화와 pub/sub 시스템에 할당하며, 쓰기 요청은 엔진에 직접 할당합니다.

쓰기 요청은 예상대로 시스템의 가장 비싼 부분이며 규모를 확장하기가 가장 어렵습니다. 거래 시스템이 효과적으로 작동하기 위해서는 다음 사항이 충족되어야 합니다:

  • 모든 참여자는 동일한 시장 데이터를 동시에 받아볼 수 있어야 합니다.
  • 참여자는 언제든지 쓰기 요청을 전송할 수 있습니다.
    • 만일 본 쓰기 요청이 유효하고 공용 상태를 변경하는 경우, 수정된 실제 상태는 승인되고 실행된 후에 모든 참여자에게 전송되어야 합니다.

최적화되지 않은 본 시스템은 2차 확장을 수행합니다: 분당 1개의 주문을 보내는 100명의 사용자가 각 참가자에 대해 1개씩 10,000개 (100 * 100)의 시장 데이터 패킷을 생성합니다. 사용자가 1000명으로 10배 증가하는 경우 시장 데이터 (1000 x 1000)가 100배 이상 생성됩니다.

본 보고서의 앞부분에서 언급했듯이 비트멕스는 2017년에 129배 성장하였습니다. 해당 기간 동안 저희 비트멕스의 사용자 기반은 비례적으로 확장되었습니다. 이는 2017년 12월 31일, 저희가 2017년 1월 1일에 비해 16,641배 (129 * 129) 더 많은 메시지를 전송하고 있었다는 것을 의미합니다.

시스템 일관성

비트멕스에 있어 확장은 분명 어려운 작업입니다. 저희 비트멕스는 전형적인 현물 혹은 파생 상품 플랫폼이 아닙니다: 저희는 가입, 입금, 거래에 이르기까지 고객의 전체 생애주기를 관리합니다.

100배의 레버리지를 안전하게 제공하기 위해서는 비트멕스의 시스템이 정확해야 하며 속도 또한 빨라야 합니다. 비트멕스는 사용자가 추가 증거금을 투입하는 데에 있어 마지막 거래 가격이 아닌 계약의 기본이 되는 현물 거래소 가격의 종합지수를 사용하며, 독창적이고 흔히 모방된 공정가격 표시 시스템을 갖추고 있습니다. 이는 외부 유동성을 참고함으로써 비트멕스 시장 내에서의 조작을 훨씬 더 효과적으로 방지합니다.

본 시스템이 제대로 작동하기 위해서는 비트멕스 엔진이 일관성을 유지해야 합니다. 시장 평균가가 변동될 때마다 해당 시스템은 포지션을 보유하고 있는 사용자들의 추가 증거금을 재설정합니다. 이때 시스템 전체가 제어 루틴에 의해 감사가 이루어집니다. 모든 오픈포지션, 미체결주문 및 잔여 마진은 모든 입금 금액과 정확하게 동일해야 합니다. 단 하나의 사토시라도 누락되지 않아야 하며, 그렇지 않으면 시스템이 종료될 수 있습니다! 이는 저희 비트멕스의 초기 운영 시절에 몇 번 발생한 적이 있습니다; 매번 추천인 프로그램 수익 혹은 수수료에 대한 사토시의 반올림 오류가 원인이었습니다. 오류가 발생할 경우 소규모의 완충자금을 구축하고 싶은 유혹은 있었지만, 저희 비트멕스 팀은 본 시스템의 지불 능력이 최고라고 믿습니다: 저희는 가능한 한 최고 수준의 기준을 고수합니다. 본 시스템은 오늘 날에도 상태에 주요한 변경사항이 있을 때마다 정확한 사토시 합계에 대한 감사를 수행하고 있습니다.

비트멕스에서 데이터베이스 접근 권한을 가진 악의적인 해커가 단순히 자신의 잔고를 편집할 수 없습니다: 해당 시스템은 비정상적인 방식으로 발생한 돈을 즉시 인식하여 치명적인 오류를 내보내고 종료합니다.

감사가 이루어지기 전, 전체 계정의 현재 가치는 처음부터 재계산되어야 합니다; 이는 새로운 가격으로 인한 모든 오픈 포지션과 미체결주문의 가치입니다. 이로 인해 거래자들은 자신들이 감당할 수 없는 규모의 계약을 체결할 수 없게 됩니다. 거래자들은 비트멕스에서 음수의 잔고에 도달할 수 없습니다. 다시 말해, 잔고가 마이너스가 되지 않습니다.

본 시스템의 속도를 높이는 것이 저희의 확장성 노력의 주요 목표 중 하나입니다. 일치성은 상대적으로 시간이 적게 소요되고 쉽게 확장할 수 있습니다; 반대로 증거금 산출은 쉽지 않습니다. 비트멕스는 항상 “정확성 우선, 속도는 차후에” 라는 마음가짐으로 노력해왔습니다 – 따라서 본 작업에 소요되는 시간은 앞서 언급한 정확성을 바로잡기 위한 저희 비트멕스의 약속이기 때문입니다. 잘못된 결과는 용인할 수 없으므로 올바르게 배포된 시스템은 느리거나 실패한 산출 결과 제공 기능을 감지하고, 부하를 재조정하여 빠듯한 시간 예산 내에서 필수적인 절차를 완료할 수 있어야 합니다. 이를 위해서는 신중하고 체계적인 주의와 엄격한 테스트가 요구됩니다.

저희 비트멕스의 엔지니어들은 최적화가 안전하게 이루어질 수 있는 몇 몇의 핵심 영역을 확인하였으며, 플랫폼의 거래 처리 용량을 획기적으로 증가시킬 수 있는 새롭고 탄탄한 플랫폼 구조를 제공하기 위해 끊임없이 노력하고 있습니다.

API 우선 설계

비트멕스는 타 경쟁사들과 비교하여 훨씬 유일무이한 거래 플랫폼입니다: 비트멕스 플랫폼은 API를 우선 순위로 구현되었습니다. 비트멕스의 구조는 세 가지 주요 부분으로 구성되어 있습니다: 거래 엔진, API 및 웹 프런트 엔드입니다. 저희가 왜 “특정” 프런트엔드라는 단어를 사용하지 않았는지에 대해 주목해 주시기 바랍니다. 그 이유는 무엇일까요?

비트멕스를 구축할 당시에 저희가 구현하고자 하는 API가 동종 업계 최고 수준이기를 바랬습니다. 훌륭한 API는 개발자들이 견고한 도구를 쉽게 개발할 수 있도록 기여합니다. 이는 심지어 저희가 상상해 보지도 않았을 상호적인 시각화 및 인터페이스 또한 구현합니다. 저희가 코딩 작업을 시작했을 당시, 암호화폐 거래에 있어 API 사용은 그다지 큰 의미가 없다는 의견이 팽배했습니다. 많은 사람들이 규칙성, 문서화 또는 사전에 작성된 어댑터의 유사성을 놓치고 있었고, 중요한 데이터는 흔히 누락되었으며, 중요한 기능은 웹사이트를 통해서만 수행할 수 있었습니다. 설상가상으로 이 중 대부분은 웹소켓 정보 제공 기능 조차도 없었을 뿐만 아니라, 그나마 해당 기능을 가지고 있던 소수의 사람들은 이를 비공개로 유지하고 웹사이트를 통해서만 접근할 수 있었습니다.

저희 비트멕스는 이러한 추세를 거스르고 암호화폐 API에 대한 새로운 표준을 수립했습니다. 저희는 타 프로그램에서 API가 사용 가능할 수도 있는 것처럼 당사 웹사이트에서도 API 사용 의무를 규정함으로써 시험 사용에 대해 신중한 정책을 채택했습니다. 이는 “특정” 프런트엔드가 아닌 단순히 비트멕스의 공식적인 프런트엔드만이 존재한다는 것을 의미합니다. 하나의 프로젝트로써의 비트멕스 웹사이트는 API 개발자들의 선호감과 몇 가지 로그인/등록 오용방지 메커니즘 이외에 특별한 접근 권한이 없습니다.

이는 또한 비트멕스에 접근하는 메커니즘이 또 다른 메커니즘보다 빠르거나 느리지 않음을 의미합니다. 모든 사용자는 모바일 장치, 브라우저, 사용자 지정 API 연결기 혹은 시에라 차트의 DTC (Data and Trading Communication, 데이터 및 거래 통신) 통합을 통해 접근하는 경우와 관계없이 동일한 데이터 경로와 대기 행렬에 합류합니다.

처음부터 비트멕스는 아래의 기능을 갖추고 있었습니다:

실시간 데이터

비트멕스의 API 우선 설계에 대한 노력은 웹소켓을 통해 노출된 실시간 데이터를 구현하는 데서 빛을 바라고 있습니다. 위에서 언급했듯이 모든 테이블에는 실시간 정보 제공 기능이 존재합니다. 이는 암호화폐 업계에서는 처음이며 오늘날에는 극히 드문 경우입니다. 또한 모든 테이블은 동일한 형식을 따르므로 스트림을 처리할 수 있는 코드 줄을 최소 30줄까지 쓸 수 있습니다. 혹은 당사의 GitHub에서 입수하여 사용하실 수도 있습니다.

본 데이터는 개별 사용자 서명을 위해 필터링이 이루어진 엔진 자체에서 생성된 변경 스트림에서 처리됩니다. 이는 비트멕스 상단의 인터페이스를 구축할 때 매우 손쉬운 처리 방식을 가능케 합니다: 테이블에 서명 후 요청을 보내며 또한 스트림에서 변경사항을 수신 대기합니다. 일반적으로 HTTP 요청에 대한 응답은 오류가 아닌 이상 무시할 수 있습니다. 이는 웹소켓 스트림과 HTTP 응답 모두를 별도로 읽고 병합해야 하는 어플리케이션에서 공통적인 이원성을 방지하여 다루기 힘든 코드와 버그를 생성합니다.

저희는 최상위 어플리케이션 인터페이스를 구축하는 이러한 철학이 최고의 사용자 공간 통합을 제공할 뿐만 아니라, 비트멕스 웹사이트와 곧 출시될 모바일 앱 또한 최상의 상태로 만들어질 것이라 믿습니다.

저희의 실시간 정보 제공 기능은 비트멕스 플랫폼이 정상적으로 작동하는 데에 있어 가장 중요합니다. 이를 위해 저희는 외부 변경 없이 대기 시간과 처리량을 크게 개선시킬 것으로 기대되는 본 시스템의 주요 내부 재 작업을 준비 중에 있습니다. 저희는 곧 이와 관련하여 출시 날짜와 결과를 발표할 예정입니다.

다음 단계

저희는 플랫폼의 향후 100배 성장을 위해 확장하는 동시에 위의 내용을 통해 비트멕스가 직면한 도전에 대하여 어느 정도 이해하셨기를 바랍니다. 저희는 해당 플랫폼의 성공과 사용자들에게 감사한 마음을 가지고 있는 한편, 앞으로 몇 년 동안 지속적으로 개선해 나갈 필요가 있다고 생각합니다.

비트멕스 거래 엔진 팀은 일주일에 여러 번 플랫폼에 대한 업데이트를 발표합니다. 이러한 점진적 변화들은 모두 엔진에 대한 전술적 용량 개선의 일환일 뿐만 아니라 거래 플랫폼의 지속적인 장기 재구축 작업이기도 합니다. 이러한 노력, 성공, 실패는 본 시리즈의 3부에서 살펴 볼 예정입니다.

비트멕스 엔진 팀은 정기적으로 시스템 처리량에 대한 주요 업그레이드를 수행할 수 있었습니다. 엔진 팀은 최근 2019년 5월 23일에 새로운 주문 처리 용량을 70%까지 증가시킨 주요 인프라 업그레이드를 수행하였습니다. 이와 같이 상당한 용량 개선은 향후 몇 개월 동안 계속 제공될 예정이며 해당 플랫폼의 대규모 재구축 작업 또한 병행될 것입니다.

신규 주문 중앙값, 평균 및 99%-ile (퍼센타일) 처리 시간. 업그레이드된 코드는 대략 01:20 UTC (한국시간 기준 10:20분)에 발표되었습니다.
95%-ile (퍼센타일)에서의 주문 취소 처리 시간 (API를 통해 사용 가능한 세 가지 유형의 취소 작업)

이와 같이 당사 거래 엔진을 확장하는 작업이 빠르게 진행되는 동안에도 저희는 비트멕스 팀 또한 활발히 늘려가고 있습니다. 저희 비트멕스는 전자 거래 시스템, 확장성, 인프라, 보안, 웹 등의 분야에서 세계적으로 저명한 전문가들을 고용하고 있으며, 배우기를 두려워하지 않고 어떠한 업무에도 흔쾌히 참여할 준비가 되어있는 사람들을 위한 중간자 역할을 수행하고 있습니다. 만일 본 보고서가 여러분께 흥미롭게 다가온다면, 여러분은 저희 비트멕스가 바라는 인재상일 수 있습니다; 비트멕스 채용과 관련하여 더 자세한 사항은 비트멕스 채용정보 페이지에서 확인해 주시기 바랍니다.

비트멕스 알트코인 / 비트코인 지수 업데이트, 2019년 5월

2019년 5월 22일 04:00 UTC (한국 시간 2019년 5월 22일 13:00시)를 기점으로 Kraken은 비트멕스의 알트코인 및 비트코인 지수에 다시 도입될 예정입니다.

이번 업데이트는 Kraken의 시장 데이터 피드 처리기가 Kraken의 REST API를 사용하여 새로운 웹소켓 API로 변경된 사항을 반영합니다.

앞서 언급한 변경 사항은 다음의 지수와 각 계약 상품에 적용될 예정입니다:

지수명

구성 요소

상품명

.BBCHXBT

(⅓ * Binance + ⅓ * Poloniex + ⅓ * Kraken)

BCHM19

.BEOSXBT

(⅓ * Binance + ⅓ * Poloniex + ⅓ * Kraken)

EOSM19

.BETH

(⅓ * Bitstamp + ⅓ * Coinbase Pro + ⅓ * Kraken)

ETHUSD

.BETHXBT

(⅓ * Binance + ⅓ * Poloniex + ⅓ * Kraken)

ETHM19

.BLTCXBT

(⅓ * Binance + ⅓ * Poloniex + ⅓ * Kraken)

LTCM19

.BXBT

(⅓ * Bitstamp + ⅓ * Coinbase Pro + ⅓ * Kraken)

XBTUSD, XBTM19,XBTU19,XBT7D_U105,XBT7D_D95

.BXRPXBT

(⅓ * Binance + ⅓ * Poloniex + ⅓ * Kraken)

XRPM19