fast-forward

[arvidn]

this PR is best reviewed one commit at a time.

overview

It introduces a feature I call "fast forward". Perhaps a better name would be "rebase". What it does is to change the coin being spent by a singleton spend. It obviously only work for a small subset of singleton spends:

1. The puzzle hash may not be altered by the spend, i.e. the state of the singleton must stay the same
2. The inner puzzle or solution may not tie the spend to a specific coin or parent coin (via AGG_SIG_ME, ASSERT_MY_COIN_ID, ASSERT_MY_PARENT_ID, etc.)
3. The output coin, that forms the new state for the singleton, must have the same coin amount as the input coin
4. The spend must use a singleton_top_layer_v1_1.clsp outer puzzle.

In order the change the coin being spent, the singleton top layer solution is altered to include a new parent's parent coin ID.

commits

The change is broken down into the following commits:

1. The core function (fast_forward_singleton()) that validates that spend as eligible and produces a new solution for the spend on the new coin.
2. Updates to the conditions parsing, identifying traits of spends as (possibly) being eligible for fast forward, setting the flag ELIGIBLE_FOR_FF. This flag does not guarantee that a spend supports fast-forward, but together with the fast_forward_singleton() function, it's believed to guarantee that the new spend is valid. (However, it's best to validate it by running the new spend). This flag is primarily meant when running a spend bundle to validate whether a spend can be fast-forwarded or not.
3. Add a fuzzer for fast_forward_spend() and extend the gen-corpus tool to pick out singletons to seed the corpus with
4. Add two new tools (under chia-tools): run-spend and fast-forward-spend. These were very helpful in the development of this feature both for manual testing and understanding of the puzzles. My vision for run-spend is to extend it to know about more puzzles in the future, to make it a convenient way of inspecting puzzles on the chain.
5. Add python bindings for this function. For convenience, the python wrapper adds two functions, one to validate whether the spend supports fast-forward, and one that also returns the new solution.

run-spend

Here's an example output from the run-spend tool, for a singleton spend:

$ cargo run --bin run-spend ../ff-tests/e3c0.spend

Spending Coin { parent_coin_info: 24dde051988ea30bb269921e1844051fc42078d1fd561086f235ddff1354e734, puzzle_hash: e3c000a395f8f69d5e263a9548f13bffb1c4b701ab8f3faa03f7647c8750d077, amount: 1 }
   coin-id: fd65e4b0f21322f78d1025e8a8ff7a1df77cd40b86885b851f4572e5ce06e4ff

Conditions

  [73] ASSERT_MY_AMOUNT 1
  [71] ASSERT_MY_PARENT_ID 24dde051988ea30bb269921e1844051fc42078d1fd561086f235ddff1354e734
  [51] CRATE_COIN e3c000a395f8f69d5e263a9548f13bffb1c4b701ab8f3faa03f7647c8750d077 1 

Puzzle Info

Puzzle: e3c000a395f8f69d5e263a9548f13bffb1c4b701ab8f3faa03f7647c8750d077
singleton_top_layer_1_1.clsp
  singleton-struct:
    mod-hash: 7faa3253bfddd1e0decb0906b2dc6247bbc4cf608f58345d173adb63e8b47c9f
    launcher-id: a314920efd80f4ea2c50a2b756c4b9b6d567e2c11e686e1c19e706342d88b021
    launcher-puzzle-hash: eff07522495060c066f66f32acc2a77e3a3e737aca8baea4d1a64ea4cdc13da9
  solution
    lineage-proof: LineageProof { parent_parent_coin_id: 8703edff9f09bb7efd3748b9323aaa29c93f4afb041956158927cee33ef3d485, parent_inner_puzzle_hash: 1590dc8c2190782bf3828bcd9257c8b743d7163a37c6ec6eb9819498809393ef, parent_amount: 1 }
    amount: 1

Inner Puzzle:

Puzzle: 1590dc8c2190782bf3828bcd9257c8b743d7163a37c6ec6eb9819498809393ef
  Unknown puzzle 635fe962cefb0ded17a52293b7057057a6bb1e60417e565ded3c8594e8f8c4ca

[coveralls-official]

Pull Request Test Coverage Report for Build 6596400357

• 470 of 479 (98.12%) changed or added relevant lines in 4 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.4%) to 89.482%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
wheel/src/api.rs	43	45	95.56%
src/fast_forward.rs	423	426	99.3%
src/error.rs	1	5	20.0%

Totals
Change from base Build 6587564828:	0.4%
Covered Lines:	9537
Relevant Lines:	10658

---

💛 - Coveralls

[trepca]

Interesting, can you explain some use cases that this feature could enable? If puzzle hash can't change, is it mainly for oracle-like coins?

[arvidn]

@trepca yes, it's primarily for oracle-like coins. One of the features it enables is for farmers to fast-forward mempool items and combine multiple spends of the same coin in the same block.

[AmineKhaldi]

Looks reasonable. I think we should expose ELIGIBLE_FOR_FF in the wheel and update the PR description to no longer mention CREATE_COIN_ANNOUNCEMENT as a restriction for instance.

[richardkiss]

I remain of the opinion that adding code to the core node that is aware of specific spend types is not a good idea.

[arvidn]

@richardkiss

I remain of the opinion that adding code to the core node that is aware of specific spend types is not a good idea.

This PR doesn't do that though

[richardkiss]

It seems strange to me to look for particular condition outputs deep in the "spend condition aggregator". It's a layer violation that gives too much preference to a particular kind of spend. I get that you don't want to have to run the spend again just to examine the output conditions.

What if we pass in an optional callback in that's run on each iterator at the appropriate time, and it can do whatever it wants? Wherever it needs to go to identify the magic spends and notate them.

[arvidn]

What if we pass in an optional callback in that's run on each iterator at the appropriate time, and it can do whatever it wants? Wherever it needs to go to identify the magic spends and notate them.

The time when we need to identify or extract information for some other purpose or puzzle would be the perfect time to introduce such abstraction. I don't think there's much value in trying to predict what it would look like, and introduce additional complexity for a potential future use.

That said, I think it would reduce complexity to find a way to pull out this checking into a separate pass. Iterating the output coins ended up being separate pass anyway.

[richardkiss]

Much less controversial now.