퀀텀 체인 공개 번호는 이 주제를 중심으로 수시로 업데이트됩니다.
퀀텀 프로젝트와 핵심 기술은 처음부터 복원되었으며 지속적인 개선의 역사가 지속적으로 개발되었습니다.
퀀텀 원래 디자인 문서 요약 (1) - 퀀텀 새로운 연산 코드
잘 알려졌지만, 퀀텀의 맨 아래 계층은 비트코인과 일치하는 UTXO 모델을 사용합니다.
원래 UTXO 스크립트는 EVM 계정 모델과 호환되지 않습니다.
그래서 퀀텀은 UTXO 거래 스크립트에 세 개의 OP_CREATE 연산 코드를 추가했습니다.
UTXO와 EVM 계정 모델 간의 전환에 대한 운영 지원 제공
세 개의 연산 코드의 원래 이름은 다음과 같습니다.
OP_EXEC(OP_CREATE), OP_EXEC_ASSIGN(OP_CALL) 및 OP_TXHASH(OP_SPEND)
다음은 관심 있는 독자를 위한 대표적인 원본 문서의 발췌 부분입니다
스마트 게약 생성을 위한 OP_CREATE (또는 OP_EXEC)
이 연산 코드에 대한 원본 디자인 문서 (중국어 번역 포함 안함)는 다음과 같습니다.
(ps : 퀀텀 <#> 또는 퀀텀코어 <#>, 내부 설계 문서 번호 매기기 문서에 있음)
퀀텀코어-3 : 계약 실행을 위한 EVM 및 OP_CREATE 추가
설명 :이 이야기 후, EVM은 통합되어야 하며 매우 기본적인 계약이 실행될 수 있어야 합니다. 새로운 연산 코드가 있을 것입니다.
OP_CREATE (이전 OP_EXEC), 4 개의 증명을 취하고, 푸시 순서로:
노트 : 외부 코드에 대한 정책을 준수하는지 확인하십시오. (바닐라 수정되지 않은 코드를 먼저 실행 한 다음 필요에 따라 변경)
EVM 테스트 스위트를 기능적으로 만들 수도 있습니다. (다른 사람이 연속적인 통합 변경을 설정할 수 있습니다)
위의 문서는 OP_CREATE에 필요한 함수와 사용된 매개 변수를 설명합니다.
OP_CALL (또는 OP_EXEC_ASSIGN)
OP_CALL은 계약 실행에 사용되며 가장 일반적으로 사용되는 연산 코드 중 하나입니다.
퀀텀6 : OP_EXEC_ASSIGN의 EVM에 호출 환경 정보 구현
설명 : Solidity는 특정 정보가 ABI의 일부로 스택에 푸시 될 것으로 예상합니다.
따라서 OP_EXEC_ASSIGN을 사용하여 계약서에 데이터를 보내면 이 데이터를 제공해야 합니다.
이 데이터에는 Solidity "함수 선택기"는 물론 연산 코드 CALLER 및 ORIGIN 함수가 올바르게 작동하도록 보장합니다.
이것은 매우 쉽습니다. BitCin 스택의 일부 데이터를 EVM 스택으로 전송하고 원본 정보에 대한 일부 필드를 설정해야 합니다.
그러나 이 이야기는 여러 작업으로 나누어져 쉽지 않은 경우 다시 평가해야 합니다.
CALLER 및 ORIGIN 값을 채우려면 다음을 수행해야 합니다.
OP_EXEC_ASSIGN은 SENDER와 SENDER_SIGNATURE라는 2 개의 추가 인수를
위의 문서는 OP_EXEC_ASSIGN이 EVM에서 구현해야 하는 호출 환경 정보를 설명합니다.
퀀텀8 : 계약서 송금을 위한 OP_EXEC_ASSIGN 구현
설명 : 새로운 연산 코드 OP_EXEC_ASSIGN을 추가해야 합니다. 이 연산 코드는 푸시 순서로 다음 인수를 취해야 합니다.
이것은 각각 소비 가능한 가스와 가스가 없는 것입니다.
쓸모없게 만들고 가스를 다룰 때의 미래 이야기가 될 것입니다.
이 이야기에서 EVM 계약은 실제로 실행될 필요가 없습니다.
이 연산 코드는 계정 시스템이 계약에서 통제할 수 있는 금액을 결정할 수 있도록 자리 표시 자 여야 합니다.
위의 문서는 OP_EXEC_ASSIGN의 구현 세부 사항을 설명합니다.
퀀텀15 : OP_EXEC_ASSIGN 동안 관련 계약서를 실행하십시오.
설명 :이 이야기가 끝나면 OP_EXEC_ASSIGN에 도달하면 주소가 부여된 계약서가 실제로 실행되어 비트 퀸 스크립트 스택의 관련 데이터가 전달됩니다.
발신자 및 발신자와 같은 다른 데이터는 추후 이야기를 위해 남겨 둘 수 있습니다.
CALLER, ORIGIN 등의 연산 코드가 올바르게 작동하게 하는 것은 이후의 이야기로 수정될 것입니다.
위의 문서는 OP_EXEC_ASSIGN 스크립트가 관련 계약 코드를 실행하는 방법을 설명합니다.
퀀텀40 : 계약서가 공개 키 해시주소로 돈을 송금하도록 허용하십시오.
설명 : 우리는 계약서가 공캐 키 해시 주소로 돈을 돌려보내도록 허락해야 합니다.
그래서 사람들은 허용되면 동전을 계약에서 인출할 수 있습니다.
이것은 버전 0 계약이 작동하는 방식과 유사하게 작동합니다.
대신 OP_EXEC_ASSIGN 출력을 사용하는 대신 표준 공캐 키 해시 스크립트를 사용해야 합니다.
그래서, 공캐 키 해시에 다음과 같은 트랜잭션을 블록체인에 배치해야 합니다.
[표준 계약 OP_EXEC_ASSIGN 입력]
OP_DUP OP_HASH160 [pubKeyHash] OP_EQUALVERIFY OP_CHECKSIG
변경 출력 - 버전 0 OP_EXEC_ASSIGN 지출 계약으로 돌아가기
이러한 출력물은 지갑 코드 자체를 변경하지 않고 지갑에서 직접 소비할 수 있어야 합니다.
위의 문서는 계약서가 퀀텀을 공캐 키 해시 주소로 보내는 것을 허용하는 방법을 설명합니다.
퀀텀코어-10 : 계약서에 다른 전개된 계약을 호출하는 기능 추가
설명 : 계약은 새로운 OP 코드인 OP_CALL을 사용하여 다른 계약을 호출할 수 있어야 합니다.
OP_CALL은 출력에서 사용될 때 계약 실행만 합니다.
OP_CREATE와 마찬가지로 출력 처리 중에 스크립트를 처리하기 위해 특수 규칙을 사용합니다 (비트코인에서 정상적으로 보냈을 때보 다).
트랜잭션 스크립트가 이 표준 형식이고 추가 연산 코드가 없는 경우에만 계약 실행을 트리거 해야 합니다.
잘못된 계약 주소를 사용하는 OP_CALL이 작성되면 계약 실행이 이루어지지 않아야 합니다.
그러나 트랜잭션은 여전히 블록 체인에서 유효해야 합니다.
OP_CALL로 돈을 송금 한 경우, 그 금액 (가스 요금을 뺀 금액)을 환불 처리하여 환불 금액을 입력 [0]의 출력 스크립트로 돌려보내야 합니다.
EVM에 노출된 "보낸 사람"은 입력 [0]에 의해 소비된 공개 키 해시여야 합니다.
입력 [0]에 의해 소비된 출력이 공개 키 해시가 아닌 경우 발신자는 0이어야 합니다.
OP_CALL 입력을 사용하여 계약에 자금을 보낼 수 있습니다.
이 기금은 다른 이야기의 계정 추상화 계층에 의해 처리되어이를 EVM에 표시합니다.
단일 OP_CALLS는 단일 트랜잭션에서 사용될 수 있습니다.
그러나 계약 이행 전에 각 OP_CALL 입력의 가스 가격과 가스 한도를 점검하여 거래가 가스를 충당하기에 충분한 거래 수수료를 제공하는지 확인해야 합니다.
또한 계약이 실행되지 않을 때 (예 : 메모리 풀에서 승인된 경우) 확인되어야 합니다.
위의 문서는 계약서가 OP_CALL을 통해 다른 계약을 호출하는 방법을 설명합니다.
OP_SPEND (또는 OP_TXHASH, OP_EXEC_SPEND)
OP_SPEND는 계약 잔고 비용으로 사용됩니다.
계약서 주소는 특별한 주소이므로 합의를 이루기 위해 UTXO를 특수하게 처리해야 하기 때문에 원본 설계 문서에 OP_SPEND 작업 코드에 대한 자세한 설명이 있습니다.
퀀텀20 : 계약서에 돈을 쓸 때 OP_EXEC_SPEND 거래 생성
설명 : EVM 계약에서 다른 계약금을 보내는 데 사용되는 CALL 연산 코드 또는 유사 코드가 새 거래로 블록체인에 표시되어야 합니다.
계약에서 자금 이체가 이루어지면 광부는 현재 처리 중인 거래가 완료된 후 새로운 거래를 추가해야 합니다.
이 트랜잭션은 redeem 스크립트에서 EXEC_SPEND를 사용하여 계약 소유의 입력을 사용해야 합니다.
이 이야기의 목적을 위해, 변화가 걱정되어야 할 것이 아니라 많은 투입물이 필요하다고 생각하십시오.
성공한 동전을 적절히 골라내고 원래 계약에 돈을 돌려보내는 것은 나중에 이야기로 나옵니다.
계약에 돈을 송금하는 거래는 거래를 실행 한 직후에 이루어져야 합니다.
출력은 버전 -0 OP_EXEC_ASSIGN 출력을 사용해야 하므로 트랜잭션이 컨텍스트 외부에서 수신된 경우 여전히 계약을 실행하지 않을 것입니다.
위의 문서는 OP_SPEND 트랜잭션을 생성하는 타이밍을 설명합니다.
퀀텀21 : OP_EXEC_SPEND 트랜잭션에 대해 합의한 핵심 변경 및 동전 선택 알고리즘 생성
설명 : # 20을 바탕으로 이제 계약에 속한 최적의 출력을 선택하여 소비하는 컨센서스에 중요한 알고리즘을 작성해야 하며 거래에서 변경으로 계약을 다시 반환하는 변경 출력을 작성합니다.
이 경우 모든 출력은 버전 0 OP_EXEC_ASSIGN을 사용하여 둘 이상의 (버전 1) OP_EXEC_ASSIGN 트랜잭션이 단일 트랜잭션이 되는 것을 방지하는 제한 사항으로 실행되지 않도록 해야 합니다.
트랜잭션에는 필요한 만큼의 입력과 정확히 2 개의 출력이 있어야 합니다.
대상 계약서로 이동하는 첫 번째 출력과 원본 계약서로 다시 변경 사항을 보내는 두 번째 출력.
퀀텀22 : 트랜잭션 당 EVM 실행을 두 개 이상 허용하지 않습니다.
설명 : 현저한 엣지 케이스를 피하려면 단일 트랜잭션에서 EVM 실행을 두 번 이상 허용하지 마십시오.
여기에는 배포 및 기금 할당 출력이 포함됩니다.
대신, 그러한 것들은 여러 트랜잭션으로 분할되어야 합니다.
두 번의 EVM 실행이 발생하면 트랜잭션을 완전히 무효로 처리해야 하며 브로드 캐스트 또는 블록 실행에 적합하지 않아야 합니다.
퀀텀23 : EVM을 실행하지 않는 "버전 0"OP_EXEC_ASSIGN을 추가하십시오.
설명 : # 22의 문제를 해결하기 위해 OP_EXEC_ASSIGN을 사용하여 계약이 실제로 실행되지 않고 계약을 체결할 수 있도록 해야 합니다.
나중에 (여러) 계약에 대한 "변경"출력에 사용됩니다.
OP_EXEC_ASSIGN에 대해 전달된 버전 번호가 0이면 계약이 실행되지 않습니다.
또한 OP_EXEC_ASSIGN에 제공된 데이터가 단일 바이트 "0"인 경우에만 유효합니다.
여러 버전 0 OP_EXEC_ASSIGN 출력은 트랜잭션에서 유효해야 하며, 버전이 아닌 0 OP_EXEC_ASSIGN (또는 OP_EXEC 배포)과 여러 버전 0 OP_EXEC_ASSIGN 출력 있어야 합니다.
이것은 계약에서 다른 계약으로 보내지는 모든 자금 지출에 사용됩니다.
위의 세 문서는 합의에 의존하는 코인 피킹 알고리즘이 OP_SPEND 연산 코드가 합의 오류를 일으키지 않는다고 보장할 경우 변경의 정확성이 보장된다고 설명합니다.
동시에 계약서를 실행할 필요가 없는 상황과 처리 방법을 설명합니다.
퀀텀34 : 코인 베이스 트랜잭션에서 OP_EXEC 및 OP_EXEC_ASSIGN을 허용하지 않습니다.
설명 : 코인 베이스의 성숙도 문제 및 가스 환불 스크립트 주문의 잠재적 부작용으로 인해 코인 베이스 산출물이 EVM 실행 또는 EVM 계정 잔액 직접 변경으로 귀결되는 것이면 안 됩니다.
여기에는 버전 0 OP_EXEC_ASSIGN 출력이 포함됩니다.
위의 문서에서는 코인 베이스 트랜잭션에 계약 관련 스크립트가 포함되어서는 안된다고 규정하고 있습니다.
또한 새 작업 코드에 필요한 인프라를 설명하는 몇 가지 문서가 있습니다.
퀀텀코어-51 : OP_CREATE 및 OP_CALL의 버전 필드를 공식화하십시오.
설명 : 프로토콜의 향후 확장을 유지하려면 "버전"인수를 OP_CREATE 및 OP_CALL로 변경하여 나중에 새 VM을 업그레이드하고 추가하는 방법에 대한 몇 가지 규칙을 설정해야 합니다.
우리는 현재 "업그레이드할 때 증분"이상의 VM 버전 형식이 필요합니다.
이렇게 하면 업그레이드 및 소프트 포크를 보다 쉽게 계획 할 수 있습니다.
버전 필드는 이제 반드시 4 바이트 푸시 이어야 합니다.
표준 EVM 계약은 이제 버전 번호 (16 진수) "01 00 00 00"을 사용합니다.
블록에서 유효한 VM 포맷은 0이어야 합니다.
다른 모든 값은 no-exec (허용되지만 실행 불능이 되어 나중에 쉽게 소프트 포크를 만들 수 있음)
VM 버전은 모든 값이 될 수 있습니다 (소프트 포크 호환성).
새 버전이 0보다 많이 사용되면 (0은 초기 출시 버전 임), 버전 0을 사용하여 실행되고 값을 무시합니다
플래그 옵션은 모든 값이 될 수 있습니다 (소프트 포크 호환성). (비활성 플래그 필드는 무시됩니다)
EVM에 할당되지 않은 모든 필드는 0기본값으로 설정되어야 합니다.
위의 문서는 공식적으로 OP_CREATE 및 OP_CALL이 사용해야 하는 버전 정보를 결정하여 퀀텀에 대한 후속 다중 VM 지원을 위한 길을 열어줍니다.
설명 : (주, 이것은 메인 넷에 대한 목표는 아니지만 포함하는 것이 좋습니다)
계약 자체 내에서 계약의 수명주기를 내부적으로 관리할 수 있어야 합니다.
계약의 수명주기 동안 변경해야 할 수도 있는 이러한 변수 및 구성 값은 다음과 같습니다.
pragma solidity ^0.4.0;
contract BlockHashTest {function BlockHashTest() {
}function ValidateGasSchedule(bytes32 addr) public returns (bool) {if(addr=="123454")
{ return true; // 계약 실행 허용}return false; // 계약 실행을 허용하지 않음}function ValidateVMVersion(byte version) public returns (bool){if(version >= 2 && version < 10)
{ return true; // 버전 2-9에서 실행하도록 허용합니다. 예를 들어 1에 취약점이 있고 10 명이 계약을 위반했다고 가정해 보겠습니다.
}return false;
}
}
이런 식으로 계약은 자신의 상태를 관리하는 책임이 있습니다.
기본 작동 방식은 OP_CALL을 사용하여 계약을 호출할 때 OP_CALL을 사용하여 이 두 가지 기능을 먼저 실행하고 실행이 가스 비용에 포함된다는 것입니다.
두 함수 중 하나가 false를 반환하면 즉시 가스 상태를 벗어나 실행을 취소합니다.
그러나 "유효성 검사 VM 버전"콜백을 관리하는 것은 약간 복잡합니다.
사용할 VM 버전을 결정해야 하기 때문입니다.
나쁜 것은 이 기능 자체가 오동작을 일으킬 수 있습니다.
위의 문서는 계약의 관리 인터페이스를 설명하고 계약은 자체 상태를 관리할 수 있습니다.
퀀텀코어-53 : 버전 0 전송을 위한 계약에 옵트아웃 플래그 추가
설명 : 일부 계약에서는 이더리움에 없는 퀀텀의 특정 기능을 거부할 수 있습니다.
이 방법으로 이더리움 계약을 퀀텀 블록체인의 새로운 기능에 대해 걱정하지 않고 퀀텀으로 이식할 수 있습니다.
버전 필드에 플래그 옵션 두 개를 추가해야 계약서를 만들 때 OP_CREATE에만 영향을 미칩니다.
2. (첫 번째 비트) AAL 외부의 본 계약에 대한 "버전 0"OP_CALL을 허용하지 않습니다. (허가하지 않은 버전0)
이 기능을 사용하면 "root VM 0"을 사용하는 OP_CALL (실행되지 않음)이 이 계약서로 보내지는 것이 허용되지 않습니다.
"버전 0"OP_CALL을 사용하여 이 계약서로 송금을 시도하면 가스 부족 예외가 발생하고 환불해야 합니다.
계정 추상화 계층에서 내부적으로 이루어진 버전 0 지불은 이 플래그의 영향을 받지 않아야 합니다.
이러한 새로운 합의 규칙과 함께 표준 메모리 풀 수표도 있어야 합니다.
위에 제시된 퀀텀의 원래 디자인 문서는 계약 실행과 관련된 퀀텀의 증가된 연산 코드를 설명하고, UTXO 모델 위에 계정 모델과 호환되는 후속 퀀텀의 EVM 가상머신을 위한 토대를 마련하고 계정 추상화 레이어 AAL을 가능하게 합니다.
추후 퀀텀 프로젝트 팀은 핵심 문서를 더 해석할 것입니다.
질문이 있으시면 독자는 의견란에 의견을 게시하거나 퀀텀 프로젝트 팀에 문의하십시오.
퀀텀 체인 공개 번호는 퀀텀 프로젝트 및 주요 기술의 이력을 처음부터 복원하기 위해 위 주제를 수시로 업데이트 될 것입니다.
※ UTXO: 미사용 거래 출력
※ UTXO ( unspent transaction output ): 비트코인의 기본 블록체인 메커니즘으로 소비되지 않은 거래 출력은 새로운 거래가 발생될 시 입력용으로 연결(소비) 되게하는 메커니즘
※ 이더리움 가상 머신(EVM): 일종의 작동 기계로 이더리움 플랫폼에서 이루어지는 스마트 계약의 코딩으로 이루어져 있으며 계약은 EVM에서 이루어짐
※ Solidity: 이더리움 가상 머신 Ethereum Virtual Machine (EVM)을 목표로 설계
스마트 계약을 구현하기 위한 계약 중심의 고급 언어
C ++, 파이썬 및 자바스크립트의 영향을 받았음
정적으로 형식화되며, 상속, 라이브러리 및 다른 기능 중에서 복잡한 사용자 정의 유형을 지원
투표, 크라우드 펀딩, 블라인드 경매, 멀티 서명 지갑 등에 대한 계약을 체결하는 것이 가능
이외 암호화폐 용어 설명 (고급) 참고: https://blog.naver.com/ehdtmdcouple/221180535677
1큐텀=1빌딩
2018.05.31 11:37
조회 수 : 589
추천:5 
아사마리
미스릴
Ray