Primrose Docs
  • Home
    • ⛓️Blockchain
      • Avalanche
        • What is AVAX?
      • Ethereum
        • Ethereum Cancun Upgrade Explained(draft)
        • go-ethereum: gas estimate
        • Blockchain Transaction Lifecycle
        • Mempool
        • Gas optimization in Solidity, Ethereum
      • Solidity DeepDive
        • Meta transaction
        • solidity: patterns
        • UUPS vs Transparent
        • Solidity Interface
        • Smart contract storage
        • ERC-2981 Contract
        • Solidity modifier
        • Solidity delete keyword
        • How To Make NFTs with On-Chain Metadata - Hardhat and JavaScript
        • How to Build "Buy Me a Coffee" DeFi dapp
        • How to Develop an NFT Smart Contract (ERC 721) with Alchemy
        • Upgradeable Contract
        • Smart Contract Verification
      • Common
        • Eigenlayer
        • MultiSig(draft)
        • Chain-Based Proof-of- Stake, BFT-Style Proof-of-Stake
        • Byzantine Fault Tolerance
        • Zero-knowledge
        • Hierarchical Deterministic Wallet
        • Maker DAO
        • Defi
        • Uniswap
        • IBC
        • Cosmos
        • Gossip Protocol
        • Tendermint
        • UTXO vs Account
        • Blockchain Layer
        • Consensus Algorithm
        • How does mining work?
        • Immutable Ledger
        • SHA256 Hash
        • Filecoin
        • IPFS - InterPlanetary File System
        • IPFS와 파일코인
        • Livepeer
        • Layer 0
      • Bitcoin
        • BIP for HD Wallet
        • P2WPKH
        • Segwit vs Native Segwit
    • 📖Languages
      • Javascript/Typescript
        • Hoisting
        • This value in Javascript
        • Execution Context
        • About Javscript
        • tsconfig.json
        • Nest js Provider
        • 'return await promise' vs 'return promise'
      • Python
        • Pythonic
        • Python: Iterable, Iterator
        • Uvicorn & Gunicorn
        • WSGI, ASGI
        • Python docstring
        • Decorator in Python
        • Namespace in Python
        • Python Method
      • Go
        • GORM+MySQL Connection Pool
        • Context in golang
        • How to sign Ethereum EIP-1559 transactions using AWS KMS
        • Mongo DB in golang(draft)
        • Golang HTTP Package
        • Panic
        • Golang new/make
        • golang container package
        • errgroup in golang
        • Generic Programming in Golang
        • Goroutine(draft)
    • 📝Database
      • MongoDB in golang
      • Nested loop join, Hash join
      • DB Query plan
      • Index
      • Optimistic Lock Pessimistic Lock
    • 💻Computer Science
      • N+1 query in go
      • Web server 를 구성할 때 Thread, Process 개수를 어떻게 정할 것인가?
      • CAP
      • Socket programming
      • DNS, IP
      • URL, URI
      • TLS과 SSL
      • Caching(draft)
      • Building Microservices: Micro Service 5 Deploy Principle
      • Red Black Tree
      • AOP
      • Distributed Lock
      • VPC
      • Docker
      • All about Session and JWT
      • Closure
      • Singleton Pattern
      • TCP 3 way handshake & 4 way handshake
      • Race Condition
      • Process Address Space 
      • Call by value, Call by reference, Call by assignment
      • Zookeeper, ETCD
      • URL Shortening
      • Raft consensus
      • Sharding, Partitioning
    • 📒ETC
      • K8S SIGTERM
      • SQS
      • Git Branch Strategy: Ship / Show / Ask
      • Kafka
      • Redis Data Types
      • CI/CD
      • How does Google design APIs?
      • Minishell (42 cursus)
      • Coroutine & Subroutine
      • Redis
Powered by GitBook
On this page
  • Solidity patterns
  • Guard Check
  • State Machine
  • Access Restriction
  1. Home
  2. Blockchain
  3. Solidity DeepDive

solidity: patterns

Solidity patterns

솔리디티의 다양한 패턴에 대해서 다루어보려고 한다.

아래 링크를 참고해서 쓰여진 글이며, 본 글에서는 모든 내용을 담고 있지는 않다.

Guard Check

Guard를 통해 스마트 컨트랙트 및 해당 입력 매개변수의 유효성을 검증.

스마트 컨트랙트의 바람직한 동작은 필요한 모든 상황을 확인하고 모든 것이 의도한 대로인 경우에만 진행하는 것이다.

이를 Guard Check Pattern이라고 한다.

단순 require 문을 활용해도 좋고, modifier를 활용해도 좋다.

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

contract GuardCheck {
    modifier addressGuard(address addr) {
        require(addr != address(0), "address should be a valid address");

        _;
    }

    modifier valueGuard(uint value) {
        require(msg.value != 0, "msg.value should be a valid value");

        _;
    }

    function donate(
        address addr
    ) public payable addressGuard(addr) valueGuard(msg.value) {
        // ...
    }
}

