This issue keeps track of the current status for the future upgrade that achieves succinctness. "Current status" refers both to code and way of thinking. Succinctness is a bit of a conundrum.
One option is to deploy succinctness as four separate new block appendices. I'm not necessarily suggesting deploying them as such, just drawing conceptual boundaries.
OwnHeaderIsCorrect. The inputs are (the hash of) all fields of the current block's header that the guesser cannot change. (height, prev_block_digest, timestamp, cumulative_proof_of_work, difficulty) The program asserts that the height, timestamp, difficulty, and cumulative proof-of-work number are correctly updated relative to the predecessor block's.PredecessorIsValid. The input is the prev_block_digest. This program asserts that the predecessor block's block proof passes validation.PredecessorHasProofOfWork. The input is the prev_block_digest. This program asserts that the hash of the predecessor block is smaller than its difficulty.PredecessorHasRightAppendices. The input is the prev_block_digest. This program asserts that the predecessor block has all necessary block appendices, including (1), (2), (3), and (self-referentially) (4), as well as the current transaction-is-valid appendix.
If we do go for a 4-stage deployment, then appendix 4 needs to come last because it needs to refer to the other three as well as itself.
Note that Triton programs have access to their own hash. This knowledge is what enables them to generate claims that refer to themselves.
This issue keeps track of the current status for the future upgrade that achieves succinctness. "Current status" refers both to code and way of thinking. Succinctness is a bit of a conundrum.
One option is to deploy succinctness as four separate new block appendices. I'm not necessarily suggesting deploying them as such, just drawing conceptual boundaries.
OwnHeaderIsCorrect. The inputs are (the hash of) all fields of the current block's header that the guesser cannot change. (height,prev_block_digest,timestamp,cumulative_proof_of_work,difficulty) The program asserts that the height, timestamp, difficulty, and cumulative proof-of-work number are correctly updated relative to the predecessor block's.PredecessorIsValid. The input is theprev_block_digest. This program asserts that the predecessor block's block proof passes validation.PredecessorHasProofOfWork. The input is theprev_block_digest. This program asserts that the hash of the predecessor block is smaller than its difficulty.PredecessorHasRightAppendices. The input is theprev_block_digest. This program asserts that the predecessor block has all necessary block appendices, including (1), (2), (3), and (self-referentially) (4), as well as the current transaction-is-valid appendix.If we do go for a 4-stage deployment, then appendix 4 needs to come last because it needs to refer to the other three as well as itself.
Note that Triton programs have access to their own hash. This knowledge is what enables them to generate claims that refer to themselves.