| Time | Item | Who | Notes |
|---|
| Types of lazy validators | | - 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
|
|
| | - 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 (2n )
- 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.
|