Smart Contract Standards
ERC-20
이더리움은 Wei라는 기본 단위를 사용한다. Ether의 최소 단위로 이해하면 된다. Wei와 Ether 사이에는 더 많은 단위가 존재하는데 10의 n승 단위로 증가한다.
- 10^18 wei = 1 ether (1 decimal 18승)
ERC-721
Non-Fungible Token (NFT)
ERC-20로 발행한 토큰과 달리 ERC-721 표준으로 발행한 토큰은 고유한 값(ID)을 가졌다.
효용성, 희귀도 등에 따라서 가치가 달라진다.
- 10^0 (1 decimal 1)
- ID 값 (1D-1, ID-2, ID-3)이 다르기 때문에 고유하다
토큰마다 고유하고 분할할 수 없는 특성 때문에 ERC-20와는 달리 decimals 필드가 없다.
ERC-1155
💡 Fungible vs Non-fungible
대체가능한 에셋은얼마나 가졌느냐가 중요하고, (돈, 토큰 등)
대체불가능한 에셋은무엇을 가졌느냐가 중요하다. (부동산, 그림 등)
게임에 주로 사용되는 표준!
고유한 아이템 n개를 발행하여, 개수만큼 보유하는 사용 사례도 있다.
ERC-721 토큰은 각 id 마다 balance의 개념이 없다. '존재한다'와 '존재하지 않는다'만 있다.
ERC-1155 토큰은 id 마다 balance가 있다.
Remix
msg.sender
- 함수를 실행하는 주체를 초기 발행자로 설정하는 코드
ex) 컨트랙트 오너, 화이트리스트 사용자, 스마트컨트랙트- 스마트컨트랙트를
msg.sender로 만드려면, 다른 컨트랙트를 임포트해서 실행하는 함수를 만들 경우 함수를 실행하면 해당 스마트컨트랙트가 주체가 된다 (지갑이 아닌 스마트컨트랙트)
- 스마트컨트랙트를
override
- 기존에 있는 함수를 변경할 때에는
override키워드를 추가해줘야 에러를 방지할 수 있다
Access Control
스마트 컨트랙트에서
Access Control이라는 개념이 상당히 중요하다.
컨트랙트의 액세스 컨트롤에 의해 토큰을 민팅하고, 제안서에 투표하고, 전송을 중단하는 등 권한이 부여된다. 시스템에 대한 완전한 제어권을 확보하려면, 이러한 개념을 잘 알고 사용하는 것이 필수적이다.
Access Control의 가장 기본적이고 일반적인 형태는 ownership이라는 개념이다. 컨트랙트의 소유자인 계정이 관리자 작업을 수행하게 된다. 관리자 한 명이 있는 컨트랙트에 적합하다. ownable 컨트랙트를 통해 지정된 소유자만이 관리할 수 있다.
ownable
- 기본적으로
ownable컨트랙트의 소유자는 해당 컨트랙트를 배포한 계정이다. - 사용하기 위해서는 아래와 같이 임포트를 해줘야한다.
import "@openzeppelin/contracts/access/Ownable.sol";
Libraries
Strings
-
String 기능을 수행하기 위해
Strings라이브러리가 필요하다. -
사용하기 위해서는 아래와 같이 임포트를 해줘야한다.
import "@openzeppelin/contracts/utils/Strings.sol";- toString(value)
- toStringSigned(value)
- toHexString(value)
- toHexString(value, length)
- toHexString(addr)
- equal(a,b)
IPFS
중앙 서버 없이 데이터를 관리할 수 있는 오픈 시스템
탈중앙화
기존 파일 시스템:
기존 파일 시스템은 일반적으로 중앙화된 형태로 서비스를 제공한다.
즉, 단일 서버나 중앙화된 서버 클러스터에 파일이 저장되었다.
파일에 접근하기 위해서는 이러한 중앙화된 서버와 통신해야 한다.
IPFS:
탈중앙화 프로토콜을 통해, 중앙화된 서버에 의존하지 않고 노드 기반의 P2P 네트워크에 걸쳐 파일이 분산된다. 네트워크의 각 노드는 파일 일부 또는 모든 파일의 복사본을 가지고 있어 중복과 향상된 가용성을 제공한다.
콘텐츠 주소 지정
기존 파일 시스템:
일반적으로 위치/파일경로에 따라 파일에 접근하게 되는데, 위치가 변경되거나 서버가 다운되는 경우에는 파일에 접근하기가 어려워진다.
IPFS:
콘텐츠 주소 지정(content addresing)을 통해 콘텐츠마다 고유한 암호학 해시를 할당한다. 이 해시는 주소로 사용된다. 즉, 파일의 콘텐츠가 주소를 결정하게 되어 위치나 네트워크 구조에 영향 받지 않게 된다.
캐시 및 속도
기존 파일 시스템:
퍼포먼스는 서버 로드, 네트워크 지연, 지리학적 거리 등 여러 요소의 영향을 받을 수 있다. 캐시 기법을 통해 속도를 개선하는데, 일반적으로 중앙화된 형태다.
IPFS:
분산형 캐시 시스템을 사용한다. 파일을 요청하면, 복사본을 가진 가장 근접한 노드로부터 fetch하여 지연을 감소시킨다. 같은 콘텐츠는 항상 동일한 주소를 갖게 되기 때문에 콘텐츠 주소 스토리지 또한 효율적인 캐시가 이루어지게끔 해준다.
버전관리 및 불변성
기존 파일 시스템:
전통적인 파일 시스템에서 버전관리 및 불변성은 내재된 특징이 아니다. 파일을 덮어쓰거나 변경하면 일반적으로 기존 버전을 교체하게 된다.
IPFS:
IPFS는 버전관리 및 불변성을 지향하도록 설계되었다. 파일이 변경되면 새로운 콘텐츠 기반 주소 해시가 생성되고 이전 버전 버전은 기존 해시가 접근할 수 있다. 파일 버전의 히스토리를 보존하도록 한다.
파일 불러오기
기존 파일 시스템:
중앙 서버의 가용성에 따라 파일을 불러올 수 있다. 서버가 다운되거나 접근할 수 없게 되면, 파일을 접근하기가 어려워진다.
IPFS:
IPFS는 분산형 네트워크의 특성을 활용한다. 파일은 다수의 노드로부터 받을 수 있어 가용성이 향상된다. 한 노드가 다운되어도 다른 노드로부터 필요한 콘텐츠를 받을 수 있다.
인센티브
기존 파일 시스템:
중앙화된 주체가 시스템을 운영하고 관리하며 사용자에게 스토리지 및 액세스에 대한 비용을 청구하는 형태다.
IPFS:
개방되고 탈중앙화된 형태로 설계되었다. 사용자가 저장공간, 대역폭을 네트워크에 기여하도록 장려하며, 자원을 제공한 대가로 Filecoin과 같은 인센티브를 보상으로 제공한다.
Typescript
npm install typescriptnpx tsc filename.ts-> js 파일이 생성된다node filename.js-> js 파일을 실행한다
