Yes. Fully trustless in the sense that it can decide canonicity (which block builds on a chain of valid blocks and holds the most accumulated proof-of-work) without downloading any other blocks.
Tradeoffs? The composers will have to do more work. With succinctness we’re expecting them to have to do at least four proofs with padded height 2^{21} followed by three 2^{20} proofs. 2^{21} is the same complexity that building a coinbase requires. A 2^{21} proof currently takes 15 seconds on a Threadripper CPU. The fastest composer uses about 40 seconds today to build a block proposal. Expect that number to rise to about 120 seconds with succinctness.
Who will run full archival nodes, i.e. read all historical blocks? With succinctness there is no good reason to store historical block proofs. So those don’t have to be saved. But if you want to be able to serve old announcements and an index into those, then you have to know all blocks.
| Capability | 1. Light | 2. Archival mutator set | 3. Full archival |
|---|---|---|---|
| Stores | Latest block only | All mutator set data | All blocks, with or without proofs |
| Disk today | One block | ~60 MB | ~60 GB with proofs / 2 GB without |
| Determine block canonicity |  |
|
|
| Restore own membership proofs |  |
|
|
| Restore arbitrary membership proofs |  |
|
|
| Can compose | |
|
|
| Can guess (PoW nonce search) | |
|
|
| Historical announcements (encrypted UTXO data for the receiver) | |
|
|
| UTXO index (instant address lookup of relevant block heights/hashes) | |
|
|
| Serve historical blocks without proofs | |
|
|
| Serve historical block proofs | |
|
 Only if proofs are stored |