Having the Core sign the state of an Account

The proposal names no repository files, tests, or implementation entry points. Start by reviewing how account state, Horizon LoadAccount responses, and SCP agreement are represented, then determine whether signed account state can be specified consistently. Done would require an agreed protocol design covering signatures, signers, subentries, validation, and lifecycle effects.

This idea has side effects related to "dead accounts", "true cold storage", "sharding accounts", and "ensuring what Horizon sent me was what the Core SCP actually agreed on" that I think are pretty useful.

A few of us noticed that the Horizon SDK clients have little way of ensuring a Horizon endpoint sent the actual balances of an account, versus whatever it felt like sending. This led to my considering a way for the "Core" to sign the current whole account state and have Horizon send that along with the rest of the account details (recipient can then validate the data wasn't tampered with by the man-in-the-middle).

The proposal is to add a "core signature" and "core signer" field to an account.

When an effect modifies something material on an account, like a "subentry", or most of the account's property fields, the proposing node also generates a "Sign Account" effect and computes the signature for the account's new, whole, state and supplies its own peer ID as the "core signer". This "Sign Account" effect would be the last step in a transaction to sign every account that was modified this txn (This could even be pushed out to being part of the "Ledger Close" instead if that's an option).

When the SDK does a "LoadAccount()" it can validate the "core signature" on the account to ensure the client received what the core agreed to via the SCP by checking it with the public key associated to the "core signer".

This assumes that the clients have a reliable method of obtaining an accurate list of public keys for the core signers (aka they didn't come from the cracked Horizon node that simply replaced these new fields too); or that the client retrieve the account's signature from multiple servers to compare several of them.

In my mind's eye the signature would include anything that counts as a "subentry" on the account.
This likely means "account details" on Horizon would be increased to include the "Offers" list so that all the subentries on the account were returned with the account query and the signature properly checked.

So how does this signature help?

• You can now do a "real" cold storage for an account. By leaving only the account signer/signature records in the database; you can delete the rest of the account from the database. When/If the account is ever "reloaded" you check that the data being reloaded matches the signature / signer data on record.

• It validates to the receiving client, that the client received what the core has agreed to

But it has some interesting other uses too:

• This means you can "remove" dead accounts. While they are "removed" they carry no reserve requirement for accounts that might be paying the reserve fee for the account.

• The account can't be transacted with from or to; so while the account is "offline" it can't be changed in any way.

• The account details cannot be looked up directly. You can always recompute them through transaction history, but the account status is simply "offline" or "unavailable" (you can confirm it exists).

• This enables "sharding" of account processing across the core collective. Since it'd no longer be required for a database to hold all data for every account; all nodes can hold only the signatures and signers for every account. They can then request on demand the data for accounts they'd like to participate in. The algo for determining this is a separate discussion; here I'm saying that account sharding by the core is enabled if the account states are signed, and the signature agreed to by the SCP.

Thanks all! I appreciate the consideration.
Mike