블로그

인공지능과 무선 통신, CSI를 중심으로

실토 — Fri, 23 Jul 2021 18:39:23 +0900

고도로 발달한 무선 통신은 시각 처리와 구별할 수 없다

이 글은 2021년 5월 진행된 POSTECH TechReview 세미나에서 이어져 7월에 투고한 원고의 줄이기 전 원본입니다. 이 분야를 완전히 모르는 사람을 대상으로 풀어쓰려고 노력하다 보니 학술적 비약도 있습니다.

현대 네트워크 기술의 데이터 처리 속도는 굉장히 빠릅니다.

환경에 따라 성능 차이가 큰 무선 네트워크도 이제는 유선과 동등한 수준의 속도를 추구하고 있습니다. 하지만 AI 기술은 아직 네트워크만큼 빠르게 동작하지 않기 때문에 네트워킹 과정에 AI를 더하여 성능 향상을 꾀하는 것은 현실적으로 아직 먼 이야기입니다. 더군다나 모바일 네트워킹에서는 제한된 배터리로 동작하는 모바일 디바이스와의 상호작용이 주가 되기에 고전력·고성능 연산이 필요한 현대 AI 기술과의 결합은 아직 요원합니다.

그렇지만 무선 통신 과정에서 AI로 해결할 수 있는 것이 무엇인지는 명확히 알 수 있었고, 학자들은 그 문제에 대해 연구하기 시작했습니다. 그리고 그 결실로 오늘날에는 기존 무선 통신 기술과 비슷하거나 더 높은 성능을 보인 기계 학습 기반 논문이 상당수 나오고 있습니다. 물론 아직 상용화까지는 많이 남았지만요. 또, AI를 위해 데이터를 모으다 보면 고성능 무선 통신을 위해 개발했지만 새로운 방향으로의 기술 활용을 발견하게 되는 경우도 생깁니다. 이번 테크리뷰 세미나에서는 이와 관련해 어떤 일들이 벌어지고 있는지 살펴보았는데, 이 글에서는 그 중 CSI와 그 활용을 중심으로 일부를 싣고자 합니다.

참고 : 요즘 시대 무선 통신 기술의 지향점

다소 동떨어진 내용이라 접어놓습니다.

무선 통신 기술은 크게 두 가지 분야의 기술의 결합인데, 각각 물리(PHY) 계층과 MAC 계층이라고 합니다. 물리 계층은 실제 1010101... 데이터를 어떻게 전기 신호로 변환하고 송·수신할지에 관한 기술, MAC 계층은 신호 전달의 매질을 여러 장치가 공유할 때 어떻게 서로 순서를 정해서 겹치지 않게 통신할지에 관한 기술입니다. 물리 계층 기술이 발달하면 더 많은 데이터를 빠르게 주고받을 수 있게 되고, 그에 맞추어 MAC 계층 기술이 효율적인 프로토콜을 제시하게 되는 것이죠. 이러한 발전의 현황과 지향점은 ITU-R^[각주:1]에서 공표하는 IMT^[각주:2] 시나리오를 보면 알 수 있습니다. 가장 최근에 발표된 것은 IMT-2020인데, 여기서는 '이 정도는 되어야 5G 기술이라 부를 수 있다'는 최소 요구 시나리오 세가지를 명세하고 있습니다. 먼저 eMBB^[각주:3] 시나리오에서는 안정적인 상황에서 20Gb/s의 통신 속도를 요구하고, URLLC^[각주:4] 시나리오에서는 일반적인 상황에서 통신 지연 1ms 이하와 기지국 전환으로 인한 지연 0ms 이하를 요구합니다. 또 mMTC^[각주:5] 시나리오에서는 제곱킬로미터당 백만 개의 디바이스가 있는 초고밀도 환경에 대응하기를 요구하고 있습니다. 이 세가지 시나리오를 모두 성공적으로 완수할 수 있어야 기술적으로 진정한 '5G'가 되는 것이죠.

ITU 로고

신호 전송의 원리와 채널

신호의 전달은 미리 정해둔 주파수 대역에서 이루어집니다. 이 주파수 대역은 반송파(Carrier Frequency)라고 하는데, 현재는 그 대역을 서로 간섭이 없는 간격으로 더 잘게 쪼갠 부반송파(Subcarrier Frequency)에서 각기 다른 정보를 전달하는 방식으로 더 많은 정보를 전달하는 OFDM 기법을 이용합니다.

OFDM(Orthogonal Frequency Division Multiplexing) 개념도. 각 부반송파에서 하나의 QAM 신호를 충분히 해석할 수 있는 시간동안 전송하는 높은 주파수 효율의 기법이다.

즉, OFDM에서는 각 부반송파마다 다른 비트열(1010101...)을 적당히 신호로 나타내서 동시에 전송하는 것이죠. 여기서 '적당히 신호로 나타내는' 방법은 QAM을 주로 사용합니다. 신호 좌표 상에 점을 찍고, 미리 각 점이 의미하는 데이터를 00, 01, 10, 11과 같이 정해두는 방식입니다. 점을 더 잘게 찍을수록 더 많은 비트를 한번에 전송해서 더욱 전송 속도를 높일 수 있습니다. 하지만 여기서 우리는 '채널'을 고려해야 합니다.

QAM(Quadrature Amplitude Modulation) 신호 종류. 위 신호는 모두 같은 시간동안 전송되므로, 오른쪽으로 갈수록 식별은 어렵지만 더 많은 양을 전송할 수 있다.

유선과 다르게 무선 신호는 선을 따라 전송되는 것이 아닙니다. 현재 대부분의 안테나는 '무지향성'이라 해서, 특정 방향을 목적으로 하는 것이 아닌 방사형으로 신호를 전파합니다. 그러다보니 신호를 받는 쪽에서 그걸 들을 때는 이리저리 반사되고 각종 벽이나 기물을 투과하며 중첩되고 왜곡된 신호가 들리게 됩니다. 이러한 신호 전달 환경을 우리는 "채널(Channel)"이라 부릅니다.

채널(Channel) 개념도. 신호가 걸어가는 사람이라면, 채널은 인도라고 볼 수 있다.

이러한 채널의 상태를 숫자로 나타낸 것을 '채널 상태 정보(Channel State Information)', CSI라고 합니다. CSI가 포함하는 정보는 두 가지 <진폭 감쇠> 정도와 <위상 이동> 정도입니다. 아까 신호 좌표 상에 점을 찍어서 정보를 나타낸다고 했는데, 여기서 보낸 신호와 받은 신호 간의 차이를 아래 그림처럼 극좌표계로 해석했을 때 각도의 변화가 위상 이동 정도, 반경의 변화가 진폭 감쇠 정도이고, 보통 복소수를 사용하여 수치화합니다.

채널은 주파수마다 달라지므로, CSI도 주파수마다 달라지게 됩니다. 만약 채널을 정확하게 안다면 어떻게 원본 신호가 변형되어 여기까지 왔는지 아는 것과 마찬가지이므로, 왜곡된 신호를 원본 신호로 복원할 수 있습니다. 채널 측정 방법은 일반적으로 미리 약속한 신호를 송신하고 수신 측에서 원래 찍혀야 할 점 위치에서 얼마나 벗어나는지를 측정하는 방식으로 이루어집니다. 여러분이 잘 알고 있는 Wi-Fi, 5G도 이러한 방식으로 채널을 추정하고 있습니다.

신호를 해석하는 AI : 심층 신경망을 활용한 채널 추정

한 주파수 안에서 우리는 데이터도 보내야 하고, 정확한 데이터 왜곡 복구를 위해 채널 측정도 해야 합니다. 항상 채널 측정만 할 수 없고, 항상 데이터 교환만 할 수도 없습니다. 그러다보니 일정 기간동안 채널을 측정하지 않을 때가 생기는데, 이 때 알고 있는 채널 상태와 실제 채널 상태가 달라 정확한 원본 신호 복구가 이루어지지 않습니다. 여기서는 AI 기술 중 하나인 초해상화(Super-Resolution)를 사용해볼 수 있습니다. 초해상화를 간단히 말하자면 CNN 학습을 통해 저해상도 이미지를 고해상도 이미지로 변환하는 기법입니다. 기존 CSI의 측정은 띄엄띄엄 이루어지므로 저해상도라 할 수 있는데, 이를 CNN 변환을 통해 고해상도로 측정된 CSI로 변환하여 더 정확한 채널 추정을 해볼 수 있습니다.

The Pipeline for DL-based Channel Estimation

이렇게 비전 처리 계열 기술을 통해 고해상도로 복원한 CSI를 기반으로 더욱 정확하게 원본 신호를 복구하고, 그것을 바탕으로 데이터를 해석하면 정보 전달 오류 또한 줄어들게 됩니다. 레퍼런스 논문^[각주:6]의 시뮬레이션에서는 48개 주파수에서 알고 있는 신호를 쏘고, 72개의 주파수에 대해 채널 추정 오류를 측정했는데, 그 결과는 아래와 같았습니다.

Channel Estimation MSE at SUI5 Channel Model

Ideal MMSE
모든 주파수의 채널 상태를 알 때
Estimated MMSE
일반적인 채널 추정 기법 사용
Ideal ALMMSE
모든 주파수의 채널 상태를 알 때, 연산량이 적은 또 다른 채널 추정 기법
Deep Low-SNR
안 좋은 채널을 복구하도록 학습한 SRCNN
Deep High-SNR나쁘지 않은 채널을 복구하도록 학습한 SRCNN

결국 컴퓨팅 파워를 조금 더 들여 인공 지능 연산을 수행하면 더욱 많은 정보를 빠르고 안정적으로 보낼 수 있게 됩니다.

신호를 눈처럼 사용하는 AI : CSI 기반의 동작 인식

이번에는 CSI의 조금 재미있는 활용에 대해 알아보겠습니다. 동작 인식이라고 하면 웨어러블 디바이스나 카메라를 이용한 것이 먼저 떠오르는데, CSI를 활용한 동작 인식이라니. 기존의 방식과 다르게 CSI 기반의 동작 인식은 개인 정보 문제, 보이는 곳이어야 한다거나 착용해야만 한다는 전제 조건, 따로 디바이스를 구매해야한다는 단점이 없습니다. CSI는 여러분 집에 있을 무선 공유기에서 이미 계산하고 있는 정보이기 때문이죠. CSI에는 신호의 전파 과정에서 일어나는 여러 왜곡이 나타나는데, 이 중에는 사람의 동작에 따른 왜곡도 포함되어 있습니다. 즉, 이를 심층 신경망을 통해 학습한다면 사람의 동작을 분류할 수 있는 것이죠. 연구 단계에서 이 기술을 사용한 사례는 아래와 같이 다양합니다.

CSI 기반 화재 감지 : Zhong, S., Huang, Y., Ruby, R., Wang, L., Qiu, Y. X., & Wu, K. (2017, May). Wi-fire: Device-free fire detection using WiFi networks. In 2017 IEEE International Conference on Communications (ICC) (pp. 1-6). IEEE.
CSI 기반 실내 측위 : Wang, X., Gao, L., Mao, S., & Pandey, S. (2016). CSI-based fingerprinting for indoor localization: A deep learning approach. IEEE Transactions on Vehicular Technology, 66(1), 763-776.
CSI 기반 호흡 감지 : Wang, X., Yang, C., & Mao, S. (2020). On CSI-based vital sign monitoring using commodity WiFi. ACM Transactions on Computing for Healthcare, 1(3), 1-27.
CSI 기반 수화 인식 : Ma, Y., Zhou, G., Wang, S., Zhao, H., & Jung, W. (2018). Signfi: Sign language recognition using wifi. Proceedings of the ACM on Interactive, Mobile, Wearable and Ubiquitous Technologies, 2(1), 1-21.

현재는 상용 솔루션을 완성하기 위해 많은 사람들이 연구 중에 있는데, 앞으로 CSI 기반의 동작 인식 기술이 나아갈 방향을 소개하자면 이렇습니다. 신호가 송신 안테나에서 방사형으로 퍼지면 수신 안테나에서는 여러 경로를 통해 도달한 신호가 겹쳐져서 수신되는데, 이를 경로마다 각각 분리할 수 있다면 각 경로에 있는 사람들의 동작을 각각 인식할 수 있겠죠.

또, 현재 개발 중인 전이중(Full-Duplex) 통신 기술을 활용해 볼 수 있습니다. 현재는 반이중(Half-Duplex) 통신을 사용해 LTE, 5G, Wi-Fi, Blue-tooth 등 통신이 이루어집니다. 반이중 통신은 한 채널에서 양방향(Duplex) 통신을 하지만 한번에 보내거나 받는 것 둘 중 하나만 할 수 있는 것을 의미하는데^[각주:7], 이 때문에 현재 CSI를 측정하기 위해서는 신호를 보내는 측과 받는 측이 별개로 필요합니다. 전이중 통신을 위해서는 자신의 송신 안테나에서 보내지고 있는 신호가 바로 수신 안테나로 흘러들어오는 것을 방지하는 노이즈 캔슬링과 같은 기술(SIC^[각주:8])이 필요한데, 이는 아직 활발히 개발되고 있으며 아직 상용 제품에 적용되지 않았습니다. 만일 전이중 통신을 기술이 사용 가능해지면 공유기 하나만 설치하여 자신의 신호가 반사되어 돌아오는 것을 측정하고, 그것에서 CSI를 계산함으로써 혼자서도 동작 인식을 할 수 있게 되겠죠.

이렇게 CSI 기반의 활용을 통해 통신 뿐 아니라 마치 카메라처럼 작동하는 동작 인식 분야로까지의 확장이 가능하다는 것을 알아보았습니다.

마치며

이 글에서는 무선 통신 분야의 일부분인 CSI와 그 연관 기술에 대해 알아보았습니다. CSI 기반 기술은 무선 네트워크 자체의 성능을 높일 뿐 아니라 독거 노인의 낙상 여부 감지, 움직임 감지를 기반으로 한 방범 기능 등 다양한 분야로의 적용이 가능하다는 점에서 굉장히 흥미로운 기술입니다. CSI 기술과 그 발전상을 바라보면 마치 비전 기술을 따라가고 있는 것처럼, 마치 저해상도 CCTV를 효율적으로 이용하는 기술을 개발하는 것처럼 느껴집니다. 여러분도 느껴지시나요?

무선 통신 분야는 사전 지식이 많이 필요한 분야입니다. 유선 컴퓨터 네트워크 지식을 모두 알고있다는 전제 하에 많은 이론이 전개되기에 컴퓨터 네트워킹도 충분히 알고있어야 하며, 정보 전달에 있어서 '무선'이라는 불안정 요소가 크기 때문에 전자기학적 지식도 알아야 합니다. 분야가 깊다는 것은 다른 의미로는 '쉽게 따라잡히지 않는다'고도 할 수 있습니다. 만일 여러분이 무선 네트워크의 세계에 빠져 연구를 한다거나 기술 창업을 하게 된다면 분명 그 누구도 쉽게 카피할 수 없을 것입니다.

End of Document

ITU-R : International Telecommunication Union Radiocommunication Sector [본문으로]
IMT : International Mobile Telecom [본문으로]
eMBB : enhanced Mobile Broadband [본문으로]
URLLC : Ultra-Reliable & Low-Latency Communications [본문으로]
mMTC : massive Machine Type Communications [본문으로]
M. Soltani, V. Pourahmadi, A. Mirzaei and H. Sheikhzadeh, "Deep Learning-Based Channel Estimation," in IEEE Communications Letters, vol. 23, no. 4, pp. 652-655, April 2019, doi: 10.1109/LCOMM.2019.2898944. [본문으로]
휴대폰 상단바 아이콘에서는 업로드/다운로드 화살표가 동시에 뜨는 표현이 있는데, 셀룰러 통신의 경우 이론적으로 업로드/다운로드가 다른 채널을 사용하기 때문에 반이중 통신이더라도 동시에 업로드/다운로드가 이루어질 수 있습니다. [본문으로]
Self-Interference Cancellation [본문으로]

md-Track

실토 — Mon, 5 Jul 2021 21:37:27 +0900

Leveraging Multi-Dimensionality in Passive Indoor Wi-Fi Tracking

2020년 9월 쯤에 랩 선배 추천으로 읽은 논문인데, 일정에 쫓겨 정리를 하다 말았음에도 그냥 지우자니 아까워서 부분이나마 블로그에 올려 본다.

원문 : Xie, Yaxiong, Jie, Xiong, Mo, Li, and Kyle, Jamieson. "MD-Track: Leveraging Multi-Dimensionality for Passive Indoor Wi-Fi Tracking." In The 25th Annual International Conference on Mobile Computing and Networking. Association for Computing Machinery, 2019.

이 논문에서는 뭘 하는가?

광대역폭이나 대형 안테나 배열이 없어도 다차원 시그널을 잘 분해하는 시스템 "mD-Track"을 구현한다.

SpotFi와 비교했을 때 약 3.5배의 성능 차이를 보였다고 한다.

무선 채널 모델

여기서 중요한 건 신호 전파에서 각 Multipath 성분의 파라미터를 얼마나 정확히 얻어내느냐가 된다.

경로 성분의 파라미터

파라미터의 종류는 크게 4가지가 있다.

ToF ($\mathbf{\tau}$). 이것과 Tx-Rx 사이의 길이를 알면 해당 신호의 전파 경로의 범위를 타원형으로 한정지을 수 있다. 이 논문에 따르면 ToF의 해상도는 채널 대역폭에 비례한다.
AoA ($\mathbf{\phi}$), AoD ($\mathbf{\varphi}$). 얘네들은 Tx/Rx의 안테나가 많을 수록 해상도가 높아진다.
Doppler Shift ($\mathbf{\gamma}$). Tx, Rx 혹은 전파가 반사된 물체 그 어느 하나라도 상대적으로 움직임이 있다면 도플러 효과에 의한 주파수 변화가 발생한다. 이 파라미터는 관찰 간격이 클수록 더욱 정밀한 값을 얻을 수 있다고 한다.
Complex attenuation ($\mathbf{\alpha}$).

경로 전파 모델

Tx 안테나 $N$개, Rx 안테나 $M$개가 각자 $d$의 간격으로 배치되어 있다고 하자.

안테나 별 발신 신호 : $U(t)=[u_1(t), u_2(t), \cdots, u_N(t)]^T$ [^0]

[^0]: 논문에서 Transpose는 되어있지 않지만 아래 식과 아귀가 맞기 위해서 $U$는 Column Vector여야 한다.

수신단에 도달하는 신호 : $s(t;v)=\alpha e^{j2\pi\gamma t}c(\phi)g(\varphi)^TU(t-\tau),\quad v=[\phi, \varphi, \tau, \gamma, \alpha]^T$
- $g(\varphi)$ : $N$-element transmit array steering vector. $N$개의 안테나에서 나오는 신호 사이의 Phase 관계.
- $c(\phi)$ : $M$-element receive array steering vector. $M$개의 안테나에서 수신한 신호 사이의 Phase 관계.

Example: steering vector of receive antenna array

안테나 별 수신 신호 : $y(t)=s(t)_{M\times 1}+W(t)_{M\times 1}$
- $W(t)=[w_1(t), w_2(t), \cdots, w_M(t)]^T$ : $M$차원 가우시안 노이즈

파라미터 추정하기

경로 하나의 파라미터 추출

Tx-Rx 사이에 Singlepath만이 존재하고, Phase Offset이 없는 완벽한 트랜시버가 구비되어 있다고 하자. Multipath와 Phase Offset은 뒤에서 고려할 것이다.

파라미터를 구하기 위해서는 가장 먼저 Channel State를 구해야 한다. Tx 안테나 2개와 Rx 안테나 2개가 있을 때 서브캐리어 $k$의 채널은 다음과 같이 나타낼 수 있다[^a] [^b].

[^a]: 논문에서는 이 부분에서 서브캐리어 수를 $N$이라고 하는데, Tx 안테나 수와 헷갈릴 수 있으므로 이 글에서는 논문 Figure 7에 나온 대로 $F$라고 서술한다.
[^b]: 또한 논문에서 $H$와 $h$에 대해 Notation 자체가 틀린 부분도 있고 헷갈리게 되어 있는데, 이 글에서는 $H$를 아래 식과 같이, 그리고 $h$에 대해서는 $h_{ij,k}$로 통일하여 바로잡아 서술한다. $i$는 Tx 안테나 인덱스, $j$는 Rx 안테나 인덱스, $k$는 서브캐리어 인덱스다.

$$H_k=\left[\begin{matrix}h_{11,k} & h_{12,k} \ h_{21,k} & h_{22,k}\end{matrix}\right],\quad k=[1,2,\cdots,F]$$

지금부터 이 $h$들을 LTF의 특성과 수신한 LTF 구간의 신호 $\textbf{x}$를 이용해서 구할 것이다.

802.11n에서 MIMO를 사용하면 각 안테나를 구분하기 위한 목적으로 LTF를 나열할 때 Mapping Matrix $P_{HT-LTF}$를 곱하게 되는데[^1] [^2], 여기서는 Tx 안테나가 두 개이고 LTF가 2번 오므로, 아래처럼 좌상단 $2\times 2$를 잘라서 사용하게 된다[^3].

[^1]: 논문에서는 갑작스런 신호 레벨 증가를 막기 위해서라고 하는데, 딱히 이 말은 그다지 이해가 가지 않는다. Tx 안테나를 구분하여 이용하기 위한 목적이라고 보는게 훨씬 맞다고 생각한다.

[^2]: 논문에서는 $P_{HTLTF}$라고 되어 있고, 실제 옛날 표준에서 도 그렇게 칭했으나, 최신 표준에서는 $P_{HT-LTF}$로 표기가 변경되었다.

[^3]: $N_{TX}$, 그리고 2개의 LTF 필드가 존재하는 이유와 관련해서는 802.11-2016 19.3.13.1에 자세히 설명되어 있다.

$$P_{HT-LTF}=\left[\begin{matrix}1 & -1 & 1 & 1 \ 1 & 1 & -1 & 1 \ 1 & 1 & 1 & -1 \ -1 & 1 & 1 & 1\end{matrix}\right]\Rightarrow\left[\begin{matrix}1 & -1 \ 1 & 1\end{matrix}\right]$$

각 안테나 별 Tx 안테나에서 전송되는 LTF와 $P_{HT-LTF}$의 곱 $P_{HT-LTF}\times \text{LTF}$의 IFFT를 시간축 그림으로 나타내면 아래와 같다. $P\times \text{LTF}$는 주파수 영역임을 기억하자.

802.11n Preamble

위 그림대로 두 신호를 두 안테나가 동시에 발신했을 때, 수신 측에서 받는 신호(FFT 이후)는 $P_{HT-LTF}\times \textbf{LTF}(k)$에 채널 상태를 곱해서 아래처럼 나타낼 수 있다. 아래 중간 식에서의 $h$의 배열은 $H_k^T$와 같다. $k$는 서브캐리어 인덱스이다.

