최초의 스마트 계약 언어로 제안된 Solidity는 블록체인 애플리케이션 시나리오를 위한 새로운 문을 열었습니다.

최초의 스마트 계약 언어로 제안된 Solidity는 블록체인 애플리케이션 시나리오를 위한 새로운 문을 열었습니다.

-- 기원--

스마트 계약이라는 용어는 1994년 학제 간 법학자인 Nick Szabo가 처음 제안했습니다. 스마트 계약에 대한 그의 정의는 다음과 같습니다.

"스마트 계약은 계약 당사자가 이러한 약속을 시행할 수 있는 계약을 포함하여 디지털로 정의된 일련의 약속입니다."

간단히 말해서 Nick Szabo는 스마트 계약을 일련의 약속으로 봅니다. 소위 약정은 참여자들이 합의한 상호 권리와 의무를 의미합니다. 따라서 스마트 계약의 본질과 목적은 약속 그 자체입니다. 예를 들어 단순한 매매 이벤트에서 판매자는 공급을 약속하고 구매자는 지불을 약속하면 이 두 가지 약속이 스마트 컨트랙트를 형성할 수 있습니다. 스마트 계약에 대한 Nick Szabo의 정의에 언급된 키워드인 디지털 형식 및 합의에 주목하십시오. 이 두 키워드는 스마트 계약이 전통적인 의미의 약속과 다르며 형식과 기능에 결정적인 특성을 가지고 있음을 결정합니다.

"스마트 계약"은 이더리움에 의해 블록체인에 처음 도입되었습니다. Ethereum 백서에 따르면 스마트 계약의 도입은 주로 다음과 같은 문제를 해결하기 위한 것입니다.

스크립팅 언어의 경우 스크립트가 Turing-complete(추후 소개)가 아니며 타원 곡선 서명 알고리즘과 같은 복잡한 기능을 구현하기 어렵습니다.

스크립트는 인출할 수 있는 금액을 세밀하게 제어할 수 없습니다.

스크립트는 상태 보존이 부족하고 더 복잡한 상태 저장 계약을 구현할 수 없습니다.

실행 중에 얻을 수 있는 데이터는 난수, 타임스탬프 및 이전 블록 해시 획득과 같이 충분히 풍부하지 않습니다.

요컨대 스크립팅 언어는 더 풍부한 애플리케이션 운영을 만족시킬 수 없기 때문에 이더리움은 고유한 스마트 계약 언어 Solidity를 설계했으며 동시에 스마트 계약을 실행하기 위한 스마트 계약 실행 엔진 EVM도 탄생했습니다.

그 이후로 블록체인 기술의 적용 시나리오는 단일 UTXO 기반 디지털 통화 거래에서 Turing의 완전한 일반 컴퓨팅 분야로 확장되었습니다. 사용자는 더 이상 비트코인 ​​스크립트가 지원하는 단순한 논리에 국한되지 않고, 복잡한 계약 논리를 스스로 설계할 수 있습니다.

-- 개요--

Ethereum 디자인 스마트 계약에는 다음과 같은 디자인 기능이 있습니다.

▲ 실행의 확실성

결정성(Determinism)은 프로그램이 실행되는 시기와 장소에 관계없이, 실행 횟수에 관계없이 주어진 입력에 대해 동일한 출력을 갖는다는 것을 의미합니다. 블록체인은 동일한 원장을 유지하므로 스마트 계약 실행의 확실성은 동일한 계약을 실행하는 서로 다른 노드가 동일한 결과를 가져야 하는 것으로 이해할 수 있습니다.

이더리움 스마트 계약 언어는 충분히 간단하게 설계되었습니다.실행의 확실성을 보장하기 위해 난수 및 불확실한 (시스템) 호출과 같은 기능을 구현하지 않습니다.동시에 스마트 계약의 실행은 제한된 환경의 가상 머신 이러한 방식으로 결과의 확실성을 하위 계층에서 보장할 수 있습니다.

▲ 튜링 완전성

튜링의 완전한 언어, 더 공식적으로 설명하면 무한 루프를 포함하여 "알고리즘으로 계산할 수 있는 모든 문제를 계산할 수 있는" 언어입니다. Ethereum에 스마트 계약을 도입하는 목적은 Turing 완전성을 달성하여 더 풍부한 응용 프로그램 형식을 지원하는 것입니다.

