Interpret transaction role declarations

[turbolent]

Work towards #2177

Description

Interpret transaction roles. Call each role's prepare block just like the transaction's prepare block before.

---

• Targeted PR against master branch
• Linked to Github issue with discussion and accepted design OR link to spec that describes this work
• Code follows the standards mentioned here
• Updated relevant documentation
• Re-reviewed Files changed in the Github PR explorer
• Added appropriate labels

[dsainati1]

Would be nice to see some tests for the multi-signer use case discussed in the FLIP, where each signer is a different role.

[turbolent]

Added tests for multiple roles and multiple signers

[turbolent]

@SupunS Could you please have a look?

[codecov]

Codecov Report

Merging #2259 (55a572f) into feature/extended-transaction-format (17610f2) will increase coverage by 0.01%.
The diff coverage is 98.82%.

@@                           Coverage Diff                           @@
##           feature/extended-transaction-format    #2259      +/-   ##
=======================================================================
+ Coverage                                77.77%   77.79%   +0.01%     
=======================================================================
  Files                                      309      309              
  Lines                                    66111    66164      +53     
=======================================================================
+ Hits                                     51420    51474      +54     
+ Misses                                   12907    12906       -1     
  Partials                                  1784     1784              

Flag	Coverage Δ
unittests	77.79% <98.82%> (+0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
runtime/interpreter/interpreter_transaction.go	98.85% <98.71%> (+1.55%)	⬆️
runtime/activations/activations.go	75.24% <100.00%> (ø)
runtime/interpreter/interpreter_expression.go	86.84% <100.00%> (+0.07%)	⬆️
runtime/sema/check_transaction_declaration.go	95.79% <0.00%> (-0.20%)	⬇️
runtime/sema/type.go	89.52% <0.00%> (ø)
runtime/sema/errors.go	94.92% <0.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[SupunS]

👌

[github-actions]

Cadence Benchstat comparison

This branch with compared with the base branch onflow:feature/extended-transaction-format commit fa2c9fe
The command for i in {1..N}; do go test ./... -run=XXX -bench=. -benchmem -shuffle=on; done was used.
Bench tests were run a total of 7 times on each branch.

Collapsed results for better readability

[turbolent]

@dsainati1 Could you please have a look? That would unblock getting the PR stack / this feature in. Thanks!

[dsainati1]

Each signer / wallet is responsible for producing a prepare statement for their assigned role block using a non-empty set of accounts they control if the prepare statement is not already defined in the transaction. This way, the wallet can choose which accounts they need to use, and how they need to accomplish assigning values for the variables they're responsible for.

Each signer / wallet involved in the transaction is assigned one of the roles defined in the transaction.

Perhaps I am misunderstanding, but this part of the FLIP implied to me that we should support something like this, where roles would allow each signing account to know which values and variables they are responsible for:

 transaction {
     prepare(signer1: AuthAccount, signer2: AuthAccount) { }
     
     role role1 {                      
           prepare(signer1: AuthAccount) { }
     }
     
     role role2 {                      
           prepare(signer2: AuthAccount) { }
     }
     
     execute {
       // ...
     }
}

Where each signer is solely responsible for a different role. It's not clear to me that we support this in this implementation. If we do can we add a test case for it?

[dsainati1]

Should this be allowed? If each signer should have 1 role, we probably need to enforce that each role has one signer and also there are an equal number of roles to signers.

[dsainati1]

Discussed with Bastian, this will be addressed in a followup PR. For now we can accept this and fix it later.