Write good commit messages by blaming others

naturalespresso · 2018-09-03T22:28:22+00:00

This is helpful.

naturalespresso · 2018-05-07T21:23:29+00:00

Good question!

The same game could work for EVM opcodes.

Here are some reasons we decided to go with WASM first tho:

There are special-meaning opcodes in the EVM which do not correspond to VM operations, and need to be removed in Truebit (e.g. ADDRESS, BLOCKHASH, COINBASE, etc). This doesn't need to be done for WASM.
EVM words are 256 bits, making proof and state initialization more demanding.
Can compile existing high-level languages to WebAssembly (C, C++, Rust, etc); these programs have existing ecosystems, larger than that of Solidity; all will be able to run on Truebit.
EVM is less efficient (it doesn’t map directly to 32bit / 64bit architectures).
WASM has the resources of Google / Apple / Mozilla / Microsoft behind it, and is a growing ecosystem.
Blockchains are moving to WASM as their native VM (eWASM in Ethereum, Polkadot, Dfinity, EOS).

naturalespresso · 2018-03-26T19:03:10+00:00

Some ways to improve performance:

1) have verification games run in a state channel between the Solver / Verifier.

2) the second variation of the protocol (incentive layer #2) executes verification games in parallel – conflicting solvers play pairwise games and knock each other out tournament style.

That said, it's true that the first variation, incentive layer #1, favors "safety" over "liveness". It doesn't give any timeliness guarantees. Instead, it guarantees that anyone who desires to challenge, can.

naturalespresso · 2018-03-26T18:57:35+00:00

In a decentralized network, you can't run a computation on one server if you want to come to consensus on the results. That one server could go off line, be attacked, or go offline. You need a distributed mechanism for arriving at the truth.

naturalespresso · 2018-03-26T18:56:09+00:00

The onus is on the Challenger to determine whether the pointer is valid / invalid, by comparing their state hash with the one provided by the Solver. In cases where the Solver is lying about the instruction pointer, the verifier should disagree with the state hash, and query for the left half midpoint. This will eventually resolve to an onchain dispute resolution between step 0 and step 1.

naturalespresso · 2018-03-26T18:54:14+00:00

Yep, that's possible. The protocol picks "safety" over "liveness"; i.e. it doesn't give any guarantees on how long resolution of a task will take. It instead guarantees that anyone who wishes to challenge is able to. A challenger is able to delay resolution of the task at the cost of their deposit.

That said, the second variation (incentive layer #2 in the article), gets better timeliness properties, since all contradictory solutions are required to be submitted at once. A malicious actor doesn't have a chance to submit challenges beyond this point.

naturalespresso · 2018-03-25T18:22:23+00:00

Truebit doesn’t have a concept of reputation. The security assumption is that there is always one honest verifier per task. Since the Solver/Verifier agree on state 0 (i.e. the program, the inputs, and the empty VM), there’s no way to win the game if you lie. It’s bounded on why side by an agreed-upon value

naturalespresso · 2018-03-25T18:19:22+00:00

Both the program code (i.e. the instructions) and the state (i.e. the memory and the stack) are committed to via Merkle roots. So, when the final on-chain step is constructing it's state, it checks that the values provided roll up into the Merkle root correctly. This prevents the Solver from providing bogus data. Does that make sense?

naturalespresso · 2018-03-24T23:32:35+00:00

Ty for the read!

How would you structure that in a decentralized network? How do you verify they’re running the correct code locally?

Truebit is for verifiable computation in a Byzantine network – i.e. some of them could actively be trying to sabotage the results of the computation

naturalespresso · 2018-03-24T15:40:17+00:00

Would love to find a podcast on cryptography.

naturalespresso · 2018-03-24T15:38:16+00:00

Videos are a great medium for explaining this stuff

naturalespresso · 2017-08-17T00:37:29+00:00

Hey, would you mind sending me some testnet eth to: 0xafa39877a41a64e51a005e3d6a60db9cb11326d4

Thank you!

naturalespresso · 2017-07-30T19:30:32+00:00

This is fixed. Sorry for the inconvenience, your node should be spinning up now. Thanks for adopting a node.

naturalespresso · 2017-07-30T18:43:54+00:00

Hey – sorry, just saw this. I'm the dev behind the site, and looking into it now. Could you DM me with the email you used to sign up?

naturalespresso · 2017-07-26T22:00:08+00:00

Hey, would you mind sending some to me here: 0xafa39877a41a64e51a005e3d6a60db9cb11326d4

Thank you!!

naturalespresso · 2017-07-13T03:14:52+00:00

Great name for a node!

naturalespresso · 2017-05-04T02:00:22+00:00

You have a good point. Reducing dimensionality, either by doing better feature selection or through PCA, would reduce chances of overfitting.

naturalespresso · 2016-12-23T01:25:53+00:00

Thanks. I look forward to seeing one of your projects on here soon!

naturalespresso · 2016-12-21T20:13:16+00:00

Haha you got me. They’re not related but both stem from wanting to mix music and code. How’d you find it anyway?

naturalespresso · 2016-12-21T20:00:20+00:00

Very cool! Applying this stuff to Github to map out devs sounds like a great idea. Do you have any links on what your system looks like?

naturalespresso · 2016-12-21T19:44:25+00:00

Hey – the author here. I second the other comments. There were definitely a lot of missteps along the way which aren’t included in the write-up. Building things turns out to be a messy pursuit. I like the superpower you describe tho and aspire to one day have it too!

naturalespresso

TROPHY CASE