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 ...
At that point you posted this question, you need to add max_net_usage to eosio.imports, but now eosio_wasm_import attribute can do same thing.
Add __attribute__((eosio_wasm_import)) before function declaration:
diff --git a/contracts/eosiolib/transaction.h b/contracts/eosiolib/transaction.h
index bb29f159a..f7d2654c4 100644
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 ...
a few things to consider:
it is not advisable to compile on your servers. you need tbe full blown dev environment to be set up correctly (all dependencies) in order to compile successfuly; when eosio-ccp was reported as hanging in the past it was because there was some dependencies missing or not version aligned (clang, submodules, etc). if you try to ...
Probably not. A contract loaded by a node is just a block of bytecode that's already in RAM. When you execute an action on a contract, there will be a lookup operation that will find the RAM address within the bytecode where the invoked action starts. Since the CPU jumps right into the point of interest, it doesn't matter what's the total size of the ...
It says there is (likely) no file named hello.cpp in your /home/corey/eos directory.
Check the previous steps in the tutorial.
Find the step which was supposed to put this file there.
Find out what happened instead.
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 ...
I couldn't make that happen either but I did make this work:
std::string s("limit: 686.97");
float limit = atoi(s.c_str());
printf("limit [%f]\n", limit);
* Edit I *
of course, that gets us to integer. sadly the atof is not available, so I think counting the number of digits in the string, removing the dot, converting to an integer and then dividing by ...
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 ...
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.