Added proof requirements to entry recreation

[SirTyson]

This update makes minor updates to evicted entry meta, provides an optimization preventing some writes of DELETED keys to the AST, and distinguishes between proof requirements when creating an entry for the first time vs. recreating an entry that was previously deleted.

The optimization for deleted keys checks the archive before writing a deleted key, and only writes the key if an ARCHIVED entry with the same key exists in the AST. If no ARCHIVED entry exists, we don't need to write the deleted key, as there in no double restore attack to prevent. This can be done safely and efficiently via the archival filters.

Unfortunately, I've recently realized an issue in new entry creation proofs wrt recreated entries. If a key has never existed before, we can optimize proofs-of-nonexistence via the archival filter. However, an issue arises when a key is archived, restored, deleted, then recreated.

Suppose LedgerEntry e with LedgerKey k is archived in AST[i]. The entry is later restored, then deleted such that the DELETED entry is written in a later epoch AST[k].

When k is recreated, the proof-of-nonexistence optimization is no longer possible. When the validator goes to check the binary fuse filter, it will see that the entry already exists in epoch i and k. Thus, a proof-of-existence for the DELETED entry in k is necessary for the recreation to be secure against eclipse attacks.

I've gone through several draft proposals, such as dividing DELETED and ARCHIVED keys into seperate filters, using multiple overlapping filters, etc. Unfortunately, I haven't found a solution where false positives don't result in an eclipse attack.

This seems like an edge case that is not bound to occur regularly, but still may provide a frustrating experience to the user. In particular, an entry must be archived, restored at least 1 epoch after being archived (any sooner and the restoration would merge with and delete the ARCHIVAL entry) , be restored, be deleted, then be recreated again. In this case, entry creation will require a proof.

Talking with some smart contract devs in the ecosystem, the only use case I could find for entry deletion then follow up recreation is in a temporary escrow accounts proposal to allow trading between classic DEX and Soroban DEX. TLDR: a temporary account is used to facilitate funds offloading from the classic DEX and entering Soroban. While the account is only used for a short time, it can't be a temporary entry because it holds funds.

The pattern I've abstracted from this proposal is that persistent entry deletion and recreation is usually done for operational reasons were the deletion occurs shortly after the initial creation. The DELETED key optimization I've included directly addresses this case.

I think we're probably ok here. The only time a recreation proof is required is when there is a relatively significant amount of time between the entry creation and follow up deletion (plus an archival and restore event before the deletion too). That being said, it probably warrants some conversation.

[dmkozh]

I wonder if we can just rename the field; the rename won't change the XDR compatibility, will it? There also shouldn't be consumers of this field either, as we don't populate it currently.

[SirTyson]

Good point, especially since we need a new LedgerCloseMeta version anyway.