내부 전송 체인에서 가스 소비

hard_gas_limit_per_operation=400000을 초과 할 수 없습니다.하지만 향후 프로토콜에서 증가 할 것입니다 (예 : "아테네 "제안 ).

내부 전송은 많은 가스를 소모 할 수 있습니다.

먼저,전송 당 가스 10,000 개의 고정 비용이 있습니다.

둘째,더 중요한 것은 계약이 '파싱'될 때 계약의 전체 code 및 storage 가 Tezos 데이터베이스에서 읽혀집니다 (big_map ). 읽은 데이터의 바이너리 크기에 따라 가스를 지불합니다. 계약의 매개 변수 유형을 가져 와서 예상 유형과 비교하기 위해 전체 code 도 '파싱'됩니다. 이는 최소한 두 곳에서 발생합니다.

1. storage 유형 (big_map 외부)에 contractp 가있는 경우 스크립트가 실행되기 전에 계약이 파싱됩니다.
2. 스크립트가 CONTRACTp Michelson 명령어를 실행하면 계약이 파싱됩니다.

즉,TRANSFER_TOKENS를 스크립팅 된 계약으로 전송하려면 코드와 저장소 크기에 비례하여 가스를 지불하고 구문 분석해야합니다. 해당 계약이 전송을 받고 실행되도록로드되면 대상 스크립트가 실행되기 전에이 비용 등이 다시 지불됩니다.

(계약을 구문 분석 할 때 데이터베이스에서 저장소 를 읽는 것은 완전히 불필요합니다. 향후 프로토콜 업그레이드에서이 문제를 사소하게 수정할 수 있습니다. 정말 놀라운 취약점으로 이어질 수 있습니다. code 로 문제를 해결하는 것은 쉽지 않지만 언젠가는 코드를 데이터베이스의 여러 조각으로 분할하여 수정 될 것으로 예상합니다. 일류 진입 점을 추가하면 이런 일이 발생할 수 있습니다.)

따라서이를 완화하는 한 가지 방법은 관련된 모든 계약에big_map을 제외하고 작은 코드와 저장소를 포함하도록하는 것입니다.big_map의 콘텐츠를 GET (또는 UNPACK ) 할 때만 가스를 지불합니다.

안타깝게도 오늘날 복잡한 계약을 작성하는 가장 최적의 방법 (특히 내부 전송 대상인 경우)은 big_mapbytes 바이트 를 저장소로 사용하는 것입니다. 모든 코드와 저장소를big_map 안에 넣고 UNPACK을 사용하여 요청시로드합니다.

You cannot exceed the hard_gas_limit_per_operation = 400000. It will probably be increased in future protocols, though (see e.g. the "Athens" proposals).

Internal transfers can use up a lot of gas.

First, there is a fixed cost of 10000 gas per transfer.

Second, and more importantly, when a contract is 'parsed', the contract's entire code and storage are read out of the Tezos database (except for the big_map). You pay gas according the binary size of the data read. The entire code is also 'parsed', in order to pull out the parameter type of the contract, and compare it to the expected type. This happens in at least two places:

1. When you have contract p in your storage type (outside of the big_map), the contract will be parsed before your script runs.
2. When your script executes the CONTRACT p Michelson instruction, the contract will be parsed.

So, this means that in order to TRANSFER_TOKENS to a scripted contract, you must parse it, paying gas proportional to its code and storage size. When that contract receives the transfer and is loaded to be executed, this cost, and more, will be paid again, before the destination script even starts running.

(It is completely unnecessary for the storage to be read from the database when parsing a contract. We could fix this trivially in a future protocol upgrade -- and we really should, it can lead to very surprising vulnerabilities. It will be less easy to fix the problem with code, but I expect it will be fixed someday, by splitting the code into several pieces in the database. Maybe this can happen when we add first-class entry points.)

So, one way to mitigate this is to make sure that every contract involved has small code and storage -- except for the big_map. You only pay gas for the contents of the big_map when you GET (and maybe UNPACK) them.

Unfortunately, this seems to mean that, today, the most optimal way to write complex contracts (especially when they are the destination for internal transfers) will be to use big_map bytes bytes as storage, and to put all the code and storage inside the big_map, loading it on demand, using UNPACK.