Composable Transactions

[kroggen]

This implements the feature of Composable Transactions

[rabbitprincess]

It seems able to make 'multicall contract', which call multiple contract in contract. Is there a difference between multiple contracts in a transaction and multiple contracts in a contract?

and also, i suspect there isn`t rollback state appropriately when composable transaction failed.

[rabbitprincess]

composable transaction can execute multiple signatures atomically, but it also can by multisig in one transaction.

[kroggen]

It seems able to make 'multicall contract', which call multiple contract in contract. Is there a difference between multiple contracts in a transaction and multiple contracts in a contract?

I honestly cannot understand what you wrote

and also, i suspect there isn`t rollback state appropriately when composable transaction failed.

I will add failure cases to the unit tests

composable transaction can execute multiple signatures atomically, but it also can by multisig in one transaction.

what do you mean by "signatures"?

what is "multisig in one transaction"?

what do you want to say with the above sentence?

[kroggen]

For reference:

https://github.com/aergoio/aergo/wiki/Composable-Transactions

[rabbitprincess]

I honestly cannot understand what you wrote

I want to ask 'why composable transaction need?', if it can be replaced by just deploy contract which call other contracts.

I will add failure cases to the unit tests

it need to tested about rollback governance params like votingPowerRank.

[hayarobi]

It seems like that there added another smart contract language, since composible transaction has its own commands and syntax. The functions listed in the wiki can be coded in lua contract. I think that making a lua contract is easier than call composible transaction because contract developers need not to learn new syntaxes and commands. One drawback of this approch is that lua contract must be deployed before calling, and this seems critical. How about add feature of ONE SHOT contract, which does not store deployed contract in statedb but just instantly run code single time. This works similar with composible transaction.

[kroggen]

It appears that you both have not read the description on the Wiki

You can also check #149

There is no deployment of new contract. This adds the feature to process many calls in a single transaction.

This feature is meant to be used by EOA (simple accounts) not by contracts

There is a new tx type MULTICALL for this purpose

The JSON script is added in the payload of a transaction, then it is processed by the Lua code in vm_multicall.go

Governance is not supported, so there is no need to check voting power

I am perceiving now that integration tests are lacking (they did not exist when this feature was created). I will add some

[hayarobi]

I suggested a new feature like yours, after reading and inspired by that wiki . The key feature is executing multiple contract call in a single transaction, atomically. And, some minor features. If the Argo node adds feature to immediately execute the Lua code inside the transaction payload (, but not deploying it), it can cover virtually all of the functions of composable transaction.

Let say this types of transaction as INSTANTCALL, the payload of transaction contains aergo lua code. If aergo node receives this transaction, the node executes the default function inside that payload only once, with slightly different behavior from CALL transaction. The node does not deploy the code to state db nor store state values or global values. I said this as ONE SHOT.

Your composable transaction looks quite simple and intuitive if it has a sequence of contract calls only, but the complexity looks significantly increased if it added result variables, scripts or some commands. I felt that it is another programming language.

[kroggen]

There are problems when allowing smart contract language on transactions:

1. It is harder to understand when reviewing the transaction on the wallet
2. It is more verbose (it uses more lines and characters)
3. There should be limits on what is allowed on EOA (not allowed examples: governance, events...)

The script logic limits what can be done, and makes it somewhat understandable. If the logic shown on the wallet is not clear, just do not sign the transaction.

The Aergo's Ledger App already has support for MultiCall, as can be seen here and here

It is not the simplest way, but it gives a lot of power to the dApps

A simpler method is being created for simpler cases, but it is more limited than this

[hayarobi]

There is a trade-off between verbosity and readability. The composable tx lacks of comment, argument type checking or etc, and provided limited functionality to manipulate variables and flow controls. If #266 is approved and put plain lua code for INSTANTCALL, both node and human will be able to review that transaction easier.

It seems possible to use a specific system function set for INSTANTCALL by applying the method of using system_lib_v* variables for the V4 hard fork.

I found a feature on Aptos chain, called Move Script , which has similar with my suggestion. For reference, smart contract code deployed intot the chain is called Module.

[kroggen]

If you want to create an alternative, create an issue or open an item in discussions. Then put all the details there of how it should work, including how a normal user would sign such transaction on a hardware wallet, and examples of code for some cases

[kroggen]

Anyway, this feature does not need to be included now. It can be further analyzed and come on V5 (or not be included)

This next hardfork (V4) is focused on security

[kroggen]

Also note that this feature does not aim to be a fully functional scripting language.

It started very basic, with just multiple contract calls and assertion, and then it was enhanced with some basic flow control.

It can also be released with just the basic commands.

Argument type checking is done by existing Lua functions. If an argument has unexpected type, it will fail and the whole transaction will be reverted.

[shepelt]

I think it would make sense to enable composable transaction as a feature that can be enabled and deploy on alphanet to perform more extensive test on a live environment (same as SQL feature.) That way, it can be used for private/enterprise environment as well.

[kroggen]

That makes sense, it is a good option

But technical decisions should be made before the deployment because it is not good to maintain different versions

I will also make a review of the functionalities and compare with alternatives

[kroggen]

Text-Based Transactions are an alternative but they do not cover all the use cases possible with Composable Transactions

Text-Based Transactions are better for:

• Token transfers (single or multiple, fungible and non-fungible)
• Token swaps (fungible and non-fungible)

And these are one of the most common use cases on a blockchain.

Composable Transactions cover the remaining cases, as it is more generic. They can be used with any kind of contract, not only those that deal with tokens.

Both above allow review of the commands on the hardware wallet, so the user can check before signing the transaction.

Making a token swap using Composable Transactions is indeed very verbose. Text-Based Transactions come to fix that.