"pow-pulse": Is this a feasible successor design which could lower latency while maintaining most of the security analysis?

[shielded-nate]

Question

I wondered about a potential successor protocol to Crosslink which is fairly simple, and wanted to write it up to get feedback or use it as a foil for other design discussions.

PoW-Pulse

The name/label is "PoW-Pulse" using the notion that it pivots the PoW component to be "merely" a secure permission less time-keeping (ie: pulse) function, and nothing more.

Goals

a. Lower the assured-finality latency as much as possible while meeting the other goals,
b. Make the changes to Crosslink such that we can retain the security arguments as-is without modification. (Caveat: parameters and constants may change, such as $$\sigma$$, issuance levels, etc… as necessary to make the result practical and safe.)
c. Make the consensus changes to Crosslink as minimal as possible in terms of protocol design, while tolerating more complexity in code, networking, clients, etc…

Overview

Starting from some well defined version of Crosslink, make these changes:

• move all "ledger state" from PoW blocks to BFT blocks. This includes anything relevant to the ledger state that's independent of PoW consensus, such as transaction tree commitments, Orchard anchor commitments, supply or pool total commitments, or any other kind of committed ledger state.
• Change the responsibility of ledger state validation from PoW miners to BFT validators.
• Lower the PoW target time as much as is feasible given the above changes.

The thinking here is that one limiting factor for lower PoW block target times is the time necessary for a miner to validate transactions. If we move that responsibility entirely out of PoW blocks, then miners only need to validate either prior PoW blocks or BFT blocks (depending on Crosslink variations, such as whether or not PoW blocks are unified with BFT proposals).

If miners only need to do a relatively light "block-header-only" validation, and are insensitive to transaction validation, then we've removed one key bottleneck in PoW target time and can lower it drastically.

Analysis

I haven't done much analysis at all, but here are some questions I'd start with if no one else sees blockers or more promising improvement proposals:

a. Does this meet design goal A? Can we reuse Crosslink security proofs without change?
b. Some PoW security analysis hinge on number of blocks, whereas others hinge on mining capacity over wall-clock time (especially if they're calculating cost/time of attack). This seems like it would only help lower latency if we protect only against attacks which hinge only on number of blocks. So, what are the attacks that matter for wall-clock time (or cost-per-time, etc…)? How bad are those attacks with Crosslink's security properties?
c. What are the other limiting factors for lower block time? Obviously speed of light is there, but probably block header validation is the next bottleneck? What is the safe ratio between estimated bottleneck time vs block target time? How low is that block target time? How beneficial is that lower block time for users?

Potential Further Improvements

Is it helpful to have recursive proofs of validity, or even constant-space-verifiable recursive history validity proofs in terms of improving latency for this design?

I have a particular fondness for constant-space/time-verifiable recursive history validity proofs, where any "node" can validate a small constant sized block header to determine either a. all of history has followed the expected rules, b. there is a bug in the recursive history circuit, or c. the proving system is unsound. If such a scheme were possible, it is obviously valuable for wallets and other light clients, but for PoW-Pulse the question is: does this help miners in any way? Does it lower latency, lower their costs, or lower their bootstrap time? If no, the two features are entirely orthogonal. If yes, they this style of proving supports the PoW-Pulse architecture.

Alternatives

There may easily be better alternative successor designs to Crosslink with similar or different goals. A similar goal space to explore is "what's the best successor protocol with low finality latency" where "best" means both good design and practical given our starting point / resources.

Different potentially desirable successor goals:

• Improve throughput substantially, or relatedly lower the txn fees required to support a larger number of transactions per time.
• Transition to non-PoW entirely while maintaining security and the nice relatively unique benefits of Crosslink: dynamic availability, permissionless restart/partition healing, economic multi-spend attack "blast radius" protection (vs pure BFT)...
• Others?