멍개의 연구소

[ethereum] foundry를 이용하여 스마트 컨트랙트 개발하기

멍개. — Mon, 17 Feb 2025 17:57:20 +0900

안녕하세요 멍개입니다.

이번글에서는 foundry을 이용하여 스마트 컨트랙트를 개발하는 방법을 다룹니다. foundry는 truffle, hardhat 처럼 스마트 컨트랙트 개발을 도와주는 도구입니다.

foundry는 4개의 명령 도구를 제공합니다.

forge: test, compile, build, deploy
cast: rpc 통신
anvil: local testnet
chisel: REPL

● 셋업

foundry는 공식문서를 통해 설치 가이드를 확인할 수 있습니다. foundry는 rust 기반이기 때문에 rust가 설치되어 있어야 합니다.

https://book.getfoundry.sh/getting-started/installation

Foundry Book

A book on all things Foundry

book.getfoundry.sh

foundry에서 스마트 컨트랙트 개발/테스트/배포하는 과정은 forge를 이용합니다.

· 프로젝트 생성

$ forge init helloworld-contracts

Initializing /Users/jeongtaepark/Desktop/helloworld-contracts...
Installing forge-std in /Users/jeongtaepark/Desktop/helloworld-contracts/lib/forge-std (url: Some("https://github.com/foundry-rs/forge-std"), tag: None)
'/Users/jeongtaepark/Desktop/helloworld-contracts/lib/forge-std'에 복제합니다...
remote: Enumerating objects: 1978, done.
remote: Counting objects: 100% (829/829), done.
remote: Compressing objects: 100% (191/191), done.
remote: Total 1978 (delta 762), reused 642 (delta 638), pack-reused 1149 (from 5)
오브젝트를 받는 중: 100% (1978/1978), 692.79 KiB | 13.86 MiB/s, 완료.
델타를 알아내는 중: 100% (1291/1291), 완료.
    Installed forge-std v1.9.5
    Initialized forge project

$ tree .

.
├── README.md
├── foundry.toml
├── lib
│   └── forge-std
│       ├── CONTRIBUTING.md
│       ├── LICENSE-APACHE
│       ├── LICENSE-MIT
│       ├── README.md
│       ├── foundry.toml
│       ├── package.json
│       ├── scripts
│       │   └── vm.py
│       ├── src
│       │   ├── Base.sol
│       │   ├── Script.sol
│       │   ├── StdAssertions.sol
│       │   ├── StdChains.sol
│       │   ├── StdCheats.sol
│       │   ├── StdError.sol
│       │   ├── StdInvariant.sol
│       │   ├── StdJson.sol
│       │   ├── StdMath.sol
│       │   ├── StdStorage.sol
│       │   ├── StdStyle.sol
│       │   ├── StdToml.sol
│       │   ├── StdUtils.sol
│       │   ├── Test.sol
│       │   ├── Vm.sol
│       │   ├── console.sol
│       │   ├── console2.sol
│       │   ├── interfaces
│       │   │   ├── IERC1155.sol
│       │   │   ├── IERC165.sol
│       │   │   ├── IERC20.sol
│       │   │   ├── IERC4626.sol
│       │   │   ├── IERC721.sol
│       │   │   └── IMulticall3.sol
│       │   ├── mocks
│       │   │   ├── MockERC20.sol
│       │   │   └── MockERC721.sol
│       │   └── safeconsole.sol
│       └── test
│           ├── StdAssertions.t.sol
│           ├── StdChains.t.sol
│           ├── StdCheats.t.sol
│           ├── StdError.t.sol
│           ├── StdJson.t.sol
│           ├── StdMath.t.sol
│           ├── StdStorage.t.sol
│           ├── StdStyle.t.sol
│           ├── StdToml.t.sol
│           ├── StdUtils.t.sol
│           ├── Vm.t.sol
│           ├── compilation
│           │   ├── CompilationScript.sol
│           │   ├── CompilationScriptBase.sol
│           │   ├── CompilationTest.sol
│           │   └── CompilationTestBase.sol
│           ├── fixtures
│           │   ├── broadcast.log.json
│           │   ├── test.json
│           │   └── test.toml
│           └── mocks
│               ├── MockERC20.t.sol
│               └── MockERC721.t.sol
├── script
│   └── Counter.s.sol
├── src
│   └── Counter.sol
└── test
    └── Counter.t.sol

13 directories, 58 files

▶ foundry.toml: 프로젝트 정보를 가집니다. 해당 파일은 여러 옵션 정보를 가질 수 있으며, 깃허브에서 어떤 옵션 정보를 가질 수 있는지 확인할 수 있습니다.

https://github.com/foundry-rs/foundry/blob/master/crates/config/README.md#all-options

foundry/crates/config/README.md at master · foundry-rs/foundry

Foundry is a blazing fast, portable and modular toolkit for Ethereum application development written in Rust. - foundry-rs/foundry

github.com

▶ lib: 깃허브로 다운받은 모듈을 의미합니다. 해당 모듈은 서브모듈(.gitmodules) 형태로 관리됩니다.

▶ scripts: forge script로 실행할 스크립트 코드를 관리합니다. 대표적으로 Deploy 관련 코드를 관리합니다. script 코드들은 solidity 기반으로 작성합니다.

▶ test: 테스트 코드를 관리합니다. 테스트 코드는 solidity 기반으로 작성합니다.

▶ src: 스마트 컨트랙트 소스코드를 관리합니다.

· 의존성 - submodule 기반

forge의 install을 이용하면 submodule 형태로 외부 라이브러리를 손쉽게 추가할 수 있습니다.

$ forge install transmissions11/solmate@v7

Installing solmate in /Users/jeongtaepark/Desktop/helloworld-contracts/lib/solmate (url: Some("https://github.com/transmissions11/solmate"), tag: Some("v7"))
'/Users/jeongtaepark/Desktop/helloworld-contracts/lib/solmate'에 복제합니다...
remote: Enumerating objects: 3085, done.
remote: Counting objects: 100% (177/177), done.
remote: Compressing objects: 100% (107/107), done.
remote: Total 3085 (delta 95), reused 120 (delta 69), pack-reused 2908 (from 1)
오브젝트를 받는 중: 100% (3085/3085), 832.96 KiB | 11.26 MiB/s, 완료.
델타를 알아내는 중: 100% (1973/1973), 완료.
'lib/ds-test' 경로에 대해 'lib/ds-test' (https://github.com/dapphub/ds-test) 하위 모듈 등록
'/Users/jeongtaepark/Desktop/helloworld-contracts/lib/solmate/lib/ds-test'에 복제합니다...
remote: Enumerating objects: 313, done.
remote: Counting objects: 100% (171/171), done.
remote: Compressing objects: 100% (79/79), done.
remote: Total 313 (delta 91), reused 132 (delta 83), pack-reused 142 (from 1)
오브젝트를 받는 중: 100% (313/313), 71.35 KiB | 17.84 MiB/s, 완료.
델타를 알아내는 중: 100% (130/130), 완료.
    Installed solmate v7

이렇게 성공적으로 라이브러리가 추가되었다면 2가지 변경사항이 존재합니다.

lib/ 아래에 설치한 라이브러리가 추가됩니다.

.gitmodules에 설치된 라이브러리의 정보가 추가됩니다.

forge install을 이용할 때 중요한 점이 있습니다. forge install이 수행되면 설치 / 추가 완료후 commit을 생성하게 됩니다. 이떄 만약 .git에서 작업 공간에 변경사항이 있을경우 정상적으로 설치되지 않습니다.

이 경우 두가지 해결법이 있습니다.

첫 번째는 현재 변경사항에 대한 커밋을 생성하여 작업 공간의 변경사항이 없는 상태에서 설치 진행하는 방법입니다.

두 번째는 forge install할 때 커밋을 생성하지 않도록 하는 방법입니다. --no-commit 옵션을 이용하면 커밋을 생성하지 않습니다.

$ forge install [패키지명] --no-commit

· 의존성 - Package Manager

파이썬의 pypi, 노드의 npm과 같이 forge에서는 soldeer를 이용합니다.

https://soldeer.xyz/

Soldeer - Solidity Package Manager

Soldeer is a lightweight package manager for Solidity built in Rust.

soldeer.xyz

$ forge soldeer install @openzeppelin-contracts~5.0.2

  Running soldeer install  

Dependency @openzeppelin-contracts-5.0.2.zip downloaded!
Writing @openzeppelin-contracts~5.0.2 to the lock file.
The dependency @openzeppelin-contracts-5.0.2 was unzipped!
Adding dependency @openzeppelin-contracts-5.0.2 to the config file
Added a new dependency to remappings @openzeppelin-contracts-5.0.2

$ tree . -L 2

.
├── README.md
├── dependencies
│   └── @openzeppelin-contracts-5.0.2
├── foundry.toml
├── lib
│   ├── forge-std
│   └── solmate
├── remappings.txt
├── script
│   └── Counter.s.sol
├── soldeer.lock
├── src
│   └── Counter.sol
└── test
    └── Counter.t.sol

8 directories, 7 files

soldeer로 설치된 외부 라이브러리는 dependencies에 추가됩니다. 그리고 remappings.txt와 soldeer.lock이 추가됩니다.remappings.txt는 dependencies에 추가된 라이브러리 목록을 가지고 있는 파일이며 soldeer.lock은 소스코드 경로, 라이브러리 이름, 버전, 체크섬 정보를 가지고 있는 파일입니다.

만약 깃허브 레포에서 forge로 구축된 프로젝트를 clone 했다면 soldeer로 관리중인 의존성 모듈을 설치해야 합니다. 이땐 update를 이용합니다.

$ forge soldeer update 
  Running soldeer update  

Dependency @openzeppelin-contracts-5.0.2.zip downloaded!
The dependency @openzeppelin-contracts-5.0.2 was unzipped!
Writing @openzeppelin-contracts~5.0.2 to the lock file.

● 개발프로세스

소스코드를 작성하고 컴파일 & 빌드를 하여 우리가 사용할 네트워크에 스마트 컨트랙트를 배포합니다. 그리고 이를 테스트는 개발 프로세스를 가집니다.

1. 소스코드 작성(with 테스트) 
2. 컴파일 & 빌드 
3. 배포 
4. 개별적으로 실행해보기 
5. 테스트 하기

출금패턴이 적용된 컨트랙트를 기반으로 테스트 합니다.

https://blog.naver.com/pjt3591oo/222594079769

[ethereum] solidity withdrawals pattern(출금패턴)

안녕하세요 멍개입니다. https://meongae.tistory.com/82으로 이관되었습니다. 이번 포스트는 solidity에서...

blog.naver.com

· 소스코드 작성

소스코드는 src/ 아래에서 관리합니다. forge 프로젝트 초기화 시 생성된 Counter.sol은 삭제합니다.

다음 코드는 출금패턴이 적용된 코드입니다.

▶ src/WithdrawalContract.sol

// SPDX-License-Identifier: GPL
pragma solidity 0.8.24;

error AlreadyWithdrawal();

contract WithdrawalContract {
  address payable public richest;
  uint public mostAmount = 0;
  uint public totalAmount = 0;

  mapping (address => uint) public pendingWithdrawals;

  receive() external payable {
    _receiveEther(msg.sender, msg.value);
  }

  constructor() payable {
    richest = payable(msg.sender);
    mostAmount = msg.value;
  }

  function becomeEther() public payable {
    _receiveEther(msg.sender, msg.value);
  }

  function _receiveEther(address sender, uint value) private {
    pendingWithdrawals[richest] += value;

    if (value > mostAmount) {
      richest = payable(sender);
      mostAmount = value;
    }

    totalAmount += value;
  }

  function withdraw() public {
    if (pendingWithdrawals[msg.sender] == 0) {
      revert AlreadyWithdrawal();
    }
    uint amount = pendingWithdrawals[msg.sender];
    // 리엔트란시(re-entrancy) 공격을 예방하기 위해
    // 송금하기 전에 보류중인 환불을 0으로 기억해 두십시오.
    pendingWithdrawals[msg.sender] = 0;
    payable(msg.sender).transfer(amount);
  }
}

· 테스트 코드 작성

forge 프로젝트 초기화 시 생성된 Counter.t.sol은 삭제합니다.

테스트를 수행할 테스트 코드와 테스트 시 사용할 2개의 컨트랙트를 정의합니다.

테슽 코드는 test/ 아래에서 관리되며 파일명은 *.t.sol 형태입니다.

먼저, 출금 테스트시 사용할 2개의 컨트랙트를 만들어줍니다.

테스트 코드를 작성할 땐 forge-std/Test.sol, Console, Vm 등을 이용하게 됩니다.

깃허브를 통해 어떤 기능을 사용할 수 있는지 알아볼 수 있습니다.

https://github.com/foundry-rs/forge-std/tree/master/src

forge-std/src at master · foundry-rs/forge-std

Forge Standard Library is a collection of helpful contracts for use with forge and foundry. It leverages forge's cheatcodes to make writing tests easier and faster, while improving the UX of ch...

github.com

▶ ./test/NonPayableContract.sol

// SPDX-License-Identifier: GPL
pragma solidity 0.8.24;

import '../src/WithdrawalContract.sol';

contract NonPayableContract {
  // receive () external payable{}
  
  constructor () payable {}

  function send(WithdrawalContract _to, uint _amount) external {
    WithdrawalContract(_to).becomeEther{value: _amount}();
  }

  function withdraw(WithdrawalContract addr) public  {
    WithdrawalContract(addr).withdraw();
  }
}

해당 컨트랙트는 생성시를 제외하고는 ETH를 전송받을 수 없습니다.

constructor() payable{}가 존재하기 때문에 생성시 ETH를 받을 수 있습니다.

receive() payable{}가 없기 때문에 ETH를 전송받을 수 없습니다.

▶ ./test/Payable.sol

// SPDX-License-Identifier: GPL
pragma solidity 0.8.24;

import '../src/WithdrawalContract.sol';

contract PayableContract {
  receive () external payable{}
  
  constructor () payable {}

  function send(WithdrawalContract _to, uint _amount) external {
    WithdrawalContract(_to).becomeEther{value: _amount}();
  }

  function withdraw(WithdrawalContract addr) public  {
    WithdrawalContract(addr).withdraw();
  }

}

해당 컨트랙트는 언제든 ETH를 전송받을 수 있습니다.

constructor() payable{}가 존재하기 때문에 생성시 ETH를 받을 수 있습니다.

receive() payable{}가 있기 때문에 ETH를 전송받을 수 있습니다.

▶ ./test/WithdrawalContract.t.sol

test_*는 assertion을 수행하는 테스트 단위입니다.

testFail_*은 exception이 발생하는지 테스트합니다. exception의 경우는 vm.expectRevert를 통해 어떤 exception이 발생했는지 검사할 수 있습니다.

vm.expectRevert의 경우 testFail_*에서 수행될 경우 항상 pass가 되며, test_*로 작성된 테스트케이스에서 수행되어야 합니다.

setUp은 test_*, testFail_*와 같이 테스트가 수행되기 전에 매번 호출됩니다.

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.13;

import {Test, console} from "forge-std/Test.sol";
import {WithdrawalContract, AlreadyWithdrawal} from "../src/WithdrawalContract.sol";

import {PayableContract} from "./PayableContract.sol";
import {NonPayableContract} from "./NonPayableContract.sol";

contract WithdrawalContractTest is Test {
    WithdrawalContract public withdrawalContract; // test target

    PayableContract public payableContract;
    NonPayableContract public nonPayableContract;
    
    function setUp() public pure {
      console.log("WithdrawalContractTest setUp");
    }

    function test_case0() public pure {
      console.log("WithdrawalContractTest test_case0");
    }
}

forge test를 통해 테스트 코드를 수행할 수 있습니다.

$ forge test -vvvv
[⠊] Compiling...
[⠢] Compiling 1 files with Solc 0.8.24
[⠆] Solc 0.8.24 finished in 2.09s
Compiler run successful!

Ran 1 test for test/WithdrawalContract.t.sol:WithdrawalContractTest
[PASS] test_case0() (gas: 3438)
Logs:
  WithdrawalContractTest setUp
  WithdrawalContractTest test_case0

Traces:
  [3438] WithdrawalContractTest::test_case0()
    ├─ [0] console::log("WithdrawalContractTest test_case0") [staticcall]
    │   └─ ← [Stop]
    └─ ← [Stop]

Suite result: ok. 1 passed; 0 failed; 0 skipped; finished in 1.04ms (98.53µs CPU time)

Ran 1 test suite in 357.14ms (1.04ms CPU time): 1 tests passed, 0 failed, 0 skipped (1 total tests)

출력 결과를 깔끔하게 보고싶다면 -vvvv를 조정하면 됩니다.

-vv

-vvv

-vvvv

-vvvvv

▶ setup

먼저 테스트를 수행하기 위해 setup에서 컨트랙트를 정의합니다.

function setUp() public {
  withdrawalContract = new WithdrawalContract{value: 0}();
 
  payableContract = new PayableContract{value: 1000}();
  nonPayableContract = new NonPayableContract{value: 1000}();
  console.log('test contract balanceof: ', address(this).balance);
}

$ forge test -vvvv
[⠒] Compiling...
[⠢] Compiling 1 files with Solc 0.8.24
[⠆] Solc 0.8.24 finished in 2.12s
Compiler run successful!

Ran 1 test for test/WithdrawalContract.t.sol:WithdrawalContractTest
[PASS] test_send() (gas: 188)
Logs:
  test contract balanceof:  79228162514264337593543948335

Traces:
  [188] WithdrawalContractTest::test_send()
    └─ ← [Stop]

Suite result: ok. 1 passed; 0 failed; 0 skipped; finished in 1.06ms (86.42µs CPU time)

Ran 1 test suite in 364.00ms (1.06ms CPU time): 1 tests passed, 0 failed, 0 skipped (1 total tests)

▶ test_send

PayableContract와 NonPayableContract에서 send를 호출하여 WithdrawalContract로 ETH를 전송하는 테스트 코드를 작성합니다.

 function test_send() public  {
      payableContract.send(withdrawalContract, 120);
      nonPayableContract.send(withdrawalContract, 100);

      assertEq(address(payableContract).balance, 880);
      assertEq(address(nonPayableContract).balance, 900);
      assertEq(address(withdrawalContract).balance, 220);    

      assertEq(withdrawalContract.mostAmount(), 120);
      assertEq(withdrawalContract.totalAmount(), 220);

      assertEq(withdrawalContract.pendingWithdrawals(address(payableContract)), 120);
      assertEq(withdrawalContract.pendingWithdrawals(address(nonPayableContract)), 100);
    }

여기서 만약 버그가 있다면 버그를 고쳐줍시다.(사실 WIthdrawalContract에 버그를 하나 심어 놨습니다.)

forge test -vvvv
[⠊] Compiling...
[⠆] Compiling 4 files with Solc 0.8.24
[⠰] Solc 0.8.24 finished in 2.22s
Compiler run successful!

Ran 1 test for test/WithdrawalContract.t.sol:WithdrawalContractTest
[FAIL. Reason: assertion failed: 100 != 120] test_send() (gas: 132991)
Logs:
  test contract balanceof:  79228162514264337593543948335

Traces:
  [418244] WithdrawalContractTest::setUp()
    ├─ [164308] → new WithdrawalContract@0x5615dEB798BB3E4dFa0139dFa1b3D433Cc23b72f
    │   └─ ← [Return] 688 bytes of code
    ├─ [53281] → new PayableContract@0x2e234DAe75C793f67A35089C9d99245E1C58470b
    │   └─ ← [Return] 266 bytes of code
    ├─ [51275] → new NonPayableContract@0xF62849F9A0B5Bf2913b396098F7c7019b51A820a
    │   └─ ← [Return] 256 bytes of code
    ├─ [0] console::log("test contract balanceof: ", 79228162514264337593543948335 [7.922e28]) [staticcall]
    │   └─ ← [Stop]
    └─ ← [Stop]

  [132991] WithdrawalContractTest::test_send()
    ├─ [81798] PayableContract::send(WithdrawalContract: [0x5615dEB798BB3E4dFa0139dFa1b3D433Cc23b72f], 120)
    │   ├─ [71972] WithdrawalContract::becomeEther{value: 120}()
    │   │   └─ ← [Stop]
    │   └─ ← [Stop]
    ├─ [30335] NonPayableContract::send(WithdrawalContract: [0x5615dEB798BB3E4dFa0139dFa1b3D433Cc23b72f], 100)
    │   ├─ [23009] WithdrawalContract::becomeEther{value: 100}()
    │   │   └─ ← [Stop]
    │   └─ ← [Stop]
    ├─ [0] VM::assertEq(880, 880) [staticcall]
    │   └─ ← [Return]
    ├─ [0] VM::assertEq(900, 900) [staticcall]
    │   └─ ← [Return]
    ├─ [0] VM::assertEq(220, 220) [staticcall]
    │   └─ ← [Return]
    ├─ [383] WithdrawalContract::mostAmount() [staticcall]
    │   └─ ← [Return] 120
    ├─ [0] VM::assertEq(120, 120) [staticcall]
    │   └─ ← [Return]
    ├─ [295] WithdrawalContract::totalAmount() [staticcall]
    │   └─ ← [Return] 220
    ├─ [0] VM::assertEq(220, 220) [staticcall]
    │   └─ ← [Return]
    ├─ [550] WithdrawalContract::pendingWithdrawals(PayableContract: [0x2e234DAe75C793f67A35089C9d99245E1C58470b]) [staticcall]
    │   └─ ← [Return] 100
    ├─ [0] VM::assertEq(100, 120) [staticcall]
    │   └─ ← [Revert] assertion failed: 100 != 120
    └─ ← [Revert] assertion failed: 100 != 120

Suite result: FAILED. 0 passed; 1 failed; 0 skipped; finished in 1.01ms (188.06µs CPU time)

Ran 1 test suite in 1.08s (1.01ms CPU time): 0 tests passed, 1 failed, 0 skipped (1 total tests)

Failing tests:
Encountered 1 failing test in test/WithdrawalContract.t.sol:WithdrawalContractTest
[FAIL. Reason: assertion failed: 100 != 120] test_send() (gas: 132991)

Encountered a total of 1 failing tests, 0 tests succeeded

에러가 발생합니다. 그 이유는 _receiveEther에서 첫 번째 호출되는 코드에 문제가 있기 떄문입니다.

pendingWithdrawals[richest] += value;

해당 코드를 다음과 같이 수정합니다. richest가 아닌 호출한 주소의 자산을 변경해주어야 합니다.

pendingWithdrawals[msg.sender] += value;

그리고 다시 테스트를 수행하면 테스트를 모두 통과합니다.

▶ withdraw 호출

withdraw를 호출하는 경우에 따라 케이스를 작성합니다.

send 이후 withdraw하는 경우

send를 하지 않고 withdraw하는 경우

send 이후 여러번의 withdraw하는 경우

function test_withdrawByRichest() public {
  payableContract.send(withdrawalContract, 120);
  payableContract.withdraw(withdrawalContract);
}
function testFail_withdrawByNoSend() public {
  payableContract.withdraw(withdrawalContract);
}
function testFail_multiWithdraw() public {
  payableContract.send(withdrawalContract, 120);
  payableContract.withdraw(withdrawalContract);
  payableContract.withdraw(withdrawalContract);
}

마지막으로 receive() external {}이 구현되지 않은 컨트랙트가 호출하는 경우를 작성합니다.

function testFail_withdrawByNonPayable() public {
  nonPayableContract.send(withdrawalContract, 100);
  nonPayableContract.withdraw(withdrawalContract);
}

여기서 중요한 점은 실패를 검증할 경우 testFail을 이용한다는 점 입니다.

· mocking

이 외에도 forge의 경우 vm을 통해 여러 모킹을 수행할수 있습니다.

▶ caller 변경

vm.prank(address(0)); // msg.sender가 변경됨

▶ block.timestamp 변경

vm.warp(1234); // 컨트랙트에서 block.timestamp를 호출할 때 값 변경

· Deploy

테스트 코드와 함께 컨트랙트 코드를 완성했습니다.

이제 우리는 forge를 이용하여 스마트 컨트랙트를 배포할 수 있습니다.

스마트 컨트랙트를 배포하기에 앞서서 anvil을 이용하여 가상의 블록체인 네트워크를 생성합니다.

$ anvil

forge create를 이용하면 src에 있는 특정 컨트랙트를 배포할 수 있습니다.

$ forge create ./src/WithdrawalContract.sol:WithdrawalContract \
  --rpc-url http://localhost:8545 \
  --private-key 0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80

다음과 같이 실행 결과를 확인할 수 있습니다.

[⠊] Compiling...
No files changed, compilation skipped
Deployer: 0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266
Deployed to: 0x5FbDB2315678afecb367f032d93F642f64180aa3
Transaction hash: 0xdb6ecae0d35a247bc700222b02fa596ac8cb0f9748378f1a0975afcabe4ef028

하지만 우리가 하나의 컨트랙트가 아닌 여러 컨트랙트를 배포해야 하는 상황이 올 수 있습니다. 이때는 forge script를 이용합니다. script 아래에 Counter.s.sol은 지워준 후 WithdrawalContract.s.sol을 만들어 줍니다.

▶ script/WithdrawalContract.s.sol

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.13;

import {Script, console} from "forge-std/Script.sol";
import {WithdrawalContract} from "../src/WithdrawalContract.sol";

contract WithdrawalContractScript is Script {
    function setUp() public {}

    function run() public {
      vm.broadcast();
      WithdrawalContract withdrawalContract = new WithdrawalContract();

      console.log("create withdrawalContract contract address: ", address(withdrawalContract));
      console.log("withdrawalContract richest: ", withdrawalContract.richest());
    }
}

vm.startBroadcast는 broadcast(배포)를 수행할 어카운트를 설정할 수 있습니다.

vm.envUint은 환경변수를 읽어올 수 있으며 정의되어있지 않다면 에러가 발생합니다.

/ SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.13;

import {Script, console} from "forge-std/Script.sol";
import {WithdrawalContract} from "../src/WithdrawalContract.sol";

contract WithdrawalContractScript is Script {
    function setUp() public {}

    function run() public {
      vm.startBroadcast(
        // vm.envUint("PRIVATE_KEY") // env check: if not set, will throw error
      );
      WithdrawalContract withdrawalContract = new WithdrawalContract();

      console.log("create withdrawalContract contract address: ", address(withdrawalContract));
      console.log("withdrawalContract richest: ", withdrawalContract.richest());

      vm.stopBroadcast();
    }
}

$ forge script ./script/WithdrawalContract.s.sol:WithdrawalContractScript \
  --rpc-url http://localhost:8545 \
  --private-key 0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80 \
  --broadcast

다음과 같이 실행 결과와 출력 결과를 확인할 수 있습니다. 혹여나 Counter.s.sol을 삭제하였는데도 해당 파일을 찾을 수 없다고 할 경우 cache/를 지우면 됩니다. 만약 --broadcast가 없다면 실제로 배포는 되지 않고 somulation만 수행합니다.

[⠒] Compiling...
No files changed, compilation skipped
EIP-3855 is not supported in one or more of the RPCs used.
Unsupported Chain IDs: 31337.
Contracts deployed with a Solidity version equal or higher than 0.8.20 might not work properly.
For more information, please see https://eips.ethereum.org/EIPS/eip-3855
Script ran successfully.

== Logs ==
  create withdrawalContract contract address:  0xe7f1725E7734CE288F8367e1Bb143E90bb3F0512
  withdrawalContract richest:  0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266

## Setting up 1 EVM.

==========================

Chain 31337

Estimated gas price: 1.753776101 gwei

Estimated total gas used for script: 294476

Estimated amount required: 0.000516444971118076 ETH

==========================

##### anvil-hardhat
✅  [Success]Hash: 0xc245d6b750a0aaf7782d99a3d57282c9eda0cb085b132105551c66514fffbecf
Contract Address: 0xe7f1725E7734CE288F8367e1Bb143E90bb3F0512
Block: 2
Paid: 0.000198673018162866 ETH (226566 gas * 0.876888051 gwei)

✅ Sequence #1 on anvil-hardhat | Total Paid: 0.000198673018162866 ETH (226566 gas * avg 0.876888051 gwei)
                                                                                                                                                           

==========================

ONCHAIN EXECUTION COMPLETE & SUCCESSFUL.

Transactions saved to: /Users/jeongtaepark/Desktop/helloworld-contracts/broadcast/WithdrawalContract.s.sol/31337/run-latest.json

Sensitive values saved to: /Users/jeongtaepark/Desktop/helloworld-contracts/cache/WithdrawalContract.s.sol/31337/run-latest.json

· cast

cast는 배포된 컨트랙트를 테스트하기 위해 rpc 통신을 수행하는 도구입니다.

조회를 위한 call과 트랜잭션 발생을 위한 send 명령어를 제공합니다.

$ cast call \
  [컨트랙트 주소]  \
  "richest()(address)" \
  --rpc-url http://localhost:8545

0xe7f1725E7734CE288F8367e1Bb143E90bb3F0512

만약 트랜잭션을 발생하고 싶다면 send를 이용합니다. 이때 value를 지정하면 이더를 전송할 수 있습니다

  function test(uint _amount) public {
    pendingWithdrawals[msg.sender] += _amount;
  }

만약 앞의 test 함수를 호출하기 위해서는 다음과 같이 send를 호출할 수 있습니다.

$ cast send \
  [컨트랙트 주소] \
  --rpc-url http://localhost:8545 \
  --private-key 0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80 \
  "test(uint)" 1000

cast는 abi-encode를 통해 함수 호출시 포함되어야 할 input 데이터를 생성할 수 있습니다.

$ cast abi-encode "test(uint)" 1000
0x00000000000000000000000000000000000000000000000000000000000003e8

cast는 이 외에도 block, transaction등과 같은 여러 명령들을 제공합니다.

https://book.getfoundry.sh/reference/cast/

Foundry Book

A book on all things Foundry

book.getfoundry.sh

· 코드 포맷

forge느 fmt를 이용하여 모든 코드의 포맷팅을 맞춰줍니다.

forge는 이 외에도 편의를 위한 여러 명령어를 제공하고 있습니다.

https://book.getfoundry.sh/reference/forge/

Foundry Book

A book on all things Foundry

book.getfoundry.sh

· anvil

anvil은 기본으로 설정된 mnemonic을 기반으로 로컬에 테스트 네트워크를 구축합니다.

test test test test test test test test test test test junk

다음과 같이 특정 네트워크를 포크하여 임의로 block 생성 주기를 변경하여 로컬 네트워크를 구축할 수 있습니다.

이는 이미 다른 네트워크에 있는 특정 스마트 컨트랙트를 테스트할 때 사용하면 상당히 도움이 많이 됩니다.

auto-impersonate 옵션은 임의로 블록을 생성하는 옵션이며 block-time은 블록 생성 주기입니다.

지금까지 foundry에서 제공하는 forge, anvil, cast를 다뤄보았습니다.

[블록체인] multi-sig와 key rotation을 이용한 악용사례

멍개. — Mon, 17 Feb 2025 17:41:59 +0900

안녕하세요 멍개입니다.

이번 시간엔 multi-sig와 key rotation을 이용한 사기 수법을 소개합니다.

본 포스트의 목적은 사기 수법을 공개함으로써 피해자가 없기를 바라는 마음으로 작성합니다.

evm, aptos, solana 등 대부분의 블록체인에서는 어카운트 구조를 사용합니다.

개인키는 해당 어카운트의 모든 권한을 가지게 됩니다.

· 다중서명(Multi-Sig) or 권한(Permission)

한 어카운트를 하나의 개인키가 아닌 다수의 개인키를 등록시켜서 다수의 개인키 서명을 받아야 트랜잭션을 성공시키는 방법이 multi sig 입니다.

multi sig를 사용하는 이유는 어카운트의 제어권을 여러 개인키로 분산함으로써 도난 / 무단 액세스 등의 위험으로부터 보호하기 위함입니다.

이렇게 되면 기존의 개인키로만 트랜잭션을 서명하더라도 해당 트랜잭션이 실행되지 않습니다. 추가적으로 등록된 개인키의 서명이 필요합니다. 이 부분은 블록체인 네트워크마다 다른 개념으로 등록이 가능할 수 있는데. aptos의 경우는 등록된 개인키마다 가중치를 부여하여 일정 이상의 가중치를 넘길만큼의 서명을 받으면 트랜잭션을 실행합니다. tron의 경우는 등록된 개인키마다 권한(permission)을 부여하여 개인키마다 권한을 부여할 수 있습니다.

· 키 회전(Key Rotation)

키 회전을 하는 이유는 보안상의 이유입니다. 가령 개인키가 노출될 경우 해당 어카운트는 더이상 안전하지 않게 됩니다. 하지만 트랜잭션을 실행할 수 있는 개인키를 변경한다면 어카운트는 안전한 상태가 됩니다.

이렇게 Changed Private Key로 어카운트의 개인키를 변경한다면 기존의 Private Key는 Address로 파생할때만 사용가능하며, 트랜잭션 서명시에는 Changed Private Key를 사용해야 합니다.

· 악용

앞에서 multi sig와 key rotation을 알아보았습니다.

그렇다면 이 둘을 이용하여 어떻게 사기를 칠 수 있는지 알아보겠습니다.

어카운트는 다음과 같이 multi-sig or key rotation된 어카운트를 낚시 계정(피싱 계정)이라고 표현하겠습니다.

악용 사례자는 낚시 계정의 원래의 private key를 피해자들에게 뿌립니다.

이렇게 되면 피해자들은 privatekey를 통해 해당 자산에 접근이 가능합니다.

하지만 private key만 뿌리면 피해자는 해당 자산에 접근만 가능할 뿐입니다.

여기사 악용 사례자는 해당 어카운트에 네이티브 코인(Eth, Apt, Trx)를 0로 만든 다음 USDT를 굉장히 많이 보유하도록 합니다.

피해자들은 해당 어카운트의 개인키를 알고 있기 때문에 네이티브 코인만 있다면 USDT를 본인의 지갑으로 옮길 수 있을거라는 생각을 합니다.

피해자들은 낚시 계정에 Native Coin을 전송합니다. 그리고 낚시 계정의 USDT를 본인의 지갑으로 뺴기 위해 악용 사례자에게 받은 Private Key로 서명한 후 트랜잭션을 실행하면 실패하게 됩니다. 악용 사례자는 Multi Sig( 추가로 등록된) 개인키 / Key Rotation(변경된 키)로 피해자가 전송한 Native Coin을 다른 지갑(or 거래소)으로 옮길수 있습니다.

· 실제 사례

해당 사건은 제가 실제로 겪었던 일입니다. 물론 저는 낚시 계정에 Native Coin을 전송하지 않았습니다. 앞의 개념을 알고 있었고 이를 확인하는 방법을 알았기 때문에 사기에 당하지 않았습니다.

저는 유튜브 댓글을 통해 다음과 같은 니모닉을 전달받았습니다.(니모닉은 개인키를 생성하는 방법)

여기서는 니모닉 = 개인키로 이해해도 충분합니다.

니모닉 : mistake turkey blossom warfare blade until bachelor fall squeeze today flee guitar 
어카운트: TAy4omTf7uENvTm2QrT22ZY8BvdrjXUKzC

니모닉을 알려주는 이유는 다음과 같았습니다.

"USDT를 가지고 있는 어카운트가 있다 해당 어카운트의 니모닉은 xxx 이며, 이를 거래소로 옮기려고 한다. 도와달라" 라는 형태의 메시지와 함께 니모닉을 알려줍니다.

해당 니모닉은 trx 기반 네트워크에서 USDT를 굉장히 많이 보유하고 있는 어카운트의 개인키입니다.

저는 USDT가 어느 네트워크에서 발행된 USDT인지 찾아보니 tron이었습니다.

여기서 저는 해당 잔액을 확인함과 동시에 트랜잭션 목록이 눈에띄었습니다.

아니 나에게 전송하는 방법을 물어봤는데 이미 전송 내역이 있다는 점이 매우 이상했습니다. 그래서 해당 어카운트의 Permission을 확인해보았습니다.

어카운트의 주소와 Permission의 주소가 다르게 나옵니다. 즉 해당 어카운트로 TRX를 전송하더라도 악용 사례자가 공유한 니모닉(개인키)를 이용하여 USDT를 전송할 수 없습니다.

aptos의 경우도 Multi sig어카운트와 Key Rotation 모두 지원하며 Key Rotation은 다음과 같이 exploer에서 [resources] - authentication_key와 어카운트 주소가 동일한지 다른지로 확인할 수 있습니다.

[github] 원격 저장소에 있는 브랜치를 로컬로 가져오는 방법

멍개. — Tue, 6 Sep 2022 20:47:28 +0900

안녕하세요. 멍개입니다.

로컬에 없는 원격 저장소에 존재하는 브랜치를 로컬로 가져오는 방법을 알아보겠습니다.

· 원격 저장소 이력 확인

원격 저장소에 있는 브랜치 정보를 로컬로 가져옵니다 이떄 브랜치를 병합하진 않습니다.

$ git remote update

remote update를 하게되면 원격 저장소에 있는 브랜치들을 로컬로 가져옵니다.

· 브랜치 확인

이렇게 가져온 브랜치는 git branch로는 조회되지 않습니다. 다음과 같이 조회해야 원격 저장소에서 가져온 브랜치를 확인할 수 있습니다.

$ git branch -r  # git branch -a


remote/origin/dev
remote/origin/feature1
remote/origin/feature2
remote/origin/feature3

원격 저장소에서 가져온 브랜치는 remote/origin/브랜치이름 형태로 표시됩니다.

· 체크아웃

remote/origin/dev로 표시된 항목은 로컬엔 없지만 원격 저장소에 dev 브랜치가 존재한다는 것입니다.

원격 브랜치로 체크아웃하기 위해 -t 옵션을 이용합니다.

$ git checkout -t [remote/origin/브랜치이름]

만약 원격 저장소의 dev 브랜치를 로컬에서 체크아웃 하기위해선 다음과 같이 입력하면 됩니다.

$ git checkout -t remote/origin/dev

원격 저장소에 있는 dev 브랜치를 로컬에서 체크아웃하게 됩니다.

멍개 저작권 등록 및 굿즈제작

멍개. — Thu, 1 Sep 2022 17:35:42 +0900

▶ 아크릴키링

https://www.oround.com/mung

selleb17500의 그라운드 : 감탄 굿즈 마켓 oround

오라운드 selleb17500의 그라운드에 오신것을 환영합니다. 컬렉션과 기획전, 리뷰를 한눈에 확인해보세요.

www.oround.com:443

· 핸드폰 케이스 - 하드

갤럭시S21울트라, 갤럭시S21, 갤럭시S21+, 갤럭시S22, 갤럭시S22+,갤럭시S22울트라, 아이폰11, 아이폰13프로맥스, 아이폰12미니, 아이폰12프로, 아이폰12, 아이폰13미니, 아이폰13프로맥스, 아이폰13프로, 아이폰13,

· 핸드폰 케이스 = 젤리

갤럭시S20+, 갤럭시S20, 갤럭시노트20울트라, 갤럭시노트, 갤럭시S20울트라, 갤럭시S21, 갤럭시S21+, 갤럭시S21울트라, 갤럭시S22, 갤럭시S22+, 갤럭시S22울트라, 아이폰11프로맥스, 아이폰11프로, 아이폰11, 아이폰XS, 아이폰12미니, 아이폰12프로맥스, 아이폰12, 아이폰12프로, 아이폰13미니, 아이폰13프로맥스, 아이폰13프로

· 저작권 등록증

굿즈 제작에 사용된 이미지는 저에게 있습니다.

[nestjs] 스웨거 사용시 주의사항 - 순환참조 에러

멍개. — Mon, 29 Aug 2022 07:50:12 +0900

nestjs에서 스웨거 사용시 주의사항을 살펴보겠습니다.

스웨거를 사용하다보면 다음과 같은 에러가 발생할 수 있습니다.

/Users/jeongtaepark/Desktop/node_modules/@nestjs/swagger/dist/services/schema-object-factory.js:170
            throw new Error(`A circular dependency has been detected (property key: "${key}"). Please, make sure that each side of a bidirectional relationships are using lazy resolvers ("type: () => ClassType").`);
                  ^
Error: A circular dependency has been detected (property key: "user"). Please, make sure that each side of a bidirectional relationships are using lazy resolvers ("type: () => ClassType").
    at SchemaObjectFactory.createNotBuiltInTypeReference (/Users/jeongtaepark/Desktop/node_modules/@nestjs/swagger/dist/services/schema-object-factory.js:170:19)
    at SchemaObjectFactory.createSchemaMetadata (/Users/jeongtaepark/Desktop/node_modules/@nestjs/swagger/dist/services/schema-object-factory.js:280:25)
    at SchemaObjectFactory.mergePropertyWithMetadata (/Users/jeongtaepark/Desktop/node_modules/@nestjs/swagger/dist/services/schema-object-factory.js:122:21)
    at /Users/jeongtaepark/Desktop/node_modules/@nestjs/swagger/dist/services/schema-object-factory.js:79:35
    at Array.map (<anonymous>)
    at SchemaObjectFactory.extractPropertiesFromType (/Users/jeongtaepark/Desktop/node_modules/@nestjs/swagger/dist/services/schema-object-factory.js:78:52)
    at SchemaObjectFactory.createQueryOrParamSchema (/Users/jeongtaepark/Desktop/node_modules/@nestjs/swagger/dist/services/schema-object-factory.js:57:45)
    at /Users/jeongtaepark/Desktop/node_modules/@nestjs/swagger/dist/services/schema-object-factory.js:31:29
    at Array.map (<anonymous>)
    at SchemaObjectFactory.createFromModel (/Users/jeongtaepark/Desktop/node_modules/@nestjs/swagger/dist/services/schema-object-factory.js:20:45)

해당 에러가 발생하는 케이스를 만들어보겠습니다.

예를 들어서 유저와 게시글 관계를 정의할 때 다음과 같이 데이터를 모델링합니다.

▶ 유저 DTO

import { ApiProperty } from "@nestjs/swagger";

import { PostDto } from "./post.dto";

export class UserDto {
  @ApiProperty({ type : Number })
  id: number;
  
  @ApiProperty({ type : String })
  name: string;

  @ApiProperty({ type : [PostDto] })
  posts: [PostDto];
}

유저는 다수의 게시글을 가질 수 있습니다.

▶ 게시글 DTO

import { ApiProperty } from "@nestjs/swagger";

import { UserDto } from "./user.dto";

export class PostDto {
  @ApiProperty({ type : Number })
  id: number;
  
  @ApiProperty({ type : String })
  title: string;

  @ApiProperty({ type : UserDto })
  user: UserDto;
}

하나의 게시글은 하나의 유저를 가집니다.

이때 user와 post는 서로 순환참조 관계를 가집니다.

· 해결방법

스웨거의 ApiProperty는 이런 순환참조를 대비하여 lazy loading을 이용하합니다. 바로 @ApiProperty는 type을 전달할 때 함수의 반환값을 이용합니다.

▶ 유저 DTO

import { ApiProperty } from "@nestjs/swagger";

import { PostDto } from "./post.dto";

export class UserDto {
  @ApiProperty({ type : Number })
  id: number;
  
  @ApiProperty({ type : String })
  name: string;

  @ApiProperty({ type : () => [PostDto] })
  posts: [PostDto];
}

▶ 게시글 DTO

import { ApiProperty } from "@nestjs/swagger";

import { UserDto } from "./user.dto";

export class PostDto {
  @ApiProperty({ type : Number })
  id: number;
  
  @ApiProperty({ type : String })
  title: string;

  @ApiProperty({ type : () => UserDto })
  user: UserDto;
}

함수의 반환값으로 타입을 전달하면 lazy loading이 되기 때문에 스웨거 로드가 정상적으로 이루어집니다.

[객체지향원칙] DIP 의존성 역전 - nestjs를 이용하여 todo 구현

멍개. — Sun, 28 Aug 2022 16:22:33 +0900

앞의 영상은 제가 즐겨보는 채널입니다. 해당 채널을 보다보면 최근들어 DI(Dependency Inversion)에 관련해서 언급을 많이하고 있습니다.

그렇다면 DI가 머길래 열정적으로 DI를 언급하는것일까요? 이번포스트에서는 DI가 무엇인지 살펴보고 DI가 잘 적용된 nestjs 프레임워크를 살펴보면서 왜 DI를 사용해야 하는지 알아보겠습니다. 추가적으로 리액트에서 DI를 넣어보도록 하겠습니다.

먼저, 우리는 선행되어야 하는 지식이 있습니다. 이 포스트의 제목에 등작한 DIP부터 시작하여 DI, IoC입니다.

● 의존성 역전 원칙이란?

의존성 역전 원칙(Dependency Inversion Principle)은 DIP라고도 부릅니다. 의존성 역전 원칙의 사전적 의미는 다음과 같습니다.

객체 지향 프로그래밍에서 의존관계 역전 원칙은 소프트웨어 모듈들을 분리하는 특정 형식을 지칭한다. 이 원칙을 따르면, 상위 계층(정책 결정)이 하위 계층(세부 사항)에 의존하는 전통적인 의존관계를 반전(역전)시킴으로써 상위 계층이 하위 계층의 구현으로부터 독립되게 할 수 있다. 이 원칙은 다음과 같은 내용을 담고 있다.[1]

첫째, 상위 모듈은 하위 모듈에 의존해서는 안된다. 상위 모듈과 하위 모듈 모두 추상화에 의존해야 한다.

둘째, 추상화는 세부 사항에 의존해서는 안된다. 세부사항이 추상화에 의존해야 한다.

이 원칙은 '상위와 하위 객체 모두가 동일한 추상화에 의존해야 한다'는 객체 지향적 설계의 대원칙을 제공한다.[2]

출처:

https://ko.wikipedia.org/wiki/%EC%9D%98%EC%A1%B4%EA%B4%80%EA%B3%84_%EC%97%AD%EC%A0%84_%EC%9B%90%EC%B9%99

내용이 상당히 어려워보이죠? 앞의 내용을 한 문장으로 해석하면 인터페이스를 활용하라는 것 입니다. 여기서 DI(방법)와 IoC(개념)가 나오게 됩니다.

DIP는 원칙이며 DI는 DIP를 위해 사용되는 방법이고 IoC는 DI 했을때 발생하는 현상입니다.

자 우선 우리는 DIP에서 D(Dependency)와 I(Inversion)가 무엇을 의미하는지 살펴보겠습니다.

· 의존성 주입이란?

우리가 코드를 작성할 때 가장 중요한 점 중 하나로 의존성을 낮추는 것을 의미합니다. 그럼 의존성이 머냐? 의존성이 높다는 코드는 new를 통해 객체를 만드는 행위입니다. 간단한 예시 코드를 살펴보겠습니다. 의존성을 낮추기 위해 의존성을 외부에서 주입을 합니다.

class MacProByIntel {

}

class Mung {
  mac: MacProByIntel;
  
  buyIntel() {
    this.mac = new MacProByIntel();
  }
}

Mung 클래스는 MacProByIntel을 받을 수 있습니다. 여기서 M1 CPU와 M2 CPU를 구매하는 메서드를 추가해보겠습니다.

class MacProByIntel {

}
class MacProByM1 {

}
class MacProByM2 {

}

class Mung {
  mac: MacProByIntel;
  
  buyIntel() {
    this.mac = new MacProByIntel();
  }
  
  buyM1() {
    this.mac = new MacProByM1();
  }
  
  buyM2() {
    this.mac = new MacProByM2();
  }
}

Mung 클래스에서 MacProByIntel, MacProByM1, MacProByM2를 new하여 직접 객체를 만드는 것을 의존성이 높다고 표현합니다.

여기서 Mung이 상위 모듈이며 Mac이 하위 모듈입니다.

class MacProByIntel {

}
class MacProByM1 {

}
class MacProByM2 {

}

class Mung {
  mac: MacProByIntel;
  
  buyIntel(mac: MacProByIntel) {
    this.mac = mac;
  }
  
  buyM1(mac: MacProByM1) {
    this.mac = mac;
  }
  
  buyM2(mac: MacProByM2) {
    this.mac = mac;
  }
}

객체를 직접 생성하지 않고 객체를 전달받는 형태로 구성이 되면 의존성이 낮아졌다고 합니다. 이런 형태를 의존성 주입이라고 합니다.

· 추상화

DIP의 정의를 살펴보면 가장 많이 나오는 단어가 추상화입니다. 추상화란 인터페이스를 의미합니다. 즉 객체를 의존하지 말고 추상화를 의존하라는 것을 의미합니다. 여기서 IoC가 발생하게 됩니다.

앞에서 DI는 방법, IoC는 개념이라고 했는데 DI를 통해 IoC가 발생합니다.

class Mac {

}

class MacProByIntel implements Mac{

}
class MacProByM1 implements Mac{

}
class MacProByM2 implements Mac{

}

class Mung {
  mac: Mac;
  
  buy (mac: Mac) {
    this.mac = mac
  }
}

이를 우리는 추상화에 의존했다고 표현합니다. 하위모듈인 MacProByIntel, MacProByM1, MacProByM2는 인터페이스를 통해 구현되어집니다. 또한 Mung은 각각의 하위모듈이 아닌 추상화 된 Mac 인터페이스를 받도록 합니다.

좌측에서 우측 처럼 화살표의 방향이 바뀌었습니다. 여기서 역전의 의미가 나오게 됩니다. 즉, IoC가 발생한 것 입니다.

DIP를 정리하면 DI를 이용하여 의존성을 낮추고 인터페이스를 이용하여 IoC 현상이 발생하는 것을 의미합니다.

DIP 원칙을 따르면 OOP 원칙 중 OCP(Open Close Principle)인 개방 폐쇠 원칙을 지킬 수 있습니다. 만약, 애플이 M3, M4, M5를 계속 만들어 낸다면 우리는 Mac 클래스를 상속받은 M3, M4, M5만 만들어 주면 됩니다. 수정에 대해서 기존 코드를 건드리지 않아도 됩니다. 확장은 자유롭고 수정은 폐쇠되어지게 됩니다.

여기서 멍개는 인터페이스(abstract)를 통해 그 구현체(implementation)에 대한 의존성을 가지게 된다고 표현합니다.

● DI(Dependency Injection)을 통한 개발은 어떻게 진행되나?

우리가 사용하는 다양한 라이브러리 및 프레임워크는 DI를 위해 컨테이너를 제공합니다.

https://blog.naver.com/pjt3591oo/222386896479

[typescript] typedi를 이용하여 Dependency Injection(DI) 이해하기

안녕하세요 멍개입니다. 타입스크립트의 typedi를 활용하여 DI(Dependency Injection)를 알아보도록 하...

blog.naver.com

또한 스프링, Nestjs, Angular, FastAPI 등이 DI를 지원하는 프레임워크입니다. 해당 프레임워크의 특징은 객체를 관리하는 컨테이너를 제공합니다.

nestjs를 이용하여 Todo앱을 만들어 보며 DI가 어떤 이점이 있는지 살펴보겠습니다.

· 데이터베이스 생성

$ docker run --name mysql-container -e MYSQL_ROOT_PASSWORD=password -d -p 3306:3306 mysql:5.7

다음으로 데이터베이스를 생성합니다.

$ docker exec -it mysql-container /bin/bash

$ mysql -u root -ppassword

mysql>

mysql> CREATE DATABASE todo;

· nestjs 프로젝트 생성

$ nest new todo

$ tree . -I node_modules
.
├── README.md
├── nest-cli.json
├── package-lock.json
├── package.json
├── src
│   ├── app.controller.spec.ts
│   ├── app.controller.ts
│   ├── app.module.ts
│   ├── app.service.ts
│   └── main.ts
├── test
│   ├── app.e2e-spec.ts
│   └── jest-e2e.json
├── tsconfig.build.json
└── tsconfig.json

2 directories, 13 files

nestjs는 module를 컨테이너라고 부릅니다. module을 통해 객체를 등록하게 됩니다. nestjs는 module에 등록된 객체를 컨트롤러나 서비스에게 주입하여 줍니다. 즉, 우리가 new를 직접하지 않소 nestjs가 new된 결과를 주입하게 됩니다.

// src/app.module.ts
import { Module } from '@nestjs/common';
import { AppController } from './app.controller';
import { AppService } from './app.service';

@Module({
  imports: [],
  controllers: [AppController],
  providers: [AppService],
})
export class AppModule {}

controllers에 providers에 명시된 항목을 주입합니다.

// src/app.controller.ts
import { Controller, Get } from '@nestjs/common';
import { AppService } from './app.service';

@Controller()
export class AppController {
  constructor(private readonly appService: AppService) {}

  @Get()
  getHello(): string {
    return this.appService.getHello();
  }
}

nestjs는 AppController에게 AppService를 주입합니다.

· 필요 라이브러리 설치

$ npm install --save typeorm mysql2 @nestjs/typeorm

· 데이터베이스 모듈 만들기

nestjs는 필요한 코드를 providers로 생성 후 module을 통해 export 하는 구조로 모듈을 생성합니다.

// database/database.providers.ts

import { DataSource } from 'typeorm';

export const databaseProviders = [
  {
    provide: 'DATA_SOURCE',
    useFactory: async () => {
      const dataSource = new DataSource({
        type: 'mysql',
        host: 'localhost',
        port: 3306,
        username: 'root',
        password: 'password',
        database: 'todo',
        entities: [
            __dirname + '/../**/*.entity{.ts,.js}',
        ],
        synchronize: true,
      });

      return dataSource.initialize();
    },
  },
];

이제 모듈을 만들어 줍니다.

// database/database.module.ts

import { Module } from '@nestjs/common';
import { databaseProviders } from './database.providers';

@Module({
  providers: [...databaseProviders],
  exports: [...databaseProviders],
})
export class DatabaseModule {}

· todo 앱 생성

$ nest g module todo
CREATE src/todo/todo.module.ts (81 bytes)
UPDATE src/app.module.ts (308 bytes)

$ nest g service todo
CREATE src/todo/todo.service.spec.ts (446 bytes)
CREATE src/todo/todo.service.ts (88 bytes)
UPDATE src/todo/todo.module.ts (155 bytes)

$ nest g controller todo
CREATE src/todo/todo.controller.spec.ts (478 bytes)
CREATE src/todo/todo.controller.ts (97 bytes)
UPDATE src/todo/todo.module.ts (240 bytes)

$ tree . -I node_modules
.
├── README.md
├── nest-cli.json
├── package-lock.json
├── package.json
├── src
│   ├── app.controller.spec.ts
│   ├── app.controller.ts
│   ├── app.module.ts
│   ├── app.service.ts
│   ├── database
│   │   ├── database.module.ts
│   │   └── database.providers.ts
│   ├── main.ts
│   └── todo
│       ├── todo.controller.spec.ts
│       ├── todo.controller.ts
│       ├── todo.module.ts
│       ├── todo.service.spec.ts
│       └── todo.service.ts
├── test
│   ├── app.e2e-spec.ts
│   └── jest-e2e.json
├── tsconfig.build.json
└── tsconfig.json

4 directories, 20 files

· todo entity 생성

src/todo/entity/todo.entity.ts를 생성하여 다음과 같이 정의합니다.

import { Entity, Column, PrimaryGeneratedColumn } from 'typeorm';

@Entity()
export class Todo {
  @PrimaryGeneratedColumn()
  id: number;

  @Column({ length: 500 })
  name: string;

  @Column('text')
  description: string;

  @Column('int')
  isComplete: number;
}

이제 todo 모듈에 등록된 컨트롤러와 프로바이더에서 데이터베이스를 사용할 수 있도록 하겠습니다

src/todo/todo.module.ts를 다음과 같이 수정합니다.

import { Module } from '@nestjs/common';
import { TodoService } from './todo.service';
import { TodoController } from './todo.controller';

import { DataSource } from 'typeorm';
import { Todo } from './entity/todo.entity';
import { DatabaseModule } from 'src/database/database.module';

@Module({
  imports: [DatabaseModule],
  providers: [
    {
      provide: 'TODO_REPOSITORY',
      useFactory: (dataSource: DataSource) => dataSource.getRepository(Todo),
      inject: ['DATA_SOURCE'],
    },
    TodoService
  ],
  controllers: [TodoController]
})
export class TodoModule { }

· 서비스 생성

서비스는 데이터베이스와 연결된 Todo 레포지토리 객체를 전달받을 수 있습니다. src/todo/todo.service.ts를 다음과 같이 작성합니다.

import { Injectable, Inject } from '@nestjs/common';
import { Repository } from 'typeorm';
import { Todo } from './entity/todo.entity';

@Injectable()
export class TodoService {
  constructor(
    @Inject('TODO_REPOSITORY')
    private todoRepository: Repository<Todo>,
  ) {}

  async findAll(): Promise<Todo[]> {
    return this.todoRepository.find();
  }

  async find(id): Promise<Todo> {
    return this.todoRepository.findOne({where: id});
  }

  async create(todo: Todo): Promise<Todo> {
    return this.todoRepository.save(todo);
  }

  async update(id, todo: Todo): Promise<Todo> {
    await this.todoRepository.update(id, todo);
    return this.todoRepository.findOne({where: id});
  }

  async delete(id): Promise<Todo> {
    const todo = await this.todoRepository.findOne({where: id});
    await this.todoRepository.remove(todo);
    return todo;
  }
}

자 이제 우리가 해야할 일은? 해당 서비스가 정상적으로 동작하는지 테스트를 해봐야겠죠? 여기서 의존성 주입이 빛을 보게 됩니다.

여기서 Entity 타입으로 처리하지면 DTO를 만들어 처리하는것을 권장합니다 (본 글에서는 Entity 타입을 그대로 이용합니다).

· todo 서비스 테스트 하기

src/todo/todo.service.spec.ts에 todoService 테스트 코드를 작성합니다.

import { Test, TestingModule } from '@nestjs/testing';
import { TodoService } from './todo.service';

describe('TodoService', () => {
  let service: TodoService;

  beforeEach(async () => {
    const module: TestingModule = await Test.createTestingModule({
      providers: [TodoService],
    }).compile();

    service = module.get<TodoService>(TodoService);
  });

  it('should be defined', () => {
    expect(service).toBeDefined();
  });
});

여기서 우리는 import로 전달하는 데이터베이스 소스를 원래 연결된 디비가 아닌 모킹된 객체를 만들어 넘길 수 있습니다. 하지만 우리는 sqlite로 연결시키겠습니다.

import { TypeOrmModule, TypeOrmModuleOptions } from '@nestjs/typeorm';
import { DataSource } from 'typeorm';
import { Module } from '@nestjs/common';
import { Test, TestingModule } from '@nestjs/testing';
import { TodoService } from './todo.service';

import { Todo } from './entity/todo.entity';

const databaseProviders = [
  {
    provide: 'DATA_SOURCE',
    useFactory: async () => {
      const dataSource = new DataSource({
        name: 'todo',
        type: 'sqlite',
        database: './data_sqlite/example.sq3',
        entities: [Todo],
        synchronize: true,
      });

      return dataSource.initialize();
    },
  },
];

@Module({
  providers: [...databaseProviders],
  exports: [...databaseProviders]
})
export class DatabaseModule {}

describe('TodoService', () => {
  let service: TodoService;

  beforeEach(async () => {
    const module: TestingModule = await Test.createTestingModule({
      imports: [DatabaseModule],
      providers: [
        {
          provide: 'TODO_REPOSITORY',
          useFactory: (dataSource: DataSource) => dataSource.getRepository(Todo),
          inject: ['DATA_SOURCE'],
        },
        TodoService
      ],
    }).compile();

    service = module.get<TodoService>(TodoService);
  });

  it('should be defined', () => {
    expect(service).toBeDefined();
  });
});

sqlite 사용을 위해 필요한 라이브러리를 다운받습니다.

$ npm install -D sqlite3

그리고 package.json의 scripts의 test를 다음과 같이 수정합니다.

{
  "script": {
    "test": "rm -rf data_sqlite && jest",
  }
}

전체 테스트 코드는 다음과 같습니다.

import { TypeOrmModule, TypeOrmModuleOptions } from '@nestjs/typeorm';
import { DataSource } from 'typeorm';
import { Module } from '@nestjs/common';
import { Test, TestingModule } from '@nestjs/testing';
import { TodoService } from './todo.service';

import { Todo } from './entity/todo.entity';

const databaseProviders = [
  {
    provide: 'DATA_SOURCE',
    useFactory: async () => {
      const dataSource = new DataSource({
        name: 'todo',
        type: 'sqlite',
        database: './data_sqlite/example.sq3',
        entities: [Todo],
        synchronize: true,
      });

      return dataSource.initialize();
    },
  },
];

@Module({
  providers: [...databaseProviders],
  exports: [...databaseProviders]
})
export class DatabaseModule {}

describe('TodoService', () => {
  let service: TodoService;

  beforeEach(async () => {
    const module: TestingModule = await Test.createTestingModule({
      imports: [DatabaseModule],
      providers: [
        {
          provide: 'TODO_REPOSITORY',
          useFactory: (dataSource: DataSource) => dataSource.getRepository(Todo),
          inject: ['DATA_SOURCE'],
        },
        TodoService
      ],
    }).compile();

    service = module.get<TodoService>(TodoService);
  });

  it('should be defined', () => {
    expect(service).toBeDefined();
  });

  it('조회', async () => {
    const res = await service.findAll();
    expect(res.length).toBe(0);
  })
  
  it('생성', async () => {
    const todo = new Todo();
    todo.name = '생성';
    todo.description = '생성';
    todo.isComplete = 0;
    await service.create(todo);
    
    const res = await service.findAll();
    expect(res.length).toBe(1);
  })
  
  it('상태변경', async () => {
    let todo = await service.find(1);
    todo.isComplete = 1
    await service.update(1, todo);

    todo = await service.find(1);

    expect(todo.isComplete).toBe(1);
  })
  
  it('삭제', async () => {
    await service.delete(1);

    const res = await service.findAll();
    expect(res.length).toBe(0);
  })
});

서비스가 원하는 형태로 잘 동작합니다. 또한 테스트 환경과 API가 동작하는 환경에서 완전히 분리된 데이터베이스 소스를 가지기 때문에 테스트를 통해 데이터베이스가 더렵혀지지 않습니다.

여기서 한 가지 정보를 알려드리면 sqlite는 bool 타입을 지원하지 않기 때문에 앞에서 entity를 만들때 isComplete를 bool 타입이 아닌 int 타입으로 생성했던겁니다.

· 컨트롤러 만들기

자 이제 해당 서비스를 주입받아 사용자에게 요청을 받고 응답하는 컨트롤러를 만들어봅니다.

파일명: src/todo/todo.controller.ts

import { Controller, Get, Post, Put, Delete, Body, Param } from '@nestjs/common';
import { Todo } from './entity/todo.entity';
import { TodoService } from './todo.service';

@Controller('todo')
export class TodoController {
  constructor(
    private readonly todoService: TodoService,
  ) {}

  @Get()
  findAll(): Promise<Todo[]> {
    return this.todoService.findAll();
  }

  @Get(':id')
  find(@Param('id') id): Promise<Todo> {
    return this.todoService.find(id);
  }

  @Post()
  create(@Body() todo: Todo): Promise<Todo> {
    return this.todoService.create(todo);
  }

  @Put(':id')
  update(@Param('id') id, todo: Todo): Promise<Todo> {
    return this.todoService.update(id, todo);
  }

  @Delete(':id')
  delete(@Param('id') id): Promise<Todo> {
    return this.todoService.delete(id);
  }
}

이제 해당 컨트롤러가 잘 동작하는지 살펴봐야 겠죠 같은 경로에 있는 todo.controller.spec.ts를 통해 단위 테스트가 가능하고 /test에서 e2e 테스트를 만들 수 있습니다.

· todo 컨트롤러 테스트

먼저 단위 테스트를 수행하겠습니다.

파일명: src/todo/todo.cotroller.spec.ts

import { Test, TestingModule } from '@nestjs/testing';
import { TodoController } from './todo.controller';

import { TypeOrmModule, TypeOrmModuleOptions } from '@nestjs/typeorm';
import { DataSource } from 'typeorm';
import { Module } from '@nestjs/common';
import { TodoService } from './todo.service';

import { Todo } from './entity/todo.entity';

const databaseProviders = [
  {
    provide: 'DATA_SOURCE',
    useFactory: async () => {
      const dataSource = new DataSource({
        name: 'todo',
        type: 'sqlite',
        database: './data_sqlite/controller.sq3',
        entities: [Todo],
        synchronize: true,
      });

      return dataSource.initialize();
    },
  },
];

@Module({
  providers: [...databaseProviders],
  exports: [...databaseProviders]
})
export class DatabaseModule {}

describe('TodoController', () => {
  let controller: TodoController;

  beforeEach(async () => {
    const module: TestingModule = await Test.createTestingModule({
      imports: [DatabaseModule],
      providers: [
        {
          provide: 'TODO_REPOSITORY',
          useFactory: (dataSource: DataSource) => dataSource.getRepository(Todo),
          inject: ['DATA_SOURCE'],
        },
        TodoService
      ],
      controllers: [TodoController],
    }).compile();

    controller = module.get<TodoController>(TodoController);
  });

  it('should be defined', () => {
    expect(controller).toBeDefined();
  });

  it('조회', async() => {
    const res = await controller.findAll();
    expect(res.length).toBe(0);
  })

  it('생성', async () => {
    const todo = new Todo();
    todo.name = '생성';
    todo.description = '생성';
    todo.isComplete = 0;
    await controller.create(todo);
    
    const res = await controller.findAll();
    expect(res.length).toBe(1);
  })
  
  it('상태변경', async () => {
    let todo = await controller.find(1);
    todo.isComplete = 1
    await controller.update(1, todo);

    todo = await controller.find(1);

    expect(todo.isComplete).toBe(1);
  })
  
  it('삭제', async () => {
    await controller.delete(1);

    const res = await controller.findAll();
    expect(res.length).toBe(0);
  })
});

이와 마찬가지로 API를 직접 호출하는 e2e 테스트에서도 별도의 데이터베이스 소스를 생성하여 테스트를 진행할 수 있습니다.

import { Test, TestingModule } from '@nestjs/testing';
import { INestApplication, Module } from '@nestjs/common';
import * as request from 'supertest';
import { DataSource } from 'typeorm';
import { Todo } from '../src/todo/entity/todo.entity';
import { TodoService } from '../src/todo/todo.service';
import { TodoController } from '../src/todo/todo.controller';

const databaseProviders = [
  {
    provide: 'DATA_SOURCE',
    useFactory: async () => {
      const dataSource = new DataSource({
        name: 'todo',
        type: 'sqlite',
        database: './data_sqlite/e2e.sq3',
        entities: [Todo],
        synchronize: true,
      });

      return dataSource.initialize();
    },
  },
];

@Module({
  providers: [...databaseProviders],
  exports: [...databaseProviders]
})
export class DatabaseModule {}

describe('AppController (e2e)', () => {
  let app: INestApplication;

  beforeEach(async () => {
    const moduleFixture: TestingModule = await Test.createTestingModule({
      imports: [DatabaseModule],
      providers: [
        {
          provide: 'TODO_REPOSITORY',
          useFactory: (dataSource: DataSource) => dataSource.getRepository(Todo),
          inject: ['DATA_SOURCE'],
        },
        TodoService
      ],
      controllers: [TodoController],
    }).compile();

    app = moduleFixture.createNestApplication();
    await app.init();
  });

  it('/todo (GET)', () => {
    return request(app.getHttpServer())
      .get('/todo')
      .expect(200)
      .expect([]);
  });

  it('/todo (POST)', () => {
    return request(app.getHttpServer())
      .post('/todo')
      .send({
        name: '생성',
        description: '생성',
        isComplete: 0,
      })
      .expect(201)
      .expect({
        name: '생성',
        description: '생성',
        isComplete: 0,
      });
  })
});

package.json의 script에서 test:e2e를 다음과 같이 수정합니다.

{
  "scripts" :{
    "test:e2e": "rm -rf data_sqlite && jest --config ./test/jest-e2e.json"
  }
}

추가적으로 컨트롤러나 서비스는 또 사이드 이펙트가 존재하는 프로바이더를 주입받을 수 있습니다. 이 또한 테스트를 진행할 때 사이드 이펙트가 모킹되거나 스파이를 통해 테스트를 진행할 수 있습니다.

여기서 핵심은 DI를 하게되면 코드의 확장성도 좋아지지만 테스트 코드를 작성하기가 매우 쉬워집니다.

여기까지 보면 DIP는 추상화된 인터페이스를 이용하도록 되어있는데 여기서는 그렇게 진행하진 않았습니다.

· 사이드 이펙트가 존재하는 서비스

일반적으로 사이드 이펙트의 대표적인 예시가 네트워크 통신입니다. 여기서는 랜덤값을 반환하는 함수로 대체하여 진행합니다.

import { Injectable } from '@nestjs/common';

@Injectable()
export class SideEffectService {
  constructor(
  ) {}

  async getRandom(): Promise<number> {
    return Math.random();
  }
}

// src/sideEffect/sideEffect.module.ts
import { Module } from '@nestjs/common';
import { SideEffectService } from './sideEffect.service';

@Module({
  providers: [{
    provide: 'SIDE_EFFECT_SERVICE',
    useFactory: () => {
      return SideEffectService;
    }
  }],
  exports: [{
    provide: 'SIDE_EFFECT_SERVICE',
    useFactory: () => {
      return SideEffectService;
    }
  }],
})
export class SideEffectModule {}

이제 이를 todo에서 사용가능하도록 하겠습니다.

todo.module.ts에서 해당 모듈을 imports에 추가하면 됩니다.

import { Module } from '@nestjs/common';
import { TodoService } from './todo.service';
import { TodoController } from './todo.controller';

import { DataSource } from 'typeorm';
import { Todo } from './entity/todo.entity';
import { DatabaseModule } from 'src/database/database.module';
import { SideEffectModule } from 'src/sideEffect/sideEffect.module';

@Module({
  imports: [DatabaseModule, SideEffectModule],
  providers: [
    {
      provide: 'TODO_REPOSITORY',
      useFactory: (dataSource: DataSource) => dataSource.getRepository(Todo),
      inject: ['DATA_SOURCE'],
    },
    TodoService
  ],
  controllers: [TodoController]
})
export class TodoModule { }

todo.controller.ts에서 SideEffectService를 주입받고 Post() 요청 핸들러인 create()에서 desciption을 앞에서 만든 랜덤값을 추가하여 저장하도록 합니다.

import { Controller, Get, Post, Put, Delete, Body, Param } from '@nestjs/common';
import { SideEffectService } from '../sideEffect/sideEffect.service';
import { Todo } from './entity/todo.entity';
import { TodoService } from './todo.service';

@Controller('todo')
export class TodoController {
  constructor(
    private readonly todoService: TodoService,
    @Inject('SIDE_EFFECT_SERVICE') private readonly sideEffectService: SideEffectService,
  ) {}

  @Get()
  findAll(): Promise<Todo[]> {
    return this.todoService.findAll();
  }

  @Get(':id')
  find(@Param('id') id): Promise<Todo> {
    return this.todoService.find(id);
  }

  @Post()
  async create(@Body() todo: Todo): Promise<Todo> {
    const random = await this.sideEffectService.getRandom();
    todo.description = `${todo.description} ${random}`;
    return this.todoService.create(todo);
  }

  @Put(':id')
  update(@Param('id') id, todo: Todo): Promise<Todo> {
    return this.todoService.update(id, todo);
  }

  @Delete(':id')
  delete(@Param('id') id): Promise<Todo> {
    return this.todoService.delete(id);
  }
}

이 친구를 우리는 어떻게 테스트할 수 있을까요? 자 우선 서버를 구동한 후 API 요청을 해보겠습니다

> SELECT * FROM todo;
+----+------+-------------------------+------------+
| id | name | description             | isComplete |
+----+------+-------------------------+------------+
|  1 | name | test 0.9163431432608733 |          0 |
+----+------+-------------------------+------------+
1 row in set (0.00 sec)

· 사이드 이펙트 테스트

자 이제 우리는 e2e를 통해 SideEffect를 호출해서 우리가 원하는대로 description에 추가해서 저장되는지 테스트를 수행해보겠습니다.

import { Test, TestingModule } from '@nestjs/testing';
import { INestApplication, Injectable, Module, Query } from '@nestjs/common';
import * as request from 'supertest';
import { DataSource } from 'typeorm';
import { Todo } from '../src/todo/entity/todo.entity';
import { TodoService } from '../src/todo/todo.service';
import { TodoController } from '../src/todo/todo.controller';

const databaseProviders = [
  {
    provide: 'DATA_SOURCE',
    useFactory: async () => {
      const dataSource = new DataSource({
        name: 'todo',
        type: 'sqlite',
        database: './data_sqlite/e2e.sq3',
        entities: [Todo],
        synchronize: true,
      });

      return dataSource.initialize();
    },
  },
];

@Module({
  providers: [...databaseProviders],
  exports: [...databaseProviders]
})
class DatabaseModule {}

@Injectable()
class SideEffectService {
  constructor() {}

  async getRandom(): Promise<number> {
    return 11234;
  }
}

@Module({
  providers: [{
    provide: 'SIDE_EFFECT_SERVICE',
    useClass: SideEffectService,
  }],
  exports: [{
    provide: 'SIDE_EFFECT_SERVICE',
    useClass: SideEffectService,
  }],
})
class SideEffectModule{}

describe('AppController (e2e)', () => {
  let app: INestApplication;

  beforeEach(async () => {
    const moduleFixture: TestingModule = await Test.createTestingModule({
      imports: [DatabaseModule, SideEffectModule],
      providers: [
        {
          provide: 'TODO_REPOSITORY',
          useFactory: (dataSource: DataSource) => dataSource.getRepository(Todo),
          inject: ['DATA_SOURCE'],
        },
        TodoService, 
      ],
      controllers: [TodoController],
    }).compile();

    app = moduleFixture.createNestApplication();
    await app.init();
  });

  it('/todo (GET)', () => {
    return request(app.getHttpServer())
      .get('/todo')
      .expect(200)
      .expect([]);
  });

  it('/todo (POST)', () => {
    return request(app.getHttpServer())
      .post('/todo')
      .type('application/json')
      .send({
        name: '생성',
        description: '생성',
        isComplete: 0,
      })
      .expect(201)
      .expect({
        name: '생성',
        description: '생성 11234',
        isComplete: 0,
        id: 1
      });
  })
});

기존의 모듈을 만들었던 부분에서 고정된 랜덤값을 반환하는 SideEffectService()를 주입합니다.

@Injectable()
class SideEffectService {
  constructor() {}

  async getRandom(): Promise<number> {
    return 11234;
  }
}

TodoController는 주입된 서비스를 정상적으로 동작하여 description이 수정되어 저장되는 모습을 확인할 수 있습니다.

만약 네트워크 통신을 하는 부분이라면 존재하는 에러 코드를 반환하도록 모킹한 후 해당 에러코드에 대해서 원하는 방향으로 동작하는지 테스트가 가능합니다.

todo.controller.spec도 테스트 코드 수정이 필요합니다.

import { Test, TestingModule } from '@nestjs/testing';
import { TodoController } from './todo.controller';

import { DataSource } from 'typeorm';
import { Module } from '@nestjs/common';
import { TodoService } from './todo.service';

import { Todo } from './entity/todo.entity';

const databaseProviders = [
  {
    provide: 'DATA_SOURCE',
    useFactory: async () => {
      const dataSource = new DataSource({
        name: 'todo',
        type: 'sqlite',
        database: './data_sqlite/controller.sq3',
        entities: [Todo],
        synchronize: true,
      });

      return dataSource.initialize();
    },
  },
];

@Module({
  providers: [...databaseProviders],
  exports: [...databaseProviders]
})
export class DatabaseModule {}

@Module({
  providers: [{
    provide: 'SIDE_EFFECT_SERVICE',
    useClass: SideEffectService,
  }],
  exports: [{
    provide: 'SIDE_EFFECT_SERVICE',
    useClass: SideEffectService,
  }],
})
class SideEffectModule{}

describe('TodoController', () => {
  let controller: TodoController;

  beforeEach(async () => {
    const module: TestingModule = await Test.createTestingModule({
      imports: [DatabaseModule, SideEffectModule],
      providers: [
        {
          provide: 'TODO_REPOSITORY',
          useFactory: (dataSource: DataSource) => dataSource.getRepository(Todo),
          inject: ['DATA_SOURCE'],
        },
        TodoService
      ],
      controllers: [TodoController],
    }).compile();

    controller = module.get<TodoController>(TodoController);
  });

  it('should be defined', () => {
    expect(controller).toBeDefined();
  });

  it('조회', async() => {
    const res = await controller.findAll();
    expect(res.length).toBe(0);
  })

  it('생성', async () => {
    const todo = new Todo();
    todo.name = '생성';
    todo.description = '생성';
    todo.isComplete = 0;
    await controller.create(todo);
    
    const res = await controller.findAll();
    expect(res.length).toBe(1);
  })
  
  it('상태변경', async () => {
    let todo = await controller.find(1);
    todo.isComplete = 1
    await controller.update(1, todo);

    todo = await controller.find(1);

    expect(todo.isComplete).toBe(1);
  })
  
  it('삭제', async () => {
    await controller.delete(1);

    const res = await controller.findAll();
    expect(res.length).toBe(0);
  })
});

· DIP 적용하기 - 방법1

nestjs에선 DIP를 아주 쉽게 적용할 수 있습니다. module에 전달하는 providers에서 provider를 문자열이 아니라 인터페이스를 넣어주면 됩니다.

@Module({
  providers: [{
    provide: SideEffectService,
    useClass: SideEffectService,
  }],
  exports: [{
    provide: SideEffectService,
    useClass: SideEffectService,
  }],
})
class SideEffectModule{}

해당 프로바이더를 주입받는 클래스는 다음과 같이 주입 inject를 사용합니다.

  constructor(
    private readonly todoService: TodoService,
    @Inject(SideEffectService) private readonly sideEffectService: SideEffectService,
  ) {}

하지만 서비스 자체를 넣는 방법보다는 인터페이스와 함께 상수를 정의하여 사용하는 방법을 권장합니다.

// src/sideEffect/ISideEffect.interface.ts
export const SIDE_EFFECT_TOKEN = "SIDE_EFFECT";

export interface ISideEffect {
  getRandom:() => Promise<number>;
};

// src/sideEffect/sideEffect.service.ts
import { Injectable } from '@nestjs/common';
import { ISideEffect } from './ISideEffect.interface';

@Injectable()
export class SideEffectService implements ISideEffect{
  constructor(
  ) {}

  async getRandom(): Promise<number> {
    return Math.random();
  }
}

// src/sideEffect/sideEffect.module.ts
import { Module } from '@nestjs/common';
import { SIDE_EFFECT_TOKEN } from './ISideEffect.interface';
import { SideEffectService } from './sideEffect.service';

@Module({
  providers: [{
    provide: SIDE_EFFECT_TOKEN,
    useFactory: () => {
      return SideEffectService;
    }
  }],
  exports: [{
    provide: SIDE_EFFECT_TOKEN,
    useFactory: () => {
      return SideEffectService;
    }
  }],
})
export class SideEffectModule {}

이에 따라서 SideEffectService를 주입받는 todo 컨트롤러의 생성자도 수정합니다.

... 중략

@Controller('todo')
export class TodoController {
  constructor(
    private readonly todoService: TodoService,
    @Inject(SIDE_EFFECT_TOKEN) private readonly sideEffectService: ISideEffect,
  ) {}
}

또한 테스트 코드에서도 주입 시 provide 이름을 변경해줍니다.

· DIP 적용 - 서비스 그대로 활용

앞의 방법으로 한다면 provide를 문자열로 해야하는 단점이 있습니다. 즉, 실수로 이미 사용중인 값을 사용할 수 있는데 이땐 서비스 자체를 provide로 넘기고 @Inject()에 넘겨주면 됩니다.

// src/sideEffect/sideEffect.module.ts

import { Module } from '@nestjs/common';
import { SideEffectService } from './sideEffect.service';

@Module({
  providers: [
    {
      provide: SideEffectService,
      useFactory: () => {
        return SideEffectService;
      },
    },
  ],
  exports: [
    {
      provide: SideEffectService,
      useFactory: () => {
        return SideEffectService;
      },
    },
  ],
})
export class SideEffectModule {}

provide가 바뀌었으니 controller에서 @Inject()를 수정합니다.

// src/todo/todo.contoller.ts
import {
  Controller,
  Get,
  Post,
  Put,
  Delete,
  Body,
  Param,
  Inject,
} from '@nestjs/common';

import { Todo } from './entity/todo.entity';
import { TodoService } from './todo.service';
import { SideEffectService } from '../sideEffect/sideEffect.service';

@Controller('todo')
export class TodoController {
  constructor(
    private readonly todoService: TodoService,
    @Inject(SideEffectService) // 변경
    private readonly sideEffectService: SideEffectService,
  ) {}

  @Get()
  findAll(): Promise<Todo[]> {
    return this.todoService.findAll();
  }

  @Get(':id')
  find(@Param('id') id): Promise<Todo> {
    return this.todoService.find(id);
  }

  @Post()
  async create(@Body() todo: Todo): Promise<Todo> {
    const random = await this.sideEffectService.getRandom();
    todo.description = `${todo.description} ${random}`;
    return this.todoService.create(todo);
  }

  @Put(':id')
  update(@Param('id') id, todo: Todo): Promise<Todo> {
    return this.todoService.update(id, todo);
  }

  @Delete(':id')
  delete(@Param('id') id): Promise<Todo> {
    return this.todoService.delete(id);
  }
}

또한 테스트 코드에서도 다음과 같이 수정합니다.

// src/todo/todo.controller.spec.ts
import { Test, TestingModule } from '@nestjs/testing';
import { TodoController } from './todo.controller';

import { DataSource } from 'typeorm';
import { Module } from '@nestjs/common';
import { TodoService } from './todo.service';

import { Todo } from './entity/todo.entity';
import { SideEffectService } from '../sideEffect/sideEffect.service';

const databaseProviders = [
  {
    provide: DataSource,
    useFactory: async () => {
      const dataSource = new DataSource({
        name: 'todo',
        type: 'sqlite',
        database: './data_sqlite/controller.sq3',
        entities: [Todo],
        synchronize: true,
      });

      return dataSource.initialize();
    },
  },
];

@Module({
  providers: [...databaseProviders],
  exports: [...databaseProviders],
})
export class DatabaseModule {}

describe('TodoController', () => {
  let controller: TodoController;

  beforeEach(async () => {
    const module: TestingModule = await Test.createTestingModule({
      imports: [DatabaseModule],
      providers: [
        {
          provide: Todo,
          useFactory: (dataSource: DataSource) =>
            dataSource.getRepository(Todo),
          inject: [DataSource],
        },
        { provide: SideEffectService, useValue: { getRandom: () => 11234 } },
        TodoService,
      ],
      controllers: [TodoController],
    }).compile();

    controller = module.get<TodoController>(TodoController);
  });

  it('should be defined', () => {
    expect(controller).toBeDefined();
  });

  it('조회', async () => {
    const res = await controller.findAll();
    expect(res.length).toBe(0);
  });

  it('생성', async () => {
    const todo = new Todo();
    todo.name = '생성';
    todo.description = '생성';
    todo.isComplete = 0;
    await controller.create(todo);

    const res = await controller.findAll();
    expect(res.length).toBe(1);
  });

  it('상태변경', async () => {
    let todo = await controller.find(1);
    todo.isComplete = 1;
    await controller.update(1, todo);

    todo = await controller.find(1);

    expect(todo.isComplete).toBe(1);
  });

  it('삭제', async () => {
    await controller.delete(1);

    const res = await controller.findAll();
    expect(res.length).toBe(0);
  });
});

// test/todo.e2e-spec.ts
import { Test, TestingModule } from '@nestjs/testing';
import { INestApplication, Module } from '@nestjs/common';
import * as request from 'supertest';
import { DataSource } from 'typeorm';
import { Todo } from '../src/todo/entity/todo.entity';
import { TodoService } from '../src/todo/todo.service';
import { TodoController } from '../src/todo/todo.controller';

import { SideEffectService } from '../src/sideEffect/sideEffect.service';

const databaseProviders = [
  {
    provide: DataSource,
    useFactory: async () => {
      const dataSource = new DataSource({
        name: 'todo',
        type: 'sqlite',
        database: './data_sqlite/e2e.sq3',
        entities: [Todo],
        synchronize: true,
      });

      return dataSource.initialize();
    },
  },
];

@Module({
  providers: [...databaseProviders],
  exports: [...databaseProviders],
})
class DatabaseModule {}

describe('AppController (e2e)', () => {
  let app: INestApplication;

  beforeEach(async () => {
    const moduleFixture: TestingModule = await Test.createTestingModule({
      imports: [DatabaseModule],
      providers: [
        {
          provide: Todo,
          useFactory: (dataSource: DataSource) =>
            dataSource.getRepository(Todo),
          inject: [DataSource],
        },
        { provide: SideEffectService, useValue: { getRandom: () => 11234 } },
        TodoService,
      ],
      controllers: [TodoController],
    }).compile();

    app = moduleFixture.createNestApplication();
    await app.init();
  });

  it('/todo (GET)', () => {
    return request(app.getHttpServer()).get('/todo').expect(200).expect([]);
  });

  it('/todo (POST)', () => {
    return request(app.getHttpServer())
      .post('/todo')
      .type('application/json')
      .send({
        name: '생성',
        description: '생성',
        isComplete: 0,
      })
      .expect(201)
      .expect({
        name: '생성',
        description: '생성 11234',
        isComplete: 0,
        id: 1,
      });
  });
});

https://github.com/pjt3591oo/nest-todo-sample

GitHub - pjt3591oo/nest-todo-sample: https://blog.naver.com/pjt3591oo/222805317573 샘플코드

https://blog.naver.com/pjt3591oo/222805317573 샘플코드 - GitHub - pjt3591oo/nest-todo-sample: https://blog.naver.com/pjt3591oo/222805317573 샘플코드

github.com

[디자인 패턴] ES6로 구현하는 디자인 패턴

멍개. — Sun, 28 Aug 2022 16:08:21 +0900

※ 디자인 패턴 종류

▶ 생성패턴

Constructor
Factory
Abstract Factory
Prototype
Singleton
Builder

▶ 구조 패턴

Adapter
Composite
Module
Decorator
Facade
Proxy
FlyWeight
Bridge

▶ 행동 패턴

Chain of Responsibility
Command
Observer
Iterator
Template
Strategy
visitor
state
memento
mediator

● 생성패턴

생성 패턴은 객체를 생성하는 다양한 방법을 제공합니다.

· 1. 생성자 패턴

생성자 패턴은 기존에 클래스를 제공하지 않았던 자바스크립트가 ES6에서 class 키워드 제공을 통해 향상된 패턴

// 옛날 스타일
function OldPerson(name, age) {
  this.name = name;
  this.age = age;
  this.getDetails = function () {
    console.log(`[OLD] ${this.name} is ${this.age} years old!`);
  }
}

// 인스턴스 생성
const oldPerson = new OldPerson('John', 20);
oldPerson.say(); // [OLD] Output - “John is 20years old!”

class NewPerson {
  constructor(name, age) {
    this.name = name;
    this.age = age;
    this.say() = function () {
      console.log(`[NEW] ${this.name} is ${this.age} years old!`);
    };
  }
}

// 인스턴스 생성
const newPerson = new NewPerson('John', 20);
newPerson.say(); // [NEW] Output - “John is 20years old!”

· 2. Factory Pattern(팩토리 패턴)

팩토리 패턴은 클래스가 객체를 생성하는 패턴

Factory 클래스에 의해 생성하는 객체는 동일한 인터페이스를 가져야 함

class Person {
  constructor() {}
  
  make (type) {
    switch (type) {
      case 'house':
        return new House();
      case 'car':
        return new Car();
      default:
        return false;
    }
  }
}

class House {
  constructor() {}

  say () {
    console.log(`I'm House`);
  }
}

class Car {
  constructor() {}

  say () {
    console.log(`I'm Car`);
  }
}

const person = new Person()

const house = person.make('house')
const car = person.make('car')

house.say() // I'm House
car.say()   // I'm Car

· 3. Prototype Pattern (프로토타입 패턴)

프로토타입 패턴은 객체의 템플릿을 기반으로 새로운 객체를 만들 수 있다. 프로토타입 패턴은 상속을 기반으로 하지만 JavaScript는 Object의 create() 메소드를 활용하여 손쉽게 구현 가능.

여기서는 json, class로 템플릿을 제공하는 방법을 다뤄봅니다.

const car = {
  noOfWheels: 4,
  start() {
    return `start ${this.noOfWheels}`;
  },
  stop() {
    return `stop ${this.noOfWheels}`;
  },
};

const myCar1 = Object.create(car, { owner: { value: 'Mung1' } });
const myCar2 = Object.create(car, { owner: { value: 'Mung2' } });

console.log(myCar1.__proto__ === car); // true
console.log(myCar2.__proto__ === car); // true

myCar2.noOfWheels += 10

console.log(myCar1.start()) // start 4
console.log(myCar1.stop()) // stop 4
console.log(myCar1.noOfWheels) // 4
console.log(myCar1.owner)  // Mung1

console.log(myCar2.noOfWheels) // 14

class Car {
  constructor (_wheels) {
    this.noOfWheels = _wheels;
  }
  
  start() {
    return `start ${this.noOfWheels}`;
  }
  
  stop() {
    return `stop ${this.noOfWheels}`;
  }
}

const car = new Car(4);

const cloneCar1 = Object.create(car, { owner: { value: 'Mung1' } });
const cloneCar2 = Object.create(car, { owner: { value: 'Mung2' } });

console.log(cloneCar1.__proto__ === car); // true
console.log(cloneCar2.__proto__ === car); // true

cloneCar2.noOfWheels += 10

console.log(cloneCar1.start()) // start 4
console.log(cloneCar1.stop()) // stop 4
console.log(cloneCar1.noOfWheels) // 4
console.log(cloneCar1.owner)  // Mung1

console.log(cloneCar2.noOfWheels) // 14

· 4. Singleton Pattern (싱글톤 패턴)

싱글톤은 하나의 객체만 생성하는 목적으로 사용

디비 커넥션 처럼 한 시스템에서 매번 커넥션을 연결할 필요 없을 때 싱글톤을 이용하여 하나의 커넥션만 유지

class Car {
  constructor (_wheels) {
    this.wheels = _wheels;
  }
  
  setWheels(_n) {
    this.wheels = _n;
  }
}

const Singleton = {
  instance: null,

  getInstance(_param1) {
    if(!this.instance) this.instance = new Car(_param1);
    return this.instance
  },
};

let car1 = Singleton.getInstance(4);
let car2 = Singleton.getInstance(3);
let car3 = Singleton.getInstance(2);

console.log(car1.wheels, car2.wheels, car3.wheels); // 4 4 4
car2.setWheels(10)
console.log(car1.wheels, car2.wheels, car3.wheels); // 10 10 10

· 5. Builder Pattern (빌더 패턴)

빌더 패턴은 체이닝 형태를 유지하여 확장성 있는 객체를 만들 수

※ Before

class Request { 
  constructor(url, data, method) { 
    this.url = url; 
    this.method = method; 
    this.data = data; 
  } 
}

url과 method만 설정하고 싶다면 다음과 같이 객체를 생성할 수 있음

const request = new Request('http://localhost', {}, method)

하지만 data를 반드시 전달해줘야 함

빌더 패턴을 사용하면 전달하지 않아도 될 인자는 전달할 필요 없음

class Request { 
  constructor() { 
    this.url = ''; 
    this.method = ''; 
    this.data = null; 
  } 
} 

class RequestBuilder { 
  constructor() { 
    this.request = new Request(); 
  } 
  forUrl(url) { 
    this.request.url = url; 
    return this; 
  } 
  
  useMethod(method) { 
    this.request.method = method; 
    return this; 
  } 
  
  setData(data) { 
    this.request.data = data; 
    return this; 
  } 
  
  build() { 
    return this.request; 
  } 
} 

let getRequest = new RequestBuilder() 
  .forUrl('https://blog.naver.com/pjt3591oo') 
  .useMethod('GET') 
  .build(); 
  
let postRequest = new RequestBuilder() 
    .forUrl('https://blog.naver.com/pjt3591oo') 
    .useMethod('POST') 
    .setData({ id: 'hg', password: 1234 }) 
    .build();

한 가지 중요한 점은 속성을 설정하는 메소드는 반드시 this를 반환하여 체이닝이 가능하도록 해야함

● Structural Design Pattern

· 1. Adapter Pattern (어댑터 패턴)

어댑터 패턴은 서로다른 인터페이스 시스템을 맞추기 위해 어댑터를 추가하여 마치 하나의 시스템인 것 처럼 동작하는 패턴

Client는 과거에 만들어진 인터페이스

Adaptee는 발전된 형태의 인터페이스

기존의 코드는 Client 인터페이스에 맞춰서 개발이 되었기 때문에 새로 개발된 Adaptee를 사용하기 위해선 인터페이스를 수정해야 하지만 Adapter를 이용하여 기존 코드의 인터페이스 수정없이 Adaptee를 사용 할 수 있음

코드가 복잡해 보일 수 있지만 자세히 보면 이전 클래스 인터페이스를 최신 인터페이스와 호환하기 위해 어댑터 클래스를 추가한 모습입니다.

기존의 TicketPrice를 TickerAdapter로 사용자 변경없이 사용가능

어댑터 패턴의 핵심은 기존의 사용중인 인터페이스를 사용자의 큰 변화없이 사용하는 것이 목표

· 2. Composite Pattern (컴포지트 패턴)

컴포지트 패턴은 파티셔닝 JS 디자인 패턴이라고도 불리며 디렉터리(폴더) 구조를 관리하는 모습을 보임

이 모습은 마치 React나 Vue와 같이 컴포넌트를 관리하는 모습을 가짐

class File {
  constructor(_name) {
    this.name = _name;
  }

  display () {
    console.log(this.name);
  }
}

class Directory {
  constructor (_name) {
    this.name = _name;
    this.files = [];
  }

  add (file) {
    this.files.push(file);
  }

  remove (_file) {
    let beforeCnt = this.files.length;
    this.files = this.files.filter(file => file.name !== _file.name);
    let afterCnt = this.files.length;

    return beforeCnt === afterCnt;
  }

  getFileName (_idx) {
    return this.files[_idx].name
  }

  display () {
    console.log(this.name);
    this.files.forEach((file, idx)  => {
      console.log(`  ${this.getFileName(idx)}`) // file.name
    })
  }
}

const directoryOne = new Directory('Directory One');
const directoryTwo = new Directory('Directory Two');
const directoryThree = new Directory('Directory Three');

const fileOne = new File('File One');
const fileTwo = new File('File Two');
const fileThree = new File('File Three');

directoryOne.add(fileOne);
directoryOne.add(fileTwo);

directoryTwo.add(fileOne);

directoryThree.add(fileOne);
directoryThree.add(fileTwo);
directoryThree.add(fileThree);

directoryOne.display();
directoryTwo.display();
directoryThree.display();

· 3. Module Pattern (모듈 패턴)

자바스크립트의 모듈 패턴은 클로저를 이용하여 함수를 마치 클래스처럼 사용하는 기법

function AnimalContainter () {
  const container = [];

  function addAnimal (name) {
    container.push(name);
  }

  function getAllAnimals() {
    return container;
  }

  function removeAnimal(name) {
    const index = container.indexOf(name);
    if(index < 1) {
      throw new Error('Animal not found in container');
    }
    container.splice(index, 1)
  }

  return {
    add: addAnimal,
    get: getAllAnimals,
    remove: removeAnimal
  }
}

  const container = AnimalContainter()

  container.add('Hen')
  container.add('Goat')
  container.add('Sheep')

  console.log(container.get()) // ["Hen", "Goat", "Sheep"]
  container.remove('Sheep')
  console.log(container.get()) // ["Hen", "Goat"]

AnimalContainter에서 반환(리턴)된 변수 / 함수만 외부에서 접근하여 사용가능

· 4. Decorator Pattern (데코레이터, 장식자 패턴)

데코레이터는 코드 재사용을 목적으로 함. 자바스크립트에선 이를 쉽게 구현할 수 있다. 이를 이용하여 동일한 클래스로 만들어진 객체에 다른 동작을 부여할 수 있다

class Vehicle {
  constructor (vehicleType = "car") {
    this.vehicleType = vehicleType;
    this.model = 'default';
    this.license = '12345-123';
  }
}

const truck = new Vehicle( "truck" );

// 여기서 화살표 함수를 사용하면 this 바인딩이 안되기 떄문에 function 이용
truck.setModel = function( _model ){
    this.model = _model;
};

truck.setColor = function( _color ){
    this.color = _color;
};

truck.setModel( "CAT" );
truck.setColor( "blue" );

console.log( truck );
/*
Vehicle {
  vehicleType: 'truck',
  model: 'CAT',
  license: '12345-123',
  setModel: [Function],
  setColor: [Function],
  color: 'blue'
}
*/

const dump = new Vehicle( "dump" );
console.log(dump) // Vehicle { vehicleType: 'dump', model: 'default', license: '12345-123' }

truck으로 전달된 변수 truck만 setModel()과 setColor() 메소드 수행

· 5. Facade Pattern (퍼사드 패턴)

퍼사드 패턴은 내부적으로 복잡한 구조(Subsystem)를 단순화(Facade)하여 외부에 공개하는 패턴

class Bank {
  verify (_name, _amount) {
    return true;
  }
}

class Credit {
  get (_name) {
    return true;
  }
}

class Background {
  check (_name) {
    return true;
  }
}

class Mortgage {
  constructor (_name) {
    this.name = _name;
  }
  
  applyFor (amount) {
    let result = "approved";
    if (!new Bank().verify(this.name, amount)) {
        result = "denied";
    } else if (!new Credit().get(this.name)) {
        result = "denied";
    } else if (!new Background().check(this.name)) {
        result = "denied";
    }
    return `${this.name} has been ${result} for a ${amount} mortgage`
  }
}

const mortgage = new Mortgage("Joan Templeton");
const result = mortgage.applyFor("$100,000");

console.log(result);

클래스 1, 2, 3에 해당하는 Bank, Credit, Background 클래스로 구현된 기능을 Mortgage의 applyFor 메소드를 통해 제공

· 6. Proxy Pattern (프록시 패턴)

프록시 패턴은 접근을 제어하고 비용 절감하며 복잡성을 줄이기 위해 사용

프록시는 네트워크 연결, 큰 메모리 객체와 같은 비용이 많이 들거나 복제가 불가능한 리소스 같은 형태에서 사용

만약 파일을 읽어야 한다면 파일을 직접 읽지 않고 프록시 객체를 통해 접근. 프록시는 반복된 파일 접근에 대해 캐싱 처리 등을 수행할 수 있다. 프록시 패턴을 적용하는 상황은 다음과 같다.

가상 프록시: 생성 비용이 높거나 리소스를 많이 사용하는 객체를 위한 프록시
원격 프록시: 원격 객체에 대한 접근 제어
보호 프록시: 민감한 마스터 객체에 대한 접근 권한 제어

class FlightListAPI {
  getFlight() {
      // get master list of flights
      console.log('Generating flight List');
  }

  searchFlight (flightDetails) {
      // search through the flight list based on criteria
      console.log('Searching for flight');
  }
  
  addFlight(flightData) {
      // add a new flight to the database
      console.log('Adding new flight to DB');
  }
};
  
class FlightListProxy {
  constructor () {
    this.flightList = new FlightListAPI();
  }
  getFlight() {
    return this.flightList.getFlight();
  }

  searchFlight(flightDetails) {
    return this.flightList.searchFlight(flightDetails);
  }

  addFlight(flightData) {
    return this.flightList.addFlight(flightData);
  }
}
  
console.log("----------With Proxy----------")
const proxy = new FlightListProxy()
proxy.getFlight() // Generating flight List

FlightListApi를 직접 제어하지 않고 Proxy를 통해 제어

· 7. Flyweight Pattern (경량화 패턴)

경량화 패턴은 Cost(비용)이 높은 자원을 공통으로 사용하는 패턴

캐시를 목적으로 하는 패턴

자원에 대한 비용이란? 
1. Duplicate Create (반복되는 패턴)
2. Low Frequncy AND Hight Cost About Create (생성 비용이 높지만 자주 사용되지 않는경우)

class Flyweight{
  map: {[key: string]: Subject} = {};
 
  getSubject( name: string ): Subject {
    let subject: Subject = this.map[name];

    if(!subject){
      subject = new Subject(name);
      this.map[name] = subject;
    }

    return subject;
  }
}

class Subject{
  name: string;

  constructor( name: string){
    this.name = name;
    console.log("create : " + name);
  }
}

const flyweight: Flyweight = new Flyweight();

flyweight.getSubject("a");
flyweight.getSubject("a"); // 다시 생성하지 않음
flyweight.getSubject("b");
flyweight.getSubject("b"); // 다시 생성하지 않음

/*
실행결과

create : a
create : b
*/

· 8. Bridge Pattern (브릿지 패턴)

브릿지 패턴은 기능과 구현을 별도의 클래스로 관리

Abstraction: 최상위 기능계층, 해당 인스턴스를 통해 구현 메소드 호출
RefindAbstraction: Abstraction을 이용하여 새로운 계층 생성(상속받아 기능확장)

Implementor: Abstraction 기능 구현을 위해 인터페이스
ConcreteImplementor: Implementor를 상속받아 실제기능 구현

// Implementor: 기능 구현을 위한 인터페이스
interface HuntingHandler {
  find(): void;
  detected(): void;
  attack(): void;
}

// ConcreteImplementor: Implementor를 상속받아 기능 구현
class HuntingMethod1 implements HuntingHandler {
  find(): void {
    console.log('find by HuntingMethod1')
  }
  detected(): void {
    console.log('detected by HuntingMethod1')
  }
  attack(): void {
    console.log('attack by HuntingMethod1')
  }
}

class HuntingMethod2 implements HuntingHandler {
  find(): void {
    console.log('find by HuntingMethod2')
  }
  detected(): void {
    console.log('detected by HuntingMethod2')
  }
  attack(): void {
    console.log('attack by HuntingMethod2')
  }
}

// Abstractor: 기능의 최상위 객체
class Animal {
  hunting: HuntingHandler;

  constructor(hunting: HuntingHandler) {
    this.hunting = hunting
  }

  find() {
    this.hunting.find();
  }
  detected() {
    this.hunting.detected();
  }
  attack() {
    this.hunting.attack();
  }

  hunt() {
    this.find();
    this.detected();
    this.attack();
  }
}

// RefineAbstraction: 최상위 Abstractor 상속받아 실제 클래스 구현
class Tiger extends Animal {
  constructor(hunting: HuntingHandler) {
    super(hunting);
  }

  hunt() {
    super.hunt()
    console.log("사냥끝~~");
  }
}

class Bird extends Animal {
  constructor(hunting: HuntingHandler) {
    super(hunting);
  }

  hunt() {
    super.hunt()
    console.log("사냥끝~~");
  }
}

const tiger: Animal = new Tiger(new HuntingMethod2());
const bird: Animal = new Bird(new HuntingMethod1());

tiger.hunt();
console.log("--------------");
bird.hunt();

/*
실행결과

find by HuntingMethod2
detected by HuntingMethod2
attack by HuntingMethod2
사냥끝~~
--------------
find by HuntingMethod1
detected by HuntingMethod1
attack by HuntingMethod1
사냥끝~~
*/

Abstract에 맞는 Implement를 주입하여 의존도를 낮추고 다양한 조합을 만들 수 있다

// old system
class TicketPrice {
  request(start, end, overweightLuggage) {
    // 가격 계산 로직
    return "$150.34";
  }
}

// new interface
class NewTicketPrice {
  login (credentials) {  };
  setStart (start) { };
  setDestination (destination) {  };
  calculate (overweightLuggage) {
    return "$120.20";
  };
}

// 어댑터
class TicketAdapter {
  constructor (credentials) {
    this.pricing = new NewTicketPrice();
    this.pricing.login(credentials);
  }

  request(start, end, overweightLuggage) {
    this.pricing.setStart(start);
    this.pricing.setDestination(end);
    return this.pricing.calculate(overweightLuggage);
  }
}

var pricing = new TicketPrice();
var credentials = { token: "30a8-6ee1" };
var adapter = new TicketAdapter(credentials);

// original ticket pricing and interface
var price = pricing.request("Bern", "London", 20);
console.log("Old price: " + price);

// new ticket pricing with adapted interface
price = adapter.request("Bern", "London", 20);
console.log("New price: " + price);

● Behavioral Design Pattern

· 1. Chain of Responsibility Pattern

빌더 패턴을 구현하는 핵심 패턴

class Request {
  constructor (_amount) {
    this.amount = _amount;
  }

  get (bill) {
    const count = Math.floor(this.amount / bill);
    this.amount -= count * bill;
    console.log(`Dispense ${count} $${bill} bills`);
    return this;
  }
}

const request = new Request(378); //Requesting amount
request.get(100).get(50).get(20).get(10).get(5).get(1);

this를 반환하여 체이닝을 할 수 있도록 함

· 2. Command Pattern

Command 패턴은 동작이나 작업을 캡술화하는 패턴

A라는 클래스를 작업을 하기 위해 A객체를 직접 접근하지 않고 중간 객체를 통해 작업수행

const calculator = {
  add: function(x, y) {
      return x + y;
  },
  sub: function(x, y) {
      return x - y;
  },
  divide: function(x,y){
      return x/y;
  },
  multiply: function (x,y){
      return x*y;
  }
}

const manager = {
  execute: function(name) {
      if (name in calculator) {
          return calculator[name].apply(calculator, [].slice.call(arguments, 1));
      }
      return false;
  }
}

console.log(manager.execute("add", 5, 2)); //  7
console.log(manager.execute("multiply", 2, 4)); //  8

Command 패턴은 좀 더 견고한 코드를 위해 execute로 수행할 객체를 전달할 수 있다.

· 3. Observer Pattern

Observer 패턴은 관찰중인 객체(Subject)에 발생하는 이벤트에 대해 여러 객체(Observer)에게 알리는 구독 메커니즘 제공

class Click {
  constructor () {
    this.observers = [];
  }

  subscribe (fn) {
    this.observers.push(fn);
  }

  unsubscribe(fn) {
    this.observers = this.observers.filter( (item) => item !== fn );
  }

  fire(o, thisObj) {
    let scope = thisObj;
    this.observers.forEach(function(item) {
      item.call(scope, o);
    });
  }
}

const clickHandler = item => { 
  console.log("Fired:" +item);
};

const click = new Click();

click.subscribe(clickHandler);
click.fire('event #1');

click.unsubscribe(clickHandler);
click.fire('event #2');

click.subscribe(clickHandler);
click.fire('event #3');

/* 
실행결과

Fired:event #1
Fired:event #3
*/

· 4. Iterator Pattern

반복자 패턴을 통해 순차적으로 접근 가능, 하지만 ES6의 제너레이터를 이용하면 좀 더 편하게 구현 가능

const items = [1, "hello", false, 99.8];

class Iterator {
  constructor(items) {
    this.items = items;
    this.index = 0;
  }

  hasNext(){
    return this.index < this.items.length;
  }

  next(){
    return this.items[this.index++]
  }
}

const iterator =  new Iterator(items);
while(iterator.hasNext()){
  console.log(iterator.next());
}

// 제너레이터 이용
const items = [1, "hello", false, 99.8];

function* Iterator (target) {
  for(item in target) {
    yield item;
  }
}

const iterator = Iterator(items);

for (item of iterator) {
  console.log(item)
}

· 5. Template Pattern

템플릿 패턴은 객체의 뼈대만 정의. 객체가 만들어지면 세부적인 내용 정의

// 인터페이스 클래스
// 사용자가 구현할 항목 명시
class DataStore {
  connect() {}

  select() {}

  disconnect() {}
}

class Mysql extends DataStore {
  constructor () {
    super()
  }

  process() {
    this.connect();
    this.select();
    this.disconnect();
  }
}

const mySql = new Mysql();

// 상속받은 인터페이스 정의
mySql.connect = function() {
  console.log("MySQL: connect step");
};

mySql.select = function() {
  console.log("MySQL: select step");
};

mySql.disconnect = function() {
  console.log("MySQL: disconnect step");
};

mySql.process();

템플릿 패턴은 특정 기능을 제공하기 위해 구현할 기능 인터페이스를 제공함으로써 사용자가 원하는 기능을 구현할 수 있도록 도와줌

process() 메서드 호출시 수행하는 메소드들을 객체 생성 후 정의한대로 동작

· 6. Strategy Pattern

Strategy 패턴은 A, B에 대한 알고리즘 정의후 각 알고리즘을 캡슐화하여 런타임 환경에서 각 알고리즘 상호교환

// 전략1 
class FedEx {
  constructor () {}
  calculate(p) {
    return 'FedEx'
  }

}

// 전략2
class UPS {
  constructor () {}
  calculate (p) {
    return 'UPS'
  }
}

// 전략3
class USPS {
  constructor () {}
  calculate (p) {
    return 'USPS'
  }
}

// 전략관리 클래스
class Strategy {
  constructor () {
    this.company = null
  }

  setStrategy (company) {
    this.company = company;
  }

  calculate (p) {
    console.log('this.company')
    if (!this.company) {return}
    return this.company.calculate(p);
  }
}

// 사용
const fedex = new FedEx();
const ups = new UPS();
const usps = new USPS();

const p = { from: 'Alabama',to:'Georgia',weight:1.5};

const strategy = new Strategy();
strategy.setStrategy(fedex); // 런타임 환경에서 ups, usps를 전달할 수 있음
console.log(`Fedex: ${strategy.calculate(p)}`);  // Fedex: FedEx

· Visitor Pattern (방문자 패턴)

방문자 패턴은 방문자(데이터 구조)와 방문 공간(데이터 연산)을 분리. 방문자는 방문 공간으로부터 행동을 위임받아 수행

새로운 연산을 추가할 땐 위해 새로운 방문자 추가

먼저, 방문공간을 정의합니다.

interface ComputerPart {
  accept(computerPartVisitor: ComputerPartVisitor): void;
}


class Keyboard implements ComputerPart {
  accept( computerPartVisitor: ComputerPartVisitor) {
     computerPartVisitor.visit(this);
  }
}
class Monitor implements ComputerPart {
  accept( computerPartVisitor: ComputerPartVisitor) {
     computerPartVisitor.visit(this);
  }
}
class Mouse implements ComputerPart {
  accept( computerPartVisitor: ComputerPartVisitor) {
     computerPartVisitor.visit(this);
  }
}
class Computer implements ComputerPart {
  parts: ComputerPart[];
  constructor() {
    this.parts = [new Mouse(), new Monitor(), new Keyboard()]
  }

  accept(computerPartVisitor: ComputerPartVisitor) {
    for (let i = 0; i < this.parts.length; i++) {
      this.parts[i].accept(computerPartVisitor);
   }
    computerPartVisitor.visit(this);
  }
}

방문자 패턴을 위한 방문 공간(ComputerPart)정의를 완료했습니다. 해당 공간을 방문할 방문 (ComputerPartVisitor)를 정의하겠습니다.

방문공간은 accept(방문자) 메소드를 통해 방문자를 받는다

다음으로 방문공간에 방문할 방문자를 정의합니다.

interface ComputerPartVisitor {
	visit(computer: Computer);
	visit(mouse: Mouse);
	visit(keyboard: Keyboard);
	visit(monitor: Monitor);
}

class ComputerPartDisplayVisitor implements ComputerPartVisitor {

  visit(computer: Computer): void  {
     console.log("Displaying Computer.");
  }

  visit(mouse: Mouse): void  {
     console.log("Displaying Mouse.");
  }

  visit(keyboard: Keyboard): void  {
     console.log("Displaying Keyboard.");
  }

  visit(monitor: Monitor): void  {
     console.log("Displaying Monitor.");
  }
}

이와같이 동일한 메소드 이름과 다른 파라미터를 통해 메소드를 구성하는 방법을 오버로딩이라고 부릅니다.

JavaScript, TypeScript는 오버로딩 지원하지 않습니다

다음과 같이 대체하여 구현합니다.

class ComputerPartDisplayVisitor implements ComputerPartVisitor {
  visit(monitor: Computer | Mouse | Keyboard | Monitor): void {
    if (monitor instanceof Computer) {
      console.log("Displaying Computer.");
    } else if (monitor instanceof Mouse) {
      console.log("Displaying Mouse.");
    } else if (monitor instanceof Keyboard) {
      console.log("Displaying Keyboard.");
    } else if (monitor instanceof Monitor) {
      console.log("Displaying Monitor.");
    }
  }
}

let computer: ComputerPart = new Computer();
computer.accept(new ComputerPartDisplayVisitor());

/*
실행결과
Displaying Mouse.
Displaying Monitor.
Displaying Keyboard.
Displaying Computer.
*/

· State Pattern (상태패턴)

상태패턴은 상태에 따라 다른 동작을 해야하는 경우 상태 객체를 통해 행동함

상태에 따른 액션을 추가할 때 상태 객체를 추가하여 메인 객체가 해당 상태 객체를 가지고 있는다.

interface StateInterface {
  on(light: Light): void;
  off(light: Light): void;
}

class OnState implements StateInterface {
  stateName: string;

  constructor() {
    this.stateName = 'ON'
  }
  
  getInstance () { 
    return factory.ON
  }

  on (light) {
    light.setState(factory.ON.getInstance())
    console.log('... 동작하지 않음')
  }

  off (light) {
    light.setState(factory.OFF.getInstance())
    console.log('전원 off')
  }
}

class OffState implements StateInterface{
  stateName: string;
  
  constructor() {
    this.stateName = 'OFF'
  }
  
  getInstance () {
    return factory.OFF
  }

  on (light) {
    light.setState(factory.ON.getInstance())
    console.log('전원 on')
  }

  off (light) {
    light.setState(factory.OFF.getInstance())
    console.log('... 동작하지 않음')
  }
}

type State = OnState | OffState;

let factory = {
  ON: new OnState(),
  OFF: new OffState()
}

class Light {
  state: State;

  constructor () {
    this.state = factory.ON.getInstance()
  }

  showState() {
    console.log(`current state: ${this.state.stateName} \n`)
  }

  setState (state: State) {
    this.state = state
  }

  onButtonPress () {
    this.state.on(this)
  }

  offButtonPress () {
    this.state.off(this)
  }
}

let l = new Light()
l.showState()

l.onButtonPress()
l.showState()

l.offButtonPress()
l.showState()

l.offButtonPress()
l.showState()

l.onButtonPress()
l.showState()

l.onButtonPress()
l.showState()

l.onButtonPress()
l.showState()

current state: ON 

... 동작하지 않음
current state: ON 

전원 off
current state: OFF 

... 동작하지 않음
current state: OFF 

전원 on
current state: ON 

... 동작하지 않음
current state: ON 

... 동작하지 않음
current state: ON

· 9. Memento Pattern (메멘토 패턴)

메멘토 패턴은 객체의 상태를 이전으로 돌리기 위해 사용

class Memento {
  state: string = '';

  constructor(state: string){
    this.state = state;
  }

  getState(): string{
  return this.state;
  }	
}

class Originator {
  state: string;

  setState(state: string): void {
    this.state = state;
  }

  getState(): string {
    return this.state;
  }

  saveStateToMemento(): Memento {
    return new Memento(this.state);
  }

  getStateFromMemento(memento: Memento): void {
    this.state = memento.getState();
  }
}

// 상태 복원 객체
class CareTaker {
  mementos: Memento[] = [];

  constructor() { }
  
  add(state: Memento): void {
    this.mementos.push(state);
  }

  get(idx: number): Memento {
    return this.mementos[idx];
  }
}

const originator: Originator = new Originator();
const careTaker: CareTaker = new CareTaker();

originator.setState("상태 #1");
originator.setState("상태 #2");
careTaker.add(originator.saveStateToMemento());
originator.setState("상태 #3");
careTaker.add(originator.saveStateToMemento());
originator.setState("상태 #4");

console.log("현재상태: " + originator.getState());

originator.getStateFromMemento(careTaker.get(0));
console.log("저장한 0번째 상태: " + originator.getState());

originator.getStateFromMemento(careTaker.get(1));
console.log("저장한 1번째 상태: " + originator.getState());

/*
실행결과

현재상태: State #4
0번째 상태: State #2
1번째 상태: State #3
*/

· 10. Mediator Pattern (중재자 패턴)

중재자 패턴은 이벤트를 처리하는 시스템에서 복잡한 송, 수신자들의 관계를 중재자 객체를 통해 정리하는 패턴

복잡한 관계를 단순하게 정리하는 역할

interface ISource {
  setMediator(mediator: Mediator): void;
  eventOccured(event: String): void;
}
class TcpComm implements ISource {
  mediator: Mediator;

  setMediator(mediator: Mediator) { // 중재자 설정
    this.mediator = mediator;
  }

  eventOccured(event: String) { // 이벤트의 전달
    this.mediator.onEvent("TCP comm", event);
  }
}
class SystemSignal implements ISource {
  mediator: Mediator;

  setMediator(mediator: Mediator) { // 중재자 설정
    this.mediator = mediator;
  }

  eventOccured(event: String) { // 이벤트의 전달
    this.mediator.onEvent("System", event);
  }
}


interface IDestination {
  receiveEvent(from: String, event: String): void;
}
class Display implements IDestination {
  receiveEvent(from: String, event: String) {
    console.log("Display : from " + from + " event : " + event);
  }
}
class Log implements IDestination {
  receiveEvent(from: String, event: String) {
    console.log("Log : from " + from + " event : " + event);
  }
}

// 등록된 목적지에게 이벤트를 전달하는 역할수행
class Mediator {
  list: IDestination[] = [];

  addDestination(destination: IDestination) {
    this.list.push(destination);
  }

  onEvent(from: String, event: String) {
    this.list.forEach((item: IDestination) => {
      item.receiveEvent(from, event);
    })
  }
}

const mediator: Mediator = new Mediator();

const tcp: ISource = new TcpComm();
tcp.setMediator(mediator);

const system: ISource = new SystemSignal();
system.setMediator(mediator);

mediator.addDestination(new Display());
mediator.addDestination(new Log());

tcp.eventOccured("connected");
tcp.eventOccured("disconnected");

system.eventOccured("Process Killed PID: 1932")

/*
실행결과

Display : from TCP comm event : connected
Log : from TCP comm event : connected
Display : from TCP comm event : disconnected
Log : from TCP comm event : disconnected
Display : from System event : Process Killed PID: 1932
Log : from System event : Process Killed PID: 1932
*/

일부 내용은 해당 자료를 참고했으며, 여기서 제공한 코드를 es6로 변환했습니다.

https://dev.to/jainrahul/a-comprehensive-guide-to-javascript-design-patterns-2h7d?fbclid=IwAR2BZK2rHLeOyL6OdACy_tnkvwY89HfN8nAftL0l7L0vIoNXBNFQgfxn7RM

A Comprehensive Guide To JavaScript Design Patterns

Design Pattern is a widely acknowledged concept in the software engineering industry in terms of the...

dev.to

샘플코드는 따로 깃허브로 제공하지 않습니다.

[암호화] 인코딩, 디코딩, 해시, 암호화, 복호화

멍개. — Sun, 28 Aug 2022 15:52:03 +0900

언제부턴가 인코딩, 해시, 암호화를 혼용하여 사용하는 나 자신을 발견하게 되었다...

우선 분류부터 해야한다.

● 인코딩 / 디코딩

인코딩 디코딩은 문자열을 바이트 코드로 바꾸는것을 의미합니다. 대표적으로 base64, url 인코딩이 있습니다. 디코딩은 바이트 코드를 다시 문자열로 복구하는 것을 의미합니다.

인/디코딩 대표적인 방식으로는 base64와 url 인코딩이 있습니다.

인코딩의 목적은 서로 다른 시스템간 동일한 포맷으로 데이터를 주고받기 위해 사용합니다. 인코딩은 암호화와 완전히 다른 목적을 가집니다.

· base64

base64는 64진법을 의미합니다. Base64는 주어진 문자를 아스키 코드로 변환한 후 2진수로 변환합니다. 그리고 6비트씩 잘라서 나온 값을 base64표를 참고하여 변환한 결과가 base64인코딩 결과입니다.

출처: 나무위키

Base64 인코딩 결과를 Text content로 돌아가는 과정을 디코딩이라고 합니다.

console.log(btoa('Man')) // base64 인코딩
// TWFu

console.log(atob('TWFu')) // base64 디코딩
// Man

base64는 단순히 텍스트 뿐 아니라 이미지 데이터를 표현하는 방식으로도 사용합니다.

data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAAkCAYAAABIdFAMAAAA....

· url 인코딩

url 인코딩은 네트워크 상에서 아스키코드만 해석할 수 있는 환경에서 한글 또는 특수문자 같은 것들을 위해 사용합니다.

헬로우 WORLD

여기엔 아스키코드로 해석이 안되는 4개의 캐릭터가 있습니다. '헬', '로', '우' 그리고 마지막으로 공백입니다.

해당 텍스트를 url 인코딩하면 다음과 같은 결과를 얻습니다.

%ED%97%AC%EB%A1%9C%EC%9A%B0+WORLD

자바스크립트에서는 URL 인코딩을 위해 인터페이스를 제공합니다.

▶ encodeURI()

const url = 'http://www.naver.com/멍개'
console.log(encodeURI(url))

// http://www.naver.com/%EB%A9%8D%EA%B0%9C

encodeURI()는 uri 표현에 사용하는 특수문자인 /, :, ., +, = 는 인코딩하지 않습니다.

decodeURI('http://www.naver.com/%EB%A9%8D%EA%B0%9C')

// http://www.naver.com/멍개

▶ encodeURIComponent()

const url = 'http://www.naver.com/멍개'
console.log(encodeURIComponent(url))

// http%3A%2F%2Fwww.naver.com%2F%EB%A9%8D%EA%B0%9C

encodeURIComponent는 /, :, +, =와 같이 URI에 표현되는 특수문자도 인코딩합니다.

decodeURIComponent('http%3A%2F%2Fwww.naver.com%2F%EB%A9%8D%EA%B0%9C')

// http://www.naver.com/멍개

● 암호화 / 복호화

암호화는 무결성과 기밀성을 유지하기 위해 사용합니다. 암호화는 크게 단방향과 양방향이 존재합니다.

여기서 단방향은 암호화만 되는것을 의미하며 복호화까지 되는것을 양방향이라고 합니다.

· 복호화가 불가능한 단방향 암호화 - 해시

단방향 암호화의 대표적인 방식이 해시입니다. 해시의 특징은 입력 데이터의 크기와 상관없이 항상 같은 크기의 결과를 얻습니다.

단방향 암호화인 해시를 사용하는 대표적인 예가 블록체인과 JWT 유효성 검사입니다.

출처: https://namu.wiki/w/%ED%95%B4%EC%8B%9C

nodejs에선 crypto를 이용하여 해시 연산이 가능합니다.

const crypto = require('crypto');

const createPW = pw => crypto.createHash('sha512').update(pw).digest('hex')
console.log(createPW('멍개'))

createHash는 단방향(해시) 알고리즘을 전달합니다,.

update는 암호화할 문자열을 전달합니다.(plain text)

digest는 출력 결과를 표시할 형식을 지정합니다.(hex는 16진수 형태로 표시하는 것을 의미합니다.)

7a28c5137e44d896da0f9d3afa2ecd02f9e65a3a54835b4d5605f75362878fa48a23c54c6e60a71b1f355ad33ccbf76dd700582212499ba61c504399e8665b81

이렇게 나온 결과는 복호화가 불가능합니다.

또한 해시는 해시 충돌이 발생할 수 있어 pdkdf2(Password-based key derivation function version 2) 방식인 더 복잡한 방법을 사용합니다.

const salt = 'slat 소금 짜당~';
console.log('salt', salt);
crypto.pbkdf2('plain text멍개멍개멍개', salt, 1203947, 64, 'sha512', (err, key) => {
  console.log('password', key.toString('base64'));
});

// salt slat 소금 짜당~
// password DC7aX5dtmva6TXdjRsdlrtJbE3E1cUzwLgo0OOl0tAwQHFIWgp3Wgzp+zQKEuymItiiQ1w+CilyWrygkHxHSaA==

salt는 plain text를 암호화 할 때 사용하는 키입니다. 해당 키는 절대 외부에 노출하면 안됩니다.

· 복호화가 가능한 양방향 암호화

양방향 암호화는 key를 이용하여 암호화를 합니다. 그리고 key를 이용하여 복호화를 수행합니다.

이때 암호화와 복호화 모두 동일한 키를 사용하는 것을 대칭키(비밀키) 방식이라고 합니다. 암호화와 복호화에 다른 키를 이용하는 것을 비대칭키(공개키) 방식이라고 합니다.

▶ 대칭키(비밀키) 방식

대칭키에 대표적인 알고리즘은 2가지로 나뉩니다.

블록 암호 알고리즘: AES, DES, 3DES, SEED, ARIA

스트림 암호 알고리즘: RC-4

const crypto = require('crypto');

const aesKey = crypto.randomBytes(32) // 32 byte
const iv = Buffer.from([0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00]); 

const aes256Encrypt = (text)  => {
  let cipher = crypto.createCipheriv('aes-256-cbc', aesKey, iv);
  let result = cipher.update(text, 'utf8', 'base64');
  result += cipher.final('base64');
  return result
}

const aes256Decrypt = (cryptogram) =>  {   
  const decipher = crypto.createDecipheriv('aes-256-cbc', aesKey, iv);
  let result = decipher.update(cryptogram, 'base64', 'utf8');
  result += decipher.final('utf8');
  return result
}

let plainTextData = "멍개입니다"
let encryptStr = aes256Encrypt(plainTextData)
let decryptStr = aes256Decrypt(encryptStr)

console.log("  encrypt : ", encryptStr)
console.log("  decrypt : ", decryptStr)

//  encrypt :  fXkEV6VmssEaWQddJo+uUA==
//  decrypt :  멍개입니다

▶ 비 대칭키(공개키) 방식

비 대칭키 방식은 공개키 방식이라고도 합니다. 비 대칭키 방식은 암/복호화를 위해 한 쌍의 개인키-공개키를 생성합니다. 이때 개인키로 암호화 된 결과는 공개키로만 복호화가 가능하며, 반대도 성립합니다. 단, 공개키로 암호화된 결과는 공개키로 복호화가 불가능합니다.

비대칭키는 두 가지 경우가 있습니다. 개인키로 암호화 하는 경우, 공개키로 암호화 하는 경우

비대칭키 알고리즘은 크게 두 가지로 나뉩니다.

인수분해: RSA

이산대수: DSA

1. 개인키로 암호화 하는 경우 - 전자서명

A 유저는 네트워크를 통해 데이터를 전송합니다. 이때 해당 데이터가 A가 전송하게 맞는지를 어떻게 증명할까요? 이때 사용하는 방식이 전자서명 입니다.

A 유저는 우선 공개키-개인키를 생성합니다. 그리고 개인키로 전송하고자 하는 데이터를 암호화 합니다. 이때 개인키는 절대 노출하면 안됩니다. 그리고 공개키는 외부에 공개를 하여 목적지로 전송합니다. 목적지는 해당 데이터를 전달 받으면 공개된 A 유저의 공개키를 기반으로 복호화 합니다. 정상적으로 복호화가 되었다면 전달받은 데이터가 A 유저가 보낸것을 증명하는 것이 됩니다.

이때 만약 해커 H가 A 유저의 개인키가 아닌 다른 개인키를 이용하여 A 유저가 보낸것처럼 위장을 해도 목적지에서는 A 유저의 공개키를 기반으로 복호화를 시도하지만 정상적으로 복호화가 되지 않기 때문에 A 유저가 보낸 데이터가 아닌것으로 간주합니다.

대표적인 방법이 공인인증서입니다.

2. 공개키로 암호화 하는 경우 - 인증

공개키로 암호화 하는 경우는 다른 사용자가 개인키와 공개키를 가지고 있는 A 유저에게 데이터를 전송할 때 악의적인 유저가 해당 데이터를 감청하더라도 해석할 수 없게 하는 방법입니다.

다른 유저가 A에게 데이터를 전송할 때 A가 공개한 공개키를 기반으로 암호화 하여 A에게 전송합니다. 이때 해커 H가 해당 데이터를 감청하더라도 A가 가지고 있는 개인키가 없으면 해당 데이터를 복호화하여 볼 수 없습니다.

즉, 해당 방식은 감청이 되더라도 원본 데이터를 볼 수 없습니다.

공개키를 암호화 하여 감청이 되더라도 원본 데이터가 유출되는 것을 방지하기 위해 SSL, TLS에서 사용하는 방법입니다.

const crypto = require("crypto");

const RSA_PRIVATE_KEY = "-----BEGIN RSA PRIVATE KEY-----\nMIICXAIBAAKBgQC41wsMRbC4M4zkWYPI85WwYttEgbLQmIiHD4g6Kjz43h0+3rgt\n8m6IJtolraHpIus+izEx03kpYgJiTLAdruQBDqXTgTyIafZpLaZxH8kYVTomfjJL\nzqTbxuHz1uLqqOaeLzvKiKbCbbCaKWolgCQOCUu+rj/qdftchEVq/LcCcwIDAQAB\nAoGAbIo6fpZd04zR6zV1YYdIGy+xumS+8Cbh5Q2F3UH4U9t6KPT4CmMV7PWDnCR9\nsz1CDpQF61BXEanv5HFL6eJNGCH20z4SctlnMZCw0CJvel4tue4mVmAORctXfcy8\nA9gXpP2D3+tWInSRjZqDZt95ca6N5htlf99a7dcebh7xQkECQQDl/KChwiHw4nBk\nGuDlRp1G7TdP5chBDccdS0655957ZJCROcrjglfJobaGNFsjhoEyWPMl+Ywbt6IZ\n1FV7Z0FbAkEAzb8rVjhuiUurkf9boO2gq1EBMhNULJJHZOB50dpXiD8LvzWcBzvm\nYPppsMYUNS35ItaqXpvQLYswyIA3Seq2yQJAPen7qHBlyL58+UYPI0oWTyDPUjAO\n8AxwfR9n6z5Ts65ICQCg8QyG654gUBLKMk8ketRdaOy8Xj3aYs+5z4XlnwJABlxE\nkLPJ5wCp2yeTw5PVBbbJXKzwSzhycJHn8i7XyeR5Dn4vxqF5a8ISBl75PPOg4gzU\n03vpoZ7N8UTVcLmK0QJBAN4B3D/iBTce6Q5q3Apza8jzMS5ZZjh4Y8/A9K6IiQ54\nkul2tfIVywHVFoxJzGm4JMkHSf7yoVjsjEDpQvKMnIk=\n-----END RSA PRIVATE KEY-----"
const RSA_PUBLIC_KEY = "-----BEGIN PUBLIC KEY-----\nMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC41wsMRbC4M4zkWYPI85WwYttE\ngbLQmIiHD4g6Kjz43h0+3rgt8m6IJtolraHpIus+izEx03kpYgJiTLAdruQBDqXT\ngTyIafZpLaZxH8kYVTomfjJLzqTbxuHz1uLqqOaeLzvKiKbCbbCaKWolgCQOCUu+\nrj/qdftchEVq/LcCcwIDAQAB\n-----END PUBLIC KEY-----"

const privateKey = RSA_PRIVATE_KEY.replace(/\\n/g, '\n');
const publicKey = RSA_PUBLIC_KEY.replace(/\\n/g, '\n');

// public key로 암호화
encodeRSAByPublic = (text) => {
  const buffer = Buffer.from(text);
  const encrypted = crypto.publicEncrypt(publicKey, buffer);
  return encrypted.toString("hex");
}

// private key로 암호화
encodeRSAByPrivate = (text) => {
  const buffer = Buffer.from(text);
  const encrypted = crypto.privateEncrypt(privateKey, buffer);
  return encrypted.toString("hex");
}

// private key로 복호화
decodeRSAByPrivate = (text) => {
  const buffer = Buffer.from(text, "hex");
  const decrypted = crypto.privateDecrypt(privateKey, buffer);
  return decrypted.toString("utf8");
}

// public key로 복호화
decodeRSAByPublic = (text) => {
  const buffer = Buffer.from(text, "hex");
  const decrypted = crypto.publicDecrypt(publicKey, buffer);
  return decrypted.toString("utf8");
}

const text = '멍개멍개';

console.log('encrypt: public, decript: private')
const encrypted0 = encodeRSAByPublic(text); 
console.log(`encrypted: ${encrypted0}`);

const decrypted0 = decodeRSAByPrivate(encrypted0); 
console.log(`decrypted: ${decrypted0}`);

console.log('==========================')

console.log('encrypt: private, decript: public')
const encrypted1 = encodeRSAByPrivate(text); 
console.log(`encrypted: ${encrypted1}`);

const decrypted1 = decodeRSAByPublic(encrypted1); 
console.log(`decrypted: ${decrypted1}`);
encrypt: public, decript: private
encrypted: 56f23d4a961151759052e633f0a8762f0c918cee5e6ff8bd335e5043c9fb2048caf3f514bfeb2afba76bad2c9955b80e63188ceb68bc9e543aad155ee0997d98f7023ba6953db4093864bfe37975eec63080e77a4ba92a0a1cde5e096a8e14f1f43e62c92ec8fbfb2768f7520085f5637b3a40cb4b9b9f7f643fc1cfde150aff
decrypted: 멍개멍개

==========================

encrypt: private, decript: public
encrypted: 0d5784fa8fe822ef8de6ae484b1797abef6a855100672b31cb22e065f95a313ff26cee581a22f3edb0abccd34e9a3e2229ba083c6b4d6a00bcbfdbe7f6fcfb2dc832ef83a5fb6a14d0e0f4137eed872e88866b26ff44f805c75c86ae5d27a8092dffee1baac12cf40dea777206c8a1e43393e078cb3ba477753b314d620cac03
decrypted: 멍개멍개

암호화: 공개키, 복호화: 개인키

암호화: 개인키, 복호화: 공개키

2가지 방식 모두 정상적으로 암/복호화를 진행합니다. 만약 암호화와 복호화를 같은키를 이용한다면?

onsole.log('encrypt: public, decript: public')
const encrypted2 = encodeRSAByPublic(text); 
console.log(`encrypted: ${encrypted2}`);

const decrypted2 = decodeRSAByPublic(encrypted2); 
console.log(`decrypted: ${decrypted2}`);

node:internal/crypto/cipher:79
    return method(data, format, type, passphrase, buffer, padding, oaepHash,
           ^

Error: error:0407008A:rsa routines:RSA_padding_check_PKCS1_type_1:invalid padding
    at Object.publicDecrypt (node:internal/crypto/cipher:79:12)
    at decodeRSAByPublic (/Users/jeongtaepark/Desktop/encrypt/rsa.js:33:28)
    at Object.<anonymous> (/Users/jeongtaepark/Desktop/encrypt/rsa.js:61:20)
    at Module._compile (node:internal/modules/cjs/loader:1101:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1153:10)
    at Module.load (node:internal/modules/cjs/loader:981:32)
    at Function.Module._load (node:internal/modules/cjs/loader:822:12)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12)
    at node:internal/main/run_main_module:17:47 {
  opensslErrorStack: [
    'error:04067072:rsa routines:rsa_ossl_public_decrypt:padding check failed'
  ],
  library: 'rsa routines',
  function: 'RSA_padding_check_PKCS1_type_1',
  reason: 'invalid padding',
  code: 'ERR_OSSL_RSA_INVALID_PADDING'
}

에러가 발생합니다.

공개키 - 개인키는 openssl을 이용하여 생성할 수 있습니다.

$ openssl genrsa -out private.key 2048

$ openssl rsa -in private.key -out public.key -pubout

비대칭키 알고리즘은 대칭키 알고리즘보다 더 많은 연산을 하기 때문에 대칭키보다 연산 결과가 느립니다.

[네트워크] TCP 핸드쉐이크... UDP가 그렇게 빨라?

멍개. — Sun, 28 Aug 2022 15:40:02 +0900

안녕하세요. 멍개입니다.

지난시간까지 TCP 기반의 대표적인 프로토콜 HTTP, WebSocket, Socket.io, RPC를 알아보았습니다. 여기서 3-way handshake, 4-way handshake라는 용어를 사용했는데 이번 시간에는 TCP에서 데이터 전송 전/후로 커넥션을 생성하고 끊는 과정인 핸드쉐이크를 설명합니다.

TCP 프로토콜은 크게 3가지 흐름이 존재합니다.

연결 생성 (Connection establishment)
데이터 전송 (Data transfer)
연결 해제 Connection termination)

본론으로 들어가기 전에 한 가지 질문을 하겠습니다. TCP가 UDP보다 느린 이유가 무엇일까요?

● TCP 패킷구조

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Source Port          |       Destination Port        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Sequence Number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Acknowledgment Number                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Data |           |U|A|P|R|S|F|                               |
   | Offset| Reserved  |R|C|S|S|Y|I|            Window             |
   |       |           |G|K|H|T|N|N|                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Checksum            |         Urgent Pointer        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Options                    |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             data                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

(출처: https://datatracker.ietf.org/doc/html/rfc793)

해당 모습은 아마 웹소켓에서 데이터 프레임을 인코딩하고 디코딩할 때 비슷한 형태의 모습을 보았을겁니다.

3-way handshake와 4-way handshake를 할때 사용하는 프레임은 Seq(Sequence Number), Ack(Acknowledgment), SYN, ACK, FIN 입니다. 핸드쉐이크에서 사용하진 않지만 Window는 본인이 사용가능한 버퍼 사이즈를 의미합니다. 여기서 Ack는 숫자를 의미하는 프레임이고, ACK는 플래그를 의미하는 프레임입니다. 이 둘을 혼용하면 안됩니다.

· Source port (16비트)

출발지 포트번호

· Destination port (16비트)

목적지 포트번호

· Seq(Sequence Number) (32비트)

Seq는 데이터를 나눠서 전송할 때 해당 패킷이 몇 번째에 해당하는지 의미하는 패킷입니다. 이를 이해하기 위해선 MSS(Max Segment Size)를 이해해야 합니다. 간단하게 설명하면 1000Mb 파일이 존재합니다. 그런데 MSS가 100MB라면 TCP는 해당 데이터를 전송하기 위해 10개의 패킷을 만듭니다. 그리고 각각의 패킷에 Seq를 순차적으로 부여하여 전송하게 됩니다. 수신자는 해당 패킷을 네트워크 상태에 따라 순서대로 받지 못할 수 있지만 Seq는 이를 순서대로 조립할 수 있도록 도와줍니다. 여기서 한 데이터를 여러 패킷으로 쪼갠것을 세그먼트라고 합니다. Seq는 해당 패킷이 몇 번째 세그먼트인지 알려줍니다.

세그먼트는 최대 크기는 MTU로 정해집니다. MTU는 네트워크 정보에서 확인할 수 있습니다.

최초의 패킷 전송인지 이어서 데이터를 전송하고 있는건지에 대한 SYN에 따라 Seq를 처리하는 방법이 달라집니다.

SYN는 0 또는 1이 될 수 있습니다. 0 또는 1에 따라 Seq가 의미하는 바가 조금은 다릅니다.

· Ack(Acknowledgment) (32비트)

세그먼트를 전달 받으면 해당 패킷은 다음번째 패킷의 Seq를 포함하고 있습니다. 다음번째 세그먼트의 Seq를 의미하는 것이 Ack 입니다. 다음번째 세그먼트의 Seq이기 때문에 Ack가 설정되는 로직은 Seq + 1 입니다.

· ACK (1비트)

Ack는 한 쪽에서 데이터를 보냈을 때 수신자가 Ack 패킷을 전송하여 해당 패킷을 받았다고 알려주는 것을 의미합니다.

· SYN (1비트)

동기화 시퀀스 번호. 최초의 패킷에만 SYN 비트가 1로 활성화 되어야합니다

· FIN (1비트)

마지막 패킷을 의미합니다.

● 연결생성을 위한 3-way handshake

3-way handshake란 두 응용프로그램간 데이터 전송을 위해 연결하는 과정을 의미합니다. 3-way인 이유는 연결을 위해 패킷을 3번 주고받기 때문입니다.

출처: https://datatracker.ietf.org/doc/html/rfc793

RFC에 정의된 TCP의 전체 상태 이미지인데... 보기 힘들죠? 저도 보기 힘듭니다. 해당 이미지에서 연결된 부분만 정리하면 다음과 같습니다.

출처: https://datatracker.ietf.org/doc/html/rfc793

· 첫 번째 패킷

클라이언트는 연결 시도를 위해 서버에게 SYN를 1로 활성화 한 패킷을 전송합니다. 해당 패킷은 Seq만 셋팅됩니다.

SYN를 1로 설정한 패킷을 보낸 클라이언트의 네트워크 상태는 SYN/ACK 패킷을 기다리며 SYN_SENT 상태가 됩니다. 이때 서버는 LISTEN 상태여야 합니다.

· 두 번째 패킷

SYN 패킷이 1로 활성화 된 패킷을 받은 서버는 연결 요청 수락을 위해 ACK와 SYN가 1로 활성화 된 패킷을 만들어 클라이언트에게 전달합니다. 해당 패킷은 서버가 초기화 한 Seq를 새로 설정하며 클라이언트가 보낸 Seq를 +1하여 Ack로 설정합니다.

이때 서버는 클라이언트가 ACK가 활성화된 패킷을 전송하기를 기다리며 SYN_RECEIVED 상태가 됩니다.

· 세 번째 패킷

서버에게 ACK와 SYN가 활성화 된 패킷을 받은 클라이언트는 서버에게 해당 패킷을 잘 받았다고 ACK만 활성화 된 패킷을 전달합니다. 해당 패킷은 서버가 만든 Ack를 Seq로 설정하며 서버가 만든 Seq를 +1하여 Ack에 포함합니다.

이때 패킷은 SYN는 0으로 비활성화 상태가 됩니다. 이때 클라이언트는 서버와 데이터를 주고받을 수 있는 상태인 ESTABLISHED가 되며 서버도 클라이언트에게 ACK 패킷을 전달받으면 ESTABLISHED 상태가 됩니다.

패킷에서 Seq와 Ack가 만들어지는 과정은 Seq는 Ack에 의해 생성합니다. Seq는 Ack에 의해 생성되는데 SYN이 1이되는 최초의 패킷의 경우 ACK가 없으므로 Seq를 랜덤한 값으로 생성합니다. Ack는 Seq + 1하여 설정합니다. 만약 Seq가 없다면? Ack는 비워집니다. 3-way handshake 첫 번째 패킷에서 Seq가 랜덤하게 만들어지고 Ack는 비워진 상태로 서버에게 패킷을 전달합니다. 서버는 해당 패킷을 받고 Seq를 +1하여 Ack에 설정하고 전달받은 패킷에 Ack이 없기 때문에 서버는 랜덤한 값으로 Seq를 설정합니다. 두 번째 패킷을 받은 클라이언트는 전달받은 패킷의 Ack를 Seq로 설정하고 Seq +1한 값을 Ack로 만들어 패킷을 만듭니다.

· TCP 서버구현

const net = require('net');

const server = net.createServer(socket => {
  console.log(`cnnected address: ${socket.address().address}`);
})

server.listen(5000, function() {
  console.log(`listen on port 5000`)
})

· TCP 클라이언트 구현

const net = require('net');

// 서버 5000번 포트로 접속 
// 3 way-handshake
const socket = net.connect({ port: 5000 });

· 패킷 캡처

서버를 실행한 후 와이어샤크 프로그램을 실행합니다. 그리고 클라이언트를 실행하면 다음과 같이 패킷이 캡처됩니다.

$ sudo tcpdump -i lo0 -vvv -nn port 5000                                                                                                                              
tcpdump: listening on lo0, link-type NULL (BSD loopback), capture size 262144 bytes

23:01:55.214330 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 64, bad cksum 0 (->3cb6)!)
    127.0.0.1.60370 > 127.0.0.1.5000: Flags [S], cksum 0xfe34 (incorrect -> 0x620a), seq 2313595154, win 65535, options [mss 16344,nop,wscale 6,nop,nop,TS val 1648035900 ecr 0,sackOK,eol], length 0

23:01:55.214390 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 64, bad cksum 0 (->3cb6)!)
    127.0.0.1.5000 > 127.0.0.1.60370: Flags [S.], cksum 0xfe34 (incorrect -> 0x2243), seq 679172691, ack 2313595155, win 65535, options [mss 16344,nop,wscale 6,nop,nop,TS val 273853589 ecr 1648035900,sackOK,eol], length 0

23:01:55.214401 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52, bad cksum 0 (->3cc2)!)
    127.0.0.1.60370 > 127.0.0.1.5000: Flags [.], cksum 0xfe28 (incorrect -> 0x834c), seq 1, ack 1, win 6379, options [nop,nop,TS val 1648035900 ecr 273853589], length 0

23:01:55.214409 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52, bad cksum 0 (->3cc2)!)
    127.0.0.1.5000 > 127.0.0.1.60370: Flags [.], cksum 0xfe28 (incorrect -> 0x834c), seq 1, ack 1, win 6379, options [nop,nop,TS val 273853589 ecr 1648035900], length 0

엥 3개의 패킷이 아니라 4개의 패킷이 캡처되는데요? 마지막 패킷은 핸드쉐이킹이 완료된 후 버퍼의 크기를 확인하기 위한 통신입니다.

패킷을 하나씩 살펴보면 다음과 같습니다.

첫 번째 패킷
 127.0.0.1.60370 > 127.0.0.1.5000: Flags [S], seq 2313595154

클라이언트가 서버로 전달한 패킷입니다. Flags는 S인데 이것은 SYN가 활성화 되었다는 의미입니다. seq는 클라이언트가 랜덤하게 만든값 입니다. 앗! 근데 와이어샤크에선 아마 0이라고 뜰건데 이건 계산의 편의를 위해 offset을 별도로 가지고 있고 Seq를 0으로 표기한겁니다.

두 번째 패킷
 127.0.0.1.5000 > 127.0.0.1.60370: Flags [S.], seq 679172691, ack 2313595155

두 번째 패킷을 살펴보면 Flags에 S.이라고 되어있는데 .은 ACK을 의미합니다. 첫 번째 패킷에 ack(Ack)가 없으므로 서버가 랜던하게 만든값입니다. ack는 seq +1한 값입니다.

세 번재 패킷
 127.0.0.1.5000 > 127.0.0.1.60370: Flags [.], seq 1, ack 1

tcpdump의 세번째 패킷의 seq라 ack는 좀 신기하게 1, 1로 표시합니다. (tcpdump가 신기하게 3-way handshake 이후엔 seq랑 ack를 와이어샤크처럼 보기 편하라고 알아서 계산해서 표기합니다)

와이어샤크에서의 각 패킷을 살펴보면 다음과 같습니다. 아 참고로 tcpdump랑 서로 다른 요청일때 캡쳐했기 때문에 seq랑 ack가 서로 맞진 않습니다.

첫 번째 패킷

seq: 116187442 (랜덤하게 만든 값)

두 번째 패킷

seq: 46286935 (랜덤하게 만든 값)
ack: 116187443(첫 번째 패킷의 seq인 116187442에서 + 1한 값)

세 번째 패킷

seq: 116187443(두 번째 패킷의 ack)
ack: 46286936(en 번째 패킷의 seq인 46286935에서 + 1한 값)

와이어샤크에선 예상대로 seq와 ack이 잘 뜨는 모습을 볼 수 있습니다.

● 연결 해제를 위한 4-way handshake

4-way handshake란 두 응용프로그램간 연결을 끊는 과정을 의미합니다. 4-way인 이유는 연결을 끊기위해 패킷을 4번 주고받기 때문입니다.

4 way-handshake는 패킷 방향이 중요합니다. 연결을 끊기를 요청하면 수신자측은 2개의 패킷은 전달합니다. 그 이유가 전송중인 데이터가 있다면 해당 전송을 마무리하기 위해서입니다.

· 첫 번째 패킷

연결 끊기를 희망하는 쪽에서 FIN을 1로 설정된 패킷을 전송합니다. 패킷을 전송한 대상은 FIN_WAIT_1 상태가 됩니다.

· 두 번째 패킷

연결끊기 요청(클라이언트) 패킷을 받은 대상은 해당 패킷의 Seq와 Ack를 기준으로 Seq와 Ack를 설정한 후 ACK 플래그를 활성화하여 연결끊기 요청 패킷을 받았다는 사실을 알려줍니다. 연결끊기를 희망하는 대상은 해당 패킷을 받으면 FIN_WAIT_2 상태가 됩니다. 그리고 플래그의 FIN이 활성화 된 패킷을 받기를 기다립니다. 혹시 서버가 이전에 전송중인 데이터가 있다면 마저 전송을 합니다.

일반적으로 연결은 클라이언트가 끊기를 요청합니다.

· 세 번째 패킷

서버가 더이상 클라이언트에 보낼 데이터가 없다면 플래그의 FIN, ACK을 설정한 패킷을 클라이언트에 보낸 후 LAST_ACK 상태가 됩니다.

두 번째 패킷과 세 번째 패킷은 하나의 패킷을 대상으로 만들어진 패킷이기 때문에 seq와 ack가 동일합니다.

· 네 번째 패킷

서버로부터 FIN 패킷을 받은 클라이언트는 TIME_WAIT 상태로 바뀝니다. FIN을 받았다는 패킷을 보내기 위해 ACK이 활성화 된 패킷을 서버로 보냅니다. 클라이언트로 부터 ACK을 받은 서버는 해당 소켓이 CLOSED 상태가 됩니다.

이후 시간이 지나면 클라이언트도 소켓을 CLOSED로 변경합니다.

· TCP 서버 구현

const net = require('net');

const server = net.createServer(socket => {
  console.log(`cnnected address: ${socket.address().address}`);
})

server.listen(5000, function() {
  console.log(`listen on port 5000`)
})

서버는 앞에서 구현한것과 동일합니다.

· TCP 클라이언트 구현

const net = require('net');

// 서버 5000번 포트로 접속 
// 3 way-handshake
const socket = net.connect({ port: 5000 });

socket.on('connect', function () {
  console.log('connected to server!');
  setTimeout(() => {
    console.log('try disconnected');
    socket.end();
  }, 4000)
});

connect가 되면 4초후 socket.end()를 호출하여 4-way handshake를 발생시킵니다.

· 패킷캡처

(이번엔 tcpdump와 와이어샤크로 같이 캡처 했습니다....)

23:39:56.895863 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52, bad cksum 0 (->3cc2)!)
    127.0.0.1.60697 > 127.0.0.1.5000: Flags [F.], cksum 0xfe28 (incorrect -> 0x0d89), seq 1, ack 1, win 6379, options [nop,nop,TS val 1441315233 ecr 3308819552], length 0
23:39:56.895910 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52, bad cksum 0 (->3cc2)!)
    127.0.0.1.5000 > 127.0.0.1.60697: Flags [.], cksum 0xfe28 (incorrect -> 0xfdeb), seq 1, ack 2, win 6379, options [nop,nop,TS val 3308823549 ecr 1441315233], length 0
23:39:56.896161 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52, bad cksum 0 (->3cc2)!)
    127.0.0.1.5000 > 127.0.0.1.60697: Flags [F.], cksum 0xfe28 (incorrect -> 0xfdea), seq 1, ack 2, win 6379, options [nop,nop,TS val 3308823549 ecr 1441315233], length 0
23:39:56.896197 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52, bad cksum 0 (->3cc2)!)
    127.0.0.1.60697 > 127.0.0.1.5000: Flags [.], cksum 0xfe28 (incorrect -> 0xfdea), seq 2, ack 2, win 6379, options [nop,nop,TS val 1441315233 ecr 3308823549], length 0

각각의 패킷을 살펴보면 다음과 같습니다.

▶ 첫 번째 패킷

해당 패킷을 보낸 클라이언트는 FIN_WAIT_1 상태가 됩니다.

와이어샤크 캡처

첫 번째 패킷(TCP 덤프)
  127.0.0.1.60697 > 127.0.0.1.5000: Flags [F.], seq 1, ack 1

클라이언트가 서버에게 플래그 비트인 FIN과 ACK을 1로 설정한 후 seq와 ack을 포함하여 서버로 전송합니다.

▶ 두 번째 패킷

서버로 부터 두 번째 패킷을 받은 클라이언트는 TIME_WAIT 상태가 됩니다.

와이어샤크 캡처

두 번째 패킷(TCP 덤프)
  127.0.0.1.5000 > 127.0.0.1.60697: Flags [.] seq 1, ack 2

서버는 클라이언트에게 첫 번째 패킷을 기준으로 seq와 ack를 셋팅한 후 ACK 플래그를 활성화 하여 클라이언트에게 전달합니다.

▶ 세 번째 패킷

세 번째 패킷을 전달한 서버는 LAST_ACK 상태가 됩니다.

세 번째 패킷도 서버가 클라이언트에게 전달하는 과정입니다. 첫 번째 패킷을 받은 상태에서 두 번째 세 번째를 서버가 보내기 때문에 seq, ack는 동일합니다.

와이어샤크 캡처

세 번째 패킷(TCP 덤프)
  127.0.0.1.5000 > 127.0.0.1.60697: Flags [F.] seq 1, ack 2

▶ 네 번째 패킷

서버로부터 FIN 패킷을 받은 클라이언트는 TIME_WAIT 상태로 바뀝니다. 클라이언트로 부터 ACK을 받은 서버는 해당 소켓이 CLOSED 상태가 됩니다.

이후 시간이 지나면 클라이언트도 소켓을 CLOSED로 변경합니다.

와이어샤크 캡처

네 번째 패킷(TCP 덤프)
  127.0.0.1.60697 > 127.0.0.1.5000: Flags [.], seq 2, ack 2

● 데이터 전송

우리는 TCP 사용을 위해 8개의 패킷을 전송하여 사용하는 모습을 확인했습니다. 만약 데이터 전송을 한다면 클라이언트 또는 서버는 상대방에게 패킷을 전송합니다. 하지만 여기서 끝이 아니라 ACK 플래그를 활성화하여 해당 패킷을 잘 받았다고 알려줘야 합니다.

const net = require('net');

// 서버 5000번 포트로 접속 
// 3 way-handshake
const socket = net.connect({ port: 5000 });

socket.on('connect', function () {
  console.log('connected to server!');
  setInterval(() => {
    console.log('send data');
    socket.write('msg');
  }, 4000)
});

4000ms 마다 한 번씩 서버에게 데이터를 요청하는 코드를 실행 시킨 후 패킷 캡처를 시도해 보겠습니다.

ACK는 무언가 확인하는 플래그입니다. 잘 전송 받았다고 알립니다.

문득 그런생각이 들지 않나요? 그럼 UDP는? 안저런가??

· UDP 서버

const dgram = require('dgram');
const server = dgram.createSocket('udp4');
const port = 5000;
 
server.on('message', (message, info) => {
  console.log(`message: ${message.toString()}`);
  console.log(`from address: ${info.address} port: ${info.port}`);
});
 
server.on('listening', () => {
  const address = server.address();
  console.log(`listening ${address.address}:${address.port}`);
});
 
server.bind(port);

· UDP 클라이언트

const dgram = require('dgram');
const toHost = '0.0.0.0';
const toPort = 5000;
const client = dgram.createSocket('udp4');
 
const data = Buffer.from('mung');
 
client.send(data, toPort, toHost, (err) => {
  if (err) console.log(err);
  else console.log('ok');
  client.close();
});

· 패킷 캡처

와이어샤크 캡처

와이어샤크는 UDP.port로 UDP 통신만 필터합니다.

하나의 요청에 하나의 패킷만 생성되는 모습을 볼 수 있습니다.

와이어샤크나 tcpdump 모니터링을 활성화 하고 postman같은 클라이언트 프로그램 또는 http 요청 라이브러리로 요청하는 패킷을 확인해보세요 그럼 12개의 패킷이 캡처되는 모습을 확인할 수 있습니다.

왜 http/1.1에서 keep-alive 기능이 나왔는지 아시겠죠?

이번시간엔 TCP가 어떻게 연결을 하고 연결 해제를 하는지 알아보았습니다. 다음 시간엔 TCP의 핵심기능인 흐름제어, 오류제어, 연결제어를 알아보겠습니다.

[네트워크] 분산된 환경에서의 호출을 위한 RPC, JSON-RPC, gRPC

멍개. — Sun, 28 Aug 2022 15:31:27 +0900

이번 시간은 MSA(Micro Service Architecture)에서 많이 사용하는 프로토콜인 RPC에 대해서 다뤄보겠습니다.

혹시 HTTP를 제대로 이해하고 있지 않다면 다음글을 먼저 읽고 해당 강좌를 보는것을 권장합니다.

2022.08.28 - [컴퓨터 공학(Computer Science & Engineering))/네트워크] - [네트워크] TCP? HTTP? 그것이 알고싶다

[네트워크] TCP? HTTP? 그것이 알고싶다

TCP와 HTTP를 다뤄보도록 하겠습니다. 근데 사실 어렵지 않아요!!!! 이걸 어렵게 설명하니깐 어려운거지..... 어렵지 않은 이유를 알려드릴게요 사실 어려운 개념은 맞습니다. 왜냐고요? 우리 눈

meongae.tistory.com

● RPC란?

RPC는 Remote Procedure Call의 약자로 원격 프로시저(함수) 호출을 의미합니다. RPC는 프로세스간 통신을 위한 통신기법 입니다. RPC와 많이 비교하는 것 중 하나가 HTTP 기반의 REST 입니다.

RPC vs HTTP

Remote Procedure Call VS Hyper Text Transfer Protocol

HTTP의 주 목적은 문서의 교환입니다. 물론 지금은 문서보다 데이터를 주고받는 형태로 사용되고 있지만, 초기의 HTTP 목적은 HTML 문서를 주고받는 목적으로 설계되었습니다. 반면의 RPC는 무언가 연산을 수행하기 위한 목적으로 호출합니다.

HTTP 요청은 파일명이 a.html인 문서를 주세요

RPC는 a와 b의 값을 연산해주세요

HTTP는 method와 path로 구분하여 정의된 핸들러를 호출합니다.

RPC는 프로시저(함수)를 직접호출합니다. 호출하는 코드를 보면 이 정의 부분이 로컬에 있는지 원격에 있는지 구분이 안됩니다. 마치 로컬환경에 정의된 느낌을 받습니다. 이 부분이 RPC의 핵심입니다. RPC의 목적은 프로시저(함수)가 로컬에 있던 원격에 있던 신경쓰지 않습니다. 그리고 프로시저(함수)를 호출하기 때문에 호출하는 대상의 인터페이스가 매우 중요합니다. RPC에서 인터페이스는 매우 중요합니다. 우리가 calculator 함수를 호출할 때 함수 이름과 전달할 파라미터, 응답 데이터의 포맷을 알아야 정상적인 코딩이 가능해지는 것처럼 RPC도 이런 인터페이스가 매우 중요합니다. 오늘날의 RPC는 매우 발전된 형태로써 인터페이스 정의를 JSON과 proto buffer 형태로 정의하여 사용합니다.

{
  "jsonrpc": "2.0", 
  "method": "test", 
  "params": [1,2], 
  "id": null
}

syntax = "proto3";

package com.terry.proto;

message Person{
  string name = 1;
  int32 age=2;
  string email=3;
}

MSA에서 HTTP보다 RPC를 사용 하는 이유가 분산된 환경에서 정의된 서비스들을 마치 로컬에서 호출하는것처럼 사용할 수 있기 때문입니다. 그리고 JSON-RPC나 gRPC의 경우 인터페이스를 정의하기 때문에 해당 인터페이스만 가지고 있다면 호출하기가 편리하다는 장점을 가집니다. 물론 gRPC의 경우 HTTP/2.0을 사용하기 때문에 기존의 HTTP/1.1보다 더 많은 장점을 가지고 있기도 합니다. JSON-RPC는 말이 RPC이지 HTTP 통신과 큰 차이를 느끼긴 힘듭니다.

오늘날의 HTTP는 다양한 프로토콜의 기반이 되는 프로토콜이 되어가고 있습니다. 지난 시간에 배웠던 웹소켓, socket.io들도 HTTP 위에서 동작하는 프로토콜이며, 오늘 다룰 JSON-RPC와 gRPC도 HTTP 위에서 동작하는 프로토콜 입니다. JSON-RPC는 HTTP/1.1에서 동작하며 gRPC는 HTTP/2.0에서 동작합니다.

HTTP는 단순히 문서를 주고받는 규약이 아니라 프로세스간 통신을 위해 데이터를 주고받는 프로토콜로써 자리를 잡고 있습니다. HTTP를 이용하여 두 프로세스를 연결시킨 후 우리가 정의한 프로토콜을 기반으로 새롭게 동작을 정의합니다. 대표적으로 웹소켓은 HTTP 헤더의 Connection을 Upgrade로 정의함으로써 HTTP로 커넥션을 요청한 후 websocket 프로토콜로 업그레이드 하여 통신을 합니다.

RPC는 HTTP보다 먼저 나온 개념입니다. HTTP는 1995년에 0.9, 1996년에 1.0이 발표되었으며 1999년에 1.1이 발표되었습니다. 하지만 RPC는 1980년도에 등장하기 시작했습니다. RPC는 TCP/IP를 기반으로 통신을 하지만 IPC를 위해 Named Pipe를 이용하기도 합니다. Named Pipe는 프로세스간 통신하는 기법입니다.

· 함수와 프로시저

앞에서 함수와 프로시저라는 용어가 나왔습니다. 이후에도 함수와 프로시저 용어는 계속 쓰입니다. 이 둘은 호출해서 무언가를 실행한다는 공통점을 가집니다. 하지만 어떤 관점의 실행이냐에 따라 함수 또는 프로시저로 나뉩니다.

함수는 인풋값에 대해서 아웃풋 값이 발생하는 것을 의미합니다. 즉 리턴이 존재합니다.

프로시저는 행위에 집중 합니다. 예를들어 A를 수행하고 B를 수행하고 C를 수행하는 일련의 과정을 프로시저로 정의할 수 있습니다.

함수와 프로시저는 데이터베이스에서도 사용합니다. 데이터베이스의 함수와 프로시저에서도 함수는 반환값을 주지만 프로시저는 반환값을 정의할 수 없도록 되어있습니다. 프로시저에서 반환값이 필요할 땐 커서 객체를 넘겨서 처리합니다.(저도 함수랑 프로시저랑 별 차이점 없이 혼용에서 썼었는데 회사에서 DBA 하시는 분이 알려줬음 ㅋ)

· 아키텍처

RPC의 전체적인 모습은 다음과 같습니다.

출처: https://www.ibm.com/docs/en/aix/7.1?topic=call-rpc-model

RPC는 정의된 인터페이스에 따라 호출을 하면 Stub을 만든 후 통신 가능한 형태로 변환하여 통신을 시도합니다. 그리고 통신 결과를 호출자에게 전달해줍니다. 클라이언트와 서버 사이의 통신은 TCP를 이용하겠죠? TCP를 이용한다는 것은 포트를 이용한다는 의미입니다. JSON-RPC와 gRPC는 Network message를 TCP를 이용한 HTTP로 주고받습니다. RPC는 OSI계층에서 전송계층과 응용계층을 연결하는 역할을 합니다.

정리하면 RPC는 인터페이스에 맞춰서 호출을 하면 원격 프로시저 또는 로컬 프로시저가 위치하는 곳으로 호출합니다. 이때 HTTP를 이용하여 호출 대상이 존재하는 목적지 프로세스까지 전달합니다. 호출 대상은 호출한 프로시저 함수를 실행한 후 결과를 돌려줍니다. RPC를 위해 HTTP를 사용한다는 것은 HTTP로도 RPC 호출을 할 수 있다는 것을 의미합니다. RPC 코드를 구현해보면 HTTP 위에 RPC를 추가하여 사용하게 됩니다.

● RPC 구현

nodejs에선 rpc 라이브러리를 이용하여 RPC 서버를 구성하고 클라이언트를 만들 수 있습니다.

· 의존성 라이브러리 설치

$ npm install --save connect rpc

connect는 express와 유사한 HTTP 서버 경량 프레임워크입니다.

· 서버 구현

const app = require('connect')();
const path = require('path');
const RPC = require('rpc');

const url_path = '/api';
const api_path = path.join(__dirname, './rpc-handler');

const rpcServer = RPC(
  url_path, 
  api_path, 
  { cors: true }
)

app.use(rpcServer);

app.listen(5000)

url_path로 엔드포인트 정의를 합니다. rpc 라이브러리는 런타임 엔진이며 실행할 코드를 rpc-handler.js로 정의합니다.

module.exports = function( input, okay, fail ) {
  console.log(input)
	let action = input.action
	if( action == "ping" ) {
		okay( "pong" );
	} else {
		fail( "Unrecognized action: " + action );
	}
}

RPC 핸들러는 3개의 인자를 전달받습니다. 첫 번째 인자는 HTTP 요청시 body 데이터를 받으며 okay와 fail은 해당 RPC 요청의 성공응답과 실패응답을 담당하는 함수입니다.

· 클라이언트

RPC 서버를 구축했지만 앞에서도 언급했지만 HTTP 위에서 구현되어 있기 때문에 HTTP 요청을 보내도 됩니다.

서버에서 action이 ping일 경우 okay를 호출합니다. 만약 action: ping이 아닌 값을 요청하면 fail을 호출합니다.

하지만 이렇게 구현을 하게되면 RPC를 만든 의미가 없습니다.

· RPC 서버구현

앞에서 RPC를 구현하기 위해선 인터페이스 정의를 한다고 했습니다. 타입스크립트의 힘을 빌리면 언어수준에서 인터페이스 정의를 맡길 수 있습니다.

$ npm install --save @node-rpc express @types/express @types/node @ co-body axios

import { createServer, RPCFunctions } from "@node-rpc/server";
import { jsonDeserializer } from "@node-rpc/server/dist/deserializers/jsonDeserializer";
import { IncomingMessage, ServerResponse } from "http";
import express from 'express'

export interface IApi {
  add: (a: number, b: number) => number;
  subtract: (a: number, b: number) => number;
  toLocaleString: (num: number) => string;
}

interface IContext {
    lang: string;
}

const api: RPCFunctions<IApi, IContext> = {
    add: (a, b) => () => a + b,
    subtract: (a, b) => () => a - b,
    toLocaleString: num => context => num.toLocaleString(context.lang), 
};

const rpcServer = createServer({
    api,
    deserializer: jsonDeserializer,
});

async function main (req: IncomingMessage, res: ServerResponse) {
    const lang = req.headers["accept-language"]?.split(",")?.[0] || "en";

    const result = await rpcServer.handleAPIRequest(req, { lang });
    console.log(result);

    res.end(JSON.stringify(result));
};

const app = express()

app.post('/rpc', main)

app.listen(5000);

엔드포인트가 /json으로 들어올 때 RPC 런타임을 동작시킵니다.

다음 코드가 RPC 런타임을 생성하는 부분입니다.

const rpcServer = createServer({
    api,
    deserializer: jsonDeserializer,
});

다음 코드가 RPC 런타임을 HTTP 위에 바인딩 시키는 작업입니다. 바인딩 되는 path는 /rpc 입니다.

async function main (req: IncomingMessage, res: ServerResponse) {
    const lang = req.headers["accept-language"]?.split(",")?.[0] || "en";

    const result = await rpcServer.handleAPIRequest(req, { lang });
    console.log(result);

    res.end(JSON.stringify(result));
};

const app = express()

app.post('/rpc', main)

· RPC 클라이언트 구현

import { createFallbackClient } from "@node-rpc/client";
import { jsonSerializer } from "@node-rpc/client/dist/serializers/jsonSerializer";
import { axiosXHR } from "@node-rpc/client/dist/xhr/axios";

interface IApi {
  add: (a: number, b: number) => number;
  subtract: (a: number, b: number) => number;
  toLocaleString: (num: number) => string;
}

const api = createFallbackClient<IApi>({
    endpoint: "http://localhost:5000/rpc",
    serializer: jsonSerializer,
    xhr: axiosXHR,
});

async function main() {
  const response = await api.createRequest('subtract', 11, 4).call();
  
  switch (response.type) {
      case "fail": {
          console.log("error", response.code, response.error);
          break;
      }
      case "noResponse": {
          console.log("no response");
          break;
      }
      case "success": {
          console.log("success", response.code, response.data);
          break;
      }
  }
}

main()

다음 코드가 RPC 런타임을 만드는 부분입니다.

const api = createFallbackClient<IApi>({
    endpoint: "http://localhost:5000/rpc",
    serializer: jsonSerializer,
    xhr: axiosXHR,
});

xhr은 데이터 통신 시 사용할 라이브러리를 의미합니다.

자 이제 HTTP 프로토콜을 어떻게 활용하여 데이터를 주고 받는지 알아보겠습니다.

· TCP 서버로 요청

const net = require('net');

const server = net.createServer(socket => {
  console.log(`cnnected address: ${socket.address().address}`);
  socket.on('data', (data) => { 
    console.log('====== receive data======='); 
    console.log(data.toString());
    socket.write('test')
    console.log('====== receive data======='); 
  });
})

server.listen(5000, function() {
  console.log(`listen on port 5000`)
})

해당 서버로 앞에서 구현한 RPC 클라이언트가 요청을 해보겠습니다.

const response = await api.createRequest('subtract', 11, 4).call();

POST /rpc HTTP/1.1
Accept: application/json, text/plain, */*
Content-Type: application/json
Authorization: 
X-RPC-Procedure: subtract
User-Agent: axios/0.25.0
Content-Length: 6
Host: localhost:5000
Connection: close

[11,4]

프로시저(함수) 이름은 X-RPC-procedure로 포함합니다. 프로시저로 전달될 파라미터는 body 영역에 포함합니다.

· TCP 클라이언트로 응답

이번엔 반대로 앞에서 구현한 RPC 서버를 실행한 후 TCP에서 직접 해당 서버로 요청을 보내보겠습니다.

const net = require('net');

// 서버 5000번 포트로 접속 
// 3 way-handshake
const socket = net.connect({ port: 5000 });

socket.on('connect', function () {
  console.log('connected to server!');
  const msg = [
    'POST /rpc HTTP/1.1',
    'Accept: application/json, text/plain, */*',
    'Content-Type: application/json',
    'Authorization: ',
    'X-RPC-Procedure: subtract',
    'User-Agent: axios/0.25.0',
    'Content-Length: 6',
    'Host: localhost:5000',
    'Connection: close',
    '',
    '[11,4]',
  ].join('\r\n')
  socket.write(msg);
});

// 서버로부터 받은 데이터를 화면에 출력 
socket.on('data', function (chunk) {
  console.log('response')
  console.log(chunk.toString());
});

클라이언트를 실행하면 응답 결과를 확인할 수 있습니다.

connected to server!
response
HTTP/1.1 200 OK
X-Powered-By: Express
Date: Sat, 29 Jan 2022 01:39:45 GMT
Connection: close
Content-Length: 1

7

● JSON-RPC

rpc를 통해 원격에 존재하는 프로시저(함수)를 호출할 수 있습니다. 하지만 한가지 문제가 있습니다. javascript처럼 자체적으로 인터페이스를 제공하지 않는 언어라면? 인터페이스 정의를 할 수 없습니다. 그래서 JSON-RPC가 등장합니다.

앞의 아키텍처 이미지에서 Interface가 명시되어 있습니다. Interface를 IDL이라고 부릅니다. IDL은 Interface Definition Laguage의 약자이며 인터페이스 정의 언어라는 뜻 입니다. JSON-RPC는 IDL로 JSON을 사용합니다. 여기서 인터페이스란 요청을 위한 정해진 폼을 의미하며 JSON-RPC는 요청시 규격화된 JSON 포맷을 이용합니다. 해당 포맷은 jsonrpc 버전, 호출 메서드 이름, 메서드 파라미터, id를 가집니다.

{"jsonrpc": "2.0", "method": "test", "params": [1,2], "id": null},

· JSON-RPC 서버구축

nodejs에선 JSON-RPC를 위해 node-json-rpc를 제공합니다.

$ npm install --save node-json-rpc

const rpc = require('node-json-rpc');
 
const options = {
  port: 5000,
  host: '127.0.0.1',
  path: '/',
  strict: false
};
 
const serv = new rpc.Server(options);
 
serv.addMethod('test', function (params, callback) {
  let error, result;
  console.log(params)
  if (params.length === 2) {
    result = params[0] + params[1];
  } else if (params.length > 2) {
    result = params.reduce( (acc, val) => acc + val, 0);
  } else {
    error = { code: -32602, message: "Invalid params" };
  }
 
  callback(error, result);
});

serv.start(function (error) {
    if (error) throw error;
    else console.log('Server running ...');
});

JSON-RPC는 요청 시 프로시저 이름, 파라미터의 위치가 정의되어 있기 때문에 어플리케이션 단에서 프로시저 이름이 있는지 없는지 검사하지 않아도 됩니다.

module.exports = function( input, okay, fail ) {
  console.log(input)
	let action = input.action
	if( action == "ping" ) {
		okay( "pong" );
	} else {
		fail( "Unrecognized action: " + action );
	}
}

· json-rpc 클라이언트

const rpc = require('node-json-rpc');
 
const options = {
  port: 5000,
  host: '127.0.0.1',
  path: '/',
  strict: false
};
 
const client = new rpc.Client(options);
 
client.call(
  {"jsonrpc": "2.0", "method": "test", "params": [1,2], "id": null},
  (err, res) => {
    if (err) { console.log(err); }
    else { console.log(res); }
  }
);
 
client.call(
  {"method": "myMethod", "params": [1,2], "id": 2},
  (err, res) => {
    if (err) { console.log(err); }
    else { console.log(res); }
  }
);

클라이언트는 정해진 JSON 포맷에 맞추어 요청하면 됩니다.

이또한 마찬가지로 HTTP 위에서 동작하기 때문에 HTTP 요청으로도 정상적으로 동작합니다.

http 요청 도구인 curl을이용하여 요청도 가능합니다.

$ curl -d '{"jsonrpc": "2.0", "method": "test", "params": [1,2], "id": null}' 127.0.0.1:5080

· 요청/응답 패킷

TCP 서버와 클라이언트를 이용하여 HTTP 프로토콜을 어떻게 활용하는지 살펴보면 다음과 같습니다.

▶ 요청 패킷

const net = require('net');

const server = net.createServer(socket => {
  console.log(`cnnected address: ${socket.address().address}`);
  socket.on('data', (data) => { 
    console.log('====== receive data======='); 
    console.log(data.toString());
    socket.write('test')
    console.log('====== receive data======='); 
  });
})

server.listen(5000, function() {
  console.log(`listen on port 5000`)
})

TCP 서버를 실행한 후 앞에서 구현한 JSON-RPC client를 실행합니다.

POST / HTTP/1.1
host: 127.0.0.1:5000
content-type: application/json
content-length: 58
Connection: close

{"jsonrpc":"2.0","method":"test","params":[1,2],"id":null}

▶ 응답 패킷

const net = require('net');

// 서버 5000번 포트로 접속 
// 3 way-handshake
const socket = net.connect({ port: 5000 });

socket.on('connect', function () {
  console.log('connected to server!');
  const msg = [
    'POST / HTTP/1.1',
    'host: 127.0.0.1:5000',
    'content-type: application/json',
    'content-length: 58',
    'Connection: close',
    '',
    '{"jsonrpc":"2.0","method":"test","params":[1,2],"id":null}',
  ].join('\r\n')
  socket.write(msg);
});

// 서버로부터 받은 데이터를 화면에 출력 
socket.on('data', function (chunk) {
  console.log('response')
  console.log(chunk.toString());
});

JSON-RPC 서버를 실행한 후 TCP 클라이언트를 실행합니다.

HTTP/1.1 200 OK
Date: Sat, 29 Jan 2022 02:01:02 GMT
Connection: close
Content-Length: 12

{"result":3}

jayson을 이용하여도 JSON-RPC 구현이 가능합니다.

https://www.npmjs.com/package/jayson#example

jayson

JSON-RPC 1.0/2.0 compliant server and client. Latest version: 4.0.0, last published: 16 days ago. Start using jayson in your project by running `npm i jayson`. There are 329 other projects in the npm registry using jayson.

www.npmjs.com

● gRPC

gRPC는 IDL을 프로토 버퍼를 사용합니다.

syntax = "proto3";

package helloworld;

service Greeter {
  rpc SayHello (HelloRequest) returns (HelloReply) {};
}

message HelloRequest {
  required string name = 1;
}

message HelloReply {
  optional string message = 1;
}

그리고 HTTP/2.0을 사용합니다. gRPC는 RPC의 프레임워크라고 소개됩니다.

출처: https://www.grpc.io/

· gRPC 서버 구현

$ npm install --save @grpc/grpc-js @grpc/proto-loader

const grpc = require('@grpc/grpc-js');
const protoLoader = require('@grpc/proto-loader');
// Suggested options for similarity to existing grpc.load behavior
const packageDefinition = protoLoader.loadSync(
    './helloworld.proto',
    {keepCase: true,
     longs: String,
     enums: String,
     defaults: true,
     oneofs: true
    });
const protoDescriptor = grpc.loadPackageDefinition(packageDefinition);
// The protoDescriptor object has the full package hierarchy
const routes = protoDescriptor.helloworld;

function sayHello(call, callback) {
  console.log(call.request)
  callback(null, {message: 'Hello ' + call.request.name});
}

function main(port = '5000') {
  const server = new grpc.Server();
  server.addService(
    routes.Greeter.service, {
      sayHello
    }
  );
  server.bindAsync(`0.0.0.0:${port}`, grpc.ServerCredentials.createInsecure(), () => {
    server.start();
  });
}

module.exports = main;

gRPC는 정의된 proto 파일 경로를 명시해야 합니다. gRPC는 런타임은 proto 파일을 기반으로 gRPC 런타임을 동작합니다.

const packageDefinition = protoLoader.loadSync(
    './helloworld.proto',
    {keepCase: true,
     longs: String,
     enums: String,
     defaults: true,
     oneofs: true
    });

helloworld.proto는 다음과 같이 정의합니다.

syntax = "proto3";

package helloworld;

service Greeter {
  rpc SayHello (HelloRequest) returns (HelloReply) {};
}

message HelloRequest {
  required string name = 1;
}

message HelloReply {
  optional string message = 1;
}

· gRPC 클라이언트 구현

const path = require('path');
const grpc = require('@grpc/grpc-js');
const protoLoader = require('@grpc/proto-loader');

// Suggested options for similarity to existing grpc.load behavior
const packageDefinition = protoLoader.loadSync(
    path.join(__dirname, './helloworld.proto'),
    {keepCase: true,
     longs: String,
     enums: String,
     defaults: true,
     oneofs: true
    });
const protoDescriptor = grpc.loadPackageDefinition(packageDefinition);
// The protoDescriptor object has the full package hierarchy
const routes = protoDescriptor.helloworld;

function main() {
  var client = new routes.Greeter('localhost:5000',
                                       grpc.credentials.createInsecure());
  client.sayHello({name: 'you'}, function(err, response) {
    console.log('Greeting:', response.message);
  });
}

main()

클라이언트도 마찬가지로 정의된 proto를 기반으로 gRPC 런타임을 구성합니다.

· 요청패킷

역시나 TCP를 이용하여 요청/응답 패킷이 어떻게 되는지 확인해보도록 하겠습니다.

▶ 요청패킷

const net = require('net');

const server = net.createServer(socket => {
  console.log(`cnnected address: ${socket.address().address}`);
  socket.on('data', (data) => { 
    console.log('====== receive data start======='); 
    console.log(data.toString());
    socket.write('test')
    console.log('====== receive data end======='); 
  });
})

server.listen(5000, function() {
  console.log(`listen on port 5000`)
})

TCP 서버를 구성 후 gRPC 클라이언트를 실행합니다.

====== receive data start=======
PRI * HTTP/2.0

SM

u��br�A��$_�*Kc�h���A����       ��@���Ȱ�B֕�Q!���4��&O��
                                                      -I~��j�P�4��&O�z��&=LMed@te�M�5�b

you
====== receive data end=======
====== receive data start=======
PRI * HTTP/2.0

SM


====== receive data end=======

지난시간에 HTTP/2.0은 하나의 요청인 스트림을 여러 메시지로 분해하여 전송한다고 했습니다. 또한 HTTP/2.0은 암호화(SSL, TSL) 되어 통신을 합니다. TCP 수준에서는 암호화 된 내용을 풀 수 없습니다. 왜냐하면 TCP의 상위레이어에서 암호화를 진행하기 때문에 상위 레이어에서 암호화를 해독할 수 있습니다. 만약 해당 수준에서 암호화가 가능하면 보안상 엄청난 이슈가 발생하게 됩니다.

HTTP/2.0이 HOLB를 해결하기 위해 하나의 요청 스트림을 여러 메시지로 쪼개어 전송된다는 사실을 확인했습니다.

지금까지 TCP부터 HTTP, WebSocket, Socket.io, RPC(RPC, JSON-RPC, gRPC)까지 긴 여정을 오시느라 고생 많으셨습니다. 이 프로토콜은 현재 서비스를 개발할 때 항상 사용하는 프로토콜입니다. 물론 다른 프로토콜들도 있겠지만 4종류의 프로토콜만 잘 이해하고 있다면 다른 프로토콜을 큰 어려움 없이 개발하거나 이해할 수 있을겁니다.

다음번 강의는 TCP의 핸드쉐이크 강의로 찾아뵙겠습니다.

아 그리고 간혹 블로그 쓸 때 어떤식으로 쓰는지 궁금해하시는 분이 있어서 블로그 쓰기전에 어떤 절차로 쓰는지 간략히 소개를 하면...

간략하게 정리할 내용을 아주 간략하게만 작성합니다. 개념같은 것들은 구글링 하여 한 3페이정도까지 읽어 본다음에 혹시나 잘못 알고있는 정보나 개념은 없는지 살펴보고 작성을 합니다. 보통 포스팅 시간은 2~3시간정도 걸리는데 이번글은 4시간 정도 걸린것 같습니다 ㅋㅋ

[네트워크] TCP와 HTTP 레이어에서 직접 구현하는 웹소켓 그리고 socket.io

멍개. — Sun, 28 Aug 2022 15:20:28 +0900

지난번 글에서 TCP와 HTTP가 무엇인지 그리고 어떻게 동작하는지 살펴보았습니다.

2022.08.28 - [컴퓨터 공학(Computer Science & Engineering))/네트워크] - [네트워크] TCP? HTTP? 그것이 알고싶다

[네트워크] TCP? HTTP? 그것이 알고싶다

meongae.tistory.com

해당 내용에서 웹소켓은 HTTP 위에서 동작하는 프로토콜이라고 언급했습니다. 이번글에서는 웹소켓이 무엇인지 그리고 이를 직접 구현해보도록 하곘습니다. 웹소켓이 HTTP위에서 동작한다는 점은 TCP 위에서 동작한다는 것과 같은 말입니다.

특히 웹소켓은 로우레벨을 이해하면 좋은점이 있습니다. 만약 거래소 또는 채팅과같이 실시간 데이터를 빠르게 처리해야 한다면 웹소켓을 직접 옵티마이징(최적화) 작업을 해야하거나 직접 구현해야하는 상황이 있습니다.

멍선생의 네트워크 강의는 단순히 이론만 설명하지 실제 동작하는 코드를 작성하여 추상적인 개념을 최대한 구체화하는 것을 목표로 하고 있습니다.

● 웹소켓(websocket)

웹소켓은 HTTP를 기반으로 양방향 통신을 제공하는 프로토콜입니다.

양방향 통신이라는 것은 클라이언트의 요청없이 서버가 클라이언트에게 메시지를 전달할 수 있다는 것을 의미합니다. 즉, 클라이언트는 최신 데이터를 받기위해 주기적으로 서버에게 요청하는 polling, long polling, stream등을 사용하지 않아도 됩니다.

웹소켓의 개념은 아주 간단합니다. 앞에서 우리는 TCP로 연결된 두 응용프로그램은 TCP 연결을 끊지 않는다면 즉, socket.end()를 하지 않는다면 서버든 클라이언트든 데이터를 전달하고 전달 받을수 있다는 점을 인지하고 있을것입니다. 여기서 HTTP와 웹소켓의 차이점이 바로 이 부분입니다. 물론 HTTP/1.1은 일정시간 연결을 끊진 않지만 결국 끊기게 됩니다.

웹소켓은 HTTP 요청을 통해 socket.end를 하지 말라고 합니다. 그리고 자체적으로 정의한 데이터프레임 형식에 맞춰 데이터를 주고 받습니다. 이때 socket.end를 하지 말라고 하는 과정을 핸드쉐이크라고 하며 핸드쉐이크 시 HTTP 프로토콜을 이용합니다.

· 핸드쉐이킹 과정

▶ handshake request

{
  upgrade: 'websocket',
  connection: 'Upgrade',
  'sec-websocket-version': '13',
  'sec-websocket-key': 'VEX/yDINihxNvSKmffJF+Q==',
  host: 'localhost:5000'
}

▶ handshake response

101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: hsBlbuDTkk24srzEOTBUlZAlC2g=

· 핸드쉐이크 구현

웹소켓의 핸드쉐이크는 HTTP를 이용합니다.

▶ 클라이언트 -> 서버 연결요청

웹소켓 사용시 클라이언트는 서버에게 다음과 같이 HTTP를 요청합니다.

GET / HTTP/1.1
Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Key: xJayu5kgUOIvPXQQpegBXQ==
Sec-WebSocket-Version: 13
Host: localhost:5000

HTTP 헤더의 Connection이 Upgrade가 되면 HTTP 서버는 해당 요청이 HTTP라고 인식하지 않습니다. 즉, HTTP가 아닌 상위 수준의 프로토콜을 구현할 수 있게 됩니다. upgrade: websocket은 업그레이드 할 대상이 websocket이라는 의미입니다. 즉, 해당 요청은 Upgrade이므로 HTTP 프로토콜에서 커네션을 끊거나 유지하거나 관리를 더이상 하지 않습니다.

Sec-Websocket-Key와 Sec-WebSocket-Version은 웹소켓 프로토콜에서 사용하는 정보이며 버전은 13이 최신버전 입니다.

nodejs의 HTTP 라이브러리는 connection이 upgrade가 되었을 때 별도로 처리할 수 있도록 핸들링할 수 있도록 제공합니다.

const http = require("http");

const server = http.createServer(function (req, res) {});

server.on("upgrade", function (req, socket, head) {
  console.log(req.headers)
  socket.on("connect", function () { console.log("success"); });
  socket.on("data", function (data) {
    console.log(data);
    socket.write(data)
  });
});

server.listen(5000, function () {
  console.log("server is on 5000");
});

해당 서버를 실행 후 웹 브라우저로 http://localhost:5000을 접속해보세요 on('upgrade')가 반응하지 않습니다. 왜냐하면 브라우저는 HTTP 요청을 하기 때문에 Connection: upgrade가 아닙니다.

<!DOCTYPE html>
<html>
  <head></head>
  <body>
    <script>
      const ws = new WebSocket('ws://localhost:5000');
    </script>
  </body>
</html>

웹소켓 연결을 시도하는 브라우저를 실행해보세요 해당 서버에서 헤더를 출력할겁니다. 그리고 헤더 정보를 보면 다음과 같습니다.

{
  upgrade: 'websocket',
  connection: 'Upgrade',
  'sec-websocket-version': '13',
  'sec-websocket-key': 'VEX/yDINihxNvSKmffJF+Q==',
  host: 'localhost:5000'
}

서버에서 별도의 데이터를 주고있지 않기 때문에 요청 헤더만 존재하고 응답 헤더는 보이지 않습니다.

websocket 라이브러리를 활용하여 해당 서버에 접속해보겠습니다.

const WebSocketClient = require('websocket').client;
const client = new WebSocketClient();

client.connect('ws://localhost:5000/');

마찬가지로 서버는 반응합니다. 그렇다면 우리가 직접 net 모듈을 통해 TCP 수준에서 요청을 해본다면?

const net = require('net');

// 서버 5000번 포트로 접속 
// TCP level: 3 way-handshake
const socket = net.connect({ port: 5000 });

socket.on('connect', function () {
  console.log('connected to server!');
  
  const msg = [
    'GET / HTTP/1.1\r\n',
    'Connection: Upgrade\r\n',
    'Upgrade: websocket\r\n',
    'Sec-WebSocket-Version: 13\r\n',
    'Sec-WebSocket-Key: s+92vaV9BEsiNRk0rVmKDA==\r\n',
    'Host: localhost:5000\r\n',
    '\r\n'
  ].join('')

  // HTTP level: 2 way-handshake
  socket.write(msg);
});

해당 클라이언트 프로그램을 실행하면 서버가 반응합니다. 지금까지 HTTP 프로토콜의 Connection: Upgrade를 알아보았습니다.

▶ 서버 -> 클라이언트 연결수락

앞에서 Connection: Upgrade, Upgrade: websocket,을 기반으로 Sec-WebSocket-Version과 Sec-WebSocket-Key를 핸드쉐이크를 위해 서버에게 전송했습니다. 서버는 Sec-WebSocket-Key를 이용하여 Sec-WebSocket-Accept를 만듭니다.

101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: hsBlbuDTkk24srzEOTBUlZAlC2g=

Sec-WebsSocket-Accept는 클라이언트가 전달한 Sec-WebSocket-Key와 258EAFA5-E914-47DA-95CA-C5AB0DC85B11를 하나의 문자열로 만듭니다. 그리고 sha1로 해싱한 후 base64로 인코딩한 결과가 Sec-WebSocket-Accept입니다. 그리고 이때 중요한 점은 상태 코드를 101로 해야합니다.

이번의 서버는 http가 아닌 net 모듈을 이용하여 구축을 해보겠습니다. 이왕 로우한 영역으로 내려온거 화끈하게 내려가보겠습니다.

const net = require('net');
const crypto = require('crypto');

function handshakeMsg(msg) {
  const websocketKey = msg.split('\n').find(item => item.includes('Sec-WebSocket-Key'));
  const secWebsocketAccept = websocketKey.split(': ')[1].replace('\n', '').replace('\r', '');
  const salt = '258EAFA5-E914-47DA-95CA-C5AB0DC85B11'

  // sha1 해싱된 결과 base64 인코딩
  const sha1 = crypto.createHash('sha1')
  const hashing = sha1.update(secWebsocketAccept + salt).digest('base64');
  
  return 'HTTP/1.1 101 Switching Protocols\r\n' +
         'Upgrade: websocket\r\n' +
         'Connection: Upgrade\r\n' +
         'Sec-WebSocket-Accept: ' + hashing + '\r\n' +
         '\r\n';
}

const server = net.createServer(socket => {
  console.log(`cnnected address: ${socket.address().address}`);
  socket.on('data', (data) => { 
    
    console.log('====== handshake start ===== ')
    console.log('request headers')
    console.log(data.toString());

    const msg = handshakeMsg(data.toString());
    console.log('response headers')
    console.log(msg)
    socket.write(msg)
    console.log('====== handshake end ===== ')
  
  });
})

server.listen(5000, function() {
  console.log(`listen on port 5000`)
})

handshakeMsg 함수는 클라이언트가 전달한 Connection: Upgrade, Upgrade: websocket, Sec-WebSocket-Version, Sec-WebSocket-Key 문자열 정보를 파라미터로 넘기면 Sec-WebSocket-Accept를 포함한 결과를 만들어 줍니다. 해당 정보를 클라이언트에게 전달하면 핸드쉐이크가 성공적으로 완료하며 HTTP의 역할은 종료합니다.

const WebSocketClient = require('websocket').client;

const client = new WebSocketClient();
client.connect('ws://localhost:5000');

client.on('connect', function(connection) {
    console.log('WebSocket Client Connected');
 });

on('connect')는 웹소켓 핸드쉐이크가 성공적으로 완료되었을 때 호출됩니다.

※ 주의사항

여기서 한 가지 해깔릴만한 부분을 알려드리겠습니다. 지금 우리는 2개의 라이브러리를 이용하여 클라이언트를 직접 구현해보고 있습니다. 바로 TCP 레이어인 net과 웹소켓 레이어인 websocket입니다.

const net = require('net');

// 서버 5000번 포트로 접속 
const socket = net.connect({ port: 5000 });

// TCP level: 3 way-handshake 완료시
socket.on('connect', function () {
  console.log('connected to server!');
})

const WebSocketClient = require('websocket').client;

const client = new WebSocketClient();
client.connect('ws://localhost:5000');

// HTTP level: 2 way-handshake 완료시
client.on('connect', function(connection) {
    console.log('WebSocket Client Connected');
})

코드의 형태가 유사하죠? 하지만 on('connect')가 호출되는 시점이 다릅니다 각 레이어마다 connect라고 인지하는 시점이 다르기 때문입니다. net에서의 on('connect')는 TCP 수준에서 발생하는 3 way-handshake입니다. 하지만 websocket은 HTTP로 Sec-WebSocket-Key와 Sec-WebSocket-Accept를 성공적으로 주고받았고 클라이언트가 101응답을 받았을 때 on('connect')를 호출합니다.

웹 브라우저에서도 우리가 만든 웹소켓 서버와 연결을 할 수 있는지 확인해보겠습니다.

HTTP 기반으로 핸드쉐이킹을 완료하여 웹소켓 연결이 되었습니다.

이렇게 연결한 두 프로그램은 웹소켓 데이터프레임을 이용하여 데이터를 주고받을 수 있습니다.

만약 http위에서 구현한다면 다음과 같이 구현할 수 있습니다. 사실상 코드가 거의 유사합니다.

const http = require("http");
const crypto = require("crypto");

function handshakeMsg(msg) {
  const secWebsocketAccept = msg;
  const salt = '258EAFA5-E914-47DA-95CA-C5AB0DC85B11'

  // sha1 해싱된 결과 base64 인코딩
  const sha1 = crypto.createHash('sha1')
  const hashing = sha1.update(secWebsocketAccept + salt).digest('base64');
  
  return 'HTTP/1.1 101 Switching Protocols\r\n' +
         'Upgrade: websocket\r\n' +
         'Connection: Upgrade\r\n' +
         'Sec-WebSocket-Accept: ' + hashing + '\r\n' +
         '\r\n';
}

const server = http.createServer(function (req, res) {});

server.on("upgrade", function (req, socket, head) {
  socket.write(headersReturn);
});

server.listen(5000, function () {
  console.log("server is on 5000");
});

· 데이터프레임

웹소켓은 다음과 같이 데이터 프레임 포맷을 맞춰야 합니다.

 0               1               2               3
 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-------+-+-------------+-------------------------------+
|F|R|R|R| opcode|M| Payload len |    Extended payload length    |
|I|S|S|S|  (4)  |A|     (7)     |             (16/64)           |
|N|V|V|V|       |S|             |   (if payload len==126/127)   |
| |1|2|3|       |K|             |                               |
+-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
 4               5               6               7
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
|     Extended payload length continued, if payload len == 127  |
+ - - - - - - - - - - - - - - - +-------------------------------+
 8               9               10              11
+ - - - - - - - - - - - - - - - +-------------------------------+
|                               |Masking-key, if MASK set to 1  |
+-------------------------------+-------------------------------+
 12              13              14              15
+-------------------------------+-------------------------------+
| Masking-key (continued)       |          Payload Data         |
+-------------------------------- - - - - - - - - - - - - - - - +
:                     Payload Data continued ...                :
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
|                     Payload Data continued ...                |
+---------------------------------------------------------------+

웹소켓의 데이터 프레임은 가변적입니다. 데이터가 가변되는 상황은 다음과 같습니다.

▶ 첫 번째 가변상황

서버 -> 클라이언트 데이터 전송
클라이언트 -> 서버 데이터 전송

이 둘은 동일한 데이터를 전송하더라도 데이터 프레임의 모양이 조금 다릅니다. 클라이언트에서 서버로 데이터를 전송할 땐 마스킹 작업을 합니다. 이를 위해 마스킹 활성비트 1로 활성화하며 마스킹 비트를 포함합니다. 이후 페이로드(실제 데이터)를 마시킹 비트와 XOR 연산 결과를 utf-8 인코딩합니다. 하지만 서버에서 클라이언트로 데이터를 전송할 땐 마스킹 처리를 하지 않습니다. 그렇기 때문에 마스킹 활성 비트는 0으로 설정되며 마스킹 비트는 존재하지 않고 페이로드는 utf-8로만 인코딩처리 합니다.

▶ 두 번째 가변상황

데이터 프레임은 페이로드(전달할 데이터)의 길이를 명시합니다. 하지만 데이터 크기에 따라 크기로 사용하는 프레임의 길이가 달라집니다. 기본적으로 페이로드 길이를 표현하기 위해 7비트를 사용하지만 페이로드 길이에 따라 최대 4바이트(32비트)까지 사용합니다. 만약 페이로드의 길이가 7비트보다 작다면 4바이트는 사용하지 않습니다.

데이터 프레임이 가변이 되는 2가지 상황을 알아보았습니다. 이제 데이터 프레임의 각 항목이 의미하는 것이 무엇인지 살펴보겠습니다.

▶ 데이터 프레임 분석

 0               1               2               3
 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-------+-+-------------+-------------------------------+
|F|R|R|R| opcode|M| Payload len |    Extended payload length    |
|I|S|S|S|  (4)  |A|     (7)     |             (16/64)           |
|N|V|V|V|       |S|             |   (if payload len==126/127)   |
| |1|2|3|       |K|             |                               |
+-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +

여기서 맨 윗줄은 바이트를 의미합니다. 그 디음 0~7은 비트를 의미합니다. 그다음 문자는 패킷의 역할입니다.

데이터프레임 4바이트는 FIN, RSV1, RSV2, RSV3, opce, MASK, payload len, Extended payload length를 포함합니다.

 4               5               6               7
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
|     Extended payload length continued, if payload len == 127  |
+ - - - - - - - - - - - - - - - +-------------------------------+
 8               9               
+ - - - - - - - - - - - - - - - +
|                               |
+-------------------------------+

Extended payload leng continued는 10번째 바이트인 9라고 적혀있는 부분까지 확장될 수 있습니다. Payload Len은 항상 존재하지만 Extended payload length는 있을수도 없을수도 있습니다.

FIN: 해당 데이터 프레임이 마지막임을 알립니다.

RSV1, RSV2, RSV3: 사용되지 않음, 추후 확장될 것을 대비하여 존재

opcode: opcode에 따라 데이터 형태가 text(0x1 항상 UTF-8입니다)/blob(0x2)인지 구분합니다.

MASK: 앞에서 가변 상황 첫번째에서 마스크 활성 비트입니다. 해당 비트가 1일 땐 마스킹 처리가 되어있음을 알립니다.

payload length: 페이로드 길이입니다. 해당 값이 126일 땐 2바이트(2~3)를 데이터 길이표현으로 추가적으로 사용하며, 127일 땐 6바이트를 추가적으로 사용합니다.

                                +-------------------------------+
                                 10              11
                                +-------------------------------+
                                |Masking-key, if MASK set to 1  |
+-------------------------------+-------------------------------+
 12              13              
+-------------------------------+
| Masking-key (continued)       |   
+--------------------------------

masking-key는 MASK가 1로 활성화되었을 때, 즉 클라이언트가 서버로 데이터 프레임을 전달할 때 Masking-key를 이용하여 페이로드를 마스킹처리 합니다.

14(15번째) 바이트 부터 페이로드 입니다.

                                +-------------------------------+
                                 14              15
                                +-------------------------------+
                                |          Payload Data         |
+-------------------------------- - - - - - - - - - - - - - - - +
:                     Payload Data continued ...                :
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
|                     Payload Data continued ...                |
+---------------------------------------------------------------+

여기서 중요한 점은 앞에서 payload length가 7비트 고정 8바이트가 가변이기 때문에 Masking-key와 Payload의 위치(offset)는 변할 수 있습니다. 그렇기 때문에 데이터프레임 인코딩/디코딩 시 이 부분을 적절히 신경써줘야 합니다.

Masking-key와 payload가 다음과 같을때 실제 페이로드는 다음과 같은 연산 작업을 진행하여 만들어 집니다.

Masking-Key: 00000001 00000002 00000003 00000004
payload data: hello world

h XOR 00000001 연산결과 utf8
e XOR 00000002 연산결과 utf8
l XOR 00000003 연산결과 utf8
l XOR 00000004 연산결과 utf8
o XOR 00000001 연산결과 utf8
띄어쓰기  XOR 00000002 연산결과 utf8
w  XOR 00000003 연산결과 utf8
o  XOR 00000004 연산결과 utf8
r  XOR 00000001 연산결과 utf8
l  XOR 00000002 연산결과 utf8
d  XOR 00000003 연산결과 utf8

· 데이터 프레임 디코딩 구현

앞서서 우리는 데이터 프레임이 가변적인 상황을 알아보았습니다. 여기선 클라이언트가 요청할 땐데이터의 길이가 7비트로 표현할 수 있는 126 이하의 데이터 사이즈만 다룹니다.

우리가 디코딩을 다루는 케이스는 클라이언트가 서버로 데이터를 전달하는 경우입니다. 이때 데이터 프레임은 마스크 활성비트가 1로 활성되었기 때문에 Masking-key로 payload를 xor 연산해야 합니다.

function decode(data) {
  let FIN = data[0] >> 7 == 1;
  let RSV1 = (data[0] >> 6 & 1) == 1;
  let RSV2 = (data[0] >> 5 & 1) == 1;
  let RSV3 = (data[0] >> 4 & 1) == 1;
  let OPCODE = data[0] & 0xf;

  console.log('FIN, RSV1, RSV2, RSV3, OPCODE', convertToBinary1(data[0]))
  console.log(FIN, RSV1, RSV2, RSV3, OPCODE)
  console.log()
  
  const IS_MASK = data[1] >> 7 == 1;
  const PAYLOAD_LENGTH = data[1] & 0x7f;

  console.log(`IS_MASK: ${IS_MASK}, PAYLOAD_LENGTH: ${PAYLOAD_LENGTH}`)

  const MASK = data.slice(2, 6);
  const payload = data.slice(8);
  console.log('mask', MASK)
  console.log('payload', payload)
   
  const buffer = Buffer.alloc(PAYLOAD_LENGTH); //  payload 저장용 버퍼생성

  for (let i = 0 ; i < PAYLOAD_LENGTH ; i++) {
    buffer[i] = data[6 + i] ^ MASK[i % 4]
  }

  return buffer.toString('utf-8')
}

클라이언트와 서버는 데이터 프레임을 바이너리를 처리하기 위해 버퍼로 관리합니다. 이 부분은 사용하는 언어 및 라이브러리에 따라 달라질겁니다. 여기서 프레임의 값을 좀 더 편하게 보기위해 2진형태로 변환하는 함수가 convertToBinary1입니다.

function convertToBinary1 (number) {
  let num = number;
  let binary = (num % 2).toString();
  for (; num > 1; ) {
      num = parseInt(num / 2);
      binary =  (num % 2) + (binary);
  }
  return binary;
}

  const IS_MASK = data[1] >> 7 == 1;
  const PAYLOAD_LENGTH = data[1] & 0x7f;

IS_MASK에 따라 xor 연산을 할지 말지 판단하며, PAYLOAD_LENGTH에 따라 추가적인 데이터 길이를 위해 필요한 부분이 있는지 달라집니다.

  const MASK = data.slice(2, 6);
  const payload = data.slice(8);

PAYLOAD_LENGTH에 따라 masking-key를 가져오는 부분과 payload를 가져오는 기준점이 달라집니다.

MASK가 활성되었기 때문에 xor 연산을 합니다.

  const buffer = Buffer.alloc(PAYLOAD_LENGTH); //  payload 저장용 버퍼생성
  for (let i = 0 ; i < PAYLOAD_LENGTH ; i++) {
    buffer[i] = data[6 + i] ^ MASK[i % 4]
  }

이렇게 말이죠 물론 xor 연산 결과를 buffer에 넣어줍니다. 버퍼의 사이즈는 미리 정해야 하기 때문에 페이로드 사이즈는 중요합니다. 물론 이를 별도의 버퍼공간을 만들어서 concat하는 방법도 있지만 이럴경우 성능이 떨어집니다.

아마 코드를 보면서 >>, &의 연산자가 많이 나오는것을 보실텐데... 이게 최적화를 위해 비트연산자를 활용한 사례입니다.... 이 부분은 최적화가 정말 중요한 문제라 최대한 비트연산자를 많이 사용합니다.

const net = require('net');
const crypto = require('crypto');

function handshakeMsg(msg) {
  const websocketKey = msg.split('\n').find(item => item.includes('Sec-WebSocket-Key'));
  const secWebsocketAccept = websocketKey.split(': ')[1].replace('\n', '').replace('\r', '');
  const salt = '258EAFA5-E914-47DA-95CA-C5AB0DC85B11'

  // sha1 해싱된 결과 base64 인코딩
  const sha1 = crypto.createHash('sha1')
  const hashing = sha1.update(secWebsocketAccept + salt).digest('base64');
  
  return 'HTTP/1.1 101 Switching Protocols\r\n' +
         'Upgrade: websocket\r\n' +
         'Connection: Upgrade\r\n' +
         'Sec-WebSocket-Accept: ' + hashing + '\r\n' +
         '\r\n';
}

function isHandshake(data) {
  return data.split('\n').length > 2;
}

function convertToBinary1 (number) {
  let num = number;
  let binary = (num % 2).toString();
  for (; num > 1; ) {
      num = parseInt(num / 2);
      binary =  (num % 2) + (binary);
  }
  return binary;
}

function decode(data) {
  let FIN = data[0] >> 7 == 1;
  let RSV1 = (data[0] >> 6 & 1) == 1;
  let RSV2 = (data[0] >> 5 & 1) == 1;
  let RSV3 = (data[0] >> 4 & 1) == 1;
  let OPCODE = data[0] & 0xf;

  console.log('FIN, RSV1, RSV2, RSV3, OPCODE', convertToBinary1(data[0]))
  console.log(FIN, RSV1, RSV2, RSV3, OPCODE)
  console.log()
  
  const IS_MASK = data[1] >> 7 == 1;
  const PAYLOAD_LENGTH = data[1] & 0x7f;

  console.log(`IS_MASK: ${IS_MASK}, PAYLOAD_LENGTH: ${PAYLOAD_LENGTH}`)

  const MASK = data.slice(2, 6);
  const payload = data.slice(8);
  console.log('mask', MASK)
  console.log('payload', payload)
   
  const buffer = Buffer.alloc(PAYLOAD_LENGTH); //  payload 저장용 버퍼생성

  for (let i = 0 ; i < PAYLOAD_LENGTH ; i++) {
    buffer[i] = data[6 + i] ^ MASK[i % 4]
  }

  return buffer.toString('utf-8')
}

const server = net.createServer(socket => {
  console.log(`cnnected address: ${socket.address().address}`);
  socket.on('data', (data) => { 
    
    if(isHandshake(data.toString())) {
      console.log('====== handshake start ===== ')
      console.log('request headers')
      console.log(data.toString());
  
      const msg = handshakeMsg(data.toString());
      console.log('response headers')
      console.log(msg)
      socket.write(msg)
      console.log('====== handshake end ===== ')
    } else {
      console.log('========= dataframe parse start =========')
      console.log(data)
      console.log('decode: ', decode(data));
      console.log('========= dataframe parse end =========')
    }
  });
})

// 클라이언트 -> 서버 마스킹 해야 함
// 서버 -> 클라이언트 마스킹 안해야 함
server.listen(5000, function() {
  console.log(`listen on port 5000`)
})

서버는 연결을 목적으로 하는 핸드쉐이크와 데이터 전달을 목적으로 하는 데이터 프레임의 목적을 구분하기 위해 isHandshake 함수를 이용하여 구분합니다. 연결목적인 경우 HTTP 헤더라 엔터가 존재하므로 엔터존재 유무로 구분하고 있습니다. 실제로는 이렇게 안합니다.

서버를 구동 후 간략하게 클라이언트를 실행하겠습니다.

const WebSocketClient = require('websocket').client;

const client = new WebSocketClient();
client.connect('ws://localhost:5000');

client.on('connect', function(connection) {
    console.log('WebSocket Client Connected');
    
    function sendNumber() {
        if (connection.connected) {
            const data0 = {a: 10};
            console.log('send data', data0)
            connection.send(JSON.stringify(data0))
            setTimeout(sendNumber, 3000);
        }
    }
    sendNumber();
});

연결이 성공적으로 되었으면 json 형태의 데이터를 문자열로 변환하여 3000ms마다 서버로 전송합니다.

<!DOCTYPE html>
<html>
  <head></head>
  <body>
    <script>
      const ws = new WebSocket('ws://localhost:5000');
      setInterval(() => {
        ws.send('hello world');
      }, 3000)
    </script>
  </body>
</html>

해당 브라우저를 실행하면 브라우저에서 우리가 구현한 서버로 인코딩 된 hello world를 전송합니다.

· 데이터 프레임 인코딩 구현

드디어 이번 여정의 마지막입니다. 우선 중요한 점! 서버에서 클라이언트로 요청할 땐 MASK 처리하지 않습니다. 그러므로 MASK 비트는 0이 됩니다. 그렇다면 Masking-Key는 존재하지 않습니다.

function encode(msg) {
  const RES_PAYLOAD_LENGTH = msg.length.toString(2).padStart(8, 0); // 2진수 변환

  const responseBuffer =  Buffer.concat([
    // FIN(1), RSV1(0), RSV2(0), RSV3(0), OPCODE(0001) 
    // 10000001 => 0x81
    Buffer.from('81'.toString(16), 'hex'),
    // mask + payload_length 서버 -> 클라이언트 시 mask는 0이므로 payload 길이만 가지고 만든다.
    Buffer.from(parseInt(RES_PAYLOAD_LENGTH, 2).toString(16).padStart(2, 0), 'hex'), 
    // 페이로드 메시지 인코딩(UTF-8)
    Buffer.from(msg)
  ])

  return responseBuffer;
}

우리가 원하는 패킷 모양을 만들어 줍니다. MASK는 이며, 해당 형태는 데이터의 길이가 126이하여야만 합니다. 이 이상이면 데이터 길이를 포함해야 하는 패킷을 더 추가해야하기 때문입니다.

이제 서버 기존에 클라이언트가 데이터를 보내면 서버는 '멍개는 잘 생겼다!!'라는 문구를 해당 클라이언트에게 2번 전송합니다.

만약 클라이언트가 서버로 보내는 데이터 프레임이라면 MASK는 1이여야 하며 Masking-Key가 추가되고 페이로드와 XOR 연산 후 UTF-8로 인코딩 되어야 합니다.

const net = require('net');
const crypto = require('crypto');

function handshakeMsg(msg) {
  const websocketKey = msg.split('\n').find(item => item.includes('Sec-WebSocket-Key'));
  const secWebsocketAccept = websocketKey.split(': ')[1].replace('\n', '').replace('\r', '');
  const salt = '258EAFA5-E914-47DA-95CA-C5AB0DC85B11'

  // sha1 해싱된 결과 base64 인코딩
  const sha1 = crypto.createHash('sha1')
  const hashing = sha1.update(secWebsocketAccept + salt).digest('base64');
  
  return 'HTTP/1.1 101 Switching Protocols\r\n' +
         'Upgrade: websocket\r\n' +
         'Connection: Upgrade\r\n' +
         'Sec-WebSocket-Accept: ' + hashing + '\r\n' +
         '\r\n';
}

function isHandshake(data) {
  return data.split('\n').length > 2;
}

function convertToBinary1 (number) {
  let num = number;
  let binary = (num % 2).toString();
  for (; num > 1; ) {
      num = parseInt(num / 2);
      binary =  (num % 2) + (binary);
  }
  return binary;
}

function decode(data) {
  let FIN = data[0] >> 7 == 1;
  let RSV1 = (data[0] >> 6 & 1) == 1;
  let RSV2 = (data[0] >> 5 & 1) == 1;
  let RSV3 = (data[0] >> 4 & 1) == 1;
  let OPCODE = data[0] & 0xf;

  console.log('FIN, RSV1, RSV2, RSV3, OPCODE', convertToBinary1(data[0]))
  console.log(FIN, RSV1, RSV2, RSV3, OPCODE)
  console.log()
  
  const IS_MASK = data[1] >> 7 == 1;
  const PAYLOAD_LENGTH = data[1] & 0x7f;

  console.log(`IS_MASK: ${IS_MASK}, PAYLOAD_LENGTH: ${PAYLOAD_LENGTH}`)

  const MASK = data.slice(2, 6);
  const payload = data.slice(8);
  console.log('mask', MASK)
  console.log('payload', payload)
   
  const buffer = Buffer.alloc(PAYLOAD_LENGTH); //  payload 저장용 버퍼생성

  for (let i = 0 ; i < PAYLOAD_LENGTH ; i++) {
    buffer[i] = data[6 + i] ^ MASK[i % 4]
  }

  return buffer.toString('utf-8')
}

function encode(msg) {
  const RES_PAYLOAD_LENGTH = msg.length.toString(2).padStart(8, 0); // 2진수 변환

  const responseBuffer =  Buffer.concat([
    // FIN(1), RSV1(0), RSV2(0), RSV3(0), OPCODE(0001) 
    // 10000001 => 0x81
    Buffer.from('81'.toString(16), 'hex'),
    // mask + payload_length 서버 -> 클라이언트 시 mask는 0이므로 payload 길이만 가지고 만든다.
    Buffer.from(parseInt(RES_PAYLOAD_LENGTH, 2).toString(16).padStart(2, 0), 'hex'), 
    // 페이로드 메시지 인코딩(UTF-8)
    Buffer.from(msg)
  ])

  return responseBuffer;
}

const server = net.createServer(socket => {
  console.log(`cnnected address: ${socket.address().address}`);
  socket.on('data', (data) => { 
    
    if(isHandshake(data.toString())) {
      console.log('====== handshake start ===== ')
      console.log('request headers')
      console.log(data.toString());
  
      const msg = handshakeMsg(data.toString());
      console.log('response headers')
      console.log(msg)
      socket.write(msg)
      console.log('====== handshake end ===== ')
    } else {
      console.log('========= dataframe parse start =========')
      console.log(data)
      console.log('decode: ', decode(data));
      const msgBuffer = encode('abcdefghijk');

      console.log('encode: ', msgBuffer);
      socket.write(msgBuffer)
      socket.write(msgBuffer)
      console.log('========= dataframe parse end =========')
    }
  });
})

// 클라이언트 -> 서버 마스킹 해야 함
// 서버 -> 클라이언트 마스킹 안해야 함
server.listen(5000, function() {
  console.log(`listen on port 5000`)
})

클라이언트가 한 번요청하면 서버는 2개의 데이터를 응답합니다.

<!DOCTYPE html>
<html>
  <head></head>
  <body>
    <script>
      const ws = new WebSocket('ws://localhost:5000');
      setInterval(() => {
        ws.send('hello world');
      }, 3000)

      ws.on('data', data => {
        console.log(data);
      })
    </script>
  </body>
</html>

3000ms마다 한 번씩 서버로 hello world데이터를 전달합니다.ws.on('data')는 서버가 전달한 데이터가 있을 때 콜백을 호출합니다.

websocket으로 구현한 클라이언트라면 다음과 같이 처리합니다.

const WebSocketClient = require('websocket').client;

const client = new WebSocketClient();
client.connect('ws://localhost:5000');

client.on('connect', function(connection) {
    console.log('WebSocket Client Connected');

    connection.on('message', function(message) {
        console.log(message)
        if (message.type === 'utf8') {
            console.log("Received: '" + message.utf8Data + "'");
        }
    });
    
    function sendNumber() {
        if (connection.connected) {
            const data0 = {a: 10};
            console.log('send data', data0)
            connection.send(JSON.stringify(data0))
            setTimeout(sendNumber, 1000);
        }
    }
    sendNumber();
});

on('message')를 이용하여 서버가 전달한 데이터를 받을 수 있습니다.

만약 http에서 웹소켓 서버를 구현했다면 TCP 보다 훨씬 깔끔합니다. TCP 입장에선 HTTP랑 websocket의 핸드쉐이크, 데이터프레임 모두 받기 때문에 이를 구분해야 합니다. 하지만 HTTP 위에선 핸드쉐이크가 끝났다면 HTTP 서버는 더이상 웹소켓 클라이언트의 요청을 직접 받지 않습니다.

const http = require("http");
const crypto = require("crypto");

function handshakeMsg(msg) {
  const secWebsocketAccept = msg;
  const salt = '258EAFA5-E914-47DA-95CA-C5AB0DC85B11'

  // sha1 해싱된 결과 base64 인코딩
  const sha1 = crypto.createHash('sha1')
  const hashing = sha1.update(secWebsocketAccept + salt).digest('base64');
  
  return 'HTTP/1.1 101 Switching Protocols\r\n' +
         'Upgrade: websocket\r\n' +
         'Connection: Upgrade\r\n' +
         'Sec-WebSocket-Accept: ' + hashing + '\r\n' +
         '\r\n';
}

// encode, decode, convertToBinary1 함수는 동일하게 사용가능

const server = http.createServer(function (req, res) {
  console.log('123')
});

server.on("upgrade", function (req, socket, head) {
  console.log(req.headers)
  let headersReturn = handshakeMsg(req.headers["sec-websocket-key"])
  socket.write(headersReturn);

  socket.on('data', (data) => {
    console.log('========= dataframe parse start =========')
    console.log(data)
    console.log('decode: ', decode(data));
    const msgBuffer = encode('abcdefghijk');

    console.log('encode: ', msgBuffer);
    socket.write(msgBuffer)
    socket.write(msgBuffer)
    console.log('========= dataframe parse end =========')
  })
});

server.listen(5000, function () {
  console.log("server is on 5000");
});

또한 핸드쉐이크 시 http 라이브러리는 json으로 파싱된 헤더를 사용할 수 있습니다.

HTTP 프로토콜이 아니라 웹소켓 데이터프레임 프로토콜에 맞춰서 통신하기 때문에 http로 동작중인 server.on은 동작하지 않고 socket이 데이터를 수신합니다.

만약 클라이언트를 TCP로 직접 구현했다면 서버에서 구현했던 데이터프레임 생성을 그대로 가져와야 하지만 가변 데이터 프레임 정책에 따라 인코딩 디코딩을 해야합니다.

const net = require('net');

// 서버 5000번 포트로 접속 
// TCP level: 3 way-handshake
const socket = net.connect({ port: 5000 });

let isHandshake = false;

socket.on('connect', function () {
  console.log('connected to server!');
  
  const msg = [
    'GET / HTTP/1.1\r\n',
    'Connection: Upgrade\r\n',
    'Upgrade: websocket\r\n',
    'Sec-WebSocket-Version: 13\r\n',
    'Sec-WebSocket-Key: s+92vaV9BEsiNRk0rVmKDA==\r\n',
    'Host: localhost:5000\r\n',
    '\r\n'
  ].join('')

  // HTTP level: 2 way-handshake
  socket.write(msg);

  setInterval(() => {
    if (isHandshake) { // handshake 되었을 때만 실행
      socket.write(); // TODO: 인코딩
    }
  }, 1000);
});

// 서버로부터 받은 데이터를 화면에 출력 
socket.on('data', function (data) {
  // TODO: 디코딩 필요
  // 핸드쉐이크 응답과 dataframe을 전달받음

  // 핸드쉐이크 응답을 전달받은 것에 따라 isHandshake를 true로 바꿔준다
  isHandshake = true; 
  console.log(data); 
});

// // 접속이 종료됬을때 메시지 출력 
// // 4 way-handshake
// socket.on('end', function () {
//   console.log('disconnected.');
// });

// // 에러가 발생할때 에러메시지 화면에 출력 
// socket.on('error', function (err) {
//   console.log(err);
// });

// // connection에서 timeout이 발생하면 메시지 출력 
// socket.on('timeout', function () {
//   console.log('connection timeout.');
// });

코드의 레이아웃은 대략 이런 모습이 됩니다.

지금까지 TCP와 HTTP 레이어에서 웹소켓을 구현해보았습니다.

● socketio

socketio는 websocket위에서 동작하는 프로토콜 입니다. 또한 socketio는 커넥션이 끊기면 재연결을 시도하거나 웹소켓을 지원하지 않는 환경에서는 polling과 같은 기술을 사용하여 웹소켓을 대체합니다. transports는 연결을 시도할 프로토콜을 명시합니다.

const { io } = require("socket.io-client");

const socket = io("ws://localhost:5000", {
  transports: ["websocket", "polling"],
});

socket.io-client 또는 socket.io의 CDN을 이용하면 socket.io를 사용할 수 있습니다. socket.io는 transports로 websocket, polling 등을 넣을 수 있습니다. transports에 명시한 순서대로 클라이언트는 연결을 시도합니다.

transports는 다음과 같은 종류를 포함할 수 있습니다.

websocket
flashsocket
htmlfile
xhr-polling
jsonp-polling
polling

(별의 별 방식이 다 있죠?)

▶ websocket으로 연결 시도시 헤더

GET /socket.io/?EIO=4&transport=websocket HTTP/1.1
Sec-WebSocket-Version: 13
Sec-WebSocket-Key: IogOLF9O3PcDxEVa1yCW7A==
Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits
Host: localhost:5000

socket.io는 sec-websocket-extensions을 포함합니다. sec-websocket-extensions은 클라이언트가 제공하는 확장 기능을 의미합니다.

▶ polling으로 연결 시도시 헤더

GET /socket.io/?EIO=4&transport=polling&t=NwOl9RS&b64=1 HTTP/1.1
User-Agent: node-XMLHttpRequest
Accept: */*
Host: localhost:5000
Connection: close

또한 socket.io는 웹소켓의 단점 중 하나인 서버와 클라이언트간 주고받는 메시지를 on('message') 하나의 이벤트로만 처리를 해야합니다. 하지만 서버와 클라이언트는 다양한 형태의 이벤트(즉 엔드포인트)를 구분하는데 이를 편하게 할 수 있도록 개선한 프로토콜이 socket.io입니다. 데이터를 보낼 때 emit('이벤트 명', 전달 할 데이터)를 호출하면 수신자 측에선 on('이벤트 명', 전달받은 데이터)로 데이터를 받을 수 있습니다. emit과 on은 서버와 클라이언트 구분없이 사용할 수 있습니다.

socket.io의 프로토콜은 다음과 같습니다. 해당 프로토콜은 Namespace(nsp), type, data, id가 포함된 json 구조의 포맷으로 만들어집니다. 확실히 점점 프로토콜의 모습도 발전하고 있는 모습이 보입니다.

https://github.com/socketio/socket.io-protocol

GitHub - socketio/socket.io-protocol: Socket.IO Protocol specification

Socket.IO Protocol specification. Contribute to socketio/socket.io-protocol development by creating an account on GitHub.

github.com

[네트워크] TCP? HTTP? 그것이 알고싶다

멍개. — Sun, 28 Aug 2022 15:07:26 +0900

TCP와 HTTP를 다뤄보도록 하겠습니다. 근데 사실 어렵지 않아요!!!! 이걸 어렵게 설명하니깐 어려운거지..... 어렵지 않은 이유를 알려드릴게요

사실 어려운 개념은 맞습니다. 왜냐고요? 우리 눈에 보이지 않으니깐요?

하지만 TCP 레이어 위에서 HTTP를 직접 구현하여 브라우저를 통해 구현한 HTTP를 사용하는 과정을 통해 진입장벽을 낮췄습니다?

TCP라고 하면 흔히 소켓 프로그래밍, TCP/IP, UDP를 많이 떠올릴것입니다. 전공자가 아니신가요? 모르셔도 됩니다.

● 배경지식

21세기의 우리는 다양한 프로토콜 기반으로 네트워크를 이용하여 데이터를 주고받습니다.

http, websocket, webrtc 등 이를 제대로 이해하기 위해 이들이 어떻게 구현되는지 알아볼건데 필요한 배경지식을 알아보겠습니다.

· OSI 7계층

첫 번재로 OSI 7계층입니다. 우리가 네트워크를 공부하면 첫 번째 포기하는 지점입니다.

아래 내용 안외워도 됩니다. 아 이렇구나 하고 그냥 빠르게 넘어가세요 왜냐하면 이를 좀 더 함축적으로 4계층으로 표현하기 때문입니다.

▶ 1층 - 물리계층

해당 계층은 통신 케이블을 통해 전달되는 계층입니다.

▶ 2층 - 데이터 링크 계층

mac address(맥 주소)를 이용하여 정보의 전달을 수행하는 계층입니다.

모뎀의 역할이 1, 2층을 의미합니다.

▶ 3층 - 네트워크 계층

IP를 이용하여 데이터를 목적지까지 전달하는 기능을 수행하는 계층입니다.

▶ 4층 - 전송계층

PORT를 이용하여 응용프로그램간 통신을 할 수 있도록 수행하는 계층입니다.

네트워크 계층은 컴퓨터를 찾는거라면 전송계층은 찾은 컴퓨터에서 동작하는 특정 응용프로그램을 의미합니다.

▶ 5층 - 세션계층

데이터가 통신하기 위한 논리적 연결하는 계층입니다.

▶ 6층 - 표현계층

대표적인 기능으로 주고 받는 데이터를 암호화 하는 계층입니다.

SSL, TLS등이 여기에 포함됩니다.

▶ 7층 - 응용계층

응용 서비스를 수행하는 서비스를 제공하는 계층입니다.

근데 7층은 너무 많죠? 이걸 좀 더 추상화 하여 기능적으로 4계층으로 줄여서 표현합니다. 해당 층이 머라고 설명이 되어있는데 이해가 잘 안될겁니다. 지극히 정상입니다. 아마 계층이라는 단어가 가장 어렵게 느껴질것입니다. 이 계층이라는 개념은 뒤에서 자세히 다뤄볼겁니다.

· OSI 4 계층

OSI 7계층을 좀 더 개발자 관점에서 묶은 레이어가 OSI 4 계층입니다. 해당 계층을 TCP/IP라고 표현합니다.

7층이 우측처럼 4층의 모양으로 됩니다. 자! 이제 여기서 한 가지 더 나아가 보겠습니다. 우리는 TCP와 HTTP를 알아본다고 했습니다.

▶ L1 - 네트워크 액세스(MAC Address)

실제로 데이터가 전송되는 과정을 담당하는 계층입니다. 모뎀을 통해 외부로 통신되는 그 과정을 관리하는 계층입니다.

▶ L2 - 인터넷 계층(IP)

L2는 모뎀 밖으로 떠나간 데이터가 목적지 컴퓨터를 찾아가기 위한 방법을 제공합니다.

여기서 데이터를 패킷 또는 프레임이라고 표현합니다.

▶ L3 - 전송계층(PORT)

L3는 모뎀밖으로 떠나간 패킷은 L2에 의해 목적지 컴퓨터에 잘 도착했습니다. 하지만 해당 패킷이 어떤 프로그램으로 가야할 지 결정해야 하는데 L3가 도착한 목적지에서 어떤 프로그램으로 갈지 결정합니다.

▶ L4 - 응용계층

L4는 프로그램에 도착한 패킷이 어떻게 처리될지 결정합니다.

앞의 이미지에서 L1, L2, 이런 녀석을 하나의 마을이라고 생각하겠습니다. 마을이 있으면 누가 있어야죠? 시민이죠 TCP, HTTP가 바로 각 마을에 서식하는 시민입니다.

OSI 4계층을 중심으로 TCP는 L3 마을에 HTTP는 L4 마을에 살고있습니다.

여기서 2가지 관점에서 레이어를 분석할 수 있습니다. 네트워크 엔지니어는 L1, L2 레이어를 관리합니다.

일반적으로 우리가 서버를 만든다는 것은 사실 L4의 더 상위 레이어를 의미하지만 최적화 작업을 위해 L3, L4까지 다룹니다. 엇 그럼 OSI의 4계층에서 L3, L4는 OSI 7계층에서 L4, L5, L6, L7을 다 알아야 하나요라는 생각이 들 수 있는데 앞에서 기능적으로 7계층을 4계층으로 묶었다고 했기 때문에 개발하는 관점에서 L5, L6, L7이 나뉘진 않습니다. 물론 아주아주아주아주 로우한 영역으로 들어가면 나뉘어 지겠지만..... 이런 경우는 아주아주아주 특수한 케이스이기 때문에 대부분 OSI 7계층의 L5, L6, L7는 OSI 4계층의 L4 하나의 계층처럼 생각해보 됩니다.

정리하면 아 그럼 개발하는 관점에서 OSI 4계층의 L3, L4만 공부하면 됩니다. 전체적으로 내용이 줄어들긴 했지만 이 둘의 개념이 아직까지 명확하지 않을겁니다.

● L3 - 전송계층(OSI 4계층의 3층)

L3는 PORT를 사용하여 컴퓨터로 들어온 패킷이 특정 응용프로그램으로 전달되도록 합니다. L3의 핵심은 실행된 응용프로그램을 PORT로 구분한다는 점입니다.

해당 계층의 가장 대표적인 프로토콜은 TCP와 UDP입니다. 여기서 우리는 TCP만 다뤄보겠습니다.

· TCP의 기초개념

해당 계층에서 TCP를 다룰때 2가지 어려운 개념이 등장합니다 바로 3 way-handshake와 4 way-handshake입니다. 이는 두 응용프로그램이 데이터 전달 전 커넥션하는 과정을 3 way-handshake라고 하며, 데이터 전달 후 커넥션을 끊는 과정을 4 way-handshake라고 합니다.

이 과정 때문에 TCP는 신뢰도 있는 데이터 전송을 보장합니다. 여기서 신뢰란 전송한 데이터가 반드시 목적지에 도착 한다는 것을 의미합니다. UDP는 별도로 다루지 않지만 UDP는 연결 전/후로 커넥션 과정을 거치지 않기 때문에 신뢰도가 적으며 대신 TCP보다 빠르게 데이터 전송을 할 수 있습니다.

TCP와 UDP를 구현하는 행위를 소켓 프로그래밍이라고 합니다.

· TCP 서버 구현해보기

nodejs에서 네이티브로 제공하는 net 모듈이 있습니다. net 모듈을 통해 TCP 서버및 클라이언트를 구현할 수 있습니다.

const net = require('net');

const server = net.createServer(socket => {
  console.log(`cnnected address: ${socket.address().address}`);
  socket.on('data', (data) => { 
    console.log(data.toString())
    socket.write('test')
    socket.end();
  });
})

server.listen(5000, function() {
  console.log(`listen on port 5000`)
})

해당 코드를 통해 TCP 서버를 실행합니다.

$ sudo lsof -i -P | grep :$PORT | grep node

:$PORT는 응용프로그램이 바인딩한 포트를 입력해줍니다. 여기서는 5000을 입력하면 됩니다.

만약 ubuntu 기반의 리눅스 환경이라면 netstat를 사용하면 됩니다.

$ netstat -a

$ netstat -antp

네트워크(TCP, UDP) 상태를 조회하면 5000번 포트의 프로세스 상태가 listen인 것을 확인할 수 있습니다. ubuntu라면 netstat로 확인 가능합니다.

server.listen을 통해 5000번 포트로 연결을 수행합니다. 사용자는 IP:PORT를 통해 해당 어플리케이션과 데이터를 주고 받을 수 있습니다.

net.createServer는 다른 응용프로그램이 연결을 요청하면 내부적으로 3 way-handshake 이후 연결된 세션 객체를 콜백으로 전달합니다. 해당 코드에선 세션 객체를 socket으로 사용합니다.

socket.on('data')는 클라이언트가 데이터를 전송할 때 발생하는 이벤트입니다. socket.write()는 데이터를 전달합니다.

socket.end()가 호출되면 4 way-handshake가 발생하고 커넥션이 끊어집니다.

· TCP 클라이언트 구현해보기

const net = require('net');

// 서버 5000번 포트로 접속 
// 3 way-handshake
const socket = net.connect({ port: 5000 });

net.connect를 통해 TCP 커넥션을 생성합니다. 이때 3 way-handshake가 발생하여 커넥션을 생성합니다.

서버가 실행된 상태에서 클라이언트 코드를 실행하면 서버에서 콘솔에 클라이언트 주소가 출력되는 모습을 확인할 수 있습니다.

const net = require('net');

// 서버 5000번 포트로 접속 
// 3 way-handshake
const socket = net.connect({ port: 5000 });

socket.on('connect', function () {
  console.log('connected to server!');
  setInterval(function () {
    socket.write('mung mung~~');
  }, 1000);
});

// 서버로부터 받은 데이터를 화면에 출력 
socket.on('data', function (chunk) {
  console.log('receive: ' + chunk);
});

// 접속이 종료됬을때 메시지 출력 
// 4 way-handshake
socket.on('end', function () {
  console.log('disconnected.');
});

// 에러가 발생할때 에러메시지 화면에 출력 
socket.on('error', function (err) {
  console.log(err);
});

// connection에서 timeout이 발생하면 메시지 출력 
socket.on('timeout', function () {
  console.log('connection timeout.');
});

만약 해당 코드를 실행하면 어떻게 될까요??

1. 클라이언트가 서버에게 mung mung~~ 전송

2. 서버가 클라이언트에게 메시지를 받으면 test를 다시 클라이언트로 전송

3. 서버는 메시지 전송 후 socket.end()로 4 way-handshake가 발생하여 커넥션이 끊김

4. 클라리언트는 1초 후 mung mung~을 전송하려고 시도

5. 커넥션이 끊겼기 때문에 에러발생

1초마다 끊어진 커넥션을 이용하여 메시지 전송을 계속 시도하기 때문에 에러가 발생합니다. 서버에서 socket.end가 실행되고 커넥션이 끊기면 클라이언트에서 이벤트를 등록한 socket.on('end')가 실행된 모습을 확인할 수 있습니다.

· 4 way-handshake 발생하지 않고 데이터 지속적으로 주고받기

만약 한 번 만들어진 커넥션을 클라이언트가 1초마다 메시지를 전송하는 것을 에러없이 받고 싶다면 서버에서 커넥션을 종료하는 socket.end()을 없애면 됩니다. socket.end()를 지운 후 서버를 재실행한 후 클라이언트를 실행해보겠습니다.

생성된 커넥션을 끊지 않는다면 지속적으로 데이터를 주고받을 수 있습니다.

· 네트워크(TCP/UDP) 상태

두 응용프로그램이 커넥션이 끊어지지 않고 데이터를 주고받을 때 네트워크(TCP/UDP) 상태조회를 하면 다음과 같습니다.

3 way-handshake는 다음과 같이 패킷을 주고받으며 두 응용 프로그램의 네트워크 상태는 다음과 같이 전이합니다.

      TCP A                                                TCP B
  1.  CLOSED                                               LISTEN
  2.  SYN-SENT    --> <SEQ=100><CTL=SYN>               --> SYN-RECEIVED
  3.  ESTABLISHED <-- <SEQ=300><ACK=101><CTL=SYN,ACK>  <-- SYN-RECEIVED
  4.  ESTABLISHED --> <SEQ=101><ACK=301><CTL=ACK>       --> ESTABLISHED
  5.  ESTABLISHED --> <SEQ=101><ACK=301><CTL=ACK><DATA> --> ESTABLISHED

결과론적으로 established 상태의 두 응용프로그램은 커넥션을 유지하고 있어 데이터를 주고받을 수 있는 상태를 의미합니다.

// 서버 
net.createServer(socket => {})

// 클라이언트
const socket = net.connect({ port: 5000 });

우리가 작성한 코드에서 서버와 클라이언트 코드가 바로 저 복잡한 과정을 거쳐 established 상태를 가진 커넥션 객체를 만들어 주는 부분입니다.

하나의 클라이언트를 더 실행했습니다. 가장 위가 서버이며 그 아래2개는 클라이언트입니다.

네트워크(TCP/UDP) 상태를 조회하면 2개의 결과가 추가되었습니다. 여기서 9378은 TCP 서버이며 5000번 포트가 50071, 50073 포트와 연결된 상태를 의미합니다. 11711, 11796은 우리가 추가로 실행한 클라이언트입니다. 커넥션이 생성되면 OS는 해당 커넥션에게 랜덤하게 포트를 부여합니다. 그리고 로컬호스트의 5000 포트와 연결되어 데이터를 주고받을 수 있습니다.(established 상태이기 때문에)

● L4 - 응용 계층

응용 계층은 L3 위에서 동작하는 레이어입니다. 여기서 위에서 동작한다는 것은 L4에서 추가된 데이터가 L3를 통해 전송한다는 것을 의미합니다.

socket.write('test')

응용 계층은 established한 상태에서 데이터를 주고받을 때 서버와 클라이언트간 합의한 규칙입니다. 앞에서 L4의 대표적인 예로 HTTP가 있다고 했습니다.

· 프로토콜이란?

HTTP를 우리는 프로토콜이라고 부릅니다. 한가지 테스트를 해보겠습니다.

const net = require('net');

const server = net.createServer(socket => {
  console.log(`cnnected address: ${socket.address().address}`);
  socket.on('data', (data) => { 
    console.log(data.toString())
    socket.write('test')
    socket.end();
  });
})

server.listen(5000, function() {
  console.log(`listen on port 5000`)
})

클라이언트에게 요청을 받으면 클라이언트에게 전달받은 데이터를 출력한 후 test 문자열을 전송 후 4 way-handshake를 발생시켜 커넥션을 끊습니다.

해당 서버를 실행한 후 브라우저로 localhost:5000을 접속해보겠습니다. 아마 브라우저는 별다른 페이지를 띄우진 않습니다. 하지만 서버의 로그를 확인하면 다음과 같습니다.

서버의 로그를 확인하면 이상한 문자를 출력합니다.

· HTTP 프로토콜 규약에 맞는 서버

바로 이 부분이 우리가 얘기하는 HTTP 입니다. 네 HTTP 라는것은 바로 write()로 전달하는 데이터입니다. HTTP라는 규칙으로 작성된 문자열입니다.

여기서 HTTP 규약에 맞춰 write에 작성해주고 서버 재시작 후 브라우저로 접속해보겠습니다.

const net = require('net');

const server = net.createServer(socket => {
  console.log(`cnnected address: ${socket.address().address}`);
  socket.on('data', (data) => { 
    console.log('====== receive data======='); 
    const httpMsg = `
HTTP/1.1 200 Success
Connection: close
Content-Length: 1573
Content-Type: text/html; charset=UTF-8
Date: Mon, 20 Aug 2018 07:59:05 GMT

<!DOCTYPE html>
<html lang=en>
  <meta charset=utf-8>
  <title>Wow!!!!</title>
  <body>
    <h1>test</h1>
  </body>
</html>
`

    console.log(data.toString());
    socket.write(httpMsg)
    console.log('====== receive data======='); 
    socket.end();
  });
})

server.listen(5000, function() {
  console.log(`listen on port 5000`)
})

브라우저에서 서버가 응답한 HTML 코드를 정상적으로 렌더링한 모습을 확인할 수 있습니다.

· json 응답하기

const httpMsg = `HTTP/1.1 200 Success
Connection: close
Content-Length: 1573
Content-Type: application/json; charset=UTF-8
Date: Mon, 20 Aug 2018 07:59:05 GMT

{
  "name": "mung",
  "age": 30
}
`;

만약 socket.write로 전송하는 데이터가 앞의 문자열과 같다면 해당 데이터는 json으로 인식합니다. Content-Type에 따라 브라우저는 해당 데이터를 HTML 또는 json으로 인식할 수 있습니다.

· 그래서 HTTP 프로토콜은 어떻게 생겨먹었는데?

RFC를 통해 표준을 정의합니다. HTTP/1.1은 RFC 2616에 작성되어 있습니다.

HTTP1.1은 다음 링크에서 어떻게 생겼는지 확인할 수 있습니다.

https://datatracker.ietf.org/doc/html/rfc2616

RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1

datatracker.ietf.org

RFC를 기반하여 socket.write()으로 데이터를 전달하면 됩니다.

· HTTP 서버, TCP 클라이언트 통신

앞에서 TCP로 서버를 만든 후 HTTP 프로토콜을 응답했을 때 브라우저가 정상적으로 렌더링하고 json을 응답하는 서버를 구현해보았습니다. 이번엔 반대로 http 라이브러리로 만든 HTTP 서버를 net 라이브러리를 이용하여 요청/응답 과정을 살펴보겠습니다.

▶ 서버

const http = require('http');
const url = require('url');

const server = http.createServer( (req, res) => {
  console.log(req.method)
  console.log(req.url)
  res.writeHead(200);
  if (req.method === 'GET' && req.url === '/') {
    return res.end('mung ');
  } else{
    return res.end('mung mung');
  }
});

server.listen(5000)

▶ 클라이언트

const net = require('net');

// 서버 5000번 포트로 접속 
// 3 way-handshake
const socket = net.connect({ port: 5000 });

socket.on('connect', function () {
  console.log('connected to server!');
  socket.write('mung mung~~');
});

// 서버로부터 받은 데이터를 화면에 출력 
socket.on('data', function (chunk) {
  console.log('receive: ' + chunk);
});

// 접속이 종료됬을때 메시지 출력 
// 4 way-handshake
socket.on('end', function () {
  console.log('disconnected.');
});

// 에러가 발생할때 에러메시지 화면에 출력 
socket.on('error', function (err) {
  console.log(err);
});

// connection에서 timeout이 발생하면 메시지 출력 
socket.on('timeout', function () {
  console.log('connection timeout.');
});

서버를 실행 후 클라이언트를 실행하면 클라이언트는 다음과 같은 메시지를 응답받습니다. 400은 올바른 요청을 하지 않았다는 것을 의미합니다.

HTTP/1.1 400 Bad Reques

바로 "mung mung~~"는 HTTP 양식에 맞지않기 때문입니다.

클라이언트에서 socket.write(mung mung~)을 HTTP 규격에 맞춰서 다음과 같이 전송하면 HTTP 서버는 정상적으로 처리합니다.

socket.on('connect', function () {
  console.log('connected to server!');
  const msg = [
    'GET / HTTP/1.1',
    'Accept: */*',
    'User-Agent: my-test-agent',
    'Host: localhost:5000',
    '',
    '',
  ].join('\r\n')
  socket.write(msg);
});

GET 메서드의 /으로 요청한 결과를 확인할 수 있습니다.

/a로 요청하고 싶다면 다음과 같이 수정합니다.

socket.on('connect', function () {
  console.log('connected to server!');
  const msg = [
    'GET /a HTTP/1.1',
    'Accept: */*',
    'User-Agent: my-test-agent',
    'Host: localhost:5000',
    '',
    '',
  ].join('\r\n')
  socket.write(msg);
});

· 그 외의 프로토콜

현재 시점에서 HTTP 프로토콜을 제외하고 많이 사용하는 프로토콜은 웹소켓이 있습니다. 일반적으로 웹소켓은 HTTP를 좀 더 개량하여 사용한 방법입니다. 웹소켓도 HTTP와 개념은 동일합니다. HTTP는 한 번 데이터를 주고 받으면 커넥션을 끊지만 웹소켓은 끊지 않습니다. 웹소켓은 HTTP 통신을 한 번 주고받고 웹소켓으로 업그레이드 되는 형태로 프로토콜이 구성되어 있습니다.

즉 정리하면 HTTP나 웹소켓은 두 응용프로그램간 연결된 상태(ESTABLISHED)에서 데이터를 주고 받을 때 HTTP는 한 번의 데이터를 주고 받으면 커넥션을 끊으며, 웹 소켓은 끊지 않는 방법입니다.

GET / HTTP/1.1
Sec-WebSocket-Version: 13
Sec-WebSocket-Key: J7dCBYk6vVIqwcI/0+CUWQ==
Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits
Host: 127.0.0.1:5000

웹소켓의 경우는 커넥션 후 데이터를 전송할 때 Connection은 Upgrade, Upgrade는 websocket으로 설정된다는 특징을 가지고 있습니다.

정리하면 L3는 데이터를 전송하기 위한 커넥션을 만들면 L4에선 정해진 규격을 맞춰 데이터를 주고 받습니다. 여기서 정해진 규격을 프로토콜이라고 합니다.

응용계층을 정리하면 HTTP는 TCP위에서 정의한 데이터를 주고받는 규격입니다. 이때 HTTP를 좀 더 확장한 개념으로 웹소켓을 사용합니다. 웹소켓과 HTTP를 좀 더 유연하게 사용하기 위해 socket.io와 같은 라이브러리가 탄생했습니다.

또 UDP를 이용한 방식으로 요즘 많이 핫해지고 있는 webRTC가 있습니다.

● L5 - 라이브러리 계층

자 이제 본격적으로 HTTP 서버를 만든다고 생각해보겠습니다. 그럼 우리는 클라이언트가 전달한 매번 클라이언트한테 요청받은 데이터를 매번 파싱해서 쓰는건 말이 안됩니다.

그래서 앞에서 클라이언트에게 전달받은 HTTP 본문을 파싱하고 write를 이용하여 응답하는 부분을 좀 더 편리하게 추상화한 라이브러리인 http를 제공합니다.

const http = require('http');
const url = require('url');

const server = http.createServer( (req, res) => {
  console.log(req.method)
  console.log(req.url)
  res.writeHead(200);
  res.end('mung mung');
});

server.listen(5000)

http 라이브러리는 요청 객체와 응답 객체를 이용하여 클라이언트의 요청 데이터를 확인하고 응답할 수 있습니다.

(req, res) => {}

established가 되어 데이터를 주고받을 수 있는 상태가 되면 클라이언트가 전달한 HTTP 본문을 첫 번째 객체인 요청 객체로 만들어주며 socket.write를 추상화하여 사용할 수 있는 두 번째 인자로 전달한 응답 객체를 전달받습니다.

브라우저 및 HTTP 클라이언트 프로그램으로 localhost:5000, localhost:5000/a로 접속하면 서버는 다음과 같이 로그를 출력합니다.

GET
/a
GET
/

HTTP 서버를 만들 땐 method와 url을 이용하여 서로 다른 데이터를 응답하는 형태로 만들게 됩니다. 이를 API라고도 하죠

· method와 url에 따라 다른 데이터 응답하기

const http = require('http');
const url = require('url');

const server = http.createServer( (req, res) => {
  console.log(req.method)
  console.log(req.url)
  res.writeHead(200);
  if (req.method === 'GET' && req.url === '/') {
    res.end('mung ');
  } else{
    res.end('mung mung');
  }
});

server.listen(5000)

서로 다른데이터를 응답받습니다.

● L6 - 프레임워크

하지만 이 또한 귀찮습니다. 먼가 코드를 유지보수하기 힘든 부분도 있을것이고 좀더 체계화할 수 있는 여러 프레임워크가 나오고 있습니다. 자바의 스프링, 노드의 express, nest, koa 등, 파이썬의 django, flask, fastapi 등 여러 프레임워크가 쏟아져 나오고 있습니다.

예를들어 여기서 언급한 프레임워크들은 각 언어에서 제공하는 http를 기반으로 보다 편하게 사용할 수 있도록 기능이 추가된 것들입니다.

const express = require('express')
const app = express()
const port = 3000

app.get('/', (req, res) => {
  res.send('mung!')
})

app.get('/a', (req, res) => {
  res.send('mung mung!')
})

app.listen(port, () => {
  console.log(`Example app listening on port ${port}`)
})

● 기타

· socket.io

socket.io 라는 라이브러리가 있습니다. socket.io는 HTTP와 WebSocket을 둘 다 지원하는 라이브러리입니다. socket.io는 L3에 비하면 상당히 추상화 된 레이어입니다. socket.io는 L3(전송계층)를 구현하지 않습니다. HTTP와 WebSocket 위의 레이어에서 WebSocket을 지원하지 않는 환경에서 HTTP를 이용하여 주기적으로 요청하는 폴링 기법을 지원합니다.

· UDP

L3의 전송계층에서 TCP를 다뤄봤는데 UDP를 다루지 않으면 UDP가 삐질테니 UDP를 빠르게 살펴보겠습니다.

▶ 서버

const dgram = require('dgram');
const server = dgram.createSocket('udp4');
const port = 5000;
 
server.on('message', (message, info) => {
  console.log(`message: ${message.toString()}`);
  console.log(`from address: ${info.address} port: ${info.port}`);
});
 
server.on('listening', () => {
  const address = server.address();
  console.log(`listening ${address.address}:${address.port}`);
});
 
server.bind(port);

▶ 클라이언트

const dgram = require('dgram');
const toHost = '0.0.0.0';
const toPort = 5000;
const client = dgram.createSocket('udp4');
 
const data = Buffer.from('mung');
 
client.send(data, toPort, toHost, (err) => {
  if (err) console.log(err);
  else console.log('ok');
  client.close();
});

아무생각없이 보면 TCP랑 다를게 없는데? 할 수 있을텐데 잘 보면 클라이언트에서 connect하는 코드가 없습니다. UDP는 커넥션 생성 -> 데이터 전송 -> 커넥션 제거 과정없이 데이터 전송을 합니다.

엥? 그럼 데이터 전송이 안될 수 있지 않나?

네 맞습니다. UDP는 데이터 전송을 보장하지 않습니다. 그렇기 때문에 일반적으로 데이터 전송을 보장해야 하므로 TCP 기반으로 구현된 HTTP, WebSocket 등을 많이 사용합니다. 하지만 요즘 UDP를 활용한 프로토콜이 핫해지고 있습니다. 바로 webRTC 입니다. 머 사실 webRTC는 내부적으로 복잡한 통신을 주고 받는데 모든 통신을 UDP로 구성되어 있진 않습니다. TCP와 UDP를 혼용하여 사용합니다. webRTC의 UDP는 UDP로 구현된 SCTP를 사용합니다.

● HTTP/1.1, HTTP/2.0, HTTP/3.0

현재 가장 많이 사용하고 있는 HTTP 버전은 1.1입니다.

HTTP/1.1도 단점이 많아 이를 개선한 방법이 HTTP/2.0, HTTP/3.0입니다.

HTTP/2.0은 SPDY를 기반으로 구현합니다.

HTTP/3.0은 QUIC를 기반으로 구현합니다. QUIC는 UDP 기반으로 만들어져있습니다.

· HTTP/1.1

HTTP/1.1은 connection: keep-alive를 이용하여 커넥션을 제거하지 않습니다. 앞에서 만든 http 모듈로 구축한 HTTP 서버를 실행합니다.

const http = require('http');
const url = require('url');

const server = http.createServer( (req, res) => {
  console.log(req.method)
  console.log(req.url)
  res.writeHead(200);
  if (req.method === 'GET' && req.url === '/') {
    return res.end('mung ');
  } else{
    return res.end('mung mung');
  }
});

server.listen(5000)

응답을 정상적으로 마쳤지만 ESTABLISHED 상태를 유지합니다.

동일한 커넥션을 가지고 데이터를 지속적으로 주고 받는지 테스트 하기 위해 요청하는 코드를 작성합니다.

setInterval(async () => {
    await fetch('http://127.0.0.1:5000')
}, 300)

앞에서 127.0.0.1:5000으로 접속한 페이지에서 개발자 도구를 연 후 해당 스크립트 코드를 실행합니다. 해당 코드는 300ms 마다 127.0.0.1:5000로 요청하는 코드입니다.

주기적으로 네트워크 상태를 살펴보면 동일한 커넥션이 유지되고 있는 모습을 확인할 수 있습니다.

커넥션을 유지하여 데이터를 주고받는 과정을 Pipelining이라고 합니다.

▶ CLOSE_WAIT

CLOSE_WAIT 상태를 만들고 싶다면 HTTP 서버를 열고 브라우저에서 해당 서버를 접속합니다. 그러면 ESTABLISHED 상태가 되는데 이때 서버를 종료하고 네트워크 상태를 확인하면 앞의 이미지처럼 CLOSE_WAIT 상태로 바뀐 모습을 확인할 수 있습니다.

CLOSE_WAIT는 두 응용프로그램에서 한쪽이 커넥션을 끊은 상황을 의미합니다. 행아웃이라고도 합니다. CLOSE_WAIT는 이미 커넥션이 끊겼기 때문에 해당 커넥션을 다시 재사용할 수 없습니다.

CLOSE_WAIT말고 TIME_OUT도 있는데 이는 재사용 가능합니다. 네트워크 상태는 다음과 같습니다.

CLOSE	    커넥션 없음
LISTEN	    Passive open, SYN을 기다리는 상태
SYN-SENT	SYN을 보내고 ACK를 기다리는 상태
SYN-RCVD	SYN+ACK을 보내고 ACK를 기다리는 상태

ESTABLISHED	커넥션이 생성된 상태, 데이터를 전송할 수 있다.

FIN-WAIT-1	첫 FIN이 보내진 상태, ACK를 기다리고 있다.
FIN-WAIT-2	첫 FIN에 대한 ACK를 받은 상태, 2번째 FIN을 기다리고 있다.
CLOSE-WAIT	첫 FIN을 받고 ACK를 보낸 상태, 어플리케이션의 종료를 기다리고 있다.
TIME-WAIT	2번째 FIN을 받고 ACK를 보낸 상태, 동일 포트와 주소에 커넥션이 생성되지 않도록 하는 시간(2MSL time out)을 기다리는 상태
LAST-ACK	2번쨰 FIN을 보내고 ACK를 기다리는 상태
CLOSING	    양쪽이 동시에 닫기로 한 상태

TCP에서 Passive와 Active 개념이 있습니다. Active는 무언가 요청하는 대상을 의미하고 Passive는 요청을 받는 대상을 의미합니다.

Active Open은 연결 오픈을 요청하는 대상, Passive Open은 연결 오픈 요청을 받는 대상

Avtive Close은 연결 종료를 요청하는 대상, Passive Close은 연결 종료 요청을 받는 대상

· HTTP/1.1 문제점

HTTP/1.1은 크게 2가지 문제점을 가집니다.

HOLB: Head Of Line Blocking
RTT: Round Trip Time
Heavy Header

▶ HOLB(Head Of Line Blocking)

앞에서 HTTP/1.1은 ESTABLISHED를 계속 유지하여 TCP 연결을 최소화합니다. 하지만 해당 상태를 유지하더라도 문제점이 있습니다. 바로 HOLB입니다.

setInterval(async () => {
    await fetch('http://127.0.0.1:5000')
}, 300)

이런 형태로 300ms마다 서버로 요청을 합니다. 만약 응답하는데 300ms가 더 걸린다면 어떻게 될까요. 예를들어 10개의 요청을 발생했을 때 7번째 응답해야하는 데이터의 크기가 너무커서 지연이 되었다고 가정하겠습니다. 7번째 이후 응답은 7번째 응답이 완료될 때까지 지연됩니다. 왜냐하면 TCP는 클라이언트의 요청을 받고 데이터를 전달하는 과정을 블락킹하기 때문입니다. 블락킹하는 이유는 TCP 자체가 순서보장을 해야하기 때문입니다.3개의 요청은 반드시 요청한 순서대로 응답해야 합니다. 이를 보장하는것이 TCP의 역할입니다.

▶ RTT(Round Trip Time)

근본적으로 HTTP는 TCP 기반으로 하기 때문에 3 way-handshake, 4 way-handshake로 인한 네트워크 지연은 피할 수 없습니다. Connection: Keep-Alive으로 커넥션을 유지하지만 일정시간 데이터를 주고받지 않으면 연결을 끊고 다시 연결을 수행합니다. 연결상태를 계속 유지할 경우 서버의 입장에서 메모리 문제가 발생할 수 있음

▶ Heavy Header

앞에서 TCP 서버를 연 후 브라우저 및 HTTP 클라이언트 프로그램으로 커넥션하여 데이터를 전송할 때 실제 데이터보다 너무 방대한 헤더를 확인할 수 있습니다.

HTTP/1.1은 실제 사용될 데이터보다 반복적으로 헤더를 포함하기 때문에 데이터가 전체적으로 무거워집니다.

HTTP/1.1은 이러한 문제를 해결하기 위해 나름 여러 방법을 고안했습니다.

Image Spriting, Domain Sharding, Minified CSS/JavaScript, Load Faster, Data URI Scheme

· HTTP/2.0

HTTP/2.0은 HTTP/1.1의 가장 큰 문제인 HOLB와 Heavy Header 문제해결을 목적으로 합니다.

구글은 SPDY 프로토콜을 구현함으로써 HTTP/2.0을 구현했습니다.

▶ Multiplexed Streams

클라이언트는 요청 순서에 상관없이 응답을 받더라도 이를 처리할 수 있습니다.

또한 사이즈가 큰 패킷을 쪼개어 응답합니다. 간단한 개념으로 사이즈가 큰 응답 메시지를 작은 단위의 여러 프레임으로 쪼개어 응답합니다. 여기서 원본 응답 메시지를 스트림이라고 표현하고 하나의 응답 메시지 스트림을 여러개로 쪼갠 단위를 프레임이라고 합니다. 하나의 스트림은 여러 프레임을 가질 수 있습니다

응답 결과를 받은 대상은 여러 단위의 프레임을 하나의 메시지로 다시 조립하여 사용합니다.

HTTP/2.0은 해당 방식을 기반으로 동작합니다.

▶ Stream Prioritization

서버는 클라이언트의 여러 요청에 대해 우선순위에 따라 응답 순서를 바꿀 수 있습니다. Multiplexed Streams에서 스트림은 여러 프레임으로 쪼개어 전송을 한다고 했습니다. 이 말은 프레임 전달 순서에 따라 성능 결정을 한다는 의미입니다.

HTTP/2.0은 스트림의 종속성과 가중치 조합을 사용하여 클라이언트가 구성한 우선순위 지정 트리를 이용하여 통신합니다. 서버는 연결된 클라이언트의 우선순위 지정 트리에 따라 다른 순서로 프레임은 전송하게 됩니다.

▶ Server Push

서버는 클라이언트의 한번의 요청으로 필요한 리소스 파일을 socket.write()하여 주는것을 의미합니다.

▶ Header Compression

HTTP/2.0은 헤더를 HPACK 압축방식을 이용하여 압축합니다. 또한 중복된 값으로 크기가 증가하는 문제를 없애기 위해 static/dynamic header table을 이용하여 중복을 최소화합니다.

HTTP/1.1과 HTTP/2.0은 근본적으로 TCP를 기반으로 동작하기 때문에 handshake 문제를 피할 수 없습니다. 또한 multiplexed streams를 이용하더라도 HOLB 문제를 완벽하게 해결할 수는 없습니다.

· HTTP/3.0

HTTP/3.0은 UDP 기반으로 구현된 QUIC 프로토콜을 이용합니다. 즉, HTTP/3.0은 UDP를 사용합니다. TCP 대신 UDP를 사용하면서 handshake 과정이 없어지기 때문에 네트워크 레이턴시가 상당히 짧아집니다. 하지만 데이터의 보장이 100% 확신할 수 없는 프로토콜 입니다. TCP와 UDP 패킷만 까봐도 TCP는 데이터의 신뢰도를 보장하기 위해 엄청나게 많은 정보를 포함하고 있습니다.(여기서 신뢰도란 데이터를 전송할 때 완벽하게 목적지에 도달하는 것을의미) 하지만 UDP는 신뢰도를 보장하지 않기 때문에 패킷이 매우 가볍습니다.

TCP 패킷(출처: http://www.ktword.co.kr/test/view/view.php?m_temp1=1889&id=1103 )

UDP 패킷(출처: http://www.ktword.co.kr/test/view/view.php?m_temp1=323&m_search=UDP )

패킷만 봐도 TCP가 얼마나 복잡한지 알 수 있습니다.

또한 HTTP/3.0을 쓰기 위해서 반드시 HTTPS를 적용해야 합니다.

필자의 경우 아직 UDP 기반의 HTTP/3.0이 정말 기존의 HTTP를 완전히 대체할 수 있을지는 잘 모르겠습니다.

● 연결성과 상태유지

마지막으로 HTTP의 연결성 및 상태유지를 다뤄보고자 합니다.

· 연결성

HTTP는 연결지향(Connected oriented)이다 비연결성(Connectionless)이다 딱 말하기가 힘듭니다. 연결지향 비연결은 연결 상태를 유지하느냐 유지 하지 않느냐를 의미합니다. 연결지향은 연결을 유지하여 데이터를 주고받는 것을 의미하며 비연결은 데이터를 전송할 때마다 연결을 다시하여 전송합니다. 즉 데이터 전송할 때마다 3 way-handshake를 수행합니다.

기본적으로 TCP는 연결지향이 맞습니다. 3 way handshake로 연결하여 ESTABLISHED 상태를 만든 후 데이터를 주고 받고 4 way handshake를 이용하여 연결을 종료합니다. ESTABLISHED에선 연결된 상태를 유지합니다. 1:1 연결이 유지된 상태에서 데이터를 주고받을 수 있습니다.

하지만 HTTP는 초기 모델에서 비연결성으로 만들어 졌습니다. 그러다보니 매번 데이터를 전송할 때마다 3 way handshake가 발생하여 네트워크 레이턴시가 증가합니다.

시간이 흐르면서 HTTP도 발전해왔고 HTTP/1.1에선 Connection: Keep-Alive을 이용하여 커넥션을 끊지않고 연결을 일정시간 유지하므로 연결지향이 됩니다. 하지만 시간이 지나면 커넥션이 끊겨 데이터 전송시 다시 연결을 시도하는 비연결이 됩니다.

· 상태유지

상태 유지의 간단한 예 중 하나가 인증입니다. HTTP의 경우 세션을 유지할 때 redis를 사용하여 관리합니다. 그 이유는 클라이언트가 다른 서버로 요청하게 되면 세션을 가지고 있지 않기 때문에 비로그인 상태로 인식하기 때문입니다. 이렇듯이 HTTP는 자체적으로 상태를 가지고 있지 않습니다. 이를 무상태 프로토콜(stateless)이라고 합니다. 만약, A 서버에서 클라이언트의 세션을 가지고 있었는데 A 서버가 재시작되었다면? 세션은 날아가기 때문에 클라이언트는 로그인 상태가 유지되지 않습니다.

HTTP는 자체적으로 상태를 저장할 수 없기 때문에 쿠키, 세션 그리고 JWT를 이용하여 별도로 클라이언트의 상태를 포함하여 전송하게 됩니다.

[ethereum] 개인키와 공개키 그리고 트랜잭션 서명

멍개. — Sun, 28 Aug 2022 08:46:00 +0900

이번 포스트에서는 개인키와 공개키가 생성되는 과정과 트랜잭션을 서명하고 검증하는 방법을 다룹니다.

또한 트랜잭션을 서명하는 과정에서 Simple Replay Attack Protection을 위해 EIP-155를 적용합니다.

본론을 들어가기 앞서서 선행되어야 하는 개념이 있습니다. 바로 ECC인 타원곡선 암호화와 modular(나머지) 연산 입니다.

● ECC(Elliptic Curve Cryptography)

ECC는 타원 곡선 암호화라고 불리면 공개키 암호화 방식입니다.

· 정의

타원곡선은 다음과 같이 정의합니다.

$$y^2=x^3+ax+b$$

타원곡선 함수

타원곡선은 x을 중심으로 대칭입니다. 그 이유는 y가 제곱 형태를띄기때문 입니다.

https://www.desmos.com/calculator?lang=ko

해당 링크에서 a와 b값에 따라 그래프가 어떤 모습을 보여주는지 확인할 수 있습니다.

· 연산

타원 곡선 암호화인 ECC를 이해하기 위해선 타원 곡선 함수에서 덧셈 연산을 이해해야 합니다.

타원곡선 상에 다음과 같이 2개의 점을 점 P, 점 Q라고 정의합니다.

점 P와 Q를 지나는 직선과 타원곡선이 만나는 교점을 -R이라고 합니다.

이때 -R의 X 축으로 대칭된 점을 R이라고 합니다.

해당 점의 좌표를 ECC에서 덧셈 연산으로 표현하면 P + Q = R이라고 정의합니다.

이를 이용하여 곱셈 연산을 덧셈 연산으로 표현할 수 있습니다.

ECC는 덧셈 연산만 가능하다는 점을 꼭 기억해야 합니다.

곱셈은 덧셈의 연속이기 때문에 덧셈으로 바꿔서 해석이 가능합니다.

P와 Q를 두 점이 아닌 한 점으로 표현해도 동일하게 P + Q = R을 성립합니다.

P와 Q는 같기 때문에 P + Q는 P + P로 표현가능합니다.

P + P = R이 됩니다. 이는 2P = R이 됩니다. 해당 그래프에서 R은 2P가 됩니다.

그렇다면 3P는 어떻게 연산이 가능할까요? 바로 앞의 그래프에서 점 P와 점 R(2P)를 지나는 직선을 그립니다. 그리고 만나는 교점을 X축으로 대칭한 위치가 3P가 됩니다.

여기서 핵심은 곱셈은 덧셈의 연속으로 풀 수 있다는 점일 인지하도록 합니다.

이를 수식으로 풀면 다음과 같습니다.

P(x1, y1), Q(x2, y2)가 E 상에 존재할 때 R(x3, y3) = P(x1, y1) + Q(x2, y2)가 된다.

$$P,\ Q\ \in \ \ E\\ P\ =\ \left(x1,\ y1\right),\ Q\left(x2,\ y2\right)\\ R\ =\ \left(x3,\ y3\right)\ =\ P\ +\ Q$$

☞ P != Q일때(addition)

$$\lambda \ =\ \frac{y2\ -\ y1}{x2\ -\ x1}$$

$$y3\ =\ \left(x1\ -\ x3\right)\lambda \ -\ y1$$

☞ P == Q일 때(Doubling)

$$\lambda \ =\ \frac{3\ \cdot \ x1^2\ +\ a}{2\ \cdot \ y1}\left(a는\ y^2\ =\ x^3\ +\ ax\ +\ b에서의\ a이다\right)$$

$$x2\ =\ {\lambda }^2\ +\ 2\ \cdot \ x1\\ y2\ =\ \left(x1\ -\ x2\right)\lambda \ -\ y1$$

· 모듈러(나머지) 연산

모듈러 연산은 나머지연산입니다. 연산자는 mod라고 표기합니다. 코드레벨에선 %으로 대부분 표현합니다.

10 % 3 = 1
10 mod 3 = 1

만약 음수에 대한 모듈러 연산을 어떻게 해야할까요?

모듈러 연산의 특징 중 하나가 피연산자의 값을 주기로 같은 결과값을 가지는 주기성을 띕니다.

-5 mod 3은 다음과 같이 변환가능합니다.
(-5 + 3) mod 3 => -2 mod 3
-5 mod 3 = -2 mod 3 이 두식의 값은 같습니다. 

(-2 + 3) mod 3 = 1 mod 3 = 1

· 갈루아 필드에서 타원 곡선(Elliptic Curves Over GF(p))

갈루아 필드는 유한체를 의미합니다.

유한한 좌표를 가지는 공간을 의미하며 이는 modular 연산을 이용합니다. mod p를 수행합니다. p는 소수로 정의합니다.

갈루아 필드는 다음과 같이 정의할 수 있습니다.

다음은 갈루아 필드의 예입니다.

$$y^2=x^3+x\ over\ {Z}_{23}\ (p=23)$$

만약 x가 9라면, (9^3 + 9) mod 23 = 2가 됩니다. 이는 (5 * 5) mod 9 = 2로 표현이 가능하며 y는 5가 됩니다. 즉 x가 9일 때 y는 5가 나옵니다.

여기서 p가 커진다면 y는 쉽게 찾기 힘듭니다.

· privatekey, publickey

ECC는 퍼블릭키를 생성하기 위해 먼저 개인키(pk)를 랜덤하게 생성합니다.

퍼블릭키(pub) = pk * G(x0, y0) (G는 이미 알려져 있음 이를 베이스 포인트라고도 부름)

즉, 퍼블릭키는 G(x0, y0)을 pk번 더합니다.

여기서 이런 의문이 들 수 있습니다. G는 이미 공개가 되어있고 공개키는 공개가 되어있으면 개인키(pk)를 찾을 수 있는거 아닌가?하는 생각이 들 수 있는데 ECC에서 G와 공개키를 알 수 있다고 pk를 찾는건 매우 어렵습니다. 이를 ECDLP라고 하며 이러한 특징 때문에 ECC를 공개키 암호기술로 사용합니다.

한 가지 예시를 들어보겠습니다.

갈루아 필드가 다음과 같이 정의될 때, G = (2, 7)일때 2G를 계산해 보겠습니다.

$$y^2\ =\ x^3\ +\ x\ +\ 6\ over\ {Z}_{11}$$

먼저 2G는 G + G이므로 앞에서 P == Q(doubling) 공식을 대입하면 됩니다.

$$x1\ =\ 2,\ \ y1\ =7\\ \lambda \ =\ \frac{3x1^2\ +\ a}{2y1}\ =\ \frac{3\ \cdot \ 2^{2\ }+1}{2\ \cdot \ 7}\ =\ \frac{13}{14}$$

여기서 람다 결과인 13/14를 분자 분모를 각각 mod11을 수행합니다.

$$2\ \cdot \ {3}^{-1}$$

여기서 3^-1을 mod 11 연산을 하면 4가 나옵니다.

$$\lambda \ =\ 2\ \cdot \ 4\ mod\ 11=8\ mod\ 11\\ x2\ =\ \lambda \ -\ 2x1\ =\ 8^2\ -\ 2\ \cdot \ 2\ =\ 5\ mod\ 11\\ y2\ =\ \left(x1\ -\ x2\right)\lambda \ -\ y1\ =\ \left(2\ -5\right)\ \cdot \ 8\ -7\ =\ 2\ mod\ 11$$

이제 G, 2G, 3G, 4G, ... KG(K는 임의의 양의정수)

pk(개인키) * G(베이스 포인트) = pub(공개키)

G=(2, 7), 2G = (5, 2), 3G = (8, 3)

4G = (10, 2), 5G = (3, 6), 6G = (7, 9)

7G = (7, 2), 8G = (3, 5), 9G = (10, 9)

● 이더리움의 개인키 공개키

트랜잭션을 만들기 위해선 트랜잭션을 서명할 개인키가 필요합니다.

이더리움은 개인키 - 공개키 - 주소 순서로 키와 주소를 생성합니다.

· 개인키 생성

개인키는 1 ~ n-1까지 정수 중 하나의 랜덤값 입니다. 여기서 n은 secp256k1 타원곡선에서 1.157920892373162e+77으로 정의됩니다.

secp256k1 타원 곡선 함수는 a=0, b=7로 정의되며 G=02 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798 입니다.

또한 유한군 소수값인 p는 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE FFFFFC2F으로 정의합니다.

a = 0

b = 7

유한군 p값 = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE FFFFFC2F

G=02 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798

개인키는 1 ~ FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364140 까지의 범위를 가집니다. 해당 범위를 넘으면 올바르지 않은 키라고 에러가 발생합니다.

const { Wallet } = require('ethers');

async function main() {
  const private = 'FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364140';
  const wallet = new Wallet(private);
  console.log(wallet)
}

main()

/*
Wallet {
  _isSigner: true,
  _signingKey: [Function (anonymous)],
  _mnemonic: [Function (anonymous)],
  address: '0x80C0dbf239224071c59dD8970ab9d542E3414aB2',
  provider: null
}
*/

const { Wallet } = require('ethers');


async function main() {
  const private = 'FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141';
  const wallet = new Wallet(private);
  console.log(wallet)
}

main()

ECC는 개인키를 구한 후 공개키를 구하지만 RSA는 공개키를 구한 후 개인키를 구합니다.

· 공개키

공개키는 개인키로 생성합니다. 개인키와 이더리움에서 정한 기준점 G를 곱합니다.

공개키 = 개인키 * G

공개키는 ECC의 덧셈 연산을 통해서 연산합니다. 기준점 G를 개인키만큼 더합니다.

· 주소

주소는 공개키를 keccak-256 해싱 결과의 마지막 20바이트입니다.

● 트랜잭션 서명과 검증

이더리움은 트랜잭션 서명을 위해 ECC를 이용한 디지털 서명을 수행합니다.

이를 ECDSA라고 합니다. ECDSA는 타원 곡선 디지털 서명 알고리즘입니다. ECDSA에서 secp256k1을 이용합니다.

트랜잭션 서명을 위해 r, s, v를 트랜잭션에 포함해야 합니다.

r과 s는 서명입니다. v는 공개키를 복구하는 키 입니다. 이더리움 트랜잭션을 서명할 때 공개키를 포함하지 않고 공개키를 복구할 수 있도록 공개키 복구키인 v를 포함합니다

· 서명 r 생성

트랜잭션 서명을 위해 r을 만드는 과정은 다음과 같습니다.

개인키를 만든 것 처럼 1 ~ n-1 난수를 생성합니다. 여기서 생성된 난수를 k라고 하겠습니다.

개인키의 경우 한 번 생성되면 계속 사용하지만 서명 r은 트랜잭션을 서명할 때마다 새로 생성합니다. ECC식인 P = k * G를 통해 점 P의 좌표를 구합니다. 이때 x 좌표가 서명 r값이 됩니다.

· 서명 s 생성

s는 서명 r을 생성하기 위해 만든 난수 k를 이용합니다.

$$s\ \ =\ k^{-1}\ \left(z\ +\ r\ \cdot \ p\right)\ mod\ n$$

z는 트랜잭션 정보를 RLP 인코딩한 값입니다.

r은 서명 r입니다.

p는 개인키입니다.

만약, 이때 서명 s가 0이 나오면 k를 새롭게 생성하고 다시 계산합니다.

▶ (RLP 인코딩 시 포함하는 트랜잭션 정보는 다음과 같습니다.)

nonce, gasprice, startgas, to, value, data, chainID, 0, 0

EIP-155에서 simple replay attack protection을 위해 chainID를 포함하여 인코딩하는 것을 권장합니다.

https://eips.ethereum.org/EIPS/eip-155

EIP-155: Simple replay attack protection

eips.ethereum.org

· 공개키 복구키 v 생성

이더리움에서는 트랜잭션에 공개키를 추가하지 않습니다. v라는 값을 이용하여 공개키를 복구 할 수 있도록 합니다.

EIP-155에서 v는 다음과 같이 정의합니다.

v = CHAIN_ID * 2 + 35 또는 v = CHAIN_ID * 2 + 36

즉, 메인넷 기준으로 37 또는 38이 나옵니다. 또한 0 + 27 또는 1 + 27을 사용하기도 합니다.

· 트랜잭션 전송

서명 s, 서명 r, 복구키 v를 트랜잭션에 포함한 후 RLP 인코딩하여 전송합니다.

· 트랜잭션 검증

트랜잭션 검증은 별도의 식이 있습니다.

트랜잭션 검증 식 = U1 * G + U2 * public key

w = s^-1 mod n (s = s서명)

U1 = z * w mod n (z = 트랜잭션 RLP 인코딩)

U2 = r * w mod n (r = r서명)

U1과 U2는 서명 s와 서명 r을 이용하여 알 수 있습니다. public key는 복구키인 v를 이용하여 복구할 수 있습니다. 복구키 v는 서명 r과 서명 s값만 가지고 공개키를 추출할 수 있도록 합니다.

solidity에서는 ecrecover() 함수를 제공합니다.

트랜잭션 검증식은 타원곡선의 연산으로 타원곡선 위의 점이 나오게 되며 해당점의 x 좌표값과 트랜잭션에 포함된 서명 r값이 같으면 해당 트랜잭션을 유효하다고 판단합니다.

참고자료:

http://wiki.hash.kr/index.php/%ED%83%80%EC%9B%90%EA%B3%A1%EC%84%A0_%EB%94%94%EC%A7%80%ED%84%B8%EC%84%9C%EB%AA%85_%EC%95%8C%EA%B3%A0%EB%A6%AC%EC%A6%98

https://eips.ethereum.org/EIPS/eip-155

https://steemit.com/kr/@icoreport/key-2-ecc

그래프 생성도구:

https://www.desmos.com/calculator?lang=ko

[ethereum] RLP 인코딩

멍개. — Sun, 28 Aug 2022 08:22:06 +0900

RLP(Recursive Length Prefix) 인코딩은 임의의 길이를 가진 문자열과 배열을 인코딩하는 방법입니다. RLP 인코딩은 인코딩 된 값에 길이 정보를 포함합니다.

RLP 인코딩은 아스키 코드를 이용합니다.

● RLP 인코딩

RLP 인코딩은 5가지 케이스가 있습니다. RLP는 아스키 코드를 절대적으로 참조하여 인코딩을 수행합니다. RLP 인코딩은 아스키 코드표 1~127을 제외한 문자는 취급하지 않습니다. 예를들면 한국어, 일본어, 일부 특수문자 등

· 첫 번째 케이스 - 단일 바이트일 때

첫 번째 케이스는 하나의 바이트만 존재할 때 입니다. 즉, 문자 하나만 존재할 때 해당 바이트에 해당하는 아스키코드 값을 그대로 사용합니다.

이 때 해당 바이트의 범위는 0x01 ~ 0x7f(1 ~ 127)입니다.

0x12와 0x7f를 인코딩한다고 가정하겠습니다.

RLP(0x12) = 0x12
RLP(0x7f) = 0x7f

a를 인코딩한다고 하면, a를 아스키 코드에서 hex값을 찾습니다. a는 97이며 0x61입니다. 범위가 0x01 ~ 0x7f이므로 RLP(a) = 0x61이 됩니다.

RLP 인코딩에서 유일하게 prefix가 붙지않는 케이스입니다.

다음 네 가지 케이스의 경우는 길이를 포함한 정보를 prefix로 붙입니다.

· 두 번째 케이스 - 문자열의 길이가 0 ~ 55 바이트(Byte)

해당 케이스는 0x80을 prefix로 사용합니다. 즉, 0x80을 시작으로 인코딩 값을 이어붙입니다.

▶ 0x80에 문자열의 길이를 더한 후 아스키 코드표를 참조한 문자열값을 이어 붙입니다.

만약 abc를 RLP 인코딩 한다면

a = 0x61(97)

b = 0x62(98)

c = 0x63(99)

문자열의 길이 = 3

prefix = 0x80 + 0x03 = 0x83

RLP("abc") = 0x83 61 62 63

· 세 번째 케이스 - 문자열의 길이가 55 바이트(byte) 초과

해당 케이스는 0xb7을 prefix로 사용합니다. 즉, 0xb7을 시작으로 인코딩 값을 이어붙입니다. 왜 하필 0xb7일까?

0x80에서 55(0x37)문자가 되었을 때 0x80 + 0x37 = 0xb7이 나옵니다.

▶ 0xb7에 문자열 길이의 바이트값을 더한 후, 길이를 이어 붙입니다. 그리고 아스키 코드표를 참조한 문자열값을이어 붙입니다.

만약, a*1000을 인코딩한다면,

a = 0x61(97)

문자열의 길이 = 1000 => 11(0x03) 11101000(0xc8)(바이트 단위로 끊는다) => 2

prefix = <0xb7 + 0x02> <0x03> <0xc8>

RLP("a"*1000) = 0xb9 03 c8 616161616...

해당 케이스에서 prefix는 0xbf까지 사용되며 최대 문자열길이는 (2^64) - 1까지 됩니다. 0xbf면 8바이트만큼 문자열 길이를 의미합니다.

0xbf ff ff ff ff ff ff ff ff 문자열 인코딩값

· 네 번째 케이스 - 배열의 모든 아이템들의 RLP 인코딩 된 값들의 길이가 55보다 작을 때

해당 케이스는 0xc0을 prefix로 사용합니다. 즉, 0xc0을 시작으로 인코딩 값을 이어붙입니다.

prefix의 범위는 0xc1 ~ 0xf7입니다.

▶ 배열의 모든 아이템들이 RLP 인코딩된 값의 길이를 더하고 각각의 요소를 인코딩 한 요소를 이어 붙입니다.

["ab"]을 인코딩하면

먼저, ab를 인코딩 합니다. RLP("ab") = 0x826162

인코딩된 값의 길이 = 3 = 0x03

prefix = 0xc0 + 0x03 = 0xc3

RLP(["ab"]) = 0xc3826162

["ab", "cd"] 을 인코딩하면

먼저 "ab"와 "cd"를 각각 RLP 인코딩합니다.

ab = 0x82 0x61 0x62 = 3자리

cd = 0x82 0x63 0x64 = 3자리

배열 요소의 인코딩 결과 길이 = 6 = 0x06

prefix = 0xc0 + 0x06

RLP(["ab", "cd"]) = 0xc6 826162 826364

· 다섯 번째 케이스 - 배열의 모든 아이템이 RLP 인코딩 된 값들의 길이가 55보다 클 때

해당 케이스는 0xf7을 prefix로 사용합니다.

prefix의 범위는 0xf8 ~ 0xff 입니다.

▶ prefix에 배열 요소들의 RLP 인코딩 값들의 길이를 표현한 값의 길이를 더하고 아스키 코드값으로 변환하여 붙입니다 (설명이 개떡같죠? 아래의 인코딩 예시를 보면 이해하기 어렵지 않습니다. 세 번째 케이스와 유사한 형태).

["a" * 50, "a" * 50]을 인코딩하면

먼저 "a" * 50을 인코딩 합니다. => 해당 인코딩은 문자열이기 때문에 길이에 따라 2, 3규칙을 적용합니다.

"a" * 50 = 0x80 + 0x32(50의 16진수) = 0xb2 61(50개)

길이 = 0xb2 61(50개) 0xb2 61(50개) = 102(0x66)자리

102는 1바이트이며 0x66입니다

prefix = 0xf7 + 1 + "f" = 0xf8f

RLP(["a" * 50, "a" * 50]) = 0xf8 0x66 0xb2 61(50개) 0xb2 61(50개)

● RLP 디코딩

인코딩인 5가지 케이스가 있는것처럼 디코딩도 5가지 케이스가 있습니다.

· 첫 번째 규칙: 첫 번째 바이트가 0x00 ~ 0x7f

값 자체가 문자 데이터

· 두 번째 규칙: 첫 번째 바이트가 0x80 ~ 0xb7

해당 범위로 시작하면 문자열을 의미합니다.

첫 번째 바이트에서 0x80을 뺀 값이 문자열의 길이입니다.

· 세 번째 규칙: 첫 번째 바이트가 0xb8 ~ 0xbf

해당범위로 시작하면 55바이트를 초과한 문자열을 의미합니다.

첫 번째 바이트에서 0xb7을 뺀 값이 바이트로 표현된 RLP 아이템 갯수입니다. RLP 아이템 갯수만큼 인코딩된 문자가 이어집니다.

· 네 번째 규칙: 첫 번째 바이트가 0xc0 ~ 0xf7

해당 범위로 시작하면 배열을 의미합니다.

첫 번째 바이트에서 0xc0를 뺀 값이 배열의 요소 갯수를 의미합니다.

· 다섯 번째 규칙: 첫 번째 바이트가 0xf8 ~ 0xff

해당 범위로 시작하면 배열의 요소 합이 55바이트를 초과한 배열을 의미합니다.

첫 번째 바이트에서 0xf7을 뺀 값이 배열의 길이를 표현한 바이트의 갯수를 의미합니다.

0xf8 0x66 0xb2 61(50개) 0xb2 61(50개) 에서

0xf8 - 0xf7 = 0x01

뒤에 나오는 0x01(1) 만큼 배열의 길이를 의미하는 바이트가 있음

0x66(102) 만큼 배열 요소를 의미

0xb2 0x61(50개) 0xb2 0x61(50개) => 해당 값은 두 번째 규칙으로 디코딩할 수 있다.

● RLP 인코딩의 한계

RLP 인코딩은 문자열과 배열 타입만 구분합니다.

한 가지 예시를 들어보겠습니다.

숫자 24,930을 RLP 인코딩을 수행하기 위해 해당수를 16진수로 바꿔야 합니다.

16진수로 바꾸고 바이트로 끊으면 2진수(1100001 01100010) -> 16진수(0x61 0x62)가 됩니다.

☞ RLP(24,930) = 0x826162

해당 결과는 RLP("ab")와 동일합니다. 이더리움에서는 이러한 문제를 해결하기 위해 24,930이 아니라 "24930"으로 처리합니다.

[ethereum] web3와 ethers를 이용하여 메타마스크로 트랜잭션 발생하기

멍개. — Sun, 28 Aug 2022 08:18:19 +0900

web3와 ethers으로 메타마스크를 이용하여 트랜잭션을 발생하는 방법을 알아보겠습니다.

확장프로그램 메타마스크가 설치되어 있다면 메타마스크 프로바이더가 window 객체에 ethereum으로 포함되어 있습니다. 근데 vanilaJS로는 window.ethereum 포함된것을 가지고 오기가 좀 까다로우므로 react에서 발생시켜보겠습니다.

window.web3.currentProvider(레거시) 또는 window.ethereum(현재버전)으로 가져오면 됩니다.

● ethers

provider에 메타마스크 프로바이더를 넣어줍니다.

window?.web3?.currentProvider

window.ethereum

import { providers, Wallet, utils, Contract } from "ethers";

function App() {
  
  const clickHandler = async () => {
    const provider = new providers.Web3Provider(
      window.ethereum || 'http://localhost:8545'
    );
    const signer = provider.getSigner(); // 메타마스크에 선택된 지갑으로 트랜잭션 서명을 함
    console.log(signer)
    
    const txHash = await signer.sendTransaction({
      from: signer.address,
      to: '0xAd46355359aE32263EaFE152a408D9D620844eda',
      value: utils.parseUnits('0.1', 'ether').toHexString()
    })

    console.log(txHash)
  }
  return (
    <div className="App">
      <button onClick={clickHandler}>
        클릭
      </button>
    </div>
  );
}

export default App;

· 메타마스크 로그인이 정상적으로 되었을 때

버튼을 누르면 메타마스크로 트랜잭션 발생을 시키기 위해 팝업을 띄웁니다.

· 메타마스크 로그인이 되어있지 않을 때

메타마스크에서 정상적으로 로그인이 되어있지 않았다면 다음과 같이 에러가 발생합니다.

index.ts:261 Uncaught (in promise) Error: unknown account #0 (operation="getAddress", code=UNSUPPORTED_OPERATION, version=providers/5.6.8)
    at Logger.makeError (index.ts:261:1)
    at Logger.throwError (index.ts:273:1)
    at json-rpc-provider.ts:204:1
    at async Promise.all (:3000/index 1)

· 트랜잭션 승인창에서 확인이 아니라 거부를 눌렀을 때

code가 4001인 오브젝트를 exception으로 발생합니다.

{
    "code": 4001,
    "message": "MetaMask Tx Signature: User denied transaction signature."
}

{
    "code": 4001,
    "message": "MetaMask Tx Signature: User denied transaction signature.",
    "stack": "{\n  \"code\": 4001,\n  \"message\": \"MetaMask Tx Signature: User denied transaction signature.\",\n  \"stack\": \"Error: MetaMask Tx Signature: User denied transaction signature.\\n    at new i (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-2.js:1:308657)\\n    at new o.EthereumProviderError (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-2.js:1:309172)\\n    at c (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-2.js:1:311507)\\n    at Object.userRejectedRequest (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-2.js:1:312738)\\n    at y.<anonymous> (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/background-4.js:1:30538)\\n    at Object.l (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-3.js:10:9069)\\n    at u (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-7.js:3:1144)\\n    at a.emit (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-7.js:3:1680)\\n    at y._setTransactionStatus (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/background-4.js:1:76051)\\n    at y.setTxStatusRejected (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/background-4.js:1:74238)\\n    at z.cancelTransaction (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/background-4.js:1:46625)\\n    at s.<anonymous> (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/background-4.js:22:11434)\\n    at l (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-1.js:20:210820)\\n    at s.emit (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-1.js:20:213815)\\n    at w (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-7.js:1:41385)\\n    at v (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-7.js:1:41200)\\n    at b.push (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-7.js:1:42014)\\n    at t.exports._write (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-6.js:8:435312)\\n    at b (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-7.js:1:54430)\\n    at chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-7.js:1:57614\\n    at y.write (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-7.js:1:57641)\\n    at e.exports.m (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-7.js:1:46585)\\n    at l (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-1.js:20:210820)\\n    at s.emit (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-1.js:20:213815)\\n    at w (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-7.js:1:41385)\\n    at v (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-7.js:1:41200)\\n    at b.push (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-7.js:1:42014)\\n    at e.exports._onMessage (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-3.js:10:14413)\\n    at chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-3.js:10:14260\"\n}\n  at new i (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-2.js:1:308657)\n  at new o.EthereumProviderError (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-2.js:1:309172)\n  at c (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-2.js:1:311507)\n  at Object.userRejectedRequest (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-2.js:1:312738)\n  at y.<anonymous> (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/background-4.js:1:30538)\n  at Object.l (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-3.js:10:9069)\n  at u (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-7.js:3:1144)\n  at a.emit (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-7.js:3:1680)\n  at y._setTransactionStatus (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/background-4.js:1:76051)\n  at y.setTxStatusRejected (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/background-4.js:1:74238)\n  at z.cancelTransaction (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/background-4.js:1:46625)\n  at s.<anonymous> (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/background-4.js:22:11434)\n  at l (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-1.js:20:210820)\n  at s.emit (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-1.js:20:213815)\n  at w (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-7.js:1:41385)\n  at v (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-7.js:1:41200)\n  at b.push (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-7.js:1:42014)\n  at t.exports._write (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-6.js:8:435312)\n  at b (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-7.js:1:54430)\n  at chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-7.js:1:57614\n  at y.write (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-7.js:1:57641)\n  at e.exports.m (chrome-extension://nkbihfbeogaeaoehlefnkodbef

● web3js

리엑트 최신 버전에서는 web3가 정상적으로 임포트되지 않습니다.

2022.08.28 - [블록체인] - [dapp] react에서 web3js 정상적으로 사용하기

[dapp] react에서 web3js 정상적으로 사용하기

최신 리액트 버전에서 web3를 사용할 때 다음과 같이 에러가 발생합니다. // src/App.js import Web3 from 'web3'; // 에러발생 지점 function App() { const onClickHandler = async () => { const web3 = new We..

meongae.tistory.com

provider에 메타마스크 프로바이더를 넣어줍니다.

window?.web3?.currentProvider

window.ethereum

import Web3 from 'web3';

function App() {

  const clickHandler = async () => {

    const web3 = new Web3(
      window.ethereum || 'http://localhost:8545'
    );
    const accounts = await web3.eth.requestAccounts(); // 메타마스크에 선택된 지갑으로 트랜잭션 서명을 함 
    console.log(accounts);

    const tx = await web3.eth.sendTransaction({
      from: accounts[0],
      to: '0xAd46355359aE32263EaFE152a408D9D620844eda',
      value: web3.utils.toWei('0.1', 'ether'),
      data: ''
    })
    console.log(tx)
  }

  return (
    <div className="App">
      <button onClick={clickHandler}>클릭</button>
    </div>
  );
}

export default App;

· 메타마스크 로그인이 정상적으로 되었을 때

· 메타마스크 로그인이 되어있지 않을 때

web3의 경우는 메타마스크 로그인창을 띄웁니다.

여기서 로그인을 하게되면 다음과 같이 트랜잭션 확인창을 띄워줍니다.

· 트랜잭션 승인창에서 확인이 아니라 거부를 눌렀을 때

code가 4001인 오브젝트를 exception으로 발생합니다.

{
    "code": 4001,
    "message": "MetaMask Tx Signature: User denied transaction signature."
}

{
    "code": 4001,
    "message": "MetaMask Tx Signature: User denied transaction signature.",
    "stack": "{\n  \"code\": 4001,\n  \"message\": \"MetaMask Tx Signature: User denied transaction signature.\",\n  \"stack\": \"Error: MetaMask Tx Signature: User denied transaction signature.\\n    at new i (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-2.js:1:308657)\\n    at new o.EthereumProviderError (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-2.js:1:309172)\\n    at c (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-2.js:1:311507)\\n    at Object.userRejectedRequest (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-2.js:1:312738)\\n    at y.<anonymous> (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/background-4.js:1:30538)\\n    at Object.l (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-3.js:10:9069)\\n    at u (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-7.js:3:1144)\\n    at a.emit (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-7.js:3:1680)\\n    at y._setTransactionStatus (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/background-4.js:1:76051)\\n    at y.setTxStatusRejected (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/background-4.js:1:74238)\\n    at z.cancelTransaction (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/background-4.js:1:46625)\\n    at s.<anonymous> (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/background-4.js:22:11434)\\n    at l (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-1.js:20:210820)\\n    at s.emit (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-1.js:20:213815)\\n    at w (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-7.js:1:41385)\\n    at v (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-7.js:1:41200)\\n    at b.push (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-7.js:1:42014)\\n    at t.exports._write (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-6.js:8:435312)\\n    at b (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-7.js:1:54430)\\n    at chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-7.js:1:57614\\n    at y.write (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-7.js:1:57641)\\n    at e.exports.m (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-7.js:1:46585)\\n    at l (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-1.js:20:210820)\\n    at s.emit (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-1.js:20:213815)\\n    at w (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-7.js:1:41385)\\n    at v (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-7.js:1:41200)\\n    at b.push (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-7.js:1:42014)\\n    at e.exports._onMessage (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-3.js:10:14413)\\n    at chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-3.js:10:14260\"\n}\n  at new i (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-2.js:1:308657)\n  at new o.EthereumProviderError (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-2.js:1:309172)\n  at c (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-2.js:1:311507)\n  at Object.userRejectedRequest (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-2.js:1:312738)\n  at y.<anonymous> (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/background-4.js:1:30538)\n  at Object.l (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-3.js:10:9069)\n  at u (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-7.js:3:1144)\n  at a.emit (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-7.js:3:1680)\n  at y._setTransactionStatus (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/background-4.js:1:76051)\n  at y.setTxStatusRejected (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/background-4.js:1:74238)\n  at z.cancelTransaction (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/background-4.js:1:46625)\n  at s.<anonymous> (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/background-4.js:22:11434)\n  at l (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-1.js:20:210820)\n  at s.emit (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-1.js:20:213815)\n  at w (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-7.js:1:41385)\n  at v (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-7.js:1:41200)\n  at b.push (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-7.js:1:42014)\n  at t.exports._write (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-6.js:8:435312)\n  at b (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-7.js:1:54430)\n  at chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-7.js:1:57614\n  at y.write (chrome-extension://nkbihfbeogaeaoehlefnkodbefgpgknn/common-7.js:1:57641)\n  at e.exports.m (chrome-extension://nkbihfbeogaeaoehlefnkodbef

[dapp] react에서 web3js 정상적으로 사용하기

멍개. — Sun, 28 Aug 2022 08:14:59 +0900

최신 리액트 버전에서 web3를 사용할 때 다음과 같이 에러가 발생합니다.

// src/App.js

import Web3 from 'web3'; // 에러발생 지점

function App() {

  const onClickHandler = async () => {

    const web3 = new Web3(
      window?.web3?.currentProvider //  메타마스크 프로바이더
      || 'http://localhost:8545'
    );
    const accounts = await web3.eth.requestAccounts();
    console.log(accounts)
    const tx = await web3.eth.sendTransaction({
      from: accounts[0],
      to: '0xAd46355359aE32263EaFE152a408D9D620844eda',
      value: web3.utils.toWei('1', 'ether'),
      data: ''
    })
    console.log(tx)
  }

  return (
    <div className="App">
      <button onClick={onClickHandler}>Send</button>
    </div>
  );
}

export default App;

web3를 import하는 지점에서 에러가 발생합니다.

최신 CRA에서 정상적으로 폴리필이 동작하지 않아 생기는 문제입니다.

$ npx create-react-app [프로젝트 이름]

$ npm install web3 web3-utils

추가 의존성 설치

$ npm install --save-dev react-app-rewired crypto-browserify stream-browserify assert stream-http https-browserify os-browserify url buffer process

웹팩 오버라이딩 하기

config-overrides.js

const webpack = require('webpack');

module.exports = function override(config) {
    const fallback = config.resolve.fallback || {};
    Object.assign(fallback, {
        "crypto": require.resolve("crypto-browserify"),
        "stream": require.resolve("stream-browserify"),
        "assert": require.resolve("assert"),
        "http": require.resolve("stream-http"),
        "https": require.resolve("https-browserify"),
        "os": require.resolve("os-browserify"),
        "url": require.resolve("url")
    })
    config.resolve.fallback = fallback;
    config.plugins = (config.plugins || []).concat([
        new webpack.ProvidePlugin({
            process: 'process/browser',
            Buffer: ['buffer', 'Buffer']
        })
    ])
    return config;
}

package.json script 수정

  "scripts": {
    "start": "react-app-rewired start",
    "build": "react-app-rewired build",
    "test": "react-app-rewired test",
    "eject": "react-scripts eject"
  },

다시 실행하면 정상적으로 동작하는 모습을 볼 수 있습니다.

[ethereum] web3.js와 같은 ethers 알아보기

멍개. — Sun, 28 Aug 2022 08:13:28 +0900

ethers는 web3.js처럼 이더리움 네트워크를 조회하고 조작할 수 있는 인터페이스를 제공하는 라이브러리입니다. 그렇다면 web3.js대신 ethers.js를 사용해야하는 이유는 무엇일까?

ethers는 provider와 signer를 주입하는 형태로 유연한 코드 작성이 가능하다고 생각합니다.

· 설치

$ npm install --save ethers

ethers는 크게 4개의 객체를 제공합니다.

▶ CommonJS

const { providers, Wallet, utils, Contract } = require('ethers');

▶ ESM

import { providers, Wallet, utils, Contract } from "ethers";

▶ CDN

<script type="module">
    import { providers, Wallet, utils, Contract } from "https://cdn.ethers.io/lib/ethers-5.2.esm.min.js";
</script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/ethers/5.6.9/ethers.umd.min.js" integrity="sha512-Veaz5IU2iRpa0BBrJlJeRgfJ7OAHWtVJZTXvgdH7s3ffsLUChllMCqC0Bb+eeRxGlrZ06iYIE/R3KsciCrgv3A==" crossorigin="anonymous" referrerpolicy="no-referrer">
</script>

<script>
  const { providers, Wallet, utils, Contract } = ethers.ethers;
</script>

● providers

providers는 이더리움 노드와 연결합니다. 블록, 트랜잭션 조회등을 수행할 수 있습니다.

· 노드연결

const provider = new providers.JsonRpcProvider(url);

const provider = new providers.JsonRpcProvider('http://localhost:8545');

만약, metamask의 provider를 이용하고 싶다면 다음과 같이 이용할 수 있습니다.

const provider = new ethers.providers.Web3Provider(window.ethereum)

· 최근 블록번호 조회

const block = await provider.getBlockNumber()

· 블록조회

const block0 = await provider.getBlock(0)

{
  hash: '0xe4b7283f03a18236615e883d91595dc6cf12119ed14d0179c7e29f5f80f2c94d',
  parentHash: '0x0000000000000000000000000000000000000000000000000000000000000000',
  number: 0,
  timestamp: 1650158272,
  nonce: '0x0000000000000000',
  difficulty: 0,
  gasLimit: BigNumber { _hex: '0x6691b7', _isBigNumber: true },
  gasUsed: BigNumber { _hex: '0x00', _isBigNumber: true },
  miner: '0x0000000000000000000000000000000000000000',
  extraData: '0x',
  transactions: [], 
  _difficulty: BigNumber { _hex: '0x00', _isBigNumber: true }
}

const txs = await provider.getBlockWithTransactions(0)
{
  hash: '0xe4b7283f03a18236615e883d91595dc6cf12119ed14d0179c7e29f5f80f2c94d',
  parentHash: '0x0000000000000000000000000000000000000000000000000000000000000000',
  number: 0,
  timestamp: 1650158272,
  nonce: '0x0000000000000000',
  difficulty: 0,
  gasLimit: BigNumber { _hex: '0x6691b7', _isBigNumber: true },
  gasUsed: BigNumber { _hex: '0x00', _isBigNumber: true },
  miner: '0x0000000000000000000000000000000000000000',
  extraData: '0x',
  transactions: [],
  _difficulty: BigNumber { _hex: '0x00', _isBigNumber: true }
}

getBlock과 getBlockWithTransactions의 차이는 transactions에 있습니다. getBlock은 트랜잭션 해시 목록을 가지고 있으며 getBlockWithTransactions는 트랜잭션 객체목록을 가지고 있습니다.

· 트랜잭션 조회

const tx = await provider.getTransaction("0x5b73e239c55d790e3c9c3bbb84092652db01bb8dbf49ccc9e4a318470419d9a0");
{
  accessList: null,
  blockHash: '0x8a179bc6cb299f936c4fd614995e62d597ec6108b579c23034fb220967ceaa94',
  blockNumber: 12598244,
  chainId: 1,
  confirmations: 1869134,
  creates: '0x733aF852514e910E2f8af40d61E00530377889E9',
  data: '0x608060405234801561001057600080fd5b5060405161062438038061062483398101604081905261002f916100cd565b60405163c47f002760e01b815260206004820152600d60248201526c0daead8e8d2c6c2d8d85ccae8d609b1b60448201526001600160a01b0382169063c47f002790606401602060405180830381600087803b15801561008e57600080fd5b505af11580156100a2573d6000803e3d6000fd5b505050506040513d601f19601f820116820180604052508101906100c691906100fb565b5050610113565b6000602082840312156100de578081fd5b81516001600160a01b03811681146100f4578182fd5b9392505050565b60006020828403121561010c578081fd5b5051919050565b610502806101226000396000f3fe608060405234801561001057600080fd5b506004361061002b5760003560e01c80634c0770b914610030575b600080fd5b61004361003e366004610309565b61005b565b60405161005293929190610389565b60405180910390f35b600060608085841461006c57600080fd5b8567ffffffffffffffff81111561009357634e487b7160e01b600052604160045260246000fd5b6040519080825280602002602001820160405280156100bc578160200160208202803683370190505b5091508567ffffffffffffffff8111156100e657634e487b7160e01b600052604160045260246000fd5b60405190808252806020026020018201604052801561011957816020015b60608152602001906001900390816101045790505b50905060005b86811015610235576101cd8a8a8a8a8581811061014c57634e487b7160e01b600052603260045260246000fd5b905060200201602081019061016191906102db565b89898681811061018157634e487b7160e01b600052603260045260246000fd5b90506020028101906101939190610460565b8080601f01602080910402602001604051908101604052809392919081815260200183838082843760009201919091525061024592505050565b8483815181106101ed57634e487b7160e01b600052603260045260246000fd5b6020026020010184848151811061021457634e487b7160e01b600052603260045260246000fd5b6020908102919091010191909152528061022d816104a5565b91505061011f565b5043925096509650969350505050565b6000606060405190506000815260208101604052600080845160208601878afa9150843d101561028857603f3d01601f191681016040523d81523d6000602083013e5b94509492505050565b60008083601f8401126102a2578182fd5b50813567ffffffffffffffff8111156102b9578182fd5b6020830191508360208260051b85010111156102d457600080fd5b9250929050565b6000602082840312156102ec578081fd5b81356001600160a01b0381168114610302578182fd5b9392505050565b60008060008060008060808789031215610321578182fd5b8635955060208701359450604087013567ffffffffffffffff80821115610346578384fd5b6103528a838b01610291565b9096509450606089013591508082111561036a578384fd5b5061037789828a01610291565b979a9699509497509295939492505050565b60006060820185835260206060818501528186518084526080860191508288019350845b818110156103c9578451835293830193918301916001016103ad565b5050848103604086015285518082528282019350600581901b82018301838801865b8381101561045057601f1980868503018852825180518086528a5b81811015610421578281018a01518782018b01528901610406565b81811115610431578b8a83890101525b5098880198601f019091169390930186019250908501906001016103eb565b50909a9950505050505050505050565b6000808335601e19843603018112610476578283fd5b83018035915067ffffffffffffffff821115610490578283fd5b6020019150368190038213156102d457600080fd5b60006000198214156104c557634e487b7160e01b81526011600452602481fd5b506001019056fea264697066735822122083b5dc25b3c9256aa4244eddaf9e4b5fccd09a45ec4e0174f2c900de7144602d64736f6c63430008040033000000000000000000000000084b1c3c81545d370f3634392de611caabff8148',
  from: '0x8ba1f109551bD432803012645Ac136ddd64DBA72',
  gasLimit: { BigNumber: "443560" },
  gasPrice: { BigNumber: "10100000000" },
  hash: '0x5b73e239c55d790e3c9c3bbb84092652db01bb8dbf49ccc9e4a318470419d9a0',
  nonce: 745,
  r: '0xaf2b969de6dfb234fb8843f47a029636abb1ef52f26bb8bb615bbabcf23808e9',
  s: '0x3dd61cd8df015e0af5689a249dd3224ee71f2b04917b7b4c14f7e68bb3a4ec17',
  to: null,
  transactionIndex: 315,
  type: 0,
  v: 38,
  value: { BigNumber: "0" },
  wait: [Function]
}

const tx = await provider.getTransactionReceipt("0x5b73e239c55d790e3c9c3bbb84092652db01bb8dbf49ccc9e4a318470419d9a0");

{
  blockHash: '0x8a179bc6cb299f936c4fd614995e62d597ec6108b579c23034fb220967ceaa94',
  blockNumber: 12598244,
  byzantium: true,
  confirmations: 1869134,
  contractAddress: '0x733aF852514e910E2f8af40d61E00530377889E9',
  cumulativeGasUsed: { BigNumber: "12102324" },
  effectiveGasPrice: { BigNumber: "10100000000" },
  from: '0x8ba1f109551bD432803012645Ac136ddd64DBA72',
  gasUsed: { BigNumber: "443560" },
  logs: [
    {
      address: '0x00000000000C2E074eC69A0dFb2997BA6C7d2e1e',
      blockHash: '0x8a179bc6cb299f936c4fd614995e62d597ec6108b579c23034fb220967ceaa94',
      blockNumber: 12598244,
      data: '0x000000000000000000000000084b1c3c81545d370f3634392de611caabff8148',
      logIndex: 160,
      topics: [
        '0xce0457fe73731f824cc272376169235128c118b49d344817417c6d108d155e82',
        '0x91d1777781884d03a6757a803996e38de2a42967fb37eeaca72729271025a9e2',
        '0x4774f6d3b3d08b5ec00115f0e2fddb92604b39e52b0dc908c6f8fcb7aa5d2a9a'
      ],
      transactionHash: '0x5b73e239c55d790e3c9c3bbb84092652db01bb8dbf49ccc9e4a318470419d9a0',
      transactionIndex: 315
    },
    {
      address: '0x00000000000C2E074eC69A0dFb2997BA6C7d2e1e',
      blockHash: '0x8a179bc6cb299f936c4fd614995e62d597ec6108b579c23034fb220967ceaa94',
      blockNumber: 12598244,
      data: '0x000000000000000000000000a2c122be93b0074270ebee7f6b7292c7deb45047',
      logIndex: 161,
      topics: [
        '0x335721b01866dc23fbee8b6b2c7b1e14d6f05c28cd35a2c934239f94095602a0',
        '0x790fdce97f7b2b1c4c5a709fb6a49bf878feffcaa85ed0245f6dff09abcefda7'
      ],
      transactionHash: '0x5b73e239c55d790e3c9c3bbb84092652db01bb8dbf49ccc9e4a318470419d9a0',
      transactionIndex: 315
    }
  ],
  logsBloom: '0x00000000000000000000000000000000000000000000000000000000000000000800000000000000000000000000004000000000000010000000000000020000000000000000000040000000000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000000000000040000000000000000100004000000000000008000040000000000000000000000000000000000005000000000041000000000000000000000000000000000000000000000000100000000000000001000000000000000000000',
  status: 1,
  to: null,
  transactionHash: '0x5b73e239c55d790e3c9c3bbb84092652db01bb8dbf49ccc9e4a318470419d9a0',
  transactionIndex: 315,
  type: 0
}

· 이더조회

const balance = await provider.getBalance('0x86B6acf21e6F4aE60bbAdFDBc4F5D00741823d17')

BigNumber { _hex: '0x056bc75e2d63100000', _isBigNumber: true }

단위변경은 utils를 이용하면 됩니다.

· 수수료 조회

트랜잭션을 만들기 위해 필요한 수수료 조회 메서드입니다. 이는 EIP1559 방식을 기준으로 조회합니다.

const fee = await provider.getFeeData();

{
  maxFeePerGas: null,
  maxPriorityFeePerGas: null,
  gasPrice: BigNumber { _hex: '0x04a817c800', _isBigNumber: true }
}

maxFeePerGas와 maxPriorityFeePerGas 모두 gasPrice와 같은 데이터 타입을 가집니다.

· 수수료 추청

트랜잭션이 정상적으로 실행되었을 때 사용되는 가스량 추청을 할 수 있습니다.

await provider.estimateGas({
  to: "0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2",   // Wrapped ETH address
  data: "0xd0e30db0",   // `function deposit() payable`
  value: parseEther("1.0")   // 1 ether
});

{ BigNumber: "27938" }

· nonce 조회

nonce란 발생된 트랜잭션 수 입니다.

const address = '0x86B6acf21e6F4aE60bbAdFDBc4F5D00741823d17';
const nonce = await provider.getTransactionCount(address, "latest")

0

· 트랜잭션 발생

const signedTx = "0xf8690401825208945555763613a12d8f3e73be831dff8598089d3dca882b992b75cbeb600080820a96a0e3767d1e99c6090a5d00532fe11e2acf3be9228f1f8df7ce9d3c5c6ca3dac151a0594869ee73fbf7394c82e080b1bc734536b67832d2abab5b7bedc79f297bb338";
await provider.sendTransaction(signedTx);

{
  chainId: 1337,
  confirmations: 0,
  data: '0x',
  from: '0x77C44C0D1D37050e9250415Ee96401B5ac270856',
  gasLimit: { BigNumber: "21000" },
  gasPrice: { BigNumber: "1" },
  hash: '0x1c392c05e5f293ce4e1367101233513ce09575c67d7f3ee519d59c2d22b9dde9',
  nonce: 4,
  r: '0xe3767d1e99c6090a5d00532fe11e2acf3be9228f1f8df7ce9d3c5c6ca3dac151',
  s: '0x594869ee73fbf7394c82e080b1bc734536b67832d2abab5b7bedc79f297bb338',
  to: '0x5555763613a12D8F3e73be831DFf8598089d3dCa',
  type: null,
  v: 2710,
  value: { BigNumber: "3141590000000000000" },
  wait: [Function]
}

서명된 트랜잭은 다음과 같이 만들 수 있습니다.

const signer = Wallet.createRandom()
const signed = await signer.signTransaction({
  to: '0x6BAE09696c44D0fcF157Cf72b1930632AF435A97',
  from: signer.address,
  value: utils.parseEther('0.1'),
})

await provider.sendTransaction(signedTx);

또한 sendTransaction은 서명된 문자열이 아닌 오브젝트를 받을 수 있습니다. 이때 from은 생성된 지갑주소가 들어갑니다. wallet을 생성하고 니모닉, 키스토어 파일, 개인키를 이용하여 복구하는 방법은 아래에서 다룹니다.

const signer = Wallet.createRandom()

const txHash = await signer.sendTransaction({
  to: '0xAd46355359aE32263EaFE152a408D9D620844eda',
  value: utils.parseUnits('0.1', 'ether').toHexString()
})

· 이벤트 수신

provider.on('block', (block) => {
  console.log(block)
})

1
2
3

해당 네트워크에 블록이 생성되면 생성된 블록번호를 전달받습니다.

provider.on("pending", (tx) => {
  console.log(tx)
});

{
  hash: '0x5a224e5f2ab73bfbe382dda2260adb8c5e2957606991b8b9b2ab7c33324c8323',
  type: 0,
  accessList: null,
  blockHash: '0xb13106233b4173006fda0e39bd2af24264d49f1b88f2f828b0b4f1fd3fee77b6',
  blockNumber: 9,
  transactionIndex: 0,
  confirmations: 1,
  from: '0x86B6acf21e6F4aE60bbAdFDBc4F5D00741823d17',
  gasPrice: BigNumber { _hex: '0x04a817c800', _isBigNumber: true },
  gasLimit: BigNumber { _hex: '0x011a59', _isBigNumber: true },
  to: null,
  value: BigNumber { _hex: '0x00', _isBigNumber: true },
  nonce: 8,
  data: '0x60566050600b82828239805160001a6073146043577f4e487b7100000000000000000000000000000000000000000000000000000000600052600060045260246000fd5b30600052607381538281f3fe73000000000000000000000000000000000000000030146080604052600080fdfea264697066735822122024e006b709493803f07277c09b5c327910ed1595e233a5d24959eacff659640364736f6c634300080d0033',
  r: '0xa93dc61c988f92aba88db265bdcd03e8412066c2d2b409c97b34ab8da882aa1a',
  s: '0x71babaf613b91c91a6979661dae2f28dfb1d5e7f9e9c2abbac7d84f5e286a516',
  v: 38,
  creates: '0x85E8E89867bc699278Da7276d32E4fd856B3Afc8',
  chainId: 1,
  wait: [Function (anonymous)]
}

팬딩중인 트랜잭션을 수신합니다.

● Wallet

Wallet은 개인키/공개키를 관리합니다.

· 키(주소) 생성

const signer = Wallet.createRandom()

console.log(signer)
console.log(signer._signingKey())
console.log(signer._mnemonic())

Wallet {
  _isSigner: true,
  _signingKey: [Function (anonymous)],
  address: '0xf3a1F20176cd7F877737012ca8FCd3e32B5bbc81',
  _mnemonic: [Function (anonymous)],
  provider: null
}
SigningKey {
  curve: 'secp256k1',
  privateKey: '0xc9ea026885ea45fd27d06049614bc1e6474fd5208dcd008a25e4f5c8297a11fd',
  publicKey: '0x0462c4b51b0a8623510168d1ac42d8731bbd38b6aa3c037b96782b987e76d695913efa32b8552d42c51fd7dc2c6ff06c8e17d75beeda5e55fa7da955850fe50ef4',
  compressedPublicKey: '0x0262c4b51b0a8623510168d1ac42d8731bbd38b6aa3c037b96782b987e76d69591',
  _isSigningKey: true
}
{
  phrase: 'clown unveil parrot rebuild trial convince box glass gun trumpet garbage electric',
  path: "m/44'/60'/0'/0/0",
  locale: 'en'
}

create 메서드를 이용하면 키스토어를 생성할 수 있습니다.

const password = '123456'
const signer = Wallet.createRandom()
const keystore = await signer.encrypt(password);
console.log(keystore)

{"address":"84db1f6c4b16cda79f4dc34404445fabe55b97bf","id":"fb49150e-baa5-4325-a3c1-4f8547c118cb","version":3,"Crypto":{"cipher":"aes-128-ctr","cipherparams":{"iv":"39fe92c0b9ccba464e25e63686695f05"},"ciphertext":"476c18b348830e566c815df1669e281e45777e282494deea857425864b778421","kdf":"scrypt","kdfparams":{"salt":"a4f06b8ee274dbb763e540cf93d3cded6ceaa43a928381c463767b7e2ee76f33","n":131072,"dklen":32,"p":1,"r":8},"mac":"3aed307763f9e53e5f3bd9533922546c554fbf8db20608c99a08103c18d7e924"},"x-ethers":{"client":"ethers.js","gethFilename":"UTC--2022-04-17T02-06-38.0Z--84db1f6c4b16cda79f4dc34404445fabe55b97bf","mnemonicCounter":"08d67dd51426a9488c97ed1ca75f3e82","mnemonicCiphertext":"b9c25a345f6bef62ea2fc287c1cc123c","path":"m/44'/60'/0'/0/0","locale":"en","version":"0.1"}}

· 지갑복구

지갑 복구는 크게 3가지 방법이 있습니다. 개인키 복구, 키스토어 파일 복구, 니모닉 복구

▶ 개인키 복구

const pk = '0xe6deaed561bbeb9ebc1941b10beb9ff060060d9ea637554abe475eb8f1b13ddc';
const signer = new Wallet(pk)
console.log(signer)

Wallet {
  _isSigner: true,
  _signingKey: [Function (anonymous)],
  _mnemonic: [Function (anonymous)],
  address: '0x86B6acf21e6F4aE60bbAdFDBc4F5D00741823d17',
}

▶ 키스토어 파일 복구

const password = '123456'
const keystore = {"address":"84db1f6c4b16cda79f4dc34404445fabe55b97bf","id":"fb49150e-baa5-4325-a3c1-4f8547c118cb","version":3,"Crypto":{"cipher":"aes-128-ctr","cipherparams":{"iv":"39fe92c0b9ccba464e25e63686695f05"},"ciphertext":"476c18b348830e566c815df1669e281e45777e282494deea857425864b778421","kdf":"scrypt","kdfparams":{"salt":"a4f06b8ee274dbb763e540cf93d3cded6ceaa43a928381c463767b7e2ee76f33","n":131072,"dklen":32,"p":1,"r":8},"mac":"3aed307763f9e53e5f3bd9533922546c554fbf8db20608c99a08103c18d7e924"},"x-ethers":{"client":"ethers.js","gethFilename":"UTC--2022-04-17T02-06-38.0Z--84db1f6c4b16cda79f4dc34404445fabe55b97bf","mnemonicCounter":"08d67dd51426a9488c97ed1ca75f3e82","mnemonicCiphertext":"b9c25a345f6bef62ea2fc287c1cc123c","path":"m/44'/60'/0'/0/0","locale":"en","version":"0.1"}}
const signer = await Wallet.fromEncryptedJson(JSON.stringify(keystore), password)
console.log(signer)

Wallet {
  _isSigner: true,
  _signingKey: [Function (anonymous)],
  address: '0x84db1f6c4B16CdA79F4dc34404445fabE55B97bF',
  _mnemonic: [Function (anonymous)],
  provider: null
}

▶ 니모닉 복구

const mnemonic = "announce room limb pattern dry unit scale effort smooth jazz weasel alcohol"
const signer = Wallet.fromMnemonic(mnemonic)
console.log(signer)

Wallet {
  _isSigner: true,
  _signingKey: [Function (anonymous)],
  address: '0x71CB05EE1b1F506fF321Da3dac38f25c0c9ce6E1',
  _mnemonic: [Function (anonymous)],
  provider: null
}

· 서명하기

서명은 트랜잭션 서명과 메시지 서명이 있습니다.

▶ 트랜잭션 서명

const signer = Wallet.createRandom()
const signed = await signer.signTransaction({
  to: '0x6BAE09696c44D0fcF157Cf72b1930632AF435A97',
  from: signer.address,
  value: utils.parseEther('0.1'),
})
console.log(signed)

0xf865808080946bae09696c44d0fcf157cf72b1930632af435a9788016345785d8a0000801ba03d0a131d414b315f5696c93627d188ca8651a31785f3b8d243c82476dd1ede56a00bc31b5e094d9ed1f3b503d96ed125009f03f3ea853d058255dc4484e232f9b5

▶ 메시지 서명

const signer = Wallet.createRandom()
const signed = await signer.signMessage("Hello World")
console.log(signed)

0xfd5a5ffed4227cd31d374b40f8ba59ed4702a74cbf6d6dca44f971525c71a6df4bb499d48f64012a7a42e13815351cc26d8fb8baef5e9a821de8db3836b84f751b

· Provider 연결

트랜잭션을 발생하기 위해선 Provider를 가지고 있어야 합니다.

const provider = new providers.JsonRpcProvider(url);

const signer = Wallet.createRandom()
const signed = await signer.signMessage("Hello World")

const wallet = signer.connect(provider)

· 이더리움 조회, nonce 조회, 트랜잭션 발생

await wallet.getBalance();
 { BigNumber: "42" }

await wallet.getTransactionCount();
 0

// Sending ether
await wallet.sendTransaction(tx)
{
  chainId: 1337,
  confirmations: 0,
  data: '0x',
  from: '0x77C44C0D1D37050e9250415Ee96401B5ac270856',
  gasLimit: { BigNumber: "21000" },
  gasPrice: { BigNumber: "1" },
  hash: '0x5037de21cbba9fbab45b779a8d4e52c610c06bb236f6e38df90a3a69f457aa12',
  nonce: 5,
  r: '0x62623cd493f7dc2a433c5bfa3b0d6802f498220c0ba1e3af0b9851ac8bfe8fe6',
  s: '0x140682e759a02e5a6d68087ff3d531fbdacb9b6ddd637a498c83507cfe347790',
  to: '0x8ba1f109551bD432803012645Ac136ddd64DBA72',
  type: null,
  v: 2709,
  value: { BigNumber: "1000000000000000000" },
  wait: [Function]
}

● utils

utils는 이더 단위를 바꾸거나 하는 메서드를 제공합니다. 다음 내용은 ethers.utils가 export 한 목록입니다.

export {
    AbiCoder,
    defaultAbiCoder,

    Fragment,
    ConstructorFragment,
    ErrorFragment,
    EventFragment,
    FunctionFragment,
    ParamType,
    FormatTypes,

    checkResultErrors,
    Result,

    Logger,

    RLP,

    _fetchData,
    fetchJson,
    poll,

    checkProperties,
    deepCopy,
    defineReadOnly,
    getStatic,
    resolveProperties,
    shallowCopy,

    arrayify,

    concat,
    stripZeros,
    zeroPad,

    isBytes,
    isBytesLike,

    defaultPath,
    HDNode,
    SigningKey,

    Interface,

    LogDescription,
    TransactionDescription,

    base58,
    base64,

    hexlify,
    isHexString,
    hexConcat,
    hexStripZeros,
    hexValue,
    hexZeroPad,
    hexDataLength,
    hexDataSlice,

    nameprep,
    _toEscapedUtf8String,
    toUtf8Bytes,
    toUtf8CodePoints,
    toUtf8String,
    Utf8ErrorFuncs,

    formatBytes32String,
    parseBytes32String,

    dnsEncode,
    hashMessage,
    namehash,
    isValidName,
    id,

    _TypedDataEncoder,

    getAddress,
    getIcapAddress,
    getContractAddress,
    getCreate2Address,
    isAddress,

    formatEther,
    parseEther,

    formatUnits,
    parseUnits,

    commify,

    computeHmac,
    keccak256,
    ripemd160,
    sha256,
    sha512,

    randomBytes,
    shuffled,

    solidityPack,
    solidityKeccak256,
    soliditySha256,

    splitSignature,
    joinSignature,

    accessListify,
    parseTransaction,
    serializeTransaction,
    TransactionTypes,

    getJsonWalletAddress,

    computeAddress,
    recoverAddress,

    computePublicKey,
    recoverPublicKey,

    verifyMessage,
    verifyTypedData,

    getAccountPath,
    mnemonicToEntropy,
    entropyToMnemonic,
    isValidMnemonic,
    mnemonicToSeed,


    ////////////////////////
    // Enums

    SupportedAlgorithm,

    UnicodeNormalizationForm,
    Utf8ErrorReason,

    ////////////////////////
    // Types

    Bytes,
    BytesLike,
    Hexable,

    AccessList,
    AccessListish,
    UnsignedTransaction,

    CoerceFunc,

    Indexed,

    Mnemonic,

    Deferrable,

    Utf8ErrorFunc,

    ConnectionInfo,
    OnceBlockable,
    OncePollable,
    PollOptions,
    FetchJsonResponse,

    EncryptOptions,
    ProgressCallback
}

· 단위변경

balance = await provider.getBalance("ethers.eth")
{ BigNumber: "82826475815887608" }

// wei -> ether
utils.formatEther(balance)
'0.082826475815887608'

// ether -> wei
utils.parseEther("1.0")
{ BigNumber: "1000000000000000000" }

// 특정 단위적용
utils.parseUnits('5', 'gwei')
BigNumber { _hex: '0x012a05f200', _isBigNumber: true }
0.000000005 Ether

· 주소 유효성 검사

console.log(utils.isAddress('0x86B6acf21e6F4aE60bbAdFDBc4F5D00741823d17'))
console.log(utils.isAddress('0x86B6acf21e6F4aE6bAdFDBc4F5D00741823d17'))

true
false

● Contract

Contract는 트랜잭션을 발생하고 컨트랙트에서 관리하는 상태를 조회할 수 있습니다.

pragma solidity 0.8.13;
 
contract test {
  uint public a = 10;

  event onEvent1(uint indexed a);
  event onEvent2(uint a);
  
  function event1() public {
    emit onEvent1(1);
  }
  
  function event2() public {
    emit onEvent2(2);
  }

  function getA() view public returns (uint) {
    return a;
  }

  function setA(uint _a) public {
    a = _a;
  }
}

CA: 0xFc0D07749d61479727d5EE0743D4d03f4C5Eb3B0

· 컨트랙트 객체 생성

const ABI = [
  {
    "inputs": [],
    "name": "event1",
    "outputs": [],
    "stateMutability": "nonpayable",
    "type": "function"
  },
  {
    "inputs": [],
    "name": "event2",
    "outputs": [],
    "stateMutability": "nonpayable",
    "type": "function"
  },
  {
    "anonymous": false,
    "inputs": [
      {
        "indexed": true,
        "internalType": "uint256",
        "name": "a",
        "type": "uint256"
      }
    ],
    "name": "onEvent1",
    "type": "event"
  },
  {
    "anonymous": false,
    "inputs": [
      {
        "indexed": false,
        "internalType": "uint256",
        "name": "a",
        "type": "uint256"
      }
    ],
    "name": "onEvent2",
    "type": "event"
  },
  {
    "inputs": [
      {
        "internalType": "uint256",
        "name": "_a",
        "type": "uint256"
      }
    ],
    "name": "setA",
    "outputs": [],
    "stateMutability": "nonpayable",
    "type": "function"
  },
  {
    "inputs": [],
    "name": "a",
    "outputs": [
      {
        "internalType": "uint256",
        "name": "",
        "type": "uint256"
      }
    ],
    "stateMutability": "view",
    "type": "function"
  },
  {
    "inputs": [],
    "name": "getA",
    "outputs": [
      {
        "internalType": "uint256",
        "name": "",
        "type": "uint256"
      }
    ],
    "stateMutability": "view",
    "type": "function"
  }
];
const signer = new Wallet(
  '0xe6deaed561bbeb9ebc1941b10beb9ff060060d9ea637554abe475eb8f1b13ddc',
  provider
)
const contract = new Contract(
  '0xFc0D07749d61479727d5EE0743D4d03f4C5Eb3B0',
  ABI,
  signer
)
const rst0 = await contract.getA();
const rst1 = await contract.a();
console.log(rst0)
console.log(rst1)

BigNumber { _hex: '0x0a', _isBigNumber: true }
BigNumber { _hex: '0x0a', _isBigNumber: true }

ethers는 ABI를 다음과 같이 정의할 수 있습니다.

const ABI = [
  'event onEvent1(uint indexed a)',
  'event onEvent2(uint a)',
  'function getA() view public returns (uint)',
  'function a() view public returns (uint)',
  'function setA(uint _a) public'
];
const signer = new Wallet(
  '0xe6deaed561bbeb9ebc1941b10beb9ff060060d9ea637554abe475eb8f1b13ddc',
  provider
)
const contract = new Contract(
  '0xFc0D07749d61479727d5EE0743D4d03f4C5Eb3B0',
  ABI,
  signer
)
const rst0 = await contract.getA();
const rst1 = await contract.a();
console.log(rst0)
console.log(rst1)

Contract 객체를 만들 때 signer가 아니라 provider를 전달할 수 있는데 signer(Wallet)를 전달하지 않으면 읽기전용입니다.

· 트랜잭션 발생

const ABI = [
  'event onEvent1(uint indexed a)',
  'event onEvent2(uint a)',
  'function getA() view public returns (uint)',
  'function a() view public returns (uint)',
  'function setA(uint _a) public'
];
const signer = new Wallet(
  '0xe6deaed561bbeb9ebc1941b10beb9ff060060d9ea637554abe475eb8f1b13ddc',
  provider
)
const contract = new Contract(
  '0xFc0D07749d61479727d5EE0743D4d03f4C5Eb3B0',
  ABI,
  signer
)
const rst0 = await contract.setA(123);
console.log(rst0)

const rst1 = await contract.a();
console.log(rst1)

{
  nonce: 10,
  gasPrice: BigNumber { _hex: '0x04a817c800', _isBigNumber: true },
  gasLimit: BigNumber { _hex: '0x682c', _isBigNumber: true },
  to: '0xFc0D07749d61479727d5EE0743D4d03f4C5Eb3B0',
  value: BigNumber { _hex: '0x00', _isBigNumber: true },
  data: '0xee919d50000000000000000000000000000000000000000000000000000000000000007b',
  chainId: 1337,
  v: 2709,
  r: '0x229c8022469d2a4cf0123e10b6b109b038545619db3f861ee28859d1d492fd34',
  s: '0x00817868e24ce66cc00ebfbe1f2a86fabba40d43bebafc15f78a73497a02d680',
  from: '0x86B6acf21e6F4aE60bbAdFDBc4F5D00741823d17',
  hash: '0xb09ab043d685e55312f95d786c37f81eb8afb70fa8fe9e63894b0dcc96cd76e9',
  type: null,
  confirmations: 0,
  wait: [Function (anonymous)]
}
BigNumber { _hex: '0x7b', _isBigNumber: true }

· 이벤트 수신

contract.on('onEvent1', (a) => {
  console.log(a)
})
contract.on('onEvent2', (a) => {
  console.log(a)
})

이벤트를 발생하는 함수를 호출하면 각각의 이벤트 리스터를 호출합니다.

[ethereum] ERC20 만들 때 주의할 점 - symbol, decimals

멍개. — Sun, 28 Aug 2022 08:02:48 +0900

ERC20의 인터페이스 중 symbol이 존재합니다. ERC20을 배포하면서 symbol을 초기화하게 되는데 이때 주의할 점이 있습니다.

기본적으로 symbol 자체는 길이가 정해져있지는 않지만 메타마스크를 기준으로는 토큰 기호가 11자리가 넘어가지 않는것을 권장합니다.

여기서 또 하나 궁금증이 생겨서 테스트를 진행해보았습니다. 한글로 설정한다면?

다행히 한글은 정상적으로 동작합니다.

마지막으로 토큰 십진수로 표시되어 있는 부분은 decimals인데 이 부분은 UINT8이 표준이므로 0~255까지 256개의 데이터를 허용합니다.

[ethereum] gas와 관련된 에러

멍개. — Sun, 28 Aug 2022 08:01:52 +0900

안녕하세요 멍개입니다. 이번글에서는 이더리움에서 트랜잭션 실행할 때 발생할 수 있는 gas 에러를 살펴보겠습니다.

▶ out of gas

▶ exceeds block gas limit

▶ gasLimit is too low

▶ base fee exceeds gas limit

· 네트워크 실행

$ ganache-cli

· out of gas

트랜잭션을 실행하여 상태를 변경할 때 실행된 코드에 따라 가스를 소모합니다. 이때 트랜잭션엔 어느정도 코드 실행을 할지 결정하는 gas를 설정할 수 있는데 설정된 값보다 더 많은 코드를 실행하려고 할 때 발생하는 에러입니다.

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.10;
 
contract Mung {
 string public text;
 constructor(string memory _text) {
   text = _text;
 }
  function setText(string memory _text) public{
   text = _text;
 }
  function say() public view returns(string memory){
   return text;
 }
 
 function errorOccur(uint a) public pure returns (uint) {
   require(a == 0, "hello world error");
   return a;
 }
}

해당 컨트랙트 코드를 배포하는 트랜잭션을 만들어보겠습니다.

const Web3 = require('web3');
let web3 = new Web3(new Web3.providers.HttpProvider("http://localhost:8545"));

async function main() {
 const from = '0x42aBb1C1b24fC723634547AcC6fa2478fD0EBe44'; // ganache-cli에서 생성한 주소
 var mungContract = new web3.eth.Contract([
	{
		"inputs": [
			{
				"internalType": "string",
				"name": "_text",
				"type": "string"
			}
		],
		"stateMutability": "nonpayable",
		"type": "constructor"
	},
	{
		"inputs": [
			{
				"internalType": "uint256",
				"name": "a",
				"type": "uint256"
			}
		],
		"name": "errorOccur",
		"outputs": [
			{
				"internalType": "uint256",
				"name": "",
				"type": "uint256"
			}
		],
		"stateMutability": "pure",
		"type": "function"
	},
	{
		"inputs": [],
		"name": "say",
		"outputs": [
			{
				"internalType": "string",
				"name": "",
				"type": "string"
			}
		],
		"stateMutability": "view",
		"type": "function"
	},
	{
		"inputs": [
			{
				"internalType": "string",
				"name": "_text",
				"type": "string"
			}
		],
		"name": "setText",
		"outputs": [],
		"stateMutability": "nonpayable",
		"type": "function"
	},
	{
		"inputs": [],
		"name": "text",
		"outputs": [
			{
				"internalType": "string",
				"name": "",
				"type": "string"
			}
		],
		"stateMutability": "view",
		"type": "function"
	}
]); // remix에서 ABI 복사한 값을 인자로 전달
 var mung = mungContract.deploy({
     data: '',  // remix에서 bytecode.object 복사한 값
     arguments: ['test'] // 생성자에 전달할 값
 }).send({
     from: from,
     gas: '100000' 
   }, function (err, contract){
     console.log(err, contract);
 })
}

main();

여기서 data엔 컴파일 결과인 바이트 코드를 넣어줍니다. gas가 100,000으로 설정되어 있습니다. 해당 코드를 실행하면 다음과 같은 에러 메시지를 출력합니다.

Error: Returned error: VM Exception while processing transaction: out of gas

실행될 코드가 가스를 초과하서 발생한 에러입니다.

해당 컨트랙트 코드는 4,700,000 정도면 충분히 배포 가능합니다.

· Exceeds block gas limit

실행할 트랜잭션은 블록에 포함되어집니다. 이때 블록이 포함하고 있는 트랜잭션의 모든 가스합을 가지고 있는데 이 값이 특정값을 넘어가면 발생하는 에러가 Exceeds block gas limit 입니다. 앞의 코드에서 gas를 매우 높여서 실행하면 다음과 같은 에러가 발생합니다.

Error: Returned error: Exceeds block gas limit

· base fee exceeds gas limit

해당 에러는 스마트 컨트랙트를 배포하거나 실행하는 트랜잭션을 실행할 떄 최소 기준 가스보다 gas의 한도치를 너무 낮게 설정할 경우 발생하는 에러입니다.(이더리움을 전송하는 트랜잭션은 해당 에러가 발생하지 않습니다.)

Returned error: base fee exceeds gas limit

· gasLimit is too low

이더리움 전송 트랜잭션은 gasLimit이 21,000으로 고정되어 있습니다. 만약 해당 수치보다 낮은 수치로 트랜잭션을 발생하면 gasLimit is too low 에러가 발생합니다. 기준치는 초과하지만 21000보다 작을 때 해당 에러가 발생합니다.

const Web3 = require('web3');
let web3 = new Web3(new Web3.providers.HttpProvider("http://localhost:8545"));

async function main() {
  const from = '0x42aBb1C1b24fC723634547AcC6fa2478fD0EBe44';
  const pk = '0xa960a13e39802345fb5c0e4bce81aed3e94ca4fccf3f17e148fd68beece8fe08' // from에 대응하는 privateKey를 넣어준다
  const to = '0x6c6117196b7c4D4986a1DA1234C003DaE54F44C9' 
  const tx = {
	from,
	to,
	gas: 21000, // gasLimit
	gasPrice: '21000000000', // 해당 값은 그대로 입력 합니다.
	value: '1000000000000000' // 원하는 이더전송 수량을 입력합니다.
  }
  const account = web3.eth.accounts.privateKeyToAccount(pk) // 개인키를 account 객체로 복구
  const signedTx = await account.signTransaction(tx) // 개인키로 트랜잭션 서명
  const sentTx = await web3.eth.sendSignedTransaction(
	signedTx.raw || signedTx.rawTransaction
  ); // 서명된 트랜잭션 이더리움 노드로 전송
  console.log(sentTx);
}
main();

from, pk, to는 적절히 넣어줍니다. 해당 코드를 실행하면 정상적으로 동작합니다. gas를 다음과 같이 수정한 후 실행하면 에러가 발생합니다.

  const tx = {
    from,
    to,
    gas: 2100, // 해당 값은 그대로 입력 합니다.
    gasPrice: '21000000000', // 해당 값은 그대로 입력 합니다.
    value: '1000000000000000' // 원하는 이더전송 수량을 입력합니다.
  }

Error: Signer Error: Signer Error:  gasLimit is too low. given 2100, need at least 21000.

두 번째로 스마트 컨트랙트를 호출 할 때 21,000보다 낮게 설정해도 해당 에러가 발생합니다.

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.10;
 
contract Mung {
 string public text;
 constructor(string memory _text) {
   text = _text;
 }
  function setText(string memory _text) public{
   text = _text;
 }
  function say() public view returns(string memory){
   return text;
 }
 
 function errorOccur(uint a) public pure returns (uint) {
   require(a == 0, "hello world error");
   return a;
 }
}

const Web3 = require('web3');
let web3 = new Web3(new Web3.providers.HttpProvider("http://localhost:8545"));
async function main() {
  const CA = "0xaF3DE8794C26363c04A313Bc0cf8A01915017B21" // 배포한 스마트 컨트랙트 주소
  const from = '0x42aBb1C1b24fC723634547AcC6fa2478fD0EBe44';
  const pk = '0xa960a13e39802345fb5c0e4bce81aed3e94ca4fccf3f17e148fd68beece8fe08' // from에 대응하는 privateKey를 넣어준다어준다
  const ABI = [
    {
      "inputs": [
        {
          "internalType": "string",
          "name": "_text",
          "type": "string"
        }
      ],
      "stateMutability": "nonpayable",
      "type": "constructor"
    },
    {
      "inputs": [
        {
          "internalType": "uint256",
          "name": "a",
          "type": "uint256"
        }
      ],
      "name": "errorOccur",
      "outputs": [
        {
          "internalType": "uint256",
          "name": "",
          "type": "uint256"
        }
      ],
      "stateMutability": "pure",
      "type": "function"
    },
    {
      "inputs": [],
      "name": "say",
      "outputs": [
        {
          "internalType": "string",
          "name": "",
          "type": "string"
        }
      ],
      "stateMutability": "view",
      "type": "function"
    },
    {
      "inputs": [
        {
          "internalType": "string",
          "name": "_text",
          "type": "string"
        }
      ],
      "name": "setText",
      "outputs": [],
      "stateMutability": "nonpayable",
      "type": "function"
    },
    {
      "inputs": [],
      "name": "text",
      "outputs": [
        {
          "internalType": "string",
          "name": "",
          "type": "string"
        }
      ],
      "stateMutability": "view",
      "type": "function"
    }
  ]; // remix 또는 트러플 컴파일 결과에서 ABI 복사하여 넣어준다.
 
  // 스마트 컨트랙트 객체 생성
  let Contract = new web3.eth.Contract(ABI, CA); 
 
  // 스마트 컨트랙트에 정의한 함수 실행
  let bytedata = await Contract.methods.setText("test").encodeABI(); 
  console.log(bytedata);
 
  const tx = {
     from,
     to: CA,
     gas: 1000, // 해당 수치는 그대로 입력합니다.
     gasPrice: '21000000000', // 해당 수치는 그대로 입력합니다.
     data: bytedata
  }
 
  const account = web3.eth.accounts.privateKeyToAccount(pk)
  const signedTx = await account.signTransaction(tx)
  const sentTx = await web3.eth.sendSignedTransaction(signedTx.raw || signedTx.rawTransaction);
  console.log(sentTx);
}
 
main();

gas를 1000으로 매우 낮게 주었습니다.

Error: Signer Error: Signer Error:  gasLimit is too low. given 1000, need at least 21520.

이더리움 전송할때와 유사한 에러를 출력합니다. 여시거 21520이 필요하다고 하는데 제가 찾은 최소값은 26788입니다.

[ethereum] EIP, ERC 그것을 파악해보자

멍개. — Sun, 28 Aug 2022 07:58:59 +0900

https://blog.naver.com/pjt3591oo/222597931496

[ethereum] hardhat을 이용하여 스마트 컨트랙트 개발하기

멍개. — Sun, 28 Aug 2022 07:58:09 +0900

지난 시간에 truffle을 이용하여 스마트 컨트랙트 개발하는 방법을 소개했습니다.

2022.08.28 - [블록체인] - [ethereum] truffle을 이용하여 스마트 컨트랙트 개발하기

[ethereum] truffle을 이용하여 스마트 컨트랙트 개발하기

ruffle을 이용하여 스마트 컨트랙트를 개발하는 방법을 다룹니다. ● 셋업 $ npm install -g truffle · 프로젝트 생성 $ mkdir dapp $ cd dapp $ truffle init init 명령어를 사용하여 truffle 기반의 프로젝트를..

meongae.tistory.com

추가적으로 출금패턴(withdrawals patterns)을 truffle을 활용하여 다뤄보기도 했습니다.

2022.08.28 - [블록체인] - [ethereum] solidity withdrawals pattern(출금패턴)

[ethereum] solidity withdrawals pattern(출금패턴)

solidity에서 출금패턴을 다뤄보겠습니다. 제가 이 포스팅을 위해 삽질한 과정을 보고 싶다면 여기로 오시면 되겠습니다. 약 2시간 30분동안 삽질을 하였습니다. ☞ 목차 1. 준비 2. 입/출금 가능한

meongae.tistory.com

이번글에서는 truffle을 대체할수 있는 hardhat을 이용하여 스마트 컨트랙트 개발하는 방법을 소개합니다.

● 셋업

hardhat을 이용하여 개발할 수 있는 환경을 구축합니다.

· 프로젝트 생성

$ mkdir hardhat-test
$ cd hardhat-test

$ npm install --save-dev hardhat

$ npx hardhat

어떤 형태의 프로젝트를 생성할 지 묻습니다.

저는 여기서 세 번째 Create an advanced sample project that uses TypeScript를 선택하도록 하겠습니다.

선택을 하면 3가지를 더 묻습니다.

프로젝트 루트 경로

.gitignore 추가유무

의존성 모듈 설치

마지막의 의존성 모듈은 typescript 기반으로 생성했으므로 typescript 관련된 의존성을 추가합니다.

$ tree . -I node_modules
.
├── README.md
├── contracts
│   └── Greeter.sol
├── hardhat.config.ts
├── package-lock.json
├── package.json
├── scripts
│   └── deploy.ts
├── test
│   └── index.ts
└── tsconfig.json

3 directories, 8 files

▶ contracts

스마트 컨트랙트 코드를 관리합니다.

▶ scripts(truffle에서 migrations 역할을 수행합니다.)

스마트 컨트랙트 배포를 관리합니다

▶ test

테스트 코드를 관리합니다.

▶ artifacts, cache

컴파일 결과를 관리합니다.

▶ hardhat.config.ts

네트워크 연결정보 및 solidity compiler 버전 정보 등을 관리합니다.

import * as dotenv from "dotenv";

import { HardhatUserConfig, task } from "hardhat/config";
import "@nomiclabs/hardhat-etherscan";
import "@nomiclabs/hardhat-waffle";
import "@typechain/hardhat";
import "hardhat-gas-reporter";
import "solidity-coverage";

dotenv.config();

// This is a sample Hardhat task. To learn how to create your own go to
// https://hardhat.org/guides/create-task.html
task("accounts", "Prints the list of accounts", async (taskArgs, hre) => {
  const accounts = await hre.ethers.getSigners();

  for (const account of accounts) {
    console.log(account.address);
  }
});

// You need to export an object to set up your config
// Go to https://hardhat.org/config/ to learn more

const config: HardhatUserConfig = {
  solidity: "0.8.4",
  networks: {
    ropsten: {
      url: process.env.ROPSTEN_URL || "",
      accounts:
        process.env.PRIVATE_KEY !== undefined ? [process.env.PRIVATE_KEY] : [],
    },
  },
  gasReporter: {
    enabled: process.env.REPORT_GAS !== undefined,
    currency: "USD",
  },
  etherscan: {
    apiKey: process.env.ETHERSCAN_API_KEY,
  },
};

export default config;

process.env는 환경변수를 가져옵니다.

hardhat은 프로젝트 생성시 .env를 생성합니다.

ETHERSCAN_API_KEY=ABC123ABC123ABC123ABC123ABC123ABC1
ROPSTEN_URL=https://eth-ropsten.alchemyapi.io/v2/<YOUR ALCHEMY KEY>
PRIVATE_KEY=0xabc123abc123abc123abc123abc123abc123abc123abc123abc123abc123abc1

hardhat은 etherscan과 연동되어 특정 액션을 수행합니다.

· 의존성 모듈 확인하기

package.json을 확인하면 앞의 명령어로 생성한 프로젝트가 얼마나 많은 라이브러리와 의존성을 가지는지 알 수 있습니다.

{
  "name": "hardhat-project",
  "devDependencies": {
    "@nomiclabs/hardhat-ethers": "^2.0.3",
    "@nomiclabs/hardhat-etherscan": "^2.1.8",
    "@nomiclabs/hardhat-waffle": "^2.0.1",
    "@typechain/ethers-v5": "^7.2.0",
    "@typechain/hardhat": "^2.3.1",
    "@types/chai": "^4.3.0",
    "@types/mocha": "^9.0.0",
    "@types/node": "^12.20.37",
    "@typescript-eslint/eslint-plugin": "^4.33.0",
    "@typescript-eslint/parser": "^4.33.0",
    "chai": "^4.3.4",
    "dotenv": "^10.0.0",
    "eslint": "^7.32.0",
    "eslint-config-prettier": "^8.3.0",
    "eslint-config-standard": "^16.0.3",
    "eslint-plugin-import": "^2.25.3",
    "eslint-plugin-node": "^11.1.0",
    "eslint-plugin-prettier": "^3.4.1",
    "eslint-plugin-promise": "^5.2.0",
    "ethereum-waffle": "^3.4.0",
    "ethers": "^5.5.2",
    "hardhat": "^2.7.1",
    "hardhat-gas-reporter": "^1.0.6",
    "prettier": "^2.5.1",
    "prettier-plugin-solidity": "^1.0.0-beta.13",
    "solhint": "^3.3.6",
    "solidity-coverage": "^0.7.17",
    "ts-node": "^10.4.0",
    "typechain": "^5.2.0",
    "typescript": "^4.5.4"
  }
}

● 개발 프로세스

일반적으로 개발이라하면 다음과 같은 프로세스에 맞춰서 개발합니다.

1. 소스코드 작성 
2. 컴파일 & 빌드 
3. 배포 
4. 개별적으로 실행해보기 
5. 테스트 하기

hardhat도 truffle과 마찬가지로 이런 일련의 과정을 코드 및 명령어 기반으로 수행할 수 있습니다.

· 소스코드 작성

소스 코드는 contracts 아래에서 관리합니다. 우리는 별도의 소스코드를 작성하지 않고 샘플로 제공하는 Greeter.sol을 이용합니다.

//SPDX-License-Identifier: Unlicense
pragma solidity ^0.8.0;

import "hardhat/console.sol";

contract Greeter {
    string private greeting;

    constructor(string memory _greeting) {
        console.log("Deploying a Greeter with greeting:", _greeting);
        greeting = _greeting;
    }

    function greet() public view returns (string memory) {
        return greeting;
    }

    function setGreeting(string memory _greeting) public {
        console.log("Changing greeting from '%s' to '%s'", greeting, _greeting);
        greeting = _greeting;
    }
}

여기서 한 가지 중요한 점은 console.log를 사용한다는 점입니다. hardhat팀은 스마트 컨트랙트 개발시 마치 자바스크립트처럼 디버깅할 수 있도록 도와주는 console.log 라이브러리를 제공하고 있습니다.

· 컴파일

$ npx hardhat compile

Downloading compiler 0.8.4
Compiling 2 files with 0.8.4
Generating typings for: 2 artifacts in dir: typechain for target: ethers-v5
Successfully generated 5 typings!
Compilation finished successfully

컴파일을 완료하면 artifacts, cache 디렉터리를 생성합니다. 만약, 컨트랙트 코드에 문제가 있다면 문제에 대한 메시지를 출력합니다.

$ tree  -I node_modules           
.
├── README.md
├── artifacts
│   ├── build-info
│   │   └── f6d72e584f9c6e176d0b340e8f9097a9.json
│   ├── contracts
│   │   └── Greeter.sol
│   │       ├── Greeter.dbg.json
│   │       └── Greeter.json
│   └── hardhat
│       └── console.sol
│           ├── console.dbg.json
│           └── console.json
├── cache
│   └── solidity-files-cache.json
├── contracts
│   └── Greeter.sol
├── hardhat.config.ts
├── package-lock.json
├── package.json
├── scripts
│   └── deploy.ts
├── test
│   └── index.ts
├── tsconfig.json
└── typechain
    ├── Greeter.d.ts
    ├── common.d.ts
    ├── factories
    │   └── Greeter__factory.ts
    ├── hardhat.d.ts
    └── index.ts

12 directories, 19 files

우리가 dapp을 만들 때 필요한 요소중 하나인 ABI와 bytecode는 artifacts/contracts 아래의 우리가 작성한 solidity 파일명인 Greeter.sol 아래에서 관리합니다.

{
  "_format": "hh-sol-artifact-1",
  "contractName": "Greeter",
  "sourceName": "contracts/Greeter.sol",
  "abi": [
    {
      "inputs": [
        {
          "internalType": "string",
          "name": "_greeting",
          "type": "string"
        }
      ],
      "stateMutability": "nonpayable",
      "type": "constructor"
    },
    {
      "inputs": [],
      "name": "greet",
      "outputs": [
        {
          "internalType": "string",
          "name": "",
          "type": "string"
        }
      ],
      "stateMutability": "view",
      "type": "function"
    },
    {
      "inputs": [
        {
          "internalType": "string",
          "name": "_greeting",
          "type": "string"
        }
      ],
      "name": "setGreeting",
      "outputs": [],
      "stateMutability": "nonpayable",
      "type": "function"
    }
  ],
  "bytecode": "생략",
  "deployedByBytecode":  "생략",
  "linkReferences": {},
  "deployedLinkReferences": {}
}

truffle의 컴파일 결과보다 필요한 정보만 가지고 있어서 이 부분은 hardhat이 맘에 드는 요소중 하나입니다.

또한 해당 프로젝트를 typescript 기반으로 생성했기 때문에 typechain 디렉터리도 생성합니다.

.
├── Greeter.d.ts
├── common.d.ts
├── factories
│   └── Greeter__factory.ts
├── hardhat.d.ts
└── index.ts

1 directory, 5 files

해당 파일은 contracts 파일에 대한 인터페이스 정의입니다.

· 테스트

테스트 코드는 test에서 관리합니다. 이 부분도 샘플로 제공하는 코드를 기준으로 진행합니다.

import { expect } from "chai";
import { ethers } from "hardhat";

describe("Greeter", function () {
  it("Should return the new greeting once it's changed", async function () {
    const Greeter = await ethers.getContractFactory("Greeter");
    const greeter = await Greeter.deploy("Hello, world!");
    await greeter.deployed();

    expect(await greeter.greet()).to.equal("Hello, world!");

    const setGreetingTx = await greeter.setGreeting("Hola, mundo!");

    // wait until the transaction is mined
    await setGreetingTx.wait();

    expect(await greeter.greet()).to.equal("Hola, mundo!");
  });
});

해당 코드의 흐름은 다음과 같습니다.

▶ 1. 컨트랙트 팩토리 메서드를 이용하여 Greeter 배포객체 가져오기

const Greeter = await ethers.getContractFactory("Greeter");

여기서 팩토리란 factory를 의미합니다. 프로그래밍에서 팩토리란 객체를 만드는 함수를 의미합니다.

▶ 2. 팩토리를 통해 가져온 컨트랙트 정보를 토대로 Hello world!를 초기값으로 가지는 컨트랙트 배포준비

const greeter = await Greeter.deploy("Hello, world!");

▶ 3. 컨트랙트 배포

await greeter.deployed();

▶ 4. 생성자에 의한 초기값 기대값 확인

expect(await greeter.greet()).to.equal("Hello, world!");

▶ 5. setGreeting() 호출하여 Hello, world!를 Hola, mundo!로 변경 - 트랜잭션 발생

const setGreetingTx = await greeter.setGreeting("Hola, mundo!");

▶ 6.트랜잭션이 블록에 포함할 때까지 기다림

await setGreetingTx.wait();

▶ 7. 6번으로 변경한 기대값 확인

expect(await greeter.greet()).to.equal("Hola, mundo!");

$ npx hardhat test

No need to generate any newer typings.

  Greeter
Deploying a Greeter with greeting: Hello, world!
Changing greeting from 'Hello, world!' to 'Hola, mundo!'
    ✓ Should return the new greeting once it's changed (601ms)

  1 passing (606ms)

 $ npx hardhat test test/index.ts

특정 파일을 명시하면 특정 파일만 테스트 합니다.

· 배포

배포는 scripts에서 관리하며 run 명령어를 이용합니다. 이 또한 샘플로 제공한 deploy.ts 파일을 이용합니다.

import { ethers } from "hardhat";

async function main() {
  const Greeter = await ethers.getContractFactory("Greeter");
  const greeter = await Greeter.deploy("Hello, Hardhat!");

  await greeter.deployed();

  console.log("Greeter deployed to:", greeter.address);
}

main().catch((error) => {
  console.error(error);
  process.exitCode = 1;
});

앞의 테스트 코드에서 다뤄본 내용입니다.

한 가지 이상하다고 느낄 수 있는 부분은 다음 부분일겁니다.

main().catch((error) => {
  console.error(error);
  process.exitCode = 1;
});

이건 main() 함수의 반환 타입이 Promise 이기 때문에 then() 또는 catch()로 체이닝이 가능합니다.

배포하기 전에 해야할 작업이 있습니다.

1. 네트워크 환경 구성
2. hardhat 배포 네트워크 설정

여기선 ganache-cli로 구축한 네트워크에 배포를 진행합니다.

▶ 로컬 네트워크 구축

아마 제 블로그를 꾸준히 보신분은 ganache-cli을 어떻게 실행하는지 아실겁니다.

하지만 전 너무나 친절한 멍개이기 때문에 설치방법과 실행방법을 알려드립니다.

$ npm install -g ganache-cli # 설치

$ ganache-cli # 실행
Ganache CLI v6.12.2 (ganache-core: 2.13.2)

Available Accounts
==================
(0) 0x6b113534c1ef028e2F90d2338F491E49EB70879c (100 ETH)
(1) 0x9BEae85001A0c3F09688345145498919423b5E8C (100 ETH)
(2) 0xF7718Dd4e188C160A051834D6F37399D64b96F5A (100 ETH)
(3) 0x9d56FFe5bF0DeAF33c70883681B09ecD0F010ac4 (100 ETH)
(4) 0x7A61860f47Bc42A865d9424d8eDC70705602300e (100 ETH)
(5) 0xd673AFCD67FFD1dedc9FbAE4cEf0A08Eb0aCD13A (100 ETH)
(6) 0xab90Abfe30dcfcf0318D4985C9d3518D24b14475 (100 ETH)
(7) 0x54E2F2BBEdb351d4eD12F34B1Df83e5fc061df1C (100 ETH)
(8) 0xB70454565eA14AB414C80a540A1022Af43597628 (100 ETH)
(9) 0xD43B9c31624a17731336516b75177cCB40358741 (100 ETH)

Private Keys
==================
(0) 0x78cc9813aa135f44dcba76b1a751271591640473cf039a0efb60d27491dab144
(1) 0x84fa91cc7df9476856ae603edc3e84e3b57782f9eea37c6e2400a0c4124f8005
(2) 0xa4da287dc643a1f5732137fc5900ffe2edf09a37b3c5d281f3610a2b2c7019a1
(3) 0xc04aac3b8bf75548e52bd437546524649da52dc9ec0897041fa3f07630ad87d0
(4) 0x0608b4d7bc929e4a4f444764ca904b1942df2b198f7604f88e57697e5e76baa7
(5) 0xbfc2e7155d0b287081992e0b41bda7560e901920d8f72cd39446364bd9ed0bcf
(6) 0xfbf0fef2691d3b822daf11e2190fa506cd4eba929dcc904af39eb54b30bff59e
(7) 0x5381c52fe5a80b2bdfc831bb129ed211b131c4ec4f488756f62c64704b082ca0
(8) 0xe317b2db45f3c334c969345c25032a9ef50b04b42f87b8c53e255cd7cba01d7f
(9) 0xfe3ad5e53cfca3d36bbd11984c25f5db8a118252735ad59370f13322271f0011

HD Wallet
==================
Mnemonic:      world globe scale buddy peace position broccoli autumn move local saddle snow
Base HD Path:  m/44'/60'/0'/0/{account_index}

Gas Price
==================
20000000000

Gas Limit
==================
6721975

Call Gas Limit
==================
9007199254740991

Listening on 127.0.0.1:8545

만약, ganache-cli가 지겨우신 가요? 그렇다면 hardhat이 제공하는 노드를 이용해도 됩니다.

Started HTTP and WebSocket JSON-RPC server at http://127.0.0.1:8545/

Accounts
========

WARNING: These accounts, and their private keys, are publicly known.
Any funds sent to them on Mainnet or any other live network WILL BE LOST.

Account #0: 0xf39fd6e51aad88f6f4ce6ab8827279cfffb92266 (10000 ETH)
Private Key: 0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80

Account #1: 0x70997970c51812dc3a010c7d01b50e0d17dc79c8 (10000 ETH)
Private Key: 0x59c6995e998f97a5a0044966f0945389dc9e86dae88c7a8412f4603b6b78690d

Account #2: 0x3c44cdddb6a900fa2b585dd299e03d12fa4293bc (10000 ETH)
Private Key: 0x5de4111afa1a4b94908f83103eb1f1706367c2e68ca870fc3fb9a804cdab365a

Account #3: 0x90f79bf6eb2c4f870365e785982e1f101e93b906 (10000 ETH)
Private Key: 0x7c852118294e51e653712a81e05800f419141751be58f605c371e15141b007a6

Account #4: 0x15d34aaf54267db7d7c367839aaf71a00a2c6a65 (10000 ETH)
Private Key: 0x47e179ec197488593b187f80a00eb0da91f1b9d0b13f8733639f19c30a34926a

Account #5: 0x9965507d1a55bcc2695c58ba16fb37d819b0a4dc (10000 ETH)
Private Key: 0x8b3a350cf5c34c9194ca85829a2df0ec3153be0318b5e2d3348e872092edffba

Account #6: 0x976ea74026e726554db657fa54763abd0c3a0aa9 (10000 ETH)
Private Key: 0x92db14e403b83dfe3df233f83dfa3a0d7096f21ca9b0d6d6b8d88b2b4ec1564e

Account #7: 0x14dc79964da2c08b23698b3d3cc7ca32193d9955 (10000 ETH)
Private Key: 0x4bbbf85ce3377467afe5d46f804f221813b2bb87f24d81f60f1fcdbf7cbf4356

Account #8: 0x23618e81e3f5cdf7f54c3d65f7fbc0abf5b21e8f (10000 ETH)
Private Key: 0xdbda1821b80551c9d65939329250298aa3472ba22feea921c0cf5d620ea67b97

Account #9: 0xa0ee7a142d267c1f36714e4a8f75612f20a79720 (10000 ETH)
Private Key: 0x2a871d0798f97d79848a013d4936a73bf4cc922c825d33c1cf7073dff6d409c6

Account #10: 0xbcd4042de499d14e55001ccbb24a551f3b954096 (10000 ETH)
Private Key: 0xf214f2b2cd398c806f84e317254e0f0b801d0643303237d97a22a48e01628897

Account #11: 0x71be63f3384f5fb98995898a86b02fb2426c5788 (10000 ETH)
Private Key: 0x701b615bbdfb9de65240bc28bd21bbc0d996645a3dd57e7b12bc2bdf6f192c82

Account #12: 0xfabb0ac9d68b0b445fb7357272ff202c5651694a (10000 ETH)
Private Key: 0xa267530f49f8280200edf313ee7af6b827f2a8bce2897751d06a843f644967b1

Account #13: 0x1cbd3b2770909d4e10f157cabc84c7264073c9ec (10000 ETH)
Private Key: 0x47c99abed3324a2707c28affff1267e45918ec8c3f20b8aa892e8b065d2942dd

Account #14: 0xdf3e18d64bc6a983f673ab319ccae4f1a57c7097 (10000 ETH)
Private Key: 0xc526ee95bf44d8fc405a158bb884d9d1238d99f0612e9f33d006bb0789009aaa

Account #15: 0xcd3b766ccdd6ae721141f452c550ca635964ce71 (10000 ETH)
Private Key: 0x8166f546bab6da521a8369cab06c5d2b9e46670292d85c875ee9ec20e84ffb61

Account #16: 0x2546bcd3c84621e976d8185a91a922ae77ecec30 (10000 ETH)
Private Key: 0xea6c44ac03bff858b476bba40716402b03e41b8e97e276d1baec7c37d42484a0

Account #17: 0xbda5747bfd65f08deb54cb465eb87d40e51b197e (10000 ETH)
Private Key: 0x689af8efa8c651a91ad287602527f3af2fe9f6501a7ac4b061667b5a93e037fd

Account #18: 0xdd2fd4581271e230360230f9337d5c0430bf44c0 (10000 ETH)
Private Key: 0xde9be858da4a475276426320d5e9262ecfc3ba460bfac56360bfa6c4c28b4ee0

Account #19: 0x8626f6940e2eb28930efb4cef49b2d1f2c9c1199 (10000 ETH)
Private Key: 0xdf57089febbacf7ba0bc227dafbffa9fc08a93fdc68e1e42411a14efcf23656e

WARNING: These accounts, and their private keys, are publicly known.
Any funds sent to them on Mainnet or any other live network WILL BE LOST.

여기서는 ganache-cli로 진행합니다. 사실 머로 진행하든 상관없습니다.

▶ hardhat.config.ts

hardhat에서 배포할 네트워크를 수정할 차례입니다.

import * as dotenv from "dotenv";

import { HardhatUserConfig, task } from "hardhat/config";
import "@nomiclabs/hardhat-etherscan";
import "@nomiclabs/hardhat-waffle";
import "@typechain/hardhat";
import "hardhat-gas-reporter";
import "solidity-coverage";

dotenv.config();

task("accounts", "Prints the list of accounts", async (taskArgs, hre) => {
  const accounts = await hre.ethers.getSigners();

  for (const account of accounts) {
    console.log(account.address);
  }
});

// You need to export an object to set up your config
// Go to https://hardhat.org/config/ to learn more

const config: HardhatUserConfig = {
  solidity: "0.8.4",
  networks: {
    ropsten: {
      url: process.env.ROPSTEN_URL || "",
      accounts:
        process.env.PRIVATE_KEY !== undefined ? [process.env.PRIVATE_KEY] : [],
    },
    dev: {
      url: "http://localhost:8545",
      accounts: [
        "0x78cc9813aa135f44dcba76b1a751271591640473cf039a0efb60d27491dab144",
        "0x84fa91cc7df9476856ae603edc3e84e3b57782f9eea37c6e2400a0c4124f8005",
        "0xa4da287dc643a1f5732137fc5900ffe2edf09a37b3c5d281f3610a2b2c7019a1",
        "0xc04aac3b8bf75548e52bd437546524649da52dc9ec0897041fa3f07630ad87d0",
        "0x0608b4d7bc929e4a4f444764ca904b1942df2b198f7604f88e57697e5e76baa7",
        "0xbfc2e7155d0b287081992e0b41bda7560e901920d8f72cd39446364bd9ed0bcf",
        "0xfbf0fef2691d3b822daf11e2190fa506cd4eba929dcc904af39eb54b30bff59e",
        "0x5381c52fe5a80b2bdfc831bb129ed211b131c4ec4f488756f62c64704b082ca0",
        "0xe317b2db45f3c334c969345c25032a9ef50b04b42f87b8c53e255cd7cba01d7f",
        "0xfe3ad5e53cfca3d36bbd11984c25f5db8a118252735ad59370f13322271f0011",
      ],
    },
  },
  gasReporter: {
    enabled: process.env.REPORT_GAS !== undefined,
    currency: "USD",
  },
  etherscan: {
    apiKey: process.env.ETHERSCAN_API_KEY,
  },
};

export default config;

network에 truffle.config.js와 비슷한 형태로 추가합니다. 이때 중요한 점은 accounts를 넣어줘야 합니다. accounts는 개인키(privatekey)를 넣어야 합니다.

▶ 배포

$ npx hardhat run --network dev scripts/deploy.ts

No need to generate any newer typings.
Greeter deployed to: 0x2977ae3f2C5473d6cebcfE37be94BA59ce1Dd483

deploy.ts 파일 main() 함수의 마지막의 다음과 같이 콘솔이 있어 마지막에 배포한 컨트랙트 주소를 출력합니다.

console.log("Greeter deployed to:", greeter.address);

만약 배포시 hardhat.config.ts의 network에 명시한 accounts를 가져오고 싶다면 다음과 같이 가져올 수 있습니다.

import { ethers } from "hardhat";

const accounts = await ethers.getSigners();

for (const account of accounts) {
    console.log(account.address);
}

import { ethers } from "hardhat";

async function main() {
  const Greeter = await ethers.getContractFactory("Greeter");
  const greeter = await Greeter.deploy("Hello, Hardhat!");
  const accounts = await ethers.getSigners();

  for (const account of accounts) {
    console.log(account.address);
  }

  await greeter.deployed();
  console.log("Greeter deployed to:", greeter.address);
}

main().catch((error) => {
  console.error(error);
  process.exitCode = 1;
});

다시 배포합니다.

$ npx hardhat run --network dev scripts/deploy.ts 

No need to generate any newer typings.
0x6b113534c1ef028e2F90d2338F491E49EB70879c
0x9BEae85001A0c3F09688345145498919423b5E8C
0xF7718Dd4e188C160A051834D6F37399D64b96F5A
0x9d56FFe5bF0DeAF33c70883681B09ecD0F010ac4
0x7A61860f47Bc42A865d9424d8eDC70705602300e
0xd673AFCD67FFD1dedc9FbAE4cEf0A08Eb0aCD13A
0xab90Abfe30dcfcf0318D4985C9d3518D24b14475
0x54E2F2BBEdb351d4eD12F34B1Df83e5fc061df1C
0xB70454565eA14AB414C80a540A1022Af43597628
0xD43B9c31624a17731336516b75177cCB40358741
Greeter deployed to: 0x825f751DAd1Cf797DF67d604c604A58e9B49c4b0

· 콘솔모드

hardhat도 truffle처럼 콘솔모드를 지원합니다.

$ npx hardhat console --network dev
No need to generate any newer typings.
Welcome to Node.js v14.17.3.
Type ".help" for more information.
>

> const { ethers } = require('hardhat');
undefined

> (await ethers.getSigners()).slice(0, 2).map(item => item.address)
[
  '0x6b113534c1ef028e2F90d2338F491E49EB70879c',
  '0x9BEae85001A0c3F09688345145498919423b5E8C'
]

> const Greeter = await ethers.getContractFactory("Greeter");
undefined
> const greeter = await Greeter.deploy("Hello, Hardhat!");
undefined
> const accounts = await ethers.getSigners();

> for (const account of accounts.slice(0, 2)) {
    console.log(account.address);
  }

0x6b113534c1ef028e2F90d2338F491E49EB70879c
0x9BEae85001A0c3F09688345145498919423b5E8C

> await greeter.deployed();

deployed()를 수행하면 먼가 쏼롸쏼라 많이 출력 합니다.

> console.log("Greeter deployed to:", greeter.address);
Greeter deployed to: 0x391947d818B5b4E9E9bD79600B51468771172F18

지금까지 hardhat을 이용하여 개발 - 컴파일 - 테스트 - 배포 과정을 알아보았습니다. 또한 scripts의 과정을 콘솔모드에서 직접 수행해보았습니다.

hardhat은 상당히 많은 기능을 제공합니다 .

저도 truffle에서 hardhat으로 넘어갈 생각입니다. 저도 써보면서 쓸만한 기능은 정리해서 공유하겠습니다

https://hardhat.org/

Hardhat | Ethereum development environment for professionals by Nomic Foundation

Hardhat is an Ethereum development environment. Compile your contracts and run them on a development network. Get Solidity stack traces, console.log and more.

hardhat.org

[ethereum] solidity withdrawals pattern(출금패턴)

멍개. — Sun, 28 Aug 2022 07:44:30 +0900

solidity에서 출금패턴을 다뤄보겠습니다.

제가 이 포스팅을 위해 삽질한 과정을 보고 싶다면

여기로 오시면 되겠습니다. 약 2시간 30분동안 삽질을 하였습니다.

☞ 목차

1. 준비
2. 입/출금 가능한 스마트 컨트랙트
3. 출금패턴
4. truffle 출금 패턴 테스트 코드 작성

● 준비

네트워크 준비, remix 네트워크 연결, metamask 네트워크 연결 및 계정준비

· 네트워크 구축

$ ganache-cli

Ganache CLI v6.12.2 (ganache-core: 2.13.2)

Available Accounts
==================
(0) 0xF3133758a5b12c99bdF762F93b86239a7Ef167f6 (100 ETH)
(1) 0x84A220f3bF83883eE93793F05506Ba512AfcBCCf (100 ETH)
(2) 0xCbf363bfbf2958725EDC0409dCd4Ea90cB94f7b6 (100 ETH)
(3) 0x7Af7683706De1F73871f7a5b5D81445E3EaE9AB2 (100 ETH)
(4) 0x9748D4c914f1b3a7B159992a0E133ad99F67EaDF (100 ETH)
(5) 0xA5a4E8d304D9D5BEc3076225d590d3bD9ccd22A2 (100 ETH)
(6) 0x14c3a4b9B0Ce420d89Ef188E1FAa536a6F4CEe25 (100 ETH)
(7) 0xC72C4B6e309b0a5A738694189523Ffa3acC86D34 (100 ETH)
(8) 0xfc6bA3aDd220Eb1B4333bbafF02C99a96c445477 (100 ETH)
(9) 0x84b5be354D9a343C0f16b98cE54E98Dcd0A57397 (100 ETH)

Private Keys
==================
(0) 0x2a137f79de5f0ade20e53bad9f7d73fa5852340df105e5b7d189f634eee6f4a9
(1) 0xfa995841f93e5dd4cdc1b61be3772d1f066b67049c3f58475aab298e66723c14
(2) 0xe38239192310bcde9c4c19a5daa7df1d0e0fa0de821083ecc511bedf5fca0536
(3) 0xec1d2c35bfbfc1c0c119af404cf60794c16d06f459a4653e9daafd94523145f7
(4) 0xc3b32dd7f90dc97bbfec3d2f552398fc94e436f0469e991747cf5f0148d2175f
(5) 0x740f283074364be311a485a5ae9e9cf5dd1ab131aba93721544cee7ee97871b9
(6) 0x162c0ac0a62f9eca99665d421497119cef6ab125022921ffc8638eab17572e67
(7) 0x2fb48a4042e9297165641a0f13f72a76dc8bda75445eb148bc09ab1035b388bd
(8) 0x3d062296e6463ac4e349526afe7ab95cdbc39ed2aca85e7ab5c61bb3784f8788
(9) 0x0fdcfc740f6095312eb2b2e1f4ff5494aca2e10559f08048e132768675177538

HD Wallet
==================
Mnemonic:      stairs another grid call actor genuine chunk hub solve picture weather settle
Base HD Path:  m/44'/60'/0'/0/{account_index}

Gas Price
==================
20000000000

Gas Limit
==================
6721975

Call Gas Limit
==================
9007199254740991

Listening on 127.0.0.1:8545

· remix 로컬 네트워크 연결

Web3 Provider 환경을 선택한 후 ganache-cli로 구축한 환경을 연결합니다.

IP: 127.0.0.1
PORT: 8545

· metamask 로컬 네트워크 연결

metamask는 크롬 확장프로그램으로 제공하는 이더리움 지갑입니다. 지갑은 출금 패턴을 위해 스마트 컨트랙트로 이더리움을 전송해야 하는데 이더리움 전송하기 위해 사용합니다.

ganache-cli에서 제공하는 지갑을가져오고 싶다면 각각의 개인키(private key)를 개별로 가져와도 되고 니모닉(mnemonic)으로 가져와도 됩니다.

니모닉으로 지갑 복구하기

개인키로 가져오기

● 입/출금 가능한 스마트 컨트랙트

출금패턴을 이해하기 위해선 스마트 컨트랙트가 이더리움을 어떤 식으로 입금/출금 하는지 이해해야 합니다.

· 입금 가능한 스마트 컨트랙트 만들기

solidity는 address payable 타입을 제공합니다. address와 유사하지만 다른 타입입니다. address payable 타입은 transfer() 메서드와 balance 속성을 제공합니다. transfer() 메서드는 to.transfer()의 형태로 작성 가능합니다.

to.transfer(amount)는 해당 스마트 컨트랙트에서 to에게 amount 만큼 이더리움을 전송합니다.

// SPDX-License-Identifier: GPL
pragma solidity 0.8.10;

contract Transfer {
    constructor () {}

    function balanceOf(address payable to) external view returns(uint) {
        return to.balance;
    }

    function transfer(address payable to, uint amount) external {
        to.transfer(amount);
    }
}

해당 컨트랙트를 배포합니다.

배포된 컨트랙트 주소(CA): 0xd1371201e390482429aF6BE4375604B790095391

이제 metamask로 해당 컨트랙트로 이더를 전송합니다.

1이더 전송을 시도합니다.

이더리움 전송을 실패합니다. 그 이유는 스마트 컨트랙트가 이더리움을 전송받기 위해선 특수한 함수가 필요합니다.

// SPDX-License-Identifier: GPL
pragma solidity 0.8.10;

contract Transfer {
    constructor () {}

    receive() external payable {}

    function balanceOf(address payable to) external view returns(uint) {
        return to.balance;
    }

    function transfer(address payable to, uint amount) external {
        to.transfer(amount);
    }
}

바로 receive() external payable 함수입니다. 해당 함수는 지갑으로 이더리움을 전송할 때 호출되는 함수입니다.

배포된 컨트랙트 주소(CA): 0x4d3063CD0e79DDF4d636b344802126F06CB0f41b

마찬가지로 metamask를 통해 해당 컨트랙트로 이더리움을 전송할 수 있습니다.

성공적으로 1ETH를 전송했습니다.

스마트 컨트랙트에 구현한 balanceOf 함수를 이용해서 스마트 컨트랙트의 이더리움 잔액 조회를 할 수 있습니다.

해당 컨트랙트에 1ETH가 조회되는 모습을 확인할 수 있습니다.

payable 키워드는 receive() 뿐 아니라 생성자(constructor) 또는 다른 함수에도 포함할 수 있습니다.

// SPDX-License-Identifier: GPL
pragma solidity 0.8.10;

contract Transfer {
    uint public amount = 0;
    
    constructor () payable {
        amount = msg.value;
    }

    receive() external payable {}

    function balanceOf(address payable to) external view returns(uint) {
        return to.balance;
    }

    function transfer(address payable to, uint _amount) external {
        to.transfer(_amount);
    }

    function test() public payable {
        amount = msg.value;
    }
}

payable로 지시된 함수는 remix 기준으로 다른 형태의 버튼UI로 표기됩니다.

Deploy 버튼을 보면 적색으로 표시됩니다. Deploy 버튼은 constructor()에 영향을 받습니다.

remix는 트랜잭션을 발생할 때 이더리움을 전송해야 한다면 녹색으로 표시한 VALUE 영역에 트랜잭션을 발생할 때 전송할 이더리움을 설정할 수 있습니다.

배포된 컨트랙트 주소: 0x29bbaC9A81b55a20E32aF944641559788207390a

VALUE에 1이더를 설정하고 Deploy 버튼을 눌렀습니다. 배포된 컨트랙트의 balanceOf를 이용하여 해당 컨트랙트의 이더리움 잔액을 확인하면 1이더가 있음을 확인할 수 있습니다.

msg 객체를 이용하여 누가 호출했고, 얼마의 이더를 전송했는지 알 수 있습니다.

msg.sender: 호출자
msg.value : 전송한 이더리움 양

만약, test() 함수를 호출 할 때 value를 입력하고 호출하면 해당 컨트랙트로 입력한 이더리움 양 만큼 전송을 합니다.

· 출금 가능한 스마트 컨트랙트 만들기

해당 컨트랙트에 있는 1ETH를 transfer() 함수를 호출하여 다른 주소로 전송할 수 있습니다. transfer()는 address payable에서 제공하는 메서드입니다.

앞에서 배포한 스마트 컨트랙트 코드에서 구현한 transfer() 함수를 살펴보겠습니다.

function transfer(address payable to, uint _amount) external {
    to.transfer(_amount);
}

우리가 만든 transfer() 함수는 2개의 인자를 전달받습니다.

첫 번째 인자인 to는 이더를 전송받을 주소입니다.

두 번째 인자인 _amount는 전송할 이더입니다. 이더리움은 decimals가 18이므로 1이더를 전송하기 위해선 1000000000000000000 만큼 전송해야 합니다.

스마트 컨트랙트의 1ETH중 0.5ETH 만큼 전송해보겠습니다.

to: 0xF3133758a5b12c99bdF762F93b86239a7Ef167f6
value: 0.5ETH (500000000000000000Wei)

transact 버튼을 누르면 트랜잭션이 발생하기 됩니다.

해당 컨트랙트 코드를 정상적으로 실행하지 못합니다. 그 이유는 출금을 할 경우에도 해당 함수에 payable이 붙어야 합니다.

배포된 컨트랙트 주소: 0x117c47cf20Cd24A88830f63204149A8229E7e269

스마트 컨트랙트의 이더를 다른 주소로 전송해보겠습니다.

to: 0x84A220f3bF83883eE93793F05506Ba512AfcBCCf
value: 0.5ETH (500000000000000000Wei)

스마트 컨트랙트에서 metamask에 존재하는 지갑으로 이더리움 전송을 완료했습니다.

· 스마트 컨트랙트에서 스마트 컨트랙트로 이더리움 전송

앞에서 transfer()를 이용하여 다른 주소로 이더리움을 전송하는 과정을 보았습니다. 컨트랙트 주소도 주소이기 때문에 to가 컨트랙트 주소일 수 있습니다.

그런데 receive()가 아니라 앞에서 test() payable 형태로 구현되어 있는 스마트 컨트랙트가 있을때 해당 컨트랙트의 test()를 호출하면서 이더리움을 전송하기 위해선 다음과 같이 해야합니다.

// test() payable 컨트랙트가 정의된 solidity 파일 이름
import './Transfer.sol';

contract TransferBridge {
  function transfer(address _to, uint _amount) external {
    Transfer(_to).test{value: _amount}();
  }
}

이런 형태로 컨트랙트에서 배포된 다른 컨트랙트의 함수를 호출할 수 있습니다. 함수이름과 () 사이에 {value: amount}를 포함하여 해당 기능을 수행할 수 있습니다. TransferBridge로 배포한 스마트 컨트랙트의 transfer를 호출하면 해당 컨트랙트에 있는 _amount 이더리움 만큼 Transfer로 전송합니다.

● 출금패턴

출금패턴은 스마트 컨트랙트의 이더리움을 외부로 전송하는 코드를 분리해서 작성하는 패턴입니다.

· 출금패턴이 필요한 이유

컨트랙트는 transfer()하는 대상이 외부 소유 계정(EOA), 컨트랙트 계정(CA)가 있습니다. transfer()를 호출할 때 EOA로 전송한다면 문제되지 않습니다.

하지만 receive() payable 또는 payable이 존재하지 않는 함수로 이더를 전송하려고 시도한다면? 반대로 컨트랙트의 특정 함수에 대해서만 이더 전송을 시도한다면 EOA는 함수가 존재하지 않기 때문에 문제가 발생할 수 있습니다.

· 출금 패턴을 적용하지 않은 코드 살펴보기

// SPDX-License-Identifier: GPL
pragma solidity 0.8.10;

contract NonWithdrawalContract {
    address payable public richest;
    uint public mostSent = 0;

    constructor() payable {
        richest = payable(msg.sender);
        mostSent = msg.value;
    }

    function becomeEther () external payable {
        if (msg.value > mostSent) {
            // richest가 receive()가 없는 컨트랙트라고 가정해보자!
            payable(richest).transfer(mostSent);
            richest = payable(msg.sender);
            mostSent = msg.value;
        } 
    }
}

해당 코드는 출금패턴을 적용하지 않은 코드입니다.

becomeEther() 함수만 살펴보겠습니다.

function becomeEther () external payable {
        if (msg.value > mostSent) {
            // richest가 receive()가 없는 컨트랙트라고 가정해보자!
            payable(richest).transfer(mostSent);
            richest = payable(msg.sender);
            mostSent = msg.value;
        } 
}

스마트 코드가 잘 동작하다가 receive()를 구현하지 않은 컨트랙트 주소가 richest에 저장되어 있다면?

해당 함수는 어디선가 richest를 바꾸지 않는다면 영영 정상적인 호출을 하지 못합니다. 또는 특정 컨트랙트의 함수를 호출하는 형태로도 작성할 수 있겠죠? 이땐 전송하는 목적지 주소가 반드시 특정 함수가 구현된 컨트랙트 주소여야 합니다.

하지만 스마트 컨트랙트는 주소만 가지고 앞의 여러 상황을 알 수 없습니다.

1. transfer()를 호출하는데 receive()를 구현한 스마트 컨트랙트 주소가 맞는지?
2. 다른 스마트 컨트랙트에 구현된 함수() payable로 전송하는데 스마트 컨트랙트 주소가 맞는지? 
   또는 함수 payable이 정상적으로 구현되어 있는지?

이런 복합적인 상황을 다 검사할 순 없습니다. 물론! 불가능한건 아니지만 너무 비효율적입니다.

여기서 비효율이란? 쓸데없는 검사를 위해 연산량이 올라가고 연산량이 증가하면 수수료가 많이 발생합니다.

· 출금 패턴 적용한 코드 살펴보기

출금 패턴은 아주 간단합니다. 앞에서 입/출금 만들면서 transfer() 함수를 이용하여 특정 함수에 출금에 관련한 코드밖에 없었습니다.

출금 패턴은 출금만 담당하는 코드를 별도로 분리하여 관리하는 것을 의미합니다. NonWithdrawalContract 여기선 becomeEther() 함수에 입금/출금 기능이 같이 있기 때문에 출금에 문제가 생기면 입금도 사용할 수 없습니다. 여기선 입금코드만 있지만 입금 외 여러가지 로직을 포함할 수 있겠죠?

// SPDX-License-Identifier: GPL
pragma solidity 0.8.10;

contract WithdrawalContract {
    address payable public richest;
    uint public mostSent;

    mapping (address => uint) pendingWithdrawals;

    constructor() public payable {
        richest = payable(msg.sender);
        mostSent = msg.value;
    }

    function becomeEther() public payable {
        if (msg.value > mostSent) {
            pendingWithdrawals[richest] += msg.value;
            richest = payable(msg.sender);
            mostSent = msg.value;
        }
    }

    function withdraw() public {
        uint amount = pendingWithdrawals[msg.sender];
        // 리엔트란시(re-entrancy) 공격을 예방하기 위해
        // 송금하기 전에 보류중인 환불을 0으로 기억해 두십시오.
        pendingWithdrawals[msg.sender] = 0;
        payable(msg.sender).transfer(amount);
    }
}

becomeEther()에서 호출한 transfer()를 withdraw() 함수로 옮겨줍니다. 대신 becomeEther()는 이더를 받는 함수이므로 mapping 타입을 이용하여 이더를 받은 주소를 관리합니다. 이렇게 하면 becomeEther()는 항상 성공하며, withdraw()는 msg.sender가 다음 조건을 만족하지 않는 경우에 대해서만 에러가 발생합니다.

1. transfer()를 호출하는데 receive()를 구현한 스마트 컨트랙트 주소가 맞는지? 2. 다른 스마트 컨트랙트에 구현된 함수() payable로 전송하는데 스마트 컨트랙트 주소가 맞는지? 또는 함수 payable이 정상적으로 구현되어 있는지?

● truffle 출금 패턴 테스트 코드 작성

마지막으로 truffle을 이용하여 출금 패턴을 적용하지 않은 코드에 대해서 에러가 나는 상황을 구현하고 이를 테스트하는 코드를 작성해보겠습니다.

이를 정확히 이해한다면, 출금 패턴을 적용하면 에러가 나지 않는 상황을 이해할 수 있을겁니다.

· 프로젝트 생성

truffle은 init 명령어로 프로젝트를 생성할 수 있습니다.

$ mkdir withdraw-patterns

$ cd withdraw-patterns

$ truffle init

error assertions 테스트와 이더리움 단위 변환을 위해 다음 2개의 라이브러리를 설치합니다.

$ npm install --save truffle-assertions
$ npm install --save web3

다음으로 truffle-config.js을 다음과 같이 수정합니다.

module.exports = {
  networks: {
    dev: {
     host: "127.0.0.1",     
     port: 8545,            
     network_id: "*",       
    },
  },
  mocha: {},

  compilers: {
    solc: {
      version: "0.8.10",  
     
    }
  }
};

networks는 스마트 컨트랙트를 배포할 환경 정보를 관리합니다. networks는 json 형태로 여러 환경을 관리할 수 있습니다.

module.exports = {
  networks: {
    dev: {
     host: "127.0.0.1",     
     port: 8545,            
     network_id: "*",       
    },
    propd: {
     host: "192.168.1.1",     
     port: 8546,            
     network_id: "*",       
    },
  },
  mocha: {},

  compilers: {
    solc: {
      version: "0.8.10",  
     
    }
  }
};

· 시나리오 설계

이 부분은 저도 처음에 출금 패턴 테스트 코드를 작성하기 위해 시간이 다소 오래걸렸던 부분입니다.

1. 3개의 컨트랙트를 준비한다.

NonWithdrawalContract: 출금패턴을 적용하지 않은 컨트랙트

PayableContract: receive()가 구현된 컨트랙트

NonPayableContract: receive()를 구현하지 않은 컨트랙트

2. NonWithdrawalContract 배포

3. PayableContract 배포 - 배포할 때 2ETH를 전송한다. constructor()는 payable를 포함합니다.

4. NonPayableContract 배포 - 배포할 때 2ETH를 전송한다. receive()는 constructor()는 payable를 포함합니다.

5. richest가 PayableContract일때와 NonPayableContract인 상황 만들기

대략적인 시나리오는 이정도 입니다.

각각의 시나리오는 truffle에선 다음과 같이 작업할 수 있습니다.

contracts: 1번 

migrations: 2번, 3번, 4번

test: 5번

truffle 프로젝트를 생성하면 3개의 디렉터리를 생성합니다.

contracts: 스마트 컨트랙트 코드 관리
migrations: 배포관리
test: 실질적인 동작을 수행하며, 정상적으로 동작하는지 테스트 가능

· 스마트 컨트랙트 코드 작성

스마트 컨트랙트 코드는 contracts 아래에서 관리합니다. 3개의 코드를 작성합니다.

▶ NonWithdrawalContract.sol

// SPDX-License-Identifier: GPL
pragma solidity 0.8.10;

contract NonWithdrawalContract {
    address payable public richest;
    uint public mostSent = 0;

    constructor() payable {
        richest = payable(msg.sender);
        mostSent = msg.value;
    }

    function becomeEther () external payable {
        if (msg.value > mostSent) {
            // richest가 receive()가 없는 컨트랙트라고 가정해보자!
            payable(richest).transfer(mostSent);
            richest = payable(msg.sender);
            mostSent = msg.value;
        } 
    }
}

▶ PayableContract.sol

// SPDX-License-Identifier: GPL
pragma solidity 0.8.10;

import './NonWithdrawPattern.sol';

contract PayableContract {
  constructor () payable {}

  receive () external payable{}

  function send(address _to, uint _amount) external {
    NonWithdrawalContract(_to).becomeEther{value: _amount}();
  }

  function balanceOf() public view returns(uint) {
      return payable(this).balance;
  }
}

▶ NonWithdrawPattern.sol

// SPDX-License-Identifier: GPL
pragma solidity 0.8.10;

import './NonWithdrawPattern.sol';

contract NonPayableContract {
  constructor () payable {}

  function send(address _to, uint _amount) external {
    NonWithdrawalContract(_to).becomeEther{value: _amount}();
  }
}

이렇게 작성된 코드는 compile 명령어를 이용하여 컴파일 할 수 있습니다.

$ truffle compile

Compiling your contracts...
===========================
> Compiling ./contracts/Migrations.sol
> Compiling ./contracts/NonPayableContract.sol
> Compiling ./contracts/NonWithdrawPattern.sol
> Compiling ./contracts/PayableContract.sol
> Compiling ./contracts/WithdrawPattern.sol
> Compilation warnings encountered:

    Warning: Visibility for constructor is ignored. If you want the contract to be non-deployable, making it "abstract" is sufficient.
  --> project:/contracts/WithdrawPattern.sol:10:5:
   |
10 |     constructor() public payable {
   |     ^ (Relevant source part starts here and spans across multiple lines).


> Artifacts written to /Users/jeongtaepark/Desktop/withdraw-patterns/build/contracts
> Compiled successfully using:
   - solc: 0.8.10+commit.fc410830.Emscripten.clang

우리가 작성한 코드가 문제 없으면 다음과 같이 build 디렉터리가 생성되며, 배포를 위한 준비가 끝납니다.

아마 0.8.10 기준으로 warning이 하나 뜨게 되는데 이건 추후에 별도로 다뤄보겠습니다.

· 배포

배포는 migrations 아래에서 관리합니다. 3개의 컨트랙트를 배포하는 코드를 작성합니다.

web3의 utils를 이용하면 이더단위를 편하게 바꿀 수 있습니다. 굳이 0을 17~18번 작성하지 않아도 됩니다.

▶ 2_PayableContract_migration.js

const PayableContract = artifacts.require("PayableContract");
const web3 = require('web3');

module.exports = function (deployer) {
  deployer.deploy(PayableContract, {value: web3.utils.toWei("2", "ether")});
};

truffle은 트랜잭션 발생할 때 마지막 인자에 {value: amount, from: address}를 전달하여 트랜잭션 정보를 포함할 수 있습니다.

▶ 3_NonPayableContract_migration.js

const NonPayableContract = artifacts.require("NonPayableContract");
const web3 = require('web3');

module.exports = function (deployer) {
  deployer.deploy(NonPayableContract, {value: web3.utils.toWei("2", "ether")});
};

▶ 4_NonWithdrawContract_migration.js

const NonWithdrawalContract = artifacts.require("NonWithdrawalContract");
const web3 = require('web3');

module.exports = function (deployer) {
  deployer.deploy(NonWithdrawalContract);
};

이제 우리는 배포를 위한 코드 작성을 마쳤습니다.

truffle은 migrate 명령어를 이용하여 스마트 컨트랙트를 배포할 수 있습니다. remix에서 deploy를 누르는 과정으로 이해하면 됩니다.

$ truffle migrate --network dev

이떄 --network 옵션으로 dev를 주게 되는데 이건 truffle-comfig.js의 network에 정의한 dev로 관리중인 정보에 배포한다는 의미입니다.

Compiling your contracts...
===========================
> Everything is up to date, there is nothing to compile.



Starting migrations...
======================
> Network name:    'dev'
> Network id:      1639353530182
> Block gas limit: 6721975 (0x6691b7)


1_initial_migration.js
======================

   Deploying 'Migrations'
   ----------------------
   > transaction hash:    0xaaf21cb53b1b6cf831b871bc8904bf878d38819e2a480169c5365dbc6c69a5be
   > Blocks: 0            Seconds: 0
   > contract address:    0xeb68a074e9C1A482f816202035ce550d30e25253
   > block number:        15
   > block timestamp:     1639359582
   > account:             0xF3133758a5b12c99bdF762F93b86239a7Ef167f6
   > balance:             94.96525818
   > gas used:            248854 (0x3cc16)
   > gas price:           20 gwei
   > value sent:          0 ETH
   > total cost:          0.00497708 ETH


   > Saving migration to chain.
   > Saving artifacts
   -------------------------------------
   > Total cost:          0.00497708 ETH


2_PayableContract_migration.js
==============================

   Deploying 'PayableContract'
   ---------------------------
   > transaction hash:    0xaef5081a44fe3f3f191451b733a95356c19de138109903afecb21e108b480d76
   > Blocks: 0            Seconds: 0
   > contract address:    0x634B0759c0d13599879b97B4f38eaD7A7cB5758D
   > block number:        17
   > block timestamp:     1639359583
   > account:             0xF3133758a5b12c99bdF762F93b86239a7Ef167f6
   > balance:             92.96091778
   > gas used:            174507 (0x2a9ab)
   > gas price:           20 gwei
   > value sent:          2 ETH
   > total cost:          2.00349014 ETH


   > Saving migration to chain.
   > Saving artifacts
   -------------------------------------
   > Total cost:          2.00349014 ETH


3_NonPayableContract_migration.js
=================================

   Deploying 'NonPayableContract'
   ------------------------------
   > transaction hash:    0x2ea04740632169ac427e93903b92700ccd879e79b71fc0b99bab23b826dbddc4
   > Blocks: 0            Seconds: 0
   > contract address:    0x6367D6059FbBd0c7832847d702588f01c6077cF1
   > block number:        19
   > block timestamp:     1639359583
   > account:             0xF3133758a5b12c99bdF762F93b86239a7Ef167f6
   > balance:             90.95737322
   > gas used:            149715 (0x248d3)
   > gas price:           20 gwei
   > value sent:          2 ETH
   > total cost:          2.0029943 ETH


   > Saving migration to chain.
   > Saving artifacts
   -------------------------------------
   > Total cost:           2.0029943 ETH


4_NonWithdrawContract_migration.js
==================================

   Deploying 'NonWithdrawalContract'
   ---------------------------------
   > transaction hash:    0xdd86457548e6d54915c626d51121e1d8286a9979aedc218540ea4ccf4c6d8959
   > Blocks: 0            Seconds: 0
   > contract address:    0x37892D4862c7Fce93752a5b8af8484dEEBFD3E3E
   > block number:        21
   > block timestamp:     1639359583
   > account:             0xF3133758a5b12c99bdF762F93b86239a7Ef167f6
   > balance:             90.95277612
   > gas used:            202342 (0x31666)
   > gas price:           20 gwei
   > value sent:          0 ETH
   > total cost:          0.00404684 ETH


   > Saving migration to chain.
   > Saving artifacts
   -------------------------------------
   > Total cost:          0.00404684 ETH


Summary
=======
> Total deployments:   4
> Final cost:          4.01550836 ETH

우리가 작성한 3개의 컨트랙트 배포를 정상적으로 마쳤습니다.

각 항목의 contract address가 배포된 컨트랙트 주소입니다.

· 동작 확인하기

동작을 수행하고 확인하는 코드는 test 아래에서 관리합니다.

const PayableContract = artifacts.require("PayableContract");
const NonPayableContract = artifacts.require("NonPayableContract");

const NonWithdrawalContract = artifacts.require("NonWithdrawalContract");
const truffleAssert = require('truffle-assertions');

const web3 = require('web3');

describe("test", function(accounts) {
  
  before(async function () {
    /* 
      배포된 컨트랙트 가져오기, 
      1. 출금패턴 비적용, 
      2. 이더수신 불가능, 
      3. 이더수신 가능 
    */
    this.instance = await NonWithdrawalContract.deployed(); 
    this.nonPayableContract = await NonPayableContract.deployed();
    this.payableContract = await PayableContract.deployed();
  })

  it('최고 전송자, 금액 바뀌는 경우 by PayableContract', async function() {
    const to = NonWithdrawalContract.address;
    const amount = web3.utils.toWei('0.1', 'ether');
    await this.payableContract.send(to, amount); 
    const richest = await this.instance.richest();
    const mostSent = await this.instance.mostSent();
    
    assert.strictEqual(richest, this.payableContract.address);
    assert.strictEqual(mostSent.toString(), amount);
  })
  
  it('최고 전송자가 바뀌지 않는경우 by NonPayableContract', async function() {
    const to = NonWithdrawalContract.address
    const amount = web3.utils.toWei('0.1', 'ether');
  
    await this.nonPayableContract.send(to, amount); 
    
    const richest = await this.instance.richest();
    const mostSent = await this.instance.mostSent();
    
    assert.strictEqual(richest, this.payableContract.address);
    assert.strictEqual(mostSent.toString(), amount);
  })
  
  it('최고 전송자가 바뀌는 경우 by NonPayableContract', async function() {
    const to = NonWithdrawalContract.address
    const amount = web3.utils.toWei('0.2', 'ether');
  
    await this.nonPayableContract.send(to, amount); 
    
    const richest = await this.instance.richest();
    const mostSent = await this.instance.mostSent();
    
    assert.strictEqual(richest, this.nonPayableContract.address);
    assert.strictEqual(mostSent.toString(), amount);
  })

  it('NonPayable -> Payable로 다시 바뀌는 경우: NonPayable에게 NonPayable.transfer 발생: 지금부터 NonWithdrawContract의 mostSent보다 높은 이더 전송시 에러', async function () {
    // 해당 케이스는 반드시 에러가 발생한다.
    // NonWithdrawalContract의 richest는 receive()가 구현되어 있지 않기 때문에 .transfer()가 정상동작 할 수 없다.
    // NonWithdrawalContract 해당 컨트랙트는 richest를 바꿀 수 있는 방법이 없기 때문에 더이상 동작하지 않는 코드가 된다.

    const to = NonWithdrawalContract.address;
    const amount = web3.utils.toWei('0.3', 'ether');
    const tx = this.payableContract.send(to, amount); 

    await truffleAssert.reverts(
      tx,
      'revert'
    );
  })

  it('에러1', async function () {
    const to = NonWithdrawalContract.address;
    const amount = web3.utils.toWei('0.4', 'ether');
    const tx = this.payableContract.send(to, amount); 

    await truffleAssert.reverts(
      tx,
      'revert'
    );
  })
  
  it('에러2', async function () {

    const to = NonWithdrawalContract.address;
    const amount = web3.utils.toWei('0.4', 'ether');
    const tx = this.payableContract.send(to, amount); 

    await truffleAssert.reverts(
      tx,
      'revert'
    );
  })

  it('에러3', async function () {
    const to = NonWithdrawalContract.address;
    const amount = web3.utils.toWei('0.4', 'ether');
    const tx = this.nonPayableContract.send(to, amount); 

    await truffleAssert.reverts(
      tx,
      'revert'
    );
  })
})

동작을 수행하기 위해 test를 이용합니다.

$ truffle test --network dev

Using network 'dev'.

Compiling your contracts...
===========================
> Everything is up to date, there is nothing to compile.

  test
    ✓ 최고 전송자, 금액 바뀌는 경우 by PayableContract (97ms)
    ✓ 최고 전송자가 바뀌지 않는경우 by NonPayableContract (87ms)
    ✓ 최고 전송자가 바뀌는 경우 by NonPayableContract (100ms)
    ✓ NonPayable -> Payable로 다시 바뀌는 경우: NonPayable에게 NonPayable.transfer 발생: 지금부터 NonWithdrawContract의 mostSent보다 높은 이더 전송시 에러 (267ms)
    ✓ 에러1 (66ms)
    ✓ 에러2 (80ms)
    ✓ 에러3 (77ms)

  7 passing (806ms)

여기선 7개의 항목에 대한 동작을 테스트합니다.

각각의 테스트 항목이 무엇을 테스트 하는지 살펴보겠습니다.

before(async function () {
    /* 
      배포된 컨트랙트 가져오기, 
      1. 출금패턴 비적용, 
      2. 이더수신 불가능, 
      3. 이더수신 가능 
    */
    this.instance = await NonWithdrawalContract.deployed(); 
    this.nonPayableContract = await NonPayableContract.deployed();
    this.payableContract = await PayableContract.deployed();
  })

해당 코드는 우리가 배포한 컨트랙트를 가져오는 것을 의미합니다.

▶ PayableOntract가 최고 전송자(richest)가 되는경우

it('최고 전송자, 금액 바뀌는 경우 by PayableContract', async function() {
  const to = NonWithdrawalContract.address;
  const amount = web3.utils.toWei('0.1', 'ether');
  await this.payableContract.send(to, amount); 
  const richest = await this.instance.richest();
  const mostSent = await this.instance.mostSent();
  
  assert.strictEqual(richest, this.payableContract.address);
  assert.strictEqual(mostSent.toString(), amount);
})

payableContract가 최초로 이더를 전송하기 때문에 최고 전송자가 됩니다. 이때 0.1ETH를 전송합니다.

▶ 최고 전송자(richest)가 바뀌지 않는경우

it('최고 전송자가 바뀌지 않는경우 by NonPayableContract', async function() {
  const to = NonWithdrawalContract.address
  const amount = web3.utils.toWei('0.1', 'ether');
  
  await this.nonPayableContract.send(to, amount); 
  
  const richest = await this.instance.richest();
  const mostSent = await this.instance.mostSent();
  
  assert.strictEqual(richest, this.payableContract.address);
  assert.strictEqual(mostSent.toString(), amount);
})

NonPayableContract가 이더를 전송하지만 현재 최고 전송자보다 더 많은 금액을 전송하지 않았기 때문에 바뀌지 않습니다.

▶ NonPayableContract로 최고 전송자(richest)가 바뀌는 경우

it('최고 전송자가 바뀌는 경우 by NonPayableContract', async function() {
  const to = NonWithdrawalContract.address
  const amount = web3.utils.toWei('0.2', 'ether');
  
  await this.nonPayableContract.send(to, amount); 
  
  const richest = await this.instance.richest();
  const mostSent = await this.instance.mostSent();
  
  assert.strictEqual(richest, this.nonPayableContract.address);
  assert.strictEqual(mostSent.toString(), amount);
})

NonPayableContract가 기존 최고 전송자보다 더 많은 ETH를 전송했기 때문에 최고 전송자가 바뀌고 기존 최고 전송자인 PayableContract에게 0.1 이더를 돌려줍니다.

여기선 NonWithdrawalsContract의 richest, mostSent만 검사했지만 PayableContract의 이더리움 잔액도 검사해야 합니다.

(각 컨트랙트의 잔액 조회까지 들어가면 코드량이 너무 증가할 것 같아 PayableContract, NonPayableContract의 이더리움 잔액 조회 코드는 포함하지 않았습니다.)

▶ PayableContract로 최고 전송자가 다시 바뀌는 상황

it('NonPayable -> Payable로 다시 바뀌는 경우: NonPayable에게 NonPayable.transfer 발생: 지금부터 NonWithdrawContract의 mostSent보다 높은 이더 전송시 에러', async function () {
  // 해당 케이스는 반드시 에러가 발생한다.
  // NonWithdrawalContract의 richest는 receive()가 구현되어 있지 않기 때문에 .transfer()가 정상동작 할 수 없다.
  // NonWithdrawalContract 해당 컨트랙트는 richest를 바꿀 수 있는 방법이 없기 때문에 더이상 동작하지 않는 코드가 된다.

  const to = NonWithdrawalContract.address;
  const amount = web3.utils.toWei('0.3', 'ether');
  const tx = this.payableContract.send(to, amount); 

  await truffleAssert.reverts(
    tx,
    'revert'
  );
})

최고 전송자가 바뀌면서 NonPayableContract에게 transfer()로 호출하기 때문에 에러가 발생합니다.

  await truffleAssert.reverts(
    tx,
    'revert'
  );

에러가 발생하는지 검사하는 코드입니다.

▶ 계속 에러 발생

it('에러1', async function () {
    const to = NonWithdrawalContract.address;
    const amount = web3.utils.toWei('0.4', 'ether');
    const tx = this.payableContract.send(to, amount); 

    await truffleAssert.reverts(
      tx,
      'revert'
    );
  })
  
  it('에러2', async function () {

    const to = NonWithdrawalContract.address;
    const amount = web3.utils.toWei('0.4', 'ether');
    const tx = this.payableContract.send(to, amount); 

    await truffleAssert.reverts(
      tx,
      'revert'
    );
  })

  it('에러3', async function () {
    const to = NonWithdrawalContract.address;
    const amount = web3.utils.toWei('0.4', 'ether');
    const tx = this.nonPayableContract.send(to, amount); 

    await truffleAssert.reverts(
      tx,
      'revert'
    );
  })

이후 누가 이더를 전송하든 항상 에러가 발생합니다. 만약, NonWithdrawalsContract가 출금 패턴을 적용했다면 PayableContract가 호출하는 에러1, 에러2는 정상적으로 호출됩니다.

샘플 코드는 깃허브로 공유합니다.

https://github.com/pjt3591oo/truffle-withdrawal-pattern

GitHub - pjt3591oo/truffle-withdrawal-pattern

Contribute to pjt3591oo/truffle-withdrawal-pattern development by creating an account on GitHub.

github.com

[ethereum] truffle을 이용하여 스마트 컨트랙트 개발하기

멍개. — Sun, 28 Aug 2022 07:30:53 +0900

ruffle을 이용하여 스마트 컨트랙트를 개발하는 방법을 다룹니다.

● 셋업

$ npm install -g truffle

· 프로젝트 생성

$ mkdir dapp
$ cd dapp

$ truffle init

init 명령어를 사용하여 truffle 기반의 프로젝트를 생성할 수 있습니다.

$ tree
.
├── contracts
│   └── Migrations.sol
├── migrations
│   └── 1_initial_migration.js
├── test
└── truffle-config.js

3 directories, 3 files

▶ contracts

solidity 코드 관리

▶ migrations

스마트 컨트랙트 배포 관리

▶ test

테스트 코드 작성

▶ build

build는 컴파일 결과를 관리합니다.

프로젝트 생성시에는 없지만 compile을 하면 build/contracts 아래에 metadata.json를 생성합니다.

$ truffle compile

▶truffle-config.js

네트워크 연결정보 및 solidity compiler 버전 정보 등을 관리합니다.

/**
 * trufflesuite.com/docs/advanced/configuration
*/

// const HDWalletProvider = require('@truffle/hdwallet-provider');
// const fs = require('fs');
// const mnemonic = fs.readFileSync(".secret").toString().trim();

module.exports = {
  networks: {
    dev: {
     host: "127.0.0.1",
     port: 8545,       
     network_id: "*",
    },
  },
  mocha: {},
  compilers: {
    solc: {
      version: "0.8.10",
    }
  },
};

network는 더 많은 정보를 넣을 수 있습니다. 이외에 더 많은 정보를 설정할 수 있습니다.

https://trufflesuite.com/docs/truffle/reference/configuration

Configuration - Truffle Suite

Configuration Location Your configuration file is called truffle-config.js and is located at the root of your project directory. This file is a Javascript file and can execute any code necessary to create your configuration. It must export an object repres

trufflesuite.com

● 개발 프로세스

일반적으로 개발이라하면 다음과 같은 프로세스에 맞춰서 개발합니다.

1. 소스코드 작성

2. 컴파일 & 빌드

3. 배포

4. 개별적으로 실행해보기

5. 테스트 하기

truffle은 이런 일련의 과정을 코드 및 명령어 기반으로 수행할 수 있습니다.

· 소스코드 작성

소스코드는 contracts 아래에서 관리합니다.

파일명: contracts/Mung.sol

// SPDX-License-Identifier: UNLICENSED 
pragma solidity ^0.8.9; 

contract Mung {
    string public text; 

    constructor(string memory _text) { 
        text = _text;
    }
    
    function setText(string memory _text) public{
        text = _text;
    }

    function errorOccur(uint a) public pure returns (uint) {
        require(a != 0, "hello world error");
        return a;
    }
}

· 컴파일 및 빌드

$ truffle compile

Compiling your contracts...
===========================
> Compiling ./contracts/HelloWorld.sol
> Compiling ./contracts/Migrations.sol
> Compiling ./contracts/Mung.sol
> Artifacts written to /Users/jeongtaepark/Desktop/ethereum-truffle-sample/build/contracts
> Compiled successfully using:
   - solc: 0.8.10+commit.fc410830.Emscripten.clang

빌드를 성공적으로 완료하면 build/contracts/*.json를 생성합니다.

· 스마트컨트랙트 배포

truffle은 migrate 명령어만으로 아주 쉽게 배포를 할 수 있습니다.

배포에 대한 코드는 migrations 아래에서 관리합니다. 이 코드는 생성자 전달할 인자를 정의합니다.

파일명: migrations/2_Mung.js

여기서 한가지 중요한 점은 migrations는 다른 디렉터리와 다르게 "숫자_"를 prefix해야 합니다.

const Mung = artifacts.require("Mung");

module.exports = function (deployer) {
  deployer.deploy(Mung, "Hello Mung~");
};

$ truffle migrate --network [truffle-config에 명시한 network]

여기선 dev로 노드 정보를 작성했기 때문에 --network dev를 전달합니다.

$ truffle migrate --network dev

Compiling your contracts...
===========================
> Everything is up to date, there is nothing to compile.

> Something went wrong while attempting to connect to the network at http://127.0.0.1:8545. Check your network configuration.

Could not connect to your Ethereum client with the following parameters:
    - host       > 127.0.0.1
    - port       > 8545
    - network_id > *
Please check that your Ethereum client:
    - is running
    - is accepting RPC connections (i.e., "--rpc" or "--http" option is used in geth)
    - is accessible over the network
    - is properly configured in your Truffle configuration file (truffle-config.js)

Truffle v5.4.22 (core: 5.4.22)
Node v14.17.3

앗! 에러가!!!

할 시간에 에러를 읽으세요 제발좀...

해당 에러는 dev로 정의한 노드를 연결할 수 없다는 에러입니다. 당연히 연결을 못하죠. 노드가 로컬에 없으니

$ npm install -g ganache-cli
$ ganache-cli

ganache-cli를 이용하여 가상의 네트워크를 만듭니다.

다시 migrate하면 정상적으로 스마트 컨트랙트를 배포할 수 있습니다.

Compiling your contracts...
===========================
> Everything is up to date, there is nothing to compile.

Starting migrations...
======================
> Network name:    'dev'
> Network id:      1637999164665
> Block gas limit: 6721975 (0x6691b7)

2_Mung.js
=========

   Deploying 'Mung'
   ----------------
   > transaction hash:    0xb390ac6cc6cfe4b52220d0388e5b595fd1b79696de1ed1ced5b6fe373a6347ab
   > Blocks: 0            Seconds: 0
   > contract address:    0x680d78685dE52F50201bC4e5b1723Daf44Bc6449
   > block number:        5
   > block timestamp:     1637999206
   > account:             0x19258f77721790dB2cEBe89fdBE1f241BCA95202
   > balance:             99.97578014
   > gas used:            425863 (0x67f87)
   > gas price:           20 gwei
   > value sent:          0 ETH
   > total cost:          0.00851726 ETH


   > Saving migration to chain.
   > Saving artifacts
   -------------------------------------
   > Total cost:          0.00851726 ETH


Summary
=======
> Total deployments:   3
> Final cost:          0.02281934 ETH

· 실행

실행은 해당 컨트랙트의 함수 및 변수를 콘솔모드에서 호출할 수 있습니다.

$ truffle console --network dev
truffle(dev)>

truffle(network)>는 콘솔모드입니다.

▶ 배포한 컨트랙트 가져오기

truffle(dev)> contract = await Mung.deployed()

▶ text 변수 값 가져오기

truffle(dev)> contract.text.call()
'Hello Mung~'

▶ setText() 함수 호출

truffle(dev)> contract.setText( 'mung', { from: accounts[0] } )
{
  tx: '0x06e58ff5e6c6f3dd45d433549a0c0a299d88dea3d621c8f6b1ec5bc44984f8d2',
  receipt: {
    transactionHash: '0x06e58ff5e6c6f3dd45d433549a0c0a299d88dea3d621c8f6b1ec5bc44984f8d2',
    transactionIndex: 0,
    blockHash: '0x8bd35ce4b109100374e15f3bfe70995fa0e2f9a2ff534ec69fbc1b05e6c1ed15',
    blockNumber: 7,
    from: '0x19258f77721790db2cebe89fdbe1f241bca95202',
    to: '0x680d78685de52f50201bc4e5b1723daf44bc6449',
    gasUsed: 29574,
    cumulativeGasUsed: 29574,
    contractAddress: null,
    logs: [],
    status: true,
    logsBloom: '0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000',
    rawLogs: []
  },
  logs: []
}

setText()는 트랜잭션을 발생하기 위해 마지막 인자로 트랜잭션을 발생할 주소를 전달합니다. 만약 {from: accounts[0]}이 없다면 기본으로 accounts[0]가 트랜잭션을 만듭니다.

▶ text 변수 값 가져오기

truffle(dev)> contract.text.call()
'mung'

truffle(dev)> contract.text()
'mung'

원하는 스타일로 작성합니다. 개인적으로 call()을 호출해서 사용하는 방법을 선호합니다.

▶ error를 일으키는 함수 정상 호출

truffle(dev)> contract.errorOccur(1, { from: accounts[0]})
BN { negative: 0, words: [ 1, <1 empty item> ], length: 1, red: null }

▶ error를 일으키는 함수 정상 호출

truffle(dev)> contract.errorOccur(0, { from: accounts[0]})
Uncaught:
Error: Returned error: VM Exception while processing transaction: revert hello world error

· 테스트하기

코드가 바뀔 때마다 앞의 과정을 반복적으로 한다면 아주 멍개같은 짓 입니다. 똑개는 절대 저렇게 테스트하지 않습니다.

테스트 코드는 test 아래에서관리합니다.

그 전에 라이브러리 하나를 설치하겠습니다.

$ npm install --save truffle-assertions

truffle-assertions은 revert가 발생하는 것을 테스트할 수 있습니다.

파일명: test/test_mung.js

const truffleAssert = require('truffle-assertions');
const Mung = artifacts.require("Mung");

contract("Mung", accounts => {
 // 각각의 테스트 케이스인 it을 실행할 때마다 before 실행하여 스마트 컨트랙트 객체를 가져옴
 before(async () => {
   this.instance = await Mung.deployed();
 })

 it("should be initialized with correct value", async () => {
   // 스마트 컨트랙트에 정의된 text() 함수 호출
   const text = await this.instance.text(); 
   assert.equal(text, "Hello Mung~", "Wrong initialized value!");
 });

 it("should change the text", async () => {
   const changedText = 'hoho';
   // 스마트 컨트랙트에 정의된 setText() 함수 호출
   // 마지막 객체는 트랜잭션 발생 정보를 가진다.
   await this.instance.setText(changedText, {from: accounts[0]});
   // 스마트 컨트랙트에 정의된 say() 함수 호출
   const text = await this.instance.text();
   assert.equal(text, changedText, "dose not change the value!");
 });

 it("should throw exception", async () => {
   // 스마트 컨트랙트에 정의된 errorOccur() 함수 호출
   await truffleAssert.reverts(
     this.instance.errorOccur(0, {from: accounts[0]}),
     "hello world error"
   )
 });

 it("should not throw exception", async () => {
   // 스마트 컨트랙트에 정의된 errorOccur() 함수 호출
   const rst = await this.instance.errorOccur(1, {from: accounts[0]});
   assert.equal(rst.words[0], 1, "ErrorOccur event not emitted!");
 });
})

$ truffle test --network dev
Using network 'dev'.


Compiling your contracts...
===========================
> Everything is up to date, there is nothing to compile.



  Contract: HelloWorld
    ✓ should be initialized with correct value
    ✓ should change the greeting (199ms)
    ✓ should throw exception (239ms)

  Contract: Mung
    ✓ should be initialized with correct value
    ✓ should change the text (190ms)
    ✓ should throw exception
    ✓ should not throw exception


  7 passing (838ms)

여기까지 진행했다면 다음과 같은 구조가 됩니다.

.
├── README.md
├── build
│   └── contracts
│       ├── Migrations.json
│       └── Mung.json
├── contracts
│   ├── Migrations.sol
│   └── Mung.sol
├── migrations
│   ├── 1_initial_migration.js
│   └── 2_Mung.js
├── package-lock.json
├── package.json
├── test
│   └── test_mung.js
└── truffle-config.js

5 directories, 11 files

여기서 진행한 코드는 깃허브에서 확인 가능합니다.

https://github.com/pjt3591oo/ethereum-truffle-sample

GitHub - pjt3591oo/ethereum-truffle-sample

Contribute to pjt3591oo/ethereum-truffle-sample development by creating an account on GitHub.

github.com

[ethereum] solidity overflow, underflow에 대해서

멍개. — Sun, 28 Aug 2022 07:23:50 +0900

solidity 8.x부터 overflow, underflow가 발생하는 연산은 revert가 발생합니다.

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.10;

contract Test {
    function f(uint a, uint b) pure public returns(uint) {
        return a - b;
    }
}

0에서 1을 감소하면 underflow가 발생하기 때문에 revert가 발생합니다.

만약 의도적인 underflow를 발생해야 한다면 unchecked를 이용하면 됩니다.

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.10;

contract Test {
    function g(uint a, uint b) pure public returns(uint) {
        unchecked { return a - b; }
    }
}

[ethereum] input data의 methodId와 event signature 만드는 방법

멍개. — Sun, 28 Aug 2022 07:19:51 +0900

● methodId

etherscan을 보다보면 input Data가 다음과 같이 출력되는 모습을 볼 수 있습니다.

원래의 input data로 변환하면 다음과 같습니다.

여기서 methodID는 어떤 원리로 만들어 지는지 알아보겠습니다.

· solidity

contract Test {
    function setA() public pure returns (bytes memory) {
       // return bytes4(keccak256('balanceOf(address)')); 해당 방법도 가능
       return abi.encodeWithSignature("transfer(address,uint256)");
    }
}

· web3

const Web3 = require('web3');
const web3 = new Web3()

console.log(web3.eth.abi.encodeFunctionSignature("transfer(address,uint256)"))

0xa9059cbb

abi를 object 형태로 전달하는 방법도 있습니다.

const Web3 = require('web3');
const web3 = new Web3()

web3.eth.abi.encodeFunctionSignature({
  name: 'transfer',
  type: 'function',
  inputs: [{
      type: 'address',
      name: 'to'
  },{
      type: 'uint256',
      name: 'value'
  }]
})

0xa9059cbb

● event signature

· web3js

web3.eth.abi.encodeEventSignature("Transfer(address,address,uint256)")

web3.eth.abi.encodeEventSignature({
  name: 'Transfer',
  type: 'event',
  inputs: [{
    indexed: true,
    type: 'address',
    name: 'from'
  }, {
    indexed: true,
    type: 'address',
    name: 'to'
  },{
    type: 'uint256',
    name: 'value'
  }]
})

0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef
0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef

[solidity] library, enum

멍개. — Sun, 28 Aug 2022 07:16:47 +0900

· library

library는 컨트랙트를 라이브러리처럼 사용할 수 있도록 도와줍니다. 다만 library를 사용하기 위해선 using ~ for ~ 키워드를 이용합니다.

pragma solidity 0.8.9;

library MyLibrary {
    struct data {
        string name;  
        uint age;
    }
    
    function add(uint a, uint b) external pure returns (uint) {
        return a + b;
    }
}

library Math {
    function add (uint _a, uint _b) external pure returns (uint) {
        return _a + _b;
    }
    
    function sub (uint _a, uint _b) external pure returns (uint) {
        return _a - _b;
    }
}

contract MyContract {
    
    using MyLibrary for MyLibrary.data;
    using Math for *;

    MyLibrary.data charactor;

    function getA () public view returns (MyLibrary.data memory) {
        return charactor;
    }
    
    function setA (string memory _name, uint _age) public  {
        charactor = MyLibrary.data(_name, _age);
    }
    
    function mathAdd (uint _a, uint _b) public pure returns (uint) {
        return Math.add(_a, _b);
    }
    
    function mathSub (uint _a, uint _b) public pure returns (uint) {
        return Math.sub(_a, _b);
    }
}

만약 MyLibrary와 Math를 별도의 파일로 분리한다고 하면 import로 가져온 후 사용할 수 있습니다.

// library.sol
pragma solidity 0.8.9;

library MyLibrary {
    struct data {
        string name;  
        uint age;
    }
    
    function add(uint a, uint b) external pure returns (uint) {
        return a + b;
    }
}

library Math {
    function add (uint _a, uint _b) external pure returns (uint) {
        return _a + _b;
    }
    
    function sub (uint _a, uint _b) external pure returns (uint) {
        return _a - _b;
    }
}

pragma solidity 0.8.9;

import './library.sol';

contract MyContract {
    
    using MyLibrary for MyLibrary.data;
    using Math for *;

    MyLibrary.data charactor;

    
    function getA () public view returns (MyLibrary.data memory) {
        return charactor;
    }
    
    function setA (string memory _name, uint _age) public  {
        charactor = MyLibrary.data(_name, _age);
    }
    
    function mathAdd (uint _a, uint _b) public pure returns (uint) {
        return Math.add(_a, _b);
    }
    
    function mathSub (uint _a, uint _b) public pure returns (uint) {
        return Math.sub(_a, _b);
    }
}

· enum

pragma solidity 0.8.9;

contract MyContract {
    enum  bb { a1, a2, a3 }
    
    function getA() public pure returns (bb) {
        return bb.a1;
    }
}

enum은 연속된 자연수를 특정 문자열에 맵핑하여 관리할 때 유용합니다.

enum은 상수를 변수로 관리하는데 의의가 있습니다.

[solidity] 에러함수 - require, revert, assert

멍개. — Sun, 28 Aug 2022 07:15:03 +0900

olidity는 require, revert, assert가 호출되면 에러를 발생하고 rollback을 수행합니다. rollback이란 함수가 호출되기 전의 상태로 돌아가는 것을 의미합니다.

롤백(rollback)은 데이터베이스 관점에서 매우 중요합니다.

· revert + error

pragma solidity ^0.8.4;

error WowError(uint x, uint y);

contract SimpleStorage {
    uint public storedData;
 
    function set(uint x) public {
        if (x == 3){
            revert WowError(1, x);
        }
        storedData = x;
    }
}

revert()는 호출 됨과 동시에 에러를 발생시켜 rollback 처리합니다. 이때 error로 정의된 함수를 호출하여 커스텀 메시지를 만들 수 있습니다.

solidity에서는 에러를 만드는 방법이 몇가지 있습니다. revert()를 호출하는 방법도 있지만 require을 이용하는 방법도 있습니다.

revert 말고 require, assert도 존재합니다. revert는 require, assert 처럼 나온지는 한참되었습니다. 하지만 error 함수는 0.8.4 버전 이후에 등장했습니다.

revert 함수만 다루면 require과 assert가 섭섭해할테니 간략하게 다뤄보겠습니다.

· require

pragma solidity ^0.8.4;

contract SimpleStorage {
    uint storedData;
 
    function set(uint x) public {
        require(x != 3, "x is not 3");
        storedData = x;
    }
 
    function get() view public returns (uint) {
        return storedData;
    }
}

require은 첫 번째 인자로 boolean을 전달하고 두 번째 인자로 에러 메시지를 전달합니다. 첫 번째 인자가 false인 경우 에러를 발생시키고 두 번째 인자로 전달한 문자열을 알려줍니다.

require()의 두 번째 인자는 옵셔널하기 때문에 꼭 전달하지 않아도 됩니다.

· assert

pragma solidity ^0.8.4;

contract SimpleStorage {
    uint storedData;
 
    function set(uint x) public {
     
        storedData = x;
        
        assert(storedData != 3);
    }
 
    function get() view public returns (uint) {
        return storedData;
    }
}

require: 소유권 검사
revert: 데이터 유효성 검사 및 사전검사(예: 정상적으로 데이터가 들어왔는지, 계산에 필요한 만큼 값을 가지고 있는지)
assert: 연산 후 유효성 검사(예: overflow, underflow 검사)

여기서 assert의 검사를 빼먹는 경우가 종종 있는데 assert를 이용해서 반드시 overflow와 underflow 처리를 해야합니다.

※ overflow와 underflow

pragma solidity ^0.7.4;

contract SimpleStorage {
    uint min = 0;
    uint max = 115792089237316195423570985008687907853269984665640564039457584007913129639935;
    function under() public view returns( uint) {
        return min - 1;
    }
    
    function over() public view returns( uint) {
        return max + 1;
    }
}

over 함수는 연산 결과는 최댓값에서 + 1을 하여 다시 0으로 돌아옵니다. 이를 오버플로우(overflow)라고 부릅니다.

under 함수는 최소값인 0에서 - 1을 하여 최대값이 됩니다. 이를 언더플로우(underflow)라고 합니다.

assert는 overflow, underflow 뿐 아니라 연산 결과가 정확히 나왔는지 검사하는것이 매우 중요하며 앞의 예시는 solidity 0.8.x 이후에선 발생하지 않습니다.

pragma solidity를 통해 다른 버전을 명시한 후 remix에서 컴파일러 버전을 바꿔주면 됩니다.

pragma solidity ^0.8.4;

contract SimpleStorage {
    uint min = 0;
    uint max = 115792089237316195423570985008687907853269984665640564039457584007913129639935;
    function under() public view returns( uint) {
        return min - 1;
    }
    
    function over() public view returns( uint) {
        return max + 1;
    }
}

값에서 overflow, underflow가 일어나면 내부적으로 revert를 발생합니다.

[Ethereum] genesis 초기화 시 cannot unmarshal 에러 해결법

멍개. — Sun, 28 Aug 2022 07:12:23 +0900

안녕하세요 멍개입니다.

geth를 이용하여 네트워크 구축 시 genesis 파일을 만들게 됩니다.

{
  "config": {
    "chainId": 1234,
    "homesteadBlock": 0,
    "eip150Block": "0x0000000000000000000000000000000000000000000000000000000000000000",
    "eip155Block": 0,
    "eip158Block": 0,
    "byzantiumBlock": 0,
    "constantinopleBlock": 0,
    "petersburgBlock": 0,
    "istanbulBlock": 0,
    "berlinBlock": 0,
    "londonBlock": 0,
    "ethash": {}
  },
  "alloc": {
    "56aE1237F0D3E2F21683Bd04402092E26f469813":{"balance":"30000000000000000000000"},  
    "55e2d8BF452e1E7D70eb375B527fd38B281B00cF":{"balance":"30000000000000000000000" }
  },
  "coinbase": "0x56aE1237F0D3E2F21683Bd04402092E26f469813",
  "difficulty": "0x20000",
  "extraData": "",
  "gasLimit": "0x2fefd8",
  "nonce": "0x0000000000000042",
  "mixhash": "0x0000000000000000000000000000000000000000000000000000000000000000",
  "parentHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
  "timestamp": "0x00"
}

해당 내용으로 genesis.json으로 만들었다면 다음과 같이 genesis 초기화를 시킬 수 있습니다.

$ geth --datadir $PWD init genesis.json
Fatal: invalid genesis file: math/big: cannot unmarshal "\"0000000000000000000000000000000000000000000000000000000000000000\"" into a *big.Int

해당 에러는 0x000000이 Int 타입이 아니라 발생하는 에러입니다.

{
  "config": {
    "chainId": 1234,
    "homesteadBlock": 0,
    "eip150Block": 0,
    "eip155Block": 0,
    "eip158Block": 0,
    "byzantiumBlock": 0,
    "constantinopleBlock": 0,
    "petersburgBlock": 0,
    "istanbulBlock": 0,
    "ethash": {}
  },
  "alloc": {
    "56aE1237F0D3E2F21683Bd04402092E26f469813":{"balance":"30000000000000000000000"},  
    "55e2d8BF452e1E7D70eb375B527fd38B281B00cF":{"balance":"30000000000000000000000" }
  },
  "coinbase": "0x56aE1237F0D3E2F21683Bd04402092E26f469813",
  "difficulty": "0x20000",
  "extraData": "",
  "gasLimit": "0x2fefd8",
  "nonce": "0x0000000000000042",
  "mixhash": "0x0000000000000000000000000000000000000000000000000000000000000000",
  "parentHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
  "timestamp": "0x00"
}

정상적으로 초기화되는 모습을 확인할 수 있습니다.

[Ethereum] EIP1559 네워크축 구축을 위한 제네시스 설정방법

멍개. — Sun, 28 Aug 2022 07:10:24 +0900

geth를 이용하여 노드를 구축할 때 EIP1559 사용가능한 형태로 노드를 띄우는 방법을 알아보겠습니다.

본론으로 들어가기 앞서서 EIP1559 방식이 무엇인지 궁금하다면 다음 링크에서 EIP1559가 무엇인지 간략하게 알 수 있습니다.

2022.08.28 - [블록체인] - [Ethereum] EIP1559 GETH, Ganache-cli 사용해보기

[Ethereum] EIP1559 GETH, Ganache-cli 사용해보기

현재 이더리움은 EIP1559 적용이 되었습니다. EIP1559 적용 후 트랜잭션 발생시 gas 사용방법이 바뀌었습니다. ▶ before(Legacy) { from, to, gas: 25000, gasPrice: '21000000000', value: '1000000000000..

meongae.tistory.com

EIP1559 방식을 사용하기 위해선 geth 프로그램 1.10.8 버전이후여야 합니다. 사실 앞의 블로그를 작성할 땐 geth 1.10.7 버전이었는데 해당 버전의 깃허브 README에서 genesis 정보를 제대로 알려주지 않아 EIP1559 방식의 트랜잭션을 발생할 수 없었습니다. 물론 README가 정리되어 있지 않더라도 코드(parmas/config.go)에서 어떤 설정값들을 넣어줘야 하는지 알 수 있습니다.

버전: 1.10.7

하지만 최신버전을 확인하면 다음과 같이 config에 londonBlock이 추가된 모습을 볼 수 있습니다.

버전: 1.10.8

londonBlock이 있어야 EIP1559 방식으로 트랜잭션을 발생할 수 있습니다.

{
  "config": {
    "chainId": "임의의 값",
    "homesteadBlock": 0,
    "eip150Block": 0,
    "eip155Block": 0,
    "eip158Block": 0,
    "byzantiumBlock": 0,
    "constantinopleBlock": 0,
    "petersburgBlock": 0,
    "istanbulBlock": 0,
    "berlinBlock": 0,
    "londonBlock": 0
  },
  "alloc": {},
  "coinbase": "0x0000000000000000000000000000000000000000",
  "difficulty": "0x20000",
  "extraData": "",
  "gasLimit": "0x2fefd8",
  "nonce": "0x0000000000000042",
  "mixhash": "0x0000000000000000000000000000000000000000000000000000000000000000",
  "parentHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
  "timestamp": "0x00"
}

네트워크 구축 하는 방법은 기존에 방법과 동일하므로 다음 링크를 참고해주세요

2022.08.27 - [블록체인] - [ethereum] Geth를 이용하여 Ethash 기반 private network 구축하기

[ethereum] Geth를 이용하여 Ethash 기반 private network 구축하기

Geth를 이용하여 Ethash(POW) 기반 private network 구축하는 방법을 알아보겠습니다. Geth는 POW(Ethash), POA(Clique), POS(Caspre)를 선택적으로 운용가능합니다. 여기선 개념적인 내용보다 방법론적인..

meongae.tistory.com

● 트랜잭션 발생

트랜잭션 발생할 때 기존 방식(Legacy)은 gas와 gasPrice를 전달합니다. EIP1559는 gasPrice 대신 maxFeePerGas, maxPriorityFeePerGas를 전달합니다.

· Legacy

> eth.sendTransaction({
    from: eth.accounts[0],
    to: eth.accounts[1],
    gas: 25000,
    gasPrice: '21000000000',
    value: '10000000'
})

· EIP1559

eth.sendTransaction({
    from: eth.accounts[0],
    to: eth.accounts[1],
    gas: 25000,
    maxFeePerGas: "0xb2d05e00",         // 3000000000 = 3Gwei
    maxPriorityFeePerGas: "0xb2d05e00", // 3000000000 = 3Gwei
    value: '10000000'
})

● 트랜잭션 조회

트랜잭션을 조회하면 type으로 Legacy, EIP1559 트랜잭션을 구분할 수 있습니다.

· Legacy

· EIP1559

EIP1559도 gasPrice가 존재합니다. Legacy와 다르게 사용자가 지정하지 않고 프로토콜 레벨에서 결정됩니다. 마치 블록 생성시 difficulty가 블럭생성 주기를 결정하기 위해 증가/감소 되는 것 처럼 특정 알고리즘에 의해 결정합니다.

● genesis config 확인

추가적으로 각 네트워크 별 genesis설정은 깃허브에서 확인가능합니다.

https://github.com/ethereum/go-ethereum/blob/master/params/config.go

GitHub - ethereum/go-ethereum: Official Go implementation of the Ethereum protocol

Official Go implementation of the Ethereum protocol - GitHub - ethereum/go-ethereum: Official Go implementation of the Ethereum protocol

github.com

main network

ropsten network

Ethash는 POW로 동작하는 네트워크 입니다.

rinkeyby network

goerli network

Clique는 POA로 동작하는 네트워크입니다.

[Ethereum] EIP1559 GETH, Ganache-cli 사용해보기

멍개. — Sun, 28 Aug 2022 07:06:13 +0900

현재 이더리움은 EIP1559 적용이 되었습니다.

EIP1559 적용 후 트랜잭션 발생시 gas 사용방법이 바뀌었습니다.

▶ before(Legacy)

{
    from,
    to,
    gas: 25000,
    gasPrice: '21000000000',
    value: '1000000000000000'
}

▶ after(EIP1559)

{
    from,
    to,
    gas: 25000,
    maxFeePerGas: "0xb2d05e00",         // 3000000000 = 3Gwei
    maxPriorityFeePerGas: "0xb2d05e00", // 3000000000 = 3Gwei
    value: '1000000000000000'
}

기존의 gasPrice가 maxFeePerGas와 maxProorityFeePerGas로 나뉘어졌습니다. gasPrice는 이제 노드 프로토콜 레이어에서 결정합니다.

maxFeePerGass는 사용자가 최대 사용할 가스를 지정합니다. 만약 가스 사용이 이를 초과할 경우 트랜잭션은 취소되며, 초과하지 않으면 남은만큼 트랜잭션 발생 대상자에게 돌려줍니다.

maxPriorityFeePerGas는 트랜잭션을 블록에 포함시킨 마이너 계정에게 보상할 수수료 입니다. 기존 방식에선 수수료 모두를 마이너가 가져갔지만 EIP1559에선 maxPriorityFeePerGas만큼만 마이너가 가져갑니다.

● 노드 프로그램에서 지원여부

이더리움 노드 프로그램으로 geth, ganache-cli가 있습니다.

· geth

· ganache-cli

두 프로그램 모두 EIP1559 방식의 트랜잭션 발생이 안됩니다. 아무래도 노드 설정이 필요한 것 같은데 기본적으로 지원을 하고있지 않은 모습을 확인할 수 있습니다.

● EIP1559 트랜잭션 VS Legacy 트랜잭션

EIP1559 트랜잭션과 Legacy 트랜잭션은 타입으로 구분할 수 있습니다.

EIP1559: 0x02 Legacy : 0x00

· EIP1559 트랜잭션

· Legacy 트랜잭션

geth, ganache-cli 모두 지원이 안되는데 어찌 트랜잭션이 발생되는가..... 하면 다음 사이트에서 키를 발급받은 후 해당 노드를 이용하면 됩니다.

https://infura.io/

Ethereum API | IPFS API & Gateway | ETH Nodes as a Service

Infura's development suite provides instant, scalable API access to the Ethereum and IPFS networks. Connect your app to Ethereum and IPFS now, for free!

infura.io

[ethereum] ERC721을 이용한 NFT 만들기 - 3편

멍개. — Sun, 28 Aug 2022 07:02:35 +0900

NFT 생성기 NFT 등록 로딩중 모바일

▶ ropsten 네트워크 배포

https://ropsten.etherscan.io/token/0x4fAb976447Abfab5ba35C94e298865409a9ddc6c

() Token Tracker | Etherscan

() Token Tracker on Etherscan shows the price of the Token $0.00, total supply 0, number of holders 1 and updated information of the token. The token tracker page also shows the analytics and historical data.

ropsten.etherscan.io

▶ ropsten 네트워크 배포 - NFT 생성기

https://inspiring-newton-bf922b.netlify.app

NFT Generator

inspiring-newton-bf922b.netlify.app

▶ solidity 0.5에서 0.8.9로 컨버팅

ERC721의 인터페이스가 아닌 mint 함수를 추상 컨트랙트를 통해 인터페이스를 제공하여 명확한 형태의 코드로 개선하였습니다.

https://github.com/Exchange-M/NFT-ERC721

GitHub - Exchange-M/NFT-ERC721: ERC721 for NFT

ERC721 for NFT. Contribute to Exchange-M/NFT-ERC721 development by creating an account on GitHub.

github.com

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.9;

import 'https://github.com/Exchange-M/NFT-ERC721/blob/master/ERC721.sol';

contract Minty_ERC721 is Minty, ERC721 {
    // Counters.Counter 타입인 _ownedTokensCount[uint]가 library Counters에 정의된 increment(), decrement(), current()를 호출하기 위해 필요
    using Counters for Counters.Counter;
    
    function _mint(address to, uint256 tokenId) internal override {
        require(to != address(0), "ERC721: mint to the zero address");
        require(!_exists(tokenId), "ERC721: token already minted");

        _tokenOwner[tokenId] = to;
        _ownedTokensCount[to].increment();

        emit Transfer(address(0), to, tokenId);
    }
}

contract CharactorByERC721 is Minty_ERC721 {
    struct Charactor {
        string  name;  // 캐릭터 이름
        uint256 level; // 캐릭터 레벨
    }

    Charactor[] public charactors; // default: [] 
    address public owner;          // 컨트랙트 소유자

    constructor () {
        owner = msg.sender; 
    }

    modifier isOwner() {
      require(owner == msg.sender);
      _;
    }

    // 캐릭터 생성
    function mint(string memory name, address account) public isOwner {
        uint256 cardId = charactors.length; // 유일한 캐릭터 ID
        charactors.push(Charactor(name, 1));
        _mint(account, cardId); // ERC721 소유권 등록
    }
}

[ethereum] ERC721을 이용한 NFT 만들기 - 2편

멍개. — Sun, 28 Aug 2022 06:57:06 +0900

지난 시간에 우리는 NFT의 기본 개념과 ERC721을 이용하여 구현해보았습니다.

2022.08.28 - [블록체인] - [ethereum] ERC721을 이용한 NFT 만들기 - 1편

[ethereum] ERC721을 이용한 NFT 만들기 - 1편

ERC721 기반의 NFT를 만들어 본 후 가볍게 실습을 진행해보는 시간을 가져보도록 하겠습니다. · NFT란? 최소한 NFT가 무엇인지부터 살펴보자. NFT는 대체 불가능한 토큰을 의미합니다. 여기서 대체

meongae.tistory.com

1편에서 작성한 코드를 추상화하여 좀 더 클린한 형태로 발전시켜 보겠습니다.

우리가 구현한 실제 비즈니스 로직이 포함된 코드는 다음과 같습니다.

contract CharactorByERC721 is ERC721{
    struct Charactor {
        string  name;  // 캐릭터 이름
        uint256 level; // 캐릭터 레벨
    }

    Charactor[] public charactors; // default: [] 
    address public owner;          // 컨트랙트 소유자

    constructor () public {
        owner = msg.sender; 
    }

    modifier isOwner() {
      require(owner == msg.sender);
      _;
    }

    // 캐릭터 생성
    function mint(string memory name, address account) public isOwner {
        uint256 cardId = charactors.length; // 유일한 캐릭터 ID
        charactors.push(Charactor(name, 1));
        _mint(account, cardId); // ERC721 소유권 등록
    }
}

그렇다면, 우리는 이외의 코드는 굳이 직접 작성할 필요는 없습니다. 하지만 울리가 앞서서 ERC721 컨트랙트 인터페이스로 제공하지 않는 _mint()를 추가하였는데 이를 확장하고 우리가 개발에 집중할 수 있는 형태로 제공해보겠습니다.

function _mint(address to, uint256 tokenId) internal {
    require(to != address(0), "ERC721: mint to the zero address");
    require(!_exists(tokenId), "ERC721: token already minted");
    _tokenOwner[tokenId] = to;
    _ownedTokensCount[to].increment();
    emit Transfer(address(0), to, tokenId);
}

자 먼저 _mint에서 접근하는 녀석들을 알아보아야 합니다. _tokenOwner, _ownedTokensCount, _exists를 접근하고 있습니다.

// 토큰 ID에서 소유자로의 매핑
mapping (uint256 => address) private _tokenOwner;

// 토큰 ID에서 승인된 주소로의 매핑
mapping (uint256 => address) private _tokenApprovals;

function _exists(uint256 tokenId) internal view returns (bool) {
    address owner = _tokenOwner[tokenId];
    return owner != address(0);
}

이를 상속받은 컨트랙트에서 접근할 수 있도로 접근자를 수정합니다. 접근자는 private에서 interval로 바꿔줍니다.

// 토큰 ID에서 소유자로의 매핑
mapping (uint256 => address) interval _tokenOwner;

// 토큰 ID에서 승인된 주소로의 매핑
mapping (uint256 => address) internal _tokenApprovals;

function _exists(uint256 tokenId) internal view returns (bool) {
    address owner = _tokenOwner[tokenId];
    return owner != address(0);
}

· 수정된 ERC721 컨트랙트 코드

contract ERC721 is ERC165, IERC721 {
    using SafeMath for uint256;
    using Address for address;
    using Counters for Counters.Counter;

    bytes4 private constant _ERC721_RECEIVED = 0x150b7a02;

    mapping (uint256 => address) internal _tokenOwner;

    mapping (uint256 => address) internal _tokenApprovals;

    mapping (address => Counters.Counter) internal _ownedTokensCount;

    mapping (address => mapping (address => bool)) private _operatorApprovals;

    bytes4 private constant _INTERFACE_ID_ERC721 = 0x80ac58cd;

    constructor () public {
        _registerInterface(_INTERFACE_ID_ERC721);
    }

    function balanceOf(address owner) public view returns (uint256) {
        require(owner != address(0), "ERC721: balance query for the zero address");

        return _ownedTokensCount[owner].current();
    }

    function ownerOf(uint256 tokenId) public view returns (address) {
        address owner = _tokenOwner[tokenId];
        require(owner != address(0), "ERC721: owner query for nonexistent token");

        return owner;
    }

    function approve(address to, uint256 tokenId) public {
        address owner = ownerOf(tokenId);
        require(to != owner, "ERC721: approval to current owner");

        require(msg.sender == owner || isApprovedForAll(owner, msg.sender),
            "ERC721: approve caller is not owner nor approved for all"
        );

        _tokenApprovals[tokenId] = to;
        emit Approval(owner, to, tokenId);
    }

    function getApproved(uint256 tokenId) public view returns (address) {
        require(_exists(tokenId), "ERC721: approved query for nonexistent token");

        return _tokenApprovals[tokenId];
    }

    function setApprovalForAll(address to, bool approved) public {
        require(to != msg.sender, "ERC721: approve to caller");

        _operatorApprovals[msg.sender][to] = approved;
        emit ApprovalForAll(msg.sender, to, approved);
    }

    function isApprovedForAll(address owner, address operator) public view returns (bool) {
        return _operatorApprovals[owner][operator];
    }

    function transferFrom(address from, address to, uint256 tokenId) public {
        //solhint-disable-next-line max-line-length
        require(_isApprovedOrOwner(msg.sender, tokenId), "ERC721: transfer caller is not owner nor approved");

        _transferFrom(from, to, tokenId);
    }

    function safeTransferFrom(address from, address to, uint256 tokenId) public {
        safeTransferFrom(from, to, tokenId, "");
    }

    function safeTransferFrom(address from, address to, uint256 tokenId, bytes memory _data) public {
        transferFrom(from, to, tokenId);
        require(_checkOnERC721Received(from, to, tokenId, _data), "ERC721: transfer to non ERC721Receiver implementer");
    }

    function _exists(uint256 tokenId) internal view returns (bool) {
        address owner = _tokenOwner[tokenId];
        return owner != address(0);
    }

    function _isApprovedOrOwner(address spender, uint256 tokenId) internal view returns (bool) {
        require(_exists(tokenId), "ERC721: operator query for nonexistent token");
        address owner = ownerOf(tokenId);
        return (spender == owner || getApproved(tokenId) == spender || isApprovedForAll(owner, spender));
    }

    function _burn(address owner, uint256 tokenId) internal {
        require(ownerOf(tokenId) == owner, "ERC721: burn of token that is not own");

        _clearApproval(tokenId);

        _ownedTokensCount[owner].decrement();
        _tokenOwner[tokenId] = address(0);

        emit Transfer(owner, address(0), tokenId);
    }

    function _burn(uint256 tokenId) internal {
        _burn(ownerOf(tokenId), tokenId);
    }

    function _transferFrom(address from, address to, uint256 tokenId) internal {
        require(ownerOf(tokenId) == from, "ERC721: transfer of token that is not own");
        require(to != address(0), "ERC721: transfer to the zero address");

        _clearApproval(tokenId);

        _ownedTokensCount[from].decrement();
        _ownedTokensCount[to].increment();

        _tokenOwner[tokenId] = to;

        emit Transfer(from, to, tokenId);
    }

    function _checkOnERC721Received(address from, address to, uint256 tokenId, bytes memory _data)
        internal returns (bool)
    {
        if (!to.isContract()) {
            return true;
        }

        bytes4 retval = IERC721Receiver(to).onERC721Received(msg.sender, from, tokenId, _data);
        return (retval == _ERC721_RECEIVED);
    }

    function _clearApproval(uint256 tokenId) private {
        if (_tokenApprovals[tokenId] != address(0)) {
            _tokenApprovals[tokenId] = address(0);
        }
    }
}

https://github.com/Exchange-M/NFT-ERC721/blob/master/ERC721.sol

이제 우리는 깃허브에 배포한 파일을 가져와서 ERC721의 _mint를 구현한 후 비즈니스 로직에 집중할 수 있습니다. 기능 여하에 따라 코드를 개선한 후 올려도 됩니다.

· 개선코드 적용

pragma solidity ^0.5.0;

import 'https://github.com/Exchange-M/NFT-ERC721/blob/master/ERC721.sol';

contract ERC721Impl is ERC721 {
    function _mint(address to, uint256 tokenId) internal {
        require(to != address(0), "ERC721: mint to the zero address");
        require(!_exists(tokenId), "ERC721: token already minted");

        _tokenOwner[tokenId] = to;
        _ownedTokensCount[to].increment();

        emit Transfer(address(0), to, tokenId);
    }
}

contract CharactorByERC721 is ERC721Impl{
    struct Charactor {
        string  name;  // 캐릭터 이름
        uint256 level; // 캐릭터 레벨
    }

    Charactor[] public charactors; // default: [] 
    address public owner;          // 컨트랙트 소유자

    constructor () public {
        owner = msg.sender; 
    }

    modifier isOwner() {
      require(owner == msg.sender);
      _;
    }

    // 캐릭터 생성
    function mint(string memory name, address account) public isOwner {
        uint256 cardId = charactors.length; // 유일한 캐릭터 ID
        charactors.push(Charactor(name, 1));
        _mint(account, cardId); // ERC721 소유권 등록
    }
}

이런 형태로 작성할 수 있습니다. 코드 자체가 훨씬 클린해졌습니다.

추각적으로 ERC721 컨트랙트에 있는 메서드들 중에 _burn 또한 ERC721의 기본 인터페이스가 아니므로 상속받은 컨트랙트에서 구성할 수 있습니다.

정상적으로 배포된 모습을 확인할 수 있습니다.

[ethereum] ERC721을 이용한 NFT 만들기 - 1편

멍개. — Sun, 28 Aug 2022 06:53:29 +0900

ERC721 기반의 NFT를 만들어 본 후 가볍게 실습을 진행해보는 시간을 가져보도록 하겠습니다.

· NFT란?

최소한 NFT가 무엇인지부터 살펴보자. NFT는 대체 불가능한 토큰을 의미합니다. 여기서 대체 불가능한 토큰이 의미하는 바가 무엇인지 알아보도록 하겠습니다.

대체 가능한 토큰 예시

앞의 그림처럼 A와 B는 서로 1000원을 가지고 있습니다. 만약, 서로가 천원을 서로 주고받더라도 각각의 1000원은 동일한 가치를 가집니다. 여기서 1000원 대신 특정 물건으로 대체해보겠습니다. 앞의 예시와 다르게 특정 물건은 고유한 유니크 값을 가지고 있습니다. 같은 정보를 가지고 있는 데이터라고 하더라도 생성일이 다르기 때문에 유니크한 값으로 만들 수 있습니다. 이러한 특성을 대체 불가능하다고 합니다.

A가 만든 캐릭터는 누가 가지고 있던간에 A가 만든 캐릭터라는 속성을 가지고 있습니다. 즉, 누가 가지고 있더라도 A가 만들었고 고유한 속성을 그대로 가지고 있습니다. 이때 이들은 데이터로 움직이기 때문에 캐릭터 정보를 다 움직이는 것이 아닌 캐릭터에 할당된 유니크한 값(ID)값으로 주고 받으며 캐릭터 하나하나를 토큰으로 취급합니다.

만약, A가 캐릭터를 10개 소유하고 있다면 10개의 토큰을 가지고 있는겁니다.

ERC20으로 만들어진 토큰의 경우 특정 주소가 소유하고 있는 토큰을 조회하면 지불하여 사용 가능한 토큰 수량을 조회하며, ERC721로 만들어진 NFT의 경우 보유중인 대체 불가능한 무언가를 소유하고 있는 수량입니다.

여기서 무언가는 어떻게 어떤 형태로 만드냐에 따라 결정됩니다.

NFT를 만들기 위해 우리는 만들어져있는 인터페이스를 활용할 수 있습니다.

● NFT 구현

NFT를 구현하기 위해 어떤 인터페이스를 제공하는지 알아보겠습니다.

event Transfer(address indexed _from, address indexed _to, uint256 indexed _tokenId);
event Approval(address indexed _owner, address indexed _approved, uint256 indexed _tokenId);
event ApprovalForAll(address indexed _owner, address indexed _operator, bool _approved);

function balanceOf(address _owner) external view returns (uint256);
function ownerOf(uint256 _tokenId) external view returns (address);
function safeTransferFrom(address _from, address _to, uint256 _tokenId, bytes data) external payable;
function safeTransferFrom(address _from, address _to, uint256 _tokenId) external payable;
function transferFrom(address _from, address _to, uint256 _tokenId) external payable;
function approve(address _approved, uint256 _tokenId) external payable;
function setApprovalForAll(address _operator, bool _approved) external;
function getApproved(uint256 _tokenId) external view returns (address);
function isApprovedForAll(address _owner, address _operator) external view returns (bool);
function supportsInterface(bytes4 interfaceID) external view returns (bool);

우리는 해당 인터페이스를 직접 구현하지 않고 구현된 인터페이스를 기반으로 우리가 원하는 기능을 구현할것입니다.

· interface(인터페이스)

library Address {

    function isContract(address account) internal view returns (bool) {
        uint256 size;
        assembly { size := extcodesize(account) }
        return size > 0;
    }
}

library SafeMath {

    function add(uint256 a, uint256 b) internal pure returns (uint256) {
        uint256 c = a + b;
        require(c >= a, "SafeMath: addition overflow");

        return c;
    }

    function sub(uint256 a, uint256 b) internal pure returns (uint256) {
        require(b <= a, "SafeMath: subtraction overflow");
        uint256 c = a - b;

        return c;
    }

    function mul(uint256 a, uint256 b) internal pure returns (uint256) {
        if (a == 0) {
            return 0;
        }

        uint256 c = a * b;
        require(c / a == b, "SafeMath: multiplication overflow");

        return c;
    }

    function div(uint256 a, uint256 b) internal pure returns (uint256) {
        require(b > 0, "SafeMath: division by zero");
        uint256 c = a / b;

        return c;
    }

    function mod(uint256 a, uint256 b) internal pure returns (uint256) {
        require(b != 0, "SafeMath: modulo by zero");
        return a % b;
    }
}

library Counters {
    using SafeMath for uint256;

    struct Counter {
        uint256 _value; // 기본값: 0
    }

    function current(Counter storage counter) internal view returns (uint256) {
        return counter._value;
    }

    function increment(Counter storage counter) internal {
        counter._value += 1;
    }

    function decrement(Counter storage counter) internal {
        counter._value = counter._value.sub(1);
    }
}

interface IERC165 {
    function supportsInterface(bytes4 interfaceId) external view returns (bool);
}

contract ERC165 is IERC165 {
    bytes4 private constant _INTERFACE_ID_ERC165 = 0x01ffc9a7;

    mapping(bytes4 => bool) private _supportedInterfaces;

    constructor () internal {
        _registerInterface(_INTERFACE_ID_ERC165);
    }

    function supportsInterface(bytes4 interfaceId) external view returns (bool) {
        return _supportedInterfaces[interfaceId];
    }

    function _registerInterface(bytes4 interfaceId) internal {
        require(interfaceId != 0xffffffff, "ERC165: invalid interface id");
        _supportedInterfaces[interfaceId] = true;
    }
}

contract IERC721 is IERC165 {
    event Transfer(address indexed from, address indexed to, uint256 indexed tokenId);
    event Approval(address indexed owner, address indexed approved, uint256 indexed tokenId);
    event ApprovalForAll(address indexed owner, address indexed operator, bool approved);

    function balanceOf(address owner) public view returns (uint256 balance);

    function ownerOf(uint256 tokenId) public view returns (address owner);

    function safeTransferFrom(address from, address to, uint256 tokenId) public;

    function transferFrom(address from, address to, uint256 tokenId) public;
    function approve(address to, uint256 tokenId) public;
    function getApproved(uint256 tokenId) public view returns (address operator);

    function setApprovalForAll(address operator, bool _approved) public;
    function isApprovedForAll(address owner, address operator) public view returns (bool);


    function safeTransferFrom(address from, address to, uint256 tokenId, bytes memory data) public;
} 

contract IERC721Receiver {
    function onERC721Received(address operator, address from, uint256 tokenId, bytes memory data)
    public returns (bytes4);
}
contract ERC721 is ERC165, IERC721 {
    using SafeMath for uint256;
    using Address for address;
    using Counters for Counters.Counter;

    bytes4 private constant _ERC721_RECEIVED = 0x150b7a02;

    // 토큰 ID에서 소유자로의 매핑
    mapping (uint256 => address) private _tokenOwner;

    // 토큰 ID에서 승인된 주소로의 매핑
    mapping (uint256 => address) private _tokenApprovals;

    // 소유자에서 소유한 토큰 개수로의 매핑
    mapping (address => Counters.Counter) private _ownedTokensCount;

    mapping (address => mapping (address => bool)) private _operatorApprovals;

    bytes4 private constant _INTERFACE_ID_ERC721 = 0x80ac58cd;

    constructor () public {
        _registerInterface(_INTERFACE_ID_ERC721);
    }

    function balanceOf(address owner) public view returns (uint256) {
        require(owner != address(0), "ERC721: balance query for the zero address");

        return _ownedTokensCount[owner].current();
    }

    function ownerOf(uint256 tokenId) public view returns (address) {
        address owner = _tokenOwner[tokenId];
        require(owner != address(0), "ERC721: owner query for nonexistent token");

        return owner;
    }

    function approve(address to, uint256 tokenId) public {
        address owner = ownerOf(tokenId);
        require(to != owner, "ERC721: approval to current owner");

        require(msg.sender == owner || isApprovedForAll(owner, msg.sender),
            "ERC721: approve caller is not owner nor approved for all"
        );

        _tokenApprovals[tokenId] = to;
        emit Approval(owner, to, tokenId);
    }

    function getApproved(uint256 tokenId) public view returns (address) {
        require(_exists(tokenId), "ERC721: approved query for nonexistent token");

        return _tokenApprovals[tokenId];
    }

    function setApprovalForAll(address to, bool approved) public {
        require(to != msg.sender, "ERC721: approve to caller");

        _operatorApprovals[msg.sender][to] = approved;
        emit ApprovalForAll(msg.sender, to, approved);
    }

    function isApprovedForAll(address owner, address operator) public view returns (bool) {
        return _operatorApprovals[owner][operator];
    }

    function transferFrom(address from, address to, uint256 tokenId) public {
        require(_isApprovedOrOwner(msg.sender, tokenId), "ERC721: transfer caller is not owner nor approved");

        _transferFrom(from, to, tokenId);
    }

    function safeTransferFrom(address from, address to, uint256 tokenId) public {
        safeTransferFrom(from, to, tokenId, "");
    }

    function safeTransferFrom(address from, address to, uint256 tokenId, bytes memory _data) public {
        transferFrom(from, to, tokenId);
        require(_checkOnERC721Received(from, to, tokenId, _data), "ERC721: transfer to non ERC721Receiver implementer");
    }

    function _exists(uint256 tokenId) internal view returns (bool) {
        address owner = _tokenOwner[tokenId];
        return owner != address(0);
    }

    function _isApprovedOrOwner(address spender, uint256 tokenId) internal view returns (bool) {
        require(_exists(tokenId), "ERC721: operator query for nonexistent token");
        address owner = ownerOf(tokenId);
        return (spender == owner || getApproved(tokenId) == spender || isApprovedForAll(owner, spender));
    }

    function _burn(address owner, uint256 tokenId) internal {
        require(ownerOf(tokenId) == owner, "ERC721: burn of token that is not own");

        _clearApproval(tokenId);

        _ownedTokensCount[owner].decrement();
        _tokenOwner[tokenId] = address(0);

        emit Transfer(owner, address(0), tokenId);
    }

    function _burn(uint256 tokenId) internal {
        _burn(ownerOf(tokenId), tokenId);
    }

    function _transferFrom(address from, address to, uint256 tokenId) internal {
        require(ownerOf(tokenId) == from, "ERC721: transfer of token that is not own");
        require(to != address(0), "ERC721: transfer to the zero address");

        _clearApproval(tokenId);

        _ownedTokensCount[from].decrement();
        _ownedTokensCount[to].increment();

        _tokenOwner[tokenId] = to;

        emit Transfer(from, to, tokenId);
    }

    function _checkOnERC721Received(address from, address to, uint256 tokenId, bytes memory _data)
        internal returns (bool)
    {
        if (!to.isContract()) {
            return true;
        }

        bytes4 retval = IERC721Receiver(to).onERC721Received(msg.sender, from, tokenId, _data);
        return (retval == _ERC721_RECEIVED);
    }

    function _clearApproval(uint256 tokenId) private {
        if (_tokenApprovals[tokenId] != address(0)) {
            _tokenApprovals[tokenId] = address(0);
        }
    }
}

NFT를 만들기 위해 ERC721을 구현하기 위한 인터페이스가 좀 길지만 전체적인 흐름은 토큰ID를 주고받는 코드입니다.

기본적으로 ERC721의 인터페이스는 특정 토큰이 생성되서 소유권을 부여하는 부분이 없습니다.

mapping (uint256 => address) private _tokenOwner;
mapping (address => Counters.Counter) private _ownedTokensCount;

특정 토큰의 소유 주소를 가지고 있는 정보와, 특정 주소가 몇개의 토큰을 소유하고 있는지에 대한 정보를 가지고 있는 변수입니다.

ERC721 컨트랙트에 다음코드를 추가하여 소유권을 부여하는 _mint를 추가합니다.

contract ERC721 is ERC165, IERC721 {
    // ... 중략 ...

    function _mint(address to, uint256 tokenId) internal {
        require(to != address(0), "ERC721: mint to the zero address");
        require(!_exists(tokenId), "ERC721: token already minted");

        _tokenOwner[tokenId] = to;         // 소유권 부여
        _ownedTokensCount[to].increment(); // 토큰 수량 +1

        emit Transfer(address(0), to, tokenId);
    }
}

여기까지 ERC721 준비는 끝났습니다. 이제 실질적으로 대체 불가능한 무엇인가를 만들어서 tokenId를 만들어 _mint를 호출하여 소유권을 부여해주면 됩니다.

· ERC165 알아가기

ERC165는 해당 스마트 컨트랙트에 특정 인터페이스가 구현되어 있는지 알려줍니다. 이를 인터페이스ID라고 합니다. 인터페이스ID는 methodId들을 XOR 연산한 값 입니다. 이를통해 특정 메서드를 구현했는지 알 수 있습니다.

methodId를 가져오는 방법은 2가지가 있습니다.

contract InterfaceId {

    mapping (address => uint) public balanceOf;
    
    function case2() public pure returns(bytes4, bytes4) {
        return (
            bytes4(keccak256('balanceOf(address)')), // 방법 1. methodId: 0x70a08231
            this.balanceOf.selector                  // 방법 2. methodId: 0x70a08231
        );
    }
}

앞의 코드처럼 methodId를 가져올 수 있습니다. 개인적으론 방법 2를 선호합니다. 방법 1은 오타가 발생하면 버그를 찾기가 너무 난해해지기 때문입니다. 하지만 방법1을 사용할 때가 있습니다. 만약 다음과 같은 함수가 있다고 해봅시다.

function test(uint a) public {}

function test(uint a, uint b) public {}

오버로딩 된 함수(함수명은 동일하지만 함수 인자로 구분)는 .selector를 이용하여 methodId를 가져올 수 없습니다.

ERC165의 모습은 다음과 같습니다.

interface IERC165 {
    function supportsInterface(bytes4 interfaceId) external view returns (bool);
}

contract ERC165 is IERC165 {
    bytes4 private constant _INTERFACE_ID_ERC165 = 0x01ffc9a7;

    mapping(bytes4 => bool) private _supportedInterfaces;

    constructor ()  {
        _registerInterface(_INTERFACE_ID_ERC165);
    }

    function supportsInterface(bytes4 interfaceId) external view returns (bool) {
        return _supportedInterfaces[interfaceId];
    }

    function _registerInterface(bytes4 interfaceId) internal {
        require(interfaceId != 0xffffffff, "ERC165: invalid interface id");
        _supportedInterfaces[interfaceId] = true;
    }
}

_supportedInterfaces는 methodId(interfaceId)를 키로 가지며, 구현 유무에 따라 true, false를 저장합니다.

    function supportsInterface(bytes4 interfaceId) external view returns (bool) {
        return _supportedInterfaces[interfaceId];
    }

_registerInterface는 methodId가 구현되었다고 저장합니다.

    function _registerInterface(bytes4 interfaceId) internal {
        require(interfaceId != 0xffffffff, "ERC165: invalid interface id");
        _supportedInterfaces[interfaceId] = true;
    }

ERC165를 상속받은 ERC721의 생성자에서 _registerInterface를 호출하여 각 인터페이스가 구현되었다는 사실을 알려줍니다. 실제로는 methodId: true 형태로 저장하고 있는 상태입니다.

// 0x80ac58cd;
bytes4 private constant _INTERFACE_ID_ERC721 = 
      bytes4(keccak256('balanceOf(address)')) ^
      bytes4(keccak256('ownerOf(uint256)')) ^
      bytes4(keccak256('approve(address,uint256)')) ^
      bytes4(keccak256('getApproved(uint256)')) ^
      bytes4(keccak256('setApprovalForAll(address,bool)')) ^
      bytes4(keccak256('isApprovedForAll(address,address)')) ^
      bytes4(keccak256('transferFrom(address,address,uint256)')) ^
      bytes4(keccak256('safeTransferFrom(address,address,uint256)')) ^
      bytes4(keccak256('safeTransferFrom(address,address,uint256,bytes)'));

또는 this.balanceOf.selector를 실행해도 각 메서드에 대한 methodId를 가져올 수 있습니다. this.함수.selector는 해당 함수의 methodId를 가져옵니다.

0x80ac58cd는 ERC721에서 제공하는 모든 함수를 구현했다는 것을 의미합니다.

만약 특정 인터페이스만 구현했다면 ERC721의 생성자(constructor)는 다음과 같이 구현할 수 있습니다.

constructor ()  {
    _registerInterface(bytes4(keccak256('balanceOf(address)')) ^ bytes4(keccak256('ownerOf(uint256)')));
}

인터페이스에서 2개만 구현되었음을 의미합니다. 저는 일반적으로 전체를 xor한것 + 개별적인 methodId도 등록하는 것을 선호합니다.

constructor ()  {
    _registerInterface(bytes4(keccak256('balanceOf(address)')));
    _registerInterface(bytes4(keccak256('ownerOf(uint256)')));
    _registerInterface(bytes4(keccak256('balanceOf(address)')) ^ bytes4(keccak256('ownerOf(uint256)')));
}

이렇게 해야 개별적인 methodId를 supportsInterface()를 호출하여 해당 메서드가 구현되었는지 알 수 있기 때문입니다. 해당 코드는 selector를 이용하여 다음과 같이 수정할 수 있습니다.

constructor ()  {
    _registerInterface(this.balanceOf.selector);
    _registerInterface(this.ownerOf.selector);
    _registerInterface(this.balanceOf.selector ^ this.ownerOf.selector);
}

이렇게 구현하는 이유는 dapp에서 특정 컨트랙트 주소를 받고 해당 컨트랙트 주소가 ERC의 표준을 잘 구현했는지 검사하는 목적으로 사용합니다. 가령 ERC20이라면 transfer 함수가 구현되어 있는지 알 수 있습니다.

물론 실질적인 메서드 구현은 하지 않았지만 해당 methodId를 _registerInterface을 통해 true로 했다면 supportsInterface를 호출하는 dapp은 구현이 되었다고 인식합니다.

interfaceID 간단하게 구하는 방법이 있습니다.

pragma solidity ^0.8.0;

interface IERC20 {
    function totalSupply() external view returns (uint256);
    function balanceOf(address account) external view returns (uint256);
    function transfer(address recipient, uint256 amount) external returns (bool);

    function allowance(address owner, address spender) external view returns (uint256);
    function approve(address spender, uint256 amount) external returns (bool);
    function transferFrom(address sender, address recipient, uint256 amount) external returns (bool);
    event Transfer(address indexed from, address indexed to, uint256 value);
    event Approval(address indexed owner, address indexed spender, uint256 value);
}

interface IERC721 {
    event Transfer(address indexed from, address indexed to, uint256 indexed tokenId);
    event Approval(address indexed owner, address indexed approved, uint256 indexed tokenId);
    event ApprovalForAll(address indexed owner, address indexed operator, bool approved);
    function balanceOf(address owner) external view returns (uint256 balance);
    function ownerOf(uint256 tokenId) external view returns (address owner);
    function safeTransferFrom(
        address from,
        address to,
        uint256 tokenId
    ) external;
    function transferFrom(
        address from,
        address to,
        uint256 tokenId
    ) external;
    function approve(address to, uint256 tokenId) external;
    function getApproved(uint256 tokenId) external view returns (address operator);
    function setApprovalForAll(address operator, bool _approved) external;
    function isApprovedForAll(address owner, address operator) external view returns (bool);
    function safeTransferFrom(
        address from,
        address to,
        uint256 tokenId,
        bytes calldata data
    ) external;
}


contract ttt  {

    function getInterfaceIDByERC20() public pure returns (bytes4) {
        return type(IERC20).interfaceId;
    }

    function getInterfaceIDByERC721() public pure returns (bytes4) {
        // bytes4 interfaceId = 
        //   this.balanceOf.selector ^
        //   this.ownerOf.selector ^
        //   this.approve.selector ^
        //   this.getApproved.selector ^
        //   this.setApprovalForAll.selector ^
        //   this.isApprovedForAll.selector ^
        //   this.transferFrom.selector ^
        //   this.safeTransferFrom.selector ^
        //   this.safeTransferFrom(address,address,uint256,bytes)')); // 0x80ac58cd
        return type(IERC721).interfaceId; // 0x80ac58cd
    }

}

type 함수에 인터페이스를 전달한후 interfaceId를 통해 interfaceId를 구할 수 있습니다.

· 대체 불가능 품목 구현

우리는 대체 불가능한 품목으로 캐릭터를 만들어 보겠습니다.

contract CharactorByERC721 is ERC721{
    struct Charactor {
        string  name;  // 캐릭터 이름
        uint256 level; // 캐릭터 레벨
    }

    Charactor[] public charactors; // default: [] 
    address public owner;          // 컨트랙트 소유자

    constructor () public {
        owner = msg.sender; 
    }

    modifier isOwner() {
      require(owner == msg.sender);
      _;
    }

    // 캐릭터 생성
    function mint(string memory name, address account) public isOwner {
        uint256 cardId = charactors.length; // 유일한 캐릭터 ID
        charactors.push(Charactor(name, 1));
        _mint(account, cardId); // ERC721 소유권 등록
    }
}

우리는 이름과 레벨 정보를 가진 캐릭터를 생성하여 대체 불가능 토큰화 시키는 코드를 완성했습니다. ERC721를 관리하는 관리자만 캐릭터를 생성할 수 있는 권한을 부여한 코드입니다.

modifier isOwner() {
  require(owner == msg.sender);
  _;
}

해당 코드가 컨트랙트 관리자인지 검사하는 코드입니다.

● 동작 확인

우리는 gnache-cli로 구성한 프라이빗 네트워크에 해당 컨트랙트를 배포한 훈 remix로 테스트를 진행합니다.

· 컨트랙트 배포

$ ganache-cli

Ganache CLI v6.12.1 (ganache-core: 2.13.1)

Available Accounts
==================
(0) 0x359b3a8108140E9ef9AA1eE99989BfCb700A7998 (100 ETH)
(1) 0x40758C66149641E955eD0bBbBfE54C728967FC6d (100 ETH)
(2) 0xE5cfe607eD4a37f8F579BDd949693C5a7B470287 (100 ETH)
(3) 0x19E51f231383dF875c01fD24D9C652fD3C84f4d6 (100 ETH)
(4) 0x5b70DD2330DC3e7ABBFEc7421962A58cA2de82c4 (100 ETH)
(5) 0x448543B6d743E276618Daa0dCF948c2507Fb0AC7 (100 ETH)
(6) 0x58EDe0F214690b7eFacd97461f749152255e9C87 (100 ETH)
(7) 0x0bC225A34f03062c677543ccA21397F7F560Bd02 (100 ETH)
(8) 0x1D3278089589ff6103B8aDb807e3332Bf2c6d5d4 (100 ETH)
(9) 0x9BF35fC633e7C3eceF88B3F36082D54AD1559E8B (100 ETH)

Private Keys
==================
(0) 0x64b0ba7f1479b2ae308c16572dffdaaa8f8ebba4a992c5d6892a8d24913c001e
(1) 0x9e3d8c8dc86c2a96ac9b5b58c5f653b5cab1853f0cbf321bc0d99b3cc646e428
(2) 0x408f62d250f1f29b2f196c78583da533f0b7e7c8a097237dbc4dd24a0aee7cbd
(3) 0x88e4e9cd80515c130a59b8e060c7f12fe7f5c94046303b03fe13b48c7df55918
(4) 0x1fbcca603a2643b16e2800e9f7cfefd429a5222bfa8dd9a742d0ef43738f9c11
(5) 0xd0caf806bdac8c56255edc1bd873a93a148383cd826ce701da7092fd6aca552b
(6) 0x6c2442112c56481bb21108eb47b730d5f4c50f8b9aa626a2bad90729a80e08a3
(7) 0x25298a064037bc7f817419058552aa11b4e3a3e1777f8d26b1f5cd444af75e67
(8) 0x6d919bb336e36f515cdbeb895497eb6368a7dbace09054fbb0aeac25c24d752f
(9) 0x170bbe066cd89e1faf6bfb39348a9af9fd927da5ee700ab20521fe0384d86f39

HD Wallet
==================
Mnemonic:      local hope lawn opinion leopard rate volcano pipe opera maximum exit cube
Base HD Path:  m/44'/60'/0'/0/{account_index}

Gas Price
==================
20000000000

Gas Limit
==================
6721975

Call Gas Limit
==================
9007199254740991

Listening on 127.0.0.1:8545

ganache-cli를 이용하여 매우 편안하게 프라이빗 전용 테스트 네트워크 생성이 가능합니다. 해당 네트워크에 우리가 작성한 컨트랙트 코드를 배포해보겠습니다.

Deploy 버튼을 누르면 배포 완료합니다.

우리가 만든 NFT의 기능을 확인할 수 있습니다.

리믹스는 파란색/주황색 버튼으로 조회/트랜잭션 기능을 구분합니다.

▶ 조회

owner 버튼(파란색)으로 해당 컨트랙트의 관리자를 조회할 수 있습니다. 해당 예제에선 컨트랙트 배포자를 관리자로 취급합니다.

balanceOf 버튼(파란색)은 전달한 주소의 보유중인 토큰수량 입니다. 여기선 캐릭터 수량이 됩니다.

charactors 버튼(파란색)은 토큰 아이디를 전달하여 캐릭터 정보를 조회합니다.

ownerOf 버튼(파란색)은 토큰 아이디를 전달하여 소유자 주소를 조회합니다.

getApproved 버튼(파란색)는 특정 토큰 아이디의 전송 권한을 가진 소유자가 아닌 주소를 조회합니다.(approve 버튼으로 설정된 주소입니다.)

▶ transaction

approve 버튼(주황색) 소유권 이외의 전송 권한 설정

mint 버튼(주황색) 생성된 토큰의 소유권 부여

safeTransferFrom, transferFrom 버튼(주황색) 토큰 소유권 이동

transferFrom 코드를 보면 _isApprovedOrOwner() 검사를 통해 호출자가 토큰 아이디의 소유자인지 또는 approve로 등록된 주소인지 검사한 후 진행 유/무를 판단합니다.

· 테스트

다음과 같은 정보로 mint를 호출합니다.

name: mung-charactor
account: 0x359b3a8108140E9ef9AA1eE99989BfCb700A7998

토큰 아이디는 mint를 호출한 순서로 0부터 1씩 증가 합니다.

balanceOf, charactors, ownerOf로 보유중인 토큰수, 정보 조회, 토큰 소유자 조회 결과입니다.

앞에서 만든 토큰을 다음 주소로 전송해보겠습니다.

0x7CA4C0d9d04E2C0F7376f47786C681b0CDbFA64E

from:    소유자 주소 => 0x359b3a8108140E9ef9AA1eE99989BfCb700A7998
to:      수신자 주소 => 0x7CA4C0d9d04E2C0F7376f47786C681b0CDbFA64E
tokenId: 토큰 아이디 => 0

ownerOf와 balanceOf로 해당 토큰 소유권 이동된 걸 확인할 수 있습니다.

샘플 코드는 깃허브에서 확인할 수 있습니다.

https://github.com/Exchange-M/NFT-ERC721

▶ 여기서 다루는 코드는 다음 코드를 기반으로 수정되어 진행되었습니다 (참고)

https://ko.docs.klaytn.com/smart-contract/sample-contracts/erc-721/1-erc721

1. ERC-721 스마트 컨트랙트 작성 - Klaytn Docs

MyERC721Card.sol은 하나의 인터페이스(IERC165), 세 라이브러리(Address, SafeMath 그리고 Counters) 그리고 네 컨트랙트(ERC165, IERC721, IERC721Receiver 그리고 MyERC721Card)로 구성됩니다.

ko.docs.klaytn.foundation

[ethereum] 이더리움 네트워크 모니터링 시스템 구축

멍개. — Sun, 28 Aug 2022 06:45:30 +0900

이번시간에는 지난번에 Ethash(POW), Clique(POA) 형태로 구축한 private network를 모니터링하는 시스템을 구축해보겠습니다.

2022.08.28 - [블록체인] - [ethereum] Geth를 이용하여 Clique(POA) 기반 private network 구축하기

[ethereum] Geth를 이용하여 Clique(POA) 기반 private network 구축하기

Geth를 이용하여 Ethash(POW) 기반 private network 구축하는 방법을 알아보겠습니다. Geth는 POW(Ethash), POA(Clique), POS(Caspre)를 선택적으로 운용가능합니다. 지난번에 정리한 POW(Ethash) 기반으로..

meongae.tistory.com

2022.08.27 - [블록체인] - [ethereum] Geth를 이용하여 Ethash 기반 private network 구축하기

[ethereum] Geth를 이용하여 Ethash 기반 private network 구축하기

meongae.tistory.com

네트워크는 POW, POA 어느것을 이용해도 진행가능합니다.

● 시스템 구성도

● eth-netstats 구동

eth-netstats는 실질적으로 사용자가 접속합니다.

$ git clone https://github.com/cubedro/eth-netstats.git
$ cd eth-netstats
$ npm i
$ grunt

$ export WS_SECRET=123
$ npm run start

WS_SECRET은 Agent 서버에서 함부로 접속하지 못하게 하기 위해 설정합니다.

localhost:3000으로 접속하면 데이터가 비어있는 모습의 사이트가 뜹니다.

이제 우리는 agent 서버를 실행하여 주기적으로 노드의 정보를 해당 페이지에 뿌려줘야 합니다.

● Agent 서버 구동

$ git clone https://github.com/cubedro/eth-net-intelligence-api.git
$ cd eth-net-intelligence-api
$ npm i

이제 우리는 2개의 파일을 만들어줘야 합니다. 2개의 노드와 연결을 하기위해 노드정보를 가지고있는 json파일을 만듭니다.

· process-node1.json

[
  {
    "name"              : "eth-node1",
    "script"            : "app.js",
    "log_date_format"   : "YYYY-MM-DD HH:mm Z",
    "merge_logs"        : false,
    "watch"             : false,
    "max_restarts"      : 10,
    "exec_interpreter"  : "node",
    "exec_mode"         : "fork_mode",
    "env":
    {
      "NODE_ENV"        : "production",
      "RPC_HOST"        : "localhost",
      "RPC_PORT"        : "8545",
      "LISTENING_PORT"  : "30303",
      "INSTANCE_NAME"   : "node1",
      "CONTACT_DETAILS" : "",
      "WS_SERVER"       : "http://127.0.0.1:3000/api",
      "WS_SECRET"       : "123",
      "VERBOSITY"       : 2
    }
  }
]

· process-node2.json

[
  {
    "name"              : "eth-node2",
    "script"            : "app.js",
    "log_date_format"   : "YYYY-MM-DD HH:mm Z",
    "merge_logs"        : false,
    "watch"             : false,
    "max_restarts"      : 10,
    "exec_interpreter"  : "node",
    "exec_mode"         : "fork_mode",
    "env":
    {
      "NODE_ENV"        : "production",
      "RPC_HOST"        : "localhost",
      "RPC_PORT"        : "8546",
      "LISTENING_PORT"  : "30304",
      "INSTANCE_NAME"   : "node2",
      "CONTACT_DETAILS" : "",
      "WS_SERVER"       : "http://127.0.0.1:3000/api",
      "WS_SECRET"       : "123",
      "VERBOSITY"       : 2
    }
  }
]

WS_SERVER와 WS_SECRET은 앞에서 실행한 eth-netstats서버 입니다. WS_SECRET은 앞에서 eth-netstats를 실행하기 전에 설정한 값을 넣어줍니다. WS_SERVER는 엔드포인트가 /api 입니다.

· Agent 실행

이제 Agent 서버를 실행해줍니다.

$ pm2 start process-node1.json

$ pm2 start process-node2.json

$ pm2 list

┌────┬─────────────────────────┬─────────┬─────────┬──────────┬────────┬──────┬──────────┬──────────┬──────────┬──────────┬──────────┐
│ id │ name                    │ version │ mode    │ pid      │ uptime │ ↺    │ status   │ cpu      │ mem      │ user     │ watching │
├────┼─────────────────────────┼─────────┼─────────┼──────────┼────────┼──────┼──────────┼──────────┼──────────┼──────────┼──────────┤
│ 0  │ eth-node1               │ 0.1.1   │ fork    │ 54204    │ 97s    │ 0    │ online   │ 0.6%     │ 44.7mb   │ bag… │ disabled │
│ 1  │ eth-node2               │ 0.1.1   │ fork    │ 54408    │ 49s    │ 0    │ online   │ 0.6%     │ 40.1mb   │ bag… │ disabled │
└────┴─────────────────────────┴─────────┴─────────┴──────────┴────────┴──────┴──────────┴──────────┴──────────┴──────────┴──────────┘

pm2는 백그라운드로 서버를 동작시킵니다. 해당 서버는 실행시 전달한 json파일에 명시된 노드에서 주기적으로 정보를 조회한 후 WS_SERVER로 전달하는 역할을 합니다.

$ pm2 log

pm2 log는 백그라운드로 동작하고 있는 서버의 로그를 출력하는 명령어입니다.

앞에서 실행한 eth-netstats의 로그를 확인해보면 다음과 같습니다.

2022년 08월 27일을 기준으로 네이버 블로그에서 이관작업 시작합니다.

멍개. — Sun, 28 Aug 2022 06:41:24 +0900

기술 블로그로 기존에 운영하던 네이버 블로그를 해당 티스토리로 이관합니다.

https://blog.naver.com/pjt3591oo

[ethereum] Geth를 이용하여 Clique(POA) 기반 private network 구축하기

멍개. — Sun, 28 Aug 2022 06:40:02 +0900

Geth를 이용하여 Ethash(POW) 기반 private network 구축하는 방법을 알아보겠습니다.

Geth는 POW(Ethash), POA(Clique), POS(Caspre)를 선택적으로 운용가능합니다.

지난번에 정리한 POW(Ethash) 기반으로 작성한 글을 참고하면 어렵지 않게 진행할 수 있습니다.

2022.08.27 - [블록체인] - [ethereum] Geth를 이용하여 Ethash 기반 private network 구축하기

[ethereum] Geth를 이용하여 Ethash 기반 private network 구축하기

meongae.tistory.com

여기선 개념적인 내용보다 방법론적인 내용을 주로 다룹니다.

※ 진행순서

1. allocation, mine base 지갑주소 생성
2. 첫 번째 노드 구동
3. 두 번째 노드 구동
4. 네트워크 연결
5. block, transaction broadcast 동작 테스트

1. 지갑주소 생성

지갑주소를 생성하는 이유는 초기 이더를 할당하고 마이닝할 때 리워드(보상)을 가져갈 주소를 미리 설정해주기 위함입니다.

참고로 POA는 POW와 다르게 컴퓨팅 파워가 아닌 라운드 로빈을 사용합니다.

$ geth --datadir [경로] account new

geth를 이용할 땐 반드시 어느경로에 저장할지 지정해줘야 합니다. 그렇지 않을경우 지정된 기본경로를 사용합니다.

· 노드1에서 지갑생성

$ geth --datadir $PWD account new

# node1 디렉터리에서 수행

$ geth --datadir $PWD account new   

INFO [02-19|10:04:28.072] Maximum peer count                       ETH=50 LES=0 total=50
Your new account is locked with a password. Please give a password. Do not forget this password.
Password: 
Repeat password: 

Your new key was generated

Public address of the key:   0x5143155F92cb9d6D3a46c7d1F4413B44C8Fb3f2d
Path of the secret key file: /Users/bagjeongtae/Desktop/POA_node1/keystore/UTC--2021-02-19T01-04-29.450280000Z--5143155f92cb9d6d3a46c7d1f4413b44c8fb3f2d

- You can share your public address with anyone. Others need it to interact with you.
- You must NEVER share the secret key with anyone! The key controls access to your funds!
- You must BACKUP your key file! Without the key, it's impossible to access account funds!
- You must REMEMBER your password! Without the password, it's impossible to decrypt the key!

$ geth --datadir $PWD account new   

INFO [02-19|10:04:31.932] Maximum peer count                       ETH=50 LES=0 total=50
Your new account is locked with a password. Please give a password. Do not forget this password.
Password: 
Repeat password: 

Your new key was generated

Public address of the key:   0x852159cDFdB2Ac32807d57782aB0217B3024fAfb
Path of the secret key file: /Users/bagjeongtae/Desktop/POA_node1/keystore/UTC--2021-02-19T01-04-33.140369000Z--852159cdfdb2ac32807d57782ab0217b3024fafb

- You can share your public address with anyone. Others need it to interact with you.
- You must NEVER share the secret key with anyone! The key controls access to your funds!
- You must BACKUP your key file! Without the key, it's impossible to access account funds!
- You must REMEMBER your password! Without the password, it's impossible to decrypt the key!

2개의 계정을 생성해주었습니다.

· 노드2에서 지갑생성

여기선 3개의 주소를 라운드 로빈을 하기위해 계정 하나를 더 만들어 줄건데 한개의 계정은 두 번째 노드 경로에 추가해주도록 하겠습니다. 참고로 계정은 어디에있던지 상관없습니다.

# node2 디렉터리에서 수행
$ geth --datadir $PWD account new   

INFO [02-19|10:08:08.105] Maximum peer count                       ETH=50 LES=0 total=50
Your new account is locked with a password. Please give a password. Do not forget this password.
Password: 
Repeat password: 

Your new key was generated

Public address of the key:   0x444BBC8CB8aa094A76F77862d661146E0C9d6339
Path of the secret key file: /Users/bagjeongtae/Desktop/POA_node2/keystore/UTC--2021-02-19T01-08-09.485488000Z--444bbc8cb8aa094a76f77862d661146e0c9d6339

- You can share your public address with anyone. Others need it to interact with you.
- You must NEVER share the secret key with anyone! The key controls access to your funds!
- You must BACKUP your key file! Without the key, it's impossible to access account funds!
- You must REMEMBER your password! Without the password, it's impossible to decrypt the key!

노드1: 0x5143155F92cb9d6D3a46c7d1F4413B44C8Fb3f2d
노드1: 0x852159cDFdB2Ac32807d57782aB0217B3024fAfb
노드2: 0x444BBC8CB8aa094A76F77862d661146E0C9d6339

2. 첫 번째 노드 구동

노드를 구동하기 전에 제네시스 블록을 생성하기 위해 제네시스 블록을 만들기 위한 파일(genesis.json)을 만들어줍니다.

파일 템플릿은 POW(Ethash)와 비슷합니다.

· genesis.json 생성

{
  "config": {
    "chainId": 12345,
    "homesteadBlock": 0,
    "eip150Block": 0,
    "eip155Block": 0,
    "eip158Block": 0,
    "byzantiumBlock": 0,
    "clique": {
      "period": 5,
      "epoch": 30000
    }
  },
  "nonce": "0x0",
  "timestamp": "0x5a722c92",
  "extraData": "0x00000000000000000000000000000000000000000000000000000000000000005143155F92cb9d6D3a46c7d1F4413B44C8Fb3f2d444BBC8CB8aa094A76F77862d661146E0C9d63390000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
  "gasLimit": "0x59A5380",
  "difficulty": "0x1",
  "mixHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
  "coinbase": "0x0000000000000000000000000000000000000000",
  "alloc": { 
    "5143155F92cb9d6D3a46c7d1F4413B44C8Fb3f2d" : {
      "balance": "1500000000000000000000"
    }
   },
  "number": "0x0",
  "gasUsed": "0x0",
  "parentHash": "0x0000000000000000000000000000000000000000000000000000000000000000"
}

여기서 라운드 로빈 시킬 계정을 extraData에 포함시키면 됩니다.

포함시키는 방법은 앞에서 생성한 지갑의 prefix로 붙어있는 0x를 제외하고 이어서 붙여주면 됩니다.

5143155F92cb9d6D3a46c7d1F4413B44C8Fb3f2d852159cDFdB2Ac32807d57782aB0217B3024fAfb444BBC8CB8aa094A76F77862d661146E0C9d6339

[라운드 로빈 계정] 부분에 앞의 문자열로 대체합니다.

{
  "config": {
    "chainId": 12345,
    "homesteadBlock": 0,
    "eip150Block": 0,
    "eip155Block": 0,
    "eip158Block": 0,
    "byzantiumBlock": 0,
    "clique": {
      "period": 5,
      "epoch": 30000
    }
  },
  "nonce": "0x0",
  "timestamp": "0x5a722c92",
  "extraData": "0x00000000000000000000000000000000000000000000000000000000000000005143155F92cb9d6D3a46c7d1F4413B44C8Fb3f2d852159cDFdB2Ac32807d57782aB0217B3024fAfb444BBC8CB8aa094A76F77862d661146E0C9d63390000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
  "gasLimit": "0x59A5380",
  "difficulty": "0x1",
  "mixHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
  "coinbase": "0x0000000000000000000000000000000000000000",
  "alloc": {  },
  "number": "0x0",
  "gasUsed": "0x0",
  "parentHash": "0x0000000000000000000000000000000000000000000000000000000000000000"
}

clique.period는 트랜잭션이 발생하지 않을때 블록생성 주기입니다.

· genesis.json 초기화

$ geth --datadir [경로] init [제네시스파일 경로]

$  geth --datadir $PWD init genesis.json

INFO [02-19|10:24:39.001] Maximum peer count                       ETH=50 LES=0 total=50
INFO [02-19|10:24:39.021] Set global gas cap                       cap=25000000
INFO [02-19|10:24:39.021] Allocated cache and file handles         database=/Users/bagjeongtae/Desktop/POA_node1/geth/chaindata cache=16.00MiB handles=16
INFO [02-19|10:24:39.099] Writing custom genesis block 
INFO [02-19|10:24:39.100] Persisted trie from memory database      nodes=0 size=0.00B time="20.641µs" gcnodes=0 gcsize=0.00B gctime=0s livenodes=1 livesize=0.00B
INFO [02-19|10:24:39.101] Successfully wrote genesis state         database=chaindata hash="8a08d7…b5ee63"
INFO [02-19|10:24:39.101] Allocated cache and file handles         database=/Users/bagjeongtae/Desktop/POA_node1/geth/lightchaindata cache=16.00MiB handles=16
INFO [02-19|10:24:39.194] Writing custom genesis block 
INFO [02-19|10:24:39.194] Persisted trie from memory database      nodes=0 size=0.00B time="4.418µs"  gcnodes=0 gcsize=0.00B gctime=0s livenodes=1 livesize=0.00B
INFO [02-19|10:24:39.195] Successfully wrote genesis state         database=lightchaindata hash="8a08d7…b5ee63"

여기까지 작업을 정상적으로 마쳤다면 다음과 같이 결과를 얻습니다.

· 노드실행

$ geth \
--datadir $PWD \
--syncmode 'full' \
--allow-insecure-unlock \
--networkid 12345 \
--maxpeers 3 \
--http \
--http.port 8545 \
--http.addr "0.0.0.0" \
--http.corsdomain "*" \
--http.api "admin,eth,debug,miner,net,txpool,personal,web3" \
--ws \
--ws.port 3334 \
--ws.api eth,net,web3 \
--port 30303 \
--gasprice 21000 \
--nodiscover \
--unlock '0x5143155f92cb9d6d3a46c7d1f4413b44c8fb3f2d' \
--password password.txt \
console

unlock은 해당 노드에서 라운드 로빈에 등록된 extraData에서 하나 또는 컴마로 구분하여 지갑을 나열합니다.

--password 옵션으로 전달하는 파일은 --unlock에 등록한 계정들의 키스토어파일 비밀번호를 작성합니다. 만약 --unlock에 컴마로 여러 지갑을 나열했다면 엔터로 구분하여 각각의 비밀번호를 작성합니다.

추후 노드 연결을 위해 enode를 잘 기억해둡시다.

enode://6e7cdfbb3ca0194187b4ce9acbd3db77f603cf197881ca3ae8598e94ce5c679f0fda5945995b87f666d090467bf3706a584856ce5e86453fff27be34669eb3d6@127.0.0.1:30303?discport=0

3. 두 번째 노드 구동

· genesis.json 파일 생성

첫 번째 노드 구동 시 사용하던 genesis.json을 가져옵니다.

· 제네시스 블록 초기화

$  geth --datadir $PWD init genesis.json

INFO [02-19|10:29:12.788] Maximum peer count                       ETH=50 LES=0 total=50
INFO [02-19|10:29:12.805] Set global gas cap                       cap=25000000
INFO [02-19|10:29:12.805] Allocated cache and file handles         database=/Users/bagjeongtae/Desktop/POA_node2/geth/chaindata cache=16.00MiB handles=16
INFO [02-19|10:29:12.888] Writing custom genesis block 
INFO [02-19|10:29:12.889] Persisted trie from memory database      nodes=0 size=0.00B time="19.063µs" gcnodes=0 gcsize=0.00B gctime=0s livenodes=1 livesize=0.00B
INFO [02-19|10:29:12.889] Successfully wrote genesis state         database=chaindata hash="8a08d7…b5ee63"
INFO [02-19|10:29:12.889] Allocated cache and file handles         database=/Users/bagjeongtae/Desktop/POA_node2/geth/lightchaindata cache=16.00MiB handles=16
INFO [02-19|10:29:12.963] Writing custom genesis block 
INFO [02-19|10:29:12.963] Persisted trie from memory database      nodes=0 size=0.00B time="3.692µs"  gcnodes=0 gcsize=0.00B gctime=0s livenodes=1 livesize=0.00B
INFO [02-19|10:29:12.964] Successfully wrote genesis state         database=lightchaindata hash="8a08d7…b5ee63"

첫 번째 노드에서 제네시스 블록을 생성할 때 사용한 명령어와 동일합니다. 다만 해당 명령어를 수행하는 위치가 다릅니다.

제네시스 블록으로 생성된 데이터의 위치가 다른것을 확인할 수 있습니다.

· 노드실행

$ geth \
--datadir $PWD \
--syncmode 'full' \
--allow-insecure-unlock \
--networkid 12345 \
--maxpeers 3 \
--http \
--http.port 8546 \
--http.addr "0.0.0.0" \
--http.corsdomain "*" \
--http.api "admin,eth,debug,miner,net,txpool,personal,web3" \
--ws \
--ws.port 3335 \
--ws.api eth,net,web3 \
--port 30304 \
--gasprice 21000 \
--nodiscover \
--unlock '0x444bbc8cb8aa094a76f77862d661146e0c9d6339' \
--password password.txt \
console

두 번째 노드를 실행할 때 중요한 건 이미 실행중인 첫 번째 노드에서 사용중인 포트를 곂치지 않게 해야합니다. 다음 3개를 수정합니다.

--http.port
--ws.port
--port

첫 번째 노드와 마찬가지로 unlock은 해당 노드에서 라운드 로빈에 등록된 extraData에서 하나 또는 컴마로 구분하여 지갑을 나열합니다.

enode://8938590dd2a17a48d23025d6e7cbb13549ca9f75374651665e38adf45cbf9c3ad4478a804bcfdf59c12f34f005d2e6842e43ceadbb680e52069dd9de2879d060@127.0.0.1:30304?discport=0

4. 노드연결

노드1: enode://6e7cdfbb3ca0194187b4ce9acbd3db77f603cf197881ca3ae8598e94ce5c679f0fda5945995b87f666d090467bf3706a584856ce5e86453fff27be34669eb3d6@127.0.0.1:30303?discport=0
노드2: enode://8938590dd2a17a48d23025d6e7cbb13549ca9f75374651665e38adf45cbf9c3ad4478a804bcfdf59c12f34f005d2e6842e43ceadbb680e52069dd9de2879d060@127.0.0.1:30304?discport=0

노드1에서 admin.addPeer(노드2 enode) 또는 노드2에서 admin.addPeer(노드1 enode)를 호출합니다. 저는 전자의 방법을 택하겠습니다.

> admin.addPeer("enode://8938590dd2a17a48d23025d6e7cbb13549ca9f75374651665e38adf45cbf9c3ad4478a804bcfdf59c12f34f005d2e6842e43ceadbb680e52069dd9de2879d060@127.0.0.1:30304?discport=0")
> true

노드 1, 2에서 admin.peers로 각 노드에서 연결하고 있는 노드를 조회할 수 있습니다.

> admin.peers
[{
    caps: ["eth/63", "eth/64", "eth/65"],
    enode: "enode://8938590dd2a17a48d23025d6e7cbb13549ca9f75374651665e38adf45cbf9c3ad4478a804bcfdf59c12f34f005d2e6842e43ceadbb680e52069dd9de2879d060@127.0.0.1:30304?discport=0",
    id: "8d125f8fe3f7b157ec183d250253b14eff3c4577beee63c6e147a0286289bfe1",
    name: "Geth/v1.9.25-stable-e7872729/darwin-amd64/go1.15.6",
    network: {
      inbound: false,
      localAddress: "127.0.0.1:51676",
      remoteAddress: "127.0.0.1:30304",
      static: true,
      trusted: false
    },
    protocols: {
      eth: {
        difficulty: 1,
        head: "0x8a08d70a448f3708d9dbd6d405af8d566e9e93a99ae3324df0603ce9c8b5ee63",
        version: 65
      }
    }
}]

> net
{
  listening: true,
  peerCount: 1,
  version: "10",
  getListening: function(callback),
  getPeerCount: function(callback),
  getVersion: function(callback)
}

> admin.peers
[{
    caps: ["eth/63", "eth/64", "eth/65"],
    enode: "enode://6e7cdfbb3ca0194187b4ce9acbd3db77f603cf197881ca3ae8598e94ce5c679f0fda5945995b87f666d090467bf3706a584856ce5e86453fff27be34669eb3d6@127.0.0.1:51676",
    id: "c1eb472449d4ca9f46f9ccaac1beae1d65d8faf022514996302570651ebaa054",
    name: "Geth/v1.9.25-stable-e7872729/darwin-amd64/go1.15.6",
    network: {
      inbound: true,
      localAddress: "127.0.0.1:30304",
      remoteAddress: "127.0.0.1:51676",
      static: false,
      trusted: false
    },
    protocols: {
      eth: {
        difficulty: 1,
        head: "0x8a08d70a448f3708d9dbd6d405af8d566e9e93a99ae3324df0603ce9c8b5ee63",
        version: 65
      }
    }
}]

> net
{
  listening: true,
  peerCount: 1,
  version: "10",
  getListening: function(callback),
  getPeerCount: function(callback),
  getVersion: function(callback)
}
>

5. 동작 테스트

POA 기반에선 miner.start()를 실행하면 컴퓨팅 리소스가 아니라 트랜잭션 발생시 extraData에 등록한 지갑 순서대로 블록생성을 합니다. 이 방법을 라운드로빈이라고 부릅니다.

· 트랜잭션 발생

> eth.sendTransaction({from: eth.accounts[0], to: eth.accounts[1], value: 12321})

INFO [02-19|11:40:47.383] Setting new local account                address=0x5143155F92cb9d6D3a46c7d1F4413B44C8Fb3f2d
INFO [02-19|11:40:47.383] Submitted transaction                    fullhash=0xf4c848358401bf56f0f28fc0831558bd520f8c09d1d80c2172bed25e32cb7061 recipient=0x852159cDFdB2Ac32807d57782aB0217B3024fAfb
"0xf4c848358401bf56f0f28fc0831558bd520f8c09d1d80c2172bed25e32cb7061"

· POA 구동시작

각 노드에서 miner.start()를 해야 각 노드에서 POA를 위해 등록한 주소를 블록생산에 참가 시킬 수 있습니다. 첫 번째, 두 번째 노드에서 POA 구동을 해줍니다.

한가지 중요한 점은 extraData에 포함한 계정 갯수(POA에 참가한 지갑)가 N개일 때 (N/2 +1)개 만큼 구동되야 정상적으로 POA를 구동합니다.

역기선 2개를 등록했기 때문에 2/2 + 1 = 2개가 구동되어야 동작하게 됩니다.

INFO [02-19|12:01:25.005]   mined potential block                  number=193 hash="229f58…6d0ce6"
INFO [02-19|12:01:25.005] Commit new mining work                   number=194 sealhash="d9511f…87a806" uncles=0 txs=0 gas=0     fees=0         elapsed="269.905µs"

블록을 생성할 때 로그입니다.

INFO [02-19|12:01:50.008] Imported new chain segment               blocks=1 txs=0 mgas=0.000 elapsed="184.608µs" mgasps=0.000   number=198 hash="84dc69…708e32" dirty=6.59KiB

블록을 전달받을 때 로그입니다.

[그림 1.1] 실행된 노드

마이닝을 하게 되면 [그림 1.1]에서 가장위의 노드는 unlock과 password를 전달하지 않는 노드입니다. 즉 블록생성을 하지 않고 아래 두 노드가 unlock과 password를 전달하여 블록 생성을 하는 노드입니다. 첫 번째 노드에서 트랜잭션을 발생하면 2, 3번째 노드가 트랜잭션을 전달받아 순차적으로 블록을 생성합니다.

일반적으로 private 네트워크를 운용할 땐 POW보단 POA를 이용하는 방법을 권장합니다. 그 이유는 POW에 비해 POA는 컴퓨터 리소스를 거의 사용하지 않기 때문에 훨씬 안정적으로 운용할 수 있습니다.

이번시간엔 Geth를 이용하여 POA 기반의 private network를 구축하는 방법을 알아보았습니다.

다음 시간엔 지난번에 구축한 POW 환경과 여기서 만든 POA 환경의 private 네트워크망에서 노드 모니터링을 연동해보도록 하겠습니다.

https://ethstats.net/

[ethereum] Geth를 이용하여 Ethash 기반 private network 구축하기

멍개. — Sat, 27 Aug 2022 17:07:16 +0900

Geth를 이용하여 Ethash(POW) 기반 private network 구축하는 방법을 알아보겠습니다.

Geth는 POW(Ethash), POA(Clique), POS(Caspre)를 선택적으로 운용가능합니다.

여기선 개념적인 내용보다 방법론적인 내용을 주로 다룹니다.

● GETH 다운로드

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

해당 링크에 접속하면 OS별로 GETH 실행프로그램을 설치할 수 있습니다.

private 네트워크 구축을 위에 필요한 준비는 다음과 같습니다.

1. allocation, mine base 지갑주소 생성
2. 첫 번째 노드 생성
3. 두 번째 노드 생성
4. 네트워크 연결
5. block, transaction broadcast 동작 테스트

1. 지갑주소 생성

가장먼저, 지갑주소를 생성해주는 이유는 초기에 이더를 할당하고 마이닝할 때 리워드(보상)을 가져갈 주소를 미리 설정해주기 위함입니다.

$ geth --datadir [경로] account new

항상 geth 또는 parity를 이용할 땐 어느 디렉터리를 기준으로 명령어를 수행할 지 반드시 전달해야 합니다.

$ geth --datadir $PWD account new            

INFO [02-16|21:22:15.157] Maximum peer count                       ETH=50 LES=0 total=50
Your new account is locked with a password. Please give a password. Do not forget this password.
Password: 패스워드 입력
Repeat password: 패스워드 입력

Your new key was generated

Public address of the key:   0x04dEb80cc89c42D8148312CFC16E1579E4aF7291
Path of the secret key file: /Users/bagjeongtae/Desktop/node1/keystore/UTC--2021-02-16T12-22-16.603245000Z--04deb80cc89c42d8148312cfc16e1579e4af7291

- You can share your public address with anyone. Others need it to interact with you.
- You must NEVER share the secret key with anyone! The key controls access to your funds!
- You must BACKUP your key file! Without the key, it's impossible to access account funds!
- You must REMEMBER your password! Without the password, it's impossible to decrypt the key!

$PWD는 현재 터미널이 가리키고 있는 위치를 의미하며 비밀번호를 입력하라고 뜹니다. 해당 비밀번호는 private key를 keystore로 변환하기 위해 사용됩니다.

$PWD는 node1 디렉터리를 가리키고 있으며 디렉터리 아래에 private key와 비밀번호를 결합하여 만들어진 keystore 파일을 보관합니다.

$ geth --datadir $PWD account new

INFO [02-16|21:24:27.530] Maximum peer count                       ETH=50 LES=0 total=50
Your new account is locked with a password. Please give a password. Do not forget this password.
Password: 
Repeat password: 

Your new key was generated

Public address of the key:   0x56F11a78100226558194655c0eAbf64F9627181D
Path of the secret key file: /Users/bagjeongtae/Desktop/node1/keystore/UTC--2021-02-16T12-24-28.547579000Z--56f11a78100226558194655c0eabf64f9627181d

- You can share your public address with anyone. Others need it to interact with you.
- You must NEVER share the secret key with anyone! The key controls access to your funds!
- You must BACKUP your key file! Without the key, it's impossible to access account funds!
- You must REMEMBER your password! Without the password, it's impossible to decrypt the key!

이렇게해서 만들어진 주소는 다음과 같습니다.

0x04dEb80cc89c42D8148312CFC16E1579E4aF7291
0x56F11a78100226558194655c0eAbf64F9627181D

혹시 keystore 파일에 대해서 궁금하신 분은 다음 링크를 통해 확인해보세요.

2022.08.27 - [블록체인] - [ethereum] keystore 파일에 대해서

2. 첫 번째 노드 생성

첫 번째 과정은 스킵하고 넘어갈 수 있습니다.

· genesis 블록 정의

genesis 블록을 만들기 위해 정보를 정의해줘야 합니다. 기본폼은 다음과 같습니다.

또한 가독성을 위해 genesis.json이라고 파일을 만들어 줍니다.

{
  "config": {
    "chainId": 10,
    "homesteadBlock": 0,
    "eip150Block": 0,
    "eip155Block": 0,
    "eip158Block": 0,
    "byzantiumBlock": 0,
    "constantinopleBlock": 0,
    "petersburgBlock": 0,
    "istanbulBlock": 0
  },
  "coinbase"   : "0x0",
  "nonce": "0x0000000000000033",
  "timestamp": "0x0x177AACF3671",
  "parentHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
  "gasLimit": "0x8000000",
  "difficulty": "0x100",
  "mixhash": "0x0000000000000000000000000000000000000000000000000000000000000000",
  "alloc": {}
}

· config

해당 부분은 geth의 버전등을 표현합니다. 해당 정보가 잘못되면 추후에 노드간 연결 및 broadcast가 원할히 진행되지 않거나 transaction이 정상적으로 발생하지 않을 수 있습니다. 항상 사용하고 있는 geth 및 parity 같은 클라이언트 프로그램의 버전에 맞춰서 작성해야 합니다.

여기서 사용한 geth 버전은 다음과 같습니다. 
1.9.25-stable-e7872729

· coinbase

마이닝 했을 때 보상받을 지갑주소 .해당값은 추후에 바꿀 수 있습니다.

하지만 해당값을 입력할 땐 prefix로 0x를 반드시 붙여줘야 합니다.

· nonce

POW 알고리즘에 사용하는 파라미터 초기설정 입니다. 알고리즘이 동작하면서 해당값을 바뀌게 됩니다. 크게 신경쓰지 않아도 됩니다.

· timestamp

첫 번째 블록이 만들어진 시간입니다. 당연히 timestamp의 16진수로 변환된 값을 넣어줍니다.

· parantHash

이전블록 해쉬값인데 첫 번째 블록의 이전 블록은 없기 때문에 0x0으로 작성합니다.

· gasLimit

말 그대로 해당 노드에서 최대로 처리할 수 있는 gas 입니다. gas는 연료의 개념으로 이더 전송의 기본 가스 소모량은 21000이며, 스마트컨트랙트는 실행된 코드에 따라 달라지게 됩니다.

· difficulty

nonce와 마찬가지로 POW 알고리즘 동작에 사용되는 파라미터이며, 알고리즘에 의해 값은 변경됩니다. 블록생성 주기가 10~20초 사이가 되도록 맞춰집니다.

· alloc

초기에 state를 정의하는 부분입니다. 즉, 이더리움을 특정 지갑에 할당하거나 스마트 컨트랙트를 배포하는 용도입니다.

alloc은 coinbase와 다르게 prefix로 포함된 0x를 지워야 합니다.

우리가 앞에서 생성한 주소를 기반으로 만들어진 genesis 블록(genesis.json) 정보는 다음과 같습니다.

{
  "config": {
    "chainId": 10,
    "homesteadBlock": 0,
    "eip150Block": 0,
    "eip155Block": 0,
    "eip158Block": 0,
    "byzantiumBlock": 0,
    "constantinopleBlock": 0,
    "petersburgBlock": 0,
    "istanbulBlock": 0
  },
  "coinbase"   : "0x04dEb80cc89c42D8148312CFC16E1579E4aF7291",
  "nonce": "0x0000000000000033",
  "timestamp": "0x177AACF3671",
  "parentHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
  "gasLimit": "0x8000000",
  "difficulty": "0x100",
  "mixhash": "0x0000000000000000000000000000000000000000000000000000000000000000",
  "alloc": {
    "04dEb80cc89c42D8148312CFC16E1579E4aF7291": { 
        "balance": "500000000000000000000000" 
    },
    "56F11a78100226558194655c0eAbf64F9627181D": { 
        "balance": "800000000000000000000000" 
     }
  }
}

· 제네시스 블록 초기화

제네시스 블록을 정의한 파일을 기반으로 제네시스 블록을 초기화 하기 위해 init 명령어를 사용합니다.

$ geth --datadir [경로] init [제네시스파일 경로]

당연히 datadir을 전달해야 해당 경로에 초기블록 정보를 저장합니다.

$ geth --datadir $PWD init genesis.json

INFO [02-16|21:41:12.661] Maximum peer count                       ETH=50 LES=0 total=50
INFO [02-16|21:41:12.692] Set global gas cap                       cap=25000000
INFO [02-16|21:41:12.692] Allocated cache and file handles         database=/Users/bagjeongtae/Desktop/node1/geth/chaindata cache=16.00MiB handles=16
INFO [02-16|21:41:12.765] Writing custom genesis block 
INFO [02-16|21:41:12.766] Persisted trie from memory database      nodes=3 size=411.00B time="205.117µs" gcnodes=0 gcsize=0.00B gctime=0s livenodes=1 livesize=0.00B
INFO [02-16|21:41:12.767] Successfully wrote genesis state         database=chaindata hash="2bd1fd…2ba123"
INFO [02-16|21:41:12.767] Allocated cache and file handles         database=/Users/bagjeongtae/Desktop/node1/geth/lightchaindata cache=16.00MiB handles=16
INFO [02-16|21:41:12.840] Writing custom genesis block 
INFO [02-16|21:41:12.841] Persisted trie from memory database      nodes=3 size=411.00B time="142.937µs" gcnodes=0 gcsize=0.00B gctime=0s livenodes=1 livesize=0.00B
INFO [02-16|21:41:12.841] Successfully wrote genesis state         database=lightchaindata hash="2bd1fd…2ba123"

여기까지 작업을 정상적으로 마쳤다면 다음과 같이 결과를 얻습니다.

자 이제 첫번째 노드를 실행시킬 준비를 마쳤습니다.

· 노드실행

$ geth \
--datadir $PWD \
--syncmode 'full' \
--allow-insecure-unlock \
--networkid 10 \
--maxpeers 3 \
--http \
--http.port 8545 \
--http.addr "0.0.0.0" \
--http.corsdomain "*" \
--http.api "admin,eth,debug,miner,net,txpool,personal,web3" \
--ws \
--ws.port 3334 \
--ws.api eth,net,web3 \
--port 30303 \
--gasprice 21000 \
--nodiscover \
console

실행 옵션이 상당히 많은데 옵션 설명은 일단 스킵하고 넘어가겠습니다. 앞의 명령어를 수행하면 다음과 같이 로그가 출력되면서 대기상태가 됩니다.

INFO [02-16|21:46:39.824] Maximum peer count                       ETH=3 LES=0 total=3
WARN [02-16|21:46:39.857] The flag --gasprice is deprecated and will be removed in the future, please use --miner.gasprice 
INFO [02-16|21:46:39.857] Set global gas cap                       cap=25000000
INFO [02-16|21:46:39.857] Allocated trie memory caches             clean=256.00MiB dirty=256.00MiB
INFO [02-16|21:46:39.857] Allocated cache and file handles         database=/Users/bagjeongtae/Desktop/node1/geth/chaindata cache=512.00MiB handles=5120
INFO [02-16|21:46:40.144] Opened ancient database                  database=/Users/bagjeongtae/Desktop/node1/geth/chaindata/ancient
INFO [02-16|21:46:40.145] Initialised chain configuration          config="{ChainID: 10 Homestead: 0 DAO: <nil> DAOSupport: false EIP150: 0 EIP155: 0 EIP158: 0 Byzantium: 0 Constantinople: 0 Petersburg: 0 Istanbul: 0, Muir Glacier: <nil>, YOLO v2: <nil>, Engine: unknown}"
INFO [02-16|21:46:40.145] Disk storage enabled for ethash caches   dir=/Users/bagjeongtae/Desktop/node1/geth/ethash count=3
INFO [02-16|21:46:40.145] Disk storage enabled for ethash DAGs     dir=/Users/bagjeongtae/Library/Ethash count=2
INFO [02-16|21:46:40.145] Initialising Ethereum protocol           versions="[65 64 63]" network=10 dbversion=<nil>
WARN [02-16|21:46:40.145] Upgrade blockchain database version      from=<nil> to=8
INFO [02-16|21:46:40.147] Loaded most recent local header          number=0 hash="2bd1fd…2ba123" td=256 age=0
INFO [02-16|21:46:40.147] Loaded most recent local full block      number=0 hash="2bd1fd…2ba123" td=256 age=0
INFO [02-16|21:46:40.147] Loaded most recent local fast block      number=0 hash="2bd1fd…2ba123" td=256 age=0
INFO [02-16|21:46:40.147] Regenerated local transaction journal    transactions=0 accounts=0
INFO [02-16|21:46:40.148] Starting peer-to-peer node               instance=Geth/v1.9.25-stable-e7872729/darwin-amd64/go1.15.6
INFO [02-16|21:46:40.148] Mining too far in the future             wait=1943952h23m17.269s
INFO [02-16|21:46:40.276] New local node record                    seq=1 id=b3a7bc0f70f798d1 ip=127.0.0.1 udp=0 tcp=30303
INFO [02-16|21:46:40.277] Started P2P networking                   self="enode://3d161a305a562575f7ca7a3e99dc5254556fc126098e4128644fb580e3b83fd6fc5ad27ef721428d1473115442c7150da15c6f7a2ff08edd7623ca9dd0e192ba@127.0.0.1:30303?discport=0"
INFO [02-16|21:46:40.277] IPC endpoint opened                      url=/Users/bagjeongtae/Desktop/node1/geth.ipc
INFO [02-16|21:46:40.278] HTTP server started                      endpoint=[::]:8545 cors=* vhosts=localhost
INFO [02-16|21:46:40.278] WebSocket enabled                        url=ws://127.0.0.1:3334
INFO [02-16|21:46:40.329] Etherbase automatically configured       address=0x04dEb80cc89c42D8148312CFC16E1579E4aF7291
Welcome to the Geth JavaScript console!

instance: Geth/v1.9.25-stable-e7872729/darwin-amd64/go1.15.6
coinbase: 0x04deb80cc89c42d8148312cfc16e1579e4af7291
at block: 0 (Sun Feb 05 53099 09:16:49 GMT+0900 (KST))
 datadir: /Users/bagjeongtae/Desktop/node1
 modules: admin:1.0 debug:1.0 eth:1.0 ethash:1.0 miner:1.0 net:1.0 personal:1.0 rpc:1.0 txpool:1.0 web3:1.0

To exit, press ctrl-d

>

저는 start.sh 파일을 만들어 앞의 명령어를 실행했습니다.

다음 명령어를 통해 앞에서 생성한 keystore 파일을 확인할 수 있습니다.

> eth.accounts
["0x04deb80cc89c42d8148312cfc16e1579e4af7291", "0x56f11a78100226558194655c0eabf64f9627181d"]

3. 두 번째 노드 생성

여기서부터 상당히 중요합니다.

· genesis 블록 정의

제네시스 파일을 별도로 만들지 않고 앞에서 만든 제네시스 파일을 그대로 사용하여 초기화 작업을 진행해야 합니다. 또한 두 번째 노드 디렉터리에 keystore/가 없어도 됩니다.

일단 두 번째 노드가 데이터를 저장할 디렉터리를 새로 만들어 준 후 앞에서 만든 genesis.json을 그대로 복사합니다.

· 제네시스 블록 초기화

$ geth --datadir $PWD init genesis.json      
        
INFO [02-16|21:53:34.096] Maximum peer count                       ETH=50 LES=0 total=50
INFO [02-16|21:53:34.119] Set global gas cap                       cap=25000000
INFO [02-16|21:53:34.119] Allocated cache and file handles         database=/Users/bagjeongtae/Desktop/node2/geth/chaindata cache=16.00MiB handles=16
INFO [02-16|21:53:34.240] Writing custom genesis block 
INFO [02-16|21:53:34.241] Persisted trie from memory database      nodes=3 size=411.00B time="208.877µs" gcnodes=0 gcsize=0.00B gctime=0s livenodes=1 livesize=0.00B
INFO [02-16|21:53:34.242] Successfully wrote genesis state         database=chaindata hash="2bd1fd…2ba123"
INFO [02-16|21:53:34.242] Allocated cache and file handles         database=/Users/bagjeongtae/Desktop/node2/geth/lightchaindata cache=16.00MiB handles=16
INFO [02-16|21:53:34.317] Writing custom genesis block 
INFO [02-16|21:53:34.317] Persisted trie from memory database      nodes=3 size=411.00B time="130.919µs" gcnodes=0 gcsize=0.00B gctime=0s livenodes=1 livesize=0.00B
INFO [02-16|21:53:34.318] Successfully wrote genesis state         database=lightchaindata hash="2bd1fd…2ba123"

첫 번째 노드에서 제네시스 블록을 생성할 때 사용한 명령어와 동일합니다. 다만 해당 명령어를 수행하는 위치가 다릅니다.

제네시스 블록으로 생성된 데이터의 위치가 다른것을 확인할 수 있습니다.

· 노드실행

노드 실행준비가 벌써 끝났습니다.

여기서 개념이 상당히 잡히지 않을 수 있는데 여기선 개념 설명은 깊게 다루지 않겠습니다.

$ geth \
--datadir $PWD \
--syncmode 'full' \
--allow-insecure-unlock \
--networkid 10 \
--maxpeers 3 \
--http \
--http.port 8546 \
--http.addr "0.0.0.0" \
--http.corsdomain "*" \
--http.api "admin,eth,debug,miner,net,txpool,personal,web3" \
--ws \
--ws.port 3335 \
--ws.api eth,net,web3 \
--port 30304 \
--gasprice 21000 \
--nodiscover \
console

두 번째 노드를 실행할 때 중요한 건 이미 실행중인 첫 번째 노드에서 사용중인 포트를 곂치지 않게 해야합니다. 다음 3개를 수정합니다.

--http.port
--ws.port
--port

INFO [02-16|21:57:57.180] Maximum peer count                       ETH=3 LES=0 total=3
WARN [02-16|21:57:57.202] The flag --gasprice is deprecated and will be removed in the future, please use --miner.gasprice 
INFO [02-16|21:57:57.202] Set global gas cap                       cap=25000000
INFO [02-16|21:57:57.202] Allocated trie memory caches             clean=256.00MiB dirty=256.00MiB
INFO [02-16|21:57:57.202] Allocated cache and file handles         database=/Users/bagjeongtae/Desktop/node2/geth/chaindata cache=512.00MiB handles=5120
INFO [02-16|21:57:57.633] Opened ancient database                  database=/Users/bagjeongtae/Desktop/node2/geth/chaindata/ancient
INFO [02-16|21:57:57.634] Initialised chain configuration          config="{ChainID: 10 Homestead: 0 DAO: <nil> DAOSupport: false EIP150: 0 EIP155: 0 EIP158: 0 Byzantium: 0 Constantinople: 0 Petersburg: 0 Istanbul: 0, Muir Glacier: <nil>, YOLO v2: <nil>, Engine: unknown}"
INFO [02-16|21:57:57.634] Disk storage enabled for ethash caches   dir=/Users/bagjeongtae/Desktop/node2/geth/ethash count=3
INFO [02-16|21:57:57.634] Disk storage enabled for ethash DAGs     dir=/Users/bagjeongtae/Library/Ethash count=2
INFO [02-16|21:57:57.634] Initialising Ethereum protocol           versions="[65 64 63]" network=10 dbversion=<nil>
WARN [02-16|21:57:57.634] Upgrade blockchain database version      from=<nil> to=8
INFO [02-16|21:57:57.634] Loaded most recent local header          number=0 hash="2bd1fd…2ba123" td=256 age=0
INFO [02-16|21:57:57.634] Loaded most recent local full block      number=0 hash="2bd1fd…2ba123" td=256 age=0
INFO [02-16|21:57:57.634] Loaded most recent local fast block      number=0 hash="2bd1fd…2ba123" td=256 age=0
INFO [02-16|21:57:57.635] Regenerated local transaction journal    transactions=0 accounts=0
INFO [02-16|21:57:57.635] Mining too far in the future             wait=1943952h12m0.269s
INFO [02-16|21:57:57.635] Starting peer-to-peer node               instance=Geth/v1.9.25-stable-e7872729/darwin-amd64/go1.15.6
INFO [02-16|21:57:57.747] New local node record                    seq=1 id=4f2e17d5582c40f7 ip=127.0.0.1 udp=0 tcp=30304
INFO [02-16|21:57:57.747] Started P2P networking                   self="enode://f550e6c4d4da21ce708c7eab69db995e76059325c08111738ebbf62545ce9430c02148b4e87c4884c41dfc0dd3034fc55e75757341f0f954686e548426f51f02@127.0.0.1:30304?discport=0"
INFO [02-16|21:57:57.748] IPC endpoint opened                      url=/Users/bagjeongtae/Desktop/node2/geth.ipc
INFO [02-16|21:57:57.748] HTTP server started                      endpoint=[::]:8546 cors=* vhosts=localhost
INFO [02-16|21:57:57.749] WebSocket enabled                        url=ws://127.0.0.1:3335
WARN [02-16|21:57:57.793] Served eth_coinbase                      reqid=3 t="22.714µs" err="etherbase must be explicitly specified"
Welcome to the Geth JavaScript console!

instance: Geth/v1.9.25-stable-e7872729/darwin-amd64/go1.15.6
at block: 0 (Sun Feb 05 53099 09:16:49 GMT+0900 (KST))
 datadir: /Users/bagjeongtae/Desktop/node2
 modules: admin:1.0 debug:1.0 eth:1.0 ethash:1.0 miner:1.0 net:1.0 personal:1.0 rpc:1.0 txpool:1.0 web3:1.0

To exit, press ctrl-d
> INFO [02-16|21:58:00.511] Mapped network port                      proto=tcp extport=30304 intport=30304 interface="UPNP IGDv1-IP1"
>

실행을 정상적으로 마쳤습니다.

여기까지 이더리움 싱글노드 구축을 완료입니다.

4. 노드 동작 & 노드연결

이제 우리가 만든 노드를 하나의 시스템으로 묶어주기 위해 연결해줘야 합니다.

현재의 상황은 앞의이미지와 같습니다. 두 번째 노드에선 account new를 수행하지 않았기 때문에 해당 노드가 관리하고 있는 keystore 파일은 존재하지 않습니다.

· 네트워크 연결

앞에서 만든 두 개의 노드를 연결하기 위해 빨간색, 파란색으로 표시한 두 번째 박스를 보면 enode가 보일것입니다. enode는 노드간 연결하기 위한 식별자로 사용합니다.

첫 번째 노드의 enode를 복사합니다.

enode://3d161a305a562575f7ca7a3e99dc5254556fc126098e4128644fb580e3b83fd6fc5ad27ef721428d1473115442c7150da15c6f7a2ff08edd7623ca9dd0e192ba@127.0.0.1:30303?discport=0

두 번째 노드에서 첫 번째 노드의 enode로 연결 요청을 합니다.

> admin.addPeer('enode://3d161a305a562575f7ca7a3e99dc5254556fc126098e4128644fb580e3b83fd6fc5ad27ef721428d1473115442c7150da15c6f7a2ff08edd7623ca9dd0e192ba@127.0.0.1:30303?discport=0')

· 연결확인

다음 명령어를 통해 해당 노드가 연결된 피어를 확인할 수 있습니다.

> admin.peers

그냥 단순히 연결된 피어숫자 및 연결가능 상태를 확인하기 위해선 다음 명령어를 수행합니다.

> net
{
  listening: true,
  peerCount: 1,
  version: "10",
  getListening: function(callback),
  getPeerCount: function(callback),
  getVersion: function(callback)
}

listening은 연결 가능상태를 알려줍니다. true는 연결가능 상태입니다.

peerCount는 해당 노드가 연결된 피어수 입니다.

version이 일치한 노드만 연결할 수 있습니다.

5. 동작 테스트

마지막으로 우리가 만든 네트워크의 노드들이 잘 동작하는지 테스트해야 합니다.

그런데 무엇을 테스트해야할까요?

1. 트랜잭션 생성/전파
2. 블록 생성/전파
3. 동일한 state를 가지고 있는지

· 트랜잭션 생성/전파

가장먼저 확인해 볼 것은 트랜잭션을 생성하고 전파하는 부분입니다. 트랜잭션이 생성되면 해당 트랜잭션이 블록에 포함되기 전의 상태를 pending 상태라고 합니다. 즉, pending 상태의 트랜잭션 전파가 잘 이루어 지는지까지 테스트해야 합니다.

geth의 경우 keystore 파일에 lock이 걸려있기 때문에 트랜잭션을 발생하기 전에 unlock해야 합니다. 해당 명령어는 unlock하고자 하는 keystore 파일이 있는 노드에서 진행해야 하기 때문에 node1에서 진행합니다.

>  personal.unlockAccount(eth.accounts[0])
Unlock account 0x04deb80cc89c42d8148312cfc16e1579e4af7291
Passphrase: 
true

트랜잭션을 발생하는 명령어는 다음과 같습니다. (트랜잭션을 발생하는 방법은 여러가지 있습니다)

eth.sendTransaction({from: 발신자, to: 수신자, value: 금액(단위 wei)})

> eth.sendTransaction({from: eth.accounts[0], to: eth.accounts[1], value: 123})

WARN [02-16|22:23:00.390] Caller gas above allowance, capping      requested=125222772 cap=25000000
INFO [02-16|22:23:00.390] Submitted transaction                    fullhash=0x438f1f0bcba2bfafa76b6c80d5838648d3b79d6f2bfe7b0920393f061592fca7 recipient=0x2c08FF6B5cfaA09BBe87c2B16B0f3A234901917E
"0x438f1f0bcba2bfafa76b6c80d5838648d3b79d6f2bfe7b0920393f061592fca7"

앞의 결과처럼 나온다면 트랜잭션이 정상적으로 발생된 것 입니다.

발생된 트랜잭션을 확인하기 위해 다음 명령어를 수행합니다.

eth.pendingTransactions

첫 번째 노드에서 발생한 트랜잭션이 두 번째 노드에 잘 전파된 모습을 확인할 수 있습니다.

여기서부터 앞에서 실수한 부분이 있어 주소값이 앞과 상이하게 표시될 수 있습니다.

(여기서 from, to가 앞에서 생성안 주소랑 달라지는데 글을 쓰면서 구동을 하다보니 실수해서 다시 처음부터 진행한 덕에 주소값이 다르게 표시됩니다)

· 블록생성 전파

블록생성의 경우 아무 노드에서나 다음 명령어를 수행하면 됩니다.

> miner.start()
> miner.stop()

저는 첫 번째 노드에서 블록을 생성했지만 두 번째 노드에서 블록생성을 시도하겠습니다. 그리고 앞에서 생성한 트랜잭션 해쉬값은 잘 가지고 있습니다. 추후에 블록에 잘 들어갔는지 확인하는 용도로 사용할 것 입니다.

0x438f1f0bcba2bfafa76b6c80d5838648d3b79d6f2bfe7b0920393f061592fca7

아직 블록에 포함되지 않았기 때문에 blockHash와 blockNumber가 null이 저장되있습니다.

> eth.getTransaction('0x438f1f0bcba2bfafa76b6c80d5838648d3b79d6f2bfe7b0920393f061592fca7')
{
  blockHash: null,
  blockNumber: null,
  from: "0x598373c741d15d4c6b993288fe94e92231355d12",
  gas: 21000,
  gasPrice: 21000,
  hash: "0x438f1f0bcba2bfafa76b6c80d5838648d3b79d6f2bfe7b0920393f061592fca7",
  input: "0x",
  nonce: 8,
  r: "0x95664b35aa1cc1945564a57baa624f519c10d236b579aecc52df8a9503fa2946",
  s: "0x192aa1271dfcae8d44dcc3ba7ec50a7e8bc5139ebbc2e777002e2bc7eed4f2a",
  to: "0x2c08ff6b5cfaa09bbe87c2b16b0f3a234901917e",
  transactionIndex: null,
  v: "0x37",
  value: 123
}

저는 두 번째 노드인 아래 노드에서 POW 알고리즘을 동작했습니다. POW 결과에 따라 생성된 블록을 연결된 첫 번째 노드로 전파를 합니다. miner.stop()을 이용하여 마이닝을 멈춰줍니다.

> eth.blockNumber

블록갯수 확인

> eth.getTransaction('0x438f1f0bcba2bfafa76b6c80d5838648d3b79d6f2bfe7b0920393f061592fca7')
{
  blockHash: "0x560ed0ae33404daeb8c23da288532fba46220a9f13c3c0380d4be2061887d09e",
  blockNumber: 71,
  from: "0x598373c741d15d4c6b993288fe94e92231355d12",
  gas: 21000,
  gasPrice: 21000,
  hash: "0x438f1f0bcba2bfafa76b6c80d5838648d3b79d6f2bfe7b0920393f061592fca7",
  input: "0x",
  nonce: 8,
  r: "0x95664b35aa1cc1945564a57baa624f519c10d236b579aecc52df8a9503fa2946",
  s: "0x192aa1271dfcae8d44dcc3ba7ec50a7e8bc5139ebbc2e777002e2bc7eed4f2a",
  to: "0x2c08ff6b5cfaa09bbe87c2b16b0f3a234901917e",
  transactionIndex: 0,
  v: "0x37",
  value: 123
}
> eth.pendingTransactions
[]

트랜잭션이 블록에 포함된 정보와 pending 상태의 트랜잭션이 비어져있는 모습을 확인할 수 있습니다.

· state 확인

앞에서 블록, 트랜잭션 상태가 동일하게 공유된 모습을 확인했습니다. 하지만 가장 중요한 것은 주소마다 보유한 이더리움이 같은지 확인을 해야합니다. 첫 번째 노드에서 관리중인 keystore의 주소값을 조회하기 위해 eth.accounts를 이용합니다.

> eth.accounts
["0x598373c741d15d4c6b993288fe94e92231355d12", "0x2c08ff6b5cfaa09bbe87c2b16b0f3a234901917e", "0xffe3aa6829730ded2c9f8a8ef1e72303f628c9b3"]

이제 각각의 이더잔액을 조회하기 위해 eth.getBalance()를 이용합니다,

> eth.getBalance(주소)

> eth.getBalance('0x598373c741d15d4c6b993288fe94e92231355d12')
> eth.getBalance('0x2c08ff6b5cfaa09bbe87c2b16b0f3a234901917e')
> eth.getBalance('0xffe3aa6829730ded2c9f8a8ef1e72303f628c9b3')

첫 번째, 두 번째 노드에서 실행하여 잔액을 확인합니다.

여기서 Looking for peers는 노드를 실행할 때 --nodiscovery 옵션을 주지 않았기 때문에 주기적으로 연결할 노드를 탐색하고 있는 로그입니다.

이번 시간엔 private한 형태로 네트워크 구축하는 방법을 알아보았습니다.

다음 시간엔 여기서 다루지 않은 개념적인 내용과 우리가 만든 private 네트워크망에서 노드 모니터링을 연동해보도록 하겠습니다.

https://ethstats.net/

[ethereum] mnemonic 생성, privatekey 복구와 계층적 구조의 원리

멍개. — Sat, 27 Aug 2022 16:54:29 +0900

· 라이브러리 설치

$ npm install --save bip39 $ npm install --save ethereumjs-wallet

· mnemonic 생성

const bip39 = require("bip39");
const mnemonic = bip39.generateMnemonic();
console.log(`mnemonic is : "${mnemonic}"`);

bip39를 이용하여 mneminic을 생성할 수 있습니다. mnemonic은 12개의 단어로 이루어진 문자열입니다.

· privatekey 복구

const bip39 = require("bip39");
const { hdkey } = require("ethereumjs-wallet");

const mnemonic = "good buyer welcome fabric call effort initial vendor surge diesel leader flip";
(async () => {

  const seed = await bip39.mnemonicToSeed(mnemonic); // seed === entropy
  const rootKey = hdkey.fromMasterSeed(seed);
  const hardenedKey = rootKey.derivePath("m/44'/60'/0'/0");
  const childKey = hardenedKey.deriveChild(0); // 값조정 가능
  const wallet = childKey.getWallet();
  const address = wallet.getAddress();
  const privateKey = wallet.getPrivateKey();
  console.log(`seed is ${seed.toString('hex')}`)
  
  console.log(`======== rootKey =======`)
  console.log(rootKey)

  console.log(`======= childKey =======`)
  console.log(childKey)

  console.log(`======= wallet is =======`)
  console.log(wallet)

  console.log(`address is ${address.toString("hex")}`);
  console.log(`privateKey is ${privateKey.toString("hex")}`);
})()

생성된 mnemonic을 이용하여 privatekey와 address를 생성할 수 있습니다.

mnemonic을 이용하면 항상 동일한 privatekey와 address를 생성할 수 있습니다. 정확히 말하면 childrenKey를생성하게 됩니다.

mnemonic을 이용하면 128Bits의 seed(entropy)를 생성합니다 seed를 이용하여 masterKey를 생성하며 마스터키를 이용하여 childrenKey 생성이 가능하며 해당 키를 이용하여 public, private key생성이 가능해집니다. 아래 이미지를 참고하면 좀 더 이해가 쉬울겁니다.

masterKey 또는 childrenKey의 derivePath를 이용하면 privateKey와 publicKey생성이 가능합니다.

이러한 구조를 계층구조라고 합니다

let hardenedKey1 = childKey.derivePath("m/44'/60'/0'/0");
let childKey1 = hardenedKey1.deriveChild(0)
console.log(childKey1.getWallet().getAddress().toString('hex'))
console.log(childKey1.getWallet().getPrivateKey().toString('hex'))

해당 코드처럼 앞에서 생성한 childrenKey를 이용하여 또다시 childrenKey 생성이 가능합니다.

여기서 한가지 의문점이 있을 수 있습니다.

바로 derivePath인데 해당 구문은 다음 이미지를 참조하면 이해할 수 있습니다.

m / purpose' / coin_type' / account' / change / address_index

이더리움은 coin_type이 60입니다.

coin_type의 자세한 정보는 아래 링크에서 확인할 수 있습니다.

https://github.com/satoshilabs/slips/blob/master/slip-0044.md

샘플 코드는 깃허브에서 확인가능 합니다.

https://github.com/pjt3591oo/ether-mnemonic

[ethereum] privatekey를 이용하여 address 복구, transaction 발생

멍개. — Sat, 27 Aug 2022 16:52:00 +0900

privateKeyToAccount()를 이용하면 privatekey를 이용하여 account를 가져올 수 있습니다.

let Web3 = require('web3')
let web3 = new Web3(new Web3.providers.HttpProvider('https://ropsten.infura.io'));

let PK = "0x1076f9a014620c526eaf424cad97755a8d5c1a492f2637731f56975d30805db6"

let account = web3.eth.accounts.privateKeyToAccount(PK)
console.log(account)

· 실행결과

{ address: '0x31bF95273C33C9042da801580F6d54a6f11b3CfE',
  privateKey:
   '0x1076f9a014620c526eaf424cad97755a8d5c1a492f2637731f56975d30805db6',
  signTransaction: [Function: signTransaction],
  sign: [Function: sign],
  encrypt: [Function: encrypt] }

가져온 account에서 encrypt를 이용하면 keystore를 만들 수 있고, signTransactio을 이용하면 트랜잭션에 서명하여 rawTransaction을 만들 수 있습니다.

· sample

let Web3 = require('web3')
let web3 = new Web3(new Web3.providers.HttpProvider('https://ropsten.infura.io'));

/*
  web3.utils.toWei(1, 'ether')  : 1ETH        => 1 * 10 ^ 18
  web3.utils.fromWei(1, 'ether'): 1 * 10 ^ 18 => 1ETH
*/

(async () => {
  let EOA1 = "0x31bF95273C33C9042da801580F6d54a6f11b3CfE"
  let PK = "0x1076f9a014620c526eaf424cad97755a8d5c1a492f2637731f56975d30805db6"
  let EOA2 = "0x22C353816541d2437dd9Aa673Be0de07d869df6B"

  let eoa1_nonce = await web3.eth.getTransactionCount(EOA1, "pending")
  let balance = await web3.eth.getBalance(EOA1)
  
  console.log(eoa1_nonce)
  console.log(balance)
  console.log(web3.utils.toWei("0.1", 'ether'))
  console.log(web3.utils.toWei("21", 'Gwei'))

  let txParam = {
    nonce: eoa1_nonce,
    from: EOA1,
    to: EOA2,
    value: web3.utils.toHex(web3.utils.toWei("0.1", 'ether')), // 0.1 이더
    gasPrice: web3.utils.toHex(web3.utils.toWei("21", 'Gwei')), // 가스 가격
    gasLimit: web3.utils.toHex(300000), // 가스 최대 사용량
  }

  let account = web3.eth.accounts.privateKeyToAccount(PK)
  let signedTx = await account.signTransaction(txParam)

  let txInfo = await web3.eth.sendSignedTransaction(signedTx.rawTransaction, (err, txHash) => {
    if (err) {
      console.log('========== transaction 발생 중 에러 ===========')  
      return
    }
    console.log('========== transaction 발생 ===========')
    console.log(txHash)
  })

  console.log('========== transaction 처리완료 ===========')
  console.log(txInfo)
})()

[블록체인] 블록체인 시스템은 어떻게 구축할까 1편 - exchange, wallet, payment에서 transaction 취급방법

멍개. — Sat, 27 Aug 2022 16:40:34 +0900

▶ 서론

블록체인의 가장 큰 단점은 처리속도가 느리다는 점 입니다!!

처리속도가 느리다는건 transaction을 처리하는데 소요 시간이 든다는 점 입니다. 이러한 특징 때문에 블록체인 기반 어플리케이션은 transaction 처리를 많이 고민해야 합니다. 또한, 모든 어플리케이션이 transaction을 같은 형태로 처리하지 않습니다.

블록체인 기반의 어플리케이션을 만들게 되면, 블록체인과 데이터베이스의 동기화가 중요합니다. 그렇기 때문에 시스템 특징에 따라 transaction 관리방법을 달리합니다.

필자는 블록체인 기반의 유통 시스템, 평가 시스템 등 다양한 시스템을 구축하면서 transaction 처리 방법에 대해 많은 연구와 고민을 하였으며, 이번글에서는 큰 차별점을 가진 거래소, 지갑, 암호화폐 기반 결제 시스템의 transaction 처리 방법을 소개합니다. 또한 해당 시스템의 기본적인 구조도 함께 소개합니다.

~~( 참고로 필자는 현재 거래소와 암호화폐기반 결제 시스템 및 지갑을 개발하고 있습니다.)~~

● 1. 거래소(exchange)

가장먼저, 거래소 시스템에서 transaction을 어떻게 관리하는지 알아보겠습니다.

거래소는 발생된 모든 거래 내역은 블록체인에 저장하지 않습니다. 거래소에서 대표적인 기능을 알아보겠습니다.

· 1.1 거래소 대표기능

[그림 1.1] 거래 페이지

[그림 1.2] 출금 페이지

[그림 1.3] 입금 페이지

1. 코인/토큰 매매 등록하기

2. 코인/원화 입금하기

3. 코인/원화 출금하기

거래소의 대표적인 기능 3가지 입니다. 여기서 3번만 블록체인에 저장합니다. 하지만 특정 상황에 대해서만 블록체인에 transaction을 관리하고 일반적으로는 데이터베이스로만 관리합니다.

· 1.2 코인/토큰 매매 등록하기

거래소에서 가장 핵심 기능인 매매 기능을 알아보겠습니다. 사용자는 보유 원화/코인/토큰을 이용하여 구매, 판매등록을 합니다. 사용자가 보유한 원화/코인/토큰은 해당 거래소 시스템에서 데이터베이스로 관리합니다.

[그림 1.4] 데이터 베이스 - balance관리

유저가 매매 등록을 하면 balanceTable에서 매매한 만큼 차감을 합니다. 그다음 매칭을 위해 해당 내역을 테이블에 저장합니다. 여기서 매매 등록행위를 오더(order)를 등록한다고 표현합니다. 등록된 오더들을 오더북(orderBook)이라고 부릅니다.

[그림 1.5] 데이터 베이스 - 오더관리

사용자가 오더(매매)를 넣으면 보유중인 원화/코인/토큰을 저장하는 balance 테이블을 업데이트 한 후 orderBook에 해당 주문을 추가합니다.

[그림 1.6] 데이터 베이스 - 채결 데이터 관리

오더를 받는 서버에서 이제 매칭 서버로 해당 오더를 주게되면 매칭 서버는 해당 오더와 채결할 데이터를 선별하여 채결합니다. 이렇게 되면 orderBook 테이블에서 채결 테이블로 옮기게 됩니다. 이때 누구의 오더와 채결했는지를 저장한 후 채결과 동시에 balanceTable을 업데이트 합니다.

(참고로 이 외에 종가를 저장하는 테이블이나 수수료 처리를 하게 됩니다.)

주문을 넣는 프로세스에는 블록체인에서 transaction을 발생하지 않습니다. tx를 발생할 경우 트래픽이 몰리면 해당 데이터를 빠르게 처리할 수 없기 때문입니다.

(사실 다른 이유가 있지만 이 부분은 기술적인 부분보다 비즈니스 적인 부분이라 언급하지 않겠습니다.)

※ 결론. 매수/매도에서는 transaction을 발생시키지 않는다.

· 1.3 코인/원화 입/출금하기

거래소는 직바을 2가지 형태로 관리를 합니다.

1. 거래소(admin) 지갑

2. 사용자(user) 지갑

만약, 거래소에서 생성한 지갑에 돈을 입금하면 거래소 시스템에서는 게더링 서버가 동작하여 사용자 지갑에 있는 코인 및 토큰을 거래소 지갑으로 옮깁니다.

[그림 1.7] 게더링 서버

사용자 지갑에 있는 보유 코인/토큰을 거래소 지갑으로 옮긴 후, 사용자 코인량을 관리하는 balance 테이블에 옮긴만큼 증가하여 업데이트 합니다. 토큰의 경우, 지갑에 돈을 입금하면 자동으로 거래소 지갑으로 옮기는 형태로 개발가능합니다.(이 부분은 따로 개발 방법을 알아보겠습니다.)

그리고 여기서 사용자 지갑 -> 거래소 지갑으로 실제 코인/토큰을 옮겨야 하기 때문에 transaction을 발생합니다. 그렇기 때문에 거래소에서 생성한 지갑으로 입금하면 다수의 transaction이 발생합니다.

다음으론 출금입니다. 출금을 하게되면 수신자가 거래소에서 관리되고 있는 지갑인지 검사합니다. 거래소에서 관리하는 지갑이면 데이터 베이스만 업데이트 합니다. 하지만 거래소에서 관리중인 지갑이 아니면 거래소(admin) 지갑에서 수신자에게 전송하는 transaction을 발생합니다.

[그림 1.8] 트랜잭션 처리

입/출금에서 발생한 transaction은 transaction 처리를 검사하는 배치서버를 통해 검사합니다.

자 여기서! 한가지 중요한점은 거래소 입/출금은 우리가 알고있는 입/출금의 개념이 아닙니다. 거래소 시스템에서 관리하는 지갑으로 돈이 들어온 경우 입금, 거래소 시스템에서 관리하고 있는 코인/토큰/원화가 빠져 나가는 것을 출금이라고 하며, 이 경우에만 트랜잭션을 발생합니다.

즉, 거래소는 블록체인으로만 이루어진 시스템이 아닙니다.

● 2. 지갑(wallet)

지갑은 거래소처럼 복잡한 시스템을 구축하지 않습니다. 지갑의 경우 비즈니스 모델이 약하기 때문에 심플한 형태로 구축합니다.

[그림 2.1] 사용자 wallet, transaction 관리

블록체인 자체에서 이력관리는 가능하나 사용자에게 띄워주기 위해 많은 리소스가 들어가므로 일부 데이터 시스템을 이용하여 사용자에게 편의성을 제공합니다.

[그림 2.2] 전송요청

지갑은 사용자 관리를 해야하기 때문에 회원가입을 하게되고 회원가입한 유저에 대해 지갑(주소)를 만들어 줍니다. 여기서는 출금(전송)을 하게되면, 즉시 transaction을 발생하고 사용자에게 응답합니다.

[그림 2.3] 월랫 전송 프로세스

transaction이 블록에 포함되기 까지 기다리지 않고 만들어진 txHash를 즉시 응답하는 것이 포인트 입니다. 물론 기다려도 됩니다. 하지만 필자의 경우는 기다리지 않고 즉시 응답하여 사용자에게 대기중이라는 메시지를 띄워주는 형태로 시스템을 만들었습니다.

월랫의 데이터 베이스는 사용자의 보유량을 따로 저장하지 않습니다. 잔액 조회시 디비가 아니라 블록체인 네트워크에 조회를 하여 보유량을 알려줍니다. 그렇기 때문에 어느 지갑에서나 사용가능합니다.

※ 추가로. 지갑의 경우 데이터 베이스 없이 완전 P2P 형태로 개발 가능합니다. 이럴경우 해당 어플리케이션에서 관리하는 데이터 베이스(캐시, 로컬 데이터 베이스)를 지울경우 사용 내역을 볼 수 없고, 사용자 식별이 힘든 부분이 있어 일부 데이터 베이스 시스템에 의존합니다. 만약, 데이터 베이스 시스템 없이 구축하게 되면 블록체인 시스템에서 트랜잭션 처리 완료시 이벤트를 받아서 처리하면 됩니다.

● 3. 암호화폐 결제(payment)

앞의 시스템을 응용하여 암호화폐 결제할 수 있습니다

[그림 3.1] 암호화폐 기반 결제

[그림 3.1] 처럼 쇼핑몰에 암호화폐 결제방법을 사용하여 결제할 수 있습니다.

암호화폐 결제시 transaction을 처리방법은 앞에서 지갑(wallet)에서 트랜잭션을 기다리면 됩니다. 지갑(wallet) 시스템처럼 기다리지 않아도 되지만 기다리는 것이 구조상 훨씬 간단합니다.

[그림 3.2] 결제 시스템 전송 프로세스

결제 시스템의 경우 안정성이 중요하기 때문에 하나의 트랜잭션(of DataBase) 보장을 해줘야 합니다. 이렇게 되면 트랜잭션 처리 검사 배치서버를 두지 않아도 됩니다. 훨씬 더 심플해지는 대신 응답 시간이 다소 소요됩니다.

여기서 결제 시스템의 경우 트랜잭션을 발생하고 해당 트랜잭션 처리를 기다려 줍니다. 트랜잭션 처리 응답을 받고 transactionComplete 테이블에 저장한후 사용자에게 결제가 완료됬다고 알려줍니다. 여기서 사용자는 일반 사용자일 수 있고 암호화폐 시스템을 연동한 다른 시스템일 수 있습니다.

물론 결제 시스템이기 때문에 사용자는 인증된 유저에 한해서만 결제를 진행하도록 해야합니다. 여기서 유저 인증은 API 키를 발급하는 형태로 진행할 수 있습니다.

이러한 부분을 SDK 형태로 만든다면 naver pay 처럼 사용 가능합니다. 현

● 4. 결합(combination)

앞에서 보여드린 3가지의 시스템은 독립적으로는 의미가 없습니다. 각각의 시스템은 하나의 시스템으로 만들어 졌을때 빛을 발합니다. 예를 들면 다음과 같이 시스템을 구축할 수 있습니다.

먼저, wallet와 payment 시스템은 하나의 서버에서 /wallet, /payment로 라우트하여 처리합니다. /wallet의 경우 트랜잭션을 기다리지 않기 때문에 transaction 테이블을 사용하고, /payment는 transaction 처리를 기다리으모 transactionComplete 테이블을 사용합니다.

payment와 wallet은 동일한 계정을 사용하여 wallet에서 다른 사람으로부터 받은 암호화폐를 payment 시스템에서 사용가능 합니다. 여기서 거래소 시스템을 별도로 두는 이유는 거래소 시스템은 게더링 서버를 통해 유저 지갑에 보유중인 금액을 거래소 지갑으로 옮기기 때문에 결제시 해당 지갑주소에 보유금액이 없어 결제가 되지 않습니다.

/payment에서는 결제만 가능하고 다른 유저에게 코인 전송하는 기능은 없습니다. 다른 사람에게 암호화폐를 받기 위해서는 wallet을 통해 받거나 줄 수 있습니다.

★ 정리

먼저, 블록체인은 실시간 처리에서 사용하는 것 보다 데이터를 요청하고 즉시 응답을 받지 않아도 되는 시스템에서 사용하는 것이 좋습니다. 실생활에서도 요청과 즉시 바로 응답이 되는 시스템이 있지만 요청을 하더라도 며칠이 걸리는 작업이 있습니다. 블록체인은 이러한 곳에 활용한다면 좀 더 좋은 곳에 활용가능 하다고 생각합니다.

해당 글에서 사용한 이미지 및 자료는 저와 저의 회사에서 실제 개발했던, 개발중인 시스템 구조도와 UI 입니다. 거래소는 현재 CBT 진행중인데 버그가 넘 많아서 골치 아프고 암호화폐 기반 결제 시스템은 프로젝트 기간이 워낙 짧아서 골치아퍼하는 멍개였습니다. 현재는 naverpay 처럼 시스템을 구축하기 위해 인증 부분과 SDK 설계 및 준비중입니다. SDk를 만들어서 배포하게 되면 다른 사람들도 같이 사용해야 하는 부분이라 문서화가 미흡한 부분 작업중입니다

[블록체인] 거래소는 시세를 어떻게 형성할까?

멍개. — Sat, 27 Aug 2022 16:34:57 +0900

거래소의 호가창에 대해서 알아보겠습니다. 먼저 거래소의 기본적인 모습을 알아보겠습니다.

거래소마다 다르긴 하겠지만 일반적인 모습입니다. 여기서 호가창이란 등록된 매수(사기)/매도(팔기)를 띄어주는 부분입니다.

호가창
동현코인	가격	수량
매도	1008	800
매도	1007	700
매도	1006	600
매도	1005	500
매도	1004	400
매도	1003	300
매도	1002	200
매도	1001	100
매수	1000	100
매수	999	200
매수	998	300
매수	997	400
매수	996	500
매수	995	600
매수	994	700
매수	993	800

해당 테이블이 호가정보입니다. 해당 테이블이 어떤것을 의미 하는지 알아보겠습니다.

가장 좌측은 매수/매도를 구분짓는 부분입니다. 다음으로 가격과 수량입니다. 매도의 가장 아랫부분을 보면 다수의 사람들이 1001원에 100개의 코인을 팔겠다고 등록한 부분입니다. 한명이 1001원에 100개를 등록했을 수 있고 아닐 수 있습니다.

호가창 구성 내용
매도			매수
아아디	가격	수량	아이디	가격	수량
1	1001	50	14	1000	100
2	1001	50	15	999	50
3	1002	120	16	998	200
4	1002	80	17	997	200
5	1003	300	18	996	100
6	1004	400	19	995	200
7	1005	150	20	994	700
8	1006	400	21	993	800
9	1007	700	22	999	150
10	1008	100	23	998	100
11	1008	700	24	997	200
12	1006	200	25	996	400
13	1005	350	26	995	400

이러한 형태로 매수/매도가 등록되면 해당 데이터를 정렬하여 앞의 호가 테이블처럼 띄워주게 됩니다.

앞의 호가테이블처럼 시장가가 형성되면 이떄부터 거래가 이루어 지면서 시장가가 형성되는데 원리를 알아보겠습니다.

누군가가 1001원으로 50개를 매수하면 다음처럼 호가 테이블이 바뀝니다.

호가창
멍개코인	가격	수량
매도	1008	800
매도	1007	700
매도	1006	600
매도	1005	500
매도	1004	400
매도	1003	300
매도	1002	200
매도	1001	50
매수	1000	100
매수	999	200
매수	998	300
매수	997	400
매수	996	500
매수	995	600
매수	994	700
매수	993	800

1001원에 100개 있었지만 50개를 사갔기 때문에 50개를 매칭시켜줍니다.

여기서 다시 1001원으로 40개 매수가 들어오면 다음과 같이 바뀝니다.

호가창
멍개코인	가격	수량
매도	1008	800
매도	1007	700
매도	1006	600
매도	1005	500
매도	1004	400
매도	1003	300
매도	1002	200
매도	1001	10
매수	1000	100
매수	999	200
매수	998	300
매수	997	400
매수	996	500
매수	995	600
매수	994	700
매수	993	800

해당 가격에 등록된 매물이 있었기 때문에 바로 채결성공 합니다. 하지만 매수/매도 했을 때의 가격으로만 체결하지 않습니다.

만약 1002원으로 110개의 코인을 매수한다면 다음과 같이 바뀝니다.

호가창
멍개코인	가격	수량
매도	1009
매도	1008	800
매도	1007	700
매도	1006	600
매도	1005	500
매도	1004	400
매도	1003	300
매도	1002	100
매수	1000	100
매수	999	200
매수	998	300
매수	997	400
매수	996	500
매수	995	600
매수	994	700
매수	993	800

1002원의 코인을 먼저사지 않고 1002원보다 싼 1001원을 먼저 구매한 후 남은량만큰 1002원에 등록된 코인을 구입합니다.

매수를 할 땐 매수할 때 등록한 금액보다 싼 금액을 우선적으로 채결합니다. 반대로 매도일 땐 비싼 금액을 우선적으로 채결합니다.

즉, 다른사람들이 매수에 코인을 사겠다고 올렸고, A가 998원에 300개만큼 매도를 하면 998원에 등록된 300개가 아닌 1000원과 999원에 등록된 100, 200개를 판매하게 됩니다. 즉, 팔때는 비싼 가격에 팔 수 있도록 하고, 살땐 싼 가격에 살 수 있도록 매칭서버가 체결합니다.

그렇기 때문에 매수/매도에서는 가장 비싼 금액과 가장 싼 금액을 우선적으로 체결합니다. 체결하는 서버를 매칭서버라고 하며, 간단하게 매칭 알고리즘이라고 합니다.

이번글에서는 거래소에서 시세가 어떻게 형성하는지 간단히 알아보았습니다. 다음번에는 해당 내용을 코드적으로 접근해보겠습니다.

[ethereum] transaction에 데이터를 포함하여 영원히 데이터 남기기

멍개. — Sat, 27 Aug 2022 16:31:03 +0900

transaction에서 input data를 포함하여 전송하는 방법을 알아보겠습니다. input data가 머냐 하시는 분들이 있을텐데 다음 링크를 접속하면 다음과 같이 보실 수 있습니다.

· 예시

https://etherscan.io/tx/0xe4ee15d3f63db8464a649e3237ed83e930f9b3e40e842537a626745d1c96553c

만약 해당 이미지처럼 안 나오면 view input As 버튼에서 UTF-8로 선택하면 됩니다.

· 계정 준비하기

테스트이기 때문에 ropsten 네트워크에서 진행합니다.

해당 계정의 private key를 이용하여 myetherwallet에서 정상적으로 읽어지는지 확인해보겠습니다.

잘 읽어와집니다. 이제 여기서 input data를 포함하여 전송하는 방법을 알아보겠습니다.

1. + 고급: 데이터 추가 버튼 누르기

빨간색으로 표시해둔 부분을 눌러주면 다음과 같이 나타납니다.

데이터에 데이터를 넣으면 됩니다. 근데 그냥 키보드로 입력한 값을 넣으면 안됩니다. 인코딩된 데이터를 넣어야 정상적으로 transaction이 발생됩니다.

· 데이터 인코딩

https://www.browserling.com/tools/url-encode

해당 사이트에 들어가면 데이터 인코딩을 할 수 있습니다.

입력란에 데이터를 입력한 후 URL Encode! 버튼을 눌러주면 인코딩된 결과를 볼 수 있습니다.

앞의 결과는 '안녕하세요'를 입력한 후 이코딩을 한 결과입니다. 여기서 %를 지웁니다.

· %지우기 전

%EC%95%88%EB%85%95%ED%95%98%EC%84%B8%EC%9A%94

· % 지운 후

EC9588EB8595ED9598EC84B8EC9A94

%를 지운 결과를 복사한 후 앞의 고급: 데이터 추가를 눌었을 때 생긴 입력란에 넣어줍니다.

· transaction 발생

데이터를 넣어줄 땐 0x를 붙여서 넣어줍니다. 0x는 16진수를 의미합니다. 받는 주소는 본인으로 한 후 0이더를 보내줍니다. 소량의 수수료만 지불하면 됩니다. 이제 트랜잭션을 생성해줍니다.

트랜잭션 생성 버튼을 누르면 트랜잭션 전송하기 버튼이 나옵니다 여기서 트랜잭션 전송하기 버튼을 눌러줍니다.

트랜잭션 전송하기 버튼을 누르면 앞의 이미지처럼 모달창이 뜹니다. 여기서 네. 맞습니다! 전송합니다. 버튼을 눌러줍니다.

하단에 transaction이 정상적으로 발생했다고 알림을 띄워줍니다. 여기서 verify Transaction 버튼을 누르면 이더스캔에서 바로 확인가능 합니다.

input data에 트랜잭션 발생시 포함한 데이터가 들어있습니다. View Input As 버튼을 눌러서 UTF-8을 눌러줍니다.

디코딩 된 결과가 잘 표시됩니다.

하지만 앞의 사이트에서 인코딩을 할 때 주의할 점은 한글이외의 영어, 숫자, 특수문자는 인코딩이 잘 되지 않습니다.

· 한글이외의 영문, 숫자, 특수문자 인코딩 방법

한글 이외의 문자는 아스키코드표를 참조하면 됩니다. 아스키코드표란 문자와 숫자를 1:1 매핑시킨 표입니다.

만약 숫자 0을 입력하고 싶으면 16진수로 30이 됩니다. 10진수로 변환하면 48에 해당하는 숫자입니다.

이번에는 '안녕하세요!'를 인코딩해보겠습니다. 먼저, '안녕하세요'는 앞의 인코딩 사이트를 가셔서 인코딩한 후 %를 모두 지워줍니다.

· '안녕하세요' 인코딩 결과

EC9588EB8595ED9598EC84B8EC9A94

그리고 !가 0x21이기 때문에 인코딩 결과에 21을 붙이면 됩니다.

· '안녕하세요!' 인코딩 결과

EC9588EB8595ED9598EC84B8EC9A9421

'안녕하세요!'가 잘 출력됩니다.

· 아스키코드 특수문자 알아보기

스페이스: 0x20
엔터: 0x0A

스페이스를 넣고싶을 땐 20, 엔터를 넣고 싶을 땐 0A를 넣으면 됩니다.

[ethereum] abi-decoder를 이용하여 inputData 해독하기

멍개. — Sat, 27 Aug 2022 16:28:44 +0900

안녕하세요. 멍개입니다.

abi-decoder 라이브러리를 이용하여 transaction에 포함된 inputData를 해석하는 방법을 다뤄보도록 하겠습니다.

· abi-decoder 모듈설치

$ npm install --save abi-decoder

npm을 이용하면 간단하게 설치할 수 있습니다.

· abi 추출하기

transaction의 inputData를 디코딩하기 위해서는 해당 컨트랙트의 ABI가 필요합니다.

pragma solidity 0.5;

contract test {
    uint var1 = 10;
    string var2 = "hello world";
    
    function setData(uint a, uint b, string memory c) public {
        var1 = a + b;
        var2 = c;
    }
    
    function getData() public view returns(uint) {
        return var1 + 10;
    }
}

ABI 복사 버튼을 눌러줍니다.

[
	{
		"constant": true,
		"inputs": [],
		"name": "getData",
		"outputs": [
			{
				"name": "",
				"type": "uint256"
			}
		],
		"payable": false,
		"stateMutability": "view",
		"type": "function"
	},
	{
		"constant": false,
		"inputs": [
			{
				"name": "a",
				"type": "uint256"
			},
			{
				"name": "b",
				"type": "uint256"
			},
			{
				"name": "c",
				"type": "string"
			}
		],
		"name": "setData",
		"outputs": [],
		"payable": false,
		"stateMutability": "nonpayable",
		"type": "function"
	}
]

· transaction 발생하여 inputdata 얻기

setData 함수를 호출하여 transaction을 발생합니다.

0xf8075633000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000000a68656c6c20776f726c6400000000000000000000000000000000000000000000

inputData는 to가 CA(contract address)라면 블록체인 네트워크에서 노드가 읽어서 EVM에서 실행하게 됩니다. 이제 inputData를 해독해보겠습니다.

· inputData 해독

앞에서 ABI와 transaction에 포함된 InputData를 복사합니다.

const abiDecoder = require('abi-decoder');

const testABI = [
	{
		"constant": true,
		"inputs": [],
		"name": "getData",
		"outputs": [
			{
				"name": "",
				"type": "uint256"
			}
		],
		"payable": false,
		"stateMutability": "view",
		"type": "function"
	},
	{
		"constant": false,
		"inputs": [
			{
				"name": "a",
				"type": "uint256"
			},
			{
				"name": "b",
				"type": "uint256"
			},
			{
				"name": "c",
				"type": "string"
			}
		],
		"name": "setData",
		"outputs": [],
		"payable": false,
		"stateMutability": "nonpayable",
		"type": "function"
	}
]
abiDecoder.addABI(testABI);

// testData엔 transaction의 inputData를 넣어줍니다.
const  testData  =  "0xf80756330000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000600000000000000000000000000000000000000000000000000000000000000006ed97aceba19c0000000000000000000000000000000000000000000000000000";
const decodedData = abiDecoder.decodeMethod(testData);

console.log(decodedData)

{ name: 'setData',
  params:
   [ { name: 'a', value: '1', type: 'uint256' },
     { name: 'b', value: '2', type: 'uint256' },
     { name: 'c', value: 'hell world', type: 'string' } ] }

실행결과를 보면 name엔 호출함수와 params엔 전달된 인자 정보를 볼 수 있습니다.

[ethereum] transaction을 보고 contract 생성을어떻게 할까

멍개. — Sat, 27 Aug 2022 16:26:35 +0900

smart contract에 대해서 알아보도록 하겠습니다.

간단하게 smart contract의 생성원리를 알아보겠습니다.

· 컨트랙트 배포 후 확인

transaction 정보를 보면 contract create라고 표시됩니다.

이더리움은 어떻게 contract 생성을 알고 contract create라고 표시하는지 알아보겠습니다.

· contract 배포직후 transaction 확인

이더리움에서 컨트랙트가 배포할 때 일반적인 transaction과 다르게 to를 비워서 보냅니다. 또한, Input Data를 컨트랙트를 작성한 코드를 컴파일한 결과를 포함하여 보냅니다.

해당 트랜잭션을 처리하는 노드는 to가 비어있고 Input Data가 있으면, contract 생성을 하게됩니다. 이때 Contract Address(CA)를 생성합니다. 이때 Input Data를 해당 컨트랙트에 저장을 합니다. 이렇게 생성된 계정을 To에 집어넣어 Transaction을 완성하게 됩니다.

[ethereum] transaction 발생 시 - Warning! Error encountered during contract execution [Out of gas] 에러

멍개. — Sat, 27 Aug 2022 16:25:05 +0900

이더리움에서 스마트 컨트랙트를 개발하다보면 상당히 다양한 에러를 접할 수 있습니다. 그중에 하나가 gas와 관련된 에러입니다.

● 정상 Transaction VS 비정상 Transaction

우선 정상적인 transaction과 비정상적으로 처리된 transaction을 비교해보겠습니다.

· 정상 Transaction

정상적인 transaction은 Success 상태가 됩니다.

· 비정상 Transaction

gas 문제로 발생된 트랜잭션 실패는 Out of gas라고 표기됩니다. 과연 이 문제가 왜 발생할까요??

적색으로 박스친 부분을 명심해야 합니다. Gas Used By Transaction(해당 트랜잭션을 실행하면서 소모한 가스)가 Gas Limit을 넘치면 앞의 에러처럼 발생합니다. 이때는 해결법이 매우매우 간단합니다.

· 해결방법

해결 방법은 gas limit(가스한도)를 올려서 트랜잭션을 발생하면 됩니다. 앞의 이미지는 metamask 기준이고 사용하는 지갑에서 gas limit(가스한도)를 더 높여주고 실행하면 됩니다.

참고로 gas limit이 21000은 이더전송을 의미합니다. 또한, gas는 ethereum에서 수수료를 지불하는 수단입니다.

[ethereum] solidity - address 관리방법(address, address payabl 타입)

멍개. — Sat, 27 Aug 2022 16:23:52 +0900

이번글에서는 solidity로 개발한 스마트 컨트랙트에서 다른 계정으로 이더를 전송하는 방법에 대해서 알아보겠습니다. 이번글도 0.5 버전을 기준으로 작성됩니다. 물론 이전 버전과 어떤 차이가 있는지도 함께 알아보겠습니다.

먼저, 컨트랙트에서 다른 계정으로 이더를 전송하기 위해서는 컨트랙트에서 이더를 보유하고 있어야 합니다. 즉, 다른 계정으로부터 이더를 전송받아야 하는데 전송 받는방법 부터 알아보겠습니다.

· 이더 전송받는 방법

pragma solidity ^0.5;

contract address05 {
    function () external payable{
        
    }
}

solidity에서는 이름이 없는 함수를 fallback 함수라고 하는데 fallback 함수에 external과 payable 옵션을 붙여주어 해당 컨트랙트가 외부 계정으로부터 돈을 입금받을 수 있도록 합니다. payable은 외부 계정으로부터 이더를 받으면 호출되는 함수입니다. 만약 payable 키워드가 존재하지 않는다면 해당 컨트랙트는 외부 계정으로부터 이더를 전송받지 못하게 됩니다.

추가적으로 external은 외부에서만 호출할 수 있는 함수를 의미합니다. 즉 해당 컨트랙트 내부에서는 해당 함수를 호출할 수 없음을 의미하고 있고 0.5 버전부터는 fallback 함수는 external을 강제하고 있습니다.

· 0.5에서 이더 전송방법

0.5부터는 이더를 전송하기 위해서는 address payable을 이용해야 합니다. 이전 버전에서는 address 타입에서 send와 transfer를 제공하여 바로 사용할 수 있었지만 0.5 버전부터는 address 타입도 address payable 타입으로 변환을 해야 정상적으로 전송이 가능해집니다.

// address payable to == address(uint160(to))

pragma solidity ^0.5;

contract address05 {
    function () external payable{
        
    }
    
    function oldSend(address to, uint value) public {
        to.send(value * (10 ** 18));
    }
    
    function newSend(address payable to, uint value) public {
        to.transfer(value * (10 ** 18));
    }
    
    function newSendTypeConvert1(address to, uint value) public {
        address payable convertedTo= address(uint160(to));
        convertedTo.send(value * (10 ** 18));
    }
    
    function newSendTypeConvert3(address to, uint value) public {
        address(uint160(to)).send(value * (10 ** 18));
    }
}

이전 버전처럼 사용하면 앞의 이미지처럼 에러가 발생하게 됩니다. address payable로 변환을 해야 정상적으로 컴파일이 됩니다.

address payable은 address(uint160())으로 변환해주면 됩니다. 또한 msg.sender로 가져오는 address도 address payable 타입입니다.

function giveBack() internal {
    msg.sender.transfer(msg.value);
}

msg.sender로 가져온 address는 address payable 타입이기 때문에 변환없이 transfer를 사용할 수 있습니다. 또한 msg.sender로 transfer 하기 위해서는 internal 형태의 함수이거나 payable 타입의 함수여야 합니다.

추가적으로 0.5 부터는 send가 아닌 transfer 사용을 권장하고 있습니다.

● 이더전송 테스트 해보기

// address payable to == address(uint160(to))

pragma solidity ^0.5;

contract address05 {
    function () external payable{}
    
    function newSend(address payable to, uint value) public {
        to.transfer(value * (10 ** 18));
    }
    
    function newSendTypeConvert1(address to, uint value) public {
        address payable convertedTo= address(uint160(to));
        convertedTo.send(value * (10 ** 18));
    }
    
    function newSendTypeConvert3(address to, uint value) public {
        address(uint160(to)).send(value * (10 ** 18));
    }
    
    function getBalance(address to) view public returns(uint) {
        return address(to).balance;
    }
    
    function giveBack() internal {
        msg.sender.transfer(msg.value);
    }
}

앞의 코드로 배포를 합니다.

※ 배포정보

배포 네트워크 : ropsten network
컨트랙트 배포 address(EOA) : 0x98e748f1d7b17e9f99210044a609cfbfe7604f0d
배포된 컨트랙트 address(CA): 0xbe649afefd32c806a4668d3fc0800d929a400f63

이더스캔을 통해서도 배포된 컨트랙트의 자세한 정보를 확인할 수 있습니다.

· 배포된 컨트랙트로 이더전송

5이더를 배포된 컨트랙트에 전송해줍니다.

배포한 컨트랙트에서 getBalance() 함수에 이더 보유를 확인할 컨트랙트 주소를 인자로 전달하여 호출하거나 이더스캔에서 확인을 할 수 있습니다. 참고로 이더리움은 decimals이 18이기 때문에 1000000000000000000 wei가 1ether가 됩니다.

· 컨트랙트에 있는 이더 외부계정에 전송

전송받을 계정 : 0x74537181C008e71BB3Fb6E4F4780f04A3470f551

현재 컨트랙트에 존재하는 이더리움중 일부를 해당 계정으로 전송해보겠습니다.

트랜잭션을 발생 시키고 해단 트랜잭션이 block에 포함될 때까지 기다린 후 이더스캔을 접속하여 확인하면 이더 전송이 된 것을 확인할 수 있습니다.

transaction의 경우는 지갑을 통해서 주고 받은 이더가 표시되고 컨트랙트 내부에서 전송이 발생된 경우는 internal Txns에서 몇 이더를 전송했는지 확인 가능합니다.

이더를 전송받은 계정또한 이더스캔에서 확인 가능합니다.

metamask 지갑에서도 확인 가능합니다.

0.5 버전에서는 이더를 전송하기 위해서는 address payable을 사용하여 전송하게 되는데 좀 더 신경써서 전송하라는 의미인 것 같습니다.

[ethereum] solidity - call, delegatecall

멍개. — Sat, 27 Aug 2022 16:18:46 +0900

solidity에서 call과 delegatecall에 대해서 다뤄보겠습니다.

우선 이번글은 solidity 0.5 버전 기준으로 합니다.

call과 delegatecall은 0.5 버전 전, 후로 사용법이 바뀌었습니다.

● 샘플코드

먼저, call과 delegatecall을 사용한 sample 코드부터 확인하겠습니다.

pragma solidity ^0.5;

contract Sample1 {

    uint public t ;

    constructor() public {
        
    }
    event L(uint a, uint b, address c);
    
    function test(uint a, uint b) public returns(uint){
        t = a + b;
        emit L(a, b, msg.sender);
        return a + b;
    }
}

contract Sample2 {
    uint public t;
    
    constructor() public {
        
    }
    
    function callTest(address contractAddr, uint to, uint value) public returns (bool, bytes memory, address) {
        (bool success, bytes memory data) = address(contractAddr).call(abi.encodeWithSignature("test(uint256,uint256)", to, value));
        
        if(!success) {
            revert();
        }
        
        //(uint a, uint[2] memory b, bytes memory c) = abi.decode(data, (uint, uint[2], bytes));

        return (success, data, contractAddr);
    }
    
    function delegatecallTest(address contractAddr, uint to, uint value) public returns (bool, bytes memory, address) {
        (bool success, bytes memory data) = address(contractAddr).delegatecall(abi.encodeWithSignature("test(uint256,uint256)", to, value));
        
        if(!success) {
            revert();
        }
        
        //(uint a, uint[2] memory b, bytes memory c) = abi.decode(data, (uint, uint[2], bytes));

        return (success, data, contractAddr);
    }
}

· 샘플코드 배포

샘플 코드를 보면 Sample1과 Sample2가 존재합니다. 각각 배포를 해줍니다. 순서는 상관없습니다.

remix를 이용하면 매우 편하게 배포가 가능합니다. 빠른 테스트를 위해 Javascript VM을 사용합니다.

우측 하단에서 배포된 컨트랙트를 확인할 수 있습니다.

· 배포정보 확인하기

앞의 사진에서 검정, 파랑, 빨강박스 순으로 트랜잭션 호출자, sample1 컨트랙트, sample2 컨트랙트 입니다.

트랜잭션 발생자(EOA): 0xca35b7d915458ef540ade6068dfe2f44e8fa733c
sample1 contract address(ca): 0x692a70d2e424a56d2c6c27aa97d1a86395877b3a
sample2 contract address(ca): 0xbbf289d846208c16edc8474705c748aff07732db

해당 정보는 테스트 할 때마다 다르게 배포됩니다.

· Sample1 컨트랙트 직접 호출

test 함수를 호출할 때 1과 2를 전달합니다. Sample1의 test()는 2개의 인자를 받아서 합하여 t에 저장합니다. 그리고 event를 호출하여 전달받은 2개의 인자와 해당 함수를 호출한 address를 인자로 전달합니다.

test() 호출 후 logs를 확인해보면

"args": {
    "a": "1",
    "b": "2",
    "c": "0xCA35b7d915458EF540aDe6068dFe2F44E8fa733c",
    "length": 3
}

전달한 값과 EOA 계정이 뜨는것을 확인할 수 있습니다.

그리고 t 변수값을 확인하면 2개의 값이 더해진 3이 저장된것을 확인할 수 있습니다.

● Sample2에서 call과 delegatecall 차이 확인

앞의 방법은 매우 일반적인 방법입니다. 이제 call과 delegatecall을 이용하여 어떤 형태로 동작하는지 알아보겠습니다.

먼저, call과 delegatecall은 일반적으로 사용자 계정이 호출하는 형태는 아니고 컨트랙트에 의해서 호출하도록 도와주는 기능입니다.

· call

call을 확인하기 위해서는 Sample2에 해보된 callTest()를 호출합니다.

callTest를 호출할 때 첫 번째 인자로 해당 컨트랙트가 호출할 컨트랙트 주소를 넣어줍니다. 그 이후의 인자는 호출할 컨트랙트가 전달받을 인자들입니다.

여기서는 Sample2가 Sample1의 컨트랙트에 있는 test()를 호출하게 됩니다.

"args": {
    "a": "4",
    "b": "5",
    "c": "0xbBF289D846208c16EDc8474705C748aff07732dB",
}

마찬가지로 logs 부분을 살쳐보면 a와 b는 callTest를 호출할 때 전달된 인자가 발생합니다. 그런데 c는 Sample2의 컨트랙트 주소가 표시됩니다. 그 이유는 Sample1로 배포된 컨트랙트를 Sample2가 호출했기 때문입니다.

EOA가 Sample2의 컨트랙트를 호출, Sample2는 Sample1 호출하는 구조가 됩니다. 그럼 t의 값을 확인해보겠습니다.

Sample1로 배포된 컨트랙트의 t값만 바뀌게 됩니다.

· delegatecall

delegatecall은 call이랑 다른 형태로 동작하게 됩니다.

이번에는 Sample2로 배포된 컨트랙트에서 delegatecallTest를 호출해보겠습니다. callTest와 똑같이 넣어줍니다. 첫 번째 인자는 Sample1로 배포된 컨트랙즈 주소 두 번째와 세 번째 인자는 Sample2에서 호출할 test 함수로 전달할 인자를 넣어줍니다.

이번에는 앞의 테스트와 차이점을 보기위해 다른 수치를 넣고 트랜잭션을 발생시켜 보겠습니다.

"args": {
    "a": "6",
    "b": "7",
    "c": "0xCA35b7d915458EF540aDe6068dFe2F44E8fa733c"
}

결과를 확인해보니 c가 Sample2의 컨트랙트가 아닌 Sample2를 호출한 EOA가 표시됩니다. 그리고 Sample1과 Sample2로 배포된 컨트랙트에서 t값을 확인해보겠습니다.

Sample1로 배포된 컨트랙트의 t가 아닌 Sample2로 배포된 컨트랙트의 t가 바뀝니다.

delegatecall을 하게되면 msg.sender와 msg.value가 유지됩니다.

그리고 context가 유지되게 됩니다. context 유지란 Sample2에서 Sample1을 delegatecall을 하게되면 Sample1 컨트랙트의 데이터를 수정하는것이 아닌 Sample2의 데이터를 수정하게 됩니다. 즉, 호출 당한 컨트랙트가 호출자 메모리 접근이 가능한 것을 의미합니다.

Sample1로 배포된 컨트랙트 test()에서 t = a + b를 할 때 call을 하게되면 Sample1에 있는 t에 접근하여 값을 변경을 하고 delegatecall을 하게되면 context가 Sample2가 유지 되기 때문에 Sample2로 배포된 컨트랙트에 있는 t의 값이 변경되게 됩니다.

● call과 delegatecall 0.5에서 변경된 사항

0.5 버전부터는 호출 성공/실패 유무와 반환된 데이터를 받아올 수 있습니다.

· 0.5 버전 이후

(bool success, bytes memory data) = address(contractAddr).delegatecall(abi.encodeWithSignature("test(uint256,uint256)", to, value));

· 0.5 버전 이전

bool success = address(contractAddr).call(bytes4(sha3("test(uint256,uint256)")), to, value);

개인적으로 solidity에서 가장 어려운 개념이지 않나 싶다.

[ethereum] keystore 파일에 대해서

멍개. — Sat, 27 Aug 2022 16:14:20 +0900

이더리움에서 account를 관리하는 방법은 여러가지 방법이 있습니다.

1. private key
2. keystore
3. mnemonic

실질적으로 우리는 private key만 있으면 되는데 private key가 노출되면 보안상에 매우 취약하므로 이를 대신해서 keystore(키스토어 파일) 또는 mnemonic(니모닉)의 형태로 대신 저장합니다.

이번글에서는 파일형태로 저장되는 keystoer 파일에 대해서 알아보겠습니다.

여기서 private key가 중요한 이유는 transaction을 발생시킬 때, transaction을 발생시키는 address의 private key로 서명을 해야하기 때문에 매우 중요.

● 구조

keystore 파일은 이름과 내용이 특정 패턴에 의해서 생성됩니다.

· 이름

keystore 파일의 이름은 생성 시간과 address를 포함하여 이름을 생성합니다.

UTC-{생성시간}-{address}

· 내용

파일 내용의 경우는 private key를 만들기 위해 암호화된 데이터들을 포함합니다.

{
   "id":"bf74fcc7-8027-2c9d-b5d4-d65451fdfa35",
   "version":3,
   "crypto":{
      "cipher":"aes-128-ctr",
      "cipherparams":{
         "iv":"059a40c98c81630c2bc9e0cd861d0a16"
      },
      "ciphertext":"05fb430f572da8d3072571d46784435fe58843919310efc083c0fb19431bf3a7",
      "kdf":"pbkdf2",
      "kdfparams":{
         "c":10240,
         "dklen":32,
         "prf":"hmac-sha256",
         "salt":"5dda813abd2b60ec414f89ecafeb50225e88ff858a4ead8652ef2eacd026be89"
      },
      "mac":"8bac7c1e8b98dc1fe37d73430266a6c96586b90dec757f7cd28064702c446536"
   },
   "address":"1c0e607bb9d657a7a4389a236b81a658a3f3b431",
   "name":"",
   "meta":"{}"
}

keystore 파일을 열어보면 앞의 내용처럼 나타나게 되는데 크게 id, version, crypto, address, name, meta 속성으로 이루어져 있습니다.

crypto 내부에 있는 정보에 대해서 자세히 알아보겠습니다.

● crypto 속성

crypto는 cipher, cipherparams, ciphertext, kdf, kdfparams, mac으로 이루어져 있습니다.

· cipher

chiper는 AES(대칭 키 알고리즘) => 사용된 알고리즘은 aes-128-ctr

· chipherparams

AES에서 필요한 매개변수. 여기서 iv는 "초기화 벡터" 입니다.

· chiphertext

AES(대칭 키 알고리즘)으로 암호화 시킬 데이터

· kdf

키를 유도하는데 사용하는 함수(해독하기 위해 필요한 값) => 키 유도 함수(key derivation function)

· kdfparams

kdf시 필요한 매개변수

· mac

암호를 확인하기 위해 사용되는 코드

keystore 파일은 private key를 단순한 형태로 저장하는 것이 아닌 password로 암호화 하여 저장하는 방법이며 입력한 비밀번호를 검증하는 내용을 포함한 파일입니다.

● 시나리오

· private key 생성

cipherparams와 aiphertext를 cipher에 정의된 알고리즘으로 암호화 합니다. 여기서 나온 결과는 암호화된 private key 입니다. keystore 파일은 private key를 암호화된 형태로 관리됩니다.

· 비밀번호로 보호

앞에서 private key를 암호화 된 형태로 관리하기 때문에 해독에 필요한 해독 키를 사용합니다. 참고로 여기서 해독을 해야하는 이유는 해독한 후 keystore 파일을 생성할 때 입력한 비밀번호화 해독된 데이터를 SHA3-256으로 해싱한 후 mac과 같으면 정상적인 비밀번호다라고 private key를 받을 수 있습니다.

kdf와 kdfparams를 이용하여 해독할 수 있는 키를 생성합니다.

여기서 해독된 결과를 주지않고 해독키만 반환하는 이유는 private key를 반환해버리면 keystore 파일만 가지고 해당 과정까지만 해서 private key가 노출되기 때문입니다.

· 검즘

kdf로 해독 키를 받아온 후 입력한 비밀번호화 SHA3-256 알고리즘으로 해싱을 한 후 같으면 정상적으로 private key로 서명할 준비가 됩니다.

[ethereum] block, transaction pool, state 각각 어디에 저장되는가

멍개. — Sat, 27 Aug 2022 16:09:57 +0900

thereum에서 block, transaction pool, state가 어디에 저장되는지 알아보도록 하겠습니다.

먼저 block, state는 levelDB를 통해 저장이 됩니다. 근데 문득 그렇다면 transaction이 발생되고 pool에 저장된 tx들은 어디에 저장되는지 궁금해져서 테스트를 해보았습니다.

· 2개의 account 생성

> eth.accounts
["0xe28674672b353d2d4c80435b610734e68bcd4362", "0xbd83f6767a57da0c25b1437660adf43c3e1667be"]

> eth.getBalance(eth.accounts[0])
75000000030000000000

> eth.getBalance(eth.accounts[1])
0

2개의 account를 생성한 후 transaction을 발생시킨 후 geth 프로그램을 종료했다가 다시 접속하여 tx pool을 확인해 보겠습니다.

· tx 발생하기 전 tx pool 확인

> eth.pendingTransactions
[]

tx를 발생시키지 않았기 때문에 비어있습니다.

· tx 발생

> personal.unlockAccount(eth.accounts[0], "p")
true

> eth.sendTransaction({from: eth.accounts[0], to: eth.accounts[1], value: 10000})
INFO [09-16|09:42:52] Submitted transaction                    fullhash=0x8360bedc21d02cd2c00e5dbc485949f6fee7cf3470e7bd94fe477d86c2152eff recipient=0xbd83f6767a57da0c25b1437660adf43c3e1667be
"0x8360bedc21d02cd2c00e5dbc485949f6fee7cf3470e7bd94fe477d86c2152eff"

geth에서는 account에 lock이 되있기 때문에 unlockAccount로 계정잠금을 풀어줘야 합니다.

· tx pool 확인

> eth.pendingTransactions
[{
    blockHash: null,
    blockNumber: null,
    from: "0xe28674672b353d2d4c80435b610734e68bcd4362",
    gas: 90000,
    gasPrice: 18000000000,
    hash: "0x8360bedc21d02cd2c00e5dbc485949f6fee7cf3470e7bd94fe477d86c2152eff",
    input: "0x",
    nonce: 0,
    r: "0x18e91ac9e352aa1353b31a4d544191e310a8fae75a1e8a63058a108a64c4f7b9",
    s: "0x55c4028befc7fdc02e0b3b0230f7873ea017effd37b5e1a0a0aba93a2619fe93",
    to: "0xbd83f6767a57da0c25b1437660adf43c3e1667be",
    transactionIndex: 0,
    v: "0x5cd84",
    value: 10000
}]

peding 중인 tx를 확인하니 방금 발생한 tx가 들어있습니다.

여기서 geth 프로그램을 종료한 후 pending을 확인하면 메모리에 저장되는지 db에 저장되는지 알 수 있습니다.

· geth 프로그램 종료

> exit
INFO [09-16|09:44:42] HTTP endpoint closed: http://0.0.0.0:8545
INFO [09-16|09:44:42] IPC endpoint closed: /Users/bagjeongtae/Desktop/geth_test/geth.ipc
INFO [09-16|09:44:42] Blockchain manager stopped
INFO [09-16|09:44:42] Stopping Ethereum protocol
INFO [09-16|09:44:42] Ethereum protocol stopped
INFO [09-16|09:44:42] Transaction pool stopped
INFO [09-16|09:44:42] Database closed                          database=/Users/bagjeongtae/Desktop/geth_test/geth/chaindata

· geth 프로그램 다시시작

$ vim start.sh
geth --networkid 1212121212 --maxpeers 3 --datadir $PWD --rpc --rpcport 8545 --rpcaddr "0.0.0.0" --rpccorsdomain "*" --rpcapi "admin,db,eth,debug,miner,net,shh,txpool,personal,web3" --port 30303 console

geth 시작명령어가 길기 때문에 매번치기 힘드므로 쉘 스크립트로 저장합니다. 머 물론 그냥 터미널에 복붙해도 됩니다.

$ ./start.sh
INFO [09-16|09:45:18] Starting peer-to-peer node               instance=Geth/v1.6.7-stable-ab5646c5/darwin-amd64/go1.9
INFO [09-16|09:45:18] Allocated cache and file handles         database=/Users/bagjeongtae/Desktop/geth_test/geth/chaindata cache=128 handles=1024
INFO [09-16|09:45:18] Initialised chain configuration          config="{ChainID: 190128 Homestead: 0 DAO: <nil> DAOSupport: false EIP150: <nil> EIP155: 0 EIP158: 0 Metropolis: <nil> Engine: unknown}"
INFO [09-16|09:45:18] Disk storage enabled for ethash caches   dir=/Users/bagjeongtae/Desktop/geth_test/geth/ethash count=3
INFO [09-16|09:45:18] Disk storage enabled for ethash DAGs     dir=/Users/bagjeongtae/.ethash                       count=2
INFO [09-16|09:45:18] Initialising Ethereum protocol           versions="[63 62]" network=1212121212
INFO [09-16|09:45:18] Loaded most recent local header          number=15 hash=8f3b47…271944 td=2103872
INFO [09-16|09:45:18] Loaded most recent local full block      number=15 hash=8f3b47…271944 td=2103872
INFO [09-16|09:45:18] Loaded most recent local fast block      number=15 hash=8f3b47…271944 td=2103872
WARN [09-16|09:45:18] Blockchain not empty, fast sync disabled
INFO [09-16|09:45:18] Starting P2P networking
INFO [09-16|09:45:20] Mapped network port                      proto=udp extport=30303 intport=30303 interface="UPNP IGDv2-IP1"
INFO [09-16|09:45:20] UDP listener up                          self=enode://d87594294e7e926cbc6de95361461550f5f7b726eeb93e7c609cb8bed0132296ef7f547c1f4284db1de8c3bc471688e0722d373aa882d0f43fdec427d5b4cc3c@121.161.16.47:30303
INFO [09-16|09:45:20] RLPx listener up                         self=enode://d87594294e7e926cbc6de95361461550f5f7b726eeb93e7c609cb8bed0132296ef7f547c1f4284db1de8c3bc471688e0722d373aa882d0f43fdec427d5b4cc3c@121.161.16.47:30303
INFO [09-16|09:45:20] IPC endpoint opened: /Users/bagjeongtae/Desktop/geth_test/geth.ipc
INFO [09-16|09:45:20] HTTP endpoint opened: http://0.0.0.0:8545
INFO [09-16|09:45:20] Mapped network port                      proto=tcp extport=30303 intport=30303 interface="UPNP IGDv2-IP1"
Welcome to the Geth JavaScript console!

instance: Geth/v1.6.7-stable-ab5646c5/darwin-amd64/go1.9
coinbase: 0xe28674672b353d2d4c80435b610734e68bcd4362
at block: 15 (Sun, 16 Sep 2018 09:34:51 KST)
 datadir: /Users/bagjeongtae/Desktop/geth_test
 modules: admin:1.0 debug:1.0 eth:1.0 miner:1.0 net:1.0 personal:1.0 rpc:1.0 txpool:1.0 web3:1.0

>

· tx pool 확인

> eth.pendingTransactions
[]

프로그램을 다시 시작하니 pending이 비어있습니다. 이것은 해당 데이터는 메모리에 저장된다는 의미입니다.

· tx pool 직접확인

> txpool
{
  content: {
    pending: {
      0xe28674672b353d2d4c80435b610734e68bcd4362: {
        0: {...}
      }
    },
    queued: {}
  },
  inspect: {
    pending: {
      0xe28674672b353d2d4c80435b610734e68bcd4362: {
        0: "0xbd83f6767a57da0c25b1437660adf43c3e1667be: 10000 wei + 90000 × 18000000000 gas"
      }
    },
    queued: {}
  },
  status: {
    pending: 1,
    queued: 0
  },
  getContent: function(callback),
  getInspect: function(callback),
  getStatus: function(callback)
}

txpool을 이용하면 좀 더 자세히 확인할 수 있습니다.

[ethereum] python으로 ethereum address 생성구현

멍개. — Sat, 27 Aug 2022 16:06:06 +0900

#!/usr/bin/env python2

# pip install ecdsa
# pip install pysha3

from ecdsa import SigningKey, SECP256k1
import sha3

def checksum_encode(addr_str): # Takes a hex (string) address as input
    keccak = sha3.keccak_256()
    out = ''
    addr = addr_str.lower().replace('0x', '')
    keccak.update(addr.encode('ascii'))
    hash_addr = keccak.hexdigest()
    for i, c in enumerate(addr):
        if int(hash_addr[i], 16) >= 8:
            out += c.upper()
        else:
            out += c
    return '0x' + out

keccak = sha3.keccak_256()

priv = SigningKey.generate(curve=SECP256k1)
pub = priv.get_verifying_key().to_string()

keccak.update(pub)
address = keccak.hexdigest()[24:]

print("Private key:", priv.to_string())
print("Public key: ", pub)
print("Address:    ", checksum_encode(address))

해당 코드는 python으로 ethereum address를 생성하는 코드입니다.
sha3이 python3에서 정상적으로 동작을 하지 않아 python2로 진행합니다.

ethereum에서 사용하는 address는 private -> public을 거쳐서 address를 생성하게 됩니다.

ECDSA는 타원곡선알고리즘 입니다.

우리가 address를 잊어버리더라도 private키를 알고있다면 address가 복구 가능한 이유가 이와같습니다. 또한 키스토어(keystore)파일로도 복구가 가능한데 keystore 파일은 private키를 생성해주는 파일입니다.