BlockChain - factory contract, DAO, modifier, checks-effects-interactions pattern, mutex

---

목차

1. factory contract

2. 스마트 컨트랙트의 DAO

3. checks-effects-interactions pattern

4. mutex 패턴

5. modifier (조건 논리 제어자)

---

 

 

 

 

 

1. factory contract

 

- 컨트랙트 배포하는 로직을 작성하는 컨트랙트
- 규칙이 있는 인스턴스 생성하는 패턴

import "./ERC721.sol"

contract Factory {
  function createContract (string memory _name, string memory _symbol) external {
    // ERC721 newNFT = ERC721(address) // 이미배포되어있는 인스턴스에 접근할때 사용한 방법
    ERC721 newNFT = new ERC721(_name, _symbol); // 새로운 컨트랙트 생성
    emit createEvent(newNFT, msg.sender); // 배포된컨트랙트 주소와 배포자를 알수있음
  }

  event createEvent(address _address, address _owner); // 이벤트로 log 확인가능함
}

- external 가스비 절약을 위해 제한자를 잘 사용하기!
- 솔리디티는 가스비절약이 목적이라 중복되는 코드와 복잡성을 줄이고, 재사용을 높여야함, 상태변수 접근 최소화

 

 

 

 

2. 스마트 컨트랙트의 DAO

 

- 분산 자율 조직(Decentralized Autonomous Organization)으로 탈중앙화 조직의 규칙 운영을 컨트랙트에 작성해서 관리
- 조직 멤버들의 투표로 의사결정
- 분산화, 투명성, 자율성, 저항성
- 블록에 기록된 내용은 누구나 조회, 검증 가능 (중앙집권제어X)
- 멤버들은 거버넌스에 참여할 권리로 토큰으로 증명 (토큰수에 따라 투표권을 가짐)
- 컨트랙트 규칙에 따라 제안을 시행하거나 (승인) 또는 거부 할수있음

 

 

2-1 DAO 진행

- 제안 → 멤버소집 → 제안(투표시스템) → 제안(유예) → 실행(다수결, 제안 실행)
- 표준이 정해져있지는 않음! 

 

 

2-2 Factory 컨트랙트 구현

- 제안하나가 컨트랙트로 구성되고
- 제안을 관리하는 factory 컨트랙트가 있고
- DAO 컨트랙트를 생성 및 관리하는 인스턴스가 되는것
 

2-3 컨트랙트 보안의 문제

- THEDAO
- 예측하지 못한 오류 발생함
- 재진입 공격해서 이더 탈취함 (상태변수가 변경되기전에 호출해버림)
   → 상태변수 코드는 위에 적으라고함

 

 

2-4 DAO의 숙제

- 탈중앙화 조직이라 자유도가 높아 법적으로 인정해주지않음
- 전문가의 도움을 받아야해(법률관련)
- 아직 발전중이라 미흡함

 

 

 

 

 

3. checks-effects-interactions pattern

 

- 순서에 맞게 코드를 작성하는 디자인 패턴(재귀호출 방지가능)
- 먼저 조건문으로 검증하고 컨트랙트 상태변경하고 외부 컨트랙트 호출하고
- 내부 컨트랙트 상태 업데이트 → 외부 컨트랙트 상태 업데이트 및 호출
  - transfer등의 메서드 사용할때 먼저 업데이트 하고 호출!

 

 

 

 

4. mutex 패턴

 

- 재진입 공격 방지를 위한 가드 추가
- 값에 따라 실행중이면 메서드 호출을 막아 방지하는것
- 저렴하고 간단한 bool값으로 사용

contract myBack {
  mapping(address => uint) balances;
  bool private lock;

  constructor(){
    lock = false;
  }

  // 출금
  function ethOut(uint _amount) payable {
    require(!lock); // 상태변수 확인
    // check
    require(balances[msg.sender] >= _amount);
    lock = true;
    // effect
    balances[msg.sender] -= _amount;
    // interaction
    address payable(msg.sender).trasfer(_amount);
    lock = false;
  }
}

 

 

 

 

5. modifier (조건 논리 제어자)

 

- 컨트랙트 가스비 절약을 위한 방법으로 새로운 문법!
- 조건문 재사용성을 높이는 방법

 

modifier onlyOwner() {
  require(msg.sender == owner);
  _; // 본문의 위치를 지정해줌   _mint(msg.sender, 10000 * (10**18));
}

function ownerMinting() public onlyOwner {
  _mint(msg.sender, 10000 * (10**18));
}


// 매개변수 사용할 경우
modifier onlyOwner(address _owner) {
  require(_owner == owner);
  _;
}

function ownerMinting(address sender) public onlyOwner(sender) {
  _mint(msg.sender, 10000 * (10**18));
}

 

- 메서드가 실행되면 조건문 검증하고, 반복되는 코드를 줄여줌

 

 

 

---

※ checks-effects-interactions pattern

※ mutex lock

※ remix를 사용해서 deploy