이더리움 댑 개발 세미나 보조 교재인 Building Ethereum Dapps 번역서가 나왔습니다. 번역서가 나온 만큼 빠르게 읽기가 가능하기 때문에 세미나 중간 중간 이 책 읽기를 추가하도록 합니다.

1장이 시작되기 전까지 내용에서 특별히 언급할 내용은 없습니다. 빠르게 읽거나 건너 뜁니다.

1장. 처음 만나는 탈중앙화 앱

탈중앙화된 환경에서 실행되는 앱, 탈중앙화된 환경을 대표하는 것이 블록체인 네트워크입니다.

1.1.3까지는 그림 중심으로 보고 넘어갑니다.

OpenBazzars는 시간을 들여 살펴볼 만한 충분한 가치가 있는 댑입니다.

1.1.4 디앱 용어

아래 인용한 본문 내용을 주의 깊게 읽고 각각의 용어들의 의미를 분명히 합니다.

Smart contract
- A smart contract is an arrangement between two or more parties that involves an exchange of digital assets. One or more of these parties allocates digital assets to the contract at its initiation. Subsequently, the assets are redistributed among the parties according to a predefined protocol encoded in logic and a state that’s initialized at the start of the contract.
Autonomous agent
- An autonomous agent is a software entity that interacts autonomously with external software services and can reconfigure or even reprogram itself following verified changes in the external environment.
Decentralized organization
- A traditional centralized organization contains assets and different classes of individuals, typically investors, employees, and customers. Investors control the organization by owning a part of it through the purchase of shares. Interactions between some classes of individuals are influenced by whether they control the organization. For instance, employees can get recruited by investors or by other employees authorized directly or indirectly by investors.
- A decentralized organization (DO) isn’t controlled by any one person or entity. Predefined protocols are what determine interactions between classes of individuals involved in the organization. But such protocols can be designed so that certain individuals have more power than others—for instance, depending on the number of shares owned—exactly as with centralized organizations.
Decentralized autonomous organization
- A decentralized autonomous organization (DAO) is both a DO and an autonomous agent. Like an autonomous agent, it’s a software entity that interacts autonomously with external software services. Individuals involved with the DAO interact, as with DOs, through predefined protocols. The main difference between a DAO and a DO is that interactions between DAOs and external parties are largely automated, and the interaction protocols are programmed in a smart contract, whereas interactions between the individuals who own the DO and external parties are subject only to a manual protocol. The key point is that from the point of view of external parties, DAOs are more trustworthy than DOs because automated interactions are predictable, whereas interactions based on a manual protocol rely entirely on the reputation of the individuals following it. According to these definitions, opinions diverge as to whether blockchain platforms built with the main or only purpose of supporting a cryptocurrency can be classified as DAOs or DOs. Because the Bitcoin infrastructure doesn’t allow for implementation of easily automated interaction protocols, some think it should be classified as a DO.
Decentralized autonomous corporation
- A decentralized autonomous corporation (DAC) is a DAO that can be partially owned through a purchase of shares. As with classic (centralized) corporations, a DAC redistributes dividends periodically, depending on its financial success. A pure DAO, on the other hand, is generally a nonprofit organization, and participants benefit economically exclusively by contributing to its ecosystem and increasing its internal capital.

아래 인용한 본문 내용을 주의 깊게 읽고, 위에서 설명한 용어들과 Dapp의 관계를 설명할 수 있도록 합니다. 또한 아래 본문 내용과 같이 Dapp을 정의할 경우 Dapp이 추구하는 바가 무엇일지에 대해서도 고심해 보고 서로 논의해 봅니다.

The current widely accepted definition of decentralized application corresponds to that of DAO described previously, which is still in use among Ethereum purists. I’ll use this definition for Dapp for the rest of this book. The reason why the initial terminology used the word organization rather than application was because the Ethereum founders wanted to put emphasis on the fact that a decentralized application can transact with other parties exactly like conventional organizations: by following rules and protocols and exchanging monetary value, obviously in the form of cryptocurrency rather than conventional currency.

1.2 디앱 적용 사례들에 어떤 것들이 있는지 살펴봅니다.

개인적으로 저는 KYC-Chain에 관심이 많습니다.

1.3 5분 만에 디앱 구현하기

소스 코드가 뭘 하는 건지 간단히 살펴보고, 소스 코드를 보지 않고 아래 절차를 따라 구현을 해 봅니다.

리믹스를 실행합니다.
- https://remix.ethereum.org/
리믹스의 우측 상단에서 ‘Use previous version’ 버튼을 클릭합니다.
- 리믹스는 계속 업데이트 되고 있기 때문에 책 내용대로 진행하려면 이전 버전을 사용해야 합니다.
리믹스 좌측 상단 툴바에서 ‘+’ 버튼을 클릭해서 SimpleCoin.sol 파일을 추가합니다.
- 기본 생성된 파일들은 모두 삭제합니다.
리믹스 우측 상단에서 ‘Run’ 탭을 선택합니다. Environment를 ‘JavaScript VM’으로 설정합니다.
- 100이더씩 갖는 기본 계정 다섯 개를 제공합니다.
SimpleCoin 컨트랙트를 작성합니다.
- 솔리디티 컴파일러 버전은 0.4.0이상 0.5.0미만으로 합니다.
- 컨트랙트 생성 시 기본 제공 계정들 중 두 번째(0x147로 시작하는) 계정에 10000코인을 할당합니다.
- 코인을 전송할 수 있는 transfer 함수를 작성합니다. 외부에서 호출가능한 함수여야 합니다.
  - 누구에게(to) 얼마만큼의 양(amount)을 전송할지가 주어져야 합니다.
  - 이 함수가 실행되면 이 함수를 호출한 계정(msg.sender)은 amount만큼 잔고가 줄어야 하고, to 계정은 amount만큼 잔고가 늘어야 합니다.
    - 계정 별로 잔고가 얼마있는지(coinBalance)가 관리되어야 합니다.
      - 외부에서 계정별 잔고가 얼마인지 알 수 있어야 합니다. coinBalance는 외부에서 접근할 수 있어야 합니다.
