Lazy Validator Hedge Meeting notes

Types of lazy validators

@Michael Stay (Unlicensed)

• Validator joins, pretends to never receive any blocks.

  • Involves Ejection, which is not implemented.  

  • Indistinguishable from network failure.

• Validator joins, issues blocks, but isn't keeping the whole tuplespace, so cannot distinguish invalid from valid ones

  • Feasible to detect.

  • they build on an invalid block

  • they can watch other validators and see which blocks they build on

• They may be able to keep a partial record of the tuplespace, but it will be very difficult for them to create any blocks without a full state.

• They could publish empty blocks.

• They could steal transactions from another validator

 @Kyle Butt

•  Disallow blocks who's root state hash is the same as the parent. These are no op blocks.

• Fee splitting contract will need access to an Oracle (piece of Scala code - that the Rholang code can reach out and ask questions about the DAG) - because it doesn't know anything about the DAG.  

  • Goal - transaction fees are not delivered until a block is built on top of the block you proposed.  The transaction fees are held in trust in the PoS contract.

  • Bag of fees for a transaction.  Initially, the fees go to the proposer, and as validatorB  creates a block referencing that block, the fees now go to the proposer & validatorB

Outcome

• When deploying, the Proof of Stake contract needs to be notified of the deployment.

  • Need to add a block validity condition - there is 1 such transaction/block - 

• In order to claim your portion, you have to build on the block. 

• The block has to be included in the fork-choice tip

• There is a risk that large chunks of fees get tied up in the Proof of Stake contract (2ⁿ )

• Unclaimed rewards

Short leash proposal

@Kyle Butt

• Short leash proposal

  • the signature somehow has to sign the code that is being paid for.

  • Oracle that gives the other pieces of the deployment - the hash of hte code and the timestamp, so they can validate the signature over the payment and details, so they can decide if they want to pay for it. 

  • Deploy, and a separate piece of code containing the hash of the deploy + timestamp + signature, sent off to the wallet to be verified.  The entire bundle is then sent to the Proof of Stake contract.

  • Craft the deploy, then craft the payment for the deploy.

  • allows for multi-sig.  Need signatures over all the things with all the keys.

  • Is the short leash credit?  Whatever phlo you get, we deduct the amount you used getting the payment and use the remainder for the code.

    • Could take advantage of the leash by jamming computation into the leash

    • If they send code that doesn't produce payment, no effects on the blockchain occur. There is a potential for DoS.  This is true in all cases where you don't know if you are getting funds for the work.

    • They can't use it to extract useful computation.