We should allow some way to ensure miners get paid on our transactions + mana limit per transaction

[steinerkelvin]

Considering:

• Any individual statement can spend mana up to the total block mana limit.
• One can't know how much mana a statement spends (or if it even succeeds) without emulating it entirely.
• A statement can affect how much mana the next statements will spend (or if they succeed).

The only way a miner can be sure it will be compensated for each statement with which it is spending block space is to emulate them all, in order, i.e. the entire block.

This is prohibitively costly.

I think this problem can be totally fixed with 2 simple features:

• statements / IOs can have an associated mana limit;
• a Try IO that would allow the outer code to keep running even if the inner IO fails;

Regarding the hypothetic code below, it ensures the miner:

• that it will not spend more than X mana, and so can be safely included with other S transactions that spends at most the total mana for a block;
• that the outer IO will succeed independently of the result of the inner IO, so the miner can check it will be paid without having to execute the entire statement (i.e. it will be paid even if the inner IO fails);

run 10000 {
  let miner = ask (Miner {Get});
  ask (Kgt.send #12345 miner);
  ask (Nonce #5);
  let ~ = (IoTry 9800 {
    // Could try to spend more than 9800 of mana, but would be halted before as per the proposed protocol
  });
  // Miner will still be paid in the outer block.
  // The outer block can still be emulated cheaply: it succeeds
  // independently of the contents of the inner IO that will be try-ed.
  (Done x)
}

cc @VictorTaelin

[VictorTaelin]

I'm not sure if either are necessary, but think this is a lightweight enough "solution" (and even independent feature, in a way) that I'm fine with including both.

[o-santi]

What about the space limit? I think it should be able to limit both mana and space, if were we to implement this.

[steinerkelvin]

@o-santi You are right.