Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Apr 26 19:11
    hswick removed as member
  • Apr 26 19:11
    hswick removed as member
  • Oct 25 2020 17:32

    teutsch on master

    update (compare)

  • 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)

James Seibel
@seibelj
Now, my questions are as follows:
1) Memory is unbounded, which is what I assume "program state" consists of. How can the entire state of memory at E - 1 and E be loaded into the blockchain? Couldn't this be enormous?
2) If the program state instead consists only of bounded registers, if a WASM instruction requires fetching data from memory, would the Ethereum miners need the entire state of program memory accessible? And how?
3) If the program is stored in IPFS rather than on the blockchain, how does an Ethereum miner load in that program and jump to that line? Could this DDOS the Ethereum network if the program is off-chain in IPFS and an enormously large program file?
Thanks in advance for your time, I know it is valuable.
Sami Mäkelä
@mrsmkl
the solver just has to send a merkle proof to Ethereum for the memory location that is modified by the step, so it works similarly to light clients
James Seibel
@seibelj
I think I'm confused by the actual computation performed on-chain. I now understand that what is submitted is not the actual memory contents, but rather merkle path to the machine state. How do the Ethereum miners do this (from the white paper): "Finally, using this information and the original task code (which existed on the blockchain prior to the verification game), the Judges check the computational step at time e and rule whether the challenge was justified."
They don't have the actual memory, they only have merkle paths. The WASM operand must modify state. If the blockchain doesn't actually have the state, just merkle paths, how can it do the operation?
And also, if program in IPFS, how do they fetch the operation?
Sami Mäkelä
@mrsmkl
the merkle proofs include the needed state cells, and the judges can easily compute the new merkle roots. notice that each step just modifies few state cells
there is a binary merkle root for the WASM file, IPFS hash is just a hint
James Seibel
@seibelj
OK, so the merkle path includes the leafs containing the state data itself that is modified by the instruction.
Finally, the merkle path and leaf containing the program instruction is also submitted by the solver? So the judge now has the actual relevant state at E - 1 and E, can verify that its accurate based on the state merkle root, the actual instruction from the merkel leaf and also verified by merkle root of the program, and using a TrueBit smart contract containing an implementation of WASM virtual machine, can actually execute the instruction. This is correct?
Sami Mäkelä
@mrsmkl
yeah
James Seibel
@seibelj
One more question. The reason that the solver doesn't just submit a proof with no work, and the verifier doesn't just say it's true, is that even if the majority solvers and verifiers are the same person, a single honest verifier can join and choose any and all tasks to verify (there is no lottery to determine who verifies what), so if this collusion was happening some enterprising verifier would quickly make money. Is this right?
Sami Mäkelä
@mrsmkl
yes, seems correct
Jason Teutsch
@teutsch
The incentive to verify has little to do with whether the Solver actually does work or not. Verifiers are just looking for "forced errors."
James Seibel
@seibelj
The verifier also wins when the error is just a mistake right (not the forced error)? I am not super deep into the game-theoretic underpinnings of the protocol but I do trust that all the major attack vectors have been thought through.
By the way, thanks so much for your time answering, I am super impressed with this project, I am going to be following it closely and experimenting. So cool I get to talk to you guys directly
Jason Teutsch
@teutsch
Verifiers might profit from finding "real" Solver mistakes, however, since we don't expect "real" mistakes to actually occur, they do not factor into the incentive structure. Whether or not "real" mistakes occur, the Verifier still has an incentive to participate.
It's great to have you here -- thanks for your questions! Are you building something with Truebit?
James Seibel
@seibelj
I am going to write an article similar to how I did for MakerDAO https://medium.com/@james_3093/the-dai-stablecoin-is-a-game-changer-for-ethereum-and-the-entire-cryptocurrency-ecosystem-13fb412d1e75 which got a lot of attention. When I see a super cool crypto project I dive deep. This one definitely needs to be understood in a significant way by a larger audience, and I hope I can do it justice
Jason Teutsch
@teutsch
Nice article! We'd love one on Truebit :) I'd be happy to discuss on a call if that would be helpful.
James Seibel
@seibelj
Sure! I will PM you
Moshe Praver
@mpraver1_twitter
Curious what the community thinks about this design pattern. We remove forced errors and instead rely on coordination between what would be the solver/verifier https://link.medium.com/LwIhh09vpS
Jason Teutsch
@teutsch
@mpraver1_twitter Why not just outright post the output in the first place if the applicant is going to reveal her secret later anyway?
Moshe Praver
@mpraver1_twitter
We need the verifier to derive the secret independently. If they are able to do so, this implies the hint:secret pair is valid.
Jason Teutsch
@teutsch
What do you assume about the attacker and the verifier selection? There could exist an incentive to pool verifier identities together in order to (errantly) pass verification.
Moshe Praver
@mpraver1_twitter
Yes - the cost of that attack is dependent on the ratio of “honest verifiers” to “dishonest verifiers”.
Moshe Praver
@mpraver1_twitter
We can also make this attack exponentially more costly by increasing the number of verifiers for each task.
Jason Teutsch
@teutsch
Does the protocol guarantee that the ratio of "honest" to "dishonest" verifiers remains constant over time?
Moshe Praver
@mpraver1_twitter
We can't know if a verifier will be dishonest. We can try to bootstrap the network by only making tokens initially available to well-intentioned verifiers. However, a malicious actor could try to accumulate enough tokens to pull off the attack.
The protocol can only ensure that such an attack would be very costly to pull off.
imTyrant
@imTyrant
Hi, @mrsmkl , sorry for bother you again... Recently I found that libpbc didn't meet my needs because the curves it supports are not used by ETH. Thus, I have to use another library published in https://github.com/herumi/ate-pairing. In the beginning, the emmake make command reports error: unknown FP unit 'sse', and I found a flag in the Makefile causes this. So, I delete the flag, and rebuild the code. And it reports following error. I personally think it not caused by the deleted flag. it looks like the compiler cannot find 64-bit version head file, and, instead, using 32-bit head file.
image.png
Sami Mäkelä
@mrsmkl
hmm, wasm cannot have 64-bit memory, so using -m64 flag probably won't work
Sami Mäkelä
@mrsmkl
anyway, it seems that the library generates x86_64 asm at runtime, so perhaps try libff instead
imTyrant
@imTyrant
@mrsmkl I download the libff, find that it also depends on ate-pairing. And I check the script libff.sh in https://github.com/TrueBitFoundation/wasm-ports/blob/master/libff.sh, however, the script doesn't download the dependents... like running git submodule init && git submodule update. So the script ignore this command....
And I replace the flag -m64 by -m32 in ate-pairing, the error is following.
image.png
Sami Mäkelä
@mrsmkl
libff has also another implementation for bn128, see https://github.com/scipr-lab/libff#elliptic-curve-choices
imTyrant
@imTyrant
Hi @mrsmkl , I test libff installed in docker by the code provided in https://github.com/scipr-lab/libff/blob/f2067162520f91438b44e71a2cab2362f1c3cab4/libff/algebra/curves/tests/test_bilinearity.cpp, with the command: em++ test.cpp -s WASM=1 -lgmp -lff -I $EMSCRIPTEN/sysytem/include -std=c++11 -o test.js. When I use node run the test.js, it returns following result...
image.png
What does this error mean?
Sami Mäkelä
@mrsmkl
I guess exception handling might cause problems with emscripten
but the problem is that profiling code calls some weird functions, if they are disabled, it works
Sami Mäkelä
@mrsmkl
I updated the script for libff at wasm-ports
imTyrant
@imTyrant
Oh! Thank you very much! I'll try the new script!
Bruno Barroca
@githubbrunob
cheers
imTyrant
@imTyrant
Hi, guys. How can I know how many TRUs a task needs to consume after it has been executed?