안녕하세요, 모두의 연구소 블록체인 연구실입니다.
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
Cheer Up! 음~? 흥미로운 포스팅이군요.