Page Comparison

...

• How do we signal intent to pay?
  • On Ethereum, the only persistent state is inside contracts, every message gets sent to a particular contract, and every message signals an intent to pay
  • On RChain, we have the potential for public data feeds.  Given any name x, a feed can publish successive messages as @(*x|n)!!(M_n), where n is a number and M_n is the nth message.  Such data should have a phlo store to pay for remaining part of the active state, but should not pay for any processing done by clients.  Clients would publish (linear!) for terms equipped with phlo for storage and for processing that would consume one of the replicated messages.
    
    

  • Perhaps the question of whether to include ! in the syntax could be resolved if it signaled an intent to pay.  x$(P)?
    
    One way to think about intent to pay is by assuming that the agent who completes a COMM is the payer. That way, contract invocation is an indication of intent. If a contract definition is replicated for:

    Code Block
    language scala
    contract @"Foo"(x) = { P } := !for ( x ← @Foo ){ P }

    
    

    then an invocation parred with a definition completes a COMM event:

    Code Block
    contract @"Foo"(x) = { P } | @"Foo"(x) => P{@z/x}

    
    So, given one contract that calls another:

    Code Block
    contract @"Bar"(@z) = { @"Foo"(z) } | contract @"Foo"(x) = { P }

    Code Block
    contract @"Bar"(@z) = { @"Foo"(z) | @z!(Q) }

    
    

    The entity charged for @Bar should also be charged for @Foo. Of course, this breaks down in the case that contract invocation happens before the definition. If a send happens first, who's responsible for paying for the running the contract? Is it the agent sending to the contract, or the agent supplying the contract? One way to enforce intention is to only allow agents to invoke contracts that have already been defined. This check could potentially be done during term sorting. If agents may only send on defined contracts, then it is always known that the agent sending to the contract is the agent completing the COMM, and therefore the payer can always be determined.
    
    
• How do we track the phlo assigned to a term?
  • phlo for storage vs phlo for processing as above
• Is Rev an ERC20-style token contract, which requires locking the balance table, or a decentralized purse system?
• Leftover funds
  • In Ethereum, you can pay extra so that miners are more likely to include your transaction, since miners get what's left over.
• Is there some way to pay validators directly rather than have the phlo tracking & Rev deduction be part of the execution semantics?  It would simplify some things and complicate others.

...

• "Free market"
  • Par messages take the form Par(<code user wants> | <send validators some tokens to incentivize them>), i.e. the <code> argument consists of two parallel parts: the useful work the user wish to accomplish and a transfer call which sends tokens to the validators so that they are being paid for including that Par in the RChain state. No <other args> are required because everything happens through on-chain computation.
  • Pros: Simple protocol, elegant, pure (100% modeled in Rholang), parametric in token used for payment (does not need to be revs), simplifies the VM (no notion of keep track of gas or need for any of the arbitrary constants gas entails - allows easy rewriting of the VM in Rholang itself in the future), and probably least dev time required until release
  • Cons: Validators need to run code to get paid and do not get paid when a computation does not complete – despite having had to spend time/resources to learn that it does not complete. But there are all sorts of fun ideas to mitigate this - pattern matching (static code analysis), white/blacklists, hybrid validation modes based on load, and potential natural uprising of subprotocols that are better than current gas based models without hard forks. The network won't be robust until validators get their strategies straightened out and/or subprotocols form. DOS attacks will not matter as much until the network starts to be heavily used (gains value), and hopefully by that time there is a healthy ecosystem of validator strategies and subprotocols to handle DOS attacks.
• "Abstracted gas payments"
  • Par messages take the form Par(<code>), similar to the free market, however in this case the code needs to include paying for gas at the end of the computation. This payment will need to leverage some VM-exposed primitive which says how much gas has been expended by this Par operation. 
  • Pros: Keeps Par call simple, parametric in token used for payment (does not need to be revs)
  • Cons: Same as above (validators still need to run code to get paid), keeping track of gas cost accumulated in parallel is tricky, opcode gas cost changes will require hard forks
• "Ethereum-style"
  • Par messages take the form Par(<code>, <paying_account>, <seq>, <sig>, <rev/gas conversion>, <gas limit>), just like Ethereum transactions.
  • Pros: Almost same as Ethereum – tried and true, we know it works
  • Cons: Complicated, impure, not parametric in the token, most changes will require a hard fork
• Put any other proposals you have here!

How to put arbitrary terms on the blockchain even if we restrict user interactions to contract deployment and invocations:

contract-single foo() {
   ... arbitrary terms
} | foo()

• If we can track the user's wallet for the above, I don't see why we can't track the user's wallet for whatever they deploy.

Discussion items

...