안녕하세요, 모두의 연구소 블록체인 연구실입니다.

10월 27일 4회차 스터디에서 진행한 Introducing Ethereum and Solidity의 4장 요약본입니다.

4장 솔리디티 언어

문제 제기

스마트폰으로 문자를 보내는 건 너무나 쉬운데,
스마트폰으로 돈을 보내는 건 너무나 어렵다?
휴양지 시나리오: 환전 안하고 신용카드만 들고 왔는데, 가판대 직원이 카드 리더기가 없음. 스마트폰만 있음.

컴퓨터 환경

무한 루프가 기본이며, 세 가지 종류의 작업 공간에서 작업이 수행됨
스택(stack): 값을 추가하거나 제거할 수 있는 일종의 컨테이너 자료형. 스택에 값을 추가하는 동작을 푸시(push), 꺼내는 동작을 팝(pop).
동적 메모리(dynamic memory)는 힙(heap)이라는 이름으로도 불리우며, 무한히 확장 가능한 바이트 배열을 말한다. 동적 메모리는 프로그램이 끝나면 리셋
키/값 저장소(key/value store): 계정 잔고를 보관하며, 스마트 계약 계정의 경우 솔리디티 코드도 보관

대안 화폐

범용 암호화폐라는 개념은 궁극적으로 지구상의 모든 인간이 휴대전화에 암호화폐 지갑을 내려받고 사용한다고 가정.
이러한 몽상은 이더리움의 로드맵과는 무관.
대신 이더리움 핵심 개발팀은 제 3자가 특별한 목적으로 브랜딩하여 사용할 수 있는 대안 화폐(complementary currencies), 또는 맞춤형 토큰(custom token)을 쉽게 만들 수 있게 하는 방식을 채택
신용카드 포인트가 이 용도에 부합한다.
이러한 제 3자(기존 기업, 스타트업, 지방 자치 단체, 대학 또는 비정부 기구)는 퍼블릭 체인 또는 대규모 허가형 체인을 통해 다양한 유형의 토큰을 사용할 수 있으며, 이는 진짜 글로벌 은행 시스템이 다양한 통화를 처리하는 방식과 유사함.

대안화폐의 필요성

소규모 공동체 내에서 지역 경제 발전을 촉진
소규모 공동체에 사회적 자본 구축
지속 가능한 생활 양식의 양성
주류 화폐가 충족시키지 못하는 수요를 충족
솔리디티 프로그래밍을 사용하면 누구나 간단한 토큰 계약 작성을 통해 대안 화폐를 만들 수 있다!

다양한 EVM용 언어

Solidity
Serpent(Python-alike)
LLL(Lisp-alike)
Mutan(지원 중단)

EVM 프로그래밍 학습에 대하여

개발자가 아니라도 쫄지 말자. 나쁜 습관이 없는 게 더 유리함. (???)
이더리움에서는 일반 웹 애플리케이션을 배포하고 확장하는 번거로움이 거의 없음. Dapp이라고도 불리우는 분산 애플리케이션의 백엔드에 필요한 모든 스마트 계약은 몇 가지 문서로 깔끔하게 묶어서 EVM으로 전송할 수 있으며 곧바로 글로벌하게 실행 가능.
웹 브라우저를 통해 접근할 수 있는 ‘하이브리드’ 이더리움 dapp을 개발하는 사례도 있음. 이더 지불을 추가하는 작업은 그리 많은 손을 필요로 하지 않음
그래도 이더리움 완성 전에는 이더리움 프로콜만으로 호스팅하는게 편하다.

솔리디티 특징

정적 자료형 언어이며, 상속, 라이브러리 및 복잡한 사용자 정의 자료형을 지원
어셈블리 코드를 인라인으로 작성할 수 있음
반복문 구현이 자바스크립트/C와 거의 동일. for (i = 0; i < 10; i++) {...}
High-level 언어이며 형식검증(formal verification)이 용이함

형식검증의 필요성

‘누군가가 무한 루프를 작성해서 기계를 마비시키는 것을 어떻게 막을 수 있을까?’
공유지의 비극(tragedy of the commons), 도덕적 해이에 대한 대비
라이스의 정리(Rice’s theorem)에 따르면, 어떤 컴퓨터 프로그램의 행동 특성은 수학적으로 결정 불가능한 것이 때문에 솔리디티 코드가 종료될 것임을 분명히 예측할 수 있는 또 다른 컴퓨터 프로그램을 작성할 수는 없음.
EVM은 블록당 계산 단계 수, 결정론적 언어 및 가스 비용에 대한 엄격한 제한을 포함하여 다양한 방식으로 이러한 현실적 위험 요소를 극복. 그럼에도 불구하고 경제적 인센티브가 있기 때문에 공격자는 항상 방법을 모색할 것.

튜링 완전이 아니었어?

실세계에서 공용 시스템을 설계할 때 튜링 완전은 환상에 불과
솔리디티 스마트 계약 실행이 가지는 제한적인 성격은 EVM이 실행할 프로그램의 동작을 이론적으로 예측할 수 있기 때문에, 실질적으로 EVM은 튜링 완전성을 가지지 않는다?
고수준 코드는 형식 검증이 가능하지만, 컴파일 이후의 바이트코드는 사실상 검증이 불가능
결국 유일한 답은 무한한 테스트
Ropsten 테스트넷: 수도꼭지를 틀면 이더가 나온다

실습 방법

준비물 1: 텍스트 편집기
준비물 2: 미스트 지갑
준비물 3: 브라우저 솔리디티 컴파일러(https://ethereum. github.io/browser-solidity/ )
텍스트 편집기에 작성한 솔리디티 코드를 브라우저형 솔리디티 컴파일러에 복붙
컴파일러에서 코드를 바이트코드로 컴파일하고, 해당 바이트코드를 미스트에 복붙
배포

퍼블릭/프라이빗 함수 - 기존 객체지향의 클래스 대신 계정으로 대체되었다고 보면 됨

public: 외부 및 내부 계정에서 볼 수 있다(저장 및 상태 변수에 대한 접근자 함수가 만들어짐).
private: 현재의 계약 계정에서만 볼 수 있다(기본값).

기본 변수형 - 모두 256비트

불리언
부호 있는 정수 및 부호 없는 정수
주소(20바이트)
동적 바이트 배열
부동 소수점 수
유리수 및 정수 리터럴
문자열 리터럴
16진수 리터럴
열거형

복합 자료형 - 256비트보다 크기 때문에 가스 비용 커질 수 있음

배열
배열 리터럴/인라인 배열
구조체
맵핑

감사합니다.

https://drive.google.com/open?id=1Vm-3jw2VAKJNQDjppBmhPZhb5_nthChDPbz-Ws7TKJo

[모두의 연구소] Introducing Ethereum and Solidity 4장 요약본 | Ecency