{integrationtests, services, sorobanauth}: Support contract account invocation

[marcelosalloum]

What

Support contract account invocation.

Why

To make the wallet-backend production ready.

Known limitations

We'll enable the remaining operations in:

• Feature Request: Include Security Edge Cases in the Integration Tests #162

Issue that this PR addresses

#147

Checklist

PR Structure

• It is not possible to break this PR down into smaller PRs.
• This PR does not mix refactoring changes with feature changes.
• This PR's title starts with name of package that is most changed in the PR, or all if the changes are broad or impact many packages.

Thoroughness

• This PR adds tests for the new functionality or fixes.
• All updated queries have been tested (refer to this check if the data set returned by the updated query is expected to be same as the original one).

Release

• This is not a breaking change.
• This is ready to be tested in development.
• The new functionality is gated with a feature flag if this is not ready for production.

[Copilot]

Pull Request Overview

This PR adds support for contract account invocation by integrating Soroban operations along with updates to tests, error handling, and configuration. Key changes include:

• New tests and helper functions for identifying and processing Soroban-specific operations.
• Adjustments in transaction service logic to handle Soroban transactions (e.g. manual sequence incrementation and base fee reduction).
• Updates to error messages and configuration defaults regarding channel account usage and signature validation.

Reviewed Changes

Copilot reviewed 16 out of 16 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
pkg/utils/utils_test.go	Added tests for Soroban operation type detection and conversion.
pkg/utils/utils.go	Introduced SorobanOpTypes and helper functions (IsSorobanXDROp, etc.).
pkg/sorobanauth/sorobanauth.go & _test.go	Updated authorization logic and tests to handle forbidden signers.
internal/tss/utils/operation_builder*.go	Refined source account enforcement for Stellar Classic vs Soroban ops.
internal/tss/services/transaction_service.go	Modified transaction construction and fee handling for Soroban flows.
internal/integrationtests/*	Updated integration tests and fixture functions for Soroban operations.
cmd/utils/global_options.go	Adjusted default base fee configuration for transactions.
internal/serve/serve.go & httphandler/tss_handler.go	Updated server routing and error handling for TSS endpoints.
internal/signing/*.go	Amended signature client mocks and channel account error handling.

Comments suppressed due to low confidence (3)

internal/serve/serve.go:38

• The removal of OperationTypeInvokeHostFunction from the blockedOperationTypes list should be reviewed to ensure it aligns with the intended security model for allowed operations.

xdr.OperationTypeInvokeHostFunction,

cmd/utils/global_options.go:65

• The default flag value for the base fee was increased significantly from 100 * txnbuild.MinBaseFee to 10000 * txnbuild.MinBaseFee. Please confirm that this change is intentional and aligns with the required fee scaling for transactions.

FlagDefault: 10000 * txnbuild.MinBaseFee,

internal/tss/services/transaction_service.go:132

• Manually incrementing the sequence number while disabling IncrementSequenceNum may lead to subtle concurrency issues. It is recommended to double-check that this approach consistently maintains correct transaction ordering in all cases.

Sequence:  channelAccountSeq + 1,

[aditya1702]

Looks good. Just a few small comments.

Also, can you please add some more comments in the important functions for someone new to understand.

[aditya1702]

why are we using only the 0th index here?

[marcelosalloum]

Good question!

SimulateResults is a slice because the original design aimed to support multiple contract invocations within a single transaction. That plan was later dropped, and now only one contract invocation is allowed per transaction.

I asked around, and it seems the slice structure is just a leftover from that earlier design that never fully landed.

[marcelosalloum]

Include more comments explaining this and other parts of the code:

0848476

[aditya1702]

you can actually combine the switch-case conditions into a single line:

case *txnbuild.InvokeHostFunction, *txnbuild.ExtendFootprintTtl, *txnbuild.RestoreFootprint

[marcelosalloum]

Noted. The reason for doing 3 cases with the same (apparent) inner code is because we have an interface at operations[0] but we need to set a parameter not exposed by that interface. The .Ext parameter is only available at the concrete types *txnbuild.InvokeHostFunction, txnbuild.ExtendFootprintTtl, and txnbuild.RestoreFootprint and we need to parse the interface to the individual type in order to set that parameter.

Go doesn't have the concept of union types (common in typescript), so there's no way around it AFAIK.

wallet-backend/internal/tss/services/transaction_service.go

Lines 207 to 216 in 461f24a

	switch sorobanOp := operations[0].(type) {
	case *txnbuild.InvokeHostFunction:
	sorobanOp.Ext = transactionExt
	case *txnbuild.ExtendFootprintTtl:
	sorobanOp.Ext = transactionExt
	case *txnbuild.RestoreFootprint:
	sorobanOp.Ext = transactionExt
	default:
	return txnbuild.TransactionParams{}, fmt.Errorf("%w: operation type %T is not a supported soroban operation", ErrInvalidArguments, operations[0])
	}

[marcelosalloum]

Also, can you please add some more comments in the important functions for someone new to understand.

Done in 0848476.