컴파일 합니다.
- 리믹스 오른쪽 상단에서 ‘Compile’ 탭을 선택하고 컴파일러로 0.4.24+commit 버전을 선택합니다. Auto compile을 체크합니다.
  - 컴파일 결과에 경고가 뜹니다. 생성 시에 설정한 계정 주소가 검증 가능한 주소 형태가 아니라는 것입니다. 검증 가능한 주소에 대해서는 마스터링 이더리움에서 다루었습니다. 경고는 무시해도 되고, 경고를 없애고 싶으면 경고에 나온 주소를 복사해서 소스코드에 붙여넣습니다.
배포 합니다.
- 리믹스 오른쪽 상단에서 ‘Run’ 탭을 선택하고 ‘Deploy’ 버튼을 클릭합니다.
  - 하단에 Deployed Contracts가 나타납니다. 아래 컨트랙트 주소가 작성된 부분을 클릭합니다.
    - coinBalance 속성과 transfer 함수가 표시됩니다.
계정별 잔고를 확인합니다.
- coinBalance 부분을 확장합니다. 잔고를 알고 싶은 계정 주소를 계정 주소 목록에서 복사하고 큰따음표로 묶어 작성합니다. call 버튼을 클릭하면 잔고가 결과로 제공됩니다.
토큰을 전송합니다.
- 두 번째 계정 0x147로 시작하는 주소에서 세 번째 계정 0x4b0로 시작하는 주소로 150 코인을 전송합니다.
  - 현재 선택된 계정목록이 트랜잭션을 전송하는 계정이 되므로 전송을 실행하기 전에는 계정 목록에서 0x147로 시작하는 계정이 선택되어 있도록 해야 합니다.
  - transfer 부분을 확장합니다. to에 0x4b0로 시작하는 주소를 amount에 150을 작성합니다. 주소는 큰따음표로 묶어 작성합니다. transact 버튼을 클릭합니다.
    - to 주소를 복사했다면 위에서 설명한 것처럼 계정 목록을 트랜잭션 전송 주소로 바꾸어야 합니다.
전송 후 계정 별 잔고를 다시 확인해 봅니다.

2장. 블록체인 이해하기

2.1 디앱 자세히 살펴보기, 2.2 디앱에 사용되는 기술은 그림 중심으로 내용을 이해하고 넘어갑니다.

2.3 이더리움 역사와 거버넌스는 가볍게 읽고 넘어가거나 건너 뜁니다.

아래 인용한 본문 내용을 통해 3가지 동기화 모드 정도는 다시 한 번 살펴보고 넘어가도록 합니다.

Full
- Your client downloads the entire blockchain and validates all blocks locally. This is the slowest option, but you’d be confident of the integrity of the local blockchain copy.
- Fast
  - Your client downloads the entire blockchain, but validates only the 64 blocks prior to the start of the synchronization and the new ones.
- Light
  - Your client retrieves the current state trie of the blockchain from a peer full node and stores it locally. It doesn’t retrieve any historic blocks from peers, and it receives only the new ones, so you don’t have to wait long. This will allow you to get up and running
    quickly.

3장. 이더리움 플랫폼

3.1 이더리움 지갑으로 이더리움 플랫폼에 접속하기 – 이더리움 지갑은 UI가 있는 지갑 기능이 있는 클라이언트라고 생각하면 됩니다. 전문적인 댑 개발을 위해서 이더리움 지갑을 사용할 일은 없으니, 이런 것이 있구나 정도를 확인하고 넘어가도록 합니다.

3.2 디앱의 핵심 기능: 스마트 컨트랙트 – 그림 중심으로 읽어 나갑니다.

아래 요약한 내용을 읽어보고, 두 가지 메시지 유형 중 콜(calls)에 대해서 다시 한 번 확인하고 넘어갑니다.

콜
- 블록체인 상태를 변경하지 않는 읽기 전용 작업 수행
- 가스를 소비하지 않음
- 동기적으로 처리 됨, 반환 값을 즉시 돌려 줌

3.3 geth로 이더리움 네트워크에 접속, 3.4 geth 계정 관리

우리 세미나에서는 클라이언트로 parity를 사용하는 것을 추천함으로 이 부분은 빠르게 읽어 나갑니다.

3.5 심플코인 컨트랙트 다시 보기

심플 코인 컨트랙트를 개선합니다.

컨트랙트 생성 시 컨트랙트 생성 계정에 초기 공급량(initialSupply)만큼 코인을 할당합니다.
코인 전송 시 선행조건을 체크합니다.
- 보내는 계정 amount이상의 잔고를 가지고 있어야 합니다.
- 받는 계정 잔액에 amount를 더 했을 때 오버플로가 발생하지 않는지 확인해야 합니다.
토큰이 전송되면 전송 이벤트를 발생시킵니다.
- Transfer 이벤트를 선언합니다.
- transfer 함수에서 전송 처리 후 Transfer 이벤트를 발생(emit)시킵니다.