$$\begin{matrix}\left[\begin{matrix} \textbf{x}_{1,k,t_1} & \textbf{x}_{1,k,t_2} \\ \textbf{x}_{2,k,t_1} & \textbf{x}_{2,k,t_2} \end{matrix}\right]&=&\left[\begin{matrix} h_{11,k} & h_{21,k} \\ h_{12,k} & h_{22,k} \end{matrix}\right]\cdot\left[\begin{matrix} 1 & -1 \\ 1 & 1 \end{matrix}\right]\cdot\left[\begin{matrix}\text{LTF}(k)&\text{LTF}(k)\\\text{LTF}(k)&\text{LTF}(k)\end{matrix}\right]\\&=&\left[\begin{matrix} h_{11,k} +h_{21,k} & -h_{11,k}+h_{21,k} \\ h_{12,k}+h_{22,k} & -h_{12,k}+h_{22,k} \end{matrix}\right]\cdot\textbf{LTF}(k)\end{matrix}$$

사실 위처럼 $H_k$와 $P_{HT-LTF}$를 곱하기 전에 양변에 $P^T_{HT-LTF}$를 곱해서 LTF와 $H_k^T$만을 남길 수 있다.

$$\left[\begin{matrix} \textbf{x}_{1,k,t_1} & \textbf{x}_{1,k,t_2} \\ \textbf{x}_{2,k,t_1} & \textbf{x}_{2,k,t_2} \end{matrix}\right]\cdot\left[\begin{matrix} 1 & 1 \\ -1 & 1 \end{matrix}\right]=2\cdot\left[\begin{matrix} h_{11,k} & h_{21,k} \\ h_{12,k} & h_{22,k} \end{matrix}\right]\cdot\textbf{LTF}(k)$$

이렇게 받아서 FFT한 신호에 $P^T_{HT-LTF}$와 $2\textbf{LTF}(k)$의 역행렬을 곱해서 서브캐리어 $k$에서의 채널 상태 ${h_{11}, h_{12}, h_{21}, h_{22}}$를 추정할 수 있다.

참고로 $H$는 행이 Rx 안테나 인덱스 열이 Tx 안테나 인덱스이고, $\textbf{X}$는 행이 Rx 안테나 인덱스고 열이 시간이다.

이렇게 추정한 채널 상태는 이제 본격적으로 파라미터 추정에 이용하게 된다. 앞으로 설명할 이 논문의 파라미터 추정 과정은 아래와 같다.

mD-Track's four-dimensional estimator that estimates parameters AoA, AoD, Doppler, and ToF of a wireless signal as it propagates along a single path

AoA와 AoD를 주파수 영역에서 구하고, 도플러 효과, ToF와 Amplitude Attenuation은 시간 영역에서 구하게 된다.

AoA & AoD 구하기

Angle of Arrival

하나의 Tx 안테나에서 발신된 Singlepath 신호가 여러 개의 Rx 안테나에 도달할 때, Rx 안테나가 규칙적으로 배열되어 있다면 그에 따라 전파 거리가 일정하게 달라질 것이다. 그리고 이는 각 Rx 안테나에서 얻은 채널 상태에 반영되어, 전파 거리 차이에 따른 규칙적인 Phase Offset이 나타날 것이다.

예시를 하나 들어보자. 아래 그림은 Rx 안테나 3개에서 얻은 특정 서브캐리어에서의 채널 상태 복소수를 복소좌표계에 표시한 것인데, 옥색 R1과 회색 R2/R3가 바로 규칙적인 Phase Offset이 나타난 채널 상태다. Amplitude 값은 그냥 저렇다고 가정하자.

Steering Vector의 정의에 의해 이 규칙적인 Phase Offset은 각 Rx 안테나에서 얻은 채널 상태에 적당한 Steering Vector를 곱해서 없앨 수 있고, Phase Offset이 사라진 채널 상태는 모두 Phase값이 같아져 그들의 합의 Power는 최대가 될 것이다. 이 경우가 바로 위 그림에서 옥색 점 세개이다. 이를 수식으로 나타내면 아래와 같다.

$$\text{Appropriate steering vector}=\underset{\text{steering vector}}{\operatorname{arg max}}\left\Vert \left[\begin{matrix}h_{R1} & h_{R2} & h_{R3}\end{matrix}\right] \cdot \text{steering vector}\right\Vert^2$$

Steering Vector는 $\phi$의 함수이므로, 위 식의 결과값을 만들어내는 $\phi$가 바로 AoA 추정값 $\phi^*$가 된다.

돌아와서 이 논문에서 제시한 Tx/Rx 안테나가 각각 2개씩인 구조에 적용해보자. 채널 상태와 Rx steering vector $c(\phi)$를 곱한 값을 $h'$라 하면, $\phi^*$는 아래와 같이 적을 수 있다.

$$\left[\begin{matrix}h'_{1,k}(\phi)\\h'_{2,k}(\phi)\end{matrix}\right]=\left[\begin{matrix}h_{11,k} & h_{12,k} \\ h_{21,k} & h_{22,k}\end{matrix}\right]c(\phi)$$

$$\phi^*=\underset{\phi}{\operatorname{arg max}}\sum^2_{i=1}\sum^F_{k=1}\left\Vert h'_{i,k}(\phi)\right\Vert^2$$

모든 Tx-Rx 안테나 쌍에서 $\phi$는 거의 같으므로, 모든 안테나에 대해 Steering Vector를 곱하고 합친 Power가 가장 큰 $\phi$을 찾아내는 것으로 $\phi^*$를 얻은 것이다. $i$는 Tx 안테나 인덱스, $k$는 서브캐리어 인덱스이다.

Angle of Departure

AoA에서 했던 것과 같은 원리로, Tx 안테나에 대해 가장 적당한 Steering Vector를 구하여 AoD 추정치 $\varphi^*$를 얻을 수 있다.

$$\varphi^*=\underset{\varphi}{\operatorname{arg max}}\sum^F_{k=1}\left\Vert h''_{k}(\varphi;\phi^*)\right\Vert^2,\quad h''_k=g_(\varphi)^H\left[\begin{matrix}h'_{1,k}(\phi^*) \\h'_{2,k}(\phi^*)\end{matrix}\right]$$

$g(\varphi)$를 Transpose가 아닌 Hermitian으로 적은 건 단순히 $g$를 어떻게 정의하느냐에 따라 달린 것으로, 뭐가 되든 결국 특정한 AoD 값을 추정할 수 있을 것이다.

Doppler Shift & ToF 구하기

이제 AoA와 AoD를 구했으니 AoA, AoD에 의한 Phase Shift 효과가 제거된 시간 영역 수신 시그널을 재건할 수 있다.

$$y''(t;\phi^*,\varphi^*)=\mathcal{F}^{-1}\{H''(\varphi^*,\phi^*)\odot \text{LTF}\},\quad H''=[\begin{matrix}h''_1&h''_2&\cdots&h''_F\end{matrix}]$$

$\odot$은 element-wise multiplication이고, 여기서 $\text{LTF}$는 주파수 영역에 있다. 이를 활용하여 앞에서 나왔던 수신단 신호 $s(t)_{M\times 1}$에서 AoA, AoD 효과를 제거한 신호 $s'(t)_{1\times 1}$를 적어보면 아래와 같다.

$$s'(t)_{1\times 1}=\alpha e^{j2\pi\gamma t}y''(t;\phi^*,\varphi^*)$$

이제 위에서 했던 방법과 비슷하게 Correlation Peak를 찾을 것이다. 먼저 ToF $\tau$부터 찾아보자[^4].

[^4]: 이 글에서는 $\tau$와 $\gamma$를 순차적으로 찾지만 논문에서는 Doppler Shift와 ToF를 동시에 찾고, 뒤에서 또 $z$라는 Unified Estimator를 소개한다. 왜 내가 이악물고 $z$를 무시하면서 Doppler Shift와 ToF 추정이 분리된 논문 정리를 했는지는 <알고리즘 최적화> 섹션에서 다뤘다.

Time of Flight

위에서 Tx 안테나 별 송신 신호를 $U(t)_{N\times 1}$라고 표시했다. 이번에는 각 안테나로 분배되기 이전 송신 신호를 $\underset{\leftarrow}{U}(t)_{1\times 1}$라고 하자. 이를 활용해서 아래와 같이 ToF를 찾을 수 있다.

$$\tau^*=\underset{\tau}{\operatorname{arg max}}\int_Ty''(t;\phi^*,\varphi^*)\underset{\leftarrow}{U}(t-\tau)dt$$

여기서 $T$는 $y''$의 신호 길이, $\tau^*$는 $\tau$의 추정치이다.

Doppler Shift

다시 한 번 Correlation을 이용하여 Doppler Shift 파라미터를 구할 수 있다.

$$\gamma^*=\underset{\gamma}{\operatorname{arg max}}\int_Te^{-j2\pi\gamma t}y''(t;\phi^*,\varphi^*)\underset{\leftarrow}{U}(t-\tau^*)dt$$

Attenuation 구하기

위에서 구한 네 가지 파라미터를 가지고 아래와 같이 Amplitude Attenuation 정도를 구할 수 있다.

$$\alpha^*=\frac{1}{M\cdot T\cdot P}\int_Te^{-j2\pi\gamma^* t}y''(t;\phi^*,\varphi^*)\underset{\leftarrow}{U}(t-\tau^*)dt$$

$M$은 Rx 안테나 수, $T$는 $y''$ 신호의 길이, $P$는 송신 전력이다.

여러 경로의 파라미터 추출

이때까지 Singlepath에 대한 이야기를 했다. 여러 경로를 다루는 건 Self Interference Cancellation을 하듯이 중첩되어 있는 $s(t)$를 여러 $s(t)$로 분리하고, 각각의 $s(t)$에 대해 파라미터 벡터 $v=[\phi, \varphi, \tau, \gamma, \alpha]^T$를 뽑아내는 방식으로 진행된다.

총 하나의 수신 신호에 들어있는 수많은 Multipath 중 $L$개의 Multipath를 뽑아낸다고 가정하자. SIC 방식을 그대로 따르면서 백색 소음 레벨까지 내려가게 되면 더이상 Multipath를 뽑을 수 없게 될 것인데, $L$은 그때까지 뽑을 수 있는 Multipath의 수로 한정된다.

$$Y(t)=\sum^L_{l=1}s_l(t;v_l)+\hat{\mathbf{W}}(t)$$

$Y(t)$는 수신 신호, $\hat{\mathbf{W}}(t)$는 큼직한 덩어리를 다 뽑아내고 남은 백색 소음 + 뽑아낼 수 없었던 소음이 되어버린 시그널이다.

하지만 여기까지만 하면 여전히 $s_l(t)$가 서로 겹쳐 있어서 상당히 부정확하게 $s_l(t)$이 뽑힌다고 한다. 그래서 나온 것이 한번 더 신호를 뽑아내는 것이다. 즉, 모든 $s_l(t)$에 대해 아래의 계산을 진행한다.

