Motviation

As a follow-up to the change in TransactionInputs where Account was replaced by PartialAccount, we should consider whether we could represent public new accounts in TxAccountUpdate as a delta rather than a full Account, as mentioned in #401 (comment). Currently, it is still represented as a full Account, but this means we need to convert a PartialAccount into a full Account during transaction proving (specifically in LocalTransactionProver::build_proven_transaction).

This results in two undesirable consequences:

• The PartialAccount in TransactionInputs needs to actually represent the full account state for new public accounts, otherwise the prover won't be able to build the correct full account state. Until we fix this situation, we cannot change the conversion from Account into PartialAccount to only track the minimal account vault and storage map entries and so this prevents us from enabling lazy loading for assets and storage map items by default.
• In order to correctly map a PartialStorageMap back to a StorageMap, it needs to include the unhashed keys (see also feat: add entry map to PartialStorageMap #1878).

Changes

The primary change would be to AccountUpdateDetails which could be changed to look like this:

pub enum AccountUpdateDetails {
    /// The Account is private (no on-chain state change).
    Private,

    /// The delta for public accounts.
    Public(AccountDelta),
}

To implement this, I think we need:

• Tracking AccountCode changes in AccountDelta, though a minimal solution could be to just have Option<AccountCode> as a stop gap solution. The code would be Some for new accounts and None for existing accounts. This will then be replaced by proper account code deltas once Support account code updates #1771 is finalized.
• To update the transaction kernel to insert the storage and asset of an account into the in-kernel account delta.
• A way to convert an AccountDelta into a full Account, if it represents a new account. This could be From<AccountDelta> for Account or TryFrom<AccountDelta> for Account, depending on whether we can and want to have a check to only allow this for new accounts. This would conceptually apply the delta to an "empty account" to get the new account's state.
• Most likely some other things that I'm missing here. Before working on this issue we should investigate this some more.

Impact

• Account delta commitments become more meaningful for new accounts, since they'd actually include all "changes" to the account. If every transaction can be represented as an account delta, that should allow for more uniformity when handling SigningInputs::TransactionSummary, for example.
• A TxAccountUpdate contains the account delta commitment which can be used to check that the delta contained in AccountUpdateDetails::Delta matches that commitment. However, we can't do that for AccountUpdateDetails::New. Removing New would allow validating the delta of a new account as well.
• We can consider reverting feat: add entry map to PartialStorageMap #1878, i.e. let PartialStorageMap only track hashed keys.