by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Dec 12 2019 04:03
    mrsmkl edited as member
  • Dec 12 2019 04:03
    hswick edited as member
  • Dec 12 2019 04:03
    bloodstalker edited as member
  • Dec 12 2019 04:01
    mrsmkl edited as member
  • Dec 12 2019 03:54
    mrsmkl edited as member
  • Dec 12 2019 03:54
    mrsmkl edited as member
  • Dec 12 2019 03:53
    mrsmkl edited as member
  • Nov 08 2019 07:23

    teutsch on master

    Update README.md (compare)

  • Oct 03 2019 12:42
    mrsmkl unassigned #70
  • Oct 03 2019 06:56

    mrsmkl on rollback

    (compare)

  • Oct 03 2019 06:56

    mrsmkl on rollback2

    (compare)

  • Oct 03 2019 06:56

    mrsmkl on master

    (compare)

  • Oct 03 2019 06:56

    mrsmkl on master

    (compare)

  • Oct 03 2019 06:52

    mrsmkl on rollback2

    (compare)

  • Oct 02 2019 14:10

    mrsmkl on master

    (compare)

  • Oct 02 2019 14:09

    mrsmkl on master

    (compare)

  • Oct 02 2019 14:08

    mrsmkl on master

    (compare)

  • Oct 02 2019 14:07

    mrsmkl on two-layer-dispute

    (compare)

  • Oct 02 2019 06:35

    mrsmkl on v2gp

    (compare)

  • Oct 02 2019 06:35

    mrsmkl on readme-1

    (compare)

