一連の内部移動におけるガス消費量

hard_gas_limit_per_operation=400000を超えることはできません.ただし、将来のプロトコルではおそらく増加するでしょう(たとえば、" Athens "の提案).

内部転送は大量のガスを消費する可能性があります.

まず、転送ごとに10000ガスの固定費がかかります.

次に、さらに重要なことに、コントラクトが「解析」されると、コントラクトの code と storage 全体がTezosデータベースから読み取られます(big_map ).読み取ったデータのバイナリサイズに応じてガスを支払います.コントラクトのパラメータタイプを引き出し、期待されるタイプと比較するために、 code 全体も「解析」されます.これは少なくとも2つの場所で発生します:

1. storage タイプ(big_map の外)に Contractp がある場合、スクリプトが実行される前にコントラクトが解析されます.
2. スクリプトが CONTRACTp Michelson命令を実行すると、コントラクトが解析されます.

つまり、スクリプト化されたコントラクトにTRANSFER_TOKENSを転送するには、コードとストレージサイズに比例したガスを支払って解析する必要があるということです.そのコントラクトが転送を受け取り、実行するためにロードされると、宛先スクリプトが実行を開始する前に、このコストなどが再度支払われます.

(契約を解析するときに storage をデータベースから読み取る必要は完全にありません.将来のプロトコルアップグレードでこれを簡単に修正できます. code の問題を修正するのは簡単ではありませんが、データベース内でコードをいくつかの部分に分割することで、いつか修正されると思います.おそらくこれは、ファーストクラスのエントリポイントを追加したときに発生する可能性があります.)

したがって、これを軽減する1つの方法は、big_mapを除いて、関連するすべてのコントラクトに小さなコードとストレージがあることを確認することです.big_mapのコンテンツを GET (およびおそらく UNPACK )する場合にのみ、ガスを支払います.

残念ながら、これは、今日、複雑なコントラクトを作成するための最適な方法(特に、内部転送の宛先である場合)は、ストレージとしてbig_mapbytesbytes を使用することを意味しているようです. UNPACKを使用して、すべてのコードとストレージをbig_map内に配置し、オンデマンドでロードします.

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.