FrankSzendzielarz / AlgorandVisualStudio

Visual Studio extensions for C# TEAL compilation and Algorand Smart Contract development
MIT License
21 stars 2 forks source link

Arbitrary Group Transaction - ValueTuple is statically defined - Suggestion: use an arbitrary InnerTransactionBuilder #29

Open mangoplane opened 1 year ago

mangoplane commented 1 year ago

Hi,

From the documentation, this is how you do an inner group transaction. This isn't adequate for my needs, as the length is statically defined. Consider a common scenario where you need to dynamically construct the inner call, based on circumstance. In PyTeal, this is possible by just calling .Next() within a for loop structure.

Perhaps you could use a dynamic List<>, that you can append to in smart contract call, where it isn't submitted until an explicit "submit" function is called. Please see https://developer.algorand.org/docs/get-details/dapps/smart-contracts/apps/innertx/#grouped-inner-transaction for how it is achieved in PyTeal.

It would remain ARC4 compliant if this change were made.

Currently:

[InnerTransactionCall]
void makePayment()
{
    // Statically defined. WYSIWYG.
    var paymentGroup=(new Payment(split1, amountToPayToRecipient1), new Payment(split2, amountToPayToRecipient2));
}

Suggested change:

[InnerTransactionCall]
void makePayment()
{
    // build the InnerTxn. Allow dynamic construction to unlock an entirely new dimension of very useful/common applications
    var paymentGroup= new GroupInnerTransaction();
    paymentGroup.Add(new Payment(split1, amountToPayToRecipient1));
    paymentGroup.Add(new Payment(split2, amountToPayToRecipient2));

    // it's built, now Submit it.
    paymentGroup.submit();
}

Kind regards.

FrankSzendzielarz commented 1 year ago

I see.

I am wondering if the simplest solution is to have the [InnerTransactionCall] group all inners by default. At the moment, subsequent Payments, for example, are "submitted" individually. Or alternatively add a new InnerTransactionCall(bool groupbydefault) attribute that will treat the local function as a group or not depending. This would be fairly low hanging fruit.

With the latter we could also add base methods BeginTransaction and EndTransaction allowing multiple groups within one local function.

This would mean that sub-groups (statically defined) would be nested groups, and app calls (smart contract reference type invocations) would be nested groups, whereas all other single transaction instantiations like new Payment would be part of the group declared by that local function.

Having said that I am not entirely sure what the significance of groups vs singles is in the context of inners, as I think they are all treated as an atomic transaction in the context of the app call.