seo스마트 계약은 비트코인과 에테르의 가장 큰 차이다.
스마트 계약은 블록 체인에서 실행되는 코드이며, 코드의 논리는 스마트 계약의 내용을 정의합니다.
스마트 계약의 계정에는 계약의 현재 작동 상태가 보존되어 있습니다. telegram 을 포함한 중국어 버전 다운로드 포털은 몇 개입니까?
잔액 현재 잔액
Nonce 트랜잭션 수
코드 계약 코드
스토리지저장, 저장된 데이터 구조는 MPT 입니다.
스마트 계약의 코드는 일반적으로 solidity 언어로 작성되며, 구문은 Javascript 와 비슷하다.
Solidity
Address 는 solidity 에만 해당되며 나중에 자세히 설명하겠습니다.
Mapping 은 주소에서 부호없는 정수로의 매핑입니다.
Event 는 로그를 기록하는 데 사용됩니다. 이 예에서 첫 번째 event 의 인수는 경매의 주소와 금액이고, 두 번째는 승자의 주소와 경매 금액입니다.
Solidity 는 순회를 지원하지 않습니다. 요소를 통과하려면 해시 테이블에 어떤 요소가 있는지 기록할 수 있는 방법을 찾아야 합니다. 여기서는 bidders 배열로 기록됩니다. solidity 언어의 배열은 고정 길이이거나 동적으로 길이를 변경할 수 있습니다.
생성자에는 두 가지 유형이 있습니다. 첫 번째는 C++ 생성자처럼 contract 와 이름이 같은 함수를 정의하는 것입니다. 함수는 인수를 가질 수 있지만 반환 값은 가질 수 없습니다. 새 버전에서는 constructor 를 사용하여 생성자를 정의하는 것이 좋습니다. 이 함수는 계약이 만들어질 때만 한 번만 호출되며 생성자도 하나뿐입니다.
멤버 함수 중 첫 번째는 payable 이고, 다른 두 가지 함수는 없습니다. 에테르는 계약계좌가 외부 이체를 받을 수 있도록 하려면 payable 로 표시해야 한다고 규정하고 있기 때문입니다.
Eg: 아래 그림은 온라인 경매 계약입니다. 이 경우 bid 함수는 경매에 참여하여 100 개의 이더넷 화폐를 내야 하는 경우와 같이 입찰에 사용됩니다. 계약의 bid 함수를 호출합니다. 그래서 경매의 규칙은 bid 함수를 호출할 때 경매 입찰가 100 개, 즉 100 개 이더넷 화폐도 과거에 계약서에 저장해 경매가 끝날 때까지 잠그는 것이다. (알버트 아인슈타인, Northern Exposure (미국 TV 드라마), 경매명언) 누군가 허공에서 입찰하는 것을 피하다 (실제로는 그렇게 많은 돈이 없고, 하늘 가득히 가격을 외치고 있다). 그래서 경매할 때 낸 가격을 스마트 계약에서 잠가야 한다. 그래서 이 bid 함수는 외부 이체를 받을 수 있는 능력이 있어야 하기 때문에 payable 이라고 표기되어 있습니다.
멤버 함수의 withdraw 함수에는 payable 이 없습니다. withdrew 함수의 용도는 경매가 끝날 때 입찰가가 가장 높은 사람이 경매를 이기고, 다른 사람들은 촬영하고 싶은 것을 찍지 않고, withdraw 함수를 호출하여 자신의 원래 입찰가, 즉 이전 bid 가 스마트계약에 잠겨 있던 에테르를 다시 꺼낼 수 있습니다. Withdraw 의 목적은 실제로 이체하는 것이 아니라, 돈을 스마트 계약으로 옮길 필요가 없고, 단지 withdraw 함수를 호출하여 당초 스마트 계약에 잠겨있던 돈을 되찾기 때문에 payable 을 사용할 필요가 없다.
외부 계정 호출
스마트 계약 호출은 이체와 유사합니다. A->B 이체는 B 가 일반 계좌인 경우 BTC 의 이체 거래와 같은 일반 이체 거래일 뿐입니다. B 가 계약 계좌인 경우 이 이체는 실제로 B 에 대한 계약 호출을 시작합니다. 구체적으로 계약의 어떤 함수가 데이터 도메인 (data 도메인) 에 있는지 알 수 있습니다.
Send address 는 호출을 시작하는 계정 주소이고, To Contract Address 는 호출되는 계약의 주소이고, 호출되는 함수는 TXdata 에서 호출할 함수입니다. 이 함수에 매개 변수가 있는 경우 매개 변수도 여기 data 필드에 설명되어 있습니다. 위 사례의 세 멤버 함수는 모두 매개 변수가 없지만 일부 멤버 함수는 다음과 같습니다
중간 행은 호출의 인수이고, Value 는 호출을 시작할 때 이체하는 돈의 수이며, 여기는 0 입니다. 여기서 함수를 호출하려고 하는 것이 실제 이체를 원하지 않기 때문에 여기서 To contract address 함수는 payable 을 정의할 필요가 없습니다. Gas used 는 이 거래소에서 쓰는 휘발유 요금이고, gas priced 는 단위 휘발유 가격이며, gas limit 은 거래보다 가장 많은 휘발유를 지불하고 있다.
계약 계정 호출
직접 호출
A 계약은 Log (로그) 로 기록되고, event 는 LogCallFoo, emit 라는 이벤트를 정의합니다. emit 의 역할은 log 를 쓰는 것입니다. 프로그램 실행에 영향을 주지 않습니다. B 계약에서 함수의 인수는 주소, 즉 A 계약의 주소이며, 이 문은 이 주소를 A 계약의 인스턴스로 변환한 다음 foo 함수를 호출합니다.
Etherfang 은 거래가 외부 계정에서만 시작될 수 있다고 규정하고 있으며 계약 계정은 스스로 거래를 시작할 수 없습니다. 이 예에서는 실제로 계약 B 의 함수 CallAFooDirectly 를 호출하는 외부 계정이 필요하며, 이 함수는 A 계약에서 foo 함수를 호출합니다.
Address 에서 call 메서드 사용
첫 번째 매개 변수는 함수의 signature 이고 그 뒤에 호출 매개 변수가 옵니다.
이 두 가지 방법의 차이점은 오류 처리의 차이점입니다.
직접 호출에서 호출되는 계약 실행에 오류가 발생하면 호출되는 계약이 함께 롤백됩니다. 예를 들어 그림 A 에 예외가 발생하면 B 가 함께 예외를 발생시킵니다.
두 번째 방법의 경우 호출되는 계약에 예외가 발생하면 호출되는 계약에서 call 함수는 false 만 반환하는데, 이는 호출이 실패했음을 나타냅니다. 호출을 시작하는 함수는 예외를 발생시키지 않고 계속 실행할 수 있습니다.
Delegatecall () 을 사용합니다
Call () 의 메서드와 기본적으로 동일합니다. 한 가지 주요 차이점은 Delegatecall () 이 호출된 계약의 환경으로 전환하지 않고 현재 환경에서 실행된다는 것입니다. 예를 들어, 현재 계정 잔액으로 저장하는 것과 같은 것들이죠.
Etherfang 에서 외부 이체를 수락하려는 모든 함수는 payable 로 표시해야 합니다. 그렇지 않으면 이 함수에 돈을 돌려 오류 처리를 일으켜 예외를 발생시키고, 외부 이체를 받을 필요가 없다면, 함수는 payable 을 쓰지 않아도 됩니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 성공명언) 구체적으로 위와 같은 코드.
Fallback 함수
인수 없음 반환 값 없음, 함수 이름 없음, fallback 키워드는 함수 이름에 나타나지 않습니다.
계약을 호출할 때, A 는 B 계약을 호출하고, 이체 거래의 데이터 필드에 계약 B 중 어떤 함수를 호출하는지 설명하고, A 가 B 에게 돈을 돌리면 어떤 함수를 호출하는지 설명하지 않습니다. 즉, 데이터 필드가 비어 있습니다. 이 때 기본값은 이 fallback 함수를 호출하는 것입니다. 이것이 바로 fallback 함수라고 부르는 이유입니다. 또 다른 경우는 호출할 함수가 존재하지 않는다는 것입니다. 데이터 도메인에서 이 함수를 호출한다고 합니다. 실제 계약에는 이 함수가 없고, fallback 함수도 호출됩니다. 그래서 이 함수에는 인수도 없고 반환 값도 없습니다. (데이비드 아셀, Northern Exposure (미국 data 드라마), 성공명언)
Fallback 함수도 payable 키워드를 표시해야 할 수 있습니다. 만약 fallback 함수가 이체를 받을 수 있는 능력이 필요하다면 payable 을 써야 합니다. 일반적으로 payable 을 써야 합니다. 계약 계정에 fallback 함수를 포함한 payable 이라는 함수가 없으면 이 계약은 외부 이체를 받아들일 수 있는 능력이 없습니다 누군가가 계약서에 돈을 이체하면 이상이 생길 수 있다.
이체 금액은 0 이 될 수 있지만 수취인에게 주는 것이지만, 휘발유 요금은 광부에게 주는 것이니, 주지 않으면 광부들은 거래를 블록체인에 포장하지 않을 것이다.
스마트 계약은 외부 계정에서 이체 거래를 시작하여 0X0 주소로 옮긴 다음 게시할 계약 코드를 데이터 도메인에 넣는 것입니다.
지능형 계약은 EVM 에서 실행됩니다. Jvm (Java virtual machine) 은 일관성을 향상시키기 위해 EVM 도 비슷한 생각을 하고 있습니다. 가상 시스템을 추가하여 지능형 계약 운영에 일관된 플랫폼을 제공하기 때문에 EVM 은 world uint compute 라고도 하며 EVM 의 주소 지정 공간은 매우 크고 256 비트입니다
비트코인과 에테르방 두 블록 체인 모델의 디자인 이념은 크게 다르다. 비트코인의 디자인 이념은 간단하다. 스크립팅 언어의 기능은 한계가 있어 순환을 지원하지 않는다. 에테르는 튜링의 완전한 프로그래밍 모델을 제공하는 것입니다. 비트코인 시스템에서는 많은 기능을 실현할 수 없거나 비교적 어렵지만, 에테르방에서 실현하는 것은 매우 쉽다. 물론, 이로 인해 사순환이 발생하는 것과 같은 문제도 생길 수 있습니다. 전체 노드가 스마트 계약에 대한 호출을 받을 때, 이 호출이 실행될 때 사순환으로 이어질 수 있는지 어떻게 알 수 있습니까? 무슨 해법이 있습니까?
아니요, 이것은 가동 중지 시간 문제입니다.
다운타임 문제는 해결할 수 없습니다. 이 문제는 NPC 의 문제 (Non-deterministic Polynomial 의 문제, 즉 다항식 복잡성의 불확실성 문제) 가 아니며, NPC 의 문제는 해결 가능하지만 다항식 시간의 해결책은 없습니다. 많은 NPC 문제에는 많은 자연 지수 시간의 해결책이 있습니다. 각 조합이 합법적 인 회로를 구성하는지 확인하고 해밀턴 회로가 있는지 확인하십시오 해밀턴 회로는 해결 가능하지만 솔루션의 복잡성은 기하급수적입니다. 셧다운 문제는 주어진 입력 프로그램에 대해 telegram 홈페이지의 다운로드 사이트가 얼마나 많은지 판단할 수 있는 알고리즘이 없다는 것이 이론적으로 증명된 바 있다. 이 프로그램이 중단될 수 있는지 아닌지는 알 수 없다. (알버트 아인슈타인, Northern Exposure (미국 TV 드라마), 스포츠명언)
에테르방에서 어떻게 해결할까요?
이 문제를 거래를 시작한 계좌로 밀어내자, 에테르는 휘발유비 메커니즘을 도입했고, 당신은 스마트계약에 대한 호출을 개시하려면 상응하는 휘발유비를 지불해야 한다.
지시마다 소비되는 휘발유 요금이 다르다. 가감법과 같은 간단한 지시문은 휘발유 비용이 적고 복잡한 지시문은 많이 소비된다.
예를 들어 해시를 취하면, 이 연산은 하나의 지시로 완성할 수 있지만, 휘발유 요금은 비교적 비싸다. 계산량 외에 상태를 저장해야 하는 명령어가 소비하는 휘발유 비용도 비교적 크다. 반대로, 단지 공공 데이터를 읽기 위해서라면, 그 지시들은 무료일 수 있다.
트랜잭션의 데이터 구조:
AccountNonce 는 앞서 언급한 재생 공격 (replay attack) 을 막기 위한 거래 순번으로, price 는 단위 휘발유 가격이고, Gaslimit 는 이 거래가 지불하고자 하는 최대 휘발유 양이며, 곱하면 이 거래가 소비할 수 있는 최대 휘발유 요금이 됩니다.
Recipient 는 수취인의 주소, amount 의 이체 금액으로 거래 중 휘발유 요금이 이체 금액과 분리되어 있음을 알 수 있습니다.
Payload 는 앞서 언급한 데이터 도메인으로, 계약에서 호출할 함수와 함수의 매개 변수 값이 무엇인지 저장하는 데 사용됩니다.
전체 노드가 스마트 계약에 대한 호출을 받으면, 먼저 이 호출에 따라 지출될 수 있는 최대 휘발유 비용을 계산한 다음, 한 번에 호출한 계좌에서 휘발유 비용을 공제한 다음, 실제 실행에 따라 실제로 얼마나 많은 휘발유 비용을 썼는지 계산하면 휘발유 비용이 부족하면 롤백이 발생할 수 있다. (윌리엄 셰익스피어, 휘발유, 휘발유, 휘발유, 휘발유, 휘발유, 휘발유, 휘발유, 휘발유, 휘발유, 휘발유, 휘발유)
에테르의 거래는 원자성을 가지고 있으며, 하나의 거래는 모두 실행되거나 전혀 실행되지 않고 일부만 실행되지는 않습니다. 이 거래에는 일반 이체 거래와 스마트 계약에 대한 호출이 모두 포함되므로 스마트 계약 실행 중 오류가 발생하면 전체 거래의 실행이 롤백되어 실행이 시작되기 전의 상태로 돌아갑니다. 마치 이 거래가 전혀 실행되지 않은 것 같습니다.
오류 처리 1
앞서 말한 휘발유 요금은 이 거래가 끝난 후 당초 가스리미트에 도달하지 못하면 추가 휘발유 요금이 이 계좌로 반송됩니다. 반대로, 절반까지 집행되면 gaslimit 이 소진되고, 계약 집행은 실행이 시작되기 전의 상태로 되돌아가고, 이때 이미 소비된 휘발유비는 환불되지 않는다. 왜 이렇게 디자인할까요? 일부 악의적인 노드가 denial service attack 을 시작하지 않도록 하고, 계산량이 많은 계약을 시작한 다음, 매번 호출할 때마다 주는 휘발유 요금이 충분하지 않습니다. 어차피 결국 휘발유 요금이 반환되어 악의적인 노드에게는 아무런 손실이 없지만 광부들에게는 많은 자원을 낭비했습니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 스포츠명언)
위에서 언급한 거래 광부 처리는 많은 자원을 낭비한다. 각 광부들이 거래를 받고 거래풀에 넣어 거래와 기타 조건 검증을 검증한 다음 거래를 블록으로 조립하고 블록에 대한 작업량 증명을 하기 때문이다.
한 블록의 모든 거래는 성공한 광부에 의해 처리되고, 그 광부는 이 블록에 대한 보상과 이 빨리 포함된 모든 거래에 대한 수수료를 받게 된다. (윌리엄 셰익스피어, 햄릿, 성공명언)
오류 처리 2
Assert 문과 require 문. 여기서 두 문은 모두 조건을 판단하는 데 사용되며, 조건이 충족되지 않으면 예외가 발생할 수 있습니다.
Assert 문은 일반적으로 C 언어와 비슷한 내부 조건을 판단하는 데 사용됩니다.
Reuire 문은 함수의 입력이 요구 사항을 충족하는지 여부를 판단하는 것과 같은 외부 조건을 판단합니다. 다음 그림에 표시된 예는 bid 함수에서 현재 시간 now 가 경매 종료 시간보다 작거나 같은지 여부를 판단하는 것입니다. 조건이 충족되면 실행을 계속합니다. 맞지 않습니다. 즉, 경매 시간이 이미 종료되면 예외가 발생합니다.
오류 처리 3
Revert 문은 무조건 예외를 발생시킵니다. revert 문이 실행되면 자동으로 롤백이 발생합니다. 이전 버전에서는 throw 문을 사용하고 새 버전의 solidity 는 revert 문으로 변경하라고 제안합니다.
Java 사용자와 같은 일부 언어는 오류가 발생하는 방법을 직접 정의할 수 있지만 solidity 에는 try-catch 구조가 없습니다.
Q1: 앞서 말한 스마트 계약 호출에 오류가 있으면 롤백이 발생할 수 있습니다. 그렇다면 중첩된 호출인 경우 한 스마트 계약이 다른 스마트 계약을 호출하고, 호출되는 스마트 계약에 오류가 발생하면 호출을 시작하는 스마트 계약도 함께 롤백되지 않을까요? 체인 롤백이라고 합니다.
꼭 그렇지는 않습니다. 이는 스마트 계약이 호출되는 방식에 따라 다릅니다. 이 스마트 계약이 직접 호출되는 경우 체인 롤백이 트리거되고 전체 트랜잭션이 롤백됩니다. Call () 을 사용하여 호출하는 경우 체인 롤백을 일으키지 않고 현재 호출이 실패하여 False 의 반환 값을 반환합니다.
Q2: 어떤 경우에는 표면적으로, 당신은 단순한 계좌 이체와 같은 어떤 함수도 호출하지 않지만, 이것이 계약계좌라면, 이체 자체가 함수에 대한 호출을 트리거할 수 있습니다. 왜 그럴까요? (데이비드 아셀, Northern Exposure (미국 TV 드라마), 남녀명언)
Fallback 기능이 있기 때문에 이것은 중첩 호출입니다. 한 계약이 다른 계약으로 이체되면 이 계약에서 fallback 함수를 호출할 수 있습니다.
(call () 을 사용하여 계약을 이체하는 경우 계약에 fallback 함수가 없거나 호출할 함수를 설명하지 않으면 call 자체가 false 를 반환하지만 연결된 롤백은 발생하지 않습니다. ) 을 참조하십시오
Blockheader
GasUsed 는 이 지역에서 모든 거래소가 소비하는 휘발유 비용을 합친 것이다.
GasLimit 은 이 블록의 모든 거래가 휘발유를 소비할 수 있는 상한선이며, 여기는 각 거래의 gaslimit 과는 다르다.
설명: 비트코인에서는 블록당 1M 을 초과할 수 없다고 규정하고 있으며, 협정에서 변경할 수 없는 거래입니다. 비트코인의 거래는 비교적 간단합니다. 기본적으로 거래의 바이트 수로 이 거래가 소비하는 자원의 양을 측정할 수 있지만, 에테르방은 이렇게 규정하면 안 됩니다세계 랭킹 1 위오피스타 공식 입구를 찾는 방법. 스마트계약의 논리가 복잡하고, 어떤 거래는 바이트에서 작게 보일 수 있지만, 다른 계약을 호출할 수 있는 것과 같이 소모되는 자원은 매우 큽니다. 거래의 구체적인 조작에 따라 요금을 내야 하는데, 이것이 바로 휘발유비 설정의 gaslimit 입니다.
에테르의 상한선 GasLimit 은 비트코인과는 달리, 각 광부들은 블록을 발표할 때 이 GasLimit 을 미세 조정할 수 있으며, 이전 블록의 GasLimit 에서 1/1024 를 올리거나 내릴 수 있습니다. 이 메커니즘은 실제로 찾은 시스템 GasLimit 이 모든 광부들이 비교적 합리적이라고 생각하는 GasLimit 의 평균치입니다.
Q1: 전체 노드가 일부 거래를 블록으로 포장해야 한다고 가정해 봅시다. 이들 거래 중 일부는 스마트 계약에 대한 호출입니다. 그러면 이 전체 노드는 먼저 스마트 계약을 모두 수행한 후 광산을 파야 할까요? 아니면 광산을 파서 부기 권리를 얻은 다음 지능 계약을 집행할 것인가?
(? 전체 노드는 광부와 같은가요? () (광부는 모든 블록 체인 데이터를 사용합니다)
(거래를 발표 한 후 각 노드를 수행해야합니다. 그렇지 않으면 상태가 동기화되지 않고 업데이트됩니다. 스마트 계약이 발표 된 후 휘발유 요금을 공제해야합니다. 노드 전체에서 공제됩니다.)
A: 먼저 스마트 계약을 수행한 다음 광산을 파야 합니다. 이더넷방 광산은 서로 다른 nonce 값을 시도해야 합니다. 요구 사항에 맞는 해시를 계산할 때 blockheader 의 내용을 찾아야 합니다. 세 그루의 뿌리해시가 포함되어 있습니다. 실행 블록에 있는 모든 거래에 스마트 계약 거래가 포함되어 있어야 세 그루의 나무를 업데이트할 수 있습니다. 세 그루의 해시를 알 수 있습니다. Blos
Q2: 전체 노드가 스마트 계약에 대한 호출을 받았을 때, 이 호출에서 쓸 수 있는 최대 휘발유 비용을 이 호출을 시작한 계좌에서 한 번에 빼야 하는데, 이것은 구체적으로 어떻게 작동합니까?
세 그루의 나무, 상태 트리, 거래 트리, 영수증 트리는 모두 노드 전체가 로컬에서 유지 관리하는 데이터 구조이며, 상태 트리는 계정 잔액을 포함한 각 계정의 상태를 기록합니다. 휘발유 요금은 전체 노드가 호출을 받을 때 로컬에서 유지 관리되는 데이터 구조에서 계정 잔액을 빼면 됩니다. 청크가 게시된 후에만 로컬 수정이 외부에서 볼 수 있게 되므로 블록 체인의 공감대가 됩니다.
Q3: 광부들은 광산을 파는 과정에서 지능 계약을 집행하는 과정에서 많은 현지 자원을 소비했지만, 부기 권리도, 보상도, 휘발유 보상도 받지 못했는데 어떻게 해야 하나요?
답: 어쩔 수 없습니다. 이태방은 보상이 없습니다. 다른 사람이 발표한 블록의 거래를 로컬에서 한 번 수행해야 합니다. 이태방은 게시 블록의 정확성을 검증하도록 규정하고, 각 전체 노드는 독립적으로 검증해야 합니다. 다른 사람이 게시한 거래 블록을 로컬에서 한 번 실행하고, 세 그루의 내용을 업데이트하여 루트 해시를 계산하고, 게시된 새 블록의 루트 해시와 일치하는지 비교해야 합니다. (존 F. 케네디, Northern Exposure (미국 TV 드라마), 성공명언) 이런 메커니즘으로 광산이 느린 광부들은 특히 손해를 본다. 휘발유비 설정은 원래 광부에 대한 지능 계약 집행에 소모된 자원에 대한 보상이었지만, 이런 보상은 광산을 파낸 광부만이 얻을 수 있고, 다른 광부들은 얻을 수 없다.
Q4: 검증하지 않으면 어떤 영향을 미칩니까? 어떻게 개선할 것인가?
A: 블록 체인의 보안을 직접 위협 할 것입니다. 블록 체인의 보안 보증은 모든 전체 노드 독립 검증 게시 된 블록의 합법성에서 비롯됩니다. 따라서 악의적 인 노드 중 일부는 이러한 콘텐츠를 변조 할 수 없습니다. 일부 광부가 알아낼 수 없다면 돈을 확인하지 않으면 블록 체인의 보안이 위태로워 질 수 있습니다.
검증 단계를 건너뛰면 나중에 광산을 파낼 수 없기 때문이다. 검증을 할 때 블록의 거래를 한 번 수행하고, 지역 나무 세 그루를 업데이트하고, 최신 뿌리해시를 얻고, 검증하지 않으면 지역 나무 세 그루의 내용을 업데이트할 수 없기 때문이다. 앞으로 새 청크를 발표할 수 없다.
게시된 블록에는 세 그루의 나무 내용이 없기 때문에, 단지 블록 머리에 뿌리의 해시가 있어서, 나무의 구체적인 내용을 볼 수 없고, 로컬 계정을 업데이트할 수 없기 때문에 검증하지 않을 수 없다.
광산에서 광부 자체는 검증되지 않았다. 전체 노드 pool manager 가 통일검증을 담당하고, 광부들은 전체 노드 검증의 정확성을 믿고, 전체 노드가 광부에게 배정된 것은 puzzle 의 내용이고, puzzle 은 전체 노드가 블록 체인을 따라 새로 얻은 것이다. (알버트 아인슈타인, Northern Exposure (미국 TV 드라마), 광부명언)
Q5: 블록 체인에 게재된 모든 거래가 성공적으로 실행되었습니까? 스마트 계약이 실행 중에 오류가 발생하면 블록 체인에 게시하시겠습니까?
오류가 발생한 거래도 블록체인에 게시해야 한다. 그렇지 않으면 휘발유 비용을 공제할 방법이 없다.
Q6: 이 거래가 성공적으로 수행되었다는 것을 어떻게 알 수 있습니까?
세 그루의 나무 중 각 거래가 실행된 후 영수증이 형성되는데, 아래 그림은 영수증의 내용이다. 여기서 status 도메인은 이 거래의 집행 상황을 알려준다.
Receipt 데이터 구조
Status 도메인은 이 거래의 이행, 성공 또는 실패를 알려줄 것이다.
Q7: 지능형 계약 지원에서 멀티스레딩을 지원하지 않습니까? 멀티코어 병렬 처리.
Solidity 는 다중 스레드를 지원하지 않으며 다중 스레드 명령문이 없습니다.
Etherfang 은 트랜잭션 중심 상태 시스템이며, 이 상태 시스템은 완전히 확실해야 합니다. 즉, 지능형 계약이 주어져야 합니다. 즉, 동일한 입력에 직면하거나, 결과 출력을 생성하거나, 다음 장소로 이동하는 상태는 완전히 결정되어야 합니다세계 랭킹 1 위오피스타 공식적인 수입 방법. 모든 전체 노드가 동일한 작업 세트를 수행해야 하기 때문에 동일한 상태에 도달하여 검증해야 합니다. 상태가 불확실하면 그 세 나무의 뿌리 해시가 맞지 않기 때문에 완전히 확정해야 한다.
멀티 스레딩의 문제는 다중 확인 메모리 액세스 순서가 다르고 실행 결과가 불확실할 수 있으므로 solidity 는 멀티 스레딩을 지원하지 않는다는 것입니다. 다중 스레드를 제외한 결과가 불확실할 수 있는 다른 모든 작업도 지원되지 않습니다 (예: 난수 생성). 따라서 에테르에서는 실제로 난수를 생성할 수 없고, 의사 난수만 생성할 수 있습니다. 그렇지 않으면 앞의 문제가 다시 발생하고, 각 노드마다 한 번 실행한 결과가 다릅니다.
이용 가능한 청크 정보
지능형 계약의 실행은 확실해야 합니다. 이로 인해 지능형 계약은 일반 프로그래밍 언어처럼 시스템 호출을 통해 시스템 호출을 통해 일부 시스템 콜의 일부 환경 정보를 얻을 수 없습니다. 각 노드의 실행 환경이 정확히 동일하지 않기 때문입니다. 따라서 그는 일부 고정 변수의 값을 통해서만 일부 상태 정보를 얻을 수 있습니다. 이 테이블은 스마트 계약에서 얻을 수 있는 블록 체인의 일부 정보입니다.
사용 가능한 호출 정보
예를 들어, 외부 계정 A, 계약 B 호출, 계약서에 함수 f1, f1 이 또 다른 계약 C 를 호출하고, 그 안에 함수 F2 가 있다면, 이 F2 함수에 대해 msg.sender 는 B 계약이고, tx.origin 은 계정 A 입니다.
Msg.gas 는 현재 이 호출에 남아 있는 휘발유 요금이 얼마인지, 이것은 내가 또 무엇을 할 수 있는지를 결정한다. 다른 계약을 다시 호출하려면 충분한 휘발유비가 남아 있어야 한다.
Msg.data 는 호출한 함수와 이 함수의 인수 값을 기록한 데이터 도메인입니다.
Msg.signature 는 msg.data 의 처음 4 바이트로 함수 식별자, 호출되는 함수입니다.
Now 와 timestamp 는 지능 계약에서 정확한 시간을 얻을 수 없고 현재 블록과의 정보 시간만 얻을 수 있다는 뜻입니다.
주소 유형
첫 번째는 멤버 변수입니다. 멤버 계정의 잔액 balance, uint256 은 멤버 변수의 유형, 함수 호출 (인수) 이 아니라 단위가 작습니다. Addr.balance () 이 주소의 계정 잔액입니다.
나머지는 멤버 함수입니다. 멤버 함수의 의미와 직관적 이해가 다릅니다. addr.transfer(12345) 는 addr 이 아니라 현재 이 계약 C 가 이 주소로 얼마나 전입했는지 알 수 있습니다.
Addr.call 은 현재 이 계약이 addr 계약을 호출하는 호출을 시작한다는 것을 의미합니다.
Q8: fallback 함수가 정의되지 않은 함수로 이체하는데, 오류가 발생하면 롤백이 연결되어 있지 않을까요?
이것은 이체하는 방법에 달려 있습니다. Transfer, send, and call.value 모두 ETH 를 보낼 수 있는 세 가지 이체 방법이 있습니다.
그러나 transfer 와 send 는 이체를 위한 함수인데, 단, transfer 는 직접 호출하는 메서드와 유사하게 연쇄 롤백을 발생시켜 실패할 때 예외를 발생시킨다는 점이 다릅니다. Send 는 체인 롤백을 일으키지 않고 False 를 반환합니다.
Call 도 이체할 수 있습니다. call.value (이체 금액) (호출되는 함수, 비어 있을 수 있음) 하지만 call 의 의도는 함수 호출을 시작하는 것이지만 이체에도 사용할 수 있습니다. 이것도 연쇄적인 롤백을 일으키지 않고 False 를 반환합니다.
또 다른 차이점은 transfer 와 send 가 호출을 시작할 때 휘발유를 조금 주었다는 점이다. 휘발유는 2300 개 단위다. 매우 적다. 이체를 받는 계약은 기본적으로 다른 일을 할 수 없다. 로그도 하나 쓰고, call 은 현재 이 호출에 남아 있는 모든 휘발유를 보냈다. 예를 들어 call 이 있는 이 계약 자체가 외부에서 호출된 것과 같다. (알버트 아인슈타인, Northern Exposure (미국 TV 드라마), 스포츠명언)
단순 경매
경매 규칙: 경매가 끝나기 전에 모든 사람이 입찰을 할 수 있습니다. 경매할 때 성실성을 보장하기 위해 경매 가격에 해당하는 에테르를 보내야 합니다. 예를 들어 100 개의 에테르를 보내야 합니다. bid 함수를 사용하여 경매할 때는 100 개의 에테르를 스마트 계약으로 보내야 합니다. 경매가 끝날 때까지 안에 잠가야 합니다. 중간 퇴출이 허용되지 않습니다. 가격을 인상할 수 있습니다. 경매가 끝난 후 경매에 성공하지 못한 다른 사람들은 돈을 다시 꺼낼 수 있다. 경매는 여러 차례 입찰할 수 있고, 차액을 스마트 계약서에 보내면 된다. 입찰이 유효하면 인상 후 입찰가가 이전의 최고 입찰가보다 높은지 확인해야 한다. 그렇지 않으면 무효가 된다.
Constructor 생성자는 계약이 생성될 때 수혜자가 누구인지, 종료 시간이 언제인지 기록합니다.
다음 두 가지는 경매에 사용되는 두 가지 함수입니다.
왼쪽은 경매 bid 함수입니다. 경매할 때 경매 계약의 bid 함수를 호출하는 거래입니다. bid 는 매개변수가 없지만 msg.value 가 이 호출을 시작할 때 이체된 이더넷 통화 수가 경매 가격입니다.
먼저 이전 입찰가와 현재 호출에서 보낸 이더넷 통화가 최고 입찰가보다 큰지 확인하고, 이전에 입찰한 적이 없다면 첫 번째 부분은 0 입니다.
Bids 는 해시 테이블입니다. solidity 의 특징은 쿼리할 키 값이 없으면 기본값 0 을 반환하는 것입니다. 그래서 이전에 입찰한 적이 없다면, 첫 번째 부분은 0 입니다.
첫 번째 경매에서는 경매인의 정보를 bidder 배열에 넣었습니다. solidity 는 순회를 지원하지 않기 때문입니다. 해시 테이블을 통과하려면 어떤 요소를 보존해야 합니다. 그리고 새로운 최고 입찰자가 누구인지, 로그 등을 기록해야 합니다. (존 F. 케네디, Northern Exposure (미국 TV 드라마), 성공명언)
오른쪽은 경매가 끝난 후의 계약입니다.
먼저 경매가 끝났는지 확인하고, 이미 끝났는데도 경매에 참여하면 예외를 던진다.
두 번째 줄은 이 함수가 호출되었는지 여부를 판단하고, 호출되면 다시 한 번 조정할 필요가 없다.
세 번째 줄은 최고 입찰자의 돈을 수혜자에게 넘기고, 경매에 성공하지 못한 사람은 결국 비더에게 금액을 돌려준다.
마지막으로, 이 함수가 이미 실행되었음을 표시해 주세요. log 를 쓰세요.
경매에 참여하려면 solidity 프로그램을 작성하고 거래를 발표하고 이 계약을 인터넷에 올리면, 다른 사람들이 이 계약이 자신의 오프라인 홍보가 필요하다는 것을 어떻게 알 수 있습니까? 블록체인은 상관없습니다. 그리고 다른 사람이 계약 주소를 알고 경매를 하는 것은 모두 블록체인에서 이체거래를 통해 집행된다
스마트 계약의 코드는 데이터 도메인에 저장됩니다. 광부들은 스마트 계약을 블록 체인에 게시한 후 계약 주소를 반환합니다. 그러면 이 계약은 블록 체인에 있으며 모든 사람이 호출할 수 있습니다. (데이비드 아셀, Northern Exposure (미국 data 드라마), 지능명언)
누구든지 입찰하여 Bid 함수를 호출하는 작업은 광부들이 블록 체인에 게시해야 한다.
여기서 한 가지 문제는 AuctionEnded 함수를 호출해야 실행이 끝나고, 실행 후에야 끝나는데, solidity 언어는 그를 경매가 끝난 후 자동으로 end 를 실행하도록 설정할 수 없다는 것이다. (알버트 아인슈타인, Northern Exposure (미국 TV 드라마), 성공명언)
해커가 경매를 실패하게 했다
해커는 팔백 (fallback) 을 이용하여 전체 경매의 실패를 실현할 수 있다.
한 사람이 위 그림 왼쪽에 있는 계약 계좌를 통해 경매에 참가한다고 가정하면 어떤 결과가 나올까요?
이 계약에는 단 하나의 함수, hack_bid, 매개 변수는 경매 계약의 주소이며 경매 계약의 예로 전환한 다음 경매 계약의 BID 함수를 호출하여 돈을 보냅니다. 이것은 계약 계좌입니다. 계약 계좌는 스스로 거래를 시작할 수 없습니다. 해커가 자신의 외부 계좌에서 거래를 시작하고, 이 계약의 hack_bid 함수를 호출해야 합니다. 이 함수는 경매 계약의 bid 함수를 다시 호출하고, 자신이 받은 돈, 해커가 외부에서 돌려준 돈, 경매 계약의 bid 함수로 넘어가면 경매에 참여합니다.
경매에 참여하는 것은 문제가 없지만 환불에 문제가 있습니다. 이 계약 계좌로 이체된 돈은 어떻게 될까요?
해커 외부 계정은 경매 계약에 보이지 않습니다. 경매 계약에서 볼 수 있는 것은 해커 계약입니다. 여기서 환불 이체 함수는 함수를 호출하지 않습니다. 계약 계정이 이체를 받고 어떤 계정도 호출하지 않을 때 fallback 함수를 호출해야 합니다. 그러나 이 함수는 fallback 함수를 정의하지 않습니다. 호출이 실패하고 예외가 발생합니다. transfer 함수는 연쇄 롤백을 발생시켜
이체는 전체 노드가 beneficiarytransfer 에 실행될 때 해당 계정의 잔액을 조정하는 프로세스입니다. 모든 solidity 문은 스마트 계약 실행 중 모든 명령문으로 상태를 수정하는 것은 로컬 상태와 로컬 데이터 구조입니다. 그래서 이 순환에서 해커 계약 순서 앞이든 뒤든 로컬 데이터 구조를 바꾸고 있지만, 뒤편에 있는 bidder 는 미처 집행할 기회가 전혀 없었고, 그 후 전체가 롤백되었다. 마치 이 스마트 계약이 한 번도 집행되지 않은 것처럼 모든 사람이 돈을 받지 못했다. (윌리엄 셰익스피어, 햄릿, 지혜명언) 이런 상황이 발생하면 어떻게 합니까?
방법이 없습니다. code is law, 지능형 계약의 규칙은 코드 논리에 의해 결정되며, 블록 체인에 게시되면 코드를 변경할 수 없습니다. 이러한 장점은 아무도 규칙을 변조할 수 없고, 단점은 허점이 있어도 수정할 수 없다는 것입니다. 스마트 계약이 잘 설계되지 않으면 에테르화폐를 영구적으로 잠글 수 있습니다. 아무도 가져갈 수 없습니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 스마트명언) Irrevocable trust 의 철회할 수 없는 신탁과 비슷하다.
개발자에게 버그를 고치기 위해 스마트 계약에 뒷문을 남겨 줄 수 있나요?
생성자에 도메인 owner 를 추가하여 owner 가 누구인지 기록한 다음, owner 의 주소에 대해 시스템 관리자와 비슷한 작업을 할 수 있도록 합니다. 예를 들면 임의로 이체할 수 있습니다. 버그가 나타난 후 수퍼 관리자는 잠긴 돈을 이체할 수 있다. 이렇게 하는 전제는 모든 사람이 이 사람을 믿어야 한다는 것이다. 그렇지 않으면 그는 돈을 가지고 도망칠 수 있다. 그럼 다른 개선 방법이 있나요?
버전 개선
앞의 auctionend 함수를 두 개의 함수로 나눕니다. 왼쪽은 withdraw 오른쪽은 beneficiary 입니다.
Withdraw 는 순환할 필요가 없다는 뜻입니다. 경매에 실패한 모든 사람이 스스로 withdraw 함수를 호출하여 돈을 인출합니다. 이 사람이 최고 입찰자인지 아닌지를 판단하면 환불할 수 없다. 계좌 잔액이 양수인지 아닌지를 판단하고, amount 는 계좌 잔액이고, if 는 계좌 잔액을 msg.sender 로 넘기고, 호출한 사람을 시작한 다음, 다음에 다시 돈을 인출하지 않도록 계좌 잔액을 0 으로 정리한다.
Pay2Beneficiary 는 수혜자에게 최고 입찰가를 제시했다.
버전 개선 문제-재진입 공격
오른쪽은 해커 계약이고, hack_bid 는 이전 계약인 hack_bid 와 같습니다. 경매 계약의 bid 함수를 호출하여 경매에 참여하고, hack_withdraw 는 경매가 끝날 때 withdraw 함수를 호출하여 돈을 돌려받습니다. 문제는 오른쪽의 마지막 함수인 fallback 함수가 돈을 다시 한 번 가져갔다는 것이다.
Hack_withdraw 가 경매 계약의 withdraw 함수를 호출할 때 왼쪽에서 if(msg.sender) 까지 실행하면 해커 계약으로 이체되고 msg.sender 주소의 fallback 함수가 호출됩니다. msg.sender 는 해커입니다
해커 계약의 fallback 함수를 실행할 때 경매 함수의 withdraw 함수를 호출하여 돈을 인출합니다. 여기서 msg.sender 는 경매 계약입니다. 경매 계약이기 때문에 이 계약으로 돈을 넘기고 왼쪽 경매 계약은 if 로 다시 한 번 돈을 돌리기 시작했습니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), Northern Exposure (미국 TV 드라마)
해커 계약 계좌의 영영 조작 (왼쪽 아래) 은 이체 거래가 완료된 후에만 진행되지만, 앞의 이체 거래는 해커와의 재귀적 호출에 빠져 전혀 영영 뒤가 되지 않아 해커가 자신의 입찰가격에 따라 경매 계약에서 돈을 계속 인출하게 된다. 처음만 자신의 입찰이고, 다른 것은 모두 계약이다. (알버트 아인슈타인, Northern Exposure (미국 TV 드라마), Northern Exposure (미국 TV 드라마)
Msg.sender.call.value(amount): msg.sender 주소로 금액 이더넷 통화를 발송하고 msg.sender 주소의 fallback 함수를 호출합니다
이 재귀는
1) 경매 계약의 잔액이 부족하여 이런 이체문을 지원하지 않습니다.
2) 휘발유 요금이 부족합니다. 재귀적으로 호출할 때마다 휘발유 요금이 소모됩니다.
3) 호출 스택이 넘쳤습니다
오른쪽 하단 해커 계약의 팔백 함수는 경매 계약의 잔액이 이체를 지원하기에 충분하다고 판단했다. 현재 호출된 나머지 휘발유 msg.gas 는 6000 단위 이상, 호출 스택의 깊이가 500 을 넘지 않으면 또 한 차례 공격을 개시한다.
재진입 공격을 어떻게 해결합니까?
먼저 0 을 청산한 후 이체할 수 있습니다. 제 2 판의 오른쪽 표기법과 일치하며 이체가 실패하여 잔액에 회신할 수 있습니다.
Call.value 없이 이체해서 send 나 transfer 로 바꿀 수도 있습니다.
먼저 0 을 청산하고 이체하면, send 와 transfer 의 한 가지 특징은 이체할 때 과거 휘발유 요금이 2300 개밖에 안 되는 것으로, 접수된 계약을 다시 시작하게 하기에 충분하지 않아 log 를 쓰기에 충분하다는 것이다. (알버트 아인슈타인, Northern Exposure (미국 TV 드라마), 스포츠명언)
