이번 시간에는 이더리움 테스트를 위한 테스트 노드 Goerli 설치하는 방법을 소개하겠습니다.
목차
1. 기본 환경 설정 2. geth 노드 설치 및 실행 3. prysm 모듈 설치 및 실행 4. 기타
0. 설치 환경
- 하드웨어: 최소 CPU 4 core, Mem 8 G, SSD 400 G (AWS c5.xlarge, c5.2xlarge)
- OS: 리눅스(Ubuntu20.04 등)
1. 기본 환경 설정
# 관련 패키지 설치
sudo apt-get install
sudo apt-get update
sudo add-apt-repository ppa:ethereum/ethereum
sudo apt-get update
sudo apt-get install ethereum
# geth 버전 확인
geth version
#---------------------------
Geth
Version: 1.10.25-stable
Git Commit: 69568c554880b3567bace64f8848ff1be27d084d
Architecture: amd64
Go Version: go1.18.5
Operating System: linux
GOPATH=
GOROOT=go
#---------------------------
2. geth 노드 설치 및 실행
# 디렉토리 생성
mkdir ethereum
cd ethereum
mkdir consensus
mkdir execution
cd consensus
mkdir prysm
cd prysm
# 키 생성
openssl rand -hex 32 | tr -d "\n" > "jwt.hex"
# geth 실행
nohup geth --goerli --http --http.api eth,net,engine,admin --authrpc.jwtsecret ./jwt.hex > geth.log &
# --syncmode snap/full/light 선택 가능
# 백그라운드 실행 설정(nohup ... &) 및 로깅 설정( > geth.log)은 필요시 사용한다.
# 로그 확인
tail -f geth.log
3. prysm 모듈 설치 및 실행
# 신규 터미널에서 prysm 다운로드
cd ethereum/consensus/prysm
curl https://raw.githubusercontent.com/prysmaticlabs/prysm/master/prysm.sh --output prysm.sh && chmod +x prysm.sh
wget https://github.com/eth-clients/eth2-networks/raw/master/shared/prater/genesis.ssz
# prysm 실행
./prysm.sh beacon-chain --execution-endpoint=http://localhost:8551 --prater --jwt-secret=./jwt.hex --genesis-state=genesis.ssz --suggested-fee-recipient=0x01234567722E6b0000012BFEBf6177F1D2e9758D9
# 관련 동의 후 백그라운드 실행
nohup ./prysm.sh beacon-chain --execution-endpoint=http://localhost:8551 --prater --jwt-secret=./jwt.hex --genesis-state=genesis.ssz --suggested-fee-recipient=0x01234567722E6b0000012BFEBf6177F1D2e9758D9 > prysm.log &
# 수수료 수신할 주소는 변경한다.
# 백그라운드 실행 설정(nohup ... &) 및 로깅 설정( > prysm.log)은 필요시 사용한다.
# 로그 확인
tail -f prysm.log
4. 기타
# 블록을 Sync 하는데 약 4-5일 소요된다.
[2022-10-18 08:05:33] INFO p2p: Peer summary activePeers=39 inbound=0 outbound=39
[2022-10-18 08:05:36] INFO initial-sync: Processing block batch of size 63 starting from 0x0f88f3c9... 156800/4131028 - estimated time remaining 116h12m19s blocksPerSecond=9.5 peers=39
# 따라서 geth 실행시 --syncmode light 등을 적용하여 목적에 맞게 노드를 운영한다.
오늘 UTC PM 10:12:49 이후로 바이낸스 BSC 체인이 블록생성이 멈추었습니다. 참고[1]
- 멈춘지 4시간이 지났네요. 우리나라 시간으로 10/7 오전 8시 12분 경이네요.
바이낸스에서 운영하는 BSC Token Hub에 취약점이 발견되어 BSC 체인을 일시적으로 중지한 것입니다.
이 글에서는 해당 해킹 사건에 대해서 분석해 보고자 합니다.
목차
1. 개요 2. 해킹 분석 3. 패치 및 대응 4. 고찰
1. 개요
- BSC 공지 내용 원문 (참고[2])
Temporary Pause of BSC
We want to confirm that we coordinated with validators to temporarily suspend BSC after having determined an exploit on a cross-chain bridge, BSC Token Hub- which resulted in extra BNB. We have asked all validators to temporarily suspend BSC. The issue is contained now. Your funds are safe. We apologize for the inconvenience and will provide further updates accordingly. The Community has already played a pivotal role in assisting and helping freeze any transfers. All funds are safe. We want to thank the node service providers for their quick and attentive response. A huge thank you to the following: Hash, Neptune, TW Staking, BSCScan, Legend, CertiK, Figment, NodeReal, Namelix, Defibit, Fuji, InfStones, MathWallet, Pexmons, Ankr, BNB48 Club, Avengers, Tranchess, Coinbase Cloud For their quick and decisive actions - a true community. Initial estimates for funds taken off BSC are between $100M - $110M. However, thanks to the community and our internal and external security partners, an estimated $7M has already been frozen. We are humbled by the speed and collaboration from the community to freeze funds. Thank you to everyone who helped and gave their support.
해당 공지는 바이낸스가 BSC 노드 검증자(Validator)들에게 BSC 토큰 허브에 BNB 토큰이 추가로 발행되는 취약점을 확인하고자 노드를 중지하고자 한다는 내용입니다.
해커가 빼낸 자금은 약 1 ~ 1.1 억 달러 이고, 그 중 7 백만 달러는 동결되었다고 합니다.
이용자의 자금을 악의적인 거래소가 훔칠 수 없도록 하면서도 고속 거래 및 낮은 수수료를 보장
머클 트리 기반의 검증 방식 사용 (Fact Registry, 참고[4])
StarkEx High-Level Architecture
- StarkEx Smart Contract Architecture
StarkEx Smart Contract Architecture
Proxy Contract: 상태 정보 및 관련 컨트랙트 정보 저장(solidity proxy pattern, 참고[5])
Dispatcher Contract: 업그레이드 가능한 컨트랙트 구현 패턴(diamond standard, 참고[6])
Sub-Contracts: StarkEx 에서 필요한 기능들이 구현된 컨트랙트들
Verifier Fact-Registry: Fact Registry를 검증하는 컨트랙트
Committee Fact-Registry: Fact Registry를 등록하는 컨트랙트
- StarkEx Back End Architecture
StarkEx Back End Architecture
Gateway: 거래소로 부터 Tx를 수신
Batching & Validation: 배치 작업 및 Tx 검증
Baches info: 배치 정보 공개
Changes Approval GW: 사용자 지정 오프체인 로직을 사용할 수 있도록 함(위원회 승인 필요)
Proving: 외부 증명 서비스를 통해 상태 전환 증명 생성, 온체인 검증자(Fact Registry)에 등록
Packing: 블록체인에 전송할 데이터(주소, payload 등)를 묶음
Blockchain Writer: 보낼 데이터에 네트워크 정보(가스, nonce, 서명 등)를 포함하여 블록체인에 전송
Catcher: 블록체인을 모니터링하여 배치 모듈에 내용 전달
- StarkEx Partner Integration
StarkEx Partner Integration
Front End: 사용자 요청에 대해 온체인(이더리움)과 오프체인(StarkEx) 둘 다 지원해야 함
일반적으로 사용자가 온체인 요청을 하면 백엔드에서는 오프체인 요청이 되도록 구성
Order Verification: 사용자 주문 확인(서명, 잔액, 금고ID 등)
Business Logic: StarkEx에 전달할 Tx 처리 및 계정 상태 업데이트
TX Stream: 0부터 시작하는 tx_ids라는 연속적인 식별자로 유효성을 검사하고, 인덱싱
Tx Sender: StarkEx Gateway에 Tx 전송 (비동기식)
Error Handler: 유효하지 않은 거래 정보를 수신하여 이전 상태로 복원
State Approval: 모든 배치를 블록체인으로 전송하기 전에 승인하는 절차
Censorship Prevention: 검열 방지를 위해 사용자가 특정 작업을 블록체인 상의 StarkEx 컨트랙트에 직접 제출 가능하도록 함
3. 무기한 계약(Perpetual Contracts)
- dYdX는 다양한 자산에 대한 비보관형 탈중앙화된 마진 상품을 제공
- Margin(증거금)
담보는 USDC로 보유
개시 증거금 요건 = abs(S × P × I)
유지 증거금 요건 = abs(S × P × M)
총 개시 증거금 요건 = Σ abs(S i × Pi × I i )
총 유지 마진 요구 사항 = Σ abs(S i × P i × M i )
총 계정 가치 = Q + Σ (S i × P i )
무료 담보 = 총 계정 가치 - 총 개시 증거금 요구 사항
S 포지션 크기입니다(롱이면 양수, 숏이면 음수)
P 시장에 대한 오라클 가격입니다
I 는 시장의 개시 증거금 비율입니다.
M 는 시장에 대한 유지 마진 비율입니다.
- Liquidations(청산)
종가(숏) = P × (1 + (M × V / W))
종가(롱) = P × (1 − (M × V / W))
P 시장에 대한 오라클 가격입니다
M 는 시장에 대한 유지 마진 비율입니다.
V 위에서 정의한 총 계정 가치입니다.
W 위에서 정의한 총 유지 증거금 요구 사항입니다.
- Funding(펀딩)
롱 과 숏 거래자 사이에 교환
펀딩 비율은 1시간 비율로 표시
펀딩 비율 계산
프리미엄 = (최대(0, 임팩트 입찰가 - 지수 가격) - 최대(0, 지수 가격 - 임팩트 매도호가)) / 지수 가격
Impact Bid Price = 임팩트 명목 가치의 시장 매도 평균 실행 가격
임팩트 매도호가 = 임팩트 명목 가치의 시장 매수에 대한 평균 실행 가격
영향 명목 금액 = 500 USDC / 개시 증거금 비율
펀딩 비율 = (프리미엄 요소 / 8) + 이자율 요소
- Contract Loss Mechanisms(계약 손실 메커니븜)
변동성이 크게 되면 일부 계정의 가치는 0 아래로 떨어질 수 있음
보험 기금으로 손실 부담
보험 기금이 고갈된 경우 가장 높은 이익과 레버리지를 가진 포지션으로 마이너스 잔고 계정을 상쇄할 수 있음
- Oracle Prices(오라클 가격)
각 거래 후 각 계정이 잘 담보되었는지 확인
계정을 청산해야 하는 시점 결정
15개의 독립적인 Chainlink 노드로 계산
- Index Prices(지수 가격)
펀딩 비율 계산
Stop-Limit and Take-Profilt 주문과 같은 트리거 가능한 주문 트리거(촉발)
4.보안
- PeckShield 에 외부 감사(참고[7])
5.평가
- 중앙화된 거래소의 빠른 거래 속도와 탈중앙화된 거래소의 스마트 컨트랙트 방식을 하이브리드 형태로 제공하는 DEX 서비스
- 기술적으로 완전 탈중앙화가 아닌 자체 거래소 구축 모듈에 의존하는 방식이므로 다양한 문제가 발생할 수 있음
- 이용자 보호를 위한 보험 및 추가적인 보호 방식을 제공하지만 공격 발생시 실효적으로 대응하기 어려운 것으로 판단됨
