Baker contracts have undesirable side-effects
During my research on how to best upgrade our indexer to v007, specifically looking at on-chain examples of baker account interactions, I found a few inconsistencies in emitted transaction receipts that impact the way we manage accounts today. Talking to Adrian I learned that it is desirable to have some sort of backwards compatibility which is OK, but the way receipts are currently implemented breaks established conventions.
Problem: Baker contracts extend Tezos' account concept by a new property: one account is represented by multiple addresses with all the resulting side effects. Specifically, a baker contract can receive direct calls via its SG1 address but at the same time also through the tz1/2/3 address derived from its current consensus key. This subtly changes who is creditor and who is debtor in transactions and fee payments.
Observation 1: Suppose you send coins to the consensus key's address, example http://dalphanet.smartpy.io/chains/main/blocks/8735/operations/3/0, but instead of being credited to that address the coins actually and almost silently end up being credited to the SG1 baker contract instead. This breaks the semantics of transaction receipts because
destination is no longer the creditor. To find the true creditor you have to look into
balance_updates. One could argue that this was always the case, but before 007 there existed at least an internal operation receipt detailing who forwarded coins to whom.
Observation 2: The debit case is similar. When the consensus key's tz1/2/3 address is the source of a transaction like here http://dalphanet.smartpy.io/chains/main/blocks/5988/operations/3/0 the fee is not paid by the sender, but by the SG1 using the consensus key and the SG1 is also the address that's debited. AFAIK fee is always paid by senders today.
Observation 3: Since the consensus key can still spend, the entire setup does not improve security. In fact security is weakened because the baker has to secure both its consensus key and its owner key now. Suppose the consensus key is stolen and an attacker uses it to drain funds as happened before, the 7 cycle delay will allow the attacker to drain all unfrozen funds as well.
Have you thoroughly considered all side effects, especially in cases where a consensus key is reused? I've been reading about re-use being a desirable feature at metastatedev/tezos!57 (closed) (somewhere down in the review comments), but I think this is not a good idea. I have not found a proper spec for the new baker account feature or tested it other than processing receipts, but here are a few questions you should be able to answer:
- Is it allowed to use the same consensus key with multiple bakers (as part of
- What happens if an implicit account exists and is funded pre baker registration and I use its pubkey as consensus key?
- When a new consensus key is pending, what happens in the debit and credit cases above?
- After a consensus key has been deprecated, what happens to the implicit account derived from the old key?
The current way baker contracts generate transaction receipts introduces subtle but significant changes that will certainly break all existing indexers, if not wallets and exchange integrations. I suggest to fix at least the receipt part by issuing internal transaction receipts for all actions that silently forward a call from tz1/2/3 to SG1.
Since consensus keys are stateful their re-use should be restricted if not forbidden to avoid side effects.