TransactionView: summary of transaction effects

[TalDerei]

Describe your changes

References #4939

Issue ticket number and link

Checklist before requesting a review

• I have added guiding text to explain how a reviewer should test these changes.

• If this code contains consensus-breaking changes, I have added the "consensus-breaking" label. Otherwise, I declare my belief that there are not consensus-breaking changes, for the following reason:

[TalDerei]

comment: need to implement infallible conversion (domain type to proto)

[TalDerei]

filled in the implementation. Sanity check the Amount was computed properly, references from https://github.com/penumbra-zone/penumbra/blob/main/crates/core/asset/src/balance.rs#L296-L301

[TalDerei]

comment: Values cannot be negative, and a negative Balance is formed by negating a balance derived from a value. How do we determine the Imbalance and differentiate between provided and required balances?

[erwanor]

I think the modeling suggested by henry here: https://github.com/penumbra-zone/penumbra/pull/4943/files#r1855950445 takes care of that

[TalDerei]

the negated flag for each individual SignedValue pair now determines the imbalance

[hdevalence]

xref https://github.com/penumbra-zone/penumbra/pull/4943/files#r1855748563

Since Values can't be negative, I think we'll want to have a list of pairs, each with a negation flag, something like

message Balance {
  message SignedValue {
    Value value = 1;
    bool negated = 2;
  }
  repeated SignedValue values = 1;
}

The top-level bool in the Rust Balance struct is an optimization that makes sign changes less expensive (unclear this was really necessary perf-wise, but, we have it now), IMO it should be excluded from serialization by having the serialized form always be "normalized" with individual sign bools.

[TalDerei]

makes sense, refactored to capture the sign information directly in the SignedValue pairs and normalize the top-level Balance

[TalDerei]

how should we handle cases where multiple entries share the same asset ID with different negation flags, for instance:

        let proto_balance = pb::Balance {
            values: vec![
                pb::balance::SignedValue { 
                    value: Some(pb::Value { asset_id: Some((*STAKING_TOKEN_ASSET_ID).into()), amount: Some(Amount::from(100u128).into()) }), 
                    negated: false
                },
                pb::balance::SignedValue {
                    value: Some(pb::Value {
                        asset_id: Some((*STAKING_TOKEN_ASSET_ID).into()),
                        amount: Some(Amount::from(200u128).into()),
                    }),
                    negated: true,
                },
            ],
        };

        let balance = Balance::try_from(proto_balance).expect("fallible conversion");

The BTreeMap can't hold multiple imbalances for the same asset ID. Instead, should it be doing something more sophisticated and explicitly accumulating values during conversion? Consequently, the serialized output should be

balance: Balance { required: [Value { amount: 100, asset_id: passet1984fctenw8m2fpl8a9wzguzp7j34d7vravryuhft808nyt9fdggqxmanqm }], provided: [] }

update: implemented an ordering-agnostic accumulation scheme that combines imbalances for the same asset ID.

[cronokirby]

IMO, we should explicitly write down the PartialOrd instance, so that someone refactoring the order of the enums or something doesn't accidentally change it.

[erwanor]

Good idea, is it even necessary here? if so, then I think a comment like this one:

Suggested change

	#[derive(Debug, Clone, PartialEq, Eq, Serialize, Deserialize, PartialOrd, Ord)]
	// Warning: This enum derives `PartialOrd` which means that re-arranging
	// field-less variants is semver breaking.
	#derive(Debug, Clone, PartialEq, Eq, Serialize, Deserialize, PartialOrd, Ord)]

would be helpful. Can put a pin on doing a lookup on the rest of the codebase.

[TalDerei]

It's necessary to satisfy other trait bounds in accumulate_effects. I added the proposed comment

[cronokirby]

Yeah, also we want a canonical serialization for balances.

[TalDerei]

added PartialOrd and Ord impls for AddressView

[TalDerei]

change base to release/v0.81.x?