For example, Alice may run her transfer from her alice account to the bob account in the simulated node and determine that the only scopes required are {alice, bob} since the bob account already has a currency balance. But between broadcasting her transfer transaction and having it processed by a block producer, Bob may have sent his entire currency balance to someone else. If the currency contract was designed to free up database objects (for the sake of reclaiming memory) if an account's balance went to 0, then the bob account would not have a currency balance by the time Alice's transfer transaction was processed. Then when Alice's transfer transaction was actually being processed, it would be rejected because EOS.IO would determine that the memory usage of the currency contract needed to increase and yet the transaction had not declared currency as part of the scope.
例如,Alice可能会将她的Alice帐户转移到模拟节点中Bob的帐户,并确定{Alice, Bob}成立,唯一的要求是Bob帐户上有余额。但是,在广播她的转账交易并由一个区块打包的时候,Bob可能已经将他的全部余额转给别人了。如果货币合约设计为释放数据库对象(为了回收内存),账户的余额变为0,那在Alice转账交易完成后,Bob账户上将没有余额。到了Alice的转账交易实际上正在处理中的时候,它将会被拒绝。因为EOS.IO确定了合同的内存使用内容需要增加,但交易没有收到currency,这会成为其中一部分的信息。
Perhaps the currency contract designer will choose to not remove database objects even if an account's balance goes to 0. In this case the required scope determined by the simulated node may be over-conservative (requiring the currency when it was actually not necessary by the time the transaction was processed), but it would be far less likely to lead to the poor user-experience of having a broadcast transaction unexpectedly fail due to missing scopes. So, in that case the currency contract designer would trade better user-experience forincreased memory usage(and therefore more EOS tokens locked).
也许货币合约设计者在账户的余额变为0的情况下,也不选择删除数据库对象,这时模拟节点需要确定的范围可能过于保守(要求currency在不是真的有必要的时候处理交易),但是由于范围缩小,让广播失败而引起差的用户体验反馈将会大大减少。因此,在这种情况下,货币合约设计者会迭代出更好的用户体验以增加内存使用量(因此锁定更多的EOS代币)。
But the point is that this design of database memory usage limits requires contract developers to make these sorts of trade-offs. Also, the previous example only looked at a currency contract. Other contracts may have more difficulty avoiding memory usage changes with most of their transactions. For example, it is highly unlikely that most transactions for an exchange contract will lead to no net change in memory usage (bid/asks need to be created and zero or more of existing bids/asks may need to be removed as orders are filled). In the case of an exchange contract, this design adds no additional overhead because all the transactions require the exchange account in the scope anyway (bids/asks are stored within the database of the exchange account). But there may be many other contracts we have not thought of that will be burdened with much less concurrency (and thus less transaction throughput) because of this design of database memory usage limits.
但重要的是,这种数据库内存使用限制的设计,要求合同开发者需要权衡这些问题。另外,前面的示例只能查看货币合约,其他合约避免可能在大部分交易中的内存使用变化时会遇到更多困难。例如,在交易合约中的大多数交易,都极不可能让内存使用情况没有变化(需要创建出价/询价,当订单被填满时,可能需要删除现有的出价/询价) 。在交易合同的情况下,这种设计不会增加额外的开销,因为所有的交易都需要交易账户在其数据库中(出价/询价将会被存储在交易账户的数据库中)。但是,由于这种数据库内存使用限制的设计,可能会有许多其他我们没有想到的合约会被更少的并发性(以及更少的交易吞吐量)所拖累。
(本文未完待续)
本文链接:https://github.com/EOSIO/eos/issues/353
翻译：Lochaiching
校正：Sheldon
免责声明：本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时，应及时向本网站提出书面权利通知或不实情况说明，并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后，将会依法尽快联系相关文章源头核实，沟通删除相关内容或断开相关链接。
