DApp 개발 완벽 마스터 : Solidity & React - 블록체인 개발

• DApp 개발 완벽 마스터 : Solidity \& React - 블록체인 개발
  • 배경지식
    • Fork에 대한 개념
    • 트랜잭션, 블록
    • Ethereum 가상 머신, 트랜잭션, 가스
    • 스토리지, 메모리와 스택, opcodes
    • 메시지 콜, 델리게이트 콜(콜코드)와 라이브러리
    • 로그, 생성, 비활성화와 자기 소멸

강의 링크 : https://www.udemy.com/course/complete-dapp-solidity-react/

목차 : Solidity 입문

배경지식

참고사항

• AWS 클라우드를 사용할때 인프라지식을 모르고도 사용 가능하다. 블록체인도 그렇다. 어느정도 감안하고 받아들이자.!

Fork에 대한 개념

Fork에는 하드포크, 소프트포크 2가지가 있다.

1.HardFork : 기존 네트워크의 규칙과 호환이 안된다.

• 하드포크가 발생하면 새로운 블록체인이 발생
• 이더리움 클래식과 이더리움이 있는 이유,
• 하드포크 발생하면, 강제적으로 소프트웨어 업데이트가 필요.

*DAO해킹사건

• 이더리움 DAO 스마트 컨트렉이 해킹되어 > 5천만 달러가 탈취, 이를 복구하고자 하드포크 결정
• 해킹된 네트워크는 이더리움 클래식이며, 해킹이 복구된 네트워크는 이더리움 이다.

2.SoftFork : 기존규칙과 호환되어 업데이트 한다.

1. Berlin Hard Fork (베를린 하드 포크)

• 활성화 시기: 2021년 4월
  • 여러 EIP(Ethereum Improvement Proposals)를 포함하여 가스 비용을 최적화하고, EIP-2565 (모듈러 거듭제곱 연산의 가스 비용 감소)

2. London Hard Fork (런던 하드 포크)

• 활성화 시기: 2021년 8월
  • EIP-1559: 거래 수수료 메커니즘을 개편하여 기본 수수료(Base Fee)를 도입하고 이를 소각하는 구조로 변경, 장기적으로 ETH의 공급량 감소 가능성을 제시.
  • EIP-3554: 이더리움 2.0으로의 전환을 준비하기 위해 난이도 폭탄(Difficulty Bomb)을 연기.

3. Paris Hard Fork (파리 하드 포크)

• 활성화 시기: 2022년 9월
  • 이더리움의 "The Merge"라는 역사적인 전환점으로, 이더리움 네트워크가 작업 증명(Proof of Work, PoW)에서 지분 증명(Proof of Stake, PoS)으로 전환됨.
  • 이 하드 포크는 에너지 소비를 크게 줄이고, 이더리움 네트워크의 보안과 확장성을 개선함.

4. Shanghai Hard Fork (상하이 하드 포크)

• 활성화 시기: 2023년 4월
  • 이더리움 2.0의 완성 단계로, PoS로의 전환을 완료한 후 첫 번째 주요 업데이트.
  • 주요 업데이트로는 스테이킹된 이더(ETH)를 인출할 수 있는 기능이 포함되었음.

5. Cancun Hard Fork (칸쿤 하드 포크)

• 예상 활성화 시기: 2024년 이후
  • 이더리움 네트워크에서의 데이터 가용성, 특히 이더리움 롤업을 위한 데이터 샤딩 기능을 포함하는 Proto-Danksharding 등의 업데이트가 예상됨.
  • 이 업그레이드는 네트워크 확장성을 대폭 향상시킬 것으로 기대됨.

트랜잭션, 블록

블록체인은 전세계적으로 공유되어 트랜잭션이 일어나는 데이터베이스

• 트랜잭션 : 추가 특징 : 참여자 동의, 원자성, 암호화

블록

• 이중 지불 공격 > POW 해결 (DB에서 동시성 제어 문제 > Lock )
• Ethereum은 약 17초마다 블록 생성
• 동시에 2개의 트랜잭션이 발생하면 첫번째가 우선 채택된다.

Ethereum 가상 머신, 트랜잭션, 가스

Ethereum 가상 머신