$$y'_l(t)=s_l(t;v_l)+\hat{\mathbf{W}}(t)\quad\Rightarrow\quad s'_l(t;v_l')$$

여기서 주의할 점은 $\hat{\mathbf{W}}$를 계속 업데이트하면서 진행하는 것이다. 예를 들어, $y'_1(t)$에서 $s'_1(t)$을 뽑아 내고, 나머지 신호를 $\hat{\mathbf{W}}$에 합산한다. 이후 그렇게 업데이트한 $\hat{\mathbf{W}}$를 사용해서 $y'_2(t)$를 구성하고, 거기서 또 $s'_2(t)$를 뽑아 낸다. 이 과정은 추출된 $l$번 신호에 대해, 큰 변화가 없을 때까지 계속 반복한다. 즉, $s_l\rightarrow s'_l \rightarrow s''_l \rightarrow \cdots$ 이다. 여기서 '큰 변화'를 판단하는 기준은 유동적으로 조절할 수 있는데 저자들은 이를 각 파라미터 찾기의 간격인 $0.02\text{rad}$, $0.5ns$, $0.1\text{Hz}$로 설정했다고 한다^[Section 6.3에 나와 있다.]. 또한, 논문에 따르면 이 반복 알고리즘으로 파라미터 벡터를 찾으면 거의 항상 수렴하는 값이 나온다고 한다.

이 과정은 아래 그림에 잘 나타나 있다.

The framework of the iterative path parameter estimation algorithm ($L=2$)

알고리즘 최적화?

이 논문에서는 위에서 내가 적은 것과 다르게 아래의 Unified Estimator $z$를 제시하여 한번에 AoA, AoD, Doppler Shift, ToF를 추정한다.

$$z(\phi, \varphi,\tau,\gamma)=\int_Te^{-j2\pi\gamma^* t}\mathcal{F}^{-1}{g^H(\varphi)Hc(\phi)\odot \text{LTF}}\underset{\leftarrow}{U}(t-\tau)dt$$

$$(\phi, \varphi, \tau, \gamma)_{est}=\underset{v}{\operatorname{arg max}}|z(\phi,\varphi,\tau,\gamma)|$$

그리고 Channel Attenuation $\alpha$는 아래의 식으로 계산한다.

$$\alpha_{est}=\frac{1}{M\cdot T\cdot P}z((\phi,\varphi,\tau,\gamma)_{est})$$

하지만 파라미터 $\phi$, $\varphi$, $\tau$, $\gamma$의 경우의 수를 각각 $p_\phi$, $p_\varphi$, $p_\tau$, $p_\gamma$라고 하면 이렇게 합쳐진 Estimator $z$는 총 $p_\phi\cdot p_\varphi\cdot p_\tau\cdot p_\gamma$의 Input 공간에서 최적값을 찾게 된다.

저자들도 이게 오버헤드가 있다는 걸 알고 있으며, 네 개를 동시에 찾는 것보다는 찾지 못한 파라미터를 고정시키고 순차적으로 찾는 아래의 방법을 뒤에서 "Reducing computational complexity"라며 제시한다.

$$\phi^*=\underset{\phi}{\operatorname{arg max}}|z(\phi,\varphi_\text{fixed},\tau_\text{fixed},\gamma_\text{fixed})|$$

$$\varphi^*=\underset{\varphi}{\operatorname{arg max}}|z(\phi^*,\varphi,\tau_\text{fixed},\gamma_\text{fixed})|$$

$$\tau^*=\underset{\tau}{\operatorname{arg max}}|z(\phi^*,\varphi^*,\tau,\gamma_\text{fixed})|$$

$$\gamma^*=\underset{\gamma}{\operatorname{arg max}}|z(\phi^*,\varphi^*,\tau^*,\gamma)|$$

즉, Input 공간을 $p_\phi\cdot p_\varphi\cdot p_\tau\cdot p_\gamma$ 에서 $p_\phi+ p_\varphi+ p_\tau+ p_\gamma$로 줄이는 것이다.

고정하는 파라미터 값은 이전 Iteration에서 찾은 값을 활용한다고 한다. 제일 첫 번째 Iteration에서는 무슨 값으로 고정하는지 나와있지 않으며^[그저 가장 빠르게 수렴하는 지점을 조심스레 선택했다고 한다.], 논문 중간의 "이 알고리즘은 글로벌 맥시멈을 보장하지 않는다"는 설명이 이와 관련이 있어보인다.

여기서 내가 든 생각이 "그럴거면 그냥 처음부터 $\mathbf{z}$를 제시하지 않고 순차적으로 계산하면 되는 것 아닌가?" 이다.

위에서 내가 서술한대로, 그리고 논문 초반 AoA, AoD Estimator 설명에서 했던대로만 계산하면 굳이 $z$를 끝까지 계산할 필요 없이 $\phi$, $\varphi$값을 찾을 수 있어 한 번 추정하는 것에 대한 계산 양 자체도 줄어들 것이다.

아직 논문 저자들이 왜 굳이 $z$의 개념을 제시했는지 잘 모르겠다.

채널 측정 오차 바로잡기

와이파이 하드웨어에는 어쩔 수 없이 오차가 생기기 마련이다. 그리고 그 오차는 파라미터 및 Multipath 추정에 영향을 미친다.

이 논문에서는 각 파라미터에 오차를 주는 주된 원인을 아래 다섯 가지로 지정하고 있다.

Tx 체인의 Phase Offset → AoD 오차의 원인. 기계적 문제로 Tx의 모든 포트에서 동일한 Phase의 신호가 나오지는 않는데, 그 Offset을 말한다.
Rx 체인의 Phase Offset → AoA 오차의 원인. 기계적 문제로 Rx의 각 포트마다 같은 신호를 약간씩 다른 Phase로 받아들이는데, 그 Offset을 말한다.
Sampling Frequency Offset → ToF 오차의 원인. Sampling Timing이 계속해서 일정하게 밀리는 것이다.
Symbol Timing Offset → ToF 오차의 원인. 일정하게 증가하는 Frequency Offset 외에도 상수값으로 존재하는 Sampling Timing의 차이이다.
Carrier Frequency Offset → Doppler Shift 오차의 원인. Up/Down converting에서의 주파수 차이이다.

그리고 아래의 방법대로, Channel Estimation 이전에 Channel Information Correction을 진행한다.

Tx/Rx Phase Offsets 제거

Tx/Rx 포트의 Offset은 Antenna-specific, Chip-specific한 수치이다. 따라서 이 논문에서는 자신들이 실험하는 기기에서 Tx-Rx 안테나 포트를 유선으로 연결하여 Chip에서 발생하는 Phase Error를 측정, 제거했다. 안테나 간의 차이에 의한 Phase Offset은 제거하지 않은 듯하다.

SFO, STO 제거

A microbenchmark study of two paths

위와 같이 했다고 한다.

CFO 제거

Channel sampling model

위와 같이 했다고 한다.

구현 및 결과

구현

Experimental setup in a indoor meeting room

WARP v3 플랫폼과 일반 와이파이 라우터를 사용해서 채널 샘플링 장치를 구성했고, 워크스테이션 서버를 이용해서 컴퓨팅을 했다고 한다. 위 사진은 여러 테스트 환경 중 실내 회의실 환경의 구성이다.

성능

자세한 내용은 논문을 직접 확인하자.

해상력. 기존 기술 MUSIC, SpotFi와 비교했을 때 훨씬 정확했으며, 여기다가 AoD, ToF, Doppler를 추가한 경우 더욱 높은 해상력을 보여주었다고 한다.
처리 시간. $t_s$는 25ms로 설정했으며, 약 130ms의 컴퓨팅 시간을 보여주었다고 한다. 느려보이지만 SpotFi와 비교해서는 최소 14배 빠른 시간이라고 한다.

Frequency Offset Estimation and Correction

실토 — Wed, 26 Aug 2020 05:08:56 +0900

in the IEEE 802.11a WLAN

원문 : E. Sourour, H. El-Ghoroury and D. McNeill, "Frequency offset estimation and correction in the IEEE 802.11a WLAN," IEEE 60th Vehicular Technology Conference, 2004. VTC2004-Fall. 2004, Los Angeles, CA, 2004, pp. 4923-4927 Vol. 7, doi: 10.1109/VETECF.2004.1405033.

이 글은 단순히 읽은 논문을 정리한 것이다.

이 논문에서는 뭘 하는가?

파일럿 신호인 STF와 LTF를 이용한 Coarse & Fine Frequency Offset Tracking을 진행한다. 검증은 AWGN까지 구현된 완전한 802.11a WLAN 시뮬레이터로 진행한다.

IEEE 802.11a PHY 레이어

아래 내용을 읽으면서 OFDM을 다시 떠올리는 데는 Keysight의 Concepts of Orthogonal Frequency Division Multiplexing (OFDM) and 802.11 WLAN 문서와 WLANpedia의 OFDM in WLAN 문서를 참고했다.

IEEE 802.11a Frame Structure

$8\mu s$의 STF와 LTF, $4 \mu s$의 OFDM Symbol이 있다.

Short Training Sequence

총 10번의 동일한 파트($t_0 ~ t_9$, 각 $0.8\mu s$)로 나뉘며, 각 파트마다 16번 샘플링하도록 구성되어 있다.
시간 동기화, AGC 설정, 안테나 선택, Coarse FO Estimation에 쓰인다.
(가정) 위 쓰임 중 나머지는 모두 성공했고, 마지막 Coarse FO Estimation에는 $t_5 - t_9$만을 사용한다고 하자.

Long Training Sequence

하나의 Guard Interval과 두 개의 동일한 Training 파트($T_0, T_1$)로 나뉘며, 각 파트마다 64번 샘플링하도록 되어 있다.
Guard Interval은 $1.6 \mu s$, 두 Training Field는 $3.2\mu s$이다.
Guard Interval은 $T_1$의 마지막 32 샘플을 이용한 Cyclic Prefix이다.
Channel 추정과 Fine FO Estimation에 쓰인다.

OFDM Symbols

$0.8\mu s$의 Guard Interval과 $3.2\mu s$의 Data Symbol로 구성되어 있다.
첫 OFDM Symbol은 SIGNAL 필드, 이후는 DATA 필드이다.

시뮬레이션 모델

시뮬레이터로 모든 검증을 진행했다고 하는데, 어떻게 환경과 오류를 모델링했는가?

채널 모델

논문 오류로 채널 모델이 정확히 표기되어 있지 않으나, 여기서 중요한 것은 채널 모델이 아니라 FO 부분이므로 대충 아래와 같이 정리하고 넘어간다.

레일리 실내 모델이고, 한 프레임을 받는 동안 채널 상태는 일정하다고 가정하자.
전파 지연($D_{rms}$)은 $20 - 200 ns$ 이며 최대 다중 경로 수($L$)는 Sampling Period($T_s$)에 대해 $1+ \left\lfloor {10D_{rms}/T_s} \right\rfloor$ 이다.

Frequency Offset 모델

한 Rx에서 FO는 하나의 Oscillator에 의해 결정되므로, Carrier Frequency와 Baseband에서 FO는 같다고 가정한다.

Carrier Frequency Offset (CFO) 모델

어긋난 Carrier Frequency에 의한 CFO Phase Shift Degree $\alpha$는 아래와 같이 나타낼 수 있다.

$$\alpha=2\pi\epsilon f_c T_s$$

$\epsilon$이 양수이면 샘플 당 Phase Shift $\alpha$ 역시 양수(반시계 방향)일 것이다.

이는 한 프레임의 $n$번째 샘플 신호에 대해 $e^{jn\alpha}$를 곱하면 CFO를 모델링할 수 있다.

Sampling Frequency Offset (SFO) 모델

어긋난 Sampling duration은 아래와 같이 나타낼 수 있다.

$$T_s'=(1-\epsilon)T_s$$

$\epsilon$이 양수이면 샘플링 기간은 짧아지고, 기존 샘플링 시각보다 이른 $\tau_n=n\epsilon T_s$에 샘플링이 이루어지게 된다.

이는 아래 그림과 같이 표현할 수 있다.

Calculating Offset Samples From The Ideal Samples

위쪽 그래프에서 실선으로 표시된 $S'$가 이상적인 샘플링 간격이며, 점선으료 표시된 $S$는 어긋난 샘플링 간격이다.

이 샘플링 오류 SFO를 모델링하기 위해서 이 논문에서는 Sinc LPF에 딜레이를 주었으며, 식으로 표현하면 아래와 같다.

$$C_m = Sinc(\pi(t+\tau_n)/T_s)|_{t=mT_s}=Sinc(\pi(m+n\epsilon)),\quad -\infty<m<\infty$$

이는 위 그림의 아래쪽 그래프에도 그려져 있다.

결국, CFO와 SFO를 모두 고려한 샘플은 $S_n=\sum^\infty_{m=-\infty}{C_mS'_{n+m}}$ 으로 나타낼 수 있다.

이 논문에서는 시뮬레이션을 돌리므로, $m$을 $-50<m<50$으로 유한히 한정한다.

Frequency Offset 추정 및 교정

아까 STF를 가지고 Coarse FO Estimation, LTF로 Fine FO Estimation을 한다고 했다.

위에서 $\alpha$를 실제 CFO로 거론했는데, 이 CFO 추정치 $\hat{\alpha}$를 구하고 그를 통해 CFO와 SFO를 교정할 것이다.

STF, LTF를 이용한 CFO 추정 및 교정

Step 1. STF를 이용한 Coarse CFO Estimation

아까 10개의 STF 중 $t_5-t_9$ 를 이용한다고 했다. 이들은 총 80개의 샘플로 이루어졌으며, 각 샘플을 $S_m$이라고 하자 ($m=0,1,\cdots,79$).

그러면 $\hat{\alpha}=\frac{1}{16}\angle \left(\sum^{63}_{m=0}S_m^*S_{m+16}\right)$ 으로 $\hat{\alpha}$를 나타낼 수 있다. 여기서 $\angle$은 $\pm \pi$ 사이의 Phase 값을 말한다.

이렇게 이 단계에서 대략 유추한 $\hat{\alpha}$ 를 $\hat{\alpha}_{ST}$ 라 하고, 다음 Fine Estimation으로 넘어가자.

Step 2. LTF를 이용한 Fine CFO Estimation

여기서는 두 개의 LTF를 모두 이용하며, 각 샘플을 $S_m;(m=0,1,\cdots,127)$ 이라고 하면 아래의 세 단계를 거쳐서 처리할 수 있다.

Coarse Correction. 각 샘플을 위의 $\hat{\alpha}{ST}$를 이용하여 보상한다. → $S_m=S_me^{-jm\hat{\alpha}_{ST}}$
Fine Estimation. 위와 동일한 방법으로, 하지만 조금 더 많은 샘플을 가지고 더 정확하게 FO Estimation을 수행한다. → $\hat{\alpha}_{LT}=\frac{1}{64}\angle\left(\sum^{63}_{m=0}S_m^*S_{m+64}\right)$
Fine Correction. 1번과 동일한 방법으로 각 샘플을 보상한다. → $S_m=S_me^{-jm\hat{\alpha}_{LT}}$

STF, LTF 이후부터는 $\hat{\alpha}=\hat{\alpha}_{ST}+\hat{\alpha}_{LT}$를 이용하여 CFO를 교정할 수 있다.

또한 위에서 언급한 $\alpha=2\pi\epsilon f_cT_s$ 관계를 이용하여 첫 번째 FO 값 $\hat\epsilon_0$을 구할 수도 있다.

Pilot Subcarrier를 이용한 FO 추정 및 교정

STF와 LTF를 이용하여 CFO를 교정하고 나서도 부정확성에 의해 Residual CFO가 나타나고, SFO도 아직 남아있다. 이로 인해 FFT 결과값에서 위상 오차가 나타나는데, 이는 Pilot Subcarrier로부터 얻은 정보를 통해 교정해볼 수 있다.

이 논문에 따르면 OFDM 심볼과 서브캐리어에 따른 (이 단계에 진입했을 때) 남아 있는 위상 차이 $\phi_{l,k}$는 아래와 같다.

$$\phi_{l,k}=2\pi l\left(\epsilon_rT_uf_c-\frac{N+N_g}{N}\epsilon k\right)$$

여기서 $l$은 OFDM 심볼 인덱스, $k$는 서브캐리어 번호 (-26 ~ 26), $N$은 FFT Size (64), $N_g$는 GI의 샘플 수 (16), $T_u$는 OFDM Symbol 길이 ($4 \mu s$), $\epsilon_r$은 $\epsilon - \hat{\epsilon}_0$, 즉 Fine CFO Correction 이후 남아있는 CFO이다.

위 식을 살펴보면 $\epsilon_rT_uf_c$ 부분은 서브캐리어 인덱스와 관계 없이 공통적으로 적용되는 Residual CFO이고, $\frac{N+N_g}{N}\epsilon k$ 부분은 SFO임을 알 수 있다.

이 논문에서는 이 두 FO를 교정하기 위해 총 세 단계를 도입했다. 이 세 단계에서 사용하는 기호 표기는 아래와 같다.

[$\mathbf{H}$] 서브캐리어 $k$의 채널 이득을 $H_k$라 하자. $k$가 -26부터 26까지 존재하므로, $H_{-26},\cdots,H_{26}$이 존재할 것이다.
[$\mathbf{Q}$] 802.11a 기준으로 Pilot Subcarrier는 -21, -7, 7, 21이므로 이를 $Q$를 이용하여 $Q_{-2}=H_{-21}$, $Q_{-1}=H_{-7}$, $Q_{1}=H_{7}$, $Q_{2}=H_{21}$ 과 같이 나타낼 수 있다.
[$\mathbf{X}$] 수신 측에서는 받은 신호에서 [GI Dropping > 64-FFT] 를 수행하고, 그 중 48개의 Payload와 4개의 Pilot Symbol을 건져 낼 것이다. 각 Subcarrier의 Symbol을 $X_k$라 하자. 여기서부터는 Frequency Domain이다.
[$\mathbf{P}$] Pilot Symbol은 Pseudo-random 값을 제거하고 채널 추정 및 시간 동기화에 쓸 수 있는데, 이를 $P$로 나타내면 $P_{l,-2}=X_{l,-21}$, $P_{l,-1}=X_{l,-7}$, $P_{l,1}=X_{l,7}$, $P_{l,2}=X_{l,21}$ 이 된다.

Step 1. SFO 교정

직전 Symbol에서 계산한 Sampling Frequency Offset 추정 값 $\hat{\epsilon}_{l-1}$과 위에서 나온 식 $\text{SFO}=2\pi l \frac{N+N_g}{N}\epsilon k$ 을 사용해서 간단히 보상해줄 수 있다. 자세한 내용은 위에서 언급한 논문을 보면 나온다.

$\hat\epsilon_{0}$은 $\hat{\alpha}=\hat{\alpha}_{ST}+\hat{\alpha}_{LT}$ 와 $\alpha=2\pi\epsilon f_c T_s$ 을 이용해서 구한 $\hat\epsilon_0$ 이다.

$$X_{l,k}=X_{l,k}\exp\left(2\pi l \frac{N+N_g}{N}\hat{\epsilon}_{l-1}k\right),\quad k=-26,\cdots,26$$

$X$에 대해서 해주는 것이므로, 당연히 Pilot Symbol $P$에 대해서도 교정을 해 주는 것이다.

Step 2. Pilot Subcarrier를 이용한 Residual CFO 교정

위에서 말한 Residual CFO 부분($2\pi\epsilon_rT_uf_c$)은 모든 서브캐리어에 대해 공통으로 적용되며 OFDM Symbol 인덱스에 따라 일정하게 증가한다. 이는 $P$와 $Q$를 활용하여 나타낼 수 있다.

$$\hat{\beta}_l=\angle\left({\sum_{i=-2,-1,1,2}P_{l,i}Q_i^*}\right)$$

이를 이용하여 다시 한 번 보상해주면 아래와 같다.

$$X_{l,k}=X_{l,k}e^{-\hat{\beta}_l},\quad k\neq -21,-7,7,21$$

여기서 Pilot Symbol을 고려하지 않는 이유는 그 다음번 $\hat\epsilon_l$을 구해야 하기 때문이다. SFO Correction만 적용한 Pilot Symbol을 FO 추정에 사용하는 것과 관련해서는 위에서 언급한 논문을 보면 나온다.

Step 3. Pilot Subcarrier를 이용한 정밀한 FO 추정

이제 다음 OFDM Symbol의 SFO 교정(위 Step 1)에 쓸 $\hat{\epsilon}_{l}$ 값을 추정해야 한다.

이 논문의 저자는 관찰을 바탕으로 실제 Frequency Offset $\epsilon$이 LTF 기반 교정 이후 구했던 초기 추정값 $\hat\epsilon_0$과 Residual CFO $\epsilon_r$의 합이라는 것을 알아냈다.

한 OFDM Symbol 이후 Residual CFO로 인해 증가하는 위상 회전 값 $2\pi \epsilon_r T_u f_c$은 아래와 같이 현/전 심볼의 Pilot Symbol을 이용해 추정할 수 있다.

$$\angle(W_l)=\angle\left(\sum_{i=-2,-1,1,2}P_{l,i}P_{l-1,i}^*\right)$$

Training Sequence 뒤 처음으로 오는 SIGNAL OFDM 심볼의 인덱스가 1임을 기억하자. 해당 심볼에서 위 값을 구할 때는 $P_{0,i}=Q_i$로 놓을 수 있다. 즉, $\angle(W_1)=\angle\left(\sum_{i=-2,-1,1,2}P_{1,i}Q_{,i}^*\right)$이 된다.

연속적인 덧셈 연산은 Fixed-point 하드웨어에서 부정확한 계산의 원인이 될 수 있으므로 4개의 연속된 $W$를 Exponential 필터를 적용하여 아래와 같이 더해준다.

Addition : $V_l=\sum^l_{m=l-3}W_m$
Filter : $U_l=\rho V_l + (1-\rho)U_{l-4}$

$l=4k$ 단위로 연산을 수행하므로 결국 $U_{4k}=\rho(W_{4k-3} + W_{4k-2} + W_{4k-1} + W_{4k}) + (1-\rho)U_{4(k-1)}$ 이 된다. 아주 부드럽게 변화하는 값이 나올 것 같다.

이 논문에서 저자들은 파라미터 $\rho$ 를 경험적으로 $1/32$로 얻은 것 같다. 이제 이를 바탕으로 $\hat{\epsilon}_l$을 추정할 수 있다. $l=4$ 이전에는 $l=0$의 값($\hat\epsilon_0$)를 사용하는 듯하다.

$\hat\epsilon_r=\angle(U_l)/(2\pi T_uf_c),\quad l=4,8,12,16,\cdots$
$\hat\epsilon_{l}=\hat\epsilon_{l+1}=\hat\epsilon_{l+2}=\hat\epsilon_{l+3}=\hat\epsilon_{0}+\hat\epsilon_{r},\quad l=4,8,12,16,\cdots$

위에서 다룬 각 과정의 결과는 OpenOFDM의 이 문서에서 Constellation Map으로 볼 수 있다.

안테나 다양성을 활용한 FO 추정 향상

안테나가 여러 개 있어도 하나의 Oscillator로 작동하므로 CFO, SFO 보상에 활용할 수 있는 데이터의 수가 늘어나 더욱 정교하게 CFO, SFO를 교정해줄 수 있다는 내용이다. 주요 관심 대상이 아니라 자세히는 읽지 않았다.

시뮬레이션 결과

Left: RMS error after ST and LT processing, Right: RMS error after Pilot Symbol processing

왼쪽은 STF와 LTF를 이용한 Coarse/Fine CFO Correction 이후인데, 점선이 Coarse Correction, 실선이 Fine Correction 이후이다. 오른쪽은 Pilot Subcarrier를 이용한 교정 이후이다. 가면 갈수록 RMS가 더 낮아지는 좋은 결과를 얻었다고 한다.

다시 한 번 정리

CFO, SFO 교정 방법

STF에서 대충 CFO를 유추하여 $\hat{\alpha}_{ST}$ 라 하고, 그를 이용하여 교정한다.
남은 CFO를 LTF로 좀 정밀하게 유추하여 $\hat{\alpha}_{LT}$ 라 하고, 그를 이용하여 교정한다.
이 단계에서 SFO와 또 남은 자잘한 CFO가 존재하게 된다.
SFO와 Residual CFO를 Pilot Symbol과 Channel Gain을 이용하여 추정하고, 교정한다.

QnA

$\alpha=2\pi \epsilon f_c T_s$인 이유는 무엇인가?
Frequency Offset이 $\epsilon$이고, 각주파수(초당 라디안)의 식이 $w=2\pi f$이므로, 매번 샘플링을 할 때마다 $T_sw=2\pi\epsilon f_c T_s$만큼이 느려지게 된다. 따라서 매번 샘플링을 할 때마다 위상 회전은 $\alpha=2\pi \epsilon f_c T_s$ 만큼 발생한다.
왜 $\hat{\alpha}_{ST}=\frac{1}{16}\angle \left(\sum^{63}_{m=0}S_m^*S_{m+16}\right)$ 인가?
여기서 논문의 오류로 보이는 것이 있는데, $\hat{\alpha}_{ST}$는 사실 $\frac{1}{16\times 64}\angle \left(\sum^{63}_{m=0}S_m^*S_{m+16}\right)$가 되어야 한다고 본다. $\hat{\alpha}_{ST}$는 한 번 샘플링을 할 때마다 생기는 Frequency Offset의 정도인데, 위의 계산식은 16 hop의 샘플 차이가 나는 것을 총 64번 더했으므로 한 hop 차이가 나는 샘플 간의 Frequency Offset은 $16\times 64$로 나눠야 그 대략적인 평균값을 알 수 있을 것이기 때문이다. 이는 $\hat{\alpha}_{LT}$와 $\angle(W_l)$도 마찬가지로, $\hat{\alpha}_{LT}=\frac{1}{64\times 64}\angle\left(\sum^{63}_{m=0}S_m^*S_{m+64}\right)$ 와 $\angle(W_l)=\frac{1}{4}\angle\left(\sum_{i=-2,-1,1,2}P_{l,i}P_{l-1,i}^*\right)$ 가 되어야 한다고 본다. 이는 내가 논문 이해를 잘못한 것일 수 있으므로, 확신하지는 않는다.
LTF를 이용한 CFO Correction의 첫 번째 단계에서 왜 STF + Guard Interval만큼의 Phase Rotation은 보상해주지 않는가?

위 그림에서 볼 수 있듯이, $\hat{\alpha}_{ST}$와 $\hat{\alpha}_{LT}$를 활용한 CFO 제거 과정에서 두 LTF의 시작 부분에서부터 Sample 인덱스를 시작하기 때문에 그 이전의 STF와 GI 시간에 증가해 온 Frequency 차이는 보상이 이루어지지 않는다. 하지만 이 값은 상수 값에 가깝기 때문에 (기울기가 위에서 설명한 FO 보상으로 제거됨), Waveform을 보면 단순한 평행 이동으로 나타나게 된다. 이는 따로 "Timing Offset"이라는 용어가 있으며, 별개의 보상 방법을 따른다. 이는 이 내가 보려는 "Frequency Offset" 주제를 벗어나기에 굳이 이 글에서 따로 다루지는 않는다.
Residual CFO 보상을 할 때와 Pilot Symbol을 활용한 Fine FO Estimation을 할 때, $P_{0,i}=Q_i$와 같이 Pilot Symbol($P$)이 들어가야 할 것 같은 자리에 채널 이득($Q$)을 대입하는데, 이렇게 해서 위상 회전 값을 구할 수 있는 이유는 무엇인가?
모르겠다. 논문에서는 아무런 설명도 나와있지 않다.
위에서 나온 아래 말의 의미는 무엇인가?

연속적인 덧셈 연산은 Fixed-point 하드웨어에서 부정확한 계산의 원인이 될 수 있으므로 4개의 연속된 $W$를 Exponential 필터를 적용하여 아래와 같이 더해준다.
모르겠다. 논문에서도 저 말 이외에 설명 혹은 인용 없이 그렇다고 하는데, 잘 모르겠다.

Precise Power Delay Profiling with Commodity Wi-Fi

실토 — Tue, 11 Feb 2020 02:12:46 +0900

CSI에서 제시하는 각 성분에 대해 더 자세히 이해하기 위해 읽게 된 논문이다. ACM MobiCom과 IEEE TMC에 등재되었는데, 더 많은 리뷰를 거친 듯한 TMC의 것을 읽었다.

IEEE Explore (2018) / ACM Library (2015)

Introduction

이 논문에서는 더 정확한 Power Delay Profile (PDP) 분석 및 활용을 위해 인접한 채널의 CSI를 이어 큰 Bandwidth에 대한 CSI 정보를 얻고자 했다.

Power Delay Profile의 시간축 Resolution은 신호의 대역폭에 따라 결정되는데 ^[각주:1]^[각주:2], 20MHz로 샘플링을 할 경우 감지할 수 있는 Multipath의 거리 차이는 최소 약 15m ($c \times (\frac{1}{20e+6})=14.9896$)이다. 만일 대역폭을 늘려 80MHz가 된다면, 감지할 수 있는 거리 차이는 최소 약 4m ($c \times (\frac{1}{80e+6})=3.7474$)로 줄어든다. 더욱 정확한 프로파일 분석이 가능해지는 것이다.

하지만 인접한 채널의 CSI를 그대로 이어붙이는 건 불가능했다. 회로의 부정확함과 통신에 영향을 주지 않는 결함이 컸기 때문이다. 따라서, 이 논문에서는 그러한 여러 오류를 어떻게 보상할 수 있을지에 대해 연구하였고, 시변 채널에 대해 얼마의 주기로 보상 값 계산을 해야하는지 등의 시스템 설계를 진행하였다.

Phase 값 이어 붙이기

이어붙이기 전에 몇 가지 문제를 해결해야 한다.

값의 겉보기 형태적 문제 (Non-linear Error)

자연의 신호는 연속이고, Phase는 선형이지만 실제 신호를 합쳐보거나 신호를 보면 그렇지 아니했다.

그래프에서 Phase값이 직선이 아니다.

원래 Propagation 거리 ($d$)가 일정하다면 주파수에 따른 Phase 값($\phi_k$)은 일정히 증가해야 한다.

$$\phi_k=2\pi( f_0+k\Delta f)\frac{d}{c}$$

하지만 Tx-Rx를 안테나를 써봐도, 안테나 대신 유선으로 땡깡 이어보아도 그러지 못했다. 즉, 아래의 (a), (b), (c)에서 직선 형태가 관찰되지 않았다.

(좌) 유선으로 Tx/Rx 칩을 이어 본 결과. 다른 색깔은 다른 칩이다. (우) 예상되는 결과.

서브캐리어 중간 부분은 어느 정도 직선 형태를 띄었는데, 양쪽 가에서는 그러지 못했다. 다만 이 Phase 왜곡 값은 모든 채널에서 각 서브캐리어에 대해 동일하게 나타났으므로, 칩마다 그 상수값을 측정하여 보상하면 된다.

개인적으로 이 내용을 구현해볼 때는 다음과 같이 했다.

40 MHz 채널에 대해서는 이 보정을 적용하기 이전에 아래의 Phase 튀는 문제의 보정을 먼저 적용했다.

% original_phase = o_phase
% linearified phase = l_phase
phase_newavg = mean(l_phase);
if size(o_phase, 2) == 114
  phase_center = mean(phase_newavg(39:76));
  phase_grad = mean(gradient(phase_newavg(39:76)));
else
  phase_center = mean(phase_newavg(19:36));
  phase_grad = mean(gradient(phase_newavg(19:36)));
end

syms x;
phase_line = x * phase_grad + phase_center;

if size(o_phase, 2) == 114
  phase_lindiff = phase_newavg - double(subs(phase_line, [-58:-2 2:58]));
else
  phase_lindiff = phase_newavg - double(subs(phase_line, [-28:-1 1:28]));
end

for i = 1:size(o_phase, 1)
  l_phase(i, :) = l_phase(i, :) - phase_lindiff;
end

이렇게 구현하면 아래와 같은 결과가 나온다.

40MHz 채널 중간에서 Phase가 튄다.

튄다. 위 그래프에서 아래 50-60 사이를 보면 훅 올라가는 구간이 있다. 이는 이 사람들이 조사해 본 결과 항상 일정한 값 (이 사람들 기기에서는 약 1.7rad)을 유지하는 경향이 있는 것이 확인되어 그냥 상수로 조사하여 보상해주면 된다.

개인적으로 이 내용을 구현해볼 때는 다음과 같이 했다.

% original phase = o_phase
% linearified phase = l_phase
if size(o_phase, 2) == 114
  phase_avg = mean(o_phase);
  phase_diff = phase_avg(58) - phase_avg(57) + ( ...
      (phase_avg(56) - phase_avg(41) ...
      + phase_avg(74) - phase_avg(59)) / 30 ...
      ) * 4;
  for i = 1:size(o_phase, 1)
      l_phase(i, :) = [ ...
          o_phase(i, 1:57) (o_phase(i, 58:114)' - phase_diff) ...
      ];
  end
end

이렇게 구현하면 아래와 같은 결과가 나온다.

위 두가지를 동작 인식에 사용할 수 있을까?

물론 사용할 수 있다. 하지만 결국 이상적으로 생각해보면 CSI의 Phase 데이터로부터 얻는 것은 하나의 일차방정식일 것이기 때문에, 위의 Nonlinear Error를 보상하는 것보다는 아래의 Linear Error를 보상하는 것이 훨씬 그 정확도를 높일 것이다. 컴퓨팅 리소스도 아낄 겸...! 뉴럴넷이 해결해줄거야...!

선형성에는 영향이 없는 오류들 (Linear Error)

이제부터는 겁나 어렵다.

안테나로부터 CSI를 얻는 과정은 위와 같은데, Phase값에 오류가 생기는 부분과 그 오류는 (그림에는 나와있지 않지만) Up/Downconverter에서 CFO, Packet Detector에서 Packet Detection Uncertainty (시간 오류), DAC/ADC에서 SFO이다.이다. CFO는 그림에 나와있듯이 CFO Corrector에서 어느정도 보상이 가능하다. 하지만 여전히 CFO 문제는 조금 남아있게 된다. AGC가 일으키는 문제는 추후 Amplitude 값 오류 해결 부분에서 다룬다.

Packet Boundary Detection Uncertainty 제거

들어오는 신호와 칩의 샘플링 주기가 정확하게 맞아 떨어지지 않는 이상, Packet Boundary Detection Error는 작은 범위 내에서 항상 일어나기 마련이다. 802.11n 칩은 Packet Boundary를 20MHz로 체크하므로, 아마 많아야 0.00000005초 이내로 차이가 날 것이라고 나는 생각하고 있다. 아무튼 PBD 에러는 거의 무조건 발생하는데, 이로 인해 실제 패킷의 시작 부분과 차이가 나는 만큼 Time Delay($\tau_b$)가 생긴다.

이 논문에서 인용한 [20]번째 문서^[각주:3]에 따르면 이 PBD 오류는 오류가 없는 점($\tau_b=0$)을 기준으로 가우시안 분포를 이룬다고 한다. 그리고 이 논문에서는 그를 직접 증명하는데, 실제로 가우시안 분포이다.

가우시안 분포를 따르는 오류는 어떻게 해결하는가?! 평균내면 된다. 그럼 영에 수렴할 터이다.

측정하려는 임의의 밴드 $b$에서 평균을 계산하기 위해 모을 패킷의 개수를 $n_b$라 하면...

$$\bar{\phi}^b_k=\sum^{n_b}_{i=1}\phi^b_k(i)/n_b$$

이다. 여기서 $i$는 측정한 Packet의 번호이고, $k$는 서브캐리어의 번호이다. 즉, 각 밴드 각 서브캐리어마다 몇개의 CSI를 모아 평균을 때린다는 것이다.

이 보정을 동작 인식에 사용한다고 생각해보자. 분명... Phase 변화가 더 부드러워질 것이다. 하지만 우리의 뉴럴넷은 어느정도의 노이즈는 받아주므로 뉴럴넷에 넣을 데이터에 이 전처리는 안 해줘도 될 것이다.

Sampling Frequency Offset 제거

SFO는 DAC와 ADC 사이의 샘플링 Frequency 차이인데, Tx와 Rx의 샘플링 주파수를 각각 $f_t$, $f_r$이라고 하면 이들로 인해 일어날 수 있는 Offset의 최소 배수 (fractional difference)를 $\zeta=\frac{f_t}{f_r}-1$이라고 할 수 있다. SFO를 $\phi_k$에서 제거하려면 $\phi_k$에다 $e^{-j\cdot \zeta'\cdot k}$를 곱하면 될 것이다. $j$는 허수, $\zeta'$는 fractional difference의 배수이다.

그렇다면 저 SFO($\zeta'$, 아래에서는 $\epsilon$)는 어떻게 구하는가? 이 논문의 저자들은 같은 환경 및 조건에서 여러 밴드에 대해 CSI를 측정할 경우 같은 Multi Path를 거치기 때문에, PBD로 인한 오류를 제거한 다음의 Phase값이 만일 SFO가 없다면 밴드 관계 없이 모두 동일해야 한다는 점을 이용했다. ^[각주:4]

for each Wi-Fi Band Pair "$c$" do  
    Record the top-two local maximal similarity values and the  
    corresponding $\epsilon:<\epsilon^c_1,\rho^c_1>$ and $<\epsilon^c_2,\rho^c_2>$.  
Clustering on $\epsilon$ and find the cluster with the maximal similarity sum.  
Return the cluster center as the final $\epsilon$ value.

알고리즘을 해석해보자면, 두 밴드의 페어를 $c$라 하고, 한쪽 밴드에 $\epsilon^c$만큼을 곱하여 "rotate" 시킨 뒤, 두 밴드의 Phase 유사도를 $\rho^c$라 하며, 그들을 저장하여 클러스터링하여 가장 유사도가 높은 곳의 $\epsilon$값을 SFO로 추정하겠다는 것이다.

이런 결과가 나오며, 여기서는 $\epsilon=0.75$ 정도가 가장 유사도($\rho$)가 크게 나왔다.

컴퓨팅 효율이 안좋을 것 같아 보이지만, 그에 대해서는 후술한다.

Central Frequency Offset 제거

Central Frequency Offset은 Tx와 Rx가 중앙 주파수를 서로 못 맞춰서 벌어지는 일이다. 이때까지의 오류 원인들은 모두 서브캐리어마다 다르게 작용하여 Normalize한 CSI 값에도 영향을 주었으나, Central Frequency Offset은 모든 서브캐리어에 동일하게 더해지기에 Normalize 결과에 영향을 주지 않는다. 따라서 하나의 밴드를 레퍼런스 삼아 다른 밴드를 캘리브레이션한다면 CFO는 고려하지 않아도 되게 될 것이다.

어떻게 캘리브레이션하냐면... [업데이트 예정]

Unused Subcarriers 메꾸기

CSI에서 보고되는 서브캐리어에는 일부가 빠져 있다. Atheros CSI Tool의 경우 아래의 $Ng=1$, Intel CSI Tool의 경우 20MHz 대역폭에서는 $Ng=2$, 40MHz 대역폭에서는 $Ng=4$를 보고한다.

어떤 툴을 써도 중앙의 DC(Central) 서브캐리어와 양쪽의 가드 밴드는 보고하지 않는다. 각각 DC Offset과 인접 채널의 영향을 막기 위해서이다. 이러면 사실상 측정하려는 밴드에 대해 연속적으로 샘플링을 하지 않는것이 되는데, 통신 이론에 따르면 특정 대역폭($B_c$) 안의 주파수 대역은 페이딩을 비슷하게 겪는다고 하며, 실내 환경에서 $B_c$는 10MHz를 넘는다고 한다. 즉, 보고되지 않은 아이들은 커브 피팅으로 보완해줄 수 있는 것이다.

어떤 커브를 썼느냐면... [업데이트 예정]

Phase 값 이어 붙이기 마무리

아직 더 오류가 남아있을 수 있지만 (Thermal Noise, AGC Error 등) 이렇게 각 신호/패킷 분석 과정에서 일어나는 오류는 보상하고 여러 밴드의 Phase값을 이어붙일 수 있다.

이어붙인 다음에 한 번 더 SFO 보상을 해줄 수 있는데, 이어붙인 넓은 Bandwidth에서 일부 서브캐리어를 연속으로 선택하여 윈도우로 만들고, 그 윈도우들끼리 SFO 보상 알고리즘을 다시 한 번 실행하여 더욱 정확하게 SFO 값을 없앨 수 있다고 한다.

윈도우의 크기가 클 수록 더 정확한 SFO를 얻을 수 있을 것으로 보이지만, 그게 아니다.

따라서 전체 Bandwidth의 0.75를 사용하여 SFO 보상을 하면 가장 정확하며, 이렇게 이어붙이고 보상을 해줄 수 있다.

Amplitude 값 이어 붙이기

AGC에서 발생하는 Power Control 오류 또한 가우시안 분포를 따른다고 한다. 허나 이는 밴드와 무관한 현상이므로, Phase에서 평균을 내는 방식과는 다르게 얻은 모든 CSI값을 평균내어 구할 수 있다.

어떻게 했냐면... [업데이트 예정]

오류 보상 주기

올바른 이어붙이기를 위해서는 언제 CSI를 측정하여 시시각각 달라지는 오류를 보상해줄지 그 스케쥴링 또한 필요하다. 하지만 지금 내 목표는 이미 기록된, Windowed CSI에 대한 후처리이기 때문에, 여기 부분은 읽지 않았다.

T. S. Rappaport, et al., Wireless Communications: Principles and Practice. Upper Saddle River, NJ, USA: Prentice Hall, 1996. [본문으로]
A. Goldsmith, Wireless Communications. Cambridge, U.K.: Cambridge Univ. Press, 2005. [본문으로]
M. Speth, S. Fechtel, G. Fock, and H. Meyr, “Optimum receiver design for wireless broad-band systems using OFDM. I,” IEEE Trans. Commun., vol. 47, no. 11, pp. 1668–1677, Nov. 1999. [본문으로]
아래 말할 Central Frequency Offset으로 인한 오류는 여기에 영향을 주지 않는다! 왜 그런가에 대해서는 후술한다. [본문으로]

Where is the orthogonality in OFDM?

실토 — Tue, 4 Feb 2020 20:25:06 +0900

Mathematical Concept of "Orthogonality"

Generally orthogonality means that the inner product of two vector is zero.

There's not only a concept of the inner product of vectors, but the inner product of functions, and this can be expressed as a definite integral.

$$\left\lbrace \begin{array}{ccc}<f,g>=\int_a^b f(x)g(x)~dx & & \textrm{Inner}\;\textrm{Prod.}\;\textrm{of}\;\textrm{Real}\;\textrm{Fn.}\\<f,g>=\int_a^b f(x)\overline{g(x)} ~dx & & \textrm{Inner}\;\textrm{Prod.}\;\textrm{of}\;\textrm{Complex}\;\textrm{Fn.}\end{array}\right.$$

Therefore, we can say that two functions are orthogonal if their inner product value is zero and this can be applied to complex signals.

Orthogonality of OFDM Subcarriers

Mathematical Expression of OFDM Signal

The OFDM signal can be expressed as below.

$$\left\lbrace \begin{array}{ccc}S(t)=\frac{1}{N}\sum_{n=0}^{N-1} A_n (t)e^{j\left\lbrack \omega_n t+\phi_n (t)\right\rbrack } & & \textrm{OFDM}\;\textrm{Signal}\\S_n (t)=A_n (t)e^{j\left\lbrack \omega_n t+\phi_n (t)\right\rbrack } & & \textrm{Signal}\;\textrm{of}\;\textrm{Each}\;\textrm{Subcarrier}\end{array}\right.$$

$N$ is the number of subcarriers, $A_n$ is amplitude of each subcarrier, and $\phi_n$ is phase of them.

$A_n (t)$ and $\phi_n (t)$ has a constant value during a symbol duration and $\omega_n =\omega_0 +n\Delta \omega$.

Suppose that the sampling rate is $1/T_s$, then a period of one OFDM symbol is $T=NT_s$ because we should sample $N$ times in one symbol. Also suppose that $\omega_0 =0$, then $\omega_n$ becomes $n\Delta \omega$.

We can now write a simple sampled signal expression: $S(tT_s )=\frac{1}{N}\sum_{n=0}^{N-1} \textrm{C}e^{jn\Delta \omega tT_s } ~~(0\le t<T)$

$\textrm{C}$ is a const from amplitude and phase values at a specific symbol.

The OFDM signal is generated from IDFT calculation, so let's compare above with general IDFT expression.

$$\left\lbrace \begin{array}{ccc}S(tT_s )=\frac{1}{N}\sum_{n=0}^{N-1} \textrm{C}e^{jn\Delta \omega tT_s } & & \textrm{Simplified}\;\textrm{OFDM}\;\textrm{Signal}\\x(tT_s )=\frac{1}{N}\sum_{n=0}^{N-1} X(tT_s )e^{j2\pi tn/N} & & \textrm{General}\;\textrm{IDFT}\;\textrm{Expression}\end{array}\right.$$

So, $\Delta \omega =\frac{2\pi }{T}$. This is a condition for the orthogonality. Why?

Dealing with Orthogonality

Let's try to show that subcarrier $\alpha$ and $\beta$ is orthogonal. We should solve definite integral of two signal of each subcarrier.

$$\int_0^T S_{\alpha } (t)\overline{S_{\beta } (t)} ~dt$$

For convinience of thinking, the amplitude part and phase part can be expressed as a symbol $C$ because they are constant. Also suppose that the lowest frequency is 0 ($\omega_0 =0$).

$$C\int_0^T e^{j(\alpha \Delta \omega )t} e^{-j(\beta \Delta \omega )t} ~dt=C\int_0^T e^{jt\Delta \omega (\alpha -\beta )} ~dt$$

Then the trigonometric form of the integration is $C\int_0^T \cos (t\Delta \omega k)+j\sin (t\Delta \omega k)~dt$ if $k=\alpha -\beta$.

This equals to $C\int_0^T \cos (\frac{2\pi tk}{T})+j\sin (\frac{2\pi tk}{T})~dt$ and $k$ is an integer!

When we solve the integral: $C(0+0j)=0$

So, for any subcarrier $\mathbf{\alpha}$ and $\mathbf{\beta}$, they are orthogonal!

MATLAB Example

csi_0006_OinOFDM.mlx

0.17MB

% Select Two Subcarriers
sub_a = 11; % Subcarrier A [1 64]
sub_b = 48; % Subcarrier B [1 64]

% Environment Configuration
symbol_duration = 3.2e-6; % 3.2 microseconds
rx_sampling_time = 5e-8:5e-8:symbol_duration; % 20MHz
N = 64; % 64 subcarriers

% One Symbol Signal Generation
rng('shuffle');
syms t;
% oscillator_resolution = (symbol_duration / (N * 1e+2));
signal = sym(zeros(N));
for i = 1:N
    signal(i) = (rand(1) + rand(1) * 1i) * ...
        exp(1i * i * 2 * pi / symbol_duration * t);
end

% Plot Signals
figure(1); clf;
hold on;
plot(NaN, 'Color', [0 0 0], 'LineWidth', 2);
plot(NaN, 'Color', 'g', 'LineWidth', 2);
plot(NaN, 'Color', 'r');
for i = 1:N
    if i ~= sub_a && i ~= sub_b
        fplot(real(signal(i)), [0 27e-8], 'Color', [0 0 0] + 0.8);
    end
end
fplot(real(signal(sub_a)), [0 27e-8], 'Color', [0 0 0], 'LineWidth', 2);
fplot(real(signal(sub_b)), [0 27e-8], 'Color', 'g', 'LineWidth', 2);
for i = 1:5
    plot([i * 5e-8 i * 5e-8], [-1.5 1.5], 'Color', 'r');
end
hold off;
ylim([-1.5 1.5]);
xlim([0 27e-8]);
xticks(0:5e-8:25e-8);
xticklabels({'0ns' '50ns' '100ns' '150ns' '200ns' '250ns'});
text(28e-8, 0, '. . .');
legend('Subcarrier A', 'Subcarrier B', 'Sampling Time', 'Location', 'southeast');
title('Real Value of Subcarriers');

% Inner Product
signal_a = signal(sub_a);
signal_b_conj = conj(signal(sub_b));
product = int(signal_a * signal_b_conj, t, 0, symbol_duration);

% Display Product Result
figure(2); clf;
scatter(real(double(product)), imag(double(product)), 1200, 'Marker', '*', ...
    'MarkerEdgeColor', [1 0.8 0.4] - 0.1, 'LineWidth', 2);
ylim([-1e-15 1e-15]);
yticks(-0.8e-15:0.2e-15:0.8e-15);
ylabel('Imag');
xlim([-1e-15 1e-15]);
xticks(-0.8e-15:0.2e-15:0.8e-15);
xlabel('Real');
pbaspect([1 1 1]);
ax = gca;
ax.XAxisLocation = 'origin';
ax.YAxisLocation = 'origin';
text(1.2e-16, 1.2e-16, '↙ Zero?');
title({'Product Result =', strtrim(evalc('disp(double(product))'))});

(Left) Figure 1 / (Right) Figure 2

References

2019년 1월 블로그, 서버 개편

실토 — Thu, 10 Jan 2019 22:15:35 +0900

겨울 방학을 맞아 서버와 블로그 관리를 조금 하고 있다.

블로그는 아예 Hexo 기반에서 티스토리 기반으로 옮기면서 그 동안 생각해오던 블로그 기능을 거의 다 넣었다. 약 3일간을 쉬지 않고 작업한 것 같다. 아직 티스토리 에디터는 코드 삽입을 제대로 지원하지 않는데, 곧 바뀔 에디터처럼 보이는 '페이지 에디터'를 보니 정식으로 코드 삽입을 잘 지원할 것 같다. 일단은 HTML 편집 모드와 위지윅 편집 모드를 오가며 엄청난 노가다를 했다. 글이 얼마 없었어서 망정이지 큰일 날 뻔 했다.

서버는 그대로 토스트 클라우드를 이용하는데, 정적 리소스 서버와 리디렉션 서버를 하나로 합치고 404 페이지를 안내하는 서버는 개인 프로젝트 페이지 리스트를 띄워 주는 서버와 합쳐 총 두 개의 서버를 돌리게 되었다.

이전에 이용하던 오브젝트 스토리지는 정적 리소스 서버로 옮겼다. 체계화된 리소스 관리가 필요하지 않기 때문이다.

춥다.

EOS, DPOS 핥아보기

실토 — Thu, 10 Jan 2019 21:36:42 +0900

이 글은 Hexo 기반의 블로그에서 옮겨온 글이며, 원본 글은 2018년 10월 7일에 작성되었다.

EOS는 수많은 DPOS 기반의 블록체인을 만들어 온 댄 라리머(Dan Larimer)가 주도하여 만든 블록체인이다. 왜 굳이 EOS인가에 대해, 댄 라리머가 한글을 배워 자신의 이름 댄을 영어로 입력하여 EOS라고 이름을 지은 것으로 나는 추측하고 있다.

~~EOS를 한글로 치면 댄이다~~

이름이야 뭐 어쨌든 이 글에서는 EOS 프로젝트의 목적과 특징을 알아보고, EOS 빌드, 테스트넷 가동, 간단한 스마트 컨트랙트 실행을 직접 해 본다.

추가적으로 DPOS의 장단점과 공격 가능 포인트들도 짚어 보았다.

EOS가 무엇일까

먼저, EOS가 무엇인지, EOS 측에서 주장하는 EOS의 특징과 장점이 무엇인지 알아보자.

EOS, block.one 로고

EOS 트랜잭션 수

왼쪽이 EOS의 로고이고, 오른쪽이 EOS를 만든 block.one의 로고이다. 이더리움의 ERC20 토큰을 기반으로 교환이 이루어지다 현재는 독자적인 메인넷을 런칭한 블록체인인 EOS는 Blocktivity에 따르면 현재 가장 활동량이 많은 블록체인이 되었다^[각주:1]. 오른쪽 CoinMetrics의 자료를 보면 EOS의 트랜잭션 수는 폭발적으로 증가했음을 볼 수 있다.

EOS는 일부로부터 "3세대 블록체인^[각주:2]"이라고 불리고 있는데, 이는 기존의 이더리움 체계에서 나타난 여러가지 문제들(대표적으로 Scalability)을 해결하면서 나타난 것이다.

	BTC	ETH	EOS
채굴 (합의 알고리즘)	PoW	PoS	DPOS
스마트 컨트랙트 지원	✕	○	○
통치(Governance) 형태^[각주:3]	Off-chain	Off-chain	On-chain
지연 (블록 포함 시간)	5 ~ 40분	5 ~ 40초	1.5초
트랜잭션 수^[각주:4]	0.22M	0.77M	7.71M
TPS	7 내외	20 내외	수천 TPS^[각주:5]
트랜잭션 비용	사용자 부담 (BTC)	사용자 부담 (Gas)	개발자 부담 (EOS)

위는 다른 블록체인과의 차이를 비교해 둔 것이다. EOS가 채택한 DPOS 합의 알고리즘으로 인해 트랜잭션 수에서 다른 블록체인과 크게 차이가 난다. 특이한 점으로는 EOS에서의 지연 시간에는 범위 표시(~)가 없다는 것인데, 비트코인이나 이더리움은 트랜잭션 비용에 따라 블록 포함 속도가 달라지기 때문에 지연 시간에 차이가 날 수 있지만, EOS는 그런 건 없기에, 트랜잭션이 생성된 이후 가장 최근 블록이 생성될 때 같이 포함된다. 나머지 부분들에 대해서는 아래에서 자세히 설명한다.

EOS의 겉보기 특징

이전 세대 블록체인과는 다른, EOS의 특징을 간단히 알아보자.

1. Scalable

첫 번째는 확장가능하다는 것이다. EOS에서는 EOS.IO가 수많은 사용자들이 동시에 EOS 애플리케이션을 구동할 수 있는 OS라고 홍보하는데, 이를 위해서는 트래픽이 커져도 빠른 속도를 유지하며 작업을 처리하는 것이 중요하다. 이더리움의 스마트 컨트랙트는 이 문제를 해결하지 못해 자주 병목 현상이 발생하곤 한데, EOS에서는 DPOS라는 무지하게 빠른 합의 알고리즘으로 빠른 블록 생성 속도를 구현한다. 또한 DPOS의 빠른 블록 생성 속도를 뒷받침하기 위해 애플리케이션의 병렬 실행을 지원한다. 멀티 체인도 지원한다. 비교를 해보자면, 비자(VISA)가 초당 약 일만 개의 트랜잭션을 처리할 수 있을 때, EOS는 이론 상 약 백만 개의 트랜잭션을 처리할 수 있다. 이를 보았을 때, 아마 EOS의 가장 큰 특징은 이러한 Scalability일 것이다.

2. Governance

두 번째는 통치 방식이다. EOS는 21개의 대표 노드(Block Producer; BP)가 전체 네트워크를 통솔하고 움직이는데, 이들은 투표를 통해 엄청 다양한 일들을 처리할 수 있다. 블록체인을 특정 블록으로 되돌릴 수 있고, 계정 동결, 프로토콜 및 약관의 개정 등 정말 다양한 일을 할 수 있다.

EOS에는 "EOS 헌법"이라는 것이 존재하는데, 아직은 임시 헌법이지만 곧 BP들 사이의 투표를 통해 제대로 된 헌법으로 확정하고 EOS 전체 네트워크의 방향과 활동을 규정하게 된다.

3. Flexible

세 번째는 유연함이다. EOS는 위에서 말한 통치 방식으로, 하드포크하지 않고도 블록체인의 문제점을 손볼 수 있고, 문제되는 DApp이 있으면 해당 DApp만을 정지하고 손볼 수 있다.

또한, Role-Based Access Control 방식을 채택하여, 유저가 불필요한 권한을 가지게 되는 상황을 방지하고 있다. 무슨 말이냐면, 사람에게 권한을 주는 기존의 방법이 아니라, 특정 "역할"에 권한을 미리 다 부여한 다음, 해당 사람의 역할만 바꾸어주어 필요한 권한만 부여될 수 있도록 권한을 관리한다.

EOS는 다양한 VM을 유연하게 지원하여, 이더리움의 스마트 컨트랙트도, 웹 어셈블리로 만들어진 스마트 컨트랙트 등 다양한 컨트랙트 종류를 EOS 네트워크에서 실행시킬 수 있다.

EOS의 세부 특징

이제는 EOS의 특징에 대해 조금 더 자세히 살펴보자.

1. 트랜잭션 비용 없음 (수익 모델)

EOS 수익 모델

EOS에는 트랜잭션 비용이 없다. 이더리움은 DApp의 사용자들이 트랜잭션을 보낼 때마다 사용료로 일정량의 Gas를 지불한다. 예를 들어 사용자가 DApp에서 댓글을 작성하려 하거나, 메시지를 보내는 비금융 활동을 하면 그것에 대해서도 사용료를 내야 한다. 하지만 이런 방식은 사용자들이 DApp을 쓰는 데 불편함을 주게 된다. EOS는 더 많은 사람들을 네트워크로 끌어들이고자 DApp 사용자가 아니라 개발자로부터 사용료를 청구한다. 정확히는, 개발자가 가지고 있는 EOS 양에 비례하여 개발자에게 네트워크 대역폭과 연산 처리 능력(CPU)을 할당한다 (개발자로부터 EOS를 가져가는 것이 아니다). 전체 구조적으로 생각해보자면, 사용자는 트랜잭션 비용을 지불하지 않으면서도 블록체인 네트워크 기반 서비스를 사용할 수 있고, 그러면 사용자가 많으면서 DApp의 개발 및 유지비용이 적게 드는^[각주:6] EOS로 개발자들이 모이게 된다. 이렇게 모인 사용자와 개발자로 EOS는 점차 점유율을 높일 수 있고, EOS 화폐 자체의 가치도 높아지면서 EOS 네트워크와 EOS 화폐를 다량 소유한 BP들이 수익을 얻게 되는 것이다.

2. DPOS (Delegated Proof-Of-Stake)

PoW와 PoS

DPOS를 이해하려면 먼저 PoW(Proof-of-Work)와 PoS(Proof-of-Stake)를 알고있는 것이 좋다. EOS를 공부하는 사람이라면 아마 PoW에 대해서는 알고있을 것이므로 PoW에 대해서는 설명하지 않겠다. PoW와 양대 산맥을 이루는 합의 알고리즘으로 PoS(지분 증명)가 있는데, 이는 암호화폐 지분을 많이 가진 사람에게 더 큰 힘을 주고자 하는 것이다. 즉, 동시에 많은 블록이 만들어진다면 지분을 많이 가진 사람의 블록을 채택하는 것이다.

DPOS

DPOS는 PoS와 원리는 같다. 이 둘의 차이는 직접 민주주의와 간접 민주주의로 이해하면 아주 쉬워진다. 둘 다 투표를 통해 무언가를 결정하지만, 직접 민주주의는 구성원 모두가 권리를 직접 행사하고, 간접 민주주의는 대리인을 내세워 그들로 하여금 권리를 행사하게 한다. PoS는 직접 민주주의로, 많은 사람들의 동의를 얻어 블록을 형성하기에 블록 형성에 시간이 오래 걸린다. 이를 해결하기 위해 등장한 DPOS는 지분을 가지고 있는 사람들이 뽑은 소수의 대표들만 투표를 진행하기 때문에 블록이 빠르게 형성될 수 있다. 이러한 DPOS 방식을 채택하는 블록체인에는 스팀, EOS 등이 있다.

EOS에서의 DPOS

그래서, EOS가 DPOS를 어떻게 적용했는지 알아보자. 앞서 말했듯이, DPOS 방식이 PoW와 PoS에 비해 월등히 빠르기에 EOS는 DPOS를 채택할 수 밖에 없었다. EOS는 매 "라운드"마다 126개의 블록을 생성하는데, 이 라운드가 시작될 때 투표를 옽해 21명의 BP(Block Producers)를 선출한다. 이 BP들은 모든 노드를 대표하여 블록을 생산하는 노드가 된다. EOS를 보유한 사람은 1 EOS당 30개의 노드에 투표할 수 있으며, 선출된 대표들은 매 라운드마다 각자 6개의 블록을 만들게 된다. 즉, 21×6=126 인 것이다. 새로운 블록은 21개의 BP 중 15개 이상이 동의하면 체인에 포함된다. 매 초마다 두 개의 블록이 체인에 포함되므로 결국 한 라운드에 1분, 즉 약 1분 동안 126개의 블록이 생성되는데, 이는 10분에 한 블록을 생성하는 비트코인과 비교하면 무척이나 빠른 속도라고 할 수 있다.

이외에 DPOS 공격 가능성과 DPOS Tradeoffs 등 부가적인 내용은 아래에 적어놓았다.

3. TaPoS (Transaction as Proof of Stake)

EOS는 네트워크의 보안을 높이는 기술인 TaPoS를 채택하고 있다. 기존의 PoS/DPOS 방식에서는 일부 노드만이 PoS 계산에 참여했는데, TaPoS는 모든 트랜잭션이 가장 최근 생성된 블록 헤더의 해시값을 포함하도록 하여 트랜잭션을 만드는 모든 노드들이 전체 네트워크의 보안에 참여하도록 한다.

4. Smart Contract Development Using C++

EOS는 이더리움이 Solidity를 사용하듯이, 스마트 컨트랙트 언어로 C++를 사용하고 있다. C++로 작성된 스마트 컨트랙트는 추후 웹 어셈블리로 컴파일되어 WASM 위에서 돌아가게 된다.

EOS 프로그램, 네트워크 구조

EOS 프로그램 구조

EOS는 nodeos, keosd, cleos의 세 가지 프로그램으로 구성되어있다. nodeos는 node와 eos가 결합한 말로, EOS의 블록을 생성하는 가장 주요한 기능을 담당한다. 사용자가 보낸 트랜잭션이 유효한지, 블록이 유효한지 등을 결정하는 하나의 노드 프로그램이다. keosd는 key와 eos가 결합한 말로, 지갑 단위로 키를 관리하는 구성요소이다. 마지막으로 cleos는 CLI와 eos가 결합한 말로, 사용자가 다른 EOS 구성요소에 접근할 수 있는 인터페이스를 제공한다. 즉, 사용자는 이를 이용하여, keosd 및 nodeos에 접근할 수 있다.

간단한 예시를 들어보자면, 사용자는 트랜잭션을 만들기 위해 일단 자신의 지갑에 접근해야 하는데, 이 때 keosd를 거쳐 올바른 키를 사용하여 지갑을 잠금 해제하게 된다. 그 다음 트랜잭션을 만들고, nodeos에 접근하여 트랜잭션 검증을 받은 후, nodeos가 블록체인 네트워크로 해당 트랜잭션을 브로드캐스트하여 블록체인에 트랜잭션이 포함되게 된다.

EOS 네트워크 구조

EOS의 메인넷에는 21개의 Block Producer 노드와 79개의 Backup Producer 노드가 있다. 만일 DDoS 공격 등으로 인해 어떤 Block Producer에게 문제가 생기면, Backup Producer가 그 일을 대신하게 된다. 각각의 노드는 자신이 소유한 EOS 만큼의 투표권을 활용하여 최대 30개의 노드에게 자신의 권한을 위임할 수 있다. 결과적으로, 이를 통해 매 라운드마다 21개의 Block Producer 노드가 투표에 의해 선출된다. 선출된 Block Producer는 각각 블록을 만들어 다른 Block Producer에게 검증을 받고, 블록체인을 잇는다.

각 노드가 EOS를 얼마나 가지고 있는지는 EOS 네트워크에서 DApp을 구현하는 데 영향을 미친다. DApp 개발자는 자신이 가지고 있는 EOS의 양에 비례하여 투표권 뿐 아니라 CPU 할당, 네트워크 대역폭을 보장받을 수 있다.

EOS 설치

이제 본격적으로 EOS를 만나보자. EOS는 자동 빌드 스크립트는 현재 아래와 같은 환경을 지원한다.

Amazon 2017.09 이상
CentOS 7
Fedora 25 이상 (27 추천)
Mint 18
Ubuntu 16.04 이상 (16.10 추천)
MacOS Darwin 10.12 이상 (10.13.x 추천)
Docker 17.05 이상

공식적으로 언급하지는 않았지만, 아래의 OS도 추가로 지원하도록 짜여져 있다.

elementary OS
Debian

이는 데비안이나 엘리멘트리 OS나 둘 다 우분투와 같은 설치 로직을 쓸 수 있기에 같이 지원하는 듯하다. 위 목록에 없는 리눅스 배포판을 사용한다면, 이 링크를 참고하여 직접 빌드해야 한다.

여기서는 도커 환경을 제외한 나머지 리눅스 환경을 기준으로 설명하겠다. 도커 환경에서의 설치 방법은 이 링크를 참조하면 된다. 참고로 위 리눅스 배포판 목록에 있는 리눅스라면, WSL 환경에서라도 잘 돌아간다.

아래의 코드에서, 작업 디렉토리는 홈 디렉토리(~)이다.

1. EOS 소스 코드 다운로드하고 빌드하기

git clone https://github.com/EOSIO/eos --recursive
cd eos; ./eosio_build.sh -s EOS

이 작업은 오래 걸린다. 환경에 따라 다르겠지만, 내 개인 서버 기준으로 약 한 시간이 걸렸다.

2. 빌드 테스트하고 바이너리 설치하기

빌드 테스트

export PATH=${HOME}/opt/mongodb/bin:$PATH
~/opt/mongodb/bin/mongod -f ~/opt/mongodb/mongod.conf &
cd ~/eos/build; make test

몇 개의 테스트는 실패하기도 하지만, 실제 이후 EOS의 동작에는 아무런 문제가 없었다.
이 과정도 아주 오래 걸렸는데, 약 한 시간 반이 소모되었다. 시간이 없는 사람은 그냥 넘어가도 좋을 듯하다.

바이너리 설치

cd build
sudo make install
export PATH=$PATH:/usr/local/eosio/bin

3. 테스트넷 구동

아래 명령어로 테스트넷을 구동해보자.

nodeos -e -p eosio --plugin eosio::chain_api_plugin --plugin eosio::history_api_plugin

여기서 각 파라미터를 설명하면 아래와 같다.

-e : 체인이 정상 체인이 아니더라도 블록을 생성하게 한다.
-p eosio : 이 노드가 통제하는 프로듀서의 ID
--plugin : 활성화 할 플러그인을 지정할 수 있으며, 여러 개를 지정할 수 있다.

만일 EOS 노드를 성공적으로 구동했으면 계속해서 블록을 만드는 로그가 콘솔에 뜰 것이다. 약 0.5초에 한 블록이 생성될 것이다.

4. CLI 실행해보기

이전의 nodeos를 닫지 말고, 다른 터미널에서 아래의 명령어를 입력하여 cleos를 이용해보자.

export PATH=$PATH:/usr/local/eosio/bin
cleos get info

이 커맨드는 현재 블록체인의 상태, 정보를 nodeos로부터 받아와 위와 같이 출력해준다. 위와 같이 출력된다면, 정상적으로 EOS가 설치된 것이다.

EOS Hello-World App 빌드해보기

테스트넷 위에 Hello World 애플리케이션을 설치해보자.

1. 애플리케이션 빌드

EOS 애플리케이션을 빌드하기 위해서는 EOSIO Contract Development Toolkit이 필요하다. 이 링크의 설명을 따라 먼저 툴킷을 설치하자.
이후 미리 작성된 컨트랙트 코드를 git으로 받아 make하여 간단하게 Hello World 컨트랙트를 빌드할 수 있다.

$ git clone https://github.com/yuoa/eos-hello-world
$ cd eos-hello-world; make
Compiling hello.cpp to web assembly files... Finished.

이후 ls 명령어로 결과를 확인해보면 hello.abi, hello.wasm 파일이 생겼을 것이다.

아래는 수동으로 방금 만든 컨트랙트 코드를 테스트하는 방법을 적어놓았는데, 시간이 없으면서도 내 EOS가 작동하는지 확인하고 싶은 사람들은 make test 명령어로 자동 테스트를 해볼 수 있다.

2. 지갑과 개인 키 만들기

방금 만든 애플리케이션을 런칭할 계정이 필요하므로, 만들어주자. 아까 실행시켜둔 nodeos는 계속 켜 두고, 다른 터미널에서 계속 진행한다.

$ cleos wallet create --to-console
Creating wallet: default
Save password to use in the future to unlock this wallet.
Without password imported keys will not be retrievable.
"PW5JXSUH1uTaQarXgSDZgdWzGeWupPFmwd2RtFkzrivudMtu2Xxs2"

이 명령줄의 마지막이 지갑의 비밀번호이므로, 따로 메모해두자.

$ cleos create-key --to-console
Private key: 5KeHEF9xm5E32DMth2K8tFwvcwT9DJohNmycLegwAnCCe3WBejT
Public key: EOS7zgbYJFXRMhcW8MtRyCKv4LS94xVQh7DHGif5ruVmHHYrmqu7d

위 명령줄로 개인/공개 키 쌍을 만들 수 있다. 이제 이 개인 키를 지갑에 추가하자.

$ cleos wallet import -n default --private-key 5KeHEF9xm5E32DMth2K8tFwvcwT9DJohNmycLegwAnCCe3WBejT
imported private key for: EOS7zgbYJFXRMhcW8MtRyCKv4LS94xVQh7DHGif5ruVmHHYrmqu7d

3. BIOS 컨트랙트 구동

이제 EOS 테스트넷에 BIOS 컨트랙트를 구동시킬 차례이다. BIOS 컨트랙트는 개발의 목적으로, 다른 계정의 리소스 할당이나 권한이 필요한 내부 API 호출 등을 직접적으로 가능하게 해 주는 컨트랙트이다. 아래의 명령으로 바이오스 컨트랙트를 로드할 수 있다.

$ cleos wallet unlock --password PW5JXSUH1uTaQarXgSDZgdWzGeWupPFmwd2RtFkzrivudMtu2Xxs2
Unlocked: default
$ cleos wallet import --private-key 5KQwrPbwdL6PhXujxW37FSSQZ1JiwsST4cqQzDeyXtP79zkvFD3
imported private key for: EOS6MRyAjQq8ud7hVNYcfnVPJqcVpscN5So8BhtHuGYqET5GDW5CV
$ cleos set contract eosio ~/eos/build/contracts/eosio.bios -p eosio
Reading WASM from ~/eos/build/contracts/eosio.bios/eosio.bios.wasm...
Publishing contract...
(the rest omitted)

여기서 난데없이 5KQwrPbwdL6PhXujxW37FSSQZ1JiwsST4cqQzDeyXtP79zkvFD3이라는 개인 키를 추가하는데, 이는 EOS 테스트넷을 만들 때 내부적으로 쓰인 키로, 바이오스 컨트랙트를 로드 및 구동하는 데 필수적이다.

참고로, EOS 메인넷에서 바이오스 컨트랙트는 EOS 보유량에 따른 CPU 및 네트워크 대역폭 할당을 담당하고 있다.

4. 테스트용 계정 만들기

아까 빌드한 스마트 컨트랙트를 테스트하기 위해 계정 두 개(user, test)를 만들어주자.

cleos create account eosio user EOS7zgbYJFXRMhcW8MtRyCKv4LS94xVQh7DHGif5ruVmHHYrmqu7d EOS7zgbYJFXRMhcW8MtRyCKv4LS94xVQh7DHGif5ruVmHHYrmqu7d
cleos create account eosio test EOS7zgbYJFXRMhcW8MtRyCKv4LS94xVQh7DHGif5ruVmHHYrmqu7d EOS7zgbYJFXRMhcW8MtRyCKv4LS94xVQh7DHGif5ruVmHHYrmqu7d

아까 생성한 개인 키/공개 키 쌍을 사용해 두 개의 계정을 만들고 나면, 아래와 같이 두 개의 계정이 성공적으로 등록되었음을 볼 수 있다.

$ cleos get accounts EOS7zgbYJFXRMhcW8MtRyCKv4LS94xVQh7DHGif5ruVmHHYrmqu7d
{
  "account_names": [
    "test",
    "user"
  ]
}

5. `nodeos` 설정 바꾸기

마지막으로, Hello World 메시지가 콘솔에 직접 표시되도록 nodeos의 설정을 바꿔 주어야 한다. 최신 EOS에서는 기본적으로 표준 출력이 표시되지 않게 설정되어 있어, config.ini 파일에서 contracts-console 항목을 바꿔 준다.

cd ~/.local/share/eosio/nodeos/config/

이 디렉토리에서 config.ini를 열고, 중간의 contracts-console = false를 contracts-console = true로 바꾸어 준다. 이후 nodeos를 재시작하자.

nodeos -e -p eosio --plugin eosio::chain_api_plugin --plugin eosio::history_api_plugin

6. 스마트 컨트랙트 구동하기

드디어 스마트 컨트랙트를 구동할 차례이다! 아까 전, 스마트 컨트랙트를 빌드했던 디렉토리로 돌아가서 아래 작업을 진행하자.

$ cleos set contract test . hello.wasm hello.abi -p test
$ cleos push action test greet '["Belli Dura Despicio"]' -p user
executed transaction: 54ad914ea76831ac248fd1930461aff03089cf01e6cfa87e08fc44cec6831969  104 bytes  725 us
#    test <= test::greet               {"user":"user"}
>> Hello world, hello Belli Dura Despicio!

이는 nodeos이 실행되고 있는 터미널에서도 확인할 수 있다. 아래의 로그를 보면 트랜잭션 하나가 블록에 포함되었음을 알 수 있다.

…
2018-09-06T20:53:41.069 thread-0   apply_context.cpp:28          print_debug          ]
[(test,greet)->test]: CONSOLE OUTPUT BEGIN =====================
Hello world, hello Belli Dura Despicio!
[(test,greet)->test]: CONSOLE OUTPUT END   =====================
2018-09-06T20:53:41.500 thread-0   producer_plugin.cpp:1302      produce_block        ] Produced block 000147bc376605d3... #83900 @ 2018-09-06T20:53:41.500 signed by eosio [trxs: 1, lib: 83899, confirmed: 0]
…

DPOS: Tradeoffs and Attacks

이 부분은 부록같은 느낌으로 작성하였다. 여기서는 DPOS의 장단점과 공격 가능한 요소들을 살펴본다.

DPOS Tradeoffs

A. 블록 프로듀서와 탈중앙화

DPOS는 지분을 가진 사람이 일부 사람에게 자신의 결정권을 위임하기에, 'Controlled Semi-Centralization'이라고 할 수 있다. 여기서 우리는 기존의 PoW나 PoS에서 항상 문제가 되어 온 '의사 결정의 효율성과 속도'라는, 중앙화의 장점을 잡을 수 있게 되고, 또 지분을 가진 사람으로부터의 선출이라는 점에서 탈중앙화의 장점 또한 잡게 된다. 하지만 그래도 기존의 방식과 비교해보았을 때, "중앙화 된다"는 점에서 일부 사람들은 DPOS를 지지하지 않는다. 또한 '중앙화의 정도'가 결정되는 중요한 요소인 "몇 명의 후보를 블록 생산자로 선출해야 적당히 효율과 탈중앙화를 모두 잡을 수 있는가" 또한 중요한 문제가 된다.

B. 체인 내부 통치 (On-Chain Governance)^[각주:7]

두 통치 방식.

On-Chain Governance는 블록체인의 정책을 결정하는 권위체가 블록체인 내부에 있다는 것을 의미한다. EOS에서는 선출된 21명의 BP가 EOS의 정책과 방향성에 대해 토의하고 결정한다. 이는 비트코인 개발자들이 비트코인 블록체인 외부에서 활동하며 메일링 리스트를 두고 비트코인 체계를 관리하는 Off-Chain Governance와는 다른 방식이다. DPOS는 모든 블록체인 네트워크가 정치적이고, 정치 과정을 공식화하려고 한다는 것을 인정하는 방식이다. On-Chain Governance는 일부 사람들이 문제를 제기하기도 하지만, 이는 DPOS의 핵심 특징이다. DPOS는 공개적이고 분산된 구조이며, 결과적으로 중앙화된 권력이 아닌, 커뮤니티의 소유이다.

결론적으로, On-Chain Governance가 다른 블록체인 운영 방식과 비교했을 때 더 나은지, 더 나쁜지는 아직 분명하지 않으며, 앞으로 계속해서 테스트되어야 한다.

Possibility of Attacks

이제 DPOS 네트워크가 어떻게 공격받을 수 있을지 생각해보고, DPOS가 그 공격 방법으로부터 안전한지도 생각해보자.

A. Nothing at Stake

Nothing at Stake 문제

DPOS에서의 NaS 문제

여기서 'At stake'라는 말은 "위험에 처하다" 라는 뜻이다. 즉, "Nothing at Stake"는 "아무것도 위험하지 않다"는 뜻이다. 이는 노드의 입장에서 말한 것인데, 어떠한 악의적인 개입으로, 유효해 보이는 블록체인이 두 개 이상 존재하게 되었을 때, 그 두 개 블록체인에 모두 블록을 생성해도 손해가 없으므로, 보상 확률을 높이기 위해 두 블록체인에 모두 블록을 생성하는 행위를 하게 된다는 것이다. 이는 본디 PoS 방식의 문제이기도 하다.

하지만 DPOS는 이런 공격에 취약하지 않다. 일정 수의 대표가 매 라운드마다 선출되어, 순서대로 블록을 생성하기 때문에 가장 긴 블록을 형성함으로써 체인에 공격을 가하기는 힘들다. 또한 다수의 대표들이 악의적으로 몰래 체인을 형성하고 있더라도, 정직한 소수의 대표들이 있다면 체인의 길이에 의한 공격은 실패가 된다.

~~물론 모든 노드가 악의적이라면...~~

B. Exploit Low Voter Turnout

PoS에서는 자신의 가진 지분에 비례하여 투표에서의 힘을 가진다. 매우 적은 지분을 가진 사람들은 투표를 하는 방법에 대해 찾아보는 그 노력에 비해 상응하는 보상을 받기는 어렵게 된다. 이런 현상으로, 10%의 지분의 블록이 투표에 참여했다고 한다면 5%의 지분을 가진 "고래"가 이를 악용하여 자신이 원하는 대로 정책을 결정할 수 있는 문제가 생긴다.

하지만 DPOS에서는 자신의 지분에서 나오는 투표권을 위임할 수 있으므로, 간접적으로 전체 투표율에 기여하게 된다. 이로써, 단순히 5%의 소유로 블록 형성에 관여할 수 있었던 '중앙화'의 위험에서 벗어나게 된다.

C. Bribing Attacks

DPOS에서는 블록 생성 권한을 토큰 소유자로부터 위임받기 때문에, 많은 사용자로부터 권한을 위임받을수록 자신이 블록 생성 노드가 될 확률이 높아지고, 더불어 채굴로 인한 보상을 받을 가능성도 커진다. 이를 이용해, 일부 노드가 "나에게 투표하면 내 채굴 보상의 일부를 나눠주겠다"며 접근했고, 일곽에서는 가장 많은 보상을 주는 노드를 알려주는 사이트까지 등장했다. 하지만 이는 DPOS 네트워크의 발전을 저해하며, 보안상 큰 문제를 야기할 수 있다. 악의적인 의도로 사용자로부터 권한을 위임받아 블록을 생성할 수 있는 것이다. 이는 실제로 스팀잇이나 리스트 등의 DPOS 기반 블록체인에서 일어났던 일이다.

하지만 우리의 EOS는 이 문제로부터 안전하다. EOS 블록체인에 참가하는 모두가 동의해야 하는 EOS 헌법에는 "투표권을 사서는 안된다^[각주:8]"라는 내용이 명시가 되어 있어, Bribing Attack을 시도하는 노드는 바로 네트워크에서 퇴출될 것이다. 또한 각 BP는 유일한 수입원인 블록 채굴 보상만으로 BP의 공약 중 하나인 "안정적인 네트워크와 유효한 블록체인을 유지한다^[각주:9]"를 이행해야 하므로, 퇴출당하지 않으려면 꽤 많은 양의 돈을 인프라 유지에 사용해야 할 것이다. 이로써 Bribing Attack은 조금 더 힘들어진다.

D. Attacks at Scale

기본적으로 블록 생산자들은 DPOS 네트워크에 자신의 CPU나 네트워크 등의 리소스를 제공한다. 여기서 문제가 발생할 수 있는 부분은 "거대한 리소스를 제공하는 BP가 블록 생산에서의 실수에 의해 쫓겨났을 때" 이다. 거대한 리소스가 한 번에 사라지면 네트워크의 능력은 현저히 떨어진다. 블록 생산 수, 제공되는 리소스 자원이 큰 폭으로 줄어들고, 전체 DPOS 네트워크는 운영에 힘이 부치게 된다. 쫓겨난 BP 대신 새로 선출된 BP가 기존의 BP와 같은 리소스 능력을 가지고 있으리라는 보장도 없다. 아직 실제 사례는 없지만, 전체 네트워크를 손상시킬 수 있는 한 가지 방법은 이와 같이 거대한 리소스를 가진 BP를 퇴출시키는 것이다.

E. Block Producers Collude

DPOS에서는 블록을 형성하는 대표자의 수가 적기 때문에 단합이 가능하다. 단합으로 저지를 수 있는 수많은 가능성 중 하나는 Censorship이다. 이들은 단합하여 마음에 들지 않지만 유효한 트랜잭션을 거부할 수 있다. 또 다른 가능성 중 하나는 프로토콜 변경이다. 악의적인 블록 제작자는 프로토콜을 변경하여 블록 생성 보상 변경, 특정 지분 소유자 추방 등 여러 일을 벌일 수 있다. EOS에서는 이를 막기 위해 21명 중 17명 이상의 동의가 있어야 프로토콜을 개정할 수 있도록 하고 있다. 또 다른 가능성 중 하나는 이중 지불 공격이다.

여러 노드들이 협의한다면 정말 못 할 일이 없게 되는 것이 DPOS의 단점이다. 소수의 블록 프로듀서가 자신의 차례에 이런 일을 벌인다면 블록은 거절 당할 것이고, 단순히 다음 블록이 몇 초 늦게 만들어지는 정도의 타격이 될 것이다. 그 소수 블록 프로듀서는 물론 자신의 명성과 미래의 수입 등 많은 부분에서 큰 타격을 입게 될 것이다. 하지만, 대다수의 BP들이 악의를 가지고 협동한다면 못할 일은 전혀 없을 것이다.

F. Distributed Denial-of-Seretvice Attack (DDoS)

DPOS의 경우, 블록을 형성하는 대표들은 IP 주소와 각 라운드마다 무작위로 결정된 블록 생성 순서가 공개되어 있기 때문에 충분히 DDoS 공격의 대상이 될 수 있다. 하지만 DPOS에는 예비 블록 프로듀서(백업 프로듀서)가 항상 대기하고 있기 때문에, DDoS 공격은 효율성이 떨어진다. 매 라운드마다 계속 BP가 바뀌므로, DDoS를 대다수의 블록 프로듀서에게 공격한다고 해도 일시적인 타격에 불과할 것이다. 참고로, EOS에서는 21명의 BP 중 한 BP가 제 기능을 못하게 되면 그 다음으로 투표를 많이 한 22번쨰 백업 프로듀서가 진짜배기 BP가 된다.

참고한 문서

EOS를 공부하면서 정말 수많은 문서를 보았다. 대부분 나보다 글을 잘 썼고, 내 글의 일부 부분은 그들 문서의 단순한 번역이 되기도 한다. 좋은 문서를 만들어 주신 모든 분들께 진심으로 감사의 말을 전하고 싶다.

이미지 출처

아래 적힌 출처 이외의 이미지는 내가 만든 이미지이다.

EOS, 블록원 로고 ー eos.io, block.one
EOS 프로그램 구조도 ー developers.eos.io
On-Chain-Governance (왼쪽 EOS DApp 도표) ー abdulqadir01@steemit
Off-Chain-Governance (오른쪽 꼭두각시 조종 손 일러스트) ー John Edward Hind
Off-Chain-Governance (오른쪽 비트코인 네트워크 도표) ー altcointoday.com
Nothing at Stake 설명 도표 (공격) ー franceos.fr
Nothing at Stake 설명 도표 (방어) ー multicoin.capital

이렇게 EOS와 DPOS에 대해서 간단히 수박겉핥기식으로 알아보았다. 다음에는 무엇을 공부해볼까...

2018년 10월 기준으로, BitShares가 1위를 가져갔다. [본문으로]
1세대는 "화폐"로서의 블록체인으로, 비트코인 등이 해당하고, 2세대는 "스마트 컨트랙트"를 등장시킨 것으로, 이더리움이 대표적이다. [본문으로]
후술하겠지만 Off-chain이란 블록체인의 정책과 방향을 결정하는 권위체가 블록체인 외부에 있음(블록체인에 참가하지 않음)을 뜻하고, On-chain은 그 반대의 개념이다. [본문으로]
출처: 2018년 8월 15일 기준이며, ~~EOS 설명 글이니 EOS를 띄워 주기 위해 좋을 때를 찍은 것이다~~ coinmetrics.io [본문으로]
2018년 10월 기준으로, 메인넷이 겪은 최대 TPS는 약 4000 TPS이다. [본문으로]
실제로 들어가는 돈이 이더리움보다 훨씬 적다고 한다. [본문으로]
On-Chain Governance는 무조건적인 DPOS의 특징은 아니지만, DPOS를 따르는 블록체인들은 DPOS를 채택하는 이유인 성능상의 문제를 살리고 DPOS의 권한 위임이라는 특징을 살리기 위해 대부분 On-Chain Governance를 채택하는 것으로 보인다. [본문으로]
이 페이지에서 EOS 헌법을 볼 수 있다. [본문으로]
이 페이지에서 EOS 메인넷의 BP가 되기 위한 BP의 약속문을 볼 수 있다. [본문으로]

Hyperledger 사용해보기

실토 — Thu, 10 Jan 2019 21:14:39 +0900

이 글은 Hexo 기반의 블로그에서 옮겨온 글이며, 원본 글은 2018년 8월 10일에 작성되었다.

지난 번 이더리움 개인 네트워크 써보기에 이어서, Hyperledger를 써보았다. 이는 여름 방학 블록체인 공부의 일환이다.

이 글의 내용으로는 Hyperledger Fabric 설치, 네트워크 실행 및 구축해보기, Hyperledger Fabric 애플리케이션 만들기를 담고 있다.

아래의 모든 코드블럭에서 사용자 계정에서 실행된 줄은 $, 루트 계정에서 실행된 줄은 >로 표기하였다.

Hyperledger

Hyperledger는 오픈소스 블록체인 기반의 원장(ledger) 및 관련 툴을 다루는 엄브렐라(우산) 구조^[각주:1]의 프로젝트이다. Hyperledger 프로젝트에 대한 보다 본격적인 설명은 이 Medium 글에 잘 적혀 있다. Medium 계정이 있는 사람이라면 들어가서 박수쳐주자.

여기서는 Hyperledger의 구현체 중 하나인 Hyperledger Fabric에서 제공하는 기본적인 기능과 예제를 사용하였다. Hyperledger Fabric에 관한 보다 본격적인 설명은 이 블로그 글의 작성자분께서 아주 잘 설명해주셨다.

Hyperledger Fabric 준비하기

요구 사항

Hyperledger Fabric 사전 요구사항에 나와 있는 프로그램들이다. 괄호 안의 버전은 이 글을 작성할 때 사용한 Archlinux에 설치된 버전이다.

Docker 엔진 17.06.2 이상 (18.05.0-ce)
이 글에서 도커를 많이 활용하게 되는데, 도커에 대한 간략한 개념은 이 블로그 글에 잘 설명되어 있다.
WSL 환경에서 Docker는 제대로 작동하지 않을 수 있으니, WSL 말고 다른 환경에서 진행하길 권장한다.
다음 단계로 넘어가기 이전에 도커 데몬 실행은 필수이다. sudo systemctl start docker 명령어로 도커 데몬을 시작할 수 있다.
Docker Compose 1.14.0 이상 (1.22.0)
node 8.9 이상 (v10.8.0 (by arch repo), v9.11.2 (by nvm))
현재 노드 10 이상은 지원되지 않는 것으로 보인다.
npm (6.3.0 (by arch repo), v5.6.0 (by nvm))
Go 1.10.x (go1.10.3)
cURL 가장 최신 버전 (7.61.0)
python 2.7 (2.7.15)
만일 커맨드라인에 python --version이라고 입력했을때 python 3 이상이 먼저 실행되어도 python 2가 설치되어 있으면 상관이 없었다. 이 글을 작성하는 도중 *.py 파일을 한 번도 본 적이 없지만, 그래도 요구사항이라고 하니 설치해주자.

이외에, Windows 사용자는 이 링크에서 추가 안내가 있다.

Hyperledger Fabric 다운로드

먼저 Hyperledger Fabric 공식 예제를 다운로드하자.

$ git clone https://github.com/hyperledger/fabric-samples
$ cd fabric-samples

그런 다음, Hyperledger Fabric을 설치하자.

$ cd scripts
$ sudo ./bootstrap.sh

위 명령어를 입력하면, 수 분 안에 도커 이미지 몇 개가 받아질 것이다. 저 bootstrap.sh, 친절하게 마지막에 설치된 Hyperledger Fabric 이미지 리스트를 출력해준다.

hyperledger/fabric-ca          1.2.0               66cc132bd09c        5 weeks ago         252MB
hyperledger/fabric-ca          latest              66cc132bd09c        5 weeks ago         252MB
hyperledger/fabric-tools       1.2.0               379602873003        5 weeks ago         1.51GB
hyperledger/fabric-tools       latest              379602873003        5 weeks ago         1.51GB
hyperledger/fabric-ccenv       1.2.0               6acf31e2d9a4        5 weeks ago         1.43GB
hyperledger/fabric-ccenv       latest              6acf31e2d9a4        5 weeks ago         1.43GB
hyperledger/fabric-orderer     1.2.0               4baf7789a8ec        5 weeks ago         152MB
hyperledger/fabric-orderer     latest              4baf7789a8ec        5 weeks ago         152MB
hyperledger/fabric-peer        1.2.0               82c262e65984        5 weeks ago         159MB
hyperledger/fabric-peer        latest              82c262e65984        5 weeks ago         159MB
hyperledger/fabric-zookeeper   0.4.10              2b51158f3898        5 weeks ago         1.44GB
hyperledger/fabric-zookeeper   latest              2b51158f3898        5 weeks ago         1.44GB
hyperledger/fabric-kafka       0.4.10              936aef6db0e6        5 weeks ago         1.45GB
hyperledger/fabric-kafka       latest              936aef6db0e6        5 weeks ago         1.45GB
hyperledger/fabric-couchdb     0.4.10              3092eca241fc        5 weeks ago         1.61GB
hyperledger/fabric-couchdb     latest              3092eca241fc        5 weeks ago         1.61GB

방금 받았으니 각 latest 이미지는 각 버전에서 태그만 다른 이미지일 것이다. 대략 8GB정도의 저장 공간이 소모되었다.

Hyperledger Fabric 구동하기

BYFN(Building Your First Network) 시나리오 예제 실행해보기

드디어, 첫 Hyperledger 네트워크를 구축해 볼 때이다. 아무것도 몰라도 좋다. fabric-samples/first-network 디렉토리 안의 byfn.sh를 실행해서 간단한 네트워크를 구성해보자.

$ sudo ./byfn.sh up

약 1~2분간 무언가가 실행되고, 마지막에 이 메시지가 뜨면 정상이다.

========= All GOOD, BYFN execution completed ===========


 _____   _   _   ____
| ____| | \ | | |  _ \
|  _|   |  \| | | | | |
| |___  | |\  | | |_| |
|_____| |_| \_| |____/

이제, byfn.sh가 도대체 무슨 행동을 한 건지 살펴보자. 먼저, byfn.sh를 뜯어보면, 방금 실행시킨 코드는 아래와 같다.

function networkUp() {

    # 도커 이미지 버전 확인
    checkPrereqs

    # fabric-samples/first-network/crypto-config 폴더가 없으면 아티팩트를 생성한다.
    # 여기서 아티팩트란 "설정 기록 파일", 즉 "설정 파일"이라고 보면 된다.
    if [ ! -d "crypto-config" ]; then
        generateCerts
        replacePrivateKey
        generateChannelArtifacts
    fi

    # CouchDB 사용 옵션 여부에 따라 다르게 도커 이미지를 제작한다.
    # 우리는 그런 옵션을 주지 않았으므로, 아래쪽 else 명령어로 도커 이미지가 제작되었을 것이다.
    if [ "${IF_COUCHDB}" == "couchdb" ]; then
        IMAGE_TAG=$IMAGETAG docker-compose -f $COMPOSE_FILE -f $COMPOSE_FILE_COUCH up -d 2>&1
    else
        # 별다른 옵션을 주지 않았으므로, 아래 $COMPOSE_FILE 변수는 스크립트 초반에 자동으로
        # 설정된 'docker-compose-cli.yaml' 일 것이다.
        # 이 파일은 fabric-samples/first-network 디렉토리에 존재한다.
        # docker-compose 명령어를 알기 쉽게 분석하면 아래와 같다.
        #
        #   'docker-compose'   : docker-compose 프로그램에게 아래의 동작을 시킨다.
        #   '-f $COMPOSE_FILE' : docker-compose-cli.yaml 파일을 주고 도커 이미지를
        #                        만든다.
        #   'up -d'            : 만들어진 도커 이미지를 컨테이너로 백그라운드에서
        #                        실행시킨다.
        #
        # 참고로, 2>&1은 (간단히 말해서) 에러 메시지도 가감없이 다 보여주라는 뜻이다.
        IMAGE_TAG=$IMAGETAG docker-compose -f $COMPOSE_FILE up -d 2>&1
    fi

    # docker-compose가 정상 (0)으로 끝나지 않았으면 오류 메시지를 출력한다.
    if [ $? -ne 0 ]; then
        echo "ERROR !!!! Unable to start network"
        exit 1
    fi

    # 이제 위의 docker-compose에서 실행시켰던 도커 컨테이너들 중 'cli' 이미지에 접속해서
    # fabric-samples/first-network/scripts/script.sh를 실행하게 된다.
    docker exec cli scripts/script.sh $CHANNEL_NAME $CLI_DELAY $LANGUAGE $CLI_TIMEOUT $VERBOSE

    # 도커가 정상 (0)으로 끝나지 않았으면 오류 메시지를 출력한다.
    if [ $? -ne 0 ]; then
        echo "ERROR !!!! Test failed"
        exit 1
    fi
}

살펴보니 위의 코드는 사전 준비 작업일 뿐, 실제 몸통은 fabric-samples/first-network/scripts/script.sh에 있어보인다. 위에서 docker-compose 명령어로 만들었던 도커 컨테이너들은 sudo docker ps -a 명령으로 확인할 수 있었고, 9개의 컨테이너가 실행중이었다. 이번엔 script.sh를 살펴보자. 이를 참고해서 이제 직접 Hyperledger 네트워크를 만들어 볼 것이다.

# (전략)
# 아래에서 사용되는 함수들은 script.sh 혹은 같은 폴더에서 확인할 수 있는 utils.sh에 있다.

## 채널 만들기.
## 채널이라 함은 'Hyperledger Fabric 네트워크'라고 해도 되고, 둘 이상의 네트워크 구성원이 있는
## 논리적인 개념을 "채널"이라 한다. 채널에는 구성원('조직'), 그리고 그 '조직' 당 하나 이상의 중계
## 피어(anchor peer), 채널 정책, 분산 공유 원장, 원장을 관리하는 체인코드 애플리케이션, 주문
## 서비스 노드 등을 포함한다. 많은 개념들이 나왔지만 여기서 모든걸 다 알 필요는 없다. 일단은 그냥
## 그렇구나 하고 넘어가도 좋다.
echo "Creating channel..."
createChannel

## 아까 docker-compose로 만든 피어가 이 채널에 들어오도록 한다.
echo "Having all peers join the channel..."
joinChannel

## 등록한 피어를 각 조직의 중계 피어로 설정한다.
echo "Updating anchor peers for org1..."
updateAnchorPeers 0 1
echo "Updating anchor peers for org2..."
updateAnchorPeers 0 2

## peer0.org1, peer0.org2 피어에 체인코드 애플리케이션을 설치한다.
echo "Installing chaincode on peer0.org1..."
installChaincode 0 1
echo "Install chaincode on peer0.org2..."
installChaincode 0 2

## peer0.org2의 체인코드를 채널에 인스턴스화한다.
## 인스턴스화를 도커에 비유하자면, 도커 이미지로 도커 컨테이너를 만드는 것으로 보면 된다. 이 함수
## 소스 코드를 보면 "a"에 "100", "b"에 200을 넣어 초기화하는 구문이 포함되어있다.
echo "Instantiating chaincode on peer0.org2..."
instantiateChaincode 0 2

## peer0.org1의 체인코드를 채널에서 조회한다.
## chaincodeQuery 함수에서는 "a" 값을 찾아 주어진 예상값과 비교하는 절차가 함수 막바지에
## 포함되어 있다. 즉, 여기서 "a"와 100을 비교하는 것이다. 위의 체인코드가 인스턴스화에 성공했다면
## "a"에는 100이 저장되어 있을 것이고, 이 절차는 잘 넘어갈것이다.
echo "Querying chaincode on peer0.org1..."
chaincodeQuery 0 1 100

## peer0.org1과 peer0.org2의 체인코드를 호출한다.
## chaincodeInvoke 함수 소스 코드를 살펴보면 'mycc' 라는 체인코드를 호출하고 있는데, 이
## mycc라는 체인코드는 인자 3개를 받아 첫번째 인자에서 세번째 인자 만큼을 빼고, 두번째 인자에
## 세번째 인자 만큼을 더하는 것이다. chaincodeInvoke 함수에서는 이 mycc에게
## '{"Args":["invoke","a","b","10"]}'라는 인자를 넘겨주어, "a"에서 10을 빼어 "b"에게
## 더해주게된다. 진짜로 이렇게 되었는지, 아래쪽 chaincodeQuery 함수에서 확인해보게 될 것이다.
## 여기서 언급한 'mycc'의 체인코드의 소스 코드는 다음 링크에 있다: https://git.io/fN7hO
echo "Sending invoke transaction on peer0.org1 peer0.org2..."
chaincodeInvoke 0 1 0 2

## peer1.org2에 체인코드 애플리케이션을 설치한다.
echo "Installing chaincode on peer1.org2..."
installChaincode 1 2

## peer1.org2의 체인코드를 채널에서 조회한다.
## 위에서 'mycc' 체인코드를 호출했기에, "a"는 90, "b"는 100이 되어있을 것이다.
## 따라서, 여기선 "a"와 90을 비교하도록 chaincodeQuery 함수가 호출되었다.
echo "Querying chaincode on peer1.org2..."
chaincodeQuery 1 2 90

echo
echo "========= All GOOD, BYFN execution completed =========== "

# (후략)

script.sh는 간단히 채널과 피어를 만들고, 체인코드 조회와 호출이 정상 작동하는지 테스트해보는 것이었다. 이제 직접 네트워크를 만들어보기 위해, BYFN 네트워크를 종료하자. 아래 명령어를 입력하면 byfn.sh에서 생성한 도커 컨테이너까지 말끔히 없애준다.

$ sudo ./byfn.sh down

직접 Hyperledger 네트워크 빌드하기

이제 위 first-network의 byfn.sh에서 자동으로 수행한 작업을 수동으로 수행해보면서 나의 Hyperledger 네트워크를 직접 만들어보자. 먼저 적당한 곳에 작업 디렉토리를 따로 하나 생성해주자.

$ mkdir my-network
$ cd my-network

그리고 cryptogen 명령어를 이용해서 Hyperledger Fabric 인증서를 만들어주기 위해, cryptogen의 설정파일인 crypto-config.yaml 파일을 아래와 같이 작성하자. YAML 형식을 모른다면, 이 글에 간단하게 잘 적혀있다.

# 이 파일은 fabric-samples/first-network/crypto-config.yaml의 한글 번역본이며, 일부
# 자체 조사하여 설명을 첨했다.
# -------------------------------------------------------------------------
# "OrdererOrgs" - 다른 원고 노드(orderer node)를 관리하는 조직의 정의
# -------------------------------------------------------------------------
OrdererOrgs:
  # -------------------------------------------------------------------------
  # Orderer
  # -------------------------------------------------------------------------
  - Name: Orderer
    Domain: example.com
    # -------------------------------------------------------------------------
    # "Specs"
    # -------------------------------------------------------------------------
    # Specs는 조직의 특성을 정의하는 행렬이다. 각 특성 항목은 두개의 필드로 구성되어있다.
    #   - Hostname:   (필수) 도메인을 제외한 호스트 이름
    #   - CommonName: (선택) 기본 설정 "{{Hostname}}.{{Domain}}"을 덮어쓰는 FQDN
    # -------------------------------------------------------------------------
    Specs:
      - Hostname: orderer
# -------------------------------------------------------------------------
# "PeerOrgs" - 피어 노드를 관리하는 조직의 정의
# -------------------------------------------------------------------------
PeerOrgs:
  # -------------------------------------------------------------------------
  # Org1
  # -------------------------------------------------------------------------
  - Name: Org1
    Domain: org1.example.com
    # -------------------------------------------------------------------------
    # "EnableNodeOUs"
    # -------------------------------------------------------------------------
    # Hyperledger Fabric MSP에서 해당 노드에 대해 신원 분류를 할지 말지를 결정하는 항목이다.
    # 아래 문서가 이 변수의 정확한 사용에 대해 알 수 있는 유일한 문서인데, 보아도 정확히 어떤
    # 작용을 하는지 아직 이해할 수 없었다.
    # https://hyperledger-fabric.readthedocs.io/en/release-1.1/msp.html
    # -------------------------------------------------------------------------
    EnableNodeOUs: true
    # -------------------------------------------------------------------------
    # "Specs" - 위에서 설명한 Specs 항목을 이곳에도 지정할 수 있다.
    # -------------------------------------------------------------------------
    # "Template"
    # -------------------------------------------------------------------------
    # 템플릿으로부터 1개 이상의 호스트를 자동으로 만들 수 있게 하는 옵션이다. 호스트 이름은
    # 기본적으로 peer%d 형식으로, 0 부터 지정개수 - 1 까지 지정된다. 아래와 같은 옵션을 지정할
    # 수 있다.
    #   - Count:    생성할 호스트의 수
    #   - Start:    호스트 번호 세기가 시작하는 숫자
    #   - Hostname: 지정하는 호스트 이름이다. (기본값: {{.Prefix}}{{.Index}})
    # 참고: 위의 "Specs" 와 이 "Template"을 모두 활용한다면 같은 이름의 호스트가 생성될 수
    # 있으므로 이름 충돌에 주의해야한다.
    # -------------------------------------------------------------------------
    Template:
      Count: 2
    # -------------------------------------------------------------------------
    # "Users"
    # -------------------------------------------------------------------------
    # 옵션은 한 가지다.
    #   - Count: 관리자(Admin) 이외의 유저 수
    # -------------------------------------------------------------------------
    Users:
      Count: 1
  # -------------------------------------------------------------------------
  # Org2: 위의 Org1과 같은 방법으로 옵션을 지정하였다.
  # -------------------------------------------------------------------------
  - Name: Org2
    Domain: org2.example.com
    EnableNodeOUs: true
    Template:
      Count: 2
    Users:
      Count: 1

이제 이 파일을 cryptogen 프로그램으로 넣어주자. 나는 fabric-samples/my-network 디렉토리에서 진행했다. 자신이 만든 작업 디렉토리와 fabric-samples/bin 디렉토리의 상대 위치를 잘 살펴가며 진행하자.

$ ../bin/cryptogen generate --config=./crypto-config.yaml
org1.example.com
org2.example.com

이제 crypto-config라는 디렉토리가 작업 디렉토리 안에 생성되었을 것이다. 이제는 Hyperledger Fabric 네트워크(채널)의 첫 블록(제네시스 ~~태초마을~~ 블록)을 만들자. configtxgen 프로그램에 넣어줄 설정 파일을 먼저 만들어야 한다. configtx.yaml 파일 안에 아래의 내용을 입력하자.

# 이 파일은 fabric-samples/first-network/configtx.yaml의 복사본이며, 자세한 주석은
# 삭제하였다.
Organizations:
    - &OrdererOrg
        Name: OrdererOrg
        ID: OrdererMSP
        MSPDir: crypto-config/ordererOrganizations/example.com/msp
    - &Org1
        Name: Org1MSP
        ID: Org1MSP
        MSPDir: crypto-config/peerOrganizations/org1.example.com/msp
        AnchorPeers:
            - Host: peer0.org1.example.com
              Port: 7051
    - &Org2
        Name: Org2MSP
        ID: Org2MSP
        MSPDir: crypto-config/peerOrganizations/org2.example.com/msp
        AnchorPeers:
            - Host: peer0.org2.example.com
              Port: 7051
Capabilities:
    Global: &ChannelCapabilities
        V1_1: true
    Orderer: &OrdererCapabilities
        V1_1: true
    Application: &ApplicationCapabilities
        V1_2: true
Application: &ApplicationDefaults
    Organizations:
Orderer: &OrdererDefaults
    OrdererType: solo
    Addresses:
        - orderer.example.com:7050
    BatchTimeout: 2s
    BatchSize:
        MaxMessageCount: 10
        AbsoluteMaxBytes: 99 MB
        PreferredMaxBytes: 512 KB
    Kafka:
        Brokers:
            - 127.0.0.1:9092
    Organizations:
Profiles:
    TwoOrgsOrdererGenesis:
        Capabilities:
            <<: *ChannelCapabilities
        Orderer:
            <<: *OrdererDefaults
            Organizations:
                - *OrdererOrg
            Capabilities:
                <<: *OrdererCapabilities
        Consortiums:
            SampleConsortium:
                Organizations:
                    - *Org1
                    - *Org2
    TwoOrgsChannel:
        Consortium: SampleConsortium
        Application:
            <<: *ApplicationDefaults
            Organizations:
                - *Org1
                - *Org2
            Capabilities:
                <<: *ApplicationCapabilities

이제 configtxgen을 실행해서 태초마을 블록을 생성하자.

$ mkdir channel-artifacts
$ ../bin/configtxgen -profile TwoOrgsOrdererGenesis -outputBlock ./channel-artifacts/genesis.block -channelID mychannel

이후 차례로 채널 구성 트랜잭션을 보내 채널 구성을 완료하자.

$ ../bin/configtxgen -profile TwoOrgsChannel -outputCreateChannelTx ./channel-artifacts/channel.tx -channelID mychannel
$ ../bin/configtxgen -profile TwoOrgsChannel -outputAnchorPeersUpdate ./channel-artifacts/Org1MSPanchors.tx -channelID mychannel -asOrg Org1MSP
$ ../bin/configtxgen -profile TwoOrgsChannel -outputAnchorPeersUpdate ./channel-artifacts/Org2MSPanchors.tx -channelID mychannel -asOrg Org2MSP

이제 기본 도커 설정 파일을 작성하고 Hyperledger Fabric 네트워크를 실행하자. 도커 설정도 first-network의 것을 그대로 가져왔으며, docker-compose의 설정 파일을 다루는 것은 이 글의 범주에서 벗어나므로 크게 다루지는 않는다. 다만, 아래 명령을 수행함으로써 하나의 orderer 컨테이너(노드)와 네 개의 peer 컨테이너(노드)가 생성된다.

$ cp ../first-network/base . -r
$ cp ../first-network/docker-compose-cli.yaml .
$ sudo env IMAGE_TAG=latest CHANNEL_NAME=mychannel docker-compose -f docker-compose-cli.yaml up -d
WARNING: The COMPOSE_PROJECT_NAME variable is not set. Defaulting to a blank string.
Creating network "my-network_byfn" with the default driver
Creating volume "my-network_orderer.example.com" with default driver
Creating volume "my-network_peer0.org1.example.com" with default driver
Creating volume "my-network_peer1.org1.example.com" with default driver
Creating volume "my-network_peer0.org2.example.com" with default driver
Creating volume "my-network_peer1.org2.example.com" with default driver
Creating peer1.org2.example.com ... done
Creating peer0.org1.example.com ... done
Creating peer1.org1.example.com ... done
Creating peer0.org2.example.com ... done
Creating orderer.example.com    ... done
Creating cli                    ... done

이제 docker ps -a 명령어로 확인하면 6개의 도커 이미지가 돌아가고 있음을 확인할 수 있을 것이다.

지금부터는 도커에 접속하여 위의 first-network에서 했던 테스트를 직접 해보자. 먼저 도커에 접속해본다. 참고로, cli 도커는 우분투 환경을 기반으로 구성되어있다. (다른 컨테이너는 확인해보지 않았다.)

$ sudo docker exec -it cli bash
> (이 부분은 곧 업데이트할 예정이다.)

이렇게, 씹고 뜯고 맛보고 즐기고 볼 장 다 봤으면 아래의 명령어로 나의 네트워크를 종료하자.

$ sudo docker-compose -f docker-compose-cli.yaml down --volumes --remove-orphans

Hyperledger Fabric 애플리케이션 실행해보기

마지막으로, Hyperledger Fabric 예제 애플리케이션 fabcar를 구동해보자. 먼저 아래 코드를 fabric-samples/fabcar 디렉토리에서 실행하자.

$ sudo ./startFabric.sh

1분 가량의 작업이 끝나면 다음과 같은 메시지가 나타난다.

Start by installing required packages run 'npm install'
Then run 'node enrollAdmin.js', then 'node registerUser'

The 'node invoke.js' will fail until it has been updated with valid arguments
The 'node query.js' may be run at anytime once the user has been registered

저들의 말에 순순히 따라주자. 먼저 npm i 명령어를 입력하여 package.json에 적힌 요구 npm 패키지를 받아오자.

$ npm i

위 명령 실행 도중에 나타나는 cc의 warning과 note는 신경쓰지 않아도 좋다. (ERR가 발생하면 더이상 진행이 불가능하다. 아래 문제 해결에 해결법이 적혀 있다.) 의존 패키지 설치가 완료되었으면 Admin과 user1을 영입할 차례이다. 아래 명령어로 관리자와 user1을 만들어주자.

$ node enrollAdmin.js
$ node registerUser.js

그런 다음, 간단하게 쿼리(조회)를 해보자.

$ node query.js
(...)
Response is  [
    {"Key":"CAR0", "Record":{"colour":"blue","make":"Toyota","model":"Prius","owner":"Tomoko"}},
    {"Key":"CAR1", "Record":{"colour":"red","make":"Ford","model":"Mustang","owner":"Brad"}},
    {"Key":"CAR2", "Record":{"colour":"green","make":"Hyundai","model":"Tucson","owner":"Jin Soo"}},
    {"Key":"CAR3", "Record":{"colour":"yellow","make":"Volkswagen","model":"Passat","owner":"Max"}},
    {"Key":"CAR4", "Record":{"colour":"black","make":"Tesla","model":"S","owner":"Adriana"}},
    {"Key":"CAR5", "Record":{"colour":"purple","make":"Peugeot","model":"205","owner":"Michel"}},
    {"Key":"CAR6", "Record":{"colour":"white","make":"Chery","model":"S22L","owner":"Aarav"}},
    {"Key":"CAR7", "Record":{"colour":"violet","make":"Fiat","model":"Punto","owner":"Pari"}},
    {"Key":"CAR8", "Record":{"colour":"indigo","make":"Tata","model":"Nano","owner":"Valeria"}},
    {"Key":"CAR9", "Record":{"colour":"brown","make":"Holden","model":"Barina","owner":"Shotaro"}}
]

이제 원장(ledger)을 업데이트해보자. invoke.js 파일을 열어 chaincodeId와 fcn 등을 담고 있는 var request를 아래와 같이 수정한다.

// createCar chaincode function - requires 5 args, ex: args: ['CAR12', 'Honda', 'Accord', 'Black', 'Tom'],
// changeCarOwner chaincode function - requires 2 args , ex: args: ['CAR10', 'Dave'],
// must send the proposal to endorsing peers
var request = {
    chaincodeId: 'fabcar',
    fcn: 'createCar',
    args: ['CAR10', 'Chevy', 'Volt', 'Red', 'Nick'],
    chainId: 'mychannel',
    txId: tx_id
};

이제 invoke.js를 실행한 뒤(node invoke.js), query.js 파일을 열어 const request를 아래와 같이 수정한다.

const request = {
    chaincodeId: 'fabcar',
    fcn: 'queryCar',
    args: ['CAR10']
};

이제 query.js를 실행시키면 아래와 같은 결과가 나온다.

$ node query.js
(...)
Response is  {"colour":"Red","make":"Chevy","model":"Volt","owner":"Nick"}

아까 invoke.js를 통해 추가한 CAR10이 제대로 추가되었음을 확인할 수 있다. 이제 아래 명령어로 생성된 도커를 지우고 모든 것을 끝내자.

# fabric-samples/basic-network 디렉토리로 이동
$ cd ../basic-network
# fabcar에서 이용한 basic-network를 종료하고 삭제
$ sudo ./teardown.sh

문제 해결

`bootstrap.sh` 실행 중 문제 발생

Cannot connect to the Docker daemon

Warning: failed to get default registry endpoint from daemon (Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?). Using system default: https://index.docker.io/v1/
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

만일 위와 같은 메시지가 뜬다면 꼭 sudo systemctl start docker 혹은 sudo service docker start를 해주자. 도커 데몬이 실행중이지 않아서 발생하는 오류이다.

Got permission denied

Warning: failed to get default registry endpoint from daemon (Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get http://%2Fvar%2Frun%2Fdocker.sock/v1.37/info: dial unix /var/run/docker.sock: connect: permission denied). Using system default: https://index.docker.io/v1/
Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Post http://%2Fvar%2Frun%2Fdocker.sock/v1.37/images/create?fromImage=hyperledger%2Ffabric-peer&tag=1.2.0: dial unix /var/run/docker.sock: connect: permission denied
Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Post http://%2Fvar%2Frun%2Fdocker.sock/v1.37/images/hyperledger/fabric-peer:1.2.0/tag?repo=hyperledger%2Ffabric-peer&tag=latest: dial unix /var/run/docker.sock: connect: permission denied

도커 데몬 소켓을 가져올 권한이 없어서 발생하는 오류이다. bootstrap.sh를 관리자 권한(sudo)으로 실행해주자.

`byfn.sh` 실행 중 문제 발생

Couldn't connect to Docker daemon

ERROR: Couldn't connect to Docker daemon at http+docker://localhost - is it running?

If it's at a non-standard location, specify the URL with the DOCKER_HOST environment variable.
ERROR !!!! Unable to start network

byfn.sh가 도커 데몬 소켓을 가져오지 못해 발생하는 오류이다. byfn.sh를 관리자 권한(sudo)으로 실행해주자.

`configtxgen` 실행 중 문제 발생

Could not find configtx.yaml.

2018-08-11 05:26:53.159 KST [common/tools/configtxgen/localconfig] Load -> CRIT 003 Error reading configuration:  Unsupported Config Type ""
2018-08-11 05:26:53.159 KST [common/tools/configtxgen] func1 -> ERRO 004 Could not find configtx.yaml. Please make sure that FABRIC_CFG_PATH or --configPath is set to a path which contains configtx.yaml

configtxgen에서 configtx.yaml 파일을 찾지 못해 벌어진 일이다. --configPath 옵션은 오류 메시지와 달리 현재 버전에서 -configPath로 하이픈이 하나 줄어들었고, 또한 그 역할은 설정 파일의 위치를 지정하는 것이 아닌 configtx.yaml이 들어있는 디렉터리를 지정하는 옵션이므로, 설정 파일 이름은 꼭 configtx.yaml로 해주도록 하고, 되도록이면 해당 configtx.yaml 파일이 들어있는 디렉토리에서 configtxgen 명령을 실행하자.

Error writing genesis block

2018-08-11 05:42:53.723 KST [common/tools/configtxgen] main -> CRIT 00c Error on outputBlock: Error writing genesis block: open ./channel-artifacts/genesis.block: no such file or directory

파일을 만드려는 디렉토리가 존재하지 않아 발생하는 오류이다. mkdir 명령어로 channel-artifacts 디렉토리를 먼저 생성해주자.

`npm i` 실행 중 문제 발생

node-pre-gyp ERR!

node-pre-gyp ERR! Tried to download(403): https://storage.googleapis.com/grpc-precompiled-binaries/node/grpc/v1.10.1/node-v64-linux-x64-glibc.tar.gz
node-pre-gyp ERR! Pre-built binaries not found for grpc@1.10.1 and node@10.8.0 (node-v64 ABI, glibc) (falling back to source compile with node-gyp)
node-pre-gyp ERR! Pre-built binaries not installable for grpc@1.10.1 and node@10.8.0 (node-v64 ABI, glibc) (falling back to source compile with node-gyp)
node-pre-gyp ERR! Hit error Connection closed while downloading tarball file

grpc가 최신 node 버전에 대응하지 않아서 발생한 문제이다. node 9, npm 5에서 정상적으로 작동하니, node 10을 이용하고 있다면 아래와 같이 nvm을 이용하여 낮은 버전의 node를 사용하자.

# 아래 끝 부분에는 자신이 이용하는, bash 계열의 쉘을 적자. 딱히 없다면 그냥 bash로 두면 된다.
$ curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.33.11/install.sh | bash
$ export NVM_DIR="$HOME/.nvm"
$ [ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"
$ [ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion"
$ nvm install 9
$ nvm use 9
# 이후 이 쉘에서 fabric-samples/fabcar 디렉토리로 가 node와 npm 작업을 수행한다.

참고로, nvm의 사용은 fish 에서 지원되지 않는다. 혹시 fish를 사용중이라면 zsh나 bash에서 nvm을 설치 및 실행하자.

`node invoke.js` 실행 중 문제 발생

Promise is rejected

error: [client-utils.js]: sendPeersProposal - Promise is rejected: Error: Invalid Smart Contract function name.

참고한 문서

'표준안' 만을 정의하는 하나의 메인 프로젝트를 중심으로, 그 표준안을 구현한 여러 서브 프로젝트가 있는 프로젝트의 형태를 말한다. [본문으로]

이더리움 개인 네트워크 써보기

실토 — Thu, 10 Jan 2019 20:58:47 +0900

이 글은 Hexo 기반의 블로그에서 옮겨온 글이며, 원본 글은 2018년 7월 26일에 작성되었다.

이 글은 지난 글에 이어서 개인 이더리움 네트워크를 활용해보면서 남기는 기록이다.

시작 상태

이더리움 개인 네트워크 설정 이후로, Javascript IPC에서 현재 상황을 알아보면 다음과 같다.

> eth.accounts //등록된 계좌들
[]
> eth.mining //현재 내가 채굴중인지 여부
false
> net.peerCount //이 네트워크에서 나와 연결된 다른 피어의 수
0

계좌 만들고 채굴하기

계좌 만들기

먼저, 아래의 명령어로 계좌를 만들 수 있다. 적당한 계좌 비밀번호를 입력하면 된다.

> personal.newAccount()
Passphrase:
Repeat passphrase:
"0x2f2ae2b466b08758a29f74f5ecae6d7114b2d562"

eth.accounts 명령어로 만든 계좌가 계좌 목록에 올라갔음을 확인할 수 있다.

참고로, personal.newAccount 함수로 계좌를 만들면 geth의 데이터 디렉토리의 keystore 디렉토리 안에 개인 키 파일이 생성된다. 앞으로 사용할 개인 키는 이 곳에서 확인할 수 있다.

계좌 잔액 확인

혹시라도 시스템 오류가 생겨 처음 만든 내 계좌에 돈이 충전되어 있을 지 모르니 확인해보자.

> eth.getBalance("0x2f2ae2b466b08758a29f74f5ecae6d7114b2d562")
0

꿈 깨자. 그럴 일 없다.

내 계좌로 채굴 시작하기

역시 돈을 벌려면 일을 해야 하는 법이다. 채굴을 시작하려면 먼저 coinbase 주소를 설정해야 하는데, 아래와 같이 할 수 있다.

> miner.setEtherbase("0x2f2ae2b466b08758a29f74f5ecae6d7114b2d562") //coinbase 설정
true
> eth.coinbase //coinbase 확인
"0x2f2ae2b466b08758a29f74f5ecae6d7114b2d562"

처음이라면 그저 eth.coinbase라고 입력하는 것 만으로 자동으로 coinbase를 설정할 수 있다.

이제 miner.start() 명령어를 입력하여 채굴을 해 보자.

아래와 같은 로그가 뜨면 블록이 하나 만들어 진 것이다. (실제 로그 출력은 아마 number가 뒤죽박죽 섞여 있을 것이다.)

INFO [07-26|16:21:13.424] Commit new mining work                   number=76 txs=0 uncles=0 elapsed=150.49µs
INFO [07-26|16:21:13.946] Successfully sealed new block            number=76 hash=320aac…7a0d4e
INFO [07-26|16:21:13.947]   mined potential block                  number=76 hash=320aac…7a0d4e
INFO [07-26|16:21:22.677]   block reached canonical chain          number=76 hash=320aac…7a0d4e

채굴을 끝내는 것은 miner.stop() 명령어로 할 수 있다. 참고로, DAG를 만들고 있을 때 이 명령어를 입력한다면 DAG 생성 과정이 끝난 후에 완전히 채굴이 멈추게 된다. DAG의 개념에 관해서는 이 잘 정리된 글을 추천한다.

채굴을 끝낸 다음에는 나의 잔액을 eth.getBalance("0x2f2ae...") 명령어로 다시 확인해보자. 나는 250000000000000000000이 들어와 있었다... 떼부자다...

거래(트랜잭션) 만들기

계좌 잠금 해제

이 계좌로 경제 활동을 하려면 계좌를 잠금 해제해야 하는데, 쓰려고 의도하지 않은 계좌로 행동을 해버리는 사고를 막기 위해 계좌 잠금의 기능이 있다고 한다. 아래와 같이 잠금 해제할 수 있다.

> personal.unlockAccount("0x2f2ae2b466b08758a29f74f5ecae6d7114b2d562")
Unlock account 0x2f2ae2b466b08758a29f74f5ecae6d7114b2d562
Passphrase:
true

나중에 작업이 끝나면 꼭 personal.lockAccount("0x2f2ae...") 같은 명령어로 계좌를 다시 잠구도록 하자.

코인 보내기

이 과정을 진행하기 전, 위의 계좌 만들기 부분과 같은 방법으로 계좌를 하나 더 생성했다. 이 계좌의 주소는 0xb0f3506ad5cb776bccb521a3da9ef6026394cbf9이다.

이제 트랜잭션을 만들 차례이다. eth.sendTransaction 함수를 이용해서 트랜잭션을 만들어 보내자. 아래는 20 ether를 보내는 트랜잭션을 생성하는 예시이다.

> eth.sendTransaction(
... {
...... from : "0x2f2ae2b466b08758a29f74f5ecae6d7114b2d562",
...... to   : "0xb0f3506ad5cb776bccb521a3da9ef6026394cbf9",
...... value: web3.toWei(20, "ether")
...... }
... );
INFO [07-26|17:10:42.321] Submitted transaction                    fullhash=0x03ab851182a5c906aee4cb6c0d0f16fedadd94837260be54deee4567b16918b1 recipient=0xb0F3506Ad5cb776BcCb521A3Da9EF6026394CbF9
"0x03ab851182a5c906aee4cb6c0d0f16fedadd94837260be54deee4567b16918b1"

여기서, value 파라미터는 wei 단위이기 때문에, web3.toWei 함수를 활용하여 20 ether를 wei 단위로 변환하였다. 또한 필요한 gas의 양은 자동 책정된다.

결과값으로는 트랜잭션 해시 값이 나온다.

승인되지 않은 거래 확인하기

아직 다음 블록이 나오지 않아, 위에서 만든 거래는 확인받지 못했을 것이다. 이 사실을 확인해보자.

> txpool.content.pending
{
  0x2F2ae2B466B08758A29f74f5ecAE6d7114b2D562: {
    ... // 이 글에 언급하지 않은, 테스트용 거래가 세 개가 앞서 있다.
    3: {
      blockHash: "0x0000000000000000000000000000000000000000000000000000000000000000",
      blockNumber: null,
      from: "0x2f2ae2b466b08758a29f74f5ecae6d7114b2d562",
      gas: "0x15f90",
      gasPrice: "0x430e23400",
      hash: "0x03ab851182a5c906aee4cb6c0d0f16fedadd94837260be54deee4567b16918b1",
      input: "0x",
      nonce: "0x3",
      r: "0xb62d5de13a99b4caaf941999d5aa96bef276ff29f96b61025237fd20bbac740c",
      s: "0x383b6c2e3ec23c8aa24785d291f41d40c55b13470ea6a61ccfb5d4ce35790ef4",
      to: "0xb0f3506ad5cb776bccb521a3da9ef6026394cbf9",
      transactionIndex: "0x0",
      v: "0xe483020ed9ed1",
      value: "0x1158e460913d00000"
    }
  }
}

역시 pending 거래 목록에 있음을 확인할 수 있다.

블록을 만들고 거래 확인하기

다시 채굴 명령어 miner.start()로 하나 이상의 블록을 만든 이후 다시 txpool.content.pending을 살펴보면 미승인된 거래가 없음을 확인할 수 있다.

> txpool.content.pending
{}
```m[, ]

`eth.getTransaction` 명령어로 아까 우리의 트랜잭션을 확인해보자.
```js
> eth.getTransaction("0x03ab851182a5c906aee4cb6c0d0f16fedadd94837260be54deee4567b16918b1")
{
  blockHash: "0x0147af80c0ec9db07debcdc1006ce37cdec765672fca49aca0325b9267eed166",
  blockNumber: 84,
  from: "0x2f2ae2b466b08758a29f74f5ecae6d7114b2d562",
  gas: 90000,
  gasPrice: 18000000000,
  hash: "0x03ab851182a5c906aee4cb6c0d0f16fedadd94837260be54deee4567b16918b1",
  input: "0x",
  nonce: 3,
  r: "0xb62d5de13a99b4caaf941999d5aa96bef276ff29f96b61025237fd20bbac740c",
  s: "0x383b6c2e3ec23c8aa24785d291f41d40c55b13470ea6a61ccfb5d4ce35790ef4",
  to: "0xb0f3506ad5cb776bccb521a3da9ef6026394cbf9",
  transactionIndex: 3,
  v: "0xe483020ed9ed1",
  value: 20000000000000000000
}

아주 잘 승인된 듯하다.

eth.getBalance 명령어로 돈을 받은 계좌의 잔액을 확인해보면 적절하게 변동하였음을 알 수 있다.

> eth.getBalance("0xb0f3506ad5cb776bccb521a3da9ef6026394cbf9")
23000000000000000000 //이 글에서 언급하지 않은 세 번의 거래로 3 ether가 더 들어 있다.

이렇게 개인 이더리움 네트워크로 간단한 이더리움 거래를 해 보았다.

참고한 글

이번에도 많은 다른 글에서 도움을 받았다.

https://github.com/ethereum/go-ethereum/blob/master/console/bridge.go
https://steemit.com/kr/@sangphilkim/geth 이 글에서 가장 큰 도움을 받았다.
https://crosswave.net/?p=2785
https://ethereum.stackexchange.com/questions/12181/how-do-you-configure-geth-to-use-coinbase

이더리움 Genesis 파일 만들고 개인 네트워크 구동하기

실토 — Thu, 10 Jan 2019 20:20:43 +0900

이 글은 Hexo 기반의 블로그에서 옮겨온 글이며, 원본 글은 2018년 7월 25일에 작성되었다.

이번 학교의 DPNM 연구실에서 여름 방학에 블록체인 관련 공부를 하고 있는데, 간단한 이더리움 활용 과제가 나와 수행하던 도중 난데없이 사설 네트워크와 "genesis"라는 단어가 나와 그에 대해 간단히 정리해본다.

아래의 글은 이미 서버에 이더리움이 설치되어 geth 명령어를 실행할 수 있다고 가정하고 작성하였다. 작성 당시 geth 버전은 1.8.12-stable이다.

이더리움 사설 네트워크와 Genesis 파일

이더리움은 사설 이더리움 네트워크를 만들 수 있게 되어 있는데, genesis 파일이란 이 개인 네트워크의 초기 설정이라 할 수 있다. "the genesis"는 발생, 창시 등의 뜻이 있다고 한다. 이더리움뿐 아니라, 다른 암호 화폐에서도 최초의 블록을 "Genesis block" 이라고 한다고 한다. 뭐... 그런 느낌이다. Genesis의 표기에 대해서는 첫 글자가 대문자이면 좀 더 멋져 보이므로, 내 맘대로 첫 글자를 대문자로 하기로 한다.

Genesis 파일 구조

Genesis 파일은 JSON 형식으로 네트워크 설정을 저장하고, 이 파일을 먼저 만들어야 나만의 이더리움 네트워크를 가동할 수 있다. 일단 그 태를 보면 아래와 같다.

{
    "config" : {
        "chainId"        : 0,
        "homesteadBlock" : 0,
        "eip155Block"    : 0,
        "eip158Block"    : 0
    },
    "alloc"      : {},
    "coinbase"   : "0x0000000000000000000000000000000000000000",
    "difficulty" : "0x10000",
    "extraData"  : "",
    "gasLimit"   : "0xffffff",
    "nonce"      : "0x0000000000000000",
    "mixhash"    : "0x0000000000000000000000000000000000000000000000000000000000000000",
    "parentHash" : "0x0000000000000000000000000000000000000000000000000000000000000000",
    "timestamp"  : "0x00000000"
}

이제 위에서부터 하나하나 말해보자면...

config
새로 만들 개인 블록체인 네트워크의 설정을 담당하는 오브젝트이다. 이 오브젝트 이외의 설정값들은 대망의 첫 블록에 관한 것이다.

chainId : 현재 블록체인의 ID이다. 리플레이 공격을 막기 위해 사용된다. 그저 이더리움 네트워크를 공부할 때는 예약된 ID가 아닌 것으로 아무렇게나 적어도 괜찮다.
homesteadBlock : 이더리움은 네트워크의 발전 단계에 따라 버전을 미리 구상해 놓았다. 그 각 단계에 올림픽, 프론티어, 홈스테드 등 여러가지 코드 네임을 붙여놓았는데, 그 중 처음으로 "안정" 단계에 해당하는 단계가 바로 홈스테드 이다. 그 홈스테드 단계가 시작되는 블록의 ID를 적으면 된다. 그저 이더리움 네트워크를 공부할 때는 처음부터 홈스테드 단계로 들어가서 살펴보게 되므로, 0이라고 적으면 된다.
eip155Block : EIP는 Ethereum Improvement Proposal 의 약자로, 이더리움 네트워크를 개선하는 여러 제안들을 말한다. 그 중 리플레이 공격 방어에 관한 155번째 제안이 적용이 시작되는 블록 ID를 적으면 된다. 그저 이더리움 네트워크를 공부할 때는 처음부터 이 보안을 적용할 것이므로, 0이라고 적으면 된다.

alloc : 네트워크 초기에 특정한 계좌에 특정한 액수의 코인을 지급할 수 있다. 암호 화폐의 초기 부흥을 위해서 화폐를 사전 판매하는 경우가 있는데, 이 때 쓰일 수 있다. 예를 들면, 아래와 같다.
```
"alloc" : {
    "19yadv8h2ebalnlrqszzlph54lci6d6pdvht5abi" : { "balance" : 10000 },
    "haq72tf9ldqzyavp3slocx55jb00hvldm4ai9iln" : { "balance" : 10000 }
}
```
이 경우 저 두 계좌로 각각 10,000 코인을 지급한 것이 된다. 그저 이더리움 네트워크를 공부할 때는 {}로 비워놔도 좋다.
coinbase : 지금 설정하고 있는 이 첫 블록의 채굴 보상이 돌아갈 계좌 주소이다. 이더리움에서 주소는 160비트로 이루어져 있다. 그저 이더리움 네트워크를 공부할 때는 0으로 해놔도 좋다.
difficulty : 첫 블록의 논스 값 범위의 난이도이다. 값이 낮을 수록 채굴이 쉬워진다. 첫 블록 이후에는 이전 블록의 difficulty와 timestamp를 참고하여 이더리움 소프트웨어가 자동으로 difficulty를 계산할 것이다. 그저 이더리움 네트워크를 공부하는 사람은 거대한 채굴 능력이 없기 때문에, 난이도를 낮게 설정하여 쉽게 채굴하도록 하는 것이 좋으므로, 0x10000 정도로 설정해놓는 것이 좋다.
extraData : 어떠한 데이터를 블록체인에 영구적으로 보존하기 위해 존재하는 32비트의 빈 공간이다. 보통 ""로 비워둔다.
gasLimit : 이더리움 거래 수수료 단위를 Gas 라 하는데, 이더리움 ETH 자체는 시장 가치의 변동폭이 매우 크므로, 그 대신 안정적으로 트랜잭션 비용을 지불하기 위해 만들어진 단위이다. 거래 별 거래 수수료는 해당 거래를 처리하기 위해 필요한 컴퓨터 연산의 정도로 책정된다. 따라서 한 블럭의 전체 거래 수수료 합이 매우 크다는 건 한 블럭을 처리하는데 엄청난 연산이 필요하다는 말이 된다. 그래서 한 블럭에 포함된 거래 수수료에 한도를 두어 한 블럭을 연산하는데 시간이 많이 걸리지 않도록 한다. 그저 이더리움 네트워크를 공부하는 사람은 굳이 여기에 제한을 둘 필요가 없으므로, 0xffffff로 설정해놓을 수 있다.
nonce : 64비트의 상수으로, mixhash와 합쳐져서 작업을 증명하는 데 사용된다. 블록 채굴자들은 이 nonce 값을 증가시켜가며 정답 범위에 들어가는 nonce값을 순차적으로 찾아나설 것이다. 그저 이더리움 네트워크를 공부할 때는 0으로 설정해놓아도 좋다.
mixhash : PoW의 핵심이 되는 값 중 하나로, 256비트의 해시값이며 nonce와 결합하여 작업을 증명하게 된다. 그저 이더리움 네트워크를 공부할 때는 그냥 간편히 0으로 설정해놓으면 된다.
parentHash : 이전 블록의 해시값이다. 이전 블록의 mixhash가 아니다. 이전 블록 전체에 관한 해시값이다. 첫 블록(Genesis block)은 이전 블록이란 게 없으므로, (parent...가 없으므로?) 0으로 설정해놓으면 된다.
timestamp : 블록이 받아들여진 시간을 유닉스 시각으로 나타낸다. 이 값은 블록의 순서를 검증할 때도 사용된다. 그저 이더리움 네트워크를 공부하는 사람은 크게 신경쓸 것 없이 0으로 설정해놓으면 된다.

위의 예시에 적히지 않은 설정 파라미터도 있고 생략가능한 파라미터도 있지만, 그저 이더리움 네트워크를 공부하는 입장에서 적당하게 적어놓았다.

Genesis 파일 만들고 개인 네트워크 시작하기

먼저, 작업 디렉토리를 만들었다.

~ $ mkdir tessup #테스트 서버 (...)
~ $ cd tessup

위의 내용을 참고하여 아래의 내용으로 genesis.json 파일을 만들어 작업 디렉토리 안에 저장했다.

{
    "config" : {
        "chainId"        : 2010010611011415,
        "homesteadBlock" : 0,
        "eip155Block"    : 0,
        "eip158Block"    : 0
    },
    "alloc"      : {},
    "coinbase"   : "0x0000000000000000000000000000000000000000",
    "difficulty" : "0x20000",
    "extraData"  : "",
    "gasLimit"   : "0x300000",
    "nonce"      : "0x0000000000000000",
    "mixhash"    : "0x0000000000000000000000000000000000000000000000000000000000000000",
    "parentHash" : "0x0000000000000000000000000000000000000000000000000000000000000000",
    "timestamp"  : "0x00000000"
}

작업 디렉토리 안에 블록이 저장될 디렉토리로 data 디렉토리를 생성했다.
```
~/tessup $ mkdir data
```
bootnode 명령어를 사용하여 부트 노드를 시작했다. bootnode는 부트스트랩 노드를 구현한 소프트웨어이다. 여기서 부트스트랩 노드는 일종의 시동 노드로, 다른 노드들의 목록을 저장하여 네트워크를 유지하는 노드를 말한다.
```
~/tessup $ bootnode -genkey=tessup.key
~/tessup $ bootnode -nodekey=tessup.key
```
개인적으로는 위 마지막 명령을 백그라운드에서 관리하기 위해 아래와 같이 pm2라는 패키지를 활용했다. pm2는 NPM이 설치되어 있는 상황에서 sudo npm i pm2 -g 명령을 통해 설치할 수 있다.
```
~/tessup $ pm2 start bootnode -- -nodekey=tessup.key
```
위 명령을 다 실행하면 내 부트스트랩 노드의 주소가 콘솔에 (pm2의 경우, pm2 log bootnode 명령어를 입력하면) 나타남을 볼 수 있다.

geth 명령어를 사용하여 네트워크에 시동을 건다.

~/tessup $ geth --datadir="./data/" init genesis.json
~/tessup $ geth --bootnodes="(enode://로 시작하는 노드 주소)" --datadir="./data/" --networkid=(genesis.json 파일에 적었던 chainId) console

이 과정이 성공적으로 완료되었다면 Geth Javascript Console이 나타남을 볼 수 있다.

노드 정보를 확인해본다.
일이 다 끝나면 아래와 같이 자바스크립트 콘솔에 입력하여 내가 실행 중인 노드 정보를 알아볼 수 있다.
```
> admin.nodeInfo
```
여기서 내가 설정한 Genesis 파일과 동일하게 돌아가는지, 나의 부트스트랩 노드와 연결했는지 확인해보자.

확인을 끝냈다면, 이제부터 나만의 네트워크를 즐겨보자!

나의 이더리움 네트워크에서 해볼 수 있는 예시 활동은 이 글에 적어놓았다.

문제 해결

유효하지 않은 IP 주소 문제

Fatal: Error starting protocol stack: bad bootstrap/fallback node "enode://...@[::]:30301" (invalid IP (multicast/unspecified))

이 문제는 bootnode의 output을 그대로 가져다 붙여서 geth를 실행했을 때 나타나는 문제인데, bootnode에서 제공하는 주소 끝의 IP (0.0.0.0 혹은 ::)는 받는 IP의 종류로, 외부에서 들어오는 접속을 IP 가리지 않고 받는다는 뜻이다. 여기서 의도하는 것은 어디로 접속해야 할 지가 중요하므로, 0.0.0.0 혹은 :: 대신 아까 bootnode를 실행한 서버의 IP, 혹여 같은 서버라면 127.0.0.1을 적어주자. 30301 포트가 막혀 있다면 꼭 포트를 열어주자.

계속 뭔가가 나오는 문제

INFO [07-26|12:57:49.005] Imported new state entries               count=1152 elapsed=4.020ms   processed=99887672 pending=21784 retry=2   duplicate=0 unexpected=192
INFO [07-26|12:57:49.400] Imported new state entries               count=953  elapsed=7.046ms   processed=99888625 pending=21836 retry=0   duplicate=0 unexpected=192

아무것도 하지 않았는데 무언가 계속 통신이 이루어지는 듯한, 위와 같은 로그가 1초에 한 번 이상의 빈도로 반복적으로 나타난다면, 혹시 위의 geth 실행 과정에서 지정한 --datadir 옵션이 잘못되어있을 수 있다. 꼭 새로운 전용 작업 디렉토리와 새로운 데이터 디렉토리를 만들고, 그 디렉토리를 그대로 적어주자.

참고한 글

다들 필력이 대단하다. 나는 쨉도 안 된다.

30년간 미뤄온 블로그 개발 계획

실토 — Thu, 10 Jan 2019 19:51:51 +0900

이 글은 구 블로그에서 옮겨온 글이며, 원본 글은 2018년 7월 25일에 작성하였다.

Hexo를 이용해서 블로그를 만든 게 올해 초, 3월이었다. 지금은 그로부터 4개월의 시간이 지났고, 블로그는 초기화시켰으며, 아무런 진전도 없다.

서버 관리나 블로그 개발 등 일련의 작업이 [dman 개발] > [Redirection 서버 구축] > [지난 학기 프로젝트를 공개용으로 변경 및 오류 수정] > [블로그 개발] > [기타 각종 페이지 제작] 순으로 가야 하는데, dman 개발이 서버 이전이나 연구 참여 등으로 계속 지연되고 있는지라 이게 제대로 진행이 안되고 있던 것이다.

그래도, 앞으로 개발해야 하는 블로그 기능 등을 상기시킬 겸 다시 한 번 계획을 적어보아야겠다는 생각이 들어서 글을 써 본다. 지금은 지워진, 3월 23일에 썼던 블로그 개발 계획 글에서 기반하였다.

모바일 레이아웃 고치기
404 페이지 제대로 연결시키기
포트폴리오 페이지 만들기 ("about")
태그(카테고리) 모아보기 페이지 만들기
`meta[name=theme-color]` 부분 고치기 (sass와 pug의 통합적 관리)
작은 화면에서의 레이아웃 고치기
검색 기능 추가핟기
구글 번역으로 번역 기능 추가하기
포스트 페이지에서도 사이드바를 작게라도 표시해주기
사이드바에 트위터 추가하기
페이지 목차 (TOC) 기능 추가하기
HTML 표준 및 웹접근성 확인하기
단락 접기 기능 추가하기
각 페이지에서 태그 목록 띄워주기
긴 코드 X축 스크롤 시 코드 종류 텍스트가 고정되지 않는 문제 해결

현재 내 블로그의 레이아웃/테마가 기반하는 테마인 "Prontera" 테마의 초기 개발자에게 개선사항 다 개선시켜서 커밋 7월까지 할 예정이라고 말을 해놨는데 아마 못지킬듯하다.

부디 8월까지 모두 완성할 수 있길...

18년 8월 10일 기록

아직도 아무런 진전도 없다. 이게 다 학과 홈페이지 개발 프로젝트 때문이다.

18년 10월 7일 기록

전체적으로 살짝 리팩토링했다. 이제 남은 건 위에 기술한 할 일 목록들을 모두 처리하고, scss를 리팩토링하는 것이다.

2018년 여름 서버 구획 정리

실토 — Thu, 10 Jan 2019 19:44:14 +0900

이 글은 구 블로그에서 옮겨온 글이며, 원본 글은 2018년 7월 25일에 작성되었다.

2016년부터 서버 정리와 블로그 제작 등을 조금씩 아주 조금씩 진전시키고 있었는데, 이번 여름에 몰아서 일을 처리하기로 했다. (참 오래도 해왔다...) 그 김에 이때까지 해온 일들도 미래의 나를 위해 정리를 해보기로 했다. 나를 위한 정리이기에 이 글은 다른 사람이 가상 서버 서비스를 선택할 때 그다지 큰 도움은 안 되리라 생각한다.

제일 먼저 했던 것은 서버 서비스 선정 및 구획 정리였다. 세상에는 정말 많은 가상 서버 서비스가 있었는데, 그 중 일부를 사용해보았고 최종적으로는 TOAST Cloud에 정착하였다.

계획한 서버 구조 (처음)

아무래도 큰 하나의 거대 서버에 여러 서비스를 몰아 넣는 일은 좋아하지 않는지라 (이 습성은 나중에 AWS에서 환경을 구성할 때 매우 큰 도움이 되었다), 적당히 서버의 역할을 쪼개서 구상하였다.

서버 계획 구조도

개발 서버
나는 개인적으로 물리적으로 소장한, 서버로 사용하는 장치가 없었으므로 언제 어디서나 접속가능하고 상시 켜져있는 개발 서버가 필요했다.
웹 서버
정적으로 파일을 서비스하는 서버가 필요했다. 이때까지만 해도 Github Pages를 이용할 생각을 못 하고 있었다.
앱 서버
내가 제작한 서버사이드 애플리케이션과 API를 항상 프리뷰 형태로 제공할 계획인데, 이 백엔드 서비스를 돌리는 서버가 필요했다.
노드 밸런싱 서버
노드 밸런싱에 관심을 가지고 있었고, 혹시나 모르는 DDoS 상황에 대비할 필요가 있었다. 아주 오래 전 코노하에서의 안 좋은 추억이 있기도 하고, 항상 모든 상황에 대한 준비를 하고싶었기에...

세상에는 좋고 편한 서비스가 많지만 처음 서버 구조를 생각할 때까지만 해도 나는 그것들을 이용할 생각이 없었다. 그렇기에 이런 돈낭비가 심한 서버 구조를 구상하게 된 것이다. 여하튼, 이렇게 꾸밀 생각으로 난 각 가상 서버 제공업자들을 떠돌아다니기 시작했다.

가상 서버 서비스계의 떠돌이

1. Linode

가장 먼저 이용했던 곳은 Linode였다. 서버 대 개편을 시작하기 전 이용하고 있던 곳이 리노드였기에, 바로 리노드에서 시작하려 했으나...

Ping이 너무 높았다.

내가 Linode를 이용할 때까지만 해도 도쿄 시설이 없었기 때문에, 런던 지역의 인스턴스를 이용했고, 반응 속도가 너무나도 느렸다. 그래서 빠르게 Vultr로 넘어가보게 되었다.

2. Vultr

정말 좋았다. Vultr은 정말 쉽게 모든 것을 할 수 있게 해주는 최고의 서비스였다. 가격도 좋았으며, ping은 들쑥날쑥했지만 가장 좋지 않을 때도 나름 쓸만한 ping을 내 주었다. 서버 관리 패널도 최신식이었고, DNS 서비스까지 제공해주었다.

내부 네트워크의 경우 수동 systemd-networkd로 설정해주어야 한다는게 귀찮기는 했지만, 한 번 설정하면 정말 빠르고 탄탄한 백본망을 제공하기에 만족스러웠다.

Vultr의 서비스를 이용하면서 리눅스 시스템에 대해서 많이 배울 수 있었는데, 서버 디스플레이를 VNC로 제공해주어 네트워크 설정이나 SSH 설정을 잘못해서 접속이 안되게 망쳐놨을 때도 VNC로 들어가서 복구를 스스로 할 수 있었기 때문이다.

하지만 1년 정도 이후 Azure로 옮겨가게 되는데, 좀 더 체계적이고, 더욱 직접 관리를 하고 싶고, (Vultr도 매우 대형 서비스이지만) 더욱 대형 서비스를 체험해보고 싶었기 때문이었다.

3. Microsoft Azure

정말 복잡했다. 처음으로 써 본 대형 서비스라서가 아니었다. 마이크로소프트 특유의 번역과 특유의 느낌이 나는 서비스명 선정 등이 내가 이해하기에 너무 어려웠다. 물론 나중에 차츰 적응이 되긴 했지만, 와닿지는 않았다. 서비스 관리 패널에서의 원인을 알 수 없는 오류도 많이 났다.

서비스 자체의 질은 나쁘지 않았고, Vultr보다 성능이 좋았다. '한국 Azure 사용자 모임'이라는 페이스북 그룹도 존재하여, 가끔 도움을 구할 수 있다.

그래도, 상기한 단점들로 결국 GCP(Google Cloud Platform)로 자리를 옮겨가게 된다.

4. Google Cloud Platform

Azure와는 확실히 다르게 메뉴를 이해하기 쉬웠다. 이건 구글이 잘 했다기 보다는 Azure가 너무 나에게 어려웠기 때문이다.

여하튼, 성능도 괜찮고 통합/연계 서비스 (G-Suite 등)도 매력적인 상품이었으나, 다소 비용이 비쌌다. 다른 곳보다 월등히 비싸지는 않지만, 내 개인적인 기준과 판단으로 비용이 많다고 생각되어 3개월 정도 후 AWS로 옮기게 되었다. 자세한 비용 비교는 기억나지 않으므로 생략한다. 내가 기억이 난다면 나중에 이 글을 업데이트 하길...

5. Amazon Web Services

남들이 다 쓴다는 AWS이기에, AWS를 안 써 볼 수가 없었다. 써 본 결과는... 정말 컴퓨팅 서비스의 명가이구나를 느낄 수 있었다. 컴퓨팅 성능도 우수했고, 핑도 상당히 괜찮았다.

하지만 AWS에서도 2달 이후 자리를 옮기게 되는데, AWS에서 제공하는 사양 중 메모리가 다른 저렴한 서비스와 비교해봤을 때 상당히 부족함을 느꼈기 때문이다. 타사에서 같은 가격으로 1GB의 메모리를 제공할 때 AWS EC2는 0.5GB를 제공했는데, Docker 위에서 nginx를 하나 돌리면 0.5GB 메모리가 가득 차서, 더이상 다른 도커 이미지를 올릴 수가 없었다.

물론, 0.5GB 인스턴스에 도커를, 그도 이미지 두개를 올린다는 것 자체가 원래부터가 정말 말도 안되는 억지인 일이고, 좋은 서비스를 이용하려면 그에 상응하는 가격을 지불하는 건 당연한 일이지만... 그냥 적어도 학생 신분일 때 까지만은 세상 공짜로 살고싶은 (혹자가 보면 매우 짜증날 만 한) 소비자가 되어보기로 했다.

AWS를 지나면서 나의 서버 계획도 바뀌었는데, 서버사이드 언어로 돌아가는 서비스를 제외하고는 모두 Github 페이지를 이용하고, 개발 서버는 내가 쓰던 예전 노트북을 DDNS와 결합하여 서버로 쓰기로 하고, 서버사이드 언어로 돌아가는 메일서버, 404 페이지 서비스, 기타 앱 서비스만을 가상 서버 서비스에 올리기로 했다.

6. TOAST Cloud

이제 고려할 만 한 다른 외국 서비스는 그다지 없었고, 핑이 중요한지라 국내 서비스를 찾아보았는데, ucloud는 개인 서비스를 종료했고, 대신 새로 떠오르는 TOAST 서비스가 있어서 이 기회에 이용해보게 되었다. 이렇게 말하니까 기승전광고글같지만 이건 그냥 개인 기록일 뿐이다.

아직까지는 지원하는 리눅스 이미지 종류도 매우 적고 (CentOS/Ubuntu/Debian/RHEL/Windows), 콘솔 로그인 계정에 대해 보안도 매우 허술하다 (TOTP 미지원 및 이메일/비밀번호만 알면 로그인이 가능).

하지만 꽤 경쟁력이 있다 (고 내가 생각하는) 가격 정책, 무엇보다도 국내 서비스라 국내 고객센터이고, 말이 잘 통하는 사람들이 답변을 달아준다. 문의를 하면 고객 센터 직원뿐 아니라 내부 운영 및 개발 직원이 직접 답변을 해주기도 한다. 이 점은 나머지 어떤 서비스에서도 찾아볼 수 없는 고객 관리라고 생각이 든다. 내가 현재 TOAST 서비스에서 떠나지 않는 이유도 이것이 주이다. 여하튼, 핑과 성능도 좋으므로, 현재 만족하며 사용중이다. 다만 TOAST Cloud에서 docker를 이용한다면 손이 많이 가게 될 것이다. docker-ready OS를 제공하지 않기 때문이다.

현재 서버 구조

현재는 상기한 TOAST Cloud 위에 아래와 같은 서비스를 굴리고 있다.

404 페이지 서버
메일 서버
채팅 앱 데모용 백엔드 서버
공용 콘텐츠 저장용 오브젝트 스토리지 두 개

나머지는 모두 Github Pages로 이전했으며, 개발은 개인 노트북 서버에서 진행한다.

두서 없이 글을 썼지만, 나중에 언젠가 나 자신에게 참고가 되겠지?