Yes, Dan made a post about their decision to choose WASM--it boils down to performance, cross-compatibility, wide industrial support, and flexibility. Excerpt from post:
Web Assembly is an emerging industry standard backed by Microsoft,
Google, and Apple. The goal of this standard is to make it possible to
run untrusted high-performance code in your ...
While executing the contracts in the VM, it doesn't really matter what was the source language: be it C++ or Rust. It only cares about the compiled WASM being accepted by the WASM interpreter.
Yes, you can write Rust, but because there's no explicit support or work done towards supporting Rust, you'll probably need quite a bit of tweaking. Several months ...
WebAssembly is indeed the instruction format that the virtual machine understands.
The actual interaction between the eos library and the wasm binary is done through WebAssembly modules. Every contract thus has to export an apply function, which serves as the entrypoint. It can also import functions to interact with the eos environment. A small subset of ...
I had the same error, and filed a bug (which has been assigned).
A short-term fix supplied by someone, which seems to work: go into build/contracts, run make, return to top level and run the original build script again.
The Web Assembly Website has information on the potential security issues for both users and developers when coding in WASM.
With regards to arbitrary code execution in EOS, @confused00 points out that these bugs were fixed before the report was even published.
EOS has a very quick turn around for serious bugs. If a vulnerability is found it can be fixed ...
Based on the details you provided in the comments, I think the error might be coming from how you are compiling the code. You said you are running these commands:
eosiocpp -o mycontract.wasm *.cpp
eosiocpp -o mycontract.wast *.cpp
eosiocpp -g mycontract.abi mycontract.cpp
when you should actually be running these:
eosiocpp -o mycontract.wast ...
Is this CPU-billing-scheme still in use?
To the best of my knowledge, yes
Points 2. and 3.
My understanding of CPU billing works is as follows:
A BP receives your transaction, starts a timer, processes it as fast as they can, stops a timer.
The time they record is the CPU billing time that you get charged.
Therefore, the number of wasm instructions ...
All inputs are based on the shared data on a public ledger. There are no analog or non-deterministic input like the time of a day or random number generator.
Smart contract in EOS are developed in C++, then compiled into wasm code using eosiocpp (or eosio-cpp) and uploaded to the blockchain using cleos set contract. Why wasm? Read this post, basically for speed performances. Ethereum also seems to want to use wasm, there is a project called ewasm.
Theoretically, the final linking stage of the compiler pulls different wasm modules together, so you could include your own wasm code in a module and then link it at that stage.
However, this isn't supported by block.one and might not be possible at some future time.
If you succeed, please share the code and build structure that you used, it would be ...
According to official eos developer guide
It doesn't support solidity now. It only supports c++ but they have also mentioned that there are other languages which will be supported in the future.
Rust, Python, and Solidity will be supported in the future updates.
I think there are two things going on:
I've run into problems with Ninja and eosio.wasmsdk. Give make a shot instead of ninja.
Those options look like they're for compiling the compiler, not for compiling a smart contract. Can you build something like the exchange example (https://github.com/EOSIO/eosio.wasmsdk/tree/master/examples/exchange) without those ...
Theoretically C++ is the most efficient language, since it is the native language for wasm, no one thinks of writing assembly by hand.
Next are Rust and Go, these probably add some overhead since they provide additional help for the programmer. TypeScript would probably add the most overhead but it really depends on the use case.
There are not a lot of ...
There are currently no recommended tools for generating ABI automatically. However, there's an article in the documentation about how to write an ABI file yourself.
From the article:
As of v1.2.0, the eosio.wasmsdk was decoupled from the core
repository. This change has introduced an eosiocpp regression where
the legacy eosio-abigen is no longer ...
As EOS chooses a web assembly, the advantages that a web assembly can provide are all there.
The benefits of web assembly are outlined below.
The two most important reasons why eos chose a web assembly is that 'performance' and 'high-level language support'.
As EOS chooses a web assembly, it is possible to write a smart contract ...
The answer to this question is being documented here.
TL/DR: Getting the most basic functionality to work is very easy. You only need to export an apply(uint64, uint64, uint64) function in webassembly, which can be easily done in AssemblyScript.