Max Zaver

I don't think that blockchain functions map well to the standard WASI modules, like core and processes, and I suggest we keep all of them in wasi-smart-contract or wasi-blockchain module....

> This proposal would support most existing smart contract platforms including those with a synchronous RPC model (e.g. Ethereum, EOS) and those with asynchronous cross-shard RPCs (e.g, Near). To clarify,...

We just need to be able to iterate over the state of the given solidity contract, we can do it by associating each contract with a vector, which will create...

Also, this is super suboptimal: https://github.com/near/near-evm/blob/master/src/lib.rs#L140 They are passing bytecode as hex and then parse it, basically they operate with hex everywhere, which is a large overhead.

Also, evm should probably be not using JSON for input/output, but should be using borsh, since it is all blobs of bytes.

@SkidanovAlex @evgenykuzyakov Actually we need to double check how contract removal works in Solidity, it might be the case the contract's destructor code is fully responsible for cleaning up the...

This does not sound like a host function, but rather a specific use case that is handled by the runtime when account is created. Also, why not stake instead of...

Expanding on (7) I suggest the following: We add two changes: * Have two storage prices: fixed price per account, and price per byte of the contract state; * Limit...

Re @mfornet > Regarding the approach from Max to put a hard limit on the contract size, Evgeny pointed out that someone can spent enough NEAR to fill the full...

> > Unfortunately, there is no incentive for users not to set too high prepaid gas, since we reimburse all unused gas. Which means people can fill in blocks with...