Do you feel you could automate all supported transaction types with this proposed solution? Are there any primitives missing?
We wanted to highlight the following transaction primitives that Kadena would find useful:
-
(A) We’re a sharded blockchain so the ability to test different types of transactions across different shards would be important. Will there be a way to specify which shard (sub-network) a transaction is expected to execute on in the testing framework? Or does testing transactions in different shards mean creating different configuration files for each shard?
-
(B) Will it be possible to connect related transactions? For example, could we specify that transaction A occurs after transaction B? Expanding on the previous ask (A), could we specify the sub-network of related transactions? For example, can we state that transaction A must occur after transaction B; and also state that transaction A must occur in chain (shard/sub-network) 1, while transaction B must occur in chain (shard/sub-network) 2?
Motivation for ask (B):
-
Kadena’s public blockchain has two transaction workflows: executions and continuations. Execution transactions are a set of operations that all execute at the same time (i.e. what’s generally considered a regular transaction in other blockchains). An example of this is a transfer transaction that will debit funds from one account and credit another account at the same time. Continuation transactions, on the other hand, are partitioned into operations that occur sequentially but at different times (i.e. multi-step transactions). For example, one transaction can begin a continuation by debiting funds from one account at block height 1, while another transaction occurs at block height 4 that finishes the continuation by crediting the funds to another account if certain on/off-chain conditions are met. And some steps in continuations might be programmed to take place in specified chain(s) only.
-
Continuations are a vital component of what we call “cross-chain transfers”. This is the process of burning coins on one chain (shard/sub-network) and redeeming them in another chain. The coins can only be redeemed if an spv proof is provided that shows that the coins were burned in the previous chain. We implement this workflow by using continuations: the first transaction (the first step) debits the funds in the source chain; an spv proof is generated proving that the funds were burned in the source chain; and the last transaction credits the funds to the specified account in the target chain. The last step can only be executed in the target chain and with an spv proof that shows that the first step successfully occurred in the source chain.
