컨센서스 실행 계약이란 블록체인 분야에 자주 부른 스마트 계약이다. 그런데 VDS 고안 팀이 지금까지 이 계약 프로그래밍의 기술이 얼마나 스마트하지 않고 그냥 한 탈 중앙화 분산형 네트워크에 코드를 편찬을 통해 이루어진 합의 행위에 대한 예정 프로그램이어서 이 단어가 너무 마케팅 성질이 있다고 생각한다. 그래서 실사구시의 과학적인 연구 정신으로 이 스마트 계약을 컨센서스 실행 계약으로 부르면 더욱 정당한 것 같다. 이를 통해 탈 중앙화 합의 협의의 본질을 표현할 뿐만 아니라 인류가 미래에 블록체인 기술이 AI스마트 기술과 결합할 때 명사 설명이 어려운 것을 극복할 수 있다.
건센서스 실행 계약이란 여러 분야에서 사용할 수 있고 예를 들면 금용 분야, 교육 분야, 행정체계, 사물 인터넷, 인터넷 쇼 비즈니스 등 분야에서 블록 체인 기술을 통해 한 정한 분산형 네트워크에서 예정 코드 편찬한 방법을 통해 한 제3반이 필요가 없는 협의에 참여한 쌍방 혹은 다방이 합의한 행동을 실행한다는 스크립트이다. 이 것이 계약에 참여한 모든 사람들에 속한 권익을 안전,확실이,공평하게 실행할 수 있다.
컨센서스 실행 계약이 블록 체인 분야의 발전에 대해 응용을 빠른 속도로 실시한 역할을 담당하고 있다. 그리고 이를 통해 고안자들을 더욱 자극적으로 이 데에 참여하게 자극할 수 있다. 그리고 블록 체인 기술에 의한 현실적인 제품 체험을 역사적으로 제고하게 된다. 이 모든 것이 다 이더리운 고안 팀이 탁월한 공헌으로 부터 시작하고 이 전체 분야를 위해 새 국면을 열렸다.
이더리움 가상 컴퓨터(EVM)이 한 256 비트 길이의 머신 코드를 사용하고 스택에 의해 한 가상 컴퓨터이다. 이를 통해 이더리움의 컨센서스 실행 계약으로 실시하는 것이다. EVM가 이더리움을 위해 디자인한 것이어서 이더리움 계좌 모델(Account Model)을 사용하고 가치를 전송하는 것이다. 그러데 VDS의 디자인은 비트 코인UTXO 모델에 근거하고 디자인하는 것이다. 이런 디자인으로 사용한 이유는 한 방면은 VDS에 있는 공명 거래 기능 즉 비트 코인을 VDS체인으로 한 방향으로 코인을 교환한 기능을 실현하기위해 그래서 한 개인 키를 통해 비트코인과 VDS가 두 가지 주소를 이루어질 수 있다.
단른 이유는 VDS의 고안 팀이 비트 코인의 저층 거래 구조가 10년 간에 시련을 겪어서 더욱 튼튼하고 믿을 만하다고 생각합니다.그래서 VDS가 계좌 추상화 계층(Account Abstraction Layer)을 사용하고 UTXO모델을 EVM에 의해 실행한 계좌 모델로 변한다. 그리고 VDS가 계좌 모델에 근거한 인터페이스를 추가해서 EVM가 VDS 체인에 있는 정보를 직접 읽을 수 있다. 설명해야 한 것은 계좌 추상화 계층이 어떤 특정한 기능 설치에 관한 디테일을 감추고 상호 조각 가능성을 제고한 것과 플랫폼의 독립성을 위해 중점을 분리한다.
비트 코인 시스템에서 스크립트 시그(Script Sig)와 스크립트 플러그인 키(Script Pub Key)가 검증이 통과해야만 대응한 거래 출력을 소비할 수 있다. .
예를 들면 스크립트 잠그기가 보통 한 거래의 출력이 한 비트 코인 주소에(공개 키의 해시 치) 로크한다. 스크립트 시그와 스크립트 플러그인 두가지의 설정 조건이 부합할 때 그룹 스크립트 실행의 결과가 진으로 (시스템의 반환 값이 1다) 나타나면 대응한 출력이 소비되다.
VDS분산형 시스템에서 우리가 컨센서스 실행의 즉시성만 강조해서 스크립트 플러그인 키에서OP_CREATE 과 OP_CALL을 조각 연산자로 추가된다. VDS 시스템이 이 연산자를 검사했을 때 전 네트워크의 노드가 이 거래를 실행하게 된다. 이런다면 비트코인의 스크립트가 연기한 역할은 다만 코드 언어가 아니고 한 관한 데이터를 EVM로 전송하는 것이다. 이더리움에 운영한 컨센서스 실행 계약과 같아OP_CREATE 과 OP_CALL 조각 연산자로 시동한 계약을 EVM가 각각의 상태 데이터베이스에서 그 상태를 변경하겠다.
VDS체인이 컨센서스 계약이 너무 쉽게 이용할 특성을 고려해 이 계약을 시동한 데이터 및 데이터 기원한 공개 키의 해시 값을 검증해야 한다. VDS체인에 UTXO가 차지한 비례가 너무 크지 않게 위해OP_CREATE 과 OP_CALL의 거래 출력을 소비할 수 잇는 상태로 디자인했다. OP_CALL의 출력이 다른 계약과 공개 키의 해시 주소에 자금을 보낼 수 있다.
우선 VDS체인에 만든 컨센서스 실행 계약에 대해 시스템이 한 거래 해시 치를 이루어지고 이 계약에 의해 사용하게 된다. 새 발표한 계약이 초시 금액이 0(비 0 초시 금액의 계약을 지지하지 않다)이다. 계약 보낸 자금의 수구에 만족시키기 위해 VDS가OP_CALL 조작 연산자로 거래 출력을 창건한다. 계약이 보낸 자금의 출력 스크립트가 다음과 갘다:
10000: gas limit for the transaction
100: gas price in Qtum satoshis
0xF012: data to send to the contract (usually using the solidity ABI)
0x1452b22265803b201ac1f8bb25840cb70afe3303:
ripemd-160 hash of the contract txid OP_CALL
이 스크립트가 복잡한 것이 아니고 OP_CALL가 대 부분의 일을 해내다. VDS가 거래의 구체적인 소비(out-of-gas의 상황을 포함되지 않고)가Output Value이다. 즉Gas Limit이다. 구체적인 Gas제도가 앞으로 나온 글에 설명하겠다. 위에 말한 출력 스크립트를 블록 체인에 추가할 때 이 출력이 계약의 계좌와 대응한 관계를 맺을 수 있다. 그뿐만 아니라 이것이 계약의 잔액에도 표현할 수 잇다. 잔액이 계약에 의해 소비할 수 잇는 충 금액으로 이해할 수 있다.
표준 공개 키의 해시 주소의 출력이 계약 거래에 사용한 기본적이 과정은 계약 사이에 거래한 과정과 비슷하다. 그리고 P2SH과 안 표준적인 거래 주소(non-standard transactions)을 통해 거래를 할 수 있다. 당전 계약이 다른 계약 혹은 공개 키 해시 주소와 거래를 할 때 이 계약 게장에 사용 가능한 출력이 소모되겠다. 소모된 출력이 VDS네트워크에 거래 검증으로 하게 된다. 반드시 존재해야 한다. 우리가 이를 계약 예정 거래이라고 부른다. (Expected Contract Transactions).계약 예정 거래가 거래 사용자 간에 생긴 것이 아니고 채굴자들이 검증하고 거래를 실행할 때 나타난 것이어서 전 네트워크에 방송하지 않겠다.
계약 예정 거래의 주요 원리는OP_SPEND로 통해 실현하는 것이다. OP_SPEND과OP_CALL가 두가지 일한 모델이 잇다. 조각 연산자이 출력 스크립트로서 될 때 EVM로 실행한다. 조각 연산자이 입력 스크립트로서 될 때 EVM가 실행하지 않겠다. (아니면 반복 실행을 하겠다.) 이런 상화에서OP_CREATE 과 OP_CALL가 무 명령 조각으로 된다. OP_CREATE 과OP_CALL가OP_SPEND로 전송한 거래 해시 값을 접수하고 1 혹은 0으로 되돌아가겠다. (즉 소비 가능과 소비 불 가능). 여기서OP_SPEND의 중요성을 표현할 수 있다. 구체적으로 설명하면OP_SPEND가 거래 해시 값을OP_CREATE 과OP_CALL에게 전송하면 ，OP_CREATE 과 OP_CALL을 통해 이 해시 값이 계약 예정 거래 리스트에 존재하는지를 비교할 것이다. 존재하면 1로 되돌아가 즉 소비 가능, 아니면 0로 되돌아가 즉 소비 가능하지 않다. 이 로직이 간접적으로 완전하고 안전한 방식을 제공하고 계약의 자금이 이 계약만 사용할 수 있는 것을 보장한다. 이것이 보통 UTXO 거래 출력과 일치하다.
EVM 계약이 공개 키 해시 주소 혹은 다른 계약에 자금을 보낼 때 한 새 거래를 만들겠다. Consensus-critical coin picking의 연산 방법으로 계약에 사용 가능한 출력 풀에 적당한 거래 출력을 선택한다. 선택된 출력 거래가 단일한OP_SPEND의 출력 스크립트로 되고 출력은 자금의 목표 주소이다. 그리고 남은 자금의 계약에 다시 보내고 동시에 소모 가능한 출력을 변경한다. 다음에 이 거래의 해시 값이 계약 예정 거래 리스트 에 추가할 수 있다. 이 거래를 실행한 후에 이 거래가 당장 블록에 기록하게 된다. 체인에 잇는 채굴이 이 거를 검증하고 실행한 후에 계약 예정 거래 리스트가 다시 만들겠다. 확실이 검증한 후에 이 해시 값이 리스트에 지우겠다. 이런다면OP_SPEND을 사용하면 효과적으로 코드로 해시 값을 편찬을 통해 출력의 소비 가능성을 방지하겠다.
VDS계좌 추상화 층이 EVM을 과도 coin-picking에 관심을 주지 않고 계약에 있는 잔액만 알면서 다른 계약 심지어 공개 키 해시 주소와 자금 거래를 할 수 있다. 이런다면 이더리움의 컨센서스 실행 계약에 대해 조금 수정을 하면 VDS의 계약 운행 요구를 만족할 수 있다.
다름 마하면 이더리움 체인에 실행한 컨센서스 계약들이 VDS체인에도 운행할 수 있다. .
VDS체인의 디자인은 비트 코인의 UTXO 모델에 근거하는 것이다. 일반적인 컨센서스 실행 계약 플랫폼은 계좌 모델을 사용한다. 계약이 한 엔티티로서 한 네트워크 표지가 필요하다. 이 표지는 바로 계약의 주소이다. 그래서 컨센서스 실행 계약을 운행하고 관리하는 동작이 다 이 주소를 조작하는 것으로 실현할 수 있다. VDS체인 모델 디자인에 계좌 추상화 층(Account Abstraction Layer, AAL)을 추가하고 UTXO 모델을 계약이 실행할 수 있는 계좌 모델로 변하게 한다.
컨센서스 실행 계약을 개발한 고안자에게 가상 컴퓨터의 계좌 모델이 상대적으로 간단하는 모델이다. 이 것이 계약 잔액 조회 기능과 다른 계약에 자금을 보낸 기능을 지지한다. 이와 같은 조각이 아주 간단하고 기초적인 조각이지만 VDS체인에 있는 모든 거래가 비트 코인 스크립트 언어를 사용하고 비트 코인 UTXO모델에 근거하여 VDS체인에 있는 계좌 추상화 층에 실현하는 것이 생각보다 어려운 일이다. 그래서 ALL가 이 기초 위에 확장을 한다. 3개 새 연산자를 추가한다.
OP_CREATE가 스마트 계약의 창건을 실행한 데에 사용한다. 거래를 통해 전송한 바이트 코드를 가상 컴퓨터의 계약 저장 데이터베이스에 전하고 한 계약 계좌를 이루어진다.
OP_CALL가 계약을 호출하기 위해 필요한 상관한 데이터와 주소 정보를 전송한 데에 사용한다. 그리고 계약에 있는 코드 내용을 실행한다.(이 연산자가 컨센서스 실행 계약에 자금을 보내기도 한다. )
OP_SPEND가 당전 계약 ID 해시 값을 입력한 거래 HASH이나 계약에 보낸 UTXO의 거래 HASH로 되고OP_SPEND을 소비 지령으로서 거래 스크립트를 구축한다.
현제는 Solidity언어로 컨센서스 실행 계약을 편찬한다.
Solidity remix혹은 기타 Solidity IDE로 코드 편찬과 편역한다.
solidity remix（https://remix.ethereum.org/）
homestead 모델로 편역하는 것을 추천한다.
solidity 0.4.24버전을 사용하기를 추천하다.(다른 버전을 사용하면 오류와 실패 행위가 나타날 가능성이 있다.
Solidity문법이（https://solidity.readthedocs.io/en）로 참고하기 바란다.
편역이 완료 후에ByteCode과 ABI을 얻을 수 있다.
vdsd -txindex=1 -logevents=1 -record-log-opcodes=1 -regtest=1
>테스트 환경이 계약 테스트, 블록 고도가 440에 달한 후에 타스트하기 바란다.
440볼록 고도가 계약 비 정상적인 사건 후에 자금 반환(refund)과 (refund) 후에의 자금 롤백 조각을 완성된다.
```vds-cli deploycontract bytecode ABI parameters```
- bytecode (string, required) contract bytecode.
- ABI (string, required) ABI String must be JSON formatted.
- parameters (string, required) a JSON array of parameters.
이 함수가 계약의 함수를 존재하기를 구조하고 참고 수를 전한 데에 사용한다. 마지막으로 배치에 사용한ByteCode을 얻을 수 있다.
(이 방법이ByteCode과 ABI을 결합하고 본지 에 저장하고 기록하며 본지가 내부 방법을 호출하고 상과 바이트에 되돌아갈 수 있다.)
```vds-cli createcontract bytecode (gaslimit gasprice senderaddress broadcast)```
- bytecode (string, required) contract bytecode.
- gaslimit (numeric or string, optional) gasLimit, default is DEFAULT_GAS_LIMIT, recommended value is 250000.
- gasprice (numeric or string, optional) gasprice, default is DEFAULT_GAS_PRICE, recommended value is 0.00000040.
- senderaddress (string, optional) The vds address that will be used to create the contract.
- broadcast (bool, optional, default=true) Whether to broadcast the transaction or not.
- changeToSender (bool, optional, default=true) Return the change to the sender.
반환 값이 :txid, 발신자,발신자의 hash160 , 계약 주소
```vds-cli gettransactionreceipt txid```
비 계약 거래의 txid의 반환 값이 공이다.
반환값은:이 번에 txid가 체인에 잇는 관한 정보
- transactionHash 거래의hash
- transactionIndex 거래가 이 블록에 처한 위치
- to 발신자는 계약 주소， 계약을 만든 거래 이 곳은
- 00000000000000000000000000000
- cumulativeGasUsed 누계 사용한Gas
다음 과 같은 경우를 주의하기 바란다. Excepted 단락이 None이 아니면 계약 실행 실패한 것을 의미된다. 거래가 체인에서 찾을 수 있지만 계약을 성공적으로 실행하는 것을 의미하지 않다. 다른 말하면 이 계약을 실행한 수수료가 반환하지 않겠다. 계약 내부에 revert 방법에 들어가만 수수료를 반환할 수 있다. 반대에 assert방법이 수수료를 반환할 수 없다.
```vds-cli addcontract name contractaddress ABI decription```
- name (string required) contract name.
- contractaddress (string required) contract address.
- ABI (string, required) ABI String must be JSON formatted.
- description (string, optional) The description to this contract.
이 함수가 계약 ABI을 본지 데이터베이스에 추가하는 데에 사용한다.
```vds-cli getcontractinfo contractaddress```
- contractaddress (string required) contract address.
이 함수가 이미 추가한 계약 정보를 얻을 데에 사용한다.
```vds-cli callcontractfunc contractaddress function parameters```
- contractaddress (string, required) The contract address that will receive the funds and data.
- function (string, required) The contract function.
- parameters (string, required) a JSON array of parameters.
이 함수가 보통 량 방법을 호출할 때 실행 결과에 되돌아간다. 예를 들면 계약 데이터 조각 방법을 호출할 때 조각 스크립트의 십육진법 격식 문자열에 되돌아가겠다.
```vds-cli sendtocontract contractaddress data (amount gaslimit gasprice senderaddress broadcast)```
- contractaddress (string, required) The contract address that will receive the funds and data.
- datahex (string, required) data to send.
- amount (numeric or string, optional) The amount in " + CURRENCY_UNIT + " to send. eg 0.1, default: 0
- gaslimit (numeric or string, optional) gasLimit, default is DEFAULT_GAS_LIMIT, recommended value is 250000.
- gasprice (numeric or string, optional) gasprice, default is DEFAULT_GAS_PRICE, recommended value is 0.00000040.
- senderaddress (string, optional) The vds address that will be used to create the contract.
- broadcast (bool, optional, default=true) Whether to broadcast the transaction or not.
- changeToSender (bool, optional, default=true) Return the change to the sender.
이 함수가 계약의 조각 스크립트를 지정한 계약에 보내고 블록 체인에 기록할 데에 사용한다.
```vds-cli gettransaction txid```
이 명령이 당전 지갑 거래의 확인 수를 볼 데에 사용한다.
```vds-cli gettransactionreceipt txid```
이 명령이 계약 창건과 거래 호출의 실행 결과를 보고 비 정상적인 투매와 실제적인 소모한 GAS을 볼 데에 사용한다.
`${datadir}/vmExecLogs.json` 블록 체인에 있는 계약 호출을 기록하겠다. 이 파일이 계약 사건의 대외 인터페이스로 된다.
l 계약 창건 인터페이스createcontract
l 계약 배치 인터페이스 deploycontract
l 계약 호출 자금을 가진 조각 인터페이스 sendtocontract
l 계약 정보 읽기 인터페이스 callcontractfunc
l 계약 거래 실행 정보를 얻은 인터페이스 gettransactionreceipt
계약을 창건한 운행 비용이 추산한 방법으로 사용한다. gas limit 가 한계가50000000이고 이 한계를 넘으면 계약이 실패하겠기 때문에 100% 성공 실행을 보장할 수 없다. VDS체인이 잔돈을 거슬러 주는 방법을 사용한다. 자세히 말하면 많이 gas을 보내도 채굴자들이 전부 gas을 써버리지 않아 남은 gas을 반환하겠다. 그래서 너무 많은 gas을 쓰는 고민이 안 해도 된다.
계약을 창건한 비용이 한Byte Code 사이즈*300을 gas limit로 되고 gas price 최적 가격이0.0000004 이다，gas price * gas limit은 계약을 창건한 비용이다.
어떤 계약을 실행한 방법은 필요한 gas가 다 예측한 것이다. 네트워크가 막히면 예측은 100% 성공적으로 체인에 올라갈 것을 보장할 수 없다. 그래서 잘못된 오도를 해 줄 것을 두려우면 고안자들이 자기 결과를 검증해야 한다.