튜링 완전성을 도입한 후 해결해야 할 한 가지 문제는 중지 문제입니다. 일반적으로 주어진 프로그램이 중지할지 여부를 알 수 있는 방법이 없습니다.

Turing의 완전성으로 인한 다운타임 문제를 피하기 위해 Ethereum은 Gas 메커니즘을 도입하여 관련 실행 프로세스에 대한 비용 계산을 수행합니다. 다양한 작업의 비용을 가스 단위로 계산하고(각 작업은 특정 가스 소비에 해당합니다. 즉, 해당 가스 소비 테이블이 있음) 각 실행에 대한 가스 소비의 상한을 설정합니다. 즉, gasLimit, 계약 실행의 누적 작업 gasLimit 상한선 이후 실행이 강제로 중지되어 종료 효과를 얻습니다. Gas 메커니즘의 도입으로 사용자가 응용 프로그램을 사용하는 복잡성은 플랫폼의 물리적 제한이 아니라 사용자가 기꺼이 지불하려는 가격에 따라 달라집니다.

물론 가스 메커니즘의 도입에는 다른 이점도 있지만 여기서는 소개하지 않겠습니다.

▲ 보안

이더리움의 설계 전제로서 보안은 스마트 계약이 보장해야 하는 것이기도 합니다. Ethereum 스마트 계약의 보안은 주로 디자인의 두 가지 측면에 반영됩니다.

1) 비교적 간단한 스마트 컨트랙트 언어

주류 Turing-complete 언어와 비교할 때 Solidity 언어는 블록체인 시나리오에 중점을 두므로 멀티 스레딩 및 시스템 호출과 같은 많은 언어 기능을 구현할 필요가 없으므로 설계가 최대한 간단합니다. 그러나 이 또한 언어의 점진적인 발전과 함께 그 기능이 지속적으로 증가하고 개선되고 있음에도 불구하고 초기에 사용하기 어려웠던 이유 중 하나이기도 합니다.

2) 스마트 계약의 실행 환경은 충분히 격리되어 있습니다.

이더리움 스마트 계약은 이더리움 가상 머신(EVM)에서 실행됩니다. EVM에서의 실행은 샌드박스일 뿐만 아니라 실제로 완전히 격리되어 EVM에서 실행되는 코드는 네트워크, 파일 시스템 또는 기타 프로세스에 액세스할 수 없습니다. 스마트 계약조차도 다른 스마트 계약에 대한 액세스가 제한됩니다. 제어 가능한 보안은 작업의 격리를 통해 대부분 보장됩니다.

—— 자세한 설명——

다음으로 Solidity 계약의 실행 엔진인 EVM에 대해 살펴보겠습니다.

텍스트

EVM은 1바이트를 명령으로 사용하는 스택 가상 머신으로 정의됩니다. 스택 가상머신의 특징은 연산을 수행할 때 피연산자 스택(operand stack)과의 상호작용에 의존한다는 점이다.

Solidity 계약 소스 코드는 낮은 수준의 스택 기반 바이트 코드를 사용하도록 컴파일되므로 실제로 Ethereum에 배포하고 EVM에서 실행하는 것은 실제로 바이트 코드 문자열입니다. 코드는 일련의 바이트로 구성되며 각 바이트는 작업을 나타냅니다. 바이트코드가 실행되면 바이트코드의 연산 의미에 따라 첫 번째 바이트코드부터 코드 끝에 도달하거나 오류가 발생할 때까지(예: REVERT, STOP 또는 RETURN opcode 발생) 순차적으로 실행됩니다. 이러한 작업은 데이터를 저장하기 위해 세 가지 유형의 공간에 액세스할 수 있습니다.

스택: 값을 푸시하고 팝할 수 있는 LIFO 컨테이너.

메모리: 무한 확장 가능한 바이트 배열

저장소: 키/값 쌍으로 저장되는 계약의 장기 저장소입니다. 계산 후 리셋되는 스택과 메모리와 달리 스토리지는 오랫동안 존재하게 되며, 이 부분도 흔히 말하는 "월드 스테이트"의 일부입니다.

스마트 컨트랙트의 실행 과정은 실제로 opcode에 의해 정의된 행위에 따른 3가지 유형의 저장 공간이 작동하는 과정인데, 다음 예를 통해 간략히 보여드리겠습니다.

다음 그림은 일부 계약 조각을 보여줍니다. 왼쪽은 계약 바이트 코드이고 오른쪽은 바이트 코드로 표현되는 작업 의미입니다.

