assert simple vote tx const cost

[tao-stones]

Problem

Simple Vote Transaction has static cost, which is sum of vote instruction cost, signature cost, 2 write lock cost, and 8CU for data size. Should have some way to make sure the const value are correct.

Summary of Changes

• add assert on the const values

Fixes #

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 81.8%. Comparing base (ce34f3f) to head (eb6db5c).

Additional details and impacted files

@@            Coverage Diff            @@
##           master     #100     +/-   ##
=========================================
- Coverage    81.8%    81.8%   -0.1%     
=========================================
  Files         838      838             
  Lines      225941   225941             
=========================================
- Hits       184945   184894     -51     
- Misses      40996    41047     +51     

[apfitzge]

What I meant in the previous PR was that if it's a simple vote, we should still have consistency. The PR description cost says the vote cost is derived from ix, signature, etc costs. But that's not consistent with what the struct returns me in terms of signature_cost (and others) since it just returns 0 for everything that's not sum

[diman-io]

It can have 2 or even 3 signatures (although the current code, for some reason, does not treat the case with three signatures as a simple_vote; I hope because it was written at a time when there were no other validators)

[tao-stones]

It can have 2 or even 3 signatures (although the current code, for some reason, does not treat the case with three signatures as a simple_vote; I hope because it was written at a time when there were no other validators)

Do you have examples of vote tx have more than one sig? afaik, simple vote txs practically always have one sig, due to the cost of additional sigverify.

[tao-stones]

What I meant in the previous PR was that if it's a simple vote, we should still have consistency. The PR description cost says the vote cost is derived from ix, signature, etc costs. But that's not consistent with what the struct returns me in terms of signature_cost (and others) since it just returns 0 for everything that's not sum

Can you explain more what you mean? SIMPLE_VOTE_USAGE_COST is consistent with its components costs, the assert is to ensure that. For example, signature_cost for vote is SIGNATURE_COST:

    pub fn signature_cost(&self) -> u64 {
        match self {
            Self::SimpleVote { .. } => block_cost_limits::SIGNATURE_COST,
            Self::Transaction(usage_cost) => usage_cost.signature_cost,
        }
    }

[apfitzge]

Huh. Idk which number I looked at last night, but you're right...all the component costs are there.

[diman-io]

It can have 2 or even 3 signatures (although the current code, for some reason, does not treat the case with three signatures as a simple_vote; I hope because it was written at a time when there were no other validators)

Do you have examples of vote tx have more than one sig? afaik, simple vote txs practically always have one sig, due to the cost of additional sigverify.

Yes, on-chain there are many transactions with two signatures. When you change a validator identity, you usually change the authorize voter (to reduce the cost, as you correctly noted). But the authorize voter cannot be changed instantly; it only changes through an epoch. Thus, practically, you pay 10K lamports for each voting transaction for two epochs. One of the most famous examples is probably Laine. And indeed, all validators who had their identity key leaked (at some point, as far as I remember, there was a discussion in Discord about a problematic provider) went through this.

Yes, probably, you can first switch the vote authority and then change the validator identity at the epoch boundary. But this does not cover the case of a leaked private key of validator identity.

Three signatures are needed when the payer for the transaction is separate (this case is not implementable on a vanilla validator). I understand that it is not economically feasible. But making a code that knowingly will not cover some cases, in my opinion, is also not right.

But overall, I thought, why not simplify the simple vote and include all transactions with a single instruction and a vote program in it. This will simply separate the change of vote accounts parameters from ordinary user transactions. Generally, this is not bad. After all, when central scheduling starts working, such transactions will be difficult to land without a priority fee. And it would be desirable to avoid that.