Constructor Documentation

[sxysun-zz]

When I was navigating the decompiled wasm code from the Token example, I found that there is no multiplexer structure in the main function for dealing with appropriate calldata, which according to the eWasm team (ewasm/design#159) should be present. I wonder if you guys are using the standard ABI for ETH 1.0 or some other mechanisms?

[hydai]

The wasm code generated by SOLL is ready to deploy on the chain, which means the original Token contract is compiled into wasm binary format and is wrapped by a ewasm deployer (See the bottom section).

SOLL uses the standard ABI for ETH 1.0 on runtime wasm bytecode. You can find the runtime wasm bytecode in your first decompiled wasm code. It will be located in the data section.

Or, using soll -runtime token.sol to get the runtime wasm bytecode for Token contract, and you get the multiplexer structure there.

[sxysun-zz]

I see, but the ewasm deployer currently is embedded in SOLL right? In the sense that there is no sentinel contract as described in the eWasm docs.
And what exactly is the difference between running with and without "runtime" option, I understand now that one has the multiplexer and the other do not, it also have more functions, but they both adopt ECI (which means it is essentially ewasm deployable contract), so are there any other differences?

btw: how did you guys handle ewasm-precompiles? Like SHA1 SHA2 SHA3 operations that are native to EVM and now wasm

[hydai]

I see, but the ewasm deployer currently is embedded in SOLL right? In the sense that there is no sentinel contract as described in the eWasm docs.
And what exactly is the difference between running with and without "runtime" option, I understand now that one has the multiplexer and the other do not, it also have more functions, but they both adopt ECI (which means it is essentially ewasm deployable contract), so are there any other differences?

Yes, the ewasm deployer is embedded in SOLL just like Solidity compiler does. When users want to deploy a smart contract on the chain, the deployed code should a deployer which contains its real runtime bytecode. You can use solc -bin and solc -bin-runtime to get the deployed version and the runtime version.

When users submit a transaction to deploy a smart contract, they have to use the deployment bytecode. When the ethereum client receives the deployment bytecode, it will (i) execute this contract to set up some initial value in this contract's storage and (ii) put the runtime bytecode into the contract's code section.
Next time, when users want to interact with this contract, the calldata will be handled by the runtime bytecode.

Both the deployment and runtime bytecode are executed by ewasm VM, that's why they both adopt ECI.

btw: how did you guys handle ewasm-precompiles? Like SHA1 SHA2 SHA3 operations that are native to EVM and now wasm

The precompiles will be a list of smart contract addresses. When we have to call the precompiles, we just make a function call like call(precompiles_address, args...).

[sxysun-zz]

I understand that in eWasm design doc it lists all the system contracts, but for now we cannot exactly use them since they have not been deployed. So for SOLL contracts we cannot test the SHA1 etc,. operations, which is also described in SOLL's developers guide that keccak256 such is not implemented. But if so, how did your example 0-0-3 work? Since it uses balances[msg.sender] = sub(balances[msg.sender], amount);, a mapping which needs hashing.

btw: do you know which file is the "ewasm deployer" embedded in SOLL?

[hydai]

The keccak256 is defined but not implemented on ethereum official ewasm testnet. So we use sha2-256 instead.
SOLL has an option -deploy to switch the keccak256/sha2-256. Please refer to our 0.0.6 release note.

The official testnet is down since we released SOLL 0.1.0. So we also provide a ewasm testnet with out own devchain toolkit. You can follow our README to test the ewasm contract.

btw: do you know which file is the "ewasm deployer" embedded in SOLL?

If you mean how we implement ewasm deployer, you can check the function emitContractConstructorDecl.
And we refer to (i) the implementation from solidity project about the smart contract deployer and (ii) ewasm deployer from the above link.

[hydai]

Thanks for your report, I am closing this one now, we will add a new page to describe the constructor documentation soon :-)

If you have other questions, please open a new issue and let us know.

[hydai]

A documentation update is needed to close this project. Reopen until the constructor documentation is finished.