정보엔지니어 (맥스웰의 도깨비, 양자컴퓨터)

콜라츠의 추측은 아래 단순한 규칙으로 반복하였을때 모두 1로 귀결된다는 추측이다.

if n is odd, get 3n+1

if n is even, get n/2

초등학생도 이해할 수 있는 문제이기 때문에, 아이들과 같이 이야기하다가 도움이 될 수 있는 만한 정보를 확보하여 기록해 둔다. 상기 계산을 숫자별로 계속 반복한 다이어그램이 바로 아래와 같다.

그런데 이 그림을 조금 계량해 보면, 이 문제를 더 단순화 할 수 있다. 어떻게? 특정 홀수들의 2의 x제곱을 각각의 줄로 나열해놓고 표기하는 방법이다. 이렇게 되면 해당 줄에 들어서면 나누기 2를 반복해서 결국 그 홀수로 귀결된다. 그러면 그 홀수에서 3n+1로 jump하는 식으로 구성할 수 있다.

위 그림에서 아예 홀수를 순서대로 나열하는 그림으로 바꾸면 아래와 같은 그림으로 전환된다.

그런데 가만히 살펴보면 이 화살표를 더 단순화 할 수 있다는 것을 알 수 있다. 일단 어느 홀수 선에든 닿으면 그것은 최종의 맨 상단의 본질적인 홀수로 닫게 되고, 그것이 다시 3n+1 jump를 해도 결국 그 jump한 홀수 선의 맨 처음으로 다시 귀결하기 때문이다. 따라서 아래와 같이 그려도 사실 어느 곳으로 움직이냐를 단순화 시켜 나타낼 수 있다.

이것을 더 크게 나타내보면 아래와 같다. 이번에는 even*2^x 패턴에서 이 even값들만 나열해보자. 그러면 더 간단히 나타낼 수 있다.

보다보면 오른쪽으로 이동이나 빨간색 왼쪽 이동은 일정 패턴이 있다는 것을 알 수 있다. 다만 어려운 것은 주황색의 왼쪽 움직임이다. 이 왼쪽 움직임은 몇가지 확인을 해본 결과 3*n을 빼놓고는 모두 닿으면서 다소 불규칙하다. 그래서 사실은 이 주황색의 움직임을 정형화 할 수 있다면 콜라츠의 추측 전체를 증명할 수 있지 않을까 싶었다. 그리고 이 이동이 사실은 테렌스 타오의 증명에 나오는 함수와 연관이 있다는 사실을 알게 되었다. 이 주황색의 움직임은 결국 소수와 연관이 있지 않을까? 그래서 불규칙한가? 라는 생각도 했었다.

이 작업을 진행하면서 3n+1 규칙 대신에 5n+1, 7n+1, 9n+1, 11n+1 등의 규칙을 조사해보았는데, 이런 확장에 대해 다소 규칙성이 있다.  새로운 규칙들에 대해 아래 숫자들을 발견하였다.

3n+1 -> 8n + (7-3)

5n+1 -> 8n + (8-5)

7n+1 -> 8n + (8-7)

9n+1 -> 16n + (16-9)

11n+1 -> 16n + (16-11)

다만 5n+1, 7n+1 등 일때는 순환이 다양한 양상으로 전개되고, 규칙 패턴이 조금씩 다르게 나타난다(검은색, 빨간색의 패턴이 다르다)

이 정보만으로 증명하기는 어렵지만 문제를 이해하는데 조금더 단순화한 그림을 제공할 수 있다고 생각한다.

이 문제에 대한 짧은 유투브 동영상을 같이 공유한다. 위 패턴중 주황색 패턴을 이해하여 이 문제의 증명에 도움을 받는이가 생겼으면 좋겠다.

https://www.youtube.com/watch?v=094y1Z2wpJg 

지난 번에 다양한 개인키를 생성하여 지갑을 추적하는 이더리움 계좌 해킹 글을 게시한 적이 있다. 지금 이 글은 그때 이더리움을 운영하는 중심 프로그램인 geth client 의 사용에 익숙해진 사용자를 대상으로 하므로 이에 대한 사전 지식이 필요하다는 점은 밝혀둔다.

해당 기존 블로그 글은 아래와 같다.

https://infoengineer.tistory.com/56 

이와 관련하여 이더리움 작업을 자동화하는 script화가 필요하고, 가장 쉬운 방법은 geth 자체의 명령을 geth attach 라는 형태로 script화 하는 것이다. 편의상 여기서는 linux의 bash shell을 통해 geth attach 기능을 사용해 보자.

우선 먼저 가정이 필요한데, script 실행하는 같은 서버에 geth가 최소한 lightmode로 작동하고 있다고 가정했다

(물론 full mode도 작동한다)

아래 처럼 nohup으로 geth를 light mode로 띄워놓자. nohup을 사용하면 다행스럽게도 terminal을 종료해도 geth가 계속 살아있다.(geth process를 만약 kill해야 한다면, ps -ef geth 명령으로 확인하여 kill PID 명령을 통해 죽이자)

$ cd /work/geth

$ more run_main_light_nohup.sh
nohup ./geth --datadir "/work/gethdata" --allow-insecure-unlock --syncmode "light" >> ./result.log 2> ./result2.log &

$ ./run_main_light_nohup.sh

A. 내 이더리움 geth 등록 계좌(eth.accounts) 전체의 잔액을 확인해보자.

아래 소스를 통해 가능하다.  https://github.com/neibc/ethereum/blob/main/check_all_balances.sh

geth attach는 bash의 명령어 입력 기능인 "<< EOF ~ EOF" 를 통해 code를 전송하면 된다.

$ cd /work/geth

$ more check_all_ballances.sh

#!/bin/bash

# check the balances of all registered accounts on geth

# 2021.08.05 by neibc

/work/geth/geth --datadir "/work/gethdata" attach << EOF

eth.accounts.forEach(function(e,i){console.log("eth.accounts["+i+"]: " + eth.accounts[i] + "\tbalance:" + web3.fromWei(eth.getBalance(eth.accounts[i]),"ether") + " Ether" )});

EOF

$ ./check_all_balances.sh
Welcome to the Geth JavaScript console!

instance: Geth/v1.10.6-stable-576681f2/linux-amd64/go1.16.4
at block: 12965696 (Thu Aug 05 2021 15:12:50 GMT+0000 (UTC))
 datadir: /work/gethdata
 modules: admin:1.0 debug:1.0 eth:1.0 ethash:1.0 les:1.0 net:1.0 personal:1.0 rpc:1.0 txpool:1.0 vflux:1.0 web3:1.0

To exit, press ctrl-d
>
>
..

eth.accounts[8]: 0xae72a48c1a36bd18af168541c53037965d26e4a8     balance:0 Ether
eth.accounts[9]: 0x8fd379246834eac74b8419ffda202cf8051f7a03     balance:0 Ether
eth.accounts[10]: 0x19e7e376e7c213b7e7e7e46cc70a5dd086daff2a    balance:1.4972e-14 Ether
eth.accounts[11]: 0x1563915e194d8cfba1943570603f7606a3115508    balance:9.96e-15 Ether
eth.accounts[12]: 0x5cbdd86a2fa8dc4bddd8a8f69dba48572eec07fb    balance:0 Ether
eth.accounts[13]: 0x7564105e977516c53be337314c7e53838967bdac    balance:0 Ether
eth.accounts[14]: 0xe1fae9b4fab2f5726677ecfa912d96b0b683e6a9    balance:0 Ether
eth.accounts[15]: 0xdb2430b4e9ac14be6554d3942822be74811a1af9    balance:0 Ether
eth.accounts[16]: 0x62f94e9ac9349bccc61bfe66ddade6292702ecb6    balance:0 Ether
eth.accounts[17]: 0x0d8e461687b7d06f86ec348e0c270b0f279855f0    balance:1.2e-14 Ether
..

계좌에 있는 잔액이 맨 오른쪽에 표시됨을 알 수 있다.

B. 이제 ethereum sendTransaction 명령(송금)을 내려보자.

아래 소스를 통해 가능하다.

https://github.com/neibc/ethereum/blob/main/automatic_transfer_eth.sh

...

eth.sendTransaction({from: fromacc, to: toacc, value: transferval, gas: gaslimit, gasPrice: gasprice});

...

특정 계정(fromacc)에서 특정 계정(toacc)으로 gas price, gas limit을 정하여 실행한다. 이때 parameter로 사용되는 gas, gas price, gas limit이라는 것을 알아보자.

ㅇgas는 gas limit을 의미한다. 해당 송금을 요청할때 사용자가 지불할 수 있는 최대 허용 gas를 정의한다.

대개 단순 송금은 21,000이다. 특이한 것은 조금더 올려 잡아도, 이더리움 송금이 최종 완료되고 나서 남으면 돌려준다. gas는 이더리움 송금 외에도 ERC-20 방식 등 별도의 이더리움 기반 코인 등 송금할때도 사용하기 때문에, 복잡한 transaction에는 높은 gas를 부과해서 처리한다.

ㅇgas price는 사용하는 gas에 곱하여 최종의 송금비용(transaction fee)를 ethereum으로 계산할 수 있다. gas price는 높이 부과해줄수록 더 빠른 송금이 가능하다. 예를들면 일반 이더리움 송금은 21,000 gas를 소모하는데, 대략 gas price는 35~60 gwei(giga wei) 정도 된다. 참고로 wei는 이더리움을 더 작은 단위로 부르는 값인데 아래와 같이 이해하면 된다.