• 스마트 컨트랙을 위한 런타임 환경
• 격리된 환경 : 일반 네트워크, 파일 시스템, 기타 프로세스들에 대해 독립적
• 2가지의 계정 종류
  • 외부 계정 (EOA) : 공개키, 비밀키 쌍
  • 컨트랙트 계정 : 외부 계정이 접근해서, 코드를 호출 > 트랜젝션 유발 해주어야 함. Storage를 가진다.

트랜잭션

• EVM에서 트랜잭션은 한 계정에서 다른 계정(같을수도, null도 가능) 보내는 메시지다.
• 메시지에는 페이로드와 Ether가 포함.
• 컨트렉 생성 트랜잭션 : 페이로드에 바이트 코드가 포함, 트랜잭션은 새로운 컨트렉트의 주소 결정, 코드 영구 저장.
• *생성자 실행 전까지 컨트랙을 호출하면 안된다.
• *트랜잭션마다 고유의 논스가 존재한다. 배포자가 1씩 증가시키면서 컨트랙을 보낸다. 컨트랙 배포 따닥을 방지.

가스

• 가스를 지불해야 누군가가 트랜잭션을 처리해준다.
• 가스양은 정해져있다. 가스 가격은 정할 수 있다.
• 가스가 부족하면 예외 오류 발생.

스토리지, 메모리와 스택, opcodes

스토리지, 메모리와 스택

• EVM의 3가지 영역이 스토리지, 메모리, 스택 이다.
• 1.스토리지 : 영구적 데이터 보관 영역,
  • 256bit(32바이트) 문자가 key-value 형태로 연결된 저장소
  • 컨트랙마다 고유한 스토리지 존재, 서로의 영역은 침범이 불가능.
  • 스토리지 수정에 많은 비용이 든다.
• 2.메모리 : 각 메시지 콜(트랜젝션)에 대한 임시 데이터 저장소.
  • 메시지 끝나면 메모리의 데이터는 날라간다.
  • 쓰기 8-256 비트, 읽기 256비트로 한정.
  • 많은 공간을 쓰면 가스비 증가
• 3.EVM은 스택 머신
  • 스택의 한계 존재(최대 1024 요소), 요소 최대 크기 존재(256비트)
  • 레지스터 머신이 아니라 스택 머신, 최상단 16개 까지 접근 및 처리.
  • *애러 처리 : 스택에 상단에 에러 값이 추가
  • *복잡한 연산일수록 재귀호출보다 반복문이 선호

명령어 집합 ( opcodes )

• EVM 코드 > opcodes = 바이트 코드로 변환.
• 모든 명령은 합의 문제를 해결하기 위해, 최소 단위로 구성.

메시지 콜, 델리게이트 콜(콜코드)와 라이브러리

메시지 콜

• 컨트랙 간의 상호작용을 위함.
• 1.컨트랙트는 다른 컨트랙트를 호출
• 2.컨트랙트가 아닌 계정으로 Ether를 송금
• 메시지 콜은 송신자, 수신자, 데이터 페이로드, Ether, 가스와 리턴 값 등을 가지고 있어 트랜잭션과 유사
• 모든 트랜잭션은 상위 메시지 콜로 구성

델리게이트 콜

• 기본적으로 메시지 콜이지만, (msg.value, msg.sender 값이 유지되면서)
• 다른 컨트랙트의 함수를 내 컨트랙트의 컨텍스트 내에서 실행되는 콜이다.
• 목적 : 이것이 라이브러리 구현 원리 이다. = 다른 코드들을 내 컨트랙에 사용가능
• 과거에는 (콜코드) 라고 불렸다.

로그, 생성, 비활성화와 자기 소멸

로그

• 이벤트가 발생하면 로그가 남는다.
• 로그는 Block Level 까지 인덱싱된 데이터 구조를 저장 한다.
• 컨트랙트에서 로그를 만들고, 접근은 불가.
• 블록체인 바깥에서 효율적으로 접근 가능

생성 콜

• 컨트랙트들은 특별한 연산 부호를 사용하여 다른 컨트랙트들을 생성

비활성화와 자기 소멸

• 블록체인에서 코드가 지워지는 유일한 방법 : selfdestruct 연산을 사용했을 때
• ㄴ(delegatecall로도 가능, 하지만 블록체인의 히스토리에 남아있다)
• 제거된 컨트랙트에 Ether를 전송하면, 해당 Ether는 영구적으로 손실
• 여러분의 컨트랙트를 비활성화하려면, 내부상태를 바꿈으로써 disable 및 이더 반환 로직을 넣어야 함.