Jason Teutsch
@teutsch
Interactive coin offering
George Roman
@georgeroman
Hi everyone! I'm trying to run a WASM task compiled from Rust on TrueBit. I'm following the steps described in https://github.com/TrueBitFoundation/wasm-ports/tree/master/samples/scrypt. When running prepare.js on my js file (generated alongside the wasm file by compiling Rust to a wasm32-unknown-emscripten target), I get the following strange error: 'unknown import "wasi_unstable"."fd_fdstat_get"'. I've inspected the wat file obtained by running wasm2wat on the wasm file and it looks like there are 5 imports that use 'wasi_unstable' (instead of the usual 'env' used in the rest of the imports): fd_fdstat_get, environ_get, environ_sizes_get, fd_write, fd_close. Any ideas on why this is happening and how to go about solving the issue?
Sami Mäkelä
@mrsmkl
those imports keep changing, so you need to use an old version of emscripten, 1.37.36 is the one used in wasm-ports Dockerfile
well at least that is a starting point, you might need to install an old version of rust, too
George Roman
@georgeroman
I've been trying to work around that issue for a few days but haven't succeeded yet. Version 1.37.36 of Emscripten is not available for download anymore and the only way to use it would be to build that specific version of Emscripten from source. I've tried most recent versions of Emscripten that use the default WASM backend instead of the old asm.js (fastcomp) one and all use WASI imports. In the current state of the project, is it possible to add support for WASI imports in TrueBit's WASM interpreter?
I'll check if there is some place in the linker that has to be changed
Sami Mäkelä
@mrsmkl
maybe there wouldn't be many changes for that
anyway, if you use 1.37.36 , you also need an old version of rust, 1.25.0 seems to work
George Roman
@georgeroman
Thanks, I'll give it a try. Unfortunately, I can't use an older version of Rust as my code only compiles with Rust above 1.40.
George Roman
@georgeroman
I'm coming back with a new question. Once I added the functions in filesystem.c and transpiled the changed code to filesystem.wasm what would be the next step to have the linker find the newly added functions?
Sami Mäkelä
@mrsmkl
in theory, the script should just find them based on names
there also another thing that has probably changed, emscripten runtime used to have some setup done to the memory in the js runtime, so you if it still does that, you'll have to find out how it has modified the memory before executing the wasm file
George Roman
@georgeroman
I've managed to implement the required functions in filesystem.c and have them available at runtime. However, I'm now faced with another issue. Running the wasm file results in a 'resource exhaustion: stack underflow' error (at the point where the error occurs the value of the stack ptr is -21568). I suppose this happens due to not enough memory available. Is globals.json the right place to increase the memory limits? If yes, how exactly should I change that file?
George Roman
@georgeroman
I've just looked over TrueBit's wasm interpreter code and I think this is where the error is triggered (the negative stack_ptr is the issue): https://github.com/TrueBitFoundation/ocaml-offchain/blob/master/interpreter/merkle/mrun.ml#L1098.
George Roman
@georgeroman
One more question, mycode fails with yet another weird error if I don't provide a 'record.bin' attached file. What is the role of that file? (https://github.com/TrueBitFoundation/ocaml-offchain/blob/master/interpreter/filesystem.c#L174)
Sami Mäkelä
@mrsmkl
try running the v2 branches, and the latest filesystem.c should be at emscripten-module-wrapper repo
records.bin is deprecated, you shouldn't need it anymore
George Roman
@georgeroman
Thank you very much for all the help! Everything works fine on the v2 branches.
George Roman
@georgeroman
Ok, now that the code compiles and runs fine I have one more issue. I have attached one file 'output.data' to a simple program that only writes some data to that file. For some reason, consecutive calls to findFile and openFile (https://github.com/TrueBitFoundation/emscripten-module-wrapper/blob/master/filesystem.c#L120-L158) get different arguments (findFile gets the expected 'output.data' argument while openFile gets a weird 'stdostdout' argument). I assume that the memory portion holding the name of the file is being overwritten somehow. Any ideas on how to go about fixing this?
George Roman
@georgeroman
Sami Mäkelä
@mrsmkl
ok. check if filesystem.wasm has it's own memory, that might cause problems, also there can be some kind of stack pointers that get messed up
George Roman
@georgeroman
Are there any limits on the size of the file that can be read? I have a big file (10240 bytes) that for some reason is not fully read (only the first 8192 bytes are read, and the program exits afterwards) (https://github.com/TrueBitFoundation/emscripten-module-wrapper/blob/master/filesystem.c#L493).
George Roman
@georgeroman
Nevermind, exporting 'emscripten_memcpy_big' from 'filesystem.c' fixed this.
George Roman
@georgeroman
In truebit-os where can I change the default parameters of the VM, like --memory-size or --stack-size?
Zhao Yang
@zhaoyang626
Hi all. Is there any demo about federated learning with truebit?
Jason Teutsch
@teutsch
Welcome @zhaoyang626! What are you trying to build?
Zhao Yang
@zhaoyang626
I am trying to combine FL and blockchain. FedAvg algorithm may cost too much using smart contract. I want to explore an off-chain solution.
komalklr
@komalklr
Hi everyone..I am trying to wrap a rust file in emscripten-module-wrapper in truebit-toolchain docker provided.
That doesn't seem to be working. Is there any alternate to that. I tried building from source but the same error coming.
Sami Mäkelä
@mrsmkl
try using the latest version from here https://github.com/mrsmkl/truebit-new
but using rust might have trouble, for example you might have to use an older version of rust compiler
Sami Mäkelä
@mrsmkl
anyway I guess that error is about IPFS not being started, I'll have to add better error message
komalklr
@komalklr
Ipfs daemon is on. Exact error I got is Assertion failed :undefined export.
Jason Teutsch
@teutsch
Do you get this same error when running from the Docker container? mrsmkl/wasm-ports:20-05-12
komalklr
@komalklr
Same error on this image also.
I am getting the error undefined export .
Is there something I am missing here.I am using rust version 1.25.0
komalklr
@komalklr
Out folder is created but generating info is giving this error
Sami Mäkelä
@mrsmkl
the docker images won't work with rust because they use llvm wasm backend, but the old versions of rust required the asm.js backend
Jason Teutsch
@teutsch
@georgeroman Which pipeline did you use for your Rust task?
George Roman
@georgeroman
@komalklr I had the same error when writing a Rust task to run on Truebit. The issue is that, for newer versions of Rust, the wasm32-unknown-emscripten target will generate WASM that depends on WASI exports. At the moment, Truebit's WASM interpreter doesn't support WASI, so those exports will be reported as undefined. I've managed to overcome this by manually changing the WASI exports in the WASM file so that they point to custom made implementations (provided in filesystem.c from emscripten-module-wrapper). This is a very hacky way to solve the issue, but it works. Here is a a fork of emscripten-module-wrapper that I've used for this: https://github.com/georgeroman/emscripten-module-wrapper. I'll update it so that you can find in the README all necessary info to have your task compiled and runnable on Truebit.
komalklr
@komalklr
Thanks :) @georgeroman
George Roman
@georgeroman
Just added the instructions in the README, feel free to ping me if you get into any issue or something doesn't work out the way it should.
komalklr
@komalklr
Hii...I am getting out of gas error in truebit-os while task submitting..error: TASK SUBMITTER: Cannot create task: Error: VM Exception while processing transaction: out of gas
Jason Teutsch
@teutsch
@komalklr I believe @georgeroman had a fix for this in depositHelper.js: { from: account, gasPrice: web3.gp } -> { from: account, gas: 3000000, gasPrice: web3.gp }
komalklr
@komalklr
Thanks @teutsch , he gave me the solution.
Aaron Foster
@pythonpete32
hey guys, I have a problem and I'm wondering if Truebit can help. essentially, I want to know the state of a vanilla ERC20 at a particular block height, the results need to be available on-chain and be as cheap as possible. for context, voting in an Aragon DAO requires a MiniMe token. this is a regular ERC20 token that includes logic that takes a snapshot of the contract at a block height. This prevents double voting, ie. voting and then transferring the tokens to another account and voting again. It is possible to lock tokens a regular ERC20 in a contract for the duration of a vote, however, this increases friction and is unpractical for most projects with existing tokens. Questions:
How would I submit a task to Truebit requesting the state of a token contract at a particular heigh?
How much would this cost?
Jason Teutsch
@teutsch

Hey @pythonpete32, it's good to hear from you! The challenge here, of course, is to reach a global consensus on the ERC20 token contract at the desired block. How can one distinguish between an arbitrary sequence of n blocks representing the "true" Ethereum blockchain and an n-block sequence that ends with an orphaned block? Let's first consider a simpler case where n is close to the current length of the Ethereum blockchain. The most recent 256 blocks are readable by smart contracts, so in this case consensus on the EVM state should be possible. Moreover, one can record it into permanent smart contract storage. With this record on file, a Merkle proof should suffice to prove an account balance or total supply, and one might appeal to Truebit for more complex statistics. So I guess the answer depends on what exactly you're trying to do?

If you were to build the ERC-20 from scratch (which it seems you wish to avoid), I recommend checking out Open Zeppelin's slick, new, "mini-me"-inspired template:

https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20Snapshot.sol