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

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