각 opcode의 간단한 의미는 다음과 같습니다.

PUSH1: 바이트코드 16진수는 60이며, 작업의 의미는 다음 바이트를 스택으로 푸시하는 것입니다.

ADD: 바이트코드 16진수는 01, 작업의 의미는 스택에 두 개의 요소를 팝하고 추가한 다음 결과를 다시 스택에 넣는 것입니다.

MSTORE: 바이트 코드 16진수는 52, 연산의 의미는 스택에서 팝된 두 번째 값을 메모리에 저장하고 저장된 인덱스 값은 스택에서 팝된 첫 번째 요소입니다.

RET: 바이트코드 16진수는 f3, 작업의 의미는 실행 종료, 결과 반환, 결과는 메모리에 있음, 시작 인덱스는 스택에서 팝된 첫 번째 값, 길이는 스택에서 팝된 두 번째 값 스택

이 바이트코드를 실행을 위해 EVM에 넣고 실행 과정은 다음과 같습니다.

그 중 PC는 현재 실행 연산 코드의 위치를 ​​나타내며 컨트랙트 프래그먼트(즉, RET 연산 코드) 실행이 끝나면 메모리에서 60부터 5바이트의 데이터를 빼게 된다. 계약 조각의 실행이 완료되고 최종 결과가 호출자에게 반환됩니다!

주의깊은 학생들은 그림에서 해당 명령어가 Storage와 관련된 연산을 가지고 있지 않다는 것을 알 수 있을 것입니다. .

"그래서 왜 EVM을 이렇게 설계한 거지? 왜 이런 스택의 진입과 퇴출, 메모리 복사, 메모리의 연산을 통해 계산 문제를 풀고 컨트랙트 상태의 획득과 수정을 완료할 수 있을까? 보관?"

여기에는 프로그래밍 언어의 설계가 포함됩니다. 이론적으로 컴퓨팅의 이론적 시스템에서 명령어 세트 아키텍처는 컴퓨터의 추상 모델이며 명령어 세트에 포함된 명령어 유형의 풍부함은 프로그램 표현의 풍부함에 직접적인 영향을 미칩니다. 예를 들어, 명령어 세트는 덧셈, 뺄셈, 곱셈 및 나눗셈과 같은 산술 및 논리 연산 명령어, 점프와 같은 제어 명령어 및 읽기 메모리와 같은 데이터 처리 명령어를 포함할 수 있다. 가상 머신으로서 원하는 기능을 표현하기 위한 명령어 세트를 구축하기 위해 필요에 따라 명령어를 선택하거나 추가할 수 있습니다. 예를 들어 EVM은 부동 소수점 숫자와 관련된 연산에 대해 스토리지 관련 명령어를 추가하지 않으므로 Solidity 언어가 부동 소수점 숫자 연산을 지원하지 않는다는 명령어 수준에서 설명됩니다. 명령이 결정된 후 현대 프로그래밍의 일부 도구를 사용하여 특정 언어를 설계할 수 있습니다. 따라서 어느 정도는 필요에 따라 자체 언어와 해당 실행 엔진을 구현할 수도 있습니다.

-- 개발하다--

EVM의 본질은 우리가 블록체인 원장이라고 부르는 프로그래밍 가능한 언어를 통해 "세계 상태"를 운영하는 것입니다.

지속적인 개발로 업계에는 많은 스마트 계약 실행 엔진이 있으며 새로운 탐색이 부족하지 않습니다.

EVM: Ethereum EVM과 호환되며 성능에 최적화되고 기능이 풍부합니다.

HVM: FunChain은 Java 언어로 스마트 계약 작성을 지원하는 효율적이고 사용하기 쉬우며 완전한 스마트 계약 실행 엔진을 개척했습니다.

FVM: Rust 및 기타 언어로 스마트 계약 작성을 지원하는 안전하고 다양하며 효율적인 스마트 계약 실행 엔진

이 글은 스마트 컨트랙트의 기원과 이더리움 스마트 컨트랙트를 소개하는 [Virtual Machine] 칼럼의 시작이며, 다음 연재에서는 다른 실행 엔진에 대해 자세히 소개할 예정이니 많은 관심 부탁드립니다!

저자 소개

저자 소개

텍스트

참조

참조

[1] 스마트 계약 바이두 백과사전

[2] 이더리움 백서