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 } |
@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.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).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.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.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.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. Par call simple, parametric in token used for payment (does not need to be revs)Par messages take the form Par(<code>, <paying_account>, <seq>, <sig>, <rev/gas conversion>, <gas limit>), just like Ethereum transactions.contract-single foo() {
... arbitrary terms
} | foo() |
| Time | Item | Who | Notes |
|---|---|---|---|
| 5min | Agenda item | Name |
|