Phlogiston / Execution Costs Meeting notes

Owned by Medha Parlikar (Unlicensed)
Last updated: Feb 26, 2018 by Kyle Butt

Date

Attendees

Goals

  • Decide on one of the proposals for how to pay for computation. The alternatives are sketched out below.

Pre-meeting notes (please review prior to meeting)

Questions from Mike:

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

      contract @"Foo"(x) = { P } := !for ( x ← @Foo ){ P }

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

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


      So, given one contract that calls another:

      contract @"Bar"(@z) = { @"Foo"(z) } | contract @"Foo"(x) = { P }
      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.

Summary of transaction boundaries for computations and interacting with the blockchain state:

  • Users interact with the RChain state via a Par(<code>, <other args>) message. The details of <other args> depends on what payment model we decide on, but the core idea behind Par is that <code> is added into the RChain state and the resulting comm. events (if any) are resolved. The transaction is considered complete for a given Par message when no further comm events can be performed in the RChain state (i.e. all processes are waiting or Nil).
  • A Par can only be successfully include in a block if the final RChain state, after the new code is added and comm events are resolved, can be determined unambiguously (modulo normalization). This means that only computations which complete in a finite number of steps can be included – partial reductions are not allowed. Validators will need to choose to stop computations with many many comm events (which might in fact be infinite loops) some how (this is of course related to payment and gas proposals below) and not include the originating Par opreation in the block. Since Par operations can be run in parallel, this might mean that multiple Par operations need to be reverted to get to a clean state.
  • More details here: Rchain State
  • Validators will likely judge whether or not to include a user's Par request based on their expected value (for guaranteed payments it is just the value itself) for the ensuing computations. The details of how they will be paid are in the proposals below.

Proposals for how to pay for computation:

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

TimeItemWhoNotes




Action items