10^18 wei = 1 Ether

0.000000000000000001 Ether = 1 wei

1 gwei = 1 giga wei = 1,000,000,000 wei

sendTransaction에서 이 gas(gas limit), gasPrice(gas price)를 생략하면 디폴트 값으로 요청되고 다소 해당 값이 작을 수도 있어서 가끔씩 오류가 발생할 수도 있다. 그리고 송금하려는 이더리움과 이 수수료가 모두 잔고에 남아있어야 송금이 성공된다. 잔고가 부족한 경우 잔고 부족 오류가 발생한다.

에러 예시>  Error: Insufficient funds for gas * price + value   - 송금지정금액+송금비가 잔액을 초과한 경우

                gas required exceeds allowance - gas limit이 작아서, 더 큰 gas limit 지정이 필요한 경우

gas price는 시간이 오래 걸려도 상관없으면 1 gwei를 지정해서 처리하기도 한다. 그러면 지금 이더리움 네트워크의 대략의 gas price는 얼마인지 궁금한가? eth.gasprice 를 사용해도 되고, 사이트에서도 확인할 수 있다. etherscan.io 사이트에서 각 transaction에 사용된 gas price, gas등도 확인이 가능하다

(예시> https://etherscan.io/tx/0xe325a7cc9b088301771c85c04b70597fccffcb50b228eea2173898b2c3a64241 )

실제 실행 소스 코드를 살펴보자.

-----------------------------------------------------------------------------------------------

#!/bin/bash

# geth attach script while running geth with light mode
# 2021.08.05 by neibc

/work/geth/geth --datadir "/work/gethdata" attach << EOF

var fromacc = "0xYOURSOURCEADDR";
var toacc = "0xYOURTARGETADDR";

console.log("fromacc: " + fromacc);
console.log("toacc: " + toacc);
var gasprice = new BigNumber(web3.toWei('35', 'gwei'));
console.log("gas price: " + gasprice);
var gaslimit = 21000;
var cost = gasprice.mul(gaslimit);
console.log("cost price: " + cost);
var deposit = eth.getBalance(fromacc);
console.log("deposit: " + deposit);
var transferval = eth.getBalance(fromacc).sub(cost);
console.log("transferval: " + transferval);

console.log("Unlock account");
personal.unlockAccount(fromacc,"YOURPASSWORD");

if(transferval > 0) {
  console.log("transfer result");
  eth.sendTransaction({from: fromacc, to: toacc, value: transferval, gas: gaslimit, gasPrice: gasprice});
} else {
  console.log("no balance");
}

EOF

-----------------------------------------------------------------------------------------------

참고로 ERC-20 token의 코인도 송금할 수 있다. 해당 토큰의 계약 주소는 etherscan.io 등에서 확인이 가능하다. 여기서는 미네리움을 예시로 들었다. ( https://etherscan.io/token/0x426CA1eA2406c07d75Db9585F22781c096e3d0E0 )

소스는 아래를 참조하자.

https://github.com/neibc/ethereum/blob/main/automatic_transfer_erc20token.sh

C. 알려진 여러개의 계좌에서 잔액이 입금될때마다 돈이 송금되게 하려면?

이전에 지적한대로 개인키가 잘 알려진(예> 개인키 1값) 계좌 등에서는 입금하자마자 출금하는 진풍경이 벌어진다.

https://etherscan.io/address/0x7e5f4552091a69125d5dfcb7b8c2659029395bdf

이런 스크립트는 어떻게 작성할 수 있을까? 필자는 crontab과 geth attach script를 결합해보았다.

이를 테면 계좌를 반복적으로 조회하면서, 잔액이 일정액 이상 남아있으면 송금하는 작업을 반복할 수 있다. 다만, 구동시 에러(peer 접속 중단 등)가 나면 해당 geth attach가 Exception으로 중단되는데, 다시 작업을 이어주기 위해 crontab에 주기적으로 다시 띄워준다. 다만, 해당 script에는 동일한 geth attach script 명령이 기 동작 중이면 실행되지 않고 멈추도록 앞 부분에 "ps -ef"를 활용한 방어 코드를 넣어주었다.

https://github.com/neibc/ethereum/blob/main/repeatedtrasfer_eth_from_knownaddr.sh

-----------------------------------------------------------------------------------------------

#!/bin/bash

# crontab registration - run every 10 minutes this script
# 10,20,30,40,50 * * * * cd /work/geth;/bin/bash repeatedtrasfer_eth_from_knownaddr.sh
# 
# 2021.08.05 by neibc
#

# run this script only where there is no duplicated attach job
# because it tries to run sendTransaction continuously if there is no error(disconnection or something)
#

ps -ef | grep "[a]ttach" > /dev/null
if [ $? -eq 0 ]; then
echo "duplicated attach job exists"
else
#/work/geth/geth --datadir "/work/gethdata" attach >> /work/geth/joblog.txt 2> /work/geth/joblog_err.txt << EOF
nohup /work/geth/geth --datadir "/work/gethdata" attach >> /work/geth/joblog.txt 2> /work/geth/joblog_err.txt << EOF

var toacc = "0xTARGETADDRESS_FIXME";
console.log("toacc: " + toacc);
var gasprice = new BigNumber(web3.toWei('130', 'gwei'));
console.log("gas price: " + gasprice);
var gaslimit = 21000;
var cost = gasprice.mul(gaslimit);
console.log("cost price: " + cost);
var deposit = 0;
var transferval = 0;

while(true) {
        eth.accounts.forEach(function(e,i){

               deposit = eth.getBalance(eth.accounts[i]);
               transferval = eth.getBalance(eth.accounts[i]).sub(cost);

               if(transferval > 0) {
                      console.log("num:"+i);
                      console.log("addr:"+eth.accounts[i]);
                      console.log("balance:"+deposit);
                      console.log("transfer val:"+transferval);
                      console.log("Unlock account");
                      personal.unlockAccount(eth.accounts[i],"YOURPASSWORD_FIXME");
                      console.log("transfer result");
                      eth.sendTransaction({from: eth.accounts[i], to: toacc, value: transferval,gas: gaslimit, gasPrice:gasprice});
               }
        });
}
EOF

fi

-----------------------------------------------------------------------------------------------

다양한 스크립트의 예시로서 위 샘플들이 참고가 되었으면 좋겠다.

소수(prime number)란 무엇인가?

암호화폐와 양자컴퓨터의 등장으로 RSA 비대칭 암호화 방식이 점점더 주목을 받기 시작했다. 그리고 이 안에 숨어있는 것이 소수이다. 그리고 수학의 정수론에서 이 소수는 늘 나타난다. 왜일까?

최근에 깨달은 것은 이 소수는 기계적으로 처리하기 어려운 예측 불가한 수라는 사실이다. 무언가 반복해서 쉽게 알아내기 어렵다. 수는 대칭적인 속성이 중요하다는 얘기를 전부터 자주해왔는데, 소수는 특이하게도 1과 자기 자신 외에는 나눠지지 않는다. 즉 여러가지 계산에 있어서 원자처럼 작동한다. 1을 여러번 더하면 되잖아요! 라고 할 수 있는데 그게 다다. 1을 반복하는 것 외에는 저 수에 도달할 방법이 없다. 그냥 뻥하고 태어난다. 2,3,5,7,11,13,17,.. 들이 그렇다.

무한히 존재하는 수를 기계적으로 매끄럽게 압축해서 표현하는 여러가지 방법이 있는데, 괴델의 불완전성의 정리에도 나오는 대로 이 세상의 모든 수는 각각 소수의 연속된 무슨 제곱의 곱으로 나타낼 수 있다. 2^a * 3^b * 5^c * ... 이러면 꽤 큰 수들을 나름 아주 압축해서 나타낼 수 있다. 예를 들면 이런걸 소수 진법이라고 칭하면 저 위의 abcde..만 모아서도 수 체계를 만들 수 있다. 그렇게 소수는 이 숫자들의 최소 구성요소로 간단하게 말할 수 있고, 더이상 압축할 수 없는 말단이다. 그런데 이렇게 정의하는 데는 이 소수의 목록이 필요한데, 그걸 그냥 테이블로 저장하는 방법 외에는 더 축소해서 나타낼 방법이 없다. 이렇게 기계로 줄이는데 여하튼 더이상 방법이 없는 수들이다.

만약에 소수에 규칙이 존재한다면 더 압축할 수 있겠다. 그것은 수의 원자를 새로 선언하는 일이 된다. 아직은 벌어지지 않는다. 정수론을 이것저것 증명하다가 소수가 발견되면 거기가 끝이다. 더이상의 정리는 불가능해진다. 거기가 쪼개질 수 있는 한계이다.

그리고 그런 성질들이 현대의 비대칭 암호화 큰 축을 지탱하고 있다.

 가끔씩 비트코인 계좌의 비밀번호(혹은 개인키)를 잃어버렸다는 기사를 볼 수 있다. 그러면 누구나 생각하게 된다. 아무도 못찾게된 저 계좌 내가 찾아볼까?

 그래서 시작해보았다. 찾아보자. 사실 이 여정은 이더리움(비트코인과도 매우 유사한 계좌 체계를 갖는다)을 이해하기 위한 여정이기도 한데, 이것저것 얻은 것은 많았다. (비트코인은 이 방법과 동일한데, 같은 글을 읽고 6번을 확인해보자)

1. 처음에는 이더리움의 지갑체계를 이해해야 한다.

 이더리움같은 암호화폐의 계좌는 일반 우리가 아는 은행의 계좌와는 전혀 다르다. 자세한 설명은 다른 글을 링크하고 ( https://infoengineer.tistory.com/55) 단순하게 이더리움의 지갑주소 생성 과정을 설명해보자.

 이더리움의 계좌 주소는 이렇게 생겼다.

"0xdcc703c0e500b653ca82273b7bfad8045d85a"

 이것은 이더리움 계좌를 정의하기 위한 개인키/공개키 쌍에서, 공개키를 가지고 생성한다. 공개키가 주어지면 아주 빠르게 위 계좌주소를 만들 수 있다. 공개키는 어떻게 만드는가? 개인키가 주어지면 또 빠르게 공개키를 만들 수 있다. 그러나 반대는 어렵다. 그렇게 설계되어 있다. 그러면 처음부터 3가지 단계로 다시 설명해보자.

        A. 개인키 선택(1~2^256 숫자 중의 한개를 임의로 고른다. 그 숫자값을 개인키라 한다)

           ex> "3a78e27b1a65f17b538892288f3144f2bb032bd5a7c54e3c578ff407a497a6b0"  (32 bytes, 64글자)

        B. 개인키에서 공개키 생성(타원곡선 알고리즘에 의해 생성한다)

           ex> "de2b88c377e01756f51c0701f....(생략)..0ee35e9c2a3582a513178fd300c03d669b2cf877be9e16af"

        C. 공개키에서 지갑 주소 생성

           ex> "0x7e5f4552091a69125d5dfcb7b8c2659029395bdf"

 이더리움 지갑주소는 가상자산 거래소에서도 대신해 만들어 주며, 이를 통해 외부 입금도 받을 수 있는데, 신기하게도 한 개의 개인키가 정해지면 저렇게 지갑주소가 곧바로 확정된다. 그리고 이 개인키만 알면, 계좌를 송금할때 필요한 서명(signing)을 남길 수 있으므로 계좌를 통제하게 된다. 이 상황은, 마치 암호를 바꿀 수 없는 은행 계좌와 같다고 볼 수 있다. 그래서 사실 저 개인키를 잘 보관해야 하며, 유출되면 바로 돈을 인출당하기 전에 다른 계좌로 송금하는 수 밖에 없다.

 자, 그러면 이제 개인키가 정해지면 이더리움의 지갑주소가 생긴다는 것을 알았다. 그런데 지갑주소에서 개인키를 얻는 계산은 사실 만들어 내기 어렵게 만들어져있다. 그러면 어떻게 하는가? 오래 걸리는 것은 나중에 생각하더라도, 시도해볼 수 있는 것은, 개인키를 1부터 증가시켜 공개키/지갑주소를 계속 만들면서, 실제 존재하는 이더리움 지갑주소와 비교해보면 되지 않겠는가. 소위 brute force 알고리즘이다. 처음부터 끝까지 다 만들어서 대조해보는 것이다.

      A. 개인키를 1부터 시작해서 증가

      B. 공개키/계좌주소를 생성

      C. 생성된 계좌 주소를 기존의 주소들과 비교. (이상 반복)

 일단 개인키를 아래처럼 16진수(hex) 32 bytes 문자열로 넘겨주면 공개키, 지갑주소를 생성하는 python code를 확보해보자. 이후 계속 이 소스를 활용한다. 필요한 모든 것이 이 eachecker.py에 들어가있다.  ( https://github.com/neibc/ethereum/blob/main/eachecker.py ) 대표적으로 get_addr_fromhexstr 함수를 살펴보자.

    $ python3 eachecker.py

    ..

    get_addr_fromhexstr("0000000000000000000000000000000000000000000000000000000000000001",1)

    ..

    Ethereum account search tool ver 0.1

    Private key: 0000000000000000000000000000000000000000000000000000000000000001
    Public key:  79be667ef9dcbbac55a06295ce870b..(생략)..e1108a8fd17b448a68554199c47d08ffb10d4b8
    Address:    0x7e5f4552091a69125d5dfcb7b8c2659029395bdf

이 함수를 쓰면, 개인키 문자열에서 Address(계좌주소)를 알아낼 수 있게 되었다. 자 그럼 여기서 잠깐. 개인키를 1로 삼는 계좌는 과연 실제 존재할까? 우리들의 개발덕들이 해보았을까?

그렇다. 존재한다.

 그리고 이 계좌는 많은 사람이 개인키가 "1" 이라는 것을 알고 있으니, 돈을 넣어가면, 바로 빼내가는 것 같다. 아래 주소에서 지갑의 거래내역을 확인할 수 있다. 계속 내 계좌로 이체하는 트랜잭션을 날리는 프로그램을 짤 수도 있겠다 싶었다. 이 경쟁에서 승리하기가 쉽지 않지만, 실제로 그렇게 경쟁하는 이들이 있다. 정말 그렇다.

https://etherscan.io/address/0x7e5f4552091a69125d5dfcb7b8c2659029395bdf

2. 이제 본격적으로 지갑주소를 생성해서 비교해볼, 실제 이더리움 계좌 목록을 확보해보자.

 여러가지 방법이 있지만, 제일 빠른 것은 구글 클라우드의 빅쿼리에서 공개DB로 제공한 이더리움 원장 테이블을 사용하는 방법이다. 구글이 고마울 뿐이다. 빅쿼리의 테스트 사용 정도는, 요금도 없다. 구글 계정으로 구글 클라우드의 빅쿼리 콘솔로 이동해 아래와 같이 쿼리를 수행하자. (가입절차는 필요하겠다)

https://console.cloud.google.com/bigquery

SELECT `address`
FROM `bigquery-public-data.crypto_ethereum.balances`
WHERE `eth_balance` > 1
ORDER BY `eth_balance` DESC
LIMIT 4000000

 대략 3백만개의 계좌를 export할 수 있었다. 이것을 etheracclist.csv 로 받아서 이후 활용한다 (당연히 파일 이름은 아래 프로그램의 소스파일에서 적당히 고쳐써도 좋다)

여기서 처럼 3백만 계좌를 python에서 dictionary로 처리하면서 탐색하고자 하면, 6.2gb가 조금 넘는 메모리가 필요하다. 속도를 위해 메모리로 올려서 처리하기 때문이다. 1천만계좌면 21gb정도 필요하다. 메모리가 부족하면 잔고가 적은 뒤쪽의 계좌들은 삭제해버리면 된다. 이더리움 잔고가 많은 계좌순으로 소팅해서 저장했기 때문이다. 기억해두자.

3. 그러면 이제 개인키 1~0x100,000 까지 모두 위 이더리움 계좌 목록과 대사해보자

 다시 조금 전에 받은 eachecker.py를 살펴보자. 그대로 실행한다. 이 프로그램은 내부에 runmode = 1 이 되면 startn 변수에 명기된 숫자부터 endn으로 명기된 숫자까지 1씩 증가시키면서, 위 계좌목록에서 일치한 것을 찾으면 BINGO를 출력하고 로그 파일에도 해당 내역을 기록한다.

    $ more eachecker.py

    ...

    runmode = 1

    ...

    print('\nrunmode 1 : full sequence searching from startn to endn...')

    startn = int("1000000000000000000000000000000000000000000000000000000000000001", 16)
    endn = int("2000000000000000000000000000000000000000000000000000000000100000", 16)

    print('\nstart num:')
    print(startn.to_bytes(32, byteorder='big').hex())
    print('end num:')
    print(endn.to_bytes(32, byteorder='big').hex())

   ...

    $ head ethacclist.csv
    address
    0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2
    0x00000000219ab540356cbb839cbe05303d7705fa
    0xbe0eb53f46cd790cd13851d5eff43d12404d33e8
    0x73bceb1cd57c711feac4224d062b0f6ff338501e
    0x53d284357ec70ce289d6d64134dfac8e511c8a3d
    0x61edcdf5bb737adffe5043706e7c5bb1f1a56eea
    0x4ddc2d193948926d02f9b1fe9e1daa0718270ed5
    0x9bf4001d307dfd62b26a2f1307ee0c0307632d59
    0xdf9eb223bafbe5c5271415c75aecd68c21fe3d7f

    $ python3 eachecker.py

    ....

 실행해보면, 예상은 했으나, 돈이 있는 계좌는, 위 숫자범위에서는 전혀 매칭이 되지 않는다는 것을 알 수 있다. 개인키가 노출된 일부 계좌는(위에 소개했던 계좌) 이미 모두 돈이 인출되어, 이더리움 잔고가 0이다. 빅쿼리로 추출한 위 대상 계좌들은 1이더리움 이상 잔고를 지니는 것을 조건으로 추출했다는 것을 기억하자.

 이제 고백할 때가 되었다. 이 무작위 대입 비교(brute force attack) 작업을 비유하는 가장 인상깊었던 표현은

"1부터 2의 256제곱이라는 숫자는 그것을 단순히 세는 것에만 필요한 전력이 우주의 태양과 같은 별이 일평생을 타는 에너지보다 더 많이 필요하다"

라는 것이었다.

 2의 256제곱(=2^256)은 대략 10^77쯤 된다. 로또 당첨확률이 대략 10^7 번 중 한 번인 것을 염두해보면, 이 개인키를 찾는 일은 로또를 11번 연속 당첨된 것과 같은 확률의 작업에 속한다. 천만분의 1의 확률을 11번 통과하는 셈이다.

 시간으로 바꿔보면 이 작업을 하는데 대략 고사양 CPU로 1초에 1만건을 처리한다고 가정하자. 초당 10^4건이다. 그러면 PC 1대로 계산한다고 하면 10^74 초 걸리고, 1년을 1억초(10^8)로 후하게 잡아도 대략 10^66 년이 걸린다. 지구의 CPU core 전체일것 같은 1000억개(10^11)쯤 동원해도 10^55 년이 걸린다. 빅뱅이후 대략 120억년(1.2 * 10^10)이 지났다고 하니, 우주가 시작되고 지금까지 계산해도 10^45번중 1개(10^10 년)를 처리한 셈이다. 그렇게 우주의 시간 계산을 10^45번 반복해야 한다.

 10^77이라는 숫자를 이렇게 10^45으로 줄이는데도(33제곱이 줄었다), 전 우주의 시간과 모든 리소스를 동원해야 하는 수준인 것이다. 아직 줄여할 숫자가 45제곱이 더 남았다. 10배씩 시간을 절감할때마다 이 제곱수를 1씩 줄일 수 있다.

 (개인키와 계좌주소의 관계가 1:1이 아닌 것으로 조금더 따져볼 수는 있겠으나 상황은 비슷할테고, 어려워서 넘어갔다.)

 그렇다. 결론적으로 이래가지고서는 가망이 없다. 그렇지만 이대로 포기할 수는 없다!

(참고로, 타원곡선암호화의 특성상 다수의 비밀키가 공개키와 매핑되므로 2^160 = 약 10^48 정도의 시도만으로 개인키를 알아낼 수 있다고 한다 https://horizon.kias.re.kr/23225/ 그래도 역시 저 48제곱을 33제곱만큼 줄이는데, 전 우주의 시간과 리소스가 동원되는것은 같다.)

4. 특별한 형태의 개인키가 있지 않을까?

 앞서 개인키 1로 된 계좌에 거래 기록이 있다는 것을 알았다. 그러면 다른 특별한 계좌 형태가 있는 것이 아닐까? 예를들면 개인키 값을 pi를 갖는 계좌는 어떨까?

있다!

Private key: 3141592653589793238462643383279502884197169399375105820974944592  #소수점 점만 뺀 32자리수. 16진수 문자열이긴 한데 이해해주자.
Public key:  cf9bfbdca0c087fde..(생략)..4096f2e2959f9959c88
Address:    0x7357589f8e367c2c31f51242fb77b350a11830f3

https://etherscan.io/address/0x7357589f8e367c2c31f51242fb77b350a11830f3

하지만 역시 잔고는 없다. 개인적으로 잠시나마 이 게임(?)에 빠져들어, pi말고 자연 상수 e를 가지고 해봤다. 엇 빙고! 아래 계좌로 생성된다.

https://etherscan.io/address/0xf28a2dea4608c46ffee718e5f0df1118b4eab419

잔고가 0.002 이더리움(약 $4)이 들어있다! 라고 놀래주고 싶으나, 사실 이건 필자가 오일러를 기념하는 마음으로, 송금해둔 이더리움이다. (이더리움 원장의 자연 상수 e로 된 개인키의 계좌를 발견하고 처음 입금한 것은 필자다. 영원히 이더리움 원장에 새겨둔 셈이다) 내 이더리움 계좌를 신규 생성한 후 개인키를 e 상수로 갖는 계좌와, 개인 휴대전화번호를 갖는 두 계좌에 소액 송금해두었다. 이렇게 영원히 새긴 셈이다. 이더리움이 충분하면 여러가지 개인키를 선점(?)할 수 있다. abcdef0 만 가지고 문장을 만들까도 잠깐 고민했다

 여하튼 그렇다. 이런 형태의 특별한 개인키에 숨겨둔 이더리움이 있을지도 모르겠다. 가끔씩 필자같은 마음으로 기부를 하는 사람이 있다. 위 pi 계좌의 거래를 보라.

5. 그러면 단순한 조합의 개인키로 누가 생성하지는 않았을까?

다시 조금 전에 받은 eachecker.py로 돌아가보자. 이 프로그램은 내부에 runmode = 0 이 되면 특정 패턴을 반복하는 형태로 개인키를 만들어서 비교해준다. 소스를 수정해 runmode = 1을 runmode = 0으로 고치자. 이 합성 방식은 이를테면

A. 1자리수를 0x1 ~ 0xe 까지 32번 복사하고.. (32bytes로 만들어야 하니)

B. 2자리수를 0x01 ~ 0xfe 까지 16번 복사하고.. (32bytes로 만들어야 하니)

C. 4자리수를 0x0001 ~ 0xfffe 까지 8번 복사하고.. (32bytes로 만들어야 하니)

하는 방식이다. 일단 실행을 해보자(아래는 이해를 위해 실제 소스보다 로그를 좀 더 찍은 버전임은 참고하자)

$ python3 eachecker.py

runmode 0 : repeated pattern searching...
2021-07-09 01:17:34 INFO     range : 1 15
2021-07-09 01:17:34 INFO     1111111111111111111111111111111111111111111111111111111111111111
2021-07-09 01:17:34 INFO     2222222222222222222222222222222222222222222222222222222222222222
2021-07-09 01:17:34 INFO     3333333333333333333333333333333333333333333333333333333333333333
2021-07-09 01:17:34 INFO     4444444444444444444444444444444444444444444444444444444444444444
2021-07-09 01:17:34 INFO     5555555555555555555555555555555555555555555555555555555555555555
2021-07-09 01:17:34 INFO     6666666666666666666666666666666666666666666666666666666666666666
2021-07-09 01:17:34 INFO     7777777777777777777777777777777777777777777777777777777777777777
2021-07-09 01:17:34 INFO     8888888888888888888888888888888888888888888888888888888888888888
2021-07-09 01:17:34 INFO     9999999999999999999999999999999999999999999999999999999999999999
2021-07-09 01:17:34 INFO     aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
2021-07-09 01:17:34 INFO     bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
2021-07-09 01:17:34 INFO     cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc
2021-07-09 01:17:34 INFO     dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd
2021-07-09 01:17:34 INFO     eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
2021-07-09 01:17:34 INFO     range : 2 255
2021-07-09 01:17:34 INFO     0101010101010101010101010101010101010101010101010101010101010101
2021-07-09 01:17:34 INFO     0202020202020202020202020202020202020202020202020202020202020202
2021-07-09 01:17:34 INFO     0303030303030303030303030303030303030303030303030303030303030303
2021-07-09 01:17:34 INFO     0404040404040404040404040404040404040404040404040404040404040404
2021-07-09 01:17:34 INFO     0505050505050505050505050505050505050505050505050505050505050505
2021-07-09 01:17:34 INFO     0606060606060606060606060606060606060606060606060606060606060606
2021-07-09 01:17:34 INFO     0707070707070707070707070707070707070707070707070707070707070707
2021-07-09 01:17:34 INFO     0808080808080808080808080808080808080808080808080808080808080808
2021-07-09 01:17:34 INFO     0909090909090909090909090909090909090909090909090909090909090909
2021-07-09 01:17:34 INFO     0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a0a
2021-07-09 01:17:34 INFO     0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b
2021-07-09 01:17:34 INFO     0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c0c
2021-07-09 01:17:34 INFO     0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d0d
2021-07-09 01:17:34 INFO     0e0e0e0e0e0e0e0e0e0e0e0e0e0e0e0e0e0e0e0e0e0e0e0e0e0e0e0e0e0e0e0e
2021-07-09 15:17:34 INFO     0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f0f
...

하면 무언가 random으로 하지 않았을때 생길수 있는 개인키들을 그나마 조사할 수 있다. 사실상 random으로 하면 찾아낼 확률이 없지만, 만약에 해당 개인키를 생성하는 프로그램에서 어찌하다보니 저런 패턴에 의지해서 만들게 되었다면, 훨씬 빠른 속도로 탐지가 될 수 있다. 다만, 필자도 몇시간 구동해 본 바로는 찾아지지 않았다. 병렬로 처리하고 여러대의 서버로 돌리면 상황이 좀 나아질지 모르겠다. (그래서 이더리움 지갑 주소를 생성할때는 아예 시작과 끝 영역을 충분히 제외하고, 반드시 랜덤의 개인키로 만들어야 한다)

4. 기타

 이 작업을 하면서 수학적으로 이렇게 개인키/공개키/지갑주소의 무작위처럼 보이는 매핑 관계를 정의해놓을 수 있다는 사실에 적잖이 감동 받았다. 암호학 분야를 조금 더 이해한 셈이다. 단지 어떤 논리적인 코드만으로 전 우주보다 큰 매핑 관계를 구성하고 역으로 알아낼 수 없게 되어 있는것 아닌가. 그리고 막연히 생각했던 것보다, 실제 찾아보면 전혀(!) 나오지 않았다. 자신의 실제 돈이 저장되는 계좌는 랜덤의 개인키로 생성하므로, 로또 7번과 우주의 어딘가에 감춰놓은 상황과 같다. 분명히 어딘가에는 존재하지만, 전 우주를 뒤질 수는 없는 노릇이고, 우연히 발견할 확률은 충분히 작다. 알쏭달쏭한 설계지만, 여하튼 찾을 수가 없다.

 그러나 여전히 아직 이 탐구 과정에서 재미있는 계좌가 있다. 마지막으로 보고 가야할 계좌가 바로 이 녀석이다.

"0xdcc703c0E500B653Ca82273B7BFAd8045D85a470"

이 계좌는 개발자의 실수로 공개키에 아무것도 할당하지 않았을때 생성되는 지갑주소이다. 원래는 개인키에서 생성한 공개키로 주소를 만들어야 하는데, 변수를 잘못 넘기는 바람에, 아무값도 없는 변수를 넘기는 경우가 있고, 그때 생기는 지갑주소이다. 그런데 이 지갑주소에 무려 815 이더리움이 송금되어 있다. 거래소에서 송금 주소를 코딩할때 실수해서 넘어갔을 테다. 결국 이 계좌는 확실하게 아무도 개인키를 모르는 계좌이다. 어떤 개인키를 가지고 만들어야 공개키가 0이 되는지 모르기 때문이다. 이것만 알아내도 815 이더리움을 가질 수 있어서, 다른 문제보다는 쉽다. (다른 녀석들은 공개키도 알수가 없고, 계좌 주소만 알기 때문인데, 이건 반쯤은 왔다)

https://etherscan.io/address/0xdcc703c0E500B653Ca82273B7BFAd8045D85a470

 반복되는 개인키 검색으로 만약 이 지갑주소가 나오는 개인키를 찾아낸다면 아무런 양심의 가책없이 내 계좌로 송금하면 된다! 

그리고 여기까지 오면서 필자가 깨달은 사실이 있다. 이더리움의 계좌 보안체계는 돈을 우주보다 넓은 광활한 어딘가에 숨겨놓는 개념이다. 일반적인 암호로 보관하는 것과는 다르다. 광활한 우주 어느 좌표(개인키)에 숨겨놓는 것이다. 위치를 모르면 찾는 방법은 그걸 하나하나 방문해보는 수 밖에 없다. 그래서 그 좌표를 들키면 아주 쉽게 꺼내갈 수 있다. 그런데 들키지만 않으면 분명히 존재하는데도, 마치 존재하지 않는 것처럼 숨겨둘 수 있다. 그리고 그 좌표를 나도 잊으면, 실질적으로 영원히 찾을 수 없다. 그 좌표(정보)를 알고 있는 사람이 그 돈의 주인다. 그게 이 지갑 체계의 비밀이다.

 이런 단순하지만 효과적인 방법을 고안하다니. 처음 개발했을 사람에게 놀랄 따름이다. 물론 과거로부터 잘 알려진 사실을 사토시 나카모토가 응용한 것이지만 말이다.

5. 정말 개인키를 찾아내면 어떻게 하죠?

 사실은 이 과정을 진행하면서, 개인키를 찾는 상상은 했지만, 실제로 찾아낸 후 어떻게 할지는 고민이 되었다. 암호화폐의 계좌 소유주라는 개념은 불친절하게도 시스템 입장에서는 개인키를 소유하고 있느냐로 판단하기 때문에, 실제로 도덕적인 문제가 좀 누그러지기도 했다. 그렇다고 계좌 주인에게 물어볼 방법도 없는게 사실이다(역시 실명화된 체계가 아니기 때문에, 알 수 없기 때문이다)

 그러나 위에서 소개한 계좌처럼, 아무도 개인키를 모르는 혹은 누구도 괴롭힐 일이 없는 개인키가 잊혀진 계좌라고 가정해보자. 

 그러면 해당 알아낸 개인키로 계좌를 개설하여 내 계좌로 송금하면 된다. geth같은 이더리움 클라이언트를 설치해 이 과정을 수행할 수 있다. 이건 역시 조금은 복잡하기 때문에 링크로 안내하자. syncmode를 light로 실행하면 10분안에 필요한 동기화가 완료되고, 잔액 조회 및 송금 명령을 실행할 수 있다.  ( https://infoengineer.tistory.com/52 ) geth를 main net에 붙이기 전에 우선 해당 발견한 개인키로 계좌는 생성해 두어야 한다. 아래 명령으로 개인키 32 bytes 16진수 문자열을 통해 가능하다.

Ex>

$ echo "0000000000000000000000000000000000000000000000000000000000000001" > plain_key1.txt
$ geth --datadir . account import plain_key1.txt          #데이터 디렉토리가 현재디렉토리인 경우

 결론이 드라마틱하지 못해서 사실은 필자도 서운하다. 자, 태양을 모두 태워서 이더리움 계좌의 개인키를 알아낼 준비가 되었는가? 이 글 가운데 소개한, 필자가 숨겨둔 작은 돈을 찾아볼 수도 있겠다.

6. 비트코인은 어떻게 하죠?

이더리움과 방법이 거의 같다. 둘은 거의 쌍둥이와 같은 계좌 암호 체계를 지니기 때문이다. 다만 비트코인 계좌 목록은 여기서 다운로드가 가능하다. 대략 천만개 정도 계좌면, 0.001 비트코인 이상 보유한 계좌라고 볼 수 있어서 그정도 하면 충분하다.

http://addresses.loyce.club/

이를 테면 balance를 모두 포함한 최신 파일을 받은 후에  아래와 같이 가공할 수 있다. 상위 12백만개의 주소만 고르고, 첫번째 컬럼만 저장한다.

$ head -n 12000000 bitcoin_address_list.tsv > bitcoin_address_12k.tsv

$ cut -f1 bitcoin_address_12k.tsv > bit.txt

아래와 같은 형식인지 확인한다.

$ more bit.txt

address

1MGzSFisX6M1NaiTpi1MXqgzson2iNUcbk

1...

..

python code는 아래 소스를 활용한다. eachecker.py와 유사한 구조로 만들어 두었다.

https://github.com/neibc/bitcoin/blob/main/btchecker.py

그리고 동일한 실험을 한다. 상기 소스내 example() 함수로 여러가지 앞서의 개인키에 의한 지갑주소를 확인할 수 있다. pi 개인키나 1개인키는 여기에도 존재한다.

pi 개인키 계좌 : https://www.blockchain.com/btc/address/1MGzSFisX6M1NaiTpi1MXqgzson2iNUcbk

"1" 개인키 계좌 : https://www.blockchain.com/btc/address/1EHNa6Q4Jz2uvNExL497mE43ikXhwF6kZm

나머지들은 같은 방법(runmode를 바꾸면서)으로 구동하여 확인할 수 있다. 정말 개인키를 찾으면 어떻게 해야하나?

bitcoin core오픈소스를 받아 bitcoind 설치/실행 한 후 bitcoin-cli 등을 통해 importprvkey를 실행한 후 유사한 방법으로 송금하면 된다(조금더 공부가 필요하다)

아래는 힌트가 될 명령어만 소개해보자. btchecker.py에 나온 prvkey를 활용하자(2개 형태가 있으니 아래 예시 통해 잘 구별해 사용하자)

$ bitcoin-cli walletpassphrase "#PASSWORD#" 60

$ bitcoin-cli importprivkey "5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreAnchuDf" acc_num1
$ bitcoin-cli importprivkey "5JByjwbxuGsu7GQTpUfR5bSRA4p8WuSaoK3UbsFv13Ns6dLGkeZ" acc_pi
$ bitcoin-cli listlabels
[
  "",
  "acc_num1",
  "acc_pi"
]

$ bitcoin-cli getaddressesbylabel acc_pi
{
  "1MGzSFisX6M1NaiTpi1MXqgzson2iNUcbk": {
    "purpose": "receive"
  }
}
$ bitcoin-cli getaddressesbylabel acc_num1
{
  "1EHNa6Q4Jz2uvNExL497mE43ikXhwF6kZm": {
    "purpose": "receive"
  }
}

행운을 빌어본다.

이더리움 keystore에 대해서는 아래 한글과 영문자료로 우선 전체를 이해할 필요가 있다.

https://julien-maffre.medium.com/what-is-an-ethereum-keystore-file-86c8c5917b97

결국 둘다 같은 내용이다.

https://medium.com/hexlant/%EC%9D%B4%EB%8D%94%EB%A6%AC%EC%9B%80-keystore-%ED%8C%8C%EC%9D%BC-utc-%EC%83%9D%EC%84%B1-%EB%B0%8F-%EC%95%94%ED%98%B8%ED%99%94-%EB%B3%B5%ED%98%B8%ED%99%94-%EC%9B%90%EB%A6%AC-1-2-d417cb605bf

그러면 이 둘에 해당하는 key들을 직접 생성할 수 없을까?

linux에서 openssl정도로 가능한데, 아래 자세히 설명되어 있다.

https://kobl.one/blog/create-full-ethereum-keypair-and-address/

key생성하는 전체 코드(Complete example, linux가정)

# Generate the private and public keys

# openssl을 통해 타원곡선 사용해 개인키/공개키를 생성한다

> openssl ecparam -name secp256k1 -genkey -noout | openssl ec -text -noout > Key

# Extract the public key and remove the EC prefix 0x04

# Key에서 공개키를 추출하고 prefix를 제거한다

> cat Key | grep pub -A 5 | tail -n +2 | tr -d '\n[:space:]:' | sed 's/^04//' > pub

# Extract the private key and remove the leading zero byte

# Key에서 개인키를 추출하고 앞의 00 byte를 없앤다

> cat Key | grep priv -A 3 | tail -n +2 | tr -d '\n[:space:]:' | sed 's/^00//' > priv

# Generate the hash and take the address part

# 해쉬값을 생성해서 주소를 만들어 낸다

# linux에서는 $ git clone https://github.com/vkobel/ethereum-generate-wallet 한 후에 ethereum-generate-wallet/lib/x86-64/keccak-256sum을 활용한다

> cat pub | keccak-256sum -x -l | tr -d ' -' | tail -c 41 > address

  *0xdcc703c0E500B653Ca82273B7BFAd8045D85a470 처럼 생긴 주소는 비어있는 공개키로 생성된 것이라 주의해야 한다.

  재미있게도 이렇게 잘못 생성한 주소로 돈을 보낸 사람이 적지 않다. 여기서 볼 수 있다. etherscan

   ex> $ touch empty; cat empty | keccak-256sum -x -l | tr -d ' -' | tail -c 41

# (Optional) import the private key to geth

# geth로 개인키를 가지고 실제 맞는지 검증해볼 수 있다

> geth account import priv

ex> $ ./geth --datadir "/Users/neibc/dev/geth/data2" --networkid 2125 account import prv  #prv파일에 위 prv 저장 가정

        출력되는 geth의 address가 상기의 생성한 address와 맞는지 확인한다.

마지막으로 또 재미있는 것은 0x7e5f4552091a69125d5dfcb7b8c2659029395bdf 라는 주소이다. 이 지갑주소는 private key가 알려져있다. 아래를 참조해보자. ( https://lsongnotes.wordpress.com/2018/04/30/manually-decrypting-ethereum-keystore-file/ )

Ex>

$ echo "0000000000000000000000000000000000000000000000000000000000000001" > plain_key1.txt
$ geth –datadir . account import plain_key1.txt

etc...

$ echo "3141592653589793238462643383279502884197169399375105820974944592" > plain_key2.txt
$ geth –datadir . account import plain_key2.txt

$ echo "2718281828459045235360287471352662497757247093699959574966967627" > plain_key3.txt
$ geth –datadir . account import plain_key3.txt

이렇게 하면 위 주소가 나온다. 신기하게도 누군가 이 계좌로 소액을 입금하고 있으며, 입금 즉시 곧바로 출금한다.

https://www.blockchain.com/eth/address/0x7e5f4552091a69125d5dfcb7b8c2659029395bdf

앞서의 여러가지 mainet이나 사설로 geth를 구성하는 방법을 가이드 했었다. 그렇게 일단 구성을 한다.

ubuntu linux와 geth 1.10.4버전하에서 수행하였으나 대부분의 linux에서 잘 작동하리라고 믿는다.

그리고 나서 아래와 같이 geth를 실행한다. miner.etherbase는 채굴한 금액이 입금될 지갑주소이다.

$ cd geth설치폴더

$ ./geth --datadir "/work/neibcprv" --allow-insecure-unlock --http --miner.etherbase "0xb98df66662a586461b668e9ab81383d2b0d341da" console

이렇게 하면 http://127.0.0.1 인터페이스를 통해 ethminer를 구동할 수 있다.

(다만 저 allow-insecure-unlock옵션은 내부 태스트용일때만 사용하자, 다른 안전한 방법을 확인중이다)

ethminer는 이더리움 전용 채굴 툴이다. 해당 툴의 gpu구성이나 설치는 사실 다른 강의를 참조하면 된다.

https://blog.boxcorea.com/wp/archives/3012

설치가 모두 끝났다면 아래와 같이 입력한다. 물론 geth가 실행된 상태여야 한다. 상기 콘솔에서도 miner도 시작해주고 거래도 일으키자.

> miner.start()

이후에 아래처럼 ethminer를 실행시켜 준다.

$ ./ethminer -P http://127.0.0.1:8545

ethminer 0.19.0-17+commit.ce52c740
Build: linux/release/gnu

 i 16:54:29 ethminer Configured pool 127.0.0.1:8545
 i 16:54:29 ethminer Selected pool 127.0.0.1:8545
 i 16:54:29 ethminer Established connection to 127.0.0.1:8545
 i 16:54:29 ethminer Spinning up miners...
cu 16:54:29 cuda-0   Using Pci Id : 01:00.0 GeForce GTX 1070 (Compute 6.1) Memory : 6.90 GB
 X 16:54:29 ethminer Got code:-32000 message:no mining work available yet  from 127.0.0.1:8545
 m 16:54:34 ethminer 0:00 A0 0.00 h - cu0 0.00
..

cu 17:00:51 cuda-0   Job: 2fe6ca74… Sol: 0x5e2c787b34bdc0a0
 i 17:00:51 ethminer **Accepted   9 ms. 127.0.0.1:8545
 i 17:00:51 ethminer **Accepted  29 ms. 127.0.0.1:8545
cu 17:00:51 cuda-0   Job: 2fe6ca74… Sol: 0x5e2c787b34d2809f
cu 17:00:51 cuda-0   Job: 2fe6ca74… Sol: 0x5e2c787b34d451d2
 i 17:00:51 ethminer **Accepted   2 ms. 127.0.0.1:8545
 i 17:00:51 ethminer **Accepted  12 ms. 127.0.0.1:8545

..

이후 nvidia-smi같은 tool로 GPU가 실제 작동하고 있는지 확인한다. GPU로 채굴하는 것을 알 수 있다.

전번편에서 간단하 geth를 다운로드 받아 구동하는 방법을 설명하였다. 사설망용 geth도 동일한 프로그램을 다운로드 받아 구성하면 된다.

아래 사이트에서 tar.gz 파일을 받아 역시 압축을 풀어보자. ubuntu linux/Geth 1.10.4 64 bit를 기준으로 하자.

https://geth.ethereum.org/downloads/ (처음에 로딩될때 버전을 참조하느라 조금 시간이 걸린다)

전체적인 과정은 아래를 참조했다. 공식 페이지이며 버전이 올라갈때마다 적절히 수정되는 것을 기대할 수 있다.

https://geth.ethereum.org/docs/interface/private-network

A. 파일을 다운로드 한 후 계정을 생성해보자.

$ mkdir /work/                     #프로그램 압축을 풀 폴더

$ mkdir /work/neibcprv     #이더리움 데이터 파일을 보관할 폴더

$ cd /work/

$ tar xvfz geth-alltools-linux-amd64-1.10.4-aa637fd3.tar.gz   # /work/에 다운받은 tar.gz가 복사되어 있다고 가정

$ cd geth-alltools-linux-amd64-1.10.4-aa637fd3     #설치후 짧은 이름으로 변경해서 사용해도 좋다.

$ ls

... geth ...

우선 geth에서 기초적으로 쓸 계좌를 2개 생성한다. 계좌를 만든다는 것은 잘 알려진대로 비밀키와 공개키, 지갑주소를 만들어 파일로 보관하는 방법이다. 비밀키는 별도의 암호를 물어 암호화하여 저장한다.

$ cd /work/geth-alltools-linux-amd64-1.10.4-aa637fd3

$ ./geth account new --datadir "/work/neibcprv"

 <-- 암호를 입력하면 /work/neibcprv/keystore에 해당 정보가 저장된다. 암호는 잘 보관해주자. 나중에 송금을 할때 암호를 입력해야 해당 개인key를 쓸 수 있다.

$ ./geth account new --datadir "/work/neibcprv"

$ ls -al /work/neibcprv/keystore
total 16
drwx------ 2 neibc neibc 4096  7월  3 16:42 .
drwxrwxr-x 4 neibc neibc 4096  7월  4 01:28 ..
-rw------- 1 neibc neibc  491  7월  3 16:42 UTC--2021-07-03T07-42-11.924219581Z--2d75914e826c023beaa98a4c05db1be808c4aaa3
-rw------- 1 neibc neibc  491  7월  3 16:42 UTC--2021-07-03T07-42-31.709155899Z--2276b96e62c9394d76fbdc59f451688a55f99d1f

파일을 열어보면 아래와 같이 나옴을 알 수 있다. 2개 만든 계좌중의 하나에 대한 정보이다.

$ cd /work/neibcprv/keystore/

$ more UTC--2021-07-03T07-42-11.924219581Z--2d75914e826c023beaa98a4c05db1be808c4aaa3 
{"address":"2d75914e826c023beaa98a4c05db1be808c4aaa3","crypto":{"cipher":"aes-128-ctr","ciphertext":"f60bbcbe58da59504a8e1cebecafaf4
0125a4fc69420d15f4e50bc58540c6461","cipherparams":{"iv":"151a19efcd65491a1839cff7994e0099"},"kdf":"scrypt","kdfparams":{"dklen":32,"
n":262144,"p":1,"r":8,"salt":"f4fb417173cb2d53cb50226c14952d8994c5b4329e8dcc244c8f4a0f7c0c166f"},"mac":"b927a65a182f79e865eb30521dad
38ea712647bd60bdba14359e32ce9465c30c"},"id":"c4ea17f1-08cd-4ba2-b8d3-d1f6bfba8a2e","version":3}

이더리움 계좌는 이렇게 local에서 우선 네트워크에 접속되어 있지 않고 생성되어  datadir/keystore/에 관련 정보를 남기는 게 전부이다. 이런 과정들의 세부가 궁금한가? 그러면 아래 URL을 참조해보자.

https://medium.com/hexlant/%EC%9D%B4%EB%8D%94%EB%A6%AC%EC%9B%80-keystore-%ED%8C%8C%EC%9D%BC-utc-%EC%83%9D%EC%84%B1-%EB%B0%8F-%EC%95%94%ED%98%B8%ED%99%94-%EB%B3%B5%ED%98%B8%ED%99%94-%EC%9B%90%EB%A6%AC-1-2-d417cb605bf

B. 다음에는 사설로 이더리움을 구성하기 위해 genesis파일을 작성하여 geth를 실행해보자.

ethereum 사설망은 PoW방식의 ethash모드와 좀 다른 형태(Proof of Authority)의 고속의 clique 방식이 있는데, 보통 ethereum에서는 clique을 추천한다. 하지만 여기서는 실제 사용되는 ethash모드로 진행하도록 하자.(대규모 개발 시험을 위해서는 clique로 하면 편하겠다. 상세 내용이나 파라메터에 대해서는 해당 공식 문서를 참조한다.(https://geth.ethereum.org/docs/interface/private-network)

ethash모드로 사설 이더리움망을 구성하려면 json파일을 하나 구성해야 하는데, genesis.json이라고 칭해보자.

간단하게 하나 만들어준다.

$ cat > /work/neibcprv/genesis.json

{
  "config": {
    "chainId": 2125,
    "homesteadBlock": 0,
    "eip150Block": 0,
    "eip155Block": 0,
    "eip158Block": 0,
    "byzantiumBlock": 0,
    "constantinopleBlock": 0,
    "petersburgBlock": 0,
    "ethash": {}
  },
  "difficulty": "1",
  "gasLimit": "8000000",
  "alloc": {
    "2d75914e826c023beaa98a4c05db1be808c4aaa3": { "balance": "10000000000000000000" },
    "2276b96e62c9394d76fbdc59f451688a55f99d1f": { "balance": "10000000000000000000" }
  }
}

그리고 아래와 같이 init을 해준다. 이렇게 하면 위 genesis파일에 기초하여 필요한 기초 파일을 생성해주고 초기 셋팅을 해준다. 초기 배정 금액 alloc/balance는 wei단위(10^18 wei = 1 이더리움)라서 100이더리움(100000000000000000000 wei)이 배정되었다

$ cd /work/geth-alltools-linux-amd64-1.10.4-aa637fd3

$ ./geth init --datadir "/work/neibcprv" /work/neibcprv/genesis.json

이렇게 실행하면 /work/neibcprv/에 geth폴더 등이 생긴다. 그리고 나서는? 실제로 실험을 해봐야한다.

아래와 같이 networkid 옵션에 위 genesis의 chainId인 2125를 그대로 넣어주고 여러가지 명령 수행을 위해 console이라고 입력한다. 그리고 나서 간단한 송금과 채굴을 해보자.

$ ./geth --datadir "/work/neibcprv" --networkid 2125 console

...

....

> primary = eth.accounts[0];    #여기서 만든 첫번째 계좌
"0x2d75914e826c023beaa98a4c05db1be808c4aaa3"
> secondary = eth.accounts[1];   #여기서 만든 두번째 계좌
"0x2276b96e62c9394d76fbdc59f451688a55f99d1f"

> miner.setEtherbase(primary);       #이체 채굴을 하면 첫번째 계좌로 돈이 들어간다.

> miner.start();                                  #채굴을 시작하자. 채굴을 하지 않으면 거래가 발생하지 않고 이더리움이 생기지도 않는다.

> personal.unlockAccount(primary);   #송금을 하기 위해 첫번째 계좌의 암호를 입력해보자.

> eth.sendTransaction({from: primary, to: secondary, value: web3.toWei(1, "ether")});  #1번계좌에서 2번계좌로 1이더리움을 송금한다.

> balance = web3.fromWei(eth.getBalance(primary), "ether");

첫번째 계좌의 현재 잔액이 표시된다.

> balance2 = web3.fromWei(eth.getBalance(secondary), "ether");

두번째 계좌의 현재 잔액이 표시된다.

자 간단하게 이더리움 서버를 사설로 구성하여 계좌를 만들고, 채굴도 하고, 돈을 송금하고 잔액을 확인해보았다.

마지막으로 nohup으로 백그라운드로 geth를 실행하는 예시다. mining도 실행되도록 mine옵션을 주었다.

$ ./geth --datadir "/work/neibcprv" --networkid 2125 --mine --minerthreads "1" 2>> /work/neibcprv/geth.log &

개인적으로 이더리움 노드에 참여해 볼수 없을까? 어려워보이지만 시작은 우선은 쉽다.

(하지만 정상적인 full mode sync를 위해서는 16gb이상, 500gb급 ssd가 필요하다. 사양이 떨어지면 light mode를 사용하자.)

 이더리움 노드 서버 혹은 클라이언트인 geth를 다운로드 받아 구동하면 된다. 여기서는 geth 1.10.4 버전 ubuntu linux에서 작동시켰다. 다만, geth는 go언어로 만들어져서 거의 모든 OS를 지원하므로, 다른 OS에서도 아래와 유사한 방식으로 구동할 수 있을 것이다.

https://geth.ethereum.org/downloads/

여기서 Geth 1.10.4 Linux 64bit 버전을 다운로드 받자(Tools가 같이 있는 버전을 받아도 좋다. 아래는 geth & tools를 기준으로 한다.) 필자는 Ubuntu 18.04기반으로 작업하였다. 다운로드를 받아 적절한 디렉토리에 압축을 풀면 go로 된 단순한 명령어들을 볼 수 있다.

아래는 /work/gethdata에 여러가지 데이터를 저장하고, /work/밑에 프로그램을 압축 푼다고 가정해보자.

$ mkdir /work/        #프로그램 설치 폴더 생성

$ mkdir /work/gethdata  #데이터 폴더 생성, 각종 정보 파일과 계좌를 만들때의 정보 등을 담게 된다

$ cd work

$ tar xvfz geth-alltools-linux-amd64-1.10.4-aa637fd3.tar.gz

....

$ cd geth-alltools-linux-amd64-1.10.4-aa637fd3

$ ls

abigen bootnode clef COPYING evm geth puppeth rlpdum

이상태에서, 아래와 같이 실행하면 곧바로 이더리움 노드에 참여하게 된다(networkid 1)

단순 기능 확인만을 위한 저사양용 light mode와 일반 안정적인 채굴등을 위한 fast mode두가지 실행 방식을 적어본다.

$ ./geth --datadir "/work/gethdata"  --syncmode "light" console  #기본 기능만 테스트하기 위해서는 light mode를 추천

혹은

$ ./geth --datadir "/work/gethdata"  console    #fast mode이며 datadir을 지정하지 않으면 ~/.ethereum/에 생성된다.

이 datadir의 위치를 바꾸면 모든 것이 리셋되고 다시 해당 datadir을 기준으로 다운받아 작동하게 되니 쉽게 리셋할 수 있다.

(다음에는 이렇게 mainnet에 참여하는게 아니라 여러가지 시험을 해볼 수 있는 사설 네트워크를 구성해보자. 이렇게 되면 나만의 이더리움 네트워크를 구성할 수 있다.)

아래 console에서 다양한 실제 작업을 할 수 있다. 간단한 명령을 살펴보자.

주소를 몇개 정의한 후 밸런스를 확인하고 계정에 암호를 입력한 후 송금하는 예시이다. 이건 따로 조사를 해 본 후 실행하기를 바란다.

> secondary = '0xb98df66662a586461b668e9ab81383d2b0d341da';
> third = '0xfd0e3e0c475a2feddfd681c599721a1b273fa78d';
> balance = web3.fromWei(eth.getBalance(secondary), "ether");

> personal.unlockAccount('0xb98df66662a586461b668e9ab81383d2b0d341da');
> eth.sendTransaction({from: secondary, to: third, value: web3.toWei(4.95, "ether"), nonce:0, gas: 300000});

#sendTransaction의 nonce는 총 출금한 개수다. 처음에는 0, 그 다음에는 1을 붙이자.

다만 main net에 제대로 참여하기 위해서는 geth가 전체 blockchain의 block들이 전부 sync(다운로드)되어야 한다.

geth 홈페이지에 따르면 4 core / 16gb ram / 500gb 이상의 ssd를 추천사양으로 이야기한다. (필자가 100%정도 sync되었을때 용량이 360GB였다) 모두 sync하는 데에는 2~3일 정도 소요되었다. ssd를 추천하는 이유는 sync를 제대로 하기 위해서는 고속의 I/O가 필요하기 때문이라고 한다. sync여부는 위 geth console에서 아래와 같이 확인 가능하다

> eth.syncing

{

  currentBlock: 12780722

  highestBlock: 12780722

  ..

}

이렇게 currentBlock과 highestBlock이 같은 값이면 sync가 100%완료된 상태이다. 그런데 disk I/O가 충분히 빠르지 않으면 이것이 100%sync가 잘 되지 않는다.

geth는 내부적으로 fast mode, full mode, light mode 3가지가 존재하는데 디폴트는 fast mode이다. hardware사양이 낮고 적은 용량만 가진 서버에서는 light mode를 확인하여 해당 방식으로 구동하는 것이 가능하다. 10분에 기초 동기화가 되고 300mb정도의 용량만으로도 유지가 가능하다고 한다. 다만 이 light mode는 다른 노드의 도움을 받아야만 정상적인 처리가 가능하여 해당 노드에 의존하므로 처리 속도가 느리다고 알려져 있다. 채굴도 불가능하다. light mode는 geth실행시에 --syncmode "light" 만 추가하면 되어 소형 기기용으로 많이 추천되고 있는 모양이다.

$ ./geth --datadir "/work/gethdata"  --syncmode "light" console  

그리고 용량 문제는 main net에 붙을때만 그렇고 private node를 운영할때는 큰 용량을 필요로 하지 않는다. 마음껏 fast mode/full mode로 하면 된다.

그리고 ethereum main net의 상태는 아래 사이트를 통해 지갑 등을 확인할 수도 있으니 비교할시에 참고하기 바란다.

https://etherscan.io/

 정보이론 서적에서 언급되는 분야중에 흥미로운 것은 DNA 분야이다. DNA는 정보로 가득차있기 때문이다. 인간의 경우만 놓고 보아도 30억쌍의 ATGC... 배열로 된 유전자 정보를 1개의 세포가 온전히 매우 안정되게 포함하는 셈이고, 1개의 수정란에서 인간의 모든 것이 시작되어 생명을 형성한다.

 흥미롭게도 이 관점에서 왜 불로장생이 어려운지에 대해서 다양한 학설이 나왔는데, 아래가 간단히 정리해놓은 글이다.

scienceon.hani.co.kr/548962

 핵심 논리는 이 DNA의 복제와 오류에 있다. 한 개의 수정란에서 시작된 인간의 세포체계는 지속 세포를 복제하여 신체를 만들어가는데 그 오류율이 상당히 낮고 잘못 복제된 DNA를 보정하는 기능까지 보유하고 있다. 그러나 오류율이 낮아도 없는 것은 아니다. 세포가 지속적으로 복제되고 교체되면서 작은 오류라도 점점 더 커지게 마련이다. 모든 세포에 대해 단일의 절대적인 기준을 두고 대사하면서 모든게 처리되지 않는다. 계속 복제되어 가면서 기존의 것과 최대한 같게 하려고 하지만 한번 오류가 발생하면 다시 복제될때는 그 오류가 전파된다. 따라서 생명체 입장에서 이 일관성 유지 문제는 난감한 일이다. 모든 세포가 하나의 원본을 수시로 참조할 수 없다. 그렇다고 DNA서열 전체를 hashing해서 비교해보고 버리지도 못한다.

 복제 과정에서 무엇이 정상적인 원본인지 알 수 없으며, 정보가 너무 크기 때문에(30억쌍) 비교하기도 어려운 것이다. 맨 처음 수정란에서 시작된 DNA정보는 오류의 축적을 피할 수가 없는 것이고, 이 부분에서 생명체는 공학적인 완성을 이루지는 못했다.

 이 전체적인 DNA의 정보전달 방식이나 변형 가능성은 노화와 암, 진화 모두에 영향을 끼치게 된다. DNA가 더 복잡할수록 더 많은 단계를 거칠수록 오류율이 높아진다. 오류율이 높아지면 오작동이 커지는데, 그 결과 새로 복제된 세포들은 필연적으로 불완전해진다. 더군다나 원본에서 더 멀어질수록(나이가 먹을수록) 더 불완전해진다.

 가끔씩은 생명을 진화시키는 돌연변이도, 이 불완전의 메카니즘을 바꾸지는 못했다. 아마도 유전자 시퀀싱 기술을 통해서 노화가 일어나는 단계별로 몸 전체 세포의 DNA 정보 불일치를 추적해나갈 수 있다면 더 자세히 이 과정의 진화를 알 수 있게 될 수 있겠다.

 그리고 태아 상태에서의 DNA 정보 변형은 치명적일 수 있다. 그 영향이 이후 복제된 수많은 세포들에 처음부터 영향을 끼치기 때문이다. 여하튼 또한 이러한 변형은 어떤 면에서는 돌연변이가 변화에 적응하여 진화하는 그 과정에도 기여하게 된다. 

 정보이론 관점에서 이러한 DNA문제를 파헤치면 여러가지 뜻깊은 사실들을 더 알 수 있지 않을까? 노화나 오류의 진전, 진화 이런 것들이 모두 영향을 받을 수 있다. 사실 그런 의미에서 간단히 이 이론들을 소개해 본 것이다.

 좀더 덧붙여보면 향후에 이 DNA 일관성을 외부 공학적인 방법을 사용해 유지할 수 있는가도 흥미로운 미래 이슈가 아닐 수 없다. 최근에 DNA변형된 세포를 찾아내 파괴하도록 하는 암 치료법이 소개되었는데, 이 방법은 변형된 DNA를 하나하나 검출해서 코딩해줘야만 파괴할 수 있다. 불행히도 아직 기술은 어떤 기준 원본 DNA를 만들어서 그것과 변형된 것을 찾아내어 파괴하지는 못한다.

www.monews.co.kr/news/articleView.html?idxno=301452

이런 상황인데 만약에 DNA 변형이 전혀 불가능해지도록 하는(변형되면 무조건 파괴하는) 생명공학이 발견되면 어떨까?

그야말로 이론적으로는 불로불사의 시대가 열리게 되겠다(물론 다른 것도 해결되어야 할 수 있겠지만, 여하튼 기초가 되겠다. 오작동이 없어진다). 어느 정도의 기술발전이 되면 미래의 꿈의 기술 후보가 될 수 있지 않을까.

짐 홀트의 책 "아인슈타인이 괴델과 함께 걸을때'를 보면 무한을 최초로 정확히 해명한 수학자로 알려진 칸토어가 한 업적이 나온다.

첫째는 어떤 두가지의 무한이 서로 본질적으로 같다는 것을 증명하는 방법(무한한 자연수와 유리수가 같다)과 그렇게 같지 않은 더 큰 계위의 무한이 존재하며, 늘 그 무한을 원소로하는 집합을 재창조함으로서 그것이 가능하다는 증명을 했다는 점이다.

흥미롭게도 이 관점은 엔지니어로서는 무한이라는 것을 컴퓨터로 구현한다는 관점에서 바라볼 수 있다.

사실상 무한이라는 것은 단순히 큰 메모리를 할당하는 것으로는 구현할 수 없다. 이를 테면, 전체를 나타내기 위해서는 메모리가 부족하게 된다. 그래서 흔히들 컴퓨터에서의 변수의 크기는 가질 수 있는 값의 범위를 제한하여 격리한다. 그런데 사실, 잘 설계하면 셀수 없이 늘어나는 것을 담을 수 있게 설계는 할 수 있다(물론 메모리가 충분히 커야하는 것은 어쩔 수 없다)

돌이켜보면 0과 1사이의 유리수 값이나, 전체 정수값이나 사실은 본질은 같은 것이다. 왜 그런가 하면 두 무한한 수 체계를 나타내기 위해 구현해야 하는 컴퓨터 코드가 크게 다르지 않기 때문이다.

즉 유리수와 정수는 생긴 모양은 다르지만 무언가 특정해야할 하나의 값이고, 같은 비용을 들여서 구현할 수 있다는 말이다. 생긴 것은 다르지만 1:1로 매핑이 가능한 본질적으로 같은 구현으로 해소가능하다.

예를 들면, 무한의 수를 나타내는 것은, 앞서의 고정된 메모리를 범위로 간단히 할당하는 것 외에, linked list같이 나타낼 수 있다. 

가장 간단하게는 2진수를 무한히 표기할 수 있도록 하는 방법을 생각해보자.

2개의 bit를 가지고 그 왼쪽 bit는 더 상위비트가 존재하는지, 오른쪽 bit는 그 자리수의 bit값 형태로 나타내고 필요에 따라 계속 2개의 bit씩 늘려가면 무한한 값을 encoding할 수 있다.

실제 예를 들면, 자리수가 정해진 1 0 1 (2)는  11 10 01 (encoded 2, 앞 bit가 다음 자리수의 존재여부) 같은 형태로 나타낼 수 있다는 말이다. 그러면 이 체계는 곧바로 정수와 유리수 모두를 나타냄에 있어서 사실 크게 다르지 않다. 칸토어가 제시한 1:1 대응 방법으로 이름만 붙이면 그만인것이다. 그 두개의 집합은 같은 무한의 체계이며 기계적인 구현이 같다.

칸토어의 업적은 따라서 무한의 수 체계를 기계적으로 나타내기 위한 구체적인 구현 동의성을 나타냈다라고 은유할 수 있다. 그렇게 인류는 무한을 기존의 여러가지 추상적인 관점에서, 더 구체화하여 이해했다고 생각한다.