内部传输链中的气体消耗

您不能超过hard_gas_limit_per_operation=400000.但是在将来的协议中,它可能会增加(例如,请参见"雅典"提案).

内部传输会消耗大量的气体.

首先,每次传输的固定费用为10000瓦斯.

第二,更重要的是,当合同被"解析"时,合同的整个code和storage将从Tezos数据库中读出(除了big_map).您根据读取的数据的二进制大小来支付费用.整个code也会被"解析",以提取合同的参数类型,并将其与期望的类型进行比较.这种情况至少发生在两个地方:

1. 当您在storage类型中(在storage之外)具有big_map时,将在运行脚本之前解析协定.
2. 当脚本执行CONTRACT p Michelson指令时,协定将被解析.

因此,这意味着为了将TRANSFER_TOKENS转换为脚本合约,您必须对其进行解析,并按照其代码和存储大小支付一定的费用.当该合同收到转移并加载执行时,将在目标脚本甚至开始运行之前再次 支付这笔费用以及更多费用.

(解析合同时,从数据库中读取storage完全是 .我们可以在以后的协议升级中轻松解决此问题-我们可以确实应该,它会导致非常令人惊讶的漏洞.使用code修复该问题将较不容易,但我希望有一天通过将代码分成数据库中的多个部分来解决此问题.当我们添加一流的入口点时,可能会发生这种情况.)

因此,减轻这种情况的一种方法是确保所涉及的每个合同都具有较小的代码和存储空间-除了big_map之外.您只有在GET(可能是UNPACK)时才为big_map的内容付费.

不幸的是,这似乎意味着,今天,写复杂合同的最佳方法(尤其是当它们是内部传输的目的地时)将使用big_map bytes bytes作为存储,并且将所有代码和存储放入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.