casper: betting on propositions? Mercury design footnote?

[dckc]

Are we betting on propositions in Mercury? Here's hoping for time to pore over the code and find relevant specs:

Unlike Ethereum’s betting on a whole blocks, RChain’s betting is on logical propositions. A proposition is a set of statements about the blockchain, for example: which transactions (i.e. proposed state transitions) must be included, in which order, which transactions should not be included, or other properties. A concrete example of a proposition is: “transaction t should occur before transaction s” and “transaction r should not be included”. For more information, see the draft specification Logic for Betting – On Betting on Propositions.

https://rchain-architecture.readthedocs.io/en/latest/execution_model/consensus_protocol.html

[dckc]

I spent most of this afternoon studying the state of the art.

some pointers:

• Core with list of tech specs:
  • RChain consensus specification - good top level requirements; largely corresponds with implementation
  • cites pretty good slides: The RChain Blockchain Structure
  • RChain Validator Economics - rough / scribbly
• "Use the Source, Luke!": Validate.scala, MultiParentCasperImpl.scala, CasperMessage.proto
• RHOL-457 Slashing & Ejection conditions Epic

Raw notes from #infrastructure:

1:17 PM] dckc:: @KentShikama : is the argument behind "the best you can do as an attacker under an asynchronous setting in Casper is to stall the network" written up anywhere? some of us are working on tidying up the arch doc, but it has very little to say about economic security. (unless I'm forgetting)
[1:22 PM] dckc:: _re-reads execution_model/consensusprotocol.html ...
[1:23 PM] dckc:: #37
GitHub
betting on propositions? Mercury design footnote? · Issue #37 · ...
Are we betting on propositions in Mercury? Here's hoping for time to pore over the code and find relevant specs: Unlike Ethereum’s betting on a whole blocks, RChain’s betting is on logical prop...

[1:23 PM] Kent:: So imagine you have 99% of the weight ; if you never propose a block, then the protocol can't ever finalize blocks (somewhat obviously).
[1:23 PM] Kent:: Now for equivocations...
[1:24 PM] dckc:: I'm not asking for a one-line-at-a-time explanation. I'm asking if it's documented somewhere.
[1:25 PM] dckc:: IIRC, Greg said in a recent call that the core team is working against specs that would be sufficient for another team to build an interoperable implementation. I haven't seen such a spec for Casper lately... certainly not one that documents the economic security properties.
[1:25 PM] Kent:: Imagine if someone with 99% of the weight equivocates. You can still slash them as long as they haven't unbonded. They can choose to stall but then that is stalling not equivocating.
[1:26 PM] Kent:: So that ends the explanation.
[1:26 PM] Kent:: It doesn't require a write up imo.
[1:26 PM] Kent:: Maybe for a formal proof yes.
[1:27 PM] dckc:: is there any Casper spec you have been coding against?
[1:27 PM] Kent:: CasperTFG mostly
[1:27 PM] dckc:: CasperTFG tells you what bytes go in a block?
[1:27 PM] Kent:: The paper that Vlad wrote
[1:28 PM] Kent:: Casper is agnostic about what goes into a block
[1:28 PM] Kent:: "contents"
[1:28 PM] Kent:: Ok it doesn't specify which bytes are for the justification, parents, etc
[1:29 PM] dckc:: grumble. The section of the arch doc that talks about betting on propositions is called "Casper Consensus Algorithm".
[1:29 PM] Kent:: But that is all in the protos
[1:29 PM] Kent:: Oh that is totally outdated
[1:29 PM] dckc:: yes, that's what I'm working on.
[1:29 PM] Kent:: There is no "betting" of any kind
[1:30 PM] dckc:: one approach to updating the arch doc is to add annotations to say "the current design is actually this thing over here"
[1:30 PM] dckc:: we added one blanket "see developer.rchain.coop" at the top https://rchain-architecture.readthedocs.io/en/latest/index.html
[1:30 PM] dckc:: but I'd like to add some in specific sections
[1:31 PM] dckc:: the protos specify things to a certain level, but I'm pretty sure they don't completely specify which blocks should be accepted and which should not
[1:32 PM] dckc:: is there some documentation with words like "parents" and "justifications" and such?
[1:32 PM] dckc:: searches the wiki...
[1:33 PM] Kent:: Validate.scala and the protos will probably answer most of your questions. I've been meaning to write it up for a while but I kind of want to do it at once at the end when we get cost accounting down
[1:33 PM] dckc:: "RHOL-283 Define rules around Slashing ... Done when: ... We have a document outlining this."
[1:34 PM] dckc:: you did write something I'm pretty sure...
[1:36 PM] dckc:: https://rchain.atlassian.net/wiki/spaces/CORE/pages/412024951/RChain+consensus+specification
[1:36 PM] Kent:: Oh yeah what I wrote can be inferred from the method signatures
[1:36 PM] Kent:: Yeah beware of that document too. It is more updated than the architecture docs though.
[1:37 PM] dckc:: so "Use the Source, Luke!" is the real state-of-the-art
[1:41 PM] dckc:: no betting? " In essence a validator says 'I'm betting on this proposed block because it has the most weight' or 'I'm NOT betting on this proposed block because this other block has more weight'."
[1:44 PM] dckc:: The slides cited under Scoring in action... is that from Boulder? (a date on the title slide would be nice)
[1:44 PM] dckc:: @JoshyOrndorff: are you available to study this part of the architecture just now?
[1:52 PM] dckc:: Validate.scala is just 633 lines. kinda dense, but at least not long.
[1:54 PM] dckc:: is there a sort of main method in object Validate, @kent:
[1:54 PM] Kent:: Nope
[1:54 PM] Kent:: It is just a lot of functions
[1:54 PM] Kent:: But they are all total functions
[1:55 PM] Kent:: Well besides the effects such a Log but you can mostly ignore those
[1:55 PM] dckc:: is there any one function in coop.rchain.casper that judges whether to accept a block? (likewise: a definition of finalized block?)
[2:01 PM] dckc:: slides say "Block = past state + current state + diff". I wonder if that's still the case.
[2:02 PM] dckc:: if we read "past state" as parentsHashList and diff as deploys, then it seems to match the protos
[2:05 PM] dckc:: "The PoS Contract ... Handles bonding, unbonding, slashing and rewards distribution" slashing? let's see...
[2:06 PM] dckc:: slash doesn't occur in MakePoS.rho. hm.
[2:35 PM] dckc:: addBlock (and internalAddBlock) in coop/rchain/casper/MultiParentCasperImpl.scala seem to be the place where blocks are judged.
[2:35 PM] dckc:: https://github.com/rchain/rchain/blob/dev/casper/src/main/scala/coop/rchain/casper/MultiParentCasperImpl.scala#L73-L145
GitHub
rchain/rchain
Contribute to rchain/rchain development by creating an account on GitHub.

[2:36 PM] Kent:: attemptAdd
[2:37 PM] dckc:: "TODO: Put tuplespace validation back in after we have deterministic unforgeable names." <- done?
[2:37 PM] Kent:: Yeah that is done indeed
[2:38 PM] dckc:: "TODO: Handle slashing" <- not done yet?
[2:38 PM] Kent:: Yup
[2:41 PM] dckc:: hmm... the roadmap has "Mint, Slashing & Finalization" in July.
[2:44 PM] dckc:: JIRA seems to know that slashing is TODO ( e.g. RHOL-839 )