State Machine

스마트 컨트랙트에서 서비스 로직을 구현하는 경우, 생애 주기를 관리해야 하는 경우가 있다.

시간에 따라서, 단계에 따라서 등 다양한 경우가 있을 수 있다.

다음과 같은 경우에 상태를 가지도록 구현할 수 있다.

  • 스마트 컨트랙트는 수명 주기동안 여러 단계로 전환해야한다.

  • 스마트 컨트랙트의 기능은 특정 단계에서만 접근 가능해야한다.

  • 사용자의 행동에 따라서 스마트 컨트랙트의 상태가 변경되어야 한다.

Solidity 에서는 다양한 단계를 모델링하기 위해 enum을 사용할 수 있다.

특정 단계에 대한 기능 액세스 제한은 뒤에서 다룰 Access Restriction을 활용하면 된다.

위에서 다룬 Guard Check 패턴과 관련이 있으나 중구난방으로 진행하면 정신없으니 일단 State Machine의 코드를 보고 넘어가보자.

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

contract StateMachine {
    // Stage에 대한 enum을 정의한다.
    enum Stages {
        AcceptingBlindBids,
        RevealBids,
        WinnerDetermined,
        Finished
    }

    Stages public stage = Stages.AcceptingBlindBids;

    uint public creationTime = now;

    modifier atStage(Stages _stage) {
        require(stage == _stage);
        _;
    }

    modifier transitionAfter() {
        _;
        nextStage();
    }

    modifier timedTransitions() {
        if (stage == Stages.AcceptingBlindBids && now >= creationTime + 6 days) {
            nextStage();
        }
        if (stage == Stages.RevealBids && now >= creationTime + 10 days) {
            nextStage();
        }
        _;
    }

    function bid() public payable timedTransitions atStage(Stages.AcceptingBlindBids) {
        // Implement biding here
    }

    function reveal() public timedTransitions atStage(Stages.RevealBids) {
        // Implement reveal of bids here
    }

    function claimGoods() public timedTransitions atStage(Stages.WinnerDetermined) transitionAfter {
        // Implement handling of goods here
    }

    function cleanup() public atStage(Stages.Finished) {
        // Implement cleanup of auction here
    }

    function nextStage() internal {
        stage = Stages(uint(stage) + 1);
    }
}

위의 예시는 Stage에 따라 컨트랙트 자체의 상태가 바뀐다.

Access Restriction

스마트 컨트랙트는 블록체인에 배포되면 누구나 접근할 수 있다.

공개적인 특성으로 인해 스마트 컨트랙트에 대한 완전한 정보 보호를 보장하는 것은 불가능에 가깝다.

모든 정보가 모두에게 표시되기때문에 누군가가 블록체인에서 컨트랙트 상태를 읽는 것을 막을수가 없다.

함수를 private으로 선언하는 선택지도 있지만, 그렇게 하면 모든 사람이 함수를 호출할 수 없게된다.

이런 경우, GuardCheck, StateMachine 패턴과 함께 사용하면 좋다.

private 은 smart contract의 인터페이스로 비공개한다.

컨트랙트 내부에서만 사용한다.

상속 받은 컨트랙트에서도 사용 불가능하다.

external은 smart contract의 인터페이스로 공개한다.

컨트랙트 내부에서 호출할 경우 this를 사용해서 접근해야 한다.

internal은 smart contract의 인터페이스로 비공개한다.

컨트랙트 내부에서만 사용한다.

상속 받은 컨트랙트에서도 사용 가능하다.

public은 smart contract의 인터페이스로 공개한다.

컨트랙트의 내부와 외부에서 모두 호출할 수 있다.

컨트랙트 내부에서 호출할 경우 this를 사용해서 접근해야 한다.

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

contract AccessRestriction {
    address public owner = msg.sender;
    uint public lastOwnerChange = now;

    modifier onlyBy(address _account) {
        require(msg.sender == _account);
        _;
    }

    modifier onlyAfter(uint _time) {
        require(now >= _time);
        _;
    }

    modifier costs(uint _amount) {
        require(msg.value >= _amount);
        _;
        if (msg.value > _amount) {
            msg.sender.transfer(msg.value - _amount);
        }
    }

    function changeOwner(address _newOwner) public onlyBy(owner) {
        owner = _newOwner;
    }

    function buyContract() public payable onlyAfter(lastOwnerChange + 4 weeks) costs(1 ether) {
        owner = msg.sender;
        lastOwnerChange = now;
    }
}

OpenZeppelin의 Ownable을 활용하면 더욱 간단하게 구현할 수 있다.

PreviousMeta transactionNextUUPS vs Transparent

Last updated 1 year ago

⛓️