KIP-0032: Cross-Chain Function Call Syntax Enhancement

[DaisukeFlowers]

This KIP proposes a syntax enhancement for Pact that enables specifying the chain ID within function calls to facilitate direct cross-chain interactions. By including the chain ID in function calls, we aim to simplify and expand cross-chain workflows, reducing reliance on yield/resume constructs for data transfer only. This will allow contracts to directly interact across chains, improving developer efficiency and usability for complex multi-chain operations.

Looking forward to feedback and any suggestions on refining the proposal!

---

• To see the specific tasks where the Asana app for GitHub is being used, see below:
  • https://app.asana.com/0/0/1208690299578288

[LindaOrtega]

Hi @DaisukeFlowers, I'm rewording this a bit to make sure I understand the main ask:

• Is this asking for smart contracts to call functions in other chains?
• This would be similar to how smart contracts can currently call functions in other smart contracts within the same chain, correct?

[LindaOrtega]

Example of reading the state in another chain:
Let say the following Pact code is being executed on Chain 0:

(free.token.get-balance ACCOUNT_A)
(1.free.token.get-balance ACCOUNT_A)

(free.token.get-balance ACCOUNT_A) will retrieve the account balance of ACCOUNT_A in Chain 0.
But (1.free.token.get-balance ACCOUNT_B) will retrieve the account balance of ACCOUNT_A in Chain 1.

Example of changing the state in another chain:
Let say the following Pact code is being executed on Chain 0:

(2.free.token.transfer ACCOUNT_A ACCOUNT_B 2.5)
(free.someOtherToken.transfer ACCOUNT_B ACCOUNT_A 1.0)

(2.free.token.transfer ACCOUNT_A ACCOUNT_B 2.5) will transfer funds from these accounts on chain 2.
(free.someOtherToken.transfer ACCOUNT_B ACCOUNT_A 1.0) will transfer funds from these accounts on chain 0.

---

aka, being able to execute a Pact function on Chain 2 while executing other code in Chain 0, for example.
Are these interpretations correct?

[DaisukeFlowers]

Hi @LindaOrtega, all statements are correct.
The function will be executed as if on the target chain.
In the last example:
If the following is executed on chain 0
(2.free.token.transfer ACCOUNT_A ACCOUNT_B 2.5)
ACCOUNT_A from chain 2 will transfer to ACCOUNT_B from chain 2.
The function will be executed as if in chain 2 from chain 0.

[LindaOrtega]

Aw, I see!

TL;DR:
Unfortunately, being able to execute code on multiple chains (especially code that changes the state) is not feasible at the moment with the current chainweb-node architecture.

That means that chain X cannot run code on chain Y directly.

Longer Explanation:
Each chain has its own block and Pact history. You can think of the different chains in Kadena as "mini" blockchains in their own right; and together they make up the bigger Kadena network. Its just that the consensus algorithm of the entire network requires hash information from all chains (see the Whitepaper for more details).

So for the different chains to communicate with each other about their respective Pact state, they need to use a "bridge" (of sorts). This "bridge" is what we usually call cross-chain operations.

---

But I would like to explore the problem you brought up a little bit more, and see if there is another solution that can work. For example, there might be a way to make using defPact easier.

1. Could you elaborate on the use case you had in mind that needed the feature being proposed?
2. And is it something that's feasible (but complex) to do right now?
3. Is there a preference for being able to read the state of different chains? Or is the preference for being able to execute code that changes the state in another chain?

edit: added the third question

[DaisukeFlowers]

I understand.
What I'm trying to accomplish is the possibility to pay dividends.
In order to do that, all shares contracts in all chains need to know how much KDA they have to calculate the dividend per share.
If the shares contract in chain 0 has 50 KDA, shares contract in chain 1 has 50 KDA and shares contract in chain 2 has 0 KDA, and all my shares are in contract in chain 2, even if it has 0 KDA, I would still be entitle of the corresponding of the total 100 KDA that the company holds.
In order to do this, each chain needs to transmit what they hold to all other chains and once all chains know how much they hold they can calculate how much dividend per share is, and do the analysis of how much they have and how much they owe, and then if they owe more than they have, all shares contracts in different chains will need to balance and transfer between them to have enough to pay the dividends they owe.
To do all this, is a big amount of cross-chain transfers and blocks.
It would be easier if I could just read the tables in other chains (call functions from other chains like get-balance), but that will not be possible.
The other option is to do it in one chain, I have that contract 100% functional but I really want to do it multi-chain.
I know is possible, I just need to find a good way to test all this cross-chain interaction ( looking forward cross-chain in RELP, I hope we get it soon)
Thanks you @LindaOrtega

[edmundnoble]

You can absolutely do this multi-chain. But this will require typical techniques from bridges and more generally distributed systems, like locking up shares for some period so that the chains can all agree for that period.

[DaisukeFlowers]

Hi @edmundnoble, I found it better to calculate the time weighted average of each share as part of the transfer function and just use that number to calculate the dividend per share than having a locking system.
Once I can test and make sure everything works as intended in cross-chain I would love to share it with you and get some feedback.

[edmundnoble]

Sure. Time-weighting sounds feasible, just as long as you've calculated that the time-weight is sufficient to prevent any way you'd game the system by doing other things with the shares in the meantime.